Modelo Relacional. Modelo Entidade-Relacionamento.

Formas
Normais

1. Introduo
Os Sistemas de gerenciadores de banco de dados (SGBD) surgiram no incio da dcada de 70,
com o objetivo de facilitar a programao de aplicaes, armazenando dados de forma eficiente,
obteno de consultas rpidas alm de manipular dados de forma concorrente.
Segundo (Korth, 2006), um banco de dados uma coleo de dados inter-relacionados,
representando informaes sobre um domnio especfico, ou seja, sempre que for possvel agrupar
informaes que se relacionam e tratam de um mesmo assunto, posso dizer que tenho um banco
de dados.
Baseado na definio de (Heuser, 2009), o projeto de um banco de dados usualmente ocorre em
trs etapas. A primeira etapa, a modelagem conceitual, procura capturar formalmente os
requisitos de informao de um banco de dados. A segunda etapa, o projeto lgico, objetiva
definir, em nvel de SGBD, as estruturas de dados que implementaro os requisitos identificados na
modelagem conceitual. A terceira etapa, o projeto fsico, define parmetros fsicos de acesso ao
BD, procurando otimizar a performance do sistema como um todo.
Os SGBDs Oracle, Mysql e Firebird so exemplos de bancos de dados relacionais.

1. Modelo Relacional
Em 1960 surgiu o primeiro Sistema Gerenciador de Banco de Dados
(SGBD) comercial, era baseado nos primitivos sistemas de arquivos
disponveis na poca, os quais no controlavam o acesso concorrente
por vrios usurios ou processos. Os SGBDs evoluram ao longo do
tempo criando novas estruturas de dados, ou modelos de dados.
Atualmente, os seguintes modelos de dados so normalmente utilizados
pelos SGBDs: modelo hierrquico, modelo em redes, modelo relacional
e o modelo orientado a objetos.
O modelo relacional atualmente o modelo mais utilizado em banco
de dados. Proposto inicialmente por Edgar Codd em 1970, revolucionou
o mercado desta rea e, apesar das novas tendncias de software como
orientao a objetos, continua sendo o modelo dominante no mercado
de banco de dados. Est baseado no princpio de que as informaes em
uma base de dados podem ser consideradas como relaes
matemticas (lgebra relacional).

Para compreender melhor o funcionamento de um banco de dados

relacional, necessrio conhecer alguns detalhes sobre a sua estrutura.
Os bancos de dados relacionais so compostos por (a)relao (b)
domnio, (c)atributo, (d)tupla e (e)chave.
a. Relao
Cada relao ou tabela ter um nome, que ser nico sendo
composta por atributos ou colunas e tuplas ou linhas.
Uma relao (tabela) consiste de um esquema e de uma instncia. O
esquema especifica o nome da relao e o nome e o domnio de cada
coluna, tambm denominada atributo ou campo da relao. O esquema
de uma relao invriavel ao longo do tempo, sendo modificado
apenas por comandos especficos. Um exemplo de esquema de relao
:
Funcionario (codigo: integer, nome:
codigoDepartamento: integer, salario: real).

string,

idade:

integer,

Neste caso est sendo definida a relao de nome Funcionario, com

atributos cdigo, nome, idade, codigoDepartamento e salario, cujos
domnios so respectivamente integer, string, integer, integer e real.
A instncia de uma relao o conjunto de linhas, tambm
denominadas tuplas ou registros, distintas entre si, que compem a
relao em um dado momento. Ela varivel, j que o nmero de tuplas
e o contedo de seus atributos podem variar ao longo do tempo. A
instncia de uma relao deve seguir sempre o seu respectivo esquema,
respeitando o nmero de atributos definidos, bem como os seus
domnios.
Esta restrio, denominada restrio de domnio, muito importante.
O modelo relacional somente considera relaes que satisfaam esta
restrio. Um exemplo de uma instncia para o esquema Funcionario
ilustrado na Figura 1.
codigo

nome

idade

55

Luiz

45

56
57

codigoDepartam
ento
12

salario
1500,00

cpf

005.001.03265
Marcos
37
12
2450,00
562.325.854.
98
Paulo
52
13
3241,15
123.254.658.
98
Figura 1 Exemplo de instncia da relao Funcionrio

