ESTRUTURA E

MODELAGEM
DE DADOS
César Torres Fernandes

E-book 2
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
● 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
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 visualizar que 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
 (1,1) (1,n)
Departamento Tem Funcionário cod_func

cod_dep
Modelo Entidade-Relacionamento 1:N

Departamento Departamento
cod_dep: Texto (1) (1,1) (1,n) cod_func: Texto (1)
cod_dep: Texto (1)

Modelo Relacional 1:N

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):

(0,1)
Peça (0,n) Compõe

cod_peca

Modelo Entidade-Relacionamento 1:N (autorrelacionamento)

Peça
cod_peca: Text...
cod_peca_FK: Te...

Modelo Relacional 1:N (autorrelacionamento)

Figura 3: Tabela com relacionamento 1:N (autorrelacionamento).

Fonte: Adaptada de Machado e Abreu (2004).

17
● Relacionamento 1:1 (entidades distintas): 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):

(0,1) (1,1)
Departamento Chefia Funcionário

cod_departamento
cod_dep cod_funcionario
Modelo Entidade-Relacionamento 1:1

Departamento Funcionario
cod_departamen... (0,1) (1,1) cod_funcionario: ...

cod_funcionario: ...

Modelo Relacional 1:1

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
 (0,1)
Pessoa (0,1) Casado_com

cod_pessoa

Modelo Entidade-Relacionamento 1:1(autorrelacionamento)

Peça
cod_pessoa: Text...
cod_pessoa_FK: Te...

Modelo Relacional 1:N (autorrelacionamento)

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
 (1,n) (1,n)
Funcionário Alocado Projeto

cod_funcionario cod_projeto

Modelo Entidade-Relacionamento M:N

Funcionário Projeto
cod_funcionario: ... cod_projeto: Tex...

(1,1) (1,1)

Alocado
(1,n) cod_projeto: Tex... (1,n)
cod_funcionario: ...

Modelo Relacional M:N

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
 (0,n) Conhecto_ (0,n)
Funcionário Projeto
Usado

(0,n)

(0,n) Conhecto_
Conhecimento (0,n)
Funcionário Projeto
Usado

Modelo Entidade-Relacionamento (relacionamento múltiplos)

Figura 7: Tabelas com relacionamento(0,n)múltiplos. Modelo Entidade-

Funcionário Conhecto_Usado Projeto
Relacionamento(0,1) (0,n)
(relacionamentos (0,n) Fonte:
múltiplos).
Conhecimento
(0,1) Adaptada de
Machado e Abreu (2004).
(0,n)
Modelo Entidade-Relacionamento (relacionamento múltiplos)

(0,1)
Funcionário Conhecto_Usado Projeto
(0,1) (0,n) Conhecto_Usado (0,n) (0,1)

(0,n)
Modelo Relacional (relacionamentos múltiplos)

(0,1)
Conhecto_Usado

Modelo Relacional (relacionamentos múltiplos)

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
 (1,1) (1,n)
Departamento Relação_1 Funcionário

cod_departamento cod_funcionario

Secretaria Engenheiro Vendedor

nome nome nome

Modelo Entidade-Relacionamento com Generalização

Departamento Funcionário
cod_departmen... (1,1) (1,n) cod_funcionario: ...
cod_departamen...

(1,1) (1,1) (1,1)

(0,n) (0,n) (0,n)

Secretaria Engenheiro Vendedor
nome: Texto(1) nome: Texto(1) nome: Texto(1)
cod_funcionario: ... cod_funcionario: ... cod_funcionario: ...

Modelo Relacional com Generalização

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
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 deve conter 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
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

ESTRUTURA E
MODELAGEM DE DADOS

MODELAGEM DE DADOS 2

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�
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.