Normalização de Dados

A normalização de um banco de dados é o tema do artigo de hoje. Este é um

tema super importante para a criação do banco de dados, vamos colocarmos a
mão-na-massa assim como fizemos no primeiro artigo de Modelagem de
Dados e vamos continuar a passar os fundamentos da linguagem e os conceitos
básicos de como funciona um banco de dados.

O Oracle é um SGBD relacional e isso quer dizer que ele aplica as regras
definidas por Edgar Frank Codd , ele foi quem desenvolveu o modelo de banco
de dados relacional. Ao todo são 12 regras, porém vou passar à vocês apenas as
3 primeiras que são as essenciais para o seu dia-a-dia.

O que vamos falar nesse artigo! [Ocutar]

• 1 Normalização Banco de Dados
o 1.1 Criando Tabelas na Normalização de Dados
o 1.2 Criando as Chaves Primárias na Normalização de Dados
o 1.3 Criando Chaves Estrangeiras na Normalização de Dados
o 1.4 Criando Relacionamentos na Normalização
• 2 Ferramenta para Normalização de Dados
• 3 3 Formas Normais
o 3.1 1ª Forma Normal (1FN)
o 3.2 2ª Forma Normal (2FN)
• 4 3ª Forma Normal (3FN)
• 5 Conclusão

Normalização Banco de Dados

Para começarmos a normalização é necessário recapitularmos o modelo
da primeira parte da aula de modelagem, abaixo vocês vão ver o modelo
relacional de entidades que fizemos na semana passada vamos seguir a ideia de
sempre darmos exemplos em cima da teoria, então vou passando as regras para
vocês com exemplos.
Com base no modelo que fizemos na ultima aula, vamos transformar isso tudo
em tabelas (que seria o local onde guardamos as informações no Banco de
Dados), e para isso existem algumas regras a serem seguidas.

Criando Tabelas na Normalização de Dados

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

Se você clicar no nome da entidade aparecerá o nome da tabela que vai ser
criada.

Relacionamentos que possuem atributos viram tabelas (existe a possibilidade

em relacionamentos 1:n dos atributos irem para uma das tabelas, ao invés de se
criar uma nova. Entretanto, relacionamentos com atributos são mais comuns
em relacionamentos n:n, gerando assim uma nova tabela);

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 campo ú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 eu vou 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
Um pouco mais de teoria com as 3 formas normais de Codd, que vou apresentar
a vocês.

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.

Conclusão
Após aplicar as 3 formais normais temos o nosso relacionamento do Banco de
Dados completo, mas antes de terminar gostaria de deixar para vocês minha
fonte para escrever este artigo foi este ótimo trabalho acadêmico que eu
encontrei no google, então caso alguém queira se aprofundar mais em
modelagem vale muito a pena lê-lo. E se você gostou do artigo não deixe de
comentar, sua opinião é muito importante para nós e claro se achou o artigo útil
compartilha ele com os seus amigos no facebook, Linkedin ou até mesmo no
seu grupo de whatsapp.