Exercícios de Exame

Opção d: $\pi_{c1,\mathrm{MAX}(c2)}(\sigma_{c3=5}(T1 \bowtie T2))$, com agregação de $\mathrm{MAX}(c2)$ por grupo $c1$.

Na tradução de SQL para álgebra relacional, o FROM corresponde à junção, o WHERE à seleção e o GROUP BY em conjunto com as funções de agregação do SELECT corresponde à agregação na projecção. Assim, primeiro se faz $T1 \bowtie T2$, depois $\sigma_{c3=5}$ e por fim projeta-se $c1$ com $\mathrm{MAX}(c2)$ agrupado por $c1$.

• $\sigma_{c3=5}(\pi_{c1,\mathrm{MAX}(c2)}(T1 \bowtie T2))$. A seleção é aplicada depois da projeção e da agregação, quando deve incidir sobre a junção antes de projetar.
• $\mathrm{MAX}_{c2}(\pi_{c1}(\sigma_{c3=5}(T1) \bowtie T2))$. O operador de agregação não pode ser aplicado a uma mera projeção de $c1$.
• $\pi_{c1,\mathrm{MAX}(c2)}(\sigma_{c3=5}(T1) \bowtie T2)$. Selecionar $c3=5$ só em $T1$ ignora a condição sobre a junção das duas tabelas.
• $\pi_{c1,\mathrm{MAX}(c2)}(\sigma_{c3=5}(T1 \bowtie T2))$. O WHERE dá a seleção $\sigma_{c3=5}$ sobre a junção, e o GROUP BY com MAX(c2) corresponde à agregação na projeção.

Opção d: $\pi_{a}(\sigma_{c=-1}(T1 \bowtie_{T1.a>T2.b} T2))$.

A junção com a condição $T1.a > T2.b$ traduz-se por $\bowtie_{T1.a>T2.b}$, o filtro $c=-1$ por $\sigma_{c=-1}$ e o SELECT a por $\pi_a$. A ordem correta é junção, seleção e projecção.

• $\sigma_{c=-1 \wedge T1.a>T2.b}(\pi_{a}(T1 \bowtie T2))$. A condição de junção $T1.a > T2.b$ não pode ficar numa seleção depois de uma junção natural, que não a impõe.
• $\pi_{a}((\sigma_{c=-1}(T1)) \bowtie_{T1.a>T2.b} T2)$. A condição $c=-1$ pode dizer respeito a qualquer das tabelas, não só a $T1$.
• $\sigma_{c=-1}(\pi_{a}(T1 \bowtie_{T1.a>T2.b} T2))$. A seleção não pode ser aplicada depois da projecção, que já eliminou os atributos necessários à condição.
• $\pi_{a}(\sigma_{c=-1}(T1 \bowtie_{T1.a>T2.b} T2))$. Faz-se a junção com a condição $T1.a>T2.b$, aplica-se a seleção $c=-1$ e projeta-se $a$.

SELECT ACRONYM, DESIGNATION
FROM PARTIES
WHERE SUBSTR(ACRONYM, 1, 1) <> SUBSTR(DESIGNATION, 1, 1)
ORDER BY ACRONYM ASC;

SUBSTR(ACRONYM, 1, 1) extrai a primeira letra da sigla e SUBSTR(DESIGNATION, 1, 1) a primeira letra da designação. O filtro <> guarda apenas os partidos em que diferem, e ORDER BY ACRONYM ordena o resultado.

SELECT D.NAME
FROM DISTRICTS D
WHERE D.REGION = 'C'
  AND D.NAME IN (
    SELECT P.NAME
    FROM MUNICIPALITIES M
    JOIN PARISHES P ON P.MUNICIPALITY = M.CODE
    WHERE M.DISTRICT = D.CODE
  )
ORDER BY D.NAME ASC;

Para cada distrito do continente, a subconsulta percorre os seus municípios e as respetivas freguesias e devolve os nomes de freguesias; o IN verifica se o nome do distrito consta dessa lista.

SELECT DISTINCT name
FROM User
WHERE id NOT IN (
    SELECT user
    FROM Photo
);

A subconsulta SELECT user FROM Photo devolve os identificadores de todos os utilizadores com pelo menos uma fotografia. O NOT IN exclui esses utilizadores, sobrando os que nunca publicaram fotos.

SELECT nome
FROM Estudante, Amizade
WHERE Estudante.ID = Amizade.ID1
GROUP BY Estudante.ID
HAVING COUNT(*) > 3;

