Modelagem de Dados, Peter Chen

Rafael Gama de Macedo Jr.

O MÉTODO ENTIDADE-RELACIONAMENTO PARA PROJETO LÓGICO DE BANCOS DE DADOS

1. INTRODUÇÃO O gerenciamento de dados tornou-se uma das atividades mais importantes em muitas organizações. Conforme nos movemos para uma sociedade cada vez mais orientada para a informação, a determinação 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 não é bem compreendido por muitas pessoas que trabalham em processamento de dados. A finalidade desta obra é proporcionar uma metodologia que torne o processo de organização de dados mais fácil de ser compreendido e seguido. 1.1 TERMINOLOGIA BÁSICA Nesta seção, vamos explicar vários conceitos básicos em gerenciamento de dados. 1

2

Modelagem de Dados

Um registro é uma coleção de itens de dados. Por exemplo, um registro de funcionário contém os dados relevantes de um funcionário específico. (Ver Figura 1.) Um registro é dividido em vários campos. Na Figura 1, NOME, SALÁRIO e ENDEREÇO são os nomes dos campos de um registro de funcionário. Nomes de campos são utilizados para interpretar o significado dos itens de dados (ou valores) no registro. Portanto, "ROBERT JOHNSON" é o "NOME" de um funcionário específico e "10K" é o seu "SALÁRIO". Um arquivo é uma coleção de registros do mesmo tipo. Por exemplo, o arquivo de FUNCIONÁRIO é uma coleção de registros de FUNCIONÁRIO. (Ver Figura 2.) Um banco de dados é uma coleção de registros de tipos diferentes. (Ver Figura 3.) Os registros em um banco de dados são 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 funcionários que trabalhem para o mesmo departamento (Ver Figura 4), de modo que seja fácil encontrar quem trabalha para um departamento específico. A Figura 4 ilustra a estrutura física de dados do banco de dados na qual as conexões entre registros de DEPARTAMENTO e registros de FUNCIONÁRIO são implementadas por cadeias. Um registro de DEPARTAMENTO tem um ponteiro que aponta para o primeiro registro de FUNCIONÁRIO na cadeia. Cada registro de FUNCIONÁRIO na cadeia tem um ponteiro que aponta para o registro de FUNCIONÁRIO seguinte. O último registro de FUNCIONÁRIO aponta de volta para o registro de DEPARTAMENTO. A Figura 4 ilustra os relacionamentos de ocorrências de registros no banco de dados, mas é detalhada demais para ser útil na comunicação de relacionamentos-chaves no banco de dados. A Figura 5 é uma maneira simples de representar a organização de registros da Figura 4. Cada retângulo na Figura 5 representa um tipo de registro e a seta representa a associação de registros de FUNCIONÁRIO com seus registros de DEPARTAMENTO. Há uma outra distinção entre as Figuras 4 e 5; a Figura 5 representa a estrutura lógica de dados do banco de dados, uma vez que mostra apenas a conexão entre o tipo de registro de DEPARTAMENTO e o tipo de registro de FUNCIONÁRIO, mas não mostra como essa conexão é implementada.

O método entidade-relacionamento para projeto lógico de bancos de dados

NOMES DE CAMPO

NOME

SALÁRIO

ENDEREÇO

ROBERT JOHNSON

10K

BOSTON, MASS.

VALORES Figura 1

Figura 2

Um registro de FUNCIONÁRIO.

ROBERT JOHNSON

10K

BOSTON, MASS.

LEE GOODMAN

25 K

N.Y., N.Y

JEAN WALTERS

16K

SAN JOSE, CALIF.

Um arquivo de FUNCIONÁRIO.

3

4

Modelagem de Dados UM BANCO DE DADOS

REGISTROS DE FUNCIONÁRIO

REGISTROS DE DEPARTAMENTO

FUNCIONÁRIO A

DEPARTAMENTO A

FUNCIONÁRIO B

DEPARTAMENTO B

FUNCIONÁRIO C

Figura 3

Um banco de dados com dois tipos de registros.

DEPARTAMENTO A

FUNCIONÁRIO B

FUNCIONÁRIO A

DEPARTAMENTO B

FUNCIONÁRIO C

Figura 4

Registros relevantes no banco de dados são interligados (estrutura física de dados do banco de dados).

FUNCIONÁRIO

DEPARTAMENTO

Figura 5

Estrutura lógica de dados do banco de dados.

O método entidade-relacionamento para projeto lógico de bancos de dados

5

1.2 PROJETO LÓGICO DE BANCO DE DADOS E PROJETO FÍSICO DE BANCO DE DADOS O projeto de bancos de dados pode ser dividido em duas etapas: projeto lógico e projeto físico. (Ver Figura 6.) O projeto físico de banco de dados é o processo de selecionar uma estrutura física de dados para uma dada estrutura lógica de dados. Por exemplo, há pelo menos três (3) estruturas físicas de dados possíveis dentro de um sistema de banco de dados CODASYL para dar suporte à mesma estrutura lógica de dados da Figura 6. A primeira é usar um "ponteiro para frente" para ligar todos os registros de FUNCIONÁRIO no mesmo departamento. A segunda é acrescentar "ponteiros para trás" aos registros de FUNCIONÁRIO. A terceira é usar um "conjunto de ponteiros" no qual o registro de DEPARTAMENTO mantém ponteiros para todos os registros de FUNCIONÁRIO relacionados. Cada uma dessas três estruturas físicas de dados tem suas vantagens e desvantagens. A primeira é fácil de implementar e é adequada para processamento seqüencial dos registros de FUNCIONÁRIO. A segunda torna relativamente fácil encontrar os registros de FUNCIONÁRIO anteriores na cadeia à custa de mais espaço de armazenamento necessário devido aos ponteiros para trás (também torna o processo de exclusão mais eficiente). A principal vantagem da terceira estrutura física de dados é que todos os registros de FUNCIONÁRIO que pertençam ao mesmo departamento podem ser recuperados simultaneamente. É importante observar que nenhuma estrutura física de dados é universalmente ótima. A finalidade do projeto físico de banco de dados é selecionar a estrutura física de dados que seja mais adequada para determinado ambiente de aplicação. Embora o projeto físico de banco de dados seja um tópico importante, não vamos aprofundar a discussão a esse respeito nesta obra. O projeto lógico de banco de dados é o processo de planejar a estrutura lógica de dados para o banco de dados. (Ver Figura 6.) Isto envolve uma análise do ambiente de aplicação e dos tipos de estruturas lógicas de dados disponíveis no sistema de banco de dados. Atualmente, há poucas ferramentas para auxiliar o processo de projeto lógico de

