Apostila BDOO - Complementar

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
Banco de Dados Orientado a Objetos
BANCO DE DADOS II 
PROF. WELTON RODRIGUES
*
Histórico
1986 SQL-86 (SQL1) - padrão originalmente desenvolvido pela ANSI, posteriormente adotado pela ISO
1989 SQL-89 - extensão do SQL-86 publicado em 89
OMG - criação do Object Management Group
1991 ODMG - criação do Object Database Management Group
1992 SQL-92 (SQL2) - padrão aprovado pela ISO
1993 ODMG 1.2
1996 SQL-92/PSM - extensão do SQL-92
- provê linguagem computacionalmente completa
1997 ODMG 2.0
1999 SQL:1999 (SQL3) - padrão aprovado em 1999 pela ISO (após 7 anos de trabalho)
- "SQL orientada a objeto"
- SGBDs comerciais oferecem parte do SQL:1999
2000 ODMG 3.0
2004 SQL-2003
Aprimoramento de SQL:1999
Introdução de XML
*
Problemas
Abandono gradual do padrão (SQL-92)
MOOSE - major object-oriented SQL extensions:
inúmeras propostas acadêmicas e industriais para estender SQL-92 com conceitos OO
Aplicações presas a:
extensões OO ad-hoc oferecidas pelos SGBDs comerciais, ou
um modelo de dados arcaico (o modelo relacional / 1NF)
Solução:
SQL:1999
*
1. Crítica ao Modelo Relacional
SGBDs Relacionais (SGBDRs) - Virtudes:
Estrutura:
1NF é simples
Integridade referencial é útil e semanticamente poderosa
Comportamento:
SQL é declarativa (não navegacional)
SQL manipula tabelas (conjuntos de tuplas)
Aplicações convencionais:
"casamento" adequado com SQL através de cursores
sistemas já consolidados no mercado
boa performance
 muitos anos de pesquisa e aprimoramento
eficiência: otimização de consultas, gerenciamento de transações
Robustez
Padronização
*
1. Crítica ao Modelo Relacional
SGBDs Relacionais (SGBDRs) - Problemas:
Problemas conceituais:
Estrutura:
falta de suporte para valores complexos (ou aderência a 1NF):
força a criação de tabelas artificiais
falta de suporte para OIDs:
força a definição de chaves artificiais
Comportamento:
SQL não oferece nenhum recurso para encapsulamento
Outros:
SQL-92 não possui recursão
Aplicações OO: "descasamento" completo entre SQL e OO-PLs
*
1. Crítica ao Modelo Relacional
Motivação para BDOO
atender os requisitos de aplicações não convencionais:
engenharia e manufatura (CAD/CAM, CIM)
aplicações científicas (Meteorologia, Genética, etc.)
aplicações envolvendo dados geográficos (GIS)
aplicações multimídia / hipermídia
...
acompanhar a evolução de LPs
*
1. Crítica ao Modelo Relacional
SGBDs Orientado a Objetos (SGBDOO)
 modelo de dados mais rico
adequado ao mercado de aplicações não convencionais
pior desempenho, se comparado com SGBDR
heterogeneidade a nível de modelo e de capacidades de consulta e atualização
*
1. Crítica ao Modelo Relacional
SGBDs Objeto-Relacional (SGBDOR)
combina as melhores características do modelo de objetos no modelo relacional
modelo rico + eficiência no gerenciamento de dados
tecnologia relativamente nova
exemplos: Oracle 11g, Informix, DB2, Postgresql
*
Limitações do Modelo Relacional
Crítica do Modelo Relacional
Novas aplicações necessitam de novos conceitos, principalmente tipos complexos de dados e encapsulamento
Vários desses novos conceitos existem há muitos anos em linguagens de programação orientadas a objeto 
Um Exemplo de Motivação
Nosso problema é de BD espacial. Trata-se de achar os retângulos superpondo o quadrado de lado de tamanho um
*
Exemplo de motivação
Condições para a superposição: x1 <= 1 e y1 <= 1; X2 >= 0 e y2 >= 0, não importando o quadrante
As condições para a superposição são válidas se x2 > x1 (ou ponto P2 à direita de ponto P1)
*
Exemplo de Motivação
Solução relacional
Retângulos (X1, X2, Y1, Y2)
Regra de integridade: Check (X2 > X1)
 SELECT * FROM RETANGULOS WHERE (x1 <= 1 AND y1 <= 1) AND (x2 >= 0 AND y2 >=0)
