modelagem de dados, peter chen

Upload: leandro-lima

Post on 08-Jul-2015

1.630 views

Category:

Documents


24 download

TRANSCRIPT

Rafael Gama de Macedo Jr.

O MTODO ENTIDADE-RELACIONAMENTO PARA PROJETO LGICO DE BANCOS DE DADOS

1. INTRODUOO gerenciamento de dados tornou-se uma das atividades mais importantes em muitas organizaes. Conforme nos movemos para uma sociedade cada vez mais orientada para a informao, a determinao de como organizar os dados para maximizar sua utilidade torna-se um problema muito importante. Sistemas de arquivo e sistemas de banco de dados baseados em computador simplificam a tarefa de manter e recuperar uma grande quantidade de dados. Contudo, o problema de como organizar os dados para utilizar a capacidade total do sistema de arquivos ou do banco de dados no bem compreendido por muitas pessoas que trabalham em processamento de dados. A finalidade desta obra proporcionar uma metodologia que torne o processo de organizao de dados mais fcil de ser compreendido e seguido. 1.1 TERMINOLOGIA BSICA Nesta seo, vamos explicar vrios conceitos bsicos em gerenciamento de dados.1

2

Modelagem de Dados

Um registro uma coleo de itens de dados. Por exemplo, um registro de funcionrio contm os dados relevantes de um funcionrio especfico. (Ver Figura 1.) Um registro dividido em vrios campos. Na Figura 1, NOME, SALRIO e ENDEREO so os nomes dos campos de um registro de funcionrio. Nomes de campos so utilizados para interpretar o significado dos itens de dados (ou valores) no registro. Portanto, "ROBERT JOHNSON" o "NOME" de um funcionrio especfico e "10K" o seu "SALRIO". Um arquivo uma coleo de registros do mesmo tipo. Por exemplo, o arquivo de FUNCIONRIO uma coleo de registros de FUNCIONRIO. (Ver Figura 2.) Um banco de dados uma coleo de registros de tipos diferentes. (Ver Figura 3.) Os registros em um banco de dados so interligados, de forma que itens de dados relevantes em registros diferentes possam ser recuperados sem dificuldade. Por exemplo, podemos desejar interligar todos os registros de funcionrios que trabalhem para o mesmo departamento (Ver Figura 4), de modo que seja fcil encontrar quem trabalha para um departamento especfico. A Figura 4 ilustra a estrutura fsica de dados do banco de dados na qual as conexes entre registros de DEPARTAMENTO e registros de FUNCIONRIO so implementadas por cadeias. Um registro de DEPARTAMENTO tem um ponteiro que aponta para o primeiro registro de FUNCIONRIO na cadeia. Cada registro de FUNCIONRIO na cadeia tem um ponteiro que aponta para o registro de FUNCIONRIO seguinte. O ltimo registro de FUNCIONRIO aponta de volta para o registro de DEPARTAMENTO. A Figura 4 ilustra os relacionamentos de ocorrncias de registros no banco de dados, mas detalhada demais para ser til na comunicao de relacionamentos-chaves no banco de dados. A Figura 5 uma maneira simples de representar a organizao de registros da Figura 4. Cada retngulo na Figura 5 representa um tipo de registro e a seta representa a associao de registros de FUNCIONRIO com seus registros de DEPARTAMENTO. H uma outra distino entre as Figuras 4 e 5; a Figura 5 representa a estrutura lgica de dados do banco de dados, uma vez que mostra apenas a conexo entre o tipo de registro de DEPARTAMENTO e o tipo de registro de FUNCIONRIO, mas no mostra como essa conexo implementada.

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

3

NOMES DE CAMPO

NOME ROBERT JOHNSON

SALRIO 10K

ENDEREO BOSTON, MASS.

VALORES Figura 1 Um registro de FUNCIONRIO.

ROBERT JOHNSON

10K

BOSTON, MASS.

LEE GOODMAN

25 K

N.Y., N.Y

JEAN WALTERS

16K

SAN JOSE, CALIF.

Figura 2

Um arquivo de FUNCIONRIO.

4

Modelagem de DadosUM BANCO DE DADOS

REGISTROS DE FUNCIONRIO FUNCIONRIO A

REGISTROS DE DEPARTAMENTO DEPARTAMENTO A

FUNCIONRIO B

DEPARTAMENTO B

FUNCIONRIO C

Figura 3

Um banco de dados com dois tipos de registros.

DEPARTAMENTO A

FUNCIONRIO A

FUNCIONRIO B

DEPARTAMENTO B

FUNCIONRIO C

Figura 4

Registros relevantes no banco de dados so interligados (estrutura fsica de dados do banco de dados).

FUNCIONRIO

DEPARTAMENTO

Figura 5

Estrutura lgica de dados do banco de dados.

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

5

1.2 PROJETO LGICO DE BANCO DE DADOS E PROJETO FSICO DE BANCO DE DADOSO projeto de bancos de dados pode ser dividido em duas etapas: projeto lgico e projeto fsico. (Ver Figura 6.) O projeto fsico de banco de dados o processo de selecionar uma estrutura fsica de dados para uma dada estrutura lgica de dados. Por exemplo, h pelo menos trs (3) estruturas fsicas de dados possveis dentro de um sistema de banco de dados CODASYL para dar suporte mesma estrutura lgica de dados da Figura 6. A primeira usar um "ponteiro para frente" para ligar todos os registros de FUNCIONRIO no mesmo departamento. A segunda acrescentar "ponteiros para trs" aos registros de FUNCIONRIO. A terceira usar um "conjunto de ponteiros" no qual o registro de DEPARTAMENTO mantm ponteiros para todos os registros de FUNCIONRIO relacionados. Cada uma dessas trs estruturas fsicas de dados tem suas vantagens e desvantagens. A primeira fcil de implementar e adequada para processamento seqencial dos registros de FUNCIONRIO. A segunda torna relativamente fcil encontrar os registros de FUNCIONRIO anteriores na cadeia custa de mais espao de armazenamento necessrio devido aos ponteiros para trs (tambm torna o processo de excluso mais eficiente). A principal vantagem da terceira estrutura fsica de dados que todos os registros de FUNCIONRIO que pertenam ao mesmo departamento podem ser recuperados simultaneamente. importante observar que nenhuma estrutura fsica de dados universalmente tima. A finalidade do projeto fsico de banco de dados selecionar a estrutura fsica de dados que seja mais adequada para determinado ambiente de aplicao. Embora o projeto fsico de banco de dados seja um tpico importante, no vamos aprofundar a discusso a esse respeito nesta obra. O projeto lgico de banco de dados o processo de planejar a estrutura lgica de dados para o banco de dados. (Ver Figura 6.) Isto envolve uma anlise do ambiente de aplicao e dos tipos de estruturas lgicas de dados disponveis no sistema de banco de dados. Atualmente, h poucas ferramentas para auxiliar o processo de projeto lgico de

6

Modelagem de Dados

