Seja Nosso Parceiro no Combate Cpia IlegalA 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.

Felipe Nery Rodrigues Machado Maurcio Pereira de Abreu

Seu Cadastro muito Importante para NsAo 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. 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:

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

Editora rica Ltda.

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 ndices para catlogo sistemtico 1. Banco de Dados: Sistemas: Processamento de dados 005.75 CDD-005.75i_ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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.

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,

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.

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

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

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

Lvio Augusto Taufer Diretor da 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 5.1 - A Existncia .......................................................................................................................45 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

10 - POR ONDE COMEAR?..................................................................................................... 121 10.1 - Iniciando um Modelo .......................................................................................................122

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 12.6 - Dependncia Funcional Transitiva .................................................................................. 163 12.7 - Segunda Forma Normal (2FN)........................................................................................ 163 12.8 - Terceira Forma Normal (3FN) ........................................................................................ 165 12.9 - Forma Normal de BOYCE/CODD (FNBC).................................................................... 167 12.10 - Quarta Forma Normal (4FN) ........................................................................................ 169

7 - RELACIONAMENTOS ESPECIAIS ...................................................................................... 81 7.1 - Relacionamentos entre Mltiplas Entidades.......................................................................81 7.2 - Relacionamentos Binrios de Um-para-Um.......................................................................87 7.3 - Usar N:N ou Construir 2 vezes 1:N -A escolha..................................................................96

8-AGREGAO............................................................................................................................. 95 8.1 -A Decomposio de um Relacionamento ...........................................................................95 8.2 - Agregao e Cardinalidade ................................................................................................100 8.3 - Restries para Uso de Agregao.....................................................................................104 8.4 - Como Utilizar Agregao com Entidades Associativas .....................................................106 8.5 - Relacionamentos entre Blocos do Modelo......................................................................... 109

12.11 - Quinta Forma Normal (5FN) .........................................................................................171 12.12- Roteiro de Aplicao da Normalizao ...........................................................................175 12.13 - Desnormalizao ...........................................................................................................177 12.14 - Consideraes Finais Sobre Normalizao....................................................................178

13 - O MODELO LGICO RELACIONAL ...............................................................................181 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 9.3 - Auto-Relacionamento Muitos-para-Muitos ....................................................................... 116 9.4 - Auto-Relacionamento e Papel em um Relacionamento..................................................... 118

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 13.6 - Caractersticas do Modelo Relacionai ............................................................................. 186 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 14.7 - Estudo de Caso 3 ................................................................................................ 292

Introduo

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 edifciodetalhamento do projeto em vrios nveis o projeto constitudo por vrias partes minimizao da interface entre as partes do projeto pouca criatividade na construo fsica especialistas manipulam diferentes partes do projeto aferio do progresso do projeto variao dos materiais e equipamentos componentes pr-moldados so usados Figura 1.1 (continuao)

Desenvolvimento de sistemaso projeto consiste de vrios nveis de detalhamento os modelos so constitudos de vrias partes minimizao da interface entre as partes do projeto pouca criatividade durante a programao especialistas manipulam reas especficas gerentes de projeto avaliam a evoluo do desenvolvimento variao do hardware e software reutilizao de cdigo para aumentar a produtividade

Construo de um edifciocriatividade no projeto construo de modelos introduo das ltimas alteraes vrias recurses so efetuadas at o projeto final existncia de padres para aferio da qualidade do projeto

Desenvolvimento de sistemascriatividade na anlise e projeto construo dos modelos introduo dos ltimos ajustes vrias iteraes so efetuadas durante os estgios de anlise e projeto existncia de padres e regras para medio da qualidade do projeto

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

Figura 1.1

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.

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.1-0 Ciclo de Vida Tradicional ou em CascataEste 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.

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

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

Figura 1.5 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

Figura 1.4

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

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

1.4 - O Ciclo de Vida da Engenharia da InformaoNo 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. 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. 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.

negcio, e principalmente, para controlar as informaes agora setorizadas e especializadas. Existem, na empresa, atividades profissionais especficas tais como: contador, comprador, almoxarife, etc. 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. 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 ArmazmPara 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 DadosO 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 LivroA 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 MotivaoTodos 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 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.

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

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

Figura 3.1 - Nveis de Abstrao.

