CAPTULO 3

MODELAGEM ORIENTADA POR OBJETOS

O objetivo deste captulo apresentar alguns conceitos associados ao desenvolvimento de sistemas de software, baseados no trabalho de Rumbaugh (1994), e a tcnica de modelagem de objetos TMO. Estes conceitos serviro de alicerce para a construo dos demais captulos.

3.1 - Introduo a Modelagem de Dados

A modelagem de dados parte integrante de uma metodologia de desenvolvimento de software. Uma metodologia um processo organizado de produo de software, que utiliza tcnicas predefinidas e notaes convencionais. As etapas que compem este processo correspondem ao ciclo de vida do software. Tradicionalmente, a formulao inicial do problema, a anlise, o projeto, a implementao, os testes e a operao (manuteno e aperfeioamento) compem estas etapas do ciclo de vida.

A modelagem de dados uma das etapas mais importantes do projeto de um SIG, pois a escolha de uma modelo que melhor se ajuste realidade que pretende expressar fator crtico para o sucesso ou fracasso do projeto (Worboys, 95). So apresentados a seguir as definies de autores como base de discusso:

Modelo de dados uma coleo de ferramentas conceituais para descrio dos dados, relacionamento entre os dados, semntica e restries dos dados (Korth e Silberschatz, 1989).

55

Um modelo uma abstrao de alguma coisa, cujo propsito permitir que se conhea essa coisa antes de se constru-la (Rumbaugh, 94).

Sinteticamente, modelar os dados uma maneira de expressar uma realidade atravs de um formalismo que requer abstrao por parte do modelador.

Existem diversas tcnicas para modelagem de dados, cada uma com ferramentas de abstrao diferenciadas determinando a classe de problemas mais adequada ao seu uso.

Um modelo completo de um sistema composto por sub-modelos que expressam vises diferentes da mesma realidade. Essas vises esto divididas em trs (Rumbaugh, 1994):

1) Viso de objetos: descreve estaticamente os objetos que compem o sistema e seus relacionamentos atravs de diagramas de objetos.

2) Viso dinmica: descreve os aspectos do sistema que se modificam com o passar do tempo, especificando o controle do sistema. Os diagramas de estado so usados como ferramenta de descrio.

3) Viso funcional: descreve as transformaes dos valores dos dados de um sistema. Os diagramas de fluxo de dados so usados como ferramenta de trabalho.

Cada viso descreve um aspecto do sistema, mas contm referncias s outras vises. A viso de objetos descreve as estruturas de dados sobre as quais atuam as vises dinmicas e funcional. As operaes da viso de objetos correspondem a eventos nas vises dinmicas, e a funes na viso funcional.

56

A viso funcional descreve as funes chamadas pelas operaes da viso de objetos e pelas aes na viso dinmica.

Por se tratar de abstrao, natural que exista alguma ambigidade quando alguma informao representada por uma viso, pois a meta simplificar a descrio sem sobrecarregar uma viso com construes complexas, de modo a se tornarem um auxlio e no um peso no desenvolvimento do sistema.

Funcional Dinmica Objetos Fig. 3.1 - As trs vises de um sistema.

Esses inter-relacionamentos entre vises inevitvel, compondo um fator delicado na modelagem. Segundo (Rumbaugh, 1994) essas vises so partes ortogonais, que se inter-relacionam, na modelagem de um sistema. A fig. 3.1 ilustra as vises.

As metodologias estruturadas abordam as trs perspectivas. Por ter como princpio a decomposio funcional para modelar sistemas, essas

metodologias do mais nfase viso funcional; em um segundo grau de importncia, vem a viso dinmica e por fim a de objetos. A viso de objetos, para as metodologias estruturadas, restringe-se apenas aos dados. As metodologias orientadas por objetos, da mesma forma que as estruturadas, abordam as trs perspectivas, com nfases diferentes. A viso de objetos a mais enfatizada, depois a viso dinmica e a funcional (Rumbaugh, 1994).

57

A realidade geogrfica modelada pelos SIGs complexa e heterognea. Com o estudo e anlise destas tcnicas de modelagem este trabalho buscar criar um embasamento conceitual para melhor compreender os modelos atuais destes SIGs.

3.2 - Abstrao de Dados

