Livro Proprietario - Modelagem de Dados

Modelagem
de Dados
2015
Editorial
Comit Editorial
Fernando Fukuda
Simone Markenson
Jeferson Ferreira Fagundes
Autor do Original
Geraldo Henrique Neto
UniSEB Editora Universidade Estcio de S

Todos os direitos desta edio reservados UniSEB e Editora Universidade Estcio de S.
Proibida a reproduo total ou parcial desta obra, de qualquer forma ou meio eletrnico, e mecnico, fotogrfico e gravao ou
qualquer outro, sem a permisso expressa do UniSEB e Editora Universidade Estcio de S. A violao dos direitos autorais
punvel como crime (Cdigo Penal art. 184 e ; Lei 6.895/80), com busca, apreenso e indenizaes diversas (Lei 9.610/98 Lei
dos Direitos Autorais arts. 122, 123, 124 e 126).
Modelagem de Dados
Su
ri o
Captulo 1: Viso Geral: Banco de Dados

e os Sistemas de Gerenciamento de Banco de
Dados (SGBD) . ........................................................ 7
Objetivos da sua aprendizagem......................................... 7
Voc se lembra?....................................................................... 8
1.1 Viso geral: Banco de dados.................................................. 9
1.2 Dados versus informao......................................................... 10
1.3 Classificando os bancos de dados................................................. 11
1.4 Sistemas de Arquivos........................................................................ 14
1.5 SGBD (Sistema de Gerenciamento de Banco de Dados)..................... 17
1.6 Os Usurios de Banco de Dados.............................................................. 19
1.7 O SGBD e suas Funcionalidades................................................................ 22
1.8 Vantagens do SGBD....................................................................................... 24
Atividades................................................................................................................ 27
Reflexo..................................................................................................................... 27
Leitura recomendada................................................................................................... 28
Referncias................................................................................................................... 28
No prximo captulo...................................................................................................... 29
Captulo 2: Projeto de Banco de Dados...................................................................... 31
Objetivos da sua aprendizagem....................................................................................... 31
Voc se lembra?............................................................................................................... 32
2.1 Projeto de banco de dados....................................................................................... 33
2.2 Modelo externo....................................................................................................... 35
2.3 Modelo Conceitual................................................................................................ 37
2.4 Modelo interno.................................................................................................... 37
2.5 Modelo fsico.................................................................................................... 39
2.6 Modelo de dados............................................................................................ 39
Atividades......................................................................................................... 47
Reflexo......................................................................................................... 47
Leitura recomendada................................................................................. 48
Referncias............................................................................................. 48
No prximo captulo.......................................................................... 49
Captulo 3: Modelo Entidade-Relacionamento........................................................... 51

Voc se lembra?............................................................................................................... 52
3.1 Modelo Entidade-Relacionamento............................................................................ 53
3.2 As Principais Caracteristicas do MER...................................................................... 57
3.3 Modelo Entidade-Relacionamento Estendido........................................................... 65
3.4 Diagrama Entidade-Relacionamento (DER)............................................................. 74
3.5 modelando o negcio............................................................................................. 79
Atividades........................................................................................................................ 81
Reflexo........................................................................................................................... 81
Leitura Recomendada...................................................................................................... 81
Referncias....................................................................................................................... 82
No prximo captulo........................................................................................................ 83
Captulo 4: Modelo de Dados Relacional..................................................................... 85
Voc se lembra?............................................................................................................... 85
4.1 Modelo De Dados Relacional................................................................................... 86
4.2 Chave Primria (Atributo Identificador)................................................................... 89
4.3 Restries de Integridade.......................................................................................... 91
4.4 Mapeamento do MER para o Modelo Relacional..................................................... 98
Atividades...................................................................................................................... 113
Reflexo......................................................................................................................... 114
Leitura Recomendada.................................................................................................... 114
Referncias..................................................................................................................... 115
No prximo captulo...................................................................................................... 116
Captulo 5: Normalizao............................................................................................ 117
Objetivos da sua aprendizagem..................................................................................... 117
Voc se lembra?............................................................................................................. 117
5.1 Normalizao.......................................................................................................... 118
Atividades...................................................................................................................... 140
Reflexo......................................................................................................................... 141
Leitura Recomendada.................................................................................................... 141
Referncias..................................................................................................................... 142
Gabarito.......................................................................................................................... 143
Ap
res
ent
Prezados(as) alunos(as)
A cada minuto, uma quantidade significativa de dados sero gerados, independentemente 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 relacionamentos, dentre outros.
Para atender adequadamente essa demanda, s tecnologias
de banco de dados, sobretudo o Big Data, o qual considerado um tema emergente que discorre 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 armazenamento adequado desses dados para a obteno do xito empresarial, independentemente 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 seguinte forma:
Captulo 1 estudaremos sobre o surgimento e a evoluo dos bancos
de dados, apresentando tambm as principais caractersticas dos Sistemas Gerenciadores 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 normalizao de dados.
Bons estudos
Profo. Me. Geraldo Henrique Neto
Viso Geral: Banco de

Dados e os Sistemas de
Gerenciamento de Banco de
Dados (SGBD)
CCC
CC C
CCC
Previamente, antes de iniciarmos o estudo acerca da Modelagem de Dados, devemos constituir

uma base slida de conhecimentos triviais que sero
imprescindveis 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 da sua aprendizagem

Nesse primeiro captulo, exploramos os aspectos histricos relacionados
aos bancos de dados, sobretudo, sobre a sua evoluo desde o incio do
seu surgimento at a atualidade. Conhecer os Sistemas Gerenciadores
de Banco de Dados (SGBD), realizando uma breve comparao 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.
Voc se lembra?
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?.
Viso Geral: Banco de Dados e os Sistemas de Gerenciamento de Banco de Dados (SGBD) Captulo 1
EAD-15- Modelagem de Dados Proibida a reproduo UniSEB
1.1 Viso geral: Banco de dados
Ser que voc consegue identificar quais foram os motivos que levaram os a realizao 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 armazenamento e organizao de vrios arquivos, mencionar, arquivos referente as informaes 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 possvel 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
matemticas 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 considerada um padro para os principais
fabricantes de bancos de dados relacional.
Inoportunamente, a IBM deixou o System R em segundo plano
por um grande 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
9
Modelagem de Dados
publicado pela equipe da IBM, e, imediatamente, deu incio ao processo

de contratao dos desenvolvedores do System R e da Universidade 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.
Proibida a reproduo UniSEB
1.2 Dados versus informao
10
normal a utilizao da denominao informao, quando na verdade estamos nos referenciando a um dado, ou at mesmo, um conjunto
de dados. Na prtica, nas empresas essa substituio se tornou relativamente normal. Todavia, imprescindvel destacar que dado e informao,
embora intimamente ligados, possuem conceitos distintos. Saber diferencia-los importante, sobretudo 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 inmeras respostas provenientes do formulrio on-line, temos
os dados em sua forma bruta, isto , eles no possuem nenhum significado. Dessa maneira, necessitamos transforma-los em dados que possam
gerar algum tipo de informao. 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 relatrios analticos so de fcil
usabilidade?
Sendo assim, podemos contextualizar que quando os dados brutos so
manipulados 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 considerarmos 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 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, conduzindo a uma melhor tomada de deciso a fim de atender
os principais apontamentos 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. importante 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 finalizar 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;
11
Modelagem de Dados
Banco de Dados Multiusurio: ao contrrio do banco de dados

monousurio, esse tipo de banco de dados d suporte e gerncia
diversos usurios simultaneamente.
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, normalmente, residente em locais fisicamente distintos.
12
Uma das mais popular classificao de banco de dados refere-se em

como os dados so manipulados, respeitando sua evoluo no tempo, ou
seja, gerenciando dados on-line e histricos. Essa classificao pode ser
determinada como:
Banco de Dados Operacional: realiza o suporte a transaes
empresariais 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
armazenamento de dados que promovem o suporte na extrao
de informaes valiosas no que se refere a tomada de deciso.
A fim de conduzir adequadamente 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 determinada 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 usurios 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 promover o controle de acesso aos
dados temporais, como: sistemas mdicos (evoluo dos tratamentos aplicados aos pacientes), sistemas empresariais (sistemas
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.;
Banco de Dados Meteorolgico: pela sua prpria nomenclatura, refere-se a um tipo de banco de dados que armazena dados
sobre o tempo (temperatura, umidade do ar, velocidade do vento, etc.);
Banco de Dados Multimdia: so normalmente direcionados ao
armazenamento e manipulao de dados considerados no convencionais, como, imagens, vdeos, msicas, etc.;
Banco de Dados Especialista: voc poder encontrar, em algumas literaturas, um outro nome aplicado a esse tipo de banco de
dados (banco de dados/sistemas baseados em conhecimento).
Esse tipo de banco mistura raciocnio e inferncia, por meio do
uso de inteligncia artificial.
ainda possvel classificarmos os bancos de dados levando em
considerao 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 permite que realizemos o devido processamento
para alcanarmos a valiosa informao 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
armazenamento 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 semiestruturados, conduzindo ao surgimento de mais uma nova vertente de
banco de dados, os intitulados de Banco de Dados XML (Extensible Markup Language).
13
Modelagem de Dados
Para encerrar esse tpico, devemos deixar explcito que os termos banco de dados e base de dados no podem ser considerados como sinnimos,
isso porque, uma base de dados, normalmente, gerenciado por ferramentas
de suporte a deciso 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 gerenciamento de banco de dados (SGBD).
1.4 Sistemas de Arquivos
14
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 organizao 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 dados por meio de uma estrutura lgica, essa responsvel pela alocao
fsica dos arquivos em dispositivos de armazenamento (disco rgido, memria
flash, CD-ROM, DVD-ROM, dentre outros.). Bem, para que voc possa abstrair ainda mais esse conceito, 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 System), 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 limitaes da tecnologia que
por sua vez, foram evoluindo com o transcorrer do tempo, bem como a
inevitvel melhoria da segurana e capacidade de armazenamento.
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 localizao dos dados de cada arquivo. Por exemplo, o sistema de arquivo FAT fragmenta a rea do dispositivo de armazenamento em pequenos blocos, permitindo 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 sistemas 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 operacional, e que, na maioria das
vezes so realizados por diversos desenvolvedores 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 usurios acessando o mesmo dado.
15
Modelagem de Dados
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.
Usurios
Aplicao
Segurana
Dados
Figura 1.1 Esquema Simplificado do Sistema de Arquivos
16
Uma dvida que pode ter surgido em voc, diz respeito se a utilizao de sistemas de arquivos no gerenciamento e manipulao dos dados
uma boa alternativa, nos dias de hoje? Para que voc possa contextualizar
ainda mais os problemas 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 nica 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 problema 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 estruturas de armazenamento nesses sistemas computacionais,
como tambm, o alto custo aplicado na manuteno para solucionar esses
dissabores, criou-se a evoluo dos sistemas de arquivos, os extraordin-
rios sistemas de gerenciamento de banco de dados (SGBD), que utilizam

novas estruturas para o armazenamento e gerenciamento dos dados.
A seguir, iniciaremos um estudo detalhado acerca dos sistemas de
gerenciamento 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 diversos 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 promovidos pelo prprio SGBD, diferenciando-se do armazenamento e gerenciamento de
Conexo:
dados por meio de sistemas de arquivos.
SGBD uma coleo de
aplicativos computacionais
Ou seja, se assemelha a uma interface
responsveis pelo gerenciamento de
inserida entre o banco de dados fsico
uma conjunto de banco de dados. (Rob
(discos, mdias de armazenamento, etc.)
et al., 2011).
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.
Aplicao 1
Aplicao 2
Aplicao 3
SGBD
Banco
de
dados
Aplicao 4
Figura 1.2 Esquema Simplificado do Sistema Gerenciador de Bancos de Dados

17
Modelagem de Dados
18
Tais aplicativos, normalmente, so desenvolvidos por uma equipe