O nmero de tuplas que uma dada instncia possui denomina-se

cardinalidade da relao e o nmero de atributos o seu grau. A
instncia de relao da Figura 1 tem cardinalidade 3 e grau 5. Note que
a cardinalidade varivel, mas o grau no.
b. Domnio
Conjunto de valores permitidos para um dado. O domnio do atributo
referenciado no esquema por seu nome e serve para restringir os
valores que este atributo pode assumir.
Exemplos
inteiro, string (domnios bsicos)
data, hora (domnios compostos)
- [0, 120], (M, F) (domnios definidos, como valores mnimos e
mximos e definio de caracteres especficos).
Para um domnio existem operaes vlidas
inteiro (somar, dividir, i maior que i, ...)
data (extrair dia, extrair ms, intervalo de datas, ...)
c. Atributo
Um atributo um item de dado do Banco de Dados e possui um
nome e um domnio. Todo atributo possui valor atmico e cada
atributo numa relao tem um nome que nico dentro da relao.
Exemplos
nome: string
idade: [0,120]

d. Tupla
Uma tupla uma linha de uma determinada instncia da relao. Esta
linha possui os valores dos atributos da tabela.
Exemplo:
tupla da relao Funcionario: {(codigo, 55), (nome, Luiz), (idade, 45),
(codigoDepartamento, 12), (salario, 1500,00), (cpf, 005.001.032-65)}.
e. Chave
Uma chave pode ser um ou mais atributos de uma relao. o conceito
usado para especificar restries de integridade bsicas de um BD
relacional.
Existem dois tipos de chave: (a) Chave Primria e (b) Chave Estrangeira.

a. Chave Primria (PK Primary Key)

A Chave Primria um atributo (Chave Primria Simples) ou uma
combinao de atributos (Chave Primria Composta) cujos valores
identificam unicamente uma tupla em uma relao. A notao para PK
de uma relao R: pk(R).
Um exemplo de Chave Primria Simples pode ser visualizado na tabela
funcionario mostrado na figura 1, tanto o atributo codigo quanto
cpf no se repetem, uma vez que esses atributos so nicos para cada
indivduo. Neste caso, qualquer um desses dois atributos poderia ser
definido como uma Chave Primria.
Uma Chave Primria Composta formada por dois ou mais atributos. Por
exemplo, suponha uma tabela chamada Localizao, e esta tabela tem
os seguintes atributos: nome da cidade, nome do estado, nome do
pas. Cada um desses atributos sozinhos no pode ser chave primria
porque eles se repetem, como mostra a figura abaixo.
nomeCidade
nomeEstado
nomePais
Paranavai
Parana
Brasil
Maringa
Parana
Brasil
Campo Grande
Mato Grosso do Sul
Brasil
Campo Grande
Rio de Janeiro
Brasil
Figura 2 Exemplo de Chave Primria Composta de uma tabela
Os atributos nomeCidade e nomeEstado juntos eles podem ser
uma Chave Primria, visto os valores resultantes da combinao destes
dois atributos no iro se repetir.
Apesar de no haver restrio quanto ao tipo de dados que ser uma
chave primria, recomenda-se o uso de chave primria em campos
numricos, em especial nmeros inteiros (que ocupam uma quantidade
menor de bytes). Isso se explica porque a comparao de valores
numricos mais rpida em relao ao uso de textos.
importante ressaltar que no existe mais de uma chave primria por
relao. Mesmo sendo uma chave composta, uma nica chave
primria composta por mais de um atributo.
b. Chave Estrangeira
Atributo(s) de uma relao R1 que estabelece(m) uma equivalncia
de valor com a chave primria de uma relao R2 (fk(R1) pk(R2)). A
notao para uma fk de uma relao R seria: fk(R).
Os domnios entre os atributos relacionados devem ser equivalentes.

Domnio(fk(R1)) = Dominio(pk(R2)), onde R1 e R2 podem ser a

mesma relao.
Exemplo:
Considere duas relaes: Funcionario e Departamento
Departamento
codigoDepartame
nto
11
12
13
14

nomeDepartame
nto
Administrativo
Financeiro
Contbil
Estoque

