Normalização em BD Relacional

Apresentação em tema: "Normalização em BD Relacional"— Transcrição da apresentação:

1 Normalização em BD Relacional
Banco de Dados I Aline Vasconcelos

2 Normalização Conjunto de Normas (ou Formas Normatizadas) que representam restrições às quais uma Relação deve atender. Estas normas são definidas com base nas chaves das relações e nas dependências funcionais entre seus atributos. A Normalização representava uma ferramenta de projeto de banco de dados relacional antes da consagração do Modelo E-R como a metodologia definitiva de projeto.

3 Normalização A Normalização de relações pode ser vista, atualmente, como uma ferramenta para análise de dados, útil em situações localizadas, notadamente quando utilizamos técnicas de projeto bottom-up. O processo consiste em projetar relações normalizadas a partir de um conjunto de relações não normalizadas até que sejam eliminadas as possibilidades de anomalias de atualização.

4 1ª Forma Normal Uma relação está em 1FN se, e somente se, todos os seus atributos contêm apenas valores atômicos (simples, indivisíveis). Atributos multivalorados ou compostos (estruturas de dados) devem ser eliminados.

5 Relação Pacientes - Não Está em 1FN
Id Nome Endereço Telefones Maria 101 R. C, 89 - Centro 121 João R. Paz, 76 - Pq. Flores R. D. 70 - Centro Antônio 231 Carlos R. X, 789- Pq. Novo 332

6 1ª Forma Normal Como colocar a relação Pacientes anterior na 1 FN?
Criar uma nova relação apenas para armazenar valores de telefones de Pacientes. Criar um campo na tabela Pacientes para cada valor de telefone. Fixa um número máximo de telefones e dá margem para muitos valores nulos. Dividir o campo Endereço em campos independentes para cada um dos componentes de informação do endereço.

7 2ª Forma Normal Uma Relação está em 2ª Forma Normal se, e somente se, estiver em 1ª Forma Normal e todo atributo não-primo (isto é, que não seja membro da chave primária) for TOTALMENTE dependente da chave primária.

8 Relação Consultas não está em 2FN
Ex de Relação não Normalizada: CONSULTAS(IdPaciente, IdMédico, Data, Hora, NomePaciente, NomeMédico, CRMMédico) Dependências Funcionais: {IdPaciente, IdMédico} -> {Data, Hora} {IdPaciente} -> {NomePaciente} {IdMédico} -> {NomeMédico, CRMmédico}

9 Dependências Funcionais
Dada uma Relação R e dois atributos X e Y, diz-se que Y é funcionalmente dependente de X se, e somente se, cada valor de X em R for associado a precisamente um valor de Y. Representa-se: R.X -> R.Y Lê-se: X determina funcionalmente Y

10 2 FN As dependências funcionais da relação Consultas indicam que atributos não-primos, i.e. NomePaciente, NomeMédico e CRMMédico, dependem PARCIALMENTE da chave primária. Portanto, a relação não está em 2 FN. A relação Consultas não está bem projetada, misturando conceitos diversos, i.e. Pacientes, Médicos e Consultas.

11 2 FN Como colocar a relação Consultas em 2 FN?
Tratar cada conceito em uma relação: Pacientes (IdPaciente, NomePaciente) Médicos (IdMedico, NomeMedico, CRMMedico) Consultas (IdPaciente, IdMedico, Data, Hora)

12 3ª Forma Normal Uma Relação está em 3ª Forma Normal se, e somente se, estiver em 2ª Forma Normal e nenhum atributo não-primo (isto é, que não seja membro da chave primária) for TRANSITIVAMENTE dependente da chave primária.

13 A Relação Pacientes não está em 3FN
Pacientes (Id, Nome, Identidade, Telefone, Sexo, SiglaConvênio, NomeConvênio, TelefoneConvênio) As dependências funcionais são: {Id} -> {Nome, Identidade, Telefone, Sexo, SiglaConvênio} {SiglaConvênio} -> {NomeConvênio, TelefoneConvênio}

14 A Relação Pacientes não está em 3FN
Como colocar a relação Pacientes em 3 FN? A relação Pacientes mistura conceitos diversos, i.e. Pacientes e Convênios. Separar os conceitos de acordo com as dependências identificadas: Pacientes (Id, Nome, Identidade, Telefone, Sexo, SiglaConvênio) Convênios (SiglaConvênio, NomeConvênio, TelefoneConvênio)

15 Forma Normal de Boyce-Codd (FNBC) ou (BCNF)
Uma Relação está em FNBC se para toda dependência funcional X -> Z, X for uma superchave. Superchave: qualquer subconjunto dos atributos cujos valores combinados não se repetem. Assim, uma chave candidata ou primária é uma superchave.

16 FNBC A FNBC é uma forma restritiva de 3 FN, ou seja, toda relação em FNBC está também em 3 FN, embora o contrário não seja verdadeiro. Uma Relação está em FNBC se para toda dependência funcional, X -> Y, X for uma superchave.

17 FNBC: Exemplo Atendimentos (Paciente, Hospital, Médico) Paciente
Carlos São José Ana Samaritano Antonio Marta São Vicente Joana João Manoel

18 FNBC: Exemplo Atendimentos (Paciente, Hospital, Médico)
Dependências Funcionais: {Paciente, Hospital} -> {Médico} {Médico} -> {Hospital} Portanto, a relação Atendimentos está em 3 FN, mas não está em FNBC, pois não existe dependência transitiva em relação à chave, mas existe dependência para atributo que não é SuperChave!

19 FNBC: Exemplo Pode ocorrer uma anomalia de exclusão na relação Atendimentos se a tupla {Carlos, Samaritano, Antonio} for excluída, a informação de que Antonio atende no Samaritano será perdida. A solução consiste em desdobrar a relação em duas novas relações: Pacientes-Médicos (Paciente, Médico) Médicos-Hospitais (Médico, Hospital)

20 FNBC: Exemplo Porém, um novo problema surge com esta decomposição: a primeira dependência funcional {Paciente, Hospital} -> {Médico} foi perdida! Este tipo de anomalia não permite a decomposição de uma relação sem perda de informação. Neste caso, para que as relações estejam em FNBC e preservem, ao mesmo tempo, as dependências funcionais originais, a solução é permitir uma Redundância de Dados Controlada. Assim, as relações resultantes seriam: Atendimentos (Paciente, Hospital, Médico) Médicos-Hospitais (Médico, Hospital)