Modelagem de Dados, Peter Chen

Rafael Gama de Macedo Jr.
O MTODO ENTIDADE-RELACIONAMENTO PARA PROJETO LGICO DE BANCOS DE DADOS
1. INTRODUO
O gerenciamento de dados tornou-se uma das atividades mais importantes em muitas organizaes. Conforme nos movemos para uma sociedade cada vez mais orientada para a informao, a determinao de como organizar os dados para maximizar sua utilidade torna-se um problema muito importante. Sistemas de arquivo e sistemas de banco de dados baseados em computador simplificam a tarefa de manter e recuperar uma grande quantidade de dados. Contudo, o problema de como organizar os dados para utilizar a capacidade total do sistema de arquivos ou do banco de dados no bem compreendido por muitas pessoas que trabalham em processamento de dados. A finalidade desta obra proporcionar uma metodologia que torne o processo de organizao de dados mais fcil de ser compreendido e seguido. 1.1 TERMINOLOGIA BSICA Nesta seo, vamos explicar vrios conceitos bsicos em gerenciamento de dados.
1
Modelagem de Dados
Um registro uma coleo de itens de dados. Por exemplo, um registro de funcionrio contm os dados relevantes de um funcionrio especfico. (Ver Figura 1.) Um registro dividido em vrios campos. Na Figura 1, NOME, SALRIO e ENDEREO so os nomes dos campos de um registro de funcionrio. Nomes de campos so utilizados para interpretar o significado dos itens de dados (ou valores) no registro. Portanto, "ROBERT JOHNSON" o "NOME" de um funcionrio especfico e "10K" o seu "SALRIO". Um arquivo uma coleo de registros do mesmo tipo. Por exemplo, o arquivo de FUNCIONRIO uma coleo de registros de FUNCIONRIO. (Ver Figura 2.) Um banco de dados uma coleo de registros de tipos diferentes. (Ver Figura 3.) Os registros em um banco de dados so interligados, de forma que itens de dados relevantes em registros diferentes possam ser recuperados sem dificuldade. Por exemplo, podemos desejar interligar todos os registros de funcionrios que trabalhem para o mesmo departamento (Ver Figura 4), de modo que seja fcil encontrar quem trabalha para um departamento especfico. A Figura 4 ilustra a estrutura fsica de dados do banco de dados na qual as conexes entre registros de DEPARTAMENTO e registros de FUNCIONRIO so implementadas por cadeias. Um registro de DEPARTAMENTO tem um ponteiro que aponta para o primeiro registro de FUNCIONRIO na cadeia. Cada registro de FUNCIONRIO na cadeia tem um ponteiro que aponta para o registro de FUNCIONRIO seguinte. O ltimo registro de FUNCIONRIO aponta de volta para o registro de DEPARTAMENTO. A Figura 4 ilustra os relacionamentos de ocorrncias de registros no banco de dados, mas detalhada demais para ser til na comunicao de relacionamentos-chaves no banco de dados. A Figura 5 uma maneira simples de representar a organizao de registros da Figura 4. Cada retngulo na Figura 5 representa um tipo de registro e a seta representa a associao de registros de FUNCIONRIO com seus registros de DEPARTAMENTO. H uma outra distino entre as Figuras 4 e 5; a Figura 5 representa a estrutura lgica de dados do banco de dados, uma vez que mostra apenas a conexo entre o tipo de registro de DEPARTAMENTO e o tipo de registro de FUNCIONRIO, mas no mostra como essa conexo implementada.
O mtodo entidade-relacionamento para projeto lgico de bancos de dados
NOMES DE CAMPO
NOME ROBERT JOHNSON
SALRIO 10K
ENDEREO BOSTON, MASS.
VALORES Figura 1 Um registro de FUNCIONRIO.
ROBERT JOHNSON
10K
BOSTON, MASS.
LEE GOODMAN
25 K
N.Y., N.Y
JEAN WALTERS
16K
SAN JOSE, CALIF.
Figura 2
Um arquivo de FUNCIONRIO.
Modelagem de Dados
UM BANCO DE DADOS
REGISTROS DE FUNCIONRIO FUNCIONRIO A
REGISTROS DE DEPARTAMENTO DEPARTAMENTO A
FUNCIONRIO B
DEPARTAMENTO B
FUNCIONRIO C
Figura 3
Um banco de dados com dois tipos de registros.
DEPARTAMENTO A
FUNCIONRIO A
FUNCIONRIO B
DEPARTAMENTO B
FUNCIONRIO C
Figura 4
Registros relevantes no banco de dados so interligados (estrutura fsica de dados do banco de dados).
FUNCIONRIO
DEPARTAMENTO
Figura 5
Estrutura lgica de dados do banco de dados.
1.2 PROJETO LGICO DE BANCO DE DADOS E PROJETO FSICO DE BANCO DE DADOS

