APOSTILA - Fundamentos_Banco_Dados

Prévia do material em texto

Direitos: Esta obra foi disponibilizada sob uma Licença Creative Commons Atribuição Uso não-comercial 
3.0 Brasil. 
Direitos de distribuição e publicação: CAPES/MEC, conforme Parágrafo Único, do Artigo 5º, da 
Resolução CD/FNDE nº 24 de 04 de Junho de 2008. 
 
 
 
Universidade Federal de Juiz de Fora 
Reitor: Henrique Duque de Miranda Chaves Filho 
 
Instituto de Ciências Exatas 
Diretor: Rubens de Oliveira 
 
Departamento de Ciência da Computação 
Chefe: Guilherme Albuquerque Pinto 
 
Curso de Licenciatura em Computação 
Coordenação: Fernanda Claudia Alves Campos 
 
 
Organização 
Regina Maria Maciel Braga 
 
Comissão Editorial 
Eduardo Barrére 
Fernanda Claudia Alves Campos 
 
Revisão Gramatical 
Hortência Cezar Pinto 
 
Editoração Eletrônica 
Eduardo Barrére 
 
 
 
Braga, Regina M. M.. 
Fundamentos de Banco de Dados / Regina Braga – 2013. 
 66 f. : il. 
Material Didático — Curso de Licenciatura em Computação 
da Universidade Federal de Juiz de Fora, Juiz de Fora, 2012. 
 
1. Educação à Distância. 2. Banco de Dados. 3. MER 4. 
SQL. I. Título. 
 
 
 
 
 
Apresentação 
Oi pessoal! 
 
Meu nome é Regina Braga. Sou professora da Universidade Federal de Juiz 
de Fora (UFJF) desde 1997. Sou graduada em Matemática, bacharelado em 
informática (1991) pela UFJF, mestre em Engenharia de Sistemas e 
Computação, com ênfase em Banco de Dados (1995), e doutora em 
Engenharia de Sistemas e Computação, com ênfase em Engenharia de 
Software e Banco de dados, pela COPPE/UFRJ. Portanto, minhas áreas de 
interesse são Banco de Dados e Engenharia de Software. 
 
Nesta disciplina vocês conhecerão conceitos de modelagem e de bancos de 
dados. Os Bancos de Dados permitem o armazenamento dos dados da 
maioria dos sistemas de informação existentes no mercado, incluindo ai o 
Moodle que vocês utilizam tanto. 
 
Este material tem como objetivo orientá-lo no estudo da disciplina Banco de 
Dados, por meio de dicas, sugestões e exercícios, com destaque aos pontos 
mais importantes. Aqui você encontrará conceitos com os quais irão trabalhar 
ao longo do Curso. 
 
Os conceitos aqui apresentados devem ser bem assimilados, pois servirão 
de base para disciplinas mais avançadas da área, e para sua vida 
profissional. 
 
Sucesso e bom aprendizado!!! 
 
Profa. Regina Maria Maciel Braga. 
 
Iconografia 
Conheça os diversos ícones utilizados nos materiais didáticos desenvolvidos pelos 
professores e tutores do curso de Licenciatura em Computação – DCC/UFJF: 
 
 
Pesquise. 
 
Exercícios. 
 
 
 
 
 
 
 
 
Material complementar 
(texto, vídeo, etc.) 
disponível na Internet. 
 
Leitura Complementar. 
 
 
 
 
 
 
 
 
Comentário do Autor. 
 
Tome nota. 
 
 
 
 
 
 
 
 
Conclusão ou síntese 
de conteúdo. 
 
Fique atento. 
 
 
Sumário 
CAPÍTULO 1 - CONCEITOS BÁSICOS .............................................................................................................. 8 
1.1. O que é um banco de dados? ............................................................................................................ 8 
1.2 Uso e abrangência .............................................................................................................................. 9 
1.3 Processamento de Dados sem Banco de Dados .............................................................................. 10 
1.4 Sistema de Gerenciamento de Banco de Dados (SGBD) .................................................................. 12 
1.6 Instâncias e Esquemas ...................................................................................................................... 14 
1.7 Visões do Banco de Dados ................................................................................................................ 15 
1.8 - Independência de Dados ................................................................................................................ 16 
1.9 - Modelo de Dados ........................................................................................................................... 17 
1.9.1 - Modelo Relacional ................................................................................................................... 17 
1.9.2. Modelo de Redes ...................................................................................................................... 18 
1.9.3. Modelo Hierárquico ................................................................................................................. 18 
1.9.4. Modelo Orientado a Objetos .................................................................................................... 19 
1.9.5. Modelo Objeto Relacional ........................................................................................................ 19 
1.10 - Linguagem de Definição de Dados ............................................................................................... 20 
1.11 - Linguagem de Manipulação de Dados ......................................................................................... 20 
1.12 - Principais Componentes de um SGBD .......................................................................................... 21 
1.12 - Arquitetura de um SGBD .............................................................................................................. 22 
1.13 - Usuários de um SGBD ................................................................................................................... 23 
CAPÍTULO 2 - MODELAGEM DE DADOS ..................................................................................................... 25 
2.1. Projeto de um Banco de Dados ....................................................................................................... 25 
2.2. Modelo Entidade Relacionamento (MER) ....................................................................................... 26 
2.3. MER - Entidades .............................................................................................................................. 26 
2.3.1. Atributos ................................................................................................................................... 27 
2.3.2. Tipos de atributos ..................................................................................................................... 28 
2.4. MER - Relacionamentos .................................................................................................................. 30 
2.4.1. Autorrelacionamento ............................................................................................................... 32 
 
2.4.2. Cardinalidade de Relacionamentos .......................................................................................... 33 
2.4.3. Relacionamentos enésimos ...................................................................................................... 37 
2.5. MER - Generalização/Especialização ............................................................................................... 37 
2.5.1. Tipos de Generalização/Especialização ................................................................................... 39 
2.6. Entidade Associativa ........................................................................................................................ 40 
2.7. Entidade Fraca ................................................................................................................................. 41 
2.8. Restrições ........................................................................................................................................ 42 
2.9. Técnicas de Projeto ......................................................................................................................... 43 
CAPÍTULO 3 - MODELO RELACIONAL.......................................................................................................... 493.1 Introdução ........................................................................................................................................ 49 
3.2 Características das Tabelas ............................................................................................................... 49 
3.3 Chaves .............................................................................................................................................. 50 
3.4 Esquema de um Banco Relacional .................................................................................................... 51 
3.5 Transformação do MER para o Modelo Relacional .......................................................................... 52 
3.6 Normalização .................................................................................................................................... 59 
3.6.1 Dependências Funcionais .......................................................................................................... 59 
3.6.2 Exemplo de aplicação de técnicas de normalização ................................................................. 60 
3.6.3 Primeira Fórmula Normal (1FN) ................................................................................................ 62 
3.6.4 Segunda Fórmula Normal (2FN) ................................................................................................ 62 
3.6.5 Terceira Fórmula Normal (2FN) ................................................................................................. 63 
CAPÍTULO 4 - LINGUAGEM DE CONSULTA - SQL ........................................................................................ 66 
4.1 Introdução ........................................................................................................................................ 66 
4.2 Definição do Esquema do Banco de Dados em SQL (DDL - Data Definition Language) ................... 67 
4.2.1 Criação e Deleção de Tabelas .................................................................................................... 67 
4.2.2 Declaração de Chaves Primária ................................................................................................. 68 
4.2.3 Chave Estrangeira ...................................................................................................................... 69 
4.2.4 Restrições em Atributos de uma tabela .................................................................................... 69 
4.2.4 Restrições de Integridade em SQL............................................................................................. 70 
 
4.3. Exemplo Prático de Criação de Banco de Dados ............................................................................. 72 
4.4. Resumo dos Principais Comandos da DDL ...................................................................................... 74 
4.4.1. Criação de tabelas e índices ..................................................................................................... 74 
4.4.2. Deleção de tabelas e índices .................................................................................................... 75 
4.4.3. Modificação de tabelas ............................................................................................................ 76 
4.5 Atualização de Informações no Banco de Dados (DML - Data Manipulation Language) ................ 76 
4.5.1 Inserção de Dados ..................................................................................................................... 76 
4.5.2 Deleção de Dados ...................................................................................................................... 77 
4.5.3 Exemplos de Inserção e Deleção de Dados ............................................................................... 77 
4.5.4 Atualização de Dados ................................................................................................................ 78 
4.6 Consulta a Informações no Banco de Dados (DML - Data Manipulation Language) ....................... 79 
4.6.1. Consultas Simples ..................................................................................................................... 79 
4.6.2. Consultas com operadores lógicos ........................................................................................... 80 
4.6.3. Ordenação de Consultas .......................................................................................................... 82 
4.6.4. Consultas em mais de uma Tabela ........................................................................................... 82 
4.6.5. Subconsultas ............................................................................................................................. 83 
4.6.6. União, Interseção e Diferença .................................................................................................. 85 
4.6.7. Agregações ............................................................................................................................... 85 
4.6.8. Eliminação de Duplicatas .......................................................................................................... 86 
4.6.9. Agrupamentos .......................................................................................................................... 86 
4.6.10. Inserção a partir de consultas ................................................................................................ 87 
4.8 Visões ............................................................................................................................................... 87 
Referências Bibliográficas .......................................................................................................................... 93 
 
EADDCC030 – Fundamentos de Banco de Dados 
8 
 
 
CAPÍTULO 1 - CONCEITOS BÁSICOS 
 
 
Neste capítulo iremos estudar conceitos importantes 
relacionados a banco de dados e que serão importantes 
para o entendimento dos demais capítulos! 
 
 
1.1. O que é um banco de dados? 
Um banco de dados ou base de dados nada mais é do que uma coleção de 
dados inter-relacionados, com algum significado inerente, isto é, informações de 
interesse de uma ou mais organizações. Ele é projetado, construído e preenchido com 
dados para um propósito específico de uma ou mais organizações e destinado à 
utilização por grupo de usuários, diretamente ou por meio de aplicações pré-
concebidas. 
 
