M ODELAGEM C ONCEITUAL

1. Introduo ao Modelo Entidade-Relacionamento (MER)

Conforme comentado no captulo anterior, o sistema de banco de dados deve

prover uma viso abstrata de dados aos usurios, isolando-os de certos detalhes do
BD. A arquitetura desta abstrao se d em trs nveis. O mais externo, o nvel de
vises do usurio, descreve partes do banco que sero visualizadas pelos usurios.
No nvel intermedirio, tem-se o nvel conceitual (ou lgico), que descreve quais os
dados esto armazenados e seus relacionamentos. Finalmente, no nvel mais baixo,
est o nvel fsico, descrevendo a forma como os dados esto realmente
armazenados.

O foco deste captulo um aprofundamento das tarefas do nvel conceitual, atravs

da modelagem conceitual dos dados referentes ao negcio. O termo negcio refere-
se ao problema em questo que se deseja realizar uma modelagem. A inteno de
armazenar informaes de alunos numa escola, por exemplo, sugere que o negcio
seja Registro acadmico. Num outro exemplo, o negcio Instituio financeira
poder ser modelado tendo dados de correntistas e saldos.

Razes para a criao do modelo conceitual:

Descreve exatamente as informaes necessrias ao negcio. Para a
modelagem, todas as regras do negcio devero ser conhecidas e, cabe ao
projetista, traduzi-las em informaes relevantes ao banco;
Facilita a discusso, seja entre o projetista e o usurio ou entre o projetista e
sua equipe de trabalho;
Ajuda a prevenir erros do futuro sistema;
Uma forma de documentar o sistema ideal. Um sistema ideal quando todas
suas informaes esto modeladas de acordo com certas condies;
a base para o projeto fsico do banco de dados.

A abordagem utilizada aqui ser a representao de dados no modelo relacional,

utilizando-se, para tal, o Modelo de Entidade-Relacionamento (MER). O MER
um modelo baseado na percepo do mundo real, que consiste em um conjunto de
objetos bsicos chamados de entidades e nos relacionamentos entre esses objetos.
Foi proposto por Peter Chen, em 1976, como uma ferramenta de projeto de banco
de dados. O MER apresenta como contribuies um maior grau de independncia de
dados que os modelos convencionais (de redes e hierrquico) e uma unificao de
representao destes modelos, atravs do formalismo grfico do Diagrama de
Entidade-Relacionamento (DER).

PGINA 1 / 16
BANCO DE DADOS I

So caractersticas do MER:
Modela regras de negcio e no a implementao. A modelagem dos dados
requeridos para o negcio, baseado nas funcionalidades do sistema atual ou a
ser desenvolvido. Para modelar um negcio, necessrio conhecer em detalhes
sobre do que se trata.
Possui uma sintaxe robusta, bem definida;
Tcnica amplamente difundida e utilizada. Atualmente, a maioria dos bancos de
dados disponveis no mercado utiliza a abordagem relacional como modelo de
dados;
Diagramas fceis de entender e alterar.

Os objetivos de uma modelagem entidade-relacionamento so:

Obter todas as informaes requeridas sobre o negcio antes de sua
implementao, tornando claras suas dependncias;
Dentro do possvel, uma informao aparecer apenas uma vez no banco de
dados. Uma modelagem que prev o armazenamento de uma mesma
informao em dois locais diferentes, deixa o sistema vulnervel quanto a
possibilidade destas informaes no serem as mesmas. No caso de uma
inconsistncia dos dados, qual delas dever ser descartada?
Facilitar o projeto do banco de dados, possibilitando a especificao de sua
estrutura lgica.

2. Entidade e Instncia

Num MER, uma entidade um objeto, real ou abstrato, de relevncia para o

negcio. uma categoria de idias que so importantes ao negcio, as quais
devem ser traduzidas em informao. Dois importantes aspectos de uma entidade
que possui instncias e estas instncias tambm so de interesse ao negcio.
Pode-se considerar que uma instncia identifica individualmente uma entidade. O
quadro abaixo mostra alguns exemplos de entidades e instncias:

Entidade Instncia
Pessoa Joo, Jos, Antnio
Produto Prego 12x12, File de Peixe Merluza
Tipo de produto Plstico, papel, madeira
Tarefa Professor, pianista, gerente
Verso do documento 1.2, 10.5

