Data Were House

Data Warehouse - Da Modelagem a Implantação AUTOR: CAMILO MUSSI

Introdução O contexto em que se vive atualmente demanda das organizações uma capacidade de analisar, planejar e reagir rápida para poder acompanhar ou superar as exigências dos clientes e à ameaça da concorrência. Para que isto aconteça, é necessário que a organização tenha disponível, quando necessário, as informações que constituem a base para obtenção de vantagens competitivas e maior fidelidade dos clientes. A todo o momento uma grande quantidade de informações sobre os mais variados aspectos dos negócios da empresa é gerada e armazenada, passando a fazer parte da base de conhecimento. Entretanto, esses dados estão espalhados por vários sistemas de difícil integração, sem qualidade e indisponíveis para os gerentes e altos executivos que são os tomadores de decisões estratégicas das organizações. Para suprir essa deficiência surgiu o Data Warehouse (DW), que se constitui de um conjunto de arquiteturas e/ou sistemas de informação orientados a assunto que existem em plataformas segregadas do ambiente transacional, manipulando grande volume de dados, principalmente históricos, e dão origem a consultas (read-only) invariavelmente não previsíveis, que tem por objetivo dar suporte a esses processos. O objetivo desse tutorial é apresentar os principais conceitos e questões envolvidas com este tecnologia, procurando enfatizar a importância de sua utilização para garantir agilidade e segurança na tomada de decisão, definido o caminho a ser desenvolvido desde a modelagem até a implantação de um DW. Histórico O universo dos sistemas de informação é historicamente imaturo, existe apenas desde a década de 1960, a prova disto é a tendência desses sistemas de concentrarem-se nos detalhes. O DW surge num contexto de evolução dos processos de tomada de decisão das empresas, que pode ser mais bem observado segundo uma perspectiva global. O processamento dos Sistemas de Apoio à Decisão (SAD) está em evolução, mas suas origens remontam aos primórdios dos computadores. Em meados da década de 60, começou a proliferação dos arquivos mestres e fitas magnéticas causando um tremendo problema: a redundância dos dados e a difícil manutenção e desenvolvimento dos programas, além da complexidade do hardware. Para solucionar esses problemas surgiu uma nova tecnologia de armazenamento e acesso a dados por volta de 1970, o armazenamento em disco ou Dispositivo de Armazenamento de Acesso Direto (DASD). Nesse novo dispositivo os dados eram acessados de forma direta, ou seja, para acessar o registro “n + 1” não era preciso passar pelos registros 1,2,...,n. O tempo de acesso passou a ser medido em milissegundos, solucionando o problema de tempo das fitas magnéticas. Com o DASD surgiu um software conhecido como Sistema Gerenciador de Banco de Dados (SGBD), que gerencia o armazenamento, acesso e indexação dos dados no DASD, além de outras funcionalidades. Com o SGBD e o DASD surgiu uma solução 1

tecnológica para os arquivos mestres, resolvendo os problemas de tempo de acesso, redundância de dados e etc. Essas novas tecnologias abriram o caminho para o processamento de transações online de alta performance e o surgimento de sistemas bancários, de controle de reservas, controle de produção e outros. Na década de 80 surgiram os computadores pessoais e as linguagens de quarta geração, que transformaram os usuários em sujeitos ativos, já que agora eles passaram a controlar os sistemas e os dados. Com essa nova tecnologia, surgiu a possibilidade de se utilizar os dados para outros objetivos além do processamento online de alta performance. Os Sistemas de Informações Gerenciais (SIG) passaram a ser viáveis, surgindo então o paradigma de um único banco de dados para apoiar o processamento transacional e o processamento analítico. Após o advento das transações on-line de alta performance surgiram os programas de extração, que usando alguns critérios de seleção transportavam os dados para um novo arquivo ou banco de dados. Com isto conseguia-se uma melhora na performance das análises coletivas dos mesmos, pois o processamento não estaria concorrendo com as transações on-line e, além disso, a posse dos dados passou para as mãos dos usuários. Por esses motivos, tornou-se comum o uso dos programas de extração e, conseqüentemente, o advento de alguns problemas como a falta de credibilidade dos dados, problemas de produtividade e a impossibilidade de transformar os dados em informações. Esse novo ambiente desorganizado não atendia às necessidades do futuro e por isso se fizeram necessárias algumas mudanças de arquitetura, surgindo o ambiente projetado de DW. No cerne de um ambiente projetado de DW está a percepção da existência de dois tipos de dados [4]: •

Dados primitivos – utilizados pelos sistemas operacionais das empresas. Podem ser atualizados e refere-se a um presente momento. Atendem as atividades funcionais;

•

Dados derivados – dados resumidos ou calculados para atender às necessidades da empresa. Não podem ser atualizados e são históricos. Atendem as atividades gerenciais.

Como pode ser visto, existe uma grande diferença entre os dados primitivos (dados operacionais) e os dados derivados (dados gerenciais) e, portanto, eles não devem coexistir num mesmo banco de dados. Num ambiente projetado de uma empresa existem quatro níveis [4]: 1. Operacional – contém os dados primitivos e atendem ao processamento on-line de alta performance; 2. Atômico ou DW – contém dados primitivos não atualizados e dados derivados; 3. Departamental – contém informações úteis aos diversos departamentos da empresa. A fonte de todos esses dados é o DW. Há um banco de marketing, um de contabilidade e assim por diante, às vezes denominado Datamart; 4. Individual – geralmente dados temporários e de pequenas proporções e são utilizados para analises heurísticas. A primeira vista, pode-se concluir que existe uma grande redundância de dados neste ambiente mas essa afirmação não é verdadeira. No nível operacional existem apenas registros com valores atuais, no de DW existem dados históricos e, no Departamental, existem registros dos departamentos específicos da empresa. 2

