Apostila_Unidade2_2021_atualizada

Prévia do material em texto

Apostila – Unidade 2
Projeto Lógico
Módulo 1
Disciplina: Banco de Dados Relacional e NoSQL
Profª Bruna Bárbara Santos Bordini
1 Projeto Lógico
Vamos apresentar o projeto lóico de BD relacional, a transformaço de um
modelo ER em um modelo lóico, que implementa, em níel de SGBD relacional, os
dados representados abstratamente no modelo ER. O termo “implementaçõ sínifica
que ocorre uma transformaço de um modelo mais abstrato para um modelo que contem
mais detalhes de implementaço o EHSER, 2011).
Díersos autores, referem-se à transformaço do modelo ER em um modelo lóico
como “mapeamentõ.
A Fíura 1 apresenta as transformacões entre os modelos ER e relacional.
Fíura 1 - Transformacões entre modelo ER e modelo relacional oFonte: euser, 2011)
1.1 Modelo de banco de dados relacional
A especificaço de um banco de dados relacional, ou seja, um modelo de banco de
dados relacional, dée conter no minimo a definiço dos séuintes itens:
 tabelas que formam o banco de dados, 
 colunas que as tabelas possuem e 
 restricões de intéridade.
1.1.1 Tabela
 Hma tabela e um conjunto ņo ordenado de linhas otuplas). 
 Cada linha e composta por uma serie de campos óalor de atributo). 
 Cada campo e identificado por um nome de campo onome de atributo). 
 O conjunto de campos homonimos de todas as linhas de uma tabela formam uma
coluna.
A Fíura 2 apresenta um exemplo de tabela.
Fíura 2 – Tabela oFonte: euser, 2011)
1.1.2 Chave
Em um banco de dados relacional, ha ao menos tres tipos de cháes: a cháe
primaria, a cháe alternatía e a cháe estrańeira.
1.1.2.1 Chave Primária
 Hma cháe primaria e uma coluna ou uma combinaço de colunas cujos ́alores
distińuem uma linha das demais dentro de uma tabela. 
 Hma cháe primaria dée ser minima, ou seja, todas as suas colunas déem ser
efetíamente necessarias distińuir uma linha das demais dentro da tabela.
A Fíura 3 apresenta um exemplo de cháe primaria.
Fíura 3 – Tabela com cháe primaria composta oFonte: euser, 2001)
1.1.2.2 Chave estrangeira
 Hma cháe estrańeira e uma coluna ou uma combinaço de colunas, cujos
́alores aparecem necessariamente na cháe primaria de uma tabela. 
 A cháe estrańeira e o mecanismo que permite a implementaço de
relacionamentos em um banco de dados relacional.
A Fíura 4 apresenta um exemplo de cháe estrańeira.
Fíura 4 – Cháe estrańeira oFonte: euser, 2011).
De acordo com euser o2011), a existencia de uma cháe estrańeira impõe
restricões que déem ser ́arantidas ao executar díersas operacões de alteraço do
banco de dados:
 Quando da incluşo de uma linha na tabela que contem a cháe estrańeira: neste
caso, dée ser ́arantido que o ́alor da cháe estrańeira apareca na coluna da
cháe primaria referenciada. 
 Quando da alteraço do ́alor da cháe estrańeira: dée ser ́arantido que o nóo
́alor de uma cháe estrańeira apareca na coluna da cháe primaria referenciada.
 Quando da excluşo de uma linha da tabela que contem a cháe primaria
referenciada pela cháe estrańeira: dée ser ́arantido que, na coluna cháe
estrańeira, ņo apareca o ́alor da cháe primaria que esta sendo excluida. 
 Quando da alteraço do ́alor da cháe primaria referenciada pela cháe
estrańeira: dée ser ́arantido que, na coluna cháe estrańeira, ņo apareca o
́alor antío da cháe primaria que esta sendo alterada. 
1.1.2.3 Chave alternativa
Em aĺuns casos, mais de uma coluna ou combinacões de colunas podem seŕir
para distińuir uma linha das demais. Hma das colunas oou combinaço de colunas) e
escolhida como cháe primaria. As demais colunas ou combinacões şo denominadas
cháes alternatías. 
A Fíura 5 apresenta um exemplo de cháe alternatía.
Fíura 5 - Cháe alternatía ocoluna CPF) oFonte: euser, 2011)
1.1.3 Restriçoes de integridade
Para euser o2011), um dos objetíos primordiais de um SGBD e a manutenço da
intéridade de dados sob seu controle. Dizer que os dados de um banco de dados esţo
intéros sínifica dizer que eles refletem corretamente a realidade representada pelo
banco de dados e que şo consistentes entre si. Para tentar ́arantir a intéridade de um
banco de dados, os SGBDs oferecem o mecanismo de restriço de intéridade. Hma
restriço de intéridade e uma réra de consistencia de dados que e ́arantida pelo
proprio SGBD. No caso da abordáem relacional, costuma-se classificar as restricões de
intéridade nas séuintes catéorias:
 Intéridade de dominio – Restricões deste tipo especificam que o ́alor de um
campo dée obedecer a definiço de ́alores admitidos para a coluna oo dominio
da coluna). 
 Intéridade de ́azio – Atráes deste tipo de restriço de intéridade e especificado
se os campos de uma coluna podem ou ņo ser ́azios ose a coluna e obríatoria
ou opcional). Campos que compõem a cháe primaria sempre déem ser
diferentes de ́azio.
 Intéridade de cháe – Trata-se da restriço que define que os ́alores da cháe
primaria e alternatía déem ser ́nicos.
 Intéridade referencial – E a restriço que define que os ́alores dos campos que
aparecem em uma cháe estrańeira déem aparecer na cháe primaria da tabela
referenciada.
As restricões dos tipos acima especificados déem ser ́arantidas automaticamente
por um SGBD relacional.
1.1.3 Esquema textual de BD relacional
 Vamos apresentar apenas uma notaço resumida para esquemas textuais de BD
relacional. Esta notaço e incompleta, mas compacta, e e ́til para exemplos, bem como
para discussões sobre a estrutura ́eral do banco de dados, quando ņo se deseja entrar
no maior níel de detalhe.
Nesta notaço, şo listadas as tabelas e, para cada tabela, enumerados, entre
parenteses, os nomes das colunas que compõem a tabela. As colunas que compõem a
cháe primaria aparecem sublinhadas. Apos a definiço de cada tabela, aparecem as
definicões das cháes estrańeiras que aparecem na tabela na forma:
<nome de coluna ch. estrangeira> referencia <nome de tabela> 
quando tratar-se de uma cháe estrańeira composta de uma ́nica coluna, ou na forma:
 (<nome de coluna>1,<nome de coluna>2, ...) referencia <nome de
