PROJETO DE BANCO DE DADOS

Ester M. Poegere
 PROJETO DE BANCO DE DADOS 2

SUMÁRIO
PERSPECTIVA HISTÓRICA DOS BANCOS DE DADOS 6 MODELO RELACIONAL 50
PRIMEIROS TEMPOS 7 CHAVES 51
DÉCADA DE 70 11 RESTRIÇÕES DE INTEGRIDADE 52
DÉCADA DE 80 13 ESPECIFICAÇÃO RESUMIDA DE UM ESQUEMA RELACIONAL 55
DÉCADA DE 90 14 NORMALIZAÇÃO DE BANCO DE DADOS 55
SITUAÇÃO ATUAL E FUTURO 15
MAPEAMENTO ER → RELACIONAL 58
FUNDAMENTOS E CONCEITOS DE BANCO DE DADOS 18 MAPEAMENTO DE ENTIDADES 59
CENTRO UNIVERSITÁRIO UNIFTEC
A EVOLUÇÃO DO DADO 19 MAPEAMENTO DE RELACIONAMENTOS DO TIPO (N:N) 59
Rua Gustavo Ramos Sehbe n.º 107.
SISTEMA DE GERÊNCIA DE BANCO DE DADOS 20 MAPEAMENTO DE RELACIONAMENTOS DO TIPO (1:N) 62 Caxias do Sul/ RS
POR QUE USAR SGBD? 22 MAPEAMENTO DE RELACIONAMENTOS DO TIPO (1:1) 62
ARQUITETURA DO SGBD 23 MAPEAMENTO DE AUTORRELACIONAMENTOS 63 REITOR
LINGUAGEM PADRÃO DOS SGBD 27 MAPEAMENTO DE RELACIONAMENTOS IDENTIFICADORES 65 Claudino José Meneguzzi Júnior
PRÓ-REITORA ACADÊMICA
MODELAGEM DE DADOS 28 MAPEAMENTO DE GENERALIZAÇÃO/ESPECIALIZAÇÃO 65 Débora Frizzo
PRÓ-REITOR ADMINISTRATIVO
MODELO ENTIDADE-RELACIONAMENTO 34 Altair Ruzzarin
DIRETORA DE EDUCAÇÃO A DISTÂNCIA (NEAD)
CONCEITOS CENTRAIS DO MODELO ER 35 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
 PROJETO DE BANCO DE DADOS 3

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.
 PROJETO DE BANCO DE DADOS 4

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-

“Who has good quality information, truturas que identificam seus elementos
reliable, the correct amount at relevantes e como estão relacionados, o
the right time, get competitive ciclo de vida da informação, mudanças que
advantage, but the lack of information ocorrem ao longo do tempo e recursos para
gaps gives the errors and missed facilitar as pesquisas, são aspectos muito
opportunities.”1 importantes para que tenhamos as infor-
mações que precisamos, quando forem
necessárias, com a precisão e qualidades
Peter Drucker adequadas.

Saiba, que na história, esses registros

Peter Ferdinand Drucker 1“Quem dispõe de informações de boa qualidade, fidedignas, em quan- eram feitos em papel, separados em pastas/
(19/11/1909 – 11/11/2005) tidade adequada e no momento certo, adquire vantagens competitivas,
mas a falta de informação dá brechas a erros e à perda de oportunidades.” caixas/gavetas/estantes, com guias de con-

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
Você já pensou sobre como a Google
armazena e recupera informações?
PROJETO DE BANCO DE DADOS 5
eficientes1 e eficazes2 de grandes volumes perspectiva histórica, no primeiro capítulo.
de dados. Banco de dados é uma área de pes-
O gmail tem mais de 60 milhões de quisa e desenvolvimento no contexto de
usuários, o Google Earth e Google Maps Ciência da Computação. Dessa forma,
armazenam imagens do mundo todo, es- possui conceitos fundamentais e termino-
truturas de vias, roteiros, etc. Além disso, logias específicas, que precisam ser conhe-
a Google guarda informações de todas as cidos e compreendidos para o adequado
páginas do mundo e recebe mais de 100 uso dessa tecnologia, assim no segundo
milhões de consultas por dia. Estima-se capítulo nos focaremos nesse objetivo.
que a Google armazene muitos petabytes
Para que possamos recuperar infor-
de dados (1 petabyte = 1024 terabytes). mações, elas precisam ser adequadamente
Tudo isso somente é possível com a armazenadas. Assim, surge a necessidade
utilização de SGBD (Sistemas Gerencia- da modelagem de dados que definirá a
dores de Bancos de Dados)! organização dos bancos de dados. Dessa
A história dos Sistemas Gerenciado- forma, no terceiro capítulo, estudaremos
res de Banco de Dados inicia na década de os fundamentos da modelagem entidade-
60 (século XX), nos laboratórios da IBM, -relacionamento (DER), que é conside-
onde faziam pesquisas para automação de rado um dos mais importantes modelos
escritórios, pois já percebiam a impor- de banco de dados. E na sequência, no
tância da informação e o alto custo, em quarto capítulo estudaremos o Modelo
termos de pessoas e espaço, necessário para Relacional. Por último, no quinto capítulo,
gerenciá-la. Desde essa época, até hoje, aprenderemos a transformar um diagrama
muito mudou e juntos analisaremos sua ER e um esquema de dados relacional.
1Ser eficiente é uma qualidade que indica a rapidez de realização de Tenho certeza que você irá gos-
uma atividade, é agilizar os processos para chegar ao objetivo no menor
tempo possível. tar muito de aprender sobre Bancos de
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 Dados!
esperado/desejável.
 PROJETO DE BANCO DE DADOS 6

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
 PROJETO DE BANCO DE DADOS 7

de bancos de dados, tão pioneiros nos pri- banco de dados. correto. Exemplo: Um arquivo com dados
mórdios, tornaram-se intrínsecos ao modo dos funcionários, onde se tem o endereço.
como as organizações gerenciam os dados. Na década de 1960 foram desenvol- Outro arquivo com dados de voluntários,
vidas pesquisas para automação de escri- onde também se tem o endereço. Agora,
A atual velocidade da produção de tórios, que visavam otimizar os proces- suponha que uma pessoa que é funcioná-
dados é impulsionada pela demanda e sos realizados, organizar as informações rio e também voluntário, teria seus dados
acessibilidade que aumentam, constan- e facilitar o trabalho. Nesse período, os redundantes, repetidos em ambos os ar-
temente, à medida que as bases de dados dados eram organizados em arquivos ge- quivos. Se ela mudar de endereço e este for
se tornam cada vez mais essenciais para renciados pelo sistema operacional, era somente alterado no arquivo de funcioná-
aspectos de nossas vidas diárias. Deve-se uma maneira rudimentar de armazená-los, rios. A partir dessa alteração, como saber
ter em conta, que o volume de dados em mas que oferecia vantagens em relação ao qual o endereço correto, pois seu endereço
muitos períodos excedeu a capacidade de armazenamento físico em papel. Por outro estará diferente em cada um dos arquivos.
processamento (humana e computacional) lado, os sistemas de arquivos apresentavam Esse é um problema grave e denomina-se
e isso sempre impulsionou a busca por al- alguns inconvenientes: inconsistência (a mesma informação com
ternativas mais eficientes, impulsionando valores diferentes em lugares diferentes).
a evolução dos bancos de dados3. Redundâncias e Inconsistências
Dificuldade de Acesso
PRIMEIROS TEMPOS Frequentemente a mesma informa-
ção estava em diversos arquivos (repetida), O acesso ás informações organi-
A IBM (International Business Ma- ou seja, havia redundância. Esta caracte- zadas em arquivos, devem ser feitas pelo
chine) está ligada às origens de muitos rística pode levar a um grave problema sistema (softwares/aplicação) que a gerou,
desenvolvimentos tecnológicos computa- que é a inconsistência, pois com a mesma assim para acessar as informações de um
cionais e não podia ser diferente com os informação repetida em dois ou mais ar- arquivo, também é necessário saber como
quivos, ela poderia ser atualizada em um foi gerada (linguagem de programação e/
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 deles e não ser em outro, assim passa a ter ou sistema) e sua estrutura, caso contrário,
“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
dois (ou mais) valores diferentes, inconsis- na maioria das vezes o acesso fica inviável.
Hollerith’s Tabulating Machine Company foi posteriormente fundida tentes e, muitas vezes, não se sabe qual o
com outras três empresas em International Business Machines (IBM).

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
PROJETO DE BANCO DE DADOS 8
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-
 PROJETO DE BANCO DE DADOS 9

mo instante estão sendo realizadas duas transferências bancárias, portanto duas Portanto, o saldo final das contas é:
transações concorrentes. Considere ainda, os seguintes saldos dos clientes: Cliente A: Cliente A: R$ 0,00; Cliente B: R$ 150,00;
R$ 200,00; Cliente B: R$ 50,00; e Cliente C: R$ 100,00. Assim, hipoteticamente, e Cliente C: R$ 300,00. Assim, novamente
se o banco tivesse apenas esses três clientes o total em depósitos seria R$ 350,00. A hipoteticamente, se o banco tivesse apenas
tabela a seguir exemplifica o problema da execução concorrente destas transações, esses três clientes o total em depósitos,
sendo T0 o tempo inicial e Tx a sequencial temporal de realização das atividades. agora seria R$ 450,00. Perceba que após o
processo, com problemas de concorrência,
Demonstração do Problema de Acesso Concorrente o saldo total de depósitos foi alterado e
Atividade Transação 1: Transação 2: deveria se manter o mesmo! O problema
transferir R$ 100,00 do transferir R$ 200,00 do é que essas duas transações não poderiam
cliente A para o cliente B cliente A para o cliente C ser executadas simultaneamente, visto que
Iniciar o processo de transferência T0 T1 consultam e alteram a mesma informação
que é o saldo do cliente A. Para correta
Consultar o saldo da conta do
cliente A
T2: saldo=R$ 200,00 T3: saldo=R$ 200,00 execução concorrente, a segunda transa-
ção somente poderia ser liberada após o
Informar o valor a ser sacado T4: R$ 100,00 T5: R$ 200,00 término da primeira e neste caso o saldo
Registrar a retirada da conta do consultado já teria sido alterado.
T6: saldo = 200 - 100 T7: saldo = 200 - 200
cliente A do valor sacado
Atualizar o saldo da conta do cliente T8: saldo = 100 (gravar) T9: saldo = 0 (gravar) Problemas de Segurança
A (cliente A) (cliente A)
Consultar o saldo da conta do T10: saldo = 50 T11: saldo = 100
cliente que recebe a transferência (cliente B) (cliente C)
As informações das corporações e
nossas informações pessoais, entre ou-
Registrar o depósito na conta do T12: saldo = 50 + 100 T13: saldo = 100 + 200 tras, muitas vezes não devem ser acessadas
cliente (cliente B) (cliente C)
por pessoas não autorizadas, portanto é
T14: saldo = 150 (gravar) T15: saldo = 300 (gravar) necessário implementar mecanismos que
Alterar o saldo na conta do cliente
(cliente B) (cliente C)
as protejam. Nos primórdios, utilizando
Finalizar a transação T16 T17 arquivos para o armazenamento, pois o

