A IMPLEMENTAÇÃO OBJETO-RELACIONAL ORACLE

A IMPLEMENTAÇÃO OBJETO-RELACIONAL ORACLE A maior parte dos sistemas gerenciadores de bancos de dados (SGBDs) utilizados nos últimos anos, é baseada no modelo relacional. No entanto, SGBDs baseados em outros modelos têm surgido devido à demanda de novas aplicações. O modelo objeto-relacional é baseado na idéia de que o modelo relacional deve ser estendido para contemplar conceitos de orientação a objetos. Para isso são acrescentadas estruturas a linguagens de consulta relacionais, como SQL, para tratar os tipos de dados acrescentados. Tais extensões tentam preservar os fundamentos relacionais, em particular o acesso declaratório ao dado, enquanto que estende o poder da modelagem. Sua principal estrutura ainda é composta por tabelas sendo que com muito mais recursos do que as tabelas puramente relacionais. Entre esses recursos podemos destacar: definição de tipos pelo usuário, registros e vetores, métodos e funções, referências, herança e polimorfismo. Os SGBDOR s são uma inovação de seus antecessores SGBDR s, e, ao contrário da conversão para sistemas de banco de dados orientados a objetos, a migração objeto/relacional não necessariamente envolverá uma mudança completa. Mostraremos em seguida alguns conceitos que definem um modelo objetorelacional: Tabelas Aninhadas: A primeira forma normal (1FN) exige que todos os atributos tenham domínios atômicos, ou seja, os elementos de seu domínio devem ser unidades indivisíveis. Entretanto, nem todas as aplicações são compatíveis com esta forma normal. Em vez de enxergar o banco de dados como um conjunto de arquivos, os usuários de certas aplicações enxergam o banco de dados como um conjunto de objetos. Esses objetos podem exigir vários arquivos para sua representação. Pode-se notar que uma interface simples e fácil de usar exige uma correspondência um para um entre a noção intuitiva de um objeto para o usuário e a noção de um item de dado para o banco de dados. O modelo relacional aninhado é uma extensão do modelo relacional em que os domínios podem ser definidos como atômicos ou como tabelas. Então, o valor de uma linha sobre um atributo pode ser uma tabela, e tabelas podem ser armazenadas dentro de tabelas. Então, um objeto complexo pode ser representado por uma ou mais linhas de uma tabela aninhada. Tipos Complexos e Orientação a Objetos: As tabelas aninhadas são apenas um exemplo de extensões ao modelo relacional básico. Outros tipos de dados não atômicos, como registros aninhados, também têm se mostrado úteis. O modelo de dados orientado a objeto tem provocado uma necessidade por características como herança e referências a objetos. Sistemas com tipos complexos e orientação a objeto permitem que os conceitos do modelo entidade-relacionamento, como identidade de entidades, atributos multivalorados, generalizações e especializações, sejam representados diretamente sem uma tradução complexa para o modelo relacional. Herança: Da mesma forma que as linguagens de programação, o modelo objeto-relacional também suporta o conceito de herança de tipos de dados estruturados definidos pelo usuário, permitindo criar um subtipo de um ou mais tipos existentes. Assim, um subtipo herda especificações de atributos e métodos de todos os supertipos 1