de desenvolvedores atravs da utilizado de uma linguagem de programao especfica, como podemos mencionar: Java, PHP, C/C++, Pascal, C#,
etc. ou, esporadicamente, 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 informao, impulsionando ainda mais a necessidade de utilizarmos
mtodos eficientes 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
Conexo:
Leia sobre a relao:
de um SGBD no se limitam a apenas
Dados-Informao-Conheciesses fatores. No temos dvida que ao
mento em: http://www.ime.usp.
br/~vwsetzer/dado-info-Folha.html
longo do processo de aprendizagem,
Este outro artigo trata sobre Inteligncia
como tambm, de sua via profissional,
Competitiva das Organizaes, pautanvoc ir se deparar com diversas outras
do-se na relao que estudamos:
vantagens ao esmiuar os detalhes dos
bancos de dados, sobretudo, na escolha
de um projeto adequado na aquisio do
mesmo.
Os usurios dos SGBDs sejam eles, usurios
finais, programadores e administradores de banco de dados, em sua rotina
diria, necessitam de extrair conhecimento 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 redundncia 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 disponveis dos SGBDs pode promover uma pssima manipulao dos dados
e, inevitavelmente, 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,
implementar a integridade e evitar redundncia
dos dados, felizmente, deixaram de ser
necessrios, entretanto, se consideVimos que dado e informararmos alguns itens, os sistemas de
o no so sinnimos, e que a
informao resultante de um procesarquivos podem possuir benefcios
samento aplicado no dado bruto, considesuperiores aos SGBDs. No tenha
rando um determinado contexto, ou seja, a
dvida que essa afirmao lhe pa- informao o dado atribudo a um determinado significado, assim temos:
rece muito estranha, mas por mais
Informao = (dado + significado).
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.
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 dados, 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 tipos de usurios. A seguir, esmiu19
Modelagem de Dados
20
aremos 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 conta corrente, utilizando o
nmero da agncia e conta corrente informado pelo usurio
final, e apresentando essa informao para o mesmo. Normalmente, 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 simplesmente leia relatrios produzido pelo
banco de dados;
Desenvolvedores de Aplicativos: tipo de usurio caracterizado
por desenvolver aplicativos computacionais. Os desenvolvedores de aplicativos selecionam, 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
Application Development), a qual permite que um determinado
desenvolvedor de aplicativos crie formulrios e relatrios sem
muito esforo de programao;
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
complexos (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 administrador 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
mecanismos de acesso aos dados;
Para melhorar o desempenho do banco de dados, o DBA poder realizar 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 acessar, concedendo distintos tipos de autorizao.
Essas autorizaes, normalmente so armazenadas e mantidas
em uma estrutura especial a qual o SGBD consulta sempre que
algum usurio tenta acessar os dados;
21
Modelagem de Dados
Considerada como fundamentais, as atribuies de manuteno

do banco de dados, desempenhada pelo DBA so cruciais para
promover a continuidade do sistema de banco de dados, a citar:
realizao de cpias de segurana (backups) periodicamente, independentemente dos dispositivos de armazenamento, ou at mesmo
em servidores secundrios, a fim de prevenir perda de dados em
caso de anomalias, catstrofes, etc. Certificar a existncia de espao suficiente em disco para desempenhar operaes convencionais e, caso seja necessrio, incrementar o espao em disco. Para
finalizar, o DBA tambm dever monitorar tarefas processadas no
banco de dados e garantir que o desempenho no seja afetado por
outras tarefas sobrecarregadas emitidas por alguns usurios.
1.7 O SGBD e suas Funcionalidades
22
Antigamente, as primeiras arquiteturas de SGBD utilizavam computadores de grande porte, denominados mainframes. A utilizao do
mainframe tornava-se necessrio 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 dados 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
equipamentos de hardware, porm, na contra mo, o aumento significante
da capacidade 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 mesma 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
processamento existente do lado do usurio, que por sua vez, assumia o
papel de cliente do SGBD. Essa filosofia conduziu a uma arquitetura
denominada cliente/servidor, que se destina a segmentar os processamentos provenientes dos aplicativos, 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 implementao dessa arquitetura. As consultas SQL, juntamente com as
funcionalidades transacionais residem do lado do servidor, esse intitulado de servidor de consulta 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.
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 proporciona a centralizao dos processos do
SGBD, como tambm, permite funcionar como emulador para
n aplicativos. Sua principal vantagem possibilitar que diversos usurios manipulem significativas quantidades de dados
e, como sua principal desvantagem, podemos citar, seu alto
custo de aquisio, sobretudo por exigir cenrio especial para
mainframes e solues centralizadas;
Computador Pessoal (PC): essa outra arquitetura permite que
computadores pessoais trabalhem em sistema stand-alone, isso
significa que, esses PCs realizam seus
prprios processamentos de maConexo:
neira autnoma. Bem no incio
:
Realize
a leitura, para
a adoo dessa arquitetura, o
melhor abstrao do conceito de
processamento era considearquitetura de um SGBD, do artigo
disponvel no link abaixo:
rado limitado, entretanto,
com o transcorrer do tempo,
paralelamente com a evoluo substancial do hardware,
atualmente possumos PCs com
larga escala de processamento.
Como vantagem dessa arquitetura,
podemos considerar sua simplicidade;
23
Modelagem de Dados
Cliente-Servidor: j nessa arquitetura, o cliente intitulado de

(front-end), esse responsvel por executar tarefas do aplicativo,
fornecendo uma interface 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 simplesmente executar as
consultas no SGBD e devolve-las como resultado ao cliente.
Essa arquitetura muito popular, se compararmos com as demais, vista at o presente momento. Um dos pontos fortes dessa arquitetura 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?
A resposta correta sim! As empresas so subsidiadas pelos seus
dados e no processamento dos mesmos. No tenha dvida que o gerenciamento e tratamento 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, dessa 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:
24
End users
Database structure
Data
http://
Application
request
DBMS
(Database
management
system)
Application
request
Single
View of data
Integrated
Metadata
Customers
Invoices
End-user
data
Products
End users
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 promove acessos dos diversos tipos de usurios e ou aplicativos
computacionais aos dados. Isso o SGBD recebe diversas solicitaes
dos aplicativos e converte em operaes 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 totalidade. A seguir apresentaremos as principais vantagens do
uso de um SGBD:
Compartilhamento de Dados: o SGBD fornece mecanismos os
quais permitem que os usurios finais consigam acessar os dados
facilmente, mesmo lidando com um grande volume de dados;
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 modelo para melhor determinar as polticas de segurana empresarial, promovendo a segurana a nvel de
usurio, refletindo em uma maior privacidade no acesso aos dados.
Diversas regras de segurana podem ser elaboradas determinando
assim quais usurios podem ou no acessar o banco de dados e,
ainda determinar, quais objetos os mesmos podero acessar;
25
Modelagem de Dados
26
Centralizao dos Dados: um beneficio importante refere-se a

centralizao dos dados, sobretudo por permitir que todos os
dados possam ser integrados a um nico repositrio, minimizando dessa forma as redundncias 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 computacionais 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
usurios, os quais possuem distintos nveis de conhecimento
tcnico, um SGBD precisa prover um leque de interfaces para
melhor atende-los. A citar, 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 administra as estruturas consideradas complexas utilizadas no
armazenamento de dados, permitindo que o usurio d nfase
em suas verdadeiras necessidades 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 os registros relacionados a
uma determinada transao so inseridos, alterados 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

Um sistema de banco de
transaes desempenhadas por ele
dados uma coleo de dados
inter-relacionados e um conjunto de prodevem atender as propriedades que
gramas que permitem aos usurios acessar
denominamos de ACID (Atomicie modificar esses dados (Silberschatz, et al.,
dade, Consistncia, Isolamento e
2006).
Disponibilidade). Essas propriedades melhoram o gerenciamento
da concorrncia dos dados e objetos junto ao SGBD.
Atividades
01. Cite pelo menos trs exemplos de Dados e Informaes, num contexto
de empresarial qualquer. Detalhe cada um.
02. Apresente quatro diferenas significativas existentes entre um sistema
de arquivo e um SGBD.
03. 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 organizaes 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.
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.
27
Modelagem de Dados
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, avanados, especialistas e DBAs), que de alguma maneira, utilizam os recursos de um SGBD.
Leitura recomendada
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
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 Administrao. 8. Ed. So Paulo: Cengage Learning, 2011.
28
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 UFRGS, 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 Design 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.
29
Modelagem de Dados
Minhas anotaes:
30
Projeto de Banco de
Dados
Cap
t u
lo
No captulo 1, aprendemos os conceitos

de dados e informaes, e como so importantes e valiosos para as empresas. Aprendemos
que a informao considerada 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, estudaremos sobre o Projeto de Banco de Dados,
que prov mecanismos eficazes para elaborao e criao de banco de dados organizacionais, permitindo a manipulao correta de
dados.
Atualmente, a grande maioria das organizaes, independentemente
do seu porte (pequeno, mdio e grande), impreterivelmente, utilizam
SGBDs para gerenciarem suas informaes empresariais de maneira
segura, ntegra e, ao mesmo 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!

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 compararmos 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!
Voc se lembra?
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?
Projeto de Banco de Dados Captulo 2
2.1 Projeto de banco de dados
Para que alcancemos com xito

os objetivos de um SGBD, torna-se
imprescindvel obtermos uma es*Um banco de dados pode ser
trutura de dados adequada e bem
considerado como uma coleo de
dados persistentes, onde esses mesmos
definida, bem como, escolher um
dados so manipulados por sua vez por
modelo de dados para ser impleaplicaes empresariais (DATE, 2003).
mentado pelo banco de dados.
Quando iniciamos a constituio de um projeto de banco
de dados, normalmente, torna-se
necessrio se basear em uma viso
abstrata do cenrio, o que consideramos tambm como processo de abstrao do
mini-mundo, inserindo 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 exemplo, podemos considerar que viso
de dados abstrada pela diretoria plenamente distinta da viso de dados
dos funcionrios vinculados produo. Esse detalhe, sem dvida, dever
ser considerado na fase de projetar o banco de dados 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
O American
National Standards Institute
de banco de dados baseando-se em di(ANSI) por meio do Standards
versos nveis de abstrao de dados.
Planning and Requirements Commitee
A arquitetura (ANSI/SPARC) consi(SPARC) estabeleceu um padro para o
dera apenas trs nveis de abstrao
desenvolvimento de tecnologias de banco de
dados, definindo uma arquitetura de 3 nveis
de dados, o externo, conceitual
independentes, a citar: interno, conceitual e
e interno. Para que voc entenda
externo. (Rob, 2005).
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.
33
Modelagem de Dados
Viso do usurio final
Viso do usurio final
Modelo externo
Modelo externo
Modelo
conceitual
Viso do projetista
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 qualquer projeto de banco de dados, independentemente
de sua complexidade.
importante mencionar que o nvel de abstrao (modelo externo/
conceitual) independente de hardware e software (SGBD). Entretanto,
o prximo nvel, o modelo lgico, ao contrario do modelo conceitual, depende do software (SGBD), todavia, tambm no considera o hardware.
Para finalizar, nosso ltimo modelo, esse intitulado de modelo interno
(modelo fsico), depende de maneira exclusiva do software (SGBD) e
hardware.
34
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 conceitos j estudados, consideramos como usurios finais a nomenclatura utilizada aos usurios que utilizam aplicativos computacionais
para promover a manipulao 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
segmentada em diversos departamentos, como por exemplo: departamento
de recursos humanos, financeiro, vendas, etc. Onde cada departamento dever atender certas restries e requisitos especficos. Dessa maneira, cada
usurio final que desempenha suas atividades nesses diversos departamentos possui uma viso de apenas um subconjunto de dados, especficos do
seu departamento, desprezando os detalhes dos outros departamentos.
Aluno
(1,1)
Faz
(0,N)
Matrcula
(0,50)
feita em
(1,1)
Professor
(1,3)
Ensina
(0,N)
Turma
(0,N)
(0,N)
(1,N)
Gera
(1,1)
Disciplina
(0,N)
utilizada por
(1,N)
Sala
Pode ministrar
Figura 2.2 Modelo Externo (controle acadmico)
35
Modelagem de Dados
36
Por meio da Figura 2.2 acima, a qual podemos visualizar o modelo

externo pertinente ao controle acadmico de uma universidade fictcia,
factvel abstrairmos o modelo externo citado
como exemplo, ser o responsvel em proConexo:
mover o armazenamento dos dados dos
Leia um pouco mais sobre
alunos, matrculas, professores, discia histria e evoluo dos SGBDs
e da SQL:
plinas e turmas. Voc pode observar
http://pcleon.if.ufrgs.br/~leon/Livro_3_
tambm que as vises das diversas
ed/node116.html
funcionalidades do sistema so, por
http://algol.dcc.ufla.br/~heitor/Artigos/
Artigo_008.html
sua vez, segmentadas entre si, e, cada
viso pode tambm compartilhar um
conjunto de dados com a outra (dados dos
alunos e cursos sendo compartilhados com a
entidade disciplina).
Voc pode ainda observar, por meio da Figura 2.2, que as entidades
e seus respectivos 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 vrias disciplinas ou nenhuma em uma universidade, dessa
forma, o modelo apresenta o uso do que chamamos de cardinalidade mnima entre PROFESSOR e DISCIPLINA como sendo
0 (zero). Sendo assim, admitimos 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
nenhuma. 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, inclusive nenhuma.
2.3 Modelo Conceitual
Posteriormente estudaremos os detalhes relacionados ao modelo

externo, podemos identificar que utilizamos o modelo conceitual, que por
sua vez representado 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 abstrao 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.
O modelo ER (entidade-relacionamento) considerado um modelo
conceitual 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 dados ser implementado;
um modelo independente da tecnologia do SGBD, ora utilizado para a implementao fsica;
No podemos deixar de destaConexo:
car que esse modelo tambm
Recomendamos a leitura
deste artigo, para melhor
no depende do hardware do
compreenso do Projeto de Banco
servidor de banco de dados,
de Dados:
sendo assim, as alteraes
www.dpi.ufv.br/~jugurta/papers/tesejug.
pdf
oriundas do hardware e software no afetar o modelo
conceitual.
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.
37
Modelagem de Dados
Sendo assim, quando voc utiliza um modelo relacional, consequentemente, voc tambm dever escolher um banco de dados que permita o
mapeamento do modelo conceitual para as tabelas (relaes) existentes
no modelo relacional. 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 Relacional). 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.
Departamentos
(0,n)
(1,1)
Responsvel
(0,n)
create table departamentos

