Acta Scientiarum 22(5):1389-1397, 2000. ISSN 1415-6814.

Criando data warehouse com o modelo dimensional

Donizete Carlos Bruzarosco*, Andr Vinicius Castoldi e Roberto Carlos dos Santos Pacheco
1

Programa de Ps-Graduao em Engenharia de Produo, Universidade Federal de Santa Catarina, 88037-001, Florianpolis-Santa Catarina, Brazil. *Author for correspondence. e-mail: dcbruzar@eps.ufsc.br RESUMO. O conhecimento armazenado ao longo dos anos nas bases de dados

organizacionais um bem vital para a sobrevivncia de uma empresa neste mercado competitivo. Para a sua efetiva utilizao como apoio ao processo decisrio de uma organizao, os dados precisam estar organizados de uma forma que possibilite o seu acesso rpido e fcil entendimento. Este trabalho apresenta a modelagem dimensional como alternativa para a construo de um data warehouse, mostrando os seus elementos, algumas tcnicas de modelagem, assim como os passos para o seu desenvolvimento, atendendo assim aos requisitos citados. Tambm apresenta os resultados e consideraes, de um estudo de caso, com a aplicao do modelo dimensional para a criao de um data mart, para um portal jurdico da internet
Palavras-chave: armazm de dados, modelagem dimensional, suporte a deciso. ABSTRACT. Developing data warehouse using dimensional model. Stored knowledge

in organizational databases during the years is vital for the survival of a company in a competitive business world. For its effective use as support in a decision-making process of a organization, data must be organized for fast access and easy comprehension. A dimensional modeling is provide as an alternative for the construction of a data warehouse, with its elements, modeling techniques, and steps for its development to meet the mentioned requirements. Results and considerations about a case study are given, together with the application of a dimensional model for the creation of a data mart, for a juridical internet portal.
Key words: data warehouse, dimensional modeling, support in decision-making.

A globalizao tornou a competio acirrada e o conhecimento fundamental para que as organizaes possam vencer nesse mercado competitivo. Para se obter esse conhecimento, que vital para apoiar as empresas nas tomadas de decises estratgicas e gerenciais, necessrio estruturar os dados de forma que facilite a sua compreenso e extrao de forma eficiente. Os dados de uma organizao podem ser armazenados de duas formas: por meio do registro dos sistemas de informaes operacionais e data warehouse (Kimball, 1998). A modelagem dimensional atende a dois requisitos fundamentais para o sucesso de um data warehouse: simplicidade na organizao dos dados, permitindo seu fcil entendimento por usurios finais; e um bom desempenho na gerao de consultas e relatrios de apoio aos executivos nos processos decisrios, pela reduo significativa de operaes de junes de dados.

O enfoque deste trabalho a aplicao do modelo dimensional no desenvolvimento de um data warehouse, atendendo fase de modelagem, a qual uma das fases que compe o ciclo de vida de projeto de um data warehouse1 e, portanto, as demais fases no so mencionadas. Este trabalho apresenta inicialmente o que um data warehouse, como planej-lo e por que o modelo dimensional o mais adequado do que o modelo relacional, no seu desenvolvimento. As sees seguintes definem os elementos, algumas tcnicas e os passos envolvidos na construo de uma modelagem dimensional de um data warehouse. Na seqncia so mostrados os resultados de um estudo de caso da criao de um data mart para um portal
1

Fases do ciclo de vida do projeto de um data warehouse (Kimball, 1998): planejamento do projeto, definio dos requisitos do negcio, projeto da arquitetura tcnica, seleo e instalao de produtos, modelagem dimensional, projeto fsico, desenvolvimento do projeto e data staging, especificao da aplicao do usurio final, implantao e manuteno.

1390

Bruzarosco et al.