O projeto de bancos de dados pode ser dividido em duas etapas: projeto lgico e projeto fsico. (Ver Figura 6.) O projeto fsico de banco de dados o processo de selecionar uma estrutura fsica de dados para uma dada estrutura lgica de dados. Por exemplo, h pelo menos trs (3) estruturas fsicas de dados possveis dentro de um sistema de banco de dados CODASYL para dar suporte mesma estrutura lgica de dados da Figura 6. A primeira usar um "ponteiro para frente" para ligar todos os registros de FUNCIONRIO no mesmo departamento. A segunda acrescentar "ponteiros para trs" aos registros de FUNCIONRIO. A terceira usar um "conjunto de ponteiros" no qual o registro de DEPARTAMENTO mantm ponteiros para todos os registros de FUNCIONRIO relacionados. Cada uma dessas trs estruturas fsicas de dados tem suas vantagens e desvantagens. A primeira fcil de implementar e adequada para processamento seqencial dos registros de FUNCIONRIO. A segunda torna relativamente fcil encontrar os registros de FUNCIONRIO anteriores na cadeia custa de mais espao de armazenamento necessrio devido aos ponteiros para trs (tambm torna o processo de excluso mais eficiente). A principal vantagem da terceira estrutura fsica de dados que todos os registros de FUNCIONRIO que pertenam ao mesmo departamento podem ser recuperados simultaneamente. importante observar que nenhuma estrutura fsica de dados universalmente tima. A finalidade do projeto fsico de banco de dados selecionar a estrutura fsica de dados que seja mais adequada para determinado ambiente de aplicao. Embora o projeto fsico de banco de dados seja um tpico importante, no vamos aprofundar a discusso a esse respeito nesta obra. O projeto lgico de banco de dados o processo de planejar a estrutura lgica de dados para o banco de dados. (Ver Figura 6.) Isto envolve uma anlise do ambiente de aplicao e dos tipos de estruturas lgicas de dados disponveis no sistema de banco de dados. Atualmente, h poucas ferramentas para auxiliar o processo de projeto lgico de
Modelagem de Dados
banco de dados; o projetista de banco de dados geralmente tem de contar com sua intuio e experincia. Como resultado, muitos bancos de dados existentes hoje em dia no so adequadamente projetados. Nesta obra, vamos nos concentrar no processo de projeto lgico de banco de dados e introduzir uma ferramenta til e prtica para ajudar o projetista de banco de dados.
MUNDO REAL ESTRUTURA LGICA DE DADOS ESTRUTURA FSICA DE DADOS DEPARTAMENTO A
FUNCIONRIO A PROJETO FlSICO DE DEPARTAMENTO BANCO DE DADOS FUNCIONRIO
FUNCIONRIO B
DEPARTAMENTO A
PONTOS DE INTERESSE PARA A EMPRESA
FUNCIONRIO A
FUNCIONRIO B
DEPARTAMENTO A
FUNCIONRIO A
FUNCIONRIO B
Figura 6
Projeto lgico e fsico de banco de dados.
1.3 SISTEMAS DE BANCOS DE DADOS E MODELOS DE DADOS H muitos sistemas de bancos de dados em uso no momento. Eles podem ser classificados em trs (3) categorias principais: hierrquico, de rede e relacionai. Uma das principais diferenas entre eles o tipo de estruturas lgicas de dados que podem ser suportadas. Sistemas hierr-
quicos de bancos de dados, como o Information Management System (IMS) da IBM, requerem que os tipos de registro de dados sejam organizados em uma forma hierrquica. (Ver Figura 7.) Essa estrutura hierrquica de dados funciona bem com alguns bancos de dados, mas torna-se difcil projetar bancos de dados usando um sistema hierrquico quando no existe uma hierarquia natural entre os tipos de registro. Sistemas de bancos de dados em rede (ou CODASYL), tais como o Integrated Data Store (IDS) da Honeywell, o DMS-1100 da UNIVAC e o IDMS da Cullinane, proporcionam capacidades mais complexas de estruturas de dados do que os sistemas hierrquicos. Por exemplo, os sistemas de rede permitem que um tipo de registro tenha mltiplos tipos de registro como "pais". (Ver Figura 8.) Os sistemas relacionais (a maioria dos quais experimental no momento)* usam tabelas como estruturas lgicas de dados. (Ver Figura 9.) Em resumo, o projeto lgico de bancos de dados preocupa-se com a organizao de dados em uma forma aceitvel para o sistema de banco de dados subjacente. (Ver Figura 10.)
DEPARTAMENTO
FUNCIONRIO
HABILIDADE
Figura 7
Estrutura "hierrquica" de dados.
"No momento" se refere a 1977, atualmente esses sistemas so de uso generalizado. (N. do R. T.)
Modelagem de Dados
DEPARTAMENTO
FUNCIONRIO
HABILIDADE
FUNCIONRIO-HABILIDADE
Figura 8
Estrutura de dados "de rede".
TABELA DE DEPARTAMENTO ND 1 5 8 ORAMENTO 10M 5M 20M
TABELA DE FUNCIONRIO NOME JOHNSON GOODMAN WALTERS SALRIO 10K 15 K 16 K ENDEREO BOSTON NYC SAN JOS
TABELA DE HABILIDADE NH 5 NOME-H FORTRAN COBOL
TABELA DE FUNCIONRIO-HABILIDADE NOME JOHNSON JOHNSON GOODMAN GOODMAN
TABELA DE DEPARTAMENTO-FUNCIONRIO ND 1 1 5 NOME JOHNSON GOODMAN WALTERS
NH
1 2 1 5
2
1
PM
Figura 9
Estrutura de dados "relacional" ("tabela").
MUNDO REAL
ESTRUTURA LGICA DE DADOS (ESQUEMA DO USURIO)
HIERRQUICA
PROJETO LGICO DE BANCO DE DADOS (COMO?)
REDE
RELACIONAL
Figura 10
Projeto Lgico de Banco de Dados.
1.4 PROBLEMAS NO PROJETO LGICO DE BANCOS DE DADOS O projeto de bancos de dados , hoje em dia, um processo complicado, uma vez que o projetista tem de considerar no apenas como modelar o mundo real, mas tambm as limitaes do sistema de banco de dados e a eficincia da recuperao e atualizao dos dados. Por exemplo: 1. O projetista de banco de dados restringido pelos tipos limitados de estrutura de dados que so suportados pelo sistema de gerncia de banco de dados. Por exemplo, os relacionamentos muitos-para-muitos entre dois tipos de entidades,
10
Modelagem de Dados
tais como os relacionamentos entre funcionrios e projetos, no podem ser representados diretamente em muitos sistemas de banco de dados. 2. O projetista de banco de dados pode ter de considerar a via de acesso dos registros (ou seja, como acessar um tipo particular de registro). Por exemplo, a suposio implcita na Figura 3 que registros de FUNCIONRIO tm de ser acessados por meio do registro de DEPARTAMENTO correspondente. 3. O projetista de banco de dados pode querer tornar a recuperao e a atualizao mais eficientes. Assim, os dados sobre uma entidade no mundo real podem ser colocados em mais de um registro para propsitos de eficincia. Por exemplo, os itens de dados sobre um funcionrio podem ser agrupados em dois registros: FUNCIONRIO-PRINCIPAL e FUNCIONRIO-DETALHE. H dois problemas no mtodo convencional de projeto de banco de dados: 1. O projetista de banco de dados tem de considerar muitas questes ao mesmo tempo, o que torna a tarefa de projeto de banco de dados muito difcil. 2. O resultado final do projeto lgico de banco de dados o esquema do usurio (ou seja, uma descrio da viso do banco de dados pelo usurio). Uma vez que o esquema do usurio representa a soluo do projetista para as questes complicadas mencionadas acima, no difcil perceber por que os esquemas do usurio so geralmente difceis de ser compreendidos e alterados. 1.5 UM NOVO MTODO PARA PROJETO DE BANCO DE DADOS: O MTODO ENTIDADE-RELACIONAMENTO Vamos descrever um novo mtodo para projeto lgico de bancos de dados chamado mtodo Entidade-Relacionamento (E-R). A idia-cha-
11
ve do mtodo E-R acrescentar um estgio intermedirio ao projeto lgico de bancos de dados. (Ver Figura 11.) O projetista de banco de dados primeiro identifica as entidades e relacionamentos que so de interesse para a empresa usando a tcnica diagramtica Entidade-Relacionamento (E-R). Nesse estgio, o projetista deve examinar os dados do ponto de vista da empresa como um todo (no a viso de um programador de aplicao especfico). Portanto, vamos chamar a descrio da viso da empresa quanto aos dados de "esquema da empresa". O esquema da empresa deve ser uma representao "pura" do mundo real e deve ser independente de consideraes sobre armazenamento e eficincia. O projetista de banco de dados primeiro projeta o esquema da empresa e ento o traduz a um esquema do usurio para seu sistema de banco de dados. (Ver Figura 11.)
MUNDO REAL ESQUEMA DA EMPRESA HIERRQUICO
ESQUEMA DO USURIO
REDE
RELACIONAL
Figura 11
Esquema da empresa - uma etapa intermediria no projeto lgico de bancos de dados.
12
Modelagem de Dados
1.6 VANTAGENS DO MTODO ENTIDADERELACIONAMENTO Os mtodos convencionais de projeto lgico de bancos de dados usualmente apresentam uma nica fase: mapeamento de informaes sobre objetos do mundo real diretamente em um esquema do usurio. O mtodo E-R para projeto lgico de bancos de dados consiste em duas fases principais: (1) Definio do esquema da empresa usando o diagrama de Entidade-Relacionamento; e (2) traduo do esquema da empresa em um esquema do usurio. As vantagens do mtodo E-R so: 1. A diviso da funcionalidade e trabalho em duas fases torna o processo de projeto de banco de dados mais simples e mais bem organizado. 2. O esquema da empresa mais fcil de ser projetado do que o esquema do usurio, uma vez que no precisa ser restrito pelas caractersticas do sistema de banco de dados e independente de consideraes sobre armazenamento e eficincia. 3. O esquema da empresa mais estvel do que o esquema do usurio. Se uma pessoa quiser mudar de um sistema de banco de dados para outro, provavelmente ter de alterar o esquema do usurio, mas no o esquema da empresa, uma vez que este independente dos sistemas de banco de dados usados. O que precisa ser feito um remapeamento do esquema da empresa para um esquema do usurio compatvel com o novo sistema de banco de dados. De forma semelhante, se uma pessoa quiser mudar o esquema do usurio para otimizar um novo programa de aplicao, no necessrio alterar o esquema da empresa, mas apenas remape-lo para um novo esquema do usurio. 4. O esquema da empresa expresso pelo diagrama de entidaderelacionamento mais facilmente compreendido por pessoas no ligadas ao processamento eletrnico de dados.
13
2. MTODO 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 seo, vamos discutir a arquitetura ANSI/X3/SPARC e como aplicar a ela o mtodo E-R. No outono de 1971, o Comit sobre Computador e Processamento d Informaes (abreviado com Comit X3) do American National Standards Institute (ANSI) formou um grupo de estudos especial para determinar quais (se h algum) aspectos dos sistemas de gerenciamento de bancos de dados so candidatos adequados ao desenvolvimento de padres. O grupo de estudos especial, que chamado Comit de Planejamento e Requisitos de Padres (Standards Planning and Requirements Committee SPARC), consiste em representantes da comunidade de usurios, fabricantes de hardware e universidades. O grupo ANSI/X3/SPARC gastou tempo e esforos considerveis ponderando diferentes vises da teoria dos bancos de dados e desenvolvendo um vocabulrio que fosse consistente e bem compreendido por todos. Como resultado, seu trabalho despertou muita ateno na comunidade de banco de dados. O grupo ANSI/X3/SPARC descobriu que no desejvel desenvolver padres que especifiquem como os componentes de um sistema de gerenciamento de banco de dados devem funcionar, sendo mais recomendvel centrar-se em como os componentes se integram (ou seja, as interfaces). Com isso em mente, o relatrio delineia uma arquitetura de trs esquemas de um sistema de gerncia de bancos de dados. (Ver Figura 12.) Os sistemas de gerncia de bancos de dados atuais usualmente possuem uma estrutura de dois nveis: a estrutura lgica (ou seja, a estrutura de dados como vista pelo programador) e a estrutura fsica (ou seja, a estrutura de dados como vista pelo computador).
14
Modelagem de Dados
A proposta ANSI/X3/SPARC apresenta uma estrutura de trs nveis: esquema externo, esquema conceituai e esquema interno. (Ver Figura 12.) O esquema externo (esquema do usurio) representa a viso do usurio (ou seja, do programador) quanto aos dados. Em outras palavras, um esquema externo uma descrio de dados visveis para um programa de aplicao em termos de nomes e caractersticas de dados. O esquema interno representa a organizao fsica de dados nos dispositivos de armazenamento. Contm tambm os detalhes de integridade, recuperao e maneiras eficientes de recuperar e atualizar dados. O esquema conceituai representa a viso da empresa quanto aos dados. uma descrio de um modelo da empresa em termos de suas entidades, atributos e relacionamentos entre si. Contm tambm os requerimentos para operaes permitidas, integridade semntica e privacidade. O esquema conceituai visa proporcionar uma viso estvel dos dados.
USURIO MUNDO REAL ESQUEMA , DO USURIO
ESQUEMA CONCEITUAL
ESQUEMA INTERNO
DISPOSITIVOS DE ARMAZENAMENTO
Figura 12
Arquitetura ANSI/X3/SPARC.
15
2.2 ESQUEMA CONCEITUAL E ESQUEMA DA EMPRESA Qual a diferena entre o esquema conceituai proposto pelo grupo ANSI/X3/SPARC e o esquema da empresa discutido nesta obra? A resposta que so quase a mesma coisa, exceto que o esquema conceituai necessrio para servir como interface entre o esquema externo e o esquema interno. (Ver Figura 12.) Uma razo para usar o esquema conceituai como a interface reduzir o nmero de mapeamentos entre os esquemas externos e os esquemas internos. Por exemplo, se h M esquemas externos e N esquemas internos, precisamos de M.N programas para fazer os mapeamentos entre os esquemas externos e os esquemas internos. (Ver Figura 13.) Se houver um esquema conceituai entre os esquemas externos e os esquemas internos, precisaremos de apenas M+N programas para fazer os mapeamentos. (Ver Figura 14.) Portanto, o nmero de programas de mapeamento reduzido drasticamente.
M ESQUEMAS EXTERNOS
ESQUEMA EXTERNO N1
ESQUEMA EXTERNO N 2
ESQUEMA EXTERNO N M
TRADUES
ESQUEMA INTERNO N1
ESQUEMA INTERNO N2
ESQUEMA INTERNO N N
N ESQUEMAS INTERNOS
Figura 13 Traduo entre esquemas externos e esquemas internos sem um esquema conceituai.
16
Modelagem de Dados
M ESQUEMAS EXTERNOS
ESQUEMA EXTERNO N 1
ESQUEMA EXTERNO N 2
ESQUEMA EXTERNO
NM
ESQUEMA CONCEITUAI.
ESQUEMA INTERNO N 1
ESQUEMA INTERNO N 2
ESQUEMA INTERNO N N
N ESQUEMAS INTERNOS
Figura 14 Uso do esquema conceituai como interface entre esquemas internos e externos.
Uma das metas da arquitetura ANSI/X3/SPARC manter o esquema conceituai relativamente estvel, permitindo mudanas nos esquemas externos e internos. Esta meta no parece difcil de ser atingida, uma vez que o esquema conceituai representa a viso da empresa quanto aos dados e deve ser relativamente estvel em comparao viso do usurio quanto viso fsica dos dados. Portanto, quando a organizao fsica do banco de dados alterada ou os dados so transportados de dispositivos de armazenamento "antigos" para dispositivos de armazenamento "novos", apenas alteramos o esquema interno, e no o esquema conceituai ou os esquemas externos. Similarmente, se um usurio quiser ver os dados como um certo tipo de organizao, podemos projetar um esquema externo para ele sem mudar o esquema conceituai e os esquemas internos. A no ser por servir como uma interface entre os esquemas externos e internos, o esquema conceituai a mesma coisa que o esquema de empresa e podemos usar o diagrama de entidade-relacionamento
O mtodo entidade-relacionamento para projeto lgico de bancos de dados 17
para descrever o esquema conceituai. Alm disso, uma vez que os esquemas externos podem ser expressos em termos de diferentes tipos de estruturas de dados, tais como rede (CODASYL), hierrquica ou relacionai (ver Figura 15), as regras de traduo entre diagramas E-R e diferentes tipos de estruturas de dados discutidos adiante nesta obra seriam muito teis na implementao da arquitetura ANSI/X3/SPARC.
REDE HIERRQUICA RELACIONAL
ESQUEMAS EXTERNOS
ESQUEMA CONCEITUAL
ESQUEMA INTERNO
Figura 15 Os esquemas externos podem ser expressos em diferentes tipos de estruturas de dados.
2.3 TRS TIPOS DE ADMINISTRADORES DE BANCOS DE DADOS O grupo ANSI/X3/SPARC identificou trs tipos de administradores de bancos de dados:
18
Modelagem de Dados
1. Administrador de empresa O administrador de empresa define o esquema conceituai e, se possvel, o valida. Ele deve compreender muito bem as operaes da empresa e o significado de suas informaes (dados). Ele responsvel pelo contedo, integridade e segurana do banco de dados. 2. Administrador de banco de dados O administrador de banco de dados define o esquema interno. Ele projeta as estruturas fsicas de dados, codificando esquemas, vias de acesso e colocao de dados em dispositivos de armazenamento. Ele responsvel pela utilizao eficiente do espao de armazenamento, assim como pelo desempenho do sistema de banco de dados. 3. Administrador de aplicao Um esquema externo representa uma viso dos dados pelo programador de aplicao. Imagina-se que cada rea geral de aplicao ter seu prprio administrador de aplicao que prov os esquemas externos para aquela rea. Mas esses esquemas externos tm de ser consistentes e derivveis de um nico esquema conceituai. Observe que os mesmos esquemas externos podem ser usados por vrios programadores de aplicao, no necessariamente trabalhando no mesmo programa. Estes trs tipos de administradores representam trs diferentes papis que podem ser desempenhados por um indivduo ou um grupo de pessoas. Embora as distines entre esses trs tipos de administradores de banco de dados sejam claras em termos da arquitetura de trs esquemas do ANSI/X3/SPARC, no so claras nos ambientes de bancos de dados convencionais. Na verdade, o "administrador de banco de dados", como definido hoje em dia em muitas organizaes, tem todas as responsabilidades dos trs tipos de administradores mencionados. Em termos do mbito desta monografia, preocupamo-nos primariamente com a responsabilidade do administrador de empresa (ou seja, a tarefa de modelar o mundo real) e a responsabilidade do administrador de aplicao (ou seja, a tarefa de projetar os esquemas externos).
19
2.4 RELEVNCIA DO MTODO E-R