Com isso chega-se ao ambiente que será estudado a seguir. Ambiente de DW Existem, nas empresas, dois tipos de sistemas: •

Sistemas operacionais (On-line Transaction Processing - OLTP): sistemas que dão suporte ao dia a dia do negócio da empresa, que mantém a empresa em funcionamento e são chamados de sistemas de produção e

•

Sistemas informacionais (On-line Analitycal Processing - OLAP): sistemas que dão suporte aos processos decisórios da empresa, que irão dar subsídios para as decisões estratégias da empresa e compreendem os SADs e os SIGs.

Como os dados informacionais exigem uma quantidade significativa e variada de recursos, devem estar num ambiente de banco de dados separado dos dados operacionais. Alguns motivos que levam a essa separação: •

O DW engloba dados de vários sistemas OLTP e

•

As estruturas básicas de dados de um DW são diferentes do sistema OLTP.

A grande vantagem de separar esses dados é que, como eles satisfazem a objetivos diferentes, eles poderão se concentrar no que fazem, oferecendo melhor desempenho e funcionalidade. Conceito de DW Segundo W. H. Inmon [4], um DW é uma coleção de dados orientada por assuntos, integrada, variante no tempo e não volátil, que tem por objetivo dar suporte aos processos de tomada de decisão. Os dados dos sistemas operacionais irão constituir a base de carga do DW. Esses dados, após sofrerem um processo de transformação, irão ser associados a um novo ponto no eixo do tempo e armazenados no DW. Contudo, um DW irá exigir mais recursos do que os vistos anteriormente e, portanto, serão incluídas também informações vindas de várias outras fontes internas (planilhas eletrônicas, documentos textuais, etc.) bem como fontes externas (jornais, revistas etc.) Características 1. Orientado por Assunto Refere-se ao fato de que os dados estaão organizados de acordo com os assuntos de interesse da empresa, como por exemplo: produto, cliente, loja. Em contrapartida, os dados dos sistemas operacionais estão organizados de acordo com a funcionalidade da empresa, como por exemplo, no caso de uma escola: aluno, servidor, matrícula. Esses assuntos serão armazenados em um conjunto de tabelas relacionadas. É importante enfatizar que, não necessariamente, todas essas tabelas devem estar com o mesmo nível de resumo ou no mesmo dispositivo de armazenamento. 2. Integrado Refere-se ao fato de que todo dado, trazido dos sistemas operacionais para o ambiente de DW é, anteriormente, consolidado, de forma que passe a ter um único significado. Como exemplo, considere o atributo “sexo” que, em uma aplicação é 3

tratado como “m/f”, em outra como “1/0”, outra como “x/y” e outra como “masculino/feminino”. Para ser transportado para o DW, o dado tem que ser codificado de uma única forma. 3. Variante no Tempo Refere-se ao fato de que as estruturas de dados no DW sempre contêm um atributo de tempo, ou seja, a cada mudança ocorrida num dado, uma nova entrada é criada e não atualizada, como acontece nos sistemas operacionais. É importante salientar a complexidade do ambiente de DW, pois pode possuir não somente resumos anuais e mensais como também diários e semanais. Sabe-se que o número de dias e o início de uma semana diferem de um mês para o outro e de um ano para o outro. Além disso, os metadados também devem acompanhar essa variação no tempo, pois um determinado dado pode ter um significado numa época e outro em uma época diferente. 4. Não Volátil Refere-se ao fato de que, em um DW, os dados não sofrem atualizações. Eles são carregados uma única vez e, a partir desse momento, só podem ser consultados. Ao contrário do que acontece nos sistemas operacionais onde existem milhões de transações de atualizações ocorrendo a todo instante. Por isso esses sistemas têm de possuir um grande número de controles para que não ocorra nenhuma inconsistência devido a uma transação interrompida indevidamente. OLTP X OLAP Existem grandes diferenças entre os dois ambientes que, a seguir, serão definidas, mostrando o benefício que a implantação do DW pode trazer para o ambiente operacional. 1. Integração dos dados Os dados no ambiente operacional não estão integrados, cada sistema possui uma definição própria. Para migrá-los para o DW deve existir uma integração prévia, porque se os dados chegarem em um estado não integrado, não poderão ser utilizados para obter uma visão corporativa. Com isso consolidam-se dados inconsistentes dos sistemas mais antigos em conjuntos coerentes. 2. Atualização dos dados Não há sobreposição entre os registros existentes no ambiente operacional e no de DW. Caso ocorra uma mudança, um novo registro é inserido no DW, associando ao mesmo um elemento de tempo. Com isso os dados históricos não precisam mais ser guardado no ambiente operacional. A remoção de grandes volumes de dados traz algumas facilidades para o ambiente de produção como: correção, reestruturação, monitoração e indexação, deixando o ambiente mais maleável. 3. Ciclo de vida do desenvolvimento O ciclo de vida do DW começa pelos dados. Caso esses dados estejam sob controle, eles são integrados e testados para verificar distorções. Então, é feita a codificação do programa. Os resultados dos programas são analisados e, finalmente, os requisitos do sistema são compreendidos. 4. Organização dos dados (modelo de dados) Enquanto no ambiente operacional, os dados são modelados segundo a técnica denominada Modelagem Entidade/Relacionamento, que busca remover qualquer 4