Abstrao uma capacidade de viso de alto nvel que nos permite examinar problemas de forma a selecionar grupos comuns, encontrar generalidades, para melhor compreender o problema e construir modelos. A abstrao deve estar associada a um propsito. Desta forma, pode-se ter vrias abstraes de um mesmo problema para propsitos diferentes. A construo de modelos pela abstrao possui o carter de simplificao da realidade a ser modelada, por isso no deve procurar a verdade absoluta, mas sim a adequao ao propsito (Rumbaugh, 1994).

Para auxiliar na construo destes modelos atravs da abstrao foram desenvolvidas algumas tcnicas e notaes grficas. Uma delas a Tcnica de Modelagem de Objetos - TMO que ser apresentada a seguir.

3.3 - Tcnica de Modelagem de Objetos

A TMO aborda as trs vises definidas anteriormente. A partir do uso da abstrao, constri-se trs modelos: de objetos , dinmico e funcional, alm da relao entre os modelos. Neste trabalho, ser tratado aspectos ligados a banco de dados, logo ser enfatizado a modelagem das estruturas estticas e seus relacionamentos: o modelo de objetos.

Precedendo a notao TMO, ser mostrado alguns conceitos bsicos de modelagem de objetos como : objeto, atributo, operaes e classes.
58

3.3.1 - Objeto, Atributo e Operaes

Define-se um objeto como

um conceito, uma abstrao, algo com limites

ntidos e significado em relao realidade estudada (Rumbaugh, 1994). Os objetos facilitam a compreenso do mundo real e oferecem uma base real para a implementao em um sistema de software. Eles possuem identidade e so distinguveis.

Os exemplos a seguir ilustram a idia de objeto: o homem Mohandas K. Gandhi, o rio Amazonas, a cidade de So Jos dos Campos, a empresa Human Tecnologies Ltda., etc..

Objetos possuem caractersticas prprias que descrevem o seu estado em um determinado momento, e a isso denomina-se atributos ou propriedades de um objeto.

A exemplo a seguir ilustra o conceito de atributo: A cidade de So Jos dos Campos possui uma populao de 450.000 habitantes. Neste caso populao um atributo que descreve o objeto So Jos dos Campos em um determinado momento.

Os objetos so responsveis por atuar sobre os seus atributos e tambm sobre outros objetos, para isto desempenham diversas operaes. Essas operaes descrevem o comportamento do objeto. Os mtodos so a implementao dessas operaes.

A seguir so mostrados dois exemplos de operao: A cidade de So Jos dos Campos incrementou sua populao de 50.000 novos habitantes. Neste caso, a operao de incrementar ser implementada por um mtodo do objeto So Jos dos Campos que adicionar 50.000 no atributo
59

populao. No segundo exemplo: A populao do Brasil de 140.000.000 de habitantes., o objeto Brasil podera se relacionar com todos os objetos que representam os estados brasileiros (objeto So Paulo, objeto Amazonas, etc.) para acumular os respectivos valores dos atributos populao ou poder se relacionar as cidades brasileiras e acumular seus valores. Da mesma forma, esses objetos representantes dos estados brasileiros se relacionam com cada objeto representante da cidade de seu estado (objeto So Jos dos Campos, objeto Ribeiro Preto, etc.) para acumular suas populaes.

3.3.2 - Classes

Uma classe de objetos descreve um grupo de objetos com propriedades semelhantes (atributos), o mesmo comportamento (operaes) e

conseqentemente a mesma semntica (Rumbaugh, 1994). No exemplo anterior, j tocamos nesta definio, quando expressamos objetos que

representam... ou seja, objetos de uma mesma classe, por exemplo: estados brasileiros e cidades.

Os objetos de uma classe compartilham um objetivo semntico comum, alm dos requisitos de atributos e comportamento. Dessa maneira, embora um celeiro e um cavalo tenham ambos um preo e uma idade, provavelmente pertencem a classes diferentes. Se o celeiro e o cavalo fossem vistos apenas como bens contbeis, provavelmente pertenceriam mesma classe. Se o desenvolvedor levar em considerao que um celeiro deve ser pintado, e um cavalo, alimentado, eles seriam modelados como classes distintas. A interpretao da semntica depende do propsito de cada aplicao, sendo uma questo de critrio.

60

Cada metodologia de modelagem utiliza uma notao grfica prpria. Esta discusso utiliza a notao de Rumbaugh (1994). A Figura 3.2 indica esta notao para o diagrama de objetos.