jurdico, utilizando o modelo dimensional. Por fim, so apresentadas as concluses deste trabalho. Data warehouse A fora do data warehouse dentro das empresas est na organizao e na entrega de dados que apiem o processo de tomada de deciso. O data warehouse a implementao fsica de um modelo de apoio a decises, que disponibiliza empresa as informaes necessrias tomada de decises estratgicas (Inmon, 1995). Um data warehouse um repositrio de dados com as seguintes caractersticas (Inmon, 1995): - baseado em assuntos: refere-se ao fato de que o data warehouse est organizado de maneira que descreve o desempenho dos negcios; os bancos de dados operacionais so orientados para o processo dos negcios; - integrados: refere-se ao fato de os dados serem organizados para fornecer uma fonte nica; - variveis em relao ao tempo: reconhecem que o desempenho de negcio medido em pontos cronolgicos (final do ms, por exemplo) e comparado em relao ao tempo; - no-volteis: sugere que os dados, uma vez inseridos no data warehouse, no devem mudar; o contedo dos bancos de dados operacionais muda cada vez que uma transao processada. Um data warehouse suporta anlise de negcios e tomada de decises atravs da integrao de dados procedentes de diversos sistemas - muitas vezes incompatveis entre si - em uma base de dados consolidada. Esta transformao de dados em informaes significativas capacita os executivos de uma organizao a efetuar anlises muito mais reais, precisas e consistentes (Meyer, 1998). Em outras palavras, o data warehouse uma base de dados projetada especificamente para atender s necessidades de tomada de deciso, em vez de atender aos sistemas de processamento de transaes (Daphne, 1999). Pode tambm ser usado como suporte a sistemas de data mining2 (Freitas, 1998). Os projetos lgico e fsico so considerados a base do data warehouse. A abordagem de modelagem dimensional, utilizada para o desenvolvimento do projeto lgico, a melhor maneira de modelar dados de suporte deciso e oferece os melhores
2

resultados em termos de facilidade de uso e alto desempenho (Kimball, 1998). Planejamento da construo de um data warehouse Uma das maiores preocupaes em data warehouse como planejar a sua construo. Ele pode ser construdo inteiro, abrangendo toda a organizao de uma s vez (abordagem monoltica), ou ento por reas (Kimball, 1998). A maioria dos tcnicos em data warehouse utilizam alguma espcie de abordagem por etapas para construir um data warehouse de uma empresa inteira. Em cada etapa construdo um data mart, que um data warehouse direcionado a apenas uma rea ou assunto especfico da organizao. Os planejadores de data warehouse utilizam a estratgia de constru-lo em pedaos pequenos (data mart) por vez, at chegar sua totalidade. O grande problema apresentado por essa construo incremental o risco de esses data marts apresentarem incompatibilidades de integrao para formar o todo (data warehouse). A soluo para essa abordagem evolutiva iniciar o planejamento do data warehouse com uma fase de especificao de uma arquitetura de dados geral com metas especficas e finitas, a qual guiar a implementao dos data marts em separado, permitindo uma aderncia entre eles (Kimball, 1998). O projeto lgico de um data warehouse pode ser realizado tanto atravs da modelagem entidaderelacionamento quanto pela modelagem dimensional (Kimball, 1998). As vantagens e desvantagens de cada abordagem so descritas a seguir. Modelagem entidade-relacionamento. A modelagem entidade-relacionamento uma tcnica de projeto lgico de banco de dados largamente utilizada, que procura eliminar redundncia e inconsistncia dos dados, alm de facilitar a sua manuteno. Como resultado, gera muitas tabelas, e isso tem um preo, pois os sistemas de software tornam-se complexos e ineficientes na manipulao e recuperao dos dados, porque requerem uma cuidadosa ateno no processamento de algoritmos para ligar esses conjuntos de tabelas (Kimball, 1998). Mesmo em aplicaes simples o Modelo ER desenvolve muitas tabelas, que so ligadas por uma intricada rede de relacionamentos. Dependendo do porte da empresa, a modelagem de seus dados resulta em centenas ou milhares de entidades, causando uma srie de problemas, tais como: usurios finais que no entendem ou no se lembram do diagrama de entidade-relacionamento (DER); a interface grfica de um diagrama geral no

Data mining um processo no trivial de procura por padres vlidos, novos, potencialmente teis e inteligveis a partir de uma coleo de dados (Freitas, 1998).

Criando data warehouse com o modelo dimensional

1391