redundância dos dados para obter um melhor desempenho da transação, no ambiente de DW os dados são modelados segundo a técnica da Modelagem Multidimensional, que busca obter um maior desempenho nas consultas e atender às necessidades de simplicidade do usuário. 5. Tempo de resposta A noção de tempo de resposta nos dois ambientes é bem diferente. Enquanto no OLTP, o tempo de resposta é um fator crítico, ou seja, está diretamente ligado aos negócios, no ambiente de DW é mais atenuado, podendo ser medido em minutos, horas ou dias. No entanto isso não quer dizer que ele não seja importante, o tempo de resposta está diretamente ligado à produtividade, então quanto menor mais resultados serão alcançados. 6. Uma máquina ou duas Como o DW exige uma quantidade significativa e variada de recursos, geralmente é implementado em uma máquina separada do sistema OLTP. A palavra recurso, de um modo geral, é um motivo suficiente para requerer uma segunda máquina, mas existem outros dois motivos importantes. Primeiro, o DW é um recurso centralizado que integra dados de vários sistemas OLTP. Neste caso, por definição, a máquina do DW é separada. Segundo, as estruturas básicas de dados do DW são completamente diferentes daquelas do sistema OLTP. Como os dados devem ser copiados e reestruturados para o DW, praticamente não há razão para mantê-los na máquina do original OLTP. [6] 7. Metadados São normalmente definidos como “dados sobre dados”. Talvez uma definição mais exata seja a de que metadado é uma abstração dos dados, ou ainda, dados de alto nível que descrevem dados de um nível inferior. Sem metadados, os dados não têm significado. São exemplos de metadados as descrições de registros em um programa de aplicação ou o esquema de um banco de dados descrito em seu catálogo ou ainda as informações contidas em um dicionário de dados. Em um ambiente operacional, os metadados são especialmente valiosos para os desenvolvedores de aplicação e os administradores de banco de dados. Os bancos de dados operacionais são usualmente utilizados via aplicação, que já contém as definições de dados embutidas. Seus usuários simplesmente interagem com as telas do sistema, sem precisar conhecer como os dados são mantidos pelo banco de dados. O ambiente de suporte a decisão, por sua vez, é bastante distinto. Nele, analistas de dados e executivos procuram por fatos não usuais e correlações que serão conhecidas quando encontradas. Aplicações rotineiras e predefinidas não fazem sentido neste ambiente. Os usuários de um DW precisam examinar seus dados e para tal, conhecer sua estrutura e significado. De um modo geral existem três camadas de metadados em um DW: •

Operacionais (do nível das aplicações) – definem a estrutura dos dados mantidos pelos bancos operacionais, usados pelas aplicações de produção da empresa;

•

Centrais do DW – mantidos no catálogo do DW. Distingue-se por serem orientados por assunto, definindo como os dados transformados devem ser interpretados. Incluem definições de agregados e campos calculados, assim como as visões sobre cruzamentos de assuntos; 5

•

Nível do usuário – mapeiam os metadados do DW para conceitos que sejam familiares e adequados aos usuários finais.

Projetando um DW Os DW de sucesso não são como os sistemas operacionais que possuem fases de desenvolvimento e manutenção bem distintas. Eles são entidades dinâmicas que mudam de acordo com as necessidades de negócio da organização, caracterizando-se assim por uma abordagem de desenvolvimento evolucionária. Além do seu dinamismo, os custos de implementação e o impacto nos sistemas operacionais também justificam essa abordagem. Muitas empresas iniciam o processo por um departamento que tenha carência de informação e cujo trabalho seja relevante para a organização, criando os chamados datamarts , para depois ir acrescentando aos poucos. Outra opção é disponibilizar um protótipo de DW, escolher alguns usuários e deixar que eles experimentem essas pequenas amostras. Após a concordância do grupo, carregar os dados dos sistemas operacionais e dados externos. De qualquer forma, Inmon [4] salienta que é um erro pensar que técnicas de projeto que servem para sistemas convencionais serão adequadas para a construção de um DW. Os requisitos para um DW não são conhecidos até que ele esteja parcialmente carregado ou já em uso. Outra questão importante, discutida por Kimball [6], é a adequação do modelo entidade-relacionamento ao tipo de transação OLTP. O principal objetivo da modelagem, neste caso, é eliminar ao máximo, a redundância, de tal forma que uma transação que promova mudanças no estado do banco de dados, atue o mais pontualmente possível. Com isso, nas metodologias de projeto usuais, os dados são fragmentados por diversas tabelas, o que traz uma considerável complexidade à formulação de uma consulta por um usuário final. Por isso, esta abordagem não parece ser a mais adequada para o projeto de um DW, onde estruturas mais simples, com menor grau de normalização devem ser buscadas. Não existe ainda no mercado uma metodologia de desenvolvimento de DW consolidada, o que se vê são propostas de construção do modelo dimensional a partir dos modelos corporativos ou departamentais de forma incremental. Segundo Inmon [4], um DW é construído de forma heurística, confirmando a abordagem evolucionária descrita anteriormente. De qualquer forma, a metodologia a ser adotada é ainda bastante dependente da abordagem escolhida, em termos de ambiente, distribuição, etc.. A seguir, serão apresentadas etapas sugeridas para desenvolvimento de um projeto de DW. Entrevistando os usuários finais Deve-se começar pelas entrevistas com os usuários finais para saber quais informações importantes são necessárias para serem consultadas e analisadas. Segundo Kimball [6], as entrevistas com os usuários finais têm duas finalidades. Primeiro, oferecem ao projetista uma visão concreta das necessidades e expectativas da comunidade de usuários. As entrevistas criam uma conexão entre as equipes de projetistas do DW e do negócio. Entender o negócio é a “moeda de ouro” da equipe de projetistas. Essas entrevistas são essenciais ao sucesso do projeto. A segunda finalidade das entrevistas permite aos projetistas aumentar o nível de conscientização dos usuários finais quanto à implantação do DW, assim como adequar 6

