MODELAGEM DE DADOS

autor do original
GERALDO HENRIQUE NETO

1 edio
SESES
rio de janeiro 2015
Conselho editorial fernando fukuda, simone markenson, jeferson ferreira fagundes

Autor do original geraldo henrique neto

Projeto editorial roberto paes

Coordenao de produo rodrigo azevedo de oliveira

Projeto grfico paulo vitor bastos

Diagramao fabrico

Reviso lingustica aderbal torres bezerra

Imagem de capa nome do autor shutterstock

Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrnico ou mecnico, incluindo fotocpia e gravao) ou arquivada em
qualquer sistema ou banco de dados sem permisso escrita da Editora. Copyright seses, 2015.

Diretoria de Ensino Fbrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus Joo Ucha
Rio Comprido Rio de Janeiro rj cep 20261-063
Sumrio

Prefcio 7

1. Viso Geral: Banco de Dados e os Sistemas

de Gerenciamento de Banco de Dados (SGBD) 10

Viso geral: Banco de dados 11

Dados versus informao 12
Classificando os bancos de dados 13
Sistemas de Arquivos 16
SGBD (Sistema de Gerenciamento de Banco de Dados) 19
Os Usurios de Banco de Dados 22
O SGBD e suas Funcionalidades 24
Vantagens do SGBD 25

2. Projeto de Banco de Dados 32

Projeto de banco de dados 33

Modelo externo 34
Modelo Conceitual 36
Modelo interno 37
Modelo fsico 38
Modelo de dados 39
3. Modelo Entidade-Relacionamento 52

Modelo Entidade-Relacionamento 53
As Principais Caracteristicas do MER 57
Modelo Entidade-Relacionamento Estendido 65
Diagrama Entidade-Relacionamento (DER) 74
Modelando o negcio 80

4. Modelo de Dados Relacional 86

Modelo De Dados Relacional 87

Chave Primria (Atributo Identificador) 92
Restries de Integridade 94
Mapeamento do MER para o Modelo Relacional 102

5. Normalizao 122

Normalizao 123
Prefcio
Prezados(as) alunos (as)

A cada minuto, uma quantidade significativa de dados sero gerados, in-

dependentemente do cenrio, seja ele empresarial ou no. Com o surgimento
das mdias sociais a gerao de informaes cresceu de maneira avassaladora,
provenientes de diversas fontes distintas, a citar, smartphones, redes de relacio-
namentos, dentre outros.
Para atender adequadamente essa demanda, s tecnologias de banco de da-
dos, sobretudo o Big Data, o qual considerado um tema emergente que discor-
re sobre a evoluo das tecnologias de datawarehouse e business intelligence,
cujo objetivo proporcionar o armazenamento e anlise de dados, sejam esses,
estruturados, semiestruturados e ou no estruturados considerando grandes
volumes de dados.
Dessa maneira, considerando a importncia em se realizar um armazena-
mento adequado desses dados para a obteno do xito empresarial, indepen-
dentemente da regra de negcio, a disciplina Modelagem de Dados tem como
propsito explorar os principais assuntos acerca de banco de dados.
Para tanto, o contedo abordado na disciplina est segmentado da seguin-
te forma:
Captulo 1 estudaremos sobre o surgimento e a evoluo dos bancos de
dados, apresentando tambm as principais caractersticas dos Sistemas Geren-
ciadores de Bancos de Dados (SGBD).
Captulo 2 abordaremos as fases constituintes de um projeto de banco de
dados considerado bem estruturado.
Captulo 3 esmiuaremos o Modelo Entidade-Relacionamento detalhando
seus principais componentes.
Captulo 4 veremos os principais conceitos do Modelo de Dados Relacional.
Captulo 5 abordaremos as principais regras aplicadas ao processo de nor-
malizao de dados.

Bons estudos

Profo. Me. Geraldo Henrique Neto

7
 1
Viso Geral: Banco de
Dados e os Sistemas
de Gerenciamento
de Banco de Dados
(SGBD)
1 Viso Geral: Banco de Dados e os
Sistemas de Gerenciamento de Banco de
Dados (SGBD)
Previamente, antes de iniciarmos o estudo acerca da Modelagem de Dados, deve-
mos constituir uma base slida de conhecimentos triviais que sero imprescin-
dveis para elucidar os contedos futuros, permitindo, dessa forma, uma melhor
abstrao de outros conceitos gerais no que se refere Modelagem de Dados.
Acreditamos que voc desperte sua curiosidade e se prepare para comear os
estudos desta disciplina, estes, sem dvida, sero de grande relevncia para sua
formao profissional.
Voc se encontra preparado para conhecer os objetivos deste captulo?!

OBJETIVOS
Nesse primeiro captulo, exploramos os aspectos histricos relacionados aos bancos de da-
dos, sobretudo, sobre a sua evoluo desde o incio do seu surgimento at a atualidade. Co-
nhecer os Sistemas Gerenciadores de Banco de Dados (SGBD), realizando uma breve com-
parao sobre os SGBD e Sistemas de Gerenciamento de Arquivos. Estudaremos tambm
os principais usurios no nvel de banco de dados e, por fim, estudaremos as particularidades
do SGBD e suas principais funcionalidades.
Exploraremos, de maneira superficial, aspectos histricos, para que voc compreenda como
ocorreu a evoluo dos Sistemas de Gerenciamento de Banco de Dados, bem como, sua
necessidade, sendo assim, estudaremos as primeiras maneiras de administrao de dados,
por meio de arquivos e sistemas de arquivos, apresentando suas vantagens e desvantagens.

REFLEXO
Voc j deve ter ouvido falar muito em bancos de dados em diversos momentos de sua vida.
Mas o que so bancos de dados? De forma geral, arquivo em que se armazene dados pode
de alguma forma entrar nessa categoria. No entanto, de forma especfica, h formas eficientes
de se armazenar, gerenciar e acessar atravs de softwares e formatos de dados especficos.
Se voc nunca lidou com bancos de dados, deve estar se perguntando: Por onde comeo?.

10 captulo 1
1.1 Viso geral: Banco de dados

Ser que voc consegue identificar quais foram os motivos que levaram os a re-
alizao de investimentos macios nos estudos destinados ao armazenamento
de dados em meios mais acessveis e eficazes?
H tempos atrs, organizaes empresariais de pequeno, mdio e grande
porte gastavam cifras significantes de recursos financeiros na contratao de
um nmero expressivo de pessoas para trabalhar no processo de armazena-
mento e organizao de vrios arquivos, mencionar, arquivos referente as in-
formaes de clientes, produtos, funcionrios, produo industrial, etc.
Em meados da dcada de 70, a empresa intitulada de IBM, juntamente com
seu colaborador chamado de Ted Codd, considerado pioneiro na publicao de
um artigo cientfico, o qual discorria sobre banco de dados relacionais, sugeriu
o uso de clculo e lgebra relacional. Esses dois temas permitia aos usurios
finais a manipulao de informaes.
O objetivo principal de Codd era implementar um sistema onde fosse poss-
vel o usurio manipular as informaes, essas armazenadas em tabelas (relao),
esse o motivo do termo relacional, por meio do uso de instrues especficas.
Diversas pessoas consideraram no adequadas aplicar as notaes mate-
mticas de Codd na manipulao de informaes provenientes de tabelas, no
despertando assim, o interesse da maioria das pessoas. Entretanto, ningum
imaginava que as teorias propostas por Codd se tornaria conceitos triviais na
evoluo no que tange o armazenamento e recuperao de informaes.
Nesse mesmo perodo, a IBM criou o System R, o qual promoveu subsdios para
a elaborao de um prottipo de banco de dados relacional, conduzindo mais
adiante, a criao da linguagem SQL (Structured Query Language) e do conhecido
DB2. No restam dvidas que, na rea de banco de dados, a linguagem SQL con-
siderada um padro para os principais fabricantes de bancos de dados relacional.
Inoportunamente, a IBM deixou o System R em segundo plano por um gran-
de perodo (diversos anos). O interesse da IBM era em um sistema de banco de
dados com credibilidade que utilizava tecnologia de ponta, conduzindo, no ano
de 1968, o IMS. Assim, a IBM no mediu esforos em publicar os resultados dos
trabalhos cientficos produzidos pela sua equipe, ora responsvel pelo System
R. Posteriormente, o criador de uma pequena e singela empresa, Larry Ellison,
se deparou com o artigo publicado pela equipe da IBM, e, imediatamente, deu
incio ao processo de contratao dos desenvolvedores do System R e da Univer-

captulo 1 11
sidade da Califrnia. No ano de 1979, graas ao perfil empreendedor de Larry,
um novo banco de dados relacional com base na linguagem SQL foi lanado no
mercado, bem antes da conservadora IBM.
Uma verso de banco de dados intitulada de Oracle, em 1983, foi criada pela
empresa de Ellison, incrementando o faturamento anual em 5 milhes de dlares.

1.2 Dados versus informao

normal a utilizao da denominao informao, quando na verdade esta-

mos nos referenciando a um dado, ou at mesmo, um conjunto de dados. Na
prtica, nas empresas essa substituio se tornou relativamente normal. To-
davia, imprescindvel destacar que dado e informao, embora intimamente
ligados, possuem conceitos distintos. Saber diferencia-los importante, sobre-
tudo para a anlise da qualidade da informao.
Imagine que voc seja responsvel por identificar a satisfao de uma parcela
de usurios no que diz respeito a um sistema computacional especialista. Voc
poderia incialmente, obter essa informao realizando entrevistas aos usurios
do sistema, questionando os mesmos sobre determinados aspectos pontuais.
Pensando em facilitar seu trabalho, voc poderia elaborar um formulrio
on-line, disponibilizado na Web, permitindo a disseminao do mesmo entre
os diversos usurios. Posteriormente, ao armazenamento dos dados das in-
meras respostas provenientes do formulrio on-line, temos os dados em sua
forma bruta, isto , eles no possuem nenhum significado. Dessa maneira, ne-
cessitamos transforma-los em dados que possam gerar algum tipo de informa-
o. A lapidao dos dados brutos, torna o mesmo com maior valor agregado,
possibilitando extrairmos respostas objetivas e eficazes do repositrio, como
exemplo, podemos mencionar: O mdulo responsvel para gerao dos rela-
trios analticos so de fcil usabilidade?
Sendo assim, podemos contextualizar que quando os dados brutos so mani-
pulados adequadamente, podemos extrair o seu significado e, dessa forma, gerar
as informaes necessrias para uma possvel tomada de deciso.
Para alguns, esse tipo de processo de gerar informao a partir de dados
brutos, pode ser considerado simples, ou complexo, principalmente se consi-
derarmos a confeco de relatrios estatsticos.
Esse outro exemplo, refere-se a utilizar um dado que ora representa uma
temperatura qualquer. Nenhuma novidade de considerarmos 43 como sendo

12 captulo 1
um dado em sua forma bruta. Porm, nesse exemplo, 43 no est vinculado a
nenhuma informao, ou seja, no possui significado algum, ao menos que,
seu contexto seja evidenciado, como: Esse valor representa a temperatura da
cidade de Ribeiro Preto em plena primavera? Ou, esse valor de temperatura
a mdia de temperatura trimestral da regio metropolitana de So Paulo?
Dessa forma, correto dizer, que os dados constituem os pilares para que
alcancemos as informaes, tornando-se quesito extremamente importante
na tomada de deciso empresarial, independentemente da rea de atuao e
porte, sejam empresas governamentais, privadas e ou de prestao de servio.
Retomando nosso exemplo inicial, os dados provenientes das questes do
formulrio on-line, podem identificar os principais pontos favorveis ou no
favorveis do mdulo responsvel pela gerao de relatrios analticos, condu-
zindo a uma melhor tomada de deciso a fim de atender os principais aponta-
mentos de seus usurios.

1.3 Classificando os bancos de dados

Podemos classificar os bancos de dados de acordo com suas caractersticas e

aplicabilidade dos dados neles armazenados. Por exemplo, essa classificao
pode variar de acordo com o nmero de usurios, localizao, e, tipo de uso. Na
sequncia, correlacionaremos os principais tipos de banco de dados. impor-
tante mencionar que, em algumas literaturas, essa classificao pode possuir
discretas alteraes.
A primeira classificao baseada pelo nmero de usurios:
Banco de Dados Monousurio: esse tipo de banco de dados promove
o suporte de apenas um nico usurio por vez. Ou seja, para que voc
possa entender, imagine que o usurio Fernando Collor se encontra
utilizando o banco de dados, e os usurios Fernando Henrique e Paulo
Maluf, por sua vez, necessitam aguardar o usurio Fernando Collor fina-
lizar sua transao para obter o respectivo acesso ao mesmo repositrio
(banco de dados). Nesse tipo de banco de dados, no existe, em hiptese
alguma, o que denominamos de controle de concorrncia;
Banco de Dados Multiusurio: ao contrrio do banco de dados monousu-
rio, esse tipo de banco de dados d suporte e gerncia diversos usurios
simultaneamente.

captulo 1 13
 Na sequncia, apresentaremos outro tipo de classificao, essa considera a
localizao do banco de dados:
Banco de Dados Centralizado: realiza a centralizao dos dados em um
nico local fisicamente existente, realizando o devido suporte ao mesmo;
Banco de Dados Distribudo: nesse tipo de banco de dados o suporte
destinado a distribuio dos dados por diversos locais, esses, normal-
mente, residente em locais fisicamente distintos.

Uma das mais popular classificao de banco de dados refere-se em como os

dados so manipulados, respeitando sua evoluo no tempo, ou seja, gerencian-
do dados on-line e histricos. Essa classificao pode ser determinada como:
Banco de Dados Operacional: realiza o suporte a transaes empresa-
riais dirias. Esse tipo de banco de dados tambm pode ser classificado
como Banco de Dados Transacional ou, at mesmo, de Banco de Dados
de Produo;
Data Warehouse: esse tipo de banco de dados, a nfase no armazena-
mento de dados que promovem o suporte na extrao de informaes
valiosas no que se refere a tomada de deciso. A fim de conduzir adequa-
damente essas decises, os dados carecem de tratamento especfico, ou
seja, torna-se necessrio realizar tratamento, cujo objetivo a obteno
de informaes valiosas, a citar, avaliao semestral de venda de uma de-
terminada regio, dentre outros. Um Data Warehouse possui a estrutura
bem diferente do Banco de Dados Operacional, por tornar gil o acesso
a esses dados;
Banco de Dados Temporal: esse tipo de banco de dados permite que os usu-
rios manipulem os dados de acordo com suas necessidades, permitindo
assim o armazenamento de todo o histrico das modificaes aplicadas aos
dados. Para exemplificar, considere aplicaes que necessitam de promo-
ver o controle de acesso aos dados temporais, como: sistemas mdicos (evo-
luo dos tratamentos aplicados aos pacientes), sistemas empresariais (sis-
temas financeiros, monitoramento da produtividade, gesto de RH, etc.),
sistemas de informaes geogrficas (SIG), dentre outros;
Banco de Dados Espacial: permitem recuperar objetos considerando
um espao multidimensional. Um caso especial desse tipo de banco de
dados o banco de dados geogrfico, por garantir o armazenamento de
dados referente a localizao de rios, municpios, estados, rodovias, etc.;

14 captulo 1
 Banco de Dados Meteorolgico: pela sua prpria nomenclatura, refere-
se a um tipo de banco de dados que armazena dados sobre o tempo (tem-
peratura, umidade do ar, velocidade do vento, etc.);
Banco de Dados Multimdia: so normalmente direcionados ao arma-
zenamento e manipulao de dados considerados no convencionais,
como, imagens, vdeos, msicas, etc.;
Banco de Dados Especialista: voc poder encontrar, em algumas litera-
turas, um outro nome aplicado a esse tipo de banco de dados (banco de
dados/sistemas baseados em conhecimento). Esse tipo de banco mistu-
ra raciocnio e inferncia, por meio do uso de inteligncia artificial.
ainda possvel classificarmos os bancos de dados levando em considera-
o como os dados esto estruturados. Um dado no estruturado considerado
como sendo um dado em sua forma original, isto , em sua forma bruta, sem
nenhum tipo de lapidao/tratamento. Para tanto, esse tipo de dado no permi-
te que realizemos o devido processamento para alcanarmos a valiosa informa-
o agregada nele. Ao contrrio, dado estruturado pode ser considerado como
o resultado de um processo que utilizou dados no estruturados, atendendo a
uma pr-formatao, criando facilitadores no que se refere ao armazenamento,
a manipulao e obteno de informao.
Em ambientes empresariais, certamente voc ir se deparar com o armaze-
namento e manipulao de dados semiestruturados, ou seja, um tipo de dado
parcialmente processado. Atualmente, existe uma demanda considervel para
armazenar e gerenciar dados no estruturados e semi-estruturados, conduzin-
do ao surgimento de mais uma nova vertente de banco de dados, os intitulados
de Banco de Dados XML (Extensible Markup Language).
Para encerrar esse tpico, devemos deixar explcito que os termos banco de da-
dos e base de dados no podem ser considerados como sinnimos, isso porque,
uma base de dados, normalmente, gerenciado por ferramentas de suporte a de-
ciso empresarial, como exemplo, podemos mencionar, o sistema ERP (Enterprise
Resource Planning). Entretanto, o gerenciamento de um banco de dados ou um
conjunto de banco de dados promovido pelo uso de um sistema de gerenciamen-
to de banco de dados (SGBD).

captulo 1 15
1.4 Sistemas de Arquivos

Voc j se deparou com as siglas FAT, FAT32, NTFS? Algo familiar para voc?
Bem, pois fique voc sabendo que essas siglas tm um propsito em comum, e,
ser que voc saberia me responder?
Os sistemas de arquivos, ora relacionados acima por meio das siglas FAT,
FAT32, NTFS, por exemplo, possuem como objetivo comum realizar a organi-
zao e armazenamento de dados em sistemas de informao computacionais,
formando dessa maneira, os dois principais sistemas para gerenciamento e
controle de informao, a citar, o prprio sistema de arquivos e o sistema de
gerenciamento de banco de dados (SGBD).
Sistemas de arquivos o mecanismo utilizado para organizar e armazenar da-
dos por meio de uma estrutura lgica, essa responsvel pela alocao fsica dos ar-
quivos em dispositivos de armazenamento (disco rgido, memria flash, CD-ROM,
DVD-ROM, dentre outros.). Bem, para que voc possa abstrair ainda mais esse con-
ceito, considere um sistema de arquivos como sendo uma estrutura responsvel
por delimitar como os arquivos sero efetivamente gravados e armazenados em
qualquer dispositivo de armazenamento.
Um detalhe tambm considerado importante para o conceito ora exposto,
que todo esse controle destinado ao acesso aos dispositivos de armazenamento
promovido pelos sistemas operacionais, a citar, MS-DOS, Windows, Linux e
Unix. Basicamente, a maioria dos sistemas de arquivos faz uso dos recursos de
armazenamento de dados os quais utilizam vrios blocos nomeados de setores,
esses com tamanhos j pr-definidos.
No temos dvidas que voc, eventualmente, utiliza um desses sistemas de
arquivos FAT (File Allocation Table), FAT32 e NTFS (New Technology File Sys-
tem), da famlia dos sistemas operacionais da Microsoft. E da? Voc quer saber
qual realmente a diferena existente entre esses sistemas de arquivos? Nosso
objetivo no esmiuar esses detalhes, e sim, promover uma viso resumida, isto
, a principal diferena ente esses sistemas de arquivos est relacionada s limita-
es da tecnologia que por sua vez, foram evoluindo com o transcorrer do tempo,
bem como a inevitvel melhoria da segurana e capacidade de armazenamento.

16 captulo 1
 Bem, agora imagine que voc tenha a necessidade de gravar um vdeo (filme
de DVD) em uma mdia de armazenamento especfica, para exemplificar, o seu
prprio Pen-Drive. Voc tem ideia de como o sistema de arquivo ir trabalhar?
Antes de qualquer coisa, necessrio conhecer o funcionamento de um sistema
de arquivo, que utiliza um tipo de tabela para armazenar todos os detalhes da lo-
calizao dos dados de cada arquivo. Por exemplo, o sistema de arquivo FAT frag-
menta a rea do dispositivo de armazenamento em pequenos blocos, permitin-
do assim que um nico arquivo possa ocupar diversas posies distintas, onde,
esses blocos, necessariamente, no necessitam estar alocados continuamente.
Podemos considerar que os sistemas de arquivos foram os pioneiros no que
se refere aos sistemas de armazenamento e manipulao de dados. Tais siste-
mas sofreram melhorias ao longo de dcadas, cujo objetivo era acompanhar a
evoluo tecnolgica. Entretanto, infelizmente, alguns problemas podem ser
caracterizados, a citar:
A estrutura de arquivos definida pelo prprio cdigo-fonte do sistema
computacional, prejudicando consideravelmente sua manuteno;
O controle de acesso desses arquivos apresentam grandes obstculos
quando mencionamos o compartilhamento;
A falta de compatibilidade entre os sistemas computacionais prejudica
consideravelmente a funcionalidade dos sistemas, pelo simples fato de
criar arquivos e sistemas voltados a um nico e exclusivo sistema ope-
racional, e que, na maioria das vezes so realizados por diversos desen-
volvedores distintos que utilizam linguagens de programao dspares;
Sistemas computacionais com dados distintos conduz a inconsistncia
dos mesmos;
O uso de formatos especficos acarreta o isolamento de dados;
A duplicidade no supervisionada dos dados leva a redundncia dos
mesmos;
O fcil acesso aos dados direciona a srios problemas de segurana;
A falta de controle de acesso concorrente promovido por diversos usu-
rios acessando o mesmo dado.

captulo 1 17
 A Figura 1.1 abaixo apresenta um exemplo do armazenamento de dados por
meio de sistemas de arquivos. Verifique que, toda a segurana e controle de
acesso aos dados so de responsabilidade da aplicao.

Figura 1.1 Esquema Simplificado do Sistema de Arquivos

Uma dvida que pode ter surgido em voc, diz respeito se a utilizao de sis-
temas de arquivos no gerenciamento e manipulao dos dados uma boa alter-
nativa, nos dias de hoje? Para que voc possa contextualizar ainda mais os pro-
blemas provenientes do uso de sistemas de arquivos, principalmente, o que se
refere inconsistncia e controle de acesso, suponha que dois clientes estejam
buscando produtos ora disponveis para comercializao em um e-commerce
qualquer. Ainda para agravar a situao, o e-commerce possui apenas uma ni-
ca unidade de um DVD, e, prontamente, o sistema apresenta essa informao
para ambos os clientes. Ao mesmo tempo, os dois clientes escolhem o mesmo
DVD para aquisio. Percebe-se que essa simples transao acarretar em pro-
blema no sistema, promovendo a inconsistncia dos dados. Esse problema que
gerou a inconsistncia foi produzido devido ausncia de bloqueio da compra
de um dos clientes, e a exibio de uma mensagem informando que no existe
mais o produto em estoque.
Dessa maneira, percebe-se que o armazenamento e manipulao de dados
por meio do uso de sistemas de arquivos podem levar a diversos dissabores. Esse
mesmo exemplo hipottico pode ser ampliado para outros tipos de sistemas, tais
como, sistemas bancrios, sistemas de hotelaria, sistemas hospitalares, etc..
Devido a alguns problemas apresentados pelo uso de sistemas de arquivos
para o armazenamento de dados, e, pela necessidade de utilizar novas estrutu-
ras de armazenamento nesses sistemas computacionais, como tambm, o alto
custo aplicado na manuteno para solucionar esses dissabores, criou-se a evo-
luo dos sistemas de arquivos, os extraordinrios sistemas de gerenciamento
de banco de dados (SGBD), que utilizam novas estruturas para o armazenamen-

18 captulo 1
to e gerenciamento dos dados.
A seguir, iniciaremos um estudo detalhado acerca dos sistemas de gerencia-
mento de banco de dados, apresentando suas principais vantagens em relao
aos sistemas de arquivos.

1.5 SGBD (Sistema de Gerenciamento de Banco de Dados)

Um Sistema de Gerenciamento de Banco de Dados (SGBD) constitudo por

um conjunto de aplicativos que possibilitam a criao e manipulao de diver-
sos bancos de dados. Como exemplo de SGBDs mais utilizados no mercado,
podemos citar o MySQL, Oracle, FireBird, DB2, SQL Server e PostgreSQL.
Quando se utiliza um SGBD, o acesso e o gerenciamento dos dados so pro-
movidos pelo prprio SGBD, diferenciando-se do armazenamento e gerencia-
mento de dados por meio de sistemas de arquivos. Ou seja, se assemelha a uma
interface inserida entre o banco de dados fsico (discos, mdias de armazena-
mento, etc.) e os usurios. Como voc pode visualizar na Figura 1.2, o SGBD
recebe todas as requisies de inmeras aplicaes computacionais, realiza a
devida interpretao a fim de melhor atende-las, escondendo a complexidade
interna existente dos bancos de dados dos usurios finais.

CONEXO
SGBD uma coleo de aplicativos computacionais responsveis pelo gerenciamento de
uma conjunto de banco de dados. (Rob et al., 2011).

Figura 1.2 Esquema Simplificado do Sistema Gerenciador de Bancos de Dados

captulo 1 19
 Tais aplicativos, normalmente, so desenvolvidos por uma equipe de desen-
volvedores atravs da utilizado de uma linguagem de programao especfica,
como podemos mencionar: Java, PHP, C/C++, Pascal, C#, etc. ou, esporadica-
mente, constitudos a partir do uso de mdulos proprietrios de um SGBD,
como exemplo, podemos evidenciar o Forms e Reports da prpria Oracle.
Voc j deve ter percebido que os dados so caracterizados como sendo a
matria bruta e imprescindvel para que alcancemos qualquer tipo de informa-
o, impulsionando ainda mais a necessidade de utilizarmos mtodos eficien-
tes e eficazes para manipula-los.
Algumas vantagens na utilizao de um sistema de gerenciamento de banco
de dados associados aos aplicativos computacionais podem ser evidenciados,
a citar, o SGBD, diferentemente do sistema de arquivo, possibilita, de maneira
facilitadora, o compartilhamento dos dados para diversos sistemas e usurios;
tambm permite a integrao das vrias vises de dados de cada usurio em um
nico repositrio de dados; fornece tambm modelos capazes de incrementar
de maneira significativa a privacidade e segurana dos dados e por fim, auxilia
na reduo de eventuais inconsistncias dos dados.
Informaes de qualidade so, normalmente, oriundas de um processo de
manipulao e gerenciamento de dados bem sucedidos, que por sua vez, criam
subsdios para uma melhor tarefa de tomada de deciso empresarial. Essas
vantagens elucidadas acima, no que tange a utilizao de um SGBD no se li-
mitam a apenas esses fatores. No temos dvida que ao longo do processo de
aprendizagem, como tambm, de sua via profissional, voc ir se deparar com
diversas outras vantagens ao esmiuar os detalhes dos bancos de dados, sobre-
tudo, na escolha de um projeto adequado na aquisio do mesmo.

CONEXO
Leia sobre a relao: Dados-Informao-Conhecimento em: http://www.ime.usp.br/~vwset-
zer/dado-info-Folha.html
Este outro artigo trata sobre Inteligncia Competitiva das Organizaes, pautando-se na re-
lao que estudamos:

20 captulo 1
 Os usurios dos SGBDs sejam eles, usurios finais, programadores e admi-
nistradores de banco de dados, em sua rotina diria, necessitam de extrair co-
nhecimento e pleno controle dos recursos disponveis para usufruir totalmente
de todos os seus benefcios, tais como, podemos evidenciar:
Maior velocidade em produzir acesso aos dados;
Solucionar problemas provenientes da ausncia de integridade e redun-
dncia de dados;
Simplicidade na criao e gerenciamento de bancos de dados;
Certificar-se se os dados esto disponveis para a distribuio fsica.

Infelizmente, a ausncia de conhecimentos triviais dos recursos dispon-

veis dos SGBDs pode promover uma pssima manipulao dos dados e, inevi-
tavelmente, provocar falhas no acesso, produzindo assim, o que denominamos
de falha de segurana.
Aps o surgimento dos SGBDs, todo aquele trabalho desempenhado pelos
programadores para realizar o devido controle de acesso aos dados, implemen-
tar a integridade e evitar redundncia dos dados, felizmente, deixaram de ser
necessrios, entretanto, se considerarmos alguns itens, os sistemas de arqui-
vos podem possuir benefcios superiores aos SGBDs. No tenha dvida que essa
afirmao lhe parece muito estranha, mas por mais bizarro que ela possa ser, a
performance, quando utilizamos sistemas de arquivos, considerada superior
em relao ao dos SGBDs, isso porque realizado a implementao especfica
e exclusiva destinada a uma determinada aplicao, j os SGBDs so utilizados
por aplicaes consideradas genricas, visto que, o objetivo atender diversas
e variadas necessidades.

ATENO
Vimos que dado e informao no so sinnimos, e que a informao resultante de um
processamento aplicado no dado bruto, considerando um determinado contexto, ou seja, a
informao o dado atribudo a um determinado significado, assim temos:
Informao = (dado + significado).

captulo 1 21
1.6 Os Usurios de Banco de Dados

Nesse tpico, evidenciaremos os principais tipos de usurio que lidam com

