Banco_Dados

Prévia do material em texto

1
Linguagem de Programação
PROF. VANDERSON JOSÉ ILDEFONSO SILVA
BANCO DE DADOS
COLATINA 
2010
PROMOÇÃO
Governo de Sergipe
Marcelo Deda Chagas
Secretaria de Estado da Educação
Belivaldo Chagas Filho
Departamento de Educação
Maria Izabel Ladeira
Coordenação Estadual do E-Tec
Rivânia Andrade
Coordenação de Curso
Marcus Vinícius Andrade Côrtes
2
Técnico em Informática
Governo Federal
Ministério da Educação
Secretaria de Educação a Distância
Professor - Autor
Vanderson José Ildefonso Silva
Equipe Técnica
Alessandro Poleto Oliveira
Revisão
Maria Isolina de Castro Soares
Projeto Gráfico
Equipe CEAD
Diagramação
Duo Translation
Crédito de Imagens (Capa e Interior)
Fonte: site sxc.hu
Ilustrador(es)
Equipe CEAD
S586b Silva, Vanderson José Ildefonso
Banco de dados. / Vanderson José Ildefonso Silva. – Colatina:
 Ifes, 2009.
167p. : il.
 1. Banco de dados. 2. Arquivo de Dados. 3. Educação a 
Distância. I. Instituto Federal do Espírito Santo. II. Título. 
 
 
 CDD 005.74
3
Linguagem de Programação
É um prazer tê-lo(a) conosco.
 