Cidade

Classe

Cidade Nome : String Populao : Integer Centroid : Integer Incrementar_Populao

Atributos Operaes

(Cidade) Nome=So Jos dos Campos Populao=450.000 Centroid=156

Objetos da Classe Cidade

(Cidade) Nome=So Paulo Populao=2.200.000 Centrid=248

Fig. 3.2 - Notao Grfica TMO.

Para completar a apresentao da modelagem orientada por objetos, torna-se necessrio outros conceitos chaves da TMO que sero discutidos a seguir.

3.3.3 - Associao, Ligao e Multiplicidade

A associao descreve um conjunto de ligao com estrutura e semntica comuns. Exemplo: Uma cidade pertence a um estado. Assim como as classes, as associaes podem possuir atributos provenientes da semntica de cada ligao.

Ligao a conexo fsica ou conceitual entre instncias de objetos. Exemplo: A cidade de Ribeiro Preto pertence ao estado de So Paulo. Uma ligao uma instncia de uma associao.

A multiplicidade especifica quantas instncias de uma classe relacionam-se a uma nica instncia de uma classe associada, restringindo a quantidade de
61

objetos relacionados. A multiplicidade pode ser expressa, de maneira geral, por um ou muitos. No entanto, possvel utilizar intervalos bem definidos. A simbologia adotada representa por uma bola cheia na extremidade do relacionamento a multiplicidade muitos significando zero ou mais, e para bola vazia a multiplicidade zero ou um. Na Figura 3.3 so ilustradas o emprego dessas notaes.

um para um ou zero Microcomputador Utilizado por Usurio

um para muitos ou zero Hotel Usufrudo por Usurio

muitos ou zero para muitos ou zero Disciplina Cursar Aluno

intervalos definidos Linha

+2

Cruza Ponto

Fig. 3.3 - Exemplos de associao e multiplicidade.

3.3.4 - Atributo de Ligao

Assim como um atributo uma propriedade dos objetos de uma classe, um atributo de ligao uma propriedade das ligaes de uma associao. Na fig. 3.4, avaliao um exemplo de propriedade de associao que do tipo muitos ou zero para muitos ou zero. Desta forma, dado um determinado aluno, este dever ter muitas avaliaes dependendo de cada disciplina que

62

cursar. No modo inverso, dado uma disciplina, esta avaliar os diversos alunos que a cursam.

Disciplina

Cursar

Aluno

Avaliao Fig. 3.4 - Exemplos de atributo de ligao.

3.3.5 - Agregao

A agregao um tipo de associao forte onde um objeto agregado contitudo de componentes. A agregao representada pelo relacionamento parte-todo ou uma-parte-de no qual os objetos que representam os componentes de alguma coisa so associados a um objeto que representa a estrutura inteira. Em termos semnticos, o objeto agregado um objeto estendido tratado como uma unidade em muitas operaes, embora fisicamente ele seja composto por objetos menores.

Uma agregao representada graficamente pelo smbolo de losango. O exemplo da fig. 3.5 ilustra a idia exposta. Projeto de Casa

Estrutural

Hidrulico

Eltrico

Arquitetura

Exterior

Interior

Paisagismo

Fig. 3.5 - Conceito de agregao aplicado a um exemplo de projeto de casa.

63

3.3.6 - Generalizao, Especializao e Herana

Esses termos referem-se a aspectos da mesma idia e so freqentemente usados de forma intercambivel. Utilizamos generalizao para nos referirmos ao relacionamento entre classes, enquanto a herana refere-se ao mecanismo de compartilhamento de atributos e operaes utilizando o relacionamento de generalizao. Generalizao e especializao so dois diferentes pontos de vista do mesmo relacionamento, vistos a partir da superclasse ou das subclasses. Generalizao deriva do fato de que a superclasse generaliza as subclasses. Especializao refere-se ao fato de que as subclasses refinam ou especializam a superclasse. A Figura 3.6 ilustra esses conceitos.

Estado Id_Estado: String Nome: String Nro_Cidade: Integer Area: Float Calcula_Populao():Integer
Estar/Possui

Cidade Nome : String Populao : Integer Centroid : Integer Incrementar (Valor):Integer

Tipo da Cidade

