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.

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.