07/10/2016 Conceitosbsicosdemodelagemdedados

Conceitos Bsicos de modelagem de dados

Se voc pretende desenvolver aplicaes que usam banco de dados relacionais dever possuir os conceitos bsicos
sobre modelagem de dados. No importa se sua aplicao muito simples ; a correta modelagem dos seus dados ir
com certeza tornar sua aplicao mais robusta e mais fcil de manter.

O propsito deste artigo fornecer os conceitos bsicos sobre modelagem de dados. Este assunto daria centenas de
livros por isto estarei sendo o mais direto e o objetivo possvel de forma a que voc possa aplicar de imediato os
conceitos aprendidos. Como o ttulo j diz sero conceitos bsicos e sobre banco de dados relacionais.

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

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

Representar o ambiente observado

Documentar e normalizar
Fornecer processos de validao
Observar processos de relacionamentos entre objetos

Modelar implica em construir modelos ento como fazer isto ? Podemos definir as etapas envolvidas na construo de
modelos em :

1 Modelo conceitual Representa as regras de negcio sem limitaes tecnolgicas ou de implementao por isto
a etapa mais adequada para o envolvimento do usurio que no precisa ter conhecimentos tcnicos. Neste modelo
temos :

Viso Geral do negcio

Facilitao do entendimento entre usurios e desenvolvedores
Possui somente as entidades e atributos principais
Pode conter relacionamentos n para m.

2 Modelo Lgico Leva em conta limites impostos por algum tipo de tecnologia de banco de dados. (banco de dados
hierrquico , banco de dados relacional ,etc.). Suas caractersticas so :

Deriva do modelo conceitual e via a representao do negcio

Possui entidades associativas em lugar de relacionamentos n:m
Define as chaves primrias das entidades
Normalizao at a 3a. forma normal
Adequao ao padro de nomenclatura
Entidades e atributos documentados

3 Modelo Fsico Leva em considerao limites impostos pelo SGBD (Sistema Gerenciador de Banco de dados) e
pelos requisitos no funcionais dos programas que acessam os dados. Caractersticas:

Elaborado a partir do modelo lgico

Pode variar segundo o SGBD
Pode ter tabelas fsicas (log , lider , etc.)
Pode ter colunas fsicas (replicao)

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

