1) O documento discute modelagem relacional de dados e normalização para evitar anomalias. 2) A normalização divide tabelas com múltiplos assuntos em tabelas separadas com um único assunto cada. 3) Isso minimiza redundâncias, inconsistências e facilita manutenção do banco de dados.

1. Modelagem Relacional e Normalização de Dados Juliana Alvares

2. Modelagem Relacional O Modelo de Dados Relacional representa os dados em um BD através de um conjunto de Relações (tabelas). Estas relações contêm informações sobre entidades ou relacionamentos existentes no domínio da aplicação utilizada como alvo para a modelagem. Informalmente uma relação pode ser considerada como uma tabela de valores, onde cada linha desta tabela representa uma coleção de valores de dados inter relacionados Estes conjuntos de valores podem estar representando uma instância de uma entidade ou relacionamento da aplicação.

3. Modelagem Relacional Os nomes fornecidos às tabelas e às suas colunas podem auxiliar na compreensão do significado dos valores armazenados em cada uma das suas linhas. Em terminologia do Modelo Relacional, cada linha da relação é denominada de Tupla , o nome da coluna é denominado Atributo da relação. É importante assinalar que não se podem ter tuplas duplicadas em uma tabela.

4. FCODIGO FNOME FCATEGORIA FCIDADE F1 Santos 20 Piracicaba F2 Machado 10 São Paulo F3 Almeida 30 São Paulo F4 Ferreira 20 Campinas F5 Rodrigues 30 São Carlos O Domínio consiste de um grupo de valores atômicos a partir dos quais um ou mais atributos (ou colunas) retiram seus valores reais. Como por exemplo o domínio do atributo FCIDADE consiste no conjunto de todos os nomes legais de cidades. Modelagem Relacional

5. Modelagem Relacional O Esquema de uma Relação consiste de um conjunto de atributos que descrevem as características dos elementos a ser modelados. É denotado por R(A1, A2, ...., An), onde cada atributo Ai toma seus valores a partir de um domínio Di; e R é o nome da relação. O número de atributos na relação n, consiste no grau da relação. Os domínios a partir dos quais os atributos da relação retiram seus valores não precisam ser necessariamente distintos. Como exemplo o esquema da relação apresentada na figura anterior é dado por: Fornecedor (FCodigo, FNome, FCategoria, FCidade)

6. Modelagem Relacional Como Esquema de um BD Relacional entende-se o conjunto de intenções (Esquemas das Relações) definidas para todas as relações da Base, e um conjunto de restrições de integridade. Sobre os nomes fornecidos aos atributos, é permitido àqueles que representem conceitos semelhantes, possuir ou não o mesmo nome em diferentes relações. Da mesma forma, atributos representando conceitos diferentes podem possuir o mesmo nome. O conjunto de restrições de integridade define regras básicas que os valores dos atributos devem obedecer quando aparecerem em uma relação.

7. Modelagem Relacional A Instância de uma Relação consiste no conjunto de valores que cada atributo, definido no esquema, assume em um determinado instante, formando o conjunto de tuplas. Ou seja, as instâncias das relações formam os dados que são armazenados no BD. As relações apresentam as seguintes características: a) Não há tuplas duplicadas em uma relação; b) Ordem das tuplas na relação não é relevante para diferenciar as relações; c) Os valores dos atributos devem ser atômicos, não sendo divisíveis em componentes.

8. Modelagem Relacional Chave é um conjunto de atributos de uma relação e que pode ser utilizado para a realização de qualquer operação que envolva atributos e valores de atributos.

9. Modelagem Relacional Uma relação pode ter várias chaves para identificação unívoca de suas tuplas, onde cada uma é denominada de Chave Candidata . Entre as chaves candidatas é escolhida uma pelo DBA (durante a fase de projeto lógico) para ser suportada pelo SGBD e assim, é mantido automaticamente a restrição de unicidade. Esta chave escolhida é denominada de Chave Primária . Desta forma, uma relação nunca apresentará tuplas repetidas em sua instância, o que significa a possibilidade de identificação de cada tupla separadamente uma da outra.

10. Modelagem Relacional Da relação apresentada para fornecedores, o conjunto {FCODIGO} é a chave primária da relação, uma vez que dois fornecedores não apresentarão o mesmo código.

11. Modelagem Relacional Um conjunto de atributos Fk em um esquema da relação R1 é uma Chave Estrangeira de R1 se os atributos em Fk possuem o mesmo domínio que os atributos da chave primária de uma relação R2 e os valores de Fk em uma tupla de R1 devem ser os mesmos que ocorrem em tuplas de R2 ou serem nulos, e neste caso é dito que os atributos da Fk se referenciam à relação R2.

12. Modelagem Relacional Para exemplificar o conceito de chave estrangeira, considere as relações abaixo sobre Peças e Fornecedores, e das peças fornecidas por cada fornecedor (as chaves de cada relação se encontram grifadas): FORNECEDOR(FCODIGO, FNOME, FCATEGORIA, FCIDADE); PEÇA (PCODIGO, PNOME, PCOR, PESO, PCIDADE); FP (FPCODIGO, FCODIGO , PCODIGO , QTDE);

13. Modelagem Relacional Entre as relações anteriores, pode-se observar que FCODIGO e PCODIGO quando aparecem na relação FP são chaves estrangeiras desta relação pois são chaves primárias das relações FORNECEDOR e PEÇA, respectivamente.

14. Normalização de Dados Normalização de dados é o processo formal passo a passo que examina os atributos de uma entidade, com o objetivo de evitar anomalias observadas na inclusão, exclusão e alteração de registros.