Em suma, se a arquitetura ANSI/X3/SPARC tornar-se realidade, o mtodo E-R pode ser usado das seguintes maneiras: 1. No projeto do esquema conceituai. 2. Na traduo do esquema conceituai em esquemas externos.
20
Modelagem de Dados
3. DIAGRAMA DE ENTIDADERELACIONAMENTO (E-R)

Neste captulo, vamos introduzir a tcnica diagramtica de entidade-relacionamento. Discutiremos primeiro o que so entidades e relacionamentos e, ento, explicaremos como descrever propriedades de entidades e relacionamentos. 3.1 ENTIDADES E RELACIONAMENTOS 3.1.1 Tipos de Entidade Uma entidade uma "coisa" que pode ser distintamente identificada. As entidades podem ser classificadas em diferentes tipos, tais como FUNCIONRIO e ACIONISTA. (Ver Figura 16.) No diagrama E-R, um tipo de entidade representado por um retngulo. (Ver Figura 17.)
FUNCIONRIO
ACIONISTA
Figura 16 Entidades e tipos de entidades.
21
FUNCIONRIO
ACIONISTA
Figura 17 Tipos de entidades so representados por retngulos.
H muitas "coisas" no inundo real. Algumas delas so de interesse para a empresa, e o resto no. responsabilidade do projetista de banco de dados selecionar os tipos de entidade que so mais adequados para sua empresa. 3.1.2 Tipos de Relacionamento Relacionamentos podem existir entre entidades. Por exemplo, CASAMENTO um relacionamento entre duas entidades humanas. (Ver Figura 18.) Os relacionamentos podem ser classificados em diferentes tipos de relacionamentos. Por exemplo, PROJ-FNC e PROJ-GERENTE so dois tipos de relacionamentos diferentes entre dois tipos de entidades, PROJ (projeto) e FUNC (funcionrio). Na notao diagramtica de entidade-relacionamento, um tipo de relacionamento representado por um losango com linhas conectadas a tipos de entidades relacionadas. (Ver Figura 19.) As notaes "m" e "1" associadas ao tipo de relacionamento PROJ-GERENTE na Figura 16 indicam que cada projeto tem apenas um gerente, mas que um funcionrio pode ser o gerente de muitos projetos. O V e "n" associados com o tipo de relacionamento PROJ-FUNC indicam que um mapeamento muitos-paramuitos. Isto , cada projeto pode consistir em vrios funcionrios e cada funcionrio pode estar associado a mais de um projeto. Observe que outros tipos de mapeamento entre entidades tambm so possveis. Por exemplo, o tipo de relacionamento CASAMENTO um mapeamento um-para-um entre entidades humanas. (Ver Figura 20.) possvel definir um tipo de relacionamento entre mais de dois tipos de entidades. Por exemplo, PARTE-FORN-PROJ, que descreve que partes so abastecidas por fornecedores especficos para projetos especficos (Figura 21), um tipo de relacionamento definido em trs tipos de entidades: PARTE, FORN (fornecedor) e PROJ (Figura 22).
22
Modelagem de Dados
CASAMENTO
Figura 18 CASAMENTO como um relacionamento entre duas entidades humanas.
PROJGERENTE
PROJ
FUNC
PROJ-FUNC
Figura 19 Tipos de relacionamentos so representados por losangos.
PESSOA
CASAMENTO
Figura 20 CASAMENTO como um tipo de relacionamento entre entidades humanas.
23
N PARTE 25 25 10 10 17 17
N FORNECEDOR 4 5 4 4 2 5
N PROJ 1 2 2 3 1
Figura 21
Informaes sobre relacionamentos PARTE-FORN-PROJ.
PARTE PARTE FORNPROJ
FORN
PROJ
Figura 22
PARTE-FORN-PROJ como um tipo de relacionamento.
Note que um relacionamento ternrio usualmente no pode ser substitudo por trs relacionamentos binrios. Por exemplo, o relacionamento ternrio PARTE-FORN-PROJ na Figura 21 substitudo por trs relacionamentos binrios: PARTE-FORN, FORN-PROJ e PROJ-PARTE. (Ver Figura 23.) Contudo, se quisermos construir o relacionamento ternrio partindo desses trs relacionamentos binrios, obteremos alguns "no-fatos". (Ver as entradas com asteriscos na Figura 24.) H muitos tipos de relacionamentos entre entidades e alguns deles so de interesse para a empresa: o projetista de banco de dados responsvel pela seleo dos tipos de relacionamentos relevantes para a empresa. Ele deve tambm especificar os tipos de mapeamento dos tipos de relacionamentos (ex.: um-para-um, um-para-muitos, muitos-para-muitos).
24
Modelagem de Dados
N PARTE 25 25 10 17 17
N FORN 4 5 4 2 5
N FORN 4 4 4 5 5 2
N PROJ 1 2 3 1 2 1
NPROJ 1 1 2 2 3
N PARTE 25 17 10 25 10
Figura 23 Informaes sobre trs relaes binrias: PARTE-FORN, FORN-PROJ e PROJ-PARTE.
N PARTE 25
N FORN 4 4 5 5 4 4 2 5
N PROJ 1 2 1 2 2 3 1 1
* *
25 25 25 10 10 17 17
Figura 24 Informaes geradas das trs relaes binrias da Figura 23.
3.2 DESCRIO DE ENTIDADES E RELACIONAMENTOS 3.2.1 Atributos e Valores Entidades e relacionamentos tm propriedades que podem ser expressas em termos de pares atributo-valor. Por exemplo, na afirmao "a IDADE DO FUNCIONRIO x 24", "IDADE" um atributo do funcionrio x e "24" o valor do atributo "IDADE". Os valores podem ser
25
classificados em diferentes tipos de valor, tais como N DE ANOS, QUANTIDADE e COR. Na notao diagramtica E-R, um tipo de valor representado por vim crculo (ver Figura 25) e um atributo representado por um ponteiro dirigido do tipo de entidade para o tipo de valor desejado.
FUNCIONRIO
N DO CIC
IDADE
N DO TELEFONE
234-55-7684 013-64-7777 315-88-4158
20 18 26 55
253-6606 253-9999 478-6574
N DO CIC F i g u r a 25
IDADE
N2 DO TELEFONE
Tipos de valores e atributos.
Em alguns casos, um atributo pode ter mais de um valor para uma determinada entidade. Por exemplo, "N DE TELEFONE" do funcionrio x pode ter dois valores: 253-6606 e 253-9999. Neste caso, colocamos "l:n" no ponteiro para indicar que um atributo de valores mltiplos. Isto similar ao conceito de "grupo de repetio" em processamento de dados convencional. Contudo, muitos atributos, tais como "IDADE" e "N DO CIC", tm um s valor. Para simplicidade, no associamos nada como "1:1" aos ponteiros no diagrama E-R para tais atributos. At agora, consideramos apenas os atributos de entidades. s vezes, estamos tambm interessados nas propriedades de um relacionamento. Por exemplo, podemos querer saber quando o funcionrio x comeou a trabalhar em um determinado projeto. A DATA DE INCIO no um atributo do FUNCIONRIO nem do PROJ, uma vez que seu valor depende tanto do funcionrio especfico quanto do projeto envol-
26
Modelagem de Dados
vido. Portanto, a DATA DE INCIO um atributo do relacionamento PROJ-FUNC. Um outro exemplo de atributo do relacionamento a PORCENTAGEM DE ESFORO, que a porcentagem de tempo que um funcionrio devota a um determinado projeto. (Ver Figura 26.) O conceito de atributo de relacionamento importante para compreender a semntica dos dados. O conceito semelhante ao de dados de relacionamento em sistemas de bancos de dados do tipo "rede" (CADASYL) e ao de dados de interseco em sistemas de bancos de dados do tipo hierrquico (tipo IMS).
PROJ
PROJFUNC DATA DE INCIO
FUNC
PORCENTAGEM DE ESFORO
9/15/75 7/22/76
20% 30% 90%
DATA DE INCIO PORCENTAGEM DE ESFORO Figura 26 Atributos de relacionamento.
3.2.2 Identificador de Entidade As entidades discutidas at agora so aquelas que existem em nossas mentes ou podem ser identificadas com um apontar de dedo. Quando algum pergunta, "De que cor isto?", "isto" ou compreendido tanto por quem est falando quanto pelo ouvinte, ou identificado apontando-se para o objeto. Este esquema de identificao pode funcionar para muito poucos objetos, porm encontraremos dificuldades quando quisermos comunicar a informao sobre uma variedade de objetos para muitas pessoas diferentes. Portanto, tanto na conversa do dia-a-dia como em processamento de dados computadorizado, precisa-
27
mos de um outro esquema para identificar entidades. Cada entidade tem muitos atributos, mas qual deles deve ser escolhido? A resposta que os atributos escolhidos devem ser capazes de identificar de forma absoluta as entidades. Por exemplo, podemos usar o atributo NOME para identificar funcionrios em uma pequena companhia, mas no em uma grande firma. Esses atributos escolhidos da entidade so chamados de identificadores de entidade. Em alguns casos, pode ser difcil ou inconveniente usar os atributos disponveis como identificadores da entidade. O que podemos fazer criar um atributo artificial que possa identificar incontestavelmente as entidades. Exemplos so N DO CIC, N DO FUNC, N DA PARTE e N DO PROJ. O conceito de identificador de entidade similar ao conceito de chave primria em processamento de dados convencional.
3.2.3 Identificador de Relacionamento

