Normalização. Prof. Rogério Gonçalves Bittencourt, M.Sc.

Transcrição

1 Normalização Prof. Rogério Gonçalves Bittencourt, M.Sc.

2 Introdução Processo sistemático e matemático através do qual uma tabela relacional não normalizada é transformada em um conjunto de tabelas normalizadas Introduzido por Dr. E. F. Codd, em 1970 (1 a Forma Normal) Técnica para a retirada de anomalias do modelo relacional O processo de normalização baseia-se no conceito de Forma Normal, que é uma regra que deve ser obedecida por uma tabela para que esta seja considerada bem projetada. Existem diversas regras (1FN, 2FN, 3FN, FNBC, 4FN e 5FN)

3 Vem das características de um mau projeto de banco de dados Motivação Repetição de informações Inabilidade de representar certas informações Perda de informação Anomalias!!!! MAU PROJETO DE BD!!! PACIENTES (ID, NOME, END, TEL, SEXO, DT_NASC, SIGLA_CONV, NM_CONVENIO, END_CONV, TEL_CONV)

4 Anomalia de Inserção Anomalias Quando se inserir um paciente, é preciso inserir também os dados do convênio, mesmo que já estejam cadastrados; Não é possível inserir um convênio sem inserir também um convênio. MAU PROJETO DE BD!!! PACIENTES (ID, NOME, END, TEL, SEXO, DT_NASC, SIGLA_CONV, NM_CONVENIO, END_CONV, TEL_CONV)

5 Anomalia de Exclusão Anomalias Ao se excluir um paciente, se este for o único associado de um convênio, então os dados do convênio serão perdidos MAU PROJETO DE BD!!! PACIENTES (ID, NOME, END, TEL, SEXO, DT_NASC, SIGLA_CONV, NM_CONVENIO, END_CONV, TEL_CONV)

6 Anomalia de Alteração Anomalias Para se modificar os dados de um convênio, é preciso atualizar os mesmos dados em todas as tuplas de pacientes que estejam associados àquele convênio. MAU PROJETO DE BD!!! PACIENTES (ID, NOME, END, TEL, SEXO, DT_NASC, SIGLA_CONV, NM_CONVENIO, END_CONV, TEL_CONV)

7 Redundância O termo redundância vem do latin redundantia que na Língua Portuguesa é definido como algo em excesso e em desperdício. Em uma tabela relacional, redundância significa informação desnecessária ou em excesso.

8 Exemplo Muitas de suas informações estão sendo repetidas. Por exemplo: Nome do estudante, endereço, nome do curso, nome do instrutor e sala. Matric Nome Endereço Disciplina Descrição Instrutor Sala Filipe Av. das flores, 25 CP302 Banco de Dados Cirano Filipe Av. das flores, 25 CP303 Comunicações Netto Filipe Av. das flores, 25 CP304 Eng. Software Ana Price Lucinéia Av. das plantas, 35 CP302 Banco de Dados Cirano 1024

9 Exemplo Inserção - considerando-se que a chave primária da tabela curso seja Matric e Disciplina, e que a chave primária não pode conter valores nulos, para inserção de uma disciplina seria necessário incluir também os dados referentes ao aluno e vice-versa; Atualização - caso tenha que ser atualizado o endereço do aluno 'Filipe', todas as ocorrências do aluno 'Filipe' terão que ser atualizadas também, existindo assim uma maior perda de tempo, um maior 'custo' para efetuar a transação e também a possibilidade de inconsistência; Exclusão - podem ser perdidos dados importantes. No caso de ser deletado o aluno 'Filipe' da tupla que contém a disciplina 'CP303' todas as informações referentes a disciplina serão perdidas também.

10 Processo de Normalização Esquema na 5FN Esquema Relacional Normalizado Esquema na 4FN Passagem à 5FN Passagem à 4FN Esquema na 3FN Passagem à 3FN Passagem à FNBC Esquema na 2FN Esquema de Arquivo ou Documento Representaçã o como tabela ÑN Esquema não normalizado Passagem à 2FN Esquema na 1FN Passagem à 1FN

