PBD livro capitulo03 ProjetoLogico

Prévia do material em texto

Unidade 3: Projeto Lógico do Banco de Dados 
3.1 Primeiras palavras 
Conforme mencionado na Unidade 1 e em acordo com o 
diagrama reproduzido na Figura 3.1, o projeto lógico de banco 
de dados, apontado nessa figura por uma flecha hachurada, 
tem por objetivo a transformação de um esquema conceitual de 
banco de dado em um esquema lógico (conforme um modelo 
de dados lógico ou de implementação). 
 
 
Figura 3.1 – Etapas de desenvolvimento de um projeto de 
sistema de banco de dados 
Fonte: extraído de [ELMASRI 2005] 
Neste livro foram adotados o Modelo de Dados Entidade-
Relacionamento (MER) para nortear o projeto conceitual do 
banco de dados (conforme visto no Capítulo 2 deste livro) e o 
Modelo de Dados Relacional para a implementação do banco 
de dados. 
Sendo assim, o projeto lógico do banco de dados descrito 
nesse livro baseia-se no esquema conceitual do banco de 
dados, anotado conforme um diagrama entidade-
relacionamento (DER), para guiar a obtenção de um esquema 
lógico relacional do banco de dados. 
3.2 Problematizando o tema 
O foco deste capítulo é aprofundar conceitos anteriormente 
vistos em disciplina introdutória aos sistemas de banco de 
dados com vistas a melhorar o desempenho do sistema 
desenvolvido. 
 
3.3 Refinamento do Esquema Conceitual Visando 
Desempenho 
Antes de iniciar o processo de obtenção do esquema lógico 
relacional é recomendado que seja efetuada uma análise do 
esquema conceitual com o objetivo de ajustá-lo para atender 
com maior eficiência as operações mais críticas e/ou 
frequentes exigidas pelo usuário do sistema que está sendo 
projetado. 
Embora não seja possível, nesta etapa, saber com precisão 
qual o número médio de acessos aos dados, é possível fazer 
uma estimativa deste valor tendo por base a descrição do 
usuário sobre quais as operações mais críticas/frequentes que 
pretende executar sobre o banco de dados. Essa informação 
deve estar presente no documento de requisitos que norteia o 
desenvolvimento do sistema de banco de dados (vide Figura 
3.1). 
Nesta seção, serão descritas algumas técnicas que visam 
refinar o esquema conceitual buscando reduzir o número de 
acessos lógicos e quantidade de informação transferida para a 
memória durante a execução de operações frequentes e/ou 
críticas de consultas do usuário no banco de dados. 
3.3.1 Particionamento de Entidades 
A técnica Particionamento de Entidades visa reduzir cada tipo 
de entidade ao seu conjunto mínimo de atributos mais 
frequentemente acessados nas operações de consultas no 
banco de dados. 
Livro
nropags
editora
nome
isbn 
primeiro
_autor edição
cidade
idioma
resumo 
Figura 3.2. Extrato de um esquema conceitual: tipo de 
entidade LIVRO e seus atributos 
Considere o tipo de entidade LIVRO ilustrado na Figura 3.2. 
Neste extrato de um esquema conceitual, o tipo de entidade 
LIVRO está representado como um tipo de entidade regular, 
identificado pelo atributo ISBN, que possui os seguintes 
atributos: nome do livro, nome e cidade da editora que o 
publicou, número de páginas, número da edição, idioma da 
publicação, resumo do livro e nome do primeiro autor. 
Suponha que na maioria das operações realizadas 
frequentemente sobre o tipo de entidade LIVRO, sejam 
desejados: o nome do livro, o nome do primeiro autor e o 
número da edição do livro. Considere, ainda, que somente as 
operações anuais do relatório dos livros necessitem das 
demais informações. 
Ou seja, para acelerar as operações de consulta que são 
realizadas frequentemente, o tipo de entidade LIVRO pode ser 
particionado, conforme ilustrado na Figura 3.3, de forma a 
manter os atributos mais acessados e se relacionar com outro 
tipo de entidade, DETALHES_LIVRO, que mantenha aqueles 
atributos menos acessados. Observe que o atributo 
identificador ISBN é mantido no tipo de entidade LIVRO e que 
o tipo de entidade DETALHES_LIVRO foi modelada como um 
tipo de entidade fraca, pois seus atributos não permitem 
identificar uma entidade única. Desta forma, no esquema 
conceitual refinado, LIVRO passou a ser um tipo de entidade 
regular proprietária do tipo de entidade fraca 
DETALHES_LIVRO. 
 
11
Livro 
isbn 
primeiro_ 
autor
edição 
Detalhes 
Livro
Tem
nropag
editora 
Cidade 
idioma
resumo
nome
Entidade fraca
(1,1)
(1,1) 
 
Figura 3.3. Refinamento do esquema conceitual referente ao 
tipo de entidade LIVRO 
3.3.2 Fusão de Entidades 
A técnica Fusão de Entidades é considerada como inversa da 
Particionamento de Entidades, pois almeja reunir tipos de 
entidades associados por tipos de relacionamento binário 1:1, 
ou seja, com cardinalidades máximas 1 para ambos os tipos de 
entidade participantes do tipo de relacionamento, quando o 
número de operações que usam o relacionamento é maior que 
o número de operações nos tipos de entidades separadas. 
Considere, por exemplo, o esquema conceitual apresentado na 
Figura 3.4. Neste esquema estão representados os tipos de 
entidade CARRO e PLACA, ambos regulares, associados pelo 
tipo de relacionamento binário TEM (com cardinalidades 
máximas 1:1). 
 
