BanDad-U3

Prévia do material em texto

3
Modelo de Dados Relacional
1. OBJETIVO
• Construir o conhecimento básico necessário para o desenvolvimento de um projeto 
lógico de Banco de Dados Relacional baseado no Modelo Conceitual.
2. CONTEÚDOS
• Modelo Relacional.
• Notação do Modelo Relacional.
• Atributos-chave de uma relação.
• Esquema de Banco de Dados Relacional.
• Restrições de integridade sobre relações.
• Projeto lógico de banco de dados: Entidade-Relacionamento para Relacional.
3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE 
Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
1) Lembre-se de que sua participação é fundamental para a construção do conhecimen-
to. Discuta com seus colegas e tutor sobre diferentes situações a fim de conhecer a 
realidade das salas de aula.
© Banco de Dados84
2) Realize as interatividades e atividades propostas. Participe! Interaja com seus colegas 
de curso e com seu tutor. Lembre-se de que é fundamental que você entregue as ati-
vidades nas datas previstas.
3) Fique atento a todo o conteúdo desta unidade, no qual você encontrará conceitos 
importantes para sua aprendizagem, como: modelo relacional, notação do modelo re-
lacional, atributos-chave de uma relação, esquema de banco de dados relacional etc.
4) Se necessário, retorne às unidades anteriores para entender e recordar os conceitos 
propostos. Consulte sempre o Glossário de conceitos-chave quando surgirem ideias 
que ainda não foram completamente abstraídas.
5) Entender álgebra relacional é importante para que você compreenda adequadamente 
o modelo relacional (E. F. Codd – 1970), o qual é baseado na lógica dos predicados e 
na teoria dos conjuntos.
4. INTRODUÇÃO À UNIDADE
Na unidade anterior, você teve a oportunidade de estudar o modelo entidade-relaciona-
mento (MER) e conhecer o que é entidade, atributos e conjuntos de entidades. Também pôde 
aprender como é a estrutura do diagrama entidade-relacionamento e como formular um proje-
to conceitual de banco de dados utilizando o MER.
Nesta unidade, você estudará o projeto lógico de um banco de dados relacional, cuja base 
é o modelo conceitual.
5. MODELO RELACIONAL
O modelo relacional, baseado na lógica dos predicados e na teoria dos conjuntos, foi apre-
sentado por E. F. Codd em 1970 e representa os dados contidos em um banco de dados por meio 
de relações (tabelas). 
A lógica dos predicados, amplamente utilizada pela matemática, fornece um modelo em 
que uma proposição (afirmação de um fato) pode ser verificada como verdadeira ou falsa. Por 
exemplo, suponha que uma estudante com ID 12345678 se chame Melissa Mendes. Essa pro-
posição pode ser facilmente demonstrada como verdadeira ou falsa. 
A teoria dos conjuntos é a parte da ciência matemática que lida com conjuntos (grupos 
de coisas), sendo utilizada como base para a manipulação de dados no modelo relacional. Por 
exemplo, suponha que o conjunto A contenha três números: 16, 24 e 77. Esse conjunto é repre-
sentado por A(16, 24, 77). O conjunto B, por sua vez, contém quatro números: 44, 77, 90 e 11, 
sendo, portanto, representado por B(44, 77, 90, 11). Com base nessas informações, é possível 
concluir que a intersecção de A e B dará origem a um terceiro conjunto, formado apenas pelo 
número 77. Esse resultado pode ser expresso por A ∩ B = 77. Em outras palavras, A e B com-
partilham um valor comum, 77.
Segundo Alvarenga (2012): 
O Modelo Relacional é claramente baseado no conceito de matrizes, onde as chamadas linhas (das 
matrizes) seriam os registros e as colunas (das matrizes) os campos. Os nomes das tabelas e dos cam-
pos são de fundamental importância para sua compreensão entre o que estamos armazenando, onde 
estamos armazenando e qual a relação existente entre os dados armazenados. 
Para esclarecer melhor essa questão, observe os nomes na Tabela 1, na qual serão feitas 
as comparações necessárias. Você pode notar que os nomes são diferentes para cada área de 
atuação, mas têm o mesmo significado em cada uma delas.
Claretiano - Centro Universitário
85© U3 – Modelo de Dados Relacional
Tabela 1 Comparações e convenções em banco de dados.
INFORMÁTICA TRADICIONAL BASE DE DADOS RELACIONAL ÁLGEBRA RELACIONAL
Arquivo Tabela Relação
Registro Linha Tupla
Campo Coluna Atributo
Existem algumas convenções importantes para a utilização dos nomes, quer para as tabe-
las, quer para os atributos que as constituem. Uma convenção não tem sentido obrigatório, no 
entanto deve ser respeitada para evitar incompatibilidades ou erros.
Determinados SGBD, como, por exemplo, o Microsoft Access, permitem alguma flexibili-
dade com os nomes das tabelas e os nomes dos atributos, ao contrário de outros. Essa flexibili-
dade pode trazer pequenos problemas quando pretendemos realizar a migração de um SGBD em 
MySQL ou Access, por exemplo, para um SGBD em Oracle. 
Os SGBDs que utilizam o modelo relacional são denominados SGBD Relacionais. Algumas 
convenções devem ser seguidas em um modelo relacional. Por exemplo, os nomes das tabelas 
deverão ter por base as entidades que representam. É necessário que o nome de cada tabela 
seja único, ou seja, não deve haver duplicação de nomes de tabelas dentro da mesma base de 
dados.
Existem diferentes convenções quanto à singularidade ou pluralidade dos nomes das ta-
belas. Não importa a convenção adotada, mas é importante manter a coerência do método ado-
tado em todas as tabelas; isto é, se a opção for um nome no singular, devem-se utilizar nomes 
no singular em todas as tabelas e vice-versa. 
Por convenção, para os nomes, devemos utilizar unicamente letras minúsculas e o unders-
core ( _ ) para separar palavras. Underscore também é conhecido como underline. 
Devemos usar abreviaturas quando necessário, por exemplo, para diminuir os nomes que 
atinjam o número máximo de caracteres permitidos pelo SGBD.
Os nomes dos campos devem basear-se no nome do atributo definido no desenho lógico, 
os quais devem ser únicos dentro da tabela; é necessário atenção, pois alguns SGBDs podem ser 
sensíveis ao fato de o nome do campo estar escrito em maiúsculas e/ou minúsculas.
Para que você entenda alguns nomes utilizados em uma relação, veja a Figura 1. Cada 
linha da relação será chamada de tupla, e cada coluna da relação será chamada de atributo. O 
conjunto de valores passíveis de serem assumidos por um atributo será intitulado de domínio. 
ALUNO NumMec Nome Curso
798764544 João Pinto CC
345673451 Carlos Semedo ERSI
487563546 Maria Silva EG
452212348 Pedro Costa MAT
relação
nome da relação atributos
tuplas
Figura 1 Exemplo da Relação ALUNO.
© Banco de Dados86
O esquema de uma relação nada mais são que as colunas existentes em uma tabela. Já 
a instância da relação consiste no conjunto de valores que cada atributo assume em um de-
terminado instante. Portanto, os dados armazenados no banco de dados são formados pelas 
instâncias das relações. 
Uma relação esquema R, dada por R(A1, A2, A3, ..., An), é um conjunto de atributos de R: {A1, 
A2, A3, ..., An }. Cada atributo Ai possui um domínio D(Ai). O grau de uma relação é definido como 
o número de atributos que ele contém.
Observando a Figura 1, podemos dizer que:
1) ALUNO (NumMec, Nome, Curso) é a relação esquema.
2) ALUNO é o nome da relação.
3) O grau da relação é 3.
4) Os domínios dos atributos são:
a) D(NumMec): números que representam o código dos alunos.
b) D(Nome): caracteres compostos de letras que formam o nome dos alunos.
c) D(Curso): caracteres que representam a sigla da disciplina.
É necessário destacar que as relações não podem ser duplicadas (não podem existir dois 
códigos idênticos de alunos no conjunto de Código de Alunos), e a ordem de entrada de dados 
no banco de dados não deverá ter qualquer importância para as relações, no que concerne ao 
seu tratamento. Os atributos deverão ser atômicos, isto é, indivisíveis. 
Tabela
A perspectiva lógica do banco de dados relacional é facilitada pela criação de relaciona-
mento de dados com base em uma estrutura conhecida como relação.Como a relação é uma 
estrutura matemática, os usuários finais consideram mais fácil pensar na relação como uma 
tabela, vista como uma estrutura bidimensional composta de linhas e colunas. Ela é chamada 
de relação, pois o criador do modelo relacional, E. F. Codd, utilizou esse termo como sinônimo 
de tabela.
Uma tabela pode conter um grupo de ocorrências de entidades relacionadas, ou seja, um 
conjunto de entidades. Por exemplo, uma tabela ALUNO contém um conjunto de ocorrências de 
entidades, cada uma representando um aluno.
As tabelas possuem várias características que devem ser compreendidas. Veja algumas 
destas características na Tabela 2:
Tabela 2 Características de uma tabela.
ITEM CARACTERÍSTICA
1 A tabela deve ser entendida como uma estrutura bidimensional composta de linhas e colunas.
2 Cada linha (tupla) representa uma única ocorrência de entidade no interior do conjunto de entidades.
3 Cada coluna da tabela representa um atributo e deve possuir um nome diferente.
4 Cada intersecção entre linha e coluna representa um único valor.
5 Todos os valores em uma coluna devem ser de um mesmo formato (número, data).
6 Cada coluna possui uma faixa específica de valores conhecida como domínio de atributos.
7 A ordem das linhas e das colunas é insignificante para o SGBD.
8
Cada tabela deve apresentar um atributo ou uma combinação deles que identifique o registro de forma exclusiva 
(CPF, por exemplo).
Claretiano - Centro Universitário
87© U3 – Modelo de Dados Relacional
A tabela representada pela Figura 2 apresenta uma exemplificação que aborda as caracte-
rísticas listadas na Tabela 2.
Figura 2 Exemplo de Tabela.
A Figura 2 demonstra um exemplo de tabela para cadastro de ALUNOS, em que cada co-
luna representa:
STU_NUM: Número do aluno.
STU_LNAME: Sobrenome do aluno.
STU_FNAME: Primeiro nome do aluno.
STU_CLASS: Classificação do aluno.
STU_DOB: Data de nascimento do aluno.
STU_GPA: Média das notas.
STU_HRS: Créditos-hora obtidos.
STU_INIT: Letra inicial do nome do meio do aluno.
STU_PHONE: Extensão de quatro dígitos do telefone do campus.
STU_TRANSFER: Aluno que foi transferido de outra instituição.
DEPT_CODE: Código do departamento.
PROF_NUM: Número do professor que é o orientador do aluno.
De acordo com os itens enumerados na Tabela 2, e utilizando a tabela ALUNO apresentada 
na Figura 2, podemos concluir que: 
1) A tabela ALUNO é vista como uma estrutura bidimensional composta de sete linhas 
(tuplas) e doze colunas (atributos).
© Banco de Dados88
2) Cada linha da tabela ALUNO descreve uma única ocorrência de entidade no interior 
do conjunto de entidades (esse conjunto é representado por toda a tabela ALUNO). 
Observe que a linha (entidade ou registro) definida por STU_NUM = 324561 define as 
características (atributos ou campos) de um aluno chamado João C. Silva. Já a Linha 4 
da Figura 2, por exemplo, descreve um aluno chamado Walter H. Ortolani; de modo si-
milar, a Linha 3 descreve uma aluna chamada Juliana Bravo. Dado o conteúdo da tabe-
la, o conjunto de entidade ALUNO inclui sete entidades (linhas) ou alunos diferentes.
3) Cada coluna representa um atributo e possui um nome diferente. Conforme pode ser 
observado, não se verifica nenhuma coluna cujo nome seja repetido.
4) Todos os valores de uma coluna atendem às características do atributo. Por exemplo, 
a coluna média das notas (STU_GPA) contém apenas entradas de STU_GPA em todas 
as linhas da tabela, ou seja, todas as entradas são relativas unicamente à média. Os 
dados devem ser classificados de acordo com seu formato e função.
Embora diferentes SGBDs possam dar suporte a diferentes tipos de dados, a maioria 
aceita, pelo menos, os seguintes dados:
a) Numéricos: são aqueles com os quais é possível executar procedimentos aritméti-
cos com significado. Por exemplo, as colunas STU_HRS e STU_GPA da Figura 2 são 
atributos numéricos. Por outro lado, STU_PHONE não é um atributo numérico, 
pois a adição ou subtração de números telefônicos não produz um resultado arit-
meticamente significativo.
b) Caracteres: conhecidos como dados de texto ou de string, podem conter quais-
quer caracteres ou símbolos não destinados à manipulação matemática. Na Figu-
ra 2, por exemplo, as colunas STU_LNAME, STU_FNAME, STU_INIT, STU_CLASS e 
STU_PHONE são atributos de caracteres.
c) Data: contêm datas de calendário armazenadas em um formato especial. Embora 
o armazenamento físico da data seja insignificante para o usuário ou o projetis-
ta, esse formato permite a execução de um tipo especial de aritmética conheci-
do como aritmética das datas. Utilizando-a, é possível determinar o número de 
dias que se passaram entre duas datas, como 12 de maio de 1999 e 20 de março 
de 2008, simplesmente subtraindo a primeira da segunda. Na Figura 2, a coluna 
STU_DOB pode ser classificada adequadamente como um atributo do tipo data. A 
maioria dos SGBDs relacionais permite a personalização do formato de apresen-
tação de dados. Por exemplo, os usuários de Oracle podem especificar o formato 
"dd/mmm/aaaa" para mostrar o primeiro valor de STU_DOB na Figura 2 como 12/
Fev/1975 (ao examinar os valores dessa coluna, você pode ver que esse formato 
foi selecionado para a apresentação da saída).
d) Lógicos: dados lógicos podem ser apenas uma condição verdadeira ou falsa (sim 
ou não). Por exemplo, um aluno é terceiro anista transferido? Na Figura 2, o atri-
buto STU_TRANSFER utiliza o formato de dados lógico, que também é conhecido 
como booleano. A maioria dos pacotes de software de bancos de dados relacio-
nais suporta esse formato.
5) A faixa de valores permitidos para a coluna é conhecida como domínio. Os valores de 
STU_GPA estão limitados na faixa 0-4, inclusive o domínio [0,4].
6) A ordem das linhas e das colunas é insignificante para o usuário.
7) Cada tabela deve ter uma chave primária. Em termos gerais, a chave primária (PK, do 
inglês Primary Key) é um atributo (ou uma combinação de atributos) que identifica 
exclusivamente uma determinada linha. Nesse caso, STU_NUM (o número do aluno) é 
a chave primária. Utilizando os dados representados na Figura 2, observe que o sobre-
nome de um aluno (STU_LNAME) não seria uma boa chave primária, pois é possível 
encontrar vários alunos com o sobrenome Smith, por exemplo. Mesmo a combinação 
de nome (STU_FNAME) e sobrenome não constituiria uma chave primária adequada, 
pois também é possível encontrar mais de um aluno chamado João Silva.
Claretiano - Centro Universitário
89© U3 – Modelo de Dados Relacional
6. NOTAÇÃO DO MODELO RELACIONAL
Algumas notações e conceitos devem ser considerados para apresentar o modelo relacio-
nal. Veja-os a seguir:
Relação
1) Conjunto não ordenado de tuplas.
2) Corresponde a entidades-tipo ou relacionamentos da base de dados. 
3) É definida por esquemas do tipo R(A1, A2, A3, ..., An), em que R é o nome da relação, e 
A1, A2, A3, ..., An é a lista de atributos. 
4) Corresponde a uma tabela de valores.
Atributo
1) Identifica uma característica/propriedade de uma relação.
Exemplo: 
R.Ai representa o atributo Ai da relação R. 
Domínio
1) Conjunto de valores atômicos que caracterizam um atributo.
Exemplo: 
D(Ai) representa o domínio do atributo Ai. 
Tuplas
1) Sequência ordenada de valores.
2) Todas as tuplas de uma relação são diferentes, pois representam entidades ou relacio-
namentos específicos da base de dados.
3) São definidas por sequência do tipo <v1, v2, v3, ..., vi>, em que cada vi corresponde ao 
valor da tupla para o atributo Ai ou valor null.
a) vi Є D(Ai) ou vi = NULL. Lê-se: vi, 1<= i <= n, ou é nulo ou pertence ao domínio D(Ai). 
b) t[Ai] ou t[i] representa o valor da tupla para o atributo Ai.
Figura 3 Tuplas.
© Banco de Dados90
4) Os nomes de atributos são, algumas vezes, qualificados com o nome da relação à qual 
pertencem, por exemplo: ALUNO.Nome ou ALUNO.Curso.
Exemplo:
• Considere a tupla t= <798764544, João Pinto, CC> da relação ALUNO da Figura 1. 
Temos que:
• t[NumMec] = 798764544 e t[Nome,Curso]=<João Pinto,CC>.
7. ATRIBUTOS-CHAVE DE UMA RELAÇÃO
Até o momento, você estudou vários conceitos importantes sobre o modelo de dados 
relacional. Neste tópico, iniciaremos o estudo de mais um conceito essencial para o seu apren-
dizado, que são os atributos-chave de uma relação. Fique atento!
No modelo relacional as chaves são importantes, pois sua utilização garante que cada 
linha da tabela seja identificável de modo exclusivo, facilitando buscas posteriores, além de 
assegurar a consistência e integridade dos dados. Elas também são utilizadas para estabelecer 
relacionamentos entre tabelas. 
Para cada relação, deve existir uma chave, que vai ser constituída por um atributo ou um 
conjunto de atributos e que identifica cada tupla (ou instância da relação) de um modo único, 
pois essa chave permite que seja estabelecido um relacionamento com outras tabelas. 
É importante lembrar que não podem existir duas tuplas com os mesmos dados para o 
mesmo atributo ou conjunto de atributos.
O papel da chave baseia-se em um conceito conhecido como determinação. No contexto 
de tabela de bancos de dados, a afirmação "A determina B" indica que conhecer o valor do atri-
buto A possibilita verificar (determinar) o valor de B. Por exemplo, conhecer apenas o identifi-
cador de um registro, como no exemplo da tabela ALUNO (Figura 2) – o STU_NUM –, é bastante 
útil, pois, a partir dele, torna-se possível obter (determinar) qualquer informação pertinente ao 
aluno cujo STU_NUM se faz conhecido: o sobrenome, a média das notas, o número de telefo-
ne, entre outros. A notação abreviada para "A determina B" é A à B. Se A determina B, C e D, 
escreve-se AàB, C, D. Portanto, utilizando os atributos da tabela ALUNO da Figura 2, é possível 
representar a afirmação "STU_NUM determina STU_LNAME", escrevendo:
STU_NUMSTU_LNAME
De fato, o valor STU_NUM da tabela ALUNO determina todos os valores de atributos do 
aluno. Por exemplo, é possível escrever:
STU_NUMSTU_LNAME, STU_FNAME, STU_INIT
e
STU_NUMSTU_LNAME, STU_FNAME, STU_INIT, STU_DOB, STU_TRANSFER
Fica claro que uma vez conhecido o identificador de um registro de uma tabela, é possível 
identificar, a partir dele, quaisquer atributos pertinentes a esse registro. Deste modo, conhecen-
do-se STU_NUM, podemos determinar qualquer atributo pertencente a um aluno; em contra-
partida, não é possível conhecer STU_NUM a partir de STU_LNAME, pois é possível que vários 
alunos tenham o mesmo sobrenome (por exemplo, Silva).
Claretiano - Centro Universitário
91© U3 – Modelo de Dados Relacional
O princípio de determinação é importante, pois é utilizado na definição de um conceito 
central de bancos de dados relacionais, conhecido como dependência funcional, o qual pode 
ser definido da seguinte maneira: o atributo B é funcionalmente dependente de A se A determi-
na B. Mais precisamente: o atributo B é funcionalmente dependente do atributo A se cada valor 
da coluna A determina um (e somente um) valor da coluna B.
Quando uma chave é composta apenas por um atributo, podemos dizer que se trata de 
uma chave simples. No exemplo da Tabela ALUNO, demonstrada na Figura 2, observa-se a exis-
tência de apenas uma chave. Uma chave constituída por mais de um atributo é denominada 
chave composta.
Para entender melhor o que são as chaves e como funcionam no modelo relacional, é 
necessário compreender alguns conceitos, tais como: chave candidata, chave primária e chave 
estrangeira. Observe suas definições a seguir:
Chave candidata é todo atributo ou conjuntos de atributos que permite identificar, de 
modo único, cada tupla. No entanto, para proceder a esta seleção de chaves candidatas, é ne-
cessário conhecer bem a realidade de cada um dos atributos da relação e qual o seu domínio.
Dentre todas as chaves candidatas, apenas uma será escolhida para identificar cada tupla 
de forma única. A chave selecionada dentre as chaves candidatas é designada chave primária 
da relação. Em todas as tabelas deve existir sempre uma chave primária, e os atributos que a 
constituem não podem conter valores nulos.
Uma chave candidata pode ser descrita como uma superchave sem atributos desnecessá-
rios, ou seja, uma superchave mínima.
A superchave é qualquer chave que identifique cada linha exclusivamente. Em resumo, 
ela determina funcionalmente todos os atributos de uma linha. Na tabela ALUNO, a superchave 
poderia ser qualquer uma das seguintes colunas:
STU_NUM
STU_NUM, STU_LNAME
STU_NUM, STU_LNAME, STU_INIT
De fato, STU_NUM, com ou sem valores adicionais, pode ser uma superchave, mesmo 
quando os atributos adicionais são redundantes.
Tomando como exemplo a chave composta STU_NUM, STU_LNAME, pode-se dizer que 
esta é uma superchave, mas não uma chave candidata. Para que esta chave pudesse ser uma 
chave candidata, teríamos que nos assegurar que não haveria nenhum sobrenome de aluno em 
duplicidade na tabela ALUNO.
Portanto, a chave primária é a chave candidata escolhida para construir o identificador 
exclusivo da linha. Podemos afirmar que uma chave primária é tanto uma superchave como uma 
chave candidata.
A chave primária possui algumas características, tais como:
• Ser unívoca: os atributos definidos para ser chave primária, por definição, devem ter 
valor único para cada registro ou tupla na relação, de modo a garantir que todas as 
linhas sejam identificadas exclusivamente por essa chave. Nesse caso, diz-se que a ta-
bela apresenta integridade de entidade.
© Banco de Dados92
• Não nula: nenhum dos atributos que formam uma chave primária poderá conter um 
valor nulo em um registro.
• Não redundante: no caso de uma chave primária ser composta, não devem ser incluí-
dos mais atributos do que os mínimos necessários para identificar os registros de modo 
unívoco.
Chave estrangeira (forasteira ou externa) é todo atributo ou conjunto de atributos que é a 
chave primária em outra tabela, ou seja, quando um atributo surge em mais do que uma tabela, 
estamos perante um relacionamento de tuplas. 
A redundância controlada faz com que o banco de dados relacional funcione. As tabelas 
no banco de dados compartilham atributos comuns que permitem sua ligação. Por exemplo, ob-
serve que as tabelas PRODUTO e FORNECEDOR na Figura 4 compartilham um atributo comum 
chamado VEND_CODE. Note também que o VEND_CODE com valor 232 na tabela PRODUTO 
ocorre mais de uma vez, assim como o 235. 
Como a tabela PRODUTO está relacionada a FORNECEDOR por meio desses valores VEND_
CODE, sua ocorrência múltipla é necessária para fazer com que o relacionamento 1:M entre 
FORNECEDOR e PRODUTO funcione. Cada valor VEND_CODE da tabela FORNECEDOR é exclu-
sivo, e o FORNECEDOR é o lado 1 do relacionamento FORNECEDOR-PRODUTO. Mas qualquer 
valor VEND_CODE da tabela FORNECEDOR pode ocorrer mais de uma vez na tabela PRODUTO, 
evidenciando que PRODUTO é o lado M desse relacionamento. Em termos de bancos de dados, 
as múltiplas ocorrências dos valores VEND_CODE na tabela PRODUTO não são redundantes, 
pois são necessárias para que o relacionamento funcione.
Figura 4 Exemplo de um banco de dados relacional simples.
Claretiano - Centro Universitário
93© U3 – Modelo de Dados Relacional
Na Figura 4, observe que o valor VEND_CODE em uma tabela pode ser utilizado para in-
dicar o valor correspondente em outra tabela. Desta forma, além de manter-se a integridade 
dos dados, evitamos repetições desnecessárias. Por exemplo, o valor VEND_CODE 235 na ta-
bela PRODUTO indica o fornecedor Henry Ortozo da tabela FORNECEDOR. Consequentemente, 
descobre-se que o produto Houselite chain saw, 16-in bar (motosserra Houselite com barra de 
16 polegadas) é fornecido por Henry Ortozo, o qual pode ser contatado pelo número 615-123-
5529. A mesma relação pode ser feita para o produto Steel tape, 12-ft legth (fita de aço com 12 
pés de comprimento) da tabela PRODUTO.
8. ESQUEMA DE BANCO DE DADOS RELACIONAL
No tópico anterior, você pôde observar um esquema de relação e uma relação associada. 
Agora, você conhecerá um sistema de banco de dados relacionale perceberá que ele contém, 
normalmente, várias relações em que as tuplas relacionam-se de diversas maneiras.
Um esquema de banco de dados relacional S é um conjunto de esquemas de relação S= 
{R1, R2, ..., Rm} e um conjunto RI de restrições de integridade. Já um banco de dados relacional 
BD de S é um conjunto de relações BD={r1, r2, ..., rm}, tal que cada ri é uma relação associada ao 
esquema Ri e satisfaz as restrições de integridade em RI.
No próximo tópico desta unidade, você verá mais detalhes sobre restrições de integridade.
Um esquema relacional é uma representação textual das tabelas de bancos de dados em 
que cada tabela PE relacionada com seu nome é seguida pela lista de seus atributos entre pa-
rênteses. O(s) atributo(s) de chave primária deve(m) aparecer sublinhado(s). Por exemplo, o 
esquema relacional para a Figura 4 seria representado como:
FORNECEDOR (VEND_CODE, VEND_CONTACT, VEND_AREACODE, VEND_PHONE)
PRODUTO (PROD_CODE, PROD_DESCRIPT, PROD_PRICE, PROD_ON_HAND, VEND_CODE)
A ligação entre as tabelas PRODUTO e FORNECEDOR da Figura 4 também pode ser repre-
sentada pelo diagrama relacional exibido na Figura 5. Nesse caso, a ligação é indicada pela linha 
que conecta as tabelas.
Figura 5 Diagrama relacional.
Observe que a ligação na Figura 5 é equivalente à reta de relacionamento de um DER. 
Ela é criada quando duas tabelas compartilham um atributo com valores comuns. Mais especi-
ficamente, a chave primária de uma tabela (FORNECEDOR) aparece como a chave estrangeira 
© Banco de Dados94
de uma tabela relacionada (PRODUTO). Uma chave estrangeira FK (do inglês Foreign Key) é um 
atributo cujos valores correspondem aos da chave primária na tabela relacionada. Por exemplo, 
na Figura 5, VEND_CODE é a chave primária da tabela FORNECEDOR e aparece como chave es-
trangeira da tabela PRODUTO.
Se a chave estrangeira contém valores correspondentes ou nulos, diz-se que a tabela que 
contém essa chave apresenta integridade referencial. Em outras palavras, integridade referen-
cial significa que se a chave estrangeira contém um valor, esse valor se refere a uma tupla (linha) 
válida existente em outra relação.
9. RESTRIÇÕES DE INTEGRIDADE SOBRE RELAÇÕES
As restrições de integridades mencionadas anteriormente correspondem às regras as 
quais toda relação de uma base de dados (relacional) deve obedecer. Tais regras são muito 
importantes para um projeto de bancos de dados e são aplicadas automaticamente por muitos 
SGBDs. 
Existem várias restrições que podem ser especificadas no modelo de dados relacional, 
conforme demonstra a Tabela 3: 
Tabela 3 Regras de integridade.
INTEGRIDADE DE ENTIDADES DESCRIÇÃO
Exigência Todas as entradas de chave primária são únicas e nenhuma parte dessa chave pode ser nula.
Finalidade Cada linha terá uma identidade exclusiva, e valores de chave estrangeira podem referenciar de modo adequado os valores de chave primária.
Exemplo Nenhum vendedor pode ter número duplicado nem ser nulo. Portanto, todos os vendedores são identificados de modo exclusivo por seu número.
INTEGRIDADE REFERENCIAL DESCRIÇÃO
Exigência
Uma chave estrangeira pode ter uma entrada nula, contanto que não faça parte de 
uma chave primária de suas tabelas, ou uma entrada que coincida com o valor de chave 
primária de uma tabela que esteja relacionada (todo valor não nulo de chave estrangeira 
deve referenciar um valor de chave primária existente).
Finalidade
É possível que um atributo não tenha valor correspondente, mas é impossível que tenha 
uma entrada inválida. A aplicação da regra de integridade referencial torna impossível a 
exclusão de uma linha de uma tabela cuja chave primária tenha valores obrigatórios de 
chave estrangeira em outra tabela.
Exemplo Um cliente pode ainda não ter recebido a atribuição de um representante de vendas (número), mas é impossível que tenha um representante de vendas inválido (número).
Uma definição formal da restrição de integridade referencial exige a definição de Chave 
Estrangeira (CE). Um conjunto de tributos CE em um esquema de relação R1 é uma chave es-
trangeira que referencia um esquema de relação R2 se ele satisfaz as seguintes propriedades: 
• Os atributos de CE possuem o mesmo domínio dos atributos da Chave Primária (CP) da 
outra relação de esquema R2. Diz-se que os atributos em CE referenciam ou referem-se 
a R2.
• Uma CE na Tupla t1 de r(R1) ou tem um valor que ocorre como CP de alguma Tupla t2 
de r(R2) ou tem o valor nulo. No primeiro caso, tem-se t1[CE] = t2[CP] e diz-se que t1 
referencia ou refere-se a t2.
Normalmente, as restrições de integridade referencial derivam-se dos relacionamentos 
entre conjuntos de entidades representadas pelos esquemas de relação. 
Claretiano - Centro Universitário
95© U3 – Modelo de Dados Relacional
Outras regras de integridade que podem ser aplicadas no modelo relacional são as restri-
ções not null e unique. A restrição not null pode ser aplicada a uma coluna para garantir que 
todas as linhas da tabela apresentem um valor para essa coluna, enquanto a restrição unique é 
aplicada a uma coluna para garantir que não haja nenhum valor duplicado.
10. OPERADORES DO CONJUNTO RELACIONAL
As operações da Álgebra Relacional são utilizadas para selecionar tuplas de uma deter-
minada relação ou para combinar tuplas relacionadas a diversas relações, com o propósito de 
especificar uma consulta (uma requisição de recuperação) sobre a base de dados. 
A Álgebra Relacional é uma coleção de operadores que tomam relações com seus ope-
randos e retornam uma relação como resultado. Desta forma, por meio de seus operadores 
específicos e adequados, é possível fazer a combinação de tuplas, relacionadas ou não, e obter 
a resultante desejada. 
A Álgebra Relacional é uma linguagem teórica que trabalha com operações que conte-
nham uma ou mais relações, a partir das quais outra relação é criada de modo a não alterar 
a relação originária. É importante mencionar que a Álgebra Relacional é uma linguagem abs-
trata, o que significa que as queries formuladas por ela não são destinadas à execução em 
um computador; portanto, o uso desta linguagem permite a compreensão da execução das 
queries no banco de dados. Somam oito os operadores relacionais: Union, Intersect, Diference, 
Product, Select, Project, Join e Divide.
Union
Este operador combina todas as linhas de duas tabelas, excluindo as duplicadas. As tabelas 
devem apresentar as mesmas características de atributos (as colunas e os domínios devem ser 
idênticos) para serem utilizadas no operador union. Um exemplo da utilização do union é apre-
sentado na Figura 6:
 P_CODE P_DESCRIPT PRICE 
