E-book 2 Estrutura e Modelagem de Dados

Prévia do material em texto

ESTRUTURA E 
MODELAGEM 
DE DADOS
E-book 2
 César Torres Fernandes 
Neste E-Book:
INTRODUÇÃO�������������������������������������������4
MODELO RELACIONAL �������������������������� 5
CONCEITOS ��������������������������������������������������������5
TABELAS �����������������������������������������������������������10
TIPOS DE CHAVES �������������������������������� 12
ÍNDICES ��������������������������������������������������� 13
REGRAS DE INTEGRIDADE ����������������� 14
MAPEAMENTO DO MODELO ER 
PARA O MO,DELO RELACIONAL ������� 15
NORMALIZAÇÃO �����������������������������������23
PRIMEIRA FORMA NORMAL ��������������26
SEGUNDA FORMA NORMAL ��������������28
TERCEIRA FORMA NORMAL ������������� 30
FORMA NORMAL DE BOYCE / 
CODD �������������������������������������������������������32
QUARTA FORMA NORMAL ���������������� 34
QUINTA FORMA NORMAL ������������������35
2
DESNORMALIZAÇÃO ���������������������������36
CONSIDERAÇÕES FINAIS ��������������������39
SÍNTESE �������������������������������������������������� 40
3
INTRODUÇÃO
Neste módulo, estudaremos os sistemas de bancos 
de dados relacionais, o mapeamento entidade-rela-
cionamento para o modelo relacional e a aplicação 
da normalização de dados� 
4
MODELO RELACIONAL
Aqui, conheceremos um pouco sobre o modelo 
relacional e seu componente básico� Além disso, 
conheceremos as relações e a estruturação lógica 
composta de linhas e colunas�
CONCEITOS 
Criado por Edgar Frank Codd no início dos anos 1970, 
o modelo relacional baseia-se no princípio de que 
as informações em uma base de dados podem ser 
consideradas como relações matemáticas e que são 
representadas por meio do uso de tabelas bidimen-
sionais (linhas e colunas), conforme ilustrado na 
Figura 1, colocando assim os dados em estruturas 
simples de armazenamento e nas quais a visão do 
usuário é privilegiada�
Figura 1: Exemplo de tabela bidimensional. Fonte: Elaboração pró-
pria.
Formalmente, podemos conceituar o modelo rela-
cional com base em conceitos matemáticos relacio-
nados à Teoria de Conjuntos, bem como à Lógica de 
Predicados� Para evitar nos aprofundarmos em con-
ceitos matemáticos, podemos pensar uma Relação 
5
como uma matriz composta de linhas e colunas, 
sendo que as linhas (ou tuplas) e cada coluna repre-
sentam um atributo� As operações sobre elas são 
feitas por linguagens declarativas, que manipulam 
a álgebra relacional (também criada por E� F� Codd), 
como é o caso da linguagem SQL�
Podcast 1 
A implementação do Modelo Relacional é realiza-
da pelos Sistemas de Gerenciamento de Banco de 
Dados Relacionais (SGBDR ou Relational Database 
Management System – RDBMS)� Esse tipo de SGBD 
tem a capacidade de ocultar a complexidade do mo-
delo para o usuário final. Este, por seu turno, pode 
manipular e consultar, de maneira lógica e intuitiva, 
os dados armazenados em uma coleção de tabelas�
A ascensão do modelo relacional e dos sistemas 
de gerenciamento de banco de dados relacionais 
ocorreu, principalmente, pelos seguintes motivos:
 ● Independência total dos dados (sua estrutura 
lógica)�
 ● Visão múltipla dos dados�
 ● Comunicação mais fluida entre o departamento e 
profissionais de TI e usuários.
 ● Redução acentuada na atividade de desen-
volvimento de aplicações e o tempo gasto em 
manutenção�
6
https://famonline.instructure.com/files/407282/download?download_frd=1
 ● Melhoria na segurança dos dados e mais agili-
dade na questão gerencial da informação ligada ao 
processo decisório da organização�
 ● Utilização da linguagem de programação declara-