QUADRO 2.1 EXEMPLOS DE ENTIDADES E INSTNCIAS

Observa-se que uma entidade possui vrias instncias e que cada instncia est
relacionada a uma entidade. Uma entidade representa um conjunto de instncias
que interessam ao negcio. Segue o exemplo abaixo:

Tarefa Em termos fsicos, uma entidade ser uma tabela do

BD e cada instncia ser uma linha (ou
Gerente registro ou tupla). Exemplo:

Porteiro Tabela Tarefa Entidade

Cdigo Descrio
Pianista 405 Gerente
Instncias
564 Porteiro
321 Pianista

PGINA 2 / 16
BANCO DE DADOS I

3. Atributo e Domnio

Um atributo tambm representa algo significativo ao negcio. Um atributo uma

propriedade de uma entidade. uma poro de informao que descreve,
quantifica, qualifica, classifica e especifica uma entidade. Normalmente, uma
entidade possui vrios atributos. Interessa, em termos de modelagem conceitual,
que estes atributos representem informaes relevantes ao negcio. Atributos
possuem valores (um nmero, um caracter, uma data, uma imagem, um som, etc),
chamados de tipos de dados ou formato. Para um atributo particular, todas suas
instncias possuem os mesmos formatos. O quadro abaixo apresenta exemplos de
entidades, instncias e atributos.

Entidade Instncia Atributo

Empregado Joo, Antnio Nome, idade, tamanho p, dependentes, cidade
Carro Escort, Gol Cor, preo, modelo
Tarefa Gerente Cdigo, Depto, Valor/hora, descrio
QUADRO 2.2 EXEMPLOS DE ENTIDADES, INSTNCIAS E ATRIBUTOS

Algumas questes:
O atributo Idade, da entidade Empregado, no parece ser uma boa escolha. O
ideal seria Data Nascimento, ficando o clculo da idade quando necessrio. O
armazenamento da informao idade de difcil, seno impossvel, atualizao;
O atributo Tamanho P, de Empregado, depender das regras de negcio.
Imaginando que a finalidade de entidade Empregado seja a de armazenar dados
sobre funcionrios numa empresa que fornea uniforme de trabalho, o atributo
coerente. Se a empresa no possui esta poltica, ele desnecessrio;
Uma importante deciso precisa ser tomada em relao a armazenar uma
informao como um atributo ou uma entidade. O atributo Cidade, de
Empregado, ter a cidade na qual o empregado reside. Se Cidade fosse uma
entidade, alguns possveis atributos seriam Populao, rea e Data Fundao.
Aqui, novamente a escolha passa pelas regras de negcio. Normalmente, uma
informao ser um atributo se for de natureza atmica e ser uma entidade
quando possuir informaes que possam (ou necessitem) ser relacionadas a
outras entidades.

Em termos fsicos, os atributos sero as colunas de uma tabela do

BD. Exemplo:

Tabela Empregado Colunas

Nome Idade
Joo 32
Antnio 25

Atributo monovalorado ou atmico: assume um nico valor, num certo instante

de tempo, para cada instncia. Exemplo: Nome, de Empregado

Atributo composto: formado por um ou mais sub-atributos. Exemplo: Cidade, de

Empregado. Cidade pode ser composto pelo nome da cidade e o estado.

Atributo multivalorado: assume diversos valores. Seu nome, normalmente, no

plural. Exemplo: Dependentes, de Empregado.

PGINA 3 / 16
BANCO DE DADOS I

Atributo determinante: identifica cada entidade como nica. Exemplo: Cdigo,

em Tarefa.

Domnio de um atributo: conjunto de valores possveis para um atributo.

Exemplo: Idade deve estar ente 18 e 60, Estado deve ser RS, RJ, SP, etc.

4. Relacionamentos

uma estrutura que indica uma associao entre duas ou mais entidades. Alguns
exemplos:

Entidade Relacionamento Entidade

Empregado Exerce Tarefa
Tarefa exercida por Empregado
Produto classificado por um Tipo Produto
Tipo Produto uma classificao de Produto
Pessoa Faz Reserva
Reserva feita por Pessoa

QUADRO 2.3 EXEMPLOS DE RELACIONAMENTOS

Empregado Tarefa

Joo Servente

Maria Cozinha
Portaria
Pedro Faxina
Sandra Pianista

