Para recuperar-se de falhas que afetam transações, um SGBD pode manter um log, de modo a controlar as operações da transação que afetem valores dos itens do banco de dados. Quando de uma falha, o SGBD deve buscar, no log, as transações T com registro [start_transaction,T], mas que não tenham o registro [commit,T]. Essas transações serão revertidas (rollback), de modo a possibilitar que seus efeitos sejam desfeitos no banco de dados.

A técnica denominada SQL injection tem por objetivo o acesso a bancos de dados por meio de aplicações web. Ataques embasados nessa técnica podem ser evitados por checagem de dados de entrada no backend e frontend da aplicação.

Gatilhos (triggers) podem ser usados para impor restrições de integridade semântica em um banco de dados relacional. Um gatilho pode especificar evento, condição e ação. A ação é executada se a condição for satisfeita quando ocorrer o evento. Se uma condição não for especificada, a ação será disparada pelo evento. Uma ação pode ser uma sucessão de declarações SQL.

A normalização é um processo no qual são analisados esquemas de relações, com base em dependências funcionais e chaves primárias, visando minimizar redundâncias e anomalias de inserção, exclusão e atualização. Na normalização, se ocorrer a decomposição de uma relação, cada dependência funcional existente antes da decomposição terá de ser representada em alguma relação existente depois da decomposição.

A partir das dependências funcionais apresentadas na tabela a seguir, é correto inferir que as relações estão na terceira forma normal, pois: as relações só contêm atributos atômicos; para as relações que possuem chaves primárias com vários atributos, nenhum atributo externo à chave é funcionalmente dependente de parte da chave primária; há dependência transitiva entre atributo não-chave e chave primária.

Acerca do modelo relacional e da normalização de dados, julgue os itens a seguir.

O teste para a segunda forma normal envolve verificar se os atributos do lado esquerdo das dependências funcionais são parte da chave primária. Nas dependências funcionais apresentadas na tabela acima, as relações atendem aos requisitos da segunda forma normal.

A partir do modelo de entidades e relacionamentos e do esquema resumido do banco de dados relacional, é correto inferir que o esquema descreve incorretamente parte do projeto de um banco de dados para o modelo apresentado, uma vez que há atributos e entidades incorretamente mapeados para as relações.

Segundo a figura I, o número de horas que um funcionário trabalha em um hotel é determinado combinando-se entidades dos tipos HOTEL e FUNCIONARIO; uma entidade do tipo HOTEL pode estar associada a apenas uma entidade do tipo HOSPEDE; os valores do atributo NOME são distintos para cada entidade do tipo CRIANCA.

Segundo a figura I, para identificar uma entidade do tipo CRIANCA, é necessário identificar uma entidade do tipo HOSPEDE; para cada entidade do tipo HOTEL, o atributo NOME tem valor único; para cada entidade do tipo FUNCIONARIO, o atributo APELIDO pode ter um conjunto de valores. O atributo HORAS pode ser migrado para a entidade FUNCIONARIO.

Há sistemas nos quais threads podem ser suportados no nível de usuário e no nível de sistema operacional. Se os threads no nível de usuário são mapeados para os threads no nível de sistema operacional, para se obter maior concorrência na execução dos threads no nível de usuário, em vez de mapear só um thread no nível de usuário para cada thread no nível de sistema operacional, tipicamente deve-se mapear mais de um no nível de usuário para cada um no nível de sistema operacional.