tiva, adotada pela maioria dos sistemas de geren-
ciamento de banco de dados relacionais, SQL, que 
permite ao usuário especificar o que deve ser feito 
sem especificar como deve ser feito.
Pensando na linguagem SQL, qualquer aplicação 
para o banco de dados relacional baseado na lin-
guagem SQL envolve três partes:
1. Interface de usuário: permite ao usuário interagir 
com os dados utilizando a linguagem SQL�
2. Coleção de tabelas armazenadas: todos os da-
dos são percebidos como dados armazenados em 
tabelas, apresentando ao usuário final os dados de 
maneira fácil de entender�
3. Mecanismo SQL: o mecanismo SQL executa to-
das as consultas e demais operações solicitadas 
pelo usuário final.
Ao definir o modelo relacional, Edgar F. Codd es-
tabeleceu um conjunto de 12 regras para determi-
nar a aderência de um SGBD ao modelo relacional 
(MACHADO; ABREU, 2004)� Essas regras podem ser 
aplicadas em qualquer sistema de banco de dados 
que gerencia dados armazenados usando apenas 
seus recursos relacionais� Essa é uma regra básica 
7
que atua como base para todas as outras regras� 
Observe as 12 regras:
1. Regra de informação: dados armazenados em um 
banco de dados, sejam eles do usuário ou metada-
dos, devem ser o valor de alguma célula da tabela� 
Tudo em um banco de dados deve ser armazenado 
em um formato de tabela�
2. Regra de acesso garantido: a garantia de que 
cada elemento de dados (valor) seja acessível logi-
camente com uma combinação de nome da tabela, 
chave primária (valor da linha) e nome do atributo 
(valor da coluna)� Nenhum outro meio, como pon-
teiros, pode ser usado para acessar os dados�
3. Tratamento sistemático de valores nulos: os valo-
res NULL em um banco de dados devem receber um 
tratamento sistemático e uniforme� Trata-se de uma 
regra muito importante, visto que um NULL pode ser 
interpretado como um dos seguintes: dados estão 
faltando, dados não são conhecidos ou dados não 
são aplicáveis�
4. Catálogo online ativo: a descrição da estrutura 
de todo o banco de dados deve ser armazenada em 
um catálogo online, conhecido como dicionário de 
dados, o qual pode ser acessado por usuários autori-
zados� Os usuários podem usar a mesma linguagem 
de consulta para acessar o catálogo que eles usam 
para acessar o próprio banco de dados�
Podcast 2 
8
https://famonline.instructure.com/files/407283/download?download_frd=1
5. Regra abrangente de subidioma de dados: um 
banco de dados só pode ser acessado por meio 
de uma linguagem com sintaxe linear que suporte 
operações de definição de dados, manipulação de 
dados e gerenciamento de transações� Essa lingua-
gem pode ser usada diretamente ou por intermédio 
de alguma aplicação� Se o banco de dados permitir 
acesso aos dados sem nenhuma ajuda dessa lin-
guagem, será considerado uma violação�
6. Exibir regra de atualização: todas as visualiza-
ções de um banco de dados, que teoricamente po-
dem ser atualizadas, também devem ser atualizáveis 
pelo sistema�
7. Regra de inserção, atualização e exclusão de alto 
nível: um banco de dados deve suportar inserção, 
atualização e exclusão de alto nível� Isso não deve 
ser limitado a uma única linha, ou seja, também deve 
suportar operações de união, interseção etc. a fim 
de gerar conjuntos de registros de dados�
8. Independência de dados físicos: os dados ar-
mazenados em um banco de dados devem ser in-
dependentes dos aplicativos que acessam o banco 
de dados� Qualquer alteração na estrutura física de 
um banco de dados não deve afetar a maneira como 
os dados estão sendo acessados por aplicativos 
externos�
9. Independência de dados lógicos: os dados lógi-
cos em um banco de dados devem ser independen-
tes da visão do usuário (aplicativo)� Qualquer altera-
ção nos dados lógicos não deve afetar os aplicativos 
9
que os utilizam� Por exemplo, se duas tabelas são 
mescladas ou uma é dividida em duas tabelas di-
ferentes, não deve haver impacto ou alteração no 
aplicativo do usuário� Essa é uma das regras mais 
difíceis de aplicar�
10. Independência da integridade: um banco de 
dados deve ser independente do aplicativo que o 
utiliza� Todas as restrições de integridade podem 
ser modificadas de maneira independente, sem a 
necessidade de qualquer alteração no aplicativo� 
Esta regra torna um banco de dados independente 
do aplicativo front-end, assim como de sua interface�
11. Independência da distribuição: o usuário final 
não pode visualizarque os dados estão distribuídos 
por vários locais� Os usuários devem ter a impres-
são de que os dados estão sempre localizados em 
apenas um website� Essa regra foi considerada a 
base dos sistemas de banco de dados distribuídos�
12. Regra de não subversão: se um sistema tiver uma 
interface que forneça acesso a registros de baixo 
nível, ela não poderá subverter o sistema tampouco 
ignorar restrições de segurança e integridade�
TABELAS
No geral, em um modelo relacional as tabelas têm 
características como (ROB; CORONEL, 2011):
 ● Uma tabela é percebida como uma estrutura bidi-
mensional composta por linhas e colunas�
10
 ● Cada linha da tabela (tupla) representa uma ocor-
rência da entidade única dentro do conjunto de 
entidades�
 ● Cada coluna da tabela representa um atributo, e 
cada coluna tem um nome distinto�
 ● Cada interseção de linha / coluna representa um 
único valor de dados�
 ● Todos os valores em uma coluna devem estar em 
conformidade com o mesmo formato de dados�
 ● Cada coluna possui um intervalo específico de 
valores conhecido como domínio do atributo�
 ● A ordem das linhas e colunas é irrelevante para 
o SGBD�
 ● Cada tabela deve ter um atributo ou uma combi-
nação de atributos que identifique exclusivamente 
cada linha�
11
TIPOS DE CHAVES
Uma chave designa o conceito lógico de item de 
busca, ou seja, um dado que será empregado nas 
consultas à base de dados� A partir disso, podemos 
definir os seguintes tipos de chaves:
 ● Superchave: determina funcionalmente todos os 
atributos de uma linha, ou seja, a superchave é qual-
quer chave que identifique exclusivamente cada 
linha de uma tabela�
 ● Chave candidata: descrita como uma superchave 
sem atributos desnecessários (superchave mínima), 
ou seja, os identificadores são candidatos a chave 
primária�
 ● Chave primária (primary key): atributo de uma ta-
bela que identifica exclusivamente uma tupla (linha)�
 ● Chave secundária (secundary key): serve para de-
finir uma chave usada estritamente para recuperar 
dados� No modelo relacional, uma tabela é acessível 
a qualquer atributo, independentemente de este ser 
declarado como chave ou não�
 ● Chave estrangeira (foreign key): são elos entre 