banco de dados; o projetista de banco de dados geralmente tem de contar com sua intuio e experincia. Como resultado, muitos bancos de dados existentes hoje em dia no so adequadamente projetados. Nesta obra, vamos nos concentrar no processo de projeto lgico de banco de dados e introduzir uma ferramenta til e prtica para ajudar o projetista de banco de dados.MUNDO REAL ESTRUTURA LGICA DE DADOS ESTRUTURA FSICA DE DADOS DEPARTAMENTO A

FUNCIONRIO A PROJETO FlSICO DE DEPARTAMENTO BANCO DE DADOS FUNCIONRIO

FUNCIONRIO B

DEPARTAMENTO A

PONTOS DE INTERESSE PARA A EMPRESA

FUNCIONRIO A

FUNCIONRIO B

DEPARTAMENTO A

FUNCIONRIO A

FUNCIONRIO B

Figura 6

Projeto lgico e fsico de banco de dados.

1.3 SISTEMAS DE BANCOS DE DADOS E MODELOS DE DADOS H muitos sistemas de bancos de dados em uso no momento. Eles podem ser classificados em trs (3) categorias principais: hierrquico, de rede e relacionai. Uma das principais diferenas entre eles o tipo de estruturas lgicas de dados que podem ser suportadas. Sistemas hierr-

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

7

quicos de bancos de dados, como o Information Management System (IMS) da IBM, requerem que os tipos de registro de dados sejam organizados em uma forma hierrquica. (Ver Figura 7.) Essa estrutura hierrquica de dados funciona bem com alguns bancos de dados, mas torna-se difcil projetar bancos de dados usando um sistema hierrquico quando no existe uma hierarquia natural entre os tipos de registro. Sistemas de bancos de dados em rede (ou CODASYL), tais como o Integrated Data Store (IDS) da Honeywell, o DMS-1100 da UNIVAC e o IDMS da Cullinane, proporcionam capacidades mais complexas de estruturas de dados do que os sistemas hierrquicos. Por exemplo, os sistemas de rede permitem que um tipo de registro tenha mltiplos tipos de registro como "pais". (Ver Figura 8.) Os sistemas relacionais (a maioria dos quais experimental no momento)* usam tabelas como estruturas lgicas de dados. (Ver Figura 9.) Em resumo, o projeto lgico de bancos de dados preocupa-se com a organizao de dados em uma forma aceitvel para o sistema de banco de dados subjacente. (Ver Figura 10.)DEPARTAMENTO

FUNCIONRIO

HABILIDADE

Figura 7

Estrutura "hierrquica" de dados.

"No momento" se refere a 1977, atualmente esses sistemas so de uso generalizado. (N. do R. T.)

8

Modelagem de Dados

DEPARTAMENTO

FUNCIONRIO

HABILIDADE

FUNCIONRIO-HABILIDADE

Figura 8

Estrutura de dados "de rede".

TABELA DE DEPARTAMENTO ND 1 5 8 ORAMENTO 10M 5M 20M

TABELA DE FUNCIONRIO NOME JOHNSON GOODMAN WALTERS SALRIO 10K 15 K 16 K ENDEREO BOSTON NYC SAN JOS

TABELA DE HABILIDADE NH 5 NOME-H FORTRAN COBOL

TABELA DE FUNCIONRIO-HABILIDADE NOME JOHNSON JOHNSON GOODMAN GOODMAN

TABELA DE DEPARTAMENTO-FUNCIONRIO ND 1 1 5 NOME JOHNSON GOODMAN WALTERS

NH1 2 1 5

21

PM

Figura 9

Estrutura de dados "relacional" ("tabela").

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

9

MUNDO REAL

ESTRUTURA LGICA DE DADOS (ESQUEMA DO USURIO)

HIERRQUICA

PONTOS DE INTERESSE PARA A EMPRESA

PROJETO LGICO DE BANCO DE DADOS (COMO?)

REDE

RELACIONAL

Figura 10

Projeto Lgico de Banco de Dados.

1.4 PROBLEMAS NO PROJETO LGICO DE BANCOS DE DADOS O projeto de bancos de dados , hoje em dia, um processo complicado, uma vez que o projetista tem de considerar no apenas como modelar o mundo real, mas tambm as limitaes do sistema de banco de dados e a eficincia da recuperao e atualizao dos dados. Por exemplo: 1. O projetista de banco de dados restringido pelos tipos limitados de estrutura de dados que so suportados pelo sistema de gerncia de banco de dados. Por exemplo, os relacionamentos muitos-para-muitos entre dois tipos de entidades,

10

Modelagem de Dados

tais como os relacionamentos entre funcionrios e projetos, no podem ser representados diretamente em muitos sistemas de banco de dados. 2. O projetista de banco de dados pode ter de considerar a via de acesso dos registros (ou seja, como acessar um tipo particular de registro). Por exemplo, a suposio implcita na Figura 3 que registros de FUNCIONRIO tm de ser acessados por meio do registro de DEPARTAMENTO correspondente. 3. O projetista de banco de dados pode querer tornar a recuperao e a atualizao mais eficientes. Assim, os dados sobre uma entidade no mundo real podem ser colocados em mais de um registro para propsitos de eficincia. Por exemplo, os itens de dados sobre um funcionrio podem ser agrupados em dois registros: FUNCIONRIO-PRINCIPAL e FUNCIONRIO-DETALHE. H dois problemas no mtodo convencional de projeto de banco de dados: 1. O projetista de banco de dados tem de considerar muitas questes ao mesmo tempo, o que torna a tarefa de projeto de banco de dados muito difcil. 2. O resultado final do projeto lgico de banco de dados o esquema do usurio (ou seja, uma descrio da viso do banco de dados pelo usurio). Uma vez que o esquema do usurio representa a soluo do projetista para as questes complicadas mencionadas acima, no difcil perceber por que os esquemas do usurio so geralmente difceis de ser compreendidos e alterados. 1.5 UM NOVO MTODO PARA PROJETO DE BANCO DE DADOS: O MTODO ENTIDADE-RELACIONAMENTO Vamos descrever um novo mtodo para projeto lgico de bancos de dados chamado mtodo Entidade-Relacionamento (E-R). A idia-cha-

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

11

ve do mtodo E-R acrescentar um estgio intermedirio ao projeto lgico de bancos de dados. (Ver Figura 11.) O projetista de banco de dados primeiro identifica as entidades e relacionamentos que so de interesse para a empresa usando a tcnica diagramtica Entidade-Relacionamento (E-R). Nesse estgio, o projetista deve examinar os dados do ponto de vista da empresa como um todo (no a viso de um programador de aplicao especfico). Portanto, vamos chamar a descrio da viso da empresa quanto aos dados de "esquema da empresa". O esquema da empresa deve ser uma representao "pura" do mundo real e deve ser independente de consideraes sobre armazenamento e eficincia. O projetista de banco de dados primeiro projeta o esquema da empresa e ento o traduz a um esquema do usurio para seu sistema de banco de dados. (Ver Figura 11.)MUNDO REAL ESQUEMA DA EMPRESA HIERRQUICOESQUEMA DO USURIO

