Normalização Disciplina: Banco de dados II.

Apresentação em tema: "Normalização Disciplina: Banco de dados II."— Transcrição da apresentação:

1 Normalização Disciplina: Banco de dados II

2 Normalização Normalização de banco de dados
Segundo Heuser (2001), uma forma normal (FN) é uma regra que deve ser obedecida por uma tabela para que ela seja considerada “bem projetada”. Existem inúmeras formas normais, ou seja, diversas regras, cada vez mais rígidas, para verificar tabelas em banco de dados relacionais. No entanto, pelo menos 3 FNs são consideradas essenciais para a construção de um bom projeto de banco de dados.

3 Projetando um Banco de Dados
Determinar qual o objetivo do banco de dados: Isto ajuda na determinação de quais os dados devem ser armazenados. É fundamental ter bem claro qual o objetivo a ser alcançado com o banco de dados. É fazer o acompanhamento das despesas, a evolução das vendas ou outro objetivo qualquer.

4 Projetando um Banco de Dados
Determinar as tabelas necessárias: Após definirmos os objetivos do Banco de Dados, as informações devem ser definidas e separadas em assuntos diferentes, tais como "Clientes", "Empregados", "Pedidos", pois cada um irá compor uma tabela no banco de dados. Lembre-se da regrinha número um: "Não misturar assuntos na mesma tabela", ou seja, uma coisa é uma coisa e outra coisa é outra coisa.

5 Projetando um Banco de Dados
Determinar os Campos de cada Tabela: Definir quais informações devem ser mantidas em cada tabela. Por exemplo, a tabela Clientes poderia ter um campo para o Código Do Cliente, outro para o Nome Do Cliente e assim por diante.

6 Projetando um Banco de Dados
Determinar a Chave Primária de cada tabela, sendo que pode haver tabelas onde não exista uma chave primária: Determinar, em cada tabela, quais campos serão utilizados como Chave Primária. Esta é uma etapa importantíssima para a definição dos Relacionamentos que vem a seguir. Pode haver tabelas onde não exista uma chave primária.

7 Projetando um Banco de Dados
Determinar os Relacionamentos: Decidir como os dados de uma tabela se relacionam com os dados de outras tabelas. Por exemplo, Clientes podem Fazer Vários Pedidos, então existe um relacionamento do tipo Um-para-vários entre a tabela Clientes (lado um) e a tabela Pedidos (lado vários). Fornecedores podem fornecer Vários Produtos, etc.

8 Projetando um Banco de Dados
Refinar a Estrutura do Banco de Dados: Antes de inserir muitos dados, ou até mesmo antes de inserir qualquer dado, verificar se a estrutura contém erros, isto é, verificar se os resultados obtidos são os desejados. Isto, normalmente, pode ser obtido através do processo de Normalização. Caso necessário, deve-se alterar a estrutura do banco de dados.

9 Dicas para determinação dos campos de uma Tabela:
Relacionar diretamente cada campo ao assunto da tabela: Se um campo descreve o assunto de uma tabela diferente, este campo deve pertencer a outra tabela. O mesmo acontece quando uma informação se repete em diversas tabelas. Este é um indício de que existem campos desnecessários em algumas tabelas.

10 Dicas para determinação dos campos de uma Tabela:
Não Incluir dados Derivados ou Calculados: Não é recomendado armazenar o resultado de cálculos nas tabelas. O correto é que o cálculo seja executado quando necessitarmos do resultado, normalmente em uma consulta.

11 Dicas para determinação dos campos de uma Tabela:
Incluir todas as informações necessárias: Como é fácil esquecer informações importantes, deve-se ter em mente todas as informações coletadas desde o início do processo e perguntar se com elas é possível obter todas os resultados desejados.

12 Dicas para determinação dos campos de uma Tabela:
Armazenar todas as informações separadamente: Existe uma tendência em armazenar informações em um único campo. Por exemplo, o nome do curso e o tempo de duração em uma mesmo campo. Como as duas informações foram combinadas em um único campo, ficará difícil conseguir um relatório classificado pelo tempo de duração dos cursos.

13 MER(Modelo de Entidade Relacional)

14 DER(Diagrama de Entidade Relacional)

15 Estudo de caso Maria é cabelereira, ela tem uma planilha com o nome dos clientes(CPF,NOME,TELEFONES,ENDEREÇO) e outra planilha com os serviços executados pelo cliente(CPF, NOME, SERVIÇO, PREÇO) e outra tabela com serviços e seus preços? Como ficaria?

16 1FN (Primeira Forma Normal)
Todos os atributos estão definidos em domínios que contêm valores atómicos. Não há conjuntos de atributos repetidos para um determinado género de característica