Os relacionamentos so identificados pelo uso de identificadores das entidades envolvidas no relacionamento. Por exemplo, se um projeto identificado por seu N DO PROJ e um funcionrio identificado por N DO FUNC, ento o relacionamento PROJ-FUNC identificado por ambos os N DO PROJ e n DO FUNC. Em algumas situaes, um tipo de relacionamento definido entre duas ocorrncias do mesmo tipo de entidade. Por exemplo, CASAMENTO um tipo de relacionamento definido entre ocorrncias do mesmo tipo de entidade, PESSOAS. Para identificar inequivocamente tais relacionamentos, usamos no apenas o identificador de entidade, mas tambm indicamos qual o papel que a entidade desempenha no relacionamento. No caso de CASAMENTO, devemos ligar os nomes MARIDO e MULHER ao identificador de entidade NOME, onde MARIDO e MULHER so os "papis" que eles desempenham na relao CASAMENTO. 3.3 TIPOS ESPECIAIS DE ENTIDADE E RELACIONAMENTO Nesta seo, vamos discutir alguns tipos especiais de entidade e relacionamento que so comumente encontrados.
28
Modelagem de Dados
3.3.1 Existncia-Dependente A existncia de uma entidade pode depender da existncia de um outro tipo de entidade. Por exemplo, a existncia de entidades FILHOS no banco de dados depende da existncia dos funcionrios associados. Em outras palavras, se um funcionrio deixa a companhia, no precisamos manter o registro de seus filhos. A Figura 27 ilustra o diagrama E-R para essa situao. FILHOS representado por um retngulo duplo, o que significa que um tipo de entidade "fraca". A existncia de uma entidade fraca depende da existncia de outras entidades. O "E" dentro do losango do relacionamento indica que um relacionamento existncia-dependente; o ponteiro associado ao losango do relacionamento indica a direo da dependncia. E possvel que o relacionamento existncia-dependente seja um mapeamento muitos-para-muitos. Por exemplo, se o pai deixa a companhia, as entidades FILHOS podem ainda existir se a me continuar sendo uma funcionria da companhia. Esta situao representada no diagrama E-R mostrado na Figura 28.
FUNC
FILHOS
Figura 27 Um relacionamento de tipo existncia-dependente e um tipo de entidade fraca.
29
FUNC M (PELO MENOS 1)
FILHOS
Figura 28 Uma relao existncia-dependente pode ser tambm um mapeamento muitos-para-muitos.
3.3.2 Dependncia de Identificador (ID) Se uma entidade no puder ser identificada inequivocamente por seus prprios atributos e tiver de ser identificada por seus relacionamentos com outras entidades, ela tem dependncia de identificador com as outras entidades. Por exemplo, "rua" s especfica dentro de uma cidade, uma cidade s especfica dentro de um Estado, e um Estado s especfico dentro de um pas. Para identificar precisamente o endereo de uma localizao, temos de especificar os nomes da cidade, Estado e pas, alm do nome da rua. dependncia de identificador indicada pelo "ID" no losango de relacionamento, e a direo do relacionamento indicada pelo ponteiro (Ver Figura 29); a maioria das dependncias ID est associada a existncias-dependentes. Contudo, a existnciadependente no implica a dependncia ID. Por exemplo, as entidades FILHOS na Figura 30 so identificadas com seus prprios atributos e o ID de seus pais (ver Figura 31), enquanto as entidades FILHOS na Figura 27 podem ser identificadas por seus prprios N DO FILHO. (Ver Figura 32.)
30
Modelagem de Dados
PAS
E&
ESTADO
E& ID
CIDADE
E& ID
RUA
Figura 29 Existncia-dependente e Dependncia ID.
31
FUNC
FILHOS
Figura 30 Existncia-dependente e Dependncia ID.
ID DOS FILHOS ID DO FUNC NOME NANCY BOK LAWRENCE BOK ROBERT JOHNSON CIC DO PAI OU ME 013-58-5545 172-66-6672 819-38-7776
D ADOS SOBRE FILHOS
IDADE 12 5 21
SEGURO-SADE BC/BS BC/BS TEM PLANO PRPRIO
Figura 31 Dependncia ID.
ID DOS FILHOS N DOS FILHOS 1011 1025 1044 NOME NANCY BOK LAWRENCE BOK ROBERT JOHNSON IDADE 12 5 21 SEGURO-SADE BC/BS BC/BS TEM PLANO PRPRIO
Figura 32 Sem Dependncia ID.
32
Modelagem de Dados
4. TRADUO DE DIAGRAMAS E-R EM DIAGRAMAS DE ESTRUTURA DE DADOS

4.1 DIAGRAMAS DE ESTRUTURA DE DADOS As estruturas lgicas de dados de bancos de dados suportadas pelo sistema tipo CODASYL (rede) de banco de dados podem ser expressas em termos de diagrama de estrutura de dados. Cada retngulo representa um tipo de registro, tal como FUNC e DEPENDENTE. O ponteiro representa um conjunto de estrutura de dados que conecta dois tipos de registro. O tipo de registro no qual o ponteiro se origina o tipo proprietrio de registro do conjunto de estrutura de dados, e o tipo de registro no qual o ponteiro termina o tipo membro de registro do conjunto de estrutura de dados. Na Figura 33, FUNC o tipo proprietrio de registro e DEPENDENTE o tipo membro de registro. Em um conjunto de estrutura de dados, o registro proprietrio pode ter zero, um ou mais registros membros (ocorrncias). Um registro membro em um conjunto de estrutura de dados tem exatamente um registro proprietrio. Em nosso exemplo, cada registro de funcionrio pode estar conectado a muitos registros de DEPENDENTE ou a nenhum. Contudo, cada registro de DEPENDENTE deve estar associado a exatamente um registro FUNC. Isto ilustrado na Figura 34. Conceitualmente, o ponteiro representa uma associao l:n (um-para-muitos) entre o tipo proprietrio de registro e o tipo membro de registro. Este tipo de associao pode tambm ser representado em forma de tabela. (Ver Figura 35.)
FUNC
TIPO "PROPRIETRIO" DE REGISTRO CONJUNTO DE ESTRUTURA DE DADOS
DEPENDENTE
TIPO "MEMBRO" DE REGISTRO
Figura 33 Um diagrama de estrutura de dados.
33
FUNC 2142
FUNC 1781
FUNC 2566
N DO FUNC
DEP A
DEP B
DEP C
DEP D
(A) ZERO DEPENDENTE
(B) TRS DEPENDENTES
(C) UM DEPENDENTE
Figura 34 Um registro PROPRIETRIO pode ter zero, um ou mais registros "membros*.

N DO FUNC 1781 1781 1781 2566 DEPENDENTE A B C D
Figura 35 Correspondncia um-para-muitos entre FUNCIONRIO e DEPENDENTES.
A Figura 36 ilustra uma estrutura de dados mais complicada. O tipo de registro FUNCIONRIO o registro proprietrio de um conjunto de estrutura de dados no qual FUNCIONRIO-HABILIDADE o registro membro. O tipo de registro FUNCIONRIO-HABILIDADE tambm o registro membro de um outro conjunto de estrutura de dados no qual o tipo de registro HABILIDADE o registro proprietrio. Na verdade, o registro FUNCIONRIO-HABILIDADE contm a informao sobre FUNCIONRIOS e HABILIDADES. Esse tipo de informao pode ser representado na forma de tabela, como mostrado na Figura 37. Podemos ver na Figura 37 que um funcionrio pode ter uma ou mais habilidades e que usualmente mais de um funcionrio tem uma habilidade especfica. Portanto, a relao entre funcionrios e habilidades m:n (muitos-para-muitos). Essa correspondncia m:n entre funcionrios e habilidades pode ser derivada da Figura 36. Os conjuntos
34
Modelagem de Dados
de estrutura de dados na Figura 36 mostram que existe um mapeamento l:m (um-para-muitos) entre o tipo de registro FUNCIONRIO e o tipo de registro FUNCIONRIO-HABILIDADE, e que um mapeamento semelhante (l:n) existe entre o tipo de registro HABILIDADE e o tipo de registro FUNC-HABILIDADE. Portanto, a correspondncia entre o registro FUNC e o tipo de registro habilidade m:n (muitos-para-muitos).
FUNC HABILIDADE
FUNC-HABILIDADE
Figura 36 Dois conjuntos de estrutura de dados tm o mesmo tipo "membro" de registro.
N DO FUNC 2142 2141 1781 2566
HABILIDADE COBOL PL/1 COBOL PL/1
Figura 37 Informaes cruzadas sobre FUNCIONRIOS e HABILIDADES.
O diagrama de estrutura de dados na Figura 36 pode ser implementado usando-se um conjunto de ponteiros, como mostrado na Figura 38. O conjunto de estrutura de dados entre o tipo de registro FUNC e o tipo de registro HABILIDADE representado pelas linhas contnuas, e o conjunto de estrutura de dados entre o tipo de registro HABILIDADE e o tipo de registro FUNC-HABILIDADE representado por linhas pontilhadas.
o mtodo entidade-relacionamento para projeto lgico de bancos de dados
35
Na Figura 38, como determinamos as habilidades de um funcionrio especfico? O primeiro passo localizar o registro de FUNC com o N DO FUNC = 2142, usando um algoritmo hashing ou algum outro mtodo. O segundo passo encontrar o primeiro registro FUNC-HABILIDADE relacionado com esse funcionrio. Por meio do ponteiro mostrado pela linha pontilhada, podemos encontrar um registro de habilidade com HABILIDADE-NOME = COBOL. Encontramos, ento, o segundo registro FUNCIONRIO-HABILIDADE relacionado com o mesmo registro de funcionrio (por meio dos ponteiros de linha contnua). Do registro FUNC-HABILIDADE, podemos seguir por intermdio do ponteiro de linha pontilhada para localizar um registro HABILIDADE com HABILIDADE-NOME = PL/1. No conseguimos, ento, encontrar mais nenhum registro FUNC-HABILIDADE relacionado com os mesmos registros de FUNCIONRIO (ou seja, encontramos a informao de que necessitvamos: o funcionrio com N DO FUNC = 2142 tem duas habilidades: COBOL e PL/1).
FUNC 2142
FUNC 1781
FUNC 2586
FUNCHABILIDADE
FUNCHABILIDADE
FUNCHABILIDADE
FUNCHABILIDADE
HABILIDADE COBOL
HABILIDADE PL/1
Figura 38 Implementao dos conjuntos de estrutura de dados da Figura 37 como conjuntos de ponteiros.
Como encontramos todos os funcionrios com uma habilidade especfica, digamos, COBOL? Primeiro, localizamos o registro HABILIDADE com HABILIDADE-NOME = COBOL. Ento, recuperamos todos os registros FUNC-HABILIDADE relacionados com o registro HABILIDADE. Para cada registro FUNCIONRIO-HABILIDADE, recuperamos, por meio do ponteiro de linha contnua, o registro FUNC correspondente. Fazendo isso, sabemos que h dois funcionrios com a habilidade COBOL, e seus nmeros so 2142 e 1781.
36
Modelagem de Dados
Uma outra maneira de implementar o diagrama de estrutura de dados da Figura 22 usar cadeias, como mostrado na Figura 39. As linhas contnuas conectam todos os registros FUNC-HABILIDADE relacionados com o mesmo registro HABILIDADE. Vamos ver como encontrar as habilidades do funcionrio com N DO FUNC = 2142. Em primeiro lugar, encontramos o primeiro registro FUNC-HABILIDADE por intermdio da cadeia de linha contnua. Do registro FUNCHABILIDADE, encontramos o registro de habilidade por meio da cadeia de linha pontilhada. Do registro FUNC-HABILIDADE procuramos o registro FUNC-HABILIDADE seguinte pela cadeia de linha slida. Do segundo registro FUNC-HABILIDADE, podemos determinar o registro de habilidade correspondente por meio da cadeia de linha pontilhada. Do segundo registro FUNC-HABILIDADE, no conseguimos encontrar mais nenhum registro FUNC-HABILIDADE na cadeia de linha contnua. Agora, sabemos todas as habilidades que o funcionrio 2142 tem. Similarmente, podemos encontrar todos os funcionrios com uma determinada habilidade seguindo atravs das cadeias.
FUNC 2142
FUNC 1781
FUNC 2566
FUNCHABILIDADE
FUNCHABILIDADE
FUNCHABILIDADE
FUNCHABILIDADE
COBOL
PL/1
Figura 39 Implementao dos conjuntos de estrutura de dados da Figura 27 como cadeias.
Um outro tipo de estrutura de dados, que pode usualmente ser encontrado em bancos de dados de processos de produo, mostrado na Figura 40. H dois tipos de registro: PARTE e PRD-REL (produo-relacionamento). Cada produto a ser fabricado consiste em muitas "partes" (componentes). Cada parte, por sua vez, feita de outras partes. O tipo
37
de registro PARTE contm informaes sobre a parte especfica. 0 tipo de registro PRD-REL contm as informaes sobre o relacionamento entre as partes. A Figura 41 ilustra esse tipo de relacionamento. Indica que, para produzir a PARTE N1, precisamos de cinco PARTES N 2e duas PARTES N 3. Podemos ver tambm que a PARTE N 3 uma subparte tanto da PARTE N1 quanto da PARTE N 4. H dois conjuntos de estrutura de dados na Figura 40 e eles podem ser implementados como "cadeias", como mostrado na Figura 42. As linhas contnuas representam a cadeia COMPONENTE e as linhas pontilhadas representam a cadeia ONDE USADA. Para encontrar os componentes de uma parte especfica, primeiro recuperamos todos os registros PRD-REL por meio da cadeia COMPONENTE e, ento, recuperamos as subpartes correspondentes pela cadeia ONDE USADA. Fazendo isso, evidenciamos que a PARTE N 4 consiste em uma PARTE N 3 e em duas PARTES N 5. Para descobrir onde uma parte especfica usada para produzir outras partes, primeiro recuperamos todos os registros PRD-REL relacionados com esse registro PARTE especfico por intermdio da cadeia ONDE USADA, e ento recuperamos os registros PARTE correspondentes por meio da cadeia COMPONENTE. Fazendo isso, descobrimos que duas PARTES N 5 so usadas na fabricao da PARTE N 4. As Figuras 33, 36 e 40 so os tipos bsicos de diagramas de estrutura de dados. Um banco de dados pode ser expresso em um grande diagrama de estrutura de dados baseado nesses trs modelos bsicos.
PARTE COMPONENTES ONDE USADA
PRD-REL
Figura 40 Dois conjuntos de estrutura de dados tm os mesmos tipos de registro "proprietrio" e "membro".
38
Modelagem de Dados
SUPERPARTE N 1 1 4 4
SUBPARTE N 2 3 3 5
QUANTIDADE 5 2 1 2
Figura 41 Relao de fabricao entre partes.
PARTE N 1
CADEIA COMPONENTE
PARTE N 4 CADEIA COMPONENTE

