IMPLEMENTAO DE UM BANCO DE DADOS ORIENTADO A OBJETOS A PARTIR DE UM MODELO DIMENSIONAL

Moiss Henrique Ramos Pereira1 Antnio da Mota Moura Junior 2 Orientador 1 moiseshrp@gmail.com; 2amoura@acad.unibh.br Curso de Cincia da Computao Uni-BH (www.unibh.br)
Resumo Este trabalho aplica parte da metodologia proposta por Borba (2006) para a implementao de modelos dimensionais e implantao de Data Warehouses (DW) em um ambiente de desenvolvimento orientado a objetos. A metodologia em que esse trabalho se baseia apresenta tcnicas para definir o modelo de negcio da organizao, gerar o modelo dimensional, representar este modelo em um diagrama UML e, por fim, efetivar o seu mapeamento em um banco orientado a objetos pelo padro ODMG. Conforme as adaptaes realizadas para o estudo de caso, este trabalho desenvolve o mapeamento de um modelo de negcio real em diagrama de classes UML, implementando o banco diretamente em um framework de persistncia de objetos integrado a uma linguagem OO comercialmente difundida. Palavras-chave Data warehouse. Modelo dimensional UML Modelagem. Banco de dados orientado a objetos. Metodologia. Abstract This work apply the methodology proposed by Borba (2006) for implementation of dimensional models and deployment of Data Warehouses (DW) in an oriented to objects development environment. The methodology on which this work is based presents techniques to define the business model of the organization, creating the dimensional model, representing it in UML diagram, and finally accomplish its mapping in a database oriented to objects by ODMG standard. As the adjustments made to the case study, this paper develops the mapping of an existing real business model in UML class diagram, implementing the database directly in a persistence framework for objects integrated into a language oriented to objects commercially distributed.

implementao de ambientes de Data Warehouse (DW) sob os conceitos do paradigma da Orientao a Objetos (OO), adaptando-a em um estudo de caso para um modelo dimensional conhecido. Na era da sociedade do conhecimento, o sucesso das organizaes est diretamente ligado ao acesso privilegiado informao em tempo e em quantidade satisfatrios dentro da dinmica de negcio (BORBA, 2006). Com a crescente necessidade de analisar o desempenho organizacional, favorecendo o processo de tomada de deciso, percebem-se no mercado diversas solues de Data Warehouses (DW) que disponibilizam, de forma mais interessante para a empresa, as informaes contidas em grandes volumes de dados distribudos em diferentes sistemas.

Da mesma forma que as organizaes precisam de agilidade para obter informaes estratgicas existentes nos sistemas, necessrio que o processo de implementao do DW seja bem definido, rpido e barato, o que pode ser determinante dentro da conjuntura comercial. Esse o problema apontado por Klein, Campos & Tanaka (1999), pois existe carncia por uma metodologia bem definida para a implantao de um DW. Assim, alguns aspectos devem ser discutidos Keywords Data warehouse. Dimensional model. UML. como o suporte manipulao de dados e Modeling. Database oriented to objects. Methodology. custos de implementao, pois em um DW necessrio modelar todos os agrupamentos de 1 INTRODUO informaes da organizao, gerando grande quantidade de dados muito complexos para o Neste trabalho so descritas e aplicadas armazenamento fsico. algumas etapas da metodologia proposta no Partindo do pressuposto que a ano de 2006 por Sueli de Ftima Poppi Borba, orientao a objetos poderia promover na Universidade Federal de Santa Catarina, em tese de doutorado referente modelagem e agilidade no desenvolvimento de bancos de dados como ocorre atualmente no mercado de

desenvolvimento de software, seria possvel implementar solues de DW seguindo uma metodologia de desenvolvimento que embarcasse este paradigma, aproveitando-se das tecnologias oferecidas pelas aplicaes de modelagem OO para melhoria da documentao do DW como, por exemplo, a abstrao oferecida pela UML (Unified Modeling Language) frente ao cliente. O conceito de DW foi proposto em meados dos anos 80 pelos idealizadores Willian Inmon (INMON, 1992) e Ralph Kimball (KIMBALL, 1998) que descrevem os processos de anlise de negcio para suprir as necessidades empresariais atravs de sistemas de apoio tomada de deciso, permitindo que informaes estratgicas sejam obtidas dos prprios dados existentes nas empresas. J a teoria OO criada na dcada de 60 por Kristen Nygaard e Ole-Johan Dahl tem como objetivo oferecer uma nova viso de modelagem e programao, pois era notvel que as pessoas pensavam em entidades e responsabilidades de negcio como um todo encapsulado, inferindo a partir da o conceito de objeto. Dessa forma, durante toda a histria do pensamento cientfico para a resoluo de problemas, diversos modelos foram definidos para documentar sistemas e metodologias de desenvolvimento, considerando as incertezas do pensamento humano e as abstraes de uma realidade para consenso de todos os envolvidos. Sobre as necessidades de diferencial competitivo promovido pelas solues de DW e as facilidades geradas pelo paradigma OO no desenvolvimento de aplicaes, percebe-se a relevncia em estudar formas de agregar os dois conceitos a fim de extrair os resultados mais eficazes frente s necessidades de melhor custo-benefcio nas anlises de negcio. O interesse deste trabalho aplicar a metodologia de Borba (2006) para implementar um determinado modelo dimensional com o uso de tecnologias altamente difundidas no mercado que utilizam o paradigma OO, bem como apresentar a possibilidade do uso comercial de bancos de

dados OO em solues de DW. Este trabalho est dividido em cinco sees, incluindo a introduo. A segunda seo aborda uma reviso da literatura, refletindo alguns dos problemas e solues existentes quanto modelagem e implementao de banco de dados, mais especificamente de bancos DW, e um breve histrico do paradigma OO. A terceira seo apresenta, de maneira mais abrangente e conceitual, alguns modelos de dados conhecidos, incluindo os conceitos de DW e modelagem dimensional. Alm disso, algumas tcnicas so descritas para exemplificar as metodologias propostas para o desenvolvimento de DW. J a seo 4 dedicada descrio mais detalhada da metodologia de Borba (2006) aplicada neste trabalho, aprofundando as etapas sobre o mapeamento do modelo dimensional utilizado para UML e sua implementao fsica por uma linguagem de programao OO. Este captulo apresenta as ferramentas utilizadas no trabalho e os conceitos definidos no prprio modelo dimensional usado no estudo de caso. Na seo final existem algumas reflexes acerca do uso da modelagem OO em ambientes DW, sugerindo algumas linhas de pesquisa para trabalhos futuros. 2 REVISO DE LITERATURA Nas dcadas de 80 e 90, o banco de dados era definido como uma nica fonte de dados para todo o processamento das aplicaes existentes no meio cientfico. Com a evoluo tecnolgica, o computador tornou-se extremamente aplicvel no mercado comercial, suprindo as instituies empresariais com dados que favoreciam o ambiente de negcio, transformando os recursos computacionais de simples instrumentos de clculo para verdadeiras ferramentas de anlise de negcio com alto poder competitivo (VIDOTTI, 2001). Neste momento, a comunidade cientfica e as organizaes passam a perceber a necessidade por alguma metodologia bem definida para a modelagem de bancos de dados e padronizar o