banco de dados. Na maioria das literaturas existentes acerca de banco de da-
dos, podemos encontrar quatro tipos distintos de usurios de banco de dados,
os quais so diferenciados exclusivamente pela forma como interagem com o
sistema de banco de dados. Existem tambm, associado a esse conceito, vrios
tipos de interfaces, essas normalmente, projetadas para atender os diversos ti-
pos de usurios. A seguir, esmiuaremos os quatro tipos de usurios, dando
exemplos de suas principais atribuies:
Usurios finais: esse tipo de usurio no possui conhecimento avanado,
e, normalmente estabelecem interao com o banco de dados por meio
do uso de aplicaes computacionais previamente implementada. Como
exemplo, imagine um caixa bancrio que necessita realizar a transferncia
de R$ 100,00 de uma conta corrente X para outa conta corrente Y. Nesse
caso, o usurio final, o caixa da instituio financeira, necessitar invocar
o aplicativo para que seja possvel realizar a transferncia do valor. Por
outro lado, esse aplicativo solicita ao usurio final (o caixa da instituio)
o valor e a conta para a qual o dinheiro ser transferido. Tomamos como
outro exemplo, um usurio final que deseja consultar seu saldo bancrio
por meio do uso de um aplicativo Web (Home Bank). Esse usurio dever
acessar um formulrio, no qual ser necessrio a insero do nmero de
sua agncia, conta corrente e senha, para identificao do mesmo. Um
aplicativo residente no servidor Web, por sua vez, recupera o saldo da con-
ta corrente, utilizando o nmero da agncia e conta corrente informado
pelo usurio final, e apresentando essa informao para o mesmo. Nor-
malmente, a interface utilizada pelos usurios finais constituda por
formulrios, os quais o usurio pode inserir as variveis necessrias que
contemple o formulrio. Tambm possvel que usurios finais simples-
mente leia relatrios produzido pelo banco de dados;
Desenvolvedores de Aplicativos: tipo de usurio caracterizado por desenvol-
ver aplicativos computacionais. Os desenvolvedores de aplicativos selecio-
nam, entre diversas ferramentas disponveis, uma que mais lhe adeque a
fim de promover o auxlio no desenvolvimento de interfaces com o usurio.
Como exemplo, podemos correlacionar a ferramenta RAD (Rapid Applica-
tion Development), a qual permite que um determinado desenvolvedor de
aplicativos crie formulrios e relatrios sem muito esforo de programao;

22 captulo 1
 Usurios Avanados: so denominados de usurios avanados aqueles que
escrevem aplicaes voltadas a banco de dados especializados, ou seja,
aplicativos que normalmente no se acopla a estrutura de processamento
de dados convencional. Como exemplo desses aplicativos, podemos citar:
sistemas de base de conhecimentos, sistemas especialistas, sistemas que
armazenam e manipulam dados com tipos de dados considerados com-
plexos (som, vdeo e imagem) e sistemas de modelagem de ambiente.

Acredito que voc deve ter reparado que havamos comentado sobre quatro
tipos principais de usurios de banco de dados, e, correlacionamos acima apenas
trs tipos deles. No se preocupe, o ltimo usurio, intitulado de Administrador
de Banco de Dados merece uma nfase maior, se compararmos com os demais.
Um dos objetivos principais de utilizarmos um SGBD obtermos controle total
sobre os dados e os aplicativos que promovem o acesso aos mesmos. Um usurio
responsvel por promover esse controle sobre o SGBD chamado de administra-
dor de banco de dados (DBA). A seguir, apresentaremos suas principais atribuies:
Por meio do uso de um conjunto de instrues de definio de dados
(DDL), o DBA capaz de criar um esquema de banco de dados qualquer;
Estabelecer a estrutura de armazenamento, bem como definir mecanis-
mos de acesso aos dados;
Para melhorar o desempenho do banco de dados, o DBA poder reali-
zar mudanas no esquema e na organizao fsica, como tambm, para
atender eventuais necessidades especficas da empresa;
O administrador de banco de dados promove o controle de objetos ora
armazenados no banco de dados que os diversos usurios podem aces-
sar, concedendo distintos tipos de autorizao. Essas autorizaes, nor-
malmente so armazenadas e mantidas em uma estrutura especial a
qual o SGBD consulta sempre que algum usurio tenta acessar os dados;
Considerada como fundamentais, as atribuies de manuteno do banco
de dados, desempenhada pelo DBA so cruciais para promover a continui-
dade do sistema de banco de dados, a citar: realizao de cpias de seguran-
a (backups) periodicamente, independentemente dos dispositivos de ar-
mazenamento, ou at mesmo em servidores secundrios, a fim de prevenir
perda de dados em caso de anomalias, catstrofes, etc. Certificar a existn-
cia de espao suficiente em disco para desempenhar operaes convencio-
nais e, caso seja necessrio, incrementar o espao em disco. Para finalizar,
o DBA tambm dever monitorar tarefas processadas no banco de dados e

captulo 1 23
 garantir que o desempenho no seja afetado por outras tarefas sobrecarre-
gadas emitidas por alguns usurios.

1.7 O SGBD e suas Funcionalidades

Antigamente, as primeiras arquiteturas de SGBD utilizavam computadores de

grande porte, denominados mainframes. A utilizao do mainframe tornava-se ne-
cessrio para realizar processamento de todas as funes do sistema, isso inclua
os aplicativos, as interfaces com o usurio, bem como todos os demais processos
responsveis por prover as funcionalidades bsicas dos SGBDs. Grande parte dos
processamentos eram desempenhados de maneira remota, isso , somente os da-
dos a serem visualizados eram submetidos para os terminais de visualizao, ora
conectados ao mainframe por meio do uso de uma rede de comunicao.
Atualmente, identificamos o decremento do custo de aquisio de equipa-
mentos de hardware, porm, na contra mo, o aumento significante da capa-
cidade de processamento e armazenamento digna de nota. Isso favoreceu
imensamente a substituio dos terminais por computadores pessoais pelos
usurios. No incio, os SGBDs faziam uso dos computadores pessoais da mes-
ma forma que utilizavam os terminais, isto , o SGBD trabalhava de maneira
centralizada e toda as demais funcionalidades, como, a execuo de programas
aplicativos e processamento de interface do usurio eram processados em uma
nica e exclusiva mquina.
Com o transcorrer do tempo os SGBDs comearam a usufruir do processa-
mento existente do lado do usurio, que por sua vez, assumia o papel de clien-
te do SGBD. Essa filosofia conduziu a uma arquitetura denominada cliente/
servidor, que se destina a segmentar os processamentos provenientes dos apli-
cativos, esses localizados do lado do cliente e o gerenciamento dos dados, esse
sendo executado do lado do servidor.
Dessa forma, essa arquitetura cliente/servidor foi introduzida aos SGBDs
comerciais, promovendo o surgimento de diversas tcnicas para a implemen-
tao dessa arquitetura. As consultas SQL, juntamente com as funcionalidades
transacionais residem do lado do servidor, esse intitulado de servidor de con-
sulta ou servidor de transao. exatamente dessa maneira que as mquinas
clientes visualizam o servidor, como sendo um servidor SQL. Cada mquina
cliente responsvel por constituir suas consultas SQL e disponibilizar uma
interface com o usurio.

24 captulo 1
 Logo abaixo, podemos resumir algumas das arquiteturas triviais dos SGBDs:
Centralizada: essa arquitetura tem como caracterstica a existncia de
um computador com expressivo poder de processamento, que lhe pro-
porciona a centralizao dos processos do SGBD, como tambm, permite
funcionar como emulador para n aplicativos. Sua principal vantagem
possibilitar que diversos usurios manipulem significativas quantida-
des de dados e, como sua principal desvantagem, podemos citar, seu alto
custo de aquisio, sobretudo por exigir cenrio especial para mainfra-
mes e solues centralizadas;
Computador Pessoal (PC): essa outra arquitetura permite que computa-
dores pessoais trabalhem em sistema stand-alone, isso significa que, es-
ses PCs realizam seus prprios processamentos de maneira autnoma.
Bem no incio a adoo dessa arquitetura, o processamento era consi-
derado limitado, entretanto, com o transcorrer do tempo, paralelamen-
te com a evoluo substancial do hardware, atualmente possumos PCs
com larga escala de processamento. Como vantagem dessa arquitetura,
podemos considerar sua simplicidade;
Cliente-Servidor: j nessa arquitetura, o cliente intitulado de (front-end),
esse responsvel por executar tarefas do aplicativo, fornecendo uma inter-
face para usurio, seja por meio de telas ou processamento de entrada e
sada. O servidor por sua vez, assume o papel de (back-end), por simples-
mente executar as consultas no SGBD e devolve-las como resultado ao
cliente. Essa arquitetura muito popular, se compararmos com as de-
mais, vista at o presente momento. Um dos pontos fortes dessa arquite-
tura a segmentao do processamento por meio do uso de dois sistemas,
reduzindo consideravelmente o trfego de dados na rede de comunicao.

1.8 Vantagens do SGBD

Vimos que os SGBDs basicamente funcionam como servidores de dados que

por sua vez disponibilizam uma interface de comunicao a qual permite que
aplicativos computacionais estabeleam comunicao com ele. Utilizando-se
essa interface possvel que os aplicativos realizem a solicitao de insero,
alterao, recuperao ou organizao dos dados armazenados pelo SGBD.
Bem, voc deve estar se questionando: Ser que correto concluir que o SGBD
rene todos os processos organizacionais de uma empresa?

captulo 1 25
 A resposta correta sim! As empresas so subsidiadas pelos seus dados e
no processamento dos mesmos. No tenha dvida que o gerenciamento e tra-
tamento correto desses dados iro permitir relevantes tomadas de decises.
Nesse contexto, a informao gerada pelos dados possui um valor imensurvel
e, basicamente, todo esse cenrio computacional gerenciado pelo SGBD, des-
sa forma, tambm correto dizermos que o SGBD o corao para a grande
maioria das empresas. Para melhor abstrairmos todo esse conceito, podemos
visualizar por meio da Figura 1.3, como efetivamente o SGBD funciona:

Figura 1.3 Sistema de Gerenciamento de Banco de Dados. Extrado de: Rob, 2005 p. 8

Podemos visualizar na Figura 1.3 acima que o SGBD o eixo central que promo-
ve acessos dos diversos tipos de usurios e ou aplicativos computacionais aos da-
dos. Isso o SGBD recebe diversas solicitaes dos aplicativos e converte em opera-
es mais elaboradas para o acesso aos dados. Assim, a complexidade de acesso as
fontes nativas dos dados so encapsuladas pelo prprio SGBD, reduzindo esforos
no que se refere a implementao dessas funcionalidades na aplicao do cliente.
totalmente indicada a adoo do uso de um SGBD em qualquer cenrio
empresarial que necessita de manipular dados de maneira correta e em sua to-
talidade. A seguir apresentaremos as principais vantagens do uso de um SGBD:
Compartilhamento de Dados: o SGBD fornece mecanismos os quais per-
mitem que os usurios finais consigam acessar os dados facilmente, mes-
mo lidando com um grande volume de dados;

26 captulo 1
 Segurana de Dados: em um cenrio que possui uma quantidade expressiva
de usurios que acessam os dados, os riscos do quesito segurana tambm
so aumentados. Com a adoo dos SGBDs torna-se factvel criar um mode-
lo para melhor determinar as polticas de segurana empresarial, promo-
vendo a segurana a nvel de usurio, refletindo em uma maior privacidade
no acesso aos dados. Diversas regras de segurana podem ser elaboradas de-
terminando assim quais usurios podem ou no acessar o banco de dados
e, ainda determinar, quais objetos os mesmos podero acessar;
Centralizao dos Dados: um beneficio importante refere-se a centrali-
zao dos dados, sobretudo por permitir que todos os dados possam ser
integrados a um nico repositrio, minimizando dessa forma as redun-
dncias dos dados;
Flexibilidade: eventualmente, alteraes aplicadas ao banco de dados
so necessrias para contemplar os novos requisitos organizacionais.
Como exemplo, podemos citar que um determinado usurio carece de
uma viso de dados ora no disponvel no banco de dados. Grande parte
dos SGBDs possibilitam que mudanas estruturais possam ser aplicadas
no banco de dados sem ao menos interferir nos aplicativos computacio-
nais existentes;
Compartilhamento de Dados: a maioria dos SGBDs so multiusurio e
precisam promover o controle adequado da concorrncia para garantir
que a transaes simultneas obtenham xito ao seu final;
Mltiplas Interfaces: mediante a existncia de diversos tipos de usu-
rios, os quais possuem distintos nveis de conhecimento tcnico, um
SGBD precisa prover um leque de interfaces para melhor atende-los. A ci-
tar, interfaces para consultas emitidas por eventuais usurios, interfaces
para desenvolvedores de aplicativos, interfaces baseadas em formulrios
destinadas aos usurios finais;
Gerenciamento e Armazenamento de Dados: o SGBD constitui e adminis-
tra as estruturas consideradas complexas utilizadas no armazenamento
de dados, permitindo que o usurio d nfase em suas verdadeiras ne-
cessidades empresariais, evitando assim que o mesmo perda o foco em
procedimentos complexos de armazenamento de dados em baixo nvel;
Gerenciamento de Transaes: uma transao se resume como sendo
um conjunto lgico de trabalho. Toda e qualquer transao possui incio
(BEGIN) e fim (COMMIT e ou ROLLBACK). Dentro desse contexto, todos

captulo 1 27
 os registros relacionados a uma determinada transao so inseridos, al-
terados ou removidos ou nada registrado (tudo ou nada), garantindo a
consistncia e integridade dos dados, ora promovido pelo SGBD.

Para concluir as principais vantagens do uso de um SGBD, todas as tran-

saes desempenhadas por ele devem atender as propriedades que denomi-
namos de ACID (Atomicidade, Consistncia, Isolamento e Disponibilidade).
Essas propriedades melhoram o gerenciamento da concorrncia dos dados e
objetos junto ao SGBD.

ATENO
Um sistema de banco de dados uma coleo de dados inter-relacionados e um conjunto de pro-
gramas que permitem aos usurios acessar e modificar esses dados (Silberschatz, et al., 2006).

ATIVIDADE
1. Cite pelo menos trs exemplos de Dados e Informaes, num contexto de empresarial
qualquer. Detalhe cada um.

2. Apresente quatro diferenas significativas existentes entre um sistema de arquivo e um

SGBD.

3. Identifique cinco caractersticas de um sistema de gerenciamento de banco de dados

(SGBD).

REFLEXO
Atualmente a demanda por informaes, independentemente do segmento organizacional uma
constante expressiva. Para voc ter ideia, no Facebook, diariamente so publicadas 250.000.000
de fotos, 2.000.000.000 de comentrios ou curtio de posts, 900.000.000 atraes como
comunidades e eventos, 800.000.000 de usurios (s no Brasil, 28.000.000). Vimos que as or-
ganizaes empresarias manipulam diariamente um imenso volume de dados cujo propsito
torna-los em algum tipo de informao relevante para o suporte a tomada de deciso.

28 captulo 1
No se esquea de que nunca poderemos considerar que dado e informao so sinnimos.
Estudamos que anteriormente da existncia dos bancos de dados os dados empresariais
os mesmos eram manipulados por sistemas de arquivos, de forma manual. notrio que os
sistemas de arquivos sobreviveram por um grande espao de tempo, onde, muitos problemas
foram identificados.
Na sequncia, estudamos como os sistemas de arquivos e os sistemas de gerenciamento de
banco de dados funcionam, detalhando suas principais caractersticas e benefcios.
Por fim, aprendemos acerca dos principais tipos de usurios (leigos, desenvolvedores, avan-
ados, especialistas e DBAs), que de alguma maneira, utilizam os recursos de um SGBD.

LEITURA
Artigos on-line: para voc aumentar anda mais o seu nvel de aprendizagem envolvendo os
conceitos de Dados e Informao e demais assuntos desta unidade, consulte as sugestes de
links abaixo:
http://www.ime.usp.br/~vwsetzer/dado-info.html
http://gestorescomvisao.blogspot.com.br/2008/11/dado-x-informao.html

REFERNCIAS BIBLIOGRFICAS
ELMASRI, R.; NAVATHE, S.B. Sistemas de bancos de dados. So Paulo: Pearson (Addison
Wesley), 2005.

KORTH, H.; SILBERCHATZ, A. Sistemas de bancos de dados. 3. ed. So Paulo: Makron

Books, 1998.

HEUSER, C. A. Projeto de Bancos de Dados. 2. ed. Porto Alegre: Sagra Luzzatto, 1999.

PRESSMAN, R.S. Engenharia de software. So Paulo: Makron Books, 1995.

ROB, P.; CORONEL, C. Sistemas de Banco de Dados: Projeto, Implementao e Administra-

o. 8. Ed. So Paulo: Cengage Learning, 2011.

captulo 1 29
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de Banco de Dados. 5. ed. Rio
de Janeiro: Elsevier, 2006.

DATE, C. J.; Introduo a Sistemas de Banco de Dados; 8. Ed.; Trad. Daniel Vieira; Rio de
Janeiro: Elsevier, 2003.

HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4 ed. Instituto de Informtica da UFR-
GS, Sagra DC Luzzatto, 1998.

RAMAKRISHNAN, R. GEHRKE, J. Database Management Systems. 2. ed. Boston: McGraw-

-Hill, 2000.

TEOREY, T.; LIGHTSTONE, S.; NADEAU, T.; JAGADISH, H. V.; Database Modeling and De-
sign Logical Design. 5 ed., Burlington USA: Elsevier, 2011.

NO PRXIMO CAPTULO
No prximo captulo, estudaremos sobre Projeto de Banco de Dados. Ser apresentado os
principais detalhes existente por trs de um projeto de banco de dados bem estruturado,
sobretudo, suas principais fases inerentes a modelagem de dados.

30 captulo 1
 2
Projeto de Banco de
Dados
2 Projeto de Banco de Dados
No captulo 1, aprendemos os conceitos de dados e informaes, e como so
importantes e valiosos para as empresas. Aprendemos que a informao con-
siderada o principal ativo das empresas, auxiliando na tomada de deciso e,
consequentemente, se tornando um fator de competitividade empresarial.
Aps abstrairmos a relevncia das informaes no cotidiano empresarial, es-
tudaremos sobre o Projeto de Banco de Dados, que prov mecanismos eficazes
para elaborao e criao de banco de dados organizacionais, permitindo a ma-
nipulao correta de dados.
Atualmente, a grande maioria das organizaes, independentemente do seu
porte (pequeno, mdio e grande), impreterivelmente, utilizam SGBDs para ge-
renciarem suas informaes empresariais de maneira segura, ntegra e, ao mes-
mo tempo, disponibiliza-las para consultas a qualquer momento. Bem, voc
deve estar se perguntando, afinal, qual a importncia real de um Projeto de
Banco de Dados? Quais so suas principais fases? Como projetar um banco de
dados conciso e bem estruturado? No tenha dvida, que nessa unidade voc
conhecer as respostas desses questionamentos. Ento, vamos aos estudos!

OBJETIVOS
Este captulo tem como objetivo expor as principais fases de um projeto de banco de dados.
Estudaremos, de maneira objetiva, os modelos externo, conceitual e externo. Conheceremos
os principais modelos de dados. extremamente importante que exploremos profundamente
o modelo relacional, apresentando suas principais caractersticas e vantagens, se comparar-
mos com os demais modelos de dados presente e disponveis para utilizao.
Prepare-se, pois voc ter um trabalho ardo pela frente, ento dica , dedique-se bastante
a este captulo!

REFLEXO
Voc se lembra de nossa discusso no captulo 1 sobre o conceito de dado e informao?
Se, eventualmente, algum perguntar a diferena entre dado e informao, qual ser a
sua resposta?

32 captulo 2
2.1 Projeto de banco de dados

Para que alcancemos com xito os objetivos de um SGBD, torna-se imprescin-

dvel obtermos uma estrutura de dados adequada e bem definida, bem como,
escolher um modelo de dados para ser implementado pelo banco de dados.

ATENO
*Um banco de dados pode ser considerado como uma coleo de dados persistentes, onde
esses mesmos dados so manipulados por sua vez por aplicaes empresariais (DATE, 2003).

Quando iniciamos a constituio de um projeto de banco de dados, normal-

mente, torna-se necessrio se basear em uma viso abstrata do cenrio, o que
consideramos tambm como processo de abstrao do mini-mundo, inserin-
do detalhes medida que o projeto decorre. Essa maneira de utilizar nveis de
abstrao de dados promove facilidade para que possamos agrupar as diversas
vises de dados existentes dentro das organizaes empresariais. Como exem-
plo, podemos considerar que viso de dados abstrada pela diretoria plena-
mente distinta da viso de dados dos funcionrios vinculados produo. Esse
detalhe, sem dvida, dever ser considerado na fase de projetar o banco de da-
dos de uma organizao qualquer, independentemente, da sua rea de atuao.
Por isso que, o Comit de Planejamento e Exigncia de Padres (SPARC) do
Instituto Nacional Americano de Padres (ANSI), em meados de 1970, elaborou
uma estrutura cujo objetivo era auxiliar a fase de modelagem de banco de dados
baseando-se em diversos nveis de abstrao de dados. A arquitetura (ANSI/SPARC)
considera apenas trs nveis de abstrao de dados, o externo, conceitual e inter-
no. Para que voc entenda melhor as hierarquias dos modelos de dados, visualize
adequadamente a Figura 2.1, ora adaptada, incluindo o modelo fsico, o qual lida
explicitamente com os detalhes referente ao modelo interno em seu nvel fsico.

ATENO
O American National Standards Institute (ANSI) por meio do Standards Planning and Requi-
rements Commitee (SPARC) estabeleceu um padro para o desenvolvimento de tecnologias
de banco de dados, definindo uma arquitetura de 3 nveis independentes, a citar: interno,
conceitual e externo. (Rob, 2005).

captulo 2 33
 Viso do usurio final Viso do usurio final

Modelo externo Modelo externo

Modelo
Viso do projetista
conceitual
Independncia
lgica
Viso do SGBD Independncia
lgica

Independncia
fsica
Modelo
fsico

Figura 2.1 Nveis de abstrao de dados

Voc pode perceber que a viso do usurio final, isso , do modelo externo,
constitui por sua vez, o modelo conceitual, ou seja, o modelo de dados em que
a grande maioria dos projetistas de dados se baseia para a elaborao de qual-
quer projeto de banco de dados, independentemente de sua complexidade.
importante mencionar que o nvel de abstrao (modelo externo/concei-
tual) independente de hardware e software (SGBD). Entretanto, o prximo n-
vel, o modelo lgico, ao contrario do modelo conceitual, depende do software
(SGBD), todavia, tambm no considera o hardware. Para finalizar, nosso l-
timo modelo, esse intitulado de modelo interno (modelo fsico), depende de
maneira exclusiva do software (SGBD) e hardware.

2.2 Modelo externo

O modelo externo considera o cenrio do ambiente de dados de todos os tipos

de usurios, porm, em especial, os usurios finais. Recapitulando os concei-
tos j estudados, consideramos como usurios finais a nomenclatura utilizada
aos usurios que utilizam aplicativos computacionais para promover a mani-

34 captulo 2
pulao dos dados, obtendo como resultado final a produo de informaes
relevantes para o ambiente empresarial.
Acredito que seja evidente para voc que, a maioria das empresas segmen-
tada em diversos departamentos, como por exemplo: departamento de recursos
humanos, financeiro, vendas, etc. Onde cada departamento dever atender cer-
tas restries e requisitos especficos. Dessa maneira, cada usurio final que de-
sempenha suas atividades nesses diversos departamentos possui uma viso de
apenas um subconjunto de dados, especficos do seu departamento, desprezan-
do os detalhes dos outros departamentos.

(1,1) (0,N)
Aluno Faz Matrcula

(0,50)

feita em

(1,1)
(1,3) (0,N) (0,N) (1,1)
Professor Ensina Turma Gera Disciplina

(1,N) (0,N)
(0,N)
utilizada por

(1,N)

Sala

Pode ministrar

Figura 2.2 Modelo Externo (controle acadmico)

Por meio da Figura 2.2 acima, a qual podemos visualizar o modelo exter-
no pertinente ao controle acadmico de uma universidade fictcia, factvel
abstrairmos o modelo externo citado como exemplo, ser o responsvel em
promover o armazenamento dos dados dos alunos, matrculas, professores,
disciplinas e turmas. Voc pode observar tambm que as vises das diversas
funcionalidades do sistema so, por sua vez, segmentadas entre si, e, cada viso
pode tambm compartilhar um conjunto de dados com a outra (dados dos alu-
nos e cursos sendo compartilhados com a entidade disciplina).

captulo 2 35
 CONEXO
Leia um pouco mais sobre a histria e evoluo dos SGBDs e da SQL:
http://pcleon.if.ufrgs.br/~leon/Livro_3_ed/node116.html
http://algol.dcc.ufla.br/~heitor/Artigos/Artigo_008.html

Voc pode ainda observar, por meio da Figura 2.2, que as entidades e seus res-
pectivos relacionamentos nos aapresentam alguns detalhes mencionados a seguir:
Cada disciplina possui, obrigatoriamente, um professor vinculado, e,
por sua vez, um professor pode ministrar vrias disciplinas, at mesmo,
nenhuma;
Voc pode perceber ainda que, apesar dos professores ministrarem v-
rias disciplinas ou nenhuma em uma universidade, dessa forma, o mo-
delo apresenta o uso do que chamamos de cardinalidade mnima entre
PROFESSOR e DISCIPLINA como sendo 0 (zero). Sendo assim, admiti-
mos que pode existir disciplinas sem professores vinculados;
Um aluno pode ou no realizar matrculas, essas vinculadas as turmas,
que por sua vez, dever estar associada a pelo menos 1 disciplina;
Um professor pode ministrar aula para vrias turmas, inclusive nenhu-
ma. De outro lado, uma turma pode possuir no mnimo 1 professor ou
no mximo 3 (trs);
Para finalizar, ainda temos a que uma turma utiliza no mnimo 1 sala de
aula, que, em contrapartida, pode ser utilizada por vrias turmas, inclu-
sive nenhuma.

2.3 Modelo Conceitual

Posteriormente estudaremos os detalhes relacionados ao modelo externo, pode-

mos identificar que utilizamos o modelo conceitual, que por sua vez representa-
do graficamente pelo diagrama de entidade-relacionamento (DER). Esse DER tm
como propsito realizar a integrao de todas as vises externas em uma nica e
simples viso. Dessa forma, o modelo conceitual permite uma abrangente abstra-
o do banco de dados, simplesmente por proporcionar a integrao de todas as
vises externas (entidade, relacionamentos e, eventuais restries de domnio e ou
referencial) em uma viso nica de todos os dados manipulados pela empresa.

36 captulo 2
 O modelo ER (entidade-relacionamento) considerado um modelo concei-
tual mais empregado pelos projetistas de bancos de dados. Voc no poder se
esquecer de que, o modelo ER representado graficamente por meio do uso
do diagrama de entidade-relacionamento (DER), que por sua vez, representa o
esquema de banco de dados.
O modelo conceitual inclui diversas vantagens, entretanto, algumas delas
devem ser destacadas:
Possibilita uma visualizao global simples do cenrio cujo banco de da-
dos ser implementado;
um modelo independente da tecnologia do SGBD, ora utilizado para a
implementao fsica;
No podemos deixar de destacar que esse modelo tambm no depende
do hardware do servidor de banco de dados, sendo assim, as alteraes
oriundas do hardware e software no afetar o modelo conceitual.

CONEXO
Recomendamos a leitura deste artigo, para melhor compreenso do Projeto de Banco de Dados:
www.dpi.ufv.br/~jugurta/papers/tesejug.pdf

2.4 Modelo interno

Quando o projetista de banco de dados chega nessa fase, imprescindvel que o

mesmo j tenha escolhido a tecnologia de sistema de gerenciamento de banco
de dados (SGBD) que ser empregado. O objetivo do modelo interno realizar
o mapeamento do modelo conceitual para um determinado SGBD.
Sendo assim, quando voc utiliza um modelo relacional, consequentemen-
te, voc tambm dever escolher um banco de dados que permita o mapeamen-
to do modelo conceitual para as tabelas (relaes) existentes no modelo rela-
cional. Provavelmente, voc deve estar interrogando como formado o modelo
interno? Diramos que essa uma tima pergunta! O esquema/modelo interno
formado pela utilizao da linguagem SQL (Structured Query Language), assim
que definimos o SGBD-R (Sistema de Gerenciamento de Banco de Dados Re-
lacional). A fim de elucidar melhor o que efetivamente realizado nessa fase,
a Figura 2.3 a seguir, representa um modelo interno, constituindo as relaes
(tabelas) aluno, departamento, disciplina e curso.

captulo 2 37
 liberada
(0,n)
Departamentos Responsvel Disciplina
(1,1) (0,n) Pr_Requis
(0,n) (0,n)
create table departamentos
id_departamento interger, liberadadora
nome varchar(40),
create table disciplina
PRIMARY KEY(id_departamento)); Disc_Curso id_disciplina interger,
nome varchar(40),
pr_requisito interger,
(0,n) id_departamento interger,
(0,n) (1,1) PRIMARY KEY(id_disciplina),
Aluno Inscrio Curso FOREIGN KEY(pr_requisito)
REFERENCES disciplina,
FOREIGN KEY(id_departamento)
REFERENCES departamentos);

create table aluno create table curso

ra interger,
nome varchar(40),
sobrenome varchar(40);
PRIMARY KEY(ra));
id_curso interger,
descrio varchar(40),
id_disciplian interger,
PRIMARY KEY(id_curso),
FOREIGN KEY(id_disciplina) REFERENCES
disciplina);

Figura 2.3 Modelo interno (sistema acadmico)