Carro
nroCarro 
ano cor
Placa
cidade
nroplaca
estado
modelo
(1,1)(1,1)
tem
 
Figura 3.4. Esquema conceitual com tipo de relacionamento 
1:1 
Analisando-o com atenção é possível observar que este não é 
um bom esquema conceitual, pois “força” a existência do tipo 
de entidade regular CARRO com a introdução de um atributo 
artificial (nroCarro), estranho às entidades que estão sendo 
representadas, para servir como identificador do tipo de 
entidade. Naturalmente, ao pensar em como identificar um 
carro em particular, pensa-se em atributos como número do 
chassis, atributo inexistente no esquema em questão, ou 
número da placa que foi modelado como identificador do tipo 
de entidade PLACA. 
Tal decisão de projeto implica que operações executadas sobre 
esse esquema, frequentemente devem reunir os dados de 
ambos os tipos de entidade, uma vez que para conhecer os 
detalhes de um determinado carro é necessário conhecer qual 
o número de sua placa identificadora. Ou seja, frequentemente 
o tipo de relacionamento TEM deve ser utilizado para atender 
às requisições do usuário. 
Uma solução para melhorar a qualidade desse esquema é 
aplicar a técnica de Fusão de Entidades, reunindo os atributos 
de ambos os tipos de entidade CARRO e PLACA em um único 
tipo de entidade, conforme apresentado na Figura 3.5. Observe 
que o número da placa passa a ser considerado o identificador 
natural do tipo de entidade CARRO e o atributo artificial 
nroCarro é eliminado do novo esquema. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 3.5. Esquema conceitual melhorado após aplicação da 
técnica Fusão de Entidades. 
3.3.3 Reprodução de Atributos 
A técnica de Reprodução de Atributos consiste em duplicar 
atributos em mais de um tipo de entidade. Essa técnica deve 
ser aplicada muito criteriosamente, ou seja, os ganhos e as 
perdas oriundos de sua aplicação devem ser bem avaliados. 
Os ganhos com a aplicação da técnica referem-se a situações 
em que a replicação de um atributo, ou mais, leve a minimizar a 
ocorrência frequente de reunião de dados dos tipos de 
entidade envolvidos. 
As perdas referem-se à necessidade de operações adicionais 
sobre o banco de dados para manter a consistência dos dados 
replicados. Tais operações deverão ser realizadas sempre que 
o dado replicado sofrer alguma alteração (inserção de um novo 
valor, alteração ou remoção do valor vigente) garantindo que 
todas as cópias do atributo sejam igualmente atualizados para 
refletir a nova situação. 
Considere o esquema conceitual apresentado na Figura 3.6. 
Esse esquema representa os dados de coleta de um banco de 
sangue onde estão representados os doadores de sangue, as 
coletas realizadase os tipos sanguineos coletados. 
O tipo de entidade DOADOR, identificado por dados do 
Registro Geral (RG), possui os atributos nome, sexo, peso com 
Carro  estado
modelo
cidade 
nroplaca
corano 
a respectiva data de pesagem, data de nascimento e 
observações relevantes. 
O tipo de entidade COLETA, identificado pelo atributo número 
da coleta (nroCol), mantém registro sobre o atende que efetuou 
a coleta e a data da mesma. 
O tipo de entidade SANGUE, identificado por tipo sanguineo 
(tipoSang) registra a quantidade de bolsas de sangue de cada 
tipo sanguineo existente no estoque do banco de sangue. 
Pode ser observado que o projetista deste esquema conceitual 
não julgou importante a manutenção do tipo sanguineo do 
doador no tipo de entidade DOADOR. 
É possível conhecer esse dado se houver uma busca, no 
banco de dados, por coletas anteriores do doador (uma vez 
que os tipos de entidade DOADOR, COLETA e SANGUE estão 
interligados, mesmo que indiretamente). No entanto, a cada 
vez que esta informação é solicitada faz-se necessário realizar 
custosas operações de junção (JOIN) no banco de dados para 
atendê-la. Se isso ocorre muito frequentemente o desempenho 
do sistema de banco de dados pode sofrer sério 
comprometimento. 
 
 
Figura 3.6. Esquema conceitual de um banco de sangue. 
Pode ser considerado conveniente, para minimizar o impacto 
dessas custosas operações de junção para consultar o tipo 
sanguíneo de um doador, replicar o atributo tipo sanguíneo, 
adicionando-o, também, no tipo de entidade DOADOR, 
conforme ilustrado na Figura 3.7. 
 