Agregao onde Estados so compostos por muitas Cidades. Um estado possui muitas cidade e uma cidade est em um estado. Especializao da classe Cidade em subclasses Capital e Municpio. As subclasses herdam os atributos e operao da superclasse Cidade.

Capital Verba_Estadual: Float Meta_Educao: String Meta_Saude: String

Municpios %_Verba_Estadual: Foat Prioridades: String

Fig. 3.6 - Exemplo de Especializao e Herana.

64

A herana mltipla um conceito que consideramos relevante para o trabalho, uma vez que aumenta a capacidade de especificao das classes. A herana mltipla permite que uma classe possua mais de uma superclasse e herde as caractersticas de todos os seus ancestrais. Isto possibilita a mesclagem de informaes de duas ou mais classes. A desvantagem desta prtica est na perda de simplicidade conceitual e de implementao. A Figura 3.7 expressa a idia.

Por esta possibilidade de modelagem, uma caracterstica proveniente da mesma classe ancestral encontrada em mais de um caminho herdada apenas uma vez. Os conflitos de definies paralelas criam ambigidades que precisam ser resolvidas seja pelas implementaes ou por ajustes no modelo, que impeam a herana mltipla.

No exemplo da Figura 3.7 uma possvel soluo para se evitar a herana mltipla, na modelagem, elevar a classe Veculo Anfbio para o mesmo nvel de Veculo Terrestre e Veculo Aqutico, tornando-se uma outra especializao de Veculo. Desta forma o novo modelo seria como apresentado pela Figura 3.8.

Em razo deste ajuste deve-se adicionar explicitamente classe Veculo Anfbio, em forma de novos atributos, as caractersticas que antes eram herdadas de ambos os ancestrais e que tambm eram motivo de conflitos.

Outras solues so possveis no nvel de implementao, no sentido de fazer uso de mecanismos oferecidos pela linguagem escolhida. Esta abordagem no ser detalhada neste trabalho por entendermos tratar-se de um nvel mais baixo de detalhes, fora do nvel conceitual o qual pretendemos seguir. Uma boa explicao sobre este assunto encontra-se em (Rumbaugh, 1994).

65

Veculo

Veculo Terrestre

Veculo Aqutico

Carro

Veculo Anfbio

Barco

Fig. 3.7 - Exemplo de herana mltipla: a classe Veculo Anfbio possui duas superclasses.

Veculo

Veculo Terrestre

Veculo Aqutico

Veculo Anfbio

Carro

Barco

Fig. 3.8 - Novo modelo ajustado para evitar a herana mltipla.

3.3.7 - Polimorfismo

Um outro conceito utilizado na abordagem orientada por objetos denomina-se polimorfismo. Trata-se da possibilidade que uma mesma operao possui de atuar de modos diferentes em classes diferentes. Isto possvel quando uma operao esteja declarada em classes diferentes, porm com o mesmo nome, executando processamentos diferentes para atender os requisitos semnticos de sua classe. Por exemplo, uma operao de mover para classe Janela executa um processo diferente do que a operao mover para classe Pea-

66

de-Xadrez. Enquanto uma operao modifica a posio de uma janela a outra movimenta uma pea de xadrez.

3.4 - Persistncia de Objetos em Ambientes Relacionais

Este tpico visa completar os tpicos antecessores sobre a TMO apresentando algumas tcnica de mapeamento das classes de dados e suas associaes em tabelas em um banco de dados relacional. Denominamos a isto persistncia de dados em ambientes relacionais.

A discusso a seguir baseada no texto de Rumbaugh (1994).

3.4.1 - Mapeamento de Classes

De uma maneira geral cada classe persistente d origem a uma tabela, onde cada atributo da classe corresponde uma coluna, e os valores dos atributos para cada objeto na classe correspondem a uma linha.

No entanto, deve-se, neste mapeamento, ter o cuidado de criar a coluna de identificao, ou seja a chave primria de cada linha ou registro armazenado. Em um programa C++, quando ocorre a criao de um novo objeto, gerado automaticamente o identificador deste objeto. J em um banco de dados

relacional cabe ao desenvolvedor a responsabilidade desta criao. Quando ocorre o mapeamento, recomenda-se armazenar no banco de dados relacional o identificador do objeto como chave primria, ou qualquer outro atributo do objeto que possa identific-lo de forma nica.

A Figura 3.9

a seguir mostra um exemplo de converso de uma classe