PONTOS DE INTERESSE PARA A EMPRESA

REDE

RELACIONAL

Figura 11

Esquema da empresa - uma etapa intermediria no projeto lgico de bancos de dados.

12

Modelagem de Dados

1.6 VANTAGENS DO MTODO ENTIDADERELACIONAMENTO Os mtodos convencionais de projeto lgico de bancos de dados usualmente apresentam uma nica fase: mapeamento de informaes sobre objetos do mundo real diretamente em um esquema do usurio. O mtodo E-R para projeto lgico de bancos de dados consiste em duas fases principais: (1) Definio do esquema da empresa usando o diagrama de Entidade-Relacionamento; e (2) traduo do esquema da empresa em um esquema do usurio. As vantagens do mtodo E-R so: 1. A diviso da funcionalidade e trabalho em duas fases torna o processo de projeto de banco de dados mais simples e mais bem organizado. 2. O esquema da empresa mais fcil de ser projetado do que o esquema do usurio, uma vez que no precisa ser restrito pelas caractersticas do sistema de banco de dados e independente de consideraes sobre armazenamento e eficincia. 3. O esquema da empresa mais estvel do que o esquema do usurio. Se uma pessoa quiser mudar de um sistema de banco de dados para outro, provavelmente ter de alterar o esquema do usurio, mas no o esquema da empresa, uma vez que este independente dos sistemas de banco de dados usados. O que precisa ser feito um remapeamento do esquema da empresa para um esquema do usurio compatvel com o novo sistema de banco de dados. De forma semelhante, se uma pessoa quiser mudar o esquema do usurio para otimizar um novo programa de aplicao, no necessrio alterar o esquema da empresa, mas apenas remape-lo para um novo esquema do usurio. 4. O esquema da empresa expresso pelo diagrama de entidaderelacionamento mais facilmente compreendido por pessoas no ligadas ao processamento eletrnico de dados.

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

13

2. MTODO E-R E PROPOSTA ANSI/X3/SPARC2.1 PROPOSTA ANSI/X3/SPARCO conceito do esquema de empresa muito semelhante ao conceito de esquema conceituai proposto pelo grupo ANSI/X3/SPARC. Nesta seo, vamos discutir a arquitetura ANSI/X3/SPARC e como aplicar a ela o mtodo E-R. No outono de 1971, o Comit sobre Computador e Processamento d Informaes (abreviado com Comit X3) do American National Standards Institute (ANSI) formou um grupo de estudos especial para determinar quais (se h algum) aspectos dos sistemas de gerenciamento de bancos de dados so candidatos adequados ao desenvolvimento de padres. O grupo de estudos especial, que chamado Comit de Planejamento e Requisitos de Padres (Standards Planning and Requirements Committee SPARC), consiste em representantes da comunidade de usurios, fabricantes de hardware e universidades. O grupo ANSI/X3/SPARC gastou tempo e esforos considerveis ponderando diferentes vises da teoria dos bancos de dados e desenvolvendo um vocabulrio que fosse consistente e bem compreendido por todos. Como resultado, seu trabalho despertou muita ateno na comunidade de banco de dados. O grupo ANSI/X3/SPARC descobriu que no desejvel desenvolver padres que especifiquem como os componentes de um sistema de gerenciamento de banco de dados devem funcionar, sendo mais recomendvel centrar-se em como os componentes se integram (ou seja, as interfaces). Com isso em mente, o relatrio delineia uma arquitetura de trs esquemas de um sistema de gerncia de bancos de dados. (Ver Figura 12.) Os sistemas de gerncia de bancos de dados atuais usualmente possuem uma estrutura de dois nveis: a estrutura lgica (ou seja, a estrutura de dados como vista pelo programador) e a estrutura fsica (ou seja, a estrutura de dados como vista pelo computador).

14

Modelagem de Dados

A proposta ANSI/X3/SPARC apresenta uma estrutura de trs nveis: esquema externo, esquema conceituai e esquema interno. (Ver Figura 12.) O esquema externo (esquema do usurio) representa a viso do usurio (ou seja, do programador) quanto aos dados. Em outras palavras, um esquema externo uma descrio de dados visveis para um programa de aplicao em termos de nomes e caractersticas de dados. O esquema interno representa a organizao fsica de dados nos dispositivos de armazenamento. Contm tambm os detalhes de integridade, recuperao e maneiras eficientes de recuperar e atualizar dados. O esquema conceituai representa a viso da empresa quanto aos dados. uma descrio de um modelo da empresa em termos de suas entidades, atributos e relacionamentos entre si. Contm tambm os requerimentos para operaes permitidas, integridade semntica e privacidade. O esquema conceituai visa proporcionar uma viso estvel dos dados.

USURIO MUNDO REAL ESQUEMA , DO USURIO

PONTOS DE INTERESSE PARA A EMPRESA

ESQUEMA CONCEITUAL

ESQUEMA INTERNO

DISPOSITIVOS DE ARMAZENAMENTO

Figura 12

Arquitetura ANSI/X3/SPARC.

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

15

2.2 ESQUEMA CONCEITUAL E ESQUEMA DA EMPRESA Qual a diferena entre o esquema conceituai proposto pelo grupo ANSI/X3/SPARC e o esquema da empresa discutido nesta obra? A resposta que so quase a mesma coisa, exceto que o esquema conceituai necessrio para servir como interface entre o esquema externo e o esquema interno. (Ver Figura 12.) Uma razo para usar o esquema conceituai como a interface reduzir o nmero de mapeamentos entre os esquemas externos e os esquemas internos. Por exemplo, se h M esquemas externos e N esquemas internos, precisamos de M.N programas para fazer os mapeamentos entre os esquemas externos e os esquemas internos. (Ver Figura 13.) Se houver um esquema conceituai entre os esquemas externos e os esquemas internos, precisaremos de apenas M+N programas para fazer os mapeamentos. (Ver Figura 14.) Portanto, o nmero de programas de mapeamento reduzido drasticamente.M ESQUEMAS EXTERNOS

ESQUEMA EXTERNO N1

ESQUEMA EXTERNO N 2

ESQUEMA EXTERNO N M

TRADUES

ESQUEMA INTERNO N1

ESQUEMA INTERNO N2

ESQUEMA INTERNO N N

N ESQUEMAS INTERNOS

Figura 13 Traduo entre esquemas externos e esquemas internos sem um esquema conceituai.

16

Modelagem de DadosM ESQUEMAS EXTERNOS

ESQUEMA EXTERNO N 1

ESQUEMA EXTERNO N 2

ESQUEMA EXTERNO

NM

ESQUEMA CONCEITUAI.

ESQUEMA INTERNO N 1

ESQUEMA INTERNO N 2

ESQUEMA INTERNO N N

