BANCO DE DADOS ORIENTADO A OBJETOS

Transcrição

1 UNIDADEB BANCO DE DADOS ORIENTADO A OBJETOS 1. Introdução Um Banco de Dados Orientado a Objetos (BDOO) é um banco de dados em que, no modelo lógico, as informações são armazenadas na forma de objetos, e só podem ser manipuladas através de métodos definidos pela classe instanciada por tais objetos. O conceito de BDOO é essencialmente o mesmo das Linguagens Orientadas a Objetos, havendo uma pequena diferença apenas: o armazenamento persistente de dados. A mais forte justificativa para o desenvolvimento e adoção do modelo orientado a objetos para os BDs é que aplicações são construídas cada vez mais em linguagens orientadas a objetos (java, C++, C#) e a persistência destes objetos está associada a um mapeamento entre o modelo OO da linguagem e o modelo Relacional do BD. Este mapeamento não é direto e pode acarretar falhas na aplicação se não for tratado com o devido cuidado. Em 2004, os bancos de dados orientados a objeto tiveram um crescimento devido ao surgimento de SGBDOOs livres. Contudo, os BDOOs não se popularizaram e não são amplamente adotados na indústria e vêm sendo propostos como alternativa para os sistemas relacionais e visam a aplicações ditas avançadas, nas quais o enfoque central está na especificação de objetos complexos. Esta abordagem é fortemente influenciada por linguagens de programação orientadas a objetos e que podem ser entendidas como uma forma de adicionar funcionalidades de SGBDs em um ambiente de linguagens de programação. O grupo Object Database Management Systems (ODMG) tem desenvolvido um padrão para o modelo de dados (Object Data Model - ODM) e especificado uma linguagem de consulta (Object Query Language - OQL), que são equivalentes ao padrão SQL para bancos de dados relacionais. Na próxima unidade estudaremos estas linguagens. 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). 10

2 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 (extent 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: a) Set<t> (conjunto) - sem ordenação e sem duplicatas; b) Bag<t> (conjunto) - sem ordenação, mas aceita duplicatas; c) List<t> (lista) - com ordenação e aceita duplicatas; d) Array<t>(arranjo) - com ordenação, aceita duplicatas e permite a localização de elementos por posição; e) 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<>). 11

3 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 extent 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 extent conforme descrito a seguir: class Pessoa (extent 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; 12

4 ...}; 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. 3. Banco de Dados OO no mercado Existem vários bancos de dados orientados a objeto, discutir cada um deles é essencial para a tomada de decisão. É importante saber qual modelo é mais apropriado para o uso da sua aplicação. A seguir estão alguns exemplos: CACHÉ: trabalha com as seguintes linguagens: Java,.Net, C++, XML e outras. É um banco de dados comercial; VERSANT: trabalha com as seguintes linguagens: Java e C++. É bastante utilizado nos sistemas telecomunicações, redes de transporte, áreas médicas e financeiras. É um banco de dados comercial; DB4Objects: Trabalha com as seguintes linguagens: Java e.net. Sua linguagem de Consulta é a Object Query Language (OQL) e é um banco de dados distribuído em duas licenças, a GPL (licença pública Geral) e uma licença comercial. JASMINE: Possui alta conectividade com Web, suporte à linguagem Java. Pode-se ainda desenvolver aplicações em Visual Basic usando Active/X, em HTML (HyperText Markup Language) usando as ferramentas de conectividade para Web disponíveis no Jasmine, em C e C++ usando APIs e em Java usando interfaces de middleware embutidas no Jasmine. É um banco de dados comercial. MATISSE: Trabalha com as seguintes linguagens: Java, C#, C++, VB, Delphi, Perl, PHP, Eiffel, SmallTalk. É um banco de dados comercial. 13

5 Objectivity/DB: trabalha com as seguintes linguagens: C#; C++; Java; Python, Smalltalk; SQL++ (SQL com objeto - extensões orientadas) e XML (para a importação e a exportação somente). É um banco de dados comercial. Ozone: trabalha com as seguintes linguagens: Java e XML. É um banco de dados livre. 14