associados. A herança pode ser no nível de tipos ou de tabelas. Será considerado inicialmente o primeiro tipo. Especificada por uma cláusula como under, a herança agrupa os tipos em uma hierarquia, permitindo modularidade e reuso na definição dos tipos. Temos que considerar ainda que uma hierarquia de tabelas não precisa estar associada a uma hierarquia de tipos. Uma tabela pode herdar atributos diretamente de outras tabelas, sem a necessidade de criação de tipos específicos. A herança torna a definição de esquema mais natural. Sem a herança de tabelas, precisaremos ligar, explicitamente, as tabelas correspondentes às subtabelas, com as tabelas correspondendo às supertabelas via chaves primárias, ou através de tipos referência, e então definir restrições entre elas para assegurar restrições referenciais e de cardinalidade. Tipos Referência: Assim como as linguagens orientadas a objeto, o modelo objeto-relacional também fornece a habilidade de se referir a objetos. O modelo objetorelacional permite que o domínio de um atributo seja uma referência para outro de um tipo especificado. Em geral, se uma tabela tem uma coluna do tipo referência, então cada valor da coluna pode referenciar qualquer objeto do tipo referenciado, ou seja, pode-se referenciar objetos em diferentes tabelas. Entretanto, existem recursos que restringem o escopo de referências para uma única tabela. Funções: Sistemas objeto-relacionais permitem que funções sejam definidas pelos usuários. Essas funções podem ser definidas em uma linguagem de programação como C/C++, Java ou em uma linguagem de manipulação de dados como a SQL. As funções definidas em linguagens de programação podem ser mais eficientes do que funções definidas usando SQL. Além de que as consultas que não podem ser executadas em SQL podem ser executadas por essas funções. Um exemplo de uso de tais funções seria executar uma complicada operação aritmética sobre o dado em uma linha. 1. MODELO OBJETO-RELACIONAL ORACLE Para utilizar os recursos de orientação a objetos a Oracle implementou diversos conceitos que definem um modelo objeto-relacional. Examinaremos os principais conceitos a seguir. Em outro artigo, poderemos esmiuçar outras características do Oracle. 1.1 - Tipo Objeto O Oracle suporta o conceito de objetos aninhados, ou object types. Podemos criar tipos de dados adicionais e depois fazermos referência a esses tipos de dados dentro de outros objetos. Essa capacidade de estender o banco de dados com tipos adicionais é um recurso muito importante, pois ajuda a simplificar a complexidade do tratamento com tipos de dados complexos. O exemplo a seguir demonstra a criação de um tipo de dados definido pelo usuário: 2

create type t_endereco as object ( rua varchar2(40), cidade varchar2(30) uf char(2), cep number(8) ) Esse tipo pode ser usado de muitas maneiras diferentes e em muitos lugares diferentes. Ainda é possível usar tipos dentre de tipos, ou seja, um tipo pode ser um atributo de outro tipo. O exemplo a seguir mostra do tipo t_endereco sendo referenciado por t_funcionario: create type t_funcionario as object ( matricula number(5), nome varchar2(30), data_admissao date, endereco t_endereco) Observamos que na criação de tipos-objeto não é suportada a definição de atributos que sejam NOT NULL. Dessa forma, por padrão, uma instância de um objeto automaticamente é inicializada como NULL. Note que o objeto inteiro é NULL, não necessariamente os atributos dele serão. 1.2 - Tabela de objetos Uma tabela de objetos (object table), é uma classe especial de tabela cujas linhas são objetos. São tabelas que possuem a estrutura definida por um tipo de dado estruturado. Desta forma, as linhas das tabelas tornam-se instâncias ou objetos do tipo que define a sua estrutura. A estes objetos, denominamos "objetos de linha". Considere o seguinte exemplo: Uma tabela que manipula objetos do tipo t_funcionario definido anteriormente pode ser definida por: create table funcionarios of t_funcionario; Como pode ser observada, a identificação de objetos no modelo objetorelacional depende do tipo de tabela a qual eles pertencem. No caso de uma tabela de objetos, na qual os objetos são derivados de um tipo estruturado, cada objeto possui um identificador do objeto (OID), e, no entanto, são identificados baseados na sua existência, conforme define o modelo orientado a objetos. Desta forma, uma tabela de objetos representa um conjunto de objetos. No entanto, no caso das tabelas relacionais 3

