Primeiramente, é de extrema importância elencar os principais itens que determinarão o sucesso do projeto. Abaixo estão alguns itens importantes:

Transcrição

1 O que é o Bate Byte O Bate Byte foi um jornal técnico que circulou mensalmente dentro da CELEPAR e nos seus clientes. Abrigava tudo, idéias, métodos, tendências, tecnologias, hardware e software. Suas edições estão preservadas neste repositório. Proposta de um Roteiro para Projetar um Data Warehouse Autor: Henrique Salatino Miorelli GPS RESUMO O "data warehouse", literalmente, é um armazém de dados. É uma base de dados carregada de forma incremental em um período de tempo. O "data warehouse" organiza e armazena os dados necessários para processamento informatizado e analítico sobre perspectivas históricas ao longo do tempo, tendo como principal objetivo transformar o dado em informação. É uma arquitetura que utiliza banco de dados desenvolvido para análise e tomada de decisões em bases sumarizadas e também detalhadas, com o intuito de contemplar os segmentos da empresa ou organização. O "data warehouse" pode revolucionar os negócios da empresa. Ao ser bem elaborado e implementado, e caso seja cuidadosamente direcionado para a chamada "inteligência de negócio", ele pode tornar se uma vantagem competitiva. Essa ferramenta está fazendo surgir novos conceitos de gestão da informação, tipos de consultas e análises dos negócios. OBJETIVO O enfoque principal é propor um roteiro que especifique as etapas necessárias no desenvolvimento de um projeto de "data warehouse" visando amenizar o grau de dificuldade encontrado por profissionais da Tecnologia da Informação quando iniciam um projeto deste nível, bem como prover o conhecimento mínimo necessário àqueles profissionais que não têm referência alguma sobre esse assunto. DESENVOLVIMENTO As etapas para a construção do roteiro estão em uma ordem seqüencial, algumas delas podem ser realizadas paralelamente a outras ou a ordem pode ser alterada, de acordo com a necessidade; isso será definido pela equipe que está elaborando o projeto. Sugere se essa seqüência pois facilita o entendimento do objetivo do projeto e descreve etapas interligadas e fundamentais para o sucesso do mesmo. Abaixo o roteiro é apresentado em uma forma esquemática e resumida: 1. Fatores críticos de sucesso Primeiramente, é de extrema importância elencar os principais itens que determinarão o sucesso do projeto. Abaixo estão alguns itens importantes: 1. É fundamental planejar o projeto. 2. É importante ter o orçamento aprovado para desenvolver o projeto de acordo com o plano de investimento da empresa. É importante que a empresa esteja disposta a modernizar se para garantir o 1/9

2 3. É importante que a empresa esteja disposta a modernizar se para garantir o crescimento e a competitividade. 4. É importante ter o apoio e o empenho dos usuários responsáveis e suas respectivas gerências através de atitudes participativas e cooperativas. 5. É fundamental ressaltar a importância das informações para a empresa e, em especial, o compartilhamento das mesmas, evitando duplicidade de dados e informações proprietárias. 6. É necessário negociar um acordo com a alta administração referente à proposta de implementação do projeto. 7. É importante primeiro analisar as áreas de atuação mais lucrativas da empresa. 8. É importante analisar a contenção de custos. 9. É imprescindível que as informações sejam precisas, consistentes e rápidas de se obter. 10. É importante ter a capacidade de adaptação às necessidades de negócio. 11. É necessário apresentar resultados entre as etapas do desenvolvimento do projeto. Após estarem definidos os fatores críticos de sucesso do projeto, deve se iniciar a análise de qual técnica de desenvolvimento de sistemas mais se integra à construção de um projeto de "data warehouse". 2. Definição da técnica para desenvolvimento de sistemas a ser utilizada É de extrema importância utilizar uma técnica para desenvolvimento de sistemas para auxiliar no projeto do "data warehouse". Indica se a técnica da Engenharia da Informação em virtude de os dados serem o enfoque principal desta técnica e em um "data warehouse" o objetivo principal é a transformação dos dados em informações. Ao utilizar a técnica da Engenharia da Informação, torna se mais fácil a forma de visualização dos relacionamentos entre os requisitos básicos que estruturam o negócio objeto de análise. Como produto principal desta técnica temos o modelo de entidades e relacionamentos (MER). Um MER é válido e confiável quando consegue responder às perguntas dos processos que serão por ele atendidos. Portanto, é um modelo obrigatório em qualquer desenvolvimento de sistemas até porque é requisito básico para a implementação física das bases de dados. Tendo definida e assimilada a técnica de desenvolvimento de sistemas a ser utilizada no projeto, é importante entender quais são as necessidades do usuário, diferenciando as entre o ambiente analítico e o operacional. 3. Visualizar as necessidades do usuário O usuário é o fator chave para o sucesso do projeto. Sua participação efetiva durante todo o projeto é o requisito mais importante pois ele é quem domina a área a ser analisada e irá dirimir as dúvidas do analista da informação que implementará o projeto. Há a necessidade de entender a diferença entre os sistemas de processamento operacional e o analítico. Sistemas de processamento operacional são sistemas que suportam as operações do diaa dia da empresa. São sistemas de processamento on line atualizados ao longo do dia. Sistemas de processamento analítico disponibilizam informações usadas para analisar um problema ou uma situação. É feito por meio de comparações ou através da análise de 2/9