Figura 3.7. Esquema conceitual de um banco de sangue com o 
tipo sanguineo replicado em DOADOR e SANGUE. 
Cabe ressaltar que no exemplo apresentado, por 
características inerentes ao problema apresentado, a 
replicação do atributo tipo sanguineo não acarretará operações 
adicionais para a manutenção da consistência no banco de 
dados. No tipo de entidade DOADOR, o mencionado atributo 
não sofrerá atualizações, pois naturalmente, uma pessoa 
sempre tem o mesmo tipo sanguineo enquanto viver e for 
doadora de sangue. No tipo de entidade SANGUE, o atributo 
tipo sanguineo é o identificador e, portanto, não poderá sofrer 
qualquer atualização. 
3.4 Transformação DER para Relacional: uma revisão 
Em disciplina introdutória aos sistemas de banco de dados são 
dispensadas várias horas de estudo para conhecer os passos 
fundamentais para transformação de um esquema conceitual 
(anotado em um diagrama entidade-relacionamento - DER) em 
um esquema lógico relacional. Neste capítulo é apresentada 
uma revisão sobre o processo de transformação básico 
(seções 3.4.1 a 3.4.7) e, nas seções seguintes, são 
apresentadas as abordagens para mapeamento de conceitos 
mais avançados do modelo entidade-relacionamento 
estendido. 
3.4.1 Mapear tipos de entidades regulares 
Lembrando: o que é um tipo de entidade regular? É um tipo de 
entidade que possui atributos suficientes para formar um 
identificador para suas entidades. 
Como os tipos de entidades regulares são representados no 
DER? Na notação empregada nesse livro, os tipos de entidade 
regulares são representados por um retângulo com linha 
simples. Cabe ressaltar que não existe uma padronização de 
notação para os diagramas entidade-relacionamento, neste 
livro foi adotada a notação apresentada em [ELMASRI 2006]. 
Como mapeá-los? 
Para cada tipo de entidade regular gerar um esquema de 
relação com nome igual ou similar ao do tipo de entidade 
incluindo todos os seus atributos simples e monovalorados. 
Assinalar como chave primária do esquema de relação gerado 
o conjunto de atributos referente ao identificador do tipo de 
entidades. 
O que fazer se o tipo de entidade possuir algum atributo 
composto? Devem ser acrescidos ao esquema de relação 
gerado apenas os atributos componentes do atributo composto 
que sejam simples e monovalorados, recursivamente. 
3.4.2 Mapear tipos de entidades fracas 
Lembrando: o que é um tipo de entidade fraca? É um tipo de 
entidade que não possui atributos suficientes para definir um 
identificador suas entidades. Todos os tipos de entidades 
fracas devem ter, no mínimo, o tipo de relacionamento 
Identidade que o associa ao seu tipo de entidade proprietária. 
Caso a cardinalidade máxima expressa no tipo de 
relacionamento Identidade leve a múltiplas ocorrências de 
entidades fracas para cada entidade proprietária (1:N ou N:M), 
então existe a necessidade de definição de um identificador 
parcial no conjunto de entidades fracas. 
Como os tipos de entidades fracas são representados no DER? 
Na notação empregada nesse livro, os tipos de entidade fracas 
são representados por um retângulo com linha dupla. O tipo de 
relacionamento Identidade é anotado como um losango com 
linha dupla. Cabe ressaltar que a cardinalidade mínima de um 
tipo de entidade fraca em seu tipo de relacionamento 
Identidade sempre é 1, ou seja, a restrição de participação é 
total. Essa restrição deve ser respeitada pois representa que 
uma entidade fraca só tem sentido de existência se estiver 
associada a, no mínimo, uma entidade proprietária. 
Como mapear os tipos de entidades fracas? 
O mapeamento implica em gerar um esquema de relação para 
cada tipo de entidade fraca incluindo seus atributos simples e 
monovalorados. Todos os comentários acerca dos atributos 
compostos feitos na seção 3.4.2 também se aplicam aqui. 
A chave primária do esquema de relação deve ser uma chave 
estrangeira que referencia o esquema de relação que 
representa o seu tipo de entidade proprietária. Caso tenha sido 
definido algum identificador parcial, esse deve também compor 
a chave primária da nova relação. 
Observe que efetuar o mapeamento do tipo de entidade fraca 
implicitamente já foi mapeado o tipo de relacionamento 
Identidade, independentemente de seu grau (binário, ternário, 
etc.) e das cardinalidades máximas envolvidas. Ou seja, 
cuidado para não mapear novamente o tipo de relacionamento 
Identidade nos passos posteriores. 
3.4.3 Mapear tipos de relacionamentos binários 
com cardinalidades máximas 1:1 
Lembrando: o que são tipos de relacionamentos binários ou de 
grau 2 (dois)? São aqueles que possuem apenas 2 (dois) tipos 
de entidades participando do tipo de relacionamento. 
E quanto a dizer que é 1:1? Isto se refere à restrição de 
cardinalidade imposta às entidades participantes do 
relacionamento, ou seja, se for considerada a restrição de 
cardinalidade 1:1 no tipo de relacionamento R entre dois tipos 
de entidade E e D, é dito que uma entidade de E pode se 
relacionar a uma, e só uma, entidade de D pelo tipo de 
relacionamento R e vice-versa. 
Segundo [ELMASRI 2005], existem 3 abordagens para o 
mapeamento de conjuntos de relacionamentos binários 1:1. 
Vamos discuti-las neste capítulo, porém salientando que a 
primeira abordagem, descrita na seção 3.4.3.1, é a mais 
seguida e deve ser preferencialmente adotada, exceto se 
houver ocorrências específicas que justifiquem a adoção de 
outra abordagem conforme será explicado a seguir. 
3.4.3.1 Escolha da chave estrangeira 
Deve ser escolhido um dos esquemas de relação referentes 
aos tipos de entidade participantes do tipo de relacionamento 
1:1 para receber a inclusão de atributos com a restrição de 
chave estrangeira referenciando o outro esquema de relação 
que participa do relacionamento. 
Mas, qual dos esquemas de relação escolher? A rigor, pode ser 
escolhido qualquer um deles, porém é recomendado que 
verifique se um dos tipos de entidade possui restrição de 
participação total no tipo de relacionamento (cardinalidade 
mínima 1) pois nesse caso é melhor que o esquema de relação 
referente a esse tipo de entidade receba a chave estrangeira. 
Por que? Porque a chave estrangeira será um atributo a mais 
nesse esquema de relação e se a restrição de participação é 
totalisso implica que esse valor sempre deverá ser preenchido 
(restrição NOT NULL). Com essa decisão de projeto, assegura-
se o menor número de ocorrências de valores NULL no banco 
de dados. 
Caso ambas as restrições de participação sejam parciais a 
escolha pode ser arbitrária, ou seja, escolha qualquer dos 
esquemas de relação e inclua os atributos como chave 
estrangeira referenciando o outro esquema de relação. Caso 
existam atributos no tipo de relacionamento esses atributos 
(desde que sejam simples e monovalorados) devem ser 
incluídos no mesmo esquema de relação que receberá a chave 
estrangeira. 
Outra possibilidade, que não é recomendada a menos que se 
justifique plenamente, para o caso de ambas as restrições de 
participação serem parciais, é a de introduzir a chave 
estrangeira em ambos os esquemas de relação, porém, além 
de grande número de valores NULL, pode acarretar problemas 
de consistência na atualização dessas tabelas. Nessa situação 
os atributos presentes no tipo de relacionamento são incluidos 
em apenas um dos esquemas de relação. A justificativa mais 
plausível para adotar essa solução é a necessidade (muito 
forte!) de facilitar a navegação entre as tabelas. Isso só se 
justifica se forem previstas consultas muito frequentes que 
exijam tal navegação. 
3.4.3.2 Opção da relação unificada (ou 
relacionamento incorporado) 
Essa abordagem prevê a incorporação dos tipos de entidade e 
do tipo de relacionamento em um só esquema de relação. Essa 
opção pode ser interessante quando ambas as restrições de 
participação são totais. 
3.4.3.3 Opção Referência Cruzada 
Nessa abordagem deve ser gerada um novo esquema de 
relação com atributos chaves estrangeiras, que referenciam 
cada esquema de relação referentes aos tipos de entidade 
envolvidos no tipo de relacionamento. A chave primária desse 
novo esquema de relação será apenas uma das chaves 
estrangeiras. Se houver atributo no tipo de relacionamento 
deve ser incluído nesse novo esquema. 
Essa abordagem deve ser evitada quando não existem 
justificativas plausíveis, por provocar na maioria das vezes, um 
acréscimo de tempo na execução de consultas ao banco de 
dados, pois envolvem o uso da custosa operação de junção 
(JOIN). 
Essa nova relação gerada é chamada de Relação de 
Relacionamento (ou Tabela de Busca), pois cada tupla 
representa uma instância do relacionamento. Essa é a solução 
para os conjuntos de relacionamentos binários N:M e para os 
de grau >2 (n-ários), como será visto nas próximas seções. 
3.4.4 Mapear tipos de relacionamentos binários 
com cardinalidades máximas 1:N 
Lembrando: o que são tipos de relacionamentos binários 1:N? 
Considere o tipo de relacionamento binário R entre os tipos de 
entidade D e P, qual a semântica da restrição de cardinalidade 
1:N? A semântica é que uma entidade D pode se associar a 
diversas entidades P enquanto uma entidade P pode se 
associar a apenas uma entidade D. 
Como mapear? 
Para mapear um tipo de relacionamento 1:N, deve ser 
localizado o esquema de relação que representa o tipo de 
entidade do lado N do tipo de relacionamento e inserir nesse 
esquema de relação a chave estrangeira que deve referenciar 
o esquema de relação referente ao tipo de entidade do lado 1. 
Essa regra se aplica pois cada instância do lado N se relaciona 
a apenas uma instância do lado 1. 
Alternativa de mapeamento: 
Pode ser adotada a solução por Tabela de Relacionamento (ou 
Tabela de Busca) como alternativa de mapeamento caso 
existam poucas tuplas do esquema de relação que recebe a 
chave estrangeira participando do conjunto de 
relacionamentos, pois nesse caso, a adoção da alternativa 
padrão implica na inclusão de muitos valores nulos (NULL) no 
banco de dados. Essa solução, como já explicado na seção 
3.4.3.3, aplica-se no caso de tipos de relacionamentos binários 
N:M e nos de grau maior que 2 (n-ários). Na próxima seção 
será explicado como gerar essas Tabelas de Relacionamento. 
3.4.5 Mapear tipos de relacionamentos binários 
com cardinalidades máximas N:M 
Lembrando: o que são tipos de relacionamentos binários N:M? 
Considere o tipo de relacionamento binário R entre os tipos de 
entidade D e P, qual a semântica da restrição de cardinalidade 
N:M? A semântica é que uma entidade D pode se associar a 
diversas entidades P e uma entidade P pode se associar a 
diversas entidades D. 
Como mapear? 
Para tipos de relacionamentos M:N é adotada a criação de uma 
Tabela de Relacionamento (ou Tabela de Busca), como já foi 
mencionado em seções anteriores. 
Como é construída essa Tabela de Relacionamento? 
Deve ser criado um esquema de relação para representar o 
tipo de relacionamento. Devem ser inseridos atributos chaves 
estrangeiras, que referenciam cada esquema de relação 
referentes aos tipos de entidade envolvidos no tipo de 
relacionamento. A chave primária dessa nova relação deve ser 
composta pelos atributos das duas chaves estrangeiras. Se 
houver atributo no tipo de relacionamento deve ser incluído 
nesse novo esquema. 
Observações Importantes: 
(A) Essa é a única situação de mapeamento de tipos de 
relacionamentos binários em que as chaves estrangeiras 
passam a fazer parte da chave primária da relação que a 
recebe. 
(B) A utilização da Tabela de Relacionamento para tipos de 
relacionamentos binários 1:1 e 1:N não são incentivados, mas 
podem ser particularmente úteis quando a relação que recebe 
a chave estrangeira tem poucas entidades que participam 
efetivamente do relacionamento para evitar o excesso de 
valores NULL na tabela. Nesses casos, a chave primária da 
Tabela de Relacionamentos será apenas uma das chaves 
estrangeiras (e não as duas chaves estrangeiras como nos 
tipos de relacionamentos M:N). 
3.4.6 Mapear tipos de relacionamentos n-ários 
(n>2) 
Lembrando: O tipo de relacionamento de grau maior que 2, ou 
n-ário com n>2 (lê-se eneário) se caracteriza por ter mais do 
que dois tipos de entidades participando nele. 
A complexidade do tipo de relacionamento aumenta de acordo 
com o número de tipos de entidades participantes, por 
exemplo, a determinação correta das restrições de 
cardinalidades máximas em um tipo de relacionamento ternário 
(com 3 tipos de entidades participantes) na etapa de projeto 
conceitual é decisivo para obtenção de um esquema de relação 
adequado para manter a informação do tipo de relacionamento. 
Em função do aumento de complexidade envolvida em n-ários, 
recomenda-se que sejam buscadas alternativas de modelagem 
ao se deparar, na etapa de projeto conceitual, com um conjunto 
de relacionamentos com grau maior do que 3. 
Dependendo das restrições de cardinalidade indicadas no tipo 
de relacionamento n-ário deve-se optar por uma das formas de 
mapeá-lo: 
3.4.6.1 Restrições de Cardinalidade Máximas 
N:N:N 
Caso todas as restrições de cardinalidade sejam múltiplas 
(N:N:N) deve ser utilizada uma Tabela de Relacionamento 
onde a chave primária é composta por todas as chaves 
estrangeiras inseridas na nova relação e inserir nela também 
os atributos simples e monovalorados presentes no conjunto de 
relacionamento. 
3.4.6.2 Restrições de Cardinalidade Máximas 
1:N:N ou 1:1:N ou 1:1:1 
Caso alguma das restrições de cardinalidade máximas seja 1 
(1:N:N) ou (1:1:N) ou (1:1:1) então a chave estrangeira 
referente àquele tipo de entidades que possui restrição de 
cardinalidade 1 não deve entrar na chave primária. No último 
caso citado (1:1:1) apenas uma delas seria chave primária. 
Observação Importante: um conjunto de relacionamento 
Identidade (que associa um conjunto de entidades fracas à sua 
proprietária) pode ser de grau maior que 2, porém o 
mapeamento segue o mesmo procedimento adotado em casos 
de conjuntos de relacionamento Identidade de grau 2. 
3.4.7 Mapear atributos multivalorados 
Lembrando: O que significa mesmo ser um atributo 
multivalorado?Significa que uma entidade do mundo real pode 
receber diversos valores para aquele atributo. 
Existem algumas alternativas para o mapeamento de atributos 
multivalorados: 
3.4.7.1 Gerar um novo esquema de relação 
Essa é a alternativa mais bem aceita e utilizada. É 
recomendada quando se deseja poder armazenar quantos 
valores forem necessários, sem limitações, para o atributo 
multivalorado. Consiste em gerar um novo esquema de relação 
que deve conter o atributo multivalorado (ou os componentes 
simples e monovalorados dele, caso seja um atributo 
composto) mais uma chave estrangeira que referencia o 
esquema de relação que representa o tipo de entidade que no 
esquema conceitual contém o atributo multivalorado. A chave 
primária dessa nova relação é composta pelos atributos 
descritores do multivalorado e pela chave estrangeira. 
3.4.7.2 Incluir o atributo multivalorado na chave 
primária 
Solução bastante adotada quando o atributo multivalorado está 
presente em um tipo de relacionamento ou quando se encontra 
em tipos de entidades com poucos atributos. Consiste em 
tornar o atributo multivalorado um componente da chave 
primária da relação que representa o tipo de 
entidade/relacionamento que o possui. 
3.4.7.3 Incluir um conjunto de atributos 
equivalente ao número de valores que se 
deseja associar a uma única entidade 
Essa solução só se aplica caso seja conhecido o número de 
possíveis valores esperados para o atributo multivalorado. O 
mapeamento consiste em acrescentar um conjunto de atributos 
equivalente ao número de ocorrências esperadas na relação 
que representa o conjunto de entidades que originalmente 
continha o atributo multivalorado. Recomenda-se que essa 
abordagem somente seja adotada se o número de atributos 
que serão incluídos na tabela para representar o multivalorado 
seja baixo (entre 3 e 4 atributos). 
3.4.8 Mapear hierarquias de 
generalização/especialização 
Lembrando: O que representam as hierarquias de 
generalização/especialização? Representam situações em que 
é possível reconhecer características comuns em dois ou mais 
tipos de entidade. São consideradas, nessa análise, 
características tanto estruturais (atributos) quanto 
comportamentais (tipos de relacionamento). 
É possível representar, no modelo de dados entidade-
relacionamento, algumas propriedades inerentes às hierarquias 
de generalização/especialização: 
(a) – Cobertura Total (T) X Cobertura Parcial (P) 
A propriedade de cobertura informa se o tipo de entidade 
generalizado representa somente entidades dos tipos de 
entidade especializados (total), ou se pode representar 
outras entidades além dessas (parcial). Considerando a 
Figura 3.8, a leitura da abstração apresentada é: as 
entidades de E1 e E2 representam a totalidade das 
entidades em G. 
Figura 3.8. DER: hierarquia de generalização total. 
Por outro lado, o esquema apresentado na Figura 3.9, 
representa que as entidades de E1 e E2 representam 
apenas uma parte das entidades em G, ou seja, existem 
entidades em G que não são especializadas nem em E1 e 
nem em E2. 
G 
idG 
atrG
E2  idE2 
atrE2 
E1 idE1 
atrE1 
(T) 
G 
idG 
atrG
E2  idE2 
atrE2 
E1 idE1 
atrE1 
(P) 
Figura 3.9. DER: hierarquia de generalização parcial. 
(b) Especialização Disjunta ou Sobreposta 
A propriedade de especialização informa se uma entidade 
pode (sobreposta) ou não (disjunta) ser especializada em 
mais de um tipo de entidade. Na Figura 3.10 está 
representada a situação de disjunção entre as entidades 
representadas por E1 e E2. Ou seja, se uma entidade e é 
uma entidade representada pelo tipo de entidade E1 então 
não pode ser representada pelo tipo de entidade E2. 
Figura 3.10. DER: hierarquia de especialização disjunta. 
Por outro lado, na Figura 3.11, está representada a 
situação de sobreposição entre as entidades representadas 
por E1 e E2. Essa propriedade representa um relaxamento 
da restrição imposta na situação de disjunção, ou seja, é 
possível que uma entidade e representada pelo tipo de 
entidade E1 seja também representada pelo tipo de 
entidade E2. 
Figura 3.11. DER: hierarquia de especialização sobreposta. 
Observação importante: as propriedades das hierarquias de 
generalização/especialização devem ser assinaladas em 
conjunto, ou seja, uma hierarquia pode ser total e disjunta; ou, 
G 
idG 
atrG
E2  idE2
atrE2 
E1 idE1
atrE1
(D) 
G 
idG 
atrG
E2  idE2 
atrE2 
E1 idE1 
atrE1 
(S) 
G 
idG 
atrG
E2  idE2 
atrE2 
E1 idE1 
atrE1 
total e sobreposta; ou, parcial e disjunta; ou, ainda, parcial e 
sobreposta. A situação mais restritiva é representada na Figura 
3.12, ou seja, uma hierarquia total e disjunta. 
Figura 3.12. DER: hierarquia total e disjunta. 
3.4.8.1 Gerar um esquema de relação para cada 
tipo de entidade envolvido na hierarquia 
Essa abordagem pode ser aplicada independente da 
combinação de propriedades assinalada na hierarquia. 
Consiste em gerar um esquema de relação para cada tipo de 
entidade envolvido na hierarquia com seus atributos simples e 
monovalorados. Os esquemas de relação gerados a partir dos 
tipos de entidade especializados devem agregar uma chave 
estrangeira que referencia o tipo de entidade generalizado e 
esta chave estrangeira deve ser assinalada como a chave 
primária do novo esquema de relação caso o tipo de entidade 
especializado não possua um identificador próprio. 
Na Figura 3.13 é apresentado um possível esquema relacional 
derivado da hierarquia total e disjunta. É possível observar que 
o tipo de entidade especializado E1 não possui um identificador 
próprio, segundo o esquema conceitual, então foi gerado um 
esquema de relação onde a chave estrangeira idG é também 
chave primária da relação. 
G 
idG 
atrG
E2  idE2 
atrE2 
E1 idE1 
atrE1 
(T,D)
Figura 3.13. Esquema relacional derivado de uma hierarquia 
parcial e disjunta. 
Por outro lado, o tipo de entidade E2, possui um identificador 
próprio idE2, portanto, pode-se respeitar esse atributo 
identificador tornando-o a chave primária do esquema de 
relação, neste caso, portanto, o atributo idG possui apenas a 
propriedade de ser chave estrangeira referenciando o tipo de 
entidade generalizado G. 
3.4.8.2 Gerar um esquema de relação para cada 
tipo de entidade especializado 
Essa abordagem só pode ser aplicada quando a propriedade 
de cobertura da generalização for total. Consiste em gerar um 
esquema de relação referente a cada tipo de entidade 
especializado, contendo além de seus próprios atributos, 
simples e monovalorados, conter também aqueles oriundos do 
tipo de entidade generalizado. Ou seja, não é gerado um 
esquema de relação para o tipo de entidade generalizado. É 
uma abordagem adequada para hierarquia total e disjunta, pois 
evita dados nulos e replicados. 
Na Figura 3.14, é ilustrada a aplicação dessa abordagem em 
um hierarquia total e disjunta. 
 