Funcionario
codigo

nome

idade

salario

cpf

45

codigoDepartam
ento
12

55

Luiz

1500,00

Marcos

37

12

2450,00

Paulo

52

13

3241,15

005.001.03265
562.325.854.
98
123.254.658.
98

56
57

Vamos considerar que o atributo codigoDepartamento da relao

Departamento seja a Chave Estrangeira da tabela. Neste caso o atributo
codigoDepartamento da relao Funcionario poderia ser uma chave
estrangeira, visto que este atributo possui equivalncia de valor com o
atributo Chave Primria de uma relao.

Restries de Integridade sobre Relaes

Um bom SGBD deve evitar a entrada de informao incorreta ou
inconsistente em sua base de dados, garantindo com isso a qualidade da
informao inserida. Uma Restrio de integridade (RI) uma condio
especificada no esquema da base de dados para restringir a informao
a ser armazenada. Ou seja, a RI uma condio definida que deve ser
verdadeira para qualquer instncia da base de dados. Se uma instncia
da base de dados satisfaz todas as RIs especificadas ento ela uma
instncia vlida.

O modelo relacional permite a especificao de vrios tipos de RIs.

Podemos citar a Restrio de Integridade de Chave, Restrio de
Integridade de Entidade, Restrio de Integridade Referencial e Restrio
de Domnio.
Restrio de Integridade de Chave: A restrio de chave serve para
garantir que as tuplas de uma relao sejam nicas.
Restrio de Integridade de Entidade: Nenhum valor de chave
primria poder ser NULO.
Restrio de Integridade Referencial: No modelo relacional comum que
a informao de uma relao esteja ligada informao de outra
relao. Se uma delas modificada a outra tambm deve ser checada e
modificada, se for o caso, de maneira a garantir a consistncia da
informao. Uma tupla em uma relao, que faz referncia a outra
relao, deve se referir a uma tupla existente nessa relao
Restrio de Domnio: As restries citadas acima so garantidas
automaticamente por um SGBD relacional. No exigido que o
programador escreva procedimentos para garanti-las explicitamente.
H muitas outras restries de integridade que no se encaixam nas
categorias bsicas. Estas restries so chamadas de restries de
domnio (ou regras do negcio). Exemplos de restries de domnio: Um
empregado do departamento denominado Finanas no pode ter a
categoria funcional Engenheiro; Um empregado no pode ter um
salrio maior que seu superior imediato.

2. Modelo Entidade-Relacionamento
O modelo ENTIDADE-RELACIONAMENTO (MER), foi apresentado por
Peter Chen em 1976. No MER, os elementos que o compe so
representados graficamente atravs da ferramenta denominada:
DIAGRAMA ENTIDADE-RELACIONAMENTO (DER).
No modelo Entidade Relacionamento existem trs pilares que o
compe: (a) Entidade, (b) Relacionamento e (c) Atributo.
a. Entidade
Entidade pode ser definida como aquele objeto que existe no mundo
real com uma identificao distinta e com um significado prprio. So
coisas que existem no negcio ou que ainda descrevem o negcio. Se
esses objetos existentes no negcio nos proporciona algum interesse
em mantermos dados (informaes) armazenados sobre ele, isto
caracteriza uma Entidade do negcio.
Uma entidade pode ser: concreta, abstrata ou eventos.
Imagine um posto de gasolina uma entidade concreta poderia ser a
bomba de combustvel, o carro a ser abastecido, o funcionrio do
posto, o combustvel entre outras coisas. Uma entidade abstrata
poderia ser a funo que um determinado funcionrio exerce na
empresa, um departamento, entre outras coisas. E por fim, uma
entidade do tipo evento poderia ser o prprio abastecimento,
pagamento de contas, recebimento de
contas entre outras coisas.
Heuser (2009) define uma Entidade como sendo um conjunto de
objetos da realidade modelada sobre as quais deseja-se manter
informaes no banco de dados.
Temos o termo Instancia de uma Entidade. Cada ocorrncia de uma
entidade denominada uma instncia da mesma. Por exemplo,
temos a entidade Cliente, uma instncia desta entidade seria uma
cliente em especfico, o Joo da Silva. Importante ressaltar que uma
instncia de uma entidade no ser representada no MER, somente
as Entidades.
A representao grfica de uma Entidade no DER se realiza atravs
de uma retngulo, com o nome da sua entidade no seu interior.
Ex:
Cliente