3 padrões ou tendências. As informações refletem um instante específico no tempo. Tendo definidas e assimiladas quais são as necessidades do usuário, é importante entender a mudança de enfoque em um projeto de "data warehouse" no que se refere às informações para a tomada de decisões. Durante este processo, é fundamental a participação do usuário e o pleno entendimento dele nesse novo processo de análise da informação. 4. Nova visão da informação para a tomada de decisões O que buscamos quando estamos modelando sistemas de informação é o entendimento operacional do negócio que está sendo modelado, sem pensar na aplicação em si, sem pensar na tecnologia envolvida, mas com a visão relacional de dados. Quando vamos executar uma modelagem multidimensional, estamos desenhando soluções de gestão de negócios, buscando entender como os executivos e gestores de uma organização avaliam as informações para adoção de estratégias e avaliação de desempenho. A análise multidimensional requer um modelo de dados que permita que os dados sejam facilmente visualizados através de diversas perspectivas. O passo seguinte é como analisar a área do negócio a ser modelado. 5. Análise do negócio a ser modelado Primeiramente, definir os objetivos do projeto que podem ser, resumidamente, descritos nos dois itens abaixo: 1. Disponibilizar as bases de dados do ambiente operacional (OLTP) para um ambiente analítico (OLAP). 2. Permitir aos usuários a extração dos dados através de análise exploratória no ambiente OLAP. Definir o escopo do projeto, observando: Caracterizar o problema: o dado deve ser representado como informação para que a empresa possa tomar decisões. Definir quais processos são mais críticos para o negócio e que precisam de decisões sobre ele. Assimilar o conhecimento e definição da área de atuação (negócio) do cliente específico e tomada de decisão. É importante representar este conhecimento em um modelo de entidades e relacionamentos pois será muito útil na modelagem dimensional. Definir grupo gestor da informação que irá participar durante todo o processo de desenvolvimento do projeto. O grupo gestor pode ser considerado como os usuários que dominam a área de negócio e que tomam decisões, juntamente com o pessoal de informática. É extremamente importante a definição do escopo do projeto pois é a base do mesmo. No escopo deve ser descrito se a implementação será em um "data warehouse" (base corporativa que atenderá toda a organização) ou em um ou vários "data mart s" (base de informação por linha de negócio que contém um subconjunto dos dados corporativos da organização). Recomenda se iniciar com "data mart s" integrando os a um "data warehouse" ao longo do tempo. Isto justifica se pelos seguintes aspectos: 3/9

4 O custo é bem inferior a implantar um "data warehouse" de toda a empresa; O tempo de implementação é reduzido; Mais fácil assimilar a atuação de uma área de negócio específica a entender todo o processo da empresa. Optando se por implementar em "data mart s", deve se ter o cuidado de não esquecer a integração entre os "data mart s", caso contrário o projeto é inviabilizado. Tendo definida a área de negócio da empresa a ser implementada no projeto, deve se analisar onde estão as informações que alimentarão o "data warehouse"/"data mart(s)". A origem destas informações é comumente chamada de legado. 6. Análise do ambiente legado Partindo das necessidades de informação por área de negócio já estarem definidas, nesta análise deve se observar o seguinte: Analisar o ambiente computacional da empresa como, por exemplo: "mainframe" IBM, ambiente DOS, ambiente "windows", ambiente UNIX, etc. Se as informações necessárias estão armazenadas nos aplicativos operacionais ou, caso contrário, manter os aplicativos operacionais para que obtenham os dados que faltam. Verificar viabilidade deste tipo de manutenção para gerar a informação que falta no sistema analítico. Definir como integrar as várias fontes de informação, se houver. Um fator importante é como analisar as fontes de informação do ambiente legado como, por exemplo: tipos de bancos de dados (relacionais, em rede, hierárquicos), arquivos seqüenciais, planilhas, etc. Também é importante verificar os modelos de dados, dicionários de dados dos sistemas do ambiente operacional, relatórios gerenciais dos aplicativos, etc. Estas informações auxiliam muito a construção do modelo dimensional. A próxima etapa do roteiro é a construção da modelagem dimensional. 7. Modelagem dimensional dos dados Sugere se utilizar, como técnica principal para a modelagem de dados dimensional, o "star schema" que é a técnica mais indicada para projetos de "data warehouse". A modelagem dimensional compõe se de tabelas dimensões e fatos: Dimensões: Representam as possíveis formas de visualizar os dados. São as entradas para as consultas (tempo, região, cliente, etc). A base para entendimento de qualquer negócio é responder às quatro perguntas fundamentais abaixo: 1. QUANDO? (Período de tempo a que se refere a análise) 2. O QUÊ? (O principal objeto de análise) 3. ONDE? (Localização física ou geográfica para análise) 4. QUEM? (Um objeto específico e detalhado para análise: opcional) 4/9

