©Silberschatz, Korth and Sudarshan (modificado)9.1.1Database System Concepts Capítulo 9: BDs Objecto-Relacional Relações imbricadas Tipos complexos e objectos

©Silberschatz, Korth and Sudarshan (modificado)9.1.1Database System Concepts

Capítulo 9: BDs Objecto-RelacionalCapítulo 9: BDs Objecto-Relacional

Relações imbricadas Tipos complexos e objectos Criação de valores complexos e de objectos Funções, procedimentos e métodos em SQL Comparação entre os vários modelos


Modelo de Dados Objecto-RelacionalModelo de Dados Objecto-Relacional

Parte do modelo relacional, e generaliza-o introduzindo noções de objectos e formas de lidar com tipos complexos.

Permite que os atributos tenham valores de tipos complexos, incluindo valores não atómicos.

Aumenta a expressividade, sem perder as principais vantagens do modelo relacional (incluindo o acesso declarativo aos dados).

É compatível com as linguagens relacionais existentes (o que torna este modelo bastante apelativo para sistemas de bases de dados comerciais).


Relações imbricadasRelações imbricadas

Motivação: Permitir domínios não atómicos (atómico indivisível) Exemplo de domínios não atómicos:

Conjunto de inteiros Conjunto de tuplos

Permite uma modelação mais intuitiva em aplicações com tipos complexos

Definição informal: Permitir relações em todo o local onde antes se permitiam

valor atómicos — relações dentro de relações Manter base matemática do modelo relacional Viola a 1ª forma normal


Exemplo de relação imbricadaExemplo de relação imbricada

Numa biblioteca cada livro tem: um título, um conjunto de autores, uma editora, um conjunto de keywords

Uma instância da relação livros, que não está na 1ª Forma Normal, é:


Versão 1NF de relação imbricadaVersão 1NF de relação imbricada

Na 1NF a instância da relação livros seria:

livros-flat


Decomposição 4NF de Nested RelationsDecomposição 4NF de Nested Relations

Remover redundâncias de livros-flat assumindo as seguintes dependências multivalor: título autor título keyword título nome-pub, pub-branch

Com decomposição de livros-flat para a 4NF obtêm-se os esquemas: (título, autor) (título, keyword) (título, nome-pub, pub-branch)


Decomposição Decomposição livros-flatlivros-flat para a 4NF para a 4NF


Problemas com a 4NFProblemas com a 4NF

Os esquemas na 4NF precisam de junção para grande parte das perguntas.

A relação na 1NF, livros-flat, que corresponde à junção das relações na 4NF: Elimina a necessidade de junções, Mas perde a correspondência biunívoca entre tuplos e entidades. E tem imensas redundâncias

Neste caso, a relação imbricada parece ser mais natural.


Tipos complexos no SQL:1999Tipos complexos no SQL:1999

As extensões do SQL para suportar tipos complexos incluem: Colecções e objectos de grande dimensão

Relação imbricadas são um exemplo de colecções Tipos estruturados

Tipos com atributos composto (registos) Herança Orientação por objectos

Incluindo identificadores de objectos e referências A apresentação que se segue baseia-se no standard

SQL:1999 (com algumas extensões) Não está (ainda) completamente implementado em nenhum

sistema comercial Mas algumas das features existem já na maioria dos sistemas

O Oracle já suporta boa parte do que se vai apresentar


ColecçõesColecções Tipo set (não existente no SQL:1999)

create table livros (…..conj-keyword setof(varchar(20))……)

Sets são um exemplo de colecções. Outros exemplo incluem: Arrays (existentes no SQL:1999 e no Oracle)

E.g. array-autores varchar(20) array[10] Permite-se o acesso a elementos, da forma habitual em

arrays: – E.g. array-autores[1]

Multisets ou Bags (não existente no SQL:1999) I.e., colecções não ordenadas onde um elemento pode

aparecer mais que uma vez Relações imbricadas são conjuntos de tuplos

O SQL:1999 (e o Oracle 9i) suporta arrays de tuplos


Objectos grandesObjectos grandes

Tipos para objectos grandes clob: Character large objects book-review clob(10KB) blob: binary large objects

image blob(10MB) movie blob (2GB)

Quer o ODBC quer o JDBC fornecem mecanismos para aceder a grandes objectos por partes pequenas de cada vez


Tipos estruturadosTipos estruturados

No SQL:99, podem-se declarar (e usar) Tipos Estruturados create type Editor as object

(nome varchar(20), branch varchar(20))

create type Livro as object (título varchar(20), array-autores varchar(20) array [10], data-publ date, editor Editor, conj-keyword setof(varchar(20)))

Nota: a declaração do setof não é suportada no SQL:1999. No entanto o Oracle suporta atributos cujo tipo é table of...

