Modelagem de Dados Peter Chen

Prévia do material em texto

O MÉTODO
ENTIDADE-RELACIONAMENTO
PARA PROJETO LÓGICO
DE BANCOS DE DADOS
1. INTRODUÇÃO
O gerenciamento de dados tornou-se uma das atividades mais
importantes em muitas organizações. Conforme nos movemos para uma
sociedade cada vez mais orientada para a informação, a determinação de
como organizar os dados para maximizar sua utilidade torna-se um
problema muito importante. Sistemas de arquivo e sistemas de banco de
dados baseados em computador simplificam a tarefa de manter e recu-
perar uma grande quantidade de dados. Contudo, o problema de como
organizar os dados para utilizar a capacidade total do sistema de ar-
quivos ou do banco de dados não é bem compreendido por muitas pessoas
que trabalham em processamento de dados. A finalidade desta obra é
proporcionar uma metodologia que torne o processo de organização de
dados mais fácil de ser compreendido e seguido.
1.1 TERMINOLOGIA BÁSICA
Nesta seção, vamos explicar vários conceitos básicos em geren-
ciamento de dados.
1
Rafael Gama de Macedo Jr.
Um registro é uma coleção de itens de dados. Por exemplo, um
registro de funcionário contém os dados relevantes de um funcionário
específico. (Ver Figura 1.) Um registro é dividido em vários campos. Na
Figura 1, NOME, SALÁRIO e ENDEREÇO são os nomes dos campos de
um registro de funcionário. Nomes de campos são utilizados para inter-
pretar o significado dos itens de dados (ou valores) no registro. Portanto,
"ROBERT JOHNSON" é o "NOME" de um funcionário específico e "10K"
é o seu "SALÁRIO". Um arquivo é uma coleção de registros do mesmo
tipo. Por exemplo, o arquivo de FUNCIONÁRIO é uma coleção de regis-
tros de FUNCIONÁRIO. (Ver Figura 2.)
Um banco de dados é uma coleção de registros de tipos dife-
rentes. (Ver Figura 3.) Os registros em um banco de dados são inter-
ligados, de forma que itens de dados relevantes em registros diferentes
possam ser recuperados sem dificuldade. Por exemplo, podemos desejar
interligar todos os registros de funcionários que trabalhem para o mes-
mo departamento (Ver Figura 4), de modo que seja fácil encontrar quem
trabalha para um departamento específico. A Figura 4 ilustra a estru-
tura física de dados do banco de dados na qual as conexões entre re-
gistros de DEPARTAMENTO e registros de FUNCIONÁRIO são
implementadas por cadeias. Um registro de DEPARTAMENTO tem um
ponteiro que aponta para o primeiro registro de FUNCIONÁRIO na
cadeia. Cada registro de FUNCIONÁRIO na cadeia tem um ponteiro que
aponta para o registro de FUNCIONÁRIO seguinte. O último registro de
FUNCIONÁRIO aponta de volta para o registro de DEPARTAMENTO.
A Figura 4 ilustra os relacionamentos de ocorrências de registros no
banco de dados, mas é detalhada demais para ser útil na comunicação de
relacionamentos-chaves no banco de dados. A Figura 5 é uma maneira
simples de representar a organização de registros da Figura 4. Cada
retângulo na Figura 5 representa um tipo de registro e a seta representa
a associação de registros de FUNCIONÁRIO com seus registros de
DEPARTAMENTO. Há uma outra distinção entre as Figuras 4 e 5; a
Figura 5 representa a estrutura lógica de dados do banco de dados, uma
vez que mostra apenas a conexão entre o tipo de registro de DEPARTA-
MENTO e o tipo de registro de FUNCIONÁRIO, mas não mostra como
essa conexão é implementada.
2 Modelagem de Dados
Figura 2 Um arquivo de FUNCIONÁRIO.
O método entidade-relacionamento para projeto lógico de bancos de dados 3
LEE GOODMAN 25 K N.Y., N.Y
JEAN WALTERS 16K SAN JOSE, CALIF.
ROBERT JOHNSON 10K BOSTON, MASS.
NOME SALÁRIO ENDEREÇO
NOMES DE CAMPO
VALORES
Figura 1 Um registro de FUNCIONÁRIO.
ROBERT JOHNSON 10K BOSTON, MASS.
Figura 4 Registros relevantes no banco de dados são interligados (estrutura física
de dados do banco de dados).
Figura 5 Estrutura lógica de dados do banco de dados.
4 Modelagem de Dados
FUNCIONÁRIO
DEPARTAMENTO
FUNCIONÁRIO A
DEPARTAMENTO A
FUNCIONÁRIO B
DEPARTAMENTO B
FUNCIONÁRIO C
REGISTROS DE FUNCIONÁRIO
UM BANCO DE DADOS
REGISTROS DE DEPARTAMENTO
DEPARTAMENTO A
DEPARTAMENTO B
FUNCIONÁRIO A
FUNCIONÁRIO B
FUNCIONÁRIO C
Figura 3 Um banco de dados com dois tipos de registros.
O método entidade-relacionamento para projeto lógico de bancos de dados 5
1.2 PROJETO LÓGICO DE BANCO DE DADOS E
PROJETO FÍSICO DE BANCO DE DADOS
O projeto de bancos de dados pode ser dividido em duas etapas:
projeto lógico e projeto físico. (Ver Figura 6.)
O projeto físico de banco de dados é o processo de selecionar uma
estrutura física de dados para uma dada estrutura lógica de dados. Por
exemplo, há pelo menos três (3) estruturas físicas de dados possíveis
dentro de um sistema de banco de dados CODASYL para dar suporte à
mesma estrutura lógica de dados da Figura 6. A primeira é usar um
"ponteiro para frente" para ligar todos os registros de FUNCIONÁRIO
no mesmo departamento. A segunda é acrescentar "ponteiros para trás"
aos registros de FUNCIONÁRIO. A terceira é usar um "conjunto de
ponteiros" no qual o registro de DEPARTAMENTO mantém ponteiros
para todos os registros de FUNCIONÁRIO relacionados. Cada uma
dessas três estruturas físicas de dados tem suas vantagens e desvanta-
gens. A primeira é fácil de implementar e é adequada para proces-
samento seqüencial dos registros de FUNCIONÁRIO. A segunda torna
relativamente fácil encontrar os registros de FUNCIONÁRIO anteriores
na cadeia à custa de mais espaço de armazenamento necessário devido
aos ponteiros para trás (também torna o processo de exclusão mais
eficiente). A principal vantagem da terceira estrutura física de dados é
que todos os registros de FUNCIONÁRIO que pertençam ao mesmo
departamento podem ser recuperados simultaneamente. É importante
observar que nenhuma estrutura física de dados é universalmente
ótima. A finalidade do projeto físico de banco de dados é selecionar a
estrutura física de dados que seja mais adequada para determinado
ambiente de aplicação. Embora o projeto físico de banco de dados seja
um tópico importante, não vamos aprofundar a discussão a esse respeito
nesta obra.
O projeto lógico de banco de dados é o processo de planejar a
estrutura lógica de dados para o banco de dados. (Ver Figura 6.) Isto
envolve uma análise do ambiente de aplicação e dos tipos de estruturas
lógicas de dados disponíveis no sistema de banco de dados. Atualmente,
há poucas ferramentas para auxiliar o processo de projeto lógico de
banco de dados; o projetista de banco de dados geralmente tem de contar
com sua intuição e experiência. Como resultado, muitos bancos de dados
existentes hoje em dia não são adequadamente projetados.
Nesta obra, vamos nos concentrar no processo de projeto lógico
de banco de dados e introduzir uma ferramenta útil e prática para
ajudar o projetista de banco de dados.
Figura 6 Projeto lógico e físico de banco de dados.
1.3 SISTEMAS DE BANCOS DE DADOS E MODELOS DE
DADOS
Há muitos sistemas de bancos de dados em uso no momento. Eles
podem ser classificados em três (3) categorias principais: hierárquico, de
rede e relacionai. Uma das principais diferenças entre eles é o tipo de
estruturas lógicas de dados que podem ser suportadas. Sistemas hierár-
6 Modelagem de Dados
FUNCIONÁRIO
FUNCIONÁRIO A FUNCIONÁRIO B
DEPARTAMENTO A
FUNCIONÁRIO BFUNCIONÁRIO A
DEPARTAMENTO A
PONTOS DE
INTERESSE
PARA A
EMPRESA
MUNDO REAL ESTRUTURA LÓGICA DE DADOS ESTRUTURA FÍSICA DE DADOS
DEPARTAMENTO A
FUNCIONÁRIO A FUNCIONÁRIO B
DEPARTAMENTO
PROJETO
FlSICO
DE
BANCO
DE
DADOS
O método entidade-relacionamento para projeto lógico de bancos de dados 7
quicos de bancos de dados, como o Information Management System
(IMS) da IBM, requerem que os tipos de registro de dados sejam organi-
zados em uma forma hierárquica. (Ver Figura 7.) Essa estrutura hierár-
quica de dados funciona bem com alguns bancos de dados, mas torna-sedifícil projetar bancos de dados usando um sistema hierárquico quando
não existe uma hierarquia natural entre os tipos de registro. Sistemas
de bancos de dados em rede (ou CODASYL), tais como o Integrated Data
Store (IDS) da Honeywell, o DMS-1100 da UNIVAC e o IDMS da
Cullinane, proporcionam capacidades mais complexas de estruturas de
dados do que os sistemas hierárquicos. Por exemplo, os sistemas de rede
permitem que um tipo de registro tenha múltiplos tipos de registro como
"pais". (Ver Figura 8.) Os sistemas relacionais (a maioria dos quais é
experimental no momento)* usam tabelas como estruturas lógicas de
dados. (Ver Figura 9.)
Em resumo, o projeto lógico de bancos de dados preocupa-se com
a organização de dados em uma forma aceitável para o sistema de banco
de dados subjacente. (Ver Figura 10.)
Figura 7 Estrutura "hierárquica" de dados.
"No momento" se refere a 1977, atualmente esses sistemas são de uso generalizado. (N. do R. T.)
DEPARTAMENTO
FUNCIONÁRIO
HABILIDADE
Figura 8 Estrutura de dados "de rede".
TABELA DE DEPARTAMENTO TABELA DE FUNCIONÁRIO
NºD
1
5
8
ORÇAMENTO
10M
5M
20M
NOME
JOHNSON
GOODMAN
WALTERS
SALÁRIO
10K
15 K
16 K
ENDEREÇO
BOSTON
NYC
SAN JOSÉ
TABELA DE HABILIDADE
NºH
5
2
1
NOME-H
FORTRAN
COBOL
PM
TABELA DE
FUNCIONÁRIO-HABILIDADE
NOME
JOHNSON
JOHNSON
GOODMAN
GOODMAN
NºH
1
2
1
5
TABELA DE
DEPARTAMENTO-FUNCIONÁRIO
NºD
1
1
5
NOME
JOHNSON
GOODMAN
WALTERS
Figura 9 Estrutura de dados "relacional" ("tabela").
8 Modelagem de Dados
DEPARTAMENTO
FUNCIONÁRIO HABILIDADE
FUNCIONÁRIO-HABILIDADE
Figura 10 Projeto Lógico de Banco de Dados.
1.4 PROBLEMAS NO PROJETO LÓGICO DE BANCOS DE
DADOS
O projeto de bancos de dados é, hoje em dia, um processo compli-
cado, uma vez que o projetista tem de considerar não apenas como mode-
lar o mundo real, mas também as limitações do sistema de banco de dados
e a eficiência da recuperação e atualização dos dados. Por exemplo:
1. O projetista de banco de dados é restringido pelos tipos limi-
tados de estrutura de dados que são suportados pelo sistema
de gerência de banco de dados. Por exemplo, os relaciona-
mentos muitos-para-muitos entre dois tipos de entidades,
O método entidade-relacionamento para projeto lógico de bancos de dados 9
MUNDO REAL
PONTOS DE
INTERESSE
PARA A
EMPRESA
PROJETO LÓGICO
DE BANCO DE DADOS REDE
(COMO?)
RELACIONAL
HIERÁRQUICA
ESTRUTURA LÓGICA
DE DADOS
(ESQUEMA DO USUÁRIO)
tais como os relacionamentos entre funcionários e projetos,
não podem ser representados diretamente em muitos sis-
temas de banco de dados.
2. O projetista de banco de dados pode ter de considerar a via de
acesso dos registros (ou seja, como acessar um tipo particular
de registro). Por exemplo, a suposição implícita na Figura 3 é
que registros de FUNCIONÁRIO têm de ser acessados por
meio do registro de DEPARTAMENTO correspondente.
3. O projetista de banco de dados pode querer tornar a recu-
peração e a atualização mais eficientes. Assim, os dados sobre
uma entidade no mundo real podem ser colocados em mais de
um registro para propósitos de eficiência. Por exemplo, os
itens de dados sobre um funcionário podem ser agrupados em
dois registros: FUNCIONÁRIO-PRINCIPAL e FUNCIO-
NÁRIO-DETALHE.
Há dois problemas no método convencional de projeto de banco
de dados:
1. O projetista de banco de dados tem de considerar muitas
questões ao mesmo tempo, o que torna a tarefa de projeto de
banco de dados muito difícil.
2. O resultado final do projeto lógico de banco de dados é o
esquema do usuário (ou seja, uma descrição da visão do banco
de dados pelo usuário). Uma vez que o esquema do usuário
representa a solução do projetista para as questões compli-
cadas mencionadas acima, não é difícil perceber por que os
esquemas do usuário são geralmente difíceis de ser com-
preendidos e alterados.
1.5 UM NOVO MÉTODO PARA PROJETO DE BANCO DE
DADOS: O MÉTODO ENTIDADE-RELACIONAMENTO
Vamos descrever um novo método para projeto lógico de bancos
de dados chamado método Entidade-Relacionamento (E-R). A idéia-cha-
10 Modelagem de Dados
ve do método E-R é acrescentar um estágio intermediário ao projeto
lógico de bancos de dados. (Ver Figura 11.) O projetista de banco de dados
primeiro identifica as entidades e relacionamentos que são de interesse
para a empresa usando a técnica diagramática Entidade-Relacio-
namento (E-R). Nesse estágio, o projetista deve examinar os dados do
ponto de vista da empresa como um todo (não a visão de um progra-
mador de aplicação específico). Portanto, vamos chamar a descrição da
visão da empresa quanto aos dados de "esquema da empresa". O es-
quema da empresa deve ser uma representação "pura" do mundo real e
deve ser independente de considerações sobre armazenamento e efi-
ciência. O projetista de banco de dados primeiro projeta o esquema da
empresa e então o traduz a um esquema do usuário para seu sistema de
banco de dados. (Ver Figura 11.)
Figura 11 Esquema da empresa - uma etapa intermediária no projeto lógico de
bancos de dados.
O método entidade-relacionamento para projeto lógico de bancos de dados 11
MUNDO REAL ESQUEMA DA
EMPRESA
PONTOS DE
INTERESSE
PARA A
EMPRESA
HIERÁRQUICO
REDE
RELACIONAL
ESQUEMA DO USUÁRIO
1.6 VANTAGENS DO MÉTODO ENTIDADE-
RELACIONAMENTO
Os métodos convencionais de projeto lógico de bancos de dados
usualmente apresentam uma única fase: mapeamento de informações
sobre objetos do mundo real diretamente em um esquema do usuário. O
método E-R para projeto lógico de bancos de dados consiste em duas
fases principais: (1) Definição do esquema da empresa usando o dia-
grama de Entidade-Relacionamento; e (2) tradução do esquema da em-
presa em um esquema do usuário. As vantagens do método E-R são:
1. A divisão da funcionalidade e trabalho em duas fases torna o
processo de projeto de banco de dados mais simples e mais
bem organizado.
2. O esquema da empresa é mais fácil de ser projetado do que o
esquema do usuário, uma vez que não precisa ser restrito
pelas características do sistema de banco de dados e é inde-
pendente de considerações sobre armazenamento e eficiência.
3. O esquema da empresa é mais estável do que o esquema do
usuário. Se uma pessoa quiser mudar de um sistema de banco
de dados para outro, provavelmente terá de alterar o esque-
ma do usuário, mas não o esquema da empresa, uma vez que
este é independente dos sistemas de banco de dados usados.
O que precisa ser feito é um remapeamento do esquema da
empresa para um esquema do usuário compatível com o novo
sistema de banco de dados. De forma semelhante, se uma
pessoa quiser mudar o esquema do usuário para otimizar um
novo programa de aplicação, não é necessário alterar o esque-
ma da empresa, mas apenas remapeá-lo para um novo esque-
ma do usuário.
4. O esquema da empresa expresso pelo diagrama de entidade-
relacionamento é mais facilmente compreendido por pessoas
não ligadas ao processamento eletrônico de dados.
12 Modelagem de Dados
Paulo César
Destacar
Paulo César
Destacar
O método entidade-relacionamento para projeto lógico de bancos de dados 13
2. MÉTODO E-R E PROPOSTA
ANSI/X3/SPARC
2.1 PROPOSTA ANSI/X3/SPARC
O conceito do esquema de empresa é muito semelhante ao con-
ceito de esquema conceituai proposto pelo grupo ANSI/X3/SPARC. Nesta
seção, vamos discutir a arquitetura ANSI/X3/SPARC e como aplicar a ela
o método E-R.
No outono de 1971, o Comitê sobre Computador e Processamento
dé Informações (abreviado com Comitê X3) do American National
Standards Institute (ANSI) formou um grupo de estudos especial para
determinar quais (se há algum) aspectos dos sistemas de gerenciamento
de bancos de dados são candidatos adequados ao desenvolvimento de
padrões. O grupo de estudos especial, que é chamadoComitê de Planeja-
mento e Requisitos de Padrões (Standards Planning and Requirements
Committee — SPARC), consiste em representantes da comunidade de
usuários, fabricantes de hardware e universidades.
O grupo ANSI/X3/SPARC gastou tempo e esforços consideráveis
ponderando diferentes visões da teoria dos bancos de dados e desen-
volvendo um vocabulário que fosse consistente e bem compreendido por
todos. Como resultado, seu trabalho despertou muita atenção na comu-
nidade de banco de dados.
O grupo ANSI/X3/SPARC descobriu que não é desejável desen-
volver padrões que especifiquem como os componentes de um sistema de
gerenciamento de banco de dados devem funcionar, sendo mais recomen-
dável centrar-se em como os componentes se integram (ou seja, as
interfaces). Com isso em mente, o relatório delineia uma arquitetura de
três esquemas de um sistema de gerência de bancos de dados. (Ver
Figura 12.) Os sistemas de gerência de bancos de dados atuais usual-
mente possuem uma estrutura de dois níveis: a estrutura lógica (ou seja,
a estrutura de dados como é vista pelo programador) e a estrutura física
(ou seja, a estrutura de dados como é vista pelo computador).
A proposta ANSI/X3/SPARC apresenta uma estrutura de três
níveis: esquema externo, esquema conceituai e esquema interno. (Ver
Figura 12.) O esquema externo (esquema do usuário) representa a visão
do usuário (ou seja, do programador) quanto aos dados. Em outras
palavras, um esquema externo é uma descrição de dados visíveis para um
programa de aplicação em termos de nomes e características de dados. O
esquema interno representa a organização física de dados nos disposi-
tivos de armazenamento. Contém também os detalhes de integridade,
recuperação e maneiras eficientes de recuperar e atualizar dados. O
esquema conceituai representa a visão da empresa quanto aos dados. É
uma descrição de um modelo da empresa em termos de suas entidades,
atributos e relacionamentos entre si. Contém também os requerimentos
para operações permitidas, integridade semântica e privacidade. O es-
quema conceituai visa proporcionar uma visão estável dos dados.
Figura 12 Arquitetura ANSI/X3/SPARC.
14 Modelagem de Dados
MUNDO REAL
PONTOS DE
INTERESSE PARA
A EMPRESA
DISPOSITIVOS
DE ARMAZENAMENTO
ESQUEMA
INTERNO
ESQUEMA
CONCEITUAL
ESQUEMA ,
DO USUÁRIO
USUÁRIO
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
2.2 ESQUEMA CONCEITUAL E ESQUEMA DA EMPRESA
Qual é a diferença entre o esquema conceituai proposto pelo
grupo ANSI/X3/SPARC e o esquema da empresa discutido nesta obra? A
resposta é que são quase a mesma coisa, exceto que o esquema con-
ceituai é necessário para servir como interface entre o esquema externo
e o esquema interno. (Ver Figura 12.)
Uma razão para usar o esquema conceituai como a interface é
reduzir o número de mapeamentos entre os esquemas externos e os
esquemas internos. Por exemplo, se há M esquemas externos e N esque-
mas 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 esque-
mas internos, precisaremos de apenas M+N programas para fazer os
mapeamentos. (Ver Figura 14.) Portanto, o número de programas de
mapeamento é reduzido drasticamente.
N ESQUEMAS INTERNOS
Figura 13 Tradução entre esquemas externos e esquemas internos sem um esquema
conceituai.
O método entidade-relacionamento para projeto lógico de bancos de dados 15
M ESQUEMAS EXTERNOS
ESQUEMA
EXTERNO
Nº1
TRADUÇÕES
ESQUEMA
INTERNO
Nº1
ESQUEMA
INTERNO
Nº2
ESQUEMA
INTERNO
Nº N
ESQUEMA
EXTERNO
Nº M
ESQUEMA
EXTERNO
Nº 2
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Figura 14 Uso do esquema conceituai como interface entre esquemas internos e
externos.
Uma das metas da arquitetura ANSI/X3/SPARC é manter o
esquema conceituai relativamente estável, permitindo mudanças nos
esquemas externos e internos. Esta meta não parece difícil de ser atin-
gida, uma vez que o esquema conceituai representa a visão da empresa
quanto aos dados e deve ser relativamente estável em comparação à
visão do usuário quanto à visão física dos dados. Portanto, quando a
organização física do banco de dados é alterada ou os dados são transpor-
tados de dispositivos de armazenamento "antigos" para dispositivos de
armazenamento "novos", apenas alteramos o esquema interno, e não o
esquema conceituai ou os esquemas externos. Similarmente, se um
usuário quiser ver os dados como um certo tipo de organização, podemos
projetar um esquema externo para ele sem mudar o esquema conceituai
e os esquemas internos.
A não ser por servir como uma interface entre os esquemas
externos e internos, o esquema conceituai é a mesma coisa que o esque-
ma de empresa e podemos usar o diagrama de entidade-relacionamento
N ESQUEMAS INTERNOS
16 Modelagem de Dados
ESQUEMA
INTERNO
Nº 2
ESQUEMA
INTERNO
Nº N
ESQUEMA
INTERNO
Nº 1
ESQUEMA
EXTERNO
Nº 1
ESQUEMA
EXTERNO
Nº 2
ESQUEMA
CONCEITUAI.
ESQUEMA
EXTERNO
NºM
M ESQUEMAS EXTERNOS
O método entidade-relacionamento para projeto lógico de bancos de dados 17
para descrever o esquema conceituai. Além disso, uma vez que os esque-
mas externos podem ser expressos em termos de diferentes tipos de
estruturas de dados, tais como rede (CODASYL), hierárquica ou rela-
cionai (ver Figura 15), as regras de tradução entre diagramas E-R e
diferentes tipos de estruturas de dados discutidos adiante nesta obra
seriam muito úteis na implementação da arquitetura ANSI/X3/SPARC.
Figura 15 Os esquemas externos podem ser expressos em diferentes tipos de estru-
turas de dados.
2.3 TRÊS TIPOS DE ADMINISTRADORES DE BANCOS
DE DADOS
O grupo ANSI/X3/SPARC identificou três tipos de administra-
dores de bancos de dados:
ESQUEMA
INTERNO
ESQUEMA
CONCEITUAL
HIERÁRQUICA RELACIONALREDE
ESQUEMAS
EXTERNOS
Paulo César
Destacar
1. Administrador de empresa
O administrador de empresa define o esquema conceituai e, se
possível, o valida. Ele deve compreender muito bem as opera-
ções da empresa e o significado de suas informações (dados).
Ele é responsável pelo conteúdo, integridade e segurança do
banco de dados.
2. Administrador de banco de dados
O administrador de banco de dados define o esquema interno.
Ele projeta as estruturas físicas de dados, codificando esque-
mas, vias de acesso e colocação de dados em dispositivos de
armazenamento. Ele é responsável pela utilização eficiente
do espaço de armazenamento, assim como pelo desempenho
do sistema de banco de dados.
3. Administrador de aplicação
Um esquema externo representa uma visão dos dados pelo
programador de aplicação. Imagina-se que cada área geral de
aplicação terá seu próprio administrador de aplicação que
provê os esquemas externos para aquela área. Mas esses
esquemas externos têm de ser consistentes e deriváveis de
um único esquema conceituai. Observe que os mesmos esque-
mas externos podem ser usados por vários programadores de
aplicação, não necessariamente trabalhando no mesmo pro-
grama.
Estes três tipos de administradores representam três diferentes
papéis que podem ser desempenhados por um indivíduo ou um grupo de
pessoas. Embora as distinções entre esses três tipos de administradores
de banco de dados sejam claras em termos da arquitetura de três esque-
mas do ANSI/X3/SPARC, não são claras nos ambientes de bancos de
dados convencionais. Na verdade, o "administrador de banco de dados",
como é definido hoje em dia em muitas organizações, tem todas as
responsabilidades dos três tipos de administradores mencionados. Em
termos do âmbito desta monografia, preocupamo-nos primariamente
com a responsabilidade do administrador de empresa (ou seja, a tarefa
de modelaro mundo real) e a responsabilidade do administrador de
aplicação (ou seja, a tarefa de projetar os esquemas externos).
18 Modelagem de Dados
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
O método entidade-relacionamento para projeto lógico de bancos de dados 19
2.4 RELEVÂNCIA DO MÉTODO E-R
Em suma, se a arquitetura ANSI/X3/SPARC tornar-se realidade,
o método E-R pode ser usado das seguintes maneiras:
1. No projeto do esquema conceituai.
2. Na tradução do esquema conceituai em esquemas externos.
3. DIAGRAMA DE ENTIDADE-
RELACIONAMENTO (E-R)
Neste capítulo, vamos introduzir a técnica diagramática de
entidade-relacionamento. Discutiremos primeiro o que são entidades e
relacionamentos e, então, explicaremos como descrever propriedades de
entidades e relacionamentos.
3.1 ENTIDADES E RELACIONAMENTOS
3.1.1 Tipos de Entidade
Uma entidade é uma "coisa" que pode ser distintamente identifi-
cada. As entidades podem ser classificadas em diferentes tipos, tais como
FUNCIONÁRIO e ACIONISTA. (Ver Figura 16.) No diagrama E-R, um
tipo de entidade é representado por um retângulo. (Ver Figura 17.)
Figura 16 Entidades e tipos de entidades.
20 Modelagem de Dados
FUNCIONÁRIO ACIONISTA
Paulo César
Destacar
Figura 17 Tipos de entidades são representados por retângulos.
Há muitas "coisas" no inundo real. Algumas delas são de inte-
resse para a empresa, e o resto não. É responsabilidade do projetista de
banco de dados selecionar os tipos de entidade que são mais adequados
para sua empresa.
3.1.2 Tipos de Relacionamento
Relacionamentos podem existir entre entidades. Por exemplo,
CASAMENTO é um relacionamento entre duas entidades humanas.
(Ver Figura 18.) Os relacionamentos podem ser classificados em
diferentes tipos de relacionamentos. Por exemplo, PROJ-FÜNC e
PROJ-GERENTE são dois tipos de relacionamentos diferentes entre
dois tipos de entidades, PROJ (projeto) e FUNC (funcionário). Na nota-
ção diagramática de entidade-relacionamento, um tipo de relaciona-
mento é representado por um losango com linhas conectadas a tipos de
entidades relacionadas. (Ver Figura 19.) As notações "m" e "1" associadas
ao tipo de relacionamento PROJ-GERENTE na Figura 16 indicam que
cada projeto tem apenas um gerente, mas que um funcionário pode ser o
gerente de muitos projetos. O V e "n" associados com o tipo de relacio-
namento PROJ-FUNC indicam que é um mapeamento muitos-para-
muitos. Isto é, cada projeto pode consistir em vários funcionários e cada
funcionário pode estar associado a mais de um projeto. Observe que
outros tipos de mapeamento entre entidades também são possíveis. Por
exemplo, o tipo de relacionamento CASAMENTO é um mapeamento
um-para-um entre entidades humanas. (Ver Figura 20.)
É possível definir um tipo de relacionamento entre mais de dois
tipos de entidades. Por exemplo, PARTE-FORN-PROJ, que descreve que
partes são abastecidas por fornecedores específicos para projetos especí-
ficos (Figura 21), é um tipo de relacionamento definido em três tipos de
entidades: PARTE, FORN (fornecedor) e PROJ (Figura 22).
O método entidade-relacionamento para projeto lógico de bancos de dados 21
FUNCIONÁRIO ACIONISTA
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Figura 18 CASAMENTO como um relacionamento entre duas entidades humanas.
Figura 19 Tipos de relacionamentos são representados por losangos.
Figura 20 CASAMENTO como um tipo de relacionamento entre entidades hu-
manas.
PESSOA
CASAMENTO
22 Modelagem de Dados
PROJ
PROJ-
GERENTE
FUNC
PROJ-FUNC
CASAMENTO
Nº PARTE
25
25
10
10
17
17
Nº FORNECEDOR
4
5
4
4
2
5
Nº PROJ
1
2
2
3
1
1
Figura 21 Informações sobre relacionamentos PARTE-FORN-PROJ.
Figura 22 PARTE-FORN-PROJ como um tipo de relacionamento.
Note que um relacionamento ternário usualmente não pode ser
substituído por três relacionamentos binários. Por exemplo, o relaciona-
mento ternário PARTE-FORN-PROJ na Figura 21 é substituído por três
relacionamentos binários: PARTE-FORN, FORN-PROJ e PROJ-PARTE.
(Ver Figura 23.) Contudo, se quisermos construir o relacionamento ter-
nário partindo desses três relacionamentos binários, obteremos alguns
"não-fatos". (Ver as entradas com asteriscos na Figura 24.)
Há muitos tipos de relacionamentos entre entidades e alguns deles
são de interesse para a empresa: o projetista de banco de dados é responsá-
vel pela seleção dos tipos de relacionamentos relevantes para a empresa.
Ele deve também especificar os tipos de mapeamento dos tipos de relaciona-
mentos (ex.: um-para-um, um-para-muitos, muitos-para-muitos).
O método entidade-relacionamento para projeto lógico de bancos de dados 23
PARTE
PARTE
FORN-
PROJ
PROJ
FORN
Paulo César
Destacar
Figura 23 Informações sobre três relações binárias: PARTE-FORN, FORN-PROJ e
PROJ-PARTE.
Nº PARTE
25
25
25
25
10
10
17
17
Nº FORN
4
4
5
5
4
4
2
5
Nº PROJ
1
2
1
2
2
3
1
1
Figura 24 Informações geradas das três relações binárias da Figura 23.
3.2 DESCRIÇÃO DE ENTIDADES E RELACIONAMENTOS
3.2.1 Atributos e Valores
Entidades e relacionamentos têm propriedades que podem ser
expressas em termos de pares atributo-valor. Por exemplo, na afirmação
"a IDADE DO FUNCIONÁRIO x é 24", "IDADE" é um atributo do
funcionário x e "24" é o valor do atributo "IDADE". Os valores podem ser
*
*
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
NºPROJ
1
1
2
2
3
Nº PARTE
25
17
10
25
10
Paulo César
Destacar
O método entidade-relacionamento para projeto lógico de bancos de dados 25
classificados em diferentes tipos de valor, tais como Nº DE ANOS,
QUANTIDADE e COR. Na notação diagramática E-R, um tipo de valor
é representado por vim círculo (ver Figura 25) e um atributo é represen-
tado por um ponteiro dirigido do tipo de entidade para o tipo de valor
desejado.
Nº DO CIC IDADE
Figura 25 Tipos de valores e atributos.
N2 DO TELEFONE
Em alguns casos, um atributo pode ter mais de um valor para
uma determinada entidade. Por exemplo, "Nº DE TELEFONE" do fun-
cionário x pode ter dois valores: 253-6606 e 253-9999. Neste caso, colo-
camos "l:n" no ponteiro para indicar que é um atributo de valores
múltiplos. Isto é similar ao conceito de "grupo de repetição" em processa-
mento de dados convencional. Contudo, muitos atributos, tais como
"IDADE" e "Nº DO CIC", têm um só valor. Para simplicidade, não
associamos nada como "1:1" aos ponteiros no diagrama E-R para tais
atributos.
Até agora, consideramos apenas os atributos de entidades. Às
vezes, estamos também interessados nas propriedades de um relaciona-
mento. Por exemplo, podemos querer saber quando o funcionário x
começou a trabalhar em um determinado projeto. A DATA DE INÍCIO
não é um atributo do FUNCIONÁRIO nem do PROJ, uma vez que seu
valor depende tanto do funcionário específico quanto do projeto envol-
Nº DO CIC IDADE Nº DO TELEFONE
FUNCIONÁRIO
20
18
26
55
253-6606
253-9999
478-6574
234-55-7684
013-64-7777
315-88-4158
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
vido. Portanto, a DATA DE INÍCIO é um atributo do relacionamento
PROJ-FUNC. Um outro exemplo de atributo do relacionamento é a
PORCENTAGEM DE ESFORÇO, que é a porcentagem de tempo que um
funcionário devota a um determinado projeto. (Ver Figura 26.) O con-
ceito de atributo de relacionamento é importante para compreender a
semântica dos dados. O conceito é semelhante ao de dados derelaciona-
mento em sistemas de bancos de dados do tipo "rede" (CADASYL) e ao de
dados de intersecção em sistemas de bancos de dados do tipo hierárquico
(tipo IMS).
DATA DE INÍCIO PORCENTAGEM DE ESFORÇO
Figura 26 Atributos de relacionamento.
3.2.2 Identificador de Entidade
As entidades discutidas até agora são aquelas que existem em
nossas mentes ou podem ser identificadas com um apontar de dedo.
Quando alguém pergunta, "De que cor é isto?", "isto" ou é compreendido
tanto por quem está falando quanto pelo ouvinte, ou é identificado
apontando-se para o objeto. Este esquema de identificação pode fun-
cionar para muito poucos objetos, porém encontraremos dificuldades
quando quisermos comunicar a informação sobre uma variedade de
objetos para muitas pessoas diferentes. Portanto, tanto na conversa do
dia-a-dia como em processamento de dados computadorizado, precisa-
PROJ PROJ-FUNC FUNC
DATA PORCENTAGEM
DE INÍCIO DE ESFORÇO
20%
30%
90%
9/15/75
7/22/76
26 Modelagem de Dados
Paulo César
Destacar
Paulo César
Destacar
O método entidade-relacionamento para projeto lógico de bancos de dados 27
mos de um outro esquema para identificar entidades. Cada entidade tem
muitos atributos, mas qual deles deve ser escolhido? A resposta é que os
atributos escolhidos devem ser capazes de identificar de forma absoluta
as entidades. Por exemplo, podemos usar o atributo NOME para identi-
ficar funcionários em uma pequena companhia, mas não em uma grande
firma. Esses atributos escolhidos da entidade são chamados de identifi-
cadores de entidade. Em alguns casos, pode ser difícil ou inconveniente usar
os atributos disponíveis como identificadores da entidade. O que podemos
fazer é criar um atributo artificial que possa identificar incontestavelmente
as entidades. Exemplos são Nº DO CIC, Nº DO FUNC, Nº DA PARTE e Nº
DO PROJ. O conceito de identificador de entidade é similar ao conceito de
chave primária em processamento de dados convencional.
3.2.3 Identificador de Relacionamento
Os relacionamentos são identificados pelo uso de identificadores
das entidades envolvidas no relacionamento. Por exemplo, se um projeto
é identificado por seu Nº DO PROJ e um funcionário é identificado por Nº
DO FUNC, então o relacionamento PROJ-FUNC é identificado por am-
bos os Nº DO PROJ e nº DO FUNC. Em algumas situações, um tipo de
relacionamento é definido entre duas ocorrências do mesmo tipo de
entidade. Por exemplo, CASAMENTO é um tipo de relacionamento
definido entre ocorrências do mesmo tipo de entidade, PESSOAS. Para
identificar inequivocamente tais relacionamentos, usamos não apenas o
identificador de entidade, mas também indicamos qual o papel que a
entidade desempenha no relacionamento. No caso de CASAMENTO,
devemos ligar os nomes MARIDO e MULHER ao identificador de enti-
dade NOME, onde MARIDO e MULHER são os "papéis" que eles desem-
penham na relação CASAMENTO.
3.3 TIPOS ESPECIAIS DE ENTIDADE E
RELACIONAMENTO
Nesta seção, vamos discutir alguns tipos especiais de entidade e
relacionamento que são comumente encontrados.
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
3.3.1 Existência-Dependente
A existência de uma entidade pode depender da existência de um
outro tipo de entidade. Por exemplo, a existência de entidades FILHOS
no banco de dados depende da existência dos funcionários associados.
Em outras palavras, se um funcionário deixa a companhia, não precisa-
mos manter o registro de seus filhos. A Figura 27 ilustra o diagrama E-R
para essa situação. FILHOS é representado por um retângulo duplo, o
que significa que é um tipo de entidade "fraca". A existência de uma
entidade fraca depende da existência de outras entidades. O "E" dentro
do losango do relacionamento indica que é um relacionamento existên-
cia-dependente; o ponteiro associado ao losango do relacionamento indi-
ca a direção da dependência.
E possível que o relacionamento existência-dependente seja um
mapeamento muitos-para-muitos. Por exemplo, se o pai deixa a compa-
nhia, as entidades FILHOS podem ainda existir se a mãe continuar
sendo uma funcionária da companhia. Esta situação é representada no
diagrama E-R mostrado na Figura 28.
Figura 27 Um relacionamento de tipo existência-dependente e um tipo de entidade
fraca.
28 Modelagem de Dados
FUNC
E
FILHOS
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Figura 28 Uma relação existência-dependente pode ser também um mapeamento
muitos-para-muitos.
3.3.2 Dependência de Identificador (ID)
Se uma entidade não puder ser identificada inequivocamente por
seus próprios atributos e tiver de ser identificada por seus relaciona-
mentos com outras entidades, ela tem dependência de identificador com
as outras entidades. Por exemplo, "rua" só é específica dentro de uma
cidade, uma cidade só é específica dentro de um Estado, e um Estado só
é específico dentro de um país. Para identificar precisamente o endereço
de uma localização, temos de especificar os nomes da cidade, Estado e
país, além do nome da rua. Á dependência de identificador é indicada
pelo "ID" no losango de relacionamento, e a direção do relacionamento é
indicada pelo ponteiro (Ver Figura 29); a maioria das dependências ID
está associada a existências-dependentes. Contudo, a existência-
dependente não implica a dependência ID. Por exemplo, as entidades
FILHOS na Figura 30 são identificadas com seus próprios atributos e o
ID de seus pais (ver Figura 31), enquanto as entidades FILHOS na
Figura 27 podem ser identificadas por seus próprios Nº DO FILHO. (Ver
Figura 32.)
O método entidade-relacionamento para projeto lógico de bancos de dados 29
FUNC
M (PELO MENOS 1)
E
FILHOS
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Paulo César
Destacar
Figura 29 Existência-dependente e Dependência ID.
30 Modelagem de Dados
RUA
E&
ID
CIDADE
ESTADO
E&
ID
PAÍS
E&
FUNC
FILHOS
Figura 30 Existência-dependente e Dependência ID.
Figura 31 Dependência ID.
Figura 32 Sem Dependência ID.
NOME
NANCY BOK
LAWRENCE BOK
ROBERT JOHNSON
ID DOS FILHOS
ID DO FUNC
CIC DO PAI OU MÃE
013-58-5545
172-66-6672
819-38-7776
D
IDADE
12
5
21
ADOS SOBRE FILHOS
SEGURO-SAÚDE
BC/BS
BC/BS
TEM PLANO PRÓPRIO
ID DOS
FILHOS
Nº DOS FILHOS
1011
1025
1044
NOME
NANCY BOK
LAWRENCE BOK
ROBERT JOHNSON
IDADE
12
5
21
SEGURO-SAÚDE
BC/BS
BC/BS
TEM PLANO PRÓPRIO
O método entidade-relacionamento para projeto lógico de bancos de dados 31
4. TRADUÇÃO DE DIAGRAMAS E-R EM
DIAGRAMAS DE ESTRUTURA DE DADOS
4.1 DIAGRAMAS DE ESTRUTURA DE DADOS
As estruturas lógicas de dados de bancos de dados suportadas
pelo sistema tipo CODASYL (rede) de banco de dados podem ser expres-
sas em termos de diagrama de estrutura de dados. Cada retângulo
representa um tipo de registro, tal como FUNC e DEPENDENTE. O
ponteiro representa um conjunto de estrutura de dados que conecta dois
tipos de registro. O tipo de registro no qual o ponteiro se origina é o tipo
proprietário de registro do conjunto de estrutura de dados, e o tipo de
registro no qual o ponteiro termina é o tipo membro de registro do
conjunto de estrutura de dados. Na Figura 33, FUNC é o tipo proprietá-
rio de registro e DEPENDENTE é o tipo membro de registro. Em um
conjunto de estrutura de dados, o registro proprietário pode ter zero, um
ou mais registros membros (ocorrências). Um registro membro em um
conjunto de estrutura de dados tem exatamente um registro proprietá-
rio. Em nosso exemplo, cada registro de funcionário pode estar conectado
a muitos registros de DEPENDENTE ou a nenhum.Contudo, cada
registro de DEPENDENTE deve estar associado a exatamente um regis-
tro FUNC. Isto é ilustrado na Figura 34. Conceitualmente, o ponteiro
representa uma associação l:n (um-para-muitos) entre o tipo proprietá-
rio de registro e o tipo membro de registro. Este tipo de associação pode
também ser representado em forma de tabela. (Ver Figura 35.)
Figura 33 Um diagrama de estrutura de dados.
32 Modelagem de Dados
FUNC
DEPENDENTE TIPO "MEMBRO" DE REGISTRO
CONJUNTO DE ESTRUTURA DE DADOS
TIPO "PROPRIETÁRIO" DE REGISTRO
(A) ZERO DEPENDENTE (B) TRÊS DEPENDENTES (C) UM DEPENDENTE
Figura 34 Um registro PROPRIETÁRIO pode ter zero, um ou mais registros "mem-
bros*.
Nº DO FUNC
1781
1781
1781
2566
DEPENDENTE
A
B
C
D
Figura 35 Correspondência um-para-muitos entre FUNCIONÁRIO e DEPEN-
DENTES.
A Figura 36 ilustra uma estrutura de dados mais complicada. O
tipo de registro FUNCIONÁRIO é o registro proprietário de um conjunto
de estrutura de dados no qual FUNCIONÁRIO-HABILIDADE é o regis-
tro membro. O tipo de registro FUNCIONÁRIO-HABILIDADE é tam-
bém o registro membro de um outro conjunto de estrutura de dados no
qual o tipo de registro HABILIDADE é o registro proprietário. Na ver-
dade, o registro FUNCIONÁRIO-HABILIDADE contém a informação
sobre FUNCIONÁRIOS e HABILIDADES. Esse tipo de informação pode
ser representado na forma de tabela, como é mostrado na Figura 37.
Podemos ver na Figura 37 que um funcionário pode ter uma ou
mais habilidades e que usualmente mais de um funcionário tem uma
habilidade específica. Portanto, a relação entre funcionários e habi-
lidades é m:n (muitos-para-muitos). Essa correspondência m:n entre
funcionários e habilidades pode ser derivada da Figura 36. Os conjuntos
O método entidade-relacionamento para projeto lógico de bancos de dados 33
FUNC 2142
Nº DO FUNC
DEP A DEP B
FUNC 1781
DEP C DEP D
FUNC 2566
de estrutura de dados na Figura 36 mostram que existe um mapeamento
l:m (um-para-muitos) entre o tipo de registro FUNCIONÁRIO e o tipo
de registro FUNCIONÁRIO-HABILIDADE, e que um mapeamento se-
melhante (l:n) existe entre o tipo de registro HABILIDADE e o tipo de
registro FUNC-HABILIDADE. Portanto, a correspondência entre o re-
gistro FUNC e o tipo de registro habilidade é m:n (muitos-para-muitos).
Figura 36 Dois conjuntos de estrutura de dados têm o mesmo tipo "membro" de
registro.
Nº DO FUNC
2142
2141
1781
2566
HABILIDADE
COBOL
PL/1
COBOL
PL/1
Figura 37 Informações cruzadas sobre FUNCIONÁRIOS e HABILIDADES.
O diagrama de estrutura de dados na Figura 36 pode ser imple-
mentado usando-se um conjunto de ponteiros, como é mostrado na Fi-
gura 38. O conjunto de estrutura de dados entre o tipo de registro FUNC
e o tipo de registro HABILIDADE é representado pelas linhas contínuas,
e o conjunto de estrutura de dados entre o tipo de registro HABILIDADE
e o tipo de registro FUNC-HABILIDADE é representado por linhas
pontilhadas.
34 Modelagem de Dados
FUNC HABILIDADE
FUNC-HABILIDADE
Rafael Gama de Macedo Jr.
Na Figura 38, como determinamos as habilidades de um funcio-
nário específico? O primeiro passo é localizar o registro de FUNC com o
Nº DO FUNC = 2142, usando um algoritmo hashing ou algum outro
método. O segundo passo é encontrar o primeiro registro FUNC-HABI-
LIDADE relacionado com esse funcionário. Por meio do ponteiro mostra-
do pela linha pontilhada, podemos encontrar um registro de habilidade
com HABILIDADE-NOME = COBOL. Encontramos, então, o segundo
registro FUNCIONÁRIO-HABILIDADE relacionado com o mesmo re-
gistro de funcionário (por meio dos ponteiros de linha contínua). Do
registro FUNC-HABILIDADE, podemos seguir por intermédio do pon-
teiro de linha pontilhada para localizar um registro HABILIDADE com
HABILIDADE-NOME = PL/1. Não conseguimos, então, encontrar mais
nenhum registro FUNC-HABILIDADE relacionado com os mesmos re-
gistros de FUNCIONÁRIO (ou seja, encontramos a informação de que
necessitávamos: o funcionário com Nº DO FUNC = 2142 tem duas
habilidades: COBOL e PL/1).
Figura 38 Implementação dos conjuntos de estrutura de dados da Figura 37 como
conjuntos de ponteiros.
Como encontramos todos os funcionários com uma habilidade
específica, digamos, COBOL? Primeiro, localizamos o registro HABILI-
DADE com HABILIDADE-NOME = COBOL. Então, recuperamos todos
os registros FUNC-HABILIDADE relacionados com o registro
HABILIDADE. Para cada registro FUNCIONÁRIO-HABILIDADE,
recuperamos, por meio do ponteiro de linha contínua, o registro FUNC
correspondente. Fazendo isso, sabemos que há dois funcionários com a
habilidade COBOL, e seus números são 2142 e 1781.
o método entidade-relacionamento para projeto lógico de bancos de dados 35
FUNC 2142
FUNC-
HABILIDADE
FUNC-
HABILIDADE
FUNC 1781 FUNC 2586
FUNC-
HABILIDADE
HABILIDADE
PL/1
FUNC-
HABILIDADE
HABILIDADE
COBOL
Uma outra maneira de implementar o diagrama de estrutura de
dados da Figura 22 é usar cadeias, como é mostrado na Figura 39. As
linhas contínuas conectam todos os registros FUNC-HABILIDADE rela-
cionados com o mesmo registro HABILIDADE. Vamos ver como en-
contrar as habilidades do funcionário com Nº DO FUNC = 2142. Em
primeiro lugar, encontramos o primeiro registro FUNC-HABILIDADE
por intermédio da cadeia de linha contínua. Do registro FUNC-
HABILIDADE, encontramos o registro de habilidade por meio da cadeia
de linha pontilhada. Do registro FUNC-HABILIDADE procuramos o
registro FUNC-HABILIDADE seguinte pela cadeia de linha sólida. Do
segundo registro FUNC-HABILIDADE, podemos determinar o registro
de habilidade correspondente por meio da cadeia de linha pontilhada. Do
segundo registro FUNC-HABILIDADE, não conseguimos encontrar
mais nenhum registro FUNC-HABILIDADE na cadeia de linha contí-
nua. Agora, sabemos todas as habilidades que o funcionário 2142 tem.
Similarmente, podemos encontrar todos os funcionários com uma deter-
minada habilidade seguindo através das cadeias.
Figura 39 Implementação dos conjuntos de estrutura de dados da Figura 27 como
cadeias.
Um outro tipo de estrutura de dados, que pode usualmente ser
encontrado em bancos de dados de processos de produção, é mostrado na
Figura 40. Há dois tipos de registro: PARTE e PRD-REL (produção-rela-
cionamento). Cada produto a ser fabricado consiste em muitas "partes"
(componentes). Cada parte, por sua vez, é feita de outras partes. O tipo
36 Modelagem de Dados
FUNC 2142 FUNC 1781 FUNC 2566
FUNC-
HABILIDADE
PL/1COBOL
FUNC-
HABILIDADE
FUNC-
HABILIDADE
FUNC-
HABILIDADE
O método entidade-relacionamento para projeto lógico de bancos de dados 37
de registro PARTE contém informações sobre a parte específica. 0 tipo
de registro PRD-REL contém as informações sobre o relacionamento
entre as partes. A Figura 41 ilustra esse tipo de relacionamento. Indica
que, para produzir a PARTE Nº1, precisamos de cinco PARTES Nº 2e
duas PARTES Nº 3. Podemos ver também que a PARTE Nº 3 é uma
subparte tanto da PARTE Nº1 quanto da PARTE Nº 4. Há dois conjuntos
de estrutura de dados na Figura 40 e eles podem ser implementados
como "cadeias", como mostrado na Figura 42. As linhas contínuas repre-
sentam a cadeia COMPONENTE e as linhas pontilhadas representam a
cadeia ONDE USADA. Para encontrar os componentes de uma parte
específica, primeiro recuperamos todos os registros PRD-REL por meio
da cadeia COMPONENTE e, então, recuperamos as subpartes corres-
pondentes pela cadeia ONDE USADA. Fazendo isso, evidenciamos que a
PARTE Nº 4 consiste em uma PARTE Nº 3 e em duas PARTES Nº 5. Para
descobrir onde uma parte específica é usada para produzir outras partes,
primeiro recuperamos todos os registros PRD-REL relacionados com
esse registro PARTE específico por intermédio da cadeia ONDE USADA,
e então recuperamos os registros PARTE correspondentes por meio da
cadeia COMPONENTE. Fazendo isso, descobrimosque duas PARTES
Nº 5 são usadas na fabricação da PARTE Nº 4.
As Figuras 33, 36 e 40 são os tipos básicos de diagramas de
estrutura de dados. Um banco de dados pode ser expresso em um grande
diagrama de estrutura de dados baseado nesses três modelos básicos.
Figura 40 Dois conjuntos de estrutura de dados têm os mesmos tipos de registro
"proprietário" e "membro".
COMPONENTES ONDE USADA
PARTE
PRD-REL
SUPERPARTE Nº
1
1
4
4
SUBPARTE Nº
2
3
3
5
QUANTIDADE
5
2
1
2
Figura 41 Relação de fabricação entre partes.
Figura 42 Implementação dos conjuntos de estrutura de dados da Figura 41.
4.2 REGRAS DE TRADUÇÃO
Como vimos na seção anterior, o diagrama de estrutura de dados
está mais próximo da organização física do banco de dados que o dia-
grama de entidade-relacionamento. Usualmente, é difícil desenhar um
diagrama de estrutura de dados para as entidades e relacionamentos
que são de interesse para a empresa. Portanto, propomos que o proje-
tista de banco de dados primeiro desenhe um diagrama E-R para repre-
sentar a visão da empresa quanto aos dados e, então, traduza-o para um
diagrama de estrutura de dados. Nesta seção, vamos discutir como
traduzir um diagrama E-R para um diagrama de estrutura de dados.
Identificamos algumas regras básicas para tradução com base no tipo de
38 Modelagem de Dados
PARTE Nº 1
CADEIA
COMPONENTE
PARTE Nº 4
PRD-REL 2
PARTE Nº 5
CADEIA ONDE
USADA
PRD-REL
CADEIA ONDE
USADA
PARTE Nº 3PARTE Nº 2
CADEIA ONDE
usada
PRD-REL PRD-REL
CADEIA
COMPONENTE
O método entidade-relacionamento para projeto lógico de bancos de dados 39
relacionamentos entre entidades. Começamos com relacionamentos defi-
nidos por dois tipos de entidades, depois relacionamentos definidos por
mais de dois tipos de entidades e, por fim, relacionamentos do mesmo
tipo de entidade. As regras de tradução são as seguintes:
1. Relacionamentos definidos por dois tipos diferentes de enti-
dades:
a) O relacionamento é uma correspondência um-para-muitos
(ou um-para-um). Por exemplo, o tipo de relacionamento
DEPT-FUNC na Figura 43 (a) é uma correspondência um-
para-muitos e pode ser transformada no diagrama de estru-
tura de dados da Figura 43 (b). Note que os tipos de entidades
tais como DEPT e FUNC no diagrama E-R são tratados como
tipos de registro no diagrama de estrutura de dados, en-
quanto 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 res-
tringe um gerente por projeto mas permite vários projetos
com o mesmo gerente, é representado por um ponteiro no
diagrama de estrutura de dados mostrado na Figura 44 (b).
DIAGRAMA E-R DIAGRAMA DE
ESTRUTURA DE DADOS
Figura 43
DEPT
FUNC FUNC
DEPT
DEPT
fUNC
Figura 44
b) O relacionamento é uma correspondência muitos-para-
muitos. Por exemplo, o tipo de relacionamento PROJ-FUNC
na Figura 45 (a) é uma correspondência muitos-para-muitos.
O diagrama de estrutura de dados correspondente é mostrado
na Figura 45 (b). Note que o tipo de relação PROJ-FUNC não
é traduzido em um ponteiro, mas em um tipo de registro.
Podemos concluir que, se um tipo de relacionamento é uma
correspondência muitos-para-muitos, ele será traduzido em
um tipo de registro com dois ponteiros apontando para ele,
vindos dos tipos de registro de entidade relacionados. O tipo
de registro PROJ-FUNC é usualmente chamado um tipo de
registro de relacionamento. Um exemplo semelhante é mos-
trado na Figura 46. Uma vez que o tipo de relacionamento
FUNC-HABILIDADE é uma correspondência muitos-para-
muitos, é traduzido em um tipo de registro (de relaciona-
mento) no diagrama de estrutura de dados.
40 Modelagem de Dados
FUNC
PROJ-
GERENTE
PROJ
DIAGRAMA E-R DIAGRAMA DE
ESTRUTURA DE DADOS
PROJ
FUNC
(a)
DIAGRAMA E-R
Figura 45
(b)
DIAGRAMA DE
ESTRUTURA DE DADOS
DIAGRAMA E-R
Figura 46
DIAGRAMA DE
ESTRUTURA DE DADOS
2. Relacionamentos definidos por mais que dois tipos de entida-
des:
Neste caso, o tipo de relacionamento no diagrama E-R será
traduzido em um tipo de registro de relacionamento no diagrama de
estrutura de dados, seja o relacionamento uma correspondência um-pa-
ra-muitos ou de outro tipo. Por exemplo, o tipo de relacionamento PAR-
TE-PROJ-FORN na Figura 47 (a) é um tipo de relacionamento definido
o método entidade-relacionamento para projeto lógico de bancos de dados 41
PROJ
FUNC
PROJ-FUNC
FUNCPROJ
FUNC
HABILIDADE*
FUNC
HABILIDADE
FUNC-
HABILIDADE
HABILI-
DADEFUNC
PROJ
FUNC
por três tipos de entidades e será traduzido em um tipo de registro no
diagrama de estrutura de dados, como é mostrado na Figura 47 (b).
DIAGRAMA DE ESTRUTURA DE DADOS
Figura 47
3. Relacionamentos binários definidos pelo mesmo tipo de enti-
dade:
Se o relacionamento binário for uma correspondência um-para-
muitos, tal como o tipo de relacionamento GERENCIADO na Figura 48
(a), ele poderá ser transformado em pelo menos dois possíveis diagramas
de estrutura de dados, como é mostrado nas Figuras 48 (b) e (c). Uma vez
que a maioria dos sistemas de bancos de dados do tipo CADOSYL (rede)
PARTE PROJ
PARTE-PROJ-FORN
FORN
42 Modelagem de Dados
PARTE PROJ
FORN
DIAGRAMA E-R
PARTE-
PROJ
FORN'
O método entidade-relacionamento para projeto lógico de bancos de dados 43
não permite que o mesmo tipo de registro seja usado tanto como tipo de
registro proprietário quanto como tipo de registro membro de um conjun-
to de estrutura de dados, a Figura 48 (b) não é válida. Portanto, usare-
mos a Figura 48 (c) como o diagrama de estrutura de dados relativo ao
diagrama E-R na Figura 48 (a). Para relacionamentos binários com
outros tipos de correspondência, usaremos o mesmo tipo de diagrama de
estrutura de dados. Por exemplo, PRD-REL é um relacionamento de tipo
de correspondência muitos-para-muitos e seu diagrama de estrutura de
dados equivalente é mostrado na Figura 49 (b).
Figura 49
DIAGRAMA E-R
Figura 48
PARTE
PRD-REL PRD-REL
PARTE
DIAGRAMA DE
ESTRUTURA DE DADOS
GERENCIADO<GERENCIADO
PESSOA PESSOAPESSOA
5. ETAPAS NO PROJETO LÓGICO DE
BANCO DE DADOS E EXEMPLOS
Nesta seção, vamos primeiro apresentar as principais etapas no
projeto lógico de bancos de dados e, então, dar três exemplos de projetos
de bancos de dados usando o método E-R.
5.1 PRINCIPAIS ETAPAS NO PROJETO LÓGICO DE
BANCOS DE DADOS
O método de entidade-relacionamento para projeto de bancos de
dados consiste nas seguintes etapas:
1. Identificar tipos de entidades.
2. Identificar tipos de relacionamentos.
3. Desenhar um diagrama E-R com tipos de entidade e relacio-
namentos.
4. Identificar tipos de valor e atributos.
5. Traduzir o diagrama E-R em um diagrama de estrutura de
dados.
6. Projetar formatos de registros.
5.2 EXEMPLO 1: UMA INDÚSTRIA
5.2.1 Identificar Tipos de Entidades
A primeira etapa é identificar os tipos de entidade que inte-
ressam à companhia. Em uma indústria, os tipos de entidade primários
são PARTE, FORN (fornecedor), PROJ, FUNC e DEPT. Há outros tipos
44 Modelagem de Dados
de entidades que podem ser de interesse em uma indústria, mas, por
motivo de simplicidade, vamos nos concentrar nestes importantes tipos
de entidade.
5.2.2 Identificar Tipos de Relacionamento
Podemos identificar pelo menos os seguintes tipos de relaciona-
mento (Ver Figura 50):
Figura 50 Um diagrama E-R para uma indústria.
a) O tipo de relacionamento DEPT-FUNC descreve a associação
do departamento com os funcionários e é um mapeamento
um-para-muitos.
6) O tipo de relacionamento PROJ-FUNC descreve a associação
dos projetos com os funcionários e é um mapeamento muitos-
para-muitos. Isto é, cada funcionário podetrabalhar em mais
de um projeto, e cada projeto pode envolver mais de um
funcionário.
c) O tipo de relacionamento PROJ-GERENTE identifica os ge-
rentes dos projetos e é um mapeamento um-para-muitos. Isto
O método entidade-relacionamento para projeto lógico de bancos de dados 45
DEPT
PRD-REL
NM
FORN
POTENCIAL
FORN
PROP
FORN
P A R T E
PARTE INVENTÁRIOPROJ
PROJ-
GERENTE
PROJ-
FUNC
FUNC
DEPT
FUNC
DEPÓSITO
é, cada projeto tem apenas um gerente, mas cada funcionário
pode estar associado a mais de um projeto.
d) O tipo de relacionamento PROJ-FORN-PARTE descreve qual
fornecedor fornece qual parte para um determinado projeto e
é um mapeamento ternário muitos-para-muitos-para-muitos.
Isto é, para uma parte específica, pode haver mais de um
fornecedor, que pode fornecer essa parte para mais de um
projeto. Similarmente, cada projeto pode usar mais de uma
parte, que pode ter mais de um fornecedor. Também, cada
fornecedor pode prover um projeto com mais de uma parte.
Uma razão para a companhia querer procurar fornecedores
diferentes para a mesma parte usada para diferentes projetos
é que, em um determinado projeto, a companhia talvez neces-
site da parte imediatamente e, portanto, pode estar disposta
a pagar mais por ela a um fornecedor local. Em geral, esse
tipo de relação ternária não pode ser substituído por três
relações binárias como PROJ-FORN, FORN-PARTE e
PARTE-PROJ.
e) O tipo de relação FORN POTENCIAL mantém uma lista de
fornecedores potenciais de uma determinada parte e é um
mapeamento muitos-para-muitos. Isto é, cada parte pode ter
mais de um fornecedor potencial, e cada fornecedor pode ser
capaz de fornecer mais de uma parte.
f) O tipo de relação INVENTARIO mantém um registro de que
parte está estocada em qual depósito e é um mapeamento
muitos-para-muitos.
5.2.3 Desenhar um Diagrama E-R com Tipos de Entidade
e Relacionamento
A terceira etapa é desenhar um diagrama E-R com os seis tipos
de entidade e as sete tipos de relacionamento mencionados. Certamente,
podemos identificar outros tipos de entidade e relacionamentos além dos
descritos acima. Contudo, uma vez que nosso propósito é introduzir
46 Modelagem de Dados
O método entidade-relacionamento para projeto lógico de bancos de dados 47
conceitos-chaves do método entidade-relacionamento, não entraremos
em maiores detalhes. o leitor desta monografia pode acrescentar mais
tipos de entidades e relações à Figura 50, de acordo com suas próprias
necessidades.
5.2.4 Identificar Tipos de Valores e Atributos
A quarta etapa é identificar as propriedades de entidades e
relacionamentos que sejam de interesse para a empresa. Isto é, quere-
mos identificar atributos e tipos de valor para as entidades e relaciona-
mentos da Figura 50.
Vamos começar com os tipos de entidade DEPT e FUNC e sua
relação DEPT-FUNC. A Figura 51 ilustra os atributos e tipos de valor
para DEPT e FUNC. Os tipos de entidade e de relacionamento estão no
domínio conceituai superior e os atributos e tipos de valor estão no
domínio conceituai inferior. Na Figura 51, identificamos os seguintes
tipos de valor: Nº DO DEPT, ORÇAMENTO, Nº DO FUNC, DATA,
SALÁRIO e Nº DO TELEFONE. O DEPT tem três atributos: Nº DO
DEPT, ORÇAMENTO DESTE ANO e ORÇAMENTO DO ANO
PASSADO. FUNC tem cinco atributos: Nº DO FUNC, DATA DE
NASCIMENTO, SALÁRIO, TELEFONE RESIDENCIAL e TELEFONE
COMERCIAL. Note que os atributos podem não ter os mesmos nomes
que os tipos de valor, e que é possível ter mais de um atributo relacio-
nado com o mesmo tipo de valor. Por exemplo, ORÇAMENTO DESTE
ANO e ORÇAMENTO DO ANO PASSADO de DEPT usam o mesmo tipo
de valor ORÇAMENTO. Um outro exemplo são os atributos TELEFONE
COMERCIAL e TELEFONE RESIDENCIAL de FUNC que usam o
mesmo tipo de valor Nº DO TELEFONE. Para simplificar o diagrama,
vamos omitir os nomes de atributos no diagrama se esses forem os
mesmos que os nomes dos tipos de valor. Assim, a Figura 52 é uma
versão simplificada da Figura 51.
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: % ESFORÇO, DATA, Nº DO PROJ, ORÇAMEN-
TO e PROJ-NOME. Há também cinco atributos na Figura 53 (embora
alguns nomes de atributos estejam omitidos no diagrama): % ESFOR-
ÇO, DATA DE INÍCIO DO PROJ, Nº DO PROJ, ORÇAMENTO e PROJ-
NOME. Note que a relação PROJ-FUNC tem dois atributos: DATA DE
INÍCIO DO PROJ e % ESFORÇO. A DATA DE INÍCIO DO PROJ é a
data na qual o funcionário começou a trabalhar em um determinado
projeto, e a % ESFORÇO é a porcentagem de tempo que um funcionário
deve gastar em um determinado projeto. Note que o tipo de valor ORÇA-
MENTO é o mesmo que o tipo de valor ORÇAMENTO na Figura 52.
Portanto, podemos dizer que os atributos podem nos ajudar a interpretar
o significado de valores.
A Figura 54 ilustra os tipos de valor e atributos para os tipos de
entidade FORN e PARTE e os tipos de relação PROJ-FORN-PARTE e
FORN POTENCIAL. A entidade FORN tem dois atributos: Nº DO FORN
e ENDEREÇO. A entidade PARTE tem os atributos Nº DA PARTE,
PESO e COR. A relação PROJ-FORN-PARTE tem o atributo QTD, que é
a quantidade de uma determinada parte fornecida por um determinado
fornecedor para um determinado projeto. A relação FORN POTENCIAL
não tem atributo. Os atributos da entidade PROJ já foram mostrados na
Figura 53.
48 Modelagem de Dados
DOMÍNIO
CONCEITUAL.
SUPERIOR
DOMÍNIO
CONCEITUAL
INFERIOR
DEPT
Nº DO DEPT ORÇAMENTO DO
ANO PASSADO
ORÇAMENTO
DESSE ANO
DATA DE
INÍCIO DO DEPT
DEPT-FUNC, FUNC
Nº DO DEPT ORÇAMENTO DATA Nº DO FUNC SALÁRIO Nº DOTELEFONE
TELEFONE
RESIDENCIALSALÁRIO
DATA DE
NASCIMENTO
Nº DO FUNC TELEFONE
COMERCIAL
Figura 52 Uma versão simplificada da Figura 51.
Figura 53 Atributos e tipos de valor para PROJ e PROJ-FUNC.
A Figura 55 mostra os atributos e tipos de valor das propriedades
da entidade DEPÓSITO e das relações INVENTÁRIO e PRD-REL. Uma
entidade DEPÓSITO tem os atributos Nº DO DEPÓSITO e ENDE-
REÇO. Um relacionamento INVENTÁRIO tem os atributos QTD-À-
MÃO, que é a quantidade de uma parte estocada em um depósito. O
relacionamento PRD-REL tem o atributo QTD-PARA-PRD, que é a
quantidade de uma subparte necessária para fazer uma superparte.
Note que QTD-À-MÃO e QTD-PARA-PRD têm o mesmo tipo de valor
QTD.
o método entidade-relacionamento para projeto lógico de bancos de dados 49
DOMÍNIO
CONCEITUAL
SUPERIOR
DOMÍNIO
CONCEITUAL
INFERIOR
DEPT FUNC
SALÁRIO NºDO
TELEFONENº DO FUNCDATAORÇAMENTO(Nº DO DEPT)
ORÇAMENTO
DESSE ANO
ORÇAMENTO DO
ANO PASSADO
DATA DE
INÍCIO DO DEPT
DATA DE
NASCIMENTO
TELEFONE
COMERCIAL
TELEFONE
RESIDENCIAL
DEPT-FUNC
DOMÍNIO
CONCEITUAL
SUPERIOR
DOMÍNIO
CONCEITUAL
INFERIOR
ESFORÇO DATA Nº DO PROJ ORÇAMENTO
PROJ-
NOME
DATA
DE INÍCIO
DO PROJETO
PROJ-
FUNC
PROJ
 PROJ