*
Exemplo de Motivação
Três problemas com esta solução
P1. Esquema obscuro
P2. Consulta obscura
P3. Execução com provável baixo desempenho. Como indexar a tabela Retângulos? 
Queremos:
Representar um ponto como ponto
Escrever uma consulta legível
Desempenho
Solução: BDOO
*
Solução BDOO: Esquema
 
Retângulo
Ponto
2
N
{Ponto2.X > Ponto1.X}
X
Y
sobrepoe_quadrado
_de_lado_um();
...
Definido_por
Repositório:
Retângulos
*
Linguagem de Consulta OO, Estilo SQL
Quais os retângulos que sobrepõem um quadrado de lado um? 
Select r.ponto1, r.ponto2 From Retangulos r 	 Where r.sobrepoe_quadrado_de_lado_um()
Basta ler, para entender!
sobrepoe_quadrado_de_lado_um() é indexável, 
como qualquer coluna de tabela
*
Encapsulamento
Encapsulamento das condições de sobreposição
Boolean sobrepoe_quadrado_lado_um() 
{ 	If ((self.ponto1.x1 <= 1 and self.ponto1.y1 <= 1)
 and 			 
 (self.ponto2.x2 >= 0 and self.ponto2. y2
 >=0))
 then return true
 else return false; }
*
Encapsulamento
 Regra de integridade: implementada no método construtor Retangulo()
Retangulos agora torna-se um repositório de objetos da classe Retangulo
 O encapsulamento deve ser parcial, para ainda permitir interfaces estilo-SQL (Select colunax ...)
*
O Mercado de SGBDs OO
SGBD OO puro:
Versant
O2 Technology
Objectivity
Servio Logic
Object Design: ObjectStore
SGBDOR:
Oracle 11g
IBM DB2
Informix 
Incorporado pela IBM
Postgresql
*
BDOO – Padrão ODMG
ODMG - Object Database Management Group
ODL - Object Definition Language, como o CREATE TABLE do SQL
OQL - Object Query Language, tenta imitar SQL no framework OO
*
Framework
ODMG imaginou que vendedores de SGBD OO implementariam uma linguagem OO como C++ com extensões (OQL), que permitisse o programador transferir dados entre o banco de dados e a linguagem hospedeira de forma fácil.
*
ODMG
Fundação: setembro de 1991
Objetivo: definir um padrão para garantir a portabilidade das aplicações escritas seguindo o modelo OO
Presidente: R. G. G. Cattell
Web site: www.odmg.org
Versões: ODMG 1.2 (1993), ODMG 2.0 (março 1997), ODMG 3.0 (janeiro 2000)
Padrões definidos pelo ODMG:
modelo de objetos
linguagem de definição de dados - ODL
linguagem de consulta - OQL
acoplamento com C++ , Smalltalk e Java
*
ODMG: Modelo de Objetos
Literal = valor + comportamento
Classificação dos literais:
Atomic: corresponde aos tipos de dados simples
Strutured: criado usando o construtor Struct
collection criado com os construtores
	Set<t>, Bag<t>, List<t>, Array<t>, Dictionary<k,t>
	onde t é o tipo de objetos ou literais na coleção