11 Dependências Funcionais Um conceito básico usado para normalizar relações Teoria de Conjuntos Dependências Funcionais (DF s) são restrições de integridade mais gerais que as restrições de chave Dada uma relação (FORNECEDOR, por exemplo), um conjunto de atributos Y (por exemplo NOMEF) é dito funcionalmente dependente de um outro conjunto de atributos X (por exemplo CODF) se, e somente se, cada ocorrência de valores de X está associada sempre com a mesma ocorrência de valores de Y.

12 Dependências Funcionais PACIENTES (ID, NOME, END, TEL, SEXO, DT_NASC, SIGLA_CONV, NM_CONVENIO, END_CONV, TEL_CONV) {SIGLA_CONV} {NM_CONV, END_CONV, TEL_CONV} Leia-se: SIGLA_CONV determina funcionalmente NM_CONV, END_CONV e TEL_CONV Significa: Se duas linhas da tabela PACIENTES tiverem o mesmo valor de SIGLA_CONV, então elas possuem o mesmo valor de NM_CONV, END_CONV e TEL_CONV Em outras palavras: Não é valida uma tabela que tenha duas linhas que coincidem na(s) coluna(s) listadas antes da seta ( ),( mas são diferentes em alguma coluna listada depois da seta

13 Dependências Funcionais Como toda restrição de integridade, DF s são baseadas na semântica da aplicação. Podemos checar uma instância de tabela e ver se uma DF é violada ou não. Mas examinando uma instância NUNCA podemos concluir se uma DF deve ser imposta ou não; Uma DF diz respeito a todas as possíveis instâncias! Uma restrição de chave é um caso especial de DF A chave (ou superchave) determina funcionalmente todos os outros atributos da tabela Como ID é chave da tabela PACIENTES, temos que: {ID} {NOME, END, TEL, SEXO, DT_NASC, SIGLA_CONV, NM_CONV, END_CONV, TEL_CONV}

14 Regras de Inferência Dadas algumas DF s, podemos geralmente inferir outras DF s Dadas as DF s {ID} {SIGLA_CONV} {SIGLA_CONV} {END_CONV} Podemos inferir que {ID} {END_CONV}

15 Regras de Inferência Axiomas de Armstrong Reflexiva Incremento Transitiva União ou Aditiva Decomposição ou Projetiva Pseudotransitividade Se Y X X Y Se X Y XZ YZ Se X Y Y Z X Z Se X Y X Z X YZ Se X YZ X Y X Z Se X Y WY Z WX Z

16 Fechamento de um Conjunto de DF s Representamos por F o conjunto de DF s de uma relação. O Fechamento (F + ) de um conjunto de DF s F é o conjunto de todas as DF s que podem ser inferidas a partir de F. Não é preciso listar todas as DF s impostas sobre um esquema. Normalmente especificamos um subconjunto dessas DF s e consideramos o fechamento desse subconjunto

17 Dependência Funcional Total A seguinte DF X Y é dita DF Total se a remoção de qualquer atributo A de X significar que a dependência não mais se mantém. A X, (X {A}) Y

18 Dependência Funcional Parcial A seguinte DF X Y é dita DF Parcial se algum atributo A X puder ser removido de X e a dependência ainda se mantiver. A X, (X {A}) Y

19 Normalização Número do Pedido: Prazo de Entrega: dias Código do Vendedor: Nome do Vendedor: Cliente: Endereço: Cidade: CGC: Inscrição Estadu Cod. Produto UnidadesDescrição Quantidade Valor Unitário Total do Prod Total do Pedido Pedido (Num_Pedido,, Prazo, Cliente, Endereço, Cidade, UF, Insc_Est, (Cod_Prod, Unid, Qtde, Descr, Val_Unit, Total_Prod), Total_Pedido, Cod_Vendedor, Nome_Vendedor)

20 Primeira Forma Normal 1FN A 1FN trata de informações que se repetem (atributos multi-valorados) e define que cada ocorrência da chave primária deve corresponder a uma e somente uma informação de cada atributo, ou seja, a entidade não deve conter grupos repetitivos. Para um esquema com relações não normalizadas (como a relação Pedido acima), a solução é decompor cada relação não normalizada em tantas entidades quanto for o número de grupos repetitivos. A B E F C D CONVERTER PARA A B E A C D F

21 Primeira Forma Normal 1FN Aplicando 1FN na relação PEDIDO, observa-se que existe um grupo repetitivo dentro da relação, que trata dos vários produtos que podem constar num pedido. Isto se deve ao fato de que este grupo forma uma coluna não atômica. Este grupo é composto dos atributos Cod_Prod, Unid, Qtde, Descr, Val_Unit. Portanto, cria-se uma nova relação, a ser chamada de ITEM_PEDIDO,, ficando o esquema da seguinte forma:

22 Primeira Forma Normal 1FN Num_Pedido PrazoClienteEndereçoCidadeUF Insc_Est Total_Pedido Cod_Vendedor Nome_Ven Cod_ProdUnid Cod_ProdUnid QtdeDescrVal_Unit QtdeDescrVal_Unit Total_Prod CONVERTER PARA Num_Pedido PrazoClienteEndereçoCidadeUF Insc_Est Total_Pedido Cod_Vendedor Nome_Vendedor Num_Pedido PrazoCliente Cod_ProdUnid QtdeDescrVal_Unit Total_Prod

23 Dependência Funcional Exemplo Dada uma relação qualquer, dizemos que um atributo ou conjunto de atributos A é dependente funcional de um outro atributo B contido na mesma entidade, se a cada valor de B existir nas linhas da relação em que aparece, um único valor de A. A depende funcionalmente de B. (B A) B é determinante de A. (B A) Exemplo: Prazo de entrega depende funcionalmente do número do pedido: Num_Pedido Prazo Nome do vendedor depende funcionalmente do código do vendedor: Cod_Vendedor Nome_Vendedor

24 Segunda Forma Normal DF Parcial e Total Dependência Funcional Total Um atributo ou conjunto de atributos depende de forma total da chave primária concatenada se a cada valor da chave (toda) está associado a um único valor para este atributo. Dependência Funcional Parcial O atributo só depende de parte da chave primária. A B C D CONVERTER PARA A B CE A D

25 Segunda Forma Normal 2FN Uma relação está em 2FN se estiver em 1FN e não tiver atributos com dependência parcial em relação à chave primária. Para uma relação na 1FN, observar se ela possui chave primária concatenada. Se possuir, verificar se existe atributo (fora da chave) que dependa parcialmente da chave, ou seja, que não dependa da chave toda. Se sim, decompor a relação para que não existam dependências parciais.

26 Segunda Forma Normal 2FN ITEM_PEDIDO ( Num_Pedido, Cod_Prod,, Un id, Qtde, Descr, Val_Unit, Total_Prod ) O atributo Qtde depende de forma total da chave primária (Num_Pedido + Cod_Prod) O atributo Descr (descrição do produto) depende de forma parcial da chave primária pois só depende do Cod_Prod e não do Num_Pedido + Cod_Prod. Observação: Dependência funcional total e parcial só ocorre quando a chave primária for composta de vários atributos (concatenada).

27 Segunda Forma Normal Exemplo: (a única relação no nosso esquema com chave concatenada) 2FN ITEM_PEDIDO ( Num_Pedido, Cod_Prod,, Unid, Qtde, Descr, Val_Unit, Total_Prod ) Os atributos Unid, Descr, Val_Unit dependem de Cod_Prod o qual faz parte da chave primária. Cria-se a relação PRODUTO (Cod_Prod( Cod_Prod, Unid, Descr, Val_Unit),, com a chave primária Cod_Prod e em ITEM_PEDIDO,, a chave primária permanece Num_Pedido + Cod_Prod.

28 Segunda Forma Normal 2FN Num_Pedido Prazo Cod_Prod Cliente Unid Qtde Descr Val_Unit Total_Prod CONVERTER PARA Num_Pedido Cod_Prod Qtde Total_Prod Cod_Prod Unid Descr Val_Unit

29 Terceira Forma Normal DF Transitiva Quando um atributo ou conjunto de atributos A depende de outro atributo B que não pertence à chave primária,, mas é dependente funcional desta, dizemos que A é dependente transitivo de B. A B C CONVERTER PARA A AB B DC

30 Terceira Forma Normal 3FN Uma relação está na 3FN se está em 2FN e se nenhum de seus atributos possui dependência transitiva em relação a outro atributo que não esteja na chave primária. Ao retirar a dependência transitiva, criamos novas relações com os atributos que dependem transitivamente do outro e a sua chave primária é o atributo que causou essa dependência. Uma relação na 3FN, além de não ter dependência transitiva, não pode ter atributos que sejam resultado de algum cálculo sobre outro atributo, o que, de certa forma, pode ser encarado como dependência funcional.

31 Terceira Forma Normal 3FN PEDIDO ( Num_Pedido,, Prazo, Cliente, Endereço, Cidade, UF, Insc_Est, Total_Pedido, Cod_Vendedor, Nome_Vendedor ) Os atributos Endereço, Cidade, UF, CGC e Insc_Est são dependentes transitivos do atributo Cliente. Nome_Vendedor é dependente transitivo de Cod_Vendedor

32 Terceira Forma Normal 3FN Num_Pedido Prazo Cliente Endereço Cidade UF Insc_Est Total_PedidoCod_VendedorNome_Vendedo CONVERTER PARA Num_Pedido Prazo Cod_Cli Total_PedidoCod_Vendedor Cod_VendedorNome_Vendedor Cod_Cli Nome Endereço Cidade UF Insc_Est

33 Terceira Forma Normal PEDIDO ( Num_Pedido,, Prazo, Cliente, Endereço, Cidade, UF, Insc_Est, Total_Pedido, Cod_Vendedor, Nome_Vendedor ) 3FN O atributo nome vendedor depende transitivamente de Cod_Vendedor, o qual não pertence à chave primária, mas depende desta. Cria-se a relação VENDEDOR (Cod_Vendedor( Cod_Vendedor, Nome_Vendedor) Os atributos Endereço, Cidade, UF, CGC e Insc_Est dependem transitivamente de Cliente que não está na chave primária (mas depende desta). Cria-se a relação CLIENTE (Cliente, Nome, Endereço, Cidade, UF, CGC, Insc_Est).

34 Quarta Forma Normal DF Multivalorada Dependência Funcional Multivalorada Dada uma relação qualquer com três atributos A, B e C.. Diz-se que B depende de forma multivalorada de A se, e somente se, sempre que existirem duas tuplas (A 1, B 1, C 1 ) e (A 1, B 2, C 2 ) existirão também duas tuplas (A 1, B 1, C 2 ) e (A 1, B 2, C 1 ). Isso quer dizer que A,, na verdade, relaciona-se com B e com C de forma independente.

35 Quarta Forma Normal DF Multivalorada

36 Quarta Forma Normal DF Multivalorada CodPesq CodAl Sala CodPesq CodAl MA MA MA MA MA MA MA INF MA001 MA001 INF003 INF CodPesq MA001 MA001 INF003 Sala

37 Quarta Forma Normal 4FN Uma relação está na 4FN se está na 3FN e se não existirem dependências multivaloradas. AutAssLiv ( (CodLivro, CodAutor, CodAssunto) CodLivro CodAutor AU1 AU1 AU2 AU2 CodAssunto AS1 AS2 AS1 AS2 Há redundâncias para representar todas as combinações AU1 AU1 AU1 AU3 AS3 AS4 AS1 AS3 2 AU3 AS4 2 AU3 AS1 2 AU3 AS2

38

39

40 Quinta Forma Normal Dependência de Junção Dependência de Junção Dada uma relação R qualquer com três atributos A, B e C,, compondo uma chave primária composta (típica em relacionamentos n- ários). Diz-se que a relação R satisfaz à DJ se, e somente se, todo o valor válido possível de R é igual à junção de suas projeções sobre A, B, e C. Isso quer dizer que o conteúdo de R pode ser reconstruído a partir da junção de tabelas menores (projeções).

41 Quinta Forma Normal Uma relação está na 5FN se está na 4FN e se o seu conteúdo não puder ser reconstruído a partir de tabelas menores. 5FN... Se o resultado de junções de projeções de R for diferente de R.

42 Quinta Forma Normal 5FN

43 Relação (R) Quinta Forma Normal 5FN Agente João João João João Carlos Companhia Ford Ford GM GM Ford Produto Carro Caminhão Carro Caminhão Carro π (agente, companhia) (R) Agente Companhia João Ford João GM Carlos Ford π (agente, produto) (R) Agente Produto João Carro João Caminhão Carlos Carro π (companhia, produto) (R) Companhia Produto Ford Carro Ford Caminhão GM Carro GM Caminhão

44 Quinta Forma Normal 5FN