Apenas para enfatizar novamente, voc j deve ter percebido que o mode-
lo interno est ligado diretamente com a tecnologia do SGBD a ser utilizado,
ou seja, existe uma dependncia em nvel de software, por exemplo, qualquer
alterao, por mais sucinta que ela seja, realizada no SGBD demandar que o
modelo interno tambm reflita algum tipo de alterao para que seja possvel
contemplar certos requisitos/restries. Eventualmente, chegamos ao ponto
de alterarmos o modelo interno sem resvalar no modelo conceitual, caracteri-
zando o que chamamos de independncia lgica.

2.5 Modelo fsico

Esse modelo conhecido por trabalhar com o nvel mais baixo de abstrao,
apresentando de maneira detalhada como os dados so efetivamente gravados
em um dispositivo de armazenamento qualquer (disco rgido, fitas magnticas,
etc.). O modelo fsico depende exclusivamente do SGBD (software) e do hardwa-
re, sobretudo por precisar conhecer previamente os dispositivos fsicos que se-
ro utilizados para o armazenamento dos dados, principalmente, os mtodos
que provero acesso aos mesmos.

38 captulo 2
 ATENO
Tuning SQL (otimizao de consulta) um processo de selecionar o plano de avaliao de
consulta mais eficiente dentre as muitas estratgias normalmente possveis para o proces-
samento de determinada consulta (Silberschatz, A. et al, 2006).

O DBA (Administrador de Banco de Dados) e ou projetista de dados no

precisam se preocupar com os detalhes em nvel do armazenamento fsico, en-
tretanto, precisam conhecer minuciosamente como realizar a sintonizao (tu-
ning) a fim de incrementar a performance, principalmente quando utilizamos
o modelo de dados relacional.
Quando for necessrio aplicar qualquer tipo de alterao no modelo fsico
sem precisar refletir a alterao/modificao no modelo interno, obtemos o
que caracterizamos de independncia fsica de dados.

2.6 Modelo de dados

O modelo de dados pode ser conceituado como sendo uma representao sim-
ples que, normalmente, simboliza graficamente as estruturas dos dados. Pode-
mos dizer que o modelo de dados uma abstrao de um ambiente real, cujo
objetivo subsidiar o compreendimento adequado dos requisitos, sejam esses
simples ou complexos, inclusos em cenrios empresariais.
O projetista de dados dever utilizar o bom senso para que seja possvel a
obteno de modelos de dados bem estruturados e aceitveis. O processo re-
lacionado elaborao de um modelo de dados no uma tarefa considerada
nada fcil, e, certamente uma verso satisfatrio do modelo de dados ser atin-
gida, posteriormente diversas correes e adaptaes.
Para exemplificar, e garantir seu entendimento pleno acerca do conceito do
modelo de dados, utilizaremos a turma da disciplina de Modelagem de Dados,
a qual dever ser divida em trs grupos distintos, onde cada grupo se responsa-
bilizar em elaborar um modelo de dados para contemplar as necessidades de
armazenamento de dados de uma locadora de automveis (regra de negcio).
Voc poder perceber que cada grupo apresentar uma verso de modelo de
dados, cujo o propsito basicamente o mesmo, ou seja, atender os requisitos
fundamentais da regra de negcio de uma locadora de automveis. Agora, qual
modelo realmente estar correto? Voc pode concluir que no existe uma res-

captulo 2 39
posta nica e exclusiva para esse questionamento. O mais adequado seria res-
ponder que: o melhor modelo de dados aquele que atende em sua plenitude
todos os requisitos da regra de negcio e, certamente, podemos chegar a mais
de uma alternativa considerada correta.
Sumarizando, podemos dizer que os modelos de dados servem como ferramen-
tas de comunicao, fomentando uma abstrao global de como os dados sero es-
truturados e armazenados no novo banco de dados a ser confeccionado.
Analogamente, imagine a abstrao de uma planta baixa de uma residn-
cia qualquer. Voc deve concordar que no conseguirmos morar na planta, ok!
Sendo assim, um modelo de dados tambm pode ser considerado como uma
abstrao, isto , no possvel realizar qualquer tipo de manipulao de infor-
mao a partir de um modelo de dados. Resumidamente, no podemos levan-
tar uma residncia bem estruturada e confivel abdicando-se do uso de uma
planta baixa, isso poder ser aplicado para o banco de dados sem nenhuma res-
trio, sobretudo por ser imprescindvel para a criao de qualquer banco de
dados a realizao prvia de um modelo de dados.
Os modelos de dados so constitudos pelo emprego de entidades, atribu-
tos, relacionamentos e eventuais restries de domnio ou referencial. Se voc
estiver confuso, principalmente por ainda no termos elucidado os conceitos
acerca de entidade, atributo e relacionamento, no se preocupe, detalharemos
na sequncia o significado de cada conceito.
Consideramos como entidade, algo que desejamos armazenar no banco de
dados, a citar: um carro, uma pessoa, etc., que por sua vez, representa um deter-
minado tipo de objeto abstrado do mundo real (mini-mundo). Dessa maneira,
conclusse que cada ocorrncia dessa mesma entidade considerada nica e
exclusiva. Como exemplo, podemos tomar como base a criao de uma enti-
dade, ora intitulada de FUNCIONARIO. Certamente teramos n ocorrncias
de funcionrios nicos, como exemplo tomamos os seguintes nomes de fun-
cionrios: Geraldo Alckmin, Acio Neves, Dilma Rousseff, etc. As entidades po-
dem constituir objetos fsicos reais (funcionrios, clientes, alunos, professores,
etc.), como tambm uma forma de abstrao, a citar como exemplo, os horrios
de uma determinada ponte-area Rio de Janeiro-So Paulo ou uma exibio de
uma filme especfico no cinema.
Por outro lado, um atributo conceituado como uma caracterstica particular
de uma entidade, ou at mesmo de um relacionamento especfico. Isso mesmo!
Podemos associar um atributo a um relacionamento, no apenas vincula-lo em
uma entidade. Para exemplificar o uso de um atributo, suponha que caracteriza-

40 captulo 2
mos a entidade FUNCIONARIO com os seguintes atributos: nmero do funcio-
nrio, nome, sobrenome, endereo e salrio.
Um relacionamento tem como propsito descrever um vnculo (associao)
entre uma ou vrias entidades. Podemos tomar como exemplo a existncia de
um relacionamento que por sua vez, associa/vincula as entidades FUNCIONA-
RIO e CLIENTE que pode ser interpretada da seguinte maneira: um funcionrio
pode atender n clientes, todavia, cada cliente pode ser atendido por somente
um funcionrio. A fim de representar adequadamente esses vnculos, o modelo
de dados faz uso de trs tipos bsicos de relacionamento (o que tambm cha-
mamos de cardinalidade): um para muitos (1:M ou 1..*), muitos para muitos
(M:N ou *..*) e um para um (1:1 ou 1..1).
Ao mencionarmos restrio aplicada ao modelo de dados, podemos enten-
der como sendo uma limitao imposta aos dados. Para aplicar a integridade
de dados, torna-se crucial a utilizao de restries. O uso de restries em um
modelo de dados considerado de suma importncia. Para exemplificar o uso
de restries aplicada em um domnio qualquer, considere os detalhes a seguir:
Um funcionrio dever possuir um salrio entre o intervalo de R$ 780,00
e R$ 7.500,00;
Um funcionrio dever possuir como mdia de venda, um valor superior
a 30% de seu salrio atual;
Cada exemplar em uma biblioteca dever possuir no mnimo 5 livros
para realizao de emprstimos.

Voc j sabe identificar corretamente as entidades, atributos e relacionamen-

tos e ou eventuais restries aplicada ao domnio? Inicialmente necessrio
voc absorver corretamente os requisitos da regra de negcio a ser modelada.
Bem, mencionamos diversas vezes o conceito de regra de negcio, porm,
ainda no contextualizamos. Podemos considerar como uma regra de negcio
uma descrio simples, clara e sem impreciso no que tange as transaes ou ob-
jetos de uma empresa qualquer, sem considerar o seu porte (pequena, mdia ou
grande). Por meio do uso das regras de negcio podemos identificar as possveis
entidades, atributos, relacionamentos e, eventuais restries. No tenha dvida
que, sem perceber, voc j se esbarrou em alguma regra de negcio e nem se deu
conta. Em nossos exemplos anteriores, quando referimos que um funcionrio
pode atender n clientes, porm, cada cliente pode ser atendido por um exclusi-
vo funcionrio, essa descrio considerada como sendo uma regra de negcio.

captulo 2 41
 Agora que j desmitificamos o conceito de regra de negcio, podemos apre-
sentar os diversos modelos de dados, ora constitudos para promover o melhor
gerenciamento dos dados, que tiveram como objetivo solucionar eventuais falhas
provenientes dos antigos sistemas de arquivos. Constitumos uma tabela, essa in-
titulada de Tabela 2.1, a fim de demonstrar resumidamente os modelos de dados
mais habituais, considerando a evoluo do tempo:

PERODO MODELO EXEMPLOS COMENTRIOS

IBM faz uso em seus
1960 a Sistema de mainframes
VMS/VSAM
1970 arquivos No utiliza relaciona-
mentos

Modelo de da- Implementado pelos pri-

IMS, ADABAS,
1970 dos hierrqui- meiros bancos de dados
IDS-II
co e em rede da poca

1970 DB2, Oracle, Utiliza os conceitos

Modelo de da-
at o MS SQL Server, bsicos (simples) e
dos relacional
presente MySQL objetivos.

Usado na manipulao
Orientado a
1980 PostgreSQL, de dados considerados
objetos
at o Versant, Cach, complexos.
Relacional
presente FastObjects.Net Disseminao de banco
estendido
de dados na web

Objectivity/DB,
DB/2 UDB, Permite a manipulao e
Do pre- dbXML, Tamino, gerenciamento de dados
sente ao XML DB2 UDB, semiestruturados.
futuro Oracle 10g, MS Suporte a documentos
SQL Server, no formato XML
PostgreSQL

Tabela 2.1 Evoluo dos Modelos de Dados (Desde 1960).

42 captulo 2
2.6.1 modelo hierrquico

O modelo hierrquico foi criado em meados de 1960, com o propsito de ge-

renciar adequadamente grandes volumes de dados provenientes de projetos
complexos. A estrutura lgica do modelo hierrquico constituda por uma
estrutura semelhante a estrutura de uma rvore, essa visualizada de cima para
baixo, possibilitando visualizar suas ramificaes.
No modelo hierrquico, consideramos um segmento como sendo um regis-
tro em um sistema de arquivo. Internamente, o modelo hierrquico possui uma
camada superior, essa denominada de raiz (n pai) do segmento subsequente
abaixo desse. A Figura 2.4 exemplifica o uso de um modelo hierrquico, onde
possvel identificarmos o segmento pai considerado raiz (voo) dos segmentos
filhos (escala, reserva e bilhete), onde escala e bilhete, por sua vez, so con-
siderados pais dos fragmentos cidade e cliente. De maneira intuitiva, os seg-
mentos ora localizados abaixo de outros segmentos so considerados filhos.
Sendo assim, se observarmos detalhadamente, factvel de identificar que o
modelo hierrquico representa exclusivamente o relacionamento um para
muitos (1:M) existente entre o segmento pai e seus respectivos filhos, ou seja,
cada segmento pai possui diversos segmentos filhos, porm, cada segmento
filho, por sua vez, possui apenas vinculado a ele um segmento pai.

VOO
voo_cod voo_data voo_hora

ESCALA BILHETE
voo_cod cid_cod esc_horacheg esc_horasaid esc_estatus bil_cod voo_cod cli_cod bil_valor

RESERVA
res_cod voo_cod res_ticket res_data res_cliente

CIDADE CLIENTE
cid_cod cid_nome cid_estado cli_cod cli_nome cli_cpf

Figura 2.4 Exemplo fictcio de um Modelo Hierrquico

J na dcada de 70, o banco de dados hierrquico era referncia, sobretudo

por possuir grandes vantagens sobre os sistemas de arquivos, constituindo as-
sim, pilares fundamentais para subsidiar o desenvolvimento de aplicativos co-
merciais. Mesmo o modelo hierrquico possuindo diversas vantagens em com-

captulo 2 43
parao ao armazenamento de dados por meio do uso de sistema de arquivo,
esse modelo apresentava limitaes relevantes, as quais, podemos mencionar
como principais a ausncia de independncia estrutural, dificuldade em geren-
ciar e manipular os registros, e, a maioria dos relacionamentos de dados no
conseguiam se adaptar cardinalidade (multiplicidade) 1:M.

2.6.2 modelo em rede

O modelo de rede foi constitudo com objetivo de representar os relacionamen-

tos de dados considerados mais elaborados, adotando uma representao sim-
ples e eficaz em comparao ao modelo hierrquico.
Ao contrrio do modelo hierrquico, o modelo em rede possibilita que um
registro possua mais de um segmento pai, conforme podemos visualizar na Fi-
gura 2.5 abaixo apresentada:

CLIENTE VOO CIDADE

cli_cod cli_nome cli_cpf voo_cod voo_data voo_hora cid_cod cid_nome cid_estado

BILHETE ESCALA
bil_cod voo_cod cli_cod bil_valor voo_cod cid_cod esc_horacheg esc_horasaid esc_estatus

RESERVA
res_cod voo_cod res_ticket res_data res_cliente

Figura 2.5 Modelo em Rede (exemplo fictcio).

Nesse exemplo, simplesmente convertemos o modelo hierrquico para o mo-

delo em rede, utilizando as mesmas regras de negcio. Voc j deve ter identifi-
cado os tipos de registros, a citar: CLIENTE, VOO, CIDADE, BILHETE, ESCALA e
RESERVA. Tambm notrio que ESCALA considerado filho de ambos, isso ,
de voo e cidade, e que, esses, por sua vez so denominados pais. Anlogo a descri-
o anterior, podemos dizer que bilhete tambm possui dois pais (cliente e voo).
Entretanto, o modelo em rede no conseguiu solucionar todos os pro-
blemas pertinentes modelagem de dados. A ausncia de estrutura correta
para permitir a realizao de consultas e a necessidade de implementao

44 captulo 2
macia de linhas de cdigo-fonte para fornecer um simples relatrio era
considerada uma das grandes desvantagens desse modelo de dados. A fal-
ta de independncia de dados tambm era considerada um de seus pontos
negativos, pois, caso fosse necessrio realizar qualquer tipo de modificao
que atingisse a estrutura dos dados, por mais sucinta que fosse correramos
o risco de destruir os aplicativos que utilizassem o banco de dados para a
manipulao dos dados.
Devido essas inmeras desvantagens correlacionadas anteriormente, ora
apresentadas pelo modelo hierrquico e em rede, por volta da dcada de 80,
surgiu o modelo de dados, esse intitulado de modelo relacional, que acabou
por substitui-los.

2.6.3 modelo relacional

O modelo relacional foi criado proveniente do conceito matemtico (relao).

Esse conceito nos permite abstrair que uma relao nada mais do que uma
matriz bidimensional, ora constituda por linhas e colunas.
Esse modelo, frequentemente, constitudo por meio do uso de um sistema
gerenciador de banco de dados relacional, ora referenciado pela sigla SGBD-R.
O SGBD-R dispe das mesmas funcionalidades apresentadas pelos sistemas
gerenciador de banco de dados que atende ao modelo hierrquico e em rede,
excluindo a insero dos demais recursos os quais permitem que o modelo re-
lacional acrescente maior complexidade em sua abstrao e implementao.
Ao mencionarmos as vantagens de um SGBD-R, importante correlatar a
maneira em que o mesmo oculta a complexidade do modelo relacional, admi-
nistrando os detalhes fsicos e expondo o banco de dados relacional aos usu-
rios finais como sendo um conjunto de relaes (tabelas) onde os dados so
armazenados, essas se relacionando entre si.
No modelo relacional, quando compartilhamos um determinado atributo
de uma tabela especfica, torna-se possvel promover o relacionamento entre si.
Para exemplificar, apresentamos a Figura 2.6, ora constituda pelas tabelas
nomeada de CLIENTE, essa por sua vez, possui o nmero do funcionrio (ID_
FUNC) que normalmente lhe atende, vinculado pela tabela FUNCIONARIO.

captulo 2 45
 Tabela: Funcionrio

ID_ SOBRE-
NOME SEXO CPF RG
FUNC NOME

987 Jos Abro M 111222333444 1234567890

321 Mrcia Marina F 555333123098 2347698243

ID_FUNC NOME SOBRENOME SEXO CPF RG

112 Wagner Moura M 765234509876 123543-MG

Relacionamento por meio do atributo ID_FUNC

Tabela: Cliente

SOBRE- ID_
ID_CLI NOME SEXO CPF RG
NOME FUNC

89710 Geraldo Alckmin M 7687171398 1233456 112

89711 Acio Neves M 6534982615 2455455 987

65412 Joo Gilberto M 1235566615 2342353 987

23113 Marina Silva F 6509090456 4563434 112

65514 Dbora Santos F 1236451324 3425633 112

Figura 2.6 Exemplo de Modelo Relacional

factvel de identificarmos o estabelecimento do relacionamento existente

entre as relaes FUNCIONARIO e CLIENTE que permite vincular um cliente a
um determinado funcionrio, esse responsvel pelo atendimento. Repare que,

46 captulo 2
mesmo que os dados dos clientes estejam armazenados em uma relao e, os
dados dos funcionrios, por sua vez, armazenados em outra, possvel traba-
lharmos com essa integridade referencial.
O exemplo exposto acima suficiente para o seu aprendizado no que se refe-
re ao modelo relacional? Ainda lhe resta dvida? Bem, vamos estudar um pou-
co mais! Podemos vincular os clientes Geraldo Alckmin, Marina Silva e Dbora
Santos com seu respectivo vendedor, o funcionrio chamado Wagner Moura,
esse identificado exclusivamente pelo nmero 112. Voc pode identificar ainda
que, na tabela CLIENTE, o atributo rotulado de ID_FUNC por sua vez uma
chave estrangeira, a qual associa os clientes com seus respectivos vendedores.
Dessa forma, conclusse que o modelo relacional, na trajetria da evoluo dos
modelos de dados, foi considerado imprescindvel, principalmente por incorporar
a linguagem SQL (Structured Query Language), que por si s nos proporciona total
transparncia na manipulao de dados e confeco de relatrios gerenciais.

ATIVIDADE
4. Descreva detalhadamente o conceito de Entidade e Relacionamento. Cite pelo menos trs
exemplos onde podemos utilizar ambos.

5. Analise o cenrio do ambiente acadmico, mais especificamente, de uma sala de aula. A

partir dessa analise, represente por meio de um DER, o conjunto de carteiras e o conjunto
dos tipos de mveis.

6. Discorra sobre os detalhes pertinentes ao Modelo Hierrquico, apontando suas desvanta-

gens comparando com o Modelo em Rede.

7. Realize uma pesquisa na Internet e descreva trs caractersticas de um Banco de Dados

XML. Cite pelo menos trs nomes de banco de dados que manipulam arquivos XML.

8. D pelo menos trs exemplos de restrio aplicada a um modelo de dados. Na sequncia,

descreva os trs tipos de relacionamentos que podem ser utilizado para associar entidades.

captulo 2 47
 REFLEXO
Finalizamos mais um captulo!
Neste captulo aprendemos sobre as fases que constituem o projeto de banco de dados.
Aprendemos que o modelo externo considera o cenrio de dados utilizado pelos usurios finais.
Estudamos tambm sobre o modelo conceitual, um dos modelos de dados mais utilizado
pelos projetistas de banco de dados (ou DBAs), na elaborao de esquema de banco de
dados, o qual representado graficamente por meio do uso do diagrama de entidade-rela-
cionamento (DER).
Verificamos tambm que o modelo relacional baseasse no conceito matemtico relao
considerando uma tabela (relao) como sendo uma matriz bidimensional constituda por
linhas e colunas.

LEITURA
Artigos on-line: para voc incrementar mais o seu nvel de aprendizagem relativo ao Projeto
de Banco de Dados:
http://juliobattisti.com.br/artigos/office/modelorelacional_p5.asp
http://www.dicasdeprogramacao.com.br/como-criar-um-projeto-de-banco-de-dados/
http://www.devmedia.com.br/dbdesigner-modelagem-e-implementacao-de-banco-de-
dados/30897

Livro: Introduo a Sistemas de Banco de Dados; 8. Ed., DATE, C. J, voc encontrar mais
conceitos acerca de SGBDs, sua utilizao e vantagens. Estude mais sobre a arquitetura dos
SGBDs, este livro faz uma abordagem bastante densa e completa do assunto. Aprofunde
seus conhecimentos!

REFERNCIAS BIBLIOGRFICAS
ELMASRI, R.; NAVATHE, S.B. Sistemas de bancos de dados. So Paulo: Pearson (Addison
Wesley), 2005.

KORTH, H.; SILBERCHATZ, A. Sistemas de bancos de dados. 3. ed. So Paulo: Makron

Books, 1998.

48 captulo 2
HEUSER, C. A. Projeto de Bancos de Dados. 2. ed. Porto Alegre: Sagra Luzzatto, 1999.

PRESSMAN, R.S. Engenharia de software. So Paulo: Makron Books, 1995.

ROB, P.; CORONEL, C. Sistemas de Banco de Dados: Projeto, Implementao e Administra-

o. 8. Ed. So Paulo: Cengage Learning, 2011.

SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de Banco de Dados. 5. ed. Rio
de Janeiro: Elsevier, 2006.

DATE, C. J.; Introduo a Sistemas de Banco de Dados; 8. Ed.; Trad. Daniel Vieira; Rio de
Janeiro: Elsevier, 2003.

HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4 ed. Instituto de Informtica da UFR-
GS, Sagra DC Luzzatto, 1998.

RAMAKRISHNAN, R. GEHRKE, J. Database Management Systems. 2. ed. Boston: McGraw-

-Hill, 2000.

TEOREY, T.; LIGHTSTONE, S.; NADEAU, T.; JAGADISH, H. V.; Database Modeling and De-
sign Logical Design. 5 ed., Burlington USA: Elsevier, 2011.

NO PRXIMO CAPTULO
No prximo captulo, estudaremos com detalhes o modelo entidade-relacionamento. Estuda-
remos a importncia de constituirmos um modelo conceitual bem estruturado. Para elaborar
um bom projeto de banco de dados, devemos aprender as caractersticas relevantes do Mo-
delo Entidade-Relacionamento.

captulo 2 49
 3
Modelo Entidade
-Relacionamento
3 Modelo Entidade-Relacionamento
No captulo anterior, estudamos acerca dos conceitos pertinentes ao projeto de
banco de dados, discorrendo sobre seus principais nveis de abstrao (modelo ex-
terno, conceitual e interno). Aprendemos o que efetivamente realizado no mode-
lo fsico e quais so os modelos de dados mais habituais (modelo hierrquico, em
rede e relacional).
Espero que voc esteja alinhado com todos esses conceitos apresentados at o pre-
sente momento, caso esteja com alguma dvida, sugerimos que voc realize uma
reviso das unidades anteriores!
Nesse captulo, estudaremos conceitos triviais para que possamos elaborar um
banco de dados utilizando-se o modelo entidade-relacionamento.
Antes de introduzirmos os novos conceitos referentes ao modelo entidade-rela-
cionamento torna-se importante e de grande relevncia aprendermos adequa-
damente sobre as fases constituintes de um projeto de banco de dados, sobre-
tudo, o que e, para que utilizamos um modelo de banco de dados.
Voc est pronto?! Vamos dar incio aos nossos objetos de aprendizagem suge-
ridos neste captulo 3?

OBJETIVOS
Este captulo tem como objetivo aprofundar os conceitos pertinentes as principais caracters-
ticas do Modelo Conceitual; apresentar o Modelo Entidade-Relacionamento, evidenciando as
entidades, relacionamentos, cardinalidade, atributos, dentre outros conceitos; entender como o
Modelo de Entidade-Relacionamento representado graficamente pelo emprego de um Dia-
grama Entidade-Relacionamento. Compreender como identificar corretamente o grau de um
determinado relacionamento seja esse relacionamento unrio, binrio, ternrio e ou nrio.

REFLEXO
Voc se lembra dos conceitos estudados na Unidade 2, onde discutimos sobre o Projeto de
Banco de Dados e os principais modelos de dados, e os principais tipos de relacionamentos?
Voc seria capaz de definir as principais caractersticas de um modelo interno de dados?
Voc se encontra confortvel em distinguir adequadamente os conceitos acerca dos Mode-
los de Dados: Hierrquico, em Rede e Relacional?

52 captulo 3
3.1 Modelo Entidade-Relacionamento

No captulo anterior, aprendemos sobre os conceitos bsicos de um projeto de

banco de dados, seus principais nveis de abstrao (modelo externo, conceitu-
al e interno). Aprendemos tambm como elaborar um modelo fsico de banco
de dados e discorremos superficialmente sobre os modelos de dados mais co-
muns (modelo hierrquico, em rede e relacional).
Nesse captulo, estudaremos os conceitos bsicos e fundamentais para a
criao de um banco de dados, independentemente da regra de negcio, por
meio do uso do modelo entidade-relacionamento.

ATENO
O processo de modelagem de dados pode ser considerado como sendo um processo que
emprega diversas etapas, normalmente iterativo e progressivo. D incio atravs de uma abs-
trao simples de um determinado problema, o qual desejamos solucionar, e conforme o nvel
de abstrao do problema incrementado, o nvel de detalhes que a modelagem compreen-
de tambm aumenta (Heuser, 2004).

Bem, antes de iniciarmos a discusso sobre os conceitos novos, referente

ao modelo entidade-relacionamento, torna-se trivial e ao mesmo tempo, apro-
priado, obtermos o conhecimento das fases que formam um projeto de banco
de dados considerado bem estruturado, e ainda, por que utilizamos o modelo
de banco de dados.
Precisamos deixar claro que a fase que constitui a modelagem de dados a
primeira envolvida na criao de um projeto de banco de dados. Essa etapa
simplesmente um processo de criao de um modelo de dados especfico que
tem como propsito a resoluo de um determinado problema, esse presente
em nossas atividades dirias.

Reflita: Voc faz ideia do tipo de problema que a modelagem de dados se

prope a solucionar?
No tenha dvida que essa resposta bem simples! Certamente todos ns
nos deparamos com eventuais problemas em nosso cotidiano, isso se replica,
as organizaes empresarias. Normalmente, tais problemas so claramente de-
finidos no ambiente empresarial real, com escopo e limites bem delimitados,
que por sua vez, devem ser tratadas como uma viso sistmica.

captulo 3 53
 Voc imagina qual seria o tipo de problema que a modelagem de dados se
prope a solucionar?
Para exemplificar, imagine a necessidade de realizar a categorizao de um
conjunto de produtos. Dizemos que processo de categorizar esse conjunto de
produtos seja o nosso problema! Para que posamos promover uma modelagem
de dados coerente e concisa, devemos realizar criteriosamente o levantamento
de todos os detalhes e, eventuais relaes que isto implicaria dentro de uma
regra de negcio especfica.

ATENO
Um esquema de banco de dados nada mais do que uma representao de um modelo de dados
por meio do uso de um conceito de modelagem de dados (DATE, 2003).

3.1.1 Modelo de Banco de Dados

Segundo Peter Chen, um Modelo Entidade-Relacionamento constitudo por

uma notao, ora formada por entidades (graficamente representado por re-
tngulos), relacionamentos (graficamente representado por losango), atribu-
tos, que compe as caractersticas das entidades, e ou, relacionamentos (esse,
graficamente representado pelo emprego de crculos) e, por fim, linhas que
realizam a conexo indicando por sua vez a cardinalidade (multiplicidade) de
uma entidade ou mais, aplicado a um relacionamento qualquer. Essas cone-
xes so graficamente representadas pelo uso de linhas.
At o momento, aprendemos que um modelo de banco de dados nada mais
do que uma descrio repleta de detalhes acerca das principais informaes
que almejamos armazenar em um banco de dados qualquer. Dessa maneira,
crucial adotarmos uma linguagem para realizar essa modelagem de dados,
conduzindo-nos a confeccionar modelos de dados confiveis e estruturado.
Classificamos essas linguagens de acordo com a representao dos mode-
los de dados. Como exemplo, podemos correlacionar, linguagens que utilizam
textos ou grficos para realizar a representao dos modelos de dados em dis-
tintos nveis de abstrao.
Dessa forma, dizemos que um esquema de banco de dados nada mais do
que uma representao de um modelo de dados, que utilizou uma linguagem
especfica de modelagem de dados.

54 captulo 3
 Um modelo de dados tem como principal caracterstica ser simples no que
se refere ao entendimento de como os dados sero organizados e manipulados
em um banco de dados, mesmo para aqueles usurios desprovidos de conheci-
mentos computacionais especficos.
Ao iniciarmos a elaborao de um projeto de banco de dados, aconselhvel
que tenhamos pelo menos dois nveis de abstrao, esses, respectivamente, nome-
ados de modelo conceitual (projeto conceitual) e modelo lgico (projeto lgico).

3.1.2 Modelo Conceitual

O modelo conceitual tem como propsito descrever um modelo de dados de

forma abstrata e independente da tecnologia do SGBD empregado. Esse mo-
delo tambm descreve genericamente, quais dados devero ser armazenados
no banco de dados, entretanto, no menciona como estes mesmos dados sero
armazenados em nvel de software (SGBD).
Essa abordagem amplamente conhecida como Entidade-Relacionamento
(ER), que por sua vez, considerada uma das principais tcnicas utilizadas na
modelagem conceitual. Tal tcnica nos permite a representao grfica do mo-
delo conceitual atravs de um diagrama, esse, intitulado de diagrama entidade-
-relacionamento (DER). A Figura 3.1 nos apresenta um exemplo do diagrama
entidade-relacionamento:

(1,n) (1,n)
Mdico atende Paciente

CRM Cdigo
Nome Nome
Especialidade Sobrenome

Figura 3.1 Representao do modelo conceitual por meio de um DER

O modelo conceitual, ora representado graficamente pelo emprego do dia-

grama entidade-relacionamento, permite abstrair que o banco de dados conte-
r dados referentes aos mdicos e pacientes. Dessa maneira, para cada mdi-
co, o banco de dados armazenar suas principais caractersticas, a citar, CRM
(nmero do Conselho Regional de Medicina), nome e sobrenome, e, por sua

captulo 3 55
vez, para cada paciente, sero armazenados seu cdigo identificador, nome e
sobrenome. Ainda podemos identificar a existncia de uma associao (rela-
cionamento) ora aplicada para descrever os atendimentos mdicos.

3.1.3 modelo lgico

O modelo lgico pode ser considerado o oposto do modelo conceitual, visto

que o mesmo depende exclusivamente do SGBD que ser utilizado na criao
do banco de dados. Esse modelo tem como objetivo descrever o banco de dados
em um nvel de abstrao visto pelo usurio do SGBD.
Na fase constituinte do modelo lgico, o projetista de dados decidir as
tabelas (relaes) que formaro o banco de dados e, ainda, definir para cada
tabela, os respectivos nomes de suas colunas, por exemplo: tabela intitulada
de mdico ser constituda pelas colunas (atributos) crm, nome e sobreno-
me. J por sua vez, a tabela nomeada de paciente ser formada pelas colunas
cod_paciente, nome, sobrenome e crm.
Esses detalhes, ora visualizados pelo usurio do SGBD correspondem ao ar-
mazenamento interno dos dados, que normalmente, interferem no desempe-
nho da aplicao computacional.
Na primeira fase do projeto de banco de dados, uma das principais atividades
o que denominados de levantamento de requisitos, atendendo as necessidades
organizacionais de um ambiente empresarial qualquer, atravs da anlise de re-
quisitos, criando assim, subsdios para a elaborao do projeto conceitual, ora
representado pelo modelo entidade-relacionamento (MER). O MER trata-se de
um modelo de dados considerado de alto nvel de abstrao, que independe da
tecnologia do SGBD adotado para a realizao do armazenamento dos dados.

CONEXO
Leia mais sobre modelo de dados:
http://www.linhadecodigo.com.br/artigo/332/planeje-o-seu-modelo-de-dados.aspx

A fase subsequente destinada a criao do projeto lgico de dados, que

possui como propsito realizar o mapeamento do modelo entidade-relaciona-
mento (MER) para um modelo de dados qualquer, a citar, o modelo relacional,
ora, obrigatoriamente dever ser suportado pelo SGBD a ser empregado.

56 captulo 3
 Finalizando o projeto de banco de dados, a terceira fase trata do projeto f-
sico. Esse tem como objetivo definir corretamente as estruturas de armazena-
mento interno, como podemos mencionar, as tabelas, os ndices, dentre outros
objetos, ainda sim, definir outras atividades associadas paralelamente, ao de-
senvolvimento de aplicativos computacionais.

3.2 As Principais Caracteristicas do MER

Bem, agora chegou o momento de esmiuarmos as principais caractersticas do

modelo entidade-relacionamento (MER). Peter Chen, na dcada de 70, constituiu
o modelo entidade-relacionamento, o qual, atualmente considerado clssico
(padro) para a modelagem conceitual de banco de dados. O objetivo principal do
MER criar adequadamente as entidades e seus respectivos relacionamentos, ora
abstrados de um ambiente empresarial real qualquer, o qual desejamos modelar.
O Modelo Entidade-Relacionamento (MER) descreve conceitualmente
como os dados sero manipulados por meio de um sistema computacional.
Uma vasta gama de conceitos aplicada ao MER, porm, esses conceitos
so considerados simples de entender, facilitando consideravelmente as tare-
fas dos projetistas de dados no que se refere ao entendimento adequado dos
conceitos referente aos dados utilizados nos aplicativos computacionais, inde-
pendentemente da tecnologia do SGBD que ser utilizada na implementao
do banco de dados. O Diagrama Entidade-Relacionamento (DER), por sua vez,
considerado como sendo um esquema conceitual, ora elaborado a partir dos
conceitos do modelo entidade-relacionamento.
Devemos tambm deixar evidente de que, mesmo que o diagrama entidade-
-relacionamento possua um elemento chamado de entidade, ora representado
graficamente pelo uso de um retngulo, tal elemento no possui nenhuma re-
lao com a entidade externa, essa representado por sua vez, por um diagrama
de fluxo de dados.

3.2.1 Entidade

Uma entidade tem como propsito representar um conjunto de objetos de um

ambiente organizacional real qualquer, ora a ser modelado. Como exemplo,
podemos tomar um funcionrio chamado de Willian Bonner, inscrito no RG
sob o nmero 12.345.678-9. O nmero do RG de Willian Bonner considerado

captulo 3 57
como sendo uma entidade, pelo simples fato de permitir identificar exclusiva-
mente um determinado funcionrio em comparao com os demais. Destaca-
se ainda que uma entidade possa assumir duas caractersticas, isso ser con-
creta (uma pessoa funcionrio) e ou abstrata (uma instituio acadmica).
Dessa maneira, voc pode perceber que um conjunto de entidades por sua vez,
forma um agrupamento de entidade de um mesmo tipo. Esses conceitos lhe dei-
xaram confuso? No se preocupe, tentaremos explica-los para a sua melhor apren-
dizagem. Suponha um conjunto de funcionrios de uma empresa qualquer, por
exemplo, a Oracle, sendo assim, permitido definirmos esse conjunto de funcion-
rios como um conjunto de entidades, essas intituladas de FUNCIONARIO.
A Figura 3.2 a seguir, representamos graficamente suas entidades por meio
do uso de um diagrama entidade-relacionamento (DER):

Funcionrio Empresa

Figura 3.2 Exemplo de entidades representada graficamente pelo DER

Para uma entidade, sempre aconselhvel a existncia de um atributo identi-

ficador, esse por sua vez, pode ser simples ou composto. O atributo identificador,
como o prprio nome diz, permite a identificao nica e exclusiva de uma ocor-
rncia de entidade. Todavia, em casos especiais, isso , em tipos especficos de
entidade, no encontraremos atributos identificadores. Esse tipo de entidade, a
qual no carece do uso de um atributo identificador chamado e entidade fraca.

CONEXO
Leia mais sobre Diagrama Entidade-Relacionamento (DER):
http://imasters.com.br/artigo/8568/banco-de-dados/documentacao-de-projetos-web-der/

Uma entidade fraca depende impreterivelmente da existncia de outra en-

tidade, dessa forma, sua existncia est vinculada a existncia de outra entida-
de. A identificao exclusiva de uma entidade fraca imposta pela associao
(mesclagem) do atributo identificador da entidade considerada proprietria, e
de sua chave parcial.

58 captulo 3
 Eventualmente, em casos pontuais, uma entidade fraca pode vir a ser subs-
tituda pelo uso de atributos multivalorados.
Na Figura 3.3, voc poder visualizar um exemplo de entidade caracterizada
como fraca. A entidade identificada como DEPENDENTE a nossa entidade
fraca, sobretudo por depender da existncia de um FUNCIONARIO. Repare que
at a representao grfica torna-se distinta (retngulo com linhas duplas e ou
linha responsvel pela conexo com o relacionamento possui mais espes-
sa), a fim de destacarmos a entidade fraca em um DER:

(1,n) (1,1)
Funcionrio possui Dependente

Cdigo Nome
Nome Sexo
Sobrenome Data_Nascimento

Figura 3.3 Entidade Fraca (Dependente)

3.2.2 Relacionamento

O uso do relacionamento nos permite realizar associaes entre as entidades.

Por exemplo, no basta simplesmente conhecermos os funcionrios de uma
determinada empresa, o projetista de dados dever associar um funcionrio a
uma empresa, permitindo que seja possvel alcanar algum tipo de informao
mais elaborada.

ATENO
Uma entidade pode ser considerada como sendo um objeto do mundo real ora podendo ser iden-
tificado de maneira unvoca. Esse objeto pode ser um elemento concreto, um evento, um ser, uma
especializao, uma funcionalidade ou qualquer outro elemento, tangvel ou no, do ambiente a
ser analisado (CASTRO, E. B. 2012).

captulo 3 59
 No diagrama entidade-relacionamento, um relacionamento representa-
do graficamente atravs do uso de um losango, ora conectado por meio de li-
nhas as entidades (retngulos). A Figura 3.4 a seguir nos permite visualizar um
exemplo de relacionamento, ora identificado de trabalha, representando o
vinculo existente entre as entidades FUNCIONARIO e EMPRESA.

Funcionrio trabalha Empresa

Figura 3.4 Exemplo de uso de relacionamento trabalha

Vamos agora analisar esse relacionamento, visualizado pela Figura 3.4,

que estabelece uma associao entre as entidades FUNCIONARIO e EMPRE-
SA. Ele nos permite referenciar as associaes entre o conjunto de entidades.
Isso , para o relacionamento trabalha, uma ocorrncia pode ser caracteriza-
da como um par de ocorrncias ora formada pelas ocorrncias das entidades
FUNCIONARIO e EMPRESA.
importante destacar que uma ocorrncia de relacionamento no ocorre ape-
nas entre entidades diferentes. O conceito de relacionamento nos permite asso-
ciarmos ocorrncias entre uma mesma entidade, formando o que chamamos de
auto-relacionamento (recursivo), como podemos observar na Figura 3.5 a seguir:

gerente

Funcionrio gerencia

gerenciado

Figura 3.5 Exemplo de um auto-relacionamento (recursivo)

Perfeito! A Figura 3.5 nos apresentou um exemplo do uso de um auto-rela-

cionamento, existente entre a entidade FUNCIONARIO. Entretanto, antes de
continuarmos, importante discorrermos sobre o conceito de uso de papis
em uma auto-relacionamento.

60 captulo 3
 O uso de papel em uma entidade vinculada em um auto-relacionamento
tem como objetivo promover a identificao correta de uma instncia da enti-
dade dentro de uma instncia do relacionamento, ou seja, uma ocorrncia de
funcionrio poder desempenhar o papel de gerente e a outra ocorrncia de
funcionrio, por sua vez, poder assumir o papel de gerenciado.

3.2.3 cardinalidade

Em algumas literaturas, podemos encontrar o termo cardinalidade sendo refe-

renciado como multiplicidade. Uma cardinalidade pode ser vista como sendo um
exemplo de restrio existente em um diagrama entidade-relacionamento (DER) a
fim de atender adequadamente as eventuais exigncias do banco de dados.
Para ilustrar um exemplo aplicado a Figura 3.6, observe as cardinalidades
mximas no DER abaixo:

N 2
Funcionrio trabalha Empresa

Figura 3.6 Exemplo do uso da cardinalidade mxima

Na sequncia, torna-se possvel realizarmos a interpretao da cardinalidade

mxima imposta sobre as entidades nomeadas de FUNCIONARIO e EMPRESA.
A entidade FUNCIONARIO apresenta uma cardinalidade mxima ilimitada
(muitos), essa podendo ser representada pelas letras N ou M. Dessa ma-
neira, uma empresa pode ter at N funcionrios trabalhando nela. Por outro
lado, a entidade EMPRESA apresenta uma cardinalidade mxima 2, por sua
vez, nos habilita interpretar que um FUNCIONARIO pode trabalhar em no m-
ximo 2 empresas.
Considere o prximo exemplo, esse representado pela Figura 3.7. Repare
que utilizamos simultaneamente a representada das cardinalidades mnima e
mxima. Observe tambm que um FUNCIONARIO pode coordenar no mximo
2 (dois) projetos, e por sua vez, um PROJETO pode ser coordenado por no m-
ximo um funcionrio.

captulo 3 61
 (1,1) (0,2)
Funcionrio coordena Projeto

Figura 3.7 Utilizao das cardinalidades mxima/mnima

Agora que realizamos uma breve apresentao do uso de cardinalidades

mxima e mnima, possvel descrever os principais tipos de cardinalidades
aplicados em relacionamentos binrios. Um detalhe, no se esquea de que,
possvel aplicar esses mesmos tipos de cardinalidades em um auto-relaciona-
mento, isso , em um relacionamento formado por uma nica entidade (rela-
cionamento unrio).
O primeiro tipo de cardinalidade um-para-um, por exemplo, um empre-
gado gerencia apenas um departamento, que por sua vez, gerenciado por um
nico empregado, conforme visualizado na Figura 3.8 abaixo:

1 1
Funcionrio gerencia Departamento

Figura 3.8 Cardinalidade 1:1

O segundo tipo de cardinalidade um-para-muitos, para exemplificar, con-

sidere que um empregado gerencia apenas um departamento; todavia, um de-
partamento pode ser gerenciado por muitos empregados, conforme apresenta-
do na Figura 3.9 a seguir:

N 1
Funcionrio gerencia Departamento

Figura 3.9 Cardinalidade 1:N

62 captulo 3
 J o terceiro tipo de cardinalidade a ser estudada, refere-se a muitos-para-
-muitos, como exemplo, considere que um empregado gerencia muitos depar-
tamentos, e que, por sua vez, um departamento pode ser gerenciado por muitos
empregados. Esse exemplo pode ser visualizado por meio da Figura 3.10:

N N
Funcionrio gerencia Departamento

Figura 3.10 Cardinalidade N:N

Voc j deve ter percebido que at o presente momento, no que tange a

exemplos de cardinalidade, utilizamos apenas relacionamentos binrios, isso
, relacionamentos com apenas duas entidades envolvidas. No existe nenhum
problema quanto a isso, sobretudo por podermos utilizar o mesmo conceito de
cardinalidade (multiplicidade) em outros graus de relacionamentos, a citar como
exemplo, o relacionamento ternrio, ora representado pela Figura 3.11 abaixo:

(1,n) (0,1)
Cidade distribuio Distribuidor

(0,n)

Produto

Figura 3.11 Cardinalidade em relacionamento ternrio

Mediante esse exemplo acima apresentado, vamos realizar a devida interpre-

tao para elucidar eventuais dvidas pertinentes ao conceito de cardinalidade.
Cada ocorrncia do relacionamento intitulado de distribuio vincula trs ocor-
rncias de entidade, ou seja, um produto poder ser distribudo, em uma determi-
nada cidade, onde realizada a distribuio, por um nico e exclusivo distribuidor.

captulo 3 63
 Bem, para clarear ainda mais esse conceito, quando nos depararmos com
relacionamentos de duas (binrio), trs (ternrio), ou n (nrio) entidades, a
cardinalidade a ser aplicada trabalha de maneira anloga a cardinalidade apli-
cada em relacionamentos binrios, isso , torna-se necessrio trabalharmos
com pares de entidades.
No exemplo da Figura 3.11, dizemos que as ocorrncias provenientes das
entidades CIDADE e PRODUTO esto associadas a , no mximo uma ocorrncia
de DISTRIBUIDOR.

3.2.4 Atributo

No modelo entidade-relacionamento MER, possvel realizar a especificao de

propriedades relacionadas s entidades. Essas propriedades so nomeadas de
atributo. Um atributo promove mecanismos para que seja possvel associar infor-
maes a ocorrncias de entidades e ou relacionamentos. Resumidamente, um
atributo tem como propsito vincular um determinado dado a cada ocorrncia de
uma entidade especfica ou, eventualmente, at mesmo a um relacionamento.
Aps apresentarmos o conceito de um atributo, podemos estender nosso
aprendizado sobre os vrios tipos de atributos existentes, como tambm apre-
sentar suas devidas utilizao. Os detalhes so apresentados logo a seguir:
Atributo Simples: tipo de atributo que armazena um dado atmico, ou
seja, um dado considerado indivisvel;
Atributo Composto: considerado como sendo um tipo especial de atribu-
to, pelo simples fato de permitir que sejam vinculados a ele diversos da-
dos segmentados de forma isolada por meio de outros atributos. Similar
ao atributo simples, um atributo composto tambm carece de que o dado
seja atmico. Como exemplo, podemos mencionar o atributo endereo,
pois, o mesmo possui vrios dados, como tipo de logradouro, o prprio
logradouro, nmero, complemento, bairro, cidade, CEP e estado;
Atributo Multivalorado: esse atributo permite armazenar vrios dados
para uma nica entidade. Um exemplo clssico para o uso desse tipo de
atributo o nmero de telefone de uma determinada pessoa. Atualmen-
te, uma pessoa pode ter dois ou mais nmeros de telefones, a citar, tele-
fone fixo e telefone celular de mais de uma operadora;

64 captulo 3
 Atributo Derivado: o atributo derivado armazena um dado proveniente
de um processamento especfico. Por exemplo, o atributo idade de uma
pessoa qualquer pode ser obtido a partir do processamento da data de
nascimento e data atual do aplicativo computacional;
Atributo Identificador: tipo de atributo imprescindvel em uma entidade.
Esse atributo permite que identifiquemos exclusivamente uma ocorrncia
de entidade. O atributo identificador aplicado a uma entidade qualquer
pode ser um atributo simples ou composto. Para exemplificar, suponha a
existncia de uma entidade chamada de Pessoa. Voc consegue imaginar
os possveis atributos identificadores que poderamos utilizar para essa en-
tidade? Como possveis respostas, teramos o nmero do CPF, RG ou um
nmero identificador produzido automaticamente pelo banco de dados.

3.3 Modelo Entidade-Relacionamento Estendido

No modelo entidade-relacionamento estendido apreenderemos como iden-

tificar eventuais cenrios os quais o uso apenas dos conceitos de entidade e
relacionamento visto at o momento no suficiente para a realizao da mo-
delagem de dados. Nesse tpico aprenderemos como utilizarmos agregao,
generalizao e especializao de entidades como tambm elaborar um banco
de dados completo com o uso do modelo entidade-relacionamento estendido.

3.3.1 Entidade Especializada

importante mencionar que o modelo entidade-relacionamento estendido

contempla todos os conceitos de modelagem apresentados no modelo entida-
de-relacionamento, incluindo novos conceitos sobre subclasse e superclasse
como ainda, os conceitos pertinentes a especializao e generalizao.
O nosso primeiro conceito referente ao modelo entidade-relacionamento
estendido discorre sobre a subclasse, que por sua vez, refere-se a um determi-
nado tipo de entidade ora utilizada para contemplar uma entidade especfica e
ou ainda, uma coleo de entidades que eventualmente podemos encontrar em
um esquema de banco de dados.

captulo 3 65
 Com o objetivo de exemplificar esse conceito de entidade especializada,
considere a entidade FUNCIONARIO que por sua vez tem como propsito des-
crever o tipo (atributos e relacionamento) de cada entidade de funcionrio em
um banco de dados qualquer. Normalmente, esse tipo de entidade pode vin-
cular diversos subgrupos ou subtipos de suas entidades que expressam algum
tipo de relevncia e carecem de ser representados de maneira correta.
No exemplo apresentado pela Figura 3.12, ser que voc consegue identifi-
car os tipos de entidade FUNCIONARIO existente? Vamos l! Considere que a
entidade do tipo funcionrio representada ora pelas entidades nomeadas de
secretria, engenheiro e tcnico. possvel interpretar que esse conjunto
de entidades esto por sua vez vinculadas ao um conjunto de entidades fun-
cionrio, isso , cada entidade considerada tambm membro de qualquer
um desses subtipos de funcionrio.
Sendo assim, o tipo de entidade nomeada de FUNCIONARIO considerado
superclasse (genrica) ou supertipo de cada uma das subclasses (especializadas).

CPF
data_nascimento
Funcionrio endereo
nome

CREA
velocidade_digitao Secretaria Tcnico Engenheiro
tipo_engenheiro

grau_tcnico

Figura 3.12 Exemplo de entidade genrica e entidades especializadas

Dessa maneira, podemos considerar que especializao um processo pelo

qual possvel determinar um conjunto de subclasses de um tipo de entidade.
Tal subconjunto de subclasses forma uma especializao tomando como refe-
rncia as variadas caractersticas da superclasse, a citar como exemplo, secre-
tria, engenheiro e tcnico, ou seja, simplesmente se refere s especializaes
da superclasse FUNCIONARIO, que distingue as entidades de funcionrio pelo
uso do tipo de cargo.

66 captulo 3
 Nesse contexto, o conjunto de entidades secretaria, inclui alm do atributo
especfico velocidade_digitao, os atributos CPF, nome, data_nascimento e
endereo, esses herdados da entidade FUNCIONARIOS.
Repare tambm que a uma instncia de secretria, por exemplo, tambm
considerada como uma instncia de funcionrio, ou seja, um determinado
membro da subclasse tambm se torna membro da superclasse, todavia, exer-
cendo funcionalidades distintas.
Outro quesito relevante refere-se a possibilidade de existir vrias especia-
lizaes do mesmo tipo de entidade, considerando apenas as propriedades
particulares, a citar como exemplo, outra especializao vinculada a entidade
funcionrio, que poderia refletir na criao de duas novas subclasses, essas no-
meadas respectivamente de FUNCIONARIO_MENSAL e FUNCIONARIO_HO-
RISTA, onde, evidentemente, a forma de realizar o pagamento ir diferenciar
os tipos de funcionrios.
Em uma extenso do Modelo ER, se cada entidade do conjunto de entida-
de genrica tiver que aparecer obrigatoriamente em um dos subconjuntos de
entidade especializada, considera-se que a especializao/generalizao sendo
como TOTAL.
Assumindo uma caracterstica oposta, uma especializao/generalizao
dita como PARCIAL quando uma entidade do conjunto de entidade genrica
no possuir a obrigatoriedade de aparecer como uma entidade de um dos sub-
conjuntos de entidade especializada.
Graficamente, o DER representa uma especializao/generalizao TOTAL
incluindo simplesmente a letra t em minsculo do lado superior direito do
tringulo utilizado para especificar as entidades especializadas. Entretanto, a
representao de uma especializao/generalizao PARCIAL dada pelo uso
da letra p, tambm em minsculo, do lado superior direito do tringulo.
Para exemplificar o uso de uma especializao/generalizao considerada
TOTAL, visualize a Figura 3.13 onde um determinado funcionrio poder ser
exclusivamente, secretria, tcnico e ou engenheiro. Nesse exemplo, no con-
sidere que um funcionrio no seja pelo menos uma secretria, um tcnico e
um engenheiro. Esse detalhe referente s possveis especializaes dos funcio-
nrios a serem aplicadas no projeto de banco de dados reportada no ato da
entrevista. Ainda assim, possvel nos depararmos com a possibilidade do pro-
jetista de dados especificar que um conjunto de entidade genrica dever ser
representada em mais de um conjunto de entidades especializadas.

captulo 3 67
 CPF
data_nascimento
Funcionrio endereo
nome

CREA
velocidade_digitao Secretaria Tcnico Engenheiro
tipo_engenheiro

grau_tcnico

Figura 3.13 Especializao/generalizao TOTAL (t)

Uma especializao/generalizao considerada como sendo EXCLUSIVA

quando cada entidade do conjunto de entidade genrica apresentar-se indispen-
savelmente no mximo em uma entidade do conjunto de entidade especializada.
O oposto de especializao/generalizao EXCLUSIVA dito pela possibilidade
de uma entidade do conjunto de entidade genrica apresentar-se como uma en-
tidade em mais de um dos conjuntos de entidade especializada. Esse tipo de es-
pecializao/generalizao denominado de COMPARTILHADA.
A fim de representar um exemplo de especializao/generalizao dita
como EXCLUSIVA, graficamente o DER utiliza a letra e em minsculo no lado
superior do tringulo. Todavia, para representar um tipo de especializao/ge-
neralizao COMPARTILHADA, tambm por meio do uso de um DER, simples-
mente adicionamos a letra c, tambm em minsculo no lado superior direito
do tringulo.
possvel ainda, a existncia de cenrios que permite o uso simultneo
de diversos tipos de especializao/generalizao, por exemplo, EXCLUSIVA e
TOTAL ou EXCLUSIVA e PACIAL, bem como, COMPARTILHADA e TOTAL ou
COMPARTIPLHADA e PARCIAL. Entretanto, em nenhuma circunstncia ser
permitido o uso de especializao/generalizao que paralelamente seja COM-
PARTILHADA e EXCLUSIVA ou TOTAL e PARCIAL.
Para exemplificao considere o MER representado pela Figura 3.14, verifi-
que que no existe nenhuma informao sobre a possibilidade de um determi-
nado tcnico tambm ser um engenheiro. Isso nos permite concluir que esse
exemplo de uma generalizao/especializao COMPARTILHADA.

68 captulo 3
 CPF
data_nascimento
Funcionrio endereo
nome

t,c

CREA
Tcnico Engenheiro
tipo_engenheiro

grau_tcnico

Figura 3.14 Especializao/generalizao do tipo COMPARTILHADA

Finalizando, conclui-se que todo esse processo de especializao permite

que seja possvel definir um conjunto de subclasses de um determinado tipo
de entidade, e ainda, incluir atributos especializados para as subclasses como
tambm especificar tipos de relacionamentos considerados exclusivos entre
cada subclasse e demais tipos de entidade ou ainda, outras subclasses.

3.3.2 Entidade Genrica

Uma entidade genrica caracterizada pelo processo inverso de abstrao o

qual exclumos as diferenas encontradas entre os diversos tipos de entidade.
Nesse processo, o objetivo identificar adequadamente as caractersticas con-
sideradas comuns, isso , generalizar em uma exclusiva superclasse.
Entendeu o conceito de entidade genrica? Est confuso?! No se preocupe,
apresentaremos um exemplo para desmistificar o conceito de generalizao.
Suponha a existncia de dois tipos de entidade, uma por sua vez, identifica-
da como CARRO e outra, identificada como CAMINHO, ambas visualizadas
pela Figura 3.15. Note que existem diversos atributos considerados comuns
entre as duas entidades, possibilitando que os mesmos sejam generalizados
na entidade VECULO. Dessa maneira, tanto CARRO quanto CAMINHO so
considerados subclasses da superclasse generalizada VECULO.

captulo 3 69
 Placa
Cdigo_veculo

Velocidade_mxima
Carro Preo
Nmero_passageiros

ID_veculo
Placa

Nmero_eixos
Caminho Preo
Capacidade_peso

Figura 3.15 Entidades especializadas CARRO e CAMINHO

Repare que foi realizado o processo oposto do processo de especializao,

cujo objetivo foi estabelecer a generalizao. Visualize por intermdio da Figu-
ra 3.16 que CARRO e CAMINHO tornam-se especializaes da entidade gen-
rica VECULO.

Cdigo_Veculo
Placa

Veculo Preo

t,c

Nmero_eixos Velocidade_mxima
Caminho Carro
Capacidade_peso nmero_passageiros

Figura 3.16 Generalizao (Veculo)

70 captulo 3
 Conclumos mais um tpico importante da disciplina de Modelagem de
Dados, explorando corretamente o recurso de herana, que permite que uma
subclasse herde as propriedades consideradas comuns da superclasse.

3.3.3 Entidade Associativa

Na elaborao de um projeto de banco de dados, a confeco de um diagrama

entidade-relacionamento (DER) exige que seja realizado eventuais descober-
tas, essas descobertas normalmente envolvem alguns tipos de entidades e seus
respectivos relacionamentos. Inicialmente, o projetista de banco de dados ela-
bora uma verso preliminar do projeto de banco de dados, e, com certeza, essa
verso preliminar receber novas sugestes/alteraes a fim de atender/lapidar
ainda mais os requisitos do negcio o qual se deseja armazenar os dados. Nor-
malmente, em uma verso final, tem-se um nmero considervel de entidades
e relacionamentos, deixando o DER na maioria das vezes indecifrvel. Para es-
sas ocasies, possvel que se realize o agrupamento de entidades para tentar
minimizar o nmero de entidades apresentadas no DER.
Essa associao entre entidades tambm caracterizado como um tipo
de entidade virtual, a qual utilizada para simbolizar vrias entidades e re-
lacionamentos no DER. Uma entidade associativa considerada virtual ou
abstrata pelo simples fato de no constituir efetivamente uma entidade final
vlida no DER.
J aprendemos em conceitos anteriores que, normalmente, em algumas si-
tuaes, torna-se imprescindvel associarmos uma entidade com a ocorrncia
de um relacionamento. importante voc recapitular que o MER no possibi-
lita em nenhuma circunstncia que seja realizado associaes entre relaciona-
mentos, apenas entre entidades. Sendo assim, uma entidade associativa tem
como propsito vincular um relacionamento como se o mesmo fosse uma enti-
dade, conforme apresentado como exemplo pela Figura 3.17.

(0,n) (0,n)
Mdico consulta Paciente

Figura 3.17 Agrupamento entre entidades (agregao)

captulo 3 71
 Caso, eventualmente, fosse necessrio controlar os medicamentos pres-
critos por um determinado mdico aps a realizao de uma consulta, seria
necessrio vincular a entidade MEDICAMENTO com uma ocorrncia de uma
consulta, associando a entidade MEDICAMENTO com o relacionamento CON-
SULTA. provvel que voc esteja achando isso tudo muito estranho. De fato
voc tem razo, pois essa manobra no permitida. No se deve realizar esse
vnculo dessa maneira, a fim de solucionar o problema exposto, aconselhado
que o relacionamento CONSULTA torne-se uma entidade associativa, ora re-
presentada graficamente atravs de um retngulo envolto do relacionamento.
A Figura 3.18 apresenta um exemplo do uso de uma entidade-associativa que
envolveu por sua vez as entidades MDICO e PACIENTE, essas intituladas a
partir do processo associativo de CONSULTA.