e k é o tipo da chave, no caso de dicionários
(note que t pode ser um tipo de objeto ou literal)
*
ODMG: Modelo de Objetos
Objeto = OID + nome + estado + comportamento
OID = identificador interno gerado pelo sistema, não sendo visível ao usuário
nome:
é opcional
deverá ser único no BD a que o objeto pertence
os objetos nomeados servirão de pontos de entrada para o BD
estado = valores das propriedades do objeto, incluindo:
atributos do objeto
relacionamentos (binários) entre o objeto e outros objetos
comportamento = operações permitidas sobre o objeto
*
ODMG: Modelo de Objetos
Fábrica = objeto utilizado para gerar ou criar outros objetos
possui necessariamente uma operação que gera novos objetos (como novos OIDs)
*
ODMG: Modelo de Objetos
Interface = definição de estrutura + assinaturas de operações
as interfaces não podem ser instanciadas, ou seja,não podem gerar conjuntos de objetos
utilizadas essencialmente para organizar as operações
*
ODMG: Modelo de Objetos
Classes = definição de estrutura + assinaturas de operações
as classes podem ser instanciadas, ou seja, podem gerar extensões - conjuntos de objetos – e definir chaves para estas extensões
a definição da estrutura inclui a especificação de:
atributos: 
simples e complexos
de referência, utilizados para representar relacionamentos 1-n entre os objetos da classe e objetos de outra classe
relacionamentos:
utilizados para representar
relacionamentos binários 1-n ou n-m entre os objetos da classe e objetos de outra classe:
permitem especificar o relacionamento inverso
não devem ser utilizados quando o relacionamento n-m possui atributos
*
ODMG: Modelo de Objetos
Herança Comportamental (via ":")
uma interface pode ser uma especialização de outras interfaces,das quais herda as operações
uma classe pode ser uma especialização de outras interfaces, das quais herda as operações
Herança Comportamental e Estrutural (via Extends)
uma classe pode ser uma especialização de apenas outra classe, da qual herda a estrutura e as operações
*
ODMG ODL
ODL é usado para definir classes persistentes, cujos objectos podem ser armazenados permanentemente no BD.
Classes ODL assemelham-se a Entity sets com relacionamentos binários, mais métodos.
*
ODL – Visão Geral
Uma Declaração de classe inclui:
Um nome para a classe.
Declaração de chaves (key) opcional.
Declaração de Extent = nome para o conjunto de objetos correntes na classe (instâncias).
Declaração de Elementos. Um element pode ser um atributo, um relacionamento, ou um método.
*
Definição de Classe
class <nome> {
	<lista de declarações de elementos, separados por ; >
}
Exemplo:
Class Estudante (extent Estudantes) {
	 attribute string name;
		attribute int idade;
}
*
Declaração de Atributos e Relacionamentos
Atributos são elementos com um tipo que não envolve classes.
		attribute <tipo> <nome>;
Relacionamentos conectam um objeto ao um ou mais outros objetos de uma classe.
		relationship <tipo> <nome>
			inverse <relationship>;