PRD-REL PRD-REL
PRD-REL
PRD-REL
CADEIA ONDE usada PARTE N 2
CADEIA ONDE USADA PARTE N 3
CADEIA ONDE USADA PARTE N 5
Figura 42 Implementao dos conjuntos de estrutura de dados da Figura 41.
4.2 REGRAS DE TRADUO Como vimos na seo anterior, o diagrama de estrutura de dados est mais prximo da organizao fsica do banco de dados que o diagrama de entidade-relacionamento. Usualmente, difcil desenhar um diagrama de estrutura de dados para as entidades e relacionamentos que so de interesse para a empresa. Portanto, propomos que o projetista de banco de dados primeiro desenhe um diagrama E-R para representar a viso da empresa quanto aos dados e, ento, traduza-o para um diagrama de estrutura de dados. Nesta seo, vamos discutir como traduzir um diagrama E-R para um diagrama de estrutura de dados. Identificamos algumas regras bsicas para traduo com base no tipo de
39
relacionamentos entre entidades. Comeamos com relacionamentos definidos por dois tipos de entidades, depois relacionamentos definidos por mais de dois tipos de entidades e, por fim, relacionamentos do mesmo tipo de entidade. As regras de traduo so as seguintes: 1. Relacionamentos definidos por dois tipos diferentes de entidades: a) O relacionamento uma correspondncia um-para-muitos (ou um-para-um). Por exemplo, o tipo de relacionamento DEPT-FUNC na Figura 43 (a) uma correspondncia umpara-muitos e pode ser transformada no diagrama de estrutura de dados da Figura 43 (b). Note que os tipos de entidades tais como DEPT e FUNC no diagrama E-R so tratados como tipos de registro no diagrama de estrutura de dados, enquanto o tipo de relacionamento DEPT-FUNC representado por um conjunto de estrutura de dados (um ponteiro) no diagrama de estrutura de dados. Similarmente, o tipo de relacionamento PROJ-GERENTE na Figura 44 (a), que restringe um gerente por projeto mas permite vrios projetos com o mesmo gerente, representado por um ponteiro no diagrama de estrutura de dados mostrado na Figura 44 (b).
DEPT
DEPT
DEPT fUNC
FUNC
DIAGRAMA E-R
FUNC
DIAGRAMA DE ESTRUTURA DE DADOS
Figura 43
40
Modelagem de Dados
FUNC
FUNC
PROJGERENTE
PROJ DIAGRAMA E-R
PROJ DIAGRAMA DE ESTRUTURA DE DADOS
Figura 44
b) O relacionamento uma correspondncia muitos-para-
muitos. Por exemplo, o tipo de relacionamento PROJ-FUNC na Figura 45 (a) uma correspondncia muitos-para-muitos. O diagrama de estrutura de dados correspondente mostrado na Figura 45 (b). Note que o tipo de relao PROJ-FUNC no traduzido em um ponteiro, mas em um tipo de registro. Podemos concluir que, se um tipo de relacionamento uma correspondncia muitos-para-muitos, ele ser traduzido em um tipo de registro com dois ponteiros apontando para ele, vindos dos tipos de registro de entidade relacionados. O tipo de registro PROJ-FUNC usualmente chamado um tipo de registro de relacionamento. Um exemplo semelhante mostrado na Figura 46. Uma vez que o tipo de relacionamento FUNC-HABILIDADE uma correspondncia muitos-paramuitos, traduzido em um tipo de registro (de relacionamento) no diagrama de estrutura de dados.

(a)
PROJ PROJ (b) FUNC
41
PROJ FUNC PROJ-FUNC FUNC DIAGRAMA E-R DIAGRAMA DE ESTRUTURA DE DADOS
Figura 45
FUNC
FUNC
HABILIDADE
FUNC HABILIDADE* FUNCHABILIDADE HABILIDADE DIAGRAMA E-R DIAGRAMA DE ESTRUTURA DE DADOS
Figura 46
2. Relacionamentos definidos por mais que dois tipos de entidades: Neste caso, o tipo de relacionamento no diagrama E-R ser traduzido em um tipo de registro de relacionamento no diagrama de estrutura de dados, seja o relacionamento uma correspondncia um-para-muitos ou de outro tipo. Por exemplo, o tipo de relacionamento PARTE-PROJ-FORN na Figura 47 (a) um tipo de relacionamento definido
42
Modelagem de Dados
por trs tipos de entidades e ser traduzido em um tipo de registro no diagrama de estrutura de dados, como mostrado na Figura 47 (b).
PARTE
PROJ
PARTEPROJ FORN'
FORN DIAGRAMA E-R
PARTE
PROJ
FORN
PARTE-PROJ-FORN DIAGRAMA DE ESTRUTURA DE DADOS
Figura 47
3. Relacionamentos binrios definidos pelo mesmo tipo de entidade: Se o relacionamento binrio for uma correspondncia um-paramuitos, tal como o tipo de relacionamento GERENCIADO na Figura 48 (a), ele poder ser transformado em pelo menos dois possveis diagramas de estrutura de dados, como mostrado nas Figuras 48 (b) e (c). Uma vez que a maioria dos sistemas de bancos de dados do tipo CADOSYL (rede)
43
no permite que o mesmo tipo de registro seja usado tanto como tipo de registro proprietrio quanto como tipo de registro membro de um conjunto de estrutura de dados, a Figura 48 (b) no vlida. Portanto, usaremos a Figura 48 (c) como o diagrama de estrutura de dados relativo ao diagrama E-R na Figura 48 (a). Para relacionamentos binrios com outros tipos de correspondncia, usaremos o mesmo tipo de diagrama de estrutura de dados. Por exemplo, PRD-REL um relacionamento de tipo de correspondncia muitos-para-muitos e seu diagrama de estrutura de dados equivalente mostrado na Figura 49 (b).
PESSOA
PESSOA
PESSOA
<GERENCIADO
GERENCIADO DIAGRAMA DE ESTRUTURA DE DADOS
DIAGRAMA E-R F i g u r a 48
PARTE
PARTE
PRD-REL
PRD-REL
Figura 49
44
Modelagem de Dados
5. ETAPAS NO PROJETO LGICO DE BANCO DE DADOS E EXEMPLOS