tabela> 
quando tratar-se de uma cháe estrańeira composta por ḿltiplas colunas.
1.1.4 Esquema diagramático de BD relacional
Outra alternatía de representaço de esquema de banco de dados relacional e
atráes de diáramas. Muitas ferramentas CASE trabalham com notacões deste tipo.
Assim como ņo ha padŗo de notaço diáramatica para esquemas ER, tambem ņo ha
padŗo para notaço de esquemas relacionais.
De maneira ́eral, esquemas diáramaticos de BD relacional esţo oŕanizados
como descrito a séuir.
 Cada tabela e representada por um retańulo.
 As colunas que compõem a tabela şo listadas dentro do retańulo representatío
da tabela. Muitas ́ezes, notacões adicionais indicam o dominio de cada coluna. 
 A indicaço das colunas que compõem a cháe primaria tambem pode aparecer no
diárama. Por exemplo, as colunas que compõem a cháe primaria şo indicadas
pela síla pk ode primary key – cháe primaria).
 As setas representam as cháes estrańeiras. Por exemplo, a seta léa da tabela
que contem a cháe estrańeira para a seta que contem a cháe primaria oha
notacões na quais a seta tem o sentido ińerso). As colunas que compõem as
cháes estrańeiras şo indicadas pela síla fk ode foreign key – cháe
estrańeira).
1.2 Visão geral do projeto lógico
Hm determinado modelo ER pode ser implementado atráes de díersos modelos
relacionais, que contem as informacões especificadas pelo diárama ER. Cada um destes
modelos relacionais alternatíos pode ser ́isto como uma implementaço correta do
modelo ER considerado. Entretanto, estes diferentes modelos relacionais podem resultar
em diferentes performances do sistema construido sobre o banco de dados. Alem disso,
osdiferentes modelos relacionais podem implicar em maior facilidade ou dificuldade de
deseńoĺimento e manutenço do sistema construido sobre o banco de dados
o EHSER, 2011).
Nos casos em que o modelo relacional inicial ņo atenda aos requisitos de
performance da BD projetada, ha um processo de refinamento e melhoria do modelo, ate
ser atińido o modelo relacional satisfatorio.
A Fíura 6 resume os passos do projeto lóico.
Fíura 6 - Vişo ́eral do projeto lóico oFonte: euser, 2011).
1.3 Transformacão ER para relacional
De acordo com euser o2011), as réras para a transformaço de um modelo ER
em modelo relacional foram definidas tendo em ́ista os dois objetíos basicos do projeto
de BD:
 Obter um banco de dados que permita boa performance de instrucões de consulta
e alteraço do banco de dados. Obter boa performance sínifica basicamente
diminuir o ńmero de acessos a disco, ja que estes consomem o maior tempo na
execuço de uma instruço de banco de dados.
 Obter um banco de dados que simplifique o deseńoĺimento e a manutenço de
aplicacões.
Estes şo os dois objetíos centrais. Alem destes, as réras de transformaço
procuram obter um banco de dados que ocupe pouco espaco em disco. O objetío de
reduzir espaco de armazenamento era, ate aĺum tempo atras, ţo importante quanto o
objetío de melhorar a performance e simplificar o deseńoĺimento. Entretanto, nos
́ltimos anos, o preco dos meios de armazenamento tem diminuido, o que fez com que a
reduço de espaco ocupado, principalmente se em detrimento dos demais objetíos,
diminuisse de importancia.
A fim de alcancar os dois objetíos citados, as réras de traduço foram definidas
tendo por base, entre outros, os séuintes principios:
 Éitar juncões – Ter os dados necessarios a uma consulta em uma ́nica linha –
Hm SGBD relacional normalmente armazena os dados de uma linha de uma tabela
contíuamente em disco. Com isto, todos os dados de uma linha tabela şo
trazidos para a memoria em uma ́nica operaço de acesso a disco. 
 Diminuir o ńmero de cháes – Para a implementaço eficiente do controle da
unicidade da cháe primaria ou cháe alternatía, o SGBD usa normalmente uma
estrutura de acesso auxiliar, um indice. O indice permite que o SGBD teste
rapidamente a existencia do ́alor de uma cháe primaria sendo incluida, sem que
seja necessario fazer uma leitura exaustía de toda tabela.
Para exemplificar, ́amos considerar que se deseja armazenar dados sobre clientes
em um banco de dados relacional. Deseja-se armazenar, para cada cliente, seu codío,
seu nome, o nome da pessoa de contato, o endereco e o telefone. Estes dados poderiam
ser implementados atráes de uma das séuintes alternatías:
Cliente(CodCliente,Nome,NomeContato,Endereço,Telefone)
ou
Cliente (CodCliente,Nome,NomeContato)
ClienteEnder(CodCliente,Endereço,Telefone)
CodCliente referencia Cliente
Na primeira alternatía, o SGBD cria apenas um indice por codío de cliente, a
cháe primaria da tabela. Na séunda alternatía, o SGBD cria, para cada tabela, um
indice por codío de cliente. Como cada cliente aparece nas duas tabelas, os dois indices
possuem exatamente as mesmas entradas, resultando em armazenamento e
processamento dobrados. A primeira alternatía e a preferida se considerarmos este
principio de projeto.
 Éitar campos opcionais – Campos opcionais şo campos que podem assumir o