id_departamento
interger,
nome
varchar(40),
PRIMARY KEY(id_departamento));
Aluno
(0,n)
create table aluno

ra
nome
sobrenome
PRIMARY KEY(ra));
Inscrio
interger,
varchar(40),
varchar(40);
Disciplina
(0,n)
Disc_Curso
(1,1)
liberada
(0,n)
Curso
Pr_Requis
(0,n)
liberadadora
create table disciplina

id_disciplina
interger,
nome
varchar(40),
pr_requisito
interger,
id_departamento
interger,
PRIMARY KEY(id_disciplina),
FOREIGN KEY(pr_requisito)
REFERENCES disciplina,
FOREIGN KEY(id_departamento)
REFERENCES departamentos);
create table curso

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)
38
Apenas para enfatizar novamente, voc j deve ter percebido que

o modelo 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, caracterizando o que chamamos de independncia lgica.
2.5 Modelo fsico
Esse modelo conhecido por traTuning SQL

balhar com o nvel mais baixo de
(otimizao de consulta)
abstrao, apresentando de maneira
um processo de selecionar o plano
detalhada como os dados so efetide avaliao de consulta mais eficiente
dentre as muitas estratgias normalmente
vamente gravados em um disposipossveis para o processamento de determitivo de armazenamento qualquer
nada consulta (Silberschatz, A. et al, 2006).
(disco rgido, fitas magnticas,
etc.). O modelo fsico depende exclusivamente do SGBD (software)
e do hardware, sobretudo por precisar conhecer previamente os dispositivos fsicos que sero utilizados para o
armazenamento dos dados, principalmente, os
mtodos que provero acesso aos mesmos.
O DBA (Administrador de Banco de Dados) e ou projetista de dados
no precisam se preocupar com os detalhes em nvel do armazenamento
fsico, entretanto, precisam conhecer minuciosamente como realizar a
sintonizao (tuning) 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 simples que, normalmente, simboliza graficamente as estruturas
dos dados. Podemos 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 relacionado elaborao de um modelo de dados no uma
tarefa considerada nada fcil, e, certamente uma verso satisfatrio do
modelo de dados ser atingida, posteriormente diversas correes e adaptaes.
39
Modelagem de Dados
40
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 responsabilizar 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 resposta nica e
exclusiva para esse questionamento. O mais adequado seria responder
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 ferramentas de comunicao, fomentando uma abstrao global de como os dados
sero estruturados e armazenados no novo banco de dados a ser confeccionado.
Analogamente, imagine a abstrao de uma planta baixa de uma
residncia 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 informao a partir de um modelo de dados. Resumidamente,
no podemos levantar 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 restrio, 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,
atributos, 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 determinado tipo de objeto abstrado do mundo real (minimundo). Dessa maneira, conclusse que cada ocorrncia dessa mesma
entidade considerada nica e exclusiva. Como exemplo, podemos tomar
como base a criao de uma entidade, ora intitulada de FUNCIONARIO. Certamente teramos n ocorrncias de funcionrios nicos, como
exemplo tomamos os seguintes nomes de funcionrios: Geraldo Alckmin,

Acio Neves, Dilma Rousseff, etc. As entidades podem 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 caracterizamos a entidade FUNCIONARIO com os seguintes
atributos: nmero do funcionrio, 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
FUNCIONARIO 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 chamamos 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
entender 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 relacionamentos e ou eventuais restries aplicada ao domnio? Inicialmente
necessrio voc absorver corretamente os requisitos da regra de negcio
a ser modelada.
41
Modelagem de Dados
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 objetos 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 exclusivo funcionrio, essa descrio considerada como sendo uma regra de negcio.
Agora que j desmitificamos o conceito de regra de negcio, podemos apresentar 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 intitulada de Tabela 2.1, a fim de demonstrar resumidamente
os modelos de dados mais habituais, considerando a evoluo do tempo:
Perodo
Exemplos
Comentrios
IBM faz uso em seus
mainframes
1960 a
1970
Sistema de arquivos
VMS/VSAM
1970
Modelo de dados
hierrquico e em
rede
IMS, ADABAS,
IDS-II
Implementado pelos primeiros bancos de dados

da poca
1970 at o
presente
Modelo de dados
relacional
DB2, Oracle,
MS SQL Server,
MySQL
Utiliza os conceitos
bsicos (simples) e
objetivos.
1980 at o
presente
42
Modelo
Do presente ao
futuro
Orientado a
objetos
Relacional estendido
XML
PostgreSQL,
Versant, Cach,
FastObjects.Net
Objectivity/
DB, DB/2 UDB,
dbXML, Tamino,
DB2 UDB, Oracle
10g, MS SQL Server, PostgreSQL
Tabela 2.1 Evoluo dos Modelos de Dados (Desde 1960).
No utiliza relacionamentos
Usado na manipulao
de dados considerados
complexos.
Disseminao de banco
de dados na web
Permite a manipulao e
gerenciamento de dados
semiestruturados.
Suporte a documentos
no formato XML
2.6.1 modelo hierrquico
O modelo hierrquico foi criado em meados de 1960, com o propsito de gerenciar 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 registro 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 considerados pais dos fragmentos
cidade e cliente. De maneira intuitiva, os segmentos 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
ESCALA
voo_data voo_hora
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
cid_cod
CLIENTE
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 assim, pilares fundamentais para subsidiar o desenvolvimento de aplicativos comerciais. Mesmo o modelo hierrquico possuindo
diversas vantagens em comparao 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 inde43
Modelagem de Dados
pendncia estrutural, dificuldade em gerenciar 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

relacionamentos de dados considerados mais elaborados, adotando uma
representao simples 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 Figura 2.5 abaixo apresentada:
CLIENTE
CIDADE
VOO
cli_cod cli_nome cli_cpf
voo_cod
BILHETE
voo_data voo_hora
cid_cod
cid_nome
cid_estado
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).
44
Nesse exemplo, simplesmente convertemos o modelo hierrquico

para o modelo em rede, utilizando as mesmas regras de negcio. Voc
j deve ter identificado 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 descrio anterior, podemos
dizer que bilhete tambm possui dois pais (cliente e voo).
Entretanto, o modelo em rede no conseguiu solucionar todos os
problemas pertinentes modelagem de dados. A ausncia de estrutura
correta para permitir a realizao de consultas e a necessidade de implementao macia de linhas de cdigo-fonte para fornecer um simples
relatrio era considerada uma das grandes desvantagens desse modelo de