O Ifes oferece a você, em parceria com as Prefeituras e com o Governo Fede-
ral, o Curso Técnico em Informática, na modalidade a distância. Apesar de 
este curso ser ofertado a distância, esperamos que haja proximidade entre 
nós, pois, hoje, graças aos recursos da tecnologia da informação (e-mail, 
chat, videoconferência,etc.), podemos manter uma comunicação efetiva.
É importante que você conheça toda a equipe envolvida neste curso: coor-
denadores, professores especialistas, tutores a distância e tutores presenciais, 
porque, quando precisar de algum tipo de ajuda, saberá a quem recorrer.
Na EaD - Educação a Distância, você é o grande responsável pelo sucesso 
a aprendizagem. Por isso, é necessário que você se organize para os estudos 
e para a realização de todas as atividades, nos prazos estabelecidos, con-
forme orientação dos Professores Especialistas e Tutores. Fique atento às 
orientações de estudo que se encontram no Manual do Aluno.
A EaD, pela sua característica de amplitude e pelo uso de tecnologias 
modernas,representa uma nova forma de aprender, respeitando, sempre, 
o seu tempo.
Desejamos-lhe sucesso e dedicação!
Equipe do Ifes
Fala do Professor
Conceitos importantes. Fique atento!
Atividades que devem ser elaboradas por você, 
após a leitura dos textos.
Indicação de leituras complemtares, referentes 
ao conteúdo estudado.
Destaque de algo importante, referente ao 
conteúdo apresentado. Atenção!
Reflexão/questionamento sobre algo impor-
tante referente ao conteúdo apresentado.
Espaço reservado para as anotações que você 
julgar necessárias.
ICONOGRAFIA
Veja, abaixo, alguns símbolos utilizados neste material para guiá-lo em seus estudos
BANCO DE DADOS
Cap. 1 - CONCEITOS DE BANCOS DE DADOS 9
1.1 Definição 9
1.2 Objetivos 14
1.3 Usuários de banco de dados 15
1.4 Modelos de bancos de dados 17
1.4.1 Modelo em Rede 17
1.4.2 Modelo Hierárquico 18
1.4.3 Modelo Relacional 20
1.4.4 Modelo Objeto-Relacional 26
1.4.5 Modelo Orientado a Objetos 27
Cap. 2 - MODELAGEM DE DADOS 29
2.1 Modelo entidade-relacionamento 30
2.1.1 A cardinalidade de relacionamentos 32
2.1.2 Exemplos do modelo entidade-relacionamento 37
2.1.3. Generalização / especialização de entidades 43
2.1.4 Entidades fracas 45
2.2 Modelo relacional normalizado 45
2.2.1 Chave primária 46
2.2.2 Chave estrangeira 51
2.2.3 Exemplos de diagrama do mrn 55
2.2.4 As formas normais 58
2.3 Ferramentas case 64
Cap. 3 - A CRIAÇÃO DE UM BANCO DE DADOS 67
3.1 A linguagem sql 67
3.2 MYSQL 69
3.3 A criação de um banco de dados 71
3.4 A criação de tabelas 74
3.5 A inserção de registros em tabelas 87
3.6 A alteração de registros em tabelas 92
3.7 A exclusão de registros em tabelas 95
Cap. 4 - CONSULTAS SQL 99
4.1 Consultas básicas 99
4.2 Consultas com cláusula order by 101
4.3 Consultas com cláusula where 105
4.4 Consultas com funções de agrupamento 109
4.5 Consultas com mais de uma tabela 115
4.6 Outras consultas 121
Cap. 5 - SEGURANÇA DA INFORMAÇÃO 123
5.1 Preparando o terreno 123
5.2 Alterando a senha do administrador do banco de dados. 124
5.3 Criando novas contas de usuário e definindo seus privilégios 
de segurança. 126
5.4 Criando visões 132
Cap. 6 - PROCEDIMENTOS ARMAZENADOS E 
GATILHOS 137
6.1 A importância de rotinas armazenadas 137
6.2 Procedimentos armazenados 139
6.3 Gatilhos 147
Cap. 7 - CRIAÇÃO DE ÍNDICES 153
7.1 Índices 153
7.2 Criando um índice durante a criação da tabela 156
7.3 Criando um índice para tabela preexistente 157
Cap. 8 - TRANSAÇÕES EM BANCO DE DADOS 159
8.1 O conceito de transação 159
8.2 Transações no mysql 164
REFERÊNCIAS BIBLIOGRÁFICAS 167
Olá Aluno!
Meu nome é Vanderson José Ildefonso Silva, responsável pela discipli-
na Banco de Dados. Atuo como professor do IFES, antigo CEFETES e 
ETFES, há treze anos, lecionando nos cursos Técnico em Informática e 
Superior em Redes de computadores. Já trabalhei como programador 
de computadores e analista de sistemas, além de lecionar ininterrup-
tamente para o ensino superior desde 1992. Também venho para a pós-
graduação desde 2003.
Sou graduado em Ciências Econômicas (1992), tenho especialização 
em Análise de Sistemas (1994) e mestrado em Informática pela UFES 
(2002). Minhas áreas de interesse são Banco de Dados, Programação, 
Engenharia de Software, Inteligência Artificial, Sistemas Distribuídos 
e Informática na Educação.
Nesta disciplina você será apresentado aos conceitos básicos de Bancos 
de dados e aprenderá a empregá-los como uma importante ferramenta 
para a manutenção de dados em sistemas de informação (persistência de 
dados). Com a crescente utilização da Tecnologia da Informação pelas 
organizações e pessoas físicas, os Bancos de Dados converteram-se em 
uma importante tecnologia, imprescindível para grande parcela dos pro-
fissionais da área de informática. 
Este material tem como objetivo orientá-lo no estudo da disciplina Banco 
de Dados, por meio de dicas e sugestões, com destaque para os aspectos 
mais importantes. Aqui você encontrará conceitos com os quais trabalha-
remos ao longo do Curso, o que não dispensa, é claro, a utilização do livro-
texto – referência para a confecção deste trabalho, que traz diversos exem-
plos adicionais e aprofundamento maior em vários aspectos. É importante 
esclarecer que, além do livro-texto, outros livros foram consultados para 
complementar alguns conceitos, a fim de facilitar o seu entendimento. Es-
ses livros constam nas referências bibliográficas deste material.
Boa Sorte!!!
Prof. Vanderson José Ildefonso Silva
APRESENTAÇÃO
9
Linguagem de Programação
CONCEITOS DE BANCO DE 
DADOS
Olá,
Neste capítulo você terá um primeiro contato com conceitos funda-
mentais da tecnologia de Banco de Dados. São conceitos importan-
tes que servirão de base para o restante do curso.
Bom estudo!
Prof . Vanderson
1.1 Definição
Desde antes do surgimento da primeira civilização, a humanidade de-
dicava-se à produção de signos. Um signo ou símbolo corresponde a 
qualquer coisa que represente algo, de alguma forma, para alguém. Da 
mesma forma que um mapa representa um dado terreno, um brasão 
pode representar o time de futebol para o qual se torce. Uma canção 
pode fazê-lo lembrar uma fase específica de sua vida ou uma paixão. 
Tudo isso e muitos outros são signos. Nesse sentido, o que para você 
nada significa pode representar algo para outros. Portanto, todo signo é 
subjetivo e pode ser de difícil interpretação.
Até hoje, pesquisadores debruçam-se sobre pinturas feitas em cavernas 
há pelo menos 15.000 anos e debatem sobre seus significados. Alguém 
as pintou para representarem algo, mas hoje, 150 séculos depois, não 
sabemos precisar qual o seu significado na época. Elas parecem repre-
sentar animais ou cenas de caçadas na pré-história. Porém, escapa-nos 
sua motivação. Faziam parte de algum ritual religioso, o registro de 
uma importante atividade socialou apenas a expressão da subjetivida-
de de seu pintor?
A chamada oralidade primária precede a invenção da escrita e se carac-
teriza pelo uso da palavra falada como a única forma de gerir a memória 
social das comunidades. A cultura narrativa valorizava as parábolas, fá-
bulas e mitos como veículos naturais do conhecimento que se pretendia 
preservar de uma geração para outra. Histórias e imagens eram associa-
das a algum fato que se buscava memorizar.
10
Técnico em Informática
O mito codifica, sob forma de narrativa, algumas das representações 
que parecem essenciais aos membros de uma sociedade. Dado o funcio-
namento da memória humana, e na ausência de técnicas de fixação da 
informação como a escrita (...), as representações que têm mais chances 
de sobreviver em um ambiente composto quase que unicamente por 
memórias humanas são aquelas que estão codificadas em narrativas dra-
máticas, agradáveis de serem ouvidas, trazendo uma forte carga emotiva 
e acompanhadas de músicas e rituais diversos. (LÉVY, 1993, p. 82).
Ao desenvolverem a escrita, as primeiras civilizações melhoraram a uti-
lidade dos símbolos. Afinal, o surgimento do Estado trouxe consigo a 
inevitável cobrança de impostos. Com a escrita, a contabilidade veio a 
possuir meios objetivos para registrar tributos devidos e valores pagos. 
Desde então, o monarca passou a contar com registros precisos de seu 
tesouro e dos súditos devedores.
Com o capitalismo e o consequente progresso técnico, a administra-
ção das organizações e do Estado tornou-se mais complexa. As em-
presas, por exemplo, demandavam maior controle da atividade pro-
dutiva, envolvendo o gerenciamento de estoques, recursos humanos 
e financeiros. O grande volume de informações registradas em papel 
dificultava consideravelmente seu gerenciamento e atualização. Então, 
com os primeiros computadores migraram-se essas informações para 
dispositivos eletrônicos.
De início, essa migração para meios eletrônicos de armazenamento foi 
implementada de maneira pouco organizada, fazendo uso de sistemas 
de arquivos tradicionais. Cada aplicação do sistema de informações 
era tratada isoladamente pela equipe de desenvolvedores. Em conse-
quência, cada aplicação tinha seus próprios arquivos e a redundância 
de informações era mais do que normal. Uma aplicação para o con-
trole da frequência dos funcionários, por exemplo, tinha seu próprio 
arquivo com dados dos empregados em atividade. Esse arquivo podia 
não ser compartilhado com a aplicação de controle das férias desses 
mesmos empregados.
Por isso, dados como nome, número de matrícula e departamento de 
trabalho podiam facilmente estar duplicados nos diferentes arquivos. 
Com a multiplicação de aplicações e assim de arquivos com redundân-
cia de dados, o risco de inconsistências de dados entre eles crescia expo-
nencialmente. Considere, por exemplo, uma funcionária que se casou e 
mudou de nome. Uma eventual falha humana podia levar a uma situa-
ção em que seu nome fosse alterado apenas em alguns destes arquivos, 
mas não em todos eles.
Capítulo 1 
11
Linguagem de Programação
Os primeiros bancos de dados surgiram no mercado como uma res-
posta a problemas como esse. Um sistema de gerenciamento de banco 
de dados (SGBD) consiste em um conjunto de arquivos estruturados 
e de programas que respondem pelo acesso e manipulação de tais ar-
quivos. Diferente dos sistemas de arquivos tradicionais, o banco de 
dados (BD) favorece o inter-relacionamento dos arquivos, portanto, 
podem ser definidos como “uma coleção de dados inter-relacionados e 
um conjunto de programas para acessá-los” (KORTH, SILBERSCHATZ 
e SUDARSHAN, 2006, p. 1).
Um banco de dados (BD) é um conjunto de dados integrados 
reunidos com o intuito de suportar o funcionamento de siste-
mas de informação.
Um sistema gerenciador de banco de dados (SGBD) é um sof-
tware de caráter geral para a manipulação eficiente de grandes co-
leções de informações estruturadas e armazenadas de uma forma 
consistente e integrada.
Em termos mais simples, podemos definir um SGBD como um software 
desenvolvido especificamente para o gerenciamento de grandes volumes 
de informações. Seu objetivo principal reside na superação de problemas 
comuns aos sistemas de arquivos tradicionais. Tais problemas ou des-
vantagens (KORTH, SILBERSCHATZ e SUDARSHAN, 2006) são:
Redundância e inconsistência de dados.1. Equipes diversas de desen-
volvedores tendem a criar diferentes aplicações ou sistemas ao longo 
do tempo. De maneira análoga, em uma mesma organização, diferen-
tes linguagens de programação, por exemplo, podem ser usadas no 
desenvolvimento de diversos sistemas de informações. Sob tais cir-
cunstâncias, conforme visto, dados distintos podem ser duplicados em 
arquivos diferentes. Essa redundância conduz a altos custos de arma-
zenamento e crescente dificuldade de atualização das informações.
Dificuldade no acesso aos dados. 2. Os dados espalhados em dife-
rentes arquivos isolados não apresentam as facilidades de acesso e 
processamento das informações dos bancos de dados. Há pouca fle-
xibilidade em relação a demandas que não tenham sido antecipadas 
quando o sistema foi projetado. Por exemplo, uma vez que o sistema 
esteja desenvolvido, caso haja a necessidade de se gerar relatórios 
com os nomes de todos os empregados do sexo masculino e com 
idade igual ou superior a 40 anos, a ausência de uma aplicação es-
Conceitos de Banco de Dados 
12
Técnico em Informática
pecífica para esse objetivo traz sérios inconvenientes. Isso porque 
quando os usuários do sistema solicitarem o desenvolvimento desse 
novo aplicativo, sua implementação demandará tempo e recursos 
da parte dos programadores para a geração de um relatório muito 
específico que raramente será usado. Outra solução seria conseguir 
a impressão de uma listagem com todos os empregados existentes 
para posterior extração da informação desejada por meios manuais. 
Essa solução também não é satisfatória, pois o processamento ma-
nual sempre está sujeito a erros humanos.
Isolamento de Dados.3. A existência de dados espalhados em diferentes 
arquivos, que podem apresentar diferentes formatos, dificulta a criação 
de novos programas aplicativos para a recuperação desses dados.
Anomalias de acesso concorrente.4. Inúmeros sistemas de informação 
permitem que múltiplos usuários acessem e atualizem dados simul-
taneamente. A inexistência de sofisticados mecanismos de gerencia-
mento de atualizações concorrentes pode resultar em dados incon-
sistentes. Considere o exemplo de uma conta bancária conjunta com 
saldo de R$ 600,00. Caso dois clientes saquem dinheiro dessa mesma 
conta simultaneamente, o saldo atualizado dessa conta pode ficar in-
consistente. Suponha que o cliente A saque R$ 50,00 ao mesmo tempo 
em que o cliente B saca R$ 100,00. Para que esses saques ocorram, o 
programa aplicativo lê o saldo da conta a partir de um arquivo especí-
fico. Em seguida, o valor do saque é diminuído do saldo lido, gerando 
assim o saldo atualizado. Então, para o aplicativo de A, temos 600 – 50 
= 550, enquanto para o aplicativo de B, temos 600 – 100 = 500. Supon-
do que o aplicativo de A atualize o arquivo antes do aplicativo de B, o 
saldo da conta registrará R$ 500,00. Afinal, no arquivo, os dados do 
aplicativo de B (Saldo atualizado = R$ 500,00) serão sobrepostos aos 
dados do aplicativo de A (Saldo atualizado = R$ 550,00). Repare que 
essa informação está errada – inconsistente – pois havia R$ 600,00 e 
foram retirados R$ 150,00. Portanto, o saldo após essas retiradas, de-
veria ser de R$ 450,00 e não R$ 500,00.
Problemas de segurança.5. O acesso a determinados dados deve ser 
restringido para alguns usuários do sistema de informações. Os da-
dos relativos ao contracheque dos empregados não podem ser dis-
ponibilizados a todos os usuários indistintamente, mas apenas aos 
usuários responsáveis pela folha de pagamento. Entretanto, quando 
programas aplicativos são instalados de maneira arbitrária, ou seja, 
sem acompanhamentoe controle necessários, não há como assegu-
rar tais restrições de segurança.
Capítulo 1 
13
Linguagem de Programação
Problemas de integridade.6. Geralmente restrições de consistência são 
impostas aos dados armazenados. Alguns as chamam simplesmente 
de regras de negócio. O saldo de uma conta bancária, por exemplo, 
não deve cair abaixo de um valor predeterminado. Restrições de con-
sistência como essa nos sistemas de arquivos tradicionais são incor-
poradas aos códigos dos programas aplicativos. Um problema grave 
ocorre quando a adição de novas restrições implica a necessidade de 
alteração de vários programas aplicativos. Sempre há o risco de es-
quecimento de algum desses programas. Em consequência, o risco de 
inconsistências dos dados ameaça a integridade dos mesmos.
Essas seis dificuldades listadas levaram ao desenvolvimento dos siste-
mas gerenciadores de banco de dados (SGBD). Ao longo deste curso 
veremos algumas das estratégias criativamente engendradas para a solu-
ção dessas desvantagens dos sistemas de arquivos tradicionais.
A tecnologia de banco de dados trouxe maior produtividade para 
o desenvolvimento de sistemas de informação. Afinal, nos sistemas 
tradicionais de arquivos, quando implementadas, as característi-
cas que somente seriam inauguradas com o surgimento dos bancos 
de dados eram incorporadas às aplicações isoladamente. Com isso, 
a complexidade do desenvolvimento de sistemas de informação au-
mentava consideravelmente, resultando em:
(1) prazos maiores para a conclusão dos sistemas de informa-
ção e, consequentemente, elevação dos custos envolvidos no 
desenvolvimento;
(2) obrigação de as equipes de desenvolvimento (analistas e progra-
madores) dedicarem muito tempo a programas que não tratavam 
diretamente do sistema de informação em questão, mas sim de fun-
cionalidades que forneceriam suporte a esse mesmo sistema;
(3) ocorrência de problemas não-previstos, favorecidos pela ausên-
cia de padronização das funcionalidades de suporte. 
Os sistemas de bancos de dados atualmente existentes no mercado ali-
viam as equipes desenvolvedoras dessas preocupações com aquilo que 
não seja diretamente relacionado aos seus objetivos, permitindo assim 
a codificação de sistemas de informação mais robustos e confiáveis.
Conceitos de Banco de Dados 
14
Técnico em Informática
Atividade 01
Crie outros possíveis exemplos (pelo menos 2) para as desvan-
tagens ou problemas trazidos pelo uso de Sistemas Tradicio-
nais de Arquivos.
1.2 Objetivos
Sistemas Gerenciadores de Bancos de Dados (SGBDs) têm o objetivo 
de prover mecanismos adequados ao armazenamento e ao acesso segu-
ro e eficiente de dados em Sistemas de Informação (SI). Mais detalha-
damente, os bancos de dados (BD) têm por objetivo:
Fornecer interfaces amigáveis e padronizadas para o armazenamen-•	
to e acesso aos dados. Assim, os usuários são poupados de conhecer 
detalhes da implementação interna, como organização dos arquivos 
e estruturas de armazenamento;
Assegurar a privacidade dos dados por meio de medidas de segu-•	
rança como a atribuição de permissões diferenciadas de acesso aos 
usuários, a criação de visões particularizadas de tais dados e o forne-
cimento de senhas de acesso. Assim, evita-se que dados importantes 
sejam acessados por pessoas não-autorizadas;
Administrar acessos concorrentes aos dados, permitindo que diferentes •	
usuários compartilhem simultaneamente a mesma coleção de dados;
Prover mecanismos para a recuperação de dados em decorrência de •	
eventuais paradas e falhas do sistema. As possíveis causas de paradas 
ou falhas podem ocorrer devido a erros de software, interrupção no 
suprimento de energia, defeito de hardware, queda na comunicação 
com o servidor, etc. Qualquer falha dessas pode resultar na perda 
de dados processados pelo SGBD no momento da parada. A perda 
desses dados pode levar o banco de dados a uma condição de in-
consistência que, se não evitada, torna a tecnologia pouco confiável 
para sistemas de aplicações críticas. Portanto, caso um produto seja 
vendido, seu estoque deve ser atualizado e, se uma falha ocorre após 
o registro da venda, mas antes da atualização do estoque, o banco de 
dados ficará inconsistente. Afinal, a quantidade em estoque não será 
real para o produto em questão.
Capítulo 1 
15
Linguagem de Programação
Atividade 02
Um Sistema Gerenciador de Banco de Dados (SGBD) foi definido 
como “uma coleção de dados inter-relacionados e um conjunto 
de programas para acessá-los” (KORTH, SILBERSCHATZ e SU-
DARSHAN, 2006, p. 1). Entretanto, os Sistemas Tradicionais de 
Arquivo, que precederam a tecnologia de Banco de Dados, falha-
vam exatamente nestes dois aspectos: (I) manter dados inter-re-
lacionados e (II) fornecer um conjunto de programas voltados à 
manutenção desses mesmos dados.
[A] Comente as vantagens que a existência de dados inter-rela-
cionados traz aos sistemas de informação.
[B] Uma das principais funcionalidades de um banco de dados 
é a chamada restrição de consistências. Explique os riscos que 
a ausência dessa funcionalidade trazia aos Sistemas Tradicio-
nais de Arquivos.
1.3 Usuários de banco de dados
Basicamente são quatro os tipos de usuários de sistemas de bancos de 
dados:
Usuários leigos: São profissionais de outras áreas cujos conhecimentos 
de informática se restringem ao básico e que interagem com o banco 
de dados por meio de aplicações escritas pelos programadores de apli-
cações. As aplicações fazem a intermediação entre esses usuários e o 
banco de dados, pois é através de suas telas ou páginas que o usuário 
leigo acessa seus dados;
Usuários avançados: usuários com maior nível de independência em 
relação aos programadores de aplicações. Geralmente interagem com 
os bancos de dados por meio de interfaces disponíveis no ambiente. Es-
crevem consultas em linguagem específica para gerarem relatórios com 
certa facili-dade, sem a necessidade de um programador escrever uma 
nova aplicação;
Analistas de Sistemas: profissionais responsáveis por traduzir as necessi-
dades dos usuários leigos e avançados em uma especificação racional de 
um sistema de informação. O projeto do sistema de informação especifica 
as aplicações e a estrutura do banco de dados. Os programadores de aplica-
ções seguem rigorosamente as especificações dos analistas de sistemas, de-
senvolvendo programas de computadores que acessem o banco de dados.
Conceitos de Banco de Dados 
16
Técnico em Informática
Programadores de aplicações: profissionais com formação em compu-
tação que se propõem a construir aplicações ou programas de computa-
dor com interfaces intuitivas e amigáveis para os usuários leigos. Tais in-
terfaces incluem formulários e relatórios que acessam bancos de dados;
Administrador de Banco de Dados (Data Base Administrator - DBA): 
usuário mais especializado de um banco de dados responsável pela ad-
ministração das bases de dados, ocupando-se com:
a atribuição de permissões de acesso adequadas a cada usuário,1. 
a geração de cópias de segurança dos dados (2. backups) como contin-
gência a possíveis falhas,
o monitoramento do ambiente como forma de assegurar a disponi-3. 
bilidade do banco de dados pelo maior tempo possível,
a otimização de recursos de infraestrutura (disco, memória, processa-4. 
dor) para assegurar o desempenho satisfatório do banco de dados,
o suporte à equipe de desenvolvimento (analistas de sistemas e pro-5. 
gramadores de aplicação).
Em resumo, o DBA deve ser o profissional que zela pela implemen-
tação adequada do banco de dados, assegurando um funcionamento 
eficiente que prime pelo desempenho, escalabilidade, flexibilidade e 
confiabilidade.
Algumas organizações preferem manter um profissional que acu-
mule as funções do analista de sistemas e do programador de 
aplicações. Isso lhes permite reduzir custos trabalhistas e evitar “ru-
ídos de comunicação” que comprometam a eficiência dos sistemas 
de informações.
Afinal, sempre há a possibilidade de que o analista de sistemas não 
entendaperfeitamente as demandas do usuário ou que não seja 
plenamente entendido pelo programador de aplicações. Assim, o 
usuário teria em suas mãos um sistema de informação muito dife-
rente do que requisitara inicialmente.
Assim, as aplicações teriam de ser reescritas, tornando o processo 
mais caro e menos eficiente do que seria.
Capítulo 1 
17
Linguagem de Programação
1.4 Modelos de bancos de dados
Os modelos de bancos de dados definem a forma como os dados estão 
organizados internamente. Em ordem cronológica, os modelos de ban-
co de dados classificam-se em redes, hierárquicos, relacionais, objeto-
relacionais e orientados a objetos. Segue-se uma descrição sobre cada 
um desses modelos para melhor entendermos suas características, di-
ferenças e usos.
1.4.1 Modelo em Rede
Um banco de dados em rede consiste em uma coleção de registros con-
catenados uns aos outros por meio de ligações. Semelhantes ao concei-
to de ponteiros, essas ligações podem ser entendidas como endereços 
de memória que indicam ou “apontam” a localização de um registro 
associado.
Na Figura 1 há um exemplo de Modelo em Rede com dois diferentes 
tipos de registros: cliente e conta. O registro de cliente apresenta três 
atributos ou subdivisões: nome, cidade e sexo. Por sua vez, o registro de 
conta possui apenas dois atributos: número e saldo.
Figura 1 - Exemplo de Banco de Dados – Modelo em Rede.
Ligações associam registros de clientes a registros de contas. Então, sa-
bemos que o cliente Reinaldo Antunes tem uma conta de número 1045 
e saldo de R$ 945,60; e os clientes Marcela Souto e André Marques 
possuem uma conta conjunta no banco de número 1447 e saldo de R$ 
93,41. Porém, Marcela tem ainda outra conta de número 1358 e saldo 
R$ 107,00; e André Marques também tem outra de número 1500 com 
R$ 1.266,00 depositados.
Um conjunto de diferentes tipos de registros relacionados entre si por 
meio de um emaranhado de ligações forma uma estrutura de dados 
muito semelhante a uma rede.
Nome
Reinaldo antunes
Nome
Marcela Souto
Nome
André Marques
Cidade
Vitória
Sexo
M
Sexo
M
Sexo
F
Cidade
Colatina
Cidade
Colatina
Número
1045
Número
1385
Número
1447
Número
1500
Saldo
945,60
Saldo
107,00
Saldo
93,41
Saldo
1.266,00
Conceitos de Banco de Dados 
18
Técnico em Informática
Atividade 03
Seguindo o modelo da Figura 1 acima, elabore um exemplo de 
banco de dados no Modelo Rede envolvendo a seguinte coleção 
de dados: Funcionário {matrícula, nome, salário, função} e Filial 
{Cidade, Bairro, Telefone}. O objetivo desta coleção de dados é 
armazenar informações sobre todos os funcionários de um super-
mercado e de suas filiais espalhadas em diversas localidades no 
país. Por meio dessa coleção deve ser possível determinar as filiais 
em que cada funcionário está lotado.
Esse exemplo deverá apresentar pelo menos duas filiais com um 
mínimo de cinco funcionários por elas distribuído. Use sua criativi-
dade para dar nomes aos funcionários, bem como o preenchimento 
dos outros dados sobre eles e as filiais nas tabelas. Lembre-se de que 
um funcionário somente poderá estar lotado em uma filial.
1.4.2 Modelo Hierárquico
Uma evolução do Modelo em Rede, os bancos de dados hierárquicos 
são uma coleção de registros relacionados uns aos outros por meio de 
ligações também semelhantes a ponteiros. Porém, o Modelo Hierárqui-
co se diferencia de seu antecessor na forma de organizar seus registros. 
Enquanto no Modelo em Rede os registros são distribuídos conforme a 
lógica de grafos arbitrários, no Hierárquico esses mesmos registros são 
dispostos como uma coleção de árvores.
Árvores Binárias é um dos temas tratados na disciplina referente 
a programação em Estrutura de Dados.
A Figura 2 traduz para o Modelo Hierárquico o exemplo anterior do 
banco com registros de clientes e contas.
Capítulo 1 
19
Linguagem de Programação
Figura 2 - Exemplo de Banco de Dados – Modelo Hierárquico.
Um registro isolado no topo da Figura 2 encontra-se associado a todos 
os registros de Clientes. Esse é o registro do tipo “raiz”, o ponto de parti-
da da árvore de registros. Ele está no nível mais elevado da estrutura de 
dados e pode ser ligado a nenhum, um ou vários registros no nível in-
ferior. Em nosso exemplo, os registros conectados ao registro “raiz” são 
sempre registros de Clientes que, por sua vez, estão sempre interligados 
a registros de Contas no nível imediatamente abaixo.
Generalizando, existem camadas, níveis ou hierarquias em uma árvo-
re. Os registros de um dado nível sempre se associam aos registros do 
nível imediatamente inferior e nunca com registros do mesmo nível. 
No primeiro nível da árvore há sempre um único registro, denomina-
do “Raiz”, que representa o ponto de partida de onde é possível acessar 
os demais registros.
Cada nível da árvore comporta um tipo de registro diferente. No exem-
plo, o nível imediatamente abaixo da raiz comporta apenas registros do 
tipo Cliente; e o nível seguinte apresenta apenas registros do tipo Conta. 
Ainda poderiam existir outros níveis, desde que houvesse registros de 
outros tipos.
Na árvore, um registro de nível K pode estar associado a, no máxi-
mo, um registro do nível imediatamente acima (K – 1). Contudo, um 
registro de nível superior pode estar associado a mais de um registro 
do nível imediatamente abaixo. Note que o registro da cliente Marcela 
Souto liga-se a dois outros registros de conta, mas a conta de número 
1447 teve de ser duplicada para que a regra fosse preservada, repli-
cando o registro para que André Marques compartilhasse essa conta 
com Marcela Souto já que um registro de conta não pode se associar 
simultaneamente a dois de clientes.
Nome
Reinaldo antunes
Nome
Marcela Souto
Nome
André Marques
Cidade
Vitória
Sexo
M
Sexo
M
Sexo
F
Cidade
Colatina
Cidade
Colatina
Número
1500
Número
1045
Saldo
945,60
Número
1385
Saldo
107,00
Número
1447
Saldo
93,41
Número
1447
Saldo
93,41
Saldo
1.266,00
Conceitos de Banco de Dados 
20
Técnico em Informática
A estrutura hierárquica desse banco de dados define o caminho de aces-
so aos registros. Qualquer busca a um registro específico sempre come-
ça pela raiz até o nível correspondente ao tipo procurado.
É comum encontrar na literatura as denominações PAI e FILHO 
para distinguir a relação existente entre registros de diferentes ca-
madas da árvore.
Registros de uma camada K geralmente são designados Filhos dos 
registros de uma camada K – 1. Em contrapartida, os registros dessa 
camada K – 1 são considerados Pais dos registros da camada K que 
a eles estiverem conectados. Portanto, em nosso exemplo da Figura 
3, os registros de Conta são Filhos dos registros de Clientes.
Atividade 04
Converta o exemplo de banco de dados no Modelo Rede da Ativi-
dade 03 em um exemplo equivalente no Modelo Hierárquico.
1.4.3 Modelo Relacional
A partir dos anos 1970, o modelo relacional de banco de dados estabe-
leceu-se como modelo preferencial para aplicações de banco de dados 
comerciais. Na década seguinte já havia se tornado o padrão de banco 
de dados utilizado pelo mercado corporativo.
Em 1970, foi Edgar Frank Codd, um pesquisador da IBM, quem 
originalmente propôs o modelo relacional de banco de dados 
tratado nesta seção. Esse novo modelo trouxe uma importante 
contribuição ao dissociar a estrutura lógica do banco de dados 
dos métodos de armazenamento físico dos dados – algo impos-
sível para os modelos em rede e hierárquico. Ao fazê-lo, tornou os 
SGBDs mais “amigáveis” (fáceis de utilizar).
Capítulo 1 
21
Linguagem de Programação
Em um modelo relacional, os registros são organizados em tabelas onde 
cada linha representa uma relação entre os valores armazenados em di-
ferentes colunas. Assim, em uma tabela de clientes, como no exemplo 
desenvolvido até aqui, temos cada registro subdividido em 3 colunas: 
nome, cidade e sexo. Toda linha existente na tabela de Clientes repre-
senta um conjunto de valores inter-relacionados. Em outras palavras, 
cada linha da tabela armazena os dadosde um cliente em particular 
organizados em diferentes colunas.
Assim, sabemos que o cliente “Reinaldo Antunes” mora em “Vitória” e 
é do sexo masculino (“M”), pois esses dados estão em uma mesma linha 
da tabela. Também sabemos que os clientes “Marcela Souto” e “André 
Marques” residem na cidade de “Colatina” e são, respectivamente, do 
sexo feminino e masculino.
O modelo relacional de banco de dados apresenta esse nome em razão 
não apenas da relação existente entre as colunas de uma mesma tabe-
la, mas também da possibilidade de estabelecer relacionamentos entre 
diferentes tabelas. Para que nosso exemplo de clientes e contas fique 
completo, precisamos relacionar registros de uma tabela com registros 
de outra. Caso contrário, não teríamos como saber com precisão a quais 
clientes cada conta pertence. Porém, ao contrário dos modelos em rede 
e hierárquico, as associações entre diferentes registros em um modelo 
relacional não são implementadas mediante o recurso de “ponteiros”. Na 
verdade, o modelo relacional emprega a duplicação de uma ou mais co-
lunas em uma tabela distinta daquela a que pertencem originalmente.
Ponteiros é um dos temas tratados na disciplina referente a pro-
gramação em Estrutura de Dados.
Sexo
M
F
M
Cliente
Nome Cidade
Reinaldo Antunes Vitória
Marcela Souto Colatina
André Marques Colatina
Conceitos de Banco de Dados 
22
Técnico em Informática
No diagrama acima, temos duas tabelas – Filme e Gênero – que estão 
relacionadas entre si através da coluna Cod_Genero. Essa coluna é ori-
ginal da tabela Gênero, mas foi duplicada na tabela Filme para estabele-
cer uma associação lógica entre os registros das diferentes tabelas. Dessa 
maneira, sabemos que o filme “Star Trek” é classificado como uma “fic-
ção-científica”, pois apresenta o valor “FIC” em sua coluna Cod_Genero 
e o mesmo valor na coluna correspondente da tabela Gênero encontra-
se associada à descrição “Ficção-Científica”.
Há quem não compreenda a necessidade de duas tabelas em situações 
como essa de Filme e Gênero. Afirmam ser uma solução de complica-
ção despropositada e perguntam-se: A coluna descrição não poderia 
simplesmente existir apenas na tabela Filme de modo a não haver a ne-
cessidade da tabela Gênero e nem das colunas duplicadas de Cod_Ge-
nero? A princípio essa parece ser uma solução mais simples e, portanto, 
melhor, mas a tabela abaixo procura exemplificar essa solução mais sim-
ples demonstrando também sua vulnerabilidade.
Filme
Numero Titulo Ano Cod_Genero
1099 El Cid 1961 DRA
1100 Star Wars 1977 FIC
1101 Star Trek 2009 FIC
1102 UP- Altas Aventuras 2009 DES
1103 Transformers 2 2009 FIC
1104 Wolverine Origens 2009 AVE
Gênero
Cod_Genero Descricao
AVE Aventura
DES Desenho
DRA Drama
FIC Ficção-Científica
MUS Musical
COM Comédia
Filme
Numero Titulo Ano Descricao_Genero
1099 El Cid 1961 Drama
1100 Star Wars 1977 Ficção-Científica
1101 Star Trek 2009 Ficção
1102 UP – Altas Aventuras 2009 Desenho
1103 Transformers 2 2009 Ficção-Científica
1104 Wolverine- Origens 2009 Aventura
Capítulo 1 
23
Linguagem de Programação
Os valores da coluna Descricao_Genero podem se repetir em diferen-
tes registros (linhas). Na tabela acima há três filmes do gênero ficção 
científica. Contudo, cada filme apresenta valores diferenciados para essa 
coluna. No filme “Transformers 2” não há hífen, mas em “Star Wars” 
esse caractere está presente. Já no filme “Star Trek”, não somente houve a 
omissão do hífen como também a supressão da palavra “Científica”. Algo 
assim é perfeitamente possível de acontecer. Usuários diferentes podem 
ter cadastrado cada um desses filmes, ou ainda um mesmo usuário em 
diferentes ocasiões pode ter cadastrado os três filmes. Acontece que, em 
um dado momento, esse usuário encontrava-se com uma disposição um 
tanto preguiçosa para escrever “ficção científica” e registrou apenas “fic-
ção”. Mais tarde, por um erro de digitação, passou a usar o hífen.
A possibilidade de ocorrer a situação descrita acima demonstra a vul-
nerabilidade de uma solução baseada em uma única tabela. Caso um 
relatório ou simples consulta seja efetuada, o resultado alcançado pode 
diferir sensivelmente da realidade que a base de dados deveria espe-
lhar. Suponha que um usuário submeta uma consulta ao banco de dados 
usando como critério de busca a coluna Descricao_Genero com o valor 
“Ficção Científica”. Infelizmente, o resultado de sua consulta não inclui-
rá os registros de “Star Trek” e “Star Wars” e ele terá a impressão de que 
existe apenas um filme desse gênero: “Transformers 2”.
Como veremos quando tratarmos do conceito de integridade refe-
rencial, a solução inicial envolvendo duas tabelas (Filme e Gênero) é a 
mais indicada para se evitar tais problemas. Ocorre que a tecnologia de 
bancos de dados relacionais possui recursos suficientes para assegurar 
que a coluna Cod_Genero da tabela Filme apresente somente valores 
já existentes na coluna Cod_Genero da tabela Gênero. Dessa maneira, 
nenhum usuário poderá cadastrar um novo filme ou alterar um velho 
filme com um código inexistente na tabela de origem (Gênero). O Sis-
tema Gerenciador de Banco de Dados (SGBD) Relacional simples-
mente não permitirá essa operação. No máximo, um usuário descui-
dado poderia lançar um código errado para um filme. Porém, ele não 
conseguiria criar um novo código de gênero para um Filme sem antes 
criá-lo na tabela de Gênero.
Retomando o exemplo do banco de dados para clientes e contas bancárias, 
a Figura 3 apresenta a configuração ideal para o modelo relacional.
Conceitos de Banco de Dados 
24
Técnico em Informática
Figura 3: Exemplo de Banco de Dados – Modelo Relacional.
Aqui, uma terceira tabela (Contas_Cliente) precisou ser criada para esta-
belecer o relacionamento entre as tabelas de Cliente e Conta. No exemplo 
anterior sobre Filme e Gênero, não houve essa necessidade, bastou repli-
car a coluna Cod_Genero na tabela Filme. Porém, a duplicação da coluna 
Id_Cliente na tabela Conta ou a duplicação da coluna Numero_Conta 
na tabela Cliente não seria uma solução eficiente para estabelecer o rela-
cionamento entre as tabelas. Por isso, criamos uma nova tabela apresen-
tando apenas duas colunas e nenhuma delas é originária dessa nova tabela 
(Contas_Cliente). As colunas Id_Cliente e Numero_Conta são replica-
das respectivamente nas tabelas Cliente e Conta.
Caso duplicássemos Id_Cliente na tabela Conta, enfrentaríamos um 
grave problema ao cadastrar a Conta de número 1447. Esta conta per-
tence a dois clientes, é uma conta conjunta: André (Id_Cliente = 37) e 
Marcela (Id_Cliente = 15). Como a coluna Id_Cliente na tabela Conta 
comporta apenas um valor por linha, teríamos de cadastrar duas linhas 
para a Conta de número 1447. Se assim procedêssemos, a tabela Conta 
teria dois registros diferentes entre si apenas no valor de uma de suas 
três colunas, Figura 4.
Figura 4: O Problema em Duplicar Id_Cliente na Tabela Conta.
Cliente
Id_Cliente Nome Cidade Sexo
10 Reinaldo Antunes Vitória M
15 Marcela Souto Colatina F
37 André Marques Colatina M
Contas_Cliente Conta
Numero_Conta Id_Cliente Numero_Conta Saldo
1045 10 1045 945,60
1385 15 1385 107,00
1447 15 1447 93,41
1447 37 1500 1.266,00
1500 37
Conta
Numero_Conta Saldo Id_Cliente
1045 945,60 10
1385 107,00 15
1447 93,41 15
1447 93,41 37
1500 1.266,00 37
Redundância de 
dados (ineficiência)
Capítulo 1 
25
Linguagem de Programação
Por outro lado, se optássemos por duplicar Numero_Conta na tabela 
Cliente, teríamos outro problema grave com a tentativa de registrar as 
duas contas de “Marcela Souto” – números 1385 e 1447, pois teríamos de 
cadastrar duas linhas exatamente iguais para Marcela na tabela Cliente, 
exceto pelo conteúdo da coluna duplicada de Numero_Conta, Figura 5.
Figura 5: O Problema em Duplicar Numero_Conta na Tabela Cliente.
As consequências mais sérias para essas tentativas equivocadas de rela-
cionamento das tabelas Cliente e Conta seriam:
Uso ineficiente dos recursos de armazenamento: redundância de dados 1. 
consumiria desnecessariamenteo espaço disponível no disco rígido;
Maior complexidade para a manutenção das informações: a atuali-2. 
zação do saldo em uma conta (Figura 4) ou a mudança de cidade 
para um cliente (Figura 5) poderia implicar a alteração de mais de 
um registro simultaneamente.
Por mais que a nova tabela Contas_Cliente (Figura 3) também seja 
uma redundância de dados, quando comparada às outras situações (Fi-
guras 4 e 5), a mesma representa uma replicação controlada e, portanto, 
mais eficiente.
Na Figura 5, por exemplo, a duplicação de dados abrange quatro colu-
nas (Id_Cliente, Nome, Cidade e Sexo), enquanto na Figura 3 a duplica-
ção envolve somente duas colunas (Id_Cliente e Numero_Conta).
Embora a Figura 4 igualmente apresente a duplicação de apenas duas 
colunas (Numero_Conta e Saldo), ela também implica a replicação de li-
nhas. O mesmo não ocorre com a situação ilustrada pela Figura 3, onde 
nenhuma linha aparece replicada. Ainda que as colunas Numero_Con-
ta e Id_Cliente apresentem valores duplicados em diferentes linhas, ne-
nhuma combinação das mesmas se repete na tabela Contas_Cliente.
Como a duplicação de dados é inerente ao modelo relacional – o que é 
inevitável – a situação representada pela Figura 3 mostra-se plenamente 
aceitável e preferível às demais situações representadas pelas Figuras 4 e 5.
Redundância de 
dados (ineficiência)
Redundância de 
dados (ineficiência)
Cliente
Id_
Cliente
Nome Cidade Sexo Numero
_Conta
10 Reinaldo Antunes Vitória M 1045
15 Marcela Souto Colatina F 1385
15 Marcela Souto Colatina F 1447
37 André Marques Colatina M 1447
7 André Marques Colatina M 1500
Conceitos de Banco de Dados 
26
Técnico em Informática
A maneira de definir quais colunas e em quais tabelas as mesmas 
deverão ser replicadas será tratada mais adiante ao nos aprofun-
darmos no Modelo Relacional, quando abordaremos conceitos como 
Chaves Primárias, Chaves Estrangeiras e Integridade Referencial.
Também veremos com detalhes a linguagem de consulta e mani-
pulação de banco de dados relacionais conhecida como Structured 
Query Language (SQL), que tornou-se importante padrão para 
Bancos de Dados desde a década de 1980.
Atividade 05
Converta o exemplo de banco de dados das Atividades 03 e 04 em 
um exemplo equivalente no Modelo Relacional.
1.4.4 Modelo objeto-relacional
Sistemas Gerenciadores de banco de dados (SGBDs) que adotam o 
modelo objeto-relacional aproveitam a estrutura básica do modelo re-
lacional acrescida de algumas características próprias da orientação a 
objetos. Porém, esse modelo híbrido não deve ser confundido com o 
Modelo Orientado a Objetos. Dentre as características da orientação a 
objetos incorporadas pelo modelo objeto-relacional merecem destaque: 
a herança de tipos e tabelas e a definição de novos tipos complexos.
O modelo objeto-relacional (OR) é uma extensão do modelo rela-
cional conhecido como modelo relacional estendido. Sua linguagem 
de consulta foi adaptada para abranger objetos, atributos multiva-
lorados, tipos abstratos de dados, além de métodos e funções como 
predicados de busca.
O padrão ANSI SQL-99 ou SQL-3, muitas vezes caracterizado como a 
SQL orientada a objetos, trouxe inúmeras inovações em relação à SQL-
92. Ela é a base de inúmeros SGBDs OR, como o Oracle 11g, o IBM DB2 
Universal Database e o Informix Universal server.
Capítulo 1 
27
Linguagem de Programação
1.4.5 Modelo orientado a objetos
Os modelos em rede, hierárquico e relacional trouxeram importantes 
contribuições para a tecnologia de banco de dados, principalmente os 
comerciais. Qualquer um desses modelos foi um avanço em relação 
aos Sistemas Tradicionais de Arquivos. Dentre os três modelos acima, 
o relacional merece destaque, pois, desde a década de 1980, tornou-
se padrão de mercado no desenvolvimento de aplicações comerciais, 
como controle de estoques, contas a pagar e a receber, frente de loja, 
recursos humanos etc.
Contudo, a complexidade de novas demandas tecnológicas como os 
sistemas de informações geográficas e multimídias evidenciaram as 
limitações desses modelos de bancos de dados. As novas aplicações 
precisavam suportar estruturas complexas de dados para objetos, as-
sim como o armazenamento de imagens digitalizadas e textos muito 
longos (NAVATE, 2005).
Outro fator que pressionou positivamente o desenvolvimento de um mo-
delo orientado a objeto (OO) para banco de dados é a predominância de 
linguagens de programação orientadas a objeto. Logo, programadores 
de aplicações convivem com os dois paradigmas de desenvolvimento: 
modelo relacional para bancos de dados e orientação a objetos para os 
programas que trabalham com esses mesmos bancos. Tudo seria mais 
simples se aplicações e bancos que dão suporte à persistência de seus da-
dos fossem igualmente orientados a objetos, não sendo mais necessário 
o mapeamento objeto-relacional para combinar as duas tecnologias.
Infelizmente, bancos de dados orientados a objetos ainda não foram 
bem aceitos pelo mercado. Em parte, essa rejeição é explicada pela sim-
plicidade e popularidade de que o modelo relacional ainda goza jun-
to aos profissionais de informática. Portanto, muitos desenvolvedores 
optam por uma solução híbrida como o já comentado modelo objeto-
relacional também conhecido como modelo relacional estendido.
Modelo Orientado a Objetos é abordado na disciplina referente 
a Análise e Projeto de Sistemas.
Conceitos de Banco de Dados 
28
Técnico em Informática
Capítulo 1 
Atividade 06
Liste em ordem cronológica os modelos de bancos de dados.
Atividade 07
Cite as causas que levaram ao surgimento do Modelo Orientado a 
Objetos de Banco de Dados.
Atividade 08
Por que bancos de dados orientados a objetos não se tornaram po-
pular no mercado? Poderíamos afirmar que a tecnologia de ban-
co de dados estagnou no modelo relacional incorporando poucas 
inovações desde o início da década de 1970?
Atividade 09
As tabelas abaixo correspondem ao modelo relacional de banco 
de dados. Converta esses dados para:
a) o modelo redes, e
b) o modelo hierárquico (lembre de começar dos dados mais ge-
rais para os mais específicos dentro da árvore)
Matricula
Funcionário:
Cargos:
Nome CPF Cargo
01 Ana 123 02
02 Maria 234 01
03 José 245 03
04 Pedro 125 01
Código Nome Cargo
01 Programador
02 Topógrafo
03 Engenheiro
29
Linguagem de Programação
MODELAGEM DE DADOS
Olá!
Imagino que esteja ansioso por “colocar a mão na massa” – imple-
mentar um banco de dados na prática. Isso é bom, mas ainda deve-
mos conter nossa ansiedade.
Antes de sair criando tabelas, relacionamentos e consultas, devemos 
aprender a projetar um banco de dados que atenda satisfatoriamen-
te aos objetivos de nossos usuários.
Um banco de dados bem modelado demandará pouca ou nenhuma 
manutenção corretiva num futuro próximo. Por isso, é conveniente des-
pender parte de seu tempo inicial de trabalho projetando ou modelan-
do o banco de dados propriamente dito. Uma vez concluída essa etapa, 
pode-se finalmente dedicar tempo à criação do banco de dados com 
suas tabelas, relacionamentos, consultas, visões, procedimentos etc.
Na modelagem de um banco de dados, nos concentramos nos 
objetivos que pretendemos atender com essa tecnologia. Se pre-
tendemos criar um banco de dados para um sistema de controle 
acadêmico que permita armazenar dados sobre alunos, turmas, 
disciplinas, notas e frequências, quais serão as tabelas necessárias 
e seus respectivos atributos?
E se o sistema objetivar gerenciar o atendimento de consultas médicas 
em uma clínica? Certamente serão outras as tabelas e atributos neces-
sários. Mas, quais serão essas tabelas e como se relacionarão entre si?
Neste capítulo abordaremos a modelagem conceitual de dados. Um 
modelo conceitual objetiva projetar os requisitos de negócio segundo 
a perspectiva do usuário-final. Tendo em vista apenas o modelo re-
lacional de banco de dados, não precisamos ainda determinar qual 
SGBD utilizaremos para implementar nosso banco de dados, não 
importando se o SGBD será o Oracle,o Microsoft SQL-Server, o 
Sybase, o PostgreeSQL, o Firebird ou o MySQL. O que modelaremos 
pode ser implementado em qualquer SGBD relacional.
Trabalharemos, com especial destaque, com o Modelo de Entidade e 
Relacionamentos (ER).
Bom estudo!
Prof. Vanderson José Ildefonso Silva
30
Técnico em Informática
2.1 Modelo entidade-relacionamento
O Modelo Entidade-Relacionamento (MER) é uma técnica criada em 
1976 por Peter Chen (CHEN, 1990) que expressa graficamente a estru-
tura lógica de um banco de dados. A aplicação dessa técnica resulta na 
elaboração de um diagrama composto dos seguintes elementos:
Entidades:1. representadas graficamente por um retângulo, as entida-
des são “coisas” ou “objetos” que deverão ser armazenados em um 
banco de dados. Médico e paciente, por exemplo, são claramente 
entidades em um banco de dados projetado para suportar um sis-
tema de agendamento de consultas (Figura 6). Afinal, tal sistema 
seria impossível de implementar sem o armazenamento de dados 
relativos aos médicos que atendem na clínica e aos pacientes que 
agendam consultas com esses profissionais.
 Figura 6 – Representação Gráfica das Entidades Médico e Paciente