G 
idG 
atrG
E2  idE2 
atrE2 
E1 atr1E1 
atr2E1 
(P,D)
G(idG, atrG) 
E1(idG, atr1E1, atr2E1) E2(idG, idE2, atrE2) 
Figura 3.14. Esquema relacional derivado de uma hierarquia 
total e disjunta (alternativo). 
Observação importante: embora seja considerada a abordagem 
mais adequada para hierarquia total e disjunta existem outros 
aspectos que são relevantes na análise de aplicabilidade dessa 
abordagem, por exemplo, o número de atributos e tipos de 
relacionamentos presentes no tipo de entidade generalizado. 
Pode ser interessante aplicar a abordagem da seção 3.4.8.1 
caso o tipo de entidade generalizado tenha muitos atributos, ou 
atributos muito complexos (multivalorados compostos). 
Situação similar ocorre se existem tipos de relacionamento N:M 
ocorrendo no tipo de entidade generalizado. 
3.4.8.3 Gerar um único esquema de relação 
Consiste em gerar um únicoesquema de relação com os 
atributos de todos os tipos de entidade envolvidos na 
hierarquia. 
Observações importantes: 
(a) se os tipos de entidade especializados forem disjuntos 
deve-se acrescentar um atributo para designar a qual 
dos tipos de entidade uma determinada tupla 
corresponde, conforme apresentado na Figura 3.15. 
 
 
 
 
 