Todos os empregados exercem tarefas;

Nenhum empregado tem mais de uma tarefa;
Nem todas as tarefas so exercidas por empregados;
Algumas tarefas so exercidas por mais de um empregado.

FIGURA 2.1 EXEMPLO DE RELACIONAMENTO ENTRE EMPREGADO-TAREFA

O exemplo anterior serviu para que sejam apresentadas algumas questes

referentes aos relacionamentos entre duas entidades. So elas:
1. Todo empregado DEVE (ou PODE) ter uma tarefa?
2. Toda tarefa DEVE (ou PODE) ser exercida por um empregado?
3. Um empregado pode exercer UMA ou MAIS tarefas? Ou ento: Uma tarefa
pode ser exercida por UM ou MAIS empregados?

Para as duas primeiras, a anlise do relacionamento de existncia (obrigatrio

DEVE ou opcional
PODE), enquanto que a terceira trata da cardinalidade do
relacionamento (um-para-um, um-para-vrios, vrios-para-um ou vrios-para-
vrios).

Um relacionamento entre duas entidades E1 e E2 deve ser lido da seguinte forma:

PGINA 4 / 16
BANCO DE DADOS I

Cada E1 {deve / pode} nome_do_relacionamento {um / vrios} E2

Existncia Cardinalidade

Existncia (Obrigatrio x Opcional)

Um relacionamento pode ser obrigatrio ou no. Se ele existe, diz-se que

obrigatrio. Se no existe, opcional. A existncia ou no de um relacionamento
identificada pelas palavras DEVE e PODE, por exemplo. Sem levar em conta a
cardinalidade, as possveis combinaes da relao de existncia entre as entidades
Empregado e Tarefa so (observar que a coluna Pode/Deve determinante da
existncia do relacionamento):

Pode Nome do Obrigatrio

E1 E2
Deve relacionamento Opcional
Cada Empregado Deve Exercer Uma/vrias Tarefas Obrigatrio
Cada Tarefa Deve Ser exercida por Um/vrios Empregados Obrigatrio
Cada Empregado Pode Exercer Uma/vrias Tarefas Opcional
Cada Tarefa Pode Ser exercida por Um/vrios Empregados Opcional

QUADRO 2.4 EXISTNCIA DE RELACIONAMENTOS

Cardinalidade

o nmero de entidades que podem estar associadas. Os relacionamentos binrios

podem ser: um-para-um (1:1), um-para-vrios (1:N) ou vrios-para-vrios (N:N).
Sem levar em conta a existncia, as possveis combinaes para a cardinalidade do
relacionamento entre as entidades Empregado e Tarefa so (observar que a coluna
de E2 determinante para a cardinalidade):

Pode Nome do
E1 E2 Cardinalidade
Deve relacionamento
Cada Empregado Deve/pode Exercer Uma Tarefa Um-para-um
Cada Tarefa Deve/pode Ser exercida por Um Empregado 1:1

Cada Empregado Deve/pode Exercer Uma Tarefa Um-para-vrios

Cada Tarefa Deve/pode Ser exercida por Vrios Empregados 1:N

Cada Empregado Deve/pode Exercer Vrias Tarefas Vrios-para-vrios

Cada Tarefa Deve/pode Ser exercida por Vrios Empregados N:N

QUADRO 2.5 CARDINALIDADE DE RELACIONAMENTOS

A cardinalidade um-para-um (1:1) ocorre quando uma instncia de E1 est

associada no mximo a uma instncia de E2 e uma instncia de E2 est associada
no mximo a uma instncia de E1.

E1 E2
A1 B1

A2 B2

FIGURA 2.2 CARDINALIDADE UM-PARA-UM

PGINA 5 / 16
BANCO DE DADOS I

A cardinalidade um-para-vrios (1:N) ocorre quando uma instncia de E1 est

associada a qualquer nmero de instncias de E2, enquanto que uma instncia de
E2 est associada no mximo a uma instncia de E1.

E1 E2
B1
A1
B2

B3
A2
B4

FIGURA 2.3 CARDINALIDADE UM-PARA-VRIOS

A cardinalidade vrios-para-vrios (N:N) ocorre quando uma instncia de E1

est associada a qualquer nmero de instncias de E2 e uma instncia de E2 est
associada a qualquer nmero de instncias de E1.

