Modelagem Dimensional

Com o crescimento da quantidade de dados no setor de informação, fez-se necessário o desenvolvimento de modelos para gerenciar o acesso e a disposição desses dados, sendo o modelo relacional e o modelo dimensional predominantes na indústria. Estes modelos diferenciam-se principalmente na estrutura lógica do esquema para representar cada um, sendo ambos alicerçados no modelo de relações entre entidades de dados, no entanto o dimensional acaba sendo mais direcional e restritivo (Breslin 2004, Jukic 2006). Como citado na seção de Business Intelligence, o objetivo principal é auxiliar na tomada de decisões dentro de uma companhia, sendo necessário dados e correlações específicas, assim a organização de dados nas ferramentas que compõem uma arquitetura de BI como o Data Warehouse e o OLAP são baseadas em um modelo de dados multidimensionais, pois permite um esquema orientado ao domínio e conciso que facilite a análise online (Park et al. 2013).

2.2.3.1 Metodologias Para o Desenvolvimentos de um DW

As principais metodologias no desenvolvimento de esquema de dados multidimensio- nais são a de Chaudhuri et al. (2005) e de Kimball e Ross (2011) (Rodriguez e Razo 2016). Chaudhuri et al. (2005) segue uma metodologia top-down, com enfoque principal no conhecimento do profissional de TI sobre o negócio e as definições dos processos pre- viamente definidas na instituição (Cavalheiro e Carreira 2016), dessa maneira, conta com uma intervenção pequena do usuário final na definição do modelo (Breslin 2004, Chaudhuri et al. 2005). A outra metodologia predominante no setor, bottom-up, é co- nhecida como ciclo de vida de Kimball e Ross (2011). Nessa, a construção do Data

Warehouse segue um processo incremental, a partir do desenvolvimento de Data Marts

independentes (Breslin 2004, Cavalheiro e Carreira 2016). O processo é dividido em quatro etapas:

• Selecionar o Processo de Negócio: Levantamento dos requisitos da organização e fontes de dados existentes para análise;

• Selecionar a Granularidade: Definir a medida da granularidade dos dados pre- sentes na tabela de fatos da organização;

• Escolher as Dimensões: Determinar o conjunto de atributos que descrevem as medidas da tabela de fatos. Normalmente, as tabelas de dimensões respondem às questões “Quem?”, “Quando?”, “O que?”, ”Onde?” e “Como?”;

• Identificar os Fatos: Definir quais medidas incluir na tabela de fatos, sendo estas compatíveis com a granularidade definida;

2.2.3.2 Tipos de Esquemas

Dentre os esquemas multidimensionais notórios utilizados na construção de Data Wa-

