introdução ao banco de dados

Prévia do material em texto

Princípios Fundamentais de Banco de 
Dados
Introdução a 
Banco de Dados 
Diretor Executivo 
DAVID LIRA STEPHEN BARROS
Gerente Editorial 
CRISTIANE SILVEIRA CESAR DE OLIVEIRA
Projeto Gráfico 
TIAGO DA ROCHA
Autoria 
LEANDRO C. CARDOSO
AUTORIA
Leandro C. Cardoso 
Olá. Sou formado em Comunicação Social com habilitação em 
Design Digital e mestrado em Tecnologias da Inteligência e Design 
Digital pela PUC-SP, com uma experiência de 20 anos em direção de 
arte e criação na área. Passei por empresas como a Laureate International 
Universities — FMU | Fiam-Faam, a Universidade Anhembi Morumbi e 
o Centro Paula Souza (Fatec-Etec), como analista de Desenvolvimento 
Pedagógico, coordenador de curso técnico de Comunicação Visual no 
Centro Paula Souza; e revisor técnico e validador para curso EAD para 
clientes Laureate International Universities, DeVry Brasil, Unef, Faesf, 
Faculdade Positivo, Uninter, Platos Soluções Educacionais S.A. (Krotonn 
— Universidade Anhanguera). Além disso, sou autor de mais de 10 livros 
didáticos e um dos organizadores da Maratona de Criação e Design do 
curso de Comunicação Visual da Etec Albert Einstein. Sou apaixonado 
pelo que faço e adoro transmitir minha experiência de vida àqueles que 
estão iniciando em suas profissões. Por isso fui convidado pela Editora 
Telesapiens a integrar seu elenco de autores independentes. Estou muito 
feliz em poder ajudar você nesta fase de muito estudo e trabalho. Conte 
comigo!
ICONOGRÁFICOS
Olá. Esses ícones irão aparecer em sua trilha de aprendizagem toda vez 
que:
OBJETIVO:
para o início do 
desenvolvimento de 
uma nova compe-
tência;
DEFINIÇÃO:
houver necessidade 
de se apresentar um 
novo conceito;
NOTA:
quando forem 
necessários obser-
vações ou comple-
mentações para o 
seu conhecimento;
IMPORTANTE:
as observações 
escritas tiveram que 
ser priorizadas para 
você;
EXPLICANDO 
MELHOR: 
algo precisa ser 
melhor explicado ou 
detalhado;
VOCÊ SABIA?
curiosidades e 
indagações lúdicas 
sobre o tema em 
estudo, se forem 
necessárias;
SAIBA MAIS: 
textos, referências 
bibliográficas e links 
para aprofundamen-
to do seu conheci-
mento;
REFLITA:
se houver a neces-
sidade de chamar a 
atenção sobre algo 
a ser refletido ou dis-
cutido sobre;
ACESSE: 
se for preciso aces-
sar um ou mais sites 
para fazer download, 
assistir vídeos, ler 
textos, ouvir podcast;
RESUMINDO:
quando for preciso 
se fazer um resumo 
acumulativo das últi-
mas abordagens;
ATIVIDADES: 
quando alguma 
atividade de au-
toaprendizagem for 
aplicada;
TESTANDO:
quando o desen-
volvimento de uma 
competência for 
concluído e questões 
forem explicadas;
SUMÁRIO
Normalização de Dados ........................................................................... 10
As Formas Normais........................................................................................................................ 10
Modelo Entidade-Relacionamento ..................................................... 18
Conceitos e Definições sobre Modelos Entidade-Relacionamento .......... 18
Modelo Lógico de Dados .........................................................................30
A Importância do Modelo Lógico de Dados .............................................................. 30
Classes e Especializações de Dados ..................................................36
Especializações de Dados ....................................................................................................... 36
7
UNIDADE
03
Introdução a Banco de Dados 
8
INTRODUÇÃO
Você sabia que é importante o conhecimento dos Princípios 
Fundamentais de Banco de Dados, sendo uma das demandas da área 
de Banco de Dados, responsável por viabilizar projetos de banco de 
dados complexos e robustos? Isso mesmo. Para isso, é importante o 
conhecimento de normalização de dados, as formas normais, .......modelo 
entidade-relacionamento, modelo lógico de dados, além de compreender 
a importância do modelo lógico de dados e as classes e especializações 
de dados. Isso tudo aliada à compreensão de uma linguagem de 
programação com estrutura de consulta capaz de orquestrar todas as 
informações. Entendeu? Ao longo desta unidade letiva você vai mergulhar 
neste universo!
Introdução a Banco de Dados 
9
OBJETIVOS
Olá. Seja muito bem-vindo à Unidade 3 – Modelando dados. Nosso 
objetivo é auxiliar você no desenvolvimento das seguintes competências 
profissionais até o término desta etapa de estudos:
1. Normalizar os dados em uma base de informações.
2. Entender os modelos entidade-relacionamento e aplicar as 
técnicas de modelagem conceitual de dados.
3. Transformar um modelo entidade-relacionamento em um modelo 
lógico de dados.
4. Lidar com situações em que seja necessário aplicar técnicas mais 
aprimoradas de modelagem de dados, como especializações e 
classes de dados.
Introdução a Banco de Dados 
10
Normalização de Dados
OBJETIVO:
Ao término deste capítulo, você será capaz de entender 
como funcionam os aspectos fundamentais de um banco 
de dados. Isso será fundamental para o exercício de sua 
profissão. As pessoas que tentaram desenvolver banco 
de dados sem a devida instrução tiveram problemas ao 
normalizar dados, entre outras dificuldades. E então? 
Motivado para desenvolver esta competência? Então, 
vamos lá. Avante!.
As Formas Normais
Antes de utilizar a ferramenta propriamente dita, é necessário 
realizar a modelagem dos dados, para que seja definida uma estrutura 
adequada e que o banco de dados seja eficiente (ELMASRI; NAVATHE, 
2005). Dessa forma, o nosso próximo passo é entender como podemos 
realizar a modelagem de dados. Concorda com o que foi dito? 
O que é um modelo de dados? Existem algumas categorias de 
modelos de dados. Veja a seguir.
1. De implementação ou representativo: são caracterizados por 
dispor princípios nos quais podem ser entendidos pelos usuários, 
porém não se distancia da maneira que os dados são armazenados 
e organizados no computador.
2. Físicos ou de baixo nível: permite um olhar com mais detalhes 
sobre a maneira que os dados estão realmente armazenados no 
computador.
3. Conceituais ou de alto nível: São caracterizados como os usuários 
que entendem os dados.
Introdução a Banco de Dados 
11
Podemos entender a normalização de dados como um processo 
a partir do qual algumas regras são aplicadas para reduzir o número de 
falhas em um projeto de banco de dados. Entre essas falhas, é comum 
existir problemas como a redundância de dados em diferentes tabelas, 
assim como dados que não estão diretamente relacionados à sua tabela. 
A técnica de normalização de dados tem origem no levantamento de 
informações do mundo real: esse é o primeiro passo quando se deseja 
informatizar um negócio.
Imagine a seguinte situação: você foi contratado para informatizar 
o setor comercial de uma empresa varejista. O primeiro procedimento 
que deve ser executado é levantar os formulários de preenchimento dos 
processos internos. Normalmente, esses formulários informam a respeito 
do negócio do cliente, pois é base de origem dos dados que serão 
cadastrados no futuro banco de dados. 
Figura 1 -‒ As soluções de banco de dados, como das formas normais, têm aplicações 
práticas, por exemplo, em lojas de varejo
Fonte: Freepik.
Introdução a Banco de Dados 
12
Para solucionar possíveis problemas com o universo de dados dessa 
empresa, pode-se aplicar o que chamamos de “formas normais”. Existem 
três delas, mas algumas literaturas defendem a existência de quatro ou 
cinco formas normais. (KENT, 2011). Podemos afirmar que uma tabela está 
na primeira forma normal quando não existem tabelas aninhadas dentro 
dela. Para descobrir isso, basta se fazer a seguinte pergunta para cada um 
de seus campos:
Este campo depende de qual outro campo? 
Para estar nesta forma normal, todos os campos só podem 
depender da própria tabela.
DEFINIÇÃO:
Para entender melhor esta teoria, deve-se imaginaruma 
tabela, resultante de um formulário de lançamento de 
vendas de uma empresa de varejo. A tabela “Vendas” dessa 
empresa poderia ter, por exemplo, a seguinte estrutura de 
campos de dados:
Vendas {Código da Venda, Nome do Cliente, Endereço, 
CEP, Cidade, Estado, Telefone, Descrição do Produto, 
Quantidade, Valor Unitário, Valor Total} (DUARTE, 2016).
Por armazenar as vendas que a empresa realizou, não pode 
haver dependência de um campo com outra tabela. E isso é facilmente 
identificado quando vemos que nessa tabela existem dados como 
“Endereço” do cliente, que não depende da venda realizada, pois duas 
vendas poderão ter sido realizadas para um mesmo cliente, e o endereço 
dele ficaria repetido em várias linhas da tabela, causando uma redundância 
desnecessária de informações. 
Introdução a Banco de Dados 
13
Figura 2 -‒ Vários dados dos clientes são armazenados nos bancos de dados de uma loja de 
varejo
Fonte: Freepik.
O mesmo ocorre com outros dados do cliente, como “CEP”, 
“Telefone”, “Estado” etc. Nesse caso, a técnica de normalização recomenda 
extrair todo e qualquer campo que não dependa da tabela “Vendas” e 
adicioná-los a tabelas específicas. Assim, a normalização dessa tabela 
fará com que uma nova tabela seja criada: a tabela “Clientes”. 
Figura 3 -‒ As informações das vendas precisam fazer parte das informações coletadas nos 
bancos de dados
Fonte: Freepik.
Introdução a Banco de Dados 
14
No lugar de todos esses dados relacionados ao cliente desta venda, 
apenas o código do cliente permanecerá na tabela “Vendas”, que, como 
vimos, será a chave estrangeira da tabela “Clientes” dentro da tabela 
“Vendas”. Veja como ficarão essas tabelas após a aplicação da primeira 
forma normal:
Vendas {Código da Venda, Código do Cliente, Descrição do Produto, 
Quantidade, Cidade, Estado, Valor Unitário, Valor Total}. Clientes {Código 
do Cliente, Nome do Cliente, Endereço, CEP, Telefone}.
A normalização segue adiante, analisando outras dependências, 
não só na tabela “Vendas”, como nas outras tabelas que serão geradas 
a partir de sua normalização. Por exemplo, o que ocorreu com o cliente, 
ocorre também com os produtos, dados como “Descrição do Produto” e 
“Valor Unitário” não dependem da venda, mas sim do produto, o que faz 
surgir uma nova tabela: “Produtos”.
Figura 4 -‒ Os dados dos produtos são de extrema importância e devem ser armazenados 
nos bancos de dados, em uma loja de varejo, por exemplo
Fonte: Freepik.
Veja a seguir uma esquematização de normalização objetivando os 
produtos:
Vendas {Código da Venda, Código do Cliente, Código do Produto, 
Quantidade, Cidade, Estado, Valor Total}. Produtos {Código do Produto, 
Descrição do Produto, Valor Unitário}. Clientes {Código do Cliente, Nome 
do Cliente, Endereço, CEP, Telefone}.
Introdução a Banco de Dados 
15
Prosseguindo, vemos que, na tabela “Vendas”, a cidade depende 
do estado, pois uma cidade só pode pertencer a um estado. Por sua vez, 
o estado também depende da cidade, pois há cidades que não poderiam 
estar associadas a ele. No entanto, mais de uma cidade pode pertencer a 
um mesmo estado. Observamos, portanto, uma dependência entre dois 
campos não chaves de uma tabela, o que caracteriza uma dependência 
funcional. Nessa situação, são removidos os dois campos da tabela 
“Vendas”, deixando apenas uma chave estrangeira denominada “Código 
da Cidade”, que faz surgir uma nova tabela denominada “Cidades”.
Vendas {Código da Venda, Código do Cliente, Código do Produto, 
Código da Cidade, Quantidade, Valor Total}. Cidades {Código da Cidade, 
Cidade, Estado}. Produtos {Código do Produto, Descrição do Produto, 
Valor Unitário}. Clientes {Código do Cliente, Nome do Cliente, Endereço, 
CEP, Telefone}.
Em relação a uma tabela que está na segunda forma normal, é 
quando não existem dependências parciais entre os campos, isto é, 
quando, em uma tabela que contém uma chave composta, ou seja, uma 
sequência de campos-chaves, cada dado depende, simultaneamente, 
de todas essas chaves. No caso da tabela “Vendas”, veremos que, depois 
de todas as normalizações, ou seja, quando ela estiver inteiramente 
dentro da primeira forma normal, restarão várias chaves estrangeiras que 
comporão a sua própria chave primária. Nesse caso, os campos que não 
forem chave dessa tabela terão que depende, exclusivamente, de todo o 
conjunto de chaves.
• Vendas {Código da Venda, Código do Cliente, Código do 
Produto, Quantidade, Valor Total}.
• Cidades (Código da Cidade, Cidade, Estado).
• Produtos {Código do Produto, Descrição do Produto, Valor 
Unitário}.
• Clientes {Código do Cliente, Nome do Cliente, Endereço, CEP, 
Código da Cidade, Telefone}.
Introdução a Banco de Dados 
16
Caso o campo “Quantidade” da tabela “Vendas” seja analisado, 
veremos que ele depende de parte das chaves dessa tabela, como 
“Código da Venda”, “Código do Cliente” e “Código do Produto”. Mas o 
campo “Quantidade” não depende do “Código da Cidade”, quem depende 
deste é o cliente.
Figura 5 -‒ O campo “Quantidade” da tabela só pode estar relacionado a campos específicos, 
que estão relacionados a quantias ou valores
Fonte: Freepik.
Temos aqui uma dependência parcial, ou seja, o campo “Quantidade” 
depende de três das quatro chaves que definem a tabela “Vendas”. 
Nesse caso, elimina-se o campo “Código da Cidade” da tabela “Vendas”, 
transferindo-o para a tabela “Clientes”.
Por fim, temos a terceira forma normal, que pretende eliminar 
qualquer possibilidade de dependência transitiva. A pergunta crucial que 
se deve fazer à tabela para testar se ela já se encontra na terceira forma 
normal é a seguinte: 
Todos os campos da tabela dependem única e exclusivamente da 
chave da própria tabela? 
Caso não, temos dependências transitivas nessa tabela: esse é 
o caso do campo “Valor Total”. Este não depende da chave da tabela 
“Vendas”, mas de uma multiplicação entre dois outros campos: o “Valor 
Unitário” e a “Quantidade”. Logo, podemos eliminar esse campo de nossa 
tabela, pois a qualquer momento poderemos montar uma consulta, como 
Introdução a Banco de Dados 
17
vimos anteriormente, calculando o resultado deste valor total. Concluindo 
as três formas normais, ficaremos com a seguinte configuração das 
tabelas:
Vendas {Código da Venda, Código do Cliente, Código do Produto, 
Quantidade}. Cidades (Código da Cidade, Cidade, Estado). Produtos 
{Código do Produto, Descrição do Produto, Valor Unitário}. Clientes {Código 
do Cliente, Nome do Cliente, Endereço, CEP, Código da Cidade, Telefone}.
O resultado da normalização é fazer com que uma única tabela, que 
pode ser o retrato de um formulário identificado na fase de levantamento 
de informações sobre o mundo real do cliente, seja derivada de uma ou 
mais tabelas, todas elas livres de redundâncias e inconsistências.
RESUMINDO:
E então? Gostou do que lhe mostramos? Aprendeu mesmo 
tudinho? Agora, só para termos certeza de que você 
realmente entendeu o tema de estudo deste Capítulo, 
vamos resumir tudo o que vimos. Você deve ter aprendido 
que antes de se aprofundar na normalização de dados 
é importante compreender como os bancos de dados 
funcionam, seus conceitos fundamentais e as técnicas mais 
rudimentares de criarmos tabelas, formulários e consultas. 
Assim, temos uma visão muito acurada sobre o que é 
essa tecnologia, suas ferramentas e o modo como esses 
grupamentos de dados são atualizados e consultados, 
além do conhecimento de uma linguagem estruturada de 
consulta capaz de orquestrar tudo isso, ou seja, a Structured 
Query Language, ou Linguagem de Consulta Estruturada 
(SQL). Com esse conhecimento, podemos avançar, saindo, 
momentaneamente, do mundo dos bits e bytes, e abstrair 
um pouco os conceitos de banco de dados. Para tanto, é 
importante o entendimento de como os dados do mundo 
real vão parar nas tabelas e consultas do mundo digital, 
além de como podem ser modelados os dados desse 
mundo real, de forma que elescaibam, na medida exata, 
dentro de um banco de dados. 
Introdução a Banco de Dados 
18
Modelo Entidade-Relacionamento
OBJETIVO:
Ao término deste capítulo, você será capaz de entender o 
modelo entidade-relacionamento. Isso será fundamental 
para o exercício de sua profissão. E então? Motivado para 
desenvolver esta competência? Então, vamos lá. Avante!
Conceitos e Definições sobre Modelos 
Entidade-Relacionamento
O modelo que iremos estudar é o modelo conceitual, chamado 
modelo entidade relacionamento (MER), pelo fato de ser um modelo de 
dados conceitual de alto nível, também muito popular. 
Antes de iniciar, vamos contextualizar o que significa o MER. Em 
1976, Peter Chen, publicou um trabalho intitulado The Entity-Relationship 
Model: Toward the unified view of data, no qual definia o processo de 
modelagem de dados. Esse trabalho foi publicado e amplamente aceito. 
Após a divulgação, passou a ser considerado o referencial definitivo para 
o processo de modelagem de dados (COUGO, 1997). O MER é composto 
por uma técnica de diagramação e um conjunto de conceitos simples, 
servindo como meio de representação dos próprios conceitos por ela 
manipulados (RAMAKRISHNAN; GEHRKE, 2002)
O MER é, na realidade, um modelo conceitual de dados, cujo 
objetivo é descrever as entidades (ou objetos) envolvidos em um negócio 
ou sistema. Cada uma dessas entidades tem atributos e relacionamentos 
estabelecidos com outras entidades.
Quando pensamos em um MER, pensamos nos dados que possam 
ser consideradas fontes de informações para o negócio do nosso cliente. 
Esses dados são as entidades, como “Funcionários”, “Produtos”, “Clientes” 
etc. Você deve estar se perguntando: mas esses dados não são tabelas? 
A resposta é: não necessariamente. 
Introdução a Banco de Dados 
19
Figura 6 -‒ Os dados dos funcionários de uma empresa podem ser considerados como uma 
entidade, sendo uma fonte de informações para o MER 
Fonte: Freepik
As entidades poderão se transformar em uma ou mais tabelas 
relacionadas entre si. Mas, e os atributos? Não são os campos de dados? 
Da mesma forma, a resposta é: não necessariamente. Digamos que, ao 
passar por um processo de transformação de modelo de dados para 
banco de dados, outros campos que não aparecem como atributos do 
modelo poderão ser criados.
Ao construir um modelo conceitual de dados, temos que focar 
no desenho das principais fontes de informações. Para exemplificar, 
vamos imaginar que estamos modelando dados para um representante 
comercial que precisa informatizar a sua cadeia de vendas. A primeira 
pergunta a fazer para esse cliente é: 
Quais são as suas principais fontes de informação? 
Ele, provavelmente, irá responder que são seus clientes, 
vendedores, produtos e fornecedores. Desenhando essas entidades em 
forma de “caixinhas”, vamos espalhá-las tanto quanto possível no papel, 
conforme exemplificado na Figura 7.
Introdução a Banco de Dados 
20
Figura 7 -‒ Principais entidades do exemplo
Clientes Produtos
Vendedores Fornecedores
Fonte: Duarte (2016).
Analisando o que foi apresentado até o momento, podemos 
questionar, por exemplo: qual é a relação entre clientes e produtos? Para 
responder a essa pergunta, vamos dividi-la em partes. Primeiramente, 
um cliente pode pedir um ou mais produtos? Se sim, a relação de um 
para o outro será de um cliente para “N” produtos. Depois, invertemos a 
pergunta: um produto pode ser pedido por um ou mais clientes? Claro que 
a resposta é sim. Nesse caso, a relação de produto para cliente também é 
de um para “N”. Ou seja, a relação entre produtos e clientes se transformou 
em um relacionamento de “N” para “N”, de muitos para muitos.
Como podemos ver no diagrama a seguir, o relacionamento entre 
“Clientes” e “Produtos” é, justamente, a relação de consumo, logo, pela 
técnica de modelagem conceitual de dados, deve-se diagramar as duas 
entidades e seu relacionamento. Veja a Figura 8
Figura 8 ‒- O relacionamento entre clientes e produtos é a relação de compra ou consumo
Clientes ProdutosPEDE
N N
Fonte: Duarte (2016).
Introdução a Banco de Dados 
21
É importante, também, outros conhecimentos, por exemplo, de 
acordo com a técnica de modelagem conceitual de dados, toda vez que 
existir uma relação de “N” para “N”, uma nova entidade será interposta 
no meio dessa relação. A essa entidade damos o nome de “entidade de 
ligação”.
DEFINIÇÃO:
Entende-se por entidade de ligação o resultado do 
relacionamento de muitos para muitos (ou “N” para “N”) 
entre duas outras entidades (DUARTE, 2016)..
No caso específico da relação clientes-produtos, essa entidade de 
ligação, certamente, será o pedido de cada cliente. Logo, em vez de duas 
entidades relacionadas, teremos três. 
Figura 9 -‒ Nos bancos de dados é coletado o relacionamento entre clientes e produtos
Fonte: Freepik,
De um lado, “Clientes”, em uma relação de um para “N” com a 
entidade de ligação “Pedidos”; do outro, teremos “Produtos”, em uma 
Introdução a Banco de Dados 
22
ligação também de um para “N” com “Pedidos”. O diagrama ilustrado na 
Figura 10 representa bem essa situação.
Figura 10 ‒- O relacionamento entre clientes e produtos é a relação que resulta nos pedidos
Clientes Produtos
N1
Fonte: Duarte (2016).
É importante que os profissionais de banco de dados conheçam 
os atributos das entidades que, sendo neste nível de abstração, como 
já apresentado anteriormente, os dados que compõem as entidades 
recebem o nome de “atributo”. Veja a seguir:
 • Chaves primárias.
 • Chaves secundárias.
 • Chaves alternativas ou candidatas. 
 • Chaves estrangeiras.
