Livro Texto - Banco de Dados

Prévia do material em texto

Banco de Dados
Banco de Dados
1ª edição
2019
Autoria
Parecerista Validador
Danilo Boechat Seufitelli
Johannes Von Lochter
*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.
4
Sumário
Sumário
Unidade 1
1. Fundamentos de Banco de Dados ............................8
Unidade 2
2. Abstração, Modelo de Dados e Modelagem de Banco 
de Dados ........................................................................23
Unidade 3
3. Projeto de Banco de Dados – Modelagem 
Conceitual ......................................................................38
Unidade 4
4. Projeto de Banco de Dados – Modelagem Lógica .54
Unidade 5
5. Normalização de Tabelas .........................................67
Unidade 6
6. Projeto de Banco de Dados – Modelagem Física (SQL 
– DDL) .............................................................................79
5
Sumário
Unidade 7
7. SQL - DML ..................................................................94
Unidade 8
8. SQL - DQL .............................................................. 106
6
Palavras do professor
Nesta disciplina, esperamos que você compreenda o quão importante é 
um banco de dados em nosso cotidiano. Afinal, os dados estão presentes 
em quaisquer ações praticadas, seja ao fazer o planejamento das contas 
do mês, seja ao utilizar grandes softwares empresariais. Esta disciplina foca 
no projeto e implementação de banco de dados. Para isso, a unidade 1 
apresentará os conceitos e fundamentos relacionados a bancos de dados, 
tais como dado, informação, sistema de banco de dados, bem como seus 
principais usuários. Em seguida, na unidade 2, estudaremos os princípios 
para concepção de modelos e os aspectos sobre a modelagem de dados 
para que seja possível representar soluções para problemas do mundo 
real em bancos de dados. Nas unidades 3, 4 e 5, detalha-se todo o pro-
cesso do projeto de um banco de dados. A unidade 6 mostra como utilizar 
as instruções SQL para implementação dos modelos. Por fim, as unidades 
7 e 8 demonstram os comandos da linguagem SQL para realização das 
operações de inclusão, exclusão, alteração e consulta aos dados armaze-
nados em um banco de dados. Para melhor aproveitamento da disciplina, 
recomendamos que você faça o uso de todo o material disponibilizado 
e não se prenda exclusivamente ao livro-texto! Ressaltamos também a 
importância de buscar outros materiais que possam complementar seus 
estudos em banco de dados.
7
Objetivos da disciplina
• Descrever os conceitos fundamentais relacionados a bancos de 
dados, incluindo dado, informação, campo, registro e tabela.
• Discutir os diferentes meios de armazenamento de dados.
• Expressar os aspectos da modelagem relacional de dados.
• Discutir e aplicar os conceitos de normalização de tabelas em 
bancos de dados relacionais.
• Projetar um banco de dados desde a fase de modelagem até a sua 
implementação.
• Empregar as instruções SQL para a implementação de bancos de 
dados.
• Aplicar as instruções SQL para manipulação de dados.
8
 1Unidade 11. Fundamentos de Banco de 