dados. A falta 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 relacional 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, administrando os detalhes fsicos e expondo o banco de dados
relacional aos usurios 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.
45
Modelagem de Dados
Tabela: Funcionrio
ID_FUNC
ID_FUNC
987
NOME
NOME
Jos
SOBRENOME
SEXO
CPF
RG
SOBRENOME
CPF
Abro
M SEXO 111222333444
RG
1234567890
321
Mrcia
Marina
555333123098
2347698243
112
Wagner
Moura
765234509876
123543-MG
Relacionamento por meio do atributo ID_FUNC
Tabela: Cliente
ID_CLI
NOME
SOBRENOME
SEXO
CPF
RG
ID_FUNC
89710
Geraldo
Alckmin
7687171398
1233456
112
89711
Acio
Neves
6534982615
2455455
987
65412
Joo
Gilberto
1235566615
2342353
987
23113
Marina
Silva
6509090456
4563434
112
65514
Dbora
Santos
1236451324
3425633
112
Figura 2.6 Exemplo de Modelo Relacional
46
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, mesmo que os dados dos clientes estejam
armazenados em uma relao e, os dados dos funcionrios, por sua vez,
armazenados em outra, possvel trabalharmos com essa integridade referencial.
O exemplo exposto acima suficiente para o seu aprendizado no
que se refere ao modelo relacional? Ainda lhe resta dvida? Bem, vamos
estudar um pouco 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, princi-
palmente 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.
Atividades
01. Descreva detalhadamente o conceito de Entidade e Relacionamento.
Cite pelo menos trs exemplos onde podemos utilizar ambos.
02. 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.
03. Discorra sobre os detalhes pertinentes ao Modelo Hierrquico, apontando suas desvantagens comparando com o Modelo em Rede.
04. 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.
05. 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.
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-relacionamento (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.
47
Modelagem de Dados
Leitura recomendada
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-projetode-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
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 Administrao. 8. Ed. So Paulo: Cengage Learning,
2011.
48

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

RAMAKRISHNAN, R. GEHRKE, J. Database Management Systems. 2. ed. Boston: McGraw-Hill, 2000.
No prximo captulo
No prximo captulo, estudaremos com detalhes o modelo entidaderelacionamento. Estudaremos a importncia de constituirmos um modelo
conceitual bem estruturado. Para elaborar um bom projeto de banco de
dados, devemos aprender as caractersticas relevantes do Modelo Entidade-Relacionamento.
49
Modelagem de Dados
Minhas anotaes:
50
Modelo Entidade
-Relacionamento
Cap
t u
lo
No captulo anterior, estudamos acerca

dos conceitos pertinentes ao projeto de banco
de dados, discorrendo sobre seus principais nveis
de abstrao (modelo externo, conceitual e interno).
Aprendemos o que efetivamente realizado no modelo
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 presente 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-relacionamento torna-se importante e de grande relevncia
aprendermos adequadamente sobre as fases constituintes de um projeto
de banco de dados, sobretudo, o que e, para que utilizamos um modelo
de banco de dados.
Voc est pronto?! Vamos dar incio aos nossos objetos de aprendizagem
sugeridos neste captulo 3?

Este captulo tem como objetivo aprofundar os conceitos pertinentes as
principais caractersticas 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 Diagrama Entidade-Relacionamento. Compreender como identificar corretamente o grau de um
determinado relacionamento seja esse relacionamento unrio, binrio, ternrio e ou nrio.
Voc se lembra?
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 Modelos de Dados: Hierrquico, em Rede e Relacional?
Modelo Entidade-Relacionamento 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, conceitual e interno). Aprendemos tambm como elaborar um
modelo fsico de banco de dados e discorremos superficialmente sobre os
modelos de dados mais comuns (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
O processo de
do uso do modelo entidade-relacionamodelagem de dados pode
mento.
ser considerado como sendo um
processo
que emprega diversas etapas,
Bem, antes de iniciarmos a
normalmente iterativo e progressivo. D
discusso sobre os conceitos noincio atravs de uma abstrao simples de
vos, referente ao modelo entidadeum determinado problema, o qual desejamos
solucionar, e conforme o nvel de abstrao
relacionamento, torna-se trivial
do problema incrementado, o nvel de
e ao mesmo tempo, apropriado,
detalhes que a modelagem compreende
obtermos o conhecimento das fases
tambm aumenta (Heuser, 2004).
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 definidos no ambiente empresarial real, com escopo e limites
bem delimitados, que por sua vez, devem ser tratadas como uma viso
sistmica.
53
Modelagem de Dados
Voc imagina qual seria o tipo de

problema que a modelagem de dados se
prope a solucionar?
Um esquema de banco de dados
Para exemplificar, imagine a
nada mais do que uma representao
de um modelo de dados por meio do uso de
necessidade de realizar a categorium conceito de modelagem de dados (DATE,
zao de um conjunto de produtos.
2003).
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.
3.1.1 Modelo de Banco de Dados
54
Segundo Peter Chen, um Modelo Entidade-Relacionamento

constitudo por uma notao, ora formada por entidades (graficamente
representado por retngulos), relacionamentos (graficamente representado por losango), atributos, 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 conexes 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
modelos de dados. Como exemplo, podemos correlacionar, linguagens
que utilizam textos ou grficos para realizar a representao dos modelos
de dados em distintos 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.
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 conhecimentos computacionais especficos.
Ao iniciarmos a elaborao de um projeto de banco de dados,
aconselhvel que tenhamos pelo menos dois nveis de abstrao, esses,
respectivamente, nomeados 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 modelo 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 modelo conceitual atravs de um diagrama, esse, intitulado
de diagrama entidade-relacionamento (DER). A Figura 3.1 nos apresenta
um exemplo do diagrama entidade-relacionamento:
Mdico
(1,n)
CRM
Nome
Especialidade
atende
(1,n)
Paciente
Cdigo
Nome
Sobrenome
Figura 3.1 Representao do modelo conceitual por meio de um DER
55
Modelagem de Dados
O modelo conceitual, ora representado graficamente pelo emprego

do diagrama entidade-relacionamento, permite abstrair que o banco de dados conter dados referentes aos mdicos e pacientes. Dessa maneira, para
cada mdico, o banco de dados armazenar suas principais caractersticas,
a citar, CRM (nmero do Conselho Regional de Medicina), nome e sobrenome, e, por sua vez, para cada paciente, sero armazenados seu cdigo
identificador, nome e sobrenome. Ainda podemos identificar a existncia
de uma associao (relacionamento) ora aplicada para descrever os atendimentos mdicos.
3.1.3 modelo lgico
56
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 sobrenome. 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 armazenamento interno dos dados, que normalmente, interferem
no desempenho da aplicao computacional.
Na primeira fase do projeto de banco
Conexo:
de dados, uma das principais atividades
Leia mais sobre modelo de
o que denominados de levantamento de
dados:
http://www.linhadecodigo.com.br/
requisitos, atendendo as necessidades
artigo/332/planeje-o-seu-modelo-deorganizacionais de um ambiente emdados.aspx
presarial qualquer, atravs da anlise
de requisitos, criando assim, subsdios
para a elaborao do projeto conceitual,
ora representado pelo modelo entidaderelacionamento (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.
A fase subsequente destinada a criao do projeto lgico de dados,

que possui como propsito realizar o mapeamento do modelo entidaderelacionamento (MER) para um modelo de dados qualquer, a citar, o modelo relacional, ora, obrigatoriamente dever ser suportado pelo SGBD a
ser empregado.
Finalizando o projeto de banco de dados, a terceira fase trata do projeto fsico. Esse tem como objetivo definir corretamente as estruturas de
armazenamento interno, como podemos mencionar, as tabelas, os ndices,
dentre outros objetos, ainda sim, definir outras atividades associadas paralelamente, ao desenvolvimento 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 tarefas dos projetistas de dados no que se refere ao entendimento
adequado dos conceitos referente aos dados utilizados nos aplicativos
computacionais, independentemente 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 relao com a entidade externa, essa representado por
sua vez, por um diagrama de fluxo de dados.
57
Modelagem 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 como sendo uma entidade, pelo simples
fato de permitir identificar exclusivamente um determinado funcionrio
em comparao com os demais. Destaca-se ainda que uma entidade possa
assumir duas caractersticas, isso ser concreta (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 deixaram confuso? No se preocupe, tentaremos explica-los
para a sua melhor aprendizagem. Suponha um conjunto de funcionrios
de uma empresa qualquer, por exemplo, a Oracle, sendo assim, permitido definirmos esse conjunto de funcionrios 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
58
Para uma entidade, sempre aconselhvel a existncia de um atributo identificador, esse por sua vez, pode ser simples
ou composto. O atributo identificador, como
Conexo:
o prprio nome diz, permite a identificao
Leia mais sobre Diagrama
nica e exclusiva de uma ocorrncia de
Entidade-Relacionamento (DER):
http://imasters.com.br/artigo/8568/
entidade. Todavia, em casos especiais,
banco-de-dados/documentacao-deisso , em tipos especficos de entidade,
projetos-web-der/
no encontraremos atributos identificadores. Esse tipo de entidade, a qual no
carece do uso de um atributo identificador chamado e entidade fraca.
Uma entidade fraca depende impreterivelmente da existncia de

outra entidade, dessa forma, sua existncia est vinculada a existncia de
outra entidade. A identificao exclusiva de uma entidade fraca imposta
pela associao (mesclagem) do atributo identificador da entidade considerada proprietria, e de sua chave parcial.
Eventualmente, em casos pontuais, uma entidade fraca pode vir a
ser substituda 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 espessa), a fim de destacarmos a entidade
fraca em um DER:
Funcionrio
(1,n)
possui
Cdigo
Nome
Sobrenome
(1,1)
Dependente
Nome
Sexo
Data_Nascimento
Figura 3.3 Entidade Fraca (Dependente)
3.2.2 Relacionamento
O uso do relacionamento nos

permite realizar associaes entre as
Uma entidade pode ser considerada
como sendo um objeto do
entidades. Por exemplo, no basta
mundo real ora podendo ser identificado
simplesmente conhecermos os
de maneira unvoca. Esse objeto pode ser
funcionrios de uma determinada
um elemento concreto, um evento, um ser,
uma especializao, uma funcionalidade ou
empresa, o projetista de dados
qualquer
outro elemento, tangvel ou no, do
dever associar um funcionrio a
ambiente a ser analisado (CASTRO, E. B.
uma empresa, permitindo que seja
2012).
possvel alcanar algum tipo de informao mais elaborada.
59
Modelagem de Dados
No diagrama entidade-relacionamento, um relacionamento representado graficamente atravs do uso de um losango, ora conectado
por meio de linhas 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
Empresa
trabalha
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
EMPRESA. Ele nos permite referenciar as associaes entre o conjunto
de entidades. Isso , para o relacionamento trabalha, uma ocorrncia
pode ser caracterizada como um par de ocorrncias ora formada pelas
ocorrncias das entidades FUNCIONARIO e EMPRESA.
importante destacar que uma ocorrncia de relacionamento no
ocorre apenas entre entidades diferentes. O conceito de relacionamento
nos permite associarmos 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)
60
Perfeito! A Figura 3.5 nos apresentou um exemplo do uso de um

auto-relacionamento, existente entre a entidade FUNCIONARIO. Entretanto, antes de continuarmos, importante discorrermos sobre o conceito
de uso de papis em uma auto-relacionamento.
O uso de papel em uma entidade vinculada em um auto-relacionamento tem como objetivo promover a identificao correta de uma instncia da entidade 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 referenciado 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:
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 maneira, 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 mximo 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 mximo um funcionrio.
61
Modelagem de Dados
Funcionrio
(1,1)
coordena
(0,2)
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-relacionamento, isso , em um relacionamento formado por
uma nica entidade (relacionamento unrio).
O primeiro tipo de cardinalidade um-para-um, por exemplo, um
empregado gerencia apenas um departamento, que por sua vez, gerenciado por um nico empregado, conforme visualizado na Figura 3.8 abaixo:
Funcionrio
gerencia
Departamento
Figura 3.8 Cardinalidade 1:1
O segundo tipo de cardinalidade um-para-muitos, para exemplificar, considere que um empregado gerencia apenas um departamento;
todavia, um departamento pode ser gerenciado por muitos empregados,
conforme apresentado na Figura 3.9 a seguir:
Funcionrio
62
Figura 3.9 Cardinalidade 1:N
gerencia
Departamento
J o terceiro tipo de cardinalidade a ser estudada, refere-se a muitos-para-muitos, como exemplo, considere que um empregado gerencia
muitos departamentos, e que, por sua vez, um departamento pode ser gerenciado por muitos empregados. Esse exemplo pode ser visualizado por
meio da Figura 3.10:
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:
Cidade
(1,n)
distribuio
(0,1)
Distribuidor
(0,n)
Produto
Figura 3.11 Cardinalidade em relacionamento ternrio
Mediante esse exemplo acima apresentado, vamos realizar a devida

interpretao para elucidar eventuais dvidas pertinentes ao conceito de
cardinalidade. Cada ocorrncia do relacionamento intitulado de distribuio vincula trs ocorrncias de entidade, ou seja, um produto poder
ser distribudo, em uma determinada cidade, onde realizada a distribuio, por um nico e exclusivo distribuidor.
63
Modelagem de Dados
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 aplicada 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
64
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 informaes 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 apresentar 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 atributo, pelo simples fato de permitir que sejam vinculados
a ele diversos dados 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. Atualmente, uma pessoa pode ter dois ou mais
nmeros de telefones, a citar, telefone fixo e telefone celular de
mais de uma operadora;
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
entidade? 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 identificar eventuais cenrios os quais o uso apenas dos conceitos
de entidade e relacionamento visto at o momento no suficiente para
a realizao da modelagem 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 entidade-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 determinado 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.
65
Modelagem de Dados
Com o objetivo de exemplificar esse conceito de entidade especializada, considere a entidade FUNCIONARIO que por sua vez tem como
propsito descrever o tipo (atributos e relacionamento) de cada entidade
de funcionrio em um banco de dados qualquer. Normalmente, esse tipo
de entidade pode vincular 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
identificar 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 funcionrio, 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).
Funcionrio
velocidade_digitao
Secretaria
Tcnico
CPF
data_nascimento
endereo
nome
Engenheiro
CREA
tipo_engenheiro
grau_tcnico
Figura 3.12 Exemplo de entidade genrica e entidades especializadas
66
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 referncia as variadas caractersticas da superclasse, a citar como exemplo, secretria, 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.
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, exercendo funcionalidades distintas.
Outro quesito relevante refere-se a possibilidade de existir vrias especializaes 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 nomeadas respectivamente de FUNCIONARIO_MENSAL
e FUNCIONARIO_HORISTA, 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
entidade 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 subconjuntos 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 considere que um funcionrio no seja pelo menos uma secretria, um tcnico e um engenheiro. Esse detalhe referente s possveis
especializaes dos funcionrios a serem aplicadas no projeto de banco
de dados reportada no ato da entrevista. Ainda assim, possvel nos
depararmos com a possibilidade do projetista de dados especificar que
um conjunto de entidade genrica dever ser representada em mais de um
conjunto de entidades especializadas.
67
Modelagem de Dados
Funcionrio
CPF
data_nascimento
endereo
nome
velocidade_digitao
Secretaria
Tcnico
Engenheiro
CREA
tipo_engenheiro
grau_tcnico
Figura 3.13 Especializao/generalizao TOTAL (t)
68
Uma especializao/generalizao considerada como sendo

EXCLUSIVA quando cada entidade do conjunto de entidade genrica
apresentar-se indispensavelmente 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 entidade em mais de um dos
conjuntos de entidade especializada. Esse tipo de especializao/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/generalizao COMPARTILHADA, tambm por meio
do uso de um DER, simplesmente 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 COMPARTILHADA e EXCLUSIVA ou
TOTAL e PARCIAL.
Para exemplificao considere o MER representado pela Figura
3.14, verifique que no existe nenhuma informao sobre a possibilidade
de um determinado tcnico tambm ser um engenheiro. Isso nos permite
concluir que esse exemplo de uma generalizao/especializao COMPARTILHADA.
Funcionrio
CPF
data_nascimento
endereo
nome
t,c
Tcnico
Engenheiro
CREA
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 consideradas 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,
identificada 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.
69
Modelagem de Dados
Placa
Cdigo_veculo
Velocidade_mxima
Preo
Nmero_passageiros
Carro
ID_veculo
Placa
Nmero_eixos
Preo
Capacidade_peso
Caminho
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 Figura 3.16 que CARRO e CAMINHO tornam-se especializaes da entidade genrica VECULO.
Cdigo_Veculo
Placa
Veculo
Preo
t,c
Nmero_eixos
Capacidade_peso
Caminho
Carro
Velocidade_mxima
nmero_passageiros
Figura 3.16 Generalizao (Veculo)
70
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 descobertas, essas descobertas normalmente envolvem alguns tipos
de entidades e seus respectivos relacionamentos. Inicialmente, o projetista
de banco de dados elabora 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. Normalmente, em uma verso final,
tem-se um nmero considervel de entidades e relacionamentos, deixando
o DER na maioria das vezes indecifrvel. Para essas 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 relacionamentos 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 situaes, torna-se imprescindvel associarmos uma entidade com
a ocorrncia de um relacionamento. importante voc recapitular que o
MER no possibilita em nenhuma circunstncia que seja realizado associaes entre relacionamentos, apenas entre entidades. Sendo assim, uma
entidade associativa tem como propsito vincular um relacionamento
como se o mesmo fosse uma entidade, conforme apresentado como exemplo pela Figura 3.17.
Mdico
(0,n)
consulta
(0,n)
Paciente
Figura 3.17 Agrupamento entre entidades (agregao)
71
Modelagem de Dados
Caso, eventualmente, fosse necessrio controlar os medicamentos

prescritos 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 CONSULTA. 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 representada 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.
Mdico
(0,n)
consulta
(0,n)
Paciente
prescreve
(0,n)
Medicamento
Figura 3.18 Agrupamento das entidades Mdico e Paciente resultando na entidade

associativa Consulta
72
Esse processo tambm denominado de agregao, isso , um

conjunto de relacionamentos e suas respectivas entidades so agregadas
em uma nova entidade. Dessa forma, o exemplo exposto pela Figura
3.18 agrega o relacionamento CONSULTA juntamente com as entidades
MDICO e PACIENTE, constituindo 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 aplicada 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 relacionamentos constituintes da agregao. Para exemplificar, considere que uma determinada consulta pode ou no ter a prescrio de medicamentos.
Mdico
(0,n)
consulta
(0,n)
Paciente
prescreve
(0,n)
Medicamento
Figura 3.19 Entidade associativa
73
Modelagem de Dados
3.4 Diagrama Entidade-Relacionamento (DER)
Antes de iniciarmos esse novo tpico, considere o diagrama entidade-relacionamento de um banco de dados de uma empresa imaginria, ora
representado pela Figura 3.12 abaixo:
Pnome
Nmero
Snome
Nome
Sexo
Nss
Localizao
Nome
N
Endereo
Salrio
EMPREGADO
TRABALHA PARA
consulta
NmeroDeEmpregados
DataIncio
DEPARTAMENTO
DataNasc
1
supervisor
GERENCIA
supervisiona
1
SUPERVISIONA
SUPERVISIONA
Horas
M
1
TRABALHA EM
DEPENDENTE DE
PROJETO
Nome
Nmero
Localizao
DEPENDENTE
Nome
Sexo
DataNasc
Relao
Figura 3.12 Exemplo de Diagrama Entidade-Relacionamento
74
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 retngulos. J os relacionamentos nomeados de
TRABALHA_PARA, GERENCIA, CONTROLA e TRABALHA_EM
utilizam a representao grfica atravs do uso de losangos. Esses relacionamentos tm como intuito realizar a conexo das diversas 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

