Banco de Dados - Volume 3

Prévia do material em texto

Recife, 2010
Banco de Dados
UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)
COORDENAÇÃO GERAL DE EDUCAÇÃO A DISTÂNCIA (EAD/UFRPE)
Sandra de Albuquerque Siebra
Volume 3
Universidade Federal Rural de Pernambuco
Reitor: Prof. Valmar Corrêa de Andrade
Vice-Reitor: Prof. Reginaldo Barros
Pró-Reitor de Administração: Prof. Francisco Fernando Ramos Carvalho
Pró-Reitor de Extensão: Prof. Paulo Donizeti Siepierski
Pró-Reitor de Pesquisa e Pós-Graduação: Prof. Fernando José Freire
Pró-Reitor de Planejamento: Prof. Rinaldo Luiz Caraciolo Ferreira
Pró-Reitora de Ensino de Graduação: Profª. Maria José de Sena
Coordenação Geral de Ensino a Distância: Profª Marizete Silva Santos
Produção Gráfica e Editorial
Capa e Editoração: Rafael Lira, Italo Amorim e Arlinda Torres
Revisão Ortográfica: Elias Vieira
Ilustrações: Noé Aprígio
Coordenação de Produção: Marizete Silva Santos
Sumário
Apresentação ................................................................................................................. 4
Conhecendo o Volume 3 ................................................................................................ 5
Capítulo 7 – O Modelo Relacional .................................................................................. 7
O Modelo Relacional (MR) ..............................................................................................7
Conceitos do Modelo Relacional .....................................................................................8
Regras de Integridade Fundamentais ............................................................................14
Capítulo 8 – Derivando o MR a partir do MER .............................................................. 25
Algumas Informações Iniciais ........................................................................................25
Regras para Derivar o Modelo Relacional a partir do MER ............................................26
Capítulo 9 – Normalização de Dados ............................................................................ 41
Dependências Funcionais ..............................................................................................41
Anomalias de Atualização ..............................................................................................43
O que é Normalização?..................................................................................................45
Primeira Forma Normal (1FN) .......................................................................................47
Segunda Forma Normal .................................................................................................49
Terceira Forma Normal ..................................................................................................52
Forma Normal de Boyce-Codd ......................................................................................55
Um Roteiro para a Normalização ...................................................................................56
Algumas Informações Adicionais ...................................................................................57
Apêndice A – Outras Formas Normais .......................................................................... 64
Quarta Forma Normal ...................................................................................................64
Quinta Forma Normal ....................................................................................................66
Considerações Finais .................................................................................................... 68
Conheça a Autora ........................................................................................................ 70
4
Apresentação
Caro(a) cursista,
Seja bem-vindo(a) ao terceiro módulo do curso Banco de Dados!
Neste terceiro módulo, vamos estudar o modelo relacional e todas as suas nuances. O modelo relacional é 
o resultado da modelagem lógica do Banco de Dados e é a etapa seguinte a modelagem conceitual. 
Dentro deste contexto, estudaremos como tranformar a modelagem conceitual em modelagem lógica, 
como otimizar o modelo criado através das regras de normalização e como fazer as checagens de integridade 
referencial.
Bons estudos!
Sandra de Albuquerque Siebra
Autora
5
Banco de Dados
Conhecendo o Volume 3
Neste terceiro volume, você irá encontrar o Módulo 3 da disciplina de Banco de 
Dados. Para facilitar seus estudos, veja a organização deste segundo módulo.
Módulo 3 – Modelagem Lógica e Projeto de Banco de Dados
Carga horária do Módulo 3: 15 h/aula
Objetivo do Módulo 3:
» Introduzir os principais conceitos e definições relacionados à modelagem lógica de 
dados.
» Examinar os principais conceitos envolvidos no modelo relacional.
» Estudar como derivar a modelagem lógica a partir da modelagem conceitual.
» Estudar como otimizar a modelagem de dados através da normalização.
Conteúdo Programático do Módulo 3:
» O Modelo Relacional.
» As 12 Regras de Codd.
» Transformação do Modelo E-R para o Modelo Relacional.
» Restrições de Integridade.
» Dependências Funcionais.
» Normalização de Dados.
6
Banco de Dados
Capítulo 7
O que vamos estudar neste capítulo?
Neste capítulo, vamos estudar os seguintes temas:
» O Modelo Relacional.
» Restrições de Integridade.
Metas
Após o estudo deste capítulo, esperamos que você consiga:
» Identificar as particularidades e os componentes do Modelo Relacional.
» Fazer a checagem de integridade do modelo.
7
Banco de Dados
Capítulo 7 – O Modelo Relacional
Vamos conversar sobre o assunto?
No projeto de Banco de Dados, a modelagem lógica ou projeto lógico é a terceira 
etapa (vide Figura 1), antecedida pela análise de requisitos e pela modelagem conceitual. 
O produto dessa etapa é o modelo relacional ou esquema relacional e este é justamente o 
assunto desse capítulo! Esse modelo já é dependente do SGBD que for ser escolhido para 
a implementação do banco de dados. Logo, atente para o fato de que esse é o momento 
dessa decisão ser tomada.
Neste capítulo, vamos falar sobre o modelo relacional, que é um exemplo de 
modelo lógico de dados, e sobre os conceitos a ele relacionados.
Figura 1 - Etapas do Projeto de Banco de Dados
O Modelo Relacional (MR)
Vamos relembrar... o que é o modelo lógico? É um modelo que vai especificar a 
representação/declaração dos dados de acordo com o SGBD escolhido, definindo assim a 
estrutura de registros do BD (onde cada registro define número fixo de campos (atributos) 
e cada campo possui tamanho fixo). Um exemplo de modelo lógico é o modelo relacional 
(MR). Os SGBDs que utilizam o MR são denominados SGBDs Relacionais e, nesta disciplina, 
trataremos do projeto lógico apenas desse tipo de SGBD.
8
Banco de Dados
O Modelo Relacional foi introduzido por Ted Codd, da IBM Research, em 1970, em 
um artigo clássico (Codd, 1970) que imediatamente atraiu a atenção em virtude de sua 
simplicidade e base matemática. O modelo usa o conceito de uma relação matemática – 
algo como uma tabela de valores – como seu bloco de construção básica e tem sua base 
teórica na teoria dos conjuntos.
As primeiras implementações comerciais do modelo relacional tornaram-se 
disponíveis no início da década de 80, antes disso, eram utilizados os modelos de redes e 
hierárquico (sobre os quais estudamos no Volume 1, capítulo 1).
O modelo relacional tem como objetivos: prover esquemas de fácil utilização; 
melhorar a independência lógica e física de dados; prover os usuários com linguagens 
de manipulação de BD de alto nível, permitindo o seu uso por usuários não experientes; 
otimizar o acesso aos BDs e melhorar a integridade e segurança dos dados.
O MR representa os dados do BD como relações1 (tabelas) de nomes únicos. O 
conceito de tabelas está intimamente ligado ao conceito de uma relação matemática – de 
onde se origina o nome deste modelo. Vamos apresentar, na seção a seguir, cada um dos 
conceitos relevantesdentro do contexto do modelo relacional.
Conceitos do Modelo Relacional
Em um ambiente de banco de dados relacional, utilizamos alguns conceitos muito 
importantes para a correta implantação e operação de qualquer sistema de banco de 
dados. Por exemplo, na terminologia do modelo relacional, cada tabela é chamada relação 
e vai possuir um nome único que a identifica; cada linha da tabela é chamada tupla e cada 
cabeçalho de coluna é conhecido como atributo (vide Figura 2).
Figura 2 - Exemplos de Terminologias do Modelo Relacional
Alguns desses novos termos originam-se diretamente da Teoria de Conjuntos, outros 
são decorrentes da utilização de elos lógicos para implementar os relacionamentos entre os 
dados armazenados no banco de dados. A seguir, cada um dos conceitos fundamentais do 
modelo relacional será descrito.
Tabela ou Relação
No modelo relacional, a estrutura que armazena os dados referentes a cada uma 
das ocorrências de uma entidade ou relacionamento com atributos do MER é chamada de 
tabela ou relação. 
Uma tabela é uma representação bi-dimensional de dados composta de linhas 
e colunas. Por exemplo, a tabela de empregados de uma empresa (vide Tabela 1) onde 
Comentário
1 A palavra relação é 
utilizada no sentido 
de lista ou rol de 
informações e não no 
sentido de associação 
ou relacionamento.
9
Banco de Dados
poderiam ser armazenados dados como o CPF, o nome e o telefone de cada empregado. A 
tabela como um todo representaria os empregados da empresa. Cada coluna representaria 
um atributo (ex: a primeira coluna da Tabela 1 é o CPF ). E cada linha da tabela representa os 
dados de um empregado. Por exemplo, a primeira linha da Tabela 1 refere-se à empregada 
de CPF número 987675456-98, de nome Ana Marques e cujo telefone é 3245-8976.
Tabela 1 - Tabela ou Relação Empregado
CPF Nome Telefone
987675456-98 Ana Marques 3245-8976
765456243-45 João Pontes 3124-5645
213415467-89 Marcos Alves 3456-8923
567324980-03 Tânia Gomes 3455-9098
Matematicamente, define-se uma relação como um subconjunto de um produto 
cartesiano de uma lista de domínios2. Assim, suponha que D1 denote o domínio do atributo 
A1, D2 denote o domínio do atributo A2 e Dn denote o domínio do atributo N da tabela T1. 
Qualquer linha da tabela que possui estes atributos é denotada pela tupla3 (d1,d2,...,dn) em 
que d1, d2 e dn têm como valores possíveis (domínios), respectivamente D1, D2 e Dn. Em 
geral, uma instância de T1 é um subconjunto de D1 X D2 X ... X Dn.
O conjunto de atributos de uma relação é chamado de esquema da relação. O 
esquema de uma relação é denotado por : R[A1 D1, ..., An Dn] onde:
R é o nome da relação; 
A1, ..., An é a lista de atributos da relação R e
D1, ..., Dn são os domínios de cada um dos atributos da relação R.
Frequentemente, é utilizada uma notação simplificada em que é omitida a definição 
do domínio de cada atributo da relação: R[A1, ..., An]. Por exemplo, o esquema da relação 
representada na Tabela 1 seria: Empregado[CPF char4(11), Nome char(50), Telefone 
char(9)] ou, na notação simplificada, teríamos Empregado[CPF, Nome, Telefone].
Na criação dos esquemas das relações o nome das relações ou tabelas devem ser 
únicos no banco de dados, devem ser escritos no singular e, de preferência, devem ser 
nomes curtos. Se for usado um nome composto, este deve ser separado por um underline 
(_), por exemplo Pessoa_Fisica ou Pessoa_Juridica.
O grau de uma relação é o número de atributos que a compõe. Por exemplo, o grau 
da relação Empregado[CPF, Nome, Telefone] é três, porque essa relação possui 3 atributos.
Uma particularidade referente à definição de relação é que, nesta definição, não 
existe qualquer tipo de ordenação ou de definição de ordenação. Assim, por exemplo, as 
duas relações representadas pelas Tabelas 1 e 2 são consideradas idênticas. Afinal, o que 
mudou de uma tabela para outra foi apenas a ordem em que os valores de preenchimento 
da tabela aparecem.
Comentário
2 Um domínio contém 
os valores possíveis 
para um determinado 
atributo da relação.
Comentário
3 Uma tupla é uma 
ocorrência particular 
de um elemento da 
tabela. Falaremos 
sobre esse conceito, 
em detalheas, mais a 
frente.
Comentário
4 O tipo char equivale 
ao tipo string das 
linguagens de 
programação, onde 
você pode digitar 
letras, números e 
símbolos. Quando 
você define um tipo 
char, você tem de 
especificar o tamanho 
do que preencherá 
o mesmo. Esse tipo 
pode variar de nome 
de SGBD para SGBD 
mas sempre vai ter um 
correspondente.
10
Banco de Dados
Tabela 2 - Tabela ou Relação Empregado
CPF Nome Telefone
213415467-89 Marcos Alves 3456-8923
567324980-03 Tânia Gomes 3455-9098
765456243-45 João Pontes 3124-5645
987675456-98 Ana Marques 3245-8976
Linha (Tupla)
Uma ocorrência, em particular, de dados em uma tabela ocupa uma linha dessa 
tabela. Por exemplo, na Tabela 3, os dados de cada um dos empregados que a compõe 
ocupam uma linha diferente da tabela. Como existem 4 empregados, a Tabela 3 possui 4 
linhas (ou tuplas ou registros). O número de linhas ou tuplas de uma relação é chamado de 
cardinalidade da relação. Logo, a cardinalidade da relação expressa na Tabela 3 é quatro.
Cada linha da tabela deve ser única e deve possuir um atributo identificador. No 
caso da Tabela 3, esse identificador é o CPF do empregado. O atributo identificador, no 
modelo relacional, passa a ser chamado de chave primária (PK) - detalharemos melhor esse 
ponto mais a frente.
Tabela 3 - Exemplos de Atributos e Tuplas
Outra definição que pode ser dada para linha ou tupla é: um conjunto de pares 
(<atributo>,<valor>), em que cada par fornece o valor do mapeamento de um atributo Ai 
para um valor Vi, tal que cada valor Vi seja um elemento do domínio Di ou um valor nulo.
Algumas regras para tuplas são: em uma tabela ou relação não devem existir tuplas 
ou linhas duplicadas. As linhas de uma tabela não seguem uma ordem específica. Dessa 
forma, as tuplas ou linhas abaixo seriam idênticas:
T = <(CPF, 987675456-98), (Nome, Ana Marques), (Telefone, 3245-8976)> e
T = <(Telefone, 3245-8976), (CPF, 987675456-98), (Nome, Ana Marques)>
Coluna (Atributo)
Cada tipo de informação armazenada em uma tabela é uma coluna. Ou seja, cada 
11
Banco de Dados
atributo que caracteriza a relação é expresso em uma coluna. Toda coluna de uma tabela 
deve possuir um nome pelo qual será referenciada sempre que necessário. Na verdade, 
ao criarmos uma tabela definimos, para cada uma de suas colunas, o seu nome (nome do 
atributo) e também o seu tipo (numérico, alfabético, data, etc). Por exemplo, CPF, Nome e 
Telefone são atributos (colunas ou campos) da Tabela Empregado, expressos na Tabela 3. 
Um nome de atributo deve ser único em uma tabela e deve expressar o tipo de 
informação que ele representa. E o valor de um atributo não deve poder ser decomposto 
em mais de uma coluna.
Domínio do Atributo
Domínio de um atributo é a faixa de valores que esse atributo pode conter. Em 
outras palavras, é o conjunto de valores que um determinado atributo pode assumir. Por 
exemplo, para o atributo CPF da Tabela 3, o domínio seria o conjunto dos números naturais. 
Em outras tabelas quaisquer, por exemplo, o domíno do atributo "dia do mês” seria o 
conjunto dos números entre 1 e 31. O atributo “sexo” teria como domínio os mnemônicos 
M (para masculino) ou F (para feminino) e assim por diante.
Sempre que identificamos um atributo de uma tabela, temos também uma ideia de 
qual o tipo de informação que ele poderá vir a conter.
Chaves
Uma chave5 é um atributo (ou conjunto de atributos) que identifica univocamente 
cada entrada de uma relação. Ou seja, por meio de chaves podemos diferenciar as diversas 
tuplas pertencentes a uma relação. Como consequência dessa definição, temos que os 
atributos chaves não podem apresentar valores duplicados, nem podem ser nulos.
NULO - Não devemos confundir o conceito de nulo com espaços em branco ou o número zero, por 
exemplo, que são valores conhecidos. Nulo é a ausênciade informação. 
Uma coluna de preenchimento obrigatório numa tabela deve possuir todos os seus valores não-
nulos. Se, por exemplo, uma linha da tabela Empregado contiver um nulo na coluna Telefone, 
significa que o telefone do empregado correspondente àquela linha é desconhecido. Assim, ou o 
telefone não foi informado por algum motivo ou o empregado não possui telefone, de qualquer 
forma, a informação está ausente na tabela.
Uma definição mais formal para chave seria: seja R um esquema de relação. Se 
dissermos que um subconjunto K de atributos de R é uma superchave6 para R, estaremos 
considerando restrições para as relações r(R), nas quais não existem duas tuplas distintas 
com mesmos valores em todos os atributos de K. Isto é, se as tuplas t1 e t2 fazem parte da 
relação r e t1 <> t2, então t1[K] <> t2[K].
Quando há a possibilidade de mais de um atributo (isoladamente) poder ser chave 
em uma relação, dizemos que esses atributos são chaves candidatas. Por exemplo, na Tabela 
4, CPF e Nome poderiam ser chaves candidatas, porque poderiam ser atributos usados para 
localizar uma entrada na tabela.
Comentário
5 O conceito 
de chave está 
diretamente ligado 
ao de identificador 
da entidade ou 
relacionamento que foi 
estudado no volume 
anterior, quando 
foram detalhados os 
componentes do MER.
Comentário
6 Superchave é o 
conjunto de um ou 
mais atributos que nos 
permitem identificar 
de maneira unívoca 
uma tupla de uma 
relação.
12
Banco de Dados
Tabela 4 - Tabela ou Relação Empregado
CPF (PK) Nome Telefone
213415467-89 Marcos Alves 3456-8923
567324980-03 Tânia Gomes 3455-9098
765456243-45 João Pontes 3124-5645
987675456-98 Ana Marques 3245-8976
Um dos princípios do modelo relacional diz que uma linha de uma tabela deve 
sempre poder ser referenciada de forma única. Por isso, entre as chaves candidatas, uma 
delas deve ser eleita para ser a principal, a chave primária da tabela (Primary Key ou PK), 
aquela que realmente identifica univocamente cada tupla da tabela. No caso, para a Tabela 
4, a melhor escolha para chave primária seria o atributo CPF, já que essa informação não se 
repetiria, de forma alguma, em dois empregados distintos da tabela. 
A escolha da chave primária (PK) da tabela é influenciada pelas necessidades do domíno do mundo 
real que está sendo modelado.
Chaves primárias são, geralmente, indicadas na tabela pela sigla PK (Primary Key) e 
podem também ser sublinhadas (vide Tabela 4).
As outras chaves candidatas que não forem escolhidas para chave primária, são 
chamadas de chaves secundárias. Por exemplo, na Tabela 4, o atributo Nome seria uma 
chave secundária.
Muitas vezes, uma tabela não possui, entre seus atributos, um que por si só seja 
suficiente para identificar univocamente uma ocorrência. Nesses casos, deve se tentar achar 
uma combinação de dois ou mais atributos que tenham a capacidade de se constituir numa 
chave primária. Chamamos a essas chaves primárias, formadas pela combinação de vários 
atributos, de chaves primárias compostas. Ou seja, uma chave primária composta é aquela 
formada por mais de um atributo ou coluna. Geralmente, uma tabela que represente um 
relacionamento entre outras duas tabelas (originada de um relacionamento do MER) irá 
possuir chaves primárias compostas. Por exemplo, a tabela Alocação (vide Tabela 5), terá 
como chaves primárias os atributos CPF (vindo da Tabela Empregado – vide Tabela 6) e 
Cod_Projeto (vindo da Tabela Projeto – vide Tabela 7). Isso, porque para descobrir qual a 
função de um empregado em um projeto, precisamos dessas duas informações. Nenhum 
dos atributos isoladamente poderia fornecer essa informação.
Se mesmo com a combinação de atributos não for possível formar uma chave 
primária coerente, deve-se criar um código sequencial para identificar unicamente cada 
entrada da tabela. Por exemplo, na Tabela 7 (Tabela Projetos), a chave da tabela é o código 
do projeto que é um sequencial numérico.
Tabela 5 - Tabela ou Relação Alocação
CPF (PK) Cod_projeto (PK) Função
213415467-89 002 Analista
567324980-03 001 Consultor
765456243-45 003 Suporte
987675456-98 002 Programador
13
Banco de Dados
Tabela 6 - Tabela ou Relação Empregado
CPF (PK) Nome Telefone
213415467-89 Marcos Alves 3456-8923
567324980-03 Tânia Gomes 3455-9098
765456243-45 João Pontes 3124-5645
987675456-98 Ana Marques 3245-8976
Tabela 7 - Tabela ou Relação Projeto
Cod_projeto (PK) Nome Projeto
001 SOFTHOUSE
002 GEOPROC
003 LINUX WORLD
Uma tabela pode incluir entre seus atributos a chave primária de outra tabela. 
Essa chave é chamada chave estrangeira. Ou seja, uma chave estrangeira é uma coluna 
(ou combinação de colunas) que indica um valor que deve existir como chave primária em 
uma outra tabela (chamada de Tabela Pai). Por exemplo, na tabela Alocação (vide Tabela 
5), as colunas CPF e Cod_Projeto são chaves estrangeiras, porque elas são chave primária, 
respectivamente, das tabelas Empregado (vide Tabela 6) e Projeto (vide Tabela 7).
Vamos definir novamente com outras palavras: uma chave estrangeira de uma 
relação R1 é um atributo (ou conjunto de atributos) que referencia a chave primária de uma 
outra relação R2. Dessa forma, para qualquer tupla de R1, o valor da chave estrangeira deve 
ser igual ao valor da chave primária de alguma tupla da relação R2 referenciada, ou deve ser 
o valor nulo (se a chave estrangeira não fizer parte da chave primária da relação R1). Com 
isso queremos dizer que o atributo que é chave estrangeira em uma relação R1, pode ou não 
fazer parte da chave primária de R1. No exemplo de chave estrangeira dado anteriormente, 
as chaves estrangeiras CPF e Cod_Projeto fazem parte da chave primária da tabela Alocação 
(vide Tabela 5). Porém, a chave estrangeira pode não fazer parte da chave primária. Observe 
a tabela Funcionário (vide Tabela 8). Ela possui um atributo chamado Cod_Depto que 
é chave primária da tabela Departamento (vide Tabela 9). Logo, na tabela Funcionário, o 
atributo Cod_Depto é uma chave estrangeira. Chaves estrangeiras são indicadas pela sigla 
FK (Foreign Key) – vide Tabela 8.
Tabela 8 - Tabela ou Relação Funcionário
CPF (PK) Nome Cod_Depto (FK)
213415467-89 Marcos Alves 11
567324980-03 Tânia Gomes 22
765456243-45 João Pontes 11
987675456-98 Ana Marques 22
14
Banco de Dados
Tabela 9 - Tabela ou Relação Departamento
Cod_Depto (PK) Nome
11 Vendas
22 Financeiro
Uma chave estrangeira formada por mais de uma coluna é chamada de chave 
estrangeira composta.
No modelo relacional os relacionamentos representados no MER passam a ser 
representados através de chaves estrangeiras. Ou seja, as chaves estrangeiras tornam 
possível a associação lógica entre tabelas distintas. Isso ficará mais claro no próximo capítulo 
quando forem apresentadas as regras de derivação do MR a partir do MER.
Regras de Integridade Fundamentais
O modelo relacional, ao definir conceitos como Tabela, Tupla, Atributo, Nulo, 
Domínio, Chave Primária e Chave Estrangeira deixa implícitas algumas regras fundamentais 
para a manutenção da consistência do banco de dados. Elas são chamadas de Regras de 
Integridade e tratam dos cuidados que analistas, projetistas e programadores devem 
observar ao implementar as rotinas de Inclusão, Alteração e Exclusão de dados nas bases 
de dados. Na prática, as restrições de integridade fornecem meios para assegurar que 
mudanças feitas no banco de dados não resultem na perda da consistência sobre estes 
dados.
Vamos ver agora dois dos principais tipos de integridade a serem mantidas em 
um banco de dados adequadamente projetado: a Integridade de Entidade e a Integridade 
Referencial. Posteriormente, discutiremos regras de integridade complementares e regras 
de integridade semântica.
Integridade de Entidade (ou de Identidade ou Existencial) 
Refere-se às chaves primárias e procura garantir que toda e qualquer linha de uma 
tabela deve poder ser acessada com base apenas no conteúdo de sua chave primária. Para 
isso, algumas regras devem ser observadas:» Toda tupla tem um conjunto de atributos que a identifica de maneira única na 
relação (Integridade de Chave).
» Nenhum atributo que faça parte de uma chave primária pode ter valor nulo (eles 
devem ser NN = not null).
» Não se deve permitir que em uma mesma tabela existam duas ocorrências (tuplas) 
com chaves primárias iguais. Ou seja, os atributos que são chave primária devem 
ser únicos (ND = No Duplicate ou Unique).
Isso significa que os conteúdos de todos os atributos que constituem uma chave 
primária devem ser conhecidos e únicos. Um conteúdo nulo representa uma informação 
desconhecida ou, em outras palavras, a ausência da informação, o que não pode ser 
permitido em qualquer elemento de uma chave primária.
Algumas recomendações para se alcançar a integridade de entidade são:
15
Banco de Dados
» Selecione chaves primárias que realmente tenham preenchimento único no 
domínio do problema.
» Se possível, prefira chaves primárias simples e numéricas.
» Se não houver nenhuma coluna que possa ser uma chave candidata, utilize chaves 
primárias sequenciais, geralmente, atribuídas pelo sistema.
Integridade Referencial
Diz respeito às chaves estrangeiras e visa manter a integridade dos relacionamentos 
previstos no banco de dados. Ou seja, a integridade referencial cuida para que uma relação 
possa ter um ou mais de atributos que formam a chave primária de outra relação. Estes 
atributos são chamados de chave estrangeira.
Na definição dos cuidados referentes a esse tipo de integridade, utilizaremos dois 
conceitos:
» Tabela-Pai (Parent Table): é aquela onde o atributo de relacionamento desempenha 
o papel de chave primária.
» Tabela-Filho (Dependent Table): tabela onde o atributo de relacionamento 
desempenha o papel de chave estrangeira.
Para manter a integridade referencial, a regra básica é: o conteúdo de uma chave 
estrangeira deve, necessariamente, ser igual ao de uma ocorrência da Tabela-Pai ou então 
ser nulo. Vale ressaltar que o valor da chave estrangeira só poderá ser nulo na Tabela-Filho, 
se o atributo que for chave estrangeira não fizer parte da chave primária da Tabela-Filho. 
Por exemplo, na última tupla da tabela Funcionário (vide Tabela 10), temos que o 
Cod_Depto é NULL. Isso é possível apenas porque o atributo Cod_Depto não faz parte da 
chave primária da tabela Funcionário. E deve significar que, por enquanto, a funcionária 
Ana Marques não foi alocada em nenhum departamento (vamos supor que ela acabou 
de ser contratada). Já todas as outras tuplas da tabela Funcionário possuem o Cod_Depto 
preenchido e, para que a integridade referencial seja mantida, como esse atributo é chave 
estrangeira, ele deve existir como chave primária em alguma outra tabela. No caso, na 
tabela Departamento (vide Tabela 9). Nesse exemplo fornecido, a tabela Funcionário é a 
Tabela-Filho e a tabela Departamento é a Tabela-Pai.
Tabela 10 - Tabela ou Relação Funcionário
CPF (PK) Nome Cod_Depto (FK)
213415467-89 Marcos Alves 11
567324980-03 Tânia Gomes 22
765456243-45 João Pontes 11
987675456-98 Ana Marques NULL
16
Banco de Dados
Observação
Uma chave estrangeira pode referenciar-se a um atributo da sua própria tabela (caso que 
ocorrerá com os auto-relacionamentos do MER). Por exemplo, a tabela Funcionário (vide 
Tabela 11) poderia ter, para cada funcionário, quem é o seu supervisor direto. Assim, o campo 
CPF_Supervisor, que é considerado chave estrangeira, é a chave primária da própria tabela 
Funcionário e não de outra tabela qualquer.
Tabela 11 - Tabela ou Relação Funcionário
CPF (PK) Nome CPF_Supervisor (FK)
213415467-89 Marcos Alves 765456243-45
567324980-03 Tânia Gomes 765456243-45
765456243-45 João Pontes NULL
As consequências da Integridade Referencial refletem-se nas consistências 
necessárias ao se proceder às operações de Inclusão, Alteração e Exclusão de dados nas 
Tabelas Pai e Filho. Veja as regras no Quadro 1.
17
Banco de Dados
Quadro 1 - Regras de Inclusão, Alteração e Exclusão para manter a Integridade Referencial
Operação Tabela_Pai Tabela-Filho
Inclusão
A inclusão de dados na tabela-pai não tem 
nenhuma implicação ou problema.
A inclusão de dados na Tabela-
Filho deve atentar para o fato de 
que não será possível incluir uma 
nova tupla se o valor do campo 
que for chave estrangeira já não 
estiver cadastrado na Tabela-Pai. 
A menos que o campo chave 
estrangeira não faça parte da 
chave e possa receber o valor 
NULL.
Alteração
Se a alteração envolver o valor da chave 
primária, deve-se utilizar um dos seguintes 
critérios:
» A chave não deve ser alterada se estiver 
sendo utilizada em alguma tabela-filho.
» A chave deve ser alterada e deve-se colocar 
NULL nas chaves estrangeiras presentes na(s) 
Tabela(s)-Filho (contanto que o valor em 
questão não faça parte da chave primária da(s) 
Tabela(s)-Filho correspondente(s)).
» A chave deve ser alterada e o novo valor deve 
ser colocado no campo que é chave estrangeira 
em todas as tabelas-filho relacionadas.
Se a alteração envolver o 
atributo que é chave estrangeira, 
a alteração só deve ser realizada 
usando valores que existam na 
tabela pai (podendo também 
usar o valor NULL, se essa chave 
estrangeira não fizer parte da 
chave primária da Tabela-Filho).
Exclusão
Para excluir uma tupla dessa tabela, deve-se 
utilizar um dos seguintes critérios:
» Não deletar, se a tupla estiver sendo utilizada 
em uma Tabela-Filho.
» Deletar a tupla e colocar NULL nas chaves 
estrangeiras das Tabelas-Filhos afetadas (isso se 
o atributo envolvido não fizer parte da chave-
primária da Tabela-Filho).
» Deletar e, também, eliminar todas as tuplas 
das Tabelas-Filho que façam uso do valor da 
tupla sendo eliminada.
A exclusão de Dados na Tabela-
Filho não tem nenhuma 
implicação ou problema. 
As restrições de integridade devem ser implementadas pelo SGBD. Muitos SGBD’s implementam 
integridade de entidade, mas não implementam integridade referencial.
18
Banco de Dados
Regras de Integridade Complementares
Além das regras de integridade de entidade e referencial, um banco de dados 
relacional pode suportar um conjunto adicional de regras (ou restrições) cuja finalidade 
é especificar aspectos próprios de cada coluna e respectivo domínio, complementando 
com isso a definição de suas características lógicas. As principais restrições de integridade 
complementares tratam da obrigatoriedade e unicidade de valores e sobre conjuntos de 
valores permitidos. Vamos às regras:
» Obrigatoriedade - Indica se deve ou não ser permitida a existência de nulos em uma 
coluna (ou seja, se um atributo pode ou não ser nulo). Colunas que não aceitam 
nulos são de preenchimento obrigatório como, por exemplo, o nome de um 
funcionário na tabela de funcionários. Campos que não possuam obrigatoriedade 
de preenchimento são considerados campos opcionais. Por exemplo, o número do 
telefone poderia ser um campo opcional, dependendo do domínio, visto que ainda 
podem haver pessoas que não possuem número de telefone. A definição de se um 
campo será de preenchimento obrigatório ou não, vai depender muito do domínio 
do mundo real sendo modelado.
» Unicidade - Indica se deve ser permitido ou não que uma coluna possua valores 
idênticos em duas ou mais linhas. Uma coluna que não pode possuir valores 
repetidos é uma coluna de valores únicos. 
» Verificação de Valores Específicos - Indica explicitamente qual o conjunto de 
valores permitidos para uma determinada coluna. Por exemplo, para a coluna Sexo 
de uma tabela Empregado só poderiam ser aceitos os valores ‘M’ ou ‘F’. Qualquer 
outro valor deveria ser recusado.
Restrições de Integridade Semântica
São restrições especificadas e mantidas num banco de dados relacional pelo 
programa de aplicação e que são inerentes a aplicação sendo desenvolvida. Ou seja, são 
as regras de negócio do domínio do mundo real sendo implementado. Por exemplo, em 
um determinado sistema pode-se querer implementar a restrição que “o salário de um 
empregadonão pode ser maior do que o salário do seu supervisor direto” ou que “o 
número máximo de horas por semana que um empregado pode trabalhar em projetos é de 
40 horas” (suponha que a empresa não permite horas extras) ou, ainda, “a data de entrega 
de um pedido não pode ser inferior à data em que o pedido foi realizado”. Tais restrições, 
como dito, são específicas do domínio sendo implementado e necessitam ser programadas 
em cada aplicação que vá fazer uso do banco de dados.
Conheça Mais
Neste capítulo foram vistos conceitos básicos do modelo relacional. Para obter mais 
informações ou materiais diversificados para o que foi visto aqui, você pode proceder a 
uma pesquisa usando o Google (www.google.com.br) com as palavras chaves “Modelagem 
Lógica” + “Banco de Dados” ou “Modelo Relacional” ou ainda “Esquema Relacional”. Você 
vai ver que virá muito material. Entre eles: apostilas, notas de aula, reportagens, etc. 
Adicionalmente, você pode consultar qualquer livro sobre banco de dados, 
pois qualquer um deles terá um ou mais capítulos voltados para a explicação do modelo 
relacional. Entre os livros que podemos indicar estão:
19
Banco de Dados
 HEUSER, CARLOS ALBERTO. Projeto De Banco De Dados – Série Livros Didáticos, 