A chave primária de uma entidade é o atributo, ou o conjunto 
deles, que identifica uma única informação, sem repetição, fazendo uma 
analogia com uma tabela. Um conjunto de colunas que identificam uma 
única linha, sem repetição. As chaves primárias podem ser as seguintes:
 • Simples: quando representadas por um único atributo.
 • Compostas: quando reúnem um conjunto de atributos. Nesse 
caso, a concatenação entre esses atributos é o que define uma 
única informação da entidade, sem repetição.
No exemplo do diagrama ilustrado anteriormente, percebemos 
que, para identificar um pedido de um cliente, precisamos do código 
deste e do produto. Dizemos, então, que a chave primária da entidade 
“Pedidos” é composta por, entre outros atributos, “Código do Cliente” e 
“Código do Produto”.
Introdução a Banco de Dados 
23
Figura 11 ‒- O pedido de um cliente são informações importantes que devem constar nos 
bancos de dados
Fonte: Freepik.
Entende-se por chave secundária de uma entidade, aquele atributo 
que, mesmo não identificando uma única informação dentro da entidade, 
pode ser utilizado para indexá-la de acordo com alguma necessidade 
de ordenamento, classificação ou agrupamento. No caso da entidade 
“Vendas”, vista no diagrama MER apresentado anteriormente, poderíamos 
ter um atributo intitulado “Categoria”, que tipificaria a venda entre vários 
níveis de importância para a empresa. Embora esse atributo não identifique 
uma única informação na entidade, ele pode ser encarado como uma 
chave secundária para várias buscas, classificações e ordenamentos, que 
podem ser realizados sobre essa entidade.
Já a chave alternativa (ou candidata) de uma entidade é o atributo, 
ou o conjunto deles, que também identifica uma única informação, 
sem repetição, mesmo sem ser a chave primária da entidade. Um bom 
exemplo disso é se tivéssemos um atributo chamado “CNPJ” dentro da 
entidade “Clientes”. Dois clientes jamais poderão ter um mesmo CNPJ, 
não é verdade? Nesse caso, o campo “CNPJ” seria um candidato à chave 
primária da entidade “Clientes”, logo, esse atributo é denominado “chave 
alternativa” ou “chave candidata” dessa entidade.
A chave estrangeira é um atributo que, embora não seja chave 
em uma entidade, é em outra, representando um elo de ligação entre 
elas. No caso da entidade de ligação “Vendas”,as chaves primárias de 
Introdução a Banco de Dados 
24
“Clientes” e “Produtos” deverão compor a sua estrutura de atributos. 
Assim, dentro da entidade “Vendas”, essas chaves serão consideradas 
estrangeiras. Podemos entender a chave estrangeira como sendo um 
atributo obrigatório em todo e qualquer relacionamento de 1:N. Nesse tipo 
de relacionamento, a chave primária da entidade “1” estará na entidade “N” 
como uma chave estrangeira.
Figura 12 -‒ Entidades com seus respectivos atributos, nos quais os atributos-chaves estão 
em maiúsculo e negrito
Clientes Produtos
N1
Pedidos
1N
CODPROD
• Descrição
• Preço
• Peso
• Volume
• Qtd-Estoque
•...
• CODPED
• CODCLI
• CODPROD
• Data-Pedido
• Qtd-Pedida
• ...
• CODCLI
• Nome
• Endereço
• CEP
• Cidade
• Estado
• ...
Fonte: Duarte (2016).
Considerando o último diagrama MER, vamos fazer algumas 
análises? Por exemplo: perceba que “Clientes.CODCLI” e “Produtos.
CODPROD” são as chaves primárias das entidades “Clientes” e “Produtos”, 
respectivamente. Por isso, vamos tratá-las com essa nomenclatura, ou 
seja, o nome da tabela seguida de um ponto “.”, e o nome do campo logo 
em seguida. Perceba que esses mesmos atributos aparecem na entidade 
de ligação “Pedidos”. Nessa entidade, nós os trataremos como “Pedidos.
CODCLI” e “Pedidos.CODPROD”.
As múltiplas ligações também são importantes de serem analisadas, 
veja este questionamento: uma entidade de ligação pode ligar apenas 
duas entidades? A resposta é não. Ela pode ligar três entidades que, 
nesse caso, estaríamos falando de uma tríplice ligação, ou mais de três.
Introdução a Banco de Dados 
25
REFLITA:
Se a entidade “Pedidos” representa uma entidade de 
ligação entre “Clientes” e “Produtos”, por que a chave 
primária adotada não foi uma chave composta de “Pedidos.
CODCLI” e “Pedidos.CODPROD”? A resposta é simples. 
Considerando que um cliente pode efetuar o pedido de 
um mesmo produto diversas vezes, esses dois atributos 
concatenados não conseguiriam identificar uma única 
informação na entidade, concorda? Desse modo, existiam 
duas maneiras de solucionar esse problema. Uma delas foi 
adotada no diagrama ilustrado anteriormente, ou seja, foi 
criada uma nova chave primária intitulada “CODPED”. Essa 
chave nunca poderá ser repetida. No entanto, poderíamos 
ter adotado uma chave primária composta para essa 
entidade. Para que não houvesse redundância, ou seja, 
para que ela pudesse recuperar uma única informação de 
“Pedidos”, teríamos que ter os seguintes atributos formando 
essa chave: “CODCLI”, “CODPROD” e “Data-Pedido”. Mas, e 
se um mesmo cliente pedisse um mesmo produto mais 
de uma vez em um mesmo dia? Nesse contexto, ainda 
estaríamos experimentando um problema de redundância. 
E como resolver isso? Ou adotamos uma chave primária 
simples e independente, como foi o caso de “CODPED”, 
ou teríamos que adicionar um atributo “Hora-Pedido” na 
entidade “Pedidos”. Inclusive, mesmo assim, teríamos que 
adicionar um atributo de hora completa, com minutos e 
segundos, pois em uma mesma hora o cliente poderia 
emitir dois pedidos.
Nada como um exemplo para entender melhor, então vamos 
retomar nosso estudo de caso anterior, tentando entender como as outras 
duas entidades se relacionam com clientes e pedidos. Vamos começar 
pelos vendedores e como eles se relacionam com os produtos vendidos 
pela empresa. Faremos duas perguntas ao nosso modelo:
1. Um vendedor vende um ou mais produtos? .............( ) Um ( ) Mais
2. Um produto é vendido por um ou mais vendedores? ( ) Um ( ) 
Mais
Introdução a Banco de Dados 
26
Claro que a resposta a essas duas perguntas é só uma: “mais”, um 
vendedor pode vender “N” produtos, e um mesmo produto pode ser 
vendido por “N” vendedores.
Figura 13 ‒- As relações de compra e venda entre o vendedor e cliente também são 
consideradas no banco de dados
Fonte: Freepik.
Veja como está ficando o MER: 
Figura 14 ‒- Relacionamento entre vendedores e produtos
Clientes Produtos
Vendedores Fornecedores
PEDE
N N
VENDE
N
N
Fonte: Duarte (2016).
Introdução a Banco de Dados 
27
É importante analisar que a venda é decorrente de um pedido, 
então, o relacionamento entre “Vendedores” e “Produtos” não faz sentido 
sem indicarmos para quais clientes eles estão vendendo os produtos 
pedidos. 
SAIBA MAIS:
Para se aprofundar no tema sobre MER, recomendamos o 
acesso da seguinte fonte de consulta e conhecimento. Para 
acessar, clique aqui.
Logo, uma venda está associada a um produto, pedido por um 
cliente. Implementando esse conceito no MER, resultará no exemplo a 
seguir.
Figura 15 ‒- Entidade de tríplice ligação
Clientes Produtos
Vendedores Fornecedores
PEDE
N N
VENDE
N
N
Fonte: Duarte (2016).
Entendemos uma tríplice ligação como o relacionamento entre 
três entidades. Esse é o caso que acabamos de analisar. Da relação entre 
“Clientes”, “Produtos” e “Vendedores” teremos o surgimento de uma nova 
entidade de ligação, ou melhor, de tríplice ligação: “Vendas”. 
Introdução a Banco de Dados 
http://revistas.faa.edu.br/https://scorm.onilearning.com.br/item-trilha.php?Componente=d817043d043132512650d6c8baa49125&sessao=vllkomnkr98mfo54fvatm1odb1&aberto=true/SaberDigital/article/view/1029
28
Figura 16 -‒ MER com uma entidade de tríplice ligação
Clientes Produtos
N1
Pedidos
1N
CODPROD
• Descrição
• Preço
• Peso
• Volume
• Qtd-Estoque
•...
• CODPED
• CODCLI
• CODPROD
• Data-Pedido
• Qtd-Pedida
• ...
• CODCLI
• Nome
• Endereço
• CEP
• Cidade
• Estado
• ...
Vendas
Vendedores
N
N
N
• CODVENDA
• CODCLI
• CODPROD
• CODVEND
• Data-Venda
• Qtd-Vendida
• Val-Desconto
• Num-Nota-Fiscal
• ...
• CODVEND
• Nome
• Endereço
• CEP
• Cidade
• Estado
• Perc-Comissão
• ...
Fonte: Duarte (2016).
O diagrama anterior ilustra como ficaria o MER com uma entidade de 
tríplice ligação, unindo as entidades “Produtos”, “Clientes” e “Vendedores”.
EXPLICANDO MELHOR:
Pesquise sobre programas para a construção de diagramas 
entidade-relacionamento.
Introdução a Banco de Dados 
29
RESUMINDO:
E então? Gostou do que lhe mostramos? Aprendeu mesmo 
tudinho? Agora, só para termos certeza de que você 
realmente entendeu o tema de estudo deste Capítulo, 
vamos resumir tudo o que vimos. Você deve ter aprendido 
que a modelagem conceitual de dados é uma alternativa 
de se chegar a um projeto de banco de dados diferente 
da normalização. Enquanto na normalização partimos dos 
dados reais do negócio, na modelagem conceitual o foco é 
o entendimento do negócio como um todo. Para entender 
bem este método, é importante usar o poder de abstração 
e, principalmente, conhecer o negócio do cliente. O MER é, 
na realidade, um modelo conceitual de dados, cujo objetivo 
é descrever as entidades (ou objetos) envolvidos em um 
negócio ou sistema. Entende-se por entidade de ligação 
o resultado do relacionamento de muitos para muitos (ou 
“N” para “N”) entre duas outras entidades. Uma entidade de 
ligação pode ligar três entidades. Nesse caso, estaríamos 
falando de uma tríplice ligação, ou mais de três.
Introdução a Banco de Dados 
30
Modelo Lógico de Dados
OBJETIVO:
Ao término deste capítulo, você será capaz de entender 
o modelo lógico de dados. Isso será fundamental para 
o exercício de sua profissão. E então? Motivado para 
desenvolver esta competência? Então, vamos lá. Avante!.
A Importância do Modelo Lógico de Dados
Modelagem de dados é um processo que começa no nível 
abstrativo e criativo, quando do desenho dos primeiros MERs, e termina 
no dicionário de dados, que determina como cada campo de cada tabela 
irá ser definido. Podemos dizer que tudo inicia no mundo do usuário e 
termina no mundo dos bits e bytes. É na transição entre o mundo real 
e o digital que começam os problemas. Estes podem ser divididos em 
dois grupos: incompatibilidade entre o desenho do MER e os recursos 
do sistema de gerenciamento de banco de dados (SGBD); dificuldade de 
performance relacionada ao desempenho dos servidores que hospedam 
o bancode dados.
Alguns SGBDs, como Oracle, PostgreSQL e SQL Server conseguem 
processar bem as chaves compostas, ou seja, um grupo de campos 
considerados chaves primárias de uma tabela. Já o Access, entre outros 
gerenciadores, não consegue extrair muito desse tipo de arranjo. Para 
essas ferramentas, independentemente de haver grupos de chaves 
estrangeiras em uma tabela de ligação, em vez de defini-los como chaves 
primárias, é melhor criar chaves simples do tipo autoincremento.
IMPORTANTE:
As chaves de autoincremento são capazes de somar “um” 
ao seu próprio valor automaticamente quando uma nova 
linha é adicionada à tabela. O Access trabalha bem com 
esse conceito de chave primária.
Introdução a Banco de Dados 
31
Embora a redundância de dados seja considerada não indicada 
ao considerarmos os preceitos das formas normais, ela é tolerada em 
alguns casos. Por exemplo, o uso de um campo calculado em uma tabela 
Access, embora seja considerado uma dependência transitiva, pode ser 
aceito em um modelo lógico por questões de otimização de performance. 
Em alguns casos, em vez de um cálculo ser processado toda vez que for 
gerada uma consulta em um banco de dados com bilhões de registros, 
talvez seja melhor manter uma redundância controlada em uma tabela 
em prol da velocidade de processamento.
É importante desenhar um modelo lógico de dados que não se 
distancia muito do modelo conceitual. A diferença se dá no detalhamento 
de certos aspectos, como a presença de todos os atributos de cada 
tabela, o detalhamento dos campos chaves e não chaves e a ausência 
completa dos relacionamentos conceituais. Ou seja, aqueles losangos 
que indicavam a ação associativa de uma tabela para a outra, como 
“Clientes” ‒ “Compram” ‒ “Produtos”.
O modelo lógico de dados pode ser melhor compreendido com 
um exemplo. Se abrirmos um banco de dados Access e clicarmos na 
ferramenta “Relações”, que pode ser encontrada no grupo “Ferramentas 
de Banco de Dados” da barra de ferramentas, veremos um bom exemplo 
do que estamos falando.
Figura 17 ‒- Exemplificação de relações no Access
Fonte: Duarte (2016).
Introdução a Banco de Dados 
32
Perceba nessa figura os atributos das entidades, que agora passam 
a se chamar: “os campos (ou colunas) das tabelas”; aparecem dentro dos 
blocos representativos de cada tabela. Os campos-chaves aparecem 
com um ícone em formato de “chave” em sua lateral esquerda; os 
relacionamentos, que sempre são de 1:N, recebem outra nomenclatura, 
ou seja, de 1 para infinito. Existem algumas ferramentas no mercado de 
softwares (CASE) que servem para auxiliar o projetista a desenhar o seu 
modelo de dados e, a partir dele, detalhar, miniespecificar e criar bancos 
de dados. O princípio de funcionamento de uma ferramenta CASE se 
assemelha bastante com o que o Access faz, com as seguintes diferenças, 
conforme apontado no Quadro 1. 
Quadro 1 ‒ Modelo lógico de um banco de dados Access
SGBD Ferramenta CASE
Parte da definição das tabelas. Parte do desenho do MER.
Chega até a criação e o 
gerenciamento do banco de 
dados.
Chega apenas até a 
miniespecificação do banco de 
dados.
Só geram bancos de dados 
para a sua própria estrutura e 
linguagem.
Gera bancos de dados em qualquer 
formato e para qualquer SGBD. 
Fonte: Duarte (2016).
O termo CASE significa “Computer-Aided Software Engineering”, 
que pode ser traduzido como “engenharia de software auxiliada por 
computador”. Existem três classes de ferramentas CASE disponíveis no 
mercado:
1. Lower CASE: servem para gerar a codificação para aplicações 
front-end, minimizando o trabalho de programação por parte do 
desenvolvedor de sistemas.
2. Upper CASE: auxiliam o projetista de software (ou analista de 
sistemas) na concepção e modelagem do sistema como um 
todo, oferecendo recursos de diagramação de modelos de dados 
e processos, chegando até a miniespecificação desses dados e 
processos.
Introdução a Banco de Dados 
33
3. Integrated CASE: são ferramentas que desempenham todo o 
trabalho de desenvolvimento, programação e implantação de 
sistemas, ou seja, é a união do Lower com o Upper CASE.
Ferramentas CASE são softwares que auxiliam profissionais 
de Tecnologia da Informação (TI) que trabalham com projetos de 
desenvolvimento de sistemas de informações, gerando documentação 
e, em alguns casos, códigos-fontes em vária linguagens de programação. 
SAIBA MAIS:
Para se aprofundar no tema modelo lógico de dados é 
recomendo o acesso à seguinte fontes de consulta e 
conhecimento. Para acessar, clique aqui.
O próximo passo depois de desenhar um modelo lógico de dados 
é construir o seu dicionário de dados. No caso específico da modelagem 
de dados, esse dicionário contém todas as informações acerca dos dados 
que compõem cada tabela do modelo. 
Figura 18 ‒- Exemplificação de CASE
Fonte: Wikimedia Commons.
No caso específico do Access, esse dicionário de dados pode ser 
extraído do próprio modelo lógico, bastando clicar em cima do bloco 
Introdução a Banco de Dados 
https://goo.gl/5Nirzn
34
representativo da tabela com o botão direito do mouse e escolher a 
opção “Design da Tabela”.
Figura 19 ‒- Exemplificação de atributos e propriedade do campo
Fonte: Duarte (2016).
Introdução a Banco de Dados 
35
O Access é um SGBD não muito robusto, por isto não há uma 
funcionalidade para imprimir ou gerar um dicionário de dados. Mas outros 
SGBDs e, principalmente as ferramentas CASE, conseguem gerar uma 
vasta documentação, incluindo o dicionário de dados de um projeto de 
banco de dados.
RESUMINDO:
E então? Gostou do que lhe mostramos? Aprendeu mesmo 
tudinho? Agora, só para termos certeza de que você 
realmente entendeu o tema de estudo deste Capítulo, 
vamos resumir tudo o que vimos. Você deve ter aprendido 
que a diferença entre modelo conceitual e modelo lógico de 
dados está na aderência do modelo à tecnologia que será 
aplicada quanto ao projeto de banco de dados. Em outras 
palavras, enquanto no modelo conceitual a preocupação 
é tão somente com o negócio do cliente e o seu mundo 
real, a preocupação do modelo lógico é a adequação 
desse mundo real às limitações e características do SGBD 
que será utilizado mais adiante. A modelagem de dados é 
uma etapa que inicia no nível abstrativo e criativo, quando 
do desenho dos primeiros MERs, e termina no dicionário 
de dados, que determina como cada campo de cada 
tabela irá ser definido. Embora a redundância de dados 
seja considerada uma heresia pelos preceitos das formas 
normais, ela é tolerada em alguns casos.
Introdução a Banco de Dados 
36
Classes e Especializações de Dados
OBJETIVO:
Ao término deste capítulo, você será capaz de compreender 
sobre classes e especializações de dados. Isso será 
fundamental para o exercício de sua profissão. E então? 
Motivado para desenvolver esta competência? Então, 
vamos lá. Avante!.
Especializações de Dados
Muitas vezes, nos projetos de bancos de dados se faz necessário 
inserir mais de uma entidade que contém os mesmos dados, porém 
para propósitos diferentes. Dessa maneira, é destacada a importância do 
conhecimento de classes e especializações de dados.
Imagine que em uma faculdade, os campos de endereço, telefone, 
bairro, cidade, e-mail, entre outros dados pessoais, são utilizados em várias 
entidades, como alunos, professores, funcionários e contatos. Embora não 
possa ser considerado redundância, pois se trata de entidades distintas, 
termina que, em alguns casos, um aluno pode se tornar um professor, 
futuramente. E, nesse caso, o que fazer com o cadastro desse aluno? 
Repetir a digitação de todos esses dados no cadastro de professores? 
Importar esses dados para tornar mais rápido o processo? Mas e quanto à 
redundância de informações? A técnica da especialização de dados veio 
para resolver esse problema, em vez de criar essas quatro entidades no 
modelo de dados, cria-se uma única entidade intitulada: “Pessoas”.
Introdução a Banco de Dados37
Figura 20 - Aglutinação dos dados comuns em uma grande entidade intitulada “Pessoas”
Alunos
Professores
Contatos
Funcionários Pessoas
Fonte: Duarte (2016).
Nessa entidade são colocados os atributos comuns a toda e 
qualquer pessoa que possa se relacionar com a faculdade, como alunos, 
pais ou responsáveis, professores, contatos de fornecedores, funcionários, 
interessados ou alunos em potencial etc. Estamos falando justamente de 
dados como “Nome”, “Endereço”, “Cidade”, “Estado”, “CEP”, “Telefones de 
contato”, “E-mail” etc. Esses atributos são comuns a qualquer entidade 
sobre as quais falamos anteriormente, pelo menos até determinado nível.
IMPORTANTE:
Claro que existem dados específicos, como o número da 
carteira profissional, que não faria sentido algum constar 
da entidade “Alunos”, mas faz todo o sentido constar 
“Funcionários”.
Como você pode visualizar neste diagrama, derivando da entidade 
“Pessoas”, podemos construir as demais entidades como sendo 
especializações de “Pessoas”. Na prática, é como se tivéssemos várias 
entidades ligadas a “Pessoas” com um relacionamento de um para um, 
a essas outras entidades derivadas damos o nome de “classes”. Por 
exemplo, a entidade “Alunos” deixa de ser uma entidade independente 
Introdução a Banco de Dados 
38
para ser uma classe da entidade “Pessoas”, e assim por diante, como 
mostra a Figura 21.
Figura 21 ‒- MER envolvendo várias classes de uma entidade
Pessoas
Alunos
Clientes
Professores
Fornecedores
Contatos
Produtos
Funcionários
Vendedores
1
1
1
1 1
1
1
1
Fonte: Duarte (2016).
Mas qual é a real vantagem disso? Uma vez cadastrada na empresa, 
uma pessoa jamais terá que ser novamente cadastrada, ela, no máximo, 
receberá uma atualização cadastral e uma mudança de status, como no 
caso do aluno que virou professor.
O autorrelacionamento é muito importante, pois, muitas vezes, uma 
entidade se relaciona com ela mesmo. Estranho? Como assim? Simples. 
Imagine uma entidade denominada “Disciplinas”, que contém todas as 
disciplinas que uma faculdade ministra para os seus alunos. Sabemos que 
algumas disciplinas têm pré-requisitos, ou seja, para cursar determinada 
disciplina, o aluno terá que ter cursado outra ou outras disciplinas de 
seu curso. Esse é um caso típico de autorrelacionamento, e pode ser 
representado na Figura 22.
Introdução a Banco de Dados 
39
Figura 22 ‒ Exemplo de autorrelacionamento de 1:N
Disciplinas
N
1
Depende
Fonte: Duarte (2016).
Você pode observar, pela ilustração em tela, que o relacionamento 
de 1:N enseja a seguinte reflexão: uma disciplina pode ser pré-requisito de 
“N” outras, mas essa disciplina só pode ter apenas um pré-requisito. É isso 
que está diagramado nesse MER. Mas será que isso é verdade mesmo? 
Se pensarmos melhor, há casos em que uma disciplina é pré-requisito 
para várias outras e, ao mesmo tempo, tem mais de um pré-requisito. 
Figura 23 ‒ Exemplo de autorrelacionamento de N:N
Disciplinas
Pedidos
N
N
Depende
Fonte: Duarte (2016).
Como vimos anteriormente, um relacionamento de muitos para 
muitos faz surgir uma entidade de ligação no meio desse relacionamento. 
SAIBA MAIS:
Para se aprofundar no tema classes e especializações de 
dados, é recomendo o acesso à seguinte fonte de consulta 
e conhecimento. Para acessar, clique aqui.
Introdução a Banco de Dados 
http://www.unilivros.com.br/pdf/dbmod.pdf
40
Essa entidade de ligação é, nesse caso, a malha de pré-requisitos 
da faculdade, ou seja, uma entidade que contém que disciplinas são 
pré-requisito de quais outras, e assim por diante. Esse novo contexto é 
ilustrado na Figura 24.
Figura 24 ‒ Exemplo de autorrelacionamento de 1:N1
Disciplinas
1
1
Pré-requisitos
N
N
Fonte: Duarte (2016).
Desse modo, o modelo ilustrado não reflete a verdade do mundo 
real, a ilustração do MER correta seria, portanto, a que foi representada 
na Figura 23.
RESUMINDO:
E então? Gostou do que lhe mostramos? Aprendeu 
mesmo tudinho? Agora, só para termos certeza de 
que você realmente entendeu o tema de estudo deste 
Capítulo, vamos resumir tudo o que vimos. Você deve 
ter aprendido que classes e especializações de dados 
podem ser consideradas como a “reta final” em relação 
à modelagem de dados. É importante aprimorarmos 
nossos conhecimentos sobre modelagem de dados, 
estudando alguns relacionamentos mais complexos, como 
o autorrelacionamento e s especializações ou classes de 
entidades. Muitas vezes, precisamos inserir mais de uma 
entidade que contém os mesmos dados, porém para 
propósitos diferentes, as técnicas da especialização de 
dados são indicadas para resolver esse problema. Um 
relacionamento de muitos para muitos faz surgir uma 
entidade de ligação no meio de relacionamentos.
Introdução a Banco de Dados 
41
REFERÊNCIAS
ALEXANDRUK, M. Modelagem de banco de dados. Unilivros, 2011. 
Disponível em: www.unilivros.com.br/pdf/dbmod.pdf. Acesso em: 14 jan. 
2022.
ARAÚJO, M. A. Modelagem de dados: teoria e prática. Revista Saber 
Digital, Valença, v. 1, n. 1, p. 33-39, 2008. 
CINDRA, J. D.; BARCELOS, M. R.; LISBÔA, J. C. Uma pesquisa sobre 
ferramentas case para engenharia reversa estática. Perspectivas On-line, 
Campos dos Goytacazes, v. 1, n. 2, p. 45-52, 2011. 
COUGO, P. Modelagem conceitual e projeto de bancos de dados. 
Rio de Janeiro: Elsevier, 1997.
DUARTE, A. L. Introdução a banco de dados. Recife: Uninassau, 
2016. 
ELMASRI, R.; NAVATHE, S. B. Sistemas de bancos de dados. 4. ed. 
São Paulo: Pearson Addison-Wesley, 2005.
KENT, W. Guia simplificado para as 5 formas normais. Revista SQL 
Magazine. Devmedia, 2011. Disponível em: http://www.devmedia.com.
br/guia-simplificado-para-as-5-formas-normais-artigo-revista-sql-
magazine-87/21043. Acesso em: 14 jan. 20.
RAMAKIRISHNAN, R.; GEHRKE, J. Database Management Systems. 
3. ed. New York: McGraw-Hill, 2002.
Introdução a Banco de Dados 
	Normalização de Dados
	As Formas Normais
	Modelo Entidade-Relacionamento
	Conceitos e Definições sobre Modelos Entidade-Relacionamento
	Modelo Lógico de Dados
	A Importância do Modelo Lógico de Dados
	Classes e Especializações de Dados
	Especializações de Dados