345678 Mocrowave 160.00 
345679 Dishwasher 500.00 
 
P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
123459 9v Battery 1.99 
123460 Powerdrill 34.99 
 
P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
123459 9v Battery 1.99 
123460 Powerdrill 34.99 
345678 Mocrowave 160.00 
345679 Dishwasher 500.00 
 
UNION 
resulta em 
Figura 6 Union.
© Banco de Dados96
Intersect
O operador intersect resulta apenas em linhas que aparecem em ambas as tabelas. Assim 
como no union, só se produzirão resultados se as tabelas forem compatíveis para união. Por 
exemplo, não é possível utilizar intersect se um dos atributos for numérico e o outro for baseado 
em caracteres. Veja o efeito do intersect apresentado na Figura 7.
 F-NAME 
George 
Jane 
Elaine 
Wilfred 
Jorge 
 
F-NAME 
Jane 
William 
Jorge 
Dennis 
 
F-NAME 
Jane 
Jorge 
 
INTERSECT 
resulta em 
Figura 7 Intersect. 
Difference
O resultado deste operador será todas as linhas de uma tabela que não se encontram na 
outra tabela, ou seja, uma tabela é subtraída da outra. Como no caso do union, só se produ-
zirão resultados válidos se as tabelas forem compatíveis para união. O efeito do difference é 
apresentado na Figura 8. No entanto, observe que subtrair a primeira tabela da segunda não 
é igual a subtrair a segunda da primeira.F-NAME 
George 
Jane 
Elaine 
Wilfred 
Jorge 
 