persistente em uma tabela. Nesse exemplo a classe Municipio possui os atributos Nome e Populacao_98. Quando ela convertida para a tabela
67

Municipio, acrescenta-se a coluna Id-Municipio, pois a classe no possui um atributo ou um conjunto de atributos que possa ser considerado chave. Essa estratgia compatvel com as linguagens baseadas em objetos, onde os objetos tm identidades independentes das suas propriedades.

Municipio Nome Populao98

TABELA MUNICIPIO Id- Municipio 123 100 131 171 ... Nome So Jos dos Campos So Paulo So Jos do Rio Preto Guaruj ... Populao98 450.000 12.000.000 480.000 204.000 ...

Fig. 3.9 Mapeamento de Classes em Tabelas.

3.4.2 Mapeamento de Associaes Muitos para Muitos

Cada associao muitos para muitos entre objetos persistentes deve ser mapeada em uma nova tabela. As chaves das tabelas das classes associadas transformam-se em atributos dessa nova tabela. Um exemplo do mapeamento de associao muitos para muitos dado na fig. 3.10.

Neste exemplo foi utilizado a propriedade Nro_Lei da classe Leis para ser a chave primria ou identificador nico da tabela gerada pelo mapeamento desta classe no banco de dados relacional.

68

Municipios Nome Area_km2 Pop98

Leis Nro_Lei Data Ambito

TABELA MUNICIPIOS
Id 121 233 321 600 ... Nome So Carlos-SP Londrina-PR Santa Maria-RS Cuiaba-MS ... Area_km2 1.800 2.360 1.640 2.660 ... Pop98 320.000 120.000 480.000 430.000 ...

TABELA LEIS
Nro_Lei 122.444.78 145.883.33 111.211.44 223.444.76 ... Data 10/09/97 03/02/98 08/12/97 10/04/98 ... Ambito Estadual Federal Federal Estadual ...

TABELA MUNICIPIOS_LEIS
Id 121 121 233 233 233 ... Nro_Lei 122.444.78 145.883.33 223.444.76 145.883.33 111.211.44 ...

Fig. 3.10 Mapeamento de Associaes muitos para muitos para Tabelas.

3.4.3 - Mapeamento de Associaes Um para Muitos

Existem duas maneiras de se mapear associaes um para muitos entre objetos persistentes para o modelo relacional. So elas :

69

 Caso 1. No primeiro caso transpe-se a chave primria da tabela correspondente classe do lado Muitos, para a tabela correspondente classe do lado 1. (Por transpor deve-se entender criar uma coluna com a chave da tabela correspondente uma determinada classe, em outra tabela). Um exemplo dado na Figura 3.11 a seguir.

Quadras Id_Quadra Area Perimetro

Lotes Id_Lote Area Proprietario

TABELA QUADRAS Id_Quadra A-10 B-08 C-22 ... Area_m2 4.580 5.200 4.220 ... Perimetro 383 652 322 ...

TABELA LOTES Id_Lote 10-01 10-05 08-03 08-07 22-01 ... Area 1.200 1.800 900 800 2.200 ... Proprietrio Antonio C. M. Paulo M. Luiza E. Luis I. L. S. Fernando H. C. ... Id_Quadra A-10 A-10 B-08 B-08 C_22 ...

Fig. 3.11 Mapeamento de associaes um para muitos do caso 1. Caso 2. No segundo caso cria-se uma tabela correspondente associao, transpondo para ela as chaves das duas classes. Um exemplo dado na Figura 3.12 a seguir (foram usadas as classes Quadras e Lotes do exemplo anterior).

70

TABELA QUADRAS Id_Quadra A-10 B-08 C-22 ... Area_m2 4.580 5.200 4.220 ... Perimetro 383 652 322 ...

TABELA LOTES Id_Lote 10-01 10-05 08-03 08-07 22-01 ... Area 1.200 1.800 900 800 2.200 ... Proprietrio Antonio C. M. Paulo M. Luiza E. Luis I. L. S. Fernando H. C. ...

TABELA QUADRAS_LOTES Id_Quadra A-10 A-10 B-08 B-08 C_22 ... Id_Lote 10-01 10-05 08-03 08-07 22-01 ...

Fig. 3.12 - Mapeamento de associaes muitos para um do caso 2.