Atributos: 2. são características ou propriedades relevantes de uma 
entidade. Por “relevantes” pretendemos destacar que nem todas as 
informações sobre uma entidade são pertinentes para o modelo: sa-
ber qual a cor do cabelo do paciente ou o time de futebol para o qual 
um médico torce em nada contribui para a marcação de uma con-
sulta. Por outro lado, o nome do paciente, sua data de nascimento 
(forma de manter atualizada sua idade), um telefone para contato, o 
endereço e o sexo a que pertence (“feminino” ou “masculino”) são 
informações que podem ser classificadas como relevantes para o 
contexto (Figura 7).
 Figura 7 – Entidades e seus respectivos atributos
Médico Paciente
Médico
Nr_CRM
Nome
Celular
Paciente
Matricula
Nome
Endereço
Telefone
Celular
Genero
Capítulo 2 
31
Linguagem de Programação
Relacionamentos: 3. são vínculos ou associações lógicas entre duas 
ou mais entidades. Em alguns casos particulares, um relacionamen-
to pode ser estabelecido entre uma entidade e ela mesma (autor-
relacionamento). Porém, a forma mais comum de relacionamento 
é entre duas entidades. As Figuras 8, 09 e 10 apresentam variados 
exemplos de relacionamentos. Eles são representados por uma linha 
com um losango sobreposto e um verbo que o identifica. No inte-
rior desse losango há geralmente uma seta indicando o sentido da 
leitura do verbo. Na Figura 8, por exemplo, podemos ler que “mé-
dico atende paciente”. Por sua vez, a Figura 09 demonstra um rela-
cionamento entre três entidades simultaneamente (relacionamento 
ternário). Nesse caso não usamos o verbo e nem a seta, apenas o 
losango na junção das linhas. A vantagem desse relacionamento em 
relação ao da Figura 08 é que se torna possível saber qual o plano 
de saúde utilizado pelo paciente em uma determinada consulta com 
um dado médico. A Figura 10 exemplifica um relacionamento entre 
uma entidade e ela mesma (o autorrelacionamento). Nesse caso, um 
funcionário pode coordenar os trabalhos de outros funcionários. 
Esse relacionamento nos permite identificar quais funcionários são 
coordenados por outros funcionários.
Figura 8 – Relacionamento entre duas entidades
Figura 09– Relacionamento entre três entidades (ternário)
Figura 10 – Relacionamento de uma entidade consigo mesma(autorrelacionamento)
Médico Paciente
atende
Médico
Plano de Saúde
Paciente
coordena
Funcionário
Modelagem de Dados
32
Técnico em Informática
Atividade 10
Faça um diagrama que demonstre relacionamentos coerentes en-
tre as seguintes entidades de um Restaurante: Mesa, Prato, Gar-
çon e Comanda (pedidos feitos pelos ocupantes da mesa). Indique 
para cada entidade um conjunto de atributos adequados.
2.1.1 A Cardinalidade de relacionamentos
A cardinalidade é uma característica de todo relacionamento no Mo-
delo Entidade-Relacionamento (MER). Indica com quantas ocor-
rências de uma entidade as ocorrências de uma outra entidade po-
dem se relacionar.
A Figura 11 mostra um autorrelacionamento ainda sem a indicação 
da cardinalidade. A novidade do exemplo está na utilização dos cha-
mados indicadores de papéis (“Marido” e “Esposa”). Ele pode ser 
lido como “pessoa casa com pessoa”. A indicação dos papéis apenas 
torna claro que, no casamento, algumas pessoas têm o papel de ma-
rido e outras, o de esposa.
Figura 11– Autorrelacionamento com indicação de Papéis.
A ausência de cardinalidade nos impossibilita uma melhor compreen-
são das regras envolvidas nesse casamento entre pessoas. Em algumas 
sociedades é permitido que um homem se case com várias mulheres. 
Caso nosso banco de dados precise refletir esse costume, devemos im-
por um relacionamento de cardinalidade um-para-muitos (1:N), como 
mostrado na Figura 12.
casa com
Pessoa
Marido Esposa
Capítulo 2 
33
Linguagem de Programação
Figura 12 – Cardinalidade Um-para-Muitos (1:N)
O relacionamento da Figura 12 exemplifica as regras de uma sociedade 
poligâmica, na qual um homem pode ter várias esposas. Então lemos 
que “uma (1) pessoa (Marido) pode casar-se com muitas (N) pesso-
as (Esposas)”. Define, também, que “uma pessoa (Esposa) somente 
pode casar-se com uma pessoa (Marido)”. Portanto, os direitos não 
são iguais nessa sociedade e a cardinalidade define isso com clareza. Um 
homem pode ter várias mulheres, mas uma mulher pode ter apenas um 
homem como marido.
Os atributos da entidade Pessoa evidenciados na figura acima são:
Identificador:1. código que possibilite distinguir uma pessoa de ou-
tra sem que haja confusões.
Nome:2. nome completo da pessoa. Não serviria para identificar com 
precisão uma pessoa, dada a possibilidade da ocorrência de homô-
nimos (pessoas com o mesmo nome. Ex: José da Silva).
Sexo:3. classificação das pessoas conforme seu sexo: “F” para femini-
no e “M” para masculino.
IdentificadorMarido: 4. atributo que será utilizado apenas pelas pessoas 
do sexo feminino. Geralmente, sociedades poligâmicas não demons-
tram tolerância com casamentos de pessoas do mesmo sexo. Esse atri-
buto ou terá valor nulo (para homens e mulheres solteiras) ou conterá 
o identificador de uma pessoa do sexo masculino (o marido).
A Figura 13 apresenta uma tabela em banco de dados relacional que 
corresponderia a uma implementação do diagrama da figura anterior, 
no qual um homem poderia ter várias esposas, mas, uma mulher, so-
mente um marido.
casa com
Pessoa
Identificador
Nome
Sexo
IdentificadorMarido
Marido Esposa
1 N
Modelagem de Dados
34
Técnico em Informática
Figura 13 – Tabela Pessoa correspondente a Entidade Pessoa
Observamos que, pelos dados da tabela Pessoa, Altair Ramos tem três 
esposas (Martha, Sueli e Ângela). Essas mulheres possuem o seu número 
identificador na coluna (atributo) IdentificadorMarido. Por outro lado, 
Karla apresenta esse atributo sem a indicação de qualquer número (va-
lor nulo). Significa que Karla é solteira. Rita de Cássia (pessoa de identi-
ficador = 6) é casada com Ricardo Souza (pessoa de identificador = 5).
Devemos destacar que a cardinalidade indicada não implica a obriga-
toriedade de cada homem ter mais de uma esposa. No exemplo, Ricardo 
tem apenas uma esposa, e poderiam ainda existir homens solteiros.
Suponhamos agora que uma verdadeira revolução de costumes tenha 
acontecido nessa sociedade poligâmica. A partir de agora, os homens 
somente poderão se casar com uma mulher, mas uma mulher poderá 
casar-se com muitos homens (poliandria). Nosso MER sofreria uma 
alteração em sua cardinalidade, deixando de apresentar um relaciona-
mento um-para-muitos (1:N) para assumir um relacionamento mui-
tos-para-um (N:1).
A Figura 14 mostra o resultado dessa mudança para uma sociedade 
poliândrica. Curiosamente, essa figura quase não difere da Figura 12. 
As únicas alterações perceptíveis são a troca de posições entre “N” e 
“1” na indicação da cardinalidade, além da substituição doatributo 
IdentificadorMarido pelo IdentificadorEsposa. Portanto, a ordem 
dos fatores influi sobre o resultado final. O relacionamento agora indi-
ca que “uma pessoa (Marido) pode casar-se com apenas uma pessoa 
(Esposa)” e que “uma pessoa (Esposa) pode casar-se com muitas 
pessoas (Maridos)”.
Pessoa
Identificador Nome Sexo IdentificadorMarido
1 Altair Ramos M
2 Karla Ramalho F
3 Martha Ramos F 1
4 Sueli Cantagalo F 1
5 Ricardo Souza M
6 Rita de Cássia F 5
7 Ângela Paneton F 1
Capítulo 2 
35
Linguagem de Programação
 Figura 14 – Cardinalidade Muitos-para-Um