controle da segurança também precisava
ser 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.
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?
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
PROJETO DE BANCO DE DADOS 10
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 COBOL 4 .
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.
 PROJETO DE BANCO DE DADOS 11

Edgar Frank Codd DÉCADA DE 70 R - Relacional), que acabou por dar nome
(23/8/1923 – 18/4/2003) ao Sistema Relacional. Este sistema evo-
lui e finalmente passou a ser chamado de
E.F. Codd foi um matemático in- DB2, o principal e mais conhecido sistema
glês que trabalhava na IBM, que em 1972 de banco de dados da IBM.
publicou um artigo chamado “Relational
Model of Data for Large Shared Data Banks”. Com o System R foi desenvolvida
Esse artigo apresentou os fundamentos uma linguagem conhecida por Structured
do Modelo de Banco de dados Relacio- Query Language6 (SQL) . O Modelo de
nal, baseado na Teoria de Conjuntos5 , Banco de Dados Relacional e os Sistemas
lançando as bases para que informações de Banco de Dados Relacionais tornaram-
interligadas fossem definidas como rela- -se padrão para a indústria de banco de
ções (conjuntos) e adaptando essa teoria dados e é um padrão ISO7 (International
matemática para a área de banco de dados. Organization for Standardization) .
Também apresentou o cálculo e a álgebra
relacional que consistem em conjunto de Sistemas de Banco de Dados Rela-
operações matemáticas para manipulação cionais separam os dados da aplicação da
das informações. sua estrutura de armazenamento e pos-
sibilitam a manipulação das informações
A proposta de Codd era comple- através de uma linguagem de consulta
xa e não foi prontamente aceita e imple- que implementa as operações matemáticas
mentada, mas ele conseguiu que a IBM especificadas no modelo relacional.
permitisse a implantação de um grupo de
pesquisa denominado System R (Sistema O protótipo do System R foi lan-
5 Ramo da matemática, a Teoria dos conjuntos estuda as coleções çado pela IBM, em 1974, que somente
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 4 Linguagem de Consulta Estruturada, hoje também conhecida
e produto cartesiano. Esta teoria inclui a especificações do cálculo e da como Linguagem de Consulta Padrão (Standard Query Language).
álgebra para os conjuntos. 7 Organização Internacional de Padronização.
 PROJETO DE BANCO DE DADOS 12

disponibilizou sua versão comercial em O Modelo ER8, como é conhecido,

1981. O primeiro Sistema Gerenciador tornou-se base para diversas metodologias
de Banco de Dados Relacional comercia- de análise e projeto de sistemas, para o
lizado, foi desenvolvido pela Honeywell desenvolvimento de ferramentas de mo-
Information Systems Inc. em 1976, mas delagem e de apoio ao desenvolvimento
não existe mais. Ainda antes da IBM, em de software (ferramentas CASE9), projetos
1979 a ORACLE Corporation lança o de dicionários e repositórios de dados.
ORACLE DataBase System e torna-se o Esse modelo ainda é utilizado atualmen-
SGBD Relacional mais conhecido e uma te, diversas extensões foram agregadas à
das maiores corporações reconhecidas até proposta original, além de ser a base para
os dias de hoje. outros modelos como o diagrama de clas-
ses do paradigma orientado a objetos. Em
Outra grande contribuição para evo- 1979 ocorreu a primeira conferência de
lução dos Sistemas de Banco de Dados foi modelagem conceitual10, conhecida como
o Modelo Entidade-Relacional proposto ER Conference. Entre os dias 14 e 17 de
por Peter Chen em seu artigo “The Enti- novembro de 2016 ocorreu a 35º ER Con-
ty-Relationship Model--Toward a Unified ference, demonstrando a atual relevância
View of Data” publicado na ACM Tran- do trabalho realizado por Peter Chen e as
sactions on Database Systems, em 1976. ramificações desse no contexto da mode-
Esse artigo é um dos mais importantes lagem conceitual de banco de dados.
para a área de banco de dados e para a
ciência da computação, além de ser um As contribuições de Codd e Chen
dos trabalhos mais citados. A inovação da foram determinantes para evolução dos
proposta de Chen, foi a especificação de Sistemas Gerenciadores de Banco de Da-
um modelo independente da implemen-
8 Modelo ER (Modelo Entidade-Relacionamento), também
tação do Sistema Gerenciador de Banco conhecido simplesmente por Diagrama ER (DER).
de Dados, iniciando o que chamamos de Software
9 CASE: Computer Aided Software Engineer (Engenharia de
Auxiliada por Computador)
modelagem conceitual de banco de dados. www.conceptualmodeling.org/)
10 International Conference on Conceptual Modeling (http://
Peter Chen
(Nasceu em 3/1/1947)

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 armazenamento e 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), apoio, ao desenvolvimento, são ampla-
utilizado como repositório de dados por mente difundidas no final desta década e
muitas aplicações.
Em paralelo com a evolução de siste- dados. Contribui para isso, a padronização
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 flexibilidade 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
se amplia a confiança para o desenvolvi-
mento de aplicações baseadas em banco de
PROJETO DE BANCO DE DADOS 13
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.

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,
PROJETO DE BANCO DE DADOS 14
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.
 PROJETO DE BANCO DE DADOS 15

