O relacionamento do tipo unário, é identificado também como um

43

ela mesma. Isso não implica que um registro dessa entidade esteja rela- cionado com ele mesmo.

Vejamos o caso de um produto em fabricação. De acordo com o grau de montagem, um conjunto de peças é montado de forma a produzir uma peça mais complexa, mas que não é ainda o produto final. Essa peça complexa se junta a outras peças ou a matérias-primas, de forma, então, a compor o produto final. Todas essas peças são, aqui, representadas por uma entidade “peça”, sendo o relacionamento denominado “parte de”. O conceito de papel também é importante para a definição de um rela- cionamento unário, para que possamos entender como as instâncias estão associadas. No caso da peça ou peças que “compõem” outra peça, e da peça que é “composta por” outras peças, temos os dois papéis (o do que contém e do que está contido). A definição dos papéis auxilia posteriormente na determinação da cardinalidade do relacionamento. Os papéis devem ser explicitados no diagrama do relacionamento ao lado das ligações. Pela Figura 2.8, vemos que existem os pares p1, p2 e

p3, p2, indicando que a peça p2 é composta pelas peças p1 e p3. Por sua

vez, vemos também que p4 é composta pela peça p2. A cardinalidade N:1 indica que mais de uma peça pode compor outra peça. Essa repre- sentação ilustra bem a estrutura de materiais, também chamada Bill Of

Materials (BOM) para certa linha de produção, o que é necessário em

um programa de Planejamento das Necessidades de Materiais (Mate-

rials Requirement Planning – MRP).

Outros exemplos de relacionamentos unários são os “empregado-che- fia” ou “contas-subcontas” (tal como num plano de contas contábil).

Figura 2.8 – Diagrama de ocorrências para o auto-relacionamento

PARTE_DE PEÇA

Composta por compõem

PEÇA PARTE_DE p1 p2 p4 p3 p1,p2 p2,p4 p3,p2

Figura 2.9 – Exemplo de relacionamento ternário

OCUPAÇÃO

PROJETO

FUNCIONÁRIO _{1 1} ÁREA

N

Um relacionamento ternário implica a associação de três entidades ao mesmo tempo, que pode ser exemplificado por uma associação “funcioná- rio-área-projeto”; desde que um funcionário trabalhe apenas em uma área,

45

porém em mais de um projeto. O relacionamento ilustrado (Figura 2.9) mostra como ficaria esta associação e o relacionamento “ocupação”.

Figura 2.10 – Diagrama de ocorrências para o exemplo de relacionamento ternário

FUNCIONÁRIO PROJETO f1 p1 f2 p2 f1,p1,a2 p3 f3 p4 f2,p2,a1 ÁREA f2,p3,a1 a1 f3,p4,a2 OCUPAÇÃO a2

O diagrama de ocorrências mostra, agora, não mais os “pares”, mas “ternos” ou “triplas” mostrando as instâncias associadas nesse modelo (Figura 2.10). Veja que os ternos f2, p2, a1 e f2, p3, a1 validam a cardina- lidade de 1:1 para a associação “funcionário-área” e 1:N para a asso- ciação “funcionário-projeto”.

É possível, ainda, representarmos relacionamentos contendo mais de três entidades, o que caracteriza relacionamentos quaternários e sub seqüentes.

Obrigatoriedade

Em certos relacionamentos entre entidades podem aparecer situações onde a presença de uma entidade não é obrigatória. Um bom exemplo é o relacionamento “empregado-dependente” na figura abaixo.

Figura 2.11 – Relacionamento empregado-dependente

EMPREGADO FILIAÇÃO DEPENDENTE 1 N

O empregado pode ter dependentes ou não. Para representar isso num diagrama E-R, expandimos o conceito de cardinalidade para mínima e

máxima.

Quando um empregado não possuir dependentes, caracterizamos a _

cardinalidade mínima para 0 (zero) do lado da entidade dependente. Como a entidade empregado sempre participa do relacionamento, a cardinalidade mínima será 1 (um) do lado do empregado.