E1 E2
A1 B1

A2 B2
B3
A3

FIGURA 2.4 CARDINALIDADE VRIOS-PARA-VRIOS

5. O Diagrama Entidade-Relacionamento (DER)

A estrutura lgica geral de um banco de dados pode ser expressa graficamente por
um Diagrama de Entidade-Relacionamento. uma representao grfica do modelo
ou parte do modelo. De acordo com o grau de complexidade do negcio ou o nvel
de detalhamento impresso pelo projetista do banco, um modelo pode ser
representado por vrios diagramas.

Um DER utiliza-se de um nmero de elementos grficos. Infelizmente, no existe

uma padronizao na representao do diagrama. Sero apresentados dois
padres: um deles segundo Peter Chen e o outro uma pequena variao de um
desenvolvido pela Oracle.

Os componentes do Diagrama de Entidade-Relacionamento, de acordo com Peter

Chen so:

Retngulos: representam as entidades

Elipses: representam os atributos
Losangos: representam os relacionamentos
Linhas: ligam atributos a entidades e entidades a relacionamentos.

Exemplo de um DER envolvendo Empregados e Tarefas

PGINA 6 / 16
BANCO DE DADOS I

N Exerce 1
Empregado Tarefa

Cod_Emp Dependentes Cod_Tar

Nome Descrio
Endereo

Rua Cidade UF

FIGURA 2.5 EXEMPLO DE DER SEGUNDO PETER CHEN

Observa-se o seguinte:
So duas as entidades: Empregado e Tarefa
Atributos da entidade Empregado:
Cod_Emp (determinante - est sublinhado)
Nome (monovalorado)
Dependentes (multivalorado)
Endereo (composto)
Rua (monovalorado)
Cidade (monovalorado)
UF (monovalorado)
Atributos da entidade Tarefa:
Cod_Tar (determinante - est sublinhado)
Descrio (monovalorado)
O relacionamento entre Empregado e Tarefa possui cardinalidade 1:n

Uma variao do diagrama anterior apresentada a seguir. Nota-se que os

atributos determinantes no mais so sublinhados, pois possuem smbolos
diferentes dos demais.

N Exerce 1
Empregado Tarefa

Cod_Emp Cod_Tar Descrio

Nome Dependentes
Endereo

Rua UF
Cidade

FIGURA 2.6 UMA VARIAO DE DER

PGINA 7 / 16
BANCO DE DADOS I

A representao adotada neste texto, adaptada de uma desenvolvida pela Oracle,

ser apresentada por intermdio de um exemplo.

EMPREGADO
TAREFA
Cod_Emp possui Cod_Tar
Nome
Descrio
Endereo exercida por
Rua
Cidade
UF
Dependentes
Cod_Tar

FIGURA 2.7 DER ADAPTADO DO PADRO ORACLE

Sobre as entidades

So duas, Empregado e Tarefa, identificadas por letras maisculas. Abrigam os

atributos correspondentes.

Sobre os atributos

Aqueles determinantes (atributos chave) so sublinhados. Possuem a idia de

obrigatrios ou opcionais, identificados, respectivamente, pelos smbolos *
(asterisco) e o (crculo). Um atributo obrigatrio quando todas suas instncias
de sua entidade possuem a informao conhecida e disponvel, enquanto que
opcional quando pode ser desconhecida ou no disponvel ou, ainda, quando
conhecida, mas no muito importante para o negcio.

Sobre os relacionamentos

No possui um smbolo especfico para sua representao. A prpria linha de

ligao entre as entidades o relacionamento.

O nome do relacionamento colocado prximo ao ponto de partida da entidade.

Sentido L-se

Empregado  Tarefa Empregado possui Tarefa

Tarefa  Empregado Tarefa exercida por Empregado

QUADRO 2.6 NOMES DE RELACIONAMENTOS

A cardinalidade do relacionamento identificada pelas extremidades da linha. Do

lado do Empregado, o smbolo semelhante a um p de galinha na ponta representa
VRIOS, e, do lado da Tarefa, uma ponta simples representa UM. Do DER
apresentado, o relacionamento de 1:n.

Cada Empregado pode (ou deve) possuir UMA Tarefa

Cada Tarefa pode (ou deve) ser exercida por VRIOS Empregados