Uma Entidade pode ser definida como qualquer coisa do mundo real , abstrata ou concreta , na qual se deseja
guardar informaes. (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 : Cdigo do Produto (Entidade Produto) , Nome do Cliente (Entidade Cliente).

Nota : Chamase Domnio o conjunto de valores possveis do atributo.

Obs: Nenhum modelo suficientemente claro se no for acompanhado de uma definio formal dos elementos ,
fazemos isto atravs do Dicionrio de Dados . Lembrese , conceitos que podem ser triviais a quem esta modelando
podem no ser para pessoas leigas no assunto. Assim o dicionrio de dados tem o objetivo de deixar claro qualquer
informao que seja de valia para o processo de compreenso e unificao de conceitos.

Para que fique claro vamos fazer um exerccio simples: Definir uma entidade que represente as informaes de uma
Pessoa e descrever seus atributos.

http://www.macoratti.net/cbmd1.htm 1/10
07/10/2016 Conceitosbsicosdemodelagemdedados

Podemos definir a entidade Pessoa que ir representar as informaes de uma pessoa. Abaixo temos a representao
da entidade e de alguns de seus atributos feitos no ERWin.

Ao lado temos a representao feita no ERWin da

Entidade Pessoa e de alguns de seus atributos.

Note que na definio dos atributos eu estou

definindo a natureza do tipo de atributo. Exemplos
de tipos de natureza: Texto , Nmero ,
Indicador(sim/no) , Cdigo, etc.

Alguns atributos so obrigatrios outros so

opcionais.

Nome obrigatrio pois toda pessoa deve ter um

nome
Telefone opcional pois nem toda pessoa possui um
telefone

Ento podemos fazer as seguintes definies:

Atributo obrigatrio aquele que para uma instncia de uma entidade ou relacionamento deve possuir um valor.
(NOT NULL)

Atributo opcional aquele que para uma instncia da entidade ou relacionamento pode possuir um valor. (NULL)

Podemos ainda classificar os atributos como :

Atributo Identificador (#) Atributo capaz de identificar exclusivamente cada ocorrncia de uma entidade.
Tambm conhecido como chave Primria ou Primary Key (PK). Ex: Cdigo do Cliente , Cdigo do Produto , etc.( O
smbolo # usado para representar a chave primria em algumas notaes)

Chave Candidata Atributo ou grupamento de atributos que tm a propriedade de identificar unicamente uma
ocorrncia da entidade . Pode vir a ser uma chave Primria. A chave candidata que no chave primria tambm
chamase chave Alternativa.

Caractersticas de uma Chave Primria :

a NO PODE haver duas ocorrncias de uma mesma entidade com o mesmo contedo na Chave Primria
b A chave primria no pode ser composta por atributo opcional , ou seja , atributo que aceite nulo.
c Os atributos identificadores devem ser o conjunto mnimo que pode identificar cada instncia de um entidade.
d No devem ser usadas chaves externas. (Atributos sobre os quais voc no tem controle. Ex: CPF)
e Cada atributo identificador da chave deve possui um tamanho reduzido
f No deve conter informao voltil.

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 associao entre instncias de Entidades devido a regras de
negcio. Normalmente ocorre entre instncias de duas ou mais Entidades , podendo ocorrer entre instncias da
mesma Entidade (autorelacionamento).

Por que o relacionamento necessrio ?

Quando existem vrias 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 autorelacionamento

Para definir o nmero de ocorrncias de uma entidade usamos o conceito de Cardinalidade.

A Cardinalidade indica quantas ocorrncias de uma Entidade participam no mnimo e no mxima do relacionamento.

Cardinalidade Mnima define se o relacionamento entre duas entidades obrigatrio ou no.

Ex: Abaixo temos a entidade Pais e a Entidade UF.

http://www.macoratti.net/cbmd1.htm 2/10
07/10/2016 Conceitosbsicosdemodelagemdedados

Um pas possui no mnimo ZERO UF

(Existem paises que no possuem
Estados . Ex: Vaticano)

Uma UF pertence pelo menos a UM

Pas.

Nota: O nome UF talvez no seja

mais apropriado. A entidade
representa um estado ou subdiviso
equivalente em um Pas

Cardinalidade Mxima define a quantidade mxima de ocorrncias da Entidade que pode participar do
Relacionamento. Deve ser maior que zero.
Ex: Abaixo temos a entidade Pais e a Entidade UF novamente.

Pas possui no
mximo Vrias (mais
de uma) UF

Juntando as duas cardinalidade temos o modelo lgico abaixo:

Pas pertence no
mnimo a ZERO UF
e no mximo a
VRIOS UF

UF pertence no
mximo e no
mnimo a UM Pas.

Agora vamos definir os tipos de cardinalidade quanto ao relacionamento:

Cardinalidade UM para UM :

PESSOA
pode ser no
mnimo um
CLIENTE.
(opcional)

CLIENTE
uma
PESSOA.
(Obrigatrio)

Nota: No relacionamento Um para Um temos o lado opcional e o lado obrigatrio . A chave primria se desloca em
direo 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 primria 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 primria de uma entidade que

http://www.macoratti.net/cbmd1.htm 3/10
07/10/2016 Conceitosbsicosdemodelagemdedados

aparece em outra entidade em virtude do relacionamento.

Cardinalidade N para N.

CLIENTE
celebra
um ou
vrios
Contratos

CONTRATO

celebrado
por um ou
vrios
clientes

A cardinalidade N para N leva para o modelo lgico a necessidade de definio de mais um entidade. Chamamos isto
de ASSOCIATIVA. Para o exemplo acima teramos:

A Entidade CLIENTE
DO CONTRATO
necessria para que
possamos identificar
o contrato de um
determinado
cliente.

Em toda
Cardinalidade N para
N temos a
ASSOCIATIVA.

Normalizao

Normalizao o conjunto de regras que visa minimizar as anomalias de modificao dos dados e dar maior
flexibilidade em sua utilizao.

Por que Normalizar ?

1) Minimizao de redundncias e inconsistncias;

2) Facilidade de manipulaes do Banco de Dados;
3) Facilidade de manuteno do Sistema de Informaes