Essa estranha sociedade foi de um extremo (poligamia) a outro (polian-
dria). Agora consideremos que homens e mulheres negociaram uma sa-
ída mais equilibrada, tornando essa sociedade monogâmica. Essa nova 
situação é representada na Figura 15.
 Figura 15– Cardinalidade Um-para-Um
Mais uma vez deparamos com pequenas mudanças: o atributo Identi-
ficadorConjuge substitui o atributo IdentificadorEsposa ou Identifi-
cadorMarido; e a cardinalidade do relacionamento agora é Um-para-
Um (1:1). Não temos mais o indicador “N” (que simboliza “muitos” 
ou “vários”). Dessa forma, agora um homem pode casar-se com ape-
nas uma mulher simultaneamente e uma mulher, com somente um 
homem por vez.
Esgotamos todas as possibilidades de cardinalidade para esse relacio-
namento? Certamente que não. Ainda há a possibilidade de que um ho-
mem possa casar-se com muitas mulheres e que também uma mulher 
possa casar-se com muitos homens. Esse seria um relacionamento de 
cardinalidade Muitos-para-Muitos (N:N).
casa com
Pessoa
Identificador
Nome
Sexo
IdentificadorEsposa
Marido Esposa
1N
casa com
Pessoa
Identificador
Nome
Sexo
IdentificadorConjuge
Marido Esposa
11
Modelagem de Dados
36
Técnico em Informática
A Figura 16 exemplifica essa situação de Muitos-para-Muitos. Nes-
se caso as mudanças são substanciais e merecem uma explicação 
mais detalhada.
 Figura 16 – Cardinalidade Muitos-para-Muitos