rehouse destacam-se Plano, floco de neve e estrela. O esquema Plano (Figura 2.7(a)

visa estruturar o modelo de dados da forma mais enxuta possível sem perder informa- ções, aglutinando todas as entidades de dados em entidades mínimas, contemplando mais informação em poucas tabelas. O esquema floco de neve (Figura 2.7(b) mantém os con- ceitos de fatos e dimensões para a organização das tabelas, no entanto, dividindo todas as hierarquias das dimensões em tabelas individuais. A partir disso, Kimball argumenta que floco de neve é indesejado, porque adiciona complexidade ao modelo de consultas e aumenta o número de operações de “join” necessárias (Moody e Kortink 2000).

Figura 2.7: Esquema plano e floco de neve.

Fonte: Malinowski e Zimányi (2004)

O esquema Estrela permite a exploração de dados multidimensionais de forma rápida e flexível (Garani e Helmer 2012, Mansmann et al. 2014), sendo este predominante na concepção de modelo de dados para Data Warehouse (Usman et al. 2013). O esquema foi desenvolvido por Kimball tendo como a principal característica a desnormalização das tabelas de dimensões, além de sua estrutura propiciar mais acessibilidade aos usuários na formulação das consultas. As otimizações do esquema estrela também são consideráveis dentro das estruturas de banco de dados relacionais pois reduzem o número de índices, o número de operações de “join” ao realizar consultas complexas, promovendo agregações mais rápidas (Aziz et al. 2015, Kimball e Ross 2011).

2.2.3.3 Tabela de Fatos

A tabela de fatos contém os dados numéricos que podem ser sumarizados para pro- duzir informações sobre o histórico de operações da companhia. Cada tabela de fatos também inclui como índices as chaves estrangeiras para as tabelas de dimensões relacio- nadas que contém os atributos para as tabelas de fatos (Singh 2013).

2.2.3.4 Tipos de Métrica

Os tipos de fatos são classificados a partir da quantidade de relacionamentos que estes mantêm com suas respectivas dimensões. Quando uma métrica pode ser sumarizada ou relacionada com todas as dimensões e hierarquias desta, este fato é chamado de aditivo. Outro tipo de fato é o semi-aditivo, nesta os dados podem ser relacionados com algumas dimensões dentro de uma hierarquia, mas não se relaciona com todas como os aditivos. O último tipo de fato é o não-aditivo, este não pode ser agrupado dentre as dimensões existentes, representando um número ou medida sem dimensões. (Kimball e Ross 2011, Golfarelli et al. 1998).

2.2.3.5 Tabela de Dimensão

As tabelas de dimensões referem-se à informações que dão contexto a tabela de fatos, podendo ser definidas como características que fornecem perspectivas adicionais a um determinado fato (Garani e Helmer 2012, Mansmann et al. 2014).

Todas as tabelas de dimensões possuem um atributo de chave primária (PK) de auto numeração denominada como Surrogate Keys. As tabelas de dimensões normalmente são tabelas desnormalizadas com muitos atributos de texto e baixa cardinalidade (Kimball e Ross 2011). Os atributos da tabela de dimensão são o principal alvo de restrições e especificações de agrupamentos de consultas em aplicações de BI. Os rótulos descritos nos relatórios geralmente são valores de domínio do atributo de dimensão.

Dentro de uma organização, as tabelas dimensionais são comumente divididas em hierarquias para representar melhor os diferentes níveis das características. Para definir os diferentes níveis de hierarquia de atributos utilizados nas dimensões de um esquema multidimensional, é aplicado o conceito de granularidade (Malinowski e Zimányi 2004, Combi et al. 2004).

Dimensões hierárquicas normalmente englobam uma série de relacionamentos um- para-muitos em uma única tabela dimensional e são oriundas geralmente de tabelas nor- malizadas. No entanto há exceção a essa regra, outra situação muito comum é aquela em que há necessidade de incluir alguns sinalizadores de cardinalidade variados e diver-

sos (Kimbal e Ross 2013, ´Camilovi´c et al. 2009). Em vez de criar dimensões separadas

para cada sinalizador e atributo, Kimbal e Ross (2013) recomenda criar uma única dimen- são combinando todos os atributos. Essa técnica é conhecida como junk dimensions e permite reduzir o número de chaves estrangeiras na tabela de fatos, de forma dramática.

2.2.3.6 Níveis de Hierarquia

Hierarquia é definida como um conjunto de relações binárias entre os níveis de uma di- mensão, onde cada dimensão participante da hierarquia é chamada de nível de hierarquia. Dados dois níveis de hierarquia, o mais alto é chamado de pai e o mais baixo de filho. As ferramentas OLAP usam hierarquias para permitir uma visão geral e detalhada dos dados usando operações como drill-down e roll-up. (Malinowski e Zimányi 2004). Dessa maneira, o suporte a diferentes níveis e tipos de hierarquia propiciam a modelagem de um grande arranjo de cenários de negócio, auxiliando na tomada de decisões (Malinowski e Zimányi 2004, Talwar e Gosain 2012).

A Figura 2.8 exibe um esquema estrela do modelo dimensional teleconsultoria obtido deste trabalho. Observa-se que é possível obter visões dos dados em diferentes níveis de hierarquia em localidade e/ou ocupação e/ou tempo. Com base nesse esquema, percebe- se que pode ser obtido o total de teleconsultoria por estabelecimento, município, estado, região ou pais.

Figura 2.8: Esquema estrela com níveis de hierarquia.

Fonte: Produção Própria

2.2.3.7 Granularidade

Granularidade pode ser visto como uma unidade indivisível (grão) de medida que au- xiliará no nível de detalhamento adotado nas análises futuras (Combi et al. 2004). Na Fi- gura 2.8, pode-se ver o nível de hierarquia nos atributos, bem como sua granularidade para cada um, como o mês sendo o menor atributo de hierarquia da dimensão DIM_TEMPO e estabelecimento_nome da dimensão DIM_LOCALIDADE. Essa é uma das questões mais críticas de um projeto de DW porque afeta o volume dos dados e o tipo de consultas que podem ser respondidas pelo DW. Quando o nível de granularidade muito alto é utili- zado, o volume do DW é reduzido juntamente com o número de consultas que podem ser respondidas.

2.2.3.8 Diferença Entre Esquema Estrela e Modelo Relacional

Apesar de ambos serem modelos lógicos, o modelo relacional tradicional e o esquema estrela diferem em dois pontos principais: As tabelas selecionadas e o modo como essas tabelas estão relacionadas. Na 2.9(a) é apresentado um modelo relacional tradicional, enquanto na figura 2.9(b) é utilizado o esquema estrela, no entanto, apesar de conterem a mesma informação, observa-se uma estrutura de relacionamentos diferentes. No modelo tradicional, os relacionamentos são estabelecidos sem enfatizar especificamente nenhuma tabela, seguindo uma lógica natural. Já no esquema estrela há mais restrição, baseando-se em um conjunto de relacionamentos “one-to-many” entre tabelas descritivas (dimensões) e uma tabela central (fatos) que representa a área de interesse (Schuff et al. 2011).

Figura 2.9: Diferença Entre Esquema Estrela e Modelo Relacional

(a) Modelo Tradicional (b) Esquema Estrela

Fonte: Schuff et al. (2011)