processo de desenvolvimento. Para Borba (2006), desde os anos 90 que a necessidade de obteno de dados relevantes, principalmente em tempo satisfatrio imposto pela dinmica do mercado, vem se apresentando cada vez mais determinante para o sucesso das organizaes. Com a crescente necessidade de gerenciar o desempenho organizacional, favorecendo o processo de tomada de deciso, percebem-se no mercado diversas solues de Data Warehouses (DW) que disponibilizam, de forma mais interessante para a empresa, as informaes contidas em grandes volumes de dados (BORBA, 2006). Em 1992, Inmon definia um DW como uma coleo de dados orientada por assunto, integrada, varivel no tempo e no-voltil, usada no apoio aos processos de tomada de deciso gerenciais. Para ele, o DW uma tecnologia voltada para o estudo de tcnicas e ferramentas utilizadas em aplicaes que envolvam anlise intensiva de dados e integrao de fontes de dados heterogneas, de forma a prover agilidade e flexibilidade na gerncia, manuteno e acesso a estes dados (INMON, 2005). Como qualquer soluo tecnolgica adotada, inicialmente no se dava uma importncia emergencial definio de um processo bem fundamentado para o desenvolvimento de DW. Conforme Klein, Campos & Tanaka (1999), no existe uma metodologia slida para implantao de ambientes DW, tendo somente guias que direcionam os arquitetos para obteno do melhor resultado alcanvel, indicando ento um dos seus principais problemas de implantao. Para facilitar a implementao deste tipo de abordagem, Kimball (1998), como poucos autores que aprofundam em um modelo lgico, prope nove passos simples para nortear a implementao de um DW, tendo como foco o modelo estrela. Ele descreve que a construo efetiva de um DW se inicia pela modelagem dimensional, uma tcnica de projeto lgico de banco de dados que busca apresentar os dados em um formato

que seja intuitivo e com alto desempenho para o usurio final. Esse enfoque para a OO, paradigma de programao criada nos anos 60, baseia-se no fato de que os objetos oferecem maior abstrao para a modelagem de dados muito complexos, pois eles representam melhor as entidades do mundo real, incorporando seus atributos e operaes (BOSCARIOLI et al, 2006). Como ocorre na modelagem dimensional, necessrio encontrar todos os objetos que compem o DW, pois os objetos podem ser estendidos para atender s novas demandas de mercado. Outra vantagem do modelo orientado a objetos percebe-se na possibilidade de utilizar o mesmo modelo no projeto conceitual, onde os objetos so construdos; no projeto lgico, estendendo-se esses objetos conforme a tecnologia; e no fsico, quando detalhes da ferramenta utilizada na implementao so incorporados ao modelo (BEZERRA, 2003). Como os objetos representam entidades do mundo real mais fielmente, os valores de seus atributos podem ser muito complexos, podendo representar outros objetos. J nos bancos de dados relacionais ocorrem incompatibilidades referentes a esse tipo de complexidade, pois existe uma grande separao entre os dados e suas operaes (BOSCARIOLI et al, 2006). Dessa forma, apesar do sucesso dos sistemas de gerenciamento de dados relacionais, Klein, Campos & Tanaka (1999) afirmam que a manipulao de informaes complexas proporcionada pelas diversas aplicaes, inclusive a tecnologia de DW, exigiram novas solues de gerenciamento de dados como os sistemas de gerenciamento de banco de dados orientados a objetos (SGBDOO) e objeto-relacionais (SGBDOR). Dentro da modelagem de um DW, o esquema estrela se projeta como a principal forma de representao da dimensionalidade de negcio e, ao introduzir as abstraes OO, esses sistemas de gerenciamento permitem que as tabelas sejam melhor representadas. Neste

contexto surge a proposta de modelagem OO O modelo conceitual representa as por Borba (2006) para bancos DW que aplica entidades e seus relacionamentos conforme integralmente os conceitos da OO sem nenhum observadas e expostas no mundo real durante a tipo de tecnologia intermediria. fase de anlise entre os envolvidos da desconsiderando detalhes Nos ltimos anos ocorreram alguns organizao, usos de BDOO, como relata Rosemberg impostos pela tecnologia, metodologias ou (2008). Um deles o db4o. A Indra Sistemas, dispositivos fsicos. No modelo lgico, grupo espanhol lder em desenvolvimento de construdo a partir do modelo conceitual, as mapeadas so representadas softwares contratada recentemente para entidades desenvolver um centro de controle do sistema conforme um padro mais tcnico e formal, de trens bala da Espanha, utilizou o db4o como considerando limitaes tecnolgicas e base de dados de tempo real para controlar o decises de projeto conforme a viso do trfego, gerando capacidade de processamento usurio do SGBD, mas ainda se abstm do em torno de 200 mil objetos por segundo com ambiente fsico onde os dados sero pouco uso de memria (ROSEMBERG, 2008). armazenados no computador. J no modelo De acordo com Jos Miguel Rubio Snchez, fsico, detalha-se os tipos de campos, o acesso gerente tcnico da Indra, o maior benefcio memria e demais itens para o SGBD, pois observado se mostrou na facilidade em os dados so representados conforme o trabalhar diretamente com objetos em ambiente fsico. consultas sem transformar os dados. 3 MODELOS DE DADOS E A ORIENTAO A OBJETOS Nas ltimas dcadas, a computao vem evoluindo no que se refere s metodologias e tecnologias de modelagem e armazenamento de dados. Uma das tecnologias que contriburam para essa evoluo so os diversos tipos de bancos de dados que armazenam grande quantidade de dados em um curto espao de tempo. Esta realidade passou a dificultar aos envolvidos identificar e analisar informaes relevantes ali presentes para o negcio da organizao. Dessa forma, o modelo de dados deve fornecer uma viso precisa e objetiva de como os dados sero armazenados para favorecer o entendimento de conceitos, especificaes e regras durante o projeto de banco de dados (BORBA, 2006). Um modelo de dados uma coleo de conceitos que podem ser usados para descrever um conjunto de dados e as operaes para manipul-los. Para Elmasri & Navathe (2002), os modelos de dados podem ser classificados em modelo conceitual, lgico e fsico, conforme a etapa de desenvolvimento do projeto do banco em que o modelo utilizado. 3.1 DATA WAREHOUSE E O MODELO DIMENSIONAL Nesta seo, sero apresentadas algumas definies referentes Data Warehouse (DW) e alguns elementos importantes do modelo dimensional para uma discusso das vantagens de um mapeamento orientado a objetos. Encontra-se na literatura a caracterizao de DW como (...) uma coleo de dados orientada a assuntos, integrada, novoltil e varivel no tempo em suporte s decises gerenciais (INMON, 2005: 29). Borba (2006) complementa que um DW uma importante ferramenta para anlise e acesso mais global aos dados advindos de diversas bases de dados autnomas e heterogneas, pois o DW possui uma cpia dos dados extrados de um ou mais sistemas de produo na fase de carregamento (KIMBALL, 1998). O conceito de Data Mart parecido com as definies acerca de um DW, mas focado sobre um determinado assunto, ou seja, Data Mart um DW departamental que possui um assunto definido. Na abordagem de Kimball (2002), Data Marts so criados e, posteriormente, o DW construdo a partir da correlao entre eles, mas para Inmon (2005), o DW construdo para depois os assuntos serem

