Apostila - Sistemas de banco de dados

Prévia do material em texto

Brasília-DF. 
SiStemaS de Banco de dadoS
Elaboração
Taylor Montedo Machado
Produção
Equipe Técnica de Avaliação, Revisão Linguística e Editoração
Sumário
APRESENTAÇÃO ................................................................................................................................. 5
ORGANIZAÇÃO DO CADERNO DE ESTUDOS E PESQUISA .................................................................... 6
INTRODUÇÃO.................................................................................................................................... 8
UNIDADE I
INTRODUÇÃO À MODELAGEM CONCEITUAL .......................................................................................... 9
CAPÍTULO 1
BANCOS DE DADOS E SEUS USUÁRIOS ...................................................................................... 9
CAPÍTULO 2
CONCEITOS E ARQUITETURAS DE UM SGBD ............................................................................ 18
CAPÍTULO 3
MODELAGEM DE DADOS UTILIZANDO O MER ......................................................................... 33
UNIDADE II
SISTEMAS DE BANCO DE DADOS: CONCEITOS E ARQUITETURAS ........................................................... 49
CAPÍTULO 1
MODELO DE DADOS RELACIONAL ......................................................................................... 49
CAPÍTULO 2
PROJETO DE BANCO DE DADOS RELACIONAL UTILIZANDO O MER .......................................... 57
CAPÍTULO 3
SQL – STRUCTURED QUERY LANGUAGE ................................................................................ 61
UNIDADE III
TEORIA E METODOLOGIA DO PROJETO DE BANCO DE DADOS ......................................................... 95
CAPÍTULO 1
DEPENDÊNCIA FUNCIONAL E NORMALIZAÇÃO ....................................................................... 95
CAPÍTULO 2
METODOLOGIA PARA PROJETO PRÁTICO DE BANCO DE DADOS .......................................... 108
UNIDADE IV
ARMAZENAMENTO DE DADOS, INDEXAÇÃO, PROCESSAMENTO DE CONSULTAS E PROJETO FÍSICO .... 111
CAPÍTULO 1
ALGORITMOS PARA PROCESSAMENTO E OTIMIZAÇÃO DE CONSULTAS .................................. 111
CAPÍTULO 2
TÉCNICAS DE CONTROLE DE CONCORRÊNCIA .................................................................... 116
CAPÍTULO 3
TÉCNICAS DE RECUPERAÇÃO DE DADOS ............................................................................. 127
PARA (NÃO) FINALIZAR ................................................................................................................... 145
REFERÊNCIAS ................................................................................................................................ 146
5
Apresentação
Caro aluno
A proposta editorial deste Caderno de Estudos e Pesquisa reúne elementos que se entendem 
necessários para o desenvolvimento do estudo com segurança e qualidade. Caracteriza-se pela 
atualidade, dinâmica e pertinência de seu conteúdo, bem como pela interatividade e modernidade 
de sua estrutura formal, adequadas à metodologia da Educação a Distância – EaD.
Pretende-se, com este material, levá-lo à reflexão e à compreensão da pluralidade dos conhecimentos 
a serem oferecidos, possibilitando-lhe ampliar conceitos específicos da área e atuar de forma 
competente e conscienciosa, como convém ao profissional que busca a formação continuada para 
vencer os desafios que a evolução científico-tecnológica impõe ao mundo contemporâneo.
Elaborou-se a presente publicação com a intenção de torná-la subsídio valioso, de modo a facilitar 
sua caminhada na trajetória a ser percorrida tanto na vida pessoal quanto na profissional. Utilize-a 
como instrumento para seu sucesso na carreira.
Conselho Editorial
6
Organização do Caderno 
de Estudos e Pesquisa
Para facilitar seu estudo, os conteúdos são organizados em unidades, subdivididas em capítulos, de 
forma didática, objetiva e coerente. Eles serão abordados por meio de textos básicos, com questões 
para reflexão, entre outros recursos editoriais que visam a tornar sua leitura mais agradável. Ao 
final, serão indicadas, também, fontes de consulta, para aprofundar os estudos com leituras e 
pesquisas complementares.
A seguir, uma breve descrição dos ícones utilizados na organização dos Cadernos de Estudos 
e Pesquisa.
Provocação
Textos que buscam instigar o aluno a refletir sobre determinado assunto antes 
mesmo de iniciar sua leitura ou após algum trecho pertinente para o autor 
conteudista.
Para refletir
Questões inseridas no decorrer do estudo a fim de que o aluno faça uma pausa e reflita 
sobre o conteúdo estudado ou temas que o ajudem em seu raciocínio. É importante 
que ele verifique seus conhecimentos, suas experiências e seus sentimentos. As 
reflexões são o ponto de partida para a construção de suas conclusões.
Sugestão de estudo complementar
Sugestões de leituras adicionais, filmes e sites para aprofundamento do estudo, 
discussões em fóruns ou encontros presenciais quando for o caso.
Praticando
Sugestão de atividades, no decorrer das leituras, com o objetivo didático de fortalecer 
o processo de aprendizagem do aluno.
Atenção
Chamadas para alertar detalhes/tópicos importantes que contribuam para a 
síntese/conclusão do assunto abordado.
7
Saiba mais
Informações complementares para elucidar a construção das sínteses/conclusões 
sobre o assunto abordado.
Sintetizando
Trecho que busca resumir informações relevantes do conteúdo, facilitando o 
entendimento pelo aluno sobre trechos mais complexos.
Exercício de fixação
Atividades que buscam reforçar a assimilação e fixação dos períodos que o autor/
conteudista achar mais relevante em relação a aprendizagem de seu módulo (não 
há registro de menção).
Avaliação Final
Questionário com 10 questões objetivas, baseadas nos objetivos do curso, 
que visam verificar a aprendizagem do curso (há registro de menção). É a única 
atividade do curso que vale nota, ou seja, é a atividade que o aluno fará para saber 
se pode ou não receber a certificação.
Para (não) finalizar
Texto integrador, ao final do módulo, que motiva o aluno a continuar a aprendizagem 
ou estimula ponderações complementares sobre o módulo estudado.
8
Introdução
Ao olharmos para os processos modernos que nos prestam serviços ou mesmo nos que somos 
os próprios prestadores de serviços, é possível inferir que existem gigantescas bases de dados 
que dão suporte ou até mesmo gerenciam nossas vidas. Questões como a nossa conta bancária. 
As instituições bancárias mantêm bancos de dados que permitem o gerenciamento de todas as 
transações financeiras realizados. São esses registros que permitem que seja possível acompanhar 
saldos, aplicações, saques e manter todo histórico de cada conta de cada cliente.
Processos como a apuração das eleições ou mesmo o processamento da declaração do imposto de 
renda também são suportados por bancos de dados mantidos pelo governo e que permitem que seja 
possível, como no caso deste último, acompanhar o histórico de cada cidadão.
Objetivos
 » Contribuir para a capacitação do participante quanto à análise, planejamento, 
estruturação e implementação de sistemas de gerenciamento de banco de dados.
 » Apresentar aos participantes os principais conceitos sobre modelagem, projeto, 
implementação de sistemas de gerenciamento de banco de dados.
 » Estimular a conscientização das potencialidades e restrições inerentes aos sistemas 
de gerenciamento de banco de dados.
9
UNIDADE I
INTRODUÇÃO 
À MODELAGEM 
CONCEITUAL
CAPÍTULO 1
Bancos de dados e seus usuários
Hoje em dia o termo banco de dados é bastante popular em diversas áreas de 
atuação. Com o aumento da utilização de computadores na manipulação de dados 
que envolvem diversas aplicações, os bancos de dados estão sendo desenvolvidos 
e aplicados nas diferentes áreas que envolvem o comércio, a indústria, a pesquisa 
acadêmica, entre outras.
Introdução
Segundo Silberschatz (2006), um banco de dadosé um conjunto de dados inter-relacionados. 
Podemos afirmar que esses bancos possuem informações que representam o dia a dia de uma 
empresa, de uma loja, de uma locadora de vídeo, enfim, de qualquer ambiente que possa ter suas 
informações coletadas e representadas de uma forma organizada. Tais bancos de dados, além de 
manter todo esse volume de dados organizado, também devem permitir atualizações, inclusões e 
exclusões de dados, sem nunca perder a consistência. E, além disso, é necessário considerar que 
muitas vezes estaremos lidando com vários acessos simultâneos e concorrentes em várias partes 
diferentes de nosso banco de dados.
Heuser (2001) define dado como sendo um fato do mundo real que está registrado e possui um 
significado implícito no contexto de um domínio de aplicação. Um banco de dados possui as 
seguintes propriedades:
 » é uma coleção lógica coerente de dados com um significado inerente; uma disposição 
desordenada dos dados não pode ser referenciada como um banco de dados;
 » é projetado, construído e populado com dados para um propósito específico; um 
banco de dados possui um conjunto pré-definido de usuários e aplicações;
 » é representado por algum aspecto do mundo real, o qual é chamado de minimundo; 