V.4. Bookman Companhia Ed., 6ª Edição - 2009
 SILBERSCHATZ, Abraham; KORTH, Henry F; SUDARSHAN, S. Sistema de banco de 
dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier; Campus, 2006.
 ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4a. ed. São 
Paulo: Pearson Education do Brasil, 2005.
 DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Campus, 
2000.
 ALVES, W.P. Fundamentos de Bancos de Dados. Editora Érica, 2004.
Você Sabia? 
As 12 Regras de Codd
Você sabia que Edgard F. Codd, em 1985, estabeleceu as 12 regras de Codd que 
determinam o quanto um banco de dados é relacional? Pois é. A título de conhecimento, 
vamos apresentá-las a seguir. Lembramos que nem todas as regras serão completamente 
compreendidas nesse momento, mas o serão até o final da disciplina. Adicionalmente, vale 
a pena saber que nem todos os SGBDs relacionais fornecem suporte a todas elas. 
Regra 1 - Regra das informações em tabelas: As informações a serem armazenadas 
no banco de dados devem ser apresentadas como relações (tabelas formadas por linhas e 
colunas) e o vínculo de dados entre as tabelas deve ser estabelecido por meio de valores de 
campos comuns (chaves estrangeiras). 
Regra 2 - Regra de acesso garantido: Todo e qualquer valor atômico em um BD 
relacional possui a garantia de ser logicamente acessado pela combinação do nome da 
tabela, do valor da chave primária e do nome do campo/coluna que deseja acessar. Isso 
porque, com o nome da tabela, se localiza a tabela desejada. Com o valor da chave primária 
a tupla desejada dentro da tabela é localizada. E com o nome do campo/coluna se acessa a 
parte desejada da tupla.
Regra 3 - Regra de tratamento sistemático de valores nulos: Valores nulos devem 
ser suportados de forma sistemática e independente do tipo de dado para representar 
informações inexistentes e informações inaplicáveis. Deve-se sempre lembrar que valores 
nulos devem ter um tratamento diferente de “valores em branco”.
Regra 4 - Regra do catálogo relacional ativo: Toda a estrutura do banco de dados 
(domínios, campos, tabelas, regras de integridade, índices, etc) deve estar disponível em 
tabelas (também referenciadas como catálogo). Sua manipulação é possível por meio de 
linguagens específicas (por exemplo, SQL). Essas tabelas são, geralmente, manipuladas pelo 
próprio sistema no momento em que o usuário efetua alterações na estrutura do banco de 
dados (por exemplo, a inclusão de um novo atributo em uma tabela).
Regra 5 - Regras de atualização de alto-nível: Essa regra diz que o usuário deve 
ter capacidade de manipular as informações do banco de dados em grupos de registros, ou 
seja, ser capaz de inserir, alterar e excluir vários registros ao mesmo tempo7.
Regra 6 - Regra de sub-linguagem de dados abrangente: Pelo menos uma 
linguagem, com sintaxe bem definida, deve ser suportada, para que o usuário possa 
Comentário
7 Veremos como fazer 
isso no último volume 
desta disicplina, 
quando estivermos 
estudando a linguagem 
SQL.
20
Banco de Dados
manipular a estrutura do banco de dados (como criação e alteração de tabelas), assim 
como extrair, inserir, atualizar ou excluir dados, definir restrições de integridade e de acesso 
e controle de transações (commit e rollback8, por exemplo). Deve ser possível ainda a 
manipulação dos dados por meio de programas aplicativos.
Regra 7 - Regra de independência física: Quando for necessária alguma 
modificação na forma como os dados estão armazenados fisicamente, nenhuma alteração 
deve ser necessária nas aplicações que fazem uso do banco de dados (isolamento), assim 
como devem permanecer inalterados os mecanismos de consulta e manipulação de dados 
utilizados pelos usuários finais.
Regra 8 - Regra de independência lógica: Qualquer alteração efetuada na estrutura 
do banco de dados como inclusão ou exclusão de campos de uma tabela ou alteração no 
relacionamento entre tabelas não deve afetar o aplicativo utilizado ou ter um baixo impacto 
sobre o mesmo. Da mesma forma, o aplicativo somente deve manipular visões9 dessas 
tabelas.
Regra 9 - Regra de atualização de visões: Uma vez que as visões dos dados de uma 
ou mais tabelas são, teoricamente, suscetíveis a atualizações, então um aplicativo que faz 
uso desses dados deve ser capaz de efetuar alterações, exclusões e inclusões neles. Essas 
atualizações, no entanto, devem ser repassadas automaticamente às tabelas originais. Ou 
seja, a atualização em uma visão deve refletir na atualização das tabelas representadas por 
essa visão.
Regra 10 - Regra de independência de integridade: As várias formas de integridade 
de banco de dados (integridade de entidade, integridade referencial e restrições de 
integridade complementares) precisam ser estabelecidas dentro do catálogo do sistema ou 
dicionário de dados e serem totalmente independentes da lógica dos aplicativos. Assim, os 
aplicativos não devem ser afetados quando ocorrerem mudanças nas regras de restrições 
de integridade. 
Regra 11 - Regra de independência de distribuição: Alguns SGBDs, notadamente os 
que seguem o padrão SQL, podem ser distribuídos em diversas plataformas/equipamentos 
que se encontrem interligados em rede. Essa capacidade de distribuição não pode afetar a 
funcionalidade do sistema e dos aplicativos que fazem uso do banco de dados. Em resumo, 
as aplicações não são logicamente afetadas quando ocorrem mudanças geográficas dos 
dados (caso dos BDs distribuídos).
Regra 12 - Regra não-subversiva: O sistema deve ser capaz de impedir qualquer 
usuário ou programador de transgredir os mecanismos de segurança, regras de integridade 
do banco de dados e restrições, utilizando algum recurso de linguagem de baixo nível que 
eventualmente possam ser oferecidos pelo próprio sistema.
Aprenda Praticando
Vamos dar uma olhada novamente em questões de concurso?
NCE-UFRJ - 2001 - TRE-RJ - Analista Judiciário - Especialidade - Análise de Sistemas 
- Desenvolvimento
1) Sobre os conceitos de domínio, atributo e relacionamento, é correto afirmar que: 
a) Um domínio é definido pelo conjunto dos atributos pertencentes a um 
relacionamento;
Comentário
8 Commit serve 
para confirmar as 
operações realizadas 
no banco de dados. 
Rollback serve para 
desfazer uma operação 
que ainda não tenha 
sido confirmada.
Comentário
9 Visão: é uma relação 
virtual que não faz 
parte do esquema 
conceitual do BD, mas 
que é visível a um 
grupo de usuários. Em 
outras palavras, uma 
visão é uma tabela 
virtual que é definida 
a partir de outras 
tabelas, contendo 
sempre os dados 
atualizados.
21
Banco de Dados
b) Domínio e atributo representam um único conceito semântico;
c) Um atributo é considerado identificador se pertencer ao domínio que define 
um relacionamento;d) Todos os atributos de uma relação devem pertencer a um mesmo domínio;
e) Domínio são os valores possíveis que um atributo pode assumir.
2) A cardinalidade de uma relação é caracterizada por:
a) Número de atributos dessa relação;
b) Número de campos dessa relação;
c) Quantidade de chaves estrangeiras da relação;
d) Número de tuplas de uma relação;
e) Nenhuma das respostas anteriores.
3) Uma chave estrangeira:
a) Pode conter valores que não existem na Tabela-Pai (tabela referenciada);
b) Pode não pertencer à chave primária;
c) Tem de pertencer, obrigatoriamente, à chave primária;
d) Podem sempre assumir o valor nulo;
e) Nenhuma das respostas anteriores.
Fundação Getúlio Vargas – 2008
4) No contexto de Banco de Dados, um conceito assegura que um valor que aparece 
em uma tabela para um determinado conjunto de atributos apareça em outro 
conjunto de atributos de outra tabela. Por exemplo, se cristalina é o nome de uma 
agência que aparece em uma tupla da tabela conta, então deve existir uma tupla 
cristalina na tabela agencia. Esse conceito é definido como um sistema de regras, 
utilizado para garantir que os relacionamentos entre tuplas de tabelas relacionadas 
sejam válidas e que não exclui ou altera, acidentalmente, dados relacionados. Trata-
se do seguinte conceito:
a) Integridade Funcional;
b) Dependência Funcional;
c) Integridade Relacional;
d) Dependência Referencial;
e) Integridade Referencial.
(Técnico de Tecnologia da Informação/UFT/FCC/2005)
5) Os dois principais tipos de integridade a serem mantidos em um banco de dados 
relacional adequadamente projetado são:
a) Integridade Existencial e Integridade Permanente;
b) Integridade de Entidade e Integridade de Relacionamento;
c) Integridade de Entidade e Integridade Referencial;
d) Integridade Permanente e Integridade Referencial;
e) Integridade Existencial e Integridade de Entidade.
22
Banco de Dados
(Administrador/PM SANTOS/FCC/2005)
6) Um tipo de dado específico, por exemplo, Nome do Funcionário é armazenado 
numa localização da estrutura do banco de dados denominada.
a) Tabela;
b) Linha;
c) Planilha;
d) Coluna;
e) Registro.
Respostas:
1) E – O domínio de um atributo são os valores que ele pode assumir. Ou seja, é o tipo 
deste atributo. Por exemplo, o atributo dia do mês tem como domínio os valores 
naturais entre 1 e 31.
2) C – A cardinalidade de uma relação é o número de linhas ou tuplas dessa relação. 
Assim, uma relação com quatro tuplas, tem cardinalidade 4.
3) B – Uma chave estrangeira pode não pertencer à chave primária, não pode conter 
valores que não existam na tabela-pai e só podem assumir valor nulo se não 
pertencer à chave primária da tabela onde é chave estrangeira.
4) E – Integridade Referencial. Ela checa todas as validações necessárias referentes ao 
uso de chaves estrangeiras.
5) C – Os dois principais tipos de integridade que podem ser verificados em um BD 
relacional são a integridade de entidade (que se referem às checagens da chave 
primária) e a integriadade referencial (que se refere às checagens da chave 
estrangeira).
6) D – Nome do funcionário é tipicamente um atributo e um atributo é representado 
no BD relacional por uma coluna.
Atividades e Orientações de Estudo
Agora vamos exercitar o que foi estudado neste capítulo. Assim sendo, faça as 
atividades sugeridas a seguir. Lembre que exercitar vai ajudá-lo(a) a fixar melhor o conteúdo 
estudado. E o conteúdo desse capítulo é fundamental para o capítulo seguinte, onde vamos 
aprender a construir o Modelo Relacional. Mãos à obra!
Atividades Práticas:
Para colocar o aprendido em prática, responda as questões a seguir. (Exercícios 
adaptados do livro de Carlos Heuser (1998) - capítulo 4).
» Exercício 1: Abaixo aparecem diversos esquemas de relação que compõem um 
banco de dados relacional. Identifique nestes esquemas, da maneira apropriada, 
as chaves primárias e chaves estrangeiras:
Aluno (CodigoAluno,Nome,CodigoCurso)
Curso(CodigoCurso,Nome)
23
Banco de Dados
Disciplina(CodigoDisciplina,Nome,Creditos,CodigoDepartamento)
Curriculo(CodigoCurso,CodigoDisciplina,Obrigatória-Opcional)
Conceito(CodigoAluno,CodigoDisciplina,Ano-Semestre,Conceito)
Departamento(CodigoDepartamento,Nome)
» Exercício 2: Considere o esquema das relações de um BD relacional a seguir:
Paciente(NumeroPaciente (PK), Nome, CodigoConvenio (FK))
Convenio(CodigoConvenio (PK), Nome)
Medico(CRM (PK), Nome, Especialização)
Consulta(CodigoConvenio (PK), NumeroPaciente (PK), CRM(PK), Data-Hora)10
 A partir desse esquema, explique que verificações/checagens deveriam ser feitas 