identificados como Data Marts. Como no DW garantida pela implementao de uma foco de anlise deste trabalho, o detalhamento dimenso de tempo que, no momento em que os dados so inseridos no DW, receber em dessas implementaes no ser abordado. seu atributo-chave o valor da data desta Como visto no captulo 2, os bancos de atualizao, permitindo assim a redundncia dados operacionais so baseados nas dos dados que esto diferenciados pela data de aplicaes da empresa, tendo desempenho alterao no ambiente operacional. analisado conforme o sistema ao qual est Voltando-se para a implementao de associado. J um DW baseado em assunto, ou seja, os dados so organizados conforme os ambientes DW depois de apresentar suas caractersticas fundamentais, so descritas, a principais assuntos do negcio da empresa. seguir, duas metodologias que possuem muitos Um DW tambm no-voltil, ou seja, elementos em comum, mas seguem os dados no so deletados e nem atualizados paradigmas diferentes em diversas fases: o livremente como nas bases operacionais. Essa modelo de Kimball e o modelo proposto por propriedade permite melhor performance do Borba (2006). DW, pois o ambiente executar as transaes Frente realidade do mercado no analticas sem perder tempo de processamento no controle de concorrncia como nos bancos gerenciamento de informaes estratgicas, de dados operacionais acessados por diversos Kimball et al (1998) promoveu, desde meados usurios que podem executar diferentes tarefas dos anos 80, um modelo contendo as principais sobre os mesmos dados (KIMBALL, 1998). diretrizes de desenvolvimento do DW, Em determinados perodos, os dados dos distribudas em 9 fases. Esse modelo afirma aplicativos em produo so inseridos e, a que os projetos do DW devem incidir sobre as partir da, sero apenas consultados durante as necessidades do negcio e que os dados devem demandas de negcio. Conforme Kimball ser unidimensionais quando apresentados aos (1998), o primeiro estgio do DW onde estes clientes. Cada projeto no DW dever ter um dados so carregados para serem tratados em ciclo finito com incio e fim bem definidos. A processos ETL (extract-transformation-load) sua primeira fase consiste do Planejamento de conhecido como data staging area e esse Projeto, seguida pelas fases de Definio dos controle de carga feito fora do expediente das Requisitos de Negcio, Design Tcnico de Arquitetura, Seleo e Instalao de Produtos, consultas analticas. Modelagem Dimensional, Design Fsico, A integridade dos dados outra Design e Desenvolvimento da Data Staging importante caracterstica de um ambiente DW, Area, Especificao e Implementao da pois os dados advindos das diversas fontes Aplicao Analtica, Implantao, Manuteno operacionais podem possuir diferentes e Crescimento (KIMBALL, 2002). Este formatos e valores, em conformidade s suas modelo foca o desenvolvimento do DW para respectivas aplicaes. Para Inmon (2005), a um ambiente de bancos de dados relacionais. integrao o processo mais importante na A Fig. 1 apresenta o diagrama de ciclo manuteno de um DW e como os dados so alimentados a partir de mltiplas fontes, eles de vida do modelo de Kimball & Ross (2002), devem ser manipulados a fim de terem uma indicando a distribuio das fases seqenciais, dependncias e fases concorrentes em um nica imagem corporativa. projeto de desenvolvimento de DW. Kimball O DW variante no tempo, ou seja, os & Ross (2002) alertam que o diagrama no dados nesse ambiente representam uma faixa reflete uma cronologia absoluta entre as fases e extensa de tempo, podendo armazenar, por nem o verdadeiro tempo de durao de cada exemplo, as realidades e instncias de um uma delas. um modelo que pode ser determinado dado concebido h vrios anos. considerado como um simples roteiro que Conforme Vidotti (2001), essa caracterstica do facilita a equipe de desenvolvimento no projeto

e que serve tanto para os projetos-assunto de Barbieri (2001) complementa que a Data Mart como para todo o ambiente DW. modelagem dimensional representa a informao como intersees das vrias dimenses do negcio para que o usurio veja os dados conforme o entendimento que ele tem dessa realidade. O modelo dimensional possui uma estrutura mais assimtrica, diferentemente do modelo ER, mapeando uma tabela central chamada de tabela fato com diversos joins com outras tabelas secundrias, as dimenses (KIMBALL, 1998). No estudo da modelagem dimensional, mostra-se necessrio entender os conceitos de tabelas fatos e dimenses. Figura 1 Diagrama de ciclo de vida As tabelas fatos, tambm conhecidas dimensional de negcio Modelo de Kimball. como cubos de deciso ou tabelas de fatos, so Fonte: KIMBALL & ROSS, 2002. representantes das transaes ou ocorrncias O modelo proposto por Borba (2006) existentes no negcio. De forma mais promove a implementao do DW em BDOO, especfica, Kimball (1998) afirma que as trabalhando com os conceitos do paradigma tabelas de fatos armazenam as medies OO em vrias de suas fases. Estes conceitos, numricas de desempenho extradas dos fatos quando representados pela UML, oferecem relevantes do negcio e as combinaes entre uma modelagem adequada das caractersticas as dimenses ali presentes. Para Borba (2006), de um DW, desde a fase de levantamento de em muitos casos, os fatos no so conhecidos requisitos at a implementao. Conforme e, geralmente, representam valores numricos, Borba & Morales (2006), as 5 etapas que tambm chamados de mtricas, quantificados compe este modelo so, nesta ordem: a em medidas conforme uma realidade que Definio do Modelo do Negcio; Gerao do determinada pelos nveis de dimenso. Modelo Dimensional; Gerao do Modelo As dimenses representam os diversos Dimensional Representado pela UML; Mapeamento do Modelo UML para BDOO. tipos de vises que os usurios podero ter do Este modelo ser devidamente discutido na negcio. Este tipo de tabela armazena as prxima seo, pois trata-se de uma parte descries das dimenses de negcio, de preferncia que sejam modeladas em campos fundamental para a realizao deste trabalho. textuais, e so utilizadas como elementos Uma das tcnicas de modelagem mais condicionais que restringem ou formam os utilizadas atualmente para a implementao de cabealhos das consultas analticas do usurio um DW a modelagem dimensional, um tipo (KIMBALL, 1998). de modelo lgico que reflete os requisitos de No modelo dimensional, o mapeamento negcio em uma estrutura de cubo de dados. Conforme Kimball & Ross (2002), para dos relacionamentos feito sob uma lgica construir o modelo dimensional necessrio diferente da aplicada ao modelo ER. As identificar o processo de negcio a ser dimenses fazem relacionamentos de 1:n com modelado, descrever o nvel de granularidade e a tabela de fatos, cujo lado 1 est na dimenso mapear as dimenses e fatos do negcio. A e o lado n na tabela fato, representando que partir disso, modelada uma tabela central, a uma instncia de uma determinada dimenso tabela fato, conectada a outras tabelas que pode estar em uma ou mais instncias dos fatos armazenaro as dimenses. Geralmente, ocorridos no negcio. Em muitos modelos somente a tabela fato normalizada, no dimensionais o lado n de relacionamentos necessariamente todas as tabelas como no descrito por um asterisco, notao muito encontrada tambm em modelos orientados a modelo ER.

