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).
string,
idade:
integer,
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
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.
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
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
Funcionar
io
Departamen
to
Empregad
o
Superviso
Superviso
Supervison
Papi
s
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
Cidade
distribuio
Produto
do
modelo
conceitual
Entidade
Matrcul
a
Nome
Endere
o
sexo
Cliente
cp
f
Endere
o
NumLivr
o
Autor
* Assunto
*
matrcula
Logradou
ro
Cep
Bairr
o
Pessoa
Lotao
Departame
nto
FUNCION
RIO
Participa
n
Projetos
FUNCION
RIO
Gerencia
Departame
nto
(0,n
Pessoa
Lotao
(1,
Departame
nto
FUNCION
RIO
(1,n
Participa
(0,n
Projetos
FUNCION
RIO
(1,1
Gerencia
(0,1
Departame
nto
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)
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
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.
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
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
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.