17 1FN (Primeira Forma Normal)
Converter atributos não atómicos em atributos atómicos, por forma a que não se possa incluir mais que um valor em cada campo de uma tabela. Eliminar os atributos repetidos, considerando-os elementos de uma nova tabela.

18 2FN (Segunda Forma Normal)
A tabela já se encontra na 1ª FN. Todos os atributos não-chave são funcionalmente dependentes da chave na sua totalidade e não apenas de parte da chave

19 2FN (Segunda Forma Normal)
Identificar a chave de uma entidade: Se a chave só tem um atributo e a tabela está na 1ª FN, também está na 2ª FN. Se a chave é composta, analisam-se as dependências dos atributos; se algum ou alguns atributos dependem de uma parte da chave, a tabela deverá ser decomposta, por forma a que cada atributo dependa apenas da totalidade da chave.

20 3FN (Terceira Forma Normal)
A tabela já se encontra na 2ª FN. Nenhum atributo não-chave depende funcionalmente de nenhum outro atributo não- chave.

21 3FN (Terceira Forma Normal)
Analisar todos os atributos não-chave e procurar dependências funcionais; se existir algum conjunto de atributos que tenha uma dependência funcional em relação a um outro atributo, então decompõe-se a tabela até que não haja dependência funcional entre os atributos não-chave; só podem existir dependências funcionais entre atributos não-chave e a chave.

22 Termos Atributos atómicos – são atributos os quais não é possível decompor em unidades mais elementares. (Ex: idade, altura) Atributos compostos – são atributos que, embora possam ser tratados em conjunto, podem facilmente ser subdivididos em partes. (Ex: nome = nome_proprio + nome_apelido).

23 EXERCÍCIO DE EXEMPLO Matérias Informática Fictício PEDIDO
Rua Afonso Principal ,50 – Aquidauana CNPJ: / Pedido nº :    5 Data: 24/02/2014 Cliente: Diego Endereço: Rua Afonso pena nº 305 Cidade: Campo Grande-MS Código Cliente: 548 Código Descrição Qtd Preço Total 1 Notebook R$ 1.000,00 22 Pen-drive 4GB 4 R$ 20,00 R$ 80,00 30 Mouse R$ 40,00  5 Teclado 1   R$ 40,00 R$ 40,00  Total pedido R$ 1,160,00 PEDIDO (PK)id_pedido + data_pedido + id_cliente + nome_cliente + endereco_cliente + id_produto + descricao_produto + qtd_produto + preco_produto+ total_produto + total_pedido

24 1FN A 1ª forma normal (“Eliminar os grupos repetidos”)
Basicamente dividimos os dados repetidos referentes ao produto, com isso criamos duas tabelas onde a segunda deve ter uma chave primaria da primeira tabela. PEDIDO (PK)id_pedido + data_pedido + id_cliente + nome_cliente + endereco_cliente + total_pedido PEDIDO_PRODUTO (FK) id_pedido + (PK)id_produto + descricao_produto + qtd_produto + preço_produto + total_produto

25 2FN A 2ª forma normal (“Todos os atributos não-chave são funcionalmente dependentes da chave na sua totalidade e não apenas de parte da chave”) Verificamos que todos os atributos da tabela PEDIDO dependem da chave (a data, os dados do cliente e o total da pedido). No entanto, na tabela PEDIDO_PRODUTO, os atributos referentes ao produto não dependem da chave primária da tabela, dando origem a uma terceira tabela. PEDIDO     (PK)id_pedido + data_pedido + id_cliente + nome_cliente + endereco_cliente + total_pedido PEDIDO_PRODUTO (FK)id_pedido + (PK) id_produto + qtd_produto + total_produto PRODUTO (PK)id_produto + descricao_produto + preco_produto

26 3FN A 3ª forma normal (“Nenhum atributo não-chave depende funcionalmente de nenhum outro atributo não-chave” Ao verificar a tabelas PRODUTO e PEDIDO_PRODUTO todos os atributos dependem da chave funcionalmente. Já se encontrando na 3ª Forma Normal. Ainda falta a tabela PEDIDO os dados referentes ao cliente dependem do id_cliente, sendo necessário criar uma quarta tabela. PEDIDO (PK) id_pedido + data_pedido + (FK) id_cliente + total_pedido CLIENTE (PK) id_cliente + nome_cliente + endereco_cliente PEDIDO_PRODUTO (PK) id_pedido + (FK) id_produto + qtd_produto + total_produto PRODUTO (PK) id_produto + descricao_produto + preco_produto

27 Referências delorelacional_p5.asp /unidade4/normalizacao.htm