objetos. Conforme Borba (2006), enquanto os relacionamentos entre as entidades so mapeados de forma explcita no modelo ER, no modelo dimensional os relacionamentos representam, implicitamente, as intersees entre a tabela de fatos e suas dimenses, dentro do ideal imposto pelo cubo de dados. A Fig. 2 abaixo apresenta um esboo de um modelo dimensional com alguns dos elementos at agora descritos.

4 MODELO DIMENSIONAL EM AMBIENTE DE PERSISTNCIA DE OBJETOS Este captulo descreve a metodologia proposta por Borba (2006), aprofundando nas etapas utilizadas para o modelo de desenvolvimento deste trabalho. Alm disso, apresenta o modelo referente ao Crdito Sem Barreiras (CSB) da Vivo, pois o foco a modelagem para um ambiente de persistncia de objetos e no as reas da anlise de requisitos e gesto de negcio, pr-requisitos da modelagem dimensional. E, por fim, esta seo termina descrevendo o mapeamento do modelo dimensional CSB em diagrama de classes UML e a sua implementao em um ambiente OO.

Partindo da anlise entre as diversas metodologias divulgadas ao longo dos anos para implementar o modelo dimensional na construo de um DW, Borba (2006) visa Figura 2 Esboo de um modelo dimensional. atender a todos os requisitos analisados em seu modelo. Neste trabalho, a implementao foi Fonte: Adaptado de KIMBALL, 1998: 10. realizada, utilizando a linguagem orientada a Os campos das tabelas desenhadas para objetos Java, associada ao framework de o modelo dimensional so extremamente persistncia de objetos db4o. importantes, pois, dependendo de como so A primeira etapa proposta por Borba classificados no modelo, eles refletiro alguma (2006) consiste na definio do modelo de caracterstica e informao importantes para os processos analticos de tomada de deciso, seja negcio com anlise de requisitos junto ao para armazenar um fato do negcio ou uma cliente, a fim de contemplar as decises das descrio textual de uma dimenso. De acordo reas a serem atendidas pela soluo de DW com Kimball (1998), essa classificao modelada. Conforme Borba & Morales (2006), denominada granularidade da tabela. Toda neste momento, os detalhes do negcio que tabela de fatos possui como atributo-chave a sero base no desenvolvimento do projeto so combinao das chaves primrias das tabelas analisados e traduzidos para o ambiente operacional adotado atravs de um modelo ER, dimensionais as quais est ligada. documentando a finalidade do projeto e os Existem diversos modelos recursos tcnicos que sero utilizados. dimensionais, mas os mais utilizados Logo a seguir, realizada a gerao do academicamente e comercialmente so o modelo multidimensional, ou seja, o modelo de modelo Estrela e o modelo Floco de Neve, conhecidos na literatura, respectivamente, por negcio identificado. Nesta etapa so Star Schema e Snowflake Schema (BORBA, identificados os sistemas e bases de dados 2006). A metodologia discutida na seo 4 operacionais, inclusive suas funcionalidades aborda detalhes do mapeamento para cada um dentro deste ambiente, para mapear o modelo destes modelos, enfatizando mais o modelo dimensional. Borba (2006) enfatiza que o Estrela, pois trata-se do formato do modelo modelo ER desenhado na etapa anterior deve ser minuciosamente analisado para que possam dimensional utilizado. ser extradas as dimenses que fazem parte do

negcio, podendo indicar dimenses implcitas a serem modeladas. A granularidade das entidades tambm merece ateno, pois a partir desse estudo sero mapeados os atributos das dimenses e os fatos do negcio a fim de definir tabelas de fatos e mtricas de derivao. necessrio, durante a anlise, definir uma dimenso Tempo, pois o DW promove a equivalncia de tempo sob a viso do negcio, agregando dados por um determinado tipo de perodo, conforme a necessidade da disposio dos dados (BORBA, 2006).

http://jude.change-vision.com. A codificao das classes mapeadas nesta fase foi realizada em linguagem de programao Java, utilizando-se o ambiente de desenvolvimento Eclipse, verso 3.2, integrado ao framework de persistncia de objetos db4o na verso 7.4, disponveis para download, respectivamente, em seus endereos http://www.eclipse.org e http://www.db4o.com. necessrio instalar plug-ins do bd4o no Eclipse para a integrao. Estes podem ser baixados no site oficial citado do db4o. Para implementar o teste de execuo As prximas etapas da metodologia realizado e descrito na ltima seo, foi abordam a representao do modelo utilizado o Oracle Express 10g para simular um ambiente operacional. dimensional em diagrama de classes UML, o Conforme Paterson et al (2006), o db4o mapeamento deste diagrama para um BDOO, e, finalmente, a sua implementao. A Fig. 3 um tipo de BDOO de cdigo aberto que demonstra a ordem de execuo destas etapas e permite aos desenvolvedores de linguagens de um esboo de toda a metodologia de Borba programao OO reduzir consideravelmente os custos envolvidos no desenvolvimento. (2006). Segundo o site oficial (DB4OBJECTS, 2008), o db4o executa consultas at 44 vezes mais rpido que algumas solues conhecidas no mercado como o hibernate que apenas oferece um mapeamento de aplicaes OO para bancos de dados relacionais e no persistncia direta de objetos. A Fig. 4 abaixo ilustra um comparativo entre as tcnicas em bancos de dados relacionais e o uso do db4o para a implementao dos objetos modelados. Observa-se que existem persistncia e mapeamento diretos dos objetos no BDOO, facilitando a consulta a esses objetos, diferente de um SGBD relacional associado s tcnicas de mapeamento objeto-relacional que implementam fisicamente os objetos modelados em diversas tabelas, projetando maior complexidade na manipulao dos mesmos.