pelo SGBD para garantir integridade referencial nas seguintes situações:
a) Uma linha é incluída na tabela Consulta.
b) Uma linha é excluída da tabela Paciente.
Vamos Revisar?
Você estudou, neste capítulo, os conceitos básicos referentes ao modelo relacional. 
Entre eles, os conceitos de tabela ou relação, tuplas ou linhas, atributos ou colunas e chaves 
(chave candidata, primária, secundária e estrangeira). Esses conceitos serão todos utilizados 
no próximo capítulo onde você aprenderá a derivar o modelo relacional a partir do modelo 
entidade-relacionamento. Adicionalmente, foram vistos também neste capítulo os principais 
tipos de integridade (de entidade e referencial), além de integridades complementares e 
integridade semântica.
Comentário
10 Aproveitamos 
esse exercício para 
lembrar que quando 
um campo é chave 
estrangeira e também 
chave primária 
de uma tabela, 
a representação 
predominante é a 
de chave primária. 
Por isso, apesar de 
CodigoConvenio, 
NumeroPaciente e 
CRM serem chaves 
estrangeiras vindas 
das tabelas Convenio, 
Paciente e Médico, 
respectivamente, o 
símbolo usado ao lado 
dos atributos é o PK de 
chave primária.
24
Banco de Dados
Capítulo 8
O que vamos estudar neste capítulo?
Neste capítulo, vamos estudar os seguintes temas:
» Como derivar o MR a partir do MER.
Metas
Após o estudo deste capítulo, esperamos que você consiga:
» Derivar o MR a partir do MER.
» Verificar a corretude do modelo derivado.
25
Banco de Dados
Capítulo 8 – Derivando o MR a partir 
do MER
Vamos conversar sobre o assunto?
“Vimos no capítulo anterior os conceitos básicos do modelo relacional. Porém, 
ainda não vimos como gerar o modelo relacional, que faz parte da modelagem lógica do 
banco de dados, que é a terceira etapa do projeto de banco de dados como um todo. A 
melhor maneira de produzir o modelo relacional é derivá-lo a partir do modelo entidade-
relacionamento. Para fazer isso, existem algumas regras. São justamente essas regras que 
discutiremos neste capítulo.”
Neste capítulo, você vai aprender como derivar o MR a partir do MER, para isso, 
todas as instruções de como fazer isso serão dadas. Vamos lá?
Algumas Informações Iniciais
A terceira fase do projeto de banco de dados é o projeto lógico que objetiva mapear 
o modelo de dados conceitual para o modelo de dados relacional. Essa fase dá origem ao 
esquema lógico representado pelo modelo relacional que já é um modelo que depende do 
SGBD e será usado para implementar o banco de dados.
É comum, em projetos de banco de dados, se realizar a modelagem dos dados 
através de um modelo de dados de alto-nível. O modelo de dados de alto-nível normalmente 
adotado é o Modelo Entidade-Relacionamento (MER) e o esquema das visões e de toda 
a base de dados são especificados em diagramas entidade-relacionamento (DER). O passo 
seguinte à modelagem dos dados conceitual é o mapeamento do diagrama da base de 
dados global para um modelo de dados de implementação. Existem três tipos de modelos 
de dados de implementação: hierárquico, rede e relacional. Para cada um desses modelos, 
podem-se definir estratégias de tradução a partir do DER. A estratégia de tradução, ou de 
mapeamento, que trataremos neste capítulo e nesta disciplina será apenas para o modelo 
de dados relacional.
O Modelo Relacional é a representação do modelo lógico do projeto de banco 
de dados, sendo que a forma de representaçãodos conceitos necessários ao projeto 
deve passar a ser mais detalhada e se aproximar um pouco mais da representação física. 
Dessa forma, várias mudanças devem ser realizadas no DER gerado na fase de modelagem 
conceitual, como, por exemplo: entidades passam a ser representadas por relações ou 
tabelas. Atributos passam a ser representados em colunas. O atributo identificador passa 
a ser a chave primária (PK) da tabela. Os relacionamentos e as dependências passam a 
ser representados por chaves estrangeiras (FK) e assim por diante. Na Figura 3, pode ser 
visto um exemplo do resultado da transformação de um MER em MR. Cada etapa desse 
mapeamento será estudada na seção a seguir.
26
Banco de Dados
Figura 3 - Passagem do MER para o MR
Regras para Derivar o Modelo Relacional a 
partir do MER
Agora, iremos estudar cada uma das etapas de derivação do MR a partir do MER. 
» Mapeamento de Entidades Fortes – Cada conjunto de entidades fortes é mapeado 
como uma relação que envolve todos os atributos da entidade correspondente do 
DER. Assim, para cada entidade regular E no DER, criar uma relação R que inclua 
todos os atributos simples de E. Se houver atributos compostos, inclua apenas 
os atributos simples que compõem o atributo composto (ou seja, decomponha o 
atributo composto). O(s) atributo(s) identificador(es) da entidade E deve(m) ser 
marcado(s) como chave primária da relação R. Por exemplo, suponha a entidade 
Aluno que possui dois atributos CPF e Nome, sendo o CPF o atributo identificador da 
entidade (vide Figura 4). No MR, seria criada uma relação ou tabela de nome Aluno, 
com duas colunas (atributos) CPF, que deveria ser marcado como chave primária 
(PK) e Nome. Como, anteriormente explicado, se houvesse atributos compostos, 
esses deveriam ser substituídos pelos atributos simples que o compõem (vide 
Figura 5). Assim, o atributo Endereço, que é composto pelos atributos Rua, Numero 
e Bairro, seria representado na relação apenas por estes últimos.
Figura 4 - Exemplo de Mapeamento de Entidade Forte
27
Banco de Dados
Figura 5 - Exemplo de mapeamento de atributo composto
» Mapeamento de Atributos Multivalorados – Os atributos multivalorados vão se 
tornar relações cujas chaves primárias serão compostas pela chave da entidade 
possuidora do atributo mais o atributo multivalorado, agora como monovalorado. 
Ou seja, para cada atributo A multivalorado, deve-se criar uma nova relação R que 
inclua o atributo multivalorado A e a chave-primária K da relação que representa o 
tipo de entidade ou o tipo de relacionamento que tem A como atributo. O detalhe 
é que a chave-primária da relação R será composta por K e pelo atributo A. Se o 
atributo multivalorado for composto, você deve seguir a instrução anteriormente 
dada de decompô-lo (usar os atributos simples que o compõem). Por exemplo, 
suponha a entidade Empregado (vide Figura 6). Ela possui os atributos CPF e Nome 
simples e o atributo Telefone que é multivalorado. Essa entidade seria mapeada 
para a relação Empregado (pela regra já descrita anteriormente) e o atributo 
mutivalorado Telefone daria origem a outra relação, que chamamos de Telefone_
Empregado, contendo a chave primária da relação Empregado (que originou-se da 
entidade possuidora do atributo) e o atributo valorado, também fazendo parte da 
chave primária dessa nova relação.
Figura 6 - Exemplo mapeamento de atributo multivalorado
» Mapeamento de Entidades Fracas – São mapeadas em uma relação formada por 
todos os atributos da entidade fraca mais os atributos que formam a chave primária 
da relação da qual a entidade fraca depende. O relacionamento não é mapeado. 
Assim, para cada tipo de entidade fraca EF do DER, criar uma relação R e incluir 
todos os atributos simples (ou os componentes simples de atributos compostos) de 
28
Banco de Dados
EF como atributos de R. Além disso, incluir como integrante da chave primária de R, 
a chave-primária da relação que corresponde à entidade forte, da qual a entidade 
fraca depende. Logo, a chave primária da entidade fraca deverá ser formada pela 
chave primária da relação que representa a entidade forte da qual a entidade 
fraca depende e pelo atributo identificador da entidade fraca. Por exemplo, vide 
a Figura 7. A entidade forte Empregado foi mapeada para a relação Empregado, 
como explicado anteriormente. A entidade fraca Dependente deu origem a uma 
relação cuja chave primária é formada pela chave primária de empregado (CPF) e 
pelo identificador da própria entidade fraca (RG), além do atributo adicional Nome. 
Figura 7 - Exemplo de mapeamento de entidade fraca
» Mapeamento de Relacionamentos Binários 1:1 – Esse tipo de relacionamento 
não é mapeado em uma nova relação. Seus atributos são colocados em qualquer 
uma das relações que mapeiem as entidades fortes envolvidas no relacionamento. 
A entidade forte escolhida para receber os atributos do relacionamento receberá, 
também, a chave primária da outra entidade envolvida como CHAVE ESTRANGEIRA. 
Assim, temos que, para cada tipo de relacionamento binário 1:1 R do DER, devem-
se criar as relações E1 e E2 que correspondem ao mapeamento das entidades 
fortes participantes do relacionamento R. Depois, deve-se escolher uma das 
relações, por exemplo, E1, para incluir nela, como chave-estrangeira, a chave-
primária de E2. Devem-se incluir também em E1 todos os atributos simples (ou os 
componentes simples de atributos compostos) do relacionamento R. Por exemplo, 
suponha que “Um empregado trabalha em uma empresa e uma empresa possui 
um único empregado. Deve ser guardada a data de admissão desse empregado na 
empresa” (vide Figura 8). Esse é um relacionamento binário 1:1. Para mapeá-lo para 
o MR, devem-se criar duas relações: Empregado e Empresa, conforme a maneira 
anteriormente explicada para mapeamento de entidades fortes. Depois, seria 
escolhida uma das relações (suponha que escolhemos a relação Empregado) para 
receber os atributos do relacionamento (no caso, Dt_admissao) e a chave primária 
da relação que não for a escolhida (no caso, a chave primária da Relação Empresa 
que é o atributo Codigo), como chave estrangeira (vide Figura 8). Se a entidade 
escolhida fosse a relação Empresa (a escolha é sua) seria necessário colocar a chave 
primária da entidade Empregado, como chave estrangeira, na relação Empresa, 
assim como adicionar a ela o(s) atributo(s) do relacionamento. Todas as duas 
abordagens seriam possíveis.
29
Banco de Dados
Figura 8 - Exemplo de mapeamento de relacionamento binário 1:1
» Mapeamento de Relacionamentos Binários 1:N – Esse tipo de relacionamento 
não é mapeado em uma nova relação. Seus atributos são colocados na relação 
que mapeia a entidade forte do lado com cardinalidade N. A chave primária da 
entidade forte do lado onde a cardinalidade é um, também, passa a fazer parte, 
como chave estrangeira, da entidade forte do lado onde a cardinalidade é N. Ou 
seja, para cada tipo de relacionamento binário 1:N (que não envolva entidades 
fracas) R, você deve identificar a relação S que representa a entidade que participa 
do lado N do relacionamento. Depois, deve incluir em S, como chave-estrangeira, a 
chave-primária da relação T que representa a outra entidade que participa em R (a 
entidade do lado com cardinalidade um). Por fim, devem-se incluir como atributos 
de S, também, quaisquer atributos simples (ou componentes simples de atributos 
compostos) do relacionamento 1:N. Por exemplo, suponha que “Uma empresa 
tem zero ou mais empregados e um empregado trabalha para uma e apenas uma 
empresa” (vide Figura 9). Esse é um relacionamento binário 1:N. Para mapeá-
lo para o MR, devem-se criar duas relações Empregado e Empresa, conforme a 
maneira anteriormente explicada (mapeamento de entidade forte). Depois, deve-
se incluir na relação que representa a entidade do lado N do relacionamento 
(no caso, Empregado), como chave estrangeira, a chave primária da relação que 
representa a entidade do lado 1 (no caso, Empresa). Por fim, os atributosdo 
relacionamento devem também ser incluídos na relação do lado N. Diferentemente 
dos relacionamentos 1:1, aqui, obrigatoriamente o lado escolhido deveria ser o 
lado N do relacionamento para receber os atributos do relacionamento e a chave 
primária da outra entidade.
30
Banco de Dados
 