Quanto à

_ cardinalidade máxima (mantemos o que foi especificado anteriormente), do lado do dependente será N, pois um empregado pode ter vários dependentes. E a cardinalidade máxima para empre- gado será obviamente 1 (um dependente só pode estar relacionado a um empregado).

Para representar agora as

_ cardinalidades mínima e máxima, utiliza- mos o par: min e max. Assim, do lado do empregado, a repre sen tação

47

das cardinalidades será (1, 1) e do lado do dependente será (0, N), conforme a Figura 2.12.

Da entidade que participa num relacionamento em que não seja obri- gatória a presença, diz-se que é uma entidade fraca. Assim, elas podem ser divididas em fortes e fracas. A entidade fraca também é represen- tada na literatura como sendo um retângulo com linha dupla incluindo a ligação com o relacionamento.

Figura 2.12 – Relacionamento empregado-dependente representando obrigatoriedade

EMPREGADO FILIAÇÃO DEPENDENTE (1,1) (0,N)

EMPREGADO FILIAÇÃO DEPENDENTE

e1 e1,d1 d1 e2 e1,d2 d2 e3 e2,d3 d3 e4 e3,d4 d4 e5 e3,d5 d5

Na figura acima, você vê a representação do diagrama de ocorrências. Como nele, a entidade “dependente” possui cardinalidade mínima 0 (não há obrigatoriedade), existem instâncias de “empregado” que não

estão associados a qualquer instância de “dependente” (e4 e e5). Note também que todas as instâncias de “dependente” estão associadas a suas respectivas instâncias de “empregado”.

[

atributos de relacionamento

]

Assim como uma entidade pode possuir atributos, um relacionamento também pode ter atributos que não ficariam bem localizados nas suas entidades associadas.

No relacionamento “funcionário-projeto” (Figura 2.13), usaremos um

atributo, a ser colocado, chamado tempo para guardar as horas traba- lhadas pelo funcionário no projeto específico. Se o atributo “tempo” ficar ligado à entidade “funcionário”, a informação referenciada nesse atributo será relativa ao funcionário, não importando o projeto. Por outro lado, se o atributo “tempo” ficar ligado à entidade “projeto”, ele é compreendido mais como o tempo trabalhado no respectivo projeto, não importando qual funcionário trabalhou. Portanto, se for ligado a qualquer uma das entidades, o atributo não atinge o objetivo, sendo, em nosso exemplo (Figura 2.13) necessário colocar o atributo “tempo” ligado ao relacionamento “alocação” para dessa forma significar as horas trabalhadas pelo funcionário no projeto específico.

Figura 2.13 – Exemplo de atributo de relacionamento

FUNCIONÁRIO ALOCAÇÃO PROJETO N N

49

[

generalização/especialização

]

Também chamada de subtipo, a generelização/especialização per- mite que uma entidade se diferencie em vários tipos. Por exemplo, se alguns empregados são programadores, e todos os programadores são empregados, então, podemos dizer que “programador” é um subtipo do supertipo “empregado”. nessa situação, se analistas também exis- tem como empregados, então “analista” também será um subtipo do supertipo “empregado” (Figura 2.14).

Podemos, portanto, discutir a existência de herança entre entidades, bem como a de uma hierarquia de tipos, porquanto, com a generaliza-

ção/especialização, a entidade caracterizada como supertipo assume as propriedades do subtipo em determinadas ocorrências. A represen- tação de generalização/especialização num diagrama E-R se faz com um triângulo invertido. A aqui utilizada (representação) se deve a Korth e Silberschatz7_{, mas outras formas também são encontradas em Heuser}8_.

Figura 2.14 – Exemplo de generalização/especialização

PROGRAMADOR ANALISTA EMPREGADO

A herança entre as entidades pressupõe que uma entidade subtipo ou

filha pode herdar as propriedades da que é supertipo ou pai. Como propriedades são compreendidos os atributos e relacionamentos da entidade-pai.