tabelas� Quando dizemos que duas tabelas estão re-
lacionadas por meio de atributos comuns, devemos 
observar que provavelmente essa coluna em uma 
das tabelas é uma chave primária e, na outra tabela, 
esse atributo vai caracterizar o que é denominado 
chave estrangeira, propiciando assim uma ligação 
lógica (relacionamento) entre as tabelas�
12
ÍNDICES
Índices são um recurso físico que visam a otimizar 
a recuperação de uma informação, via um método 
de acesso� Têm como principal objetivo melhorar 
o desempenho de um sistema� Um atributo-chave 
pode ser utilizado como índice, mas um índice não 
é necessariamente uma chave� A forma de criação 
do índice depende do ambiente relacional�
Do ponto de vista conceitual, um índice compõe-se 
de uma chave de índice e um conjunto de ponteiros� 
A chave do índice é, com efeito, o ponto de referência 
do índice� Mais formalmente, um índice é um arranjo 
ordenado de chaves e ponteiros, em que cada chave 
aponta para a localização dos dados identificados 
pela chave�
13
REGRAS DE INTEGRIDADE
As regras de integridade de um modelo de banco de 
dados relacional são importantes para um projeto 
de banco de dados, pois garantem a confiabilida-
de das informações contidas no banco de dados 
(MACHADO; ABREU, 2004)� As regras são:
 ● Integridade de entidade: a chave primária não 
pode conter um valor nulo (NULL)� O valor nulo não é 
o valor zero nem o caractere branco, é simplesmente 
a não existência de conteúdo neste campo�
 ● Integridade referencial: se a Tabela A possui uma 
chave estrangeira, a qual é chave primária em outra 
Tabela B, então ela deve ser igual a um valor de cha-
ve primária existente em B, ou ser nula (NULL)� Não 
pode existir na chave estrangeira um valor que não 
exista na tabela na qual ela é chave primária, ou seja, 
todo valor de chave estrangeira não nulo deve fazer 
referência a um valor de chave primária existente�
Sendo assim, podemos determinar que, no Modelo 
Relacional, uma tabela será acessível por qualquer 
campo (atributo) independente se esse campo é 
declarado como chave ou não� Ainda, que o rela-
cionamento entre conjunto de dados (tabelas) não 
existe fisicamente, pois o relacionamento é apenas 
lógico e representado por chaves estrangeiras� Por 
fim, que a maioria dos SGBDR se utiliza de lingua-
gens autocontidas e não procedurais, como o SQL 
e que os ambientes relacionais têm um otimizador 
estratégico para escolher o melhor caminho para 
recuperação dos dados�
14
MAPEAMENTO DO MODELO 
ER PARA O MO,DELO 
RELACIONAL
Conforme observam Machado e Abreu (2004), no 
projeto de banco de dados, temos a necessidade de 
passar as visões do modelo conceitual para o mo-
delo lógico relacional, no qual os dados são vistos 
como estruturas de dados voltadas às caracterís-
ticas do modelo lógico escolhido, visando à imple-
mentação do banco de dados�
Para a realização de tal tarefa, temos que utilizar 
um conjunto de regras de conversão denominado 
mapeamento do Modelo ER para o Modelo Relacional 
e, necessariamente, observar as características do 
SGBD destino�
 ● Mapeamento das Entidades: toda entidade do mo-
delo ER torna-se uma tabela no Modelo Relacional, 
da mesma forma que os atributos da entidade se 
tornam campos da tabela criada� A chave primária e 
as chaves candidatas são projetadas para elas não 
permitirem ocorrências múltiplas nem admitirem os 
nulos� Em relação às entidades fracas, as chaves 
são formadas pelos atributos indicados, precedidos 
pelos atributos que compõem a chave primária das 
entidades da qual ela é fraca�
 ● Mapeamento dos Atributos: atributos das enti-
dades e relacionamentos devem ser gerados de 
maneira a minimizar o consumo de espaço de ar-
15
mazenamento e tornar mais eficiente a recuperação 
dos dados� Todas as características de SGBD em 
uso devem ser exploradas; para tanto, é preciso 
considerar se os campos têm ou não a especificação 
de extensão em bytes, se há localização no interior 
do registro que propicie vantagens na recuperação 
e se há compactação de espaços não ocupados�
 ● Mapeamento dos Relacionamentos: em relação ao 
mapeamento dos relacionamentos, temos que as 
alternativas possíveis são divididas em dois grandes 
grupos, a saber:
1. Navegação incorporada: trabalha em consonância 
com o conceito de chave estrangeira�
2. Navegação disjunta: trabalha sem a modificação 
das definições dos registros já existentes, criando 
registros (entidades) diferentes das existentes, as 
quais têm a finalidade de propiciar a navegação.
No que tange ao mapeamento dos relacionamen-
tos, temos que analisar todos os tipos de relaciona-
mentos existentes, caso a caso (MACHADO; ABREU, 
2004):
 ● Relacionamento 1:N (entidades distintas): a en-
tidade (tabela) cuja conectividade é N carrega o 
identificador da entidade (tabela) cuja conectividade 
é 1 (chave estrangeira), e os atributos do relaciona-
mento, se houver, tal qual observada na Figura 2:
16
Tem
(1,n)(1,1)
cod_dep
Departamento cod_func
(1,n)(1,1)
Funcionário
Modelo Entidade-Relacionamento 1:N
Modelo Relacional 1:N
Departamento
 cod_dep: Texto (1)