F-NAME 
Jane 
William 
Jorge 
Dennis 
 
F-NAME 
George 
Elaiine 
Wilfred 
 
DIFFERENCE 
resulta em 
Figura 8 Difference.
Product
Resultará em todos os pares de linhas possíveis a partir de duas tabelas. Essa operação 
também é conhecida como produto cartesiano. Portanto, se uma tabela tiver seis linhas e a ou-
tra tiver três, o product resulta em uma lista composta de 6x3=18 linhas. O efeito do product é 
apresentado na Figura 9.
Claretiano - Centro Universitário
97© U3 – Modelo de Dados Relacional
 P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
213345 9v Battery 1.99 
 
STORE AILSE SHELF 
23 W 5 
24 K 9 
25 Z 6 
 
P_CODE P_DESCRIPT PRICE STORE AILSE SHELF 
123456 Flashlight 5.26 23 W 5 
123457 Flashlight 5.27 24 K 9 
123458 Flashlight 5.28 25 Z 6 
123457 Lamp 25.15 23 W 5 
123458 Lamp 25.16 24 K 9 
123459 Lamp 25.17 25 Z 6 
123458 Box Fan 10.99 23 W 5 
123459 Box Fan 10.100 24 K 9 
123460 Box Fan 10.101 25 Z 6 
213345 9v Battery 1.99 23 W 5 
213346 9v Battery 1.100 24 K 9 
213347 9v Battery 1.101 25 Z 6 
 
