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

Apresentação em tema: "©Silberschatz, Korth and Sudarshan (modificado)9.1.1Database System Concepts Capítulo 9: BDs Objecto-Relacional Relações imbricadas Tipos complexos e objectos."— Transcrição da apresentação:

1 ©Silberschatz, Korth and Sudarshan (modificado)9.1.1Database System Concepts Capí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

2 ©Silberschatz, Korth and Sudarshan (modificado)9.1.2Database System Concepts Modelo 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).

3 ©Silberschatz, Korth and Sudarshan (modificado)9.1.3Database System Concepts Relaçõ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

4 ©Silberschatz, Korth and Sudarshan (modificado)9.1.4Database System Concepts Exemplo 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, é:

5 ©Silberschatz, Korth and Sudarshan (modificado)9.1.5Database System Concepts Versão 1NF de relação imbricada Na 1NF a instância da relação livros seria: livros-flat

6 ©Silberschatz, Korth and Sudarshan (modificado)9.1.6Database System Concepts Decomposiçã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)

7 ©Silberschatz, Korth and Sudarshan (modificado)9.1.7Database System Concepts Decomposição livros-flat para a 4NF

8 ©Silberschatz, Korth and Sudarshan (modificado)9.1.8Database System Concepts Problemas 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.

9 ©Silberschatz, Korth and Sudarshan (modificado)9.1.9Database System Concepts Tipos 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

10 ©Silberschatz, Korth and Sudarshan (modificado)9.1.10Database System Concepts Colecções Tipo set (não existente no SQL:1999) create table livros ( ….. conj-keyword setof(varchar(20)) …… ) n Sets são um exemplo de colecções. Outros exemplo incluem: X Arrays (existentes no SQL:1999 e no Oracle) v E.g. array-autores varchar(20) array[10] v 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) v I.e., colecções não ordenadas onde um elemento pode aparecer mais que uma vez X Relações imbricadas são conjuntos de tuplos v O SQL:1999 (e o Oracle 9i) suporta arrays de tuplos

11 ©Silberschatz, Korth and Sudarshan (modificado)9.1.11Database System Concepts Objectos grandes n Tipos para objectos grandes X clob: Character large objects book-review clob(10KB) X blob: binary large objects image blob(10MB) movie blob (2GB) n Quer o ODBC quer o JDBC fornecem mecanismos para aceder a grandes objectos por partes pequenas de cada vez

12 ©Silberschatz, Korth and Sudarshan (modificado)9.1.12Database System Concepts Tipos 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

13 ©Silberschatz, Korth and Sudarshan (modificado)9.1.13Database System Concepts 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.

14 ©Silberschatz, Korth and Sudarshan (modificado)9.1.14Database System Concepts Tipos estruturados (Cont.) n 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))) n Podem-se incluir métodos na definição dos tipos: create type Empregado as object ( nome varchar(20), salario integer) method anual return integer n O corpo dum método é definido separadamente create method anual for Empregado begin return self.salario * 14; end

15 ©Silberschatz, Korth and Sudarshan (modificado)9.1.15Database System Concepts Exemplo 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;

16 ©Silberschatz, Korth and Sudarshan (modificado)9.1.16Database System Concepts Exemplo 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; /  create table empregados of Empregado;

17 ©Silberschatz, Korth and Sudarshan (modificado)9.1.17Database System Concepts Criação de valores para tipos complexos 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 Editor begin 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’)

18 ©Silberschatz, Korth and Sudarshan (modificado)9.1.18Database System Concepts 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’))

19 ©Silberschatz, Korth and Sudarshan (modificado)9.1.19Database System ConceptsHeranç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

20 ©Silberschatz, Korth and Sudarshan (modificado)9.1.20Database System Concepts Heranç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

21 ©Silberschatz, Korth and Sudarshan (modificado)9.1.21Database System Concepts Heranç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

22 ©Silberschatz, Korth and Sudarshan (modificado)9.1.22Database System Concepts Heranç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

23 ©Silberschatz, Korth and Sudarshan (modificado)9.1.23Database System Concepts Heranç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.

24 ©Silberschatz, Korth and Sudarshan (modificado)9.1.24Database System Concepts Heranç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.

25 ©Silberschatz, Korth and Sudarshan (modificado)9.1.25Database System Concepts Tipos 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

26 ©Silberschatz, Korth and Sudarshan (modificado)9.1.26Database System Concepts Declaraçã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)

27 ©Silberschatz, Korth and Sudarshan (modificado)9.1.27Database System Concepts Inicializaçã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’

28 ©Silberschatz, Korth and Sudarshan (modificado)9.1.28Database System Concepts Inicializaçã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))

29 ©Silberschatz, Korth and Sudarshan (modificado)9.1.29Database System Concepts Geraçã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’)

30 ©Silberschatz, Korth and Sudarshan (modificado)9.1.30Database System Concepts 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