Departamento
 cod_func: Texto (1)
 cod_dep: Texto (1)
Figura 2: Tabelas distintas com relacionamento 1:N. Fonte: Adaptada 
de Machado e Abreu (2004).
 ● Relacionamento 1:N (autorrelacionamento): a cha-
ve primária da entidade é incluída na própria entida-
de como chave estrangeira, gerando uma estrutura 
de acesso a partir da chave estrangeira (Figura 3):
Compõe
(0,1)
(0,n)
cod_peca
Peça
Modelo Entidade-Relacionamento 1:N (autorrelacionamento)
Modelo Relacional 1:N (autorrelacionamento)
Peça
 cod_peca: Text...
 cod_peca_FK: Te...
Figura 3: Tabela com relacionamento 1:N (autorrelacionamento). 
Fonte: Adaptada de Machado e Abreu (2004).
17
 ● Relacionamento 1:1 (entidadesdistintas): as en-
tidades (tabelas) envolvidas neste relacionamento 
vão possuir o identificador da outra (uma ou outra 
ou ambas) conforme a conveniência do projeto e 
segundo o acesso a essas tabelas (Figura 4):
cod_depcod_departamento cod_funcionario
Chefia
(1,1)(0,1)
Departamento
(1,1)(0,1)
Funcionário
Modelo Entidade-Relacionamento 1:1
 Modelo Relacional 1:1
Departamento
 cod_departamen...
Funcionario
 cod_funcionario: ...
 cod_funcionario: ...
Figura 4: Tabelas distintas com relacionamento 1:1. Fonte: Adaptada 
de Machado e Abreu (2004).
 ● Relacionamento 1:1 (autorrelacionamento): a chave 
primária da entidade é incluída na própria entidade 
(chave estrangeira) e gera uma estrutura de acesso 
para ela (Figura 5)�
18
Casado_com
(0,1)
(0,1)
cod_pessoa
Pessoa
Modelo Entidade-Relacionamento 1:1(autorrelacionamento)
Modelo Relacional 1:N (autorrelacionamento)
Peça
 cod_pessoa: Text...
 cod_pessoa_FK: Te...
Figura 5: Tabela com relacionamento 1:1 (autorrelacionamento). 
Fonte: adaptada de Machado e Abreu (2004).
 ● Relacionamento M:N (entidades distintas ou au-
torrelacionamento): o relacionamento torna-se uma 
tabela que carrega os atributos (se houver) e os 
identificadores das tabelas que ele relaciona. Esse 
é o único caso em que um relacionamento se torna 
uma tabela (Figura 6)�
19
cod_funcionario cod_projeto
Alocado
(1,n)(1,n)
Funcionário
(1,1)
(1,n)(1,n)
(1,1)
Projeto
Modelo Entidade-Relacionamento M:N
Projeto
 cod_projeto: Tex...
Funcionário
 cod_funcionario: ...
 Modelo Relacional M:N
Alocado
 cod_projeto: Tex...
 cod_funcionario: ...
Figura 6: Tabelas distintas com relacionamento M:N.Fonte: 
Adaptada de Machado e Abreu (2004).
 ● Relacionamento múltiplo: o relacionamento é ma-
peado em uma tabela, gerando estruturas de aces-
so condizentes com o grau do relacionamento, ou 
seja, quantas forem necessárias� A chave primária 
de cada uma das entidades associadas gera uma 
estrutura de acesso; assim, a chave da nova tabela é 
a concatenação das chaves estrangeiras (Figura 7)�
20
Conhecto_
Usado
(0,n)
(0,n)
(0,n)
Funcionário Projeto
Conhecimento
Modelo Entidade-Relacionamento (relacionamento múltiplos)
Modelo Relacional (relacionamentos múltiplos)
(0,n)
(0,n) (0,1)(0,1) (0,n)
(0,1)
Conhecto_Usado
Conhecto_Usado
Funcionário ProjetoFigura 7: Tabelas com relacionamento múltiplos. Modelo Entidade-
Relacionamento (relacionamentos múltiplos). Fonte: Adaptada de 
Machado e Abreu (2004).
Conhecto_
Usado
(0,n)
(0,n)
(0,n)
Funcionário Projeto
Conhecimento
Modelo Entidade-Relacionamento (relacionamento múltiplos)
Modelo Relacional (relacionamentos múltiplos)
(0,n)
(0,n) (0,1)(0,1) (0,n)
(0,1)
Conhecto_Usado
Conhecto_Usado
Funcionário Projeto
Figura 8: Modelo Relacional (relacionamentos múltiplos). Fonte: 
Adaptada de Machado e Abreu (2004).
 ● Generalização: a entidade que representa “o todo” 
torna-se uma tabela, e as entidades que representam 
as especializações tornam-se tabelas que carregam 
o identificador (chave primária) da tabela à qual 
pertencem (Figura 9)�
21
cod_departamento cod_funcionario
Relação_1
(1,n)(1,1)
Departamento Funcionário
Modelo Entidade-Relacionamento com Generalização
Engenheiro Vendedor
nomenome nome
(1,1)
(0,n)(0,n)(0,n)
(1,1)(1,1)
(1,1) (1,n)
Funcionário
 cod_funcionario: ...
Departamento
 cod_departmen...
Modelo Relacional com Generalização
Secretaria
nome: Texto(1)
 cod_funcionario: ...
 cod_departamen...
Engenheiro
nome: Texto(1)
 cod_funcionario: ...