Dados 
Para iniciar seus estudos
Esta unidade apresenta a evolução histórica do banco de dados, com 
exemplos e definições, de forma a caracterizar o banco de dados relacio-
nal em termos tecnológicos. A distinção entre dados e informação tam-
bém será explicitada. Além disso, os diversos usuários de banco de dados 
serão caracterizados, de modo a ressaltar o papel de cada um deles no 
ciclo de vida de um banco de dados.
Objetivos de Aprendizagem
• Recordar a evolução histórica dos meios de armazenamento e dos 
bancos de dados. 
• Explicar o que é um banco de dados.
• Apontar os conceitos básicos, como entidade/tabela, atributo/
campo, dado e registro. 
• Diferenciar banco de dados de sistema gerenciador de banco de 
dados.
• Discutir os princípios de um sistema de banco de dados. 
• Classificar os usuários de banco de dados quanto ao seu papel.
9
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
Introdução da unidade
Hoje em dia, a população se encontra cada vez mais conectada digitalmente. As pessoas se comunicam por 
tablets e celulares, utilizam os painéis inteligentes dos carros para ter acesso a informações importantes e usam 
streaming de música e vídeo para entretenimento. A utilização de tablets e celulares aponta para a necessidade 
de acesso de dados que são armazenados em algum lugar, seja para visualizar uma página da internet, seja para 
ver as últimas publicações no aplicativo do Facebook. Os painéis inteligentes dos veículos também armazenam 
os dados antes de exibi-los, podendo esses dados – como nível de combustível e proximidade lateral de outros 
veículos – ser coletados por sensores. Com a população conectada digitalmente, acessando e gerando dados o 
tempo todo, é imprescindível que exista uma forma inteligente e segura de armazená-los.
Elmasri e Navathe (2010) trazem em seu livro outro exemplo interessante relacionado ao uso de banco de dados, 
que, para muitos, pode passar despercebido. Os supermercados utilizam sistemas integrados a bancos de dados 
para registrar o controle de vendas e o estoque de produtos (normalmente em empresas de médio a grande 
porte). Tais sistemas atualizam automaticamente o banco de dados responsável pelo estoque disponível dos 
produtos.
Exemplos que destacam a importância do uso de banco de dados não faltam. Para isso, esta unidade intro-
duz importantes conceitos afins, como banco de dados, sistemas gerenciadores de banco de dados, sistemas de 
banco de dados e os principais papéis dos usuários em banco de dados.
1.1 Evolução dos bancos de dados
O uso dos bancos de dados pode ser mais antigo do que imaginamos. A população primitiva já fazia o uso dos 
bancos de dados antes mesmo de surgirem os atuais e modernos computadores de uso pessoal. As pinturas 
rupestres, que, resumidamente, se referem a conjuntos de desenhos e símbolos encontrados em rochas e caver-
nas (FIGURA 1), podem ser considerados bancos de dados. Afinal, essas pinturas registram a história da popula-
ção primitiva antes mesmo do surgimento da língua e da escrita da forma que conhecemos hoje.
Figura 1 – Pintura de parede de arte pré-histórica na caverna neolítica Magura, na Bulgária
Fonte: SHUTTERSTOCK, 2018.
10
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
Porém, não é preciso voltar ao tempo dessa forma. Exemplos mais recentes, como anotações em papel de pão 
ou em blocos de notas (FIGURA 2), aquela velha agenda em que se anotavam os telefones de amigos e de lojas 
importantes, bloquinhos de recibos (FIGURA 3) ou quaisquer outros meios não tecnológicos que eram (ou ainda 
são) utilizados para armazenar dados, são considerados bancos de dados.
Figura 2 – Bloco de notas
Fonte: SHUTTERSTOCK, 2018.
Figura 3 – Bloco de recibos
Fonte: SHUTTERSTOCK, 2018.
Fichários ou arquivos são outro exemplo clássico de banco de dados. Os fichários nada mais são do que locais 
físicos (ex.: armários) em que se armazenam fichas. As fichas, normalmente de papel, contêm dados específicos 
de alguma organização. Esses dados, por exemplo, podem ser de clientes, de vendas, de faturamento, de controle 
de estoque, entre outros. As Figuras 4 e 5 ilustram o fichário.
11
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
Figura 4 – Fichário utilizado para armazenar fichas
Fonte: SHUTTERSTOCK, 2018.
Figura 5 – Arquivo de fichas
Fonte: SHUTTERSTOCK, 2018.
Você consegue imaginar, nos dias de hoje, alguma empresa multinacional utilizando fichá-
rios para armazenar e gerenciar seus dados? Quais seriam os problemas que o uso do fichá-
rio poderia gerar? Como pesquisare organizar milhares de registros em pastas e papéis?
12
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
Dentre os diversos problemas que o uso de fichários causa, podemos citar a demora na recuperação/obtenção de 
dados; afinal, a busca por um registro é praticamente sequencial. Outro grande problema é o acesso único, pois, 
devido às limitações físicas, apenas uma pessoa poderá manipular determinada ficha por vez, seja para consulta 
ou atualização.
Suponha que Antônio, gerente de uma loja de roupas, está com a ficha de Beatriz (cliente) para atualizar seus 
dados. Neste momento, a Beatriz chega à loja. Ao registrar sua compra, Marina, a nova vendedora da loja, iden-
tifica que Beatriz não possui uma ficha no arquivo. Com toda sua proatividade, Marina cria uma nova ficha para 
Beatriz. Após a atualização dos dados, Antônio devolve a ficha de Beatriz para o arquivo. Resultado: agora Beatriz 
possui duas fichas ativas. Ou seja, a duplicidade e/ou inconsistência dos dados (entre outros problemas) podem 
ser muito frequentes ao utilizar tais soluções para o armazenamento de dados.
Para resolver problemas como esses, surgiram os bancos de dados em ambientes computacionais. A Figura 6 
ilustra a linha do tempo de evolução dos bancos de dados computacionais. Ramakrishnan e Gehrke (2008) afir-
mam que, desde os primeiros computadores, armazenar e manipular dados têm sido as principais preocupações 
dos aplicativos. Os primeiros bancos de dados utilizados foram o banco de dados hierárquico e o banco de dados 
em rede. Porém, tais bancos de dados eram complexos, e os usuários precisavam conhecer a estrutura física de 
tais bancos para realizar uma consulta.
Ainda na década de 1970, surgiram os bancos de dados relacionais com a proposta de simplificar o uso dos ban-
cos de dados, pois eles separam a estrutura lógica e física de armazenamento dos dados. Posteriormente, vieram 
os bancos de dados orientados a objetos e objetos-relacionais, que tinham o objetivo de melhor comunicar com 
as aplicações orientadas a objetos. Porém, tais bancos de dados não tiveram muita aceitação no mercado. Além 
disso, alguns gerenciadores de banco de dados relacionais tiveram suas funcionalidades estendidas com alguns 
recursos de orientação a objetos.
Atualmente, existem outros tipos de banco de dados chamados de NoSQL, que vem do inglês Not Only SQL ou 
“Não Somente SQL”. Resumidamente, tais bancos de dados visam armazenar e recuperar melhor e mais rapida-
mente os dados criados e compartilhados na internet. Os principais bancos de dados NoSQL são: orientados a 
documentos, colunares, chave-valor e orientados a grafos. Cada um tem uma proposta diferente para armazenar 
e manipular os dados, de acordo com a necessidade das aplicações.
Figura 6 – Linha do tempo da evolução dos bancos de dados
Herárquico Relacional
Rede NoSQLOrientado
a Objetos
Objeto
Relacional
1960 1980 Hoje
Fonte: Elaborada pelo autor.
Neste livro-texto, o foco será em banco de dados relacionais, pois ainda é o banco de dados mais utilizado como 
solução de armazenamento de dados de aplicações. A seguir, serão apresentados os conceitos de banco de 
dados, SGBD e sistema de banco de dados.
13
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
1.2 Banco de dados
1.2.1 Definições
Banco de dados é uma coleção de dados operacionais usados pelas aplicações de determinada organização 
(DATE, 2016). Ramakrishnan e Gehrke (2008) descrevem os bancos de dados como uma coleção de dados que, 
de forma característica, descrevem as atividades de uma ou mais organizações que se relacionam. Para Elmasri 
e Navathe (2010), banco de dados é uma coleção de dados relacionados que possui as seguintes propriedades 
implícitas:
• Representa aspectos do mundo real (minimundo).
• É uma coleção de dados logicamente coerentes com algum significado inerente.
• É projetado, construído e instanciado (“povoado”) para uma aplicação específica.
Apesar das diversas definições que podemos encontrar, todas elas convergem para algo sim-
ples, ou seja, um banco de dados é um conjunto de dados, normalmente organizados por 
assunto, que se relacionam entre si.
Para ilustrar melhor esse conceito, pense no serviço de streaming de vídeos Netflix, que é um 
ótimo exemplo para contextualizar banco de dados. Nesse serviço, são armazenados: dife-
rentes categorias de vídeos, tais como filmes, seriados e documentários; os cadastros dos 
assinantes e suas respectivas preferências; e visualizações dos vídeos para sugestão posterior 
de conteúdo relacionado ou para cada usuário lembrar o que estava vendo.
1.2.2 Conceitos básicos
Em bancos de dados, dizemos que as entidades são abstrações do mundo real. Por exemplo, podemos abstrair 
um conjunto de veículos que compartilham características comuns (como possuir rodas, volante, portas, etc.) 
como sendo uma entidade CARRO. O conceito de entidade está associado à etapa de modelagem de um banco 
de dados. Fisicamente, os dados associados às entidades são armazenados em tabelas no banco de dados (NERY, 
2014). Em termos práticos, podemos dizer que entidades e tabelas são sinônimos. 
As entidades são caracterizadas por um conjunto de atributos. Por exemplo, uma entidade Cliente pode ser 
caracterizada pelos seguintes atributos: CPF, nome, e-mail e telefone. De modo análogo, uma tabela possui colu-
nas ou campos. Do mesmo modo que uma entidade e uma tabela, na prática, são sinônimos, uma coluna de 
uma tabela corresponde a um atributo de uma entidade.
A Tabela 1 exemplifica uma tabela física de um banco de dados para armazenar os dados dos clientes de uma 
locadora e suas respectivas locações. Note que as tabelas se relacionam pelo atributo CPF do cliente.
14
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
Tabela 1 – Banco de dados que armazena informações de clientes e suas locações
Cliente
CPF Nome E-mail Telefone
123.321.456-78 José j@gmail.com (22) 98899-5544
456.654.123-31 Maria ma@gmail.com (31) 97745-1122
879.955.815-57 Carla ca@gmail.com (11) 94415-7841
126.784.552-14 Daniela dani@gmail.com (15) 94415-7841
Locação
Cliente Data Filme Valor
456.654.123-31 05/02/2017 Homem-Aranha R$5,00
123.321.456-78 18/03/2017 Vovozona 3 R$4,50
126.784.552-14 20/02/2018 Esqueceram de mim R$4,00
Fonte: Elaborada pelo autor.
Em outras palavras, um banco de dados armazena dados relativos a um contexto específico. Os dados, por sua 
vez, são fatos que podem ser registrados e que possuem significado implícito ou explícito, como nomes, núme-
ros de telefone, endereços, locações (como na TABELA 1), entre outros (ELMASRI; NAVATHE, 2010). Tais dados 
correspondem aos valores associados aos atributos das entidades – ou colunas/campos das tabelas – e formam 
os registros.
Registro é um conjunto de dados logicamente relacionados que descrevem uma instância de uma entidade/
tabela, como, por exemplo, os dados de cada coluna associados ao cliente José (CPF: 123.321.456-78; nome: 
José; e-mail: j@gmail.com; telefone: (22) 98899-5544). Também é possível associar um registro como sendo uma 
linha de uma tabela.
É importante ressaltar que dado e informação são conceitos distintos. Apesar de serem similares e importantes 
para o conhecimento, cada termo possui uma definição apropriada. Um dado sozinho não possui significado 
relevante e não leva a alguma compreensão. Já a informação corresponde à organização e ordenação dos dados, 
de modo a dar significado e compreensão a determinado contexto.
Um banco de dados pode ser criado e mantido tanto manualmente (como as planilhas eletrônicas e fichários) 
quanto por um grupo de aplicativos que automatizam o processo de manutenção dos bancos de dados. Para isso, 
utiliza-se um sistema gerenciador de banco de dados, que será abordado a seguir.
1.3 Sistema gerenciador de banco de dados
Sistema gerenciador de banco de dados (SGBD) ou, ainda, database management system (DBMS) é uma coleção de 
programas que permite aos usuários criar, administrar e manter um banco dedados (ELMASRI; NAVATHE, 2010). 
15
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
A finalidade principal dos SGBDs é fornecer uma maneira eficiente e conveniente de recuperar as informações 
em bancos de dados (SILBERSCHATZ et al., 2013). Para Elmasri e Navathe (2010), os sistemas gerenciadores de 
banco de dados facilitam o processo de definição, construção, manipulação e compartilhamento de bancos 
de dados entre as aplicações e seus usuários.
O processo de definição de um banco de dados engloba diversas atividades, sendo uma delas especificar os tipos 
de dados de cada coluna das tabelas. Existem diversos tipos de dados; entretanto, os mais comuns são os numé-
ricos, textuais e temporais. Por exemplo, uma coluna que armazena o preço de um produto é do tipo numérico; 
uma coluna que armazena o nome de um produto é do tipo textual; e uma coluna que armazena a data de vali-
dade de um produto é do tipo temporal. Além disso, o processo de definição contempla a atividade de definir as 
estruturas dos dados, ou seja, como as tabelas serão criadas e organizadas. Por fim, outra importante atividade é 
definir as restrições associadas aos dados. Por exemplo, em uma coluna que armazena o sexo de uma pessoa, só 
serão aceitos os caracteres M ou F, sendo que M representa masculino e F representa feminino. Outro exemplo 
de restrição associada aos dados pode ser dado pelo estado civil de uma pessoa, cuja coluna só deverá aceitar 
valores como solteiro, casado, separado e viúvo.
Já a construção é o processo de armazenar os dados fisicamente (por exemplo, em um HD) a serem controlados 
pelo SGBD. É importante dizer que os SGBDs permitem que uma tabela seja armazenada em um ou vários discos 
rígidos. Essa divisão de dados pode ser útil, por exemplo, quando uma tabela contiver muitos dados (bilhões, por 
exemplo) e demandar mais de um disco para armazenar os dados. Outra situação para a divisão de dados em 
diferentes discos rígidos é quando se torna necessário aumentar a performance de um banco de dados.
A manipulação inclui funções para realizar consultas com o objetivo de recuperar dados específicos, atualizar o 
banco de dados para refletir as mudanças no minimundo ou ainda gerar relatórios a partir dos dados armazena-
dos. Por fim, o compartilhamento permite o acesso ao banco de dados por vários usuários e programas de forma 
simultânea. O compartilhamento de dados é vinculado ao papel dos usuários, pois há aqueles que podem incluir 
e remover registros, outros podem apenas visualizar, e alguns outros podem efetivamente modificar as tabelas e 
estruturas fisicamente por definição.
Os SGBDs também são utilizados com o intuito de proteger os dados, tanto em relação ao acesso indevido por 
pessoas não autorizadas quanto em relação à confiabilidade dos dados armazenados. Ou seja, um SGBD pode 
restringir o acesso aos objetos de banco de dados a somente pessoas autorizadas. Um objeto de banco de dados 
é utilizado para referenciar ou armazenar dados, tais como tabelas, colunas, credenciais de usuários, etc. Ou seja, 
os SGBDs criam, manipulam e administram os objetos de banco de dados.
Atualmente, existe uma gama de SGBDs disponíveis, como o SQL Server, MySQL, Oracle, PostgreSQL, MariaDB, 
entre outros. Porém, não é obrigatório o uso de soluções prontas para gerenciar os dados. É possível escrever os 
nossos próprios programas para gerenciar os bancos de dados. Contudo, seria preciso desenvolver sistemas bem 
complexos para essa manipulação e manutenção dos bancos de dados.
Ainda que façamos o uso das soluções prontas – como os SGBDs citados anteriormente –, normalmente seu uso 
não é de modo isolado. Ou seja, os SGBDs funcionam em conjunto com bancos de dados, bem como outros pro-
gramas de aplicação. A esse conjunto, damos o nome de sistema de banco de dados, que será abordado a seguir.
1.4 Sistema de banco de dados
O uso de banco de dados em empresas – principalmente as de médio e grande porte – não se limita apenas ao 
uso de softwares gerenciadores para manipular banco de dados. É comum que tais empresas possuam diversos 
16
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
sistemas diferentes, com seus respectivos bancos de dados, e que, em algum momento, tanto os sistemas quanto 
os bancos de dados se integrem. O banco de dados (BD) e o sistema gerenciador de banco de dados (SGBD) for-
mam o chamado sistema de banco de dados ou sistemas de banco de dados = BD + SGBD. A Figura 7 ilustra um 
sistema de banco de dados.
O SGBD e o BD são apenas alguns dos componentes de um sistema de banco de dados. 
Para o completo funcionamento, precisa-se de hardware, software, pessoas, procedimentos e 
dados! Veja mais em Rob e Coronel (2010).
Fique atento!
Figura 7 – Configuração de um sistema de banco de dados
Usuários/programadores
Aplicativos/consultas
Processador de consultas MySQL, Oracle, 
MariaDB, 
PostgreSQL, etc.Acesso aos dados
SGBD
Local de 
armazenamento 
físico dos dados
 