suas expectativas. Entrevistar o usuário final é sem dúvida uma faca de dois gumes. A equipe de projetistas deve estar preparada para dar continuidade ao projeto logo após o término das entrevistas, porque o DW estará nas mentes dos usuários. O processo de entrevista deve alternar entre grupos de usuários finais e Administradores de Banco de Dados (DBAs) de sistemas legados. À medida que os usuários finais levantam os tópicos importantes, surgem as questões sobre qual a capacidade dos dados disponíveis de suportar tais tópicos. As entrevistas ideais consistem em sessões de uma hora, em que dois ou três projetistas da equipe reúnem-se com um gerente de área e alguns de seus subordinados. As reuniões com muitos participantes de cada departamento são uma perda de tempo. Uma hora de reunião será mais que suficiente para a equipe de DW obter informações iniciais e geralmente é oportuno absorver as principais necessidades do usuário antes de prosseguir com as entrevistas. Em uma organização de grande porte, é aconselhável realizar uma ou duas entrevistas com cada segmento, mesmo que alguns deles não sejam prioritários para o DW. Será especialmente importante incluir tanto o segmento matriz como o filial nas entrevistas principais, além das áreas igualmente importantes. Será melhor não entrevistar todas as equipes de uma determinada área em seqüência, isto é, todas as equipes de marketing, seguidas de todas as equipes de produção e de todas as de vendas. À medida que as entrevistas progridem, os projetistas adquirem maior entendimento do negócio e pode ser útil retornar a um tópico do início do processo, nas últimas entrevistas. O conteúdo das entrevistas finais não deve acrescentar nada de extraordinário às informações coletadas, comprovando dessa forma que todos os aspectos importantes do negócio foram abordados. Caso surjam informações totalmente novas nas etapas finais do processo de entrevistas, então devemos suspeitar de que alguns dos tópicos não foram amplamente cobertos. Deve-se ter cuidado na escolha do usuário que deve ser entrevistado. O mesmo deve ser capaz de responder todas as perguntas sobre o negócio da empresa e especialmente do seu departamento. O segredo de uma boa entrevista é fazer o usuário descrever seu trabalho. Há várias perguntas que resultam em respostas produtivas. A seguir estão algumas delas, mas lembre-se: Seja flexível. •

Qual a missão do seu grupo/departamento/divisão?

•

Qual mudança recente na condução do negócio é mais significativa?

•

Como você mede o sucesso em seu grupo?

Perguntas sobre o nível de granularidade devem ser incluídas: •

Você consulta os dados diariamente?

•

Você precisa distinguir terças de sábados?

•

Instantâneos mensais são suficientes para o que você deseja fazer?

A combinação dos níveis de detalhe de cada uma das dimensões determina a granularidade da tabela de fatos central. Finalmente algumas perguntas sobre urgência : •

É necessário que os dados de ontem estejam disponíveis hoje? Observe que essa pergunta é diferente daquela de granularidade. É possível que um 7

grupo precise distinguir terças-feiras de sábados (granularidade), mas não que os dados de ontem estejam disponíveis hoje (urgência). •

Quanto tempo após o fechamento do mês deve ser gerado o instantâneo mensal?

As respostas a essas perguntas orientarão o projeto do sistema de extração de dados. No final da entrevista, será um bom momento para serem solicitados exemplos de relatórios sobre os temas discutidos. Um processo de entrevista bem sucedido deve resultar num acúmulo de relatórios administrativos. Entrevistando os DBAs Segundo Kimball [6], as entrevistas com os DBAs são de vital importância, pois eles são os especialistas dos sistemas legados que podem ser usados como fonte de dados do DW e, por isso, devem ser realizadas intercaladas com as dos usuários finais. Essas entrevistas devem checar a consistência dos temas abordados nas entrevistas com os usuários finais. Deve também ser solicitado, anteriormente, aos DBAs, a descrição textual de cada tabela importante do banco, dos campos das tabelas e a contagem de linhas de cada tabela para servir como suporte a construção do DW. A seguir estão descritas algumas perguntas que devem ser feitas aos DBAs : •

Como os vários sistemas de produção relacionam-se entre si? Que sistema alimenta outro sistema? Qual a origem dos dados?

•

Onde os DW obtém os arquivos mestre para algumas das dimensões chave?

•

Quais campos das tabelas importantes estão preenchidos? Quais estão totalmente preenchidos? Quais possuem garantia de qualidade? Quais são obrigatórios no momento da entrada de dados? Quais são validados no momento da entrada de dados?

•