PRODUCT 
resulta em 
Figura 9 Product.
Select
Este operador, também conhecido como restrict, resulta nos valores de todas as linhas 
de uma tabela que satisfaçam uma dada condição. O select pode ser utilizado para listar todos 
os valores de linha ou apenas aqueles que atenderem a um critério especificado. Em outras 
palavras, select produz um subconjunto horizontal de uma tabela, e seu efeito é apresentado na 
Figura 10.
© Banco de Dados98
 Tabela original 
 P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
123459 9v Battery 1.99 
123460 Powerdrill 34.99 
 
Nova tabela ou lista 
 P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
123459 9v Battery 1.99 
123460 Powerdrill 34.99 
 
SELECT ALL resulta 
em 
SELECT apenas atributo PRICE inferior a US$ 2,00 resulta em 
P_CODE P_DESCRIPT PRICE 
123459 9v Battery 1.99 
 
SELECT apenas atributo P_CODE = 123457 resulta em 
P_CODE P_DESCRIPT PRICE 
123457 Lamp 25.15 
 
Figura 10 Operador Select.
Project
A resultante deste operador será todos os valores de atributos selecionados. Em outras 
palavras, o project produz um subconjunto vertical de uma tabela. Seu efeito é apresentado na 
Figura 11:
 Tabela original 
 P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
123459 9v Battery 1.99 
123460 Powerdrill 34.99 
 
PROJECT PRICE 
resulta em 
PRICE 
5.26 
25.15 
10.99 
1.99 
34.99 
 
Nova lista de tabelas 
P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
123459 9v Battery 1.99 
123460 Powerdrill 34.99 
 
PROJECT P_DESCRIPT e 
PRICE resulta em 
P_DESCRIPT PRICE 
Flashlight 5.26 
Lamp 25.15 
Box Fan 10.99 
9v Battery 1.99 
Powerdrill 34.99 
 
Figura 11 Operador Project.
Claretiano - Centro Universitário
99© U3 – Modelo de Dados Relacional
Join
O operador join possibilita a combinação de informações de duas ou mais tabelas. Trata-
-se da potência real por trás dos bancos de dados relacionais, e permite a utilização de tabelas 
independentes ligadas por atributos comuns. As tabelas CLIENTE e CORRETOR, apresentadas na 
Figura 12, ilustram vários tipos de utilização do operador join (junções).
 Nome da tabela: CLIENTE 
 CUS_CODE CUS_LNAME CUS_ZIP AGENT_CODE 
1234 Walker 31145 231 
1235 Adares 32145 125 
1236 Rakowski 34129 167 
1237 Rodriguez 37134 125 
1238 Smithson 37134 421 
1239 Vanloo 32145 231 
 
Nome da tabela: CORRETOR 
AGENT_CODE AGENT_PHONE 
125 6152439887 
167 6153426778 
231 6152431124 
333 9041234445 
 
Figura 12 Tabelas para demonstrar o operador Join.
A junção natural (natural join) liga tabelas selecionando apenas as linhas com valores co-
muns em seu(s) atributo(s) comum(ns). É o resultado de um processo em três estágios:
a) Aplica-se o operador product nas tabelas.
b) Executa-se uma operação select sobre o resultado da Etapa a para se obter apenas as 
linhas para as quais os valores AGENT_CODE são iguais. As colunas comuns são cha-
madas de colunas de junção.
c) Executa-se uma operação project sobre os resultados da Etapa b para produzir uma 
única cópia de cada atributo, eliminando-se, assim, as colunas duplicadas.
O resultado da operação join entre CLIENTE e CORRETOR é demonstrado na Figura 13:
Figura 13 Tabela resultado do Join entre CLIENTE e CORRETOR.
O resultado de uma junção natural produz uma tabela que não inclui pares sem corres-
pondência. O resultado fornece apenas as cópias das correspondências.
Outra forma de junção, conhecida como junção por igualdade (equijoin), tem por fina-
lidade realizar a ligação entre tabelas com base em uma condição de igualdade que compara 
colunas especificadas de cada tabela. O resultado da junção por igualdade não elimina colunas 
duplicadas, e a condição ou critério utilizado para unir as tabelas deve ser definido explicitamen-
te. Esse tipo de junção recebe seu nome em função do operador de comparação de igualdade 
(=) utilizado na condição.
Em uma junção externa (outer join), os pares com correspondência são mantidos e os va-
lores em correspondência na outra tabela são deixados nulos. De modo mais específico, se for 
realizado uma junção externa para as tabelas CLIENTE e CORRETOR, há duas situações possíveis:
© Banco de Dados100
• Junção externa à esquerda (left outer join): resulta em todas as linhas da tabela CLIEN-
TE, inclusive aquelas que não apresentam um valor correspondente na tabela CORRE-
TOR. Um exemplo dessa junção é apresentado na Figura 14:
Figura 14 Junção externa à esquerda.
• Junção externa à direita (right outer join): resulta em todas as linhas da tabela CORRE-
TOR, inclusive aquelas que não apresentam um valor correspondente na tabela CLIEN-
TE. Veja o exemplo na Figura 15:
Figura 15 Junção externa à direita.
Junções externas são especialmente úteis quando se tenta determinar qual(is) valor(es) 
de tabelas relacionadas causa(m) problemas de integridade referencial. Esses problemas são 
criados quando valores de chave estrangeira não correspondem a valores de chave primária 
da(s) tabela(s) relacionada(s).
Você deve estar se perguntando por que as junções externas são identificadas como à 
esquerda e à direita. Esses nomes se referem à ordem em que as tabelas são relacionadas no 
comando SQL.
Divide
A operação divide utiliza uma tabela com uma única coluna (por exemplo, a coluna A) 
como o divisor e uma tabela de duas colunas (por exemplo, as colunas A e B) como o dividendo. 
As tabelas devem ter uma coluna em comum (por exemplo, a coluna A). A saída da operação 
divide é uma única coluna com os valores da coluna A e as linhas da tabela de dividendo, em que 
o valor da coluna comum (por exemplo, a coluna A) coincide em ambas as tabelas. A Figura 16 
apresenta a operação divide:
Claretiano - Centro Universitário
101© U3 – Modelo de Dados Relacional
 CODE LOC 
