Depois de ter um design preliminar para o banco de dados, você pode aplicar regras de normalização para certificar-se de que as tabelas estão estruturadas corretamente. Pense nestas regras como padrões da indústria.
Dito isto, nem todos os bancos de dados são bons candidatos para a normalização. Em geral, os bancos de dados de processamento de transações on-line (OLTP, na abreviação em inglês), nos quais os usuários se preocupam com a criação, a leitura, a atualização e a exclusão de registros, devem ser normalizados.
Bancos de dados de processamento analítico on-line (OLAP, na sigla em inglês), que favorecem a análise e a elaboração de relatórios podem ser melhorados com um certo grau de desnormalização, uma vez que a ênfase é na velocidade de cálculo. Estes incluem aplicativos de suporte à decisão onde os dados precisam ser analisados rapidamente, mas não alterados.
Cada formulário, ou nível de normalização, inclui as regras associadas com os formulários inferiores.
Primeiro formulário normal
O primeiro formulário normal (abreviado como 1NF) especifica que cada célula na tabela pode ter apenas um valor, nunca uma lista de valores, portanto, uma tabela como esta é incorreta:
| 1 | marrom, amarelo | US$ 15 |
| 2 | vermelho, verde | US$ 13 |
| 3 | azul, laranja | US$ 11 |
Você pode ser tentado a contornar isso dividindo esses dados em colunas adicionais, mas isso também é contra as regras: uma tabela com grupos de atributos repetidos ou estreitamente relacionados não atende ao primeiro formulário normal. A tabela abaixo, por exemplo, está incorreta:
Em vez disso, divida os dados em várias tabelas ou registros até que cada célula contenha apenas um valor e não haja colunas extras. Nesse ponto, diz-se que os dados são atômicos, ou divididos até o menor tamanho útil. Para a tabela acima, você poderia criar uma tabela adicional chamada "Detalhes de vendas" que corresponderia a produtos específicos com vendas. "Vendas" então teria uma relação 1:M com "Detalhes de vendas".
Segundo formulário normal
O segundo formulário normal (2NF) diz que cada um dos atributos deve ser totalmente dependente de toda a chave primária. Isso significa que cada atributo deve depender diretamente da chave primária, e não indiretamente, através de algum outro atributo.
Por exemplo, um atributo "idade" que depende de "data de nascimento", que por sua vez depende de "ID do aluno", é dito como tendo uma dependência funcional parcial, e uma tabela contendo esses atributos não cumpriria o segundo formulário normal.
Além disso, uma tabela com uma chave primária composta de vários campos viola o segundo formulário normal se um ou mais dos outros campos não dependerem de cada parte da chave.
Assim, uma tabela com esses campos não atenderia ao segundo formulário normal, porque o atributo "nome do produto" depende de ID do produto, mas não do número do pedido:
Número do pedido (chave primária)
ID do produto (chave primária)
- Nome do produto
Terceiro formulário normal
O terceiro formulário normal (3NF) adiciona a essas regras a exigência de que cada coluna sem chave seja independente de qualquer outra coluna. Se a alteração de um valor em uma coluna sem chave faz com que outro valor seja alterado, essa tabela não atende ao terceiro formulário normal.
Isso evita que você armazene quaisquer dados derivados na tabela, como a coluna "imposto" abaixo, que depende diretamente do preço total do pedido:
| Pedido | Preço | Imposto |
| 14325 | US$ 40,99 | US$ 2,05 |
| 14326 | US$ 13,73 | US$ 0,69 |
| 14327 | US$ 24,15 | US$ 1,21 |
Formulários adicionais de normalização foram propostos, incluindo o formulário normal de Boyce-Codd, o quarto a sexto formulários normais, e o formulário normal de domínio-chave, mas os três primeiros são os mais comuns.
Embora esses formulários expliquem as práticas recomendadas a serem seguidas em geral, o grau de normalização depende do contexto do banco de dados.
O que � Banco de Dados?
Segundo Korth, um banco de dados �� uma cole��o de dados inter-relacionados, representando informa��es sobre um dom�nio espec�fico�, ou seja, sempre que for poss�vel agrupar informa��es que se relacionam e tratam de um mesmo assunto, posso dizer que tenho um banco de dados.
Podemos exemplificar situa��es cl�ssicas como uma lista telef�nica, um cat�logo de CDs ou um sistema de controle de RH de uma empresa.
J� um sistema de gerenciamento de banco de dados (SGBD) � um software que possui recursos capazes de manipular as informa��es do banco de dados e interagir com o usu�rio. Exemplos de SGBDs s�o: Oracle, SQL Server, DB2, PostgreSQL, MySQL, o pr�prio Access ou Paradox, entre outros.
Por �ltimo, temos que conceituar um sistema de banco de dados como o conjunto de quatro componentes b�sicos: dados, hardware, software e usu�rios. Date conceituou que �sistema de bancos de dados pode ser considerado como uma sala de arquivos eletr�nica�. A Figura 1 ilustra os componentes de um sistema de banco de dados.
Confira nossa Guia de Banco de Dados para Programadores
Figura 1.Componentes de um sistema de banco de dadosOs objetivos de um sistema de banco de dados s�o o de isolar o usu�rio dos detalhes internos do banco de dados (promover a abstra��o de dados) e promover a independ�ncia dos dados em rela��o �s aplica��es, ou seja, tornar independente da aplica��o, a estrat�gia de acesso e a forma de armazenamento.
DevCast: Quatro dicas de banco de dados
Abstra��o de dados
O sistema de banco de dados deve garantir uma vis�o totalmente abstrata do banco de dados para o usu�rio, ou seja, para o usu�rio do banco de dados pouco importa qual unidade de armazenamento est� sendo usada para guardar seus dados, contanto que os mesmos estejam dispon�veis no momento necess�rio.
Esta abstra��o se d� em tr�s n�veis (Figura 2):
- N�vel de vis�o do usu�rio: as partes do banco de dados que o usu�rio tem acesso de acordo com a necessidade individual de cada usu�rio ou grupo de usu�rios;
- N�vel conceitual: define quais os dados que est�o armazenados e qual o relacionamento entre eles;
- N�vel f�sico: � o n�vel mais baixo de abstra��o, em que define efetivamente de que maneira os dados est�o armazenados.
Projeto de banco de dados
Todo bom sistema de banco de dados deve apresentar um projeto, que visa a organiza��o das informa��es e utiliza��o de t�cnicas para que o futuro sistema obtenha boa performance e tamb�m facilite infinitamente as manuten��es que venham a acontecer.
O projeto de banco de dados se d� em duas fases:
- Modelagem conceitual;
- Projeto l�gico.
Estas duas etapas se referem a um sistema de banco de dados ainda n�o implementado, ou seja, que ainda n�o exista, um novo projeto. Para os casos em que o banco de dados j� exista, mas � um sistema legado, por exemplo, ou um sistema muito antigo sem documenta��o, o processo de projeto de banco de dados se dar� atrav�s da utiliza��o de uma t�cnica chamada de Engenharia Reversa, que ser� visto em outra oportunidade.
Saiba mais sobre modeladem de dados
Modelo conceitual
� a descri��o do BD de maneira independente ao SGBD, ou seja, define quais os dados que aparecer�o no BD, mas sem se importar com a implementa��o que se dar� ao BD. Desta forma, h� uma abstra��o em n�vel de SGBD.
Uma das t�cnicas mais utilizadas dentre os profissionais da �rea � a abordagem entidade-relacionamento (ER), onde o modelo � representado graficamente atrav�s do diagrama entidade-relacionamento (DER) (Figura 3).
O modelo acima, entre outras coisas, nos traz informa��es sobre Alunos e Turmas. Para cada Aluno, ser� armazenado seu n�mero de matr�cula, seu nome e endere�o, enquanto para cada turma, teremos a informa��o de seu c�digo, a sala utilizada e o per�odo.
Modelo l�gico
Descreve o BD no n�vel do SGBD, ou seja, depende do tipo particular de SGBD que ser� usado. N�o podemos confundir com o Software que ser� usado. O tipo de SGBD que o modelo l�gico trata � se o mesmo � relacional, orientado a objetos, hier�rquico, etc.
Abordaremos o SGBD relacional, por serem os mais difundidos. Nele, os dados s�o organizados em tabelas (Quadro 1).
Aluno | ||
mat_aluno | nome | endereco |
1 | Cec�lia Ortiz Rezende | Rua dos Ip�s, 37 |
2 | Ab�lio Jos� Dias | Avenida Presidente J�nio Quadros, 357 |
3 | Renata Oliveira Franco | Rua Nove de Julho, 45 |
| Turma | ||
| cod_turma | sala | periodo |
| 1 | 8 | Manh�nte |
| 2 | 5 | Noite |
Quadro 1. Exemplo de tabelas em um SGBD relacional
O modelo l�gico do BD relacional deve definir quais as tabelas e o nome das colunas que comp�em estas tabelas.
Para o nosso exemplo, poder�amos definir nosso modelo l�gico conforme o seguinte:
Aluno(mat_aluno, nome, endereco) Turma (cod_turma, sala, periodo)
� importante salientar que os detalhes internos de armazenamento, por exemplo, n�o s�o descritos no modelo l�gico, pois estas informa��es fazem parte do modelo f�sico, que nada mais � que a tradu��o do modelo l�gico para a linguagem do software escolhido para implementar o sistema.
Refer�ncias bibliogr�ficas
KORTH, H.F. e SILBERSCHATZ, A.; Sistemas de Bancos de Dados, Makron Books, 2a. edi��o revisada, 1994.
DATE, C.J.; Int. a Sistemas de Bancos de Dados, tradu��o da 4a.edi��o norte-americana, Editora Campus, 1991.
Curso relacionado: Modelagem de Bancos de Dados Relacionais
Links �teis
- JPQL: Escrevendo consultas na JPA:
Aprender a consultar dados armazenados em bancos de dados relacionais � um importante passo na constru��o de sistemas. - Laravel: Como implementar um CRUD N:N:
Neste curso veremos como desenvolver um CRUD em Laravel utilizando duas entidades que se relacionam de forma N:N. - PHP e MVC: Como fazer um CRUD 1:N:
Neste curso voc� aprender� a implementar um sistema de CRUD com duas entidades que se relacionam de forma 1:N em PHP, usando para isso o padr�o arquitetural MVC.
Saiba mais sobre SQL ;)
- Guias Banco de Dados:
Aqui voc� encontra o Guia de estudo ideal para aprimorar seus conhecimentos nos principais Banco de Dados do mercado. Escolha o seu e bons estudos! - Banco de Dados para Programadores:
Neste guia voc� encontrar� os principais conte�dos que voc� precisa estudar, como programador, para trabalhar com bancos de dados. - Guia de Linguagem SQL:
Neste Guia de Refer�ncia voc� encontrar� todo o conte�do que precisa para aprender sobre a SQL, linguagem de consulta estruturada utilizada por programadores e DBAs para a execu��o de consultas e comandos nos principais SGBDs do mercado. - Canal Banco de Dados:
Al�m dos �ltimos posts da revista SQL Magazine, listamos os �ltimos artigos, v�deos e cursos sobre os principais banco de dados existentes hoje no mercado. - Revista SQL Magazine 149:
Edi��o que tem como destaque o aprimoramento da sua auditoria: conhe�a o Oracle Audit Vault Server.
- Banco de Dados
- Modelagem
- SGBD
- SQL
Confira outros conte�dos:
Por Ricardo Em 2006