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.


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-


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


9

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

MUNDO REAL

HIERÁRQUICA


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-


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


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.


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


ESQUEMA CONCEITUAL

ESQUEMA INTERNO

DISPOSITIVOS DE ARMAZENAMENTO

Figura 12

Arquitetura ANSI/X3/SPARC.


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


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


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.


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


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-


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.


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.


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.


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


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


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


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


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


Figura 45

FUNC

HABILIDADE

FUNC

FUNC HABILIDADE* FUNCHABILIDADE HABILIDADE DIAGRAMA E-R


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)


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

GERENCIADO DIAGRAMA DE ESTRUTURA DE DADOS

DIAGRAMA E-R F i g u r a 48

Figura 49

PARTE

PARTE

PRD-REL

PRD-REL

44

Modelagem de Dados

5. ETAPAS NO PROJETO LÓGICO DE BANCO DE DADOS E EXEMPLOS Nesta seção, vamos primeiro apresentar as principais etapas no projeto lógico de bancos de dados e, então, dar três exemplos de projetos de bancos de dados usando o método E-R. 5.1 PRINCIPAIS ETAPAS NO PROJETO LÓGICO DE BANCOS DE DADOS O método de entidade-relacionamento para projeto de bancos de dados consiste nas seguintes etapas: 1. Identificar tipos de entidades. 2. Identificar tipos de relacionamentos. 3. Desenhar um diagrama E-R com tipos de entidade e relacionamentos. 4. Identificar tipos de valor e atributos. 5. Traduzir o diagrama E-R em um diagrama de estrutura de dados. 6. Projetar formatos de registros. 5.2 EXEMPLO 1: UMA INDÚSTRIA 5.2.1 Identificar Tipos de Entidades A primeira etapa é identificar os tipos de entidade que interessam à companhia. Em uma indústria, os tipos de entidade primários são PARTE, FORN (fornecedor), PROJ, FUNC e DEPT. Há outros tipos


45

de entidades que podem ser de interesse em uma indústria, mas, por motivo de simplicidade, vamos nos concentrar nestes importantes tipos de entidade. 5.2.2 Identificar Tipos de Relacionamento Podemos identificar pelo menos os seguintes tipos de relacionamento (Ver Figura 50): DEPT

FORN FORN POTENCIAL PROP FORN

DEPT FUNC

PARTE

PROJFUNC PROJ

FUNC PROJGERENTE

PARTE M

INVENTÁRIO

DEPÓSITO

N

PRD-REL

Figura 50 Um diagrama E-R para uma indústria.

a) O tipo de relacionamento DEPT-FUNC descreve a associação do departamento com os funcionários e é um mapeamento um-para-muitos. 6) O tipo de relacionamento PROJ-FUNC descreve a associação dos projetos com os funcionários e é um mapeamento muitospara-muitos. Isto é, cada funcionário pode trabalhar em mais de um projeto, e cada projeto pode envolver mais de um funcionário. c) O tipo de relacionamento PROJ-GERENTE identifica os gerentes dos projetos e é um mapeamento um-para-muitos. Isto

46

Modelagem de Dados

é, cada projeto tem apenas um gerente, mas cada funcionário pode estar associado a mais de um projeto. d) O tipo de relacionamento PROJ-FORN-PARTE descreve qual fornecedor fornece qual parte para um determinado projeto e é um mapeamento ternário muitos-para-muitos-para-muitos. Isto é, para uma parte específica, pode haver mais de um fornecedor, que pode fornecer essa parte para mais de um projeto. Similarmente, cada projeto pode usar mais de uma parte, que pode ter mais de um fornecedor. Também, cada fornecedor pode prover um projeto com mais de uma parte. Uma razão para a companhia querer procurar fornecedores diferentes para a mesma parte usada para diferentes projetos é que, em um determinado projeto, a companhia talvez necessite da parte imediatamente e, portanto, pode estar disposta a pagar mais por ela a um fornecedor local. Em geral, esse tipo de relação ternária não pode ser substituído por três relações binárias como PROJ-FORN, FORN-PARTE e PARTE-PROJ. e) O tipo de relação FORN POTENCIAL mantém uma lista de fornecedores potenciais de uma determinada parte e é um mapeamento muitos-para-muitos. Isto é, cada parte pode ter mais de um fornecedor potencial, e cada fornecedor pode ser capaz de fornecer mais de uma parte. f) O tipo de relação INVENTARIO mantém um registro de que parte está estocada em qual depósito e é um mapeamento muitos-para-muitos. 5.2.3 Desenhar um Diagrama E-R com Tipos de Entidade e Relacionamento A terceira etapa é desenhar um diagrama E-R com os seis tipos de entidade e as sete tipos de relacionamento mencionados. Certamente, podemos identificar outros tipos de entidade e relacionamentos além dos descritos acima. Contudo, uma vez que nosso propósito é introduzir


47

conceitos-chaves do método entidade-relacionamento, não entraremos em maiores detalhes. o leitor desta monografia pode acrescentar mais tipos de entidades e relações à Figura 50, de acordo com suas próprias necessidades.

5.2.4 Identificar Tipos de Valores e Atributos A quarta etapa é identificar as propriedades de entidades e relacionamentos que sejam de interesse para a empresa. Isto é, queremos identificar atributos e tipos de valor para as entidades e relacionamentos da Figura 50. Vamos começar com os tipos de entidade DEPT e FUNC e sua relação DEPT-FUNC. A Figura 51 ilustra os atributos e tipos de valor para DEPT e FUNC. Os tipos de entidade e de relacionamento estão no domínio conceituai superior e os atributos e tipos de valor estão no domínio conceituai inferior. Na Figura 51, identificamos os seguintes tipos de valor: Nº DO DEPT, ORÇAMENTO, Nº DO FUNC, DATA, SALÁRIO e Nº DO TELEFONE. O DEPT tem três atributos: Nº DO DEPT, ORÇAMENTO DESTE ANO e ORÇAMENTO DO ANO PASSADO. FUNC tem cinco atributos: Nº DO FUNC, DATA DE NASCIMENTO, SALÁRIO, TELEFONE RESIDENCIAL e TELEFONE COMERCIAL. Note que os atributos podem não ter os mesmos nomes que os tipos de valor, e que é possível ter mais de um atributo relacionado com o mesmo tipo de valor. Por exemplo, ORÇAMENTO DESTE ANO e ORÇAMENTO DO ANO PASSADO de DEPT usam o mesmo tipo de valor ORÇAMENTO. Um outro exemplo são os atributos TELEFONE COMERCIAL e TELEFONE RESIDENCIAL de FUNC que usam o mesmo tipo de valor Nº DO TELEFONE. Para simplificar o diagrama, vamos omitir os nomes de atributos no diagrama se esses forem os mesmos que os nomes dos tipos de valor. Assim, a Figura 52 é uma versão simplificada da Figura 51.