6

Modelagem de Dados

banco de dados; o projetista de banco de dados geralmente tem de contar com sua intuição e experiência. Como resultado, muitos bancos de dados existentes hoje em dia não são adequadamente projetados. Nesta obra, vamos nos concentrar no processo de projeto lógico de banco de dados e introduzir uma ferramenta útil e prática para ajudar o projetista de banco de dados. MUNDO REAL

ESTRUTURA FÍSICA DE DADOS

ESTRUTURA LÓGICA DE DADOS

DEPARTAMENTO A

FUNCIONÁRIO A

PONTOS DE INTERESSE PARA A EMPRESA

PROJETO FlSICO DE DEPARTAMENTO BANCO DE DADOS FUNCIONÁRIO

FUNCIONÁRIO B

DEPARTAMENTO A

FUNCIONÁRIO A

FUNCIONÁRIO B

DEPARTAMENTO A

FUNCIONÁRIO A

Figura 6

FUNCIONÁRIO B

Projeto lógico e físico 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 três (3) categorias principais: hierárquico, de rede e relacionai. Uma das principais diferenças entre eles é o tipo de estruturas lógicas de dados que podem ser suportadas. Sistemas hierár-

O método entidade-relacionamento para projeto lógico 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 hierárquica. (Ver Figura 7.) Essa estrutura hierárquica de dados funciona bem com alguns bancos de dados, mas torna-se difícil projetar bancos de dados usando um sistema hierárquico quando não 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 hierárquicos. Por exemplo, os sistemas de rede permitem que um tipo de registro tenha múltiplos tipos de registro como "pais". (Ver Figura 8.) Os sistemas relacionais (a maioria dos quais é experimental no momento)* usam tabelas como estruturas lógicas de dados. (Ver Figura 9.) Em resumo, o projeto lógico de bancos de dados preocupa-se com a organização de dados em uma forma aceitável para o sistema de banco de dados subjacente. (Ver Figura 10.) DEPARTAMENTO

FUNCIONÁRIO

HABILIDADE

Figura 7

Estrutura "hierárquica" de dados.

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

8

Modelagem de Dados

DEPARTAMENTO

FUNCIONÁRIO

HABILIDADE

FUNCIONÁRIO-HABILIDADE

Figura 8

Estrutura de dados "de rede".

TABELA DE FUNCIONÁRIO

TABELA DE DEPARTAMENTO NºD

ORÇAMENTO

NOME

SALÁRIO

ENDEREÇO

1

10M

JOHNSON

10K

BOSTON

5

5M

GOODMAN

15 K

NYC

8

20M

WALTERS

16 K

SAN JOSÉ

TABELA DE HABILIDADE NºH

NOME-H

5

FORTRAN

2

COBOL

1

PM

Figura 9

TABELA DE FUNCIONÁRIO-HABILIDADE

TABELA DE DEPARTAMENTO-FUNCIONÁRIO

NOME

NºH

NºD

NOME

JOHNSON

1

1

JOHNSON

JOHNSON

2

1

GOODMAN

GOODMAN

1

5

WALTERS

GOODMAN

5

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

O método entidade-relacionamento para projeto lógico de bancos de dados

9

ESTRUTURA LÓGICA DE DADOS (ESQUEMA DO USUÁRIO)

MUNDO REAL

HIERÁRQUICA

PONTOS DE INTERESSE PARA A EMPRESA

PROJETO LÓGICO DE BANCO DE DADOS

REDE

(COMO?)

RELACIONAL

Figura 10

Projeto Lógico de Banco de Dados.

1.4 PROBLEMAS NO PROJETO LÓGICO DE BANCOS DE DADOS O projeto de bancos de dados é, hoje em dia, um processo complicado, uma vez que o projetista tem de considerar não apenas como modelar o mundo real, mas também as limitações do sistema de banco de dados e a eficiência da recuperação e atualização dos dados. Por exemplo: 1. O projetista de banco de dados é restringido pelos tipos limitados de estrutura de dados que são suportados pelo sistema de gerência 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 funcionários e projetos, não 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 suposição implícita na Figura 3 é que registros de FUNCIONÁRIO têm de ser acessados por meio do registro de DEPARTAMENTO correspondente. 3. O projetista de banco de dados pode querer tornar a recuperação e a atualização mais eficientes. Assim, os dados sobre uma entidade no mundo real podem ser colocados em mais de um registro para propósitos de eficiência. Por exemplo, os itens de dados sobre um funcionário podem ser agrupados em dois registros: FUNCIONÁRIO-PRINCIPAL e FUNCIONÁRIO-DETALHE. Há dois problemas no método convencional de projeto de banco de dados: 1. O projetista de banco de dados tem de considerar muitas questões ao mesmo tempo, o que torna a tarefa de projeto de banco de dados muito difícil. 2. O resultado final do projeto lógico de banco de dados é o esquema do usuário (ou seja, uma descrição da visão do banco de dados pelo usuário). Uma vez que o esquema do usuário representa a solução do projetista para as questões complicadas mencionadas acima, não é difícil perceber por que os esquemas do usuário são geralmente difíceis de ser compreendidos e alterados. 1.5 UM NOVO MÉTODO PARA PROJETO DE BANCO DE DADOS: O MÉTODO ENTIDADE-RELACIONAMENTO Vamos descrever um novo método para projeto lógico de bancos de dados chamado método Entidade-Relacionamento (E-R). A idéia-cha-