No diagrama da Figura 2.15, vemos um exemplo onde (no contexto de um sistema de livraria) a entidade “cliente” está associada à entidade “mídia” através do relacionamento “venda”. Veja que pelo diagrama, “mídia” pode assumir uma ocorrência da entidade-filha “livro” ou uma ocorrência da outra entidade-filha “revista”. Veja que “mídia” possui o atributo identificador “ID” e “nome”, que identifica, por sua vez, uma ins- tância de “mídia”. Atributo que irá servir tanto para “livro” quanto para “revista”. Agora, quando “mídia” assume a ocorrência da entidade-filha “livro”, esta irá herdar os atributos que pertencem à mídia (ID e nome) mais os seus atributos específicos (ou seja, ISBN e ano). Quando “mídia” assume a ocorrência da entidade-filha “revista”, esta irá herdar os atribu- tos de “mídia” (ID e nome) mais os seus atributos específicos (que agora são ISSN e periodicidade). Além disso, as entidades-filha irão herdar tam- bém o relacionamento “vendas” que existe com a entidade “cliente”.

Figura 2.15 – Exemplo de generalização/especialização com atributos e relacionamento

Num diagrama E-R, contemplando generalização/especialização, pode- mos também fazer com que existam vários níveis, uma vez que um subti po pode ser ao mesmo tempo um supertipo e assim há um novo

CLIENTE VENDA LIVRO REVISTA NOME ID QUANTIDADE PREÇO NOME ID PERIODICIDADE ISSN ANO ISBN (1,N) (1,N) MÍDIA

51

nível de hierarquia de tipos. O exemplo da Figura 2.16 pode ser esten- dido de forma a ilustrar a inclusão de mais um nível. Veja que agora mídia pode se projetar na entidade-filha “filme”. Esta, por sua vez, é a entidade-pai de outras duas entidades: “VHS” e “DVD”. Note que o atributo duração está colocado na entidade-pai “filme”, pois tanto “VHS” quanto “DVD” possuem certa duração.

Figura 2.16 – Exemplo de generalizacão/especialização com mais níveis

[

um diagrama

-

mais complexo

]

Na Figura 2.17, encontra-se um diagrama E-R com um número maior de entidades e relacionamentos descrevendo uma parte de um sistema comercial.

CLIENTE VENDA

LIVRO FILME REVISTA

MÍDIA NOME ID QUANTIDADE PREÇO NOME ID PERIODICIDADE ISSN ANO ISBN (1,N) (1,N) VHS DVD DURAÇÃO

Nele observamos duas entidades – “clientes” e “pedido” – relaciona- das entre si. O relacionamento não apresenta um nome, mas poderia ter qualquer descrição que fosse considerada a mais apropriada ao con- texto. A descrição, ali encontrada, significa que os clientes fazem pedi- dos. A cardinalidade máxima N ao lado da entidade “pedido” indica que um cliente pode fazer mais de um pedido, porém um pedido pode ser associado somente a um cliente, como indica a cardinalidade máxima 1 que está ao lado da entidade “cliente”. Na questão da cardinalidade mínima ou obrigatoriedade, vemos que um pedido sempre estará asso- ciado a pelo menos um cliente, porém a cardinalidade mínima 0 ao lado de “pedido” indica que um cliente pode não estar associado a um pedido. Pode-se notar também que a entidade “cliente” possui um atributo chave ou identificador “código”. Assim, este atributo indicará individualmente cada instância ou ocorrência de um cliente simbolizado pela entidade “cliente”. Quanto à entidade “pedido”, também possui um código iden- tificando cada pedido individualmente. Porém, o relacionamento indica que para o pedido estar associado ao cliente, a instância de “pedido” precisa estar associada a uma instância de “cliente”, e assim a ligação do relacionamento identificador estar enfatizada do lado de pedido*. Deve-se imaginar a entidade “pedido” como sendo uma “aglutinadora” de itens. Um cliente pode solicitar mais de um item constando em um pedido. Assim, “pedido” está associada à entidade “itens” por um rela- cionamento não nominado. A obrigatoriedade indicada pelas cardina- lidades mínimas mostra que deve existir pelo menos um item para um pedido (logicamente, se existe um pedido deve existir pelo menos um item associado a este pedido). A cardinalidade máxima indica que um