*
Relacionamentos Inversos
Suponha uma classe C que tenha um relacionamento R a uma classe D.
Então a classe D deve ter algum relacionamento S à classe C.
R e S devem ser inversos.
Se um objeto d está relacionado a um objeto c via R, então c deve estar relacionado a d via S.
*
*
Ex.: Atributos e Relacionamentos
class Bar {
	attribute string name;
	attribute string addr;
	relationship Set<Beer> serves inverse Beer::servedAt;
}
class Beer {
	attribute string name;
	attribute string manf;
	relationship Set<Bar> servedAt inverse Bar::serves;
}
*
*
Tipos de Relacionamentos
O tipo de um relacionamento é:
Uma classe, como Bar. Neste caso, um objeto com este relacionamento pode estar conectado a apenas um objeto Bar.
Set<Bar>: o objeto está conectado a um conjunto de objetos Bar.
Bag<Bar>, List<Bar>, Array<Bar>: o objeto está conectado a um bag, list, ou array de objetos Bar.
*
*
Multiplicidade dos Relacionamentos
Todos os relacionamento ODL são binários.
Relacionamentos Muitos-para-Muitos têm Set<…> para o tipo do relacionamento e seu inverso.
Relacionamentos Muitos-para-Um têm Set<…> no relacionamento do lado Um e a apenas a classe para o relacionamento do lado Muitos
Relacionamentos Um-para-Um têm classes com o tipo em ambas direções. 
*
*
Exemplo: Multiplicidade
class Drinker { …
	relationship Set<Beer> likes inverse Beer::fans;
	relationship Beer favBeer inverse Beer::superfans;
}
class Beer { …
	relationship Set<Drinker> fans inverse Drinker::likes;
	relationship Set<Drinker> superfans inverse Drinker::favBeer;
}
*
*
Exemplo2: Multiplicidade
class Drinker {
	attribute … ;
	relationship Drinker husband inverse wife;
	relationship Drinker wife inverse husband;
	relationship Set<Drinker> buddies
		inverse buddies;
}
*
*
Lidando com Relacionamentos Múltiplos
ODL não dar suporte a relacionamentos ternários.
Podemos simular relacionamentos ternários através de uma classe de “conexão”, cujos objetos representam tuplas de objetos que nós gostariamos de conectar via o relacionamento ternário.
*
*
 Classes de Conexão
Suponha que queremos conectar as classes X, Y, e Z através do relacionamento R.
Projete uma classe C, cujos objetos representam uma tripla de objetos (x, y, z) das classes X, Y, and Z, respectivamente.
Precisamos de três muitos-para-um relacionamentos de (x, y, z) para cada um de x, y, e z.
*
*
Exemplo: Classe de Conexão
Suponha que tenhamos as classes Bar e Beer, e queremos representat o preço de cada Beer em vendida em cada Bar.
Um relacionamento muitos-para-muitos entre Bar e Beer não pode ter o atributo preço como ocorre no modelo E/R.
One solution: cria-se a classe Price e uma classe de conexão BBP para representar uma tripla bar, beer, e price.
*
*
Exemplo --- Continuação
Uma vez que objetos Price são apenas números, uma melhor solução seria:
Dar aos objetos BBP um atributo price.
Usar dois relacionamentos muitos-para-um entre um objeto BBP e os objetos Bar e Beer.
*
*
Exemplo, em ODL
Definição de BBP:
class BBP {
	attribute price:real;
	relationship Bar theBar inverse Bar::toBBP;
	relationship Beer theBeer inverse Beer::toBBP;
}
Bar e Beer devem ser modificados para incluir relacionamentos, ambos chamados toBBP, e ambos do tipo Set<BBP>.
*
*
Structs e Enums
Atributos podem ter uma estrutura (com em C) ou ser uma enumeration.
Declare com
attribute [Struct ou Enum] <nome do
	struct ou enum> { <detalhes> }
	<nome do atributo>;