16. Normalização de Dados Uma regra de ouro que devemos observar quando do projeto de um Banco de Dados baseado no Modelo Relacional de Dados é a de "não misturar assuntos em uma mesma Tabela". Por exemplo: na Tabela Clientes devemos colocar somente campos relacionados com o assunto Clientes. Não devemos misturar campos relacionados com outros assuntos, tais como Pedidos, Produtos, etc. Essa "Mistura de Assuntos" em uma mesma tabela acaba por gerar repetição desnecessária dos dados bem como inconsistência dos dados.

17. Normalização de Dados Normalmente após a aplicação das regras de normalização de dados, algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que no final gera um número maior de tabelas do que o originalmente existente. Este processo causa a simplificação dos atributos de uma tabela, colaborando significativamente para a estabilidade do modelo de dados, reduzindo-se consideravelmente as necessidades de manutenção.

19. Facilidade de manipulações do banco de dados;

20. Facilidade de manutenção do sistema de Informação.

21. Normalização de Dados O Processo de normalização aplica uma série de regras sobre as tabelas de um banco de dados, para verificar se estas estão corretamente projetadas. Embora existam cinco formas normais (ou regras de normalização), na prática usamos um conjunto de três Formas Normais. Vejamos as três primeiras formas normais do processo de normalização de dados.

22. Normalização de Dados Primeira Forma Normal 1FN Uma relação estará na Primeira forma normal 1FN, se e somente se todos os domínios básicos contiverem somente valores atômicos (não contiver grupos repetitivos). Em outras palavras podemos definir que a primeira forma normal não admite repetições ou campos que tenha mais que um valor.

23. Normalização de Dados Procedimentos: a) Identificar a chave primária da entidade; b) Identificar o grupo repetitivo e removê-lo da entidade; c) Criar uma nova entidade com a chave primária da entidade anterior e o grupo repetitivo.

24. Normalização de Dados Exemplo da primeira forma normal Considere a tabela cliente abaixo: Cliente Código_cliente Nome * Telefone Endereço

25. Normalização de Dados Agora a tabela com os dados: Tabela desnormalizada, ou seja, não está na 1ª forma normal Analisando teremos:

26. Normalização de Dados Todos os clientes possuem Rua, CEP e Bairro, e essas informações estão na mesma célula da tabela, logo ela não está na primeira forma normal. Para normalizar, deveremos colocar cada informação em uma coluna diferente, como no exemplo a seguir: Tabela ainda não está na primeira forma normal

27. Normalização de Dados Mesmo com o ajuste acima, a tabela ainda não está na primeira forma normal, pois há clientes com mais de um telefone e os valores estão em uma mesma célula. Para normalizar será necessário criar uma nova tabela para armazenar os números dos telefones e o campo-chave da tabela cliente. Veja o resultado a seguir:

28. Normalização de Dados Tabela na 1ª forma normal Tabela na 1ª forma normal

29. Normalização de Dados Nesse exemplo, foi gerado uma segunda entidade para que a primeira forma normal fosse satisfeita, contudo é possível manter a tabela original, admitindo-se valores duplos em uma mesma coluna, como exemplo o campo telefone ficaria assim: 11-3400-3563 e 19-3500-9650. Neste caso a tabela ficaria desnormalizada, mas muitos acabam preferindo assim, principalmente quando há poucos casos de repetição.

30. Normalização de Dados Segunda Forma Normal 2FN Uma tabela está na Segunda Forma Normal 2FN se ela estiver na 1FN e todos os atributos não chave forem totalmente dependentes da chave primária (dependente de toda a chave e não apenas de parte dela).

31. Normalização de Dados Procedimentos: a) Identificar os atributos que não são funcionalmente dependentes de toda a chave primária; b) Remover da entidade todos esses atributos identificados e criar uma nova entidade com eles. A chave primária da nova entidade será o atributo do qual os atributos do qual os atributos removidos são funcionalmente dependentes .

32. Normalização de Dados Exemplo de segunda forma normal Considere a tabela vendas abaixo: Vendas N_pedido Código_produto Produto Quant Valor_unit Subtotal

33. Normalização de Dados Agora a tabela com os dados: Tabela não está na segunda forma normal Analisando teremos:

34. Normalização de Dados O nome do produto depende do código do produto, porém não depende de N_pedido que é a chave primária da tabela, portanto não está na segunda forma normal. Isto gera problemas com a manutenção dos dados, pois se houver alteração no nome do produto teremos que alterar em todos os registros da tabela venda. Para normalizar esta tabela teremos de criar a tabela Produto que ficará com os atributos Código_produto e produto e na tabela Venda manteremos somente os atributos N_pedido, código_produto, quant, valor_unit e subtotal. Veja o resultado:

35. Normalização de Dados Tabela na 2ª forma normal Tabela na 2ª forma normal

36. Normalização de Dados Terceira Forma Normal 3FN Uma tabela está na Terceira Forma Normal 3FN se ela estiver na 2FN e se nenhuma coluna não-chave depender de outra coluna não-chave. Na terceira forma normal temos de eliminar aqueles campos que podem ser obtidos pela equação de outros campos da mesma tabela.

37. Normalização de Dados Procedimentos: a) Identificar todos os atributos que são funcionalmente dependentes de outros atributos não chave; b) Removê-los. A chave primária da nova entidade será o atributo do qual os atributos removidos são funcionalmente dependentes.

38. Normalização de Dados Exemplo da terceira forma normal Considere a tabela abaixo: Tabela não está na terceira forma normal

39. Normalização de Dados Considerando ainda a nossa tabela Venda, veremos que a mesma não está na terceira forma normal, pois o subtotal é o resultado da multiplicação Quant X Valor_unit, desta forma a coluna subtotal depende de outras colunas não-chave. Para normalizar esta tabela na terceira forma normal teremos de eliminar a coluna subtotal, como no exemplo a seguir:

40. Normalização de Dados Tabela na terceira forma normal