* No modelo lógico relacional isso é entendido como sendo o código do cliente fazendo parte da relação “pedido” como uma chave externa ou estrangeira, como será visto mais adiante.

53

pedido pode estar associado a vários itens, porém um item deve estar associado a um único pedido.

Da mesma forma que o relacionamento anterior, deve-se notar que existe um atributo chave ou identificador para o item. Um item poderá ser numerado para cada pedido começando, por exemplo, do item número 1 até o item máximo. Como poderemos ter vários itens de número 1, precisamos fazer o relacionamento identificador do lado da entidade “item”, de forma que o atributo chave esteja associado ao atri- buto chave da entidade “pedido”. Agora será permitido referenciar ade- quadamente o pedido 1000 com o seu item 1 e o pedido 1001 também com o seu item 1 respectivo.

O relacionamento “item-produto” associa as entidades “itens” e “esto- que”. A cardinalidade indica que um item pode ter mais de um produto em estoque (ou seja, um item de pedido poderá possuir mais de um pro- duto. Isso pode acontecer em termos reais como numa promoção, por exemplo, em que dois ou mais produtos são oferecidos com certo des- conto). A cardinalidade mínima 0 do lado da entidade “estoque” indica que uma instância de “estoque” não é obrigada a participar de uma ins- tância de “item”. Notamos também que o relacionamento “item-pro- duto” possui dois atributos: “preço” e “desconto”. Esses atributos não poderiam estar ligados à entidade “estoque”, pois iriam indicar que o preço e desconto seriam sempre os mesmos não importasse o item. Por outro lado, caso estivessem ligada à entidade “item”, se houvesse mais de uma instância de produto para um item, o preço e o desconto teriam que ser entendidos como os mesmos para os produtos associados a este item. Assim, o relacionamento fica com os dois atributos*.

* Num modelo relacional, esse relacionamento se transformará em uma tabela com seus atributos próprios e os códigos (que são identificadores) respectivos de cada entidade associada.

Figura 2.17 – Exemplo de diagrama E-R sobre uma parte de um sistema comercial CLIENTE PEDIDO NOME CODIGO (1,1) (0,N) TELEFONE LIMITE_COMPRA VALOR (1,1) DATA CODIGO ESTOQUE ITEM_ PRODUTO ITENS (0,N) (1,1) (1,N) CODIGO SUBTOTAL QTD DESCONTO PREÇO PRAZOENT (1,N) CUSTO PROD_ FORNECEDORES FORNECEDOR (1,N) CODIGO NOME TELEFONE UF ULTENT PTOPED ESTMIN CODIGO DESCRIÇAO QTD

O último relacionamento “prod_fornecedor” associa as entidades “estoque” e “fornecedor”. Este relacionamento significa quais produ- tos no estoque são fornecidos por quais fornecedores. Um produto em estoque pode ser fornecido por vários fornecedores. Um fornecedor pode fornecer mais de um produto (veja a cardinalidade máxima N dos dois lados). O relacionamento é obrigatório também, ou seja, um item sempre deve estar associado a pelo menos um fornecedor. E um forne-

55

[

entidade associativa

]

Em certos momentos, num processo de modelagem de um diagrama E-R, veremos que será necessário associar uma entidade a um relacio- namento. Porém, não se pode pela regra de associação de diagramas E-R associar um relacionamento a outro. Por exemplo, no diagrama E-R explicado anteriormente, caso queiramos associar uma entidade denominada “ordem de compra” para que possamos controlar os pro- dutos que são solicitados aos fornecedores, a qual entidade associar? Se associarmos diretamente à entidade “estoque”, não teremos como ligar a qual fornecedor será feita a ordem de compra. Caso associemos com a entidade “fornecedor”, não teremos a informação de produto para solicitar. A solução seria relacionar diretamente com o próprio relacionamento “prod_fornecedor”, que vem a ser onde encontramos as duas informações juntas. Porém, não podemos ligar dois relaciona- mentos. Assim, transformamos o relacionamento “prod_fornecedor” numa entidade associativa (Figura 2.18), e agora poderemos estabele- cer um relacionamento entre a entidade associativa “prod_fornecedor” e a entidade “ordem de compra”. O símbolo para uma entidade asso- ciativa é um retângulo sobrescrevendo um losango.