(0,n) (0,n)
Mdico consulta Paciente

prescreve

(0,n)
Medicamento

Figura 3.18 Agrupamento das entidades Mdico e Paciente resultando na entidade

associativa Consulta

72 captulo 3
 Esse processo tambm denominado de agregao, isso , um conjunto de
relacionamentos e suas respectivas entidades so agregadas em uma nova enti-
dade. Dessa forma, o exemplo exposto pela Figura 3.18 agrega o relacionamen-
to CONSULTA juntamente com as entidades MDICO e PACIENTE, constituin-
do uma nova entidade ora chamada de CONSULTA. Em algumas ocasies, no
necessrio estabelecer um nome para a nova entidade criada aps o processo
de agregao.
Na prxima Figura 3.19 possvel visualizar um exemplo de agregao apli-
cada no DER ora representado graficamente por um retngulo que por sua vez
engloba as entidades e o relacionamento envolvido no processo. Ainda nos
permitido aplicar cardinalidades mnima e mxima no conjunto de relaciona-
mentos constituintes da agregao. Para exemplificar, considere que uma de-
terminada consulta pode ou no ter a prescrio de medicamentos.

(0,n) (0,n)
Mdico consulta Paciente

prescreve

(0,n)
Medicamento

Figura 3.19 Entidade associativa

captulo 3 73
3.4 Diagrama Entidade-Relacionamento (DER)

Antes de iniciarmos esse novo tpico, considere o diagrama entidade-relacio-

namento de um banco de dados de uma empresa imaginria, ora representado
pela Figura 3.12 abaixo:

Nmero
Pnome Snome
Nome Localizao

Nome Endereo N 1
TRABALHA PARA
Sexo Salrio
Nss consulta

EMPREGADO DataIncio NmeroDeEmpregados DEPARTAMENTO

DataNasc
1 1 1
supervisor GERENCIA

supervisiona SUPERVISIONA

1 N Horas
SUPERVISIONA

N
M N
1 TRABALHA EM PROJETO

DEPENDENTE DE Nome
Localizao
N Nmero

DEPENDENTE

Nome Sexo DataNasc Relao

Figura 3.12 Exemplo de Diagrama Entidade-Relacionamento

Com o conhecimento exposto at o momento, voc certamente j identificou

as principais entidades, essas intituladas de EMPREGADO, DEPARTAMENTO e
PROJETO, que por sua vez, so representadas graficamente pelo uso de retn-
gulos. J os relacionamentos nomeados de TRABALHA_PARA, GERENCIA, CON-
TROLA e TRABALHA_EM utilizam a representao grfica atravs do uso de lo-
sangos. Esses relacionamentos tm como intuito realizar a conexo das diversas

74 captulo 3
entidades participantes do modelo de dados ora proposto, a fim de atender as
necessidades de uma regra de negcio especfica. Os atributos (propriedades das
entidades) so representados graficamente por meio do uso de elipses conecta-
das as entidades e ou, eventualmente, vinculadas aos relacionamentos. Existe
ainda uma forma de representar atributos compostos, onde esses tambm so
representados graficamente pelo uso de elipses, todavia, so associados aos atri-
butos o qual depende, por exemplo, o atributo NOME composto pelos atributos
PNOME (primeiro nome) e SNOME (sobrenome). Outro detalhe que podemos
abstrair diz respeito aos atributos multivalorados. Sua denotao dada por
meio de elipses circundada por linhas duplas, para exemplificar, repare o atri-
buto LOCALIZAO da entidade DEPARTAMENTO. Os atributos identificadores
(atributos-chaves e ou chave-primria) so identificados por sua vez na forma su-
blinhada, dentro da elipse. Como o prprio nome sugere, os atributos derivados
so simbolizados pelo uso de elipse circundada de linhas tracejadas, a citar como
exemplo, considere o atributo ora intitulado de NmeroDeEmpregado perten-
cente a entidade DEPARTAMENTO. Em algumas literaturas voc pode encontrar
o conceito de que esse tipo de atributo (derivado) tambm chamado de atributo
processado, isso , o valor atrelado a esse tipo de atributo estar sempre associa-
do a algum tipo de processamento computacional.
J a identificao de entidades e relacionamentos considerados fracos im-
posta pelo uso de retngulos e losangos circundados com linhas duplas. Em
nosso exemplo (Figura 3.12), podemos destacar esse conceito, ora representa-
do pela entidade-fraca, identificada de DEPENDENTE e seu respectivo relacio-
namento, esse nomeado de DEPENDENTE_DE.
Esmiuando ainda mais nosso exemplo de DER, apresentado pela Figura
3.12, possvel obter informaes acerca das cardinalidades (multiplicidade)
aplicada para cada relacionamento de grau 2 (relacionamento binrio). Como
exemplo, podemos citar a cardinalidade 1:1 existente entre o relacionamento
GERENCIA que associa as entidades DEPARTAMENTO e EMPREGADO. A inter-
pretao dessa cardinalidade seria: um empregado gerencia no mximo um de-
partamento e, por sua vez, um departamento gerenciado por no mximo um
empregado. Outra cardinalidade digna de exemplo a cardinalidade referente
ao relacionamento TRABALHA_PARA que vincula as entidades DEPARTAMEN-
TO e EMPREGADO, essa cardinalidade dita como 1:N (um para muitos)
e M:N (muitos para muitos) para o relacionamento TRABALHA_EM. Com
relao a representao grfica utilizada para sinalizar uma restrio de parti-

captulo 3 75
cipao parcial, utiliza-se o emprego de linhas simples, todavia, quando neces-
sitamos de representar graficamente no DER uma dependncia existente entre
entidades, utilizamos linhas paralelas.
Outro detalhe considerado relevando que devemos prestar muita ateno,
discorre sobre a existncia de um auto-relacionamento. Vimos anteriormente
que, quando existe um auto-relacionamento em um DER qualquer, funda-
mental o uso de papis a fim de identificar adequadamente qual o tipo de
relacionamento desempenhado em um determinado instante. Como exemplo,
considere ainda o nosso DER da Figura 3.12, o auto-relacionamento nomeado
de SUPERVISIONA assume o uso de dois papis dspares, ou seja, ora o empre-
gado assume o papel de SUPERVISOR ora o papel de SUPERVISIONADO.

3.4.1 Grau de Relacionamento

Para determinar o grau de um relacionamento devemos analisar o nmero de

entidades participantes do mesmo relacionamento. Dessa maneira, possvel
identificar como grau um (tambm chamado de unrio) um relacionamento
que utiliza apenas uma entidade, por outro lado, um relacionamento de grau
dois (binrio) aquele que faz uso de duas entidades, grau trs (ternrio) utiliza
trs entidades e grau n (nrio) faz uso de mais de trs entidades. Em nosso
prximo DER, ora representado pela Figura 3.13, podemos visualizar um rela-
cionamento ternrio.

Quantidade
Cdigo Nome

Fornecedor fornece Projeto

Cdigo Nome
Nmero Pea

Figura 3.13 Relacionamento ternrio (grau trs)

76 captulo 3
 A Figura 3.14 nos demonstra um DER a fim de exemplificar um relaciona-
mento binrio. Repare que o relacionamento intitulado de CURSO emprega
apenas dias entidades (ALUNO e DISCIPLINA).

RA Nome

Aluno fornece Disciplina

Cdigo Nome

Figura 3.14 Relacionamento binrio (grau dois)

A Figura 3.15 nos apresenta outro exemplo, onde possvel identificarmos que
o grau do relacionamento CASAMENTO unrio (grau um), simplesmente por
existir uma nica entidade, essa chamada de PESSOA. Voc no deve se esquecer
de que, quando fazemos uso de um relacionamento unrio, imprescindvel o em-
prego de papis. Nesse tipo de relacionamento, os papis possui um importante
objetivo, o qual representar corretamente uma associao entre ocorrncias de
uma mesma entidade (isso , ora pessoa assume o papel homem ora pessoa as-
sume o papel mulher).

CPF Nome

Homem

Pessoa casamento

Mulher

Figura 3.15 Relacionamento unrio (grau um)

captulo 3 77
 Finalizando o tpico que discorre sobre o grau dos relacionamentos, pos-
svel visualizarmos por meio da Figura 3.16, um exemplo de relacionamento
nrio, ou seja, possvel abstrair uma associao entre n (diversas) ocor-
rncias de entidades.

Quantidade
CPF CNPJ Nome
Nome

Candidato realiza Empresa

Entrevista resultado Trabalho

Depto/Data

Departamento Data

Figura 3.16 Exemplo de relacionamento nrio (vrias entidades)

Voc deve ter percebido as variadas notaes utilizadas para representar

uma entidade, entidade-fraca, relacionamento, atributo, atributo identifi-
cador, etc., em um diagrama entidade-relacionamento (DER). A Tabela 3.1 a
seguir apresenta as diversas notaes com suas respectivas descries, empre-
gadas at o presente momento nos exemplos de DER. Lembrando que, even-
tualmente, essas representaes grficas (smbolos) podem sofrer variao
dependendo o tipo de ferramenta utilizada na elaborao dos diagramas enti-
dade-relacionamento.

78 captulo 3
NOTAO (SIMBOLOGIA) DESCRIO

Entidade

Entidade-Fraca

Relacionamento

Relacionamento Identificador

Atributo

Atributo-chave (identificador)

Atributo Multivalorado

captulo 3 79
 NOTAO (SIMBOLOGIA) DESCRIO

Atributo Composto

Atributo Derivado

3.5 Modelando o negcio

Bem, agora que voc j aprendeu basicamente todos os conceitos sobre o dia-
grama entidade-relacionamento, chegou o momento de coloca-los em prtica.
A descrio dos requisitos a seguir, permite que utilizemos uma entidade-fraca.
Sendo assim, vamos elaborar a partir desses requisitos o DER que completa em sua
totalidade, as regras do negcio, ora representado por uma universidade fictcia.
Uma universidade deseja implantar um Sistema de Informao para realizar
o gerenciamento da quantidade de carteiras por sala de aulas existentes nos seus
vrios Campus. Hoje, essa universidade possui 5 campus, localizados em regies
(cidades) distintas. Em cada campus existe blocos de salas. Cada campus possui
um nmero sequencial utilizado para identificao e cada bloco de salas, por sua
vez, identificado por uma letra. As salas so numeradas de forma sequencial
dentro de cada bloco. desejvel que o sistema de informao disponibilize al-
gumas informaes, como por exemplo: nome e endereo de cada um dos Cam-
pus; para cada campus, quais so os blocos de sala de aula e para cada bloco qual
o nmero de salas que possui, juntamente com a quantidade de andares; para
cada sala de aula, importante conhecer o nmero de carteiras, seu tamanho
(rea) e quais so as carteiras existente em cada sala (nmero do patrimnio da
carteira e se o brao de apoio est localizado do lado direito ou esquerdo).
Aps abstrairmos os requisitos necessrios, podemos confeccionar uma
verso preliminar do DER, o qual deve atender de forma adequada todas as fun-

80 captulo 3
cionalidades expostas na descrio do Sistema de Informao a ser criado pela
Universidade. A Figura 3.17 apresenta um exemplo de DER que teve como pro-
psito atender os requisitos triviais do Sistema de Informao da Universidade.
Voc pode identificar a utilizao de duas entidades-fracas, uma chamada de
bloco e outra de sala de aula. Visualize os detalhes pertinentes a essas enti-
dades-fracas no box cinza.

QtdeSalas
(1,1) (0,n)
Campus possui Bloco TotalAndares
IdentBloco
(0,n)
EndCampus Campus x Bloco:
NomeCampus cada instncia desse conjunto
IdentCampus ser identificada por
(IdentCampus + IdentBloco)
localizada

(0,n)
NroSala
(0,n) (1,1)
Carteira alocado Sala de aula MetragemSala
QtdCarteirasSala

LadoBraoCart Sala de Aula:

a identificao unvoca de
NroPatrimnio cada sala dada por
(IdentCampus + IdentBloco + NroSala)

Figura 3.17 DER de uma Universidade Fictcia

ATIVIDADE
9. Conceitue adequadamente um atributo, e discorra sobre os seus principais tipos. Na
sequncia, d pelo menos um exemplo de cada tipo.

10. Conceitue um relacionamento e classifique os relacionamentos em relao ao nmero

de objetos envolvidos.

11. Imagine um contexto acadmico, o qual, poderamos considerar uma sala de aula. Qual
seria a cardinalidade mxima de um professor em relao aos alunos, como tambm,
dos alunos em relao ao professor?

captulo 3 81
 REFLEXO
Parabns! Voc finalizou mais um captulo, essa sem dvida foi uma densa unidade de estu-
dos! Foi possvel aprendermos acerca das principais caractersticas do Modelo Entidade-Re-
lacionamento, e como esse modelo se torna imprescindvel para a criao de um bom projeto
de banco de dados.
Acreditamos que voc tenha maximizado seu conhecimento referente ao MER, como seus
principais componentes, a citar: tipos de entidades, relacionamentos, cardinalidade (um-para-
-um; um-para-muitos e muitos-para-muitos), tipos de atributos (simples, composto, multiva-
lorado, derivado e identificador).
Foi possvel ainda estudarmos acerca da representao grfica do MER, essa imposta pelo
uso do que chamamos de diagrama entidade-relacionamento (DER), sobretudo interpretar-
mos corretamente o grau dos relacionamentos existentes nele.
Voc consegue lembrar-se dos principais graus que podemos abstrair de um determinado
relacionamento?
O grau de um relacionamento factvel de ser abstrado levando em considerao o nmero
de entidades participantes (unrio, binrio, ternrio, quaternrio e nrio).

LEITURA
Artigos on-line: para voc aumentar ainda mais o seu nvel de conhecimento sobre os
MER e DER:
http://www.devmedia.com.br/projeto-de-bd-tatico-para-informacoes-da-concorrencia/31392
http://imasters.com.br/artigo/8568/banco-de-dados/documentacao-de-projetos-web-der/

Livros:
Modelagem Lgica de Dados: construo bsica e simplificada, de Eduardo Bernardes Castro.
Banco de Dados: Implementao em SQL, PL/SQL e Oracle 11g, Sandra Puga, Edson Frana
e Milton Goyga;
Nestes livros voc encontra um bom contedo para complementar os estudos apresentados
pela apostila. Aprofunde seus conhecimentos!

82 captulo 3
 REFERNCIAS BIBLIOGRFICAS
ELMASRI, R.; NAVATHE, S.B. Sistemas de bancos de dados. So Paulo: Pearson (Addison
Wesley), 2005.

KORTH, H.; SILBERCHATZ, A. Sistemas de bancos de dados. 3. ed. So Paulo: Makron

Books, 1998.

HEUSER, C. A. Projeto de Bancos de Dados. 2. ed. Porto Alegre: Sagra Luzzatto, 1999.

PRESSMAN, R.S. Engenharia de software. So Paulo: Makron Books, 1995.

ROB, P.; CORONEL, C. Sistemas de Banco de Dados: Projeto, Implementao e Administra-

o. 8. Ed. So Paulo: Cengage Learning, 2011.

SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de Banco de Dados. 5. ed. Rio
de Janeiro: Elsevier, 2006.

DATE, C. J.; Introduo a Sistemas de Banco de Dados; 8. Ed.; Trad. Daniel Vieira; Rio de
Janeiro: Elsevier, 2003.

HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4 ed. Instituto de Informtica da UFR-
GS, Sagra DC Luzzatto, 1998.

RAMAKRISHNAN, R. GEHRKE, J. Database Management Systems. 2. ed. Boston: McGraw-

-Hill, 2000.

TEOREY, T.; LIGHTSTONE, S.; NADEAU, T.; JAGADISH, H. V.; Database Modeling and De-
sign Logical Design. 5 ed., Burlington USA: Elsevier, 2011.

CASTRO, E. B.; Modelagem Lgica de Dados: construo bsica e simplificada; Rio de Ja-
neiro: Editora Cincia Moderna, 2012.

PUGA, S.; FRANA, E.; GOYA, M.; Banco de Dados Implementao em SQL, PL/SQL e
Oracle 11g; So Paulo: Pearson Education do Brasil, 2013.

captulo 3 83
 NO PRXIMO CAPTULO
No prximo captulo iremos esmiuar o modelo de dados relacional! Pratique exaustivamente
modelagem de dados, os tipos de relacionamentos e os seus principais conceitos.

84 captulo 3
 4
Modelo de Dados
Relacional
4 Modelo de Dados Relacional
No captulo anterior estudamos acerca dos modelos de dados, com sua evoluo e
a importncia de compreend-los para que seja possvel a elaborao de um proje-
to de banco de dados bem estruturado.
Caso voc tenha alguma dvida sobre algum conceito, retorne a unidade anterior e
realize uma reviso dos principais conceitos!
Estudamos profundamente sobre os principais modelos de dados, vamos a partir
de agora dar nfase no modelo relacional, o qual considerado um modelo clssi-
co, e amplamente adotado pela grande parte dos SGBDs. Estudaremos os concei-
tos e princpios relevantes, como os atributos identificadores, restries de integri-
dade, mapeamento do MER para o modelo relacional, dentre outros.
No perca o foco neste contedo!

OBJETIVOS
Este captulo tem como objetivo permitir um estudo detalhado referente aos aspectos perti-
nentes ao modelo de dados relacional, onde, seus principias conceitos podem ser encontra-
dos nos principais SGBDs comerciais. Esperamos que ao final desta unidade voc seja capaz
de compreender o funcionamento do uso de chave primria e estrangeira, como as regras de
integridade de entidade e referencial so imprescindveis para promover a integridade dos
dados, alm de, estudarmos atravs de exemplos prticos a tarefa do mapeamento do MER
para o modelo de dados relacional.

REFLEXO
Voc se lembra dos conceitos estudados na unidade anterior?
Quanto aos principais graus aplicados aos relacionamentos?
Voc se sente confortvel em discorrer sobre os principais componentes de um DER?
Voc se encontra confortvel em distinguir adequadamente os conceitos acerca dos Mode-
los de Dados: Hierrquico, em Rede e Relacional?

86 captulo 4
4.1 Modelo De Dados Relacional

O Modelo de Dados Relacional foi criado por Codd na dcada de 70. Esse mo-
delo de dados caracterizado por ser o mais simples dos modelos de dados
disponveis para implementao de banco de dados. Tal modelo possui como
objetivo a apresentao dos dados similar a um conjunto de relaes. Dessa
maneira, podemos comparar uma relao como sendo uma possvel tabela, ou,
simplesmente, um simples arquivo contendo n registros.
O Modelo de Dados Relacional calcado no conceito de matrizes. Podemos
considerar que as linhas em uma matriz como sendo os registros e as colunas, seus
respectivos campos. Os identificadores das tabelas (relao) e dos campos so de
extrema relevncia para seu entendimento entre o que voc est armazenando,
onde est armazenando e qual a relao existente entre os dados armazenados.
Como exemplo, tomamos a Figura 4.1, que estrutura os dados por meio do
uso de um modelo de dados relacional.

RA Nome Sala Departamento

tb_Aluno 192 Ana Paula 1 Computao

324 Ceclia 2 Computao

Departa-
Cdigo Nome Crditos
mento

C123 ICC 4 Computao

tb_ Disci- Estrutura de

C342 4 Computao
plina Dados

M098 Clculo I 4 Matemtica

Banco de
C124 4 Computao
Dados

captulo 4 87
 Cdigo Pr_requisito

C124 C324
tb_pr_requisito
C124 M098

C324 C123

Cdi- Discipli- Semes-

Ano Professor
go na tre

Prof. Ms. Frederi-

45 C123 1 2012
co Valeri

Prof. Dr. Rodrigo

52 C324 2 2012
Mendes

tb_se- Prof. Ms. Jos

124 C124 1 2013
o Ribeiro

Profa. Ms. Valria

132 M098 1 2012
Cruz

Prof. Dr. Jean

139 C324 2 2013
Nunes

Prof. Ms. Givanil-

155 C124 1 2013
so Martins

88 captulo 4
 RA Cdigo_Seo Nvel

192 155 B

192 139 B

tb_histrico 324 132 A

324 124 A

324 52 A

324 45 B

Figura 4.1 Exemplo de um Modelo de Dados Relacional

As relaes apresentadas pela Figura 4.1 podem ser vistas tambm como
tabelas. Em uma tabela, uma linha representa um registro (tupla), isso uma
coleo de valores relacionados. Nesse contexto, esses valores referem-se a um
fato de uma entidade especfica, ou at mesmo uma instncia de um relacio-
namento qualquer. Vimos no incio do tpico que o nome da tabela com os no-
mes das respectivas colunas so cruciais para que seja possvel interpretarmos
o correto sentido dos valores em cada linha (tupla) existente em uma tabela.
Bem, voc conseguiu entender esse conceito? No se preocupe! Vamos agora
interpretar as relaes pertinentes a Figura 4.1. factvel identificarmos que a
tabela ora nomeada de tb_aluno, cada linha (tupla) diz respeito a um fato espe-
cfico ora armazenado nessa tabela. Suas colunas, essas identificadas como RA
(registro acadmico), nome, sala e departamento possibilitam que realizemos
a devida interpretao dos valores vinculados para cada linha (tupla). Conside-
re que, para cada coluna, todos os valores associados a mesma, dever, obriga-
toriamente, manipular o mesmo tipo de dado.

captulo 4 89
 Na maioria das literaturas que discorre sobre o tema Modelo Relacional,
uma linha caracterizada como sendo uma tupla, uma coluna como um atri-
buto e uma tabela de relao. Ainda tomando como referncia o modelo rela-
cional, o conceito de domnio refere-se ao tipo de dados que ser armazenado
em uma coluna qualquer. O grau de uma relao interpretado pelo nmero de
atributos existentes nela.
A fim de esclarecer o grau de uma relao, considere a relao ora apresen-
tada abaixo, que por sua vez, apresenta informaes referentes aos alunos de
uma universidade qualquer:

Aluno (ra, nome, endereo, telefone, celular, idade, media_ponderada).

Nessa relao, consideramos que aluno o nome da relao, a qual possui

sete atributos, por isso podemos interpretar que essa relao de grau sete.
possvel ainda, detalhar alguns domnios para cada atributo presente na re-
lao aluno, por exemplo, o domnio RA (registro acadmico numrico ou
literal), nome (nomes dos alunos - literal), telefone (nmero do telefone fixo
numrico ou literal), celular (nmero do telefone mvel numrico ou literal)
e media_ponderada (valor correspondente a mdia ponderada de um determi-
nado aluno - numrico).
A Figura 4.2 nos apresenta a relao intitulada de aluno, onde podemos
abstrair que cada tupla (linha) representa uma entidade aluno. Essa relao
representada por sua vez como uma tabela considera cada tupla como sendo
uma linha e, cada atributo existente nessa tabela, como um cabealho que, tem
como propsito indicar um papel especfico ou simplesmente promover a in-
terpretao dos valores vinculados a cada coluna.

90 captulo 4
 Mdia
RA Nome Endereo Telefone Celular Idade
Ponderada

3412-
123 Alice Martins Rua Piau, 87 null 21 6,5
0909

Av. Pio XII, 9123-

324 Marcia Garcia null 26 7,8
1562 0989
Aluno
Rua Treze de 8345-
709 Bruno Freitas null 19 9,0
Maio, 98 0912

3634-
21 Murilo Henrique Rua Javari, 23 null 20 4,8
0987

Av. Nove de 8723-

523 Igor Afonso null 23 7,0
Julho, 23 8877

Figura 4.2 Tabela aluno com suas respectivas instncias

captulo 4
}
91
 ATENO
Um domnio descreve os tipos de dados que cada campo (atributo) pode armazenar. (Heuser,
2004)

4.2 Chave Primria (Atributo Identificador)

Com os conceitos estudados at o presente momento, j aprendemos que uma

relao considerada como um conjunto de tuplas. Devemos considerar que,
todos os elementos constituintes desse conjunto de tuplas devem ser exclusi-
vos, isto significa que, absolutamente nenhuma tupla dever possuir a mesma
combinao de valores para todas as suas colunas. Isso significa que, em uma
relao, eventuais subconjuntos de atributos no podem conter tuplas com a
mesma combinao de valores. Sendo assim, conclui-se que toda a relao deve
conter pelo menos uma super-chave. Como exemplo, retornamos a Figura 4.2,
onde o atributo nomeado de RA (registro acadmico) considerado uma su-
per-chave da relao aluno por simplesmente no deixar que um mesmo aluno
possua o mesmo registro acadmico.

CONEXO
Como sugesto, aconselhamos a leitura deste artigo, para aprofundar seus conhecimentos
no que diz respeito ao modelo relacional:
http://imasters.com.br/artigo/2419/banco-de-dados/o-modelo-relacional-de-dados-parte-01/
http://imasters.com.br/artigo/5403/banco-de-dados/modelagem-de-dados-parte-
05-transformacao-entre-modelos/

Um valor vinculado a um atributo-chave utilizado para distinguir de manei-

ra exclusiva uma tupla em uma relao especfica. Ou seja, o valor 21, do atributo
RA, utilizado exclusivamente para identificar a tupla vinculada ao aluno Murilo
Henrique, ora existente na relao ALUNO. importante escolher corretamente
o atributo-chave de uma relao, principalmente se considerarmos que o mes-
mo no poder sofrer modificaes no transcorrer do tempo. A fim de melhor
exemplificar, possvel dizer que o atributo NOME da mesma relao ALUNO

92 captulo 4
no dever, em hiptese alguma, ser escolhido como atributo-chave, sobretudo
por, no possuirmos garantia da no existncia de nomes idnticos.
Na maioria das vezes, em uma relao poder existir mais de um atributo-chave.
Para atender essas particularidades, cada chave referenciada como chave-candi-
data. Voltamos ao exemplo ora apresentado pela Figura 4.2, em algumas ocasies,
seria permitido adicionar um atributo chamado de CODIGO_ALUNO (surrogate
key) para identificar exclusivamente um determinado aluno por meio de um cdi-
go interno. Nessa circunstncia, a relao ALUNO teria duas chaves-candidatas, o
atributo RA e CODIGO_ALUNO. Esse recurso considerado normal, isso , relati-
vamente comum escolhermos duas chaves-candidatas como chave-primria (atri-
buto-chave) de uma relao. No modelo de dados relacional, representamos uma
chave-primria, simplesmente sublinhando os atributos que formam a chave-can-
didata. Se, eventualmente, uma relao possuir vrias chaves-candidatas, a escolha
da chave mais adequada se torna facultativa, porm, a seleo da chave-primria
com o menor nmero de atributos sempre desejvel.

ATENO
Uma chave-candidata uma chave que apresenta obrigatoriamente as duas caractersticas
a seguir:
1)Unicidade: No h duas linhas (tuplas) distintas na tabela com o mesmo valor para os atri-
butos da chave (isso j era garantido na chave e foi explicado na seo anterior);
2)Irredutibilidade: No existe um subconjunto de atributos da chave que apresentem a ca-
racterstica de Unicidade.
(Date, 2004)

Uma chave-primria inclui algumas caractersticas relevantes, a considerar

a seguir:
Unvoca (exclusiva): os atributos definidos para constituir a chave-prim-
ria, por definio, tm que possuir valores nicos para cada registro (ou
tupla) na relao. Isso significa que todas as linhas devem ser identifica-
das de maneira exclusiva por essa chave. Nesse contexto, mencionamos
que a tabela apresenta integridade de entidade;
No nula: nenhum dos atributos que constituem a chave primria pode-
r, em hiptese alguma, possuir valores nulos em nenhum registro;

captulo 4 93
 No redundante: no caso da chave-primria ser composta, no poder
ser adicionado mais atributos do que os mnimos necessrios para iden-
tificar os registros de forma unvoca.

Reflita: O que voc entende sobre redundncia controlada?

A redundncia controlada considerada um dos princpios do funciona-
mento dos bancos de dados relacionais, permitindo que distintas tabelas com-
partilhem um mesmo atributo.

4.3 Restries de Integridade

Em um esquema relacional, S formado por um conjunto de relaes S={R1,

R2, ..., Rn}, e, concomitantemente, por um conjunto de restries de integridade
(RI). Normalmente, atendemos duas consistncias, essas consideradas cruciais,
a citar Restrio de Integridade de Entidade (RIE) e a Restrio de Integridade
Referencial (RIR). A RIE tem como propsito garantir o acesso aos dados sem ne-
nhuma ambiguidade. Para exemplificar o emprego da RIE, considere uma tupla
qualquer, ora existente na relao R, dizemos que o valor de cada atributo que
constitui a chave-primria de (t) deve ser diferente de nulo e, ainda, no poder
haver uma outra tupla (t) em R com o mesmo valor da chave-primria de (t).
A fim de exemplificar a RIR, imagine uma tupla (t) e uma chave-estrangeira
(foreign key) em (t), o valor da chave-estrangeira pode ser nulo se e somente se
os atributos de chave-estrangeira no formarem a chave-primria de (t), e ain-
da, o valor da chave-estrangeira poder ser diferente de nulo apenas se existir
uma tupla (t) na relao referenciada tal que a chave-primria de (t) possuir o
mesmo valor da chave-estrangeira de (t).
Existem ainda, outras implicaes que devemos nos atentar referente a RIR,
por exemplo, suponha a existncia de duas relaes, essas identificadas de R1 e
R2, respectivamente e uma chave-estrangeira (fk) aplicada R1 que referencia
por sua vez chave-primria de R2, trs aes bsicas podem ser consideradas:
XII. Impedimento: uma operao de atualizao no ser concluda;
XIII. Cascata: se ocorrer uma excluso de uma tupla (t) qualquer ora arma-
zenada em R2, ento dever ser removida todas as tuplas de R1 tal que
a chave-estrangeira referencie a chave-primria de (t); se ocorrer uma
alterao da chave-primria de uma tupla (t) de R2, dever ento ser
alterado todas as tuplas de R1 que faa referncia ao valor anterior da
chave-primria de (t) para o novo valor da chave-primria de (t);