Detalhes são os nomes dos campos e tipos de um Struct, uma lista de constantes de um Enum.
*
*
Exemplo: Struct e Enum
class Bar {
	attribute string name;
	attribute Struct Addr
		{string street, string city, int zip} address;
	attribute Enum Lic
		{ FULL, BEER, NONE } license;
	relationship …
}
*
*
Declarações de Métodos
Uma definição de classe pode incluir declarações de métodos para a classe.
Informação consiste de:
Tipo de retorno, se algum.
Nome do método.
Argument modes e tipos (sem nomes).
Modes são in, out, e inout.
Quaisquer exceções que o método possa lançar.
*
*
Exemplo: Métodos
real cre(in string)raises(semNotas);
O método cre retorna um número real, que contém o CRE de um aluno.
cre recebe um argumento, uma string (matrícula do aluno) e não modifica este argumento.
cre pode lançar a exceção semNotas.
*
*
Tipos em ODL 
Tipos básicos: int, real/float, string, enumerated types, e classes.
Type constructors:
Struct para estruturas.
Collection types : Set, Bag, List, Array, e Dictionary ( = mapeamento de um tipo domínio type para um tipo imagem).
Tipos Relationship podem apenas ser uma classe ou um tipo collection aplicado a uma classe.
*
*
ODL Subclasses
Usual object-oriented subclasses.
Indica superclasse com extends e seu nome.
Subclasse lista apenas as propriedades únicas à mesma.
Herda as propriedades da superclasse.
*
*
Exemplo: Subclasses
Maltada é uma subclasse de beers:
class Maltada extends Beer {
	attribute string color;
}
*
Subclasses: Herança Múltipla
ODL permite herança múltipla
Conflitos são resolvidos a nível de implementação
class Anime extends Filme:Cartoon {
	attribute …
}
*
*
ODL Keys
Podem declarar chaves para uma classe.
Depois do nome da classe, adicionamos:
		(key <list of keys>)
