O relacionamento N:N se transforma em uma tabela com chave primária composta

Se voc� pretende desenvolver aplica��es que usam banco de dados relacionais dever� possuir os conceitos b�sicos sobre modelagem de dados. N�o importa se sua aplica��o � muito simples ; a correta modelagem dos seus dados ir� com certeza tornar sua aplica��o mais robusta e mais f�cil de manter.

O prop�sito deste artigo � fornecer os conceitos b�sicos sobre modelagem de dados. Este assunto daria centenas de livros por isto estarei sendo o mais direto e o objetivo poss�vel de forma a que voc� possa aplicar de imediato os conceitos aprendidos. Como o t�tulo j� diz ser�o conceitos b�sicos e sobre banco de dados relacionais.

Nota: Estarei usando o ERWin como ferramenta para modelagem para os exemplos citados neste artigo. Eu n�o vou

Qual o objetivo da modelagem de dados ? Por que modelar ?

• Representar o ambiente observado
• Documentar e normalizar
• Fornecer processos de valida��o
• Observar processos de relacionamentos entre objetos

Modelar implica em construir modelos ent�o como fazer isto ? Podemos definir as etapas envolvidas na constru��o de modelos em :

1 - Modelo conceitual - Representa as regras de neg�cio sem limita��es tecnol�gicas ou de implementa��o por isto � a etapa mais adequada para o envolvimento do usu�rio que n�o precisa ter conhecimentos t�cnicos. Neste modelo temos :

• Vis�o Geral do neg�cio
• Facilita��o do entendimento entre usu�rios e desenvolvedores
• Possui somente as entidades e atributos principais
• Pode conter relacionamentos n para m.

2- Modelo L�gico - Leva em conta limites impostos por algum tipo de tecnologia de banco de dados. (banco de dados hier�rquico , banco de dados relacional ,etc.). Suas caracter�sticas s�o :

• Deriva do modelo conceitual e via a representa��o do neg�cio
• Possui entidades associativas em lugar de relacionamentos n:m
• Define as chaves prim�rias das entidades
• Normaliza��o at� a 3a. forma normal
• Adequa��o ao padr�o de nomenclatura
• Entidades e atributos documentados

3- Modelo F�sico - Leva em considera��o limites impostos pelo SGBD (Sistema Gerenciador de Banco de dados) e pelos requisitos n�o funcionais dos programas que acessam os dados. Caracter�sticas:

• Elaborado a  partir do modelo l�gico
• Pode variar segundo o SGBD
• Pode ter tabelas f�sicas (log , lider , etc.)
• Pode ter colunas f�sicas (replica��o)

Precisamos definir agora entidade e atributo. O que s�o e o que representam ?

Uma Entidade pode ser definida como qualquer coisa do mundo real , abstrata ou concreta , na qual se deseja guardar informa��es. (Tabela , File, etc..). Exemplos de entidades : Cliente , Produto , Contrato , Vendas , etc.

Um atributo  � tudo o que se pode relacionar como propriedade da entidade. (coluna , campo , etc,..). Exemplos de atributos : C�digo do Produto (Entidade Produto) , Nome do Cliente (Entidade Cliente).

Nota :  Chama-se Dom�nio o conjunto de valores poss�veis do atributo.

Obs: Nenhum modelo � suficientemente claro se n�o for acompanhado de uma defini��o formal dos elementos , fazemos isto atrav�s do Dicion�rio de Dados . Lembre-se , conceitos que podem ser triviais a quem esta modelando podem n�o ser para pessoas leigas no assunto. Assim o dicion�rio de dados tem o objetivo de deixar claro qualquer informa��o que seja de valia para o processo de compreens�o e unifica��o de conceitos.

Para que fique claro vamos fazer um exerc�cio simples: Definir uma entidade que represente as informa��es de uma Pessoa e descrever seus atributos.

Podemos definir a entidade Pessoa que ir� representar as informa��es de uma pessoa. Abaixo temos a representa��o da entidade e de alguns de seus atributos feitos no ERWin.

Ao lado temos a representa��o feita no ERWin da Entidade Pessoa e de alguns de seus atributos. Note que na defini��o dos atributos eu estou definindo a natureza do tipo de atributo. Exemplos de tipos de natureza: Texto , N�mero , Indicador(sim/n�o) , C�digo, etc. Alguns atributos s�o obrigat�rios outros s�o opcionais. Nome � obrigat�rio pois toda pessoa deve ter um nome Telefone � opcional pois nem toda pessoa possui um telefone

