1 / 106

2. Banco de Dados Orientado a Objetos

2. Banco de Dados Orientado a Objetos. Banco de Dados II 2009.2 Prof. Cláudio Baptista, Ph.D. Roteiro. Histórico Crítica ao Modelo Relacional Exemplo de Motivação Introdução ao Modelo de Objetos ODMG ODL ODMG OQL. Histórico.

liam
Download Presentation

2. Banco de Dados Orientado a Objetos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 … }

More Related