G 
idG 
atrG
E2  idE2 
atrE2 
E1 atr1E1 
atr2E1 
(T,D)
E1(idG,atrG,atr1E1,atr2E1) E2(idG,atrG,idE2,atrE2) 
 
Figura 3.15. Esquema relacional derivado de uma hierarquia 
total e disjunta (esquema único). 
(b) se os tipos de entidade especializados forem 
sobrepostos deve-se acrescentar um atributo para cada 
tipo de entidade especializado para designar a quais 
deles a tupla corresponde. A Figura 3.16 ilustra esta 
situação. 
Figura 3.16. Esquema relacional derivado de uma hierarquia 
total e sobreposta (esquema único). 
(c) A adoção dessa abordagem pode implicar em um 
número elevado de valores nulos, recomenda-se 
cautela para empregá-la. Adequada quando o número 
de atributos dos tipos especializados é baixo e quando 
é desejado priorizar desempenho de consultas (pois 
diminui a necessidade do emprego de operações de 
junção). 
3.4.9 Mapear herança múltipla 
G 
idG 
atrG
E2  idE2 
atrE2 
E1 atr1E1 
atr2E1 
(T,D)
G(idG,atrG,atr1E1,atr2E1,idE2,atrE2,tipo)
G 
idG 
atrG
E2  idE2 
atrE2 
E1 atr1E1 
atr2E1 
(T,S)
G(idG,atrG,atr1E1,atr2E1,idE2,atrE2,tipoE1,tipoE2) 
Existem hierarquias de generalização/especialização que 
consideram a possibilidade de entidades de um tipo 
especializado derivar propriedades de dois ou mais tipos de 
entidade generalizados. Diz-se que essas entidades possuem 
herança múltipla. 
Para o mapeamento de hierarquias com essa característica 
podem ser adotados os mesmos procedimentos descritos na 
seção 3.4.8. Deve ser observado que, se não houver um 
identificador próprio do tipo de entidade especializado, deve-se 
adotar como chave primária apenas uma das chaves 
estrangeiras que referenciam os tipos de entidade 
generalizados. A Figura 3.17 ilustra esta situação. 
 
 
 
 
 
 
 
 
 