tradicionais, as linhas da tabela não possuem OID, e conseqüentemente, possuem existência baseada apenas nos valores de seus atributos, conforme o modelo relacional. Neste caso, as tabelas representam um multi-conjunto de linhas, ou sejam podem possuir mais de uma linha com os valores de todos os atributos idênticos. Podemos concluir que estes dois mecanismos de identificação de objetos coexistem em um esquema objeto-relacional. 1.2.1 Operador VALUE Esse operador retorna o conteúdo de um objeto armazenado em uma object table. É usado quando for preciso referenciar uma linha de uma object table como um objeto em vez de uma lista de colunas. Por exemplo, a declaração abaixo irá armazenar o objeto obtido pela consulta dentro da variável v_funcionario: declare v_funcionario t_funcionario; begin select value(f) into v_funcionario from funcionarios f where matricula = 1574; dbms_output.put_line (v_funcionario.nome); end; 1.3 - Tipos Referência Este é o ponteiro lógico utilizado pelo Oracle. No Oracle, o relacionamento entre duas entidades pode ser modelado nativamente via o conceito de uma referência. Expressamos tais relacionamentos utilizando o identificador do objeto (OID) associado a cada instância de um tipo de dado estruturado. Esse identificador é atribuído automaticamente a objetos para identificar unicamente um objeto, permitindo assim que o objeto correspondente seja referenciado a partir de outros objetos. Isto é feito através do tipo REF, que encapsula uma referência para um objeto especificado. Uma referência é especificada na definição do tipo objeto através da expressão REF e o nome do tipo objeto alvo. Exemplo: Seja o tipo de dado estruturado t_departamento, a tabela de objetos departamentos e a tabela funcionarios definidos respectivamente por: create type t_departamento as object ( num_depto number, nome varchar2(30), endereco t_endereco ); 4