Metadados
 
Banco de 
dados
Fonte: Adaptada de ELMASRI; NAVATHE, 2010. p. 5.
Silberschatz et al. (2013) listam diversas aplicações representativas dos sistemas de banco de dados. São elas:
• Bancos: para informações de clientes, contas, empréstimos e operações bancárias.
• Empresas aéreas: para reservas de horários, poltronas e informações.
• Universidades: para registrar dados de alunos, cursos, notas e afins.
17
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
• Operadoras de cartão de crédito: para registrar compras efetuadas com o cartão e para emitir as fatu-
ras mensais de cobranças.
• Telecomunicação: para registrar chamadas efetuadas e recebidas, gerar os custos da ligação, manter o 
saldo atualizado, armazenar informações sobre a rede, etc.
• Finanças: para arquivar informações imobiliárias, como compra e venda de ativos financeiros (ações e 
títulos), armazenar dados de bolsa de valores, negócios online, entre outros.
• Vendas: para manter dados de clientes, produtos e compras realizadas.
• Revendedores online: para o registro das vendas, anteriormente citado, bem como a manutenção de 
avaliações de produtos feitas por clientes online.
• Indústria: para gerenciar a cadeia de suprimentos, bem como monitorar a produção de itens nas fábri-
cas, controlar o estoque de tais itens e fiscalizar o pedido dos itens.
• Recursos humanos: para manter informações sobre funcionários, incluindo seus salários, descontos 
realizados em folha de pagamento, controle de benefícios e geração de contracheques.
Ou seja, o uso de sistemas de banco de dados está presente em praticamente todas as áreas das atuais empre-
sas, sendo imprescindível a sua utilização. Caso contrário, as empresas poderão perder em competitividade, por 
exemplo, pelo simples fato de os dados não estarem acessíveis no momento certo. Afinal, um SGBD provê rápido 
acesso aos dados, além de permitir que diferentes usuários acessem os dados de modo simultâneo, entre outras 
vantagens.
Dentro desses sistemas, cada funcionário da empresa tem um papel diferente e, portanto, deve ter acesso a 
diferentes partes de um banco de dados. Por exemplo, se no processo de compras de uma empresa não existe 
necessidade de utilizar informações dos outros funcionários da empresa (recursos humanos), é natural que os 
compradores da empresa não tenham acesso aos dados dos recursos humanos. Do mesmo modo, se dentro de 
uma empresa apenas alguns funcionários são responsáveis por criar e consultar tabelas, é natural que outros 
funcionários de diferentes setores não tenham permissão para criar e manipular esses objetos.
Assim, em sistemas de bancos de dados, têm-se responsabilidades distintas para cada usuário envolvido. Tais 
usuários serão discutidos a seguir.
1.5 Usuários de banco de dados
Em sistemas de bancos de dados, é comum a existência de diversas pessoas envolvidas, desde a fase de projeto 
e implementação até a fase final, com o uso em produção. É importante destacar que os usuários dos bancos 
de dados sãodiferentes dos usuários gerenciados pelo sistema operacional cujo sistema de banco de dados é 
executado. Os usuários de banco possuem objetos de banco de dados – como tabelas, visões e resultado de con-
sultas – e podem ter privilégios concedidos (graças ao SGBD) nesses objetos. Dessa forma, cada usuário poderá 
acessar somente os objetos aos quais lhe competem. Veja a seguir os usuários de banco de dados destacados por 
Silberschatz et al. (2013), Elmasri e Navathe (2010).
1.5.1 Projetista de banco de dados
18
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
Os projetistas de banco de dados são responsáveis por identificar quais dados deverão ser armazenados em um 
banco de dados. Os projetistas analisam o minimundo, ou seja, analisam o problema a ser solucionado em nível 
de banco de dados para que consigam abstrair todos os dados e suas restrições a serem armazenados. Uma das 
funções do projetista é escolher a melhor estrutura de armazenamento para tais dados. Os projetistas também 
analisam as necessidades de cada grupo de usuários do banco de dados, de modo a especificar as visões de obje-
tos necessárias para que o banco de dados seja capaz de atender as demandas de todos os usuários. Os projetis-
tas de banco de dados costumam ser o “braço direito” dos administradores de banco de dados.
1.5.2 Administradores de banco de dados
Os sistemas de banco de dados contemplam atividades e softwares complexos, e demandam muita responsabi-
lidade ao serem manipulados. Os administradores de banco de dados ou Database Administrator (DBA) são res-
ponsáveis por administrar esses recursos. Os DBAs são encarregados de autorizar o acesso dos usuários ao banco 
e/ou aos objetos de banco de dados específicos. Outra responsabilidade inerente aos DBAs é a monitoração e 
controle do uso dos bancos de dados. Em suma, os administradores de banco de dados coordenam todas as ativi-
dades envolvidas dos sistemas de banco de dados. Para isso, é essencial que os DBAs possuam um domínio sobre 
os recursos de informação da empresa/organização, bem como suas necessidades. É importante ressaltar que os 
DBAs, em sua maioria, são profissionais especializados em determinados SGBDs e que, muitas vezes, possuem 
certificações de mercado para comprovar sua experiência.
Silberschatz et al. (2013) diz que uma das principais razões de se usar um SGBD é possuir o controle central do 
sistema. Tal controle deve ser de responsabilidade do DBA. Dentre as responsabilidades de um DBA, Silberschatz 
et al. listam as seguintes:
• Definir o esquema: o DBA cria a estrutura do banco de dados.
• Estruturar o armazenamento e definir o método de acesso.
• Modificar o esquema e a organização física: quando houver mudanças nas empresas ou quando hou-
ver demanda por melhor desempenho.
• Conceder autorização de acesso aos dados: o DBA pode conceder diferentes tipos de autorização a 
diferentes tipos de usuários. Por exemplo, um aluno não pode ter acesso de atualização ou escrita a uma 
tabela que contenha as notas de disciplinas.
• Manter rotinas: um DBA deve manter diversas rotinas para que um banco de dados funcione correta-
mente. Dentre elas, podemos citar a de realizar backups dos dados para situações em que seja preciso 
recuperar um banco de dados; verificar espaço livre para avaliar a necessidade da aquisição de um novo 
disco rígido; e monitorar tarefas em execução a fim de manter o bom desempenho.
19
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
O cotidiano de um DBA pode ser mais intenso que o esperado. Além de questões tecnoló-
gicas, os administradores de banco de dados também são responsáveis pela manutenção 
dos recursos de hardware. Os DBAs devem analisar constantemente a carga de trabalho do 
sistema de modo a identificar a necessidade de mais recursos físicos. Outra importante fun-
ção do DBA é evitar falhas de segurança e manter um bom tempo de resposta do sistema de 
banco de dados. Você pode aprofundar seu conhecimento sobre as tarefas de um DBA nos 
principais livros de banco de dados.
Saiba mais
1.5.3 Usuário final
Usuários finais são aqueles cujas profissões requerem uma interação com o banco de dados. Essa interação 
pode ser para atualização e consultas, bem como para gerar relatórios, por exemplo. Segundo Elmasri e Navathe 
(2010), há diversas categorias de usuários finais. São eles:
• Usuários casuais: são pessoas que acessam ocasionalmente o banco de dados em busca de diferentes 
informações a cada acesso. Em geral, utilizam linguagens de consulta a bancos de dados para atender 
suas demandas. Tais usuários normalmente são gerentes de nível médio a elevado ou profissionais com 
demandas ocasionais.
• Usuários iniciantes: compõem boa parte dos usuários finais. São usuários que realizam atividades 
“engessadas”, ou seja, atividades de consultas e atualizações nos bancos de dados que são padronizadas 
e já foram previamente programadas e testadas. Exemplos:
• Caixas de banco periodicamente checam os saldos das contas e relatam saques e depósitos.
• Funcionários de empresas aéreas, hotéis e locadoras checam a disponibilidade antes de atender as 
respectivas reservas.
• Os correios identificam os pacotes de modo a atualizar o banco de dados de pacotes recebidos e em 
trânsito.
• Usuários sofisticados: são engenheiros, cientistas, analistas de negócios, entre outros que se benefi-
ciam das facilidades dos SGBDs para que tenham suas complexas solicitações atendidas.
• Usuários autônomos: são usuários que mantêm um banco de dados pessoal utilizando pacotes de pro-
gramas prontos. A característica desses softwares é possuir uma interface gráfica de fácil uso. Por exem-
plo, usuários que utilizam planilhas eletrônicas.
1.6 Analistas de sistemas e programadores
20
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
Os analistas de sistemas capturam as demandas dos usuários finais – principalmente os usuários iniciantes – para 
desenvolver as especificações que atendam tais demandas. Os programadores implementam as especificações 
geradas pelos analistas. Além disso, os programadores devem testar, documentar e manter a codificação das 
demandas dos usuários finais.
1.6.1 Administrador de dados
Os usuários administradores de dados são responsáveis por todo o sistema de informação, e não apenas dos 
subsistemas automáticos de processamento de dados. Seu principal objetivo é a estratégia de negócios e seus 
reflexos nos requisitos de informação, e não a tecnologia em si; ao contrário do DBA, por exemplo, que se preo-
cupa com as manutenções preventivas, bem como com o monitoramento e garantia de aplicação das melhores 
práticas estabelecidas pelos fabricantes de SGBDs.
Em outras palavras, um administrador de dados tem como objetivo manter atualizados os modelos de dados 
de uma organização, bem como manter os modelos, as estruturas lógicas e físicas dos dados em acordo com 
as regras de negócio definidas (e atualizadas) pela organização, independentemente da tecnologia e do SGBD a 
serem utilizados.
1.6.2 Analistas de dados
São usuários que possuem capacidades em diversas áreas de conhecimento, como consulta a dados, limpeza 
dos dados, extração de informações, entre outras. Tais conhecimentos auxiliam o analista de dados (AD) a extrair 
valor dos dados armazenados e gerar insights para um negócio. O analista de dados combina habilidades técnicas 
e de negócio. A Figura 8 resume o funcionamento do sistema de banco de dados, destacando alguns dos usuá-
rios e suas interações.
21
Banco de Dados | Unidade 1 - Fundamentos de Banco de Dados 
Figura 8 – Ambiente do sistema de banco de dados
Fonte: Adaptada de ROB; CORONEL, 2010. p. 21.
Síntese da unidade
Nesta unidade, vimos que os bancos de dados são coleções de dados relacionados por assunto – por exemplo, 
redes sociais. Para facilitar a criação e manutenção desses bancos de dados, foram desenvolvidos os sistemas 
gerenciadores de banco de dados, que nada mais são que um conjunto de programas que lidamcom todos os 
processos envolvidos para criar e manter bancos de dados. Os SGBDs também são responsáveis por gerenciar a 
segurança do acesso aos dados e pela confiabilidade dos dados armazenados. O conjunto banco de dados mais 
sistemas gerenciadores de banco de dados constitui o chamado sistema de banco de dados, que se faz presente 
na maioria das organizações, principalmente as de médio e grande porte.
Por fim, vimos que existem diversos tipos de usuários que lidam direta ou indiretamente com o banco de dados. É 
importante ter essa separação de forma clara, pois o administrador de banco de dados deverá conceder diferen-
tes tipos de acesso ao banco de dados, de acordo com o papel e as necessidades de cada usuário.
22
Considerações finais
Os bancos de dados estão presentes na sociedade há muito tempo, desde 
as pinturas rupestres que registraram parte da história dos povos primi-
tivos. As pessoas buscam por maneiras de armazenar dados relevantes 
para si. Nos dias de hoje, com a rede de computadores e os vários dispo-
sitivos que nos permitem estar conectados à internet 24 horas por dia, 
os bancos de dados se tornaram cruciais para o bom funcionamento da 
vida moderna. Afinal, você já se imaginou ter que preencher um cadastro 
gigantesco todas as vezes em que for acessar alguma rede social? Com o 
uso dos bancos de dados, podemos efetuar nosso cadastro apenas uma 
vez e, então, acessar nossas contas e informações a partir de credenciais 
armazenadas.
23
 2Unidade 22. Abstração, Modelo de Dados 