Podemos também ver um banco de dados como um conjunto de arquivos 
estruturados de forma a facilitar o acesso aos conjuntos de dados armazenados. Esses 
arquivos encontram-se, de alguma forma, relacionados. Por exemplo, em um banco de 
dados escolar podemos encontrar alguns arquivos, tais como: dados dos alunos 
(nome, endereço, CPF, sexo), dos cursos propriamente ditos (título, ano de 
lançamento, formato, etc.) e dados sobre as disciplinas (nome, ementa, código, etc.). 
Para obter informações sobre uma dada disciplina e os alunos que participam dela, 
como nome da disciplina e nome dos alunos, será necessário consultar os dois 
EADDCC030 – Fundamentos de Banco de Dados 
9 
 
primeiros arquivos, que devem estar relacionados. Desta forma, o relacionamento entre 
os arquivos é uma das condições para que tenhamos um banco de dados, pois 
somente através destes relacionamentos, teremos a informação propriamente dita. 
No entanto, somente com os arquivos relacionados fica ainda difícil de se 
acessar estas informações. Com o crescimento do volume e dos tipos de dados nas 
organizações, e preciso utilizar softwares especiais para gerenciar os dados, os 
chamados SGBDs (Sistemas Gerenciadores de Banco de Dados). 
 
Um SGBD é um software de caráter geral para a manipulação eficiente de 
grandes coleções de informações estruturadas e armazenadas de uma forma 
consistente e integrada. Tais sistemasincluem módulos para consulta, atualização e as 
interfaces entre o sistema e o usuário. Podemos afirmar, então, que um SGBD e 
constituído por um conjunto de dados associados a um conjunto de programas para 
acesso a eles [SILBERSCHATZ, 2006]. 
1.2 Uso e abrangência 
Nas atividades diárias necessitamos de aplicações que envolvem bancos de 
dados: 
 Controle Escolar: Precisamos armazenar informações sobre os alunos, os cursos 
da escola, as turmas abertas, a alocação dos alunos nas turmas, professores, 
alocação dos professores nas turmas, etc. 
 Bancos: o sistema financeiro necessita de armazenar as informações sobre seus 
clientes, contas, transações financeiras (débitos e créditos nas contas), entre 
outras. 
EADDCC030 – Fundamentos de Banco de Dados 
10 
 
 Reservas em hotéis ou companhias aéreas: Este tipo de sistema precisa 
armazenar informações sobre os assentos disponíveis no avião, os que já foram 
vendidos, os reservados, os dados dos clientes, as datas de embarque, etc. Os 
sistemas de reservas em hotéis precisam armazenar os dados dos hóspedes, as 
datas de hospedagem, os consumos no frigobar, entre outros. 
 Catálogo informatizado em bibliotecas: Precisamos armazenar as informações 
sobre os livros, os exemplares que a biblioteca dispõe, os empréstimos, os atrasos, 
as multas, a localização dos exemplares, etc. 
 Compras em supermercados: Um sistema para gerenciar compras de 
supermercado precisa armazenar os dados dos produtos, preço de compra e de 
venda, gerenciar o estoque dos produtos, dentre outras necessidades. 
1.3 Processamento de Dados sem Banco de Dados 
O que aconteceria se não tivéssemos um Banco de Dados para o 
armazenamento dos dados das aplicações? Os dados poderiam ficar armazenados em 
vários conjuntos de arquivos, um conjunto pra cada aplicação, sem ligação entre si, ou 
seja, os dados de uma aplicação não estariam integrados com os dados de outra 
aplicação, poderia haver redundância, dados inconsistentes, ou seja, tem um valor em 
um arquivo e pode ter valor diferente em outro. Ou seja, os dados não estariam 
integrados. O que teríamos seria algo como na figura abaixo. 
 
O que pode acontecer???? [SILBERSCHATZ, 2006] 
 Redundância e inconsistência de dados. Considerando que diferentes 
programadores tem a possibilidade de criar arquivos com estruturas diferentes e 
aplicações para acessa-los, a possibilidade de se redundar dados por esses 
arquivos e muito grande. Alem disso, em função dessa redundância, poderão 
ocorrer as inconsistências, pois os dados podem ser atualizados em alguns 
arquivos e em outros não. Imaginem se um aluno resolve trancar matrícula em uma 
Arquivos Alunos Arquivos Professores Arquivos Turmas 
Aplicação Controle 
Alunos 
Aplicação 
Professores 
Aplicação Turmas 
EADDCC030 – Fundamentos de Banco de Dados 
11 
 
turma e sair do colégio. Quais arquivos deveriam ser atualizados?? No mínimo os 
arquivos relacionados ao controle de alunos e os arquivos relacionados ao controle 
de turmas. E se forem atualizados somente os arquivos relacionados ao controle de 
turmas?? DESATUALIZAÇÃO. 
 Dificuldade no acesso aos dados. Diferentemente dos SGBDs, os sistemas de 
arquivos não possuem um ambiente para recuperação dos dados armazenados. 
Com isso, para cada informação a ser gerada, é necessário construir uma aplicação 
ou então teremos que "escovar bits" para acessar os dados. 
 Isolamento de dados. Considerando a diversidade de formatos existentes dos 
arquivos e, conseqüentemente, dos dados armazenados neles, torna-se uma tarefa 
difícil a construção de aplicações para a recuperação desses dados pois cada um 
terá um formato. 
 Problemas de atomicidade. Em banco de dados, este conceito quer dizer que algo é 
indivisível, ou é totalmente feito ou é totalmente desfeito. Um exemplo clássico de 
atomicidade seria uma transferência de dinheiro entre duas contas. Se desejarmos 
transferir, por exemplo, R$ 100,00 da conta do professor " João" para a conta da 
sua filha "Maria", ou os R$ 100,00 será transferido integralmente ou não ocorrerá a 
transferência. Não pode acontecer do dinheiro sair da conta do "João" e não entrar 
na conta da "Maria"! 
 Anomalias de acesso concorrente. Considerando o acesso simultâneo aos arquivos, 
por diferentes aplicações ou por diferentes usuários de uma mesma aplicação, 
pode-se gerar inconsistências nesses arquivos, devido a esses acessos. Tomemos 
como exemplo que uma conta conjunta A de fundo de formatura- com saldo igual a 
R$ 1000,00 - foi acessada de forma simultânea pelos alunos Carolina e Pedro. 
Carolina sacou R$100,00 para pagar os convites e Pedro, R$200,00 para comprar 
refrigerantes. Pergunta-se: qual o saldo da conta após os saques? Se ambos leram 
o valor do saldo igual a R$1000,00, podemos ter como possíveis valores : 
R$900,00, R$800,00, levando-se em conta qual valor foi escrito por ultimo. Nesse 
caso, nenhum dos dois valores seria valido. O correto seria ter um saldo igual a 
R$700,00 e o banco de dados garante isso, mas arquivos isolados podem não 
garantir. 
 Problemas de segurança. Nem todos os usuários possuem perfil para acessar a 
todos os dados disponíveis em um arquivo. Tomemos como exemplo um arquivo de 
EADDCC030 – Fundamentos de Banco de Dados 
12 
 
professores, que possui, entre outros dados, o valor do salário do professor. 
Embora tenhamos a curiosidade de saber o salário dos nossos colegas, 
principalmente do nosso chefe, não é politicamente correto que desrespeitemos seu 
direito a privacidade. No entanto, não é possível definir, para um arquivo, que 
algumas informações poderão ser visíveis por um usuário e por outros não, o que 
gera vulnerabilidade nesses sistemas; 
 Problemas de integridade. Imaginem o seguinte problema, estamos cadastrando 
todos os alunos de uma dada turma e, alguns alunos não tem CPF próprio e usam o 
CPF da mãe. Imaginem agora que temos dois alunos gêmeos e eles vão ser 
cadastrados usando o mesmo CPF e estamos utilizando o CPF para identificação 
dos alunos. O que teríamos neste caso: INCONSISTÊNCIA, uma vez que dois 
alunos tem o mesmo CPF. Em um sistema de arquivos, isso poderia passar 
desapercebido mas em um banco de dados, existe o controle de integridade de 
chave primária que não deixa isso acontecer. No entanto, não se preocupem por 
enquanto. Depois vamos ver isso em detalhes! 
1.4 Sistema de Gerenciamento de Banco de Dados (SGBD) 
Um Sistema de Gerenciamento de Banco de Dados (SGBD) é um conjunto de 
software para gerenciar um banco de dados. Veja na figura a seguir. 
 
EADDCC030 – Fundamentos de Banco de Dados 
13 
 
O Banco de Dados propriamente dito diz respeito aos dados que serão 
armazenados nos arquivos relacionados ao SGBD e também ao esquema que será 
montado pelo SGBD para armazenar estes dados, o chamado esquema de dados, que 
veremos mais adiante. 
Um SGBD provê armazenamento e acesso multiusuário eficiente a uma grande 
quantidade de dados armazenados, além de garantir a integridade e segurança dos 
dados, ou seja, tudo que não se tinha utilizando conjuntos de arquivos separados! 
 
• Observe na figura acima, que o SGBD aparece como uma parte pequena do 
esquema apresentado. No entanto, como poderemos mais a frente, na 
verdade um SGBD é um sistema complexo, que envolve vários módulos!!!! 
 
• Veja também que o SGBD faz a ponte das aplicações com os arquivos da 
base de dados, ou seja, as aplicações não acessam a base de dados 
diretamente. O acesso é sempre pelo SGBD. 
 
A partir das aplicações, o processamento de dados com uso de SGBD fica 
simplificado, pois os dados são integrados no banco e o SGBD controla qualquer 
problema de inconsistência e redundância, ficando transparente para o usuário. 
 