b. Relacionamento
Um relacionamento pode definido como um conjunto de associaes
entre ocorrncias de entidades.
Vamos exemplificar. Supondo que temos as Entidades: Funcionrio e
Departamento. Se pegarmos uma instncia da entidade Funcionrio
poderamos relacionar com uma instncia da Entidade Departamento.
Ento teramos que Joo da Silva (instancia da entidade funcionrio)

pertence ao departamento
departamento).

de

Estoque

(instancia

da

entidade

A representao grfica no DER para uma relacionamento o losango,

geralmente um nome definido para este relacionamento e inserido
dentro da figura. Ex:
Lotao

Funcionar
io

Departamen
to

Ento temos representado nesta Figura 1 duas entidades (Funcionario e

departamento) e um relacionamento (lotao).
Portanto, no relacionamento LOTAO, existe um par especfico formado
por uma ocorrncia de Funcionario e uma ocorrncia de Departamento.
Na Figura 2 podemos visualizar melhor alguns exemplos de pares deste
relacionamento.

Temos alguns tipos de relacionamentos, entre eles: auto-relacionamento,

relacionamento paralelo, relacionamento ternrio.
O auto-relacionamento representa uma associao entre ocorrncias de
uma mesma entidade. Neste tipo de relacionamento a identificao de
papis exigida.
Vejamos o exemplo da Figura 3:

Empregad
o

Superviso
Superviso
Supervison

Papi
s

Um empregado pode ser supervisionado por outro empregado.

Figura 4. Auto-relacionamento
Podemos visualizar melhor os pares na Figura 4, onde demostra o auto
relacionamento da Entidade Pessoa, em um momento uma ocorrncia
da entidade tem o papel de esposo e em outro de marido relacionados
pelo relacionamento do casamento.
Temos tambm o relacionamento paralelo, quando duas entidades
possuem dois relacionamentos diferentes entre si. Vejamos o exemplo
da figura 5, onde as Entidades Cidade e Eleitor podem se relacionar
atravs de dois relacionamentos distintos. Um eleitor pode votar em
uma cidade como tambm pode morar em uma cidade.
VOTAR
Eleitor

Cidade
MORAR

Figura 5. Relacionamento paralelo

E por fim, temos o relacionamento tercirio, onde trs entidades esto

ligadas com apenas um relacionamento. Vejamos o exemplo da figura 6.
Distribuido
r

Cidade

distribuio

Produto

Figura 6. Relacionamento tercirio

Neste exemplo podemos identificar que uma ocorrncia de distribuidor
pode distribuir um produto especfico (uma ocorrncia de produto) para
uma cidade (uma ocorrncia de cidade).
c. Atributo
Outro
conceito
importante
Relacionamento o Atributo.

do

modelo

conceitual

Entidade

Um atributo um dado que associado a cada ocorrncia de uma

entidade ou relacionamento. Na figura 7 podemos como os atributos so
representados no DER.
Aluno

Matrcul
a
Nome
Endere
o

Figura 7. Representao de atributos no DER.

Na figura acima visualizamos cada ocorrncia da entidade Aluno ter a
ela associada uma matrcula, um nome e um endereo.
Os atributos so propriedades que identificam as entidades e
relacionamentos. Uma entidade representado por um conjunto de
atributos. Eles podem ser: simples, composto, multivalorado, ou
identificador.
Atributo simples: no possui qualquer caracterstica especial. A maioria
dos atributos sero simples. Quando ele no se enquadra em nenhum
dos outros tipos de atributo ele ser considerado um atributos simples.
Ex: idade, sexo, salario, DataContratao, etc.
Aluno

sexo

Atributo Composto: um atributo composto, como o prprio nome j diz,

formado por vrios itens menores. Ex: Endereo. Este atributo poder
ser dividido em vrios outros atributos: Tipo Logradouro, Logradouro,
Numero, Cep e Bairro.

Cliente

cp
f

Endere
o

Atributo multivalorado: o seu contedo formado por mais de uma

valor. Ex: telefone, autor. Uma pessoa poder ter mais de um nmero de
telefone, um livro poder ter mais de um autor. indicado colocando um
asterisco na frente do nome do atributo.
Livro

NumLivr
o
Autor
* Assunto
*

Atributo Identificador: identifica de forma nica uma entidade, ou seja

no pode haver dados repetidos. Por exemplo um bom atributo
identificador da entidade Aluno, poderia ser o nmero de sua matrcula,
visto que um nmero nico para cada ocorrncia de Aluno, no
podendo haver duplicidade de dados. Pode ser indicado sublinhando o
nome do atributo. Estes tipos de atributos podero ser as chaves
primrias no banco de dados e seu uso tem implicaes na normalizao
de dados. Toda entidade deve ter um identificador que pode ser formado
por um ou um conjunto de atributos.
Aluno

matrcula

Para um melhor refinamento do modelo conceitual mapear as

restries.
O Esquema E-R de uma empresa pode definir certas restries, as quais
o contedo de banco de dados deve respeitar. Isso feito utilizando o
Mapeamento de Cardinalidade.
A cardinalidade define quantas ocorrncias de uma entidade podem
estar associadas a uma determinada ocorrncia atravs do
relacionamento. Temos as seguintes cardinalidades:
Cardinalidade mxima: defina a quantidade mxima de
ocorrncias de entidades que podem estar associadas a uma
ocorrncia da outra entidade (1 ou n), onde 1 somente uma
ocorrncia e n vrias.

Logradou
ro
Cep
Bairr
o

Cardinalidade mnima: define se a participao todas as

ocorrncias das entidades no relacionamento obrigatria ou
opcional (0 ou 1), onde 0 opcional e 1 obrigatrio.
Exemplos:
n

Pessoa

Lotao

Departame
nto

Figura 8. Exemplo de Cardinalidade mxima

FUNCION
RIO

Participa
n

Projetos

Figura 9. Exemplo de Cardinalidade mxima

FUNCION
RIO

Gerencia

Departame
nto

Figura 10. Exemplo de Cardinalidade mxima

Na figura 8 entendemos que uma ocorrncia de Pessoa pode estar

relacionada a apenas uma ocorrncia de Departamento, ou seja uma
pessoa poder estar lotada em apenas um departamento da empresa, j
um Departamento pode conter muitas Pessoas.
A figura 9 nos revela que um Funcionrios pode participar de muitos
projetos, e um projeto pode ter a participao de muitos Funcionrios.

A figura 10 nos diz que um Funcionrio pode gerenciar apenas um

Departamento e que um Departamento pode ser gerenciado por apenas
um Funcionrio.
A seguir veremos exemplos de cardinalidades mnimas e mximas.

(0,n

Pessoa

Lotao

(1,
Departame
nto

Figura 11. Exemplo de Cardinalidade mxima

FUNCION
RIO

(1,n

Participa
(0,n

Projetos

Figura 12. Exemplo de Cardinalidade mxima

FUNCION
RIO

(1,1

Gerencia

(0,1
Departame
nto

Figura 13. Exemplo de Cardinalidade mxima

Na figura 11 entendemos que uma ocorrncia de Pessoa deve estar
relacionada obrigatoriamente a apenas um Departamento, mas que um
Departamento pode conter no mnimo nenhuma pessoa (0) ou vrias
(n).

A figura 10 nos revela que um Funcionrios pode participar de nenhum

projeto ou de muitos projetos, j um projeto deve estar obrigatoriamente
associado a no mnimo um Funcionrio e no mximo vrios.
A figura 11 nos diz que um Funcionrio pode gerenciar nenhum
Departamento ou apenas um e que um Departamento pode ser
gerenciado por apenas um Funcionrio.
A abordagem Entidade Relacionamento a tcnica de modelagem mais
usada para nvel conceitual, sendo uma ferramenta de extrema
importncia para o mapeamento do modelo fsico de um banco de
dados.

3. Formas Normais
Normalizao de dados o processo formal e passo a passo que
examina os atributos de uma entidade, com o objetivo de evitar
anomalias observadas na incluso, excluso e alterao de registros.
O conceito de entidade muito importante neste processo, ou seja,
devemos identificar quais so as entidades que faro parte do projeto
de banco de dados.
O processo de normalizao aplica uma srie de regras e esto
divididas em trs etapas: Primeira Forma Normal (1FN), Segunda
Forma Normal (2FN) e Terceira Forma Normal (3FN). Quando o modelo
chegou na terceira forma normal o mesmo considerado
normalizado.
Vamos as regras.
Primeira Forma Normal:
Uma relao estar na primeira forma normal 1FN, se no houver grupo
de dados repetidos, isto , se todos os valores forem nicos. Em outras
palavras podemos definir que a primeira forma normal no admite
repeties ou atributos compostos ou multivalorados.
Os procedimentos mais recomendados para aplicar a 1FN so os
seguintes:
a)
b)
c)
d)

Identificar a chave primria da entidade;

Identificar os atributos compostos e transform-los em atributos simples.
Identificar atributos que so multivalorados e remov-los da entidade;
Criar uma nova entidade com os atributos identificados como
multivalorados 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.
Exemplo para Normalizar na 1FN:
Considere a relao cliente:
Cod_Cliente
001

Nome
Jose

Endereo
Rua x, 10
Morumbi
87701-000

Telefone
3252-1515
1525-1515

002

Maria

003

Joao

Rua Z, 25
So Jorge
87701-852
Rua M, 87
Oasis
87701-897

1414-1515
2535-9898
7878-9898
8745-8585

Analisando teremos:
1- Todos os clientes possuem Rua, Bairro e Cep e essas informaes
esto juntas no mesmo atributo, portanto existe uma atributo
composto, logo esta tabela no est na 1FN, para normalizar
deveremos colocar cada informao em um atributo simples,
teremos:
Cod_Clien
te
001

Nom
e
Jose

Endereo

Bairro

Cep

Telefone

Rua x, 10

Morumbi

002

Mari
a
Joao

Rua Z, 25

So Jorge

Rua M, 87

Oasis

87701000
87701852
87701897

3252-1515
1525-1515
1414-1515
2535-9898
7878-9898
8745-8585

003

2- Agora no existe mais nenhum atributo composto, porm o

atributo Telefone considerado um atributo multivalorado, pois
pode possuir mais de uma valor no mesmo atributo, ento esta
tabela ainda no est na 1FN. Para resolver devemos criar uma
nova tabela com a chave primria da entidade origem, veja o
como ficar.
Cod_Clien
te
001

Nom
e
Jose

Endereo

Bairro

Cep

Rua x, 10

Morumbi

002

Rua Z, 25

So Jorge

003

Mari
a
Joao

Rua M, 87

Oasis

87701000d
87701852
87701897

Cod_Clien

Telefone

te
001
001
002
002
003
003

3252-1515
1525-1515
1414-1515
2535-9898
7878-9898
8745-8585

Agora sim, tanto a primeira tabela quanto a segundo que foi criada
esto na 1FN.

Segunda Forma Normal

Uma relao esta na Segunda Forma Normal (2FN) se ela estiver na 1FN
e todos os atributos no chave forem totalmente dependentes da chave
primria (dependente de toda a chave e no apenas de parte dela).
Se o nome do produto j existe na tabela produtos, ento no
necessrio que ele exista na tabela de vendas. A segunda forma
normal trata destas anomalias e evita que valores fiquem em
redundncia no banco de dados.
Procedimentos:
a) A tabela deve estar na 1FN.
b) Todos os atributos no-chave so funcionalmente dependentes da
chave na sua totalidade e no apenas de parte da chave.
c) 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
removidos so funcionalmente dependentes.
Para exemplificar, considere as Tabelas abaixo:
Tabela Pedido
Num_Pedi
do
1001