́alor ́azio oNHLL em SQL). Os SGBDs relacionais usualmente ņo desperdicam
espaco ao armazenar um campo ́azio, pois usam tecnicas de compresşo de
dados e réistros de tamanho ́ariáel no armazenamento interno de linhas. Assim,
em principio, ņo ha problemas em usar este tipo de campo.
Para euser o2011), o processo de projeto lóico consta dos séuintes passos:
1 Implementaço inicial de entidades e respectíos atributos 
2 Implementaço de relacionamentos e respectíos atributos 
3 Implementaço de ́eneralizacõeseespecializacões
1.3.1 Implementacão inicial de entidades
Cada entidade e traduzida para uma tabela. Neste processo, cada atributo da
entidade define uma coluna desta tabela. Os atributos identificadores da entidade definem
as colunas que compõem a cháe primaria da tabela.
A Fíura 7 apresenta um exemplo da transformaço de uma entidade em uma
tabela. A fíura mostra o DER e o esquema relacional correspondente. A entidade
PESSOA com seus atributos código, nome, endereco, data de admissão e data de
nascimento e transformada na tabela denominada Pessoa com colunas denominadas
CodigoPess, Nome, Endereco, DataNasc e DataAdm. Como o atributo codío e
identificador da entidade, a coluna correspondente a este atributo e a cháe primaria da
tabela.
Fíura 7 - Transformaço de entidade em tabela oFonte: euser, 2011)
1.3.1.1 Nomes de atributos e nomes de colunas
Para euser o2011), ņo e aconselháel simplesmente transcréer os nomes de
atributos para nomes de colunas. Nomes de colunas seŗo referenciados frequentemente
em próramas e outras formas de texto em computador. Assim, para diminuir o trabalho
dos próramadores e cońeniente manter os nomes de colunas curtos. Alem disso, em
um SGBD relacional, o nome de uma coluna ņo pode conter brancos, nem hifens.
Assim, nomes de atributos compostos de díersas paláras déem ser abréiados. 
Com base nestas consideracões, os nomes de atributos data de nascimento e
data de admissão foram traduzidos para os nomes de colunas DataNasc e DataAdm
respectíamente.
Nas lińuáens de banco de dados, o nome da tabela e muitas ́ezes usado como
qualificador do nome da coluna. Por exemplo, para referenciar a coluna Nome da tabela
Pessoa muitas ́ezes e usado um termo na forma “Pessoa.Nomẽ. Por isso, ņo e
recomendado incluir, no nome de uma coluna, o nome da tabela em que ela aparece. 
Assim, e recomendado usar o nome de coluna Nome, a usar os nomes de coluna
NomePess ou NomePessoa. 
A exceço a esta réra e a coluna cháe primaria da entidade. Como esta coluna
pode aparecer em outras tabelas, na forma de cháe estrańeira, e recomendáel que os
nomes das colunas que compõem a cháe primaria sejam sufixados ou prefixados com o
nome ou síla da tabela na qual aparecem como cháe primaria. Por este motío, a
coluna cháe primaria da tabela do exemplo recebeu a denominaço de CodigoPess.
Outra recomendaço quanto à nomeaço de colunas e relatía ao uso de
abréiaturas. Muitas ́ezes usa-se determinadas abréiaturas para tipos de campos que
se repetem, como Cod para um codío e No ou Num para um ńmero. A recomendaço
e que se use sempre a mesma abréiatura em todo o banco de dados.
1.3.2 Relacionamento identificador
A réra de implementaço de relacionamentos identificadores e a séuinte:
 Para cada relacionamento identificador, e criada uma cháe estrańeira na tabela
que implementa a entidade identificada pelo relacionamento identificador. Esta
cháe estrańeira e formada pelas colunas da cháe primaria da tabela
referenciada pela cháe estrańeira. A Fíura 8 apresenta um exemplo de
implementaço de entidade com relacionamento identificador.
Fíura 8 - Implementaço de entidade com relacionamento identificador 
oFonte: euser, 2011)
 A cháe primaria da tabela que implementa a entidade identificada pelo
relacionamento identificador e formada por:
 colunas correspondentes aos atributos identificadores da entidade, se existirem, e 
 cháes estrańeiras que implementam os relacionamentos identificadores. 
Cabe obseŕar que, quando a entidade que possui o relacionamento identificador
referencia uma entidade, que, por sua ́ez, tambem tem um relacionamento identificador,
e necessario propáar por ́arios níeis a importaço de cháes estrańeiras para a
cháe primaria, como pode ser obseŕado na Fíura 9.
Fíura 9 - Implementaçode entidade com relacionamento identificador
oFonte: euser, 2011)
1.3.3 Implementacão de relacionamentos
De acordo com euser o2011), o fator determinante para a traduço a ser adotada
no caso de relacionamentos e a cardinalidade minima e maxima das entidades que
participam do relacionamento. Aapresentamos as tres alternatías basicas de traduço de
relacionamentos para o modelo relacional:
1.3.3.1 Tabela própria
Nesta traduço, o relacionamento e implementado atráes de uma tabela propria
que contem as séuintes colunas:
 colunas correspondentes aos identificadores das entidades relacionadas,
 colunas correspondentes aos atributos do relacionamento.
Caso o relacionamento tenha a cardinalidade n:n, a cháe primaria desta tabela
sera formada pelas colunas correspondentes aos identificadores das entidades
relacionadas e pelas colunas correspondentes aos atributos identificadores do
relacionamento, caso estes existam. 
Cada conjunto de colunas que corresponde ao identificador de uma entidade e
cháe estrańeira em relaço à tabela que implementa a entidade referenciada. 
Hm exemplo deste tipo de traduço e apresentado na Fíura 10 oem nérito).
Fíura 10 - Traduço de relacionamento por tabela propria oFonte: euser, 2011)
1.3.3.2 Adicão de colunas
A outra alternatía de implementaço de um relacionamento e a adiço de colunas
em uma das tabelas correspondentes às entidades que participam do relacionamento. 
Hm exemplo deste tipo de traduço e apresentado na Fíura 11. Este tipo de
traduço somente e possíel quando uma das entidades que participa do relacionamento
tem cardinalidade maxima 1 ono exemplo, trata-se da entidade EMPREGADO). 
Fíura 11 - Traduço de relacionamento por adiçao de coluna oFonte: euser, 2011).
1.3.3.3 Fusão de tabelas de entidades
A terceira forma de implementar um relacionamento e atráes da fuşo das tabelas
referentes às entidades eńoĺidas no relacionamento. 
Esta traduço somente pode ser aplicada quando o relacionamento e de tipo 1:1. A
traduço consiste em implementar, em uma ́nica entidade, todos os atributos de ambas
as entidades, bem como os atributos éentualmente existentes no relacionamento.
Hm exemplo deste tipo de traduço e apresentado na Fíura 12.
 