A 5 
A 9 
A 4 
B 5 
B 3 
C 6 
D 7 
D 8 
E 8 
 
CODE 
A 
B 
 
LOC 
A 
 
DIVIDE 
Resulta em 
Figura 16 Divide.
No exemplo apresentado na Figura 16, observe que:
• A Tabela 1 é dividida pela Tabela 2 para produzir a Tabela 3. As Tabelas 1 e 2 contêm a 
coluna CODE, mas não compartilham a LOC.
• Para ser incluído na Tabela 3 resultante, um valor de uma coluna não compartilhada 
(LOC) deve estar associada (na Tabela 2 de divisão) a todos os valores da Tabela 1.
• O único valor associado tanto a A como a B é 5.
11. RELACIONAMENTOS DENTRO DO BANCO DE DADOS RELACIONAL
Até o momento compreendemos a importância de se manter a integridade dos dados e 
quais os seus tipos em um banco de dados. Conhecemos também os operadores básicos que 
embasam os operadores SQL para a manipulação dos dados.
Estudaremos neste tópico os tipos de relacionamentos que podem ser utilizados para a 
modelagem de um projeto de banco de dados, a fim de garantir melhor perfomance e, acima de 
tudo, manter a integridadedos dados.
Você já sabe que os relacionamentos são classificados como um para um (1:1), um para 
muitos (1:M) e muitos para muitos (M:N ou M:M). Veja, a seguir, mais informações sobre cada 
um desses relacionamentos.
Relacionamento 1:M
O relacionamento 1:M é a norma do banco de dados relacional. Para ver como esse re-
lacionamento é modelado e implementado, considere o exemplo "o PINTOR cria a PINTURA". 
Compare o modelo de dados na Figura 17 com sua implementação, na Figura 18:
Figura 17 Relacionamento 1:M entre PINTOR e PINTURA.
© Banco de Dados102
 Nome da Tabela: PINTOR 
 Chave primária: PAINTER_NUM 
 Chave estrangeira: nenhuma 
 PAINTER_NUM PAINTER_LNAME PAINTER_FNAME PAINTER_INITIAL 
123 Ross Georgette P 
126 Itero Julio G 
 
Nome da Tabela: PINTURA 
 Chave primária: PAINTING_NUM 
 Chave estrangeira: PAINTER_NUM 
 PAINTING_NUM PAINTING_TITLE PAINTER_NUM 
1338 Dawn Thunder 123 
1339 Vanilla Roses To Nowhere 123 
1340 Tired Flounders 126 
1341 Hasty Exit 123 
1342 Plastic Paradise 126 
 
Figura 18 Relacionamento 1:M implementado entre PINTOR e PINTURA.
Ao examinar o conteúdo da tabela PINTOR e PINTURA na Figura 18, observe os seguintes 
aspectos:
• Cada pintura é criada por um e somente um pintor, mas cada pintor pode ter criado 
várias pinturas. Observe que a Pintora 123 (Georgette P. Ross) possui três pinturas ar-
mazenadas na tabela PINTURA.
• Há apenas uma linha da tabela PINTOR para qualquer linha da tabela PINTURA, mas há 
várias linhas da tabela PINTURA para qualquer linha da tabela PINTOR.
Relacionamento 1:1
Como o próprio nome diz, no relacionamento 1:1 uma entidade pode ser relacionada à 
apenas outra entidade e vice-versa. Por exemplo, um chefe de departamento – um professor 
– pode chefiar apenas um departamento, e um departamento pode ter apenas um chefe. As 
entidades PROFESSOR e DEPARTAMENTO apresentam, portanto, um relacionamento 1:1.
O relacionamento 1:1 básico é modelado na Figura 19 e sua implementação é apresentada 
na Figura 20.
Figura 19 Relacionamento 1:1 entre PROFESSOR e DEPARTAMENTO.
Claretiano - Centro Universitário
103© U3 – Modelo de Dados Relacional
 Nome da Tabela: PROFESSOR 
 Chave primária: EMP_NUM 
 Chave estrangeira: DEPT_CODE 
 EMP_NUM DEPT_CODE PROF_OFFICE PROF_EXTENSION PROF_HIGH_DEGREE 
103 HIST DRE 156 3296 Ph.D. 
104 ENG DRE 102 3328 MA 
106 ACCT KLR 229 3392 Ph.D. 
110 MKT/MGT KLR 229B 3520 Ph.D. 
114 BIOL KLR 126 3648 Ph.D. 
155 ACCT AAJ 89 4960 Ph.D. 
160 MATH DBE 988 5120 Ph.D. 
162 ENG KLR 1898 5184 Ph.D. 
191 CIS DRE 293 6112 DBA 
195 MKT/MGT AAK 192 6240 Ph.D. 
209 PXYCH BBG 277 6688 Ph.D. 
228 CIS DK 123 7296 Ph.D. 
297 CIS DFK 134 9504 Ph.D. 
299 MATH AAC 182 9568 Ph.D. 
301 ECON/FUN ACE 282 9632 Ph.D. 
335 ACCT CDE 122 10720 Ph.D. 
342 ENG DKD 312 10944 Ph.D. 
387 SOC RTE 152 12384 Ph.D. 
401 BIOL DK 234 12832 MA 
425 HIST DFR 13600 MBA 
435 ECON/FUN DDF 39 13920 Ph.D. 
 
Nome da Tabela: DEPARTAMENTO 
 Chave primária: DEPT_CODE 
 Chave estrangeira: EMP_NUM 
 DEPT_CODE DEPT_NAME SCHOOL_CODE EMP_NUM DEPT_EXTENSION 
ACCT Accounting BUS 114 2933 
ART FineArts ASCI 435 2832 
BIOL Biology ASCI 387 4813 
CIS Computer Info. Systems BUS 209 4821 
ECON/FIN Economics/Finance BUS 299 3845 
ENG English ASCI 160 2482 
HIST History ASCI 103 3365 
MATH Mathematics ASCI 297 3461 
MKT/MGT Marketing/Management BUS 106 3471 
PSYCH Psychology ASCI 195 5732 
SOC Sociology ASCI 342 5735 
 
