Apostila ProjetoBancoDadosI

Prévia do material em texto

PROJETO DE BANCO DE DADOS
Sandra Rovena Frigeri
2PROJETO DE BANCO DE DADOS
SUMÁRIO
CENTRO UNIVERSITÁRIO UNIFTEC
Rua Gustavo Ramos Sehbe n.º 107. 
Caxias do Sul/ RS 
REITOR
Claudino José Meneguzzi Júnior
PRÓ-REITORA ACADÊMICA
Débora Frizzo
PRÓ-REITOR ADMINISTRATIVO
Altair Ruzzarin
DIRETORA DE EDUCAÇÃO A DISTÂNCIA (NEAD)
Lígia Futterleib
Desenvolvido pelo Núcleo de Educação a 
Distância (NEAD)
Designer Instrucional 
Sabrina Maciel
Diagramação, Ilustração e Alteração de Imagem
Igor Zattera
Revisora
Ana Clara Garcia
PERSPECTIVA HISTÓRICA DOS BANCOS DE DADOS 6
PRIMEIROS TEMPOS 7
DÉCADA DE 70 11
DÉCADA DE 80 13
DÉCADA DE 90 14
SITUAÇÃO ATUAL E FUTURO 15
FUNDAMENTOS E CONCEITOS DE BANCO DE DADOS 18
A EVOLUÇÃO DO DADO 19
SISTEMA DE GERÊNCIA DE BANCO DE DADOS 20
POR QUE USAR SGBD? 22
ARQUITETURA DO SGBD 23
LINGUAGEM PADRÃO DOS SGBD 27
MODELAGEM DE DADOS 28
MODELO ENTIDADE-RELACIONAMENTO 34
CONCEITOS CENTRAIS DO MODELO ER 35
MODELO RELACIONAL 50
CHAVES 51
RESTRIÇÕES DE INTEGRIDADE 52
ESPECIFICAÇÃO RESUMIDA DE UM ESQUEMA RELACIONAL 55
NORMALIZAÇÃO DE BANCO DE DADOS 55
MAPEAMENTO ER → RELACIONAL 58
MAPEAMENTO DE ENTIDADES 59
MAPEAMENTO DE RELACIONAMENTOS DO TIPO (N:N) 59
MAPEAMENTO DE RELACIONAMENTOS DO TIPO (1:N) 62
MAPEAMENTO DE RELACIONAMENTOS DO TIPO (1:1) 62
MAPEAMENTO DE AUTORRELACIONAMENTOS 63
MAPEAMENTO DE RELACIONAMENTOS IDENTIFICADORES 65
MAPEAMENTO DE GENERALIZAÇÃO/ESPECIALIZAÇÃO 65
3PROJETO DE BANCO DE DADOS
APRESENTAÇÃO
Informações são essenciais para a 
tomada de decisões e para a gestão das 
organizações, contudo o volume de dados/
informações cresce a cada dia, tornando 
complexa a atividade de recuperá-las e 
relacioná-las. Assim, os Sistemas Geren-
ciadores de Banco de Dados tornam-se 
importante ferramenta, pois possibilitam 
o armazenamento e recuperação eficiente 
de dados/informações. O objetivo deste 
material é oferecer uma introdução aos 
conceitos de Banco de Dados, sua história 
e evolução, demonstrar a relevância da 
modelagem de dados e estudar técnicas 
de modelagem, e, finalmente, apresentar 
algumas perspectivas para o futuro dos 
bancos de dados.
4PROJETO DE BANCO DE DADOS
INTRODUÇÃO
Você já se questionou sobre a importância da 
informação?
Peter Drucker já defendia, em 1993, que a informação é a base para a gestão, 
afirma que estamos na sociedade do conhecimento e, assim, a informação passa a 
suplantar o valor do capital financeiro e de seu adequado uso depende o sucesso 
empresarial. Nesse sentido, o acesso à informação aliado à capacidade de extração 
de conhecimentos é vital para a ampliação do potencial competitivo, pois pode pro-
porcionar a eficiência na utilização dos recursos, maximizando resultados.
A organização dos dados, as es-
truturas que identificam seus elementos 
relevantes e como estão relacionados, o 
ciclo de vida da informação, mudanças que 
ocorrem ao longo do tempo e recursos para 
facilitar as pesquisas, são aspectos muito 
importantes para que tenhamos as infor-
mações que precisamos, quando forem 
necessárias, com a precisão e qualidades 
adequadas.
Saiba, que na história, esses registros 
eram feitos em papel, separados em pastas/
caixas/gavetas/estantes, com guias de con-
“Who has good quality information, 
reliable, the correct amount at 
the right time, get competitive 
advantage, but the lack of information 
gaps gives the errors and missed 
opportunities.”1
Peter Drucker
1“Quem dispõe de informações de boa qualidade, fidedignas, em quan-
tidade adequada e no momento certo, adquire vantagens competitivas, 
mas a falta de informação dá brechas a erros e à perda de oportunidades.”
Peter Ferdinand Drucker 
(19/11/1909 – 11/11/2005)
5PROJETO DE BANCO DE DADOS
sulta que indexavam os dados, permitindo 
buscas limitadas por determinados termos 
pré-definidos. A evolução da informática 
trouxe alternativas para realização do re-
gistro e recuperação de dados, trazendo 
eficiência ao processo, apresentando pos-
sibilidades de cruzamentos e permitindo 
a dedução de novas informações. Inicial-
mente, os registros informatizados eram 
bastante rudimentares e o potencial de 
buscas bastante restrito, mas atualmente 
a capacidade dos Sistemas Gerenciadores 
de Banco de Dados é muito grande, per-
mitindo o armazenamento e recuperação 
eficientes1 e eficazes2 de grandes volumes 
de dados. 
O gmail tem mais de 60 milhões de 
usuários, o Google Earth e Google Maps 
armazenam imagens do mundo todo, es-
truturas de vias, roteiros, etc. Além disso, 
a Google guarda informações de todas as 
páginas do mundo e recebe mais de 100 
milhões de consultas por dia. Estima-se 
que a Google armazene muitos petabytes 
de dados (1 petabyte = 1024 terabytes).
Tudo isso somente é possível com a 
utilização de SGBD (Sistemas Gerencia-
dores de Bancos de Dados)!
A história dos Sistemas Gerenciado-
res de Banco de Dados inicia na década de 
60 (século XX), nos laboratórios da IBM, 
onde faziam pesquisas para automação de 
escritórios, pois já percebiam a impor-
tância da informação e o alto custo, em 
termos de pessoas e espaço, necessário para 
gerenciá-la. Desde essa época, até hoje, 
muito mudou e juntos analisaremos sua 
1Ser eficiente é uma qualidade que indica a rapidez de realização de 
uma atividade, é agilizar os processos para chegar ao objetivo no menor 
tempo possível.
2Ser eficaz é uma qualidade que tem relação com a ideia de efeito, 
assim, a partir de uma determinada ação, segue sempre um resultado 
esperado/desejável.
perspectiva histórica, no primeiro capítulo.
Banco de dados é uma área de pes-
quisa e desenvolvimento no contexto de 
Ciência da Computação. Dessa forma, 
possui conceitos fundamentais e termino-
logias específicas, que precisam ser conhe-
cidos e compreendidos para o adequado 
uso dessa tecnologia, assim no segundo 
capítulo nos focaremos nesse objetivo.
Para que possamos recuperar infor-
mações, elas precisam ser adequadamente 
armazenadas. Assim, surge a necessidade 
da modelagem de dados que definirá a 
organização dos bancos de dados. Dessa 
forma, no terceiro capítulo, estudaremos 
os fundamentos da modelagem entidade-
-relacionamento (DER), que é conside-
rado um dos mais importantes modelos 
de banco de dados. E na sequência, no 
quarto capítulo estudaremos o Modelo 
Relacional. Por último, no quinto capítulo, 
aprenderemos a transformar um diagrama 
ER e um esquema de dados relacional.
Tenho certeza que você irá gos-
tar muito de aprender sobre Bancos de 
Dados! 
Você já pensou sobre como a Google 
armazena e recupera informações?
6PROJETO DE BANCO DE DADOS
PERSPECTIVA 
HISTÓRICA DOS 
BANCOS DE 
DADOS
Você já pensou sobre como armazenamos as 
informações que precisamos consultar?
Como foi a evolução deste recurso tão 
importante para todos os sistemas?
Para iniciarmos o nosso estudo, é importante conhecer 
o início dos bancos de dados, tão importante para as organi-
zações empresariais, como para nós. Vamos compreender a 
sua evolução, seus marcos históricos e tecnológicos, além de 
entender as suas perspectivas futuras. A história dos bancos 
de dados está ligada ao desenvolvimento da ciência da com-
putação, suas transformações tecnológicas e sua inf luência 
sobre forma como os profissionais de informática pensam a 
estruturação da informação. As práticas, frameworks e usos 
7PROJETO DE BANCO DE DADOS
de bancos de dados, tão pioneiros nos pri-
mórdios, tornaram-se intrínsecos ao modo 
como as organizações gerenciam os dados.
A atual velocidade da produção de 
dados é impulsionada pela demanda e 
acessibilidade que aumentam, constan-
temente, à medida que as bases de dados 
se tornam cada vez mais essenciais para 
aspectos de nossas vidas diárias. Deve-se 
ter em conta, que o volume de dados em 
muitos períodos excedeu a capacidade de 
processamento (humana e computacional) 
e isso sempre impulsionou a busca por al-
ternativas mais eficientes, impulsionando 
a evolução dos bancos de dados3. 
PRIMEIROS TEMPOS
A IBM (International Business Ma-
chine) está ligada àsorigens de muitos 
desenvolvimentos tecnológicos computa-
cionais e não podia ser diferente com os 
3 Herman Hollerith, ao ver a crescente quantidade de dados recolhidos 
pelo Censo dos EUA de 1880 (que levou 8 anos para ser tabulada), inventou 
“Hollerith cartões”, classificador e máquinas de tabulação, com o propósito 
de tabular dados, representados por buracos nos cartões de perfurados. A 
Hollerith’s Tabulating Machine Company foi posteriormente fundida 
com outras três empresas em International Business Machines (IBM).
banco de dados. 
Na década de 1960 foram desenvol-
vidas pesquisas para automação de escri-
tórios, que visavam otimizar os proces-
sos realizados, organizar as informações 
e facilitar o trabalho. Nesse período, os 
dados eram organizados em arquivos ge-
renciados pelo sistema operacional, era 
uma maneira rudimentar de armazená-los, 
mas que oferecia vantagens em relação ao 
armazenamento físico em papel. Por outro 
lado, os sistemas de arquivos apresentavam 
alguns inconvenientes:
Redundâncias e Inconsistências
Frequentemente a mesma informa-
ção estava em diversos arquivos (repetida), 
ou seja, havia redundância. Esta caracte-
rística pode levar a um grave problema 
que é a inconsistência, pois com a mesma 
informação repetida em dois ou mais ar-
quivos, ela poderia ser atualizada em um 
deles e não ser em outro, assim passa a ter 
dois (ou mais) valores diferentes, inconsis-
tentes e, muitas vezes, não se sabe qual o 
correto. Exemplo: Um arquivo com dados 
dos funcionários, onde se tem o endereço. 
Outro arquivo com dados de voluntários, 
onde também se tem o endereço. Agora, 
suponha que uma pessoa que é funcioná-
rio e também voluntário, teria seus dados 
redundantes, repetidos em ambos os ar-
quivos. Se ela mudar de endereço e este for 
somente alterado no arquivo de funcioná-
rios. A partir dessa alteração, como saber 
qual o endereço correto, pois seu endereço 
estará diferente em cada um dos arquivos. 
Esse é um problema grave e denomina-se 
inconsistência (a mesma informação com 
valores diferentes em lugares diferentes).
Dificuldade de Acesso
O acesso ás informações organi-
zadas em arquivos, devem ser feitas pelo 
sistema (softwares/aplicação) que a gerou, 
assim para acessar as informações de um 
arquivo, também é necessário saber como 
foi gerada (linguagem de programação e/
ou sistema) e sua estrutura, caso contrário, 
na maioria das vezes o acesso fica inviável.
8PROJETO DE BANCO DE DADOS
Falta de Integridade Lógica e Isolamento de 
dados
Um dos principais objetivos do ar-
mazenamento de informações é realizar 
o cruzamento de diversos dados, identi-
ficando suas relações, porém a organiza-
ção da informação em arquivos isola as 
informações, pois cada arquivo pode ter 
sido gerado por sistemas e/ou linguagens 
diferentes, que normalmente não possuem 
meios de intercomunicação, dificultando a 
realização de cruzamentos e reduzindo a 
capacidade de análise dos dados. Arquivos 
de dados não possuem integridade lógica, 
ou seja, não há relações entre os dados de 
um arquivo com os dados de outro arquivo, 
estão isolados.
Falta de Atomicidade nas Transações
Transações são processos realizados 
em sistemas computacionais, com o obje-
tivo de realizar alguma tarefa dentro do 
contexto de uma aplicação. Normalmente, 
as transações envolvem um conjunto de 
atividades que somente são coerentes e 
corretas, se consideradas como uma uni-
dade atômica (indivisível), ou seja, todas 
as operações da transação devem ser exe-
cutadas, caso contrário o resultado será 
indesejável. Sistemas que trabalham com 
arquivos convencionais não possuem ferra-
mentas que possam, efetivamente, garantir 
a atomicidade das transações, esse controle 
deve ser implementado em cada aplicação 
pelos programadores, que caso se esque-
çam ou não dos testes, adequadamente a 
implementação poderá compromete-la. 
Considere o seguinte exemplo: de-
seja-se fazer uma transferência bancária, 
sacando R$ 100,00 da conta do cliente 
A e depositando este valor na conta do 
cliente B. Isso é uma transação e envolve 
as seguintes atividades: iniciar o processo 
de transferência; consultar o saldo da conta 
do cliente A; informar o valor a ser sacado; 
registrar a retirada da conta do cliente A 
do valor sacado; atualizar o saldo da conta 
do cliente A; consultar o saldo da conta 
do cliente B; registrar p depósito na conta 
do cliente B; alterar o saldo na conta do 
cliente B; finalizar a transação. Perceba 
que todas as atividades dessa transação 
precisam ser realizadas, não se pode parar 
no meio (por uma falha técnica ou por 
qualquer outro motivo), pois isso com-
prometeria a qualidade e consistência das 
informações do sistema, além de reclama-
ções dos clientes!
Problemas de Acesso Concorrente
As informações dos arquivos de-
vem refletir as atualizações mais recentes. 
Porém, o que ocorre quando mais de um 
sistema ou pessoa deseja atualizar a mesma 
informação ao mesmo tempo? De quem 
deve ser a prioridade? Como garantir que 
a informação fique correta? Ness e caso, o 
procedimento a ser desenvolvido é sempre 
que for consultada uma informação com 
a intenção de alterá-la o seu acesso deve 
ficar bloqueado aos outros usuários até que 
libere a informação. A responsabilidade 
deste controle nos sistemas de arquivos 
convencionais é do programador de cada 
aplicação, que pode estar sujeito a falhas.
Agora, suponha que quase no mes-
9PROJETO DE BANCO DE DADOS
mo instante estão sendo realizadas duas transferências bancárias, portanto duas 
transações concorrentes. Considere ainda, os seguintes saldos dos clientes: Cliente A: 
R$ 200,00; Cliente B: R$ 50,00; e Cliente C: R$ 100,00. Assim, hipoteticamente, 
se o banco tivesse apenas esses três clientes o total em depósitos seria R$ 350,00. A 
tabela a seguir exemplifica o problema da execução concorrente destas transações, 
sendo T0 o tempo inicial e Tx a sequencial temporal de realização das atividades.
Atividade Transação 1: 
transferir R$ 100,00 do 
cliente A para o cliente B
Transação 2: 
transferir R$ 200,00 do 
cliente A para o cliente C
Iniciar o processo de transferência T0 T1
Consultar o saldo da conta do 
cliente A T2: saldo=R$ 200,00 T3: saldo=R$ 200,00
Informar o valor a ser sacado T4: R$ 100,00 T5: R$ 200,00
Registrar a retirada da conta do 
cliente A do valor sacado T6: saldo = 200 - 100 T7: saldo = 200 - 200
Atualizar o saldo da conta do cliente 
A
T8: saldo = 100 (gravar)
(cliente A)
T9: saldo = 0 (gravar)
(cliente A)
Consultar o saldo da conta do 
cliente que recebe a transferência
T10: saldo = 50
(cliente B)
T11: saldo = 100
(cliente C) 
Registrar o depósito na conta do 
cliente
T12: saldo = 50 + 100
(cliente B)
T13: saldo = 100 + 200
(cliente C)
Alterar o saldo na conta do cliente T14: saldo = 150 (gravar)(cliente B)
T15: saldo = 300 (gravar)
(cliente C)
Finalizar a transação T16 T17
Demonstração do Problema de Acesso Concorrente
Portanto, o saldo final das contas é: 
Cliente A: R$ 0,00; Cliente B: R$ 150,00; 
e Cliente C: R$ 300,00. Assim, novamente 
hipoteticamente, se o banco tivesse apenas 
esses três clientes o total em depósitos, 
agora seria R$ 450,00. Perceba que após o 
processo, com problemas de concorrência, 
o saldo total de depósitos foi alterado e 
deveria se manter o mesmo! O problema 
é que essas duas transações não poderiam 
ser executadas simultaneamente, visto que 
consultam e alteram a mesma informação 
que é o saldo do cliente A. Para correta 
execução concorrente, a segunda transa-
ção somente poderia ser liberada após o 
término da primeira e neste caso o saldo 
consultado já teria sido alterado.
Problemas de Segurança
As informações das corporações e 
nossas informações pessoais, entre ou-
tras, muitas vezes não devem ser acessadas 
por pessoas não autorizadas, portanto é 
necessário implementar mecanismos que 
as protejam. Nos primórdios, utilizando 
arquivos para o armazenamento, pois o 
10PROJETO DE BANCO DE DADOS
controle da segurança também precisavaser implementado pelos programadores 
em cada aplicação, porém sem essa, os 
dados ficavam vulneráveis e abertos para 
acessos indevidos. Portanto, os sistemas de 
arquivos tinham problemas de segurança.
CODASYL E IMS
Nesta época, os computadores pro-
gressivamente passam a se tornar parte 
do custo das empresas, evidenciando as 
necessidades de ampliação das capacidades 
de armazenamento e recuperação de dados. 
O resultado deste interesse foi o desen-
volvimento dos dois primeiros modelos 
de dados: modelo em rede (CODASYL 
- Comitee for Data Systems Language) e 
o modelo hierárquico (IMS – Information 
Management System). Eram modelos em 
que a estrutura lógica de acesso à infor-
mação estava intrinsecamente ligada à or-
ganização física e aos recursos da lingua-
gem para acesso aos dados. Assim, eram 
utilizados links (ligações) entre os dados/
registros que eram implementados através 
de ponteiros de baixo nível (referência ao 
endereço do dispositivo de armazenamen-
to). Qualquer alteração na estrutura dos 
dados implicava na reescrita dos programas 
para realização do armazenamento e das 
consultas, também era necessário conhecer 
toda a estrutura física para todo o desen-
volvimento. A diferença básica entre esses 
modelos é a forma como as ligações podem 
ser estruturadas. No modelo hierárquico 
é necessário ter uma origem da hierarquia 
e as outras informações são relacionadas 
abaixo desta, formando a hierarquia, de 
onde vem a denominação do modelo. Já, 
no modelo em rede não há a limitação da 
estrutura hierárquica, permitindo que as 
informações sejam relacionadas sem uma 
origem.
A IBM lançou um dos primeiros 
sistemas de banco de dados no final da 
década de 60, que foi o IMS (Information 
Management System). Na mesma época, 
o comitê da CODASYL lança o sistema 
de banco de dados em rede integrado a 
linguagem COBOL4 .
Esses modelos foram uma evolução 
em relação a utilização de arquivos para 
gerenciamento de informações, permitiam 
que os dados que seriam armazenados fos-
sem organizados e relacionados, diminuin-
do os problemas de acesso aos dados, falta 
de integridade e isolamento dos mesmos. 
Mas ainda era necessário evoluir!
4 COBOL é a sigla de COmmon Business Oriented Language 
(Linguagem Comum Orientada para os Negócios) é uma linguagem de 
programação criada com foco para o processamento de banco de dados 
comerciais, desenvolvida no final da década de 50, integrada a sistemas 
de banco de dados no final da década de 60, tornou-se a linguagem mais 
utilizada durante as décadas de 70 e 80 para o desenvolvimento de aplicações 
comerciais. Ainda foi amplamente utilizada na década de 90 e começou sua 
decadência no início do século XXI. Ainda é possível encontrar aplicações 
em uso desenvolvidas em COBOL.
Agora, vamos refletir!
 Arquivos ainda são utilizados? Com 
