Livro - Projeto de Banco de Dados - Uma Visão Prática - Felipe Machado e Mauricio Abreu

7/26/2019 Livro - Projeto de Banco de Dados - Uma Viso Prtica - Felipe Machado e Mauricio Abreu

1/156


2/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.

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, cujapostagem ser paga pela Editora Erica, bastando deposit-la em qualquer caixa de

correio, voc passar a receber, automaticamente, informaes sobre nossoslanamentos em sua rea de preferncia.

Conhecendo melhor nossos leitores e suas preferncias, vamos produzir ttulos queatendam suas necessidades.

Obrigado pela sua escolha.

Felipe Nery Rodrigues MachadoMaurcio Pereira de Abreu

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

Os problemas s podem ser enviados por:

1. E-mail:[email protected]

2. Fax: (11) 217.4060

3. Carta: Rua So Gil, 159 - Tatuap - CEP 03401-030 - So Paulo - SP

Ano: 2004 2003 2002Edio: 13 12 11 10 9 8

Editora rica Ltda.

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

Conselho Editorial:

Diretor Editorial: DiretorComercial: Diretor dePublicidade: Editorao:Desenhos:Finalizao de Capa:Reviso Gramatical:Coordenao:
mailto:[email protected]:[email protected]


3/156
http://www.erica.com.br/


4/156

Prefcio

Desde a Antigidade, o homem tem procurado transmitir e documentar seuconhecimento, 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 representavamobjetos e animais, os habitantes daquelas cavernas eternizavam a sua realidade. O homemevoluiu. 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 daatividade humana. Numa quantidade e velocidade nunca antes experimentadas. A era dainformao no s j bateu nossa porta, como ocupa nosso escritrio, sala de aula e muitasvezes 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 estmodificando o perfil comportamental das pessoas e das organizaes. Nunca, como nos ltimosanos, 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 sistemasaplicativos mudaram e evoluram de forma incrvel. A Metodologia da Engenharia daInformao, por exemplo, trouxe-nos uma srie enorme de ferramentas para o desenvolvimentoeficaz 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 deaplicativos. Estes eram os proprietrios dos dados. A modelagem de dados era entosimplesmente uma atividade paralela, quase desconhecida e muitas vezes desprezada. Quandoutilizada, seu objetivo era meramente documentacional.

Com o reconhecimento de serem os dados um dos recursos mais importantes dascorporaes, ultrapassando as prprias fronteiras dos sistemas aplicativos, a modelagem de

dados se tornou, com justa razo, a mais importante tcnica utilizada na produo dosresultados das fases de planejamento e anlise dos projetos de sistemas de informao.

Com o surgimento da Reengcnharia de Negcios e o advento do Business ProcessReengincering (BPR), volta-se a colocar nova nfase nos processos. Procura-sc agora umbalanceamento perfeito entre a anlise dos processos e dos


5/156


6/156


7/156

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 ..................................................................... ...........................27714.6- Estudo de Caso 2 ..................................................................... ...........................282

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

Temos observado ao longo dos nossos anos de experincia nodesenvolvimento de sistemas de informao, que existe uma grande dificuldade dosanalistas e programadores em entenderem a diferena entre INFORMAO eDADO. Esta dificuldade traz, como conseqncia direta, problemas na especificao emodelagem de um sistema.

A INFORMAO acrescenta algo ao conhecimento da realidade a ser

analisada. Por exemplo, a dosagem que um paciente precisa receber de umdeterminado remdio, uma INFORMAO. Este conhecimento pode ser (ou no)modelado (registrado).

O DADO uma representao, um registro de uma informao. Este DADOpode ser registrado fisicamente atravs de um papel (receita mdica), um disco decomputador ou um impulso eltrico, etc. Este registro pode ser o originador de umasrie 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 daINFORMAO, ou seja, o endereo do fabricante do remdio no tem nenhuminteresse para um sistema de controle que mantm a vida dos pacientes em um CTI.

Podemos concluir ento, que em um sistema de informaes, esto contidastodas as INFORMAES necessrias ao objetivo do sistema (manter a vida do

paciente). Os DADOS originados dessas INFORMAES sero processados pelosistema criado. Por definio, um computador no processa INFORMAES, massim, DADOS.

Introduo


8/156


9/156

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

Figura 12

A seguir, sero apresentadas algumas metodologias que so bastante utilizadasno processo de desenvolvimento de sistemas de informao. Muitas delas j noapresentam o mesmo vigor de utilizao de quando foram desenvolvidas, e

praticamente formam um conjunto evolutivo no processo de captar as reaisnecessidades 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 baixainterao 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 sabesobre o problema e o que ele deseja para solucionar o mesmo. Aps a definio doproblema, 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 utilizadastcnicas de estruturao e quase no existe oportunidade para o usurio realizaralguma alterao em pontos dos requisitos congelados. As atividades so realizadasem 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 caracterizampela alta incidncia de manuteno, pois esto sujeitos a poucas alteraes durante odesenvolvimento.

1.2 O Ciclo de Vida da Anlise EstruturadaO 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 ltimosafirmavam que era possvel escrever qualquer programa utilizando os trs construtores

bsicos: seqncia, repetio e deciso. Eles afirmavam que utilizando estesconstrutores, a programao se tornar-se-ia mais fcil de entender e manter.


10/156

A partir destas idias, no incio dos anos 70, foram surgindo os conceitos doprojeto estruturado (W. Stevens. - G. Myers - L. Constantine[21]), no qual seorganizavam as funes de um programa de forma hierrquica, sobre a qual esto

presentes dois conceitos fundamentais: Acoplamento - que retrata a comunicaoentre os mdulos do sistema, e Coeso - que fala a respeito das relaes internas dosmdulos. O produto final s estaria em um nvel aceitvel de qualidade para sercolocado 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.

Este ciclo de vida (figura 1.4) caracterizado pelo uso das tcnicasestruturadas, 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 problemasque podem influenciar no produto final.

Neste ciclo de vida, o envolvimento do usurio bastante significativo. Suaparticipao na maioria das revises traz novas sugestes e correes dos aspectos nocompatveis com suas necessidades.

1.3 - O Ciclo de Vida da Engenharia de SoftwareDurante os anos 70 com a utilizao da anlise estruturada, o desenvolvimento

de sistemas ganhou um impulso muito grande. Em decorrncia deste impulso, anecessidade de novos sistemas cresceu rapidamente e com isso as manutenestambm comearam a ter um papel proeminente no ciclo de vida dos sistemas. Istotudo levou a um aumento natural do custo de desenvolvimento e manuteno.Comeou ento a surgir uma preocupao maior relativa produtividade dos analistase programadores, com a qualidade dos produtos e com os aspectos de segurana de

programas.

Figura 1.5

Com base nestas preocupaes, foi criado o ciclo de vida da engenharia desoftware (figura 1.5), o qual veio para preencher certas lacunas deixadas pelo ciclo devida da anlise estruturada. Na engenharia de software se busca uma maior disciplinaem termos de desenvolvimento de sistemas. Ela caracterizada pela forte orientao

por processos, pela determinao bem acentuada de cada fase, enfatiza a reutilizaode cdigo de programa, prov revises e pontos de checagem bem determinados edefine mtricas

Figura 1.4


11/156

bem fundamentadas para o gerente realizar o controle da produtividade, a qualidade eo custo do produto final. Algumas mtricas da engenharia de software foramapresentadas por Bany Boehm [2] e por Arndt Von Staa [20].

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 faseimediatamente anterior para se rever os passos que levaram ao desenvolvimentodaquela onde ocorreu o problema.

1.4 - O Ciclo de Vida da Engenharia da Informao