Olhando para a Figura 16, percebemos que um retângulo tracejado 
apareceu sobre o losango do relacionamento. Essa é uma consequên-
cia direta de qualquer relacionamento de cardinalidade Muitos-para-
Muitos. Esse retângulo tracejado corresponde a uma relação e, como 
tal, possui nome (Casamento) e atributos (IdentificadorMarido e 
IdentificadorEsposa).
Transpondo essa situação para um banco de dados relacional, encontra-
mos duas tabelas: Pessoa e Casamento, exemplificado na Figura 17.
casa com
Pessoa
Identificador
Nome
Sexo
Casamento
IdentificadorMarido
IdentificadorEsposa
N N
Capítulo 2 
37
Linguagem de Programação
Figura 17 – Banco de Dados equivalente ao Modelo ER da Figura 16
Conforme os dados apresentados na Figura 17, Eduardo Licoli (Iden-
tificador = 1) possui duas ocorrências na tabela Casamento. Uma vez 
que é do sexo masculino, seu Identificador aparece na coluna (atributo) 
IdentificadorMarido. Significa que Eduardo é casado com duas mulhe-
res: Ana Paula Souza (Identificador = 2) e Cecília Castro (Identificador 
= 6). Como essas pessoas são do sexo feminino, seus identificadores são 
reproduzidos na coluna IdentificadorEsposa da tabela Casamento. Por 
analogia, Ronaldo Silvestre é casado com três mulheres: Ana Paula Sou-
za, Cibele Tornado e Cecília Castro. Sérgio Couto continua solteiro, pois 
não tem ocorrências na tabela Casamento.
Atividade 11
Acrescente a cardinalidade aos relacionamentos da Atividade 10.
2.1.2 Exemplos do modelo entidade-relacionamento
Considere um banco de dados que objetive manter informações atua-
lizadas sobre os projetos desenvolvidos por uma empresa e as equipes 
responsáveis por esses mesmos projetos. Todos os integrantes das equi-
pes são funcionários da empresa. Cada projeto é gerenciado por um 
funcionário e as equipes podem ser formadas por um número indeter-
Pessoa
Identificador Nome Sexo
1 Eduardo Lincoli M
2 Ana Paula Souza F
3 Ronaldo Silvestre M
4 Cibele Tornado F
5 Anabela Couto F
6 Cecília Castro F
7 Sérgio Souto M
Casamento
IdentificadorMarido IdentificadorEsposa
1 2
1 6
3 2
3 4
3 6
Modelagem de Dados
38
Técnico em Informática
minado de funcionários. Independentemente dos projetos, cada funcio-
nário possui uma função específica na empresa (administrador, analista 
de sistemas, contador, engenheiro, etc.).
De cada projeto importa armazenar seu número identificador, nome, data 
de início, data prevista de conclusão e data efetiva de conclusão. Em relação a 
cada funcionário é importante guardar sua matrícula, nome, sexo e função.
A Figura 18 apresenta um diagrama ER que modela o banco de dados 
proposto. Nela há três relacionamentos, três entidades e uma relação.
Observe que conforme modelado, um funcionário pode gerenciar muitos 
projetos, mas um projeto pode ser gerenciado apenas por um funcioná-
rio. Por outro lado, um funcionário pode trabalhar em muitos projetos 
(simultaneamente ou ao longo do tempo), e cada projeto pode ter muitos 
funcionários nele trabalhando. Também é verdade que um funcionário 
possui apenas uma função, mas uma função pode pertencer a muitos fun-
cionários. Portanto, um funcionário não pode ser contador e programador 
de computadores ao mesmo tempo, mas a empresa pode, por exemplo, ter 
mais de um programador de computadores dentre seus funcionários.
Como indicam os atributos do modelo, um projeto ainda em andamen-
to apresentaria a Data_Final_Efetiva com valor nulo. A existência de 
uma Data_Final_Prevista e de uma Data_Final_Efetiva permite ava-
liar o atraso de um projeto em andamento ou já concluído.
Figura 18 – Exemplo de Diagrama ER
Funcionário
Matricula
Nome
Sexo
Função
Possui
trabalha em
Id_Função
Descrição
Projeto
Equipe
1
1 N
N
N
N
Matricula
Numero
Numero
Nome
Data_Inicio
Data_Final_Prevista
Data_Final_Efetiva
Capítulo 2 
39
Linguagem de Programação
Consideremos agora a modelagem de um banco de dados desenvolvido 
para o gerenciamento de uma biblioteca. Para efeito de simplificação, 
essa biblioteca empresta apenas livros. Não há revistas ou dvds em seu 
acervo. Também é vetado ao usuário dessa biblioteca reservar um livro 
indisponível no momento como em algumas bibliotecas em que o usuá-
rio pode entrar em uma fila de reservas, de modo que, ao ser devolvido 
um exemplar do livro reservado, os usuários que fizeram a reserva po-
dem, conforme a ordem que ocupam na fila, requisitar o empréstimo do 
livro. Como dito, nossa biblioteca não dispõe desse serviço. Por outro 
lado, o banco de dados modelado deve prover os seguintes requisitos:
(1) Manter dados sobre as obras do acervo, como nome dos autores, 
data da aquisição, editora, edição e título.
(2) Manter registro de todos os livros de uma mesma obra.
(3) Efetuar o empréstimo e a devolução de livros, mantendo registros 
detalhados dos mesmos ao longo do tempo.
(4) Consultar livros por código de identificação, título da obra, nome de 
autores e gênero da obra (autoajuda, dicionário, literatura, etc.).
(5) Manter dados sobre os usuários da biblioteca: matrícula, nome, sexo, 
data de nascimento, endereço e telefone.
A Figura 19 mostra o diagrama ER para o sistema de informação dessa 
biblioteca. Não se assuste com o tamanho; embora seja maior que o an-
terior, ainda é bem menor que a média em uma situação real.
Repare que foram usadas duas entidades – Obra e Livro – em vez de 
uma com todos os seus atributos. Você deve estar se perguntando o 
porquê dessa decisão. Embora, a princípio, pareça correto utilizar 
uma entidade com todos esses atributos, na verdade eles pertencem 
a entidades diferentes.
A entidade Livro, por exemplo, refere-se a uma edição em particular de 
uma obra. Considere uma obra do século XIX, como Helena, de Ma-
chado de Assis, um clássico da literatura brasileira em sua fase român-
tica, que já foi publicada por diferentes editoras ao longo de mais de 
um século de existência. Portanto, a entidade Editora não poderia estar 
relacionada à entidade Obra, mas sim à entidade Livro, como demons-
trado na Figura 19. Se fossediferente, essa obra somente poderia ser 
publicada por uma editora.
Modelagem de Dados
40
Técnico em Informática
Figura 19 – Diagrama ER do Sistema de Gerenciamento de Biblioteca
Por analogia, o atributo Edição não pode estar na entidade Obra, mas na 
entidade Livro. Afinal, somente livros publicados de uma mesma obra 
podem ter edições diferentes. Nessa biblioteca, por exemplo, podem 
existir 30 livros da obra Helena. Desses, 10 foram publicados pela edi-
tora Guanabara em 1981 e são da quinta edição e 4 desses livros adqui-
ridos mais recentemente foram publicados pela editora Martin Claret.
A entidade Autor se relaciona à entidade Obra, pois se estivesse relaciona-
da a Livro implicaria o relacionamento pouco justificável de seus autores 
a cada livro adquirido pela biblioteca. Nesse caso, se 50 livros da obra de 
Alexandre Dumas, Os Três Mosqueteiros, fossem doados para a bibliote-
publica
referencia
classifica
escreve
movimenta
Movimentação
Autoria
1
1
1
NN
N
N
N
N
N Usuário
Matrícula
Nome
Sexo
Data_Nascimento
Telefone
Celular
E_Mail
Endereço
Matrícula
Nr_Livro
Data_Emprestimo
Data_Prevista
Data_Devolução
Autor
Id_Autor
Nome
Obra
Nr_Obra
Título
Nr_Obra
Id_Autor
Livro
Nr_Livro
Data_Aquisição
Edição
Editora
Id_Editora
Nome_Fantasia
Gênero
Id_Gênero
Descrição
Capítulo 2 
41
Linguagem de Programação
ca, um funcionário deveria relacionar sua ocorrência a 50 ocorrências de 
Livros. Contudo, o relacionamento de Autor com Obra evita esse traba-
lho. O autor Alexandre Dumas seria relacionado a uma única obra e esta, 
por sua vez, aos 50 livros dessa mesma obra. O funcionário da biblioteca 
agradece seu empenho em tornar sua tarefa menos árdua.
Olhando o diagrama ER da Figura 19, notamos que um gênero pode 
classificar várias obras, mas que uma obra pode ser classificada por um 
gênero. Assim, Helena e Os Três Mosqueteiros podem ser classificadas 
como Literatura. Porém, nenhuma dessas obras pode ser classificada em 
mais de um gênero simultaneamente.
Um autor pode escrever muitas obras e uma obra pode ser escrita por 
muitos autores. Em razão da cardinalidade N:N surgiu a relação Au-
toria (o retângulo tracejado), cobrindo a possibilidade de obras com 
mais de um autor, comum em livros didáticos ou em uma coleção de 
artigos científicos.
Um livro pode referenciar apenas uma obra, mas uma obra pode ser 
referenciada por muitos livros.
Uma editora pode publicar muitos livros, mas um livro pode ser publi-
cado apenas por uma editora.
Um usuário pode movimentar vários livros e um mesmo livro pode ser 
movimentado por vários usuários ao longo do tempo. Mais uma vez a 
cardinalidade N:N faz emergir a relação Movimentação. Essa relação ar-
mazena os empréstimos e devoluções de livros efetuados na biblioteca.
Quando a biblioteca empresta um livro para um usuário, uma ocorrên-
cia de movimentação é gerada com o atributo Data_Devolução nulo e 
Data_Empréstimo com a data atual do sistema. Na devolução do livro 
essa movimentação é atualizada com a alteração do atributo Data_De-
volução para a data corrente do sistema.
Um terceiro e último exemplo de um diagrama ER está na Figura 20.
Modelagem de Dados
42
Técnico em Informática
Figura 20 – Diagrama ER para Marcação de Consultas Médicas
Nesse caso temos um banco de dados modelado para suportar um sis-
tema de gerenciamento da marcação de consultas médicas. Na verda-
de, deve estar lembrado, já fizemos algumas considerações acerca desse 
contexto (Figuras 7 a 10), mas ainda não havíamos apresentado seu 
diagrama completo.
O referido diagrama foi modelado a partir dos seguintes requisitos:
armazenar dados de médico: número de registro no Conselho Re-1. 
gional de Medicina (CRM), nome completo, sexo, telefone fixo, ce-
lular e e-mail para contato.
armazenar informações de paciente: número identificador, nome 2. 
completo, sexo, telefone fixo e celular.
identificar as especialidades de cada médico (um mesmo médico 3. 
pode atuar, por exemplo, como clínico geral e dermatologista).
agendar consultas para um paciente, especificando o plano de saúde 4. 
e o médico.
possui
N N
N
N
N
Médico
CRM
Nome
Sexo
Telefone
Celular
E-Mail
Paciente
Consulta
Especialista
Id_Paciente
Nome
Sexo
Telefone
Celular
Especialidade
Cod_Especialidade
Descrição
Plano_Saude
Id_Plano
Nome_Fantasia
CRM
Cod_Especialidade
CRM
Data
Hora
Id_Plano
Id_Paciente
Capítulo 2 
43
Linguagem de Programação
como simplificação do modelo não será necessário armazenar os 5. 
horários de atendimento semanal para cada médico. Considerare-
mos apenas que todos os médicos atendem todos os dias úteis da 
semana em um horário fixo e igual para todos.
Note que Consulta é uma relação gerada a partir de um relacionamento 
ternário entre as entidades Médico, Paciente e Plano_Saúde.
2.1.3. Generalização / especialização de entidades
Existem situações em que diferentes entidades apresentam algumas ca-
racterísticas em comum, divergindo apenas em algumas outras poucas 
características. Na Figura 21, por exemplo, temos duas entidades nessa 
condição de semelhança: Médico e Paciente.
 Figura 21 – Entidades com Atributos em Comum
