E-Book Completo_Banco de Dados_SER e Digital Pages (Versão Digital)

Prévia do material em texto

G
RU
PO
 SER ED
U
CACIO
N
AL
BANCO
DE DADOS
BAN
CO
 D
E D
AD
O
S
Renato Alves Ferreira. Renato Alves Ferreira.
BANCO
DE DADOS
Prezado aluno, seja bem-vindo a mais uma etapa do nosso curso! A disciplina de banco 
de dados foi cuidadosamente elaborada para tratar de conhecimentos importantes e 
relevantes à sua formação. Os bancos de dados impactam nossas vidas e trazem faci-
lidades em praticamente todas as áreas do conhecimento. Ter a possibilidade de obter 
informação de forma rápida e confiável é fundamental para o mundo em que vivemos 
e os bancos de dados permitem controlar e disponibilizar tais informações, o que os 
tornam elementos indispensáveis em uma sociedade moderna.
Em nossa unidade, serão abordados conceitos fundamentais sobre o tema, como: os 
tipos de bancos de dados, modelagem de dados e suas estruturas, sistemas gerencia-
dores de banco de dados, ferramentas CASE para modelagem de banco de dados, en-
tre outros. Esperamos que os assuntos e temas abordados nesta disciplina contribuam 
enormemente em seu processo de formação e permitam alicerçar o seu crescimento 
com uma aprendizagem geradora de resultados e realizações. Vamos ao trabalho?
Banco de dados - Unidade 1_A5.indd 8 09/09/19 09:53
BANCO
DE DADOS
© Ser Educacional 2019
Rua Treze de Maio, nº 254, Santo Amaro 
Recife-PE – CEP 50100-160
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos. 
Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio 
ou forma sem autorização. 
A violação dos direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo 
artigo 184 do Código Penal.
Imagens de ícones/capa: © Shutterstock
Presidente do Conselho de Administração 
Diretor-presidente
Diretoria Executiva de Ensino
Diretoria Executiva de Serviços Corporativos 
Diretoria de Ensino a Distância
Autoria
Projeto Gráfico e Capa
ISBN
Janguiê Diniz
Jânyo Diniz 
Adriano Azevedo
Joaldo Diniz
Enzo Moreira
Prof. Renato Alves Ferreira 
DP Content
978-65-5487-142-6
DADOS DO FORNECEDOR
Análise de Qualidade, Edição de Texto, Design Instrucional, 
Edição de Arte, Diagramação, Design Gráfico e Revisão.
Banco de dados - Unidade 1_A5.indd 2 09/09/19 09:53
Palavras chave: 1. Banco de dados; 2. Three-Schema; 3. SQL; 4. MLD 
Boxes
ASSISTA
Indicação de filmes, vídeos ou similares que trazem informações comple-
mentares ou aprofundadas sobre o conteúdo estudado.
CITANDO
Dados essenciais e pertinentes sobre a vida de uma determinada pessoa 
relevante para o estudo do conteúdo abordado.
CONTEXTUALIZANDO
Dados que retratam onde e quando aconteceu determinado fato;
demonstra-se a situação histórica do assunto.
CURIOSIDADE
Informação que revela algo desconhecido e interessante sobre o assunto 
tratado.
DICA
Um detalhe específico da informação, um breve conselho, um alerta, uma 
informação privilegiada sobre o conteúdo trabalhado.
EXEMPLIFICANDO
Informação que retrata de forma objetiva determinado assunto.
EXPLICANDO
Explicação, elucidação sobre uma palavra ou expressão específica da 
área de conhecimento trabalhada.
Banco de dados - Unidade 1_A5.indd 3 09/09/19 09:53
Unidade 1 - Conceitos iniciais
Objetivos da unidade ........................................................................................................... 12
Introdução aos bancos de dados ...................................................................................... 13
Conceitos de sistemas de banco de dados .............................................................. 13
Introdução à modelagem de dados ................................................................................... 17
Projeto conceitual de banco de dados ...................................................................... 18
Modelo Entidade-relacionamento .................................................................................... 21
Conceitos básicos ......................................................................................................... 21
Aspectos avançados .................................................................................................... 24
Diagrama Entidade-relacionamento .......................................................................... 27
Sintetizando ........................................................................................................................... 39
Referências bibliográficas ................................................................................................. 40
Sumário
Banco de dados - Unidade 1_A5.indd 4 09/09/19 09:53
Sumário
Unidade 2 - Modelo relacional
Objetivos da unidade ........................................................................................................... 42
Modelo relacional ................................................................................................................ 43 
Conceitos básicos ........................................................................................................ 43
Restrições de integridade ............................................................................................ 47
Esquema relacional de um banco de dados ................................................................... 49
Projeto de implementação de banco de dados ...................................................... 50
Implementação de bancos de dados relacionais .................................................... 53
Sistemas de gerenciamento de banco de dados ........................................................... 59
Arquitetura de sistemas de banco de dados ............................................................ 60
Sintetizando ........................................................................................................................... 65
Referências bibliográficas ................................................................................................. 66
Banco de dados - Unidade 1_A5.indd 5 09/09/19 09:53
Sumário
Unidade 3 - Modelo físico do banco de dados – introdução à Linguagem SQL
Objetivos da unidade ........................................................................................................... 68
Conceitos de Linguagem SQL ............................................................................................ 69
Consultas básicas em Linguagem SQL ...................................................................... 76
Restringindo e ordenando dados ...................................................................................... 79
Uso de funções para transformar dados .................................................................. 81
Exibindo dados de várias tabelas ............................................................................... 84
Agregando dados com funções de grupo ........................................................................ 89
Usando subconsultas de dados .................................................................................. 92
Sintetizando ........................................................................................................................... 95
Referências bibliográficas ................................................................................................. 96
Banco de dados - Unidade 1_A5.indd 6 09/09/19 09:53
Sumário
Unidade 4 - Implantação de bancos de dados relacionais
Objetivos da unidade ........................................................................................................... 98
Inserindo, eliminando e alterando dados ........................................................................ 99
Criando e manipulando tabelas .................................................................................. 99
Criação das tabelas .................................................................................................... 104Inserindo dados nas tabelas ..................................................................................... 105
Copiando dados e gerando nova tabela a partir de uma existente .................... 108
Alterando dados da tabela ........................................................................................ 109
Eliminando dados da tabela ...................................................................................... 110
Alterando a estrutura da tabela ................................................................................ 111
Incluindo restrições de dados em tabelas .................................................................... 112
Criando visões de dados ............................................................................................ 116
Criando sequências .................................................................................................... 117
Criando índices ............................................................................................................ 117
Tecnologias emergentes para bancos de dados .......................................................... 119
Banco de dados não relacional e suas aplicações .............................................. 119
Banco de dados orientado a objetos e suas aplicações ..................................... 120
Segurança em banco de dados ....................................................................................... 121
Definição de perfis de usuário (roles) ..................................................................... 122
Ataques típicos em bancos de dados (SQL injection e outros)........................... 123
Soluções de segurança para bancos de dados .................................................... 124
Sintetizando ......................................................................................................................... 125
Referências bibliográficas ............................................................................................... 126
Banco de dados - Unidade 1_A5.indd 7 09/09/19 09:53
BANCO DE DADOS 8
Banco de dados - Unidade 1_A5.indd 8 09/09/19 09:53
Prezado aluno, seja bem-vindo a mais uma etapa do nosso curso! A dis-
ciplina de banco de dados foi cuidadosamente elaborada para tratar de co-
nhecimentos importantes e relevantes à sua formação. Os bancos de dados 
impactam nossas vidas e trazem facilidades em praticamente todas as áreas 
do conhecimento. Ter a possibilidade de obter informação de forma rápida e 
confi ável é fundamental para o mundo em que vivemos e os bancos de dados 
permitem controlar e disponibilizar tais informações, o que os tornam elemen-
tos indispensáveis em uma sociedade moderna.
Em nossa unidade, serão abordados conceitos fundamentais sobre o tema, 
como: os tipos de bancos de dados, modelagem de dados e suas estruturas, 
sistemas gerenciadores de banco de dados, ferramentas CASE para modela-
gem de banco de dados, entre outros. Esperamos que os assuntos e temas 
abordados nesta disciplina contribuam enormemente em seu processo de for-
mação e permitam alicerçar o seu crescimento com uma aprendizagem gera-
dora de resultados e realizações. Vamos ao trabalho?
BANCO DE DADOS 9
Apresentação
Banco de dados - Unidade 1_A5.indd 9 09/09/19 09:53
A Deus, que me capacita a cada dia, aos meus pais, meu porto seguro, aos 
meus fi lhos, razão da minha existência.
O professor Renato Alves Ferreira 
é mestre em informática e gestão do 
conhecimento pela Uninove (2017). É 
especialista em sistema de informação 
com ênfase em tecnologia da infor-
mação pelo Centro Universitário Eniac 
(2005). Graduado em pedagogia plena 
com habilitação em administração es-
colar pela Unoeste (1995), também é 
técnico em processamento de dados 
pelo Eniac (1988).
Currículo Lattes:
http://lattes.cnpq.br/4524836424246846
BANCO DE DADOS 10
O autor
Banco de dados - Unidade 1_A5.indd 10 09/09/19 09:53
CONCEITOS
INICIAIS
1
UNIDADE
Banco de dados - Unidade 1_A5.indd 11 09/09/19 09:54
Objetivos da unidade
Tópicos de estudo
 Apresentar as estruturas de banco de dados comerciais;
 Modelar banco de dados relacionais.
 Introdução aos bancos de 
dados
 Conceitos de sistemas de 
banco de dados
 Introdução à modelagem de 
dados
 Projeto conceitual de banco 
de dados
 Modelo Entidade-relaciona-
mento
 Conceitos básicos
 Aspectos avançados
 Diagrama Entidade-relaciona-
