Assine o DeepL Pro para traduzir documentos maiores.

Visite www.DeepL.com/pro para mais informações.

CONCEPÇÃO DA BASE DE DADOS:

Normalização - Exercícios e respostas

(a) A tabela apresentada na Figura 1 é suscetível de anomalias de atualização. Dê exemplos de

anomalias de inserção, eliminação e modificação.

Respostas:

Esta tabela não está bem estruturada, não está normalizada e contém dados redundantes. Utilizando uma
abordagem de baixo para cima, analisamos a tabela dada para detetar anomalias. A primeira observação
é que vemos vários valores numa coluna de consultas, o que, obviamente, viola o 1NF. Ao assumir o
staffNo e o patientNo como chaves candidatas, existem muitas anomalias.

Anomalias de inserção:

Para inserir um novo doente particular que marca uma consulta com o médico designado, é
necessário introduzir os dados correctos da equipa. Por exemplo, para inserir os detalhes de um
novo doente em patientNo, patientName e uma consulta, temos de introduzir os detalhes correctos
do médico (staffNo, dentistName) para que os detalhes do doente sejam consistentes com os valores
do médico designado, por exemplo, S1011.
Para introduzir dados de um novo doente que não tenha um médico para ser atribuído, não podemos
inserir valores NULL para a chave primária.

Anomalias de eliminação:

Se quisermos eliminar um doente chamado Ian MacKay, por exemplo, é necessário eliminar dois
registos, como nas linhas 3 e 4. Esta anomalia também é óbvia quando queremos apagar o
dentistName, sendo necessário apagar vários registos para manter a integridade dos dados.
Quando eliminamos um registo de um Dentista, por exemplo Tony Smith, os detalhes sobre os
seus pacientes também se perdem da base de dados.
Anomalias de modificação:

Com dados redundantes, quando queremos alterar o valor de uma coluna de um determinado
dentista, por exemplo, o dentistName, temos de atualizar todos os registos de dentistas atribuídos ao
doente em causa, caso contrário a base de dados tornar-se-á inconsistente. Também é necessário
alterar os horários das consultas, porque cada dentista tem horários diferentes.

(b) Descreva e ilustre o processo de normalização da tabela apresentada na Figura 1 para 3NF.
Indique quaisquer suposições que tenha feito sobre os dados apresentados nesta tabela.

Os pressupostos assumidos incluem que um doente está registado num único consultório e que pode
ter mais do que uma consulta num determinado dia. Todos os horários foram fixados para todos os
dias e semanas.

No 1NF, removemos todos os grupos repetidos (nomeação), atribuímos uma nova coluna (apptDate
e apptTime) e atribuímos chaves primárias (chaves candidatas). Em seguida, descobrimos as
dependências funcionais (FDs). Utilizando o diagrama de dependências, representamos a tabela da
seguinte forma. (NF - significa Forma Normal)
Nota: A forma de encontrar os FDs é subjectiva!!! No entanto, a regra é que deve refletir a situação
real.

FD1
pessoal doenteNo patientName cirurgiaNã
apptDate hora de dentistaNome
Não o
início

FD2 FD3

FD4

FD5

FD1 já está em 2NF. Neste caso, podemos ver que FD2 (depende apenas de staffNo) e FD4
(depende apenas de staffNo e apptDate) violam o 2NF. Estas duas NFs são parcialmente
dependentes das chaves candidatas e não das chaves completas. A FD2 pode manter-se por si só,
dependendo do staffNo e, entretanto, a FD4 também pode manter-se por si só, dependendo do
staffNo.
O FD3 viola o 3NF mostrando a dependência transitiva em que surgeryNo e patientName
dependem de patientNo enquanto patientNo depende de staffNo, ou seja, a não-chave depende de
outra não-chave.
O 2NF já está no 1NF e não há dependência parcial. Por isso, precisamos de remover a FD2 e a
FD4 dividindo-as em novas tabelas e, ao mesmo tempo, criando chaves estrangeiras. As novas
tabelas que estão em 2NF são mostradas abaixo.

pessoal apptDate hora de pacienteN patientName

Não início o

pessoal apptDate cirurgiaNã

Não o

pessoal dentistaNome
Não

Finalmente, no 3NF, devemos remover a dependência transitiva. Neste caso, removemos a

FD3 dividindo-a numa nova tabela. A dependência transitiva que resta é o nome do doente
(patientName) que depende do número do doente (patientNo), pelo que o dividimos numa
nova tabela e criamos uma chave externa.