Aplicação Controle 
Turmas 
Aplicação Notas Aplicação Professores 
Dados integrados 
da escola 
SGBD 
Esquema da 
base 
Base de 
Dados 
S 
G
B
D 
Aplicação 
Aplicação 
AplicaçãoEADDCC030 – Fundamentos de Banco de Dados 
14 
 
 
 
1.6 Instâncias e Esquemas 
Um conceito importante em Banco de Dados é o de Instância X Esquema. Uma 
Instância do Banco de Dados é o conjunto de informações contidas nos arquivos do 
Banco de Dados em um dado momento. 
Já o Esquema do banco de dados é o projeto geral, ou seja, é a descrição de 
como os dados serão armazenados no banco de dados. Veja a figura a seguir. Nela 
fica mais claro a diferença entre instância e esquema. 
Estado Consistente do Banco de Dados: estado do BD satisfazendo aos critérios 
de correção definidos no esquema. O SGBD garante que os dados ficarão organizados 
e relacionados de acordo com as definições contidas no esquema definido. 
EADDCC030 – Fundamentos de Banco de Dados 
15 
 
 
1.7 Visões do Banco de Dados 
Considerando que o nível de conhecimento dos usuários de bancos de dados é 
muito variável, oscilando entre aqueles que conhecem muito e outros que são leigos, 
os Sistemas de Bancos de Dados devem prover mecanismos que administrem essa 
complexidade, simplificando as interações dos usuários com o sistema. Para isso, três 
níveis de abstração são considerados: 
 
 
 Nível físico (interno) 
mais baixo nível de abstração; como os dados estão de fato armazenados, estrutura de 
armazenamento e recuperação, incluindo índices. 
Nível lógico (conceitual) 
nível médio de abstração; visão da comunidade de usuários; estruturas, 
operações e restrições do modelo que se está usando. 
 Nível de visão (externo) 
mais alto nível de abstração; visão de cada usuário; descreve 
apenas parte do banco de dados. 
Esquema 
Instância 
EADDCC030 – Fundamentos de Banco de Dados 
16 
 
Para que possamos entender melhor estes três níveis de abstração, vamos 
considerar um exemplo bem prático, usando a base de dados para registro escolar 
apresentada acima. O BD pode ter diversos destes tipos de informação (registro), 
incluindo Aluno, com os campos nome, número, turma, curso_hab: 
 No nível físico um registro de Aluno pode ser descrito como um bloco consecutivo 
de memória (por exemplo, palavra ou bytes). O compilador esconde este nível de 
detalhes dos programadores. 
 No nível lógico, cada registro é descrito por um tipo definido, como acima, assim 
como é definida a inter-relação entre estes tipos de registros. 
 No nível de visão, os usuários do computador vêem um conjunto de programas de 
aplicação que escondem os detalhes dos tipos de dados. Ex: uma aplicação que só 
lida com os dados cadastrais dos alunos não saberá sequer que o banco de dados 
tem informações tb. sobre cursos e turmas! 
 
1.8 - Independência de Dados 
É a capacidade de modificar a definição dos esquemas em determinado nível, 
sem afetar o esquema do nível superior. 
 Independência de dados física: modifica o esquema físico sem que, com isso, 
qualquer programa aplicativo precise ser reescrito (ocasionais para aumento de 
desempenho). Como exemplo prático seria modificarmos a estrutura de dados 
utilizada para o armazenamento dos dados sem afetar os demais níveis. O que 
vocês acham disso? É claro que não vai afetar em nada os níveis acima pois a 
estrutura lógica ficará a mesma! 
 Independência de dados lógica: modifica o esquema lógico sem que, com isso, 
qualquer programa aplicativo precise ser reescrito (sempre que uma estrutura lógica 
do BD é alterada). Um exemplo concreto seria: Vamos considerar os alunos do 
curso. Vamos supor que além das informações como nome, numero, turma e curso, 
teríamos também que agora armazenar os endereço dos alunos, ou seja, teríamos 
que modificar a tabela alunos para incluir este novo campo! Qual o impacto disso! 
Com certeza um pouco maior que a mudança no nível físico, pois pelo menos na 
aplicação onde é feito o cadastramento dos alunos, teríamos que fazer mudanças!!! 
EADDCC030 – Fundamentos de Banco de Dados 
17 
 
1.9 - Modelo de Dados 
Um modelo de Dados descreve a estrutura conceitual dos dados armazenados no 
banco de dados, detalhando a organização dos dados internamente no banco. 
Suponham que tivéssemos que criar um banco de dados para um sistema 
escolar. O modelo de dados a ser criado deverá descrever o que este banco de dados 
deve armazenar: 
 alunos (o que precisamos armazenar a respeito dos alunos: matricula, nome, 
endereço, etc), 
 notas (turma, matricula do aluno, nota)...... 
A forma como estes dados são organizados no banco também varia. Desta forma, 
um banco de dados pode ser classificado quanto ao seu modelo nos seguintes tipos: 
relacional, objeto-relacional, orientado a objetos, em redes e hierárquico. 
1.9.1 - Modelo Relacional 
O modelo relacional é o modelo mais utilizado atualmente pelos SGBDs. Tem 
como características marcantes a simplicidade e uniformidade do modelo, o formalismo 
matemático e o suo de uma linguagem padronizada para consulta (SQL - Structured 
Query Language). 
O modelo relacional usa um conjunto de tabelas para representar tanto os dados 
quanto a relação entre eles. As ligações entre as tabelas e feita por meio dos valores 
dos atributos ou colunas, conforme descrito posteriormente. 
Cada tabela possui múltiplas colunas, conforme o exemplo abaixo. 
nome rua cidade Nro-conta 
Mário Av. São Carlos SP 1234 
Rui Rua XV São Carlos 1333 
Rui Rua XV São Carlos 5512 
Silvia Av. Dom Pedro Itu 5512 
Silvia Av. Dom Pedro Itu 7556 
 
EADDCC030 – Fundamentos de Banco de Dados 
18 
 
1.9.2. Modelo de Redes 
Um banco de dados em rede consiste em uma coleção de registros que são 
concatenados uns aos outros por meio de ligações. Este modelo de dados não é mais 
utilizado pelos bancos de dados atuais, sendo mais ligado a forma de se acessar o 
dado fisicamente, ao contrário do modelo relacional, que permite uma visão mais lógica 
do banco de dados1. Estes registros são organizados no BD por um conjunto arbitrário 
de grafos como no exemplo a seguir. 
 
 
1.9.3. Modelo Hierárquico 
Um banco de dados hierárquico é similar ao modelo em rede uma vez que os 
dados e suas relações são representadas por registros e links (ligações). A principal 
diferença é que no modelo hierárquico os registros estão organizados em árvores ao 
invés de gráficos arbitrários como é o caso do modelo de redes. 
Este modelo também não é mais utilizado como modelo dos banco de dados 
atuais apesar de se ter como grande vantagem o desempenho das consultas por conta 
da estrutura em árvore 2. 
 
1
 Quer pesquisar mais sobre isso: veja nos livros clássicos de BD ou na web!! 
2
 Você conhece a estrutura de dados em árvore? Muito importante em banco de dados no nível físico!!!! 
1234 55,00 
1333
 600,00 
5512
 350,00 
7556
 3.000,00 
Mário Av. S.Carlos S.P. 
Rui Rua XV S.Carlos 
Silvia Av.D.Pedro Itu 
EADDCC030 – Fundamentos de Banco de Dados 
19 
 
 
 
1.9.4. Modelo Orientado a Objetos 
O modelo orientado a objetos surgiu para cobrir uma lacuna no armazenamento 
de dados providos a partir das linguagens de programação OO. 
Considerando que nas aplicações trabalhamos a partir de objetos (como em 
Java), porque armazenar os dados dos objetos em tabelas e não em objetos? Esta foi 
a idéia que norteou o desenvolvimento de bancos de dados orientados a objetos, onde 
conceitos como classes, herança, métodos, associações entre classes foram 
incorporados nos banco de dados. No entanto, apesar de toda a flexibilidade do 
modelo, este tipo de banco de dados não foi bem aceito no mercado. 
 
Pense na frente: pesquise em livros e na web para qual 
tipo de aplicação os bancos de dados OO seriam mais 
adequados!!! 
 
 
1.9.5. Modelo Objeto Relacional 
O modelo objeto-relacional, também conhecido como relacional estendido, é um 
modelo intermediário entre o relacional e o orientado a objetos. Na verdade, os bancos 
de dados que se enquadram nesse modelo caracterizam-se por usar a estruturabásica 
1234 55,00 
1333 600,00 
5512 350,00 
7556 3.000,00 
 
7556 3.000,00 
Mário Av. S.Carlos S.P. 
Rui Rua XV S.Carlos 
Silvia Av.D.Pedro Itu 
EADDCC030 – Fundamentos de Banco de Dados 
20 
 
do modelo relacional, incorporando algumas características dos bancos de dados 
orientados a objetos. Características estas que incluem: herança de tipos e tabelas e 
definição de novos tipos complexos, que seriam semelhantes ao conceito de classes. 
Lembrem-se da disciplina de Modelagem!!!! 
Atualmente, os grandes SGBDs existentes no mercado adotam o modelo objeto 
relacional. No entanto, o uso da parte objeto-relacional é muito restrita e algumas vezes 
com problemas de desempenho, sendo o forte mesmo a parte que adota o modelo 
relacional. Isso se dá por conta destes SGBDs criarem uma camada de objetos em 
cima do modelo relacional, o que acaba afetando seu desempenho! 
 