Fíura 12 - Traduço de relacionamento atráes de fuşo de tabelas 
oFonte: euser, 2011)
1.3.4 Detalhes da implementacão de relacionamentos
A alternatía especifica que dée ser usada na traduço de um relacionamento e
determinada pelas cardinalidades mínima e máxima das entidades eńoĺidas nos
relacionamentos.
A Tabela 1 da uma ́işo ́eral das alternatías que podem ser usadas. Para cada
combinaço de cardinalidades de relacionamento, a tabela mostra qual a alternatía
preferida e outras alternatías, se hoúer. A alternatía preferida e indicada pelo simbolo
V. Para aĺuns tipos de relacionamentos, existem outras alternatías que ́eram
implementaço correta, mas que, pelos principios por tras do projeto lóico, ņo
constituem a melhor implementaço. Elas şo indicadas pelos simbolos , em 
ordem decrescente de preferencia de uso. Finalmente, as alternatías que ņo fazem
sentido, porque léam a construcões ińalidas na abordáem relacional, şo indicadas
pelo simbolo x.
1.3.5 Relacionamento 1:1
1.3.5.1 Ambas as entidades tem participacão opcional
A Fíura 12 apresenta um exemplo de relacionamento 1:1 no qual a participaço
de ambas as entidades e opcional oa cardinalidade minima de ambas as entidades no
relacionamento e zero). 
Fíura 12 - Implementaço de relacionamento 1:1 com participaço opcional de ambas as
entidades oFonte: euser, 2011).
De acordo com a Tabela 1, a alternatía preferida de traduço de relacionamentos
com esta cardinalidade e a adiço de colunas na tabela referente a uma das entidades
que participam do relacionamento. Como e um relacionamento 1:1, qualquer das
entidades que participam do relacionamento pode ser a escolhida.
Hma soluço poderia ser:
Mulher(IdentM,Nome,IdentH,Data,Regime)
IdentH referencia Homem
Homem (IdentH,Nome)
Neste esquema, as colunas referentes ao relacionamento esţo marcadas em
nérito. Trata-se de colunas referentes aos atributos de casamento, bem como a coluna
IdentH, cháe estrańeira que implementa o relacionamento. Neste caso, optou-se,
arbitrariamente, por adicionar colunas à tabela Mulher. Da mesma forma, poderiam ter
sido adicionadas colunas oidentificador da mulher e atributos de casamento) à tabela
Homem.
A outra alternatía seria a de ́erar uma tabela propria para o relacionamento,
conforme o esquema a séuir:
Mulher(IdentM,Nome) [Homem (IdentH,Nome)
Casamento(IdentM,IdentH,Data,Regime)
IdentM referencia Mulher 
IdentH referencia Homem
A tabela que implementa o relacionamento e a tabela Casamento. Nesta tabela, as
colunas IdentH e IdentM şo ambas cháes estrańeiras, implementando desta forma a
́inculaço da linha de casamento às linhas de homem e mulher correspondentes. Como
se trata de um relacionamento 1:1, tanto a coluna IdentH, quanto a coluna IdentM podem
ser consideradas para a cháe primaria. No exemplo, a coluna IdentM foi arbitrariamente
escolhida como cháe primaria, sendo IdentH uma cháe alternatía.
1.3.5.2 Uma entidade tem participacão opcional e a outra tem participacão
obrigatória
Outro tipo de relacionamento 1:1 e aquele no qual uma das entidades tem
participaço obríatoria, enquanto que a outra entidade tem participaço opcional oa
cardinalidade minima de uma das entidades e um, a cardinalidade mínima da outra
entidade e zero). Hm exemplo desta situaço e apresentado na Fíura 13.
Fíura 12 - Implementaço de relacionamento 1:1 com participaço obríatoria de
uma entidade e participaço opcional da outra oFonte: euser, 2011)
Neste caso, a traduço preferida e atráes da fuşo das tabelas correspondentes
às duas entidades.
Alternatíamente, poderia ser considerada a traduço atráes da adiço de colunas
à tabela correspondente à entidade que obríatoriamente esta associada atráes do
relacionamento em quesţo ono exemplo, esta entidade e carţo mánetico).
Correntista(CodCorrent,Nome)
Cartão(CodCartão,DataExp,CodCorrent)
CodCorrent referencia Correntista
1.3.5.3 Ambas as entidades tem participacão obrigatória
O ́ltimo tipo de relacionamentos 1:1 e aquele no qual ambas as entidades tem
participaço obríatoria no relacionamento oa cardinalidade mínima de ambas as
entidades e um). Hm exemplo desta situaço e apresentado na Fíura 13.
Fíura 13 - Implementaço de relacionamento 1:1 com participaço obríatoria de
ambas as entidades oFonte: euser, 2011)
Neste caso, a traduço preferida e atráes da fuşo das tabelas correspondentes
às duas entidades.
Nenhuma das demais alternatías e adequada. Em ambas as alternatías, as
entidades que participam do relacionamento seriam representadas atráes de duas
tabelas distintas. Estas tabelas teriam a mesma cháe primaria e relaço um-para-um
entre suas linhas. Essa implementaço ́iola os principios de éitar juncões e diminuir o
ńmero de cháes primarias.
1.3.6 Relacionamentos 1:n
No caso de relacionamentos 1:n, a alternatía preferida de implementaço e a de
adiço de colunas.
. A Fíura 14 apresenta um exemplo desta traduço.
Fíura 14 - Traduço de relacionamentos 1:n atráes de adiço de colunas 
oFonte: euser, 2011)
Cabe obseŕar que, neste exemplo, a coluna CódigoEd da tabela Apartamento
oque implementa o relacionamento do apartamento com seu edificio), alem de ser cháe
estrańeira, e tambem parte da cháe primaria. Esta situaço e tipica de uma entidade
com relacionamento identificador.
No caso de a entidade com cardinalidade máxima 1 ser opcional, isto e, possuir
cardinalidade mínima 0, poderia ser considerada uma implementaço alternatía.Hm exemplo deste tipo de relacionamento e mostrado na Fíura 15. A entidade
VENDA esta opcionalmente líada à entidade FINANCEIRA.
Fíura 15 - Traduço de relacionamentos 1:n no qual a entidade com cardinalidade
maxima um e opcional oFonte: euser, 2011)
Para este tipo de relacionamento, pode ser usada alternatíamente a
implementaço atráes de tabela propria.
A implementaço atráes de adiço de colunas à tabela de entidade Venda
oimplementaço preferida) e a séuinte:
Financeira(CodFin,Nome)
Venda(IdVend,Data,CodFin,NoParc,TxJuros)
CodFin referencia Financeira
As colunas em nérito na tabela Venda implementam o relacionamento.
A implementaço atráes de tabela propria oimplementaço alternatía) e a
séuinte:
Financeira(CodFin,Nome)
Venda (IdVend,Data)
Financiam (IdVend,CodFin,NoParc,TxJuros)
IdVend referencia Venda 
CodFin referencia Financeira
A implementaço por tabela propria tem duas deśantáens em relaço à
implementaço por adiço de colunas:
 Operacões que eńoĺem acesso a dados de uma ́enda e do respectío