Figura 3. Resumo da metodologia de Borba. Fonte: BORBA & MORALES (2006) Estas ltimas etapas so descritas nas prximas sees, utilizando um modelo dimensional real j definido. Segue, antes disso, uma breve descrio das ferramentas utilizadas para a implementao do modelo em BDOO para, alm de fundamentar, exemplificar a aplicao da metodologia de Borba (2006) sobre modelos de dados reais. 4.1 AS FERRAMENTAS UTILIZADAS Para representar o modelo dimensional em diagrama de classes UML foi utilizado o software Jude Community 3.2.1, disponibilizado para download no site oficial

Figura 4. Forma de armazenamento de objetos de um SGBD relacional e no db4o. Fonte: DB4OBJECTS, 2008.

4.2 MODELO DIMENSIONAL UTILIZADO O modelo utilizado para a aplicao da metodologia de Borba (2006) trata-se do modelo dimensional do servio Crditos Sem Barreiras (CSB), disponibilizado pela operadora Vivo em Minas Gerais, e encontrase implementado no Data Mart de Vendas. Este Data Mart fornece informaes referentes ao gerenciamento de vendas da Vivo - MG e armazena os dados das ativaes de contratos de celulares de planos pr e ps-pagos, das vendas de produtos como aparelhos e chips, das ativaes de cartes e o acompanhamento entre estas vendas e metas. O servio de Crdito sem Barreiras uma forma de venda de recarga programada da Vivo - MG. O sistema origem permite que o cliente com um celular de plano ps-pago agende a compra de crditos pr-pagos para outro celular designado por ele. Os usurios do DW acompanham a movimentao da carteira, adeses e cancelamentos referentes ao servio. Existem anlises por clientes ps-pagos distintos que aderiram ao CSB e tambm por agendamentos. Informaes mais pontuais como os nmeros de celulares ps e pr-pagos, valores de crdito, canal de compra e funcionrio que efetuou a venda so extradas diretamente das dimenses do DW, onde os dados so tratados e manipulados conforme as demandas de negcio. O modelo dimensional referente ao CSB est representado na Fig. 5.

dois modelos representados pelas tabelas de fatos ADESAO_CSB e CANCELAMENTO_CSB que armazenam informaes sobre as adeses dos clientes ao servio e os cancelamentos realizados, respectivamente. As outras tabelas TEMPO_ANO_MES, TIPO_CONTATO, OPERADORA e AGRUPAMENTO referemse, assim, dimenso de tempo no negcio, por qual tipo de contato o cliente solicitou sua adeso ou cancelamento do servio CSB, a qual operadora o cliente pertence e os agrupamentos de clientes por alguma caracterstica, servio ou planos em comum mapeados na base de dados. Os atributos-chave das tabelas de fatos so compostos por referncias ou Foreign Keys das chaves primrias das tabelas dimensionais. Quando necessrio, como neste modelo, outros atributos relevantes de um fato de negcio podem tambm fazer parte do grupo de atributos-chave das tabelas fato a fim de melhorar a qualidade de resposta nas consultas analticas. Conforme Machado & Abreu (2004), os relacionamentos entre as tabelas esto representados logicamente por estas Foreign Keys e, como todo modelo que possui configurao baseada no ER, para cada valor atmico presente nestes campos das tabelas fatos existe correspondente de mesmo valor no atributo-chave da dimenso, permitindo assim buscar as devidas associaes no conjunto de resposta solicitado pelo usurio. De forma mais geral, este modelo dimensional agrupa as semnticas e fatos de negcio referentes s informaes de adeses e cancelamentos do CSB (Crdito Sem Barreiras) solicitados por um cliente de uma determinada operadora atravs de um tipo de contato em um perodo de tempo. 4.3 MAPEAMENTO DO MODELO DIMENSIONAL EM UML Com o modelo dimensional definido por meio de um esquema estrutural como, por exemplo, o Star Schema ou Snowflake Schema, basta classificar as entidades e suas hierarquias conforme as regras do negcio a fim de mape-

Figura 5. Modelo dimensional CSB. Fonte: Adaptado de Core Synesis, 2008. Conforme a Fig. 5 acima, o modelo dimensional CSB utilizado possui duas tabelas de fatos conectadas a outras quatro tabelas de dimenso. Este modelo dimensional agrupa

las sob a perspectiva OO da UML, permitindo que os dados representados sejam agregados posteriormente (BORBA, 2006). Dessa forma, como visto nas definies acerca de classes, as tabelas dimensionais so modeladas como classes dimensionais no respectivo diagrama da UML e as tabelas de fatos so representadas por classes de fatos. Alm de mapear as classes e seus atributos para representar as tabelas do modelo, faz-se necessrio tambm traar os relacionamentos e as multiplicidades entre as classes fato e suas dimenses.

multiplicidade 1..*, pois as dimenses esto em diversas instncias de fatos (BORBA, 2006).