Cada linha de Amizade com ID1 = Estudante.ID é um amigo do estudante. A junção com essa condição seguida de GROUP BY Estudante.ID conta os amigos de cada estudante, e o HAVING COUNT(*) > 3 filtra os que têm mais de três.

A dependência $AF \to D$ não pode ser obtida.

Calcula-se o fecho de cada lado esquerdo. $AF^+ = \{A, F\} \cup \{B\} \cup \{E\} = \{A, B, E, F\}$, que não inclui $D$. Todas as outras opções são triviais ou deriváveis pelas regras de Armstrong.

• $ACD \to D$. É uma dependência trivial, pois $D$ já pertence ao lado esquerdo.
• $AF \to D$. O fecho de $AF$ é $AF^+ = \{A, B, E, F\}$, que não contém $D$, logo a dependência não se segue.
• $AF \to E$. De $AF$ chega-se a $B$ por $F \to B$ e a $E$ por $B \to E$.
• $AFC \to D$. De $AFC$ chega-se a $B$ e $E$; como já se tem $A$, $B$ e $C$, a regra $ABC \to DGH$ dá $D$.

$R$ não está na BCNF. A chave candidata é $ABCF$, pois $ABCF^+ = \{A, B, C, D, E, F, G, H\}$. Todas as dependências não triviais têm lado esquerdo ($ABC$, $F$, $B$, $G$) que não é superchave, pelo que a condição da BCNF é violada.

Para estar na BCNF, o lado esquerdo de todas as dependências não triviais deve ser uma superchave. Aqui, por exemplo, $F \to B$ tem lado esquerdo $F$, que não determina todos os atributos, logo a relação não está na BCNF.

A relação está na 1ª FN.

A chave candidata é $AB$, pois $AB^+ = \{A, B, C, D, E\}$. Como todos os atributos são atómicos, a relação está na 1ª FN. A dependência $A \to C$ mostra que um subconjunto próprio da chave determina um atributo não primo ($C$), pelo que há dependência parcial e a relação não está na 2ª FN (nem em formas superiores).

• 3ª FN. A dependência $A \to C$ viola a 3ª FN: $A$ não é superchave e $C$ não é atributo primo.
• 1ª FN. Os atributos são atómicos, logo está na 1ª FN; mas $A \to C$ é uma dependência parcial da chave $AB$, pelo que não está na 2ª FN.
• BCNF. $A \to C$ viola a BCNF, pois $A$ não é superchave.
• 2ª FN. A chave candidata é $AB$ e $A \to C$ é uma dependência parcial, logo não está na 2ª FN.

Uma vista pode ser usada como qualquer tabela, exceto que só permite a inserção de registos se não juntar várias tabelas.

Uma vista é uma tabela virtual definida por uma consulta. Pode ser consultada como qualquer tabela, mas inserir registos numa vista que junta várias tabelas é ambíguo (não se sabe em que tabela colocar cada tuplo), ao passo que numa vista simples a inserção é possível.

• Uma vista pode ser usada como qualquer tabela, sem restrições.. As inserções numa vista que junta várias tabelas nem sempre são possíveis.
• Uma vista pode ser usada como qualquer tabela, exceto que só permite a inserção de registos se não juntar várias tabelas.. Numa vista simples (sem junção de várias tabelas) a inserção é possível; em vistas com junções a atualização é ambígua.
• Uma vista pode ser usada como qualquer tabela, exceto para operações de DELETE.. As limitações incidem sobre as atualizações em geral, não especificamente sobre o DELETE.
• Uma vista só pode ser usada como tabela se for materializada.. Uma vista virtual também pode ser consultada como tabela.

CREATE TRIGGER AmizadeMesmoCurso
AFTER INSERT ON Estudante
FOR EACH ROW
BEGIN
    INSERT INTO Amizade(ID1, ID2)
    SELECT e1.ID, e2.ID
    FROM Estudante AS e1, Estudante AS e2
    WHERE (e1.ID = NEW.ID OR e2.ID = NEW.ID)
      AND e1.curso = e2.curso
      AND e1.ID != e2.ID;
END;

O gatilho dispara depois de cada inserção em Estudante. Para cada par de estudantes em que um deles é o novo registo (NEW.ID), do mesmo curso e distintos entre si, insere-se a linha correspondente em Amizade, criando a amizade nos dois sentidos.

INSTEAD OF INSERT ON V.