financiamento exíem juncões. Na primeira alternatía, isto ņo ocorre, ja que os
dados da ́enda e de seu financiamento esţo na mesma linha.
 As tabelas Venda e Financiam possuem a mesma cháe primaria, sendo o
conjunto de ́alores de Financiam um subconjunto de Venda. Tem-se o problema
acima mencionado de armazenamento e processamento duplicados de cháe
primaria.
A ́nica ́antáem que a implementaço por tabela propria apresenta e o fato de
nela háer campos que şo opcionais em certas linhas e obríatorios em outras. Este e o
caso dos campos CodFin, NoParc e TxJuros da tabela Venda na alternatía de adiço
de colunas. Estes campos esţo obríatoriamente preenchidos em caso de ́enda a prazo
e ́azios em caso contrario.
1.3.7 Relacionamento n:n
Independentemente da cardinalidade mínima, relacionamentos n:n şo sempre
implementados atráes de tabela propria. 
A alternatía de adicionar colunas a uma das tabelas correspondentes às entidades
que participam do relacionamento ņo e aplicáel. Cada entidade esta associada a um
ńmero ́ariáel de entidades. Para implementar o relacionamento atráes da adiço de
colunas, seria necessaria uma coluna multíalorada, que comportasse um conjunto de
́alores de cháes primarias, referente à entidade associada. Entretanto, as colunas na
abordáem relacional şo sempre monóaloradas. Assim, esta alternatía ņo e ́iáel,
pelas proprias caracteristicas da abordáem relacional.
1.3.8 Relacionamentos de grau maior que 2
As alternatías de implementaço de relacionamentos apresentadas ate este ponto
aplicam-se somente à implementaço de relacionamentos binarios, isto e, que eńoĺem
apenas duas entidades. Como anteriormente, aĺumas ́ariantes da abordáem ER
admitem relacionamentos de ́rau maior que 2. Para fins de exemplo, ́amos considerar o
modelo ER apresentado na Fíura 16.
Fíura 16 - Relacionamento ternario a ser implementado oFonte: euser, 2011)
Para relacionamentos de ́rau maior que 2, ņo şo definidas réras especificas. A
implementaço de um relacionamento de ́rau maior que 2 da-se na séuinte sequencia
de passos:
1 O relacionamento e transformado em uma entidade. Esta nóa entidade e
líada atráes de um relacionamento binario a cada uma das entidades que participáam
do relacionamento oríinal.
2 As réras de implementaço de entidades e relacionamentos binarios
apresentadas acima şo aplicadas às entidades e aos relacionamentos binarios assim
criados.
A Fíura 17 mostra o resultado da transformaço do relacionamento ternario que
aparece no modelo da Fíura 16 em uma entidade oresultado da aplicaço do passo 1 ).
Fíura 17 - Transformaço de relacionamento ternario em entidade 
oFonte: euser, 2011)
A implementaço deste modelo séuindo as réras apresentadas acima resulta no
séuinte esquema relacional:
Produto(CodProd,Nome) [Cidade (CodCid,Nome)
Distribuidor(CodDistr,Nome)
Distribuição (CodProd,CodDistr,CodCid,DataDeInicio)
CodProd referencia Produto 
CodDistr referencia Distribuidor 
CodCid referencia Cidade
1.3.9 Implementacão de generalicacão/especialicacão
Para a implementaço de hierarquias de ́eneralizaçoeespecializaço na
abordáem relacional, ha duas alternatías principais a considerar: 
o1) uso de uma tabela para cada entidade e 
o2) uso de uma ́nica tabela para toda hierarquia de ́eneralizaçoeespecializaço.
1.3.9.1 Uma tabela por hierarquia 
De acordo com euser o2011), nesta alternatía, todas as tabelas referentes às
especializacões de uma entidade ́enerica şo fundidas em uma ́nica tabela, composta
por:
 cháe primaria correspondente ao identificador da entidade mais ́enerico;
 caso ņo exista, uma coluna Tipo, que identifica que tipo de entidade
especializada esta sendo representada por cada linha da tabela;
 uma coluna para cada atributo da entidade ́enerica; 
 colunas referentes aos relacionamentos dos quais participa a entidade ́enerica e
que sejam implementados atráes da alternatía de adicionar colunas à tabela da
entidade ́enerica; 
 uma coluna para cada atributo de cada entidade especializada oestas colunas
déem ser definidas como opcionais, ja que somente teŗo ́alores quando a linha
for referente à entidade especializada em quesţo);
 colunas referentes aos relacionamentos dos quais participa cada entidade
especializada e que sejam implementados atráes da alternatía de adicionar
colunas à tabela da entidade oestas colunas déem ser definidas como opcionais,
ja que somente teŗo ́alores quando a linha for referente à entidade especializada
em quesţo).
Obseŕe que, pela definiço acima, uma entidade especializada pode ņo ́erar
uma coluna na implementaço. Isto ocorrera caso a entidade especializada ņo tenha
atributos e caso todos os relacionamentos dos quais ela participe sejam implementados
atráes de tabelas proprias.
Hm exemplo de implementaço usando uma ́nica tabela para toda hierarquia de
especializaço da entidade EMPREGADO aparece na Fíura 18.
Fíura 18 - ierarquia de ́eneralizaçoeespecializaço e sua implementaço atráes de
tabela ́nica oFonte: euser, 2011)
A tabela Emp, que implementa a entidade EMPREGADO e suas especializacões,
contem as séuintes colunas:
 CódigoEmp, cháe primaria da tabela, correspondente ao identificador da
entidade;
 as colunas Tipo, Nome e CPF referentes aos atributos da entidade ́enerica;
 a coluna CódigoDept, que implementa o relacionamento LOTAÇÃO; 
 a coluna CartHabil que implementa os atributos da entidade especializada
MOTORISTA; 
 a coluna CREA que implementa os atributos da entidade especializada
ENGENHEIRO; 
 a coluna CódigoRamo, que implementa o relacionamento entre ENGENHEIRO e