1.10 - Linguagem de Definição de Dados 
Para expressar formalmente o esquema de dados em um banco de dados, ou 
seja, criação de tabelas, índices, etc., utilizamos a Linguagem de Definição de Dados 
(LDL) (Data-Definition Language (DDL)). Alguns exemplos de comandos LDL: CREATE 
TABLE (para criar um tabela); ALTER TABLE (alteração de tabelas); DROP TABLE 
(apagar uma tabela); CREATE INDEX (criação de índices); ALTER INDEX (alteração 
de índices) ; DROP INDEX (apagar um índice); 
O resultado da compilação dos parâmetros LDL é armazenado em tabelas que 
constituem o dicionário de dados ou diretório de dados. Relembrando, dicionário de 
dados: é na verdade um arquivo de metadados (dados a respeito de dados) que fica 
armazenado no SGBD. Esse diretório é consultado para verificar a estrutura do 
esquema de dados sempre antes que um dado real seja modificado. 
1.11 - Linguagem de Manipulação de Dados 
A Linguagem de Manipulação de Dados (LMD) (Data Manipulation Language 
(DML)) é a linguagem que permite a manipulação de dados. Podemos realizar as 
seguintes operações a partir da LMD: 
 recuperação das informações armazenadas no BD 
 inserção de novas informações no BD 
 remoção de informações do BD 
 modificação das informações do BD 
EADDCC030 – Fundamentos de Banco de Dados 
21 
 
A DML viabiliza o acesso (manipulação) dos dados de forma compatível ao 
modelo de dados apropriado. Tanto a LMD quanto a LDD fazem parte da linguagem 
SQL (Structured Query Language), que veremos mais adiante. 
 
1.12 - Principais Componentes de um SGBD 
O sistema de banco de dados é dividido em módulos específicos, de modo a 
atender a todas as suas funções, algumas delas fornecidas pelo sistema operacional. 
Esses módulos podem ser organizados em dois grandes grupos: o de processamentos 
de consultas e o de administração do armazenamento de dados. 
 
 Processamento de Consultas: Composto principalmente pelo otimizador e 
processador de consultas. Tem como principal objetivo receber uma requisição 
do usuário especificada em SQL e melhorar esta requisição em termos de 
desempenho (fazer com que a consulta seja executada o menor tempo possível) 
e acessar o e disponibilizar s dados requisitados pelo usuário; 
 Administração do armazenamento de dados: é o responsável por garantir o 
estado consistente do banco de dados, não permitindo acesso não autorizado 
aos dados e nem o acesso simultâneo aos dados. Além disso, gerencia a 
alocação de espaço em disco e as estruturas de dados utilizadas para 
armazenar as informações. Outro componente importante é o gerenciamento 
das trocas de dados entre o disco e a memória, o que é feito pelo gerente de 
memória. 
EADDCC030 – Fundamentos de Banco de Dados 
22 
 
1.12 - Arquitetura de um SGBD 
A arquitetura de um SGBD diz respeito a forma como os componentes do mesmo 
são organizados considerando o hardware e o sistema operacional onde o SGBD será 
executado. Atualmente, os tipos mais utilizados são: 
 Arquitetura Centralizada: O SGBD é executado e armazenado em uma máquina, 
podendo ser consultado através de outros computadores com acesso a este 
computador denominado servidor de SGBD. O acesso pode ser multiusuário, mas 
o SGBD está centralizado é uma máquina (o servidor). 
 
 Arquitetura Distribuída: O SGBD é dividido em múltiplas máquinas e/ou sites, 
sendo que o processamento de qualquer requisição é gerenciada de forma a 
acessar as "partes" onde estão armazenadas as informações relevantes. 
 
 WIS - (Sistemas Integrados de Informação na Web): são sistemas para tratar 
dados extraídos de sites da Web. Estes sistemas funcionam como um grande 
banco de dados. Os WIS devem lidar com um grande número de sites da web, 
considerando que estes sites tem autonomia (podem sair do ar e voltar a qualquer 
momento sem aviso prévio) e que os dados constantes destes sites podem não ter 
estrutura nenhuma (bem diferente dos SGBDs convencionais). 
EADDCC030 – Fundamentos de Banco de Dados 
23 
 
1.13 - Usuários de um SGBD 
Basicamente são quatro os tipos de usuários de um SGBD: 
 Usuários leigos: interagem com o banco de dados por meio das interfaces de 
aplicativos que acessam o banco de dados; 
 Usuários avançados: interagem com os bancos de dados por meio de interfaces 
específicas disponíveis no SGBD. Escrevem consultas SQL e submetem a 
execução sem a necessidade de escrever uma aplicação para esse fim; 
 Programadores aplicações: usuários com formação em computação e que se 
propõem a construir aplicações, por meio de ferramentas (compiladores) 
destinadas para esse fim. Utilizando essas ferramentas, constroem interfaces para 
as aplicações, incluindo formulários e relatórios que acessam o bancos de dados; 
 Administrador de Banco de Dados (DBA - DataBase Administrator): usuário 
mais especializado. Cabe a ele a administração dessas bases, definição da melhor 
estrutura de armazenamento desses dados, definição de aspectos de segurança, 
programação de copias de segurança (backup’s), dentre outros. 
 
 
Exercícios de Fixação: 
 
1) Defina as principais categorias de modelos de dados? 
 
2) Dê uma vantagem e uma desvantagem de se usar um 
SGBD em um sistema. 
 
 
 
Exercícios Propostos: 
 
1) Cite quatro sistemas que você tenha usado recentemente e 
que provavelmente tenha um SGBD para realizar a 
persistência dos dados. 
2) Detalhe quais são as principais funções de um administrador 
de um banco de dados 
3) Descreva pelos menos três tabelas que você acredita que 
precisariam ser usadas para armazenar informações em um 
sistema de redes sociais como o Facebook. 
4) Liste os primeiros passos que você seguiria para a criação de 
um banco de dados para uma empresa. 
 
 
EADDCC030 – Fundamentos de Banco de Dados 
24 
 
Respostas dos Exercícios de Fixação: 
1. Defina as principais categorias de modelos de dados? 
As principais categorias são: 
 Modelo físico para representar o esquema interno. 
 Modelo conceitual para representar os esquemas conceitual e externo, é mais próximo dos 
usuários finais, (exemplo MER) 
 Modelo lógico é um nível intermediário, possui conceitos que podem ser entendidos por usuários 
finais, mas que não são tão distantes da forma como os dados são armazenados. (exemplos 
Modelo em rede, hierárquico, orientado a objeto, relacional, etc.) 
 
2. Dê uma vantagem e uma desvantagem de se usar um SGBD em um sistema. 
Exemplos de Vantagem: 
Persistência 
 Armazenamento dos objetos do banco de dados, que vão sofrendo modificações com o tempo 
Recuperação de dados: 
 Garantir que falhas durante o processamento de transações não sejam propagadas aos objetos 
persistentes. 
Controle de concorrência: 
 Garantir que transações concorrentes serão executadas sem conflitos em seus procedimentos. 
Gerência de memória e de arquivos: 
 Gerenciar a alocação de espaço no armazenamento em disco e as estruturas de dados usadas 
para representar estas informações armazenadas em disco, 
 Responsável pela intermediação de dados do disco para a memória principale pela decisão de 
quais dados colocar em memória cache 
Restrições de Integridade 
 Mantém o BD em estado consistente, satisfazendo algumas condições, chamadas de restrições 
de integridade. 
Segurança 
 Implementa mecanismos de segurança de acesso para consulta, remoção, atualização e 
inserção de dados 
Facilidades para: 
 Carregar e descarregar o banco de dados ou parte deles 
 Fazer cópia de segurança = backup 
 Restaurar o banco de dados a partir do backup 
 
Exemplos de Desvantagem: 
O uso de SGBDs em aplicativos que não necessitam de armazenamento persistente dos dados em disco 
não é vantajoso, pois tornará a aplicação mais lenta e provavelmente mais complexa, gastará recursos 
da máquina para processamento do SGBD sem necessidade, etc.. 
 
 
 
 
 
EADDCC030 – Fundamentos de Banco de Dados 
25 
 
 
CAPÍTULO 2 - MODELAGEM DE DADOS 
 
Neste capitulo estudaremos conceitos de modelagem 
conceitual de dados. Um modelo conceitual modela os 
requisitos de negocio, segundo a visão do usuário, ou 
seja, independentemente de tecnologia. Nosso foco será o 
Modelo de Entidade e Relacionamentos (ER). 
 
2.1. Projeto de um Banco de Dados 
O processo de projetar um banco de dados inclui três fases distintas: 
1. Caracterização de todos os dados necessários na perspectiva do usuário, tendo 
como resultado a especificação das necessidades do usuário (levantamento de 
requisitos). 
2. Transcrição das necessidades especificadas para um esquema conceitual de BD. 
Resultado: projeto-conceitual que será especificado através de um modelo 
conceitual. 
3. Transporte do modelo de dados abstrato para sua implementação: 
projeto lógico: o esquema conceitual de alto nível mapeado para modelo de 
implementação de dados do SGBD que será usado. 
projeto físico: dependente dos recursos do SGBD, cuida das formas de organização 
de arquivos e estruturas internas de armazenamento. 
Neste capítulo iremos focar no projeto conceitual, através da especificação de um 
modelo conceitual que é utilizado para descrição de dados no nível conceitual, de 
forma independente do SGBD escolhido. 
O objetivo é registrar as estruturas dos dados que irão aparecer no banco de 
dados. Os modelos conceituais proporcionam grande capacidade de estruturação e 
permitem a especificação de restrições nos dados de forma explícita. Exemplos: 
 Modelo Entidade-Relacionamento (M.E.R.) 
 Modelo de Semântica de dados 
 Modelos Orientados a Objetos (OO) 
Aqui iremos utilizar o Modelo Entidade-Relacionamento! 
EADDCC030 – Fundamentos de Banco de Dados 
26 
 