SITUAÇÃO ATUAL E FUTURO escalável de sistemas NoSQL para pro- assim como o telescópio alterou a forma de
cessamento on-line de transações (leitura compreensão do universo e o microscópio
e gravação), enquanto ainda usa o SQL. nos permitiu ver o que parecia invisível.
No século XXI, amplia-se o uso dos Esses bancos de dados incluem ScaleBa- Big Data mudará a forma de como per-
bancos de dados XML14 , que são um tipo se, Clustrix, EnterpriseDB, MemSQL, cebemos o mundo, pois deixamos de ter
de banco de dados estruturado orientado a NuoDB e VoltDB. problemas para coletar dados, não temos
documentos e que permite consultas com mais escassez de dados, contudo, agora,
base em atributos de documentos XML. A história dos SGBDs está ligada a temos abundância de dados. Com isso,
Os bancos de dados XML são utiliza- necessidade de armazenar grandes volumes surge um novo problema, pois temos uma
dos como padrão de interoperabilidade de informações para que possam ser recu- capacidade limitada para lidar com gran-
de dados máquina-a-máquina. Também peradas, de forma eficiente e convenien- des volumes de dados e torna-se cada vez
surgem os bancos de dados NoSQL que, te. Estima-se que em 2020 serão gerados mais difícil filtrar o que nos interessa ou
geralmente, são muito rápidos, não re- mais de 40 zetabytes de dados (mais de 40 não.
querem esquemas de tabela fixa, evitam trilhões de gigabytes), de fontes de dados
operações de junção, armazenando dados diversificadas: sistemas empresariais, sis- O impacto do Big Data supera a
desnormalizados e são projetados para temas de instituições de pesquisa, sistemas invenção da imprensa (1430), que nos pri-
trabalhar com escalonamento horizontal. de monitoramento, dados climáticos, redes meiros 50 anos publicou mais conteúdos
sociais, fotos, etc. Constitui-se ainda um que em toda a história anterior. Desde
É desenvolvido também o NewS- desafio organizar todas essas informações 2010, a cada 2 dias são gerados mais dados
QL, o qual é uma classe de Banco de Da- de maneira a torná-las úteis e significati- do que em toda a história da humanida-
dos Relacionais modernos, que tem como vas, permitindo que sejam correlacionadas de (anterior à internet) e estima-se que a
objetivo fornecer o mesmo desempenho e que possibilitem a tomada de decisões cada 2 anos o volume de informações seja
ou o seu simples acesso, quando forem duplicado.
14 XML (eXtensible Markup Language) é um padrão recomendado
pela da W3C para produzir arquivos com objetivos específicos. A XML
necessárias e relevantes. Esse grande vo-
deriva da SGML (acrônimo de Standard Generalized Markup Language ou lume de informações constitui o Big Data. Assim, muitas pesquisas tem sido
Linguagem Padronizada de Marcação Genérica) e possibilita a descrição de
diversos tipos de dados. O objetivo principal é facilitar o compartilhamento realizadas para trabalhar com o Big Data,
de informações pela internet. O Consórcio World Wide Web (W3C) é
um consórcio internacional no qual organizações filiadas, uma equipe em O Big Data sinaliza o princípio de essas visam a integração de diversas ferra-
tempo integral e o público trabalham juntos para desenvolver padrões para
a Web. (https://www.w3.org/ )
uma grande transformação na sociedade, mentas e desenvolvimento de novas com o
 PROJETO DE BANCO DE DADOS 16

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 a ser 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?

 PROJETO DE BANCO DE DADOS 18

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.

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.
PROJETO DE BANCO DE DADOS 19
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.

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.
PROJETO DE BANCO DE DADOS 20
• Construção do Banco de Dados: é dados relacionados e que são gerenciados
o processo de criação das estruturas por um sistema de gerência de banco de
físicas e configurações do Banco de dados.
Dados.
Dessa forma, o SGBD constitui-se
• Manipulação do Banco de Dados: em um conjunto de softwares especializa-
são os processos de armazenamen- dos com funções específicas, interligados
to de dados (inclusão, alteração e com os programas de aplicações e com o
exclusão de dados) e execução de banco de dados. Vamos conhecer alguns
consultas e relatórios. destes softwares que fazem parte de um
SGBD ou trabalham em conjunto com ele:
Vamos aprender a definir Banco de
Dados!! Programas de Aplicação: são pro-
gramas desenvolvidos para as organiza-
Há várias formas de definir o que é ções e usuários com os mais diversos fins:
um banco de dados: conjunto de arquivos gestão empresarial, cálculos de impostos,
relacionados, coleção de dados operacio- gestão de estoques, cálculos de custos,
nais armazenados e usados por sistemas, catalogação de livros, etc.
coleção de dados relacionais. Enfim, um
banco de dados é uma estrutura armazena- Gerenciador de Arquivos: software
da em um dispositivo físico composta por especializado em fazer a gestão dos arqui-

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 relação entre esses e alguns outros ele-
1 DBA: DataBase Administrator
mentos de um SGBD:
PROJETO DE BANCO DE DADOS 21
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 linguagem SQL 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

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
PROJETO DE BANCO DE DADOS 22
da inconsistência de dados2 . • Restrições de Segurança: os con-
troles de acesso e operações válidas
• Compartilhamento dos Dados: os para cada usuário são definidas pelo
dados armazenados nos Bancos de administrador do banco de dados
Dados gerenciados pelos SGBD Re- (DBA) e garantidas pelo SGBD,
lacionais são manipulados através da isso permite que os programadores
linguagem SQL. Assim, é simples de aplicações não precisam ter essa
construir aplicações para acesso aos preocupação em cada programa de-
dados de qualquer SGBD e inclusive senvolvido.
integrando informações de mais de
um Banco de Dados. • Gestão das Transações (Atomici-
dade das Transações e Controle da
• Padronização e Portabilidade: para Concorrência): as transações (con-
serem armazenados no SGBD os juntos de comandos que realizam
dados devem ser organizados e se- um processo consistente em relação
guem um padrão de modelagem e a aplicação) devem ser consideradas
especificação, esse padrão é compar- como unidades atômicas e que não
tilhado pelos diversos fabricantes de devem usar dados que estão sendo
SGBD Relacionais. Dessa forma, as manipulados por outras transações.
bases de dados podem ser facilmente Os SGBD possuem controle próprio
portadas de um SGBD para outro. para que cada transação seja executa
Essa portabilidade não é absoluta, inteiramente (todos os seus coman-
exige algum esforço, mas é possível. 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
2 Lembres que a Inconsistência de Dados refere-se a mesma
manipulando determinados dados
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 estes se tornam automaticamente
são valores inconsistentes.

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
PROJETO DE BANCO DE DADOS 23
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

• 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
para garantir a correção das informações.
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
PROJETO DE BANCO DE DADOS 24
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.

direcionando-as apenas para quem
as precisa. Nesse nível trabalham os
programadores de aplicações que as
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-
PROJETO DE BANCO DE DADOS 25
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,

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-
PROJETO DE BANCO DE DADOS 26
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

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
PROJETO DE BANCO DE DADOS 27
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.
 PROJETO DE BANCO DE DADOS 28

Linguagem de Manipulação de dos (DTL – Data Transaction Language): serão utilizados para construção da base
Dados (DML – Data Manipulation Lan- Subconjunto de comandos que possibili- de dados do sistema.
guage): Subconjunto de comandos para in- tam o controle de transações e engloba
serir, remover e modificar informações em os seguintes comandos: BEGIN TRAN- Por que é importante MODE-
um esquema de banco de dados (INSERT, SACTION, que define o início de uma LAR?
UPDATE E DELETE). Os comandos transação; COMMIT, que finaliza uma
DML não são diretamente efetivados no transação com sucesso e efetiva todas as A modelagem é uma etapa que faz
Banco de Dados, pois dependem da con- operações realizadas no Banco de Dados; e parte do processo de análise de um sis-
clusão com sucesso da transação em que ROLLBACK, que interrompe uma tran- tema, de forma que quando é realizada a
estão, assim podem ser desfeitos. sação e desfaz todas as operações realizadas interação com os usuários, para compreen-
desde o início da transação. der adequadamente suas necessidades; as
Linguagem de Consulta de Dados informações das quais precisa; as relações
(DQL – Data Query Language) – é a parte entre as informações; as transformações
MODELAGEM DE DADOS
da SQL que é mais utilizada e embora que as informações podem sofrer; as regras
seja formada por apenas um comando de funcionamento das atividades que o
(SELECT) e um dos mais importantes, Saiba que a Modelagem de Dados é usuário realiza; os controles que precisam
permite a extração de dados/informações uma etapa essencial do desenvolvimento ser feitos; os resultados esperados; a forma
do Banco de Dados. de um sistema! de apresentação das informações; as aná-
lises de dados que devem ser realizadas;
Linguagem de Controle de Da- Modelar é um processo que utiliza quais os tipos de usuários que devem ter
dos (DCL – Data Control Language): um modelo de dados para construir um acesso às informações; as restrições de
esquema que explicita as características de
Subconjunto de comandos para controlar acesso a essas informações; enfim entender
informações, funcionamento e compor-
as autorizações de acesso e manipulação todo o contexto para o qual a aplicação
tamento de uma realidade para a cons-
das estruturas do SGBD. Isso é realizado será desenvolvida.
por comando que concedem ou revogam trução de um software. Nesse sentido,
as permissões (GRANT E REVOKE). o esquema de dados é uma abstração da A partir dessa compreensão é pos-
realidade que especifica as propriedades sível construir o esquema de dados e fa-
Linguagem de Transação de Da- dos dados, informações e restrições que zer toda a especificação do sistema, que
 PROJETO DE BANCO DE DADOS 29

depois passará para etapas de projeto e • A manutenção do sistema será di- • Modelos conceituais: que permi-
desenvolvimento (programação). Quando fícil. tem a especificação de alto nível
a análise e a modelagem de dados não são do banco de dados, mais próxima
feitas, ou quando ocorrem falhas nesta Para realizar a modelagem de dados do usuário e independe do tipo
etapa diversos problemas podem ocorrer: é necessário utilizar modelos de dados! de SGBD que será utilizado. Os
principais modelos conceituais são:
• O sistema desenvolvido pode não MODELOS DE DADOS modelo entidade-relacionamento; e
atender às necessidades dos usuários; modelo de classes (orientado a ob-
jetos).
• O sistema desenvolvido pode ter O que são modelos de dados??
erros em relação aos requisitos; • Modelos lógicos: dependem da
Os modelos de dados são ferramen- classe de SGBD que será utilizado,
• A base de dados pode não conter tas conceituais que possuem um conjunto mas não de um SGBD específico. O
todas as informações que os usuários de estruturas para especificação de ele- modelo lógico é construído a partir
precisam; mentos de uma realidade, suas relações do modelo conceitual. Os principais
e suas restrições que permitem construir modelos lógicos são: modelo rela-
• A base de dados pode ter relaciona- esquemas de dados. cional; modelo orientado a objetos;
mentos incorretos entre os dados, ou e modelo objeto-relacional.
falta de relações adequadas; Ferramentas conceituais são recursos
textuais ou gráficos, que através de regras • Modelos físicos: descrevem as es-
• A base de dados pode ter regras de orientam o trabalho do analista para a truturas e métodos de acesso de um
integridade incorretas ou inadequa- construção dos esquemas. Assim, para SGBD específico e é construído a
das para o contexto da aplicação; compreender um modelo de dados é ne- partir do modelo lógico. Relaciona-
cessário compreender as suas ferramentas do com a linguagem de programação
• A base de dados pode não ter a fle- conceituais e regras. do SGBD.
xibilidade adequada para a evolução
do sistema desenvolvido; Os modelos de dados podem ser Para construção da base de dados é
classificados em: necessário seguir as seguinte etapas:
 PROJETO DE BANCO DE DADOS 30

1. Análise de Requisitos: quando se lhido e toma-se por base o esquema lógico construído na fase anterior.
interage com os usuários e especi-
fica os requisitos do sistema. Isto A tabela a seguir resume, em forma de esquema, as etapas de construção de
é realizado através de entrevistas um banco de dados:
com os usuários, observação do seu
trabalho e análise de documentos. MUNDO REAL Requisitos da aplicação
Interação com os usuários
2. Projeto Conceitual: com base nos Compreensão da aplicação
requisitos é construído o esquema
conceitual do sistema e se utiliza
para isso um modelo conceitual.
Este esquema deve ser validado com MODELO Independente do SGBD
o usuário, visando eliminar dúvidas CONCEITUAL (Especificação mais
e garantindo que atende as expecta- (Modelo próxima dos usuários)
tivas do sistema a ser desenvolvido. Abstrato dos
Dados)
3. Projeto Lógico: realizamos o ma-
peamento do esquema de dados MODELO Dependente do tipo de Modelo Modelo Modelo Objeto
conceitual para um esquema lógico, LÓGICO SGBD mas não de um Relacional Orientado a Relacional
utilizando o modelo lógico da classe (Estrutura dos SGBD específico Objetos
de banco de dados escolhido. Dados) Derivado do Esquema
Conceitual
4. Projeto Físico: fazemos as espe-
MODELO Derivado do Esquema - Estruturas de armazenamento de dados
cificações da base de dados para
FÍSICO Lógico - Índices de acesso
um SGBD específico, definindo a
(Organização Dependente do SGBD - Restrições de integridade e segurança
organização física dos dados que
Física dos escolhido
englobam estruturas, tipos e outros
Dados)
elementos, conforme o SGBD esco-
 PROJETO DE BANCO DE DADOS 31

Assim, podemos considerar um restrições de integridade e acesso

exemplo de uso bastante comum destas no SGBD Oracle (um SGBD es-
etapas: pecífico).

1. Análise de Requisitos: etapa de en- Dessa forma, para o uso regular des-
trevistas e interação com o usuário, se processo precisamos estudar o Modelo
análise dos processos que o usuário Entidade-Relacionamento e o Modelo
realiza e estudo de documentos/re- Relacional.
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- Ampliando nosso conhecimento!

amento do esquema de dados con- Pesquise sobre alguns dos SGBDs
ceitual para um esquema de dados utilizados comercialmente nos dias de hoje.
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,
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?
 PROJETO DE BANCO DE DADOS 34

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 )
 PROJETO DE BANCO DE DADOS 35

apresenta as bases desse modelo conceitual, CONCEITOS CENTRAIS DO MODELO ER

independente de um Sistema Gerenciador
de Banco de Dados, e descreve as fer-
ramentas conceituais do modelo que se Para construção de diagramas entidade-relacionamento (DER) é necessário
constituem de entidades, objetos concretos conhecer as suas ferramentas conceituais que são os conceitos centrais do Modelo ER:
ou abstratos da realidade considerada, e de
relacionamentos que se estabelecem entre • Entidades
elas. Dessa estrutura deriva a denomina-
ção do modelo: entidade-relacionamento • Relacionamentos
(Entity-Relationship Model). Atualmen-
te, o Modelo ER ainda é a técnica mais • Atributos
difundida e utilizada na etapa de projeto
conceitual. • Cardinalidade

Esse modelo é uma orientação siste- • Generalização/Especialização

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.
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.
 PROJETO DE BANCO DE DADOS 36

Uma habilidade importante para

modelagem de dados é saber identificar
as entidades dentro do contexto de uma
ENTIDADE aplicação/sistema!

Vejas a seguir alguns exemplos de entidades: Considere o contexto acadêmico, a

seguir estão listadas as principais entidades
que podem ser identificadas:

ALUNO CURSO

INSTITUIÇÃO DE
CONCRETAS CURRÍCULO
ENSINO

PESSOA CARRO LIVRO

MATRÍCULA TURMA

DISCIPLINA PRÉDIO
ABSTRATAS MATRÍCULA CURSO PROJETO
SALA PROFESSOR

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.
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.
ATRIBUTO INDETIFICADOR
MATRÍCULA 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-
PROJETO DE BANCO DE DADOS 37
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
 PROJETO DE BANCO DE DADOS 38

poderíamos acrescentar cor dos olhos e cor dos cabelos. A seguir, veja os diagramas Assim, os atributos (características)
ER da entidade Pessoa nestes diferentes contextos de sistemas: não são inerentes à entidade considerada,
mas dependem da aplicação em que a en-
tidade está sendo modelada.
NOME
DATA DE NASCIMENTO

Contexto de um Sistema Acadêmico PESSOA CPF

EMAIL
TELEFONE
Atividade: Considere alguns contextos
de sistemas e Defina os atributos das
principais entidades.
NOME
TELEFONE
CPF
Contexto de um Sistema de uma
PESSOA EMAIL
Academia DATA DE NASCIMENTO
PESO Sugestões de Contextos: gestão de DVDs,
ALTURA controle de gastos, controle de compras,
etc.

NOME
CPF
DATA DE NASCIMENTO
RELACIONAMENTOS
Contexto de um Sistema de PESO

Relacionamentos PESSOA ALTURA

Os relacionamentos representam as
COR DOS OLHOS associações que ocorrem entre as entida-
COR DOS CABELOS des da realidade considerada, ou seja, as
EMAIL relações que existem entre os objetos do
TELEFONE mundo real. Por exemplo: pessoas fazem
 PROJETO DE BANCO DE DADOS 39

cursos; cursos são formados por disci-

plinas; livros tem autores; pessoas prati-
cam esportes; produtos são constituídos Pessoas fazem cursos: PESSOA FAZER CURSO
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 Cursos são formados por
há entre elas. DISCIPLINA FORMAR CURSO
disciplinas:
A representação gráfica dos relacio-
namentos é feita com um losango ligado
por segmentos de reta às entidades ligadas Livros tem autores:
LIVRO TER AUTOR
pelo relacionamento. Normalmente, uti-
liza-se um verbo no infinitivo para repre-
sentar a função do relacionamento.
Pessoas praticam
PESSOA PRATICAR ESPORTE
RELACIONAR esportes:

Produtos são compostos

PRODUTO COMPOR COMPONENTE
ENTIDADE A RELACIONAR
por componentes:
ENTIDADE B

Vamos ver alguns exemplos de re-

lacionamentos entre entidades: Professores ministram
PROFESSOR MINISTRAR DISCIPLINA
disciplinas:
 PROJETO DE BANCO DE DADOS 40

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:

QUANTIDADE

RECEITA UTILIZAR 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:
 PROJETO DE BANCO DE DADOS 41

Agora, vamos demonstrar como

DATA INÍCIO MANDATO
ficam as ocorrências do relacionamento
Administrar. Para especificar essas ocor-
CÓDIGO PESSOA
PESSOA ADMINISTRAR
CÓDIGO EMPRESA
rências precisamos utilizar os atributos
NOME EMPRESA RAZÃO SOCIAL identificadores de cada uma das entida-
des que participam do relacionamento e,
além disso, adicionamos os atributos do
DATA FIM MANDATO relacionamento.
Nesse diagrama apenas foram especificados os atributos essenciais para a
DATA
compreensão do exemplo. Para um melhor entendimento, vamos verificar alguns CÓDIGO CÓDIGO
INÍCIO
DATA FIM
PESSOA EMPRESA MANDATO
exemplos de ocorrências das entidades e dos relacionamentos. MANDATO

As tabelas a seguir apresentam alguns exemplos (ocorrências) fictícios para 1 100 30/03/2010 29/03/2012
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
2 100 30/03/2012 29/03/2014
em ocorrências diferentes.

CÓDIGO CÓDIGO 3 200 01/04/2013 31/03/2015

NOME RAZÃO SOCIAL
PESSOA EMPRESA
3 200 01/04/2015 31/03/2017
1 RUY BARBOSA 100 LITERATURA S.A.

Toda ocorrência de relacionamento é

2 FERREIRA GOULART 200 HISTÓRIA LTDA
identificada pela composição dos atributos
identificadores das entidades relaciona-
MACHADO DE das. Nesse caso, código pessoa e código
3 300 EMPREENDIMENTOS
ASSIS empresa, não se pode ter nessa situação

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.
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.
PROJETO DE BANCO DE DADOS 42
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).
(minima, máxima) (minima, máxima)
ENTIDADE A RELACIONAR ENTIDADE B
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.

