George Hamilton Slide Title Asterio K. Tanaka BANCO DE DADOS Dependências funcionais e Normalização de Bancos de Dados Relacionais (Material complementar.

Apresentação em tema: "George Hamilton Slide Title Asterio K. Tanaka BANCO DE DADOS Dependências funcionais e Normalização de Bancos de Dados Relacionais (Material complementar."— Transcrição da apresentação:

1 George Hamilton Slide Title Asterio K. Tanaka BANCO DE DADOS Dependências funcionais e Normalização de Bancos de Dados Relacionais (Material complementar aos Capítulos 14-15 de Elmasri-Navathe 2000) Asterio K. Tanaka http://www.uniriotec.br/~tanaka tanaka@rjnet.com.br Utilização por terceiros autorizada com citação da fonte.

2 George Hamilton Slide Title Asterio K. Tanaka Projeto de Bancos de Dados Requisitos de Dados Projeto Conceitual Projeto Lógico Projeto Físico Esquema Conceitual Esquema Físico Esquema Lógico Modelagem dos requisitos de dados através de diagramas de Entidades e Relacionamentos (DER) ou de Classes e Objetos (DCO) Mapeamento do esquema conceitual para o modelo de dados do SGBD escolhido, através de diagrama de estruturas de dados (DED) Mapeamento do esquema lógico para os tipos de dados e restrições de integridade do SGBD escolhido; criação de visões e índices.

3 George Hamilton Slide Title Asterio K. Tanaka Normalização Normalização de dados : processo de decomposição de esquemas para evitar anomalias de atualização (na inserção, exclusão, modificação de dados). Bom design evita redundância de dados e anomalias de atualização. Mecanismo formal para analisar esquemas de relações baseado nas suas chaves e nas dependências funcionais entre seus atributos. Antes da modelagem conceitual, normalização era um método de projeto de relações, a partir de uma RELAÇÃO UNIVERSAL. Uma modelagem conceitual bem feita resulta naturalmente em esquemas normalizados, portanto normalização é conseqüência, ou seja, um bom design é conseqüência de uma boa modelagem.

4 George Hamilton Slide Title Asterio K. Tanaka Redundância de Dados e Anomalias de Atualização CPFNome-FuncData-NascEndereçoNum-DeptNome-DeptGerente-Dept CPFNum-ProjHorasNome-FuncNome-ProjLocal-Proj Redundância nas tuplas: Num-Dept, Nome-Dept, Gerente-Dept são repetidos para todo funcionário que trabalha naquele departamento. Idem para Nome-Func, Nome-Proj, Local-Proj para cada funcionário alocado em determinado projeto. Anomalias de atualização: Inserção: incluir um novo funcionário implica em incluir dados de departamento our deixar nulos; como incluir um novo departamento, se CPF é chave primária Exclusão: ao excluir um funcinário que seja o único funcinário de um departamento, estaremos perdendo dados sobre o departamento Modificação: ao mudarmos um dado de um departamento (por exemplo, o gerente), todas as tuplas de funcionários daquele departamento terão que ser modificadas. FUNC-DEPT FUNC-PROJ

5 George Hamilton Slide Title Asterio K. Tanaka Projeto de BD por Normalização CPFNome EmpNum DeptNome DeptNum ProjNome ProjHoras CPFNome EmpNum Dept CPFNum ProjHoras Num DeptNome Dept Num ProjNome Proj Normalização Esquema com relações normalizadas relação universal (tabelão com todos os dados)

6 George Hamilton Slide Title Asterio K. Tanaka Primeira Forma Normal (1FN) É parte da definição formal de uma relação; foi definida para não permitir atributos multivalorados, atributos compostos e suas combinações. A 1FN garante a propriedade de fechamento da Álgebra Relacional. Uma relação está em 1FN se e somente se todos os seus atributos contêm apenas valores atômicos (simples, indivisíveis).

7 George Hamilton Slide Title Asterio K. Tanaka Nome Núm Gerente Data-Inicio DEPARTAMENTO Pesq Adm Sede 541541 333445555 987654321 888665555 22Mai88 01Jan92 19Jun91 Lins, Bauru, Santos Campinas Santos Localização Relação que não está em 1FN Num-Dept Localização LOCAL_DEPT 1455514555 Santos Campinas Lins Bauru Santos Nome Núm Gerente Data-Inicio DEPARTAMENTO Pesq Adm Sede 541541 333445555 987654321 888665555 22Mai88 01Jan92 19Jun91 Relações em 1FN sem redundância atributo multivalorado

8 George Hamilton Slide Title Asterio K. Tanaka CPF-Emp Num-Proj Horas TRABALHA_EM 123456789 666884444 453453453 333445555 999887777 987987987 987654321 888665555 1 2 3 1 2 3 10 20 30 10 30 20 32,5 7,5 40,0 20,0 10,0 30,0 10,0 35,0 5,0 20,0 15,0 nulo Relação em 1FN CPF-Emp Projetos Num-Proj Horas TRABALHA_EM 123456789 666884444 453453453 333445555 999887777 987987987 987654321 888665555 1 2 3 1 2 3 10 20 30 10 30 20 32,5 7,5 40,0 20,0 10,0 30,0 10,0 35,0 5,0 20,0 15,0 nulo Relação que não está em 1FN atributo composto

9 George Hamilton Slide Title Asterio K. Tanaka Dependência Funcional CPF Num-Proj Horas Nome-Emp Nome-Proj Local-Proj EMP-PROJ df1 df2 df3 df1 : {CPF, Num-Proj} {Horas} df2 : {CPF} {Nome-Emp} df3 : {Num-Proj} {Nome-Proj, Local-Proj} DF deve ser explicitamente definida por alguém que conheça a semântica dos atributos de uma relação. Não basta deduzir a DF pelas instâncias. X Y Os valores dos atributos do conjunto X determinam os valores dos atributos do conjunto Y ou, inversamente, os valores dos atributos do conjunto Y dependem funcionalmente dos valores dos atributos do conjunto X.

10 George Hamilton Slide Title Asterio K. Tanaka Regras de Inferência para Dependências Funcionais Regra reflexiva : Se X Y, então X Y. Regra de aumento : {X Y} XZ Y. Regra transitiva : {X Y, Y Z} X Z. Regra projetiva ou de decomposição : {X YZ} X Y. Regra aditiva ou de união : {X Y, X Z} X YZ. Regra pseudo-transitiva : {X Y, WY Z} WX Z.

11 George Hamilton Slide Title Asterio K. Tanaka Segunda Forma Normal (2FN) Uma relação está em 2FN se e somente se estiver em 1FN e todo atributo não-primo (isto é, que não seja membro de uma chave) for totalmente dependente de qualquer chave.

12 George Hamilton Slide Title Asterio K. Tanaka CPF Num-Proj Horas CPF Nome-Emp Num-Proj Nome-Proj Local-Proj df1 TRABALHA_EM EMPREGADO PROJETO df2 df3 Relações em 2FN CPF Num-Proj Horas Nome-Emp Nome-Proj Local-Proj EMP-PROJ df1 df2 df3 Relação em 1FN que não está em 2FN

13 George Hamilton Slide Title Asterio K. Tanaka Terceira Forma Normal (3FN) Uma relação está em 3FN se e somente se estiver em 2FN e nenhum atributo não-primo (isto é, que não seja membro de uma chave) for transitivamente dependente da chave primária. Em outras palavras, para toda df X A, uma das duas condições seguintes devem valer: X é uma superchave ou A é membro de uma chave candidata

14 George Hamilton Slide Title Asterio K. Tanaka CPF Nome-Emp Data-Nasc Endereço Num-Dept Nome-Dept Ger-Dept EMP-DEPT Relação em 2FN que não está em 3FN df1 df2 CPF Nome-Emp Data-Nasc Endereço Num-Dept df1 Num-Dept Nome-Dept Ger-Dept df2 EMPREGADO DEPARTAMENTO Relações em 3FN

15 George Hamilton Slide Title Asterio K. Tanaka Forma Normal de Boyce-Codd (FNBC) É uma forma mais restritiva de 3FN, isto é toda relação em FNBC está também em 3FN; entretanto, uma relação em 3FN não está necessariamente em FNBC. Uma relação está em FNBC se para toda DF X Z, X é uma super-chave.

16 George Hamilton Slide Title Asterio K. Tanaka AlunoDisciplinaProfessor df1 df2 AlunoDisciplinaProfessor Carlos QuímicaAna CarlosFísicaAntonio MartaQuímicaAna MartaPortuguêsMaria JoãoPortuguêsManoel Relação em 3FN que não está em FNBC Anomalia de exclusão : Se Carlos sair da aula de Física, não teremos nenhum registro de que Antonio leciona Física. AULA df2 : {Professor} Disciplina} {Professor} não é uma superchave.