2.2. Modelo Entidade Relacionamento (MER) 
Também conhecido como Diagrama Entidade Relacionamento. O modelo foi 
criado em 1976 por Peter Chen e é baseado na percepção de que o mundo real é 
formado por um conjunto de objetos chamados entidades e pelo conjunto dos 
relacionamentos entre estes objetos. É o padrão para modelagem conceitual. Ao longo 
dos anos sofreu diversas extensões, similares a conceitos adotados na orientação a 
objetos. Iremos estudar em detalhes cada um destes conceitos. 
DICA: O MER é um importante elemento de modelagem em banco de 
dados. Se especificarmos um bom MER, todas as demais etapas da 
modelagem serão também bem especificadas, sem necessidades de 
ajustes nas demais etapas. No entanto, se especificarmos um MER 
ruim, teremos que fazer diversos ajustes nas etapas posteriores. 
Veremos isso nos próximos capítulos!! 
 
O objetivo principal do MER é definir um modelo de alto nível independente de 
implementação. Para isso, o modelo é formado por três elementos básicos: 
 entidades, 
 relacionamentos e 
 atributos. 
O Modelo Entidade-Relacionamento (MER) utiliza uma notação gráfica para 
representação dos modelos. 
 
 
 
2.3. MER - Entidades 
Entidades são conjuntos de objetos da realidade modelada sobre os quais se 
deseja manter informações no Banco de Dados. Um conjunto de entidades pode 
representar objetos concretos (pessoas, automóveis) da realidade quanto objetos 
abstratos (departamentos, disciplinas). Para se referir a uma entidade em particular é 
também usado o termo instância (ou ocorrência, ou objeto). Exemplos: 
 existência concreta 
Conjunto de Professores 
Conjunto de Alunos 
AlunoAluno TurmaTurmamatriculamatricula
(1,N)(1,N) (1,N)(1,N)
EADDCC030 – Fundamentos de Banco de Dados 
27 
 
 existência conceitual 
Conjunto de Disciplinas 
Conjunto de Turmas 
 notação gráfica de entidade 
 
 
 
 
Uma Entidade é formada por um conjunto de instâncias/objetos de mesmo tipo 
que compartilham as mesmas propriedades: os atributos. O conceito de Entidade é 
similar ao conceito de classe na orientação a objetos. 
 
 
 
 
 
2.3.1. Atributos 
Atributos são as propriedades descritivas de cada instância/objeto de uma 
entidade. 
A designação de um atributo para uma entidade expressa que o BD mantém 
informações similares de cada uma das instâncias da entidade; entretanto, cada 
instância pode ter seu próprio valor em cada atributo. 
 
 
 
Aluno
Disciplina
Professor
Aluno
cpf nome
endereço sexo
Entidade Aluno
Atributos
Disciplina
Código Nome
AABDDCC090
Banco de DadosDCC077
NomeCódigo
AABDDCC090
Banco de DadosDCC077
NomeCódigo
EADDCC030 – Fundamentos de Banco de Dados 
28 
 
Atributos da entidade Disciplina: código e nome. Para cada atributo, existe um 
conjunto de valores possíveis, chamado domínio, ou conjunto de valores. 
O domínio do atributo nome pode ser o conjunto de todos os textos string de um 
certo tamanho. 
O domínio do atributo código pode ser o conjunto de strings que começam com as 
letras "DCC" e mais uma sequencia de três dígitos. 
 
2.3.2. Tipos de atributos 
Os valores dos atributos que descrevem as entidades constituem uma porção 
significativa dos dados que serão armazenados no banco de dados. 
Um atributo pode ser caracterizado pelos seguintes tipos: 
 simples ou compostos 
 monovalorados ou multivalorados 
 nulos 
 derivados 
 
Atributo simples ou composto 
Um atributo simples é aquele que não é dividido em partes. Já um atributo 
composto pode ser dividido em partes (isto é, em outros atributos). 
Ex: O atributo nome pode ser estruturado em primeiroNome e sobrenome. 
Suponha que queiramos substituir os atributos rua_aluno e cidade_aluno do 
conjunto de entidades Aluno para endereço_aluno, atributo composto por rua, cidade, 
estado e CEP. 
Os atributos compostos ajudam-nos a agrupar atributos correlacionados, tornando 
o modelo mais claro. Note que os atributos compostos podem estar hierarquizados. 
Retomando o exemplo do atributo composto endereço_Aluno, seu atributo rua pode vir 
a ser subdividido posteriormente em numero_rua, nome-rua e apt_numero. 
 
EADDCC030 – Fundamentos de Banco de Dados 
29 
 
 
DICA: O uso de atributos compostos em um esquema de dados é uma 
boa escolha quando o usuário desejar se referir ao atributo como um 
todo em certas ocasiões e somente a parte dele em outras. 
 
Atributo mono ou multivalorados 
São atributos que aceitam somente um valor (mono), ou múltiplos 
(multi) valores para dada instância da entidade. O atributo nome de uma 
entidade específica de Aluno refere-se apenas ao nome do Aluno e é 
monovalorado. 
Para instâncias onde um atributo possui um conjunto de valores este 
atributo é chamado multivalorado. Considere que a entidade Aluno tenha 
agora um novo atributo telefone. O aluno pode ter dois telefones um 
residencial e um celular; assim, uma mesma instância da entidade Aluno 
pode ter dois valores para o atributo telefone. Este atributo portanto é 
chamado multivalorado. 
 
 
 
 
 
Atributo Nulo 
O atributo nulo é usado quando uma entidade não possui valor para determinado 
atributo. 
Ex: se um AlunoEspecial em particular não quer fornecer sua data de nascimento, 
o valor do atributo data_nascimento para este aluno deverá ser nulo, e isto significa 
que este atributo“não é aplicável”. O uso do atributo nulo também pode significar que o 
valor do atributo é desconhecido. 
{32112030, 91023456}
{32150140, 88871245}
telefone
90887654321Pedro Manuel
12345678909João da Silva
CPFnome
{32112030, 91023456}
{32150140, 88871245}
telefone
90887654321Pedro Manuel
12345678909João da Silva
CPFnome
multivaloradomultivalorado
EADDCC030 – Fundamentos de Banco de Dados 
30 
 
 
 
 
 
 
 
Atributo Derivado 
O valor deste tipo de atributo pode ser derivado de outros atributos ou entidades a 
ele relacionados. 
Ex: A entidade AlunoEspecial possui o atributo idade que representa a idade do 
aluno naquele momento. Podemos derivar o valor deste atributo subtraindo a data 
corrente pela data de nascimento do aluno. 
AlunoEspecial
Nome Data_nascimento
endereco idade
 
 
2.4. MER - Relacionamentos 
É toda associação entre duas ou mais entidades, sobre a qual se deseja manter 
informações no Banco de Dados. 
Os relacionamentos representam fatos ou situações da realidade, onde as 
entidades interagem de alguma forma. Um dado por si só não faz uma informação, pois 
não tem sentido próprio; é necessário que haja uma associação de dados para que a 
informação seja obtida. O relacionamento faz o papel desta associação. 
AlunoEspecial
Nome Data_nascimento
endereço idade
EADDCC030 – Fundamentos de Banco de Dados 
31 
 
No MER, um relacionamento é representado por um losango. 
 
Exemplos: 
 matricula: entre as entidades Aluno e Turma. 
 oferece: entre as entidades Disciplina e Turma. 
 pertence: entre as entidades Professor e Escola. 
Representação no MER: 
 
 
Importante: 
 O valor corrente de uma entidade é o conjunto de instâncias 
que pertence a ele. Exemplo: Conjunto de Disciplina = {Banco 
de Dados, Engenharia de Software, Orientação a Objetos....} 
 O valor de um relacionamento é o conjunto de pares de 
instâncias que se relacionam, de acordo com o mesmo. 
2012_2OOOO
2013_1ESEng. De Software
2013_1BDBanco de Dados
TurmaDisciplina
2012_2OOOO
2013_1ESEng. De Software
2013_1BDBanco de Dados
TurmaDisciplina
Disciplina Turmaoferece
 
 
Como faríamos a seguinte modelagem utilizando entidades e os relacionamentos 
entre as mesmas: Bares vendem cervejas e são freqüentados por apreciadores de 
cerveja. Como faço esta modelagem? 
 
aluna turmamatricula
EADDCC030 – Fundamentos de Banco de Dados 
32 
 
CERVEJA BARVENDE
BEBEDOR
FREQÜENTA
GOSTA
 
 
Um relacionamento também pode ter atributos descritivos 
Professor EscolatrabalhaProfessor Escolatrabalha
salário
 
O atributo salário não pertence nem a entidade Professor e nem a entidade 
Escola isoladamente mas pertence sim ao relacionamento entre o professor e a escola. 
Um professor em uma escola diferente pode ter outro salário e um outro professor da 
mesma escola pode ter salário diferente. 
O número de entidades que participam em um relacionamento é também o grau 
deste relacionamento. Um conjunto de relacionamento binário é de grau dois (duas 
entidades participantes); um relacionamento ternário é de grau três (três entidades 
participantes). 
2.4.1. Autorrelacionamento 
A função que uma entidade desempenha em um relacionamento é chamada de 
papel. Antes de falarmos sobre Auto-relacionamentos, devemos primeiro entender o 
conceito de papel. 
EADDCC030 – Fundamentos de Banco de Dados 
33 
 
Um autorrelacionamento é o relacionamento entre ocorrências da mesma 
entidade. Para que fique claro a qual papel uma dada instância da entidade esta 
desempenhando no relacionamento, devemos nomear os lados do relacionamento. 
Professor
ÉTutor
Subordinado 
Tutor
Orientador
 A entidade Professor tem um 
 papel em cada lado do relacionamento! 
 
2.4.2. Cardinalidade de Relacionamentos 
A cardinalidade de uma entidade em um relacionamento expressa o número de 
instâncias da entidade que podem ser associadas a uma determinada instância da 
entidade relacionada. 
Devem ser consideradas duas cardinalidades: 
 Cardinalidade máxima 
 Cardinalidade mínima 