Porm quando deve-se usar o Caso 1, e quando deve-se usar o Caso 2 ? A seguir so apresentadas algumas vantagens e desvantagens de cada abordagem. Elas devem ser analisadas de acordo com os requisitos estabelecidos pelo sistema que est sendo desenvolvido (Setzer,1986).

A Figura 3.12 tem uma tabela a menos. Isso significa menor espao ocupado pelos arquivos resultantes e, muito mais importante, maior eficincia (rapidez) no processamento de operaes que envolvam a associao. As transaes so tambm expressas de maneira mais simples. Portanto, se eficncia for um requisito do sistema que est sendo desenvolvido, deve-se optar por essa abordagem.

71

A Figura 3.12 apresenta uma soluo com maior independncia de dados : a tabela Lotes contm exclusivamente seus dados prprios, ao contrrio da Figura 3.11 em que recebe a chave de Quadras.

Uma vantagem da Figura 3.12 que uma mudana estrutural do tipo da associao, passando de muitos para um para muitos para muitos, no requer nenhuma alterao estrutural nas tabelas, ao contrrio da Figura 3.12.

3.4.4 - Mapeamento de Associaes Um para Um

Para se fazer o mapeamento das associaes um para um entre objetos persistentes deve-se criar uma tabela para cada classe, e transpor a chave de uma tabela para a outra. O sentido da transposio depende das formas de acesso para ganho de eficincia.

Os exemplos da Figura 3.13 e da Figura 3.14 a seguir mostram as duas maneiras de se mapear as associaes um para um em tabelas. O exemplo da Fig. 3.13 melhor pois como todas as ocorrncias de IPTU possui um lote associado, logo a transposio da chave de lotes para a tabela de IPTU no existir ocorrncia de valores vazios. J o contrrio, como mostrado pela Figura 3.14, nem todas as ocorrncia de lotes possuem um IPTU associado. Os lotes da prefeitura so isentos de IPTU. Neste ltimo caso, na transposio da chave de IPTU para lotes, existir valores vazios nesta chave transposta para as ocorrncias de lotes pertencentes a prefeitura por exemplo. So eles : Caso 1. Transpe-se a chave de Lotes para IPTU, como mostra a Figura 3.13 a seguir.

72

Lotes Id_Lote Area Proprietario

IPTU Nro_IPTU Valor Vencimento Situao

TABELA LOTES
Id_Lote 10-01 10-05 08-03 08-07 22-01 22-02 25-01 ... Area 1.200 1.800 900 800 2.200 3.000 1.450 ... Proprietrio Antonio C. M. Paulo M. Luiza E. Luis I. L. S. Fernando H. C. Prefeitura Prefeitura ...

TABELA IPTU
Nro_IPTU 0345/96 0337/97 0224/95 0112/97 0332/92 ... Valor 1.200,00 1.800,00 900,00 800,00 2.200,00 ... Vencimento 12/03/98 12/03/98 12/03/98 12/03/98 12/03/98 ... Situacao NOT_OK NOT_OK OK OK OK ... Id_Lote 10-01 10-05 08-03 08-07 22-01 ...

Fig. 3.13 Primeira alternativa para mapear associaes um para um em tabelas - caso 1. Caso 2. Transpe-se a chave de IPTU para LOTES, como mostra a Figura 3.14 a seguir.

3.4.5 - Mapeamento de Generalizaes

Existem trs abordagens principais para o mapeamento de generalizaes de classes persistentes em tabelas. Sero dados exemplos das trs abordagens tomando-se como base a Figura 3.15. So elas :

73

TABELA LOTES
Id_Lote 10-01 10-05 08-03 08-07 22-01 22-02 25-01 ... Area 1.200 1.800 900 800 2.200 3.000 1.450 ... Proprietrio Antonio C. M. Paulo M. Luiza E. Luis I. L. S. Fernando H. C. Prefeitura Prefeitura ... Nro_IPTU 0345/96 0337/97 0224/95 0112/97 0332/92 Null Null ...

TABELA IPTU
Nro_IPTU 0345/96 0337/97 0224/95 0112/97 0332/92 ... Valor 1.200,00 1.800,00 900,00 800,00 2.200,00 ... Vencimento 12/03/98 12/03/98 12/03/98 12/03/98 12/03/98 ... Situacao NOT_OK NOT_OK OK OK OK ...