CRIA

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

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

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-

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

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-

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

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 DadosAo 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 ConceituaisAs 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 Diagrama29

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

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. Esta entidade ser ento um conjunto de dados em nosso modelo conceituai. 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. 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 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.

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.

O Modelo Entidade - Relacionamento

CLIENTE

PRODUTO

FUNCIONRIO

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.

NOTA FISCAL

ORDEM DE PRODUO

Figura 4.4 Entidades. As instncias de uma entidade no so representadas no diagrama de Entidades e Relacionamentos, mas so semanticamente interpretadas no mesmo. 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.

4.4 - AtributosTodo 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. Entidade: Funcionrio Matrcula Nome 4456 6689 1203 7702 Joo Carlos Silva Silvia de Oliveira Carla Martinez Pedro Guilherme Souza Data de Admisso 29/04/91 30/02/92 14/04/92 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

34

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. Entidade: Funcionrio Matrcula 4456 6689 1203 7702 Nome Joo Carlos da Silva Silvia de Oliveira Carla Martinez Pedro Guilherme Souza Data de Admisso 29/04/91 30/02/92 14/04/92 01/01/92

Como entender no mundo real um valor nulo? - 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: - Em que instante modelamos entidades? - Como devemos nos orientar para determinar as entidades? - Como ter certeza de que algo uma entidade?

4.5 - Enxergando EntidadesQuando 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: 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. 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.

Valores de chave primria de tabela: 4456 6689 1203 7702

Chave primria ento o atributo (ou conjunto de atributos concatenados) que identifica uma nica ocorrncia dentro de uma tabela. Este conceito no foge de forma alguma ao que acontece no mundo real, j que um objeto sempre possui uma forma de identificao unvoca. Este objeto no pode, ao modelarmos dados, possuir um identificador corri valor nulo, pois um valor desconhecido impediria a identificao (existncia) deste objeto.

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. 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? 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. Mas o que descreve Consulta Mdica? Os atributos de uma consulta mdica so aqueles que rapidamente comentamos no incio do problema: 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.

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

CRM_Mdico 21114 21113 51024 76004

Nome_Mdico Lus Paulo Carvalho Pedro Estevo Poct Maurcio Abreu Simone Almeida

Especialidade_Mdico Pediatria Ginecologia Neurologia Cardiologia

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

CRM_do_Mdico 21113 21113 14442 55555

Identificao_Paciente Joo Pedro Lima Clara Mathias Lus Alberto Conde Maria Luiza Andrade

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

Sexo Masc. Fem. Fem. Masc.

Idade 32 56 36 56

Figura 4.6 - Entidade Consulta Mdica.

Figura 4.7 - Entidades Mdico e Paciente.

No devemos considerar como entidade um objeto, se no conseguirmos ter a viso de seu contedo em instncias com valores de atributos. 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).

Se analisarmos superficialmente, poderamos ter definido entidades para cada uma destas classes. Ou seja, existiriam as entidades especficas de cada um.

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

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.

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

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. Existe, na realidade, uma hierarquia de classes de dados, encapsulada em uma entidade genrica. 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: Todos os pedidos suspensos; Todos os pedidos nacionais suspensos; Todos os pedidos nacionais; Todos os pedidos pendentes de exportao.

Figura 4.11

Na realidade, temos os subconjuntos do quadro:

Pedido Nacional Pedido Suspenso

Pedido Exportao 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 ExistnciaO 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. 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.

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.

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

JOO Figura 5.1

MARIA

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.

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

HOMEM PEDRO LUS SRGIO CLVIS MARCELO CELSO CARLOS

MULHER SILVIA CARLA ANTNIA ANDREIA CRISTINA MARIA ANA LCIA ANA PAULA ANA 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 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. 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.

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

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

48

5.3 - Relacionamentos CondicionaisSo 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.

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

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 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 ViagemMas 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. Logo temos 4 entidades envolvidas com a nossa viagem, ou seja:MALA SAPATO

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

SAPATO ROUPA PRODUTO DE HIGIENE

Vamos entender quais so os seus atributos bsicos. ENTIDADE: Mala ATRIBUTOS Cor Volume Material Indicador de rodas Tipo de fechamento RELACIONAMENTO Contm Colocado na Est na 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 LIGA Roupa com Mala Sapato com Mala Produto de Higiene com MalaPRODUTO DE HIGIENE

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.

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. 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. 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. 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. 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.SENTIDO DE LEITURA

Figura 5.8