Figura 3.17. Esquema relacional derivado de uma hierarquia 
com herança múltipla. 
 
3.4.10 Mapear categorização 
Lembrando: Categoria é um subconjunto da união de dois ou 
mais tipos de entidades generalizadas. Dois exemplos comuns 
são apresentados na Figura 3.18, em (a) um tipo de entidade 
Pessoa que pode herdar características do tipo de entidade PF 
(Pessoa Física com identificador CPF) ou do tipo de entidade 
PJ (Pessoa Jurídica com identificador CNPJ). Pode-se dizer 
que Pessoa é uma categoria que ora terá um CPF e ora terá 
CNPJ. Em (b) a categoria Veículo, que pode derivar 
características de dois tipos de entidade, Carro e Moto, que 
G1(idG1,atrG1)
G2(idG2,atrG2) 
E1(idG1,idG2,atr1E1,atr2E1) 
G1 
idG1 
atrG1 
E1 atr1E1 
atr2E1 
G2 
idG2
atrG2
possuem o mesmo identificador placa. As categorias estão 
associadas pelo tipo de relacionamento Possui. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 3.18. Esquema conceitual Proprietários 
No exemplo apresentado na Figura 3.18 são observados dois 
tipos de categorias: (a) Pessoa é uma categoria que pode ter 
diferentes identificadores (CPF ou CNPJ) e (b) Veículo que 
possui identificador próprio, e, além disso, é subconjunto da 
união de dois tipos de entidade que possuem o mesmo 
identificador (Placa). 
3.4.10.1 Herda distintos identificadores 
Para o mapeamento de categorias que são subconjuntos de 
tipos de entidade pais com distintos identificadores, usualmente 
é gerado um atributo surrogate (um novo atributo para servir de 
identificador) no esquema de relação que representa a 
U