CARDINALIDADE MÁXIMA ER apresenta a relação entre pessoas que
fazem cursos. A cardinalidade foi especifi-
cada apenas em uma das extremidades do
Especifica a proporção que as ocor- relacionamento, a fim de facilitar a com-
rências de uma entidade podem se relacio- preensão. Foi definida como (1,1), ou seja,
nar com as ocorrências da outra entidade. cardinalidade mínima = 1, e cardinalidade
Na prática, indica se uma ocorrência pode máxima = 1. Explicando a interpretação
se relacionar com no máximo uma ocor- desta especificação: cada ocorrência de
rência da outra entidade ou se pode se pessoa é obrigada a se relacionar como no
relacionar com duas ou mais ocorrências. mínimo um curso (cardinalidade míni-
Os valores possíveis para a cardinalidade ma = 1), isso é uma restrição e deverá ser
máxima são: garantida pelo SGBD. Além disso, cada
pessoa pode se relacionar com no máximo
• 1 – que indica a relação com no má- um curso (cardinalidade máxima = 1), isso
ximo 1 ocorrência (restrição) também é uma restrição que deverá ser
controlada pelo SGBD. A leitura desse
• N – que indica que pode ter relação relacionamento é a seguinte: uma pessoa
com várias ocorrências é obrigada a fazer exatamente um curso.
Na prática, conforme o contexto,
(1, 1)
pode-se ter qualquer combinação de car- PESSOA FAZER CURSO
dinalidades mínimas e máximas. As car-
dinalidades serão definidas a partir das
regras da aplicação. Exemplo 2: A cardinalidade foi de-
finida como (0,1), ou seja, cardinalidade
Vamos analisar alguns exemplos! mínima = 0, e cardinalidade máxima =
1. Explicando a interpretação desta espe-
Exemplo 1: O seguinte diagrama cificação: cada ocorrência de pessoa não
PROJETO DE BANCO DE DADOS 43
é 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.
(0, 1)
PESSOA FAZER 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 é
 PROJETO DE BANCO DE DADOS 44

obrigada a fazer no mínimo um curso e se relacionar as informações na aplicação não é obrigada a fazer um curso (cardina-
pode fazer vários cursos. que está sendo modelada. Perceba nesses lidade mínima = 0) e pode fazer diversos
exemplos que a análise é feita, conside- cursos (cardinalidade máxima = n). Já, um
PESSOA FAZER
(1, n) rando a forma como a entidade Pessoa se curso é obrigado a ter no mínimo uma
CURSO
relaciona com a entidade Curso e que as pessoa que o faça (cardinalidade mínima
cardinalidades são especificadas ao lado = 1) e pode ter diversas pessoas que o faça
Exemplo 4: A cardinalidade foi de- da entidade Curso. Agora, é necessário (cardinalidade máxima = n).
finida como (0,n), ou seja, cardinalidade especificar as cardinalidades, considerando
mínima = 0, e cardinalidade máxima = como a entidade Curso se relaciona com PESSOA
(1, n)
FAZER
(0, n)
CURSO
n. Explicando a interpretação desta espe- a entidade Pessoa. As alternativas são as
cificação: cada ocorrência de pessoa não mesmas e sua escolha sempre dependerá
é obrigada a se relacionar com um curso da aplicação. Analise os exemplos a seguir. Já no diagrama ER, a seguir, tem-se
(cardinalidade mínima = 0), ou seja, po- as seguintes especificações: Uma pessoa
derão existir pessoas que não tem relação No diagrama ER, a seguir, tem-se as não é obrigada a fazer um curso (cardina-
com cursos. Além disso, cada pessoa pode seguintes especificações: Uma pessoa deve lidade mínima = 0) e pode fazer diversos
se relacionar com diversos cursos (car- fazer exatamente um curso (cardinalidade cursos (cardinalidade máxima = n). Já, um
dinalidade máxima = n). A leitura deste mínima = 1 e cardinalidade máxima = 1); curso é obrigado a ter no mínimo uma
relacionamento é a seguinte: uma pessoa Já um curso pode não ter pessoas que o pessoa que o faça (cardinalidade mínima
não é obrigada a fazer um curso e pode façam (cardinalidade mínima = 0) e pode = 1) e pode ter diversas pessoas que o faça
fazer vários cursos. ter diversas pessoas que o façam (cardina- (cardinalidade máxima = n).
lidade máxima = n).
(0, n)
PESSOA FAZER CURSO
(0, n) (1, 1)
PESSOA FAZER CURSO Atividade: Complemente a atividade
É importante destacar que todos anterior definindo as cardinalidades dos
esses diagramas podem estar corretos em relacionamentos.
contextos diferentes. Portanto, é necessá- Já no diagrama ER, a seguir, tem-se
rio compreender muito bem como devem as seguintes especificações: Uma pessoa
 PROJETO DE BANCO DE DADOS 45