certeza sim! Você e muitas organizações 
utilizam arquivos de editores de textos, 
planilhas eletrônicas, anotações, 
imagens/fotos, etc. O gerenciamento 
destes arquivos apresenta alguns dos 
inconvenientes dos arquivos utilizados nos 
primórdios dos bancos de dados?
11PROJETO DE BANCO DE DADOS
DÉCADA DE 70
E.F. Codd foi um matemático in-
glês que trabalhava na IBM, que em 1972 
publicou um artigo chamado “Relational 
Model of Data for Large Shared Data Banks”. 
Esse artigo apresentou os fundamentos 
do Modelo de Banco de dados Relacio-
nal, baseado na Teoria de Conjuntos5 , 
lançando as bases para que informações 
interligadas fossem definidas como rela-
ções (conjuntos) e adaptando essa teoria 
matemática para a área de banco de dados. 
Também apresentou o cálculo e a álgebra 
relacional que consistem em conjunto de 
operações matemáticas para manipulação 
das informações.
A proposta de Codd era comple-
xa e não foi prontamente aceita e imple-
mentada, mas ele conseguiu que a IBM 
permitisse a implantação de um grupo de 
pesquisa denominado System R (Sistema 
5 Ramo da matemática, a Teoria dos conjuntos estuda as coleções 
de elementos (conjuntos). A linguagem da teoria dos conjuntos inclui 
definições que especificam relações entre elementos e conjuntos, possui 
operadores que determinam essas relações (contém e está contido) e pos-
sibilita operações entre conjuntos, tais como: união, intersecção, diferença 
e produto cartesiano. Esta teoria inclui a especificações do cálculo e da 
álgebra para os conjuntos.
R - Relacional), que acabou por dar nome 
ao Sistema Relacional. Este sistema evo-
lui e finalmente passou a ser chamado de 
DB2, o principal e mais conhecido sistema 
de banco de dados da IBM. 
Com o System R foi desenvolvida 
uma linguagem conhecida por Structured 
Query Language6 (SQL) . O Modelo de 
Banco de Dados Relacional e os Sistemas 
de Banco de Dados Relacionais tornaram-
-se padrão para a indústria de banco de 
dados e é um padrão ISO7 (International 
Organization for Standardization) . 
Sistemas de Banco de Dados Rela-
cionais separam os dados da aplicação da 
sua estrutura de armazenamento e pos-
sibilitam a manipulação das informações 
através de uma linguagem de consulta 
que implementa as operações matemáticas 
especificadas no modelo relacional.
O protótipo do System R foi lan-
çado pela IBM, em 1974, que somente 
4 Linguagem de Consulta Estruturada, hoje também conhecida 
como Linguagem de Consulta Padrão (Standard Query Language).
7 Organização Internacional de Padronização.
Edgar Frank Codd
(23/8/1923 – 18/4/2003)
12PROJETO DE BANCO DE DADOS
disponibilizou sua versão comercial em 
1981. O primeiro Sistema Gerenciador 
de Banco de Dados Relacional comercia-
lizado, foi desenvolvido pela Honeywell 
Information Systems Inc. em 1976, mas 
não existe mais. Ainda antes da IBM, em 
1979 a ORACLE Corporation lança o 
ORACLE DataBase System e torna-se o 
SGBD Relacional mais conhecido e uma 
das maiores corporações reconhecidas até 
os dias de hoje.
Outra grande contribuição para evo-
lução dos Sistemas de Banco de Dados foi 
o Modelo Entidade-Relacional proposto 
por Peter Chen em seu artigo “The Enti-
ty-Relationship Model--Toward a Unified 
View of Data” publicado na ACM Tran-
sactions on Database Systems, em 1976. 
Esse artigo é um dos mais importantes 
para a área de banco de dados e para a 
ciência da computação, além de ser um 
dos trabalhos mais citados. A inovação da 
proposta de Chen, foi a especificação de 
um modelo independente da implemen-
tação do Sistema Gerenciador de Banco 
de Dados, iniciando o que chamamos de 
modelagem conceitual de banco de dados.
O Modelo ER8, como é conhecido, 
tornou-se base para diversas metodologias 
de análise e projeto de sistemas, para o 
desenvolvimento de ferramentas de mo-
delagem e de apoio ao desenvolvimento 
de software (ferramentas CASE9), projetos 
de dicionários e repositórios de dados. 
Esse modelo ainda é utilizado atualmen-
te, diversas extensões foram agregadas à 
proposta original, além de ser a base para 
outros modelos como o diagrama de clas-
ses do paradigma orientado a objetos. Em 
1979 ocorreu a primeira conferência de 
modelagem conceitual10, conhecida como 
ER Conference. Entre os dias 14 e 17 de 
novembro de 2016 ocorreu a 35º ER Con-
ference, demonstrando a atual relevância 
do trabalho realizado por Peter Chen e as 
ramificações desse no contexto da mode-
lagem conceitual de banco de dados.
As contribuições de Codd e Chen 
foram determinantes para evolução dos 
Sistemas Gerenciadores de Banco de Da-
8 Modelo ER (Modelo Entidade-Relacionamento), também 
conhecido simplesmente por Diagrama ER (DER).
9 CASE: Computer Aided Software Engineer (Engenharia de 
Software Auxiliada por Computador)
10 International Conference on Conceptual Modeling (http://
www.conceptualmodeling.org/)
Peter Chen
(Nasceu em 3/1/1947)
13PROJETO DE BANCO DE DADOS
dos, mas ainda havia muito trabalho a ser 
feito em termos de desenvolvimento das 
ferramentas e superação das limitações 
do hardware (principalmente em relação 
aos dispositivos de armazenamento). Ao 
final dessa década, tem-se as bases para 
o armazenamentoe recuperação de dados 
baseados no modelo relacional, mas as 
aplicações ainda não apresentam eficiência 
adequada e muitos desenvolvedores ainda 
preferem utilizar a linguagem COBOL 
com os sistemas de banco de dados base-
ados nos modelos hierárquico e em rede.
DÉCADA DE 80
Nesta década ocorreu um grande 
desenvolvimento dos bancos de dados e 
muitas melhorias foram implementadas 
nos SGBDs, possibilitando que seu uso 
comercial fosse ampliando. A ORACLE 
lançou o ORACLE 2 e a IBM lançou o 
SQL/DS (que depois tornou-se o DB2), 
utilizado como repositório de dados por 
muitas aplicações. 
Em paralelo com a evolução de siste-
mas baseados no modelo relacional, inicia-
ram os estudos que levaram ao desenvol-
vimento de Sistemas de Banco de Dados 
Orientados a Objetos para manipularem 
informações que não eram passíveis de 
serem modeladas através do Modelo Re-
lacional, tais como aplicações de medicina, 
multimídia e física, as quais precisavam 
de mais f lexibilidade para a especificação 
e gerenciamento de suas informações. Os 
primeiros SGBDOO (Sistemas Gerencia-
dores de Banco de Dados Orientados a 
Objetos) foram: O2 [1988]; Exodus [1986]; 
e ORION [1986].
A partir desses estudos, começaram 
a surgir Sistemas Gerenciadores de Banco 
de Dados Relacionais, os quais agregavam 
características dos Banco de Dados Orien-
tados a Objetos: POSTGRES [1986]; e 
STARBURST [1988]. 
A performance e ferramentas de 
apoio, ao desenvolvimento, são ampla-
mente difundidas no final desta década e 
se amplia a confiança para o desenvolvi-
mento de aplicações baseadas em banco de 
dados. Contribui para isso, a padronização 
da linguagem SQL, que define que todo 
SGBD Relacional deve utilizar a mesma 
linguagem a SQL ANSI11 [1986, 1989], 
assim uma aplicação desenvolvida para 
um banco de dados relacional utilizará a 
mesma linguagem para manipulação das 
informações, tornando as aplicações por-
táveis12, conferindo certa independência 
do SGBD.
Nesse período, já se tem diversos 
SGBDs a disposição, entre eles se pode 
destacar os seguintes: DB2; Ingres; Oracle; 
Sybase; e Informix.
11 American National Standards Institute.
12 Portabilidade de uma aplicação em relação ao Sistema Geren-
ciador de Banco de Dados, indica que esta pode ser desenvolvida para um 
SGBD específico e pode ser utilizada em outro, realizando apenas poucos 
ajustes.
14PROJETO DE BANCO DE DADOS
DÉCADA DE 90
Nesse período, os Sistemas Ge-
renciadores de Banco de Dados se po-
pularizaram e a maioria das aplicações já 
passaram a ser desenvolvidas, utilizando 
essa tecnologia para armazenamento e re-
cuperação de informações. Diversos recur-
sos e ferramentas foram incorporados aos 
SGBDs disponibilizados comercialmente 
e as melhorias no hardware e sistemas 
operacionais também contribuíram para 
melhoria de sua eficiência. Já, o uso dos 
sistemas baseados nos modelos hierárquico 
e em rede passou a se restringir aos siste-
mas legados13. 
13 Sistemas Legados são aqueles baseados em tecnologias obsoletas 
ou em obsolescência, que já estão em desuso.
Há também muitos avanços na área 
de banco de dados, alguns relacionados 
a estruturação das informações e tipos 
de informações que podem ser manipu-
ladas, outros para melhorar a forma de 
processamento das informações ou ainda 
interfaces entre aplicações e para os di-
versos tipos de usuários. Assim surgem 
comercialmente, a partir de pesquisas já 
realizadas, SGBDs paralelos, SGBDs de 
tempo real, SGBD Orientados e Objetos, 
SGBDs multimídia além de SGBDs para 
arquiteturas cliente-servidor, alinhados à 
evolução dos sistemas operacionais. 
Além disso, são funções aplicadas, 
que eram, até o momento, baseadas no 
registro e recuperação de dados ligados à 
área operacional das organizações. Assim, 
começam a ser amplamente utilizados Sis-
temas de Apoio a Tomada de Decisões, 
Sistemas Especialistas, Sistemas para Des-
coberta de Conhecimento em Bases de 
Dados, Mineração de Dados, Sistemas 
para gerenciamento de mídias, multimí-
dias e hipermídia, além de aplicações que 
integram bases de dados de fontes diver-
sificadas (Datawarehouse). Acrescenta-se 
a isso, os desenvolvimentos de sistemas de 
banco de dados para gerenciamento de 
páginas e informações da internet.
Os SGBDs chegaram a sua matu-
ridade, possuem distribuições comerciais 
estáveis e confiáveis, mas ainda existem 
desafios a serem superados, como por 
exemplo o crescimento do volume de da-
dos.
15PROJETO DE BANCO DE DADOS
SITUAÇÃO ATUAL E FUTURO
No século XXI, amplia-se o uso dos 
bancos de dados XML14 , que são um tipo 
de banco de dados estruturado orientado a 
documentos e que permite consultas com 
base em atributos de documentos XML. 
Os bancos de dados XML são utiliza-
dos como padrão de interoperabilidade 
de dados máquina-a-máquina. Também 
surgem os bancos de dados NoSQL que, 
geralmente, são muito rápidos, não re-
querem esquemas de tabela fixa, evitam 
operações de junção, armazenando dados 
desnormalizados e são projetados para 
trabalhar com escalonamento horizontal.
É desenvolvido também o NewS-
QL, o qual é uma classe de Banco de Da-
dos Relacionais modernos, que tem como 
objetivo fornecer o mesmo desempenho 
14 XML (eXtensible Markup Language) é um padrão recomendado 
pela da W3C para produzir arquivos com objetivos específicos. A XML 
deriva da SGML (acrônimo de Standard Generalized Markup Language ou 
Linguagem Padronizada de Marcação Genérica) e possibilita a descrição de 
diversos tipos de dados. O objetivo principal é facilitar o compartilhamento 
de informações pela internet. O Consórcio World Wide Web (W3C) é 
um consórcio internacional no qual organizações filiadas, uma equipe em 
tempo integral e o público trabalham juntos para desenvolver padrões para 
a Web. (https://www.w3.org/ )
escalável de sistemas NoSQL para pro-
cessamento on-line de transações (leitura 
e gravação), enquanto ainda usa o SQL. 
Esses bancos de dados incluem ScaleBa-
se, Clustrix, EnterpriseDB, MemSQL, 
NuoDB e VoltDB.
A história dos SGBDs está ligada a 
necessidade de armazenar grandes volumes 
de informações para que possam ser recu-
peradas, de forma eficiente e convenien-
te. Estima-se que em 2020 serão gerados 
mais de 40 zetabytes de dados (mais de 40 
trilhões de gigabytes), de fontes de dados 
diversificadas: sistemas empresariais, sis-
temas de instituições de pesquisa, sistemas 
de monitoramento, dados climáticos, redes 
sociais, fotos, etc. Constitui-se ainda um 
desafio organizar todas essas informações 
de maneira a torná-las úteis e significati-
vas, permitindo que sejam correlacionadas 
e que possibilitem a tomada de decisões 
ou o seu simples acesso, quando forem 
necessárias e relevantes. Esse grande vo-
lume de informações constitui o Big Data.
O Big Data sinaliza o princípio de 
uma grande transformação na sociedade, 
assim como o telescópio alterou a forma de 
compreensão do universo e o microscópio 
nos permitiu ver o que parecia invisível. 
Big Data mudará a forma de como per-
cebemos o mundo, pois deixamos de ter 
problemas para coletar dados, não temos 
mais escassez de dados, contudo, agora, 
temos abundância de dados. Com isso, 
surge um novo problema, pois temos uma 
capacidade limitada para lidar com gran-
des volumes de dados e torna-se cada vez 
mais difícil filtrar o que nos interessa ou 
não.
O impacto do Big Data supera a 
invenção da imprensa (1430), que nos pri-
meiros 50 anos publicou mais conteúdos 
que em toda a história anterior. Desde 
2010, a cada 2 dias são gerados mais dados 
do que em toda a história da humanida-
de (anterior à internet) e estima-se que a 
cada 2 anos o volume de informações seja 
duplicado.
Assim, muitas pesquisas tem sido 
realizadas para trabalhar com o Big Data, 
essas visam a integração de diversas ferra-
mentas e desenvolvimento de novas com o 
16PROJETO DE BANCO DE DADOS
intuito de facilitar o acesso as mais variadas 
informações, minimizando os problemas 
do excesso de informações disponíveis. 
No entanto, ainda há muito aser feito 
nesse sentido.
 Outro foco, são os bancos de dados 
para dispositivos móveis, onde quase em 
oposição ao Big Data, tem-se diversas res-
trições, principalmente, em relação ao es-
paço para armazenamento de informações 
e custo de transmissão de dados. Assim, 
é necessário, ao mesmo tempo, otimizar 
as informações de maneira a ocuparem o 
menor espaço possível e manter a quali-
dade e relevância do que é apresentado.
A área de Banco de Dados ainda é 
fonte de muitas pesquisas, inovações sem-
pre são necessárias e, com certeza, todo 
profissional de informática precisa ter, no 
mínimo, noções sobre o armazenamento 
e recuperação de informações.
Amplie seus conhecimentos !
Pesquise para conhecer mais sobre 
a vida e o trabalho de Edgar Frank 
Codd e Peter Chen, personalidades 
que tanto contribuíram para o 
desenvolvimento da área de banco 
de dados.
FAZENDO UM AUTOESTUDO!
1. Qual a importância da informação em nossa sociedade?
2. Quais são os problemas dos arquivos convencionais?
3. O que são SGBDs?
4. Quando começaram as ser desenvolvidos os SGBDs?
5. Qual a importância de E.F. Codd para a área de 
Banco de Dados?
6. Quem definiu o Modelo Entidade-Relacionamento?
7. Qual a importância do Modelo ER?
8. Quais desafios os Sistemas Gerenciadores de 
Banco de Dados Relacionais enfrentaram desde 
o seu surgimento até a sua estabilização?
9. Enumere algumas aplicações que utilizam Sistemas 
de Banco de Dados?
10. O que é o Big Data e quais seus desafios?
18PROJETO DE BANCO DE DADOS
FUNDAMENTOS 
E CONCEITOS 
DE BANCO DE 
DADOS
Para conversamos com alguém precisamos 
conhecer seu idioma e gírias!
Para trabalhar com Banco de Dados 
precisamos conhecer seu vocabulário!
Agora, vamos conhecer alguns conceitos relacionados 
com a área de Banco de Dados, pois estes são importantes 
para que entendamos os principais elementos relacionados 
com o seu uso.
19PROJETO DE BANCO DE DADOS
A EVOLUÇÃO DO DADO
É possível definir o Banco de Dados 
como um conjunto de dados relaciona-
dos, que possibilitam a identificação de 
informações. Dessa forma, precisamos 
entender, e diferenciar, o que são dados, 
informações, o que podem ser e transfor-
mar no que é conhecimento.
Dados são registros numéricos ou 
textuais, de operações, ocorrências, situ-
ações, características, ou ainda, resultados 
obtidos, que isolados e sem contexto, po-
dem não ter significado próprio. Assim, 
dados podem ser definidos como fatos em 
sua forma primária, como observamos no 
mundo. Por exemplo, considere o dado 10, 
podemos dizer que é um número inteiro, 
mas o que significa? Qual informação 
representa? É uma nota? Nota 10. É um 
dia? Dia 10. É um mês? Mês de outubro. 
É uma duração de tempo? 10 minutos ou 
10 horas. Quando os dados são colocados 
em um contexto e são interligados passam 
a ter significado.
Assim, informação é uma mensagem 
significativa e contextualizada, resultado 
da análise realizada sobre os dados. Pode-
mos dizer que informação é o significado 
que as pessoas associam aos dados através 
de convenções usadas em sua interpreta-
ção. Dessa maneira, quando os dados são 
organizados em conjunto, acrescenta-se a 
eles valor, tornam-se úteis, então se tor-
nam informação. Assim, quando o dado 
10 é vinculado a temperatura, associado 
ao dia e hora em que foi observada, tor-
na-se uma informação, principalmente se 
vinculado a um conjunto de temperaturas, 
por exemplo, coletadas ao longo de um 
período de tempo. 
 Chegamos ao topo da pirâmide, 
onde o conhecimento irá refletir os estados 
mentais que estão em constante transfor-
mação, representando a experiência. Na 
produção do conhecimento as informações 
são selecionadas, organizadas, sintetizadas, 
relacionadas com outras e mobilizadas para 
realização de algo prático e possibilitam 
a tomada de decisões ou a realização de 
alguma tarefa específica. 
O conhecimento é, portanto, a in-
formação em movimento. Por exemplo, 
quando se tem a informação que está 10°, 
sabe-se que está frio e toma-se a decisão de 
fechar as janelas, colocar roupas quentes, 
etc. Para informação se transformar em 
conhecimento ela precisa ser compreen-
dida, seu conteúdo deve ser reconhecido 
e fazer parte da memória e experiência de 
um indivíduo, e assim possa ser utilizado 
para orientar as ações.
20PROJETO DE BANCO DE DADOS
SISTEMA DE GERÊNCIA DE 
BANCO DE DADOS
Os SGBD (Sistemas de Gerência de 
Banco de Dados ou Sistemas de Gerencia-
mento de Banco de Dados) possibilitam 
a definição, construção e manipulação 
de bancos de dados para as mais diversas 
aplicações.
Vamos entender melhor o que isso 
significa:
• Definição do Banco de Dados: é a 
descrição das estruturas que serão 
armazenadas no banco de dados, 
engloba a modelagem conceitual e 
especificação física dos dados e suas 
relações.
• Construção do Banco de Dados: é 
o processo de criação das estruturas 
físicas e configurações do Banco de 
Dados.
• Manipulação do Banco de Dados: 
são os processos de armazenamen-
to de dados (inclusão, alteração e 
exclusão de dados) e execução de 
consultas e relatórios.
Vamos aprender a definir Banco de 
Dados!!
Há várias formas de definir o que é 
um banco de dados: conjunto de arquivos 
relacionados, coleção de dados operacio-
nais armazenados e usados por sistemas, 
coleção de dados relacionais. Enfim, um 
banco de dados é uma estrutura armazena-
da em um dispositivo físico composta por 
dados relacionados e que são gerenciados 
por um sistema de gerência de banco de 
dados. 
Dessa forma, o SGBD constitui-se 
em um conjunto de softwares especializa-
dos com funções específicas, interligados 
com os programas de aplicações e com o 
banco de dados. Vamos conhecer alguns 
destes softwares que fazem parte de um 
SGBD ou trabalham em conjunto com ele:
Programas de Aplicação: são pro-
gramas desenvolvidos para as organiza-
ções e usuários com os mais diversos fins: 
gestão empresarial, cálculos de impostos, 
gestão de estoques, cálculos de custos, 
catalogação de livros, etc. 
Gerenciador de Arquivos: software 
especializado em fazer a gestão dos arqui-
21PROJETO DE BANCO DE DADOS
vos gerenciados pelo SGBD, que englobam 
arquivos de dados, arquivos de índices, 
arquivos de dicionários de dados, arquivos 
de recuperação, arquivos de usuários, etc. 
Suas principais funções são: alocar espaço 
nos dispositivos de armazenamento, criar 
e gerenciar estruturas de indexação, criar 
e gerenciar estruturas de recuperação em 
caso de falhas, criar e gerenciar estruturas 
de memória para otimizar o acesso aos 
registros dos arquivos. É um dos mais 
importantes módulos de um SGBD e deve 
funcionar de forma autônoma em relação 
aos outros módulos, pois isso permite que 
seja atualizado de forma independente, 
visando a otimização de seus processos 
ou adequação a atualizações dos sistemas 
operacionais.
Gerenciador de Banco de Dados: 
fornece uma interface para o administrador 
do banco de dados (DBA1 ) para acessar o 
gerenciador de arquivos, os aplicativos de 
definição de dados e de consulta.
Interpretador DDL: o processa-
dor de expressões DDL (Data Definition 
1 DBA: DataBase Administrator
Language) é parte da SQL e constitui-se em uma linguagem de definição de dados, 
que é utilizada para criação de estruturas (tabelas, objetos, funções, etc.) no banco 
de dados.
Dicionário de Dados: é o componente responsável pelos metadados do banco de 
dados. Os metadados são uma estrutura que possui as informações sobre a estrutura 
do banco de dados. Metadados são dados que tem as explicações dos dados que serão 
armazenados no banco de dados. Assim os metadados tornam possível transformar 
os dados em informações.
Processador e Otimizador de Consultas: responsável por analisar comandos 
de consultas SQL e transformá-las em um plano de execução otimizado, para a efi-
ciente recuperação de dados.
Pré-compilador DML e Compilador DML: converte comandos DML (Da-
taManipulation Language) em instruções para manipulação dos dados. A DML 
é parte da linguagemSQL e constitui-se por comandos de manipulação de dados 
(inclusão, alteração e exclusão). 
Gerenciador de Transações: 
inclui os módulos de controle de con-
corrência e subsistema de recuperação, 
responsáveis pela correta execução das 
transações.
A figura a seguir demonstra a 
relação entre esses e alguns outros ele-
mentos de um SGBD:
22PROJETO DE BANCO DE DADOS
POR QUE USAR SGBD?
Os SGBDs proporcionam às orga-
nizações o controle centralizado de seus 
dados e isto apresenta diversos benefícios:
• Separação entre o Banco de Dados 
e Programas: um dos principais be-
nefícios dos SGBDs é oferecer uma 
solução de gerenciamento de dados 
que possui uma separação entre o 
armazenamento dos dados e os pro-
gramas que gerenciam e manipulam.
• Redução da Redundância e Evi-
tar a Inconsistência: ao definir um 
banco de dados é criada uma estru-
tura integrada e esta é mapeada nos 
metadados, que ficam no dicionário 
de dados. Assim, evita-se a repeti-
ção da mesma informação em mais 
de um lugar do sistema, evitando a 
redundância e mesmo, que ela ne-
cessariamente precise ocorrer, por 
condições especificadas da aplica-
ção, será claramente identificada e 
poderá ser evitado o grave problema 
da inconsistência de dados2 .
• Compartilhamento dos Dados: os 
dados armazenados nos Bancos de 
Dados gerenciados pelos SGBD Re-
lacionais são manipulados através da 
linguagem SQL. Assim, é simples 
construir aplicações para acesso aos 
dados de qualquer SGBD e inclusive 
integrando informações de mais de 
um Banco de Dados.
• Padronização e Portabilidade: para 
serem armazenados no SGBD os 
dados devem ser organizados e se-
guem um padrão de modelagem e 
especificação, esse padrão é compar-
tilhado pelos diversos fabricantes de 
SGBD Relacionais. Dessa forma, as 
bases de dados podem ser facilmente 
portadas de um SGBD para outro. 
Essa portabilidade não é absoluta, 
exige algum esforço, mas é possível.
2 Lembres que a Inconsistência de Dados refere-se a mesma 
informação registrada em mais de um lugar no sistema e em cada lugar 
com valores diferentes, impedindo que se saiba qual o correto, portanto 
são valores inconsistentes.
• Restrições de Segurança: os con-
troles de acesso e operações válidas 
para cada usuário são definidas pelo 
administrador do banco de dados 
(DBA) e garantidas pelo SGBD, 
isso permite que os programadores 
de aplicações não precisam ter essa 
preocupação em cada programa de-
senvolvido.
• Gestão das Transações (Atomici-
dade das Transações e Controle da 
Concorrência): as transações (con-
juntos de comandos que realizam 
um processo consistente em relação 
a aplicação) devem ser consideradas 
como unidades atômicas e que não 
devem usar dados que estão sendo 
manipulados por outras transações. 
Os SGBD possuem controle próprio 
para que cada transação seja executa 
inteiramente (todos os seus coman-
dos), garantindo que caso ocorram 
falhas no meio do processo, as ações 
já realizadas sejam desfeitas. Por ou-
tro lado, quando transações estão 
manipulando determinados dados 
estes se tornam automaticamente 
23PROJETO DE BANCO DE DADOS
inacessíveis para outras transações, 
garantindo a correta execução con-
corrente das transações, mantendo 
a integridade dos dados do banco 
de dados.
• Tolerância a Falhas: o SGBD for-
nece recursos que possibilitam a re-
cuperação em caso de falhas. Que 
falhas podem ocorrer? Faltar luz 
durante a execução de uma transa-
ção, neste caso quando a luz voltar 
o sistema deve saber onde parou e 
desfazer/refazer atividades para ga-
rantir a correção do banco de dados. 
Outra falha, pode ser um problema 
no dispositivo de armazenamento, 
assim o SGBD deve ser configura-
do, trabalhar com o espalhamento e 
permitir a continuidade do trabalho 
a partir desta base de dados. 
• Abstração de Dados: o SGBD for-
nece aos usuários uma visão abstrata 
dos dados, ou seja, dependendo da 
necessidade, cada tipo de usuário 
terá acesso as informações que pre-
cisa, sem ser necessário compreender 
toda a estrutura do SGBD para utilizá-lo. Assim, por exemplo, um progra-
mador de uma aplicação que consulta apenas o nome e o endereço de pessoas 
armazenadas no Banco de Dados, precisa apenas conhecer essas informações e 
não precisa saber outros detalhes do esquema de dados e nem precisa saber as 
configurações físicas do SGBD. Esta é uma das grandes vantagens dos SGBD.
ARQUITETURA DO SGBD
A arquitetura do SGBD é dividida em três níveis que proveem diferentes visões 
da estrutura do sistema de banco de dados, ela é conhecida como arquitetura ANSI/
SPARC3 . Esta organização em níveis, efetiva a visão abstrata dos dados, reduzindo 
a complexidade do sistema conforme o nível em que o usuário trabalha. Os níveis da 
arquitetura do SGBD são: nível interno ou físico; nível conceitual ou lógico; e nível 
externo ou de visão. 
Através dessa arquitetura em níveis, cada usuário terá percepções diferentes e 
independentes do sistema, mesmo acessando os mesmos dados, pois a visão é per-
sonalizada. Essas visões possibilitam que determinadas alterações em um nível não 
afetem os outros níveis. O Administrador do Banco de Dados trabalha e conhece 
todos os níveis, mas os outros usuários não precisam ter esse amplo conhecimento. 
A figura, a seguir, apresenta a relação entre os níveis.
3 American National Standards Institute, Standards Planning And Requirements Committee 
24PROJETO DE BANCO DE DADOS
• NÍVEL INTERNO: O nível in-
terno também é denominado nível 
físico, pois relaciona-se com as es-
truturas física de armazenamento 
dos dados e com o gerenciamento 
dessas. Nesse nível, são realizadas 
definições de localização dos arqui-
vos físicos, blocos de leitura/escrita, 
tamanho e quantidade de arquivos 
de log, tamanho e quantidade de 
arquivos de recuperação, estruturas 
e métodos de indexação e ordenação 
de dados, configurações de segu-
rança e protocolos de acesso, além 
de outras configurações específicas 
de cada SGBD. Nesse nível traba-
lham o Administrador de Redes de 
Computadores em conjunto com o 
Administrador de Banco de Dados. 
• NÍVEL CONCEITUAL: O ní-
vel conceitual é também conhecido 
como nível lógico. Nesse nível é des-
crita a estrutura conceitual completa 
do banco de dados, tal que engloba 
a definição do esquema do banco de 
dados (que é construído utilizando-
-se dos modelos de dados), a defi-
nição das restrições de integridade4, 
4 Restrições de Integridade: são regras que devem ser seguidas 
para garantir a correção das informações.
a definição das restrições de acesso, 
enfim toda a especificação concei-
tual das informações que o sistema 
de banco de dados deve gerenciar. 
Assim é especificado o dicionário 
de dados5 do banco de dados. Nesse 
nível trabalha o Administrador de 
Banco de Dados sob as orientações 
dos analistas e projetistas de siste-
mas.
• NÍVEL EXTERNO: O nível ex-
terno é o mais próximo dos usuários 
finais e também recebe o nome de 
nível de visão, pois especifica visões 
parciais dos dados conforme as ne-
cessidades de cada usuário ou aplica-
ção. Assim, são definidos esquemas 
externos que são visões do esquema 
conceitual global, permitindo uma 
redução da complexidade e simpli-
ficando o acesso às informações, 
5 Um dicionário de dados é uma coleção de metadados (informa-
ções sobre os dados) que contêm definições e representações de elementos 
de dados. Dentro do contexto de sistemas gerenciadores de bancos de dados, 
um dicionário de dados é um grupo de tabelas, habilitadas apenas para 
leitura ou consulta, ou seja, é uma base de dados, propriamente dita, que 
entre outras coisas, mantém as seguintes informações: Definição precisa 
sobre elementos de dados; Perfis de usuários, papéis e privilégios; Descrição 
de objetos; Integridade de restrições; procedimentos e funções; Estrutura 
geral da base de dados; Informações de verificação; Alocações de espaço.
25PROJETO DE BANCO DE DADOS
direcionando-as apenas para quem 
as precisa. Nesse nível trabalham os 
programadores de aplicações queas 
desenvolvem para os usuários finais.
Por meio desta arquitetura é possí-
vel cumprir duas importantes regras dos 
SGBD, as quais são garantir a abstração 
de dados e a independência de dados.
• ABSTR AÇÃO DE DADOS: 
Cada usuário, dependendo de suas 
funções no sistema de banco de da-
dos, precisará conhecer e trabalhar 
com as informações que são perti-
nentes a sua atividade, trabalhando 
em um nível de abstração.
• INDEPENDÊNCIA DE DA-
DOS: Refere-se à capacidade do 
SGBD de permitir que sejam rea-
lizadas alterações em determinado 
nível da abstração, sem que essa 
tenha impacto nos outros níveis. A 
independência de dados divide-se 
em dois tipos:
• INDEPENDÊNCIA DE DA-
DOS FÍSICA: refere-se a con-
dição do SGBD que permite que 
sejam realizadas alterações no ní-
vel interno (físico) sem que estas 
gerem alterações nos outros níveis 
(conceitual e externo). Assim, é 
possível atualizar o sistema que 
faz o gerenciamento dos arquivos, 
reorganizar a estrutura de arma-
zenamento, redefinir arquivos de 
recuperação e de log, entre outras 
configurações físicas e isso não 
deve provocar alterações, nem no 
esquema conceitual e nem nas vi-
sões. Essa independência é obri-
gatória, ou seja, todo o SGBD 
deve cumprir essa regra.
• INDEPENDÊNCIA DE DA-
DOS LÓGICA: refere-se a ha-
bilidade do SGBD possibilitar 
que sejam realizadas alterações 
no nível conceitual (lógico) e essas 
não devem provocar alterações no 
nível externo (visões). Assim, é 
possível fazer complementações 
no esquema conceitual (adicionar 
um novo campo em uma tabela, 
26PROJETO DE BANCO DE DADOS
por exemplo), definição de novas 
regras de integridade e acesso, e 
isso não implicará em alterações 
nos programas de aplicações e vi-
sões já desenvolvidas, com exceção 
daqueles que sejam diretamente 
afetados pela alteração realizada. 
Essa independência tem peso de 
uma obrigatoriedade parcial, ou 
seja, os SGBD devem cumprir 
essa regra, mas visto que algumas 
aplicações/visões serão afetadas 
pela alteração, considera-se que a 
regra de independência de dados 
lógica é parcialmente cumprida.
Assim, percebe-se que é importante 
entender quais são os principais tipos de 
usuários que utilizam (trabalham com) os 
Sistemas de Banco de Dados e seus papéis/
responsabilidades neste contexto:
• Usuários Finais: são pessoas que 
utilizam programas de aplicação, 
especificamente, construídos com 
alguma finalidade (administrativa, 
científica, etc.). Esses usuários não 
precisam ter conhecimentos sobre 
SGBD para utilizá-los, apenas usam 
as aplicações que lhes fornecem uma 
visão abstrata dos dados que contêm 
apenas as informações que precisam 
para realização de seu trabalho.
• Desenvolvedores de Aplicações: 
são profissionais da área de infor-
mática que desenvolvem aplicações, 
para isso precisam conhecer parte 
do esquema conceitual do banco de 
dados, necessários para o desenvol-
vimento das aplicações e precisam 
interagir com o Administrador do 
Banco de Dados para permissões.
• Analistas e Projetistas de Siste-
mas: são profissionais da área de 
informática que analisam e proje-
tam aplicações, definindo o esquema 
conceitual do banco de dados e suas 
restrições de integridade e acesso, 
estes são passados ao Administrador 
do Banco de Dados para que faça 
as integrações e configurações no 
nível conceitual do SGBD.
• Administrador de Redes de Com-
putadores: profissional da área de 
informática, responsável pela insta-
lação, configuração e gerenciamento 
das redes de computadores e siste-
mas nela instalados. Logo, o SGBD 
é um desses sistemas e portanto é o 
Administrador de Rede junto com o 
Administrador de Banco de Dados, 
o qual faz as configurações no nível 
interno (físico) do SGBD, além de 
monitorar questões de performance 
e realizar procedimentos de segu-
rança.
• Administrador do Banco de Dados 
(DBA – Database Administrator): 
profissional da área de informáti-
ca responsável pelo gerenciamento 
dos Sistemas de Banco de Dados e 
engloba as seguintes funções: par-
ticipar da instalação e configura-
ção do SGBD e Bancos de Dados; 
participar da definição do esquema 
conceitual; criar e gerenciar o esque-
ma conceitual no Banco de Dados, 
realizando integração de novas es-
truturas quando necessário; criar as 
restrições de integridade e restrições 
27PROJETO DE BANCO DE DADOS
de acesso, gerenciando-as; definir e 
gerenciar as possíveis visões e seus 
modos de acesso; conceder acesso 
aos Bancos de Dados; monitorar a 
performance do SGBD e das aplica-
ções que usam os Banco de Dados, 
de maneira, a perceber problemas e 
realizar ou solicitar os ajustes neces-
sários. Enfim, o DBA é uma peça 
central em um ambiente que utilize 
SGBDs.
LINGUAGEM PADRÃO DOS 
SGBD
Para trabalhar com os SGBDs 
disponíveis, atualmente, tem-se diversas 
interfaces gráficas, mas para o desenvol-
vimento de aplicações é ainda necessário 
conhecer a linguagem que permita criar 
e administrar o esquema do banco de da-
dos. Além disso, criar e administrar todo 
tipo de estruturas, criar e administrar as 
restrições de integridade, configurar e ge-
renciar o acesso, criar e gerenciar funções e 
trabalhar com a base de dados, realizando 
as operações de inclusão, alteração e exclu-
são de dados, além do objetivo principal 
de uma banco de dados, que é recuperar 
as informações, o que se expressa através 
de consultas. 
A linguagem padrão para trabalhar 
com os Sistemas Gerenciadores de Banco 
de Dados Relacionais é a SQL (Structured 
Query Language – Linguagem de Con-
sulta Estruturada). A SQL se originou do 
trabalho de E.F. Codd que desenvolveu na 
IBM a linguagem SEQUEL (Strutucred 
English Query Language - Linguagem 
de Consulta em Inglês Estruturado). Os 
fornecedores de banco de dados relacio-
nais buscaram um método padronizado 
para gerenciar os dados dos bancos de 
dados relacionais, assim a linguagem SQL 
tornou-se popular e foi padronizada pelo 
ANSI (American National Standards Ins-
titute) que lançou os padrões para SQL 
em 1986, 1989, 1992, 1999, 2003 e 2006. 
Cada um agregando novos elementos que 
foram tornando a linguagem mais po-
derosa e, atualmente, atende ao padrão 
objeto-relacional, gerencia dados multimí-
dia e hipermídia e incorpora recursos de 
inteligência artificial para gestão de bases 
de conhecimento, mineração de dados e 
outros tipos de análises. Embora padro-
nizado pela ANSI e ISO, a SQL possui 
muitas variações e extensões produzidas 
pelos fabricantes de SGBDs, mesmo assim 
mantém diversas estruturas comuns, o que 
permite que seja migrada de uma plata-
forma para outra sem grandes mudanças 
estruturais.
O conjunto de comandos da lingua-
gem SQL pode ser agrupado conforme 
a função que possui e assim se define a 
estrutura básica dessa linguagem:
Linguagem de Definição de Da-
dos (DDL – Data Definition Language): 
Subconjunto de comandos para criação, 
alteração e remoção de estruturas no Ban-
co de Dados, principalmente a estrutura 
base desse, que são as tabelas. Assim a 
DDL possui comandos para criar, alterar 
e remover tabelas (CREATE TABLE, 
ALTER TABLE E DROP TABLE). Os 
comandos DDL são diretamente efetiva-
dos no Banco de Dados, não podem ser 
desfeitos, apenas podem ser compensados 
pela execução de comando inverso. 
28PROJETO DE BANCO DE DADOS
Linguagem de Manipulação de 
Dados (DML – Data Manipulation Lan-
guage): Subconjunto de comandos para in-
serir, remover e modificar informações em 
um esquema de banco de dados (INSERT, 
UPDATE E DELETE). Os comandos 
DML não são diretamente efetivados no 
Banco de Dados, pois dependem da con-
clusão com sucesso da transação em que 
estão, assim podem ser desfeitos.
Linguagem de Consulta de Dados 
(DQL – Data Query Language) – é a parte 
da SQL que é mais utilizada e embora 
seja formada por apenas um comando 
(SELECT) e um dos mais importantes, 
permite a extração de dados/informações 
do Banco de Dados. 
Linguagem de Controle de Da-
dos (DCL – Data Control Language): 
Subconjunto de comandos para controlar 
as autorizaçõesde acesso e manipulação 
das estruturas do SGBD. Isso é realizado 
por comando que concedem ou revogam 
as permissões (GRANT E REVOKE).
Linguagem de Transação de Da-
dos (DTL – Data Transaction Language): 
Subconjunto de comandos que possibili-
tam o controle de transações e engloba 
os seguintes comandos: BEGIN TRAN-
SACTION, que define o início de uma 
transação; COMMIT, que finaliza uma 
transação com sucesso e efetiva todas as 
operações realizadas no Banco de Dados; e 
ROLLBACK, que interrompe uma tran-
sação e desfaz todas as operações realizadas 
desde o início da transação.
MODELAGEM DE DADOS
Saiba que a Modelagem de Dados é 
uma etapa essencial do desenvolvimento 
de um sistema!
Modelar é um processo que utiliza 
um modelo de dados para construir um 
esquema que explicita as características de 
informações, funcionamento e compor-
tamento de uma realidade para a cons-
trução de um software. Nesse sentido, 
o esquema de dados é uma abstração da 
realidade que especifica as propriedades 
dos dados, informações e restrições que 
serão utilizados para construção da base 
de dados do sistema.
Por que é importante MODE-
LAR? 
A modelagem é uma etapa que faz 
parte do processo de análise de um sis-
tema, de forma que quando é realizada a 
interação com os usuários, para compreen-
der adequadamente suas necessidades; as 
informações das quais precisa; as relações 
entre as informações; as transformações 
que as informações podem sofrer; as regras 
de funcionamento das atividades que o 
usuário realiza; os controles que precisam 
ser feitos; os resultados esperados; a forma 
de apresentação das informações; as aná-
lises de dados que devem ser realizadas; 
quais os tipos de usuários que devem ter 
acesso às informações; as restrições de 
acesso a essas informações; enfim entender 
todo o contexto para o qual a aplicação 
será desenvolvida. 
A partir dessa compreensão é pos-
sível construir o esquema de dados e fa-
zer toda a especificação do sistema, que 
29PROJETO DE BANCO DE DADOS
depois passará para etapas de projeto e 
desenvolvimento (programação). Quando 
a análise e a modelagem de dados não são 
feitas, ou quando ocorrem falhas nesta 
etapa diversos problemas podem ocorrer:
• O sistema desenvolvido pode não 
atender às necessidades dos usuários;
• O sistema desenvolvido pode ter 
erros em relação aos requisitos;
• A base de dados pode não conter 
todas as informações que os usuários 
precisam;
• A base de dados pode ter relaciona-
mentos incorretos entre os dados, ou 
falta de relações adequadas;
• A base de dados pode ter regras de 
integridade incorretas ou inadequa-
das para o contexto da aplicação;
• A base de dados pode não ter a f le-
xibilidade adequada para a evolução 
do sistema desenvolvido;
• A manutenção do sistema será di-
fícil.
Para realizar a modelagem de dados 
é necessário utilizar modelos de dados!
MODELOS DE DADOS
O que são modelos de dados??
Os modelos de dados são ferramen-
tas conceituais que possuem um conjunto 
de estruturas para especificação de ele-
mentos de uma realidade, suas relações 
e suas restrições que permitem construir 
esquemas de dados.
Ferramentas conceituais são recursos 
textuais ou gráficos, que através de regras 
orientam o trabalho do analista para a 
construção dos esquemas. Assim, para 
compreender um modelo de dados é ne-
cessário compreender as suas ferramentas 
conceituais e regras. 
Os modelos de dados podem ser 
classificados em:
• Modelos conceituais: que permi-
tem a especificação de alto nível 
do banco de dados, mais próxima 
do usuário e independe do tipo 
de SGBD que será utilizado. Os 
principais modelos conceituais são: 
modelo entidade-relacionamento; e 
modelo de classes (orientado a ob-
jetos).
• Modelos lógicos: dependem da 
classe de SGBD que será utilizado, 
mas não de um SGBD específico. O 
modelo lógico é construído a partir 
do modelo conceitual. Os principais 
modelos lógicos são: modelo rela-
cional; modelo orientado a objetos; 
e modelo objeto-relacional.
• Modelos físicos: descrevem as es-
truturas e métodos de acesso de um 
SGBD específico e é construído a 
partir do modelo lógico. Relaciona-
do com a linguagem de programação 
do SGBD.
Para construção da base de dados é 
necessário seguir as seguinte etapas:
30PROJETO DE BANCO DE DADOS
1. Análise de Requisitos: quando se 
interage com os usuários e especi-
fica os requisitos do sistema. Isto 
é realizado através de entrevistas 
com os usuários, observação do seu 
trabalho e análise de documentos.
2. Projeto Conceitual: com base nos 
requisitos é construído o esquema 
conceitual do sistema e se utiliza 
para isso um modelo conceitual. 
Este esquema deve ser validado com 
o usuário, visando eliminar dúvidas 
e garantindo que atende as expecta-
tivas do sistema a ser desenvolvido.
3. Projeto Lógico: realizamos o ma-
peamento do esquema de dados 
conceitual para um esquema lógico, 
utilizando o modelo lógico da classe 
de banco de dados escolhido.
4. Projeto Físico: fazemos as espe-
cificações da base de dados para 
um SGBD específico, definindo a 
organização física dos dados que 
englobam estruturas, tipos e outros 
elementos, conforme o SGBD esco-
lhido e toma-se por base o esquema lógico construído na fase anterior.
A tabela a seguir resume, em forma de esquema, as etapas de construção de 
um banco de dados:
MUNDO REAL Requisitos da aplicação
Interação com os usuários
Compreensão da aplicação
MODELO 
CONCEITUAL 
(Modelo 
Abstrato dos 
Dados)
Independente do SGBD 
(Especificação mais 
próxima dos usuários)
MODELO 
LÓGICO
 (Estrutura dos 
Dados)
Dependente do tipo de 
SGBD mas não de um 
SGBD específico
Derivado do Esquema 
Conceitual
Modelo 
Relacional
Modelo 
Orientado a 
Objetos
Modelo Objeto 
Relacional
MODELO 
FÍSICO
(Organização 
Física dos 
Dados)
Derivado do Esquema 
Lógico 
Dependente do SGBD 
escolhido
- Estruturas de armazenamento de dados
- Índices de acesso
- Restrições de integridade e segurança
31PROJETO DE BANCO DE DADOS
Assim, podemos considerar um 
exemplo de uso bastante comum destas 
etapas:
1. Análise de Requisitos: etapa de en-
trevistas e interação com o usuário, 
análise dos processos que o usuário 
realiza e estudo de documentos/re-
latórios, visando a compreensão do 
sistema a ser desenvolvido e gerando 
a especificação dos requisitos.
2. Projeto Conceitual: utilização do 
Modelo Entidade-Relacionamento 
para a construção do esquema de 
dados conceitual. 
3. Projeto Lógico: realiza-se o mape-
amento do esquema de dados con-
ceitual para um esquema de dados 
relacional, utilizando o modelo re-
lacional, que é a classe de banco de 
dados escolhido.
4. Projeto Físico: realiza-se o mape-
amento do esquema de dados re-
lacional para os comandos SQL 
para criar a base de dados, tabelas, 
restrições de integridade e acesso 
no SGBD Oracle (um SGBD es-
pecífico).
Dessa forma, para o uso regular des-
se processo precisamos estudar o Modelo 
Entidade-Relacionamento e o Modelo 
Relacional. 
Ampliando nosso conhecimento!
Pesquise sobre alguns dos SGBDs 
utilizados comercialmente nos dias de hoje.
FAZENDO UM AUTOESTUDO!
1. Conceitue e diferencie dado, informação e conhecimento.
2. Sistemas de Gerência de Banco de dados possibilitam 
a definição, construção e manipulação de bancos 
de dados. Explique o que esses sistemas realizam?
3. O que é um banco de dados?
4. Quais são os principais softwares que devem fazer 
parte de um SGBD?
5. Explique os benefícios que se obtém ao utilizar 
SGBDs?
6. Explique como é a arquitetura dos SGBD co-
nhecida como ANSI/SPARC?
7. Explique o que é abstração de dados?Explique o 
que é independência de dados, independência de 
dados física e independência de dados lógica?
8. Descreva os principais tipos de usuários que uti-
lizam SGBDs?
9. O que é a linguagem SQL? E qual o significado 
das siglas DDL e DML?
10. Por que é importante fazer a modelagem dos dados?
11. Quais informações são coletas dos usuários durante 
a etapa de modelagem?
12. O queé um esquema de dados?
13. Quais são as etapas para a construção de uma 
base de dados?
14. Quais os principais modelos utilizados para 
fazer o projeto de uma base de dados?
34PROJETO DE BANCO DE DADOS
MODELO 
ENTIDADE-
RELACIONAMENTO
Você deve estar se perguntando: 
Como construir um modelo conceitual?
O Modelo Entidade-Relacionamento é uma ferramenta 
conceitual que permite construir uma abstração do mundo 
real através de um esquema de dados conceitual, denomi-
nado diagrama entidade-relacionamento (DER), com as 
estruturas fundamentais para construção do banco de dados. 
Esse modelo possibilita que informações semânticas sejam 
modeladas através de uma técnica diagramática (representação 
gráfica). Foi construído com o intuito de ser simples e de que 
os diagramas pudessem ser compreendidos pelos usuários, 
para que pudessem participar de sua construção e validação.
Peter Pin-Shan Chen, em 1976, publicou na ACM 
Transactions on Database Systems o artigo “The Entity-Re-
lationship Model--Toward a Unified View of Data”1 , no qual 
1 Chen,P.S. “The Entity-Relationship Model--Toward a Unified View of Data”, ACM Transactions 
on Database System, Volume 1 Número 1, 1976. (http://bit.csc.lsu.edu/~chen/pdf/erd-5-pages.pdf )
35PROJETO DE BANCO DE DADOS
CONCEITOS CENTRAIS DO MODELO ER
Para construção de diagramas entidade-relacionamento (DER) é necessário 
conhecer as suas ferramentas conceituais que são os conceitos centrais do Modelo ER:
• Entidades
• Relacionamentos
• Atributos
• Cardinalidade
• Generalização/Especialização
ENTIDADES
As entidades representam coleções de objetos (concretos ou abstratos) da reali-
dade modelada, que são úteis e relevantes para o sistema a ser desenvolvido, possuem 
propriedades através das quais são descritas e permitem que seus exemplos (ocorrên-
cias) sejam diferenciados e identificados. 
A representação gráfica de entidades é feita através de um retângulo e o nome 
da entidade é colocado dentro deste. Normalmente se utiliza um substantivo no 
singular para nomear a entidade. 
apresenta as bases desse modelo conceitual, 
independente de um Sistema Gerenciador 
de Banco de Dados, e descreve as fer-
ramentas conceituais do modelo que se 
constituem de entidades, objetos concretos 
ou abstratos da realidade considerada, e de 
relacionamentos que se estabelecem entre 
elas. Dessa estrutura deriva a denomina-
ção do modelo: entidade-relacionamento 
(Entity-Relationship Model). Atualmen-
te, o Modelo ER ainda é a técnica mais 
difundida e utilizada na etapa de projeto 
conceitual.
Esse modelo é uma orientação siste-
mática, utilizada para descrever e definir 
um processo de negócio com ênfase nas 
suas informações. O foco da modelagem 
são os componentes (entidades), que pos-
suem ligações explicitadas por relaciona-
mentos, que expressam as dependências 
e exigências entre elas. Assim, através da 
utilização desse modelo é possível deter-
minar os recursos de dados fundamentais 
para uma organização, catalogando-os em 
termos de entidades e relacionamentos.
36PROJETO DE BANCO DE DADOS
Vejas a seguir alguns exemplos de entidades:
CONCRETAS
ABSTRATAS
PESSOA CARRO LIVRO
MATRÍCULA CURSO PROJETO
ENTIDADE
Uma habilidade importante para 
modelagem de dados é saber identificar 
as entidades dentro do contexto de uma 
aplicação/sistema! 
Considere o contexto acadêmico, a 
seguir estão listadas as principais entidades 
que podem ser identificadas:
ALUNO CURSO
CURRÍCULO INSTITUIÇÃO DE 
ENSINO
MATRÍCULA TURMA
DISCIPLINA PRÉDIO
SALA PROFESSOR
37PROJETO DE BANCO DE DADOS
ATRIBUTOS
Os atributos são propriedades asso-
ciadas às entidades (ou aos relacionamen-
tos) usados para descreve-los, ou seja, são 
as informações relevantes no contexto da 
aplicação e que esta precisa ter. Pode-se, 
também, definir atributos como caracte-
rísticas que são usadas para descrever as 
ocorrências de uma entidade. 
Por exemplo, considere a entidade 
Pessoa que pode ter as seguintes proprie-
dades: nome, data de nascimento e email; 
assim, uma ocorrência da entidade Pessoa 
será descrita por essas propriedades: Nome 
= Fulano Apelido, Data de Nascimento 
= 01/01/1990, email = fulanoapelido@
gmail.com. 
A representação gráfica dos atri-
butos é feita com um segmento de reta, 
utilizando um pequeno círculo como ter-
minal, junto a esse se coloca o nome do 
atributo. 
Os atributos podem ser classificados 
em: atributos comuns, ou simplesmente 
atributos, e atributos identificadores. Os 
atributos identificadores são aqueles que 
permitem diferenciar uma ocorrência da 
entidade das outras ocorrências, ou seja, 
são um código único para cada ocorrência, 
cada valor deste atributo, somente pode es-
tar vinculado a uma única ocorrência. Por 
exemplo, uma pessoa pode ser identificada 
por seu CPF e não há duas pessoas com o 
mesmo CPF. Toda a entidade deve ter um 
atributo identificador. A grande maioria 
dos atributos são atributos comuns, ou seja, 
não tem a responsabilidade de identificar 
as ocorrências e podem ter seus valores 
repetidos em diferentes ocorrências da 
mesma entidade. Por exemplo, a data de 
nascimento, mais de uma pessoa pode ter 
nascido no mesmo dia e, portanto, terão 
o mesmo valor neste atributo.
Os atributos de uma entidade não 
são, necessariamente, constituídos por 
todas as características que objeto possui 
na realidade, mas sim, devem ser o sub-
conjunto dessas que são relevantes para 
o contexto da aplicação. Por exemplo, ao 
pensarmos na entidade Pessoa, se o sistema 
considerado for um sistema acadêmico, as 
informações relevantes podem ser nome, 
data de nascimento, CPF, email, telefo-
ne, por outro lado, se o contexto for um 
sistema de uma academia, poderíamos 
acrescentar peso e altura, mas se o con-
texto for um sistema de relacionamentos 
Atividade: Considere alguns contextos de 
sistemas e Enumere as principais entidades 
destes.
Sugestões de Contextos: gestão de DVDs, 
controle de gastos, controle de compras, 
etc.
MATRÍCULA
ATRIBUTO INDETIFICADOR
ATRIBUTO
38PROJETO DE BANCO DE DADOS
poderíamos acrescentar cor dos olhos e cor dos cabelos. A seguir, veja os diagramas 
ER da entidade Pessoa nestes diferentes contextos de sistemas:
Contexto de um Sistema Acadêmico
Contexto de um Sistema de uma 
Academia
Contexto de um Sistema de 
Relacionamentos
PESSOA
NOME
DATA DE NASCIMENTO
CPF
EMAIL
TELEFONE
PESSOA
NOME
TELEFONE
CPF
EMAIL
DATA DE NASCIMENTO
PESSOA
PESO
ALTURA
NOME
CPF
DATA DE NASCIMENTO
PESO
ALTURA
COR DOS OLHOS
COR DOS CABELOS
EMAIL
TELEFONE
Assim, os atributos (características) 
não são inerentes à entidade considerada, 
mas dependem da aplicação em que a en-
tidade está sendo modelada.
RELACIONAMENTOS
Os relacionamentos representam as 
associações que ocorrem entre as entida-
des da realidade considerada, ou seja, as 
relações que existem entre os objetos do 
mundo real. Por exemplo: pessoas fazem 
Atividade: Considere alguns contextos 
de sistemas e Defina os atributos das 
principais entidades.
Sugestões de Contextos: gestão de DVDs, 
controle de gastos, controle de compras, 
etc.
39PROJETO DE BANCO DE DADOS
cursos; cursos são formados por disci-
plinas; livros tem autores; pessoas prati-
cam esportes; produtos são constituídos 
de componentes; professores ministram 
disciplinas. Perceba que as associações são 
expressas por verbos que ligam as entida-
des e determinam o tipo de relação que 
há entre elas. 
A representação gráfica dos relacio-
namentos é feita com um losango ligado 
por segmentos de reta às entidades ligadas 
pelo relacionamento. Normalmente, uti-
liza-se um verbo no infinitivo para repre-
sentar a função do relacionamento. 
Vamos ver alguns exemplos de re-
lacionamentos entre entidades:
RELACIONAR
RELACIONARENTIDADE A ENTIDADE B
FAZERPESSOA CURSO
FORMARDISCIPLINA CURSO
Pessoas fazem cursos:
Cursos são formados por 
disciplinas:
TERLIVRO AUTOR
Livros tem autores:
PRATICARPESSOA ESPORTE
Pessoas praticam 
esportes:
COMPORPRODUTO COMPONENTEProdutos são compostos 
por componentes:
MINISTRARPROFESSOR DISCIPLINA
Professores ministram 
disciplinas:
40PROJETO DE BANCO DE DADOS
Logo, a partir da especificação do sistema, juntamente feita, com os usuários 
é possível identificar as entidades e as relações que existem entre elas, gerando um 
diagrama ER e validando com os usuários a correção dessas associações e inclusive 
verificar se todas foram mapeadas.
Os relacionamentos também podem ter atributos, que são informações que 
derivam da associação entre as entidades e que caracterizam o relacionamento. 
Considere que precisa ser construído um sistema para registrar as receitas de um 
chefe de cozinha. As principais entidades desse sistema são: Receita e Ingrediente, 
além disso quando um ingrediente é associado à receita em que é utilizado, também 
é necessário informar a quantidade necessária desse ingrediente, assim quantidade é 
um atributo do relacionamento entre Receita e Ingrediente:
Os relacionamentos também podem ter atributos identificadores que permitem 
diferenciar uma ocorrência do relacionamento das outras ocorrências. 
Vamos analisar um exemplo para entender essa situação. Considere que em um 
sistema administrativo deseja-se registrar os administradores das empresas, mantendo 
o histórico de todos os administradores e sabendo que a mesma pessoa pode admi-
nistrar a empresa mais de uma vez em diferentes mandatos. Como resultado desta 
especificação, foi construído o seguinte diagrama ER:
UTILIZARRECEITA INGREDIENTE
QUANTIDADE
41PROJETO DE BANCO DE DADOS
ADMINISTRARPESSOA EMPRESA
DATA INÍCIO MANDATO
DATA FIM MANDATO
CÓDIGO EMPRESA
RAZÃO SOCIAL
CÓDIGO PESSOA
NOME
Nesse diagrama apenas foram especificados os atributos essenciais para a 
compreensão do exemplo. Para um melhor entendimento, vamos verificar alguns 
exemplos de ocorrências das entidades e dos relacionamentos.
As tabelas a seguir apresentam alguns exemplos (ocorrências) fictícios para 
as entidades, Pessoa e Empresa. Perceba que os atributos identificadores Código 
Pessoa e Código Empresa são informações que não podem ter ser valores repetidos 
em ocorrências diferentes.
CÓDIGO 
PESSOA NOME
1 RUY BARBOSA
2 FERREIRA GOULART
3 MACHADO DE ASSIS
CÓDIGO 
EMPRESA RAZÃO SOCIAL
100 LITERATURA S.A.
200 HISTÓRIA LTDA
300 EMPREENDIMENTOS
Agora, vamos demonstrar como 
ficam as ocorrências do relacionamento 
Administrar. Para especificar essas ocor-
rências precisamos utilizar os atributos 
identificadores de cada uma das entida-
des que participam do relacionamento e, 
além disso, adicionamos os atributos do 
relacionamento.
Toda ocorrência de relacionamento é 
identificada pela composição dos atributos 
identificadores das entidades relaciona-
das. Nesse caso, código pessoa e código 
empresa, não se pode ter nessa situação 
CÓDIGO 
PESSOA
CÓDIGO 
EMPRESA
DATA 
INÍCIO 
MANDATO
DATA FIM 
MANDATO
1 100 30/03/2010 29/03/2012
2 100 30/03/2012 29/03/2014
3 200 01/04/2013 31/03/2015
3 200 01/04/2015 31/03/2017
42PROJETO DE BANCO DE DADOS
convencional mais de um relacionamento 
entre as mesmas entidades. Perceba no 
exemplo, que a mesma pessoa (código pes-
soa = 3) está relacionada duas vezes com a 
mesma empresa (código empresa = 200), 
logo em um relacionamento simples isso 
não seria possível! Porém, ao adicionar no 
relacionamento o atributo identificador 
Data Início Mandato, o relacionamento 
passa a ser identificado pela composição 
dos três campos (Código Pessoa + Código 
Empresa + Data Início Mandato) e assim, 
permite que a mesma pessoa administre 
a mesma empresa mais de uma vez, des-
de que a data de início do mandato seja 
diferente.
CARDINALIDADES
As cardinalidades especificam a forma como as ocorrências das entidades se 
relacionam com as ocorrências das outras entidades. Assim, é possível definir se 
as ocorrências de uma entidade são obrigadas a se relacionar com no mínimo uma 
ocorrência da outra entidade que participa do relacionamento, e também definir se 
há um limite de ocorrências com que pode estar ligada.
Temos dois tipos de cardinalidades: Cardinalidade Mínima e Cardinalidade 
Máxima. Que são definidas no relacionamento e são especificadas juntas (Cardina-
lidade Mínima, Cardinalidade Máxima).
CARDINALIDADE MÍNIMA
Especifica, se as ocorrências de uma entidade são obrigadas a participar do re-
lacionamento, ou seja, ter relação com no mínimo uma ocorrência da outra entidade, 
ou não, nesse caso não precisam participar do relacionamento. Os valores possíveis 
para a cardinalidade mínima são:
• 1 – que indica obrigatoriedade (restrição).
• 0 – que indica a não obrigatoriedade.
Atividade: Considere alguns contextos de 
sistemas e Defina os relacionamento entre 
as principais entidades.
Sugestões de Contextos: gestão de DVDs, 
controle de gastos, controle de compras, 
etc.
RELACIONARENTIDADE A ENTIDADE B
(minima, máxima) (minima, máxima)
43PROJETO DE BANCO DE DADOS
CARDINALIDADE MÁXIMA
Especifica a proporção que as ocor-
rências de uma entidade podem se relacio-
nar com as ocorrências da outra entidade. 
Na prática, indica se uma ocorrência pode 
se relacionar com no máximo uma ocor-
rência da outra entidade ou se pode se 
relacionar com duas ou mais ocorrências. 
Os valores possíveis para a cardinalidade 
máxima são:
• 1 – que indica a relação com no má-
ximo 1 ocorrência (restrição)
• N – que indica que pode ter relação 
com várias ocorrências
Na prática, conforme o contexto, 
pode-se ter qualquer combinação de car-
dinalidades mínimas e máximas. As car-
dinalidades serão definidas a partir das 
regras da aplicação.
Vamos analisar alguns exemplos!
Exemplo 1: O seguinte diagrama 
ER apresenta a relação entre pessoas que 
fazem cursos. A cardinalidade foi especifi-
cada apenas em uma das extremidades do 
relacionamento, a fim de facilitar a com-
preensão. Foi definida como (1,1), ou seja, 
cardinalidade mínima = 1, e cardinalidade 
máxima = 1. Explicando a interpretação 
desta especificação: cada ocorrência de 
pessoa é obrigada a se relacionar como no 
mínimo um curso (cardinalidade míni-
ma = 1), isso é uma restrição e deverá ser 
garantida pelo SGBD. Além disso, cada 
pessoa pode se relacionar com no máximo 
um curso (cardinalidade máxima = 1), isso 
também é uma restrição que deverá ser 
controlada pelo SGBD. A leitura desse 
relacionamento é a seguinte: uma pessoa 
é obrigada a fazer exatamente um curso.
Exemplo 2: A cardinalidade foi de-
finida como (0,1), ou seja, cardinalidade 
mínima = 0, e cardinalidade máxima = 
1. Explicando a interpretação desta espe-
cificação: cada ocorrência de pessoa não 
é obrigada a se relacionar com um curso 
(cardinalidade mínima = 0), ou seja, po-
derão existir pessoas que não tem relação 
com cursos. Além disso, cada pessoa pode 
se relacionar com no máximo um curso 
(cardinalidade máxima = 1), isso é uma 
restrição que deverá ser controlada pelo 
SGBD. A leitura desse relacionamento é 
a seguinte: uma pessoa não é obrigada a 
fazer um curso e pode fazer no máximo 
um curso.
Exemplo 3: A cardinalidade foi de-
finida como (1,n), ou seja, cardinalidade 
mínima = 1, e cardinalidade máxima = 
n. Explicando a interpretação desta es-
pecificação: cada ocorrência de pessoa é 
obrigada a se relacionar como no mínimo 
um curso (cardinalidade mínima = 1), isso 
é uma restrição e deverá ser garantida pelo 
SGBD. Além disso, cada pessoa pode se 
relacionar com diversos cursos (cardina-
lidade máxima = n). A leitura deste re-
lacionamento é a seguinte: uma pessoa é 
FAZERPESSOA CURSO
(1, 1)
FAZERPESSOA CURSO
(0, 1)
44PROJETO DE BANCO DE DADOS
obrigada a fazer no mínimo um curso e 
pode fazer vários cursos.
Exemplo 4: A cardinalidade foi de-
finida como (0,n), ou seja, cardinalidade 
mínima = 0, e cardinalidade máxima = 
n. Explicando a interpretação desta espe-
cificação: cada ocorrência de pessoa não 
é obrigada a se relacionar com um curso 
(cardinalidade mínima = 0), ou seja, po-
derão existir pessoas que não tem relação 
com cursos. Além disso, cada pessoa