Uma key com mais de um atributo precisa de parênteses adicionais ao redor dos atributos.
*
*
Exemplo: Keys
class Beer (key name) { …
nome é a key para beers.
class Course (key (dept,number),(room, hours)){ 
dept and number formam uma key; como também room e hours.
*
*
Extents
Para cada classe existe um extent, o conjunto de objetos existentes na classe (instâncias)
Podemos pensar o extent como uma relação cuja classe é seu esquema.
Indique extent depois do nome da classe, junto com as keys, como:
		(extent <extent name> … )
*
*
Exemplo: Extents
class Beer
	(extent Beers key name) { …
}
Convenção, usa-se singular para nomes de classes, e plural para o extent correspondente.
*
ODMG OQL: Object Query Language
Consultas a repositórios de classes - ODL 
OQL combina os aspectos declarativos da linguagem SQL com o paradigma de programação OO
Apresentação by example 
*
*
Path Expressions
Seja x um objeto da
classe C.
Se a é um atributo de C, então x.a é o valor daquele atributo.
Se r é um relacionamento de C, então x.r é o valor para o qual x está conectado por r.
Poderia ser um objeto ou um conjunto de objetos, dependendo do tipo de r.
Se m é um método de C, então x.m (…) é o resultado de aplicar m a x.
*
*
Running Example
class Sell (extent Sells) {
	attribute real price;
	relationship Bar bar inverse Bar::beersSold;
	relationship Beer beer inverse Beers::soldBy;
}
class Bar (extent Bars) {
	attribute string name;
	attribute string addr;
	relationship Set<Sell> beersSold inverse Sell::bar;
}
*
*
Running Example --- Cont.
class Beer (extent Beers) {
	attribute string name;
	attribute string manf;
	relationship Set<Sell> soldBy inverse Sell::beer;
}
*
*
Exemplo: Path Expressions
Seja s be uma variável do tipo Sell, i.e., um objeto bar-beer-price.
s.price = o preço no objeto s.
s.bar.addr = o endereço do bar que pode ser alcançado seguindo relacionamento bar em s.
Note que a cascata de pontos está OK aqui, pois s.bar é um objeto, e não uma coleção de objetos.
*
*
Exemplo: Uso Ilegal do .
Não podemos aplicar o . A uma coleção na esquerda, apenas a um único objeto.
Exemplo (ilegal), com b sendo um objeto Bar:
		b.beersSold.price
*
*
OQL Select-From-Where
Similar a SQL:
	SELECT <lista de valores>
	FROM <lista de coleções e nomes>
	WHERE <condição>
*
*
Cláusula FROM 
Cada termo da cláusula FROM é:
<collection> <member name>
Uma coleção pode ser:
O extent de alguma classe.
Uma expressão que leva a uma coleção, e.g., certas path expressions como b.beersSold .
*
*
Exemplo
Obtenha o menu do Joe’s Bar.
		SELECT s.beer.name, s.price
		FROM Sells s
		WHERE s.bar.name = “Joe’s Bar”
*
*
 Exemplo 2
Esta query também obtém Joe’s menu:
		SELECT s.beer.name, s.price
		FROM Bars b, b.beersSold s
		WHERE b.name = “Joe’s Bar”
*
*
Dica para Uso de Path Expressions
Se uma path expression denota um objeto, você estendê-lo com outro . e uma propriedade daquele objeto.
Exemplo: s, s.bar, s.bar.name .
Se uma path expression denota uma coleção de objetos, você NÃO estendê-lo, mas pode usá-lo na cláusula FROM.
Exemplo: b.beersSold .
*
*
O Result Type
Por default, o tipo do resultado de um select-from-where é um Bag of Structs.
Struct tem um campo para cada termos da cláusula SELECT. Seus nomes e tipos são obtidos do ;ultimo nome na path expression.
Se SELECT tem apenas um termo, tecnicamente o result é um one-field struct.
*
*
Exemplo: Result Type
		SELECT s.beer.name, s.price
		FROM Bars b, b.beersSold s
		WHERE b.name = “Joe’s Bar”
Tem tipo:
	Bag(Struct(name: string, price: real))
*
*
Renomeando os Campos
Para modificar os nomes dos campos, preceda-os pelo nome e : .
Exemplo:
	SELECT beer: s.beer.name, s.price
	FROM Bars b, b.beersSold s
	WHERE b.name = “Joe’s Bar”
Result type é: 
		 Bag(Struct(beer: string, price: real)).
*
*
Produzindo um Set of Structs
Adicione DISTINCT no SELECT para eliminar duplicatas.
Exemplo:
SELECT DISTINCT s.beer.name, s.price
FROM Bars b, b.beersSold s
WHERE b.name = “Joe’s Bar”
Result type é:
		Set(Struct(name: string, price: string))
*
*
Subqueries
Uma expressão select-from-where pode conter parêntesis e usado como uma subquery de várias maneiras, como:
Numa cláusula FROM, como uma coleção.
Em expressões EXISTS e FOR ALL.
*
*
Exemplo: Subquery em FROM
Encontre os fabricantes de cervejas vendidas por Joe’s:
SELECT DISTINCT b.manf
FROM (
	SELECT s.beer FROM Sells s
	WHERE s.bar.name = “Joe’s Bar”
) b
*
*
Quantificadores
Duas expressões booleanas para uso em cláusulas WHERE:
FOR ALL x IN <collection> : <condition>
EXISTS x IN <collection> : <condition>
True sss todos membros (resp. pelo menos um membro) da coleção satisfaz a condição.
*
*
Exemplo: EXISTS
Encontre todos os nomes de bares que vendem ao menos uma cerveja por mais de $5.
		SELECT b.name FROM Bars b
		WHERE EXISTS s IN b.beersSold :
			s.price > 5.00
*
*
Exemplo 2
Encontre os nome de todos os bares nos quais as únicas cervejas que eles vendem por mais de $5 são fabricadas por Pete’s.
SELECT b.name FROM Bars b
WHERE FOR ALL be IN (
	SELECT s.beer FROM b.beersSold s
	WHERE s.price > 5.00
) : be.manf = “Pete’s”
*
*
Agregações
AVG, SUM, MIN, MAX, e COUNT se aplicam a qualquer coleção onde faça sentido.
Exemplo: Encontre e atribua a x o preço médio de cervejas em Joe’s:
x = AVG(
		SELECT s.price FROM Sells s
		WHERE s.bar.name = “Joe’s Bar”
);
*
Exemplo 2: Esquema de Filmes
Class Filme 
	(extent Filmes key (tiitulo, ano))
{
	attribute string titulo; attribute integer ano; attribute integer duracao; attribute enum TipoFilme (cores, pretoebranco) tipo; relationship Set <Estrela> estrelas 
			inverse Estrela::estreladoEm; relationship Estudio produzidoPor 
			inverse Studio::produziu; float duaracaoEmHoras() raises (duracaoNãoEncontrada); void nomesEstrelas(out Set<String>); void outrosFilmes (in Estrela, out Set<Filme>) raises (notFound);
};
*
Exemplo 2: Esquema de Filmes
Class Estrela
	(extent Estrelas key nome)
{
	attribute string nome; attribute Struct End {string rua, string cidade} 						endereco; relationship Set <Filme> estreladoEm 
				inverse Filme::estrelas; 
};
*
Exemplo 2: Esquema de Filmes
Class Estudio
	(extent Estudios key nome)
{
	attribute string nome; attribute string endereco; relationship Set <Filme> produziu 
				inverse Filme::produzidoPor; 
};
*
Consultas Intra-Classe
Qual o ano do filme "E o vento levou“?
 f é uma variável do tipo Filme que "varre" o repositório Filmes (isto é, pode receber cada valor da repositório corrente Filmes)
SELECT f.ano
FROM Filmes f
WHERE f.título = "E o vento levou?"
*
Consultas Inter-Classes
Quais os nomes das estrelas do filme "Casablanca"?
Note o tratamento unificado para atributos e relacionamentos 
SELECT e.nome
FROM Filmes f, f.estrelado_por e
WHERE f.título = "Casablanca" 
For each f in Filmes do
 If f.título = "Casablanca" then
 For each e in f.estrelado_por then
 Add e.nome to output bag
*
Consultas Com Método
Quais os títulos e anos dos filmes com mais de 2 horas de duração?
Note o tratamento unificado para atributos, relacionamentos e métodos
SELECT f.título, f.ano
FROM Filmes f
WHERE f.duração_em_horas( ) > 2.0; 
/* pode ser também duração_em_horas(f) */
*
Path Expressions 
Se o denota um objeto pertencendo a uma classe C, e p é uma propriedade da classe, então o.p é o resultado de aplicar p a o 
Se p é um atributo, então o.p é o valor do atributo no objeto o 
Se p é um relacionamento, então o.p é o objeto ou coleção de objetos relacionados com o através do relacionamento p 
Se p é um método (talvez, com parâmetros), então o.p é o resultado de aplicar o método a o 
Pode ser usado o símbolo -> em lugar do ponto 
*
 
O valor de meu_filme.duração é a duração do filme, isto é, o valor do atributo duração para o objeto Filme denotado por meu_filme 
O valor de meu_filme.duração_em_horas() é um número real, a duração do filme em horas, calculada pela aplicação do método duração_em_horas() ao objeto meu_filme 
*
 
O valor de meu_filme.estrelado_por é o conjunto de objetos Estrela que estrelaram o filme meu_filme 
A expressão meu_filme.estrelas (nomes) não retorna valor (em C++, o tipo de função void). Entretanto retorna o conjunto dos nomes das estrelas de meu_filme (parâmetro de saída nomes, do tipo coleção)
O que significa meu_filme.realizado_por.nome? 
*
Expressões OQL
Estilo SQL
Select-From-Where 
A palavra-chave SELECT seguida por uma lista de expressões 
A palavra-chave FROM seguida por uma ou mais declarações de variáveis simples. Uma variável é declarada por dar
uma expressão cujo valor
tem um tipo coleção, isto é, um conjunto, ou bag, ou lista, ou array 
A palavra-chave opcional AS 
O nome da variável simples, que “varre” a coleção 
*
Tipicamente, a expressão de (a) é o repositório de alguma classe, como o repositório Filmes da classe Filme. Entretanto, qualquer expressão que produza uma coleção de objetos pode ser utilizada, incluindo outra expressão Select-From-Where 
A palavra-chave WHERE é uma expressão booleana. Este expressão, como a expressão seguindo o SELECT, pode usar somente constantes e variáveis declaradas na cláusula FROM 
Uma consulta produz um bag de objetos 
*
Eliminação de Duplicatas
SELECT DISTINCT e.nome
FROM Filmes f, f.estrelado_por e
WHERE f.realizado_por.nome = "Disney" 
*
Objetos Complexos
Set<Struct N {string c1, string c2}> N1
 
N1 = SELECT DISTINCT Struct(estrela1:
 e1.nome, estrela2: e2.nome)
 FROM Estrelas e1, Estrelas e2
 WHERE e1.endereço = e2.endereço
 AND e1.nome < e2.nome
*
Sub-consultas
SELECT DISTINCT e.nome
FROM (SELECT f
 FROM Filmes f
 WHERE f.realizado_por.nome = 
 "Disney") d, d.estrelado_por e
*
Resultado como Lista
SELECT f
FROM Filmes f
WHERE f.realizado_por.nome = "Disney"
ORDER BY f.duração, f.título
*
Expressões com Quantificadores
FOR ALL x IN C : C(x), onde C é um conjunto, x é uma variável, e C(x) é uma condição
 
