Concepção e Administração de Bases de Dados

Transcrição

MODELO OBJECTO - RELACIONAL
ORACLE 8
Trabalho realizado no âmbito da cadeira
Concepção e Administração de Bases de Dados
Mestrado em Engenharia Informática
Departamento de Engenharia Informática
Universidade de Coimbra
Filipe Manuel Simões Caldeira, 1999
Oracle 8 – Modelo Objecto - Relacional
Índice
Introdução......................................................................................................................... 3
Bases de Dados Orientadas a Objectos............................................................................. 4
Orientação a Objectos ................................................................................................... 4
O Objecto ................................................................................................................... 4
Hierarquias das Classes ............................................................................................. 6
O Modelo Objecto - Relacional do Oracle 8 .................................................................... 7
Objectos em Oracle ....................................................................................................... 7
Definição de objectos................................................................................................. 7
Métodos ..................................................................................................................... 9
Métodos de comparação ............................................................................................ 9
Tabelas de Objectos (Object Tables) .......................................................................... 10
Referências .................................................................................................................. 10
Tipos de Referências................................................................................................ 11
Dados do Tipo Colecção ............................................................................................. 11
Varray ...................................................................................................................... 11
Nested Tables........................................................................................................... 12
Varrays Vs Nested Tables........................................................................................ 12
Uma estrutura de dados no Modelo Objecto-relacional ................................................. 13
Estrutura de Dados no Modelo Relacional:................................................................. 14
Estrutura de dados no Modelo Objecto - Relacional: ................................................. 16
Conclusão ....................................................................................................................... 20
Bibliografia..................................................................................................................... 20
Pág. 2
Introdução
Pretende-se com este trabalho, mostrar de uma forma simples a utilização do
“object options pack” do sistema Oracle 8 para implementar o modelo objectorelacional no desenho e estruturação de bases de dados.
É abordada a forma de “pensar” e “programar” orientada a objectos, focando
naturalmente as bases de dados. Apresentam-se também as principais novidades do
Oracle no que se refere a objectos e seu modo de funcionamento e implementação.
Foi introduzido um exemplo que pretende demonstrar a aplicação desta
metodologia a um problema concreto. Este problema é abordado usando o modelo
relacional e posteriormente é usado o modelo objecto-relacioanl, permitindo assim
efectuar uma comparação entre os dois métodos.
Pág. 3
Bases de Dados Orientadas a Objectos
Uma base de dados orientada a objectos pode ser definida, de um modo geral,
como sendo uma extensão de dois conceitos já bastante conhecidos e divulgados: As
linguagens orientadas a objectos, por exemplo o C++ e um sistema de gestão de bases
de dados.
Um sistema OODBMS, conjuga as principais características destes dois
sistemas, herdando da programação orientada a objectos, as noções de Objecto,
Abstracção de Tipo de Dados, Métodos, Mensagens, Herança e Identidade de cada
Objecto; das bases de dados relacionais, pode usar as características de Persistência,
Transacções, Recuperação, Segurança. Pesquisa, Performance, etc.
Orientação a Objectos
O Objecto
O principal componente do paradigma de orientação a objectos é o objecto. O
Objecto pode ser do tipo primitivo, por exemplo os números inteiros (2,6,8,...),
correspondendo a valores simples, ou do tipo complexo, normalmente definidos pelo
programador, correspondendo a variáveis com uma maior ou menor complexidade
interna, podendo conter vários dados (variáveis), bem como estruturas de programação
no seu interior.
Exemplo de um objecto:
Um objecto que pretende representar a informação respeitante a um aluno:
{Número, Nome, Curso, Morada, telefone, ... }
Cada objecto tem um determinado tipo (Type), denominado class. Sendo que
cada objecto individual de um determinado tipo ou classe é denominado instância. Ao
conjunto de funções e operadores que podem agir sobre uma determinada classe,
chama-se Métodos.
Todos os objectos estão encapsulados, isto é, a estrutura interna de um
determinado objecto não é visível ao utilizador desse objecto, sabendo apenas que o
objecto pode realizar determinadas funções (Métodos). Por exemplo, podem ser
aplicados os seguintes métodos ao objecto alunos: Aprovar_Aluno, Matricular_Aluno
Pág. 4
etc. O código que implementa os métodos está contido dentro do próprio objecto e pode
utilizar a representação interna do objecto para efectuar a sua função.
A principal vantagem do encapsulamento é permitir alterações na representação
interna dos objectos, sem implicar que se tenha que alterar as aplicações que usem esses
mesmos objectos. Obviamente que uma alteração na representação interna de um
determinado objecto, implicará as alterações correspondentes no código que implementa
os métodos existentes para esse objecto. O conceito de encapsulamento, permite ver o
objecto como tendo duas componentes: Memória Privada e Interface Publico:
A memória privada é constituída pelas variáveis ou atributos do objecto que
representam o seu estado interno. Estas variáveis estão escondidas do utilizador, mas
visível para o código que implementa os diversos métodos desse objecto. Este conceito
aplica-se aos sistemas Orientados a Objectos Puros. Quer dizer que a maior parte dos
sistemas orientados a objectos permitem que o programador veja alguns dos atributos
do objecto partindo do seu exterior.
O Interface Publico consiste na definição da interface entre o objecto e o
programador, basicamente entrada e saída de dados de e para os métodos existentes no
objecto. O código que implementa este interface (implementa os métodos) também não
é visível ao programador. O interface Publico faz parte da definição da classe do
objecto, estando presente apenas no objecto que define a classe e não em cada uma das
instâncias dessa classe.
Os métodos ou acções sobre objectos, são activados usando um sistema de
mensagens, funcionando estas como chamadas a funções ou procedimentos em que o
alvo é identificado. Por exemplo, suponha-se que se pretende escrever o aluno A na
cadeira X, então poderia existir uma mensagem (com uma sintaxe hipotética) para o
alunos X, fazendo com que ele passe a estar matriculado nem uma determinada cadeira :
A Matricular (X) ou Matricular(A,X)
Cada objecto definido tem uma identidade ou identificação única, a que
podemos chamar “Object ID” ou identificador de objecto. O identificador do objecto
poderá ser usado na base de dados como sendo um ponteiro para o objecto a que se
refere. Nesta abordagem, não é necessário que cada objecto tenha uma chave candidata
ou primária, pelo que podem existir dois objectos virtualmente iguais, sendo apenas
distinguidos pelo seu identificador de objecto.
Pág. 5
A utilização do identificador de objecto, permite criar no modelo objectorelacional, a noção de hierarquia, podendo então um determinado objecto ter um ou
mais atributos que são referências a outros objectos.
Hierarquias das Classes
Nesta abordagem, existe o que podemos chamar hierarquia de classes, sendo esta
hierarquia definida por:
Por exemplo, podemos dizer que a classe de objectos Y é uma subclasse de X, se
e só se todos os objectos de Y forem objectos de X. Do mesmo modo podemos dizer
que X é uma superclasse de Y. Neste caso, os objectos da classe Y, vão herdar (Noção
de herança) as variáveis e métodos que se aplicam á classe X. Como consequência deste
facto, podemos utilizar um objecto do tipo Y sempre que é permitido o uso de um
objecto do tipo X. A herança pode ser simples ou múltipla, isto é, uma determinada
classe pode ser a subclasse de várias superclasses em simultâneo. A herança de
variáveis é denominada herança estrutural; a herança de métodos é denominada
herança comportamental. A possibilidade de aplicar os mesmos métodos a diferentes
classes (desde que uma seja superclasse da outra) é chamada de polimorfismo.
Pág. 6
O Modelo Objecto - Relacional do Oracle 8
Sendo um dos principais sistemas de gestão de bases de dados existente no
mercado, o Oracle na sua versão 8 introduz uma nova abordagem de funcionamento
com vista á implementação do seu novo modelo Objecto – Relacional. Este modelo
pretende ser um sistema de base de dados orientada a objecto, sendo contudo baseado
no actual modelo relacional.
Usando a opção “object option” do Oracle 8, este transforma-se num sistema
Objecto - Relacional (ORDBMS), permitindo ao utilizador definir tipos de dados
complexos – Objectos – definindo a sua estrutura, bem como definindo o seu modo de
funcionamento – Métodos. Estes novos tipos de dados (objectos) podem agora ser
usados no tradicional modelo relacional, praticamente do mesmo modo como são
utilizados os tipos de dados pré definidos do sistema Oracle (Números, Cadeias de
Caracteres, datas, etc).
Objectos em Oracle
Um objecto em oracle é estruturado da mesma forma que os objectos nas linguagens
de programação orientadas a objectos, permitindo que uma entidade real seja
representada por objecto contendo todos os seus atributos. Deste modo podem-se
referenciar três componentes presentes num objecto:
?? Nome: Representa o tipo de dados no modelo da base de dados.
?? Atributos: Todos os dados existentes dentro do objecto, representando a sua
estrutura bem como o seu estado. Os atributos podem ser de tipo de dados
standard do Oracle ou mesmo outros objectos.
?? Métodos: Operações sobre o objecto, que podem ser escritos em PL/SQL sendo
guardados na própria base de dados ou escritos noutra linguagem como por
exemplo o C++ e guardados externamente.
Definição de objectos
Como exemplo pode ser usada um caso concreto de um objecto. Uma entidade
real “aluno”, pode ser representada pela sua informação base:
Pág. 7
-
Número do Aluno
Nome
BI
Data de Nascimento
.....
Morada
.....
Um objecto deste tipo poderá ser definido como sendo:
CREATE TYPE Morada AS OBJECT (
Rua
VARCHAR(70),
Cidade
VARCHAR(40),
Codigo_Postal
VARCHAR(40),
Pais
VARCHAR(20),
Telefone
VARCHAR(10),
..... );
CREATE TYPE Aluno AS OBJECT (
Numero
NUMBER,
Nome,
BI
VARCHAR(10),
Data_Nascimento
DATE,
... ,
Contacto
MORADA,
.... );
Uma vez criados os objectos, estes podem ser usados de igual modo como os
tipos de dados já existentes no Oracle, para a criação de uma base de dados relacional,
por exemplo uma base de dados de alunos matriculados:
CREATE TABLE Matriculas (
Identificação ALUNO,
Ano_Lectivo NUMBER,
Data_Matricula
DATE );
Neste caso a tabela Matriculas é uma tabela de uma base de dados relacional,
com a particularidade de conter numa das suas colunas um objecto, sendo esta coluna
denominada Coluna Objecto.
Pág. 8
Métodos
Um tipo especial de método é o Método Construtor, que permite criar novas
instâncias de um determinado tipo de objecto. O método construtor é uma função,
devolvendo como resultado uma nova instância do objecto. Os seus parâmetros são o
nome e tipo dos atributos do objecto a ser criado.
O nome deste método corresponde por defeito ao nome do tipo do objecto a ser
criado. Por exemplo para a criação de um novo aluno teríamos:
Aluno (
12345,
“Filipe Caldeira”
“9267646”,
28/01/1971,
.... ,
Morada ( “Quinta do Bosque Lt 127 5ºDP”, “Viseu”, “3500 Viseu”, ”Portugal”,
“09367065981”, ....);
)
Métodos de comparação
Sendo uma operação fundamental no funcionamento de uma base de dados, o
Oracle já contém funções de comparação para os seus tipos de dados padrão, por
exemplo é possível sem necessidade de nenhuma operação especial, comparar dois
valores numéricos. Com a criação de objectos, surge a necessidade de comparar dois
objectos distintos, sendo necessário neste caso construir um ou mais de métodos que
permitam comparar estes objectos. Para resolver esta situação, o Oracle 8 põe á
disposição do utilizador dois métodos: Métodos do tipo map e do tipo order.
O método do tipo map, usa as funcionalidades já existentes para a comparação
de tipos padrão, usando os atributos do objecto como factores da comparação. O método
order, usa a lógica interna do objecto para efectuar a comparação entre dois objectos
diferentes (do mesmo tipo), devolvendo um valor correspondente ao tipo de ordem, por
exemplo 1 se o segundo objecto for maior que o primeiro. Na definição do objecto,
apenas se pode definir um dos dois tipos de ordenação mencionados. Caso não seja
especificado nenhum método de comparação, o motor de base de dados apenas pode
concluir se dois objecto são iguais, nada podendo dizer sobre a sua ordem de
relacionamento.
Pág. 9
Tabelas de Objectos (Object Tables)
Na aproximação objecto-relacional do oracle 8, os objecto são guardados no
formato habitual das tabelas relacionais oracle. A uma tabela contendo objecto foi dados
o nome de object table, permitindo aceder aos dados dos objectos de uma forma
relacional, utilizando duas formas distintas:
-
Uma tabela apenas com uma coluna, em que cada registo é um objecto
diferente.
-
Uma tabela com várias colunas, em que cada atributo do objecto ocupa uma
coluna independente.
Os objectos que aparecem numa linha da tabela, são chamados “row objects”,
sendo aqueles que aparecem numa coluna chamados “column objects”.
Referências
Do mesmo modo que no modelo relacional, tem que ser dados algum tipo de
tratamento ás relações “muitos para um”. No modelo relacional, são usadas chaves
estrangeiras para manter a consistência da base de dados. No modelo objecto relacional
o tipo de relação “muitos para um” é tratado usando Referências, isto é, o oracle atribui
a cada objecto (objecto row), um identificador único e inalterável, chamado “object
identifier”. Existe um tipo de dados pré-definido, chamado REF, que permite que um
objecto seja referenciado por outros objecto ou por uma tabela. As referências podem
ser usadas para visualizar ou modificar o objecto a que ela se refere ou para obter uma
cópia desse mesmo objecto. As únicas alterações que podem ser feitas a uma referência
são de a pôr a apontar para outro objecto do mesmo tipo ou para um valor nulo (Null).
Object view:
Como as Vistas (View) do tradicional modelo relacional, podemos agora criar
um tipo diferente de vistas: As vistas objecto (Object view), que como as suas
antecessoras não passam de tabelas virtuais, neste caso, tabelas objecto virtuais. O
oracle 8 usa as referências de cada objecto para criar as vistas de objecto, permitindo
aceder ás tabelas de uma forma mais personalizada. Por exemplo, pode-se usar uma
vista objecto para aceder apenas a um determinado conjunto de atributos de um objecto.
Pág. 10
Tipos de Referências
Scoped REF’s – Elemento do tipo REF que contém apenas referências para objectos do
tipo object table.
Dangling REF’s – Referência que pode estar a apontar para um objecto que já não
existe ou cujos privilégios foram alterados. Usando a função IS DANGLING o oracle
permite saber se uma determinada referência está nestas condições.
Dereferencing REF’s – Modo de aceder a objectos do Tipo REF. O Operador utilizado
para esta operação é DEREF.
Uma referência para um determinado objecto, pode ser obtida seleccionando
esse objecto da tabela e aplicando o operador REF.
Dados do Tipo Colecção
O Oracle 8 dispõe de um tipo de dados que pode conter um número indefinido
de objectos de um determinado tipo. Os tipos de dados colecção podem ser do tipo array
ou do tipo tabela, correspondendo a tipos de dados Varray ou Nested Tables.
Varray
Um array é um conjunto ordenado de elementos do mesmo tipo, sendo que cada
elemento desse array têm associado um número (index) correspondente á sua posição
nesse mesmo array. O tamanho do array, ou seja o seu número de elementos pode ser
variável, mas é exigido pelo oracle que seja definido o seu número máximo quando da
criação do array.
A seguinte declaração cria um tipo de dados novo, baseado no tipo Array:
CREATE TYPE Lista AS VARRAY(8) OF NUMBER;
Este novo tipo de dados chamado Lista, pode agora ser utilizado, como tipo de dados
para uma qualquer coluna de uma tabela, um tipo de dados para um atributo de um
objecto ou ainda como uma variável em PL/SQL.
Pág. 11
Nested Tables
Uma tabela do tipo “nested table”, é um conjunto de dados não ordenados, todos
pertencentes ao mesmo tipo de dados. Estas tabelas são constituídas por apenas uma
coluna, que poderá ser de um tipo de dados standard ou mesmo por um tipo de dados
definido pelo utilizador – um objecto. Sendo uma tabela de dados, pode ser visualizada
de duas formas, mostrando apenas o objecto ou mostrando várias colunas cada uma com
seu atributo do objecto presente na tabela.
CREATE TYPE Lista AS TABLE OF NUMBER;
Este tipo de dados pode ser utilizado nas mesmas situações que o VARRAY,
isto é, como tipo de dados de uma coluna de tabela, como atributo de objectos ou como
variável.
Varrays Vs Nested Tables
Existem algumas diferenças entre estes dois tipos de dados dos quais se podem
destacar as seguintes:
-
Os Varrays são estruturas ordenadas e as nested tables não.
-
As nested tables podem conter um conjunto de elementos virtualmente
infinito, podendo crescer ou diminuir consoante as necessidades.
Contrariamente os Varrays são estruturas mais rígidas, isto é, temos que
definir sempre o número máximo de elementos que estes podem conter. Em
contrapartida os Varrays são mais eficientes em termos de ocupação de
espaço, pelo que a sua utilização deverá ser aconselhada sempre que se possa
definir um número de elementos máximo.
-
Os Varrays não podem ser pesquisados, ou seja, não podemos aplicar querys
neste tipo de dados. No caso das nested tables, podemos aplicar querys sobre
os seus elementos o que poderá ser útil em várias situações.
De um modo geral, caso a ordenação e o número máximo de elementos não
sejam condições muito importantes, devem-se usar nested tables sempre que
pretendemos efectuar pesquisas nestes dados e deve-se usar Varrays quanto podemos
tratar a colecção de dados como um todo com índices para cada um dos elementos.
Pág. 12
Uma estrutura de dados no Modelo Objecto-relacional
Usando um sistema de gestão de bases de dados, pretende-se gerir a inscrição de
alunos nas várias cadeiras ao longo do curso, bem como guardar informação sobre todas
as avaliações realizadas pelo alunos em cada uma dessas cadeiras. O problema em
questão pode ser representado pelo seguinte esquema. Um aluno é identificado
univocamente pelo seu número de alunos, sendo necessário guardar para cada aluno,
vários dados como o seu nome, morada, telefone, etc. Não se pretende com este
exemplo ser muito exaustivo nos dados necessários para a resolução do problema, mas
apenas se pretende mostrar a estrutura das tabelas. Cada aluno poderá estar ou ter estado
inscrito a uma ou mais cadeiras, sendo que para cada cadeira o aluno poderá realizar
várias avaliações que deverão também ser guardadas.
Aluno
{ Dados do Aluno }
Cadeiras
Cadeira 1 – 10-10-1997 – 1 – {Lista de Avaliações}
.
.
.
Cadeira n – 04-10-1998 – 1 – {Lista de Avaliações}
Época 1 – 1997 Época 2 – 1997 Época 3 – 1997 Época 1 – 1998 Época 2 – 1998 -
Frequência - 25-01-1998 - 4 val.
Exame Normal - 10-07-1998 - 8 val.
Exame Recurso - 16-09-1998 - 9 val.
Frequência - 12-02-1999 - 7 val.
Exame Normal - 23-07-1999 - 12 val.
Época 1 – 1998 - Frequência - 08-02-1999 - 8 val.
Época 3 – 1998 - Exame Recurso - 03-09-1999 - 14 Val.
Analisando os dados necessários para a resolução deste problema, chega-se a um
conjunto de tabelas organizadas segundo o modelo relacional. Cada tabela poderá estar
relacionada com outra(s), usando o conceito de chave estrangeira.
Pág. 13
Estrutura de Dados no Modelo Relacional:
A tabela alunos é uma das tabelas base de toda esta estrutura de dados,
fornecendo a sua chave primária (Naluno) a outras tabelas para servir ai de chave
estrangeira.
Tabela de Alunos:
CREATE TABLE Alunos (
NAluno
Nome
Ano_Ingresso
Ano
Rua1
Cpostal1
Cidade1
Telefone11
Telefone12
Rua2
Cpostal2
Cidade2
Telefone21
Telefone22
PRIMARY KEY (Numero)
);
NUMBER,
VARCHAR(100),
NUMBER,
NUMBER,
VARCHAR(100),
VARCHAR(50),
VARCHAR(50),
VARCHAR(12),
VARCHAR(12),
VARCHAR(100),
VARCHAR(50),
VARCHAR(50),
VARCHAR(12),
VARCHAR(12),
É necessário que exista informação sobre quais as cadeiras existentes, isto é,
quais as cadeiras a que o aluno pode estar inscrito. Para resolver esta situação é criada
uma tabela que contém todas as cadeiras existentes.
Tabela de Cadeiras Existentes:
CREATE TABLE Cadeiras (
Cod_Cadeira
NUMBER,
Ano
NUMBER,
Nome
NUMBER,
Creditos
NUMBER,
PRIMARY KEY(Codigo)
);
A relação Alunos<->Cadeiras é implementada usando uma tabela em que é
ligado o Número de Aluno e o código da cadeira como chave primária. Estes valores
são chaves estrangeiras das tabelas Alunos e cadeiras, fazendo com que apenas possa
Pág. 14
existir uma linha desta tabela se o Aluno indicado existir assim como se existir a cadeira
indicada.
Cadeiras de cada Aluno;
CREATE TABLE Aluno_Cadeira (
NAluno
NUMBER REFERENCES Alunos,
Cod_Cadeira
NUMBER REFERENCES Cadeiras,
DataInsc
DATE,
Aprovado
NUMBER,
PRIMARY KEY (Naluno,Cod_Cadeira)
);
Para definir a relação Alunos<->Cadeira<->Avaliações, é usada uma nova tabela
cuja chave primária é constituída pelo número do aluno, código da cadeira, ano_lectivo
e época de avaliação. As chaves estrangeiras presentes nesta tabela referem-se a dados
existentes na tabela anterior, isto é, apenas permite que seja introduzida uma avaliação a
um aluno/Cadeira que exista na tabela de cadeiras por aluno, ou seja, o aluno está
inscrito a essa cadeira.
Avaliação por cadeira:
CREATE TABLE Cadeira_Avaliacao (
Naluno
NUMBER REFERENCES Aluno_Cadeira,
Cod_Cadeira
NUMBER REFERENCES Aluno_Cadeira,
Ano_Lectivo
NUMBER,
Epoca
NUMBER,
Desc_Aval
VARCHAR(50),
Data
DATE,
Nota
NUMBER,
PRIMARY KEY (Naluno, Cod_Cadeiram, Ano_Lectivo, Epoca)
);
Esta estrutura poderá ser melhorada completando os dados necessários em cada
tabela (informação pertinente a guardar). Por outro lado existe informação que está a ser
duplicada, como por exemplo as épocas de avaliação e a sua descrição. Deveria existir
uma tabela de dados onde fossem guardada essa informação, servindo depois como
chave estrangeira para a tabela Cadeira_Avaliação. Não foram contempladas estas
alterações pois não se pretende resolver completamente o problema mas sim mostrar a
estrutura de dados a implementar e usar esta estrutura como ponto de comparação com o
mesmo problema resolvido usando o método objecto-relacional e implementado no
Oracle 8 usando nested tables, que é apresentado de seguida.
Pág. 15
Estrutura de dados no Modelo Objecto - Relacional:
Usando uma definição prévia dos tipos de dados a serem usados, permite que se possa
definir objectos que usem este tipo de dados, mesmo antes de eles terem sido
completamente definidos. Funciona basicamente como a declaração forward do C++.
Definição Inicial de Todos os Tipos de dados a serem usados.
CREATE TYPE Aluno ;
CREATE TYPE Endereco ;
CREATE TYPE Telefones ;
CREATE TYPE Cadeira_Disponiveis ;
CREATE TYPE Cadeiras ;
CREATE TYPE Lista_Cadeiras ;
CREATE TYPE Avaliacao ;
CREATE TYPE Lista_Avaliacoes ;
De modo a permitir que cada aluno possa ter definidos até cinco número de
telefone diferentes por cada endereço fornecido, é definido o tipo de dados Telefones
como um array de 5 elementos, sendo cada elemento um campo de texto de
comprimento 12. Definiu-se este tipo de dados utilizando um array, porque o número
máximo de telefones a guardar pode ser claramente definido, assim como não será
necessário efectuar pesquisas nos dados introduzidos.
CREATE TYPE Telefones AS VARRAY(5) OF VARCHAR(12) ;
O objecto endereço, permite uma maior simplicidade na posterior definição do
objecto Aluno pois este objecto irá conter toda a informação necessária a cada um dos
endereços definidos, incluindo uma lista de números de telefone para cada um dos
endereços.
CREATE TYPE Endereco AS OBJECT (
Rua
VARCHAR(100),
Cpostal
VARCHAR(50),
Cidade
VARCHAR(50),
Tel
REF TELEFONES
);
Pág. 16
É criado um objecto Cadeiras_Disponiveis, contendo a informação necessária á
identificação de cada cadeira que o aluno pode frequentar e propor-se a avaliação. Estes
objectos serão guardados numa tabela a que podemos chamar uma tabela auxiliar, pois
irá permitir por exemplo (na aplicação a desenvolver) escolher a cadeira em que cada
aluno se pretende e pode matricular.
CREATE TYPE Cadeiras_Disponiveis AS OBJECT (
Cod_Cadeira
NUMBER,
Ano
NUMBER,
Nome
NUMBER,
Creditos
NUMBER
);
Com os dois objectos seguintes, Cadeiras e Lista_cadeiras, pretende-se vir a
implementar as relações entre alunos / cadeiras / Avaliações.
O Objecto Lista_cadeiras é definido como sendo uma nested table, pelo que cada
objecto deste tipo irá conter as cadeiras a que cada aluno se matriculou (relação AlunosCadeiras). Do mesmo modo cada Objecto desta lista irá conter no seu interior outra
objecto (Lista_Avaliações), também implementado como uma nested table onde estão
todas as avaliações a que o alunos se foi submetendo para esse objecto (cadeira).
CREATE TYPE Cadeiras AS OBJECT (
Cadeira
REF Cadeiras_Disponiveis,
Data1Insc
DATE,
Aprovado
NUMBER,
Avaliacoes
Lista_Avalicaoes
);
CREATE TYPE Lista_Cadeiras AS TABLE OF Cadeiras ;
O Objecto do tipo Avaliação, irá conter a informação de cada avaliação que o
aluno realizou a uma determinada cadeira. Sendo a lista de avaliações a cada cadeira
implementada como uma nested table.
Pág. 17
CREATE TYPE Avaliacao AS OBEJCT (
Ano_Lectivo
NUMBER,
Epoca
NUMBER,
Desc_Aval
VARCHAR(50),
Data
DATE,
Nota
NUMBER
);
CREATE TYPE Lista_Avaliacoes AS TABLE OF Avalicao ;
O Objecto do tipo aluno será neste caso o principal objecto de toda esta
estrutura, contendo a informação de cada aluno, salientado que cada endereço é um
objecot definido anteriormente. As cadeiras a que o aluno está matriculado também são
definidas aqui como sendo um objecto do tipo Lista_cadeiras. Portanto podemos ver o
conceito de “objecto dentro de objecto”. Neste caso dentro de cada elemento da Lista de
cadeiras ainda podemos encontrar um novo objecto contendo a lista das avaliações a
essa cadeira. Foi também introduzido um método que irá permitir comparar dois alunos,
neste caso será implementado utilizando o número de alunos nessa comparação,
permitindo então por exemplo ordenar os alunos por ordem numérica.
CREATE TYPE Aluno AS OBJECT (
NAluno
NUMBER,
Nome
VARCHAR(100),
Ano_Ingresso
NUMBER,
End_Aulas
ENDERECO,
End__Ferias
ENDERECO,
Cadeiras_Mat
Lista_Cadeiras,
ORDER MEMBER FUNCTION
Ordena_Alunos (X IN Aluno) RETURN INTEGER,
);
Nesta estrutura de dados poderiam ser implementado vários métodos, como por
exemplo a pesquisa de cadeiras feitas pelo aluno, cadeiras por fazer, média das cadeiras
já feitas, etc. Neste exemplo vou apenas apresentar o método que permite comparar
dois alunos usando o seu número como termo de comparação.
Pág. 18
Definição do método Ordena_Alunos:
CREATE OR REPLACE TYPE BODY Aluno AS
ORDER MEMBER FUNCTION
Ordena_Alunos (X IN Alunos) RETURN INTEGER IS
BEGIN
RETURN NAluno – X.Naluno
END;
END;
Criação das Tabelas de Suporte:
Uma vez definido o tipo de dados a usar, é necessário criar as tabelas que irão
servir de suporte á informação.
A tabela que irá conter as cadeiras (Objectos do tipo Cadeira) a que o aluno se
poder inscrever é definida do seguinte modo:
CREATE TABLE Tab_Cadeiras OF Cadeiras_Disponiveis
( Cod_Cadeira PRIMARY KEY) ;
Do mesmo modo vamos definir a tabela que irá conter os alunos e as relações
para cadeiras/avaliações.
CREATE TABLE Tab_Alunos OF Alunos (
PRIMARY KEY (Naluno)
)
NESTE TABLE Lista_Cadeiras STORE AS Tab_L_Cadeiras ;
ALTER TABLE Tab_L_Cadeiras ADD (
SCOPE FOR (Cadeira) IS tab_Cadeiras
)
NESTED TABLE Lista_Avaliacoes STORE AS Tab_L_Aval );
A tabela de alunos (Tab_Alunos), irá conter tosos os objecto do tipo aluno,
sendo que uma das suas colunas é um ponteiro para uma nested table (Tab_L_Cadeiras)
que contém as cadeiras a que o aluno está matriculado. Foi feita uma alteração á tabela
Tab_L_Cadeiras, de modo a que esta nested table também contenha uma coluna que
aponte para outra nested table que contem os dados referentes á avaliação dessa cadeira.
Pág. 19
Conclusão
Podemos verificar que o uso do modelo Objecto - Relacional poderá na grande
maioria dos casos facilitar o desenho da estrutura da base de dados, estando as relações
entre objectos reais, encapsuladas no interior de cada objecto da base de dados. Neste
caso, os dados ficam melhor estruturados que no modelo relacional, pois embora
fisicamente as relações estejam feitas usando tabelas diferentes, o utilizador apenas
poderá utilizar a tabela principal Alunos que contém toda a informação necessária. A
sintaxe da criação de tipos de dados e de tabelas poderá conter algumas falhas, pois não
me foi possível ter acesso a um sistema Oracle 8 com a opção de objectos.
Esta abordagem da Oracle poderá ser considerada como um grande avanço na
área das bases de dados, facilitando o seu desenho e principalmente, facilitando a
posterior construção de aplicações, pois muito código poderá ser embebido no interior
de cada objecto.
Bibliografia
?? Apontamentos das Aulas da Cadeira
?? An Introduction to Database Systems – 6ª Edição
C. J. Date
Addison-Wesley Publishing Company
?? A First Course in Database Systems
Jeffrey D. Velman, Jennifer Widom
Prentice Hall
?? Manuais “On-Line” do Oracle 8
?? Pesquisa na Internet,
Pág. 20

Concepção e Administração de Bases de Dados

Transcrição

Documentos relacionados

O apriorismo kantiano Documento PDF

Imprimir/PDF

Imprimir/PDF

Exposição do imóvel

Energia mecânica. Energias cinética e potencial.

Imprimir/PDF

Trompe l`oeil, le coeur et la raison, Maria de Fátima

Flags of the world

Dicionário Ilustrado de Termos Artísticos VOL-01

CRÉDITO CRÉDITO HABITAÇÃO - CONSTRUÇÃO