conectadas 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 atributos 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 atributo LOCALIZAO da entidade DEPARTAMENTO. Os atributos identificadores
(atributos-chaves e ou chave-primria) so identificados por sua vez na
forma sublinhada, 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 pertencente 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 associado a algum tipo
de processamento computacional.
J a identificao de entidades e relacionamentos considerados fracos imposta pelo uso de retngulos e losangos circundados com linhas
duplas. Em nosso exemplo (Figura 3.12), podemos destacar esse conceito,
ora representado pela entidade-fraca, identificada de DEPENDENTE e
seu respectivo relacionamento, 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 interpretao dessa cardinalidade seria:
um empregado gerencia no mximo um departamento 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 DEPARTAMENTO 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 participao parcial, utiliza-se o emprego de linhas simples, todavia,
75
Modelagem de Dados
quando necessitamos 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, fundamental 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 empregado 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 relacionamento ternrio.
Cdigo
Quantidade
Nome
fornece
Fornecedor
Projeto
Cdigo
Nmero
76
Pea
Figura 3.13 Relacionamento ternrio (grau trs)
Nome
A Figura 3.14 nos demonstra um DER a fim de exemplificar um relacionamento binrio. Repare que o relacionamento intitulado de CURSO
emprega apenas dias entidades (ALUNO e DISCIPLINA).
RA
Nome
fornece
Aluno
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 emprego 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 assume o papel mulher).
CPF
Nome
Homem
casamento
Pessoa
Mulher
Figura 3.15 Relacionamento unrio (grau um)
Finalizando o tpico que discorre sobre o grau dos relacionamentos,

possvel visualizarmos por meio da Figura 3.16, um exemplo de relacionamento nrio, ou seja, possvel abstrair uma associao entre n
(diversas) ocorrncias de entidades.
77
Modelagem de Dados
CPF
Quantidade
Nome
Candidato
CNPJ
realiza
Empresa
Entrevista
resultado
Nome
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
identificador, etc., em um diagrama entidade-relacionamento (DER). A
Tabela 3.1 a seguir apresenta as diversas notaes com suas respectivas
descries, empregadas at o presente momento nos exemplos de DER.
Lembrando que, eventualmente, essas representaes grficas (smbolos)
podem sofrer variao dependendo o tipo de ferramenta utilizada na elaborao dos diagramas entidade-relacionamento.
Notao (Simbologia)
Descrio
Entidade
78
Entidade-Fraca
Relacionamento
Relacionamento Identificador
Atributo
Atributo-chave (identificador)
Atributo Multivalorado
Atributo Composto
Atributo Derivado
3.5 modelando o negcio
Bem, agora que voc j aprendeu basicamente todos os conceitos

sobre o diagrama entidade-relacionamento, chegou o momento de colocalos 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
79
Modelagem de Dados
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 algumas informaes, como por exemplo: nome e endereo de cada um dos Campus; 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 funcionalidades expostas na descrio do Sistema de Informao
a ser criado pela Universidade. A Figura 3.17 apresenta um exemplo de
DER que teve como propsito 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 entidades-fracas no box cinza.
Campus
(1,1)
EndCampus
NomeCampus
IdentCampus
possui
(0,n)
Campus x Bloco:
cada instncia desse conjunto
ser identificada por
(IdentCampus + IdentBloco)
Bloco
QtdeSalas
TotalAndares
IdentBloco
(0,n)
localizada
(0,n)
Carteira
(0,n)
alocado
LadoBraoCart
NroPatrimnio
80
Figura 3.17 DER de uma Universidade Fictcia
(1,1)
Sala de aula
NroSala
MetragemSala
QtdCarteirasSala
Sala de Aula:
a identificao unvoca de
cada sala dada por
(IdentCampus + IdentBloco + NroSala)
Atividades
01. Conceitue adequadamente um atributo, e discorra sobre os seus principais tipos. Na sequncia, d pelo menos um exemplo de cada tipo.
02. Conceitue um relacionamento e classifique os relacionamentos em relao ao nmero de objetos envolvidos.
03. 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?
Reflexo
Parabns! Voc finalizou mais um captulo, essa sem dvida foi uma
densa unidade de estudos! Foi possvel aprendermos acerca das principais
caractersticas do Modelo Entidade-Relacionamento, 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, multivalorado, derivado e identificador).
Foi possvel ainda estudarmos acerca da representao grfica do
MER, essa imposta pelo uso do que chamamos de diagrama entidaderelacionamento (DER), sobretudo interpretarmos 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 Recomendada
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
81
Modelagem de Dados
http://imasters.com.br/artigo/8568/banco-de-dados/documentacaode-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!
Referncias
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 Administrao. 8. Ed. So Paulo: Cengage Learning, 2011.
DATE, C. J.; Introduo a Sistemas de Banco de Dados; 8. Ed.; Trad.

Daniel Vieira; Rio de Janeiro: Elsevier, 2003.
82

RAMAKRISHNAN, R. GEHRKE, J. Database Management Systems.

2. ed. Boston: McGraw-Hill, 2000.
CASTRO, E. B.; Modelagem Lgica de Dados: construo bsica e
simplificada; Rio de Janeiro: 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.
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.
83
Modelagem de Dados
Minhas anotaes:
84
Modelo de Dados
Relacional
Cap
t u
lo
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 projeto 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 clssico, e amplamente adotado pela grande
parte dos SGBDs. Estudaremos os conceitos e princpios relevantes,
como os atributos identificadores, restries de integridade, mapeamento
do MER para o modelo relacional, dentre outros.
No perca o foco neste contedo!

Este captulo tem como objetivo permitir um estudo detalhado referente
aos aspectos pertinentes ao modelo de dados relacional, onde, seus principias conceitos podem ser encontrados 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.
Voc se lembra?
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 Modelos de Dados:
Hierrquico, em Rede e Relacional?
Modelagem de Dados
4.1 Modelo De Dados Relacional
O Modelo de Dados Relacional foi criado por Codd na dcada de

70. Esse modelo 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.
tb_Aluno
tb_ Disciplina
tb_pr_requisito
86
RA
Nome
Sala
Departamento
192
Ana Paula
Computao
324
Ceclia
Computao
Cdigo
Nome
Crditos
Departamento
C123
ICC
Computao
C342
Estrutura de
Dados
Computao
M098
Clculo I
Matemtica
C124
Banco de
Dados
Computao
Cdigo
Pr_requisito
C124
C324
C124
M098
C324
C123
Modelo de Dados Relacional Captulo 4
tb_seo
Cdigo
Disciplina
Semestre
Ano
Professor
45
C123
2012
Prof. Ms. Frederico

Valeri
52
C324
2012
Prof. Dr. Rodrigo

Mendes
124
C124
2013
Prof. Ms. Jos

Ribeiro
132
M098
2012
Profa. Ms. Valria

Cruz
139
C324
2013
Prof. Dr. Jean Nunes
155
C124
2013
Prof. Ms. Givanilso

Martins
tb_histrico
RA
Cdigo_Seo
Nvel
192
155
192
139
324
132
324
124
324
52
324
45
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 relacionamento qualquer. Vimos no incio do tpico que
o nome da tabela com os nomes 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 especfico 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). Considere que, para cada coluna, todos os valores associados a mesma, dever,
obrigatoriamente, manipular o mesmo tipo de dado.
87
88
}
7,0
23
8723-8877
Figura 4.2 Tabela aluno com suas respectivas instncias
null
Igor Afonso
523
Av. Nove de Julho, 23
4,8
20
null
3634-0987
Murilo Henrique
21
Rua Javari, 23
9,0
19
8345-0912
null
Bruno Freitas
709
Rua Treze de Maio, 98
7,8
26
9123-0989
null
Av. Pio XII, 1562
Marcia Garcia
324
6,5
21
null
3412-0909
Alice Martins
123
Rua Piau, 87
Mdia
Ponderada
Idade
Celular
Telefone
Endereo
Nome
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 relao 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 determinado 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
Aluno
Aluno (ra, nome, endereo, telefone, celular,

idade, media_ponderada).
RA
Na maioria das literaturas que discorre

sobre o tema Modelo Relacional, uma linha
caracterizada como sendo uma tupla, uma
coluna como um atributo e uma tabela de
relao. Ainda tomando como referncia o
modelo relacional, 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 apresentada
abaixo, que por sua vez, apresenta informaes referentes aos alunos de uma universidade qualquer:
Tuplas
Modelagem de Dados
tupla como sendo uma linha e, cada

atributo existente nessa tabela,
como um cabealho que, tem como
Um domnio descreve os tipos de dados
propsito indicar um papel especque cada campo (atributo) pode armazenar.
fico ou simplesmente promover a
(Heuser, 2004)
interpretao dos valores vinculados a cada coluna.
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 exclusivos, 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 super-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 maneira 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 mesmo no poder sofrer modificaes no transcorrer do tempo. A fim de melhor exemplificar, possvel
89
Modelagem de Dados
90
dizer que o atributo NOME da mesma relao ALUNO 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-candidata. 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 cdigo interno. Nessa
circunstncia, a relao ALUNO teria duas chaves-candidatas, o atributo
RA e CODIGO_ALUNO. Esse recurso considerado normal, isso ,
relativamente comum escolhermos duas chaves-candidatas como chaveprimria (atributo-chave) de uma relao. No modelo de dados relacional,
representamos uma chave-primria, simplesmente sublinhando os atributos que formam a chave-candidata. Se, evenUma
tualmente, uma relao possuir vrias
chave-candidata
chaves-candidatas, a escolha da chave
uma chave que apresenta
mais adequada se torna facultativa,
obrigatoriamente as duas caractersticas a seguir:
porm, a seleo da chave-primria
1)Unicidade: No h duas linhas (tuplas)
com o menor nmero de atributos
distintas na tabela com o mesmo valor para
sempre desejvel.
os atributos da chave (isso j era garantido na
chave e foi explicado na seo anterior);
Uma chave-primria inclui
2)Irredutibilidade: No existe um subconjunalgumas caractersticas relevantes,
to de atributos da chave que apresentem
a considerar a seguir:
a caracterstica de Unicidade.
(Date, 2004)
Unvoca (exclusiva): os
atributos definidos para
constituir a chave-primria, por
definio, tm que possuir valores
nicos para cada registro (ou tupla) na relao. Isso significa
que todas as linhas devem ser identificadas 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 poder, em hiptese alguma, possuir valores nulos em
nenhum registro;
No redundante: 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.
Reflita: O que voc entende sobre redundncia controlada?

A redundncia controlada considerada um dos princpios do funcionamento dos bancos de dados relacionais, permitindo que distintas
tabelas compartilhem 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 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
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 chaveestrangeira (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 ainda, 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:
I. Impedimento: uma operao de atualizao no ser concluda;
II. Cascata: se ocorrer uma excluso de uma tupla (t) qualquer ora
armazenada 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 R 2, 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);
91
Modelagem de Dados
III. Anulao: se ocorrer uma excluso ou uma alterao de uma tupla (t) de R 2, dessa maneira para toda tupla de R1 tal que a chaveestrangeira referencie a chave-primria de (t) dever configurar o valor
da chave-estrangeira 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
Cd.
Emp
Nome
Sobrenome
DataNasc
Endereo
Sexo
Cd.
Depto
Salrio
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
Dependente
Cd
Empregado
Cd
Dependente
Nome
Sexo
DataNasc
Relao
Figura 4.3 Esquema Relacional de uma organizao fictcia
92
Analisando o esquema relacional apresentado pela Figura 4.3,

possvel identificar que o atributo chamado CdDepto da relao intitulada de DEPARTAMENTO 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 CdDepto presente nas relaes EMPREGADO e PROJETO. Para o nosso exemplo, utilizamos nomes iguais,
todavia, isso no regra, podemos utilizar nomes diferentes para os mesmos atributos, sem qualquer tipo de restrio. Normalmente, atributos 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 banco de dados relacional apresentado pela Figura 4.3, como, por
exemplo, as restries 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 integridade de entidade
(RIE) e a restrio de integridade referencial (RIR).
A restrio de integridade de entidade (RIE) que tem como objetivo
determinar que absolutamente nenhum valor vinculado chave-primria
seja nulo, simplesmente por utilizamos esse valor de chave-primria para
identificar unicamente as tuplas na relao. Como exemplo, assuma que
existam duas tuplas ou mais com valores nulos associados chave-primria. Dessa forma, no existiria nenhuma maneira de identificar exclusivamente uma tupla da outra.
A outra restrio chamada de restrio de integridade referencial
(RIE) possui 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, referenciar a uma tupla existente naquela
mesma relao. A Figura 4.4, factvel 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.
93
Modelagem de Dados
As restries de integridade referencial so provenientes dos relacionamentos entre 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 restries
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.
Emp
Nome
Sobrenome
DataNasc
Endereo
Sexo
Salrio
CdDepto
101
Joaquim
Mendes
09/01
/1995
Rua
A, 1
R$3.500,00
15
102
Elton
da Cruz
08/12
/1965
Rua B,
234
R$2.350,00
15
103
Juliano
Batista
19/07
1965
Av C,
78
R$1.775,00
24
104
Vanda
da Silva
30/06
1961
Rua D,
98
R$4.565,00
24
105
Emersom
Frota
16/09
/1968
Rua E,
21
R$9.100,00
15
106
Fabrcio
dos
Santos
31/07
/1986
Av J,
1347
R$8.100,00
15
107
Michelle
Pavereli
30/03
/1989
Av H,
76
R$2.450,00
24
108
Venilton
Jos
02/11
/1965
Rua T,
76
R$8.899,00
11
Departamento
94
Cd
Depto
Nome
CdGerente
Datal Inico Gerente
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
20
IRPF 2013
Mococa
15
30
ERP
RibeiroPreto
24
40
SAP
RibeiroPreto
24
Trabalho_Projeto
CdProjeto
Horas
101
11
40
101
11
55
108
40
67
103
30
90
105
20
120
108
13
102
12
30
104
30
24
106
40
18
107
11
CdEmpregado
95
Modelagem de Dados
Dependente
Cd
Empregado
Cd
Dependente
Nome
Sexo
DataNasc
Relao
101
Joo
28/02/2000
Filho
101
Pedro
10/10/2007
Filho
108
Sandra
01/07/2005
Sogra
105
Marcia
28/09/1940
Filha
105
Sabrina
17/04/2003
Filha
107
Guilherme
09/09/2008
Filho
103
Izadora
10/12/2012
Filha
Figura 4.4 Instncias do Esquema de banco de dados relacional
96
Dando sequencia nos conceitos de restrio de integridade referencial RIR, torna-se necessrio apresentar o conceito de chave-estrangeira
(CE). Uma chave-estrangeira (do ingls foreign key) determina a existncia de uma integridade referencial aplicada entre duas relaes (R1 e R2)
e ou, eventualmente, aplicada em uma mesma relao.
Voc j aprendeu que normalmente um banco de dados, independentemente 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 obter 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 EMPREGADO, o atributo CdDepto refere-se ao departamento em que cada empregado 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 existente 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 correspondente 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 tupla referente ao empregado Venilton Jos se
encontra vinculado ao atributo 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 chaveestrangeira recursiva. A fim de exemplificar graficamente o emprego das
restries de integridade referencial, visualize a Figura 4.5, a qual nos
apresenta um esquema relacional com inmeras restries de integridade
referencial, ora representadas pelo uso de setas direcionais.
Empregado
CdEmp
Nome
Sobrenome
Departamento
CdDepto
Nome
CdGerente DataInicioGerente
Depto_Localizao
CdDepto
Projeto
CdProjeto
Dependente
CdEmpregado
Endereo
Sexo
Salrio
CdDepto
DeptoLocalizao
Nome
Trabalha_Projeto
CdEmpregado
DataNasc
ProjLocalizao CdDepto
CdProjeto
CdDependente
Horas
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 esquema 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
97
Modelagem de Dados
a definio dos variados tipos de restries, assegurando que essa verificao seja realizada pelo SGBD-R de forma automtica.
Estudamos at aqui apenas as restries de integridade de entidade
e referencial, porm, outras restries, a citar, restries de integridade semntica, tambm podem ser aplicadas em um banco de dados relacional.
Para exemplificar 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 operaes triviais (insero, alterao e remoo) empregadas em
um esquema de banco de dados relacional qualquer. A primeira operao
discorre sobre a insero, 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 alterados, 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 atendidas a fim de evitar
eventuais inconsistncias indesejveis.
4.4 Mapeamento do MER para o Modelo

Relacional
O
MER foi criado
98
Podemos utilizar n esquemas

para dar subsdio ao procesrelacionais para um esquema ER,
so de modelagem de dados que
possui como objetivo realizar a construisso , existe diversas formas de se
o de bancos de dados (ROB, 2005).
implementar uma modelagem conceitual abstrata.
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 considerado 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
3. Mapeamento de relacionamentos e seus atributos
Para exemplificar, considere a Figura 4.6, ora representada por uma
entidade 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 (chave-primria) representado pelo uso de um sublinhado
no nome do atributo.
Empregados
RG
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-estrangeira na tabela fraca. Esse exemplo pode ser
visualizado na Figura 4.7. Lembre-se que a entidade-fraca nesse exemplo
ITENS. Note que foi utilizada uma chave-primria composta para esse
exemplo.
99
Modelagem de Dados
(1,1)
Pedido
(1,n)
composto
Cdigo
Produto
Quantidade
Itens
Nmero
CE Chave Estrangeira
Itens (NrPedido, CdItem, Produto, Quantidade)
CP Chave Primria Composta
Figura 4.7 Mapeamento da entidade-fraca (ITENS)
J o exemplo apresentado pela Figura 4.8, realizado o mapeamento dos atributos (obrigatrio, opcional e composto):
PlanoSade (0,1)
Telefone (1,n)
Rua
Nmero
Cidade
Endereo
Empregados
RG
Nome
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)
100
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
Nmero
Cidade
Endereo
Empregados
RG
Nome
Idade
EMPREGADOS (RG, Nome, Idade, PlanoSade, Rua, Nmero,

Cidade, FoneRes, FoneCom, Celular)
Figura 4.9 Outra maneira de realizar o mapeando dos atributos
Agora, a respeito do mapeamento de entidades especializadas,

deve-se considerar trs opes:
1. Opo: considerar uma nica tabela para a entidade considerada genrica e suas especializaes;
2. Opo: considerar o uso de tabelas para entidade genrica e
para as entidades especializadas;
3. Opo: considerar o uso de tabelas apenas para as entidades
especializadas.
No prximo exemplo, a 1 opo adotada. Repare na Figura 4.10
que foi realizado o mapeamento da entidade genrica e suas respectivas
entidades especializadas, mesclando tudo em uma nica tabela. Dessa
maneira, o atributo tipo pode armazenar mais de um valor apenas se, a
especializao for no-exclusiva.
101
Modelagem de Dados
SERVIDORES
Funo
FUNCIONRIOS
CPF
Nome
PROFESSORES
Titulao
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, considere 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.
SERVIDORES
Funo
102
FUNCIONRIOS
CPF
Nome
PROFESSORES
SERVIDORES (CPF, Nome)

FUNCIONRIOS (CPF, Funo)
PROFESSORES (CPF, Titulao, Categoria)
Figura 4.11 2 alternativa: Mapeando de entidade genrica e especializada
Titulao
Categoria
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 especializaes parciais.
SERVIDORES
Funo
FUNCIONRIOS
CPF
Nome
PROFESSORES
Titulao
Categoria
FUNCIONRIOS (CPF, Nome, Funo)

PROFESSORES (CPF, Nome, Titulao, Categoria)
Figura 4.12 3 alternativa: Mapeando apenas as entidades especializadas
O mapeamento dos relacionamentos considera uma anlise aplicada

na cardinalidade existente nos relacionamentos. Aps essa anlise, diversas alternativas de mapeamento podem ser escolhidas, a citar: as entidades
ora relacionadas 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 corretamente o relacionamento. A Figura 4.13 apresenta
um exemplo de mapeamento de um relacionamento, cujo cardinalidade
1:1 (um-para-um), ou seja, obrigatrio em ambos os sentidos.
103
Modelagem de Dados
Obrigatrio em ambos os lados
CONFERNCIAS
Sigla
(1,1)
(1,1)
Organizao
COMISSES
Endereo
eMail
Nmero
DataInstalao
Nome
CONFERNCIAS (Sigla, Nome, DataIstComisso, NrComisso,

EndereoComisso, eMailComisso)
Figura 4.13 Mapeando um relacionamento (1:1).
Como outro exemplo, podemos tomar o mapeamento de um relacionamento 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.
Opcional: cardinalidade(mnima, mxima)
PESSOAS
Cdigo
(1,1)
Nome
Posse
(0,1)
CARTEIRAS_MOTORISTA
DataRetirada
DataExpedio
Validade
Categoria
Nmero
PESSOAS (Cdigo, Nome, NmeroCarteiraMotorista, DataExpedio,

Validade, Categoria, DataRetirada)
Figura 4.14 1 alternativa: Opcional em um dos sentidos
104
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)
PESSOAS
Cdigo
(0,1)
Posse
CARTEIRAS_MOTORISTA
DataRetirada
Nome
DataExpedio
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 relacionamento opcional em ambos os sentidos, isso , a cardinalidade
mnima das entidades denominadas HOMENS e MULHERES respectivamente, equivalem zero, simbolizando um relacionamento opcional
independentemente do sentido utilizado.
Opcional em ambos os lados
HOMENS
RG
(0,1)
Nome
(0,1)
Casamento
Data
MULHERES
RG
Nome
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 considera o mesmo relacionamento anterior, ou seja, opcional em ambos
os sentidos, porm realiza o mapeamento apenas das entidades envolvidas.
105
Modelagem de Dados
Opcional em ambos os lados

(0,1)
HOMENS
Nome
RG
(0,1)
Casamento
MULHERES
Data
RG
Nome
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 obrigatrio e ou opcional do lado N. O exemplo a seguir, ora representado pela Figura 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, torna-se possvel visualizar o
mapeamento final utilizando duas tabelas, essas nomeadas de DEPARTAMENTOS e EMPREGADOS e, ainda, que o atributo referente ao relacionamento LOTAO se encontra includo na tabela EMPREGADOS.
Obrigatrio/Opcional do lado n
(1,n)
(1,1)
Lotao
EMPREGADOS
DEPARTAMENTOS
(0,n)
Cdigo
Nome
Data
Cdigo
DEPARTAMENTOS (Cdigo, Nome)
106
EMPREGADOS (CPF, Nome, CdDepto, DataLotao)

Figura 4.18 Mapeando do relacionamento (obrigatrio e opcional)
Nome
Repare agora que, quando trabalhamos com relacionamentos 1:N e

opcional 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 relacionamento POSSE, que por sua vez, possui
como caracterstica os atributos RG (chave-estrangeira), chassi (chaveprimria e chave-estrangeira) e DataCompra.
Opcional no lado 1
(1,n)
Posse
AUTOMVEIS
(0,1)
PESSOAS
(0,n)
Ano
Modelo
Chassi
DataCompra
RG
Nome
PESSOAS (RG, Nome)

AUTOMVEIS (Chassi, Modelo, Ano)
POSSE (RG, Chassi, DataCompra)
Figura 4.19 1 Opo: Mapeamento do relacionamento (opcional lado 1).
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 tabelas 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.
107
Modelagem de Dados
Opcional no lado 1
(1,n)
Posse
AUTOMVEIS
(0,1)
PESSOAS
(0,n)
Ano
Modelo
Chassi
DataCompra
RG
Nome
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.

Verifique que temos trs tabelas resultantes do processo de mapeamento, ou
seja, duas tabelas para mapear as entidades EMPREGADOS e PROJETOS
respectivamente, e outra tabela exclusiva para mapear o relacionamento PARTICIPAO. Dessa maneira, a tabela PARTICIPAO formada pelos atributos RG, cdigo e DataIncio, e ainda, note que RG e cdigo tornam-se os
atributos identificadores 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.
Obrigatrio/Opcional em ambos os sentidos
(1,n)
Participao
EMPREGADOS
(0,n)
Nome
RG
(1,n)
PROJETOS
(0,n)
DataIncio
Cdigo
Nome
EMPREGADOS (RG, Nome)
108
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

mapeamento 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 visualizado duas alternativas de mapeamento de um
auto-relacionamento. importante lembrar que para esse tipo de relacionamento imprescindvel o uso de papis, esses utilizados para identificar
adequadamente o papel de cada instncia de EMPREGADOS, ora assumindo o papel de GERENTE e ou SUBORDINADO.
gerente
(0,1)
Gerncia
EMPREGADOS
(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
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.
109
Modelagem de Dados
EMPRSTIMOS
LIVROS
(0,n)
(0,1)
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 mapeamento em relacionamento de grau trs. A Figura 4.24 representa
um exemplo do processo de mapeamento aplicado em um relacionamento
dito como ternrio, esse formado pelas entidades INSTITUIES, PROJETOS e PESQUISADORES. 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 quatro tabelas, uma destinada para cada entidade e outra exclusiva para o relacionamento intitulado de PESQUISA.
DataIncio
INSTITUIES
110
(1,n)
Pesquisa
(0,n)
Sigla
PROJETOS
Nmero
(1,n)
PESQUISADORES
RG
(1,n)
PESQUISADORES
RG
Caso: N:N:N
INSTITUIES (Sigla, ...)
PROJETOS (Nmero, ...)
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 aplicado em um relacionamento ternrio. Como resultado final do
processo de mapeamento, foi obtido quatro tabelas, similar ao exemplo
apresentado pela Figura 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-primria da tabela DISTRIBUIO por simplesmente possibilitar que um produto seja distribudo
em uma cidade por nenhum ou no mximo um distribuidor.
(0,n)
PRODUTOS
Distribuio
(0,n)
Cdigo
CIDADES
Cdigo
(0,1)
DISTRIBUIDORES
RG
Caso: 1:N:N
PRODUTOS (Cdigo, ...)
CIDADES (Cdigo, ...)
DISTRIBUIDORES (RG, ...)
DISTRIBUIO (CdProduto, CdCidade, RG)
111
(0,1)
Modelagem de Dados
DISTRIBUIDORES
RG
Caso: 1:N:N
PRODUTOS (Cdigo, ...)
CIDADES (Cdigo, ...)
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 Figura 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.
CORRESPONDNCIAS
(0,n)
Entrega
Peso
Cdigo
(0,n)
Cdigo
(0,1)
CARTEIROS
BAIRROS
RG
Caso: 1:1:N
BAIRROS(Cdigo, ...)
CARTEIROS (RG, ...)
112
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 atributos Cdigo, PesoPainel,
CdMotor, FabrMotor, CdLataria e ModLataria.
PAINIS
(1,1)
Peso
Cdigo
Veculo
(1,1)
MOTORES
(1,1)
Fabricante
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).
Atividades
01. Conceitue chave-primria simples e composta. D pelo menos trs
exemplo de cada tipo de chave-primria.
02. 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.
03. Analise os requisitos a seguir e constitua sua modelagem relacional
que atenda algumas necessidades de informao, a citar: Qual o cdigo e
113
Modelagem de Dados
a descrio de cada projeto desempenhado 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;
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;
04. 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. Esperamos 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.
114
Leitura Recomendada
Artigos on-line: para que voc possa aumentar ainda mais o seu nvel de aprendizagem referente ao modelo de dados relacional:
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 unidade. fortemente recomendado que voc maximize seus conhecimentos nestas bibliografias.
Referncias

