MODELAGEM GRÁFICA DE DATA
WAREHOUSES E DATA MARTS USANDO UML
JOANA SCHEEREN
Porto Alegre 2009
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
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.
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.
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.
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.
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 2.0 ...30
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
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
LISTA DE ABREVIATURAS E SIGLAS
BI Business Intelligence
CASE Computer Aided Software Engineering
DM Data Mart
DW Data Warehouse
ER Entidade Relacionamento ERP Enterprise Resource Planning
ETL Extraction, Transform and Load
HOLAP Hybrid On-line analytical processing
MOLAP Multidimensional On-line analytical processing
OLAP On-line analytical processing
OLTP On-line Transaction Processing
OMG Object Management Group
ROLAP Relational On-line analytical processing
SGBD Sistemas Gerenciadores de Banco de Dados SQL Structured Query Language
SUMÁRIO
1 INTRODUÇÃO ...12
2 REFERENCIAL TEÓRICO ...16
2.1 BUSINESS INTELLIGENCE ...17
2.1.1 Data Warehouse e Data Mart ...19
2.1.2 Modelagem Multidimensional...22
2.1.3 Modelos de Dados Multidimensionais...26
2.2 UML...29
3 SOLUÇÃO IMPLEMENTADA ...34
3.1 PLANEJAMENTO ...36
3.2 LEVANTAMENTO DAS NECESSIDADES...37
3.3 MODELAGEM DIMENSIONAL ...42
3.3.1 Primeira Etapa – Definindo os fatos ou métricas ...44
3.3.2 Segunda Etapa – Definindo as dimensões de negócio...45
3.3.3 Terceira Etapa – Definindo a granularidade das informações em cada dimensão ...47
3.3.4 Quarta Etapa – Definindo a hierarquia de agrupamento de informações ...47
3.4 MODELANDO REGRAS DE NEGÓCIO ...49
3.5 PROJETO FÍSICO DO BANCO DE DADOS...51
3.6 PROJETO DE ETL – EXTRACT, TRANSFORM AND LOAD ...52
3.7 DESENVOLVIMENTO DE APLICAÇÕES...56 3.8 VALIDAÇÃO E TESTE ...56 3.9 TREINAMENTO ...56 3.10 IMPLANTAÇÃO...57 4 CONSIDERAÇÕES FINAIS ...59 5 REFERÊNCIAS BIBLIOGRÁFICAS ...60
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, é
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. Destaca-se 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.
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.
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.
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).
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
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
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,
Integrados de várias fontes
Organização dos dados Por aplicação/sistema de
informação
Por assunto/ Negócios
Natureza dos dados Dinâmica Estática até o “refreshment” dos
dados
Formato das Estruturas Relacional, próprio para
computação transacional
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
tempos de respostas maiores Fonte: (BARBIERI, 2001).
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.
2.1.1 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).
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
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
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.
2.1.2 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
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.
A Quadro 2 apresenta uma comparação entre o modelo entidade-relacionamento e o modelo dimensional.
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 que representam Dados e
Relacionamentos
Tabelas Fato são o núcleo – normalizadas Todas as tabelas são comumente normalizadas Modelo mais facilmente “joined” Maior dificuldade de “join”, por ter um número
maior de tabelas Leitura mais fácil do modelo por usuários não
especializados
Maior dificuldade de leitura pelo usuário não especializado.
Fonte: BARBIERI, 2001
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
Para explorar os dados de um DW utiliza-se a abordagem OLAP
(On-line 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.
2.1.3 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
Os relacionamentos entre a tabela central, a tabela Fato, e as dimensões são ligações simples, geralmente, um relacionamento de um-para-muitos. Observa-se que, no modelo Star Schema, não se aplica a terceira forma normal às dimensões. Estas dimensões possuirão toda a hierarquia de dados, pois isso facilitará a realização de consultas posteriores.
Um modo de entender, de forma exemplificada, a diferença entre os fatos e as dimensões, e seu arranjo gráfico, é utilizar quatro pontos cardeais que podem auxiliar a descobrir as informações de dimensão que estarão dispostas ao redor da ocorrência – o fato.
O fato é a ocorrência, o acontecimento a ser modelado. Por exemplo, em uma abstração da venda do dia “x” de produtos por uma empresa a um cliente “y”, tem-se a VENDA como o fato do modelo.
Os quatro pontos de referência são: “O que?”, “Quando?”, “Quem?” e “Onde?” (MACHADO, 2006). Assim, ao analisar o fato, é necessário verificar quando ele ocorreu, onde se passou, quem é o personagem principal e o que é seu objeto. Verificando através do exemplo, têm-se as perguntas e respostas esquematizadas pela Figura 3.
O que? Produto Quando? Dia “x” Quem? Cliente “y” Onde? Empresa
Figura 3 – Identificando Fatos e Dimensões
Fonte: MACHADO, 2006
Neste caso, este modelo ficaria esquematizado conforme ilustra a Figura 4.
Figura 4 – Quatro Pontos Cardeais
É importante frisar que nem todos os modelos terão os quatro pontos de referência podendo, ainda ter mais elementos a serem considerados. Contudo, esta é uma abstração muito eficiente, já que atende a grande maioria dos projetos e dos modelos.
O modelo Snow Flake (floco de neve) é uma variação do modelo estrela. Esse possui a mesma abordagem de colocar o fato ao centro e as dimensões ao seu redor. Contudo, sua abordagem separa as hierarquias das dimensões em tabelas diferentes, variantes da dimensão principal (MACHADO, 2006).
Este modelo é resultado da terceira forma normal nas dimensões, evitando a redundância de valores textuais em uma tabela e deixando mais visível as hierarquias (MACHADO, 2006).
Porém, esta abordagem pode deixar o modelo bastante poluído à medida que aumentam as dimensões presentes no projeto. Com isso, ao invés de facilitar a visualização dos dados, há uma dificuldade de identificar as dimensões principais e as hierarquias variantes delas (MACHADO, 2006).
Pode-se notar a diferença entre os modelos analisando o esquema da Figura 5.
Figura 5 – Modelo Snow Flake
Fonte: Adaptado de MACHADO, 2006.
Além dos conceitos relacionados a BI foi necessário fazer uma análise da UML, visto que se pretende identificar possíveis adaptações nesta notação para a modelagem de sistemas de DW.
2.2 UML
A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é uma notação gráfica criada para modelar sistemas com o paradigma de orientação a objetos.
Destaca-se que esta não é uma linguagem de programação, mas uma linguagem de modelagem que se tornou um padrão nos últimos anos por ser adotada internacionalmente em projetos de software (GUEDES, 2007).
Assim que a primeira versão da UML foi lançada, em 1996, diversas empresas passaram a utilizá-la até ter sido adotada pela OMG (Object
Management Group) como um padrão de modelagem.
Esta metodologia é baseada em vários diagramas que permitem modelar o sistema sob diversos aspectos. Com isto, um diagrama complementa o outro e a possibilidade de incorrer em falhas, na fase de desenvolvimento, é muito reduzida, já que ao longo da análise pode-se verificar erros ou alterações a serem feitas nos diagramas anteriores (GUEDES, 2007).
Com a UML é possível modelar um software, em diferentes níveis de abstração, através de diferentes pontos de vista, fazendo com que se tenha uma identificação e seleção de alternativas mais adequadas ao sistema a ser modelado, levando-o a um resultado de melhor qualidade (SILVA, 2007).
A versão 2.0 da UML agregou diagramas e propôs melhorias para preencher lacunas que as versões anteriores apresentavam, fazendo com que ela seja mais eficaz e completa para a modelagem de projetos de software (SILVA, 2007).
A UML 2.0 é composta de treze diagramas, classificados em duas categorias: os diagramas estruturais e os diagramas comportamentais (SILVA, 2007). Os diagramas são desenhados para permitir uma visualização total do sistema, sob diferentes perspectivas (BOOCH et. al, 2005). Os primeiros tratam da parte estrutural tanto do sistema, como das classes. Já os últimos visam especificar os aspectos do sistema quando em execução (GUEDES, 2007).
A Figura 6 ilustra as classificações adotadas pelos diagramas da UML, considerando a versão 2.0.
Figura 6 – Diagramas da UML 2.0
Fonte: GUEDES, 2007
Após o estudo dos treze diagramas foram identificados como passíveis de subsidiar a documentação de algumas das etapas do projeto de sistemas de BI os seguintes diagramas: Diagrama de Casos de Uso, Diagrama de Classes, Diagrama de Seqüencias, Diagrama de Implantação e Diagrama de Pacotes.
Um resumo de cada um dos diagramas utilizados neste trabalho é apresentado no próximo capítulo, durante a sua utilização.
Os demais diagramas foram excluídos da solução proposta por (i) não agregarem novas informações ao projeto, e seu uso só faria o processo ser mais burocrático; (ii) terem objetivos que não são aderentes a modelagem de
Data Warehouses ou Data Marts, onde não há interação com usuários no
sistema para o cadastro e controle de informações. Assim, este trabalho tentou tornar o processo, de modelagem de DWs, mais documentado e menos burocrático, com o intuito de tornar a documentação eficaz através do uso de diagramas.
Desta forma, os diagramas da UML 2.0 não utilizados neste trabalho foram: Diagrama de Objetos, Diagrama de Estrutura Composta, Diagrama de Comunicação, Diagrama de Máquina de Estados, Diagrama de Atividades, Diagrama de Interação Geral, Diagrama de Componentes e Diagrama de Tempo. Algumas considerações sobre cada um deles pode ser verificada nos parágrafos que seguem,
O diagrama de objetos pode ser definido como uma variação do diagrama de classes, porém com o objetivo de fornecer uma “visão” dos
valores armazenados pelos objetos das classes em determinado momento da execução do sistema (GUEDES, 2007). Como em projetos convencionais, em projetos de BI este diagrama não acrescentará nenhuma informação nova, apenas demonstrará exemplos dos dados que os objetos armazenarão. Assim, ele pode ser usado em projetos de DW ou DM quando for necessário para uma exemplificação das informações do projeto, porém não como um componente crítico para a modelagem do sistema.
O diagrama de estrutura composta é um dos três novos diagramas propostos pela UML 2.0, sendo um dos diagramas estruturais da linguagem. Ele é voltado a um detalhamento da interligação entre os elementos em tempo de execução, por estes estarem envolvidos em prol de um objetivo ou tarefa em comum (SILVA, 2007). Por ser um complemento da modelagem estrutural, ele não é obrigatório em projetos de sistemas orientados a objetos e também não nos projetos de BI propostos neste trabalho. Este diagrama pode ser utilizado quando uma interação precisa ser claramente documentada.
O diagrama de comunicação (até a versão 1.5 da UML) era conhecido como diagrama de colaboração, tendo seu nome alterado por ser um complemento do diagrama de seqüências e determinar as conexões entre os objetos. Ele demonstra praticamente as mesmas informações do diagrama de seqüência, contudo sem se preocupar com a temporalidade (GUEDES, 2007). O diagrama de comunicação não é um diagrama essencial no projeto, podendo servir de apoio quando existirem etapas mais complexas do diagrama de seqüências que necessitem de uma documentação mais completa para descrever as regras de negócio que contém. No entanto, verificou-se que, para modelagens de projetos de Data Warehouse ou Data Marts, os diagramas de comunicação não agregariam mais informações além daquelas já modeladas pelo diagrama de seqüências que abordarão as fases do processo de ETL.
O diagrama de máquina de estados é utilizado para modelar os diferentes “comportamentos” ou situações que um objeto pode assumir ao longo do processo. Este diagrama pode representar os diversos estados de um objeto ou os comportamentos do sistema inteiro (GUEDES, 2007). Em uma modelagem de Data Warehouse ou de Data Mart, acredita-se que ele não será útil. Uma vez que não há troca de estados de um objeto durante o processo de carga e a informação não pode ser uma durante a carga e outra ao inseri-la no
repositório. Na verdade, o repositório conterá a última posição do sistema transacional.
O diagrama de atividades foi considerado um caso especial dentro da UML por estar ligado ao diagrama de estados (hoje denominado de diagrama de máquina de estados). A partir da versão 2.0 da UML, ele passou a ser considerado um diagrama independente e voltado a descrever as atividades ou os passos a serem executados durante o processo. Ele dá ênfase ao nível de algoritmo e provavelmente é um dos diagramas com mais detalhes da UML (GUEDES, 2007). Assim como o diagrama de máquina de estados, o diagrama de atividades descreve ações a serem realizadas ao longo de um processo. Como em uma carga de dados para um Data Warehouse ou um Data Mart, os dados lidos já devem estar “prontos”, pois não há atividades transacionais após esta carga, o diagrama de atividades pode ser dispensado.
O diagrama de interação geral é uma variação do diagrama de atividades. Contudo, esse não se preocupa com a modelagem de cada ação das atividades, mas, sim, com as interações modeladas em outros diagramas, pois seu objetivo é fornecer uma visão geral do controle de fluxo. Como o diagrama é uma especialização do diagrama de atividades, criado para representar o fluxo dos casos de uso, ele não será um diagrama essencial para projetos de BI.
O diagrama de componentes é um diagrama estrutural que visa identificar os componentes que fazem parte do sistema modelado. Estes componentes podem ser representações de componentes lógicos (de processos ou de negócios), bem como de componentes físicos como arquivos de código-fonte, bibliotecas, arquivos de ajuda etc. (GUEDES, 2007). Para projetos de sistemas de BI, o uso deste diagrama não apresenta a mesma eficácia, uma vez que estes sistemas não possuem etapas de processamento. Um sistema de BI busca os dados finais do sistema transacional, não necessitando executar etapas mais complexas para obter os dados, e conseqüentemente, não haverá muitos componentes para documentar.
O diagrama de tempo enfoca o mesmo escopo que o diagrama de máquina de estados – as alterações de estado de um objeto. Contudo, o de tempo utiliza o fator tempo para esta representação. Ou seja, ele modela as alterações de estado já descritas na máquina de estados, porém ao longo do
tempo (GUEDES, 2007). Assim como o diagrama de máquina de estados, o diagrama de tempo não terá utilidade em projetos de DW ou DM, pois não há alteração de estados nos componentes ou destes ligados ao fator tempo. Os dados são lidos do sistema sem que sejam necessárias transações posteriores nos objetos.
Ao concluir esta fundamentação teórica, passou-se para o estudo e validação da solução, como descreve a próxima seção.
4 CONSIDERAÇÕES FINAIS
A busca por uma forma de documentar de modo claro, visual e eficiente projetos de Business Inteligence (BI) foi motivada pela experiência da autora do trabalho (no papel de analista de sistemas) em suporte, manutenção e controle desse tipo de sistema. Os modelos Star Schema e Snow Flake, por si só, não identificam por que os modelos foram desenhados ou como estão implementados, deixando lacunas importantes para as futuras manutenções que a empresa possa necessitar no sistema.
Com a conclusão do presente trabalho e através da validação da solução proposta com um estudo de caso real, verificou-se que a proposta de utilizá-los para a documentação gráfica de projetos de BI, foco deste trabalho, é realmente possível e pode trazer inúmeras vantagens aos envolvidos com o projeto.
A utilização dos estereótipos facilitou atingir o objetivo do trabalho, uma vez que proporcionou a aderência dos diagramas na realidade dos projetos foco deste trabalho. Pode-se considerar que o estudo da UML, das aplicações e das possíveis extensões com os estereótipos tenham sido a etapa mais difícil para o desenvolvimento desta monografia, visto que os conceitos do modelo de dados, dos requisitos de projetos e dos conceitos de BI já eram conhecidos na prática.
Como trabalhos futuros pretende-se implementar toda a modelagem criada para a validação do presente trabalho, já que a empresa pretende utilizar o sistema de BI para suas análises e tomada de decisões. Outra possibilidade de continuação deste trabalho poderia ser a adaptação de alguma ferramenta para a criação de diagramas, a fim de prever os estereótipos criados e, assim, facilitar a documentação de projetos de BI.
5 REFERÊNCIAS BIBLIOGRÁFICAS
ANDRADE, Fábio Bahia. Conceitos de Staging Area aplicados a Data
Warehouses. CienteFico, Salvador, ano III, v II, 2003.
BARBIERI, Carlos. BI: Business Inteligence. Rio de Janeiro: Axcel Books, 2001.
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usuário. 8. ed. Rio de Janeiro: Campus, 2005.
GUEDES, Gilleanes T.A. UML 2: Guia Prático. São Paulo: Novatec Editora, 2007.
INMON, W. H. Como construir o Data Warehouse. Rio de Janeiro: Campus, 1997.
ITALIANO, Isabel C.; ESTEVES, Luiz A. Modelagem de Data Warehouses e Data Marts – Parte 1. SQL Magazine, Rio de Janeiro, n. 13, p. 42-45, 2004.
COLAÇO JUNIOR, Methanias. Projetando Sistemas de Apoio à Decisão
Baseados em Data Warehouse. Rio de Janeiro: Axcel Books, 2004.
KIMBALL, Ralf. Data Warehouse Toolkit. São Paulo: Makron Books, 1998.
LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos. Porto Alegre: Bookman, 2006.
MACHADO, Felipe Nery Rodrigues. Tecnologia e Projeto de Data
Warehouse: Uma visão multidimensional. Tatuapé: Érica, 2006.
SILVA, Ricardo Pereira. UML 2: Modelagem Orientada a Objetos. Florianópolis: Visual Books, 2007.