create table departamentos of t_departamento; create table funcionarios ( matricula number, nome varchar2(30), depto ref t_departamento); Neste caso, a coluna depto definida na tabela funcionarios contém uma referência a um identificador único para objetos do tipo t_departamento. Como dissemos anteriormente, uma coluna do tipo REF pode referenciar objetos do tipo referenciado de qualquer tabela. Para restringir o escopo de referências para uma única tabela utilizamos a cláusula SCOPE, conforme mostra o exemplo: create table funcionarios ( matricula number, nome varchar2(30), depto ref t_departamento scope is departamentos); Uma coluna do tipo referência pode também referenciar objetos do mesmo tipo. Por exemplo, o tipo t_pessoa definido abaixo pode incluir uma referência a seu amigo, que também é do tipo t_pessoa, como segue: create type t_pessoa as object ( nome varchar2(30), endereco t_endereco, data_nasc date, amigo REF t_pessoa); Para demonstrar como os dados são inseridos nas tabelas de objetos que contêm atributos do tipo referência, segue abaixo dois exemplos: insert into departamentos values (1, ITP, t_endereco ( Av. Beira Mar, 1254, Aracaju, SE, 49000000) 5

insert into funcionarios values (4036, Mara Rubia, (select ref(d) from departamentos d where d.nome= ITP )); Neste caso, o atributo depto conterá uma referência para o referido objeto departamento o qual o funcionário está lotado. E sendo assim, quando precisarmos recuperar um objeto a partir de uma referência podemos utilizar o operador DEREF. Por exemplo, a declaração a seguir armazena o objeto departamento dentro da variável v_depto: declare v_depto departamento; v_nome_depto varchar2(30); begin select deref(depto) into v_depto from funcionarios where nome='mara Rubia ; select v_depto.nome into v_nome_depto from dual; end; Observamos que não é permitido referenciar diretamente um atributo de uma coluna do tipo objeto. Por exemplo, a declaração abaixo é inválida: select nome, deref(depto).nome from funcionarios; Entretanto, uma das vantagens da utilização de referências no projeto de esquemas objeto-relacionais é a possibilidade de referenciar atributos através dos tipos referência. Como exemplo, suponhamos que queiramos obter o nome do departamento que um funcionário trabalha a partir do nome do mesmo. A declaração a seguir usa a referência armazenada no atributo depto que é um apontador para o respectivo objeto departamento. select f.depto.nome from funcionarios f where nome='mara Rubia ; Uma outra importante característica a ser destacada refere-se ao uso do tipo REF como restrição de integridade referencial. Embora exista a imposição que uma instância do REF (isto é, OID) seja válida quando armazenada em uma tabela, esta imposição não permanece válida. Isto é, um objeto referenciado por um tipo REF pode ser excluído da 6

tabela de objeto correspondente, e desta forma, a referência a este objeto torna-se inválida, não sendo verificada pelo SGBD. Tal verificação pode ser feita através de triggers que previnem a exclusão de objetos referenciados por REFs. Com a criação dessas triggers para garantir a integridade referencial, adicionamos um processamento adicional (overhead), em nosso esquema, principalmente se este fizer o uso constante de tipos REF em seus tipos de dados. 1.4 - Tipos coleção Os tipos coleção (collection types) definem estruturas de dados que permitem manipular conjuntos de elementos do mesmo tipo. O Oracle implementa dois tipos de dados coleções: o tipo vetor (varray) e a tabela aninhada (nested table). 1.4.1 - Tipo Vetor (VARRAY) Esse tipo é um vetor, ou seja, uma lista ordenada de elementos do mesmo tipo. Cada elemento tem um índice, que é um número da posição do elemento no vetor. No Oracle é chamado de VARRAY, porque o vetor é de tamanho variável. Por isso quando este for criado sempre deverá ser especificado o seu tamanho máximo. É importante notar que o banco de dados não aloca realmente qualquer espaço; ele apenas define um novo tipo e o armazena no catálogo do sistema. O seguinte exemplo declara um tipo varray: create type lista_telefones as varray(5) of varchar2(10) Neste caso, é criada uma lista que suporta até cinco telefones. É possível ainda fazer referência a esse vetor em outra tabela, como o tipo de dados de uma coluna. Por exemplo: create table pessoa ( nome varchar2(25), telefone lista_telefones) 1.4.2 - Tabelas Aninhadas (Nested tables) Vimos que o modelo objeto-relacional permite criar tabelas aninhadas, que na prática são tabelas com colunas cujo tipo de dado de domínio é outra tabela. Isto é, as tabelas podem ser aninhadas dentro de outras tabelas como valores na coluna. Desta maneira, os relacionamentos muitos-para-muitos podem ser representados por tabelas aninhadas (nested tables). O tipo de dados nested table contém elementos desordenados, todos do mesmo tipo, e sem limite de elementos. Sua funcionalidade básica é semelhante a uma tabela de 7

índices: é composta por duas colunas chave e valor. Quando uma coluna de uma tabela é do tipo nested table, seus dados são armazenados no mesmo lugar desta tabela. Exemplo: Suponha que o material necessário para o aprendizado de uma disciplina seja um conjunto de livros. Sejam os tipos de dados estruturados t_livro e lista_livros para representar um livro e uma lista de livros: create type t_livro as object ( numero number(4), titulo varchar2(40) ) create type lista_livros as table of t_livro; A definição a seguir cria a tabela que irá armazenar todas as informações do material necessário à disciplina: create table material_disciplina ( departamento char(4), curso number(3), livros_requeridos lista_livros) nested table livros_requeridos store as livros_requeridos_tab; Neste caso, será criada uma tabela secundária (store table), que é a tabela que irá armazenar os dados da nested table. Cada linha de livros_requeridos conterá uma referência para a tabela secundária (store table) que foi chamada de livros_requeridos_tab. Observamos que no Oracle, uma tabela pode conter mais de uma tabela aninhada, e no Oracle 9i uma tabela aninhada também pode conter outra tabela aninhada. Vejamos a seguir como os dados são inseridos na tabela material_disciplina que contém uma tabela de objetos que irá armazenar uma lista de livros: insert into material_disciplina values ( ccft, 10, lista_livros ( t_livro (1, Oracle 9i ), t_livro (2, Oracle 8i ) ) ); 8

Mostramos ainda um exemplo de uma pesquisa nesta tabela: select l.titulo from material_disciplina m, table(m.lista_livros) l where m.departamento= CCFT and m.curso=10; Neste caso, é listada a lista de livros requeridos do curso número 10 do departamento CCFT. Observe que usamos a expressão TABLE para representar o conjunto de elementos armazenados na nested table livros_requeridos. 1.5 - Métodos e funções Outro recurso importante é a capacidade de vincular código aos dados. Chamamos isso de segmentos de código. Isso se aproxima da capacidade de encapsulamento, uma das bases dos bancos de dados orientados a objetos. Considere o tipo de objeto t_funcionário definido abaixo: create type t_funcionario as object ( nome varchar2(30), data_nasc date), member function idade return integer), member procedure altera_nome(p_nome IN varchar2), map member function retornar_nome return varchar2, order member function comparar_func (p_func in t_funcionario ) return number); Neste caso os métodos e funções estão vinculados ao código do tipo de dados t_funcionario. Com isso temos código e dados sendo unidos fortemente. Isso é muito mais poderoso do que as triggers de banco de dados tradicionais. Essa habilidade de ter objetos dentro de objetos, código e dados vinculados traz um grande ganho de desempenho. A criação da função idade do tipo t_funcionario seria assim definida: create type body t_funcionario is member function idade return integer is begin -- código-fonte da função end; 9