Para que voc compreenda melhor vou dar um exemplo. Vamos supor que voc criou uma entidade Funcionrios
para armazenar as informaes dos funcionrios de um empresa e que o resultado fsico 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 Excluso O que acontece se voc excluir o funcionrio de cdigo igual a 3 ? O Setor vai ser
excludo junto e ai voc danou..

Anomalia de Alterao O nome do Setor Suporte mudou para Apoio . Voc vai ter alterar o nome em todos os
registros da tabela. Danou novamente...

Anomalia de Incluso Foi contratado um novo funcionrio para o Setor Suporte. Voc vai ter que incluir um
funcionrio ao campo QuantidadeFuncionarios em todas as ocorrncias com setor de nome SUPORTE. Danou
mais uma vez...

http://www.macoratti.net/cbmd1.htm 4/10
07/10/2016 Conceitosbsicosdemodelagemdedados

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 relao est na 1FN se somente todos os domnios bsicos contiverem
somente valores atmicos (no contiver grupos repetitivos). Para atingir esta forma normal devemos eliminar os
grupos de repetio. Como ?0

Procedimentos:

a) Identificar a chave primria da entidade;

b) Identificar o grupo repetitivo e exclulo da entidade;
c) Criar uma nova entidade com a chave primria da entidade anterior e o grupo repetitivo.

A chave primria da nova entidade ser obtida pela concatenao da chave primria da entidade inicial e a do grupo
repetitivo.

Abaixo temos um exemplo de como efetuar a normalizao para a primeira forma normal:

No normalizada Normalizada usando a primeira forma normal (1FN)

2 Segunda Forma Normal (2FN) Uma relao R est na 2FN se e somente se ela estiver na primeira e todos os
atributos no chave forem totalmente dependentes da chave primria (dependente de toda a chave e no apenas de
parte dela).

Procedimentos:

a) Identificar os atributos que no so funcionalmente dependentes de toda a chave primria.

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

A chave primria da nova entidade ser o atributo do qual os atributos do qual os atributos removidos so
funcionalmente dependentes.
Exemplo:
Sejam as entidades :
Arquivo de Notas Fiscais (Num. NF, Srie, Cdigo do Cliente, Nome do cliente, Endereo do cliente, Total Geral da
Nota)
Arquivo de Vendas (Num. NF, Cdigo da Mercadoria, Descrio da Mercadoria, Quantidade vendida, Preo de venda e
Total da venda )

Normalizando para segunda forma normal (2FN):

Arquivo de Notas Fiscais (Num. NF, Srie, Cdigo do Cliente, Nome do cliente, Endereo do cliente, Total Geral da
Nota)
Arquivo de Vendas (Num. NF, Cdigo da Mercadoria, Quantidade vendida e Total da Venda)
Arquivo de Mercadorias (Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda)

http://www.macoratti.net/cbmd1.htm 5/10
07/10/2016 Conceitosbsicosdemodelagemdedados

Como resultado desta etapa, houve um desdobramento do arquivo de Vendas (o arquivo de Notas Fiscais, no foi
alterado, por no possuir chave composta) em duas estruturas a saber:
Primeira estrutura (Arquivo de Vendas): Contm os elementos originais, sendo excludos os dados que so
dependentes apenas do campo Cdigo da Mercadoria.
Segundo estrutura (Arquivo de Mercadorias): Contm os elementos que so identificados apenas pelo Cdigo da
Mercadoria, ou seja, independentemente da Nota Fiscal, a descrio e o preo de venda sero constantes.