amigvel para os usurios finais; software de consulta geral sobre o modelo paga um alto preo de desempenho; e a sua aplicao para data warehouse contraria a finalidade deste, de ser intuitivo e oferecer um alto desempenho na recuperao de dados (Kimball, 1998). Modelagem dimensional. Modelagem dimensional a tcnica de projeto lgico de banco de dados mais usada no desenvolvimento de data warehouses, embora tambm possa ser aplicada ao projeto de sistemas de informaes operacionais. Na verdade, ela busca apresentar os dados em um formato que seja intuitivo e ao mesmo atenda a acessos com um alto desempenho (Kimball, 1998). Um modelo dimensional composto por uma tabela com uma chave composta, denominada tabela de fatos, e um conjunto de tabelas menores conhecidas como tabelas de dimenso, que possuem chaves simples (formadas por uma nica coluna). Na verdade, a chave da tabela de fatos uma combinao das chaves das tabelas de dimenso. Isto faz com que a representao grfica do modelo dimensional assemelhe-se a uma estrela. Por este motivo, o modelo tambm conhecido como modelo estrela (Kimball, 1998). A idia fundamental da modelagem dimensional baseia-se no fato de que quase todo tipo de dado do negcio pode ser representado como uma espcie de cubo de dados, onde as clulas do cubo contm os valores medidos e os lados do cubo definem as dimenses naturais dos dados (Harrison, 1998). A Figura 1 contm um exemplo de um cubo com 3 dimenses: produto (conjunto de produtos comercializados pela empresa), mercado (rea de atuao) e tempo (perodo de tempo de atuao). Modelos dimensionais reais do mundo dos negcios geralmente possuem entre 4 e 15 dimenses.

Elementos de um modelo dimensional A seguir so definidos os elementos que compem o modelo dimensional (Kimball, 1998). Dimenses. Uma dimenso uma coleo de atributos textuais que so altamente correlacionados entre si. Os atributos textuais que descrevem coisas so organizados dentro das dimenses. Em uma base de dados de varejo so comuns dimenses como produto, armazm, cliente, promoo e tempo. A Figura 2 apresenta exemplos de dimenses: mercado, produto e tempo, de um histrico de negcios. Uma dimenso dita conformada quando pode ser compartilhada por duas ou mais tabelas de fatos. Um exemplo de dimenses conformadas seria um caso que contivesse duas tabelas de fatos: uma de vendas realizadas e outra de vendas previstas, e que compartilhasse as mesmas dimenses: produto, mercado e de tempo. Tabela de fatos. A tabela de fatos sintetiza o relacionamento existente entre as diversas dimenses. Isto ocorre porque a chave da tabela de fatos a associao das chaves primrias das tabelas de dimenses. Geralmente este tipo de tabela possui um ou mais fatos numricos que ocorrem na combinao de chaves que define cada registro. A tabela Histrico de Negcios, ilustrada na Figura 2, um exemplo de tabelas de fatos. Atributos. Geralmente so campos de textos, os quais descrevem uma caracterstica de uma coisa tangvel. Os atributos mais comuns so as descries de produtos. O sabor um exemplo de atributo do produto. No se mede o atributo sabor de um produto. Se for necessrio criar um produto com um novo sabor, cria-se um novo registro de produto. Atributos de dimenses oferecem o contedo da maioria das respostas solicitadas pelos usurios. Pode-se dizer que a qualidade do data warehouse medida pela qualidade dos atributos das dimenses. Uma tabela de dimenso contm muitos campostextos descrevendo os membros de uma dimenso particular. A meta do data warehouse criar atributos de tabelas de dimenso com as seguintes caractersticas: eloqente, descritivo, completo, qualidade garantida, indexado, disponvel e documentado. Exemplos de atributos so apresentados pela Figura 2, tais como: descrio de produto, produtor, marca, cor, tamanho e nvel, da tabela de dimenso de produtos.

Figura 1. Exemplo de um cubo dimensional

1392

Bruzarosco et al.

