UNIVERSIDADE DO ESTADO DO PARÁ

CENTRO DE CIÊNCIAS NATURAIS E TECNOLÓGICAS

Disciplina: BANCO DE DADOS ll

Prof: EDUARDO TAVARES

NORMALIZAÇÃO EM BANCO DE DADOS

Normalização de banco de dados é um conjunto de regras que visa, principalmente,
a organização de um projeto de banco de dados para reduzir a redundância de dados,
aumentar a integridade de dados e o desempenho. Para normalizar o banco de dados,
deve-se examinar as colunas (atributos) de uma entidade e as relações entre
entidades (tabelas), com o objetivo de se evitar anomalias observadas na inclusão,
exclusão e alteração de registros.

 Este é um modelo ENTIDADE – RELACIONAMENTO. Neste modelo, as

entidades viram tabelas;
 As tabelas guardam as informações no Banco de Dados. Para isto existem
algumas regras a serem seguidas;
 Toda entidade vira uma tabela.

Então seguindo esta regra teremos as seguintes tabelas:

1. TB_PRODUTO
2. TB_COMANDA
3. TB_ESTOQUE
4. TB_CLIENTE
5. TB_CAIXA
Relacionamentos que possuem atributos viram tabelas.
Agora vamos criar as tabelas desses relacionamentos.
1. TB_PRODUTO_COMANDA
2. TB_PRODUTO_ESTOQUE
3. TB_CAIXA_ESTOQUE
4. TB_CLIENTE_PAGAMENTO

Toda tabela possui um ou mais campos que são os campos únicos, onde cada
entidade se diferencia, por exemplo, um cliente possui um CPF único que pode ser o
que diferencia todos os clientes, estes campos únicos são chamados de chaves
primárias.

Criando as Chaves Primárias na Normalização de Dados

Abaixo seguem as chaves primárias de todas as tabelas criadas.
1. ID_PRODUTO
2. ID_COMANDA, DT_INICIO, DT_FIM
3. ID_ESTOQUE
4. ID_CLIENTE (Que nesse caso vai ser o CPF)
5. ID_PAGAMENTO
6. ID_PRODUTO, ID_COMANDA, DT_INICIO, DT_FIM
7. ID_PRODUTO, ID_ESTOQUE
8. ID_PAGAMENTO, ID_ESTOQUE
9. ID_CLIENTE, ID_PAGAMENTO

Criando Chaves Estrangeiras na Normalização de Dados

Relacionamentos são representados por chaves estrangeiras (ou Foreign Key –
atributo correspondente à chave primária de outra relação, base para a integridade
referencial);
Temos as tabelas que possuem chaves estrangeiras que compõem os
relacionamentos das tabelas do nosso banco de dados.
 ID_PRODUTO, ID_COMANDA
 ID_PRODUTO, ID_ESTOQUE
 ID_PAGAMENTO, ID_ESTOQUE
 ID_CLIENTE, ID_PAGAMENTO

Perceberam algo bem interessante, as chaves estrangeiras são os mesmos campos

que formam as chaves primárias compostas dos relacionamentos, então tentem
sempre achar esta conexão entre os relacionamentos, chaves estrangeiras e chaves
primárias.

Criando Relacionamentos na Normalização

Relacionamentos 1:1 podem ser mapeados numa única tabela (quando possuem a
mesma chave primária), em duas tabelas (quando as chaves primárias são diferentes
e um dos lados do relacionamento é obrigatório) ou em três tabelas (quando o
relacionamento é opcional em ambos os lados)
No nosso caso existe apenas um relacionamento 1:1 na nossa modelagem que é o
relacionamento da entidade Comanda x Cliente, porque um cliente pode apenas ter
uma comanda para efetuar compras e uma comanda pode pertencer apenas a um
cliente enquanto ela estiver ativada. Por esse motivo temos esse relacionamento 1:1.
Mas elas possuem chaves primárias diferentes então por esse motivo tempos duas
tabelas, porém com a obrigatoriedade do ID_CLIENTE (Chave Primária da
TB_CLIENTE, na TB_COMANDA).
 Relacionamentos 1:n são mapeados de forma que a chave primária do lado “1”
seja representada do lado “n” como chave estrangeira;
 Relacionamentos n:n devem ser transformados em dois relacionamentos 1:n,
resultando numa nova tabela;
Estes dois últimos passos ficarão mais legais nos desenhos que vou mostrar para
vocês logo abaixo.

Ferramenta para Normalização de Dados