3 Terceira Forma Normal (2FN) Uma relao R est na 3FN se somente estiver na 2FN e todos os atributos no
chave forem dependentes no transitivos da chave primria (cada atributo for funcionalmente dependente apenas
dos atributos componentes da chave primria ou se todos os seus atributos no chave forem independentes entre si).

Procedimentos:

a) Identificar todos os atributos que so funcionalmente dependentes de outros atributos no chave;

b) Removlos e criar uma nova entidade com os mesmos.

A chave primria da nova entidade ser o atributo do qual os atributos removidos so funcionalmente dependentes.
Estrutura na segunda forma normal (2FN):
Arquivo de Notas Fiscais (Num. NF, Srie, Data emisso, Cdigo do Cliente, Nome do cliente, Endereo do cliente,
Total Geral da Nota)
Arquivo de Vendas (Num. NF, Cdigo da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)
Arquivo de Mercadorias (Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda)
Estrutura na terceira forma normal (3FN):
Arquivo de Notas Fiscais (Num. NF, Srie, Data emisso, Cdigo do Cliente e Total Geral da Nota)
Arquivo de Vendas (Num. NF, Cdigo da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)
Arquivo de Mercadorias (Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda)
Arquivo de Clientes (Cdigo do Cliente, Nome do cliente, Endereo do cliente)
Como resultado desta etapa, houve um desdobramento do arquivo de Notas Fiscais, por ser o nico que possua
campos que no eram dependentes da chave principal (Num. NF), uma vez que independente da Nota Fiscal, o
Nome, Endereo so inalterados. Este procedimento permite evitar inconsistncia nos dados dos arquivos e
economizar espao por eliminar o armazenamento freqente e repetidas vezes destes dados. A cada nota fiscal
comprada pelo cliente, haver o armazenamento destes dados e poder ocorrer divergncia entre eles.
As estruturas alteradas e o motivo das alteraes :
Primeira estrutura (Arquivo de Notas Fiscais): Contm os elementos originais, sendo excludo os dados que so
dependentes apenas do campo Cdigo do Cliente (informaes referentes ao cliente).
Segundo estrutura (Arquivo de Clientes): Contm os elementos que so identificados apenas pelo Cdigo do
Cliente, ou seja, independente da Nota Fiscal, o Nome, Endereo sero constantes.

Aps a normalizao, as estruturas dos dados esto projetadas para eliminar as inconsistncias e redundncias dos
dados, eliminando desta forma qualquer problema de atualizao e operacionalizao do sistema. A verso final dos
dados poder sofrer alguma alterao, para atender as necessidades especficas do sistema, a critrio do analista de
desenvolvimento durante o projeto fsico do sistema

Exerccios sobre modelagem de dados

Vejamos a seguir alguns exerccios prticos onde iremos colocar toda esta teoria para funcionar em casos quase reais.

Exerccio 1
Vou comear com um bem simples : De acordo com as regras , normalize as estruturas abaixo.

Relao de Funcionrio:
MATRCULA DO FUNCIONRIO
NOME DO FUNCIONRIO
DATA DO NASCIMENTO
DEPENDENTE
CDIGO DO DEPENDENTE
NOME DO DEPENDENTE
CURSO
CDIGO DO CURSO
NOME DO CURSO
ANO DO CURSO
http://www.macoratti.net/cbmd1.htm 6/10
07/10/2016 Conceitosbsicosdemodelagemdedados

Regras do negcio :

Um funcionrio pode ter mais de um dependente

Um funcionrio pode fazer mais de um curso

Esta simples. Veja abaixo uma das solues:

Resposta:

Exerccio 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 devero compor
o sistema , com base nesta lista lista normalize a estrutura de dados de acordo com as formas normais.

Lista de informaes que devero compor o sistema cadastro de clientes:

Nome
Nome do Pai
Nome da Me
Endereo
Telefone1
Telefone2
Nmero do Fax
Nmero do Celular
Telefone do trabalho
Data de Nascimento
Naturalidade
Nacionalidade
Endereo de correspondncia
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 Cnjuge
Nmero do CPF
Nmero da carteira de
identidade