O método entidade-relacionamento para projeto lógico de bancos de dados

11

ve do método E-R é acrescentar um estágio intermediário ao projeto lógico de bancos de dados. (Ver Figura 11.) O projetista de banco de dados primeiro identifica as entidades e relacionamentos que são de interesse para a empresa usando a técnica diagramática Entidade-Relacionamento (E-R). Nesse estágio, o projetista deve examinar os dados do ponto de vista da empresa como um todo (não a visão de um programador de aplicação específico). Portanto, vamos chamar a descrição da visão da empresa quanto aos dados de "esquema da empresa". O esquema da empresa deve ser uma representação "pura" do mundo real e deve ser independente de considerações sobre armazenamento e eficiência. O projetista de banco de dados primeiro projeta o esquema da empresa e então o traduz a um esquema do usuário para seu sistema de banco de dados. (Ver Figura 11.) MUNDO REAL

ESQUEMA DA EMPRESA

ESQUEMA DO USUÁRIO

HIERÁRQUICO

PONTOS DE INTERESSE PARA A EMPRESA

REDE

RELACIONAL

Figura 11

Esquema da empresa - uma etapa intermediária no projeto lógico de bancos de dados.

12

Modelagem de Dados

1.6 VANTAGENS DO MÉTODO ENTIDADERELACIONAMENTO Os métodos convencionais de projeto lógico de bancos de dados usualmente apresentam uma única fase: mapeamento de informações sobre objetos do mundo real diretamente em um esquema do usuário. O método E-R para projeto lógico de bancos de dados consiste em duas fases principais: (1) Definição do esquema da empresa usando o diagrama de Entidade-Relacionamento; e (2) tradução do esquema da empresa em um esquema do usuário. As vantagens do método E-R são: 1. A divisão 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 fácil de ser projetado do que o esquema do usuário, uma vez que não precisa ser restrito pelas características do sistema de banco de dados e é independente de considerações sobre armazenamento e eficiência. 3. O esquema da empresa é mais estável do que o esquema do usuário. Se uma pessoa quiser mudar de um sistema de banco de dados para outro, provavelmente terá de alterar o esquema do usuário, mas não 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 usuário compatível com o novo sistema de banco de dados. De forma semelhante, se uma pessoa quiser mudar o esquema do usuário para otimizar um novo programa de aplicação, não é necessário alterar o esquema da empresa, mas apenas remapeá-lo para um novo esquema do usuário. 4. O esquema da empresa expresso pelo diagrama de entidaderelacionamento é mais facilmente compreendido por pessoas não ligadas ao processamento eletrônico de dados.

O método entidade-relacionamento para projeto lógico de bancos de dados

13