mento
BANCO DE DADOS 12
Banco de dados - Unidade 1_A5.indd 12 09/09/19 09:54
Conceitos de sistemas de banco de dados
Talvez você já tenha se pergunta-
do em algum momento o porquê do 
nome banco de dados, sendo que 
a tradução mais literal dos famosos 
Data Base seria o equivale a bases de 
dados – que também é utilizada, mas 
não com a mesma predileção. A pa-
lavra “banco” é empregada em várias 
áreas, como nos bancos de sangue ou 
de órgãos na área da saúde, no banco 
das agências fi nanceiras ou banco de questões de uma disciplina. 
Podemos então, a princípio, defi nir banco como o agrupamento de elemen-
tos de mesma natureza ou de um mesmo segmento, não é? Mas, com o foco 
em nossa disciplina, podemos encontrar uma defi nição mais apropriada para 
banco de dados. 
O nome banco de dados é atribuído a um conjunto de dados agrupados 
em uma estrutura regular que permite o acesso de maneira organizada e 
normalmente mantido por um sistema computacional que o gerencie.
Introdução aos bancos de dados
Abordaremos conteúdos básicos e elementos fundamentais no universo 
dos bancos de dados. Serão apresentados conceitos, estruturas, aplicações, 
tipos de sistemas gerenciadores de bancos de dados e modelagens de dados; 
inclusive, iniciaremos os estudos sobre desenvolvimento de Diagramas Entida-
des-relacionamentos.
CITANDO
“Então, o que é exatamente um sistema de banco de dados? Basicamente 
nada mais é do que um sistema de armazenamento de dados baseado em 
computador, isto é, um sistema cujo objetivo global é registrar e manter 
informação” (DATE, 2003, p. 26).
BANCO DE DADOS 13
Banco de dados - Unidade 1_A5.indd 13 09/09/19 09:54
Esses sistemas de gerenciamento de banco de dados são conhecidos pela 
sigla SGBD e são os responsáveis por armazenar, manter e prover acesso de ma-
neira controlada e segura à sua base de dados. Para tanto antes, é necessário 
que os bancos de dados sejam projetados segundo uma estrutura clara e bem 
definida, em um modelo teórico, chamado modelo conceitual. Posteriormente, 
por intermédio dos SGBD, conseguimos transformar todo esse modelo concei-
tual em um modelo físico e real com toda a estrutura anteriormente projetada.
A Fig. 1 ilustra o processo de modelagem de um modelo conceitual de banco 
de dados.
Figura 1. Modelagem de banco de dados. Fonte: Shutterstock. Acesso em: 25 fev. 2019.
Os SGBDs, como já definido antes, são os responsáveis pelo gerenciamen-
to dos bancos de dados. São compostos de um conjunto de softwares que 
realizam essa tarefa e muitas vezes são confundidos e chamados também de 
bancos de dados. 
Então, para não restar dúvidas, o banco de dados é a base de dados, o agru-
pamento de dados de mesma natureza que ficam armazenados e gerenciados 
por intermédio dos sistemas gerenciadores de banco de dados.
Pode fazer uma analogia com a vida real: em um escritório, podem existir 
várias gavetas e armários com documentos separados em pastas, fichas ou até 
mesmo uma simples agenda. A organização dessas informações é que faz toda 
a diferença quando pensamos em banco de dados. A Fig. 2 ilustra um banco de 
dados no mundo real, com uma gaveta com pastas de documentos organizados.
BANCO DE DADOS 14
Banco de dados - Unidade 1_A5.indd 14 09/09/19 09:54
Enquanto isso, os SGBDs, em nossa analogia, seriam os profi ssionais res-
ponsáveis em manter e manipular os documentos dessa gaveta no mundo real.
Figura 2. Exemplo de banco de dados no mundo real. Fonte: Shutterstock. Acesso em: 24 fev. 2019.
Aestrutura regular e simplifi cada de um banco de dados pode facilmente 
ser comparada a uma simples tabela ou lista, que organiza as informações de 
mesma natureza, como pode ser visto na Tabela 1.
QUADRO 1. COMPETÊNCIAS PARA O PROFISSIONAL
Produto
Código Nome Valor Quantidade
100020 KL-77 230,00 2
200030 SL-23 150,00 53
200035 SL-91 435,00 30
500040 JS-10 890,00 1
100020100020100020
200030200030
200035
200030
200035
500040
200035
500040500040
KL-77KL-77
SL-23SL-23
SL-91SL-91SL-91
JS-10JS-10
230,00230,00
150,00150,00
435,00
150,00
435,00435,00
890,00890,00
2
53
30
Analisando a Tabela 1, é perceptível que está dividida colunas. Essas colunas 
são os as divisões ou campos que agruparão os dados separadamente. Em um 
sistema de banco de dados computacional, essa tabela recebe o nome de en-
tidade, muito embora que o nome tabela também seja bem praticado. Já suas 
colunas são os atributos da entidade, também conhecidos como campos.
Os dados propriamente ditos estão nas linhas, onde aparecem as caracte-
rísticas de cada produto. Essas linhas com dados sãs chamadas de instâncias 
BANCO DE DADOS 15
Banco de dados - Unidade 1_A5.indd 15 09/09/19 09:54
da entidade, conhecidas também por tuplas ou registros, que é o nome mais 
popularmente conhecido.
Existem dezenas de sistemas gerenciadores de banco de dados em todo o 
mundo. Uma lista mais completa pode ser consultada no portal especializado 
no portal Db-Engines. Alguns dos principais SGBDs utilizados no mundo são:
• Oracle, da empresa Oracle Corporation, de mesmo nome;
• MySQL, criado pela Sun Microsystem, e posteriormente adquirida pela 
Oracle;
• MS SQL Server, da empresa Microsoft;
• PostgreSQ, software livre e não proprietário de código aberto;
• MongoDB, da empresa MongoDB Inc. e de código aberto;
• IBM DB2, criado pela IBM;
• SQLite, software livre e não proprietário de código aberto.
Dados x informação x conhecimento
Antes de avançarmos para o próximo tópico, é necessária uma reflexão so-
bre três elementos instigantes repercutidos no universo de qualquer banco de 
dados: o dado, a informação e o conhecimento. Muitas vezes, em textos lite-
rais e no dia a dia, são tratados ou confundidos como sinônimos. Dependendo 
do contexto, isso realmente pode ocorrer, mas cada um possui características 
bem definidas quando fazemos uma análise mais crítica desses elementos. 
E você, o que acha? Poderia facilmente identificar e conceituar cada um de-
les? Vamos tentar? Imagine a seguinte situação: seu professor pede para você 
olhar o que está escrito no quadro negro. Ao ler, você repara que há apenas a 
letra O. Você diria se tratar de um dado, uma informação ou um conhecimento?
Poderia ser qualquer um deles, não é mesmo? Nesse caso específico, para 
ter certeza de qual elemento se trata, devemos realizar algumas ponderações.
A letra O vista no quadro negro representou algo a você? Trouxe alguma infor-
mação ou conhecimento por si só? Se a resposta é não, então a letra O nesse caso 
é apenas um dado, sem contexto, mas é um dado. Podemos até classificá-lo como 
um simples dado do tipo alfabético ou caractere.
Agora, imagine se seu professor tivesse dito que, ao ler o quadro negro, 
você encontraria o nome de um grupo sanguíneo. Dessa vez, a letra O passou 
a ser um elemento importante, que é o nome de um grupo sanguíneo. Isso é 
uma informação suficiente e completa em si só.
BANCO DE DADOS 16
Banco de dados - Unidade 1_A5.indd 16 09/09/19 09:54
Mas e se o professor dissesse a você que no quadro negro estaria um grupo 
sanguíneo que, juntamente com o grupo sanguíneo tipo A, quase 90% da população 
brasileira é pertencente a esses dois grupos. Podemos dizer agora que a letra O, 
junto com a quantidade de informações fornecidas anteriormente, produziu conhe-
cimento sobre um fato. Isso quer dizer que, sendo bem contextualizado ou relacio-
nado, um único dado poderá trazer consigo informação e conhecimentos.
O segredo está nesse vínculo de um dado com o seu contexto. O número 
49 isoladamente escrito em uma lousa nada quer dizer, mas se acrescentar um 
elemento rótulo, uma legenda ou uma descrição a esse número, poderá fazer 
muito sentido. Exemplo:
- Ano de nascimento: 49
- Peso: 49
- Minutos para o fi m da prova: 49
- Idade: 49
Em um banco de dados, esses elementos são chamados de atributos. Te-
mos, no último exemplo, os atributos ano, peso, minutos e idade, sendo que, 
para todos os casos, o dado em si é o fator mais importante e que consome vo-
lume de armazenamento, ou seja, utiliza espaço no banco de dados. O nome dos 
atributos são meras legendas, mas dão signifi cância aos dados.
EXPLICANDO
O conhecimento é constituído por intermédio de informações que adqui-
rimos e toda informação é constituída por dados. Logo, temos uma hierar-
quia muito bem defi nida e estabelecida. Para que um sistema de banco de 
dados se justifi que e seja efi ciente, não pode ser apenas um depósito de 
dados. Precisa fornecer informações que gerem conhecimentos que satis-
façam as necessidades das organizações que os utilizam e os mantêm.
Introdução à modelagem de dados
Até este ponto, você já deve ter tido uma visão bem superfi cial sobre o que 
são os bancos de dados. Mas como esses bancos de dados são criados? Quais 
as primeiras etapas que devemos seguir para implementarmos um efi ciente 
e poderoso banco de dados? Qual SGBD devemos adotar? Será que todos são 
iguais? Questões como essas só podem ser respondidas no momento em que 
BANCO DE DADOS 17
Banco de dados - Unidade 1_A5.indd 17 09/09/19 09:54
nos aprofundamos mais nos assuntos que os cercam e é isso que faremos a 
partir desse tópico. Vamos lá?
A primeira etapa de um projeto que envolva banco de dados é a modela-
gem de dados, tendo como principal objetivo o desenvolvimento de um mode-
lo que ajude a organizar a forma de raciocínio e conhecimento sobre os dados, 
demonstrando o signifi cado e a aplicação prática de cada elemento envolvido. 
Na visão de Muller (2002), a modelagem de dados também estabelece o víncu-
lo entre as necessidades do usuário e a solução de software que as atende, 
fazendo com que se tenha uma redução da complexidade do projeto a um pon-
to que o projetista possa compreender e manipular os dados.
Modelar os dados signifi ca planejar e conceituar como será a estrutura e 
a organização destes dados no banco que será criado, portanto, essa atividade 
antecede a criação física do banco de dados. 
É necessário ter conhecimento detalhado sobre o que se quer modelar; 
para tanto, isso só deve ocorrer após a análise de requisitos prevista no pro-
cesso de engenharia de software. Logo, se faz necessário adquirir conheci-
mentos do negócio e estrutura da empresa ou organização que usufruirá do 
banco de dados a ser implementado. A modelagem de dados é uma técnica 
usada para especifi car as regras de negócios e a estrutura de dados de um 
banco de dados. 
Modelagem de dados envolve ações teóricas e práticas, visando construir 
um modelo de dados consistente, não redundante e podendo ser aplicado em 
qualquer SGBD moderno.
Projeto conceitual de banco de dados
O projeto conceitual de um banco de dados é uma fase muito importante 
no planejamento. As metodologias de projeto de bancos de dados estão forte-
mente relacionadas com as diretrizes da engenharia de software, no entan-
to, a modelagem conceitual está realizada no nível mais alto e elementar que 
permite envolver o cliente, pois seu foco é discutir os aspectos do negócio do 
cliente e não das tecnologias envolvidas. Os exemplos de modelagem de dados 
vistos pelo modelo conceitual são mais fáceis de compreender, já que não há 
limitações, especifi cação ou aplicação de tecnologia específi ca. 
BANCO DE DADOS 18
Banco de dados - Unidade 1_A5.indd 18 09/09/19 09:54
Abstração
Há um conceito em modelagem de dados que diz respeito à possibilidade 
de se criar uma visão abstrata de dados para aos usuários. Tal abstraçãode 
dados diz respeito à ocultação de detalhes mais técnicos da estrutura e do ar-
mazenamento, dando destaque apenas aos recursos essenciais para melhor 
entendimento desses dados, ou seja, é possível descrever um banco de dados 
sem se preocupar com as especificidades e detalhes de software ou de hardware 
que o suportarão. 
Essa visão pode ser dividida em níveis de abstração: um nível mais elevado 
para a visão do usuário, outro com uma visão intermediária mais voltada para 
a implementação e outra com uma visão para o nível físico, com menor de 
abstração. 
Seguindo essa linha, um projeto de banco de dados pode ser estruturado 
de uma forma hierárquica conhecida como modelos de dados. Para Elmasri 
e Navathe (2011), modelos de dados podem ser usados para descrever a es-
trutura de um banco de dados, sendo classificados em três modelos distintos: 
conceitual, lógico e físico, que serão apresentados a seguir.
Modelo conceitual
Modelo de dados de alto nível ou projeto conceitual. É o modelo mais pró-
ximo do cliente e usuário final. Os elementos entidades, atributos e relaciona-
mentos são alguns dos itens definidos nesta fase. Um exemplo deste modelo é 
o chamado Modelo Entidade-relacionamento, conhecido como MER. Assim 
sendo, o MER é apenas um modelo conceitual, mas possui um diagrama concei-
tual, uma ferramenta chamada DER (Diagrama Entidade-relacionamento), 
que permite a representação gráfica do modelo conceitual.
Modelo lógico
Modelo de dados representativo, de implementação ou projeto lógico. 
Os dados são mostrados usando estrutura de registro. Os modelos de dados 
relacional, hierárquico e de rede são exemplos deste modelo. O modelo ló-
gico é implementado com detalhes mais técnicos, levando em conta algumas 
limitações e utiliza recursos como nomenclaturas e adequação de padrão. Nes-
sa fase, há a preocupação com itens do tipo, atributos do tipo chave, normaliza-
ção, integridade referencial, entre outras. O modelo lógico é criado baseado na 
modelagem de dados criada no processo anterior, ou seja, modelo conceitual.
BANCO DE DADOS 19
Banco de dados - Unidade 1_A5.indd 19 09/09/19 09:54
Modelo físico
Modelo de dados de baixo nível ou projeto físico. Descreve os dados do 
modelo anterior para armazenamento no computador, abrangendo o formato 
dos registros e os caminhos de acesso aos dados. No modelo físico, realizamos 
a modelagem física do modelo de banco de dados, sendo assim, levamos em 
conta as limitações impostas pelo SGBD escolhido. Usamos uma sequência de 
comandos executados em linguagem SQL (Structured Query Language), para a 
criação dos artefatos do banco de dados, por exemplo, criarmos tabelas, es-
truturas, ligações e finalmente a criação do banco de dados. O modelo físico 
é criado baseado na modelagem de dados criada no processo anterior, ou seja, 
modelo lógico.
O Diagrama 1 ilustra a hierarquia desses modelos para a modelagem de dados. 
Perceba que a modelagem é realizada após a análise de requisitos, que é uma im-
portante fase que faz parte do processo de desenvolvimento, previsto na engenha-
ria de software. Assim sendo, todas as informações necessárias referentes às regras 
de negócio e necessidades do cliente ou usuário já foram devidamente colhidas e 
assimiladas, então o processo de modelagem está pronto para ser iniciado. 
Caro aluno, no tópico a seguir e durante toda nossa disciplina, esses assuntos 
serão detalhados, exemplificados e exercitados. Abordaremos também outros 
conceitos necessários para iniciarmos uma trajetória geradora de resultados po-
sitivos no universo dos bancos de dados. Anime-se: o melhor vai começar!
DIAGRAMA 1. COMPETÊNCIAS INDIVIDUAIS BÁSICAS
Análise de
requisitos
Base de
dados
Projeto 
conceitual
Projeto 
lógico
Projeto 
físico
BANCO DE DADOS 20
Banco de dados - Unidade 1_A5.indd 20 09/09/19 09:54
Modelo Entidade-relacionamento
O Modelo Entidade-relacionamento, conhecido como MER ou ER, é um mo-
delo de dados conceitual de alto nível. Conforme já abordado anteriormente, 
seus conceitos foram defi nidos para serem os mais compreensíveis possível ao 
usuário comum. Essa é uma fase muito importante no desenvolvimento de um 
projeto de banco de dados. Foi idealizado por Peter Chen em 1976 e ainda é 
muito utilizado, tendo sofrido ajustes bem sutis, mas permanecendo ainda a sua 
essência. Peter Pin-Shan Chen é professor americano de ciência da computação, 
conhecido como criador do Modelo Entidade-relacionamento (CHEN, 1990). 
As vantagens da utilização do MER são muitas:
• Possui uma sintaxe robusta, permitindo a criação da documentação das 
informações do cliente de maneira precisa e clara;
• Facilita a comunicação, permitindo que o cliente e o usuário entendam o modelo;
• Facilidade para criar e manter o modelo;
• Pode ser integrado com várias aplicações e projetos diferentes;
• Oferece independência de implementação, pois sua utilização é universal 
e não está vinculada a um tipo de banco de dados.
Conceitos básicos
Os conceitos fundamentais do Modelo Entidade-relacionamento estão cal-
cados nos preceitos de entidades, relacionamentos e atributos. A seguir, ve-
jamos separadamente cada um deles.
Entidades
Em um de banco de dados, podemos ter uma ou várias entidades. As en-
tidades são artefatos ou objetos que organizam as informações que serão 
armazenadas e manipuladas em um banco de dados. Elas devem possuir ca-
racterísticas muito bem estabelecidas e defi nidas. 
Para Silberschatz, Korth e Sudarshan (1999) uma entidade é uma “coisa” ou um 
“objeto” do mundo real que pode ser identifi cada de forma unívoca em relação a to-
dos os outros objetos. Deve possuir identifi cação distinta e com um signifi cado pró-
prio. Também são descritas como objetos da realidade na qual se deseja manter infor-
mações. Normalmente é representado por um substantivo na descrição do negócio.
BANCO DE DADOS 21
Banco de dados - Unidade 1_A5.indd 21 09/09/19 09:54
Normalmente, uma entidade é também entendida como uma lista ou tabe-
la que receberá registros sobre um determinado assunto. Como uma tabela 
de jogos de um campeonato ou uma lista de clientes com seus dados pessoais 
e dos produtos comprados. O Diagrama 2 ilustra como as entidades podem ser 
representadas para compor a documentação e a estrutura de um projeto de 
banco de dados. Basicamente, cada entidade deverá ocupar um retângulo com 
um nome que a descreve ao centro.
DIAGRAMA 2. EXEMPLO DE REPRESENTAÇÃO DE ENTIDADES
DIAGRAMA 3. EXEMPLO DE REPRESENTAÇÃO DE ATRIBUTOS
Produto Animal Aluno CompraPagamentoCliente
Perceba que a nomenclatura usada para cada entidade normalmente é um 
substantivo. A entidade com o nome COMPRA é um substantivo, não um ver-
bo: “você realiza a compra e eu a venda”. Aqui, no caso, não é a flexão do verbo 
comprar na terceira pessoa do singular e, sim, um substantivo feminino.
Atributos
As entidades são formadas por atributos. Os atributos definem as caracte-
rísticas das entidades, ou seja, os atributos não apenas caracterizam as enti-
dades, mas as constituem em sua essência. Existem diferentes tipos de atri-
butos dependendo da natureza do campo e da necessidade planejada para a 
entidade. O Diagrama 3 ilustra a representação gráfica da entidade ALUNOS 
com seus atributos RA, nome, sexo, curso e endereço, que por sua vez é com-
posto pelos atributos rua, número e cidade.
Rua
Cidade
NúmeroNome
Sexo Endereço
RA CursoAluno
BANCO DE DADOS 22
Banco de dados - Unidade 1_A5.indd 22 09/09/19 09:54
Outra forma de representação visual das entidades e seus atributos pode 
ser vista no Diagrama 4. Nesse formato, deve-se colocar o nome da entidade 
na parte superior do retângulo, seguido de uma linha para separar os nomes 
dos atributos que devem ser descritos em seguida.
DIAGRAMA 4. REPRESENTAÇÃO ALTERNATIVA DE ENTIDADES E ATRIBUTOS
Cliente
Razão
social CNPJ
Endereço Entidadecliente Telefone
Última
compra
Atributo
Produto
Entidade
produto
CódigoDescrição
UnidadeValor unitário
Cd. Fornecedor
Agora que você já sabe o que são entidades e atributos, o que acha de rea-
lizar uma atividade simples a respeito desses dois elementos da modelagem 
de banco de dados? Em uma folha de papel, idealize quais entidade seriam 
necessárias para uma biblioteca de uma escola e quais atributos mínimos cada 
entidade precisaria. Ok? Vamos lá!
Relacionamento
Quando a entidade possui elos com uma ou várias entidades, chamamos 
esses elos de relacionamento. Esse relacionamento é realizado entre atributos 
coirmãos das diferentes entidades, desde que tais atributos sejam de mesma 
natureza e contexto; dessa forma, criamos uma relação entre as entidades. 
Esse é o conceito de relacionamento. 
Há também a possibilidade de um auto-relacionamento, quando uma en-
tidade está associada a um ou mais elemento da mesma entidade. Outro item 
importante no relacionamento são as cardinalidades envolvidas nessa relação. 
O Diagrama 5 ilustra a relação de uma entidade Médico com a entidade Pa-
cientes, sendo que o nome da relação é consulta. O assunto relacionamento 
será tratado com mais detalhes no tópico Diagrama Entidade-relacionamento. 
BANCO DE DADOS 23
Banco de dados - Unidade 1_A5.indd 23 09/09/19 09:54
DIAGRAMA 5. EXEMPLO DE RELACIONAMENTO
(1, 1) (0, n)
Médico
Consulta
Paciente
Perceba que a nomenclatura usada para defi nir o relacionamento normal-
mente é um verbo. Aqui, no caso, fl exão do verbo consultar na terceira pessoa 
do singular, não como um substantivo feminino. Ele “consulta” o médico e eu 
consulto o médico.
Aspectos avançados
Em modelagem de banco de dados, existem muitos detalhes e recursos que 
precisam ser descritos aos poucos. Não se deve tentar em um único diagrama 
resolver todos os problemas. Devemos criar diagramas mais genéricos sem 
tantos detalhes inicialmente e aumentar o nível de detalhe na medida em que 
a necessidade exige.
As entidades, os atributos e relacionamentos possuem recursos mais téc-
nicos e avançados que também introduziremos aos poucos. No momento em 
que esses recursos se façam necessários e indispensáveis, serão abordados e 
exemplifi cados para serem aplicados. As variações dos atributos e as cardinali-
dades dos relacionamentos serão descritos a seguir. 
Tipos de atributos
Existem vários tipos de atributos com características diferentes que podem 
formar uma entidade. Vejamos cada um deles.
• Atributos simples: atributos não divisíveis são chamados simples ou atô-
micos. Exemplos: nome, sexo, preço, CPF;
• Atributos compostos: podem ser divididos em partes com signifi cados 
independentes, como um endereço, que poderá ser composto pelos atributos 
rua, cidade, Estado e CEP. Atributos compostos podem formar uma hierarquia;
BANCO DE DADOS 24
Banco de dados - Unidade 1_A5.indd 24 09/09/19 09:54
• Atributos univalorados ou monovalorados: quando o atributo pode re-
ceber apenas um único valor. Tais atributos são chamados atributos simples 
ou univalorados. Exemplos: data de nascimento, tipo sanguíneo, cor da pele;
• Atributos multivalorados: podem receber um conjunto de valores, ou seja, 
pode haver mais de um dado a armazenar. Exemplos: telefone, e-mail, nomes dos 
dependentes, opção de cursos;
• Atributos determinantes: recebem valores exclusivos que possibilitam a 
identificação inequívoca de um registro da entidade. Exemplo: RA, número de 
matrícula, código do produto, CNPJ, RG, CPF. Alguns desses atributos podem 
ser definidos como um atributo chave da entidade, que será explicado mais 
adiante, mas saiba que nem todo atributo determinante necessariamente será 
um atributo chave;
• Atributos derivados e armazenados: o valor pode ser encontrado ou 
calculado relacionando dois ou mais valores de atributos ou de referên-
cia. Exemplo: a idade de uma pessoa pode ser determinada pela data de 
nascimento registrada em outro atributo, um atributo armazenado, com a 
data atual que não precisa estar armazenada no banco de dados. O atribu-
to que armazenará a idade da pessoa é um atributo derivado. Isso quer 
dizer que não necessariamente um atributo derivado precise ficar alojado 
no banco de dados ocupando espaço, sendo que, quando necessário, pode 
ser encontrado ou calculado. 
Outra situação para sua reflexão: como proceder para descobrir o número de 
dias que um cliente está em atraso com seus vencimentos? Quais seriam os atribu-
tos ou de referência envolvidos?
• Atributos chave ou identificador: um tipo especial, também chamado 
de identificador, pois garante a unicidade dos dados em uma entidade. Isso 
quer dizer que, se determinado valor foi inserido em um campo do tipo chave, 
o mesmo valor não poderá ser aceito novamente em outro registro. Exemplo: 
sendo o CPF um atributo chave, não haverá outro registro sendo inserido na 
entidade com o mesmo CPF.
EXPLICANDO
Todo campo chave é também um atributo determinante, mas nem todo 
atributo determinante precisará ser um atributo chave.
BANCO DE DADOS 25
Banco de dados - Unidade 1_A5.indd 25 09/09/19 09:54
Existem vários tipos de chaves para as entidades. Veja:
• Chave primária: seu valor identifica cada registro de forma única;
• Chave composta: é formada por mais de um atributo;
• Chave candidata: é o atributo com possibilidade de vir a se tornar uma 
chave primária;
• Chave estrangeira: quando o atributo de uma entidade é a chave primá-
ria de outra entidade com a qual ela se relaciona.
Cardinalidade
Em um relacionamento, a cardinalidade se refere ao grau do vínculo que uma 
entidade mantém com outra entidade, também chamado de domínio. Vejamos 
o Diagrama 6. Perceba que a relação entre as entidades são as seguintes: 
• A entidade médico poderá ter no mínimo 0 e no máximo n pacientes em 
consulta. Já a entidade paciente poderá passar em consulta com no mínimo 1 
médico e no máximo 1;
• A leitura da cardinalidade é feita de maneira cruzada, ou seja, a cardinali-
dade próxima à entidade da esquerda é referente à relação com a entidade da 
direita e vice-versa;
• Essa notação poderia ser simplificada para 1 do lado do médico e n do lado 
do paciente, ou seja, o paciente passa por consulta com apenas 1 médico, já o 
médico pode ter n pacientes (inclusive nenhum). 
• Vejam que essa relação é conhecida na definição das regras do negócio, 
durante a análise de requisitos, conforme já exposto anteriormente, aqui na 
modelagem apenas se aplica àquilo que já foi levantado.
DIAGRAMA 6. EXEMPLO DE CARDINALIDADE
Médico PacienteConsulta
(1, 1)
Cardinalidade
(0, n)
BANCO DE DADOS 26
Banco de dados - Unidade 1_A5.indd 26 09/09/19 09:54
A aplicação prática dos relacionamentos, cardinalidade e outros detalhes 
serão abordados no tópico a seguir.
Diagrama Entidade-relacionamento
Como defi nido anteriormente, o 
Diagrama Entidade-relacionamento, 
conhecido como DER, é uma repre-
sentação gráfi ca de um modelo con-
ceitual. Muitas vezes é tratado como 
sinônimo do modelo conceitual, já que 
o modelo pode se tornar abstrato de-
mais e difi cultaria muito o processo 
de desenvolvimento geral do sistema. 
Dessa forma, quando se está defi nin-
do o modelo conceitual, o mais prático, muitas vezes, é já ir criando a repre-
sentação gráfi ca do modelo, ou seja, o DER. O diagrama facilita muito a comu-
nicação entre os envolvidos na equipe de desenvolvimento, pois oferece uma 
linguagem comum utilizada tanto pelo analista, responsável por levantar os 
requisitos e regras de negócio, os desenvolvedores, responsáveis por imple-
mentar aquilo que foi modelado e até mesmo o cliente e usuário fi nal.
No DER, originalmente, no modelo proposto por Chen (1990), as entidades 
são representadas por retângulos, seus atributos por elipses e os relaciona-
mentos por losangos, ligados por linhas e contendo também uma marcação de 
cardinalidade (Diagrama 7). 
Um formato mais moderno e usual propôs a troca das elipses que repre-
sentam os atributos e passaram a utilizar o formato utilizadona UML (Unifi ed 
Modeling Language, “linguagem unifi cada de modelagem”), em que os atributos 
são descritos dentro da própria entidade, fazendo com que o diagrama seja 
mais legível e fácil de ser entendido (Diagrama 8). Esse formato também se 
aproxima mais do modelo lógico, que será visto posteriormente.
Vale ressaltar que nem sempre será necessário construir Diagramas de En-
tidades-relacionamentos com todos os atributos. Muitas vezes bastam apenas 
as entidades e a indicação de relacionamentos sem nenhum atributo.
BANCO DE DADOS 27
Banco de dados - Unidade 1_A5.indd 27 09/09/19 09:55
DIAGRAMA 7. EXEMPLO DO DER PROPOSTO POR CHEN
DIAGRAMA 8. EXEMPLO ALTERNATIVO DO DER
AlugaVeículos
Modelo
Marca
Chassi
CPF
Nome
Fone
Cliente
Tais diagramas foram idealizados com simbologias simples com objetivo de 
serem criados inclusive à mão ou com o mínimo de recursos de softwares, mas 
existem ferramentas CASE (Computer-Aided Software Engineering, “engenharia 
de software assistida por computador”), que, entre outras coisas, permitem-
-nos criar o DER e outros diagramas sem muito esforço. É possível, inclusive, 
gerar o modelo lógico a partir do modelo conceitual do DER e até mesmo o 
modelo físico.
AlugaVeículos
Marca
Modelo
Chassi
Cor
Ano
Km
Cliente
CPF
Nome
Telefone
Endereço
Data
Última 
locação
BANCO DE DADOS 28
Banco de dados - Unidade 1_A5.indd 28 09/09/19 09:55
Segue uma lista de algumas dessas ferramentas. Existem ferramentas on-
line que não necessitam de instalação, como é caso da Draw.io e o Lucidchart:
• brModelo: versão gratuita de código livre;
• Astah: a versão completa é paga;
• MySQL Workbench: solução completa e gratuita;
• DBDesigner 4: solução paga. Requer registro on-line;
• Draw.io: solução on-line e gratuita;
• MS Visio: solução paga. Versão acadêmica gratuita;
• Lucidchart: solução on-line e gratuita.
Na produção dos diagramas aqui em nossos exemplos, vamos optar pela 
ferramenta brModelo (2019) para confeccionarmos o DER, por ser muito sim-
ples de usar e instalar. É uma ferramenta gratuita de código aberto, além de 
ser uma solução brasileira. Para fazer as atividades previstas da disciplina, você 
poderá escolher essa ou alguma outra se desejar. No site do desenvolvedor, já 
mencionado, você terá instruções sobre a instalação e utilização, mas também 
existem vários vídeos postados na internet mostrando a instalação e uso da 
ferramenta. No entanto, faremos um passo a passo para sua instalação e utili-
zação inicial. É muito simples.
Passos para instalação da ferramenta brModelo
• Primeiro: baixe o brModelo direto do site do desenvolvedor. A Fig. 3 mos-
tra onde acessar o link para iniciar o processo de download;
Figura 3. Print de tela da ferramenta CASE para modelagem.
BANCO DE DADOS 29
Banco de dados - Unidade 1_A5.indd 29 09/09/19 09:55
• Segundo: escolha um lugar em seu computador para armazenar o arquivo 
brModelo.jar. Ele é um arquivo executável e não necessita de descompactação 
ou instalação;
• Terceiro: abra o arquivo brModelo.jar simplesmente dando um clique 
duplo. Se necessário, será solicitado a você uma atualização do ambiente 
Java, mas isso é uma tarefa comum e provavelmente seu computador já 
esteja atualizado;
• Quarto: a tela do brModelo será aberta em poucos segundos (Fig. 4). Re-
pare que aproveitamos a imagem para adicionarmos algumas legendas para 
explicações sobre a ferramenta. O processo todo não foi bem simples?
Figura 4. Print de tela da ferramenta brModelo.
Ferramentas e menu
Painel de criação
Barra de artefatos
Janelas de propriedades
e outros
Detalhando um pouco a ferramenta
Agora que temos nossa ferramenta CASE brModelo de modelagem de da-
dos instalada, vamos conhecer um pouco sobre seus recursos para podermos 
criar nossos diagramas, ok? 
Vejamos então as principais partes do editor de modelagem brModelo.
Ferramentas e menu: nessa área, entre outras coisas, você poderá salvar e abrir 
seus modelos criados ou gerar o modelo lógico a partir do seu DER criado (Fig. 5);
BANCO DE DADOS 30
Banco de dados - Unidade 1_A5.indd 30 09/09/19 09:55
Painel de criação: é área livre onde você poderá trazer seus objetos para 
construção do diagrama;
Barra de artefatos: nessa barra, você encontra todos os objetos para cons-
trução do seu diagrama. Basta clicar sobre eles e em seguida clicar em alguma 
área do painel de construção (Fig. 6). Perceba que a figura está na horizontal 
apenas para melhor apresentação e explicação.
Figura 6. Print de tela da barra de artefatos do brModelo.
Cada um desses objetos da barra de artefatos será usado para a composi-
ção dos diagramas. Para adicioná-los ao painel de criação, basta selecioná-los 
com um clique e depois clicar no local desejado para inseri-lo. Não clique e 
arraste, ou seja, não é drag-and-drop. Para mudar seus atributos, como nome e 
outros, use a janela de propriedades.
Janela de propriedade e outros: chamada de barra Inspector, é o local que 
sempre trará informação a respeito do objeto selecionado, em foco, que você está 
manipulando (Fig. 7). Dependendo do objeto, você poderá atribuir nomes aos ob-
jetos, cor, tipos e tamanhos de letras. No momento que você muda o foco, ou seja, 
clica em outro objeto, a janela traz as propriedades deste objeto.
O brModelo é um editor gráfico de modelagem, portanto, sempre que um 
objeto é inserido para a área de diagramação, ele já sugere o tamanho ideal 
para cada objeto. Para uma manter uma melhor organização e leitura, é acon-
selhável evitar que objetos fiquem de tamanho diferentes desnecessariamen-
te. Alguns símbolos podem variar um pouco na sua aparência de outras ferra-
mentas, mas não compromete a modelagem geral.
Figura 5. Print de tela da barra de ferramentas do brModelo.
BANCO DE DADOS 31
Banco de dados - Unidade 1_A5.indd 31 09/09/19 09:55
Figura 7. Print de tela da janela de propriedades do brModelo.
Dica: Para inserir o rótulo ao 
objeto (nome do objeto), utilize 
essa propriedade ou a pr priedade.
Texto, quando o objeto for de 
outro tipo.
Simbologia original utilizada na construção do DER
Os símbolos para construção do DER são os mais simples possíveis e podem 
ser criados manualmente, conforme proposto por Chen. Na construção dos 
diagramas, podem ocorrer pequenas variações de aparência, dependendo da 
ferramenta gráfica utilizada. 
Seguem os símbolos padrões e suas aplicações:
Entidade primária. Usado para definir as entidades 
fortes. São entidades que não dependem de nenhu-
ma outra para existir.
Entidade fraca. Entidades fracas são dependentes de 
outras entidades para existir. Não possuem chave pri-
mária.
Entidade associativa. Associam as instâncias de vá-
rios tipos de entidades. Elas contêm atributos volta-
dos especificamente ao relacionamento entre essas 
instâncias.
BANCO DE DADOS 32
Banco de dados - Unidade 1_A5.indd 32 09/09/19 09:55
Relacionamento. Símbolo utilizado que representa o re-
lacionamento associações entre entidades. 
Relacionamento fraco. Também chamado de relaciona-
mento de identificação, são relacionamentos entre um 
tipo de entidade fraca e seu proprietário, ou seja, uma en-
tidade primária.
Atributo. Atributos definem as características das enti-
dades. Em algumas ferramentas CASE ele é uma elipse 
ou um círculo pequeno, com o nome do atributo escrito 
ao lado, como o caso do brModelo (Fig. 8).
Atributo multivalorado. São atributos capazes de rece-
ber vários valores. Exemplo: um atributo para represen-
tar vários telefones. 
Atributo derivado. São atributos onde o valor pode ser 
calculado a partir de valores de outros atributos ou va-
lores de referência.
Atributo chave. Seu valor identifica cada registro de 
forma única. São atributos ou combinações de atributos 
que identificam de modo único apenas uma instância de 
uma entidade. Em algumas ferramentas CASE ele é uma 
elipse ou um pequeno círculo pintado de preto. Veja a Fig. 8.
Atributo composto. São atributosprovenientes de 
outro atributo. São divididos em partes com signifi-
cados independentes.
BANCO DE DADOS 33
Banco de dados - Unidade 1_A5.indd 33 09/09/19 09:55
A Fig. 8 ilustra um exemplo de disposição de um DER simples, porém, com-
pleto, criado na ferramenta brModelo, também para mostrar que a diagrama-
ção por ferramenta CASE pode diferenciar um pouco da simbologia original, 
mas a própria ferramenta se encarrega de dar nomes aos objetos quando es-
tão em foco.
Analisando a figura, tente levantar os seguintes elementos presentes no 
diagrama: 
Quantas entidades estão envolvidas? Quais os atributos de cada entidade? 
Há relacionamento? Se houver, qual o nome do relacionamento? Há algum atri-
buto chave ou composto? Perceba que os nomes dos elementos pouco impor-
tam, o que interessa é saber se você consegue diferenciar cada elemento.
Figura 8. Print de tela da disposição do der no brModelo.
 Criando nosso primeiro Diagrama Entidade-relacionamento (DER)