Nesta seo, vamos primeiro apresentar as principais etapas no projeto lgico de bancos de dados e, ento, dar trs exemplos de projetos de bancos de dados usando o mtodo E-R. 5.1 PRINCIPAIS ETAPAS NO PROJETO LGICO DE BANCOS DE DADOS O mtodo 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 INDSTRIA 5.2.1 Identificar Tipos de Entidades A primeira etapa identificar os tipos de entidade que interessam companhia. Em uma indstria, os tipos de entidade primrios so PARTE, FORN (fornecedor), PROJ, FUNC e DEPT. H outros tipos
45
de entidades que podem ser de interesse em uma indstria, 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 DEPT FUNC PROJFUNC FUNC PROJGERENTE PROJ PARTE M N INVENTRIO DEPSITO PROP FORN
PARTE
PRD-REL
Figura 50 Um diagrama E-R para uma indstria.
a) O tipo de relacionamento DEPT-FUNC descreve a associao do departamento com os funcionrios e um mapeamento um-para-muitos. 6) O tipo de relacionamento PROJ-FUNC descreve a associao dos projetos com os funcionrios e um mapeamento muitospara-muitos. Isto , cada funcionrio pode trabalhar em mais de um projeto, e cada projeto pode envolver mais de um funcionrio. 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 funcionrio 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 ternrio muitos-para-muitos-para-muitos. Isto , para uma parte especfica, 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. Tambm, cada fornecedor pode prover um projeto com mais de uma parte. Uma razo 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 relao ternria no pode ser substitudo por trs relaes binrias como PROJ-FORN, FORN-PARTE e PARTE-PROJ. e) O tipo de relao FORN POTENCIAL mantm 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 relao INVENTARIO mantm um registro de que parte est estocada em qual depsito 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 alm dos descritos acima. Contudo, uma vez que nosso propsito introduzir
47
conceitos-chaves do mtodo entidade-relacionamento, no entraremos em maiores detalhes. o leitor desta monografia pode acrescentar mais tipos de entidades e relaes Figura 50, de acordo com suas prprias 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 comear com os tipos de entidade DEPT e FUNC e sua relao DEPT-FUNC. A Figura 51 ilustra os atributos e tipos de valor para DEPT e FUNC. Os tipos de entidade e de relacionamento esto no domnio conceituai superior e os atributos e tipos de valor esto no domnio conceituai inferior. Na Figura 51, identificamos os seguintes tipos de valor: N DO DEPT, ORAMENTO, N DO FUNC, DATA, SALRIO e N DO TELEFONE. O DEPT tem trs atributos: N DO DEPT, ORAMENTO DESTE ANO e ORAMENTO DO ANO PASSADO. FUNC tem cinco atributos: N DO FUNC, DATA DE NASCIMENTO, SALRIO, TELEFONE RESIDENCIAL e TELEFONE COMERCIAL. Note que os atributos podem no ter os mesmos nomes que os tipos de valor, e que possvel ter mais de um atributo relacionado com o mesmo tipo de valor. Por exemplo, ORAMENTO DESTE ANO e ORAMENTO DO ANO PASSADO de DEPT usam o mesmo tipo de valor ORAMENTO. Um outro exemplo so 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 verso simplificada da Figura 51.
48
Modelagem de Dados
DOMNIO CONCEITUAL. SUPERIOR
DEPT
DEPT-FUNC,
FUNC
DOMNIO CONCEITUAL INFERIOR
N DO DEPT
DATA DE ORAMENTO DO ANO PASSADO INCIO DO DEPT DATA DE NASCIMENTO
N DO FUNC TELEFONE COMERCIAL SALRIO TELEFONE RESIDENCIAL
ORAMENTO DESSE ANO
N DO DEPT
ORAMENTO
DATA
N DO FUNC
SALRIO
N DO TELEFONE
Figura 51
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: % ESFORO, DATA, N DO PROJ, ORAMENTO e PROJ-NOME. H tambm cinco atributos na Figura 53 (embora alguns nomes de atributos estejam omitidos no diagrama): % ESFORO, DATA DE INCIO DO PROJ, N DO PROJ, ORAMENTO e PROJNOME. Note que a relao PROJ-FUNC tem dois atributos: DATA DE INCIO DO PROJ e % ESFORO. A DATA DE INCIO DO PROJ a data na qual o funcionrio comeou a trabalhar em um determinado projeto, e a % ESFORO a porcentagem de tempo que um funcionrio deve gastar em um determinado projeto. Note que o tipo de valor ORAMENTO o mesmo que o tipo de valor ORAMENTO 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 relao PROJ-FORN-PARTE e FORN POTENCIAL. A entidade FORN tem dois atributos: N DO FORN e ENDEREO. A entidade PARTE tem os atributos N DA PARTE, PESO e COR. A relao PROJ-FORN-PARTE tem o atributo QTD, que a quantidade de uma determinada parte fornecida por um determinado fornecedor para um determinado projeto. A relao FORN POTENCIAL no tem atributo. Os atributos da entidade PROJ j foram mostrados na Figura 53.

DOMNIO CONCEITUAL SUPERIOR
49
DEPT
DEPT-FUNC
FUNC
ORAMENTO DO DATA DE ANO PASSADO INCIO DO DEPT ORAMENTO DESSE ANO DATA DE NASCIMENTO
TELEFONE COMERCIAL TELEFONE RESIDENCIAL
(N DO DEPT)
ORAMENTO
DATA
N DO FUNC
SALRIO
NDO TELEFONE
Figura 52 Uma verso simplificada da Figura 51.
PROJ GERENTE. FUNC DOMNIO CONCEITUAL SUPERIOR PROJFUNC PROJ
DATA DE INCIO DO PROJETO
ESFORO
DATA
N DO PROJ
ORAMENTO
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 DEPSITO e das relaes INVENTRIO e PRD-REL. Uma entidade DEPSITO tem os atributos N DO DEPSITO e ENDEREO. Um relacionamento INVENTRIO tem os atributos QTD-MO, que a quantidade de uma parte estocada em um depsito. O relacionamento PRD-REL tem o atributo QTD-PARA-PRD, que a quantidade de uma subparte necessria para fazer uma superparte. Note que QTD--MO e QTD-PARA-PRD tm o mesmo tipo de valor QTD.
50
Modelagem de Dados
PROJ
PARTE
PROJFORNPARTE, DOMNIO CONCEITUAL SUPERIOR
FORN POTENCIAL
FORN
QTD
N DO FORN
ENDEREO
NDA PARTE
PESO
COR
Figura 54
Atributos e tipos de valor para FORN, PARTE e PROJ-FORN-PARTE.
DOMNIO CONCEITUAI. SUPERIOR
DEPSITO
INVENTARIO
PARTE
PRD-REL
QTD-A-MO
QTD-PARA-PRD
N DO DEPSITO
ENDEREO
QTD
Figura 55
Atributos e tipos de valor de DEPSITO, INVENTRIO e PRD-REL.
As Figuras 52-55 ilustram os atributos e tipos de valor necessrios para descrever as propriedades de entidades e relacionamentos que podem ser de interesse para uma ir indstria.
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 traduo discutidas na Seo 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 relao PROJ-GERENTE tambm 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 relao PROJFORN-PARTE um mapeamento ternrio muitos-para-muitos-paramuitos, ele traduzido em um tipo de registro.O tipo de relao PRD-REL traduzido em um tipo de registro, uma vez que um tipo de relao 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 tambm que o tipo de registro PROJ-FORN-PARTE apontado por trs 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 orientaes bsicas para agrupar atributos em registros so:
52
Modelagem de Dados
1. Todos os atributos de uma entidade sero colocados no mesmo tipo de registro. Por exemplo, os atributos de DEPT sero 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 sero 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 INCIO NO DEPT ser includo 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
FUNC
PROJ
FORN
PARTE
DEPSITO
PROJ-FUNC
PROJ-FORN-PARTE
PRD-REL
INVENTRIO
FORN POTENCIAL
Figura 56 O diagrama de estrutura de dados derivado do diagrama E-R da Figura 50.
N DO DEPT
ORAMENTO DESTE ANO
ORAMENTO 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
SALRIO
TELEFONE TELEFONE | COMERCIAL RESIDENCIAL
PARA O PRIMEIRO REGISTRO PROJ GERENCIADO POR ESTE FUNCIONRIO
PARA O PRIMEIRO REGISTRO FUNC-PROJ RELACIONADO COM ESTE FUNCIONRIO
Figura 58 Registro FUNC.
3. Se o tipo de relacionamento for traduzido em um tipo de registro, ento os atributos de relacionamento sero tratados como campos nesse tipo de registro. Por exemplo, o tipo de relao PROJ-FUNC na Figura 53 traduzido em um tipo de registro, e os atributos %ESFORO e DATA DE INCIO 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 so 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 PRXIMO REGISTRO PROJ GERENCIADO PELO MESMO FUNCIONRIO
N DO PROJ PROJ-NOME ORAMENTO
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 PRXIMO REGISTRO PROJ-FUNC PARA O MESMO FUNCIONRIO
DATA DE INCIO NO PROJ
% ESFORO
PARA O PRXIMO 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.
ENDEREO
PARA O PRIMEIRO FORN POTENCIAL RELACIONADO A ESTE FORNECEDOR
Figura 61 Registro FORN.

