Bancos de Dados Objeto-Relacionais

(1)

Bancos de Dados

Objeto-Relacionais

BDOR Abril 2008

Prof. Ricardo Ramos

CEFET-PI

Pós-graduação Lato Sensu

(2)

Evolução dos SGBDs

Sistemas de Arquivos _{SGBD Hierárquico} (1ª Geração) AAAA SGBD em Rede (1ª Geração) AAAA SGBD Relacionais (2ª Geração) BBBB SGBD Orientado a Objetos (3ª Geração) CCCC

(3)

Evolução dos SGBDs

A AA

A - Final da década de 1960 (SGBDs de legado) SGBD Hierárquico: IMS da IBM

SGBD de Rede: IDSII, IDMS, IMAGE, VAX-DBMS, etc B

B B

B - Final da década de 1970 e início da década de 1980

C C C

C - Final da década de 1980 e início da década de 1990

D D D

(4)

Classificação dos SGBDs

- Dados bem estruturados;

Banco de Dados ConvencionaisBanco de Dados ConvencionaisBanco de Dados ConvencionaisBanco de Dados Convencionais

- Tipos de dados simples (inteiros, reais, caracteres...);

- Transações simples e curtas; - Acesso através de chaves;

(5)

Classificação dos SGBDs

- Grande volume de dados estruturados; Banco de Dados Não ConvencionaisBanco de Dados Não ConvencionaisBanco de Dados Não ConvencionaisBanco de Dados Não Convencionais

- Tipos de dados complexos (textos, gráficos, imagens, vídeos e sons);

- Transações longas; - Acesso não trivial;

- Exemplo de aplicações: projeto assistido por computador (CAD), CASE e SIG;

(6)

Matriz de Stonebraker

Dados complexos Dados simples

III

I

Sem consulta

IV

II

Com consulta

(7)

Matriz de Stonebraker

I I I I –––– Dados simples sem consultaDados simples sem consultaDados simples sem consultaDados simples sem consulta

- Este quadrante representa aplicações que lidam apenas com dados bastantes simples e não têm qualquer exigência para consultas

ad-hoc

;

- Exemplo: um editor de texto;

- Na realidade, essas aplicações não são de modo algum aplicações de banco de dados no sentido comum desse termo;

(8)

Matriz de Stonebraker

I I I I –––– Dados simples sem consulta (cont)Dados simples sem consulta (cont)Dados simples sem consulta (cont)Dados simples sem consulta (cont)

- O “SGBD” que melhor serve as suas necessidades é apenas o gerenciador de arquivos interno, fornecido como parte do sistema operacional.

(9)

Matriz de Stonebraker

III

I

Gerenciadores de Arquivos Sem consulta

IV

II

Com consulta

(10)

Matriz de Stonebraker

II II II II –––– Dados simples com consultaDados simples com consultaDados simples com consultaDados simples com consulta

- Este quadrante representa aplicações que têm uma exigência de consulta

ad-hoc,

mais ainda lidam apenas com dados bastantes simples;

- A maioria das aplicações comerciais de hoje se encaixa nesse quadrante, e elas são razoavelmente bem aceitas por SGBDsSGBDsSGBDsSGBDs relacionaisrelacionaisrelacionais tradicionais (ou, relacionais pelo menos, SQL);

(11)

Matriz de Stonebraker

II II II II –––– Dados simples com consulta (cont)Dados simples com consulta (cont)Dados simples com consulta (cont)Dados simples com consulta (cont) - Linguagem de consulta;

- Ferramentas de interfaces;

-Performance (gerenciamento de transações consistentes);

(12)

Matriz de Stonebraker

III

I

IV

II

(SGBDR) Com consulta

(13)

Matriz de Stonebraker

III III III III –––– Dados complexos sem consultaDados complexos sem consultaDados complexos sem consultaDados complexos sem consulta

- Este quadrante representa aplicações com exigências complexas de dados e processamento, mas nem uma exigência de consultas

ad-hoc

;

- Exemplo: aplicações CAD;

- Os SGBDOOsSGBDOOsSGBDOOsSGBDOOs atuais se destinam principalmente a esse segmento de mercado (os produtos de SQL tradicionais tendem a não realizar um trabalho muito bom sobre aplicações deste quadrante);