Conforme já mencionado anteriormente, modelagem de banco de dados 
depende dos requisitos de softwares e necessidades do cliente com as regras 
de negócio devidamente levantados. Então vamos propor uma situação para 
você montar seu primeiro Diagrama Entidade-relacionamento, ok? Vamos lá.
Você terá que idealizar um DER respeitando as regras de negócio estipula-
das abaixo. Idealize quais seriam as entidades para cada, seus atributos essen-
ciais e relacionamentos. Crie uma primeira versão simplificada e posteriormen-
te uma mais completa.
BANCO DE DADOS 34
Banco de dados - Unidade 1_A5.indd 34 09/09/19 09:55
Regras de negócio
Primeira situação: há uma relação nos procedimentos de consulta em um 
consultório médico que um paciente só possa ser atendido por um médico por 
consulta. Já o médico poderá ter diversos pacientes, inclusive nenhum. Faça 
um diagrama mais simplificado. Não é necessário detalhar os atributos das en-
tidades.
Segunda situação: em outra situação de relação entre entidades, o pacien-
te poderá se consultar com um ou vários médicos. O médico só será alocado 
se for para atender no mínimo um paciente. Apesar de não ser necessário para 
representar essa relação, tente criar o DER com atributos de exemplos para 
cada entidade, inclusive com atributos simples, chaves e compostos.
Sugestões de soluções 
Solução para a primeira situação: o Diagrama 9 ilustra uma possível 
solução de diagramação para a primeira situação proposta, apenas com as 
entidades e relacionamento com cardinalidade de acordo com a primeira 
situação. 
Observe que a cardinalidade adotada para a entidade paciente é de 1 para 
1, que significa que o paciente poderá ser atendido por apenas um médico, 
nem mais nem menos. Já a cardinalidade para a entidade médico, é de 0 para n, 
sugerindo que o médico poderá atender desde nenhum até n pacientes. Lem-
brando que a leitura da cardinalidade, para um entendimento mais fácil, é sem-
pre cruzada, ou seja, a cardinalidade ao lado da entidade médico diz respeito à 
entidade paciente e vice-versa.
DIAGRAMA 9. POSSÍVEL SOLUÇÃO PARA A SITUAÇÃO 1
Médico
(1, n) (1, n)
Consulta Paciente
BANCO DE DADOS 35
Banco de dados - Unidade 1_A5.indd 35 09/09/19 09:55
Solução para a segunda situação: o Diagrama 10 ilustra uma possível so-
lução de para a segunda situação proposta. Nesse caso, além das entidades, 
estão os atributos de cada uma e relacionamento com cardinalidade de acordo 
com a segunda situação.
Perceba que os atributos chaves são destacados com uma marcação pin-
tada de preto. Esse é o formato do que seria a elipse na simbologia original. O 
atributo convênio é do tipo composto. Os demais são atributos simples.
Observe que para esse caso, a cardinalidade adotada para a entidade pa-
ciente é de 1 para n, significando que o paciente poderá ser atendido por um 
médico ou mais médicos. Já a cardinalidade para a entidade médico, é de 1 para 
n, sugerindo que o médico poderá atender de um até n pacientes. Lembran-
do que a leitura da cardinalidade, para um entendimento mais fácil, é sempre 
cruzada, ou seja, a cardinalidade ao lado da entidade médico diz respeito a 
entidade paciente e vice-versa.
DIAGRAMA 10. POSSÍVEL SOLUÇÃO PARA A SITUAÇÃO 2
Convênio 1 Convênio 2
Médico
(1, n) (1, n)
CRM
Nome
ConvêniosNome
Telefone
Código
Especialidade
Consulta Paciente
Vejamos agora outro exemplo de DER.
O exemplo a seguir, Diagrama 11, demonstra de forma simplificada o pro-
cesso de devolução de livros a uma biblioteca. 
Analise o diagrama, faça anotações a respeito e depois verifique as explica-
ções são exatamente o que você entendeu, correto?
BANCO DE DADOS 36
Banco de dados - Unidade 1_A5.indd 36 09/09/19 09:55
DIAGRAMA 11. EXEMPLO DE DEVOLUÇÃO DE LIVROS PARA BIBLIOTECA
Explicando o diagrama: perceba que temos três relacionamentos. Sendo 
assim, dividimos a explicação em três itens, a seguir:
1 - Inicialmente vemos a entidade aluno se relacionando com a entidade requi-
sição com a seguinte cardinalidade 1 para 1, ou seja, o aluno só poderá ter uma 
única requisição de livros por vez. O nome desse relacionamento é “devolve”.
2- A entidade requisição está relacionada tanto com aluno quanto com a 
entidade livro. 
A relação dela com a entidade aluno também é de 1 para 1, ou seja, toda 
requisição só poderá ter um único aluno a ela vinculada. É isso mesmo que 
ocorre no mundo real, não é mesmo? Em seguida, pode-se ver que a entidade 
requisição está também relacionada com a entidade livro, em uma cardinali-
dade 1 para n, ou seja, uma requisição poderá ter um ou mais livros. o nome 
desse relacionamento é “contém”.
3- A entidade livro está relacionada tanto com a entidade requisição quanto 
com a entidade sessão. 
A relação dela com a entidade requisição é de 1 para 1, ou seja, um exem-
plar de um livro específico só pode estar em uma requisição e não em várias. 
Correto? Exemplo: “esse livro está contido em sua requisição e não em outra”.
Em seguida, vemos que a entidade livro possui uma relação “pertence” com a en-
tidade sessão com uma cardinalidade 1 para 1, ou seja, o livro só pode ficar alojado 
em uma única sessão específica.
Aluno
(1, 1) (1, 1) (1, 1) (1, n) (1, n) (1, 1)
Devolve Contém Pertence
Requisição Livro Sessão
BANCO DE DADOS 37
Banco de dados - Unidade 1_A5.indd 37 09/09/19 09:55
Olhando do lado da entidade sessão, analisamos que a cardinalidade é de 1 
para n, ou seja, uma sessão, vários livros serão pertencentes a ela. Ok? 
Lembrando que a análise da cardinalidade é mais fácil quando observa-
da de maneira cruzada.
BANCO DE DADOS 38
Banco de dados - Unidade 1_A5.indd 38 09/09/19 09:55
Sintetizando
Caro aluno, neste capítulo, iniciamos os estudos sobre banco de dados. 
Foram abordados conceitos básicos sobre o tema de forma geral, que serão 
destacados aqui. 
Na apresentação do conceito de bancos de dados, vimos tratar-se de uma 
organização eficiente dos dados armazenados e suportados por sistemas com-
putacionais, que são os SGBDs, Gerenciadores de Bancos de Dados. Bancos de 
dados são como grandes tabelas de dados muito bem projetadas e implemen-
tadas para atender as necessidades do projeto de desenvolvimento de banco 
de dados.
Na abordagem sobre modelagem de dados, ficou claro que modelar signi-
fica planejar e conceituar como ficará a estrutura e a organização dos dados 
e que essa fase só poderá ocorrer após a finalização da análise de requisitos, 
prevista no processo de desenvolvimento da engenharia de software. 
Em abstração, vimos os benefícios de tratar a modelagem em níveis diferentes 
durante os processos, o nível conceitual, lógico e físico, com a ocultação de deta-
lhes desnecessários para cada nível, para melhor entendimento desses dados por 
todos os envolvidos, durante toda a modelagem. 
Neste capítulo, foi dado um destaque ao nível conceito do processo de mo-
delagem de banco de dados, abordando o Modelo Entidade-relacionamento, co-
nhecidocomo MER, e seu Diagrama Entidade-Relacionamento, chamado de DER. 
Conclui-se, então, que o capítulo trouxe uma visão geral dos bancos de da-
dos e do processo de modelagem, especificamente na fase do modelo concei-
tual, logo, você já é capaz de iniciar a primeira fase do processo de modelagem 
desenvolvendo o projeto conceitual da modelagem de dados.
Esperamos que tenha aproveitado cada conteúdo. Bons estudos!
BANCO DE DADOS 39
Banco de dados - Unidade 1_A5.indd 39 09/09/19 09:55
Referências bibliográficas
BRMODELO. Modelagem ER. Disponível em: <http://www.sis4.com/brMode-
lo/>. Acesso em: 1 mar. 2019.
CHEN, Peter. Gerenciando banco de dados. A abordagem entidade-relaciona-
mento para projeto lógico. São Paulo: McGraw-Hill, 1990.
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro: 
Elsevier, 2003.
DB-ENGINES. Knowledge base of relational and nosql database manage-
ment systems. Disponível em: <https://db-engines.com/en/ranking>. Acesso 
em: 1 de mar. 2019.
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 6. ed. São Paulo: 
Addison Wesley, 2011.
MULLER, J. R. Projeto de banco de dados - usando uml para modelagem de 
dados. São Paulo: Berkeley, 2002.
BANCO DE DADOS 40
Banco de dados - Unidade 1_A5.indd 40 09/09/19 09:55
MODELO RELACIONAL
2
UNIDADE
Banco de dados - Unidade 2_A5.indd 41 09/09/19 09:54
Objetivos da unidade
Tópicos de estudo
 Introdução ao modelo relacional;
 Projeto de banco de dados até o modelo lógico;
 Apresentar a arquitetura de sistemas de bancos de dados.
 Modelo relacional
 Conceitos básicos 
 Restrições de integridade
 Esquema relacional de um 