Books, 1995.
2011.
115
Modelagem de Dados

CASTRO, E. B.; Modelagem Lgica de Dados: construo bsica e
simplificada; Rio de Janeiro: 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.
No prximo captulo
No prximo captulo, estudaremos sobre o processo de normalizao, conceito tambm considerado importantssimo para obtermos projetos de banco de dados ntegros e concisos!
116
Normalizao
Cap
t u
lo
No captulo anterior, aprendemos

sobre o modelo de dados relacional, regras de integridade de entidade e referencial.
Vamos agora aumentar nossos conhecimentos
num assunto de extrema relevncia para a criao de
projetos de banco 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 amplamente 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 dependncias funcionais.
Para fechar a unidade, estudaremos com exemplos prticos as cinco formas normais (1FN, 2FN, 3FN, 4FN e 5FN), enfatizando as trs primeiras,
essas consideradas 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 dependncias funcionais ocorrem. Para isso, a partir de agora, fique atendo
quando abordamos conceitos sobre dependncias funcionais.

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.
Voc se lembra?
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?
Modelagem de Dados
5.1 Normalizao
118
Em algumas ocasies, aplicaes computacionais podem apresentar

problemas 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 qualquer tipo de redundncia caracterizada como indesejvel, ora presentes em alguns 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 estruturado e conciso.
Em meados dos anos 70, quando Codd criou os primeiros conceitos que discorriam sobre o processo de normalizao, pouco se conhecia
sobre seu propsito. 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, alterao 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 indesejveis sem ocasionar perda de informao.
Ao se conduzir um processo de normalizao de dados em um
banco de dados 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.
Normalizao Captulo 5
As fases do processo de normalizao de dados devem ser realizadas de maneira contnua (em cascata), ou seja, inicialmente deve-se
aplicar a primeira forma normal (1FN), na sequncia, deve-se aplicar
a segunda forma-normal (2FN), logo aps, deve-se conduzir a terceira
forma-normal (3FN), posteriormente, 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, sucessivamente.
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
Regras de Normalizao: as regras
de
normalizao podem ser consideatende a nenhuma das regras da
radas como sendo uma formalizao dos
1FN, e, na maioria das vezes, essa
bons princpios para o projeto de bancos de
tabela pode possuir uma ou mais
dados ou ainda como regras de conduta na
tabelas ditas como aninhadas (uma definio de registros em um projeto de banco
de dados. (CASTRO, 2012).
tabela dentro de outra tabela, e assim, sucessivamente).
Uma tabela dita como aninhada quando possui grupo de dados
redundantes, colunas multivaloradas, colunas no atmicas, isso , no possui dados atmicos, e sim, tabelas inclusas dentro de outras. Para apresentar um exemplo
de tabela aninhada (no normalizada) considere a Figura 5.1.
119
120
Sistema ERP
Desenvolvimento de
Solfware
Manuteno
PSI001
PSI034
Figura 5.1 Exemplo de aninhamento de tabelas
Sistema Apoio
Deciso
Descrio
Tipo
CdProjeto
A2
Joo de
Freitas
2141
A1
Sonia
Purcini
1189
C1
A1
Sonia
Purcini
1189
Jos
Ribeiro
A2
Carlos da
Silva
6162
4211
C1
Jos
Ribeiro
A2
Fbio
Cardoso
5134
4211
A1
Victor Nunes
6124
Categoria
Nome
Cd
Empregado
Salrio
Empregado
11/01/2002
01/04/2001
05/01/2003
11/01/2002
10/04/2002
10/03/2002
10/02/2001
11/01/2001
Data incio
24
48
24
24
36
36
48
48
Tempo
Modelagem de Dados
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,
Categoria, 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 anomalias de insero, alterao e remoo.
O processo de normalizao de dados deve seguir obrigatoriamente
a hierarquia 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
121
Modelagem de Dados
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 aninhada, 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 consideradas monovalorados.
A transformao de uma tabela no normalizada, ou dita tambm
como aninhada em um esquema que atenda as regras pertinentes a 1FN
envolve basicamente duas alternativas: lanar uso de uma nica tabela
aninhada contendo redundncia 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 externas tabela aninhada so repetidos para cada linha
da tabela aninhada.
Tabela No-Normalizada (Aninhada):
1FN (1 Alternativa):
122
Perceba que os registros pertinentes ao projeto so duplicados para

cada empregado que trabalha no projeto.
J a segunda alternativa para a aplicao da 1FN na tabela aninhada