(14)

Matriz de Stonebraker

III III III III –––– Dados complexos sem consulta (cont)Dados complexos sem consulta (cont)Dados complexos sem consulta (cont)Dados complexos sem consulta (cont)

- Necessidade de rotinas específicas para manipulação dos dados complexos;

- Grande integração com uma linguagem de programação;

- Performance na atualização de variáveis persistentes.

(15)

Matriz de Stonebraker

III

(SGBDOO)

I

IV

II

(16)

Matriz de Stonebraker

IV IV IV IV –––– Dados complexos com consultaDados complexos com consultaDados complexos com consultaDados complexos com consulta

- Este quadrante representa aplicações com necessidade de dados complexos e consultas ocasionais sobre seus dados;

- Exemplo: um banco de dados contendo slides digitalizados de 35mm, com uma consulta típica sendo “obter imagens do pôr do sol tiradas em Teresina”;

(17)

Matriz de Stonebraker

IV IV IV IV –––– Dados complexos com consulta (cont)Dados complexos com consulta (cont)Dados complexos com consulta (cont)Dados complexos com consulta (cont)

- Um SGBDORSGBDORSGBDOR é necessário para aplicações onde SGBDOR se encaixam neste quadrante;

- Nos próximos anos, a maioria das aplicações de recursos humanos poderá se expandir para incluir fotografias de empregados, gravações sonoras (mensagens faladas) e coisas desse tipo.

- Os SGBDORsSGBDORsSGBDORs surgiram como uma maneira de se SGBDORs estenderem as capacidades de SGBDRs com algumas das características que apareceram em SGBDOOs.

(18)

Matriz de Stonebraker

IV IV IV IV –––– Dados complexos com consulta (cont)Dados complexos com consulta (cont)Dados complexos com consulta (cont)Dados complexos com consulta (cont)

-Linguagem de consulta estendida à objetos complexos (SQL3);

- Ferramentas de visualização não convencionais; - Otimizador de consultas.

(19)

Matriz de Stonebraker

III

(SGBDOO)

I

IV

(SGBDOR)

II

(20)

Características Fundamentais

de um SGBDOR

As principais motivações que há por trás do desenvolvimento de SGBDORs têm origem na incapacidade dos SGBDs de legado e dos SGBDRs, de fazer face aos desafios de novas aplicaçõesnovas aplicaçõesnovas aplicações.novas aplicações

As novas aplicações se encontram basicamente em áreas que envolvem vários tipos de dados, necessitando uma extensão dos tipos de dadosextensão dos tipos de dadosextensão dos tipos de dadosextensão dos tipos de dados básicos.

(21)

Características Fundamentais

de um SGBDOR

Exemplos de novas aplicações::::

- imagens obtidas por satélite ou na previsão do tempo;

- dados complexos não-convencionais em projetos de engenharia;

- informações sobre o genoma biológico; - dados sobre a poluição da água e do ar.

(22)

Características Fundamentais

de um SGBDOR

Portanto, existe uma clara necessidade de se projetarem bancos de dados que possam desenvolver, manipular e manter os objetos objetos objetos objetos complexos

complexoscomplexos

complexos que surgem de tais aplicações.

Além disso, torna-se necessário lidar com informações digitalizadas que representam streams (correntes) de dados de áudio e vídeo que requerem o armazenamento de BLOBs (grandes grandes grandes grandes

(23)

Características Fundamentais

de um SGBDOR

O suporte a herançaherançaherança para a criação de novos herança tipos de dados.

Por conseguinte, surgiu uma tendência de combinar as melhores características do modelo e da linguagem de dados de objetos com o modelo relacional, de modo que o mesmo possa ser estendido para lidar com as desafiadoras aplicações dos dias de hoje....

(24)

Projeto de BD para SGBDOR

Um projeto mal feito é responsável pelo fracasso de muitas aplicações.

Um bom projeto é um desafio mesmo para BD relacionais.

A maioria dos produtos são baseados no modelo E-R.

(25)

Projeto de BD para SGBDOR

Projeto E-R:::: -- identificar entidades;;;;

-- identificar atributos de cada entidade;

-- dar a cada entidade um identificador único (chave primária);

-- identificar os relacionamentos entre entidades (1:1, 1:N, M:N);

(26)

Projeto de BD para SGBDOR

Projeto E-R: : : : (cont)

-- identificar os eventuais atributos dos relacionamentos;

-- mapear o esquema E-R gerando tabelas normalizadas.

(27)

Projeto de BD para SGBDOR

Por que tantos problemas com projetos de BD? 1)

