Curso: Tecnologia em Informática para Negócios

Disciplina: BANCO DE DADOS

Aulas/semana: 04

Profª Ma. Luciana Zapparolli

Modelagem de Dados

1 de 40
Normalização de dados

2 de 40
 Atributos

Tipo;
Tamanho;
Ser obrigatório ou opcional;
Ser condicional a outros atributos;
Possuir várias ocorrências;

3 de 40
 Registro

Registro é um conjunto de atributos que contém informações comuns de

um determinado elemento (pessoa, evento, objeto, etc.). Um exemplo é o
registro de funcionários de uma empresa que contém informações
(atributos) específicos de cada funcionário como: nome, cargo, salário e
departamento que trabalha.

4 de 40
 Arquivo

Arquivo é um conjunto de registros que tratam do mesmo

assunto.

5 de 40
Chave

6 de 40
Chave – características

Única
Obrigatória
Imutável

7 de 40
 Normalização de Dados

Um bom projeto de banco de dados deve garantir ao usuário

a possibilidade de modificações no conteúdo do banco sem
causar efeitos colaterais inesperados.

8 de 40
 Normalização de Dados

O processo de normalização de dados se caracteriza por

refinar o esquema de banco de dados, buscando eliminar
problemas de redundâncias de dados e reduzir ao máximo os
problemas de anomalias de inclusão, alteração e exclusão de
dados, garantindo a integridade dos mesmos. Esse processo é
dividido em várias etapas, denominadas Formas Normais, que
são conjuntos de restrições às quais os dados devem
satisfazer (MACHADO,2014).

9 de 40
 1ª Forma Normal

Na primeira forma normal devemos identificar a chave da tabela, de

forma que não possua dados repetidos. Os atributos devem conter apenas
valores atômicos (não divisíveis), por exemplo, o CPF, este não pode ser
dividido em outros atributos. Os atributos também não podem ser
multivalorados, ou seja, não podem assumir diversos valores, por exemplo,
o atributo Fone de um cliente, que pode assumir diversos valores
(ALVES,2014).

10 de 40
 Dependência Funcional

• A dependência funcional é parcial quando em uma tabela tivermos

uma chave primária composta e um dos seus atributos depende
funcionalmente de apenas parte da chave, ou seja, depende de
apenas um ou mais atributos que compõem a chave, mas não de
todos e se ele for retirado a DF continuará existindo. A DF é total se
o atributo em questão dependa de todos os atributos que
compõem a chave (CARDOSO, 2008).

11 de 40
 Dependência Funcional

Dependência funcional é a característica de um

atributo depender de outro, ou de outros
atributos representarem uma informação
completa.
A dependência funcional pode ser verificada
quando analisamos um atributo isoladamente e
chegamos a conclusão de que ele por si só não
representa uma informação completa.

12 de 40
 Segunda Forma Normal (2FN)

A aplicação da segunda forma normal (2FN)

consiste em retirar das estruturas de dados que
possuem chaves compostas todos os atributos que
são funcionalmente dependentes de somente
alguma parte desta chave.

13 de 40
 Segunda Forma Normal (2FN)

A tabela se encontra na segunda forma normal

(2FN) se além de estar na primeira forma normal
(1FN) todos os seus atributos forem dependentes
da chave primária composta.

14 de 40
 Terceira Forma Normal (3FN)

A aplicação da terceira forma normal (3FN) consiste em

retirar das estruturas de dados os atributos que são
funcionalmente dependentes de outros atributos que não
sejam chaves, pois, caso exista atributos com dependência
funcional transitiva em uma tabela, estes podem também
causar anomalias de inclusão, alteração e exclusão.

15 de 40
 Terceira Forma Normal (3FN)

Uma tabela está na terceira forma normal (3FN)

caso esteja na segunda forma normal (2FN) e não
possua nenhum atributo dependente de outro que
não faça parte da chave primária.

16 de 40
 Aplicando as Formas Normais

Uma tabela está na terceira forma normal (3FN)

caso esteja na segunda forma normal (2FN) e não
possua nenhum atributo dependente de outro que
não faça parte da chave primária.

17 de 40
 Aplicando as Formas Normais