Podemos pensar num modelo equivalente, caso não queiramos traba- lhar com a entidade associativa*. Assim, para o novo modelo, trans- forma-se a entidade associativa “prod_fornecedor” em uma entidade, e associa-se esta a cada entidade do diagrama E-R com seus respectivos relacionamentos exigidos pelo padrão de diagramação.

* Na conversão de um diagrama E-R para um modelo relacional, o processo é mais simples sem o uso de entidade associativa.

Figura 2.18 – Exemplo de entidade associativa FORNECEDOR (1,N) CODIGO NOME TELEFONE UF ULTENT ESTOQUE PRAZOENT (1,N) CUSTO PTOPED ESTMIN CODIGO DESCRIÇAO QTD ORDEM DE COMPRA PROD_ FORNECEDOR

Note que no diagrama E-R, da Figura 2.19, foi substituída a entidade associativa pela entidade “prod_fornecedor”, tendo relacionamentos com as outras entidades: “estoque” e “fornecedor”. Com a entidade “ordem de compra”, existe um relacionamento que permite identificar a ordem de compra com o código respectivo, e esta instância pode aglu-

tinar (como acontece na entidade “pedido” descrita anteriormente) vários pares produto-fornecedor. E a quantidade a ser requisitada é colocada no relacionamento, pois, a cada nova ordem de compra, quantidades diferentes poderão ser solicitadas. Não faria sentido se fosse colocado o atributo da quantidade na entidade “ordem de com- pra”, nem mesmo na entidade “prod_fornecedor”.

57

Figura 2.19 – Uma alternativa para o diagrama anterior sem entidade associativa

FORNECEDOR CODIGO NOME TELEFONE UF ULTENT ESTOQUE PRAZOENT (1,1) CUSTO PTOPED ESTMIN CODIGO DESCRIÇAO QTD ORDEM DE COMPRA PROD_ FORNECEDOR (1,N) (1,1) (1,N) (1,N) (1,1) QTD CODIGO

[

resumo

]

O modelo entidade-relacionamento, difundido por Chen, permite agre- gar à representação dos dados aspectos semânticos, apresentando um bom ponto de partida para a compreensão daquilo que normalmente não transparece num banco de dados relacional. Basicamente o modelo propõe a representação da entidade, que pode ser um elemento con- creto ou abstrato, referente a algo pessoal, lugar, objeto, evento ou conceito; do atributo, que são as características da entidade, pode ser simples ou derivado; e do relacionamento, que associa uma ou mais entidades. O tipo de relacionamento, de acordo com o número de enti- dades que participam da relação, pode ser unário, binário ou ternário. A obrigatoriedade refere-se a situações em que há necessidade da pre- sença de uma entidade, ou não, contendo o conceito de cardinalidade (o número de elementos associados à entidade). Uma entidade que par- ticipa de um relacionamento é dita fraca no caso de não ser obrigató- ria a sua presença. Um relacionamento também pode possuir atributos, assim como uma entidade, na qual a presença de tais atributos faça mais sentido ao modelo do que se estivessem ligados às entidades participan- tes. A diferenciação de uma entidade em subtipos e supertipos também é possível, sendo tal representação hierárquica denominada de genera-

lização-especialização. A entidade associativa permite a representação de uma entidade que evita a conexão entre dois relacionamentos, o que não é permitido pelo modelo E-R.

59

[

exercícios

]

1. Porque a abordagem modelo entidade-relaciona- mento é útil para a modelagem de bancos de dados? 2. Quais são os elementos que podem constar em um diagrama E-R?