1) 1)

1) Dificuldade em ajustar o esquema

Normalizar ou desnormalizar tabelas em função de melhoria da performance analisando as consequências para o resto do esquema.

(28)

Projeto de BD para SGBDOR

Por que tantos problemas com projetos de BD? (cont)

2) 2) 2)

2) Desinteresse em seguir todos os passos do projeto

O projeto é um processo evolutivo e tem que ser revisto em diversas circunstâncias. É uma tarefa que demanda um grande esforço e é necessário uma pessoa responsável unicamente por esta

(29)

Projeto de BD para SGBDOR

3) 3) 3)

3) Projeto irreal da aplicação

Um implementador pode usar uma dada funcionalidade do SGBD para resolver vários problemas sem analisar se é um bom mecanismo ou não. Ex: triggers (gatilhos)

(30)

Projeto de BD para SGBDOR

4) 4) 4)

4) Fracasso em atingir os objetivos de performance em grandes BD

Carregar e testar grandes BD previamente para que qualquer problema de performance seja identificado a tempo de uma ação corretiva.

(31)

Projeto de BD para SGBDOR

5) 5) 5)

5) Dificuldade em capturar todo o esquema

Capturar todas as restrições do esquema, regras do tipo: “todo empregado deve trabalhar em um departamento” e todas as ações a serem tomadas em caso de falha.

(32)

Projeto de BD para SGBDOR

6) 6) 6)

6) Excesso de foco na modelagem formal da aplicação

Busca por uma ferramenta apropriada e decisão de construir uma própria depois de uma longa procura.

(33)

Projeto de BD para SGBDOR

Desafios em projetos de BDOR:

OR é um super-conjunto do relacional, os problemas são os mesmos porém mais complexos.

1) Escolher entre as várias opções:

- como implementar as tabelas empregado e como implementar as tabelas empregado e como implementar as tabelas empregado e como implementar as tabelas empregado e departamento?

departamento?departamento?

departamento? (Ver pág 28 BDOO)

a) O atributo departamento na tabela Empregado como ref(Departamento).

(34)

Projeto de BD para SGBDOR

1) Escolher entre as várias opções: (cont)

b) O relacionamento empregados da tabela Departamento como setof(ref(empregado)).

c) Ou qualquer um dos casos anteriores de outra forma.

(35)

Projeto de BD para SGBDOR

Realmente se requer arte e uma boa intuição para escolher a melhor maneira de implementar um esquema OR.

Pela riqueza do modelo, o projeto de um banco de dados OR é proporcionalmente mais difícil.

(36)

Projeto de BD para SGBDOR

Representação de dados versus procedimentos Consideremos o exemplo de datadenascimentodatadenascimentodatadenascimentodatadenascimento e idade

idadeidade

idade de um empregado (Ver pág 33 BDOO).

No modelo relacional seriam implementados dois atributos com controle de consistência entre eles.

(37)

Projeto de BD para SGBDOR

Representação de dados versus procedimentos (cont)

No OR, existe a possibilidade de implementação de procedimentos. Logo, um pode ser implementado como um atributo e o outro calculado por um procedimento e identificado quando o procedimento será executado (se na entrada do dado ou em uma consulta).

(38)

Projeto de BD para SGBDOR

Em resumo:

- projeto OR é mais difícil do que o relacional;

- são necessárias pessoas qualificadas para definir qual a melhor opção e não existem muitas no mercado;

- SGBDOR devem ser mais fáceis de usar no futuro;

(39)

Projeto de BD para SGBDOR

Em resumo: (cont)

- o esquema deve ser ajustado automaticamente pelo sistema para melhorar performance;

- o sistema deveria prevenir o usuário das conseqüências de suas escolhas em termo de performance.