banco de dados
 Projeto de implementação de 
banco de dados
 Implementação de bancos de 
dados relacionais
 Sistemas de gerenciamento de 
banco de dados
 Arquitetura de sistemas de 
banco de dados
BANCO DE DADOS 42
Banco de dados - Unidade 2_A5.indd 42 09/09/19 09:54
Modelo relacional
Olá alunos! Nesta unidade iremos nos aprofundar em alguns conceitos que 
envolvem os bancos de dados relacionais, assim como abordar outros assun-
tos bem relevantes. Preparados? Então, vamos lá!
O modelo relacional é fundamentado na teoria dos conjuntos e lógica 
de predicado, que são conceitos matemáticos. Alguns dos primeiros sistemas 
comerciais de banco de dados baseados em modelo relacional dos anos 80 
foram o Oracle, MySql, Access, entre vários outros (ELMASRI; NAVATHE, 2011). 
Enquanto o modelo entidade-relacionamento é voltado para o projeto 
conceitual do banco de dados, o modelo relacional está diretamente ligado 
ao projeto lógico; assim sendo, essa fase é dependente da conclusão do pro-
jeto conceitual. 
Enfatizando, portanto, o modelo ou projeto conceitual é um modelo abs-
trato que descreve a estrutura de um banco de dados independente de um 
SGBD. Já o modelo lógico ou projeto lógico é aquele com dados que repre-
sentam a estrutura com foco em um SGBD específi co, apesar de ainda não 
ser necessária a sua utilização durante essa fase do projeto, mas, sim, na fase 
seguinte, no projeto físico.
CITANDO
“A abordagem entidade-relacionamento é voltada à modelagem de dados 
de forma independente do SGBD considerado. É adequada para constru-
ção do modelo conceitual. Já a abordagem relacional modela os dados em 
nível de SGBD relacional. Um modelo neste nível de abstração é chamado 
de modelo lógico.” (HEUSER, 2009, p. 6).
Conceitos básicos
O modelo relacional foi proposto por Edgar Frank Codd, matemático bri-
tânico e pesquisador da IBM, em um artigo acadêmico em 1970. Entre outros 
aspectos, Codd propôs representar os dados como uma coleção de relações, 
sendo que cada relação fosse representada em formato de tabelas, com colu-
nas e linhas. Ele é considerado o pai do modelo relacional, já que vários siste-
mas gerenciadores de bancos de dados nasceram dessa ideia.
BANCO DE DADOS 43
Banco de dados - Unidade 2_A5.indd 43 09/09/19 09:54
DICA
Edgard Frank Codd publicou, em 1970, o artigo A relational 
model of data for large shared data banks na ACM Ma-
gazine. A partir dessa publicação, o modelo relacional, 
inicialmente testado nos laboratórios na IBM, passou a ter 
mais credibilidade. O autor, por sua vez, continuou suas 
pesquisas sobre o modelo relacional, escrevendo diversos 
artigos sobre o tema.
O modelo relacional refere-se a três aspectos principais: aspecto estrutu-
ral, de integridade e de manipulação de dados (DATE, 2003). No aspecto 
estrutural, o banco de dados é representado como um conjunto de relações, 
similar a uma tabela, com linhas e colunas associadas. As linhas são denomi-
nadas tuplas e em cada coluna são distribuídos os atributos, como se fossem 
títulos para as colunas (ELMASRI; NAVATHE, 2011). 
Essa associação de linhas e colunas forma então uma relação. Observando 
a Tabela 1, nota-se a relação de Matriculados, composta por suas tuplas e seus 
atributos distribuídos em colunas. Lembrando que tupla refere-se aos valores 
de uma linha inteira da tabela ou um registro da tabela. Pela defi nição matemá-
tica, tupla é uma sequência ordenada e fi nita de elementos, em que cada um 
desses elementos possui um nome identifi cador e um valor. Diferentemente 
do relacionamento exposto no Quadro 1, a Tabela 1 ilustra uma tabela única, 
mas poderia ser também o produto resultante entre outras tabelas.
TABELA 1. ATRIBUTOS E TUPLAS DA RELAÇÃO MATRICULADOS
MATRICULADOS
RA Aluno Cod_Curso Nome_Curso
123450001 Bartolomeu Silva 100034 Enfermagem
123450005 Ana Soares 100040 Informática
123450009 Julia dos Santos 100034 Enfermagem
123450033 Beatriz Gomes 100050 Nutrição
123450042 Karoline Sevla 100020 Engenharia Elétrica
123450043 Lucas Arierref 100040 Informática
123450050 Margaria Alves 100034 Enfermagem
123450001123450001123450001
123450005
123450001
123450005123450005
123450009
Bartolomeu Silva
123450005
123450009
123450033
Bartolomeu Silva
123450009
123450033
Bartolomeu Silva
123450033
123450042
Bartolomeu Silva
Ana Soares 
123450033
123450042
Bartolomeu Silva
Ana Soares 
Julia dos Santos
123450042
123450043
Bartolomeu Silva
Ana Soares 
Julia dos Santos
Beatriz Gomes
123450043
123450050
Ana Soares 
Julia dos Santos
Beatriz Gomes
123450043
123450050
100034
Julia dos Santos
Beatriz Gomes
Karoline Sevla
123450050
100034
Julia dos Santos
Beatriz Gomes
Karoline Sevla
123450050
100034
100040
Beatriz Gomes
Karoline Sevla
Lucas Arierref
100040
100034
Karoline Sevla
Lucas Arierref
Margaria Alves
Enfermagem
100034
Karoline Sevla
Lucas Arierref
Margaria Alves
Enfermagem
100034
100050
Lucas Arierref
Margaria Alves
Enfermagem
Informática
100050
100020
Lucas Arierref
Margaria Alves
Enfermagem
Informática
Enfermagem
100020
Margaria Alves
Enfermagem
Informática
Enfermagem
100020
100040
Informática
Enfermagem
Nutrição
100040
Enfermagem
Nutrição
Engenharia 
100040
100034
Enfermagem
Nutrição
Engenharia 
100034
Nutrição
Engenharia 
Elétrica
Engenharia 
Elétrica
InformáticaInformática
Enfermagem
Informática
EnfermagemEnfermagemEnfermagem
BANCO DE DADOS 44
Banco de dados - Unidade 2_A5.indd 44 09/09/19 09:54
O conjunto de valores em cada coluna, ou seja, o que cada atributo é capaz 
de assumir é chamado de domínio (SILBERSCHATZ; KORTH; SUDARSHAN, 1999). 
Assim sendo, pode-se representar o domínio de um atributo por Dn, onde D é 
o domínio de um determinado atributo e n a posição do atributo na relação, ou 
seja, o número da coluna em que o atributo está alojado. Exemplifi cando: 
Na Tabela 1, pode-se ver o domínio do atributo RA na coluna 1 da relação, por-
tanto, na teoria dos conjuntos, pode ser denotado como D1, já o domínio D2 repre-
senta o atributo Aluno, D3 representa o Cod_Curso e D4 o atributo Nome_Curso. O 
Quadro 1 destaca apenas o domínio D1 com a relação de RAs cadastrados.
QUADRO 1. DOMÍNIO DO ATRIBUTO RA REPRESENTADO POR D1 DA TABELA 1
D1
123450001
123450005
123450009
123450033
123450042123450043
123450050
123450001123450001123450001
123450005
123450001
123450005
123450009
123450005
123450009
123450033
123450009
123450033
123450042
123450033
123450042
123450043
123450033
123450042
123450043
123450042
123450043
123450050
123450043
123450050123450050
Ainda na visão dos referidos autores (SILBERSCHATZ; KORTH; SUDARSHAN, 
1999), a relação em questão pode ser defi nida como um subconjunto do pro-
duto cartesiano de uma lista de domínios. Sendo assim, a relação de matri-
culados pode ser denotada por D1 x D2 x D3 x D4, ou seja, matriculados é um 
subconjunto do conjunto de todas as combinações possíveis de valores. 
Matriculados também pode ser denotado por relação r.
Podemos também denotar tn para representar as tuplas, onde n é o núme-
ro da tupla em evidência, ou seja, t1 para os valores da primeira tupla, t2 para 
a segunda, t3 para a terceira e assim por diante. Já que uma relação é um con-
junto de tuplas, podemos usar a notação matemática t r para denotar que a 
tupla t pertence à relação r.
BANCO DE DADOS 45
Banco de dados - Unidade 2_A5.indd 45 09/09/19 09:54
De igual modo, as linhas com dados de alunos que formam as tuplas podem 
ser denotadas por vn, sendo, v1 para o RA do aluno, v2 para o seu nome, v3 o códi-
go do curso e v4 o nome do curso e um determinado momento ou posição na Ta-
bela 1, como pode ser visto em destaque no Quadro 2, em que o RA 123450042 
ocupa a quinta posição da tabela, ou seja, é o quinto registro.
QUADRO 2. VALORES DE UMA TUPLA ESPECÍFICA
V1 V2 V3 V4
T5 123450042 Karoline Sevla 100020 Engenharia Elétrica123450042123450042123450042123450042 Karoline SevlaKaroline SevlaKaroline SevlaKaroline Sevla 100020100020100020 Engenharia ElétricaEngenharia ElétricaEngenharia ElétricaEngenharia ElétricaEngenharia ElétricaEngenharia Elétrica
 O Quadro 3 ilustra uma visão de um relacionamento entre tabelas no mo-