Para aplicar esta etapa da metodologia, os mapeamentos acima sero descritos logo a seguir. Tendo como base o modelo dimensional CSB e os padres considerados, foram modeladas as classes das dimenses TempoAnoMes, TipoContato, Operadora e Agrupamento que correspondem s tabelas dimensionais de mesmo nome. As classes fato AdesaoCSB e CancelamentoCSB foram No mapeamento das tabelas do modelo modeladas a partir das tabelas de fato dimensional em classes, alm de seguir as ADESAO_CSB e CANCELAMENTO_CSB notaes de modelagem da UML, OMG e do modelo dimensional CSB. ODMG, deve-se aplicar os padres definidos Na construo do diagrama, para no DW pela organizao. Para auxiliar as implementar o ltimo tipo de notao acima, equipes envolvidas na administrao e ou seja, a identificao das classes de fatos e desenvolvimento do DW, interessante que dimensionais, as abreviaes CS e CD foram aja padronizao para identificar, concatenadas aos nomes das classes para explicitamente, as tabelas de fatos e as identificar, respectivamente, as classes de fatos dimenses em consultas OLAP (On-line sumarizadas e as dimenses na manipulao Analytical Processing) e rotinas ETL. dos dados pelo desenvolvedor. As classes de Conforme Borba (2006), uma das formas mais apropriadas para representar os relacionamentos entre as classes de fatos e as classes das dimenses por meio de agregaes compartilhadas, pois, pela semntica dos conceitos de DW em modelos dimensionais, a tabela fato agrega as dimenses. A agregao representa que um fato de negcio constitudo de diversas partes, as dimenses, ou seja, as dimenses do negcio fazem parte de um fato de negcio. Somente para exemplificar, pois em ambientes DW no existe formalmente excluso e alterao de dados, a excluso de um fato no implica que as dimenses que o constituam devam ser excludas, demonstrando que as informaes referentes s dimenses so independentes dos fatos ocorridos. Aps incluir as agregaes, as multiplicidades devem ser mapeadas para detalhar mais o diagrama. Nos relacionamentos entre as dimenses e a fato, a extremidade referente s dimenses possui multiplicidade 0..1, pois estas armazenam os dados em mais baixo nvel; e a extremidade junto fato possui fatos do diagrama dimensional, agora CSAdesaoCSB e CSCancelamentoCSB, foram generalizadas para uma classe CSCSB, pois elas apresentam atributos em comum, alm de possurem dados referentes ao mesmo tipo de servio, no caso o Crdito Sem Barreiras. Conforme Cattell et al (2000), todo objeto em uma base de dados possui um identificador nico OID que deve ser modelado nos diagramas de dados. Borba (2006) confirma que os identificadores devem ser representados de forma explcita, mas somente para classes de dimenso, colocandose a restrio {OID} no atributo definido para cada classe. J os descritores so os atributos representativos de cada classe dimensional e devem ser textuais, preferencialmente, por serem campos de referncia para o usurio, modelados com a restrio {D} no diagrama de classes UML (BORBA, 2006). Um padro sugerido neste trabalho para nomear os OIDs concatenar o termo OID ao nome da classe sem carregar a sigla CD. Conforme as anlises e padres descritos, o diagrama de classes CSB apresentado na Fig. 6.

4.4 IMPLEMENTAO DO DIAGRAMA UML NO BDOO Nesta seo est descrito o processo de implementao da etapa da metodologia de Borba (2006) que visa codificar o script para um determinado BDOO a partir do diagrama de classes obtido anteriormente. Para este trabalho, houve adaptaes para a gerao do cdigo referente persistncia de objetos que, na verdade, utiliza uma linguagem de programao OO para desenvolver diretamente as classes UML modeladas. Borba & Morales (2006) comentam que o padro ODMG oferece a linguagem OQL, mas ela no oferece interoperabilidade e trata-se de um padro de codificao que ser depois implementado, independente de linguagem de programao. J neste trabalho a abordagem utilizada delega aos desenvolvedores de linguagens de programao OO, neste caso a linguagem Java (SUN MICROSYSTEMS, 2009), a codificao direta das classes e relacionamentos pelo padro UML. Conforme Cattell et al (2000), o modelo de objetos prope pelo padro ODMG que o estado de um objeto seja representado por seus atributos e relacionamentos. Este tipo de representao muito importante, pois as consultas em BDOO so feitas de acordo com os estados fornecidos. Na formalizao do modelo de dados como tambm abordado no diagrama de classes UML, foi definido que uma classe tambm possui operaes que devem ser representadas e, posteriormente, implementadas em mtodos presentes no escopo desta classe (RUMBAUGH, JACOBSON & BOOCH, 2004). Como citado anteriormente, alm das operaes definidas explicitamente no diagrama, os mtodos implcitos tambm devem ser codificados, com exceo das operaes sets que no devem ser implementadas, pois no usual que algum dado existente nas dimenses e nas classes de fatos seja deletado ou alterado. Na Fig. 7 abaixo a classe dimensional CDAgrupamento est definida em Java, conforme os mesmos

Figura 6 Diagrama de classes CSB. Percebe-se na Fig. 6 que as classes fato CSAdesaoCSB e CSCancelamentoCSB esto conectadas diretamente s classes de dimenses CDTipoContato, CDOperadora, CDTempoAnoMes e CDAgrupamento, assim representando os mesmos dois modelos dimensionais referentes s adeses e cancelamentos do servio CSB. Os descritores escolhidos no diagrama so, justamente, os atributos mais significativos e que possuem o tipo String por serem atributos textuais. Analisando Rumbaugh, Jacobson & Booch (2004), classe pode possuir mtodos que retornam e alteram diretamente os dados de seus atributos. Estes mtodos so representados pelas operaes gets e sets, mas, por padro, no necessrio mape-los explicitamente no diagrama. Foram representadas somente as operaes addFato nas dimenses e toString para as classes fato que correspondem, respectivamente, aos mtodos para adicionar os fatos que cada dimenso participa e a descrio dos valores internos dos fatos ocorridos, mtodos dos quais sero implementados na prxima etapa da metodologia. A classe CSCSB criada para generalizar as classes fato foi modelada como classe abstrata, pois mesmo contendo atributos e operaes prprios, no ser instanciada para armazenar dados. Para implementar o polimorfismo no diagrama, a operao toString definida nas classes de fatos foi mapeada tambm para esta classe CSCSB, pois mesmo que esse diagrama seja muito usado no nvel conceitual, pode-se adicionar detalhes de implementao (BEZERRA, 2003).

atributos definidos no diagrama de classes desenvolvedores, ou seja, o OID deve ser CSB e as operaes implementadas pelos representado nos diagramas, mas no precisa mtodos addFato e gets destes atributos. ser codificado explicitamente: o prprio sistema de gerenciamento de objetos do public class CDAgrupamento { ambiente OO utilizado para persistir os objetos gera, automaticamente, um OID associado ao private int codAgrupamento; private int codTipoAgrupamento; objeto no momento em que este instanciado. J nas classes de fatos os atributos que correspondem s mtricas foram public int getCodAgrupamento(){ implementados como variveis estticas, return codAgrupamento; usando-se a palavra reservada static. Toda vez } que um objeto de fato for criado, indicando public int getCodTipoAgrupamento(){ que um novo tipo de adeso ou cancelamento return codTipoAgrupamento; } foi realizado, a mtrica incrementada public String getDscAgrupamento(){ automaticamente no mtodo construtor, return dscAgrupamento; conforme o tipo de servio. Como so atributos } estticos, os valores destas mtricas so public void addFato(CSCSB credito){ visveis por todos os objetos instanciados this.listaFatos.add(credito); } destas classes (SUN MICROSYSTEM, 2009). } Este tipo de implementao facilita as consultas OLAP posteriores que no Figura 7 Cdigo parcial da classe de sobrecarregariam o banco com clculos de dimenso CDAgrupamento em Java. campos derivados para obter as sumarizaes, Refletindo agora sobre alguns detalhes pois basta consultar o campo pelo mtodo get de implementao, toda classe deve possuir um correspondente para obter esse somatrio mtodo construtor para inicializar todos os armazenado no BDOO. seus atributos quando a mesma instanciada. Este mtodo construtor recebe os valores 4.5 IMPLEMENTAO E EXECUO DA atmicos referentes a todos os seus atributos CONSULTAS para as inicializaes, exceto para a lista de fatos que deve ser apenas criada no construtor, Depois da codificao das classes sugere-se pois ter elementos adicionados nela somente realizar a carga do novo banco de dados OO quando ocorrer um fato do qual a dimenso criado ou parte dele com os dados existentes no ambiente operacional. neste momento que participe. os recursos do BDOO escolhido so Conforme Bezerra (2003), para que o plenamente utilizados, pois a definio das conceito estrutural de objeto seja classes pode ser feita por qualquer linguagem implementado, os atributos das classes devem de programao em ambientes de possuir visibilidade privada e os mtodos, desenvolvimento diversos, inclusive por scripts inclusive os utilizados para acessarem esses para modelar as classes, mas no processo de atributos, devem possuir visibilidade pblica, carga e realizao de consultas que o BDOO modeladas no Java pelas palavras reservadas tem seu desempenho e funcionalidades private e public. avaliadas. Observa-se no cdigo Java De acordo com Paterson (2006), o bd4o desenvolvido que os identificadores e trabalha com trs formatos de consultas: o descritores no esto assim explcitos, sendo QBE, as Native Queries e o SODA. O QBE que estes primeiros nem sequer encontram-se (Query-By-Example) o mecanismo mais implementados. Segundo Cattell et al (2000), bsico oferecido pelo db4o e fornece os OIDs so transparentes para os usurios e os consulta um novo objeto com o mesmo estado
private String dscAgrupamento; private ArrayList listaFatos;