Em relao existncia do relacionamento, ele pode se obrigatrio ou opcional. Os

smbolos utilizados para esta identificao so, respectivamente, um trao cortando

PGINA 8 / 16
BANCO DE DADOS I

a linha do relacionamento (lado do Empregado) e um crculo sobre a linha (lado do

Depto).

Cada Empregado DEVE possuir uma Tarefa

Cada Tarefa PODE ser exercida por vrios Empregados

Os quadros seguintes mostram as possveis combinaes para relacionamentos

envolvendo a questo da existncia, com seus respectivos smbolos.

Relacionamento 1:n L-se

Cada E1 deve existir em vrios E2

Cada E2 deve existir em um E1

Cada E1 pode existir em vrios E2

Cada E2 deve existir em um E1

Cada E1 deve existir em vrios E2

Cada E2 pode existir em um E1

Cada E1 pode existir em vrios E2

Cada E2 pode existir em um E1

Relacionamento n:n L-se

Cada E1 deve existir em vrios E2

Cada E2 deve existir em vrios E1

Cada E1 deve existir em vrios E2

Cada E2 pode existir em vrios E1

Cada E1 pode existir em vrios E2

Cada E2 deve existir em vrios E1

Relacionamento 1:1 L-se

Cada E1 deve existir em um E2

Cada E2 deve existir em um E1

Cada E1 deve existir em um E2

Cada E2 pode existir em um E1

Cada E1 pode existir em um E2

Cada E2 deve existir em um E1

QUADRO 2.7 POSSVEIS RELACIONAMENTOS

PGINA 9 / 16
BANCO DE DADOS I

6. Projeto de chaves e Regras de Integridade

A questo fundamental do projeto de chaves numa modelagem eliminar ao

mximo os efeitos da redundncia. Uma chave um conjunto de um ou mais
atributos que, tomados coletivamente, permite identificar unicamente uma
entidade.

Numa entidade que contenha mais de uma chave, cada uma chamada de chave
candidata. Outros conceitos de chaves so relevantes neste contexto: chave
primria (primary key - pk), chave alternativa (alternate key -ak) e chave
estrangeira (foreign key - fk).

Chave primria: o conjunto de atributos que identificam unicamente uma

entidade. o mesmo conceito de atributo determinante, j explicado. Exemplo: a
figura 2.7 apresenta os atributos Cod_Emp e Cod_Tar como chaves primrias de
suas entidades. Pode-se imaginar, como outro exemplo, uma entidade ALUNO
contendo um atributo Nro de Matrcula. Este atributo uma chave primria
(primary key - pk), pelo fato de no existir dois alunos dentre os cadastrados com o
mesmo Nro de Matricula. Num BD, permitida apenas uma chave primria a cada
entidade.

Chave alternativa: tambm conhecida como chave secundria, aquela chave

candidata que no primria. De acordo com as regras do negcio, s vezes pode
ser conveniente identificar entidades por atributos que no so nicos dentre todas
as instncias. No exemplo da entidade ALUNO, um atributo Nome srio candidato
a ser uma chave alternativa (alternate key - ak). Desta forma, apesar de Nome no
garantir que todas as instncias sejam nicas por este atributo (uma mesma
pessoa pode estar matriculada em dois cursos. Assim, a chave primria Nro de
Matrcula nica dentre todos os alunos, mas Nome ter, pelo menos, em duas
instncias), as instncias de ALUNO podem ser recuperadas pela chave alternativa.
Pode-se ter tantas chaves alternativas quantas forem necessrias, numa mesma
entidade.

Chave estrangeira: so atributos de uma entidade cujos valores aparecem como

chave primria em outra entidade. A presena de uma chave estrangeira (foreign
key - fk) numa entidade ocorre por fora das regras de integridade referencial.

As regras de integridade num BD relacional so:

1 regra - Integridade de entidade: nenhum valor de uma chave primria pode

ser nulo. Em termos de DER, o atributo pk deve ser sempre obrigatrio, nunca
opcional.

2 regra - Integridade referencial: numa entidade que possui uma chave

estrangeira, cada valor desta chave s pode ser nulo ou igual a algum valor da pk
correspondente no relacionamento. As alteraes dos valores constituintes da pk ou
a remoo de uma instncia que contenha uma pk com uma fk associada em outra
entidade pode causar problemas de integridade referencial.