delo lógico. Como um produto desse relacionamento, e dependendo da cardina-
lidade aplicada, pode-se obter uma entidade associativa ou resultante chamada 
Matrícula, que pode ser física, formando efetivamente uma nova tabela ou ape-
nas para efeito de visualização, como em um relatório. Outras formas de repre-
sentação do modelo lógico serão apresentadas mais adiante.
É possível verifi car que a aluna Ana Soares e o aluno Lucas Arierref estão ma-
triculados no curso de Informática, graças ao relacionamento entre um atributo 
em comum nas duas tabelas. 
A tabela Aluno possui o atributo Cod_Curso que serve como chave-estran-
geira para relacionar-se com tabela Curso, que, por sua vez, possui um atributo 
correspondente, mas implementado como chave-primária. 
No caso apresentado, não é necessário que tenham o mesmo nome, mas 
devem ser idênticos em tipo e em conteúdo, para que o relacionamento permita 
o cruzamento das informações em ambas as tabelas. Perceba que o nome do 
aluno é proveniente da tabela Aluno e nome do curso da tabela Curso. É comum 
acrescentarmos o nome da tabela, ou parte do nome, à chave-estrangeira.
Exemplo: 
Um atributo chamado código de uma tabela Cliente, ao ser referenciado por ou-
tra tabela como chave-estrangeira, tem como nome ideal algo como codigo_Cliente 
ou codigo_Cli. Lembrando que as acentuações e alguns caracteres especiais não são 
permitidos – e mesmo quando são, devem ser evitados na defi nição dos nomes de 
atributos, na maioria dos bancos de dados e linguagens de programação.
BANCO DE DADOS 46
Banco de dados - Unidade 2_A5.indd 46 09/09/19 09:54
QUADRO 3. ILUSTRAÇÃO DE RELACIONAMENTOS NO MODELO LÓGICO
ALUNO
RA Aluno Cod_Curso
123450005 Ana Soares 100040
123450033 Beatriz Gomes 100050
123450042 Karoline Sevla 100020
123450043 Lucas Arierref 100040
123450050 Margaria Alves 100034
CURSO
Cod_Curso Nome_Curso Valor
100034 Enfermagem 2500,00
100040 Informática 2500,00
100050 Nutrição 2500,00
100020 Engenharia 2500,00
123450005123450005123450005
123450033
123450005
123450033
123450042
123450033
123450042
123450043
Ana Soares 
123450042
123450043
123450050
Ana Soares 
Beatriz Gomes
123450043
123450050
Ana Soares 
Beatriz Gomes
Karoline Sevla
123450043
123450050
Beatriz Gomes
Karoline Sevla
Lucas Arierref
123450050
Beatriz Gomes
Karoline Sevla
Lucas Arierref
Margaria Alves
100040
Karoline Sevla
Lucas Arierref
Margaria Alves
100040
100050
Lucas Arierref
Margaria Alves
100050
Margaria Alves
100050
100020
Margaria Alves
100020
100040100040
100034100034
100034100034
100040
100034
100040100040
100050
Enfermagem
100050
100020
Enfermagem
100020
Enfermagem
Informática
Enfermagem
Informática
Nutrição
Enfermagem
Informática
Nutrição
Engenharia
2500,00
Nutrição
Engenharia
2500,00
Engenharia
2500,00
2500,00
Engenharia
2500,00
2500,002500,00
2500,00
2500,00
2500,002500,00
RA Cod_Curso Aluno Nome_Curso
123450005 100040 Ana Soares Informática
123450033 100050 Beatriz Gomes Nutrição
123450042 100020 Karoline Sevla Engenharia
123450043 100040 Lucas Arierref Informática
123450050 100034 Margaria Alves Enfermagem
Restrições de integridade
As restrições de integridade servem para garantir a exatidão dos dados em 
um banco de dados relacional. Segundo Heuser (2009), as restrições de integri-
dade equivalem a dizer que os dados de um banco estão íntegros, signifi cando 
que eles refl etem corretamente a realidade representada pelo banco de dados 
e que são consistentes entre si. 
Há uma variação de tipos de restrições de integridade. Como exemplo, a in-
tegridade de domínio de um atributo que verifi ca se os dados são do tipo espe-
rado e permitido, como alfanumérico, numérico, data, limites para o tamanho 
do campo, se pode ter conteúdo nulo ou não. 
Tipos de restrições de integridade
Restrição de chave
Impede que uma chave-primária tenha repetições, garantindo assim a uni-
cidade dos dados no banco de dados.
BANCO DE DADOS 47
Banco de dados - Unidade 2_A5.indd 47 09/09/19 09:54
Restrição de domínio
Definir o conjunto de valores permitidos ou possíveis que um atributo pode 
ter. Também pode haver a integridade de vazios, que verifica se um campo pode 
receber um valor nulo (null) ou não.
Integridade referencial 
Uma chave-estrangeira de uma relação tem que coincidir com uma chave-
-primária da entidade principal. Nesse caso, o atributo deve ser do mesmo tipo 
e existir em ambas as tabelas, assim como o conteúdo idêntico. Por exemplo: 
em um relacionamento entre uma entidade Funcionário e Departamento, o 
código do departamento em que o funcionário trabalha deverá existir tanto na 
tabela de funcionário como na tabela de departamento. 
Poderá haver a chamada violação da integridade referencial, quando a cha-
ve-estrangeira não coincide com a chave-primária da entidade principal. O Dia-
grama 1 exemplifica a integridade referencial.
Integridade definida pelo usuário
A integridade definida pelo usuário permite definir regras próprias e espe-
cíficas voltadas ao negócio e que não se encaixam em outras categorias de 
integridade. Pode-se exemplificar restrições como: 
• Todo aluno deve estar matriculado obrigatoriamente em um curso.
• Todo dependente deve estar atrelado a um funcionário.
• Todo produto vendido precisa estar associado a um número de pedido.
• Toda nota-fiscal precisa ter no mínimo um item de venda associado a ela.
Por intermédio do relacionamento e da aplicação dos tipos de cardinalidades 
envolvidas, conseguimos determinar várias restrições de integridades. É impor-
tante notar que a forma de representar as cardinalidades pode variar de autor 
para autor, entre ferramentas CASE ou mesmo por convenção dos envolvidos na 
documentação do projeto de banco de dados, como: (1,1), (1,N), (0,1), (0,N), (N,N) 
ou (N,M). O M nem sempre é adotado e representa vários, assim como o N.
Há também a possibilidade, em algumas ferramentas CASE, de informar 
o número mínimo e o máximo entre os relacionamentos, exemplo: (1,3), que 
informa quehá um relacionamento de no mínimo e máximo, no caso, mínimo 
de 1 e máximo de 3. A vírgula ou o ponto e vírgula indicam a cardinalidade mí-
nima e máxima para uma entidade participante do relacionamento e o ponto e 
vírgula separam a cardinalidade de cada entidade relacionada. 
BANCO DE DADOS 48
Banco de dados - Unidade 2_A5.indd 48 09/09/19 09:54
No Diagrama 1, pode-se dizer que o relacionamento entre as entidades A e B 
se dá por (1,1 : 0,N), em que A pode se relacionar com B, com nenhuma ou até 
N instâncias, e B pode se relacionar com A obrigatoriamente com apenas uma 
instância de A. Nesse caso, A é uma entidade independente de B, já B é depen-
dente de ao menos uma instância de A. 
Exemplo: veja o Diagrama 1. Sendo A uma entidade Professor e B, uma 
entidade Disciplina. Segundo alguma regra de negócio estabelecida, não pode 
existir uma disciplina sem professor e só pode ser um (nesse exemplo hipoté-
tico), mas pode haver um professor sem nenhuma ou com muitas disciplinas. 
Mas isso deve ser muito bem defi nido e convencionado entre as esquipes de 
desenvolvimento durante as regras de negócio, a fi m de não existir dúvidas na 
interpretação correta dos relacionamentos.
DIAGRAMA 1. EXEMPLO DE RESTRIÇÃO DE INTEGRIDADE PROPORCIONADA POR 
NOTAÇÕES DE CARDINALIDADE – MODELO CONCEITUAL
(1,1) (0,n)A Relação B
Esquema relacional de um banco de dados
O esquema relacional é a especifi cação de um banco de dados relacional de 
maneira textual e deve ser utilizado para descrever as relações. Deve conter, no 
mínimo, a defi nição dos seguintes elementos, já apresentados anteriormente:
• Tabelas necessárias que irão compor o banco de dados;
• Atributos (colunas ou campos) de cada tabela;
• Relacionamentos entre tabelas;
• Restrições de integridade.
Na defi nição do esquema relacional, são usadas diversas notações, que po-
dem variar de um SGBD para outro. O SGBD assegura que as instâncias do ban-
co de dados estejam em conformidade com as restrições impostas no esque-
ma de banco de dados defi nido. Um esquema de banco de dados não contém 
dados, ele é apenas um esboço das tabelas do banco de dados. 
BANCO DE DADOS 49
Banco de dados - Unidade 2_A5.indd 49 09/09/19 09:54
Um esquema relacional pode ser indicado por R(A1, A2,A3,...An), em que 
R é o nome da relação e A são os atributos (ELMASRI; NAVATHE, 2011, p. 
40). No caso do Quadro 3, o esquema relacional das relações Aluno, Curso e 
Matricula fi caria assim: 
Aluno (RA, Nome, Cod_Curso)
Curso (Cord_Curso, Nome_Curso, Valor)
Matricula (RA,Cod_Curso)
EXPLICANDO
É possível defi nir o esquema relacional, tanto do modelo lógico em tabelas 
(veja o Quadro 3) ou direto do modelo conceitual (diagrama Entidade-Rela-
cionamento), desde que os atributos tenham sido especifi cados. Observe 
que no modelo lógico, não se especifi cam os tipos e características de 
cada campo. Isso é uma tarefa desenvolvida no modelo físico, muito em-
bora, algumas ferramentas CASE já tragam o modelo lógico também com 
tais informações sobre os campos, mas não é necessário que seja assim 
na defi nição do projeto lógico.
Projeto de implementação de banco de dados
Agora chegou a hora de colocarmos a mão na massa. Preparados? Iremos 
apresentar um projeto conceitual completo e no tópico seguinte, a implemen-
tação do projeto de banco de dados relacional. 
Para produção dos diagramas do projeto de banco de dados, usaremos a 
ferramenta CASE brMODELO (2019), mas lembre-se que os modelos produzidos, 
tanto o conceitual como o lógico, não necessitam de ferramentas e podem ser 
feitos manualmente apenas com um lápis e papel. 
Vale também relembrar que a idealização do modelo conceitual é baseada 
na análise de requisitos que, obviamente, já tenha sido devidamente concluída.
Apresentação e análise do modelo conceitual
O Diagrama 2 ilustra o modelo conceitual representado pelo Diagrama Enti-
dade-Relacionamento – DER de um projeto de banco de dados para o controle 
de uma biblioteca acadêmica. 
O modelo conceitual apresenta as entidades, seus atributos, relacionamen-
tos com as devidas cardinalidades e a movimentação necessária para a rotina 
empréstimo e devolução de livros. 
BANCO DE DADOS 50
Banco de dados - Unidade 2_A5.indd 50 09/09/19 09:54
Baseado no modelo conceitual, será criado o modelo lógico na sequência.
DIAGRAMA 2. DER PARA REPRESENTAR O PROJETO CONCEITUAL DO BANCO 
DE DADOS PARA CONTROLE DE BIBLIOTECA
RA
Nome
Data_devolução
Data_empréstimo
(1,1)
(0,n)
(0,1)
(1,n)
(1,n)
(1,1)
RA_Aluno
Cod_Livro
Autor
Título
Num_requisição
Multa_atraso
Cord_Curso
Turma
Solicita Devolve
Contém
Aluno
Requisição
Livro
 Entendendo o modelo conceitual apresentado 