Ent�o podemos fazer as seguintes defini��es:

Atributo obrigat�rio -  � aquele que para uma inst�ncia de uma entidade ou relacionamento deve possuir um valor. (NOT NULL)

Atributo opcional - � aquele que para uma inst�ncia da entidade ou relacionamento pode possuir um valor. (NULL)

Podemos ainda classificar os atributos como :

Atributo Identificador - (#) - Atributo capaz de identificar exclusivamente cada ocorr�ncia de uma entidade. Tamb�m conhecido como chave Prim�ria ou Primary Key (PK). Ex: C�digo do Cliente , C�digo do Produto , etc.( O s�mbolo # � usado para representar a chave prim�ria em algumas nota��es)

Chave Candidata - Atributo ou grupamento de atributos que t�m a propriedade de identificar unicamente uma ocorr�ncia da entidade . Pode vir a ser uma chave Prim�ria. A chave candidata que n�o � chave prim�ria tamb�m chama-se chave Alternativa.

Caracter�sticas de uma Chave Prim�ria :

a - N�O PODE haver duas ocorr�ncias de uma mesma entidade com o mesmo conte�do na Chave Prim�ria
b - A chave prim�ria n�o pode ser composta por atributo opcional , ou seja , atributo que aceite nulo.

c - Os atributos identificadores devem ser o conjunto m�nimo que pode identificar cada inst�ncia de um entidade.

d - N�o devem ser usadas chaves externas. (Atributos sobre os quais voc� n�o tem controle. Ex: CPF)

e - Cada atributo identificador da chave deve possui um tamanho reduzido

f - N�o deve conter informa��o vol�til.

Ao criar modelos geralmente temos diversas entidades cada uma com diversos atributos que podem se relacionar entre si. Vamos definir como podem ser estes relacionamentos.

O que � um relacionamento ?

Um relacionamento pode ser entendido como uma associa��o entre inst�ncias de Entidades devido a regras de neg�cio. Normalmente ocorre entre inst�ncias de duas ou mais Entidades   , podendo ocorrer entre inst�ncias da mesma Entidade (auto-relacionamento).

Por que o relacionamento � necess�rio ?

• Quando existem v�rias possibilidades de relacionamento entre o par das entidades e se deseja representar apenas um
• Quando ocorrer mais de um relacionamento entre o par de entidades
• Para evitar ambiguidade
• Quando houver auto-relacionamento

Para definir o n�mero de ocorr�ncias de uma entidade usamos o conceito de Cardinalidade.

A Cardinalidade indica quantas ocorr�ncias de uma Entidade participam no m�nimo e no m�xima do relacionamento.

Cardinalidade M�nima - define se o relacionamento entre duas entidades � obrigat�rio ou n�o.
Ex: Abaixo temos a entidade Pais e a Entidade UF.

Um pa�s possui no m�nimo ZERO UF (Existem paises que n�o possuem Estados . Ex: Vaticano) Uma UF pertence pelo menos a UM Pa�s. Nota: O nome UF talvez n�o seja mais apropriado. A entidade representa um estado ou subdivis�o equivalente em um Pa�s

Cardinalidade M�xima - define a quantidade m�xima de ocorr�ncias da Entidade que pode participar do Relacionamento. Deve ser maior que zero.
Ex: Abaixo temos a entidade Pais e a Entidade UF novamente.

Pa�s possui no m�ximo V�rias (mais de uma) UF

Juntando as duas cardinalidade temos o modelo l�gico abaixo:

Pa�s pertence no m�nimo a ZERO UF e no m�ximo a V�RIOS UF UF pertence no m�ximo e no m�nimo a UM Pa�s.

Agora vamos definir os tipos de cardinalidade quanto ao relacionamento:

Cardinalidade UM para UM :

PESSOA pode ser no m�nimo um CLIENTE. (opcional)  CLIENTE � uma PESSOA.(Obrigat�rio)

Nota: No relacionamento Um para Um temos o lado opcional e o lado obrigat�rio . A chave prim�ria se desloca em dire��o ao lado opcional. No exemplo acima o descolamento seria da entidade CLIENTE para a entidade PESSOA.

Cardinalidade UM para N.

PRODUTO possui nenhum ou muitas modalidade de produto MODALIDADE DE PRODUTO pertence a um produto.

Nota : A cardinalidade UM para N leva a chave prim�ria do lado UM para o lado N. Neste caso o atributo recebe o nome de chave estrangeira ou Foreign Key ( FK ).  Chave Estrangeira � a chave prim�ria de uma entidade que aparece em outra entidade em virtude do relacionamento.

Cardinalidade N para N.

CLIENTE celebra um ou v�rios Contratos CONTRATO � celebrado por um ou v�rios clientes

A cardinalidade N para N leva para o modelo l�gico a necessidade de defini��o de mais um entidade. Chamamos isto de ASSOCIATIVA. Para o exemplo acima ter�amos:

A Entidade CLIENTE DO CONTRATO � necess�ria para que possamos identificar o contrato de um determinado cliente. Em toda Cardinalidade N para N temos a ASSOCIATIVA.

Normaliza��o

Normaliza��o � o conjunto de regras que visa minimizar as anomalias de modifica��o dos dados e dar maior flexibilidade em sua utiliza��o.

Por que Normalizar ?

         1�) Minimiza��o de redund�ncias e inconsist�ncias;
         2�) Facilidade de manipula��es do Banco de Dados;
         3�) Facilidade de manuten��o do Sistema de Informa��es

 Para que voc� compreenda melhor vou dar um exemplo. Vamos supor que voc� criou uma entidade Funcion�rios para armazenar as informa��es dos funcion�rios de um empresa e que o resultado f�sico final seja a tabela mostrada abaixo.