( __, 1) ( __, 1)
Sugestões de Contextos: gestão de DVDs, ENTIDADE A RELACIONAR ENTIDADE B
controle de gastos, controle de compras,
etc.
Relacionamentos (1:N) e (N:1) – um-para-muitos e muitos-para-um: quando
as ocorrências de uma entidade só podem se relacionar com no máximo 1 entidade,
mas essa pode ser relacionar com diversas da primeira.
TIPOS DE RELACIONAMENTOS

( __, 1) ( __, N)
Os relacionamentos são classificados ENTIDADE A RELACIONAR ENTIDADE B
conforme as cardinalidades máximas que
os compõe. Dessa forma, podemos ter os
seguintes tipos de relacionamentos: 1:1
(um-para-um); 1:N (um-para-muitos); N:1
( __, N) ( __, 1)
(muitos-para-um); e N:N (muitos para ENTIDADE A RELACIONAR ENTIDADE B
muitos). Essa classificação será muito im-
portante para o mapeamento do modelo
entidade-relacionamento e para o modelo
relacional. Relacionamentos (N:N) – muitos-para-muitos e muitos-para-um: quando as
ocorrências das entidades que participam do relacionamento podem se relacionar
Relacionamentos (1:1) – um-para- com diversas ocorrências das outras entidades deste.
-um: quando as ocorrências das entidades
que participam do relacionamento somente
( __, N)
podem ser relacionar com uma entidade ENTIDADE A RELACIONAR
( __, N)
ENTIDADE B
relacionada.

AUTORRELACIONAMENTO
As ocorrências de uma entidade po-
dem se relacionar com outras ocorrências
de uma mesma entidade, por exemplo,
um pessoa pode se casar com outra pes-
soa, um produto pode ser composto por
outros produtos, um processo pode ser
subdividido em outros processos. A essa
associação de uma entidade com ela pró-
pria, denomina-se autorrelacionamento.
Um autorrelacionamento segue a mesma
estrutura de representação e cardinalidades
que outros relacionamentos, a diferença é
que relaciona-se apenas com uma entidade.
ENTIDADE AUTORRELACIONAR
Vamos analisar alguns exemplos
de autorrelacionamento!
O exemplo a seguir, mostra a espe-
cificação de dados de pessoas que podem
se casar. Para que se possa ler o relaciona-
mento, é necessário estabelecer papéis das
PROJETO DE BANCO DE DADOS 46
ocorrências e assim “é como se tivéssemos
2 entidades relacionadas”. Desse modo, (0, 1) marido
CASAR
o relacionamento especifica que Pessoas PESSOA (0, n) esposa
(marido) não são obrigadas a se casar e po-
dem se casar com no máximo uma pessoa Agora, considere que estamos mo-
(esposa). Já, as Pessoas (esposa) não são delando um sistema para um cartório de
obrigadas a se casar e podem se casar com registro civil, onde, conforme a lei brasi-
no máximo uma pessoa (marido). É um leira, as pessoas somente podem se casar
relacionamento do tipo (1:1) e estabelece com uma outra pessoa, mas podem se di-
uma relação de monogamia. vorciar e então se casar novamente. Nesse
caso, ao longo da vida, uma pessoa pode
(0, 1) marido
ter diversos cônjuges, sendo um por vez,
CASAR
PESSOA (0, 1) esposa
e inclusive uma pessoa pode casar nova-
mente com alguém que já esteve casada,
mas se divorciou. Além disso, as pessoas
Agora, pense que temos que mode- não são obrigadas a se casar. A figura a
lar o sistema em um contexto em que a seguir apresenta o diagrama ER que aten-
poligamia é permitida (como ocorre em de a esse requisito.
alguns países). O diagrama ER preci-
saria ser modificado e ficaria conforme
apresentado, a seguir, especificando que (0, n) marido
CASAR
Pessoas (marido) não são obrigadas a se PESSOA (0, n) esposa
casar e podem se casar com diversas pes-
soas (esposa). Já, as Pessoas (esposa) não DATA DE CASAMENTO
são obrigadas a se casar e podem se casar
com no máximo uma pessoa (marido). É
um relacionamento do tipo (1:N).
 PROJETO DE BANCO DE DADOS 47

RELACIONAMENTO IDENTIFICADOR

Algumas entidades (objetos) do mundo real somente existem porque outras

entidades (objetos), dos quais eles dependem, existem. Por exemplo, um cartão de uma
conta bancária somente pode existir se existir uma conta bancária; um dependente de
um associado somente pode existir se o associado existir; um exemplar de um livro
somente pode existir se o livro existir. Normalmente, essas entidades que dependem
de outras para existir, também precisam dessas para serem identificadas. Nessas
situações, utiliza-se o relacionamento identificador, ou seja, um relacionamento que
contribui para que a entidade relacionada seja identificada pela herança do atributo
identificador da outra entidade.

Considere o seguinte diagrama ER, a definição do relacionamento identificador

é feita pelo traço mais grosso que liga a entidade EXEMPLAR (entidade fraca) ao
relacionamento TER, que também liga a entidade LIVRO (que se torna a entidade
forte desse relacionamento). Assim, as ocorrências da entidade exemplar terão como
identificador código livro + numero exemplar, pois herda o atributo identificador da
entidade LIVRO.

CÓDIGO LIVRO
(1, 1) (0, N) CÓDIGO EXEMPLAR
TÍTULO
LIVRO TER EXEMPLAR DATA AQUISIÇÃO
 PROJETO DE BANCO DE DADOS 48

GENERALIZAÇÃO/ESPECIALIZAÇÃO
A generalização e a especialização
são formas de associação entre objetos
(entidades) que pertencem a uma mesma
categoria, normalmente representando
uma hierarquia e que compartilham pro-
priedades, além de terem, frequentemente,
propriedades específicas. Uma entidade
generalizada é definida para especificar
os atributos compartilhados (comuns) às
entidades especializadas, que possuem os
atributos próprios (não compartilhados). A
representação gráfica do conceito de gene-
ralização/especialização é feita utilizando
um triângulo, no qual sua base organiza as
entidades especializadas e a ponta indica
a entidade generalizada.
ENTIDADE
GENERALIZADA
Considere que precisamos modelar um sistema que gerencie todo tipo de meio
de transporte: carros, caminhões, motos, iates, barcos, helicópteros, aviões, trens, etc.
Algumas propriedades são compartilhadas entre esses meios de transporte: identi-
ficação, tipo, modelo, capacidade de passageiros, etc. Mas outras são específicas da
categoria a que pertencem, por exemplo, dos veículos aéreos é necessário saber a au-
tonomia de voo e a altitude máxima, dos veículos fluviais é necessário saber o calado
(para que se saiba onde podem navegar). Esses requisitos podem ser observados no
diagrama, a seguir, que apresenta a entidade MEIO DE TRANSPORTE (entida-
de generalizada) e as entidades especializadas: TRANSPORTE TERRESTRE,
TRANSPORTE AÉREO e TRANSPORTE FLUVIAL.
CÓDIGO MEIO
CAPACIDADE
MEIO DE TRANSPORTE TIPO
MODELO
TRANSPORTE TRANSPORTE CALADO
TERRESTRE FLUVIAL

TRANSPORTE AUTONOMIA DE VOO

AÉREO ALTITUDE
ENTIDADE ENTIDADE
ESPECIALIZADA 1 ESPECIALIZADA 2
FAZENDO UM AUTOESTUDO!

1. Quais os objetivos do Modelo Entidade-Relacionamento?

2. Enumere os conceitos centrais do Modelo Entidade-Rela-

cionamento.

3. O que são Entidades? Qual a representação gráfica

de Entidades? Liste alguns exemplos de Entidades?

4. Qual a diferença entre atributos (comuns) e atributos

identificadores?

5. Explique o que são relacionamentos e qual a sua re-

presentação gráfica?

6. Qual a diferença entre cardinalidades mínimas

e cardinalidades máximas? Quais os valores
possíveis para cada tipo de cardinalidade?

7. Considerando as cardinalidades máximas, em

que tipos os relacionamentos podem ser clas-
sificados?

8. O que é um autorrelacionamento?

9. Quando devemos utilizar relacionamentos identifica-

dores?

10. Para que serve o conceito de generalização/especialização?

 PROJETO DE BANCO DE DADOS 50

MODELO
RELACIONAL
Você já deve estar se perguntando, como
funciona esse modelo que é base dos SGBDs!

O Modelo Relacional foi proposto por Codd (1970) como

resultado das pesquisas que realizava na IBM. É um modelo
formal, fundamentado nos conceitos de relações da Teoria dos
Conjuntos (matemática), logo, para o modelo relacional um
banco de dados é um conjunto de relações. Informalmente as
relações passaram a ser denominadas tabelas.

Toda tabela é um conjunto não ordenado de dados,