Cardinalidade Máxima de uma Entidade: é o número máximo de instâncias 
da entidade associada que devem se relacionar com uma instância da entidade 
em questão. 
Disciplina Turmaoferece
1 n
Expressa que uma 
instância de Turma
pode estar associada 
a no máximo a uma 
instância de 
Disciplina
Expressa que uma 
instância de 
Disciplina pode estar 
associada 
a várias instâncias de 
Turma
 
EADDCC030 – Fundamentos de Banco de Dados 
34 
 
 Tipos de Cardinalidade Máxima 
o Um para Um (1:1): Uma entidade em A está associada no máximo com 
uma entidade em B, e uma entidade em B está associada com no 
máximo uma entidade em A. 
 
 
 
 
 
Turma Professorpossui
1 1
Pessoa
Casamento
Marido Mulher
11
 
o Um para Muitos (1:N): Uma entidade em A está associada com várias 
entidades em B. Uma entidade em B, entretanto, deve estar associada 
no máximo a uma entidade em A. 
a1
a2
a3
b1
b2
b3
b4
a1
a2
a3
b1
b2
b3
b4
 
a1
a2
a3
a4
b1
b2
b3
b4
a1
a2
a3
a4
b1
b2
b3
b4
EADDCC030 – Fundamentos de Banco de Dados 
35 
 
 
o Muitos para um: Uma entidade em A está associada a no máximo uma 
entidade em B. Uma entidade em B, entretanto, pode estar associada a 
um número qualquer de entidades em A. 
a1
a2
a3
a4
b1
b2
a1
a2
a3
a4
b1
b2
 
o Muitos para Muitos: Uma entidade em A está associada a qualquer 
número de entidades em B, e uma entidade em B está associada a um 
número qualquer de entidades em A. 
a1
a2
a3
a4
b1
b2
b3
b4
a1
a2
a3
a4
b1
b2
b3
b4
 
 
EADDCC030 – Fundamentos de Banco de Dados 
36 
 
Aluno TurmaMatricula
n n
Professor Turmaleciona
n n
 
 
Cardinalidade mínima de uma entidade: é o número mínimo de instâncias da 
entidade associada que devem se relacionar com uma instância da entidade em 
questão. A cardinalidade mínima é usada para indicar o tipo de participação da 
entidade em um relacionamento. 
Esta participação pode ser: 
 Parcial ou Opcional: Uma ocorrência da entidade pode ou não participar de 
determinado relacionamento. É indicado pela cardinalidade mínima = 0 (zero). 
Departamento Professoralocação
(1,1) (0,N)
 
o Um Departamento pode ter no mínimo nenhum professor (0) e no máximo, 
vários professores. 
o Indica que podem existir departamentos que não tem nenhum professor 
relacionado a ele. 
 
 Total ou Obrigatória: Quando todas as ocorrências de uma entidade devem 
participar de determinado relacionamento. É indicado pela cardinalidade mínima > 0 
(zero) .... geralmente 1. 
Departamento Professoralocação
(0,1) (1,N)
 
o Todos os departamentos devem possuir pelo menos (no mínimo) um 
professor alocado. Observem a bolinha vermelha que indica o 1 do lado do 
professor. 
EADDCC030 – Fundamentos de Banco de Dados 
37 
 
o Indica que não poderá existir no banco um departamento que não tenha 
nenhum professor. 
Departamento Professoralocação
(1,1) (10,n)
 
o Parcialidade mínima: para um departamento ser criado, devem existem pelo 
menos 10 professores alocados. 
 
2.4.3. Relacionamentos enésimos 
Algumas vezes pode ser necessário expressar relacionamentos envolvendo mais 
de duas entidades. 
 Relacionamentos ternários ou maiores são raros mas as vezes necessários para se 
refletir a verdadeira semântica 
 O exemplo abaixo mostra o relacionamento contrato, que envolve escola, professor 
e turma. Este relacionamento representa que uma escola tem contrato com 
professores em particular para atuarem em turmas. 
Disciplina Professorcontrato
Escola
(1,N)
(1,N)
(1,1)
Dada uma disciplina e um 
professor, os mesmos
só podem ser relacionados a uma 
escola. Por outro lado, uma 
escola
pode contratar vários professores 
para uma disciplina e
Um professor pode ser 
contratado por uma escola para 
várias disciplinas. 
 
2.5.MER - Generalização/Especialização 
Generalização: Processo de abstração em que vários tipos de entidade são 
agrupados em uma única entidade genérica, que mantém as propriedades comuns. 
Especialização: Processo inverso, ou seja, novas entidades especializadas são 
criadas, com atributos que acrescentam detalhes à entidade genérica existente: 
 
EADDCC030 – Fundamentos de Banco de Dados 
38 
 
 Entidade genérica é denominada superclasse 
 Entidade especializadas são subclasses. As subclasses possuem, além de 
seus próprios atributos, os atributos da superclasse correspondente (herança). Usada 
quando é necessário caracterizar entidades com atributos próprios ou participação em 
relacionamentos específicos. 
Dito em outras palavras, a superclasse armazena os dados gerais de uma 
entidade e as subclasses armazenam os dados particulares. 
Superclasse e subclasses são conectadas por um relacionamento ISA (É UM), 
que é representado geralmente por um triângulo. Todo relacionamento ISA é um para 
um e portanto não precisamos representar a cardinalidade. 
Filme
Desenho Suspense
tamanho
ano
título
arma
dubla
Estrela
 
 
Exemplos: 
 Um filme típico, que não é suspense e nem desenho, só terá instância na entidade 
Filme e terá os três atributos desta entidade. 
 Um filme que é desenho terá valores para os 3 atributos de filme e terá ainda o 
relacionamento dubla que só vale para filmes-desenho. 
EADDCC030 – Fundamentos de Banco de Dados 
39 
 
 Um filme de suspense terá os três atributos de filme mais o atributo arma . 
 Um filme como Roger Rabbit que é desenho e suspense ao mesmo tempo tem 
instâncias nas 3 entidades. 
 
2.5.1. Tipos de Generalização/Especialização 
No MER estendido, podemos ainda classificar os tipos de relacionamentos ISA: 
 Total: indica que toda instância tem que pertencer a uma das especializações. 
(Todo cliente tem obrigatoriamente que ser ou pessoa física ou jurídica) 
Cliente
Jurídica Física
T
 
 Parcial: indica que podemos ter instância na superclasse que não pertencem as 
subclasses. 
Funcionário
Secretária Motorista
P
 
 Em cada relacionamento ISA, as instâncias nas subclasses são mutuamente 
exclusivas 
 Seguindo este princípio, no exemplo a seguir não podemos ter uma instância que 
seja Jurídica e Física ao mesmo tempo (ambas as entidades estão conectadas pelo 
mesmo ISA) 
Cliente
Jurídica Física
T
 
EADDCC030 – Fundamentos de Banco de Dados 
40 
 
 No exemplo a seguir podemos ter um filme que seja ao mesmo tempo desenho e 
suspense. 
Filme
Desenho Suspense
 
 
Importante: 
O relacionamento de Gen/ESP no MER lembra muito o 
conceito de herança e hierarquia de classes do modelo OO.No 
entanto, existe uma diferença fundamental entre a visão ISA 
do MER e a visão OO: 
 
 Uma instância pode ter representantes em mais de um conjunto de 
entidades no MER e no modelo OO uma instância só está relacionada a 
uma classe. 
 Ex: O filme Roger Rabbit tem representante nas entidades, 
suspense, desenho e filme no MER. No modelo OO isto não é 
possível – lançaríamos mão do conceito de herança 
múltipla..... 
 
2.6. Entidade Associativa 
É a entidade criada a partir de um relacionamento. 
No exemplo a seguir, a entidade associativa foi utilizada para adicionar a 
informação que a cada consulta feita pelo paciente são prescritos um ou mais 
medicamentos. 
Médico Pacienteconsulta
Medicamento
prescreve
 
EADDCC030 – Fundamentos de Banco de Dados 
41 
 
2.7. Entidade Fraca 
Para melhor definirmos o conceito de Entidade Fraca, detalharemos o conceito de 
dependência existencial. 
Se a existência da entidade x depende da existência da entidade y, então x é dito 
ser dependente da existência de y. Operacionalmente, se y for excluído, o mesmo 
deve acontecer com x. 
 A entidade y é chamada entidade dominante e a x é chamada entidade 
subordinada. 
A entidade subordinada é mais conhecida no MER como ENTIDADE FRACA 
A entidade dominante é conhecida como ENTIDADE FORTE. 
 
Importante: 
A participação total está estreitamente relacionada a 
existência de dependência. 
 
 
No geral, Existem duas causas principais (não únicas) para se utilizar entidade 
fraca: 
1. Quando uma dada entidade pode ser considerada como uma subunidade de 
uma outra, algumas vezes a subunidade pode não ter identificadores únicos 
Staff EstúdioÉ unidade
(0,N) (1,1)
 
Um estúdio tem um conjunto de pessoas que trabalham em filmes. Estes são designados por 
staff 1, staff2. Estes nomes são utilizados por vários estúdios. Assim, sem o nome do estúdio 
não podemos identificar unicamente um staff. Precisamos da entidade Estúdio. 
especies GêneroPertence a
(0,N) (1,1)
 
 
EADDCC030 – Fundamentos de Banco de Dados 
42 
 
Um espécie é designada pelo seu gênero e o nome da espécie. Por exemplo, os homens são 
da espécie Homo Sapiens. Homo é o nome do gênero e sapiens o nome da espécie. Em 
geral, um gênero consiste de várias espécies. As espécies não são únicas e precisam do 
gênero para sua identificação única. 
2. Uso de uma entidade de conexão usada para eliminar relacionamentos 
ternários ou maiores.. Estas entidades não vão ter atributos seus. Vão sempre 
usar os atributos das entidades fortes. 
Filme
Estrela
Filme_de
Estúdio
1
1
contrato
N
Estrela_de
N
Estúdio_de
1
N
 
 
Requisitos para uso de entidades fracas: 
 A relação entre entidade fraca e forte deve ser binária, muitos para um da entidade 