(40)

Visão Geral da SQL3

A SQL é a linguagem de consulta padrão para SGBDRs.

A SQL foi especificada pela primeira vez nos anos 70, e em 1986 foi adotada como padrão ANSI e em 1987 como ISO.

Em 1999 a SQL3 acrescenta características

(SQL3

-

http://en.wikipedia.org/wiki/Sql);

Em 1992 a SQL-92 (SQL2) teve sua maior revisão.

(41)

Visão Geral da SQL3

Em SGBDORs a SQL pode ser estendida para lidar ao mesmo tempo com tabelas do modelo relacional e classes e objetos do modelo orientado a objetos.

(42)

Visão Geral da SQL3

Novos tipos de operações foram adicionados à SQL3:

--

-- A operação SIMILAR, SIMILAR, SIMILAR, SIMILAR, que permite o uso de expressões regulares para combinar com strings de caracteres;

--

-- Valores booleanos foram estendidos com UNKNOWN

UNKNOWNUNKNOWN

UNKNOWN(DESCONHECIDO) quando uma comparação não resulta nem verdadeiro nem

(43)

Visão Geral da SQL3

Novos tipos de operações foram adicionados à SQL3: (cont)

--

-- Uma nova operação importante é a recursão recursão recursão recursão linear

linearlinear

linear para especificar consultas recursivas;

Tabela_Peças(Peça 1, Peça 2) – tupla<p1, p2> sempre que a peça p1 contenha a peça p2 como componente. Uma consulta para produzir a lista de materiais para alguma peça p1 (ou seja, todas as peças componentes necessárias para produzir p1) está descrita a seguir:

(44)

Visão Geral da SQL3

WITH RECURSIVE

Lista_Materiais(Peça 1, Peça 2) As

(Select Peça 1, Peça 2, from Tabela_Peças where Peça 1 = ‘p1’ UNION ALL

Select Tabela_Peças (Peça 1), Tabela_Peças (Peça 2) from Lista_Materiais, Tabela_Peças

(45)

Visão Geral da SQL3

--

-- rolerolerole(papel), é semelhante a uma “descrição de role serviço” e está sujeito à autorização de privilprivilprivilpriviléééégiosgiosgiosgios. As verdadeiras pessoas (contas de usuários) que são designadas para um papel podem ser alteradas, mas a autorização de papéis propriamente dita não precisa ser alterada;

(46)

Visão Geral da SQL3

--

-- inclui sintaxe para especificação e uso de

triggers

como regras ativas. Eventos de

triggers

incluem as operações INSERT, DELETE e UPDATE em uma tabela. O disparo pode ser especificado como sendo antes (BEFORE) ou após (AFTER) o evento de disparo.

(47)

Visão Geral da SQL3

- A SQL3 está sendo estendida com facilidades de linguagem de programação.

- Rotinas escritas em SQL computacionalmente completa, com a plena combinação de tipos de dados e um ambiente integrado, denominam-se rotinas da SQL

rotinas da SQLrotinas da SQL rotinas da SQL.

(48)

Visão Geral da SQL3

- Para tornar computacionalmente completa a linguagem, estão incluídas na sintaxe da SQL3 as seguintes estruturas de controle de programação: CALL/RETURN, BEGIN/END, FOR/END_FOR, IF/ THEN/ELSE/END_IF, CASE/END_CASE, LOOP/

(49)

Visão Geral da SQL3

- Variáveis são declaradas utilizando-se DECLARE e atribuições são especificadas utilizando-se SET.

(50)

Visão Geral da SQL3

A SQL3 estende a (SQL2/SQL-92) para incluir funcionalidades orientadas a objetos. Novos tipos de dados incluem objetos booleanos, objetos de caracteres e objetos binários grandes (LOBs).

Em função da SQL/Fundamentos, a SQL3 admite tipos de dados definidos pelo usuário, construtores de tipo, tipos de coleção, funções e procedimentos definidos pelo usuário, suporte pra

(51)

Visão Geral da SQL3

Os objetos na SQL3 são de dois tipos:

- tipos linhastipos linhastipos linhastipos linhas, cujas instâncias são tuplas em tabelas;

- tipos abstratos de dados (TAD)tipos abstratos de dados (TAD)tipos abstratos de dados (TAD), que significam tipos abstratos de dados (TAD) quaisquer tipos gerais.

(52)

Visão Geral da SQL3

Um tipo linhatipo linhatipo linhatipo linha pode ser definido utilizando-se a sintaxe:

CREATE ROW TYPE nome (< componentes >); Exemplo 1:

CREATE ROW TYPE empempempemp (nome VARCHAR (35), idade INTERGER ); CREATE ROW TYPE compcompcomp (nomecomp VARCHAR (20), localizaçãocomp VARCHAR (20));

(53)

Visão Geral da SQL3

Tabelas podem ser criadas com base nas declarações dos tipos linhas empempempemp e compcompcompcomp.

Exemplo 2:

CREATE TABLE EmpregadoEmpregadoEmpregadoEmpregado OF TYPE empempemp; emp CREATE TABLE CompanhiaCompanhiaCompanhiaCompanhia OF TYPE compcompcompcomp;

Um atributo componente de uma tupla pode ser uma referência (REF) referência (REF) referência (REF) referência (REF) para uma tupla de uma outra(ou talvez da mesma) relação.

(54)

Visão Geral da SQL3

Exemplo 3:

CREATE ROW TYPE empregoempregoempregoemprego (EmpregadoEmpregadoEmpregadoEmpregado REF (empempemp), emp

Companhia Companhia Companhia

Companhia REF (compcompcompcomp));

CREATE TABLE EmpregoEmpregoEmpregoEmprego OF TYPE empregoempregoemprego;emprego

A SQL3 utiliza notanotanotanotaçççção de doisão de doisão de doisão de dois pontos para construir expressões de caminho que se referem aos componentes de tuplas.

Exemplo 4:

(55)

Visão Geral da SQL3

Identificadores de objeto (Identificadores de objeto (Identificadores de objeto (Identificadores de objeto (OIDsOIDsOIDs)))) podem ser OIDs explicitamente declarados e acessados.

Exemplo 5:

CREATE ROW TYPE empempempemp (nome CHAR (35), idade INTENGER, Id REF (empempemp));emp

Valores de identificador de objeto podem ser gerados pelo sistema.

Exemplo 6:

CREATE TABLE Empregado OF TYPE emp VALUES FOR Id ARE SYSTEM GENERATED;

(56)

Visão Geral da SQL3

Tipos Abstratos de Dados (Tipos Abstratos de Dados (Tipos Abstratos de Dados (Tipos Abstratos de Dados (TADsTADsTADs))))TADs

Na SQL3, é fornecido um componente semelhante à definição de classe através do qual o usuário pode criar um tipo definido pelo usuáááário com sua própria especificação de comportamento e estrutura interna.

Exemplo 7:

CREATE TYPE <nome> (

(57)

Visão Geral da SQL3

Exemplo 8:

CREATE TYPE PessoaPessoaPessoaPessoa (nome VARCHAR (40), identidade INTEGER);

Um TAD tem inúmeras funções definidas pelo usuário a ele associadas. A sintaxe é:

Exemplo 9:

(58)

Visão Geral da SQL3

HeranHeranHeranHeranççççaaaa

- Todos o atributos são herdados;

- A ordem dos subtipos na clausula UNDER determina a hierarquia de herança;

- Uma instância de um subtipo pode ser utilizada em todos os contextos em que uma instância de supertipo seja utilizada.

(59)

Visão Geral da SQL3

SobrecargaSobrecargaSobrecargaSobrecarga

- Um subtipo pode redefinir qualquer função que esteja definida em seu supertipo, com a restrição de que a assinatura seja a mesma.

ResoluResoluResoluResoluçççção de Funão de Funão de Funão de Funççççõesõesõesões

- Quando uma função é chamada, a melhor combinação é selecionada com base nos tipos de todos os argumentos.

(60)

Visão Geral da SQL3

Tipos ColeTipos ColeTipos ColeTipos Coleççççõesõesõesões

- A SQL3 suporta construtores para tipos de coleção, que podem ser utilizadas para se criarem estruturas aninhadas para objetos complexos.

Exemplo 11: