MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML - PDF
MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML
Download "MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML"
Pietra Olivares de Sá
1 1 MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML JOANA SCHEEREN Porto Alegre 2009
2 2 JOANA SCHEEREN MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML Trabalho de Conclusão de Curso II apresentado à Faculdade de Informática, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação. Orientador: Profa. Dra. Sílvia de Castro Bertagnolli Porto Alegre 2009
3 3 Dedico este trabalho aos meus pais, meus grandes mestres; ao meu marido Maiquel, pela compreensão, apoio e dedicação em todos os momentos e à minha mãe pelas lições de força e superação neste semestre.
4 Agradeço ao meu marido Maiquel pela paciência, auxílio e amizade nos momentos confusos; à professora Sílvia pelas grandes lições, pelo apoio e incentivo. A todos os amigos, colegas e familiares que me deram força e motivação para alcançar este objetivo. 4
5 5 RESUMO Os sistemas de Business Intelligence tornam-se muito importantes nas organizações em geral, uma vez que possibilitam analisar os históricos dos processos para criar subsídios de apoio à decisão. Os repositórios destes sistemas os Data Warehouses ou Data Marts são construídos de forma a atender a demanda destes sistemas e por isso possuem uma abordagem de modelagem específica. Este trabalho propõe o estudo dos diagramas da UML 2.0 a fim de adaptá-los para permitir uma documentação mais adequada para os projetos de Data Warehouses e Data Marts, já que as suas abordagens de modelagem atuais, não cobrem todos os elementos necessários do projeto. Palavras-Chave: Business Intelligence, UML 2.0, Data Warehouse, Data Mart.
6 6 ABSTRACT The Business Intelligence systems become very important in organizations, once it allows analyzing the historical processes to create benefits for decision support. The databases of these systems - the Data Warehouse or Data Marts - are constructed to attend the demands of these systems and therefore have a specific approach to modeling. This article, proposes the study of the diagrams of UML 2.0 in order to adapt them to allow a more adequate documentation for the projects of Data Warehouse and Data Marts, whereas its current modeling approaches do not cover all the necessary elements of the project. Keywords: Business Intelligence, UML 2.0, Data Warehouse, Data Mart.
7 7 LISTA DE FIGURAS Figura 1 Cubo com Dimensões...24 Figura 2 Modelo Star Schema...26 Figura 3 Identificando Fatos e Dimensões...27 Figura 4 Quatro Pontos Cardeais...27 Figura 5 Modelo Snow Flake...28 Figura 6 Diagramas da UML Figura 7 Modelo Fonte das Informações Visão Apólices...39 Figura 8 Modelo Fonte das Informações Visão Metas...39 Figura 9 Fato Venda com métricas e métricas calculadas...45 Figura 10 Dimensão Cia com atributos...46 Figura 11 Hierarquia de Clientes...48 Figura 12 Hierarquia de Datas...48 Figura 13 Regras de Negócio aplicadas a classe Cliente...50 Figura 14 Diagrama de Classes visão Venda...50 Figura 15 Diagrama de Seqüência de Carregar Cliente...54 Figura 16 Diagrama de Seqüência de Buscar Cliente...55 Figura 17 Diagrama de Implantação...58
8 8 LISTA DE QUADROS QUADRO 1 Comparativo entre dados Operacionais e Informacionais...19 QUADRO 2 Comparação entre Modelo Dimensional e Modelo ER...24 QUADRO 3 Comparativo entre perguntas aos usuários e elementos definidos para a modelagem...49
9 9 LISTA DE ABREVIATURAS E SIGLAS BI CASE DM DW ER ERP ETL HOLAP MOLAP OLAP OLTP OMG ROLAP SGBD SQL UML Business Intelligence Computer Aided Software Engineering Data Mart Data Warehouse Entidade Relacionamento Enterprise Resource Planning Extraction, Transform and Load Hybrid On-line analytical processing Multidimensional On-line analytical processing On-line analytical processing On-line Transaction Processing Object Management Group Relational On-line analytical processing Sistemas Gerenciadores de Banco de Dados Structured Query Language Unified Modeling Language
10 10 SUMÁRIO 1 INTRODUÇÃO REFERENCIAL TEÓRICO BUSINESS INTELLIGENCE Data Warehouse e Data Mart Modelagem Multidimensional Modelos de Dados Multidimensionais UML SOLUÇÃO IMPLEMENTADA PLANEJAMENTO LEVANTAMENTO DAS NECESSIDADES MODELAGEM DIMENSIONAL Primeira Etapa Definindo os fatos ou métricas Segunda Etapa Definindo as dimensões de negócio Terceira Etapa Definindo a granularidade das informações em cada dimensão Quarta Etapa Definindo a hierarquia de agrupamento de informações MODELANDO REGRAS DE NEGÓCIO PROJETO FÍSICO DO BANCO DE DADOS PROJETO DE ETL EXTRACT, TRANSFORM AND LOAD DESENVOLVIMENTO DE APLICAÇÕES VALIDAÇÃO E TESTE TREINAMENTO IMPLANTAÇÃO CONSIDERAÇÕES FINAIS REFERÊNCIAS BIBLIOGRÁFICAS...60
11 APÊNDICES
12 12 1 INTRODUÇÃO Com os avanços da tecnologia da informação, pode-se contar com recursos que possibilitam às empresas manter, processar e controlar enormes volumes de dados, representando todos os seus processos. A partir do banco de dados criado e alimentado, é possível extrair informações valiosas do cenário histórico e atual da empresa. É neste contexto que os sistemas de BI (Business Intelligence) ganham força, pois visam disponibilizar informação e conhecimento aplicados ao negócio das empresas, enquanto o foco dos ERP s (Enterprise Resource Planning) e demais sistemas OLTP (Online Transaction Processing) é buscar estabelecer subsídios de controle dos processos. O Data Warehouse (DW) ou armazém de dados propõe-se a lidar com grandes volumes de dados históricos (oriundos dos sistemas transacionais) e disponibilizar informações às consultas dos usuários, sejam elas ad-hoc ou não. Por sua vez, um Data Mart (DM) funciona como um repositório menor, com uma visão mais direcionada a algum assunto específico da empresa, mas também com a proposta de disponibilizar informações que possibilitem análises diversas para apoio à decisão. Desse modo, os DW e os DM de uma empresa devem ser construídos com muito planejamento, pois um projeto de implantação mal definido pode ser traumático em termos de custo, tempo e desempenho nas consultas executadas posteriormente. A escolha da arquitetura do projeto do Data Warehouse ou Data Mart pode ser considerada uma decisão prioritária, já que a modelagem deve refletir a forma de pensar dos analistas e atender aos requisitos de negócio da empresa. Para que o projeto do Data Warehouse ou Data Mart da empresa possa ser analisado pelos gestores e analistas envolvidos no projeto com eficácia, é
13 13 imprescindível que haja uma documentação completa e fidedigna da modelagem proposta para auxiliar tanto na aprovação e definição do escopo, como possibilitar o entendimento das visões e métricas entregues ao final. Atualmente, os modelos de dados, comumente utilizados para a modelagem de projetos de DW ou DM são os modelos Star Schema (Estrela) ou Snow Flake (Floco de Neve). Esses modelos, embora muito mais conceituais do que práticos, possuem uma orientação à representação dos processos que podem ser considerados para modelar/construir o armazém de dados e não apenas na composição física de seus componentes como propõe o modelo ER (Entidade-Relacionamento). Ambos os modelos são muito importantes na fase de concepção do projeto, pois derivam do levantamento das regras de negócio. Contudo, eles não se preocupam em documentar com detalhes os requisitos e as características do projeto, tampouco em atender as necessidades de compreensão de todos os envolvidos nele. Há diversas outras formas de modelar sistemas computacionais. Destacase que um dos padrões atuais de modelagem de software orientado a objetos é a UML (Unified Modeling Language), pois foi adotada internacionalmente pela indústria de Engenharia de Software. A UML é uma linguagem de modelagem visual, utilizada para auxiliar na definição das características e requisitos dos softwares, abrangendo todo o projeto. Criada para atender processos de desenvolvimento de software que utilizem o paradigma de orientação a objetos, esta linguagem possui muitos diagramas para que todos os passos do projeto possam ser descritos e facilmente entendidos por todos os envolvidos na construção - desde usuários até desenvolvedores. Como a UML é um dos padrões atuais de modelagem, tem-se no mercado uma diversidade de ferramentas CASE (Computer Aided Software Engineering) que podem ser utilizadas na criação dos modelos de dados requeridos. Além disso, a preocupação em descrever todas as fases do projeto, com uma visão dos processos de negócio, faz com que a UML seja uma abordagem de fácil compreensão por todos os envolvidos em um projeto de software.
14 14 Sendo assim, surge a idéia de estudar os requisitos para a construção de Data Warehouses e Data Marts, bem como os diagramas da UML 2.0 para propor a representação visual e a documentação destes, de modo que atendam ao requisito fundamental da fase de definição do projeto: o entendimento do modelo e definição do escopo requerido, auxiliando tanto usuários, como analistas a obter mais sucesso e eficácia no produto final, evitando distorções entre o que era esperado e o que efetivamente foi construído. A proposta inclui, portanto, o estudo dos diagramas da UML, que possam representar as fases de projetos de DW e DM, para que, em conjunto, construam uma documentação eficaz que possibilite a fácil identificação das decisões tomadas e das regras de negócio abrangidas pelo modelo. Desse modo, o objetivo geral deste trabalho é a seleção e/ou adaptação de diagramas da UML 2.0, que descrevam a fase de modelagem de dados de um projeto de Data Warehouse ou Data Mart, auxiliando em um melhor entendimento do escopo pelos envolvidos neste tipo de projeto. Como objetivos específicos para este trabalho propõem-se: adquirir conhecimentos que propiciem embasamento teórico na área de Data Warehouse e Data Mart; adquirir conhecimentos quanto aos requisitos da modelagem de um Data Warehouse ou Data Mart para entender como devem ser exemplificados através de documentos e/ou diagramas; entender e estudar os diagramas da UML 2.0; estudar e definir quais os diagramas da UML podem ser selecionados e/ou adaptados para os projetos utilizados com o escopo do trabalho, a fim de exemplificar de forma mais simples e visual os requisitos e a modelagem; elaborar um estudo de caso com os diagramas e documentos propostos a fim de exemplificar a sua aplicação.
15 15 O texto deste trabalho prossegue organizado da seguinte forma: Capítulo 2 apresenta o referencial teórico utilizado para estudar e entender os conceitos dos objetos de estudo do trabalho; Capítulo 3 apresenta a descrição da solução elaborada e aplicada em um estudo de caso; Capítulo 4 descreve as conclusões obtidas com o desenvolvimento deste trabalho. O texto continua com a descrição dos aspectos teóricos que fundamentaram o desenvolvimento deste trabalho.
16 16 2 REFERENCIAL TEÓRICO Durante muitos anos, o foco de estudos e das empresas esteve em aplicativos transacionais, como os ERPs (Enterprise Resource Planning), para obter elementos de controle e automação dos processos da empresa (MACHADO, 2006). Os SGBDs (Sistemas Gerenciadores de Banco de Dados) utilizados por estes aplicativos são os relacionais, que se preocupam com o armazenamento e recuperação de dados, exatamente o que se necessita para responder às necessidades de controle das transações. Este foco no gerenciamento dos dados garantiu a segurança, a eliminação das redundâncias e a integridade do banco de dados, porém a preocupação ainda é o controle dos processos e não apenas a recuperação dos dados controlados (MACHADO, 2006). Contudo, o cenário atual de dinamismo trouxe à tona a necessidade de se obter estratégias de negócio para adquirir vantagens competitivas frente aos concorrentes. Mais do que isso, as empresas estão sendo obrigadas a criar maneiras de se adaptar de uma forma contínua e rápida para que possam se manter e crescer no mercado. Para que estas necessidades sejam atendidas, a fim de incluir a empresa em um cenário vantajoso, é preciso que os gestores tenham informações para tomar as decisões certas no momento adequado, para analisar os dados disponíveis e formular estratégias de forma rápida e segura (COLAÇO JUNIOR, 2004). É neste contexto que se verifica a importância dos sistemas de BI (Business Intelligence) para as organizações, pois após a implantação dos sistemas transacionais e do controle de seus processos, observa-se a necessidade de sistemas que forneçam informações integradas e sumarizadas, que possam prover insumos para análise, planejamento e suporte à decisão (COLAÇO JUNIOR, 2004).
17 17 Assim como qualquer projeto de software, a documentação dos requisitos e a modelagem do sistema são muito importantes para uma melhor compreensão do escopo do projeto e de como ele será estruturado. Isto influencia o desenvolvimento eficaz e a manutenção após a entrega. A modelagem orientada a objetos auxilia, ainda, em uma melhor compreensão da arquitetura do sistema tanto dos analistas, como dos usuários envolvidos. Como a UML é considerada um dos padrões atuais neste tipo de modelagem, ela pode ser estudada para utilização nos projetos de BI (LARMAN, 2006). As próximas seções apresentam um resumo dos principais aspectos teóricos relacionados à BI e à UML que serão utilizados por este trabalho. 2.1 BUSINESS INTELLIGENCE Com o avanço das tecnologias de informação e com o amadurecimento dos sistemas dentro das empresas teve-se um aumento tanto na capacidade de armazenamento e processamento dos sistemas, como no tamanho das bases de dados com informações das diversas formas de interação da empresa com seu negócio (COLAÇO JUNIOR, 2004). Os ERP s não lidam de forma eficaz com grandes volumes históricos, pois o controle dos processos seria muito oneroso, levando-o a não atender seu propósito principal. Além disso, possuir grandes volumes de dados, mesmo que seja possível recuperá-los, não garante a continuidade dos negócios. Assim, surgem os armazéns de dados ou Data Warehouses, e os Data Marts, cujas bases de dados possuem informações consolidadas e integradas, capazes de apoiar os processos de tomada de decisões com conhecimento preciso e voltado ao negócio. Eles, também, possibilitam no nível tático da organização, a visualização do desempenho de um departamento e até mesmo de toda a corporação (MACHADO, 2006). Pode-se definir um sistema de BI como um conjunto de tecnologias orientadas à disponibilização da informação e do conhecimento estratégico para os processos de tomada de decisão em uma empresa (MACHADO, 2006). Para alcançar estes objetivos, o BI de uma empresa utiliza variadas
18 18 fontes de informação, de acordo com a definição das estratégias de negócio, para estar competitiva (BARBIERI, 2001). As técnicas de BI visam, portanto, extrair informações dos sistemas transacionais e armazená-las de forma eficiente para retirar o conhecimento requerido e manter grandes históricos, a fim de subsidiar verificações de cenários. Estas técnicas podem ser utilizadas para descobrir as necessidades de indicadores de negócio da empresa e para disponibilizar o conhecimento estratégico de forma dinâmica e precisa (MACHADO, 2006). Como já mencionado, os modelos relacionais de banco de dados não se mostram eficazes para o controle do volume e do formato de dados que requer um sistema de BI. Para isto, utilizam-se os DW e os DM, pois são capazes de armazenar e recuperar grandes volumes de dados, além de recuperá-los para prover análises no formato e agilidade que um sistema de BI requer (MACHADO, 2006). Para que os dados cheguem até o Data Warehouse ou ao Data Mart no formato que se planejou, há uma etapa muito importante dentro do projeto do BI: o processo de ETL Extraction, Transform and Load (extração, transformação e carga). Através dele, os dados são levados até uma área temporária que possui o objetivo de formatar e tornar consistentes estes dados no repositório final, conforme as necessidades ou o contexto (ANDRADE, 2003). A extração remete a busca dos dados para as fontes transacionais, onde os processos são controlados. A transformação é necessária para montar o modelo de dados que atende ao sistema, pois a normalização do modelo transacional não é eficaz nestes casos. Dentro da transformação, também é feita a limpeza dos dados que é responsável por isolar apenas as informações que são necessárias para as análises que estarão disponíveis no BI, de acordo com a definição da empresa no projeto, além de remover erros encontrados nos dados. Por fim, a carga realiza a gravação dos dados no repositório final, criando o histórico da empresa e os subsídios para o sistema de BI (ANDRADE, 2003). Ao contrário da abordagem tradicional de dados, o conceito de BI está relacionado com formas alternativas de tratamento das informações (BARBIERI, 2001). Por isso, há grandes diferenças entre os dados constituídos
19 19 para o controle de processos e os que subsidiam análises para a tomada de decisões. O Quadro 1 apresenta um comparativo entre os dados de natureza operacional e informacional. QUADRO 1 Comparativo entre dados Operacionais e Informacionais Características Dados Operacionais Dados Informacionais Conteúdo Valores Correntes Valores Sumarizados, Calculados, Organização dos dados Por aplicação/sistema de informação Integrados de várias fontes Por assunto/ Negócios Natureza dos dados Dinâmica Estática até o refreshment dos Formato das Estruturas Relacional, próprio para computação transacional dados Dimensional, simplificado, próprio para atividades analíticas Atualização dos dados Atualização campo a campo Acesso, sem update Uso Altamente estruturado, processamento repetitivo Desestruturado, com processamento analítico/heurístico Tempo de Resposta Otimizado para 2 a 3 segundos Análises mais complexas, com Fonte: (BARBIERI, 2001). tempos de respostas maiores Um sistema de BI precisa, portanto, de uma modelagem diferenciada que atenda seus requisitos de análises e consultas, embora um banco de dados ERP seja comumente confundido com um sistema de BI. Esta modelagem deverá subsidiar uma base que consiga integrar dados de múltiplas fontes de forma concisa e não-normalizada e organizá-los para um maior desempenho de suas consultas. Para formar estas bases, surgiu o conceito de Data Warehouse, que será descrito na próxima seção Data Warehouse e Data Mart O Data Warehouse, cuja tradução literal é armazém de dados, pode ser definido como uma base de dados preparada para ser acessada por sistemas de apoio à decisão (MACHADO, 2006).
20 20 Os dados são armazenados em estruturas dimensionais e em vários graus de relacionamento e sumarização de forma a possibilitar o processamento analítico por ferramentas especiais do tipo OLAP (On-Line Analytical Processing), que atendem aos executivos de diferentes níveis, responsáveis pelas decisões de negócios nas empresas (BARBIERI, 2001). O DW também compreende a base de dados histórica da empresa, que une de forma integrada e confiável as informações de interesse da mesma, permitindo verificar evoluções, em geral, em grande espaço de tempo (BARBIERI, 2001). Um Data Mart, também chamado Mercado de Dados, pode ser considerado uma especialização, uma espécie de Data Warehouse com um assunto-foco, que atende a áreas específicas da empresa, porém voltado da mesma forma para os processos decisórios gerenciais (BARBIERI, 2001). Ambos têm os mesmos objetivos finais, porém a abrangência de projeto muda devido à especialização do Data Mart. Pode-se também, afirmar que um Data Warehouse é formado pelos diversos Data Marts integrados. Como o DW é um banco voltado a consultas, não se pode projetá-lo pensando na consistência entre os dados carregados (BARBIERI, 2001). Por isto, a abordagem entidade-relacionamento não é eficaz neste tipo de projeto, já que ela se preocupa com a eliminação de redundâncias de dados e com a garantia da integridade destes, o que não é ponto focal de um DW. Nestes projetos utiliza-se mais a modelagem multidimensional (COLAÇO JUNIOR, 2004). Segundo Inmon (INMON, 1997), um Data Warehouse pode ser considerado um conjunto de dados não-volátil, orientado a tópicos, integrado e que varia com o passar do tempo servindo de suporte para o processo de tomada de decisões da gerência. Estas características permitem compreender sua formação: não-volátil remete ao fato de DW permitir, na maior parte dos casos, que os dados sejam apenas acessados e não alterados ou atualizados. Assim, ao contrário de um sistema transacional, cujo objetivo é a atualização registro a registro, um DW efetua uma carga inicial dos dados e os disponibiliza para consultas. As
21 21 alterações tornam-se mais onerosas do que uma remoção e recarga dos dados. Há, contudo, exceções como dados contábeis, por exemplo, que podem ter que sofrer atualizações ao longo do tempo. Mas são raros os casos, já que a base tem o objetivo de ser histórica e refletir todas as situações do negócio ao longo do tempo; orientado a tópicos (ou temas) indica que as informações que ele armazena e que são necessárias para processos de tomada de decisões, são organizadas segundo temas ou assuntos de negócio que são importantes para a empresa. Cada tema pode possuir várias tabelas e níveis de agregação como, por exemplo, as diversas informações que possam ser armazenadas dos clientes e as formas que podem ser detalhadas; integrado este aspecto remete à consolidação dos dados de diversas origens e possíveis codificações diferentes. Todos os dados de um Data Warehouse precisam estar na mesma convenção, perfeitamente integrados, para permitir todas as interligações possíveis; variante no tempo em um DW, os dados devem ser carregados, como fotografias, da base operacional no momento da carga para que incorpore as mudanças que permitirão análises das alterações ao longo do tempo. A área de retenção, ou Staging Area, é responsável pelo armazenamento intermediário entre as fontes de dados dos sistemas transacionais e o Data Warehouse ou Data Mart. Nesta área, ocorre a etapa de Transformação que, após a extração, é a etapa responsável por isolar os dados que serão utilizados no suporte à decisão, para então, executar a limpeza destes e criar o modelo dimensional (ANDRADE, 2003). A limpeza dos dados visa assegurar a consistência destes que serão armazenados, assim como ocorre na integração, para que haja padronização de descrições, codificações, além de formato de campos (ANDRADE, 2003). A construção do modelo dimensional é o agrupamento das informações em estruturas não-normalizadas na Staging Area para a posterior gravação no
22 22 modelo final. Estas estruturas atenderão às demandas de consultas complexas, que compreende o objetivo da estrutura dimensional de um sistema de BI (MACHADO, 2006). Com os dados consistentes, tratados na Staging Area, passa-se à etapa de carga, onde os dados, finalmente, são migrados para o Data Warehouse. Esta carga pode ser incremental (adiciona-se somente os dados novos) ou baseada nos dados, momento em que as dimensões são removidas completamente e recarregadas a cada execução. A escolha da forma de atualização é uma decisão do projeto e poderá variar conforme a tecnologia escolhida para o BI da empresa (ANDRADE, 2003). Todas estas peculiaridades de um Data Warehouse ou Data Mart fazem com que um modelo entidade-relacionamento (ER) não seja o mais recomendado. Por isso, em projetos de BI, deve-se estudar a modelagem dimensional, como apresenta a próxima seção Modelagem Multidimensional Segundo Colaço Junior (2004) a modelagem dimensional atende aos requisitos de sistemas categorizados como DW e DM: As informações contidas em um Data Warehouse possuem características específicas que as distinguem das informações existentes em projetos de banco de dados convencionais. Grandes volumes de dados, dados históricos e bases não normalizadas são algumas das peculiaridades que impedem a utilização das metodologias tradicionais de análise de sistemas. (COLAÇO JUNIOR, 2004, IV) A modelagem multidimensional ou dimensional é uma técnica estruturada que foi desenvolvida para a obtenção dos modelos de dados necessários a projetos de Business Intelligence onde se pretende identificar, de forma fácil, os aspectos de negócio da empresa (BARBIERI, 2001). Segundo Barbieri (2001), a estrutura dimensional modifica a ordem de distribuição de campos por entre as tabelas, permitindo uma formatação estrutural mais voltada para os muitos pontos de entradas específicos (as
23 23 chamadas dimensões) e menos, para os dados granulares em si (os chamados fatos). Esta estrutura baseada em múltiplas dimensões permite a visualização dos dados de diversas maneiras (KIMBALL, 1998). O modelo multidimensional é formado por três elementos básicos: fatos, dimensões e medidas (MACHADO, 2006): um fato é modelado através de uma tabela que compreende as coleções de transações ou eventos de negócio da empresa. Tais coleções são compostas pelas medições numéricas que representam a evolução dos negócios de uma organização; as dimensões são os elementos dos fatos do negócio, são os assuntos, os atributos classificatórios dos elementos de um fato. Cada dimensão pode ter vários níveis hierárquicos para agregar os dados nos níveis necessários e propiciar um melhor entendimento e visualização dos indicadores; as medidas ou variáveis são os atributos numéricos que representam os fatos, ou seja, os indicadores que mostram a evolução do negócio da empresa. O modelo dimensional é mais leve que o modelo relacional, pois facilmente possibilita identificar seus componentes. Contudo, à medida que se adicionam novas extensões, ele pode se tornar mais complexo (BARBIERI, 2001). As técnicas da modelagem dimensional foram criadas para modificar alguns conceitos dos projetos tradicionais de banco de dados, como o modelo ER. Os projetos de BI precisam de estruturas mais ágeis do que as definidas pelo modelo normalizado e em níveis agregados, precisando também transgredir a premissa da não-redundância do relacional, mesmo que para chegar a tudo isso haja um considerável aumento no custo de armazenamento.
24 A Quadro 2 apresenta uma comparação entre o modelo entidaderelacionamento e o modelo dimensional. 24 QUADRO 2 Comparação entre Modelo Dimensional e Modelo ER Modelo Dimensional Modelo Relacional - ER Padrão de estrutra mais fácil e intuitiva Modelo mais complexo Anterior ao ER, anos 60 Ênfase nos bancos de dados relacionais, anos 70 Tabelas Fato e tabelas dimensão Tabelas Fato são o núcleo normalizadas Modelo mais facilmente joined Leitura mais fácil do modelo por usuários não especializados Fonte: BARBIERI, 2001 Tabelas que representam Dados e Relacionamentos Todas as tabelas são comumente normalizadas Maior dificuldade de join, por ter um número maior de tabelas Maior dificuldade de leitura pelo usuário não especializado. A forma mais comum de visualizar um modelo multidimensional é um desenho de um cubo. O cubo é somente uma metáfora, já que não há como expressar nele todas as dimensões de visualização, apenas três. Porém, este elemento visual auxilia muito no entendimento das múltiplas dimensões, visões de um mesmo fato (MACHADO, 2006). A Figura 1 ilustra um cubo voltado para a realidade do setor de Vendas (Fato de Vendas), o qual é composto por três dimensões: tempo, produto e cliente e a representação de uma métrica da tabela fato. Figura 1 Cubo com Dimensões Fonte: Adaptado de BARBIERI, 2001
25 25 Para explorar os dados de um DW utiliza-se a abordagem OLAP (Online Analytical Processing) que possui um conjunto de operações que possibilitam análises do comportamento dos indicadores de negócio permitindo a descoberta de cenários e tendências da organização (MACHADO, 2006). As ferramentas OLAP são aplicações que possibilitam aos usuários extrair as informações de apoio à decisão de forma dinâmica e flexível. Isto se torna possível, pois as ferramentas implementam operações como slice and dice e drill que efetuam a análise dimensional dos dados. Pode-se considerar que, hoje, há três formas de implementação das aplicações OLAP (COLAÇO JUNIOR, 2004): ROLAP (Relational On-line Analytical Processing) utiliza um repositório relacional para guardar os dados e a aplicação OLAP para gerenciar as consultas SQL (Structured Query Language) definidas pelos usuários; MOLAP (Multidimensional On-line Analytical Processing) utiliza, como repositório dos dados, um SGBD (Sistema Gerenciador de Banco de Dados) que suporta uma visão multidimensional dos dados; HOLAP (Hybrid On-line Analytical Processing) é uma variação das duas abordagens anteriores. Uma vez que esta se utiliza tanto de repositório relacional (para grandes volumes de dados), como de estruturas multidimensionais (por exemplo, cubos) para consultas que necessitem maior agilidade na análise das informações. No modelo relacional, tem-se o Diagrama Entidade e Relacionamento (DER) para representar graficamente as estruturas, operadores e regras que definem os dados de um projeto de banco de dados. Para os projetos de BI de construção de Data Warehouses, também é necessário o uso de elementos textuais e gráficos que dêem suporte à modelagem a ser definida. Esta modelagem precisa atender a todos os conceitos da modelagem dimensional, utilizada neste tipo de abordagem.
26 Modelos de Dados Multidimensionais Os princípios básicos de um modelo ER são identificar os itens relevantes e geradores de informação para os processos do sistema, as transações e os objetivos; identificar as entradas e saídas; bem como as regras de negócio que restringem a criação dos dados (COLAÇO JUNIOR, 2004). Quando se trata de projetos cuja finalidade é gerar consultas complexas que atendam às necessidades de negócio, deve-se quebrar o paradigma de eliminação de redundâncias em um modelo de dados (a normalização) e buscar o armazenamento histórico dos dados (COLAÇO JUNIOR, 2004). Dentro da modelagem multidimensional, tem-se duas abordagens principais: o modelo Star Schema e o modelo Snow Flake (MACHADO, 2006). O modelo Star Schema (estrela) é a abordagem, proposta por Ralph Kimball (1998), que visa criar um modelo mais simples e incremental. Esse modelo propõe o desenvolvimento de projetos de Data Marts menores e independentes que, posteriormente, podem ser integrados. Esses Data Marts possuem um assunto específico, um foco de negócio da empresa. Assim, o modelo transforma os dados em fatos e dimensões. Portanto, o assunto principal fica ao centro do modelo e suas características, as dimensões, ficam posicionadas ao seu redor, criando, assim, um modelo que lembra uma estrela, conforme ilustra a Figura 2. Figura 2 Modelo Star Schema Fonte: Adaptado de MACHADO, 2006
Aplicando Técnicas de Business Intelligence sobre dados de desempenho Acadêmico: Um estudo de caso
Aplicando Técnicas de Business Intelligence sobre dados de desempenho Acadêmico: Um estudo de caso Ana Magela Rodriguez Almeida 1, Sandro da Silva Camargo 1 1 Curso Engenharia de Computação Universidade
Faculdade INED Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional II Prof.: Fernando Hadad Zaidan 1 Unidade 4.3 2 1 BI BUSINESS INTELLIGENCE BI CARLOS BARBIERI
Bloco Administrativo BI Business Intelligence Objetivo O objetivo deste artigo é dar uma visão geral sobre o Módulo Business Intelligence, que se encontra no Bloco Administrativo. Todas informações aqui
DESMISTIFICANDO O CONCEITO DE ETL
DESMISTIFICANDO O CONCEITO DE ETL Fábio Silva Gomes da Gama e Abreu- FSMA Resumo Este artigo aborda os conceitos de ETL (Extract, Transform and Load ou Extração, Transformação e Carga) com o objetivo de
Oracle Hyperion Essbase Guia Claudio Bonel Oracle Hyperion Essbase Guia Dedicatória Este Livro é dedicado a minha família. 2 Guia Oracle Hyperion Essbase Sumário Agradecimentos Introdução Capítulo 1: OLAP
BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING http://www.uniriotec.br/~tanaka/tin0036 tanaka@uniriotec.br Introdução a Data Warehousing e OLAP Introdução a Data Warehouse e Modelagem Dimensional Visão