utilizada como exemplo, cria-se uma tabela para a prpria tabela que est
sendo normalizada e uma tabela para representar cada tabela considerada
aninhada.
PROJETOS (CdProjeto, Tipo, Descrio,CdEmpregado, Nome,
Categoria, Salrio, DataIncio, Tempo).
1FN (2 Alternativa)
PROJETOS (CdProjeto, Tipo, Descrio).
PROJETOS_EMPREGADOS (CdEmpregado, Nome, Categoria,

Salrio, DataIncio, 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 preferncia 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 alternativa, 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, dividimos em fases como descritas a seguir:
1 Fase: a chave-primria da tabela na 1FN basicamente igual
chave-primria da tabela aninhada (no normalizada).
123
Modelagem de Dados

(CdProjeto, Tipo, Descrio,(CdEmpregado, Nome, Categoria,
Salrio, DataIncio, Tempo)).
1FN:
2 Fase: constituir uma nova tabela, essa constituda pelas
chaves-primrias de cada uma das tabelas na qual a tabela em
questo se encontra aninhada, e, outra tabela constituda pelas
colunas da prpria tabela aninhada.
(CdProjeto, Tipo, Descrio, (CdEmpregado, Nome, Categoria,
1FN:
(CdProjeto, Tipo, Descrio) (CdProjeto, CdEmpregado,
Nome, Categoria, Salrio, DataIncio, Tempo)).
124
3 Fase: estabelecer, na 1FN, as chaves-primrias das tabelas

correspondentes tabela aninhada. Nessa fase ento, para a
tabela externa, simplesmente transcrevemos a chave-primria
para a tabela na 1FN.

(CdProjeto, Tipo, Descrio, (CdEmpregado, Nome, Categoria,
1FN:
(CdProjeto, Tipo, Descrio) (CdProjeto, CdEmpregado, Nome,
Categoria, 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 considerada ideal para tabela PROJETOS_EMPREGADOS?
Para escolhermos uma chave-primria adequadamente, torna-se necessrio identificar com qual frequncia 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,
eventualmente, pode trabalhar em diversos projetos. Para exemplificar,
os empregados Sonia Purcini e Jos Ribeiro, esto alocados em dois projetos, esses descritos como Sistema ERP e Sistema de Apoio Deciso.
Dessa forma, os valores associados coluna CdEmpregado (chaveprimria da tabela aninhada), de forma inoportuna, se apresenta diversas
vezes na tabela aninhada.
Sendo assim, torna-se necessrio a associao entre as colunas
CdEmpregado e CdProjeto para identificar exclusivamente as diversas
ocorrncias, constituindo dessa maneira, o que denominamos de chaveprimria composta.
1FN:
Categoria, 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.
125
Modelagem de Dados
CdProjeto
Tipo
Descrio
PSI001
Desenvolvimento de
Solfware
Sistema ERP
PSI034
Manuteno
Sistema Apoio Deciso
Empregado
CdProjeto
Cd
Empregado
Nome
Categoria
Salrio
Data incio
Tempo
PIS001
6124
Victor
Nunes
A1
11/01/2001
48
PIS001
5134
Fbio
Cardoso
A2
10/02/2001
48
PIS001
4211
Jos
Ribeiro
C1
10/03/2002
36
PIS001
6162
Carlos da
Silva
A2
10/04/2002
36
PIS001
1189
Sonia
Purcini
A1
11/01/2002
24
PSI034
1189
Sonia
Purcini
A1
05/01/2003
24
PSI034
4211
Jos
Ribeiro
C1
01/04/2001
48
PSI034z
2141
Joo de
Freitas
A2
11/01/2002
24
Figura 5.3 Tabelas resultantes da 1FN (a partir de uma tabela aninhada).
5.1.3 Regra: Segunda Forma Normal (2FN)
126
Para que seja possvel estudarmos as regras pertinentes a 2FN e

3FN, torna-se crucial o entendimento adequado do conceito de dependncia funcional. Considere uma tabela relacional qualquer, dizemos que uma
coluna C2 depende funcionalmente 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 dependncia 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 funcional entre as colunas intituladas de A e B.
A
20
15
20
20
15
15
10
18
12
18
10
18
20
15
10
18
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).
127
Modelagem de Dados
20
15
20
20
15
15
10
18
12
18
10
18
20
15
10
18
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 propsito eliminar um determinado tipo de redundncia de
dados. Para exemplificar, considere o esquema a seguir:
(CdProjeto, CdEmpregado, Nome, Categoria, Salrio, DataIncio,
Tempo).
possvel identificarmos que os dados referente ao empregado

(Nome, Categoria 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.
128
Empregado
CdProjeto
Cd
Empregado
Nome
Categoria
Salrio
Data incio
Tempo
PIS001
6124
Victor
Nunes
A1
11/01/2001
48
PIS001
5134
Fbio
Cardoso
A2
10/02/2001
48
PIS001
4211
Jos
Ribeiro
C1
10/03/2002
36
PIS001
6162
Carlos da
Silva
A2
10/04/2002
36
PIS001
1189
Sonia
Purcini
A1
11/01/2002
24
PSI034
1189
Sonia
Purcini
A1
05/01/2003
24
PSI034
4211
Jos
Ribeiro
C1
01/04/2001
48
2141
Joo de
Freitas
A2
11/01/2002
24
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 funcional parcial? Uma dependncia funcional parcial formada
quando uma determinada coluna depende apenas de parte de uma chaveprimria 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 CdEmpregado) para identificar exclusivamente os valores
pertinentes as colunas nome, categoria e salrio.
129
Modelagem de Dados
Com o propsito de distinguir uma dependncia funcional parcial

de uma dependncia funcional no parcial, considere o esquema utilizado
acima, entretanto, verifique que destacamos apenas as colunas que dependem de toda a chave-primria composta.
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 chaveprimria (chave-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-primria simples).
1FN:
2FN:
(CdProjeto, Tipo, Descrio)
130
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, Salrio,
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 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, conforme apresentado no esquema a seguir:
1FN:
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.
Projetos
CdProjeto
Tipo
Descrio
PSI001
Desenvolvimento de
Solfware
Sistema ERP
PSI034
Manuteno

131
Modelagem de Dados
Tabela: Projetos_empregados
CdProjeto
Cd
Empregado
Data incio
Tempo
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
Empregado
Nome
Categoria
Salrio
6124
Victor Nunes
A1
5134
Fbio
Cardoso
A2
4211
Jos
Ribeiro
C1
6162
Carlos da
Silva
A2
1189
Sonia
Purcini
A1
1189
Sonia
Purcini
A1
4211
Jos
Ribeiro
C1
2141
Joo de Freitas
A2
Figura 5.8 Tabelas resultantes do processo de normalizao (2FN).
5.1.4 Regra: Terceira Forma Normal (3FN)
132
As regras referente 3FN tem como objetivo solucionar um outro

tipo de redundncia, conforme apresentado pelo esquema abaixo:
2FN:
Empregados (CdEmpregado, Nome, Categoria, Salrio)
Detalhando o esquema apresentado anteriormente, note que a coluna Salrio 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 Empregados.
Tabela: Empregados
Cd
Empregado
Nome
Categoria
Salrio
6124
Victor Nunes
A1
5134
Fbio
Cardoso
A2
4211
Jos
Ribeiro
C1
6162
Carlos da
Silva
A2
1189
Sonia
Purcini
A1
1189
Sonia
Purcini
A1
4211
Jos
Ribeiro
C1
2141
Joo de Freitas
A2
Figura 5.9 Tabela Empregados
Na sequncia, analisaremos as dependncias funcionais existentes

no esquema que representa a tabela Empregados.
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 Empregados atenda as regras da 3FN, torna-se necessrio eli133
Modelagem de Dados
minar a dependncia funcional transitiva presente nela, deixando apenas

colunas que dependem da chave-primria na tabela original, conforme
demonstrado pelo esquema a seguir:
2FN:
3FN:
Empregados (CdEmpregado, Nome, Categoria)
Dessa maneira, as colunas que dependem de uma coluna que no
chave-primria devem constituir uma nova tabela, conforme apresentado
pelo esquema 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 abaixo:
134
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
PSI001
Desenvolvimento de
Solfware
Sistema ERP
PSI034
Manuteno
Tabela: Projetos_empregados
CdProjeto
Cd
Empregado
Data incio
Tempo
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
Empregado
Nome
Categoria
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
135
Modelagem de Dados
Tabela: Categorias
CdCategoria
Salrios
A1
A2
C1
Figura 5.10 Tabelas resultantes do esquema (3FN).
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 seguir, constitudo pelas entidades PROJETO, EQUIPAMENTO e
EMPREGADO, as quais se relacionamento por intermdio do relacionamento ora identificado de UTILIZAO.
PROJETO
Cdigo
Nome
EQUIPAMENTO
Cdigo
Nome
Utilizao
EMPREGADO
Cdigo
Nome
Figura 5.11 Relacionamento Ternrio
136
Suponha que seja necessrio realizar o controle dos equipamentos

utilizados 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 apresentado na Figura 5.12.
Tabela: Utilizao
CdProjeto
CdEmpregado
CdEquipamento
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 desse tipo de dependncia funcional. Note que a sua notao
diferente das demais dependncias funcionais estudadas at o presente
momento.
137
Modelagem de Dados
Tabela: Utilizao
Tabela: Utilizao
CdProjeto CdEmpregado CdEquipamento

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

1
1
1
1
2
1
1
3
1
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 seguinte 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 Projetos_Equipamentos presentes no esquema anterior contemplam
as regras pertinentes a 4FN.
5.1.6 Regra: Quinta Forma Normal (5FN)
138
Uma tabela se encontra na 5FN se a mesma no possuir nenhuma

dependncia funcional cclica. Mas afinal, o que significa uma dependncia funcional cclica?
Uma dependncia funcional cclica ocorre quando as seguintes dependncias esto presentes em uma tabela:
A B; B C; C A
Ou seja, B depende funcionalComparando as regras da

mente de A, C depende funcio3FN
e
BCNF, factvel de identificar
nalmente de B e, por sua vez, A
a existncia de vantagens para a 3FN,
depende funcionalmente de C,
na medida em que sabemos que sempre
fechando um ciclo, caracterizan possvel obter um projeto que atenda as
regras da 3FN sem sacrificar a preservao
do uma dependncia funcional
de dependncia ou da ausncia de perda.
cclica.
(Silberschatz, et Al, 2006).
Para ilustrar melhor a ocorrncia de uma dependncia funcional cclica, suponha os requisitos de
negcio de uma instituio de ensino
superior, onde um professor pode ministrar
diversas disciplinas (Professor Disciplina), isso ,
nesse caso, dizemos que Disciplina depende funcionalmente de Professor,
conforme demonstrada pela tabela PROFESSOR ora representada pela
Figura 5.14:
Tabela: Professor
Professor
Disciplina
Banco de Dados 1
Jos Ribeiro
Bancos de Dados 2
Fernando Feliciano
Engenharia de Software
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.
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
Prof. Esp. Jos Cardoso
Gerenciamento de Projetos
Figura 5.15 Dependncia Funcional Cclica (Professor_Apostila).

139
Modelagem de Dados
Por fim, a exemplificao da dependncia funcional cclica, a tabela

Disciplina_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).
140
Conexo:
Leia mais sobre normalizao de dados em:
http://imasters.com.br/artigo/7020/
Posteriormente a visualizao
banco-de-dados/modelagem-de-dadosdas trs tabelas (Professor, Profesfinal-normalizacao/
sor_Apostila e Disciplina_Apostila),
possvel identificar a relao cclica
existente entre Professor Disciplina;
Disciplina Apostila e Professor
Apostila.
No processo de normalizao de bancos de
dados relacionais, eventualmente, podemos nos deparar com alguns problemas, por exemplo, o uso de chaves primrias incorretas ou at mesmo
omitidas; atributos considerados relevantes no representados corretamente e possveis atributos no relevantes, redundantes ou derivados.
Chaves-primrias omitidas ou utilizadas de forma inadequada podem surgir em uma tabela devido ao conceito de uma chave-primria no
ser obrigatria, 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 chaveprimria 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-primria estivesse presente e, principalmente,
inseri-la na forma no normalizada.
Atividades
01. Conceitue adequadamente o processo de normalizao de dados. Cite
suar principais formas.
02. Defina com suas palavras o conceito de dependncia funcional parcial.
03. Apresente um exemplo de dependncia funcional transitiva.
04. 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 dados. 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 adequadamente 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 Recomendada
Artigos on-line: para voc incrementar mais o seu nvel de aprendizagem do processo de normalizao de dados:
http://www.devmedia.com.br/normalizacao-de-banco-de-dados/29555
http://www.devmedia.com.br/passo-a-passo-para-modelagem-dedados/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 baseada nos conceitos deste
141
Modelagem de Dados
livro. Vale a pena sua consulta. Dedique-se bastante sobre o processo de

normalizao de dados, conhecer as principais regras de normalizao de
grande importncia para manipularmos dados de forma integra e concisa.
Referncias
Books, 1995.
2011.

142

Gabarito
Captulo 1
01. 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 Costa.
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
associado ao contexto hospitalar, gerando a informao de que esse dado diz respeito
ao nome de uma paciente qualquer. Dessa maneira, podemos concluir de que o dado nico e exclusivamente sozinho no nos gera nenhuma informao, tornando-se imprescindvel conhecermos o contexto (regra de negcio) o qual o mesmo se encontra associado.
02. 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 utilizamos a primeira opo, a citar: a estrutura de arquivos definida pelo prprio cdigofonte do sistema computacional, prejudicando consideravelmente sua manuteno; o
controle de acesso desses arquivos apresentam grandes obstculos quando mencionamos
o compartilhamento; 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 reportados 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.
03. 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.
143
Modelagem de Dados
Captulo 2
01. 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 armazenar 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
vrias 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 Departamento 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 ministrada por um ou vrios professores.
02. 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
Razo_Social
Endereo
Universidade
Nmero_Sala
Tamanho
Andar
(1,1)
(1,n)
possui
Sala de Aula
(1,1)
contm
(0,n)
Cdigo
Descrio
144
Tipo Mvel
(1,1)
possui
(0,n) Mvel/Mobilia
Cdigo
Descrio
03. Discorra sobre os detalhes pertinentes ao Modelo Hierrquico, apontando suas

desvantagens comparando com o Modelo em Rede.
Sugesto de Resposta: A estrutura lgica do modelo hierrquico constituda por uma
estrutura similar a estrutura de uma rvore, essa visualizada de cima para baixo, permitindo a visualizao das suas respectivas ramificaes. Como principais desvantagens,
comparando-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.
04. 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.
05. 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 muitos (1:M ou 1..*), muitos para muitos (M:N ou *..*) e um para um (1:1 ou 1..1).
Captulo 3
01. Conceitue adequadamente um atributo, e discorra sobre os seus principais tipos. Na sequncia, 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.
02. Conceitue um relacionamento e classifique os relacionamentos em relao ao
nmero de objetos envolvidos.
145
Modelagem de Dados
Sugesto de Resposta: Um relacionamento tem como propsito descrever um vnculo

(associao) entre uma ou vrias entidades. O grau de um relacionamento determinado
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).
03. 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?
Professor
(1,n)
possui
(0,n)
Aluno
Captulo 4
01. 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 possuir 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 chaveprimria 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.
02. Utilize suas prprias palavras para discorrer sobre os conceitos de Restrio de
Integridade de Entidade (RIE) e Restrio de Integridade Referencial (RIR). Cite
146
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
valor de chaveprimria de (t). J a restrio de integridade referencial, poder ser exemplificada 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
diferente de nulo apenas se existir uma tupla (t) na relao referenciada tal que a chaveprimria de (t) possuir o mesmo valor da chave-estrangeira de (t).
03. 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 desempenhado na empresa? Qual o nmero da matrcula e nome de cada
funcionrio? Quais so as possveis funes desempenhadas na empresa?
Funcionrio
(1,1)
possui
(1,n)
Funcionrio
(1,n)
participa
(0,n)
Projeto
(0,n)
desempenha
(1,n)
Funo
04. 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 cardinalidades a fim de atender as regras).
05. Quais caractersticas so desejveis para uma chave-candidata?
Sugesto de Resposta: 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 atributos da chave; (2) irredutibilidade: no existe um
subconjunto de atributos da chave que apresentem a caracterstica de unicidade.
147
Modelagem de Dados
Captulo 5
01. Conceitue adequadamente o processo de normalizao de dados. Cite suas principais formas
Sugesto de Resposta: O processo de normalizao tem como objetivo promover a reestruturao dos dados a fim de eliminar qualquer tipo de redundncia caracterizada como
indesejvel, ora presentes em alguns esquemas de banco de dados. Esse mesmo processo
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.
02. 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 ocorrncia dessa entidade (relao/tabela).
03. Apresente um exemplo de dependncia funcional transitiva.
Sugesto de Resposta: Uma dependncia funcional transitiva quando um atributo
(coluna) 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 entidade (relao/tabela), caracterizando o que chamamos de dependncia funcional
transitiva.
04. 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
148
Minhas anotaes:
149
Modelagem de Dados
Minhas anotaes:
150
Minhas anotaes:
151
Modelagem de Dados
Minhas anotaes:
152

Livro Proprietario - Modelagem de Dados

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Livro Proprietario - Modelagem de Dados

Uploaded by

Copyright:

Available Formats

Modelagem

UniSEB Editora Universidade Estcio de S

Captulo 1: Viso Geral: Banco de Dados

Captulo 3: Modelo Entidade-Relacionamento........................................................... 51

Viso Geral: Banco de

Previamente, antes de iniciarmos o estudo acerca da Modelagem de Dados, devemos constituir

Objetivos da sua aprendizagem

Voc j deve ter ouvido falar muito em bancos de dados em diversos

EAD-15- Modelagem de Dados Proibida a reproduo UniSEB

1.1 Viso geral: Banco de dados

publicado pela equipe da IBM, e, imediatamente, deu incio ao processo

Proibida a reproduo UniSEB

1.2 Dados versus informao

EAD-15- Modelagem de Dados Proibida a reproduo UniSEB

1.3 Classificando os bancos de dados

Banco de Dados Multiusurio: ao contrrio do banco de dados

Proibida a reproduo UniSEB

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

EAD-15- Modelagem de Dados Proibida a reproduo UniSEB

financeiros, monitoramento da produtividade, gesto de RH, etc.),

Proibida a reproduo UniSEB

1.4 Sistemas de Arquivos

Voc j se deparou com as siglas FAT, FAT32, NTFS? Algo familiar

EAD-15- Modelagem de Dados Proibida a reproduo UniSEB

A Figura 1.1 abaixo apresenta um exemplo do armazenamento de

Proibida a reproduo UniSEB

Figura 1.1 Esquema Simplificado do Sistema de Arquivos

rios sistemas de gerenciamento de banco de dados (SGBD), que utilizam

1.5 SGBD (Sistema de Gerenciamento de Banco

EAD-15- Modelagem de Dados Proibida a reproduo UniSEB

Figura 1.2 Esquema Simplificado do Sistema Gerenciador de Bancos de Dados

Proibida a reproduo UniSEB

Tais aplicativos, normalmente, so desenvolvidos por uma equipe

Maior velocidade em produzir acesso aos dados;

EAD-15- Modelagem de Dados Proibida a reproduo UniSEB

1.6 Os Usurios de Banco de Dados

Nesse tpico, evidenciaremos os principais tipos de usurio que

Proibida a reproduo UniSEB

aremos os quatro tipos de usurios, dando exemplos de suas principais

EAD-15- Modelagem de Dados Proibida a reproduo UniSEB

Usurios Avanados: so denominados de usurios avanados

Considerada como fundamentais, as atribuies de manuteno

Proibida a reproduo UniSEB

1.7 O SGBD e suas Funcionalidades

EAD-15- Modelagem de Dados Proibida a reproduo UniSEB

Dessa forma, essa arquitetura cliente/servidor foi introduzida aos

Cliente-Servidor: j nessa arquitetura, o cliente intitulado de

1.8 Vantagens do SGBD

Proibida a reproduo UniSEB

Vimos que os SGBDs basicamente funcionam como servidores de

EAD-15- Modelagem de Dados Proibida a reproduo UniSEB

Proibida a reproduo UniSEB

Centralizao dos Dados: um beneficio importante refere-se a

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

EAD-15- Modelagem de Dados Proibida a reproduo UniSEB

Atualmente a demanda por informaes, independentemente do

Proibida a reproduo UniSEB

SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de

HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4 ed. Instituto

EAD-15- Modelagem de Dados Proibida a reproduo UniSEB

Proibida a reproduo UniSEB

No captulo 1, aprendemos os conceitos

Objetivos da sua aprendizagem

Voc se lembra de nossa discusso no captulo 1 sobre o conceito de dado