N ESQUEMAS INTERNOS

Figura 14 Uso do esquema conceituai como interface entre esquemas internos e externos.

Uma das metas da arquitetura ANSI/X3/SPARC manter o esquema conceituai relativamente estvel, permitindo mudanas nos esquemas externos e internos. Esta meta no parece difcil de ser atingida, uma vez que o esquema conceituai representa a viso da empresa quanto aos dados e deve ser relativamente estvel em comparao viso do usurio quanto viso fsica dos dados. Portanto, quando a organizao fsica do banco de dados alterada ou os dados so transportados de dispositivos de armazenamento "antigos" para dispositivos de armazenamento "novos", apenas alteramos o esquema interno, e no o esquema conceituai ou os esquemas externos. Similarmente, se um usurio quiser ver os dados como um certo tipo de organizao, podemos projetar um esquema externo para ele sem mudar o esquema conceituai e os esquemas internos. A no ser por servir como uma interface entre os esquemas externos e internos, o esquema conceituai a mesma coisa que o esquema de empresa e podemos usar o diagrama de entidade-relacionamento

O mtodo entidade-relacionamento para projeto lgico de bancos de dados 17

para descrever o esquema conceituai. Alm disso, uma vez que os esquemas externos podem ser expressos em termos de diferentes tipos de estruturas de dados, tais como rede (CODASYL), hierrquica ou relacionai (ver Figura 15), as regras de traduo entre diagramas E-R e diferentes tipos de estruturas de dados discutidos adiante nesta obra seriam muito teis na implementao da arquitetura ANSI/X3/SPARC.REDE HIERRQUICA RELACIONAL

ESQUEMAS EXTERNOS

ESQUEMA CONCEITUAL

ESQUEMA INTERNO

Figura 15 Os esquemas externos podem ser expressos em diferentes tipos de estruturas de dados.

2.3 TRS TIPOS DE ADMINISTRADORES DE BANCOS DE DADOS O grupo ANSI/X3/SPARC identificou trs tipos de administradores de bancos de dados:

18

Modelagem de Dados

1. Administrador de empresa O administrador de empresa define o esquema conceituai e, se possvel, o valida. Ele deve compreender muito bem as operaes da empresa e o significado de suas informaes (dados). Ele responsvel pelo contedo, integridade e segurana do banco de dados. 2. Administrador de banco de dados O administrador de banco de dados define o esquema interno. Ele projeta as estruturas fsicas de dados, codificando esquemas, vias de acesso e colocao de dados em dispositivos de armazenamento. Ele responsvel pela utilizao eficiente do espao de armazenamento, assim como pelo desempenho do sistema de banco de dados. 3. Administrador de aplicao Um esquema externo representa uma viso dos dados pelo programador de aplicao. Imagina-se que cada rea geral de aplicao ter seu prprio administrador de aplicao que prov os esquemas externos para aquela rea. Mas esses esquemas externos tm de ser consistentes e derivveis de um nico esquema conceituai. Observe que os mesmos esquemas externos podem ser usados por vrios programadores de aplicao, no necessariamente trabalhando no mesmo programa. Estes trs tipos de administradores representam trs diferentes papis que podem ser desempenhados por um indivduo ou um grupo de pessoas. Embora as distines entre esses trs tipos de administradores de banco de dados sejam claras em termos da arquitetura de trs esquemas do ANSI/X3/SPARC, no so claras nos ambientes de bancos de dados convencionais. Na verdade, o "administrador de banco de dados", como definido hoje em dia em muitas organizaes, tem todas as responsabilidades dos trs tipos de administradores mencionados. Em termos do mbito desta monografia, preocupamo-nos primariamente com a responsabilidade do administrador de empresa (ou seja, a tarefa de modelar o mundo real) e a responsabilidade do administrador de aplicao (ou seja, a tarefa de projetar os esquemas externos).

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

19

2.4 RELEVNCIA DO MTODO E-REm suma, se a arquitetura ANSI/X3/SPARC tornar-se realidade, o mtodo E-R pode ser usado das seguintes maneiras: 1. No projeto do esquema conceituai. 2. Na traduo do esquema conceituai em esquemas externos.

20

Modelagem de Dados

3. DIAGRAMA DE ENTIDADERELACIONAMENTO (E-R)Neste captulo, vamos introduzir a tcnica diagramtica de entidade-relacionamento. Discutiremos primeiro o que so entidades e relacionamentos e, ento, explicaremos como descrever propriedades de entidades e relacionamentos. 3.1 ENTIDADES E RELACIONAMENTOS 3.1.1 Tipos de Entidade Uma entidade uma "coisa" que pode ser distintamente identificada. As entidades podem ser classificadas em diferentes tipos, tais como FUNCIONRIO e ACIONISTA. (Ver Figura 16.) No diagrama E-R, um tipo de entidade representado por um retngulo. (Ver Figura 17.)

FUNCIONRIO

ACIONISTA

Figura 16 Entidades e tipos de entidades.

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

21

FUNCIONRIO

ACIONISTA

Figura 17 Tipos de entidades so representados por retngulos.

H muitas "coisas" no inundo real. Algumas delas so de interesse para a empresa, e o resto no. responsabilidade do projetista de banco de dados selecionar os tipos de entidade que so mais adequados para sua empresa. 3.1.2 Tipos de Relacionamento Relacionamentos podem existir entre entidades. Por exemplo, CASAMENTO um relacionamento entre duas entidades humanas. (Ver Figura 18.) Os relacionamentos podem ser classificados em diferentes tipos de relacionamentos. Por exemplo, PROJ-FNC e PROJ-GERENTE so dois tipos de relacionamentos diferentes entre dois tipos de entidades, PROJ (projeto) e FUNC (funcionrio). Na notao diagramtica de entidade-relacionamento, um tipo de relacionamento representado por um losango com linhas conectadas a tipos de entidades relacionadas. (Ver Figura 19.) As notaes "m" e "1" associadas ao tipo de relacionamento PROJ-GERENTE na Figura 16 indicam que cada projeto tem apenas um gerente, mas que um funcionrio pode ser o gerente de muitos projetos. O V e "n" associados com o tipo de relacionamento PROJ-FUNC indicam que um mapeamento muitos-paramuitos. Isto , cada projeto pode consistir em vrios funcionrios e cada funcionrio pode estar associado a mais de um projeto. Observe que outros tipos de mapeamento entre entidades tambm so possveis. Por exemplo, o tipo de relacionamento CASAMENTO um mapeamento um-para-um entre entidades humanas. (Ver Figura 20.) possvel definir um tipo de relacionamento entre mais de dois tipos de entidades. Por exemplo, PARTE-FORN-PROJ, que descreve que partes so abastecidas por fornecedores especficos para projetos especficos (Figura 21), um tipo de relacionamento definido em trs tipos de entidades: PARTE, FORN (fornecedor) e PROJ (Figura 22).

22

Modelagem de Dados

CASAMENTO