Se voc� olhar bem para a tabela acima vai ter que concordar comigo que ele sofre das seguintes anomalias:

• Anomalia de Exclus�o - O que acontece se voc� excluir o funcion�rio de c�digo igual a 3 ? O Setor vai ser exclu�do junto e ai voc� dan�ou..
   
• Anomalia de Altera��o - O nome do Setor Suporte mudou para Apoio . Voc� vai ter alterar o nome em todos os registros da tabela. Dan�ou novamente...
   
• Anomalia de Inclus�o - Foi contratado um novo funcion�rio para o Setor Suporte.  Voc� vai ter que incluir um funcion�rio ao campo - QuantidadeFuncionarios -  em todas as ocorr�ncias com setor de nome SUPORTE. Dan�ou mais uma vez...

Para poder resolver o dilema acima temos que NORMALIZAR a entidade. Para isto aplicamos as formas normais a saber:

1- Primeira Forma Normal -(1FN)-   Uma rela��o est� na 1FN se somente todos os dom�nios b�sicos contiverem somente valores at�micos (n�o contiver grupos repetitivos). Para atingir esta forma normal devemos eliminar os grupos de repeti��o. Como ?0

Procedimentos:

    a) Identificar a chave prim�ria da entidade;
    b) Identificar o grupo repetitivo e exclu�-lo da entidade;
    c) Criar uma nova entidade com a chave prim�ria da entidade anterior e o grupo repetitivo.

A chave prim�ria da nova entidade ser� obtida pela concatena��o da chave prim�ria da entidade inicial e a do grupo repetitivo.

Abaixo temos um exemplo de como efetuar a normaliza��o para a primeira forma normal:

N�o normalizada	Normalizada usando a primeira forma normal (1FN)

2- Segunda Forma Normal -(2FN)-   Uma rela��o R est� na 2FN se e somente se ela estiver na primeira e todos os atributos n�o chave forem totalmente dependentes da chave prim�ria (dependente de toda a chave e n�o apenas de parte dela).   

Procedimentos:

a) Identificar os atributos que n�o s�o funcionalmente dependentes de toda a chave prim�ria.

b) Remover da entidade todos esses atributos identificados e criar uma nova entidade com eles.

A chave prim�ria da nova entidade ser� o atributo do qual os atributos do qual os atributos removidos s�o funcionalmente dependentes.

Exemplo:

Sejam as entidades :

Arquivo de Notas Fiscais (Num. NF, S�rie, C�digo do Cliente, Nome do cliente, Endere�o do cliente, Total Geral da Nota)

Arquivo de Vendas (Num. NF, C�digo da Mercadoria, Descri��o da Mercadoria, Quantidade vendida, Pre�o de venda e Total da venda )
 

Normalizando para segunda forma normal (2FN):

Arquivo de Notas Fiscais (Num. NF, S�rie, C�digo do Cliente, Nome do cliente, Endere�o do cliente, Total Geral da Nota)