Usando um array para os autores, pode-se guardar a ordem Podem-se criar tabelas com tipos estruturados. create table livros of Livro


Tipos estruturados (Cont.)Tipos estruturados (Cont.)

Os tipos estruturados permitem a representação directa de atributos compostos.

Podem-se também usar, em SQL:1999, tipos anónimos para definir atributos compostos E.g. Pode-se omitir a declaração do tipo Editor e, em vez

disso, usar a seguinte declaração no tipo Livro editor row (nome varchar(20),

branch varchar(20))

As colecções permitem a representação directa de atributos multivalor.


Tipos estruturados (Cont.)Tipos estruturados (Cont.) Podem-se criar as tabelas sem criar tipos intermédios:

create table livros (título varchar(20), array-autores varchar(20) array[10], data-publ date, editor row (nome varchar(20), branch varchar(20)) conj-keyword setof(varchar(20)))

Podem-se incluir métodos na definição dos tipos: create type Empregado as object ( nome varchar(20), salario integer) method anual return integer

O corpo dum método é definido separadamente create method anual for Empregado begin return self.salario * 14; end


Exemplo em OracleExemplo em Oracle

> create type autor as object ( nome varchar(10) );/

> create type conj_autores as table of autor;/

> create type editorT as object(nome varchar(10), branch varchar(20));

/> create type livro as object (

titulo varchar(20),autores conj_autores,data_publ date,editor editorT);

/> create table livros of livro nested table autores store as tabaut;


Exemplo em OracleExemplo em Oracle

> create type Empregado as object (nome varchar(20),

salario number,member function anual return number);

/

> create type body Empregado is member function anual return number is begin

return salario*14;

end;end;/

> create table empregados of Empregado;


Criação de valores para tipos Criação de valores para tipos complexoscomplexos

Os valores para tipos complexos são construídos recorrendo a funções (ou métodos) de construção E.g. Editor(‘McGraw-Hill’, ‘New York’) Nota: o valor retornado não é um objecto

No SQL:1999 podem-se definir funções de construção E.g.

create function Editor (n varchar(20), b varchar(20)) returns Editorbegin

set nome =n;set branch =b;

end Todo o tipo estruturado tem um construtor usado supletivamente, mas

podem-se definir outros. Os valores de tipos row podem-se construir usando listas de valores entre

parêntesis E.g. dado o tipo row (nome varchar(20),

branch varchar(20))pode-se atribuir um valor usando, e.g. (`McGraw-Hill’,`New York’)


Criação de valores (Cont.)Criação de valores (Cont.) Construção de Arrays array [‘Silberschatz’,`Korth’,`Sudarshan’] Atributos com conjuntos

set(v1, v2, …, vn) Para criar um tuplos da relação livros

(‘Compilers’, array[`Smith’,`Jones’], Editor(`McGraw-Hill’,`New York’),

set(`parsing’,`analysis’))

Para inserir esse tuplo na relação livros insert into livros

values (`Compilers’, array[`Smith’,`Jones’], Editor(‘McGraw Hill’,`New York’ ), set(`parsing’,`analysis’))


HerançaHerança Considere a seguinte definição de tipo para pessoas:

create type Pessoa as object (nome varchar(20),

morada varchar(20)) not final;

Pode-se usar herança para definir os tipos para estudante e professor

create type Estudante under Pessoa (grau varchar(20), departamento varchar(20)); create type Docente under Pessoa (salário integer, departamento varchar(20));

Os subtipos podem redefinir os métodos usando (explicitamente) na definição do tipo overriding method em vez de method


Herança MúltiplaHerança Múltipla Num sistema com herança múltipla, pode-se definir monitor como:

create type Monitor under Estudante, Docente

Para evitar conflito entre duas ocorrências de departamento (departamento onde estuda vs departamento onde lecciona), podem-se renomear os atributos

create type Monitor under Estudante with (departamento as dep-estud), Docente with (departamento as dep-docente)

Nem o SQL:1999, nem o Oracle, suportam herança múltipla Mas há generalizações do SQL que consideram herança múltipla


Herança em TabelasHerança em Tabelas A herança em tabelas permite que um objecto tenha múltiplos

tipos, deixando que uma entidade pertença simultaneamente a mais do que uma tabela.

E.g. create table pessoas of Pessoa Podemos definir as subtabelas estudantes e docentes:

create table estudantes of Estudante under pessoas

create table docentes of Docente under pessoas

Cada tuplo numa subtabela pertence (implicitamente) à supertabela correspondente


Herança em tabelas: papéisHerança em tabelas: papéis

Herança múltipla em tabelas pode ser usada para modelizar os vários papéis que uma entidade pode ter (e.g. trabalhador do banco: do quadro ou a contrato; caixa, ou gerente)

Deixa que um valor tenham múltiplos tipos, sem ter necessariamente um tipo mais específico. e.g., um objecto pode estar simultaneamente nas (sub-)tabelas de

