PROJETO LÓGICO DE BDOO

Transcrição

1 UNIDADEC PROJETO LÓGICO DE BDOO Quando estudamos Projeto de Banco de Dados Relacional em um módulo anterior, aprendemos a mapear o Modelo ER para o Modelo Relacional e, com isso, transformar um modelo conceitual em um modelo lógico para ser de fato implementado em um SGDB. Nesta unidade iremos estudar o mapeamento daquele mesmo modelo ER agora, porém, para o modelo lógico Orientado a Objetos. Da mesma forma como na referida unidade anterior, veremos passo-a-passo como fazer a conversão entre os modelos. 1. Mapeamento de Entidades Entidades tornam-se classes em um processo de mapeamento direto. Deve-se controlar a unicidade dos atributos identificadores, como o CPF no diagrama ER da Figura 1. Além disso, os métodos relevantes a esta classe podem ser previstos. O diagrama de classes da Figura 1 mostra a classe resultante do mapeamento. 2. Mapeamento de Entidades Fracas Quando uma entidade é fraca em relação a outra, ou seja, o relacionamento entre elas é identificador, temos duas opções para o mapeamento. Na primeira, quando uma entidade fraca relaciona-se apenas com a entidade que a identifica, criamos um atributo composto e multivalorado para a entidade fraca como se pode ver na Figura 2. 15

2 Na segunda opção, quando uma entidade fraca relaciona-se também com outras entidades, devemos criar uma classe para a entidade fraca associando a classe que a identifica como um atributo multivalorado, como se pode ver na Figura Mapeamento de Relacionamentos A seguir, vamos analisar o mapeamento de relacionamentos considerando as diferentes possíveis cardinalidades e a participação obrigatória ou não da entidade no relacionamento. 3.1 Relacionamentos 1:1 Quando um relacionamento é 1:1 e ambas as entidades são obrigatórias no relacionamento, fazemos uma fusão das entidades em uma mesma classe, como mostra a Figura 4. 16

3 No mesmo tipo de relacionamento citado acima, mas quando uma ou ambas as entidades tem participação opcional no relacionamento, criamos uma classe para cada entidade. Além disso, devemos criar um atributo referenciando a outra classe e vice-versa, como mostra a Figura Relacionamentos 1:N Para relacionamentos de cardinalidade 1:N com ambas as entidade com participação obrigatória, devemos criar uma classe para cada entidade e uma referência monovalorada da classe que representa a entidade de cardinalidade N para a classe que representa a entidade de cardinalidade 1, como mostra a Figura 6. 17

4 No caso que discutimos acima, uma vez que existam atributos no relacionamento, devemos colocá-los como um atributo complexo, como mostra a Figura 7. Para relacionamentos de cardinalidade 1:N com ambas as entidades com participação obrigatória, devemos criar uma classe para cada entidade e uma referência monovalorada da classe que representa a entidade de cardinalidade N para a classe que representa a entidade de cardinalidade 1, como mostra a Figura 6. Para relacionamentos de cardinalidade 1:N com alguma entidade com relacionamento opcional, devemos criar um atributo monovalorado que associe a classe cuja entidade tem cardinalidade N com a classe cuja entidade tem cardinalidade 1, como mostra a Figura 8. 18

5 3.3 Relacionamentos M:N Para o caso do relacionamento de muitos-para-muitos, a regra geral é criar um atributo de referência multivalorado em, pelo menos, uma das classes, como mostra a Figura 9. Para o caso de haverem atributos de relacionamento, adota-se o mesmo princípio dos relacionamentos de cardinalidade 1:N, discutidos anteriormente. 4. Mapeamento de Atributos Especiais O Modelo ER trabalha com alguns atributos especiais, dos quais os principais são os Compostos e os Multivalorados. No Modelo OO, o mapeamento destes atributos se dá de forma simples para atributos OO Complexos e Multivalorados, respectivamente. 19

6 5. Mapeamento de Herança A herança (ou generalização/especialização) no Modelo ER pode se dar de quatro formas distintas que serão discutidas e exemplificadas a seguir. 5.1 Com Exclusão Mútua e Totalidade Quando uma hierarquia no Modelo Relacional envolve exclusão mútua, ou seja, uma instância só pode ser especializada em um entidade da hierarquia, e totalidade, ou seja, uma instância deverá ser necessariamente de uma entidade especializada, cria-se uma classe para cada entidade especializada e uma classe abstrata para a classe geral, como mostra a Figura Com Exclusão Mútua e Parcialidade Neste caso, como não temos mais a totalidade, a classe geral não pode ser abstrata, como mostra a Figura

7 5.3 Sem Exclusão Mútua e Totalidade/Parcialidade Quando não há exclusão mútua na hierarquia, independente da totalidade ou parcialidade, é preciso criar uma classe para instâncias que pertencerão a mais de uma entidade especializada e relacioná-las como herança múltipla. As Figuras 12 e 13 ilustram isso, já mostrando também que o mesmo tratamento para a totalidade e parcialidade comentado anteriormente deve ser feito aqui. 6. Mapeamento de Entidade Associativa Para fazermos o mapeamento de Entidades Associativas, seguimos a mesma prática do mapeamento de relacionamentos binários, como mostra a Figura

8 22