Data_Pedi
do

Nome_Clie
nte
Maria

1002

Carla

1003

Carla

Cpf_Cliente
123.325.365
-00
251.321.321
-98
251.31.321-

1004

Paulo

98
854.321.321
-50

Tabela Pedido_Produto
Num_Pedi
do
1001
1001
1002
1003
1004

Cod_Produ Nome_Produto
to
1-934
Impressora
Laser
1-935
Impressora
Deskjet
1-935
Impressora
Deskjet
1-934
Impressora
Laser
1-925
Impressora
Wireless

Valor_Unita
rio
1.500,00

Quan
t
5

SubTotal

350,00

1.050,00

350,00

350,00

1.500,00

9.000,00

980,00

1.960,00

7.500,00

Analisemos:
1- Primeiro as tabelas esto normalizadas na 1 FN, pois no possuem
nenhum atributo composto ou multivalorado.
2- Segundo, verificamos na Tabela Pedido_Produto existem atributos
no chave que no dependem da chave primria na sua totalidade
(Num_Pedido e Cod_Produto). Por exemplo, o atributo
Nome_Produto e Valor_Unitario dependem do cdigo do produto,
mas no dependem de Num_pedido, portanto esta tabela no est
na segunda forma normal. Isto gera problemas com a
manuteno dos dados, pois se houver alterao no nome do
produto teremos que alterar em todos os registros da tabela
venda.
Para normalizar esta tabela teremos os de criar a tabela Produto, as
tabelas ficaro assim:
Tabela Pedido
Num_Pedi
do
1001