Arquivo de Vendas (Num. NF, C�digo da Mercadoria, Quantidade vendida e Total da Venda)

Arquivo de Mercadorias (C�digo da Mercadoria, Descri��o da Mercadoria, Pre�o de venda)

Como resultado desta etapa, houve um desdobramento do arquivo de Vendas (o arquivo de Notas Fiscais, n�o foi alterado, por n�o possuir chave composta) em duas estruturas a saber:

Primeira estrutura (Arquivo de Vendas): Cont�m os elementos originais, sendo exclu�dos os dados que s�o dependentes apenas do campo C�digo da Mercadoria.

Segundo estrutura (Arquivo de Mercadorias): Cont�m os elementos que s�o identificados apenas pelo C�digo da Mercadoria, ou seja, independentemente da Nota Fiscal, a descri��o e o pre�o de venda ser�o constantes.

3- Terceira Forma Normal -(2FN)-  Uma rela��o R est� na 3FN se somente estiver na 2FN e todos os atributos n�o chave forem dependentes n�o transitivos da chave prim�ria (cada atributo for funcionalmente dependente apenas dos atributos componentes da chave prim�ria ou se todos os seus atributos n�o chave forem independentes entre si).

Procedimentos:

a) Identificar todos os atributos que s�o funcionalmente dependentes de outros atributos n�o chave;

b) Remov�-los e criar uma nova entidade com os mesmos.
 

A chave prim�ria da nova entidade ser� o atributo do qual os atributos removidos s�o funcionalmente dependentes.

Estrutura na segunda forma normal (2FN):

Arquivo de Notas Fiscais (Num. NF, S�rie, Data emiss�o, C�digo do Cliente, Nome do cliente, Endere�o do cliente, Total Geral da Nota)

Arquivo de Vendas (Num. NF, C�digo da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)

Arquivo de Mercadorias (C�digo da Mercadoria, Descri��o da Mercadoria, Pre�o de venda)

Estrutura na terceira forma normal (3FN):

Arquivo de Notas Fiscais (Num. NF, S�rie, Data emiss�o, C�digo do Cliente e Total Geral da Nota)

Arquivo de Vendas (Num. NF, C�digo da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)

Arquivo de Mercadorias (C�digo da Mercadoria, Descri��o da Mercadoria, Pre�o de venda)

Arquivo de Clientes (C�digo do Cliente, Nome do cliente, Endere�o do cliente)

Como resultado desta etapa, houve um desdobramento do arquivo de Notas Fiscais, por ser o �nico que possu�a campos que n�o eram dependentes da chave principal (Num. NF), uma vez que independente da Nota Fiscal, o Nome, Endere�o s�o inalterados. Este procedimento permite evitar inconsist�ncia nos dados dos arquivos e economizar espa�o por eliminar o armazenamento freq�ente e repetidas vezes destes dados. A cada nota fiscal comprada pelo cliente, haver� o armazenamento destes dados e poder� ocorrer diverg�ncia entre eles.

As estruturas alteradas e o motivo das altera��es :

- Primeira estrutura (Arquivo de Notas Fiscais): Cont�m os elementos originais, sendo exclu�do os dados que s�o dependentes apenas do campo C�digo do Cliente (informa��es referentes ao cliente).

- Segundo estrutura (Arquivo de Clientes): Cont�m os elementos que s�o identificados apenas pelo C�digo do Cliente, ou seja, independente da Nota Fiscal, o Nome, Endere�o ser�o constantes.

Ap�s a normaliza��o, as estruturas dos dados est�o projetadas para eliminar as inconsist�ncias e redund�ncias dos dados, eliminando desta forma qualquer problema de atualiza��o e operacionaliza��o do sistema.  A vers�o final dos dados poder� sofrer alguma altera��o, para atender as necessidades espec�ficas do sistema, a crit�rio do analista de desenvolvimento durante o projeto f�sico do sistema

Exerc�cios sobre modelagem de dados

Vejamos a seguir alguns exerc�cios pr�ticos onde iremos colocar toda esta teoria para funcionar em casos quase reais.

Exerc�cio 1
Vou come�ar com um bem simples : De acordo com as regras , normalize as estruturas abaixo.

•– Rela��o de Funcion�rio:

-•MATR�CULA DO FUNCION�RIO

•-NOME DO FUNCION�RIO

•-DATA DO NASCIMENTO

•-DEPENDENTE