Figura 18 CASAMENTO como um relacionamento entre duas entidades humanas.

PROJGERENTE

PROJ

FUNC

PROJ-FUNC

Figura 19 Tipos de relacionamentos so representados por losangos.

PESSOA

CASAMENTO

Figura 20 CASAMENTO como um tipo de relacionamento entre entidades humanas.

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

23

N PARTE 25 25 10 10 17 17

N FORNECEDOR 4 5 4 4 2 5

N PROJ 1 2 2 3 1

1

Figura 21

Informaes sobre relacionamentos PARTE-FORN-PROJ.

PARTE PARTE FORNPROJ

FORN

PROJ

Figura 22

PARTE-FORN-PROJ como um tipo de relacionamento.

Note que um relacionamento ternrio usualmente no pode ser substitudo por trs relacionamentos binrios. Por exemplo, o relacionamento ternrio PARTE-FORN-PROJ na Figura 21 substitudo por trs relacionamentos binrios: PARTE-FORN, FORN-PROJ e PROJ-PARTE. (Ver Figura 23.) Contudo, se quisermos construir o relacionamento ternrio partindo desses trs relacionamentos binrios, obteremos alguns "no-fatos". (Ver as entradas com asteriscos na Figura 24.) H muitos tipos de relacionamentos entre entidades e alguns deles so de interesse para a empresa: o projetista de banco de dados responsvel pela seleo dos tipos de relacionamentos relevantes para a empresa. Ele deve tambm especificar os tipos de mapeamento dos tipos de relacionamentos (ex.: um-para-um, um-para-muitos, muitos-para-muitos).

24

Modelagem de Dados

N PARTE 25 25 10 17 17

N FORN 4 5 4 2 5

N FORN 4 4 4 5 5 2

N PROJ 1 2 3 1 2 1

NPROJ 1 1 2 2 3

N PARTE 25 17 10 25 10

Figura 23 Informaes sobre trs relaes binrias: PARTE-FORN, FORN-PROJ e PROJ-PARTE.

N PARTE 25

N FORN 4 4 5 5 4 4 2 5

N PROJ 1 2 1 2 2 3 1 1

* *

25 25 25 10 10 17 17

Figura 24 Informaes geradas das trs relaes binrias da Figura 23.

3.2 DESCRIO DE ENTIDADES E RELACIONAMENTOS 3.2.1 Atributos e Valores Entidades e relacionamentos tm propriedades que podem ser expressas em termos de pares atributo-valor. Por exemplo, na afirmao "a IDADE DO FUNCIONRIO x 24", "IDADE" um atributo do funcionrio x e "24" o valor do atributo "IDADE". Os valores podem ser

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

25

classificados em diferentes tipos de valor, tais como N DE ANOS, QUANTIDADE e COR. Na notao diagramtica E-R, um tipo de valor representado por vim crculo (ver Figura 25) e um atributo representado por um ponteiro dirigido do tipo de entidade para o tipo de valor desejado.

FUNCIONRIO

N DO CIC

IDADE

N DO TELEFONE

234-55-7684 013-64-7777 315-88-4158

20 18 26 55

253-6606 253-9999 478-6574

N DO CIC F i g u r a 25

IDADE

N2 DO TELEFONE

Tipos de valores e atributos.

Em alguns casos, um atributo pode ter mais de um valor para uma determinada entidade. Por exemplo, "N DE TELEFONE" do funcionrio x pode ter dois valores: 253-6606 e 253-9999. Neste caso, colocamos "l:n" no ponteiro para indicar que um atributo de valores mltiplos. Isto similar ao conceito de "grupo de repetio" em processamento de dados convencional. Contudo, muitos atributos, tais como "IDADE" e "N DO CIC", tm um s valor. Para simplicidade, no associamos nada como "1:1" aos ponteiros no diagrama E-R para tais atributos. At agora, consideramos apenas os atributos de entidades. s vezes, estamos tambm interessados nas propriedades de um relacionamento. Por exemplo, podemos querer saber quando o funcionrio x comeou a trabalhar em um determinado projeto. A DATA DE INCIO no um atributo do FUNCIONRIO nem do PROJ, uma vez que seu valor depende tanto do funcionrio especfico quanto do projeto envol-

26

Modelagem de Dados

vido. Portanto, a DATA DE INCIO um atributo do relacionamento PROJ-FUNC. Um outro exemplo de atributo do relacionamento a PORCENTAGEM DE ESFORO, que a porcentagem de tempo que um funcionrio devota a um determinado projeto. (Ver Figura 26.) O conceito de atributo de relacionamento importante para compreender a semntica dos dados. O conceito semelhante ao de dados de relacionamento em sistemas de bancos de dados do tipo "rede" (CADASYL) e ao de dados de interseco em sistemas de bancos de dados do tipo hierrquico (tipo IMS).

PROJ

PROJFUNC DATA DE INCIO

FUNC

PORCENTAGEM DE ESFORO

9/15/75 7/22/76

20% 30% 90%

DATA DE INCIO PORCENTAGEM DE ESFORO Figura 26 Atributos de relacionamento.

3.2.2 Identificador de Entidade As entidades discutidas at agora so aquelas que existem em nossas mentes ou podem ser identificadas com um apontar de dedo. Quando algum pergunta, "De que cor isto?", "isto" ou compreendido tanto por quem est falando quanto pelo ouvinte, ou identificado apontando-se para o objeto. Este esquema de identificao pode funcionar para muito poucos objetos, porm encontraremos dificuldades quando quisermos comunicar a informao sobre uma variedade de objetos para muitas pessoas diferentes. Portanto, tanto na conversa do dia-a-dia como em processamento de dados computadorizado, precisa-

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

27

mos de um outro esquema para identificar entidades. Cada entidade tem muitos atributos, mas qual deles deve ser escolhido? A resposta que os atributos escolhidos devem ser capazes de identificar de forma absoluta as entidades. Por exemplo, podemos usar o atributo NOME para identificar funcionrios em uma pequena companhia, mas no em uma grande firma. Esses atributos escolhidos da entidade so chamados de identificadores de entidade. Em alguns casos, pode ser difcil ou inconveniente usar os atributos disponveis como identificadores da entidade. O que podemos fazer criar um atributo artificial que possa identificar incontestavelmente as entidades. Exemplos so N DO CIC, N DO FUNC, N DA PARTE e N DO PROJ. O conceito de identificador de entidade similar ao conceito de chave primria em processamento de dados convencional.