17 George Hamilton Slide Title Asterio K. Tanaka Carlos Ana CarlosAntonio MartaAna MartaMaria JoãoManoel Relações em FNBC Note, entretanto, que a dependência funcional df1 : {Aluno, Disciplina} Professor foi perdida na decomposição. Considere, por exemplo, a inserção de (Marta, Manoel) em R1. AlunoProfessor Ana Química AntonioFísica MariaPortuguês ManoelPortuguês ProfessorDisciplina R1 R2

18 George Hamilton Slide Title Asterio K. Tanaka Conclusão: alguns esquemas não podem ser normalizados em FNBC e ao mesmo tempo preservar todas as dfs. Solução: redundância parcial. Decomposição/Junção sem Perda AlunoDisciplinaProfessor Carlos QuímicaAna CarlosFísicaAntonio MartaQuímicaAna MartaPortuguêsMaria JoãoPortuguêsManoel AULA Ana Química AntonioFísica MariaPortuguês ManoelPortuguês ProfessorDisciplina R2 Relações em FNBC, com redundância parcial e todas as dependências funcionais preservadas

19 George Hamilton Slide Title Asterio K. Tanaka Quarta Forma Normal Baseada em dependências multivaloradas (DMVs) Quarta forma normal (4FN) Uma relação R está em 4FN se e somente se estiver em FNBC e, caso exista alguma DMV X --->> Y, a DMV é trivial (i.e., Y X ou X Y = R) ou X é uma superchave de R.