qualquer alteração efetuada no minimundo é automaticamente refletida no banco 
de dados.
10
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
Um banco de dados pode ser criado e mantido por um conjunto de aplicações desenvolvidas 
especialmente para a tarefa, denominada Sistema de Gerenciamento de Banco de Dados 
(SGBD). Um SGBD permite aos usuários criar e manipular bancos de dados de propósitos gerais. 
Silberschatz (2006) define SGBD como sendo uma coleção de dados inter-relacionados e um 
conjunto de programas para acessar esses dados. 
Metadados
Uma característica importante da abordagem Banco de Dados é que o SGBD mantém não somente 
os dados, mas também a forma como esses são armazenados, uma vez que contém uma descrição 
completa do banco de dados. 
Essas informações são armazenadas no catálogo do SGBD, o qual contém informações como a 
estrutura de cada arquivo, o tipo e o formato de armazenamento de cada tipo de dado, restrições. 
Segundo Heuser (2001), o conjunto de informações armazenadas no catálogo de dados é 
denominado Metadados. 
No processamento tradicional de arquivos, o programa que irá manipular os dados deve conter 
este tipo de informação, ficando limitado a manipular as informações que ele conhece. Por outro 
lado, utilizando a abordagem banco de dados, a aplicação pode manipular diversas bases de dados 
diferentes.
Programas versus dados
O processamento tradicional de arquivos pressupõe que a estrutura de dados está incorporada 
ao próprio programa de acesso. Assim sendo, uma alteração na estrutura de arquivos resulta na 
alteração do código fonte de todos os programas. Porém, a abordagem de banco de dados permite 
que as alterações sejam efetuadas apenas no catálogo de dados, sem necessitar alterações nos 
programas de acesso.
Abstração de dados
Uma das funções de um SGBD é fornecer aos usuários uma representação conceitual dos dados sem 
que, para tanto, necessite fornecer muitos detalhes de como os dados estão armazenados.
Um Modelo de Dados é uma forma de abstração dos dados que é utilizada para fornecer essa 
representação conceitual, utilizando conceitos lógicos como objetos, suas propriedades e seus 
relacionamentos (ALVES, 2004). 
Os níveis de abstração têm como função, inclusive, ocultar a complexidade e simplificar o processo 
de interação com os usuários. Sob esse ponto de vista, podemos classificar a abstração em três níveis 
(SILBERSCHATZ, 2006).
11
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
 » Físico: é o nível de abstração mais baixo e descreve como os dados são realmente 
armazenados no banco de dados. Nesse nível, um registro de dado pode ser descrito 
como um bloco consecutivo de memória.
 » Lógico: é nível de abstração intermediário, que descreve que os dados estão 
armazenados no banco de dados e quais são as relações existentes entre eles. 
Nesse nível, um registro de dado é descrito por um tipo definido (como um tipo em 
linguagem de programação) e as inter-relações entre dados são definidas.
 » Visualização: é o nível de abstração mais alto, que descreve a parte do banco de 
dados de maior interesse para o usuário final. Nesse nível, podemos dizer que 
se trata de subconjunto de dados que podem existir apenas durante a execução de 
uma operação.
Múltiplas visões de dados
Uma vez que um banco de dados deve permitir o acesso de um conjunto diverso de usuários a todo 
o seu conteúdo, é possível inferir que cada usuário, ou grupo de usuários, pode ter uma necessidade 
específica. Desse modo, é necessário que cada conjunto de usuário tenha a possibilidade de ter 
visões diferentes da base de dados.
Assim, uma visão é definida como um subconjunto de uma base de dados, formando desse modo, 
um conjunto virtual de informações (SILBERSCHATZ, 2006).
Usuários
Em todo grande banco de dados existe um grande número de pessoas envolvidas que varia desde 
sua concepção e seu projeto até sua manutenção.
Administrador de Banco de Dados (DBA)
Um ambiente de banco de dados envolve vários recursos que vão desde o banco de dados em si 
até o SGBD e outros softwares. Cabe ao Administrador de Banco de Dados (DBA) o seu 
gerenciamento, envolvendo tarefas como a autorização de acesso a ele, a sua coordenação e a 
monitoração de seu uso.
Projetista de banco de dados
Cabe ao Projetista de Banco de Dados a identificação dos dados que devem ser armazenados, 
bem como a definição da estrutura adequada para representá-los e armazená-los. É função do 
projetista também avaliar as necessidades de cada grupo de usuários para definir as visões que 
12
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
serão necessárias, integrando-as, fazendo com que o banco de dados seja capaz de atender a todas 
as necessidades dos usuários.
Usuários finais
Os usuários finais são as pessoas que utilizam o banco de dados fazendo consultas, atualizações e 
gerando documentos. Podemos agrupar esses usuários em três categorias:
 » casuais: acessam o banco de dados casualmente, mas podem necessitar de 
diferentes informações a cada acesso; utilizam sofisticadas linguagens de consulta 
para especificar suas necessidades;
 » novatos ou paramétricos: utilizam porções predefinidas do banco de dados, 
valendo-se de consultas preestabelecidas que já foram exaustivamente testadas;
 » usuários avançados: são usuários que estão familiarizados com o SGBD e 
realizam consultas complexas.
Analistas de sistemas e programadores de 
aplicações
Os Analistas de Sistemas são responsáveis pela determinação dos requisitos dos usuários finais 
e pelo desenvolvimento das especificações para atender aos requisitos mapeados. Por sua vez, os 
Programadores são responsáveis pela implementação das especificações definidas na forma de 
programas, testando, depurando, documentando e dando manutenção.
Esquemas de dados
Segundo Silberschatz (2006), os esquemas de dados dizem respeito ao projeto geral do banco de 
dados e é um aspecto que raramente é modificado. 
Um esquema de base de dados é especificado durante o projeto da base de dados e a forma de 
visualização de um esquema é chamada Diagrama do Esquema. 
Os SGBDs possuem vários esquemas de banco de dados que variam em função do nível de abstração 
dos dados: 
 » esquema físico: tem como objetivo descrever o projeto do banco de dados no 
nível físico;
 » esquema lógico: diz respeito à descrição do banco de dados no nível lógico;
 » subesquema de visualização: diz respeito à descrição das visualizações possíveis 
para um banco de dados.
13
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
Muitos modelos de dados têm certas convenções para, diagramaticamente, mostrar esquemas 
especificados neles. 
Alguns autores defendem que uma das maiores contribuições dos primeiros SGBDs foi introduzir a 
separaçãoentre os dados armazenados e a descrição da estrutura dos dados, o esquema de dados. 
Vantagens e desvantagens do uso de um SGBD
Como toda e qualquer ferramenta, o uso de banco de dados apresenta um conjunto de vantagens e 
desvantagens quanto ao seu uso.
Desvantagens
Altos custos
As organizações têm se tornado cada vez mais complexas e os processos de negócio, por sua vez, 
refletem a necessidade da disponibilidade de dados de forma rápida, precisa e flexível. Como 
consequência, os bancos de dados acabam por se tornar cada vez mais complexos, volumosos e 
onerosos.
Apesar dos custos relativos ao armazenamento de dados estarem sendo reduzidos em ritmo 
acelerado, juntamente com a popularização do hardware necessário, aspectos como a concepção, 
o gerenciamento e a manutenção de bancos de dados cada vez mais pesam no orçamento de seu 
projeto. Por vezes, os custos podem se tornar um empecilho para a adoção de um banco de dados.
Gerenciamento e manutenção
A par e passo com a evolução da necessidade de informações, os bancos de dados também 
necessitam de manutenção evolutiva e/ou corretiva. Uma vez que um processo na organização, que 
é suportado por um banco de dados, sofre alguma mudança, a necessidade de informações para 
geri-lo adequadamente também muda. Além disso, a evolução tecnológica dos SGBDs imprime a 
necessidade de ajustes de versão de software e/ou upgrades para que seja possível usufruir dos 
benefícios que estes sistemas oferecem.
Desse modo, a necessidade de uma estrutura para gerenciar o banco de dados, bem como a 
necessidade de mantê-lo, gera custos que podem tornar o seu uso proibitivo.
14
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
Vantagens
Controle de redundância
No processamento tradicional de tratamento de arquivos, é necessário que cada grupo de usuários 
mantenha seu próprio conjunto de arquivos e dados, o que pode fazer com que acabe ocorrendo 
redundâncias que prejudiquem o sistema com problemas como:
 » toda vez que for necessário atualizar um arquivo de um grupo, todos os grupos 
devem ser atualizados para manter a integridade dos dados no ambiente como um 
todo;
 » a redundância desnecessária de dados leva ao armazenamento excessivo de 
informações, ocupando espaço que poderia estar sendo utilizado com outras 
informações.
Compartilhamento de dados
A utilização de um SGBD permite que múltiplos usuários acessem o banco de dados ao mesmo 
tempo, permitindo que múltiplas aplicações integradas possam acessá-lo.
O SGBD multiusuário necessita manter o controle de acessos simultâneos (concorrência) para 
assegurar a qualidade do resultado de atualizações, bem como fornecer recursos que permitam a 
construção de múltiplas visões.
Restrição a acesso não autorizado
Um SGBD permite que seja criado um subsistema de autorização e segurança, o qual é utilizado pelo 
DBA para criar contas de acesso e especificar as restrições de cada conta, sendo estendido tanto para 
acesso aos dados quanto ao uso de softwares inerentes ao SGBD.
Representação de relacionamentos complexos entre 
dados
Um banco de dados permite que seja catalogada uma variedade de dados que estão inter-relacionados 
de várias formas. Por sua vez, um SGBD fornece uma série de recursos para representar uma grande 
variedade de relacionamentos entre os dados, bem como recuperá-los e atualizá-los de maneira 
prática e eficiente.
Padronização
A abordagem de base de dados permite que o DBA defina e obrigue a padronização entre os usuários 
da base de dados em grandes organizações. Isso facilita a comunicação e a cooperação entre 
15
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
vários departamentos, projetos e usuários. Padrões podem ser definidos para formatos de nomes, 
elementos de dados, telas, relatórios, terminologias.
É possível utilizar esse recurso, com maior facilidade, em um ambiente de base de dados centralizado, 
em comparação com um ambiente onde cada usuário ou grupo tem o controle de seus próprios 
arquivos e programas de aplicação.
Flexibilidade
Mudanças nos requisitos podem acarretar a necessidade de modificações na estrutura de um banco 
de dados. Por exemplo, um novo grupo de usuários pode surgir com necessidade de informações 
adicionais, ainda não disponíveis na base de dados. Alguns SGBDs permitem que tais mudanças 
na estrutura da base de dados sejam realizadas sem afetar a maioria dos programas de aplicações 
existentes.
Redução do tempo de desenvolvimento de aplicações
Uma das características mais significativas da abordagem de base de dados é o tempo reduzido para 
o desenvolvimento de novas aplicações, como a recuperação de certos dados da base de dados para 
a impressão de novos relatórios. 
Projetar e implementar uma nova base de dados pode tomar mais tempo do que escrever uma 
simples aplicação especializada de arquivos. Porém, uma vez que a base de dados esteja em uso, 
geralmente é bastante reduzidoo tempo para se criar novas aplicações, usando-se os recursos de 
um SGBD. O tempo para se desenvolver uma nova aplicação em um SGBD é estimado em 1/4 a 
1/6 do tempo de desenvolvimento, usando-se apenas o sistema de arquivos tradicional, devido às 
facilidades de interfaces disponíveis em um SGBD.
Disponibilidade de informações atualizadas
A abordagem de banco de dados permite que tão logo um usuário modifique uma base de dados, 
todos os outros usuários podem usufruir imediatamente dessa modificação. Essa disponibilidade 
de informações atualizadas é essencial para muitas aplicações, tais como sistemas de reservas de 
passagens aéreas ou bases de dados bancárias.
Economia de escala
A abordagem de banco de dados permite a consolidação de dados e de aplicações, reduzindo-se, 
desse modo, o desperdício em atividades redundantes de processamento em diferentes projetos ou 
departamentos. 
16
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
Quando não utilizar um SGBD
Não raro, o uso de um SGBD pode representar um acréscimo desnecessário de custos, se comparado 
à abordagem de processamento tradicional de arquivos. Exemplificando, podemos ter:
 » alto investimento inicial na compra de software e hardware adicionais;
 » generalidade que um SGBD fornece na definição e processamento de dados;
 » sobrecarga na provisão de controle de segurança, de controle de concorrência, na 
