Linguagem BD + capacidades OO qVariante da representação OO das encomendas EncomTipo = RECORDOF( e#: int, inclui: SETOF( IQTipo ), cliente: ClienteTipo.

Apresentação em tema: "Linguagem BD + capacidades OO qVariante da representação OO das encomendas EncomTipo = RECORDOF( e#: int, inclui: SETOF( IQTipo ), cliente: ClienteTipo."— Transcrição da apresentação:

1 Linguagem BD + capacidades OO qVariante da representação OO das encomendas EncomTipo = RECORDOF( e#: int, inclui: SETOF( IQTipo ), cliente: ClienteTipo ) INCLUI CLIENTEE# ITEMQUANT NOMEI# NOMEENDEREÇOBALANÇO ENCOMTIPO NOMEI# NOMEI# qHipótese de representação relacional correspondente CREATE TABLE ENCOMTIPOCREATE TABLE IQTIPOCREATE TABLE CLIENTE ( E# NUMERIC, ( ITEM ITEMTIPO, ( NOME CHAR(20), INCLUI SETOF( IQTIPO ), QUANT NUMERIC ) ENDEREÇO CHAR(60), CLIENTE CLIENTETIPO ) BALANÇO NUMERIC )

2 Classe = Relação qextensões ao modelo relacional necessárias suporte para colunas compostas -cada valor de CLIENTE é um triplo que existe na tabela CLIENTETIPO suporte para tabelas como valores de atributos (caso de INCLUI ) suporte para métodos associados às tabelas (ex: calc_quant_total ) qproblemas estes objectos são linhas em tabelas, não encapsulados (nome de CLIENTE obtido por caminho ENCOMTIPO.CLIENTE.NOME) o domínio de E# é NUMERIC, um tipo de dados, restrição intemporal; mas o domínio de CLIENTE é CLIENTETIPO, uma tabela variante no tempo e não um verdadeiro tipo de dados embora a imagem seja a de objectos que contêm objectos, de facto a partilha de subobjectos é feita por apontadores e qualquer alteração num cliente é logo reflectida em todas as encomendas que o refiram (diferente de uma chave externa, que é um valor) — não se tem relações, mas tabelas com valores e apontadores

3 Problemas ?????E# NOME 1327Micro NOMEE# 1327Micro se é isto, então lá se vai a hierarquia; mais vale ficar no modelo relacional se é isto, qual o nome da 2ª coluna? - como fazer a junção com o nome do cliente em CLIENTETIPO ? CLIENTE = (NOME) - de que classe é o resultado da projecção? que métodos se lhe aplicam? calc_quant_total não pode ser projecção de ENCOMTIPO sobre o número da encomenda e o nome do cliente -dá ( E#, (NOME) ) ou antes (E#, NOME) Conclusão: erro está em se equacionar classe com relação

4 Outra representação qrepresentação de rectângulos CREATE DOMAIN RECTANGLE REP (... ) ; -- REP é uma representação eficiente CREATE FUNCTION RECTANGLE -- construtor ( A FLOAT, B FLOAT, C FLOAT, D FLOAT ) RETURNS ( RECTANGLE ) AS BEGIN; DECLARE R RECTANGLE; R.X1:= A; R.X2:= B; R.Y1:= C; R.Y2:= D; RETURN( R ); END; CREATE FUNCTION OVERLAP -- determina sobreposição ( R1 RECTANGLE, R2 RECTANGLE ) RETURNS( BOOLEAN ); AS BEGIN;... code... END; CREATE TABLE RECTANGLES -- tabela com rectângulos na 2ª coluna ( RECTID..., R RECTANGLE,..., UNIQUE( RECTID ) ); SELECT RECTID -- pergunta que processa rectângulos FROM RECTANGLES WHERE OVERLAP( R, RECTANGLE( 0, 1, 0,1 ) );

5 Classe = Domínio qextensões - os sistemas relacionais têm que suportar convenientemente domínios de atributos, que podem ser tipos de dados de complexidade arbitrária, definidos pelo utilizador (o modelo sempre suportou domínios — baseia-se neles) qcomparação construção OO básica: classe de objectos, i.e., tipo de dados abstracto definido pelo utilizador construção relacional básica: domínio de atributo, i.e., tipo de dados encapsulado definido pelo utilizador (embora muitos sistemas comerciais não o suportem) — só as funções pre-definidas podem manipular internamente os valores complexos (como as funções de string manipulam os valores CHAR ) -classe = domínio (são a mesma coisa) instância = elemento do domínio colecção = conjunto de valores numa coluna qos domínios podem conter qualquer objecto: vectores, listas, documentos, fotografias,... domínios encapsulam, relações não hierarquias de classes e polimorfismo têm o seu lugar na construção de domínios ao nível relacional, não há necessidade de identificadores de objectos

6 Caminho promissor ono futuro (SQL3?), SQL mais tipos de dados abstractos definidos pelo utilizador (generalização dos domínios) -podem ser utilizados para enriquecer as colunas -requerem a capacidade de chamar os métodos respectivos nas instruções de pesquisa SQL herança -funciona sobre uma hierarquia de classes -as classes não têm extensão; só as tabelas oBD inteligentes misturam ou integram várias extensões -orientação por objectos -regras dedutivas (sistemas periciais e Inteligência Artificial) -pesquisa de informação (em texto, pesquisa booleana) -multimedia (texto, imagem, voz, video) com pesquisa por conteúdo Conclusão: preferível equacionar classe com domínio