Carro  Placa
ModeloC
Moto  Placa
ModeloM
(b) 
N
Veículo 
Possui
M
Chassis
PF 
CPF 
nome 
Pessoa 
PJ 
CNPJ
razaoSocial 
U

(a) 
categoria e adiciona-se esse surrogate como chave estrangeira 
nos esquemas de relação que representam os tipos de 
entidade pais, conforme apresentado na Figura 3.19. 
 
 
 
 
 
 
 
 
 
 
 
Figura 3.19. Esquema relacional: categoria Pessoa 
3.4.10.2 Herda o mesmo identificador 
Para o mapeamento de categorias que são subconjuntos de 
tipos de entidade pais com mesmos identificadores basta incluir 
o mesmo identificador dos pais como chave primária do 
esquema de relação que representa o filho. No exemplo 
apresentado na Figura 3.18 (b) Veículo possui seu próprio 
identificador (além de possuir pais com mesmos 
identificadores), sendo assim, alternativamente, basta migrar o 
seu identificador como chave estrangeira para os esquemas de 
relação dos pais, conforme apresentado na Figura 3.20. 
 
 
 
 
 
 
 
 
 
 
PF 
CPF 
nome 
Pessoa 
PJ 
CNPJ
razaoSocial 
U

(a) 
Pessoa(idPessoa)
PF(CPF,nome,idPessoa) PJ(CNPJ,razaoSocial,idPessoa) 
Veículo 
U