recuperação e na integração de funções.
É necessário reconhecer que problemas adicionais podem ocorrer como da resultado especificação 
inadequada do projeto e/ou da implementação das aplicações de forma não apropriada. Caso o 
DBA não administre o banco de dados de forma adequada, tanto a segurança quanto a integridade 
dos sistemas podem ser comprometidas. A sobrecarga causada pelo uso de um SGBD e a má 
administração justificam a utilização da abordagem de processamento tradicional de arquivos em 
casos como:
 » o banco de dados e as aplicações sejam simples, bem-definidos e não sejam esperadas 
mudanças no projeto;
 » sejá necessário processamento em tempo real de certas aplicações, que são 
terrivelmente prejudicadas pela sobrecarga causada pelo uso de um SGBD;
 » não haja múltiplo acesso ao banco de dados.
Um breve histórico da aplicação de banco de dados
Entre a década de 1950 e o início dos anos 1960, as fitas magnéticas eram utilizadas para o 
armazenamento de dados e as tarefas de processamento de dados eram efetuadas quase que de 
forma mecanizada. Os registros também podiam ser alimentados por decks de cartão perfurado e 
necessitavam que fossem carregados sequencialmente, na mesma ordem em que estavam gravados 
nas fitas magnéticas.
No final dos anos 1960, a tecnologia de armazenamento em discos rígidos levou a uma mudança 
radical no cenário do processamento de dados, pois permitiam o acesso direto aos dados, 
independentemente de sua posição no disco.
Entre as décadas de 1960 e 1970, várias pesquisas foram desenvolvidas no sentido de desenvolver 
tecnologias que permitissem a simplificação dos processos de escritório que conduziram à automação.Tarefas como armazenar e organizar arquivos, que dependiam única e exclusivamente de mão de 
obra intensiva, poderiam ser simplificadas com o uso de soluções mecânicas mais eficientes e mais 
baratas. Desse modo, muitas pesquisas foram desenvolvidas e resultaram na criação dos modelos 
hierárquicos, de rede e relacionais.
17
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
Nesse cenário, empresas, como a IBM, tomaram a dianteira e, em 1970, um pesquisador daquela 
empresa, Ted Codd, publicou o primeiro artigo sobre bancos de dados relacionais, que tratava 
de um método que permitia que usuários não técnicos pudessem armazenar e recuperar grande 
quantidade de dados, a partir da utilização de comandos que manipulassem dados armazenados 
em tabelas.
Na década de 1980, com base nesse estudom, a IBM montou um grupo de pesquisa conhecido 
como Sistema R (System R) que objetivava a criação de um banco de dados relacional que tivesse 
viabilidade comercial. O primeiro sistema comercial baseado no conceito desenvolvido pela IBM, 
foi lançado em 1976 pela Honeywell Information Systems Inc. No entanto, o primeiro SGBD 
construído nos padrões SQL só começou a surgir no mercado a partir do início da década de 1980 
com o Oracle 2, da empresa Oracle, e, posteriormente, com o SQL/DS, da IBM.
No início da década de 1990, um dos produtos do Sistema R foi a criação de uma linguagem 
denominada SQL – Structured Query Language (Linguagem de Consulta Estruturada). 
A linguagem SQL tornou-se um padrão na indústria para bancos de dados relacionais e hoje 
em dia, é um padrão ISO (International Organization for Standardization1), o que permitiu o 
desenvolvimento e refinamento de softwares de banco de dados relacionais. Outros aspectos 
relevantes que contribuíram para o refinamento e popularização dos bancos de dados relacionais 
foram: o retorno que os usuários desses sistemas davam para o aprimoramento da linguagem, o 
desenvolvimento de sistemas para novas indústrias e aumento do uso de computadores pessoais e 
sistemas distribuídos. O padrão SQL passou da IBM para a ANSI (American National Standards 
Institute) – Instituto Nacional Americano para Padrões que, juntamente com a ISO, formaram um 
grupo de trabalho para continuar o desenvolvimento. Este desenvolvimento ainda acontece com 
outras novas versões dos padrões definidos até os dias atuais.
O final da década de 1990 foi marcado pela massificação do uso da World Wide Web (WWW), 
fazendo com que os sistemas de banco de dados tivessem de trabalhar com taxas de processamento 
de transação cada vez maiores e disponibilidade de 24x7, ou seja, disponibilidade 24 horas por dia, 
7 dias por semana.
Em meados de 2000, surge a Linguagem Extensível de Formatação ou Extended Markup 
Language (XML) como uma nova tecnologia de banco de dados. O XML é uma especificação 
técnica desenvolvida pela W3C – World Wide Web Consortium2.
 