48

Modelagem de Dados

DOMÍNIO CONCEITUAL. SUPERIOR

DOMÍNIO CONCEITUAL INFERIOR

DEPT

Nº DO DEPT

Figura 51

DATA DE ORÇAMENTO DO ANO PASSADO INÍCIO DO DEPT

ORÇAMENTO DESSE ANO

Nº DO DEPT

ORÇAMENTO

FUNC

DEPT-FUNC,

Nº DO FUNC TELEFONE COMERCIAL

DATA DE NASCIMENTO

DATA

Nº DO FUNC

SALÁRIO

SALÁRIO

TELEFONE RESIDENCIAL

Nº DO TELEFONE

Atributos e tipos de valores para DEPT, FUNC e DEPT-FUNC.

Em seguida, vamos considerar os tipos de entidade PROJ e FUNC e seus tipos de relacionamento PROJ-GERENTE e PROJ-FUNC. Há cinco tipos de valor: % ESFORÇO, DATA, Nº DO PROJ, ORÇAMENTO e PROJ-NOME. Há também cinco atributos na Figura 53 (embora alguns nomes de atributos estejam omitidos no diagrama): % ESFORÇO, DATA DE INÍCIO DO PROJ, Nº DO PROJ, ORÇAMENTO e PROJNOME. Note que a relação PROJ-FUNC tem dois atributos: DATA DE INÍCIO DO PROJ e % ESFORÇO. A DATA DE INÍCIO DO PROJ é a data na qual o funcionário começou a trabalhar em um determinado projeto, e a % ESFORÇO é a porcentagem de tempo que um funcionário deve gastar em um determinado projeto. Note que o tipo de valor ORÇAMENTO é o mesmo que o tipo de valor ORÇAMENTO na Figura 52. Portanto, podemos dizer que os atributos podem nos ajudar a interpretar o significado de valores. A Figura 54 ilustra os tipos de valor e atributos para os tipos de entidade FORN e PARTE e os tipos de relação PROJ-FORN-PARTE e FORN POTENCIAL. A entidade FORN tem dois atributos: Nº DO FORN e ENDEREÇO. A entidade PARTE tem os atributos Nº DA PARTE, PESO e COR. A relação PROJ-FORN-PARTE tem o atributo QTD, que é a quantidade de uma determinada parte fornecida por um determinado fornecedor para um determinado projeto. A relação FORN POTENCIAL não tem atributo. Os atributos da entidade PROJ já foram mostrados na Figura 53.

o método entidade-relacionamento para projeto lógico de bancos de dados DOMÍNIO CONCEITUAL SUPERIOR

DEPT-FUNC

DEPT

FUNC

ORÇAMENTO DO DATA DE ANO PASSADO INÍCIO DO DEPT


ORÇAMENTO DESSE ANO

(Nº DO DEPT)

ORÇAMENTO

TELEFONE COMERCIAL TELEFONE RESIDENCIAL

DATA DE NASCIMENTO

DATA

Nº DO FUNC

49

SALÁRIO

NºDO TELEFONE

Figura 52 Uma versão simplificada da Figura 51.

PROJ GERENTE. PROJ

FUNC DOMÍNIO CONCEITUAL SUPERIOR

PROJFUNC

DATA DE INÍCIO DO PROJETO


ESFORÇO

DATA

Nº DO PROJ

ORÇAMENTO

PROJNOME

Figura 53 Atributos e tipos de valor para PROJ e PROJ-FUNC.

A Figura 55 mostra os atributos e tipos de valor das propriedades da entidade DEPÓSITO e das relações INVENTÁRIO e PRD-REL. Uma entidade DEPÓSITO tem os atributos Nº DO DEPÓSITO e ENDEREÇO. Um relacionamento INVENTÁRIO tem os atributos QTD-ÀMÃO, que é a quantidade de uma parte estocada em um depósito. O relacionamento PRD-REL tem o atributo QTD-PARA-PRD, que é a quantidade de uma subparte necessária para fazer uma superparte. Note que QTD-À-MÃO e QTD-PARA-PRD têm o mesmo tipo de valor QTD.

50

Modelagem de Dados

PROJ

PARTE

PROJFORNPARTE, DOMÍNIO CONCEITUAL SUPERIOR

FORN POTENCIAL

FORN


Nº DO FORN

QTD

Figura 54

ENDEREÇO

PESO

COR

Atributos e tipos de valor para FORN, PARTE e PROJ-FORN-PARTE.

DOMÍNIO CONCEITUAI. SUPERIOR

DEPÓSITO

INVENTARIO


PARTE

QTD-A-MÃO

Nº DO DEPÓSITO

Figura 55

N«DA PARTE

ENDEREÇO

PRD-REL

QTD-PARA-PRD

QTD

Atributos e tipos de valor de DEPÓSITO, INVENTÁRIO e PRD-REL.

As Figuras 52-55 ilustram os atributos e tipos de valor necessários para descrever as propriedades de entidades e relacionamentos que podem ser de interesse para uma ir indústria.


51

