2. Banco de Dados Orientado a Objetos

1. 2. Banco de Dados Orientado a Objetos Banco de Dados II 2009.2 Prof. Cláudio Baptista, Ph.D.

2. Roteiro • Histórico • Crítica ao Modelo Relacional • Exemplo de Motivação • Introdução ao Modelo de Objetos • ODMG ODL • ODMG OQL

3. 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

4. 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

5. 1. CríticaaoModeloRelacional • 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

6. 1. CríticaaoModeloRelacional • 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

7. 1. CríticaaoModeloRelacional • 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

8. 1. CríticaaoModeloRelacional • 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

9. 1. CríticaaoModeloRelacional • 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

10. Limitações do ModeloRelacional • 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

11. 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)

12. 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)

13. 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

14. Solução BDOO: Esquema Repositório: Retângulos Retângulo Ponto N Definido_por 2 X Y {Ponto2.X > Ponto1.X} sobrepoe_quadrado _de_lado_um(); ...

15. Linguagem de Consulta OO, Estilo SQL • Quais os retângulos que sobrepõem um quadrado de lado um? • Selectr.ponto1, r.ponto2FromRetangulos rWherer.sobrepoe_quadrado_de_lado_um() • Basta ler, para entender! sobrepoe_quadrado_de_lado_um() é indexável, como qualquer coluna de tabela

16. Encapsulamento • Encapsulamento das condições de sobreposição • Booleansobrepoe_quadrado_lado_um() • {If ((self.ponto1.x1 <= 1 andself.ponto1.y1 <= 1) • and • (self.ponto2.x2 >= 0 andself.ponto2. y2 • >=0)) • thenreturntrue • elsereturnfalse; }

17. Encapsulamento • Regra de integridade: implementada no método construtor Retangulo() • Retangulosagora torna-se um repositório de objetos da classe Retangulo • O encapsulamento deve ser parcial, para ainda permitir interfaces estilo-SQL (Selectcolunax ...)

18. 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

19. 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

20. 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.

21. 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

22. 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)

23. 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

24. 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)

25. 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

26. 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

27. 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

28. 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.

29. ODL – VisãoGeral • UmaDeclaração de classeinclui: • Um nomepara a classe. • Declaração de chaves (key) opcional. • Declaração de Extent= nomepara o conjunto de objetoscorrentesnaclasse (instâncias). • Declaração de Elementos. Um elementpode ser um atributo, um relacionamento, ou um método.

30. Definição de Classe class <nome> { <lista de declarações de elementos, separadospor ; > } Exemplo: Class Estudante (extent Estudantes) { attribute string name; attribute intidade; }

31. 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>;

32. RelacionamentosInversos • 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.

33. O tipo de relacionamento serves É um set de Beer objects. O operador :: conecta um nome à direita ao contexto do nome à esquerda 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; }

34. Tipos de Relacionamentos • O tipo de um relacionamento é: • Umaclasse, como Bar. Nestecaso, um objeto com esterelacionamentopodeestarconectado a apenas um objeto Bar. • Set<Bar>: o objetoestáconectado a um conjunto de objetos Bar. • Bag<Bar>, List<Bar>, Array<Bar>: o objetoestáconectado a um bag, list, ou array de objetos Bar.

35. Multiplicidade dos Relacionamentos • Todososrelacionamento ODL sãobinários. • RelacionamentosMuitos-para-Muitostêm Set<…> para o tipo do relacionamento e seuinverso. • RelacionamentosMuitos-para-Um têm Set<…> no relacionamento do lado Um e a apenas a classepara o relacionamento do ladoMuitos • Relacionamentos Um-para-Um têm classes com o tipoemambasdireções.

36. Many-many uses Set<…> in both directions. Many-one uses Set<…> only with the “one.” 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; }

37. husband and wife are one-one and inverses of each other. buddies is many-many and its own inverse. Note no :: needed if the inverse is in the same class. Exemplo2: Multiplicidade class Drinker { attribute … ; relationship Drinker husband inverse wife; relationship Drinker wife inverse husband; relationship Set<Drinker> buddies inverse buddies; }

38. Lidando com RelacionamentosMúltiplos • ODL nãodarsuporte a relacionamentosternários. • Podemossimularrelacionamentosternáriosatravés de umaclasse de “conexão”, cujosobjetosrepresentamtuplas de objetosquenósgostariamos de conectar via o relacionamentoternário.

39. Classes de Conexão • Suponhaquequeremosconectar as classes X, Y, e Zatravés do relacionamentoR. • ProjeteumaclasseC, cujosobjetosrepresentamumatripla de objetos (x, y, z) das classes X, Y, and Z, respectivamente. • Precisamos de trêsmuitos-para-um relacionamentos de (x, y, z) paracada um de x, y, e z.

40. Exemplo: Classe de Conexão • Suponhaquetenhamos as classes Bar e Beer, e queremosrepresentat o preço de cada Beer emvendidaemcada Bar. • Um relacionamentomuitos-para-muitos entre Bar e Beer nãopodeter o atributopreçocomoocorre no modelo E/R. • One solution: cria-se a classe Price e umaclasse de conexão BBP pararepresentarumatripla bar, beer, e price.

41. Exemplo --- Continuação • Umavezqueobjetos Price sãoapenasnúmeros, umamelhorsoluçãoseria: • Dar aosobjetos BBP um atributo price. • Usardoisrelacionamentosmuitos-para-um entre um objeto BBP e osobjetos Bar e Beer.

42. 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 modificadosparaincluirrelacionamentos, ambos chamadostoBBP, e ambos do tipo Set<BBP>.

43. Structs e Enums • Atributospodemterumaestrutura (com em C) ou ser uma enumeration. • Declare com attribute [StructouEnum] <nome do structouenum> { <detalhes> } <nome do atributo>; • Detalhessãoosnomes dos campos e tipos de um Struct, umalista de constantes de um Enum.

44. Nomes para a estrutura e enumeração nomes dos atributos Exemplo: Struct e Enum class Bar { attribute string name; attribute StructAddr {string street, string city, int zip} address; attribute EnumLic { FULL, BEER, NONE } license; relationship … }

45. Declarações de Métodos • Umadefinição de classepodeincluirdeclarações de métodospara a classe. • Informaçãoconsiste de: • Tipo de retorno, se algum. • Nome do método. • Argument modes e tipos (semnomes). • Modes são in, out, e inout. • Quaisquerexceçõesque o métodopossalançar.

46. Exemplo: Métodos real cre(in string)raises(semNotas); O métodocreretorna um número real, quecontém o CRE de um aluno. crerecebe um argumento, uma string (matrícula do aluno) e nãomodificaesteargumento. crepodelançar a exceçãosemNotas.

47. Tiposem ODL • Tiposbásicos: int, real/float, string, enumerated types, e classes. • Type constructors: • Structparaestruturas. • Collection types : Set, Bag, List, Array, e Dictionary ( = mapeamento de um tipodomínio type para um tipoimagem). • Tipos Relationship podemapenas ser umaclasseou um tipo collection aplicado a umaclasse.

48. ODL Subclasses • Usual object-oriented subclasses. • Indicasuperclasse com extends e seunome. • Subclasselistaapenas as propriedadesúnicas à mesma. • Herda as propriedadesdasuperclasse.

49. Exemplo: Subclasses • Maltada é umasubclasse de beers: class Maltada extends Beer { attribute string color; }

50. Subclasses: HerançaMúltipla • ODL permite herança múltipla • Conflitos são resolvidos a nível de implementação class Anime extends Filme:Cartoon { attribute … }