O relacionamento 1:M “o DEPARTAMENTO emprega o PROFESSOR” é implementado por meio da 
inserção da chave estrangeira DEPT_CODE na tabela PROFESSOR 
O relacionamento 1:1 “o PROFESSOR chefia o 
DEPARTAMENTO” é implementado por meio da inserção 
da chave estrangeira EMP_NUM na tabela 
DEPARTAMENTO 
Figura 20 Relacionamento 1:1 implementado entre PROFESSOR e DEPARTAMENTO.
Ao examinar as tabelas da Figura 20, observe que há vários aspectos importantes:
• Cada professor é um funcionário da Tiny College. Portanto, a identificação do professor 
se dá por meio de EMP_NUM (número de funcionário). No entanto, observe que nem 
todos os funcionários são professores, existindo outro relacionamento opcional.
• O relacionamento 1:1 "o PROFESSOR gerencia o DEPARTAMENTO" é implementado 
com o EMP_NUM como chave estrangeira da tabela DEPARTAMENTO. Observe que 
o relacionamento 1:1 é tratado como um caso particular do relacionamento 1:M, no 
qual o lado muitos está restrito a uma única ocorrência. Nesse caso, DEPARTAMENTO 
contém EMP_NUM como um chave estrangeira para indicar que é o departamento que 
possui um gestor.
© Banco de Dados104
• Observe também que a tabela PROFESSOR contém a chave estrangeira DEPT_CODE 
para implementar o relacionamento 1:M "o DEPARTAMENTO emprega o PROFESSOR". 
Esse é um bom exemplo de como duas entidades podem participar de dois (ou mais) 
relacionamentos simultâneos.
Relacionamento M:N
Para explorar o relacionamento muitos para muitos (M:N), considere um ambiente típico 
de faculdade em que cada ALUNO possa estar em várias TURMAs e cada TURMA possa conter 
vários ALUNOs. O modelo ER da Figura 21 mostra esse relacionamento M:N.
Figura 21 Relacionamento M:N do ER entre ALUNO e TURMA.
Observe os aspectos do ER da Figura 21:
• Cada TURMA pode ter vários ALUNOs e cada ALUNO pode estar em várias TURMAs.
• Pode haver muitas linhas na tabela TURMA para qualquer linha da tabela ALUNO e 
pode haver muitas linhas da tabela ALUNO para qualquer linha da tabela TURMA.
Os problemas inerentes aos relacionamentos muitos para muitos (M:N) podem ser fa-
cilmente evitados, criando-se uma entidade composta (também chamada de entidade ponte 
ou entidade associativa). Como essa tabela é utilizada para ligar as tabelas originalmente no 
relacionamento M:N, a estrutura da entidade composta inclui, como chaves estrangeiras, pelo 
menos as chaves primárias das tabelas que estão sendo ligadas.
É possível criar a tabela composta MATRÍCULA, exibida na Figura 22, para ligar as tabelas 
TURMAS e ALUNO. Nesse exemplo, a chave primária da tabela é a combinação de suas chaves 
estrangeiras CLASS_CODE e STU_NUM.
Figura 22 Conversão de um relacionamento M:N em dois relacionamentos 1:M.
Claretiano - Centro Universitário
105© U3 – Modelo de Dados Relacional
Observe na Figura 23 que o tipo de entidade chamada MATRÍCULA representa o relaciona-
mento TEM entre ALUNO e TURMA.
Figura 23 Alteração do relacionamento M:N em dois relacionamentos 1:M.
Índices
Suponha que se queira localizar um livro específico em uma biblioteca. Faria sentido olhar 
todos os livros até encontrar o desejado? É claro que não: utiliza-se o catálogo da biblioteca, 
que apresenta índices por título, assunto e autor. O índice (tanto em um sistema manual como 
em computadores) aponta para o local do livro, transformando sua localização em uma solução 
rápida e simples. Um índice é uma disposição ordenada utilizada para acessar logicamente as 
linhas de uma tabela.
Suponha, ainda, que você queira encontrar um assunto como, por exemplo, o modelo ER 
neste livro. Faria sentido ler todas as páginas até encontrar o tópico acidentalmente? Certamen-
te não. É muito mais simples recorrer ao índice do livro, procurar a expressão modelo ER e ler 
as referências que apontam para a(s) página(s) adequada(s). Em cada caso, o índice é utilizado 
para localizar rapidamente um item necessário.
De modo geral, um índice é uma disposição ordenada de chaves e ponteiros. Cada chave 
aponta para a localização dos dados identificados por ela.
Imagine que você queira procurar as pinturas criadas por determinado pintor no banco de 
dados da Figura 24. Sem um índice, é necessário ler todas as linhas da tabela PINTURA e ver se 
o atributo PAINTER_NUM corresponde ao pintor solicitado. No entanto, indexando-se a tabela 
PINTOR e utilizando-se a chave de índice PAINTER_NUM, basta procurar o valor adequado desse 
atributo no índice e encontrar os ponteiros correspondentes. Em termos conceituais, o índice se 
assemelha à apresentação ilustrada na Figura 24.
© Banco de Dados106
Figura 24 Componentesde um índice.
Ao examinar a Figura 24, observe que o primeiro valor da chave de índice PAINTER_NUM 
(123) encontra-se nos registros 1, 2 e 4 da tabela PINTURA da Figura 18. O segundo valor PAIN-
TER_NUM (126) encontra-se nos registros 3 e 5 dessa mesma tabela.
Os SGBDs utilizam índices para finalidades muito diferentes. Você pôde aprender que os 
índices podem ser utilizados para recuperar dados de modo mais eficiente, mas os SGBDs tam-
bém podem aplicá-los para recuperar dados ordenados por um ou vários atributos específicos. 
A criação de um índice de sobrenome de clientes, por exemplo, permitirá a recuperação alfabé-
tica dos dados de clientes a partir de seus sobrenomes. Além disso, a chave de índice pode ser 
composta por um ou mais atributos.
Os índices executam um papel importante nos SGBDs para a implantação das chaves pri-
márias. Ao se definir a chave primária de uma tabela, o SGBD cria automaticamente um índice 
exclusivo para a(s) coluna(s) dessa chave.
12. PROJETO LÓGICO DE BANCO DE DADOS: MAPEAMENTO DO MODELO 
ENTIDADE-RELACIONAMENTO PARA O MODELO RELACIONAL
Anteriormente, foram definidas as relações para o projeto de um banco de dados simples 
para uma escola, cujo modelo entidade-relacionamento foi demonstrado na Unidade 2. Neste 
tópico, mostraremos, passo a passo, como converter o projeto conceitual de um banco de dados 
no projeto lógico. Esses passos são fundamentados no Capítulo 9 do livro Sistemas de Bancos de 
Dados, de Elmasri e Navathe (2018), em que os autores apresentam as etapas de um algoritmo 
para mapeamento de DER (diagrama entidade-relacionamento) para o modelo relacional.
Para desenvolver os passos a seguir, você deve ter em mente as fases de construção de 
um banco de dados para facilitar as conversões do DER para o modelo relacional. Vale relembrar 
que o modelo entidade-relacionamento é utilizado durante o projeto conceitual e o modelo de 
dados relacional, durante o projeto lógico da base. Com isso, é natural pensar em um algoritmo 
que traduza os conceitos de um dos modelos (DER) nos conceitos do outro (relacional). Lembre-
-se de que o esquema relacional do banco de dados é extraído do DER, ou seja, nada pode ser 
acrescentado ou removido que não esteja projetado no DER.
Claretiano - Centro Universitário
107© U3 – Modelo de Dados Relacional
É importante reforçarmos a notação que deve ser adotada. Relembrando os 
símbolos do DER, Ramakrishnan e Gehrke (2008, p. 25) afirmam: "Um conjunto de 
entidades é representado por um retângulo, e um atributo é representado por um 
símbolo oval. Cada atributo da chave primária é sublinhado"; Elmasri e Navathe (2018 p. 
64), por sua vez, confirmam que "na notação diagramática ER, cada atributo-chave tem 
seu nome sublinhado dentro da oval".
Sobre relacionamentos, Ramakrishnan e Gehrke (2008, p. 25) definem que se trata 
de "uma associação entre duas ou mais entidades", enquanto Elmasri e Navathe (2018, 
p. 64) complementam que “tipos de relacionamento são mostrados em caixas em forma 
de losango, conectadas aos tipos de entidades participantes com linhas retas”.
Elmasri e Navathe (2018, p. 67) ainda acrescentam:
Os atributos são mostrados em ovais, e cada atributo é conectado por uma linha reta a seu tipo 
de entidade ou tipo de relacionamento. 
Os atributos componentes de um atributo composto são conectados ao oval que representa 
o atributo composto.
Os atributos multivalorados aparecem em ovais duplas [bordas simples].
Os atributos derivados aparecem em ovais tracejadas [bordas tracejadas].
Sobre o modelo relacional, Elmasri e Navathe (2018, p. 429) afirmam que 
"Consideramos que um conjunto de dependências funcionais é dado para cada relação, 
e que cada relação tem uma chave primária designada". Isso significa que nenhuma 
relação pode ficar sem a indicação da chave primária.
E como é indicada a chave primária? Elmasri e Navathe (2018, p. 145) apontam que 
“a convenção de que atributos que formam a chave primária de um esquema de relação 
são sublinhados” e que “em cada esquema de relação, o atributo sublinhado representa 
a chave primária”. Silberchatz, Korth e Sudarshan (2020, p. 27) também afirmam que “Os 
atributos de chave primária aparecem sublinhados”. Portanto, sublinhe os atributos que 
indicam qual é a chave primária da relação. Vale destacar, ainda, que "Valores null não 
podem aparecer em um campo de chave primária" (RAMAKRISHNAN; GEHRKE, 2008, p. 
57).
Elmasri e Navathe (2018, p. 148) afirmam que "para definir a integridade referencial 
de maneira mais formal, primeiro estabelecemos o conceito de uma chave estrangeira 
(ChE, ou foreign key, FK)". A versão original do livro é em inglês, por isso se adota o uso 
de FK; Como utilizamos a língua portuguesa, assumimos o sufixo –CE, uma simplificação 
de –ChE, proposta pelo tradutor do livro.
Ainda nesse contexto, Silberchatz, Korth e Sudarshan (2020, p. 27) definem que 
“em uma restrição de chave estrangeira, os atributos referenciados precisam ser a chave 
primária da relação referenciada”.
Já para Ramakrishnan e Gehrke (2008, p. 56), "A chave estrangeira na relação de 
referência deve corresponder à chave primária da relação referenciada; ou seja, ela deve 
ter o mesmo número de colunas e tipos de dados compatíveis, embora os nomes das 
colunas possam ser diferentes". Os autores citados afirmam também que "A presença 
de null em um campo de chave estrangeira não viola a restrição de chave estrangeira" 
(2008, p. 57).
© Banco de Dados108
A seguir, vamos verificar os sete passos do algoritmo proposto por Elmasri e Navathe 
(2018, p. 265-282):
Passo 1 – Entidades Normais/Fortes
Para cada tipo de entidade-forte E no diagrama entidade-relacionamento (DER), crie um esquema de 
relação R que inclua todos os atributos simples de E. Sobre os atributos compostos, inclua os atributos 
simples que os compõem. Escolha um dos atributos-chave de E como chave primária de R. Se a chave 
escolhida é composta, o conjunto dos atributos simples dessa chave forma a chave primária de R 
(ELMASRI; NAVATHE, 2018, p. 266).
Em outras palavras, execute o seguinte:
• Para cada um dos Tipos de Entidade Normal (retângulos com borda simples), crie uma 
nova relação.
• Nessa nova relação, acrescente todos os atributos simples (elipses com bordas sim-
ples).
• Se houver atributos compostos (atributos simples com “subatributos”), exclua o atribu-
to da raiz e acrescente apenas os “subatributos”.
• Não insira atributos multivalorados (elipses com bordas duplas) nem atributos deri-
vados (elipses com bordas tracejadas).
• A chave primária da relação deve ser escolhida dentre um dos atributos-chave (elipses 
com bordas simples e sublinhadas).
Por meio do diagrama entidade-relacionamento representado pela Figura 25, você pode 
identificar que o atributo código constitui a chave primária da entidade ora nomeada de aluno, 
e o atributo endereço é composto pelos atributos simples rua, número e bairro.
Aluno
Idade
Telefone
Endereço
Código
Nome
Sexo
Rua
Bairro
Número
Nascimento
Figura 25 ALUNO (Código, Nome, Sexo, Nascimento, Rua, Número, Bairro).
Claretiano - Centro Universitário
109© U3 – Modelo de Dados Relacional
Passo 2 – Entidades Fracas
Para cada tipo de entidade-fraca F no Diagrama Entidade-Relacionamento, crie um esquema de relação 
R que inclua todos os atributos simples de F. Além disso, inclua como chave estrangeira de R os atributos 
que formam a chave primária do esquema de relação associado à entidade proprietária E de F. A chave 
primária de R é uma combinação da chave primária de E com a chave parcial de F (ELMASRI; NAVATHE, 
2018, p. 267).
Analisando o passo 2, execute o seguinte:
• Para cada um dos Tipos de Entidade Fraca (retângulos com bordas duplas), crie uma 
nova relação.
• Nessa nova relação, acrescente todos os atributos simples (elipses com bordas sim-
ples).
• Acrescente o atributo que você escolheu como chave primária da relação (da qual o 
Tipo de Entidade Fraca depende) como chave estrangeira. Indique com o sufixo–CE. 
Você pode distinguir checando o relacionamento de identificação (losango com bordas 
duplas)
• Se houver atributos compostos (atributos simples com “subatributos”), exclua o atribu-
to da raiz e acrescente apenas os “subatributos”.
• Não insira atributos multivalorados (elipses com bordas duplas) nem atributos deri-
vados (elipses com bordas tracejadas).
• A chave primária dessa nova relação é a chave estrangeira mais a chave fraca (elipse 
com bordas simples e sublinhado tracejado) – portanto, será uma chave composta por 
dois atributos.
Elmasri e Navathe (2018, p. 72-73) afirmam:
Tipos de entidade que não possuem atributos-chave próprios são chamados tipos de entidade fraca. 
[...] As entidades pertencentes a um tipo de entidade fraca são identificadas por estarem relacionadas 
a entidades específicas de outro tipo em combinação com um de seus valores de atributo. Chamamos 
esse outro tipo de entidade de identificação ou proprietário e chamamos o tipo de relacionamento 
que relaciona um tipo de entidade fraca a seu proprietário de relacionamento de identificação 
do tipo de entidade fraca. Um tipo de entidade fraca sempre tem uma restrição de participação 
total (dependência de existência) [linha de ligação dupla] com relação a seu relacionamento de 
identificação, porque a entidade fraca não pode ser identificada sem uma entidade proprietária.
Os mesmos autores também definem que “Os tipos de entidade fraca são distinguidos 
ao serem colocados em retângulos duplos e terem seu relacionamento de identificação 
colocado em losangos duplos. A chave parcial do tipo de entidade fraca é sublinhada com 
um linha tracejada” (ELMASRI; NAVATHE, 2018, p. 75).
Sobre a chave parcial, característica das relações que representam entidades fracas, 
Ramakrishnan e Gehrke (2008, p. 31) asseguram:
Uma entidade fraca pode ser univocamente identificada apenas se considerarmos alguns dos seus 
atributos em conjunto com a chave primária de uma outra entidade. [...] O conjunto de atributos 
de um conjunto de entidades fracas que identifica univocamente uma entidade fraca de uma 
determinada entidade proprietária é chamada chave parcial do conjunto de entidades fracas.
Já Elmasri e Navathe (2018, p. 73) complementam:
Um tipo de entidade fraca normalmente tem uma chave parcial, que é o atributo que pode identificar 
exclusivamente as entidades fracas que estão relacionadas à mesma entidade proprietária. […] O 
atributo de chave parcial é sublinhado com uma linha tracejada ou pontilhada.
© Banco de Dados110
A Figura 26, por meio do diagrama-relacionamento, apresenta um exemplo de entida-
de fraca chamada de dependente, a qual possui uma chave primária composta formada pelos 
atributos NSS e Nome, em que o atributo NSS é uma chave estrangeira que referencia a chave 
primária da entidade, identificada como empregado.
Figura 26 DEPENDENTE (NSS-CE, Nome, Data_nasc, Relação, Sexo).
Passo 3 – Relacionamentos com Cardinalidade 1:1 (Um-para-Um)
O diagrama ER, identificado na Figura 27, demonstra cada tipo de relacionamento binário 
R 1:1 no diagrama Entidade-Relacionamento. Identifique os esquemas de relação S e T que dele 
participam. Escolha uma das relações, digamos S, e inclua como chave estrangeira de S a chave 
primária de T. Inclua todos os atributos simples de R como atributos de S (ELMASRI; NAVATHE, 
2018).
Resumidamente, você deve fazer o seguinte:
• Encontrar os Tipos de Relacionamento (losangos com bordas simples) que têm 
cardinalidade 1:1, ou seja, 1 dos dois lados.
• Receberá a chave estrangeira, o Tipo de Entidade que estiver do lado com participação 
total (linha dupla entre o tipo de relacionamento e o tipo de entidade).
Claretiano - Centro Universitário
111© U3 – Modelo de Dados Relacional
• Adicionar o atributo da chave primária do lado que tem participação parcial no 
relacionamento (linha simples) na relação do tipo de entidade que tem participação 
total (linha dupla). Se existirem outros atributos no relacionamento, adicione-os 
também na relação do lado que tem participação total. Lembre-se: não adicione 
atributos multivalorados nem atributos derivados.
• Não mexa na chave primária da relação! Ela foi definida no passo 1 e não deve ser 
modificada!
Na Figura 27 você pode identificar que o atributo nome forma a chave primária da entidade 
departamento. Como se trata de um relacionamento 1:1, no qual um empregado pode apenas 
gerenciar um único departamento e, por sua vez, um departamento pode ser gerenciado 
por, no máximo, um empregado, torna-se necessário inserirmos uma chave estrangeira em 
departamento. Essa chave é identificada como NSS, que referencia a chave primária da entidade 
empregado.
Nesse caso, em que a cardinalidade é 1:1, escolhe-se o lado no qual se deve colocar a chave 
estrangeira. Na prática, é melhor fazer essa "escolha" no momento do DER, escolhendo o lado 
com participação total (linhas duplas), o que deixaria o relacionamento conforme demonstrado 
na Figura 27.
Figura 27 DEPARTAMENTO (Nome, Número, NSS-CE).
Passo 4 – Relacionamento com Cardinalidade 1:N (Um-para-Muitos)
Para cada tipo de relacionamento binário R 1:M, identifique o esquema S que representa o tipo de 
entidade do lado M de R. Inclua como chave estrangeira de S a chave primária do esquema T que 
representa o outro tipo de entidade (do lado 1). Inclua todos os atributos simples de R como atributos 
de S (ELMASRI; NAVATHE, 2018, p. 269).
Em outras palavras, execute o seguinte:
• Encontre os Tipos de Relacionamento (losango com bordas simples) que têm 
cardinalidade 1 de um lado e N ou M do outro.
• Receberá a chave estrangeira a relação do Tipo de Entidade (retângulos) que está do 
lado N. Portanto, adicione a chave primária da relação do Tipo de Entidade do lado 1 na 
relação do Tipo de Entidade do lado N.
• Se existirem outros atributos no relacionamento, adicione-os também na relação do 
lado N. Lembre-se: não adicione atributos multivalorados nem atributos derivados.
• Não mexa na chave primária da relação! Ela foi definida no passo 1 e não deve ser 
modificada!
© Banco de Dados112
Você pode perceber que, ao realizamos o mapeamento da entidade DEPARTAMENTO, 
representada pela Figura 28, foi necessário incluir o atributo NSS, que, devido à cardinalidade 
1:N, é uma chave estrangeira que referencia a chave primária da entidade EMPREGADO. Você 
pode observar também que a diferença entre as Figuras 27 e 28 é a cardinalidade. O resultado, 
portanto, é semelhante.
Figura 28 Mapeamento de relacionamento binário (cardinalidade 1:N). DEPARTAMENTO (Nome, Número, NSS-CE).
Passo 5 – Relacionamentos com Cardinalidade M:N (Muitos-para-Muitos)
Para cada tipo de relacionamento binário R M:N, crie um novo esquema de relação S para representá-
lo. Inclua como chave estrangeira de S as chaves primárias dos esquemas de relação que representam 
os tipos de entidade participantes do relacionamento. A combinação dessas chaves forma a chave 
primária de S. Inclua todos os atributos simples de R como atributos de S (ELMASRI; NAVATHE, 2018, 
p. 270).
Diante do exposto, execute o seguinte:
• Encontre os Tipos de Relacionamento (losangos com borda simples) que têm cardinali-
dade M de um lado e N do outro.
• Crie uma nova relação para representar esse relacionamento.
• Adicione nessa nova relação as chaves estrangeiras das relações que representam os 
dois Tipos de Entidade (retângulos) que participam do relacionamento.
• Se existirem outros atributos no relacionamento, adicione-os também na nova relação. 
Lembre-se: não adicione atributos multivalorados nem atributos derivados.
• A chave primária dessa nova relação será a combinação das 2 chaves estrangeiras adi-
cionadas! Portanto, será uma chave primária composta por, pelo menos, 2 atributos.
Ramakrishnan e Gehrke (2008, p. 35) afirmam que, em relacionamentos M:N, não 
existem chaves primárias, "porque um relacionamento é identificado univocamente pelas 
entidades participantes".
Ainda nesse contexto, Elmasri e Navathe (2018, p. 270)destacam que “Não podemos 
representar um tipo de relacionamento M:N por um único atributo de chave estrangeira em 
uma das relações participantes, temos de criar uma relação separada”.
Claretiano - Centro Universitário
113© U3 – Modelo de Dados Relacional
Na Figura 29, que ilustra um exemplo de um Diagrama Entidade-Relacionamento, você 
constatará a necessidade de criarmos um novo esquema, identificado como professor_leciona_
disciplina, que é formado pelos atributos codigo_prof e codigo_disc. Ambos formam a chave 
primária composta dessa entidade e também são chave estrangeira, ou seja, codigo_prof 
referencia a chave primária da entidade professor e codigo_disc, a chave primária da entidade 
disciplina.
Figura 29 PROFESSOR_LECIONA_DISCIPLINA (Codigo_prof-CE, Codigo_disc). 
Passo 6 – Atributos Multivalorados (elipses com bordas duplas)
Para cada atributo multivalorado A, crie um novo esquema de relação R. Esse esquema incluirá 
dois atributos: um correspondente a A e outro correspondente à chave primária K do esquema que 
representa o tipo de entidade que possui A como atributo. A chave primária de R é a combinação de A 
e K (ELMASRI; NAVATHE, 2018, p. 270).
Colocando em prática a descrição anterior, realize as indicações a seguir:
• Encontre os atributos multivalorados (elipses com bordas duplas) do DER. Eles ainda 
não foram mapeados.
• Para cada um deles, mesmo que estejam ligados ao mesmo Tipo de Entidade (retângu-
lo), crie uma nova relação.
• Adicione a essa nova relação como chave estrangeira a chave primária da relação que 
representa o tipo de entidade a que o atributo multivalorado está ligado.
• Adicione à relação o atributo multivalorado.
• A chave primária da nova relação será a combinação da chave estrangeira e do atri-
buto multivalorado; portanto, essa nova relação terá uma chave composta por pelo 
menos dois atributos.
Perceba que, quando realizamos o mapeamento da entidade aluno, ilustrado na Figura 
30, torna-se necessária a criação de um esquema, identificado como telefone_aluno, formado 
pelos atributos codigo_alu e telefone, com codigo_alu sendo a chave estrangeira que referencia 
a chave primária da entidade aluno, pelo simples fato de o atributo telefone ser multivalorado.
© Banco de Dados114
Aluno
Idade
Telefone
Endereço
Código
Nome
Sexo
Rua
Bairro
Número
Nascimento
Figura 30 TELEFONE_ALUNO (Codigo_alu-CE, Telefone).
Passo 7 – Relacionamento (n)ários M:N (Relacionamentos ternários e/ou Quaternários)
Para cada tipo de relacionamento m-ário R (quando existem 3 ou 4 tipos de entidade ligadas ao mesmo 
relacionamento), em que M>2, crie um novo esquema de relação S para representar R. Inclua como 
chaves estrangeiras em S as chaves primárias dos esquemas de relação relacionados aos tipos de 
entidades que participam do relacionamento. Inclua todos os atributos simples de R como atributos de 
S. A chave primária de S corresponde à combinação de todas as chaves estrangeiras que referenciam 
os esquemas de relação das entidades participantes do relacionamento (ELMASRI; NAVATHE, 2018, p. 
271).
Em resumo, faça o seguinte:
• Procure no DER um relacionamento ternário ou quaternário (com 3 e 4 tipos de enti-
dades, respectivamente).
• Crie uma nova relação para representar esse relacionamento.
• Adicione a essa nova relação as chaves estrangeiras das relações que representam os 
Tipos de Entidade (retângulos) que participam do relacionamento.
• Se existirem outros atributos no relacionamento, adicione-os também à nova relação. 
Lembre-se: não adicione atributos multivalorados nem atributos derivados.
• A chave primária dessa nova relação será a combinação das 2 chaves estrangeiras adi-
cionadas! Portanto, será uma chave primária composta por, pelo menos, 3 atributos se 
o relacionamento for ternário, e por 4, se for quaternário.
A Figura 31 representa esse tipo de relacionamento, tornando-se necessária a realização 
do mapeamento do relacionamento identificado em matricula-se, que, a partir de agora, passa 
a ser uma entidade, a qual é nomeada como matrícula, formada pelos atributos codigo_tur, 
codigo_disc, codigo_prof e codigo_alu. Todos esses atributos, chaves estrangeiras, referenciam 
respectivamente suas chaves primárias correspondentes.
Claretiano - Centro Universitário
115© U3 – Modelo de Dados Relacional
Figura 31 MATRICULA (Codigo_tur-CE, Codigo_Disc-CE, Codigo_Prof-CE, Codigo_alu-CE).
ATENÇÃO!
O relacionamento descrito é quaternário. Quando há três entidades envolvidas, ele 
deve ser chamado de relacionamento ternário.
Considerando o banco de dados escolar demonstrado na Unidade 2, veremos, a seguir, um 
exemplo de banco de dados lógico.
De acordo com os sete passos mencionados anteriormente, definiremos, agora, as 
entidades e os atributos das entidades.
Aplicação dos passos – banco de dados escolar
Por exemplo, no caso do banco de dados escolar (Figura 32), você deve, inicialmente, 
seguir o Passo 1. Logo você terá as seguintes entidades: professor, disciplina, curso e aluno.
© Banco de Dados116
Figura 32 DER Sistema Escolar.
Passo 1 – Tipos de Entidades Normais/Fortes
1) PROFESSOR (Codigo, Nome, Titulo).
2) DISCIPLINA (Codigo, Nome).
3) CURSO (Codigo, Nome).
4) TURMA (Codigo, Periodo_letivo, Inicio, Termino).
5) ALUNO (Codigo, Nome, Sexo, Nascimento, Rua, Numero, Bairro, Cidade).
Não será necessário fazer o passo 2 porque no DER não há Entidades Fracas.
Passo 3 – Relacionamentos com cardinalidade 1:1
Temos um relacionamento assim, que é leciona. Observe que quem tem a participação 
total no relacionamento é Disciplina. Assim, Disciplina receberá a chave estrangeira de Professor.
6) DISCIPLINA (Codigo, Nome, Codigo_Prof-CE).
Passo 4 – Relacionamentos com cardinalidade 1:N
Temos um relacionamento assim, que é possui. Observe que o tipo de entidade que está 
do lado N é Turma; assim, Turma receberá a chave estrangeira de Curso.
7) TURMA (Codigo, Periodo_letivo, Inicio, Termino, Codigo_Cur-CE).
Passo 5 – Relacionamentos com cardinalidade M:N
Temos dois casos de relacionamento com cardinalidade M:N, Matricula-se e Oferecida. 
Criaremos duas novas relações, uma para cada um deles e adicionaremos as chaves primárias 
Claretiano - Centro Universitário
117© U3 – Modelo de Dados Relacional
dos tipos de entidade que participam de cada um dos relacionamentos como chave estrangeira. 
A combinação dessas chaves estrangeiras formará a chave primária das novas relações. 
Acrescentamos também os atributos do relacionamento (exceto o atributo derivado), sendo 
que Data_Matricula, que é multivalorado, também será adicionado à chave primária.
8) MATRICULA (Codigo_Tur-CE, Codigo_Alu-CE, Data_Matricula, Data_Cancelamento, 
Motivo_Cancelamento).
9) OFERECIDA (Codigo_Tur-CE, Codigo_Dis-CE).
Passo 6 – Atributos Multivalorados
Temos 2 atributos multivalorados no DER, mas apenas Telefone está anexado a um tipo de 
entidade. Atributos multivalorados anexados a relacionamentos com cardinalidade M:N devem 
ser adicionados à nova relação e à chave primária da nova relação. Já no caso de Telefone, 
que está anexado ao tipo de entidade, mapearemos conforme o passo 6, sendo preciso criar 
uma nova relação para cada atributo multivalorado – nesse caso, criaremos a relação Telefone_
Aluno, que receberá a chave primária da relação Aluno como chave estrangeira, além do atributo 
multivalorado Telefone. A combinação dos dois forma a chave primária dessa nova relação.
10) TELEFONE_ALUNO (Codigo_Alu-CE, Telefone).
Não será necessário realizar o passo 7 porque no DER não há relacionamentos ternários 
nem quaternários.
Assim, ao concluirmos todos os passos, teremos o esquema de relações do banco de 
dados que segue:
• PROFESSOR (Codigo, Nome, Titulo).
• CURSO (Codigo, Nome).
• ALUNO (Codigo, Nome, Sexo, Nascimento, Rua, Numero, Bairro, Cidade).
• DISCIPLINA (Codigo, Nome, Codigo_Prof-CE).
• TURMA (Codigo, Periodo_letivo, Inicio, Termino, Codigo_Cur-CE).
• MATRICULA (Codigo_Tur-CE, Codigo_Alu-CE, Data_Matricula, Data_Cancelamento, 
Motivo_Cancelamento).• OFERECIDA (Codigo_Tur-CE, Codigo_Dis-CE).
• TELEFONE_ALUNO (Codigo_Alu-CE, Telefone).
Para que serve o Mapeamento
O mapeamento é o projeto lógico do banco de dados. O projeto físico (Linguagem SQL) 
não pode de forma alguma ser realizado sem que o projeto lógico (mapeamento) tenha sido 
gerado a partir do projeto conceitual (DER). Em outras palavras, o mapeamento não pode ter 
nada a mais nem a menos do que estava previsto no DER e o projeto físico, da mesma forma, 
não pode ter nada a mais nem a menos do que consta no mapeamento.
© Banco de Dados118
Em resumo, cada relação do mapeamento deverá ser uma tabela do banco de dados 
(Linguagem SQL) e não pode haver diferenças entre elas, ou seja, atributos não podem ser 
acrescentados nem removidos e as chaves primárias e estrangeiras devem respeitar o que foi 
definido no mapeamento. De outra forma, para que fazer o mapeamento? Por que motivo 
o projetista realizaria um processo complexo como este para não ser usado? Portanto, o 
mapeamento depende do DER, pois é uma interpretação dele, e o Script em Linguagem SQL 
depende do mapeamento, sendo seu espelho. Qualquer coisa fora disso está incorreta.
13. QUESTÕES AUTOAVALIATIVAS
Confira, a seguir, as questões propostas para verificar o seu desempenho no estudo desta 
unidade:
1) Defina e exemplifique os seguintes conceitos
a) Chave candidata.
b) Chave estrangeira.
2) Quais são as principais regras de integridade de entidades?
3) Quais são as principais regras de integridade referencial?
4) Quais são os principais operadores pertinentes ao conjunto relacional?
5) Exemplifique os seguintes relacionamentos:
a) Relacionamento 1:M.
b) Relacionamento 1:1.
c) Relacionamento M:N.
6) A questão a seguir utilizou os dados de um banco de dados simplificado, apresentado pelas tabelas CLIENTE, 
PEDIDO e ITEM, dispostos na Figura 33. 
Figura 33 Tabelas CLIENTE, PEDIDO e ITEM.
Claretiano - Centro Universitário
119© U3 – Modelo de Dados Relacional
No modelo apresentado, a especificação de chave primária correta é:
a) atributo id_item na tabela Item.
b) atributo id_loja na tabela Pedido.
c) atributo id_pedido na tabela Item.
d) atributo nome na tabela Cliente.
e) Atributos id_pedido, id_item na tabela Item.
7) Pode-se afirmar que os relacionamentos entre as tabelas Cliente e Pedido e entre as tabelas Pedido e Item são, 
respectivamente: 
a) 1:1 e 1:N.
b) 1:N e 1:1.
c) 1:N e 1:N.
d) 1:N e N:N.
e) N:N e 1:N.
Gabarito 
Confira, a seguir, as respostas corretas para as questões autoavaliativas propostas:
6) e.
7) c.
14. CONSIDERAÇÕES 
Nesta unidade, você teve a oportunidade de conhecer o Modelo Relacional, ou seja, um 
Modelo de Dados Lógico para o ambiente escolar.
O aprendizado passo a passo do processo de mapeamento do esquema conceitual para o 
esquema relacional permitiu a compreensão de como iniciar a formulação e criação do banco 
de dados relacional.
As relações do banco de dados para uma escola, apresentadas na Unidade 2, foram utili-
zadas para exemplificar as tabelas e aplicar restrições de integridade. Nesta unidade, também 
foram apresentados alguns comandos básicos da linguagem SQL. A confecção de consultas mais 
completas e complexas exigirá o conhecimento de Álgebra Relacional (ver Apêndice 3) e o uso 
da linguagem SQL, que será discutida na próxima unidade.
Para que compreenda melhor os conceitos apresentados, sugerimos que você retorne a 
esta unidade após o estudo da Unidade 4. 
Bons estudos!
15. E-REFERÊNCIAS
ALVARENGA, J. P. Informática: Banco de Dados I. Disponível em :<http://pt.scribd.com/doc/34137068/9/RELACIONAL>. Acesso 
em: 23 out. 2012.
DFC-UFMS. Disponível em: <http://www.dct.ufms.br/~said/disciplinas/bd/bd.html>. Acesso em: 14 jan. 2008.
16. REFERÊNCIAS BIBLIOGRÁFICAS
ELMASRI, R.; NAVATHE, S.B. Sistemas de bancos de dados. São Paulo: Pearson (Addison Wesley), 2005.
© Banco de Dados120
KORTH, H.; SILBERCHATZ, A. Sistemas de bancos de dados. 3. ed. São Paulo: Makron Books, 1998.
PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995.
RAMAKRISHNAN, R. GEHRKE, J. Database management systems. 2. ed. Boston: McGraw-Hill, 2000.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. 7. ed. Rio de Janeiro: Campus, 2020.