end; member procedure altera_nome (p_nome IN varchar2) is begin nome := p_nome; end; 1.6 - Herança A partir do Oracle 9i um tipo pode ser estendido criando subtipos que reusam a especificação e implementação (atributos e métodos) do tipo que ele deriva. Num subtipo, a capacidade de aumentar a estrutura dos dados herdada de seu supertipo definindo outros atributos, é referenciada a ele como uma herança de dados. A capacidade de adicionar outros métodos além dos herdados de seu supertipo é referenciado como herança de método. O Oracle 9i provê suporte a herança de dados e de métodos. Através dos objetos é possível criar uma hierarquia de tipos. Isso significa que os subtipos automaticamente adquirem os atributos e métodos de seu tipo pai, e quando esses atributos e métodos são alterados em seu pai, os subtipos também são influenciados. Um subtipo pode ser derivado indiretamente através de outros subtipos, podendo ter vários subtipos irmãos. Mas um subtipo pode derivar apenas de um único supertipo, ou seja, não pode derivar de mais de um simultaneamente. Em outras palavras, o Oracle 9i não suporta herança múltipla. Um subtipo se torna um tipo especial de seu pai pelo fato de possuir novos atributos e métodos e também de poder redefinir os que foram herdados. Redefinir métodos dá ao subtipo um estilo próprio de executar esses métodos. A Supertipo de todos B Subtipo de A Supertipo de C D Subtipo de A C Subtipo de B Figura 1 Exemplo de uma hierarquia de tipos 10

1.6.1. Tipos e métodos FINAL e NOT FINAL A definição do tipo do objeto determina se um subtipo pode ser derivado. Por padrão os tipos de objeto são do tipo FINAL, por isso para permitir subtipos, deve ser adicionada a expressão NOT FINAL na declaração do tipo do objeto. Por exemplo: create type t_pessoa as object (codigo number, nome varchar2(30), endereço varchar2(100) ) not final; Essa expressão declara que o tipo t_pessoa pode ser derivado, permitindo que sejam criados subtipos a partir dele. Assim como os tipos de objetos, os métodos também podem ser declarados como FINAL ou NOT FINAL. Se um método for definido como FINAL, os subtipos não podem redefinir sua implementação. Mas, diferente dos tipos de objetos, os métodos são definidos por padrão como NOT FINAL, e por isso para que não seja permitida sua redefinição, deve ser declarada a expressão FINAL em sua declaração. O exemplo abaixo cria um tipo de objeto NOT FINAL contendo uma função FINAL: create type t as object (..., member procedure imprimir(), final member function alterar(x number)... ) not final; 1.6.2 Criação de subtipos Podemos criar um subtipo usando a declaração CREATE TYPE e especificar o seu supertipo através do parâmetro UNDER. Por exemplo: create type t_estudante under t_pessoa ( cod_dep number, disciplina_principal varchar2(30) ) not final; 11