94 captulo 4
 XIV. Anulao: se ocorrer uma excluso ou uma alterao de uma tupla (t)
de R2, dessa maneira para toda tupla de R1 tal que a chave-estrangeira
referencie a chave-primria de (t) dever configurar o valor da chave-es-
trangeira para nulo.

Na Figura 4.3, podemos visualizar um esquema de banco de dados relacional o

qual atende os requisitos bsico de uma empresa fictcia qualquer. O conceito de
banco de dados relacional discorre de um esquema e suas respectivas instncias.

Empregado

So- En- Cd.

Cd. Data- Sa-
Nome bre- dere- Sexo Dep-
Emp Nasc lrio
nome o to

Departamento

Cd.Depto Nome Cd.Gerente Datal Inico Gerente

Depto_Localizao

Cd.Depto Depto.Localizao

Projeto

CdProjeto Nome ProjLocalizao Cd.Depto

Trabalho_Projeto

Cd.Empregado Cd.Projeto Horas

captulo 4 95
 Dependente

Cd
Cd Data-
Depen- Nome Sexo Relao
Empregado Nasc
dente

Figura 4.3 Esquema Relacional de uma organizao fictcia

Analisando o esquema relacional apresentado pela Figura 4.3, possvel

identificar que o atributo chamado CdDepto da relao intitulada de DEPAR-
TAMENTO e DEPTO_LOCALIZAO diz respeito a um identificador aplicado ao
departamento, atendendo o mesmo conceito aplicado em um cenrio real. Dessa
forma, esse mesmo conceito pode ser aplicado ao atributo intitulado de CdDep-
to presente nas relaes EMPREGADO e PROJETO. Para o nosso exemplo, utiliza-
mos nomes iguais, todavia, isso no regra, podemos utilizar nomes diferentes
para os mesmos atributos, sem qualquer tipo de restrio. Normalmente, atribu-
tos que simbolizam conceitos dspares podem utilizar o mesmo nome desde que
estejam presentes em relaes distintas. A carter de exemplificao, o atributo
ora identificado de NOME presente na relao EMPREGADO, por sua vez, utiliza
o mesmo identificador, NOME, na relao DEPARTAMENTO.
Eventuais restries de integridade podero ser utilizadas no esquema de ban-
co de dados relacional apresentado pela Figura 4.3, como, por exemplo, as restri-
es de chave-primria que tem como objetivo especificar as chaves-candidatas de
cada relao em nosso esquema. Isso significa que, os valores atrelados s chaves-
candidatas devero garantir exclusividade para todas as tuplas. Outros dois tipos
de restries podero ser aplicadas em nosso modelo relacional, a restrio de in-
tegridade de entidade (RIE) e a restrio de integridade referencial (RIR).
A restrio de integridade de entidade (RIE) que tem como objetivo deter-
minar que absolutamente nenhum valor vinculado chave-primria seja nulo,
simplesmente por utilizamos esse valor de chave-primria para identificar uni-
camente as tuplas na relao. Como exemplo, assuma que existam duas tuplas
ou mais com valores nulos associados chave-primria. Dessa forma, no exis-
tiria nenhuma maneira de identificar exclusivamente uma tupla da outra.
A outra restrio chamada de restrio de integridade referencial (RIE) pos-
sui como propsito contemplar uma restrio associada entre duas relaes,
que garante a consistncia entre tuplas das mesmas. Ou seja, a RIR garante que
uma tupla de uma relao, essa associada por sua vez outra relao, dever,

96 captulo 4
referenciar a uma tupla existente naquela mesma relao. A Figura 4.4, fac-
tvel observar que o atributo chamado de CdDepto da relao EMPREGADO
referencia um nmero de departamento em que cada empregado realiza suas
atividades. Ou seja, todos os valores associados coluna CdDepto da relao
EMPREGADO devero pertencer ao conjunto de valores da coluna CdDepto da
relao DEPARTAMENTO.

As restries de integridade referencial so provenientes dos relacionamentos en-

tre conjuntos de entidades que por sua vez, representam um determinado esquema de
banco de dados.
Outras regras de integridade podem ser aplicadas no modelo relacional, a citar as restri-
es no-nula (NOT NULL) e no-redundante (UNIQUE). A restrio no-nula poder
ser aplicada em uma coluna para garantir que todas as tuplas da tabela apresentem
um valor para essa coluna. A restrio no-redundante implementada em uma coluna
para garantir que no exista nenhum valor duplicado na mesma. (DATE, 2003)

Empregado

Cd. Data- Ende- Cd-

Nome Sobrenome Sexo Salrio
Emp Nasc reo Depto

09/01 Rua
101 Joaquim Mendes M R$3.500,00 15
/1995 A, 1

08/12 Rua B,
102 Elton da Cruz M R$2.350,00 15
/1965 234

19/07 Av C,
103 Juliano Batista M R$1.775,00 24
1965 78

30/06 Rua D,
104 Vanda da Silva F R$4.565,00 24
1961 98

16/09 Rua E,
105 Emersom Frota M R$9.100,00 15
/1968 21

31/07 Av J,
106 Fabrcio dos Santos M R$8.100,00 15
/1986 1347

captulo 4 97
 Empregado

30/03 Av H,
107 Michelle Pavereli F R$2.450,00 24
/1989 76

02/11 Rua T,
108 Venilton Jos M R$8.899,00 11
/1965 76

Departamento

Cd
CdGe-
Dep- Nome Datal Inico Gerente
rente
to

11 Recursos Humanos 105 20/05/2000

15 Contabilidade 108 13/01/1996

24 Tcnologia da Informao 106 13/02/2009

Depto_Localizao

CdDepto DeptoLocalizao

11 Sertzinho

15 Mococa

24 RibeiroPreto

Projeto

CdProjeto Nome ProjLocalizao CdDepto

11 Matriz Sertzinho 11

12 Alpha Sertzinho 11

13 Genexus RibeiroPreto 24

98 captulo 4
 20 IRPF 2013 Mococa 15

30 ERP RibeiroPreto 24

40 SAP RibeiroPreto 24

Trabalho_Projeto

CdEmpregado CdProjeto Horas

101 11 40

101 11 55

108 40 67

103 30 90

105 20 120

108 13 8

102 12 30

104 30 24

106 40 18

107 11 8

Dependente

Cd Cd
Empre- Depen- Nome Sexo DataNasc Relao
gado dente

101 1 Joo M 28/02/2000 Filho

101 2 Pedro M 10/10/2007 Filho

108 3 Sandra F 01/07/2005 Sogra

captulo 4 99
 Dependente

105 4 Marcia F 28/09/1940 Filha

105 5 Sabrina F 17/04/2003 Filha

Guilher-
107 6 M 09/09/2008 Filho
me

103 7 Izadora F 10/12/2012 Filha

Figura 4.4 Instncias do Esquema de banco de dados relacional

Dando sequencia nos conceitos de restrio de integridade referencial RIR,

torna-se necessrio apresentar o conceito de chave-estrangeira (CE). Uma cha-
ve-estrangeira (do ingls foreign key) determina a existncia de uma integrida-
de referencial aplicada entre duas relaes (R1 e R2) e ou, eventualmente, apli-
cada em uma mesma relao.
Voc j aprendeu que normalmente um banco de dados, independente-
mente da regra de negcio, possui vrias relaes, essas por sua vez, utilizam
n restries de integridade referencial. O DBA (ou projetista de dados) deve
conhecer a fundo o significado correto dos atributos existentes nas diversas
relaes que constituem o esquema de banco de dados, para que se possa ob-
ter sucesso na elaborao dessas restries. Tais restries, frequentemente,
so provenientes dos vrios relacionamentos existentes entre as entidades ora
representadas pelo esquema de banco de dados. Como exemplo, considere o
banco de dados representado pela Figura 4.4. Verifique que na relao EMPRE-
GADO, o atributo CdDepto refere-se ao departamento em que cada emprega-
do est associado, ou seja, desempenha suas atividades, dessa maneira, esse
atributo considerado uma chave-estrangeira de EMPREGADO, que tem como
propsito, referenciar valores vinculados ao atributo CdDepto, esse existen-
te na relao DEPARTAMENTO. Para finalizar esse exemplo, considere que o
valor associado ao atributo CdDepto independentemente da tupla da relao
EMPREGADO, dever, impreterivelmente, estar associado um valor corres-
pondente chave-primria da relao DEPARTAMENTO. Esse mesmo valor,
eventualmente, pode ser nulo somente se o empregado no estiver vinculado a
nenhum departamento. Ainda citando como exemplo a Figura 4.4, note que a

100 captulo 4
tupla referente ao empregado Venilton Jos se encontra vinculado ao atribu-
to CdDepto da relao DEPARTAMENTO, evidenciando que o Venilton Jos
est associado ao departamento, ora intitulado de Recursos Humanos.
possvel ainda abstrair que uma chave-estrangeira pode referenciar sua
mesma relao, descrevendo o que denominamos de uma chave-estrangeira
recursiva. A fim de exemplificar graficamente o emprego das restries de in-
tegridade referencial, visualize a Figura 4.5, a qual nos apresenta um esquema
relacional com inmeras restries de integridade referencial, ora representa-
das pelo uso de setas direcionais.

Empregado
CdEmp Nome Sobrenome DataNasc Endereo Sexo Salrio CdDepto

Departamento
CdDepto Nome CdGerente DataInicioGerente

Depto_Localizao
CdDepto DeptoLocalizao

Projeto
CdProjeto Nome ProjLocalizao CdDepto

Trabalha_Projeto
CdEmpregado CdProjeto Horas

Dependente
CdEmpregado CdDependente Nome Sexo DataNasc Relao

Figura 4.5 Representao grfica das restries de integridade referenciais

Para que seja possvel estabelecer a validade das restries para o banco de
dados, essas restries de integridade devem ser implementadas em um es-
quema de banco de dados relacional. Sendo assim, torna-se imprescindvel o
emprego de um Sistema Gerenciador de Banco de Dados Relacional (SGBD-R),
sobretudo o uso da linguagem de definio de dados (DDL Data Definition
Language), que por sua vez, promove recursos para a definio dos variados ti-
pos de restries, assegurando que essa verificao seja realizada pelo SGBD-R
de forma automtica.

captulo 4 101
 Estudamos at aqui apenas as restries de integridade de entidade e refe-
rencial, porm, outras restries, a citar, restries de integridade semntica,
tambm podem ser aplicadas em um banco de dados relacional. Para exem-
plificar o uso de restrio de integridade semntica, suponha que o salrio de
um empregado no pode ser superior ao salrio do seu diretor e, ou, o nmero
mximo de horas dirias trabalhadas no pode exceder 8 horas.
Para finalizar esse tpico, importante mencionar a existncia de trs ope-
raes triviais (insero, alterao e remoo) empregadas em um esquema de
banco de dados relacional qualquer. A primeira operao discorre sobre a in-
sero, a qual responsvel por inserir novas tuplas em uma relao. A segunda
operao a de alterao, onde os valores de um ou mais atributos so altera-
dos, e, por fim, a terceira operao, essa nomeada de remoo, como o prprio
nome sugere, realiza a remoo das tuplas. Dessa forma, independente do tipo
de operao aplicada em um esquema relacional, as restries devem ser aten-
didas a fim de evitar eventuais inconsistncias indesejveis.

4.4 Mapeamento do MER para o Modelo Relacional

Podemos utilizar n esquemas relacionais para um esquema ER, isso , existe

diversas formas de se implementar uma modelagem conceitual abstrata.

ATENO
O MER foi criado para dar subsdio ao processo de modelagem de dados que possui como
objetivo realizar a construo de bancos de dados (ROB, 2005).

Dessa forma, nessa etapa, o projetista de dados deve evitar o uso de um

grande nmero de tabelas, sobretudo, evitar que o tempo de resposta seja con-
siderado insatisfatrio nas operaes de consultas e atualizaes de dados.
Esse quesito implica em minimizar o nmero de junes entre as tabelas, evitar
atributos opcionais, evitar tabelas subutilizadas, evitar excesso de controles de
integridade no banco de dados e evitar organizaes de dados em tabelas que
possuem um nmero significante de controle de integridade.
Normalmente, a fase que constitui o processo de mapeamento formado
pelas seguintes etapas:
1. Mapeamento preliminar de entidades e seus atributos
2. Mapeamento de especializaes

102 captulo 4
 3. Mapeamento de relacionamentos e seus atributos

Para exemplificar, considere a Figura 4.6, ora representada por uma enti-
dade chamada de EMPREGADOS, que por sua vez, incorpora os atributos RG
(atributo identificador) nome e idade. Repare que o processo de mapeamento
para esse exemplo bem simples e objetivo e que, o atributo identificador (cha-
ve-primria) representado pelo uso de um sublinhado no nome do atributo.

RG
Empregados Nome
Idade

Empregados (RG, Nome, Idade)

CP Chave Primria

Figura 4.6 Mapeando convencional de uma entidade

Em relao ao mapeamento de entidades-fracas, deve-se observar que o

identificador da entidade considerada forte, constitui parte da chave-primria
da tabela correspondente entidade-fraca e, por outro lado, torna-se chave-es-
trangeira na tabela fraca. Esse exemplo pode ser visualizado na Figura 4.7. Lem-
bre-se que a entidade-fraca nesse exemplo ITENS. Note que foi utilizada uma
chave-primria composta para esse exemplo.

(1,1) (1,n) Cdigo

Pedido composto Itens Produto
Quantidade

Nmero

CE Chave Estrangeira

Itens (NrPedido, CdItem, Produto, Quantidade)

CP Chave Primria Composta

Figura 4.7 Mapeamento da entidade-fraca (ITENS)

captulo 4 103
 J o exemplo apresentado pela Figura 4.8, realizado o mapeamento dos
atributos (obrigatrio, opcional e composto):

PlanoSade (0,1)
Telefone (1,n)

Rua RG
Nmero Endereo Empregados Nome
Cidade Idade

EMPREGADOS (RG, Nome, Idade, PlanoSade, Rua, Nmero, Cidade)

TELEFONE (RG, Nmero)

ou

TELEFONE (RG, Nmero)

Figura 4.8 Mapeamento dos atributos (obrigatrio, opcional e composto)

Existe tambm uma outra forma de realizar o mapeamento dos atributos

apresentados no exemplo anterior (Figura 4.8). Note que nesse exemplo, ora
visualizado pela Figura 4.9, a cardinalidade mxima do atributo telefone trs
(FoneRes, FoneCom e Celular).

PlanoSade (0,1)
Telefone (1,3)

Rua RG
Nmero Endereo Empregados Nome
Cidade Idade

EMPREGADOS (RG, Nome, Idade, PlanoSade, Rua, Nmero,

Cidade, FoneRes, FoneCom, Celular)

Figura 4.9 Outra maneira de realizar o mapeando dos atributos

104 captulo 4
 Agora, a respeito do mapeamento de entidades especializadas, deve-se con-
siderar trs opes:
1. Opo: considerar uma nica tabela para a entidade considerada gen-
rica e suas especializaes;
2. Opo: considerar o uso de tabelas para entidade genrica e para as en-
tidades especializadas;
3. Opo: considerar o uso de tabelas apenas para as entidades especiali-
zadas.
No prximo exemplo, a 1 opo adotada. Repare na Figura 4.10 que foi rea-
lizado o mapeamento da entidade genrica e suas respectivas entidades especia-
lizadas, mesclando tudo em uma nica tabela. Dessa maneira, o atributo tipo
pode armazenar mais de um valor apenas se, a especializao for no-exclusiva.

CPF
SERVIDORES
Nome

Funo Titulao
FUNCIONRIOS PROFESSORES
Categoria

SERVIDORES (RG, Nome, Tipo, Funo, Titulao, Categoria)

Figura 4.10 1 alternativa: Mapeando da entidade genrica e especializada

Para a 2 alternativa de mapeamento de entidade genrica e especializada, con-

sidere como exemplo a Figura 4.11, a qual foi realizada o mapeamento de forma
separada entre a entidade genrica SERVIDORES e suas entidades especializadas,
intituladas de FUNCIONARIOS e PROFESSORES.

captulo 4 105
 CPF
SERVIDORES
Nome

Titulao
Funo FUNCIONRIOS PROFESSORES
Categoria

SERVIDORES (CPF, Nome)

FUNCIONRIOS (CPF, Funo)

PROFESSORES (CPF, Titulao, Categoria)

Figura 4.11 2 alternativa: Mapeando de entidade genrica e especializada

Em nossa ltima alternativa, repare (Figura 4.12) que realizamos apenas o

mapeamento das entidades especializadas FUNCIONARIOS e PROFESSORES.
Um detalhe importante diz respeito a no utilizao dessa alternativa em espe-
cializaes parciais.

CPF
SERVIDORES
Nome

Funo Titulao
FUNCIONRIOS PROFESSORES
Categoria

FUNCIONRIOS (CPF, Nome, Funo)

PROFESSORES (CPF, Nome, Titulao, Categoria)

Figura 4.12 3 alternativa: Mapeando apenas as entidades especializadas

106 captulo 4
 O mapeamento dos relacionamentos considera uma anlise aplicada na
cardinalidade existente nos relacionamentos. Aps essa anlise, diversas alter-
nativas de mapeamento podem ser escolhidas, a citar: as entidades ora rela-
cionadas podem ser fundidas em uma nica tabela; outras tabelas podem ser
criadas para acolher os relacionamentos, e, como ltima alternativa, eventuais
chaves-estrangeiras podem ser constitudas nas tabelas para estabelecer cor-
retamente o relacionamento. A Figura 4.13 apresenta um exemplo de mapea-
mento de um relacionamento, cujo cardinalidade 1:1 (um-para-um), ou seja,
obrigatrio em ambos os sentidos.

Obrigatrio em ambos os lados

(1,1) (1,1) Endereo

CONFERNCIAS Organizao COMISSES eMail
Nmero

Nome DataInstalao
Sigla

CONFERNCIAS (Sigla, Nome, DataIstComisso, NrComisso,

EndereoComisso, eMailComisso)

Figura 4.13 Mapeando um relacionamento (1:1).

Como outro exemplo, podemos tomar o mapeamento de um relacionamen-

to que possui duas cardinalidades, a primeira (1:1) e a segunda cardinalidade
(0:1), isso simboliza, opcional em um dos sentidos. A Figura 4.14 demonstra o
resultado desse mapeamento, perceba que foi similar ao exemplo anterior, ou
seja, fundimos em uma nica tabela.

captulo 4 107
 Opcional: cardinalidade(mnima, mxima)

(1,1) (0,1)
PESSOAS Posse CARTEIRAS_MOTORISTA

Nome DataRetirada DataExpedio

Cdigo Validade
Categoria
Nmero
PESSOAS (Cdigo, Nome, NmeroCarteiraMotorista, DataExpedio,
Validade, Categoria, DataRetirada)

Figura 4.14 1 alternativa: Opcional em um dos sentidos

Existe ainda uma outra alternativa para esse caso, apresentado pela Figura
4.15 que promove tambm o mapeamento do mesmo MER (opcional em um dos
sentidos), todavia, utiliza duas tabelas (PESSOAS e CARTEIRAS_MOTORISTA).

Opcional: cardinalidade(mnima, mxima)

(1,1) (0,1)
PESSOAS Posse CARTEIRAS_MOTORISTA

Nome DataRetirada DataExpedio

Cdigo Validade
Categoria
Nmero
PESSOAS (Cdigo, Nome)

CARTEIRASMOTORISTA (Nmero, DataExpedio, Validade, Categoria,

Cdigo, DataRetirada)

Figura 4.15 2 alternativa: Opcional em um dos sentidos

A Figura 4.16 exemplifica uma alternativa aplicada ao mapeamento de re-

lacionamento opcional em ambos os sentidos, isso , a cardinalidade mnima
das entidades denominadas HOMENS e MULHERES respectivamente, equiva-
lem zero, simbolizando um relacionamento opcional independentemente do
sentido utilizado.

108 captulo 4
 Opcional em ambos os lados

(0,1) (0,1)
HOMENS Casamento MULHERES

Nome Data Nome

RG RG

HOMENS (RG, Nome)

MULHERES (RG, Nome)

CASAMENTO (RGh, RGm, Data)

Figura 4.16 Mapeamento do relacionamento (opcional em ambos os sentidos)

A segunda alternativa para o mesmo MER, representado pela Figura 4.17 con-
sidera o mesmo relacionamento anterior, ou seja, opcional em ambos os sentidos,
porm realiza o mapeamento apenas das entidades envolvidas.
Opcional em ambos os lados

(0,1) (0,1)
HOMENS Casamento MULHERES

Nome Data Nome

RG RG

HOMENS (RG, Nome, RGesposa)

MULHERES (RG, Nome, RGmarido, DataCasamento)

Figura 4.17 Mapeamento do relacionamento (opcional em ambos os sentidos)

Quando se trata de um relacionamento 1:N, isso , um relacionamento obri-

gatrio e ou opcional do lado N. O exemplo a seguir, ora representado pela Figu-
ra 4.18, possvel identificar que a entidade nomeada de EMPREGADO trabalha
com duas alternativas de cardinalidade, uma representando a cardinalidade 1:N
e a outra 0:N, a qual caracteriza opcional no lado N. No exemplo apresentado, tor-
na-se possvel visualizar o mapeamento final utilizando duas tabelas, essas no-
meadas de DEPARTAMENTOS e EMPREGADOS e, ainda, que o atributo referen-
te ao relacionamento LOTAO se encontra includo na tabela EMPREGADOS.

captulo 4 109
 Obrigatrio/Opcional do lado n

(1,n)
(1,1)
EMPREGADOS Lotao DEPARTAMENTOS
(0,n)
Nome Data Nome
Cdigo Cdigo

DEPARTAMENTOS (Cdigo, Nome)

EMPREGADOS (CPF, Nome, CdDepto, DataLotao)

Figura 4.18 Mapeando do relacionamento (obrigatrio e opcional)

Repare agora que, quando trabalhamos com relacionamentos 1:N e op-

cional do lado 1, basicamente podemos aplicar duas possibilidades para o
processo de mapeamento. Como primeira alternativa, ora representada pela
Figura 4.19, criada trs tabelas, duas tabelas destinadas ao mapeamento das
entidades AUTOMOVEIS e PESSOAS, e uma tabela exclusiva para mapear o rela-
cionamento POSSE, que por sua vez, possui como caracterstica os atributos RG
(chave-estrangeira), chassi (chave-primria e chave-estrangeira) e DataCompra.

Opcional no lado 1

(1,n)
(0,1)
AUTOMVEIS Posse PESSOAS
(0,n)
Ano DataCompra Nome
Modelo RG
Chassi

PESSOAS (RG, Nome)

AUTOMVEIS (Chassi, Modelo, Ano)
POSSE (RG, Chassi, DataCompra)

Figura 4.19 1 Opo: Mapeamento do relacionamento (opcional lado 1).

110 captulo 4
 Como segunda opo para o mapeamento do MER apresentado pela Figura
4.19, utilizado a Figura 4.20, onde possvel notar que foi utilizado duas tabe-
las para realizar o mapeamento do relacionamento caracterizado de 1:N, isso ,
simplesmente foi criado uma tabela para mapear a entidade PESSOAS e outra
tabela para mapear a entidade AUTOMOVEIS. Repare ainda que inserimos o
atributo RG da entidade PESSOAS, que por sua vez uma chave-estrangeira,
com o atributo DataCompra, esse de propriedade do relacionamento POSSE.

Opcional no lado 1

(1,n)
(0,1)
AUTOMVEIS Posse PESSOAS
(0,n)
Ano DataCompra Nome
Modelo RG
Chassi

PESSOAS (RG, Nome)

AUTOMVEIS (Chassi, Modelo, Ano, RG, DataCompra)

Figura 4.20 2 Opo: Mapeamento do relacionamento (opcional lado 1).

Para exemplificar um relacionamento N:N, visualize a Figura 4.21. Verifi-

que que temos trs tabelas resultantes do processo de mapeamento, ou seja,
duas tabelas para mapear as entidades EMPREGADOS e PROJETOS respecti-
vamente, e outra tabela exclusiva para mapear o relacionamento PARTICIPA-
O. Dessa maneira, a tabela PARTICIPAO formada pelos atributos RG,
cdigo e DataIncio, e ainda, note que RG e cdigo tornam-se os atributos iden-
tificadores constituindo o que denominamos de chave-primria composta. O
relacionamento aplicado nesse exemplo, entre as entidades EMPREGADOS e
PROJETOS obrigatrio e ou opcional nos dois sentidos.

captulo 4 111
 Obrigatrio/Opcional em ambos os sentidos

(1,n) (1,n)
EMPREGADOS Participao PROJETOS
(0,n) (0,n)

Nome DataIncio Nome

RG Cdigo

EMPREGADOS (RG, Nome)

PROJETOS (Cdigo, Nome)
PARTICIPAO (RG, Cdigo, DataIncio)

Figura 4.21 Mapeando um relacionamento N:N (obrigatrio e ou opcional nos dois sentidos).

Nesse prximo exemplo, exploraremos conhecimentos referente ao mapea-

mento de um auto-relacionamento, isso , de um relacionamento de grau um.
No existe nenhuma exceo, pois permitido aplicar absolutamente todas as
regras de mapeamento vistas at o momento. A Figura 4.22 permite que seja vi-
sualizado duas alternativas de mapeamento de um auto-relacionamento. im-
portante lembrar que para esse tipo de relacionamento imprescindvel o uso de
papis, esses utilizados para identificar adequadamente o papel de cada instn-
cia de EMPREGADOS, ora assumindo o papel de GERENTE e ou SUBORDINADO.

gerente
(0,1)
EMPREGADOS Gerncia
(0,n) subordinado
Idade
Nome
RG

1 Alternativa:

EMPREGADOS (RG, Nome, Idade)

GERNCIA (RGempregado, RGgerente)
2 Alternativa:

EMPREGADOS (RG, Nome, Idade, RGgerente)

Figura 4.22 Mapeamento de um auto-relacionamento

112 captulo 4
 Em relao ao processo de mapeamento de uma entidade associativa, pode-
se utilizar as mesmas recomendaes estudadas at o momento. Apenas uma
ressalva, importante identificar corretamente a entidade associativa junto ao
MER. A Figura 4.23 exemplifica o mapeamento de entidades associativas.

EMPRSTIMOS

(0,n) (0,1)
LIVROS Emprstimo CLIENTES

DataDevoluo
(0,n)

(1,1)
Cadastro BIBLIOTECRIAS

LIVROS (Cdigo, ..., Rgcliente, DataDevoluo, RGbibliotecria)

CLIENTES (RGcliente, ...)

BIBLIOTECRIAS (RGbibliotecria, ...)

Figura 4.23 Mapeamento de entidades associativas

Para finalizar esse tpico, estudaremos agora os processos aplicados no ma-

peamento em relacionamento de grau trs. A Figura 4.24 representa um exem-
plo do processo de mapeamento aplicado em um relacionamento dito como
ternrio, esse formado pelas entidades INSTITUIES, PROJETOS e PESQUI-
SADORES. Note que foi considerado a cardinalidade N:N:N que envolve por sua
vez as trs entidades do MER. Aps o mapeamento, repare que foi obtido qua-
tro tabelas, uma destinada para cada entidade e outra exclusiva para o relacio-
namento intitulado de PESQUISA.

captulo 4 113
 DataIncio
DataIncio
(1,n) (0,n)
INSTITUIES Pesquisa
(1,n) (0,n) PROJETOS
INSTITUIES Pesquisa PROJETOS

Sigla Nmero
Sigla (1,n) Nmero
(1,n)
PESQUISADORES RG
PESQUISADORES RG

Caso: N:N:N

Caso: N:N:N (Sigla, ...)

INSTITUIES
PROJETOS (Nmero,
INSTITUIES (Sigla, ...)
...)
PESQUISADORES (RG, ...)
PROJETOS (Nmero, ...)
PESQUISA (Sigla, Nmero, RG, DataIncio)
PESQUISADORES (RG, ...)
PESQUISA (Sigla, Nmero, RG, DataIncio)

Figura 4.24 Mapeamento de um relacionamento Grau 3 (N:N:N).

Na Figura 4.25, foi considerado para o exemplo a cardinalidade 1:N:N apli-

cado em um relacionamento ternrio. Como resultado final do processo de ma-
peamento, foi obtido quatro tabelas, similar ao exemplo apresentado pela Fi-
gura 4.24, isso , uma tabela para mapear cada entidade e outra especfica para
mapear o relacionamento DISTRIBUIO. Apenas como distino do exemplo
anterior (Figura 4.24), considere a criao correta da chave-primria composta,
que por sua vez, no vinculou o atributo RG chave-estrangeira na chave-prim-
ria da tabela DISTRIBUIO por simplesmente possibilitar que um produto
seja distribudo em uma cidade por nenhum ou no mximo um distribuidor.

114 captulo 4
 (0,n) (0,n)
PRODUTOS Distribuio CIDADES
(0,n) (0,n)
PRODUTOS Distribuio CIDADES

Cdigo Cdigo
Cdigo (0,1) Cdigo
(0,1)
DISTRIBUIDORES RG