Vendedor
nome: Texto(1)
 cod_funcionario: ...
Secretaria
Figura 9: Tabelas com generalizações. Fonte: Adaptada de Machado 
e Abreu (2004).
Em resumo, as tabelas são componentes básicos 
de um sistema de banco de dados relacional, à me-
dida que uma tabela é representada por uma matriz 
composta por linhas (tuplas) e colunas� Cada linha 
representa uma única entidade dentro do conjunto 
22
de entidades, bem como cada coluna representa 
atributos das entidades�
As chaves são elementos centrais para o uso de ta-
belas relacionais, uma vez que elas definem depen-
dências funcionais, isto é, outros atributos depen-
dem da chave e, portanto, podem ser encontrados 
se o valor da chave for conhecido� Cada linha da 
tabela deve ter uma chave primária; como ela deve 
ser exclusiva, nenhum valor nulo é permitido� Embora 
sejam independentes, as tabelas podem se vincular 
por atributos comuns� Portanto, a chave primária de 
uma tabela pode aparecer como chave estrangeira 
em outra tabela à qual se vincula�
23
NORMALIZAÇÃO
Ao projetarmos um banco de dados, podemos ter um 
conjunto de anomalias relacionadas à atualização 
(inclusão, alteração e exclusão) que pode causar 
problemas, como grupos repetitivos de dados (atri-
butos multivalorados), dependências parciais em 
relação a uma chave concatenada, redundâncias de 
dados, perdas acidentais de informação, dificuldade 
na representação de fatos da realidade observada e 
dependências transitivas entre atributos�
Com o intuito de minimizar esses problemas, E� F� 
Codd introduziu, em 1970, o conceito de normaliza-
ção, tornando o modelo lógico de dados bastante 
estável e com poucas necessidades de manutenção� 
Após a definição de um modelo de dados, aplica-se 
a normalização (visão Top-Down), obtendo assim 
elementos mais estáveis, tendo em vista sua imple-
mentação física em um banco de dados�
SAIBA MAIS
Saiba mais sobre a visão Top-Down, lendo Top 
down: o que é e como funciona esse conceito?, 
de Tiago Reis, o qual se encontra disponível em: 
https://www.sunoresearch.com.br/artigos/top-do-
wn/� Acesso em: 19 nov� 2019�
A respeito da normalização, Rob e Coronel (2011) 
afirmam que é um processo que avalia e corrige es-
truturas e tabelas de dados de modo a minimizar as 
24
https://www.sunoresearch.com.br/artigos/top-down/
https://www.sunoresearch.com.br/artigos/top-down/
redundâncias de dados, reduzindo a probabilidade 
de anomalias, atuando por meio de uma série de 
estágios chamados formas normais�
Entretanto, advertem Machado e Abreu (2004), antes 
de analisarmos as formas normais, devemos enten-
der os conceitos de dependência funcional, pois é 
sobre esses conceitos que a maior parte da teoria 
que envolve a normalização foi baseada� Assim, 
temos:
 ● Dependência funcional: dada uma entidade qual-
quer, dizemos que um atributo ou conjunto de atri-
butos A é dependente funcional de um outro atributo 
B contido na mesma entidade� Se, a cada valor de 
B, existirem linhas da entidade em que aparece um 
único valor de A, A depende então funcionalmente 
de B�
 ● Dependência funcional total ou completa e par-
cial: quando da ocorrência de uma chave primária 
concatenada, um atributo ou conjunto de atributos 
depende completa ou totalmente da chave primária 
concatenada, se e somente se a cada valor da chave 
(e não parte dela), estiver associado um valor para 
cada atributo, ou seja, um atributo (dependência 
parcial) não se apresenta com dependência com-
pleta ou total quando só depende de parte da chave 
primária concatenada e não dela como um todo� 
Assim, devemos observar que a dependência total 
ou completa só ocorre quando a chave primária 
for composta por vários (concatenados) atributos, 
ou seja, em uma entidade de chave primária com-
25
posta de um único atributo não possui esse tipo de 
dependência�
Dependência funcional transitiva: quando um atri-
buto ou conjunto de atributos A depende de outro 
atributo B que não pertence à chave primária, mas 
é dependente funcional desta, dizemos que A é de-
pendente transitivo de B�
Com bases nos conceitos sobre as dependências 
funcionais entre atributos de uma entidade, podemos 
verificar as formas normais. Na sequência, estuda-
remos em detalhes cada uma dessas formas�
26
PRIMEIRA FORMA NORMAL
Conforme postulam Machado e Abreu (2004), para 
a Primeira Forma Normal (1FN) temos que cada 
ocorrência da chave primária deve corresponder a 
uma e somente uma informação de cada atributo, 
ou seja, não deveconter grupos repetitivos (mul-
tivalorados), as tabelas aninhadas� Devemos de-
compor então cada entidade não normalizada em 
entidades à medida que o número de conjunto de 
atributos repetitivos; nas novas entidades criadas, a 
chave primária será composta pela chave primária 
da entidade original mais o(s) atributo(s) do grupo 
repetitivo identificados como chave primária deste 
grupo�
Exemplo:
Entidade não normalizada
PEDIDO ( num_pedido, prazo_entrega, cliente, 
endereço, cidade, uf, cnpj, inscricao_estadual, 
cod_produto(*), unid_produto(*), quant_produto(*), 
descr_produto(*), valor_unit_produto(*), valor_to-
tal_produto(*), valor_total_pedido, cond_vendedor, 
nome_vendedor)
Ao analisarmos essa entidade, verificamos a exis-
tência de atributos repetidos (marcados com (*))� 
Assim, ao aplicarmos a 1FN, ficaremos com:
27
Entidades normalizadas – 1FN
PEDIDO ( num_pedido, prazo_entrega, cliente, en-
dereço, cidade, uf, cnpj, inscricao_estadual, va-
lor_total_pedido, cond_vendedor, nome_vendedor)
ITEM_PEDIDO(num_pedido, cod_produto, unid_pro-
duto, quant_produto, descr_produto, valor_unit_
produto, valor_total_produto)
Dessa forma, as tabelas que estejam na 1FN não 
apresentam grupos de repetição (tabelas aninhadas), 
ou seja, cada linha/coluna possui um e somente 
um valor�
 