do objeto desejado, ou seja, um objeto externo criado como exemplo para a consulta retornar o objeto armazenado que possui os mesmos valores de alguns ou todos os atributos fornecidos. As Native Queries so muito utilizadas para consultas mais complexas e so escritas com as expresses da linguagem de programao OO utilizada, ultimamente C# ou Java. Neste tipo de formato, informa-se ao banco um trecho de cdigo da linguagem utilizada com a lgica requerida pela consulta atravs de um objeto Query, prprio de uma biblioteca db4o. J o formato SODA (Simple Object Data Access) uma API que oferece diversos tipos de objetos e mtodos para realizar as consultas sob uma perspectiva mais OO. Dessa forma, a partir de instancias de objetos prprios suportados pelo bd4o, mtodos SODA so combinados para realizar consultas que podem retornar uma lista de objetos, o ObjectSet (PATERSON, 2006). Sobre esta lista aplicam-se polimorfismo, encapsulamento e diversos mecanismos da OO para processar as informaes obtidas. Para realizar as cargas e consultas das classes criadas nesta trabalho, foi utilizado o formato SODA para manipular os dados. O novo BDOO implementado a partir do diagrama CSB um objeto do tipo ObjectContainer que gera um arquivo de extenso YAP atravs do mtodo openFile do bd4o. Para inserir os dados no banco, basta invocar o mtodo store deste objeto, passando como parmetro os objetos a serem armazenados e, depois de utilizado, o mtodo close chamado para encerrar a sesso com o ObjectContainer. O cdigo implementado para os testes de carga e consulta possui os dois mtodos processoStagingProd, que insere os dados nas dimenses; e processoDMVendasAdesao, que representa os dados do modelo dimensional ADESAO_CSB. Conforme o site da Sun (SUN MICROSYSTEMS, 2009), para aplicaes relacionais, estas cargas so facilmente

implementadas via JDBC, conjunto de mtodos muito utilizados comercialmente oferecidos pela tecnologia Java para acessar bancos de dados transacionais e mapear seus dados em objetos para, depois, grav-los no ObjectContainer criado do bd4o. Os objetos referentes s dimenses so buscados do banco, alterados e novamente gravados. Como j discutido, papel do BDOO utilizado associar um novo OID para cada novo objeto armazenado, mas o db4o gerencia esse tipo de situao automaticamente, verificando se o objeto a ser armazenado pelo mtodo store resultante de algum processamento sobre algum objeto consultado do mesmo tipo. Caso seja, ele somente atualiza o objeto consultado, seno um novo objeto armazenado no ObjectSet instanciado (PATERSON, 2006). Por fim, para ilustrar a codificao do teste, realizou-se uma busca por todas as ocorrncias de objetos do tipo CSAdesaoCSB armazenados no BDOO, apresentando como resultado de execuo os atributos descritores das dimenses participantes e as mtricas da prpria classe de fatos. Incluindo a realizao desta busca como todo o processamento anterior discutido, o db4o demonstrou bom desempenho de execuo, semelhante aos custos de implementao e testes das aplicaes OO pelo fato de basear suas consultas no prprio framework oferecido pela linguagem OO hospedeira. Conforme as informaes oficiais do db4o (DB4OBJECTS, 2008), o uso deste banco de objetos permite facilmente o armazenamento de estruturas altamente complexas de dados, atingindo timo desempenho de performance em relao aos bancos de dados objeto-relacionais existentes no mercado: o db4o pode ser executado at 44 vezes mais rpido que o MySQL com Hibernate, pois economiza cerca de 90% do custo de desenvolvimento da camada de persistncia e agiliza a comercializao em um perodo de tempo at 10% menor em relao a algumas tecnologias existentes.

5 CONCLUSO A utilizao das tcnicas formuladas pela metodologia proposta por Borba em 2006 proporcionou bons resultados que refletiram alto desempenho e baixo custo de desenvolvimento frente s tecnologias utilizadas atualmente para bancos de dados, incluindo maior uso da abstrao junto ao cliente e melhoria da semntica de negcio promovida pela unio dos ideais da UML e dos conceitos de DW. Existem hoje no mercado diversas solues que convergem seus esforos sobre a tecnologia objeto-relacional a qual no suporta integralmente os conceitos da OO. Dependendo do negcio modelado, estes conceitos devem ser aplicados para apresentar aos envolvidos uma estrutura de armazenamento e processamento mais prxima da semntica desejada. Mesmo que seja comum, em um primeiro momento, que a tecnologia objeto-relacional seja utilizada para carregar os dados do ambiente operacional, geralmente relacional, as prximas manipulaes dos dados no DW seriam somente sobre o BDOO modelado. Quando utilizado um modelo OO visando a sua implementao em ambientes de bancos de dados, os conceitos oferecidos pelo paradigma OO so preservados e aplicados de forma direta entre o banco e as aplicaes, incluindo as cargas de dados ocorridas dentro do DW e as consultas OLAP realizadas pelos usurios nos sistemas gerenciais.