2. MÉTODO E-R E PROPOSTA ANSI/X3/SPARC 2.1 PROPOSTA ANSI/X3/SPARC O conceito do esquema de empresa é muito semelhante ao conceito de esquema conceituai proposto pelo grupo ANSI/X3/SPARC. Nesta seção, vamos discutir a arquitetura ANSI/X3/SPARC e como aplicar a ela o método E-R. No outono de 1971, o Comitê sobre Computador e Processamento dé Informações (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 são candidatos adequados ao desenvolvimento de padrões. O grupo de estudos especial, que é chamado Comitê de Planejamento e Requisitos de Padrões (Standards Planning and Requirements Committee — SPARC), consiste em representantes da comunidade de usuários, fabricantes de hardware e universidades. O grupo ANSI/X3/SPARC gastou tempo e esforços consideráveis ponderando diferentes visões da teoria dos bancos de dados e desenvolvendo um vocabulário que fosse consistente e bem compreendido por todos. Como resultado, seu trabalho despertou muita atenção na comunidade de banco de dados. O grupo ANSI/X3/SPARC descobriu que não é desejável desenvolver padrões que especifiquem como os componentes de um sistema de gerenciamento de banco de dados devem funcionar, sendo mais recomendável centrar-se em como os componentes se integram (ou seja, as interfaces). Com isso em mente, o relatório delineia uma arquitetura de três esquemas de um sistema de gerência de bancos de dados. (Ver Figura 12.) Os sistemas de gerência de bancos de dados atuais usualmente possuem uma estrutura de dois níveis: a estrutura lógica (ou seja, a estrutura de dados como é vista pelo programador) e a estrutura física (ou seja, a estrutura de dados como é vista pelo computador).

14

Modelagem de Dados

A proposta ANSI/X3/SPARC apresenta uma estrutura de três níveis: esquema externo, esquema conceituai e esquema interno. (Ver Figura 12.) O esquema externo (esquema do usuário) representa a visão do usuário (ou seja, do programador) quanto aos dados. Em outras palavras, um esquema externo é uma descrição de dados visíveis para um programa de aplicação em termos de nomes e características de dados. O esquema interno representa a organização física de dados nos dispositivos de armazenamento. Contém também os detalhes de integridade, recuperação e maneiras eficientes de recuperar e atualizar dados. O esquema conceituai representa a visão da empresa quanto aos dados. É uma descrição de um modelo da empresa em termos de suas entidades, atributos e relacionamentos entre si. Contém também os requerimentos para operações permitidas, integridade semântica e privacidade. O esquema conceituai visa proporcionar uma visão estável dos dados.

USUÁRIO MUNDO REAL ESQUEMA , DO USUÁRIO

PONTOS DE INTERESSE PARA A EMPRESA

ESQUEMA CONCEITUAL

ESQUEMA INTERNO

DISPOSITIVOS DE ARMAZENAMENTO

Figura 12

Arquitetura ANSI/X3/SPARC.

O método entidade-relacionamento para projeto lógico de bancos de dados

15

2.2 ESQUEMA CONCEITUAL E ESQUEMA DA EMPRESA Qual é a diferença entre o esquema conceituai proposto pelo grupo ANSI/X3/SPARC e o esquema da empresa discutido nesta obra? A resposta é que são quase a mesma coisa, exceto que o esquema conceituai é necessário para servir como interface entre o esquema externo e o esquema interno. (Ver Figura 12.) Uma razão para usar o esquema conceituai como a interface é reduzir o número 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 número de programas de mapeamento é reduzido drasticamente. M ESQUEMAS EXTERNOS

ESQUEMA EXTERNO Nº1

ESQUEMA EXTERNO Nº 2

ESQUEMA EXTERNO Nº M

ESQUEMA INTERNO Nº1

ESQUEMA INTERNO Nº2

ESQUEMA INTERNO Nº N

TRADUÇÕES

N ESQUEMAS INTERNOS

Figura 13 Tradução entre esquemas externos e esquemas internos sem um esquema conceituai.

16

Modelagem de Dados M ESQUEMAS EXTERNOS

ESQUEMA EXTERNO Nº 1

ESQUEMA EXTERNO Nº 2

ESQUEMA EXTERNO

NºM

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 estável, permitindo mudanças nos esquemas externos e internos. Esta meta não parece difícil de ser atingida, uma vez que o esquema conceituai representa a visão da empresa quanto aos dados e deve ser relativamente estável em comparação à visão do usuário quanto à visão física dos dados. Portanto, quando a organização física do banco de dados é alterada ou os dados são transportados de dispositivos de armazenamento "antigos" para dispositivos de armazenamento "novos", apenas alteramos o esquema interno, e não o esquema conceituai ou os esquemas externos. Similarmente, se um usuário quiser ver os dados como um certo tipo de organização, podemos projetar um esquema externo para ele sem mudar o esquema conceituai e os esquemas internos. A não 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 método entidade-relacionamento para projeto lógico de bancos de dados 17

para descrever o esquema conceituai. Além disso, uma vez que os esquemas externos podem ser expressos em termos de diferentes tipos de estruturas de dados, tais como rede (CODASYL), hierárquica ou relacionai (ver Figura 15), as regras de tradução entre diagramas E-R e diferentes tipos de estruturas de dados discutidos adiante nesta obra seriam muito úteis na implementação da arquitetura ANSI/X3/SPARC. REDE

HIERÁRQUICA

RELACIONAL

ESQUEMAS EXTERNOS

ESQUEMA CONCEITUAL

ESQUEMA INTERNO

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

2.3 TRÊS TIPOS DE ADMINISTRADORES DE BANCOS DE DADOS O grupo ANSI/X3/SPARC identificou três 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 possível, o valida. Ele deve compreender muito bem as operações da empresa e o significado de suas informações (dados). Ele é responsável pelo conteúdo, integridade e segurança do banco de dados. 2. Administrador de banco de dados O administrador de banco de dados define o esquema interno. Ele projeta as estruturas físicas de dados, codificando esquemas, vias de acesso e colocação de dados em dispositivos de armazenamento. Ele é responsável pela utilização eficiente do espaço de armazenamento, assim como pelo desempenho do sistema de banco de dados. 3. Administrador de aplicação Um esquema externo representa uma visão dos dados pelo programador de aplicação. Imagina-se que cada área geral de aplicação terá seu próprio administrador de aplicação que provê os esquemas externos para aquela área. Mas esses esquemas externos têm de ser consistentes e deriváveis de um único esquema conceituai. Observe que os mesmos esquemas externos podem ser usados por vários programadores de aplicação, não necessariamente trabalhando no mesmo programa. Estes três tipos de administradores representam três diferentes papéis que podem ser desempenhados por um indivíduo ou um grupo de pessoas. Embora as distinções entre esses três tipos de administradores de banco de dados sejam claras em termos da arquitetura de três esquemas do ANSI/X3/SPARC, não são claras nos ambientes de bancos de dados convencionais. Na verdade, o "administrador de banco de dados", como é definido hoje em dia em muitas organizações, tem todas as responsabilidades dos três 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 aplicação (ou seja, a tarefa de projetar os esquemas externos).

O método entidade-relacionamento para projeto lógico de bancos de dados

19

2.4 RELEVÂNCIA DO MÉTODO E-R Em suma, se a arquitetura ANSI/X3/SPARC tornar-se realidade, o método E-R pode ser usado das seguintes maneiras: 1. No projeto do esquema conceituai. 2. Na tradução do esquema conceituai em esquemas externos.

20

Modelagem de Dados

3. DIAGRAMA DE ENTIDADERELACIONAMENTO (E-R) Neste capítulo, vamos introduzir a técnica diagramática de entidade-relacionamento. Discutiremos primeiro o que são entidades e relacionamentos e, então, 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 FUNCIONÁRIO e ACIONISTA. (Ver Figura 16.) No diagrama E-R, um tipo de entidade é representado por um retângulo. (Ver Figura 17.)

FUNCIONÁRIO

Figura 16 Entidades e tipos de entidades.

ACIONISTA

O método entidade-relacionamento para projeto lógico de bancos de dados

FUNCIONÁRIO

21

ACIONISTA

Figura 17 Tipos de entidades são representados por retângulos.

Há muitas "coisas" no inundo real. Algumas delas são de interesse para a empresa, e o resto não. É responsabilidade do projetista de banco de dados selecionar os tipos de entidade que são 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-FÜNC e PROJ-GERENTE são dois tipos de relacionamentos diferentes entre dois tipos de entidades, PROJ (projeto) e FUNC (funcionário). Na notação diagramática de entidade-relacionamento, um tipo de relacionamento é representado por um losango com linhas conectadas a tipos de entidades relacionadas. (Ver Figura 19.) As notações "m" e "1" associadas ao tipo de relacionamento PROJ-GERENTE na Figura 16 indicam que cada projeto tem apenas um gerente, mas que um funcionário 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 vários funcionários e cada funcionário pode estar associado a mais de um projeto. Observe que outros tipos de mapeamento entre entidades também são possíveis. Por exemplo, o tipo de relacionamento CASAMENTO é um mapeamento um-para-um entre entidades humanas. (Ver Figura 20.) É possível definir um tipo de relacionamento entre mais de dois tipos de entidades. Por exemplo, PARTE-FORN-PROJ, que descreve que partes são abastecidas por fornecedores específicos para projetos específicos (Figura 21), é um tipo de relacionamento definido em três 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

FUNC

PROJ

PROJ-FUNC

Figura 19 Tipos de relacionamentos são representados por losangos.

PESSOA

CASAMENTO

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

O método entidade-relacionamento para projeto lógico de bancos de dados

Figura 21

Nº PARTE

Nº FORNECEDOR

Nº PROJ

25

4

1

25

5

2

10

4

2

10

4

3

17

2

1

17

5

1

23

Informações sobre relacionamentos PARTE-FORN-PROJ.

PARTE

FORN PARTE FORNPROJ

PROJ

Figura 22

PARTE-FORN-PROJ como um tipo de relacionamento.

Note que um relacionamento ternário usualmente não pode ser substituído por três relacionamentos binários. Por exemplo, o relacionamento ternário PARTE-FORN-PROJ na Figura 21 é substituído por três relacionamentos binários: PARTE-FORN, FORN-PROJ e PROJ-PARTE. (Ver Figura 23.) Contudo, se quisermos construir o relacionamento ternário partindo desses três relacionamentos binários, obteremos alguns "não-fatos". (Ver as entradas com asteriscos na Figura 24.) Há muitos tipos de relacionamentos entre entidades e alguns deles são de interesse para a empresa: o projetista de banco de dados é responsável pela seleção dos tipos de relacionamentos relevantes para a empresa. Ele deve também 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

Nº FORN

Nº FORN

Nº PROJ

NºPROJ

Nº PARTE

25

4

4

1

1

25

25

5

4

2

1

17

10

4

4

3

2

10

2

25

3

10

17

2

5

1

17

5

5

2

2

1

Figura 23 Informações sobre três relações binárias: PARTE-FORN, FORN-PROJ e PROJ-PARTE.

* *

Nº PARTE

Nº FORN

Nº PROJ

25

4

1

25

4

2

25

5

1

25

5

2

10

4

2

10

4

3

17

2

1

17

5

1

Figura 24 Informações geradas das três relações binárias da Figura 23.

3.2 DESCRIÇÃO DE ENTIDADES E RELACIONAMENTOS 3.2.1 Atributos e Valores Entidades e relacionamentos têm propriedades que podem ser expressas em termos de pares atributo-valor. Por exemplo, na afirmação "a IDADE DO FUNCIONÁRIO x é 24", "IDADE" é um atributo do funcionário x e "24" é o valor do atributo "IDADE". Os valores podem ser

O método entidade-relacionamento para projeto lógico de bancos de dados

25

classificados em diferentes tipos de valor, tais como Nº DE ANOS, QUANTIDADE e COR. Na notação diagramática E-R, um tipo de valor é representado por vim círculo (ver Figura 25) e um atributo é representado por um ponteiro dirigido do tipo de entidade para o tipo de valor desejado.

FUNCIONÁRIO

Nº DO CIC

F i g u r a 25

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

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 funcionário x pode ter dois valores: 253-6606 e 253-9999. Neste caso, colocamos "l:n" no ponteiro para indicar que é um atributo de valores múltiplos. Isto é similar ao conceito de "grupo de repetição" em processamento de dados convencional. Contudo, muitos atributos, tais como "IDADE" e "Nº DO CIC", têm um só valor. Para simplicidade, não 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 também interessados nas propriedades de um relacionamento. Por exemplo, podemos querer saber quando o funcionário x começou a trabalhar em um determinado projeto. A DATA DE INÍCIO não é um atributo do FUNCIONÁRIO nem do PROJ, uma vez que seu valor depende tanto do funcionário específico quanto do projeto envol-

26

Modelagem de Dados

vido. Portanto, a DATA DE INÍCIO é um atributo do relacionamento PROJ-FUNC. Um outro exemplo de atributo do relacionamento é a PORCENTAGEM DE ESFORÇO, que é a porcentagem de tempo que um funcionário devota a um determinado projeto. (Ver Figura 26.) O conceito de atributo de relacionamento é importante para compreender a semântica 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 intersecção em sistemas de bancos de dados do tipo hierárquico (tipo IMS).

PROJFUNC

PROJ

DATA DE INÍCIO

FUNC

PORCENTAGEM DE ESFORÇO

9/15/75 7/22/76

20% 30% 90%

DATA DE INÍCIO PORCENTAGEM DE ESFORÇO Figura 26

Atributos de relacionamento.

3.2.2 Identificador de Entidade As entidades discutidas até agora são aquelas que existem em nossas mentes ou podem ser identificadas com um apontar de dedo. Quando alguém 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 identificação pode funcionar para muito poucos objetos, porém encontraremos dificuldades quando quisermos comunicar a informação 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 método entidade-relacionamento para projeto lógico 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 funcionários em uma pequena companhia, mas não em uma grande firma. Esses atributos escolhidos da entidade são chamados de identificadores de entidade. Em alguns casos, pode ser difícil ou inconveniente usar os atributos disponíveis como identificadores da entidade. O que podemos fazer é criar um atributo artificial que possa identificar incontestavelmente as entidades. Exemplos são Nº DO CIC, Nº DO FUNC, Nº DA PARTE e Nº DO PROJ. O conceito de identificador de entidade é similar ao conceito de chave primária em processamento de dados convencional.

3.2.3 Identificador de Relacionamento Os relacionamentos são identificados pelo uso de identificadores das entidades envolvidas no relacionamento. Por exemplo, se um projeto é identificado por seu Nº DO PROJ e um funcionário é identificado por Nº DO FUNC, então o relacionamento PROJ-FUNC é identificado por ambos os Nº DO PROJ e nº DO FUNC. Em algumas situações, um tipo de relacionamento é definido entre duas ocorrências do mesmo tipo de entidade. Por exemplo, CASAMENTO é um tipo de relacionamento definido entre ocorrências do mesmo tipo de entidade, PESSOAS. Para identificar inequivocamente tais relacionamentos, usamos não apenas o identificador de entidade, mas também 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 são os "papéis" que eles desempenham na relação CASAMENTO. 3.3 TIPOS ESPECIAIS DE ENTIDADE E RELACIONAMENTO Nesta seção, vamos discutir alguns tipos especiais de entidade e relacionamento que são comumente encontrados.

28

Modelagem de Dados

3.3.1 Existência-Dependente A existência de uma entidade pode depender da existência de um outro tipo de entidade. Por exemplo, a existência de entidades FILHOS no banco de dados depende da existência dos funcionários associados. Em outras palavras, se um funcionário deixa a companhia, não precisamos manter o registro de seus filhos. A Figura 27 ilustra o diagrama E-R para essa situação. FILHOS é representado por um retângulo duplo, o que significa que é um tipo de entidade "fraca". A existência de uma entidade fraca depende da existência de outras entidades. O "E" dentro do losango do relacionamento indica que é um relacionamento existência-dependente; o ponteiro associado ao losango do relacionamento indica a direção da dependência. E possível que o relacionamento existência-dependente seja um mapeamento muitos-para-muitos. Por exemplo, se o pai deixa a companhia, as entidades FILHOS podem ainda existir se a mãe continuar sendo uma funcionária da companhia. Esta situação é representada no diagrama E-R mostrado na Figura 28.

FUNC

E

FILHOS

Figura 27 Um relacionamento de tipo existência-dependente e um tipo de entidade fraca.

O método entidade-relacionamento para projeto lógico de bancos de dados

29

FUNC M (PELO MENOS 1)

E

FILHOS

Figura 28 Uma relação existência-dependente pode ser também um mapeamento muitos-para-muitos.

3.3.2 Dependência de Identificador (ID) Se uma entidade não puder ser identificada inequivocamente por seus próprios atributos e tiver de ser identificada por seus relacionamentos com outras entidades, ela tem dependência de identificador com as outras entidades. Por exemplo, "rua" só é específica dentro de uma cidade, uma cidade só é específica dentro de um Estado, e um Estado só é específico dentro de um país. Para identificar precisamente o endereço de uma localização, temos de especificar os nomes da cidade, Estado e país, além do nome da rua. Á dependência de identificador é indicada pelo "ID" no losango de relacionamento, e a direção do relacionamento é indicada pelo ponteiro (Ver Figura 29); a maioria das dependências ID está associada a existências-dependentes. Contudo, a existênciadependente não implica a dependência ID. Por exemplo, as entidades FILHOS na Figura 30 são identificadas com seus próprios atributos e o ID de seus pais (ver Figura 31), enquanto as entidades FILHOS na Figura 27 podem ser identificadas por seus próprios Nº DO FILHO. (Ver Figura 32.)

30

Modelagem de Dados

PAÍS

E&

ESTADO

E& ID

CIDADE

E& ID

RUA

Figura 29 Existência-dependente e Dependência ID.

O método entidade-relacionamento para projeto lógico de bancos de dados

FUNC

FILHOS

Figura 30 Existência-dependente e Dependência ID.

ID DOS FILHOS

D ADOS SOBRE FILHOS

ID DO FUNC NOME

CIC DO PAI OU MÃE

IDADE

SEGURO-SAÚDE

NANCY BOK

013-58-5545

12

BC/BS

LAWRENCE BOK

172-66-6672

5

BC/BS

ROBERT JOHNSON

819-38-7776

21

TEM PLANO PRÓPRIO

Nº DOS FILHOS

NOME

IDADE

SEGURO-SAÚDE

1011

NANCY BOK

12

BC/BS

1025

LAWRENCE BOK

5

BC/BS

1044

ROBERT JOHNSON

21

TEM PLANO PRÓPRIO

Figura 31 Dependência ID.

ID DOS FILHOS

Figura 32 Sem Dependência ID.

31

32

Modelagem de Dados

4. TRADUÇÃO DE DIAGRAMAS E-R EM DIAGRAMAS DE ESTRUTURA DE DADOS 4.1 DIAGRAMAS DE ESTRUTURA DE DADOS As estruturas lógicas 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 retângulo 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 proprietário 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 proprietário de registro e DEPENDENTE é o tipo membro de registro. Em um conjunto de estrutura de dados, o registro proprietário pode ter zero, um ou mais registros membros (ocorrências). Um registro membro em um conjunto de estrutura de dados tem exatamente um registro proprietário. Em nosso exemplo, cada registro de funcionário 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 associação l:n (um-para-muitos) entre o tipo proprietário de registro e o tipo membro de registro. Este tipo de associação pode também ser representado em forma de tabela. (Ver Figura 35.)

FUNC

TIPO "PROPRIETÁRIO" DE REGISTRO CONJUNTO DE ESTRUTURA DE DADOS

DEPENDENTE

TIPO "MEMBRO" DE REGISTRO

Figura 33 Um diagrama de estrutura de dados.

O método entidade-relacionamento para projeto lógico de bancos de dados

FUNC 2142

Nº DO FUNC

(A) ZERO DEPENDENTE

FUNC 2566

FUNC 1781

DEP A

33

DEP C

DEP B

(B) TRÊS DEPENDENTES

DEP D

(C) UM DEPENDENTE

Figura 34 Um registro PROPRIETÁRIO pode ter zero, um ou mais registros "membros*. Nº DO FUNC

DEPENDENTE

1781

A

1781

B

1781

C

2566

D

Figura 35 Correspondência um-para-muitos entre FUNCIONÁRIO e DEPENDENTES.

A Figura 36 ilustra uma estrutura de dados mais complicada. O tipo de registro FUNCIONÁRIO é o registro proprietário de um conjunto de estrutura de dados no qual FUNCIONÁRIO-HABILIDADE é o registro membro. O tipo de registro FUNCIONÁRIO-HABILIDADE é também o registro membro de um outro conjunto de estrutura de dados no qual o tipo de registro HABILIDADE é o registro proprietário. Na verdade, o registro FUNCIONÁRIO-HABILIDADE contém a informação sobre FUNCIONÁRIOS e HABILIDADES. Esse tipo de informação pode ser representado na forma de tabela, como é mostrado na Figura 37. Podemos ver na Figura 37 que um funcionário pode ter uma ou mais habilidades e que usualmente mais de um funcionário tem uma habilidade específica. Portanto, a relação entre funcionários e habilidades é m:n (muitos-para-muitos). Essa correspondência m:n entre funcionários 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 FUNCIONÁRIO e o tipo de registro FUNCIONÁRIO-HABILIDADE, e que um mapeamento semelhante (l:n) existe entre o tipo de registro HABILIDADE e o tipo de registro FUNC-HABILIDADE. Portanto, a correspondência 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 têm o mesmo tipo "membro" de registro.

Nº DO FUNC

HABILIDADE

2142

COBOL

2141

PL/1

1781

COBOL

2566

PL/1

Figura 37 Informações cruzadas sobre FUNCIONÁRIOS 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 contínuas, 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 método entidade-relacionamento para projeto lógico de bancos de dados

35

Na Figura 38, como determinamos as habilidades de um funcionário específico? O primeiro passo é localizar o registro de FUNC com o Nº DO FUNC = 2142, usando um algoritmo hashing ou algum outro método. O segundo passo é encontrar o primeiro registro FUNC-HABILIDADE relacionado com esse funcionário. Por meio do ponteiro mostrado pela linha pontilhada, podemos encontrar um registro de habilidade com HABILIDADE-NOME = COBOL. Encontramos, então, o segundo registro FUNCIONÁRIO-HABILIDADE relacionado com o mesmo registro de funcionário (por meio dos ponteiros de linha contínua). Do registro FUNC-HABILIDADE, podemos seguir por intermédio do ponteiro de linha pontilhada para localizar um registro HABILIDADE com HABILIDADE-NOME = PL/1. Não conseguimos, então, encontrar mais nenhum registro FUNC-HABILIDADE relacionado com os mesmos registros de FUNCIONÁRIO (ou seja, encontramos a informação de que necessitávamos: o funcionário com Nº DO FUNC = 2142 tem duas habilidades: COBOL e PL/1).

FUNC 2142

FUNC 1781

FUNCHABILIDADE

FUNCHABILIDADE

HABILIDADE COBOL

FUNC 2586

FUNCHABILIDADE

FUNCHABILIDADE

HABILIDADE PL/1

Figura 38 Implementação dos conjuntos de estrutura de dados da Figura 37 como conjuntos de ponteiros.

Como encontramos todos os funcionários com uma habilidade específica, digamos, COBOL? Primeiro, localizamos o registro HABILIDADE com HABILIDADE-NOME = COBOL. Então, recuperamos todos os registros FUNC-HABILIDADE relacionados com o registro HABILIDADE. Para cada registro FUNCIONÁRIO-HABILIDADE, recuperamos, por meio do ponteiro de linha contínua, o registro FUNC correspondente. Fazendo isso, sabemos que há dois funcionários com a habilidade COBOL, e seus números são 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 contínuas conectam todos os registros FUNC-HABILIDADE relacionados com o mesmo registro HABILIDADE. Vamos ver como encontrar as habilidades do funcionário com Nº DO FUNC = 2142. Em primeiro lugar, encontramos o primeiro registro FUNC-HABILIDADE por intermédio da cadeia de linha contínua. 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 sólida. Do segundo registro FUNC-HABILIDADE, podemos determinar o registro de habilidade correspondente por meio da cadeia de linha pontilhada. Do segundo registro FUNC-HABILIDADE, não conseguimos encontrar mais nenhum registro FUNC-HABILIDADE na cadeia de linha contínua. Agora, sabemos todas as habilidades que o funcionário 2142 tem. Similarmente, podemos encontrar todos os funcionários com uma determinada habilidade seguindo através das cadeias.

FUNC 1781

FUNC 2142

FUNCHABILIDADE

FUNCHABILIDADE

COBOL

FUNC 2566

FUNCHABILIDADE

FUNCHABILIDADE

PL/1

Figura 39 Implementação 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 produção, é mostrado na Figura 40. Há dois tipos de registro: PARTE e PRD-REL (produção-relacionamento). Cada produto a ser fabricado consiste em muitas "partes" (componentes). Cada parte, por sua vez, é feita de outras partes. O tipo

O método entidade-relacionamento para projeto lógico de bancos de dados

37

de registro PARTE contém informações sobre a parte específica. 0 tipo de registro PRD-REL contém as informações sobre o relacionamento entre as partes. A Figura 41 ilustra esse tipo de relacionamento. Indica que, para produzir a PARTE Nº1, precisamos de cinco PARTES Nº 2e duas PARTES Nº 3. Podemos ver também que a PARTE Nº 3 é uma subparte tanto da PARTE Nº1 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 contínuas representam a cadeia COMPONENTE e as linhas pontilhadas representam a cadeia ONDE USADA. Para encontrar os componentes de uma parte específica, primeiro recuperamos todos os registros PRD-REL por meio da cadeia COMPONENTE e, então, 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 específica é usada para produzir outras partes, primeiro recuperamos todos os registros PRD-REL relacionados com esse registro PARTE específico por intermédio da cadeia ONDE USADA, e então recuperamos os registros PARTE correspondentes por meio da cadeia COMPONENTE. Fazendo isso, descobrimos que duas PARTES Nº 5 são usadas na fabricação da PARTE Nº 4. As Figuras 33, 36 e 40 são os tipos básicos de diagramas de estrutura de dados. Um banco de dados pode ser expresso em um grande diagrama de estrutura de dados baseado nesses três modelos básicos.

PARTE COMPONENTES

ONDE USADA

PRD-REL

Figura 40 Dois conjuntos de estrutura de dados têm os mesmos tipos de registro "proprietário" e "membro".

38

Modelagem de Dados

SUPERPARTE Nº

SUBPARTE Nº

QUANTIDADE

1

2

5

1

3

2

4

3

1

4

5

2

Figura 41 Relação de fabricação entre partes.

PARTE Nº 4

PARTE Nº 1 CADEIA COMPONENTE

CADEIA COMPONENTE

PRD-REL

CADEIA ONDE usada PARTE Nº 2

PRD-REL

PRD-REL

CADEIA ONDE USADA PARTE Nº 3

PRD-REL

2

CADEIA ONDE USADA PARTE Nº 5

Figura 42 Implementação dos conjuntos de estrutura de dados da Figura 41.

4.2 REGRAS DE TRADUÇÃO Como vimos na seção anterior, o diagrama de estrutura de dados está mais próximo da organização física do banco de dados que o diagrama de entidade-relacionamento. Usualmente, é difícil desenhar um diagrama de estrutura de dados para as entidades e relacionamentos que são de interesse para a empresa. Portanto, propomos que o projetista de banco de dados primeiro desenhe um diagrama E-R para representar a visão da empresa quanto aos dados e, então, traduza-o para um diagrama de estrutura de dados. Nesta seção, vamos discutir como traduzir um diagrama E-R para um diagrama de estrutura de dados. Identificamos algumas regras básicas para tradução com base no tipo de

O método entidade-relacionamento para projeto lógico de bancos de dados

39

relacionamentos entre entidades. Começamos 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 tradução são as seguintes: 1. Relacionamentos definidos por dois tipos diferentes de entidades: a) O relacionamento é uma correspondência um-para-muitos (ou um-para-um). Por exemplo, o tipo de relacionamento DEPT-FUNC na Figura 43 (a) é uma correspondência 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 são 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 vários projetos com o mesmo gerente, é representado por um ponteiro no diagrama de estrutura de dados mostrado na Figura 44 (b).