Após passar essas regras começamos a desenhar o nosso banco de dados, bom
como nesse caso ficaria muito trabalhoso usar o Paint para desenhar tudo na mão,
então vamos utilizar o MySql Workbench que é uma ferramenta utilizada para modelar
o MySQL, que é um banco de dados muito utilizado para aplicações web e que foi
comprado pela Oracle e melhor de tudo, esta ferramenta é totalmente grátis.

3 Formas Normais
1ª Forma Normal (1FN)
Toda relação deve ter uma chave primária e deve-se garantir que todo atributo seja
atômico. Atributos compostos devem ser separados. Por exemplo, um atributo
Endereço deve ser subdividido em seus componentes: Logradouro, Número,
Complemento, Bairro, Cidade, Estado e CEP. Além disso, atributos multivalorados
devem ser discriminados separadamente ou separados em uma outra relação. Por
exemplo, um atributo multivalorado Telefones poderia ser separado em Telefone
Residencial, Telefone Comercial e Telefone Celular ou, ainda, ser convertido em outra
relação que pudesse representar um número indeterminado de telefones.
Já passei para vocês como transformar um Modelo de Relacionamentos de Entidades
em um modelo de relacionamento de tabelas. E se alguém ficar com alguma dúvida
por favor comentem para que eu posso ajudá-los a resolve-las e claro fazer com que
o meu curso evolua sanando as principais dúvidas de todos.
Para exemplificar vou pegar um dos casos de relacionamento, quando criamos a
tabela TB_PRODUTO_COMANDA, que contém o Identificador da Comanda e o
Identificador do Produto estamos transformando um relacionamento de n:n entre o
produto e a comanda em um relacionamento 1:n, pois podem existir vários produtos,
mas na tabela TB_PRODUTO_COMANDA vai existir apenas um ID_PRODUTO e
campo quantidade para fazer os cálculos na hora da compra e o mesmo serve para a
Comanda, onde podem existir várias comandas, mas apenas um identificador de
comanda poderá estar atrelado a tabela TB_PRODUTO_COMANDA.
Segue a primeira parte do nosso modelo aplicando a primeira regra de normalização
de Codd.

2ª Forma Normal (2FN)

Toda relação deve estar na 1FN e devem-se eliminar dependências funcionais
parciais, ou seja, todo atributo não chave deve ser totalmente dependente da chave
primária. Como exemplo, uma relação que contenha os atributos Código da Obra,
Código do Fornecedor, Nome do Fornecedor e Preço de Venda, Considerando que a
chave primária é composta pelos atributos Código da Obra e Código do Fornecedor,
não está na Segunda Forma Normal, uma vez que o Nome do Fornecedor depende
apenas do Código do Fornecedor, e não do Código da Obra. Uma nova relação
(Fornecedor) deve ser criada contendo os campos Código do Fornecedor (como
chave) e Nome do Fornecedor. Na relação original, ficariam os atributos Código da
Obra e o Código do Fornecedor, ambos formando a chave primária composta, e o
atributo Preço de Venda. Além disso, o atributo Código do Fornecedor também seria
uma chave estrangeira para a nova relação criada. Esta forma normal ajuda a diminuir
redundâncias de informações criadas indevidamente.
Essa regra é bem interessante, porque eliminamos informações duplicados e
conseguimos conservar a integridade das informações, por exemplo, na tabela
TB_PRODUTO colocamos o nome do tipo do produto, bom vamos dizer que o produto
seja uma bebida, e que um funcionário cadastrou o banco de dados Bebida, mas veio
outro funcionário e ao cadastrar o produto cadastrou Bebidas, isso faria com que
tivéssemos dois tipos de produto cadastrados no banco, que na verdade seriam os
mesmos, por esse motivo é necessário criar essas tabelas.
Aplicando a 2ª Regra temos o seguinte modelo:

3ª Forma Normal (3FN)

Toda relação deve estar na 2FN e devem-se eliminar dependências funcionais
transitivas, ou seja, todo atributo não chave deve ser mutuamente independente.
Como exemplo, uma relação que contenha os atributos Matrícula do Funcionário
(atributo chave), Nome do Funcionário, Código do Departamento e Nome do
Departamento não está na Terceira Forma Normal. O Nome do Departamento é
dependente do Código do Departamento, e não da Matrícula do Funcionário. Uma
mudança no nome do departamento, por exemplo, levaria a modificações em todos
os funcionários daquele departamento. Para eliminar este problema, cria-se uma nova
relação (Departamento) contendo Código do Departamento e Nome do
Departamento. Na relação original, retira-se o Nome de Departamento, mantendo-se
o Código do Departamento, agora como chave estrangeira. Esta forma normal
também ajuda a diminuir redundâncias e aumentar a independência das relações.