Uploaded by 007Gilmar
Biblioteca 558614
capitulo8575221035
Configurando o JDK
Sistemas de Bancos de Dados Orientados a Objetos
Depto. Engenharia de Computação e Automação Industrial Faculdade de Engenharia Elétrica e de Computação Universidade Estadual de Campinas mailto:ricarte@dca.fee.unicamp.br http://www.dca.fee.unicamp.br/~ricarte/
Resumo Sistemas de banco de dados representam um papel fundamental em aplicações de processamento de informação não-numérica, onde a utilização de tais sistemas permite facilitar a manutenção de dados consistentes que podem ser compartilhados por diversas aplicações, as quais não precisam conhecer o modo como tais dados são internamente armazenados ou representados. A tecnologia de banco de dados já está madura para diversas aplicações, principalmente nas áreas administrativa e comercial. Entretanto, novas categorias de aplicações têm demandado o gerenciamento de dados mais complexos — são aplicações tais como sistemas de apoio a projetos e de automação de escritórios. Para essas aplicações, o paradigma de orientação a objetos surge como alternativa adequada para a representação e manipulação dos dados, mas é preciso ainda integrar de forma adequada esta tecnologia a sistemas de banco de dados. Sistemas gerenciadores de bancos de dados orientados a objetos constituem a proposta corrente para a solução desse problema. Neste trabalho apresentam-se os aspectos básicos da modelagem e da tecnologia de tais sistemas, com uma breve discussão sobre tendências na área de processamento de informação não-numérica. Pela análise dessas tendências, observa-se que as técnicas desenvolvidas para a integração de orientação a objetos a banco de dados oferecem contribuições que certamente estarão presentes nas novas plataformas de processamento por objetos distribuídos. Assim, o estudo de sistemas gerenciadores de base de objetos devem ainda permanecer como objeto de interesse por um longo período.
Ivan L. M. Ricarte
Um banco de dados é uma coleção de dados relacionados que pode ser armazenada sob alguma forma física. Os dados armazenados em um banco de dados representam algum aspecto específico do mundo real — um universo de discurso de onde os dados são obtidos — e apresentam algum grau de coerência lógica entre seus componentes. Portanto, uma coleção aleatória de dados não constitui um banco de dados. Um sistema gerenciador de banco de dados é o software que permite criar, manter e manipular bancos de dados para diversas aplicações. A criação e manutenção de bancos de dados é tarefa de uma pessoa ou grupo de pessoas, normalmente referenciada como o administrador do banco de dados. A manipulação do banco de dados — atualizações e consultas — é realizada direta ou indiretamente, através de programas aplicativos, pelos usuários do banco de dados. O sistema gerenciador de banco de dados pode ser de propósito geral ou específico para alguma aplicação. Um sistema de banco de dados é constituído por um banco de dados e por um sistema gerenciador de banco de dados, como mostrado na Fig. 1 [16]. Um sistema de banco de dados é usualmente uma aplicação que serve de suporte a outras aplicações, tais como folha de pagamento, controle de pessoal e informações bancárias.
Sistema de Banco de Dados SGBD Programas Aplicativos/Consultas Software para Processar Consultas e Programas
Software para Acessar os Dados Armazenados
Base de Dados Armazenados
Figura 1: Sistema simplificado de banco de dados.
Tradicionalmente, sistemas de banco de dados estavam relacionados a aplicações nas áreas administrativa e comercial. Com o tempo, as vantagens obtidas com a utilização de um sistema de banco de dados para suportar a armazenagem da informação de uma aplicação — principalmente a independência da aplicação com relação à estrutura interna de armazenagem e a possibilidade de
compartilhar dados entre aplicações — passaram a ser desejadas em outras classes de aplicações, tais como projetos de engenharia (CAD/CAE — Computer Aided Design, Computer Aided Engineering), automação industrial e de escritórios (CAM — Computer Aided Manufacturing, OA — Office Automation), sistemas especialistas de suporte à tomada de decisões (DSS — Decision Support Systems) e sistemas de suporte ao trabalho cooperativo (CSCW — Computer Supported Cooperative Work). Muitas destas aplicações "não convencionais" impõem requisitos ao sistema de banco de dados que não estavam presentes nas aplicações tradicionais, tais como lidar com maiores volumes de dados, a necessidade de manipulação de dados em formatos não-alfanuméricos — incluindo informação multimídia — e o tratamento de esquemas evolutivos e dinâmicos. As necessidades dessas novas categorias de aplicações constituem a maior motivação para o surgimento de novas abordagens para o gerenciamento de dados. É neste sentido que a integração do paradigma de orientação a objetos a sistemas de banco de dados tem surgido como a tendência mais promissora em termos de gerenciamento de dados para as mais diversas categorias de aplicação. Neste trabalho apresenta-se um breve relato da evolução dos sistemas de banco de dados em direção a sistemas gerenciadores de base de objetos. Na Seção 2 descreve-se a "primeira onda" do processamento da informação não-numérica, culminando com a proposta do modelo relacional e o desenvolvimento dos primeiros sistemas gerenciadores de banco de dados relacionais. Sistemas gerenciadores de banco de dados relacionais ainda dominam boa fatia do mercado de processamento de informação, utilizando uma tecnologia dominada e sendo perfeitamente adequados para grande parte das aplicações comerciais e administrativas. Na Seção 3 apresentam-se os resultados de um período de transição, onde a limitação dos modelos tradicionais de representação de dados tornou-se patente para as novas aplicações computacionais que surgiam. Nesse contexto foi que a orientação a objetos foi proposta como o paradigma adequado de representação de dados, embora ainda fosse incerto como o casamento entre orientação a objetos e sistemas de banco de dados devesse ocorrer. Foi um período de experimentação, durante o qual foram lançados os fundamentos para a modelagem de dados segundo o paradigma de orientação a objetos. Na Seção 4 apresenta-se o resultado do amadurecimento da aplicação do paradigma de orientação a objetos a sistemas de banco de dados. Aspectos da tecnologia que oferece suporte à implementação de sistemas gerenciadores de base de objetos são apresentados. A Seção 5 apresenta alguns exemplos representativos de gerenciadores de objetos, onde algumas destas técnicas são ilustradas. Finalmente, na Seção 6 são apresentadas as tendências para o futuro do gerenciamento de dados em aplicações computacionais, que indicam ser o paradigma de orientação a objetos a base para a evolução dessas aplicações. Assim, sistemas gerenciadores de base de objetos deverão de fato representar um papel fundamental como repositórios de informação no futuro das aplicações computacionais por um longo período.
2 Evolução de sistemas de banco de dados
Para melhor compreender o estado atual da tecnologia de banco de dados, é interessante observar como esta tecnologia surgiu e evoluiu. O surgimento dos primeiros computadores está intimamente ligado à realização de cálculos numéricos repetitivos. Este era a motivação de Babbage para o projeto e elaboração de seu Engenho Analítico no Século XIX. Da mesma forma, os trabalhos pioneiros de Zuse, na Alemanha, e de Atanasoff, Aiken, Mauchly e Eckert, nos Estados Unidos, eram computadores voltados para a solução de problemas numéricos. Por um longo período, o desenvolvimento de computadores científicos (para aplicações numéricas) foi independente do desenvolvimento de máquinas para aplicações comerciais. Somente no início da década de 1960 a integração entre estas duas tendências ocorreu de modo mais acentuado, principalmente através dos esforços da IBM para otimizar sua linha de produção de máquinas para as duas áreas de aplicação. O conceito que motivou o surgimento de bancos de dados é quase tão antigo quantos os primeiros sistemas computacionais para aplicações não-numéricas, remontando ao final da década de 1950. Entretanto, o surgimento de sistemas gerenciadores de banco de dados sofreu influências também de outras áreas de aplicação, notadamente da área de defesa e de aplicações militares.
2.1 Primórdios do processamento não-numérico
O desenvolvimento de linguagens de definição de dados foi um fator importante no desenvolvimento de sistemas de banco de dados [18]. Entre elas destacam-se COMPOOL e COBOL. COMPOOL foi uma linguagem desenvolvida no Massachusetts Institute of Technology no contexto do projeto SAGE, de controle de tráfego aéreo, suportado pela Força Aérea norte-americana. Ela fornecia um mecanismo para definição de atributos compartilhados por centenas de programas em tempo-real. COBOL é uma linguagem de programação com uma seção centralizada para a definição de dados, a DATA DIVISION. A criação desta linguagem foi coordenada pelo consórcio CODASYL para integrar linguagens de aplicações comerciais, como FACT (Honeywell), GECOM (General Electric) e Commercial Translator (IBM). O uso de uma linguagem comum de definição e processamento dos dados, como no caso de COBOL, era atrativo pois a linguagem de definição seguia o modelo da sistemas baseados em fitas e cartões. Entretanto, cada fabricante adotava seu próprio esquema de armazenamento, o que dificultava a transferência de dados entre sistemas de fabricantes distintos. Geradores de relatórios foram criados para facilitar o trabalho de produzir saídas formatadas a partir de dados armazenados no sistema. Embora tais tarefas pudessem ser (e eram) produzidas a partir de linguagens de programação convencionais, os programas produzidos eram muito extensos. O uso destes report generators permitia então que usuários examinassem e manipulassem grandes volumes de dados, sendo um precursor das linguagens de consulta a bancos de dados.
e o Formatted File. Base-Ball foi um sistema especialista de acesso a dados através de uma interface em linguagem natural. descrito por Climenson na Communications da ACM. foram esforços significativos para a época e que influenciaram de diversos modos o desenvolvimento dos sistemas posteriores [18]. a oferecer gerenciamento dinâmico de memória principal e a utilizar um montador com rotina para alocação dinâmica de memória. estado de Washington. RPG II (1967). desenvolvido pela força aérea norte-americana no período 1961–1965. B-Tree é uma estrutura extensivamente utilizada para acesso eficiente a arquivos. Os dados. verificação de projeto e avaliação de sistemas gerenciadores de dados. Tinha por objetivo ser um laboratório para modelagem. 2. desenvolvido por Bachman no período 1964–1966. Após estes primeiros esforços no sentido de oferecer sistemas manipuladores de dados. desenvolvimento de protótipos. Entretanto. da MITRE Corporation. por Collilla e Sams. Este sistema foi o ancestral de todos os sistemas de geração de relatórios. ACSI-Matic foi um sistema projetado para explorar o uso efetivo de memória e inferências.Ivan L. M. ADAM (Advanced Data Management System) foi um sistema desenvolvido com recursos da Força Aérea norte-americana a partir do protótipo ETF (Experimental Transport Facility). Colingo era um conjunto de sistemas de gerência de dados orientados a fitas. com um protótipo implementado em 1964 pela RCA. em 1956. descrito inicialmente em 1960. incluindo os sistemas da IBM. o IDS (Integrated Data Store). Era parte de um projeto do exército norteamericano. Foi o primeiro sistema a oferecer um pacote generalizado para recuperação de dados em discos com requisições em batch. era um sistema de gerenciamento de acesso à informação generalizado para unidades de fita. surgiram de fato as primeiras famílias de gerenciadores de dados. assim como o vocabulário de interação entre usuários e a base de fatos. Alguns destes esforços são citados a seguir. de março de 1963. por Cheatham e Warshall. se comparados com os sistemas atuais. O Formatted File influenciou . descrita em artigo na Communications da ACM também de janeiro de 1962. RPG (System/360.2 Desenvolvimento de gerenciadores de banco de dados Os primeiros protótipos desenvolvidos com a funcionalidade de gerenciar dados de uma aplicação. QUERY era uma linguagem de consulta a dados com tradução para linguagem de máquina. eram relacionados a beisebol. cuja primeira implementação foi apresentada em artigo publicado na Communications da ACM de janeiro de 1962. desenvolvido por Postley na Informatics no período 1964–1968. Recol (Retrieval Command-Oriented Language). 1965) e seu sucessor. Esforços pioneiros incluíam o Mark IV para máquinas IBM1401. Ricarte Bancos de Dados Orientados a Objetos A General Electric desenvolveu o Generalized Report Generator para o centro de operações da Atomic Energy Commission em Hanford. oferecendo uma estrutura estilo COBOL em máquinas IBM. oferecem pouca semelhança de funcionalidade.
IBM e Caterpillar para apoio ao programa Apollo. da Rockwell. com mecanismos para remoção e inserção implícitas. Data Language/I). e acesso compartilhado aos dados. 1969–1971) e o projeto IMS (1966–1969) da Agência Espacial norte-americana (NASA). em 1966) oferecendo um modelo de dados do tipo rede. implementações de IDMS pela Digital Equipment Corporation para suas máquinas PDP11/45 e PDP-10. As restrições sobre tipos de dados e de esquemas que são permitidos por um sistema constituem seu modelo de dados. As principais características destes gerenciadores. que foram contribuições importantes para gerenciadores de dados que se seguiram. GIS (Generalized Information System). Esta abordagem foi adotada por diversos produtos. verbos para manipulação de dados na interface de alto nível. Foram frutos deste projeto os produtos ICS/DL/I (Information Control System. da IBM desenvolvido para suas máquinas da família System/360. Ricarte Bancos de Dados Orientados a Objetos o produto da IBM. IDMS-11 e DBMS-10. O IDS combinava tecnologia de acesso a posições aleatórias com linguagens procedimentais de alto nível (inicialmente. que influenciou o produto IMS/360 da IBM. princípios elementares de manutenção da consistência. descrições separadas para armazenamento e para programação. desenvolvido pela IBM para IBM System/360. com o Data Base Task Group (DBTG. e IMS/360.Ivan L. Os primeiros desenvolvimentos comerciais em gerenciadores de banco de dados foram marcados . conceitos de paginação de dados. desenvolvido na General Motors (1966). da NASA.3 O modelo relacional de dados A maior contribuição dos primeiros gerenciadores de dados foi introduzir a separação entre os dados armazenados e a descrição da estrutura dos dados. COBOL. Nesta mesma família de gerenciadores incluem-se também APL (Associative PL/I). entre os quais destacam-se o IDMS (Integrated Data Management System). incluem: pelos esforços da CODASYL. o esquema de dados. A abordagem do DBTG foi propor uma extensão a COBOL para a manipulação de bancos de dados. e o IDS/II. da Honeywell (1970). O projeto IMS foi resultado de um desenvolvimento conjunto das empresas Rockwell. 2. uma adaptação de IDS realizada pela Honeywell para adequação ao padrão DBTG. e dataBASIC. que introduziu como contribuições o armazenamento de tabela com o formato do arquivo e a manipulação de grandes arquivos. M. posteriormente. respectivamente. Gecom.
a união de duas relações com estruturas compatíveis ( ) e a diferença de duas relações com estruturas compatíveis ( ). os modelos rede e hierárquico apresentavam como limitação uma forte dependência entre as estruturas internas de armazenamento e a representação abstrata dos dados. Ricarte Bancos de Dados Orientados a Objetos A abordagem proposta pelo grupo CODASYL/DBTG suporta um modelo de dados conhecido posteriormente como o modelo rede (network). O modelo oferece a possibi- . pois muitos clientes concentravam suas aplicações em uma única máquina de grande porte. que pode ser expressa em termos de seleção e produto cartesiano. O modelo relacional oferece uma visão do conjunto de dados como uma coleção de tabelas ou relações (no sentido matemático da palavra). A álgebra relacional oferece operações básicas como seleção de tuplas dentre as pertencentes a uma relação ( ). limitando a organização dos dados a uma estrutura de árvore. onde o resultado é uma terceira relação que contém as tuplas da primeira relação que não estão presentes na segunda relação. que apresentava um modelo matemático para a representação e manipulação de dados totalmente independente de características de implementação. No modelo de dados hierárquico cada registro tem um único antecessor. Ambos modelos de dados têm por princípio o estabelecimento de ligações entre grupos de registros. M. Apesar do avanço em relação aos primeiros sistemas gerenciadores de dados. No entanto. enquanto que a abordagem de IMS introduziu o modelo de dados hierárquico. Um grande marco na evolução em modelos de dados foi a proposta do modelo relacional [12]. No modelo de dados rede os registros são organizados na forma de grafos dirigidos. Uma característica genérica dos produtos baseados nestes modelos estava no modo como as ligações entre registros era armazenada. lidade de expressar consultas e manipulações sobre a base de dados usando linguagens independentes de sistemas. ou hierarquia. usualmente utilizando endereços físicos. com uma forte dependência entre a representação do armazenamento e a máquina onde o sistema estava implementado. influenciando assim os mecanismos de manipulação. baseadas em álgebra relacional e em cálculo relacional [26]. que pode ser expressa em termos de diferenças. As principais operações derivadas das operações básicas na álgebra relacional incluem: a interseção de conjuntos. a junção com predicados. o produto cartesiano de duas relações gerando uma nova relação com todas as combinações possíveis de tuplas entre as duas relações originais ( ). ¦ ¤   §   ¨  ¦ § ¦ ©§  ¤ %! ¢ $#" § §   ! ¥ £¢ ¡ -uplas ordenadas de valores literais pertencentes a domínios atômicos. onde cada tabela é um conjunto de registros ou tuplas. a projeção de colunas da tabela gerando uma nova relação com apenas as colunas selecionadas ( ). para aquela época portabilidade não era uma questão maior.Ivan L.
Os principais projetos desta fase foram o System R. As principais contribuições deste projeto foram a definição da linguagem de consulta SQL. em . A década de 1970 foi assim marcada pelo desenvolvimento de protótipos de sistemas relacionais. onde o predicado de junção é a igualdade entre valores de atributos com domínios compatíveis nas duas relações envolvidas. um produto do mesmo nome derivado deste projeto foi lançado pela empresa Relational Technology. 46] foi um sistema gerenciador de banco de dados experimental desenvolvido por um grupo de pesquisa da Universidade de Berkeley. INGRES [45. Posteriormente. O protótipo inicial do sistema foi desenvolvido em um PDP-11. o cálculo de tuplas e o cálculo de domínios — têm poder equivalente de expressão [26]. em 1983. da IBM. da Universidade da Califórnia em Berkeley. Neste sentido. e INGRES. e a introdução dos conceitos de locking em duas fases e com múltiplas granularidades. a introdução de mecanismos para a compilação e otimização de consultas. As linguagens relacionais. É possível mostrar que estas três linguagens relacionais — a álgebra.. para a obtenção do resultado desejado. As vantagens do modelo relacional podem ser resumidas em dois pontos principais.Ivan L. A linguagem SQL usa uma combinação de construções da álgebra e do cálculo relacionais. a IBM lançou também o produto DB2 para manipulação de grandes bases de dados relacionais. 6] foi um projeto-protótipo do laboratório de pesquisa da IBM em San Jose. M. Ricarte Bancos de Dados Orientados a Objetos ordem. Posteriormente. Califórnia. iniciado em 1974. O segundo é a facilidade oferecida para o mapeamento de tuplas para os dispositivos de armazenamento. Estas vantagens motivaram os pesquisadores da época a investir no estudo de mecanismos de suporte à implementação de sistemas gerenciadores de banco de dados relacionais. Duas variantes básicas são o cálculo relacional de tuplas e o cálculo relacional de domínios. No entanto. não é uma linguagem procedimental completa. A álgebra relacional permite expressar as operações elementares que devem ser seguidas. Outras linguagens de consulta conhecidas incluem Quel (baseada no cálculo relacional de tuplas) e QBE (baseada no cálculo relacional de domínios). Inc. O cálculo relacional é baseado em construções não-procedimentais. sendo atualmente comercializado pela empresa Ingres Inc. ofereceram os fundamentos para o desenvolvimetno de diversas linguagens computacionais de consulta e manipulação de bases de dados. deu ainda origem ao produto SQL/Data System (1981) e ao projeto R* para estudo de sistemas de bancos de dados distribuídos. matemáticas. a introdução de mecanismos de integração da linguagem de consulta a linguagens de programação. INGRES foi projetado como um sistema gerenciador com diversos a junção natural. com sistema operacional Unix. O System R [2. é uma linguagem procedimental. pois suas expressões definem sequências de operações. Concluído em 1979. com uma associação praticamente direta para registros de dimensão fixa em arquivos com acesso direto em disco. pois não inclui as construções de controle de execução usualmente presentes em linguagens de programação. O primeiro é seu forte suporte teórico para descrição da representação e da manipulação dos dados. usando descrições formais do que é desejado na manipulação.
através de um processo de decomposição de consultas. A linguagem Quel foi introduzida por este projeto. Ricarte Bancos de Dados Orientados a Objetos processos concorrentes com mecanismos de comunicação inter-processos. Assim. Estes protótipos influenciaram o desenvolvimento de muitos produtos. juntamente com um mecanismo de embedding para a linguagem de programação C. os modelos de dados conceituais estão próximos do nível mais alto. cujas necessidades de representação de informação nem sempre eram adequadamente atendidas por tais produtos. A não existência de um modelo estendido unificado dificulta uma aceitação mais ampla dessa linha de evolução de modelos. 2). que evoluiu posteriormente para um produto comercial denominado Montage [50]. 3. . havia uma necessidade de se buscar modelos de dados com maior poder de expressão que o modelo relacional de dados. versões. e sistemas gerenciadores de banco de dados relacionais atingiram grande sucesso comercial. Sistemas representativos desta tendência incluem op já citado POSTGRES. Deste projeto derivou-se também o projeto POSTGRES [41]. As técnicas de otimização de consulta não eram realizadas por pré-compilação. Entretanto. Os principais mecanismos descritos em diversas propostas incluem procedimentos armazenados. e Starburst [27]. o desenvolvimento da tecnologia computacional vem motivando a implementação de aplicações cada vez mais complexas. Aqui adotou-se a nomenclatura de Parsaye [36]. É a partir de situações como essas que a busca por novos mecanismos de expressão de dados é motivada. 2. normalizado. das quais se destacam: 1. embora em geral não haja um consenso sobre os nomes de cada nível. o poder de expressão das tabelas é limitado. sistema gerenciador de banco de dados relacional com características avançadas de controle de restrições e apoio a novos tipos de dados. O termo "conceitual" refere-se ao fato de que as construções oferecidas por estes modelos estão em níveis de abstração mais próximos do universo de interesse do usuário do que dos aspectos de implementação da máquina. Várias propostas de arquiteturas de bancos de dados utilizam três níveis de abstração para bancos de dados (Fig. desenvolver um bom projeto relacional. o modelo relacional de dados enfrentou (e continua enfrentando) algumas críticas. objetos binários (BLOBs) e definição de tipos abstratos de dados.Ivan L. 38]. não é tarefa simples. da Universidade da Califórnia em Berkeley. os modelos de dados conceituais e os modelos orientados a objetos. do IBM Almaden Research Center. Os modelos de dados conceituais oferecem construções no nível mais próximo do projetista para organização do mundo de interesse [5. mas durante a interpretação das consultas. é apenas adequado para aplicações "estruturalmente simples". M. como em System R. As abordagens resultantes podem ser resumidas em três grandes categorias de modelos: os modelos relacionais estendidos. Neste caso. Os modelos relacionais estendidos incorporam mecanismos não previstos na proposta original do modelo relacional [13]. De qualquer modo.
onde algumas construções computacionais podem já ser consideradas. atributos e relações. agregação e generalização. Ricarte Bancos de Dados Orientados a Objetos Conceitual entidades atributos relações registros campos tabelas dicionários definições de dados métodos de acesso dispositivos de armazenamento Lógico Físico Figura 2: Arquitetura de banco de dados. O modelo entidade-relacionamento [11] foi proposto por Chen em 1976 como um modelo conceitual. Construções para a representação dos dados seriam registros. Neste nível seriam consideradas construções computacionais como dicionários. não estando diretamente relacionado a preocupações relativas à implementação de suas primitivas. campos e tabelas. Nesta estruturação de banco de dados em uma arquitetura de três níveis. a informação é estruturada. Neste nível. para os quais havia sistemas gerenciadores de banco de dados disponíveis. e os modelos semânticos e funcionais. foram propostos .Ivan L. os mecanismos de abstrações em bancos de dados. definições de dados. Os conceitos de abstração em bancos de dados. representação e desempenho. métodos de acesso e dispositivos de armazenamento. M. a informação do mundo real é modelada por usuários independentemente das estruturas computacionais que serão utilizadas no nível conceitual. O nível interno ou físico corresponde a representações do dado onde são considerados detalhes de armazenamento. que organiza a informação em tipos de entidades e tipos de relacionamentos. agregação e generalização. Por este motivo. Algumas das características de interesse do modelo E-R são o encapsulamento dos detalhes estruturais em construções de alto nível (tipos de entidade e tipos de relacionamento) e mecanismos para manutenção de integridade e consistência dos dados. construções para a representação dos dados são (por exemplo) entidades. No nível conceitual. Algumas das principais propostas no sentido de oferecer modelos de dados conceituais incluem o modelo entidade-relacionamento. juntamente com a proposta do modelo há descrições para realizar o mapeamento do modelo E-R para os modelos relacional e rede. que organizam a informação através de objetos e funções.
Embora inicialmente tenha também sofrido pelo excesso de abordagens não-compatíveis. Ricarte Bancos de Dados Orientados a Objetos por Smith e Smith [44] em 1977 como ferramentas de projeto de banco de dados.1 Princípios da orientação a objetos O conceito de objeto como construção de programação foi inicialmente introduzido na linguagem Simula 67. Assim. sendo por este motivo objeto de intenso interesse de pesquisa e desenvolvimento. principalmente relacionais. Essas aplicações incluem. juntamente com propostas de mecanismos para seu suporte em sistemas gerenciadores de banco de dados. autoria e manipulação de documentos eletrônicos. manufatura e controle. o desenvolvimento de sistemas gerenciadores de bases de objetos (SGBOs) surgiu como uma alternativa com o potencial adequado para atender à demanda de tais aplicações. 3. engenharia civil e arquitetura). da mesma forma como ocorreu com modelos relacionais estendidos. Deste modo. Antevia-se que tais sistemas ofereceriam o ferramental necessário para as novas categorias de aplicações que não estavam sendo adequadamente suportadas por bases de dados relacionais. entre outras. 37] estão voltados principalmente para a integração entre sistemas de bancos de dados e sistemas de representação de conhecimento. atividades em projetos de engenharia (siatemas CASE para engenharia de software. sendo fortemente influenciados por técnicas da inteligência artificial. relacionamentos entre objetos (incluindo hierarquias na forma IS-A) e derivação de esquemas. sua ampla aceitação motivou esforços de padronização que vêm unificando o chamado "modelo de objetos". A abordagem de modelagem por orientação a objetos. incorporam mecanismos para expressar tipos complexos. Entretanto. baseados principalmente no modelo relacional de dados. que . apesar de próximo em princípio aos modelos de dados conceituais. CAD para desenvolvimento de hardware e apoio à engenharia mecânica. em diversos níveis de escala de aplicação. Por este motivo. M.Ivan L. Estes conceitos básicos reaparecem em muitos outros modelos sob diferentes formas. vem recebendo atenção e aceitação muito mais ampla. 3 Modelagem de dados orientada a objetos Os sistemas comerciais de gerência de banco de dados. onde a execução de um programa era realizada através da composição da execução de vários objetos inter-relacionados. Modelos semânticos e modelos funcionais [22. Também não houve uma abordagem de modelagem semântica universalmente aceita. esse tópico será tratado em mais detalhes na próxima seção. obtiveram ampla aceitação e divulgação. O paradigma de orientação a objetos surgiu como uma alternativa para a modelagem de bancos de dados que permitiria incorporar muitos dos conceitos propostos pelas outras abordagens alternativas ao modelo relacional de dados. Objetos com uma mesma estrutura constituíam uma classe. tais sistemas mostraram-se inadequados para uma ampla gama de aplicações que surgiu com a ampliação do poder de processamento dos computadores modernos.
Como Stroustrup destaca [47]. espera-se que um método denominado print em duas classes distintas tenha um comportamento comum. o desenvolvimento de um sistema em um processo de informação através de transformações de seu estado. A substância do processo é organizada como componentes do sistema. Por exemplo. Apenas a partir da década de 1980 houve um maior esforço no sentido de valorizar tais conceitos e incorporá-los a outras linguagens de programação. Polimorfismo é o mecanismo que permite expressar que ações similares em classes distintas venham a ter um comportamento uniforme. que permite abstrair (nesta definição) substância como declarações de classes. Juntamente com a técnica de padrões de projeto (design patterns). criando classes derivadas a partir de declarações de classes bases já existentes. por mais simples ou complexa que seja a unidade de informação. Em Smalltalk [19] toda a informação sobre o processo de interesse é organizada através de objetos. A execução de um programa Smalltalk ocorre por interpretação.Ivan L. dois conceitos inerentes à programação orientada a objetos são herança e polimorfismo. Transformações de estado são consideradas como ações por objetos. assim como de métodos invocados. um paradigma. assim como não há garantia de que um programa será orientado a objetos simplesmente porque foi implementado em uma linguagem de programação orientada a objetos. valores e propriedades mensuráveis como declarações de tipos. podendo haver uma conversão de um programa fonte para um programa em formato intermediário de interpretação. Além dos conceitos fundamentais de classes. herança torna-se um mecanismo de reuso poderoso. Uma linguagem de programação orientada a objetos nada mais é do que uma linguagem de programação que favorece a aplicação dessa técnica. Uma propriedade mensurável da substância é uma propriedade de um objeto. Nygaard [31] define programação orientada a objetos como . Entretanto. . bytecodes. sendo que a definição sobre a realização do objeto. ocorre apenas durante o período de execução. Atualmente. Herança é o mecanismo que permite reaproveitar declarações de classes. M. e ações como declarações de métodos ou procedimentos. denominados objetos. Um aspecto chave em programação orientada a objetos é o conceito de abstração. independentemente das diferenças internas de sua implementação. . Embora Simula tenha introduzido o conceito de objetos em programação. através do mecanismo de ligação dinâmica (ou late binding). objetos e métodos. programação orientada a objetos é uma técnica. Ricarte Bancos de Dados Orientados a Objetos era descrita por uma declaração de classe. Um objeto encapsula uma estrutura que só é manipulável através de métodos componentes de uma interface pública. é possível realizar programação orientada a objetos sem usar uma linguagem de programação orientada a objetos. Programas manipulam objetos. as linguagens de programação orientadas a objetos de maior utilização são C++ e . Os conceitos introduzidos por Simula estiveram por muito tempo limitados à utilização em aplicações de simulação. Smalltalk foi a linguagem responsável por sua popularização [29].
templates ou herança múltipla. favorece a implementação de programas não-orientados a objetos. 3. as duas abordagens de soluções — de linguagens e de modelos — estavam bem distantes naquele momento. ou seja. sistemas de banco de dados atendiam às necessidades das aplicações que manipulavam dados nos mais diversos tipos de sistemas de processamento de informação. Tendo este objetivo. representando valores simples como inteiros. Estes sistemas ofereciam o armazenamento persistente dos dados. os dados registrados no sistema tinham um período de vida que se estendia além do período de vida dos processos que os manipulavam. Assim. variáveis tipicamente se extingüem com o final da execução do programa. empregou-se o conceito de compilar programas Java para bytecodes que são interpretados por uma máquina virtual [21]. em meados da década de 1980. alguns destes conceitos estavam presentes em propostas de modelos de dados. Para alcançar portabilidade. Críticas à linguagem referem-se principalmente à sua complexidade e à dificuldade de se realizar o transporte de aplicações em C++ entre diferentes plataformas computacionais. De um lado. causadores da maior parte dos erros de programação. como o agrupamento de entidades (objetos) em tipos de entidades (classes) no modelo Entidade-Relacionamento de Chen. Inicialmente. Ricarte Bancos de Dados Orientados a Objetos Java. através do mecanismo de early binding. Entretanto. De fato. é uma linguagem fortemente tipada. números reais. M. C++ [48].Ivan L. A portabilidade é alcançada a partir do momento em que máquinas virtuais Java estejam disponíveis em diversas plataformas. considerou-se a utilização de C++ para atingir este objetivo. muito maiores que a capacidade de memória principal dos . Assim. com o objetivo inicial de desenvolver aplicações de software para sistemas embarcados. Assim. eficiente e oferecer um alto grau de portabilidade entre as possivelmente várias plataformas de execução distintas. Em um programa orientado a objetos. fazendo com que C++ seja a linguagem preferencial onde o desempenho das aplicações é um aspecto importante. sua execução é rápida e eficiente. caracteres e strings. Como C++ não é uma linguagem interpretada. Além disto. Java [20] é uma linguagem de programação definida pela Sun Microsystems como uma "simplificação" de C++. Informação em C++ pode estar representada sob a forma de objetos. ou sob a forma de literais. onde a maior parte das verificações de operações sobre objetos são realizadas em tempo de compilação. ao contrário de Smalltalk. apesar da proximidade em seus objetivos finais. Java não utiliza ponteiros. foram eliminados. parecia ser o caminho natural de evolução a fusão de orientação a objetos e sistemas de banco de dados. Sistemas de banco de dados também eram eficientes em oferecer aramzenamento eficiente para grandes volumes de registros. C++ é uma linguagem que. devido à sua proximidade e compatibilidade com a linguagem C. definiu-se uma nova linguagem de programação tomando C++ como base mas onde os seus mecanismos complexos. mas constatou-se que essa linguagem — assim como muitas outras analisadas — não era adequada para tal fim. a linguagem deveria ser simples. representantes de entidades abstratas ou do mundo real.2 Incorporação de orientação a objetos a sistemas de banco de dados A definição de Nygaard para programação orientada a objetos sugere ser este um paradigma adequado à manipulação de sistemas de informação.
mudanças na estrutura interna de armazenamento não afetavam a implementação da aplicação. . ou seja. onde entidades do mundo real pudessem ser representadas univocamente no esquema da base de dados por uma construção com alto nível de abstração (o objeto). de recuperação de dados em casos de falhas. era possível implementar aplicações sem que fosse preciso conhecer a estrutura interna de como os seus dados estavam registrados. ter uma identificação única. As motivações. como os mecanismos de controle de transações atômicas. era muito mais do que oferecido por qualquer linguagem de programação. M. Por este motivo. para se obter mecanismos de modelagem de objetos eram muitas. Duas conseqüências desta propriedade eram fundamentais para a implementação de aplicações em sistemas de informação. assim como as necessidades. parecia ser a solução ideal para o problema do gap semântico entre modelagens e o mundo real. Apesar da distância entre linguagens de programação orientadas a objetos e sistemas de banco de dados. Outro aspecto bem atendido por sistemas de banco de dados referia-se ao oferecimento de mecanismos de alto nível para a interação com usuários. e sistemas de regras (triggers) para a avaliação de condições durante a manipulação de dados que permitiam "disparar" procedimentos de verificação e manutenção da consistência. Desta forma. permitindo a manutenção simplificada de um único repositório de dados para as aplicações de uma corporação. houve um grande investimento da parte dos pesquisadores da área de banco de dados em se desenvolver modelos integrando os conceitos de orientação a objetos com funcionalidades de bancos de dados. Em aplicações de engenharia. como descrito a seguir [10]. a identificação de entidades por valores de atributos pode ser artificial e sujeita a inconsistências. Ricarte Bancos de Dados Orientados a Objetos computadores. é importante para tais aplicações. Mesmo que a solução não fosse a ideal. Acima de tudo. Em segundo lugar. a utilização de sistemas de banco de dados permitia que aplicações alcançassem a independência de dados. independente de valores de atributos e gerenciada pelo sistema. era possível compartilhar os dados entre diversas aplicações.Ivan L. Identificadores de objetos. de projeto e em algumas aplicações comerciais. tais como a definição de linguagens de consulta declarativas e mecanismos para a geração de formulários de interação. uma vez que os problemas de ambientes com bases de dados heterogêneas e ambientes multidatabases ainda são objetos de estudo [23]. Sistemas de banco de dados também ofereciam mecanismos interessantes de manutenção de consistência dos dados. A operação de bases de dados em ambientes distribuídos já apresentava soluções sob a forma de sistemas de banco de dados distribuídos. A perspectiva de se ter um modelo de objetos. Em primeiro lugar. as vantagens antevistas para a integração entre as duas abordagens era evidente. Outro aspecto melhor atendido por sistemas de banco de dados era a questão do suporte a múltiplos usuários em acesso concorrente às bases de dados.
o comportamento é relevado à aplicação. O mecanismo de BLOBs presentes am alguns sistemas relacionais estendidos. Sistemas relacionais operam exclusivamente com o conceito de conjuntos (coleções não ordenadas). O mecanismo de herança presente em linguagens de programação orientadas a objetos deve ser oferecido como um mecanismo de definição de esquemas de dados e objetos. Isolar a estrutura interna de objetos da aplicação é um mecanismo importante para obter reuso. M.Ivan L. Procedimentos associados. É interessante que a base de objetos possa registrar tanto a estrutura quanto o comportamento dos objetos da aplicação. Em sistemas tradicionais. apesar de permitir o armazenamento destes volumes de dados. não oferece mecanismos para a interpretação destes dados. delegando tal tarefa exclusivamente à aplicação. é preciso que o sistema seja capaz de manter a integridade dessas referências. Exemplos são registros de textos. Encapsulação de objetos. Referências e integridade. que é o estabelecimento de associações entre objetos. Ricarte Bancos de Dados Orientados a Objetos Objetos compostos. imagens e sons. Adicionalmente. é usual a necessidade de se oferecer mecanismos para definir objetos que contêm outros objetos. Um sistema gerenciador da base de objetos deve oferecer mecanismos adicionais para a representação de coleções mais genéricas que simplesmente conjuntos. Nestas aplicações. A importância deste conceito já havia sido enfatizada pelo trabalho de Smith e Smith sobre abstração de dados. onde o comportamento é expresso pelos procedimentos (métodos) que manipulam o conteúdo dos objetos. com mecanismos adequados para se utilizar esta informação. A base de objetos deve oferecer subsídios para que este mecanismo das linguagens de programação orientadas a objetos reflita-se no sistema gerenciador da base de objetos. inter-operabilidade e modularização das aplicações. Composição por agregação é apenas um caso especial de uma necessidade maior. Sistemas de banco de dados relacionais não lidavam de modo adequado com o conceito de objetos formados pela agregação de outros objetos. sendo importante para a maior parte das aplicações. É fundamental a capacidade de se expressar relacionamentos genéricos entre objetos. assim como de oferecer operações de acesso a subcomponentes nas hierarquias que definem tais objetos. Grandes blocos de dados. mas há diversas aplicações onde a ordem dos elementos de uma coleção é importante. . Hierarquias de tipos. Alguns atributos de objetos podem ocupar espaços de armazenagem muito maior que o espaço usualmente ocupado pela representação de valores literais. sendo essencial em sistemas de banco de dados de apoio a projetos de engenharia. Coleções ordenadas.
o conceito de orientação a objetos. É importante que um sistema gerenciador da base de objetos permita expressar essa multiplicidade de representações para um mesmo objeto. necessitam facilidades para introduzir modificações no esquema de objetos ao longo de sua execução.3 Protótipos pioneiros Nesta seção serão apresentados alguns dos esforços pioneiros no desenvolvimento de sistemas gerenciadores que incorporassem.Ivan L. motivando diversas linhas de pesquisa com o objetivo de analisar e propor como tal integração poderia ocorrer. Afinal. 3. locking por períodos que podem ser extensos e checkin de objetos. a operação de computadores em redes é a regra geral e não a exceção. a manipulação dos dados ocorre através de uma linguagem de consulta. não procedimental. Embora tais motivações tenham sido expostas principalmente a partir das necessidades de um sistema gerenciador da base de objetos para aplicações de projeto em engenharia. M. Iris [17] foi um protótipo desenvolvido na Hewlett-Packard para explorar as novas funcionalidades de um sistema gerenciador da base de objetos. A abordagem adotada em Iris pode ser classificada . é importante ter um sistema gerenciador da base de objetos no qual modificações de esquema possam ocorrer sem maiores impactos sobre os dados já armazenados. ORION e GemStone [25]. Interfaces de programação. Em aplicações de projeto o conceito de versões dos objetos é essencial. semanticamente distante da linguagem de programação da aplicação. ao contrário. Aplicações de projeto. Assim. um sistema gerenciador da base de objetos incorporando tais mecanismos constitui uma ferramenta poderosa para aplicações futuras e para a evolução de aplicações tradicionais. Ricarte Bancos de Dados Orientados a Objetos Acesso remoto. Nas aplicações utilizando um sistema gerenciador da base de objetos. claramente diversos desses mecanismos são interessantes para outras categorias de aplicação. Múltiplas versões. tanto para a manutenção da evolução histórica do projeto como para expressar alternativas concorrentes para os objetos de projeto. Alguns dos primeiros desenvolvimentos em sistemas gerenciadores da base de objetos incluem os sistemas Iris. é interessante que haja uma maior integração entre a base de objetos e a linguagem de programação orientada a objetos usada pela aplicação. com mecanismos de checkout. É importante que um sistema gerenciador da base de objetos ofereça mecanismos eficientes para acesso remoto aos objetos. uma vez que ambas adotam o mesmo paradigma. Em sistemas gerenciadores de banco de dados tradicionais. Evolução de esquema. pois nesse tipo de aplicação a definição do esquema é parte da atividade de projeto. mais que outras. de algum modo. A importância em se obter uma combinação destes novos mecanismos com os mecanismos tradicionalmente oferecidos por sistemas gerenciadores de banco de dados foi logo observada. Em ambientes de projeto.
O . e um mecanismo simples de controle de versões por checkout e checkin. objetos. a possibilidade de associar um objeto a mais de um tipo. Ricarte Bancos de Dados Orientados a Objetos como uma extensão de sistemas funcionais para orientação a objetos. versões Gerenciador de armazenamento concorrência. que teriam suas construções mapeadas para as construções internas do gerenciador de objetos. OpenODB. três abordagens de interface foram propostas para este sistema. suporte a transações longas e a múltiplas versões das bases de dados. recuperação. consultas. Aplicações poderiam interagir com o sistema gerenciador da base de objetos através de várias linguagens. funções. otimização. Texas. Para o módulo gerenciador de armazenamento. OSQL. O sistema foi implementado em C em estações de trabalho Unix (HP-9000). 3. ORION [24] foi resultado de um projeto desenvolvido no Programa Advanced Computer Architecture da MCC (Microelectronics and Computer Corporation). a terceira abordagem procurava explorar o conceito de persistência de objetos. A segunda abordagem apresentava o sistema gerenciador da base de objetos como um objeto para a aplicação. onde objetos da aplicação seriam manipulados pelo sistema gerenciador da base de objetos de forma transparente para o programador. oferecia facilidades para a criação e manipulação de esquemas de objetos. Iris deu origem posteriormente a um produto da HP. empresa de Austin. implementado em Lisp. Entre os objetivos do projeto buscava-se incorporar novos mecanismos de modelagem e de construção de tipos de dados. Object SQL Editor Gráfico Objetos C Objetos Lisp Lisp-Iris C-Iris Gerenciador de objetos tipos. A arquitetura básica do sistema é apresentada na Fig. Um editor gráfico. clustering dados estruturados dados não estruturados Figura 3: Arquitetura do sistema Iris. indexação. Finalmente. embutidos em alguma linguagem de programação. suporte a inferências no banco de dados. buffering. um sistema gerenciador de banco de dados relacional da própria HP foi utilizado. Algumas características particulares de Iris incluíam a possibilidade de examinar esquemas como quaisquer outros dados. atualizações. A primeira abordagem refletia a interface usual para sistemas gerenciadores de banco de dados de então — através de comandos de uma linguagem. M. que interagiria com o sistema através de métodos aplicados ao objeto.Ivan L. Do ponto de vista da aplicação.
Uma visão simplificada da arquitetura do sistema GemStone é apresentada na Fig. A arquitetura do sistema é apresentada na Fig. subsistema de objetos manipulador de mensagens subsistema de transações subsistema de armazenamento Figura 4: Arquitetura do Sistema ORION. verificava autorização de usuários. gerência de transações. STDM (Set Theoretic Data Model). Caso atuasse no servidor. adotando formatos neutros para representação interna de dados. herança múltipla. e oferecia um conjunto pré-definido de classes e métodos em OPAL para uso da aplicação. Lisp e Ada. objetos compostos e BLOBs. Duas formas de evolução de esquema eram suportadas: mudanças na definição de classes (atributos e métodos) e mudanças na estrutura de classes (classes e associações). A interação da aplicação com ORION foi definida através de mensagens. para a definição e armazenamento de dados. mensagens de acesso. Posteriormente o sistema apresentou uma segunda versão com múltiplos clientes e uma terceira versão com múltiplos servidores. era . O sistema ORION deu posteriormente origem a um sistema de banco de dados comercial. gerência de transações. 5. para realizar tarefas tais como definição de esquemas. dados do sistema podes ser compartilhados por aplicações com interface de programação C++. CLOS. 4. O sistema. Gem oferecia compilação de programas em OPAL. Entre outras características.Ivan L. C. M. uma plataforma para sistemas especialistas. Ricarte Bancos de Dados Orientados a Objetos objetivo do projeto era inicialmente suportar as necessidades de manipulação de dados de Proteus. GemStone [7. criação e remoção de instâncias. foi implementado em Common Lisp para Symbolics (máquina Lisp) e estações de trabalho Unix. OPAL. A linguagem resultante. inicialmente mono-usuário. para a recuperação e atualização de valores de atributos de uma classe. que poderiam ser métodos definidos por usuários. As principais ênfases no projeto ORION foram na implementação de bases distribuídas e em evoluções de esquema [4]. evolução dinâmica de esquemas. Versões de objetos e referências eram suportadas através de time stamps. Itasca [3]. 8. implementava um modelo de dados baseado em teoria de conjuntos. e funções definidas pelo sistema. consultas e armazenamento de dados multimídia. Assim. Foram implementadas em ORION funções tais como controle de versões e notificação de modificações. Itasca apresenta uma arquitetura de múltiplos clientes e múltiplos servidores. GemStone incorporava o conceito de história de objetos. 14] foi um produto da Servio Logic Corporation que estendeu a linguagem Smalltalk para incorporar manipulação de bases de dados.
foi implementado em hardware específico. compilador concorrência. Assim. Opcionalmente. seguida por uma apresentação dos principais aspectos de implementação. limitações relacionadas ao processamento de chaves (primárias. este módulo poderia ser alocado à máquina cliente. objetos têm uma identificação única que não depende de valores de seus atributos. Inicialmente é apresentada uma visão conceitual dos mecanismos de manipulação de objetos. Não obstante. Posteriormente. replicação. suportando a linguagem OPAL. recebendo bytecodes para um submódulo interpretador. módulo onde as funcionalidades de sistemas de banco de dados.1 Objetos e atributos Na orientação a objetos. Stone era o gerenciador de dados. tais como entrada e saída de disco. O protótipo inicial de GemStone. tanto internas como (possivelmente) externas. autorização. Esta identificação de objeto (OID) é utilizada para referências a objetos.Ivan L. controle de concorrência. eram efetivamente implementadas. GemStone foi o primeiro sistema a oferecer integração através de mais de uma linguagem. 4. M. 4 Manipulação e implementação de gerenciadores de bases de objetos Nesta seção são descritos os aspectos do gerenciamento de dados que são específicos para sistemas gerenciadores de base de objetos [10]. o sistema também foi oferecido com possibilidade de integração a aplicações em C++. Ricarte Bancos de Dados Orientados a Objetos sessão sessão interpretador. serviços de transação e de recuperação. Deste modo. apesar de não ser um conceito da orientação a objetos. Deste modo. o conceito de um atributo chave está presente em muitas aplicações. recuperação Gem Stone Figura 5: Arquitetura do Sistema GemStone. vários sistemas gerenciadores de base de objetos oferecem a definição de atributos chaves como um mecanismo de acesso adicional ao identificador de objeto. mais próximo da compreensão dos usuários e oferecendo as mesmas restrições de . "estrangeiras") em sistemas de banco de dados relacionais não estariam presentes em sistemas de banco de dados orientados a objetos. transações. também o módulo encarregado por controlar conexões com as sessões clientes. armazenamento.
sendo que em sistemas tradicionais usualmente tais atributos estão restritos a valores literais e atômicos. os três tipos citados são as construções parametrizáveis fundamentais. não sendo considerados simples BLOBs literais. Ricarte Bancos de Dados Orientados a Objetos integridade presentes em sistemas gerenciadores de banco de dados relacionais. sendo que apenas através dos métodos públicos a informação associada ao objeto pode ser manipulada. Em muitas aplicações. tendo como valores identificadores de objetos. atributos de um objeto são propriedade privada e exclusiva do objeto. Coleções são exemplos de tipos parametrizados presentes em sistemas gerenciadores de base de objetos. M. Atributos virtuais ou derivados são aqueles cujos valores não estão explicitamente armazenados na base de dados. listas ou arranjos de valores. Métodos são definidos em uma linguagem procedimental. tais atributos são definidos como read-only. Há no entanto diversas outras linguagens de programação orientadas a objetos e sistemas gerenciadores de base de objetos que relaxam uma ou mais destas . 4. valores multimídia são considerados atributos simples. porém outras podem estar presentes em distintas implementações.Ivan L. Métodos podem manipular apenas dados do próprio objeto. que podem simples ou complexos. é preciso suportar a orientação a objetos comportamental [1]. Um sistema gerenciador de banco de dados multimídia é essencialmente um sistema gerenciador de base de objetos onde os dados multimídia recebem tratamento diferenciado. Atributos simples são aqueles cujos valores são literais. Atributos de objetos estão presentes em qualquer sistema gerenciador de banco de dados. 3. Referências ou associações estabelecem relacionamentos entre objetos. Além da orientação a objetos estrutural. Apenas métodos podem ser públicos. atômico e não-estruturado. Atributos complexos do tipo coleção são utilizados para definir conjuntos. Uma diferença em sistemas gerenciadores de base de objetos está na maior flexibilidade oferecida para a definição destes atributos. Em geral. Em geral. Um aspecto fundamental em sistemas gerenciadores de base de objetos é a manutenção da consistência entre referências a objetos. A definição estrita de encapsulação exige a satisfação de três critérios: 1. Este mecanismo de encapsulação é fundamental para atingir independência de dados em sistemas gerenciadores de base de objetos. que pode ser obtida através da definição de métodos. 2. onde o BLOB referente ao objeto multimídia é considerado um valor literal.2 Aspectos comportamentais Um sistema gerenciador de base de objetos precisa oferecer mais que simplesmente novos mecanismos de estruturação de dados. coleções ou virtuais. sendo raro o oferecimento de mecanismos para atualizar seus valores. Esta definição é satisfeita em Smalltalk. procedimentos que permitem encapsular a semântica de um objeto. mas ao invés são computados através de procedimentos. Atributos complexos podem ser de três tipos: referências.
M. que permite definir novos tipos de objetos a partir de tipos já existentes. muitas vezes necessitando de processamento off-line para converter os dados de um esquema para o outro. Uma diferença entre uma linguagem de definição de dados e uma linguagem de definição de objetos é que esta última pode permitir. sendo que o tipo do objeto é definido através de uma declaração de classe. Atributos derivados já foram apresentados anteriormente. tipos são criados através de uma linguagem de definição de dados ou. A representação de comportamento em sistemas gerenciadores de base de objetos permite definir dados ativos. como já observado. onde as ações são ativadas quando modificações à base de dados tornam verdadeiro o predicado expresso no padrão da regra. onde oferece-se uma implementação diferenciada para um método já existente no tipo ancestral.3 Tipos e herança Objetos com estrutura similar são agrupados em classes. Em um sistema gerenciador de base de objetos. ou sobrecarga (overloading). enviar uma mensagem por correio eletrônico. Em um sistema gerenciador de base de objetos. porém independentes. a definição de procedimentos associados à estrutura. podendo realizar ações que extrapolam o ambiente da base de dados — por exemplo. Herança múltipla refere-se ao mecanismo de herança através do qual um novo tipo de objeto pode ser derivado a partir de mais de um tipo ancestral. o esquema de tipos de objetos passa a ser organizado como uma malha ou grafo de tipos. Restrições de integridade são casos particulares de regras onde as ações estão limitadas a sinalizações de condições de erro. incorporando assim aspectos de linguagem de manipulação de dados. como no caso de atributos virtuais. que incluem os atributos derivados. com o acréscimo de novos atributos. Ademais. Deste modo. Um conceito avançado que pode estar presente um uma linguagem de definição de objetos é o conceito de herança. Quando herança múltipla é suportada. Em um sistema gerenciador de banco de dados tradicional.Ivan L. Entretanto. o esquema de tipos de objetos define uma árvore ou hierarquia de tipos relacionados. regras e agentes. esta evolução de esquemas deve ocorrer de forma mais natural. a implementação de herança múltipla requer cuidados adicionais para lidar com situações como o conflito de resolução para atributos ou métodos. modificações no esquema eram ações que afetavam extremamente as aplicações. Usualmente. Ricarte Bancos de Dados Orientados a Objetos restrições para oferecer um melhor desempenho de execução às custas de se aceitar um grau menor de encapsulação. mais especificamente em sistemas gerenciadores de base de objetos. a semântica de herança múltipla nem sempre é clara. São três as categorias de modificações que implicam em evolução do esquema: mudanças em componentes (atributos . Herança é um mecanismo de implementação do conceito de generalização. 4. Agentes são caracterizados por processos associados ao sistema gerenciador de base de objetos. importante para bancos de dados como ressaltado no trabalho de Smith e Smith sobre abstração de dados. Os novos subtipos podem ser diferenciados dos tipos dos quais foram derivados por mecanismos tais como especialização. através de uma linguagem de definição de objetos. Regras ou triggers são definidos como pares padrão-ação. a modificação de um tipo implica na modificação do esquema de dados.
Ricarte Bancos de Dados Orientados a Objetos ou métodos) de um tipo. através de modificação de nome. A diferença entre estas linguagens de programação e de manipulação de dados dá origem ao problema de "descasamento de impedâncias" (impedance mismatch) entre as linguagens. consegue eliminar completamente o problema do descasamento de impedâncias entre as aplicações. existe um único tipo . mudanças na hierarquia (ou malha) de tipos. Este é o mecanismo mais transparente. nenhuma destas abordagens. Na especificação de persistência por invocação explícita. alguns sistemas estendem linguagens de manipulação de dados com construções procedimentais. re-traduzidos e armazenados de volta à base de dados. a aplicação solicita explicitamente ao sistema gerenciador de base de objetos o armazenamento persistente do objeto em questão. inclusão ou remoção de tipos. descritas a seguir. 4. onde todos os objetos relevantes para a operação da aplicação são recuperados da base de dados. Nesta situação. com o objetivo de maximizar a concorrência de acesso à base de dados. Em geral. manipulados. mas que exige mais em termos de processamento da parte do sistema gerenciador de base de objetos. traduzidos para a representação adequada para a linguagem de programação. Na especificação por referência. e todos os objetos por eles referenciados tornam-se automaticamente persistentes. Em sistemas relacionais. Uma crítica a este modelo é que persistência e especificação de tipos são conceitos ortogonais. Em outra direção de integração. Uma abordagem mais transparente de integração entre linguagens de programação orientadas a objetos e sistemas gerenciadores de base de objetos é a incorporação de mecanismos de persistência de objetos à linguagem de programação. que é endereçado de maneiras distintas em diversos sistemas gerenciadores de base de objetos. um ou mais objetos (as raízes) são declarados como persistentes. a base de dados é utilizada de forma implícita e transparente como meio de manutenção do estado de objetos da aplicação entre sessões. Sybase adotou esta abordagem ao estender SQL com construções de controle de execução para sistemas relacionais. M. Na especificação por tipo. por invocação explícita ou por referência. Uma estratégia de integração de linguagens é o query download. apenas alguns tipos prédefinidos são persistentes. Métodos de especificação de persistência em sistemas gerenciadores de base de objetos podem ser por tipo.Ivan L. e que associar persistência a apenas alguns tipos fere essa ortogonalidade. que nesta situação não conteria nenhuma informação sobre a estrutura do objeto. Uma variante deste esquema limita a operação a um único objeto por interação. aplicações usando bases de dados são desenvolvidas em alguma linguagem de programação e integram expressões de manipulação de dados aos programas. Outros sistemas oferecem novos tipos de dados na linguagem de programação para refletir tipos e operações referentes à base de dados.4 Consultas Um dos principais aspectos a se considerar na manipulação de bases de dados é o mecanismo oferecido para expressar operações sobre os dados. ou mudanças na definição de tipos. Outro aspecto importante relativo a consultas em sistemas gerenciadores de base de objetos refere-se ao tipo de resultado que uma consulta gera. Entretanto. Outra alternativa ainda é armazenar objetos da linguagem de programação como BLOBs na base de dados.
o grau de liberdade é maior. em alguns casos. A junção por valor. identificados e recuperados da base de dados. Versões oferecem um mecanismo alternativo para controle de concorrência. operandos e resultados de consultas são relações. como ocorre em linguagens de programação orientadas a objetos onde objetos são identificados por sua posição na memória. assim como a junção de sistemas relacionais. Através do mecanismo de versões libera-se o sistema de manter uma única cópia de um objeto na base. Um conceito relacionado a este é configuração. A representação de identificadores de objetos pode ser física ou lógica. Uma possível diferença é que sistemas gerenciadores de base de objetos podem (e geralmente o fazem) incluir transações longas e. não necessitando portanto de associações explícitas para sua realização. Em sistemas gerenciadores de base de objetos. Ricarte Bancos de Dados Orientados a Objetos (a relação). Em um sistema gerenciador de base de objetos. o que alivia uma eventual degradação que poderia ocorrer com a incorporação de transações (e consequentemente locks) longas. evoluções alternativas nos estados dos objetos são permitidas. diferentemente do que ocorre em sistemas tradicionais. . M. Com versões. portanto. de recuperação de dados em caso de operações falhas e de manutenção de integridade dos dados. Operações sobre objetos persistentes são usualmente definidas no escopo de transações.Ivan L. Duas variantes da operação de junção em sistemas gerenciadores de base de objetos são a junção por referência e a junção por valor. Consultas envolvendo múltiplos objetos necessitam de alguma forma de mecanismo de junção. coleções de objetos ou até mesmo relações (arranjos tabulares de dados). 4. objeto. o que pode criar dificuldades adicionais na manutenção de consistência dos dados. uma aplicação manipula de forma natural dados transientes e dados persistentes. assim como ocorre em sistemas gerenciadores de banco de dados tradicionais. embora a tendência seja permitir a manipulação de resultados abertos — literal. 4. é preciso que haja mecanismos para controle de acesso concorrente. Alguns sistemas podem limitar a resposta obtida a alguns tipos específicos. um conjunto de versões de objetos mutuamente consistente. A junção por referência utiliza associações definidas na base de objetos para obter objetos associados. A representação física contém o endereço real do objeto. transações aninhadas.5 Concorrência e recuperação Como dados em uma base de dados são persistentes e usualmente compartilhados por várias aplicações e/ou usuários.6 Implementação de identificadores Um dos fatores mais importantes no desempenho de um sistema gerenciador de base de objetos é a forma de implementação da representação de seus objetos — como são armazenados. Configurações equivalem a snapshots (ou visões instantâneas) consistentes da base de objetos. é realizada sobre valores de atributos que compartilham um domínio comum. A representação lógica envolve algum mecanismo de mapeamento entre uma representação interna e o endereço do objeto.
é um processo importante na manipulação de objetos. na linguagem de programação orientada a objetos adotada pela aplicação. M. Evidentemente. na base de objetos. onde valores de atributos chaves são mapeados a identificadores de objetos através de índices hash ou B-trees. e ORION e Itasca adotam surrogates tipados. utilização de endereços estruturados. Em geral. fixar a posição do objeto na base torna-a menos flexível. 4. endereços físicos não são utilizados na prática. e não identificadores de objetos. identificadores lógicos que são mapeados para endereços físicos através de um índice ou de uma tabela. Mudanças na representação interna dos dados podem ser necessárias principalmente quando a base de objetos é . Alguns sistemas garantem que identificadores de objetos removidos não são reaproveitados. Além da referência a objetos por identificadores de objetos. por endereços. modificações na estrutura e no formato de representação de dados. Ricarte Bancos de Dados Orientados a Objetos As quatro abordagens básicas de implementação de identificadores são utilização simples do endereço. onde a informação sobre o tipo do objeto é incluída no identificador lógico. A tradução de identificadores de objetos para referências a objetos na linguagem de programação é a principal atividade desempenhada durante o swizzling. e sua representação dinâmica. sendo determinante para o desempenho do sistema gerenciador de base de objetos. Porém. Identificadores de objetos são utilizados tanto pelas aplicações como pela própria base de objetos. Referências dinâmicas são tipicamente ponteiros na linguagem de programação. A unicidade de um identificador de objeto é um aspecto fundamental para a manutenção da consistência de uma base de objetos. incorporando o endereço da máquina servidora no identificador de objeto. que contém uma componente lógica e outra física. para representar associações entre objetos. Mudanças na estrutura podem ocorrer através da incorporação de cabeçalhos e campos para utilização em tempo de execução. dificultando operações como relocação de objetos. outros buscam garantir unicidade entre múltiplas bases de objetos interligadas em rede. A relocação pode ser necessário para ampliar o espaço de armazenamento associado a um objeto ou realizar uma compactação ou reclustering da base de objetos. onde o objeto será efetivamente manipulado.7 Swizzling Swizzling é o processo de conversão entre a representação persistente do objeto. utilização de surrogates. um identificador físico. Identificadores de objetos puramente físicos. Por este motivo. O mecanismo para garantir unicidade pode variar entre implementações distintas. A conversão que deve ocorrer através de swizzling envolve tipicamente traduções de referências e. e a utilização de surrogates tipados. eventualmente. a implementação deste mecanismo em sistemas gerenciadores de base de objetos é similar àquela de sistemas tradicionais. oferecem o melhor potencial de desempenho para recuperação de objetos. ONTOS e Objectivity/DB utilizam endereços estruturados. diversos sistemas oferecem a possibilidade de se localizar um objeto através de atributos chaves.Ivan L. GemStone e POSTGRES utilizam surrogates.
A abordagem de imagem do disco. Se o sistema gerenciador de base de objetos for compartilhado por muitas aplicações. embora eficiente. é referenciado pela primeira vez pela aplicação. ou granularidades. o tráfego de dados pela rede é reduzido. 4. Este risco está presente principalmente quando a aplicação utiliza uma linguagem de programação onde é permitido aos programas examinar e alterar qualquer posição de seu espaço de memória — como ocorre em C++. Ricarte Bancos de Dados Orientados a Objetos compartilhada em ambientes heterogêneos. pois uma página pode conter mais informação que a solicitada pela aplicação. Entretanto. uma das quatro abordagens a seguir é adotada: 1. Quando a granularidade adotada é um objeto ou um resultado de consulta. distintas. Esta última abordagem é adotada em ObjectStore. o qual é registrado também na base de dados. seria necessário que o sistema gerenciador de base de objetos impusesse mecanismos adicionais de manutenção da integridade dos dados em uma página manipulada pela aplicação. Tipicamente. objetos ou resultados de consultas. o tráfego de dados pela rede é ampliado. as granularidades adotadas são páginas. Entretanto. A conversão ocorre quando não é possível reaproveitar um endereço físico designado anteriormente. M. Tipicamente. A conversão ocorre no momento em que o objeto. por exemplo. Em tais situações. Swizzling pode ocorrer em momentos distintos. 2. A abordagem mais utilizada nas implementações de sistemas gerenciadores de base de objetos é passar para a aplicação uma imagem do disco. adotando granularidade de uma página (Fig. 3. um alto número de requisições simultâneas pode ter impacto significativo no desempenho do servidor. 6). Esta abordagem simplifica o trabalho do servidor de páginas. onde o processamento será mínimo. A conversão ocorre no momento em que o objeto é transferido da base de objetos para o espaço de memória da aplicação (checkout). 4. exige-se nessas situações que o servidor de objetos já realize algum processamento sobre a base de objetos. de acordo com a implementação adotada para este mecanismo. que busca explorar a grande capacidade de endereçamento virtual dos processadores modernos para alocar um objeto sempre à mesma posição de memória virtual. pode apresentar riscos à integridade dos dados presentes na página. A conversão ocorre no momento em que a aplicação a solicita explicitamente. pois garante-se que a aplicação estará recebendo apenas o que foi solicitado. evitando sua degradação através de . já transferido para a memória.Ivan L.8 Granularidade de transferência Bases de objetos podem transferir informação entre o disco e a memória em unidades de dimensão.
(2) swizzling. (3) manipulação do objeto pela aplicação. o tamanho do valor do atributo e o valor. não permitindo operar de modo eficiente com atributos de dimensões variáveis. o registro de quais objetos estão na memória da aplicação. Ricarte Bancos de Dados Orientados a Objetos Área de memória da aplicação aplicação página objeto (3) (2) (4) Área de armazenamento do servidor página objeto (1) Figura 6: Abordagem de imagem do disco com servidor de páginas: (1) transferência de página (checkout) do servidor para cliente. . Informação típica de run time para um objeto inclui o mapeamento de um identificador de objeto para endereço físico. a evolução de esquema pela inclusão de atributos e o armazenamento eficiente para atributos não utilizados por um objeto. M. esta alternativa limita severamente a flexibilidade de representação para objetos. manutenção de dirty bits para indicar se objetos foram atualizados ou apenas consultados. Entretanto. Abordagens para manipulação deste tipo de informação incluem a manutenção de tabelas em memória. Listas de propriedades oferecem um mecanismo mais versátil de implementação de atributos de um objeto.Ivan L. com campos de dimensão fixa. com coleções com quantidade variável de elementos. representando um identificador de atributo. como foi proposto por alguns protótipos iniciais de sistemas gerenciadores de base de objetos. Uma lista de propriedades é composta por elementos contendo três campos. (4) reconversão para formato do disco e transferência de página (checkin) do cliente para o servidor. e contadores de referências para sustentar atividades internas de swapping e garbage collection. as implementações correntes de sistemas gerenciadores de base de objetos não incorporam mecanismos com este fim. 4. Citou-se como uma das atividades durante o swizzling a incorporação de informação para manipulação de objetos em tempo de execução. Entretanto. Este mecanismo é flexível. utilização de descritores de objetos e incorporação de status bits no próprio objeto. ações inadvertidas ou maliciosas.9 Atributos A forma de implementação mais simples para a representação de atributos de um objeto seria utilizar relações.
4. Como coleções podem ser demasiadamente extensas e/ou conter objetos grandes. tais como inserção e remoção de bytes na posição corrente. oferecendo métodos tais como produzir o próximo elemento da coleção (lista) ou buscar o -ésimo elemento da coleção (arranjo). nem sempre este mecanismo é suportado em sistemas gerenciadores de base de objetos. Apesar de estar presente em muitas aplicações. mecanismos mais elaborados são necessários para estabelecer priridades na concatenação e resolver conflitos entre tipos ancestrais com atributos de mesmo nome. e assim recursivamente até encontrar os atributos do tipo de objeto que é a raiz da hierarquia. sem critérios de ordenação entre elementos) são suportadas. a aplicação tem o objeto completo em memória virtual. por indexação. um stream permite referenciar objetos sem que esses estejam completamente concretizados em memória. onde apenas coleções do tipo conjunto (assim como relações. Por exemplo. Em sistemas onde apenas herança simples é permitida. Um piece stream é um mecanismo de stream com facilidades adicionais que permitem a atualização de conteúdo do BLOB. A importância da ordenação da coleção é reconhecida de longa data. é preciso oferecer mecanismos que permitam manipulá-las de modo mais eficiente. & . A estratégia de implementação pode depender da multiplicidade das associações. a lista de propriedades de um objeto é composta pela concatenação dos atributos do tipo do objeto com os atributos do tipo de objeto ancestral. ler e escrever blocos de dados binários. M. Alternativas para a manipulação de BLOBs incluem a paginação por demanda e utilização de piece streams. o modelo CODASYL definia associações de ordenação manual (critério de ordenação estabelecido pela aplicação) e automática (estabelecido pelo sistema sobre algum atributo da coleção). A manipulação de atributos do tipo BLOB é usualmente implementada através de interfaces stream. com métodos para posicionar. Para lidar com herança múltipla. Neste caso. sendo que páginas do objeto são transferidas para a aplicação à medida que seus bytes são referenciados. o mecanismo de lista de propriedades é ainda adequado. O principal mecanismo adotado é a utilização de objetos iteradores. Ricarte Bancos de Dados Orientados a Objetos porém demanda um maior grau de processamento da parte dos métodos que manipulam a estrutura interna do objeto. Na paginação por demanda.10 Associações A implementação de relacionamentos não precisa refletir diretamente a forma como a aplicação os define conceitualmente. Manipulação de coleções é outro aspecto crítico em sistemas gerenciadores de base de objetos. Um iterador é um objeto temporário que contém referências aos membros da coleção. um relacionamento um-para-muitos pode ser representado por contiguidade física.Ivan L. Herança é outro aspecto que traz impacto na representação de atributos. Assim como iteradores. sendo esse mecanismo amplamente utilizado na descrição de estrutura de atributos de objetos e no retorno de consultas. Um tipo de associação implícita entre os elementos de uma coleção é a ordenação. por ligação ou através de objetos intermediários criados pelo sistema gerenciador de base de objetos.
Referências: adota a existência de relacionamentos quaisquer entre objetos para direcionar a proximidade de armazenamento. indicando que os dois devem ser armazenados em posições próximas. 4. Assim. A seleção de um critério de clustering deve depender da forma de recuperação mais adotada para o objeto na aplicação. o conceito de clustering é adotar alguma estratégia de alocação de objetos no sistema de armazenamento de modo a minimizar a quantidade de páginas necessárias para manipular objetos.11 Clustering A incorporação do conceito de objeto complexo em sistemas gerenciadores de base de objetos introduz grande flexibilidade de estruturação dos dados. Este é um critério equivalente ao adotado pela maior parte dos sistemas gerenciadores de banco de dados relacionais. que potencialmente podem estar distribuídos em diversas páginas espalhadas pelo disco. Simplesmente colocado. para buscar a melhor posição de armazenamento de um objeto. em tempo de execução. Assim. o conteúdo de um objeto complexo é composto por outros objetos. As estratégias de clustering mais utilizadas são: Objetos complexos: adota o relacionamento de agregação para identificar objetos que devem ser armazenados próximos — preferencialmente. M. Afinal. Tipos de objetos: adota o critério de aproximar o armazenamento de objetos de uma mesma classe. Alternati- vamente. Ricarte Bancos de Dados Orientados a Objetos Outro aspecto importante na implementação de associações é a manutenção da integridade referencial. em sistemas CAD provavelmente a estratégia de objetos ( ' ) 10( ' ( ' ) . denotada . Um exemplo de implementação utiliza um identificador de um objeto existente como parâmetro na criação de um novo objeto. Índices: adota o valor de um atributo como critério de ordenação dos objetos. A estratégia de clustering por objetos complexos é um caso especial desta estratégia. O mecanismo mais amplamente adotado para este fim é a utilização de pares de atributos inversos. e aproxima o armazenamento de objetos com valores próximos neste atributo. Clustering é um mecanismo que pode ser adotado para minimizar esta degradação no desempenho.Ivan L. recuperar o conteúdo de um objeto complexo pode acarretar em várias solicitações de páginas do servidor para o cliente. Por outro lado. o sistema gerenciador de base de objetos cria internamente a referência . na mesma página ou em páginas contígüas. a recuperação de objetos complexos pode introduzir degradação no desempenho dos sistemas. Por exemplo. o sistema pode implementar um contador de referências para o objeto. onde tuplas de uma mesma relação são armazenadas contigüamente. Definição do usuário: utiliza um indicativo da aplicação. se a aplicação define uma referência de um objeto para um objeto . só permitindo sua remoção quando o valor deste contador for nulo.
qualquer modificação no tipo de um objeto é imediatamente refletida para os objetos. Na estratégia de atualização posterior. Nesta estratégia. atualização posterior. Modificações no tipo. atualização imediata. A estratégia de tipos de uma escrita (ou tipos write-once) é a abordagem mais simples. a estrutura de um objeto cujo tipo tenha sido modificado não é alterada a não ser no primeiro momento em que o objeto é acessado após a alteração do tipo. que determina que qualquer tipo que já contenha pelo menos uma instância não pode ser modificado. não tendo sido implementada em nenhum sistema gerenciador de base de objetos até o momento. até o momento em que uma reorganização da base de objetos seja explicitamente solicitada. Mudanças no esquema devem obedecer a tais restrições. 4. Há quatro estratégias básicas que determinam como um esquema pode evoluir: tipo de uma escrita. Entretanto. envolvendo seqüências de recuperações em ordem alfabética. a inclusão de um novo atributo em um tipo faria com que todos os objetos daquele tipo tivessem sua estrutura atualizada oara conter um campo adicional contendo o valor nulo. a implementação de tal estratégia seria extremamente complexa. é preciso que o sistema gerenciador de base de objetos mantenha informação histórica sobre a evolução de esquemas e sobre procedimentos de conversão para poder manter a consistência da base. determinando como esquemas podem evoluir. restrições de acesso são impostas como forma de manutenção da integridade da base de objetos. e mapeamento de esquema. Nesta abordagem. o que possibilitaria que usuários pudessem ter visões de um mesmo objeto sob diferentes versões de esquema. Nesta estratégia é preciso manter os mapas de conversão entre todas as possíveis versões de esquema. . Ricarte Bancos de Dados Orientados a Objetos complexos seria a preferencial. o esquema de dados é em si armazenado como um objeto. A estratégia de atualização imediata é a mais adotada em sistemas gerenciadores de base de objetos correntes. deve ser explicitamente desempenhada pela aplicação através da criação de um novo tipo e cópia do conteúdo de objetos já existentes para objetos do novo tipo. Assim. Tais estratégias são brevemente apresentadas a seguir. tal como a inclusão de um novo atributo.Ivan L.12 Evolução de esquemas Em grande parte dos sistemas gerenciadores de base de objetos. enquanto que para uma aplicação comercial. M. Entretanto. a estratégia de índices seria a mais adequada. A estratégia de mapeamento de esquema equivale a uma estratégia de atualização posterior onde o momento de atualização é postergado indefinidamente. este objeto nem sempre é diretamente manipulável pela aplicação em tempo de execução.
apresentase inicialmente um protótipo sobre o qual informação sobre a implementação é bem conhecida. A parte superior da figura representa módulos relativos ao esquema de objetos. que em se tratando de sistemas comerciais geralmente não é possível obter informação detalhada sobre os mecanismos de implementação do sistema. tipos de objetos são identificados por um nome. A arquitetura de UniCOSMOS é apresentada na Fig. 39]. cinco listas internas mantêm informação sobre: 1. Neste sistema.valor subsistema de acesso a objetos iv domínio de valores domínio de iv objetos Figura 7: Arquitetura de UniCOSMOS. objetos).Ivan L. O subsistema de acesso a tipos mantém uma tabela hash que associa os nomes de objetos a surrogates tipados (id). nome do tipo id subsistema de acesso a tipos nome domínio de tipos de objetos iv ir id io id io domínio de tríades domínio. 5. sendo possível associar mais de um nome para um mesmo tipo de objeto. 3. Para cada tipo de objeto. entretanto.1 UniCOSMOS UniCOSMOS (University of Campinas Object Storage Management System) foi um protótipo desenvolvido na UNICAMP no período 1985–1989 para aplicações em engenharia [28. 2. mas sim um núcleo para tais sistemas onde alguns dos mecanismos básicos de manipulação de objetos persistentes poderiam ser avaliados. as associações com outros tipos de objeto. os nomes do tipo de objeto. . Um mecanismo de sinônimos é suportado. M. enquanto que a parte inferior representa módulos que manipulam instâncias (ou seja. O domínio de tipos de objetos registra a informação sobre o esquema da base de dados. UniCOSMOS não era um sistema gerenciador de base de objetos. 7. Efetivamente. Por este motivo. Ricarte Bancos de Dados Orientados a Objetos 5 Exemplos Nesta seção serão descritos alguns exemplos de sistemas gerenciadores de base de objetos. os atributos do tipo de objeto. Devese observar.
e cada elemento da lista é formado por um identificador de atributo (referente ao identificador do tipo de objeto. em estações de trabalho Unix. Para facilitar a manutenção . O principal módulo do sistema é o EngenhoO . manipulação de herança [43] e a implementação de um gerenciador de dados para projetos de engenharia manipulando esquemas entidade-relacionamento estendidos com mecanismos para objetos complexos e evolução de esquemas [40].2 O 'D)C5A)B( 5A@9#' ) ( ) ( ) ' ) 80765 ( )2 43¦ ' . Cada lista de propriedades é identificada por um surrogate de objeto (io). caso o objeto seja complexo. Cada elemento desta lista. M. Neste módulo são implementados os mecanismos para agilizar acesso à informação. O desenvolvimento do Sistema O [15] iniciou-se como um protótipo de pesquisa. Para agilizar a realização destas combinações. é preciso combinar este resultado com o resultado de uma busca no nível de esquema. Os valores são armazenados de fato no domínio de valores.Ivan L. diversos métodos de manipulação de surrogates são oferecidos às aplicações de UniCOSMOS. criado internamente. Assim. Ricarte Bancos de Dados Orientados a Objetos 4. A flexibilidade das listas de propriedades permite manipular adequadamente atributos com valores nulos. através do nome do objeto. uma referência é mapeada internamente para uma tríade da integridade referencial. tais como estruturas de índices. objetos são representados através de listas de propriedades armazenadas no domínio de objetos. id) e por um identificador de valor (iv). Associações são representadas internamente por tríades. o domínio de tríades armazena todas as permutações de cada associação. caso o objeto faça parte de um objeto complexo. contém a dimensão e a representação interna do valor. O sistema foi implementado em linguagem C. o conjunto de elementos dos quais os valores de atributos são tomados) é composto por uma lista de propriedades para valores. onde cada domínio (no sentido matemático da palavra. No nível de instâncias. ou associações binárias. Como domínios podem ser compartilhados por vários tipos de objeto. estruturado em três camadas: E E E E 5. os tipos de objetos componentes. O subsistema de acesso a objetos tem por objetivo apoiar atividades de consultas por valor à base de objetos. multivalorados e de dimensão variável. Desenvolvimentos relacionados a UniCOSMOS incluíram o tratamento de transações convencionais e longas [35]. 5. os tipos de objetos que contêm este tipo como componente. tratamento de regras e de restrições [30]. também são armazenadas neste domínio as tríades e . as respostas a consultas são organizadas na forma de listas de surrogates io. O sistema foi desenvolvido em C++ para plataformas Unix. A ligação entre dois tipos de objetos é estabelecida por um terceiro tipo de objeto. Para restringir a busca a um único tipo de objeto. posteriormente convertido para um produto comercial da empresa francesa O Technology. Assim. Cada tríade registrada neste domínio é identificada por um surrogate ir. identificado por um surrogate iv.
onde a aplicação gerenciador de disco atua como um servidor de páginas. ObjectStore oferece suporte para identificação de objetos. em C++ e. Para a aplicação. Identificadores de objetos são registrados internamente sob a forma de endereços estruturados. com campos para identificação de um volume de dados (2 bytes). de Burlington. direta ou indiretamente. strings e bits) ou complexos. criados a partir de construtores de tuplas. arranjos e dicionários. bags.. A interação entre ObjectStore e a aplicação pode ocorrer através de uma linguagem de manipulação de dados ou através de interfaces de programação em C. ObjectStore é um dos sistemas mais próximos desta linguagem em termos semânticos. através de uma linguagem declarativa (O C) ou através de O SQL. Objetos em O podem ser atômicos (inteiros. A Fig. camada intermediária que fornece identificação de objetos e implementa estratégias de indexação e clustering. Bags são conjuntos que permitem duplicação de elementos. também é oferecido. acesso paginado a BLOBs e aplicações interativas para visualização de conteúdo e criação de esquemas. recuperação. booleanos. Gerenciador de disco. o mecanismo E E E . são persistentes. responsável por monitorar criação. objetos que são derivados de uma raiz persistente. combinado com uma identifcação de página no volume (4 bytes) e uma posição (slot) na página (2 bytes). Ricarte Bancos de Dados Orientados a Objetos Gerenciador de esquema. que inclui conjuntos. Um dos objetivos iniciais no desenvolvimento deste sistema era fazer de C++ uma linguagem de programação de banco de dados.3 ObjectStore ObjectStore [32] é um sistema comercial de banco de dados orientado a objetos desenvolvido pela Object Design Inc. 8 apresenta uma árvore de decisão associada à definição da melhor forma de coleção para uma aplicação [33]. uma extensão de SQL para lidar com objetos complexos. O mecanismo de mapeamento de objetos para o espaço de memória virtual torna a persistência natural em ObjectStore. Por este motivo. reais. herança múltipla. onde qualquer dado pode se tornar persistente. 5. conjuntos. Gerenciador de objetos. Massachusetts. listas. Manipulação de coleções é oferecida através de bibliotecas de tipos de coleções. atributos inversos. Um tipo genérico. responsável por implementar as estruturas de arquivos (paginados) que armazenam fisicamente os dados dos objetos do sistema. coleção. Assim. As camadas mais elevadas do sistema são organizadas na forma de uma aplicação cliente. M. A interação de uma aplicação com o sistema pode ocorrer através de interfaces de programação em C ou C++. atualização e remoção de classes.0. Persistência é definida por referência. Dicionários são bags onde a cada elemento é associada uma chave. que pode executar em uma máquina conectada ao servidor ba base de dados. bags e arranjos.Ivan L. em Java. descritores de objetos são utilizados. métodos e nomes globais. desde a versão 5.
dificultando a portabilidade do sistema entre plataformas distintas. com ênfase nos aspectos de padronização e futuras aplicações. Um aspecto negativo nesta estratégia é que este mecanismo exige a manutenção de mecanismos de pré-processamento. caracterizando ObjectStore como tendo uma arquitetura múltiplos clientes e múltiplos servidores. Ricarte Bancos de Dados Orientados a Objetos Permite mudanças entre coleções ordenadas e desordenadas. Um cliente pode acessar informação de diversos servidores. 9). 6. de persistência é ortogonal à hierarquia de tipos. uma vez que objetos sejam transferidos para a memória principal após um page fault. 6 Esforços correntes e direções futuras Nesta seção final é feito um breve apanhado de esforços correntes que poderão afetar o desenvolvimento futuro de sistemas gerenciadores de base de objetos. sua manipulação é tão rápida como a de qualquer objeto não persistente da linguagem de programação. M. O lado cliente de ObjectStore é implementado através de um Cache Manager. Aplicações de ObjectStore utilizam dois processos para sua execução. formado em 1991 por diversos fabricantes de sistemas gerenciadores de base de objetos. que tem por objetivo criar um padrão para bancos de dados orientados a objetos que permita ampliar o grau de portabilidade das aplicações .1 ODMG ODMG (Object Database Management Group) é um consórcio. Por outro lado. O servidor de páginas é o ObjectStore Server.Ivan L. ou entre desordenadas com duplicatas e desordenadas sem duplicatas sim não os_Collection Mantém a ordem de inserção não sim Associa chave a cada elemento sim não Adição automática de número especificado de elementos nulos não sim os_Dictionary Permite duplicatas não sim os_List os_Array os_Set os_Bag Figura 8: Árvore de decisão para tipos complexos em Object Store. que está executando permanentemente em uma máquina onde os dados estão armazenados. que é ativado automaticamente pela aplicação (Fig.
estabelece o mapeamento das construções do padrão para aquelas de linguagens de programação.. tais como a arquitetura. busca-se com ODMG atingir um grau de padronização similar para sistemas gerenciadores de base de objetos. Poet Software. O modelo de objetos de ODMG sumariza diversos conceitos suportados por sistemas gerenciadores de base de objetos. Entretanto. a linguagem de declaração (ODL) e uma linguagem declarativa de consulta (OQL).. O foco deste padrão foi na integração de sistemas gerenciadores de base de objetos a linguagens de programação. Literais E . Servio e Texas Instruments. apenas oferecem uma interface comum para as aplicações. para poder definir interfaces padronizadas entre sistemas gerenciadores de base de objetos e linguagens de programação era necessário inicialmente ter uma visão comum de como um sistema gerenciador de base de objetos deveria estar estruturado e de quais seriam os seus componentes. Pelo menos estas empresas concordaram em tornar seus produtos compatíveis com o padrão ODMG para sistemas gerenciadores de base de objetos. Deve ser enfatizado que não há uma padronização da implementação. Smalltalk e Java são contempladas no padrão. 10. Os participantes do consórcio ODMG incluem Object Design.Ivan L. O Technology. framework e bindings. Intellitic. Atualmente. os produtos de cada empresa não são idênticos. C++. O padrão ODMG está organizado em duas componentes principais. Ele oferece objetos e literais como primitivas de modelamento. ou seja. M. O resultado deste primeiro esforço foi a definição de uma arquitetura comum. apresentada na Fig. o modelo de objetos. Assim como SQL permite oferecer para uma aplicação uma visão comum de bases de dados relacionais. Hewlett-Packard. Versant. Digital Equipment. independente do fabricante. desenvolvidas para os seus diferentes sistemas [9]. servidor cache manager aplicação cache manager aplicação aplicação Figura 9: Processos na arquitetura de ObjectStore. Itasca. O conjunto de bindings. Em framework definem-se aspectos comuns a todas as linguagens de programação. Ricarte Bancos de Dados Orientados a Objetos aplicação servidor cache manager . Objectivity. ONTOS.
entre outros. estabelece a funcionalidade de uma camada middleware. List e Array) ou estruturados (Date. podem ser atômicos (Long. Time. serviços de segurança. que podem ser atributos ou relacionamentos. M. Timestamp. CORBAservices. Octet.2 OMG OMG (Object Management Group) [34] é um consórcio industrial. adotando para tal o paradigma de objetos distribuídos. O principal resultado do OMG foi a definição de uma arquitetura para o desenvolvimento de aplicações por objetos distribuídos. O comportamento do objeto é definido pelo conjunto de operações que podem ser executadas sobre o objeto. formado em 1989. 6. busca por propriedades (trader). de transações e de notificação de eventos. . O estado de um objeto é definido por suas propriedades.. CORBA (Common Object Request Broker Architecture) (Fig. 11). Atualmente o consórcio engloba mais de 800 participantes. Um banco de dados armazena objetos. permitindo que estes sejam compartilhados por múltiplos usuários e aplicações. Um banco de dados é baseado em um esquema que é definido em uma linguagem de definição de objetos e contém instâncias de tipos definidos por seu esquema. cujo objetivo é definir padrões para permitir inter-operabilidade em sistemas distribuídos heterogêneos. . um objeto é denominado uma instância de um tipo. . ). Bag. Objetos podem ser atômicos ou coleção. Ricarte Bancos de Dados Orientados a Objetos Declarações em ODL Programa aplicação pré-processador compilador SGBO runtime Código objeto metadados ligador acesso aos dados base de dados Código executável Figura 10: Arquitetura de um sistema gerenciador de base de objetos no padrão ODMG. Esta arquitetura. que incluem serviços de busca de objetos por nome (naming). Float. coleção (Set. o ORB (Object Request Broker) e as funcionalidades de serviços de objetos padrões. elementos de um mesmo tipo têm estrutura e comportamento comuns.Ivan L.. Algumas vezes. ). Objetos e literais são categorizados por seus tipos. . .
Um exemplo de uma facilidade nesta categoria é o Distributed Document Component Facility. Ricarte Bancos de Dados Orientados a Objetos Common Facilities Domain interfaces Application interfaces ORB CORBAservices Figura 11: Arquitetura de gerenciamento de objetos (OMA). Como mostra a Fig. particularmente para aplicações multimídia. tais serviços estão mais próximos em nível de abstração do usuário final. Antevê-se que a combinação destas duas linhas de desenvolvimento seja a direção para as novas aplicações de sistemas de informação em ambientes distribuídos. M. 12. não sendo portanto objeto de padronização. Além disto. Domain Interfaces ou Application Interfaces [42]. ORB tradução localização heterogeneidade invocação remota SGBO descrição identificação distribuição armazenamento transações versões consultas Figura 12: Funcionalidades ORB e ODMG. mas apresentam um alto grau de complementação de serviços oferecidos. Common Facilities incluem serviços de propósito geral. para a manipulação de documentos compostos. porém. ORB e bancos de dados aderentes à proposta ODMG apresentam alguma sobreposição de funcionalidades. . As interfaces de aplicação são componentes da arquitetura específicos de uma aplicação. Assim como CORBAservices. outras categorias de aplicação poderiam analisar qual plataforma atende melhor às suas necessidades para selecionar a estratégia de implementação. Similarmente. As interfaces de domínio são serviços especializados para dadas categorias de aplicações. telecomunicações e medicina. outros tipos de serviços podem estar agrupados em Common Facilities. foi apresentada por Tobar [49]. enquanto CORBAservices apresentam nível de abstração baixo.Ivan L. como em área financeira. Uma análise da integração entre sistema gerenciador de base de objetos e CORBA.
M. A chave para atingir esta próxima etapa na tecnologia de banco de dados está na generalidade. Ao contrário do paradigma de desenvolvimento que dominou o final da década de 1970 e praticamente toda a década de 1980. quando havia dezenas ou centenas de sistemas gerenciadores de banco de dados especializados para a aplicação cada aplicação. O oferecimento de tais serviços torna-se interessante à medida que eles não são de uso exclusivo de um banco de dados ou de uma aplicação. Esta abordagem de oferecimento de serviços atende de forma muita adequada às novas categorias de aplicação em sistemas de informação. No entanto. Provavelmente. e assim por diante.Ivan L. o objetivo atual é oferecer serviços básicos. Banco de dados é apenas uma das áreas que vem se beneficiando desta tecnologia. de pesquisa. no entanto. com utilização efetiva nas mais diversas categorias de aplicação. Assim. onde a tecnologia de objetos distribuídos vem se destacando. O que há algum tempo atrás era apenas uma buzzword que dava um "ar de modernidade" para algumas aplicações é atualmente uma tecnologia relativamente madura. Dificilmente seria possível desenvolver um sistema gerenciador de banco de dados especializado que atendesse adequadamente às necessidades de todas aplicações multimídia ou hipermídia. há atualmente produtos em bancos de dados orientados a objetos que utilizam uma tecnologia que já está razoavelmente amadurecida. é perfeitamente viável imaginar que tais aplicações serão atendidas através da combinação de serviços especializados de armazenamento. da mesma maneira que assim o serão serviços de interfaces gráficas com usuários ou invocação dinâmica de serviços distribuídos. Ricarte Bancos de Dados Orientados a Objetos 6. os serviços de um sistema gerenciador de base de objetos poderão ser incorporados a aplicações de forma uniforme e transparente. uma necessidade de se estender as funcionalidades desses serviços de bancos de dados para qualquer aplicação desenvolvidas em frameworks de objetos distribuídos. A segunda pode ser resumida pela palavra inter-operabilidade. A primeira pode ser resumida através das palavras generalidade e adaptabilidade. de consulta. possivelmente configuráveis. por exemplo. as pesquisas nesta área seguem duas diretrizes fundamentais. Para atingir este objetivo. Há ainda. o mesmo serviço de pesquisa que é utilizado por uma aplicação multimídia poderia ser utilizado em uma outra aplicação em data mining. Nesta abordagem. mais do que simplesmente oferecer a capacidade de ter um repositório orientado a objetos para aplicações isoladas. ou para a aplicação . a importância de sistemas gerenciadores de base de objetos será permitir a integração de aplicações em ambientes de objetos distribuídos. Desenvolvimentos em design patterns são emblemáticos desta diretriz. Em suma. que possam ser integrados de acordo com as necessidades de G F .3 Conclusões A tecnologia de orientação a objetos está permeando praticamente todas as novas aplicações computacionais. atendendo a muitas aplicações. pois estas variam muito de acordo com o caráter da aplicação. incluindo a manipulação de informação multimídia e hipermídia.
Semantics and implementation of schema evolution in object-oriented databases. F. ter Bekke. G. editor. Cattell. Blasgen. 1993. [11] Peter P. e R. D. Watson. M. W. Abiteboul e P. R. G. Dezembro 1979. Traiger. Galareneau. Revised edition. G. The two facets of object-oriented data models. Putzolu. Bruce Schuchardt. G. Allen Otis. B. . A relational model of data for large shared data banks. King. Schkolnick. System R: Relational approach to database management. Em Kim e Lochovsky [25]. G. D. Astrahan. e R. H. Griffiths. capítulo 12. e Monty Williams. Codd. A. Lorie. J. ACM Transactions on Database Systems. Gray. D. J. ACM Transactions on Database Systems. Putzolu. e J. N. W. Junho 1991. R. Junho 1970. . R. M. P. R. W. R. 13(6):377–387. 34(10):64–77. Março 1976. G. Codd. G. Communications of the ACM. 1987. 1994. [4] Jay Banerjee. Lorie. L. 1(2):97–137. e Henry F. The GemStone object database management system. T. W. [3] T. P. [12] E. IBM Systems Journal. J. Stein. Selinger. R. W. páginas 311–322. A. Semantic Data Modeling. D. The GemStone data management system. Extending the database relational model to capture more meaning. [2] M. Lindsay. Ricarte Bancos de Dados Orientados a Objetos Referências [1] S. Ayers. Jacob Stein. P. 4(4):397–434. 1(1):9–36. Chamberlin. Julho 1991. G. H. J.Ivan L. Chen. Price. Communications of the ACM. Junho 1976. B. Strong. A. Prentice Hall. 4(4):46–49. páginas 283–308. McJones. [6] M. M. Object Data Management: Object-Oriented and Extended Relational Database Systems. Journal of Object-Oriented Programming. Zoeller. Em Proceedings of the ACM SIGMOD Conference. F. D. Harold Williams. [8] P. 20(1):41–62. G. Development of ITASCA. 1992. V. Chamberlin. W. M. [13] E. I. Wade. Astrahan. K. Eswaran. IEEE DB Engineering Bulletin. Mehl. Cattell. P. Traiger. [9] R. King. R. System R: An architectural overview. David Maier. e V. Kanellakis. Gray. I. 14(2). Outobro 1991. Addison-Wesley. P. Wade. Hyoung-Joo Kim. San Mateo. Morgan–Kaufmann Publishers. J. Yost. D. Barry. D. E. J. F. W. Slutz. Otis. Mehl. [7] Robert Bretl. Jason Penney. Blasgen. B. R. Butterworth. F. CA. L. Won Kim. K. Korth. 1981. ACM Transactions on Database Systems. M. [10] R. [5] J. Dolejsi. A. M. The entity-relationship model — toward a unified view of data. The Object Database Standard: ODMG–93. W. N. R.
[25] Won Kim e Frederick H. W. C. Nat Ballou. 1989. ACM Computing Surveys. . Em Kim e Lochovsky [25]. páginas 251–282. Garza. H. Beech. [24] Won Kim. and Applications. [19] Adele Goldberg e David Robson. CA.com/doc/language_specification/index.com/docs/ white/langenv/. Gosling. M. Risch. A. Lyngbaek. Making Smalltalk a database system. Java Series. Delobel. Mahbod. Em Kim e Lochovsky [25]. [16] Ramez Elmasri e Shamkant B. D. Hong-Tai Chou. Guy M. 2(1). Semantic database modeling: Survey. ACM. W. Ricarte Bancos de Dados Orientados a Objetos [14] George Copeland e David Maier. Setembro 1989. Sun Microsystems. Benja- min/Cummings Publishing Company. ACM Press. [20] J. B. Steele. Object-Oriented Concepts. 1986. Interoperability and Beyond. Mountain View. Leichner. Hoch. Fundamentals of Database Systems. P. 1984. and research issues. [22] Richard Hull e Roger King. Database System Concepts. Ioannidis. capítulo 11. T. SIGMOD Record (ACM Special Interest Group on Management of Data). [23] Won Kim. 8(1):7–42. The Java Language Specification.javasoft. capítulo 10. Davis. Evolution of data-base management systems. [21] James Gosling e Henry McGilton. M. S. J. [18] J. Junho 1990. e Hamid Pirahesh. ACM Press. Wilkinson.html. Fry e E. Addison-Wesley. 19(3):201–260. Smalltalk-80. B. editores. H. [27] George Lapis. e Darrel Woelk. Modern Database Systems: The Object Model. The Language.. Y. P. C. páginas 219–250. Chow. http://www. Lohman. Korth e Abraham Silberschatz. IEEE Transactions on Knowledge and Data Engineering. Addison-Wesley Series in Computer Science. Inc. Maio 1996. K. Jorge F. Fishman.Ivan L. Lochovsky. D. Databases. Features of the ORION object-oriented database system. ACM Computing Surveys. Março 1976. Addison-Wesley. Joy. Deux. DeWitt. Em Proceedings of the SIGMOD Conference. Setembro 1987. J. McGraw-Hill. Shan. [15] O. Annevelink. páginas 316–325. Overview of the Iris DBMS.sun. e G. Navathe. http://java. segunda edição. E. Neimat. G. Sibley. 1995. e W. Kent. T. editor. C. 19(2). [26] Henry F. 1994. The Java Language Environment: A White Paper. M. Frontier Series. applications. Hasan. The story of O2. Connors. et al. W. [17] D. Março 1990. Starburst is born. 1996.
Ricarte Bancos de Dados Orientados a Objetos [28] Léo P. Em V Simpósio Brasileiro de Banco de Dados. Regina C. [40] Ivan L. e Harry Wong. Porto Alegre. Em Proceedings of the 13th VLDB Conference. Mark Chignell. Computer Applications in Production and Engineering. Implementação de um banco de dados não-convencional: a experiência GERPAC/UniCOSMOS. MOODS: a modular. Maio 1991. MA. MA. páginas 53–63. 1998. Em VI Simpósio Brasileiro de Banco de Dados. Kimura e A. Rolstadås. 1989. Em II Simpósio Brasileiro de Banco de Dados. Em Kim e Lochovsky [25].omg. Olguín. M. páginas 225– 229. http://www. Maio 1987. IEEE Computer. Em IV SBBD — Simpósio Brasileiro de Banco de Dados. Armando L. páginas 22–38. e Carlos José M. Ricarte e Armando L. OMG home page. SIGPLAN Notices. Abril 1989. N. [37] Joan Peckham e Fred Maryanski. páginas 77–89. Inc. Ivan L. [32] Object Design. 1989. Um sistema de tratamento de restrições de projeto no contexto GERPAC/UniCOSMOS. UK. Manaus.0. [30] Farid Nourani e Léo Pini Magalhães. [41] Lawrence A. Rio de Janeiro. ACM Computing Surveys. Intelligent Databases: Object-Oriented. Ricarte. [36] Kamran Parsaye. Burlington. páginas 83–96. Setrag Khoshafian. [34] Object Management Group. Stonebraker. object-oriented design database system. Olguín e Léo Pini Magalhães. Ruschel. Junho 1988. ObjectStore C++ API User Guide. N. RJ. [33] Object Design. Magalhães. John Wiley and Sons. 1987. and hyper-semantic approaches do data modeling. Potter e Robert P. capítulo 1. Brighton.Ivan L. . M. M. ObjectStore Technical Overview. Inc. The POSTGRES data model. páginas 3–21. [35] Carlos José M. Ricarte. SP. [31] Kristen Nygaard. Julho 1992. semantic. Delgado. Outobro 1986. Basic concepts in object oriented programming. Rowe e Michael R. A survey of object-oriented concepts. North-Holland.org/. RS. editores. AM. Junho 1995. M. Abril 1990. [39] Ivan L. [38] Walter D. Setembro 1988. 21(10):128–132.. Deductive. Release 2. Delgado. Campinas. [29] Oscar Nierstrasz. Trueblood. GERPAC — um SGBD para PAC. Em F. 20(3):153– 189. Hypermedia Technologies. Um gerenciador de transações no contexto do GERPAC/UniCOSMOS. Burlington. Semantic data models. Traditional.
Addison-Wesley.wustl. e Gerald Held. Agosto 1998. [43] Mamede Augusto Machado da Silveira. The C++ Programming Language. [47] Bjarne Stroustrup. Ricarte. Abril 1991. 1(3):189–222. Peter Kreps. Eugene Wong. Fevereiro 1995. Retrospection on a database system. Proceedings of the IFIP International Conference on Open Distributed Processing. Tese de mestrado. Extensão do Núcleo UniCOSMOS para Suporte à Orientação por Objeto. Overview of CORBA. The design and implementation of INGRES. [44] John Miles Smith e Diane C. Database abstractions: Aggregation and generalization. SIGMOD Record (ACM Special Interest Group on Management of Data). The Montage extensible DataBlade architecture. Em Open Distributed Processing: Experiences with Distributed Environments. páginas 439–450. 23(2):482–482. [48] Bjarne Stroustrup.html.cs. ACM Transactions on Database Systems. 1991. [50] M. UNICAMP. P. [49] Carlos M. a distributed object database system for multimedia support. Junho 1977. Junho 1980. segunda edição. http://www. Setembro 1976. M. 5(2):225–240. 2(2):105–133. Junho 1994. [46] Michael Stonebraker. M. Tobar e Ivan L. Ubell. páginas 10–20.edu/~schmidt/ corba-overview. Ricarte Bancos de Dados Orientados a Objetos [42] Doug Schmidt. . Faculdade de Engenharia Elétrica. ICODP'95. Multiware database. ACM Transactions on Database Systems. Maio 1988.Ivan L. What is object-oriented programming? IEEE Software. [45] Michael Stonebraker. Smith. ACM Transactions on Database Systems.