Fig. 3.14 - Segunda Alternativa para Mapear associaes um para um em Tabelas - Caso 2. Caso 1. A classe de generalizao e as classes de especializao so mapeadas cada uma para uma tabela. A chave da tabela da classe de generalizao reproduzida nas tabelas das classes de especializao. Um exemplo dado na Figura 3.16.

Nesse exemplo, a identidade de um objeto atravs de uma generalizao preservada com a utilizao de um ID compartilhado. Desse modo, uma dada ocorrncia de n ter uma linha na tabela Pontos, e outra linha na tabela Nos, e em ambas as ocorrncias permanecer o mesmo valor para Id_Ponto.

A coluna Tipo acrescentada tabela Pontos para que se possa saber que tabela pesquisar, se a tabela de nos ou se a tabela de vertices.

A navegao nas tabelas do exemplo anterior poderia ser feita da seguinte forma :

74

Ponto Coordenada_X Coordenada_Y

N Nro_de_Arcos

Vrtice Posio

Fig. 3.15 - Exemplo de generalizao-especializao: ponto, n e vrtice.

TABELA PONTOS Id_Ponto 0001 0002 0003 0004 ... Coordenada_X 3445 7772 8290 0023 ... Coordenada_Y 23322 27765 20900 00090 ... TIPO NO NO VERTICE VERTCE ...

TABELA NOS Id_Ponto 0001 0002 ... Nro_de_arcos 4 5 ...

TABELA VERTICES Id_ponto 0003 0004 ... Posicao 2 1 ...

Fig. 3.16 - Mapeamento de generalizao-especializao em tabelas de generalizao e em tabelas de especializao - caso 1.

75

1) Dado o identificador de um ponto, descobre-se a linha da tabela Pontos correspondente a ele. 2) Recupera-se o tipo do ponto para essa linha da tabela. 3) Vai-se para a tabela da classe de especializao indicada pelo tipo do ponto e encontra-se a linha com o mesmo identificador da linha da tabela pontos. Caso 2. Cada classe de especializao mapeada para uma tabela. A classe de generalizao eliminada, e seus atributos so reproduzidos em cada tabela de especializao. Um exemplo dado na Figura 3.17 a seguir.

TABELA NOS Id_Ponto 0001 0002 ... Coordenada_X 3445 7772 ... Coordenada_Y 23322 27765 ... Nro_de_arcos 4 5 ...

TABELA VERTICES Id_ponto 0003 0004 ... Coordenada_X 8290 0023 ... Coordenada_Y 20900 00090 ... Posicao 2 1 ...

Fig. 3.17 - Mapeamento de generalizao-especializao em tabelas de especializao - Caso 2. Caso 3.

A classe de generalizao mapeada para uma tabela

juntamente com os atributos das classes de especializao. Um exemplo dado na Figura 3.18.

76

TABELA PONTOS
Id_Ponto 0001 0002 0003 0004 ... Coordenada_X 3445 7772 8290 0023 ... Coordenada_Y 23322 27765 20900 00090 ... Nro_Arco 4 5 Null Null ... Posicao Null Null 2 1 ...

Fig. 3.18 - Mapeamento de generalizao-especializao em tabela de generalizao.

Porm em que situao deve-se usar cada caso ? Abaixo seguem algumas vantagens e desvantagens de cada abordagem. Elas devem ser analisadas de acordo com os requisitos estabelecidos pelo sistema que est sendo desenvolvido (Rumbaugh,1994) :

1) A Figura 3.16 apresenta a abordagem padro, que a mais correta e estensiva logicamente. Contudo ela envolve muitas tabelas, e a navegao das classes de generalizao para as classes de especializao pode ser lenta.

2) A Figura 3.17 apresenta uma abordagem que pode ser utilizada se as classes de especializao possurem muitos atributos, se a classe de generalizao tiver poucos atributos, e se a aplicao souber qual classe deve ser pesquisada.

3) A Figura 3.18 apresenta a abordagem menos satisfatria, porm ela pode ser til se existirem somente duas ou trs classes de generalizao com poucos atributos.

77

4) As abordagens das Figura 3.17 e Figura 3.18 so abordagens alternativas motivadas pelo desejo de eliminar a navegao da classe de generalizao para as classes de especializao, melhorando o

desempenho de consultas; contudo, esta melhora de desempenho incorre em outros problemas, tal como armazenamento de valores nulos.

78