fraca para a forte. 
 Da lado da entidade forte, a cardinalidade mínima deve ser total, ou seja, para toda 
entidade fraca E, deve existir no banco uma entidade forte F. 
 Os atributos que serão utilizadas como chave de E por parte de F devem ser os 
atributos chave de F. 
 
2.8. Restrições 
Atributo Chave: uma chave é um atributo ou conjunto de atributos de uma 
entidade de forma que duas instâncias quaisquer dessa entidade não tenham valores 
iguais para estes atributos. Devemos designar uma chave para todo conjunto de 
entidade. Representamos atributos chave no MER pelo grifo em baixo de seu nome. 
 
EADDCC030 – Fundamentos de Banco de Dados 
43 
 
Aluno
Infantil Fundamental
nome
endereço
matricula
atividade
extra
 
Valores únicos para atributos: Todo atributo chave deve ser monovalorado. 
Sempre que possível, tentar descrever atributos monovalorados - isso não é uma regra 
para atributos não chave uma vez que podemos ter atributos multivalorados. 
Integridade Referencial: Quando temos cardinalidade mínima 1 (total), como no 
caso de Filial no exemplo abaixo, significa que devemos reforçar algumas restrições na 
manipulação do nosso BD. Não podemos apagar uma filial do nosso BD até que não se 
tenha nenhum cliente relacionado a ela. Se for necessário apagar uma filial, todos os 
clientes relacionados a ela também devem ser apagados, chamamos isso de deleção 
em cascata. 
Filial Clientepertence
(1,1) (0,n)
 
 
2.9. Técnicas de Projeto 
1. Evitar a redundância: As informações devem aparecer no modelo apenas uma vez. 
Informações replicadas dão margem a inconsistências. 
 
Filme
título
Ano tamanho
tipoFilme
Estúdio
Nome
endereco
comanda
 
EADDCC030 – Fundamentos de Banco de Dados 
44 
 
A modelagem anterior é boa uma vez que endereço do estúdio aparece apenas uma vez. Já 
o modelo a seguir não é tão bom, pois cria a informação sobre estúdio duas vezes, na 
entidade estúdio e no filme. 
Filme
título
Ano tamanho
tipoFilme
Estúdio
Nome
endereco
comanda
estúdio
 
 
O modelo abaixo é pior ainda, pois repete o nome e endereço do estúdio para todos os 
filmes de um dado estúdio. Pior ainda, se um estúdio é novo e ainda não tem filme, não 
aparecerá no banco. 
Filme
título
Ano
tamanho
tipoFilme
estúdioNome
enderecoEstudio
 
2. O que usar: Entidade ou Atributo? Dois requisitos devem ser atendidos para ser 
entidade: 
 Algo merece ser entidade se tiver mais do que um atributo. Se tiver apenas 
um atributo,não merece ser entidade e sim atributo de alguma outra 
entidade. 
 Se este algo for o lado muitos em um relacionamento muitos para um ou 
muitos para muitos. 
empregado
nome_emp
nro-fone
empregado
nome_empnome_emp
nro-fonenro-fone nro-fone não 
merece ser entidade 
uma vez que possui 
apenas um atributo 
 
EADDCC030 – Fundamentos de Banco de Dados 
45 
 
MAS, se o telefone for, no modelo, uma entidade sujeita a seus próprios atributos como 
nro_fone e localização, então: 
 conjunto de entidades empregado (atributo nome_emp) 
 conjunto de entidades telefone (atributos nro_fone e localização) 
 conjunto de relacionamentos emp_telefone, denotando a associação entre os 
empregados e os telefones que podem ter. 
empregado
nome_emp
telefone
localização
nro-fone
emp_
telefoneempregado
nome_empnome_emp
telefone
localização
nro-fone
emp_
telefone
 
Diferenças entre as duas modelagens acima: 
 No 1. caso, a definição implica que todo o empregado possui precisamente um 
número de telefone a ele associado. 
 No 2. caso, entretanto, a definição estabelece que o empregado pode ter vários 
números de telefones (incluindo zero) a ele associados. 
 a 2a. definição é mais geral que a 1a. e pode refletir com maior precisão as 
situações reais. 
Linha mestra para escolha entre criar uma entidade ou atributo: 
recorrer ao conjunto de relacionamentos para descrever uma ação que 
ocorre entre entidades. Esta abordagem pode ser útil também para 
decidir se certos atributos podem ser expressos de maneira mais 
apropriada como relacionamentos. 
 
3. Quando usar entidades fracas? 
Procure por uma chave para as entidades (não chaves imaginárias... mas chaves 
consistentes). Caso não ache e considere que para identificar unicamente uma 
instância necessitamos na instância de uma outra, então, esta será entidade fraca. 
 Tenha em mente: não existe uma autoridade global para designar chaves. 
o Ex: é muito pouco provável que se designe uma chave global para se 
identificar cada jogador unicamente entre os times de futebol. 
EADDCC030 – Fundamentos de Banco de Dados 
46 
 
 
4. Como tratar atributos opcionais?? 
Empregado
CRM
tipoEmpregado código
nome
CREA
 
 
Ver se existe a possibilidade de se criar uma GEN/ESP. 
Empregado
Médico Engenheiro
nomecódigo
CRM CREA
 
 
5. Como tratar atributos multivalorados? 
Geralmente criamos uma entidade e um relacionamento para a entidade original. 
Empregado
código
nome
dependentes 
dependente
Data nasc
Empregado
código
nome
possui
nome
 
 
 
EADDCC030 – Fundamentos de Banco de Dados 
47 
 
6. Como tratar atributos que mudam de valor ao longo do tempo? 
Geralmente criamos uma entidade e um relacionamento para a entidade original. 
Empregado
código
nome
salário
salário
data
Empregado
código
nome
possui
valor
 
7. Como tratar relacionamentos que mudam ao longo do tempo? 
Geralmente criamos um relacionamento com um atributo específico para isso. 
sala
localizacao
Empregado
código
nome
alocado
numero
sala
localizacao
Empregado
código
nome
alocado
numero
data
 
Exercícios de Fixação: 
a) Suponha que um grande estúdio de cinema tenha nos chamado para modelar 
um banco de dados para controle de seus filmes. Devemos controlar os filmes 
lançados, guardando informações sobre seus títulos, ano de lançamento, tamanho e 
tipo (colorido ou preto e branco). Devemos também saber quem foram as estrelas 
(atores ou atrizes) usados no filme. Destas estrelas devemos saber inicialmente seu 
nome, endereço, data nascimento e idade (sabemos que algumas estrelas não dizem por nada a 
data de nascimento....). Atualmente os estúdios só produzem filmes que sejam realmente feitos por 
outros estúdios menores. Desta forma, devemos também guardar informações acerca destes 
estúdios, guardando inicialmente seu nome e endereço. 
EADDCC030 – Fundamentos de Banco de Dados 
48 
 
Exercícios Propostos: 
a) Fazer um MER para uma companhia de projetos. A Companhia é 
organizada em departamentos. Cada departamento possui nome único, um 
no único, e um funcionário que o dirige. Um departamento controla um no 
de projetos, cada um dos quais possui um nome e um no único, e uma 
localização. Para cada funcionário é mantido o seu nome, sua RG que é 
única, e uma matrícula também única. Um funcionário pertence a um e somente um 
departamento, porém pode trabalhar em mais de um projeto. Controla-se o no de horas 
semanais que cada funcionário trabalha em cada projeto. Controla-se também quem é o 
supervisor direto de cada funcionário. É mantida a informação de quando o funcionário 
começou a dirigir o departamento. 
b) Nossa empresa de projetos cresceu e alguns novos requisitos são necessários: Foi criado 
um projeto especial, chamado multimídia, que é o único que tem alocado uma série de 
recursos para seu funcionamento. Consideramos recursos material tais como software de 
autoria, scanner, etc. Agora, de tempos em tempos, os departamentos ganham uma 
verba extra para se manterem. No entanto, a qualquer momento a sede da empresa pode 
requisitar um relatório com a quantidade de verbas enviadas para cada departamento e 
quando foram os aportes. Agora cada departamento possui um gerente, que é um 
empregado. No entanto, gerentes possuem maior qualificação e por conta disso, devemos 
guardar a informação de seu grau de instrução. Devemos ainda guardar informações 
sobre cursos extras que os funcionários fizerem ao longo dos anos que trabalham na 
empresa. E para cada funcionário, devemos saber ao certo a idade que o mesmo realizou 
o curso. 
 
Resposta do Exercício de Fixação: 
a) Suponha que um grande estúdio de cinema tenha nos chamado para modelar um banco de 
dados para controle de seus filmes. Devemos controlar os filmes lançados, guardando 
informações sobre seus títulos, ano de lançamento, tamanho e tipo (colorido ou preto e 
branco). Devemos também saber quem foram as estrelas (atores ou atrizes) usados no filme. 
Destas estrelas devemos saber inicialmente seu nome, endereço, data nascimento e idade 
(sabemos que algumas estrelas não dizem por nada a data de nascimento....). Atualmente os 
estúdios só produzem filmes que sejam realmente feitos por outros estúdios menores. Desta 
forma, devemos também guardar informações acerca destes estúdios, guardando inicialmente 
seu nome e endereço. 
Estrela
Nome
Data_nascimento
endereco
idadeFilme
título
Ano tamanho
tipoFilme
Estúdio
Nome
endereco
 
 
 
 
 
EADDCC030 – Fundamentos de Banco de Dados 
49 
 
 
CAPÍTULO 3 - MODELO RELACIONAL 
 
Neste capitulo você estudará conceitos relacionados ao projeto 
lógico de banco de dados, através do modelo relacional. Um 
modelo lógico faz uma adequação do modelo conceitual, incluindo 
restrições relacionadas ao modelo de banco de dados escolhido, 
que no nosso caso é o modelo relacional. Trata-se de um modelo 
com maior nível de detalhe do que o conceitual. 
 