DEPT

DEPT

DEPT fUNC

Figura 43

FUNC

FUNC

DIAGRAMA E-R

DIAGRAMA DE ESTRUTURA DE DADOS

40

Modelagem de Dados

FUNC

FUNC

PROJGERENTE

PROJ

PROJ

DIAGRAMA E-R

DIAGRAMA DE ESTRUTURA DE DADOS

Figura 44

b) O relacionamento é uma correspondência muitos-para-

muitos. Por exemplo, o tipo de relacionamento PROJ-FUNC na Figura 45 (a) é uma correspondência muitos-para-muitos. O diagrama de estrutura de dados correspondente é mostrado na Figura 45 (b). Note que o tipo de relação PROJ-FUNC não é traduzido em um ponteiro, mas em um tipo de registro. Podemos concluir que, se um tipo de relacionamento é uma correspondência 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 correspondência muitos-paramuitos, é traduzido em um tipo de registro (de relacionamento) no diagrama de estrutura de dados.

o método entidade-relacionamento para projeto lógico de bancos de dados (b)

(a) PROJ

41

PROJ

FUNC

PROJ FUNC PROJ-FUNC FUNC DIAGRAMA E-R

DIAGRAMA DE ESTRUTURA DE DADOS

Figura 45

FUNC

HABILIDADE