e Modelagem de Banco de 
Dados
Para iniciar seus estudos
Nesta unidade, você será apresentado ao conceito de abstração no 
contexto de banco de dados. A abstração é fundamental para modelar 
problemas do mundo real e resolvê-los a nível de banco de dados. Para 
isso, também será mostrado como diferenciar modelo de dados e mode-
lagem de dados. Além disso, serão apresentadas as etapas de um pro-
jeto de banco de dados, que envolvem as fases de modelagem, projeto e 
implementação.
Objetivos de Aprendizagem
• Aplicar os conceitos de abstração para caracterizar problemas do 
mundo real em soluções de banco de dados.
• Esclarecer os conceitos de modelo de dados.
• Utilizar a modelagem de dados e entender a sua importância.
• Identificar as etapas da arquitetura de três níveis: modelagem, 
projeto e implementação de banco de dados.
24
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagem de Banco de Dados
Introdução da unidade
Nos dias atuais, o uso dos bancos de dados em vários contextos é totalmente indispensável. Isso ocorre porque os 
bancos de dados visam facilitar a manutenção de dados essenciais às organizações ou, também, ao uso pessoal.
Em contrapartida, um banco de dados mal projetado pode trazer certos prejuízos em relação ao seu uso. Tais pre-
juízos podem ocorrer devido à alta complexidade que alguns projetos de banco de dados podem conter em suas 
estruturas. O projeto de banco de dados refere-se às atividades que abordam o desenvolvimento da estrutura 
que será utilizada para armazenar e manter os dados.
Para projetar um banco de dados capaz de atender as necessidades dos usuários finais, é preciso entender a téc-
nica de abstração, os modelos de dados e como se modelar os dados. Nesta unidade, você terá a oportunidade 
de discutir essas questões, assim como aplicá-las em problemas didáticos.
2.1 Abstração
As abstrações auxiliam a entender, classificar e modelar uma realidade, ou seja, algo do mundo real que seja 
importante para os envolvidos. No caso dos bancos de dados, os envolvidos podem ser quaisquer usuários, ou 
seja, usuários finais, projetistas, analistas ou administradores de banco de dados.
Segundo Machado (2014), a abstração ou a capacidade de abstração é um processo mental utilizado para sele-
cionar determinadas características e propriedades de um conjunto de objetos ou fatos, e também para descar-
tar outras características consideradas não relevantes em certo contexto. Ou seja, a abstração é aplicada sempre 
em contextos específicos, quando determinados conjuntos de propriedades são relevantes. Já as características 
não importantes são descartadas após uma análise contextualizada.
Para exemplificar o processo de abstração, considere as seguintes figuras de carros, como ilustrado na Figura 9. 
Ao visualizar esta figura do ponto de vista de um site de venda de automóveis, interessariam as características 
de cor, número de portas, tamanho, tipo das rodas, etc.; já do ponto de vista de uma loja de aluguel de carros, é 
provável que muitas dessas características fossem ignoradas, sendo mais importantes informações como ano de 
fabricação do carro, potência, autonomia e afins. 
Figura 9 – Ilustrações de diferentes carros
Fonte: SHUTTERSTOCK, 2018.
25
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagem de Banco de Dados
Quando se fala em abstração no contexto de banco de dados, tem-se que a fonte dessas abstrações é deno-
minada minimundo. Os minimundos representam uma descrição formal de uma realidade a ser represen-
tada. Também é possível entender minimundo como uma porção da realidade captada pelo analista e que 
a organização tem interesse em observar, controlar e administrar. Devido à complexidade de alguns mini-
mundos, o analista pode optar em subdividi-los em partes menores. As partes menores de um minimundo 
são chamadas de visão do processo de negócio (MACHADO, 2014).
Para Elmasri e Navathe (2010), um minimundo – que também pode ser chamado de universo de discurso 
(UoD) – representa alguns aspectos do mundo real. Qualquer eventual mudança no minimundo reflete 
diretamente no banco de dados, ou seja, é possível dizer que o minimundo funciona como as regras de 
negócio de uma organização.
Uma característica essencial dos bancos de dados é permitir a abstração dos dados, de modo a ocultar os 
detalhes do armazenamento. Em outras palavras, os usuários utilizam os dados de um banco de dados sem 
necessariamente conhecer como esses dados são armazenados, em quais tabelas ou tipos de campo. Isso 
ocorre porque, em geral, essas informações são desnecessárias para a maioria dos usuários de banco de 
dados. O modelo de dados é a ferramenta que permite criar essa abstração, descrevendo a estrutura dos 
bancos de dados.
2.2 Modelo de dados
Um modelo de dados pode ser definido como um conjunto de conceitos e técnicas que podem ser utilizados para 
descrever a estrutura e as operações em um banco de dados (ELMASRI; NAVATHE, 2010). A busca pelo melhor 
gerenciamento de dados resultou em distintos modelos; em geral, os modelos de dados buscam suprir as falhas 
encontradas em sistemas de arquivos (ROB; CORONEL, 2010).
Neste capítulo, será apresentada uma visão geral dos principais modelos de dados em uma ordem cronológica, 
de acordo com Rob e Coronel (2010). São eles: modelo hierárquico, modelo de rede, modelo relacional, modelo 
entidade-relacionamento e modelo orientado a objetos.
2.2.1 Modelo hierárquico
Desenvolvido na década de 1960, o modelo hierárquico gerenciava uma enorme quantidade de dados prove-
nientes de complexos projetos de fabricação, como o projeto do foguete Apollo, que aterrissou na Lua em 1969.
O modelo hierárquico é determinado por uma estrutura de árvore, no sentido da raiz até as folhas. Essa estrutura 
possui os chamados níveis ou segmentos, que equivalem ao tipo de registro em um sistema de arquivos. O nível 
superior (raiz) é chamado de pai do nível imediatamente abaixo dele, que também pode ser chamado de nível 
filho. Da mesma forma, um filho pode ser pai do próximo nível imediatamente abaixo dele, e assim por diante. 
O modelo hierárquico representa um conjunto de relacionamentos um para muitos (1:N) entre um pai e seus 
filhos. É importante destacar que cada pai pode ter muitos filhos; porém, cada filho só pode possuir um pai. A 
Figura 10 ilustra um exemplo de uma estrutura hierárquica de cargos em uma empresa.
26
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagemde Banco de Dados
Figura 10 – Estrutura hierárquica
PresidenteRaiz (pai)
Nível 1 
(filhos da raiz)
Nível 2 
(filhos do nível 1)
Nível 3
(filhos do nível 2)
Gerente 
de vendas
Vendedores Caixa Auxiliar de 
produção
Auxiliar de 
compras
Gerente de 
marketing
Gerente de 
operações
Gerente 
administrativo
Diretor 
administrativo
Diretor 
comercial
Fonte: Elaborada pelo autor.
O modelo hierárquico apresenta diversas vantagens em relação aos sistemas de arquivos e serviu de base para 
os modelos de dados atuais. Porém, o modelo hierárquico era de difícil implementação e gerenciamento, além 
de não possuir independência estrutural. Outro fator crítico é que os relacionamentos de dados comuns não se 
adéquam ao formato 1:N. Tais limitações levaram os profissionais de banco de dados a se reunirem e desenvol-
verem outros modelos, como o modelo de rede.
2.3 Modelo de rede
O modelo de rede teve como principal característica a representação de relacionamentos de dados complexos 
de forma mais eficiente que o modelo hierárquico. Outro importante propósito era melhorar o desempenho dos 
bancos de dados, bem como impor um padrão a eles. A falta de um padrão foi um grande problema aos projetis-
tas de banco de dados, pois dificultava a portabilidade de projetos e aplicações.
Nesse modelo de rede, o usuário percebe o banco de dados como uma coletânea de registros que possuem o 
relacionamento um para muitos (1:N). No entanto, o modelo de rede difere do modelo hierárquico, pois permite 
que um registro tenha mais de um pai. A Figura 11 mostra um exemplo do modelo de dados em rede.
Figura 11 – Modelo de dados em rede
Conjunto Comissão
Conjunto Estoque Conjunto Linha
Conjunto Vendas Conjunto Pagamento
1:N
1:N 1:N
1:N 1:N
REPCOMERCIAL CLIENTE
PRODUTO FATURA PAGAMENTO
FAT_LINHA
Fonte: ROB; CORONEL, 2010. p. 39.
27
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagem de Banco de Dados
Neste exemplo, CLIENTE, REPCOMERCIAL, FATURA, FAT_LINHA, PRODUTO e PAGAMENTO representam os tipos 
de registro. Note que o registro FATURA, por exemplo, é filho de REPCOMERCIAL e CLIENTE, relacionamento este 
que o modelo hierárquico não permitiria.
Apesar de possuir um relacionamento que torna as consultas mais eficientes – por não depender de um único nó 
raiz para iniciar a pesquisa –, o modelo em rede ainda apresenta alguns problemas. A falta de um recurso para a 
elaboração de consultas resultava na criação de códigos para a produção de relatórios simples. Além disso, alte-
rações estruturais poderiam prejudicar os aplicativos que utilizavam o banco de dados. Por conta dos diversos 
problemas, na década de 1980, os modelos de dados hierárquicos e em rede foram amplamente substituídos 
pelo modelo relacional.
2.3.1 Modelo relacional
O modelo relacional surgiu em 1970, apresentado por Edgar F. Codd; porém, começou a ser utilizado apenas 
em 1980, com o surgimento dos bancos de dados relacionais. O modelo relacional é baseado na concepção de 
que as informações em um banco de dados podem ser consideradas como relações matemáticas. Com isso, 
elas podem ser representadas por meio de tabelas, nas quais as linhas são as ocorrências de uma entidade, e as 
colunas, seus atributos.
O relacionamento entre as tabelas se dá por meio do compartilhamento de determinado atributo que seja 
comum entre as tabelas, criando uma referência entre elas. Por exemplo, na tabela abaixo, as tabelas CORRETOR 
e CLIENTE compartilham o atributo AGENT_CODE.
Tabela 2 – Ligação de tabelas relacionais
Ligação por meio de AGENT_CODE
Nome da tabela: CORRETOR (seis primeiros atributos)
AGENT_CODE AGENT_LNAME AGENT_FNAME AGENT_INITIAL AGENT_AREACODE AGENT_PHONE
501 Alby Alex B 713 228-1249
502 Hahn Leah F 615 882-1244
503 John John T 615 123-5589
Nome da tabela: CLIENTE
CUS_CODE CUS_LNAME CUS_FNAME CUS_INITIAL
CUS_
AREACODE
CUS_PHONE
CUS_INSURE_
TYPE
AGENT_
CODE
10010 Ramas Alfred A 615 844-2573 T1 502
10011 Dunne Leona K 713 894-1238 T1 501
10012 Smith Kathy W 615 894-2285 S2 502
10013 Olowski Paul F 615 894-2180 S1 502
10014 Orlando Myron 615 222-1672 T1 501
Fonte: Adaptada de ROB; CORONEL, 2010. p. 41.
28
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagem de Banco de Dados
O modelo relacional permite a manipulação em conjuntos de dados ao invés de um único registro. As operações 
de manipulação possíveis incluem relacionar diferentes informações através de seleções e filtros feitos em uma 
linguagem de alto nível, como SQL, que foi padronizada pela American National Standard Institute (ANSI).
Dentre as principais vantagens do modelo relacional, destacam-se:
• Independência dos dados.
• Múltipla visão dos dados, ou seja, os dados podem ser acessados/visualizados de formas diferentes pelos 
usuários.
• Menor tempo de desenvolvimento.
• Maior segurança no acesso aos dados.
• Maior velocidade em consulta/atualização de dados.
• Implementação de restrições de integridade de dados.
2.4 Modelo entidade-relacionamento
São notáveis os avanços do modelo relacional em relação aos modelos hierárquicos e de rede; porém, as comple-
xas atividades de projeto demandam simplicidade conceitual. O modelo relacional necessitava de recursos para 
se transformar em uma eficiente ferramenta de projeto.
Em 1976, Peter Chen apresenta o modelo entidade-relacionamento (ER) ou MER, que se tornou um padrão para 
a modelagem de dados. O modelo ER provê recursos diagramáticos para representar visualmente as entidades e 
os relacionamentos de um banco de dados. As representações gráficas do modelo ER utilizadas para modelar os 
componentes de banco de dados são chamadas de diagramas entidade-relacionamento (DER).
Resumidamente, o modelo entidade-relacionamento é baseado nos seguintes componentes:
• Entidade – qualquer coisa do mundo real sobre o qual se deseja coletar e armazenar dados. É represen-
tada por um retângulo, com seu nome escrito no centro do retângulo. Exemplos de entidade: funcionário 
e pintor.
• Relacionamento – descreve as associações entre os dados. Normalmente, as associações ocorrem entre 
duas tabelas. Os relacionamentos são expressos geralmente por um verbo na voz ativa ou passiva. Por 
exemplo, um pintor pinta várias pinturas.
A Figura 12 mostra duas notações possíveis para diferentes tipos de relacionamento, utilizando as notações do 
modelo entidade-relacionamento. O lado esquerdo mostra a notação original apresentada por Peter Chen, e o 
lado direito, a notação pé de galinha (crow’s foot), que é mais atual. Note que a relação um para muitos (1:N) indica 
que um pintor (1) pinta várias pinturas (N), e não o contrário.
29
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagem de Banco de Dados
Figura 12 – Notações de Peter Chen e pés de galinha (crow’s foot).
Notação de Chen
PINTOR
FUNCIONÁRIO HABILIDADE
1 N
pinta
aprende
PINTURA
Relacionamento um para muitos (1:N): Um PINTOR pode pintar várias PINTURAS. Cada PINTURA é criada por 
apenas um PINTOR
Relacionamento um para muitos (N:M): Um FUNCIONÁRIO pode aprender várias HABILIDADES. Cada HABILIDADE 
pode ser aprendida por vários FUNCIONÁRIOS.
Relacionamento um para UM (1:1) Um FUNCIONÁRIO gerencia uma LOJA. Cada LOJA é gerenciada por um 
FUNCIONÁRIO.
Notação Pé de Galinha
N M
FUNCIONÁRIO LOJAgerência
1 1
pinta
PINTOR PINTURA
aprende
gerência
FUNCIONÁRIO
FUNCIONÁRIO
HABILIDADE
LOJA
Fonte: ROB; CORONEL, 2010. p. 44.
Para saber mais sobre o modelo entidade-relacionamento e suas notações, consulte os livros:
• ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 6. ed. São 
Paulo: Pearson, 2010.
• MACHADO, Felipe Nery Rodrigues. Banco de dados: projeto e implementação. São 
Paulo: Erica, 2014. ISBN Digital: 9788536518961.
Você também pode realizar pesquisas na internet sobre o modelo ER.
Saiba mais
2.5 Modelo orientado a objetos
Problemas ainda mais complexos levaram à criação de modelos de dados que pudessem representar o mundo 
real de modo mais preciso.O modelo de dados orientado a objetos (MDOO) apresenta os dados e seus relacio-
namentos de modo encapsulado, em uma estrutura única, chamada de objeto. No MDOO, o objeto inclui infor-
mações sobre os relacionamentos internos, ou seja, entre seus próprios atributos, bem como os relacionamentos 
externos, provenientes de outros objetos.
30
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagem de Banco de Dados
O modelo de dados orientado a objetos é baseado nos seguintes componentes:
• Objetos – abstrações de uma entidade do mundo real. Podem ser considerados como entidades do 
modelo entidade-relacionamento.
• Atributos – são as propriedades dos objetos. São como as colunas das tabelas do modelo ER.
• Classe – representa grupo de objetos que compartilham determinada estrutura. A classe também con-
tém os métodos, que são ações que os objetos daquela classe podem realizar. Por exemplo, um objeto da 
classe PESSOA pode possuir o método CANTAR.
• Hierarquia de classes – representa a organização semelhante ao modelo hierárquico, no qual uma 
classe possui apenas um pai. Por exemplo, as classes CLIENTE e EMPREGADO são filhas da classe PESSOA.
• Herança – determina o compartilhamento de atributos e métodos no interior da hierarquia de classes. 
No caso do exemplo anterior, as classes CLIENTE e EMPREGADO herdarão todos os atributos e métodos 
da classe PESSOA.
O modelo orientado a objetos tem seus dados e relacionamentos representados, em sua maioria, por diagramas 
de classe da linguagem de modelagem unificada (unified modeling language – UML). Para ilustrar esse modelo, 
considere a situação de um simples faturamento, em que as faturas são geradas por clientes. Cada fatura é 
expressa por uma ou mais linhas, e cada linha representa um item adquirido pelo cliente.
Para aprofundar os seus conhecimentos, existe ainda o seguinte modelo de dados: NoSQL 
ou Not Only SQL.
Fique atento!
2.6 Modelagem de dados
O projeto de um banco de dados tem como objetivo definir a estrutura do banco de dados que será utilizado para 
armazenar e gerenciar os dados dos usuários finais (RAMAKRISHNAN; GEHRKE, 2008). A modelagem de dados é 
um processo iterativo e incremental, que utiliza os modelos de dados para descrever as estruturas de armazena-
mento dos dados. O processo inicia-se com a concepção do domínio do problema, normalmente descrito pelos 
minimundos (ROB; CORONEL, 2010).
É importante destacar que, à medida que a compreensão do domínio do problema se desenvolve, o nível de 
detalhes do processo de modelagem também se expande. Se o processo de modelagem for feito com qualidade, 
o produto resultante será o esquema de dados, que se assemelha a uma “planta” que contém todas as instruções 
para a construção de um banco de dados de modo a atender as demandas dos usuários finais.
31
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagem de Banco de Dados
Um esquema de dados considerado pronto para implementação deve conter os seguintes 
artefatos:
• Descrição da estrutura dos dados.
• Regras para garantir a integridade dos dados.
• Procedimentos para manipulação dos dados que suportem a transformação de 
dados.
Fique atento!
O processo de modelagem de dados normalmente ocorre em diferentes níveis de abstração. No nível mais alto, 
há o modelo conceitual, que é utilizado para validar os requisitos de banco junto aos usuários finais. No nível 
intermediário, existe o modelo lógico, que descreve a estrutura lógica e a organização dos dados. Por fim, no 
nível mais baixo, tem o modelo físico, que descreve como os dados serão armazenados fisicamente, tornando-o 
dependente de um sistema gerenciador de banco de dados. Os usuários que utilizam os esquemas lógicos e físi-
cos são o administrador de banco de dados, analista de sistemas e os administradores de dados. A seguir, serão 
apresentados os três níveis de categoria de modelo de dados.
2.7 Categorias de modelo de dados
Nesta unidade, serão definidas as categorias de modelo de dados utilizadas para se projetar banco de dados. Em 
seguida, será discutida a independência dos dados.
2.7.1 Modelo conceitual
O modelo conceitual pode ser definido como uma descrição de um banco de dados de forma independente 
da implementação de um sistema gerenciador de banco de dados. O modelo conceitual preocupa-se com os 
dados que podem aparecer em um banco de dados, mas não define como os dados serão armazenados (HEUSER, 
2009). Segundo Elmasri e Navathe (2010), o modelo conceitual oculta os detalhes de implementação física e 
explora a descrição das entidades e seus relacionamentos.
A técnica mais utilizada para a realização da modelagem conceitual é o uso do modelo entidade-relacionamento 
(ER). Como resultado da modelagem conceitual utilizando o modelo ER, temos o esquema conceitual. Normal-
mente, esse esquema é representado pelo diagrama entidade-relacionamento (DER), como mostrado na Figura 
13. As entidades são representadas pelos retângulos, e as propriedades das entidades são representadas pelas 
32
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagem de Banco de Dados
linhas que saem dos retângulos. Os atributos identificadores de uma entidade são representados por círculos 
pretos, e os não identificadores são representados por círculos brancos.
Figura 13 – Exemplo de esquema conceitual
preço
Produto
descrição
n 1
código
Tipo de
produto 
descrição
código
Fonte: HEUSER, 2009. p. 17.
O esquema apresentado na Figura 13 descreve um banco de dados para armazenar os dados sobre produtos, 
tais como o código, a descrição e o preço, bem como o tipo de produto ao qual está associado, por meio de um 
código e de uma descrição. Esse esquema pode ser utilizado para validar, junto ao usuário final, os requisitos de 
banco de dados, ou seja, o esquema conceitual apresenta uma visão global dos requisitos do usuário.
Uma das principais vantagens do modelo conceitual é justamente a produção de uma visão macro do sistema 
de fácil compreensão. Além disso, o modelo conceitual é independente de hardware e software, ou seja, qualquer 
alteração de hardware ou software não causa impactos no projeto de banco de dados a nível conceitual. Para Rob 
e Coronel (2010), é comum encontrar o termo projeto lógico para a tarefa de se criar um esquema conceitual 
que possa ser utilizado em qualquer SGBD.
2.8 Modelo lógico
O próximo nível do projeto de um banco de dados é o modelo lógico. Este modelo, ao contrário do modelo 
conceitual, depende do tipo de implementação física de um banco de dados. Por exemplo: um SGBD relacio-
nal armazena dados relacionais; um SGBD orientado a objetos armazena dados orientados a objetos; um SGBD 
hierárquico armazena dados do modelo hierárquico de dados; e assim por diante. Portanto, nessa etapa, não é 
preciso saber qual será o sistema gerenciador de banco de dados a ser utilizado (ex.: Oracle, MariaDB, MySQL, 
etc.); porém, é preciso conhecer o tipo de dados armazenados pelo SGBD escolhido.
O modelo lógico representa a estrutura do banco de dados da forma como ele será manipulado pelos sistemas 
gerenciadores de banco de dados. Aqui, será considerado o modelo relacional de dados para o projeto de banco 
33
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagem de Banco de Dados
de dados. Neste caso, o modelo lógico deve mapear as entidades provenientes do modelo conceitual para as 
estruturas do modelo relacional. Em outras palavras, as entidades expressas em um esquema conceitual são 
mapeadas para tabelas no esquema lógico.
No modelo lógico, os tipos de dados, bem como suas restrições de domínio, referencial ou definida pelos usuá-
rios, também são considerados. A Figura 14 ilustra o esquema lógico subsequente ao esquema conceitual da 
Figura 13.
Figura 14 – Esquema lógico
Produto Tipo Produto
PK PKcódigo INT codTipo INT
descrição VARCHAR(50)descrição VARCHAR (100)
preço FLOAT
FK codTipo INT
Fonte: Adaptadade HEUSER, 2009.
Se houver uma modificação no tipo de software de banco de dados, será preciso alterar também o esquema 
lógico, pois o modelo lógico é dependente do tipo do SGBD escolhido. Em contrapartida, o modelo lógico é inde-
pendente de hardware, pois não é afetado pela escolha do servidor em que o sistema gerenciador de banco de 
dados será instalado.
2.9 Modelo físico
O nível mais baixo da abstração dos dados corresponde ao modelo físico. Neste nível, os dados são descritos de 
acordo com o modo de armazenamento do mesmo, como discos ou fitas. O modelo físico é construído a partir 
do modelo lógico e descreve as estruturas físicas de armazenamento de dados, tais como tipos e tamanhos de 
campos, índices, domínios de preenchimento dos campos, nomenclaturas, gatilhos, etc. Sendo assim, o modelo 
físico depende da implementação específica do SGBD, dos métodos de acesso aos arquivos e dos tipos de dispo-
sitivos de armazenamento que o sistema operacional suporta.
Para ilustrar um esquema físico, considere que o sistema gerenciador de banco de dados escolhido seja o MySQL. 
Como já mencionado, este SGBD armazena dados relacionais em tabelas. O esquema físico subsequente ao 
esquema lógico expresso na Figura 14 é expresso da seguinte maneira:
34
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagem de Banco de Dados
CREATE Database Produtos;
USE Produtos;
CREATE Table TipoProduto
(
 codTipo INT PRIMARY KEY,
 descricao VARCHAR(50)
);
CREATE Table Produto
(
 codigo INT PRIMARY KEY,
 descricao VARCHAR(100),
 preco FLOAT, 
 codTipo INT,
 CONSTRAINT fktipoproduto FOREIGN KEY (codTipo) REFERENCES TipoProduto(codTipo)
);
2.10 Independência de dados
As categorias de modelo de dados divididas em três níveis auxiliam no entendimento do conceito de indepen-
dência de dados. Elmasri e Navathe (2010) definem a independência de dados como a capacidade de mudança 
de um esquema de dados em um nível inferior, sem que ele cause mudanças de esquema no nível superior mais 
próximo. Eles ainda destacam que existem dois tipos de independência de dados: a independência de dados 
lógica e a independência física de dados.
• Independência de dados lógica: é a capacidade de mudar o esquema lógico sem a necessidade de 
alterar os programas que utilizam o banco de dados. Dessa forma, os usuários são protegidos contra alte-
rações na estrutura lógica dos dados.
• Independência física de dados: o esquema físico de um banco de dados oculta detalhes sobre como os 
dados estão, de fato, armazenados no disco rígido; como exemplo, os índices e as estruturas dos arquivos. 
Logo, o esquema físico isola os usuários de alterações nos detalhes de armazenamento. Consequente-
mente, os aplicativos também não serão afetados.
A independência de dados provoca a imunidade dos programas em relação às mudanças que ocorrem nas estru-
turas de banco de dados, o que pode ser entendido como uma das maiores vantagens na utilização de um SGBD. 
O quadro 1 resume os níveis de abstração de dados e indica as dependências correspondentes.
35
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagem de Banco de Dados
Quadro 1 – Níveis de abstração de modelos de dados e suas dependências
Modelo Grau de abstração Foco Dependência
Conceitual Alto Visão geral do banco de 
dados. Independente 
de tecnologias.
Lógico Médio Representar os dados 
de acordo com o 
modelo de dados 
utilizado pelo SGBD 
escolhido.
Tipo do modelo de 
dados utilizado pelo 
SGBD.
Físico Baixo Definir as estruturas 
físicas dos dados, bem 
como seus tipos e 
restrições.
Implementação física 
do SGBD.
Fonte: Adaptado de ROB; CORONEL, 2010. p. 56.
As categorias de modelo de dados são semelhantes aos conceitos de arquitetura em três 
níveis definidos pelos principais autores de banco de dados. Por isso, é recomendado que 
você leia mais sobre a arquitetura de três níveis nos livros Sistemas de banco de dados, de 
Elmasri e Navathe (2010), e Sistemas de gerenciamento de banco de dados, de Rama-
krishnan e Gehrke (2010).
Fique atento!
Síntese da unidade
Nesta unidade, foi explorado o conceito de abstração de dados, que é fundamental para se modelar um banco 
de dados. Além disso, foi discutido como as necessidades dos usuários costumam ser expressas e o que são os 
chamados minimundos ou universos de discurso.
Os modelos de dados são utilizados para a abstração de um ambiente de dados real e complexo. Projetistas 
de banco de dados se comunicam com os programadores de sistemas ou os usuários de aplicação através dos 
modelos de dados. Os componentes básicos para uma boa modelagem de dados são entidades, atributos, rela-
cionamentos e restrições.
Nesta unidade, também foram discutidos os diversos modelos de dados existentes, dos mais antigos e já obso-
letos até os mais modernos; são eles: o modelo hierárquico, em rede, relacional, entidade-relacionamento e o 
modelo orientado a objetos. Existem outros modelos, ainda mais novos, que não foram abordados nesta uni-
dade, pois o foco é o projeto de sistemas de banco de dados relacionais.
36
Banco de Dados | Unidade 2 - Abstração, Modelo de Dados e Modelagem de Banco de Dados
O projeto de um banco de dados tem como etapa fundamental a modelagem de dados a partir do momento em 
que se é definido o modelo de dados que será utilizado. Porém, foi discorrido que a etapa de modelagem pode 
ser categorizada em três etapas: a modelagem conceitual, que visa obter um esquema de alto nível da solução 
de banco de dados; a modelagem lógica, que foca na organização lógica dos dados, bem como em suas restri-
ções e domínio de acordo com o tipo do sistema gerenciador de banco de dados que será utilizado; e por fim, a 
modelagem física, que corresponde ao conjunto de instruções que, de fato, cria as estruturas dos dados segundo 
definições da implementação física de um banco de dados (SGBD).
Por último, foi ponderado que a independência dos dados é de muita importância no contexto de sistemas de 
banco de dados. Afinal, essa independência protege as aplicações que utilizam os bancos de dados (também 
chamadas de visão dos dados) de eventuais mudanças nos esquemas lógicos dos dados.
37
Considerações finais
Os sistemas de banco de dados foram desenvolvidos com o propósito de 
facilitar, ao máximo, as operações de criação e manutenção, comparti-
lhamento, segurança e independência dos dados. Porém, se um banco 
de dados for mal projetado, pode ser que todas as vantagens e benefícios 
acabem trazendo prejuízos às organizações. 
É importante destacar que um banco de dados bem projetado e mode-
lado poderá ser reutilizado em outros contextos ou, então, ter partes de 
seu esquema reutilizado.
Também foi discutido que o modelo conceitual é independente de tecno-
logias ou modelos de dados específicos. Desta forma, é possível mapear 
um esquema conceitual para diversos modelos de dados diferentes, bem 
como promover arquiteturas híbridas para o armazenamento dos dados.
Com o crescente volume de dados criados e compartilhados na internet, 
os bancos de dados se fazem cada vez mais necessários para sua manu-
tenção. Sendo assim, tenha sempre em mente que tudo se inicia a partir 
da modelagem desses dados nos diferentes níveis de abstração: concei-
tual, lógico e físico.
38
 3Unidade 33. Projeto de Banco de Dados – 