5.2.5 Traduzir o Diagrama E-R em um Diagrama de Estrutura de Dados A quinta etapa é traduzir o diagrama E-R em um diagrama de estrutura de dados usando as regras de tradução discutidas na Seção 4.2. Considere o diagrama E-R da Figura 50. Ele pode ser traduzido no diagrama de estrutura de dados mostrado na Figura 56. Todos os tipos de entidade no diagrama E-R tornam-se tipos de registro no diagrama de estrutura de dados. Uma vez que o relacionamento DEPTFUNC é um mapeamento um-para-muitos, ele é traduzido em um conjunto de estrutura de dados (ou seja, um ponteiro) no diagrama de estrutura de dados. Similarmente, o tipo de relação PROJ-GERENTE é também um mapeamento um-para-muitos e é traduzido em um conjunto de estrutura de dados. Uma vez que o tipo de relacionamento PROJFUNC é um mapeamento muitos-para-muitos, ele é traduzido em um tipo de registro com ponteiros apontando para tipos de registros de entidades relacionados, FUNC e PROJ. Como o tipo de relação PROJFORN-PARTE é um mapeamento ternário muitos-para-muitos-paramuitos, ele é traduzido em um tipo de registro.O tipo de relação PRD-REL é traduzido em um tipo de registro, uma vez que é um tipo de relação definido pelo mesmo tipo de entidade. Note que o tipo de registro PRD-REL na Figura 42 tem dois ponteiros (ou seja, conjuntos de estrutura de dados) apontando do mesmo tipo de registro PARTE. Note também que o tipo de registro PROJ-FORN-PARTE é apontado por três ponteiros vindos dos tipos de registro (de entidade) relacionados. 5.2.6 Projetar Formato de Registro A sexta etapa é agrupar atributos de entidades e relacionamentos em registros e decidir como implementar os conjuntos de estrutura de dados (usando "cadeias"?, "conjuntos de ponteiros"? etc.) As orientações básicas para agrupar atributos em registros são:


52

Modelagem de Dados

1. Todos os atributos de uma entidade serão colocados no mesmo tipo de registro. Por exemplo, os atributos de DEPT serão tratados como nomes de campos no tipo de registro DEPT. (Ver Figuras 52 e 57.) 2. Se o tipo de relacionamento for um mapeamento um-paramuitos, os atributos do relacionamento serão tratados como campos no tipo de registro membro do conjunto de estrutura de dados. Por exemplo, o tipo de relacionamento DEPT-FUNC (Figura 52) é um mapeamento um-para-muitos e seu atributo DATA DE INÍCIO NO DEPT será incluído como um campo no tipo de registro membro do conjunto de estrutura de dados (ou seja, o tipo de registro FUNC; ver Figuras 56 e 58). DEPT

PROJ

FUNC

PROJ-FUNC

FORN

PROJ-FORN-PARTE

PARTE

DEPÓSITO

PRD-REL

INVENTÁRIO

FORN POTENCIAL

Figura 56 O diagrama de estrutura de dados derivado do diagrama E-R da Figura 50.

Nº DO DEPT

ORÇAMENTO DESTE ANO

ORÇAMENTO DO ANO PASSADO

PARA O PRIMEIRO REGISTRO FUNC NO DEPARTAMENTO

Figura 57 Registro DEPT.


53

PARA O REGISTRO FUNC SEGUINTE NO MESMO DEPARTAMENTO

N« DO FUNC

DATA DE DATA DE NASCIMENTO INlCIO NO DEP1

SALÁRIO

PARA O PRIMEIRO REGISTRO PROJ GERENCIADO POR ESTE FUNCIONÁRIO

TELEFONE TELEFONE | COMERCIAL RESIDENCIAL

PARA O PRIMEIRO REGISTRO FUNC-PROJ RELACIONADO COM ESTE FUNCIONÁRIO

Figura 58 Registro FUNC.

3. Se o tipo de relacionamento for traduzido em um tipo de registro, então os atributos de relacionamento serão tratados como campos nesse tipo de registro. Por exemplo, o tipo de relação PROJ-FUNC na Figura 53 é traduzido em um tipo de registro, e os atributos %ESFORÇO e DATA DE INÍCIO NO PROJ tornam-se campos no tipo de registro mostrado na Figura 60. Podemos aplicar essas regras a outros tipos de entidade e de relacionamento. Uma vez que todos os outros tipos de entidade e relacionamento, exceto PROJ-GERENTE, na Figura 50 são traduzidos diretamente em tipos de registro, o agrupamento de atributos em tipos de registro é direto. A Figura 53 é traduzida nas Figuras 59 e 60. Note que o tipo de relacionamento PROJ-GERENTE é traduzido em um conjunto estrutura de dados. A Figura 54 é traduzida nas Figuras 61-64; a Figura 55 é traduzida nas Figuras 65 e 66.

54

Modelagem de Dados PARA O PRÓXIMO REGISTRO PROJ GERENCIADO PELO MESMO FUNCIONÁRIO

Nº DO PROJ PROJ-NOME ORÇAMENTO

PARA O PRIMEIRO REGISTRO PROJ-FUNC RELACIONADO A ESTE PROJETO

PARA O PRIMEIRO REGISTRO PROJ-FORN-PARTE RELACIONADO A ESTE PROJETO

Figura 59 Registro PROJ. PARA O PRÓXIMO REGISTRO PROJ-FUNC PARA O MESMO FUNCIONÁRIO

DATA DE INÍCIO NO PROJ

% ESFORÇO

PARA O PRÓXIMO REGISTRO PROJ-FUNC PARA O MESMO PROJETO

Figura 60 Registro PROJ-FUNC

PARA O PRIMEIRO REGISTRO PARTE-FORN-PROJ RELACIONADO A ESTE FORNECEDOR

REGISTRO FORN.

ENDEREÇO

PARA O PRIMEIRO FORN POTENCIAL RELACIONADO A ESTE FORNECEDOR

Figura 61 Registro FORN.

o método entidade-relacionamento para projeto lógico de bancos de dados PARA O PRIMEIRO REGISTRO PARTE-FORN-PROJ RELACIONADO A ESTA PARTE

Nº DA PARTE

55

PARA O PRIMEIRO REGISTRO FORN POTENCIAL RELACIONADO A ESTA PARTE

PESO

COR

PARA O PRIMEIRO REGISTRO PRD-REL NA CADEIA ONDE-USADA

PARA O PRIMEIRO REGISTRO PRD-REL NA CADEIA COMPONENTE

PARA O PRIMEIRO REGISTRO INVENTÁRIO RELACIONADO A ESTA PARTE

Figura 62 Registro PARTE.

PARA O PRÓXIMO REGISTRO PARTE-FORN-PROJ PARA A MESMA PARTE

QTD

PARA O PRÓXIMO REGISTRO PARTE-FORN-PROJ PARA O MESMO FORNECEDOR PARA O PRÓXIMO REGISTRO PARTE-FORN-PROJ PARA O MESMO PROJETO

Figura 63 Registro PARTE-FORN-PROJ.

56

Modelagem de Dados PARA O PRÓXIMO REGISTRO FORN-POTENCIAL PARA A MESMA PARTE

