Upload
jonatas-narciso
View
230
Download
0
Embed Size (px)
Citation preview
©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
©Silberschatz, Korth and Sudarshan (modificado)9.1.2Database System Concepts
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).
©Silberschatz, Korth and Sudarshan (modificado)9.1.3Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)9.1.4Database System Concepts
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, é:
©Silberschatz, Korth and Sudarshan (modificado)9.1.5Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)9.1.6Database System Concepts
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)
©Silberschatz, Korth and Sudarshan (modificado)9.1.7Database System Concepts
Decomposição Decomposição livros-flatlivros-flat para a 4NF para a 4NF
©Silberschatz, Korth and Sudarshan (modificado)9.1.8Database System Concepts
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.
©Silberschatz, Korth and Sudarshan (modificado)9.1.9Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)9.1.10Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)9.1.11Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)9.1.12Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)9.1.13Database System Concepts
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.
©Silberschatz, Korth and Sudarshan (modificado)9.1.14Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)9.1.15Database System Concepts
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;
©Silberschatz, Korth and Sudarshan (modificado)9.1.16Database System Concepts
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;
©Silberschatz, Korth and Sudarshan (modificado)9.1.17Database System Concepts
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’)
©Silberschatz, Korth and Sudarshan (modificado)9.1.18Database System Concepts
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’))
©Silberschatz, Korth and Sudarshan (modificado)9.1.19Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)9.1.20Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)9.1.21Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)9.1.22Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)9.1.23Database System Concepts
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.
©Silberschatz, Korth and Sudarshan (modificado)9.1.24Database System Concepts
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.
©Silberschatz, Korth and Sudarshan (modificado)9.1.25Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)9.1.26Database System Concepts
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)
©Silberschatz, Korth and Sudarshan (modificado)9.1.27Database System Concepts
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’
©Silberschatz, Korth and Sudarshan (modificado)9.1.28Database System Concepts
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) )
©Silberschatz, Korth and Sudarshan (modificado)9.1.29Database System Concepts
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’)
©Silberschatz, Korth and Sudarshan (modificado)9.1.30Database System Concepts
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