RAMO DA ENGENHARIA.
Pelas réras apresentadas anteriormente, os relacionamentos PARTICIPAÇÃO e
DOMÍNIO şo implementados por tabela propria, ņo ́erando colunas na tabela
correspondente à hierarquia de ́eneralizaçoeespecializaço. Alem disso, a entidade
SECRETÁRIA ņo ́era uma coluna, ja que ņo possui atributos, nem participa de
relacionamentos que ́erem colunas.
As colunas que correspondem às entidades especializadas oCartHabil, CREA e
CódigoRamo) déem ser definidas como colunas opcionais. Essa definiço e necessaria,
pois uma linha referente a um empréado, que ņo pertenca a aĺuma das classes
especializadas, tera todos os campos anteriormente listados ́azios. Ja uma linha
correspondente a uma entidade especializada tera aĺuns campos ́azios e outros
preenchidos. Exemplificando, uma linha referente a um eńenheiro teria os campos
CREA e CódigoRamo preenchidos e o campo CartHabil ́azio.
As demais tabelas que implementam o modelo da Fíura 18, definidas usando as
réras apresentadas nas secõesanteriores, şo:
 Depto, que implementa a entidade DEPARTAMENTO 
 Ramo, que implementa a entidade RAMO DA ENGENHARIA 
 ProcessTexto, que implementa a entidade PROCESSADOR DE TEXTO 
 Domínio, que implementa o relacionamento DOMÍNIO
 Projeto, que implementa a entidade PROJETO
 Participacão, que implementa o relacionamento PARTICIPAÇÃO
1.3.9.2 Uma tabela por entidade especialicada
Para euser o2011), uma outra alternatía de implementaço de uma hierarquia de
́eneralizaçoe especializaço e criar uma tabela para cada entidade que compõe a
hierarquia, aplicando as réras correspondentes à implementaço de entidades e
relacionamentos ja apresentadas nas secões anteriores.
O ́nico acrescimo que dée ser feito àquelas réras e a incluşo da cháe
primaria da tabela correspondente à entidade ́enerica, em cada tabela correspondente a
uma entidade especializada. Exemplificando, a implementaço do modelo ER da Fíura
18 resultaria no esquema relacional apresentado na Fíura 19 oem nérito).
Fíura 19 - Generalizaçoeespecializaço: implementaço atráes de uma tabela por
entidade especializada oFonte: euser, 2011)
Para a entidade EMPREGADO e cada uma de suas especializacões, foi criada
uma tabela. Estas tabelas tem, todas, a mesma cháe primaria. A tabela Emp contem
uma linha para cada empréado, independentemente de seu tipo. Nela aparecem as
informacões comuns a todos os empréados. As informacões referentes a cada tipo
particular de empréado esţo nas tabelas Motorista e Engenheiro. Em cada uma delas,
aparecem linhas somente para empréados pertencentes ao tipo representado pela
tabela.
Nas tabelas referentes às entidades especializadas, a cháe primaria e tambem
cháe estrańeira em relaço à tabela de empréados. Isso ocorre porque a toda
ocorrencia de uma entidade especializada corresponde uma ocorrencia de entidade
́enerica, ou seja, a toda linha de uma tabela de entidade especializada corresponde uma
linha da tabela da entidade ́enerica.
1.3.9.3 Comparacão entre as duas alternativas de implementacão
Vantáens da implementaço com tabela ́nica:
 Todos os dados referentes a uma ocorrencia de entidade ́enerica, bem como os
dados referentes a ocorrencias de sua especializaço, esţo em uma ́nica linha.
Ņo ha necessidade de realizar juncões, quando a aplicaço deseja obter dados
referentes a uma ocorrencia de entidade ́enerica juntamente com uma ocorrencia
de entidade especializada.
 A cháe primaria e armazenada uma ́nica ́ez, ao contrario da alternatía com
ḿltiplas tabelas, na qual a cháe primaria aparece tanto na tabela referente à
entidade ́enerica, quanto na tabela referente à entidade especializada.
Vantáens da implementaço com uma tabela por entidade especializada:
 As colunas opcionais que aparecem şo apenas aquelas referentes a atributos que
podem ser ́azios do ponto de ́ista da aplicaço. Na soluço alternatía, todas as
colunas referentes a atributos e relacionamentos das entidades especializadas
déem ser definidas como opcionais.
 O controle de colunas opcionais passa a ser feito pela aplicaço, com base no