20 George Hamilton Slide Title Asterio K. Tanaka Nome-Emp Nome-Proj Nome-Depend PradoXJoão PradoYAna PradoXAna PradoYJoão BorbaWJosé BorbaXJosé BorbaYJosé BorbaZJosé BorbaWJoana BorbaXJoana BorbaYJoana BorbaZJoana BorbaWBeto BorbaXBeto BorbaYBeto BorbaZBeto EMPREGADO Relação EMPREGADO não está em 4FN. 2 DMVs não triviais: Nome-Emp --->> Nome-Proj Nome-Emp --->> Nome-Depend Nome-Emp Nome-Proj Nome-Emp Nome-Depend PradoX PradoY BorbaW BorbaX BorbaY BorbaZ PradoJoão PradoAna BorbaJosé BorbaJoana BorbaBeto EMP-PROJ EMP-DEP As relações EMP- PROJ e EMP-DEP estão em 4FN

21 George Hamilton Slide Title Asterio K. Tanaka Outras Formas Normais Tipos adicionais de dependências. dependências de junção e de inclusão, que levam a formas normais mais restritas (Quinta Forma Normal, Forma Normal de Domínio-Chave). A utilidade prática destas formas normais é limitada, porque num banco de dados real com muitos atributos, é muito difícil (e praticamente irrelevante) descobrir tais dependências e restrições.

22 George Hamilton Slide Title Asterio K. Tanaka Normalização como Ferramenta para Validação da Qualidade de um Esquema As formas normais até FNBC são baseadas em dependências funcionais, exceto a 1FN, que faz parte da definição do modelo relacional. O design conceitual baseado nos modelos ER ou OO tende naturalmente a produzir esquemas normalizados, a menos da 1FN. A separação de conceitos é o resultado natural do design conceitual bem feito. Na prática, esquemas que violam a normalização são exemplos de esquemas mal projetados.

23 George Hamilton Slide Title Asterio K. Tanaka Dicas (Guidelines) para projeto de Relações 1.Projete um esquema de relação de forma que seja fácil explicar seu significado. Não combine atributos de múltiplos tipos de entidades e relacionamentos numa única relação. 2.Projete os esquemas de relações de modo que anomalias de inserção, exclusão ou de modificação não sejam possíveis. Caso nào seja possível evitá-las, assegure-se que os programas que ataulizam o banco de dados vão funcionar corretamente. 3.Tanto quanto possível, evita colocar atributos numa relação cujos valores possam ser frequentemente nulos. 4.Projete esquemas de relações de modo que elas possam ser juntadas com condições de junção de igualdade sobre atributos que sejam chaves primárias ou chaves estrangeiras, de uma forma que tuplas espúrias não sejam geradas.

24 George Hamilton Slide Title Asterio K. Tanaka Problemas de Valores Nulos em Tuplas Relações com muitos atributos tendem a produzir muitos valores nulos, desperdiçando espaço. Outro problema: como levar em conta os nulos em operações agregadas como COUNT e SUM? Qual a interpretação de cada nulo? –O atributo não se aplica a essa tupla. –O valor do atributo para essa tupla é desconhecido. –O valor é conhecido mas ausente, isto é, ainda não foi inserido. Um exemplo: se apenas 10% dos funcionários possuem um número de sala na empresa, este atributo não deveria estar na relação base (Funcionários), mas numa relação auxiliar Funcionarios_Salas, que teriam apenas os atributos Matrícula e Numero da Sala.

25 George Hamilton Slide Title Asterio K. Tanaka Geração de Tuplas Espúrias