Data_Pedi
do

Nome_Clien
te
Maria

Cpf_Cliente
123.325.36500

1002

Carla

1003

Carla

1004

Paulo

251.321.32198
251.31.32198
854.321.32150

Tabela Pedido_Produto
Num_Pedi
do
1001
1001
1002
1003
1004

Cod_Produ
to
1-934
1-935
1-935
1-934
1-925

Quan
t
5
3
1
6

SubTotal
7.500,00
1.050,00
190,00
5.880,00

Tabela Produto
Cod_Produ Nome_Produto
to
1-934
Impressora
Laser
1-935
Impressora
Deskjet
1-936
Impressora
Matricial
1-925
Impressora
Wireless

Valor_Unita
rio
1.500,00
350,00
190,00
980,00

Terceira Forma Normal

Uma relao est na Terceira Forma Normal (3FN) se ela estiver na 2FN e
nenhum atributo no chave depende funcionalmente de nenhum outro
atributo no chave.
Procedimentos:
a) Primeiro as tabelas j esto na Segunda Forma Normal.

b) Segundo existem atributos no chave que dependem

funcionalmente de outro atributo no chave. Os atributos
Cpf_Cliente depende funcionalmente de um atributo no chave, o
Cliente, portanto esta tabela no est na terceira forma normal.
c) Devemos criar uma quarta tabela, Cliente