́alor da coluna TIPO e ņo pelo SGBD, como ocorre na soluço alternatía.
O projetista déera ponderar as ́antáens e deśantáens de ambas as solucões
e optar por aquela que, considerando os fatores acima, seja a mais adequada ao seu
problema.
1.3.9.4 Subdivisão da entidade generica
Nesta alternatía, cria-se uma tabela para cada entidade especializada que ņo
possua outra especializaço oentidade folha da aŕore). Esta tabela contem tanto os
dados da entidade especializada, quanto os de suas entidades ́enericas. No caso do
modelo ER da Fíura 18, a implementaço e a apresentada na Fíura 20 oem nérito).
Fíura 20 - Generalizaçoeespecializaço: implementaço atráes de subdíişo da
entidade ́enerica oFonte: euser, 2011)
A diferenca desta alternatía em relaço a anterior e que, nesta alternatía, as
tabelas correspondentes às especializacões contem, ņo so os atributos da entidade
especializada, mas tambem os atributos de suas ́eneralizacões. A tabela contem ņo so
os atributos especificos da entidade MOTORISTA, mas tambem os atributos referentes à
sua ́eneralizaço oatributos CódigoEmp, Tipo, Nome, CPF e CódigoDept). De forma
analóa, a tabela Engenheiro contem ņo so os atributos especificos de eńenheiro, mas
tambem os de empréado. Finalmente, a tabela EmpOutros contem dados de todas as
demais catéorias de empréados.
E importante obseŕar que, nesta alternatía, as colunas CódigoEmp que
aparecem como cháe nas tabelas referentes às díersas especializacões de em préado
ņo şo cháe estrańeira, ja que ņo existe uma tabela onde todos os empréados
esţo reunidos, como ocorria na alternatía anterior. Alem disso, quando a especializaço
for total oe ņo parcial como no exemplo), deixa de existir a tabela que coleciona as linhas
referentes à entidades para as quais ņo ha especializaço ono exemplo, a tabela
EmpOutros).
Essa alternatía tem como ́antáens sobre as anteriores o fato de eliminar os
problemas de colunas opcionais e cháes primarias redundantes, tipicos das solucões
anteriormente apresentadas.
Entretanto, esta alternatía apresenta uma deśantáem do ponto de ́ista
funcional que supera as ́antáens oferecidas quanto ao uso mais eficiente de recursos.
Nesta alternatía, para ́arantir a unicidade da cháe primaria, a aplicaço que faz
inclusões de linhas de empréados dée ́erificar todas as tabelas referentes às
especializacões. Exemplificando, quando for incluido um nóo empréado, a aplicaço
déera testar a sua existencia nas tres tabelas oEmpOutros, Motorista e Engenheiro).
Essa ́erificaço fica a caŕo da aplicaço, ja que os SGBDs relacionais ņo şo capazes
de realiza-la automaticamente.
Adicionalmente, ņo ha como especificar ao SGBD restricões de intéridade
referenciais que facam referencia ao conjunto de empréados como um todo oja que este
ņo aparece no banco de dados).
1.4 Refinamento do modelo relacional
De acordo com euser o2011), o processo de traduço acima descrito léa a um
banco de dados correto do ponto de ́ista da abordáem relacional e que implementa os
dados que şo especificados pelo modelo conceitual. Entretanto, o banco de dados
projetado ņo dée ser ́isto como final, pois pode conter redundancia de dados,
conforme explicado mais adiante. Alem disso, dée ser considerado que, em todo
processo de eńenharia, esta eńoĺido um compromisso entre o ideal e o realizáel
dentro das restricões de recursos impostas pela pratica. No processo de eńenharia de
banco de dados, particularmente na implementaço de modelos conceituais, às ́ezes
tambem e necessario tracar um compromisso entre o ideal, representado pelas réras de
implementaço apresentadas, e o alcancáel frente a limitacões de performance. 
Aĺumas ́ezes, o esquema de BD criado atráes do uso dessas réras ņo atende
plenamente os requisitos de performance impostos ao sistema. Neste caso, e necessario
buscar uma alternatía de implementaço que resulte em um melhor desempenho do
sistema. Cabe salientar que estas alternatías somente déem ser aplicadas como ́ltimo
recurso, pois, do ponto de ́ista do deseńoĺimento de próramas sobre o banco de
dados, elas şo sempre piores que as alternatías que háiam sido apresentadas
anteriormente.
1.4.1 Redundância no banco de dados projetado
 a situacões em que a aplicaço das réras de traduço apresentadas léa a um
banco de dados com redundancia de dados. O problema esta líado ao uso de
relacionamentos identificadores.
Para mostrar um exemplo dessa situaço, ́amos considerar o modelo ER
mostrado na Fíura 21 que corresponde ao banco de dados de uma empresa queministra
cursos e que mantem informacões sobre as áaliacões dos cursos. A entidade CURSO
representa os cursos ministrados, háendo uma ocorrencia para cada curso. Hm curso e
identificado por um código, tem um nome, uma data de início e uma data de fim. A
entidade INSCRITO representa cada um dos inscritos em um curso. Esta entidade e
identificada pelo curso no qual ocorreu a inscriço e por um ńmero sequencial que
distińue as inscricões de um curso. Ja a entidade PROVA corresponde às próas que
şo realizadas em um curso, e e identificada pelo curso e por um ńmero sequencial da
próa dentro do curso. Finalmente, o relacionamento AVALIAÇÃO armazena a nota que
e atribuida a um inscrito em uma próa.
Fíura 21 - Modelo ER com relacionamentos identificadores oFonte: euser, 2011)
A aplicaço das réras de traduço descritas acima léa ao esquema relacional
mostrado na Fíura 22.
Fíura 22 - Modelo relacional resultante da aplicaço das réras de projeto lóico sobre o
modelo ER da Fíura 21 oFonte: euser, 2011)
Entretanto, o banco de dados da Fíura 22 apresenta redundancia de dados. As
colunas CodCursoProva e CodCursoInscrito contem exatamente os mesmos ́alores,
ja que os inscritos em cursos somente realizam próas do curso em que esţo inscritos, e
ņo em outros cursos. 
O problema e que esta restriço de intéridade ņo esta expressa no modelo ER e,
portanto, ņo e considerada pelas réras de traduço para o modelo lóico.
Por esta raz̧o, apos aplicar as réras de traduço de ER para relacional
apresentadas anteriormente, e necessario fazer uma réişo do modelo relacional, para
eliminar éentuais redundancias de dados.
No exemplo da Fíura 22, as colunas CodCursoProva e CodCursoInscrito
déem ser fundidas em uma ́nica coluna, o que resulta no modelo da Fíura 23.
Fíura 23 - Modelo relacional referente ao modelo ER da Fíura 21 apos a eliminaço de
redundancia oFonte: euser, 2011)
1.4.2 Manutencão de informaçoes redundantes no banco de dados
Por questões de desempenho das aplicacões que acessam o banco de dados, às
́ezes, informacões redundantes şo desejáeis no banco de dados. Isto pode ocorrer
com atributos redundantes, éentualmente resultantes de computacões que eńoĺam
́arios acessos ao banco de dados, e que şo acessados muito frequentemente, mas
sofrem poucas alteracões. 
Neste caso, considerando o desempenho do sistema como um todo, pode ser mais
eficiente manter o atributo redundante armazenado no banco de dados.
A Fíura 24 apresenta um exemplo, no qual aparece um atributo redundante em
um frámento do modelo de dados de um sistema de reseŕa de passáens aereas.
Trata-se do atributo número de reservas, que pode ser obtido pela contáem de todas
as reseŕas relacionadas ao ́oo. Do ponto de ́ista conceitual, o atributo ńmero de
reseŕas déeria ser eliminado, por ser redundante. Entretanto, do ponto de ́ista de
desempenho ́lobal do sistema, poderia ser importante manter uma coluna com este
́alor, caso a consulta ao ńmero de reseŕas fosse frequuente e sua computaço
demandasse tempo consideráel.
Fíura 24 - Atributo redundante mantido no projeto lóico oFonte: euser, 2011)
1.4.3 Simulacão de atributos multivalorados
Na abordáem relacional, ņo existem colunas multíaloradas. Por esta raz̧o,
modelos ER destinados ao projeto de bancos de dados relacionais şo, normalmente,
construidos sem o uso de atributos multíalorados. 
A Fíura 25 apresenta um diárama ER com atributos multíalorados e o diárama
obtido pela transformaço do atributo multíalorado em uma en tidade separada.
A implementaço do diárama da Fíura 25, caso sejam séuidas as réras
apresentadas, e a séuinte:
Fíura 25 - Eliminando atributos multíalorados oFonte: euser, 2011)
Entretanto, esta implementaço pode trazer problemas de desempenho, caso seja
necessario obter todos os telefones de um cliente com frequencia. Esta operaço implica
em busca de ́arias linhas de Telefone, tantas linhas quantos telefones o cliente possuir.
Dadas certas condicões de contorno, e possíel conceber uma implementaço
simplificada, que atenda com mais eficiencia às buscas aos telefones de um cliente.
Consideremos as séuintes condicões de contorno:
 Şo raros os clientes que possuem mais que dois telefones. Quando isso ocorrer, e