PARA O PRIMEIRO REGISTRO PARTE-FORN-PROJ RELACIONADO A ESTA PARTE PARA O PRIMEIRO REGISTRO FORN POTENCIAL RELACIONADO A ESTA PARTE
55
N DA PARTE PARA O PRIMEIRO REGISTRO PRD-REL NA CADEIA ONDE-USADA
PESO
COR
PARA O PRIMEIRO REGISTRO PRD-REL NA CADEIA COMPONENTE
PARA O PRIMEIRO REGISTRO INVENTRIO RELACIONADO A ESTA PARTE
Figura 62 Registro PARTE.
PARA O PRXIMO REGISTRO PARTE-FORN-PROJ PARA A MESMA PARTE
QTD
PARA O PRXIMO REGISTRO PARTE-FORN-PROJ PARA O MESMO FORNECEDOR PARA O PRXIMO REGISTRO PARTE-FORN-PROJ PARA O MESMO PROJETO
Figura 63 Registro PARTE-FORN-PROJ.
56
Modelagem de Dados
PARA O PRXIMO REGISTRO FORN-POTENCIAL PARA A MESMA PARTE
PARA O PRXIMO REGISTRO FORN POTENCIAL PARA O MESMO FORNECEDOR
Figura 64
Registro FORN POTENCIAL.
N DO DEPSITO
ENDEREO
PARA O PRIMEIRO REGISTRO INVENTRIO RELACIONADO A ESTE DEPSITO
Figura 65
Registro DEPSITO.
PARA O PRXIMO REGISTRO INVENTRIO PARA A MESMA PARTE
QTD--MO
PARA O PRXIMO REGISTRO INVENTRIO PARA O MESMO DEPSITO
Figura 66
Registro INVENTRIO.
Aps colocar todos os atributos nos tipos de registro, a questo seguinte decidir como implementar os conjuntos de estrutura de dados. Neste exemplo industrial, vamos usar cadeias como a implementao fsica dos conjuntos de estrutura de dados. Isto , vamos usar as Figuras
57
39 e 42 como a implementao fsica das Figuras 36 e 40, respectivamente. A partir dessas figuras, podemos fazer as seguintes observaes sobre como implementar ponteiros de cadeia: 1. Se o registro for o tipo de registro proprietrio de um conjunto de estrutura de dados, ele deve ter um ponteiro para a primeira ocorrncia 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 ocorrncia seguinte de registro membro na cadeia ou para a ocorrncia de registro proprietrio se este for o ltimo registro na cadeia. 3. Se um tipo de registro estiver envolvido em mltiplos conjuntos de estrutura de dados, ele deve conter vrios 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 proprietrio de um conjunto de estrutura de dados, ele tem um ponteiro apontando para a primeira ocorrncia de registro FUNC naquele departamento. 0 tipo de registro FUNC na Figura 58 tem trs ponteiros, uma vez que est envolvido em trs 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 proprietrio o tipo de registro DEPT, o tipo de registro FUNC manter um ponteiro para a ocorrncia seguinte de registro FUNC no mesmo departamento. Uma vez que o tipo de registro FUNC o registro proprietrio de um conjunto de estrutura de dados cujo tipo de registro membro PROJ, ele mantm um ponteiro para a primeira ocorrncia de registro PROJ gerenciada por esse funcionrio. Se o funcionrio no estiver gerenciando nenhum projeto, o valor do ponteiro ser nulo. Uma vez que o tipo de registro FUNC tambm o tipo de registro proprietrio do conjunto de estrutura de dados cujo tipo de registro membro PROJ-FUNC, ele mantm um ponteiro para a primeira ocorrncia 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 mantm dois ponteiros: um apontando para a ocorrncia seguinte do registro PROJ-FUNC para o mesmo funcionrio e o outro apontando para a ocorrncia 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 trs conjuntos de estrutura de dados, tem trs ponteiros, um para cada cadeia. Explicaes semelhantes podem ser dadas para os ponteiros em outros tipos de registro.
CLIENTE CLIENTE PEDIDO, PEDIDO DEPSITO
INVENTARIO;
LINHA
LINHA PARTE
PARTE
Figura 67 Diagrama E-R para um banco de dados de anotao de pedidos.
CLIENTE
CLIENTE PEDIDO
PEDIDO
DESPACHO PARA ENDEREOS
DESPACHO PARA ENDEREO
N DO CLIENTE
SALDO DE CONTA
LIMITE DE CRDITO
DESCONTO
ENDEREO
N DO PEDIDO
DATA
Figura 68 Atributos e tipos de valor para CLIENTE e PEDIDO.
59
5.3 EXEMPLO 2: UM BANCO DE DADOS DE ANOTAO DE PEDIDOS DE COMPRA 5.3.1 Identificar Tipos de Entidade
Uma anotao de pedidos lida com os pedidos dos clientes em itens, os quais podem estar armazenados em determinados depsitos. Os tipos de entidade importantes so: CLIENTE, PEDIDO, LINHA, PARTE, ITEM e DEPOSITO. (Ver Figura 69.) Cada pedido tem vrias linhas, cada uma declarando o nmero e a quantidade do item desejado.
PEDIDO LINHA LINHA PARTE PARTE
QTD PEDIDA
QTDA ENTREGAR
N DA LINHA
QTD
Figura 69
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 so existncias-dependentes e ID-dependentes das entidades PEDIDO correspondentes. Cada pedido tem vrias linhas, mas cada linha faz parte de apenas um pedido.
60
Modelagem de Dados
3. A relao LINHA-PARTE descreve que parte anotada nesta linha do pedido. Descreve tambm a quantidade da parte que est sendo pedida. Este tipo de relacionamento um mapeamento um-para-muitos. Cada linha contm apenas uma parte, mas cada parte pode ser colocada em muitas linhas (usualmente em pedidos diferentes). 4. A relao INVENTRIO mantm o controle de que parte est estocada em qual depsito, 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 anotao de pedidos de compra. Note que dois tipos de entidade, PARTE e DEPSITO, j foram discutidos no Exemplo 1. Na verdade, possvel 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 CRDITO, DESCONTO e DESPACHO PARA ENDEREOS. Cada cliente pode ter mais de um DESPACHO PARA ENDEREO. Cada entidade PEDIDO tem trs atributos: N DO PEDIDO, DESPACHO PARA ENDEREO e DATA. Cada pedido tem apenas um DESPACHO PARA ENDEREO. O relacionamento CLIENTE-PEDIDO no tem atributos. A Figura 69 ilustra os atributos e tipos de valor das propriedades das entidades LINHA e das relaes LINHA-PARTE. Uma entidade LINHA tem um atributo: N DA LINHA. Uma relao 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 so feitos.
61
Os atributos e tipos de valor para PARTE, INVENTRIO e DEPSITO 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 traduo discutidas na Seo 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 so mapeamentos um-para-muitos, eles so 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
PEDIDO
PARTE
DEPSITO
LINHA
INVENTRIO
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 contm no apenas os atributos da entidade LINHA, mas tambm os atributos dos relacionamentos LINHA-PARTE. (Ver Figuras 69 e 73.) Neste exemplo de banco de dados de anotao de
62
Modelagem de Dados
pedidos de compra tambm escolhemos cadeias como implementao fsica dos conjuntos de estrutura de dados. Os formatos de registro para os tipos de registro DEPSITO e INVENTRIO esto 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 REPETIO LIMITE DE CRDITO
N DO CLIENTE
SALDO DA CONTA
DESCONTO
DESPACHO PARA ENDEREOS
PARA O PRIMEIRO REGISTRO PEDIDO RELACIONADO A ESTE CLIENTE
Figura 71 Registro CLIENTE.
PARA O PRXIMO REGISTRO PEDIDO PERTENCENTE AO MESMO CLIENTE
N DO PEDIDO
DATA
PARA O PRIMEIRO REGISTRO LINHA RELACIONADO A ESTE PEDIDO
Figura 72 Registro PEDIDO.

PARA O PRXIMO REGISTRO LINHA PERTENCENTE AO MESMO PEDIDO
63
N DA LINHA
QTD PEDIDA
QTD A ENTREGAR
PARA O PRXIMO 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 tambm proporcionar um sistema computadorizado para busca de livros por categorias, palavras-chaves ou autores. Tipos de entidade importantes so: LIVRO, AUTOR, PALAVRA-CHAVE, CATEGORIA e FUNCIONRIO. (Ver Figura 75.)
64
Modelagem de Dados
SUBCHAVES
PALAVRACHAVE
SINNIMO
"CLASSIFICAO* PRIMARIA
CLASSIFICAO SECUNDARIA
AUTORIA PRINCIPAL AUTOR CO-AUTORIA LIVRO
CATLOGO PRIMRIO CATEGORIA
SUB-CATEGORIA
EMPRSTIMO
REQUISIO
FUNCIONRIO
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 vrios co-autores (alm 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 CATLOGO PRIMRIO e a outra o CATLOGO SECUNDRIO. Cada livro pertence a apenas uma categoria primria, mas pode pertencer a vrias categorias secundrias. Por exemplo, um livro relacionado a "fsico-qumica" pode ter "qumica" como sua categoria primria e
65
"fsica" como sua categoria secundria. H tambm um tipo de relacionamento chamado SUBCATEGORIA, que definido entre entidades CATEGORIA; isto , cada categoria pode ser dividida em subcategorias. Por exemplo, "cincia" pode ser divida em "fsica", "qumica", "matemtica" etc. Similarmente, existem dois tipos de relacionamentos entre entidades PALAVRA-CHAVE e entidades LIVRO: uma a CLASSIFICAO PRIMRIA e a outra a CLASSIFICAO SECUNDRIA. Cada palavra-chave pode ser dividida em vrias subchaves. Alm disso, cada palavra-chave pode ter vrios sinnimos. Por exemplo, "memria de computador", "memria principal" e "memria de ncleo" so sinnimos. Existem dois tipos de relacionamentos entre entidades FUNCIONRIO e entidades LIVRO: uma EMPRSTIMO e a outra REQUISIO. Cada funcionrio pode tomar emprestado vrios livros, mas um livro usualmente levado por apenas um funcionrio. Se um funcionrio no encontrar um livro na biblioteca, ele pode requisitar que o livro seja guardado para ele quando for devolvido. A relao REQUISIO 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 PUBLICAO, TTULO, EDIO e CDIGO. A Figura 77 ilustra os atributos e tipos de valor para CATEGORIA e CATLOGO SECUNDRIO. Cada entidade CATEGORIA tem um nome tal como "fsica" ou "qumica". Uma relao CATLOGO SECUNDRIO tem um atributo chamado RELEVNCIA, que um valor numrico (tal como 0,1,0,55, 0,9) atribudo por um bibliotecrio para indicar o
66
Modelagem de Dados
grau de relevncia entre um livro e uma categoria secundria. Convenciona-se que a categoria primria tem 1,0 como grau de relevncia. O conceito de RELEVNCIA pode estreitar o campo de ao de buscas no banco de dados. Similarmente, um relacionamento CLASSIFICAO SECUNDRIA na Figura 78 tambm tem um atributo chamado RELEVNCIA.
AUTORIA PRINCIPAL
AUTOR
LIVRO
CO-AUTORIA
DATA DE NASCIMENTO
DATA DE PUBLICAO
NOME
DATA
TITULO
EDIO
CDIGO
Figura 76
Atributos e tipos de valor para AUTOR e LIVRO.
CATLOGO PRIMRIO
LIVRO CATLOGO SECUNDRIO
CATEGORIA
SUBCATEGORIA
RELEVNCIA
NOME
Figura 77
Atributos e tipos de valor para CATEGORIA e CATLOGO SECUNDRIO.
67
CLASSIFICAO PRIMRIA LIVRO PALAVRACHAVE CLASSIFICAO SECUNDRIAS
SUBCHAVES
SINNIMO
RELEVNCIA
NOME
Figura 78
Atributos e tipos de valor para PALAVRA-CHAVE e CLASSIFICAO SECUNDRIA.
Os atributos e tipos de valor para FUNCIONRIO, EMPRSTIMO e REQUISIO so mostrados na Figura 79. Um FUNCIONRIO tem dois atributos: N DO FUNC e NOME. Um relacionamento EMPRSTIMO tem dois atributos: DATA DE SADA e DATA DE DEVOLUO. Esta informao pode ajudar o bibliotecrio a descobrir qual livro est com prazo vencido. Um relacionamento de REQUISIO tem um atributo chamado DATA DE REQUISIO, que proporciona a informao necessria para que o bibliotecrio atribua o livro ao funcionrio certo quando o livro estiver disponvel. 5.4.5 Traduzir o Diagrama E-R em um Diagrama de Estrutura de Dados Usando as regras de traduo discutidas na Seo 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 so 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 so 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).
EMPRSTIMO LIVRO REQUISIO FUNCIONRIO
DATA DE SAlDA
DATA DE DEVOLUO
DATA DE REQUISIO
DATA
(N DO FUNC)
NOME
Figura 79 Atributos e tipos de valor para FUNCIONRIO, EMPRSTIMO e REQUISIO.

PALAVRACHAVE
AUTOR
FUNCIONRIO
CATEGORIA
LIVRO
SUBCATEGORIA
SUBCHAVES
SINNIMO
CO-AUTORIA
REQUISIO
CATALOGO SECUNDRIO
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 tambm so 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 so semelhantes aos discutidos nos dois exemplos anteriores. Portanto, omitimos a discusso aqui.
70
Modelagem de Dados
6. OUTRAS CONSIDERAES EM PROJETO LGICO DE BANCO DE DADOS