Antes de ver a resposta sugiro que pelo menos tente esboar alguma tentativa de resolver a questo.

Que tal deixar a soluo para um prximo artigo ? Brincadeira ! Uma das possveis solues dada abaixo:

Resposta

http://www.macoratti.net/cbmd1.htm 7/10
07/10/2016 Conceitosbsicosdemodelagemdedados

Exerccio 3
Para deixar voc ainda mais afiado vamos a outra situao.

Voc deve representar usando o modelo lgico a situao descrita a seguir:

O Departamento de Vendas da Indstria Beleza Ltda, aps estudos de mercado, verificou que para atingir seus
objetivos seria necessrio adquirir frota de veculos prprios para motorizar seus vendedores. O mercado consumidor
foi dividido em regies de venda; foram estabelecidos percursos de entrega abrangendo pontos estratgicos dessas
regies e vendedores foram designados para cobrir estes percursos. Um sistema deve ser construdo para
administrao da nova sistemtica de vendas adotada pela empresa. Aps entrevistas com o gerente da rea, foram
obtidas as seguintes informaes:

cada regio identificada por um cdigo;
uma regio composta de vrios pontos estratgicos;
as regies no tm pontos estratgicos em comum;
o vendedor tem a responsabilidade de cobrir uma regio;
uma regio pode ser coberta por vrios vendedores;
a cada dia, um veculo fica sob responsabilidade de um vendedor;
um vendedor pode vender quaisquer itens ativos da tabela de produtos;
o vendedor responsvel pela identificao de cada cliente consumidor na nota fiscal;
a nota fiscal contendo identificao do vendedor, itens e quantidades vendidas exigida para comprovao da
venda

E ento ? Quer ver como seria uma das solues ? Ento espia...

Resposta

http://www.macoratti.net/cbmd1.htm 8/10
07/10/2016 Conceitosbsicosdemodelagemdedados

Para encerrar aqui vai a ltima questo.

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

Relao de Programadores:
Numero da Matrcula
Nome do Programador
Setor
Nvel ( 1,2,3)
Descrio do Nvel ( 1 Jnior, 2 Pleno, 3 Senior)
Programas
Codigo do Programa
Nome do Programa
Tempo Estimado
Nvel de Dificuldade ( 1, 2 ou 3 )
Descrio da Dificuldade ( Fcil, Mdio, Difcil)

Regras do negcio:
Um programa pode ser feito por mais de um Programador;
Um programador pode fazer um ou mais programas;
O Nvel de dificuldade do programa depende do tempo estimado para a elaborao do
mesmo;

Resposta:

http://www.macoratti.net/cbmd1.htm 9/10
07/10/2016 Conceitosbsicosdemodelagemdedados

Voc no pode reclamar , dei a teoria e ainda mostrei alguns casos prticos clssicos resolvidos. claro que para se
tornar um bom modelador de dados voc vai precisar ler mais e praticar muiiitooo maaaiiisss...

At o prximo artigo VB.

Veja os Destaques e novidades do SUPER DVD Visual Basic 2013

(sempre atualizado) : clique e confira !

Quer migrar para o VB .NET ?

Veja mais sistemas completos para a plataforma .NET no

Super DVD .NET , confira...

Curso Bsico VB .NET Vdeo Aulas

Quer aprender C# ??

Chegou o Super DVD C# com exclusivo material de

suporte e vdeo aulas com curso bsico sobre C#.

Curso C# Basico Video Aulas

Gostou ? Compartilhe no Facebook Compartilhe no Twitter

Referncias:

Seo VB .NET do Site Macoratti.net

Super DVD .NET A sua porta de entrada na plataforma .NET
Super DVD Vdeo Aulas Vdeo Aula sobre VB .NET, ASP .NET e C#
Seo C# do site Macoratti.net
Seo Visual Basic 6 do site Macoratti .net

Jos Carlos Macoratti

http://www.macoratti.net/cbmd1.htm 10/10