Em SQLite, uma vista não é atualizável diretamente. Para aceitar inserções numa vista, define-se um gatilho INSTEAD OF INSERT ON V cuja ação reescreve a operação na tabela ou tabelas subjacentes.

• AFTER INSERT ON R. Um gatilho AFTER na tabela subjacente não intercepta a operação sobre a vista.
• INSTEAD OF INSERT ON V. Em SQLite, os gatilhos INSTEAD OF executam a ação definida em vez da operação sobre a vista, permitindo atualizações de vistas.
• INSTEAD OF INSERT ON R. O gatilho deve incidir sobre a vista V, não sobre a tabela R.
• BEFORE INSERT ON R. Um gatilho BEFORE na tabela subjacente não substitui a operação sobre a vista.

Com a cláusula UNIQUE.

Uma tabela só pode ter uma chave primária, mas pode ter várias chaves candidatas. Em SQL, cada chave candidata adicional define-se com a restrição UNIQUE, que impõe unicidade aos valores dessa coluna ou conjunto de colunas.

• Com a cláusula FOREIGN KEY. FOREIGN KEY define uma chave estrangeira, não uma chave candidata.
• Com a cláusula UNIQUE. Uma chave candidata adicional define-se com UNIQUE, que garante unicidade dos valores, tal como a chave primária.
• Com uma das cláusulas PRIMARY KEY ou UNIQUE. A chave primária já está definida; a segunda tem de usar UNIQUE.
• Com a cláusula PRIMARY KEY. Só pode existir uma chave primária por tabela.

É a horizontal: partição dos dados por vários servidores, suportados em hardware menos poderoso.

A escalabilidade horizontal (scale-out) reparte os dados por várias máquinas commodity através de partição (sharding), enquanto a vertical (scale-up) consiste em tornar uma única máquina mais potente. Para bases de dados, a forma tradicional é a horizontal.

• É a horizontal, que consiste na partição de dados, o que implica a compra de hardware mais poderoso.. A partição de dados é horizontal, mas não exige hardware mais poderoso.
• É a vertical, que consiste na implementação de vários níveis de servidores para armazenar todos os dados.. Vários níveis não é a definição de escalabilidade vertical.
• É a horizontal, que consiste na partição dos dados, o que permite suportar a base de dados em hardware menos poderoso.. A escalabilidade horizontal (scale-out) distribui os dados por vários servidores comuns, evitando hardware caro e poderoso.
• É a vertical, que consiste na compra de hardware mais poderoso para armazenar todos os dados.. Comprar hardware mais potente é escalabilidade vertical, mas não é a forma tradicional de escalar bases de dados distribuídas.

Só comete $T_i$ se as transações $T_j$ cujas alterações foram usadas por $T_i$ já tiverem sido cometidas.

Um escalonamento é recuperável se nenhuma transação faz commit antes de todas as transações das quais leu dados terem feito commit. Assim, se uma transação falhasse, não haveria risco de ter de desfazer commits já feitos (commit em cascata).

• Que não gera bloqueios.. A recuperabilidade não elimina bloqueios.
• Que a base de dados fica consistente.. A consistência é garantida pelas propriedades ACID em geral, não especificamente pela recuperabilidade.
• Que só comete uma transação $T_i$ se as transações $T_j$ cujas alterações foram usadas por $T_i$ já tiverem sido cometidas.. Num escalonamento recuperável, uma transação só pode fazer commit depois de todas as transações das quais leu dados terem feito commit, evitando commits em cascata impossíveis de desfazer.
• Que resulta numa base de dados igual à que seria obtida se as transações fossem executadas em série.. Essa é a definição de serializabilidade, não de recuperabilidade.

Numa tabela com 2 colunas: a chave e o valor respetivo.

Numa base de dados chave-valor, cada registo é um par (chave, valor). A chave identifica univocamente o valor, que pode ser qualquer objeto, sem esquema interno imposto pela base de dados.

• Numa estrutura organizada por colunas.. Isso descreve uma base de dados de famílias de colunas (column-family), não chave-valor.
• Em 2 tabelas, uma com as propriedades dos nós e outra com as suas relações.. Isso descreve uma base de dados de grafos.
• Numa base sem qualquer esquema explícito.. A ausência de esquema é típica de documentos, não de chave-valor.
• Simplesmente numa tabela com 2 colunas, a chave e o valor respetivo.. Um key-value store guarda pares (chave, valor): a chave identifica o registo e o valor é o conteúdo associado.