 SELECT e
 FROM Estrelas e
 WHERE ALL f IN e.estrelou_em :
 f.realizado_por.nome = "Disney"
*
 
EXISTS x IN C : C(x)
 SELECT e
 FROM Estrelas e
 WHERE EXISTS f IN e.estrelou_em :
 f.realizado_por.nome = "Disney" 
 
 
*
Expressões com Agregação
OQL usa os mesmos cinco operadores de agregação usados em SQL: AVG, COUNT, SUM, MIN, e MAX. 
Aplicáveis a qualquer coleção cujos membros são de tipos apropriados 
 SELECT ... AVG(SELECT f.duração
 FROM Filmes f)...
*
Expressões com GROUP BY
A forma de uma cláusula GROUP BY em OQL é 
As palavras chave GROUP BY
Uma lista de atributos-partição ("partition attributes"). Cada atributo-partição consiste de 
Um nome de uma variável (um critério de agregação) 
Dois pontos 
Uma expressão mencionando uma variável na cláusula FROM 
*
 
Na lista do SELECT, só podem aparecer os critérios de agregação, e os valores agregados 
O valor retornado pela cláusula GROUP BY é um conjunto de estruturas 
Cada estrutura tem a forma
 Struct(critério_agregação1:v1, ...,
 critério_agregaçãon:vn,
 lista_de_valores_agregados) 
*
 
Os valores agregados referem-se a uma partição (um conjunto de valores de atributos-partição)
 