A figura 2.8 abaixo apresenta um DER e algumas instncias das entidades

envolvidas. Este exemplo servir para maiores explicaes sobre o projeto de
chaves e as regras de integridade da modelagem.

PGINA 10 / 16
BANCO DE DADOS I

EMPREGADO
TAREFA
Cod_Emp possui Cod_Tar
Nome
Descrio
Endereo exercida por
Rua
Cidade
UF
Dependentes
Cod_Tar

EMPREGADO TAREFA
Cod_Emp Nome Cod_Tar Cod_Tar Descrio
120 Jalson 77 42 Secretrio
343 Cleber 42 12 Office-boy
459 Lus 77 77 Contador
530 Marcela 77

FIGURA 2.8 DER ENTRE EMPREGADO-TAREFA

Questes sobre o exemplo:

Cod_Emp, de EMPREGADO e Cod_Tar, de TAREFA, so chaves primrias (pk)

Cod_Tar de EMPREGADO uma chave estrangeira (fk)
As pks so atributos obrigatrios. Pela primeira regra de integridade, portanto,
todas as instncias de EMPREGADO e de TAREFA devem estar com esta coluna
preenchida.
Neste caso, a fk um atributo obrigatrio porque a regra de existncia do
relacionamento diz que Cada empregado deve possuir uma tarefa. Poderia
ser opcional, caso o relacionamento fosse Cada empregado pode possuir uma
tarefa.
A remoo da instncia Secretrio, de TAREFA, ou a troca do contedo de
Cod_Tar, de TAREFA, de 42 para 39, por exemplo, causa problemas de
integridade referencial (segunda regra).
A remoo da instncia Office-Boy, de TAREFA, no fere a nenhuma regra de
integridade, porque no existe nenhuma instncia em EMPREGADO com fk=12.
Em relao a existncia do relacionamento do lado de TAREFA, o fato de ser
opcional (Cada Tarefa PODE ser exercida por vrios Empregados), faz que se
tenha instncias (Office-Boy) sem necessariamente estar associado a algum
empregado.

Uma anlise entre as chaves de entidades e cardinalidade dos relacionamentos

(1:1, 1:n ou n:n), leva-nos s seguintes observaes:

Num relacionamento 1:1, a fk deve estar em umas das entidades relacionadas.

Exemplo:

EMPREGADO
TAREFA
Cod_Emp possui
Cod_Tar
Nome exercida por
Descrio
Cod_Tar

PGINA 11 / 16
BANCO DE DADOS I

ou

TAREFA
EMPREGADO possui Cod_Tar
Cod_Emp exercida por
Descrio
Nome
Cod_Emp

Num relacionamento 1:n, a fk deve estar na entidade da direo VRIOS.

Exemplo:

EMPREGADO TAREFA
Cod_Emp possui Cod_Tar
Nome exercida por Descrio
Cod_Tar

Num relacionamento n:n, deve ser criada uma nova entidade contendo como pk
as pks das entidades relacionadas. Exemplo:

EMPREGADO TAREFA
Cod_Emp possui Cod_Tar
exercida por Descrio
Nome

EMPREGADO TAREFA
Cod_Emp possui exercida por Cod_Tar
Nome Descrio

EMPREGADO-TAREFA
Cod_Emp
Cod_Tar

PGINA 12 / 16
BANCO DE DADOS I

7. Normalizao e Regras para a confeco de DER

Conforme j comentado, o esquema de um banco de dados a estrutura geral do

BD e, este esquema, pode ser representado de uma forma textual ou grfica.
Normalmente, utiliza-se o DER para a representao grfica, ficando a textual como
uma opo mais simples e rpida no processo de normalizao dos dados.

Para uma modelagem conceitual de dados, necessrio um completo domnio das

regras de negcio, de modo que o modelo resultante reflita numa estrutura que
melhor represente os objetos envolvidos.

Tm-se duas alternativas para a criao de modelos conceituais: uma delas

atravs da normalizao de dados e, a outra, por umas regras bsicas de
identificao dos elementos do DER na idia geral do negcio.