Figura 9 - Exemplo de mapeamento de relacionamento binário 1:N
» Mapeamento de Relacionamentos Binários M:N – O relacionamento é mapeado 
em uma nova relação que recebe os atributos do relacionamento e as chaves 
primárias das entidades envolvidas no relacionamento, como chave primária. 
Assim, a chave da relação que representa o relacionamento seria a concatenação 
das chaves primárias das entidades envolvidas (e, em alguns casos, também o 
atributo identificador do próprio relacionamento11). Então teríamos que, para 
cada relacionamento R binário do tipo M:N, deve-se criar uma nova relação S para 
representar este relacionamento R. Nesta nova relação seriam incluídas, como 
chave primária, as chaves-primárias das relações que representam as entidades 
participantes do relacionamento. Ou seja, a combinação dessas chaves-primárias 
irá formar a chave primária da nova relação S. Também seriam incluídos na relação 
S qualquer atributo simples do relacionamento M:N (ou componentes simples dos 
atributos compostos). Relacionamentos M:N sempre derivam uma nova relação 
para representar o relacionamento no modelo relacional. Por exemplo, temos que 
“Um projeto aloca zero ou mais empregados e um empregado pode trabalhar em 
zero ou mais projetos.” (vide Figura 10). Como o relacionamento é binário e M:N, 
seriam criadas três relações: Projeto, Empregado e Alocação (melhor passar o verbo 
para um substantivo, assim o relacionamento aloca passa a ser a relação alocação). 
As duas primeiras relações seriam criadas pela regra já vista de mapeamento de 
entidades fortes. Quanto ao relacionamento, ele daria origem a relação Alocação 
que teria como chave primária as chaves das duas relações que representam as 
entidades envolvidas no relacionamento (no caso, CPF e Código), além do atributo 
do próprio relacionamento (no caso, Dt_alocação).
Comentário
11 Isso ocorrerá quando 
for necessário que 
o relacionamento 
reflita algum aspecto 
temporal ou mantenha 
algum tipo de 
histórico. Consulte o 
capítulo 5 do Volume 
2 da disciplina para 
mais informações a 
respeito.
31
Banco de Dados
Figura 10 - Exemplo de mapeamento de relacionamento binário M:N
 Se, como mencionado anteriormente, fosse necessário armazenar algum aspecto 