que possui um nome que a identifica e diferencia das outras
tabelas. Além disso, é formada por um conjunto de colunas
(campos) que também possuem um nome e são vinculadas a
domínios (tipos), que especificam os tipos de valores possíveis.
Assim, cada linha (tupla) da tabela, representa um conjunto
de valores de dados relacionados, os quais descrevem uma
ocorrência de uma entidade ou de um relacionamento.
 PROJETO DE BANCO DE DADOS 51

CHAVE ESTRANGEIRA
CHAVES
Uma chave estrangeira é um cam-
As chaves são estruturas que organizam os processos de manipulação das tuplas po em uma tabela que referencia a chave
das tabelas e de suas relações. Assim, os principais tipos de chave são: chave primária primária de outra tabela.
e chave estrangeira.
No exemplo a seguir: Na tabela
PESSOA a chave primária é o campo
CHAVE PRIMÁRIA
Código Pessoa e ela também tem uma
chave estrangeira, que é o campo Código
A chave primária de uma tabela é um campo ou conjunto de campos, que Cidade que referencia a chave primária da
permitem identificar e diferenciar cada linha (tupla) de uma tabela, dessa forma, tabela CIDADE.
um determinado valor de chave primária somente identifica uma única linha (tupla).

A seguir, podemos visualizar a tabela CIDADE e a sua chave primária, o

campo Código Cidade.
 PROJETO DE BANCO DE DADOS 52

INTEGRIDADE DE IDENTIDADE

A integridade de identidade é uma

regra que define que chave primária é a
identidade da tabela. Nesse caso, cada
tupla (linha) da tabela deve ter um valor
diferente nesse campo (ou conjunto de
campos, caso a chave primária seja com-
posta). Essa regra tem impacto sobre as
operações de inclusão e alteração de tuplas
(linhas) na tabela:

• Inclusão: Quando uma nova tupla

(linha) for inserida na tabela, pri-
Assim é possível intuir que a pessoa de código 100 (Cabral) mora na cidade
meiro é verificado se o valor da cha-
de código 2, que é Bento Gonçalves. Já a pessoa de código 101 (Colombo) mora na
ve primária da nova tupla (linha) é
cidade de código 1, que é Caxias do Sul. Logo, percebemos que a chave estrangeira
diferente de todos os valores desse
é a forma de relacionar as tabelas, efetivar suas ligações.
campo em todas as tuplas (linhas)
da tabela, se for diferente a nova
RESTRIÇÕES DE INTEGRIDADE tupla será incluída na tabela, caso
contrário será informado um erro e
a nova tupla não será inserida.
As restrições de integridade são regras que os SGBD relacionais devem cumprir
para atender as especificações do Modelo Relacional e garantir a correção do banco
• Alteração: Quando uma tupla (li-
de dados.
nha) for alterada na tabela, primeiro
é verificado se o valor da chave pri-
mária alterado é diferente dos va-
 PROJETO DE BANCO DE DADOS 53

lores desse campo nas outras tuplas INTEGRIDADE REFERENCIAL campo, que é chave estrangeira de
(linhas) da tabela, se for diferente uma tupla, antes de efetivar a alte-
a tupla (linha) será alterada, caso ração é verificado se o valor deste
contrário, será informado um erro A integridade referencial é uma re- campo possui correspondência com
e a tupla não será alterada. gra que define que o valor do campo, que algum dos valores do campo, que é
é chave estrangeira em uma tabela, deve chave primária na tabela referen-
Assim, consideremos a seguinte ser um dos valores que são chave primária ciada, se isto for verdadeiro a tupla
tabela de Cidades e as tuplas (linhas) já na tabela referenciada ou deve ter o valor poderá ser alterada, caso contrário
inseridas nela: NULL (vazio), caso os requisitos da apli- será gerado um erro e indicado que
cação permitam. Esta regra tem impacto não há correspondência do valor da
sobre as operações de inclusão, alteração chave estrangeira.
e exclusão de tuplas.
• Exclusão: quando for solicitada a
• Inclusão: quando for inserida uma exclusão de uma tupla em uma ta-
tupla em uma tabela em que um dos bela que é referenciada, por chave
campos é chave estrangeira, antes estrangeira em outra tabela, é veri-
de efetivar a inclusão é verificado ficado se o valor da chave primária
se o valor deste campo possui cor- da tupla a ser excluída é referenciado
Agora, suponhamos que se deseja respondência com algum dos valo-
incluir uma nova tupla (linhas) com as res do campo, que é chave primária
seguintes informações: código cidade = 3 na tabela referenciada, se isto for
e descrição = Farroupilha. Essa nova tupla verdadeiro, a nova tupla poderá ser
não será inserida na tabela, pois não atende incluída, caso contrário será gera-
à restrição de integridade de identidade do um erro e indicado que não há
tentando incluir uma nova tupla com um correspondência do valor da chave
valor de chave primária que já existe na estrangeira.
tabela.
• Alteração: quando for alterado o
 PROJETO DE BANCO DE DADOS 54

por algumas das tuplas, onde é chave estrangeira em outra tabela, se for a tupla • Se tentarmos excluir uma tupla da
não será excluída, caso contrário será permitida a exclusão. tabela CIDADE, aquela em que o
Código Cidade = 2. O SGBD de-
Consideremos as seguintes tabelas para compreender a integridade referencial, verá gerar um erro de integridade
onde na tabela PESSOA, a chave primária é o campo Código Pessoa e possui uma referencial, pois o valor dessa chave
chave estrangeira, Código Cidade, que referencia a Tabela CIDADE, que tem como primária é referenciado por pelo me-
chave primária o campo Código Cidade: nos uma tupla na tabela PESSOA
e, portanto, esta tupla não será ex-
cluída.

INTEGRIDADE DE DOMÍNIO

A integridade de domínio é uma

regra que define que os valores de um
campo devem ser compatíveis com o do-
• Se tentarmos incluir uma nova tupla na tabela PESSOA com as seguintes mínio que foi determinado para o campo.
informações: Codigo Pessoa = 104, Nome = Wagner e Código Cidade = 5. Um domínio define o conjunto de valores
O SGBD deverá gerar um erro de integridade referencial, pois não existe na possíveis e este pode ser um domínio con-
tabela CIDADE uma tupla em que o Código Cidade seja igual a 5. Portanto, tínuo (exemplo: números reais, números
esta tupla não será incluída. inteiros, alfanumérico, etc.), ou pode ser
um domínio discreto, que especifica um
• Se tentarmos alterar uma tupla na tabela PESSOA, alterando a tupla em que conjunto finito de valores possíveis para
o Código Pessoa = 101, alterando o campo Código Cidade para o valor 6. o campo (exemplo: sexo masculino ou fe-
O SGBD deverá gerar um erro de integridade referencial, pois não existe na minino). Assim, antes de qualquer ope-
tabela CIDADE uma tupla em que o Código Cidade seja igual a 6. Portanto, ração de inclusão ou alteração de tuplas,
esta tupla não será alterada. o SGBD deve verificar a integridade de
domínio, e caso algum campo tenha va-
 PROJETO DE BANCO DE DADOS 55

lores incompatíveis, a operação não pode sibilita uma visão resumida, e ao mesmo • Os campos que forem opcionais (que
ser realizada e deve ser informada uma tempo, bastante completa do esquema podem receber o valor nulo) serão
mensagem de erro. relacional. precedidos do símbolo °:

INTEGRIDADE DE VALORES NULOS Nossa descrição textual utilizará as • Tabela(ChavePrimária, campo,

seguintes notações:
A integridade de valores nulos defi-
ne que os campos que não forem definidos
como obrigatórios podem receber o valor
NULL (Nulo ou Vazio). Por outro lado,
campos obrigatórios não podem receber
o valor NULL. O SGBD deve fazer essa
verificação e informar as situações de erro,
caso ocorram. A chave primária de uma
tabela nunca pode receber o valor NULL.
ESPECIFICAÇÃO RESUMIDA
DE UM ESQUEMA
RELACIONAL
°campoopcional..., # ChaveEs-
trangeira, ...)
• Cada tabela será definida por um
nome e entre parênteses serão de- A seguir, apresentamos um pequeno
finidos os campos que compõe a esquema relacional para exemplificar essa
tabela: notação textual:
• Tabela (Campo1, Campo2, ..., Pessoa(CodigoPessoa, nome, da-
CampoN) taNascimento, °email, °telefone, #Codi-
goCidade)
• O campo (ou campos) que compõem
a chave primária da tabela serão su- Cidade(CodigoCidade, descrição,
blinhados: DDD, #SiglaUF)
• Tabela(ChavePrimária, campo, UnidadeFederativa(SiglaUF, des-
...) crição)

Existem muitas formas de especi- • O campo (ou campos) que compões

ficar um Esquema Relacional, que é o
projeto de uma base de dados Relacional.
Alguns utilizam representações gráficas
e outros descrições textuais. Optaremos
aqui, por uma descrição textual que pos-
NORMALIZAÇÃO DE BANCO
uma chave estrangeira serão prece-
didos do símbolo #: DE DADOS
• Tabela(ChavePrimária, campo, A normalização de banco de da-
..., # ChaveEstrangeira, ...) dos consiste em um conjunto de regras,

as quais devem ser válidas para todas as
tabelas de um banco de dados. Essas re-
gras visam garantir a correta estruturação
do banco de dados, garantindo que seja
íntegro, facilite a realização das operações
(inclusão, alteração, exclusão e consultas),
amplie a disponibilidade das informações
durante a realização dessas operações, além
de evitar a redundância de dados.
O processo de análise da norma-
lização de um banco de dados deve ser
realizado seguindo a sequência das formas
normais, onde cada forma normal especi-
fica uma regra que a tabela deve cumprir.
Se a tabela não estiver em conformidade
com a regra, deve ser transformada para
que se adeque a ela. O processo de nor-
malização pode ser aplicado em uma base
de dados relacional que já esteja em uso
com o objetivo de avaliar a sua qualidade
e reestruturá-la, a fim de que atenda as
regras de normalização.
PRIMEIRA FORMA NORMAL
A primeira forma normal (1FN)
PROJETO DE BANCO DE DADOS 56
especifica que todos os atributos de uma TERCEIRA FORMA NORMAL
tabela devem ser atômicos, isso significa
que em cada tupla da tabela, cada atri- A terceira forma normal (3FN) es-
buto pode receber somente um valor. Se pecifica que as tabelas devem estar livres
na tabela existirem atributos que podem de dependências funcionais transitivas.
receber mais de um valor, eles devem ser Esse tipo de dependência ocorre quan-
extraídos e em alguns casos dar origens a do campos que não fazem parte da chave
novas tabelas. primária dependem funcionalmente de
outros campos que também não são chave.
SEGUNDA FORMA NORMAL Assim, esses campos também devem ser
retirados da tabela e se necessário construir
novas tabelas.
A segunda forma normal (2FN)
especifica que todos os atributos de uma
tabela devem depender, funcionalmente,
de toda a chave primária da tabela, não
permitindo que ocorram dependências
funcionais parciais, ou seja, que algum
atributo dependa funcionalmente ape-
nas de parte da chave primária da tabela.
A análise dessa regra somente é realiza-
da quando a chave primária da tabela é
composta por 2 ou mais campos. Quando
algum atributo possui um dependência
funcional parcial ele deve ser retirado da
tabela e às vezes é necessária a criação de
nova tabela.
FAZENDO UM AUTOESTUDO!

1. O principal elemento do Modelo Relacional é a Tabela, assim,

descreva o que é uma Tabela.

2. Para que serve a chave primária de uma tabela?

3. Com qual objetivo são colocadas chaves estrangeiras

em uma tabela?

4. Qual a importância das restrições de integridade?

5. O que define a integridade de identidade?

6. Por que um SGBD Relacional precisa da inte-

gridade referencial?

7. É possível dizer que a integridade de domínio

está relacionada aos tipos de dados?

8. O que são valores nulos?

9. Qual o objetivo da normalização de dados?

10. Conceitue e diferencie 1FN, 2FN e 3FN.

 PROJETO DE BANCO DE DADOS 58

MAPEAMENTO
ER → RELACIONAL
E agora! O que eu faço com esses dois
modelos: entidade-relacionamento e
relacional?
Depois de construir um Diagrama Entidade-Relaciona-
mento (DER), que constitui-se na etapa de projeto conceitual
do banco de dados, pode-se fazer o mapeamento deste para
um esquema conceitual relacional.

O processo de mapeamento deve iniciar pelas entida-

des e depois podem ser mapeados os relacionamentos, não é
necessário mapear todas as entidades para depois mapear os
relacionamentos, podemos mapear as entidades que participam
de um relacionamento e depois se pode mapear este relacio-
namento e, assim, progressivamente mapear todo o diagrama
ER para um esquema de dados relacional. Mapear um dia-
grama ER para um esquema relacional significa especificar
as tabelas, seus campos, chaves primárias e estrangeiras.
 PROJETO DE BANCO DE DADOS 59

A seguir, estudaremos as técnicas identificador Código Livro, e os outros

para mapear cada um dos conceitos Mo- atributos comporão os campos da tabela.
delo Entidade-Relacionamento para es-
truturas do Modelo Relacional.
CÓDIGO AUTOR
AUTOR NOME
MAPEAMENTO DE
ENTIDADES
AUTOR (CodigoAutor, Nome)
Toda entidade será mapeada para
uma nova tabela, de forma que o atributo Nesse exemplo, temos a entidade
identificador será a chave primária da ta- Autor que deve ser mapeada para uma
bela e os outros atributos serão os campos Tabela. A chave primária será o atributo
da tabela. identificador Código Autor, e os outros
atributos comporão os campos da tabela.
CÓDIGO LIVRO
TÍTULO MAPEAMENTO DE
RESUMO RELACIONAMENTOS DO TIPO
LIVRO QUANTIDADE PÁGINAS
(N:N)
EDIÇÃO
ANO
Todo relacionamento do tipo (N:N)
LIVRO (CodigoLivro, Titulo, Re- será mapeado para uma nova tabela, de
sumo, QuantidadePaginas, Edicao, Ano). forma que a chave primária desta tabe-
la será composta pela junção das chaves
Nesse exemplo, temos a entidade primárias das tabelas derivadas das enti-
Livro que deve ser mapeada para uma dades que participam do relacionamento,
tabela. A chave Primária será o atributo juntamos a ela o atributo identificador do
 PROJETO DE BANCO DE DADOS 60

relacionamento, se houver, e os outros atributos como campos da tabela (se existirem).

O exemplo a seguir é de um relacionamento do tipo (N:N), onde um AUTOR

não é obrigada a estar relacionado com um livro, mas pode escrever diversos livros;
já um LIVRO é obrigado a ter no mínimo um autor e pode ter diversos autores que
o escreveram. Assim, de maneira simplificada, um livro pode ser escrito por diversos Perceba que na tabela LIVROAU-
autores e um autor pode escrever diversos livros, essa é a ideia de um relacionamento TOR:
(N:N).
• A chave primária é CodigoLivro +
CÓDIGO LIVRO CodigoAutor, é uma chave primária
TÍTULO composta por dois campos;
RESUMO (0, N) (1, N) CÓDIGO AUTOR
LIVRO ESCREVER AUTOR
QUANTIDADE PÁGINAS
NOME • #CodigoLivro indica que este cam-
EDIÇÃO
po é uma chave estrangeira que re-
ANO
ferencia a tabela LIVRO;
Para realizar o mapeamento do relacionamento, primeiro é necessário mape-
ar as entidades que ele interliga, depois é possível mapear o relacionamento. Nesse • #CodigoAutor indica que este cam-
exemplo, por ser um relacionamento (N:N), dará origem a uma tabela, em que a po é uma chave estrangeira que re-
chave primária será a composição da chave primária da tabela LIVRO com a chave ferencia a tabela AUTOR.
primária da tabela AUTOR, como não há outros campos no relacionamento, esta
tabela somente terá esses campos. Agora, considere o exemplo a seguir,
em que um relacionamento (N:N) possui
LIVRO (CodigoLivro, Titulo, Resumo, QuantidadePaginas, Edicao, Ano) atributos no relacionamento e um deles
também é um atributo identificador.
AUTOR (CodigoAutor, Nome)

LIVROAUTOR (#CodigoLivro, #CodigoAutor)

 PROJETO DE BANCO DE DADOS 61

DATA INÍCIO MANDATO

CÓDIGO CURSO CÓDIGO

(0, N) (0, N) COORDENAÇÃO
DESCRIÇÃO CURSO CORDENA COORDENADOR NOME

DATA FIM MANDATO

Para fazer esse mapeamento, devemos iniciar pelo mapeamento das entidades
e depois mapear o relacionamento:

CURSO (CodigoCurso, Descricao)

COORDENADOR (CodigoCoordenador, Nome)

CURSOCOORDENADOR (#CodigoCurso, #CodigoCoordenador, Da-

taInicio, DataFim)

Perceba que na tabela CURSOCOORDENADOR:

• A chave primária é CodigoCurso + CodigoCoordenador + DataInicio, é uma

chave primária composta por três campos;

• #CodigoCurso indica que este campo é uma chave estrangeira que referencia
a tabela CURSO;

• #CodigoCoordenador indica que este campo é uma chave estrangeira que

referencia a tabela COORDENADOR.
 PROJETO DE BANCO DE DADOS 62

MAPEAMENTO DE RELACIONAMENTOS DO TIPO (1:N) relacionamento, ou seja, CodigoUsuario

que é chave primária da tabela USUÁRIO.
Assim, o projeto das tabelas ficará:
Os relacionamentos do tipo (1:N) não são mapeados para uma nova tabela, o
processo consiste em adicionar uma chave estrangeira na tabela que está do lado N, USUÁRIO (CodigoUsuario, nome)
referenciando a chave primária da tabela que está do lado 1.
EMPRÉSTIMO (CodigoEmpres-
Considere o diagrama ER a seguir, que faz parte de um sistema de uma bi- timo, DataEmprestimo, DataEntrega,
blioteca, onde se fazem empréstimos de publicações e cada empréstimo é de somente #CodigoUsuario)
um usuário. É um exemplo de relacionamento (N:1). Para fazer o mapeamento do
relacionamento, primeiro se deve: Percebas que na tabela EMPRÉS-
TIMO:
CÓDIGO EMPRÉSTIMO
(0, N) (1, 1)
• #CodigoUsuario indica que este
DATA EMPRÉSTIMO CÓDIGO USUÁRIO
EMPRÉSTIMO FAZER USUÁRIO
DATA ENTREGA NOME
campo é uma chave estrangeira que
referencia a tabela USUÁRIO
Para fazer o mapeamento do relacionamento, primeiro se deve mapear as en-
tidades que participam do relacionamento: 5.4 MAPEAMENTO DE
RELACIONAMENTOS DO TIPO
USUÁRIO (CodigoUsuario, nome) (1:1)
EMPRÉSTIMO (CodigoEmprestimo, DataEmprestimo, DataEntrega)
Os relacionamentos do tipo (1:1) são
Depois que se analisa o relacionamento, visto que é um relacionamento do muito raros e normalmente são mapeados
tipo (N:1), o procedimento a ser realizado é adicionar um novo campo na tabela que pela fusão das tabelas ou como se fosse um
está do lado N do relacionamento, ou seja, EMPRÉSTIMO, colocando nessa, uma relacionamento do tipo (1:N).
chave estrangeira que referencie a chave primária da tabela que está do lado 1 do
 PROJETO DE BANCO DE DADOS 63

Considere o seguinte exemplo, onde um livro pode ter no máximo uma ficha caso, colocar a chave estrangeira na tabela,
cadastral e uma ficha cadastral é de exatamente um livro, ou seja, é um relaciona- que é obrigada a se relacionar com a outra,
mento (1:1). neste exemplo é a FICHACADASTRAL
que deve estar relacionada a no mínimo 1
CÓDIGO LIVRO
e no máximo 1 LIVRO.
TÍTULO
RESUMO (1, 1) (0, 1)
QUANTIDADE PÁGINAS LIVRO RELAÇÃO_1 FICHA
CÓDIGO FICHA
LIVRO (CodigoLivro, Titulo, Re-
CADASTRAL DESCRIÇÃO
sumo, QuantidadePaginas, Edicao, Ano)
EDIÇÃO
ANO
FICHACADASTRAL (Codigo-
Sempre, antes de mapear o relacionamento, é necessário mapear as entidades Ficha, Descricao, #CodigoLivro)
que participam dele:
Perceba que na tabela FICHACA-
LIVRO (CodigoLivro, Titulo, Resumo, QuantidadePaginas, Edicao, Ano) DASTRAL:
• #CodigoLivro indica que este cam-
FICHACADASTRAL (CodigoFicha, Descricao) po é uma chave estrangeira que re-
ferencia a tabela LIVRO.
Para mapear o relacionamento (1:1) temos duas alternativas:

a) Fazer a fusão das tabelas, nesse caso elegendo qual a mais relevante para o MAPEAMENTO DE
sistema e incorporando a outra. Nesse exemplo, a tabela mais relevante é LIVRO, AUTORRELACIONAMENTOS
assim a FICHACADASTRAL sofrerá a fusão e seus campos serão agregados à
tabela LIVRO: Os autorrelacionamentos seguem as
mesmas regras de mapeamento dos rela-
LIVRO (CodigoLivro, Titulo, Resumo, QuantidadePaginas, Edicao, Ano, cionamentos entre duas entidades, a única
CodigoFicha, DescricaoFicha) diferença é que em algumas situações será
necessário dar o nome dos papéis para as
b) A outra alternativa, é tratar o relacionamento como se fosse (N:1) e nesse chaves estrangeiras.
 PROJETO DE BANCO DE DADOS 64

Neste diagrama temos um autorrelacionamento do tipo (N:N), ou seja, um Pro- PRODU TOCOM P OSICAO
duto (Composto) não é obrigado a ter componentes e pode ter vários componentes e (#CodigoProdutoComposto, #Codi-
um Produto (Componente), o qual não é obrigado a fazer parte de uma composição, goProdutoComponente)
mas pode fazer parte de diversas composições.
Perceba que na tabela PRODUTO-
CODIGO PRODUTO (0, 1) COMPOSTO COMPOSICAO:
COMPOR
DESCRICAO PRODUTO (0, 1) COMPONENTE

• #CodigoProdutoComposto indica
que este campo é uma chave estran-
O mapeamento desse autorrelacionamento segue a mesma regra de mapea- geira que referencia a tabela PRO-
mento dos relacionamentos do tipo (N:N), ou seja, dará origem a uma nova tabela, DUTO
que deve herdar como chave primária as chaves primárias das tabelas relacionadas.
Começamos mapeando a entidade: • #CodigoProdutoComponente in-
dica que este campo é uma chave
PRODUTO (CodigoProduto, Descricao): estrangeira que referencia a tabela
PRODUTO
Agora, vamos mapear o relacionamento, neste caso criaremos uma nova tabela,
que decidimos chamar de PRODUTOCOMPOSICAO, e nela, devemos herdar as • A chave primária é CodigoPro-
duas chaves primárias das tabelas relacionadas, por se tratar de um autorrelaciona- dutoComposto + CodigoProduto-
mento, a tabela ficaria assim: Componente, é uma chave primária
composta por dois campos.
PRODUTOCOMPOSICAO (#CodigoProduto, #CodigoProduto)

Mas não podemos ter dois campos com o mesmo nome, por isso utilizaremos
os papéis para diferenciá-los:

PRODUTO (CodigoProduto, Descricao)


MAPEAMENTO DE
RELACIONAMENTOS
IDENTIFICADORES
O relacionamentos identificadores
relacionam uma entidade que depende de
outra para existir e ser identificada, por-
tanto, esta entidade dependente (também
denominada entidade fraca) dará origem DEPENDENTE que deve herdar a chave primária da tabela ASSOCIADO:
a uma nova tabela e deverá herdar a chave
primária da tabela a que está relacionada
pelo relacionamento identificar, a esta se
acrescenta o seu atributo identificador,
compondo assim, sua chave primária,
depois se adicionam os outros atributos
como campos.
Neste diagrama, a entidade DE-
PENDENTE está ligada a entidade
ASSOCIADO por um relacionamento
identificador. Assim, para mapear esse
diagrama devemos primeiro mapear a enti-
dade associada e depois mapear a entidade
dependente, através do relacionamento
identificador.
PROJETO DE BANCO DE DADOS 65
CÓDIGO EMPRÉSTIMO
DATA EMPRÉSTIMO
DEPENDENTE
(0, N)
POSSUIR
(1, 1)
ASSOCIADO
CÓDIGO USUÁRIO
DATA ENTREGA NOME
ASSOCIADO (CodigoAssociado, Nome, DataNascimento)
Depois de mapear a entidade associado, procede-se o mapeamento da entidade
DEPENDENTE ( #CodigoAssociado, NumeroDependente, Nome)
Perceba que na tabela DEPENDENTE:
• #CodigoAssociado indica que este campo é uma chave estrangeira que refe-
rencia a tabela ASSOCIADO
• A chave primária é CodigoAssociado + NumeroDependente, é uma chave
primária composta por dois campos.
MAPEAMENTO DE GENERALIZAÇÃO/ESPECIALIZAÇÃO
A generalização/especialização especifica uma hierarquia de entidades que
possui três alternativas de mapeamento. A escolha da alternativa depende do tipo de
informações que são representados por este conceito.
 PROJETO DE BANCO DE DADOS 66

Usaremos o mesmo diagrama ER para exemplificar essas alternativas de mapea- a. Todas as entidades da hierarquia
mento, nesse diagrama é apresentada uma hierarquia de generalização/especialização, dão origem às Tabelas: Neste caso,
onde a entidade generalizada é FUNCIONÁRIO que se especializa em ADVOGA- cada uma das entidades que com-
DO e MOTORISTA (entidades especializadas). Vamos analisar esta especificação: a põe a generalização/especialização
organização terá outros funcionários que não são advogados e nem motoristas? Sim, é mapeada em tabelas, conforme
mas não foram modeladas essas outras especializações, pois não possuíam informa- especificado no diagrama ER. Esta
ções próprias, precisando apenas dos dados de FUNCIONÁRIO. Além disso, todo é a forma mais recomendável de
ADVOGADO, neste diagrama, é um FUNCIONÁRIO, e todo MOTORISTA é mapeamento deste conceito. Nes-
um FUNCIONÁRIO. Também podemos considerar que ADVOGADOS podem se caso, as entidades especializadas
ser MOTORISTAS e vice-versa. devem herdar a chave primária da
tabela mapeada a partir da entidade
generalizada.

Iniciamos o processo de mapeamen-

CÓDIGO FUNCIONÁRIO
to transformando a entidade generalizada
NOME
em tabela, seguindo a regra normal de
FUNCIONÁRIO DATA NASCIMENTO
mapeamento de entidades para tabelas:

FUNCIONÁRIO ( CodigoFun-
cionario, Nome, DataNascimento )

HABILITAÇÃO Agora, vamos mapear as entidades

OAB
ADVOGADO MOTORISTA DATA EXPIRAÇÃO especializadas e para isso precisamos her-
ESPECIALIDADE
CATEGORIA dar a chave primária da tabela derivada da
entidade generalizada: CodigoFunciona-
rio, e acrescentar os atributos próprios da
entidade especializada.
 PROJETO DE BANCO DE DADOS 67

ADVOGADO ( #CodigoFuncio- à entidade generalizada, que passa a

nario, OAB, Especialidade) ter todos os atributos da hierarquia
de generalização/especialização.
MOTORISTA ( #CodigoFun-
cionario, Habilitacao, DataExpiracao, Essa solução possui o inconveniente
Categoria) de criar dados opcionais, pois quando um
funcionário não for advogado e nem mo-
a. Somente as entidades especiali- torista, esses dados ficarão nulos (vazios).
zadas dão origem a Tabelas: Neste
caso, a entidade generalizada não é FUNCIONÁRIO ( CodigoFun-
mapeada e todos seus atributos são cionario, Nome, DataNascimento, °OAB,
herdados por cada uma das entida- °Especialidade, °Habilitacao, °DataExpi-
des especializadas que dão origem racao, °Categoria)
a tabelas próprias.

ADVOGADO ( CodigoFuncio-
nario, Nome, DataNascimento, OAB,
Especialidade)

MOTORISTA ( CodigoFuncio- Ampliando nossos conhecimentos!

nario, Nome, DataNascimento, Habili-
tacao, DataExpiracao, Categoria) Mapeie os diagramas ER, construídos no
capítulo anterior, para esquemas de dados
a. Fusão dos atributos mapeando relacionais.
somente a entidade generalizada:
Neste caso, as entidades especializa-
das não são mapeadas para tabelas, e
todos os seus atributos são agregados
FAZENDO UM AUTOESTUDO!

1. Para que serve o mapeamento ER -> Relacional?

2. Como ocorre o mapeamento de entidades?

3. Como é feito o mapeamento de relacionamentos

N:N?

4. Como é feito o mapeamento de relacionamentos N:1?

5. Como é feito o mapeamento de relacionamentos 1:1?

6. Como é feito o mapeamento de autorelaciona-

mentos?

7. Como é feito o mapeamento de relacionamen-

tos identificadores?

8. Quais são as alternativas de mapeamento para

generalização/especialização?
 PROJETO DE BANCO DE DADOS 69

REFERÊNCIAS

KORTH, H. F.; SILBERS-

CHATZ, A.; SUDARSHAN, S.. Sistema
de Banco de Dados. 6ª ed., Elsevier, 2012.

HEUSER, Carlos Alberto. Projeto

de Banco de Dados. 6ª Ed., Bookman,
2008.

ELMASRI, R.; NAVATHE, S.

B.. Sistemas de Banco de Dados. 4a ed.,
Pearson-Addison-Wesley, 2005.

DATE, C. J.. Introdução a Siste-

mas de Banco de Dados. Elsevier Editora,
2004.