5 Fatos: É a tabela central que interliga as dimensões e tem os indicadores de análise ou métricas (quantidade, valores,etc.). A tabela fato deverá possuir, no mínimo, as três primeiras dimensões. A pergunta "QUEM?" refere se a um nível de análise mais detalhado. Agregações: Fator importante a analisar durante a modelagem já que o principal objetivo de uma agregação é prever um aumento de performance no acesso aos dados e reduzir o volume de dados na tabela. Resumo das etapas importantes para a modelagem dimensional: 1. Obter a necessidade executiva: qual o negócio objeto de gestão. 2. Entender quais são os indicadores de valor do negócio definindo as métricas de controle. 3. Descrever em um modelo de dados conceitual o negócio. 4. Se houver modelos de relatórios do ambiente operacional: simular. 5. Definir o que descreve o negócio: dimensões. 6. Definir a organização da dimensão tempo: qual a menor unidade de tempo. 7. Trabalhar com o conceito de hierarquia nas dimensões de consulta: Por exemplo, uma hierarquia na dimensão tempo: Dia > Mês > Trimestre > Semestre > Ano 8. Definir a tabela fatos. 9. Montar o "star schema". A modelagem dimensional é aplicada para visualizarmos os dados referentes às necessidades do usuário para obtenção da informação em um sistema analítico. O modelo de dados dimensional independe de qual banco de dados será implementado (ROLAP ou MOLAP). Muito importante é documentar o modelo de dados em uma ferramenta CASE onde definem se as tabelas, atributos, domínios, enfim, todas as informações necessárias para garantir a plena documentação do modelo e facilitar a geração dos esquemas físicos no banco de dados, principalmente em bancos de dados relacionais. Outro fator importante são os metadados que podem ser entendidos como verdadeiros documentadores dos dados que compõem um "data warehouse". Estas informações são armazenadas em um repositório que tem como objetivo principal documentar e administrar os metadados. Os metadados englobam o "data warehouse" e mantêm informações sobre a estrutura dos dados, as fontes de dados, a transformação dos dados, as rotinas de extração de dados, o modelo de dados, relacionamentos e demais informações pertinentes a dar significado ao dado. 8. Aspectos da implementação física Um "data warehouse" exige grande capacidade de armazenamento e processamento dos dados, pois armazena dados analíticos, destinados às necessidades de tomada de decisão. Estes dados podem ser armazenados tanto em um banco de dados relacional (ROLAP) 5/9

