Artigo SQL Magazine 6 - Projeto de Banco Dados parte V: Modelo Físico

Projeto de Banco de Dados Parte V: Modelo Físico

Por  Vinicius Lourenço de Sousa

Continuando a construção do projeto de banco de dados da livraria Book.NET, veremos mais alguns recursos do modelo físico: normalização, chaves primárias e desnormalização.

Normalização

Normalizar significa organizar as tabelas de forma que informações redundantes não sejam armazenadas. A redundância gera uma série de problemas para o banco de dados – veja o artigo “Normalização e Técnicas”, publicado nesta edição, para maiores detalhes. 

A normalização é composta por  várias fases, onde cada uma é chamada de forma normal (FN). As tabelas, para serem consideradas bem projetadas, devem respeitar a definição das FNs. Neste artigo serão estudadas e aplicadas as três primeiras formas normais, já que as demais FNs são muito específicas e não são utilizadas na maioria das aplicações comerciais.

A seguir, daremos início a normalização aplicando a primeira forma normal nas tabelas do nosso projeto.

Nota: Muitos conceitos utilizados aqui são explicados no artigo “Normalização e Técnicas”, publicado nesta edição.

Primeira Forma Normal (1FN)

A regra da 1FN é simples: cada campo de uma tabela deve ser atômico, ou seja, indivisível. A 1FN geralmente é violada de três formas em um projeto de banco de dados:

1) Campos compostos: por exemplo, o campo Endereco da tabela Cliente. Nesse caso, obter a 1FN significa separar esse campo em partes indivisíveis. Veja o resultado da divisão na figura 1.

Definir se um campo é composto ou atômico não é uma tarefa simples. Normalmente, essa decisão é tomada com base na regra de negócio da aplicação. Por exemplo: o campo Nome deve ser dividido em partes menores (primeiro nome, sobrenome etc.)? A resposta é “depende” – em algumas aplicações (como venda de passagens) a separação do nome é importante; em outras, não.

2) Campos repetidos: imagine uma tabela de notas com campos Nota1, Nota2, Nota3 etc. Uma estrutura como essa tem problemas pois não é suficientemente flexível, desperdiça espaço e é ineficiente para realizar alguns tipos de busca. Se você armazenar uma única nota, estará desperdiçando espaço com colunas vazias. Se precisar armazenar quatro notas, terá que criar colunas extras.

Uma solução eficiente é criar uma tabela auxiliar e relacioná-la com a tabela principal através de uma chave estrangeira. Observe a figura 2.

3) Ocorrência de tabelas aninhadas ou atributos multivalorados: ambos possuem múltiplos valores para um mesmo atributo. A entidade Cliente possui quatro atributos multivalorados: telefone, email, homepage e endereço (observe no modelo que a cardinalidade destes atributos é 1:N).

A solução é criar uma tabela auxiliar, semelhante ao que é feito com atributos repetidos. Como exemplo, veja a tabela auxiliar Endereço na figura 3.

O mesmo procedimento foi feito para os campos email, homepage e telefone. O modelo atualizado após a aplicação da 1FN pode ser visualizado na figura 4.

Nota: Observe que as chaves primárias de Endereço, Telefone, Email e Homepage possuem o campo Cod_cliente, indicando que as tabelas são fracas em relação a Cliente.

Segunda Forma Normal (2FN)

"

A exibição deste artigo foi interrompida.

  Este é um post disponível para assinantes MVP

Este post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!

Saiba como acessar este post através de Créditos DevMedia:

Assinatura de Créditos – Aqui este post custa R$ 1,47
Com esse plano você compra R$ 180,00 em créditos e ganha, em média, 80% de desconto no preço do post.  
Assine agora

Plano ocasional - Aqui este post custa: R$ 1,96 (assinante) ou R$ 2,45 (não-assinante)
Você compra um mínimo de R$ 60,00 em créditos e ganha, em média, 50% de desconto no preço do post.  
Compre agora

Plano conveniência – Neste plano este post custa R$ 4,90
Neste plano você compra somente um post, pagando seu preço sem desconto.  
Compre agora