6 1 OUTRAS REGRAS DE TRADUO DE DIAGRAMAS . E-R PARA DIAGRAMAS DE ESTRUTURA DE DADOS
As regras de traduo de diagramas E-R para diagramas de estrutura de dados discutidas na Seo 4.2 so comumente usadas, mas no so 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 so traduzidos em tipos de registro, exceto os tipos de relacionamentos EXISTNCIA 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 FUNC PROJ FORN PARTE DEPSITO
DEPT-FUNC
PROJGERENTE
PROJ-FORNPARTE
FORN POTENCIAL
INVENTRIO
PROJ-FUNC
PRD-REL
Figura 81 Outro diagrama de estrutura de dados derivado do diagrama E-R da Figura 50.
71
CLIENTE
PEDIDO
PARTE
DEPSITO
LINHA
CLIENTE-PEDIDO
LINHA-PARTE
INVENTRIO
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 recuperao e atualizao. Contudo, pode proporcionar um nvel mais alto de independncia de dados. Isto , programas e estruturas de bancos de dados no precisam ser alterados quando um determinado tipo de relacionamento muda de um mapeamento um-para-muitos para um mapeamento muitos-para-muitos. Essa mudana em tipos de mapeamentos converter um conjunto de estrutura de dados em um tipo de registro ou vice-versa se as regras de traduo discutidas na Seo 4.2 forem usadas, mas nenhuma mudana necessria se for utilizada a regra simplificada discutida nesta seo. 6.2 MODIFICAR O DIAGRAMA DE ESTRUTURA DE DADOS POR RAZES DE DESEMPENHO E ARMAZENAMENTO Depois de obtermos diagramas de estrutura de dados a partir de diagramas E-R usando as regras de traduo, podemos querer modificlos para conseguir melhor desempenho do sistema ou melhor utilizao do espao de armazenamento. Por exemplo, podemos dividir o registro FUNC das Figuras 56, 58 e 81 em dois registros. Um o registro FUNC PRINCIPAL que contm campos N DO FUNC, DATA DE NASCIMENTO e SALRIO. (Ver Figura 83.) O outro o FUNC-DETALHE, que contm
72
Modelagem de Dados
os campos DATA DE INCIO NO DEPT, TELEFONE COMERCIAL e TELEFONE RESIDENCIAL. (Ver Figura 84.) Note que necessrio um ponteiro para conectar as ocorrncias desses dois tipos de registro. Os diagramas de estrutura de dados nas Figuras 56 e 81 sero modificados pela incorporao da Figura 85. Uma das razes para dividir um registro em dois ou trs registros melhorar o desempenho de recuperao. Por exemplo, espera-se que os campos no registro FUNC PRINCIPAL venham a ser usados com mais freqncia do que os campos no registro FUNC-DETALHE. Uma vez que no queremos recuperar os dados que no so necessrios, seria uma boa idia dividir o registro em dois. Uma outra razo para dividir um registro em dois a limitao do tamanho do registro. Em alguns casos devido a limitaes de hardware/software, pode ser prefervel limitar o tamanho do registro a um comprimento fixo (digamos, 256 bytes). Se um registro "conceituai" for maior do que o comprimento mximo de um registro, ele poder ter de ser dividido em dois ou mais registros.
PARA O PRXIMO REGISTRO FUNC NO MESMO DEPARTAMENTO
N DO FUNC
DATA DE NASCIMENTO
SALRIO
PARA O PRIMEIRO REGISTRO PROJ GERENCIADO POR ESTE FUNCIONRIO
PARA O REGISTRO FUNC-DETALHE
PARA O PRIMEIRO REGISTRO FUNC-PROJ RELACIONADO A ESTE FUNCIONRIO
Figura 83 Registro FUNC PRINCIPAL.
73
PARA O REGISTRO FUNC PRINCIPAL
DATA DE INCIO 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 prtica comum fatorar os grupos de repetio. Por exemplo, o DESPACHO PARA ENDEREOS nas Figuras 68 e 71 um grupo de repetio (ou seja, h muitos valores de dados para este atributo). Podemos retirar esse campo e coloc-lo em um novo registro chamado DESPACHO PARA ENDEREO. (Ver Figuras 86 e 87.) Os diagramas de estrutura de dados nas Figuras 70 e 82 sero modificados pela incorporao 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, ento, 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 CRDITO
DESCONTO
PARA O PRIMEIRO REGISTRO DESPACHO PARA ENDEREO PARA ESTE CLIENTE
Figura 86
Um "novo" registro CLIENTE.
PARA O PRXIMO REGISTRO DESPACHO PARA ENDEREO PARA O MESMO CLIENTE
Figura 87
Registro DESPACHO PARA ENDEREO.
CLIENTE
Figura 88
Um diagrama de estrutura de dados para CLIENTE e DESPACHO PARA ENDEREO.
75
7. PROJETO DE BANCOS DE DADOS HIERRQUICOS

Em sistemas de bancos de dados hierrquicos como o IMS da IBM, os dados sero organizados em hierarquias de registros. (Ver Figura 7.) Nesta seo, faremos uma breve discusso sobre como usar o mtodo E-R para o projeto de banco de dados hierrquicos. 7.1 REGRAS DE TRADUO Uma vez que os tipos de relacionamento hierrquicos permitem apenas mapeamentos um-para-muitos, temos de traduzir os tipos de relacionamentos com mapeamentos muitos-para-muitos em estruturas hierrquicas. H pelo menos cinco estruturas lgicas de dados possveis para o diagrama E-R sobre PROJ-FUNC na Figura 89. Essas cinco estruturas lgicas de dados esto 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 lgica de dados ser eficiente para determinados tipos de perguntas mas no para outros. Por exemplo, se queremos encontrar todos os funcionrios 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 necessria se quisermos encontrar todos os projetos associados a um determinado funcionrio. 3. Uma vez que nem a estrutura lgica 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 manuteno de dados redundantes. 4. Em IMS, podemos escolher a estrutura lgica de dados da Figura 93, de forma que o tipo de registro FUNC ser o "pai fsico" do PROJ-FUNC, e o tipo de registro PROJ ser o "pai lgico". 5. Uma alternativa em IMS tornar o tipo de registro FUNC o "pai lgico" em vez de "pai fsico" do tipo de registro PROJFUNC. (Ver Figura 94.)
FUNC
PROJ-FUNC
PROJ
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.
mtodo entidade-relacionamento para projeto lgico de bancos de dados
77
FUNC
PROJ
PROJ Figura 92 Mantendo dois bancos de dados.
FUNC
FUNC
PROJ
PROJFUNC Figura 93 PROJ como o "pai lgico" de PROJ-FUNC.
FUNC
PROJ
PROJFUNC Figura 94 FUNC como o "pai lgico" de PROJ-FUNC.
EXEMPLO Para o diagrama E-R do banco de dados de anotao de pedidos de compra (Figura 67), podemos derivar muitas estruturas lgicas hierrquicas possveis. Uma estrutura possvel mostrada na Figura 95, na qual o tipo de registro LINHA o "filho fsico"do tipo de registro PEDIDO e o "filho lgico" do tipo de registro PARTE.
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 PARTE
PEDIDO
DEPSITO
LINHA
Figura 95 Um banco de dados hierrquico para o diagrama E-R da Figura 67.
79
8. COMENTRIOS FINAIS
Nesta obra, esboamos um novo mtodo em projeto lgico de bancos de dados: o Mtodo Entidade-Relacionamento. A base do mtodo foi testada em ambientes do mundo real e mostrou-se fcil de entender e fcil de usar. Em particular, o diagrama E-R mostrou-se uma ferramenta de comunicao valiosa e efetiva entre pessoas ligadas e no ligadas ao processamento eletrnico de dados. Um de nossos projetos atuais no M.I.T. desenvolver diagramas E-R detalhados e padronizados para vrios tipos de empresas, como fbricas, bancos, varejo etc, que possam ser usados para auxiliar o projeto de banco de dados ou o planejamento do sistema de informaes. Alguns trabalhos relevantes para o mtodo E-R esto relacionados nas referncias. Qualquer sugesto para aperfeioar o mtodo E-R ser apreciada.
80
Modelagem de Dados
9. REFERNCIAS
1. CHEN, Peter, P.S. "The Entity-Relationship Model: Towards a Unified View of Data", ACM Transaction on Database Systems, vol. 1, n1, (maro-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.
So Paulo: Makron Books, 1990. 80p.

Modelagem de Dados, Peter Chen

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Modelagem de Dados, Peter Chen

Hochgeladen von

Copyright:

Verfügbare Formate

Rafael Gama de Macedo Jr.

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

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

NOME ROBERT JOHNSON

ENDEREO BOSTON, MASS.

VALORES Figura 1 Um registro de FUNCIONRIO.

SAN JOSE, CALIF.

REGISTROS DE FUNCIONRIO FUNCIONRIO A

REGISTROS DE DEPARTAMENTO DEPARTAMENTO A

Um banco de dados com dois tipos de registros.

Estrutura lgica de dados do banco de dados.

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

1.2 PROJETO LGICO DE BANCO DE DADOS E PROJETO FSICO DE BANCO DE DADOS

FUNCIONRIO A PROJETO FlSICO DE DEPARTAMENTO BANCO DE DADOS FUNCIONRIO

PONTOS DE INTERESSE PARA A EMPRESA

Projeto lgico e fsico de banco de dados.

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

Estrutura "hierrquica" de dados.

Estrutura de dados "de rede".

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

TABELA DE HABILIDADE NH 5 NOME-H FORTRAN COBOL

TABELA DE FUNCIONRIO-HABILIDADE NOME JOHNSON JOHNSON GOODMAN GOODMAN

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

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

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

ESTRUTURA LGICA DE DADOS (ESQUEMA DO USURIO)

PONTOS DE INTERESSE PARA A EMPRESA

PROJETO LGICO DE BANCO DE DADOS (COMO?)

Projeto Lgico de Banco de Dados.

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

PONTOS DE INTERESSE PARA A EMPRESA

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

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

2. MTODO E-R E PROPOSTA ANSI/X3/SPARC

USURIO MUNDO REAL ESQUEMA , DO USURIO

PONTOS DE INTERESSE PARA A EMPRESA

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

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

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

2.4 RELEVNCIA DO MTODO E-R

3. DIAGRAMA DE ENTIDADERELACIONAMENTO (E-R)

Figura 16 Entidades e tipos de entidades.

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

Figura 17 Tipos de entidades so representados por retngulos.

Figura 18 CASAMENTO como um relacionamento entre duas entidades humanas.

Figura 19 Tipos de relacionamentos so representados por losangos.

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

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

Informaes sobre relacionamentos PARTE-FORN-PROJ.

PARTE PARTE FORNPROJ

PARTE-FORN-PROJ como um tipo de relacionamento.

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

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

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

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

253-6606 253-9999 478-6574

Tipos de valores e atributos.

PROJFUNC DATA DE INCIO

20% 30% 90%

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

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

3.2.3 Identificador de Relacionamento

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