Normalizao de Dados
Consiste em definir o formato lgico adequado s entidades identificadas no
negcio, com o objetivo de minimizar o espao utilizado pelos dados e garantir as
regras de integridade e a confiabilidade das informaes.
A normalizao feita atravs da anlise dos dados que compem as entidades,
utilizando um conceito chamado Formas Normais (FN). As FN so conjuntos de
restries nos quais os dados devem satisfaz-las. Pode-se dizer que a estrutura
est na primeira forma normal (1FN), se os dados que a compem satisfizerem as
restries definidas para esta etapa.
A normalizao completa dos dados feita seguindo as restries das trs formas
normais existentes, sendo que a passagem de uma FN para outra feita tendo
como base o resultado obtido na etapa anterior, ou seja, na FN anterior.
Para realizar a normalizao dos dados, so imprescindveis as definies dos
atributos chave a cada entidade e ser adotada a representao textual.
Como exemplo, criar um modelo conceitual para armazenar os dados de um
boletim escolar, conforme a figura 2.9 abaixo:

ESCOLA ESTADUAL BARO DE MACABAS www.eebm.com.br

Aluno: FRANCISCO JOS GUSMES LIMA Matrcula: 6969 Ano letivo: 2004
Endereo: RUA DAS ACCIAS, 465, CARREIROS, SO FIDLIS - RJ
Filiao: GERALDO TENRIO LIMA Curso: 45 INFORMTICA
FELICIA MARIA GUSMES LIMA Turno: DIURNO
NOTAS FALTAS
Disciplina Turma MF TA TF Cond.
I II III IV Ex I II III IV
13 - LGICA A 7,0 8,0 6,0 7,0 0 4 6 0 7,0 23 10 Aprov
08 - BDADOS C 5,0 4,0 9,0 8,0 8,0 3 3 0 0 6,9 35 9 Aprov

As notas I, II, III e IV referem-se aos quatro bimestres. A nota Ex a nota do exame
As faltas I, II, III e IV referem-se aos quatro bimestres.
MF a Mdia Final, TA o Total de Aulas dadas, TF o Total Faltas e Cond condio de aprovao

FIGURA 2.9 EXEMPLO DE UM BOLETIM ESCOLAR EMPREGADO-TAREFA

PGINA 13 / 16
BANCO DE DADOS I

Primeira Forma Normal (1FN)

Consiste em retirar da entidade os elementos repetitivos, ou seja, aqueles dados

que podem compor uma estrutura de vetor. Pode-se afirmar que uma entidade est
normalizada na 1FN, se no possuir atributos repetitivos.

Do exemplo, pode-se iniciar pensando numa nica entidade chamada BOLETIM,

com o seguinte esquema:

BOLETIM (Nome Escola, Http Escola, Nome Aluno, Nro

Matrcula, Ano Letivo, Endereo, Pai, Me, Cod
Curso, Nome Curso, Turno, Relao de
Disciplinas (Cod Disc, Nome Disc, Turma,
Relao de Notas (I, II, III, IV, Ex), Relao de
Faltas (I, II, III, IV), MF, TA, TF, Cond)).

necessria a definio de uma pk para BOLETIM. Como o assunto trata de

boletins escolares e cada aluno possui um, o atributo Nro Matricula apresenta-se
como um forte candidato a chave primria.

Da entidade, observa-se que existem vrias disciplinas para cada aluno, sendo,
portanto, elementos repetitivos que devero ser retirados. Ento, a primeira forma
normal ser:

BOLETIM (Nome Escola, Http Escola, Nome Aluno, Nro

Matrcula, Ano Letivo, Endereo, Pai, Me, Cod
Curso, Nome Curso, Turno)

MATRICULA (Nro Matrcula, Cod Disc, Nome Disc, Turma,

Relao de Notas (I, II, III, IV, Ex), Relao
de Faltas (I, II, III, IV), MF, TA, TF, Cond))

Como resultado desta etapa, ocorre um desdobramento dos atributos da entidade,

a saber:
Em BOLETIM, foram extrados os atributos repetidos;
Em MATRICULA, os atributos foram os extrados de BOLETIM, tendo como chave
primria Nro Matrcula e Cod Disc. Esta pk, em MATRICULA, nica.

Em MATRICULA, nota-se ainda uma repetio de notas e de faltas, que podero dar
origem a novas entidades. Por uma deciso de projeto, as entidades ficam:

BOLETIM (Nome Escola, Http Escola, Nome Aluno, Nro

Matrcula, Ano Letivo, Endereo, Pai, Me, Cod
Curso, Nome Curso, Turno)