A declaração acima cria um tipo t_estudante que é subtipo de t_pessoa, herdando assim todos os atributos e métodos declarados em t_pessoa. Apenas são adicionados dois novos atributos. Os nomes dos novos atributos declarados no subtipo devem ser diferentes dos nomes e métodos declarados no seu supertipo. Como dito anteriormente, um tipo pode ter múltiplos subtipos, e esses também podem ter subtipos. A declaração abaixo cria outro subtipo t_empregado herdando de t_pessoa: create type t_empregado under t_pessoa (cod_emp number, setor varchar2(30)); 1.6.3 Criação de tabelas Pode-se observar que não há estrutura de armazenamento associada com os tipos que pertencem à hierarquia acima descrita. Deve-se então, criar tabelas de objetos para manipular as instâncias dos tipos, formando assim uma hierarquia de tabelas, como ilustra o exemplo a seguir: create table pessoas of t_pessoa; create table estudantes of t_estudante under t_pessoa; create table empregados of t_empregado under t_empregado; 12

CONCLUSÕES O modelo relacional foi amplamente empregado nos últimos quinze anos e não é possível simplesmente ignorar todas as aplicações já construídas. Esses sistemas devem coexistir com as novas aplicações orientadas a objeto, entretanto, os Bancos de Dados Relacionais estão tornando-se ou adquirindo características de OO-relacional, um ser híbrido. Isto mostra que, mais cedo ou mais tarde, os Bancos de Dados que quiserem sobreviver deverão mudar sua estrutura até chegar, no futuro, em um Banco de Dados efetivamente OO no qual os problemas de desempenho serão minimizados ou resolvidos de maneira clara e a baixo preço. É claro que tudo isso depende de uma aceitação do mercado. O interesse dos grandes fabricantes de software é essencial neste processo. Em se tratando de tecnologia objeto-relacional o suporte recebido das ferramentas CASE ainda é deficiente. Como conseqüência, existem no mercado poucos softwares que auxiliam ao desenvolvedor na modelagem objeto-relacional para utilizar a tecnologia com profundidade. Uma base objeto-relacional traz vantagens em relação ao desempenho, pois a utilização de ponteiros e tabelas aninhadas tornam as consultas de um SGBDOR mais rápidas e compactas que as consultas feitas através de junções no modelo relacional. Um dos grandes problemas do modelo Objeto Relacional é a falta de padrão. Isto implica problemas de transportabilidade, pois cada SGBDOR possui suas idiossincrasias. 13

BIBLIOGRAFIA ABBEY, Michael; ABRAMSON, Ian; COREY, Michael. Oracle 8i: guia introdutório. Rio de Janeiro: Campus, 2000. 701 p. pp. 58-82. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML, guia do usuário. Rio de Janeiro: Campus, 2000. 472 p. COLAÇO, Methanias & SANTOS, Maria de Fátima Almeida; RIBEIRO, Mateus de Freitas. Evolução dos bancos de dados: Um enfoque para os sistemas pós-relacionais. Trabalho de Conclusão de Curso de Ciência da Computação. Aracaju: Universidade Federal de Sergipe, 2000. CHAUDHRI, Akmal B. e ZICARI, Roberto. Succeeding with Object Databases John Wiley & Sons, 2000. 464 p. - pp. 29-51 Oracle 9i - Application Developer s Guide: Object-Relational Features. Oracle Corporation, 2001. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de Banco de Dados. 3a. ed. São Paulo: Makron Books, 1999. URMAN, Scott. Oracle 8i: Advanced PL/SQL Programming. Oracle Press.. Oracle 8: PL/SQL Programming. Oracle Press. 14

Methanias Colaço Rodrigues Júnior (www.unit.br/methanias) é Especialista em Ciência da Computação e Tecnologia da Informação, Mestre em Informática pela UFCG, Professor da Universidade Tiradentes (www.unit.br), Líder de Projeto do Banco de Estado de Sergipe (www.banese.com.br), consultor da Oráculo Consultoria. Presta consultoria e dá treinamentos em Bancos de Dados, Engenharia de Software, Data Warehouse e Sistemas de Cartão de Crédito. 15