A entidade Aluno possui quatro atributos, sendo RA seu atributo-chave. 
A entidade Requisição possui inicialmente dois atributos, sendo Num_re-
quisição a chave-primária e RA_Aluno, a chave-estrangeira. Esses dois atribu-
tos são elos com as entidades Aluno e Livro. A entidade Requisição poderá re-
ceber outros atributos referentes aos relacionamentos em que está envolvida 
ou uma nova entidade do relacionamento poderá ser produzida. Essa é uma 
definição que poderá ser definida no modelo lógico.
BANCO DE DADOS 51
Banco de dados - Unidade 2_A5.indd 51 09/09/19 09:54
A entidade Livro possui três atribu-
tos, sendo Cod_livro seu atributo-chave.
A entidade Aluno possui um rela-
cionamento solicita com a entidade 
Requisição com cardinalidade (1,1 : 
0,N), que significa que um aluno pode-
rá ter nenhuma ou várias requisições 
para retirada de livros, ou seja, cardi-
nalidade 0,N, e toda requisição só po-
derá ter um aluno como requerente 
(1,1). O relacionamento solicita possui 
um atributo de relacionamento chamado Data_empréstimo que armazenará a 
data da requisição de empréstimo. 
Esse atributo deverá ser acrescentado em alguma entidade envolvida no 
relacionamento ou ainda a criação de uma entidade exclusiva para essa fina-
lidade. Essa definição se dará no modelo lógico, mas poderia ter sido defini-
da também nesse modelo. Isso mostra que, em alguns casos, podem ocorrer 
adaptações entre o modelo conceitual e lógico, desde que não comprometa a 
coerência entre os dois modelos e principalmente que venha a comprometer o 
projeto de banco de dados como um todo.
A entidade Aluno também possui um relacionamento devolve com a en-
tidade Requisição com cardinalidade (1,1 : 1,N), que significa que um aluno 
poderá ter uma ou várias devoluções de livros, ou seja, cardinalidade 1,N, e 
toda requisição devolvida só poderá ter um aluno como responsável (1,1). O re-
lacionamento devolve possui dois atributos de relacionamento, um chamado 
Data_devolução e o outro Multa_atraso, que armazenam a data da devolução 
e, se for o caso, o valor da multa cobrada pelo atraso na entrega do emprés-
timo. Esses atributos deverão ser acrescentados em alguma entidade relacio-
nada ou ainda deverá ser criada uma entidade exclusiva para tal, conforme já 
explicado no parágrafo anterior.
A entidade Livro possui um relacionamento contém com a entidade Requi-
sição com cardinalidade (1,N : 0,1), que significa que um livro poderá não estar 
em nenhuma ou em apenas uma requisição por vez, ou seja, cardinalidade 0,1, 
e toda requisição poderá ter um ou vários livros (1,N). 
BANCO DE DADOS 52
Banco de dados - Unidade 2_A5.indd 52 09/09/19 09:54
Implementação de bancos de dados relacionais
Depois de criado o modelo conceitual, Diagrama 2, o próximo passo é a cria-
ção do modelo lógico, que envolve um diagrama com Modelo Lógico de Da-
dos, por alguns chamado de MLD, ou ainda representado na forma de tabelas 
simples com colunas e tuplas relacionadas e o esquema relacional, conforme já 
apresentado anteriormente. 
Independentemente da forma que o modelo lógico será apresentado, é neces-
sário se familiarizar com algumas nomenclaturas e passos adaptados ou mapeados 
do modelo conceitual para o modelo lógico. A Tabela 2 resume esse mapeamento.