GERENTE.
FUNC
Figura 54 Atributos e tipos de valor para FORN, PARTE e PROJ-FORN-PARTE.
Figura 55 Atributos e tipos de valor de DEPÓSITO, INVENTÁRIO e PRD-REL.
As Figuras 52-55 ilustram os atributos e tipos de valor neces-
sários para descrever as propriedades de entidades e relacionamentos
que podem ser de interesse para uma ir indústria.
DOMÍNIO
CONCEITUAI.
SUPERIOR
DOMÍNIO
CONCEITUAL
INFERIOR
DEPÓSITO
Nº DO
DEPÓSITO ENDEREÇO QTD
QTD-A-MÃO QTD-PARA-PRD
PRD-RELPARTEINVENTARIO
DOMÍNIO
CONCEITUAL
SUPERIOR
DOMÍNIO
CONCEITUAL
INFERIOR
QTD Nº DOFORN ENDEREÇO
N«DA
PARTE PESO COR
FORN
PARTEPROJ
PROJ-
FORN-
PARTE,
F O R N
POTENCIAL
50 Modelagem de Dados
O método entidade-relacionamento para projeto lógico de bancos de dados 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 umdiagrama de
estrutura de dados usando as regras de tradução discutidas na Seção
4.2.
Considere o diagrama E-R da Figura 50. Ele pode ser traduzido
no diagrama de estrutura de dados mostrado na Figura 56. Todos os
tipos de entidade no diagrama E-R tornam-se tipos de registro no dia-
grama de estrutura de dados. Uma vez que o relacionamento DEPT-
FUNC é um mapeamento um-para-muitos, ele é traduzido em um
conjunto de estrutura de dados (ou seja, um ponteiro) no diagrama de
estrutura de dados. Similarmente, o tipo de relação PROJ-GERENTE é
também um mapeamento um-para-muitos e é traduzido em um conjunto
de estrutura de dados. Uma vez que o tipo de relacionamento PROJ-
FUNC é um mapeamento muitos-para-muitos, ele é traduzido em um
tipo de registro com ponteiros apontando para tipos de registros de
entidades relacionados, FUNC e PROJ. Como o tipo de relação PROJ-
FORN-PARTE é um mapeamento ternário muitos-para-muitos-para-
muitos, ele é traduzido em um tipo de registro.O tipo de relação
PRD-REL é traduzido em um tipo de registro, uma vez que é um tipo de
relação definido pelo mesmo tipo de entidade. Note que o tipo de registro
PRD-REL na Figura 42 tem dois ponteiros (ou seja, conjuntos de estru-
tura de dados) apontando do mesmo tipo de registro PARTE. Note
também que o tipo de registro PROJ-FORN-PARTE é apontado por três
ponteiros vindos dos tipos de registro (de entidade) relacionados.
5.2.6 Projetar Formato de Registro
A sexta etapa é agrupar atributos de entidades e relacionamen-
tos em registros e decidir como implementar os conjuntos de estrutura
de dados (usando "cadeias"?, "conjuntos de ponteiros"? etc.)
As orientações básicas para agrupar atributos em registros são:
1. Todos os atributos de uma entidade serão colocados no mesmo
tipo de registro. Por exemplo, os atributos de DEPT serão
tratados como nomes de campos no tipo de registro DEPT.
(Ver Figuras 52 e 57.)
2. Se o tipo de relacionamento for um mapeamento um-para-
muitos, os atributos do relacionamento serão tratados como
campos no tipo de registro membro do conjunto de estrutura
de dados. Por exemplo, o tipo de relacionamento DEPT-FUNC
(Figura 52) é um mapeamento um-para-muitos e seu atributo
DATA DE INÍCIO NO DEPT será incluído como um campo no
tipo de registro membro do conjunto de estrutura de dados
(ou seja, o tipo de registro FUNC; ver Figuras 56 e 58).
Figura 56 O diagrama de estrutura de dados derivado do diagrama E-R da Figura
50.
Nº DO DEPT ORÇAMENTODESTE ANO
ORÇAMENTO DO
ANO PASSADO
PARA O PRIMEIRO
REGISTRO FUNC
NO DEPARTAMENTO
Figura 57 Registro DEPT.
52 Modelagem de Dados
FUNC PROJ FORN PARTE DEPÓSITO
INVENTÁRIOPRD-REL
FORN POTENCIAL
PROJ-FORN-PARTEPROJ-FUNC
DEPT
Rafael Gama de Macedo Jr.
PARA O REGISTRO
FUNC SEGUINTE NO
MESMO DEPARTAMENTO
PARA O PRIMEIRO
REGISTRO PROJ GERENCIADO
POR ESTE FUNCIONÁRIO
Figura 58 Registro FUNC.
PARA O PRIMEIRO
REGISTRO FUNC-PROJ
RELACIONADO
COM ESTE FUNCIONÁRIO
3. Se o tipo de relacionamento for traduzido em um tipo de
registro, então os atributos de relacionamento serão tratados
como campos nesse tipo de registro. Por exemplo, o tipo de
relação PROJ-FUNC na Figura 53 é traduzido em um tipo de
registro, e os atributos %ESFORÇO e DATA DE INÍCIO NO
PROJ tornam-se campos no tipo de registro mostrado na
Figura 60.
Podemos aplicar essas regras a outros tipos de entidade e de
relacionamento. Uma vez que todos os outros tipos de entidade e relacio-
namento, exceto PROJ-GERENTE, na Figura 50 são traduzidos dire-
tamente 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.
N« DO FUNC DATA DENASCIMENTO
DATA DE
INlCIO NO DEP1 SALÁRIO
TELEFONE
COMERCIAL
TELEFONE |
RESIDENCIAL
O método entidade-relacionamento para projeto lógico de bancos de dados 53
Figura 61 Registro FORN.
54 Modelagem de Dados
Figura 60 Registro PROJ-FUNC
DATA DE INÍCIO
NO PROJ % ESFORÇO
PARA O PRÓXIMO REGISTRO
PROJ-FUNC PARA O MESMO PROJETO
PARA O PRIMEIRO REGISTRO
PARTE-FORN-PROJ RELACIONADO
A ESTE FORNECEDOR
PARA O PRIMEIRO FORN POTENCIAL
RELACIONADO A ESTE FORNECEDOR
REGISTRO
FORN. ENDEREÇO
PARA O PRÓXIMO REGISTRO
PROJ GERENCIADO PELO
MESMO FUNCIONÁRIO
Nº DO PROJ PROJ-NOME ORÇAMENTO
PARA O PRIMEIRO REGISTRO
PROJ-FORN-PARTE RELACIONADO
A ESTE PROJETO
PARA O PRIMEIRO REGISTRO
PROJ-FUNC RELACIONADO
A ESTE PROJETO
Figura 59 Registro PROJ.
PARA O PRÓXIMO REGISTRO
PROJ-FUNC PARA O MESMO FUNCIONÁRIO
PARA O PRIMEIRO REGISTRO PARA O PRIMEIRO REGISTRO
PARTE-FORN-PROJ RELACIONADO FORN POTENCIAL RELACIONADO
A ESTA PARTE A ESTA PARTE
PARA O PRIMEIRO REGISTRO
PRD-REL NA CADEIA ONDE-USADA PARA O PRIMEIRO REGISTRO PRD-REL
NA CADEIA COMPONENTE
PARA O PRIMEIRO REGISTRO
INVENTÁRIO RELACIONADO A ESTA PARTE
Figura 62 Registro PARTE.
PARA O PRÓXIMO REGISTRO PARTE-FORN-PROJ
PARA A MESMA PARTE
PARA O PRÓXIMO REGISTRO PARTE-FORN-PROJ
PARA O MESMO FORNECEDOR
PARA O PRÓXIMO REGISTRO PARTE-FORN-PROJ
PARA O MESMO PROJETO
Figura 63 Registro PARTE-FORN-PROJ.
o método entidade-relacionamento para projeto lógico de bancos de dados 55
Nº DA PARTE PESO COR
QTD
PARA O PRÓXIMO REGISTRO FORN-POTENCIAL
PARA A MESMA PARTE
PARA O PRÓXIMO REGISTRO FORN POTENCIAL
PARA O MESMO FORNECEDOR
Figura 64 Registro FORN POTENCIAL.
Nº DO DEPÓSITO ENDEREÇO
PARA O PRIMEIRO REGISTRO INVENTÁRIO
RELACIONADO A ESTE DEPÓSITO
Figura 65 Registro DEPÓSITO.
PARA O PRÓXIMO REGISTRO INVENTÁRIO
PARA A MESMA PARTE
QTD-À-MÃO
PARA O PRÓXIMO REGISTRO INVENTÁRIO
PARA O MESMO DEPÓSITO
Figura 66 Registro INVENTÁRIO.
Após colocar todos os atributos nos tipos de registro, a questão
seguinte é decidir como implementar os conjuntos de estrutura de dados.
Neste exemplo industrial, vamos usar cadeias como a implementação
física dos conjuntos de estrutura de dados. Isto é, vamos usar as Figuras
56 Modelagem de Dados
O método entidade-relacionamento para projeto lógico de bancos de dados 57
39 e 42 como a implementação física das Figuras 36 e 40, respectiva-
mente. A partir dessas figuras, podemos fazer as seguintes observações
sobre como implementar ponteiros de cadeia:
1. Se o registro for o tipo de registro proprietário de um conjunto
de estrutura de dados, ele deve ter um ponteiro para a pri-
meira ocorrência de registro membro.
2. Se o registro for um tipo de registro membro de um conjunto
de estrutura de dados, ele deve ter um ponteiro para a ocor-
rência seguinte de registro membro na cadeia ou para a
ocorrência de registro proprietário se este for o último regis-
tro na cadeia.
3. Se um tipo de registro estiver envolvido em múltiplos conjun-
tos de estrutura de dados, ele deve conter vários ponteiros,
um para cada conjunto de estrutura de dados.
Usando estas regras, podemos definir os ponteiros nos tipos de
registro como é mostrado nas Figuras 57 e 66. Vamos considerar pri-
meiro a Figura 57. Uma vez que o tipo de registro DEPT é o tipo de
registro proprietário de um conjunto de estrutura de dados, ele tem um
ponteiro apontando para a primeira ocorrência de registro FUNC na-
quele departamento. 0 tipo de registro FUNC na Figura 58 tem três
ponteiros, uma vez que está envolvido em três conjuntos de estrutura de
dados. Uma vez que o tipo de registro FUNC é o tipo de registro membro
de um conjunto de estrutura de dados cujo proprietário é o tipo de
registro DEPT, o tipo de registro FUNC manterá um ponteiro para a
ocorrência seguinte de registro FUNC no mesmo departamento. Uma
vez que o tipo de registro FUNC é o registro proprietário de um conjunto
de estrutura de dados cujo tipo de registro membroé PROJ, ele mantém
um ponteiro para a primeira ocorrência de registro PROJ gerenciada por
esse funcionário. Se o funcionário não estiver gerenciando nenhum pro-
jeto, o valor do ponteiro será nulo. Uma vez que o tipo de registro FUNC
é também o tipo de registro proprietário do conjunto de estrutura de
dados cujo tipo de registro membro é PROJ-FUNC, ele mantém um
ponteiro para a primeira ocorrência de registro PROJ-FUNC na cadeia.
Uma vez que PROJ-FUNC é o tipo de registro membro de dois
conjuntos de estrutura de dados, ele mantém dois ponteiros: um apon-
tando para a ocorrência seguinte do registro PROJ-FUNC para o mesmo
funcionário e o outro apontando para a ocorrência seguinte do registro
PROJ-FUNC para o mesmo projeto. (Ver Figuras 56 e 60.)
Consideremos um caso mais complicado: o tipo de registro PROJ-
FORN-PARTE nas Figuras 56 e 63. Uma vez que este é o tipo de registro
membro de três conjuntos de estrutura de dados, tem três ponteiros, um
para cada cadeia. Explicações semelhantes podem ser dadas para os
ponteiros em outros tipos de registro.
Figura 67 Diagrama E-R para um banco de dados de anotação de pedidos.
Figura 68 Atributos e tipos de valor para CLIENTE e PEDIDO.
58 Modelagem de Dados
Nº DO
CLIENTE
SALDO DE
CONTA
LIMITE DE
CRÉDITO DESCONTO ENDEREÇO
Nº DO
PEDIDO DATA
DESPACHO PARA
. ENDEREÇOS
DESPACHO PARA
ENDEREÇO
CLIENTE CLIENTEPEDIDO PEDIDO
LINHA LINHAPARTE PARTE
PEDIDO DEPÓSITO
INVENTARIO;
CLIENTE
PEDIDO,CLIENTE
5.3 EXEMPLO 2: UM BANCO DE DADOS DE ANOTAÇÃO
DE PEDIDOS DE COMPRA
5.3.1 Identificar Tipos de Entidade
Uma anotação de pedidos lida com os pedidos dos clientes em
itens, os quais podem estar armazenados em determinados depósitos. Os
tipos de entidade importantes são: CLIENTE, PEDIDO, LINHA,
PARTE, ITEM e DEPOSITO. (Ver Figura 69.) Cada pedido tem várias
linhas, cada uma declarando o número e a quantidade do item desejado.
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 LI-
NHA são existências-dependentes e ID-dependentes das enti-
dades PEDIDO correspondentes. Cada pedido tem várias
linhas, mas cada linha faz parte de apenas um pedido.
PEDIDO
Nº DA
LINHA QTD
QTD QTDA
PEDIDA ENTREGAR
PARTE
LINHA
PARTELINHA
o método entidade-relacionamento para projeto lógico de bancos de dados 59
3. A relação LINHA-PARTE descreve que parte é anotada nesta
linha do pedido. Descreve também a quantidade da parte que
está sendo pedida. Este tipo de relacionamento é um mapea-
mento um-para-muitos. Cada linha contém apenas uma
parte, mas cada parte pode ser colocada em muitas linhas
(usualmente em pedidos diferentes).
4. A relação INVENTÁRIO mantém o controle de que parte está
estocada em qual depósito, e é um mapeamento muitos-para-
muitos.
5.3.3 Desenhar um Diagrama E-R com Tipos de Entidade
e Relacionamento
A Figura 67 é um diagrama ER para um determinado banco de
dados de anotação de pedidos de compra. Note que dois tipos de entida-
de, PARTE e DEPÓSITO, já foram discutidos no Exemplo 1. Na verdade,
é possível fundir as Figuras 67 e 50, formando um grande diagrama E-R.
5.3.4 Identificar Tipos de Valor e Atributos
A Figura 68 mostra os atributos e tipos de valor para tipos de
entidade CLIENTE e PEDIDO. Uma entidade CLIENTE tem cinco
atributos: Nº DO CLIENTE, SALDO DE CONTA, LIMITE DE CRÉDI-
TO, DESCONTO e DESPACHO PARA ENDEREÇOS. Cada cliente pode
ter mais de um DESPACHO PARA ENDEREÇO. Cada entidade PE-
DIDO tem três atributos: Nº DO PEDIDO, DESPACHO PARA ENDE-
REÇO e DATA. Cada pedido tem apenas um DESPACHO PARA
ENDEREÇO. O relacionamento CLIENTE-PEDIDO não tem atributos.
A Figura 69 ilustra os atributos e tipos de valor das propriedades
das entidades LINHA e das relações LINHA-PARTE. Uma entidade
LINHA tem um atributo: Nº DA LINHA. Uma relação LINHA-PARTE
tem dois atributos: QTD PEDIDA e QTD A ENTREGAR. O valor da QTD
A ENTREGAR é, inicialmente, igual à QTD PEDIDA e é gradualmente
reduzido a zero conforme os despachos parciais são feitos.
60 Modelagem de Dados
Os atributos e tipos de valor para PARTE, INVENTÁRIO e
DEPÓSITO podem ser encontrados nas Figuras 54 e 55.
5.3.5 Traduzir o Diagrama E-R em um Diagrama de
Estrutura de Dados
Usando as regras de tradução discutidas na Seção 4.2, o diagra-
ma E-R da Figura 67 pode ser traduzido no diagrama de estrutura de
dados mostrado na Figura 70. Todos os tipos de entidade tornam-se tipos
de registro no diagrama de estrutura de dados. Uma vez que os tipos de
relacionamento CLIENTE-PEDIDO, PEDIDO-LINHA e LINHA-PARTE
são mapeamentos um-para-muitos, eles são traduzidos em conjuntos de
estrutura de dados no dia diagrama de estrutura de dados. Uma vez que o
relacionamento INVENTARIO é um mapeamento muitos-para-muitos,
ele é traduzido em um tipo de registro.
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 Fi-
gura 70. O registro LINHA contém não apenas os atributos da entidade
LINHA, mas também os atributos dos relacionamentos LINHA-PARTE.
(Ver Figuras 69 e 73.) Neste exemplo de banco de dados de anotação de
LINHA
PARTE
INVENTÁRIO
DEPÓSITOPEDIDO
CLIENTE
o método entidade-relacionamento para projeto lógico de bancos de dados 61
pedidos de compra também escolhemos cadeias como implementação
física dos conjuntos de estrutura de dados. Os formatos de registro para
os tipos de registro DEPÓSITO e INVENTÁRIO estão mostrados nas
Figuras 65 e 66. Note que, se fundirmos as Figuras 56 e 60, teremos de
reprojetar o formato de registro para o registro PARTE; isto é, fundir a
Figura 62 com a Figura 74.
Figura 72 Registro PEDIDO.
62 Modelagem de Dados
PARA O PRIMEIRO REGISTRO PEDIDO
RELACIONADO A ESTE CLIENTE
Figura 71 Registro CLIENTE.
PARA O PRÓXIMO REGISTRO PEDIDO
PERTENCENTE AO MESMO CLIENTE
PARA O PRIMEIRO REGISTRO LINHA
RELACIONADO A ESTE PEDIDO
DESPACHO
PARA
ENDEREÇO
DATANº DO PEDIDO
Nº DO
CLIENTE
SALDO DA
CONTA
LIMITE DE
CRÉDITO DESCONTO
GRUPO DE REPETIÇÃO
DESPACHO
PARA
ENDEREÇOS
Figura 74 Registro PARTE.
5.4 EXEMPLO 3: UM BANCO DE DADOS DE UMA
BIBLIOTECA
5.4.1 Identificar Tipos de Entidade
Uma Biblioteca quer manter o controle de seus livros e também
proporcionar um sistema computadorizado para busca de livros por
categorias, palavras-chaves ou autores. Tipos de entidade importantes
são: LIVRO, AUTOR, PALAVRA-CHAVE, CATEGORIA e FUNCIO-
NÁRIO. (Ver Figura 75.)
o método entidade-relacionamento para projeto lógico de bancos de dados 63
Nº DA PARTE PESO COR
PARA O PRIMEIRO REGISTRO LINHA
RELACIONADO A ESTA PARTE
Figura 73 Registro LINHA.
PARA O PRÓXIMO REGISTRO LINHA
RELACIONADO À MESMA PARTE
Nº DA LINHA QTD PEDIDA QTD A ENTREGAR
PARA O PRÓXIMO REGISTRO LINHA
PERTENCENTE AO MESMO PEDIDO
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 enti-
dades LIVRO. Uma é a AUTORIA PRINCIPAL e a outra é a CO-
AUTORIA. (Ver Figura 75.) Cada livro tem apenas um autor principal,
mas um autor pode ser o autor principal de muitos livros. Por outro lado,
cada livro pode ter vários co-autores (além do autor principal) e cada
autor pode ser o co-autor de muitos livros. Há dois tipos de relaciona-
mento entre entidades CATEGORIA e entidades LIVRO: uma é o
CATÁLOGO