Fatos. Um modelo dimensional faz distino entre fatos e atributos. Um atributo usualmente alguma coisa que conhecida com antecedncia. Um fato uma observao do mercado. Muitos fatos no mundo dos negcios so numricos, embora alguns possam conter texto. Algumas vezes, um valor numrico como preo padro parece ser um atributo da dimenso produto, pois uma constante conhecida antecipadamente. Mas, em um exame mais cuidadoso, verifica-se que o atributo preopadro sofre alterao durante o ano, o que leva a alter-lo na fase de projeto para um fato. Uma tpica e correta deciso a ser tomada considerar quase todos os campos numricos de pontos flutuantes como fatos. Exemplos de fatos tais como: reais, unidades e preo (custo), da tabela histrico de negcios, podem ser verificados na Figura 2. Fatos aditivos, semi-aditivos e no aditivos

A notao grfica dos relacionamentos entre as tabelas dos exemplos das Figuras 2, 3, 4, 5 e 6 e suas respectivas cardinalidades da linguagem e mtodo IDEF1X (Nist, 1993), (Kern, 1999), que utilizada para modelagem da informao baseada no modelo Entidade-Relacionamento (Chen, 1990). Tcnicas de modelagem dimensional Algumas tcnicas de modelagem dimensional so apresentadas a seguir (Kimball, 1998). Snowflaking. Uma dimenso dita estar snowflaked quando os campos de baixa cardinalidade de uma dimenso compuseram uma outra tabela, a qual foi ligada com a tabela original com chaves artificiais. O snowflake (ilustrado na Figura 3 pelas tabelas dimenso cliente e subdimenso regio) feito para salvar espao em disco, mas no recomendado para ambientes de data warehouse por tornar a sua apresentao mais complexa (por aumentar o nmero de tabelas) e para consultas com processamento mais pesado (por aumentar a necessidade de juno de tabelas para se obter a informao), acarretando maior tempo de resposta.

Estado Estado So Paulo So Paulo So Paulo So Paulo Rio de Janeiro Rio de Janeiro Rio de Janeiro

Marca Total Reais TotalCusto Lucro Bruto Marca Total Reais Total Custo Lucro Bruto Marca A A 1.223,00 1.058,00 Marca R$R$1.223,00 R$ R$1.058,00 R$ R$ 175,00 175,00 Marca R$R$2.239,00 R$ R$2.200,00 R$ 39,00 Marca B B 2.239,00 2.200,00 R$ 39,00 Marca A R$ 2.097,00 R$ 1.848,00 R$ 249,00 Marca A B R$2.246,00 R$ R$2.350,00 R$ R$ 249,00 2.097,00 1.848,00 Marca R$ 78,00

Figura 2. Exemplo de modelo dimensional e um relatrio gerado a partir dele

Figura 3. Exemplo de dimenso snowflaked

Os fatos da tabela de fatos deveriam ser aditivos, isto , ser a soma dos fatos ao longo de todas as dimenses (ex.: registrador de vendas). Medidas numricas de intensidade no so perfeitamente aditivas (semi-aditivo), como por exemplo, saldo de contas e nveis de inventrio, os quais so como uma fotografia de algum momento no tempo. Tambm possvel um fato medido ser textual (no aditivo), como por exemplo, a condio do tempo descrito pelo policial no cenrio de um acidente, considerando-se que o acidente a granularidade (o nvel atmico do dado) da tabela de fatos. A Figura 2 mostra uma modelagem dimensional que permite gerar consultas e/ou relatrios de vendas dos fatos: reais, unidades, preo (custo); por mercado (estado), produto (marca) e perodo (dimenses), como ilustrado no relatrio criado. Os atributos mercado, produto e perodo compem a chave primaria, e tambm so definidos como chaves estrangeiras (foreign keys - FK), da tabela de fatos Histrico de Negcios.

Agregao. Agregados so sumrios armazenados construdos primeiramente para melhorar o desempenho de consultas. Agregados, preferencialmente so armazenados em tabelas separadas, diferentes das tabelas de fatos originais contendo os dados no agregados. Certos fatos em um ambiente podem no ser expressveis no menor nvel de granularidade. Neste caso uma tabela de agregados requerida para apresentar esses novos fatos agregados. Alteraes em dimenses. Quando houver necessidade de se alterar uma informao, pode-se utilizar uma das trs estratgias abaixo: - sobrepor o registro de dimenso com os novos valores e perdendo o histrico; - criar um registro de dimenso adicional, usando um valor novo da chave artificial; - criar um campo velho no registro dimenso, para armazenar o valor prvio do atributo.