–    -C�DIGO DO DEPENDENTE

    –-NOME DO DEPENDENTE

•-CURSO

    –-C�DIGO DO CURSO

    –-NOME DO CURSO

    –-ANO DO CURSO

–Regras do neg�cio :

• Um funcion�rio pode ter mais de um dependente
• Um funcion�rio pode fazer mais de um curso

Esta � simples. Veja abaixo uma das solu��es:

Resposta:

–

Exerc�cio 2:
Voc� acabou de fundar sua empresa de consultoria , a Maicrousofiti Consultoria , e seu primeiro trabalho e desenvolver um sistema para cadastro de clientes voc� recebeu o cliente uma lista com os dados que dever�o compor o sistema , com base nesta lista lista normalize a estrutura de dados de acordo com as formas normais.

Lista de informa��es que dever�o compor o sistema cadastro de clientes:

Antes de ver a resposta sugiro que pelo menos tente esbo�ar alguma tentativa de resolver a quest�o.

Que tal deixar a solu��o para um pr�ximo artigo ? Brincadeira ! Uma das poss�veis solu��es � dada abaixo:

Resposta

Exerc�cio 3
Para deixar voc� ainda mais afiado vamos a outra situa��o.

Voc� deve representar usando o modelo l�gico a situa��o descrita a seguir:

•

•O Departamento de Vendas da Ind�stria Beleza Ltda, ap�s estudos de mercado, verificou que para atingir seus objetivos seria necess�rio adquirir frota de ve�culos pr�prios para motorizar seus vendedores. O mercado consumidor foi dividido em regi�es de venda; foram estabelecidos percursos de entrega abrangendo pontos estrat�gicos dessas regi�es e vendedores foram designados para cobrir estes percursos. Um sistema deve ser constru�do para administra��o da nova sistem�tica de vendas adotada pela empresa. Ap�s entrevistas com o gerente da �rea, foram obtidas as seguintes informa��es:
 

•

�- - cada regi�o � identificada por um c�digo;

-� uma regi�o � composta de v�rios pontos estrat�gicos;

- �as regi�es n�o t�m pontos estrat�gicos em comum;

- �o vendedor tem a responsabilidade de cobrir uma regi�o;

- �uma regi�o pode ser coberta por v�rios vendedores;

- �a cada dia, um ve�culo fica sob responsabilidade de um vendedor;

- �um vendedor pode vender quaisquer itens ativos da tabela de produtos;

- �o vendedor � respons�vel pela identifica��o de cada cliente consumidor na nota fiscal;

- �a nota fiscal contendo identifica��o do vendedor, itens e quantidades vendidas � exigida para comprova��o da venda

E ent�o ? Quer ver como seria uma das solu��es ? Ent�o espia...

Resposta

Para encerrar aqui vai a �ltima quest�o.

Exercicio 4:
De acordo com as regras , normalize as estruturas abaixo.

•Rela��o de Programadores:

–Numero da Matr�cula

– Nome do Programador

–Setor

–N�vel ( 1,2,3)

–Descri��o do N�vel ( 1 - J�nior, 2 - Pleno, 3 - Senior)

–Programas

–Codigo do Programa

–Nome do Programa

–Tempo Estimado

–N�vel de Dificuldade ( 1, 2 ou 3 )

–Descri��o da Dificuldade ( F�cil, M�dio, Dif�cil)

Regras do neg�cio:
- Um programa pode ser feito por mais de um Programador;

- Um programador pode fazer um ou mais programas;

- O N�vel de dificuldade do programa depende do tempo estimado para a elabora��o do  mesmo;

Resposta:

Voc� n�o pode reclamar , dei a teoria e ainda mostrei alguns casos pr�ticos cl�ssicos resolvidos. � claro que para se tornar um bom modelador de dados voc� vai precisar ler mais e praticar muiiitooo maaaiiisss...

At� o pr�ximo artigo VB.

Refer�ncias:

• Se��o VB .NET do Site Macoratti.net

• Super DVD .NET - A sua porta de entrada na plataforma .NET

• Super DVD V�deo Aulas - V�deo Aula sobre VB .NET, ASP .NET e C#

• Se��o C# do site Macoratti.net

• Se��o Visual Basic 6 do site Macoratti .net

Jos� Carlos Macoratti

O que é uma chave primária composta?

Quando um relacionamento vira tabela?

O que é um relacionamento N N?

Qual é a função de uma chave primária?