MODELO RELACIONAL-OBJETO
Visão geral da SQL e suas características objeto-relacionais. Tipos de dados, array e multiconjunto.
Caracteristicas objeto-relacionais do Oracle.
Evolução e tendências atuais da tecnologia de banco de dados.
Bancos de Dados Relacionais-Objeto
Com o surgimento do modelo orientado a objetos, nos anos 90 acreditava-se que os bancos relacionais, que dominavam o mercado, fossem gradativamente substituídos por bancos de dados orientados a objetos. Entretanto, apesar das comprovadas vantagens apresentadas por modelos de dados orientados a objetos na modelagem de aplicações, poucos foram os gerenciadores de bancos de dados construídos especificamente conforme este paradigma. O mercado hoje ainda continua dominado por bancos de dados relacionais, devido à sua tecnologia comprovada e especializada. Os bancos relacionais são o resultado de muitos anos de pesquisas, que resultaram em bancos com alto desempenho, tanto no gerenciamento de transações como na eficiência para resolução de consultas.
Entretanto, bancos relacionais não se mostraram adequados para armazenar e manipular adequadamente dados de aplicações avançadas, cada vez mais comuns nos dias de hoje, e que apresentam um número muito grande de informações associadas. Exemplos destas aplicações são:
• Mapas de sistemas de informação geográfica e espacial;
• Imagens em sistemas multimídia;
• Dados biológicos;
• Projetos arquitetônicos em Projetos Assistidos por Computador (CAD);
• Séries de dados históricos para transações comerciais.
As vantagens do modelo orientado a objetos nunca foram questionadas. Muita aplicações seriam grandemente beneficiadas caso uma modelagem, feita através de um modelo orientado a objetos, pudesse ser implementada diretamente em bancos de dados relacionais. Para permitir a utilização
da orientação a objetos, os fabricantes destes bancos passaram a incorporar alguns dos seus conceitos aos bancos relacionais, dando origem ao que é denominado de Bancos de Dados Relacionais-Objeto (BDROs). Nestes, apesar do modelo de implementação ser relacional, são disponibilizadas algumas facilidades para sua utilização como se fossem bancos orientados a objetos. Tem-se, assim, um modelo semanticamente rico para a modelagem das aplicações, e, simultaneamente, eficiência no gerenciamento de dados.
BDRO constituem uma tecnologia relativamente nova, incorporada a alguns bancos de dados comerciais tais como Oracle, DB2 e PostgreSQL.
Modelo de Dados Relacional Objeto
Um banco de dados relacional-objeto se baseia em um modelo de dados relacional-objeto. O modelo de dados relacional-objeto é, na realidade, uma extensão do modelo relacional tradicional, adicionando a este características de orientação a objetos. Deste modo, toda a tecnologia desenvolvida para os modelos relacionais, tais como suporte à linguagem de consulta SQL, gerência de transações, processamento e otimização de consultas, está disponível nestes modelos.
Mesmo que para um usuário o modelo de dados relacional-objeto tenha todas as características de um modelo orientado a objetos, fisicamente sua implementação é feita através de tabelas, ou seja, como um modelo relacional. A semântica da aplicação é modelada e representada através de objetos, enquanto sua implementação física é feita na forma relacional.
Uma das principais vantagens de estender um modelo relacional é a possibilidade de utilizar os dados de sistemas legados, geralmente implementados segundo modelos relacionais, fazendo sua migração para um novo sistema de banco de dados de uma forma gradual e transparente ao usuário.
As principais extensões ao modelo relacional que caracterizam os modelos relacionais-objeto são:
• Incorporação de novas funcionalidades ao SGBD para manipular este novos tipos complexos de dados;
• Suporte a herança;
• Possibilidade de manipulação de objetos diretamente por parte do usuário;
• Extensões feitas na linguagem SQL, para possibilitar manipular e consultar objetos.
A utilização dos conceitos de orientação a objetos adicionada à possibilidade de definir tipos complexos de dados possibilita que modelos E-R sejam facilmente implementados, o que não acontece diretamente com o modelo relacional.
A versão mais atual da SQL, SQL:1999, apresenta características para manipular e consultar bancos que implementem o modelo relacional-objeto. É uma extensão da SQL-2 (SQL 92) incluindo tratamento de objetos (objetos complexos, tabelas aninhadas, TADs, referências, identificadores de objetos, herança e definição de comportamento), consultas recursivas, instruções de programação, etc. Os exemplos a seguir serão apresentados de acordo com esta linguagem.
Os principais aspectos incluídos na SQL:1999 para dar suporte ao tratamento de objetos são:
• Relações aninhadas (objetos linha);
• Tipos complexos de dados;
• Herança;
• Referências e OIDs;
• Consultas mais complexas; e
• Definição de comportamento. Relações aninhadas
Em bancos relacionais, os domínios de todos os atributos são atômicos, ou seja, domínios cujos elementos são considerados unidades indivisíveis.
Muitas aplicações requerem que se armazene "objetos", que representam a realidade de uma forma mais natural. Neste caso, o banco de dados é visto como um conjunto de objetos. Em muitos casos não é possível representar um determinado objeto do mundo real através de somente um registro, sendo necessários vários registros para sua representação. É importante que o usuário tenha acesso a este banco de dados através dos objetos, sem tomar conhecimento de sua implementação física.
Segundo a SQL:1999, uma das formas de definir um objeto, é através da definição de um objeto linha (row object). Um tipo objeto linha define a estrutura de uma tupla, na forma de um registro.
Para permitir a representação de objetos que necessitam ser representados através de mais de um registro, o modelo relacional é estendido incorporando relações aninhadas. Isto significa que o domínio de um atributo pode ser uma relação, e não somente um valor atômico.
O exemplo a seguir permite que se entenda melhor o que significa este conceito. Consideremos uma aplicação que representa uma livraria. Cada livro possui um título, pode ter um ou mais autores, tem um preço de venda, e tem uma data de publicação, sendo representado pela seguinte relação:
Vamos supor que a esta relação apresente 2 tuplas, representadas na tabela 1.1.
Vemos na tabela acima que o domínio do atributo autores é uma relação, composta, por sua vez, de dois atributos: nome e sobrenome. Além disso, vemos que o atributo autores pode ser multivalorado, ou seja, pode ser composto de várias tuplas. Isto caracteriza o que denominamos de relações aninhadas. É importante frisar que não existe limitação para o nível de aninhamento de relações.
Uma tupla de uma relação aninhada pode ser vista como um item de dado, o que leva a uma correspondência um-para-um entre itens de dados e objetos na visão de um usuário. É importante lembrar que fisicamente as relações aninhadas continuam sendo implementadas através de tabelas distintas, de forma transparente ao usuário que tem acesso ao item de dado completo, como se estivesse em uma única tabela.
Assim, de acordo com o modelo relacional-objeto, um objeto é representado por um tupla de uma relação. Para simplificar a representação dos domínios constituídos por relações, eles são representados na modelagem somente por um nome, que é o nome do relacionamento. Assim, usando o exemplo anterior, podemos definir uma classe de objetos denominada LIVROS, sendo uma instância desta classe representada por uma tupla da tabela. Cada livro (objeto desta classe) apresenta os seguintes atributos:
• titulo, com valor atômico (string);
• autores - atributo multivalorado representando uma coleção de valores, de número variável, pois um artigo pode ter um ou mais autores. Cada um destes valores pode ser recuperado de forma independente, como por exemplo, quando se quer todos os artigos escritos por um determinado autor, mesmo que este seja um de uma série de autores;
• preco_venda - valor atômico, contendo o preço atual de venda deste livro;
• data_publicacao - composto por dia, mês e ano.
A definição dos atributos multivalorados é feita diretamente na modelagem da aplicação.
Assim, no modelo relacional-objeto o domínio de um atributo pode ser uma relação, sendo que os atributos desta relação podem também ser representados por relações, ou seja, relações podem
armazenar outras relações. Desta forma, o modelo relacional-objeto permite que um objeto complexo pode ser representado por uma única tupla de uma relação.
Tipos Complexos de Dados
Uma das principais características do modelo relacional-objeto é a possibilidade de definir tipos complexos de dados. Conforme já visto no último exemplo apresentado, as extensões feitas aos domínios para o modelo relacional não se restringem a relações aninhadas. Podem ser definidos domínios com valores multivalorados estruturados de diferentes formas, seja através de arranjos (arrays), de conjuntos (sets) ou de multiconjuntos (multisets), cada uma delas com diferentes formas de organização, manipulação e acesso. Os valores dos atributos destes domínios são sempre outros objetos, que também podem ser compostos de outros objetos.
Outra característica importante na utilização deste modelo é a possibilidade de definir referências a tuplas definidas através de esquemas próprios. Para isso, é acrescentada ao modelo a possibilidade de definição de tipos complexos de dados. Estes tipos complexos, também conhecidos como Tipos Abstratos de Dados (TADs), definem não somente a estrutura que os objetos criados com este tipo terão, mas também seu comportamento e possíveis heranças. Os tipos de dados assim definidos são armazenados juntamente com o esquema no banco de dados, e podem ser utilizados por aplicações que utilizem este banco. Estes tipos definidos pelo modelo relacional-objeto diferem dos tipos definidos em linguagens de programação (incluindo as linguagens de programação persistentes), pois os últimos não são armazenados no banco de dados, podendo ser utilizados somente pelos programas que incluem um arquivo textual contendo as declarações.
Usando a SQL:1999 para modelar o exemplo apresentado na seção anterior, inicialmente é definido o tipo correspondente a um objeto livro, sendo depois criada a tabela livros com este tipo. Na definição de um tipo podem ser utilizados outros tipos com domínio de atributos. A tabela do exemplo anterior pode ser criada definindo inicialmente os tipos utilizados como domínios (TNome e TData), depois o tipo de um livro (TLivro):
As declarações de tipos não criam tabelas. Estes tipos são usados no lugar da lista de atributos nos comandos que criam as tabelas (CREATE TABLE). Por exemplo, a declaração a seguir cria a tabela livros com o tipo definido acima:
Uma vez definido um tipo de dado, diferentes tabelas podem ser definidas de acordo com este tipo, sendo elas diferenciadas entre si pelo nome. Assim, o mesmo tipo definido para um livro poderia ser utilizado para criar uma tabela de apostilas:
Uma tabela definida com base em um TAD difere de tabelas convencionais do modelo relacional sob vários aspectos:
• Cada linha da tabela tem um OID - um identificador de objeto;
• As linhas desta tabela podem ser referenciadas por outros objetos do banco de dados. Como exemplo da utilização de outros tipos complexos de dados, poderíamos alterar a definição do conjunto de autores para um arranjo no qual cada elemento conteria o nome completo de um autor. Esta definição teria a vantagem de apresentar uma ordenação (o que não acontece no caso de conjunto), podendo ser identificado quem é o primeiro autor, quem é o segundo, e assim por diante. Supondo um número máximo de 10 autores, a definição de TLivro seria alterada para:
Objetos longos
Novas aplicações, tais como CAD (Computação gráfica) e SIG (Sistemas de Informação Geográfica), requerem que grandes objetos complexos possam ser utilizados na modelagem. Isto é aceito pelo modelo relacional-objeto ao permitir a definição de objetos longos. Assim, são tratados como um único objeto fotografias, imagens médicas de alta resolução, vídeos, textos longos, etc. Deste modo, os objetos da aplicação são representados diretamente no banco de dados, integrados aos outros dados, e não em arquivos separados.
Objetos longos - LOB (Large Objects), são armazenados diretamente no BDOR como atributos de tabelas, sendo considerados parte do esquema do BD, não precisando ser mantidos e tratados em arquivos separados. A SQL:1999 define alguns tipos de dados para tratar destes objetos longos:
• CLOB (Character LOB) para textos longos;
• BLOB (Binary LOB) para imagens.
Os valores destes domínios são da ordem de KB, MB e GB. Como exemplo, a definição de um tipo para autor de um livro poderia incluir seu curriculum vitae completo e sua foto:
Herança
O modelo orientado a objetos requer que sejam utilizados conceitos de herança. O modelo relacional-objeto suporta somente herança simples (herança múltipla não é contemplada). Herança está presente no nível dos tipos e no das classes.
Herança através da definição de tipos é representada através de relacionamentos supertipo/subtipo. Consideremos, por exemplo, a definição de um tipo pessoa na mesma aplicação que representa uma livraria:
Uma pessoa no contexto de uma livraria pode ser um funcionário ou um cliente. Nos dois casos, as propriedades do tipo TPessoa estão presentes. A figura 1.4 mostra a estrutura destas classes.
As subclasses para representar os dois papéis diferentes desempenhados por uma pessoa nesta aplicação podem ser criadas a partir das seguintes definições de tipos:
Herança também é representada no nível das tabelas do banco de dados. Os tipos das tabelas filhas devem ser subtipos da tabela pai. Devido ao conceito de herança, todas as tuplas das tabela filhas estão implicitamente presentes na tabela pai.
Usando este conceito, o exemplo anterior é representado da seguinte maneira:
Diferentes formas de armazenamento das subtabelas podem ser implementadas para aumentar a eficiência do banco de dados. A forma natural é a de armazenar os atributos comuns, herdados pelas subtabelas, somente na tabela da superclasse. Nas subclasses são armazenados somente os atributos específicos de cada uma delas. Entretanto, para melhorar a eficiência, podem ser replicados os atributos herdados nas subclasses, facilitando desta forma as consultas, pois todos os atributos da subclasse seriam encontrados na mesma (tanto os herdados como os específicos). O conceito de herança torna mais natural a definição do esquema em um banco de dados relacional-objeto. Se a herança não estivesse presente, o projetista do banco de dados precisa encadear explicitamente as tabelas das subclasses às suas superclasses através de chaves primárias, e definir restrições entre a tabelas para garantir restrições referenciais e de cardinalidade. A utilização da herança permite a utilização de funções definidas para supertipos nos objetos pertencentes aos subtipos, permitindo desta forma a extensão ordenada do banco de dados através da incorporação de novos tipos.
Referências e OIDs
No modelo relacional-objeto, um atributo pode referenciar diretamente um outro objeto. O domínio deste tipo de atributo consiste em um ponteiro lógico para um objeto de um determinado tipo. Desta forma são modelados relacionamentos de associação entre objetos. Somente pode ser referenciada uma tabela que tenha definido um OID (identificador de objeto).
A utilização de referências não é semelhante a uma chave estrangeira – chaves estrangeiras podem ser compostas. O modelo relacional-objeto não permite a definição de chaves estrangeiras.
Como exemplo desta forma de relacionamento, consideremos a definição de um tipo representando uma seção da livraria. Cada seção é identificada por um nome, possui uma localização e um chefe. Este chefe é uma referência direta a um objeto:
No tipo definido acima, TSecao, o domínio do atributo chefe é uma referência a um objeto de tipo TFuncionario.
Quando mais de uma tabela pertence a um mesmo tipo, a definição de uma referência necessita adicionalmente da indicação de qual a tabela que se quer referenciar, ou seja, é necessária a definição do escopo da referência. Isto é feito através da cláusula "scope", no momento da definição de uma tabela com o tipo que contém algum atributo do tipo referência. Esta cláusula somente é necessária no caso de existirem duas ou mais tabelas do tipo referenciado. No exemplo acima, caso mais de uma tabela tenha sido declarada com o tipo Funcionario, a definição do escopo da referência para a tabela Funcionarios ao criar a tabela Secoes é feita da seguinte maneira:
A manipulação de tabelas que contém atributos do tipo referência deve ser feita acessando diretamente os objetos referenciados. Seguindo com o mesmo exemplo anterior onde foi definida a tabela (classe) Secoes, vamos supor que tenham sido instanciadas as diferentes seções da livraria. Cada instância desta classe recebe o valor de seu atributo chefe, definido por referência, acessando o objeto que representa o funcionário que será o chefe da seção, como por exemplo:
Para se obter a linha apontada por uma referência é usado o apontador de referência "!". Por exemplo, a construção:
retorna o atributo salario da linha apontada por chefe.
Segundo os conceitos de orientação a objetos, o identificador de um objeto (OID) normalmente não é visto pelos usuários. Entretanto, em bancos de dados pode ser útil tratar o OID como um atributo normal.
Em um BDRO, o identificador de um objeto é o valor indicado pelos atributos de referência. Pode ser definido pelo usuário ou pelo sistema, e constituir uma chave primária. A SQL:1999 permite que uma coluna (domínio de um atributo) contenha referências para a própria linha. Por exemplo, vamos alterar a definição do tipo de seção da seguinte maneira:
Na definição do tipo TSecao, a definição do nome da seção indica que seu domínio é uma referência a uma linha do próprio tipo. Na criação da tabela se especifica que a referência dentro da linha deve apontar para a própria linha. Da maneira como foi definido (SYSTEM GENERATED), o OID é gerado e controlado pelo sistema. A SQL:1999 permite também que os valores de OIDs sejam definidos pelo usuário (USER GENERATED), caso em que o atributo é definido pelo usuário,
Consultas
As linguagens de manipulação para BDRO, como a SQL:1999, devem oferecer um mecanismo capaz de especificar consultas que contenham as chamadas expressões de caminho. As consultas são feitas utilizando expressões de caminho para acessar os diferentes campos das tuplas aninhadas que apresentam os objetos complexos. Expressões de caminho são um recurso simples e elegante para navegar pela estrutura dos objetos, pois as linguagens que suportam a escrita de expressões de caminho fornecem um mecanismo uniforme para a formulação de consultas que envolvem diferentes características do modelo OO, incluindo relacionamentos binários, derivados e herança.
No contexto do processamento de consultas, vale a pena ressaltar que a existência de uma expressão de caminho pode sugerir uma ordem de execução que não necessariamente pode ser a mais eficiente. Uma expressão de caminho pode às vezes ser processada mais eficientemente usando-se junções (ao invés de percorrer diretamente as referências entre os objetos), ou mesmo sendo percorrida na ordem inversa à qual foi definida, percorrendo-se os atributos inversos. O processamento de consultas com expressões de caminho torna-se ainda mais complexo quando levamos em conta a presença de métodos e aspectos de desempenho. Isto porque os métodos podem ser implementados em outras linguagens de programação, o que torna extremamente difícil a tarefa do otimizador de consultas de identificar regras de transformação entre operadores e estimar custos das operações. Além disso, a maioria das técnicas de otimização de consultas já proposta na literatura até hoje não são diretamente aplicáveis pois não consideram as características novas do modelo OO em relação ao modelo relacional. Para contornar os problemas de desempenho no processamento de expressões de caminho, novos recursos como a definição de índices para expressões de caminhos são considerados por trabalhos na literatura. Em [14] encontra-se um estudo detalhado da resolução de consultas para modelos relacionais-objeto.
O modelo relacional-objeto permite ao usuário a definição de funções e procedimentos para representar os métodos dos objetos. O padrão SQL:1999 permite a manipulação de código de programa através de três formas diferentes: métodos, funções e procedimentos.
O corpo de um método é definido separadamente, sendo seu nome adicionado à definição do tipo. Por exemplo, consideremos a seguinte alteração na definição do tipo de livro, acrescentando a este tipo a definição de um método que altera o preço de venda do livro, acrescentando a ele um determinado percentual (passado como parâmetro):
Funções e procedimentos podem ser definidos fora do TAD, através de declarações CREATE FUNCTION e CREATE PROCCEDURE. A identificação da função/procedimento a ser executado é determinada em tempo de compilação (early binding).
A SQL:1999 já vem com alguns métodos pré-definidos:
• construtor - inicializa valores de atributos. Se T é o nome de um ADT, T() é o nome do construtor. O construtor padrão atribui null a todos os atributos do objeto;
• acessadores (observer function) - aplicado um por atributo, devolve o valor deste atributo. São equivalentes aos métodos get de LPOO. Se A é o nome de um atributo, e X é uma variável cujo valor é um objeto, A(X) ou X.A devolve o valor do atributo A;
• alteradores (mutator function) - também aplicado um por atributo, atribui um valor a este atributo. Esta função sobre-escreve a instrução de atribuição da linguagem de BD.
Funções e procedimentos podem ser definidos basicamente de duas maneiras diferentes: através de uma linguagem de programação, como bindings para Java, C ou C++; ou utilizando uma linguagem de manipulação de dados tipo SQL, como o PL/SQL para o Oracle ou o TransactSQL para o MS SQL Server. As funções definidas através de linguagens de programação tendem a ser mais eficientes do que aquelas definidas através de linguagens do tipo SQL. Entretanto, quando estas precisam ser compiladas externamente e depois carregadas e executadas sobre o banco de dados, trazem o risco de introduzir erros no banco, podendo corromper a estrutura interna do banco.
Bancos de Dados Relacionais-Objeto Comerciais
Muitos dos aspectos hoje apresentados por BDROs foram introduzidos pelo Postgres, que evoluiu para o atual PostgreSQL. O primeiro dos grandes vendedores de bancos de dados a incluir características relacionais-objeto a seus produtos foi o Informix, ao comprar e incorporar o SGBDRO Illustra o qual, por sua vez, foi construído por empregados do Postgres. Quando a Informix transformou seu banco em um BDRO, introduzindo o Servidor Universal, tanto a Oracle como a IBM seguiram seus passos estendendo seus SGBDs para manipular o modelo relacional-objeto. Mais tarde, em 2001, a IBM comprou o Informix, passando a incorporar esta tecnologia ao DB2.
Hoje em dia, todos os grandes SGBDs, tais como DB2 da IBM, Oracle e Microsoft SQL Server, suportam a tecnologia relacional-objeto, com diferentes graus de sucesso.
Oracle
A partir da versão 8, foram adicionadas características de objetos ao banco de dados Oracle, um banco de dados relacional, tornando-se assim um SGBDRO. A última versão é o Oracle 10g. A cada nova versão são incluídos novos tipos de dados, para representar dados de novas aplicações. Estes tipos de dados estendidos são definidos e agrupados em cartridges, que oferecem novos tipos e novas funções para manipular esses novos tipos de dados. A cada nova versão do Oracle são disponibilizados novos cartridges, acrescentando ao banco novas funcionalidades. Existem cartridges para trabalhar com dados espaciais, dados multimídia, textos longos, etc.
Além dos tipos básicos da SQL, o Oracle permite que sejam definidos dois tipos de dados pelo usuário (user defined data types): tipos de objetos e tipos de coleções. Enquanto a SQL:1999 fala de tipos (para colunas) e de tipos de linha (para relações), o Oracle a partir da versão 8i/pi usa a notação de tipos de objetos para ambos. Os usuários podem definir seus próprios tipos (para representar os objetos de seus negócios), e os relacionamentos (herança, agregação) entre estes tipos; podem armazenar as instâncias destes tipos no banco de dados, seja em uma coluna de uma tabela, ou em tabelas propriamente ditas; e podem consultar, inserir e atualizar estas instâncias.
O tipo objeto é semelhante ao de classe em orientação a objetos, com exceção da herança. Como em OO, para cada tipo objeto deve ser definido um nome, uma lista de atributos e uma lista de métodos. Exemplo da definição para o Oracle:
Atributos multivalorados podem ser representados através do tipo VARRAY. Um VARRAY possui implícito um contador COUNT que indica o número do elemento corrente, e um limite LIMIT para indicar o número máximo de elementos que o arranjo pode ter. Exemplo:
Atributos do tipo referência podem ser definidos, através da utilização do construtor REF. Os objetos têm identificadores únicos, denominados Object ID, que podem ser usados como referências entre objetos.
Uma propriedade interessante é que os dados definidos como objetos também podem ser tratados de forma relacional. Assim, dados definidos através de referência podem ser acessados através destas referências, ou através de junções explícitas entre os objetos das tabelas. Por outro lado, o
Oracle permite que um usuário trate dados relacionais como se fossem objetos, através de visões de objetos (object views).
Além disso, os usuários podem definir métodos para definir operações sobre os objetos definidos. Estes métodos podem ser implementados como procedimentos armazenados escritos em Java ou PL/SQL. O Oracle disponibiliza um conjunto grande de APIs para ligação com diferentes linguagens de programação, oferecendo suporte nativo para Java e PL/SQL dentro do banco de dados, com forte ligação entre o sistema de tipos relacionais-objeto e os procedimentos escritos nestas duas linguagens. O banco disponibiliza também o mapeamento entre os tipos SQL e as linguagens de programação, tais como Java e C++, de modo a disponibilizar o acesso a instâncias dos tipos SQL a partir de aplicações Java e C++.