estudante e de docentes, sem necessidade da subclasse monitor (que ficaria debaixo de estudantes e de docentes)

Podem-se adicionar ou retirar papéis a um objecto, adicionando ou removendo tuplos nas sub-tabelas

NOTA: O Oracle obriga a que todos os valores tenham um tipo mais específico


Herança em tabelas: requisitos de consistênciaHerança em tabelas: requisitos de consistência

Requisitos de consistência para subtabelas e supertabelas. Cada tuplo da supertabela (e.g. pessoas) só pode corresponder, no

máximo, a um tuplo em cada uma das subtabelas (e.g. estudantes e docentes)

Requisito adicional no SQL:1999:

Todos os tuplos com o mesmo valor num atributo herdado têm que ser derivados de um só tuplo (inserido numa só tabela). Ou seja, cada entidade tem que ter um tipo mais específico Não se pode ter um tuplo em pessoas que corresponda

simultaneamente a um tuplo de estudantes e a um tuplo de docentes

Por outras palavras, em SQL:1999 a herança em tabelas “implementa” especializações disjuntas.


Herança em tabelas: alternativas para armazenamentoHerança em tabelas: alternativas para armazenamento

Alternativas para armazenamento:1. Armazenar nas subtabelas apenas os atributos locais e a chave

primária da supertabela Os atributos herdados são derivados através de junções com a

supertabela

2. Cada tabela armazena todos os atributos (herdados e locais) O acesso a todos os atributos de um tuplo pode ser mais

eficiente: não requer junções Se todas as entidades tiverem um tipo mais específico, então

cada um dos tuplos é guardado numa só tabela– Caso contrário, i.e. se uma entidade puder ter mais que um

tipo mais específico, pode haver redundância.


Tipos referênciaTipos referência

As linguagens de objectos permitem criar e referenciar objectos. No SQL:1999

Podem-se referenciar tuplos Cada referência diz respeito a tuplo de uma tabela específica. I.e. cada

referência deve limitar o escopo a uma única tabela


Declaração de Referências em SQL:1999Declaração de Referências em SQL:1999

E.g. definir o tipo Departamento com atributo nome e atributo presidente que é uma referência para o tipo Pessoa, tendo a tabela pessoas como escopo

create type Departamento as object ( nome varchar(20), presidente ref Pessoa scope pessoas)

A tabela departamentos pode ser criada como usual:

create table departamentos of Departamento Em SQL:1999 pode-se omitir a declaração de scope na

definição do tipo, passando-a para a criação da tabela, da seguinte forma:

create table departamentos of Departamento (presidente with options scope pessoas)


Inicialização de referências no OracleInicialização de referências no Oracle

Para criar um tuplo com uma referência, cria-se primeiro o tuplo com uma referência null, actualizando depois a referência com a função ref(p):

E.g. para criar um departamento com nome DI e presidente Pedro:insert into departamentos values (`DI’, null)update departamentos set presidente = (select ref(p)

from pessoas as p where nome=`Pedro’)

where nome = `DI’


Inicialização de referências no SQL:1999Inicialização de referências no SQL:1999 O SQL:1999 não suporta a função ref(). Em vez disso exige a

declaração de um atributo especial para guardar o identificador dum objecto

O atributo com o identificador é declarado usando ref is na criação da tabela: create table pessoas of Pessoa ref is oid system generated Aqui, oid é um nome dum atributo.

Para obter a referência para um tuplo usa-se esse atributos. Por exemplo: select p.oid

(em vez de select ref(p) )


Geração de identificadoresGeração de identificadores

O SQL:1999 permite que os identificadores sejam gerados pelo utilizador O tipo do identificador tem que ser declarado como para qualquer

outro atributo da tabela E.g.

create type Pessoa (nome varchar(20) morada varchar(20)) ref using varchar(20) create table pessoas of Pessoa ref is oid user generated

Quando se cria um tuplo, tem que se dizer qual o valor do identificador (que é sempre dado como primeiro atributo): insert into pessoas values

(‘01284567’, ‘Pedro’, `Lisboa’)


Geração de identificadores (Cont.)Geração de identificadores (Cont.) Pode depois usar-se o valor inserido como referência, ao inserir

tuplos noutras tabelas Evita pergunta para saber qual o identificador:

E.g. insert into departamentos values(`DI’, `02184567’)

Também é possível usar uma chave primária como identificador. Para isso usa-se ref from, e declara-se a referência como sendo derived

create type Pessoa (nome varchar(20) primary key, morada varchar(20)) ref from(nome)create table pessoas of Pessoa ref is oid derived

Documents

©Silberschatz, Korth and Sudarshan (modificado)9.1.1Database System Concepts Capítulo 9: BDs Objecto-Relacional Relações imbricadas Tipos complexos e objectos