6 quanto em um multidimensional (MOLAP). A diferença básica é que em uma estrutura ROLAP devem se criar vários índices atrelados às tabelas fatos e dimensões para um acesso mais rápido e eficiente ao banco de dados enquanto que, em um banco multidimensional, somente precisamos informar quais são as dimensões e os fatos e o próprio banco encarrega se de gerar os cubos. Levantamento de volumes de dados: É necessário analisar a necessidade de sumarizar os dados (agregações). Um fator importante é que as agregações reduzem o volume de dados considerando que um sistema para tomada de decisões geralmente não analisa o dado em nível detalhado pois esta informação já se encontra no ambiente operacional (OLTP). O volume de dados a ser carregado e a previsão de crescimento é fator importante ao decidir qual tipo de banco de dados será utilizado (MOLAP ou ROLAP). Um banco MOLAP não suporta eficientemente um volume muito grande de dados. Ao analisar o volume de dados na tabela fatos, há de considerar o crescimento no número de linhas na tabela, número de dimensões associadas e qual o nível de detalhe desejado. Muitas vezes, é importante analisar a necessidade de separar a tabela, fatos em outras tabelas menores ou em agregações em nível mais alto. Periodicidade de Carga: As rotinas de extração dos dados do ambiente operacional devem ser executadas de acordo com um esquema de processamento pré definido. A periodicidade de execução pode ser diária (inviável quando a extração necessita de muitas fontes externas), semanal, quinzenal, mensal, etc., sempre levando em consideração o volume de processamento. Tempo de Armazenagem dos Dados: De acordo com o volume de dados carregados de forma incremental no "data warehouse", é importante estimar por quanto tempo estes dados deverão estar disponíveis na base de dados. O principal objetivo do "data warehouse" é manter o histórico dos dados por um período de tempo necessário para a análise. Tudo depende do tipo de negócio do cliente. Geralmente a carga inicial do "data warehouse" corresponde a um volume histórico de 3 anos (no mínimo) para dar um respaldo necessário ao processo analítico. De acordo com o crescimento do banco de dados, é necessário gerenciar o expurgo das informações não mais utilizadas em um determinado período de tempo. Caso o usuário queira manter as informações por um período de tempo longo, deve se deixar claro que o custo de manutenção de "hardware" e "software" aumentará. Controle de "Backup s": O administrador do "data warehouse" deve controlar como o "backup" das bases de dados será efetuado (periodicidade, volume, dispositivos de armazenamento, etc.). É importante verificar se há necessidade de copiar todo o banco de dados (visto que, em projetos de "data warehouse" muito grandes, o custo desta atividade é alto e torna se inviável) ou apenas um determinado período de tempo. Obviamente o "backup" é importante e deve ser analisado. Vale a pena verificar se as informações originárias dos sistemas transacionais para carga do "data warehouse" são facilmente recuperáveis pelas rotinas de extração, aproveitando o "backup" das bases operacionais (bancos de dados, arquivos seqüenciais, etc.) em caso de problemas. Neste caso pode se utilizar como "backup" os próprios arquivos oriundos do sistema transacional com os movimentos (diários, semanais, mensais, etc.) carregados no "data warehouse". Tudo depende de como gerenciar este processo e analisar por quanto tempo o "data warehouse" pode ficar indisponível em caso de recuperação do banco de dados e estimar quanto tempo levará a recarga a partir dos "backup s" operacionais. Este gerenciamento envolve os administradores do "data 6/9

7 warehouse" diretamente. Análise de Performance: Indica se a técnica "star schema" pelos principais motivos na implementação física em um servidor ROLAP: As tabelas fato contêm a maioria das linhas de dados. As tabelas dimensão tendem a ter um número menor de linhas. Os "joins" (junções, relacionamentos) em um "star schema" tipicamente envolvem uma tabela fato grande e uma ou mais tabelas dimensão pequenas, o que torna a operação de consulta mais rápida. Sempre consultar as tabelas fatos pelas entradas que são as dimensões. Esquema altamente desnormalizado para melhorar performance. A desnormalização provoca redundância e duplicação de dados, o que privilegia a performance em detrimento do consumo de espaço. Uma análise importante refere se aos índices a serem criados nas tabelas fatos e dimensões quando da implementação em uma estrutura ROLAP. Os índices são extremamente importantes pois permitem o acesso às informações de uma maneira rápida, visto que o processo de tomada de decisão pode envolver consultas complexas que necessitem acessar um grande número de registros. Geralmente, criam se índices das chaves primárias nas tabelas dimensão e fatos, mais outros atributos das dimensões necessários às consultas e também à combinação de dimensões na tabela fatos. Ao criarmos índices em bancos de dados relacionais devemos considerar a granularidade das informações, seletividade e outros fatores pertinentes à estrutura do banco, pois os bancos relacionais analisam seu próprio plano de acesso antes de decidir acessar a estrutura de índices ou se é mais eficiente dar um scan table (pesquisa em toda a tabela). Geralmente, definem se índices clustered para cada chave primária. Este tipo de suporte é fornecido pelo administrador do banco de dados (DBA). Ao utilizarmos um servidor MOLAP (com um banco multidimensional), não é necessário criar índices, visto que a própria estrutura deste tipo de banco de dados cria os cubos com todas as combinações possíveis das dimensões. Devemos informar ao banco de dados quais são as dimensões e quais são os fatos. Esta tecnologia multidimensional tem alta performance porém ocupa um alto espaço de armazenamento, dependendo do volume de dados da tabela fatos. A tendência dos bancos de dados é reunir funcionalidades ROLAP e MOLAP. Segurança: Além de utilizar o esquema de segurança de "logins" do próprio banco de dados (chaves autorizadas e o nível de acesso de cada uma), é importante que o administrador do "data warehouse" tenha um controle do perfil de usuários com autorização de acesso. Muitas ferramentas OLAP possuem um controle de segurança próprios. Outra alternativa é o desenvolvimento de um aplicativo específico de controle de usuários autorizados, antes de executarem uma consulta ao banco de dados onde reside o "data warehouse"/"data mart". 9. Aspectos da visualização das informações Queries Simples: São comandos SQL simples desenvolvidos pelo usuário fazendo o acesso diretamente ao 7/9