FUNC

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 correspondência 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 três tipos de entidades e será traduzido em um tipo de registro no diagrama de estrutura de dados, como é mostrado na Figura 47 (b).

PROJ

PARTE

PARTEPROJ FORN'

FORN DIAGRAMA E-R

PARTE

PROJ

FORN

PARTE-PROJ-FORN DIAGRAMA DE ESTRUTURA DE DADOS

Figura 47

3. Relacionamentos binários definidos pelo mesmo tipo de entidade: Se o relacionamento binário for uma correspondência um-paramuitos, tal como o tipo de relacionamento GERENCIADO na Figura 48 (a), ele poderá ser transformado em pelo menos dois possíveis 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 método entidade-relacionamento para projeto lógico de bancos de dados

43

não permite que o mesmo tipo de registro seja usado tanto como tipo de registro proprietário quanto como tipo de registro membro de um conjunto de estrutura de dados, a Figura 48 (b) não é válida. Portanto, usaremos a Figura 48 (c) como o diagrama de estrutura de dados relativo ao diagrama E-R na Figura 48 (a). Para relacionamentos binários com outros tipos de correspondência, usaremos o mesmo tipo de diagrama de estrutura de dados. Por exemplo, PRD-REL é um relacionamento de tipo de correspondência muitos-para-muitos e seu diagrama de estrutura de dados equivalente é mostrado na Figura 49 (b).

PESSOA

PESSOA

PESSOA