Essas entidades foram extraídas do exemplo de diagrama ER da Figura 
21. Repare que ambas apresentam 4 atributos em comum: nome, sexo, 
telefone e celular. Médico ainda possui dois atributos exclusivos: CRM 
e e-mail. Por sua vez, a entidade Paciente apresenta um único atributo 
somente seu: Id_Paciente.
Nesse e em casos semelhantes podemos lançar mão de um recurso pre-
visto na modelagem de dados, conhecido como generalização. Então, 
uma nova entidade, mais genérica – ou se preferir, menos especializada 
– deve ser criada para agregar os atributos comuns.
Na Figura 22 temos uma entidade de nome Pessoa que assume esse papel de 
entidade menos especializada. Essa nova entidade chama para si os atribu-
tos comuns das entidades mais especializadas: Médico e Paciente. O símbolo 
triangular que interliga essas entidades indica que os atributos de Pessoa são 
compartilhados por Médico e Paciente, ou seja, Médico e Paciente herdam os 
atributos de Pessoa. Entretanto, o atributo de Id_Paciente pertence somente a 
Paciente; e CRM e E_Mail são atributos exclusivos de Médico.
Médico
CRM
Nome
Sexo
Telefone
Celular
E_Mail
Paciente
Id_Paciente
Nome
Sexo
Telefone
Celular
Modelagem de Dados
44
Técnico em Informática
Figura 22 – Exemplo de Generalização / Especialização
Generalização: entidades de um nível mais baixo de abstração, 
com características comuns; são agrupadas, dando origem a uma 
entidade de nível mais alto.
Especialização: uma entidade de nível mais alto de abstração é 
desmembrada em várias entidades de nível mais baixo, com ca-
racterísticas parcialmente distintas.
Atividade 12
Construa um diagrama ER completo para um sistema de super-
mercado que permita as seguintes funcionalidades:
(1) Manter informações sobre produtos (código, nome, preço uni-
tário, quantidade em estoque e estoque mínimo);
(2) Registrar vendas de produtos nos caixas;
(3) Registrar recebimentos – discriminando o tipo: em dinheiro, 
cheque, cartão de débito, ou cartão de crédito.
Pessoa
Nome
Sexo
Telefone
Celular
Paciente
Id_Paciente
Médico
CRM
E_Mail
Capítulo 2 
45
Linguagem de Programação
2.1.4 Entidades fracas
Uma entidade fraca é qualquer entidade cuja existência no modelo ER 
não se justiça por si mesma. Essa entidade surge apenas em razão do 
relacionamento desta com uma outra entidade, considerada forte. A 
chamada entidade fraca deve apresentar identificadores compostos 
(formados pelo menos por dois atributos). Um desses atributos deve 
ser originário da entidade forte. Ele é replicado na entidade fraca para 
estabelecer uma ligação entre ocorrências das duas entidades.
Um exemplo clássico de entidade fraca é demonstrado na Figura 23. 
Dependente é a entidade fraca, pois a identificação de um dependente 
é impossível sem a identificação do sócio. Na verdade, os dependentes 
não existiriam se não houvesseos sócios.
Figura 23 – Exemplo de Entidade Fraca (Dependente)
2.2 Modelo relacional normalizado
O Modelo Entidade-Relacionamento (MER) constitui apenas a pri-
meira etapa da chamada modelagem de dados para a implementação 
de um banco de dados que poderá ser parte de um sistema de banco de 
dados. Desenvolvido pelo analista de sistemas, o MER é considerado 
um modelo conceitual do banco de dados em implementação. Como 
afirmado anteriormente, o MER pode ser elaborado antes mesmo da 
definição do Sistema Gerenciador de Banco de Dados (SGBD) em que 
a solução será implementada. A única restrição imposta pelo modelo 
ER é a escolha de um SGBD também relacional.
Uma vez concluída esta etapa, a equipe de analistas de sistemas deve ocu-
par-se do projeto lógico do banco de dados, também conhecido como 
1 N
Sócio
Id_Sócio
Nome
Sexo
Endereço
Telefone
CPF
RG
Data_Nascimento
Id_Sócio
Id_Dependente
Nome
Sexo
Data_Nascimento
Dependente
Modelagem de Dados
46
Técnico em Informática
o Modelo Relacional Normalizado (MRN). Nessa fase o projetista deixa 
de ocupar-se exclusivamente com os requisitos levantados junto ao usuá-
rio demandante do banco de dados. Não que esteja autorizado a ignorar 
as necessidades e desejos do usuário e possa, a partir de agora, impor di-
tatorialmente a sua própria vontade. Em momento algum os requisitos do 
usuário-final devem ser ignorados. Ao ocupar-se com o MRN, o analista 
de sistemas deve também preocupar-se com a forma de armazenamento 
das informações em um banco de dados relacional.
Na elaboração do modelo conceitual do banco de dados (o modelo ER), 
ignoramos alguns importantes conceitos que, agora, durante o modelo 
lógico, não podemos mais deixar de considerar. O mais básico desses con-
ceitos e nosso ponto de partida nesta etapa é a chamada chave primária.
2.2.1 Chave primária
Em bancos de dados relacionais as informações são armazenadas em ta-
belas, sendo essencialmente organizadas em linhas e colunas. Cada linha 
de uma tabela corresponde a uma ocorrência da informação. Assim, em 
uma tabela de alunos (Figura 24), cada linha (ou registro) corresponde ao 
conjunto de informações inter-relacionadas de um aluno em particular. 
As colunas (ou campos) correspondem a subdivisões lógicas ou compar-
timentos para diferentes informações contidas em uma mesma linha.
Na tabela Aluno da Figura 24, cada linha foi subdividida em 5 colunas 
(Matrícula, Nome, Sexo, Nascimento e Curso). No exemplo apresenta-
do existem 6 linhas armazenando as informações de 6 diferentes alunos 
de uma instituição de ensino. Os dados armazenados nas colunas de 
uma mesma linha são relativos a um mesmo aluno. Assim, podemos 
afirmar que o aluno de nome Rodrigo Bívar tem matrícula 1099, é do 
sexo masculino, nasceu em 25 de dezembro de 1992 e cursa informática. 
Também podemos confirmar que a aluna Karina Gonçalves encontra-se 
matriculada no curso de Biologia com a matrícula 1203.
Figura 24 – Tabela Aluno
Aluno
Matrícula Nome Sexo Nascimento Curso
1099 Rodrigo Bívar M 25/12/1992 Informática
1100 Ximene Lascasas F 13/09/1996 Informática
1203 Karina Gonçalves F 03/11/1998 Biologia
1399 José da Silva M 27/02/1995 Matemática
1500 Cesário Antunes M 16/12/1999 Farmácia
1701 José da Silva M 03/10/1991 Informática
Capítulo 2 
47
Linguagem de Programação
Uma tabela como essa pode armazenar centenas ou milhares de linhas (re-
gistros). Imaginar a complexidade da tarefa de localizar um registro espe-
cífico em meio a milhares de outros na mesma tabela é algo que não exige 
muito esforço. Uma ou mais colunas podem servir para identificar uma li-
nha em específico, distinguindo-a de todas as demais linhas existentes.
Supondo que desejamos acessar os dados de um aluno em específico, a 
busca pela linha que armazena esses dados deve ser parametrizada pelo 
valor de uma ou mais colunas, mas não de qualquer coluna. Afinal, di-
ferentes alunos podem, por exemplo, ter o mesmo nome. Na Figura 24, 
essa situação encontra-se exemplificada nas linhas 4 e 6 da tabela, onde 
estão registrados dois alunos de nome José da Silva. A possibilidade de 
ocorrência de alunos homônimos desqualifica a coluna nome como uma 
coluna adequada para a identificação de um registro em particular.
A Figura 25 mostra o resultado de uma busca na tabela Aluno com o 
critério de pesquisa Nome = “José da Silva”. O fato dessa busca/con-
sulta resultar na apresentação de mais de uma linha evidencia a inade-
quação da coluna Nome na identificação de uma linha em particular. 
Embora com mesmo nome, os alunos são pessoas diferentes, com datas 
de nascimento distintas.
Figura 25 – Resultado da Busca por Aluno de Nome = “José da Silva”
Por outro lado, a utilização da coluna Matrícula como critério de pes-
quisa mostra-se perfeitamente adequada para a identificação de uma 
única linha. Afinal, não podem existir dois alunos com um mesmo nú-
mero de matrícula. A Figura 26 exemplifica o resultado de uma busca 
utilizando a coluna Matrícula como critério de pesquisa.
Figura 26 – Resultado da Busca por Aluno de Matrícula = 1701
 