O que os códigos significam? Onde é possível obter a descrição textual dos códigos? Quem pode informar o significado dos códigos?

•

Como são administradas as chaves das tabelas? Elas são reutilizadas?

•

Sempre é gerada uma nova chave de produção quando acontece uma modificação num determinado registro? Existe um documento descrevendo exatamente essa modificação? Seremos notificados sobre essas modificações?

•

É possível ler diretamente os arquivos de produção de dados? Quais sistemas estão disponíveis para executar essa etapa de leitura? Os registros modificados são identificados nos arquivos de dados de produção? É possível ler o histórico de transações original?

•

Há campos nessas tabelas sendo utilizados com mais de uma finalidade e depende do contexto?

No final da entrevista, será um bom momento para ser solicitado exemplos de relatórios fornecidos a comunidade de usuários. Definindo o modelo de dados Após levantamento das informações que os usuários desejam analisar no DW e os sistemas legados onde se encontram essas informações, deve-se definir o “escopo de integração”, que consiste em identificar as entidades que pertencem ao escopo do modelo de dados. 8

Depois de definir o escopo, para construir um modelo de dados para o DW, o ponto de partida é o modelo corporativo. Contudo, um considerável número de alterações é feito no modelo corporativo para ser aplicado ao DW, como : •

Remover dados meramente operacionais.

•

As estruturas de chaves do modelo corporativo de dados são aumentadas para conter um elemento de tempo.

•

Os relacionamentos de dados dos modelos operacionais são transformados em “artefatos” no DW.

•

Realização de análise de estabilidade (consiste em agrupar atributos de dados de acordo com sua propensão a alterações).

No final dessas transformações, se esboçará um modelo de dados que servirá como guia para a construção do DW iterativamente. A seguir, estão algumas das muitas razões da importância do desenvolvimento iterativo [4]: •

O usuário final não terá condições de expressar suas necessidades com clareza até que a primeira iteração seja feita;

•

A gerência não se comprometerá por completo até que verdadeiros resultados tangíveis e claros sejam apresentados;

•

Há necessidade de, rapidamente, obter resultados visíveis.

Como todo o esforço de desenvolvimento é guiado pelo modelo de dados unificado, ele irá produzir um todo coeso e firmemente orquestrado. Contudo há algumas limitações quanto ao uso do modelo de dados como alicerce do DW. O modelo de dados parece tornar todas as entidades iguais e, na realidade, no mundo do DW, as entidades não são pares idênticos, elas demandam seu próprio tratamento especial. Analisando o DW sob uma perspectiva tridimensional, observa-se que algumas entidades serão escassamente povoadas, ao passo que outras serão altamente povoadas. A vantagem da criação do modelo dimensional consiste em agilizar os dados para o processamento do SAD. Por meio da pré-junção dos dados e da geração de redundância seletiva, o projetista simplifica e agiliza os dados para acesso e análise, que é necessário para o DW. Em resumo, o modelo de dados relacional e o dimensional se enquadram como alicerces do projeto do DW. O modelo dimensional se aplica como um alicerce do projeto das entidades de grande porte que existirão. O modelo de dados relacional se aplica como alicerce do projeto para as entidades de pequeno porte. Existem dois tipos de esquema para o modelo dimensional: o star join (estrela) e o snowflake (flocos de neve). No modelo star join, as instâncias são armazenadas em uma tabela contendo o identificador de instância, valores das dimensões descritivas para cada instância, e valores dos fatos ou medidas, para aquela instância (tabela de fatos). Além disso, pelo menos uma tabela é usada, para cada dimensão, para armazenar dados sobre a dimensão (tabela de dimensão). Este esquema é chamado de star join por apresentar uma tabela de fatos dominante no centro do esquema e as tabelas de dimensões nas extremidades. A tabela de fatos é ligada às demais tabelas por múltiplas junções, 9

enquanto as tabelas de dimensões se ligam apenas à tabela central por uma única junção. A tabela de fatos é onde as medidas numéricas do fato representado são armazenadas. Cada uma destas medidas é tomada segundo uma interseção de todas as dimensões. O outro tipo, o modelo snowflake, consiste de uma extensão do star join, onde cada uma das pontas da estrela passa a ser o centro de outras estrelas. Porque cada tabela de dimensão seria normalizada, quebrando-se a tabela original ao longo de hierarquias existentes em seus atributos. Kimball [6] aconselha os projetistas a resistirem à tentação de transformar esquemas estrela em floco de neve, devido ao impacto da complexidade deste tipo de estrutura sobre o usuário final, enquanto que o ganho em termos de espaço de armazenamento seria pouco relevante. Questões que devem ser observadas na modelagem Segundo Kimball [6], algumas características devem ser observadas, durante a modelagem do DW, para que as consultas não produzam resultados incorretos, pois as mesmas servirão de base para a tomada de decisão das empresas, ou se tornem muito lentas e impossíveis de serem executadas. São elas: •

Atributos semi-aditivos e não aditivos

Uma operação não aditiva, como o cálculo da margem bruta, pode ser computada em qualquer plano da tabela de fatos, lembrando-se de calcular o quociente das somas, não a soma dos quocientes. Em outras palavras, o resultado deve ser a divisão das somas e não o inverso. Uma operação semi-aditiva não pode ser adicionada ao longo de todas as dimensões da tabela de fatos, deve-se limitar com isso a operação às dimensões válidas. •

Dimensões descaracterizadas