Modelagem Conceitual
Para iniciar seus estudos
Nesta unidade, será esclarecido o funcionamento do projeto conceitual 
de um banco de dados por meio da apresentação da forma mais utilizada 
para se criar esquemas conceituais: o modelo entidade-relacionamento 
(ER). Podemos dizer que essa é a primeira fase do projeto de um banco 
de dados. Porém, o projeto conceitual é uma fase muito importante, pois 
nele extraímos todos os requisitos e exigências dos usuários.
Objetivos de Aprendizagem
• Identificar os elementos estruturais que compõem o modelo enti-
dade-relacionamento, tais como entidade, relacionamento, atri-
butos e restrições.
• Manipular o modeloentidade-relacionamento.
• Abstrair dados provenientes de minimundos para criar esquemas 
conceituais utilizando-se do diagrama entidade-relacionamento 
(DER).
39
Banco de Dados | Unidade 3 - Projeto de Banco de Dados – Modelagem Conceitual
Introdução da unidade
Todo projeto de banco de dados precisa possuir uma ideia, um ponto central; ou seja, precisa de uma represen-
tação que auxilie no entendimento do que será armazenado. Para isso, a modelagem de dados tem o objetivo de 
apresentar uma representação dos dados de uma aplicação, de forma resumida e não redundante. Em projetos 
conceituais de banco de dados, o modelo entidade-relacionamento é o mais conhecido e utilizado por projetis-
tas para representar os dados de um sistema de banco de dados.
Machado (2014) diz que atualmente o projeto de banco de dados para sistemas de aplicação não é mais uma 
tarefa a ser realizada somente por profissionais especializados em bancos de dados. Segundo o autor, os analistas 
de sistemas, mesmo que sem prévia experiência em banco de dados, utilizam as técnicas estruturadas (como o 
modelo ER) para projetar bancos de dados.
Porém, ainda que existam modelos de dados que visem à padronização da modelagem dos dados, há profissio-
nais que fazem uso de técnicas pessoais ou, então, que distorcem as técnicas existentes, criando variações em 
modelos universalmente conhecidos. Essa é uma das principais causas de falhas em projetos de banco de dados. 
Um bom projeto de banco de dados é embasado pelo uso de técnicas previamente desenvolvidas e conhecidas 
pelos projetistas de banco de dados. O uso dessas técnicas permite a validação de requisitos junto aos usuários 
finais de banco de dados – para quem os BDs são projetados – por conter esquemas simples e de fácil entendi-
mento. Outro fator importante do uso de modelos de dados conceituais é que se permite o compartilhamento de 
soluções já modeladas, visto que determinado problema pode ser comum a vários usuários.
Nesta unidade, descreveremos os conceitos da estruturação de dados e as restrições do modelo entidade-rela-
cionamento. Discutiremos também o uso do modelo ER para a criação de esquemas em projetos conceituais de 
banco de dados. Será apresentada uma notação diagramática do modelo ER para auxiliar o processo de desen-
volvimento dos esquemas conceituais, que são os diagramas entidade-relacionamento (DER).
3.1 Modelo entidade-relacionamento (ER)
O modelo entidade-relacionamento (ER) foi publicado por Peter Chen em 1976 em seu artigo 
The Entity-Relationship Model: Toward a Unified View of Data (CHEN, 1976). O modelo ER é conceitual e tem 
como objetivo representar o mundo real como entidades e seus relacionamentos com outras entidades.
Segundo Peter Chen, para se visualizar uma realidade, é preciso se basear nos relacionamentos entre as entida-
des que retratam os fatos de tal realidade. Dessa forma, tanto as entidades quanto os relacionamentos podem 
possuir atributos que auxiliam na caracterização da realidade que está sendo modelada.
A seguir, serão apresentados os componentes que compõem o modelo entidade-relacionamento em termos de 
definições e exemplos. Ao mesmo tempo, serão apresentados os componentes gráficos que representam tais 
componentes de modo gráfico. Os componentes gráficos também são chamados de diagrama entidade-rela-
cionamento (DER).
40
Banco de Dados | Unidade 3 - Projeto de Banco de Dados – Modelagem Conceitual
3.1.1 Entidade e tipos de entidades
Um dos objetos básicos que o modelo entidade-relacionamento utiliza para representar partes envolvidas de 
determinado domínio são as entidades, que representam algo do mundo real que possui uma existência inde-
pendente, seja física ou conceitualmente.
As entidades físicas são aquelas cuja existência é tangível, ou seja, elas existem e são visíveis no mundo real. 
Como exemplo de entidades físicas (FIGURA 15), podemos citar uma pessoa, um carro, um prédio ou até mesmo 
objetos como livros, roupas, perfumes, computadores, etc. Em suma, qualquer “coisa” do mundo real que possua 
uma existência física é chamada de entidade física.
Figura 15 – Exemplo de entidades do mundo real: pessoa, carro, casa e animal
Fonte: SHUTTERSTOCK, 2018.
Já as entidades conceituais – também chamadas de entidades lógicas – são aquelas que existem devido à inte-
ração com outras entidades, com uma existência conceitual, ou aquelas que fazem sentido em determinado 
contexto, porém, não existem fisicamente no mundo real. Por exemplo, uma empresa ou um curso são entidades 
lógicas. Note que não estamos falando da sede da empresa ou do curso – que normalmente estão localizados em 
construções prediais –, e sim de seus conceitos.
No modelo ER, as entidades são descritas através de substantivos concretos ou abstratos, de modo a representar 
claramente o seu papel em determinado contexto. Podemos citar, por exemplo, as entidades cliente, produto, 
venda, aluno, disciplina, curso, cargo, entre outras.
As entidades podem ser classificadas em dois diferentes tipos, de acordo com o motivo da sua existência:
• Entidades fortes: são entidades cuja existência é independente de outras entidades ou aquelas que 
representam algo do mundo real com existência própria. Por exemplo, em um contexto em que produtos 
são vendidos, os produtos vendidos são considerados como entidades fortes, pois sua existência é inde-
pendente da venda.
• Entidades fracas: são entidades cuja existência depende de outras entidades para existirem, pois, sozi-
nhas, não fazem sentido. No caso do exemplo das vendas e produtos, uma venda sem itens (produtos) 
41
Banco de Dados | Unidade 3 - Projeto de Banco de Dados – Modelagem Conceitual
não faria sentido. Logo, a entidade venda depende da entidade produto. Outro exemplo clássico para 
ilustrar entidades fracas é a entidade dependente. Filhos, cônjuge e pais, por exemplo, podem ser con-
siderados dependentes de um funcionário em uma empresa. Logo, a existência de uma instância da 
entidade dependente está sujeita à existência da instância de uma entidade funcionário. Afinal, não faria 
o menor sentido, em um contexto empresarial, a existência de um dependente sem que haja um funcio-
nário associado.
No diagrama entidade-relacionamento, uma entidade forte é representada por um retângulo, e uma entidade 
fraca é representada por um duplo retângulo. Em ambos os casos, o nome das entidades se localizam no interior 
do retângulo. A Figura 16 ilustra as entidades forte e fraca.
Figura 16 – Exemplo da representação das entidades forte e fraca
Funcionário ← Entidade forte
Entidade fraca → Dependente
Fonte: Adaptada de ELMASRI; NAVATHE, 2010, p. 38.
3.2 Atributos
Atributos são as propriedades que descrevem as entidades. Por exemplo, uma entidade Aluno possui diversas 
características comuns às suas instâncias. Essas características podem ser o nome, sobrenome, e-mail, telefone 
e número de matrícula. A notação original do modelo ER apresentada por Peter Chen representa os atributos de 
uma entidade como elipses ligadas aos retângulos das respectivas entidades. A Figura 17 ilustra uma entidade e 
seus atributos.
Figura 17 – Exemplo da representação das entidades e seus atributos
nome
sobrenome
e-mail
telefone
matrícula
Aluno
Fonte: Adaptada de MACHADO, 2014, p. 238.
42
Banco de Dados | Unidade 3 - Projeto de Banco de Dados – Modelagem Conceitual
3.2.1 Atributo identificador (chave)
Atributo identificador – também conhecido como atributo-chave ou chave primária – é o conjunto de um ou 
mais atributos que tem a finalidade de identificar exclusivamente cada instância de cada entidade. Para ilustrar 
sua importância, considere o exemplo da entidade Aluno. Dentro de uma universidade, escola ou afins, podem 
existir diversos alunos com o mesmo nome. Em contrapartida, determinados alunos, mesmo que possuam nomes 
idênticos (incluindo sobrenome), não podem possuir o mesmo número de matrícula (ou até mesmo o CPF). Logo, 
o atributo identificador visadistinguir diferentes instâncias de determinada entidade. 
No modelo entidade-relacionamento, os atributos-chave são expressos por meio de elipses; porém, possuem 
seu nome sublinhado. Pode haver casos em que uma entidade faça uso das chaves compostas, ou seja, quando é 
preciso mais de um atributo para identificar unicamente uma instância de uma entidade. Da mesma forma, sub-
linham-se todos esses atributos para indicar que são atributos identificadores, formando, assim, a chave com-
posta. A Figura 17 ilustra a notação gráfica de atributos-chave por meio do atributo matrícula, que se encontra 
sublinhado. 
3.2.2 Atributos simples e compostos
Os atributos podem ser classificados como simples e compostos. Atributo simples é um atributo que não pode 
ser dividido, pois já constitui uma unidade atômica. Por exemplo, os atributos idade, sexo, estado civil e unidade 
federativa são simples, pois não podem ser divididos.
Atributo composto, por sua vez, é aquele que pode ser subdividido em vários outros atributos. Por exemplo, con-
sidere o atributo Endereço. Sabemos que um endereço pode ser expresso por uma rua, um número, um bairro, 
uma cidade, um estado e um CEP. Da mesma forma, um atributo Telefone pode ser subdividido nos atributos 
código do país, código de área e o número do telefone propriamente dito. A Figura 18 ilustra a representação 
diagramática do atributo composto: Endereço.
Figura 18 – Exemplo da representação de atributos simples e compostos
 