28
SEGUNDA FORMA 
NORMAL
Segundo Machado e Abreu (2004), uma tabela para 
estar na Segunda Forma Normal (2FN) não pode ter 
atributos com dependência parcial em relação à 
chave primária� Para a aplicação da 2FN, devemos 
verificar se alguma entidade possui chave primária 
concatenada; já para as que satisfizerem tal condi-
ção, analisar se existe algum atributo ou conjunto de 
atributos com dependência parcial em relação a al-
gum elemento da chave primária concatenada� Com 
isso, são geradas novas entidades, que herdarão a 
chave parcial e todos os atributos que dependem 
da chave parcial�
 Exemplo:
Entidades normalizadas – 1FN
PEDIDO ( num_pedido, prazo_entrega, cliente, en-
dereço, cidade, uf, cnpj, inscricao_estadual, va-
lor_total_pedido, cond_vendedor, nome_vendedor)
ITEM_PEDIDO(num_pedido, cod_produto, unid_pro-
duto, quant_produto, descr_produto, valor_unit_
produto, valor_total_produto)
Ao analisar ITEM_PEDIDO, verificamos a existência 
de uma chave primária concatenada e de alguns 
atributos que dependem parcialmente do atributo 
29
cod_produto, o qual faz parte da chave primária� 
Assim, ao aplicarmos a 2FN, ficaremos com:
Entidades normalizadas – 2FN
PEDIDO ( num_pedido, prazo_entrega, cliente, en-
dereço, cidade, uf, cnpj, inscricao_estadual, va-
lor_total_pedido, cond_vendedor, nome_vendedor)
ITEM_PEDIDO (num_pedido, cod_produto, quant_
produto, valor_total_produto)
PRODUTO (cod_produto, unid_produto, descr_pro-
duto, valor_unit_produto)
Uma tabela está na 2FN, portanto, quando se apre-
senta na 1FN e não inclui dependências parciais, 
ou seja, não apresenta atributos que tenham de-
pendência apenas de uma parte da chave primária�
30
TERCEIRA FORMA 
NORMAL
De acordo com Machado e Abreu (2004), uma ta-
bela só estará na Terceira Forma Normal (3FN) se 
nenhum de seus atributos possuir dependência 
transitiva em relação a outro atributo da entidade 
que não participe da chave primária, ou seja, não 
exista nenhum atributo intermediário entre a chave 
primária e o próprio atributo observado� Também 
não poderá conter atributos que sejam o resultado 
do cálculo sobre algum atributo�
Exemplo:
Entidades normalizadas – 2FN
PEDIDO ( num_pedido, prazo_entrega, cliente, en-
dereço, cidade, uf, cnpj, inscricao_estadual, va-
lor_total_pedido, cond_vendedor, nome_vendedor)
ITEM_PEDIDO (num_pedido, cod_produto, quant_
produto, valor_total_produto)
PRODUTO (cod_produto, unid_produto, descr_pro-
duto, valor_unit_produto)
Entidades normalizadas – 3FN
PEDIDO ( num_pedido, prazo_entrega, cod_cliente, 
cod_vendedor)
31
ITEM_PEDIDO (num_pedido , cod_produto , 
quant_produto)
PRODUTO (cod_produto, unid_produto, descr_pro-
duto, valor_unit_produto)
CLIENTE (cod_cliente, cliente, endereço, cidade, uf, 
cnpj, inscricao_estadual)
VENDEDOR (cod_vendedor, nome_vendedor)
Assim, uma tabela está na 3FN quando se apresenta 
na 2FN e não inclui dependências transitivas�
32
FORMA NORMAL DE 
BOYCE / CODD
Quando da criação e definições de Codd para as 
2FN e 3FN, é preciso observar que elas não cobriam 
os casos em que ocorrem simultaneamente três 
condições: caso a entidade tenha várias chaves 
candidatas ou caso estas chaves candidatas sejam 
concatenadas (mais de um atributo) e as chaves 
concatenadas compartilham pelo menos um atri-
buto comum�
Robert Boyce foi quem, em 1974, observou tal aspec-
to� Surge então a necessidade de criação da Forma 
Normal de Boyce/Codd (FNBC), que é considera-
da uma extensão da 3FN e foi definida da seguinte 
forma: uma tabela está na FNBC, se e somente se 
todos os determinantes forem chaves candidatas�
Exemplo:
FILHO (nome_filho, endereco_filho, data_nascimen-
to, nome_escola, numero_sala, nome_professor)
Ao analisar a tabela FILHO e assumir que um pro-
fessor pode estar associado a mais de uma es-
cola/sala, temos como determinantes as chaves 
concatenadas:
a) nome_escola e numero_sala 
b) numero_escola e nome_professor
33
Assim, satisfazem-se as três condições: caso a enti-
dade tenha várias chaves candidatas, caso as chaves 
candidatas sejam concatenadas (mais de um atri-
buto) e as chaves concatenadas compartilhem pelo 
menos um atributo comum� Teremos, portanto, as 
chaves candidatas para a tabela FILHO: nome_filho e 
endereco_filho; nome_filho e numero_sala; nome_fi-
lho e nome_professor� Todas as chaves têm atributos 
concatenados e compartilham o mesmo atributo 
(nome_filho); logo, ao aplicar a FNBC, teremos as 
seguintes tabelas:
FILHO (nome_filho, endereco_filho, data_nascimen-
to, nome_escola, numero_sala)
SALA (nome_escola, numero_sala, nome_professor)
Com isso, a tabela está na FNBC quando todos os 
seus determinantes são chaves candidatas�
34
QUARTA FORMA NORMAL
Quando uma entidade possui algum atributo não 
chave e que recebe múltiplos valores para um mes-
mo valor de chave, bem como esta entidade tenha 
no mínimo três atributos, faz-se necessário aplicar 
a Quarta Forma Normal (4FN), ou seja, uma entida-
de que esteja na 3FN também está na 4FN se ela 
não contiver mais do que um fato multivalorado a 
respeito da entidade descrita�
Exemplo:
TABELA (cod_fornecedor, cod_peça, cod_comprador)
Ao analisar a tabela e ela se encontrar na 3FN, verifi-
camos que ela contém dois atributos multivalorados; 
com isso, temos problemas relativos à atualização 
dos dados e de memória (causados pela ocupação 
desnecessária de área de memória)�
Assim, temos que aplicar a 4FN, realizando uma di-
visão da entidade original em duas outras, ambas 
herdando a chave primária e concatenando, em cada 
nova entidade, com os atributos restantes�
FORNECEDOR_PEÇA (cod_fornecedor, cod_peça)
FORNECEDOR_COMPRADOR (cod_fornecedor, 
cod_comprador)
35
QUINTA FORMA NORMAL
A Quinta Forma Normal (5FN) trata de casos bas-
tante particulares, que ocorrem na modelagem de 
dados, ponto em que ocorrem relacionamentos múl-
tiplos (ternários, quaternários, n-ários)� Uma tabela 
está na 5FN quando o conteúdo dessa mesma tabela 
não puder ser reconstruído (junção) a partir de ou-
tras tabelas menores, extraídas da tabela principal� 
Em outras palavras, se ao particionar uma tabela 
e sua junção posterior não conseguir recuperar as 
informações contidas na tabela original, então esta 
tabela estará na 5FN�
36
DESNORMALIZAÇÃO
Quando aplicadas e implementadas em um SGBD, 
as formas normais podem trazer prejuízos; por isso, 
devido às características de construção física de 
certos bancos de dados, entidades e relacionamen-
tos devem ser desnormalizados� Para que o SGBD 
tenha melhor desempenho, deve-se então levar em 
consideração o custo da redundância de dados e as 
anomalias de atualização decorrentes�
A partir da documentação existente no ambiente 
analisado(visão bottom-up) em um ciclo de vida de 
um projeto de banco de dados, a normalização pode 
se mostrar mais satisfatória� Sendo um desenvolvi-
mento do tipo top-down, no qual se cria um modelo 
de dados a partir da visualização da realidade, a 
normalização serve para realizar um aprimoramen-
to deste modelo, tornando-o menos redundante e 
inconsistente� Nessa visão, a normalização torna-
-se um poderoso aliado da implementação física 
do modelo�
SAIBA MAIS
Saiba mais sobre a visão Bottom-Up, lendo o ar-
tigo Você sabe o que são os processos de Top-
-down e Bottom-Up?, que está disponível em: 
https://canaldoensino.com.br/blog/voce-sabe-o-
-que-sao-os-processos-de-top-down-e-bottom-
-up� Acesso em: 19 nov� 2019�
37
https://canaldoensino.com.br/blog/voce-sabe-o-que-sao-os-processos-de-top-down-e-bottom-up
https://canaldoensino.com.br/blog/voce-sabe-o-que-sao-os-processos-de-top-down-e-bottom-up
https://canaldoensino.com.br/blog/voce-sabe-o-que-sao-os-processos-de-top-down-e-bottom-up
Temos cinco tipos básicos de desnormalização:
1. Duas entidades em um relacionamento muitos-
-para-muitos: a tabela de relacionamento resultante 
dessa construção é composta pelas chaves pri-
márias de cada uma das entidades associadas� Se 
implementarmos a junção dessa tabela com uma 
das tabelas de entidade como uma única tabela em 
vez das tabelas originais, podemos evitar determi-
nadas junções frequentes baseadas em ambas as 
chaves, mas apenas os dados não chave de uma 
das entidades originais�
2. Duas entidades em um relacionamento um para 
um: a tabela para essas entidades pode ser imple-
mentada como uma tabela única, evitando junções 
frequentes exigidas por certos aplicativos�
3. Dados de referência em um relacionamento um 
para muitos: quando as chaves primárias artificiais 
são introduzidas em tabelas que não têm chaves pri-
márias ou composições muito grandes, elas podem 
ser adicionadas à entidade filho em um relaciona-
mento um para muitos como uma chave estrangei-
ra e evitar, deste modo, determinadas junções nos 
aplicativos atuais�
4. Entidades com dados mais detalhados: atributos 
de valores múltiplos são geralmente implementados 
como entidades, por isso, são representados como 
registros separados em uma tabela� Às vezes, é mais 
eficiente implementá-las como colunas nomeadas 
individualmente como uma extensão da entidade pai 
38
quando o número de replicações é um número fixo 
pequeno para todas as instâncias da entidade pai�
5. Atributos derivados: se um atributo é derivado de 
outro no momento da execução, em alguns casos, 
é mais eficiente armazenar o valor original e o valor 
derivado diretamente no banco de dados� Adiciona-
se assim, pelo menos, uma coluna extra à tabela 
original, além de se evitar o cálculo repetitivo�
39
CONSIDERAÇÕES FINAIS
Neste texto, tivemos uma visão geral sobre o Modelo 
Relacional, estabelecendo conceitos básicos tanto 
sobre o modelo quanto sobre os sistemas gerencia-
dores de banco de dados relacionais� Em seguida, 
estudamos as 12 regras estabelecidas por Edgar 
Frank Codd para verificar sua aderência ao modelo 
relacional� Também conceituamos tabelas, tipos de 
chaves, índices e as regras de integridade�
Por fim, tratamos do mapeamento do Modelo 
Entidade-Relacionamento para o Modelo Relacional� 
Em relação à Normalização, abordamos as for-
mas normais: 1FN, 2FN, 3FN, 4FN, FNBC e 5FN; na 
sequência, tratamos brevemente do assunto da 
Desnormalização�
40
SÍNTESE
Neste módulo, tivemos uma visão geral do Modelo Relacional, conceitos básicos 
sobre Tabelas, Tipos de chaves, Índices, regras de integridade e mapeamento do 
Modelo Entidade-Relacionamento para Modelo Relacional� Em seguida, estudamos 
as 12 regras criadas por Edgar Frank Codd, com a finalidade de averiguar a aderência 
de um SGBD ao Modelo Relacional (SGBDR)� 
Depois, abordamos os conceitos de Normalização e as Formas normais (1FN, 2FN, 
3FN, FNBC, 4FN e 5FN), discutindo as vantagens desse processo para o projeto de 
banco de dados�
Finalizamos com a apresentação do conceito de Desnormalização e com a discussão 
de quando devemos aplicar esse processo em prol de melhorias no projeto do banco 
de dados dentro de certos contextos�
ESTRUTURA E 
MODELAGEM DE DADOS
MODELAGEM DE DADOS 2
Referências Bibliográficas 
& Consultadas
ALVES, W. P. Banco de Dados: teoria e desenvolvi-
mento. São Paulo: Érica, 2014.
ASCENCIO, A. F. G.; ARAÚJO, G. S. Estruturas 
de dados: algoritmos, análise da complexidade 
e implementações em JAVA e C/C++. São Paulo: 
Pearson Prentice Hall, 2010 [Biblioteca Virtual].
ELMASRI, R.; NAVATHE, S. B. Sistema de banco 
de dados. 6. ed. São Paulo: Pearson Addison-
Wesley, 2010 [Biblioteca Virtual].
GUIMARÃES, A. M.; LAGES, N. A. C. Algoritmos 
e estruturas de dados. Rio de Janeiro: LTC, 2008.
GUIMARÃES, C. C. Fundamentos de Bancos de 
Dados: modelagem, projeto e linguagem SQL. 
Campinas: Editora da Unicamp, 2003.
HEUSER, C. A. Projeto de banco de dados. 6. ed. 
Porto Alegre: Bookman, 2008 [Minha Biblioteca].
MACHADO, F. N. R.; ABREU, M. P. Projeto de 
Banco de Dados: uma visão prática. 8. ed. São 
Paulo. Érica, 2004.
MEDEIROS, L. F.; Banco de dados: princípios e 
prática. Curitiba: InterSaberes, 2013 [Biblioteca 
Virtual].
PUGA, S.; FRANÇA, E.; GOYA, M. Banco de da-
dos: implementação em SQL, PL/SQL e Oracle 11g. 
São Paulo: Pearson Education do Brasil, 2013 
[Biblioteca Virtual].
RAMAKRISHNAN, R.; GEHRKE, J. Sistemas de 
gerenciamento de banco de dados. 3. ed. Porto 
Alegre: AMGH, 2008 [Minha Biblioteca].
ROB, P.; CORONEL, C. Sistemas de banco de da-
dos: projeto, implementação e gerenciamento. 8. 
ed. São Paulo: Cengage Learning, 2011.
TENENBAUM, A. M.; LANGSAM, Y.; 
AUGENSTEIN, M. J.; Estruturas de dados usando 
C. São Paulo: Pearson Makron Books, 2010.
	_GoBack
	INTRODUÇÃO
	MODELO RELACIONAL
	CONCEITOS 
	TABELAS
	TIPOS DE CHAVES
	ÍNDICES
	REGRAS DE INTEGRIDADE
	MAPEAMENTO DO MODELO ER PARA O MO,DELO RELACIONAL
	NORMALIZAÇÃO
	PRIMEIRA FORMA NORMAL
	SEGUNDA FORMA NORMAL
	TERCEIRA FORMA NORMAL
	FORMA NORMAL DE BOYCE / CODD
	QUARTA FORMA NORMAL
	QUINTA FORMA NORMAL
	DESNORMALIZAÇÃO
	CONSIDERAÇÕES FINAIS
	Síntese