Sei sulla pagina 1di 156

Seja Nosso Parceiro no Combate Cpia Ilegal

A cpia ilegal crime. Ao efetu-la, o infrator estar cometendo um grave erro, que
inibir a produo de obras literrias, prejudicando profissionais que sero atingidos
pelo crime praticado.

Felipe Nery Rodrigues Machado


Maurcio Pereira de Abreu

Junte-se a ns nesta corrente contra a pirataria. Diga no cpia ilegal.

Seu Cadastro muito Importante para Ns


Ao preencher e remeter a ficha de cadastro constante no final desta publicao, cuja
postagem ser paga pela Editora Erica, bastando deposit-la em qualquer caixa de
correio, voc passar a receber, automaticamente, informaes sobre nossos
lanamentos em sua rea de preferncia.
Conhecendo melhor nossos leitores e suas preferncias, vamos produzir ttulos que
atendam suas necessidades.
Obrigado pela sua escolha.

Fale Conosco!
Eventuais problemas referentes ao contedo deste livro sero encaminhados ao(s)
respectivo(s) autor(es) para esclarecimento, excetuando-se as dvidas que dizem
respeito a pacotes de softwares, as quais sugerimos que sejam encaminhadas aos
distribuidores e revendedores desses produtos, que esto habilitados a prestar todos os
esclarecimentos.

Ano: 2004 2003 2002


Edio: 13 12 11 10 9 8

Editora rica Ltda.

Os problemas s podem ser enviados por:


1. E-mail: producao@erica.com.br
2. Fax: (11) 217.4060
3. Carta: Rua So Gil, 159 - Tatuap - CEP 03401-030 - So Paulo - SP

Conselho Editorial:
Diretor Editorial: Diretor
Comercial: Diretor de
Publicidade: Editorao:
Desenhos:
Finalizao de Capa:
Reviso Gramatical:
Coordenao:

Antnio Marco V. Cipelli Paulo Roberto


Alves Waldir Joo Sandrini Rosana Ap.
Alves dos Santos Pedro Paulo Vieira
Herruzo Maurcio S. de Frana
Marlene Teresa Santin Alves Rosana
Arruda da Silva

Copyright 1996 da Editora rica Ltda.


Dados Internacionais de Catalogao na Publicao (CIP)
(Cmara Brasileira do Livro, SP, Brasil)
Machado, Felipe Nery Rodrigues
Projeto de Banco de Dados: uma viso prtica / Felipe Nery Rodrigues
Machado, Maurcio Pereira de Abreu. -- So Paulo : rica, 1996.
Bibliografia.
ISBN 85.7194.312-5
1. Banco de dados: I. Abreu, Maurcio Pereira de. - II. Ttulo
96.0014

CDD-005.75

i_ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ndices para catlogo sistemtico


1.

Biografia -

Felipe Nery Rodrigues Machado


Com formao em Engenharia Mecnica, possui larga experincia no projeto
de banco de dados utilizando DB2,MS-SQL,INFORMIX, SYBASE e ORACLE. Nos
seus trabalhos de consultoria, utiliza Metodologia de Desenvolvimento orientada a
dados, possuindo profundos conhecimentos sobre modelagem de dados. Realizou o
treinamento de mais de 1000 profissionais, principalmente no projeto de banco de
dados, utilizando a tcnica de modelagem de dados com o Diagrama EntidadeRelacionamcnto com foco de abstrao conceituai.

Banco de Dados: Sistemas: Processamento de dados 005.75

Todos os direitos reservados. Proibida a reproduo total ou parcial, por qualquer meio ou processo, especialmente
por sistemas grficos, microflmicos, fotogrficos, reprogrficos, fonogrficos, videogrficos, internet, e-books.
Vedada a memorizao e/ou recuperao total ou parcial em qualquer sistema de processamento de dados e a incluso
de qualquer parte da obra em qualquer programa jusciberntico. Essas proibies aplicam-se tambm s caractersticas
grficas da obra e sua editorao. A violao dos direitos autorais punvel como crime (art. 184 e pargrafos, do
Cdigo Penal, cf. Lei na 6.895, de 17.12.80) com pena de priso e multa, conjuntamente com busca e apreenso e
indenizaes diversas (artigos 102, 103 pargrafo nico, 104, 105. 106 e 107 itens 1, 2 e 3 da Lei n 9.610, de 19/06/98,
Lei dos Direitos Autorais).
Os Autores e a Editora acreditam que todas as informaes aqui apresentadas esto corretas e podem ser utilizadas
para qualquer fim legal. Entretanto, no existe qualquer garantia, explcita ou implcita, de que o uso de tais
informaes conduzir sempre ao resultado desejado. Os nomes de sites e empresas, porventura mencionados, foram
utilizados apenas para ilustrar os exemplos, no tendo vnculo algum com o livro, no garantindo a sua existncia nem
divulgao.
"Algumas imagens utilizadas neste livro foram obtidas a partir do CorelDRAW 7, 8 e 9 e da Coleo do MasterCIips/
MasterPhotos da MSI, 1985 Francisco Blud. East, San Rafael, CA 94901-5506,

Editora rica Ltda.


Rua So Gil, 159 - Tatuap
CEP: 03401-030 - So Paulo - SP
Fone: (11) 295-3066 - Fax: (11) 217-4060
Site: www.erica.com.br

Maurcio Pereira de Abreu


Engenheiro Eletricista com ps-graduao em Anlise de Sistemas pela PUCRJ. Atuou como professor da cadeira de Projeto de Estruturas de Dados do curso de
Anlise de Sistemas da PUC-RJ. Desenvolveu, junto a grandes empresas
(PETROBRS, ITAIPU Binacional, GLOBOSAT, etc.), projetos de consultoria
envolvendo a construo de banco de dados. Projetou c desenvolveu um prototipador
CLIPPER, baseado no Modelo E-R, para a ferramenta CASE Talisman. Desenvolveu
uma metodologia de desenvolvimento de sistemas para uma empresa nacional, lder no
mercado de banco de dados.

Prefcio
Desde a Antigidade, o homem tem procurado transmitir e documentar seu
conhecimento, objetos e fatos da vida real. Nas cavernas pr-histricas, foram encontrados
desenhos de animais, caadas c cenas do cotidiano. Por meio de smbolos que representavam
objetos e animais, os habitantes daquelas cavernas eternizavam a sua realidade. O homem
evoluiu. Sua tcnica de representar a realidade por intermdio de modelos tambm mudou.
O final do milnio nos surpreendeu com mudanas radicais em todos os nveis da
atividade humana. Numa quantidade e velocidade nunca antes experimentadas. A era da
informao no s j bateu nossa porta, como ocupa nosso escritrio, sala de aula e muitas
vezes reparte conosco nossa prpria sala de estar. Nem todos a perceberam, mas assim como a
revoluo industrial mudou o perfil da indstria mundial, a revoluo da informao est
modificando o perfil comportamental das pessoas e das organizaes. Nunca, como nos ltimos
anos, a viso do negcio esteve to prxima da viso do projeto dos sistemas de informao.
Com tudo isto, as tcnicas, mtodos c ferramentas de desenvolvimento de sistemas
aplicativos mudaram e evoluram de forma incrvel. A Metodologia da Engenharia da
Informao, por exemplo, trouxe-nos uma srie enorme de ferramentas para o desenvolvimento
eficaz de sistemas de informao, entre elas as tcnicas formais da modelagem de dados.
No passado, o processo era o centro de tudo nos projetos de desenvolvimento de
aplicativos. Estes eram os proprietrios dos dados. A modelagem de dados era ento
simplesmente uma atividade paralela, quase desconhecida e muitas vezes desprezada. Quando
utilizada, seu objetivo era meramente documentacional.
Com o reconhecimento de serem os dados um dos recursos mais importantes das
corporaes, ultrapassando as prprias fronteiras dos sistemas aplicativos, a modelagem de
dados se tornou, com justa razo, a mais importante tcnica utilizada na produo dos
resultados das fases de planejamento e anlise dos projetos de sistemas de informao.
Com o surgimento da Reengcnharia de Negcios e o advento do Business Process
Reengincering (BPR), volta-se a colocar nova nfase nos processos. Procura-sc agora um
balanceamento perfeito entre a anlise dos processos e dos

os envolvidos, ambos centrados porm, na viso do negcio em que a informao o


objetivo final. Neste contexto, a modelagem de dados passa a ter a importncia maior
ainda.
Os princpios bsicos da modelagem de dados so amplamente conhecidos, ensinados
e divulgados pelos mais diversos meios. Na vida real, tambm, muitas vezes nos
defrontamos com situaes inusitadas, desconhecidas e que nunca foram cobertas ou sequer
imaginadas nesses cursos e publicaes. Ns, 10 projetistas de sistemas de informaes,
precisamos ento acumular uma vasta experincia na rea para fazer frente a esses eventos,
ou procurar auxlio externo. E experincia o que no falta aos autores deste livro que, de
uma maneira clara, simples e agradvel, transporta-nos dos primeiros passos da arte de
modelar dados at suas ltimas conseqncias. Com uma srie de Estudos de sos, eles nos
transmitem toda a sua vivncia, apresentando solues para uma srie de situaes as quais
certamente, se voc ainda no enfrentou, mais cedo ou mais tarde ir encontrar.
O valor intrnseco desta obra, praticamente uma enciclopdia sobre Modelagem de
Dados, reside especialmente na vivncia desses dois projetistas de temas de informao,
que sem academicismos obscuros do ao assunto o trstamento que todos ns sempre
quisemos ver em uma publicao tcnica: reza e objetividade.

Lvio Augusto Taufer Diretor da

Sumrio

1-INTRODUO............................................................................................................ 01
1.1 - O Ciclo de Vida Tradicional ou em Cascata........................................................ 04
1.2 - O Ciclo de Vida da Anlise Estruturada .............................................................. OS
1.3 - O Ciclo de Vida da Engenharia de Software ....................................................... 07
1.4-0 Ciclo de Vida da Engenharia da Informao...................................................... 08
1.5 - Informao - Um Recurso Empresarial ............................................................... 12
1.6 - Uma Nova Ordem - Comear por Dados............................................................. 14
1.7 - Objetivos do Livro................................................................................................15

2 - O FUTURO ................................................................................................................ 17
2.1 - A Motivao..........................................................................................................17

RCMInformtica
3 - MODELAGEM CONCEITUAL ...............................................................................21
3.1-0 Projeto de Banco de Dados .................................................................................25
3.2 - O "Meta-Modelo" Entidade-Relacionamento (E-R).............................................27

4 - O MODELO ENTIDADE-RELACIONAMENTO..................................................29
4.1 - Modelagem Conceituai de Dados ........................................................................ 29
4.2 - Objetos Conceituais ............................................................................................. 29
4.3 - Entidades.............................................................................................................. 32
4.4 - Atributos .............................................................................................................. 35
4.5 - Enxergando Entidades.......................................................................................... 37
4.6 - Generalizao e Especializao ........................................................................... 40

5 - RELACIONAMENTOS ........................................................................................................... 45

10 - POR ONDE COMEAR?..................................................................................................... 121

5.1 - A Existncia .......................................................................................................................45

10.1 - Iniciando um Modelo .......................................................................................................122

5.2- Condicionalidade ................................................................................................................48


5.3 - Relacionamentos Condicionais.......................................................................................... 50
5.4 - Relacionamentos Incondicionais ....................................................................................... 50
5.5 -AViagem ................................................................................................ ,.......................... 51
5.6 - Grau do Relacionamento ................................................................................................... 54
5.7 - A Modelagem dos Relacionamentos ................................................................................. 59

11 - ESTUDOS DE CASOS ...........................................................................................................133


11.1 - Introduo........................................................................................................................133
11.2 - Estudo de Caso 1 .............................................................................................................134
11.3 - Estudo de Caso 2 .............................................................................................................146
11.4 - Estudo de Caso 3 .............................................................................................................151

6 - EFETIVAO LGICA DOS RELACIONAMENTOS.......................................................67


6.1 - A Expresso do Relacionamento....................................................................................... 67
6.2 - Quando os Fatos podem Confundir-nos ............................................................................ 69
6.3 - Valor Nulo......................................................................................................................... 73
6.4 - Como se Efetiva este Relacionamento?............................................................................. 76

12 - NORMALIZAO.................................................................................................................155
12.1 -Anomalias de Atualizao................................................................................................ 156
12.2 - Primeira Forma Normal (1FN)........................................................................................ 158
12.3 - Variao Temporal e a Necessidade de Histrico ........................................................... 161
12.4 - Dependncia Funcional ................................................................................................... 162
12.5 - Dependncia Funcional Total (Completa) e Parcial ........................................................ 162

7 - RELACIONAMENTOS ESPECIAIS ...................................................................................... 81

12.6 - Dependncia Funcional Transitiva .................................................................................. 163

7.1 - Relacionamentos entre Mltiplas Entidades.......................................................................81

12.7 - Segunda Forma Normal (2FN)........................................................................................ 163

7.2 - Relacionamentos Binrios de Um-para-Um.......................................................................87

12.8 - Terceira Forma Normal (3FN) ........................................................................................ 165

7.3 - Usar N:N ou Construir 2 vezes 1:N -A escolha..................................................................96

12.9 - Forma Normal de BOYCE/CODD (FNBC).................................................................... 167


12.10 - Quarta Forma Normal (4FN) ........................................................................................ 169

8-AGREGAO............................................................................................................................. 95

12.11 - Quinta Forma Normal (5FN) .........................................................................................171


12.12- Roteiro de Aplicao da Normalizao ...........................................................................175

8.1 -A Decomposio de um Relacionamento ...........................................................................95

12.13 - Desnormalizao ...........................................................................................................177

8.2 - Agregao e Cardinalidade ................................................................................................100

12.14 - Consideraes Finais Sobre Normalizao....................................................................178

8.3 - Restries para Uso de Agregao.....................................................................................104


8.4 - Como Utilizar Agregao com Entidades Associativas .....................................................106

13 - O MODELO LGICO RELACIONAL ...............................................................................181

8.5 - Relacionamentos entre Blocos do Modelo......................................................................... 109


13.1 - Principais Vantagens da Abordagem Relacionai .............................................................182
13.2 - As 12 Regras de Codd ..................................................................................................... 183
9 - AUTO-RELACIONAMENTO..................................................................................................113
9.1 - Introduo.......................................................................................................................... 113
9.2 -Auto-Relacionamento Um-para-Muitos ............................................................................. 113

13.3 - Chaves e ndices.............................................................................................................. 184


13.4 - O Conceito de Chave no Modelo Relacionai................................................................... 184
13.5 - Regras de Integridade do Modelo Relacionai .................................................................. 186

9.3 - Auto-Relacionamento Muitos-para-Muitos ....................................................................... 116

13.6 - Caractersticas do Modelo Relacionai ............................................................................. 186

9.4 - Auto-Relacionamento e Papel em um Relacionamento..................................................... 118

13.7 - Derivao do Modelo E-R para o Modelo Relacionai ..................................................... 187

14 -SQL.........................................................................................................................195
14.1 - A Importncia da Linguagem SQL.................................................................... 195
14.2 - A Linguagem SQL............................................................................................. 196
14 3 -Vantagens e Desvantagens da Linguagem SQL................................................. 199
14.4 - O Exemplo ..........................................................................................................200
14.5 - Estudo de Caso 1 ................................................................................................277
14.6 - Estudo de Caso 2 ................................................................................................282

Introduo

14.7 - Estudo de Caso 3 ................................................................................................ 292

Temos observado ao longo dos nossos anos de experincia no


desenvolvimento de sistemas de informao, que existe uma grande dificuldade dos
analistas e programadores em entenderem a diferena entre INFORMAO e
DADO. Esta dificuldade traz, como conseqncia direta, problemas na especificao e
modelagem de um sistema.
A INFORMAO acrescenta algo ao conhecimento da realidade a ser
analisada. Por exemplo, a dosagem que um paciente precisa receber de um
determinado remdio, uma INFORMAO. Este conhecimento pode ser (ou no)
modelado (registrado).
O DADO uma representao, um registro de uma informao. Este DADO
pode ser registrado fisicamente atravs de um papel (receita mdica), um disco de
computador ou um impulso eltrico, etc. Este registro pode ser o originador de uma
srie de processos que influenciam na realidade observada (salvar a vida de um
paciente, tocar um alarme, etc).
O tratamento das INFORMAES d origem a vrios tipos de DADOS,
porm o DADO deve registrar apenas os aspectos realmente relevantes da
INFORMAO, ou seja, o endereo do fabricante do remdio no tem nenhum
interesse para um sistema de controle que mantm a vida dos pacientes em um CTI.
Podemos concluir ento, que em um sistema de informaes, esto contidas
todas as INFORMAES necessrias ao objetivo do sistema (manter a vida do
paciente). Os DADOS originados dessas INFORMAES sero processados pelo
sistema criado. Por definio, um computador no processa INFORMAES, mas
sim, DADOS.

Para que possamos chegar automao de uma realidade (CTI


computadorizado de um hospital), necessrio que possamos entender esta mesma
realidade. Fica evidente a impossibilidade de um analista ou programador conhecer
todas as possveis realidades que, ao longo de sua vida profissional aparecem para
serem modeladas e automatizadas. Na verdade, o desenvolvimento do conhecimento
humano, alm de exigir uma contnua especializao, acaba por provocar tambm
uma crescente necessidade de gente capacitada relacionar as partes com o todo:
"projetista de sistemas", o qual deve ter a capacidade de sintetizar complexidades.
Tendo em mente a natural "restrio" humana de manipular grandes
quantidades de informao ao mesmo tempo, foram criadas tcnicas para se modelar
os diversos problemas que existem. Estas tcnicas, juntas, formam m conjunto
conhecido como METODOLOGIA de produo de sistemas de informao.
A construo de sistemas pode ser encarada como a construo de um edifcio
(James Kowal [15]), a qual obedece a fases e procedimentos bem definidos. Na
figura 1.1, apresentada uma comparao entre a construo de sistemas e edifcios.

Construo de um
edifcio

Desenvolvimento de
sistemas

criatividade no projeto

criatividade na anlise e projeto

construo de modelos

construo dos modelos

introduo das ltimas alteraes

introduo dos ltimos ajustes

Construo de um
edifcio

Desenvolvimento de
sistemas

detalhamento do projeto em
vrios nveis

o projeto consiste de vrios


nveis de detalhamento

o projeto constitudo por


vrias partes

os modelos so constitudos de
vrias partes

minimizao da interface entre as


partes do projeto

minimizao da interface entre as


partes do projeto

pouca criatividade na
construo fsica

pouca criatividade durante a


programao

especialistas manipulam
diferentes partes do projeto

especialistas manipulam reas


especficas

aferio do progresso do projeto

gerentes de projeto avaliam a

variao dos materiais e


equipamentos

evoluo do desenvolvimento
variao do hardware e
software

componentes pr-moldados so
usados

reutilizao de cdigo para


aumentar a produtividade

Figura 1.1 (continuao)


vrias recurses so efetuadas at o
projeto final

vrias iteraes so efetuadas


durante os estgios de anlise e projeto

existncia de padres para


aferio da qualidade do projeto

existncia de padres e regras para


medio da qualidade do projeto

Figura 1.1

Uma METODOLOGIA estabelece um caminho nico no desenvolvimento de


sistemas novos ou na evoluo de sistemas j existentes. Ela introduz uma consistncia
ao longo do desenvolvimento de vrios projetos de sistemas, provendo uma lista de
todas as atividades a serem realizadas, estabelecendo pontos de checagem para
auditoria e controle do projeto.
Desde 1950, vrias metodologias esto sendo colocadas em prtica. Estas
metodologias definem o CICLO DE VIDA do desenvolvimento, no qual esto
mostradas as fases que compem o caminho a ser seguido pelos analistas e
programadores, at a produo do sistema de informaes na sua

verso operacional (figura 1.2). Cada fase pode ser vista como o refinamento da etapa
anterior.

Figura 12
A seguir, sero apresentadas algumas metodologias que so bastante utilizadas
no processo de desenvolvimento de sistemas de informao. Muitas delas j no
apresentam o mesmo vigor de utilizao de quando foram desenvolvidas, e
praticamente formam um conjunto evolutivo no processo de captar as reais
necessidades que um usurio possui em termos de automao de sua realidade.

1.1-0 Ciclo de Vida Tradicional ou em Cascata


Este ciclo de vida (figura 1.3) apresenta como principal caracterstica a baixa
interao dos usurios do sistema com o pessoal de desenvolvimento. Durante as
etapas de Levantamento e Anlise, o usurio tenta_passar para o analista tudo que sabe
sobre o problema e o que ele deseja para solucionar o mesmo. Aps a definio do
problema, criado um documento, contendo os requisitos do futuro sistema, que
ento congelado e utilizado durante todas as fases de desenvolvimento.

Figura 1.3
Neste ciclo de vida, no criado nenhum tipo de modelo, no so utilizadas
tcnicas de estruturao e quase no existe oportunidade para o usurio realizar
alguma alterao em pontos dos requisitos congelados. As atividades so realizadas
em seqncia e no existem retornos entre as atividades. Toda a documentao
produzida aps o trmino do projeto.
Fica evidente que os projetos realizados com este ciclo de vida se caracterizam
pela alta incidncia de manuteno, pois esto sujeitos a poucas alteraes durante o
desenvolvimento.

1.2 O Ciclo de Vida da Anlise Estruturada


O conceito de programao estruturada foi introduzido em 1962, atravs de
artigos escritos por E.W. Dijkstra [9] e C. Bohm/G. Jacopini [3]. Os dois ltimos
afirmavam que era possvel escrever qualquer programa utilizando os trs construtores
bsicos: seqncia, repetio e deciso. Eles afirmavam que utilizando estes
construtores, a programao se tornar-se-ia mais fcil de entender e manter.

A partir destas idias, no incio dos anos 70, foram surgindo os conceitos do
projeto estruturado (W. Stevens. - G. Myers - L. Constantine[21]), no qual se
organizavam as funes de um programa de forma hierrquica, sobre a qual esto
presentes dois conceitos fundamentais: Acoplamento - que retrata a comunicao
entre os mdulos do sistema, e Coeso - que fala a respeito das relaes internas dos
mdulos. O produto final s estaria em um nvel aceitvel de qualidade para ser
colocado em produo, quando possusse baixo acoplamento e alta coeso.
Mais tarde, Cris Gane e T. Sarson [12], Tom DeMarco [8] e Edward Yourdon
[24] publicaram livros descrevendo um mtodo estruturado de analisar sistemas.

1.3 - O Ciclo de Vida da Engenharia de Software


Durante os anos 70 com a utilizao da anlise estruturada, o desenvolvimento
de sistemas ganhou um impulso muito grande. Em decorrncia deste impulso, a
necessidade de novos sistemas cresceu rapidamente e com isso as manutenes
tambm comearam a ter um papel proeminente no ciclo de vida dos sistemas. Isto
tudo levou a um aumento natural do custo de desenvolvimento e manuteno.
Comeou ento a surgir uma preocupao maior relativa produtividade dos analistas
e programadores, com a qualidade dos produtos e com os aspectos de segurana de
programas.

Este ciclo de vida (figura 1.4) caracterizado pelo uso das tcnicas
estruturadas, incluindo as revises estruturadas. Muitas das atividades so realizadas
em paralelo, produzindo documentao nos vrios estgios do desenvolvimento.
Revises peridicas so realizadas para se detectar o mais cedo possvel problemas
que podem influenciar no produto final.
Neste ciclo de vida, o envolvimento do usurio bastante significativo. Sua
participao na maioria das revises traz novas sugestes e correes dos aspectos no
compatveis com suas necessidades.

Figura 1.5

Figura 1.4

Com base nestas preocupaes, foi criado o ciclo de vida da engenharia de


software (figura 1.5), o qual veio para preencher certas lacunas deixadas pelo ciclo de
vida da anlise estruturada. Na engenharia de software se busca uma maior disciplina
em termos de desenvolvimento de sistemas. Ela caracterizada pela forte orientao
por processos, pela determinao bem acentuada de cada fase, enfatiza a reutilizao
de cdigo de programa, prov revises e pontos de checagem bem determinados e
define mtricas

bem fundamentadas para o gerente realizar o controle da produtividade, a qualidade e


o custo do produto final. Algumas mtricas da engenharia de software foram
apresentadas por Bany Boehm [2] e por Arndt Von Staa [20].

Com estas observaes concluiu-se que os dados envolvidos em cada processo


eram extremamente estveis, se comparados com os processos. Esta estabilidade era
devido ao fato de que os dados s sofrem algum tipo de mudana no momento em que
o negcio tambm muda/evolui.

A engenharia de software fundamentada em sete fases: viabilidade,


anlise, projeto, implementao, teste do sistema, teste do usurio e
produo. Quando algum problema ocorre em uma das fases, retorna-se a fase
imediatamente anterior para se rever os passos que levaram ao desenvolvimento
daquela onde ocorreu o problema.

Atravs destas concluses, em 1981, Matt Flavin [11], James Martin e Clive
Finkelstein [17] introduziram o conceito de engenharia da informao. O princpio
fundamental baseava-se no fato de que o dado existe e descrito, independentemente
dos processos que podem utiliz-lo.

1.4 - O Ciclo de Vida da Engenharia da Informao

Como o centro desta metodologia o DADO, a idia principal levantar as


estruturas de dados que vo dar origem aos bancos de dados, provendo um fcil acesso
aos mesmos.

No decorrer de 20 anos de uso de tcnicas para o desenvolvimento de


sistemas, no qual a idia central era analisar com base nos processos atuais
apresentados no ambiente do usurio e nos propostos para se chegar ao sistema final,
comeou-se a notar que os processos dentro de uma empresa, corporao, repartio,
etc. eram fortemente influenciados pelo meio ambiente externo aos locais de utilizao
destes processos (figura 1.6).

Figura 1.7
A engenharia da informao (figura 1.7) um conjunto integrado de tcnicas
que organiza os dados de um determinado negcio e determina um acesso fcil, por
parte do usurio final, a estes dados. Esta metodologia pode ser detalhada nas
seguintes fases: planejamento estratgico das informaes, anlise da informao,
modelagem de dados, formao dos procedimentos,
Figura 1.6

anlise do uso dos dados, anlise da distribuio dos dados, projeto fsico da Base de
dados e especificao dos programas.

negcio, e principalmente, para controlar as informaes agora setorizadas e


especializadas. Existem, na empresa, atividades profissionais especficas tais
como: contador, comprador, almoxarife, etc.

O suporte desta metodologia est baseado na tcnica de modelagem de dados e


seus relacionamentos, desenvolvida inicialmente por Peter Chen [5] em 1976,
chegando modelagem da informao atravs de Flavin [11] em 1981, e finalmente
modelagem semntica dos dados atravs de Shlaer e Mellor [19] em 1988.

Este um primeiro instante da "departamentalizao" da empresa. Mas


o que nos interessa salientar que se observa uma grande dificuldade do ser
humano em lidar com grandes massas de informao. J no mais possvel,
ao proprietrio, manipular e ter o domnio completo das informaes de seu
negcio. Isto caracteriza o que denominamos de aumento do domnio do
problema.

Devido ao crescimento natural dos negcios (Veja "O Armazm" -quadro


abaixo), das necessidades de informao e do aprimoramento dos sistemas de
gerenciamendo de banco de dados (SGBD), que passaram a ser cada vez mais
utilizados pelas empresas, a modelagem de dados passou a ser um fator fundamental
no desenvolvimento de sistemas de informao.

Neste instante, pode ser estratgico e crtico para o negcio a


necessidade de informatizao do supermercado.
Mas a questo : O que estamos procurando solucionar? Qual o
problema?
A resposta correta , e sempre ser, a necessidade de informao.

O Armazm
Para ilustrarmos melhor a evoluo das necessidades de informao,
vamos analisar o crescimento das empresas no pas. A grande maioria das
empresas nacionais teve seu incio de atividade caracterizado por um negcio
de pequeno porte. Para ilustrar essa figura tpica, poderamos utilizar a imagem
de uma pequena quitanda, um armazm de bairro. Ali o proprietrio (um
"futuro" grande empresrio) administra seu negcio junto com seus familiares.
Observa-se que existe um domnio completo sobre o negcio e sobre suas
informaes. O proprietrio obtm dados rapidamente sobre seus estoques,
simplesmente olhando para os seus itens nas prateleiras. Conhece pessoalmente
seus clientes, normalmente pessoas do bairro, permitindo que comprem a
crdito atravs de um caderno de "pinduras" por cliente, e tambm conhece seus
fornecedores pessoalmente. O controle do fluxo de caixa resume a simples
operaes de pagar, receber e sobrar, diretamente na caixa registradora. Existe
ento a informao completamente acessvel, disponvel e de qualidade
suficiente para o negcio.
Mas como este um pas de iniciativas (??? mesmo???), o bom
atendimento prestado pelo proprietrio do armazm faz com que a clientela
aumente, solicite produtos melhores, mais variedade e quantidade, alm de
formas de pagamento diferenciadas, etc, e o negcio vai crescendo, at que
encontramos o velho armazm transformado em um supermercado.
Com o crescimento, o volume de informaes cresce de forma quase
que exponencial, qualifica-se e especializa-se. O proprietrio daquele antigo
armazm, agora um promissor supermercado, conta com profissionais
especializados que o auxiliam no atendimento de atividades especficas, tanto
junto aos clientes quanto no controle do

Os Dados
O desenvolvimento de aplicaes computadorizadas, orientadas pelas
necessidades setoriais de cada rea, utilizando equipamentos e software
variados no ir resolver o problema, mas paliativa mente passar a sensao de
que as coisas esto andando rapidamente, e que todos tm controle sobre suas
situaes e necessidades. Mas e qual a realidade afinal?
Em toda e qualquer empresa que se analise, constataremos que as
informaes se interligam constantemente, no permanecendo isoladas e
estanques em um determinado setor de uma empresa. Logo, dados que so
gerados por Vendas, so necessrios a Compras, para que esta disponibilize a
entrega das vendas, estabelea os pontos de ressuprimento dos produtos
considerando e calculando o giro de estoque. Da mesma forma os dados de
Compras interessam para o Financeiro, j que devemos providenciar uma
previso de desembolso. Os dados de Compras so importantes para Vendas
para estabelecimento de preos. Poderamos continuar todo este livro fazendo
ligaes entre departamentos, mas no este o objetivo. O que queremos
salientar a importncia das informaes no negcio da empresa, e que elas no
produzem resultados se isoladas em rgos.
Existe a clara necessidade de interligao de todas as informaes, para
que se venha a obter uma viso corporativa do negcio, e que seja explcita o
suficiente para nos mostrar a empresa como ela realmente .
Um sistema de informaes realizado de forma estanque e
departamentalizada, vai ter como caracterstica um fluxo de dados
extremamente complexo entre os departamentos, mas no representando uma
realidade clara e lmpida do negcio.

alta, e que o nvel de qualidade ser provavelmente baixo. Destacamos que no existiu
um trabalho de busca das informaes, logo no se buscou o conhecimento do
problema e sim uma soluo para algo momentneo e provavelmente passageiro.

1.6 - Uma Nova Ordem - Comear por Dados


O que pretendemos ao lanarmos este trabalho, apresentar um enfoque
metodolgico baseado inteiramente na definio e modelagem dos dados da
organizao, para a construo dos sistemas de aplicao, e que possuam em primeiro
lugar, qualidade e confiabilidade de informaes. Para isto vamos orientar nossos
trabalhos de anlise no levantamento e definio do aspecto fundamental de um
sistema, seus dados.
Os dados no possuem caractersticas to volteis que sua existncia assuma
caracterizao temporal acentuada, pois nos refletem no um momento a ser
modificado, mas sim uma realidade a ser automatizada.
A modelagem de dados (ou de informaes) est baseada no princpio de que,
comprovadamente, os dados so estveis no decorrer da vida de uma empresa ou
organizao, no tendo volatilidade dependente de fatores pessoais, governamentais e
temporais. J os procedimentos possuem esta caracterstica de volatilidade, pois
sofrem constantes alteraes, seja por fatores pessoais, quando existe troca de pessoas
e mtodos, por decises governamentais e legislativas, por fatores de calamidade, e
outros, externos s atividades normais da empresa.
Para que uma empresa mude seus dados, torna-se necessrio que a mesma
mude sua atividade-fim, por exemplo: em uma indstria metalrgica, seus dados
somente iro mudar quando a mesma se transformar em uma empresa agrcola ou
fechar e abrir como ferro-velho.
Logo podemos concluir que os dados, na realidade, so imutveis durante o
ciclo de vida de uma empresa, mudando somente os valores presentes nos dados, mas
no o conceito do dado em si.
Quando passamos a adotar uma metodologia baseada em modelo de dados,
com trabalhos iniciais e extensos de modelagem, conseguimos obter um domnio do
negcio da empresa, temos uma fotografia global da mesma.

Mas isto nos d algum ganho no processo de desenvolvimento? Se


considerarmos que os ganhos do processo de desenvolvimento so uma relao direta
entre tempo, qualidade e custo, torna-se bvio que a anlise de um sistema com
tcnicas que permitam conhecimento perfeito e compreenso ampla do negcio em um
espao de tempo reduzido, nos permitir desenvolver e obter qualidade na aplicao,
principalmente sobre a informao, e conseqentemente um retorno positivo na
relao de custo x benefcio para o projeto de desenvolvimento do sistema de
informaes.

1.7 - Objetivos do Livro


A finalidade deste livro apresentar de forma didtica e prtica o
desenvolvimento da modelagem de dados. Sero abordados aspectos lgicos e fsicos,
mostrados atravs de exemplos desenvolvidos em SQL-ORACLE .
Como vimos no incio deste captulo, existem vrias abordagens (ciclos de
vida) para o desenvolvimento de sistemas de informao. Neste livro, estaremos
preocupados em construir bases de dados que atendam s reais necessidades de
informao de um determinado ambiente.
A construo de bases de dados pode ser dividida em trs fases bem distintas:
modelagem conceituai, projeto lgico e projeto fsico, que podem estar presentes em
qualquer ciclo de vida e foram desenvolvidas no final dos anos 70.
Iremos, ao longo dos captulos, detalhar a construo do Modelo Conceituai, o
qual apresenta as necessidades de informao captadas. Nesta fase, so registrados os
fatos que ocorrem na realidade e que de certa forma influenciam no funcionamento da
mesma.
O projeto de um banco de dados um processo complexo e que geralmente
necessita de muitas decises em diferentes nveis. Esta Conplexidade melhor
gerenciada quando o problema subdividido em vrios subproblemas independentes
("dividir para conquistar"). O fato central nas trs fases do projeto de bases de dados
a modelagem do dado e suas Propriedades.

Vocs, leitores, devem estar achando no mnimo estranho, o captulo 2 falar


sobre O Futuro. Normalmente, um tema como este s aparece no fim do livro. Ns
sentimos que ser muito importante voc saber que aquilo que o espera no futuro tem
como base os ensinamentos presentes nos prximos captulos. Esta percepo lhes
dar mais motivao para estudar de forma profunda e consciente.

2.1 - A Motivao
Todos j devem ter notado na introduo, que a grande preocupao em
qualquer levantamento feito com o domnio do problema e as responsabilidades do
sistema. Durante muitos anos o desenvolvimento de sistemas de informao era
dividido entre o levantamento dos processos (prioridade) e o levantamento dos dados.
Esta forma de anlise trouxe inmeros problemas para o usurio, pois o mesmo no
via o produto como uma soluo para suas necessidades.
Como vimos no captulo 1, trabalhar com os dados foi um fator vantajoso no
desenvolvimento de sistemas de informao. Mesmo com a Modelagem da
informao mapeando diretamente o domnio do problema
ainda havia a necessidade de um detalhamento maior. Os cientistas [25] d de
Sistema de Informao comearam ento a juntar dados e processos
Em um nico elemento. Esta unio deu origem ao conceito de modelagem
orientada a objetos (OO), a qual passou a fornecer um elo de fixao mais mais
estvel entre o mundo real e o sistemas de informao. Podemos dizer que
OO um novo pensamento sobre os problemas, organizando modelos cada
vez mais prximos dos conceitos do mundo real.

O Futuro

As tcnicas de orientao a objetos apresentam vrios benefcios:


1 - Utilizam um conceito mais especializado de detalhamento da
realidade (herana);
2 - Trabalham com o conceito de reutilizao, que permite uma maior
produtividade;
3 - Aumentam a consistncia dos resultados da anlise;
4 - Produzem uma melhor ligao entre o analista e o usurio;
5 - Suportam melhor alteraes na realidade;
6 - Podem enfrentar, de forma mais direta, domnios mais complexos
na realidade;
7 - Possuem uma maior continuidade em todas as fases do ciclo de
vida do projeto.
Esta nova forma de explorao da realidade utiliza, diretamente, os princpios
bsicos da administrao da complexidade enunciados por Coad e Yourdon [25]:
1 - abstrao (dados e procedimentos): foco no essencial;
2 - encapsulamento (information hiding): invisibilidade dos aspectos
internos de um objeto, quando observado por outro objeto;
3 - herana: objetos podem herdar caractersticas (dados e processos)
de outros objetos;
4 - comunicao entre os objetos atravs de mensagens;
5 - polimorfismo: caractersticas diferentes para um mesmo objeto ao
mesmo tempo;
6 - mtodos de organizao (objetos e atributos, todo e partes, classes
e membros com distino entre eles);
Basicamente, a modelagem da informao atende aos princpios 1 e 6, porm
com relao aos demais deixa muito a desejar.
Os sistemas elaborados hoje em dia, so diferentes dos que eram
desenvolvidos h dez ou vinte anos. So maiores, mais complexos, mais volteis e
sofrem alteraes constantes. E principalmente, hoje se d uma grande nfase
interface homem-mquina, a qual se tornou bastante

poderosa e complexa, levando a ter um papel preponderante no cdigo final


(aproximadamente 75%).
A OO nasceu com a finalidade de dar maior poder de produtividade e
aumentar a qualidade dos produtos desenvolvidos.
Mesmo com a entrada firme da modelagem de dados na maioria das empresas,
j se fala em anlise, projeto e programao orientada a objetos. A modelagem
orientada a objetos tem seu fundamento na modelagem da informao. Este livro tem
como preocupao central apresentar a tcnica de modelagem de dados. Quanto ao
futuro (orientao a objetos), ser tema para um outro encontro entre vocs, leitores, e
ns, autores. Enquanto este novo encontro no acontece, fiquem com a base de toda
esta nova tecnologia. Mos obra.

Modelagem
Conceitual

Toda a realidade sempre, em princpio, bastante nebulosa e informal. Atravs


da observao podemos extrair dela (realidade) fatos que nos levam a conhec-la de
uma forma mais organizada.
Em um negcio, existem fatos que, observados e modelados, dizem algo a
respeito do funcionamento deste negcio. Estes fatos esto ligados diretamente ao
funcionamento da realidade, os quais temos grande interesse em compreender e
manter.
Para que possamos retratar estes fatos e que os mesmos possam nos levar a
futuras decises e aes, se faz necessrio ento registr-los. Este registro feito
atravs da criao de um modelo.
E evidente que os fatos ocorrem a todo instante dentro de uma realidade,
geralmente ficam registrados em documentos formais, tais como: fichas, memorandos,
requerimentos, leis, protocolos, decretos e na maioria dos casos, esto registrados na
cabea das pessoas que de forma direta ou indireta influenciam na realidade a ser
modelada. Normalmente, na criao e utilizao desses documentos no h nenhuma
preocupao em se utilizar, no futuro, um ambiente automatizado.
O analista, durante a modelagem conceituai dos dados, deve se concentrar na
observao dos fatos relevantes que ocorrem na realidade, com finalidade de construir
um sistema que possa automatizar as necessidades de informao da mesma. Neste
momento, os documentos que registram estes fatos s devem ser utilizados como
apoio ao entendimento, e no como base Para o desenvolvimento do sistema de
informaes, ou seja, no devemos ter a preocupao em simular o ambiente atual,
seja ele manual ou automatizado.

A preocupao que o analista deve ter : retratar as necessidades de


informao que as pessoas (que agem sobre esta realidade) precisam para alcanar os
objetivos desta mesma realidade.
Ao coletar e selecionar os fatos relevantes, o analista deve identificar os elementos
geradores de informao, as leis que regem esta realidade, bem como as operaes
que incidem sobre os elementos bsicos (dados).
O que se quer criar uma abstrao (figura 3.1) da realidade, que seja capaz
de registrar os acontecimentos da mesma, de tal forma que se possa implementar um
sistema automatizado que atenda as reais necessidades de informao
Para registrarmos as necessidades de informao de uma realidade, precisamos
fazer uso de um modelo, ou seja, algo que nos mostre como as informaes esto
relacionadas (fatos). E com base no modelo criado, os analistas podem interagir com
os usurios validando seus objetivos e metas, permitindo a construo de um sistema
de informaes cada vez mais prximo da realidade do usurio.

Descrio dos elementos da abstrao:


- Minimundo: Poro da realidade, captada pelo analista, a qual a funo gerencial tem
forte interesse em observar. A complexidade de se analisar at mesmo um minimundo,
pode levar o analista a subdividi-lo em partes menores, s quais damos o nome de
viso.
. Banco de Dados: uma coleo de fatos registrados que refletem o estado de certos
aspectos de interesse do mundo real. A todo o momento o contedo do banco de dados
representa uma viso instantnea do estado do mundo real. Cada mudana em algum
item do banco de dados reflete uma mudana ocorrida na realidade.

A tecnologia de banco de dados tem como fundamento bsico permitir que os


dados possam ser definidos e mantidos, independente dos sistemas de aplicao que
venham a utiliz-los (independncia DADO x PROCESSO).

- Modelo Conceituai:

Representa e/ou descreve a realidade do ambiente do


problema, constituindo-se em uma viso global dos principais dados e
relacionamentos (estruturas de informao), independente das restries de
implementao
Quando se fala em Modelo Conceituai, estamos nos referindo a primeira etapa
do projeto de um sistema de aplicao em banco de dados.

Figura 3.1 - Nveis de Abstrao.

CRIA

O objetivo do Modelo Conceituai descrever as informaes contidas em uma


realidade, as quais iro estar armazenadas em um banco de dados. uma descrio em
alto nvel (macrodefinio), mas que tem a preocupao de captar e retratar toda a
realidade de uma organizao, setor, repartio, departamento, etc.

. Modelo FSICO: O Modelo Fsico ir partir do Modelo Lgico e descreve as


estruturas fsicas de armazenamento de dados, tais como: tamanho de campos, ndices,
tipo de preenchimento destes campos, nomenclaturas, etc, projetadas de acordo com
os requisitos de processamento e uso mais econmico dos recursos computacionais.
Este modelo detalha o estudo dos mtodos de acesso do SGBD, para elaborao dos
ndices de cada informao colocada nos Modelos Conceituai e Lgico.
O Modelo Conceituai no retrata os aspectos ligados abordagem do banco de
dados que ser utilizado e to pouco se preocupa com as formas de acesso ou
estruturas fsicas implementadas por um SGBD especfico.
O resultado de um Modelo Conceituai um esquema que representa a
realidade das informaes existentes, assim como as estruturas de dados que
representam estas informaes.
O Modelo Conceituai no construdo com consideraes procedurais, no
existindo preocupao com as operaes de manipulao/manuteno dos dados. na
fase de modelagem conceituai que iremos executar os trabalhos de construo de um
modelo de dados.
- Modelo Lgico: O Modelo Lgico tem seu incio a partir do Modelo Conceituai,
levando em considerao uma das trs abordagens atualmente possveis: Relacionai,
Hierrquica e Rede.

Esta a etapa final do projeto de Banco de Dados, na qual ser utilizada a


Linguagem de Definio de Dados do SGBD (DDL), para a realizao da montagem
do mesmo no nvel do Dicionrio de Dados.

3.1- O Projeto de Banco de Dados


Todo o projeto de um sistema de aplicao para banco de dados necessita de
um corao, um centro nervoso do mesmo. A modelagem de um sistema atravs da
abordagem Entidade Relacionamento representa este Ponto central no Projeto
Conceituai de um Sistema.

ABORDAGENS
HIERRQUICA

O Modelo Lgico descreve as estruturas que estaro contidas no banco de


dados, de acordo com as possibilidades permitidas pela abordagem, mas sem
considerar, ainda, nenhuma caracterstica especfica de um Sistema Gerenciador de
Banco de Dados (SGBD), resultando em um esquema lgico de dados sob a tica de
uma das abordagens citadas.

O objetivo da Modelagem de Dados transmitir e apresentar uma


representao nica, no redundante e resumida, dos dados de uma aplicao. Em
projetos conceituais de aplicaes em banco de dados o modelo EntidadeRelacionamento o mais largamente utilizado para a representao e entendimento
dos dados que compem a essncia de um sistema.
O Projeto de Banco de Dados para sistemas de aplicao hoje no mais uma
tarefa realizada somente por profissionais da rea de informtica, n^as tambm
possvel de ser realizada por no especialistas, atravs de tcnicas estruturadas como a
Modelagem Conceituai de Dados.

O projeto de um sistema de informaes uma atividade complexa que inclui


planejamento, especificaes e desenvolvimento de vrios imponentes.
O que se prope situar a seqncia destas atividades em uma ordem que
possa resultar em ganhos de produtividade e confiabilidade dos sistemas
desenvolvidos, eliminado-se sensivelmente as falhas de sistema aps sua inplantao.
Desafortunadamente as metodologias de projeto de banco de dados, ara
sistemas de aplicao, no so ainda muito populares entre a comunidade tcnica,
sendo que vrias organizaes e profissionais se utilizam e pequenas tcnicas
pessoais, ou ainda pior, de uma inexistncia completa de metodologia para estes
projetos, sendo isto uma das maiores causas de falhas nos sistemas de informao
desenvolvidos.
A utilizao de uma abordagem correta de metodologia orientada a banco de
dados envolve a estruturao nos trs nveis de viso de dados vistos anteriormente,
ou seja, trs etapas na execuo de um projeto conceitual, lgico e fsico.

Isola-se desta forma a realidade a ser retratada em dados de suas implicaes


lgicas e fsicas, determinando-se o momento para adequao do modelo a estes
fatores.
E evidente e bvio que a realidade dos negcios de uma empresa sempre
diferente da realidade de outra empresa, mesmo que falem de ambientes similares.
Existem particularidades que s dizem respeito ao funcionamento daquele ambiente
especfico.
Devido a esta no similaridade entre ambientes de mesma natureza, ser
sempre necessria a criao de um modelo especfico para cada nova realidade
observada. Fica bem claro ento, a necessidade de termos um modelo que nos permita
construir vrios outros modelos, o qual chamado de "meta-modelo".

O "meta-modelo" a ser utilizado deve ter a caracterstica de poder modelar


qualquer realidade, ter uma forma de trabalho bastante simples e deve ter
caractersticas grficas que sejam bastante simples de construir e entender. O "metamodelo" que iremos utilizar neste livro ser o Entidade-Relacionamento (E-R).

3.2 - O "META-MODELO" Entidade-Relacionamento (E-R)


O modelo Entidade-Relacionamento foi definido por Peter Chen em 1976, e
teve como base a teoria relacionai criada por E. F. Codd (1970).
Ao longo dos anos, vrios estudiosos (Theorey, Fry, James Martin entre
outros) evoluram e expandiram este "meta-modelo". No prximo captulo, iremos
apresentar uma viso bastante moderna a respeito dele.
Segundo Chen, a viso de uma dada realidade, baseia-se no relacionamento
entre entidades, os quais retratam os fatos que governam esta mesma realidade, e que
cada um (entidade ou relacionamento) pode possuir atributos (qualificadores desta
realidade).
Grande parte das extenses ao "meta-modelo" baseiam-se em alguns
mecanismos de abstrao: classificao, generalizao e agregao. O conceito de
abstrao permite ao analista separar da realidade em estudo, as partes que so
realmente relevantes para o desenvolvimento do sistema de informaes e excluir da
modelagem todos os aspectos que no exercem influncia sobre o ambiente a ser
modelado.
Os conceitos do modelo E-R destinam-se prioritariamente ao projeto de banco
de dados, mas podem ser utilizados para o entendimento de um determinado negcio
(modelo do negcio) bem como auxiliar o desenvolvimento de estruturas de dados que
possam ser implementadas fora de um ambiente de banco de dados, utilizando-se uma
linguagem de Programao (COBOL, C, PASCAL, etc). O modelo E-R , atualmente,
a base para o desenvolvimento de sistemas orientados a objetos.
No prximo capitulo, vocs tero a oportunidade de ter contato com este
Modelo e observar a sua facilidade de uso e sua alta legibilidade.
O objetivo da modelagem de dados possibilitar a apresentao de uma viso
nica, no redundante e resumida dos dados de uma aplicao. No desenvolvimento
de aplicaes em banco de dados, o modelo Entidade-

O projeto de um sistema de informaes uma atividade complexa que inclui


planejamento, especificaes e desenvolvimento de vrios componentesO que se prope situar a seqncia destas atividades em uma ordem me
possa resultar em ganhos de produtividade e confiabilidade dos sistemas
diesenvolvidos, eliminado-se sensivelmente as falhas de sistema aps sua
implantao.
Desafortunadamente as metodologias de projeto de banco de dados, para
sistemas de aplicao, no so ainda muito populares entre a comunidade tcnica,
sendo que vrias organizaes e profissionais se utilizam de pequenas tcnicas
pessoais, ou ainda pior, de uma inexistncia completa de metodologia para estes
projetos, sendo isto uma das maiores causas de falhas nos sistemas de informao
desenvolvidos.
A utilizao de uma abordagem correta de metodologia orientada a banco de
dados envolve a estruturao nos trs nveis de viso de dados vistos anteriormente,
ou seja, trs etapas na execuo de um projeto :conceitua, lgico e fsico.

Isola-se desta forma a realidade a ser retratada em dados de suas implicaes


lgicas e fsicas, determinando-se o momento para adequao do modelo a estes
fatores.
evidente e bvio que a realidade dos negcios de uma empresa sempre
diferente da realidade de outra empresa, mesmo que falem de ambientes similares.
Existem particularidades que s dizem respeito ao funcionamento daquele ambiente
especfico.
Devido a esta no similaridade entre ambientes de mesma natureza, ser
sempre necessria a criao de um modelo especfico para cada nova realidade
observada. Fica bem claro ento, a necessidade de termos um modelo que nos permita
construir vrios outros modelos, o qual chamado de "meta-modelo".

O "meta-modelo" a ser utilizado deve ter a caracterstica de poder modelar


qualquer realidade, ter uma forma de trabalho bastante simples e deve ter
caractersticas grficas que sejam bastante simples de construir e entender. O "metamodelo" que iremos utilizar neste livro ser o EntidadeRelacionamento (E-R).

3.2-O "META-MODELO" Entidade-Relacionamento (E-R)


O modelo Entidade-Relacionamento foi definido por Peter Chen em 1976, e
teve como base a teoria relacionai criada por E. F. Codd (1970).
Ao longo dos anos, vrios estudiosos (Theorey, Fry, James Martin entre
outros) evoluram e expandiram este "meta-modelo". No prximo captulo, iremos
apresentar uma viso bastante moderna a respeito dele.
Segundo Chen, a viso de uma dada realidade, baseia-se no relacionamento
entre entidades, os quais retratam os fatos que governam esta mesma realidade, e que
cada um (entidade ou relacionamento) pode possuir atributos (qualificadores desta
realidade).
Grande parte das extenses ao "meta-modelo" baseiam-se em alguns
mecanismos de abstrao: classificao, generalizao e agregao. O conceito de
abstrao permite ao analista separar da realidade em estudo, as partes que so
realmente relevantes para o desenvolvimento do sistema de informaes e excluir da
modelagem todos os aspectos que no exercem influncia sobre o ambiente a ser
modelado.
Os conceitos do modelo E-R destinam-se prioritariamente ao projeto de banco
de dados, mas podem ser utilizados para o entendimento de um determinado negcio
(modelo do negcio) bem como auxiliar o desenvolvimento de estruturas de dados que
possam ser implementadas fora de um ambiente de banco de dados, utilizando-se uma
linguagem de Programao (COBOL, C, PASCAL, etc). O modelo E-R , atualmente,
a base para_o desenvolvimento de sistemas orientados a objetos.
No prximo capitulo, vocs tero a oportunidade de ter contato com este
modelo e observar a sua facilidade de uso e sua alta legibilidade.
O objetivo da modelagem de dados possibilitar a apresentao de urna viso
nica, no redundante e resumida dos dados de uma aplicao. No desenvolvimento
de aplicaes em banco de dados, o modelo Entidade-

Relacionamento (E-R) o mais largamente utilizado para a representao e


entendimento dos dados que compem a essncia de um sistema de informaes.

O Modelo EntidadeRelacionamento

4.1 - Modelagem Conceituai de Dados


Ao se utilizar a Modelagem Conceituai de Dados com a tcnica de Entidades e
Relacionamentos, obteremos resultados e esquemas puramente conceituais sobre a
essncia de um sistema, ou melhor sobre o negcio para o qual estamos
desenvolvendo um projeto, no representando-se procedimentos ou fluxo de dados
existentes.
A modelagem como a arte fotogrfica, prepara-se a cmera e tira-se a foto,
sem se importar com os movimentos. Entretanto, o esquema produzido pelo trabalho
de modelagem de dados nos possibilita a visualizao das atividades e procedimentos
que podero ser exercidos sobre estas estruturas de dados.

4.2 - Objetos Conceituais


As literaturas existentes nunca deixam claro como podemos entender
entidades e relacionamentos. Uma vez que a maioria dos profissionais de anlise de
sistemas tem sua cultura baseada em sistemas procedurais, onde os dados so o
resultado e no o meio, existe a necessidade de que se coloque mais enfoque didtico
no detalhamento do que so efetivamente entidades e relacionamentos.
As tcnicas estruturadas mais avanadas, que neste pas alcanaram
divulgao profissional a nvel prtico, baseiam-se na anlise dos Procedimentos, e
com enfoque principalmente direcionado para o Diagrama
29

de Fluxo de Dados. Estas tcnicas estruturadas colocam as informaes derivadas dos


procedimentos em Depsitos de Dados, os quais finalmente acabam sendo traduzidos
em arquivos de um sistema.
Para que se efetue ento a migrao desta base cultural, torna-se necessrio
que a regra bsica - procedimentos no nos interessam - seja atendida nesta
abordagem de levantamento.
Vamos estabelecer como preocupao somente a necessidade de retratarmos
as informaes existentes no negcio. Nosso objetivo primordial entendermos o
negcio, para o qual projetaremos um sistema, atravs de seus dados.
Quando escrevemos Objetos Conceituais, no estamos pretendendo nos
inserir na Orientao a Objetos. Apesar de a modelagem conceituai de dados ser a base
para o entendimento desta nova abordagem tecnolgica, o nosso objetivo na
realidade ir at as razes da conceituao de modelo Entidade-Relacionamento (figura
4.1).

figura 4.1 - Um Modelo E-R.

Quando Peter Chen formulou a proposta do modelo Entidade-Relacionamento,


baseou-se no na viso de um sistema de aplicao como princpio e sim na
compreenso da realidade em que se situava o problema. Como iremos projetar um
sistema se no entendemos o negcio para o qual ser realizado?

Se alguma "coisa" (figura 4.3), existente no negcio nos proporciona


algumjnteresse em mantermos dados, (informaes armazenadas sqbre_glgj. isto a
caracteriza como uma Entidade do negcio.

Chen dedicou-se a destacar a importncia de reconhecer os objetos que


compem este negcio, independentemente de preocupar-se com formas de tratamento
das informaes, procedimentos, programas, etc. Estes objetos que desejamos
conhecer e modelar para um sistema, Chen classificou em dois grupos: Entidades e
Relacionamentos.

importante destacarmos aqui que uma entidade a representao de uma


Classe de dados do negcio, um conjunto de informaes de mesmas caractersticas, e
suas instncias (ocorrncias), so a representao destes dados.

Na figura 4.2, apresentado um fato comum que pode acontecer em qualquer


realidade. Este fato deve ser retratado atravs de elementos bsicos que compem o
modelo Entidade-Relacionamento.

Esta entidade ser ento um conjunto de dados em nosso modelo conceituai.

Quando falamos sobre Classe de Dados, estamos na realidade trabalhando


mentalmente um nvel macro de informaes, estamos atuando com abstraes
interpretadas de acordo com o meio em que nos localizamos e seus interesses e
objetivos organizacionais.

Figura 43
Figura 42

4.3 - Entidades
Define-se entidade como aquele objeto que existe no mundo real com uma
identificao distinta e com um significado prprio.
So as "coisas" que existem no negcio, ou ainda, descrevem o negcio em si.

Para traarmos um paralelo inicial com vistas a facilitar a viso do leitor e


situ-lo em relao ao seu ambiente cultural normal, diramos que a entidade
comparvel ao arquivo de dados e suas instncias so os registros deste arquivo. Mas
esta uma comparao que no de todo real, j que estamos projetando bancos de
dados, e logo tratando conjuntos de informaes.
A representao de uma Entidade no modelo EntidadeRelacionamento se
realiza atravs de um retngulo, com o nome desta entidade em seu interior, como na
figura 4.4.

O Modelo Entidade - Relacionamento

CLIENTE

PRODUTO

NOTA
FISCAL

FUNCIONRIO

ORDEM DE
PRODUO

Da mesma forma temos em um ambiente empresarial, diversos objetos


setoriais e corporativos que caracterizam-se como entidades, com um nmero
indeterminado de instncias, como veremos a seguir.
Mas antes vamos conhecer como descrevemos uma entidade, ou melhor, os
qualificadores (atributos) de uma entidade.

Figura 4.4 Entidades.

4.4 - Atributos

As instncias de uma entidade no so representadas no diagrama de


Entidades e Relacionamentos, mas so semanticamente interpretadas no mesmo.

Todo objeto para ser uma entidade possui propriedades que so descritas por
atributos e valores. Estes atributos e seus valores, juntos, descrevem as instncias de
uma entidade, formando o que no tpico anterior salientamos como registros em um
arquivo.

Devemos, ao visualizar uma entidade, entend-la como uma tabela de dados,


onde cada linha desta tabela representa uma instncia da mesma. Mas como vamos
detalhar mais este aspecto no tpico de atributos de uma entidade, fixemo-nos neste
ponto para compreendermos as "coisas" de um negcio.
Para que se possa absorver entidades devemos primordialmente nos orientar
pelo mundo real, onde acontecem as coisas, buscando obtermos domnio do problema,
enxerg-las sem a preocupao da construo de um sistema, sem imaginar programas,
e sim exclusivamente preocupados em retratar uma realidade, compreender um
negcio por seus dados.
Em nosso dia-a-dia, estamos frente a frente com diversas entidades, as quais
processamos, selecionando instncias que nos interessam.
Por exemplo, quando desejamos uma distrao relaxante nos fins de semana,
vamos at uma locadora de fitas de videocassete.
Vamos selecionar fitas para assistirmos em casa. Neste momento, estamos
consultando a entidade "Filme" da locadora, que possui vrias instncias, ou seja, so
as fitas disponveis na locadora.
Quando desejamos obter o telefone de alguma pessoa, ou empresa,
consultamos a entidade "lista telefnica oficial", que possui milhares de instncias de
telefones.
Em uma viagem de frias, utilizamos instncias da entidade "mala", pois
selecionamos algumas das nossas malas disponveis para o tipo de viagem, quantidade
de roupas, clima, etc.

34

Entidade: Funcionrio
Matrcula Nome

Data de Admisso

4456

Joo Carlos Silva

29/04/91

6689

Silvia de Oliveira

30/02/92

1203

Carla Martinez

14/04/92

7702

Pedro Guilherme Souza

01/01/92

Figura 4.5 - Entidade Funcionrio.


Vamos considerar que em uma empresa, temos uma entidade, um objeto sobre
o qual desejamos manter informaes armazenadas, chamado Funcionrio.
O que descreve Funcionrio?
Funcionrio descrito por um nmero de matrcula, um nome deste
funcionrio, sua data de admisso, como representado na tabela da figura 4.5, mas
poderamos ainda descrev-lo com mais dados, tais como data de nascimento, valor de
seu salrio, etc. Estes dados que caracterizam o objeto funcionrio so os atributos
inerentes entidade Funcionrio.
Cada instncia de Funcionrio, cada existncia de um objeto da Classe
Funcionrio, ser formada por valores nestes atributos, sendo que o
35

conjunto destes valores representados que devemos visualizar como uma linha de uma
tabela de dados.
Os valores de determinados atributos ou de um determinado atributo, nas
ocorrncias desta entidade, so sempre diferentes para cada instncia, caracterizando
que no existem objetos repetidos dentro de uma classe de objetos, isto , dentro de
uma entidade.
Este(s) atributo(s) cujos valores nunca se repitem, sempre tem(tm) a funo
de atuar(em) como identificador(es) nico(s) das instncias da entidade. Dentro da
abordagem relacionai de banco de dados, denomina-se esta propriedade como Chave
Primria de uma tabela, conceito este que iremos utilizar dentro de nosso contexto.

Data de Admisso

Nome

4456

Joo Carlos da Silva

29/04/91

6689

Silvia de Oliveira

30/02/92

1203

Carla Martinez

14/04/92

7702

Pedro Guilherme Souza

01/01/92

Valores de chave primria de tabela:


4456

6689

1203

- Um valor nulo no deve ser visto de forma fsica, e sim de forma


conceituai, como no mundo real.
Por exemplo, se nos apresentarmos frente dos leitores com este livro,
em nossas mos, qual , neste instante, o valor do contedo do mesmo
para os leitores que visualizam este fato?
desconhecido, pois no o abriram , no leram, logo o valor de seu
contedo neste instante nulo. (PS: Se voc j leu at este captulo,
logo o valor do contedo j no mais nulo para voc, leitor, mesmo
que no tenha gostado do que encontrou!)
Colocam-se neste momento ento, as seguintes questes:

Entidade: Funcionrio
Matrcula

Como entender no mundo real um valor nulo?

7702

Chave primria ento o atributo (ou conjunto de atributos concatenados) que


identifica uma nica ocorrncia dentro de uma tabela.

- Em que instante modelamos entidades?


- Como devemos nos orientar para determinar as entidades?
- Como ter certeza de que algo uma entidade?

4.5 - Enxergando Entidades


Quando efetuamos uma atividade de levantamento de dados, estamos
efetivamente identificando entidades ou classes de dados. Num primeiro contato com
um negcio para o qual se efetuar um sistema de aplicao, podemos no possuir
conhecimento especializado no mesmo, logo devemos procurar conhecer seus objetos
principais.
A descrio dos objetos ou do objeto central do negcio ir nos apresentar a
realidade retratada em diversas entidades. Por exemplo:

Este conceito no foge de forma alguma ao que acontece no mundo real, j


que um objeto sempre possui uma forma de identificao unvoca.

Uma clnica mdica necessita controlar as consultas mdicas realizadas e


marcadas pelos mdicos a ela vinculados, assim como acompanhar quem so os
pacientes atendidos para manter o acompanhamento clnico dos mesmos.

Este objeto no pode, ao modelarmos dados, possuir um identificador corri


valor nulo, pois um valor desconhecido impediria a identificao (existncia) deste
objeto.

Ao levantarmos os dados para a construo do sistema, nos foi informado que


para cada mdico a clnica mantm uma ficha com o nmero de CRM do mdico, seu
nome, endereo, especialidade etc.
Os pacientes preenchem um cadastro com dados pessoais tais como nome,
endereo, data de nascimento, sexo etc. Toda consulta registrada em fichrio prprio
com as informaes sobre mdico e paciente, diagnstico etc.

36

37

Vamos ento exercitar neste caso nossa viso de dados, de objetos neste
contexto. Quais so os objetos candidatos a entidades?
Ora, o objetivo mximo desta clnica a administrao das consultas mdicas.
Caracteriza-se neste ponto a existncia de um objeto de importncia crucial no
negcio: A Consulta Mdica.

Devemos continuar nossa anlise, pois definimos um pr-release da entidade


consulta, e ela no obviamente a nica no contexto, portanto consideremos ento,
que fomos informados de que a clnica mantm informaes sobre mdicos e tambm
sobre seus pacientes.

Mas o consulta mdica possui atributos que a caracterizem efetivamente como


uma entidade? Existiro vrias ocorrncias de consulta mdica? Podemos representla sob a forma de uma tabela com linhas e colunas?

Como existe mais de um mdico na clnica, fato j colocado, mas sem


especificao de um nmero desta existncia, indeterminado, caracteriza-se a
existncia de uma entidade Mdico no contexto, e da mesma forma a entidade
Paciente. J que iro existir muitas ocorrncias destes objetos, logo existem as duas
entidades (figura 4.7).

Obviamente, neste caso, a resposta as estas questes afirmativa, o que


permite-nos dizer que este objeto efetivamente uma Classe de Dados, ou seja, uma
Entidade.

Vamos procurar ento enxergar as tabelas de instncias destas entidades para


que possamos ter domnio e viso do conjunto de dados, eliminando-se assim o defeito
de analisar uma situao com base em um registro.

Mas o que descreve Consulta Mdica?


Os atributos de uma consulta mdica so aqueles que rapidamente
comentamos no incio do problema:

Lembrem-se, leitores, que vamos utilizar sempre uma viso espacial de dados,
vamos conhecer um nvel de dado ainda abstrato, logo vamos enxergar o todo e no
uma nica ocorrncia.

Data de realizao da consulta;


Identificao do mdico que realizou a consulta;
Identificao do paciente que fez a consulta.
Podemos, agora, visualizar a entidade Consulta, que um conjunto de
instncias que representam o fato, de um paciente se consultar com um mdico, na
forma de uma tabela de dados. de extrema importncia que se realize a simulao
desta tabela (figura 4.6), com atribuio de valores para cada atributo, e com mais de
uma ocorrncia do objeto consulta mdica.

Data_da_Consulta

CRM_do_Mdico

Identificao_Paciente

22/04/92
22/04/92
21/03/91
31/03/92

21113
21113
14442
55555

Joo Pedro Lima


Clara Mathias
Lus Alberto Conde
Maria Luiza Andrade

Figura 4.6 - Entidade Consulta Mdica.

CRM_Mdico

Nome_Mdico

Especialidade_Mdico

21114
21113
51024
76004

Lus Paulo Carvalho


Pedro Estevo Poct
Maurcio Abreu
Simone Almeida

Pediatria
Ginecologia
Neurologia
Cardiologia

Nome_Paciente
Julio Adamastor
Carmen Milhor
Sandra Chu Li
lvaro Medeiros

Endereo
R. Silva S n 26
R. Dias Mejores 56
R.:? BoBoa Norcia.
R. Botina do Ouvidor 56

Figura 4.7 - Entidades Mdico e Paciente.

Sexo
Masc.
Fem.
Fem.
Masc.

Idade
32
56
36
56

No devemos considerar como entidade um objeto, se no conseguirmos ter a


viso de seu contedo em instncias com valores de atributos.

Se analisarmos superficialmente, poderamos ter definido entidades para cada


uma destas classes. Ou seja, existiriam as entidades especficas de cada um.

Isto eqivale a afirmar que num primeiro momento, visualizamos sempre o


macro objeto, uma abstrao, e devemos obrigatoriamente, para nosso entendimento,
procurar obter a viso de sua composio de ocorrncias, sem a qual no poderemos,
com certeza, afirmar sua existncia, e fix-la em nosso modelo.
O exemplo anterior caracteriza que uma entidade pode ser um objeto concreto,
como mdico e paciente, como tambm pode ser um objeto abstrato, um fato, um
evento que desejamos registrar, e que possui caractersticas prprias no caso como a
consulta mdica (figura 4.8).

Figura 4.9
O que na realidade fizemos foi, atravs da colocao de um atributo
qualificador, o qual permite a distino entre cada classe de dados, generalizar todas
estas classes em uma nica, que denominamos de Mdico.
Dentro do contexto da metodologia, alguns autores consideram que a entidade
mdico uma entidade supertipo, mas esta nomenclatura no consideramos como
ideal para expressar a realidade que estamos analisando.

Figura 4.8

4.6 - Generalizao e Especializao

Temos como regra ento que quando encontramos entidades que possuem o
mesmo conjunto de atributos para descrev-las, podemos generaliz-las em uma nica
entidade, mantendo sua identidade de subconjunto atravs da insero de um atributo
qualificador para as ocorrncias de cada uma.

importante que quando estamos na busca da visualizao dos dados de um


negcio, nos atenhamos ao nvel de abstrao em que estamos atuando, pois quando
definimos uma entidade, estamos com a viso de uma classe genrica de dados, que
pode estar incorporando, implicitamente, diversas outras classes de dados.
Ou seja, existe um encapsulamento de informaes sob a forma desta entidade
genrica, a qual possui subconjuntos de dados que formam classes diferenciadas, mas
que possuem caractersticas que nos permitem coloc-las sob a viso de uma nica
entidade.
Por exemplo, o caso que estudvamos da Clnica Mdica.
A entidade mdico na realidade uma generalizao para diversas classes de
dados de mdicos, tais como a figura 4.9 representa: Mdico Pediatra, Mdico
Cardiologista e Mdico Neurologista.

Figura 4.10
A esta qualificao por atributos que nos permitir identificar um grupo, uma
classe dentro da classe genrica, denominamos de Especializao.
Aparece neste instante um dos conceitos de vises de dados.

Viso de dados a efetivao de um subconjunto de uma_entidade


(especializao) atravs da representao efetiva no diagrama de entidades e
relacionamentos, de forma a permitir o tratamento e entendimento da formao de
dados existente na realidade.

Poderamos, em uma anlise mais profunda, descer a um nvel mais apurado


de observao, em que estes subconjuntos especificados seriam na realidade
tambm compostos por outros subconjuntos, tais como Drama Romntico e
Drama Policial, ou ainda Comdia Policial e Comdia Romntica.

Dentro da abordagem relacionai de banco de dados, este na realidade o


conceito de "role", ou "alis", um indicador de que uma entidade possui entre suas
ocorrncias, algumas que representam um ou mais conjuntos de dados, com existncia
real definida.

Existe, na realidade, uma hierarquia de classes de dados, encapsulada em uma


entidade genrica.

No nosso exemplo at aqui utilizado, temos na entidade mdico, um atributo


qualificador que "Especialidade_do_Mdico".
A
figura
4.10
apresenta
como
podemos
representar
a
generalizao/especializao num diagrama de entidades e relacionamentos, para o
exemplo em questo.
Mas vejamos outros exemplo, para que possamos estender nossa capacidade
de anlise de entidades. Seja um modelo de dados que possua uma entidade Filme,
como a locadora de fitas de videocassete que citamos anteriormente.
Como j salientamos, poderamos ter a entidade Filme.
Observando a maneira como as pessoas selecionam as fitas que iro assistir,
assim como as solicitam e questionam sobre sua existncia, podemos observar ento
que existem dentro da entidade filme, subconjuntos que caracterizam-se como
especializaes desta entidade.
Nestes subconjuntos podemos visualizar: Filme Comdia, Filme-Drama e FilmePolicial (figura 4.11).

Mas por que a preocupao deste gnero?


Quando ela se torna importante?
Ela importante porque podemos vir a ter na anlise funcional do sistema,
tratamentos procedurais e diferenciados para cada subconjunto, assim como
poderemos tratar simultaneamente todos os conjuntos.
Estes subconjuntos de uma entidade podem ser, inclusive, de naturezas
completamente diferentes, mas importantes de conhecimento.
Seja uma entidade Pedido em um determinado sistema.
Esta entidade Pedido pode estar generalizando, por exemplo, os seguintes
subconjuntos: Pedidos Pendentes, Pedidos Suspensos e Pedidos Atendidos.
Por outro lado os pedidos podem ser Pedidos Nacionais e Pedidos de
Exportao.
Neste caso, temos que analisar se existem na entidade pedidos de dois tipos,
distintos de especializao, um por origem de pedido e outro por situao de pedido,
sendo que os dois podem se superpor, tal como Pedido Nacional Pendente, ou Pedido
Suspenso de Exportao.
Devemos represent-los de forma que possamos vir a trat-los como um todo
ou como parte do todo.
Por exemplo:

Figura 4.11

Todos os pedidos suspensos;


Todos os pedidos nacionais suspensos;
Todos os pedidos nacionais;
Todos os pedidos pendentes de exportao.

Na realidade, temos os subconjuntos do quadro:

Pedido Nacional

Pedido Exportao

Pedido Suspenso

Pedido Pendente

Pedido Atendido

Especializao em trs nveis:


Pedido Nacional
Pedido Nacional Suspenso
Pedido Suspenso
A figura 4.12 nos mostra a representao deste caso dentro de um diagrama de
Entidade-Relacionamento.
Sempre que existirem topologias em uma entidade, existir de fato uma
generalizao/especializao.

5.1 - A Existncia
O entendimento sobre o que so efetivamente relacionamentos e a capacidade
de enxergar estes objetos, como participantes do mundo real, so fatores primordiais
para que se venha a efetuar trabalhos de modelagem de dados com compreenso do
que est sendo realizando.
No devemos, nunca, colocar temores de complexidade em uma tcnica, e sim
lembrarmo-nos de que a mesma nada mais do que uma forma estruturada de
representar as coisas que existem e ocorrem no mundo real. Procurando, sempre,
retratar com simplicidade os fatos, isso os levar a representar com correo e
entendimento.

Devemos estar atentos ao executar o projeto conceituai, pois existem casos em


que teremos entidades diversas com nomes distintos, mas que na realidade podem ser
generalizadas em uma nica, j que conceitualmente referem-se a um macro objeto,
que por generalizao pode absorv-las integralmente.
Na prtica, a generalizao efetivada quando o conjunto de atributos das
entidades comum em sua maior parte.
Concluindo, na generalizao estamos colocando todas as instncias de
entidades diversas em uma nica entidade, realizando seu tratamento como um todo,
ou como parte quando necessrio.

Temos sentido nas diversas turmas de cursos que ministramos, um certo grau
de dificuldade dos alunos em compreender corretamente relacionamentos, fato que
leva a dedicar este captulo para o perfeito entendimento do tema e sua utilizao.
Dentro deste enfoque definimos RELACIONAMENTO como o fato, o
acontecimento que liga dois objetos, duas "coisas" existentes no mundo real.
Considerando que estamos nos orientando para aplicaes que sero
desenvolvidas e administradas por um Sistema Gerenciador de Banco de Dados,
poderamos estender o conceito, principalmente para ambientes relacionais, como
sendo relacionamento o fato que efetua a juno de duas ou mais tabelas de dados.

Relacionamentos
Entretanto, como estamos trabalhando em modelagem conceituai de dados,
vamos nos privar de preocupaes relativas a software ou o hardware, e nos
concentrar em obter a viso dos dados de um determinado problema ou rea de
negcio.
Para um retrato dos objetos e fatos de um problema, os relacionamentos so os
elementos que nos do o sentido da existncia destes objetos e suas inter-relaes, sem
as quais ficaria de extrema complexidade o entendimento e a compreenso do domnio
do problema.
A figura 5.1 apresenta apenas dois objetos de um contexto qualquer, sendo:
um homem de nome Joo e uma mulher de nome Maria.

JOO
Figura 52
Na figura 5.2 com os mesmos objetos, apenas com a incluso de um verbo
entre eles, passamos a contar com um contexto de mais expressividade. l podemos
dizer que temos maior domnio (conhecimento) do ambiente.
A colocao do verbo, ou seja, do Relacionamento, deu semntica ao todo, as
coisas j fazem sentido, no esto mais soltas, j existe um fato entre os objetos
realizando uma ligao.
VERBO = A EXPRESSO DE UM FATO

JOO

MARIA

Figura 5.1
O que podemos entender deste contexto?
Temos apenas dois objetos (substantivos), soltos no espao, torna-se evidente,
at este instante, a inexistncia de qualquer ligao entre os dois objetos.
Voc j tentou se comunicar com as pessoas, explicar uma situao, contar
uma histria sem utilizar VERBOS em seu vocabulrio?
E impossvel nos fazermos entender, em qualquer situao, sem utilizarmos
verbos, sem explicarmos o relacionamento entre as "coisas" sobre s quais nos
referimos.

No mundo que nos cerca, tanto em nossas atividades profissionais como nas
atividade pessoais, convivemos com os mais variados tipos de entidades (objetos
reais), que como j vimos, so descritos por uma srie de atributos, e que expressam
uma realidade de existncia.
Estas entidades do dia-a-dia no esto soltas, desligadas umas das outras, e
sim relacionadas de forma a mostrar a realidade com um contedo lgico.
Diariamente relatamos coisas do mundo real, e quando o fazemos estamos na
verdade expressando entidades e relacionamentos, seno vejamos:
As Pessoas Moram em Apartamentos;
Os Apartamentos Formam Condomnios;
Os Condomnios Localizam-se em Ruas, ou Avenidas;
As Avenidas e Ruas Esto em uma Cidade.
Poderamos seguir at o infinito do espao sideral, mas um simples
olhar para a figura 5.3 nos d uma viso clara dos objetos, existentes no

mundo real, assim como as relaes entre estes objetos nos do domnio de
conhecimento sobre um contexto especfico.

Figura 53 - Fatos de uma Realidade.

HOMEM
PEDRO
LUS
SRGIO
CLVIS
MARCELO
CELSO
CARLOS

MULHER
SILVIA
CARLA
ANTNIA
ANDREIA
CRISTINA
MARIA
ANA LCIA
ANA PAULA
ANA FLVIA

Figura 5.4

O que desejamos obter atravs da modelagem destes objetos, exatamente a


compreenso de contextos atravs dos dados.

Um Homem pode estar casado com duas ou mais mulheres ?

Mas o importante construir sistemas de aplicao com a certeza de que


sabemos para que os construmos e com completo domnio do negcio para o qual o
sistema foi projetado. Um sistema sempre projetado para que venha a resolver um
determinado problema de um negcio.

Todas as mulheres so casadas?

Este negcio, possui, seguramente, um grupo de objetos que representa os


interesses da organizao. Vamos detalhar ento, como estes objetos se relacionam e
de que formas estes relacionamentos existem no mundo real.

5.2 - Condicionalidade
Sejam duas entidades conforme a figura 5.4: Homens e Mulheres.

Depende do pas onde estaremos realizando o projeto do sistema.

Todos os Homens so casados ?


Se estivermos retratando a realidade, as respostas s perguntas "Todos"
evidentemente "No". Mas ento como vamos entender a existncia de
relacionamentos, se existem elementos que no fazem parte, ocorrncias das entidades
que no esto se relacionando?
A questo das duas ou mais mulheres, iremos analisar quando tratarmos de
cardinalidade de relacionamentos, logo adiante neste livro.
O fato de alguns elementos da entidade no acontecerem no relacionamento,
em hiptese alguma indica a inexistncia do fato, pois no mundo real o caso de
homens no serem casados no elimina a existncia do rato, do evento casamento,
existindo homens casados e no casados em uma mesma entidade, sendo inclusive a
participao no relacionamento (evento Casado), uma qualificao de um conjunto da
entidade Homens.
Isto nos leva a dois grandes grupos de Relacionamento:
a) Relacionamentos Condicionais - relacionamentos que possuem uma
condio, uma qualificao para ocorrerem, e;
b) Relacionamentos Incondicionais - no possuem esta condio,
caracterizam-se por serem obrigatrios.

48

5.3 - Relacionamentos Condicionais


So efetivamente aqueles relacionamentos em que nem todos os elementos de
uma entidade A esto ligados com elementos da entidade B. Dizemos que este tipo de
relacionamento possui opcionalidade.

5.4 - Relacionamentos Incondicionais


Todos os elementos de uma entidade esto obrigatoriamente
relacionados com um elemento, no mnimo, da outra entidade.

Estes dois grupos de relacionamentos possuem cada um, vrios graus de


relacionamentos, que iremos estudar neste livro detalhadamente.
Agora neste ponto j conhecemos os dois elementos bsicos do modelo
Entidade Relacionamento, vamos ver ento qual a forma de representao grfica
do relacionamento, utilizada por Deter Chen, para que o modelo E-R mantivesse um
grau de semntica que espelhasse efetivamente o mundo real.
Os relacionamento so representados por um losango entre as entidades e com
arestas ligando as entidades a este losango. No interior do losango, inserimos um
verbo que explicite o fato (o evento) que o relacionamento (figura 5.6).

Neste caso, existe a obrigatoriedade do relacionamento entre todos os


elementos de uma entidade com os elementos de outra.
Por exemplo, vejamos a figura 5.5 a seguir:

Figura 5.5
Toda ocorrncia de me est relacionada a um ou mais filhos e; Toda a
ocorrncia de Filho est obrigatoriamente ligada a uma ocorrncia de me.
Neste caso, no poderamos ter em nenhuma hiptese, a possibilidade de
existir na entidade filhos ocorrncias que no estivessem ligadas a uma ocorrncia da
entidade me. E no sentido inverso tambm no poderamos ter uma ocorrncia em
me que no estivesse ligada a um ou mais filhos, pois se permitssemos, estaramos
distorcendo o mundo real, j que no existe uma me se no possuir filhos, e ningum
pode ser filho se no possuir uma me.
O relacionamento Tem da figura 5.6 ento um relacionamento
Incondicional, pois obrigatrio para todos os elementos de me e todos os elementos
de Filho.

Figura 5-6 - Representao de Relacionamentos.


Na figura 5.6, temos ento os relacionamentos:
Homem Casado com Mulher;
Me Tem Filho;
Condomnio Localizado em Rua;
Funcionrio Recebe Salrio.

5.5 - A Viagem
Mas voltemos ao nosso dia-a-dia, e vamos preparar as malas para uma viagem
ao Caribe (quem sabe um dia!!).

Projeto de Banco de Dados

Relacionamentos

Temos em casa um jogo de malas com tamanhos, cores e de materiais


diferentes, com rodinhas, sem rodinhas, ou seja, uma infinidade de caractersticas para
cada uma. Em nossas malas iremos colocar roupas, sapatos, produtos de higiene, etc,
tudo aquilo que se leva quando se sai de frias.
Como roupas so diferentes umas das outras, criamos uma srie de atributos
que as caracterizam e individualizam, e da mesma forma iremos proceder com sapatos
e produtos de higiene.

Existem casos em que as pessoas vo lembrar o que perderam ao extraviaremse suas malas, muitos meses depois.
Logo, temos de criar relacionamentos entre as entidades envolvidas na
viagem, que tenham o mesmo efeito de uma lista de coisas colocadas em cada mala,
isto na realidade uma viso dos dados com relacionamentos entre eles. O que iremos
fazer um modelo E-R, que ir representar com a mesma simplicidade da vida real
este relacionamento (figura 5.7).

Logo temos 4 entidades envolvidas com a nossa viagem, ou seja:


MALA SAPATO
SAPATO
ROUPA PRODUTO DE HIGIENE

Vamos entender quais so os seus atributos bsicos.


ENTIDADE:

ATRIBUTOS

Mala

Cor
Volume Material
Indicador de rodas
Tipo de fechamento

Roupa

Cor da roupa Material


(tecido) Descrio da
roupa
Sapato
Cor
Tipo (Esporte/Social)
Marca
Produto de higiene Nome
Marca
e Beleza
Se por acaso "um acidente de percurso" acontecer, e uma mala for extraviada
ou perdida no trajeto Rio-Miami, e, se no houvesse uma forma de relacionar as
coisas, como iremos saber o que estaria faltando de roupas, sapatos e produtos de
higiene.

PRODUTO DE HIGIENE

RELACIONAMENTO

LIGA

Contm

Roupa com Mala

Colocado na

Sapato com Mala

Est na

Produto de Higiene com Mala

figura 5.7
Para a descoberta do relacionamento existe um tipo de, digamos, "Pulo o Gato",
para aps definidas as entidades de um sistema, descobrirmos onde acontecem
relacionamentos, mas isto ser estudado mais adiante.
Primeiro importante estudarmos as chamadas Cardinalidades dos
relacionamentos, ou Grau dos Relacionamentos dentro dos dois grupos Principais.
Outro aspecto importante a ser considerado o fato de conseguirmos enxergar
em um diagrama de Entidades e Relacionamentos, os fatos que esto ali retratados,
com a mesma simplicidade com que estes acontecem no mundo

Relacionamentos

real, o diagrama de Entidade e Relacionamento deve expressar os dados e eventos,


sem teorticas transcries ou tradues de cdigos, mas sim com expresso pura e
simples da realidade dos fatos (figura 5.8).

Figura 5.9 - Relacionamento um-para-um.


A figura 5.9 mostra um diagrama de instncias onde dois objetos se relacionam
com cardinalidade de um-para-um.

Figura 5.8

O elemento A da entidade 1 relaciona-se com o elemento Y da entidade 2 e


somente com ele, no existindo nenhum outro relacionamento entre A e qualquer
outro elemento da entidade 2, que no o existente com Y.

5.6 - Grau do Relacionamento

importante salientar que lemos o diagrama somente em um sentido, e isto


est incorreto dentro do conceito de relacionamento, pois os mesmos no so
unidirecionais.

Quando temos um relacionamento entre duas entidades, o nmero de


ocorrncias de uma entidade que est associado, com ocorrncias de outra entidade,
determina o Grau do Relacionamento, ou Cardinalidade deste fato.

Devemos ler o relacionamento nos dois sentidos em que ele se efetua. Logo
leremos no caso da entidade Homem e da entidade Mulher, que um homem est
casado somente com uma mulher e uma mulher est casada somente com um homem.

Quando questionamos anteriormente se um homem poderia estar casado com


mais de uma mulher, estvamos na realidade questionando o grau de relacionamento
que existia entre as entidade Homem e Mulher.

Muitos dos erros na construo de modelo de dados ocorrem por serem


realizados exames apressados sobre a cardinalidade dos relacionamento, efetuando-se
a anlise somente no sentido de um interesse especfico do negcio, sem que se
verifique a cardinalidade no sentido inverso.

O mundo real apresenta-se com trs possibilidade de relacionarmos os dados,


ou seja, trs graus de relacionamento, que so:

SENTIDO DE LEITURA

5.6.1 - Relacionamento de Um-para-Um


Neste grau de relacionamento, cada elemento de uma entidade relaciona-se
com um e somente um elemento de outra entidade.
No caso comentado acima, temos que uma ocorrncia da entidade Homem
relaciona-se com uma, e somente uma, ocorrncia da entidade Mulher, pois o
casamento no Brasil ainda monogmico (figura 5.9).

IDNTICO RESULTADO = 1:1

Relacionamentos

5.6.2 - Relacionamento de Um-para-Muitos


Este grau de relacionamento o mais comum no mundo real, sendo o que
denominamos de relacionamento bsico entre entidades, entretanto possui
caractersticas especficas, quanto ao sentido de leitura dos fatos e sua interpretao.
Um elemento da entidade 1 relaciona-se com muitos elementos da entidade 2,
mas cada elemento da entidade 2 somente pode estar relacionado a um elemento da
entidade 1.
Ou seja, o grau de cardinalidade determinante sempre o maior grau obtido da
interpretao dos fatos.

Devemos ter como regra geral ento, que um relacionamento do tipo umpara-Muitos, quando um sentido de leitura dos fatos nos apresenta este grau de Umpara-Muitos e o sentido oposto apresenta obrigatoriamente o grau Um-para-Um.

5.6.3 - Relacionamentos de Muitos-para-Muitos


Vejamos o exemplo da figura 5.11. Fcil visualizao e entendimento,
apresentando a associao entre a entidade Estudante e a entidade Disciplina
(relacionamento Cursa). Nela tambm so mostradas as instncias do relacionamento:

Para ilustrarmos inicialmente este relacionamento, vamos nos deslocar


at algum dos pases rabes.

Figura 5.11 - Relacionamento muito-para-muitos.


RESULTADO = 1:N Figura 5.10 Relacionamento um-para-muitos.
Um homem casado com muitas mulheres, mas a recproca no
verdadeira, pois uma mulher casada com um s homem (figura 5.10).
O fato de em um dos sentidos de leitura apresentar um grau Um-para-Um, no
garante que o grau geral do relacionamento seja este.

Um estudante cursa vrias (muitas) disciplinas, mas alguns estudantes


temporariamente podem estar cursando somente uma, ou nenhuma
disciplina.
Uma disciplina cursada por vrios (muitos) estudantes, mas
eventualmente podemos ter uma disciplina que no possua nenhum
estudante cursando-a, ou somente um. Neste caso, por haver
opcionalidades, caracteriza um relacionamento condicional.

Identifica-se esta cardinalidade pelo fato de que em ambos os sentidos de


leitura encontramos um grau Um-para-Muitos, o que caracteriza ser ento um contexto
geral de Muitos-para-Muitos. Este tipo de relacionamento caracteriza-se por um
aspecto que lhe extremamente peculiar, ele possui atributos. Isto quer dizer que este
relacionamento possui dados que so inerentes ao fato e no s entidades.
Em nosso exemplo anterior, poderamos considerar que a data de matrcula, ou
a turma onde o aluno cursa a disciplina, so atributos que descrevem ou informam algo
sobre a associao das entidades, no sendo um atributo inerente a nenhuma das duas
entidades em questo.
No devemos nunca, ao pesquisar a Cardinalidade de um relacionamento,
analisar somente uma ocorrncia de associao entre os dados, pois no caso de
relacionamentos condicionais, estas ocorrncias podem no ser relacionadas, e mais,
podem estar com cardinalidade somente de um-para-um eventualmente.
Para a descoberta da cardinalidade devemos analisar de forma macro a
possibilidade de relacionamentos, sendo que a ocorrncia de maior valor que
determina sempre o grau lgico do relacionamento.
Apresentamos seguir a estrutura das entidades envolvidas na figura 5.11, e
os atributos que so inerentes ao prprio relacionamento, ou seja, identificam ou
qualificam o relacionamento:
ENTIDADE

ATRIBUTOS

RELACIONAMENTOS

Estudante

Nome do Estudante
Matrcula do Estudante
Cdigo da Disciplina
Nome da Disciplina

com Disciplina 1:N

Disciplina

5.7 - A Modelagem dos Relacionamentos


Sabemos, por experincia adquirida ao longo dos anos e das salas de
treinamento, que no nos basta conhecer as cardinalidades possveis, ou seja, o grau
dos relacionamentos. Existe o lado crtico do trabalho prtico:
Como saber qual o grau de um relacionamento que observamos no mundo
real? E mais;
Ser mesmo um relacionamento, ou um procedimento de sistema, que os
vcios anteriores de anlise procedural trazem a ns para tornar nebulosa a
viso dos dados?

5.7.1 - A Descoberta dos Relacionamentos


Existem diversas situaes em que vislumbramos turvamente um
relacionamento.
Devemos sempre questionar se no estamos visualizando um
procedimento.

com Estudante 1:N


Figura 5.12

RELACIONAMENTO

ATRIBUTOS

Cursa

Data da Matrcula
Turma

Certos verbos utilizados para expressar o relacionamento so tipicamente


representaes de procedimentos.
Seja ento a situao da figura 5.12. Interpretando a entidade Item de
Nota-Fiscal: ela possui em cada cocorrncia, um objeto, que um produto
constante em alguma nota-fiscal.
A entidade Item-de-Estoque guarda em suas ocorrncias os itens que
compem o estoque de produtos. Logo, temos ento a seguinte formao de dados
para o modelo:

Um Item de Nota Fiscal est em Um Item de Estoque, ou,


ENTIDADE

ATRIBUTOS

Item de Nota
Fiscal

Nmero da Nota Fiscal


Cdigo de Identificao do
Produto
Quantidade do Produto na Nota
Cdigo de Identificao do
Produto
Descrio do Produto
Quantidade em Estoque
Valor Unitrio do Produto

Item de Estoque

Quando estamos analisando o contexto de administrao de estoques, muitas


vezes a preocupao com os procedimentos nos leva a seguinte observao:
Quando enviamos uma nota fiscal, estamos tambm remetendo os tens desta
nota fiscal, que so itens de estoque. Logo temos de dar baixa nos saldos em estoque.
Esta baixa ser realizada pela operao de subtrao da quantidade do produto na
nota fiscal, da quantidade em estoque do produto.
Muitas vezes temos encontrado modelos que embutem o procedimento no
modelo como se ele fosse um relacionamento.

Um Item de Nota Fiscal Refere Um Item de Estoque, ou ento,


Um Item de Nota Fiscal Consta Um Item de Estoque.
O reverso sempre ser obtido tambm, pois um Item de Estoque referido
por muitos Itens de Nota Fiscal
Uma leitura ampla do diagrama nos esclarece melhor a viso dos dados.
Todo Item de Nota Fiscal um Item de Estoque.
As ligaes sugeridas do maior semntica ao modelo e sua
interpretao retrata a realidade dos dados com sua dinmica.

5.7.2 - Como Testar se um Relacionamento Realmente Existe


Isto na realidade uma tarefa, relativamente, complexa quando no temos de
imediato uma estrutura de dados com informaes comuns no primeiro instante de
nossa anlise.
Relacionamentos em um modelo podem surgir em funo das exigncias e
necessidades de recuperao de informaes por parte do usurio.

Ento apareceria Item de Nota Fiscal Baixa Item de Estoque. Mas se os


permitirmos usar um verbo to indicador de procedimentos no modelo, reguramente
iremos cometer uma srie de desvios que levar o modelo a ser concebido sob uma
orientao de procedimentos, que levar, por sua vez, construo de uma base de
dados instvel.

Figura 5.13
Entretanto se nos preocuparmos em somente fotografarmos os dados,
procurando descobrir o que so e no o que feito com eles, teremos o mlodelo da
figura 5.13 que simplifica o entendimento:

Figura 5.14
Seja o modelo Departamento Lota Funcionrios e Departamento Tem
Escritrios, da figura 5.14.

Departamento lota 1 ou mais funcionrios e um funcionrio est lotado em


um e somente um departamento.
Um departamento possui 1 ou mais escritrios.

A certido de nascimento das pessoas que t filhos,


possui o nome dos filhos?

Para que estas instncias aconteam de fato, necessitamos que existam dados
ou campos comuns s duas entidades:

E bvio que no. a certido de nascimento dos


filhos que possui o nome dos pais.

Entidade:

Atributos:

Resumindo, dependentes indicam de que


dependem.

Departamento

Cdigo do Departamento
Nome do Departamento
Verba do Departamento

Funcionrio

Escritrio

Cdigo do Funcionrio
Nome do Funcionrio
Data de Admisso
Nmero do Escritrio
rea do Escritrio

Esta estrutura de dicionrio possui os campos necessrios descrio de cada


uma das entidades. Mas como efetivarmos o relacionamento?
Olhando a figura do E-R apresentada, vamos trabalhar o primeiro
relacionamento, entre Departamento e Funcionrio.

ENTIDADE ATRIBUTOS
Voltando ento ao nosso caso, a estrutura de dados para Funcionrio deve ser:

RELACIONAMENTOS
Funcionrio Cdigo do Funcionrio Nome do
Funcionrio Data de Admisso
Cdigo do Departamento

Com Departamento 1:1


(Lotado)

Este campo exerce a funo de Chave Estrangeira na entidade Funcionrio.

Vejamos ento o diagrama de instncias deste modelo de dados:

Um Departamento tem Lotados muitos Funcionrios;


Um Funcionrio est Lotado somente em um Departamento.
Sendo que se encontrarmos dois graus de relacionamento conforme o sentido
de leitura, adotamos o grau maior como o efetivo do relacionamento.
Ento, o lado que ficar com a cardinalidade N (muitos) dever ter um campo,
em sua estrutura, idntico a um campo da outra entidade, o qual chave primria nesta
entidade.
Este o conceito de chave estrangeira: um dado colocado em uma entidade
que em outra o identificador unvoco (chave primaria).

E importante sempre lembrar, que este campo utilizado como chave


estrangeira, dever ser na entidade referenciada (lado Um) correspondente Chave
Primria desta.

E isto uma lgica normal das hierarquias naturais, seno vejamos:


Bem, uma vez resolvido o relacionamento entre Departamento Funcionrio,
temos ainda que resolver o relacionamento entre Departamento

e Escritrio, j que necessrio recuperar, ou seja, consultar quais escritrios so de


um determinado Departamento.
Seguindo o mesmo raciocnio lgico, uma vez que entre Departamento e
Escritrio existe uma ligao Um-para-Muitos, colocaremos a Chave Principal de
Departamento na estrutura de Escritrio.

ENTIDADE ATRIBUTOS
Escritrio

Nmero do Escritrio
rea do Escritrio
* Cdigo do Departamento

ENTIDADE
ATRIBUTOS
Funcionrio Cdigo do Funcionrio Nome
do Funcionrio Data de
Admisso
Cdigo do Departamento
Nmero do Escritrio

RELACIONAMENTO
Com Departamento 1:1

* Chave Estrangeira
Temos assim em escritrio uma referncia lgica ao Departamento que ele
pertence.
Poderamos, na realidade, denominar estes campos inseridos na estrutura das
entidades, do lado Muitos do relacionamento, como sendo "Pointers Lgicos", que
nos indicam seus parceiros no relacionamento.
Mas ainda dentro de nosso modelo, devemos sempre validar se as
necessidades de informaes so possveis de serem supridas no modelo resultante.
Por exemplo, se houver necessidade de obtermos a informao de onde
trabalha o Funcionrio, ou seja, em que Escritrio trabalha um Funcionrio, ou mais,
que Funcionrios trabalham em um determinado escritrio.
Se observarmos os modelos, e mais a estrutura de dados que j obtivemos
para este, conclumos que facilmente podemos saber o Departamento em que um
Funcionrio est Lotado, mas a partir de Departamento torna-se impossvel descobrirse em que escritrio ele trabalha. J que um departamento possui muitos Escritrios, o
funcionrio pode estar em qualquer um deles. Alm do mais, a lgica do mundo real
nos informa que em um Escritrio devero atuar muitos funcionrios.
Este caso na realidade, de soluo muito fcil, pois basta-nos colocar o
identificador nico de escritrio na estrutura de Funcionrio, que estaremos
estabelecendo condies para a existncia de um relacionamento direto entre as duas
entidades neste modelo.

* Identifica a Chave Estrangeira


Aps esta insero na estrutura Funcionrio, temos:
Um Departamento Lota muitos Funcionrios;
Um Departamento Tem muitos Escritrios e em um Escritrio Atuam
muitos Funcionrios.
Pode at parecer que estamos com um caminho redundante no modelo, no
tocante a Funcionrio Lotado Departamento Tem Escritrio e Funcionrio Atua
Escritrio, mas como j vimos, so fatos distintos, com graus de relacionamento
distintos, o que nos permite recuperar a informao com mais segurana.
Se Funcionrio est ligado a Escritrio e Escritrio est ligado a
Departamento, ser mesmo necessrio ligar Funcionrio a Departamento, ou pelo
Escritrio podemos saber o Departamento em que o funcionrio est alocado?
Devemos considerar neste momento, que um Funcionrio pode eventualmente
estar atuando, exercendo suas atividades profissionais, em um Escritrio que no
pertence ao Departamento no qual ele est alocado.
Logo, no seria completa a viso dos dados se colocssemos restries para
viabilizar um modelo com menos relacionamentos.
O caminho de relacionamento entre Funcionrio e Escritrio desta forma de
grande valia para a obteno de informaes deste caso (figura 5.15).

Figura 5.15

6.1 - A Expresso do Relacionamento


Apresentamos at este ponto a necessidade de incluirmos campos na estrutura
de dados das entidades para que se efetuem os relacionamentos, ou seja, existem
campos comuns para a ligao.
Quando um campo em uma entidade caracteriza-se por ser a chave de
identificao nica de ocorrncias desta entidade, denomina-se, como j vimos, Chave
Primria.
Quando em uma entidade temos um campo que chave primria de outra
entidade, denomina-se Chave Estrangeira.
Esta ligao realiza-se por comparao do valor da Chave estrangeira de uma
talula com o valor da Chave Primria de outra tabela.
Se temos um Funcionrio Joo e um Departamento Contabilidade, estes
objetos somente estaro relacionados se:
O valor do campo Cdigo do Departamento na ocorrncia de Joo da
entidade Funcionrio for igual ao valor do campo Cdigo do Departamento
da entidade Departamento na ocorrncia Depto de Contabilidade.
Ora, isto nos fornece ento uma expresso lgica, de comparao de valores,
que explicita e estabelece uma regra para o relacionamento entre as duas entidades:

Cdigo_do_departamento em Funcionrio =
Cdigo_do_departamento em Departamento.
Se desejarmos saber quais os funcionrios de um departamento especfico,
bastar informarmos o valor do cdigo deste departamento, para que sejam
selecionadas todas as ocorrncias de funcionrio, cujo campo cdigo do departamento
seja igual ao valor informado.
Este um processo de seleo, ou melhor, uma operao de seleo relacionai.
Vamos observar as figuras das tabelas apresentadas a seguir, que simulam o
contedo das duas entidades referidas.
Entidade: Departamento
Cdigo
Departamento

Nome
Departamento

Verba

01
10
21

Contabilidade
Vendas
Faturamento

500,00
1.000,00
250,00

Cdigo

Nome

Data
Admisso

Cdigo
Depto

0111
0112
0271
0108
0357
0097

Joo

12/11/90
12/12/91
05/06/91
03/03/90
20/10/91
15/02/92

01
01
10
10
10
21

Podemos ento desta forma, responder s questes:


Quais os funcionrios do Departamento de Vendas ?
- Cdigo do Departamento de Vendas = 10
Quais os Funcionrios que tm Cdigo de Departamento igual a 10?
- Carlos: Eduardo e Lus.

Para um bom trabalho de modelagem devemos esquecer estas operaes


comentadas, preocupando-nos somente com os dados em si, no nos importando com
procedimentos que sero inerentes ao sistema como um todo.
Na realidade, quando modelamos, no pensamos em sistemas, e sim em
conseguir obter o entendimento de um negcio ou problema, estruturando os dados
deste problema, com vistas ao seu domnio e sua soluo.
Para que se solidifiquem os conceitos de uma tcnica, no bastam apenas a
apresentao de um exemplo de situao e sua aplicabilidade, mas bem pelo contrrio,
a massificao de casos analisados que nos dar a possibilidade de ter segurana em
nosso conhecimento adquirido.
A visualizao de uma massa de casos tem por objetivo, alm da solidificao
de uma cultura, propiciar diversidade de situaes de anlise.
Entendemos que quanto mais situaes passarmos com esta publicao, maior
fonte de consulta o leitor ter para a sua vida profissional.

Entidade: Funcionrio

Antnio
Carlos
Eduardo
Lus
Vera

Gostaramos de salientar que temos colocado a preocupao de sempre nos


orientarmos para recuperar informaes combinadas, no dando nfase neste
momento insero, manuteno ou deleo de dados, aspectos que iremos comentar
adiante neste livro, mas que so elementos que auxiliam na descoberta do contexto e
sua consolidao.

6.2 - Quando os Fatos podem Confundir-nos


O correto entendimento de uma informao depende muito da condio de
interpretao dos fatos e da determinao da inerncia do dado Pelo analista de
sistemas.
O saber interpretar o que um dado caracteriza, ou a quem este dado se refere
de suma importncia para o resultado correto do modelo de dados.
Vamos ento analisar uma situao em que se poderia ter interpretaes
errneas da verdadeira caracterizao que um dado efetua.

Entidade:

Atributos:

Funcionrio

Matrcula do Funcionrio Nome Aloca N:l


do Funcionrio Endereo
Cdigo do Projeto Data de
Incio no Projeto Tempo
Previsto de Alocao

Projeto

Cdigo do Projeto
Nome do Projeto

Figura 6.1
Em uma determinada empresa, so realizados diversos projetos de engenharia
que alocam os funcionrios disponveis de seu quadro funcional conforme a
necessidade, ficando estes funcionrios alocados a somente um projeto at o
encerramento do mesmo.
Uma vez alocado o funcionrio a um determinado projeto, deve ser registrada
a data de incio de suas atividades no projeto, assim como o tempo em meses que o
mesmo ir ficar alocado. O modelo E-R que representa este fato o apresentado na
figura 6.1.
Interpretando, ou melhor, lendo o diagrama que exprime o modelo de dados
temos:

Relacionamento:

Aloca 1:N

Se a realidade colocada em anlise fosse a de que um funcionrio estivesse


alocado a muitos projetos, esta seria uma informao do relacionamento entre
Funcionrio e Projeto, j que para cada associao do Funcionrio com um Projeto,
teramos estes dados para caracteriz-la. Veremos mais a seguir um estudo deste tipo
de relacionamento.

Um Funcionrio Alocado a um Projeto e um Projeto Aloca muitos


Funcionrios.

A figura 6.2 apresenta o diagrama de instncias para o relacionamento Umpara-Muitos entre Funcionrio e Projeto.

Surge agora no tocante aos dois dados antes referidos, Data de Incio e Tempo
de Alocao, a dvida de sua caracterizao. Estes dados so inerentes ao fato
Alocao, logo so campos, dados do relacionamento Alocado. Mas esta afirmativa
est errada.

Propositalmente, colocamos no diagrama de instncias, ocorrncias em ambas


as entidades, que no participam de nenhum relacionamento, ou seja, no esto
relacionadas.

Seriam de fato, se um funcionrio fosse Alocado a mais de um Projeto, mas


como um funcionrio alocado a um projeto somente, estes dados so informaes
inerentes ao funcionrio, pois possuem uma nica existncia para cada ocorrncia de
Funcionrio, que esteja relacionado com o projeto.
Da mesma forma que na entidade Funcionrio, para que se estabelea o
relacionamento com a entidade Projeto, necessita do atributo Cdigo_do_Projeto em
sua estrutura.
Temos ento a seguinte estrutura de dados:

O funcionrio F4 no est alocada a nenhum projeto, assim como o projeto-P3


no possui nenhum funcionrio alocado.
Queremos dizer com isto, que a condicionalidade, ou melhor a opcionalidade
de um relacionamento tem tambm o seu grau de importncia no contexto, pois
permite que uma ocorrncia de projeto seja inserida na entidade Projeto sem que
exista a necessidade, a obrigatoriedade de j possuir funcionrios alocados
antecipadamente.
Assim como a insero de uma ocorrncia em Funcionrio, sem que esta
esteja previamente relacionada com uma ocorrncia em Projeto.
Na vida real, esta situao ocorre exatamente desta forma, pois em 99% dos
casos em anlise e projeto, os relacionamentos so condicionais no mnimo para um
dos lados do relacionamento.

6.3 - Valor Nulo


O desconhecido sempre nos assusta. Mas para entendermos o que um valor
nulo, o especialista Lvio Taufer apresentou, certo dia, uma forma simples de
compreendermos este valor: - Vamos analisar uma situao tpica de nosso dia-a-dia.
Se pararmos em frente a um supermercado, iremos observar diversas pessoas
saindo deste estabelecimento comercial. A maioria carrega nas mos sacolas ou
pacotes fechados que denominaremos de Compras.

Figura 6.2
Que existem ocorrncias de Funcionrio que no esto alocados a nenhum
projeto fato concreto, mas como podemos visualizar este fato?
QUAL O CONTEDO?
Vimos no captulo 5 que uma caracterstica do relacionamento um-para-muitos
o fato de ele necessitar da existncia de chave estrangeira em uma das entidades.

Para ns que estamos ali parados, olhando a movimentao, qual o valor do


contedo daquelas sacolas e pacotes? Nulo.

Tomarmos como regra geral, que sempre que existir um relacionamento com
cardinalidade de Um-para-Muitos, a referncia lgica (chave estrangeira), estar
colocada na entidade que possui o lado Muitos da cardinalidade.

Ora, todos iro concordar que desconhecido, ou seja, Nulo, porque no


sabemos o que existe dentro das sacolas e pacotes.

Em nosso exemplo, a ligao da entidade Funcionrio com a entidade Projeto


ser possvel de se efetuar atravs da insero do atributo Cdigo_do_Projeto (Chave
Primria de Projeto) na entidade Funcionrio.
E como devemos entender a opcionalidade do relacionamento com relao aos
valores dos atributos?
Para as ocorrncias da entidade Funcionrio que no estiverem relacionadas
com nenhuma ocorrncia de Projeto, o atributo tambm existir porm, o valor deste
atributo ser NULO, isto , uma informao desconhecida, inexistente.

Ento Nula a informao desconhecida, o dado no informado. Em Banco


de Dados, atributo tem valor Nulo, quando este dado no obrigatrio de se informar,
opcional. Quando no informamos nenhum valor para ele, torna-se seu valor Nulo.
E as ocorrncias de Projeto que no tm nenhuma ocorrncia de Funcionrio
relacionada?
O valor da chave de identificao destas ocorrncias (Chave Primria)
obviamente no estar constando como chave estrangeira (valor do atributo
Cdigo_do_Projeto na entidade Funcionrio) em nenhuma ocorrncia da entidade
funcionrio.
A observao do diagrama Entidade-Relacionamento e dos atributos de cada
objeto pode no ser suficiente para voc leitor, adquirir a viso espacial dos dados.

Para uma melhor compreenso de contedo, torna-se necessrio a utilizao


de uma simulao dos dados, criando-se as tabelas para as futuras necessrias ao
diagrama e colocando valores nos campos destas tabelas.

A tabela que representa a entidade Projeto, se agora analisada, em conjunto


com a tabela de instncias de Funcionrio, possibilita a visualizao da parcialidade do
relacionamento entre as entidades.

As tabelas a seguir apresentam a simulao das ocorrncias das entidades


Funcionrio e Projeto.

Existe na entidade Projeto uma ocorrncia ( projeto p-32) que no est sendo
referenciada por nenhuma ocorrncia da tabela da entidade Funcionrio, assim como a
entidade Funcionrio, possui uma ocorrncia que tm valor nulo para os atributos
relativos ao relacionamento com a entidade Projeto: Cdigo_do_Projeto,
Data_de_incio, e Tempo_de_Alocao, a ocorrncia do funcionrio Carlos Estevo.

Funcionrio
Matrcula Nome

Cdigo do
Projeto

Data de Incio
no Projeto

Tempo de
Alocao

L466

Pedro Antnio

P-25

12/12/91

16 meses

2322

Luiz Paulo Diniz

P-18

05/01/92

4 meses

7712

Carlos Estevo

NULO

NULO

NULO

4415

Slvia Cristina

P-18

18/04/92

Projeto
Cdigo do Projeto

Nome do Projeto

P-18

Projeto Phoenix

P-25

Projeto Minerva

P-32

Projeto Corrup (Cruzes!!)

P-55

Projeto Nova Ponte

P-203

Oramento 95

5 meses

Existem ocorrncias que justificam a cardinalidade Muitos-para-Um,


independentemente de existirem ocorrncias com cardinalidade Um-para-um.
Na tabela de instncias de Funcionrios apresentada, existe um Projeto e s
referenciado por uma ocorrncia de Funcionrio. Somente o funcionrio Pedro
Antnio est com cdigo de projeto P-25, mas como demos perceber, existe pelo
menos um caso de um projeto estar tendo seu
valor de Cdigo_do_projeto referenciado em mais de uma ocorrncia de
funcionrio, o que nos suficiente para estabelecer esta cardinalidade de muitospara-Um, entre Funcionrio e Projeto.

preciso, pelo apresentado nos exemplos, que tenhamos uma massa crtica de
dados para simularmos as ocorrncias dos mesmos no mundo real, para que a
definio de cardinalidades seja realizada, com segurana.
Agora vamos estudar outra situao neste mesmo caso.
Se por exemplo, neste caso, a empresa informa que um funcionrio pode atuar
em mais de um projeto, ou melhor, est alocado a mais de um projeto
simultaneamente.
Vamos ver como ficaria o nosso modelo de dados, quais alteraes iria sofrer.
Teramos um relacionamento do tipo Muitos-para-Muitos, conforme o diagrama da
figura 6.3.

Figura 6.3
Como j estudamos na definio de relacionamento com cardinalidade
Muitos-para-Muitos, este tipo de relacionamento tem a caracterstica de possuir
campos para represent-lo, informaes inerentes ao fato, ao evento, que o
relacionamento, sendo no mnimo dois campos, que so as chaves primrias das
entidades relacionadas.
Neste caso em estudo, os dados Data_de_incio_no_Projeto e
Tempo_de_Alocao_no_Projeto, so informaes relativas ao evento que une
Funcionrio a Projeto, e como pode existir mais de um evento destes para cada
ocorrncia de Funcionrio, assim como de Projeto, estes dados deixam de ser nicos
por ocorrncia de Funcionrio, passando a ser mltiplos.

Como o nmero de ocorrncias do relacionamento indeterminado, no


podemos mant-lo como atributo de Funcionrio, pois no saberamos quantas
ocorrncias colocar destes atributos em Funcionrio, sendo necessrio o
desdobramento.
Logo, o relacionamento Alocado, passa a ter uma existncia fsica, ou seja,
uma tabela o implementa.
As estruturas de dados correspondentes ao modelo figura 6.3 ficam assim
delineadas:
Entidades:

Atributos:

Funcionrio

Matrcula_Funcionrio
Nome_Funcionrio
Cdigo_Projeto
Nome_Projeto

Projeto

Relacionamento:

Atributos:

Alocado

Matrcula_Funcionrio
Cdigo_Projeto
Data_Incio_no_Projeto
Tempo_de_Alocao

relacionamento Alocado deve ser igual ao valor do campo Cdigo_do_Projeto na


entidade Projeto, conjuntamente.
Quando isto acontecer com uma ocorrncia de Funcionrio, uma ocorrncia de
Alocado e uma ocorrncia de Projeto, estaremos relacionando as duas entidades que
so Funcionrio e Projeto.
Vamos ento visualizar estes fatos na simulao das tabelas relacionais que
representam esta realidade.
Funcionrio:
Matrcula

Nome

Data_Admisso

1466

Pedro Antnio

12/05/90

2322

Luiz Paulo Diniz

18/06/91

7712

Carlos Estevo

24/05/90

4415

Silvia Cristina

05/05/91

1216

Sandra Chi Min

01/02/92

1401

Maurcio Abreu

15/05/92

Projeto:
Cdigo_do_Projeto

Nome_do_Projeto

6.4 - Como se Efetiva este Relacionamento?

P-18

Projeto Phoenix

P-25

Projeto Minerva

O Relacionamento efetiva-se atravs de uma expresso relacionai que indica


como deve ser feita a comparao entre os campos comuns s Entidades, s que agora
com uma caracterstica diferente: a comparao realizada entre campos das entidades
e campos do relacionamento, formando uma expresso composta.

P-32

Projeto Corrup (Cruzes!!)

P-55

Projeto Nova Ponte

P-203

Oramento 95

Expresso de Relacionamento:
Funcionrio.Matrcula-funcionrio
=
Alocado.MatrculaFuncionrio e Alocado.cdigo-projeto = Projeto.cdigo-projeto.
Esta expresso quer nos dizer que o valor do campo matrcula na entidade
Funcionrio deve ser igual ao valor do campo matrcula no relacionamento Alocado, e
que o valor do campo Cdigo_do_Projeto no

Vamos ento simular relacionamentos Muitos-para-Muitos com estas duas


tabelas de ocorrncias das entidades, criando o relacionamento Alocado, e suas
possveis ocorrncias.

ALOCADO:
Data_Incio_
no_Projeto

Tempo_de_Alocao
no_Projeto

P-18

24/05/90

24 MESES

P-25
P-32
P-18
P-79
P-18
P-25

12/11/91
02/01/92
10/06/91
12/12/91
15/01/92
01/03/92

06 MESES
12 MESES
04 MESES
12 MESES
03 MESES
05 MESES

Matrcula
Funcionrio

Cdigo_do_Projeto

1466
1466
1466
7712
7712
4415
1216

J os projetos P-32 e P-79 possuem somente uma ocorrncia d


Funcionrio a eles relacionada.
Observem que interpretamos, ou melhor, realizamos a leitura pura simples
da tabela que representa este relacionamento, no considerando ainda neste instante,
as ocorrncias das duas entidades que no figuram n relacionamento. Estas
ocorrncias so irrelevantes para a interpretao d Relacionamento.
Observem o diagrama da figura 6.4, para que se estabelea uma regra formal
para determinao de um relacionamento Muitos-para-Muitos.

Vamos interpretar o mundo real, atravs da tabela de ocorrncias do


relacionamento Alocado:
A ocorrncia de Funcionrio com matrcula 1466 est alocada a trs (03)
Projetos, respectivamente P-18, P-25 e P-32, isto , Um Funcionrio
Alocado a Muitos Projetos;
A ocorrncia de Funcionrio com matrcula 7712 est tambm alocada a
muitos projetos (dois);
J as ocorrncias de funcionrio de matrcula 4415 e a de matrcula 1216
esto cada uma alocada a somente um projeto, pois s constam uma vez
dentro do relacionamento com campos Alocados.
Novamente lembramos que o fato de existirem ocorrncias relacionando-se
com a cardinalidade Um-para-Um no invalida a cardinalidade bsica do
relacionamento, uma vez que possumos ocorrncias que realizam a cardinalidade
Muitos-para-Muitos.
sempre muito importante que se efetue a leitura do modelo de dados em dois
sentidos, para compreenso perfeita da realidade. Ento vamos agora analisar a
situao por outro sentido de leitura do relacionamento:
O projeto de cdigo P-18 possui Muitas ocorrncias de Funcionrio a ele
alocadas, ou seja, respectivamente 1466, 7712 e 4415;
Assim como o projeto de cdigo P-25 possui tambm muitas ocorrncias de
Funcionrio a ele relacionadas (1466 e 1216);

Figura 6.4

7.1 - Relacionamentos entre Mltiplas Entidades


At o momento, neste livro, estudamos e analisamos situaes em que as
entidades se relacionavam aos pares. Este o princpio de descoberta dos
relacionamentos na construo de um modelo de dados: analisar as entidades aos
pares.
Entretanto um relacionamento pode existir envolvendo mais de duas
entidades, que podem ser trs, quatro, ou uma quantidade indeterminada de entidades
que o fato do relacionamento envolve.
Os relacionamentos entre mltiplas entidades expressam um fato em que todas
as entidades ocorrem simultaneamente, ou seja, todas as ocorrncias do
relacionamento possuem, sempre, ligaes com todas as entidades envolvidas no
relacionamento. No pode existir de um relacionamento triplo, em um determinado
momento, se transformar em duplo.
Vamos observar ento o diagrama da figura 7.1 que apresenta uma situao de
relacionamento ternrio que envolve trs entidades simultaneamente.

Figura 7.1

Para podermos descobrir as cardinalidades do relacionamento ternrio da


figura 7.1, devemos proceder da seguinte forma:
Separar a entidade ALUNO e analisar o par PROFESSOR, DISCIPLINA.
Para cada par PROFESSOR / DISCIPLINA podemos ter de 1 at N
ALUNOS relacionados;
Separar a entidade PROFESSOR e analisar o par ALUNO, DISCIPLINA.
Para cada par ALUNO / DISCIPLINA podemos ter 1 e somente 1
PROFESSOR relacionado;
Separar a entidade DISCIPLINA e analisar o par PROFESSOR, ALUNO.
Para cada par PROFESSOR / ALUNO podemos ter de 1 at N
DISCIPLINAS relacionadas.
Relacionamento mltiplo com mais de quatro entidades relacionadas
extremamente difcil de se encontrar na realidade do dia a dia. Quando voc encontrar
com algum fato que d origem a um relacionamento mltiplo, analise com cuidado,
pois o mesmo pode ser desmembrado em mais de um relacionamento. A
implementao de relacionamento mltiplo em bancos de dados torna o trabalho de
manipulao bastante complexo.

7.1.1 - Relacionamentos Mltiplos Muitos-para-Muitos


No diagrama da figura 7.1, temos a seguinte realidade descrita:
Quando um aluno est matriculado em uma disciplina, este tem sempre um
professor;
Um aluno pode estar matriculado em vrias disciplinas;
Uma disciplina tem vrios alunos, e somente um professor;
Um professor leciona uma disciplina para vrios alunos.
Este relacionamento ternrio, pois envolve trs entidades simultaneamente.
Observem que quando ocorrncias de duas das entidades se relacionam,
obrigatoriamente relaciona-se a elas uma ocorrncia da terceira entidade.

O exemplo da figura 7.2 possui uma cardinalidade Muitos-para-Muitos, tendo


a terceira entidade envolvida, uma cardinalidade de participao neste relacionamento
tambm de muitos.
Vamos analisar o diagrama de instncias deste relacionamento (figura 7.3), para
que se possa melhor entend-lo, e aps construir as tabelas com daos para as entidades
e os relacionamentos.

Vamos observar
relacionamento ternrio:

as

tabelas

que

simulam estes

Professor (Entidade)

objetos

do

Aluno (Entidade)

Cdigo_Professor

Nome_Professor

Nmero_do_Aluno

Nome_do_Aluno

12

Antnio Furtado

120

Carlos Antnio

11

M. de Medeiros

122

Lus Carlos

14

Juarez Antnio

123

Silvia Regina

45

Joo Clvis

124

Irene Maria

66

Celso Bressany

200

Pedro Lus

Cursam (Relacionamento)

Disciplina (Entidade)

Cdigo_Professor

Nmero_Aluno

Cdigo_da
Disciplina

Cdigo_da
Disciplina

Nome_Disciplina

Colocamos no diagrama de instncias, ocorrncias em cada uma das entidades


envolvidas que no esto participando do relacionamento.

14

120

D24

D24

Matemtica I

A interpretao correta deste tipo de relacionamento nos apresenta um ponto


de interseo das trs ocorrncias das entidades envolvidas em cada evento de
relacionamento, caracterizando uma tabela (CURSAM) para representar este tipo de
relacionamento, que tem ento cardinalidade de Muitos-para-Muitos.

14
14

123
122

D24
D24

D55
D66

Fsica Aplicada
Laboratrio Fsica II

11

200

D27

D99

E. P. Brasileiros II

11

122

D27

D27

CobolI(Uuhgh)

66

120

D99

66

123

D99

45

120

D66

Figura 73

Teramos neste caso, as seguintes estruturas para as entidades e o


relacionamento:
ENTIDADE:

ATRIBUTOS:

CONEXES:

ALUNO

Nmero_do_Aluno
Nome_do_Aluno Data
da Matrcula
Cdigo_Disciplina
Nome Disciplina
Cdigo_Professor
Nome Professor
Nmero_do_Aluno
Cdigo_Professor
Cdigo_Disciplina

Com CURSAM 1:N Parcial

DISCIPLINA
PROFESSOR
Cursam

Com CURSAM 1:N Parcial


Com CURSAM 1:N Parcial
com Aluno
N:l com
Professor N:l com
Disciplina N:l

Observando a tabela de dados do relacionamento Cursam, podemos ver que


existem ocorrncias de Aluno que no figuram no relacionamento, assim como
existem ocorrncias de Professor que tambm no figuram, e igualmente Disciplina,
colocando a opcionalidade no relacionamento em relao s ocorrncias de cada
entidade.
No entanto podemos observar que sempre que existe uma ocorrncia no
relacionamento, esta apresenta referncia s trs entidades, no existindo, Por
exemplo, nenhuma ocorrncia somente com professor e disciplina.

7.1.2 - Relacionamentos Temrios Um-para-Muitos


No diagrama da figura 7.4, apresentado um relacionamento de Um-paraMuitos entre Funcionrio, Projeto e Mquina.
Este relacionamento est retratando a seguinte realidade:
Um funcionrio trabalha somente em um Projeto, e um Projeto pode ter
somente um funcionrio trabalhando nele. Quando um funcionrio trabalha em um
projeto, ele tem um Supervisor. Um Supervisor pode supervisionar muitos
funcionrios que esto trabalhando em algum projeto.
Vamos estudar com carinho este caso, j que est nos apresentando uma
cardinalidade de Um-para-Um entre duas das entidades, e de Muitos-para-Um em
relao terceira entidade envolvida.

Resumindo, decompomos o relacionamento em dois fatos, ou seja,


supervisor controla as atividades de muitos funcionrios alocados projetos.
No somos partidrios da utilizao de relacionamentos mltiplos,
considerar que eles no espelham claramente uma realidade, j que como podemos
observar, em um relacionamento desta natureza temos sempre dl fatos envolvidos.
Vamos visualizar como ficam as estruturas de dados destes objtos para este
exemplo.
ENTIDADE

ATRIBUTOS

Funcionrio

Cdigo_Funcionrio
Nome_Funcionrio
Cdigo_Projeto
Cdigo_Supervisor
Cdigo_Projeto
Nome_Projeto
Cdigo_Supervisor
Nome_Supervisor

Projeto
Supervisor

Relacionamento

Expresso

Trabalham

Funcionrio_Codigo_Projeto=Projeto.Codigo_Projeto
Funcionrio.Codigo_Supervisor=Supervisor.Codigo_Supervisor

A expresso de relacionamento, por ser composta, explicita a


obrigatoriedade da existncia de trs elementos no relacionamento.
Figura 7.4
Devemos atentar para a realidade que est sendo retratada, ou seja, um
supervisor supervisiona as atividades de um funcionrio no projeto, e no
supervisiona o projeto em si. Ento:
Lus est alocado no Projeto Ponte do Rio Ca e tem como supervisor
Slvio;
Carlos Alocado no Projeto Reforma de Viadutos tem como seu Supervisor
Antnio Pedro;
Antnio Pedro supervisor de Carla no Projeto Braslia ("mais um rumo
ao Planalto").

7.2 - Relacionamentos Binrios de Um-Para-Um


Os relacionamentos de cardinalidade Um-para-Um existi
efetivamente no mundo real. A questo : Como implement-los atravs referncias
lgicas?
Este_tipo de relacionamento tem sua existncia sempre questionada pois
seguidamente resultante de um erro de interpretao do contexto das entidades
existentes em um modelo, devendo por isto termos ateno redobrada sempre que
nos depararmos com um deles.

Vejamos ento os diagramas propostos na figura 7.5.

Mas a questo que gostaramos de apresentar aos leitores a seguinte: Onde


colocamos a chave estrangeira para efetivar, logicamente, este relacionamento?
Sendo um relacionamento em que ambos os participantes possuem grau de
cardinalidade Um, a referncia lgica da chave estrangeira pode estar colocada em
qualquer um dos lados do relacionamento. Como orientao de segurana e
estabilidade, sugerimos sempre que esta chave estrangeira seja colocada no lado que
tem a possibilidade semntica de evoluir, no futuro, para uma cardinalidade Muitos.
O questionamento da existncia deste relacionamento ocorre quando, por um
erro de interpretao da realidade, criamos duas entidades em que ambas descrevem
ou caracterizam um mesmo objeto.

Figura 7.5
No primeiro exemplo, temos Nota Fiscal relacionada com Pedido de Um-paraUm, isto , uma ocorrncia de Nota Fiscal atende (relaciona-se) a uma ocorrncia de
Pedido. Na realidade, queremos dizer que atravs de uma Nota Fiscal remetemos
somente um Pedido solicitado. Independente da existncia de outros pedidos, uma nota
fiscal s remete um pedido. Por outro lado, um pedido s remetido por uma nica
nota fiscal.

Neste caso, podemos visualizar que os atributos das duas entidades


caracterizam um nico objeto, e ainda mais, suas chaves identificadoras, as chaves
primrias, so idnticas.
Vejamos o exemplo no diagrama da figura a seguir.

Que implicao tem este relacionamento no mundo real?


Este relacionamento restritivo quanto a operacionalidade do evento remeter,
estabelece uma regra significativa e ampla: Um pedido nunca pode ser entregue
parcialmente, j que isto implicaria em associar-se a ele mais de uma nota fiscal, e por
outro lado, uma nota fiscal jamais poder remeter dois ou mais pedidos, pela mesma
implicao.
No segundo diagrama, apresentado temos uma entidade, que contm os carros
de uma empresa, e outra entidade o elenco de motoristas da mesma organizao.
O relacionamento est afirmando que um carro da empresa somente pode ser
dirigido por um nico motorista e que um motorista somente poder dirigir um nico
carro.
O terceiro exemplo de diagrama apresenta uma situao tpica de um credirio
de uma loja, onde temos o cliente e sua conta corrente de credirio.
Sendo que um cliente somente tem uma conta corrente na loja, e por sua vez
cada conta corrente existente pertence a somente um cliente.

O exemplo tpico, pois quando estamos realizando nossos primeiros


trabalhos de modelagem, cria-se uma entidade chamada Estoque para relacionar-se
com Produto (Um-para-Um), por considerarmos o aspecto fsico do Estoque como
distinto de Produto.
Observando com mais ateno, podemos chegar soluo correta. Se dado um
produto, este possui somente uma quantidade em estoque, considerando que esta
quantidade representa o quanto temos do produto na empresa, o atributo quantidade
em estoque , na realidade, nada mais do que um dos atributos de produto.
necessrio usar um relacionamento 1:1? No.

Quando estamos realizando o Projeto Fsico de Banco de Dados, m surgir


situaes em que iremos efetivamente colocar uma vertical da entidade, mas por
um motivo nada conceituai. Objetivo de uma decomposio desta ordem poderia
ser, por exemplo: a de concentrao de acessos entidade Produto, sendo que
nem todos acessos estejam interessados em recuperar o dado quantidade em que.

Figura 7.6
Todas as notas fiscais tm, no mnimo, um item de nota fiscal relacionado;

Os relacionamentos Um-para-Um podem ser utilizados quando estivermos


com entidades complementares de outra, como nos casos de generalizao de
dados.

7.3 - Usar N :N ou Construir 2 vezes 1:N - A Escolha


Como modelagem de dados, antes de ser uma tcnica tambm uma pois
reflete a interpretao de um ser humano da realidade que o cerca, podemos ter
uma mesma situao representada de formas diferentes.
Desta forma, a semntica de um modelo de dados pode, freqentemente,
esconder em conjuntos de relacionamentos Um-para-Muitos, relacionamento (na
realidade) Muitos-para-Muitos.

Todo Item de Nota Fiscal est relacionado a uma Nota Fiscal;


Todo Item de Nota Fiscal est relacionado a um Produto.
A entidade Item de Nota Fiscal contm em suas ocorrncias, os registros dos
itens que constam em uma nota fiscal. Vejamos ento as estruturas de dados que
temos no exemplo:
ENTIDADE

ATRIBUTO

RELACIONAMENTOS

Nota Fiscal

Nmero_da_Nota_Fiscal
Cdigo_do_Cliente_da_Not a
Data_da_Nota

Item de Nota Fiscal

Nmero_da_Nota_Fiscal
Cdigo_do_Produto
Quantidade_Produto

Produto

Cdigo_Produto
Descrio_Produto
Unidade_Produto
Preo_Unitrio_Produto
Quantidade_Estoque_Produto

Com Item de Nota Fiscal 1:N total


(todas as notas tm no mnimo um
item de nota fiscal
relacionado)
Com Nota Fiscal 1:1 total
(todo item de Nota Fiscal est
relacionado a uma Nota Fiscal)
Com Produto 1:1 total
(todo item de Nota Fiscal est
relacionado a um Produto)
Com Item de Nota Fiscal 1:N
Parcial

Vamos utilizar para esta anlise a figura 7.6.

Colocamos o relacionamento entre Produto e Item de Nota Fiscal como


parcial, no sentido de Produto para Item de Nota Fiscal, porque nem todos produtos
so referenciados por uma ocorrncia de Item de Nota Fiscal.

ENTIDADE

ATRIBUTOS

RELACIONAMENTOS

Produto

Cdigo_Produto
Descrio_Produto
Unidade_Produto
Preo_Unitrio_Produto
Quantidade_Estoque_Produto

Com Nota Fiscal atravs de


Contm 1: NParcial
(Nem todos os produtos
esto contidos em uma
Nota Fiscal)

J, por sua vez, o relacionamento entre Item de Nota Fiscal e Produto, no


sentido de Item para Produto total, porque todo item de uma nota fiscal
obrigatoriamente uma ocorrncia de Produto.
Apesar de entidade Item de Nota Fiscal possuir uma nomenclatura bastante
semntica, est na realidade exercendo uma funo de relacionamento no modelo de
dados.
Atravs desta entidade, estamos, na verdade, relacionando Nota Fiscal e
Produto. Poderamos substitu-la por um relacionamento de Muitos-para-Muitos, pois
Nota Fiscal Contm Produtos.
Olhando atentamente o diagrama da figura 7.6, pode-se notar que a entidade
Item-de-Nota-Fiscal apresenta uma convergncia de cardinalidade Muitos nos dois
relacionamentos ligados a ela. Este fato pode caracterizar um relacionamento de
Muitos-para-Muitos. Vrios autores denominam esta entidade com uma tipologia
muito clara: Entidade Associativa, aquela que associa, que relaciona.
A figura 7.7 apresenta o Diagrama E-R, com a utilizao de um
Relacionamento no lugar da entidade associativa.

RELACIONAMENTO

ATRIBUTOS

CONEXO

Contm

Nmero_da_Nota
Cdigo_do_Produto
Quantidade_Produto

com Nota Fiscal (total) e


com Produto (total)

A expresso do relacionamento seria ento:


Nota_Fiscal. Nmero_da_Nota = Contm.Nmero_da.Nota, e;
Contm.Cdigo_Produto = Produto.Cdigo_Produto
Este processo de comparao atravs de uma expresso lgica denominado
de navegao no modelo de dados.
Esta navegao, executada quando temos uma expresso composta para
comparao dos campos, denomina de navegao disjunta, pois executamos a
comparao na seqncia linear do relacionamento. Comparamos primeiro o
Nmero_da_Nota na entidade Nota_Fiscal com o nmero da nota no relacionamento
Contm e na seqncia comparamos o Cdigo_Produto no relacionamento Contm
com um Cdigo_Produto na entidade Produto.

Figura 7.7
A estrutura de dados do modelo e sua lgica relacionai no dicionrio de dados
ficar da seguinte forma:
ENTIDADE

ATRIBUTOS

RELACIONAMENTOS

Nota Fiscal

Nmero_da_Nota_Fiscal
Cdigo_do_Cliente_da_Nota
Data_da_Nota

Com Produto atravs de Contm 1:N


total
(Todas as Notas tm no mnimo um
produto fiscal relacionado)

Agregao

8.1 - A Decomposio de um Relacionamento


Existem momentos em que temos uma viso dos dados que nos deixa em
duvida de como representar um fato que est relacionado a outro fato Isto eqivaleria a
dizer que um relacionamento est relacionado a outro. Mas conceitualmente, no
existem relacionamentos entre relacionamentos. uma inverdade conceitual. O que
existe no mundo real, so relacionamentos

Vamos iniciar nosso estudo com um caso policial como se


estivssemos lendo um romance policial moderno, localizado Fluminense que tanto
assistimos nos telejornais. Uma tpica (credo!) chacina ou extermnio de menores
(arhg, quando isto vai parar?)
provas tais como as armas do crime.
vtimas assassinou vrias Podemos, nessa situao, afirmar que um criminoso
assassinou vrias vitimas e que uma vitima foi assassinada por vrios criminosos j que
no
frente a frente com um relacionamento de Muitos-para-Muitos. j participaram do fato
Estamos

Figura 8.1

O diagrama da figura 8.1 apresenta um impasse: temos a entidade Meliante, e


a entidade Vtima, relacionadas com cardinalidade Muitos-para-Muitos. Aparece ento
em cena uma terceira entidade, denominada de Arma, que contm as armas
apreendidas. Como iremos ligar as ocorrncias de Arma, ao fato, ao evento do
Assassinato, este relacionamento com campos?
A entidade Arma est com suas ocorrncias relacionadas a Meliante, ou est
relacionada a Vtima?
Se ligarmos Arma a Meliante, no podemos afirmar que ela foi utilizada no
assassinato de uma Vtima. Se ligarmos Vtima, mais difcil torna-se estabelecermos
uma relao com o Assassino.
Como resolver esta questo?
relativamente simples esta soluo, basta que nos detenhamos em retratar a
realidade da mesma forma como ela expressa em linguagem natural, ou seja:

So na realidade dois relacionamentos para retratar um fato


completo.
O que desejamos relacionar uma ocorrncia de Arma, com I ocorrncia
do fato, do relacionamento Assassina (Se "A Gata Triste raciocinasse assim,
perdiam a graa, todos os seus livros!).
O relacionamento Assassina, como colocamos na situao, possuicampos.
Vamos ento relacionar uma ocorrncia deste relacionamento uma ou vrias
ocorrncias da entidade Arma, criando um relacionam entre Assassina e Arma,
que denominamos de Usa.
A figura 8.3, mostra a representao da agregao relacionada
Arma.

Um Meliante Assassina Vtimas. Quando ele Assassina Vtimas, Usa


Armas. Esta realidade apresentada graficamente (modelo E -R) na figura
8.2.

Figura 83
Interpretando o diagrama Entidade-Relacionamento, temos enxergar
o conjunto resultante de Meliante Assassina Vtima, relacionado c o conjunto das
ocorrncias da entidade Arma. Na realidade, estamos lei este conjunto resultante
como se ele mesmo fosse uma entidade.
Figura 82
Existem, nesta expresso da realidade, dois verbos inter-relacionados, ou seja,
existe um relacionamento entre objetos dependentes um da existncia de outro.

Quando deixamos de lado um pouco o conceito entidade, podemos


interpretar como o objeto Assassinato (Meliante Assassina Vtima relacionado com
Arma.

Conseguimos desta forma ligar a Arma cena do Crime (Assassinato).


Para melhor entendimento vamos conhecer as estruturas de atributo das entidades
envolvidas neste caso policialesco, e de seus relacionamentos

DICIONRIO DE DADOS:

VTIMA

ENTIDADE

ATRIBUTOS

RELACIONAMENTO

MELIANTE

Registro do Meliante
Nome Oficial
Codinome Idade

VITIMA

Num. documento da vtima


Nome do infeliz
Sexo
Idade
Num. Apreenso da Arma
Marca da arma Tipo da arma
Nmero de srie

Com Vtima atravs de Assassina


1:N (Parcial)
(Nem todo Meliante assassinou uma
Vtima)
Com Meliante atravs de Assassina
1:N (Total)
(Toda Vtima foi assassinada por um
Meliante)
Com Assassina atravs de Usa 1:N
(Parcial)
(Nem toda arma apreendida foi usada num
assassinato)

ARMA

RELACIONAMENTO

ATRIBUTOS

CONEXES

ASSASSINA

Data do crime
Num. documento da Vtima
Registro do Meliante
Num. documento da Vtima
Registro do Meliante Num de
apreenso da arma

Com Meliante N:l (Total)


Com Vtima N:l (Total)

USA

NOME

SEXO

IDADE

111111111

Antnio Moacir

58

243387569
806578913
684714325

Jlio A. Macedo
Sazaina Moraeis
Ana Luiza Martins

M
F
F

35
24
32

ARMA
NMERO

MARCA

TIPO

SRIE

191

Taurus

Pistola

A656B767

192

Magnus

Pistola

Mg457T8V9

As tabelas apresentadas a seguir mostram apenas uma parte do


relacionamentos possveis para as ocorrncias das entidades Meliante Vtima,
considerando-se que, os casos que no esto relacionados, no foram at esta edio
solucionados.

Com Assassina N:l (Total)


Com Arma N:l (Total)

Vamos agora observar as tabelas a seguir, que nos apresentam a simulao das
tabelas representativas das entidades e dos relacionamentos envolvidos em nossa
novela policial.

DOCUMENTO

ASSASSINA
DATA

VTIMA

MELIANTE

11/02/92

111111111

121212

14/03/92
03/04/92

243387569
806578913

121212
334455

USA
MELIANTE
REGISTRO

NOME

CODINOME

IDADE

121212

Joo Pedrum

Jo Caveira

33

221134
334455
212378
335588

Luiz Cabrum
Carlos S
Srgio Bruks
Tonho Silva

L Vampiro
Cadinhos Mau
Balaustre
Tonho Faco

42
18
26
19

VTIMA

MELIANTE

ARMA

111111111

121212

191

111111111

121212

192

O fato de um crime associar duas armas ao mesmo meliante, um exerccio


de imaginao, mas que nos permite observar que a agregao admite que se tenha
uma cardinalidade de Muitos-para-Muitos entre o objeto resultante do relacionamento
entre Meliante e Vtima com a entidade Arma.

QC

Agora que j vimos uma realidade literria, vamos trabalhar um caso mais
normal em termos de sistemas de aplicao.

8.2 - Agregao e Cardinalidade


Seja a situao de relacionamento Muitos-para-Muitos que havamos estudado
quando da anlise deste tipo de relacionamento, entre a entidade Funcionrio e a
entidade Projeto.

Diferentemente do caso anterior onde uma Arma era usada por I criminoso
somente em Assassinato, agora temos a colocao de que uma mquina pode estar
sendo utilizada por diversos funcionrios atuando em projetos
Como devemos tratar esta situao?
Lendo, a situao fica mais simples, seno vejamos: um Funcionrio
Atuando em Um Projeto caracteriza uma ocorrncia de Alocado e e ocorrncia
utiliza uma ou nenhuma Mquina, por outro lado uma Mquina pode ser utilizada
por "n" Funcionrios atuando em Projeto.
Temos ento um relacionamento de um-para-muitos entre Mquinas a viso
de Funcionrio Alocado Projeto.
Como existe uma cardinalidade de Um-patra-Muitos I relacionamento
Utiliza, este no ser um relacionamento com campos, sendo realizado pela
execuo de uma expresso de comparao lgica.
Vamos ento observar as estruturas do dicionrio de dados para melhor
compreendermos as ligaes lgicas e como se realizam.
DICIONRIO DE DADOS:
ENTIDADE

ATRIBUTOS

RELACIONAMENTO

Figura 8.4

FUNCIONRIO

Um Funcionrio Atua em muitos Projetos e, um Projeto tem trabalhando nele


muitos Funcionrios, conforme o diagrama E-R da figura
8.4.

Com Projeto atravs de Atual 1:N


(Parcial)

PROJETO

Quando um Funcionrio est trabalhando em um Projeto, ele pode Utilizar


uma ou nenhuma Mquina para a realizao de suas atividades.

MQUINA

Matrcula Funcionrio
Nome Funcionrio Data
Admisso
Cdigo Projeto
Nome Projeto
Verba Projeto
Cdigo Mquina
Nome Mquina

Novamente temos uma situao de um evento decorrente de outro, e ainda


com uma caracterstica adicional, que a opcionalidade do segundo evento acontecer.

RELACIONAMENTO

A viso agregada de Funcionrio Alocado Projeto, permite-nos tratar este


bloco de modelo, como sendo uma entidade consolidada por um fato, mas vejam bem
que estamos considerando um bloco, e que este bloco ento relaciona-se com
Mquina, opcionalmente.

Com Funcionrio atravs de Atua 1:N


(Parcial)
Com Atua atravs de Utiliza 1:N
(Parcial)

ATRIBUTOS

CONEXES

RELACIONAMENTO
DO BLOCO
AGREGADO

Cdigo_Projeto
Matrcula_Func
Cd_Mquina

Com Projeto N:l


(Total)
Com Funcionrio
N:l (Total)

Com mquina atravs


de utiliza N:l (Parcial

Agregao

RELACIONAMENTO

ATRIBUTOS

UTILIZA

CONEXES

RELACIONAMENTO
DO BLOCO
AGREGADO

Com Alocado N: 1
Com Mquina 1:1

Este caso de agregao apresenta da mesma forma uma decomposio de um


relacionamento em dois, pois ao analisarmos a situao, encontraremos sempre dois
fatos, dois eventos acontecendo, sendo um dependente de outro.
Funcionrio Utiliza Mquina, "quando" Alocado a Projeto. Este tipo de
temporalidade representado pela palavra "quando" que nos d a pista, o caminho
correto para a soluo do caso.
Figura 8.5
Sempre que nos depararmos com um relacionamento envolvendo mais de duas
entidades, devemos questionar as entidades que se ligam em um relacionamento
bsico, atravs da colocao da questo:
Quando acontece o fato?
Vamos ento conhecer um outro caso de agregao, agora j visualizando uma
temporalidade, e executando o questionamento temporal que discutimos.
Seja ento a seguinte situao:
Um mdico atende a muitos pacientes, que o consultam, e um paciente pode
realizar consultas com muitos mdicos. Sempre que um paciente consulta um mdico,
este fornece uma receita, que pode ter um, ou vrios remdios.

I
A figura 8.5 nos mostra o diagrama E-R para esta viso dos dados.
Este caso envolve o mesmo tipo de ligao dos outros dois, mas detalhando-se
agora que esta viso de um relacionamento com o agregado de Muitos-para-Muitos.
Interpretando o diagrama temos:
Um Remdio receitado em muitas Consultas;
Uma Consulta receita muitos Remdios.
Mas o que esta Consulta da qual estamos falando?
nada mais nada menos que o relacionamento Atende existente entre a
entidade Mdico e a entidade Paciente, que possui cardinalidade de Muitos-paraMuitos.
Vamos observar ento como fica a construo do dicionrio de dados para este
exemplo em pauta.
Observem, leitores, que agora neste caso temos trs entidades se dois
relacionamentos com campos, para solucionar o problema.

DICIONRIO DE DADOS:
ENTIDADE

ATRIBUTOS

RELACIONAMENTOS

MDICO

Cdigo Mdico
Nome Mdico
Nmero Paciente
Nome Paciente
Cdigo Remdio
Nome Remdio

Com Paciente atravs de Consulta 1:N


(Parcial)
Com Mdico atravs de Consulta 1:N
(Parcial)
Com Consulta atravs de Receita 1:N
(Parcial)

PACIENTE
REMDIO

RELACIONAMENTO

ATRIBUTOS

CONEXES

ATENDE

Cdigo Mdico
Nmero Paciente
Data Consulta

Com Mdico N:l Com


Paciente N:l Com Remdio
atravs de Receita 1:N

Cdigo Remdio
Cdigo Mdico
Nmero Paciente
Posologia Remdio

Com Remdio N:l


Com Consulta N:l

RECEITA

8.3 - Restries para Uso de Agregao


Queremos que o leitor observe e grave em sua mente a regra bsica para que
se possa utilizar uma Agregao em um modelo de dados:

Figura 8.6
S podemos utilizar agregao quando temos um relacionamento c Muitospara-Muitos, que representa um fato, pois caso contrrio a terceira entidade
envolvida estar relacionada sempre com uma das entidades em questo (figura 8.6).
Para melhor exemplificar, e permitir a compreenso desta restrio vamos
considerar que o relacionamento entre Funcionrio e Projeto, estudado
anteriormente, tivesse uma cardinalidade de Um-para-Muitos, ou seja, Um Projeto
tem muitos Funcionrios, mas um Funcionrio trabalha somente em um Projeto.
Ora, se o funcionrio s trabalha em um Projeto, a mquina ou a mquinas
que ele utiliza esto relacionadas diretamente a ele, uma vez que ele s possui uma
existncia de relacionamento com projeto.
Sempre que tivermos relacionamentos de cardinalidade Um-para-Muitos, a
terceira entidade est relacionada com uma das duas (Figura 8.7).

ERRADO

Agregao

realidade, e aps, adaptarmos esta viso que obtemos da realidade a( esquema


permitido pelo SGBD.
Vamos ver a situao do exemplo Funcionrio Alocado em Projeto Usa
Mquina, em um banco de dados qualquer, supondo que ele no implemente< este
conceito de Muitos-para-Muitos e agregao. Mostraremos que a viso lgica nunca
deve ser superada pela viso fsica, quando da anlise modelagem conceituai de

Figura 8.1
Mesmo que se interprete como um relacionamento decorrente do evento, este
evento s ocorre uma vez, logo podemos relacionar o terceiro objeto participante com
o objeto que tem cardinalidade muitos.
Por favor, leitores, gravem bem: somente utilizamos agregao quando temos
relacionamentos de cardinalidade Muitos-para-Muitos.
Vamos agora ento analisar uma situao que faz muitos autores negarem o
conceito de agregao e evitarem sua utilizao.

dados.
Figura 8.8
A figura 8.8 apresenta o primeiro estgio do desdobramento lgico de
relacionamento Muitos-para-Muitos, utilizando-se uma entidade associativa. para
represent-lo.
A leitura do diagrama agora se faz como Funcionrio Tem Alocao
Associada a Projeto.
Temos ento o desdobramento do relacionamento Alocado, em dois
relacionamentos simples: Tem e Associado.

8.4 - Como Utilizar Agregao por Implementao de


Entidades Associativas, (ou meu Banco de Dados no
Permite todas as Extenses E-R)
Existe uma preocupao, que muitas vezes leva os analistas e projetistas de
bancos de dados a abandonarem suas vises de dados, e atuarem diretamente no
modelo fsico, deixando de lado o modelo lgico.
Uma destas preocupaes referente ao Sistema Gerenciador de Banco de
Dados, que no permite ou no possui caractersticas que possibilitem a
implementao de solues de relacionamentos com campos, e ainda mais com
agregaes de dados.
Isto em nada afeta os trabalhos de modelagem, ou sequer impossibilita esta
forma de ver os dados. Devemos, isto sim, modelar de acordo com a

Sendo que os campos que pertenciam ao relacionamento Alocado agora


pertencem a uma entidade associativa denominada Alocao.
E como fica a ligao entre este evento antes representado por uma
relacionamento nico, com a entidade Mquina?
relativamente simples. Mquina relaciona-se da mesma forma com o evento,
independente deste ser representado por um relacionamento com campos ou uma
entidade, j que o importante no contexto o entendimento e a expresso de uma
realidade.
Mas e se o relacionamento entre Mquina e Alocao for mais um
relacionamento com campos, como em nosso exemplo anterior?
Novamente vamos desdobrar este relacionamento com campos em dois
relacionamentos com uma outra entidade associativa, para a efetivao do fato
dependente.

permitindo que se desenhe um esquema conceituai mais coerente com realidade do


negcio para o qual desenhamos um sistema.

8.5 - Relacionamentos entre Blocos do Modelo


J vimos at aqui que uma agregao de dados pode relacionar-se com outras
entidades, mas existe ainda a possibilidade de realizarmos relacionamentos de
qualquer grau entre dois blocos de agregao existente no modelo de dados.
Acreditem, os autores deste livro no enlouqueceram no Simplesmente
estamos procurando conduzir a modelagem de dados em sua forma mais pura,
buscando sempre uma eficincia e fidelidade do modelo d dados ao mundo real, e a
forma como ele expresso em linguagem natural, aquela que utilizamos quando no
estamos preocupados com Programas Mquinas e Softwares.
Vamos estudar ento esta extenso da utilizao de agregaes em um
modelo de dados.

Figura 8.9
Temos ento, como na figura 8.9, Mquina Usa Utilizao Possui Alocao.

FATO l

Proposital mente escrevemos a leitura do modelo em sua ordem inversa, para


que se possa destacar que este tipo de converso de modelo provoca sempre
cacofonismos semnticos, mas o modelo continua expressando uma realidade. Vamos
efetivar a leitura linear dos fatos, para ver o resultado que encontramos:
Funcionrio Tem Alocao Associada Projeto;
Alocao Possui Utilizao Usa Mquina.
, os leitores havero de concordar, resolve, mas que no fica muito
semntico, isto verdade, no fica mesmo.
Figura 8.10
O importante que se voc, leitor, utiliza um banco de dados que permite este
tipo de implementao (agregao e Muitos-para-Muitos), no deixe de utilizar, j que
em projetos de grande complexidade e volume de entidades e relacionamentos, o
modelo ficar extremamente sujo em termos de semntica para expressar uma
realidade. O ideal seria que todos os bancos de dados fossem construdos para permitir
esta implementao conceituai,

A figura 8.10 apresenta dois blocos distintos com relacionamentos Muitospara-Muitos em cada um, expressando dois fatos do mundo real.
O fato nmero 1 retrata uma situao que j estudamos, em que um mdico
atende a muitos pacientes, e um paciente faz consultas com muitos mdicos.
O fato nmero 2, aparentemente dissociado, representa uma Clnica Atua em
muitos Locais, sendo que em um Local Atuam muitas Clnicas.

Como as consultas mdicas no so realizadas no espao, deve ser possvel


associarmos o fato da Consulta a uma Localizao deste acontecimento.
A questo , quais as consultas realizadas pela ocorrncia X de Clnica no
Local Y?

Esta mesma situao pode, como j afirmamos, ser implementada com


desdobramento dos relacionamentos Muitos-para-Muitos em entidades associativas,
apesar de perder grande parte da simplicidade semntica desta soluo.

Podemos querer saber, por outro lado, em que Local e Clnica foi realizada
uma determinada consulta.
Isto nos conduz a afirmar que os dois blocos do modelo de dados no esto
realmente dissociados, que esto profundamente relacionados. Ento o que nos falta
representar a associao dos dois fatos.

Figura 8.12
A figura 8.12 apresenta o mesmo caso que estudamos, representado atravs da
utilizao de entidades associativas.
Um detalhe importante e que muitos projetistas esquecem, ou fingem
esquecer, que a fidelidade semntica dos dados e relacionamentos deve sempre ser
mantida, procurando-se dar nomenclaturas s entidades e relacionamentos que
expressem um sentido, evitando-se de todas as formas, a utilizao de siglas, tanto
para entidades quanto para relacionamentos, que impeam a leitura simples e natural
de um diagrama de Entidades e Relacionamentos.

A figura 8.11 nos apresenta a soluo, com o relacionamento existindo entre as


duas agregaes, atravs de Realiza.
Temos ento um relacionamento com cardinalidade de Um-para-Muitos entre
a agregao Localizao e a agregao Consulta.
A leitura do diagrama E-R reflete claramente agora o que acontece no mundo
real: uma Clnica Atua em muitos Locais, quando uma Clnica Atua m um Local
Realiza muitas Consultas, isto , Mdico Atende Paciente.

Auto-Relacionamento

9.1 - Introduo
Para que possamos entender bem este tipo especial de relacionamento,
devemos conceituar melhor o que auto-relacionar-se.
Nos dias atuais, muito se comenta sobre qualidade de vida. E um dos
comentrios mais ouvidos, visto que no somos psiclogos e nem pretendemos, de
que para se estar de bem com a Vida, devemos em primeiro lugar, estar de bem com
ns mesmos. Devemos nos auto-relacionar muito bem, gostar de si mesmo, antes de
tudo, para poder encarar a Vida de frente.
Estas afirmativas apresentam um auto-relacionamento de ns seres humanos
com ns mesmos, isto auto-relacionar-se.
Em nosso estudo, at certo ponto bem mais simples de entender o autorelacionamento, pois em uma classe de objetos, eles se relacionam entre si.
Em uma entidade, suas ocorrncias possuem relacionamentos prprios entre
elas.

9.2 - Auto-Relacionamento Um-para-Muitos


Auto-relacionamentos so, em verdade, representaes de estruturas de
hierarquias na maioria das vezes. Por exemplo, vamos considerar uma entidade
Pessoa, cujas ocorrncias so representativas de inmeras pessoas de um determinado
local. Pois bem, entre estas inmeras ocorrncias de pessoas

existem relacionamentos bem-definidos, como _filho_de. Isto , algumas pessoas so


filhas de outras pessoas.
Um outro exemplo seriam os funcionrios de um empresa. Entre estes
funcionrios existe uma relao de hierarquia. Podemos afirmar que alguns
funcionrios so gerentes de outros, que por sua vez so subordinados a um gerente.

Figura 9.1
A figura 9.1 apresenta um diagrama para a situao em que Uma Pessoa
possui Muitos Filhos, um relacionamento de cardinalidade Um-para-Muitos, mas um
auto-relacionamento, j que temos uma nica entidade envolvida.
E como este fato se efetiva logicamente?
Como j comentamos neste livro, da mesma forma que as certides de
nascimento referenciam o nome dos pais, estas ocorrncias estariam realizando
referncias lgicas a outras ocorrncias da mesma entidade.
Vamos definir o dicionrio de dados correspondente a esta situao para a
entidade Pessoa, mostrados nas tabelas a seguir.
ENTIDADE

ATRIBUTOS

PESSOA

Identificao_Pessoa Nome
Identificao_Pessoa_PAI
Identificao_Pessoa_ME

RELACIONAMENTO

EXPRESSO

Tem_PAI

Pessoa.Identificao_Pessoa_PAI =
Pessoa. Identif icao_Pessoa
Pessoa. Identificao_Pessoa_ME =
Pessoa.Identificao Pessoa

Tem_MAE

Seja ento a entidade Pessoa e seus auto-relacionamentos Tem_PAI e


Tem_ME, como enxergar estes dados em uma nica tabela? A soluo est
mostrada na tabela simulada apresentada na figura 9.2.
Tabela da Entidade Pessoa
IDENTIFICAO
PESSOA

NOME

IDENTIFICAO IDENTIFICAO
PESSOA_PAI
PESSOA_ME

1-68

Carlos Feliciano

null

null

1-99
1-29
1-45
1-34
1-55
1-78

Jussara Pinto
Cludia Bicoy
Pedro Luiz Bil
Cludio Carvil
Antnio Luiz
Orvandina

1-68
null
1-68
1-55
null
null

1-29
null
1-29
1-78
null
null

Figura 92
Pelo conceito de generalizao temos, na realidade, mltiplos subconjuntos de
dados, dentro da entidade Pessoa, tais como Filhos de Pai, e Filhos da Me
(desculpem a expresso!!!).
Brincadeiras parte, a leitura dos dados da tabela nos apresenta a
interpretao do mundo real que est retratada no diagrama da figura 9.3.

Figura 93
Jussara filha de Carlos Feliciano, pelo relacionamento Tem_Pai, e filha de
Cludia Bicoy pelo relacionamento Tem_Me.

A prpria interpretao do relacionamento mostra-nos que as ocorrncias da


entidade assumem papis diferentes conforme seu posicionamento no
relacionamento.
O diagrama que vimos at este instante no expressa estes papis. Este
conceito de papel exercido, funo, role em ingls, deve ser passado tambm para o
diagrama de entidades e relacionamentos, porque permite que se tenda o sentido do
relacionamento e qual tipo de participao no acionamento tem uma ocorrncia.
A figura anterior apresenta o diagrama E-R, agora com a forma de presso do
role, papis da entidade em cada lado do relacionamento.

Os campos deste relacionamento representam a estrutura de engenharia de um


produto.
A figura 9.4 apresenta este relacionamento, com os papis existentes
(componente e composto) em funo do relacionamento.
Outro aspecto importante entendermos como fica a estrutura dos atributos
pertinentes entidade Produto e ao relacionamento Compe (figura 9.5).
ENTIDADE

ATRIBUTO

PRODUTO

Cdigo_Produto
Descrio_Produto
Unidade_Produto

9.3 - Auto-Relacionamento Muitos-para-Muitos


Os auto-relacionamentos podem possuir qualquer um dos tipos de
cardinalidade. Vamos ento aprender a visualizar o tipo de cardinalidade Muitospara-Muitos.
muito comum este tipo de cardinalidade quando desejamos apresentar
composies de algum objeto, por exemplo:
N

RELACIONAMENTO

ATRIBUTO

COMPE

Cdigo_Produto_Composto
Cdigo_Produto_Componente
Quantidade_Participao_Componente

Figura 95
Vamos imaginar uma tabela com Produtos e uma tabela do
Relacionamento.
TABELA DE PRODUTOS

Figura 9.4
Em uma indstria, um produto composto de vrios outros produtos, e so
componentes. Por outro lado, um produto componente pode participar da
composio de muitos produtos.
Observem que estamos lidando com um nico tipo de objeto, Produto.
Temos ento um auto-relacionamento Muitos-para-Muitos, com campos, que
expressam composio de objetos.

PRODUTO

DESCRIO

UNIDADE

001
002
003
004
005
010
011
023
045
068
087

Terminal de vdeo
Tubo Imagem 14"
Caixa para terminal P22
Transformador XXX
Boto de controle
Gabinete para CPU 386
Boto dois estgios
Capa plstica para vdeo
Parafuso Phillips 3/4"
Cola Superbonder
Fita isolante borracha

pea
pea
pea
pea
pea
pea
pea
pea
pea
tubo
rolo
117

PRODUTO

DESCRIO

UNIDADE

055
076
077
081
099

Tinta anticorrosiva verde


leed vermelho
leed verde
Painel frontal
Caixa para vdeo

litro
pea
pea
pea
pea

Vamos ver ento como ficaria o relacionamento Compe para a estrutura de


engenharia de um terminal de vdeo fictcio.
Compe para o Produto 001 Terminal de Vdeo
Cdigo_Produto
Composto

Cdigo_Produto
Componente

Quantidade
Componente

001
001
001
001
001
001
001
001
001

002
003
004
005
011
023
068
087
099

1
1
1
1
1
1
4
3
1

O que queremos mostrar aos leitores, a fcil visualizao dos dados no


interior do relacionamento.
Para uma estrutura de produto mais complexa, vrios nveis, o modelo no
sofre mudanas, pois nada mais do que a interiorizao do relacionamento, isto , a
composio de um produto componente, e assim por diante.

9.4 - Auto-Relacionamento e Papel em um


Relacionamento
Freqentemente, vemos nossos alunos confundirem-se quando enfrentam
determinados contextos de sistema, entre os papis assumidos por ocorrncias de uma
entidade relacionada a outra, com um auto-relacionamento.

Vamos examinar uma situao em que este caso aparece.


Supondo que temos uma entidade Apartamento, e uma entidac Pessoa.

Existe ento para cada apartamento um Locador (que o proprietrio< e um


Locatrio (a pessoa que aluga o apartamento), que por sua vez so ocorrncias de
Pessoa.
Muitas vezes temos visto os alunos realizarem a ligao de Pessoa com
apartamento por um relacionamento Possui, para identificar os proprietrios um
auto-relacionamento em Pessoa, para representar o fato de algum si Locatrio.
Mas a realidade de que quem aluga o apartamento est relacionado com o
objeto apartamento diretamente, e com o proprietrio atravs deste apartamento
indiretamente.
O papel de Locador o do objeto que se relaciona com Apartamento atravs
de um relacionamento que denominamos Possui, e o papel d Locatrio o obtido
atravs do relacionamento entre Apartamento e Pessoa. denominado Aluga. So na
realidade dois relacionamentos distintos entre Pessoa e Apartamento.
Esta forma de enfoque permite que uma ocorrncia de Pessoa possa estar
relacionada com uma ocorrncia de Apartamento por Possui (proprietria do
apartamento), e esta mesma ocorrncia de Pessoa pode ter um relacionamento com
outra ocorrncia de Apartamento atravs do relacionamento Aluga, referindo-se ao
fato de que esta pessoa pode esta alugando um apartamento.
O que mais importante ainda de entendermos que entre duas entidades
pode haver mais de um relacionamento, como neste caso.

Por Onde Comear?


Figura
9-6
O diagrama da figura 9.6 mostra estes dois relacionamentos, e como ambos
possuem cardinalidade de Um-para-Muitos, conclumos que existem as chaves
estrangeiras em apartamento, uma para ligao com o papel Locatrio e outra para a
ligao com o papel Locador.
A seguir, apresentamos a estrutura de dados do dicionrio, para estes dois
relacionamentos.
ENTIDADE

ATRIBUTOS

PESSOA

Cdigo_Pessoa
Nome_Pessoa
Nmero_Apartamento
Nmero_do_Prdio
Endereo_Predio
Cdigo_do_Proprietrio # Chave estrangeira para
Possui
Cdigo_do_Locatrio # Chave estrangeira para
Aluga

APARTAMENTO

Agora que j conhecemos o modelo Entidade-Relacionamento proposto por


Peter Chen, agora que j sabemos o que so vises de dados, vamos por mos obra.
Mas natural que o ponto mais crucial seja ligar os motores. Vamos ento
aprender como podemos iniciar um trabalho de Modelagem de dados para um sistema,
j que nosso objetivo neste livro no sermos meramente didticos, e sim passar
experincias e acelerar as possibilidades de voc, leitor, efetuar realmente trabalhos de
desenvolvimento de sistemas a partir de modelos de dados.
A maior dificuldade nos trabalhos de modelagem de dados encontra-se nos
trabalhos iniciais de identificao das entidades.
Afinal o que vem a ser as entidades em um sistema, como podemos localizlas e identific-las sem que incorramos numa margem acentuada de erros?
Se o analista vem de uma formao tradicional, totalmente orientada a
procedimentos, por onde comear?
Como conduzir o usurio a nos mostrar estas entidades que tanto necessitamos
conhecer?
Embora seja um tema um tanto quanto ambguo, de difcil formalizao,
existem na verdade formas e regras que podemos seguir para termos produtividade
para realizar estas descobertas, que nos levaro a dominar um problema de negcios a
ser informatizado.

10.1 - Iniciando um Modelo


Cumpre aqui lembrarmos que a viso de dados no nos to distante quanto
primeira vista nos parece.
Analisemos ento um sistema a ser desenvolvido dentro de enfoque com
orientao a dados e que ir atender rea de vendas de uma empresa, ou melhor, ao
negcio Vendas de uma empresa.

Se realizamos uma venda, estamos obviamente vendendo alguma coisa, a


qual denominamos de Produto.
Se quando vendemos, o fazemos para diversos produtos possveis, logo temos
tambm uma entidade Produto, pois existem diversas ocorrncias de objetos produto
no contexto de uma venda.
Obtemos ento neste momento um diagrama E-R, com entidades assim
delineadas:

Ora como no conhecemos nenhum detalhe, ou ainda mais, no temos


nenhuma experincia anterior com sistemas de vendas, existe neste instante uma
abstrao global designada como Venda, sobre a qual iremos partir para nosso trabalho
de modelagem. Teramos num primeiro momento a entidade Venda. Mas o que
caracteriza uma Venda?
Ao questionarmos este objeto denominado Venda, passaremos a observar que
este elemento abstrato, na realidade, tem um elenco de atributos e possui ainda outros
objetos encapsulados relativamente simples, de fcil percepo, pois inclusive
convivemos com eles em nosso dia-a-dia. Exemplificando ento: uma venda descrita
por um vendedor tirando pedidos de produtos feitos por algum que deseja adquiri-los.
Esta afirmativa desmembra, na realidade, a abstrao inicial denominada
Venda em trs objetos agora melhor delineados. Seno vejamos: existem os objetos
Vendedor, Pedido e Cliente.
A questo que define conceitualmente uma entidade se desejamos guardar
dados para o objeto em si.
Ora, Pedidos qualifica a existncia de uma certa quantidade de ocorrncias de
objetos Pedido, os objetos Cliente e Vendedor da mesma forma. Logo temos j neste
instante descobertas trs das entidades que participam do contexto de Vendas.
Estes objetos so qualificados como entidades porque podemos identificar
suas ocorrncias individualmente, podendo ser construdas tabelas com informaes
sobre clientes, sobre pedidos e sobre os vendedores da empresa.
Mas uma anlise mais apurada logo ir, atravs de uma simples interpretao,
nos lembrar de que uma venda se efetiva para alguma coisa.

Podemos agora ento comear a analisar e verificar a existncia de


relacionamentos entre estas entidades, ou seja, quais so objetos do tipo fato, que
existem ligando estas entidades.
Neste momento, visualizamos um relacionamento de caractersticas
importantes dentro do contexto.
Quando afirmamos que um pedido contm produtos, estamos relacionando as
entidades pedido e produto. Bem, neste instante j sabemos que existe o
relacionamento pois ele claro no mundo real. Necessitamos, isto sim, compreend-lo
melhor. Qual a sua cardinalidade, como os dados se relacionam?
Sabemos, bastando para isto lembrarmos de um documento Pedido, que um
pedido pode conter 1 ou vrios produtos, no existindo um nmero exato de quantos
produtos estaro em um pedido, pois depende da venda, do momento, de uma
negociao.
Ento observando no sentido de viso de pedido para produto, encontramos
uma cardinalidade que diz que um pedido contm muitos produtos, logo cardinalidade
Um-para-Muitos.
Mas os produtos da empresa so vendidos uma nica vez na vida? bvio
que no. Um produto da empresa vendido diversas vezes para clientes diferentes ou
para o mesmo atravs de vrios pedidos.
123

Novamente analisando agora o sentido inverso de interpretao, de produto


para pedido, encontramos uma cardinalidade de um produto em muitos pedidos, isto ,
.

ENTIDADE

ATRIBUTOS

RELACIONAMENTO

PRODUTO

Identificao_Produto
Descrio_Produto

Com Pedido 1:N (Contm)

Ora, conforme j vimos no modelo Entidade-Relacionamento, quando temos


um relacionamento entre duas entidades, no qual ambos os sentidos de leitura do
diagrama apresentam cardinalidade Um-para-Muitos, isto est caracterizando que o
relacionamento do tipo Muitos-para-Muitos.

PEDIDO

Nmero_Pedido
Valor_Pedido
Data_Pedido

Com Produto 1:N (Contm)

Logo j temos uma das representaes do diagrama de Entidades e


Relacionamentos.

RELACIONAMENTO

ATRIBUTOS

CONTM

Nmero_Pedido Identificao_Produto Muitos Com Pedido


Quantidade_Produto
(Nmero_Pedido) Muitos
Nmero_de_Seqncia_no_Pedido
com Produto
(Identificao_Produto)

Mas neste ponto perguntamos:


Onde esto as informaes de quantidade de produto vendida?

LIGAES

O preo total do produto no pedido?

Figura 10.1

A seqncia do produto dentro do pedido?

Quando comeramos a descrever um jogo bsico de entidades, iro existir


atributos que, na realidade, nos mostram que pertencem no s entidades j definidas,
mas sim, que so caracterizadores de um objeto ainda no determinado por ns.

Ora, j sabemos que os relacionamentos com cardinalidade Muitos-paraMuitos possuem campos, tm a forma de uma tabela, logo estas informaes fazem
parte do jogo de atributos deste relacionamento entre Pedido e Produto, e que
denominaremos de Contm, conforme apresentado na tabela da figura 10.1, para
expressar melhor a realidade.
Devemos continuar o nosso trabalho no sentido de verificar a possibilidade de
desmembrar as entidades j conhecidas at ento. Para isto :orna-se necessrio que se
desenhem os atributos que descrevem cada entidade.
O que caracteriza um pedido?
Um pedido pode ser caracterizado por um nmero de identificao, pela sua
data, a identificao do cliente que o fez, a identificao do vendedor que o emitiu, e
basicamente os produtos que esto vendidos em um pedido.
ENTIDADE

ATRIBUTOS

VENDEDOR

Identificao_Vendedor
Nome_Vendedor
Identificao_Cliente
Nome_CIiente

CLIENTE

RELACIONAMENTO

E quais seriam os relacionamentos existentes entre o restante das entidades at


aqui descobertas?
Vamos recordar que o importante em modelagem de dados retratar o mundo
real, logo a interpretao da sentena: Cliente faz Pedido, nos apresenta alm de duas
entidades, mais um fato, que tambm um objeto deste contexto, o ato de fazer um
pedido. Faz o relacionamento entre a entidade Cliente e a entidade Pedido, e efetuase por intermdio de referncia lgica em pedido a um cliente.
Observa-se que em Pedido temos o atributo "Identificao_do_Cliente", que
caracteriza uma chave estrangeira em Pedido, permitindo uma expresso de
comparao: Cliente.Identificao_de_Cliente = Pedido.Identificao_de_Cliente.
Recordando o captulo de relacionamentos, a chave estrangeira est em
Pedido, logo o relacionamento possui uma cardinalidade de Um-para-Muitos no
sentido de Cliente para Pedido, isto , um Cliente Faz Muitos Pedidos (figura 10.2).

A efetivao desta ligao no mundo real realiza-se atravs de um meio,


atravs de um Pedido. Logo, as ocorrncias da entidade Vendedor esto relacionadas
com as ocorrncias da entidade Pedido, este relacionamento sim, devemos efetivar no
modelo.

Figura 102

Na figura 10.3 apresentada uma simulao das tabelas Cliente e Pedido.


CLIENTE
IDENTIFICAO_CLIENTE

NOME_CLIENTE

2412
2122
5577
2901

Atacado Jos
Mercado Pedro
Banca Maurcio
Lojas du Pedter

Para obtermos o vendedor que atendeu a um cliente, devemos obviamente,


verificar os pedidos de um cliente, para nos pedidos obter quem o atendeu.
Analisando o modelo at este ponto trabalhado, temos ento os seguintes
objetos delineados:
4 Entidades:
-

Cliente;
Pedido;
Produto;
Vendedor.

PEDIDO
NMERO_
PEDIDO

DATA_PEDIDO

7709/92
5588/92

21/02/92
23/04/92

VENDEDOR

76
55

IDENTIFICAO_CLIENTE

2122
5577

Figura 103
Seguindo a linha de raciocnio, analisemos agora as ligaes possveis de
Vendedor com outras entidades.
Vendedor est relacionado com o qu?
A primeira sentena do caso em estudo, retrata-nos o vendedor tirando os
pedidos, realizando o atendimento a um cliente.
Mas o que neste contexto um fato relevante? Tirar o pedido ou Atender a um
Cliente?
Seguidamente, em treinamentos realizados de modelagem de dados, os nosso
alunos apresentam a tendncia a efetivar uma ligao entre vendedor e cliente.
Perguntamos ento se esta ligao se efetiva diretamente, ou necessita de um
meio para realizar-se?

3 Relacionamentos:
- Faz;
- Tira;
- Contm.
Sendo este ltimo um relacionamento com campos, que representa os itens de
um pedido.
O modelo de dados representativo da anlise realizada composto ento por
um Diagrama de Entidades e Relacionamentos um descritivo de cada entidade com
seus atributos, e os relacionamentos existentes entre estas entidades, com seus
atributos e expresses de relacionamento (Dicionrio de Dados).
A figura 10.4 procura mostrar ao leitor o diagrama ER resultante da anlise
realizada.

VENDEDOR

PRODUTO

Figura 10.4
A construo de uma simulao importante para que possamos obter o
entendimento e a validao do modelo que estamos definindo. Ao visualizar as
tabelas de dados, temos ento o domnio do problema simulado, permitindo-nos
correes por interpretao de contexto.
Na figura 10.5 apresentado uma simulao da realidade, com valores
alocados nas tabelas criadas.

CLIENTE
IDENTIFICAO_CLIENTE

NOME_CLIENTE

!412
2122
5577
!901

Atacado Jos
Mercado Pedro
Banca Maurcio
Lojas du Pedter

NMERO_PRODUTO

NOME_PRODUTO

111
256
387
358
470
631

Camisa
Rdio
Pomada
Garrafa
Tijolo
Bicicleta

CONTEM
NMERO_PEDIDO

NMERO_PRODUTO

QUANTIDADE

7709/92
7709/92
5588/92
8936/94
2738/95
2738/95
2738/95
4976/95

111
387
256
256
358
470
631
256

100
20
2
3
400
1000
4
1

Figura 10.5 (continuao)


PEDIDO
NMERO
PEDIDO

DATA_PEDIDO

VENDEDOR

IDENTIFICAO_CLIENTE

7709/92
588/92
936/94
738/95
976/95

21/02/92
23/04/92
20/07/94
01/11/95
15/12/95

76
55
97
17
76

2122
5577
2901
2412
2901

Figura 10.5

Como no primeiro momento da modelagem o que nos importa determinar


quais so as entidades que coexistem no modelo, alguns dados so colocados parte,
divididos em grupos similares quanto ao tipo de informao que possivelmente iro
compor.
Por exemplo, em nosso caso, podem surgir dados como comisso do vendedor
por suas vendas, expressos por um valor financeiro totalizador de um ms especfico,
reserva de mercadorias para as vendas j colocadas ou as condies de pagamento
concedidas ao cliente para o pedido que ele est realizando.

Podem, eventualmente, surgir adjetivos de qualificao genricos que no


devem nos induzir a criar novas entidades, j que identificam grupos seletivos de uma
mesma entidade j delineada, tais como: o fato de que pedidos podem ficar pendentes.
Pedidos Pendentes uma adjetivao de um pedido, um status do pedido, no
caracterizando em nenhuma hiptese uma nova entidade, j que no tem uma
existncia prpria, desvinculada como um objeto distinto de Pedido, sendo na
realidade uma especializao de Pedido, como j vimos.
Historicamente, os nossos usurios quando descrevem seu ambiente
operacional, apresentam-nos na realidade, no uma foto do setor, mas sim um filme do
mesmo em movimento.
No existe a preocupao dos mesmos sobre o que est efetivamente
participando, informando-nos seguidamente distores, principalmente quanto aos
dados por eles processados.
As tcnicas de normalizao de dados so extremamente teis, como
estudaremos no captulo 12, mas a forma ideal de utilizao seria somente a partir do
reconhecimento e identificao de um grupo principal de entidades, no sendo
normalizao um conjunto de regras fundamental para a identificao de entidades.
A questo maior a conduo do processo de elaborao do chamado modelo
descritivo de sistema.
Devemos criar atas de reunies com usurios? Ou existe uma forma de
trabalho que nos leve diretamente a modelos de dados?
A anlise de abstraes apresentada no caracteriza a necessidade de longas
reunies, mas possui, isto sim, a caracterstica de ser uma atividade a ser realizada em
conjunto com os usurios desde o incio da atividade de projeto de sistemas.
Voltando a lembrar, este o primeiro passo efetivo do trabalho de anlise, s
sendo suplantado pela apresentao formal das pessoas que executam o papel de
usurios, para fins de relaes interpessoais.
Mas para que este livro no fique parco de casos, vamos simular outras
situaes de modelagem para o passo de descoberta de entidades, de forma que
possam, estas interpretaes de anlise, serem aproveitadas como experincias de
modelagem pelos leitores. Mas como relacionamentos so

objetos que aparecem conjuntamente com as entidades, passaremos ento a tratar de


forma global, os casos propostos e resolvidos.
No exemplo que at aqui utilizamos, aplicamos a forma top-down da viso dos
dados de um contexto, baseados na atividade-fim, para a qual existia o setor da
empresa.
Denominamos de entidade principal de um sistema, aquela que possui a
caracterstica de representar numa anlise de abstraes top-down, o nvel mais alto
de abrangncia.
fator primordial para um resultado eficiente de modelagem de dados, que se
identifique claramente esta entidade (ou entidades) corn os objetivos organizacionais
do setor, para elaborar-se um sistema, pois poderemos desta forma, conduzir um
projeto visando cumprir os objetivos e metas de um negcio.
No prximo captulo, vamos analisar uma srie de casos propostos e
resolvidos, tratando de situaes mais abrangentes, simulando casos reais.

Estudo de Casos

11.1 - Introduo
Esta a parte que consideramos fundamental neste livro. E composta de trs
casos prticos que esto baseados em fatos verdicos, situaes que podem
perfeitamente ser encontradas no mundo real, e, claro, ns as encontramos.
As solues sero comentadas passo a passo, procurando transmitir o processo
de levantamento que utilizamos na vida prtica e nos treinamentos realizados por ns.
Ser criada uma proposta bsica de diagrama Entidade-Relacionamento para cada
situao.
Em modelagem de dados, no existe um modelo do gnero "A resposta esta,
e somente esta". Como estamos trabalhando com a viso que seres humanos tm dos
dados de uma realidade, eles podem ter diferentes interpretaes para um mesmo fato,
e como conseqncia, representaes diferenciadas podem e certamente vo ocorrer.
O objetivo no restringirmos os resultados, uma vez que desejamos conduzilos para implementaes em ambientes de Banco de Dados diversos.
Vamos apresentar, alm do diagrama ER que ser construdo neste captulo, a
definio da base de dados no SGBD ORACLE v. 7 e Microsoft Sql Server 7.0
utilizando a linguagem SQL (Strutured Query Language). Esta definio das bases de
dados ser apresentada no final do captulo 14.
A apresentao dos resultados ser narrativa, objetivando que a viso dos
dados cresa gradativamente na interpretao dos fatos em um problema.

2 - Estudo de Caso 1
Controle de Cinemas
Vamos iniciar nossos estudos de caso com uma situao que envolve diversos
nveis de abstrao, possibilitando a utilizao de extenses do Modelo EntidadeRelacionamento.
Vamos projetar um modelo de dados que atenda s necessidades de controle
dos cinemas e filmes em uma determinada empresa de distribuio filmes.

- Os atores de um filme podem, obviamente, atuar em diversos filmes, assim


como o diretor de um filme pode tambm ser ator nesse filme ou, ainda mais,
ser ator em outro filme. Um ator possui as seguintes caractersticas: um
nmero de identificao, um nome, uma nacionalidade e uma idade;
- As sesses de cinema devem ter seu pblico registrado diariamente, para que
se permita a totalizao dos assistentes quando o filme sair de cartaz, ou a
qualquer instante.
Nas reunies de levantamento, os usurios nos passaram as seguintes
necessidades de informao:

Viso do negcio:

- Apurao do pblico por municpio, por cinema e por sesso de cada cinema;

- rea de Negcio: Departamento de Programao;

- Permitir uma forma de consulta, que dado um determinado ator, sejam


localizados os cinemas onde esto em cartaz os
filmes em que esse ator atua;

- Funo Gerencial: Administrao de Cinemas.


Aps vrias reunies com os futuros usurios do sistema, relacionamos uma
srie de regras do negcio e que sero a base para o envolvimento do diagrama
ER:
- A empresa de distribuio possui vrios cinemas em diversas localidades;
- Cada cinema possui uma identificao nica, um nome fantasia, um
endereo completo, incluindo rua, avenida, bairro, municpio, estado e sua
capacidade de lotao;
- Os filmes podem ser dos mais variados tipos e gneros;
- Cada filme registrado com um ttulo original, e se for filme estrangeiro,
possuir tambm o ttulo em portugus, o gnero, sua durao, sua
impropriedade e seu pas de origem, informaes sobre os atores que
compem seu elenco, e o seu diretor. Existir um nico diretor para cada
filme;
- Alguns cinemas apresentam mais de um filme em cartaz, sendo, nesses
casos, sesses alternadas com um filme e outro;
-As sesses possuem horrios que variam de acordo com a durao do filme,
havendo sempre um intervalo de aproximadamente 15 minutos entre elas;

ex: "Quais cinemas (nomes) passam filmes em que atue a atriz "Jlia
Roberts"? Queremos obter somente os nomes dos cinemas,
independentemente dos filmes." Para testarmos esta solicitao utilizaremos
comandos SQL.
- Em quais
de filme;

cinemas

est

sendo

exibido

um

determinado

gnero

- Em quais cinemas esto sendo exibidos filmes nacionais.


Ento vamos comear nossa anlise dos objetos da realidade:
- Qual(is) o(s) objeto(s) que se destaca(m) no mundo real?
- Existe um objeto, uma abstrao global, ou mais de uma?
A resposta a estas questes fundamental, pois a partir dela que iremos
iniciar o desenvolvimento do modelo.
Vejamos ento.
Temos claramente duas classes de objetos que podemos considerar como
grandes entidades neste contexto: Filme e Cinema.

Filme possui uma srie de atributos que o caracterizam, alm do que podemos
visualizar que existem muitas ocorrncias de filme em nosso caso.
Cinema, da mesma forma, j que possui atributos prprios que o caracterizam,
alm de ser fcil imaginar a existncia de diversos cinemas.
Mas neste ponto, os leitores iro perguntar: E da, o que possvel montar
com o obtido at este momento?

Como podemos observar no quadro, surgiu a informao sobre os atores de


um filme. Podemos concluir que temos um objetivo que representar os atores de um
filme, ou seja, o seu elenco.
Desta forma, como est afirmado no contexto do problema que um ator pode
atuar nos mais diversos filmes, e possui atributos independentes de participao em
filmes, caracteriza uma entidade para armazenarmos informaes sobre os atores.
Neste instante, temos as entidades:

Antes de seguirmos desenhando entidades "alopradamente", vamos analisar a


caracterizao de cada uma delas, em relao ao contexto que nos foi apresentado.
Cinema tem os seguinte atributos:
CINEMA
Identificao do cinema
Nome fantasia
Endereo
Rua/Avenida
Bairro
Municpio
Estado
Capacidade de lotao
Vejamos quais seriam os atributos possveis para Filme, de acordo com o
contexto apresentado:
FILME
Identificao do filme
Ttulo Original
Ttulo em portugus
Durao
Identificao do Diretor
Pas de origem
Gnero
Impropriedade
Atores (Quantos?)

Com os objetos que j identificamos, o procedimento mais correto para o


trabalho de modelagem , neste instante, efetuarmos a anlise dos relacionamentos
que so possveis de existir no mundo real entre estas entidades.
Vamos ento ao cinema, para entendermos melhor o mundo real onde as
coisas acontecem.
A primeira premissa que podemos utilizar para ligarmos entidades a de que
um Filme passa em um Cinema. Neste momento, caracterizamos uma existncia no
mundo real.
Na seqncia de raciocnio, sabemos que um mesmo Filme passa em vrios
Cinemas ao mesmo tempo; logo, temos um relacionamento entre as entidades Cinema
e Filme, mas qual ser sua cardinalidade correta?
Ora, existe no contexto das regras de negcio apresentado a informao de
que um cinema pode apresentar mais de um filme em cartaz. Por outro lado, sabemos
que quando estamos modelando, no estamos preocupados com o processo de
informao; logo, um cinema pode passar vrios filmes em datas diferentes,
caracterizando-se ento que um cinema passa mais de um filme.
Com esta anlise podemos desenhar ento um bloco de modelo com as
entidades Filme e Cinema, e seu relacionamento, que ento um relacionamento de
muitos para muitos.
Leia-se o modelo seguinte como:

Um Filme possui muitos Atores, o que nos fornece a cardinalidade de Umpara-Muitos no sentido Filme - Ator. Por outro lado, mudando nosso posicionamento
para a entidade Ator, temos: um determinado Ator (ex: Linda Mulher "Jlia Roberts")
atua, ou melhor, relaciona-se com muitos Filmes, no sentido de Ator para Filme. Esta
situao est representada na figura 11.1.

MODELO
INICIAL
Um Cinema
passa muitos Filmes

Um Filme passa em muitos Cinemas


J estudamos que quando nos defrontamos com cardinalidades de Um-paraMuitos nos dois sentidos de leitura do modelo, o relacionamento na realidade
Muitos-para-Muitos.
Mas devemos seguir analisando o restante dos objetos at aqui descobertos.

Logo, temos novamente a situao que j havamos encontrado (Cinema /


Filme), um relacionamento entre Filme e Ator com cardinalidade Muitos-para-Muitos.
E que campos poderia ter este relacionamento?
Vamos deixar para um pouco mais adiante na soluo deste exerccio, o
delineamento dos campos deste relacionamento.

A questo que se coloca em seguida, so os relacionamentos que existem


entre o que j delineamos do modelo e a entidade Ator, que contm os dados de cada
ator registrado como tal.
Ator est ligado com Cinema?
Somente se os atores comparecerem em cada cinema que passa o Filme.
Afirma-se que um filme tem um elenco de atores, isto , muitos atores em um
Filme, tornando-se bvio que o ator relaciona-se com filme exclusivamente.
Mas com que cardinalidade?
N
Figura 112
J temos ento o modelo agora com trs entidades e dois relacionamentos,
conforme nos mostra a figura 11.2.
Vamos analisar o contexto que diz que um filme possui um diretor, e esse
diretor pode tambm ser um ator, e por conseqncia possui os mesmos dados
cadastrais de ator.
Existe ento, mais um relacionamento entre Filme e Ator?
Qual a sua cardinalidade?
Figura 11.1

Quando afirmado que um ator pode tambm ser um diretor, estamos criando
um sinnimo simples para ator, denominado Diretor, que ser o papel
139

exercido por uma ocorrncia da entidade Ator, quando ela estiver relacionada com
Filme por meio de um relacionamento chamado Dirige, que distinto do
relacionamento Atua.
No conjunto de atributos de Filme, consta um atributo desde o incio de nosso
caso, que a identificao do diretor, o que caracteriza uma chave estrangeira em
filme, referenciando uma outra entidade, no caso a entidade Ator.
Criamos ento o relacionamento DIRIGE, que um fato puro que ocorre no
mundo real; todos os filmes so dirigidos por algum. No diagrama ER, criamos um
papel para a entidade ATOR, chamado DIRETOR. Estabelecemos ento, que
relacionamento DIRIGE existe entre a entidade FILME e a entidade DIRETOR, que
na verdade a mesma coisa que ATOR.
Na figura 11.3, apresentado o modelo ER com as consideraes
apresentadas a respeito de ATOR, DIRETOR e FILME.
Figura 11.4
Pode-se perguntar, por que estabelecemos uma cardinalidade de Um--paraMuitos, baseados em que princpios? Somente na chave estrangeira?
No poderia ser um relacionamento de Um-para-Um?
Existe, nas premissas do caso em estudo, uma afirmativa de que cada filme
somente possui um diretor, mas nada que limite um diretor somente dirigir um nico
filme; logo, a cardinalidade Um-para-Muitos.
Bem, j possumos uma boa parte da soluo para a modelagem solicitada.
Vejamos ento o que nos falta.
E solicitado o controle de pblico que assistiu a um determinado Filme. Essa
informao deve ser possvel de obter tanto em nvel de cinema, quanto em nvel de
cidade, e o pblico do filme como um todo.
Figura 11.3
A cardinalidade tornou-se bvia em funo de existir uma chave estrangeira
na entidade FILME, pois conforme j havamos citado neste livro, a chave estrangeira
est do lado muitos. Na figura 11.4, apresentado o modelo ER com as cardinalidades
ATOR/FILME.

Vamos recordar que quando vamos a um cinema para assistir a um Filme,


vamos a um Cinema que Passa um Filme.
Ento, estando em frente ao Cinema que Passa um Filme, vemos que quando
o Cinema Passa um Filme, existem sesses para assistirmos.
Logo, iremos fazer parte do pblico que assistiu a um determinado filme num
cinema especfico, em uma localidade qualquer.

Vamos analisar um objeto que nos parece interessante, a SESSO de cinema


que passa um filme.
O objeto SESSO s existe se antes existir um CINEMA que PASSA um
FILME, ou seja, deve existir um Filme relacionado com um cinema para que exista
uma ou mais sesses.
Isto nos leva a modelar dados, ou seja, atributos para sesso inicialmente:

SESSO
Data da Sesso
Hora da Sesso
Pblico da Sesso
Mas com esses atributos somente, no poderamos identificar em que cinema
foi realizada essa sesso e nem para que filme ela aconteceu.
Logo, necessitamos relacionar cada ocorrncia de Sesso com um Filme
passando em um Cinema, isto , com o bloco de modelo que representa o fato
CINEMA PASSA FILME.

Figura 11.5
Agora j podemos fechar o modelo ER, o qual pode nos permitir visualizar
todos os fatos que envolvem o caso prtico. Vejamos a figura 11.6, e vamos executar
a sua leitura.

Um CINEMA quando PASSA um FILME tem muitas SESSES, e por outro


sentido de leitura dos fatos, uma SESSO s est relacionada a um FILME em um
CINEMA.
Isto nos apresenta a necessidade do uso de uma agregao, uma extenso do
modelo E-R, que estudamos no captulo 8. A figura 11.5 representa esta situao do
uso de agregao.

Figura 11.6
Um cinema passa muitos filmes, e um filme passa em muitos cinemas.
Quando um filme passa em um cinema, este tem muitas sesses.

Cada filme possui atores que participam dele, e por sua vez um ator pode
participar de muitos filmes.

sobre Normalizao. Com estas duas observaes podemos melhorar o modelo ER


proposto anteriormente (figura 11.8).

Todo filme tem um diretor que pode ser tambm um ator desse filme. Um
diretor pode dirigir muitos filmes.
Na figura 11.7, so apresentados os atributos de cada objeto.
ENTIDADES
CINEMA
Identificao do
cinema
Nome fantasia
Endereo
Rua/Avenida
Bairro
Municpio
Estado
Capacidade
(lotao)

FILME
Cdigo do filme
Ttulo em
portugus
Ttulo Original
Impropriedade
Durao
Pas de origem
Gnero

ATOR
Cdigo do ator
Idade
Nome do ator
Nacionalidade

SESSO
Data da Sesso
Hora da Sesso
Pblico da
Sesso

Relacionamentos

Figura 11.8
ATUA
DURAO
Cd.Ator
Cod.Filme

PASSA
Cod.Filme
Ident. de Cinema

Na figura 11.9, so apresentados os atributos dos novos objetos.

Figura 11.7
O modelo criado j atende de forma satisfatria s necessidades de informao
da Distribuidora de Filmes. Com base neste modelo podemos, a partir de agora,
aprofundar nossas observaes a respeito da realidade enfocada, tentando obter uma
viso cada vez mais detalhada a respeito dos objetos do negcio.
Se fixarmos a ateno na entidade FILME, podemos observar que existe um
agrupamento de nacionalidade dos filmes: filme nacional e filme estrangeiro.
Observando mais atentamente a entidade FILME, podemos observar tambm que a
ocorrncia de Gnero pode ter muitas repeties. Esta particularidade sobre
redundncias ser tratada no captulo 12 que discorre

Figura 11.9
Fica bem evidente que para a implementao deste modelo alguns aspectos
poderiam ser desconsiderados, tais como a ocorrncia dos subtipos: filme nacional e
filme estrangeiro, devido a sua simplicidade de atributos.

11.3 - Estudo de Caso 2


Gerncia Acadmica de uma Universidade
Decidiu-se automatizar alguns procedimentos da Gerncia Acadmica (GA)
da Universidade UNITESTE. Com a finalidade de auxiliar esta tarefa, foi solicitado o
desenvolvimento de um banco de dados.
A Gerncia Acadmica mantm um controle centralizado de alunos, cursos,
disciplinas, turmas de matrias, professores e histrico escolar de alunos.
Os alunos so admitidos nos cursos por meio de um vestibular ou
transferncia, e um aluno s pode estar ligado a um curso, em um dado instante. Os
alunos, quando ingressam na universidade, preenchem uma ficha cadastral (com
nmero de matrcula pr-impresso) com nome e endereo.
De acordo com as normas (estatutos) da UNITESTE, cada disciplina para ser
oferecida, necessita de um mnimo de dez alunos e para que o alto padro de ensino
oferecido seja mantido, cada disciplina dever ter no mximo 50 (cinqenta) alunos.
Os cursos so compostos por disciplinas, as quais podem ser obrigatrias ou optativas,
dependendo do curso a que pertencem. Cada disciplina est sob a responsabilidade de
um departamento da universidade, e codificada de acordo com um padro
preestabelecido pelo conselho.
Segundo uma conveno adotada pela UNITESTE, os professores podem ser
cadastrados na GA sem estar lecionando uma disciplina. Cada professor pode
ministrar at o mximo de 3 (trs) matrias. Para que um professor ministre uma
disciplina, o mesmo, deve estar devidamente habilitado pelo CFE (Conselho Federal
de Educao). Cada professor est vinculado a um departamento e possui um cdigo
especfico para sua diferenciao dentre os demais professores.
Para o perfeito acompanhamento acadmico do aluno durante o curso, a
UNITESTE possui um histrico escolar. Esse documento o conjunto de todas as
disciplinas cursadas pelo aluno em toda a sua vida acadmica dentro da UNITESTE.
Contm o registro das disciplinas e indica a nota (conceito) final e a data em que a
disciplina foi cursada.

Os departamentos so responsveis pelos cursos de suas reas de atuao. As


responsabilidades envolvem a definio do nmero de crditos exigidos para a
concluso do curso, o nmero total de horas exigidas para o curso e o nmero total de
horas nas disciplinas obrigatrias.
A UNITESTE adota um sistema progressivo de aprendizado, no qual cada
disciplina pode ter no mximo 3 (trs) e no mnimo 0 (zero) pr-requisitos.
Geralmente, as matrias sem nenhum pr-requisito, ou esto no primeiro perodo, ou
so disciplinas eletivas (no obrigatrias).
De acordo com o Conselho Acadmico, um aluno pode, em um dado semestre,
no estar matriculado em nenhuma disciplina, caracterizando um trancamento de
matrcula. Em um perodo letivo, um aluno pode se matricular, no mximo, em 7
(sete) disciplinas. O conselho tambm fixou que um aluno pode repetir no mximo 3
(trs) vezes a mesma disciplina.
No total, a UNITESTE pode comportar 5000 (cinco mil) alunos matriculados
em seus diversos cursos. A cada ano, so admitidos 800 (oitocentos) novos alunos via
vestibular e as transferncias externas podem ser no mximo 60 (sessenta). Formamse em torno de 300 (trezentos) alunos por semestre. A UNITESTE oferece 10 cursos e
280 (duzentos e oitenta) disciplinas, possuindo cerca de 120 (cento e vinte)
professores.
Viso do negcio:
- rea de Negcio: Gerncia Acadmica;
- Funo Gerencial: Controle Administrativo.
Por meio da anlise das informaes obtidas no levantamento, podemos
observar claramente algumas classes de objetos que podemos considerar como
centrais para as necessidades da Gerncia Acadmica: Alunos, Cursos, Disciplinas e
Professores.

Cujos atributos so:


ALUNO
Nmero de Matrcula
Nome
Endereo
Rua/Avenida
Bairro
Municpio
Estado

PROFESSOR
Cdigo do Professor
Nome
Inscrio CFE
Departamento

DISCIPLINA
Cdigo da
Disciplina
Nome da
Disciplina
Descrio
curricular
Departamento

CURSO
Cdigo do Curso
Nome do Curso
Departamento

A partir desta anlise preliminar das


classes
de
objetos,
podemos ento traar os relacionamentos (fatos) que interligam estas entidades.
Podemos retirar do levantamento feito os seguintes relacionamentos:
- ALUNO Cursa DISCIPLINA: um aluno cursa de 0 a N (mx. 7)
disciplinas; e uma disciplina pode estar sendo cursada por 0 a N (min. 10 /
mx. 50) alunos;
- ALUNO Realizou DISCIPLINA (histrico escolar): um aluno realizou de
0 a N disciplinas; e uma disciplina pode ter sido realizada por 0 a N
alunos. O fato da realizao s pode ocorrer no mximo 3 vezes
(repetio) para a mesma ligao entre um aluno e uma disciplina;
- PROFESSOR Rege DISCIPLINA: um professor pode reger nenhuma,
uma ou vrias disciplinas; e uma disciplina pode ter a regncia de nenhum,
um ou vrios professores;
- PROFESSOR Possui-Habilitao DISCIPLINA: um professor deve ter
pelo menos uma habilitao de disciplina para poder pertencer aos quadros
da UNITESTE; e uma disciplina pode ter nenhum, um ou vrios
professores habilitados;
- ALUNO Pertence a CURSO: um aluno s pode pertencer a um curso; e
um curso pode permitir a matrcula de vrios alunos.
Com base nas observaes descritas anteriormente, podemos construir o
diagrama ER preliminar, apresentado na figura 11.10.

Figura 11.10
Observe que em algumas cardinalidades foram colocados os valores reais
(mnimos e mximos). Na vida prtica, algumas ferramentas automatizadas de
modelagem (CASE) permitem a colocao destes valores para uso futuro,
principalmente em prototipadores No diagrama, estes valores no devem aparecer.
Observando mais atentamente os conjuntos de atributos das vrias classes de
objetos at aqui levantadas, podemos notar que existe um elemento comum a pelo
menos trs delas (CURSO, DISCIPLINA e PROFESSOR): o atributo Departamento.
Este fato nos leva concluso de que Departamento tambm uma classe de objetos a
ser controlada pela Gerncia Acadmica. Com isso vai aparecer uma entidade chamada
DEPARTAMENTO, que possui os seguintes relacionamentos:
- DEPARTAMENTO Controla CURSO: um departamento pode controlar de
1 at N cursos; e um curso s controlado por um e somente um
departamento;

-DEPARTAMENTO

Responsvel
DISCIPLINA:
um
departamento responsvel por uma ou vrias disciplinas; e uma disciplina
de responsabilidade de um e somente um departamento;
-PROFESSOR est Ligado DEPARTAMENTO: um professor est ligado
a um e somente um departamento; e um departamento pode possuir vrios
professores.
Alm do aparecimento da entidade DEPARTAMENTO, a realidade mostranos que uma DISCIPLINA est ligada a outra por uma relao de pr-requisito. Essa
ligao caracteriza um auto-relacionamento com dois papis bem-definidos: exige e
satisfaz.

O conjunto de atributos deste modelo apresentado em seguida:


ENTIDADES
ALUNO
Nmero de Matrcula
Nome
Endereo
Rua/Avenida
Bairro
Municpio
Estado
Cdigo do Curso

A partir destes novos objetos podemos construir o diagrama final (figura


11.11) para a situao apresentada para o controle da Gerncia Acadmica.

PROFESSOR
Cdigo do Professor
Nome
Inscrio CFE
Cd. Departamento
DISCIPLINA
Cdigo da Disciplina
Nome da Disciplina
Descrio curricular
Cd. Departamento

DEPARTAMENT
Cd. Departamento
Nome do Depto.
CURSO
Cdigo do Curso
Nome do Curso
Cd. Depto.

RELACIONAMENTOS
POSSUI
Cdigo da Disciplina
Cdigo do Curso
Norma do CFE

PRE-REQUISITO
Cdigo da Disciplina
Cd. Disc. Pre-req.
Norma do CFE

CURSA
Nm. de Matrcula
Cdigo da Disciplina
Nota final

HABILITAO
Cd. do Professor
Cd. da Disciplina
Data da Habilitao

REALIZOU
Cdigo da Disciplina
Nm. de Matrcula
Mdia
Perodo
REGNCIA
Cd. do Professor
Cd. da Disciplina
Perodo
Avaliao

11.4 - Estudo de Caso 3


Grupo de Pesquisa sobre Vrus
Figura 11.11

Um grupo de pesquisa mdica de um grande hospital deseja construir e manter


um banco de dados sobre todas as publicaes relativas a certos tipos de vrus.

A informao registrada sobre cada vrus inclui o nome cientfico e um texto


livre para sua descrio cientfica. Cada publicao impressa em uma edio
particular do jornal cientfico do hospital, identificado pelo nome do ornai, o nmero
do volume e o nmero da edio.
Uma publicao pode ter um ou mais autores e ser referente a um ou mais
tipos de virose.
O resumo (abstract) da publicao tambm armazenado no banco de dados,
junto com o nome do autor (autores) e o nome da instituio (instituto) qual a
pesquisa est associada, caso esta seja de fora do grupo de pesquisas.
Cada publicao contm uma lista de referncias a outras publicaes e essa
informao registrada na base de dados.
As publicaes editadas pelo grupo de pesquisa, alm das informaes
normais armazenadas para cada publicao, possuem informaes a respeito do
contrato de pesquisa (nmero do contrato, valor, data de incio e trmino).
A seguir, so apresentadas algumas das necessidades de informao por parte
dos usurios:
Entrar uma nova publicao com todas as informaes;
Listar os detalhes de todas as publicaes relativas a um vrus especfico;
Listar as publicaes de um especfico autor;
Listar as publicaes associadas a um especfico contrato de pesquisa.
Viso do negcio:
- rea de Negcio: Pesquisa Mdica;
- Funo Gerencial: Controle de Publicaes Tcnicas.
Utilizando as mesmas prticas realizadas nos dois estudos anteriores,
podemos observar a existncia de classes de objetos necessrias para o Controle de
Publicaes Tcnicas: Publicao, Vrus e Autor.

A relao entre estes trs objetos mostrada em seguida:


- AUTOR Escreve PUBLICAO: N:M;
- PUBLICAO Diz-Respeito VRUS: N:M.
A partir destas relaes, outros objetos podem ser visualizados, tais como:
instituto produz pelo menos uma publicao (externa) e contrato que financia a
publicao interna. Podemos observar que necessrio o particionamento da
publicao (externa / interna), porm a publicao externa no ser necessrio
representar, pois ela possui os mesmos atributos das publicaes internas. Estas, por
sua vez, devem ser representadas, pois apresentam atributos especficos para a ligao
com contrato.
As publicaes referenciam outras publicaes, evidenciando, assim, a
ocorrncia de um auto-relacionamento (REFERNCIA) entre publicaes.
Estas anlises nos levam construo do seguinte modelo a seguir.

A seguir, apresentada a relao de atributos do modelo anterior:

PUBLICAO (chave de publicao, ttulo, chave do instituto, jornal,


Nmero do volume, nmero da edio, ano)

Normalizao

PUBLICAO_NTERNA (chave de publicao, nmero do contrato)


AUTOR (chave do autor, nome do autor, nacionalidade, data de nascimento)
INSTITUTO (chave do instituto, nome do instituto, endereo, tipo)
CONTRATO (nmero do contrato, valor, data de incio, data de trmino)
VRUS (chave do vrus, nome do vrus, descrio).
RELACIONAMENTOS

Escreve (chave de publicao, chave do autor, data de entrega)


Referncia (chave de publicao, referncia de publicao)
Diz_Respeito (chave de publicao, chave do vrus)

O conceito de normalizao foi introduzido por E. F. Codd em 1970 (primeira


forma normal). Esta tcnica um processo matemtico formal, que tem seus
fundamentos na teoria dos conjuntos.
Atravs deste processo pode-se, gradativamente, substituir um conjunto de
entidades e relacionamentos por um outro, o qual se apresenta "purificado" em relao
s anomalias de atualizao (incluso, alterao e excluso) as quais podem causar
certos problemas, tais como: grupos repetitivos (atributos multivalorados) de dados,
dependncias parciais em relao a uma chave concatenada, redundncias de dados
desnecessrias, perdas acidentais de informao, dificuldade na representao de fatos
da realidade observada e dependncias transitivas entre atributos.
Neste captulo, vamos mostrar como estes problemas podem ser minimizados,
sensivelmente, atravs da normalizao, tornando o modelo de dados elaborado
bastante estvel e sujeito a poucas manutenes.
Os conceitos abordados neste captulo, podem ser aplicados s duas formas de
utilizao da normalizao:
- sentido de cima para baixo (TOP-DOWN):
Aps a definio de um modelo de dados, aplica-se a normalizao Para se
obter uma sntese dos dados, bem como uma decomposio das entidades e
relacionamentos em elementos mais estveis, tendo em vista sua implementao fsica
em um banco de dados;

- - sentido de baixo para cima (BOTTON-UP):


Aplicar a normalizao como ferramenta de
projeto do modelo de dados usando os relatrios,
formulrios e documentos utilizados pela realidade
em estudo, constituindo-se em uma ferramenta de
levantamento.

12.1 - Anomalias de Atualizao


Observando-se o formulrio de PEDIDO
apresentado na figura 12.1, podemos considerar que
uma entidade formada com os dados presentes neste
documento, ter a seguinte apresentao:
Atributos da entidade PEDIDO:
-

nmero do pedido
prazo de entrega
cliente
endereo
cidade
UF

- CGC
-

inscrio estadual
cdigo do produto (*)
unidade do produto (*)
quantidade do produto (*)
descrio do produto (*)
valor unitrio do produto (*)
valor total do produto (*)
valor total do pedido (*)
cdigo do vendedor
nome do vendedor
(*) Atributos que se repetem no
documento

Figura 12.1

Caso esta entidade fosse implementada como uma tabela


em um banco de dados, as seguintes anomalias iriam aparecer:
anomalia de incluso: ao ser includo um novo cliente, o
mesmo tem que estar relacionado a uma venda;

anomalia de excluso: ao ser excludo um cliente, os dados referentes as


suas compras sero perdidos;
anomalia de alterao: caso algum fabricante de produto altere a faixa de
preo de uma determinada classe de produtos, ser preciso percorrer toda a
entidade para se realizar mltiplas alteraes.

Para entidade PEDIDO, temos:


Entidade no normalizada:
PEDIDO:

12.2 - Primeira Forma Normal (1FN)


Em uma determinada realidade, s vezes encontramos algumas informaes
que se repetem (atributos multivalorados), retratando ocorrncias de um mesmo fato
dentro de uma nica linha e vinculadas a sua chave primria.
Ao observarmos a entidade PEDIDO, apresentada acima, visualizamos que
um certo grupo de atributos (produtos solicitados) se repete (nmero de ocorrncias
no definidas) ao longo do processo de entrada de dados na entidade.
A 1FN diz que: cada ocorrncia da chave primria deve corresponder a uma e
somente uma informao de cada atributo, ou seja, a entidade no deve conter grupos
repetitivos (multivalorados).
Para se obter entidades na 1FN, necessrio decompor cada entidade no
normalizada em tantas entidades quanto for o nmero de conjuntos de atributos
repetitivos. Nas novas entidades criadas, a chave primria a concatenao da chave
primria da entidade original mais o(s) atributo(s) do grupo repetitivo visualizado(s)
como chave primria deste grupo.

Atributo chave da Entidade:

Representao no ER: PEDIDO


Ao
Ao aplicarmos a 1FN sobre a entidade
PEDIDO,
obtemos mais uma nova entidade chamada de ITEM-DEPEDIDO, que herdar os atributos repetitivos e
destacados da entidade PEDIDO.

Ao aplicarmos a 1FN sobre entidade PEDIDO, obtemos mais uma entidade chamada de ITEM-DE-PEDIDO, que herdar os atributos repetitivos e destacados da entidade PEDIDO.

Entidades na 1FN:
PEDIDO

ITEM-DE-PEDIDO

Representao no ER

Um PEDIDO possui no mnimo 1 e no mximo N elementos em ITErv DE-PEDIDO e um ITEM-DE-PEDIDO pertence a l e


PEDIDO, log o relacionamento POSSUI do tipo 1:N.

somente 1

12.3 - Variao Temporal e a Necessidade de Histrico


Observamos que normalmente, ao se definir um ambiente c armazenamento de dados, seja ele um banco de dados ou no,
geralmente mantm a ltima informao cadastrada, que s vezes, por sua prpr natureza, possui um histrico de ocorrncias.
Mas como a atualizao sempre feita sobre esta ltima informao, perdem-se totalmente os dad passados.
A no-observao deste fato leva a um problema na hora de un auditoria de sistemas, que em vez de utilizar uma pesquisa
automatizai sobre os histricos, se v obrigada a uma caada manual cansativa sobre u mar imenso de papis e relatrios, e
que na maioria das vezes se apreser incompleta ou inconsistente devido a valores perdidos (document extraviados) ou no
documentados.
Com a no-utilizao de histricos e a natural perda desi informaes, a tomada de decises por parte da alta
administrao de ur empresa pode levar a resultados catastrficos para a corporao.
Toda vez que a deciso de armazenar o histrico de algum atributo tomada, cria-se explicitamente um
um para muitos (1-1 entre a entidade que contm o atributo e a entidade criada para contei histrico deste
existir ento uma entidade depender contendo (no mnimo) toda data em que houve alguma alterao do
respectivo valor do atributo para cada alterao. A chave de entidade de histrico ser concatenada, e um
ser a data referncia.

relacionamento de
atributo. Passa a
atnbu bem como o
de seus atributos

Com base nesta necessidade de armazenamento de histricos, apo aplicao da 1FN devemos observar para cada entidade
definida, quais seus atributos se transformaro com o tempo, se preciso armazenar daC histricos deste atributo e em caso
afirmativo, observar o perodo de tem

Projeto de Banco de Dados

que devemos conservar este histrico, ou atravs de quantas alteraes foram


realizadas neste atributo.

12.4 - Dependncia Funcional


Para descrevermos as prximas formas normais, se faz necessria a introduo
do conceito de dependncia funcional, sobre o qual a maior parte da teoria de
normalizao foi baseada.
Dada uma entidade qualquer, dizemos que um atributo ou conjunto de
atributos A dependente funcional de um outro atributo B contido na mesma
entidade, se a cada valor de B existir nas linhas da entidade em que aparece, um nico
valor de A. Em outras palavras, A depende funcionalmente de B.
Ex: Na entidade PEDIDO, o atributo PRAZO-DE-ENTREGA depende
funcionalmente de NUMERO-DO-PEDIDO.
O exame das relaes existentes entre os atributos de uma entidade deve ser
feito a partir do conhecimento (conceituai) que se tem sobre a realidade a ser
modelada.

12.5 - Dependncia Funcional Total (Completa) e


Parcial
Na ocorrncia de uma chave primria concatenada, dizemos que um atributo
ou conjunto de atributos depende de forma completa ou total desta chave primria
concatenada, se e somente se, a cada valor da chave (e no parte dela), est associado
um valor para cada atributo, ou seja, um atributo no (dependncia parcial) se
apresenta com dependncia completa ou total quando s dependente de parte da chave
primria concatenada e no dela como um todo.
Ex: dependncia total - Na entidade ITEM-DO-PEDIDO, o atributo
QUANTIDADE-DO-PRODUTO depende de forma total ou completa da chave
primria concatenada (NUMERO-DO-PEDIDO + CODIGO-DO PRODUTO).
A dependncia total ou completa s ocorre quando a chave primria for
composta por vrios (concatenados) atributos, ou seja, em uma entidade
162

Normalizao

de chave primria composta de um nico atributo no ocorre este tipo de


dependncia.

12.6 - Dependncia Funcional Transitiva


Quando um atributo ou conjunto de atributos A depende de outro atributo B
que no pertence chave primria, mas dependente funcional desta, dizemos que A
dependente transitivo de B.
Ex: dependncia transitiva - Na entidade PEDIDO, os atributos ENDEREO,
CIDADE, UF, CGC e INSCRIO-ESTADUAL so dependentes transitivos do
atributo CLIENTE. Nesta mesma entidade, o atributo NOME-DO-VENDEDOR
dependente transitivo do atributo CODIGO-DO-VENDEDOR.
Com base na teoria sobre as dependncias funcionais entre atributos de uma
entidade, podemos continuar com a apresentao das outras formas normais.

12.7 - Segunda Forma Normal (2FN)


Devemos observar se alguma entidade possui chave primria concatenada, e
para aquelas que satisfizerem esta condio, analisar se existe algum atributo ou
conjunto de atributos com dependncia parcial em relao a algum elemento da chave
primria concatenada.
Com a finalidade de tornar ainda mais estvel o modelo de dados, a aplicao
da 2FN sobre as entidades em observao geram novas entidades, que herdaro a
chave parcial e todos os atributos que dependem desta chave parcial, ou seja, uma
entidade para estar na 2FN no pode ter atributos com dependncia parcial em relao
chave primria.
Ex: A entidade ITEM-DO-PEDIDO apresenta uma chave primria
concatenada e por observao, notamos que os atributos UNIDADE-DO-PRODUTO,
DESCRIO-DO-PRODUTO e VALOR-UNITARIO dependem de forma parcial do
atributo CODIGO-DO-PRODUTO, que faz parte da chave Primria. Logo devemos
aplicar a 2FN sobre esta entidade. Quando aplicamos a 2FN sobre ITEM-DOPEDIDO, ser criada a entidade PRODUTO que herdar os atributos UNIDADE-DOPRODUTO, DESCRIO-DO-PRODUTO e VALOR-UNITRIO e ter como
chave primria o CODIGO-DO-PRODUTO.

PEDIDO

Um PRODUTO participa de no mnimo 1 e no mximo N elementos de


ITEM-DE-PEDIDO e um ITEM-DE-PRODUTO s pode conter 1 e somente 1
PRODUTO. Logo, o novo relacionamento criado do tipo N:l.

12.8 -Terceira Forma Normal (3FN)


Uma entidade est na 3FN se nenhum de seus atributos possu dependncia
transitiva em relao a outro atributo da entidade que no participe da chave primria,
ou seja, no exista nenhum atributo intermedirio entre a chave primria e o prprio
atributo observado.
Ao retirarmos a dependncia transitiva, devemos criar uma nova entidade que
contenha os atributos que dependem transitivamente de outro | a sua chave primria o
atributo que causou esta dependncia.
ITEM-DO-PEDIDO

PRODUTO

Representao no ER:

Alm de no conter atributos com dependncia transitiva, entidades na 3FN


no devem conter atributos que sejam o resultado de algum clculo sobre outro
atributo, que de certa forma pode ser encarada como uma dependncia, funcional.

Ex: Na entidade PEDIDO, podemos observar que o atributo NOME-DOVENDEDOR depende transitivamente do atributo CODIGO-DO-VENDEDOR que
no pertence chave primria. Para eliminarmos esta anomalia devemos criar a
entidade VENDEDOR, com o atributo NOME-DO-VENDEDOR e tendo como chave
primria o atributo CODIGO-DO VENDEDOR.
Encontramos ainda o conjunto de atributos formados por ENDEREO ,
CIDADE, UF, CGC e INSCRIO-ESTADUAL que dependem transitiva mente do
atributo CLIENTE. Neste caso, devemos criar a entidade CLIENT] que conter os
atributos ENDEREO, CIDADE, UF, CGC e INSCRIO ESTADUAL. Para chave
primria desta entidade vamos criar um atributo chamado CODIGO-DO-CLIENTE
que funcionar melhor como chave Primria do que NOME-DO-CLIENTE, deixando
este ltimo como simple atributo da entidade CLIENTE.

PEDIDO

Representao no ER

ITEM-DO-PEDIDO

PRODUTO

Um PEDIDO s feito por um e somente um CLIENTE e um CL1ENTE


pode fazer de zero (clientes que devem ser contatados mais freqentemente pelos
vendedores) at N elementos de PEDIDO. Um PEDIDO s tirado por um e somente
um VENDEDOR e um VENDEDOR pode tirai de zero (vendedores que devem ser
reciclados em termos de treinamento; para aumentar o poder de venda) a N elementos
de PEDIDO.

12.9 - Forma Normal de BOYCE / CODD (FNBC)


CLIENTE

As definies da 2FN e 3FN, desenvolvidas por Codd, no cobriam certos


casos. Esta inadequao foi apontada por Raymond Boyce em 1974. Os casos no
cobertos pelas definies de Codd somente ocorrem quando trs condies aparecem
juntas:
- a entidade tenha vrias chaves candidatas;
- estas chaves candidatas sejam concatenadas (mais de um
atributo);
- as chaves concatenadas compartilham pelo menos um atributo comum.

VENDEDOR

Na verdade, a FNBC uma extenso da 3FN, que no resolvia certas


anomalias presentes na informao contida em uma entidade. O problema foi
observado porque a 2FN e a 3FN s tratavam dos casos de dependncia parcial e
transitiva de atributos fora de qualquer chave, porm quando o

atributo observado estiver contido em uma chave (primria ou candidata), ele no


captado pela verificao da 2FN e 3FN.

segunda que contm os atributos que designam um professor em uma particular escola
e nmero de sala.

A definio da FNBC a seguinte: uma entidade est na FNBC se e somente


se todos os determinantes forem chaves candidatas. Notem que esta definio em
termos de chaves candidatas e no sobre chaves primrias.

FNBC

Considere a seguinte entidade FILHO:


FILHO

Por hiptese, vamos assumir que um professor possa estar associado a mais de
uma escola e uma sala. Sob esta suposio, tanto a chave (candidata) concatenada
NOME-DA-ESCOLA + SALA-DA-ESCOLA bem como NOME-DA-ESCOLA +
NOME-DO-PROFESSOR podem ser determinantes. Logo esta entidade atende s
trs condies relacionadas anteriormente:
as chaves candidatas para a entidade FILHO so: NOME-DO-FILHO +
ENDEREO-DO-FILHO, NOME-DO-FILHO + NUMERO-DASALA e NOME-DO-FILHO + NOME-DO-PROFESSOR;
- todas as trs chaves apresentam mais de um atributo (concatenados);
- todas as trs chaves compartilham um mesmo atributo: NOME-DOFILHO.
Neste exemplo, NOME-DO-PROFESSOR no completamente dependente
funcional do NUMERO-DA-SALA, nem NUMERO-DA-SALA completamente
dependente funcional do NOME-DO-PROFESSOR. Neste aso, NOME-DOPROFESSOR realmente completamente dependente funcional da chave candidata
concatenada NOME-DO-FILHO + NUMERO-)A-SALA ou NUMERO-DA-SALA
completamente dependente funcional ia chave candidata concatenada NOME-DOFILHO + NOME-DO-PROFESSOR.

SALA

Ao se aplicar FNBC, a entidade FILHO deve ser dividida em duas entidades,


uma que contm todos os atributos que descrevem o FILHO, e urna

12.10 - Quarta Forma Normal (4FN)


Na grande maioria dos casos, as entidades normalizadas at a 3FN so fceis
de entender, atualizar e de se recuperar dados. Mas s vezes podem surgir problemas
com relao a algum atributo no chave, que recebe valores mltiplos para um mesmo
valor de chave. Esta nova dependncia recebe o nome de dependncia multivalorada
que existe somente se a entidade contiver no mnimo trs atributos.
Uma entidade que esteja na 3FN tambm est na 4FN, se ela no contiver mais
do que um fato multivalorado a respeito da entidade descrita. Esta dependncia no
o mesmo que uma associao M:N entre atributos, geralmente descrita desta forma em
algumas literaturas.

Ex: Dada a entidade hipottica a seguir:

12.11 - Quinta Forma Normal (5FN)

CDIGO FORNECEDOR

CDIGO PEA

CDIGO COMPRADOR

1111
1111
1111
1111

BA3
CJ10
88A
BA3

113
113
435
537

Tabela 1
Como podemos observar, esta entidade tenta conter dois fatos multivalorados:
as diversas peas compradas e os diversos compradores. Com isso apresenta uma
dependncia multivalorada entre CDIGO-FORNECEDOR e o CDIGO-PEA e
entre CDIGO-FORNECEDOR e o CDIGO-COMPRADOR. Embora esteja na
3FN, ao conter mais de um fato multivalor, torna sua atualizao muito difcil, bem
como a possibilidade de problemas relativos ao espao fsico de armazenamento
poderem ocorrer, causados pela ocupao desnecessria de rea de memria (primria
ou secundria), podendo acarretar situaes crticas em termos de necessidade de mais
espao para outras aplicaes.
Para passarmos a entidade acima para a 4FN, necessria a realizao de uma
diviso da entidade original, em duas outras, ambas herdando a chave CDIGOFORNECEDOR e concatenado, em cada nova entidade, com os atributos CDIGOPEA e CDIGO-COMPRADOR.

Esta ltima forma normal trata do conceito de dependncia de iunco quando a


noo de normalizao aplicada decomposio, devido a uma operao de projeo,
e aplicada na reconstruo devido a uma juno.
A 5FN trata de casos bastante particulares, que ocorrem na modelagem de
dados, que so os relacionamentos mltiplos (ternrios, quaternrios n-rios). Ela fala
que um registro est na sua 5FN, quando o contedo deste mesmo registro no puder
ser reconstrudo (juno) a partir de outros registros menores, extrados deste registro
principal. Ou seja, se ao particionar um registro, e sua juno posterior no conseguir
recuperar as informaes contidas no registro original, ento este registro est na 5FN.
Vamos ilustrar o uso da 5FN utilizando um exemplo de relacionamento
ternrio, apresentado no livro do Prof. Waldemar Setzer [T81
Ex: Uma empresa constri equipamentos complexos. A partir de desenhos de
projeto desses equipamentos, so feitos documentos de requisies de materiais,
necessrios para a construo do equipamento; toda a requisio de um material d
origem a um ou mais pedidos de compra. A modelagem deste exemplo, ir mostrar
quais materiais de que requisies geraram quais pedidos. Na figura 12.2
apresentado este relacionamento ternrio.

FORNECEDOR-PEA

FORNECEDOR-COMPRADOR

Figura 12.2
A tabela 2, representante do relacionamento ternrio M-R-P, poderia conter os
seguintes dados:

MATERIAL PEDIDO DE COMPRA

REQUISIO

ROTOR 1BW

PC 0792

R1292

ROTOR 1BW

PC0992

R3192

PC0792

R3192

PC0792

R3192

Cl 102
ROTOR 1BW

Como resposta, podemos dizer que geralmente no possvel criar esta


decomposio sem perda de informao, armazenada no relacionamento ternrio.
Realizando uma projeo na tabela anterior, chegamos s entidades
apresentadas na figura 12.5.
ENTIDADE 1
MATERIAL

PEDIDO DE
COMPRA

ROTOR 1BW

PC 0792

ROTOR 1BW

PC0992

Cl 102

PC0792

Tabela 2
Utilizando uma soma de visualizao da dependncia de juno apresentada
por James Bradley[4], obtemos o seguinte grfico de dependncia de juno,
mostrado na figura 12.3.

ENTIDADE 2
PEDIDO DE
COMPRA

REQUISIO

PC 0792

RI 292

PC0992

R3192

PC0792

R3192

Figura 12.3
Uma pergunta surge sobre este problema: possvel substituir o
relacionamento ternrio por relacionamentos binrios, como os apresentados
na figura 12.4.

ENTIDADE 3
MATERIAL

REQUISIO

ROTOR 1BW

R1292

ROTOR 1BW

R3192
R3192

Figura 12.5
Se realizarmos, agora, um processo de juno destas trs entidades, terenos:
Figura 12.4

Inicialmente, vamos juntar a entidade 1 com a entidade 2, atravs do campo


pedido de compra. Obtemos ento a entidade 4 mostrada na figura 12.6;
ENTIDADE 4
MATERIAL

PEDIDO DE
COMPRA

REQUISIO

ROTOR 1BW

PC 0792

R1292

ROTOR 1BW

PC0992

R3192

Cl 102

PC0792

R3192

ROTOR 1BW

PC0792

R3192

Cl 102

PC0792

R1292

Figura 12.6
Podemos observar que o registro apontado pela seta no existia na tabela
original, ou seja, foi criado pela juno das tabelas parciais. Devemos
juntar a entidade 4, resultante da primeira juno, com a entidade 3,
atravs dos campos material e requisio. Aps esta ltima operao de
juno, obtemos a entidade 5, mostrada na figura 12.7.
ENTIDADE 5

Como se pode notar, ao se juntar as trs entidades, fruto da decomposio da


entidade original, as informaes destas foram preservadas. TSto significa que o
relacionamento M-R-P no est na 5FN, sendo necessrio decomp-lo em
relacionamentos binrios, os quais estaro na 5FN.
A definio da 5FN diz que: uma relao de 4FN estar em 5FN, quando seu
contedo no puder ser reconstrudo (existir perda de informao) a partir das diversas
relaes menores que no possuam a mesma chave primria. Esta forma normal trata
especificamente dos casos de perda de informao, quando da decomposio de
relacionamentos mltiplos.
Com a 5FN, algumas redundncias podem ser retiradas, como a informao de
que o "ROTOR 1BW" est presente na requisio "R3192", ser armazenada uma
nica vez, a qual na forma no normalizada pode ser repetida inmeras vezes.

12.12 - Roteiro de Aplicao da Normalizao


Entidade ou documento no normalizado, apresentando grupos repetitivos e
certas anomalias de atualizao.
aplicao da 1FN
- Decompor a entidade em uma ou mais entidades, sem grupos
repetitivos;
- Destacar um ou mais atributos como chave primria da(s) nova(s)
entidade(s), e este ser concatenado com a chave primria da entidade
original.;
- Estabelecer o relacionamento e a cardinalidade entre a(s) nova(s)
entidade(s) gerada(s) e a entidade geradora;
- Verificar a questo da variao temporal de certos atributos e criar
relacionamentos 1:N entre a entidade original e a entidade criada por
questes de histrico.

MATERIAL

PEDIDO DE
COMPRA

REQUISIO

ROTOR 1BW

PC 0792

R1292

ROTOR 1BW

PC0992

R3192

Cl 102

PC0792

R3192

=> ENTIDADES NA 1FN

ROTOR 1BW

PC0792

R3192

aplicao da 2FN
- Para entidades que contenham chaves primrias concatenadas,
destacar os atributos que tenham dependncia parcial em relao
chave primria concatenada;

Figura 12.7

to de Banco de Dados

- Criar uma nova entidade que conter estes atributos, e que ter como
chave primria o(s) atributo(s) do(s) qual(quais) se tenha dependncia
parcial;
- Sero criadas tantas entidades quanto forem os atributos da chave
primria concatenada, que gerem dependncia parcial- Estabelecer o relacionamento e a cardinalidade entre a(s) novas
entidade(s) gerada(s) e a entidade geradora.
=> ENTIDADES NA 2FN
aplicao da 3FN
- Verificar se existem atributos que sejam dependentes transitivos de
outros que no pertencem chave primria, sendo ela concatenada ou
no, bem como atributos que sejam dependentes de clculo realizado a
partir de outros atributos;
- Destacar os atributos com dependncia transitiva, gerando uma nova
entidade com este atributo e cuja chave primria o atributo que
originou a dependncia;
- Eliminar os atributos obtidos atravs de clculos realizados a partir de
outros atributos.
Z> ENTIDADES NA 3FN

Normalizao

- Retirar estes atributos no chaves e multivalorados, criando


novas entidades individuais para cada um deles, herdando a
chave primria da entidade desmembrada.
=> ENTIDADES NA 4FN
aplicao da 5FN
- Aplicada em elementos que estejam na 4FN;
- A ocorrncia deste tipo de forma normal est vinculada aos
relacionamentos mltiplos (ternrios, etc.) ou entidades que possuam
chave primria concatenada com trs ou mais atributos;
- Verificar se possvel reconstruir o contedo do elemento original a
partir de elementos decompostos desta;
- Se no for possvel, o elemento observado no est na 5FN, caso
contrrio os elementos decompostos representam um elemento na 5FN.
=> ENTIDADES NA FORMA NORMAL FINAL
O processo de normalizao leva ao refinamento das entidades, retirando delas
grande parte das redundncias e inconsistncias. Naturalmente, para que haja uma
associao entre entidades preciso que ocorram redundncias mnimas de atributos
que evidenciam estes relacionamentos. Sem estas redundncias no haveria
relacionamento entre entidades.

aplicao da FNBC
- S aplicvel em entidades que possuam chaves primrias e candidatas
concatenadas;
- Verificar se alguma chave candidata concatenada um determinante, e
em caso afirmativo, criar uma entidade com os que dependam
funcionalmente deste determinante e cuja chave primria o prprio
determinante.
=> ENTIDADES NA FNBC
aplicao da 4FN

12.13 - Desnormalizao
Parece um tanto quanto incoerente, em um captulo sobre normalizao,
apresentar um item falando sobre desnormalizao. Porm os processos de sntese de
entidades vistos at aqui levam criao de novas entidades e relacionamentos.
Os novos elementos criados podem trazer prejuzos na hora de serem
implementados em um SGDB. Devido as caractersticas de construo fsica de certos
bancos de dados, algumas entidades e relacionamentos devem ser desnormalizados
para que o SGBD tenha um melhor desempenho.

- Para se normalizar em 4FN, a entidade tem que estar (obrigatoriamente)


na 3FN;
- Verificar se a entidade possui atributos que no sejam participantes da
chave primria e que sejam multivalorados e independentes em relao
a um mesmo valor da chave primria;
177

Hoje em existe um grande debate sobre as chamadas semnticas da


normalizao, sua utilidade e falicilidade em relao implementao fsica em um
sistema computacional.
Vrios estudos e algumas consideraes esto sendo realizados, e se chega at
a utilizao de banco de dados relacionais no normalizados [18] por apresentarem
maior ligao com a realidade e por terem vnculos matemticos mais amenizados.
Outro aspecto da normalizao que todas as definies sobre as formas
normais aps a 1FN, ainda no foram exaustivamente examinadas propiciando assim
grandes controvrsias. A reduo das anomalias de atualizao devido s formas
normais de alta ordem sofre os ataques bvios dos grandes problemas (fsicos) de
atualizao, pois as relaes esto excessivamente normalizadas e com isso uma
simples alterao pode encadear um efeito cascata bastante profundo no banco de
dados, ocasionando um aumento bastante significativo no tempo.
Infelizmente, os argumentos que podem viabilizar o processo de
desnormalizao sofrem de uma deficincia e aderncia matemtica.
Pesquisas recentes indicam que as estruturas desnormalizadas (apelidadas de
forma normal no primeira) tm um atrativo matemtico similar ao que foi o da
normalizao. Estas pesquisas esto provendo recentes definies sobre lgebra
relacionai desnormalizada e extenses linguagem SQL para a manipulao de
relaes desnormalizadas.
Ao se optar pela desnormalizao, deve-se levar em conta o custo da
redundncia de dados e as anomalias de atualizao decorrentes.
Chegou-se concluso tambm que o esprito da normalizao contradiz
vrios princpios importantes, relativos modelagem semntica e a construo de
bases de dados em SGBD orientados por objeto. Este assunto, como j foi dito
anteriormente, fica para um prximo encontro entre ns e vocs, caros leitores.

12.14 - Consideraes Finais Sobre Normalizao


Antes de qualquer concluso, podemos observar que as formas normais nada
mais so do que restries de integridade, e medida que se alimenta este grau de
normalizao, tornam-se cada vez mais restritivas-

dependendo do SGBD relacionai utilizado, essas restries podem se tornar benficas


ou no.
A forma de atuao da normalizao no ciclo de vida de um projeto de bases
de dados pode ser mais satisfatria no desenvolvimento (botton - up) de modelos
preliminares, a partir da normalizao da documentao existente no ambiente
analisado, bem como de arquivos utilizados em alguns processos automatizados neste
ambiente.
No caso do desenvolvimento top - dozvn, no qual um modelo de dados
criado a partir da visualizao da realidade, a normalizao serve para realizar um
aprimoramento deste modelo, tornando-o menos redundante e inconsistente. No caso
desta viso, a normalizao torna-se um poderoso aliado da implementao fsica do
modelo.
Por experincia, podemos afirmar que a construo de um modelo de dados j
leva naturalmente ao desenvolvimento de entidades e relacionamentos na 3FN,
ficando as demais (FNBC, 4FN e 5FN) para melhorias e otimizaes.
A criao de modelos de dados, partindo-se da normalizao de documentos e
arquivos pura e simplesmente, no o mais indicado, pois na verdade estaremos
observando o problema e no dando uma soluo para ele. Neste caso, estaremos
projetando estruturas de dados que se baseiam na situao atual (muitas vezes catica)
e que certamente no vo atender s necessidades reais do ambiente em anlise. Ao
passo que, se partirmos para a criao do modelo de dados com entidades e
relacionamentos aderentes realidade em estudo (mundo real), vamos naturalmente
desenvolver uma base de dados ligada viso da realidade e como conseqncia
iremos solucionar o problema de informao.
A aplicao da modelagem de dados, ao longo da nossa vida profissional, tem
sido bastante gratificante, mostrando principalmente, que a tcnica de normalizao
uma ferramenta muito til como apoio ao desenvolvimento do modelo de dados. Seja
ela aplicada como levantamento inicial (documentos e arquivos) bem como
otimizadora do modelo de dados, tendo em vista certas restries quanto
implementao fsica nos bancos de dados conhecidos.
Todas as idias sobre eficincia da normalizao passam necessariamente
sobre tempo e espao fsico, em funo, principalmente, das consultas efetuadas pelos
usurios bem como a quantidade de bytes necessrios para guardar as informaes.

atravs da observao, que o projeto do modelo conceituai nem


sempre pode ser derivado para o modelo fsico final. Com isso, de grande
importncia que o responsvel pela modelagem (analista, AD, etc.) no conhea s a
teoria iniciada por Peter Chen, mas tambm tenha bons conhecimentos a respeito do
ambiente de banco de dados utilizado pelo local em anlise.

O Modelo Lgico
Relacionai

Criado por Edgar F. Codd, nos anos 70 [6], comeou a ser realmente utilizado
nas empresas a partir de 1987. A abordagem relacionai est baseada no princpio de
que as informaes em uma base de dados podem ser consideradas como relaes
matemticas e que esto representadas de maneira uniforme, atravs do uso de tabelas
bidimensionais. Este princpio coloca os dados (entidades e relacionamentos)
dirigidos para estruturas mais simples de armazenar dados, que so as tabelas, e nas
quais a viso do usurio privilegiada.
Definio Clssica: So conjuntos de dados vistos segundo um conjunto de
TABELAS (figura 13.1) e as operaes sobre elas (tabelas) so feitas por linguagens
que manipulam a lgebra relacionai, no sendo procedurais, ou seja, manipulando
conjuntos de uma s vez.
Produto
CDProd

Descrio Quant-Est

Compra
cdP

CDCO

Quant.

Preo

Comprador
CDCO

Endereo

Melhoria na segurana dos dados;


Mais agilidade na questo gerencial da informao ligada ao
processo decisrio da organizao.

Histrico

13.2 - As 12 Regras de Codd


Exemplos: DB2, INGRES, ORACLE, PROGRESS, XDB, etc .................
Figura 13.1

Codd, ao definir o modelo relacionai, estabeleceu um conjunto de 12 regras


para a determinao de um banco de dados ser realmente relacionai. Segundo estas
regras, discute-se a fidelidade de um SGBD ao modelo relacionai [7]. Raros so os
bancos de dados que se enquadrem em mais do que 10 destas regras.
As regras de Codd so:

O conceito principal vem da teoria dos conjuntos (lgebra relacionai) atrelado


idia de que no relevante ao usurio saber onde os dados esto nem como os
dados esto (transparncia). Os usurios manipulam objetos dispostos em linhas e
colunas das tabelas (figura 13.2) . O usurio, para lidar com estes objetos, conta com
um conjunto de operadores e funes de alto nvel, constantes na lgebra relacionai.
VISO LGICA DE DADOS

1 - Toda informao num banco de dados relacionai apresentada a nvel


lgico por valores em tabelas;
2- Todo dado em um banco de dados relacionai tem a garantia de ser
logicamente acessvel, recorrendo-se a uma combinao do nome da
tabela, um valor de chave e o nome da coluna;
3 - Tratamento sistemtico de valores nulos (ausncia de dado);

SAFRA

BRANCO

87

PRODT.

MARCA

86

BRANCO

01

CLOS DE NOBLES

87

TINTO

01

CLOS DE NOBLES

86

BRANCO

05

FORESTIER RIESL.

85

TINTO

03

GRANJA UNIO

07

TIPO

4-

O dicionrio de dados (catlogo) relacionai ativo baseado no modelo


relacionai;

5-

O SGBD relacionai deve ter uma linguagem para definio, detalhamento


e manipulao dos dados;

ALMADEN CORD.

6 - Tratamento das atualizaes de vises dos dados;


COMO O USURIO V SEUS DADOS

7-

Tratamento de alto nvel para insero, atualizao e eliminao de


dados;

8-

Independncia dos dados fsicos (mudana na memria e no mtodo de


acesso);

Figura 13.2

13.1 - Principais Vantagens da Abordagem Relacionai

Independncia total dos dados;


Viso mltipla dos dados;
Melhor comunicao entre CPD e usurio;
Reduo acentuada na atividade de desenvolvimento de aplicaes e o
tempo gasto em manuteno;

9 - Independncia de dados lgicos (mudanas de qualquer


tipo nas tabelas bsicas, ex: diviso de uma tabela por linha ou coluna);
10 - Independncia das restries de integridade;
183

11 - Independncia de distribuio;
12 - No subverso das regras de integridade
quando se utiliza uma linguagem de baixo nvel.

ou

restries

13.3 - Chaves e ndices


Chave designa o conceito de item de busca, ou seja, um dado que ser
empregado nas consultas base de dados. um conceito lgico da aplicao;
ndice um recurso fsico visando otimizar a recuperao de uma informao,
via um mtodo de acesso. Seu objetivo principal est relacionado com a
performance de um sistema.
Uma chave pode ser utilizada como ndice, mas um ndice no
necessariamente uma chave. A forma de criao do ndice depende do ambiente
relacionai.
Ex. lista invertida (ADABAS), rvore B+ (DB2)

13.4 - O Conceito de Chave no Modelo Relacionai


> Chave PRIMRIA (primary key): o atributo de uma tabela que
identifica univocamente uma tupla.
Uma chave primria no tem nenhuma ligao com o conceito de ordenao e
com o acesso tabela, pois declarar um atributo como primrio e acessar a tabela por
outro atributo, serve para manter duas restries de integridade determinadas por
Codd.
> Chave SECUNDRIA (secundary key): Serve para definir uma
segunda chave primria. Identifica sempre um item de busca,
atravs do qual desejamos recuperar uma informao ou um
conjunto de informaes. o atributo de uma tabela que identifica
um subconjunto de tuplas onde este subconjunto pode ter apenas
uma tupla. No ambiente tradicional, s posso acessar um registro se
declarar que aquele campo chave. No ambiente relacionai, uma
tabela acessvel por qualquer campo (atributo) independente deste
ser declarado como chave ou no.

Usamos normalmente a declarao de chave secundria para agilizar o acesso


quela tabela naquele campo (atributo).
Para cada chave secundria declarada, o ambiente relacionai cria um ndice
(estratgia de acesso). Qualquer campo pode ser chave secundria.
> Chave CANDIDATA: Uma tabela relacionai pode possuir alternativas de
identificador nico, ou seja, vrias colunas ou concatenaes diferentes de
colunas podem ter esta propriedade. Estes identificadores so candidatos
chave primria, como um e somente um ser escolhido como chave
primria, o restante passa a ser considerado como chave alternativa.
> Chave ESTRANGEIRA (foreign key): As chaves estrangeiras constituem
um conceito de vital importncia no modelo relacionai. So os elos de
ligao entre as tabelas.
Quando dizemos que duas tabelas esto relacionadas atravs de atributos
comuns, devemos observar que provavelmente esta coluna em uma das tabelas uma
chave primria. Na outra tabela, este atributo ir caracterizar o que denominado de
chave estrangeira, propiciando, assim, uma ligao lgica (relacionamento) entre as
tabelas.
0 CONCEITO DE CHAVE NO MODELO RELACIONAI.
Cod. Projeto

Nome do Projeto

Tipo do Projeto

Departamento

SFT

Sist. Faturamento

001-1

ANLISE

CAP

Contas a Pagar

002-N

PROGRAMAO

ADP

Modulo de Cadastro

004-E

ANALISE

COB-2

Cobrana Filial RIO

002-N

DIRETORIA SISTEMAS

PAG

Folha de Pagamento

007-E

Verba
16.000

Nome do Departamento
ANALISE

22.000

PROGRAMAO

G.000

DIRETORIA SISTEMAS

2.500

OPERAO

1.000

OIM

PROGRAMAO

Tipo

Descrio

001-I
002-N
005-1
004-E
007-E

PROTTIPO
NOVO SISTEMA
ESTUDO
EXPANSO
ADEQUAO

13.5 - Regras de Integridade do Modelo Relacionai

Existem regras precisas que no do margem a erros sendo que uma


vez projetado o ER, as tabelas que representam o ER num nvel mais baixo
podem ser obtidas de forma clara. evidente que nesta passagemdevem ser devem
ser

1- Integridade de Identidade (ou entidade)


A chave primria no pode conter um valor nulo (NULL). O NULL no o
valor 0 (zero) nem o caractere branco, simplesmente a no-existncia de contedo
neste campo.

observadas as caractersticas do SGBD que ser utilizados, pois diferenas que


podem auxiliar ou dificultar algumas solues
Alguns SGBD's necessitam de adaptaes especficas.

2- Integridade Referencial
Se uma determinada tabela A possui uma chave estrangeira, a qual chave
primria em uma outra tabela B, ento ela deve:
ser igual a um valor de chave primria existente em B; ou
ser NULA (NULL).
No pode existir na chave estrangeira, um valor que no exista na tabela na
qual ela chave primria.
As regras de integridade do modelo relacionai representam a garantia de que
as tabelas guardam informaes compatveis. So de extrema importncia para a
confiabilidade das informaes contidas no banco de dados.

13.6 - Caractersticas do Modelo Relacionai


1 - Uma tabela acessvel por qualquer campo
independente se este declarado como chave ou no;

As chaves das entidades fracas so formadas pelos atributos indicados,


precedidos pelos atributos que compem a chave primria das entidades das
entidades qual ela fraca.
Voc v um retngulo, o que fazer? Transform-lo em uma tabela, no tem
como errar.

(atributo)

2 - O relacionamento entre conjunto de dados (tabelas) no existe


fisicamente, pois este relacionamento apenas lgico e
representado atravs das chaves estrangeiras;
3 - Utilizao de linguagens auto-contidas e no procedurais;
4 - Os ambientes relacionais possuem um otimizador estratgico
para escolher o melhor caminho para recuperao dos dados.

13.7 - Derivao do Modelo E-R para o Modelo


Relacional
Nesta etapa, o desenvolvedor ir passar as vises do modelo conceitual para o
modelo lgico relacional, no qual os dados so vistos como estruturas de
dados voltadas para as caractersticas do modelo lgico escolhido, visando
a implementao do banco de dados.

Regras de Converso

=> Mapeamento das ENTIDADES: Toda entidade torna-se uma tabela


carregando todos os atributos (definidos para a entidade) Cada atributoum campo da
tabela criada. Cada uma das chaves gera "estruturas de acesso". A chave primria e
as chaves candidatas so projetadas para no permitir ocorrncias mltiplas e nem
admitem nulos.

Por que no tem como errar? Porque estamos falando de um modelo


conceituai previamente elaborado e validado junto com o usurio processos que vo
trabalhar em cima desses dados.
Ex. Processo: dado um banco de dados empregado e departamento O
usurio olha para o banco e diz: Quero um relatrio que imprima o nmero de
empregados que cada departamento tem, a voc valida: esses dados respondem
ao relatrio que o usurio quer? sim - est legal; no tenho de ajustar o banco de
dados pois no vai responder necessidade do usurio A validao sempre com o
usurio, ele confirma e v se o meu banco responde

=> Mapeamento dos ATRIBUTOS: Os atributos das entidades e relacionamentos


(que
possuam
atributos)
devem
ser
gerados
na
ordem
que
minimize o consumo de espao de armazenamento e torne mais eficiente a
recuperao. Devem ser exploradas todas as caractersticas de SGBD em uso
Para tanto, deve ser considerado se os campos tm ou no a especificao de
extenso em bytes, se existe localizao no interior do registro que propicie
vantagens na recuperao e se existe compactao de espaos no ocupados.
=>

Funcionrio

Departamento

Mapeamento dos RELACIONAMENTOS


As alternativas possveis so divididas em dois grandes grupos:
Navegao incorporada: trabalha diretamente com o conceito de
chave estrangeira;
Navegao disjunta: trabalha sem a modificao das definies dos
registros j existentes, criando novos registros (entidades) diferentes
dos existentes, que tm a finalidade de propiciar a navegao.

Neste livro, iremos utilizar as alternativas do primeiro grupo (navegao


incorporada), por ser mais simples e de uso mais comum hoje em dia. A segunda
alternativa ser utilizada na questo dos relacionamentos
N:M.
=>

Relacionamento - 1:N (envolvendo entidades distintas)

A entidade (tabela) cuja conectividade N carrega o identificador da entidade


(tabela) cuja conectividade 1 (chave estrangeira), e os atributos do relacionamento,
se houver ( praticamente impossvel aparecer em relacionamentos 1:N e 1:1 algum
atributo, pois neste nvel j se consegue enxergar quem o dono do dado). Ou seja,
quem est com o 'N' do lado carrega a chave do outro.

=> Relacionamento - 1:N (envolvendo auto-relacionamento)


Incluir a chave primria da entidade na prpria entidade como chave
estrangeira, gerando uma estrutura de acesso a partir desta chave estrangeira.
Pea
Cd.

Nome

Etc.

Cdch

4534

Correia

G547

Parafuso

7734

Freio

...

6547

1198

Carburador

...

6547

Compe

=> Relacionamento -1:1 (envolvendo entidades distintas)


As entidades (tabelas) envolvidas neste relacionamento carregaro o
identificador da outra (uma ou outra ou ambas) conforme a convenincia do Projeto
(de acordo com o acesso a essas tabelas).

Segundo a nossa definio, carregar o identificador da outra (uma ou outra ou

ambas). Se no acesso, as operaes que manipulam esse banco de dados so operaes


que manipulam muito o conjunto de DEPARTAMENTO, ento seria conveniente
colocar a matrcula do funcionrio no conjunto DEPARTAMENTO e, se for
FUNCIONRIO o mais operado colocamos o Cdigo do departamento em
Funcionrio, se manipula os dois coloca-se nos dois.
=> Relacionamento -1:1 (envolvendo auto-relacionamento)
Incluir a chave primria da entidade na prpria entidade (chave
estrangeira) e gerar uma estrutura de acesso para ela.

> Relacionamento - M:N

(envolvendo entidades distintas e auto-

relacionamento)
O relacionamento torna-se uma tabela carregando os atributos (se houver) e os
identificadores das tabelas (entidades) que ele relaciona.
Esse o nico caso em que um relacionamento torna-se uma tabela, (figuras
na prxima pgina)

Nome Disciplina

PrRequisito
Cd. CPr

Qumica I

123

888

Disciplina
Cd. Disciplina
666
123

Clculo III

491

324

324

Fsica I

491

888

888

Clculo II

666

324

491

Fsica II

=> As generalizaes
Ex: dado o conjunto 'funcionrio', existe uma variao para este, tem um ponto
bsico para os funcionrios que so engenheiros pois os mesmos tm informaes
adicionais, estes dados adicionais no subconjunto 'engenheiro', para o vendedor
existem outros dados que no seriam semelhantes aos de engenheiro.
O artifcio, pois no posso ter campos com tamanho varivel, criar
subconjuntos para os casos em que as informaes variam.
Um elemento de 'funcionrio' s pode ter em um e somente um subconjunto.

=> Relacionamento mltiplo


O relacionamento mapeado em uma tabela e so geradas tantas estruturas
de acesso quanto for o grau do relacionamento. A chave primria de cada uma das
entidades associadas gera uma estrutura de acesso. A chave desta nova tabela a
concatenao das chaves estrangeiras.

As informaes dos engenheiros sero completadas pelo subconjunto


'engenheiro'.

Se no tivesse atributo diferente para os outros, todos os que no em


fossem engenheiros ou vendedores s teriam seus dados no conjunto
funcionrio'.

No possvel, um empregado cuja funo engenheiro, atuar corno


vendedor, porque os elementos no podem se sobrepor.
Os subconjuntos tornam-se tabelas carregando o identificador do conjunto ao
qual pertencem.

SQL

14.1 - A Importncia da Linguagem SQL


O nome "SQL" significa "Structured Query Language" - Linguagem
Estruturada de Pesquisa. Essa linguagem, de grande utilizao, teve seus fundamentos
no modelo relacionai de Codd (1970). Sua primeira verso recebeu o nome de
SEQUEL ("Structured English Query Language"), sendo definida por D. D.
CHAMBERLIN, entre outros, em 1974, nos laboratrios de pesquisa da IBM
(Califrnia). Em 1975, foi implementado um prottipo de aplicao dessa nova
linguagem. Entre 1976 e 1977, o SEQUEL foi revisado e ampliado, e teve seu nome
alterado para "SQL" por razes jurdicas.
Com esta reviso foi posto em prtica um projeto ambicioso da IBM chamado
System R. Novas alteraes foram introduzidas na SQL, graas s idias
apresentadas pelos diversos usurios do ambiente.

A garantia de no-sobreposio dos subconjuntos uma restrio de


integridade que deve ser expressa na linguagem de acesso ao banco de dados (ex:
SQL).
O conjunto 'funcionrio' vira uma tabela (regra padro) e os subconjuntos
sero transformados em outras tabelas, carregando a chave primria matrcula.

Devido ao sucesso dessa nova forma de consulta e manipulao de dados,


dentro de um ambiente de banco de dados, a utilizao da SQL foi se tornando cada
vez maior. Com isso uma grande quantidade de SGBD's foi tendo como linguagem
bsica a SQL - SQL/DS e DB2 da IBM, ORACLE da Oracle Corporation, RDB da
Digital, SYBASE da Sybase INC, e Microsoft SQL Server, entre outros.
A SQL se tornou um padro de fato, no mundo dos ambientes de banco de
dados relacionados. Bastava agora se tornar de direito. Ento, em 1982, o American
National Standard Institute (ANSI) tornou a SQL padro oficial de linguagem em
ambiente relacionai.
Infelizmente, como todo padro que se preze, existem hoje vrios dialetos
SQL, cada um, evidentemente, tentando ser mais padronizado que o

outro. Neste captulo, iremos seguir o padro ANSI da SQL, tentando ser o mais
isento possvel de implementaes especficas de cada fabricante.
Como vimos no captulo anterior, o modelo relacionai constitudo
basicamente de tabelas, cada qual contendo linhas (registros, tuplas) e colunas. Os
registros na tabela no so ordenados e sua localizao se faz por meio de um campochave, ou seja, um campo que assume o papel de chave primria da tabela. por
intermdio dessa chave que se identifica uma, e somente uma, ocorrncia do valor
contido no campo.
Uma das razes da popularidade dos sistemas relacionais a sua facilidade de
manipulao e entendimento.
A linguagem SQL foi desenvolvida especialmente para o ambiente relacionai,
podendo ser adaptada a qualquer ambiente no relacionai.

14.2 - A Linguagem SQL


A idia original da SQL s previa seu uso de forma interativa. Aps sofrer
alguns acrscimos, ela passou tambm a ter capacidade de ser utilizada em linguagens
hospedeiras, tais como: COBOL, FORTRAN, "C", etc.

Atualmente, a linguagem SQL assume um papel muito importante nos sistemas


de gerenciamento de banco de dados, podendo ter muitos enfoques, como apresenta a
figura 14.1:
Linguagem interativa de consulta (query AdHoc)- Por meio de
comandos SQL, os usurios podem montar consultas poderosas sem a
necessidade da criao de um programa, podendo utilizar Forms ou
ferramentas de montagem de relatrio;
Linguagem de programao para acesso a banco de dados Comandos SQL embutidos em programas de aplicao que acessam os
dados armazenados;
Linguagem de administrao de banco de dados - O responsvel
pela administrao do banco de dados (DBA) pode utilizar
comandos SQL para realizar suas tarefas;
Linguagem cliente/servidor - Os programas (cliente) dos computadores
pessoais usam comandos SQL para se comunicarem por meio de uma rede
local, compartilhando os dados armazenados em um nico local (servidor).
A arquitetura cliente/servidor minimiza o trfego de dados pela rede;
Linguagem para banco de dados distribudo - A SQL auxilia na
distribuio dos dados por meio de vrios ns conectados ao sistema de
computao. Auxilia tambm na comunicao de dados com outros
sistemas;
Caminho de acesso a outros bancos de dados em diferentes
mquinas - A SQL auxilia na converso entre diferentes produtos
de banco de dados colocados em diferentes mquinas (de micro at
mainframe).
Por ser uma linguagem de numerosas aplicaes, a SQL pode manipular
objetos de diferentes classes (figura 14.2) entre as funes de um SGBD:

Figura 14.1

14.3 - Vantagens e Desvantagens da Linguagem SQL


Com o uso e a padronizao da SQL, algumas vantagens so diretas:
Independncia de fabricante - A SQL oferecida em praticamente todos
os SGBD's, e os que ainda no tm esto se encaminhando para l. Com
isso posso mudar de SGBD sem me preocupar com o novo que vai chegar;
Portabilidade entre computadores - A SQL pode ser utilizada desde um
computador pessoal, passando por uma estao de trabalho, at um
computador de grande porte;
Reduo dos custos com treinamento - Baseado no item anterior, as
aplicaes podem se movimentar de um ambiente para o outro sem que seja
necessria uma reciclagem da equipe de desenvolvimento;
Ingls estruturado de alto nvel - A SQL formada por um conjunto bem
simples de sentenas em ingls, oferecendo um rpido e fcil entendimento;

Figura 142
Definio de dados (DDL) - permite ao usurio a definio da estrutura e
organizao dos dados armazenados, e as relaes que existem entre eles;
Manipulao de dados (DML) - permite ao usurio ou a um programa de
aplicao, a incluso, remoo, seleo ou atualizao de dados
previamente armazenados no banco;
Controle de acesso - protege os dados de manipulaes no autorizadas;
Compartilhamento de dados - coordena o compartilhamento dos dados
por usurios concorrentes, sem contudo interferir na ao de cada um
deles;
Integridade dos dados - auxilia no processo de definio da integridade
dos dados, protegendo contra corrupes, inconsistncias e falhas do
sistema de computao.

Consulta interativa - A SQL prove um acesso rpido aos dados


fornecendo respostas ao usurio, a questes complexas, em minuto ou
segundos;
Mltiplas vises dos dados - A SQL permite ao criador do banco de dados
levar diferentes vises dos dados a diferentes usurios;
Definio dinmica dos dados - Por meio da SQL, podem-se alterar,
expandir ou incluir, dinamicamente, as estruturas dos dado armazenados
com a mxima flexibilidade;
Apesar de todas essas vantagens, algumas crticas so dirigidas SQL:
A padronizao leva a uma, natural, inibio da criatividade, pois quem
desenvolve aplicaes fica preso a solues padronizadas no podendo
sofrer melhorias ou alteraes;
A SQL est longe de ser uma linguagem relacionai ideal - Segundo C. J.
Date, em seu livro "Relational Database: selected Writin (Addison Werley, 1986)", algumas crticas so feitas linguagei SQL:

- Falta de ortogonalidade nas expresses, funes embutidas,


variveis indicadoras, referncia a dados correntes, constante
NULL, conjuntos vazios, etc;
- Definio formal da linguagem aps sua criao;
- Discordncia com as linguagens hospedeiras;
- Falta de algumas funes;
- Erros (valores nulos, ndices nicos, clusula FROM, etc);
- No d suporte a alguns aspectos do modelo relacionai (atribuio
de relao, join explcito, domnios, etc):
Mesmo enfrentando alguns problemas e crticas, a linguagem SQL veio
para ficar, auxiliando de forma bastante profunda a vida dos usurios e
analistas no trabalho de manipulao dos dados armazenados em um banco de
dados relacionai. E sobre esse auxlio que este captulo ir tratar, mostrando
comandos e funcionalidades da SQL, por meio de exemplos prticos. No
iremos mostrar todos os comandos, principalmente os que foram definidos para
serem utilizados dentro de uma linguagem hospedeira (cursor); apresentaremos
os comandos para criao, atualizao, alterao, pesquisa e eliminao de
tabelas dentro de um ambiente relacionai tpico.
Alm dos comandos da SQL padro ANSI, vamos apresentar a sintaxe
de comandos SQL efetuados no SGBD ORACLE da Oracle Corporation e
MS-SQL Server 7.0, um produto da Microsoft .

14.4 - O Exemplo
Todo o nosso percurso pela linguagem SQL ser efetuado com base no
exemplo de modelo de dados apresentado na figura 14.3, criado no captulo 13
sobre Normalizao.

Figura 143
Na figura 14.4, so apresentadas as tabelas referentes ao modelo da
figura 14.3.
TABELA CLIENTE

TABELA ITEM_DO_PEDIDO (continuao)

TABELA VENDEDOR
Cdigo do
vendedor

Nome do
vendedor

Salrio
Fixo

Faixa de
Comisso

209
111
11
240
720
213
101
310
250

Jos
Carlos
Joo
Antnio
Felipe
Jonas
Joo
Josias
Maurcio

1.800,00
2.490,00
2.780,00
9.500,00
4.600,00
2.300,00
2.650,00
870,00
2.930,00

C
A
C
C
A
A
C
B
B

TABELA PEDIDO
Nmero do
Pedido
121
97
101
137
148
189
104
203
98
143
105
111
103
91
138
108
119
127

Prazo de
Entrega

Cdigo do
Cliente

Cdigo do
Vendedor

20
20
15
20
20
15
30
30
20
30
15
20
20
20
20
15
30
10

410
720
720
720
720
870
110
830
410
20
180
260
260
260
260
290
390
410

209
101
101
720
101
213
101
250
209
111
240
240
11
11
11
310
250
11

TABELA ITEM_DO_PEDIDO
Nmero do
pedido

Cdigo do
produto

Quantidade

121
121
97
101

25
31
77
31

10
35
20
9

Figura 14.4 (continuao)

Nmero do
pedido

Cdigo do
produto

Quantidade

101
101
98
148
148
148
148
148
104
203
189
143
143
105
111
111
103
91
138
138
138
108
119
119
119
119
137

78
13
77
45
31
77
25
78
53
31
78
31
78
78
25
78
53
77
22
77
53
13
77
13
22
53
13

18
5
5
8
7
3
10
30
32
6
45
20
10
10
10
70
37
40
10
35
18
17
40
6
10
43
8

TABELA PRODUTO
Cdigo do
produto

Unidade do
produto

Descrio do
produto

Valor
unitrio

25
31
78
22
30
53
13
45
87
77

Kg
BAR
L
M
SAC
M
G
M
M
M

Queijo
Chocolate
Vinho
Linho
Acar
Linha
Ouro
Madeira
Cano
Papel

0,97
0,87
2,00
0,11
0,30
1,80
6,18
0,25
1,97
1,05

Figura 14.4 (continuao)

As informaes armazenadas nas tabelas da figura 14.4 sero


utilizadas pelos comandos SQL, apresentados ao longo deste captulo.

14.4.1 - Viso Grfica do Exemplo

Server, o comando utilizado o DISK INIT, entretanto, no sendo objeto de nosso


estudo.
b) Criar os databases nos devices j criados anteriormente.
Para isto iremos usar no MS-SQL Server o comando CREATE
DATABASE com a seguinte sintaxe:
CREATE DATABASE database_name

[ON {DEFAJLT| database_device} [= size]


[,database_device [= size) ]...] [LOG
ON database_device [= size]
[, database__device [= size] ] . . . ]
[FOR LOAD]

Um exemplo:
1. CREATE DATABASE vendas

Cria o database vendas no device default com tamanho default de 2 MB.


2. CREATE DATABASE vendas ON default = 256
Cria o Database Vendas no device default com 256 Mb.

14.4.2 - Criao e Distribuio de Tabelas


Para podermos criar e inserir as tabelas de uma aplicao em Banco de Dados,
dependendo do ambiente de SGBD que estivermos utilizando, criar o DATABASE,
ou seja criar um banco de dados no qual estaro residentes as tabelas de nosso
sistema.
Esta operao, no Microsoft SQL Server, por exemplo, realizada
normalmente por equipes de suporte, e consiste em dois passos, no mnimo, que pela
ordem so:
a) Inicializar os arquivos em que sero armazenados os DATABASES de
nossas aplicaes ( devices);
Esta uma criao de nomes fsicos e lgicos e determinao do tamanho da
rea em meio magntico desse device; no Microsoft-SQL

3. CREATE
DATABASE
novosdados = 2 5

vendas

ON

default

50,

Cria o Database Vendas e aloca 50 Mb no device default, e 25 Mb no device


NovosDados.
4. CREATE DATABASE vendas ON library_devl = 10 LOG
ON librlog_dev2 = 4

Cria o DataBase Vendas e aloca 10 Mb em library_devl e coloca 4 Mb para


log de transaes num device separado chamado librlog_dev2.

Uma vez que j criamos o DataBase, ou seja, o nosso banco de dados da


aplicao, podemos ento partir para criar as nossas tabelas.
O comando CREATE TABLE cria a tabela solicitada e obedece seguinte
forma:
Na linguagem SQL padro
CREATE TABLE <tabela>
(<descrio das colunas>);
(<descrio das chaves>);

Em que:

FOREIGN KEY

(codigo_vendedor)
REFERENCES VENDEDOR

);
CREATE TABLE ITEM_DO_PEDIDO
(
num_pedido
int
not null unique,
cdigo_produto
smallint
not null unique,
quantidade
decimal, FOREIGN KEY
(num_pedido)
REFERENCES PEDIDO,
FOREIGN KEY
(cdigo_produto)
REFERENCES PRODUTO
);

<tabela> - o nome da nova tabela a ser criada;


<descrio das colunas> - uma lista de colunas (campos) e seus
respectivos tipos de dados (smallint, char, money, varchar, integer, decimal, float,
real, date, time, timestamp, logical).

Observe-se que a clusula REFERENCE estabelece a restrio de integridade


referencial entre as tabelas. Porm, observe sempre que s podemos incluir essas
restries se as tabelas referidas na clusula REFERENCE j foram criadas antes
desta.

<descrio das chaves> - a lista de colunas que so tratadas como chave


estrangeira.

Como em nosso exemplo a tabela PRODUTO ainda no foi criada teramos


um erro ao executar esses comandos. Para criar a tabela ITEM DE PEDIDO,
deveramos cri-la aps a tabela PRODUTO.

Alguns campos podem receber o valor NULL (nulo) e o campo definido como
chave primria, alm de no poder receber NULL, deve ser um campo UNIQUE (sem
repeties - chave primria). Para o banco de dados da figura acima temos os
seguintes comandos:

Da mesma forma, a tabela PEDIDO somente pode ser criada com a restrio
de integridade referencial se for criada aps a criao de CLIENTE e VENDEDOR.

CREATE TABLE CLIENTE


(
smallint
Cdigo cliente
nome cliente
char(20),
endereo
char(30),
cidade
char(15),
CEP
char(8),
UF
char(2),
CGC
char(20),
IE
char(20)
);
CREATE TABLE PEDIDO
(
num pedido
prazo entrega
cdigo cliente
cdigo vendedor
FOREIGN KEY

int

not null unique,

muito normal realizar a criao das tabelas sem especificar a clusula


REFERENCE posteriormente ao processo de criao, utilizar-se o comando ALTER
TABLE para realizar a insero das restries de integridade referencial, como
mostraremos quando da apresentao desse comando.
CREATE TABLE VENDEDOR
(
cdigo_vendedor
smallint
not null,
nome_vendedor
char(20),
salrio_fixo
money,
faixa_comisso
char(l)
PRIMARY KEY (codigo_vendedor)
);

not null

unique,

smallint
not null,
smallint
not null,
smallint
not null,
(cdigo c cliente)
REFERENCES CLIENTE,

Note que a chave primria j est definida juntamente com o registro da


tabela. A criao do ndice, que por razes bvias deve acontecer aps a tabela,
naturalmente um comando totalmente independente do primeiro create, que serviu
para criar a tabela e suas caracterstica bsicas.
207

Problema:

CREATE TABLE PRODUTO

(
cdigo_produto
unidade
descrio_
val_unit
);

smallint not null unique,


char(3),
produto char(30),
money

- Listar todos os produtos com respectivas descries, unidades e


valores unitrios.
Diagrama grfico:

Para eliminar uma tabela criada, utilizado o comando DROP:


forma: DROP TABLE <tabela>; Ex.: DROP TABLE
PEDIDO
elimina a tabela de pedidos que foi previamente criada, seus dados e
suas referncias a outras tabelas.

14.4.3 - Extraindo Dados de uma Tabela: Comando SELECT


Uma das operaes mais comuns, realizadas sobre um banco de dados,
examinar (selecionar) as informaes armazenadas.
Essas operaes so realizadas por meio do comando SELECT.
Neste item, iremos mostrar vrias situaes de utilizao do comando
SELECT.
O comando SELECT tem palavras-chaves em um comando bsico:
a) SELECT Especifica as colunas da tabela que queremos selecionar;
b) FROM - Especifica as tabelas;
c) WHERE - Especifica as linhas.

A) Selecionando Colunas Especficas da Tabela


Sintaxe:
select <nome(s) da(s) coluna( s ) > from
<tabela>;

Sintaxe
SELECT descrio, unidade, valor_unitrio FROM
produto ;

A execuo desse comando neste formato ir listar todas as


linhas da tabela produto.
SELECT sem WHERE lista todas as linhas de uma tabela.
Resultado:
DESCRIO

UNIDADE

VAL UNIT

Queijo
Chocolate
Vinho
Linho
Acar
Linha
Ouro
Madeira
Cano
Papel

Kg
BAR
L
M
SAC
M
G
M
M
M

0,97
0,87
2,00
0,11
0,30
1,80
6,18
0,25
1,97
1,05

Problema:
- Listar da tabela CLIENTE :
- o CGC, o nome do cliente c seu endereo.

B) Selecionando todas as Colunas da Tabela

Diagrama grfico:

Sintaxe:
SELECT *
FROM <tabela>;

Problema:
- Listar todo o contedo de vendedor.
Diagrama grfico:

Neste caso, cumpre destacar que estamos realizando a seleo de


colunas especficas da tabela e apresentando o resultado com a disposio dos
campos diferente da ordem em que se encontram-na tabela.
Sintaxe
SELECT CGC, nome_cliente, endereo
FROM cliente;

Sintaxe ANS

Resultado:
CGC

NOME DO CLIENTE

ENDEREO

12113231/0001-34
22534126/9387-9
14512764/98349-9
28315213/9348-8
32816985/7465-6
23463284/234-9
12835128/2346-9
32485126/7326-8
32848223/324-2
1273657/2347-4
21763571/232-9
13276571/1231-4
32176547/213-3
2176357/1232-3

Ana
Flvio
Jorge
Lcia
Maurcio
Edmar
Rodolfo
Beth
Paulo
Lvio
Susana
Renato
Sebastio
Jos

Rua 17 n. 19
Av. Pres. Vargas 10
Rua Caiapo 13
Rua Itabira 123 Loja 9
Av. Paulista 1236 sl/2345
Rua da Praia sn/
Largo da Lapa 27 sobrado
Av. Climrio n. 45
__
Tv. Moraes c/3
__
Av. Beira Mar n. 1256
___
Rua Lopes Mendes 12
__
Rua Meireles n. 123 bl.2 s 1345
Rua da Igreja n. 10.
Quadra 3 bl. 3 si. 1003 _______

SELECT *
FROM vendedor;

Resultado:
CDIGO
VENDEDOR

NOME
VENDEDOR

SALRIO
FIXO

FAIXA
COMISSO

209

Jos

1.800,00

111

Carlos
Joo
Antnio
Felipe
Jonas
Joo

2.490,00
2.780,00
9.500,00
4.600,00
2.300,00
2.650,00

A
C
C
A
A
C

11
240
720
213
101

A utilizao do comando SELECT sem a clusula WHERE causa uma desnecessria carga
nos recursos de sistema. Por esta razo, em MS-SQL e ORACLE utilize sempre a clusula
WHERE.

CDIGO
VENDEDOR

NOME
VENDEDOR

SALRIO
FIXO

FAIXA
COMISSO

D) Manipulando dados numricos: Operadores Aritmticos

310
250

Josias
Maurcio

870,00
2.930,00

B
B

Operadores aritmticos podem ser usados sobre qualquer coluna


numrica, incluindo colunas de tipo de dado int, smallint, tinyint, float, real,
money, or smallmoney2.
Os operadores Aritmticos so:

C) Alterando o Heading (Cabealho) da coluna

Smbolo

Operao

Pode ser usado com (MS-SQL Server 7.0)

Por default, o heading (nome da coluna criado no database) apresentado


na sada do SELECT o nome da coluna na tabela. (Ver comando CREATE)

Adio

Int, smallint,tinyint, numeric,decimal, float,


real, money and smallmoney

O SQL permite que se apresente a sada de um SELECT com


cabealhos de colunas ao nosso gosto.

Subtrao

Int, smallint,tinyint, numeric,decimal, float,


real, money and smallmoney

Diviso

Int, smallint,tinyint, numeric, decimal, float,


real, money and smallmoney

Multiplicao

Int, smallint,tinyint, numeric,decimal, float,


real, money and smallmoney

Mdulo

Int,smallint e tinyint

Sintaxe:
SELECT cabealho da coluna = nome da coluna, [, nome
da coluna]
FROM nome da tabela
Exemplo:
SELECT numero = codigo_vendedor,
nome= nome_vendedor rendimentos
= salario_fixo, comisso =
faixa_comisso
FROM vendedor

0/

/o

Exemplo:
SELECT nome_vendedor, salario_fixo =
(salario_fixo * 2) FROM vendedor
NOMEJVENDEDOR

Resultado :
NUMERO

NOME

RENDIMENTOS

COMISSO

209

Jos

1.800,00

111
11
240
720
213
101
310
250

Carlos
Joo
Antnio
Felipe
Jonas
Joo
Josias
Maurcio

2.490,00
2.780,00
9.500,00
4.600,00
2.300,00
2.650,00
870,00
2.930,00

A
C
C
A
A
C
B
B

SALARIO_FIXO

Jos

3,600.00

Carlos

4,980.00

Joo
Antnio
Felipe
Jonas
Joo
Josias
Maurcio

Datatypes de MS-SQL Server 7.0

5,560.00
19,000.00
9,200.00
4,600.00
5,300.00
1,740.00
5,860.00

O resultado apresenta os
salrios com valores
multiplicados por dois.

E) Selecionando somente algumas linhas da Tabela:

Diagrama grfico:

A clusula WHERE em um comando SELECT especifica quais linhas


queremos obter, baseada em condies de seleo.
Chamamos isto de observar uma seleo horizontal de informaes.
Sintaxe bsica:
SELECT <nome(s) da(s) coluna(s)>
FROM <tabela>
WHERE <condies de seleo;

Comparaes na Clusula WHERE

Sintaxe:
SELECT num_pedido, cdigo_produto, quantidade FROM
item_do_pedido WHERE quantidade = 3 5;

WHERE <nome da coluna> <operador> <valor>

Resultado:

E.l) Operadores de Comparao


= => Igual
<> ou != => diferente
< => menor do que
> => maior do que
>= -> maior ou igual do que
!> -> no maior

NMERO DO
PEDIDO

CDIGO DO
PRODUTO

QUANTIDADE

121
138

31
77

35
35

Problema:
- Quais os clientes que moram em Niteri?
Diagrama grfico:

!< -> no menor


<= -> menor ou igual do que
Quando a coluna do tipo caractere, o <valor> deve estar entre aspas (');
Ex.: 'PARAFUSO'
Na linguagem SQL, existe a diferenciao entre maisculas e
minsculas em alguns SGBDs, logo 'PARAFUSO' diferente de 'parafuso'.
Problema:
- Listar o num_pedido, o cdigo_produto e a quantidade dos itens do
pedido com a quantidade igual a 35 da tabela item_do_pedido.

Sintaxe:
SELECT nome_cliente
FROM cliente
WHERE cidade = 'Niteri';

Resultado:

Diagrama grfico:

NOME CLIENTE
Ana
Susana
E.2) Operadores Lgicos
AND -> "e" lgico
OR -> "ou" lgico
NOT -> negao

Problema:

Sintaxe:

- Listar os produtos que tenham unidade igual a 'M' e valor unitrio igual a
R$ 1,05 da tabela produto.

SELECT nome_cliente, endereo


FROM cliente
WHERE (CEP >= '30077000' AND CEP <= '3O079000')
OR cidade = 'So Paulo';

Diagrama grfico:

Resultado:

Sintaxe:
SELECT descrio_produto
FROM produto
WHERE unidade = 'M' AND val_unit = 1.05;
Resultado:

Descrio_produto
Papel
Problema:
Liste os clientes e seus respectivos endereos, que moram em 'SAO
PAULO' ou estejam na faixa de CEP entre '30077000' e '30079000'.

NOME CLIENTE

ENDEREO CLIENTE

Flvio

Av. Pres. Vargas 10

Jorge
Maurcio

Rua Caiapo 13
Av. Paulista 1236 sl/2345

Rodolfo
Beth
Lvio

Largo da Lapa 27 sobrado


Av. Climrio n. 45
Av. Beira Mar n. 1256

Renato

Rua Meireles n. 123 bl.2 sl.345

A utilizao dos parnteses fundamental para a construo correta da


sentena, pois sem eles as consultas podem ser analisadas de forma errada, devido
prioridade do operador AND ser maior que a prioridade do operador OR.
Problema:
- Mostrar todos os pedidos que no tenham prazo de entrega igual a 15
dias.

217

Diagrama grfico:

E.3) Operadores Between e NOT Between


Sintaxe:
- WHERE <nome da coluna> BETWEEN <valorl> AND <valor2>
- WHERE <nome da coluna> NOT BETWEEN <valorl> AND
<valor2>

Sintaxe:
SELECT num_pedido
FROM pedido

WHERE NOT (prazo_entrega =


15);

Ou podemos alternativamente utilizar um


operador de comparao <> que ir
realizar a mesma operao de seleo.
Sintaxe2:
SELECT num_pedido
FROM pedido

Este operador propicia a pesquisa por uma determinada coluna e


selecionando as linhas cujo valor da coluna esteja dentro de uma faixa
determinada de valores, sem a necessidade dos operadores >=, <= e AND.
Tanto o VALORl quanto o VALOR2 tm de ser do mesmo tipo de dado da
coluna.
3

Quando executado sobre colunas do tipo char, varchar, text, datetime e


smalldatetime devemos colocar estes valores entre aspas.
Problema:
- Listar o cdigo e a descrio dos produtos que tenham o valor
unitrio na faixa de R$ 0,32 at R$ 2,00.
Diagrama grfico:

WHERE (prazo_entrega <> 15);

Resultado:
Num_pedido
121
97
137
148
104
203
98
143
111
103
91
138
119

Sintaxe:
SELECT codigo_produto, descrio_produto
FROM produto
WHERE val_unit between 0.32 and 2.00;
Resultado:
CDIGO DO PRODUTO
25
31

DESCRIO
Queijo
Chocolate

CDIGO DO PRODUTO

DESCRIO

78
53
87
77

Vinho
Linha
Cano
Papel

E.4) Operadores baseados em string de caracteres LIKE e NOT LIKE

LIKE '[CM]%' permite enxergar qualquer nome que comece com 'C ' ou com
'M'.
LIKE '[C-X]%' permite enxergar qualquer nome que comece com 'C '
at'X
LIKE 'M[^o]%' permite enxergar qualquer nome que comece com 'M ' e no
tenha a letra 'o' como segunda letra.

Sintaxe:

Vamos ver mais alguns exemplos de utilizao da clusula LIKE.

- WHERE <nome da coluna> LIKE <valor>;


- WHERE <nome da coluna> NOT LIKE <valor>;

Problema:
- Listar todos os produtos que tenham o seu nome comeando por
Q.
Diagrama grfico:

Os operadores LIKE e NOT LIKE s trabalham sobre colunas que sejam do


tipo CHAR. Eles tm praticamente o mesmo funcionamento que os operadores = e < >
, porm o poder desses operadores est na utilizao dos smbolos (%) e (_) que
podem fazer o papel de "curinga":
% - substitui uma palavra
_ - substitui um caractere
Ex.: Like 'LPIS %' pode enxergar os seguintes registros:
'LPIS PRETO,

Sintaxe:

'LPIS CERA',

SELECT Cdigo_produto/ descrio_produto


FROM produto
WHERE descrio_produto LIKE 'Q_';

'LPIS BORRACHA'
Ou seja, todos os registros que contenham 'LPIS' seguido de qualquer
palavra ou conjunto de caracteres.

Resultado:

LIKE 'BROCA N_' pode enxergar os seguintes registros:

'BROCA NI',
'BROCA N9',
'BROCA N3'

CDIGO DO PRODUTO

DESCRIO

25

Queijo

Problema:
- Listar os vendedores que no comeam por 'Jo'.

LIKE '%o_' pode enxergar qualquer nome que termine em "o".

Diagrama grfico:

Diagrama grfico:
Sintaxe ANSI
SELECT Cdigo_vendedor, nome_vendedor
FROM vendedor
WHERE nome_vendedor NOT LIKE 'Jo%';

Sintaxe Microsoft SQL Server


SELECT Cdigo_vendedor, nome_vendedor
FROM vendedor
WHERE nome_vendedor LIKE '[^Jo]%';

Resultado NOT LIKE:


CDIGO VENDEDOR

NOME VENDEDOR

111
240
720
250

Carlos
Antnio
Felipe
Maurcio

E.5) Operadores baseados em listas IN e NOT IN


- WHERE <nome da coluna> IN <valores>;
- WHERE <nome da coluna> NOT IN <valores>;
Esses operadores pesquisam registros que esto ou no contidos no conjunto
de <valores> fornecido. Estes operadores minimizam o uso dos operadores =, <>,
AND e OR.
Problema:
- Listar os vendedores que so da faixa de comisso A e B.

Sintaxe:
SELECT nome_vendedor
FROM vendedor
WHERE faixa_comisso IN ('A', 'B');
Resultado:
NOME VENDEDOR
Carlos
Felipe
Jonas
Josias
Maurcio
E.6) Operadores baseados em valores desconhecidos :IS NULL e IS NOT NULL
- WHERE <nome da coluna> IS NULL;
- WHERE <nome da coluna> IS NOT NULL;
A utilizao do valor nulo (NULL) muito problemtica, pois cada
implementao da linguagem pode adotar qualquer representao para o valor nulo.
O resultado da aplicao destes operadores permite o tratamento de valores
nulos em colunas de uma tabela, selecionando as linhas correspondentes.
Problema:
- Mostrar os clientes que no tenham inscrio estadual.

A informao <nmero da coluna> se refere


quando for apresentado o resultado da consulta, e no
contada da esquerda para a direita. As palavras
respectivamente, ascendente e descendente. A forma
assumida como padro.

Diagrama grfico:

posio relativa das colunas


posio na tabela original,
ASC e DESC significam,
ascendente de ordenao

Problema:
- Mostrar em ordem alfabtica a lista de vendedores e seus respectivos
salrios fixos.
Diagrama grfico:
Sintaxe:
SELECT *
FROM cliente
WHERE IE IS NULL;

Resultado:
Cdigo
Cliente

Nome
Cliente

Endereo

Cidade

Cep

UF

110

Jorge

R. Caiapo 13

Curitiba

30078500

PR

180

Lvio

Av. Beira Mar 1256

Florianpolis

30077500

SC

CGC

IE

145127645/983493-9

Sintaxe:
SELECT nome_vendedor, salrio_fixo
FROM vendedor
ORDER BY nome_vendedor;

127365713/2347-4

Resultado:

F) Ordenando os Dados Selecionados


Quando se realiza uma seleo, os dados recuperados no esto ordenados. Os
dados so recuperados pela ordem em que se encontram dispostos fisicamente na
tabela do SGBD.
A SQL prev a clusula ORDER BY para realizar uma ordenao dos dados
selecionados.
Sintaxe bsica:
SELECT <nome da(s) coluna(s)>
FROM <tabela>
WHERE <condio(es)> >
ORDER BY <nome da(s) coluna(s)>
ORDER BY <nmero da coluna>

ASC

DESC

NOME VENDEDOR

SALRIO FIXO

Antnio

9.500,00

Carlos
Felipe
Joo

2.490,00
4.600,00
2.780,00

Joo
Jonas
Jos
Josias
Maurcio

2.650,00
2.300,00
1.800,00
870,00
2.930,00

Problema:
- Listar os nomes, cidades e estados de todos os clientes,
ordenados por estado e cidade de forma descendente.

Problema:

Diagrama grfico:

- Mostrar a descrio e o valor unitrio de todos os produtos que


tenham a unidade 'KG', em ordem de valor unitrio ascendente
Diagrama grfico:

Sintaxe:
SELECT nome_cliente, cidade, UF
FROM cliente
ORDER BY UF DESC, cidade DESC;

Sintaxe:
SELECT descrio, val_unit FROM
produto WHERE unidade = 'M'
ORDER BY 2 ASC;

Resultado:
NOME CLIENTE

CIDADE

UF

Flvio
Maurcio
Beth
Renato
Lvio
Rodolfo
Ana
Susana
Paulo
Jorge
Sebastio
Lcia
Jos
Edmar

So Paulo
So Paulo
So Paulo
So Paulo
Florianpolis
Rio de Janeiro
Niteri
Niteri
Londrina
Curitiba
Uberaba
Belo Horizonte
Braslia
Salvador

SP
SP
SP
SP
SC
RJ
RJ
RJ
PR
PR
MG
MG
DF
BA

Resultado:
DESCRIO

VALOR UNITRIO

Linho
Madeira
Papel
Linha
Cano

0,11
0,25
1,05
1,80
1,97

E) Realizando Clculos com Informao Selecionada


Com a linguagem SQL pode-se criar um campo que no pertena tabela
original, e seja fruto de clculo sobre alguns campos da tabela.
Problema:
- Mostrar o novo salrio fixo dos vendedores, de faixa de comisso 'C,
calculado com base no reajuste de 75% acresddo de R$ 120 00 de
bonificao. Ordenar pelo nome do vendedor.

Diagrama grfico:

Diagrama grfico:

Sintaxe:

Sintaxe:
SELECT nome_vendedor,
novo_salrio = (salrio_fixo * 1.75) + 120
FROM vendedor
WHERE faixa comisso = 'C'
ORDER BY nome_vendedor;
Resultado:

NOME VENDEDOR

NOVO SALRIO

Antnio
Joo
Joo
Jos

16.745,00
4.985,00
4.757,50
3270,00

G) Utilizando Funes de Agregao sobre Conjuntos


As funes de agregao resultam sempre em uma nova coluna no
resultado da pesquisa.
G.l) Buscando Mximos e Mnimos (MAX, MIN)
Problema:
Mostrar o menor e o maior salrios da tabela vendedor.

SELECT MIN(salrio_fixo), MAX(salrio_fixo)


FROM vendedor;
Resultado:

MIN(salrio fixo)

MAX(salrio fixo)

870,00

9.500,00

F.2) Totalizando dos valores de Colunas (SUM)


Problema:
- Mostrar a quantidade total pedida para o produto 'VINHO' de
cdigo 78' na tabela item_de_pedido.
Diagrama grfico:

Sintaxe:

F.4) Contando os Registros (COUNT)


Problema:

SELECT SUM(quantidade) ,
FROM item_pedido
WHERE cdigo_produto = '78';

- Quantos vendedores ganham acima de R$ 2.500,00 de salrio fixo?


Diagrama grfico:

Resultado:
SUM(Quantidade)
183

F.3) Calculando Mdias (AVG)


Problema:
- Qual a mdia dos salrios fixos dos vendedores?

Sintaxe:

Diagrama grfico:

SELECT COUNT(*),
FROM vendedor
WHERE salrio_fixo >2 5 0 0 ;
O comando COUNT, quando utilizado sem a clusula WHERE, realiza a contagem
das linhas da tabela.
Resultado:

COUNT (*)
5
Sintaxe:
SELECT AVG(salrio_fixo),
FROM vendedor;
Resultado:
AVG(salrio fixo)

F.5) Utilizando a Clusula DISTINCT


Normalmente, vrios registros dentro de uma tabela podem conter os Mesmos
valores, com exceo da chave primria. Com isso, muitas consultas Podem trazer
informaes erradas. A clusula DISTINCT, aplicada em uma consulta, foi criada para no
permitir que certas redundncias, obviamente necessrias, causem problemas. A clusula
DISTINCT elimina repeties de valores em relao a uma coluna.

3.324,44
Problema:
- Quais as unidades de produtos, diferentes, na tabela produto?

Diagrama grfico:

Podemos igualmente continuar com a clusula WHERE selecionando as


condies da seleo.
Forma:
SELECT <nome da(s) coluna(s)>
FROM <tabela>
WHERE condio(es)>
GROUP BY <nome da(s) coluna(s)>;
HAVING <condio(es)>;

Problema:

Sintaxe:
SELECT DISTINCT unidade,
FROM produto;

- Listar o nmero de produtos que cada pedido contm.


Diagrama grfico:

Resultado:
UNIDADE
Kg
BAR
L
M
SAC
G

Importante: Com a utilizao de DISTINC no se classificam os dados


de sada4.
F.6) Agrupando Informaes Selecionadas (GROUP BY e HAVING)
A funo de agregao por si prpria produz um nmero simples para
uma tabela.
A clusula organiza esse sumrio de dados em grupos, produzindo
informao sumarizada para os grupos definidos na tabela objeto de seleo.
A clusula HAVING realiza as restries das linhas resultantes da
mesma forma que a clusula WHERE o faz em um SELECT.

Especificao para MS-SQL Server 7.0.

Sintaxe:
SELECT num_pedido,
total_produtos = COUNT(*)
FROM item_de_pedido GROUP
BY num_pedido;

Inicialmente, os registros so ordenados de forma ascendente por


nmero do pedido.
Num segundo passo, aplicada a operao COUNT(*) para cada grupo
de registros que tenha o mesmo nmero de pedido.
Aps a operao de contagem de cada grupo, o resultado da consulta
utilizando a clusula GROUP BY apresentado.

Sintaxe:

Resultado:
Num_pedido
91
97
98
101
103
104
105
108
111
119
121
138
143
148
189
203

Total_Produtos
1
1
1
3
1
1
1
1
2
4
2
3
2
5
1
1

Geralmente, a clusula GROUP BY utilizada em conjunto com as


operaes COUNT e AVG.
F.7) Utilizando com HAVING
Problema:
- Listar os pedidos que tm mais do que trs produtos.
Diagrama grfico:

SELECT num_pedido,total_produtos = COUNT(*) FROM


item_pedido GROUP BY num_pedido; HAVING COUNT(*)
>3;

Resultado:
NMERO DO PEDIDO

TOTAL DE PRODUTOS

119
148

4
5

A clusula GROUP BY pode ser utilizada em conjunto com qualquer


outra clusula que j estudamos at este ponto.

G) Recuperando Dados de Vrias Tabelas (JOINS)


At agora viemos trabalhando com a recuperao de dados sobre uma
nica tabela, mas o conceito de banco de dados rene, evidentemente vrias
tabelas diferentes.
Para que possamos recuperar informaes de um banco de dados, temos,
muitas vezes, a necessidade de acessar simultaneamente vrias tabelas
relacionadas entre si. Algumas dessas consultas necessitam realizar uma juno
(JOIN) entre tabelas, para poder extrair dessa juno as informaes necessrias
para a consulta formulada.
G.1) O Conceito de Qualificadores de Nome
O qualificador de nome consiste no nome da tabela seguido de um
ponto e o nome da coluna na tabela, por exemplo:
O qualificador de nome para a coluna DESCRIO da tabela
PRODUTO ser
- PRODUTO.descrio Os qualificadores de nome so utilizados em uma
consulta para efetivar a juno (JOIN) entre tabelas, uma vez que o
relacionamento entre tabelas realizado por meio de chaves estrangeiras, como
vimos no captulo 6,

e isto implica na existncia de colunas com mesmo nome em tabelas


diferentes.
Existem duas sintaxes que vamos considerar em nosso estudo.5
A sintaxe ANSI SQL e a sintaxe do MS-SQL Server para
implementao de joins.
Sintaxe ANSI SQL
SELECT <nome_da_tabela.nome_da_coluna
[nome_da_tabela.nome_da_coluna .... ]>
FROM
{nome_da_tabela
[tipo
de
nome_da_tabela ON condio de pesquisa
WHERE [condio de pesquisa .. ]

join]

Sintaxe Microsoft-SQL Server


SELECT < nome_da_tabela.nome_da_coluna
[nome_da_tabela.nome_da_coluna .. ]>
FROM <nome_da_tabela, nome_da_tabela>
WHERE <nowie_da_tajbe!a.nome_da_coluna
de join] .no.me_da_tajbeIa.nome_da_coluna

Nos joins do MS-SQL Server, a clusula FROM lista as tabelas envolvidas


no JOIN e a clusula WHERE especifica que linhas devem ser includas no conjunto
resultante. Na clusula WHERE, o operador de join utilizado entre os componentes
a serem juntados.
Os seguintes operadores so utilizados como join operators no MS-SQL
Server:
Smbolo

Significado

Igual a

>

Maior que

<

Menor que

>=

Maior ou igual

<=

Menor ou igual

Diferente

[operador

Na sintaxe ANSI, criamos uma tabela de join, "uma joinjable", para as linhas
selecionadas conforme a clusula WHERE. Podemos escolher o tipo de Join a
realizar, colocando a palavra que o identifica (tipo de join).
Quando usamos INNER JOIN como tipo de join, sero includas somente as
linhas que satisfazem a condio do join.

Problema:
Ver os pedidos de cada cliente.
Diagrama grfico:

Quando usamos CROSS JOIN, inclumos cada uma da combinaes de todas


as linhas entre as tabelas.
E finalmente, quando usamos OUTER JOIN, inclumos as linhas que
satisfazem a condio de JOIN e as linhas restantes de uma das tabelas do JOIN.
Na sintaxe MS-SQL Server, so comparadas as tabelas por uma coluna
especfica para cada tabela (chave estrangeira), linha por linha, e so listadas as linhas
em que a comparao verdadeira.
G.2) Inner Joins
Sintaxe ANSI SQL
Aqui vale a pena destacar que existe um padro de sintaxe:ANSI e um padro de sintaxe
MS-SQL Server para a execuo de joins, sendo que no podemos usar os dois
simultaneamente.

SELECT

Cliente.nome_cliente,
pedido.cod_cliente,
pedido.num_pedido

FROM cliente INNER JOIN pedido ON


cliente.codigo_do_cliente = pedido.
codigo_do__cliente

G.3) Cross Join ou Produto Cartesiano


Problema:

Sintaxe Microsoft-SQL Server

- Juntar Clientes com Pedidos.

SELECT Cliente.nome_cliente,
pedido.cod_cliente,
pedido.num_pedido
FROM cliente, pedido
WHERE cliente.codigo_do_cliente
= pedido.codigo_do_cliente

Diagrama grfico:

Resultado:
Nome_Cliente
Ana
Ana
Ana
Ana
Flvio

Jorge
Maurcio
Rodolfo
Rodolfo
Rodolfo
Beth
Lvio
Susana
Susana
Susana
Susana
Renato
Sebastio

Pedido.Codigo_do_cliente
720
720
720
720
870
110
830
410
410
410
20
180
260
260
260
260
290
390

Pedido.num_pedido
97
101
137
148
189
104
203
121
98
127
143
105
111
103
91
138
108
119

Nesta juno, so apresentados os pedidos de cada cliente, pois a condio de "join"


restringe e qualifica a juno dos dados entre as tabelas. A equao apresentada na clusula
WHERE chamada de EQUAO DE JUNO.

Sintaxe ANSI SQL:


SELECT nome_cliente,
pedido.cod_cliente,
num_pedido
FROM cliente CROSS JOIN pedido

Sintaxe MS- SQL Server :


SELECT nome_c1iente,
pedido.cod_cliente,
num_pedido
FROM cliente, pedido

Resultado:
Nome_cliente

Pedido.codigo_do_cliente

Pedido.num_pedido

Ana
Ana
Ana
Ana
Ana
Ana
Ana

720
260
870
390
260
830
410

97
111
54
119
103
203
121

Nome_cliente

Pedido.codigo_do_cliente

Pedido.num_pedido

G.4) Outer Joins

Ana
Ana
Ana
Ana
Ana
Flvio
Flvio
Flvio
Flvio
Flvio
Flvio
Flvio
Flvio
Flvio
Flvio
Flvio
Jorge
Jorge
Jorge
Jorge
Jorge
Jorge
Jorge
Jorge
Jorge
Jorge
Jorge
Jorge
Lcia
Lcia
Lcia
Lcia
Lcia

110
180
720
290
410
720
260
870
390
260
830
410
110
720
290
410
720
260
870
390
260
830
410
110
180
720
290
410
720
260
870
390
260

104
105
83
108
89
97
111
54
119
103
203
121
104
83
108
89
97
111
54
119
103
203
121
104
105
83
108
89
97
111
54
119
103

a seleo em que so restritas as linhas que interessam em uma tabela, mas


so consideradas todas as linhas de outra tabela.
Ou seja, queremos ver quais linhas de uma tabela esto relacionadas com a
outra tabela e quais linhas no esto.
Poderamos dizer, exemplificando no mundo real, que queremos ver quais
clientes tem pedidos e quais no tm nenhum pedido.
de muita utilidade quando queremos verificar se existem membros rfos
em um banco de dados, ou seja, chave primria e chave estrangeira sem sincronia ou
simetria.
Um OUTER JOIN somente pode ser realizado entre duas tabelas, no mais
que duas tabelas.
A sintaxe SQL ANSI possui trs tipos de qualificadores para o OUTER JOIN:
LEFT OUTER JOIN - So includas todas as linhas da tabela do primeiro
nome de tabela ( a tabela mais esquerda da expresso).
RIGHT OUTER JOIN - So includas todas as linhas da tabela do segundo
nome de tabela da expresso (tabelas mais direita da expresso).
FULL OUTER JOIN - So includas as linhas que no satisfazem a expresso
tanto da primeira tabela quanto da segunda tabela.
O MS-SQL Server utiliza operadores para outer join:
*= Inclui todas as linhas da primeira tabela da expresso

=*Inclui todas as linhas da segunda tabela da expresso

Vamos ver um exemplo de OUTER JOIN para entenderemos melhor a sua


funcionalidade.
Problema: Quais so os clientes que tm pedido e os que no tm pedido.

Podemos observar que no existe muito proveito do resultado desse tipo de


JOIN, excetuando-se quando queremos fazer referncia cruzada entre duas tabelas e
suas linhas todas.

Diagrama grfico:

Sintaxe ANSI SQL


SELECT nome_cliente,
pedido.cod_cliente,
num_pedido
FROM cliente LEFT OUTER JOIN pedido ON
cliente.codigo_do_cliente =
Pedido.codigo_do_cliente

Sintaxe Microsoft- SQL Server :


SELECT nome_cliente,
pedido.cod_cliente,
num_pedido
FROM cliente, pedido WHERE
cliente.codigo_do_cliente *=
Pedido.codigo_do_cliente
Resultado

Nome_Cliente

Pedido.Codigo_
do_cliente

Pedido.num_pedido

Rodolfo
Beth
Lvio
Susana
Susana
Susana
Susana
Renato
Sebastio
Lcia
Edmar
Paulo
Jos

410
20
180
260
260
260
260
290
390
NULL
NULL
NULL
NULL

127
143
105
111
103
91
138
108
119
NULL
NULL
NULL
NULL

Como os clientes Lcia, Edmar, Paulo e Jos no tm nenhuma linha da


tabela pedindo a informao de seu cdigo, essas informaes so
apresentadas como NULL.
Por este motivo no devemos utilizar NULL na condio de seleo, pois
teremos de utilizar os resultados mais imprevisveis possveis ou
imaginrios.
Podemos utilizar as clusulas LIKE, NOT LIKE, IN, NOT IN, NULL, NOT
NULL e mistur-las com os operadores AND, OR e NOT, dentro de uma clusula
WHERE na juno entre tabelas.
Vamos estudar comandos de seleo de dados com esses operadores.

Nome_Cliente

Pedido.Codigo_
do_cliente

Pedido.num_pedido

Ana
Ana
Ana
Ana
Flvio
Jorge
Maurcio
Rodolfo
Rodolfo

720
720
720
720
870
110
830
410
410

97
101
137
148
189
104
203
121
98

Problema:
- Quais clientes tm prazo de entrega superior a 15 dias e pertencem aos
estados de So Paulo ('SP') ou Rio de Janeiro ('RJ')?

Problema:

Diagrama grfico:

- Mostrar os clientes e seus respectivos prazos de entrega,


ordenados do maior para o menor.
Diagrama grfico:

Sintaxe SQL ANSI:


SELECT Cliente.nome_cliente, pedido.cod_cliente,
pedido.num_pedido FROM cliente INNER
JOIN pedido ON cliente.codigo_do_cliente
= pedido.codigo_do_cliente WHERE
UF IN ( ' S P ' , 'RJ') AND prazo_entrega > 15

Sintaxe Microsoft-SQL Server


SELECT Cliente.nome_cliente, pedido.cod_cliente,
pedido.num_pedido FROM cliente, pedido
WHERE cliente.codigo_do_cliente
= pedido.codigo_do_cliente AND UF IN ('SP',
'RJ') AND prazo_entrega > 15

Resultado:
NOME CLIENTE

UF

PRAZO ENTREGA

Ana
Maurcio
Rodolfo
Beth
Susana

RJ

20
30
20
30
20

SP

RJ
SP
RJ

Sintaxe SQL ANSI


SELECT nome_cliente, prazo_entrega
FROM cliente, pedido
ON cliente.cod_cliente = pedido.cod_cliente ORDER BY
prazo_entrega desc;

Sintaxe Microsoft-SQL Server:


SELECT nome_cliente, prazo_entrega
FROM cliente, pedido
WHERE cliente.cod_cliente = pedido.cod_cliente ORDER
BY prazo_entrega desc;

Resultado:
NOME CLIENTE

PRAZO ENTREGA

Jorge

30
30
30
30
20
20
20
15
15
15
15
10

Maurcio
Beth
Sebastio
Rodolfo
Ana
Susana
Ana
Flvio
Lvio
Renato
Rodolfo

Para que no seja necessrio escrever todo o nome da tabela nas


qualificaes de nome, podemos utilizar ALIASES (sinnimos) definidos na
prpria consulta. A definio dos ALIASES feita na clusula FROM e
utilizada normalmente nas outras clusulas (Where, order by, group by, having,
select).
Problema:

G.2) Juntando mais de duas Tabelas


Problema:
- Mostre os clientes (ordenados) que tm prazo de entrega ma que
15 dias para o produto 'QUEIJO' e sejam do Rio de Janeiro.
Diagrama grfico:

- Apresentar os vendedores (ordenados) que emitiram pedidos com


prazos de entrega superiores a 15 dias e tenham salrios fixos
iguais ou superiores a R$ 1.000,00.
Diagrama grfico:

Sintaxe:
SELECT nome_vendedor, prazo entrega
FROM vendedor V, pedido P
WHERE salrio_fixo >= 1000.00 AND
prazo_entrega > 15 AND
V.cod_vendedor = P.cod_vendedor
ORDER BY nome_vendedor;

Resultado:
NOME VENDEDOR

PRAZO ENTREGA

Antnio
Carlos
Joo
Jos
Maurcio

20
30
20
20
30

Novamente vamos apresentar a sintaxe ANSI e a sintaxe especfica


MS-SQL Server.
Sintaxe ANSI
SELECT Cliente.nome_cliente,
FROM cliente INNER JOIN pedido ON
cliente.codigo_do_cliente = pedido.codigo_do_clieni
INNER JOIN item_de_pedido ON
pedido.num_pedido = item-de_pedido.num_pedido
INNER JOIN produto ON
item_de_pedido.cod_produto=produto.cod_produto
WHERE Pedido.prazo_entrega > 15 AND
Produto.Descricao ='queijo' AND Cliente.UF = 'RJ'
ORDER BY Cliente.nome_cliente

Sintaxe Microsoft-SQL Server:


SELECT nome_cliente
FROM cliente , pedido , item_pedido , produto
WHERE Cliente.cod_cliente = Pedido.cod_cliente
AND Pedido.num_pedido = Item_de_pedido.num_pedido
AND Item_de_pedido.cod_produto = Produto.cod_produto
AND Pedido.prazo_entrega >15
AND
Produto.descrio = 'Queijo'
AND Cliente.UF = 'RJ'
ORDER BY Cliente.nome_cliente;

Resultado:
NOME CLIENTE
Ana
Rodolfo
Susana

AND Item_de_pedido.cod_produto = Produto.codj>rodutc

AND
AND

quantidade >10
descrio = 'Chocolate';

Resultado:

NOME VENDEDOR
Jos
Carlos
Problema:
- Quantos clientes fizeram pedido com o vendedor Joo?
Diagrama grfico:

Vamos a mais um exemplo:


Problema:
- Mostre todos os vendedores que venderam chocolate em
quantidade superior a 10 Kg.
Diagrama grfico:

Sintaxe Microsoft-SQL Server


SELECT COUNT (cod_cliente)
FROM cliente , pedido ,vendedor
WHERE Cliente.cod_cliente , Pedido.cod_cliente AND
Pedido.cod_vendedor = Vendedor.cod_vendedor
AND Vendedor.nome_vendedor = 'Joo';
Resultado:
COUNT (Cdigo cliente)
4

Sintaxe Microsoft-SQL Server:


SELECT DISTINCT nome_vendedor
FROM vendedor ,pedido , item_pedido , produto
WHERE Cliente.cod_vendedor = Pedido.cod_vendedor
AND Pedido.num_pedido = Item_de_pedido.num_pedido

Problema:

Diagrama grfico:

- Quantos clientes da cidade do Rio de Janeiro e de Niteri tiveram seus


pedidos tirados com o vendedor Joo?
Diagrama grfico:

Sintaxe:
SELECT descrio
FROM produto WHERE
cod_produto IN (SELECT
cod_produto FROM
item_pedido WHERE
quantidade = 10)

Resultado:
Sintaxe Microsoft-SQL Server:
SELECT cidade, nmero = COUNT (nome_cliente)
FROM cliente , pedido , vendedor
WHERE nome_vendedor = 'Joo'
AND CIDADE IN ('Rio de Janeiro', 'Niteri')
AND Vendedor.cod_Vendedor = Pedido.cod_Vendedor AND
Pedido.cod_cliente = Cliente.cod_cliente
GROUP BY cidade;
Resultado:
CIDADE

NMERO

Niteri
Rio de Janeiro

2
1

G.3) Utilizando Consultas Encadeadas (Subqueries)


Que uma subquery? Em linhas gerais, quando o resultado de uma consulta
utilizado por outra consulta, de forma encadeada e contida no mesmo comando SQL.
Problema - Utilizando IN
- Que produtos participam de qualquer pedido cuja quantidade seja 10?

DESCRIO
Queijo
Vinho
Linho

Problema - Utilizando AVG


- Quais vendedores ganham um salrio fixo abaixo da mdia?
Diagrama grfico:

Resultado:

Sintaxe:
SELECT nome_vendedor
FROM vendedor WHERE
salrio_fixo < (SELECT
AVG(salrio_fixo) FROM
vendedor);
Resultado:

NomeJVendedor
Jos
Carlos
Joo
Jonas
Josias
Maurcio

Problema: - Utilizando NOT IN


- Quais os produtos que no esto presentes em nenhum pedido?
Diagrama grfico:

Sintaxe:
SELECT cd_produto, descrio
FROM produto
WHERE cod.produto NOT IN (SELECT *
FROM item_pedido WHERE
item_de_pedido.cod_produto =
Produto.cod_produto)

CDIGO PRODUTO

DESCRIO

87

Carro

Na consulta anterior, a "subquery" no executada diretamente de uma


vez s; ela executada para cada valor do registro do produto, ou seja, para
cada execuo da "subquery" utilizado um valor do cdigo do produto dentro
do produto, o qual comparado, via condio de subquery, com vrios valores
em itens do pedido.
Problema:
- Quais os vendedores que s venderam produtos por grama ('G')?
Diagrama grfico:

Sintaxe ANSI:6
SELECT DISTINCT cod_vendedor, nome_vendedor
FROM vendedor
WHERE unidade ALL =('G')
SELECT unidade
FROM pedido, item_pedido, produto
WHERE Pedido.num_pedido =item_de_pedido.num_pedido
AND Item_de__pedido.cod_produto = Produto. cod_produto
AND Produto.cod_vendedor = Vendedor.cod_vendedor);
Resultado:

CDIGO VENDEDOR

NOME VENDEDOR

720
310

Felipe
Josias

Sintaxe:
SELECT nome_cliente
FROM cliente WHERE
EXIST (SELECT
COUNT(*)
FROM pedido
WHERE cod_cliente = Cliente.cod_cliente
HAVING COUNT(*) >3);

Interpretando o comando aplicado:


Selecione todas as ocorrncias da tabela vendedores que esto associadas
tabela pedidos, e cujas ocorrncias da tabela item de pedido, relacionada com a tabela
pedidos e com a tabela produtos, so de produtos com unidade 'G ', ou seja, Grama.
Condio que satisfaz a query:

Resultado:

Todos os itens de pedido de um pedido tm unidade G.

NOME CLIENTE

Mostrar o nome dos vendedores associados a esses pedidos.

Ana
Susana

Sabemos que esse comando complicado de entender, por isto tentamos uma
forma de explic-lo em uma linguagem mais natural, entretanto sabemos, caro leitor
que mesmo assim talvez no tenhamos conseguido ser claros completamente.
Problema: - Subquery testando a existncia
- Quais clientes esto presentes em mais de trs pedidos?

Entendendo o comando:
Sempre analisamos a query entre parnteses primeiro.
Neste Select, estamos contando ( Count) os pedidos de cada cliente e
selecionando os clientes que tm mais de trs Pedidos
A query principal, por assim dizer, somente lista o nome dos clientes que
EXISTEM nesse conjunto obtido (EXIST).
Destaque-se aqui a diferena entre o comando select com EXIST e com NOT
IN (IN):

No encontramos sintaxe especfica neste caso para MS-SQL Server.

Quando utilizamos EXIST, no colocamos nenhum nome de coluna antes da


clusula, e quando utilizamos IN ou NOT IN, somos obrigados a colocar o nome da
coluna antes.
WHERE coluna IN (NOT IN) - retorna uma lista de zero ou mais valores.
WHERE EXIST ( NOT EXIST) - retorna um valor falso ou verdadeiro.
Problema - Criar uma nova tabela com o resultado de um SELECT.
Quando usamos um comando Select com a clusula INTO, definimos uma
tabela e colocamos os dados resultantes da query dentro dela.
falhar.

14.4.4 - Inserindo, Modificando e Apagando Registros


A) Adicionando Registro Tabela
Forma:
INSERT INTO <nome da tabela>
<nome da(s) coluna(s)>)
VALUES (<valores>);

Problema:

Se a tabela j existir com o mesmo nome dado no comando, esse comando ir

- Adicionar o produto 'parafuso' tabela produto.

Sintaxe Bsica MS-SQL Server

Diagrama grfico:

SELECT <lista de colunas>


INTO <nova tabela>
FROM < lista de tabelas>
WHERE <condies de seleo>
No MS-SQL Server a clusula INTO criar uma nova tabela permanente
somente se a opo select into/bulkcopy estiver setada, caso contrrio estaremos
criando uma tabela temporria.
Se as colunas selecionadas na lista de colunas no possurem nomes (SELECT
*), as novas colunas criadas na nova tabela tambm no possuiro nomes e somente
podero ser selecionadas por meio de um SELECT * FROM <nome da tabela>.

Sintaxe:
INSERT into produto
VALUES (108,
'Parafuso', 'Kg' ,

1.25);

A clusula VALUE especifica os dados que voc deseja inserir na tabela. A


clusula VALUE uma palavra requerida para introduzir no comando uma lista de
valores para cada coluna.
Se no especificados os nomes de colunas, essa lista de valores dever estar na
ordem das colunas definidas no comando CREATE TABLE.
B) Adicionando Registros usando um SELECT
Formato:
No encontramos referncia sobre a utilizao dessa clusula no MS-SQL Server de forma
diferenciada.

INSERT INTO <nome da tabela>


(<nome da(s) coluna(s)>)

257

SELECT <nome da(s) coluna(s)>


FROM <nome da tabela> WHERE
<condio>;

C) Atualizando um Registro - UPDATE


A atualizao de dados em linhas existentes na tabela permite que :

Problema:

Especifique-se uma determinada coluna e altere-se seu valor.

- Cadastrar como cliente os vendedores que emitiram mais de 50 pedidos.


Usar para cdigo de cliente o mesmo cdigo de vendedor.

Seja indicada uma linha especfica ou uma condio de identificao de linhas


para que sejam alterados valores de determinadas colunas.

Diagrama grfico:

Formato:
UPDATE <nome da tabela>
SET <nome da(s) coluna(s)> = valor
WHERE <condio>;
Problema:
- Alterar o valor unitrio do produto 'parafuso' de R$ 1.25 para R$ 1.62.
Diagrama grfico:

Sintaxe ANSI 92:


INSERT into cliente (cod_cliente, nome_cliente)
SELECT cod_vendedor, nome_vendedor/ COUNT (*)
FROM vendedor , pedido
WHERE Vendedor.cod_vendedor = Pedido.cod_vendedor
HAVING COUNT(*) > 50;

Sintaxe:
UPDATE produto
SET val_unit = 1.62
WHERE descrio = 'Parafuso';

Sintaxe MS-SQL Server:


INSERT cliente (cod_cliente, nome_cliente)
SELECT cod_vendedor, nome_vendedor, COUNT(*)
FROM
vendedor , pedido
WHERE Vendedor.cod_vendedor = Pedido.cod_vendedor
HAVING COUNT(*) > 50;

A diferena de sintaxe se resume somente existncia da clusula INTO


no SQL ANSI 92 e cumpre destacar que ORACLE exige a clusula INTO.

Resultado na tabela:
COD_PRODUTO

DESCRIO

UNIDADE

VAL_UNIT

108

parafuso

Kg

1.62

Problema:
- Atualizar o salrio fixo de todos os vendedores em 27% mais uma
bonificao de R$ 100,00.

Diagrama grfico:

D) Alterando Registros com dados de outra Tabela


Para explicar esse comando, vamos supor que nossa tabela de produtos
possua um campo de vendas acumuladas do ano.
Diagrama Grfico
PRODUTO
Cdigo_do_produtoO
Descrio Unidade

Sintaxe:
UPDATE vendedor
SET salrio_fixo = (salrio_fixo * 1.27) + 100.00;

O resultado desse comando faz com que todos os vendedores tenham o


mesmo valor de salrio fixo.
A sintaxe idntica para Microsoft SQL SERVER.

Vai. Unit.
Vendas_acumuladas

Problema:
Atualizar as vendas acumuladas do ano para cada produto.

- Acrescentar 2,5% ao preo unitrio dos produtos que estejam abaixo da


mdia dos preos, para aqueles comprados a Quilo.

UPDATE Produto
SET Vendas_acumuladas = 0
UPDATE Produto
SET Vendas_acumuladas = ( SELECT SUM (quantidade)
FROM Item_de_pedido)

Diagrama grfico:

Resultado na tabela

Problema:

Cdigo do
produto

Unidade do
produto

Descrio do
produto

Valor
unitrio

Vendas
Acumuladas

25
31
78
22
30
53
13
45
87
77

Kg
BAR
L
M
SAC
M
G
M
M
M

Queijo
Chocolate
Vinho
Linho
Acar
Linha
Ouro
Madeira
Cano
Papel

0,97
0,87
2,00
0,11
0,30
1,80
6,18
0,25
1,97
1,05

30
57
193
20
0
82
36
8
0
143

Sintaxe:
UPDATE produto
SET val_unit = val_unit * 1.025
WHERE val_unit <
SELECT AVG(val_unit)
FROM produto
WHERE unidade = 'Kg');

D) Apagando Registros da Tabela


Formato:
DELETE FROM <nome da tabela>
WHERE <condio>;

Problema:
- Apagar todos os vendedores com faixa de comisso nula.
Diagrama grfico:

D.l) Apagando Registros da Tabela com Base em Dados de


Outra Tabela
Problema:
- Apagar todos os registros de item de pedidos realizados para produtos que
possuam "lh" no nome.
Sintaxe ANSI92:

Sintaxe:
DELETE FROM vendedor
WHERE faixa_comisso IS NULL;

Problema:
- Apagar todos os registros de pedidos realizados por vendedores
fantasmas (operao caa-fantasma).
Diagrama grfico:

DELETE FROM item_de_pedido WHERE


pedido.cod_produto IN (SELECT * FROM produto,
item_de_pedido WHERE
produto.cod_produto = item_de_pedido.cod_produto AND
produto.descricao LIKE %lh%)

Sintaxe Micrososft-SQL Server:


DELETE FROM item_de_pedido FROM
produto P, item_de_pedido I WHERE
P.cod_produto = I.cod_produto AND
produto.descrio LIKE %lh%)

14.4.5 - Utilizando Views


Uma VIEW um caminho alternativo para visualizarmos dados derivados de
uma ou mais tabelas em um banco de dados. Um usurio pode necessitar ver partes
selecionadas de dados com nome, departamento e supervisor, porm no visualizar
salrio. VIEWS tambm podem ser utilizadas para informao calculada ou derivada,
como preo total de um item de pedido que calculado por meio da multiplicao de
quantidade e preo unitrio.

Sintaxe:
DELETE FROM pedido
WHERE NOT EXIST
(SELECT vendedor
FROM vendedor
WHERE cod_vendedor = Pedido.cod_vendedor);

As tabelas criadas em um banco de dados relacionai tm existncia fsica


dentro do sistema de computao. Muitas vezes necessrio criar tabelas que no
ocupem espao fsico, mas que possam ser utilizadas como as tabelas normais. Essas
so chamadas de VIEWS (tabelas virtuais).
Como as TABELAS REAIS, as VIEWS devem ser criadas:
Formato:
CREATE VIEW <nome da VIEW>
(<nome da(s) coluna(s)>) AS

SELECT <nome da(s) coluna(s)>


FROM <nome da tabela> WHERE
<condio> [WITH CHECK
OPTION];

Diagrama grfico:

As VIEWS so utilizadas para se ter uma particular viso de uma


tabela, para que no seja necessria a utilizao do conjunto como um todo.
Restries de Views.
UNION

NO Utilize SELECT INTO,

ORDER BY,

COMPUTE,

COMPUTE BY

OU

Problema:
Criar uma VIEW que contenha s os produtos cuja medida seja
metro.
Diagrama Grfico:

Sintaxe:
CREATE VIEW salrio_medio (cod_vendedor,
nome_vendedor, salrio_medio) AS SELECT cod_vendedor,
nome_vendedor, salario_fixo/12 FROM vendedor;

14.4.6 - Criando uma View por meio de um Join


Problema:
- Criar uma VIEW contendo os vendedores, seus
pedidos efetuados e os respectivos produtos.
Sintaxe:
CREATE VIEW PR_metro (cod_PR_metro,
descrio, unidade) AS SELECT
cod_produto, descrio, unidade FROM
produto WHERE unidade = 'M';

Problema:

Criar uma VIEW contendo o cdigo do vendedor, o seu nome e o


salrio fixo mdio no ano.

Diagrama grfico:

Sintaxe:

Diagrama grfico:

CREATE VIEW lista_pedidos AS


SELECT nome_vendedor, num_pedido, descrio
FROM vendedor V, pedido P, item_pedido I, produto PR
WHERE V.cod_vendedor = P.cod_vendedor and
P.num_pedido = I.num_pedido and
I.cod_produto = PR.cod_produto;

As VIEWS criadas passam a existir no banco de dados como se fossem


tabelas reais. As VIEWS so volteis, desaparecendo no final da sesso de trabalho.
Depois de criadas, elas podem ser utilizadas em todas as funes da linguagem SQL
(listar, inserir, modificar, apagar, etc).

14.4.7 - Utilizando uma View

Sintaxe:
INSERT INTO pr_metro
VALOES (110, 'Linha_10\ 'M') ;

C) Modificando
Problema:

A) Listando
Problema:
- Com base na VIEW SALRIO_MEDIO, mostrar os vendedores que
possuem mdia salarial superior a R$2.000,00.

- Alterar a descrio de 'Linha_10' para 'Linha_20' no cdigo 110 da


VIEW PR METRO.
Diagrama grfico:

Diagrama grfico:

Sintaxe:

Sintaxe:
SELECT nome_vendedor, salario_medio FROM
salario_medio WHERE salario_medio >
2000.00;

B) Inserindo
Problema:
- Inserir o registro: 110, Linha_10, M; na VIEW PR_METRO.

UPDATE pr_metro
SET descrio = 'Linha_2 0' WHERE
cod_pr_metro = 110;

D) Apagando
Problema:
- Apagar da VIEW salario_medio o registro de cdigo do
vendedor igual a 240.

Diagrama grfico:

A) O Comando Grant (garantir)


Quando uma tabela/view criada, o nome do usurio que a criou anexado,
internamente, ao nome da tabela.
Por exemplo: se a tabela produto foi criada pelo usurio Felipe, ento
internamente ela ser conhecida como Felipe.produto.

Sintaxe:
DELETE FROM salario_medio
WHERE cod_vendedor = 2 40;

E) Eliminando uma View


Formato:
DROP VIEW <nome da VIEW>;
Problema:
- Eliminar a VIEW salrio_mdio;
Sintaxe:
DROP VIEW salrio_mdio;

O criador da tabela/view tem total privilgio sobre a tabela criada podendo


disponibilizar qualquer privilgio para outros usurios pelo comando GRANT:
Sintaxe:
GRANT {ALL |Lista de privilgios} ON {nome da
tabela/view [lista de colunas]} TO {PUBLIB |lista
de usurios} [WITH GRANT OPTION]
A palavra ALL falta um verbo quando qualquer previlgio aplicvel ao
objeto, ou ento especificamos qual o previlgio que est sendo dado (SELECT,
UPDATE, etc).
A clusula ON especifica a tabela ou view e suas colunas para as quais est
sendo dado o previlgio.
** - Importante: Somente pode ser utilizada uma tabela ou view por comando.
As diferentes verses de SQL dos SGBDs relacionais incluem diferentes
conjuntos de previlgios. SELECT, UPDATE, DELETE e INSERT esto sempre
presentes em todos esses conjuntos, indiferentemente do SGBD.

14.4.8 - Garantindo os Privilgios de Acesso - Grant e


Revoke

Os previlgios podem ser especificados para algumas colunas , porm devem


ser todas da mesma tabela. Se no for especificada nenhuma coluna, os previlgios
valem para todas.

Muitos sistemas de banco de dados relacionais podem ser acessados por


diversos usurios. Cada usurio tem uma determinada necessidade em relao aos
dados armazenados. De acordo com o projeto do banco de dados, alguns usurios s
podem consultar alguns dados, outros podem atualizar, outros podem inserir, etc. Para
que o dado fique protegido do uso indevido de qualquer usurio, a linguagem SQL
permite a definio dos privilgios que cada um pode ter em relao s tabelas criadas
no banco de dados.

A clusula opcional WITH GRANT OPTION permite que quando se d o


previlgio a um usurio, ele passe esse previlgio para os outros usurios.

Os privilgios garantem a segurana e a integridade dos dados, bem como a


responsabilidade de cada usurio sobre seus dados especficos.

Lista de opes de privilgios:


Select

=> O pode
tabela

executar

uma

consulta

sobre

Insert

=> pode

executar

uma

insero

sobre

Problema:

tabela
Delete

=> pode apagar registros da tabela

Update

=>O pode modificar registros na tabela

All privileges/all
<usurio>

PUBLIC

=> pode executar


a tabela

qualquer

operao

- Disponibilizar para seleo, s os campos cdigo de vendedor e


nome do vendedor da tabela vendedor a todos os usurios.
Sintaxe:
GRANT Select (cod_vendedor, nome_vendedor) ON
vendedor TO public;

sobre

=> nome do usurio que vai receber os


privilgios. Tem de ser um nome
cadastrado dentro do ambiente.
=> Concede os privilgios especificados
todos os usurios do ambiente.

Exemplos:

Podemos passar nossa concesso de privilgios a outros usurios por meio da


clusula WITH GRANT OPTION, como explicamos anteriormente
Problema:
- Conceder ao usurio FELIPE o poder de permitir a concesso de
todos os privilgios a outros usurios sobre a tabela PEDIDO.
Sintaxe:
GRANT
ALL
ON
pedido TO Felipe
WITH GRANT OPTION

GRANT SELECT ON Produto TO Maurcio; - permite s consultas ao usurio


Maurcio sobre a tabela produto;
GRANT Select, insert, update on pedido to tele_mark; - concede ao usurio
tele_mark (entrada de pedidos), os privilgios de seleo, insero e alterao sobre a
tabela PEDIDO;
GRANT All privileges on cliente to public; - permite todos os privilgios a
todos os usurios sobre a tabela cliente;
GRANT Select on cliente to Felipe, Maurcio; - concede aos usurios
Maurcio e Felipe, o privilgio de seleo sobre a tabela CLIENTE.
Problema:
- Disponibilizar para seleo, a view salrio_medio a todos os usurios.
Sintaxe:
GRANT Select ON salario_medio TO public;

Podemos, por meio do comando GRANT, disponibilizar acessos s a alguns


campos da tabela/view. Vamos a um exemplo:

B) O Comando Revoke (revogao)


Da mesma forma que o criador da tabela pode garantir (GRANT) os
privilgios de acesso aos outros usurios, ele pode revogar esses privilgios por meio
do comando REVOKE:
Formato:
REVOKE [ lista de privilgios ]
ON [nome da tabela/view] FROM
[lista de usurios];

Problema:
-

Retirar o privilgio de seleo sobre a tabela produto do usurio


Maurcio.

Sintaxe:
REVOKE select
ON produto FROM
Mauricio;

271
70

Problema:
- Revogar todos os privilgios concedidos a todos os usurios sobre a
tabela cliente.

As colunas que so regularmente utilizadas em joins devem ser indexadas


porque o sistema pode performar esses joins de forma muito mais rpida, e tempo de
resposta algo vital no desenvolvimento de projetos fsicos de bancos de dados.
Crie ndice sempre em colunas que so pesquisas por um intervalo de valores.

Sintaxe:
REVOKE select
ON cliente PROM
public;
Problema:
- Retirar os privilgios de atualizao e insero concedidos ao usurio
tele_mark sobre a tabela pedido.
Sintaxe:
REVOKE insert, update
ON pedido PROM
tele_mark

14.4.9 - Trabalhando com ndices


ndice uma estrutura que permite rpido acesso s linhas de uma tabela, com
base nos valores de uma ou mais colunas. O ndice simplesmente uma outra tabela no
banco de dados, na qual esto armazenados valores e ponteiros, arrumados de forma
ascendente ou descendente. O SGBD utiliza os ndices para pesquisar rapidamente um
determinado valor dentro do banco de dados. Por intermdio dos ponteiros se localiza
em qual linha o valor desejado est armazenado.
As tabelas de ndices so utilizadas internamente pelo SGBD, ficando
totalmente transparente ao usurio sua utilizao.

Um Check List para Criao de ndices


Quando vamos criar ndices em colunas, devemos considerar :
Criar ndice sobre coisas que vamos pesquisar com freqncia.
Indexe suas chaves estrangeiras quando precisar de "joins" mais eficientes e
performantes.

E por fim, crie ndice sempre em colunas que so utilizadas em clusulas


WHERE.
Quando no criar ndices:
Se a expectativa de retorno de linhas de uma consulta for muito alta ndices no
devem ser utilizados. Por exernplo: se uma coluna tem somente dois valores: Masculino
e Feminino, uma consulta a essa coluna sempre vai retornar uma alta quantidade de
linhas. Como um ndice no agrupado, poder ocupar muito espao e pode no ser
utilizado para consultas.
O conceito de ndice Cluster ou agrupado quando os valores constantes na
coluna podem ser agrupados em pequenos conjuntos de pesquisa, facilitando a
pesquisa na rea de ndices da tabela. Quando c nmero de valores diferentes que pode
aparecer na coluna pequeno, c ndice no agrupado. Mas nosso objetivo aqui
somente tentar dar um conceito; no vamos nos aprofundar demais, pois estes aspectos
fazem parte de um estudo todo especfico para Administradores de Bancos de Dados.
ndices agrupados ou "clustered" so dispostos na rnesma ordem fsica das
linhas da tabela, e ndices No Agrupados ou noncclustered so organizados pela
ordem lgica das linhas da tabela.
Vamos ver como se criam ndices.
A) Criando ndices
Cada ndice aplicado a uma tabela, especificando uma ou mais colunas dessa
tabela.
ndices so criados por meio do cormando CREATE INDEX, que cria um
ndice sobre colunas de uma tabela.
Formato:
CREATE [UNIQUE] INDEX <nome do
<nome da tabela> (<coluna(s ) > ) ;

ndice> ON

A clusula UNIQUE opcional e define que para aquela coluna no existiro


valores duplicados, ou seja, todos os dados armazenados na coluna sero nicos.
A juno do ndice unique e da especificao NOT NULL para uma coluna
define a chave primria da tabela quanto ao aspecto lgico, pois uma chave primria,
como vimos neste livro, no pode ser NULA.
A criao dos ndices depende muito do projeto do banco de dados e pelas
necessidades de pesquisa formuladas pelos usurios do banco de dados. Ds ndices
esto muito ligados s necessidades de velocidade na recuperao da informao, e
na execuo rpida de uma operao de JOIN.
Para cada SGBD existem clusulas especficas operacionais que devem ser
usadas, mas neste caso vamos apresentar a sintaxe padro geral do SQL ANSI.
Exemplos:
CREATE INDEX nome_pro ON

produto (descrio);

- Cria a tabela de ndices chamada nome_pro baseada no campo


descrio da tabela produto;
CREATE INDEX ped_pro

ON item_produto (num_pedido, cod_produto);

- Cria a tabela de ndices ped_pro baseada na concatenao dos


campos num_pedido e cod_produto da tabela item_pedid
importante considerar que praticamente todas as sintaxes em se
tratando de SGBDs relacionais exige que se identifique o database
proprietrio da tabela, principalmente em Microsoft SQL Server.
CREATE UNIQUE INDEX clientex
ON [nome do database]cliente (cod_cliente);

- Cria o ndice nico para a tabela cliente baseada no cdigo do


cliente, no podendo haver duplicidade de informao
armazenada.

C) Eliminando ndices
Da mesma forma que um ndice criado, ele pode ser eliminado, dependendo
das necessidades do projeto do banco de dados.
Formato:
DROP index <nome do ndice>;

Exemplos:
DROP index nome_pro ;
DROP index ped_pro ;

14.4.10 - Tpicos Avanados de SQL


A) Combinando Resultados de Pesquisas (UNION)
Eventualmente, necessrio combinar os resultados de duas ou mais consultas
feitas sobre tabelas. Para realizar esta operao, a linguagem SQL oferece o operador
UNION e uma listagem contendo os resultados das consultas combinadas.
Problema:
- Listar os nomes e cdigos dos vendedores que tm salrio fixo maior que
R$ 1.000,00 e clientes que residem no Rio de Janeiro.
Diagrama grfico:

Sintaxe:

Sintaxe Microsoft SQL Server :

SELECT codigo = cod_cliente, nome = nome_cliente


FROM cliente
WHERE UF = 'RJ'
UNION
SELECT cod_vendedor, nome_vendedor
FROM vendedor
WHERE salario_fixo > 1000.00

** Observa-se que as duas listas de colunas dos SELECT contm o mesmo


nmero de itens (duas colunas) e os tipos de dados so compatveis.

C) Realizando um JOIN entre uma Tabela e ela mesma


s vezes, necessrio realizar pesquisas complexas dentro da mesma tabela.
Porque esse join envolve uma tabela em juno com ela mesma, necessrio que se
providenciem dois aliases para a tabela.
Este tipo de enfoque melhor explicado com um exemplo:
Problema:
- Determinar quais vendedores cujo estado Califrnia, residem na mesma
cidade Oakland e vivem no mesmo ZIP Code (Cep americano):

SELECT nome_menor = V1.nome_vendedor,


salario_menor = V1.salario_fixo,
nome_maior = V2.nome_vendedor,
salario_maior = V2.salario_fixo,
FROM vendedor V1 vendedor V2
WHERE V1. salario_fixo < V2 . salario_fixo ORDER BY 1;

Resultado:

NOME MENOR

SALRIO MENOR

NOME MAIOR

SALRIO MAIOR

Carlos
Carlos
Carlos
Carlos
Carlos
Felipe

2490,00
2490,00
2490,00
2490,00
2490,00
4600,00
2780,00
2780,00
2780,00
2650,00
2650,00
2650,00
2650,00

Joo

2780,00
9500,00
4600,00
2650,00
2930,00
9500,00
9500,00
4600,00
2930,00
2780,00
9500,00
4600,00
2930,00

Joo
Joo
Joo
Joo
Joo
Joo
Joo
.

Diagrama Grfico:

Antnio
Felipe
Joo
Maurcio
Antnio
Antnio
Felipe
Maurcio

Joo
Antnio
Felipe
Maurcio

A seguir, ser apresentado o uso da Linguagem SQL para a construo das


bases de dados dos estudos de casos apresentados no Captulo 11. Sero utilizados
como SGBD, o ORACLE Verso 7e Microsoft SQL Server 7.0 .

14.5 - Estudo de Caso 1


Para que o nosso leitor possa comparar as sintaxes dos comandos SQL, nesta
reviso estamos apresentando os scripts gerados para os estudos de caso deste livro.

Sintaxe ANSI
SELECT nome_menor = V1.nome_vendedor,
salario_menor = V1.salario_fixo,
nome_maior = V2.nome_vendedor,
salario_maior = V2.salario_fixo,
FROM vendedor VI CROSS JOIN vendedor V2
WHERE V1. salario_fixo < V2 . salario_fixo ORDER BY 1 ;

Utilizamos para este fim o software ERWin 3.5 para os servidores SQL
Oracle e Microsoft SQL Server.
Desta forma, o leitor ter sua disposio duas formas de criao para os
bancos de dados fsicos dos estudos de caso. Bom proveito, amigo!

Microsoft-SQL Server. 7.0


CREATE TABLE ator (
cdator
noator
idade
nacionalidade
) go
CREATE TABLE gnero (
cd_genero
nome_genero
) go

nome_personagem
(cdfilme)
int NOT NULL,
char(30) NULL,
int NULL,
char(20) NULL

int NOT NULL,


char(30) NULL

CREATE TABLE filme (


cdfilme
int NOT NULL,
cddiretor
int NULL,
titulo_original
char(30) NULL,
titulo_brasil
char(30) NULL,
impropriedade
int NOT NULL,
durao
int NULL,
origem
char(15) NULL,
cd_genero
int NULL,
FOREIGN KEY (cddiretor)
REFERENCES ator, FOREIGN KEY
(cd_genero)
REFERENCES gnero
) go
CREATE INDEX XIF19filme ON filme
(
cd_genero
)
go
CREATE INDEX XIF24filme ON filme (
cddiretor
) go
CREATE TABLE elenco (
cdator
cdfilme
numero_personagem
tempo_de_atuacao

int NOT NULL,


int NOT NULL,
int NOT NULL,
datetime NULL,

(cdator)
go

char(30) NULL, FOREIGN KEY


REFERENCES filme, FOREIGN KEY
REFERENCES ator )

CREATE INDEX XIF2 2elenco ON elenco (


cdator ) go
CREATE INDEX XIF23elenco ON elenco
(
cdfilme
)
go
CREATE TABLE cinema (
cdcinema
int NOT NULL,
nome_fantasia
char(30)
Logradouro
char(30) NULL,
Bairro
char(30) NULL,
Municipio
char(30) NULL,
Estado
char(20) NULL,
CEP
char(9) NULL,
Capacidade
int NULL
)
go

NULL,

CREATE TABLE passa (


cdcinema
int NOT NULL,
cdfilme
int NOT NULL,
data_inicio_exibicao
datetime
NULL,
data_fim_exibicao
datetime
NULL,
FOREIGN
KEY
(cdfilme)
REFERENCES filme, FOREIGN KEY
(cdcinema)
REFERENCES cinema )
go
CREATE INDEX XIF17passa ON passa (
cdcinema )
go
CREATE INDEX XIF18passa ON passa (
cdfilme

go
CREATE INDEX XIF19filme ON filme
CREATE TABLE sesso (
cdfilme
int NULL,
cdcinema
int NULL,
data_sessao
datetime NULL,
publico
int NULL,
horario_sessao
datetime NULL,
FOREIGN KEY (cdcinema, cdfilme)
REFERENCES passa
)
go
CREATE INDEX XIF20sessao ON sesso (
cdfilme,
cdcinema
) go

Oracle 8.xx
CREATE TABLE ator (
cdator
INTEGER NOT NULL,
noator
CHAR(30) NULL,
idade
INTEGER NULL,
nacionalidade
CHAR(20) NULL,
PRIMARY KEY (cdator)
);
CREATE TABLE gnero (
cd_genero
INTEGER NOT NULL,
nome_genero
CHAR(3 0) NULL,
PRIMARY KEY (cd_genero)
);
CREATE TABLE filme (
cdfilme
INTEGER NOT NULL,
cddiretor
INTEGER NULL,
titulo_original
CHAR(30) NULL,
titulo_brasil
CHAR(30) NULL,
impropriedade
INTEGER NOT NULL,
durao
INTEGER NULL,
origem
CHAR(15) NULL,
cd_genero
INTEGER NULL,
PRIMARY KEY (cdfilme),
FOREIGN KEY (cddiretor)
REFERENCES ator,
FOREIGN KEY (cd_genero)
REFERENCES gnero

cd_genero
CREATE INDEX XIF24filme ON filme
cddiretor

CREATE TABLE elenco (


cdator
INTEGER NOT NULL,
cdfilme
INTEGER NOT NULL,
numero_personagem
INTEGER NOT NULL,
tempo_de_atuacao
DATE NULL,
nome_personagem
CHAR(30) NULL, PRIMARY
KEY (cdator, cdfilme, numerojerso FOREIGN
KEY (cdfilme)
REFERENCES filme,
FOREIGN KEY (cdator)
REFERENCES ator
CREATE INDEX XIF22elenco ON elenco
cdator
CREATE INDEX XIF23elenco ON elenco
cdfilme
CREATE TABLE cinema (
cdcinema
INTEGER NOT NULL,
nome_fantasia
CHAR(30) NULL,
Logradouro
CHAR(3 0) NULL,
Bairro
CHAR(30) NULL,
Municipio
CHAR(30) NULL,
Estado
CHAR(20) NULL,
CEP
CHAR(9) NULL,
Capacidade
INTEGER NULL,
PRIMARY KEY (cdcinema)
);
CREATE TABLE passa (
cdcinema
INTEGER NOT NULL,
cdfilme
INTEGER NOT NULL,
data_inicio_exibicao DATE NULL,
data_fim_exibicao
DATE NULL,

PRIMARY KEY (cdcinema, cdfilme),


FOREIGN KEY (cdfilme)
REFERENCES filme,
FOREIGN KEY (cdcinema)
REFERENCES cinema
) I

CREATE INDEX XIF17passa ON passa


cdcinema
CREATE INDEX XIF18passa ON passa
cdfilme

CREATE TABLE sesso (


cdfilme
INTEGER NULL,
cdcinema
INTEGER NULL,
data_sessao
DATE NULL,
publico
INTEGER NULL,
horario_sessao
DATE NULL,
FOREIGN KEY (cdcinema, cdfilme)
REFERENCES passa
);
CREATE INDEX XIF20sessao ON sesso
(
cdfilme,
cdcinema
) ;

CREATE TABLE Disciplina (


Codigo_da_disciplina INTEGER NOT NULL,
Codigo_do_Departamento INTEGER NOT NULL,
Nome_Disciplina
CHAR(20) NULL,
Descrio_Curricular CHAR(40) NULL,
PRIMARY
KEY
(Codigo_da_dis<
Codigo_do_Departamento) ,
FOREIGN KEY (Codigo_do_Departamento)
REFERENCES Departamen
);
CREATE UNIQUE INDEX XPKDisciplina ON Disciplina
(
Codigo_da_disciplina,
Codigo_do_Departamento
);
CREATE INDEX XIF26Disciplina ON Disciplina
(
Codigo_do_Departamento
);
CREATE TABLE Pre_requisito (
Codigo_do_Departamento INTEGER NOT NULL,
Codigo_da_disciplina INTEGER NOT NULL,
Codigo_Prerequisito CHAR(18) NULL,
Norma_CFE
CHAR(18) NULL,
PRIMARY
KEY
(Codigo_do_Depar1
Codigo_da_disciplina),
FOREIGN

KEY

Codigo_do_Departamento)

14.6 - Estudo de Caso 2

FOREIGN
KEY
Codigo_do_Departamento)

(Codigo_da_disc

REFERENCES Disciplina
(Codigo_da_dis<i
REFERENCES Disciplina

Oracle 8.xx

);

CREATE TABLE Departamento (


Codigo_do_Departamento INTEGER NOT NULL,
Nome_Depto
CHAR(20) NULL,
PRIMARY KEY (Codigo_do_Departamento)
);

CREATE UNIQUE INDEX XPKPre_requisito ON Pre_requis:


(
Codigo_do_Departamento,
Codigo_da_disciplina
);

CREATE UNIQUE INDEX XPKDepartamento ON


Departamento
(
Codigo_do_Departamento
);

CREATE TABLE Professor (


Codigo_do_Departamento INTEGER NOT NULL,
Codigo_do_professor INTEGER NOT NULL,
Nome_Professor
CHAR(30) NULL,
Inscrio_CFE
INTEGER NULL,

PRIMARY
KEY
(Codigo_do_Departamento,
Codigo_do_professor) ,
FOREIGN KEY (Codigo_do_Departamento)
REFERENCES Departamento )
;
CREATE UNIQUE INDEX XPKProfessor ON Professor
(
Codigo_do_Departamento,
Codigo_do_professor
);
CREATE INDEX XIFllProfessor ON Professor
(
Codigo_do_Departamento
);
CREATE TABLE Habilitao (
Codigo_do_Departamento INTEGER NOT NULL,
Codigo_do_professor INTEGER NOT NULL,
Codigo_da_disciplina INTEGER NOT NULL,
Data_Habilitacao
DATE NULL,
PRIMARY
KEY
(Codigo_do_Departamento,
Codigo_do_professor,
Codigo_da_disciplina) ,
FOREIGN
KEY
(Codigo_do_Departamento,
Codigo_do_professor)
REFERENCES Professor,
FOREIGN
KEY
(Codigo_da_disciplina,
Codigo_do_Departamento)
REFERENCES Disciplina )
;
CREATE UNIQUE INDEX XPKHabilitacao ON Habilitao (
Codigo_do_Departamento,
Codigo_do_professor,
Codigo_da_disciplina )
;
CREATE INDEX XIF13Habilitacao ON Habilitao
(
Codigo_da_disciplina,
Codigo_do_Departamento )
;
CREATE INDEX XIF14Habilitacao ON Habilitao
(
Codigo_do_Departamento,

Codigo_do_professor
) ;
CREATE TABLE Curso (
Codigo_do_Departamento INTEGER NOT NULL,
Codigo_Curso
INTEGER NOT NULL,
Nome_Curso
CHAR(20) NULL,
PRIMARY
KEY
(Codigo_do_Departai
Codigo_Curso),
FOREIGN KEY (Codigo_do_Departamento)
REFERENCES Departamento
);
CREATE UNIQUE INDEX XPKCurso ON Curso
(
Codigo_do_Departamento,
Codigo_Curso
);
CREATE INDEX XIF18Curso ON Curso
(
Codigo_do_Departamento
) ;
CREATE TABLE Possui (
Codigo_do_Departamento INTEGER NOT NULL,
Codigo_Curso
INTEGER NOT NULL,
Codigo_da_disciplina INTEGER NOT NULL,
Norma_CFE
CHAR(18) NULL,
PRIMARY KEY (Codigo_do_Departamento, Codigo_Cv
Codigo_da_disciplina),
FOREIGN
KEY
(Codigo_da_discir.
Codigo_do_Departamento)
REFERENCES Disciplina,
FOREIGN KEY (Codigo_do_Departamento, Codigo_Ct
REFERENCES Curso
);
CREATE UNIQUE INDEX XPKPossui ON Possui (
Codigo_do_Departamento,
Codigo_Curso,
Codigo_da_disciplina )
;
CREATE INDEX XIFlOPossui ON Possui
(
Codigo_da_disciplina,
Codigo_do_Departamento
) ;

CREATE INDEX XIF9Possui ON Possui


(
Codigo_do_Departamento,
Codigo_Curso )
;
CREATE TABLE Aluno (
Numero_matricula
INTEGER NOT NULL,
Codigo_do_Departamento INTEGER NOT NULL,
Codigo_Curso
INTEGER NOT NULL,
Nome
CHAR(20) NOT NULL,
Endereo
CHAR(30) NULL,
Bairro
CHAR(20) NULL,
Cidade
CHAR(20) NULL,
Estado
CHAR(20) NULL,
CEP
INTEGER NOT NULL,
PRIMARY
KEY
(Numero_matricula,
Codigo_do_Departamento,
Codigo_Curso), FOREIGN KEY
(Codigo_do_Departamento, Codigo_Curso)
REFERENCES Curso
);
CREATE UNIQUE INDEX XPKAluno ON Aluno (
Numero_matricula,
Codigo_do_Departamento,
Codigo_Curso )
;
CREATE INDEX XIF22Aluno ON Aluno
(
Codigo_do_Departamento,
Codigo_Curso )
;
CREATE TABLE CURSA (
Codigo_do_Departamento INTEGER NOT NULL,
Codigo_da_disciplina INTEGER NOT NULL,
Numero_matricula
INTEGER NOT NULL,
Codigo_Curso
INTEGER NOT NULL,
nota_final
DECIMAL(2) NULL,
PRIMARY
KEY
(Codigo_do_Departamento,
Codigo_da_disciplina,
Numero_matricula, Codigo_Curso),
FOREIGN
KEY
(Codigo_da_disciplina,
Codigo_do_Departamento)
REFERENCES Disciplina,
FOREIGN
KEY
(Numero_matricula,
Codigo_do_Departamento,

Codigo_Curso)

REFERENCES Aluno )
;
CREATE UNIQUE INDEX XPKCURSA ON CURSA
(
Codigo_do_Departamento,
Codigo_da_disciplina,
Numero_matricula,
Codigo_Curso
);
CREATE INDEX XIF3CURSA ON CURSA
(
Numero_matricula,
Codigo_do_Departamento,
Codigo_Curso
);
CREATE INDEX XIF4CURSA ON CURSA
(
Codigo_da_disciplina,
Codigo_do_Departamento
) ;
CREATE TABLE REALIZOU (
Codigo_do_Departamento INTEGER NOT NULL,
Numero_matricula
INTEGER NOT NULL,
Codigo_da_disciplina INTEGER NOT NULL,
Codigo_Curso
INTEGER NOT NULL,
media
DECIMAL(1) NOT NULL,
periodo
INTEGER NOT NULL,
PRIMARY
KEY
(Codigo_do_Departair
Numero_matricula,
Codigo_da_disciplina, Codigo_Curso),
FOREIGN
KEY
(Codigo_da_discip
Codigo_do_Departamento)
REFERENCES Disciplina,
FOREIGN
KEY
(Numero_matri
Codigo_do_Departamento,
Codigo_Curso)
REFERENCES Aluno
);
CREATE UNIQUE INDEX XPKREALIZOU ON REALIZOU
(
Codigo_do_Departamento,
Numero_matricula,
Codigo_da_disciplina,
Codigo_Curso
);

CREATE INDEX XIF2 0REALIZOU ON REALIZOU


(
Codigo_do_Departamento,
Numero_matricula,
Codigo_Curso ;
CREATE INDEX XIF21REALIZOU ON REALIZOU
(
Codigo_do_Departamento,
Codigo_da_disciplina
) ;
CREATE TABLE Regncia (
Codigo_do_Departamento INTEGER NOT NULL,
Codigo_do_professor INTEGER NOT NULL,
Codigo_da_disciplina INTEGER NOT NULL,
nro_periodo
CHAR(18) NULL,
txavaliacao
CHAR(IO) NULL,
PRIMARY
KEY
(Codigo_do_Departamento,
Codigo_do_professor,
Codigo_da_disciplina),
FOREIGN
KEY
(Codigo_da_disciplina,
Codigo_do_Departamento)
REFERENCES Disciplina,
FOREIGN
KEY
(Codigo_do_Departamento,
Codigo_do_professor)
REFERENCES Professor )
;
CREATE UNIQUE INDEX XPKRegencia ON Regncia
(
Codigo_do_Departamento,
Codigo_do_professor,
Codigo_da_disciplina
) ;
CREATE INDEX XIF24Regencia ON Regncia
(
Codigo_do_Departamento,
Codigo_do_professor
);
CREATE INDEX XIF25Regencia ON Regncia
(
Codigo_do_Departamento,
Codigo_da_disciplina
) ;

Microsoft-SOL Server. 7.0


CREATE TABLE Departamento (
Codigo_do_Departamento int NOT NULL,
Nome_Depto
char(20) NULL,
PRIMARY KEY (Codigo_do_Departamento)
)
go
CREATE TABLE Disciplina (
Codigo_da_disciplina int NOT NULL,
Codigo_do_Departamento int NOT NULL,
Nome_Disciplina
char(20) NULL,
Descricao_Curricular char(40) NULL,
PRIMARY
KEY
(Codigo_da_discip!
Codigo_do_Departamento),
FOREIGN KEY (Codigo_do_Departamento)
REFERENCES Departamento
)
go
CREATE TABLE Pre_requisito (
Codigo_do_Departamento int NOT NULL,
Codigo_da_disciplina int NOT NULL,
Codigo_Prerequisito char(18) NULL,
Norma_CFE
char(18) NULL,
PRIMARY

KEY

Codigo_da_disciplina),
FOREIGN
KEY
Codigo_do_Departamento)
FOREIGN
KEY
Codigo_do_Departamento)

(Codigo_do_Departam<

(Codigo_da_discip:
REFERENCES Disciplina,
(Codigo_da_discipJ
REFERENCES Disciplina

)
go
CREATE TABLE Professor (
Codigo_do_Departamento int NOT NULL,
Codigo_do_professor int NOT NULL,
Nome_Professor
char(30) NULL,
Inscricao_CFE
int NULL,
PRIMARY
KEY
(Codigo_do_Departam
Codigo_do_professor),
FOREIGN KEY (Codigo_do_Departamento)
REFERENCES Departamento
)

go
CREATE TABLE Habilitao (
Codigo_do_Departamento int NOT NULL,
Codigo_do_professor int NOT NULL,
Codigo_da_disciplina int NOT NULL,
Data_Habilitacao
datetime NULL,
PRIMARY
KEY
(Codigo_do_Departamento,
Codigo_do_professor,
Codigo_da_disciplina),
FOREIGN
KEY
(Codigo_do_Departamento,
Codigo_do_professor)
REFERENCES Professor,
FOREIGN
KEY
(Codigo_da_disciplina,
Codigo_do_Departamento)
REFERENCES Disciplina
)
go
CREATE TABLE Curso (
Codigo_do_Departamento int NOT NULL,
Codigo_Curso
int NOT NULL,
Nome_Curso
char(20) NULL,
PRIMARY KEY (Codigo_do_Departamento, Codigo_Curso),
FOREIGN KEY (Codigo_do_Departamento)
REFERENCES Departamento
)
go
CREATE TABLE Possui (
Codigo_do_Departamento int NOT NULL,
Codigo_Curso
int NOT NULL,
Codigo_da_disciplina int NOT NULL,
Norma_CFE
char(18) NULL,
PRIMARY KEY (Codigo_do_Departamento, Codigo_Curso,
Codigo_da_disciplina),
FOREIGN
KEY
(Codigo_da_disciplina,
Codigo_do_Departamento)
REFERENCES Disciplina,
FOREIGN KEY (Codigo_do_Departamento, Codigo_Curso)
REFERENCES Curso
)
go

CREATE TABLE Aluno (


Numero_matricula
int NOT NULL,
Codigo_do_Departamento int NOT NULL,
Codigo_Curso
int NOT NULL,
Nome
char(20) NOT NULL,
Endereo
char(30) NULL,
Bairro
char(2 0) NULL,
Cidade
char(20) NULL,
Estado
char(20) NULL,
CEP
int NOT NULL,
PRIMARY

KEY

(Numero_matri<

Codigo_do_Departamento,
Codigo_Curso), FOREIGN KEY
(Codigo_do_Departamento, Codigo_Cur
REFERENCES Curso
)
go
CREATE TABLE CURSA (
Codigo_do_Departamento int NOT NULL,
Codigo_da_disciplina int NOT NULL,
Numero_matricula
int NOT NULL,
Codigo_Curso
int NOT NULL,
nota_final
decimal(2) NULL,
PRIMARY
KEY
(Codigo_do_Departame
Codigo_da_disciplina,
Numero_matricula, Codigo_Curso),
FOREIGN
KEY
(Codigo_da_discipl
Codigo_do_Departamento)
REFERENCES Disciplina,
FOREIGN
KEY
(Numero_matric
Codigo_do_Departamento,
Codigo_Curso)
REFERENCES Aluno
) go
CREATE TABLE REALIZOU (
Codigo_do_Departamento int NOT NULL,
Numero_matricula
int NOT NULL,
Codigo_da_disciplina int NOT NULL,
Codigo_Curso
int NOT NULL,
media
decimal(1) NOT NULL,
periodo
int NOT NULL,
PRIMARY
KEY
(Codigo_do_Departamen
Numero_matricula,
Codigo_da_disciplina, Codigo_Curso),

FOREIGN
KEY
Codigo_do_Departamento)
FOREIGN
KEY
Codigo_do_Departamento,
Codigo_Curso)

(Codigo_da_disciplina,
REFERENCES Disciplina,
(Numero_matricula,
REFERENCES Aluno

)
go
CREATE TABLE Regncia (
Codigo_do_Departamento int NOT NULL,
Codigo_do_professor int NOT NULL,
Codigo_da_disciplina int NOT NULL,
nro_periodo
char(18) NULL,
txavaliacao
char(10) NULL,
PRIMARY
KEY
(Codigo_do_Departamento,
Codigo_do_professor,
Codigo_da_disciplina),
FOREIGN
KEY
(Codigo_da_disciplina,
Codigo_do_Departamento)
REFERENCES Disciplina,
FOREIGN
KEY
(Codigo_do_Departamento,
Codigo_do_pro fes s or)
REFERENCES Professor
)
go

14.7 - Estudo de Caso 3


Microsoft SOL Server 7.0
CREATE TABLE VRUS (
COD_DO_VIRUS
char(18) NOT NULL,
NOME_VIRUS
char(30) NULL,
DESCRIO
char(10 0) NULL,
PRIMARY KEY (COD_DO_VIRUS)
)
go
CREATE TABLE CONTRATO (
NUMERO_DO_CONTRATO
char(18) NOT NULL,
VALOR
money NULL,
DATA_DE_INICIO
datetime
NULL,
DATA_DE_TERMINO
datetime
NULL,
PRTMARY KEY (NUMERO DO CONTRATO)

)
go
CREATE TABLE INSTITUTO (
COD_INSTITUTO
int NOT NULL,
NOME_INSTITUTO
char(30) NULL,
ENDEREO
char(18) NULL,
LOGRADOURO
char(20) NULL,
BAIRRO
char(20) NULL,
MUNICPIO
char(25) NULL,
ESTADO
char(25) NULL,
CEP
char(8) NULL,
PRIMARY KEY (COD_INSTITUTO)
)
go
CREATE TABLE PUBLICAO (
COD_PUBLICACAO
char(18) NOT NULL,
NUMERO_DO_CONTRATO
int NOT NULL,
COD_INSTITUTO
int NULL,
TITULO
char(40) NULL,
JORNAL
char(20) NULL,
NUMERO_VOLUME
char(3)
NULL,
NUMERO_DA_EDICAO
char(2)
NULL,
ANO
char ( 4) NULL,
TIPO
char(l) NULL,
PRIMARY KEY (COD_PUBLICACAO),
FOREIGN KEY (NUMERO_DO_CONTRATO)
REFERENCES CONTRATO,
FOREIGN KEY (COD_INSTITUTO)
REFERENCES INSTITUTO
)
go
CREATE INDEX XIF2PUBLICAO ON PUBLICAO
(
COD_INSTITUTO
)
go
CREATE INDEX XIF2 0PUBLICACAO ON PUBLICAO
(
NUMERO_DO_CONTRATO
)
go
CREATE TABLE PUBLICACAO_VIRUS (
COD_PUBLICACAO
char(18) NOT NULL,
COD_DO_VIRUS
char(18) NOT NULL,
PRIMARY KEY (COD_PUBLICACAO, COD_DO_VIRUS),
FOREIGN KEY (COD_DO_VIRUS)
REFERENCES VRUS,
FOREIGN KEY (COD_PUBLICACAO)
REFERENCES PUBLICAO

go
CREATE INDEX XIF2 5PUBLICACAO_VIRUS ON PUBLICACAO_VIRUS
(
COD_PUBLICACAO )
go
CREATE INDEX XIF2 6PUBLICACAO_VIRUS ON
PUBLICACAO_VIRUS
(
COD_DO_VIRUS )
go
CREATE TABLE REFERENCIA (
COD_PUBLICACAO
char(18) NOT NULL,
COD_PUBLICACAO_REFERENCIADA int NOT NULL,
PRIMARY KEY (COD_PUBLICACAO),
FOREIGN KEY (COD_PUBLICACAO)
REFERENCES PUBLICAO,
FOREIGN KEY (COD_PUBLICACAO)
REFERENCES PUBLICAO
)
go
CREATE TABLE AUTOR (
COD_AUTOR
char(18) NOT NULL,
NOME_AUTOR
char(25) NULL,
NACIONALIDADE
char(15)
NULL,
DATA_DE_NASCIMENTO datetime NULL,
PRIMARY KEY (COD_AUTOR)
)go
CREATE TABLE ESCREVE (
COD_AUTOR
char(18) NOT NULL,
COD_PUBLICACAO
char(18) NOT NULL,
DATA_ENTREGA
datetime NULL,
PRIMARY KEY (COD_AUTOR, COD_PUBLICACAO),
FOREIGN KEY (COD_PUBLICACAO)
REFERENCES PUBLICAO,
FOREIGN KEY (COD_AUTOR)
REFERENCES AUTOR
)
go
CREATE INDEX XIF4ESCREVE ON ESCREVE
(
COD_AUTOR
)
go
CREATE INDEX XIF5ESCREVE ON ESCREVE
(
COD_PUBLICACAO))go

Oracle 8.xx
CREATE TABLE VRUS (
COD_DO_VIRUS
CHAR(18) NOT NULL,
NOME_VIRUS
CHAR(3 0) NULL,
DESCRIO
CHAR(IOO) NULL,
PRIMARY KEY (COD_DO_VIRUS)
);
CREATE TABLE CONTRATO (
NUMERO_DO_CONTRATO
CHAR(18) NOT NULL,
VALOR
NUMBER NULL,
DATA_DE_INICIO
DATE NULL,
DATA_DE_TERMINO
DATE NULL,
PRIMARY KEY (NUMERO_DO_CONTRATO)
);
CREATE TABLE INSTITUTO
COD_INSTITUTO
INTEGER NOT
NOME_INSTITUTO
CHAR(30)
ENDEREO
CHAR(18)
LOGRADOURO
CHAR(20)
BAIRRO
CHAR(20)
MUNICPIO
CHAR(25)
ESTADO
CHAR(25)
CEP
CHAR(8)
PRIMARY KEY (COD_INSTITUTO)
);

(
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,

CREATE TABLE PUBLICAO (


COD_PUBLICACAO
CHAR(18) NOT NULL,
NUMERO_DO_CONTRATO
INTEGER NOT NULL,
COD_INSTITUTO
INTEGER NULL,
TITULO
CHAR(40) NULL,
JORNAL
CHAR(20) NULL,
NUMERO_VOLUME
CHAR(3)
NULL,
NUMERO_DA_EDICAO
CHAR(2)
NULL,
ANO
CHAR(4) NULL,
TIPO
CHAR(l) NULL,
PRIMARY KEY (COD_PUBLICACAO),
FOREIGN KEY (NUMERO__DO_CONTRATO)
REFERENCES CONTRATO,
FOREIGN KEY (COD_INSTITUTO)
REFERENCES INSTITUTO
) ;
CREATE INDEX XIF2PUBLICAO ON PUBLICAO

(
COD_INSTITUTO ) ;
CREATE INDEX XIF2OPUBLICAO ON PUBLICAO
(
NUMERO_DO_CONTRATO
);
CREATE TABLE PUBLICACAO_VIRUS (
COD_PUBLICACAO
CHAR(18) NOT NULL,
COD_DO_VIRUS
CHAR(18) NOT NULL,
PRIMARY KEY (COD_PUBLICACAO, COD_DO_VIRUS), FOREIGN
KEY (COD_DO_VIRUS)
REFERENCES VRUS, FOREIGN
KEY (COD_PUBLICACAO)
REFERENCES PUBLICAO
CREATE INDEX XIF25PUBLICACAO_VIRUS ON PUBLICACAO_VIRUS
COD_PUBLICACAO
CREATE INDEX XIF2 6PUBLICACAO_VIRUS ON PUBLICACAO_VIRUS
COD_DO_VIRUS

CREATE TABLE REFERENCIA (


COD_PUBLICACAO
CHAR(18) NOT NULL,
COD_PUBLICACAO_REFERENCIADA INTEGER NOT NULL, PRIMARY
KEY (COD_PUBLICACAO), FOREIGN KEY (COD_PUBLICACAO)
REFERENCES PUBLICAO, FOREIGN
KEY (COD_PUBLICACAO)
REFERENCES PUBLICAO ) ;
CREATE TABLE AUTOR (
COD_AUTOR
CHAR(18) NOT NULL,
NOME_AUTOR
CHAR(25) NULL,
NACIONALIDADE
CHAR(15) NULL,
DATA_DE_NASCIMENTO
DATE NULL,
PRIMARY KEY (COD_AUTOR)
);

CREATE TABLE ESCREVE (


COD_AUTOR
CHAR(18) NOT NULL,
COD_PUBLICACAO
CHAR(18) NOT NULL,
DATA_ENTREGA
DATE NULL,
PRIMARY KEY (COD_AUTOR, COD_PUBLICACAO), FOREIGN KEY
(COD_PUBLICACAO)
REFERENCES PUBLICAO, FOREIGN KEY
(COD_AUTOR)
REFERENCES AUTOR
);
CREATE INDEX XIF4ESCREVE ON ESCREVE (
COD_AUTOR
);
CREATE INDEX XIF5ESCREVE ON ESCREVE
( COD_PUBLICACAO
);

Valuta