Vamos exemplificar estas técnicas através de uma

tabela de vendas de automóveis, onde os clientes
são empresas e compram frotas de automóveis. Em
uma primeira análise, foram levantados os
seguintes dados que necessitam ser armazenados
em um banco de dados.

18 de 40
 Aplicando as Formas Normais

 Número Venda;  Ano;

 Data da Venda;  Quantidade;
 Código do Cliente;  Preço unitário;
 Nome do Cliente;  Valor total;
 Endereço;  Código do vendedor;
 Cidade;  Nome do vendedor.
 UF;
 Código do Produto;
 Modelo automóvel;

19 de 40
 Aplicando as Formas Normais

Ao armazenar essas informações em um banco de dados,

ficariam assim:

20 de 40
 Aplicando as Formas Normais

Desta forma, podemos detectar as seguintes anomalias:

 O cliente está relacionado juntamente com a venda;

 Caso seja excluída uma venda da tabela, os dados do

cliente também serão excluídos;

 Se houver alteração do endereço do cliente por exemplo,

todas as linhas (registros) em que ele aparecer deverão
ser alteradas;

21 de 40
 Aplicando as Formas Normais

Desta forma, podemos detectar as seguintes anomalias:

 Se houver alteração do preço de um produto por exemplo,

ou qualquer outro atributo referente ao produto, todos os
registros que contem essa informação também deverão
ser alterados;

 Se houver alteração do nome do vendedor por exemplo,

todos os registros que contem essa informação também
deverão ser alterados;

22 de 40
 Aplicando as Formas Normais

Desta forma, podemos detectar as seguintes anomalias:

 A cada venda realizada a um determinado cliente, são

solicitadas todas as informações do mesmo, tais como:
endereço, cidade, uf;

23 de 40
 Aplicando as Formas Normais

Observamos que a tabela não está normalizada na primeira

forma normal (1FN), pois, o atributo Número da venda que
é a chave primária se repete e, isso não é permitido. Não
podemos também ter atributos multivalorados, que se
repetem, e em nosso exemplo temos os produtos.

24 de 40
 Aplicando as Formas Normais

Vamos aplicar a primeira forma normal (1FN) nesta tabela

não-normalizada e decompô-la em tantas unidades
quantas forem necessárias.

25 de 40
 Aplicando as Formas Normais

Inicialmente, vamos representar o esquema da tabela:

26 de 40
 Aplicando as Formas Normais

Inicialmente, vamos representar o esquema da tabela:

O atributo Número venda é a chave primária, está

sublinhado e em negrito.
27 de 40
 Aplicando as Formas Normais

Agora, vamos remover os atributos que se repetem, são eles:

Código do Produto, Modelo, Ano, Qtde, Preço Unitário e Valor
Total. O esquema das tabelas fica assim:

28 de 40
Aplicando as Formas Normais

29 de 40
 Aplicando as Formas Normais

Como podemos observar, na tabela Vendas, a chave

primária é o atributo Número Venda, é único para cada
registro, não se repete. A chave primária na tabela
Itens_Vendas é uma chave composta, formada pelos
atributos Número Venda e Código Produto.

30 de 40
 Aplicando as Formas Normais

Percebam que a tabela Itens_vendas, que foi derivada

no processo de normalização através da primeira forma
normal (1FN), herdou o atributo que é chave primária da
qual a tabela foi derivada (Vendas) e juntamente com o
atributo Código do Produto gerou uma chave primária
composta..

31 de 40
Aplicando as Formas Normais

Agora a nossa tabela Vendas está

normalizada na 1FN ! Não apresenta atributos
multivalorados, que se repetem e também o
atributo que é chave primária também não se
repete. Será que o resultado atende a segunda
forma normal (2FN) ?

32 de 40
 Aplicando as Formas Normais

Continuando com o nosso exemplo, vamos aplicar a

segunda forma normal (2FN).

A tabela Itens_vendas possui uma chave primária

composta, formada pelos atributos Número da Venda e
Código do Produto. Os atributos Modelo, Ano e Preço
Unitário não dependem totalmente da chave, já os atributos
Qtde e Valor Total dependem.

