| 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 |
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:
Nome |
Nome do Pai |
Nome da M�e |
Endere�o |
Telefone1 |
Telefone2 |
N�mero do Fax |
N�mero do Celular |
Telefone do trabalho |
Data de Nascimento |
Naturalidade |
Nacionalidade |
Endere�o de correspond�ncia |
Nome do filho 1 |
idade do filho 1 |
Nome do filho 2 |
idade do filho 2 |
Nome do filho 3 |
idade do filho 3 |
Nome do filho 4 |
idade do filho 4 |
Nome do C�njuge |
N�mero do CPF |
N�mero da carteira de identidade |
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