FK
pessoal apptDate hora de pacienteN
Não início o

FK

pessoal apptDate cirurgiaNã

Não o

pessoal dentistaNome
Não

doenteNo nome do
paciente

Vamos reorganizar e dar nomes às mesas.

pessoal dentistaNome
Não

Dentista(staffNo, dentistName)

FK
pessoal apptDate cirurgiaNã
Não o

Cirurgia(staffNo, apptDate, surgeryNo)

doenteNo nome do
paciente

Paciente(patientNo, patientName)

FK
pessoal apptDate hora de pacienteN
Não início o

Consulta(staffNo, apptDate, apptTime, patientNo)

Uma agência chamada InstantCover fornece pessoal a tempo parcial/temporário a hotéis em toda a
Escócia. O quadro apresentado na figura 2 indica o tempo passado pelo pessoal da agência a
trabalhar em dois hotéis. O número de segurança social (NIN) é único para cada trabalhador.

(1) A tabela apresentada na Figura 2 é suscetível de anomalias de atualização. Dê exemplos de

anomalias de inserção, eliminação e modificação.

Respostas:

É óbvio que o NIN e o contractNo podem ser chaves candidatas. Existem redundâncias de dados
em termos de grupos de repetição.

Anomalias de inserção:

Para inserir os dados do novo hotel, temos de saber o NIN do pessoal, porque se trata de uma chave
primária e não podemos atribuir um valor NULL à chave primária. Por exemplo, se quisermos
inserir os dados de um novo hotel, temos de inserir também o NIN e o contractNo.
Para recrutar um novo funcionário, é necessário conhecer os pormenores do hotel. Por exemplo, se
quisermos recrutar e atribuir novos funcionários ao H4, temos de introduzir os dados correctos do
H4 para que os dados do hotel sejam coerentes com os valores do hotel H4.

Anomalias de eliminação:

Se eliminarmos um registo da tabela que representa o nome do funcionário, por exemplo, John
Smith, os detalhes sobre o contrato também se perderão da base de dados e afectarão outros registos,
como se pode ver na segunda linha do contratoNo (C1024).
Pelo contrário, quando eliminamos um contratoNo, os dados de outros funcionários também se
perdem. Por exemplo, se apagarmos o C1025, os dados da Sarah White e do John Smith perder-se-
ão.

Anomalias de modificação:

Se alterarmos o valor do contractNo, é necessário alterar vários registos, por exemplo, as linhas 1 e
2, bem como as linhas 3 e 4, se editarmos qualquer um dos contractNo.
Se editarmos os detalhes do pessoal, por exemplo, actualizando John Smith, é necessário atualizar
vários registos. Isto também se aplica à coluna hotelNo.
(2) Descreva e ilustre o processo de normalização da tabela apresentada na Figura 2 para 3NF.
Indique quaisquer suposições que tenha feito sobre os dados apresentados nesta tabela.

No 1NF, removemos todos os grupos repetidos, se existirem, e atribuímos chaves primárias (chaves
candidatas). Em seguida, descobrimos as dependências funcionais (FDs). Utilizando o diagrama de
dependências, representamos a tabela da seguinte forma. (NF -stand para Forma Normal)

FD1 FD4

NIN contratoNão horas eNome hotelNão hotelLocalizaç

ão

FD2

FD3

Obviamente, FD2 e FD3 violam a 2NF (dependência parcial) e FD4 viola a 3NF (dependência
transitiva). No 2NF, removemos a dependência parcial do FD2 e do FD3 dividindo-os em novas
tabelas, como se mostra a seguir.

NIN contratoNão horas

NIN eNome

contratoNão hotelNão hotelLocalizaç

ão
Em 3NF, eliminamos a dependência transitiva do FD4, dividindo-o numa nova tabela, como se
mostra a seguir.

FK FK

NIN contratoNão horas

NIN eNome

FK

contratoNão hotelNão

hotelNão hotelLocalizaç
ão

Finalmente, vamos reorganizar a tabela e atribuir nomes.

NIN eNome

Pessoal(NIN,
eName)

hotelNão hotelLocalizaç
ão

Hotel(hotelNo, hotelLocation)

FK

contratoNão hotelNão

Contrato(contractNo, hotelNo)
FK FK
NIN contratoNão horas

WorkHours(NIN, contractNo, hours)