PARA O PRÓXIMO REGISTRO FORN POTENCIAL PARA O MESMO FORNECEDOR

Figura 64

Registro FORN POTENCIAL.

Nº DO DEPÓSITO

ENDEREÇO

PARA O PRIMEIRO REGISTRO INVENTÁRIO RELACIONADO A ESTE DEPÓSITO

Figura 65

Registro DEPÓSITO.

PARA O PRÓXIMO REGISTRO INVENTÁRIO PARA A MESMA PARTE

QTD-À-MÃO

PARA O PRÓXIMO REGISTRO INVENTÁRIO PARA O MESMO DEPÓSITO

Figura 66

Registro INVENTÁRIO.

Após colocar todos os atributos nos tipos de registro, a questão seguinte é decidir como implementar os conjuntos de estrutura de dados. Neste exemplo industrial, vamos usar cadeias como a implementação física dos conjuntos de estrutura de dados. Isto é, vamos usar as Figuras


57

39 e 42 como a implementação física das Figuras 36 e 40, respectivamente. A partir dessas figuras, podemos fazer as seguintes observações sobre como implementar ponteiros de cadeia: 1. Se o registro for o tipo de registro proprietário de um conjunto de estrutura de dados, ele deve ter um ponteiro para a primeira ocorrência de registro membro. 2. Se o registro for um tipo de registro membro de um conjunto de estrutura de dados, ele deve ter um ponteiro para a ocorrência seguinte de registro membro na cadeia ou para a ocorrência de registro proprietário se este for o último registro na cadeia. 3. Se um tipo de registro estiver envolvido em múltiplos conjuntos de estrutura de dados, ele deve conter vários ponteiros, um para cada conjunto de estrutura de dados. Usando estas regras, podemos definir os ponteiros nos tipos de registro como é mostrado nas Figuras 57 e 66. Vamos considerar primeiro a Figura 57. Uma vez que o tipo de registro DEPT é o tipo de registro proprietário de um conjunto de estrutura de dados, ele tem um ponteiro apontando para a primeira ocorrência de registro FUNC naquele departamento. 0 tipo de registro FUNC na Figura 58 tem três ponteiros, uma vez que está envolvido em três conjuntos de estrutura de dados. Uma vez que o tipo de registro FUNC é o tipo de registro membro de um conjunto de estrutura de dados cujo proprietário é o tipo de registro DEPT, o tipo de registro FUNC manterá um ponteiro para a ocorrência seguinte de registro FUNC no mesmo departamento. Uma vez que o tipo de registro FUNC é o registro proprietário de um conjunto de estrutura de dados cujo tipo de registro membro é PROJ, ele mantém um ponteiro para a primeira ocorrência de registro PROJ gerenciada por esse funcionário. Se o funcionário não estiver gerenciando nenhum projeto, o valor do ponteiro será nulo. Uma vez que o tipo de registro FUNC é também o tipo de registro proprietário do conjunto de estrutura de dados cujo tipo de registro membro é PROJ-FUNC, ele mantém um ponteiro para a primeira ocorrência de registro PROJ-FUNC na cadeia.

58

Modelagem de Dados

Uma vez que PROJ-FUNC é o tipo de registro membro de dois conjuntos de estrutura de dados, ele mantém dois ponteiros: um apontando para a ocorrência seguinte do registro PROJ-FUNC para o mesmo funcionário e o outro apontando para a ocorrência seguinte do registro PROJ-FUNC para o mesmo projeto. (Ver Figuras 56 e 60.) Consideremos um caso mais complicado: o tipo de registro PROJFORN-PARTE nas Figuras 56 e 63. Uma vez que este é o tipo de registro membro de três conjuntos de estrutura de dados, tem três ponteiros, um para cada cadeia. Explicações semelhantes podem ser dadas para os ponteiros em outros tipos de registro. CLIENTE PEDIDO,

CLIENTE

PEDIDO

DEPÓSITO

INVENTARIO;

LINHA

LINHA PARTE

PARTE

Figura 67 Diagrama E-R para um banco de dados de anotação de pedidos.

CLIENTE PEDIDO

CLIENTE

.

Nº DO CLIENTE

SALDO DE CONTA

DESPACHO PARA ENDEREÇOS

LIMITE DE CRÉDITO

DESCONTO

PEDIDO

DESPACHO PARA ENDEREÇO

ENDEREÇO

Nº DO PEDIDO

Figura 68 Atributos e tipos de valor para CLIENTE e PEDIDO.

DATA


59

5.3 EXEMPLO 2: UM BANCO DE DADOS DE ANOTAÇÃO DE PEDIDOS DE COMPRA 5.3.1

Identificar Tipos de Entidade

Uma anotação de pedidos lida com os pedidos dos clientes em itens, os quais podem estar armazenados em determinados depósitos. Os tipos de entidade importantes são: CLIENTE, PEDIDO, LINHA, PARTE, ITEM e DEPOSITO. (Ver Figura 69.) Cada pedido tem várias linhas, cada uma declarando o número e a quantidade do item desejado. PEDIDO

LINHA PARTE

LINHA

QTD PEDIDA

Nº DA LINHA

Figura 69

PARTE

QTDA ENTREGAR

QTD

Atributos e tipos de valor para LINHA e LINHA-PARTE.

5.3.2 Identificar Tipos de Relacionamento Podemos identificar os seguintes tipos de relacionamento: 1. O tipo de relacionamento CLIENTE-PEDIDO descreve que CLIENTE faz um determinado pedido e é um mapeamento um-para-muitos. Isto é, um cliente pode fazer muitos pedidos, mas cada pedido é feito por apenas um cliente. 2. O relacionamento PEDIDO-LINHA indica que entidades LINHA são existências-dependentes e ID-dependentes das entidades PEDIDO correspondentes. Cada pedido tem várias linhas, mas cada linha faz parte de apenas um pedido.

60

Modelagem de Dados