Tabela Pedido
Num_Pedi
do
1001

Data_Pedi
do

Cpf_Cliente
123.325.36500
251.321.32198
251.31.32198
854.321.32150

1002
1003
1004

Tabela Pedido_Produto
Num_Pedi
do
1001
1001
1002
1003
1004

Cod_Produ
to
1-934
1-935
1-935
1-934
1-925

Quan
t
5
3
1
6

SubTotal
7.500,00
1.050,00
190,00
5.880,00

Tabela Produto
Cod_Produ Nome_Produto
to
1-934
Impressora
Laser
1-935
Impressora
Deskjet
1-936
Impressora
Matricial
1-925
Impressora

Valor_Unita
rio
1.500,00
350,00
190,00
980,00

Wireless
Tabela Cliente
Cpf_Cliente
123.325.36500
251.321.32198
251.31.32198
854.321.32150

Nome_Clien
te
Maria
Carla
Carla
Paulo

Tabelas normalizadas na 3FN.

Pudemos observar que as dependncias funcionais e as formas normais
Permitem detectar e prevenir a redundncia e garantir a coerncia da
informao. Estabelecendo critrios de qualidade de desenho tanto no
modelo Entidade-Relacionamento quanto na construo do modelo
Relacional.

Concluses
Os Bancos de dados, cada vez mais, constituem um repositrio essencial para os dados e
informaes da empresa, sem os quais as operaes ficariam seriamente prejudicadas, ou mesmo
inviabilizadas. Portanto, a correta administrao dos bancos de dados so relevantes para o
sucesso das organizaes.

Bibliografia

HEUSER. Carlos, A. Projeto de Banco de Dados. Editora Bookman, 6ed. Rio de Janeiro, 2009.