33 de 40
 Aplicando as Formas Normais

Desta forma, os atributos que são parcialmente

dependentes devem ser removidos do esquema.

Vamos remover os atributos que dependem parcialmente

da chave primária na tabela Itens_vendas e
consequentemente vamos gerar uma terceira tabela
denominada Produtos.

34 de 40
Aplicando as Formas Normais

35 de 40
Aplicando as Formas Normais

36 de 40
 Aplicando as Formas Normais

Agora a nossa tabela Vendas está

normalizada na 1FN e também na 2FN ! Não
apresenta atributos multivalorados, que se
repetem e o atributo que é chave primária
também não se repete. Os atributos que
dependem parcialmente da chave primária foram
removidos e foi gerada uma terceira tabela
(Produtos). Será que o resultado atende a terceira
forma normal (3FN)?

37 de 40
 Aplicando as Formas Normais

Em nosso exemplo, a tabela VENDAS possui atributos

que identificam um cliente, que são: nome, endereço, cidade
e UF e também um vendedor: nome do vendedor. Os dados
dos atributos do cliente, tais como: nome, endereço, cidade e
UF dependem do Código do Cliente, desta forma é possível
criar uma outra tabela, denominada Clientes. O atributo
nome do vendedor, depende do código do vendedor, então,
também é possível criar a tabela Vendedores.

38 de 40
Aplicando as Formas Normais

39 de 40
Aplicando as Formas Normais

40 de 40
 Aplicando as Formas Normais

Na maioria das vezes um projeto é normalizado até a

terceira forma normal (3FN), sendo considerado
suficiente para se obter um bom modelo. Refinar as
tabelas além da terceira forma normal pode não ser
aconselhável.

41 de 40
 Restrições de integridade considerando
o Modelo Relacional

Um banco de dados com informações imprecisas ou

mesmo totalmente errôneas pode causar resultados
catastróficos. Devido a este fato, uma das maiores
preocupações de qualquer desenvolvedor ou projetista
de banco de dados é encontrar uma forma de garantir a
integridade dos dados que se encontram armazenados.

42 de 40
 Restrições de integridade considerando
o Modelo Relacional

Se o próprio sistema de banco de dados oferecer

formas para restringir ou não tornar possível a quebra
dessas integridades, poderá gerar menos trabalho ao
desenvolvedor.
Um SGBD deve ajudar a evitar a entrada de
informações incorretas.

43 de 40
 Restrições de integridade considerando
o Modelo Relacional

As restrições de integridade (RI) são utilizadas para

garantir a consistência dos dados em um banco de
dados relacional.
Um SGBD impõe restrições de integridade, de forma
que ele permita somente o armazenamento de dados
válidos no banco de dados.

44 de 40
 Restrições de integridade considerando
o Modelo Relacional

Existem muitos tipos de restrições que podem ser

especificadas no modelo relacional, vamos abordar:
Integridade de chave e Integridade Referencial.

45 de 40
 Integridade de Chave

Uma restrição de chave primária permite diferenciar de

forma única os registros em uma tabela, ou seja,
impede que uma atributo que é chave tenha os seus
conteúdos repetidos.

46 de 40
 Integridade de Chave

Por exemplo, considerando uma tabela de Clientes com

os seguintes atributos: Código Cliente, Nome e idade,
sendo que o Código do Cliente é a chave primária,
Desta forma, podemos ter mais de um cliente com o
mesmo nome, porém, cada um deve apresentar um
código diferente.

47 de 40
Integridade de Chave

48 de 40
 Integridade Referencial

Muitas vezes, informações armazenadas em uma tabela

estão ligadas às informações armazenadas em outra tabela,
no entanto, se uma dessas tabelas for modificada a outra
deverá ser verificada e talvez até modificada para manter os
dados consistentes. Desta forma, uma restrição de
integridade deverá ser especificada caso o SGBD necessite
fazer esta verificação.

49 de 40
 Integridade Referencial

Exemplo:

50 de 40
 Integridade Referencial
Violações

Exemplo:

51 de 40
 Integridade Referencial
Violações

Exemplo: Tentar excluir o cliente Código 2

52 de 40