3.1 Introdução 
Quando construímos um modelo conceitual, focamos apenas no que o usuário 
deseja, abstraindo da plataforma em que este será implementado. No que se refere 
aos projetos de Banco de Dados, a preocupação e centrada em estabelecer de que 
forma os dados serão armazenados no sistema. Introduzido pelo pesquisador da IBM 
Edward F. Codd em 1970. Possui duas características marcantes, razões de sucesso: 
sua estrutura de dados simples e uniforme e uma fundamentação teórica sólida oriunda 
da matemática. Opera com os dados organizados como um conjunto de tabelas. O 
conceito de tabela é o mais forte no modelo relacional. 
 
3.2 Características das Tabelas 
Tabela Fornecimento 
1209782001
5678702002
1200701501
QuantidadeProjetoPecaFornecedor
1209782001
5678702002
1200701501
QuantidadeProjetoPecaFornecedor
 
Algumas características marcantes do modelo são detalhadas a seguir: 
 Cada Tabela tem um nome único através do qual ela é referenciada. 
 Cada Tabela contém um número fixo de colunas (grauda tabela). 
 Não existem linhas iguais (por conta da unicidade da chave primária). 
EADDCC030 – Fundamentos de Banco de Dados 
50 
 
 A ordem das linhas é irrelevante (identificação não é feita pela localização, mas sim 
pelo valor da chave primária). Cada coluna tem um nome único (diferente das 
demais colunas). 
 A ordem das colunas é irrelevante (a coluna é identificada pelo seu nome). obs: 
Para algumas cláusulas SQL (inserção) esta ordem é relevante (dependendo da 
sintaxe da inserção). 
 Cada coluna contém valores atômicos (não são permitidos grupos de valores) 
 Cada valor de coluna é extraído de um determinado DOMÍNIO (conjunto de valores 
possíveis) 
 Duas ou mais colunas podem ser definidas sobre um mesmo Domínio 
 Conexões entre tabelas somente serão expressas através de valores das colunas 
(Chave Estrangeira) 
Considere a tabela FORNECIMENTO. Ela possui quatro colunas: Fornecedor, 
Peça, Projeto, Quantidade. Seguindo a terminologia do modelo relacional, tratamos os 
nomes dessas colunas como atributos. Para cada atributo há um conjunto de valores 
permitidos, chamado domínio da coluna em questão. Para o atributo Fornecedor, por 
exemplo, o domínio é o conjunto de todos os números de fornecedores. Suponha que 
D1 denote esse conjunto, D2 o conjunto de números de peças, D3 o conjunto de 
números de todos os projetos e D4, o conjunto de todos os inteiros. Qualquer linha da 
tabela FORNECIMENTO consiste necessariamente de uma tupla (v1, v2, v3, v4), em 
que v1 é o número do fornecedor, (isto é, v1 está no domínio D1), v2 é um número de 
peça e assim por diante. Em geral, uma linha da tabela fornecimento é um conjunto de 
D1 x D2 x D3 x D4. 
Matematicamente, define-se uma relação como um subconjunto de um produto 
cartesiano de uma lista de domínios. Essa definição corresponde quase exatamente a 
definição de uma tabela. A única diferença é que designamos nomes aos atributos, ao 
passo que matematicamente se usam apenas “nomes” numéricos. Como as tabelas 
em essência são relações, podemos usar os termos matemáticos relação e tupla no 
lugar de tabela e linhas, respectivamente. 
3.3 Chaves 
Chave primária (primary key): É um atributo (coluna) ou uma combinação de 
atributos cujos valores distinguem uma linha das demais, dentro de uma tabela. 
EADDCC030 – Fundamentos de Banco de Dados 
51 
 
1209782001
5678702002
1200701501
QuantidadeProjetoPecaFornecedor
1209782001
5678702002
1200701501
QuantidadeProjetoPecaFornecedor
 
7Maria02
7José01
NumDEPTONomeNumFUNC
7Maria02
7José01
NumDEPTONomeNumFUNC
DCC7
DescricaoNumDEPTO
DCC7
DescricaoNumDEPTO
Chave Estrangeira
Chave Primária
 
Chave estrangeira (foreign key): É um atributo ou uma combinação de atributos, 
cujos valores aparecem necessariamente na chave primária de uma tabela. A chave 
estrangeira é o mecanismo que permite a implementação de relacionamentos 
(navegabilidade). 
Chave candidata ou alternativa: Em alguns casos, mais de um atributo ou 
combinações de atributos podem servir para distinguir uma linha das demais. Um dos 
atributos (ou combinação de atributos) é escolhido como chave primária e os demais 
atributos (ou combinações) são denominados chaves candidatas. 
Chave 
candidata
CPFFunc
Chave 
estrangeira
Chave 
primária
NumDEPTONomeNumFUNC
Chave 
candidata
CPFFunc
Chave 
estrangeira
Chave 
primária
NumDEPTONomeNumFUNC
 
 
3.4 Esquema de um Banco Relacional 
O esquema de uma relação é constituído pelo nome da relação e seus atributos, 
em ordem. 
Filme(#nro, título, tamanho, tipoFilme) ou 
Pode conter o detalhamento relativo ao tipo de atributo. 
EADDCC030 – Fundamentos de Banco de Dados 
52 
 
Filme(#nro:inteiro, tamanho: float, tipoFilme:string) 
Desta forma, um Banco de Dados pode ser definido como sendo uma coleção de 
relações e um Esquema do Banco de Dados é definido como um conjunto de 
esquemas das relações. 
Já o Catálogo é um Banco de Dados do sistema contendo informações sobre as 
tabelas básicas, além de visões, direitos da acesso, etc. São também chamados de 
metadados. Este catálogo ou metadados pode ser consultado com SQL. 
 
3.5 Transformação do MER para o Modelo Relacional 
Apresentamos a seguir um passo a passo para a elaboração do projeto lógico de 
bancos de dados relacionais a partir do Modelo Entidade e Relacionamento (MER). 
Esta apostila tem foco apenas o projeto de banco de dados relacional, mas outras 
estratégias, não apresentadas aqui, podem ser utilizadas para a passagem do MER 
para o modelo hierárquico, em redes ou orientado a objetos. 
 
Passo 1: Análise das Entidades 
 Entidades se tornam tabelas 
o Escolher uma chave para ser a chave primária 
Engenheiro
Código Nome endereco
Engenheiro
#Codigo nome endereco
 
 Cada atributo da entidade se torna um atributo da tabela ou relação. 
 
Passo 1.1: Atributos Compostos 
Exemplo: se o atributo endereço fosse composto, isto é: endereço (rua, numero, 
bairro, cidade, estado) -> colocar os atributos que compõem endereço na tabela. 
Engenheiro
#Codigo nome rua numero bairro cidade estado
 
EADDCC030 – Fundamentos de Banco de Dados 
53 
 
Passo 1.2: Atributos Multivalorados 
 Criar outra tabela com o atributo multivalorado e a chave da tabela principal. 
 
 
 
 
 
Passo 2: Análise dos Relacionamentos 
 Análise de Relacionamento 
o As ligações entre as tabelas no modelo relacional representam os 
relacionamentos do modelo conceitual. 
 Regra Geral 
o Toda vez que um relacionamento tiver atributo, este relacionamento vai ser 
representado por uma tabela. 
Observe: isso é uma regra geral. Temos que analisar caso a caso. 
Pode ser que em uma relação 1:N que tenha atributo valha mais a 
pena colocar este atributo junto com a chave estrangeira do lado 1 na 
tabela do lado N (ganho: otimização de consultas). A mesma coisa no 
rel 1:1. Na verdade, em um projeto real, usamos estas diretivas. 
 
 Representação do Relacionamento 
o Relacionamento vira Tabela. 
o Relacionamento vai ser representado por uma Chave Estrangeira. 
 
Passo 2.1: Mapeamento Relacionamento 1:1 
 Pelo menos uma das entidades possui participação total no relacionamento 
 Ex: O atributo num-emp foi transposto para a relação departamento, com o objetivo 
de representar a restrição de que todo departamento possui um gerente que é 
empregado da empresa. 
Engenheiro
#Codigo Nome telefones
Engenheiro
#Codigo Nome
Telefones
#Codigo #telefone
Opcionalmente, se soubermos a cardinalidade 
da multivaloração (2, 3, 4), podemos criar 
campos na própria tabela. Somente quando 
tivermos certeza disso.
EADDCC030 – Fundamentos de Banco de Dados 
54 
 
 O diagrama mostra a restrição que não podemos ter um departamento sem chefe e 
devemos representar isso no modelo relacional. 
Departamento Empregadochefia
Departamento
#Código Nome Num_Ger
Empregado
Num_func Nome
 
 Mapeamento Relacionamento 1:1 (casos específicos) 
o Ambas entidades possuem participação parcial no relacionamento. 
o Escolhe-se um dos lados para se colocar a chave estrangeira. 
Homem Mulhercasamento
Homem
#CPF_H Nome_H CPF_M 
Mulher
#CPF_M Nome_M
 
Passo 2.2: Mapeamento Relacionamento 1:N 
 A entidade do lado um possui participação total no relacionamento. 
 A chave primária da relação do lado "um" é parte integrante da relação do lado 
muitos. 
Cliente Pedidochefia
CLIENTE
#COD_CLI NOME
PEDIDO
#NRO_PED DATA COD_CLI
 
 Mapeamento Relacionamento 1:N (casos específicos) 
o A entidade do lado um possui participação parcial no relacionamento. 
o Define-se uma terceira relação correspondendo ao relacionamento. 
EADDCC030 – Fundamentos de Banco de Dados 
55 
 
o Na prática, dificilmente fazemos isso mas se quisermos evitar valores nulos 
para a chave estrangeira, esta é a melhor política. No entanto, para fazer 
consultas precisamos juntar mais tabelas. 
Homem
CPF_H Nome_H