2. Modelo de Objetos

O modelo de objetos do ODMG é o modelo de referência para um banco de dados orientado a objetos. Esse modelo especifica construções que são suportadas por um SGBDOO, tais como: características dos objetos, relacionamentos entre os objetos, e como os objetos podem ser nomeados e identificados.

 Veja as principais características do modelo de objetos ODMG.

• as primitivas do modelo são: objeto, que possui um identificador único (pode ser referenciado), e literal, que não possui identificador (não pode ser referenciado);
• o estado de um objeto é definido pelos valores de suas propriedades (atributos e relacionamentos);
• o comportamento de um objeto é determinado pelo conjunto de operações (apenas as assinaturas das operações);
• tanto objetos quanto literais podem ser de um tipo. Todos os elementos de um determinado tipo possuem um mesmo conjunto de propriedades e comportamento;
• um modelo específico é construído, usando a ODL (independente de linguagem).

O conceito de chaves no modelo de objetos ODMG é apenas uma restrição de unicidade de valor e não tem o papel de OID, nem de referência entre objetos. Portanto, chave em ODMG corresponde a um ou a mais atributos cujos valores identificam uma instância dentro de uma extensão. Essa chave deve ser definida pelo usuário, enquanto o OID é definido pelo sistema.

Abaixo temos um exemplo de uma definição de chave no modelo OO:

class Pessoa (extend pessoas key codigo) {
    attribute short codigo;
};

Existem alguns aspectos que devem ser conhecidos em relação aos objetos:

• O OID de um objeto o diferencia dos demais objetos dentro do BD, sendo gerado pelo SGBD. O OID se mantém imutável durante toda a vida do objeto. A estrutura do identificador não é definida pelo modelo e sim na implementação;
• Dois objetos são considerados iguais quando possuem os mesmos valores para os seus atributos; ² dois objetos são considerados idênticos (isto é, o mesmo objeto) quando se referenciam ao mesmo OID;
• O método same_as() testa se dois objetos possuem o mesmo OID;
• O método copy() faz uma cópia de determinado objeto, o que resulta em dois objetos iguais;
• O método delete() remove o objeto da memória e do banco de dados;
• Os métodos same_as(), copy(), delete(), entre outros, estão definidos na interface Object, que é herdada por qualquer objeto definido pelo usuário;
• O acesso, criação, alteração ou remoção de objetos persistentes devem ser feitos dentro do escopo de uma transação;
• É permitido associar um ou mais nomes a um objeto. Este nome não é armazenado no objeto e sim mantido pelo SGBD, que fornece uma função que mapeia um nome de objeto para o objeto em si. É importante enfatizar que nomes de objetos não devem ser confundidos com chaves ou OIDs;
• Um objeto pode ser persistente (sobrevive à execução de um programa), ou transiente (ao terminar a execução do programa deixa de existir). Os dois podem ser manipulados pelas mesmas operações. Esses dois conceitos são independentes de tipo, pois um mesmo tipo pode possuir algumas instâncias persistentes e outras transientes;
• Um objeto pode ser do tipo atômico (definido pelo usuário), coleção ou estruturado;
• Os elementos de um objeto coleção devem ser todos de um mesmo tipo, podendo ser de um dos tipos de literais ou de um dos tipos de objetos. Os tipos de coleções são:
  • Set<t> (conjunto) - sem ordenação e sem duplicatas;
  • Bag<t> (conjunto) - sem ordenação, mas aceita duplicatas;
  • List<t> (lista) - com ordenação e aceita duplicatas;
  • Array<t>(arranjo) - com ordenação, aceita duplicatas e permite a localização de elementos por posição;
  • Dictionary<t,v> (lista indexada) - com ordenação, aceita duplicatas e permite a localização de elementos por chave associada a cada elemento.
• Vários métodos podem ser aplicados a coleções, tais como - new(), is_empty(), contains_element(), etc.;

Os literais não possuem identificadores. Três tipos de literais são suportados pelo Modelo de Objetos:

• Atômico - é representado por números e caracteres, tais como: long, long long, short, unsigned long, unsigned short, float, double, boolean, octet, char, string, enum (enumeração);
• Coleção - é semelhante a um objeto coleção, porém não possui identificador de objeto. Os literais coleção existentes são: set<t>, bag<t>, list<t>, array<t>, dictionary<t>. Seus elementos podem ser de tipos literais ou tipos objetos.
• Estruturado - é representado por: date, interval, time, timestamp e definidos pelo usuário (structure<>).

A herança pode ser definida de duas formas:

• ISA ou is-a - representa herança de comportamento. Neste caso, apenas interfaces podem ser herdadas, mas tanto classes quanto interfaces podem herdá-las. Pode-se ter herança múltipla, ou seja, é possível herdar de várias interfaces. A forma de representá-la é através de dois pontos (:). Por exemplo:

  interface Funcionario {...};
  interface Professor : Funcionario {...};
  class Professor_Titular : Professor {...};

• Extends - representa herança de estado e comportamento. Neste caso, a herança é dada apenas entre classes, não podendo haver herança múltipla. A forma de representá-la é através da palavra extends. Por exemplo:

  class Funcionario{...};
  class Professor extends Funcionario{...};

A extensão de um tipo (extend) é formada por todas as instâncias deste tipo que existem no banco de dados. Se o projetista desejar, esta extensão é mantida automaticamente pelo SGBDOO. A manutenção do extend envolve a inclusão e remoção de instâncias, bem como a criação e manutenção de índices para estas.

Por exemplo, na classe Pessoa, pode-se declarar o seu extend conforme descrito a seguir:

class Pessoa (extend pessoas){
    ...
};

Os relacionamentos são propriedades definidas entre, no máximo, dois tipos, em que cada tipo participante do relacionamento tem que possuir um OID. O ODMG permite apenas relacionamentos binários, podendo ter cardinalidade um-para-um, um-para-muitos ou muitos-para-muitos.

Um relacionamento é definido explicitamente pela declaração de caminhos que permitem à aplicação usar as conexões lógicas entre os objetos envolvidos no relacionamento. Esses caminhos são declarados em pares, um para cada direção.

A seguir, vemos um exemplo em que um professor ensina um conjunto de disciplinas, e uma disciplina é ensinada por um professor. O relacionamento declarado nas duas direções é apresentado nas duas classes Professor e Disciplina:

class Professor
{...
    relationship set <Disciplina> ensina
    inverse Disciplina :: é_ensinada_por;
...};

class Disciplina
{...
    relationship Professor é_ensinada_por
    inverse Professor :: ensina;
...};

O SGBDOO é responsável por manter a integridade referencial dos relacionamentos. Se um objeto que participa de um relacionamento for removido, então qualquer caminho para aquele objeto deve ser removido também.

As operações são representadas apenas pelas suas assinaturas, que contêm o nome da operação, nome e tipo de cada argumento, tipo de valor retornado e exceções que podem ser sinalizadas pela operação. O nome de uma operação deve ser único apenas dentro de uma definição de tipo.

Assim, tipos diferentes podem ter operações definidas com o mesmo nome. Nestes casos, quando uma operação é chamada, uma operação específica deve ser selecionada para execução. Esta seleção é feita pegando-se o tipo mais específico do objeto fornecido como primeiro argumento da chamada.

Operações podem criar exceções, e estas podem passar os resultados das exceções. Quando uma exceção é criada, as informações sobre a sua causa são passadas para o manipulador de exceções como propriedades de uma exceção.

Conhecendo o modelo orientado a objetos, detalhado acima, podemos passar a estudar, como dito anteriormente, as linguagens de manipulação de BDOs. Quando virmos os exemplos de uso destas linguagens, vários conceitos discutidos aqui ficarão ainda mais claros. Antes de concluir, vamos conhecer os SGBDOOs que estão disponíveis atualmente e que implementam os conceitos que estamos estudando.