3. A relação LINHA-PARTE descreve que parte é anotada nesta linha do pedido. Descreve também a quantidade da parte que está sendo pedida. Este tipo de relacionamento é um mapeamento um-para-muitos. Cada linha contém apenas uma parte, mas cada parte pode ser colocada em muitas linhas (usualmente em pedidos diferentes). 4. A relação INVENTÁRIO mantém o controle de que parte está estocada em qual depósito, e é um mapeamento muitos-paramuitos. 5.3.3 Desenhar um Diagrama E-R com Tipos de Entidade e Relacionamento A Figura 67 é um diagrama ER para um determinado banco de dados de anotação de pedidos de compra. Note que dois tipos de entidade, PARTE e DEPÓSITO, já foram discutidos no Exemplo 1. Na verdade, é possível fundir as Figuras 67 e 50, formando um grande diagrama E-R. 5.3.4 Identificar Tipos de Valor e Atributos A Figura 68 mostra os atributos e tipos de valor para tipos de entidade CLIENTE e PEDIDO. Uma entidade CLIENTE tem cinco atributos: Nº DO CLIENTE, SALDO DE CONTA, LIMITE DE CRÉDITO, DESCONTO e DESPACHO PARA ENDEREÇOS. Cada cliente pode ter mais de um DESPACHO PARA ENDEREÇO. Cada entidade PEDIDO tem três atributos: Nº DO PEDIDO, DESPACHO PARA ENDEREÇO e DATA. Cada pedido tem apenas um DESPACHO PARA ENDEREÇO. O relacionamento CLIENTE-PEDIDO não tem atributos. A Figura 69 ilustra os atributos e tipos de valor das propriedades das entidades LINHA e das relações LINHA-PARTE. Uma entidade LINHA tem um atributo: Nº DA LINHA. Uma relação LINHA-PARTE tem dois atributos: QTD PEDIDA e QTD A ENTREGAR. O valor da QTD A ENTREGAR é, inicialmente, igual à QTD PEDIDA e é gradualmente reduzido a zero conforme os despachos parciais são feitos.


61

Os atributos e tipos de valor para PARTE, INVENTÁRIO e DEPÓSITO podem ser encontrados nas Figuras 54 e 55. 5.3.5 Traduzir o Diagrama E-R em um Diagrama de Estrutura de Dados Usando as regras de tradução discutidas na Seção 4.2, o diagrama E-R da Figura 67 pode ser traduzido no diagrama de estrutura de dados mostrado na Figura 70. Todos os tipos de entidade tornam-se tipos de registro no diagrama de estrutura de dados. Uma vez que os tipos de relacionamento CLIENTE-PEDIDO, PEDIDO-LINHA e LINHA-PARTE são mapeamentos um-para-muitos, eles são traduzidos em conjuntos de estrutura de dados no dia diagrama de estrutura de dados. Uma vez que o relacionamento INVENTARIO é um mapeamento muitos-para-muitos, ele é traduzido em um tipo de registro. CLIENTE

PARTE

PEDIDO

LINHA

DEPÓSITO

INVENTÁRIO

Figura 70 O diagrama estrutura de dados derivado do diagrama E-R da Figura 67.

5.3.6 Projetar Formato de Registro As Figuras 71 a 74 ilustram os formatos de registro para os quatro tipos de registro CLIENTE, PEDIDO, LINHA e PARTE da Figura 70. O registro LINHA contém não apenas os atributos da entidade LINHA, mas também os atributos dos relacionamentos LINHA-PARTE. (Ver Figuras 69 e 73.) Neste exemplo de banco de dados de anotação de

62

Modelagem de Dados

pedidos de compra também escolhemos cadeias como implementação física dos conjuntos de estrutura de dados. Os formatos de registro para os tipos de registro DEPÓSITO e INVENTÁRIO estão mostrados nas Figuras 65 e 66. Note que, se fundirmos as Figuras 56 e 60, teremos de reprojetar o formato de registro para o registro PARTE; isto é, fundir a Figura 62 com a Figura 74. GRUPO DE REPETIÇÃO

Nº DO CLIENTE

LIMITE DE CRÉDITO

SALDO DA CONTA

DESCONTO

DESPACHO PARA ENDEREÇOS

PARA O PRIMEIRO REGISTRO PEDIDO RELACIONADO A ESTE CLIENTE

Figura 71 Registro CLIENTE.

PARA O PRÓXIMO REGISTRO PEDIDO PERTENCENTE AO MESMO CLIENTE

Nº DO PEDIDO

DATA


PARA O PRIMEIRO REGISTRO LINHA RELACIONADO A ESTE PEDIDO

Figura 72 Registro PEDIDO.


63

PARA O PRÓXIMO REGISTRO LINHA PERTENCENTE AO MESMO PEDIDO

Nº DA LINHA

QTD PEDIDA

QTD A ENTREGAR

PARA O PRÓXIMO REGISTRO LINHA RELACIONADO À MESMA PARTE

Figura 73 Registro LINHA.

Nº DA PARTE

PESO

COR

PARA O PRIMEIRO REGISTRO LINHA RELACIONADO A ESTA PARTE

Figura 74 Registro PARTE.

5.4 EXEMPLO 3: UM BANCO DE DADOS DE UMA BIBLIOTECA 5.4.1 Identificar Tipos de Entidade Uma Biblioteca quer manter o controle de seus livros e também proporcionar um sistema computadorizado para busca de livros por categorias, palavras-chaves ou autores. Tipos de entidade importantes são: LIVRO, AUTOR, PALAVRA-CHAVE, CATEGORIA e FUNCIONÁRIO. (Ver Figura 75.)

64

Modelagem de Dados

SUBCHAVES

PALAVRACHAVE

"CLASSIFICAÇÃO* PRIMARIA

CLASSIFICAÇÃO SECUNDARIA

AUTORIA PRINCIPAL AUTOR

SINÔNIMO

CATÁLOGO PRIMÁRIO LIVRO

CATEGORIA

CO-AUTORIA

SUB-CATEGORIA

EMPRÉSTIMO

REQUISIÇÃO

FUNCIONÁRIO

Figura 75 Um diagrama E-R para um banco de dados de biblioteca.

5.4.2 Identificar Tipos de Relacionamento Há dois tipos de relacionamento entre entidades AUTOR e entidades LIVRO. Uma é a AUTORIA PRINCIPAL e a outra é a COAUTORIA. (Ver Figura 75.) Cada livro tem apenas um autor principal, mas um autor pode ser o autor principal de muitos livros. Por outro lado, cada livro pode ter vários co-autores (além do autor principal) e cada autor pode ser o co-autor de muitos livros. Há dois tipos de relacionamento entre entidades CATEGORIA e entidades LIVRO: uma é o CATÁLOGO PRIMÁRIO e a outra é o CATÁLOGO SECUNDÁRIO. Cada livro pertence a apenas uma categoria primária, mas pode pertencer a várias categorias secundárias. Por exemplo, um livro relacionado a "físico-química" pode ter "química" como sua categoria primária e