temporal do relacionamento (no caso, guardar o histórico das alocações feitas), 
o atributo Dt_alocação do relacionamento viria no DER como identificador do 
Relacionamento (vide Figura 11). Isso faria com que esse atributo, no mapeamento, 
também passasse a fazer parte da chave primária da relação que representa 
esse relacionamento (no caso, a relação Alocação). Dessa forma, agora a relação 
Alocação possui três chaves primárias (CPF, Código e Dt_alocação), conforme pode 
ser visto na Figura 11. Consegue perceber o que muda? (Observe as Figuras 10 e 
11).
Figura 11 - Exemplo de mapeamento de relacionamento binário M:N (guardando aspecto temporal)
32
Banco de Dados
» Mapeamento de Relacionamentos Ternários, Quaternários, etc – Usualmente, 
mapeamos tais relacionamentos como se todos fossem de cardinalidade M:N. 
A relação será formada pelos atributos do relacionamento e as chaves primárias 
das entidades envolvidas neste relacionamento. Por exemplo, suponha o 
relacionamento ternário da Figura 12. Cada entidade forte seria mapeada em uma 
relação, conforme regra já vista. E o relacionamento matricula, seria mapeado na 
relação Matricula que seria composta pelas chaves primárias de cada uma das 
relações que representam as entidades envolvidas no relacionamento (no caso, 
Sigla, CPF e Código), mais o atributo existente no próprio relacionamento (no caso, 
Dt_matricula). Sendo que as chaves primárias comporiam as chaves primárias da 
própria relação.
Figura 12 - Exemplo de mapeamento de relacionamento ternário
» Mapeamento de Especialização/Generalização – Há dois casos. Primeiro, se 
a especialização for mutuamente exclusiva e total. Ou seja, nenhum elemento é 
membro de mais de uma entidade e se todas as entidades do nível superior forem 
membros dos níveis inferiores (por exemplo, todo cliente ou é pessoa física ou é 
pessoa jurídica, nunca será apenas um cliente). Neste caso, são criadas relações 
apenas para as especializações (entidades filhas, no nível inferior) e elas usarão 
como chave primária o atributo identificador da entidade de nível superior. Por 
exemplo, atente para a Figura 13. Temos que o Cliente foi especializado em Pessoa_
Fisica e Pessoa_Juridica e essa é uma especialização mutuamente exclusiva e total. 
Dessa forma, esse diagrama dará origem a duas relações. Ambas terão os atributos 
da entidade de nível superior (e a chave primária será o identificador da mesma – o 
código), além de seus próprios atributos.
33
Banco de Dados
Figura 13 - Exemplo de mapeamento de especialização/generalização total e mutuamente exclusiva
Se a especialização não for mutuamente exclusiva, deve ser criada uma tabela 
para cada entidade, todas tendo como chave primária o atributo identificador da entidade 
principal (de nível superior). Por exemplo, vide a Figura 14. Uma conta pode ser apenas 
uma conta normal, pode ser uma poupança ou uma conta de investimento. Assim, a 
especialização não é mutuamente exclusiva, como consequência, cada entidade dará 
origem a uma tabela e todas terão como chave primária a chave da entidade principal.
34
Banco de Dados
Figura 14 - Exemplo de mapeamento de especialização/generalização não exclusiva
» Agregação e Entidade Associativa – Envolvem um relacionamento entre 
relacionamentos. Para fazer o mapeamento, primeiro, criamos relações para 
todas as entidades envolvidas. Segundo, criamos uma relação para o primeiro 
relacionamento (a entidade associativa) que terá como chave primária as chaves 
primárias das entidades diretamente envolvidas. Terceiro, criamos uma relação para 
o relacionamento externo, contendo as chaves primárias de todas as entidades. Por 
exemplo, vide a Figura 15. Nela temos um exemplo de uso de entidade associativa 
para poder especificar que em uma consulta feita por um médico a um paciente, 
medicamentos podem ser prescritos. Cada entidade forte dará origem a uma 
relação. Depois, a entidade associativa Consulta também dará origem a uma 
relação que terá como chave primária as chaves das duas entidades diretamente 
envolvidas (no caso, Medico e Paciente) no relacionamento da entidade associativa. 
Por último, o relacionamento externo, que se liga com a entidade associativa (no 
caso, o relacionamento prescreve que passamos a chamar de prescrição no MR) 
também dará origem a uma relação que terá como chave primária a chave da 
entidade associativa e a chave da entidade que a ela se liga.
35
Banco de Dados
Figura 15 - Exemplo de mapeamento de diagrama envolvendo entidade associativa
» Mapeando Autorrelacionamentos –. Existem duas maneiras de transformar um 
autorrelacionamento (vide Figura 16) em relações:
Figura 16 - Exemplo de autorrelacionamento
› A primeira é usar para representar a entidade e seu autorrelacionamento 
apenas uma relação com duas ocorrências da chave primária. Por exemplo, 
o autorrelacionamento da Figura 16 que representa que um empregado 
é gerenciado por zero ou um empregado e esse empregado-gerente pode 
gerenciar zero ou mais empregados, daria origem a uma única relação 
chamada Empregado, onde haveria duas ocorrências da chave primária CPF: 
uma para o próprio empregado e outra para o seu gerente, como apresentado 
a seguir:
36
Banco de Dados
› A outra opção é criar duas relações, uma para representar a entidade e 
outra para representar o autorrelacionamento. Dessa forma, o DER da 
Figura 16 daria origem a duas relações: Empregado e Gerência. A relação 
Empregado seria mapeadada forma já explicada para entidades fortes. E 
o autorrelacionamento seria mapeado em uma relação que conteria duas 
entradas da chave primária da entidade: uma para o empregado e outra para 
o seu gerente, como apresentado a seguir.
Considerações Finais
O principal ponto que deve ser considerado em um esquema relacional, quando 
comparado ao esquema do MER, é que os relacionamento não são mais representados 
explicitamente. Eles passam a ser representados no MR através do uso de chaves 
estrangeiras.
Uma vez que o modelo relacional esteja pronto, ele deve ser normalizado 
(otimizado). "Como fazer isso" é assunto do próximo capítulo. Depois, com o MR 
Normalizado, o projeto do banco de dados estará pronto para passar da sua fase lógica 
(Projeto Lógico), para a fase física, o Projeto Físico ou de Implementação.
Conheça Mais
Alguns livros que podem ser usados para aprofundar o estudo nesse capítulo são:
 HEUSER, CARLOS ALBERTO. Projeto de Banco De Dados – Série Livros Didáticos, 