3.2.3 Identificador de RelacionamentoOs relacionamentos so identificados pelo uso de identificadores das entidades envolvidas no relacionamento. Por exemplo, se um projeto identificado por seu N DO PROJ e um funcionrio identificado por N DO FUNC, ento o relacionamento PROJ-FUNC identificado por ambos os N DO PROJ e n DO FUNC. Em algumas situaes, um tipo de relacionamento definido entre duas ocorrncias do mesmo tipo de entidade. Por exemplo, CASAMENTO um tipo de relacionamento definido entre ocorrncias do mesmo tipo de entidade, PESSOAS. Para identificar inequivocamente tais relacionamentos, usamos no apenas o identificador de entidade, mas tambm indicamos qual o papel que a entidade desempenha no relacionamento. No caso de CASAMENTO, devemos ligar os nomes MARIDO e MULHER ao identificador de entidade NOME, onde MARIDO e MULHER so os "papis" que eles desempenham na relao CASAMENTO. 3.3 TIPOS ESPECIAIS DE ENTIDADE E RELACIONAMENTO Nesta seo, vamos discutir alguns tipos especiais de entidade e relacionamento que so comumente encontrados.

28

Modelagem de Dados

3.3.1 Existncia-Dependente A existncia de uma entidade pode depender da existncia de um outro tipo de entidade. Por exemplo, a existncia de entidades FILHOS no banco de dados depende da existncia dos funcionrios associados. Em outras palavras, se um funcionrio deixa a companhia, no precisamos manter o registro de seus filhos. A Figura 27 ilustra o diagrama E-R para essa situao. FILHOS representado por um retngulo duplo, o que significa que um tipo de entidade "fraca". A existncia de uma entidade fraca depende da existncia de outras entidades. O "E" dentro do losango do relacionamento indica que um relacionamento existncia-dependente; o ponteiro associado ao losango do relacionamento indica a direo da dependncia. E possvel que o relacionamento existncia-dependente seja um mapeamento muitos-para-muitos. Por exemplo, se o pai deixa a companhia, as entidades FILHOS podem ainda existir se a me continuar sendo uma funcionria da companhia. Esta situao representada no diagrama E-R mostrado na Figura 28.

FUNC

E

FILHOS

Figura 27 Um relacionamento de tipo existncia-dependente e um tipo de entidade fraca.

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

29

FUNC M (PELO MENOS 1)

E

FILHOS

Figura 28 Uma relao existncia-dependente pode ser tambm um mapeamento muitos-para-muitos.

3.3.2 Dependncia de Identificador (ID) Se uma entidade no puder ser identificada inequivocamente por seus prprios atributos e tiver de ser identificada por seus relacionamentos com outras entidades, ela tem dependncia de identificador com as outras entidades. Por exemplo, "rua" s especfica dentro de uma cidade, uma cidade s especfica dentro de um Estado, e um Estado s especfico dentro de um pas. Para identificar precisamente o endereo de uma localizao, temos de especificar os nomes da cidade, Estado e pas, alm do nome da rua. dependncia de identificador indicada pelo "ID" no losango de relacionamento, e a direo do relacionamento indicada pelo ponteiro (Ver Figura 29); a maioria das dependncias ID est associada a existncias-dependentes. Contudo, a existnciadependente no implica a dependncia ID. Por exemplo, as entidades FILHOS na Figura 30 so identificadas com seus prprios atributos e o ID de seus pais (ver Figura 31), enquanto as entidades FILHOS na Figura 27 podem ser identificadas por seus prprios N DO FILHO. (Ver Figura 32.)

30

Modelagem de Dados

PAS

E&

ESTADO

E& ID

CIDADE

E& ID

RUA

Figura 29 Existncia-dependente e Dependncia ID.

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

31

FUNC

FILHOS

Figura 30 Existncia-dependente e Dependncia ID.

ID DOS FILHOS ID DO FUNC NOME NANCY BOK LAWRENCE BOK ROBERT JOHNSON CIC DO PAI OU ME 013-58-5545 172-66-6672 819-38-7776

D ADOS SOBRE FILHOS

IDADE 12 5 21

SEGURO-SADE BC/BS BC/BS TEM PLANO PRPRIO

Figura 31 Dependncia ID.

ID DOS FILHOS N DOS FILHOS 1011 1025 1044 NOME NANCY BOK LAWRENCE BOK ROBERT JOHNSON IDADE 12 5 21 SEGURO-SADE BC/BS BC/BS TEM PLANO PRPRIO

Figura 32 Sem Dependncia ID.

32

Modelagem de Dados

4. TRADUO DE DIAGRAMAS E-R EM DIAGRAMAS DE ESTRUTURA DE DADOS4.1 DIAGRAMAS DE ESTRUTURA DE DADOS As estruturas lgicas de dados de bancos de dados suportadas pelo sistema tipo CODASYL (rede) de banco de dados podem ser expressas em termos de diagrama de estrutura de dados. Cada retngulo representa um tipo de registro, tal como FUNC e DEPENDENTE. O ponteiro representa um conjunto de estrutura de dados que conecta dois tipos de registro. O tipo de registro no qual o ponteiro se origina o tipo proprietrio de registro do conjunto de estrutura de dados, e o tipo de registro no qual o ponteiro termina o tipo membro de registro do conjunto de estrutura de dados. Na Figura 33, FUNC o tipo proprietrio de registro e DEPENDENTE o tipo membro de registro. Em um conjunto de estrutura de dados, o registro proprietrio pode ter zero, um ou mais registros membros (ocorrncias). Um registro membro em um conjunto de estrutura de dados tem exatamente um registro proprietrio. Em nosso exemplo, cada registro de funcionrio pode estar conectado a muitos registros de DEPENDENTE ou a nenhum. Contudo, cada registro de DEPENDENTE deve estar associado a exatamente um registro FUNC. Isto ilustrado na Figura 34. Conceitualmente, o ponteiro representa uma associao l:n (um-para-muitos) entre o tipo proprietrio de registro e o tipo membro de registro. Este tipo de associao pode tambm ser representado em forma de tabela. (Ver Figura 35.)

FUNC

TIPO "PROPRIETRIO" DE REGISTRO CONJUNTO DE ESTRUTURA DE DADOS

DEPENDENTE

TIPO "MEMBRO" DE REGISTRO

Figura 33 Um diagrama de estrutura de dados.

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

33

FUNC 2142

FUNC 1781

FUNC 2566

N DO FUNC

DEP A

DEP B

DEP C

DEP D

(A) ZERO DEPENDENTE

(B) TRS DEPENDENTES

(C) UM DEPENDENTE

Figura 34 Um registro PROPRIETRIO pode ter zero, um ou mais registros "membros*.N DO FUNC 1781 1781 1781 2566 DEPENDENTE A B C D

Figura 35 Correspondncia um-para-muitos entre FUNCIONRIO e DEPENDENTES.

A Figura 36 ilustra uma estrutura de dados mais complicada. O tipo de registro FUNCIONRIO o registro proprietrio de um conjunto de estrutura de dados no qual FUNCIONRIO-HABILIDADE o registro membro. O tipo de registro FUNCIONRIO-HABILIDADE tambm o registro membro de um outro conjunto de estrutura de dados no qual o tipo de registro HABILIDADE o registro proprietrio. Na verdade, o registro FUNCIONRIO-HABILIDADE contm a informao sobre FUNCIONRIOS e HABILIDADES. Esse tipo de informao pode ser representado na forma de tabela, como mostrado na Figura 37. Podemos ver na Figura 37 que um funcionrio pode ter uma ou mais habilidades e que usualmente mais de um funcionrio tem uma habilidade especfica. Portanto, a relao entre funcionrios e habilidades m:n (muitos-para-muitos). Essa correspondncia m:n entre funcionrios e habilidades pode ser derivada da Figura 36. Os conjuntos