Números de controle de documentos, como números de pedidos, números de fatura e números de conhecimento de embarque, normalmente são representados como dimensões descaracterizadas (isto é, chaves de dimensão sem uma tabela correspondente) em tabelas de fatos em que o grão da tabela é o documento propriamente dito ou uma linha de item do documento. •

Dimensões derivadas que suportam agregados

Ë extremamente importante construir tabelas de fatos derivadas (resumidas) em vários níveis superiores de detalhe para melhorar o desempenho das consultas, que de outra forma apresentariam um grande número de registros. Existem muitas formas de agregados no DW, sendo as mais comuns: a. Cumulativa simples: as transações diárias são transportadas do ambiente operacional e resumidas em forma de registros no DW. O resumo pode ser feito por qualquer área de interesse, segundo a qual o DW esteja organizado. b. Resumo rotativo: os dados passam do ambiente operacional para o DW como mencionado anteriormente. A diferença está na forma como é agregado. Por exemplo, nesta estrutura, nos primeiros sete dias da semana a atividade é resumida em sete posições diárias. No oitavo dia, as sete posições diárias são acumuladas e colocadas na primeira posição semanal. No final do mês, as posições semanais são acumuladas e colocadas na primeira posição mensal. No final do ano, as posições mensais são acumuladas, e a primeira posição anual é 10

carregada. Existem vantagens e desvantagens nesta abordagem com relação a anterior: ƒ

Os dados podem ser processados para encontrar o ponto mais alto, mais baixo, a média, e assim por diante.

ƒ

A primeira e a última ocorrência de dados podem ser dispostas em um bloco.

ƒ

Dados de determinados tipos, inseridos nos limites de diversos parâmetros, podem ser mensurados.

ƒ

Dados válidos em relação a um determinado momento podem ser dispostos em um bloco.

ƒ

Os dados mais antigos e os mais recentes podem ser dispostos em um bloco.

c. Dimensões grandes: não se devem desmembrar as dimensões, mesmo que elas sejam extensas, pois poderá causar um desempenho limitado. A melhor abordagem para rastrear modificações nessas tabelas é subdividi-las em minidimensões compostas por pequenos conjuntos de atributos estruturados para conter um número limitado de valores. d. Dimensões de modificação lenta: o DW deve representar de forma concreta o histórico passado, por isso não se pode considerar que as entidades não se modificam ao longo do tempo. Entretanto, a solução não será incluir tudo na tabela de fatos ou tornar cada dimensão dependente no tempo. Em vez disso, deve-se explorar o fato de que a maioria das dimensões é constante ao longo do tempo e que se pode preservar uma estrutura dimensional independente, incluindo relativamente poucas adições para capturar o aspecto temporal das modificações. Essas dimensões praticamente constantes são chamadas de dimensões de modificação lenta. Existem três opções de modificação destas dimensões, cada uma delas resultando em um diferente nível de rastreamento de modificações ao longo do tempo: ƒ

Substituir os valores antigos dos registros da dimensão e, portanto, perder a capacidade de rastrear o histórico passado.

ƒ

Adicionar um registro à dimensão, contendo os novos valores do atributo no momento da mudança, para segmentar o histórico entre a descrição antiga e a nova descrição com muita precisão.

ƒ

Criar novos campos “atuais” no registro original da dimensão para incluir os novos valores do atributo, mantendo também seus valores originais, permitindo dessa forma descrever o histórico anterior e o posterior à mudança tanto em relação aos valores originais do atributo quanto aos valores atuais.

e. Tabela de fatos sem fatos: alguns processos que são representados no DW produzem tabelas de fatos semelhantes às tabelas que foram construídas, mas que não contém fatos mensuráveis. São chamadas de tabelas de fatos sem fatos. As duas principais variações dessas tabelas são tabelas de rastreamento de eventos e tabelas de cobertura. Os eventos são geralmente modelados por uma tabela de fatos contendo algumas chaves, cada qual representando uma dimensão do evento, freqüentemente não estão associadas a fatos numéricos óbvios. As tabelas de cobertura são, freqüentemente, tabelas de eventos que 11

não ocorreram e, de modo geral, não contém fatos assim como as tabelas de rastreamento de eventos. [6] Decisões no projeto de um DW Uma vez que o modelo de dados tenha sido definido, o próximo passo é definir algumas características do projeto físico, para que se possam satisfazer alguns critérios como: •

Capacidade de gerenciar grande quantidade de dados.

•

Capacidade de permitir que os dados sejam acessados de modo flexível.

•

Capacidade de, periodicamente, carregar grande quantidades de dados.

•

Capacidade de acessar dados de um registro por vez, ...