65

"física" como sua categoria secundária. Há também um tipo de relacionamento chamado SUBCATEGORIA, que é definido entre entidades CATEGORIA; isto é, cada categoria pode ser dividida em subcategorias. Por exemplo, "ciência" pode ser divida em "física", "química", "matemática" etc. Similarmente, existem dois tipos de relacionamentos entre entidades PALAVRA-CHAVE e entidades LIVRO: uma é a CLASSIFICAÇÃO PRIMÁRIA e a outra é a CLASSIFICAÇÃO SECUNDÁRIA. Cada palavra-chave pode ser dividida em várias subchaves. Além disso, cada palavra-chave pode ter vários sinônimos. Por exemplo, "memória de computador", "memória principal" e "memória de núcleo" são sinônimos. Existem dois tipos de relacionamentos entre entidades FUNCIONÁRIO e entidades LIVRO: uma é EMPRÉSTIMO e a outra é REQUISIÇÃO. Cada funcionário pode tomar emprestado vários livros, mas um livro usualmente é levado por apenas um funcionário. Se um funcionário não encontrar um livro na biblioteca, ele pode requisitar que o livro seja guardado para ele quando for devolvido. A relação REQUISIÇÃO é um mapeamento muitos-para-muitos.

5.4.3 Desenhar um Diagrama E-R O diagrama E-R para o banco de dados da biblioteca é mostrado na Figura 75. Note que podemos cominar a Figura 75 com a Figura 50 e a Figura 67 para obter um grande diagrama E-R.

5.4.4 Identificar Atributos e Tipos de Valor A Figura 76 mostra os atributos e tipos de valor para AUTOR e LIVRO. Uma entidade AUTOR tem dois atributos: NOME e DATA DE NASCIMENTO. Uma entidade LIVRO tem quatro atributos: DATA DE PUBLICAÇÃO, TÍTULO, EDIÇÃO e CÓDIGO. A Figura 77 ilustra os atributos e tipos de valor para CATEGORIA e CATÁLOGO SECUNDÁRIO. Cada entidade CATEGORIA tem um nome tal como "física" ou "química". Uma relação CATÁLOGO SECUNDÁRIO tem um atributo chamado RELEVÂNCIA, que é um valor numérico (tal como 0,1,0,55, 0,9) atribuído por um bibliotecário para indicar o

66

Modelagem de Dados

grau de relevância entre um livro e uma categoria secundária. Convenciona-se que a categoria primária tem 1,0 como grau de relevância. O conceito de RELEVÂNCIA pode estreitar o campo de ação de buscas no banco de dados. Similarmente, um relacionamento CLASSIFICAÇÃO SECUNDÁRIA na Figura 78 também tem um atributo chamado RELEVÂNCIA. AUTORIA PRINCIPAL

LIVRO

AUTOR

CO-AUTORIA

DATA DE NASCIMENTO

NOME

Figura 76

DATA

DATA DE PUBLICAÇÃO

TITULO

EDIÇÃO

CÓDIGO

Atributos e tipos de valor para AUTOR e LIVRO.

CATÁLOGO PRIMÁRIO

CATEGORIA

LIVRO

SUBCATEGORIA

CATÁLOGO SECUNDÁRIO

RELEVÂNCIA

Figura 77

NOME

Atributos e tipos de valor para CATEGORIA e CATÁLOGO SECUNDÁRIO.


CLASSIFICAÇÃO PRIMÁRIA

SUBCHAVES PALAVRACHAVE

LIVRO

CLASSIFICAÇÃO SECUNDÁRIAS

RELEVÂNCIA

Figura 78

67

SINÔNIMO

NOME

Atributos e tipos de valor para PALAVRA-CHAVE e CLASSIFICAÇÃO SECUNDÁRIA.

Os atributos e tipos de valor para FUNCIONÁRIO, EMPRÉSTIMO e REQUISIÇÃO são mostrados na Figura 79. Um FUNCIONÁRIO tem dois atributos: Nº DO FUNC e NOME. Um relacionamento EMPRÉSTIMO tem dois atributos: DATA DE SAÍDA e DATA DE DEVOLUÇÃO. Esta informação pode ajudar o bibliotecário a descobrir qual livro está com prazo vencido. Um relacionamento de REQUISIÇÃO tem um atributo chamado DATA DE REQUISIÇÃO, que proporciona a informação necessária para que o bibliotecário atribua o livro ao funcionário certo quando o livro estiver disponível. 5.4.5 Traduzir o Diagrama E-R em um Diagrama de Estrutura de Dados Usando as regras de tradução discutidas na Seção 4.2, o diagrama E-R da Figura 75 pode ser traduzido no diagrama de estrutura de dados mostrado na Figura 80. Todos os tipos de relacionamento que sejam mapeamentos um-para-muitos são traduzidos em conjuntos de estrutura de dados (ponteiros.) Por exemplo, o tipo de relacionamento AUTORIA PRINCIPAL é traduzido em um ponteiro. Todos os tipos de

68

Modelagem de Dados

relacionamento que sejam mapeamentos muitos-para-muitos são traduzidos em tipos de registro. Por exemplo, o tipo de relacionamento COAUTORIA é traduzido em um tipo de registro apontado por dois ponteiros (um do tipo de registro AUTOR e outro do tipo de registro LIVRO).

EMPRÉSTIMO LIVRO

FUNCIONÁRIO REQUISIÇÃO

DATA DE SAlDA

DATA DE DEVOLUÇÃO

DATA DE REQUISIÇÃO

(N° DO FUNC)

DATA

NOME

Figura 79 Atributos e tipos de valor para FUNCIONÁRIO, EMPRÉSTIMO e REQUISIÇÃO.

AUTOR

FUNCIONÁRIO

LIVRO

CO-AUTORIA

REQUISIÇÃO

CATEGORIA

SUBCATEGORIA

PALAVRACHAVE

SUBCHAVES

SINÔNIMO

CATALOGO SECUNDÁRIO

Figura 80 Um diagrama de estrutura de dados derivado do diagrama E-R da Figura 75.


69

Os tipos de relacionamento definidos entre entidades do mesmo tipo também são traduzidos em tipos de registro. Por exemplo, o tipo de relacionamento SUBCHAVES é traduzido em um tipo de registro.