Rafael Gama de Macedo Jr.

34

Modelagem de Dados

de estrutura de dados na Figura 36 mostram que existe um mapeamento l:m (um-para-muitos) entre o tipo de registro FUNCIONRIO e o tipo de registro FUNCIONRIO-HABILIDADE, e que um mapeamento semelhante (l:n) existe entre o tipo de registro HABILIDADE e o tipo de registro FUNC-HABILIDADE. Portanto, a correspondncia entre o registro FUNC e o tipo de registro habilidade m:n (muitos-para-muitos).FUNC HABILIDADE

FUNC-HABILIDADE

Figura 36 Dois conjuntos de estrutura de dados tm o mesmo tipo "membro" de registro.

N DO FUNC 2142 2141 1781 2566

HABILIDADE COBOL PL/1 COBOL PL/1

Figura 37 Informaes cruzadas sobre FUNCIONRIOS e HABILIDADES.

O diagrama de estrutura de dados na Figura 36 pode ser implementado usando-se um conjunto de ponteiros, como mostrado na Figura 38. O conjunto de estrutura de dados entre o tipo de registro FUNC e o tipo de registro HABILIDADE representado pelas linhas contnuas, e o conjunto de estrutura de dados entre o tipo de registro HABILIDADE e o tipo de registro FUNC-HABILIDADE representado por linhas pontilhadas.

o mtodo entidade-relacionamento para projeto lgico de bancos de dados

35

Na Figura 38, como determinamos as habilidades de um funcionrio especfico? O primeiro passo localizar o registro de FUNC com o N DO FUNC = 2142, usando um algoritmo hashing ou algum outro mtodo. O segundo passo encontrar o primeiro registro FUNC-HABILIDADE relacionado com esse funcionrio. Por meio do ponteiro mostrado pela linha pontilhada, podemos encontrar um registro de habilidade com HABILIDADE-NOME = COBOL. Encontramos, ento, o segundo registro FUNCIONRIO-HABILIDADE relacionado com o mesmo registro de funcionrio (por meio dos ponteiros de linha contnua). Do registro FUNC-HABILIDADE, podemos seguir por intermdio do ponteiro de linha pontilhada para localizar um registro HABILIDADE com HABILIDADE-NOME = PL/1. No conseguimos, ento, encontrar mais nenhum registro FUNC-HABILIDADE relacionado com os mesmos registros de FUNCIONRIO (ou seja, encontramos a informao de que necessitvamos: o funcionrio com N DO FUNC = 2142 tem duas habilidades: COBOL e PL/1).

FUNC 2142

FUNC 1781

FUNC 2586

FUNCHABILIDADE

FUNCHABILIDADE

FUNCHABILIDADE

FUNCHABILIDADE

HABILIDADE COBOL

HABILIDADE PL/1

Figura 38 Implementao dos conjuntos de estrutura de dados da Figura 37 como conjuntos de ponteiros.

Como encontramos todos os funcionrios com uma habilidade especfica, digamos, COBOL? Primeiro, localizamos o registro HABILIDADE com HABILIDADE-NOME = COBOL. Ento, recuperamos todos os registros FUNC-HABILIDADE relacionados com o registro HABILIDADE. Para cada registro FUNCIONRIO-HABILIDADE, recuperamos, por meio do ponteiro de linha contnua, o registro FUNC correspondente. Fazendo isso, sabemos que h dois funcionrios com a habilidade COBOL, e seus nmeros so 2142 e 1781.

36

Modelagem de Dados

Uma outra maneira de implementar o diagrama de estrutura de dados da Figura 22 usar cadeias, como mostrado na Figura 39. As linhas contnuas conectam todos os registros FUNC-HABILIDADE relacionados com o mesmo registro HABILIDADE. Vamos ver como encontrar as habilidades do funcionrio com N DO FUNC = 2142. Em primeiro lugar, encontramos o primeiro registro FUNC-HABILIDADE por intermdio da cadeia de linha contnua. Do registro FUNCHABILIDADE, encontramos o registro de habilidade por meio da cadeia de linha pontilhada. Do registro FUNC-HABILIDADE procuramos o registro FUNC-HABILIDADE seguinte pela cadeia de linha slida. Do segundo registro FUNC-HABILIDADE, podemos determinar o registro de habilidade correspondente por meio da cadeia de linha pontilhada. Do segundo registro FUNC-HABILIDADE, no conseguimos encontrar mais nenhum registro FUNC-HABILIDADE na cadeia de linha contnua. Agora, sabemos todas as habilidades que o funcionrio 2142 tem. Similarmente, podemos encontrar todos os funcionrios com uma determinada habilidade seguindo atravs das cadeias.

FUNC 2142

FUNC 1781

FUNC 2566

FUNCHABILIDADE

FUNCHABILIDADE

FUNCHABILIDADE

FUNCHABILIDADE

COBOL

PL/1

Figura 39 Implementao dos conjuntos de estrutura de dados da Figura 27 como cadeias.

Um outro tipo de estrutura de dados, que pode usualmente ser encontrado em bancos de dados de processos de produo, mostrado na Figura 40. H dois tipos de registro: PARTE e PRD-REL (produo-relacionamento). Cada produto a ser fabricado consiste em muitas "partes" (componentes). Cada parte, por sua vez, feita de outras partes. O tipo

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

37

de registro PARTE contm informaes sobre a parte especfica. 0 tipo de registro PRD-REL contm as informaes sobre o relacionamento entre as partes. A Figura 41 ilustra esse tipo de relacionamento. Indica que, para produzir a PARTE N1, precisamos de cinco PARTES N 2e duas PARTES N 3. Podemos ver tambm que a PARTE N 3 uma subparte tanto da PARTE N1 quanto da PARTE N 4. H dois conjuntos de estrutura de dados na Figura 40 e eles podem ser implementados como "cadeias", como mostrado na Figura 42. As linhas contnuas representam a cadeia COMPONENTE e as linhas pontilhadas representam a cadeia ONDE USADA. Para encontrar os componentes de uma parte especfica, primeiro recuperamos todos os registros PRD-REL por meio da cadeia COMPONENTE e, ento, recuperamos as subpartes correspondentes pela cadeia ONDE USADA. Fazendo isso, evidenciamos que a PARTE N 4 consiste em uma PARTE N 3 e em duas PARTES N 5. Para descobrir onde uma parte especfica usada para produzir outras partes, primeiro recuperamos todos os registros PRD-REL relacionados com esse registro PARTE especfico por intermdio da cadeia ONDE USADA, e ento recuperamos os registros PARTE correspondentes por meio da cadeia COMPONENTE. Fazendo isso, descobrimos que duas PARTES N 5 so usadas na fabricao da PARTE N 4. As Figuras 33, 36 e 40 so os tipos bsicos de diagramas de estrutura de dados. Um banco de dados pode ser expresso em um grande diagrama de estrutura de dados baseado nesses trs modelos bsicos.