V.4. Bookman Companhia Ed., 6ª Edição - 2009
 SILBERSCHATZ, Abraham; KORTH, Henry F; SUDARSHAN, S. Sistema de banco de 
dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier;Campus, 2006.
 ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4a. ed. São 
Paulo: Pearson Education do Brasil, 2005.
 DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Campus, 
2000.
 ALVES, W.P. Fundamentos de Bancos de Dados. Editora Érica, 2004.
37
Banco de Dados
Aprenda Praticando 
A partir das regras de mapeamento estudadas neste capítulo, mapeie o MER a 
seguir para o MR, apresentando o esquema das relações que são originadas.
Vamos começar o mapeamento pela especialização/generalização do lado esquerdo 
do diagrama. Se observar, a especialização do diagrama é mutuamente exclusiva e total. Um 
cliente não pode ser pessoa física e jurídica. Ele ou é pessoa física ou é pessoa jurídica. 
Também, ele não pode ser simplesmente um cliente. Dessa forma, precisamos criar relações 
apenas para as especializações (entidades filhas, no nível inferior), no caso Pessoa_Fisica e 
Pessoa_Juridica. E, essas relações usarão como chave primária o atributo identificador da 
entidade de nível superior (no caso Cliente).
Uma vez mapeada a especialização, vamos tratar agora de mapear o relacionamento 
38
Banco de Dados
superior (circulado no diagrama acima). Se observar, esse é um relacionamento 1:N. E, como 
vimos, em relacionamento binário 1:N, os atributos chaves da entidade com cardinalidade 1 
são mapeados (passam a fazer parte) da entidade com cardinalidade N, bem como qualquer 
atributo que o relacionamento tivesse (o que não é o caso, pois o relacionamento possui 
não tem nenhum atributo). Logo, ficaríamos com:
Não é tão complicado! Quanto mais você exercitar, mais vai memorizar as regras e 
conseguir aplicá-las com mais facilidade. Porém, para isso, você realmente precisa praticar!
Atividades e Orientações de Estudo
Agora é a sua vez de fazer as atividades! Lembre-se: praticar é muito importante 
para fixar o conteúdo estudado!
Atividades Práticas
A partir das regras de mapeamento estudadas neste capítulo, mapeie os MER, a 
seguir, para o MR, apresentando o esquema das relações que são originadas.
a) Controle Acadêmico
39
Banco de Dados
b) Controle Farmácia
Vamos Revisar?
A modelagem lógica que vem em seguida a modelagem conceitual é caracterizada 
pela criação do modelo relacional (MR). Uma das formas de criar esse modelo é derivando 
o mesmo a partir do modelo entidade-relacionamento, criado na etapa anterior de 
modelagem conceitual. Para derivar o modelo, existem diversas regras que seguidas, 
produzem os esquemas relacionais. Foram justamente essas regras que foram apresentadas 
nesse capítulo, bem como alguns exemplos de mapeamento do MER para o MR. No 
próximo capítulo, veremos como otimizar os esquemas relacionais através da normalização 
de dados. Até lá!
40
Banco de Dados
Capítulo 9
O que vamos estudar neste capítulo?
Neste capítulo, vamos estudar os seguintes temas:
» Dependências Funcionais.
» Normalização de Dados.
Metas
Após o estudo deste capítulo, esperamos que você:
» Saiba o que são dependências funcionais.
» Saiba normalizar o seu modelo relacional, pelo menos, até a 3ª Forma Normal.
» Conheça todas as formais normais 1FN, 2FN e 3FN, além da forma normal de Boyce-
Codd.
41
Banco de Dados
Capítulo 9 – Normalização de Dados
Vamos conversar sobre o assunto?
Projetar um banco de dados relacional significa agrupar atributos para formar bons 
esquemas de relações. Mas o que seria um bom esquema? Em nível geral, poderíamos dizer 
que seria um esquema fácil de entender e em que as tuplas da relação fossem armazenadas 
e acessadas de forma eficiente. Para isso, é preciso que sejam minimizadas, ao máximo, 
a redundância nos dados e as anomalias de inserção, atualização e exclusão. Além disso, 
é preciso garantir a integridade dos dados, evitando que informações sem sentido sejam 
inseridas e é preciso organizar e dividir as tabelas da forma mais eficiente possível. Uma 
forma de colaborar com essas necessidades é fazer a normalização dos dados. Esse é 
justamente o assunto deste capítulo.
Neste capítulo, estudaremos o que são dependências funcionais, seu impacto sobre 
os dados e como realizar a otimização do MR através da normalização dos dados. Vamos lá?
Dependências Funcionais
Sempre que um atributo X identifica um atributo Y dizemos que entre eles há uma 
dependência funcional12. Temos, portanto, que X é o determinante e que Y é o dependente. 
A representação é: X → Y. Em outras palavras, se o valor de um atributo X permite descobrir 
o valor de um outro atributo Y, dizemos que X determina funcionalmente Y. Por exemplo, 
dada uma determinada cidade (não considerando cidades homônimas) sabemos o seu 
estado e com o estado temos o país. Isso é representado da seguinte forma:
Cidade → estado
Estado → país
Em outras palavras, estado é funcionalmente dependente de cidade e país é 
funcionalmente dependente de estado. Ou ainda, cidade determina estado e estado 
determina país.
Logo, a dependência funcional é caracterizada pela existência de campos em uma 
determinada tabela relacional cuja ocorrência de valores está associada a valores que 
são preenchidos em outros campos na mesma tabela. Por exemplo, suponha uma tabela 
EMPREGADO que possui dois atributos CPF e NOME. O atributo NOME é funcionalmente 
dependente do atributo CPF. Assim, CPF → Nome. Com isso, queremos dizer que nome é 
função do CPF, ou seja, se eu tiver um número de CPF, poderei encontrar o nome da pessoa 
correspondente. Em outras palavras, CPF determina o Nome (vide Figura 17).
Você Sabia?
12 O Modelo Relacional 
pegou emprestado da 
teoria de funções da 
matemática o conceito 
de dependência 
funcional.
42
Banco de Dados
Figura 17 – CPF determina o Nome
Para efetuar a normalização de um modelo de dados relacional, como veremos 
daqui a pouco, alguns tipos de dependências funcionais são de extrema relevância:
» Dependência Parcial – Ocorre quando a chave primária é composta e existe um 
campo da relação que depende somente de parte desta chave primária composta. 
Por exemplo, veja a Relação Alocação (vide Tabela 12). Ela possui a chave composta 
CPF_Empregdo e Cod_Projeto. O ideal seria que todos os campos (atributos) da 
relação dependessem (fossem funcionalmente dependentes) da chave primária 
total, completa. Porém, o campo Nome_Empregado depende apenas de parte da 
chave primária (no caso, do CPF_Empregado). O mesmo ocorre com o atributo 
Nome_Projeto que só depende do atributo Cod_Projeto. Apenas o atributo Horas_
Trabalhadas é funcionalmente dependente da chave primária completa (porque 
para determinar as horas trabalhadas, precisamos saber o CPF do empregado e 
para qual projeto ele está trabalhando através do código do projeto).
Tabela 12 - Relação Alocação
CPF_Empregado 
(PK)
Cod_
Projeto (PK)
Nome_Empregado Nome_Projeto Horas_Trabalhadas
123456 11Ana Maria Gomes SoftHouse 40
654321 22 José da Silva HardCore 20
789654 33 Cláudio Alencar LinuxP 40
» Dependência Transitiva – Ocorre quando uma coluna depende não somente da 
chave primária da tabela, mas também de uma segunda coluna (ou conjunto de 
colunas) da tabela, que não fazem parte da chave primária. Em outras palavras, 
a dependência funcional transitiva é a dependência funcional indireta existente 
entre dois ou mais atributos. Assim, se um atributo C depende funcionalmente de 
um atributo B e o atributo B depende funcionalmente de um atributo A, então diz-
se que o atributo C depende indiretamente (transitivamente) do atributo A (vide 
Figura 18).
43
Banco de Dados
Figura 18 - Exemplo de dependência transitiva
Por exemplo, a relação Pedido_Venda (vide Tabela 13) tem como chave primária 
o atributo Cod_Pedido. Os atributos Data_Pedido, Situação_Pedido e CPF_Cliente 
dependem funcionalmente dessa chave primária. Porém, o atributo Nome_Cliente depende 
funcionalmente do CPF_Cliente (que não é a chave primária) e, apenas, indiretamente do 
Cod_Pedido, o que é uma anomalia, visto que, todos os atributos de uma relação deveriam 
depender funcionalmente apenas da sua chave primária.
Tabela 13 - Relação Pedido_Venda
Cod_Pedido 
(PK)
Data_Pedido Situação_Pedido CPF_Cliente Nome_Cliente
1 18/03/2010 Pendente 123456 Pedro Alves
2 22/02/2010 Entregue 654211 Carolina Dantas
3 10/01/2010 Entregue 987654 Olívia Duncan
» Dependência Multivalorada – Ocorre quando o valor de um atributo determina 
um conjunto de valores de um outro atributo. Por exemplo, até agora vimos que 
um atributo (que deve ser a chave primária da relação) determina outro atributo: 
CPF → Nome (ou seja, o CPF determina o nome, sendo um nome para cada 
CPF). Porém, se considerarmos: CPF → Dependente teremos um problema para 
expressar a realidade, porque através de um CPF poderia ocorrer de mais de um 
dependente ser determinado e não apenas um. Isso caracteriza uma dependência 
multivalorada. Uma dependência multivalorada é representada por X →→ Y (que 
quer dizer, X multidetermina Y ou Y é multidependente de X).
Uma dependência funcional (DF) é uma propriedade do esquema da relação e não de uma 
instância particular da relação (tupla). Assim, uma DF não pode ser automaticamente inferida a 
partir de algumas tuplas da relação, mas deve ser definida por alguém que conheça a semântica 
dos atributos da relação. Isso, porque a DF deve ser válida para todas as tuplas de uma relação, ou 
seja, para a definição do esquema da relação como um todo.
Anomalias de Atualização
A mistura de atributos de várias entidades pode gerar problemas conhecidos como 
anomalias de atualização e essas anomalias podem, por sua vez, causar problemas tais 
como a ocorrência de: 
44
Banco de Dados
» Grupos repetitivos de dados;
» Dependências parciais de chave;
» Redundâncias desnecessárias de dados; 
» Perdas acidentais de informações; 
» Dificuldade de representação de fatos da realidade (modelos); e
» Dependências transitivas entre atributos.
As anomalias de atualização podem ser de 3 tipos:
» Anomalias de inserção – Causam a repetição desnecessária de dados (redundância);
» Anomalias de alteração – Levam as inconsistências e aumentam o esforço para a 
atualização dos dados;
» Anomalias de exclusão - Causam a perda de informações associadas a um dado 
registro.
Para ficar mais claro, vamos demonstrar essas anomalias através de exemplos.
Exemplo 1 - Considere uma única relação VENDAS para representar as informações 
sobre os negócios de uma loja de CDs (vide Tabela 14)
Tabela 14 - Relação Vendas
Nome_Cliente 
(PK)
Cod_CD (PK) Dt_Compra (PK) Nome_CD Cantor Preço
Carlos Veneza 22 20/05/2009 Tribalistas Tribalistas 22,00
Juliano Morais 10 13/02/2010 Siderado Skank 10,00
Joana Pena 45 10/10/2009 Amarantine Enya 18,00
Agora imagine a seguinte situação: o cliente João Pontes deseja comprar 5 CDs 
iguais (por exemplo, Perfil de Ivete Sangalo, que custa 15 reais). Como essa operação 
refletiria na Relação Vendas? Seria possível realizá-la?
O primeiro problema seria: como não podemos ter mais de uma tupla com a 
mesma chave primária, o cliente não poderia comprar os 5 cds no mesmo dia. Isso, porque, 
se comprasse, haveria 5 tuplas com a mesma chave primária (Nome_Cliente, Cod_CD e Dt_
Compra), o que não seria possível. Se o cliente comprasse em dias diferentes, mesmo assim, 
poderiam ser observadas as seguintes anomalias:
» Anomalia de inserção – Redundância em quase todas as colunas (5 linhas 
praticamente iguais – mudando só o campo Dt_Compra - na tabela), afinal, é o 
mesmo CD e o mesmo cliente.
» Anomalia de alteração – Se houvesse um aumento de preço do CD, a atualização 
do preço deveria ser feita em todas as linhas referentes àquele CD na tabela.
» Anomalia de exclusão – A tabela só guarda registro dos CDs que foram comprados. 
Dessa forma, se só ocorreu uma única venda de um CD e ela fosse apagada, não 
haveria na loja mais nenhuma informação sobre aquele CD.
Exemplo 2 – Suponha que você criou uma relação Empregado para armazenar as 
informações sobre os empregados de uma empresa X qualquer (vide Tabela 15).
45
Banco de Dados
Tabela 15 - Relação Empregado
CPF (PK) Nome_Emp Endereco_Emp Cod_Depto Nome_Depto
123456 Carlos Veneza R. das Flores, 10 12 Vendas
987654 Juliano Morais R. ABC, 230 55 Suporte
007654 Joana Pena Av. João XX, 11 43 Financeiro
Na relação criada dessa forma, é possível observar as seguintes anomalias de 
atualização:
» Anomalia de inserção - Para inserir uma nova tupla Empregado na relação 
Empregado, deve-se incluir, também, valores para os atributos do departamento 
em que o empregado trabalha ou colocar null em qualquer campo referente 
ao departamento. Além disso, deve-se tomar cuidado ao inserir dados de um 
departamento que já conste na tabela. Por exemplo, para inserir uma nova tupla 
para um empregado que trabalhe no departamento 55, é preciso tomar cuidado 
para poder assegurar que os valores dos atributos sejam inseridos corretamente, 
tal que fiquem consistentes com os valores do departamento 55 que já existe na 
relação (segunda linha da Tabela 15), senão, seriam inseridos dados inconsistentes 
na relação. Adicionalmente, seria difícil inserir um novo departamento que ainda 
não tivesse empregados na relação Empregado. A única maneira de fazer isso seria 
colocar valores null nos atributos relativos aos empregados. Porém, isso provocaria 
um problema, pois o CPF do empregado faz parte da chave primária da relação 
Empregado, e supõe-se que cada tupla deva representar um empregado e não um 
departamento. 
» Anomalia de alteração - Se for mudado o valor de um dos atributos de um 
departamento qualquer, por exemplo, se o nome do departamento 43 passa a ser 
“Administração”, esse valor precisaria ser mudado em todas as tuplas referentes a 
todos os empregados que trabalhassem neste departamento ou a base de dados se 
tornaria inconsistente.
» Anomalia de remoção - Se for removida uma tupla da relação Empregado e esta for 
a última ocorrência de um departamento em particular (por exemplo, remover o 
empregado “Carlos Veneza”), a informação correspondente ao departamento seria 
perdida (no caso, as informações sobre o departamento “Vendas”). 
De acordo com as anomalias exemplificadas acima, pode-se verificar a importância 
de projetar esquemas de relações de maneira que nenhuma anomalia de atualização ocorra. 
Neste contexto, podem ser usadas as técnicas de normalização, pois um dos objetivos das 
mesmas é justamente evitar anomalias de atualização no banco de dados. Veremos essas 
técnicas ainda neste capítulo.
O que é Normalização?
Em 1970, o Professor Dr. Edgar F. Codd13, analista da IBM, desenvolveu uma série 
de estudos sobre como tratar os dados, a fim de eliminar as anomalias de atualização e 
as suas consequências desagradáveis para as organizações. Deste esforço surgiram duas 
inovações que revolucionaram a maneira de tratar os dados. A primeira destas inovações