DISTRIBUIDORES RG

Caso: 1:N:N

PRODUTOS (Cdigo, ...)

Caso: 1:N:N
CIDADES (Cdigo, ...)
PRODUTOS (Cdigo, ...)
DISTRIBUIDORES (RG, ...)
CIDADES (Cdigo, ...)
DISTRIBUIO (CdProduto, CdCidade, RG)
DISTRIBUIDORES (RG, ...)
DISTRIBUIO (CdProduto, CdCidade, RG)

Figura 4.25- Mapeamento de relacionamento ternrio (1:N:N).

Quando existe relacionamento ternrio 1:1:N, esse representado pela Figu-

ra 4.26, temos como resultado do processo de mapeamento trs tabelas, uma
para cada entidade. A fim de atender corretamente o relacionamento presente
entre as entidades, note que na tabela CORRESPONDENCIAS existe as chaves-
-estrangeiras CdBairro e RG, as quais determinam que uma correspondncia
ser entregue nica e exclusivamente por um carteiro para um nico bairro.

captulo 4 115
 (0,n) (0,n)
CORRESPONDNCIAS Entrega BAIRROS

Peso Cdigo
(0,1)
Cdigo
CARTEIROS RG

Caso: 1:1:N

BAIRROS(Cdigo, ...)
CARTEIROS (RG, ...)
CORRESPONDNCIAS (CdCarta, Peso, CdBairro, RG, ...)

Figura 4.26 Mapeamento do relacionamento ternrio (1:1:N).

Para concluir esse tpico, que tratou acerca do mapeamento MER para o
modelo de dados relacional, o ltimo exemplo de mapeamento apresentado
pela Figura 4.27, que apresenta um relacionamento ternrio 1:1:1. Repare que
quando lidamos com esse tipo de relacionamento, o resultado do processo de
mapeamento inclui apenas uma tabela, essa responsvel por incorporar todos
os atributos das entidades envolvidas no relacionamento. Para esse exemplo,
foi gerado uma tabela nomeada de VEICULO, que por sua vez, incluiu os atribu-
tos Cdigo, PesoPainel, CdMotor, FabrMotor, CdLataria e ModLataria.

116 captulo 4
 (1,1) (1,1)
PAINIS Veculo MOTORES

Peso Fabricante
(1,1)
Cdigo Cdigo
LATARIAS

Modelo
Cdigo

Caso: 1:1:1

VECULO (Cdigo, PesoPainel, CdMotor, FabrMotor,

CdLataria, ModLataria)

Figura 4.27 Mapeamento do relacionamento ternrio (1:1:1).

ATIVIDADE
1. Conceitue chave-primria simples e composta. D pelo menos trs exemplo de cada tipo
de chave-primria.

2. Utilize suas prprias palavras para discorrer sobre os conceitos de Restrio de Integridade
de Entidade (RIE) e Restrio de Integridade Referencial (RIR). Cite exemplos para ambos
os conceitos.

3. Analise os requisitos a seguir e constitua sua modelagem relacional que atenda algumas
necessidades de informao, a citar: Qual o cdigo e a descrio de cada projeto desem-
penhado na empresa? Qual o nmero da matrcula e nome de cada funcionrio? Quais
so as possveis funes desempenhadas na empresa?
Imagine que uma empresa os funcionrios trabalham em projetos, onde em cada projeto
um funcionrio poder exercer diversas funes de acordo com as regras expostas abaixo:
Os funcionrios podem realizar distintas funes em diversos projetos;
Eventualmente, um funcionrio pode exercer em um mesmo projeto distintas funes;

captulo 4 117
 Em um determinado projeto podemos ter uma mesma funo (atribuio) exercida por
distintos funcionrios;
Por outro lado, um funcionrio poder realizar a mesma funo em distintos projetos;

4. Quais caractersticas so desejveis para uma chave-candidata?

REFLEXO
Parabns! Finalizamos mais um captulo de estudo!
Neste captulo, trabalhamos muito, sobretudo por abordamos assuntos mais ridos. Espera-
mos que tenha compreendido os contedos.
Neste captulo estudamos o modelo de dados relacional e seus componentes, como por
exemplo, como as chaves funcionam e qual a sua relevncia como atributos identificadores,
e ainda, seu principal objetivo na identificao nica de instncias de entidades.
Na sequncia, estudamos algumas restries de integridade, consideradas primordiais para
impor a consistncia dos dados em qualquer esquema de banco de dados.
A partir de agora, fortemente indicado realizao dos exerccios sugeridos, e, se possvel,
realize pesquisas alm do contedo da apostila para incrementar seus conhecimentos. Caso,
eventualmente, voc se deparar com alguma dvida, volte aos tpicos e refaa a leitura com
bastante concentrao..

LEITURA
Artigos on-line: para que voc possa aumentar ainda mais o seu nvel de aprendizagem refe-
rente ao modelo de dados relacional:
http://imasters.com.br/artigo/2419/banco-de-dados/o-modelo-relacional-de-dados-parte-01/
http://imasters.com.br/artigo/2419/banco-de-dados/o-modelo-relacional-de-dados-parte-02/
http://imasters.com.br/artigo/2419/banco-de-dados/o-modelo-relacional-de-dados-parte-03/

Livros:
Sistemas de Banco de Dados: Projeto, Implementao e Administrao. ROB e CORONEL.
Sistemas de Bancos de Dados. Elmasri e Navathe;
Nesses dois livros possvel encontrar com detalhes todo o contedo explorado nesta unida-
de. fortemente recomendado que voc maximize seus conhecimentos nestas bibliografias.

118 captulo 4
 REFERNCIAS BIBLIOGRFICAS
ELMASRI, R.; NAVATHE, S.B. Sistemas de bancos de dados. So Paulo: Pearson (Addison
Wesley), 2005.

KORTH, H.; SILBERCHATZ, A. Sistemas de bancos de dados. 3. ed. So Paulo: Makron

Books, 1998.

HEUSER, C. A. Projeto de Bancos de Dados. 2. ed. Porto Alegre: Sagra Luzzatto, 1999.

PRESSMAN, R.S. Engenharia de software. So Paulo: Makron Books, 1995.

ROB, P.; CORONEL, C. Sistemas de Banco de Dados: Projeto, Implementao e Administra-

o. 8. Ed. So Paulo: Cengage Learning, 2011.

SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de Banco de Dados. 5. ed. Rio
de Janeiro: Elsevier, 2006.

DATE, C. J.; Introduo a Sistemas de Banco de Dados; 8. Ed.; Trad. Daniel Vieira; Rio de
Janeiro: Elsevier, 2003.

HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4 ed. Instituto de Informtica da UFR-
GS, Sagra DC Luzzatto, 1998.

RAMAKRISHNAN, R. GEHRKE, J. Database Management Systems. 2. ed. Boston: McGraw-

-Hill, 2000.

TEOREY, T.; LIGHTSTONE, S.; NADEAU, T.; JAGADISH, H. V.; Database Modeling and De-
sign Logical Design. 5 ed., Burlington USA: Elsevier, 2011.

CASTRO, E. B.; Modelagem Lgica de Dados: construo bsica e simplificada; Rio de Ja-
neiro: Editora Cincia Moderna, 2012.

PUGA, S.; FRANA, E.; GOYA, M.; Banco de Dados Implementao em SQL, PL/SQL e
Oracle 11g; So Paulo: Pearson Education do Brasil, 2013.

captulo 4 119
 NO PRXIMO CAPTULO
No prximo captulo, estudaremos sobre o processo de normalizao, conceito tambm con-
siderado importantssimo para obtermos projetos de banco de dados ntegros e concisos!

120 captulo 4
 5
Normalizao
5 Normalizao
No captulo anterior, aprendemos sobre o modelo de dados relacional, regras
de integridade de entidade e referencial. Vamos agora aumentar nossos conhe-
cimentos num assunto de extrema relevncia para a criao de projetos de ban-
co de dados bem estruturados.
Uma vez abstrados os principais conceitos relacionados ao modelo de dados
relacional, voc no deve ter se surpreendido pelo fato desse modelo ser ampla-
mente adotado, sendo considerado um clssico na maioria das literaturas que
discorrem sobre o assunto.
Neste captulo, estudaremos sobre a normalizao, o que , e para que aplica-
-la. Explicar o que uma tabela aninhada e aprender sobre as principais depen-
dncias funcionais.
Para fechar a unidade, estudaremos com exemplos prticos as cinco formas
normais (1FN, 2FN, 3FN, 4FN e 5FN), enfatizando as trs primeiras, essas con-
sideradas como inevitveis.
Para que seja possvel estudarmos de forma real todas as fases que envolvem o
processo de normalizao, devemos abstrair corretamente quando e como as de-
pendncias funcionais ocorrem. Para isso, a partir de agora, fique atendo quando
abordamos conceitos sobre dependncias funcionais.

OBJETIVOS
O propsito dessa unidade estudarmos o processo de normalizao de dados, de modo a
compreendermos suas principais fases. A partir desse conceito, deveremos estar aptos para
representar tabelas livres de redundncias e ou qualquer tipo de inconsistncias.

REFLEXO
Voc se lembra de nossa discusso no captulo 4 sobre os conceitos do modelo de dados
relacional?
Estudamos nos captulos anteriores sobre os nveis de abstrao, voc ainda se lembra?
Em relao s chaves-primrias, estrangeiras e regras de integridade, voc capaz de defini-los?

122 captulo 5
5.1 Normalizao

Em algumas ocasies, aplicaes computacionais podem apresentar proble-

mas de desempenho oriundos de uma modelagem de dados mal realizada, a
qual acaba produzindo uma quantidade expressiva de redundncia de dados,
esses por sua vez prejudicam o sucesso do objetivo empresariais.
Erros na abstrao da estrutura do banco de dados constituem barreiras no
que se refere a resoluo desse tipo de problema. O processo de normalizao
tem como objetivo promover a reestruturao dos dados a fim de eliminar qual-
quer tipo de redundncia caracterizada como indesejvel, ora presentes em al-
guns esquemas de banco de dados.
Basicamente, o processo de normalizao constitudo por cinco formas
normais, entretanto, se for considerado as trs primeiras formas normais, j
possvel alcanarmos um modelo de banco de dados considerado bem estrutu-
rado e conciso.
Em meados dos anos 70, quando Codd criou os primeiros conceitos que dis-
corriam sobre o processo de normalizao, pouco se conhecia sobre seu prop-
sito. Inmeros profissionais na ocasio desconheciam a maneira de se aplicar
normalizao de dados. Varias dvidas pertinentes ao tema surgiram, a citar: O
que efetivamente se almeja no processo de normalizao de dados?
A normalizao de dados pode ser considerada como um processo onde o
objetivo examinar minuciosamente as estruturas e tabelas de um banco de
dados relacional, minimizando possveis redundncias e inconsistncias de
dados, assim promovendo a eliminao das irregularidades de insero, alte-
rao e excluso.
As formas normais que constituem o processo de normalizao de dados
so utilizadas em um banco de dados relacional como um filtro aplicado sobre
as entidades e seus respectivos relacionamentos, eliminado elementos indese-
jveis sem ocasionar perda de informao.
Ao se conduzir um processo de normalizao de dados em um banco de da-
dos relacional, desejamos ao final desse processo evitar: eventuais duplicaes
de dados (atributos multivalorados); qualquer tipo de dependncia funcional e
redundncia de dados que possam conduzir a perdas de informao.
As fases do processo de normalizao de dados devem ser realizadas de
maneira contnua (em cascata), ou seja, inicialmente deve-se aplicar a primei-
ra forma normal (1FN), na sequncia, deve-se aplicar a segunda forma-normal

captulo 5 123
(2FN), logo aps, deve-se conduzir a terceira forma-normal (3FN), posterior-
mente, a quarta forma-normal (4FN) e, para finalizar o processo, deve-se aplicar
a quinta forma-normal (5FN). Conceitualmente, a forma normal mais elevada
possui melhor eficincia se comparamos com sua antecessora, isto , a 5FN
mais eficaz que a 4FN, que por sua vez, melhor que a 3FN, e assim, sucessiva-
mente. importante mencionar que, apesar do processo de normalizao de
dados ser constitudo por cinco formas normais, normalmente, em cenrios
empresarias convencionais, realizamos a aplicao das trs primeiras regras de
normalizao de dados, ou seja, 1FN, 2FN e 3FN, resultando em um esquema
de banco de dados considerado aceitvel. As regras que constituem a 4FN e 5FN
tornam-se aconselhvel apenas em estrutura de banco de dados que realmente
carecem da aplicao de tais regras.

5.1.1 Aninhameno de Tabela

Uma tabela no normalizada (aninhada) uma tabela que no atende a ne-

nhuma das regras da 1FN, e, na maioria das vezes, essa tabela pode possuir
uma ou mais tabelas ditas como aninhadas (uma tabela dentro de outra tabe-
la, e assim, sucessivamente).

ATENO
Regras de Normalizao: as regras de normalizao podem ser consideradas como sendo uma
formalizao dos bons princpios para o projeto de bancos de dados ou ainda como regras de
conduta na definio de registros em um projeto de banco de dados. (CASTRO, 2012).

Uma tabela dita como aninhada quando possui grupo de dados redun-
dantes, colunas multivaloradas, colunas no atmicas, isso , no possui dados
atmicos, e sim, tabelas inclusas dentro de outras. Para apresentar um exem-
plo de tabela aninhada (no normalizada) considere a Figura 5.1.

124 captulo 5
 Empregado
CdProjeto Tipo Descrio Cd
Nome Categoria Salrio Data incio Tempo
Empregado
6124 Victor Nunes A1 2 11/01/2001 48
Fbio
5134 A2 2 10/02/2001 48
Cardoso
Desenvol- Jos
Sistema 4211 C1 4 10/03/2002 36
PSI001 vimento de Ribeiro
ERP
Solfware Carlos da
6162 A2 2 10/04/2002 36
Silva
Sonia
1189 A1 2 11/01/2002 24
Purcini
Sonia
1189 A1 2 05/01/2003 24
Sistema Purcini
Manuten-
PSI034 Apoio Jos
o 4211 C1 2 01/04/2001 48
Deciso Ribeiro
2141 Joo de Freitas A2 4 11/01/2002 24
Figura 5.1 Exemplo de aninhamento de tabelas

captulo 5
125
 Pode-se identificar a existncia de aninhamento entre tabelas, sobretudo
por ser fcil de identificar duas tabelas aninhadas, ou seja, uma tabela com
os dados referente aos empregados e outra tabela ora armazenando os dados
acerca dos projetos desempenhados por esses mesmos empregados. Caso seja
aplicado o processo de mapeamento da tabela utilizada como exemplo (Figura
5.1), seria obtido como resultado final o esquema de dados abaixo:

PROJETOS (CdProjeto, Tipo, Descrio, CdEmpregado, Nome, Catego-

ria, Salrio, DataIncio, Tempo)

Com base nesse esquema ora no normalizado, iniciaremos o processo de

normalizao de dados, aplicando as regras necessrias para que essa tabela
possa ser considerada como bem projetada, livre de redundncia de dados e
eventuais inconsistncias, ou seja, sem a presena do que denominamos ano-
malias de insero, alterao e remoo.
O processo de normalizao de dados deve seguir obrigatoriamente a hie-
rarquia apresentada pela Figura 5.2.

Tabela
Aninhada

Esquema
na 1FN

Esquema
na 2FN

Esquema
na 3FN

Figura 5.2 Principais regras de normalizao de dados

126 captulo 5
5.1.2 Regra: Primeira forma normal (1FN)

As regras referente a primeira forma normal fornecesse subsdios para iniciar

o processo de normalizao de dados. Tendo como referncia a tabela aninha-
da, a partir dessa, ser aplicada a 1FN. Uma tabela se encontra na 1FN quando
todas as suas tuplas so consideradas distintas entre si, e, absolutamente, no
poder existir nenhum tipo de aninhamento de tabelas. Conclusse que, uma
tabela est na 1FN quando todos os valores atrelados as suas colunas so consi-
deradas monovalorados.
A transformao de uma tabela no normalizada, ou dita tambm como ani-
nhada em um esquema que atenda as regras pertinentes a 1FN envolve basica-
mente duas alternativas: lanar uso de uma nica tabela aninhada contendo re-
dundncia de dados ou, constituir uma tabela para cada tabela aninhada. Sem
dvida, a segunda alternativa mais conveniente, entretanto, apresentaremos
as duas possibilidades para que voc analise suas vantagens e desvantagens.
Como primeira alternativa do processo de normalizao que envolve as regras
da 1FN, tem-se o uso de apenas uma nica tabela onde os registros das linhas ex-
ternas tabela aninhada so repetidos para cada linha da tabela aninhada.

Tabela No-Normalizada (Aninhada):

PROJETOS (CdProjeto, Tipo, Descrio, CdEmpregado, Nome, Catego-
ria, Salrio, DataIncio, Tempo)

1FN (1 Alternativa):
PROJETOS (CdProjeto, Tipo, Descrio, CdEmpregado, Nome,
Categoria, Salrio, DataIncio, Tempo)

Perceba que os registros pertinentes ao projeto so duplicados para cada

empregado que trabalha no projeto.

captulo 5 127
 J a segunda alternativa para a aplicao da 1FN na tabela aninhada utili-
zada como exemplo, cria-se uma tabela para a prpria tabela que est sendo
normalizada e uma tabela para representar cada tabela considerada aninhada.

Tabela No-Normalizada (Aninhada):

PROJETOS (CdProjeto, Tipo, Descrio,CdEmpregado, Nome, Categoria,
Salrio, DataIncio, Tempo).

1FN (2 Alternativa)
PROJETOS (CdProjeto, Tipo, Descrio).

PROJETOS_EMPREGADOS (CdEmpregado, Nome, Categoria, Salrio, Da-

taIncio, Tempo)
Note que a primeira alternativa pode ser considerada como vlida, mesmo
que o resultado final contenha apenas uma nica tabela. A segunda alternativa,
que por sua vez, fragmenta uma tabela aninhada em vrias outras tabelas, em
um primeiro momento, pode ser considerada arriscada por refletir eventuais
perdas de dados. Todavia, em cenrios empresariais reais, existe uma prefern-
cia de utilizar as regras que compe a segunda alternativa, isso , empregar o
fracionamento de tabelas.
Em nosso cotidiano, podemos nos confrontar com a existncia de diversas
tabelas aninhadas, essas possuindo vrios nveis de aninhamento, impedindo
visualizao adequada da tabela na 1FN, se considerarmos a primeira alternati-
va, a qual emprega exclusivamente apenas uma nica tabela.
Com o propsito de detalharmos o processo pertinente a criao de uma
tabela que contemple as regras da 1FN, a partir de uma tabela aninhada, dividi-
mos em fases como descritas a seguir:

128 captulo 5
 1 Fase: a chave-primria da tabela na 1FN basicamente igual chave-
-primria da tabela aninhada (no normalizada).
Tabela No-Normalizada (Aninhada):
(CdProjeto, Tipo, Descrio,(CdEmpregado, Nome, Categoria, Salrio,
DataIncio, Tempo)).

1FN:

2 Fase: constituir uma nova tabela, essa constituda pelas chaves-pri-

mrias de cada uma das tabelas na qual a tabela em questo se encon-
tra aninhada, e, outra tabela constituda pelas colunas da prpria tabela
aninhada.

Tabela No-Normalizada (Aninhada):

(CdProjeto, Tipo, Descrio, (CdEmpregado, Nome, Categoria, Salrio,
DataIncio, Tempo)).

1FN:
(CdProjeto, Tipo, Descrio) (CdProjeto, CdEmpregado, Nome, Catego-
ria, Salrio, DataIncio, Tempo)).

captulo 5 129
 3 Fase: estabelecer, na 1FN, as chaves-primrias das tabelas correspon-
dentes tabela aninhada. Nessa fase ento, para a tabela externa, sim-
plesmente transcrevemos a chave-primria para a tabela na 1FN.

Tabela No-Normalizada (Aninhada):

(CdProjeto, Tipo, Descrio, (CdEmpregado, Nome, Categoria, Salrio,
DataIncio, Tempo)).

1FN:
(CdProjeto, Tipo, Descrio) (CdProjeto, CdEmpregado, Nome, Catego-
ria, Salrio, DataIncio, Tempo)).

Agora possvel analisar o resultado final produzido pela 3 fase. Voc deve
estar se questionando: Em relao a chave-primria, qual seria a opo consi-
derada ideal para tabela PROJETOS_EMPREGADOS? Para escolhermos uma
chave-primria adequadamente, torna-se necessrio identificar com qual fre-
quncia os valores vinculados ao atributo CdEmpregado aparece na tabela
considerada aninhada. Apenas uma vez ou vrias vezes? Retorne na Figura 5.1
e obtenha essa informao.
No necessrio muito trabalho para certificar que um empregado, even-
tualmente, pode trabalhar em diversos projetos. Para exemplificar, os empre-
gados Sonia Purcini e Jos Ribeiro, esto alocados em dois projetos, esses des-
critos como Sistema ERP e Sistema de Apoio Deciso. Dessa forma, os valores
associados coluna CdEmpregado (chave-primria da tabela aninhada), de
forma inoportuna, se apresenta diversas vezes na tabela aninhada.
Sendo assim, torna-se necessrio a associao entre as colunas CdEm-
pregado e CdProjeto para identificar exclusivamente as diversas ocorrncias,
constituindo dessa maneira, o que denominamos de chave-primria composta.

1FN:
(CdProjeto, Tipo, Descrio) (CdProjeto, CdEmpregado, Nome, Catego-
ria, Salrio, DataIncio, Tempo))

Aps utilizarmos as regras para contemplar a 1FN em nossa tabela aninhada,

obteramos como resultado duas tabelas, conforme apresentada na Figura 5.3.

130 captulo 5
 CdProjeto Tipo Descrio

Desenvolvimento de
PSI001 Sistema ERP
Solfware

PSI034 Manuteno Sistema Apoio Deciso

Empregado

CdPro- Cd Cate-
Nome Salrio Data incio Tempo
jeto Empregado goria

PIS001 6124 Victor Nunes A1 2 11/01/2001 48

Fbio
PIS001 5134 A2 2 10/02/2001 48
Cardoso

Jos
PIS001 4211 C1 4 10/03/2002 36
Ribeiro

Carlos da
PIS001 6162 A2 2 10/04/2002 36
Silva

Sonia
PIS001 1189 A1 2 11/01/2002 24
Purcini

Sonia
PSI034 1189 A1 2 05/01/2003 24
Purcini

Jos
PSI034 4211 C1 2 01/04/2001 48
Ribeiro

Joo de
PSI034z 2141 A2 4 11/01/2002 24
Freitas

Figura 5.3 Tabelas resultantes da 1FN (a partir de uma tabela aninhada).

captulo 5 131
5.1.3 Regra: Segunda Forma Normal (2FN)

Para que seja possvel estudarmos as regras pertinentes a 2FN e 3FN, torna-se cru-
cial o entendimento adequado do conceito de dependncia funcional. Considere
uma tabela relacional qualquer, dizemos que uma coluna C2 depende funcional-
mente de uma coluna C1, isso , uma coluna C1 por sua vez, determinada C2, ou
ainda, para todas as tuplas da tabela, para cada valor de C1 presente na tabela,
aparece o mesmo valor de C2. A Figura 5.4 demonstra um exemplo de dependn-
cia funcional existente entre as colunas Cdigo e Salrio. A interpretao para
essa dependncia funcional seria: salrio depende funcionalmente de cdigo.

... Cdigo ... Salrio ...

... Emp01 ... R$6.059,00 ...

... Emp03 ... R$6.059,00 ...

... Emp01 ... R$6.059,00 ...

... Emp02 ... R$3.750,00 ...

... Emp02 ... R$6.059,00 ...

... Emp03 ... R$3.750,00 ...

... Emp01 ... R$6.059,00 ...

Cdigo Salrio
Figura 5.4 Dependncia funcional entre as colunas Salrio e Cdigo

A prxima Figura 5.5, factvel identificar a ausncia da dependncia fun-

cional entre as colunas intituladas de A e B.

A B C D

B 5 2 20

C 4 2 15

132 captulo 5
 B 6 7 20

B 5 2 20

C 2 2 15

C 4 2 15

A 10 5 18

A 12 3 18

A 10 5 18

B 5 2 20

C 4 2 15

A 10 5 18

C 4 2 15

Figura 5.5 Ausncia de dependncia funcional (A e B)

A seguir, ser apresentado outro exemplo de dependncia funcional, ora

apresentado na Figura 5.6, onde a coluna C depende funcionalmente de uma
combinao de colunas (A,B).

A B C D

B 5 2 20

C 4 2 15

B 6 7 20

B 5 2 20

C 2 2 15

C 4 2 15

A 10 5 18

captulo 5 133
 A 12 3 18

A 10 5 18

B 5 2 20

C 4 2 15

A 10 5 18

C 4 2 15

(A, B) C

Figura 5.6 Dependncia funcional (C depende funcionalmente da associao das colunas

A e B).

Agora que voc j aprendeu o conceito de dependncia funcional e, a partir

de agora, capaz de identifica-lo em uma tabela relacional, podemos avanar
em nossos estudos aprendendo as novas regras da 2FN. A 2FN tem como pro-
psito eliminar um determinado tipo de redundncia de dados. Para exempli-
ficar, considere o esquema a seguir:

(CdProjeto, CdEmpregado, Nome, Categoria, Salrio, DataIncio, Tempo).

possvel identificarmos que os dados referente ao empregado (Nome, Catego-

ria e Salrio) so considerados redundantes para os empregados que trabalham em
mais de um projeto. A Figura 5.7 nos apresenta um exemplo dessa redundncia.

Empregado
Cd Cate-
CdProjeto Nome Salrio Data incio Tempo
Empregado goria

PIS001 6124 Victor Nunes A1 2 11/01/2001 48

Fbio
PIS001 5134 A2 2 10/02/2001 48
Cardoso

Jos
PIS001 4211 C1 4 10/03/2002 36
Ribeiro

134 captulo 5
 Carlos da
PIS001 6162 A2 2 10/04/2002 36
Silva

Sonia
PIS001 1189 A1 2 11/01/2002 24
Purcini

Sonia
PSI034 1189 A1 2 05/01/2003 24
Purcini

Jos
PSI034 4211 C1 2 01/04/2001 48
Ribeiro

Joo de
2141 A2 4 11/01/2002 24
Freitas

Figura 5.7 Redundncia aplicada as colunas (nome, categoria e salrio).

Uma tabela dita na 2FN, quando, alm de se enquadrar na 1FN, deve estar
livre de dependncia funcional parcial.
Bem, voc deve estar se perguntando. Afinal, o que uma dependncia fun-
cional parcial? Uma dependncia funcional parcial formada quando uma de-
terminada coluna depende apenas de parte de uma chave-primria composta.
Por meio do esquema a seguir, factvel a identificao de uma dependncia
funcional parcial.

1FN:

Projetos_Empregados (CdProjeto, CdEmpregado, Nome, Categoria, Salrio, DataIncio, Tempo)

Note que as colunas nome, categoria e salrio dependem por sua vez apenas
de parte da chave-primria composta, isso , apenas da coluna CdEmpregado,
no tornando necessrio a associao entre as duas colunas (CdProjeto e C-
dEmpregado) para identificar exclusivamente os valores pertinentes as colunas
nome, categoria e salrio.
Com o propsito de distinguir uma dependncia funcional parcial de uma
dependncia funcional no parcial, considere o esquema utilizado acima, en-
tretanto, verifique que destacamos apenas as colunas que dependem de toda a
chave-primria composta.

captulo 5 135
 Projetos_Empregados (CdProjeto, CdEmpregado, Nome, Categoria, Salrio, DataIncio, Tempo)

As colunas DataInco e Tempo dependem funcionalmente de toda a chave-

-primria composta, constitudas pelas colunas CdProjeto e CdEmpregado.
Um detalhe relevante que devemos destacar que, se uma tabela qualquer
se encontra na 1FN e possui apenas uma coluna como chave-primria (cha-
ve-primria simples), a mesma no possui dependncias funcionais parciais,
pois impossvel uma coluna depender de uma parte de uma chave-primria
simples. Sendo assim, considere que toda a tabela que contempla as regras da
1FN e que possui apenas uma coluna como chave-primria j se enquadra na
2FN automaticamente.
Com o objetivo de exemplificar, apresentamos o esquema a seguir, onde
possvel constatar que a tabela intitulada de PROJETOS j atende as regras da
2FN, sobretudo por no possuir dependncias funcionais parciais (chave-pri-
mria simples).

1FN:
(CdProjeto, Tipo, Descrio) (CdProjeto, CdEmpregado, Nome, Catego-
ria, Salrio, DataIncio, Tempo)

2FN:
(CdProjeto, Tipo, Descrio)

A tabela que possui a chave-primria composta e colunas no chave deve ser

examinada com cuidado. Verifique cuidadosamente o esquema a seguir, o qual
j contempla as regras da 1FN.

1FN:
Projetos_Empregados (CdProjeto, CdEmpregado, Nome, Categoria, Sal-
rio, DataIncio, Tempo)

Nesses casos, deve-se realizar o seguinte questionamento para cada coluna

no chave: a coluna depende de toda a chave-primria composta ou apenas de

136 captulo 5
parte dela? ou, para identificar exclusivamente um valor da coluna necessrio
o uso de toda a chave-primria ou apenas de parte dela?
Posteriormente essa verificao, colunas identificadas como dependentes
de toda a chave-primria composta devem permanecer na tabela original, con-
forme apresentado no esquema a seguir:

1FN:

Projetos_Empregados (CdProjeto, CdEmpregado, Nome, Categoria, Salrio, DataIncio, Tempo)

2FN:
Projetos_Empregados (CdProjeto, CdEmpregado, DataIncio, Tempo)

Como resultado final, ou seja, posteriormente aplicar as regras referente a

2FN, o esquema de banco de dados pode ser resumido como:

2FN:
Projetos (CdProjeto, Tipo, Descrio)
Projetos_Empregados (CdProjeto, CdEmpregado, DataIncio, Tempo)

possvel ainda representar o esquema de banco de dados anterior por

meio do uso de tabelas, essas identificadas por sua vez de Projetos, Empregado
e Projetos_Empregados, conforme a Figura 5.8.

captulo 5 137
 Projetos

CdProjeto Tipo Descrio

Desenvolvimento de
PSI001 Sistema ERP
Solfware

PSI034 Manuteno Sistema Apoio Deciso

Tabela: Projetos_empregados

Cd
CdProjeto Data incio Tempo
Empregado

PIS001 6124 11/01/2001 48

PIS001 5134 10/02/2001 48

PIS001 4211 10/03/2002 36

PIS001 6162 10/04/2002 36

PIS001 1189 11/01/2002 24

PSI034 1189 05/01/2003 24

PSI034 4211 01/04/2001 48

PSI034 2141 11/01/2002 24

Tabela: Empregados

Cd
Nome Categoria Salrio
Empregado

6124 Victor Nunes A1 2

5134 Fbio Cardoso A2 2

4211 Jos Ribeiro C1 4

6162 Carlos da Silva A2 2

138 captulo 5
 1189 Sonia Purcini A1 2

1189 Sonia Purcini A1 2

4211 Jos Ribeiro C1 2

2141 Joo de Freitas A2 4

Figura 5.8 Tabelas resultantes do processo de normalizao (2FN).

5.1.4 Regra: Terceira Forma Normal (3FN)

As regras referente 3FN tem como objetivo solucionar um outro tipo de redun-
dncia, conforme apresentado pelo esquema abaixo:

2FN:
Empregados (CdEmpregado, Nome, Categoria, Salrio)

Detalhando o esquema apresentado anteriormente, note que a coluna Sal-

rio determinada pela coluna Categoria. Nessa caso, salrio pago para uma
determinada categoria, ora armazenada diversas vezes independentemente do
nmero de empregados vinculados mesma categoria.
A Figura 5.9 exemplifica esse tipo de problema, ora aplicada na tabela Em-
pregados.

Tabela: Empregados

Cd
Nome Categoria Salrio
Empregado

6124 Victor Nunes A1 2

5134 Fbio Cardoso A2 2

4211 Jos Ribeiro C1 4

6162 Carlos da Silva A2 2

1189 Sonia Purcini A1 2

captulo 5 139
 1189 Sonia Purcini A1 2

4211 Jos Ribeiro C1 2

2141 Joo de Freitas A2 4

Figura 5.9 Tabela Empregados

Na sequncia, analisaremos as dependncias funcionais existentes no es-

quema que representa a tabela Empregados.

Empregados (CdEmpregado, Nome, Categoria, Salrio)

A seta de cor azul escura representa o que denominamos de dependncia

funcional transitiva.
Uma tabela se encontra na 3FN, se e somente se, alm de atender as regras da
2FN e no possuir dependncias funcionais transitivas. Para que a tabela Empre-
gados atenda as regras da 3FN, torna-se necessrio eliminar a dependncia fun-
cional transitiva presente nela, deixando apenas colunas que dependem da cha-
ve-primria na tabela original, conforme demonstrado pelo esquema a seguir:

2FN:

Empregados (CdEmpregado, Nome, Categoria, Salrio)

3FN:
Empregados (CdEmpregado, Nome, Categoria)

140 captulo 5
 Dessa maneira, as colunas que dependem de uma coluna que no cha-
ve-primria devem constituir uma nova tabela, conforme apresentado pelo es-
quema abaixo, onde criamos uma nova tabela intitulada de Categoria com os
atributos CdCategoria e Salrio.

3FN:
Categorias (CdCategoria, Salrio )

O esquema final, aps contemplar as regras da 3FN ser constitudo pelas

seguintes tabelas a seguir:

3FN:
Projetos (CdProjeto, Tipo, Descrio)
Projetos_Empregados (CdProjeto, CdEmpregado, DataIncio, Tempo)
Empregados (CdEmpregado, Nome, Categoria)

Finalizando o processo de normalizao que atende a 3FN, apresentamos

o esquema anterior constitudo pelas tabelas Projetos, Empregados, Projetos_
Empregados e Categorias com suas respectivas instncias, conforme podemos
visualizar na Figura 5.10.

CdProjeto Tipo Descrio

Desenvolvimento de
PSI001 Sistema ERP
Solfware

PSI034 Manuteno Sistema Apoio Deciso

Tabela: Projetos_empregados

Cd
CdProjeto Data incio Tempo
Empregado

PIS001 6124 11/01/2001 48

PIS001 5134 10/02/2001 48

PIS001 4211 10/03/2002 36

captulo 5 141
 PIS001 6162 10/04/2002 36

PIS001 1189 11/01/2002 24

PSI034 1189 05/01/2003 24

PSI034 4211 01/04/2001 48

PSI034 2141 11/01/2002 24

Tabela: Empregados

Cd
Nome Categoria
Empregado

6124 Victor Nunes A1

5134 Fbio Cardoso A2

4211 Jos Ribeiro C1

6162 Carlos daSilva A2

1189 Sonia Purcini A1

1189 Sonia Purcini A1

4211 Jos Ribeiro C1

2141 Joo de Freitas A2

Tabela: Categorias

CdCategoria Salrios

A1 2

A2 2

C1 4

Figura 5.10 Tabelas resultantes do esquema (3FN).

142 captulo 5
5.1.5 Regra: Quarta Forma Normal (4FN)

Basicamente, para a grande maioria dos bancos de dados, aplicar regras de

normalizao que atenda at a 3FN j considerado suficiente. Normalmente,
torna-se necessrio decompor ainda mais o banco de dados, implementando
outras formais normais, como, a citar a 4FN.
Considere o relacionamento de grau trs apresentado pela Figura 5.11 a se-
guir, constitudo pelas entidades PROJETO, EQUIPAMENTO e EMPREGADO,
as quais se relacionamento por intermdio do relacionamento ora identificado
de UTILIZAO.

Cdigo Cdigo
PROJETO EQUIPAMENTO
Nome Nome

Utilizao

Cdigo
EMPREGADO
Nome

Figura 5.11 Relacionamento Ternrio

Suponha que seja necessrio realizar o controle dos equipamentos utili-

zados nos projetos, como tambm, os empregados alocados aos projetos. Um
possvel mapeamento para o relacionamento UTILIZAO seria similar ao
apresentado abaixo:

Utilizao (CdProjeto, CdEmpregado, CdEquipamento )

Vamos considerar esses dados para a tabela UTILIZAO, conforme apre-

sentado na Figura 5.12.

captulo 5 143
 Tabela: Utilizao

CdProjeto CdEmpregado CdEquipamento

1 1 1

1 2 1

1 3 1

1 1 2

1 2 2

1 3 2

2 2 2

2 2 4

3 3 1

3 4 1

3 3 3

3 4 3

3 3 5

3 4 5

4 2 5

Figura 5.12 Instancias da Tabela Utilizao

Agora que possumos a tabela UTILIZAO com seus respectivos dados,

voc consegue identificar quais so os empregados alocados no projeto cujo
seu cdigo corresponda ao nmero 1? Achou estranho? Existe duplicidade de
dados na tabela? Para piorar ainda mais a situao, tente responder quais so
os equipamentos utilizados no projeto de nmero 1?
No se preocupe, estamos lidando com um tipo particular de dependncia
funcional, a chamada de multivalorada. A Figura 5.13 apresenta exemplos des-

144 captulo 5
se tipo de dependncia funcional. Note que a sua notao diferente das de-
mais dependncias funcionais estudadas at o presente momento.

Tabela: Utilizao Tabela: Utilizao

CdProjeto CdEmpregado CdEquipamento CdProjeto CdEmpregado CdEquipamento
1 1 1 1 1 1
1 2 1 1 2 1
1 3 1 1 3 1
1 1 2 1 1 2
. .
. .
. .
CdProjeto CdEmpregado CdProjeto CdEquipamento

Figura 5.13 Dependncia Funcional Multivalorada

Para que uma tabela atenda as regras da 4FN, alm de atender as regras da
3FN, no poder existir mais de uma dependncia funcional multivalorada.
Para adequarmos a relao UTILIZAO para a 4FN, devemos realizar a seguin-
te modificao:

3FN:
Utilizao (CdProjeto, CdEmpregado, CdEquipamento )

4FN:
Projetos_Empregados (CdProjeto, CdEmpregado)
Projetos_Equipamentos (CdProjeto, CdEquipamento)
Dessa forma, podemos concluir que as tabelas Projetos_Empregados e Pro-
jetos_Equipamentos presentes no esquema anterior contemplam as regras
pertinentes a 4FN.

5.1.6 Regra: Quinta Forma Normal (5FN)

Uma tabela se encontra na 5FN se a mesma no possuir nenhuma dependncia

funcional cclica. Mas afinal, o que significa uma dependncia funcional cclica?

captulo 5 145
 Uma dependncia funcional cclica ocorre quando as seguintes dependn-
cias esto presentes em uma tabela:
A B; B C; C A
Ou seja, B depende funcionalmente de A, C depende funcionalmente de B e,
por sua vez, A depende funcionalmente de C, fechando um ciclo, caracterizan-
do uma dependncia funcional cclica.

ATENO
Comparando as regras da 3FN e BCNF, factvel de identificar a existncia de vantagens
para a 3FN, na medida em que sabemos que sempre possvel obter um projeto que atenda
as regras da 3FN sem sacrificar a preservao de dependncia ou da ausncia de perda.
(Silberschatz, et Al, 2006).

Para ilustrar melhor a ocorrncia de uma dependncia funcional cclica, su-

ponha os requisitos de negcio de uma instituio de ensino superior, onde um
professor pode ministrar diversas disciplinas (Professor Disciplina), isso , nes-
se caso, dizemos que Disciplina depende funcionalmente de Professor, confor-
me demonstrada pela tabela PROFESSOR ora representada pela Figura 5.14.

Tabela: Professor

Professor Disciplina

Banco de Dados 1
Jos Ribeiro
Bancos de Dados 2

Engenharia de Software
Fernando Feliciano
Anlise de Projeto de Sistemas

Ainda existe a possibilidade de um ou vrios professores escreverem uma ou

diversas apostilas, formando assim a dependncia funcional cclica, conforme
podemos constatar na tabela Professor_Apostila representada pela Figura 5.15.

146 captulo 5
 Tabela: Professor_Apostila

Professor Apostila

Prof. Dr. Marcos Felipe

Prof. Ms. Hlio da Silva Banco de Dados 1 e 2

Prof. Dr. Joaquim dos Santos

Prof. Ms. Mrio da Cruz

Gerenciamento de Projetos
Prof. Esp. Jos Cardoso

Figura 5.15 Dependncia Funcional Cclica (Professor_Apostila).

Por fim, a exemplificao da dependncia funcional cclica, a tabela Disci-

plina_Professor utilizada para representar que cada disciplina pode possuir
diversas apostilas (Disciplina Apostila), conforme ilustrado pela Figura 5.16.

Tabela: Disciplina_Apostila

Disciplina Apostila

Banco de Dados 1
Banco de Dados 1 e 2
Bancos de Dados 2

Engenharia de Solfware
Engenharia de Solfware
Anlise e Projeto de Sistemas

Figura 5.16 Dependncia Funcional Cclica (Disciplina_Apostila).

Posteriormente a visualizao das trs tabelas (Professor, Professor_Aposti-

la e Disciplina_Apostila), possvel identificar a relao cclica existente entre
Professor Disciplina; Disciplina Apostila e Professor Apostila.

captulo 5 147
 CONEXO
Leia mais sobre normalizao de dados em: <http://imasters.com.br/artigo/7020/banco-
de-dados/modelagem-de-dados-final-normalizacao/>

No processo de normalizao de bancos de dados relacionais, eventual-

mente, podemos nos deparar com alguns problemas, por exemplo, o uso de
chaves primrias incorretas ou at mesmo omitidas; atributos considerados re-
levantes no representados corretamente e possveis atributos no relevantes,
redundantes ou derivados.
Chaves-primrias omitidas ou utilizadas de forma inadequada podem sur-
gir em uma tabela devido ao conceito de uma chave-primria no ser obrigat-
ria, dessa forma, existe a possibilidade de encontrarmos tabelas onde a chave-
-primria se encontra ausente.
Caso voc se deparar com uma tabela que no possui uma chave-primria ou,
se a chave-primria existente nessa tabela seja distinta da chave-primria usual,
para o processo de normalizao de dados, deve-se considerar como se a chave-pri-
mria estivesse presente e, principalmente, inseri-la na forma no normalizada.

ATIVIDADE
5. Conceitue adequadamente o processo de normalizao de dados. Cite suar principais
formas.

6. Defina com suas palavras o conceito de dependncia funcional parcial.

7. Apresente um exemplo de dependncia funcional transitiva.

8. Define adequadamente as dependncias funcionais existentes em uma tabela que no

contempla as regras da 4FN e 5FN.

REFLEXO
Parabns! Voc est se tornando um especialista em modelagem de dados!
Neste captulo estudamos as principais regras utilizadas para realizar a normalizao de da-

148 captulo 5
dos. A normalizao de dados um processo trivial em um projeto de banco de dados. Por
meio da normalizao eliminamos as anomalias de insero, alterao e remoo.
Alm de compreendermos os principais tipos de dependncias funcionais, agora seremos
capazes de identifica-las e ao mesmo tempo, elimina-las a fim de estruturarmos adequada-
mente nossa relao.
Vimos tambm que a utilizao das regras pertinentes a 4FN e 5FN torna-se necessrio
apenas em esquemas de banco de dados bem especficos, sobretudo por no ser habitual
encontrarmos dependncias funcionais multivaloradas e cclicas.

LEITURA
Artigos on-line: para voc incrementar mais o seu nvel de aprendizagem do processo de nor-
malizao de dados:
http://www.devmedia.com.br/normalizacao-de-banco-de-dados/29555
http://www.devmedia.com.br/passo-a-passo-para-modelagem-de-dados/28326

Livro: Sistema de Banco de Dados, Silberschatz, A., Korth, H. F., Sudarshan, S. Neste livro voc
encontrar um contedo especfico de normalizao de dados, muito desta unidade foi basea-
da nos conceitos deste livro. Vale a pena sua consulta. Dedique-se bastante sobre o processo
de normalizao de dados, conhecer as principais regras de normalizao de grande impor-
tncia para manipularmos dados de forma integra e concisa.

REFERNCIAS BIBLIOGRFICAS
ELMASRI, R.; NAVATHE, S.B. Sistemas de bancos de dados. So Paulo: Pearson (Addison
Wesley), 2005.

KORTH, H.; SILBERCHATZ, A. Sistemas de bancos de dados. 3. ed. So Paulo: Makron

Books, 1998.

HEUSER, C. A. Projeto de Bancos de Dados. 2. ed. Porto Alegre: Sagra Luzzatto, 1999.

PRESSMAN, R.S. Engenharia de software. So Paulo: Makron Books, 1995.

captulo 5 149
ROB, P.; CORONEL, C. Sistemas de Banco de Dados: Projeto, Implementao e Administra-
o. 8. Ed. So Paulo: Cengage Learning, 2011.

SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de Banco de Dados. 5. ed. Rio
de Janeiro: Elsevier, 2006.

DATE, C. J.; Introduo a Sistemas de Banco de Dados; 8. Ed.; Trad. Daniel Vieira; Rio de
Janeiro: Elsevier, 2003.

HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4 ed. Instituto de Informtica da UFR-
GS, Sagra DC Luzzatto, 1998.

RAMAKRISHNAN, R. GEHRKE, J. Database Management Systems. 2. ed. Boston: McGraw-

-Hill, 2000.

TEOREY, T.; LIGHTSTONE, S.; NADEAU, T.; JAGADISH, H. V.; Database Modeling and De-
sign Logical Design. 5 ed., Burlington USA: Elsevier, 2011.

EXERCCIO RESOLVIDO
Captulo 1

1. Cite pelo menos trs exemplos de Dados e Informaes, num contexto de empresarial
qualquer. Detalhe cada um.
Sugesto de Resposta: Podemos exemplificar dados e informaes da seguinte maneira.
Imagine respectivamente que voc encontre esses trs dados em um e-mail existente
em sua caixa de mensagens: R$ 2.567,00, Rafael Carvalho e Elizabeth Mendes da Cos-
ta. Bem, voc pode concordar que esses dados no evidenciam nenhuma informao,
por simplesmente desconhecermos o contexto o qual os mesmos esto inseridos. Agora,
suponha que o primeiro dado (R$ 2.567,00) esteja associado ao contexto de uma conta
bancria, assim, poderamos subtender que esse dado agora seria a informao do saldo
atual dessa mesma conta. Por sua vez, o segundo dado se encontra incluso no contexto
acadmico, sendo assim, Rafael Carvalho se trataria do nome do aluno que foi aprovado
em uma determinada disciplina. E, por fim, o dado Elizabeth Mendes da Costa, esteja asso-
ciado ao contexto hospitalar, gerando a informao de que esse dado diz respeito

150 captulo 5
 ao nome de uma paciente qualquer. Dessa maneira, podemos concluir de que o dado ni-
co e exclusivamente sozinho no nos gera nenhuma informao, tornando-se imprescin-
dvel conhecermos o contexto (regra de negcio) o qual o mesmo se encontra associado.

2. Apresente quatro diferenas significativas existentes entre um sistema de arquivo e

um SGBD.
Sugesto de Resposta: Se compararmos o armazenamento de dados utilizando-se um
sistema de arquivo e um SGBD, alguns problemas podem ser evidenciado quando utiliza-
mos a primeira opo, a citar: a estrutura de arquivos definida pelo prprio cdigo-fonte
do sistema computacional, prejudicando consideravelmente sua manuteno; o controle
de acesso desses arquivos apresentam grandes obstculos quando mencionamos o com-
partilhamento; o uso de formatos especficos acarreta no isolamento de dados e por fim,
a ausncia de controle de acesso concorrente pode gerar inconsistncias nos dados. J
o armazenamento de dados por meio do uso de um SGBD elimina esses problemas re-
portados anteriormente, e ainda, implementa o uso de uma linguagem padro (SQL) para
promover adequadamente o acesso (DCL) e manipulao dos dados (DML) e objetos
(DDL) de um banco de dados.

3. Identifique cinco caractersticas de um sistema de gerenciamento de banco de dados

(SGBD).
Sugesto de Resposta: Evidenciamos como 5 principais caractersticas associadas a um
SGBD o: controle de acesso aos dados; controle de redundncia; compartilhamento de
dados com controle de concorrncia; mltiplas vises do mesmo conjunto de dados e
restries de integridade, seja a nvel de entidade e ou referencial.

Captulo 2

1. Descreva detalhadamente o conceito de Entidade e Relacionamento. Cite pelo menos

trs exemplos onde podemos utilizar ambos.
Sugesto de Resposta: Entidade pode ser considerada como algo que desejamos arma-
zenar no banco de dados, a citar como exemplos: um carro, um funcionrio e ou um aluno,
que, por sua vez, representa um determinado tipo de objeto abstrado do mundo real. Um
relacionamento tem como propsito descrever um vnculo (associao) entre uma ou v-

captulo 5 151
 rias entidades. Como primeiro exemplo, suponha a existncia de um relacionamento o
qual associa as entidades Funcionrio e Cliente essa nomeada de atende, que pode
ser interpretado da seguinte maneira: um funcionrio atende um ou vrios clientes. Um
cliente atendido por nenhuma, ou no mximo um funcionrio. Para o segundo exemplo,
considere um relacionamento nomeado de trabalha que associa as entidades Departa-
mento e Funcionrio. A interpretao desse relacionamento seria algo similar a: em um
departamento pode trabalhar nenhum ou vrios funcionrios, por outo lado, um
funcionrio pode trabalhar em no mximo um departamento. E para finaliza os exemplos
de relacionamentos, suponha a existncia das entidades Professor e Disciplina, um
relacionamento sugestivo seria ministra. Sua interpretao poderia ser algo como: um
professor ministra um ou vrias disciplinas, e pode sua vez, uma disciplina pode ser minis-
trada por um ou vrios professores.

2. Analise o cenrio do ambiente acadmico, mais especificamente, de uma sala de aula.

A partir dessa analise, represente por meio de um DER, o conjunto de carteiras e o
conjunto dos tipos de mveis.
Sugesto de Resposta:

CNPJ Nmero_Sala
Razo_Social Tamanho
Endereo Andar

Universidade (1,1) (1,n) Sala de Aula

possui

(1,1)

contm

(0,n)

Cdigo (1,1) (0,n) Cdigo

Tipo Mvel possui Mvel/Mobilia
Descrio Descrio

3. Discorra sobre os detalhes pertinentes ao Modelo Hierrquico, apontando suas desvan-

tagens comparando com o Modelo em Rede.
Sugesto de Resposta: A estrutura lgica do modelo hierrquico constituda por uma es-
trutura similar a estrutura de uma rvore, essa visualizada de cima para baixo, permitindo a

152 captulo 5
 visualizao das suas respectivas ramificaes. Como principais desvantagens, comparan-
do-se com o modelo de rede, podemos citar: representao exclusiva do relacionamento
um para muitos (1:M) existente entre o segmento pai e seus respectivos filhos, isto , cada
segmento pai possui diversos segmentos filhos, porm, cada segmento filho, por sua vez,
possui apenas vinculado a ele um segmento pai; ausncia de independncia estrutural e a
dificuldade em gerenciar e manipular registros.

4. Realize uma pesquisa na Internet e descreva trs caractersticas de um Banco de Dados

XML. Cite pelo menos trs nomes de banco de dados que manipulam arquivos XML.
Sugesto de Resposta: Oracle, PostgreSQL e SQL Server.

5. D pelo menos trs exemplos de restrio aplicada a um modelo de dados. Na sequncia,

descreva os trs tipos de relacionamentos que podem ser utilizado para associar entidades.
Sugesto de Resposta: Exemplos de restries aplicadas a um modelo de dados qualquer:
restrio de chaveprimria, restrio de chave-estrangeira e restrio de unicidade.
Os trs tipos de relacionamentos possveis para associar entidades seriam: uma para mui-
tos (1:M ou 1..*), muitos para muitos (M:N ou *..*) e um para um (1:1 ou 1..1).

Captulo 3

1. Conceitue adequadamente um atributo, e discorra sobre os seus principais tipos. Na sequn-

cia, d pelo menos um exemplo de cada tipo.
Sugesto de Resposta: um atributo conceituado como uma caracterstica particular
de uma entidade, ou at mesmo de um relacionamento especfico. Os atributos podem
ser segmentados em diversos tipos, a citar: simples , composto, multivalorado, derivado
e identificador.
Exemplos: Simples: nome; Composto: endereo; Multivalorado: telefone; Derivado: idade
e Identificador: CPF.

2. Conceitue um relacionamento e classifique os relacionamentos em relao ao nmero de

objetos envolvidos.
Sugesto de Resposta: Um relacionamento tem como propsito descrever um vnculo
(associao) entre uma ou vrias entidades. O grau de um relacionamento determinado

captulo 5 153
 pelo nmero de entidades participantes do mesmo relacionamento. A citar unrio (grau
um), binrio (grau dois), ternrio (grau trs) e nrio (faz uso de mais de trs entidades).

3. Imagine um contexto acadmico, o qual, poderamos considerar uma sala de aula. Qual seria
a cardinalidade mxima de um professor em relao aos alunos, como tambm, dos alunos
em relao ao professor?
Sugesto de Resposta:

(1,n) (0,n)
Professor possui Aluno

Captulo 4

1. Conceitue chave-primria simples e composta. D pelo menos trs exemplo de cada tipo de
chave-primria.
Sugesto de Resposta: uma chave-primria possui algumas caractersticas relevantes, a
citar: os atributos definidos para constituir a chave-primria, por definio, tm que pos-
suir valores nicos para cada registro na relao; nenhum dos atributos que constituem
a chave-primria poder, em hiptese alguma, possuir valores nulos em nenhum registro
e no caso da chave-primria ser composta, no poder ser adicionado mais atributos do
que os mnimos necessrios para identificar os registros de forma unvoca. Uma chave-
-primria simples necessita de apenas um atributo para identificar exclusivamente uma
ocorrncia de uma entidade qualquer, todavia, uma chave-primria composta, precisa de
mais de um atributo para identificar uma ocorrncia de endidade.

2. Utilize suas prprias palavras para discorrer sobre os conceitos de Restrio de Integridade
de Entidade (RIE) e Restrio de Integridade Referencial (RIR). Cite exemplos para ambos
os conceitos.
Sugesto de Resposta: A restrio de integridade de entidade (RIE) tem como propsito
garantir o acesso aos dados sem nenhuma ambiguidade. Para exemplificar o emprego da
RIE, considere uma tupla qualquer, ora existente na relao R, dizemos que o valor de cada
atributo que constitui a chave-primria de (t) deve ser
diferente de nulo e, ainda, no poder haver outra tupla (t) na relao (R) com o mesmo

154 captulo 5
 valor de chaveprimria de (t). J a restrio de integridade referencial, poder ser exem-
plificada considerando uma tupla (t) qualquer e um chave-estrangeira em (t), o valor de
chave-estrangeira pode ser nulo se e somente se os atributos de chave-estrangeira no
formarem a chave-primria de (t), e ainda, o valor da chave-estrangeira poder ser diferen-
te de nulo apenas se existir uma tupla (t) na relao referenciada tal que a chave-primria
de (t) possuir o mesmo valor da chave-estrangeira de (t).

3. Analise os requisitos a seguir e constitua sua modelagem relacional que atenda algumas
necessidades de informao, a citar: Qual o cdigo e a descrio de cada projeto desempe-
nhado na empresa? Qual o nmero da matrcula e nome de cada funcionrio? Quais so
as possveis funes desempenhadas na empresa?
Sugesto de Resposta:

(1,1) (1,n) (1,n) (0,n)

Funcionrio possui Funcionrio participa Projeto

(0,n)

desempenha

(1,n)

Funo

4. Imagine que uma empresa os funcionrios trabalham em projetos, onde em cada projeto um
funcionrio poder exercer diversas funes de acordo com as regras expostas abaixo:
Os funcionrios podem realizar distintas funes em diversos projetos;
Eventualmente, um funcionrio pode exercer em um mesmo projeto distintas funes;
Em um determinado projeto podemos ter uma mesma funo (atribuio) exercida
por distintos
funcionrios;
Por outro lado, um funcionrio poder realizar a mesma funo em distintos projetos.
Sugesto de Resposta: (similar ao DER anterior, porm, agora incrementamos as cardina-
lidades a fim de atender as regras).

captulo 5 155
5. Quais caractersticas so desejveis para uma chave-candidata?
Sugesto de Resposta: Uma chave-candidata uma chave que apresenta obrigatoria-
mente as duas caractersticas a seguir: (1) unicidade: no h duas linhas (tuplas) distintas
na tabela com o mesmo valor para os atributos da chave; (2) irredutibilidade: no existe um
subconjunto de atributos da chave que apresentem a caracterstica de unicidade.

Captulo 5

1. Conceitue adequadamente o processo de normalizao de dados. Cite suas principais formas

Sugesto de Resposta: O processo de normalizao tem como objetivo promover a rees-
truturao dos dados a fim de eliminar qualquer tipo de redundncia caracterizada como
indesejvel, ora presentes em alguns esquemas de banco de dados. Esse mesmo pro-
cesso constitudo por cinco formas normais (1FN, 2FN, 3FN, 4FN e 5FN), entretanto,
se for considerado as trs primeiras formas normais (1FN, 2FN e 3FN), j se possvel
alcanarmos satisfatoriamente um modelo de banco de dados estruturado e conciso.

2. Defina com suas palavras o conceito de dependncia funcional parcial.

Sugesto de Resposta: Uma dependncia funcional parcial quando um determinado
atributo (coluna) depende de apenas parte de uma chave-primria composta, ou seja, no
depende da chave-primria composta inteira para identificar exclusivamente uma ocorrn-
cia dessa entidade (relao/tabela).

3. Apresente um exemplo de dependncia funcional transitiva.

Sugesto de Resposta: Uma dependncia funcional transitiva quando um atributo (co-
luna) depende de outro atributo (coluna) que no a chave-primria e nem faz parte
de uma chave-primria composta para identificar uma ocorrncia de entidade (relao/
tabela) exclusivamente.
Exemplo: Considere a relao abaixo intitulada de Funcionrios:
Funcionrios (CdFuncionrio, Nome, Sobrenome, Endereo, Funo, Salrio)
Os valores do atributo nomeado de Salrio depende dos valores do atributo Funo e no
da chaveprimria CdFuncionrio para identificar exclusivamente uma ocorrncia de enti-
dade (relao/tabela), caracterizando o que chamamos de dependncia funcional transitiva.

156 captulo 5
4. Define adequadamente as dependncias funcionais existentes em uma tabela que no
contempla as regras da 4FN e 5FN.
Sugesto de Resposta: Uma tabela para contemplar as regras pertinentes a 4FN e
5FN devem respectivamente eliminar o que denominamos de dependncia funcional
multivalorada e transitiva

captulo 5 157