Funcionário
Nome
Rua
Número
Bairro
Cidade
Sobrenome
Endereço
Fonte: Adaptada de MACHADO, 2014, p. 72.
43
Banco de Dados | Unidade 3 - Projeto de Banco de Dados – Modelagem Conceitual
3.2.3 Atributos monovalorados e multivalorados
Atributos monovalorados são aqueles que podem apenas possuir um valor. Exemplos: uma pessoa pode possuir 
apenas um número junto ao cadastro de pessoas físicas (CPF); um veículo pode possuir apenas um número de 
chassi, entre outros. 
Porém, é importante ressaltar que um atributo monovalorado não é necessariamente um atributo simples. No 
caso dos chassis automotivos, este atributo pode ser subdividido em outros atributos que são, o identificador de 
fabricante mundial (WMI), a seção descritiva do veículo (VDS) e a seção indicadora de veículo (VIS).
Atributos multivalorados são atributos que possuem ou podem possuir muitos valores. Por exemplo, uma pes-
soa pode possuir vários graus de ensino (bacharel, mestrado e doutorado) ou, ainda, vários números de telefone 
(fixo, celular e trabalho). No diagrama entidade-relacionamento, os atributos multivalorados são representados 
por uma dupla elipse. A Figura 19 ilustra o exemplo de um atributo multivalorado (telefone).
Figura 19 – Atributo multivalorado (telefone) em uma entidade
 
