Gerar relacionamentos

No relacionamento entre as classes Gerente-Cidade e Cliente-Cidade, os atributos representando a cidade estão em cada uma das classes - Gerente e Cliente - através de um tipo de objeto denominado estrutura, que é composto de outros objetos, conforme a declaração no trecho ODL da figura 44. Considerando que os atributos são comuns para as classes Gerente e Cliente, estes são gerados

na superclasse Pessoa, para que as classes especializadas herdem tais características. struct Cidade { string NomeCidade; string UFCidade; string RegiaoCidade; }

class Pessoa (extent Pessoas) {

attribute string NomePessoa; attribute string ChavePessoa;

attribute struct Cidade CidadePessoa; attribute string EnderecoPessoa; }

Figura 44 - Script do tipo de objeto estrutura Cidade.

A declaração ODL enum pode assumir valores específicos e enumerados na classe Tempo, que tem o atributo NomeMes com os valores respectivamente relacionados para cada um dos meses do ano, conforme representa a figura 45.

class Tempo (extent DataPed) {

...

enum NomeMes {JANEIRO, FEVEREIRO, MARÇO, ABRIL, MAIO, JUNHO, JULHO, AGOSTO, SETEMBRO, OUTUBRO, NOVEMBRO, DEZEMBRO};

... }

Figura 45 - Script da declaração enum na classe Tempo.

Em ODL, a definição de um relacionamento origem-destino inclui a geração de um tipo destino, a cardinalidade do lado destino e informações sobre o relacionamento inverso, do lado origem.

O relacionamento de agregação não é representado diretamente em ODL, portanto, deve ser transformado em um relacionamento de associação.

No exemplo da figura 46, o tipo de coleção literal set<> indica que cada gerente pode estar em uma ou mais ocorrências na classe PosicaoConta, definido em ODL:

class Gerente extends Pessoa {

...

Relationship set<PosicaoConta> ContaGerente inverse Gerente::posicao; ...

Figura 46 - Script do tipo de coleção literal set<>.

No modelo proposto, observa-se que cada cliente pode ter várias contas, bem como cada conta pode conter vários produtos, sem a definição de um número exato de ocorrências. Portanto, para a solução deste relacionamento, o modelo apresentado inclui uma tabela bridge entre as tabelas Conta-Cliente, como ilustrado na figura 47.

istered Trial Version EA 5.1 Unregistered Trial Version EA 5.1 Unregistered Trial Versio istered Trial Version EA 5.1 Unregistered Trial Version EA 5.1 Unregistered Trial Versio istered Trial Version EA 5.1 Unregistered Trial Version EA 5.1 Unregistered Trial Versio istered Trial Version EA 5.1 Unregistered Trial Version EA 5.1 Unregistered Trial Versio istered Trial Version EA 5.1 Unregistered Trial Version EA 5.1 Unregistered Trial Versio istered Trial Version EA 5.1 Unregistered Trial Version EA 5.1 Unregistered Trial Versio istered Trial Version EA 5.1 Unregistered Trial Version EA 5.1 Unregistered Trial Versio istered Trial Version EA 5.1 Unregistered Trial Version EA 5.1 Unregistered Trial Versio istered Trial Version EA 5.1 Unregistered Trial Version EA 5.1 Unregistered Trial Versio

Cliente

- CPFCliente: int - DataNascimento: char

Conta

- {OID} OIDConta: int - DataAbertura: char - DescricaoCategoria: char - DescricaoTipoConta: char - NumeroConta: char

Pessoa

- {OID} OIDPessoa: int - {D} NomePessoa: char - ChavePessoa: int - CidadePessoa: char - EnderecoPessoa: char - RegiaoPessoa: char - UFPessoa: char ContaCliente - Titular: boolean

Figura 47 - Tabela bridge entre as classes Cliente e Conta.

Em ODL a geração da classe ContaCliente é representada na figura 48. Nas classes Conta e Cliente são gerados os relacionamentos correspondentes, em ODL, conforme mostra a figura 49.

Ao término da quarta etapa da metodologia, a figura 50 apresenta o resumo das tarefas desenvolvidas nesta fase, quando o modelo multidimensional representado pelos diagramas de classe e estrutura composta são mapeados para o padrão ODMG, utilizando a ODL..

class ContaCliente (extent CtaCli) {

attribute boolean Titular;

relationship set<Conta> ItemCta inverse Conta::contas; relationship set<Cliente> ItemCli inverse Cliente::clientes; }

Figura 48 - Script da classe bridge ContaCliente.

class Conta (extent Contas) {

attribute date DataAbertura; attribute string DescricaoCategoria; attribute string DescricaoTipoConta; attribute string NumeroConta;

relationship set< ContaCliente> contas inverse ContaCliente:: ItemCta; }

class Cliente extends Pessoa {

attribute long CPFCliente; attribute date DataNascimento;

relationship set<ContaCliente> clientes inverse ContaCliente::ItemCli; }

Figura 49 - Script das classes Conta e Cliente dos relacionamentos com a classe bridge ContaCliente.

Implantação de modelos multidimensionais mapeados em BDOO

Etapa 4

• Classes:

o script de criação das classes dimensão Tempo, Agencia, StatusConta, UnidadeDomiciliar e Conta;

o script de criação da superclasse Pessoa, com as propriedades comuns de Cliente e Gerente;

o script de criação das classes Cliente e Gerente, herdando as propriedades da superclasse Pessoa;

o script de criação da classe PosicaoConta como uma classe Fatos;

o script de criação das classes associativas ContaCliente e ContaProduto;

• Relacionamentos:

o transposição do relacionamento de especialização / generalização para o relacionamento ISA, definido na superclasse Pessoa;

o transposição do relacionamento de herança de estado e

comportamento para o relacionamento EXTENDS para as classe Cliente e Gerente, especializadas da superclasse Pessoa;

o transformação dos relacionamentos de agregação entre as classes Dimensão e Fatos para relacionamentos de associação, definindo os relacionamentos e seus inversos;

o utilização da declaração enum para definir restrições de valores para os atributos das classes;

o transformação do relacionamento n:n entre as classes Conta-Cliente para relacionamento de associação, gerando a classe bridge ContaCliente, definindo os relacionamentos e seus inversos;

o transformação do relacionamento da estrutura composta entre as classes Conta e Produto na classe bridge ContaProduto, definindo os relacionamentos e seus inversos;

• Identificadores: não são representados pela ODL. • Descritores: não são representados pela ODL. • Atributos:

o transformação dos atributos complexos em atributos estruturados, através da utilização da estrutura Cidade, utilizada como atributo nas classes UnidadeDomiciliar, Agencia e na superclasse Pessoa;

o definição do tipo de dados dos atributos das classes, segundo o padrão ODMG.

Figura 50 - Resumo da etapa 4 da metodologia.

6.6 Etapa 5: Implementar o modelo

Para a aplicação da proposta de modelagem multidimensional segundo o paradigma da orientação a objetos e seu respectivo mapeamento, gerando a persistência de objetos, foi utilizado o banco de dados pós-relacional Caché – Intersystems.

A seção apresenta a utilização do banco de dados adotado para a aplicação do trabalho, apresentando suas características e funcionalidades. Para cada especificação do modelo multidimensional é apresentada a equivalência no banco de dados Caché, observando-se ainda, a padronização especificada pela ODL.

O mapeamento considera as classes do modelo multidimensional, seus relacionamentos e tipo de dados, observando as soluções propostas nas seções

anteriores. As ferramentas associadas ao banco de dados são exploradas no contexto de verificar as facilidades para a implementação do modelo definido.

O banco de dados deve fornecer as características apresentadas nos capítulos anteriores, considerando particularmente os conceitos do paradigma da orientação a objetos.

6.6.1 Banco de Dados Orientado a Objetos Caché