 SELECT nome_estúdio, ano_filme,
 média_durações:
 AVG(SELECT p.f.duração FROM partition p)
 FROM Filmes f
 GROUP BY nome_estúdio: f.realizado_por.nome, ano_filme: f.ano 
 HAVING MAX(SELECT p.f.duração FROM 
 partition p) > 120 
*
Operadores sobre Coleções
Pode-se aplicar os operadores de união (UNION), interseção (INTERSECT) e diferença (EXCEPT) a duas coleções compatíveis de objetos
 
 (SELECT DISTINCT f
 FROM Filmes f, f.estrelado_por e
 WHERE e.nome = "Harrison Ford")
 EXCEPT
 (SELECT DISTINCT f
 FROM Filmes f
 WHERE f.realizado_por = "Disney") 
*
Variáveis Hospedeiras (Binding)
Set<Filme> Velhos_filmes
Velhos_filmes = SELECT DISTINCT f
 FROM Filmes f
 WHERE f.ano < 1920;
*
 
List<Filme> Minha_lista
Minha_lista = SELECT f
 FROM Filmes f
 ORDER BY f.título, f.ano
*
Extraindo o Elemento de uma Coleção Unitária
Filme Meu_filme
Meu_filme = ELEMENT(SELECT f
 FROM Filmes f
 WHERE f.título = "E o Vento Levou")