5.4.6 Projetar Formato de Registro Os formatos dos registros são semelhantes aos discutidos nos dois exemplos anteriores. Portanto, omitimos a discussão aqui.


70

Modelagem de Dados

6. OUTRAS CONSIDERAÇÕES EM PROJETO LÓGICO DE BANCO DE DADOS 6.1 OUTRAS REGRAS DE TRADUÇÃO DE DIAGRAMAS E-R PARA DIAGRAMAS DE ESTRUTURA DE DADOS As regras de tradução de diagramas E-R para diagramas de estrutura de dados discutidas na Seção 4.2 são comumente usadas, mas não são as únicas regras. Podemos usar uma regra simples que traduz todos os tipos de relacionamento em tipos de registro, seja qual for o tipo de mapeamento (muitos-para-muitos, um-para-muitos etc). Usando esta regra, o diagrama E-R da Figura 50 seria traduzido na Figura 81, em vez de na Figura 56. O diagrama E-R da Figura 67 seria traduzido na Figura 82 em vez de na Figura 70. Note que todos os tipos de relacionamento são traduzidos em tipos de registro, exceto os tipos de relacionamentos EXISTÊNCIA ou ID DEPENDENTES. Por exemplo, o tipo de relacionamento entre PEDIDO e LINHA é traduzido em um conjunto de estrutura de dados (um ponteiro) na Figura 67. DEPT

DEPT-FUNC

FUNC

PROJGERENTE

PROJ-FUNC

PROJ

FORN

PROJ-FORNPARTE

PARTE

FORN POTENCIAL

DEPÓSITO

INVENTÁRIO

PRD-REL

Figura 81 Outro diagrama de estrutura de dados derivado do diagrama E-R da Figura 50.


CLIENTE

PEDIDO

PARTE

71

DEPÓSITO

LINHA

CLIENTE-PEDIDO

LINHA-PARTE

INVENTÁRIO

Figura 82 Outro diagrama de estrutura de dados derivado do diagrama E-R da Figura 67.

Usando esta regra simplificada, o diagrama de estrutura de dados resultante será mais complicado e pode ser menos eficiente em recuperação e atualização. Contudo, pode proporcionar um nível mais alto de independência de dados. Isto é, programas e estruturas de bancos de dados não precisam ser alterados quando um determinado tipo de relacionamento muda de um mapeamento um-para-muitos para um mapeamento muitos-para-muitos. Essa mudança em tipos de mapeamentos converterá um conjunto de estrutura de dados em um tipo de registro ou vice-versa se as regras de tradução discutidas na Seção 4.2 forem usadas, mas nenhuma mudança é necessária se for utilizada a regra simplificada discutida nesta seção. 6.2 MODIFICAR O DIAGRAMA DE ESTRUTURA DE DADOS POR RAZÕES DE DESEMPENHO E ARMAZENAMENTO Depois de obtermos diagramas de estrutura de dados a partir de diagramas E-R usando as regras de tradução, podemos querer modificálos para conseguir melhor desempenho do sistema ou melhor utilização do espaço de armazenamento. Por exemplo, podemos dividir o registro FUNC das Figuras 56, 58 e 81 em dois registros. Um é o registro FUNC PRINCIPAL que contém campos Nº DO FUNC, DATA DE NASCIMENTO e SALÁRIO. (Ver Figura 83.) O outro é o FUNC-DETALHE, que contém

72

Modelagem de Dados

os campos DATA DE INÍCIO NO DEPT, TELEFONE COMERCIAL e TELEFONE RESIDENCIAL. (Ver Figura 84.) Note que é necessário um ponteiro para conectar as ocorrências desses dois tipos de registro. Os diagramas de estrutura de dados nas Figuras 56 e 81 serão modificados pela incorporação da Figura 85. Uma das razões para dividir um registro em dois ou três registros é melhorar o desempenho de recuperação. Por exemplo, espera-se que os campos no registro FUNC PRINCIPAL venham a ser usados com mais freqüência do que os campos no registro FUNC-DETALHE. Uma vez que não queremos recuperar os dados que não são necessários, seria uma boa idéia dividir o registro em dois. Uma outra razão para dividir um registro em dois é a limitação do tamanho do registro. Em alguns casos devido a limitações de hardware/software, pode ser preferível limitar o tamanho do registro a um comprimento fixo (digamos, 256 bytes). Se um registro "conceituai" for maior do que o comprimento máximo de um registro, ele poderá ter de ser dividido em dois ou mais registros. PARA O PRÓXIMO REGISTRO FUNC NO MESMO DEPARTAMENTO

Nº DO FUNC

DATA DE NASCIMENTO

PARA O PRIMEIRO REGISTRO PROJ GERENCIADO POR ESTE FUNCIONÁRIO

SALÁRIO

PARA O REGISTRO FUNC-DETALHE

PARA O PRIMEIRO REGISTRO FUNC-PROJ RELACIONADO A ESTE FUNCIONÁRIO

Figura 83 Registro FUNC PRINCIPAL.


73

PARA O REGISTRO FUNC PRINCIPAL

DATA DE INÍCIO TELEFONE TELEFONE COMERCIAL RESIDENCIAL NO DEPT

Figura 84 Registro FUNC-DETALHE.

FUNC PRINCIPAL

FUNC-DETALHE

Figura 85 Diagrama de estrutura de dados para FUNC PRINCIPAL e FUNCDETALHE.

Uma outra prática comum é fatorar os grupos de repetição. Por exemplo, o DESPACHO PARA ENDEREÇOS nas Figuras 68 e 71 é um grupo de repetição (ou seja, há muitos valores de dados para este atributo). Podemos retirar esse campo e colocá-lo em um novo registro chamado DESPACHO PARA ENDEREÇO. (Ver Figuras 86 e 87.) Os diagramas de estrutura de dados nas Figuras 70 e 82 serão modificados pela incorporação da Figura 88. Note que um diagrama E-R pode ser traduzido em muitos diagramas de estrutura de dados diferentes, para atender às diferentes necessidades de processamento de dados. Portanto, recomendamos que o projetista de banco de dados comece com um diagrama E-R e, então, traduza-o a um diagrama de estrutura de dados adequado para seu ambiente.

74

Modelagem de Dados PARA O PRIMEIRO REGISTRO PEDIDO RELACIONADO A ESTE CLIENTE