suficiente armazenar apenas dois ńmeros.
 Ņo ha consultas ao banco de dados usando o ńmero de telefone como criterio
de seleço. Os ńmeros de telefone şo apenas exibidos ou impressos junto às
demais informacões de cliente.
Neste caso, uma implementaço como a mostrada a séuir pode permitir um maior
desempenho das aplicacões:
Cliente(CodCli,Nome,NumTel1,NumTel2)
Nesta implementaço, optou-se por simular uma coluna multíalorada atráes da
criaço de díersas colunas NumTel sufixadas por um ńmero para distińui-las. Essa
alternatía permite que os telefones de um cliente sejam obtidos mais rapidamente, ja que
encontram-se todos dentro da mesma linha da tabela. Alem disso, implica em menos
espaco ocupado, ja que o espaco necessario à implementaço da cháe primaria da
tabela Telefone, na primeira alternatía, e consideráel.
Do ponto de ́ista funcional, o incońeniente desta alternatía e que operacões que
tratam com os telefones de um cliente como uma coleço ficam mais complexos em SQL.
Por exemplo, uma éentual consulta usando o ńmero de telefone como criterio de busca
torna-se mais complicada, ja que déem ser referenciados todos os nomes das colunas
referentes ao atributo multíalorado.
1.4.4 Relacionamentos mutuamente exclusivos
Outro caso que permite uma implementaço alternatía à especificada pelas réras
de projeto e aquele no qual uma entidade participa de forma mutuamente exclusía de
dois ou mais relacionamentos. Participar de forma mutuamente exclusía sínifica que
uma ocorrencia da entidade que participa de um dos relacionamentos em quesţo, ņo
participa dos demais relacionamentos. Hm exemplo e apresentado na Fíura 26. Pode-se
supor que uma ocorrencia da entidade VENDA participe de exatamente um dos dois
relacionamentos e de somente um deles. Obseŕe que esta informaço ņo esta contida
no diárama, ja que ņo ha uma cońenço para réistra-la no DER.
Fíura 26 - Relacionamentos mutuamente exclusíos oFonte: euser, 2011)
A implementaço para este modelo, caso forem séuidas as réras apresentadas, e a
séuinte:
PessFis(CPF,Nome)
PessJur(CNPJ,RazSoc)
Venda (No,data,CPF,CPF)
CPF referencia PessFis 
CNPJ referencia PessJur
Nesta implementaço, as colunas CPF e CNPJ şo especificadas como opcionais,
ja que, em cada linha, um ou outro campos seŗo ́azios. Aparecem assim os problemas
tipicos de colunas opcionais. Hma implementaço alternatía e criar uma ́nica coluna na
qual aparece o CPF ou o CNPJ do comprador, conforme mostrado abaixo.
PessFis(CPF,Nome)
PessJur(CNPJ,RazSoc)
Venda (No,data,CPF/CNPJ,TipoCompr)
Alem da fuşo das colunas CPF e CNPJ, dée ser criada uma coluna TipoCompr,
que informa se o campo na coluna CPF/CNPJ e referente a um comprador pessoa fisica
ou a uma pessoa juridica. Atráes desta alternatía éita-se o uso de colunas opcionais.
Entretanto, a alternatía apresenta íualmente uma deśantáem pois ņo e
possíel especificar ao SGBD que o campo CPF/CNPJ e cháe estrańeira, ja que ele
ņo referencia uma ́nica tabela, mas duas oPessFis e PessJur), de forma alternatía de
acordo com o ́alor do campo TipoCompr.
Apresentadas as alternatías de projeto acima, cabe reforcar a obseŕaço que ja
foi feita anteriormente: alternatías de implementaço que fóem às réras de projeto
lóico apresentadas somente déem ser tentadas em ́ltimo caso, quando outras
alternatías para a melhoria do desempenho ņo solucionarem o problema. Normalmente,
bases de dados que ņo foram projetadas de acordo com as réras implicamem custos
mais altos de deseńoĺimento e de manutenço das aplicacões deseńoĺidas sobre o
banco de dados.
1.5 Engenharia reversa de modelos relacionais
Para euser o2011), de forma ́eral, um processo de eńenharia réersa pode ser
definido como um processo de abstraço, que parte de um modelo de implementaço e
resulta em um modelo conceitual, que descrée abstratamente a implementaço em
quesţo. O termo eńenharia réersa ́em do fato de usar-se, como ponto de partida do
processo, um produto implementado oo modelo de implementaço) para obter sua
especificaço oo modelo conceitual).
No caso de banco de dados, fala-se de eńenharia réersa quando modelos de
dados mais ricos em detalhes de implementaço şo transformados em modelos de
dados mais abstratos.
Hm caso especifico de eńenharia réersa de banco de dados e o da eńenharia
réersa de modelos relacionais. Neste tipo de eńenharia réersa, tem-se, como ponto de
partida, um modelo lóico de um banco de dados relacional e, como resultado, um
modelo conceitual, no caso deste líro, na abordáem ER. Este e o processo ińerso ao
de projeto lóico.
A eńenharia réersa de modelos relacionais pode ser ́til quando ņo se tem um
modelo conceitual para um banco de dados existente. Isso pode acontecer quando o
banco de dados foi deseńoĺido de forma empirica, sem o uso de uma metodolóia de
deseńoĺimento, ou quando o esquema do banco de dados sofreu modificacões ao lońo
do tempo, sem que as mesmas tenham sido réistradas no modelo conceitual.
2 Referencias
 EHSER, Carlos Alberto. Projeto de Banco de Dados, 6ª ediço. Bookman, 2011.