Estas mesmas organizaes, com o rpido crescimento do seu volume de dados, vm implantando solues de DW em busca de diferencial competitivo. Dessa forma, pela dinmica do mercado, interessante que as empresas possuam uma metodologia bem definida e gil para a implantao de solues inteligentes no gerenciamento de dados do ambiente de DW. A metodologia discutida neste trabalho, bem como as adaptaes realizadas, projeta um nico processo de definio e implementao, utilizando uma nica abordagem a baixos custos de desenvolvimento. A modelagem para BDOO apresenta-se como uma opo vivel para a modelagem dimensional, permitindo o tratamento de objetos complexos, o aumento da reusabilidade de cdigo e desempenho compatvel com os modelos relacionais. AGRADECIMENTOS Agradeo a todos que me incentivaram nesta caminhada rumo ao conhecimento. Agradeo minha me, alma inspiradora, e a toda minha famlia; aos meus amigos Adriano, Ana Paula, Breno e Francielly, que me acompanham em amizade slida; minha namorada Luanda, quem sempre me ajudou e me confortou; e ao meu orientador pelos conselhos. Muito obrigado a todos. REFERNCIAS

BARBIERI, Carlos. BI - Business Intelligence Modelagem & Tecnologia. Rio Sob uma viso analtica, perceptvel de Janeiro (RJ): Axcel Books, 2006. 424 p. que a metodologia discutida abrange todas as BEZERRA, Eduardo. Princpios de Anlise e etapas usuais para um processo de Projeto de Sistemas com UML. Rio de desenvolvimento de DW descritas por Janeiro (RJ): Elsevier: Campus, 2007. 2 ed. Kimball, mas seu principal destaque a 369 p. fundamentao no paradigma OO. Como a programao OO est cada vez mais presente BORBA, Sueli de Ftima Poppi. Metodologia no desenvolvimento de softwares, alcanando para implantao de modelos dimensionais em at as linguagens do ambiente web, e como banco de dados orientado a objetos. nenhuma organizao sobrevive sem a Florianpolis (SC), 2006. 228p. Doutorado em implantao e gerncia de um banco de dados, Engenharia de Produo - Universidade notvel a compatibilidade da abordagem OO Federal de Santa Catarina - UFSC. Disponvel em: http://www.tede.ufsc.br/teses/PE para a modelagem de bancos de objetos. PS5029.pdf - Acesso em janeiro de 2009.

BORBA, Sueli de Ftima Poppi; MORALES, Aran Bey Tcholakian. Aplicao de Banco de Dados Orientado a Objetos na Modelagem Multidimensional. Florianpolis (SC), 2006. XXI Simpsio Brasileiro de Banco de Dados SBBD. Disponvel em: http://www.lbd.dcc.ufmg.br:8080/colecoes/sbb d/2006/010.pdf - Acesso em janeiro de 2009. BOSCARIOLI, Clodis; BEZERRA, Anderson; BENEDICTO, Marcos de; DELMIRO, Gilliard. Uma reflexo sobre Banco de Dados Orientados a Objetos. Ponta Grossa (PR), 2006. IV Congresso de Tecnologias para Gesto de Dados e Metadados do Cone Sul CONGED. Disponvel em: http://conged. deinfo.uepg.br/artigo4.pdf - Acesso em janeiro de 2009. CATTELL, Rick. G. G.; BARRY, Douglas K.; BERLER, Mark; EASTMAN, Jeff; JORDAN, David; RUSSELL, Craig; SCHADOW, Olaf; STANIENDA, Torsten; VELEZ, Fernando. The Object Data Standard: ODMG 3.0. San Francisco (USA), 2000. Grupo de Gesto de Objetos - Objects Management Group - OMG. Disponvel em: http://www.omg.org/docs/omg/ 04-07-02.pdf - Acesso em janeiro de 2009.

Wiley Computer Publishing, 2002. 2 ed.421 p. KIMBALL, Ralph; ROSS, Margy; REEVES, Laura; THORNTHWAITE, Warren. Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing and Deploying Data Warehouses. New York (USA): John Wiley & Sons, 1998. 2 ed. 405 p. KLEIN, Lawrence Zordam; CAMPOS, Maria Luiza Machado; TANAKA, Astrio Kiyoshi. A Tecnologia Objeto-Relacional em Ambientes de Data Warehouse: Uso de Sries Temporais como Tipo de Dado No Convencional. Florianpolis (SC), 1999. XIV Simpsio Brasileiro de Banco de Dados SBBD. Disponvel em: http://www.inf.ufsc.br/ sbbd99/anais/SBBD-Completo/30.PDF Acesso em janeiro de 2009. MACHADO, Felipe Nery Rodrigues; ABREU, Maurcio Pereira de. Projeto de Banco de Dados - Uma viso prtica. So Paulo (SP): rica, 2004. 11 ed. 299 p. PATERSON, Jim. EDILCH, Stefan. HRNING, Henrik. HRNING, Reidar - The Definitive Guide to bd4o - Nova Iorque (EUA): Apress, 2006. 484 p.

CORE SYNESIS. Disponvel em: http://www. ROSEMBERG, Dave. INDRA: Sistema de coresynesis.com.br Acesso em Misso Crtica para controle de trens de alta velocidade. Traduo de Cssio R. Eskelsen. dezembro/2008. Disponvel em: https://www.db4o.com/ DB4OBJECTS. db4o - Banco de objetos de portugues/db4o%20Success%20Story%20cdigo aberto. Disponvel em: https://www. %20INDRA%20Sistemas(Portuguese).pdfdb4o.com/portugues/db4o%20Product%20Info Acesso em dezembro de 2008. rmation%20V5.0(Portuguese).pdf - Acesso em RUMBAUGH, James; JACOBSON, Ivar; dezembro de 2008. BOOCH, Grady. The Unified Modeling ELMASRI, Ramez; NAVATHE, Sham. Language Reference Manual. Boston (EUA): Sistemas de banco de dados: fundamentos e Addison-Wesley, 2004. 2 ed. 721 p. aplicaes. Rio de Janeiro (RJ): LTC, 2006. SUN MICROSYSTEMS. Disponvel em: 3 ed. 837 p. http://www.sun.com/ Acesso em INMON, William H. Building the Data janeiro/2009. Warehouse. Indianapolis (USA): Wiley VIDOTTI, Julio Cesar. Projeto de um Data Computer Publishing, 2005. 4 ed. 543 p. Warehouse: Anlise de Custo/Benefcio. KIMBALL, Ralph. Data Warehouse Toolkit. Cuiab (MT), 2001. 36 p. Universidade Traduo de Mnica Rosemberg. So Paulo Federal do Mato Grosso - UFMT. Disponvel (SP): Makron Books, 1998. 388 p. em: http://www.ufmt.br/cacomp/Downloads/ KIMBALL, Ralph; ROSS, Margy. The Data monografias/ProjetoDataWareHouse.pdf Warehouse Toolkit. Indianapolis (USA): Acesso em janeiro de 2009.