Matrícula Nome Sexo Nascimento Curso
1399 José da Silva M 27/02/1995 Matemática
1701 José da Silva M 03/10/1991 Informática
 
Matrícula Nome Sexo Nascimento Curso
M1701 José da Silva 03/10/1991 Informática
Modelagem de Dados
48
Técnico em Informática
Ao conjunto de um ou mais atributos que permite identificar 
com precisão uma única linha de uma tabela dá-se o nome de 
superchave.
Na Figura 27 é apresentada a entidade Funcionário dotada de 12 atri-
butos. Destes, podemos selecionar algumas superchaves: Carteira_
Identidade é certamente uma superchave, pois não deve existir mais 
de um funcionário com o mesmo número da carteira de identidade. 
Entretanto, essa não é a única superchave. CPF também pode ser 
considerado uma superchave, assim como a combinação de atributos 
{Nome e Carteira_Identidade}, ou {Nome e CPF}, ou ainda {Nome, 
Carteira_Identidade e CPF}.
Figura 27 – Atributos da Entidade Funcionário
Como destacado anteriormente, o atributo Nome isoladamente não 
pode ser considerado uma superchave. Porém, sua combinação com 
outros atributos pode formar superchaves. É o caso da combinação 
{Nome, Logradouro}.
Nome
Sexo
Data_Nascimento
Carteira_Identidade
CPF
Logradouro
Complemento
Bairro
Cidade
UF
CEP
Telefone
Funcionário
Capítulo 2 
49
Linguagem de Programação
Chaves candidatas são um subconjunto específico das chamadas 
superchaves. Somente podem ser chaves candidatas as chamadas 
superchaves mínimas.
Ou seja, uma superchave formada pela combinação de mais de 
um atributo pode ser classificada como uma chave candidata 
apenas se essa combinação não possuir qualquer subconjunto 
próprio que seja ele mesmo uma superchave. Veja o exemplo do 
CPF a seguir.
Portanto, a combinação de atributos {Nome, CPF}, apesar de ser super-
chave, não pode ser uma chave candidata, pois {CPF} também é super-
chave e subconjunto da combinação. O mesmo vale para a combinação 
{Carteira_Identidade, CPF, Nome}, que não é chave candidata, pois 
existem inúmeros subconjuntos que são superchaves.
A entidade Funcionário possui várias chaves candidatas: {CPF}, {Car-
teira_Identidade} e {Nome, Logradouro}.
Chave primária é uma chave candidata escolhida pelo projetista 
de banco de dados. Ela é o principal meio de identificação unívoca 
de uma linha em uma entidade.
Toda chave primária obedece às seguintes regras:
(1) Não pode conter valor nulo (a chave primária é de preenchi-
mento obrigatório. Não pode ser omitida);
(2) Não pode conter valores duplicados (não pode existir na enti-
dade mais de uma linha com o mesmo valor de chave primária).
A Figura 28 mostra as entidades e relações do sistema de marca-
ção de consultas com suas respectivas chaves primárias. Observe 
que a distinção na representação gráfica entre entidades e relações 
desapareceu. De fato, no Modelo Relacional Normalizado (MRN) 
as relações deixam de ser representadas por linhas tracejadas e são 
tratadas como as entidades.
Modelagem