Granularidade O mais importante aspecto do projeto de DW é a questão da granularidade, pois afeta profundamente o volume de dados que residem no DW e, ao mesmo tempo, afeta o tipo de consulta que pode ser atendida. O volume de dados e o espaço bruto não são as únicas questões relevantes, existe também a força de processamento que precisa ser empregada para acessar esses dados. Há, portanto, um bom motivo para a compactação de dados, porque se economiza, sobre o total de DASD utilizado, o número de índices necessários e os recursos de processador para o tratamento de dados. No entanto, à medida que o nível de granularidade se eleva, há uma correspondente diminuição da possibilidade de utilização dos dados para atender a consulta. Para solucionar essa questão, ou seja, possuir armazenamento e acesso aos dados de forma eficiente e, ao mesmo tempo, poder analisar os dados em maior detalhe, deve-se utilizar níveis duais de granularidade na parte detalhada do DW. Ao criar dois níveis de granularidade no nível detalhado, o arquiteto do SAD possibilita que, na maior parte do tempo, o processamento dirija-se aos dados levemente resumidos que são compactados e de fácil acesso, além de disponibilizar o nível de dados históricos quando um maior nível de detalhe for requerido. Em decorrência dos custos, da eficiência, da facilidade de acesso e da possibilidade de atender a qualquer consulta que possa ser respondida, para a maior parte das empresas, o nível dual de dados consiste na melhor opção arquitetônica para o nível detalhado do DW. Particionamento O objetivo do particionamento dos dados de detalhe corrente consiste em repartir os dados em unidades físicas menores, para proporcionar ao pessoal de operação e ao projetista mais flexibilidade no gerenciamento dos dados do que é proporcionado pelas unidades físicas maiores. Quando os dados residem em unidades físicas maiores, entre outras coisas, eles não podem ser: Reestruturados facilmente; Indexados livremente; Pesquisados seqüencialmente, se necessário; Reorganizados, Recuperados ou Monitorados facilmente 12

Há vários critérios por meio dos quais é possível dividir dados, como: Data; Área de negócio; Área geográfica; Unidade organizacional ou por todos os critérios anteriores. Ciclicidade dos dados A ciclicidade de dados refere-se ao tempo necessário para que uma alteração realizada no ambiente operacional seja refletida no DW. Algumas razões devem ser observadas, como: •

Quanto mais rigidamente o ambiente operacional for emparelhado com o DW, mais dispendiosa e complexa será a tecnologia.

•

Os dados devem ser estabilizados antes de migrarem para o DW.

Eliminação dos dados Há diversas maneiras pelas quais os dados são eliminados ou os detalhes dos dados são transformados, como [4]: •

Acrescentados a um arquivo de resumo rotativo onde os detalhes são perdidos.

•

Transferidos de um meio de armazenamento para outro de alta performance, como do DASD para um meio de armazenamento em massa.

•

Efetivamente eliminados do sistema.

•

Transferidos de um nível de arquitetura para outro, como do nível operacional para o nível de data warehouse.

Instantâneos A interação básica de negócios, que faz com que o DW se torne povoado por dados, pode ser chamada de interação “EVENTO -> INSTANTÂNEO”. Em uma interação “EVENTO -> INSTANTÂNEO”, algum evento de negócio dispara um instantâneo de dados (normalmente no ambiente operacional), que por sua vez é movido para o ambiente de DW. Existem dois tipos de evento de negócio que podem disparar um instantâneo: •

Evento gerado pela atividade: um exemplo pode ser a concretização de uma venda, a entrada de um item no estoque, a realização de uma chamada telefônica ou a entrada de uma carga.

•

Evento gerado pelo tempo: Um exemplo pode ser o final do dia, o final da semana, ou o final de mês.

Erros na implantação de um DW O Data Warehousing Institute [10] aponta os dez erros mais comuns na implantação de um DW: 1. Começar o projeto com o tipo errado de patrocínio. 2. Gerar expectativas que não podem ser satisfeitas, frustrando os executivos quando da utilização do DW. 3. Dizer: “Isto vai ajudar os gerentes a tomar decisões melhores” e outras informações politicamente ingênuas. 4. Carregar o DW com informações só “porque estavam disponíveis” . 13

5. Falhar no objetivo de acrescentar valor ao dada por meio de mecanismos de desnormalização, categorização e navegação assistida. 6. Escolher um gerente que seja voltado para a tecnologia e não para o usuário. 7. Focalizar em dados tradicionais internos orientados a registro e ignorar o valor potencial de dados textuais, imagem, som, vídeo e dados externos. 8. Fornecer dados com definições confusas e sobrepostas. 9. Acreditar nas promessas de desempenho, capacidade e escalabilidade dos vendedores de produtos. 10. Usar o DW como justificativa para modelagem de dados e uso de ferramentas case. Povoando um data warehouse A extração, limpeza, transformação e migração de dados dos sistemas existentes na empresa para o DW constituem tarefas críticas para o seu funcionamento efetivo e eficiente. Diversas técnicas e abordagens têm sido propostas, algumas bastante genéricas e outras especialmente voltadas para a manutenção da integridade dos dados num ambiente caracterizado pela derivação e replicação de informações. O grande desafio por trás da alimentação de dados das fontes para o DW não é técnico, mas gerencial. Muitos dos processos envolvidos – como mapeamento, integração e avaliação da qualidade – ocorrem de fato durante a fase de análise e projeto. Especialistas afirmam que identificar fontes, definir regras de transformação, detectar e resolver questões de qualidade e integração consome cerca de 80% do tempo de projeto. Embora algumas ferramentas possam ajudar a detectar problemas na qualidade dos dados e gerar programas de extração, a maioria das informações necessárias para desenvolver regras de mapeamento e transformação existe apenas na cabeça dos analistas e usuários. Fatores que certamente influem na estimativa de tempo para estas tarefas são o número de fontes e a qualidade dos metadados sobre as fontes. As regras de negócio associadas a cada fonte – tais como validação de domínios, regras de derivação e dependências entre elementos de dados – são outras fonte de preocupações. Se estas regras tiverem de ser extraídas do código fonte das aplicações, o tempo para mapeamento e integração pode dobrar. Os processos associados à migração de dados das fontes para o DW incluem extração de dados, limpeza, transformação e carga do DW. Extração As várias alternativas para extração permitem balancear desempenho, restrições de tempo e de armazenamento. Por exemplo, se a fonte for um banco de dados online, pode-se submeter uma consulta diretamente ao banco para criar os arquivos de extração. O desempenho das aplicações ligadas às fontes pode cair consideravelmente se transações on-line e as consultas para extração competirem entre si. Uma solução alternativa é criar uma cópia corrente dos dados das fontes a partir da qual então se fará a extração. Como desvantagem desta solução, pode-se citar o espaço adicional de disco necessário para armazenar a cópia. Outra alternativa é examinar o ciclo de processamento de algumas transações off-line que atuem nas fontes. Os programas que criam os arquivos de extração para a carga do DW podem ser incorporados a um ponto apropriado do esquema de processamento. 14