8 SGBDR e retornando as linhas acessadas em uma forma tabular. Este usuário deve possuir um perfil técnico avançado na criação de consultas SQL Stored Procedures (sp): Uma "stored procedure" fica armazenada no banco de dados relacional e o acesso é mais rápido. Recomenda se desenvolver "stored procedures" quando as consultas são prédefinidas pelo usuário. Ferramentas OLAP: As ferramentas OLAP de visualização dos dados transformam números enfadonhos em excitantes apresentações visuais e são ferramentas facilmente operadas pelo usuário final. Aplicativos de Consulta: Muitas vezes o usuário solicita "queries" pré definidas que podem ser armazenadas no banco de dados na forma de "stored procedures" ou gravadas de acordo com o tipo de ferramenta OLAP. A viabilidade de construir um aplicativo de consulta é diretamente relacionada às necessidades de informação do alto escalão da empresa (presidência, diretoria, gerências). Obviamente estes funcionários não irão desenvolver "queries" e sim desejam somente clicar em um ícone para obter a informação. Nestes casos, um aplicativo de consulta que integra as "queries" pré definidas deve ser implementado prevendo a integração de novas consultas que são executadas freqüentemente. Consultas esporádicas não se justificam implementar em um aplicativo pois o usuário pode desenvolvê las de acordo com sua necessidade. Depende da análise do usuário se quer ou não implementar determinada consulta em um aplicativo. CONSIDERAÇÕES FINAIS "Data warehouse" não é modismo, tornou se uma necessidade para a organização. "Data warehouse" não resolve os problemas da organização se não houver o fator humano para analisar os resultados e tomar as decisões. É fundamental o envolvimento do usuário em todo o processo (usuário que atua na análise de informações para a tomada de decisão). São poucos os usuários com este perfil. Evitar trabalhar em nível operacional (detalhe) e sim em nível estratégico (dados consolidados/agregados), a não ser que seja muito necessária a análise detalhada. A técnica mais adequada para a modelagem dimensional é a "star schema". Evitar utilizar a técnica "snow flake" visto que é uma técnica onde as dimensões são normalizadas, degradando a performance de acesso à tabela fatos. Utilizar a modelagem dimensional. A utilização do MER, somente para visualizar a área de negócio para, então, analisar como obter as informações fontes para o "data warehouse". O analista de Tecnologia da Informação deve possuir o conhecimento da tecnologia utilizada no projeto principalmente em: SGBD, Modelagem de Dados Tradicional e Multidimensional. A estação cliente deve ter alto desempenho. 8/9

9 As consultas demandam um alto consumo de recursos (tanto do servidor quanto da rede de comunicação de dados). A avaliação da necessidade de implantar tal sistema deve levar em conta: A necessidade da empresa de responder continuamente às mudanças de mercado. A existência ou não de uma base consistente de informações oriundas dos bancos de dados operacionais. A inviabilidade de obter as informações de suporte à decisão diretamente dos bancos de dados operacionais da empresa. À medida que a infra estrutura de informações das empresas amadurece, aumenta a necessidade de qualidade dos dados e de sistemas eficientes e eficazes de suporte à decisão. Esse tipo de sistema e o uso corporativo que se faz dele alavancam o conhecimento de negócio ou sua inteligência, resultando em vantagem competitiva. No cenário atual, onde os administradores das empresas precisam tomar decisões rápidas e certeiras em resposta aos diversos eventos que ocorrem a todo instante em suas empresas, faz se necessário construir todo um mecanismo de suporte rápido e eficiente aos processos decisórios. O "data warehouse" é uma ferramenta apropriada para este tipo se situação. Se bem projetado, permite aos gerentes obter informações rápidas e confiáveis que lhe servirão de suporte para a solução de seus problemas e para atingir os objetivos propostos para os negócios. OBS: Resumo da monografia apresentada à FAE para o curso de especialização Tecnologia da Informação e Comunicação. Ano Trabalho disponível na biblioteca da CELEPAR Companhia de Informática do Paraná Celepar Rua Mateus Leme 1561 Centro Cívico Curitiba PR /9