Carro 
Placa
ModeloC
Moto  Placa
ModeloM 
(b) Chassis
Veículo(Chassis)
Carro(Placa,ModeloC,Chassis)
Moto(Placa,ModeloM,Chassis) 
Figura 3.20. Esquema relacional: categoria Veículo 
O esquema relacional completo, referente ao esquema 
conceitual Proprietários, é apresentado na Figura 3.21. 
 
Figura 3.21. Esquema relacional Proprietários 
 
3.4.11 Mapear agregação 
Lembrando: O que caracteriza uma abstração de agregação? 
Abstração de agregação, no modelo entidade-relacionamento, 
corresponde à possibilidade de relacionamentos entre tipos de 
entidade poderem ser visualizados como um novo tipo de 
entidade. Ou seja, um tipo de relacionamento passa a ser visto 
como um tipo de entidade. Só tem sentido usar essa abstração 
se houver a necessidade de expressar “relacionamento entre 
relacionamentos”! 
O mapeamento de uma agregação para o modelo relacional 
pode seguir, basicamente, duas abordagens: 
(a) São geradas 2 tabelas: (1) para representar o tipo de 
relacionamento que dá origem à agregação e (2) para 
representar a própria agregação 
(b) É gerada apenas uma tabela que representa tanto o tipo 
de relacionamento quanto a agregação 
Considere o exemplo apresentado na Figura 3.22. São 
considerados corretos os seguintes esquemas de relação 
Pessoa(idPessoa) 
PF(CPF, nome, idPessoa) 
PJ(CNPJ, razaoSocial, idPessoa) 
Veículo(Chassis) 
Carro(Placa, modeloC, Chassis) 
Moto(Placa, modeloM, Chassis) 
Pessoa_Possui_Veiculo(IdPessoa,Chassis) 
derivados desse esquema conceitual conforme a abordagem 
(a): 
Disciplina(Sigla) 
Professor(CPF, Nome) 
Aluno(RA, Nome) 
Ministra(FK_Disciplina(Sigla), FK_Professor(CPF)) 
Aula(FK_Ministra(Sigla,CPF)) 
Aula_freq_Aluno(FK_Aula(Sigla,CPF), FK_Aluno(RA)) 
 
Deve ser observado que nesta abordagem respeita-se a 
semântica de necessitar acontecer o relacionamento 
Ministra entre um Professor e uma Disciplina para que 
então possa existir uma Aula que será frequentada por um 
Aluno. Essa semântica é garantida com o emprego correto 
das chaves estrangeiras nas tabelas Aula e 
Aula_freq_Aluno. 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 3.22. Esquema conceitual Escola 
 
Porém, essa abordagem leva à construção de relações com 
esquemas muito similares (observe as relações Ministra e 
Aula). Pode ser convencionado que embora possuam 
esquemas idênticos, a relação Aula pode conter um 
subconjunto das tuplas de Ministra que atende ao 
Aula 
 Disciplina  Sigla
Ministra  É_frequentada
 Professor  CPF 
Nome
 Aluno  RA 
Nome 
N 
N 
N
N
relacionamento é_frequentada. Ou seja, é possível que o 
conjunto de tuplas de Aula seja menor que o de Ministra. 
Quando a distinção de tuplas entre as duas tabelas é desejável 
que se evite a replicação desnecessária de dados. Nessa 
situação adota-se a abordagem (b) e são gerados os seguintes 
esquemasde relação que também são considerados corretos: 
Disciplina(Sigla) 
Professor(CPF, Nome) 
Aluno(RA, Nome) 
Aula (FK_Disciplina(Sigla), FK_Professor(CPF)) 
Aula_freq_Aluno(FK_Aula(Sigla,CPF), FK_Aluno(RA)) 
 
3.4.12 Considerações Gerais 
Nesta seção foram apresentados vários conceitos de 
modelagem conceitual e lógico, porém existem alguns 
conceitos que embora não tenham sido apresentadas com 
maiores detalhes merecem alguns destaques. 
Um tipo de relacionamento que expressa muitas situações 
cotidianas é o tipo de relacionamento unário (ou 
autorelacionamento). Por que unário (grau 1)? Porque o tipo de 
relacionamento envolve apenas um tipo de entidade. 
Esse tipo de relacionamento requer que sejam incluidos os 
papéis que cada entidade exerce no relacionamento. Isso é 
importante para que seja facilitada a análise das cardinalidades 
mínimas e máximas no tipo de relacionamento. As 
cardinalidades máximas e mínimas irão auxiliar nas decisões 
para derivar o esquema lógico que represente adequadamente 
esses tipos de relacionamento. 
Cabe ressaltar que embora não seja usual, existem situações 
que necessitam ser representadas por tipos de relacionamento 
unários em que o tipo de entidade participe com mais de 2 
papéis distintos. 
Para a derivação do esquema lógico, caso o tipo de entidade 
participe com apenas 2 papéis distintos, devem ser seguidas as 
mesmas orientações oferecidas neste capítulo referentes aos 
tipos de relacionamento binários. Caso participe com mais de 
dois papéis devem ser seguidas as orientações oferecidas para 
os tipos de relacionamento n-ários (n>2). 
 
Outra observação Importante refere-se ao conjunto de 
relacionamento Identidade (que associa um conjunto de 
entidades fracas à sua proprietária) que pode ser de grau maior 
que 2, porém o mapeamento para o esquema lógico relacional 
segue o mesmo procedimento adotado em casos de conjuntos 
de relacionamento Identidade de grau 2.