Funcionário
Nome
Rua
Número
Bairro
Cidade
Telefone
Endereço
Fonte: Adaptada de MACHADO, 2014, p. 74.
3.2.4 Atributos derivados e armazenados
Ao se modelar dados, pode haver casos em que dois ou mais atributos podem estar relacionados. Por exemplo, 
os atributos Idade e Data de Nascimento. Para uma entidade do tipo Pessoa, o atributo Idade pode ser calculado 
a partir do atributo Data de Nascimento, considerando a data corrente (hoje); ou seja, o atributo Idade é cha-
mado de atributo derivado, pois ele é derivado do atributo data de nascimento. O atributo data de nascimento 
(dataNascimento) é chamado de atributo armazenado, pois seu dado respectivo, de fato, estará armazenado 
no banco de dados. No diagrama entidade-relacionamento, os atributos derivados são representados por elipses 
com traços intermitentes. A Figura 20 ilustra a representação de um atributo derivado.
44
Banco de Dados | Unidade 3 - Projeto de Banco de Dados – Modelagem Conceitual
Figura 20 – Atributo derivado (idade) em uma entidade
Pessoa
Nome
Telefone Idade
Data de Nascimento
Fonte: Adaptada de ELMASRI; NAVATHE, 2010, p. 68.
3.3 Relacionamentos
Um relacionamento pode ser expresso por uma associação entre entidades. Logo, as entidades que participam 
de um relacionamento são chamadas de entidades participantes. Os relacionamentos possuem papéis, que 
são identificados pelos nomes que os descrevem. Dessa forma, é possível identificar diversos relacionamentos 
entre as mesmas entidades. 
Para se nomear os relacionamentos, normalmente são utilizados verbos em voz passiva ou voz ativa. Por exemplo, 
um Aluno frequenta uma Turma. Um Professor leciona em um Curso. Um Professor coordena um Curso. Note 
que, entre Professor e Curso, há dois relacionamentos distintos: um que indica o papel do professor como parte 
do corpo docente de um curso, e outro que mostra o papel de coordenador que um professor pode exercer em 
um curso. No DER, os relacionamentos são expressos por um losango com o nome do relacionamento no interior 
do losango. A Figura 21 ilustra o exemplo de um relacionamento entre as entidades Aluno e Turma.
Figura 21 – Relacionamento entre as entidades Aluno e Turma
FREQUENTAALUNO TURMA
N 1
Fonte: Adaptada de ELMASRI; NAVATHE, 2010, p. 58.
Os relacionamentos entre as entidades podem ocorrer em ambos os sentidos. Logo, é preciso especificar como 
podem ocorrer as interações provenientes dos relacionamentos. Por exemplo, considere um relacionamento 
entre um Aluno e um Curso, que é ditado das seguintes formas:
Um Aluno pode se matricular em apenas um Curso.
Um Curso pode conter vários Alunos.
45
Banco de Dados | Unidade 3 - Projeto de Banco de Dados – Modelagem Conceitual
Com essa especificação, podemos identificar a quantidade de instâncias de um relacionamento das quais a enti-
dade pode participar. A essa especificação é dado o nome de razão de cardinalidade ou apenas cardinalidade. A 
razão de cardinalidade para o relacionamento entre as entidades Curso e Aluno (relacionamento binário) pode 
ser expressa pela razão de cardinalidade 1:N. As possíveis razões de cardinalidade para relacionamentos binários 
são: 1:1, 1:N, N:1 e N:M. A seguir, discorreremos sobre cada uma delas; além disso, será discutido o conceito de 
participação de relacionamento.
3.3.1 Relacionamento 1:1
Um relacionamento um para um (1:1) é utilizado quando se permite apenas uma ocorrência de dada entidade 
em um relacionamento. Por exemplo, considere as entidades Empregado e Departamento e um relacionamento 
entre elas denominado Gerência. Em outras palavras, podemos dizer que um empregado gerencia apenas um 
departamento e que um departamento é gerenciado por apenas um empregado. A Figura 22 ilustra o relacio-
namento em questão.
Figura 22 – Relacionamento Gerência 1:1
EMPREGADO
e1 •
r1 d
1
d
2
d
3
e2 •
e3 •
e4 •
e5 •
e6 •
e7 •
GERÊNCIA DEPARTAMENTO
r2
r3
Fonte: ELMASRI; NAVATHE, 2010, p. 47.
3.3.2 Relacionamentos 1:N e N:1
Os relacionamentos um para muitos (1:N) e muitos para um (N:1) são análogos, visto que eles são diferencia-
dos apenas pela direção em que ocorre a restrição de participação do relacionamento. Para ilustrar melhor esse 
relacionamento, considere a Figura 23. Nesse caso, um empregado pode trabalhar apenas para 1 departamento; 
porém, um departamento pode possuir diversos empregados. Ou seja, a cardinalidade do relacionamento Empre-
gado e Departamento é N:1. Há ainda um relacionamento 1:N entre as entidades Departamento e Empregado.
46
Banco de Dados | Unidade 3 - Projeto de Banco de Dados – Modelagem Conceitual
Figura 23 – Instâncias do relacionamento TRABALHA_PARA, N:1
EMPREGADO
TRABALHA PARA
DEPARTAMENTO
e1 •
e2 •
e3 •
e4 •
e5 •
e6 •
e7 •
r1
r2
r3
r4
r5
r6
r7
d
1
d
2
d
3
Fonte: ELMASRI; NAVATHE, 2010, p. 44.
3.3.3 Relacionamento N:M
O relacionamento muitos para muitos (N:M ou N:N, dependendo do autor) ocorre quando há a possibilidade de 
ocorrência de diversas instâncias de ambas as entidades que participam do relacionamento binário.
Para ilustrar melhor esse relacionamento, considere a seguinte restrição de um minimundo: em determinada 
empresa, um empregado pode trabalhar em diversos projetos ao mesmo tempo. Cada