Arquitetura de componentes de dados em business intelligence

Do ponto de vista técnico, Kimbal e Ross (2013) focam o conceito na componente de data warehouse, referindo-se de forma alargada a todo o componente de dados informacionais, enquanto forma de organização da informação, caracterizado da seguinte forma:

• Está organizado por assuntos que correspondem a áreas de negócio da organização e devem ser considerados para modelação quer ao nível de modelos base de carregamento como ODS e DW, e especificamente ao nível de data marts;

• Deve ser integrado, independentemente da origem dos dados e seus formatos, deve-se utilizar o processo de ETL ou Data Replication, para transformar e consolidar os dados, para carregar de forma integrada e sem duplicações;

• Mantém dados não voláteis e com uma data de manutenção superior a cinco anos, pois por um lado os dados são carregados normalmente por períodos e não dependentes de transações online, e por outro lado, necessitam de perspetivas históricas de acordo com os temas, para detetar padrões, tendências e comparações.

68

Segundo Berkeley (2006), é necessário considerar componentes de arquitetura próprios destes sistemas, como é o caso de “data”, “application”, “technology” e “processes”, tal como apresentado na Figura 3.32. Na componente específica de “Data”, Berkeley (2006) considera que uma data warehouse integra igualmente uma visão de projeções futuras em termos de previsões e orçamentos, o que permite montar uma estratégia de acompanhamento e medição entre previsto e realizado, de acordo com o planeado, identificando e planeando as melhorias necessárias face às evidências detetadas.

Figura 3.32: Componentes arquiteturais de uma data warehouse (Berkeley, 2006)

Como tal, para Berkeley (2006), uma data warehouse e data mart incluem dados históricos e uma separação entre dados mensuráveis (factos) e contexto ou perspetivas de análise (dimensões). As dimensões podem ser utilizadas em vários factos ocorridos, sendo que o conjunto de dimensões partilhadas representam o nível de visão comum das várias áreas de negócio estruturadas nos factos analisados sob estas perspetivas. O conhecimento destas estruturas, envolve um modelo de metadados enquanto guia ou dicionário sobre estruturas e utilização dos dados em termos técnicos e de negócio.

Considerando os vários níveis de dados nestes sistemas, podemos sistematizar da seguinte forma a função de cada um em termos de utilização e forma de modelação:

• Operational Data Store e Data Staging: são áreas de dados temporárias, apesar de poderem manter-se durante períodos superiores a um mês, mas que têm como objetivo suportar os processos de ETL na agregação, transformação e limpeza de dados, antes do carregamento otimizado para a data warehouse e/ou data marts. São dados em bruto, obtidos do operacional, normalmente com modelação relacional se for em bases de dados, ou podem ser dados não estruturado ou mesmo ficheiros diversos;

• Data Warehouse: modelos de dados organizados por temas, de acordo com o objetivo e negócio da organização, para suportar processos de data mining, CPM, BAM e visualização através de ferramentas de navegação utilizando normalmente tecnologia OLAP (On-line Analytic Processing). Podem utilizar surrogate keys (chaves ou códigos gerados ao nível do DW para normalizar casos em que vários sistemas origem têm o mesmo código, mas com definições diferentes), modelação com SCD (Slowly Changing Dimenson), modelos em star Schema, snowflake schema ou totalmente relacional;

69

• Data Mart: modelo de dados organizado por assuntos normalmente associado a temas (e.g. rendibilidade, clientes, produtos, eficiência), dependente ou independente da data warehouse, com dados replicados, mas agregados de forma otimizada e com cálculos adicionais ao que existe na data warehouse, para acelerar a visualização, agregar conteúdos temáticos e facilitar a sua distribuição/acesso. É neste nível de dados que o conceito de métricas e dimensões de análise é mais utilizado. Utiliza normalmente modelação em star schema ou snowflake schema;

• Metadados: estrutura de dados que permitem identificar as fontes, manter informação sobre as transformações e identificar a relação entre origem e destino dos dados, suportando igualmente o processo de ETL e os modelos de visualização de dados. Permitem igualmente adicionar informação numa perspetiva de negócio, incluindo a explicação de fórmulas de cálculo, utilização de métricas e relatórios, ou inclusive a relação entre conceitos mapeados em campos de dados.

Na base dos modelos, as tabelas são normalmente definidas como sendo de Factos ou Dimensões segundo Kimbal e Ross (2013), o mesmo acontecendo para os campos das tabelas, mas sob o nome de métricas e dimensões. De acordo com Mohania et al. (1999), existe uma diferença entre métricas e dimensões:

• Métricas correspondem a dados normalmente numérico ou passível de ser factual (por exemplo contagens de registos com determinadas características) que representam a atividade da organização (e.g. quantidade de vendas, valor das vendas, quantidade de clientes, rendibilidade de produtos);

• Dimensões correspondem a perspetivas de análise das métricas, isto é, da atividade da organização (e.g. clientes, regiões, semestres, produto).

Estas métricas e dimensões, são organizadas em modelos específicos com tabelas que podem ser de factos ou de dimensões, estando organizadas num modelo em star schema ou snowflake schema, sendo a base do que é conhecido como bases de dados multidimensionais, segundo Chaudhuri et al. (2011) ou também bases de dados informacionais.

No caso de formato em Star, as tabelas de factos têm um conjunto de métricas, designadas medidas de análise utilizando-se uma chave primária composta por várias dimensões, que são igualmente chaves estrangeiras para as tabelas e dimensões recorrendo a Kimbal e Ross (2013), como apresentado na Figura 3.33. Nesta modelo considera-se sempre um grupo de uma tabela de factos e várias tabelas de dimensões, mas as tabelas de dimensões não têm relações entre si. As hierarquias de dimensões (e.g. tipo produto, produto, categoria, para o caso de “Product Dimension”) estão representados numa única tabela de dimensão de forma desnormalizada. Este modelo apresenta ganhos no desempenho, pois a query de exploração junta normalmente a tabela de factos com tabelas de dimensões necessárias, mas sem decomposição das dimensões em várias outras junções pois a hierarquia está toda representada numa única tabela.

70

Figura 3.33:Modelo multidimensional star schema (Kimbal e Ross, 2013)

No caso de formato em snowflake schema as tabelas de dimensões estão normalizadas de onde resulta a criação de hierarquias em dimensões, como apresentado na Figura 3.34 para o caso desagregado da dimensão “Product Dimension”. Desta forma, para se obter os mesmos dados que o modelo em Star, obriga a juntar mais tabela numa query, o que pode prejudicar o desempenho.

Figura 3.34: Modelo multidimensional em snowflake (Kimbal e Ross, 2013)

Por outro lado, ao nível de data warehouse e respetiva relação com data marts, existem metamodelos sectoriais desenvolvidos por fabricantes com modelos com os principais conceitos (tabelas, campos, relações), que podem ser implementados pelas organizações com os devidos ajustamentos face ao tipo de dados e modelo de negócio específico de cada organização, como é o caso do IBM Banking Data Warehouse Blueprint [IBM BDW] (2014) e Teradata Financial Services Data Model [TERADATA] (2014).