Nº DO CLIENTE

SALDO DE CONTA

LIMITE DE CRÉDITO

DESCONTO

PARA O PRIMEIRO REGISTRO DESPACHO PARA ENDEREÇO PARA ESTE CLIENTE

Figura 86

Um "novo" registro CLIENTE.


PARA O PRÓXIMO REGISTRO DESPACHO PARA ENDEREÇO PARA O MESMO CLIENTE

Figura 87

Registro DESPACHO PARA ENDEREÇO.

CLIENTE


Figura 88

Um diagrama de estrutura de dados para CLIENTE e DESPACHO PARA ENDEREÇO.


75

7. PROJETO DE BANCOS DE DADOS HIERÁRQUICOS Em sistemas de bancos de dados hierárquicos como o IMS da IBM, os dados serão organizados em hierarquias de registros. (Ver Figura 7.) Nesta seção, faremos uma breve discussão sobre como usar o método E-R para o projeto de banco de dados hierárquicos. 7.1 REGRAS DE TRADUÇÃO Uma vez que os tipos de relacionamento hierárquicos permitem apenas mapeamentos um-para-muitos, temos de traduzir os tipos de relacionamentos com mapeamentos muitos-para-muitos em estruturas hierárquicas. Há pelo menos cinco estruturas lógicas de dados possíveis para o diagrama E-R sobre PROJ-FUNC na Figura 89. Essas cinco estruturas lógicas de dados estão relacionadas a seguir: 1. O tipo de registro PROJ é tratado como um "registro-filho" (ou "registro-subordinado") para o tipo de registro FUNC. (Ver Figura 90.) Esta estrutura lógica de dados será eficiente para determinados tipos de perguntas mas não para outros. Por exemplo, se queremos encontrar todos os funcionários associados a um determinado projeto, podemos ter de fazer uma busca exaustiva por todo o banco de dados. 2. O tipo de registro FUNC é tratado como um "registro-filho" para o tipo de registro PROJ. (Ver Figura 91.) Uma busca exaustiva de todo o banco de dados será necessária se quisermos encontrar todos os projetos associados a um determinado funcionário. 3. Uma vez que nem a estrutura lógica de dados da Figura 90 nem a da Figura 91 podem ser eficientes para todos os tipos de perguntas, podemos querer manter dois bancos de dados,

76

Modelagem de Dados

como é mostrado na Figura 92. Mas isto requer a manutenção de dados redundantes. 4. Em IMS, podemos escolher a estrutura lógica de dados da Figura 93, de forma que o tipo de registro FUNC será o "pai físico" do PROJ-FUNC, e o tipo de registro PROJ será o "pai lógico". 5. Uma alternativa em IMS é tornar o tipo de registro FUNC o "pai lógico" em vez de "pai físico" do tipo de registro PROJFUNC. (Ver Figura 94.)

FUNC

PROJ-FUNC

Figura 89 Mapeamento muitos-para-muitos.

FUNC

PROJ

Figura 90 PROJ como registro-filho para FUNC.

PROJ

FUNC

Figura 91 FUNC como registro-filho para PROJ.

PROJ

o

Figura 92

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

FUNC

PROJ

PROJ

FUNC

Mantendo dois bancos de dados.

FUNC

PROJ

PROJFUNC Figura 93

PROJ como o "pai lógico" de PROJ-FUNC.

FUNC

PROJ

PROJFUNC Figura 94

FUNC como o "pai lógico" de PROJ-FUNC.

EXEMPLO Para o diagrama E-R do banco de dados de anotação de pedidos de compra (Figura 67), podemos derivar muitas estruturas lógicas hierárquicas possíveis. Uma estrutura possível é mostrada na Figura 95, na qual o tipo de registro LINHA é o "filho físico"do tipo de registro PEDIDO e o "filho lógico" do tipo de registro PARTE.

77

78

Modelagem de Dados

Note que a Figura 95 pode ser modificada (ou seja, dividindo ou fundindo tipos de registro) para satisfazer necessidades de desempenho ou armazenamento. CLIENTE

PEDIDO

PARTE

DEPÓSITO

LINHA

Figura 95 Um banco de dados hierárquico para o diagrama E-R da Figura 67.



79

8. COMENTÁRIOS FINAIS Nesta obra, esboçamos um novo método em projeto lógico de bancos de dados: o Método Entidade-Relacionamento. A base do método foi testada em ambientes do mundo real e mostrou-se fácil de entender e fácil de usar. Em particular, o diagrama E-R mostrou-se uma ferramenta de comunicação valiosa e efetiva entre pessoas ligadas e não ligadas ao processamento eletrônico de dados. Um de nossos projetos atuais no M.I.T. é desenvolver diagramas E-R detalhados e padronizados para vários tipos de empresas, como fábricas, bancos, varejo etc, que possam ser usados para auxiliar o projeto de banco de dados ou o planejamento do sistema de informações. Alguns trabalhos relevantes para o método E-R estão relacionados nas referências. Qualquer sugestão para aperfeiçoar o método E-R será apreciada.

80

Modelagem de Dados

9. REFERÊNCIAS 1. CHEN, Peter, P.S. "The Entity-Relationship Model: Towards a Unified View of Data", ACM Transaction on Database Systems, vol. 1, nº1, (março-1976), p. 9-36. 2. CHEN, Peter, P.S. "The Entity-Relationship Model: A Basis for the Enterprise View of Data", AFIPS Conference Proceedings, vol. 46, AFIPS Press, N.J., (1977 National Computer Conference), p. 77-84. 3.

HO, Thomas I.M. "New Perspectives for Information Systems Education", AFIPS Conference Proceedings, vol. 46, AFIPS Press, N.H., (1977 National Computer Conference), p. 569-574.

4. HO, Thomas, I.M. "Data Base Concepts for Systems Analysis", Purdue University, Computer Sciences Department Technical Report, novembro-1976. 5. Moulin, P.J. Randon, M. Teboul, et al., "Conceptual Model as a Database Design Tool", Proc. IFIP TC-2 Working Conference, janeiro-1976, Floresta Negra, Alemanha, p. 459-479. 6. TOZER, E.E. "Database Systems Analysis and Design", Technical Report, Software Sciences Limited, Inglaterra, abril-1976.

São Paulo: Makron Books, 1990. 80p.

Modelagem de Dados, Peter Chen

Recommend Documents