Com estas observaes concluiu-se que os dados envolvidos em cada processoeram extremamente estveis, se comparados com os processos. Esta estabilidade eradevido ao fato de que os dados s sofrem algum tipo de mudana no momento em queo negcio tambm muda/evolui.

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

Como o centro desta metodologia o DADO, a idia principal levantar asestruturas de dados que vo dar origem aos bancos de dados, provendo um fcil acessoaos mesmos.

No decorrer de 20 anos de uso de tcnicas para o desenvolvimento desistemas, no qual a idia central era analisar com base nos processos atuaisapresentados 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 utilizaodestes processos (figura 1.6).

Figura 1.7

A engenharia da informao (figura 1.7) um conjunto integrado de tcnicasque 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 nasseguintes fases: planejamento estratgico das informaes, anlise da informaomodelagem de dados, formao dos procedimentos,

Figura 1.6


12/156


13/156


14/156

Vocs, leitores, devem estar achando no mnimo estranho, o captulo 2 falarsobre OFuturo. Normalmente, um tema como este s aparece no fim do livro. Nssentimos que ser muito importante voc saber que aquilo que o espera no futuro tem

como base os ensinamentos presentes nos prximos captulos. Esta percepo lhesdar mais motivao para estudar de forma profunda e consciente.

2.1 - A Motivao

Todos j devem ter notado na introduo, que a grande preocupao emqualquer levantamento feito com o domnio do problema e as responsabilidades dosistema. Durante muitos anos o desenvolvimento de sistemas de informao eradividido entre o levantamento dos processos (prioridade) e o levantamento dos dados.Esta forma de anlise trouxe inmeros problemas para o usurio, pois o mesmo novia o produto como uma soluo para suas necessidades.

Como vimos no captulo 1, trabalhar com os dados foi um fator vantajoso nodesenvolvimento de sistemas de informao. Mesmo com a Modelagem dainformao 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 processosEm um nico elemento. Esta unio deu origem ao conceito de modelagemorientada 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 queOO um novo pensamento sobre os problemas, organizando modelos cadavez mais prximos dos conceitos do mundo real.


15/156

O Futuro

As tcnicas de orientao a objetos apresentam vrios benefcios:

1 - Utilizam um conceito mais especializado de detalhamento darealidade (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 devida do projeto.

Esta nova forma de explorao da realidade utiliza, diretamente, os princpiosbsicos 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, pormcom relao aos demais deixa muito a desejar.

Os sistemas elaborados hoje em dia, so diferentes dos que eramdesenvolvidos h dez ou vinte anos. So maiores, mais complexos, mais volteis esofrem 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 eaumentar 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 modelagemorientada a objetos tem seu fundamento na modelagem da informao. Este livro temcomo preocupao central apresentar a tcnica de modelagem de dados. Quanto aofuturo (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 todaesta nova tecnologia. Mos obra.


16/156

Toda a realidade sempre, em princpio, bastante nebulosa e informal. Atravsda observao podemos extrair dela (realidade) fatos que nos levam a conhec-la deuma forma mais organizada.

Em um negcio, existem fatos que, observados e modelados, dizem algo arespeito do funcionamento deste negcio. Estes fatos esto ligados diretamente aofuncionamento da realidade, os quais temos grande interesse em compreender emanter.

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 feitoatravs 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 nacabea das pessoas que de forma direta ou indireta influenciam na realidade a sermodelada. 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 naobservao dos fatos relevantes que ocorrem na realidade, com finalidade de construirum sistema que possa automatizar as necessidades de informao da mesma. Nestemomento, os documentos que registram estes fatos s devem ser utilizados comoapoio ao entendimento, e no como base Para o desenvolvimento do sistema deinformaes, ou seja, no devemos ter a preocupao em simular o ambiente atual,

seja ele manual ou automatizado.

Modelagem

Conceitual


17/156


18/156


19/156


20/156


21/156

Relacionamento (E-R) o mais largamente utilizado para a representao eentendimento dos dados que compem a essncia de um sistema de informaes.

4.1 - Modelagem Conceituai de DadosAo se utilizar a Modelagem Conceituai de Dados com a tcnica de Entidades e

Relacionamentos, obteremos resultados e esquemas puramente conceituais sobre aessncia de um sistema, ou melhor sobre o negcio para o qual estamosdesenvolvendo um projeto, no representando-se procedimentos ou fluxo de dadosexistentes.

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 trabalhode modelagem de dados nos possibilita a visualizao das atividades e procedimentosque podero ser exercidos sobre estas estruturas de dados.

4.2 - Objetos ConceituaisAs literaturas existentes nunca deixam claro como podemos entender

entidades e relacionamentos. Uma vez que a maioria dos profissionais de anlise desistemas tem sua cultura baseada em sistemas procedurais, onde os dados so oresultado e no o meio, existe a necessidade de que se coloque mais enfoque didticono detalhamento do que so efetivamente entidades e relacionamentos.

As tcnicas estruturadas mais avanadas, que neste pas alcanaramdivulgao profissional a nvel prtico, baseiam-se na anlise dos Procedimentos, ecom enfoque principalmente direcionado para o Diagrama

29

O Modelo Entidade-Relacionamento


22/156

de Fluxo de Dados. Estas tcnicas estruturadas colocam as informaes derivadas dosprocedimentos em Depsitos de Dados, os quais finalmente acabam sendo traduzidosem 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 nestaabordagem de levantamento.

Vamos estabelecer como preocupao somente a necessidade de retratarmosas informaes existentes no negcio. Nosso objetivo primordial entendermos onegcio, para o qual projetaremos um sistema, atravs de seus dados.

Quando escrevemos Objetos Conceituais, no estamos pretendendo nosinserir na Orientao a Objetos. Apesar de a modelagem conceituai de dados ser a base

para o entendimento desta nova abordagem tecnolgica, o nosso objetivo narealidade ir at as razes da conceituao de modelo Entidade-Relacionamento (figura4.1).

figura 4.1 - Um Modelo E-R.


23/156

Quando Peter Chen formulou a proposta do modelo Entidade-Relacionamento,baseou-se no na viso de um sistema de aplicao como princpio e sim nacompreenso da realidade em que se situava o problema. Como iremos projetar umsistema se no entendemos o negcio para o qual ser realizado?

Chen dedicou-se a destacar a importncia de reconhecer os objetos quecompem este negcio, independentemente de preocupar-se com formas de tratamentodas informaes, procedimentos, programas, etc. Estes objetos que desejamosconhecer e modelar para um sistema, Chen classificou em dois grupos: Entidades eRelacionamentos.

Na figura 4.2, apresentado um fato comum que pode acontecer em qualquerrealidade. Este fato deve ser retratado atravs de elementos bsicos que compem omodelo Entidade-Relacionamento.

Figura 42

4.3 - EntidadesDefine-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.

Se alguma "coisa" (figura 4.3), existente no negcio nos proporcionaalgumjnteresse em mantermos dados, (informaes armazenadas sqbre_glgj. isto acaracteriza como uma Entidade do negcio.

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

importante destacarmos aqui que uma entidade a representao de umaClasse de dados do negcio, um conjunto de informaes de mesmas caractersticas, esuas instncias (ocorrncias), so a representao destes dados.

Quando falamos sobre Classe de Dados, estamos na realidade trabalhandomentalmente um nvel macro de informaes, estamos atuando com abstraesinterpretadas de acordo com o meio em que nos localizamos e seus interesses eobjetivos organizacionais.

Figura 43

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. Masesta uma comparao que no de todo real, j que estamos projetando bancos dedados, e logo tratando conjuntos de informaes.

A representao de uma Entidade no modelo EntidadeRelacionamento serealiza atravs de um retngulo, com o nome desta entidade em seu interior, como nafigura 4.4.


24/156


25/156


26/156


27/156


28/156

Pedido Nacional Pedido Exportao


29/156

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 deEntidade-Relacionamento.

Sempre que existirem topologias em uma entidade, existir de fato umageneralizao/especializao.

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

que teremos entidades diversas com nomes distintos, mas que na realidade podem sergeneralizadas 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 dasentidades 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.

5.1 - A Existncia

O entendimento sobre o que so efetivamente relacionamentos e a capacidadede enxergar estes objetos, como participantes do mundo real, so fatores primordiais

para que se venha a efetuar trabalhos de modelagem de dados com compreenso doque 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 derepresentar as coisas que existem e ocorrem no mundo real. Procurando, sempre,retratar com simplicidade os fatos, isso os levar a representar com correo eentendimento.

Temos sentido nas diversas turmas de cursos que ministramos, um certo graude dificuldade dos alunos em compreender corretamente relacionamentos, fato queleva a dedicar este captulo para o perfeito entendimento do tema e sua utilizao.

Dentro deste enfoque definimos RELACIONAMENTO como o fato, oacontecimento que liga dois objetos, duas "coisas" existentes no mundo real.

Considerando que estamos nos orientando para aplicaes que serodesenvolvidas 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.


30/156

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 denegcio.

Para um retrato dos objetos e fatos de um problema, os relacionamentos so oselementos que nos do o sentido da existncia destes objetos e suas inter-relaes, semas quais ficaria de extrema complexidade o entendimento e a compreenso do domniodo 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

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, contaruma histria sem utilizar VERBOS em seu vocabulrio?

E impossvel nos fazermos entender, em qualquer situao, sem utilizarmosverbos, sem explicarmos o relacionamento entre as "coisas" sobre s quais nosreferimos.

Na figura 5.2 com os mesmos objetos, apenas com a incluso de um verboentre eles, passamos a contar com um contexto de mais expressividade. l podemosdizer que temos maior domnio (conhecimento) do ambiente.

A colocao do verbo, ou seja, do Relacionamento, deu semntica ao todo, ascoisas j fazem sentido, no esto mais soltas, j existe um fato entre os objetosrealizando uma ligao.

VERBO = A EXPRESSO DE UM FATO

No mundo que nos cerca, tanto em nossas atividades profissionais como nasatividade pessoais, convivemos com os mais variados tipos de entidades (objetosreais), que como j vimos, so descritos por uma srie de atributos, e que expressamuma realidade de existncia.

Estas entidades do dia-a-dia no esto soltas, desligadas umas das outras, esim relacionadas de forma a mostrar a realidade com um contedo lgico.

Diariamente relatamos coisas do mundo real, e quando o fazemos estamos naverdade 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 simplesolhar para a figura 5.3 nos d uma viso clara dos objetos, existentes no


31/156

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

HOMEM MULHERPEDROLUSSRGIOCLVIS

MARCELOCELSOCARLOS

SILVIACARLAANTNIAANDREIA

CRISTINAMARIAANA LCIAANA PAULAANA FLVIA

Figura 53 - Fatos de uma Realidade.

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

compreenso de contextos atravs dos dados.

Mas o importante construir sistemas de aplicao com a certeza de quesabemos para que os construmos e com completo domnio do negcio para o qual osistema foi projetado. Um sistema sempre projetado para que venha a resolver umdeterminado problema de um negcio.

Este negcio, possui, seguramente, um grupo de objetos que representa osinteresses da organizao. Vamos detalhar ento, como estes objetos se relacionam ede que formas estes relacionamentos existem no mundo real.

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

Figura 5.4

Um Homem pode estar casado com duas ou mais mulheres ?

Depende do pas onde estaremos realizando o projeto do sistema. Todas as mulheres so casadas?

Todos os Homens so casados ?

Se estivermos retratando a realidade, as respostas s perguntas "Todos"evidentemente "No". Mas ento como vamos entender a existncia derelacionamentos, se existem elementos que no fazem parte, ocorrncias das entidadesque no esto se relacionando?

A questo das duas ou mais mulheres, iremos analisar quando tratarmos decardinalidade 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 dehomens no serem casados no elimina a existncia do rato, do evento casamento,existindo homens casados e no casados em uma mesma entidade, sendo inclusive aparticipao no relacionamento (evento Casado), uma qualificao de um conjunto daentidade Homens.

Isto nos leva a dois grandes grupos de Relacionamento:

a) Relacionamentos Condicionais - relacionamentos que possuem umacondio, uma qualificao para ocorrerem, e;

b) Relacionamentos Incondicionais - no possuem esta condio,caracterizam-se por serem obrigatrios.

48

5.3 - Relacionamentos Condicionais

Estes dois grupos de relacionamentos possuem cada um, vrios graus derelacionamentos, que iremos estudar neste livro detalhadamente.


32/156

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

5.4 - Relacionamentos IncondicionaisTodos os elementos de uma entidade esto obrigatoriamente

relacionados com um elemento, no mnimo, da outra entidade.

Neste caso, existe a obrigatoriedade do relacionamento entre todos oselementos de uma entidade com os elementos de outra.

Por exemplo, vejamos a figura 5.5 a seguir:

, q

Agora neste ponto j conhecemos os dois elementos bsicos do modeloEntidade Relacionamento, vamos ver ento qual a forma de representao grficado relacionamento, utilizada por Deter Chen, para que o modelo E-R mantivesse umgrau de semntica que espelhasse efetivamente o mundo real.

Os relacionamento so representados por um losango entre as entidades e comarestas ligando as entidades a este losango. No interior do losango, inserimos umverbo que explicite o fato (o evento) que o relacionamento (figura 5.6).

Figura 5.5

Toda ocorrncia de me est relacionada a um ou mais filhos e; Toda aocorrncia de Filho est obrigatoriamente ligada a uma ocorrncia de me.

Neste caso, no poderamos ter em nenhuma hiptese, a possibilidade deexistir na entidade filhos ocorrncias que no estivessem ligadas a uma ocorrncia daentidade me. E no sentido inverso tambm no poderamos ter uma ocorrncia emme que no estivesse ligada a um ou mais filhos, pois se permitssemos, estaramosdistorcendo 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 relacionamentoIncondicional, pois obrigatrio para todos os elementos de me e todos os elementosde 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 ViagemMas voltemos ao nosso dia-a-dia, e vamos preparar as malas para uma viagem

ao Caribe (quem sabe um dia!!).


33/156

Projeto de Banco de Dados Relacionamentos

Temos em casa um jogo de malas com tamanhos, cores e de materiaisdiferentes, 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 atributosque as caracterizam e individualizam, e da mesma forma iremos proceder com sapatose produtos de higiene.

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

SAPATO

PRODUTO DE HIGIENE

Vamos entender quais so os seus atributos bsicos.

Existem casos em que as pessoas vo lembrar o que perderam ao extraviarem-se suas malas, muitos meses depois.

Logo, temos de criar relacionamentos entre as entidades envolvidas naviagem, 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 iremosfazer um modelo E-R, que ir representar com a mesma simplicidade da vida realeste relacionamento (figura 5.7).

SAPATO

ENTIDADE: ATRIBUTOS

Mala CorVolume Material

Indicador de rodasTipo de fechamento

Roupa Cor da roupa Material(tecido) Descrio daroupa

Sapato CorTipo (Esporte/Social)Marca

Produto de higiene

e BelezaNome

Marca

Se por acaso "um acidente de percurso" acontecer, e uma mala for extraviadaou perdida no trajeto Rio-Miami, e, se no houvesse uma forma de relacionar ascoisas, como iremos saber o que estaria faltando de roupas, sapatos e produtos dehigiene.

RELACIONAMENTO

ContmColocado na

Est na

figura 5.7

LIGA

Roupa com MalaSapato com Mala

Produto de Higiene com Mala

MALA

ROUPA

PRODUTO DE HIGIENE

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 enxergarem um diagrama de Entidades e Relacionamentos, os fatos que esto ali retratados,com a mesma simplicidade com que estes acontecem no mundo

Relacionamentos


34/156

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 esimples da realidade dos fatos (figura 5.8).

Figura 5.8

5.6 - Grau do Relacionamento

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.

Quando questionamos anteriormente se um homem poderia estar casado commais de uma mulher, estvamos na realidade questionando o grau de relacionamentoque existia entre as entidade Homem e Mulher.

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

ou seja, trs graus de relacionamento, que so:

5.6.1 - Relacionamento de Um-para-UmNeste 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 Homemrelaciona-se com uma, e somente uma, ocorrncia da entidade Mulher, pois ocasamento no Brasil ainda monogmico (figura 5.9).

Figura 5.9 - Relacionamento um-para-um.

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

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 qualqueroutro elemento da entidade 2, que no o existente com Y.

importante salientar que lemos o diagrama somente em um sentido, e istoest incorreto dentro do conceito de relacionamento, pois os mesmos no sounidirecionais.

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 estcasado somente com uma mulher e uma mulher est casada somente com um homem.

Muitos dos erros na construo de modelo de dados ocorrem por seremrealizados exames apressados sobre a cardinalidade dos relacionamento, efetuando-sea anlise somente no sentido de um interesse especfico do negcio, sem que severifique a cardinalidade no sentido inverso.

SENTIDO DE LEITURA

IDNTICO RESULTADO = 1:1


35/156

Relacionamentos

5.6.2 - Relacionamento de Um-para-Muitos

Este grau de relacionamento o mais comum no mundo real, sendo o quedenominamos de relacionamento bsico entre entidades, entretanto possuicaractersticas 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 daentidade 1.

Ou seja, o grau de cardinalidade determinante sempre o maior grau obtido dainterpretao dos fatos.

Para ilustrarmos inicialmente este relacionamento, vamos nos deslocarat algum dos pases rabes.

RESULTADO = 1:NFigura 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.

Devemos ter como regra geral ento, que um relacionamento do tipo um-para-Muitos, quando um sentido de leitura dos fatos nos apresenta este grau de Um-para-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:

Figura 5.11 - Relacionamento muito-para-muitos.

Um estudante cursa vrias (muitas) disciplinas, mas alguns estudantestemporariamente podem estar cursando somente uma, ou nenhumadisciplina.

Uma disciplina cursada por vrios (muitos) estudantes, mas

eventualmente podemos ter uma disciplina que no possua nenhumestudante cursando-a, ou somente um. Neste caso, por haveropcionalidades, caracteriza um relacionamento condicional.


36/156


37/156

ENTIDADE ATRIBUTOS

Item de Nota

FiscalNmero da Nota Fiscal

Cdigo de Identificao doProdutoQuantidade do Produto na Nota

Item de Estoque Cdigo de Identificao doProdutoDescrio do ProdutoQuantidade em EstoqueValor Unitrio do Produto

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

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 suainterpretao retrata a realidade dos dados com sua dinmica.

Quando estamos analisando o contexto de administrao de estoques, muitasvezes a preocupao com os procedimentos nos leva a seguinte observao:

Quando enviamos uma nota fiscal, estamos tambm remetendo os tens destanota 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 nanota fiscal, da quantidade em estoque do produto.

Muitas vezes temos encontrado modelos que embutem o procedimento no

modelo como se ele fosse um relacionamento.

Ento apareceria Item de Nota Fiscal Baixa Item de Estoque. Mas se ospermitirmos usar um verbo to indicador de procedimentos no modelo, reguramenteiremos cometer uma srie de desvios que levar o modelo a ser concebido sob umaorientao de procedimentos, que levar, por sua vez, construo de uma base dedados instvel.

Figura5.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 dafigura 5.13 que simplifica o entendimento:

5.7.2 - Como Testar se um Relacionamento Realmente Existe

Isto na realidade uma tarefa, relativamente, complexa quando no temos deimediato uma estrutura de dados com informaes comuns no primeiro instante denossa anlise.

Relacionamentos em um modelo podem surgir em funo das exigncias enecessidades de recuperao de informaes por parte do usurio.

Figura5.14

Seja o modelo Departamento Lota Funcionrios e Departamento TemEscritrios, da figura 5.14.


38/156

Departamento lota 1 ou mais funcionrios e um funcionrio est lotado emum e somente um departamento.

Um departamento possui 1 ou mais escritrios.

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

Entidade: Atributos:

Departamento Cdigo do DepartamentoNome do DepartamentoVerba do Departamento

Funcionrio Cdigo do FuncionrioNome do Funcionrio

Data de AdmissoEscritrio Nmero do Escritrio

rea do Escritrio

Esta estrutura de dicionrio possui os campos necessrios descrio de cadauma das entidades. Mas como efetivarmos o relacionamento?

Olhando a figura do E-R apresentada, vamos trabalhar o primeiro

relacionamento, entre Departamento e Funcionrio.

Um Departamento tem Lotados muitos Funcionrios;

Um Funcionrio est Lotado somente em um Departamento.

Sendo que se encontrarmos dois graus de relacionamento conforme o sentidode 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 nestaentidade.

Este o conceito de chave estrangeira: um dado colocado em uma entidadeque em outra o identificador unvoco (chave primaria).

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

A certido de nascimento das pessoas que t filhos,possui o nome dos filhos?

E bvio que no. a certido de nascimento dosfilhos que possui o nome dos pais.

Resumindo, dependentes indicam de quedependem.

RELACIONAMENTOS

Cdigo do Funcionrio Nome doFuncionrio Data de Admisso

Cdigo do Departamento

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

Vejamos ento o diagrama de instncias deste modelo de dados:

E importante sempre lembrar, que este campo utilizado como chaveestrangeira, dever ser na entidade referenciada (lado Um) correspondente ChavePrimria desta.

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

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

Funcionrio Com Departamento 1:1(Lotado)


39/156


40/156

Figura 5.15

6.1 - A Expresso do RelacionamentoApresentamos at este ponto a necessidade de incluirmos campos na estrutura

de dados das entidades para que se efetuem os relacionamentos, ou seja, existemcampos comuns para a ligao.

Quando um campo em uma entidade caracteriza-se por ser a chave deidentificao nica de ocorrncias desta entidade, denomina-se, como j vimos, ChavePrimria.

Quando em uma entidade temos um campo que chave primria de outraentidade, denomina-se Chave Estrangeira.

Esta ligao realiza-se por comparao do valor da Chave estrangeira de umatalula com o valor da Chave Primria de outra tabela.

Se temos um Funcionrio Joo e um Departamento Contabilidade, estesobjetos 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 Departamentoda 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:


41/156


42/156


43/156

Figura 6.2

Que existem ocorrncias de Funcionrio que no esto alocados a nenhumprojeto fato concreto, mas como podemos visualizar este fato?

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.

Tomarmos como regra geral, que sempre que existir um relacionamento comcardinalidade de Um-para-Muitos, a referncia lgica (chave estrangeira), estar

colocada na entidade que possui o lado Muitos da cardinalidade.

Em nosso exemplo, a ligao da entidade Funcionrio com a entidade Projetoser possvel de se efetuar atravs da insero do atributo Cdigo_do_Projeto (ChavePrimria de Projeto) na entidade Funcionrio.

E como devemos entender a opcionalidade do relacionamento com relao aosvalores dos atributos?

Para as ocorrncias da entidade Funcionrio que no estiverem relacionadas

com nenhuma ocorrncia de Projeto, o atributo tambm existir porm, o valor desteatributo ser NULO, isto , uma informao desconhecida, inexistente.

6.3 - Valor NuloO 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 oupacotes fechados que denominaremos de Compras.

QUAL O CONTEDO?

Para ns que estamos ali parados, olhando a movimentao, qual o valor docontedo daquelas sacolas e pacotes? Nulo.

Ora, todos iro concordar que desconhecido, ou seja, Nulo, porque nosabemos o que existe dentro das sacolas e pacotes.

Ento Nula a informao desconhecida, o dado no informado. Em Bancode 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 Funcionriorelacionada?

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 entidadefuncionrio.

A observao do diagrama Entidade-Relacionamento e dos atributos de cadaobjeto pode no ser suficiente para voc leitor, adquirir a viso espacial dos dados.


44/156

Como o nmero de ocorrncias do relacionamento indeterminado no l i Al d d i l l d Cdi d j


45/156

Como o nmero de ocorrncias do relacionamento indeterminado, nopodemos mant-lo como atributo de Funcionrio, pois no saberamos quantasocorrncias colocar destes atributos em Funcionrio, sendo necessrio odesdobramento.

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 assimdelineadas:

relacionamento Alocado deve ser igual ao valor do campo Cdigo_do_Projeto naentidade Projeto, conjuntamente.

Quando isto acontecer com uma ocorrncia de Funcionrio, uma ocorrncia deAlocado 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 querepresentam esta realidade.

Entidades: Atributos:

Funcionrio Matrcula_FuncionrioNome_FuncionrioCdigo_ProjetoProjeto

Nome_Projeto

Relacionamento: Atributos:

Alocado Matrcula_FuncionrioCdigo_ProjetoData_Incio_no_ProjetoTempo_de_Alocao

6.4 - Como se Efetiva este Relacionamento?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 agoracom uma caracterstica diferente: a comparao realizada entre campos das entidadese campos do relacionamento, formando uma expresso composta.

Expresso de Relacionamento:

Funcionrio.Matrcula-funcionrio = Alocado.Matrcula-Funcionrio e Alocado.cdigo-projeto = Projeto.cdigo-projeto.

Esta expresso quer nos dizer que o valor do campo matrcula na entidadeFuncionrio deve ser igual ao valor do campo matrcula no relacionamento Alocado, eque o valor do campo Cdigo_do_Projeto no

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

P-18 Projeto Phoenix

P-25 Projeto Minerva

P-32 Projeto Corrup (Cruzes!!)

P-55 Projeto Nova Ponte

P-203 Oramento 95

Vamos ento simular relacionamentos Muitos-para-Muitos com estas duastabelas de ocorrncias das entidades, criando o relacionamento Alocado, e suas

possveis ocorrncias.

j i d


46/156

ALOCADO:

MatrculaFuncionrio

Cdigo_do_Projeto Data_Incio_no_Projeto

Tempo_de_Alocaono_Projeto

1466 P-18 24/05/90 24 MESES1466 P-25 12/11/91 06 MESES

1466 P-32 02/01/92 12 MESES

7712 P-18 10/06/91 04 MESES

7712 P-79 12/12/91 12 MESES

4415 P-18 15/01/92 03 MESES

1216 P-25 01/03/92 05 MESES

Vamos interpretar o mundo real, atravs da tabela de ocorrncias dorelacionamento Alocado:

A ocorrncia de Funcionrio com matrcula 1466 est alocada a trs (03)Projetos, respectivamente P-18, P-25 e P-32, isto , Um FuncionrioAlocado a Muitos Projetos;

A ocorrncia de Funcionrio com matrcula 7712 est tambm alocada amuitos projetos (dois);

J as ocorrncias de funcionrio de matrcula 4415 e a de matrcula 1216esto cada uma alocada a somente um projeto, pois s constam uma vezdentro do relacionamento com campos Alocados.

Novamente lembramos que o fato de existirem ocorrncias relacionando-secom a cardinalidade Um-para-Um no invalida a cardinalidade bsica dorelacionamento, uma vez que possumos ocorrncias que realizam a cardinalidadeMuitos-para-Muitos.

sempre muito importante que se efetue a leitura do modelo de dados em doissentidos, para compreenso perfeita da realidade. Ento vamos agora analisar asituao por outro sentido de leitura do relacionamento:

O projeto de cdigo P-18 possui Muitas ocorrncias de Funcionrio a elealocadas, ou seja, respectivamente 1466, 7712 e 4415;

Assim como o projeto de cdigo P-25 possui tambm muitas ocorrncias deFuncionrio a ele relacionadas (1466 e 1216);

J os projetos P-32 e P-79 possuem somente uma ocorrncia dFuncionrio a eles relacionada.

Observem que interpretamos, ou melhor, realizamos a leitura pura simplesda tabela que representa este relacionamento, no considerando ainda neste instante,as ocorrncias das duas entidades que no figuram n relacionamento. Estasocorrncias so irrelevantes para a interpretao d Relacionamento.

Observem o diagrama da figura 6.4, para que se estabelea uma regra formalpara determinao de um relacionamento Muitos-para-Muitos.

Figura 6.4


47/156

7.1 - Relacionamentos entre Mltiplas Entidades

At o momento, neste livro, estudamos e analisamos situaes em que asentidades se relacionavam aos pares. Este o princpio de descoberta dosrelacionamentos na construo de um modelo de dados: analisar as entidades aos

pares.

Entretanto um relacionamento pode existir envolvendo mais de duasentidades, que podem ser trs, quatro, ou uma quantidade indeterminada de entidadesque o fato do relacionamento envolve.

Os relacionamentos entre mltiplas entidades expressam um fato em que todasas entidades ocorrem simultaneamente, ou seja, todas as ocorrncias dorelacionamento possuem, sempre, ligaes com todas as entidades envolvidas norelacionamento. No pode existir de um relacionamento triplo, em um determinadomomento, 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


48/156

Para podermos descobrir as cardinalidades do relacionamento ternrio dafigura 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 NALUNOS relacionados;

Separar a entidade PROFESSOR e analisar o par ALUNO, DISCIPLINA.Para cada par ALUNO / DISCIPLINA podemos ter 1 e somente 1PROFESSOR relacionado;

Separar a entidade DISCIPLINA e analisar o par PROFESSOR, ALUNO.Para cada par PROFESSOR / ALUNO podemos ter de 1 at NDISCIPLINAS relacionadas.

Relacionamento mltiplo com mais de quatro entidades relacionadas extremamente difcil de se encontrar na realidade do dia a dia. Quando voc encontrarcom algum fato que d origem a um relacionamento mltiplo, analise com cuidado,

pois o mesmo pode ser desmembrado em mais de um relacionamento. Aimplementao de relacionamento mltiplo em bancos de dados torna o trabalho demanipulao 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 umprofessor;

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 relacionamentotambm de muitos.

Vamos analisar o diagrama de instncias deste relacionamento (figura 7.3), paraque se possa melhor entend-lo, e aps construir as tabelas com daos para as entidadese os relacionamentos.

Vamos observar as tabelas que simulam estes objetos do


49/156

Figura 73

Colocamos no diagrama de instncias, ocorrncias em cada uma das entidadesenvolvidas que no esto participando do relacionamento.

A interpretao correta deste tipo de relacionamento nos apresenta um ponto

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

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

relacionamento:

ENTIDADE: ATRIBUTOS: CONEXES:

ALUNO Nmero_do_Aluno

Nome_do_Aluno Datada Matrcula

Com CURSAM 1:N Parcial

DISCIPLINA Cdigo_DisciplinaNome Disciplina


PROFESSOR Cdigo_ProfessorNome Professor


Cursam Nmero_do_AlunoCdigo_ProfessorCdigo_Disciplina

com Aluno N:l comProfessor N:l comDisciplina N:l

Vamos observar as tabelas que simulam estes objetos dorelacionamento ternrio:

Professor (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_daDisciplina

Cdigo_daDisciplina

Nome_Disciplina

14 120 D24 D24 Matemtica I

14 123 D24 D55 Fsica Aplicada

14 122 D24 D66 Laboratrio Fsica II

11 200 D27 D99 E. P. Brasileiros II11 122 D27 D27 CobolI(Uuhgh)

66 120 D99

66 123 D99

45 120 D66

Observando a tabela de dados do relacionamento Cursam, podemos ver queexistem 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 cadaentidade.

No entanto podemos observar que sempre que existe uma ocorrncia norelacionamento, esta apresenta referncia s trs entidades, no existindo, Porexemplo, nenhuma ocorrncia somente com professor e disciplina.

Aluno (Entidade)


50/156


51/156


52/156

Quando estamos realizando o Projeto Fsico de Banco de Dados, m surgirsituaes em que iremos efetivamente colocar uma vertical da entidade, mas porum motivo nada conceituai. Objetivo de uma decomposio desta ordem poderiaser, por exemplo: a de concentrao de acessos entidade Produto, sendo quenem todos acessos estejam interessados em recuperar o dado quantidade em que.

Os relacionamentos Um-para-Um podem ser utilizados quando estivermoscom entidades complementares de outra, como nos casos de generalizao dedados.

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

Como modelagem de dados, antes de ser uma tcnica tambm uma poisreflete a interpretao de um ser humano da realidade que o cerca, podemos teruma 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 (narealidade) Muitos-para-Muitos.

Vamos utilizar para esta anlise a figura 7.6.

Figura 7.6

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

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 dositens que constam em uma nota fiscal. Vejamos ento as estruturas de dados quetemos no exemplo:

ENTIDADE ATRIBUTO RELACIONAMENTOS

Nota Fiscal Nmero_da_Nota_FiscalCdigo_do_Cliente_da_Not aData_da_Nota

Com Item de Nota Fiscal 1:N total(todas as notas tm no mnimo umitem de nota fiscal

relacionado)Item de Nota Fiscal Nmero_da_Nota_FiscalCdigo_do_ProdutoQuantidade_Produto

Com Nota Fiscal 1:1 total(todo item de Nota Fiscal estrelacionado a uma Nota Fiscal)Com Produto 1:1 total(todo item de Nota Fiscal estrelacionado a um Produto)

Produto Cdigo_ProdutoDescrio_ProdutoUnidade_Produto

Preo_Unitrio_ProdutoQuantidade_Estoque_Produto

Com Item de Nota Fiscal 1:NParcial


53/156

gregao


54/156

8.1 - A Decomposio de um RelacionamentoExistem 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, noexistem relacionamentos entre relacionamentos. uma inverdade conceitual. O queexiste no mundo real, so relacionamentos

Vamos iniciar nosso estudo com um caso policial como seestivssemos 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 criminosoassassinou vrias vitimas e que uma vitima foi assassinada por vrios criminosos j queno

frente a frente com um relacionamento de Muitos-para-Muitos. j participaram do fatoEstamos

Figura 8.1

O diagrama da figura 8.1 apresenta um impasse: temos a entidade Meliante, ea entidade Vtima, relacionadas com cardinalidade Muitos-para-Muitos. Aparece ento

So na realidade dois relacionamentos para retratar um fatocompleto.


55/156

, p pem cena uma terceira entidade, denominada de Arma, que contm as armasapreendidas. Como iremos ligar as ocorrncias de Arma, ao fato, ao evento doAssassinato, este relacionamento com campos?

A entidade Arma est com suas ocorrncias relacionadas a Meliante, ou estrelacionada a Vtima?

Se ligarmos Arma a Meliante, no podemos afirmar que ela foi utilizada noassassinato de uma Vtima. Se ligarmos Vtima, mais difcil torna-se estabelecermosuma relao com o Assassino.

Como resolver esta questo?

relativamente simples esta soluo, basta que nos detenhamos em retratar arealidade da mesma forma como ela expressa em linguagem natural, ou seja:

Um Meliante Assassina Vtimas. Quando ele Assassina Vtimas, UsaArmas. Esta realidade apresentada graficamente (modelo E -R) na figura8.2.

Figura 82

Existem, nesta expresso da realidade, dois verbos inter-relacionados, ou seja,existe um relacionamento entre objetos dependentes um da existncia de outro.

completo.

O que desejamos relacionar uma ocorrncia de Arma, com I ocorrnciado 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 vriasocorrncias da entidade Arma, criando um relacionam entre Assassina e Arma,que denominamos de Usa.

A figura 8.3, mostra a representao da agregao relacionadaArma.

Figura 83

Interpretando o diagrama Entidade-Relacionamento, temos enxergaro conjunto resultante de Meliante Assassina Vtima, relacionado c o conjunto dasocorrncias da entidade Arma. Na realidade, estamos lei este conjunto resultante

como se ele mesmo fosse uma entidade.

Quando deixamos de lado um pouco o conceito entidade, podemosinterpretar como o objeto Assassinato (Meliante Assassina Vtima relacionado comArma.

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 DOCUMENTO NOME SEXO IDADE


56/156

ENTIDADE ATRIBUTOS RELACIONAMENTO

MELIANTE Registro do MelianteNome OficialCodinome Idade

Com Vtima atravs de Assassina1:N (Parcial)(Nem todo Meliante assassinou umaVtima)

VITIMA Num. documento da vtimaNome do infelizSexoIdade

Com Meliante atravs de Assassina1:N (Total)(Toda Vtima foi assassinada por umMeliante)

ARMA Num. Apreenso da ArmaMarca da arma Tipo da arma

Nmero de srie

Com Assassina atravs de Usa 1:N(Parcial)(Nem toda arma apreendida foi usada numassassinato)

111111111 Antnio Moacir M 58

243387569 Jlio A. Macedo M 35

806578913 Sazaina Moraeis F 24

684714325 Ana Luiza Martins F 32

ARMA

NMERO MARCA TIPO SRIE

191 Taurus Pistola A656B767

192 Magnus Pistola Mg457T8V9

RELACIONAMENTO ATRIBUTOS CONEXES

ASSASSINA Data do crimeNum. documento da VtimaRegistro do Meliante

Com Meliante N:l (Total)Com Vtima N:l (Total)

USA Num. documento da VtimaRegistro do Meliante Num deapreenso da arma

Com Assassina N:l (Total)Com Arma N:l (Total)

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

As tabelas apresentadas a seguir mostram apenas uma parte dorelacionamentos possveis para as ocorrncias das entidades Meliante Vtima,considerando-se que, os casos que no esto relacionados, no foram at esta ediosolucionados.

ASSASSINA

DATA VTIMA MELIANTE

11/02/92 111111111 121212

14/03/92 243387569 121212

03/04/92 806578913 334455

USA

MELIANTE

REGISTRO NOME CODINOME IDADE

121212 Joo Pedrum Jo Caveira 33

221134 Luiz Cabrum L Vampiro 42

334455 Carlos S Cadinhos Mau 18

212378 Srgio Bruks Balaustre 26

335588 Tonho Silva Tonho Faco 19

VTIMA MELIANTE ARMA

111111111 121212 191111111111 121212 192

O fato de um crime associar duas armas ao mesmo meliante, um exercciode imaginao, mas que nos permite observar que a agregao admite que se tenhauma cardinalidade de Muitos-para-Muitos entre o objeto resultante do relacionamentoentre Meliante e Vtima com a entidade Arma.

QC

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

Diferentemente do caso anterior onde uma Arma era usada por I criminososomente em Assassinato agora temos a colocao de que uma mquina pode estar


57/156

p

8.2 - Agregao e CardinalidadeSeja a situao de relacionamento Muitos-para-Muitos que havamos estudado

quando da anlise deste tipo de relacionamento, entre a entidade Funcionrio e aentidade Projeto.

Figura 8.4

Um Funcionrio Atua em muitos Projetos e, um Projeto tem trabalhando nelemuitos Funcionrios, conforme o diagrama E-R da figura8.4.

Quando um Funcionrio est trabalhando em um Projeto, ele pode Utilizaruma ou nenhuma Mquina para a realizao de suas atividades.

Novamente temos uma situao de um evento decorrente de outro, e aindacom uma caracterstica adicional, que a opcionalidade do segundo evento acontecer.

A viso agregada de Funcionrio Alocado Projeto, permite-nos tratar estebloco de modelo, como sendo uma entidade consolidada por um fato, mas vejam bemque estamos considerando um bloco, e que este bloco ento relaciona-se comMquina, opcionalmente.

somente em Assassinato, agora temos a colocao de que uma mquina pode estarsendo utilizada por diversos funcionrios atuando em projetos

Como devemos tratar esta situao?

Lendo, a situao fica mais simples, seno vejamos: um FuncionrioAtuando em Um Projeto caracteriza uma ocorrncia de Alocado e e ocorrnciautiliza uma ou nenhuma Mquina, por outro lado uma Mquina pode ser utilizadapor "n" Funcionrios atuando em Projeto.

Temos ento um relacionamento de um-para-muitos entre Mquinas a visode Funcionrio Alocado Projeto.

Como existe uma cardinalidade de Um-patra-Muitos I relacionamentoUtiliza, este no ser um relacionamento com campos, sendo realizado pelaexecuo de uma expresso de comparao lgica.

Vamos ento observar as estruturas do dicionrio de dados para melhorcompreendermos as ligaes lgicas e como se realizam.

DICIONRIO DE DADOS:

ENTIDADE ATRIBUTOS RELACIONAMENTO

FUNCIONRIO Matrcula FuncionrioNome Funcionrio DataAdmisso

Com Projeto atravs de Atual 1:N(Parcial)

PROJETO Cdigo ProjetoNome ProjetoVerba Projeto

Com Funcionrio atravs de Atua 1:N(Parcial)

MQUINA Cdigo MquinaNome Mquina

Com Atua atravs de Utiliza 1:N(Parcial)

RELACIONAMENTO ATRIBUTOS CONEXES RELACIONAMENTODO BLOCOAGREGADO

Cdigo_ProjetoMatrcula_FuncCd_Mquina

Com Projeto N:l(Total)Com FuncionrioN:l (Total)

Com mquina atravsde utiliza N:l (Parcial

Agregao


58/156

RELACIONAMENTO ATRIBUTOS CONEXES RELACIONAMENTODO BLOCO

AGREGADO

UTILIZA Com Alocado N: 1Com Mquina 1:1

Este caso de agregao apresenta da mesma forma uma decomposio de umrelacionamento em dois, pois ao analisarmos a situao, encontraremos sempre doisfatos, dois eventos acontecendo, sendo um dependente de outro.

Funcionrio Utiliza Mquina, "quando" Alocado a Projeto. Este tipo detemporalidade representado pela palavra "quando" que nos d a pista, o caminhocorreto para a soluo do caso.

Sempre que nos depararmos com um relacionamento envolvendo mais de duasentidades, devemos questionar as entidades que se ligam em um relacionamentobsico, atravs da colocao da questo:

Quando acontece o fato?

Vamos ento conhecer um outro caso de agregao, agora j visualizando umatemporalidade, e executando o questionamento temporal que discutimos.

Seja ento a seguinte situao:

Um mdico atende a muitos pacientes, que o consultam, e um paciente poderealizar consultas com muitos mdicos. Sempre que um paciente consulta um mdico,este fornece uma receita, que pode ter um, ou vrios remdios.

Figura 8.5I

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-seagora 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 aentidade Mdico e a entidade Paciente, que possui cardinalidade de Muitos-para-Muitos.

Vamos observar ento como fica a construo do dicionrio de dados para esteexemplo em pauta.

Observem, leitores, que agora neste caso temos trs entidades se doisrelacionamentos com campos, para solucionar o problema.

DICIONRIO DE DADOS:

ENTIDADE ATRIBUTOS RELACIONAMENTOS


59/156

MDICO Cdigo MdicoNome Mdico

Com Paciente atravs de Consulta 1:N(Parcial)

PACIENTE Nmero PacienteNome Paciente

Com Mdico atravs de Consulta 1:NParcial

REMDIO Cdigo RemdioNome Remdio

Com Consulta atravs de Receita 1:N(Parcial)

RELACIONAMENTO ATRIBUTOS CONEXES

ATENDE Cdigo Mdico

Nmero PacienteData Consulta

Com Mdico N:l Com

Paciente N:l Com Remdioatravs de Receita 1:N

RECEITA Cdigo RemdioCdigo MdicoNmero PacientePosologia Remdio

Com Remdio N:lCom Consulta N:l

8.3 - Restries para Uso de AgregaoQueremos 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 Muitos-para-Muitos, que representa um fato, pois caso contrrio a terceira entidadeenvolvida estar relacionada sempre com uma das entidades em questo (figura 8.6).

Para melhor exemplificar, e permitir a compreenso desta restrio vamosconsiderar que o relacionamento entre Funcionrio e Projeto, estudado

anteriormente, tivesse uma cardinalidade de Um-para-Muitos, ou seja, Um Projetotem muitos Funcionrios, mas um Funcionrio trabalha somente em um Projeto.

Ora, se o funcionrio s trabalha em um Projeto, a mquina ou a mquinasque ele utiliza esto relacionadas diretamente a ele, uma vez que ele s possui umaexistncia de relacionamento com projeto.

Sempre que tivermos relacionamentos de cardinalidade Um-para-Muitos, aterceira entidade est relacionada com uma das duas (Figura 8.7).

ERRADO


60/156

permitindo que se desenhe um esquema conceituai mais coerente com realidade donegcio para o qual desenhamos um sistema.


61/156

Figura 8.9

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

Proposital mente escrevemos a leitura do modelo em sua ordem inversa, paraque se possa destacar que este tipo de converso de modelo provoca sempre

cacofonismos semnticos, mas o modelo continua expressando uma realidade. Vamosefetivar 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 muitosemntico, isto verdade, no fica mesmo.

O importante que se voc, leitor, utiliza um banco de dados que permite estetipo de implementao (agregao e Muitos-para-Muitos), no deixe de utilizar, j queem projetos de grande complexidade e volume de entidades e relacionamentos, omodelo ficar extremamente sujo em termos de semntica para expressar umarealidade. O ideal seria que todos os bancos de dados fossem construdos para permitiresta implementao conceituai,

8.5 - Relacionamentos entre Blocos do ModeloJ vimos at aqui que uma agregao de dados pode relacionar-se com outras

entidades, mas existe ainda a possibilidade de realizarmos relacionamentos dequalquer grau entre dois blocos de agregao existente no modelo de dados.

Acreditem, os autores deste livro no enlouqueceram no Simplesmenteestamos 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 aforma como ele expresso em linguagem natural, aquela que utilizamos quando noestamos preocupados com Programas Mquinas e Softwares.

Vamos estudar ento esta extenso da utilizao de agregaes em ummodelo de dados.

FATO l

Figura 8.10

A figura 8.10 apresenta dois blocos distintos com relacionamentos Muitos-para-Muitos em cada um, expressando dois fatos do mundo real.

O fato nmero 1 retrata uma situao que j estudamos, em que um mdicoatende a muitos pacientes, e um paciente faz consultas com muitos mdicos.

O fato nmero 2, aparentemente dissociado, representa uma Clnica Atua emmuitos Locais, sendo que em um Local Atuam muitas Clnicas.

Como as consultas mdicas no so realizadas no espao, deve ser possvelassociarmos o fato da Consulta a uma Localizao deste acontecimento.

Esta mesma situao pode, como j afirmamos, ser implementada comdesdobramento dos relacionamentos Muitos-para-Muitos em entidades associativas,


62/156

A questo , quais as consultas realizadas pela ocorrncia X de Clnica noLocal Y?

Podemos querer saber, por outro lado, em que Local e Clnica foi realizadauma determinada consulta.

Isto nos conduz a afirmar que os dois blocos do modelo de dados no estorealmente dissociados, que esto profundamente relacionados. Ento o que nos falta representar a associao dos dois fatos.

p ,apesar de perder grande parte da simplicidade semntica desta soluo.

Figura 8.12

A figura 8.12 apresenta o mesmo caso que estudamos, representado atravs dautilizao de entidades associativas.

Um detalhe importante e que muitos projetistas esquecem, ou fingem

esquecer, que a fidelidade semntica dos dados e relacionamentos deve sempre sermantida, procurando-se dar nomenclaturas s entidades e relacionamentos queexpressem um sentido, evitando-se de todas as formas, a utilizao de siglas, tantopara entidades quanto para relacionamentos, que impeam a leitura simples e naturalde um diagrama de Entidades e Relacionamentos.

A figura 8.11 nos apresenta a soluo, com o relacionamento existindo entre asduas agregaes, atravs de Realiza.

Temos ento um relacionamento com cardinalidade de Um-para-Muitos entrea 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 LocalRealiza muitas Consultas, isto , Mdico Atende Paciente.

uto- e ac onamento


63/156

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 doscomentrios mais ouvidos, visto que no somos psiclogos e nem pretendemos, deque para se estar de bem com a Vida, devemos em primeiro lugar, estar de bem comns mesmos. Devemos nos auto-relacionar muito bem, gostar de si mesmo, antes detudo, para poder encarar a Vida de frente.

Estas afirmativas apresentam um auto-relacionamento de ns seres humanoscom ns mesmos, isto auto-relacionar-se.

Em nosso estudo, at certo ponto bem mais simples de entender o auto-relacionamento, pois em uma classe de objetos, eles se relacionam entre si.

Em uma entidade, suas ocorrncias possuem relacionamentos prprios entreelas.

9.2 - Auto-Relacionamento Um-para-Muitos

Auto-relacionamentos so, em verdade, representaes de estruturas dehierarquias na maioria das vezes. Por exemplo, vamos considerar uma entidadePessoa, 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 sofilhas de outras pessoas.

Seja ento a entidade Pessoa e seus auto-relacionamentos Tem_PAI eTem_ME, como enxergar estes dados em uma nica tabela? A soluo estmostrada na tabela simulada apresentada na figura 9.2.


64/156

Um outro exemplo seriam os funcionrios de um empresa. Entre estesfuncionrios 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 Pessoapossui Muitos Filhos, um relacionamento de cardinalidade Um-para-Muitos, mas umauto-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 denascimento referenciam o nome dos pais, estas ocorrncias estariam realizandoreferncias lgicas a outras ocorrncias da mesma entidade.

Vamos definir o dicionrio de dados correspondente a esta situao para aentidade Pessoa, mostrados nas tabelas a seguir.

ENTIDADE ATRIBUTOS

PESSOA Identificao_Pessoa NomeIdentificao_Pessoa_PAIIdentificao_Pessoa_ME

p g

Tabela da Entidade Pessoa

IDENTIFICAOPESSOA

NOME IDENTIFICAOPESSOA_PAI

IDENTIFICAOPESSOA_ME

1-68 Carlos Feliciano null null

1-99 Jussara Pinto 1-68 1-29

1-29 Cludia Bicoy null null

1-45 Pedro Luiz Bil 1-68 1-29

1-34 Cludio Carvil 1-55 1-78

1-55 Antnio Luiz null null

1-78 Orvandina null null

Figura 92

Pelo conceito de generalizao temos, na realidade, mltiplos subconjuntos dedados, 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.

RELACIONAMENTO EXPRESSO

Tem_PAI Pessoa.Identificao_Pessoa_PAI =Pessoa. Identif icao_Pessoa

Tem_MAE Pessoa. Identificao_Pessoa_ME =Pessoa.Identificao Pessoa

Figura 93

Jussara filha de Carlos Feliciano, pelo relacionamento Tem_Pai, e filha deCludia Bicoy pelo relacionamento Tem_Me.

A prpria interpretao do relacionamento mostra-nos que as ocorrncias daentidade assumem papis diferentes conforme seu posicionamento norelacionamento.

Os campos deste relacionamento representam a estrutura de engenharia de umproduto.


65/156

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 odiagrama de entidades e relacionamentos, porque permite que se tenda o sentido dorelacionamento e qual tipo de participao no acionamento tem uma ocorrncia.

A figura anterior apresenta o diagrama E-R, agora com a forma de presso dorole, papis da entidade em cada lado do relacionamento.

9.3 - Auto-Relacionamento Muitos-para-Muitos

Os auto-relacionamentos podem possuir qualquer um dos tipos decardinalidade. Vamos ento aprender a visualizar o tipo de cardinalidade Muitos-

para-Muitos.

muito comum este tipo de cardinalidade quando desejamos apresentarcomposies de algum objeto, por exemplo:

Figura 9.4

Em uma indstria, um produto composto de vrios outros produtos, e socomponentes. Por outro lado, um produto componente pode participar dacomposio de muitos produtos.

Observem que estamos lidando com um nico tipo de objeto, Produto.

Temos ento um auto-relacionamento Muitos-para-Muitos, com campos, queexpressam composio de objetos.

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 atributospertinentes entidade Produto e ao relacionamento Compe (figura 9.5).

ENTIDADE ATRIBUTO

PRODUTO Cdigo_ProdutoDescrio_ProdutoUnidade_Produto

RELACIONAMENTO ATRIBUTO

COMPE Cdigo_Produto_CompostoCdigo_Produto_ComponenteQuantidade_Participao_Componente

Figura 95

Vamos imaginar uma tabela com Produtos e uma tabela doRelacionamento.

TABELA DE PRODUTOS

PRODUTO DESCRIO UNIDADE

001 Terminal de vdeo pea002 Tubo Imagem 14" pea003 Caixa para terminal P22 pea

004 Transformador XXX pea005 Boto de controle pea010 Gabinete para CPU 386 pea011 Boto dois estgios pea023 Capa plstica para vdeo pea045 Parafuso Phillips 3/4" pea068 Cola Superbonder tubo087 Fita

Livro - Projeto de Banco de Dados - Uma Visão Prática - Felipe Machado e Mauricio Abreu

Documents

Transcript of Livro - Projeto de Banco de Dados - Uma Visão Prática - Felipe Machado e Mauricio Abreu