Transformação e filtros Os processos de transformação invocam as regras que convertem valores de dados das fontes para valores do ambiente global e integrado do DW. Algumas ferramentas permitem ao usuário controlar a maioria das atividades de exportação e transformação por meio de parâmetros e “scripts”, constituindo uma filtragem avançada. Outras ferramentas atuam como shells onde programas específicos de extração e filtragem são inseridos. Incorporando modificações Sempre que modificações relevantes são feitas nas fontes de informações, estes novos dados são extraídos e traduzidos para o modelo de dados do DW, onde são integrados com os já existentes. A detecção e extração das modificações dependem das facilidades disponíveis pela fonte. Se esta fonte dor sofisticada, como um SGBD relacional que possui triggers, este processo é relativamente fácil. No entanto, em muitos casos a fonte não dispõe de recursos avançados para detecção e captura das modificações (sistemas herdados, por exemplo). Neste casos existem basicamente três alternativas para detectar e extrair modificações: 1. A aplicação que utiliza a fonte de informação é alterada de modo a enviar notificações de alteração para o DW. Esta alternativa requer que o código existente seja modificado. No entanto, na maioria dos casos essa opção é impraticável devido à complexidade do código e grande tempo necessário para sua alteração. 2. O arquivo de log do sistema é analisado de modo a obter as modificações relevantes. O problema com esta alternativa é que, normalmente, são necessários privilégios de DBA para acessar o log e muitos administradores relutam em prover este acesso pois coloca em risco a segurança do sistema. 3. As modificações são determinadas por meio da comparação do dump corrente da fonte com um anterior. O problema com esta alternativa é que ela não é muito escalonável, ou seja, à medida que os dados das fontes aumentam é necessário um número muito maior de comparações. Deste modo, torna-se absolutamente necessário implementar este algoritmo do modo mais eficiente possível. OLAP OLAP sempre envolve consultas interativas aos dados, seguindo um caminho de análise por meio de múltiplos passos, como por exemplo, aprofundar-se sucessivamente por níveis mais baixos de detalhe de um quesito de informação específico. Envolve capacidades analíticas, incluindo a derivação de taxas, variâncias e outras, envolvendo medidas ou dados numéricos por meio de muitas dimensões, devendo suportar modelo de previsões, análises estatísticas e de tendências. Dois tipos de processos são bastante comuns em aplicações OLAP: •

Slice and Dice: corresponde à técnica de mudar a ordem das dimensões mudando assim a orientação segundo a qual os dados são visualizados. Embora os dados permaneçam os mesmos, a mudança de orientação permite ao usuário investigar diferentes inter-relacionamentos entre eles.

•

Drill Down: consiste em permitir ao usuário “descer” pelas hierarquias das dimensões: é comum o usuário iniciar pelo nível resumido (tal como vendas 15

nacionais, por marca) e então seletivamente obter níveis de detalhe adicionais para seguir e explicar uma observação feita no nível resumido. Conclusão As organizações atuais, tanto nacionais como multinacionais, estão sempre procurando vantagens competitivas. Sabe-se que a informação é a chave para se ganhar tal vantagem. O problema é entender como as montanhas de dados que estão nos sistemas operacionais irão ajudar para tal. Nesse cenário, surge o DW como uma alternativa de transformar tais dados em informações que irão ajudar a identificar as oportunidades para obtenção dessas vantagens. Bibliografia [1] Corey, M., Abbey, M., Abramson, I., Taub, B. Oracle 8i - Data Warehouse. Campus, 2001. [2] Gonçalves, M. Extração de Dados para Data Warehouse. Axcel Books, 2003. [3] Inmon, W.H.. Terdeman, R. H., Imjoff, C. Data Warehousing: como transformar informações em oportunidades de negócio. Berkeley, 2001. [4] Inmon, W.H. Como Construir o Data Warehouse. Campus, 1997. [5] Inmon, W.H., Welch, J. D., Glassey, K. L. Gerenciando Data Warehouse. Makron Books, 1999. [6] Kimball, R. Data Warehouse Toolkit. Makron Books, 1998. [7] Kimball, R., Merz, R. Data Webhouse: construindo o data warehouse para a Web. Campus, 2000. [8] Pinheiro, Carlos A. R. WEB Warehousing, Extração e Gerenciamento de Dados na Internet. Axcel Books, 2003. [9] Thomsen, E. OLAP: Construindo sistemas de informações multidimensionais. Campus, 2002. [10] Singh, H. S. Data Warehouse: conceitos, tecnologias, implantação e gerenciamento. Makron Books, 2001.

16