PARTE COMPONENTES ONDE USADA

PRD-REL

Figura 40 Dois conjuntos de estrutura de dados tm os mesmos tipos de registro "proprietrio" e "membro".

38

Modelagem de Dados

SUPERPARTE N 1 1 4 4

SUBPARTE N 2 3 3 5

QUANTIDADE 5 2 1 2

Figura 41 Relao de fabricao entre partes.

PARTE N 1CADEIA COMPONENTE

PARTE N 4 CADEIA COMPONENTEPRD-REL PRD-REL

PRD-REL

PRD-REL

2

CADEIA ONDE usada PARTE N 2

CADEIA ONDE USADA PARTE N 3

CADEIA ONDE USADA PARTE N 5

Figura 42 Implementao dos conjuntos de estrutura de dados da Figura 41.

4.2 REGRAS DE TRADUO Como vimos na seo anterior, o diagrama de estrutura de dados est mais prximo da organizao fsica do banco de dados que o diagrama de entidade-relacionamento. Usualmente, difcil desenhar um diagrama de estrutura de dados para as entidades e relacionamentos que so de interesse para a empresa. Portanto, propomos que o projetista de banco de dados primeiro desenhe um diagrama E-R para representar a viso da empresa quanto aos dados e, ento, traduza-o para um diagrama de estrutura de dados. Nesta seo, vamos discutir como traduzir um diagrama E-R para um diagrama de estrutura de dados. Identificamos algumas regras bsicas para traduo com base no tipo de

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

39

relacionamentos entre entidades. Comeamos com relacionamentos definidos por dois tipos de entidades, depois relacionamentos definidos por mais de dois tipos de entidades e, por fim, relacionamentos do mesmo tipo de entidade. As regras de traduo so as seguintes: 1. Relacionamentos definidos por dois tipos diferentes de entidades: a) O relacionamento uma correspondncia um-para-muitos (ou um-para-um). Por exemplo, o tipo de relacionamento DEPT-FUNC na Figura 43 (a) uma correspondncia umpara-muitos e pode ser transformada no diagrama de estrutura de dados da Figura 43 (b). Note que os tipos de entidades tais como DEPT e FUNC no diagrama E-R so tratados como tipos de registro no diagrama de estrutura de dados, enquanto o tipo de relacionamento DEPT-FUNC representado por um conjunto de estrutura de dados (um ponteiro) no diagrama de estrutura de dados. Similarmente, o tipo de relacionamento PROJ-GERENTE na Figura 44 (a), que restringe um gerente por projeto mas permite vrios projetos com o mesmo gerente, representado por um ponteiro no diagrama de estrutura de dados mostrado na Figura 44 (b).

DEPT

DEPT

DEPT fUNC

FUNCDIAGRAMA E-R

FUNCDIAGRAMA DE ESTRUTURA DE DADOS

Figura 43

40

Modelagem de Dados

FUNC

FUNC

PROJGERENTE

PROJ DIAGRAMA E-R

PROJ DIAGRAMA DE ESTRUTURA DE DADOS

Figura 44

b) O relacionamento uma correspondncia muitos-para-

muitos. Por exemplo, o tipo de relacionamento PROJ-FUNC na Figura 45 (a) uma correspondncia muitos-para-muitos. O diagrama de estrutura de dados correspondente mostrado na Figura 45 (b). Note que o tipo de relao PROJ-FUNC no traduzido em um ponteiro, mas em um tipo de registro. Podemos concluir que, se um tipo de relacionamento uma correspondncia muitos-para-muitos, ele ser traduzido em um tipo de registro com dois ponteiros apontando para ele, vindos dos tipos de registro de entidade relacionados. O tipo de registro PROJ-FUNC usualmente chamado um tipo de registro de relacionamento. Um exemplo semelhante mostrado na Figura 46. Uma vez que o tipo de relacionamento FUNC-HABILIDADE uma correspondncia muitos-paramuitos, traduzido em um tipo de registro (de relacionamento) no diagrama de estrutura de dados.

o mtodo entidade-relacionamento para projeto lgico de bancos de dados(a)PROJ PROJ (b) FUNC

41

PROJ FUNC PROJ-FUNC FUNC DIAGRAMA E-R DIAGRAMA DE ESTRUTURA DE DADOS

Figura 45

FUNC

FUNC

HABILIDADE

FUNC HABILIDADE* FUNCHABILIDADE HABILIDADE DIAGRAMA E-R DIAGRAMA DE ESTRUTURA DE DADOS

Figura 46

2. Relacionamentos definidos por mais que dois tipos de entidades: Neste caso, o tipo de relacionamento no diagrama E-R ser traduzido em um tipo de registro de relacionamento no diagrama de estrutura de dados, seja o relacionamento uma correspondncia um-para-muitos ou de outro tipo. Por exemplo, o tipo de relacionamento PARTE-PROJ-FORN na Figura 47 (a) um tipo de relacionamento definido

42

Modelagem de Dados

por trs tipos de entidades e ser traduzido em um tipo de registro no diagrama de estrutura de dados, como mostrado na Figura 47 (b).

PARTE

PROJ

PARTEPROJ FORN'

FORN DIAGRAMA E-R

PARTE

PROJ

FORN

PARTE-PROJ-FORN DIAGRAMA DE ESTRUTURA DE DADOS

Figura 47

3. Relacionamentos binrios definidos pelo mesmo tipo de entidade: Se o relacionamento binrio for uma correspondncia um-paramuitos, tal como o tipo de relacionamento GERENCIADO na Figura 48 (a), ele poder ser transformado em pelo menos dois possveis diagramas de estrutura de dados, como mostrado nas Figuras 48 (b) e (c). Uma vez que a maioria dos sistemas de bancos de dados do tipo CADOSYL (rede)

O mtodo entidade-relacionamento para projeto lgico de bancos de dados

43

no permite que o mesmo tipo de registro seja usado tanto como tipo de registro proprietrio quanto como tipo de registro membro de um conjunto de estrutura de dados, a Figura 48 (b) no vlida. Portanto, usaremos a Figura 48 (c) como o diagrama de estrutura de dados relativo ao diagrama E-R na Figura 48 (a). Para relacionamentos binrios com outros tipos de correspondncia, usaremos o mesmo tipo de diagrama de estrutura de dados. Por exemplo, PRD-REL um relacionamento de tipo de correspondncia muitos-para-muitos e seu diagrama de estrutura de dados equivalente mostrado na Figura 49 (b).

PESSOA

PESSOA

PESSOA