1 A ISO é a organização internacional de padronização responsável pelos padrões técnicos internacionais
2 A W3C é a entidade responsável pela definição da área gráfica da internet. (http://www.w3.org).
18
CAPÍTULO 2
Conceitos e arquiteturas de um SGBD
Tenha certeza da completa compreensão das informações organizacionais durante o 
estudo de Modelagem Conceitual, pois inseguranças durante os estágios posteriores 
da disciplina podem ser extremamente caras, prejudicando a aprendizagem.
Modelos de dados, esquemas e instâncias
Esquemas e instâncias
Uma distinção importante para qualquer modelo de dados é a que deve ser feita entre a descrição 
do banco de dados e o próprio banco. A descrição de um banco de dados é chamada de esquema 
de um banco de dados e é especificada durante o projeto do banco de dados. Geralmente, poucas 
mudanças ocorrem no esquema do banco de dados. 
Uma instância3 do banco de dados diz respeito à coleção de dados armazenados em um banco de 
dados em um determinado momento (SILBERSCHATZ, 2006). A instância modifica toda vez que 
uma alteração no banco de dados é feita. O SGBD é responsável por garantir que toda instância 
do banco de dados satisfaça o seu esquema do banco de dados, respeitando sua estrutura e suas 
restrições. 
O esquema de um banco de dados também pode ser chamado de intensão de um banco de dados e 
a instância, de extensão de um banco de dados. 
A diferenciação entre esquema e instância de um banco de dados pode ser melhor compreendida 
fazendo uma analogia com um programa, conforme ilustrado na Figura 1.
Figura 1. Analogia entre um Programa e um Banco de Dados
Declaração da 
Variável
Esquema do Banco de 
Dados
PROGRAMA BANCO DE DADOS
Valor da 
Variável
Instância do Banco de 
Dados
3 Também pode ser chamada de ocorrência ou estado de um banco de dados
19
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
Modelos de dados
Uma das vantagens mais relevantes de um banco de dados é a possibilidade de fornecer alguns níveis 
de abstração de dados para o usuário final, omitindo os detalhes de como estes são armazenados.
Segundo Silberschatz, um Modelo de Dados é uma coleção de ferramentas conceituais para 
descrever dados, relações de dados, semântica de dados e restrições de consistência. Um modelo 
de dados permite descrever a estrutura4 de um banco de dados de forma lógica e física. Além 
disso, vários Modelos de Dados também definem um conjunto de operações para especificar 
como recuperar e modificar a base de dados.
Desse modo, podemos dizer que o Modelo de Dados é a principal ferramenta que fornece a 
abstração a um BD. 
Os modelos de dados podem ser basicamente de dois tipos:
 » alto nível: ou modelo conceitual de dados, que fornece uma visão mais próxima do 
modo como os usuários realmente visualizam os dados;
 » baixo nível: ou modelo físico de dados, que fornece uma visão mais detalhada do 
modo como os dados estão realmente armazenados no computador.
Modelo de dados hierárquico
O primeiro modelo de dados a ser reconhecido foi o modelo hierárquico, que só pôde ser desenvolvido 
devido à consolidação dos discos de armazenamento endereçáveis. Esses discos possibilitaram a 
exploração de sua estrutura de endereçamento físico para viabilizar a representação hierárquica das 
informações. 
No modelo hierárquico, os dados são estruturados em hierarquias ou árvores. Os nós das hierarquias 
contêm ocorrências de registros, onde cada registro é uma coleção de campos (atributos), cada um 
contendo apenas uma informação.
O registro-pai é o registro da hierarquia que precede a outros, sendo esses outros denominados 
registros-filhos. Uma ligação é uma associação entre dois registros. Possui cardinalidade 1:N o 
relacionamento entre um registro-pai e vários registros-filhos.
Organizando os dados segundo o modelo hierárquico, esses podem ser acessados por meio de uma 
sequência hierárquica com uma navegação do topo para as folhas e da esquerda para a direita. Um 
registro pode estar associado a vários registros diferentes, desde que seja replicado. 
O Information Management System da IBM Corp (IMS) foi o sistema comercial mais divulgado no 
modelo hierárquico. Uma boa parte das restrições e consistências de dados estava contida dentro 
dos programas escritos para as aplicações Para acessar o banco de dados, era necessário escrever os 
programas na ordem.
4 Por estrutura podemos compreender o tipo dos dados, os relacionamentos e as restrições que podem recair sobre os dados.
20
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
O esquema de um banco de dados hierárquico é descrito por meio de um diagrama de estrutura de 
árvore. Tal diagrama consiste em dois componentes básicos: Caixas, as quais correspondem aos 
tipos de registros, e Linhas, que correspondem às ligações entre os tipos de registros. Como exemplo 
do modelo hierárquico, considere a Figura 2.
Figura 2. Diagrama de Estrutura de Árvore Cliente-Conta Corrente
Nome Rua Cidade
No Conta Corrente Saldo
João R121 Brasília
51935 100,00 61893 500,00
 
Pedro R231 Guará
Fonte: Adaptadode Silberschatz (2006).
O Modelo Hierárquico apresenta algumas restrições devido a:
 » complexidade dos diagramas de estrutura de árvore;
 » não permitir ciclos no gráfico básico de um diagrama de estrutura de árvore;
 » existência de restrições à cardinalidade dos links (de muitos para muitos (N:M) e de 
muitos para um (N:1));
 » ausência de facilidades de consultas declarativas;
 » necessidade de navegação por ponteiros para acesso à informações; 
 » alta complexidade das consultas.
Além disso, a replicação possui duas grandes desvantagens: pode causar inconsistência de dados, 
quando houver atualização, e o desperdício de espaço é inevitável. 
Modelo de dados de rede
O surgimento do modelo de rede deu-se como uma extensão ao modelo hierárquico; dessa forma, 
foi eliminando o conceito de hierarquia e permitindo que um mesmo registro estivesse envolvido 
em várias associações.
Os registros, no modelo em rede, são organizados em grafos onde aparece um único tipo de 
associação (set) que define uma relação 1:N entre 2 tipos de registros: proprietário e membro. Nesse 
sentido, é possível construir um relacionamento M:N entre A e D, dados dois relacionamentos 1:N 
entre os registros A e D e entre os registros C e D.
Com linguagem própria para definição e manipulação de dados, o gerenciador Data Base Task 
Group (DBTG) da CODASYL (Committee on Data Systems and Languages) estabeleceu uma norma 
21
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
para esse modelo de banco de dados. Como os dados tinham uma forma limitada de independência 
física, a única garantia era que o sistema deveria recuperar os dados para as aplicações como se eles 
estivessem armazenados na maneira indicada nos esquemas. 
Concorrência e segurança foram definidas, pelos geradores de relatórios da CODASYL, como dois 
aspectos chaves dos sistemas gerenciadores de dados. Para cada um desses aspectos foram definidas 
sintaxes. O mecanismo de segurança fornecia uma facilidade em que parte do banco de dados (ou 
área) pudesse ser bloqueada para prevenir acessos simultâneos, quando necessário. A sintaxe da 
segurança permitia que uma senha fosse associada a cada objeto descrito no esquema. 
Ao contrário do modelo hierárquico, o modelo em rede possibilita acesso a qualquer nó da rede 
sem passar pela raiz. O CAIDMS da Computer Associates é o sistema comercial mais divulgado 
do modelo em rede. O diagrama para representar os conceitos do modelo em redes consiste em 
dois componentes básicos: Caixas, que correspondem aos registros, e Linhas, que correspondem às 
associações. A Figura 3 ilustra um exemplo de diagrama do modelo em rede.
Figura 3. Diagrama Esquemático da Estrutura de Dados Cliente-Conta Corrente
Cliente Conta
Nome Rua Cidade No Conta Corrente Saldo
Cliente Conta
Pedro R231 Guará 61893 500,00
João R121 Brasília 51935 100,00
R_Link
R_Link
Fonte: Adaptado de Silberschatz (2006).
O Modelo de Rede apresenta algumas restrições devido:
 » forte dependência da implementação;
 » necessidade de criação de registros artificiais para implementar relacionamentos 
muitos para muitos;
 » alta complexidade das consultas, pois o programador é forçado a pensar em termos 
de links e como percorrê-los para obter as informações necessárias (manipulação 
de dados navegacional).
Modelo de dados relacional
O modelo relacional surgiu devido às necessidades de aumentar a independência de dados nos 
sistemas gerenciadores de banco de dados; de prover um conjunto de funções apoiadas em álgebra 
22
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
relacional para armazenamento e recuperação de dados, de permitir o processamento ad hoc1. Esse 
modelo, tendo por base a teoria dos conjuntos e a álgebra relacional, foi resultado de um estudo 
teórico realizado por CODD[1]2. 
Esse modelo foi o que revelou ser o mais flexível e adequado ao solucionar os vários problemas que 
se colocam no nível da concepção e implementação da base de dados. Sua estrutura fundamental é a 
relação (tabela). Uma relação é constituída por um ou mais atributos (campos) que traduzem o tipo 
de dados a armazenar. Tupla (registro) é o nome dado a cada instância do esquema (linha).
O modelo relacional não tem caminhos pré-definidos para se fazer acesso aos dados como nos 
modelos que o precederam e implementa estruturas de dados, organizadas em relações. 
Figura 4. Diagrama de Estrutura Relacional Cliente-Conta Corrente
Cód_Cliente Nome Rua Cidade
1 João R121 Brasília
2 Pedro R231 Guará
Cód_Cliente No Conta Corrente
1 61893
2 51935
No Conta Corrente Saldo
61893 500,00
51935 100,00
Cód_Cliente Nome Rua Cidade
Cód_Cliente No Conta Corrente
No Conta Corrente Saldo
Fonte: Adaptado de Silberschatz (2006).
Algumas restrições devem ser impostas para que se trabalhe com essas tabelas e evitar aspectos 
indesejáveis como: repetição de informação, incapacidade de representar parte da informação e 
perda de informação. Essas restrições são: integridade referencial, chaves e integridade de junções de 
relações. A Figura 4 traz exemplos de tabelas sob o modelo relacional.
Modelo de dados orientado a objetos
Em meados de 1980, começaram a se tornar comercialmente viáveis os bancos de dados orientados 
a objeto. Seu surgimento foi motivado em função dos limites de armazenamento e representação 
semântica impostas no modelo relacional. Os sistemas de informações geográficas (SIG), os sistemas 
CAD e CAM, que são mais facilmente construídos usando tipos complexos de dados, são alguns dos 
exemplos que podem ser citados.
Uma característica das linguagens de programação orientadas a objetos é a habilidade para criar 
os tipos de dados necessários. Contudo, esses sistemas necessitam guardar representações das 
estruturas de dados que utilizam no armazenamento permanente. 
23
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
O ODMG (Object Database Management Group) foi quem criou a estrutura padrão para os bancos 
de dados orientados a objetos. Esse grupo é formado por representantes dos principais fabricantes 
desses bancos disponíveis comercialmente. Os membros do grupo têm o compromisso de incorporar 
o padrão em seus produtos.
Modelo Orientado a Objetos é um termo usado para documentar o padrão que contém a descrição 
geral das facilidades de um conjunto de linguagens de programação orientadas a objetos e a 
biblioteca de classes que pode formar a base para o Sistema de Banco de Dados. Algumas das falhas 
perceptíveis do modelo relacional pareceram ter sido solucionadas quando os bancos de dados 
orientados a objetos foram introduzidos e acreditava-se que tais bancos de dados ganhariam grande 
parcela do mercado. 
Acredita-se que nos dias atuais, enquanto os sistemas relacionais continuarão a sustentar os 
negócios tradicionais, onde as estruturas de dados baseadas em relações são suficientes, os Bancos 
de Dados Orientados a Objetos serão usados em aplicações especializadas. 
O diagrama de classes UML serve geralmente como o esquema para o modelo de dados orientado a 
objetos. Observe o exemplo da Figura 5. e compare as diferenças com o modelo anterior.
Figura 5. Diagrama UML Cliente-Conta Corrente
Cliente
Nome: String
Rua: String
Cidade: String
Conta
No Conta Corrente: Inteiro
Saldo: Real
1..* 1..*
Fonte: Adaptado de Silberschatz (2006).
Modelo de dados para sistemas objeto-relacionais
Os sistemas relacionais convencionais têm dificuldade de representar e manipular dados complexos, 
visando ser mais representativos em semântica e construções de modelagens; com isso, a área de 
atuação dos sistemas Objeto-Relacional tenta suprir essas dificuldades. A solução proposta é a 
adição de facilidades para manusear tais dados utilizando-se das facilidades SQL (Structured Query 
Language) existentes. Para isso, foi necessário adicionar: extensões dos tipos básicos no contexto 
SQL; representações para objetos complexos no contexto SQL; herança no contexto SQL e sistema 
para produção de regras.
A arquitetura três esquemas
O principal objetivoda arquitetura três esquemas é permitir a separação das aplicações do usuário 
do banco de dados físico. Uma representação gráfica da arquitetura três esquemas é apresentada na 
Figura 6. Com base nessa arquitetura, é possível classificar os esquemas:
 » nível interno: ou esquema interno, que descreve a estrutura de armazenamento 
físico do banco de dados; utiliza um modelo de dados e descreve detalhadamente os 
dados armazenados e os caminhos de acesso ao banco de dados;
24
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
 » nível conceitual: ou esquema conceitual, que descreve a estrutura do banco de 
dados como um todo; é uma descrição global do banco de dados, que não fornece 
detalhes do modo como os dados estão fisicamente armazenados;
 » nível externo: ou esquema de visão, que descreve as visões do banco de dados 
para um grupo de usuários; cada visão descreve as porções do banco de dados às 
quais um grupo de usuários terá acesso.
Independência de dados
Segundo Oppel (2004), é possível definir a independência de dados como a capacidade de se 
alterar um esquema em um nível em um banco de dados sem ter que alterar um nível superior. É 
possível classificar a independência de dados em dois tipos:
 » independência de dados lógica: é a capacidade de alterar o esquema conceitual 
sem ter que alterar o esquema externo ou as aplicações do usuário;
 » independência de dados física: é a capacidade de alterar o esquema interno sem 
ter que alterar o esquema conceitual, o esquema externo ou as aplicações do usuário.
Figura 6. Arquitetura Três Esquemas
Visão Externa 1 Visão Externa n
Usuários Finais
Esquema Conceitual
Esquema Interno
NÍVEL EXTERNO
NÍVEL CONCEITUAL
NÍVEL INTERNO
Banco de Dados Armazenado
...
Mapeamento 
Conceitual Externo
Mapeamento 
Conceitual Externo
25
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
Linguagens de banco de dados
Cada camada e/ou função de um banco de dados necessita de um tipo de linguagem específica, 
conforme podemos ver.
Linguagem de definição de dados
A Linguagem de Definição de Dados ou Data Definition Language (DDL) é a linguagem 
utilizada pelo DBA e pelos projetistas de banco de dados para definir seus esquemas. O SGBD, 
por sua vez, possui um compilador para processar descrições em DDL e construir a descrição do 
esquema armazenado no catálogo. 
Linguagem de manipulação de dados
A Linguagem de Manipulação de Dados ou Data Manipulation Language (DML) é a 
linguagem pela qual os usuários manipulam os dados em um SGBD. Manipulações comuns como 
recuperação, inserção, remoção e modificação de dados são realizadas pela DML. 
Linguagem de definição de armazenamento
Em situações onde a separação entre os níveis conceitual e interno de um SGBD é bem clara, utiliza-
se a Linguagem de Definição de Armazenamento ou Storage Definition Language (SDL) 
para a especificação do esquema interno, sendo que a especificação do esquema conceitual fica por 
conta da DDL.
Linguagem de definição de visões
Sistemas de Banco de Dados que utilizam a arquitetura três esquemas necessitam de uma linguagem 
para a definição de visões, a Linguagem de Definição de Visões ou Vision Definition 
Language (VDL). 
O ambiente de sistemas de banco de dados
O Ambiente dos Sistemas de Banco de Dados diz respeito ao conjunto de elementos necessário 
para que ocorram as transações relativas ao armazenamento, processamento e recuperação de 
dados, conforme representado pela Figura 7.
26
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
Componentes de um sistema gerenciador de 
banco de dados
Processamento de consultas
O componente de processamento de consultas é composto pelos seguintes elementos:
 » Compilador DML: é o elemento que traduz os comandos DML em instruções 
de baixo nível, entendidos pelo componente de execução de consultas. Também é 
responsável pela otimização de solicitações do usuário.
 » Pré-compilador para comandos DML inseridos em programas de 
aplicação: são os elementos que convertem comandos DML em chamadas de 
procedimentos normais da linguagem hospedeira. Também interagem com o 
compilador DML de modo a gerar o código apropriado.
 » Interpretador DDL: é o elemento que interpreta os comandos DDL e os registra 
no dicionário de dados.
 » Componente de execução de consultas: é o elemento que executa instruções 
de baixo nível geradas pelo compilador DML.
Figura 7. Um ambiente de Sistema de Banco de Dados
Ge
re
nc
ia
do
r d
e 
M
em
ór
ia
Usuários
Interface
Usuários 
Navegadores
Usuários 
Avançados
Administradores 
de BD
Programadores de 
Aplicações
Interface com 
Aplicações
Programas de 
Aplicações
Esquema de 
Banco de Dados
Consultas 
(Queries)
Programas de 
Aplicações em 
Código Objeto
Pré-compilador de 
Comandos DML
Interpretador DDLCompilador DML
Componente 
de Execução de 
Consultas
Gerenciador de 
Buffer
Pr
oc
es
sa
do
r d
e 
Co
ns
ul
ta
s
Gerenciador de 
Arquivos
Gerenciador de 
Transações
Arquivos de 
Dados
Índices
Dicionário de 
Dados
Dados Estatísticos
Banco de Dados
Si
st
em
a 
Ge
re
nc
ia
do
r d
e 
 B
an
co
 d
e 
Da
do
s
Am
bi
en
te
 d
o 
Si
st
em
a 
Ge
re
nc
ia
do
r d
e 
Ba
nd
o 
de
 D
ad
os
Fonte: Adaptado de Silberschatz (2006).
27
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
Gerenciador de memória
O componente Gerenciador de Memória é o responsável por traduzir os diversos comandos DML 
em comandos de baixo nível de sistemas de arquivos, o que lhe confere especial importância uma 
vez que um dos principais objetivos de um SGBD é simplificar e otimizar o acesso aos dados. Visto 
que esse componente é responsável por fazer a interface entre o armazenamento de dados em um 
nível mais baixo e as consultas e programas de aplicações submetidos ao sistema, é possível afirmar 
que o Gerenciador de Memória é um dos principais elementos de um SGBD.
O componente de gerenciamento de memória é composto pelos seguintes elementos:
 » Gerenciamento de Autorizações e Integridade: são os elementos que testam 
o cumprimento das regras de integridade e a permissão ao usuário no acesso ao 
dado.
 » Gerenciamento de Transações: são os elementos responsáveis pela execução 
das transações.
 » Administração de Buffer5: é o elemento responsável pela intermediação de 
dados do disco para a memória principal e pela decisão de quais dados alocar em 
memória auxiliar.
 » Administração de Arquivos: é o elemento que gerencia a alocação de espaço no 
armazenamento em disco e as estruturas de dados usadas para representar essas 
informações armazenadas.
Módulo banco de dados
O Módulo Banco de Dados não se limita apenas a armazenar dados, uma vez que também contém 
definições e descrições sobre a estrutura que forma o Banco de Dados (metadados). Os metadados, 
por sua vez, contêm definições da estrutura de cada arquivo, o tipo e formato de armazenamento de 
cada item de dados e as restrições dos dados. Todas essas definições ficam armazenadas no Catálogo 
de Dados (dicionário de dados) do Banco de Dados e são utilizadas pelo SGBD.
O Módulo Banco de Dados é composto por:
 » Arquivo de Dados: é o elemento que armazena os dados (o banco de dados 
propriamente dito).
 » Dicionário de Dados: é o elemento que armazena os metadados.
 » Índices: é o elemento estrutural que otimiza o acesso aos itens de dados.
 » Estatística de Dados: é o elemento que armazena informações estatísticas 
relativas aos dados contidos no banco de dados. Essas informações são usadas 
pelo processador de consultas para seleção de meios eficientes para execução de 
consultas.
5 Unidade de armazenamento temporária (relativo a computador). Fonte: http://www.merriam-webster.com/dictionary
28
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
Arquiteturas de banco de dados
Os mainframes eram utilizados pelas primeiras arquiteturas para executar o processamento 
principal e de todas as funções do sistema, incluindo os programas aplicativos, programas de 
interface com o usuário, bem como a funcionalidadedos SGBDs. Essa é a razão pela qual a maioria 
dos usuários fazia acesso aos sistemas via terminais que não possuíam poder de processamento, mas, 
somente a capacidade de visualização. Apenas as informações a serem visualizadas e os controles 
eram enviados do mainframe para os terminais de visualização e todos os processamentos eram 
feitos remotamente, conectados a ele por redes de comunicação. 
Muitos usuários trocaram seus terminais por Computadores Pessoais (PC) e estações de trabalho 
devido à queda dos preços do hardware. No começo, os SGBDs usavam esses computadores da 
mesma maneira que usavam os terminais. O SGBD era centralizado e toda sua funcionalidade, 
execução de programas aplicativos e processamento da interface do usuário eram executados em 
apenas uma máquina.
Os SGBDs, gradualmente, começaram a explorar a disponibilidade do poder de processamento no 
lado do usuário, o que levou à arquitetura cliente-servidor. Essa arquitetura foi desenvolvida para 
dividir ambientes de computação onde um grande número de PCs, estações de trabalho, servidores 
de arquivos, impressoras, servidores de banco de dados e outros equipamentos são conectados 
juntos por uma rede. 
A idéia era definir servidores especializados, tais como servidor de arquivos, que mantém os arquivos 
de máquinas clientes, ou servidores de impressão que podem estar conectados a várias impressoras; 
assim, quando se desejar imprimir algo, todas as requisições de impressão são enviadas a esse 
servidor. As máquinas clientes disponibilizam para o usuário as interfaces apropriadas para utilizar 
esses servidores, bem como o poder de processamento para executar aplicações locais. 
A arquitetura cliente-servidor se tornou muito popular por causa da facilidade de implementação 
dada à clara separação das funcionalidades e dos servidores; pelo servidor ser inteligentemente 
utilizado porque as tarefas mais simples são delegadas às máquinas-clientes mais baratas e também 
porque o usuário pode executar uma interface gráfica que lhe é familiar, ao invés de usar a interface 
do servidor. 
Aos SGBDs comerciais, foi incorporada a arquitetura cliente-servidor e diferentes técnicas foram 
propostas para se implementar essa arquitetura, sendo que a mais adotada pelos Sistemas 
Gerenciadores de Banco de Dados Relacionais (SGBDRs) comerciais é a inclusão da funcionalidade 
de um SGBD centralizado no lado do servidor. Permanecem no servidor de consulta ou servidor de 
transação as consultas e a funcionalidade transacional. É assim que um servidor SQL é fornecido 
aos clientes.
Os clientes têm que formular suas consultas SQL, prover a interface do usuário e as funções de 
interface usando uma linguagem de programação. Podem também se referir a um dicionário de 
dados, que inclui informações sobre a distribuição dos dados em vários servidores SQL, bem como 
sobre os módulos para a decomposição de uma consulta global em um número de consultas locais 
que podem ser executadas em vários sítios. 
29
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
O servidor SQL também é chamado de back-end machine e o cliente de front-end machine. Como 
SQL provê uma linguagem padrão para o SGBDRs, esta criou o ponto de divisão lógica entre o 
cliente e o servidor.
Atualmente, existem várias tendências para arquitetura de Banco de Dados, nas mais diversas 
direções.
As principais arquiteturas de SGBDs são:
 » Plataformas centralizadas: nessa arquitetura existe um computador com grande 
capacidade de processamento, sendo esse o hospedeiro do SGBD e emulador para 
os vários aplicativos. Sua principal vantagem é a de permitir que muitos usuários 
manipulem grande volume de dados e sua principal desvantagem está no seu alto 
custo, pois exige ambiente especial para mainframes e soluções centralizadas.
 » Sistemas de Computador Pessoal: fazem seus processamentos sozinhos 
e, com isso, trabalham em sistema stand-alone. No começo esse processamento 
era bastante limitado, porém, com a evolução do hardware, tem-se hoje PCs com 
grande capacidade de processamento. Utilizam o padrão Xbase e, em se tratando de 
SGBDs, funcionam como hospedeiros e terminais. Desta forma, possuem um único 
aplicativo a ser executado na máquina e sua principal vantagem é a simplicidade.
 » Banco de Dados Cliente-Servidor: nessa arquitetura, o cliente (front_
end) executa as tarefas do aplicativo fornecendo a interface do usuário (tela e 
processamento de entrada e saída). O servidor (back_end) executa as consultas no 
DBMS e retorna os resultados ao cliente. Embora sendo uma arquitetura bastante 
popular, são necessárias soluções sofisticadas de software que possibilitem: o 
tratamento de transações, as confirmações de transações (commits), desfazer 
transações (rollbacks), linguagens de consultas (stored procedures) e gatilhos 
(triggers). A principal vantagem dessa arquitetura é a divisão do processamento 
entre dois sistemas, o que reduz o tráfego de dados na rede. (Ver Figura 8)
 » Banco de Dados Distribuídos (N camadas): como se pode observar na Figura 
9, a informação, nessa arquitetura, está distribuída em diversos servidores. Cada 
servidor atua como no sistema cliente-servidor, porém as consultas oriundas dos 
aplicativos são feitas para qualquer servidor indistintamente. Caso a informação 
solicitada seja mantida por outro servidor ou servidores, o sistema encarrega-se 
de obter a informação necessária, de maneira transparente para o aplicativo, que 
passa a atuar consultando a rede, independente de conhecer seus servidores. As 
bases de dados corporativas, em que o volume de informação é muito grande e, 
por isso, deve ser distribuído em diversos servidores são exemplos típicos. Porém, 
não é dependente de aspectos lógicos de carga de acesso aos dados, ou de base de 
dados fracamente acopladas, em que uma informação solicitada vai sendo coletada 
numa propagação da consulta numa cadeia de servidores. A existência de diversos 
programas aplicativos consultando a rede para acessar os dados necessários é a 
característica básica, porém, sem o conhecimento explícito de quais servidores 
dispõem desses dados.
30
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
Figura 8. Arquitetura Cliente-Servidor
Fonte: Produzido pelo autor.
Figura 9. Arquitetura Distribuída N Camadas
Fonte: Adaptado de Silberschatz (2006)
Classificação dos SGBDs
O principal critério utilizado para classificar um SGBD é o modelo de dados no qual é baseado. A 
grande maioria dos SGBDs atuais são baseados no modelo relacional, alguns em modelos conceituais 
e outros em modelos orientados a objetos. Outras classificações possíveis.
 » Quanto aos usuários: um SGBD pode ser monousuário, comumente utilizado 
em computadores pessoais ou multi-usuários, utilizado em estações de trabalho, 
minicomputadores e máquinas de grande porte.
 » Quanto à localização: um SGBD pode ser localizado ou distribuído; se ele for 
localizado, então todos os dados estarão em uma só máquina (ou em um único 
31
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
disco); se distribuído, os dados estarão distribuídos por diversas máquinas (ou 
diversos discos).
 » Quanto ao ambiente: ambiente homogêneo é o ambiente composto por um único 
SGBD e um ambiente heterogêneo é o ambiente composto por diferentes SGBDs.
Exemplos de sistemas gerenciadores de banco de 
dados
Existem, atualmente no mercado, vários aplicativos que exercem a função de Sistemas Gerenciadores 
de Banco de Dados. A seguir, apresentamos alguns exemplos.
 » dBASE: é um aplicativo lançado pela Ashton-Tate e posteriormente adquirido 
pela Borland. Teve versões para DOS e Windows, trabalhava com gerenciamento 
de arquivos planos baseados em listas invertidas e possuía uma linguagem de 
programação própria para desenvolvimento de aplicações. A partir da versão 7, os 
direitos foram vendidos pela Borland.
 » Paradox: teve versões para DOS e hoje possui apenas versões para Windows. 
Possui ambiente integrado de desenvolvimento para criação de aplicativos eseus 
direitos de produção foram vendidos para a Corel.
 » DataFlex: teve versões para DOS e Windows e é popular para ambiente Unix. 
Hoje é comercializado com o nome de Visual Data Flex e possui ambiente integrado 
para o desenvolvimento de aplicações. 
 » FoxBase/FoxPro: é um aplicativo concorrente do dBase, com total compatibilidade 
em termos de arquivos e programas-fontes. Possui recursos adicionais como a 
capacidade de pré-compilação dos códigos-fontes para melhorar o desempenho. 
Hoje, se chama Visual FoxPro após a aquisição pela Microsoft da Fox Software 
(produtora original).
 » Access: é um aplicativo que, por possuir ambiente integrado, permite a criação 
e gerenciamento do banco de dados, desenvolvimento de aplicações e geração 
de relatórios. Sua linguagem de programação deriva do Visual Basic. Para 
microcomputadores do ambiente Windows é padrão em banco de dados.
 » Oracle: é o primeiro em Banco de Dados Corporativos (cliente/servidor) possuindo 
grande variedade de distribuições (para Macintosh, Windows, Linux, FreeBSD, 
Unix) e para computadores de grande porte. É padrão SQL com uma linguagem 
própria para desenvolvimento de aplicações.
 » Interbase: teve uma versão liberada como Open Source e foi incluído, pela Borland, 
nas suas ferramentas de desenvolvimento (Delphi, C++Builder, JBuider).
32
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
 » MS-SQL Server: as versões atuais são independentes e operam exclusivamente 
sobre Windows. Foi produzido pela Microsoft. Inicialmente era uma versão especial 
do Sybase.
 » Sybase SQL Anywhere: as aplicações para esse banco de dados são desenvolvidas 
com o PowerBuilder. No mercado, seu concorrente corporativo é o Oracle.
 » MySQL: além de gratuito, possui versões para Windows, Solaris, Unix, FreeBSD, 
Linux. Usado principalmente para desenvolvimento WEB como servidor de dados 
para comércio eletrônico.
 » PostgreSQL: além de ser gratuito, tem boa aceitação. Foi concebido para rodar 
em Linux e possui versões para Windows. É, principalmente, usado para comércio 
eletrônico, juntamente com a linguagem PHP.
 » Informix: aplicativo comercializado pela IBM. Possui boa escalabilidade e 
desempenho.
 » BD2: aplicativo produzido pela IBM, nasceu nos ambientes de grande porte, sendo 
posteriormente portado para plataformas mais simples (microcomputadores).
 » Firebird: aplicativo nascido de uma iniciativa da Borland em abrir o código do 
InterBase 6. Este sistema é open source e esbanja versatilidade e robustez. Possui 
recursos de trigger, store procedures e transações concorrentes.
33
CAPÍTULO 3
Modelagem de dados utilizando o MER
Uma entidade dever ter atributos que necessitam ser conhecidos do ponto de vista 
dos negócios ou então não é uma entidade no escopo dos requisitos do negócio.
O Modelo Entidade-Relacionamento (MER)
O Modelo Entidade-Relacionamento (MER) foi definido por Peter Chen,, em 1976, e teve como base 
a teoria relacional criada por E.F.Codd (1970). Segundo Chen, a visão de uma dada realidade baseia-
se no relacionamento entre entidades, que retratam os fatos que governam essa mesma realidade, e 
que cada um (entidade ou relacionamento) pode possuir atributos (qualificadores dessa realidade).
É um modelo de dados conceitual de alto nível, cujos conceitos foram projetados para estar o mais 
próximo possível da visão que o usuário tem dos dados, não se preocupando em representar como 
esses dados estarão realmente armazenados. Baseia-se na percepção de um mundo real que consiste 
em uma coleção de objetos básicos, denominados entidades, e de relações entre esses objetos.
O MER é utilizado principalmente durante o processo de projeto de banco de dados e é, atualmente, 
a técnica mais difundida, chegando a confundir-se com a própria modelagem de dados.
A Figura 10 faz uma descrição simplificada do processo de projeto de um banco de dados.
Características do MER
O modelo ER apresenta as seguintes características.
 » Expressividade: suporta relacionamentos n-ários; inclui os três mecanismos de 
abstração: classificação, agregação e generalização.
 » Simplicidade: possui uma riqueza de conceitos e com isso se torna uma poderosa 
ferramenta para a descrição da realidade. Não é um modelo muito simples, 
especialmente no que diz respeito aos conceitos de cardinalidade, cobertura de 
generalização e identificação. Uma solução é produzir diagramas ER em diferentes 
níveis de detalhe.
 » Minimalidade: nenhum conceito do modelo pode ser descrito em termos dos 
demais, com exceção dos atributos compostos. O fato de a mesma realidade poder 
ser modelada de diferentes maneiras não invalida a minimalidade do modelo. 
34
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
 » Formalidade: possui o necessário grau de formalidade, uma vez que cada um de 
seus conceitos possui uma interpretação única, precisa e bem-definida. 
 » Representação gráfica: todos os seus conceitos possuem um símbolo gráfico 
associado, por isso, é um modelo graficamente completo. Os diagramas ER são 
fáceis de serem entendidos pelos usuários.
Uma aplicação
A Figura 10 descreve uma base de dados COMPANHIA, que será utilizada para ilustrar o processo 
de projeto de base de dados. São listados os requisitos da base de dados e criado o seu esquema 
conceitual passo a passo ao mesmo tempo em que são introduzidos os conceitos de modelagem 
usando o MER. 
A base de dados COMPANHIA armazena os dados dos empregados, departamentos e projetos. 
Supõe-se que após a Obtenção e Análise dos Requisitos, os projetistas da base de dados produziram 
a seguinte descrição do minimundo – parte da companhia a ser representada na base de dados.
 » A companhia é organizada em departamentos. Cada departamento tem um nome, 
um número e um empregado que o gerencia. Armazena-se a data de início em que 
o empregado começou a gerenciar o departamento. Um departamento pode ter 
diversas localizações.
 » Um departamento controla inúmeros projetos, sendo que cada um tem um nome, 
um número e uma localização.
 » Do empregado armazena-se o nome, número do seguro social, endereço, salário, 
sexo e a data de nascimento. Todo empregado é associado a um departamento, mas 
pode trabalhar em diversos projetos, que não são necessariamente controlados pelo 
mesmo departamento. Armazena-se, também, o número de horas que o empregado 
trabalha em cada projeto. Mantém-se, ainda, a indicação do supervisor direto de 
cada projeto.
 » Os dependentes de cada empregado são armazenados com o propósito de garantir 
os benefícios do seguro. Para cada dependente será armazenado o nome, sexo, data 
de nascimento e o relacionamento com o empregado.
35
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
Figura 10: Esquematização da Modelagem de Dados usando o MER
Obtenção e Análise Requisitos
Projeto Conceitual
Projeto Físico
Mini-Mundo
Requisitos da Base de Dados
Modelo Conceitual (Alto-Nível)
Esquema Conceitual (SGBD específico)
Esquema Interno
Banco de Dados
Co
m
um
 a
 to
do
s 
os
 ti
po
s 
de
 S
GB
D
Co
nf
or
m
e 
o 
SG
BD
 
Mapeamento do Modelo de Dados
Fonte: Adaptado de Silberschatz (2006).
Entidades e atributos
O objeto básico tratado pelo modelo ER é a entidade, que pode ser definida como um objeto do 
mundo real, concreto ou abstrato e que possui existência independente. 
Cada entidade possui um conjunto particular de propriedades que a descreve, denominado 
atributos. Para cada atributo existe um conjunto de valores permitidos, que é chamado de 
domínio desse atributo. Um atributo pode ser dividido em diversas partes menores com significado 
independente entre si, recebendo o nome de atributo composto. Um atributo que não pode ser 
subdividido é chamado de atributo simples ou atômico.
O atributo que pode assumir apenas um determinado valor em uma determinada instância é 
denominado atributo simplesmente valorado, enquanto que um atributo que pode assumir diversos 
valores em uma mesma instância é denominado multivalorado. Um atributoque é gerado a partir 
de outro é chamado de atributo derivado.
36
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
Tipos entidade, conjunto de valores, atributo chave
Um banco de dados costuma conter grupos de entidades que são similares, possuindo os mesmos 
atributos, porém, cada entidade conta com seus próprios valores para cada atributo. Esse conjunto 
de entidades similares forma tipo entidade. Cada tipo entidade é identificado por seu nome 
e pelo conjunto de atributos que definem suas propriedades. A descrição do tipo entidade é 
chamada de esquema do tipo entidade, onde são especificados o nome do tipo entidade, o nome 
de cada um de seus atributos e qualquer restrição que incida sobre as entidades. 
Relacionamentos
Tipos de relacionamento
Um tipo relacionamento R entre n entidades E1, E2, ..., En é um conjunto de associações possíveis 
entre entidades desse tipo. Em outras palavras, cada instância de relacionamento r1 em R é 
uma associação de entidades. Isso significa que essas entidades estão relacionadas de alguma forma 
no minimundo. 
A Figura 11 mostra um exemplo entre dois tipos entidade (empregado e departamento) e o 
relacionamento entre eles (trabalha para). Repare que para cada relacionamento participa 
apenas uma entidade de cada tipo entidade, porém, uma entidade pode participar de mais de um 
relacionamento.
Figura 11. Exemplo de um Relacionamento Binário
R1
R2
R3
R4
R5
R6
Trabalha ParaEmpregado
E
1
E
2
E
3
E
4
E
5
E
6
Departamento
D1
D2
D3
37
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
Grau de um relacionamento
O grau de um tipo relacionamento é o número de tipos entidade que participam do tipo relacionamento. 
No exemplo da Figura 11, temos um relacionamento binário. O grau de um relacionamento é 
ilimitado, porém, a partir do grau 3, a compreensão e a dificuldade de se desenvolver a relação 
corretamente se tornam extremamente complexas.
Um exemplo de um tipo de relacionamento ternário é Fornece para, ilustrado na Figura 12. Cada 
instância de relacionamento R1 associa três entidades – um fornecedor F, uma peça E e um projeto 
P – onde o fornecedor F fornece a peça E para o projeto P. Podem existir tipos de relacionamento de 
qualquer grau, porém é mais frequente encontrar o tipo de relacionamento de grau dois.
Relacionamentos como atributos
Algumas vezes é conveniente pensar em um relacionamento como um atributo. Considere o exemplo 
da Figura 11. Podemos pensar departamento como sendo um atributo da entidade empregado, ou 
empregado, como um atributo multivalorado da entidade departamento. Se uma entidade não 
possuir existência muito bem definida, talvez seja mais interessante para a coesão do modelo lógico 
que ela seja representada como um atributo.
Figura 12. Exemplo de um Relacionamento Ternário
R1
R2
R3
R4
R5
R6
Fornecer para
Peças
E
1
E
2
E
3
E
4
E
5
E
6
Projeto
P
1
P
2
P
3
Fornecedor
F
1
F
2
Nomes de papéis e relacionamentos recursivos
Cada tipo entidade que participa de um tipo relacionamento desempenha um papel particular 
no relacionamento. O nome do papel representa o papel que uma entidade de um tipo entidade 
38
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
participante desempenha no relacionamento. No exemplo da Figura 11, nós temos o papel empregado 
ou trabalhador para o tipo entidade EMPREGADO e o papel departamento ou empregador para a 
entidade DEPARTAMENTO. 
Nomes de papéis não são necessariamente importantes quando todas as entidades participantes 
desempenham papéis diferentes. Algumas vezes, o papel torna-se essencial para distinguir o 
significado de cada participação. Isso é muito comum em “relacionamentos recursivos”.
Um relacionamento recursivo é um relacionamento entre entidades do mesmo tipo entidade, 
conforme ilustrado na Figura 13.
Na Figura 13, temos um relacionamento entre o tipo entidade EMPREGADO, onde um empregado 
pode supervisionar outro empregado e um empregado pode ser supervisionado por outro empregado.
Figura 13. Um Relacionamento Recursivo
Supervisiona
R1
R2
R3
R4
R5
R6
Empregado
E
1
E
2
E
3
E
4
E
5
E
6
Supervisiona
Supervisionando
Refinando o projeto de entidade-relacionamento
Tipos entidades fracas
Em alguns casos, alguns tipos entidade podem não ter um atributo chave por si só. Isso implica que 
não poderemos distinguir algumas entidades porque as combinações dos valores de seus atributos 
podem ser idênticas. Esses tipos entidade são chamados entidades fracas. As entidades desse 
tipo precisam estar relacionadas com uma entidade pertencente ao tipo entidade proprietária. 
Esse relacionamento é chamado de relacionamento identificador. 
Na Figura 14, o tipo entidade DEPENDENTE é uma entidade fraca uma vez que não possui um 
método de identificar uma entidade única. O EMPREGADO não é uma entidade fraca uma vez que 
possui um atributo para identificação (atributo chave). 
39
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
O número do CPF de um empregado pode identificar um único empregado, porém um dependente 
de 5 anos de idade não possui necessariamente um documento como esse. Dessa forma, essa 
entidade é um tipo entidade fraca. 
Figura 14. Exemplo de um Relacionamento com uma Entidade Fraca
Possui Dependente
R
1
R
2
R
3
Empregado
E
1
E
2
E
3
Dependente
D
1
D
2
D
3
Um tipo entidade fraca possui uma chave parcial que, juntamente com a chave primária da 
entidade proprietária, forma uma chave primária composta.
No exemplo da Figura 14 a chave primária do EMPREGADO pode ser o CPF. A chave parcial 
do DEPENDENTE pode ser o seu nome, pois dois irmãos não podem ter o mesmo nome. Desse 
modo, a chave primária desta entidade fica sendo o CPF do pai ou da mãe mais o nome 
do dependente.
Atributos em tipos de relacionamentos
Os tipos de relacionamento também podem ter atributos da mesma maneira que os tipos de entidades. 
Exemplificando, tomemos a situação representada pela Figura 15 e acrescentemos a necessidade de 
representar a data em que um EMPREGADO começou a gerenciar um DEPARTAMENTO por 
meio de um atributo Data_Início para o tipo de relacionamento GERÊNCIA.
Figura 15. Exemplo de um Relacionamento
Gerência
R
1
R
2
R
3
Departamento
D
1
D
2
D
3
Empregado
E
1
E
2
E
3
E
4
E
5
E
6
Nesse caso, é possível perceber que atributos de tipos de relacionamento 1:1 ou 1:N podem ser 
incluídos como atributos de um dos tipos de entidades participantes. Assim, o atributo Data_
Início para o tipo de relacionamento GERÊNCIA pode ser um atributo tanto de EMPREGADO 
quanto de DEPARTAMENTO embora, conceitualmente, ele pertença ao relacionamento 
40
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
GERÊNCIA. Isso ocorre porque GERÊNCIA é um relacionamento 1:1, uma vez que toda entidade 
DEPARTAMENTO ou EMPREGADO participam em apenas uma instância de relacionamento 
e, dessa forma, o valor do atributo Data_Início pode ser representado em qualquer uma das 
entidades participantes.
No caso de um tipo de relacionamento 1:N, um atributo de relacionamento pode somente ser 
colocado no tipo de entidade que está do lado N do relacionamento. Isso pode ser visto 
na Figura 11, pois se o relacionamento TRABALHA-PARA tiver um atributo Data_Início, 
indicando quando um empregado começou a trabalhar para um DEPARTAMENTO, esse atributo 
pode ser colocado como atributo de EMPREGADO. Isso ocorre porque o relacionamento é 1:N 
de modo que cada entidade EMPREGADO participa apenas uma única vez em uma instância de 
TRABALHA-PARA. 
Uma vez que o valor de um atributo é determinado pela combinação das entidades participantes 
em uma instância de relacionamento, e não apenas por uma das entidades, então o atributo deve 
ser especificado como um atributo de relacionamento. Esse é o caso de atributos de tipos de 
relacionamentos M:N, porque as entidades dos tipos de entidades participantes podem participar 
em inúmeras instâncias de relacionamento. 
Exemplificando, tomemos a situação descrita na Figura 11 e acrescentemos a necessidade de incluiro atributo Horas_Trabalhadas do relacionamento M:N TRABALHA-PARA. O número de 
horas que um empregado trabalha em um projeto é determinado pela combinação empregado-
projeto e não separadamente.
Modelo Entidade-Relacionamento Estendido (ERE)
Os conceitos do modelo Entidade-Relacionamento, discutidos anteriormente, são suficientes para 
representar logicamente a maioria das aplicações de banco de dados. Porém, com o surgimento 
de novas aplicações, surgiu também a necessidade de novas semânticas para a modelagem de 
informações mais complexas. 
O modelo Entidade-Relacionamento Estendido (ERE) visa fornecer esta semântica para 
permitir a representação de informações complexas. É importante frisar que, embora o modelo ERE 
trate classes e subclasses, ele não possui a mesma semântica de um modelo orientado a objetos.
O modelo ERE engloba todos os conceitos do modelo E-R mais os conceitos de subclasse, 
superclasse, generalização, especialização e o de herança de atributos.
Subclasses, Superclasses e Especializações
O primeiro conceito do modelo ERE, que será abordado, é o de subclasse de um tipo entidade. 
Como visto anteriormente, um tipo entidade é utilizado para representar um conjunto de entidades 
do mesmo tipo. Em muitos casos, um tipo entidade possui diversos subgrupos adicionais de entidades 
41
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
que são significativas e precisam ser representadas explicitamente, devido ao seu significado, à 
aplicação de banco de dados. Considere o seguinte exemplo:
Para um banco de dados de uma empresa temos o tipo entidade empregado, o qual possui as seguintes 
características: nome, RG, CPF, número funcional, endereço completo (rua, número, complemento, 
CEP, bairro, cidade), sexo, data de nascimento e telefone (ddd e número); caso o(a) funcionário(a) 
seja um(a) engenheiro(a), então deseja-se armazenar as seguintes informações: número do CREA e 
especialidade (Civil, Mecânico, Eletrônico); caso o(a) funcionário(a) seja um(a) secretário(a), então 
se deseja armazenar as seguinte informações: qualificação (bi ou trilíngue) e os idiomas em que 
possui fluência verbal e escrita.
Se as informações número do CREA, especialidade, tipo e idiomas forem representados diretamente 
no tipo entidade empregado estaremos representando informações de um conjunto limitado de 
entidades empregado para os todos os funcionários da empresa. Nesse caso, podemos criar duas 
subclasses do tipo entidade empregado: engenheiro e secretária, as quais irão conter as informações 
acima citadas. Além disto, engenheiro e secretária podem ter relacionamentos específicos.
Uma entidade não pode existir meramente como componente de uma subclasse. Antes de ser 
componente de uma subclasse, uma entidade deve ser componente de uma superclasse. Isto leva ao 
conceito de herança de atributos; ou seja, a subclasse herda todos os atributos da superclasse. Isso 
porque a entidade de subclasse representa as mesmas características de uma mesma entidade da 
superclasse. Uma subclasse pode herdar atributos de superclasses diferentes. Uma representação 
diagramática do exemplo mencionado é ilustrada na Figura 15.
Figura 15. Representação de Superclasse e Subclasses
Nome
No Funcional
CPF
RG
Dt. Nascimento
Sexo
Endereço
Empregado
Função
d
Engenheiro Engenheiro
No Registro
Especialização
Qualificação
Idiomas
Especialização
Especialização é o processo de definição de um conjunto de classes de um tipo entidade; esse tipo 
entidade é chamado de superclasse da especialização. O conjunto de subclasses é formado com base 
em alguma característica que distinga as entidades entre si.
No exemplo da Figura 15, temos uma especialização, que podemos chamar de função. Veja agora no 
exemplo da Figura 16, temos a entidade empregado e duas especializações.
42
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
Figura 16. Duas Especializações para Empregado: Função e Categoria Salarial
Engenheiro HoristaSecretária Mensalista
Empregado
Função
Categoria Salarial
dd
Como visto anteriormente, uma subclasse pode ter relacionamentos específicos com outras entidades 
ou com a própria entidade, que é a sua superclasse. Veja o exemplo da Figura 17.
Figura 17. Relacionamentos entre Subclasses e Entidades
d
Secretária
Empregado
Engenheiro
Projeto
É desenvolvido por N
N
S
N
É liderado
Lidera
Participa
Função
O processo de especialização nos permite:
 » definir um conjunto de subclasses de um tipo entidade;
 » associar atributos específicos adicionais para cada subclasse;
 » estabelecer tipos relacionamentos específicos entre subclasses e outros tipos 
entidades.
Generalização
A generalização pode ser pensada como um processo de abstração reverso ao da especialização, no 
qual são suprimidas as diferenças entre diversos tipos entidades, identificando suas características 
comuns e generalizando essas entidades em uma superclasse.
43
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
Figura 18. Tipos Entidades Engenheiro e Secretária
Figura 19. Generalização Empregado para os Tipos Entidades Engenheiro e Secretária
É importante destacar que existe diferença semântica entre a especialização e a generalização. Na 
especialização, podemos notar que a ligação entre a superclasse e as subclasses é feita por meio 
de um traço simples, indicando participação parcial por parte da superclasse. Analisando o 
exemplo da Figura 17, é observado que um empregado não é obrigado a ser um engenheiro ou 
uma secretária. Na generalização, podemos notar que a ligação entre a superclasse e as subclasses 
é feita por intermédio de um traço duplo, indicando participação total por parte da superclasse. 
Analisando o exemplo da Figura 18, é observado que um empregado é obrigado a ser um engenheiro 
ou uma secretária.
A letra d dentro do círculo que especifica uma especialização ou uma generalização significa 
disjunção. Uma disjunção em uma especialização ou generalização indica que uma entidade do 
tipo entidade que representa a superclasse pode assumir apenas um papel dentro dela. Analisando 
o exemplo da Figura 19 temos duas especializações para a superclasse Empregado, as quais são 
restringidas por meio de uma disjunção. Nesse caso, um empregado pode ser um engenheiro ou 
uma secretária e ele pode ser horista ou mensalista.
Além da disjunção, podemos ter um overlap, representado pela letra o. No caso do “overlap”, uma 
entidade de uma superclasse pode ser membro de mais que uma subclasse em uma especialização ou 
generalização. Analise a generalização no exemplo da Figura 20. Suponha que uma peça fabricada em 
uma tornearia pode ser manufaturada ou torneada, ou ainda, pode ter sido manufaturada e torneada.
44
UNIDADE I │ INTRODUÇÃO À MODELAGEM CONCEITUAL
Figura 20. Uma Generalização com “Overlap”
“Lattice” ou múltipla herança
Uma subclasse pode ser definida por meio de um “lattice”, ou múltipla herança, ou seja, ela pode 
ter diversas superclasses, herdando características de todas. Tomemos como base a situação de 
que uma construtora possui diversos funcionários, que podem ser engenheiros ou secretárias. Um 
funcionário pode também ser assalariado ou horista. Todo gerente de departamento da construtora 
deve ser um engenheiro e assalariado.
O modelo lógico da expressão acima tem o seguinte formato (Figura 21):
Figura 21. Um “Lattice” com a Subclasse Gerente Compartilhada
Nesse caso, então, um gerente será um funcionário que, além de possuir as características próprias 
de Gerente, herdará as características de Engenheiro e de Mensalista.
45
INTRODUÇÃO À MODELAGEM CONCEITUAL │ UNIDADE I
Diagrama entidade-relacionamento
O Diagrama Entidade-Relacionamento (DER) é composto por um conjunto de objetos 
gráficos que visa representar todos os objetos do modelo Entidade Relacionamento, tais como 
entidades, atributos, atributos chaves, relacionamentos, restrições estruturais etc.
O diagrama ER oferece uma visão lógica do banco de dados, fornecendo um conceito mais 
generalizado de como