Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
NOMES DE CAMPO
SALRIO 10K
ROBERT JOHNSON
10K
BOSTON, MASS.
LEE GOODMAN
25 K
N.Y., N.Y
JEAN WALTERS
16K
Figura 2
Um arquivo de FUNCIONRIO.
Modelagem de Dados
UM BANCO DE DADOS
FUNCIONRIO B
DEPARTAMENTO B
FUNCIONRIO C
Figura 3
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
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 B
DEPARTAMENTO A
FUNCIONRIO A
FUNCIONRIO B
DEPARTAMENTO A
FUNCIONRIO A
FUNCIONRIO B
Figura 6
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
"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
TABELA DE FUNCIONRIO NOME JOHNSON GOODMAN WALTERS SALRIO 10K 15 K 16 K ENDEREO BOSTON NYC SAN JOS
NH
1 2 1 5
2
1
PM
Figura 9
MUNDO REAL
HIERRQUICA
REDE
RELACIONAL
Figura 10
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
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
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.
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
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
20
Modelagem de Dados
FUNCIONRIO
ACIONISTA
21
FUNCIONRIO
ACIONISTA
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
PROJGERENTE
PROJ
FUNC
PROJ-FUNC
PESSOA
CASAMENTO
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
FORN
PROJ
Figura 22
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
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
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
20 18 26 55
N DO CIC F i g u r a 25
IDADE
N2 DO TELEFONE
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
FUNC
PORCENTAGEM DE ESFORO
9/15/75 7/22/76
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.
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
29
FILHOS
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
31
FUNC
FILHOS
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
IDADE 12 5 21
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
32
Modelagem de Dados
FUNC
DEPENDENTE
33
FUNC 2142
FUNC 1781
FUNC 2566
N DO FUNC
DEP A
DEP B
DEP C
DEP D
(C) UM DEPENDENTE
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
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.
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
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.
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
PARTE N 1
CADEIA COMPONENTE
PRD-REL
PRD-REL
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
Figura 44
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.
41
Figura 45
FUNC
FUNC
HABILIDADE
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'
PARTE
PROJ
FORN
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
DIAGRAMA E-R F i g u r a 48
PARTE
PARTE
PRD-REL
PRD-REL
Figura 49
44
Modelagem de Dados
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
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.
48
Modelagem de Dados
DEPT
DEPT-FUNC,
FUNC
N DO DEPT
N DO DEPT
ORAMENTO
DATA
N DO FUNC
SALRIO
N DO TELEFONE
Figura 51
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.
49
DEPT
DEPT-FUNC
FUNC
ORAMENTO DO DATA DE ANO PASSADO INCIO DO DEPT ORAMENTO DESSE ANO DATA DE NASCIMENTO
(N DO DEPT)
ORAMENTO
DATA
N DO FUNC
SALRIO
NDO TELEFONE
ESFORO
DATA
N DO PROJ
ORAMENTO
PROJNOME
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
FORN POTENCIAL
FORN
QTD
N DO FORN
ENDEREO
NDA PARTE
PESO
COR
Figura 54
DEPSITO
INVENTARIO
PARTE
PRD-REL
QTD-A-MO
QTD-PARA-PRD
N DO DEPSITO
ENDEREO
QTD
Figura 55
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
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
N DO DEPT
53
N DO FUNC
SALRIO
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
% ESFORO
REGISTRO FORN.
ENDEREO
55
PESO
COR
QTD
PARA O PRXIMO REGISTRO PARTE-FORN-PROJ PARA O MESMO FORNECEDOR PARA O PRXIMO REGISTRO PARTE-FORN-PROJ PARA O MESMO PROJETO
56
Modelagem de Dados
PARA O PRXIMO REGISTRO FORN-POTENCIAL PARA A MESMA PARTE
Figura 64
N DO DEPSITO
ENDEREO
Figura 65
Registro DEPSITO.
QTD--MO
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
CLIENTE
CLIENTE PEDIDO
PEDIDO
N DO CLIENTE
SALDO DE CONTA
LIMITE DE CRDITO
DESCONTO
ENDEREO
N DO PEDIDO
DATA
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
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
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
N DO PEDIDO
DATA
63
N DA LINHA
QTD PEDIDA
QTD A ENTREGAR
N DA PARTE
PESO
COR
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
SUB-CATEGORIA
EMPRSTIMO
REQUISIO
FUNCIONRIO
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.
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
CATLOGO PRIMRIO
CATEGORIA
SUBCATEGORIA
RELEVNCIA
NOME
Figura 77
67
SUBCHAVES
SINNIMO
RELEVNCIA
NOME
Figura 78
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).
DATA DE SAlDA
DATA DE DEVOLUO
DATA DE REQUISIO
DATA
(N DO FUNC)
NOME
AUTOR
FUNCIONRIO
CATEGORIA
LIVRO
SUBCATEGORIA
SUBCHAVES
SINNIMO
CO-AUTORIA
REQUISIO
CATALOGO SECUNDRIO
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.
70
Modelagem de Dados
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
73
FUNC PRINCIPAL
FUNC-DETALHE
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
Figura 86
Figura 87
CLIENTE
Figura 88
75
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
FUNC
PROJ
PROJ
FUNC
77
FUNC
PROJ
FUNC
FUNC
PROJ
FUNC
PROJ
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
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.