Criando data warehouse com o modelo dimensional

1393

Dimenses grandes e com grande volume de alteraes podem ocasionar muito consumo de espao de armazenamento. Uma soluo para esse problema dividir a dimenso, como no caso da dimenso cliente conforme Figura 4, que para salvar espao de armazenamento, foi dividida em duas dimenses: uma com atributos com baixo volume de alteraes (dimenso cliente) e outra com atributos com alto volume de alteraes (dimenso demografia). Essa soluo economiza espao em disco em detrimento do desempenho de consultas.

ocorrncia da tabela de dimenso diagnstico (o paciente pode ter mais de um diagnstico), caracterizando o relacionamento muitos-paramuitos, a soluo para o problema a criao da tabela bridge table grupo de diagnsticos.

Figura 5. Exemplo de dimenso muitos-para-muitos

Figura 4. Diviso da dimenso cliente para suportar alteraes

Chaves estrangeiras, primrias e artificiais. Todas as tabelas dimensionais possuem chaves primrias, as quais devem ser chaves artificiais. No se deve usar a chave original dos sistemas de produo para evitar que problemas ou alteraes nos mesmos afetem o data warehouse. A chave artificial pequena e sua nica finalidade recuperar o registro para ver seu contedo. Dimenses muitos-para-muitos. Nas situaes de projetos clssicos, a granularidade da tabela de fatos facilmente entendida e bvio que cada dimenso esteja ligada a um registro da tabela de fatos. Freqentemente uma dimenso pode ter zero, um ou muitos valores para um dado registro. A dimenso muitos-para-muitos ocorre quando um dado registro da tabela de fatos pode ter mais de uma ocorrncia em uma dimenso, sendo a soluo para essa situao a criao de uma bridge table3. No exemplo apresentado pela Figura 5, onde uma ocorrncia da tabela de fatos despesas do paciente pode estar relacionada a mais de uma
3

Hierarquia. Representar uma estrutura de organizao arbitrria uma tarefa difcil em um ambiente relacional. Por exemplo: pode-se desejar um relatrio de receitas de um conjunto de clientes comerciais relacionados entre si. Podem-se vender produtos ou servios para quaisquer desses clientes comerciais e, em diferentes momentos, ter uma posio, individualmente ou em famlias organizadas dentro de uma estrutura hierrquica. Essa estrutura hierrquica pode ser representada com ponteiros recursivos em cada registro da dimenso cliente, contendo a chave cliente do pai na organizao. Embora seja uma maneira compacta e efetiva de representar uma hierarquia arbitrria, este tipo de estrutura no pode ser usado efetivamente pela linguagem SQL. A soluo para esse problema seria a construo de uma bridge table entre a dimenso cliente e a tabela de fatos, conforme ilustrado na Figura 6. Drill down e drill up significam apresentar uma informao com mais detalhe (drill down) ou mais resumida (drill up), a partir de estruturas hierrquicas. Como exemplo de drill down pode-se citar uma consulta que permita mostrar em um primeiro momento os produtos vendidos por categoria, depois subcategoria, em seguida por marca e finalmente no detalhe de produto.

Uma bridge table uma tabela criada para intermediar (fazer uma ponte) em um relacionamento muito-para-muitos, entre uma tabela de fatos e uma tabela de dimenses, para resolver problemas de consultas de sistemas relacionais.

Figura 6. Usando uma bridge table para facilitar a navegao no modelo

1394

Bruzarosco et al.

Construo do modelo dimensional O data mart construdo reunindo-se um conjunto de tabelas de fatos, cada qual contendo uma chave composta pelas chaves primrias de suas dimenses (juno das chaves estrangeiras). As tabelas de fatos contm zero ou mais fatos que representam medidas tomadas de cada combinao dos seus componentes chaves. Cada tabela de fatos circundada por uma aurola de tabelas de dimenses e este projeto tambm chamado de esquema estrela (Kimball, 1998), (Teorey, 1999). A maior responsabilidade da equipe de projeto de data warehouse central estabelecer, divulgar, manter e forar o uso das dimenses conformadas. Sem uma rgida aderncia proporcionada pelas dimenses conformadas, o data warehouse no pode funcionar como uma unidade integrada. A maioria das dimenses conformadas deve ser definida no seu nvel mais granular (atmico) possvel (Kimball, 1998). Para decidir quais modelos dimensionais construir, pode-se comear com uma abordagem de planejamento top-down chamada matriz de arquitetura bus de um data warehouse. Essa matriz fora a identificar todos os data marts possveis e todas as dimenses envolvidas com esses data marts. Depois, pode-se ser mais especfico dentro do projeto criando-se as tabelas de fatos para os data marts, utilizando-se do mtodo de quatro passos (Kimball, 1998) descrito abaixo para a criao do projeto lgico: Escolher o data mart. Primeiramente deve-se decidir se o data mart inicial tratar uma fonte simples ou mltiplas fontes. Uma fonte simples representa um domnio de aplicao de menor complexidade em relao a um de mltiplas fontes. Como exemplos de fonte simples pode-se citar: solicitao de compra, vendas, pagamentos, etc; e como exemplo de mltiplas fontes, o lucro por cliente, onde fontes que descrevem receitas devem ser combinadas com fontes que descrevem custos, para se obter o resultado desejado. recomendado implementar separados data marts no contexto de um conjunto de dimenses conformadas, ligando os data marts em um data warehouse bus4. Comece-se com um data mart de fonte simples. Declarar a granularidade da tabela de fatos. fundamental definir claramente a granularidade do registro da tabela de fatos no projeto dimensional
4

proposto. Geralmente, a granularidade da tabela de fatos escolhida para ter o menor nvel de granularidade possvel, pois isto permitir responder melhor a novas consultas e a introduo de novos elementos de dados com nvel maior de granularidade. Exemplos de granularidades de tabela de fato: transao de venda, indenizao de seguro, transao de um caixa automtico de banco, total de vendas dirias por produto, posio mensal de conta, cada item de um pedido, etc. Uma granularidade seria definida mais alta somente por razes de desempenho. Escolher as dimenses. Aps a definio clara da granularidade da tabela de fatos, a escolha das dimenses bastante direta. A tabela de fatos em um modelo dimensional um conjunto simultneo de medidas de uma granularidade particular. Neste ponto, o projetista dimensional decora o conjunto de medidas com todas as dimenses que ele encontrar dirigidas aos requisitos do negcio. Por exemplo, o conjunto mnimo de dimenses para um item de um pedido seria data do pedido, cliente, produto e uma dimenso degenerada (no existindo fisicamente por no possuir atributos) contendo somente o nmero da ordem. Cada dimenso tem sua prpria granularidade, a qual no pode ser menor que a granularidade da tabela de fatos Escolher os fatos. A granularidade da tabela de fatos tambm permite a escolha dos fatos individuais, deixando claro qual o seu escopo. Um data mart um conjunto coordenado de tabelas de fatos com estruturas similares (Kimball, 1998). Muitos negcios possuem um fluxo lgico que tem um comeo e um fim. Um pedido, um produto ou um cliente envolvem uma srie de passos. Geralmente capturam-se transaes ou instantneos fotogrficos de cada passo, fazendo mais sentido gerar uma tabela de fatos para cada passo. Uma tabela de fatos e um conjunto de dimenses associadas so ento definidos para cada passo da cadeia. As dimenses conformadas so cuidadosamente projetadas, e estas dimenses so usadas como o barramento (a forma de integrao) para separadamente implementar cada passo na cadeia. Em um exemplo sobre seguro, talvez os dois passos mais interessantes da sua cadeia de valores sejam vendas do corretor e processamento de reclamaes. Esses dois modelos dimensionais poderiam ser implementados antes dos outros com a garantia de que um framework de dimenses conformadas sempre guiaria os esforos de

Data warehouse bus: data warehouse composto pelos data marts desenvolvidos conforme uma matriz de arquitetura bus.

Criando data warehouse com o modelo dimensional

1395

implementao subsequentes e garantiria que todas as tabelas de fatos trabalhariam juntas no futuro. Virtualmente, cada data mart necessita de duas verses dos dados modelados separadamente: a verso transao e uma verso de instantneo fotogrfico peridico. Transaes do a possibilidade da mais completa viso do comportamento detalhado e o instantneo fotogrfico permite-nos rapidamente medir o status da empresa. Quando usados juntos, fornecem uma completa e imediata viso do negcio e, quando so parte de um data warehouse, eles se misturam elegantemente, formando uma viso maior atravs do tempo e atravs de outras dimenses principais. Alguns conselhos teis de projeto (Kimball, 1998) so: - os nomes que so usados para identificar os data marts, dimenses, atributos e fatos deveriam originar-se do vocabulrio do negcio; - um atributo pode existir em somente uma dimenso, mas um fato pode ser repetido em mltiplas tabelas de fatos; - se uma dimenso, como uma entidade do negcio parece residir em mais de um lugar, provavelmente vrios papis esto sendo representados. Neste caso, deve-se identificar unicamente os papis e trat-los em dimenses separadas; - um campo simples de uma base de dados fonte pode ter uma ou mais colunas lgicas associadas com ele. Por exemplo: o campo produto pode ser traduzido para cdigo do produto, descrio curta do produto e descrio longa do produto. - cada fato deveria ter uma regra de agregao default (soma, mnimo, mximo, ltimo, semi-aditivo, algoritmo especial e no agregvel), a qual serviria para uso das consultas e relatrios e como requisito na avaliao de ferramentas geradoras de consultas e relatrios. Os diagramas do projeto devem conter informaes descritivas fornecendo um documento compreensivo do projeto, o qual tambm deveria conter uma breve introduo da modelagem dimensional com seus conceitos e terminologia. Como qualquer modelagem de dados, o desenvolvimento do modelo dimensional um processo iterativo e seu sucesso depende de um trabalho em equipe. A partir do esboo inicial do projeto, sesses de reviso com as pessoas envolvidas devem ser efetuadas, em que as informaes so apresentadas e discusses so encorajadas para

explorar o suporte do modelo ao negcio. No final do projeto, o patrocinador do usurio pode assinar o seu documento, afirmando assim que o seu escopo rene as necessidades do negcio. A modelagem dimensional deveria ser desenvolvida usando-se uma ferramenta que a suportasse (como por exemplo, o software Erwin (CA, 2000)). Isso traria uma srie de vantagens tais como: integrao com outros modelos de dados corporativos, garantia de consistncia dos nomes, criao de uma boa documentao, gerao automtica do projeto fsico para os SGBDRs mais populares, etc. Estudo de caso Para aplicao do modelo dimensional foi implementado um prottipo de um data mart que oferece subsdios e ferramentas gerenciais para a tomada de deciso na gesto de um portal jurdico. Esse portal fornece um completo, eficaz e moderno canal de negcios jurdicos via internet, onde profissionais, escritrios e organizaes privadas e pblicas ligadas ao ramo jurdico tm o seu espao na economia digital. Configura uma central jurdica na internet. O portal jurdico est tematicamente organizado e permite o estabelecimento de contatos e prestao de servios especializados. Tem por objetivo ampliar a visibilidade em mbito jurdico, reduo de custos, maior competitividade, economia de escopo, disponibilidade e agilidade na busca de conhecimento atualizado no local e hora desejados. As consultas de clientes so encaminhadas ao profissional associado mais habilitado a responder sobre o assunto questionado. O diagrama de entidade-relacionamento, mostrado na Figura 7, se refere aos dados requeridos para a carga do data mart. composto pelas tabelas: Consulta_tcnica (onde ficam registrados os dados da consulta feita pelo cliente), Cliente (dados cadastrais de clientes), rea-Tcnica (reas em que est dividida a central jurdica); Unidade_Federao (dados das unidades da federao) e Municpio (dados dos municpios). O data mart tem por objetivo auxiliar a administrao do portal nos seguintes questionamentos: Quais os Estados ou cidades do Brasil e em que reas tcnicas do direito esto sendo feitas as consultas tcnicas em um dado perodo de tempo? Como direcionar o marketing para que ele seja mais eficiente e menos custoso, de modo a expandir o negcio? Como racionalizar os recursos tcnicos?

1396

Bruzarosco et al.

O grfico apresentado na Figura 10 dinmico, ou seja, sempre que os dados do cubo forem modificados o grfico muda automaticamente. Para realizao da carga dos dados OLTP (On Line Transaction Processing) para o DW foi utilizada uma ferramenta do SQL Server 7.0 (Data Transformation Services).

Figura 7. Diagrama de entidade-relacionamento do sistema de origem

A modelagem dimensional do data mart, mostrada na Figura 8, para atender aos requisitos citados composta: pela tabela de fatos Fato_Consulta-Tcnica, que contm as consultas por cliente, rea tcnica e por data. As dimenses so as tabelas: Cliente, rea-Tcnica e de tempo time_by_day. A tabela Municipio uma subdimenso da tabela Cliente. Na etapa do projeto fsico foi gerado o Cubo no servidor Olap ( On Line Analytical Processing) do gerenciador de banco dados SQL Server 7.0, da Microsoft. A interface com o usurio (a visualizao dos dados a partir do cubo) pode ser feita de duas formas: 1. Por meio da utilizao do Olap Browser, do servidor Olap Nesta ferramenta, pode-se realizar drill down e drill up, cruzar os dados com as dimenses disponveis e tambm filtrar os dados a partir das dimenses, conforme mostrado na Figura 9. 2. Utilizao de uma ferramenta front end tal como, a planilha Excel da Microsoft A partir do Excel pode-se conectar uma planilha a um cubo existente. Veja-se o resultado mostrado na Figura 10.

Figura 9. Exemplo de interface com o usurio utilizando o Olap Browser

Figura 10. Exemplo de interface com o usurio utilizando a planilha Excel

Consideraes finais O data warehouse o meio e no o fim, pois o fim o negcio da empresa. A informao um produto valioso e confere vantagem competitiva. A modelagem dimensional possui um grande potencial para as aplicaes de data warehouse e, seus elementos, tcnicas e passos que orientam o seu desenvolvimento, aumentam a probabilidade de sucesso do projeto. A criao de um data warehouse utilizando-se a modelagem dimensional gera uma interface grfica simples para a base de dados, permitindo que os usurios a entendam e possam desenvolver aplicativos amigveis para navegar essas bases de modo

Figura 8. Modelagem dimensional do data mart

Criando data warehouse com o modelo dimensional

1397 1999. URL: http://www.daphnesoft.com/whitepaper. doc Freitas, A, A Data Mining- Minerao de Dados. Cefet Pr - Nucce, 1998. Harrison, T.H. Intranet data warehouse, Berkeley, 1998. Inmon, W.H. What is a data warehouse?, 1995 URL: http://www.cait.wustl.edu/papers/prism/vol1_no1/ Kern, M.V. Modelagem da Informao com IDEF1X: Linguagem, Mtodo, Princpio do Consenso. Rev. Alcance, 3:99-107, 1999. Kimbal, R. et al. The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses. John Wiley & Sons, New York, 1998. Meyer, D. Building a better data warehouse, Prentice Hall, 1998. Nist (National Institute of Standards and Technology). Federal Information Processing Standards Publication 184. Integration Definition for Information Modeling (IDEF1X). Gaithersburg, MD (USA), December 1993. Teorey, J.T. Database Modeling & Design. Morgan Kaufmann Publishers, San Francisco, 1999.
Received on October 07, 2000. Accepted on November 22, 2000.

eficiente, apoiando significativamente as tomadas de decises de uma organizao. A existncia do modelo E/R dos sistemas fontes do data warehouse permite um melhor entendimento dos seus dados, facilitando a modelagem dimensional. A construo do modelo multidimensional deve ser feita sob uma perspectiva do usurio, e no dos dados. A modelagem dimensional desenvolvida no estudo de caso do portal jurdico, para a construo do DW, revelou-se eficiente para a obteno de respostas s perguntas inicialmente formuladas. Portanto, o modelo dimensional oferece um potencial significativo e efetivo, para a criao de data warehouse com sucesso. Referncias bibliogrficas
CA (Computer Associates International, inc.). Computer Associates Erwin, 2000. URL: http://ca.com/products/ alm/erwin.htm Chen, P. Gerenciando Banco de Dados: A Abordagem Entidade-Relacionamento para Projeto Lgico. McGraw-Hill, 1990. Daphne Corp. Building Corporate Business Intelligence: From Data marts to the Enterprise Data Warehouse,