MATRICULA (Nro Matrcula, Cod Disc, Nome Disc, Turma,

MF, TA, TF, Cond)

NOTA e FALTA (Nro Matrcula, Cod Disc, Id Bimestre,

Nota, Falta)

PGINA 14 / 16
BANCO DE DADOS I

Aqui, mais uma vez, a nova entidade NOTA e FALTA tem sua pk composta da pk de
MATRICULA acrescentada de Id Bimestre, uma identificao do bimestre.

Segunda Forma Normal (2FN)

Consiste em retirar, das entidades que possuem chaves compostas (atributo chave
formado por mais de um atributo), os atributos que so funcionalmente
dependentes de parte da chave. Pode-se afirmar que, uma entidade est na 2FN,
se estiver na 1FN e no possuir atributos funcionalmente dependentes de parte da
chave.

(1FN) BOLETIM (Nome Escola, Http Escola, Nome Aluno, Nro

Matrcula, Ano Letivo, Endereo, Pai, Me, Cod
Curso, Nome Curso, Turno)

MATRICULA (Nro Matrcula, Cod Disc, Nome Disc, Turma,

MF, TA, TF, Cond)

NOTA e FALTA (Nro Matrcula, Cod Disc, Id Bimestre,

Nota, Falta)

A ltima configurao das entidades as apresenta na 1FN. Pode-se notar

MATRCULA como a nica entidade que possui uma pk composta com atributos
dependentes (Nome Disc depende de Cod Disc). A segunda forma normal, ento,
define:

BOLETIM (Nome Escola, Http Escola, Nome Aluno, Nro

Matrcula, Ano Letivo, Endereo, Pai, Me, Cod
Curso, Nome Curso, Turno)

MATRICULA (Nro Matrcula, Cod Disc, Turma, MF, TA, TF,

Cond)

DISCIPLINA (Cod Disc, Nome Disc)

NOTA e FALTA (Nro Matrcula, Cod Disc, Id Bimestre,

Nota, Falta)

Da ao da 2FN, tem-se:
Surgiu a nova entidade DISCIPLINA, tendo como pk parte da pk do atributo
originrio constante na dependncia.
O atributo Nome Disc foi excludo de MATRICULA por ser dependente de Cod
Disc.

PGINA 15 / 16
BANCO DE DADOS I

Terceira Forma Normal (3FN)

Consiste em retirar os atributos que so funcionalmente dependentes de outros

atributos que no so chaves. Pode-se afirmar que, uma entidade est na 3FN, se
estiver na 2FN e no possuir atributos dependentes de outros atributos no chaves.

(2FN)
BOLETIM (Nome Escola, Http Escola, Nome Aluno, Nro
Matrcula, Ano Letivo, Endereo, Pai, Me, Cod
Curso, Nome Curso, Turno)

MATRICULA (Nro Matrcula, Cod Disc, Turma, MF, TA, TF,

Cond)

DISCIPLINA (Cod Disc, Nome Disc)

NOTA e FALTA (Nro Matrcula, Cod Disc, Id Bimestre,

Nota, Falta)

(3FN)
BOLETIM (Nro Matrcula, Nome Aluno, Endereo, Pai,
Me, Cod Curso, Turno)

CURSO (Cod Curso, Nome Curso)

MATRICULA (Nro Matrcula, Cod Disc, Turma, MF, TA, TF,

Cond)

DISCIPLINA (Cod Disc, Nome Disc)

NOTA e FALTA (Nro Matrcula, Cod Disc, Id Bimestre,

Nota, Falta)

A ao da 3FN provocou poucas alteraes; surgiu uma nova entidade CURSO e o

atributo Nome Curso, de BOLETIM, foi eliminado. Os demais ajustes foram em
decorrncia de uma melhoria da modelagem. So eles:
Atributo Ano Letivo foi eliminado do modelo por no se relacionar com nenhuma
entidade existente. Em termos prticos, pode-se imaginar que todos os dados
referentes ao ano letivo fiquem armazenados em BD diferentes, mas com a
mesma estrutura (um BD para o ano 2001, outro para 2002, ...).
Os dados da escola no so relevantes nesta modelagem porque so
constantes, ou seja, so iguais a todos os boletins.

PGINA 16 / 16