Modelo Tese MGI / MEGI

MODELO ZeEN Uma abordagem minimalista para o desenho de data warehouses

Miguel Nuno da Silva Gomes Rodrigues Gago

Dissertação apresentada como requisito parcial para obtenção do grau de Mestre em Estatística e Gestão de Informação Dissertation presented as partial requirement for obtaining the Master’s degree in Statistics and Information Management

ii TÍTULOTÍTULO Subtítulo Subtítulo

Nome completo do Candidato Nome completo do Candidato

Dissertação / Trabalho de Projeto / Relatório de Dissertação / Trabalho de Projeto / Relatório de Estágio apresentada(o)Estágio apresentada como requisito(o) como parcial requisito para obtenção parcial do para grauobtenção de Mestre do emgrau Gestão de Mestre de Informação em Estatística e Gestão de Informação

Instituto Superior de Estatística e Gestão de Informação Universidade Nova de Lisboa

MODELO ZeEN

Uma abordagem minimalista para o desenho de data warehouses

por

Miguel Nuno da Silva Gomes Rodrigues Gago

Dissertação apresentada como requisito parcial para a obtenção do grau de Mestre em Estatística e Gestão de Informação, Especialização em Gestão dos Sistemas e Tecnologias de Informação

Orientador: Prof. Dr. Miguel de Castro Neto

Março 2013

iii

Ao meu Pai, o Engenheiro Armando Rodrigues Gago, que me ensinou a procurar sempre mais além.

Agradecimentos

À minha Mãe Maria Ondina,

À minha Mulher Luísa, pelo tempo que lhes subtraí e por acreditarem sempre em mim.

Ao Prof. Dr. Miguel de Castro Neto, por me ter incutido confiança em desenvolver esta dissertação na área da Business Intelligence.

Il semble que la perfection soit atteinte, non quand il n'y a plus rien à ajouter mais quand il n'y a plus rien à retrancher.

Saint-Exupéry, Terre des Hommes

vi RESUMO

Constituindo o data warehouse o componente estrutural por excelência dum sistema de Business Intelligence, alterações à estrutura do modelo de negócio servido implicam normalmente alterações ao modelo de dados utilizado e, logo, operações especializadas de administração e arquitectura, tais como: paragem do sistema, redesenho e reimplementação do data warehouse, adaptação dos processos de carregamento e da lógica de acesso à informação, testes, novo carregamento e novo arranque do sistema.

Tendo em conta o tempo, risco e custo envolvidos nestas operações, potenciados pela rigidez e complexidade dos modelos de dados, torna-se oportuno procurar formas de agilizar os processos de mudança, pela concepção de um novo modelo de dados simples, seguro, e generalizável.

Focando o âmbito da investigação numa necessidade do modelo de negócio da indústria farmacêutica, e após revisão de modelos de dados existentes, propõe-se nesta dissertação um novo modelo (ZeEN - Zero Effort Entity-Network) com o objectivo referido, cujos desempenho e complexidade de implementação e manutenção foram avaliados positivamente face aos modelos tradicionais relacional e dimensional e à recente abordagem Anchor Modeling.

Desta comparação são retiradas conclusões relativas às necessidades de Business Intelligence em geral, e são propostas vias para futura actividade.

PALAVRAS-CHAVE

Base de dados; Data warehouse; Modelação de dados; Business Intelligence; Normalização; Customer Relationship Management

vii ABSTRACT

As the data warehouse is the core framework of a Business Intelligence system, changes to the business model at stake also imply changes to the applied data model, which require specialized maintenance and architecture operations, such as: halting the system, data warehouse redesign and reimplementation, changes to loading processes and information retrieval logic, tests, reloading of data and system rebooting.

Considering time, risk and cost implied in these operations, strongly related to data model rigidity and complexity, it seems advisable to seek streamlining of change processes, by framing a new simple, safe and generalizable data model.

Aiming at this purpose, after reviewing existing data model concepts, and by focusing research on a specific need of the pharmaceutical industry, a new model (ZeEN - Zero Effort Entity-Network) is presented here, which was succesfully benchmarked against traditional relational and dimensional models and Anchor Modeling recent approach, for performance, and implementation and maintenance complexity.

From the experiment, conclusions are drawn over Business Intelligence generic needs, and future work is suggested.

KEYWORDS

Database; Data warehouse; Data modeling; Business Intelligence; Normalization; Customer Relationship Management

viii ÍNDICE

1. Introdução ...... 21 1.1. Descrição do problema de investigação ...... 21 1.2. Objectivo da investigação ...... 22 1.3. Questões de investigação ...... 22 1.4. Metodologia ...... 23 1.5. Valor da investigação ...... 24 1.6. Estrutura da dissertação ...... 25 2. Revisão da Literatura ...... 27 2.1. Introdução ...... 27 2.2. Business Intelligence ...... 27 2.3. Modelos de dados ...... 29 2.3.1. Dados ...... 29 2.3.2. Ficheiros manuais ...... 29 2.3.3. Sistemas baseados em ficheiros ...... 30 2.3.4. Sistemas de gestão de bases de dados ...... 31 2.3.4.1. Primeira geração ...... 31 2.3.4.2. Segunda geração ...... 34 2.3.4.3. Normalização de dados ...... 34 2.3.4.4. Temporalidade ...... 43 2.3.4.5. Modelo dimensional ...... 43 2.3.5. Outras Abordagens ...... 54 2.3.5.1. Bases de dados baseadas em objectos ...... 54 2.3.5.2. Schema integration, Schema evolution e Schema versioning .. 55 2.3.5.3. Schema matching genérico ...... 56 2.3.5.4. Row modeling / Entity-Attribute-Value ...... 57 2.3.5.5. Anchor modeling ...... 58 2.3.5.6. Data Vault ...... 61 2.3.5.7. Metodologias ágeis em bases de dados ...... 64 3. Métodos e Materiais ...... 66 3.1. Métodos ...... 66 3.2. Materiais ...... 67 4. Resultados e Discussão ...... 69

ix 4.1. Descrição do modelo de negócio subjacente ao modelo de dados a testar ...... 69 4.2. Descrição dos dados utilizados para teste ...... 71 4.2.1. Estrutura de Eventos ...... 71 4.2.2. Estrutura de Dimensões ...... 71 4.2.3. Modelação ...... 72 4.2.4. Dados ...... 74 4.2.4.1. Factos ...... 74 4.2.4.2. Dados de Estruturas ...... 74 4.3. Descrição do processo de BI considerado ...... 75 4.4. Descrição do dashboard pretendido...... 77 4.4.1. Indicadores de Marketing e Vendas MI e Evol ...... 77 4.4.2. Necessidade de um dashboard ...... 80 4.4.3. Configuração do dashboard pretendido ...... 82 4.4.4. Alinhamento com o objectivo da investigação ...... 83 4.5. Implementação do modelo relacional ...... 85 4.5.1. Modelo físico (R) ...... 85 4.5.2. Consulta de dados ...... 85 4.5.3. Modelo relacional com cubo de pré-agregação ...... 91 4.6. Identificação de alternativa ao modelo relacional ...... 94 4.6.1. Necessidade ...... 94 4.6.2. Potencial circunstância impactante ...... 94 4.6.3. Avaliação de impacto ...... 95 4.6.3.1. Impacto na estrutura de armazenamento ...... 95 4.6.3.2. Impacto na consulta aos dados ...... 97 4.6.4. Objectivo de redução de impacto ...... 98 4.6.5. Estratégia de redução de impacto ...... 98 4.6.6. Desenvolvimento do conceito ...... 100 4.6.7. Aperfeiçoamento do conceito ...... 102 4.7. Implementação do modelo Z ...... 109 4.7.1. Modelo físico ...... 109 4.7.2. Avaliação de impacto de alterações em Z ...... 111 4.7.3. Consulta de dados ...... 112 4.7.4. Modelo Z com cubo de pré-agregação (Z_c) ...... 113 4.7.5. Modelo Z com associações directas (Z_d) ...... 115

x 4.7.6. Modelo relacional com associações directas ...... 118 4.8. Identificação de alternativa ao modelo de factos ...... 119 4.8.1. Necessidade ...... 119 4.8.2. Solução ...... 119 4.9. Implementação do novo modelo de factos ...... 121 4.9.1. Modelo físico (Z+) ...... 121 4.9.2. Consulta de dados ...... 122 4.10. Modelo dimensional ...... 125 4.11. Anchor model...... 129 4.12. Sintese dos resultados ...... 131 4.13. Designação escolhida ...... 135 5. Conclusões ...... 137 5.1. Cumprimento do objectivo de investigação ...... 137 5.1.1. Esforço e impacto Zero ...... 137 5.1.2. Simplicidade, imutabilidade e determinismo ...... 137 5.1.3. Compromisso aceitável ...... 138 5.2. Duas variantes, para diferentes necessidades ...... 138 5.3. Aproveitamento de infra-estrutura e know-how existentes ...... 138 5.4. Possível standard para data warehousing ...... 139 5.5. Contributos para o conhecimento ...... 139 5.5.1. Filosofia ZeEN ...... 139 5.5.2. Materialização de relações indirectas ...... 140 5.5.3. Flexibilidade temporal ...... 140 5.5.4. Separação clara dos conceitos e estruturas de dimensões e eventos ...... 140 6. Limitações e Recomendações para Trabalhos Futuros ...... 141 6.1. Demonstração teórica formal ...... 141 6.2. Acomodação de diferentes tipos e domínios de dados...... 141 6.3. Máquina universal de análise (ZeEN#) ...... 141 6.4. Detecção automática de fontes ...... 141 6.5. Acomodação de Metadata e outros dados auxiliares ...... 142 6.6. Considerações temporais adicionais ...... 142 6.7. Linguagem de cálculo ...... 142 6.8. Linguagem de navegação ...... 143 6.9. Tecnologia nova ...... 143

xi 7. Apêndices ...... 144 7.1. Script das tabelas do Modelo Relacional (R)...... 144 7.2. Script da consulta on-the-fly do Modelo Relacional (R) ...... 149 7.3. Output da consulta para o dashboard (R) ...... 153 7.4. Script da rotina de criação do cubo (R) ...... 155 7.5. Script da consulta on-the-fly dos Modelos Relacional (R) e Z sobre cubo ...... 158 7.6. Script da rotina de criação dum modelo Z a partir dum modelo relacional ..... 159 7.7. Script da rotina de criação dum modelo relacional a partir dum modelo Z ..... 162 7.8. Script da consulta on-the-fly do Modelo Z ...... 164 7.9. Materialização de associações indirectas (Z_d) ...... 168 7.10. Script da consulta on-the-fly do Modelo Z_d ...... 170 7.11. Script de carregamento dos Factos de Z_d para Z+ ...... 172 7.12. Script da consulta on-the-fly do Modelo Z+ ...... 173 7.13. Script da consulta on-the-fly do Modelo Dimensional ...... 175 7.14. Script da camada inferior da consulta on-the-fly aplicada a AM ...... 176 8. Referências bibliográficas ...... 178

xii ÍNDICE DE FIGURAS

Figura 1. Ficheiros manuais...... 30 Figura 2. Modelo hierárquico...... 33 Figura 3. Modelo em rede...... 33 Figura 4. ZNF...... 36 Figura 5. 1NF...... 36 Figura 6. 2NF...... 38 Figura 7. 3NF / BCNF...... 39 Figura 8. 4NF / 5NF / DKNF / 6NF...... 42 Figura 9. Modelo relacional monotemporal...... 44 Figura 10. Modelo dimensional Star...... 46 Figura 11. Modelo dimensional Constellation...... 46 Figura 12. Modelo dimensional Star Cluster...... 47 Figura 13. Modelo dimensional Constellation Cluster...... 47 Figura 14. Modelo dimensional Snowflake...... 49 Figura 15. Modelo EAV aplicado à entidade DIM a partir da 2NF...... 59 Figura 16. Modelo Anchor do exemplo ...... 62 Figura 17. Modelo Anchor do exemplo convertido em relacional (SQL) ...... 62 Figura 18. Modelo Anchor em tabelas relacionais na 6NF...... 63 Figura 19. Modelo ER simples...... 73 Figura 20. O processo de BI...... 75 Figura 21. Dashboard para Análise de Vendas...... 81 Figura 22. Modelo físico relacional (base de dados R)...... 84 Figura 23. Registos de uma consulta efectuada...... 86 Figura 24. Camada inferior da consulta: cálculo de MS regional e MS nacional...... 87 Figura 25. Camada superior da consulta: cálculo algébrico sobre as métricas auxiliares e organização dos registos para entrega ao dashboard...... 88 Figura 26. Dos dados ao dashboard – modelo relacional com e sem cubo...... 90 Figura 27. Modelo ER – nova entidade SBU ...... 95 Figura 28. Modelo ER vs modelo de grafos ...... 99 Figura 29. Nós e associações no modelo de grafos...... 101 Figura 30. Entidades acrescentadas e associadas como nós...... 101 Figura 31. Modelos ER, relacional e de grafos (extremo)...... 103

xiii Figura 32. Modelo lógico em rede extremo (grafos)...... 104 Figura 33. Modelo lógico em rede e respectivo DSD...... 105 Figura 34. Modelo Z...... 106 Figura 35. Modelo Z - estrutura de dimensões do exemplo da revisão de literatura. . 108 Figura 36. Modelo físico Z...... 110 Figura 37. Tabela Tables...... 110 Figura 38. Tabela Groups...... 111 Figura 39. Camada inferior da consulta para o modelo Z...... 113 Figura 40. Dos dados ao dashboard - modelo relacional (c/cubo) vs Z_c ...... 114 Figura 41. Camada inferior da consulta para o modelo Z_d...... 117 Figura 42. Modelação genérica de factos – conceito e exemplo...... 120 Figura 43. Modelação genérica de factos – implementação...... 121 Figura 44. Camada inferior da consulta para o modelo Z+...... 122 Figura 45. Evolução dos modelos no sentido da generalização...... 124 Figura 46. Modelo dimensional Snowflake ...... 127 Figura 47. Dos dados ao dashboard - modelo relacional vs dimensional (OLAP) ...... 128 Figura 48. Anchor model do caso estudado ...... 130 Figura 49. Anchor model implementado no modelo relacional...... 131

xiv ÍNDICE DE TABELAS

Tabela 1. OLTP vs OLAP (Ponniah, 2001) ...... 50 Tabela 2. Fórmulas de cálculo do MI e do Evol...... 78 Tabela 3. Parâmetros de consulta de teste ...... 89 Tabela 4. Parâmetros de criação do cubo de teste ...... 93 Tabela 5. Relação Linha Comercial - SBU ...... 94 Tabela 6. Esforço necessário para implementar alterações em cada modelo...... 133 Tabela 7. Esforço necesssário para implementar alterações em cada modelo (cont.)...... 134 Tabela 8. Quantificação dos factores implicados nas questões de investigação...... 136 Tabela 9. Ranking dos modelos...... 136

xv LISTA DE SIGLAS E ABREVIATURAS

1NF Primeira Forma Normal

2NF Segunda Forma Normal

3NF Terceira Forma Normal

4NF Quarta Forma Normal

5NF Quinta Forma Normal

6NF Sexta Forma Normal

AIM Autorização de Introdução no Mercado

AM Agile Modeling

AM Anchor Model(ing)

API Application Programming Interface

BCNF Boyce-Codd Normal Form

BI Business Intelligence

BIU Basic Information Unit

C Nome de uma linguagem de programação

C-DV Conceptual Data Vault

COBOL Common Business-Oriented Language

xvi

CODASYL Conference on Data Systems Languages

CRM Customer Relationship Management

DBA Database Administrator

DBMS Database Management System

DCI Denominação Comum Internacional

DDL Data Definition Language

DIM Delegado de Informação Médica

DKNF Domain/Key Normal Form

DM Data Mining

DML Data Manipulation Language

DMX Data Mining Extensions

DSD Data Structure Diagram

DSDM Dynamic systems development method

DSS Decision Support Sytem

DV Data Vault

DW Data Warehouse

DW 2.0 Data Warehousing 2.0

EAV Entity-Attribute-Value

EIS Executive Information System

ER Entity-Relationship

EPRS Electronic Patient Record System

ETL Extract-Transform-Load

Evol Evolution Index

FDD Feature-driven development

GUAM Generalized Update Access Method

HOLAP Hybrid OLAP

ID Código Identificador único

KPI Key Performance Indicator

LC Located Contents

MB Megabyte

MDX Multidimensional Expressions

MI Market Index

MIS Management Information System

MOLAP Multidimensional OLAP

MQL Marketing Query Language

MS Market Share

MS Microsoft

MSN Market Share Nacional

MSR Market Share Regional

MSRM Medicamentos Sujeitos a Receita Médica

MVD Multivalued Dependency

MVS Materialized View Selection

OLAM On-line Analytical Mining

OLAP On-line Analytical Processing

OLTP On-Line Transaction Processing ou On-line Teleprocessing

OODBMS Object-Oriented Database Management System

ORDBMS Object-Relational Database Management System

RAM Random Access Memory

RDBMS Relational Database Management System

ROLAP Relational OLAP

SBU Strategic Business Unit

SQL Structured Query Language

UoD Universe of Discourse

XML Extensible Markup Language

XMLA XML for Analysis

XP Extreme Programming

ZNF Zero Normal Form

ZeDMS Zero Effort Data Management System

ZeEN Zero Effort Entity-Network

ZeEN+ Zero Effort Entity-Network Plus

ZeEN# Zero Effort Entity-Network Sharp

ZeQL Zero Effort Query Language

1. INTRODUÇÃO

1.1. DESCRIÇÃO DO PROBLEMA DE INVESTIGAÇÃO

As organizações, comerciais ou outras, necessitam de informação relevante, correcta e atempada para suportar a tomada das decisões mais acertadas, sempre necessárias à melhoria contínua do seu desempenho e à sua sobrevivência (Cody, Kreulen, Krishna, & Spangler, 2002; Lönnqvist & Pirttimäki, 2006; Thomsen, 2002; Turban, Sharda, Aronson, & King, 2007).

O processo de Business IntelIigence (BI) tem como objectivo suprir esta necessidade (Golfarelli, Mandreoli, Penzo, Rizzi, & Turricchia, 2012; Rud, 2009; Turban et al., 2007).

Fá-lo canalizando regularmente dados de actividade para um data warehouse (DW) onde, após transformação, ficam armazenados de forma persistente e organizada, permitindo aos utilizadores do sistema explorar a informação obtida através de aplicações de análise e visualização, e tomar decisões (Agrawal, Sundararaghavan, Ahmed, Nandkeolyar, 2009; Inmon, 1999).

O DW por definição reproduzindo a estrutura do negócio (Inmon, 2005), qualquer alteração a este último implica alterações ao modelo de dados (Sen & Sinha, 2005; Curino, Tanca, Moon, & Zaniolo, 2008), e logo actividades especializadas de administração e rearquitectura (Rönnback, Regardt, Bergholz, Johannesson, & Wohed, 2010a).

Por sua vez, alterações ao modelo de dados implicam adicionalmente alterações às aplicações de exploração da respectiva informação (De Vries & Roddick, 2007; Simsion & Witt, 2005).

Estas actividades de adaptação, quer no DW quer no software que dela depende, envolvem tempo, risco e custos elevados (Curino, Moon, & Zaniolo, 2009; Kimball & Ross, 2010; Simsion & Witt, 2005), logo torna-se imperativo

encontrar forma de agilizar o processo de adaptação do modelo de dados a mudanças na realidade, cada vez mais frequentes (Curino et al., 2008; Inmon, 2005).

1.2. OBJECTIVO DA INVESTIGAÇÃO

A presente investigação tem como objectivo identificar um modelo de dados cuja configuração permita atenuar ou eliminar a complexidade e os problemas decorrentes da adaptação de bases de dados a alterações de requisitos, as quais ocorrem com frequência (Moody & Kortink, 2000).

1.3. QUESTÕES DE INVESTIGAÇÃO

Logo, colocam-se as seguintes questões de investigação:

Questão genérica:

. É possível identificar um modelo de dados com o qual a implementação de alterações a regras de negócio se traduz em menor impacto nas operações de adaptação do mesmo, e nos algoritmos de consulta, comparativamente a um modelo tradicionalmente utilizado?

Questões específicas:

. Que operações de carregamento e de adaptação se conseguem eliminar utilizando o novo modelo? . Haverá operações adicionais necessárias? . Qual o impacto do novo modelo no desempenho das consultas? . Qual o impacto do novo modelo no espaço em disco utilizado? . Qual o impacto do novo modelo nos tempos de carregamento? . Qual o impacto do novo modelo no risco do projecto de BI?

. Que soluções (variantes) existem de equilíbrio entre os factores anteriores e a que cenários mais se adequam?

1.4. METODOLOGIA

Os fundamentos para responder a estas questões serão investigados na literatura respeitante a modelos de dados existentes que têm sido habitualmente adoptados em BI, na maioria o relacional e o dimensional (Jovanovic & Bojicic, 2012; Nagabhushana, 2006; Pedersen & Jensen, 2001; Teorey, Lightstone, Nadeau, & Jagadish., 2011), assim como a outras abordagens com presumível potencial para solucionar o problema de investigação.

A solução poderá consistir em algo encontrado na literatura ou prática, uma adaptação de algo já existente, ou algo essencialmente novo, sendo utilizado no processo de descoberta quer o raciocínio dedutivo (como quando se aplicam regras de normalização para aperfeiçoar um modelo) quer o indutivo (inferindo novos caminhos para uma determinada área a partir de áreas distintas).

Será utilizada uma abordagem experimental para teste de possíveis soluções, focada numa necessidade concreta, em detrimento duma abordagem algébrica formal, que poderá ter lugar em desenvolvimentos futuros de investigação.

A solução será testada com um conjunto de dados simulando a actividade de vendas e promoção duma empresa farmacêutica, procurando responder a um cenário delimitado de requisitos de análise da área comercial habituais no sector.

O teste será efectuado tendo como benchmark uma implementação tradicional em modelo relacional e dimensional dos dados para o mesmo objectivo. Mais do que uma implementação ou versão da solução poderão ser estudadas consoante a evolução e aperfeiçoamento do conceito. Adicionalmente, será eventualmente testada alguma abordagem alternativa identificada na literatura que se revele também poder contribuir para a resolução do problema de investigação.

1.5. VALOR DA INVESTIGAÇÃO

A solução a identificar, nas organizações onde for aplicada

. deverá permitir reduzir de forma significativa: - tempo e consequente custo de mão-de-obra com reconfiguração de sistemas, - custo de mão-de-obra (interna ou contratada) elevado devido a alto nível de especialização, - prejuízos no negócio devidos a tempo de paragem dos sistemas, e - riscos de inconsistência ou perda de dados devido a complexidade e novidade de tarefas;

. evitará insucesso e abandono de sistemas de BI, frequentemente devidos a inadaptações ao negócio, em que a opção de reconfiguração ou é rejeitada por ser demasiado cara, ou falha ou chega tarde demais pela sua complexidade – a companhia analista do mercado IT Gartner, em 2011 reportava um nível de 70 a 80% de projectos falhados em BI (Kernochan, 2011), e Watson e Ariyachandra (2005) relataram 30 a 50% de projectos de DW atrasados ou a ultrapassar o orçamento;

. permitirá uma entrada em funcionamento praticamente imediata de novos sistemas de BI e novas funcionalidades;

. facilitará a integração de dados entre sistemas de organizações diferentes (por exemplo entre empresas envolvidas numa fusão ou pertencentes a uma multinacional, ou entre o cliente e o fornecedor de dados);

. poderá facilitar a migração de dados num contexto de sistemas integrados, contribuindo para a extensão do conceito de data warehousing a ambientes distintos da BI (Caetano & Costa, 2012);

. poderá reduzir o tempo dos processos de carregamento (ETL), grande parte dos quais são dedicados à agregação de dados em cubos, que serão eventualmente tornados obsoletos;

. poderá vir a reduzir o espaço em disco necessário por uma maior normalização dos dados, evitando pré-agregações redundantes e espaço perdido com dados esparsos em cubos – frequentemente mais de 90% (Todman, 2001);

e pelas razões referidas apresenta potencial para se tornar um standard para data warehousing.

1.6. ESTRUTURA DA DISSERTAÇÃO

A seguir à presente introdução, o capítulo 2 comenta a revisão da literatura, orientada do seguinte modo:

Primeiro contextualiza-se e refere-se a importância dos dados/DW em BI, para se passar ao seu estudo ao longo da história, desde os ficheiros manuais, até aos sistemas gestores de bases de dados (DBMS).

Destes, analisa-se a primeira geração (modelos hierárquico e em rede), e a segunda, em que surge o modelo relacional, de que uma das vantagens principais é a possibilidade de normalização de dados. Logo revela-se pertinente analisar de seguida as várias formas normais aceites na literatura, por grau crescente de normalização.

Deste modo se pretende, em todo o capítulo 2, percorrer por ordem crescente de funcionalidade, novidade e/ou sofisticação a evolução das ideias que estão subjacentes à organização de dados que nos propomos melhorar. Para reforçar visualmente a evolução dos conceitos, acompanhamos o percurso com um pequeno exemplo simplificado e contextualizado que ajuda a compreender a miríade de modos possíveis de representar os mesmos dados, a questionar em que medida uns modelos são melhores que outros, e a entender porque existem.

Após a exploração do modelo relacional até à sua implementação teoricamente mais perfeita no sentido da normalização, passamos paradoxalmente ao conceito oposto, de desnormalização, em que consiste a passagem ao modelo dimensional, mais recente e igualmente popular, na sua configuração mais preconizada em estrela (Jovanovic & Bojicic, 2012), e também em floco-de-neve (Pedersen & Jensen, 2001).

Conseguimos então obter uma perspectiva total dos modelos mais utilizados em data warehousing, razão pela qual mais adiante serão escolhidos como referência neste estudo: os modelos relacional (normalizado) e dimensional.

De seguida, continuando a procurar identificar potenciais soluções ou ideias para uma solução, vamos examinar abordagens inovadoras que partilham de ideal alinhado com o desta investigação, como agilizar, facilitar, aligeirar, padronizar, generalizar, ou universalizar.

Segue-se o capítulo 3 – Métodos e Materiais – que menciona os pormenores técnicos e o racional das implementações de teste de soluções.

No capítulo 4 – Resultados e Discussão – comentam-se todos os passos conducentes à concepção e desenvolvimento do novo modelo e variantes, os testes efectuados e os resultados obtidos.

No capítulo 5, conclui-se acerca destes resultados, destacando as vantagens, desvantagens e aplicações possíveis do novo modelo nas suas variantes.

O capítulo 6 termina a dissertação, apontando as limitações da investigação efectuada, e sugerindo vias para desenvolvimento futuro.

2. REVISÃO DA LITERATURA

2.1. INTRODUÇÃO

Neste capítulo é comentado o conhecimento recolhido considerado mais relevante no âmbito da procura dum novo modelo de dados simples para suportar necessidades de informação organizacionais, pelo que os temas investigados são a Business Intelligence (BI) e a modelação de dados (cujas várias abordagens serão examinadas e comparadas na forma como se aplicam a um caso prático).

2.2. BUSINESS INTELLIGENCE

Em 1957, é utilizada pela primeira vez a expressão “Business Intelligence” num texto de investigação. Em “A Preliminary Proposal for a Business Intelligence System”, já existe preocupação com o crescimento, complexidade e ritmo acelerado do mundo empresarial, e respectivo impacto na partilha de informação, sendo proposto como solução um sistema de automatização da codificação e entrega de informação (Luhn, 1957; 1958).

Efectivamente, as organizações, comerciais ou outras, necessitam de informação relevante, correcta e atempada para suportar a tomada das decisões mais acertadas, sempre necessárias à melhoria contínua do seu desempenho e mesmo à sua sobrevivência (Lönnqvist & Pirttimäki, 2006; Turban et al., 2007).

A partir dos anos 1990 (Turban et al., 2007), a expressão “Business Intelligence” - retomada e promovida em 1989 por Howard Dressner do Gartner Group (Negash & Gray, 2008) - passa a ser correntemente aceite para designar o processo que responde a esta necessidade, assegurando a entrega da informação certa na altura certa aos decisores adequados (Larson, 2009; Rud, 2009)

BI constitui-se, logo à partida, como um termo popular e abrangente (Collier, 2011) que engloba tanto arquitecturas, como ferramentas, bases de dados e aplicações, consistindo num processo de transformação sucessiva de dados em informação, em seguida decisões e finalmente acções (Negash & Gray, 2008; Raisinghani, 2004; Turban et al., 2007).

A disponibilização de informação aos decisores de forma acessível permitindo- lhes retirar rapidamente conclusões quanto às acções a tomar, automatizada com o advento da informática e cada vez mais facilitada pela respectiva evolução (Power, 2007), tem continuado até hoje a ser consensualmente abarcada sob a designação “Business Intelligence”, não obstante as várias e nem sempre coincidentes definições do termo usadas na prática (Kobielus, 2010; Sabanovic, 2008), e a sua ainda escassa sistematização académica (Jourdan, Rainer, & Marshall, 2008; Negash, 2004).

Apesar desta indefinição do termo (Turban et al., 2007), existe significativo consenso em considerar e classificar os processos de BI em três grandes fases: recolha, armazenamento e disponibilização de informação de negócio (Hannula & Pirttimäki, 2003; Lönnqvist & Pirttimäki, 2006; Negash & Gray, 2008).

A presente revisão de literatura centra-se na fase do armazenamento, focando a base de dados por constituir um elemento-charneira cujo posicionamento afecta tanto a transformação dos dados externos ao sistema de BI como a sua disponibilização de forma inteligível (informação) ao utilizador/decisor, as quais se pretende tornar mais adaptáveis a alterações ao modelo de negócio duma organização. O foco é efectuado na estrutura lógica dos dados, com o objectivo de identificar em que medida as alternativas já existentes ou propostas podem contribuir para a agilidade pretendida.

Segundo Codd (1980), a reflexão sobre modelos de dados deve contribuir para lidar com a evolução de bases de dados de modo a minimizar o respectivo impacto em software existente, e para investigar as propriedades de organizações alternativas dos dados, motivações que pautarão esta investigação, incluindo a revisão que segue.

1 2.3. MODELOS DE DADOS

2.3.1. Dados

A base de dados, referida como data warehouse (DW) no contexto de BI (Rainardi, 2008) é o elemento de armazenamento persistente e organizado dos dados relevantes ao negócio, pronto para ser acedido através de rotinas de consulta (Negash & Gray, 2008).

O armazenamento de dados tem vindo a ser utilizado desde o advento dos computadores como auxiliares de gestão nos anos 1960, numa altura em que o termo BI não tinha ainda sido popularizado e o software de apoio à decisão era designado por outros nomes e acrónimos como DSS, MIS ou EIS (Power, 2007; Thomsen, 2003; Turban et al., 2007), e tal como este tem acompanhado a evolução tecnológica.

2.3.2. Ficheiros manuais

Os primeiros sistemas computorizados a usar uma quantidade considerável de dados foram criados para melhorar o acesso à informação, que até então se fazia por meio de ficheiros manuais, cada ficheiro tendo informação associada a uma instância de uma entidade, como um determinado cliente, produto ou projecto (Connolly & Begg, 2005; Silberschatz, Korth & Sudarshan, 2011).

A Figura 1, que simula de forma simplificada alguns ficheiros manuais duma empresa comercial, dá uma ideia (imaginando a totalidade dos ficheiros e a quantidade de gavetas onde estavam armazenados) de como seria difícil num sistema manual reunir os ficheiros necessários e efectuar as operações de associação e de

1 A expressão “modelo de dados” é correntemente empregue em duas acepções diferentes: como definição abstracta de estruturas de dados, ou como uma definição específica da estrutura de dados de uma realidade concreta (Date, 2012) – ou seja uma instanciação da primeira. Na presente dissertação, a expressão será utilizada indiferentemente nos dois sentidos, e em alguns casos aplicar-se- á à representação de uma definição abstracta sobre outra definição abstracta (o modelo relacional).

cálculo, para obter uma informação aparentemente simples como, por exemplo, o total de vendas dum produto da responsabilidade dum supervisor.

Figura 1. Ficheiros manuais.

2.3.3. Sistemas baseados em ficheiros

Os sistemas computorizados que surgem então são denominados “baseados em ficheiros” (file-based), mas não se trata apenas dum processo de digitalização de ficheiros manuais. Existe um pequeno avanço conceptual em que geralmente o novo ficheiro electrónico representa agora uma entidade, ou seja um conjunto de instâncias, dispostas em linhas (registos), ficando a informação associada disposta em colunas (campos) (Connolly & Begg, 2005) – o vulgar conceito de tabela, embora sem um formato imposto pelo sistema.

Assim, em vez do que observamos na Figura 1, esperaríamos passar a dispor de um ficheiro de Vendedores, e não de um por Vendedor, passando a existir melhor organização e logo mais fácil acesso.

No entanto, a tecnologia que então suportava os ficheiros electrónicos padecia dos seguintes problemas (Ramakrishnan & Gehrke, 2003; Silberschatz et al., 2011): . tratava-se de simples ficheiros do sistema operativo, vulneráveis, sendo difícil gerir as respectivas políticas de acesso e segurança; . cada programador desenvolvia em separado as suas aplicações (habitualmente cingidas a um único departamento), pelo que cada ficheiro

apresentava uma estrutura e uma lógica de acesso próprias, o que acabava por conduzir a redundância e inconsistência de dados, além de dificultar o desenvolvimento de novos programas; . qualquer nova análise solicitada sobre os dados requeria um esforço considerável de programação; e . a dispersão em ficheiros isolados tornava impossível o controlo da consistência dos dados após um erro e durante o acesso simultâneo por diferentes utilizadores.

Fundamentalmente, por não incluir nem linguagem de consulta que permitisse tratar os dados como conjuntos, nem funcionalidade de folha de cálculo que facilitasse cálculos agregados, no modelo baseado em ficheiros continuava-se a aceder a cada instância (antes ficheiro manual, agora registo digital) de forma isolada. O acesso aos dados apenas era possível percorrendo todos os registos um por um através de linguagens processuais de programação como o COBOL ou o C (Connolly & Begg, 2005). Além disso, os ficheiros gerados eram frequentemente formatados para responder a necessidades físicas, como o output para determinada impressora, tendo layouts rígidos pouco compatíveis com a exploração de dados (Stern & Stern, 1993).

2.3.4. Sistemas de gestão de bases de dados

2.3.4.1. Primeira geração

Os sistemas de gestão de bases de dados (DBMS) surgem como resposta às limitações da utilização de simples ficheiros para armazenamento (Silberschatz et al., 2011), com o objectivo de providenciar um registo da definição dos dados independente das aplicações e do hardware, e um mecanismo autónomo de controlo do acesso e manipulação dos mesmos (Connolly & Begg, 2005).

Na primeira geração de DBMS nasceram dois tipos de sistema: hierárquico e em rede (network ou CODASYL). O modelo hierárquico aparece nos anos 1960 com o software GUAM desenvolvido para lidar com a vasta quantidade de informação que

iria gerar o projecto Apollo de ida à Lua (Connolly & Begg, 2005). Pela prevalência na altura da utilização de armazenamento em fita magnética, implicando acesso unidireccional, o sistema fica limitado a gerir relações hierárquicas (um só pai).

Entretanto, tirando partido do surgimento do suporte em disco, de acesso aleatório imediato, a General Electric desenvolve o DBMS em rede (network) para permitir uma modelação de relações mais sofisticada que a hierárquica, e também tentar impôr um standard para a gestão de dados – CODASYL (Bachman, 1969; Connolly & Begg, 2005).

A Figura 2 e a Figura 3 representam respectivamente, o modelo hierárquico possível e o modelo em rede das relações entre registos dum exemplo retratando uma estrutura simplificada dum grupo farmacêutico. A traço sólido estão as associações hierárquicas (de 1 para n), a tracejado as associações em rede (n para n).

Obviamente no modelo hierárquico estas últimas - um Delegado de Informação Médica (DIM) pode cobrir várias zonas, e uma zona pode ser coberta por vários DIM - não puderam ser devidamente representadas, tendo sido necessário recorrer ao subterfúgio de as representar pelas instâncias duma nova entidade (Zona/DIM) criada para o efeito.

Podemos logo concluir que o modelo lógico em rede é superior ao hierárquico, pois permite representar as mesmas associações de 1 para n, e além destas as relações de n para n.

Em qualquer caso, ambos os sistemas da primeira geração apresentavam no entanto ainda insuficiências enquanto sistemas de gestão de bases de dados, necessitando do desenvolvimento de programas complexos mesmo para consultas simples, e não apresentavam fundamento teórico sólido (Codd, 1970; Connolly & Begg, 2005).

NossaEmpresa1

Linha 2 Linha 10 Linha 3 Produto 2337

CR 007 CR 005 CR 029 CR 027 CR 008

DIM 040 DIM 038 DIM 117 DIM 116 DIM 044

Zona410/DIM 040 Zona400/DIM 038 Zona410/DIM 117 Zona400/DIM 116 Zona400/DIM 044 Zona410/DIM 044

NossaEmpresa2

Linha 1 Linha 7 Linha 8 Produto 2535 Produto 2542

CR 004 CR 019 CR 023

DIM 009 DIM 010 DIM 084 DIM 106 DIM 105

Zona400/DIM 009 Zona410/DIM 010 Zona410/DIM 084 Zona400/DIM 084 Zona400/DIM 106 Zona410/DIM 105

Figura 2. Modelo hierárquico.

Zona Dim Supervisor Linha Empresa Produto

DIM 038 CR 005 Linha 2 NossaEmpresa1 Produto 2337

DIM 116 CR 027 Linha 10

DIM 009 CR 004 Linha 1

DIM 106 CR 023 Linha 8

Zona400 Produto 2535 DIM 044 CR 008 Linha 3 NossaEmpresa2

Produto 2542 DIM 084 CR 019 Linha 7

DIM 010

DIM 105

Zona410

DIM 040 CR 007

DIM 117 CR 029

Figura 3. Modelo em rede.

2.3.4.2. Segunda geração

Em 1970 E.F. Codd publica, fortemente fundamentado em formalismo teórico, o artigo científico (Codd, 1970) em que apresenta o modelo relacional, concebido para “libertar os utilizadores da tarefa frustrante de lidar com os pormenores de representação do armazenamento de dados” (Codd, 1979).

O artigo é aceite muito favoravelmente e torna-se influente, dando origem ao surgimento de DBMS relacionais (RDBMS) experimentais e comerciais (Connolly & Begg, 2005), à emergência do modelo relacional como um standard a partir do nício dos anos 1980 (Pendse, 2008), à consolidação da disciplina académica de Sistemas de Bases de Dados, e à popularização de RDBMS e do seu uso empresarial, tornando-se prática corrente e predominante até aos nossos dias (Ambler, 2003; Ramakrishnan & Gehrke, 2003; Silberschatz et al., 2011; Taitslin, 2011).

A ideia prevalente do modelo relacional, ao ser apresentado, foi a da independência da representação dos dados em relação à máquina, o que constituíu, juntamente com o conceito de linguagem de acesso a dados não-processual de elevado nível (Astrahan et al., 1976), um importante distanciamento qualitativo em relação ao modelo concorrente na altura, o modelo em rede de Bachman (1969), que por essa razão só a muito custo permitia alterações ao esquema de dados (Silberschatz et al., 2011).

2.3.4.3. Normalização de dados

Finalidade

Codd (1970) aponta ainda outra vantagem do modelo relacional como sendo a de permitir endereçar com solidez as questões de derivabilidade, redundância e consistência das relações. Trata-se da questão da normalização de bases de dados relacionais, que procura evitar, só pelo desenho, situações ambíguas, potenciais causadoras de inconsistência ou da necessidade de tarefas adicionais para a evitar (Chen, 1976).

A normalização das bases de dados surge pois como uma forma preferencial de organizar o esquema relacional numa base de dados, uma vez que existem múltiplas formas possíveis de o fazer (Codd, 1970), constituindo uma condição para que a promessa de simplicidade e robustez do modelo relacional se cumpra o mais possível.

Investigação subsequente de diversos autores conduziu à demonstração formal de uma hierarquia de várias formas de normalização (sete geralmente aceites e uma mais recente e controversa), que ficou sistematizada na literatura (Date, 2012).

Para obter sensibilidade à pertinência dos conceitos estudados face ao objectivo da presente investigação, retomamos e detalhamos agora o exemplo já usado anteriormente (para ilustrar os modelos de primeira geração de DBMS), no qual existe uma hierarquia de Força de Vendas DIM-Supervisor-Linha-Empresa, uma hierarquia de Produto Produto-Empresa e uma alocação de Zonas geográficas aos DIM (n para n), e ao qual agora juntamos dados de Vendas e Visitas.

No modelo de negócio farmacêutico de medicamentos, Visitas promocionais são feitas e registadas pelos DIM e Vendas são obtidas externamente. Neste exemplo a análise de Visitas é efectuada cruzando DIM, Zona e Produto, e a de Vendas cruzando apenas Zona e Produto. Este exemplo irá continuando a acompanhar a sucessiva descrição de modelos.

ZNF

Na Figura 4 os elementos apresentados não se encontram normalizados, o que corresponde à Forma Normal Zero, ou ZNF (Speelpenning, Daux & Gallus, 2001), representando uma de infinitas possibilidades de os dados serem obtidos na fonte.

Neste caso, simulamos uma realidade típica em que a tabela AlinhamentoEstrutura foi obtida em ferramenta de apresentações PowerPoint a partir da área comercial da companhia, representando o alinhamento estratégico dos DIM em relação à geografia e ao portfolio de produtos, e a tabela Factos é um output de um software de CRM que integra a informação de Vendas com a de Visitas.

AlinhamentoEstrutura Factos DIM Zona Supervisor Linha Empresa Produto Produto Zona Vendas DIM Visitas DIM 040 Zona410 CR 007 Linha 2 NossaEmpresa1 Produto 2337 Produto 2337 Zona400 500 DIM 038 17 DIM 038 Zona400 CR 005 Linha 2 NossaEmpresa1 Produto 2337 DIM 044 8 DIM 117 Zona410 CR 029 Linha 10 NossaEmpresa1 Produto 2337 DIM 116 21 DIM 116 Zona400 CR 027 Linha 10 NossaEmpresa1 Produto 2337 Zona410 2000 DIM 040 13 DIM 044 Zona400 CR 008 Linha 3 NossaEmpresa1 Produto 2337 DIM 044 14 Zona410 DIM 117 26 DIM 009 Zona400 CR 004 Linha 1 NossaEmpresa2 Produto 2535 Produto 2535 Zona400 3300 DIM 009 18 Produto 2542 DIM 084 21 DIM 010 Zona410 CR 004 Linha 1 NossaEmpresa2 Produto 2535 DIM 106 15 Produto 2542 Zona410 7000 DIM 010 9 DIM 084 Zona400 CR 019 Linha 7 NossaEmpresa2 Produto 2535 DIM 084 18 Zona410 Produto 2542 DIM 105 28 DIM 106 Zona400 CR 023 Linha 8 NossaEmpresa2 Produto 2535 Produto 2542 Zona400 670 DIM 009 12 Produto 2542 DIM 084 9 DIM 105 Zona410 CR 023 Linha 8 NossaEmpresa2 Produto 2535 DIM 106 13 Produto 2542 Zona410 1600 DIM 010 28 DIM 084 14 DIM 105 18 Figura 4. ZNF.

A tabela AlinhamentoEstrutura não se encontra normalizada pois, por exemplo, o DIM 044 apresenta uma repetição de zonas no campo Zona. O mesmo tipo de irregularidade também é visível na tabela Factos.

TudoNumaTabela Produto Zona DIM Supervisor Linha Empresa Vendas Visitas Produto 2337 Zona400 DIM 038 CR 005 Linha 2 NossaEmpresa1 500 17 Produto 2337 Zona400 DIM 044 CR 008 Linha 3 NossaEmpresa1 500 8 Produto 2337 Zona400 DIM 116 CR 027 Linha 10 NossaEmpresa1 500 21 Produto 2337 Zona410 DIM 040 CR 007 Linha 2 NossaEmpresa1 2000 13 Produto 2337 Zona410 DIM 044 CR 008 Linha 3 NossaEmpresa1 2000 14 Produto 2337 Zona410 DIM 117 CR 029 Linha 10 NossaEmpresa1 2000 26 Produto 2535 Zona400 DIM 009 CR 004 Linha 1 NossaEmpresa2 3300 18 Produto 2535 Zona400 DIM 084 CR 019 Linha 7 NossaEmpresa2 3300 21 Produto 2535 Zona400 DIM 106 CR 023 Linha 8 NossaEmpresa2 3300 15 Produto 2535 Zona410 DIM 010 CR 004 Linha 1 NossaEmpresa2 7000 9 Produto 2535 Zona410 DIM 084 CR 019 Linha 7 NossaEmpresa2 7000 18 Produto 2535 Zona410 DIM 105 CR 023 Linha 8 NossaEmpresa2 7000 28 Produto 2542 Zona400 DIM 009 CR 004 Linha 1 NossaEmpresa2 670 12 Produto 2542 Zona400 DIM 084 CR 019 Linha 7 NossaEmpresa2 670 9 Produto 2542 Zona400 DIM 106 CR 023 Linha 8 NossaEmpresa2 670 13 Produto 2542 Zona410 DIM 010 CR 004 Linha 1 NossaEmpresa2 1600 28 Produto 2542 Zona410 DIM 084 CR 019 Linha 7 NossaEmpresa2 1600 14 Produto 2542 Zona410 DIM 105 CR 023 Linha 8 NossaEmpresa2 1600 18

Figura 5. 1NF.

1NF

Para satisfazer a primeira forma normal (1NF) basta que os dados estejam dispostos em tabelas, conjuntos de registos com mesmo número de campos, nos quais não podem existir elementos repetidos (Kent, 1983).

Uma das soluções possíveis para obter normalização 1NF foi obter uma tabela única com registos regulares (Figura 5).

2NF

No entanto, as dependências de Supervisor, Linha e Empresa relativamente a DIM (que é parte da chave Produto-Zona-DIM) podem gerar inconsistência. Por exemplo, se o DIM 084 passar a reportar a outro supervisor, a alteração necessária, que apenas deveria ser efectuada num único lugar, tem aqui de ser efectuada em dois registos, implicando risco de inconsistência. É pois necessário normalizar mais.

A segunda forma normal (2NF) consiste em obter tabelas em que qualquer atributo não-chave depende de toda a chave, e não apenas de parte (Ponniah, 2007).

Assim obtém-se a Figura 6 por decomposição da tabela única2. Agora a anomalia referida já está corrigida: apenas existe um sítio onde alterar o supervisor na tabela dos DIM, porque agora o DIM é chave (os elementos já não se repetem).

2 Passamos a incluir na parte inferior das figuras exemplificativas, a partir da 2NF, também um esquema Entidade-Associação (ER) simplificado que representa as associações entre tabelas.

EstruturaOrganizacional Alinhamento DIM Supervisor Linha Empresa DIM Zona Produto DIM 040 CR 007 Linha 2 NossaEmpresa1 DIM 009 Zona400 Produto 2535 DIM 038 CR 005 Linha 2 NossaEmpresa1 DIM 009 Zona400 Produto 2542 DIM 117 CR 029 Linha 10 NossaEmpresa1 DIM 010 Zona410 Produto 2535 DIM 116 CR 027 Linha 10 NossaEmpresa1 DIM 010 Zona410 Produto 2542 DIM 044 CR 008 Linha 3 NossaEmpresa1 DIM 038 Zona400 Produto 2337 DIM 009 CR 004 Linha 1 NossaEmpresa2 DIM 040 Zona410 Produto 2337 DIM 010 CR 004 Linha 1 NossaEmpresa2 DIM 044 Zona400 Produto 2337 DIM 084 CR 019 Linha 7 NossaEmpresa2 DIM 044 Zona410 Produto 2337 DIM 106 CR 023 Linha 8 NossaEmpresa2 DIM 084 Zona400 Produto 2535 DIM 105 CR 023 Linha 8 NossaEmpresa2 DIM 084 Zona400 Produto 2542 DIM 084 Zona410 Produto 2535 DIM 084 Zona410 Produto 2542 DIM 105 Zona410 Produto 2535 Visitas DIM 105 Zona410 Produto 2542 Produto Zona DIM Visitas DIM 106 Zona400 Produto 2535 Produto 2337 Zona400 DIM 038 17 DIM 106 Zona400 Produto 2542 Produto 2337 Zona400 DIM 044 8 DIM 116 Zona400 Produto 2337 Produto 2337 Zona400 DIM 116 21 DIM 117 Zona410 Produto 2337 Produto 2337 Zona410 DIM 040 13 Produto 2337 Zona410 DIM 044 14 Produto Zona Produto 2337 Zona410 DIM 117 26 Produto Zona Produto 2535 Zona400 DIM 009 18 Produto 2337 Zona400 Produto 2535 Zona400 DIM 084 21 Produto 2535 Zona410 Produto 2535 Zona400 DIM 106 15 Produto 2542 Produto 2535 Zona410 DIM 010 9 Produto 2535 Zona410 DIM 084 18 Vendas Produto 2535 Zona410 DIM 105 28 Produto Zona Vendas Produto 2542 Zona400 DIM 009 12 Produto 2337 Zona400 500 Produto 2542 Zona400 DIM 084 9 Produto 2337 Zona410 2000 Produto 2542 Zona400 DIM 106 13 Produto 2535 Zona400 3300 Produto 2542 Zona410 DIM 010 28 Produto 2535 Zona410 7000 Produto 2542 Zona410 DIM 084 14 Produto 2542 Zona400 670 Produto 2542 Zona410 DIM 105 18 Produto 2542 Zona410 1600

Alinhamento

Produto Zona EstruturaOrg

Vendas

Visitas

Figura 6. 2NF.

3NF

Não obstante, continua a existir uma situação irregular pois há relações transitivas entre atributos não pertencentes à chave (Supervisor, Linha, Empresa). Temos por exemplo a seguinte anomalia (que embora sendo deste novo tipo é parecida com a anterior): para alterar a Linha a que pertence o supervisor CR 023, há que corrigir simultaneamente mais que um registo.

Com novo esforço de normalização, obtém-se então na Figura 7 a 3ª Forma Normal (3NF), que é a 2NF sem ocorrência de dependências transitivas (Ben-Gan, 2012).

DIM Supervisor Alinhamento DIM Supervisor Supervisor Linha DIM Zona Produto DIM 040 CR 007 CR 007 Linha 2 DIM 009 Zona400 Produto 2535 DIM 038 CR 005 CR 005 Linha 2 DIM 009 Zona400 Produto 2542 DIM 117 CR 029 CR 029 Linha 10 DIM 010 Zona410 Produto 2535 DIM 116 CR 027 CR 027 Linha 10 DIM 010 Zona410 Produto 2542 DIM 044 CR 008 CR 008 Linha 3 DIM 038 Zona400 Produto 2337 DIM 009 CR 004 CR 004 Linha 1 DIM 040 Zona410 Produto 2337 DIM 010 CR 004 CR 019 Linha 7 DIM 044 Zona400 Produto 2337 DIM 084 CR 019 CR 023 Linha 8 DIM 044 Zona410 Produto 2337 DIM 106 CR 023 DIM 084 Zona400 Produto 2535 DIM 105 CR 023 Linha DIM 084 Zona400 Produto 2542 Linha Empresa DIM 084 Zona410 Produto 2535 Linha 2 NossaEmpresa1 DIM 084 Zona410 Produto 2542 Linha 10 NossaEmpresa1 DIM 105 Zona410 Produto 2535 Visitas Linha 3 NossaEmpresa1 DIM 105 Zona410 Produto 2542 Produto Zona DIM Visitas Linha 1 NossaEmpresa2 DIM 106 Zona400 Produto 2535 Produto 2337 Zona400 DIM 038 17 Linha 7 AlinhamentoNossaEmpresa2 DIM 106 Zona400 Produto 2542 Produto 2337 Zona400 DIM 044 8 Linha 8 NossaEmpresa2 DIM 116 Zona400 Produto 2337 Produto 2337 Zona400 DIM 116 21 DIM 117 Zona410 Produto 2337 Produto 2337 Zona410 DIM 040 13 2NF Produto 2337 ProdutoZona410 DIM 044 14 Zona Produto EstruturaOrgZona Produto 2337 Zona410 DIM 117 26 Produto Zona Produto 2535 Zona400 DIM 009 18 Produto 2337 Zona400 Produto 2535 Zona400 DIM 084 21 Produto 2535 Zona410 Produto 2535 Zona400 DIM 106 15 Produto 2542 Produto 2535 Zona410 DIM 010 Vendas9 Produto 2535 Zona410 DIM 084 18 Vendas Produto 2535 Zona410 DIM 105 28 Produto Zona Vendas Produto 2542 Zona400 DIM 009 12 Produto 2337 Zona400 500 Produto 2542 Zona400 DIM 084 9 Visitas Produto 2337 Zona410 2000 Produto 2542 Zona400 DIM 106 13 Produto 2535 Zona400 3300 Produto 2542 Zona410 DIM 010 28 Produto 2535 Zona410 7000 Produto 2542 Zona410 DIM 084 14 Produto 2542 Zona400 670 Produto 2542 Zona410 DIM 105 18 Produto 2542 Zona410 1600

Linha

Alinhamento Supervisor

3NF / BCNF Produto Zona DIM

Vendas

Visitas

Figura 7. 3NF / BCNF.

Empresa

Linha

39 4NF / 5NF / DKNF / 6NF AlinhGeo Supervisor

Produto Zona DIM

Vendas

Visitas

BCNF

A Boyce-Codd Normal Form (BCNF) está acima da 3NF pois nela não existem dependências em relação a combinações de parte da chave com atributos, apenas existindo dependências de atributos não-chave em relação a toda a chave (Davidson & Moss, 2012). No caso da Figura 7, em que existe no máximo um atributo não-chave, também a BCNF está já satisfeita.

4NF

No entanto, na tabela Alinhamento ainda existe uma situação de potencial inconsistência, pois verifica-se uma dependência multi-valor (MVD) entre os três elementos da chave.

Esta situação irregular ocorre quando pelo menos dois dos três elementos são independentes entre si, pois cada inserção de novo valor num dos dois atributos implica ter de acrescentar todos os valores possíveis do outro para assegurar todas as combinações possíveis entre eles. A 4ª Forma Normal (4NF), representada na Figura 8, é a BCNF em que não ocorre nenhuma situação irregular de dependência multi-valor (Fagin, 1977) .

5NF

Se a 4NF estiver satisfeita, mas existir uma relação indirecta (através de outra tabela) entre dois dos três elementos da chave, também existe possibilidade de inconsistência, pois uma actualização indiscriminada num dos elementos pode violar a relação indirecta existente. A 5ª Forma Normal (5NF) é a 4NF em que não ocorre esta irregularidade (Date & Fagin, 1992; Stephens, 2009).

Ao retirar Produto da tabela Alinhamento, transformando-a em AlinhGeo, e ao associar Produto a Empresa, como consta da definição inicial do negócio, garante-se a passagem simultânea a 4NF e 5NF com o modelo retratado na Figura 8.

DKNF

Uma outra forma normal reconhecida é a Domain-Key Normal Form (DKNF) que, partindo da 5NF, se caracteriza adicionalmente pela ausência de qualquer dependência de valores de domínio, ou seja de valores possíveis para um atributo em relação a outros atributos (Halpin & Morgan, 2008). Como neste caso não está prevista nenhuma dependência desse tipo, o modelo também já se encontra em DKNF.

6NF

Encontrando-se uma tabela em DKNF e não existindo dimensão temporal, também se encontra automaticamente por definição na 6ª Forma Normal 6NF (Knowles, 2012).

Esta forma, a mais avançada, é mais controversa, não goza de total aceitação, e é muito raramente utilizada (Rainardi, 2008), a não ser no contexto de conceitos como Data Warehousing 2.0 (DW 2.0), Anchor Modeling e outros de nova geração que preconizam DW extremamente fragmentadas e totalmente temporalizadas (Knowles, 2012).

Note-se que, habitualmente no contexto empresarial, considera-se uma base de dados normalizada desde que respeite a 3NF (Connolly & Begg, 2005), sendo as formas mais sofisticadas pouco conhecidas ou entendidas, e raramente utilizadas.

DIM Supervisor AlinhGeo DIM Supervisor Supervisor Linha DIM Zona DIM 040 CR 007 CR 007 Linha 2 DIM 009 Zona400 DIM 038 CR 005 CR 005 Linha 2 DIM 010 Zona410 DIM 117 CR 029 CR 029 Linha 10 DIM 038 Zona400 DIM 116 CR 027 CR 027 Linha 10 DIM 040 Zona410 DIM 044 CR 008 CR 008 Linha 3 DIM 044 Zona400 DIM 009 CR 004 CR 004 Linha 1 DIM 044 Zona410 DIM 010 CR 004 CR 019 Linha 7 DIM 084 Zona400 DIM 084 CR 019 CR 023 Linha 8 DIM 084 Zona410 DIM 106 CR 023 DIM 105 Zona410 DIM 105 CR 023 Linha DIM 106 Zona400 Linha Empresa DIM 116 Zona400 Linha 2 NossaEmpresa1 DIM 117 Zona410 Linha 10 NossaEmpresa1 Visitas Linha 3 NossaEmpresa1 Produto Zona DIM Visitas Linha 1 NossaEmpresa2 Produto 2337 Zona400 DIM 038 17 Linha 7 NossaEmpresa2 Produto 2337 Zona400 DIM 044 8 Linha 8 NossaEmpresa2 Produto 2337 Zona400 DIM 116 21 Produto 2337 Zona410 DIM 040 13 Produto 2337 Zona410 DIM 044 14 Produto Zona Produto 2337 Zona410 DIM 117 26 Produto Empresa Zona Produto 2535 Zona400 DIM 009 18 Produto 2337 NossaEmpresa1 Zona400 Produto 2535 Zona400 DIM 084 21 Produto 2535 NossaEmpresa2 Zona410 Produto 2535 Zona400 DIM 106 15 Produto 2542 NossaEmpresa2 Produto 2535 Zona410 DIM 010 9 Produto 2535 Zona410 DIM 084 18 Empresa Vendas Produto 2535 Zona410 DIM 105 28 Empresa Produto Zona Vendas Produto 2542 Zona400 DIM 009 12 NossaEmpresa1 Produto 2337 Zona400 500 Produto 2542 Zona400 DIM 084 9 NossaEmpresa2 Produto 2337 Zona410 2000 Produto 2542 Zona400 DIM 106 13 Produto 2535 Zona400 3300 Produto 2542 Zona410 DIM 010 28 Produto 2535 Zona410 7000 Produto 2542 Zona410 DIM 084 14 Produto 2542 Zona400 670 Produto 2542 Zona410 DIM 105 18 Produto 2542 Zona410 1600 Empresa

Linha

AlinhGeo Supervisor

Produto Zona DIM

Vendas

Visitas

Figura 8. 4NF / 5NF / DKNF / 6NF.

2.3.4.4. Temporalidade

Para além de apenas armazenar informação relativa a um único instante, um DW, deverá, por definição, constituir um repositório de dados históricos, com identificação do respectivo período de validade, respondendo a uma necessidade de análise de negócio cada vez maior (Inmon, 2005; Johnston & Weis, 2010).

Trata-se da questão da temporalidade em bases de dados que representa um desafio passível de ser resolvido de diversas maneiras (Johnston & Weis, 2010; Silberschatz et al., 2011), usando intervalos de períodos ou períodos isolados, e podendo-se temporalizar parte ou toda a base de dados (Date, Darwen, & Lorentzos, 2003).

Vamos escolher uma abordagem simples e simultaneamente abrangente para temporalizar a forma mais normalizada, da Figura 8, acrescentando um atributo temporal representando o mês de igual modo em todas as tabelas, obtendo a Figura 9. Desta forma salvaguardamos o histórico de negócio tanto de entidades como de associações, conseguindo um modelo monotemporal (Johnston & Weis, 2010).

Ao ter acrescentado o mês à chave existente em todas as tabelas, as associações entre estas continuam a fazer-se do mesmo modo por conexão de chaves, apenas evoluindo o esquema ER da Figura 8 pela inclusão da tabela temporal.

2.3.4.5. Modelo dimensional

Até agora, pudemos observar a variedade de formas com que se podem organizar os dados representativos de uma mesma realidade, mesmo num caso simples como o do exemplo utilizado. Tal possibilidade, verificada dentro dum único modelo – o relacional - potencia o risco e a dificuldade de consenso na tomada de decisões de arquitectura, e é um obstáculo à compatibilidade entre sistemas, afastando-nos do ideal da investigação.

DIM Supervisor AlinhamentoGeo Tempo DIM CR Tempo Supervisor Linha Tempo DIM Zona Mar-12 DIM 040 CR 007 Mar-12 CR 007 Linha 2 Mar-12 DIM 009 Zona400 Mar-12 DIM 038 CR 005 Mar-12 CR 005 Linha 2 Mar-12 DIM 010 Zona410 Mar-12 DIM 117 CR 029 Mar-12 CR 029 Linha 10 Mar-12 DIM 038 Zona400 Mar-12 DIM 116 CR 027 Mar-12 CR 027 Linha 10 Mar-12 DIM 040 Zona410 Mar-12 DIM 044 CR 008 Mar-12 CR 008 Linha 3 Mar-12 DIM 044 Zona400 Mar-12 DIM 009 CR 004 Mar-12 CR 004 Linha 1 Mar-12 DIM 044 Zona410 Mar-12 DIM 010 CR 004 Mar-12 CR 019 Linha 7 Mar-12 DIM 084 Zona400 Mar-12 DIM 084 CR 019 Mar-12 CR 023 Linha 8 Mar-12 DIM 084 Zona410 Mar-12 DIM 106 CR 023 Abr-12 CR 007 Linha 1 Mar-12 DIM 105 Zona410 Mar-12 DIM 105 CR 023 Abr-12 CR 005 Linha 1 Mar-12 DIM 106 Zona400 Abr-12 DIM 040 CR 007 Abr-12 CR 029 Linha 10 Mar-12 DIM 116 Zona400 Abr-12 DIM 038 CR 005 Abr-12 CR 027 Linha 10 Mar-12 DIM 117 Zona410 Abr-12 DIM 117 CR 029 Abr-12 CR 004 Linha 1 Abr-12 DIM 009 Zona400 Abr-12 DIM 116 CR 027 Abr-12 CR 019 Linha 7 Abr-12 DIM 010 Zona410 Abr-12 DIM 044 CR 004 Abr-12 CR 023 Linha 8 Abr-12 DIM 038 Zona400 Abr-12 DIM 009 CR 004 Abr-12 DIM 040 Zona410 Abr-12 DIM 010 CR 004 Linha Abr-12 DIM 044 Zona400 Abr-12 DIM 084 CR 019 Tempo Linha Empresa Abr-12 DIM 084 Zona400 Abr-12 DIM 106 CR 023 Mar-12 Linha 2 NossaEmpresa1 Abr-12 DIM 084 Zona410 Abr-12 DIM 105 CR 023 Mar-12 Linha 10 NossaEmpresa1 Abr-12 DIM 105 Zona410 Mar-12 Linha 3 NossaEmpresa1 Abr-12 DIM 106 Zona400 Mar-12 Linha 1 NossaEmpresa2 Abr-12 DIM 116 Zona400 Mar-12 Linha 7 NossaEmpresa2 Abr-12 DIM 117 Zona410 Visitas Mar-12 Linha 8 NossaEmpresa2 Tempo Produto Zona DIM Visitas Abr-12 Linha 10 NossaEmpresa1 Zona Mar-12 Produto 2337 Zona400 DIM 038 17 Abr-12 Linha 1 NossaEmpresa2 Tempo Zona Tempo Mar-12 Produto 2337 Zona400 DIM 044 8 Abr-12 Linha 7 NossaEmpresa2 Mar-12 Zona400 Tempo Mar-12 Produto 2337 Zona400 DIM 116 21 Abr-12 Linha 8 NossaEmpresa2 Mar-12 Zona410 Mar-12 Mar-12 Produto 2337 Zona410 DIM 040 13 Abr-12 Zona400 Abr-12 Mar-12 Produto 2337 Zona410 DIM 044 14 Produto Abr-12 Zona410 Mar-12 Produto 2337 Zona410 DIM 117 26 Tempo Produto Empresa Mar-12 Produto 2535 Zona400 DIM 009 18 Mar-12 Produto 2337 NossaEmpresa1 Vendas Mar-12 Produto 2535 Zona400 DIM 084 21 Mar-12 Produto 2535 NossaEmpresa2 Tempo Produto Zona Vendas Mar-12 Produto 2535 Zona400 DIM 106 15 Mar-12 Produto 2542 NossaEmpresa2 Mar-12 Produto 2337 Zona400 500 Mar-12 Produto 2535 Zona410 DIM 010 9 Abr-12 Produto 2337 NossaEmpresa1 Mar-12 Produto 2337 Zona410 2000 Mar-12 Produto 2535 Zona410 DIM 084 18 Abr-12 Produto 2535 NossaEmpresa2 Mar-12 Produto 2535 Zona400 3300 Mar-12 Produto 2535 Zona410 DIM 105 28 Mar-12 Produto 2535 Zona410 7000 Mar-12 Produto 2542 Zona400 DIM 009 12 Empresa Mar-12 Produto 2542 Zona400 670 Mar-12 Produto 2542 Zona400 DIM 084 9 Tempo Empresa Mar-12 Produto 2542 Zona410 1600 Mar-12 Produto 2542 Zona400 DIM 106 13 Mar-12 NossaEmpresa1 Abr-12 Produto 2337 Zona400 500 Mar-12 Produto 2542 Zona410 DIM 010 28 Mar-12 NossaEmpresa2 Abr-12 Produto 2337 Zona410 2000 Mar-12 Produto 2542 Zona410 DIM 084 14 Abr-12 NossaEmpresa1 Abr-12 Produto 2535 Zona400 3300 Mar-12 Produto 2542 Zona410 DIM 105 18 Abr-12 NossaEmpresa2 Abr-12 Produto 2535 Zona410 7000 Abr-12 Produto 2337 Zona400 DIM 038 17 Abr-12 Produto 2337 Zona400 DIM 044 8 Abr-12 Produto 2337 Zona400 DIM 116 21 Abr-12 Produto 2337 Zona410 DIM 040 13 Abr-12 Produto 2337 Zona410 DIM 117 26 Abr-12 Produto 2535 Zona400 DIM 009 18 Tempo Abr-12 Produto 2535 Zona400 DIM 084 21 Abr-12 Produto 2535 Zona400 DIM 106 15 Abr-12 Produto 2535 Zona410 DIM 010 9 Empresa Linha Abr-12 Produto 2535 Zona410 DIM 084 18 Abr-12 Produto 2535 Zona410 DIM 105 28 AlinhGeo Supervisor

Produto Zona DIM

Vendas

Visitas

Figura 9. Modelo relacional monotemporal.

No entanto, a normalização oferece uma orientação e uma forma determinística de chegar a um modelo relacional óptimo, como demonstrou Bernstein (1976) desenvolvendo um algoritmo de determinação das tabelas em número mínimo que satisfazem a 3NF, dado um conjunto de dependências funcionais. Logo, o modelo relacional é uma plataforma capaz de gerar consenso nas suas implementações desde que estas obedeçam a regras formais estritas.

Não obstante, Kimball (1997) em “A Dimensional Modeling Manifesto” prefere enfatizar a variabilidade intrínseca ao modelo relacional para o contrapor ao modelo que defende para análise a dados, o modelo dimensional. Embora referindo-se marginalmente a tecnologia proprietária, propõe uma definição do modelo dimensional baseada inteiramente em tabelas do modelo relacional, ou seja, fundamentalmente prescreve um standard de regras de implementação do modelo relacional: uma tabela de factos, com chaves a apontarem para tabelas de dimensões desnormalizadas, ou seja o esquema em estrela ou Star Schema (Figura 10) (Golfarelli, 2008).

Evitando repetir as tabelas de dimensões comuns aos dois tipos de factos (“conformed dimensions”), e ligando os factos entre si, obtém-se a evolução Constellation (Figura 11) do modelo Star. Outra variante é a Star Cluster, onde se define uma tabela adicional relativa a uma subdimensão partilhada (Figura 12) no âmbito de um mesmo Facto. Ambos os conceitos estão representados na Figura 13.

Kimball (1997) consegue afortunadamente justificar o modelo Star com base em fundamentos conceptuais e físicos ao mesmo tempo, raramente alinhados mas neste caso coincidentes: . o modelo, por estar simplificado, é mais perceptível aos utilizadores, e . simultaneamente o modelo permite optimizar as consultas por não necessitar de ligações (joins) encadeadas entre tabelas.

Considerando o segundo argumento como consensual na literatura e comprovado na prática, já o primeiro nos parece em grande parte suportado pela forma como o autor apresenta o modelo relacional como sendo o de toda a empresa, contrapondo-o à simplicidade de modelos Star organizados cada um em torno de uma tabela de factos (“Data Marts”).

DIM Tempo DIM Supervisor Linha Empresa Tempo DIM 040 CR 007 Linha 2 NossaEmpresa1 Mar-12 DIM 038 CR 005 Linha 2 NossaEmpresa1 Abr-12 DIM 117 CR 029 Linha 10 NossaEmpresa1 DIM 116 CR 027 Linha 10 NossaEmpresa1 DIM 044 CR 008 Linha 3 NossaEmpresa1 DIM 009 CR 004 Linha 1 NossaEmpresa2 DIM 010 CR 004 Linha 1 NossaEmpresa2 DIM 084 CR 019 Linha 7 NossaEmpresa2 DIM 106 CR 023 Linha 8 NossaEmpresa2 DIM 105 CR 023 Linha 8 NossaEmpresa2

Visitas Tempo Produto Zona DIM Visitas Mar-12 Produto 2337 Zona400 DIM 038 17 Mar-12 Produto 2337 Zona400 DIM 044 8 Mar-12 Produto 2337 Zona400 DIM 116 21 Mar-12 Produto 2337 Zona410 DIM 040 13 Mar-12 Produto 2337 Zona410 DIM 044 14 Mar-12 Produto 2337 Zona410 DIM 117 26 Mar-12 Produto 2535 Zona400 DIM 009 18 Mar-12 Produto 2535 Zona400 DIM 084 21 Produto Zona Mar-12 Produto 2535 Zona400 DIM 106 15 Produto Empresa Zona Mar-12 Produto 2535 Zona410 DIM 010 9 Produto 2337 NossaEmpresa1 Zona400 Mar-12 Produto 2535 Zona410 DIM 084 18 Produto 2535 NossaEmpresa2 Zona410 Mar-12 Produto 2535 Zona410 DIM 105 28 Produto 2542 NossaEmpresa2 Mar-12 Produto 2542 Zona400 DIM 009 12 Mar-12 Produto 2542 Zona400 DIM 084 9 Mar-12 Produto 2542 Zona400 DIM 106 13 Mar-12 Produto 2542 Zona410 DIM 010 28 Mar-12 Produto 2542 Zona410 DIM 084 14 Mar-12 Produto 2542 Zona410 DIM 105 18 Vendas Abr-12 Produto 2337 Zona400 DIM 038 17 Tempo Produto Zona Vendas Abr-12 Produto 2337 Zona400 DIM 044 8 Mar-12 Produto 2337 Zona400 500 Abr-12 Produto 2337 Zona400 DIM 116 21 Mar-12 Produto 2337 Zona410 2000 Abr-12 Produto 2337 Zona410 DIM 040 13 Mar-12 Produto 2535 Zona400 3300 Abr-12 Produto 2337 Zona410 DIM 117 26 Mar-12 Produto 2535 Zona410 7000 Abr-12 Produto 2535 Zona400 DIM 009 18 Mar-12 Produto 2542 Zona400 670 Abr-12 Produto 2535 Zona400 DIM 084 21 Mar-12 Produto 2542 Zona410 1600 Abr-12 Produto 2535 Zona400 DIM 106 15 Abr-12 Produto 2337 Zona400 500 Abr-12 Produto 2535 Zona410 DIM 010 9 Abr-12 Produto 2337 Zona410 2000 Abr-12 Produto 2535 Zona410 DIM 084 18 Abr-12 Produto 2535 Zona400 3300 Abr-12 Produto 2535 Zona410 DIM 105 28 Abr-12 Produto 2535 Zona410 7000

Zona Zona

Produto Produto Tempo Tempo

Visitas Vendas DIM Figura 10. Modelo dimensional Star.

Zona Produto

DIM Tempo Vendas

Visitas

Figura 11. Modelo dimensional Constellation.

Visitas Tempo Produto Zona DIM Visitas Empresa Mar-12 Produto 2337 Zona400 DIM 038 17 Empresa Mar-12 Produto 2337 Zona400 DIM 044 8 NossaEmpresa1 Mar-12 Produto 2337 Zona400 DIM 116 21 NossaEmpresa2 Mar-12 Produto 2337 Zona410 DIM 040 13 Mar-12 Produto 2337 Zona410 DIM 044 14 Mar-12 Produto 2337 Zona410 DIM 117 26 Mar-12 Produto 2535 Zona400 DIM 009 18 Mar-12 Produto 2535 Zona400 DIM 084 21 Produto Zona Mar-12 Produto 2535 Zona400 DIM 106 15 Produto Empresa Zona Mar-12 Produto 2535 Zona410 DIM 010 9 Produto 2337 NossaEmpresa1 Zona400 Mar-12 Produto 2535 Zona410 DIM 084 18 Produto 2535 NossaEmpresa2 Zona410 Mar-12 Produto 2535 Zona410 DIM 105 28 Produto 2542 NossaEmpresa2 Mar-12 Produto 2542 Zona400 DIM 009 12 Mar-12 Produto 2542 Zona400 DIM 084 9 Mar-12 Produto 2542 Zona400 DIM 106 13 Mar-12 Produto 2542 Zona410 DIM 010 28 Mar-12 Produto 2542 Zona410 DIM 084 14 Mar-12 Produto 2542 Zona410 DIM 105 18 Vendas Abr-12 Produto 2337 Zona400 DIM 038 17 Tempo Produto Zona Vendas Abr-12 Produto 2337 Zona400 DIM 044 8 Mar-12 Produto 2337 Zona400 500 Abr-12 Produto 2337 Zona400 DIM 116 21 Mar-12 Produto 2337 Zona410 2000 Abr-12 Produto 2337 Zona410 DIM 040 13 Mar-12 Produto 2535 Zona400 3300 Abr-12 Produto 2337 Zona410 DIM 117 26 Mar-12 Produto 2535 Zona410 7000 Abr-12 Produto 2535 Zona400 DIM 009 18 Mar-12 Produto 2542 Zona400 670 Abr-12 Produto 2535 Zona400 DIM 084 21 Mar-12 Produto 2542 Zona410 1600 Abr-12 Produto 2535 Zona400 DIM 106 15 Abr-12 Produto 2337 Zona400 500 Abr-12 Produto 2535 Zona410 DIM 010 9 Abr-12 Produto 2337 Zona410 2000 Abr-12 Produto 2535 Zona410 DIM 084 18 Abr-12 Produto 2535 Zona400 3300 Abr-12 Produto 2535 Zona410 DIM 105 28 Abr-12 Produto 2535 Zona410 7000

Zona Zona

Produto Produto Tempo Tempo Empresa

Visitas Vendas DIM

Figura 12. Modelo dimensional Star Cluster.

Empresa

Produto Zona

DIM Tempo Vendas

Visitas Figura 13. Modelo dimensional Constellation Cluster.

Se concedermos também ao modelo relacional a capacidade de se subdividir (ou usarmos a configuração dimensional Constellation para toda a empresa), a diferença do modelo relacional para o dimensional é apenas de as dimensões associadas hierarquicamente passarem de tabelas distintas para tabelas únicas (Figura 14) (Bouman & Dongen, 2009). E no caso do modelo dimensional Snowflake (Vassiliadis & Sellis, 1999), o conceito geralmente percebido acaba por ser idêntico ao do modelo relacional - embora Kimball (1997) previsse com esta designação um Star re- normalizado com tabelas adicionais apenas para dimensões de cardinalidade baixa.

Kimball (1997) defende também como vantagem do modelo Star este constituir uma estrutura standard e previsível, permitindo acomodação fácil a alterações à estrutura ou necessidades, e resposta simétrica a pedidos diferentes de consultas, capacidades que interessam à nossa investigação.

No entanto, questionamos a medida em que tal pode ser conseguido, pois permanece, tal como no modelo relacional, a necessidade de alterar e criar tabelas, nomeadamente:

. criação de campo adicional na tabela de factos para cada nova métrica, . criação de nova tabela de dimensões para um conjunto novo de dimensões hierarquicamente associadas, e . criação de novo campo em tabela de dimensões existente, para um novo nível hierárquico.

Também não é claro como conseguir consultas mais generalizáveis do que no modelo relacional normalizado, pois continua a ser necessário endereçar explicitamente o nome de cada tabela e campo relevante.

O artigo de Kimball (1997), longe de apresentar rigor científico, foi escrito como uma defesa da legitimidade da utilização de dados desnormalizados (contrariando as regras estabelecidas para o modelo relacional), constatando uma prática já então estabelecida em DW.

Tempo DIM Supervisor Tempo DIM Supervisor Supervisor Linha Mar-12 DIM 040 CR 007 CR 007 Linha 2 Abr-12 DIM 038 CR 005 CR 005 Linha 2 DIM 117 CR 029 CR 029 Linha 10 DIM 116 CR 027 CR 027 Linha 10 DIM 044 CR 008 CR 008 Linha 3 DIM 009 CR 004 CR 004 Linha 1 DIM 010 CR 004 CR 019 Linha 7 DIM 084 CR 019 CR 023 Linha 8 DIM 106 CR 023 DIM 105 CR 023

Visitas Linha Tempo Produto Zona DIM Visitas Linha Empresa Mar-12 Produto 2337 Zona400 DIM 038 17 Linha 2 NossaEmpresa1 Mar-12 Produto 2337 Zona400 DIM 044 8 Linha 10 NossaEmpresa1 Mar-12 Produto 2337 Zona400 DIM 116 21 Linha 3 NossaEmpresa1 Mar-12 Produto 2337 Zona410 DIM 040 13 Linha 1 NossaEmpresa2 Mar-12 Produto 2337 Zona410 DIM 044 14 Linha 7 NossaEmpresa2 Mar-12 Produto 2337 Zona410 DIM 117 26 Linha 8 NossaEmpresa2 Mar-12 Produto 2535 Zona400 DIM 009 18 Mar-12 Produto 2535 Zona400 DIM 084 21 Mar-12 Produto 2535 Zona400 DIM 106 15 Produto Zona Mar-12 Produto 2535 Zona410 DIM 010 9 Produto Empresa Zona Mar-12 Produto 2535 Zona410 DIM 084 18 Produto 2337 NossaEmpresa1 Zona400 Mar-12 Produto 2535 Zona410 DIM 105 28 Produto 2535 NossaEmpresa2 Zona410 Mar-12 Produto 2542 Zona400 DIM 009 12 Produto 2542 NossaEmpresa2 Mar-12 Produto 2542 Zona400 DIM 084 9 Mar-12 Produto 2542 Zona400 DIM 106 13 Mar-12 Produto 2542 Zona410 DIM 010 28 Mar-12 Produto 2542 Zona410 DIM 084 14 Mar-12 Produto 2542 Zona410 DIM 105 18 Empresa Vendas Abr-12 Produto 2337 Zona400 DIM 038 17 Empresa Tempo Produto Zona Vendas Abr-12 Produto 2337 Zona400 DIM 044 8 NossaEmpresa1 Mar-12 Produto 2337 Zona400 500 Abr-12 Produto 2337 Zona400 DIM 116 21 NossaEmpresa2 Mar-12 Produto 2337 Zona410 2000 Abr-12 Produto 2337 Zona410 DIM 040 13 Mar-12 Produto 2535 Zona400 3300 Abr-12 Produto 2337 Zona410 DIM 117 26 Mar-12 Produto 2535 Zona410 7000 Abr-12 Produto 2535 Zona400 DIM 009 18 Mar-12 Produto 2542 Zona400 670 Abr-12 Produto 2535 Zona400 DIM 084 21 Mar-12 Produto 2542 Zona410 1600 Abr-12 Produto 2535 Zona400 DIM 106 15 Abr-12 Produto 2337 Zona400 500 Abr-12 Produto 2535 Zona410 DIM 010 9 Abr-12 Produto 2337 Zona410 2000 Abr-12 Produto 2535 Zona410 DIM 084 18 Abr-12 Produto 2535 Zona400 3300 Abr-12 Produto 2535 Zona410 DIM 105 28 Abr-12 Produto 2535 Zona410 7000

Empresa

Zona Zona Empresa

Linha

Produto Produto

Tempo Tempo

Supervisor

Visitas Vendas DIM

Figura 14. Modelo dimensional Snowflake.

Tal prática reflecte a necessidade de separação, nas organizações, entre sistemas operacionais (OLTP), que asseguram o funcionamento diário do negócio, e sistemas de análise (OLAP). Em OLTP, as transacções consistem essencialmente em entrada de dados, ao passso que em OLAP, o objectivo é retirar informação estratégica; logo os dois sistemas apresentam objectivos, âmbitos, conteúdo, padrões de utilização e tipos de acesso diferentes (French, 1995; Ponniah, 2001), como mostra a Tabela 1.

Como tal, tornou-se consensual os DW necessitarem de uma modelação de dados própria (Corr & Stagnitto, 2012), e esta consistir na perspectiva conceptual intuitiva para o utilizador de que o que caracteriza qualquer negócio pode ser sempre generalizável da seguinte forma (Golfarelli, Rizzi, & Biondi, 2011):

. existem várias dimensões (ex: produto, cliente, região, tempo) . com vários níveis de agregação (hierarquias); e . na confluência de uma ou mais dimensões, ocorrem factos . mensuráveis ou calculáveis (métricas); . podendo-se analisar os valores das métricas, agregadas ou detalhadas a qualquer nível de qualquer dimensão, isolado ou em combinação com outros níveis de outras dimensões

OLTP OLAP Conteúdo dos dados corrente resumido, agregado, calculado, histórico Tipo de operações transacções consultas complexas suportadas Frequência de acesso elevada média-baixa Tipo de acesso leitura e escrita Leitura Utilização previsível, repetitiva ad-hoc, aleatória Tempo de resposta Inferior ao segundo segundos a minutos Número de utilizadores elevado Reduzido

Tabela 1. OLTP vs OLAP (Ponniah, 2001)

Para além do OLAP dever permitir seleccionar ilimitadamente o que se deseja analisar (dimensões, níveis, métricas) através de menus e/ou caixas de selecção, também é consensual que deva facultar ao utilizador uma forma intuitiva de navegar sobre a informação, como por exemplo ao clicar numa bolha dum gráfico, ter acesso a um novo gráfico com o respectivo detalhe esperado (desagregação ou drill-down), ou a operação inversa, de agregação (roll-up) (Codd, Codd & Salley, 1993; Vassiliadis & Sellis, 1999).

No entanto, existe pouco consenso quanto a terminologia e base semântica de um modelo multidimensional, limitando-se essencialmente à seguinte classificação da arquitectura OLAP de acordo com a tecnologia que a indústria de software tem vindo a desenvolver (Thomsen, 2002):

. ROLAP (OLAP relacional), . MOLAP (OLAP multidimensional) e . HOLAP (OLAP híbrido).

Em ROLAP, os dados são implementados numa estrutura relacional, modelados em Star ou Snowflake, sendo este último a normalização do primeiro (Vassiliadis & Sellis, 1999) como referido anteriormente.

Em MOLAP, os dados são convertidos internamente num formato assimilável a uma folha de cálculo multidimensional gigante, em tecnologia proprietária, com desempenho habitualmente superior pois já traz grande parte das agregações possíveis pré-calculadas. No entanto, o MOLAP é mais difícil de actualizar e administrar (Vassiliadis & Sellis, 1999).

Em HOLAP, os dados elementares (aos níveis mais baixos das hierarquias) são armazenados em tabelas relacionais e só os dados agregados é que ficam em estruturas MOLAP (Halpin & Morgan, 2008).

A nível de esforços académicos quanto à caracterização de um modelo dimensional, estes dividem-se em extensões ao modelo relacional (elaborando sobre o conceito de tabelas), e outros cuja abordagem parte directamente do conceito

intuitivo de cubo acima referido. No entanto, mesmo estes não se distanciam muito do modelo relacional, podendo ser-lhe directamente mapeados (Vassiliadis & Sellis, 1999).

Apesar de alguma investigação académica já efectuada em modelação de DW, não existe ainda nenhum consenso quanto a um método de desenho, nem nenhum modelo OLAP geralmente aceite (Thomsen, 2002), e novas necessidades como a de BI em tempo real entretanto surgiram, que já não se enquadram nos pressupostos tradicionais dos processos de DW. Por estas razões, a área de data warehousing, incluindo a modelação dimensional, continua a necessitar de investigação e novas abordagens (Rizzi, Abellò, Lechtenbörger, & Trujillo, 2006).

Em suma, da tecnologia e processos actualmente existentes em modelos multidimensionais, retiramos para os fins da nossa investigação, os seguintes pontos:

. Em geral e por princípio, um sistema anunciado actualmente como OLAP é uma opção dispendiosa, pois quase sempre representa um acrescento a um sistema relacional (Kimball & Ross, 2010).

. Um cubo OLAP requer sempre passos de administração e manutenção adicionais aos que têm de ser efectuados na base de dados relacional, envolvendo tempos acrescidos de desenvolvimento e carregamento, e especialização de tarefas, o que à partida e só por si, inviabiliza o nosso interesse por esta via.

. As vantagens em termos de desempenho são questionáveis em MOLAP (Thomsen, 2002), e os sistemas OLAP em geral não têm apresentado o mesmo grau de escalabilidade dos relacionais (Kimball & Ross, 2010).

. Os processos de actualização e administração de MDBMS apresentam mais dificuldade que em RDBMS (Vassiliadis & Sellis, 1999).

. Em ROLAP, espaço em disco será gasto com a agregação de dados, da mesma forma que ocorre se esta for efectuada no modelo relacional simples (Thomsen, 2002).

. Os modelos OLAP por si só não implicam uma navegação automatizada ou facilitada para o utilizador, esta dependendo sempre de aplicações ou interfaces aplicacionais (API) que trazem essa funcionalidade (que pode teoricamente ser implementada tanto em modelos relacionais como outros).

. A única linguagem que pode ser considerada um standard “de facto”, o MDX (Golfarelli et al., 2012), não é ideal (Thomsen, 2002) e pode tornar o desenvolvimento de aplicações mais complexo (Halpin & Morgan, 2008; Vassiliadis & Sellis, 1999).

. Em termos de puro modelo lógico, o modelo dimensional habitualmente considerado na prática, resume-se a apenas algumas configurações simples (Star sobretudo) de entre as várias possíveis no modelo relacional, carecendo de originalidade e de fundamentação teórica.

Concluímos então, das considerações acima e de todas as configurações que investigámos até agora dos modelos relacional e dimensional - os mais utilizados na prática em combinação OLTP/OLAP (Corr & Stagnitto, 2012) - que nenhuma oferece a independência que desejamos em relação à estrutura e às necessidades do negócio, frustrando as expectativas anunciadas quer quanto ao modelo relacional de “libertar os utilizadores da tarefa frustrante de lidar com os pormenores de representação do armazenamento de dados” (Codd, 1979), quer quanto ao modelo dimensional de “acomodar novos e imprevistos elementos de dados e novas decisões de design” (Kimball, 1997).

Por outro lado, a possibilidade de se poder optar por tamanha diversidade de configurações possíveis, incluindo combinações híbridas num mesmo DW, é potencialmente geradora de controvérsia (Codd, 1990; Watson & Ariyachandra, 2005) e ruído, o que prejudica os processos incontornáveis de adaptação do modelo de dados.

Passamos então a rever, para além dos modelos já analisados, outros conceitos com potencial para agilização.

2.3.5. Outras Abordagens

2.3.5.1. Bases de dados baseadas em objectos

Considera-se como terceira geração de DBMS os que apresentam uma lógica baseada em objectos: Object-Relational (ORDBMS) e Object-Oriented (OODBMS).

Ambos surgem como uma tentativa de reunir numa só modelação as estruturas estáticas de dados e os processos dinâmicos, tradicionalmente separados, e de simultaneamente permitir maior flexibilidade que o modelo relacional, escapando da sua estrutura homogénea, desnormalizando com controlo ao permitir por exempo um número de atributos variável conforme a instância.

A ideia de juntar código encapsulado aos dados vem assim teoricamente endereçar as seguintes limitações apontadas ao modelo relacional (Connolly & Begg, 2005):

. estrutura de dados homogénea; . fraca representação de entidades reais; . limitação semântica; . fraco suporte a protecção de integridade e política de acessos; . operações limitadas; . problema da recursividade pouco eficiente das consultas; . e problemas implicados por alterações de estrutura.

Os OODBMS, que se apresentam como alternativa radical aos RDBMS, facilitam teoricamente a manutenção e a evolução de bases de dados; no entanto a sua concretização traduz-se ainda em sistemas demasiado complexos, não padronizados e experimentais, acabando por ser mais caros e difíceis de operar que as alternativas comuns (Connolly & Begg, 2005).

Já no caso dum ORDBMS, a filosofia não é rejeitar a base relacional que contitui um RDBMS, mas potenciá-la, essencialmente através de extensões à linguagem SQL, sem perder o investimento e trabalho efectuados. No entanto este sistema traduz-se na complexidade e custo operativo acumulados de um RDBMS e da componente objecto.

Apesar de teoricamente poderem proporcionar um grau elevado de abstracção e versatilidade, na prática ambos os sistemas OODMS e ORDBMS ainda apresentam complexidade e custos acrescidos em relação aos RDBMS, o que retira interesse em prosseguir investigação nesta área no âmbito da nossa investigação.

2.3.5.2. Schema integration, Schema evolution e Schema versioning

A investigação em Schema evolution e Schema versioning procura reduzir os efeitos de alterações ao esquema de dados sobre os sistemas de software (Roddick & De Vries, 2006), objectivo alinhado com o da presente investigação.

Schema versioning preocupa-se adicionalmente em guardar versões de várias evoluções da base de dados para poderem ser reutilizadas. Com Schema versioning, o objectivo é conseguir uma visão única dos dados sobre esquemas diferentes, ao qual é frequentemente associado o interesse simétrico, de procurar, com base em várias visões desejadas, um esquema comum (Schema integration).

Desde 1987, a investigação nesta área tem sido regular, subdividindo-se em três linhas gerais - os 3 R’s (Roddick & De Vries, 2006): . Reduzir: procurar reduzir a quantidade de alterações necessárias ao esquema por incorporar nos modelos conceptual e lógico a capacidade de acomodar alterações a definições. . Reutilizar: reutilizar definições anteriores, e dados associados, através de mecanismos de conversão, como camadas (layers e wrappers). . Reciclar: facilitar a integração e a evolução, através de coerção de dados.

Uma abordagem de redução é o conceito de mesodata (La-Ongsri, Roddick, & De Vries, 2008), que acrescenta ao modelo relacional a faculdade de definir domínios de atributos com base em outros atributos e estruturas complexas de dados, enquanto mantém o tipo de dados. Acomoda uma alteração de classificação, mas não a introdução ou destruição de campos e tabelas, problema subjacente à nossa investigação.

A abordagem de reutilização efectua-se através de mecanismos de interface requerendo algoritmos, geralmente orientados a objectos.

No caso da coerção de dados, advoga-se a transformação dos próprios dados para o novo formato válido, com perda intencional de histórico.

Qualquer das três estratégias em Schema integration, evolution e versioning está longe de estar totalmente investigada, podendo representar uma via futura para estudo sobre o nosso problema de investigação. No entanto, as soluções existentes em geral requerem intervenção manual, são incompletas, aplicam-se a casos muito específicos e requerem um modelo de dados orientado a objectos (Roddick & De Vries, 2006), implicando a inadequação da sua aplicação imediata à nossa investigação.

2.3.5.3. Schema matching genérico

Schema matching é uma operação que consiste em mapear elementos, habitualmente de forma manual, entre duas estruturas diferentes, ou com representações diferentes, como entre as fontes de dados e o DW, e em qualquer caso de necessidade de integração de dados. Peukert, Eberius, e Rahm (2012) propõem um sistema auto-configurável para efectuar esta operação automaticamente em diversos domínios de aplicação e modelos de dados.

Apresentando interesse para facilitar a parte inicial do processo de ETL, na automatização da leitura e extracção das fontes independentemente do seu formato, esta abordagem eventualmente poderá constituir uma via de investigação para identificar alterações à própria estrutura do negócio permitindo importar

directamente as novas definições para dentro do DW, o que constituiria uma abordagem possível para contornar o problema identificado de rigidez do modelo de dados.

No entanto, não o elimina nem reduz, sendo que o ideal para minimizar o esforço nas operações de ETL seria combinar o mapeamento automático das estruturas-fonte, com a elegância, economia e segurança dum modelo de dados efectivamente genérico, que permanece como o objectivo desta investigação.

2.3.5.4. Row modeling / Entity-Attribute-Value

O tratamento de dados clínicos de pacientes necessita potencialmente registar milhares de indicadores por paciente, embora na maioria dos casos o número de indicadores seja reduzido (Nadkarni & Brandt, 1998).

As bases de dados tradicionais, relacionais, por um lado geralmente não podem exceder um limite máximo de colunas, por outro, seria impraticável acrescentar constantemente tabelas ou campos para acomodar novos casos.

A maioria dos sistemas electrónicos de registo de pacientes (EPRS) resolve o problema utilizando o modelo de representação Entity-Attribute-Value (EAV), também designado por Row modeling, no qual os atributos são tratados como dados, de tal maneira que o acrescento de novos indicadores não implica a reestruturação da base de dados.

Aplicando ao nosso pequeno exemplo, podemos visualizar o conceito convertendo a única tabela que tem vários atributos não-chave, a tabela de Estrutura Organizacional, na tabela DIM da Figura 15, onde podemos claramente observar a pretendida conversão de colunas em linhas.

Note-se que o modelo EAV é muito específico a uma determinada realidade, representada por factos unidimensionais. No caso que usámos, estamos intencionalmente, para fins de ilustração comparativa do conceito, a forçar a utilização do modelo EAV para registar, não valores (factos) mas dimensões associadas,

conseguindo uma nova forma de representação do caso-exemplo, com uma vantagem tendo em conta o nosso objectivo de investigação: se um DIM passar a reportar a uma SBU, por exemplo, deixa de ser necessário alterar a estrutura da base de dados criando uma nova tabela.

Dinu, Nadkarni, e Brandt (2006) estudam duas formas de reverter o formato de uma única coluna do EAV no formato tradicional de atributos por coluna, para permitir o tratamento gráfico e estatístico: . através de SQL estático no caso de um número não excessivamente elevado de atributos; e . utilizando operações de gestão de tabelas directamente na memória RAM.

A primeira abordagem reveste interesse para um potencial aproveitamento simples e elegante de um formato genérico colunar, semelhante ao EAV, por ferramentas de geração de consultas ad-hoc, o que se insere no nosso objectivo de investigação.

A segunda abordagem envolve algoritmos de processamento e tecnologia de hardware, os quais se encontram fora do âmbito da perspectiva pura de modelação de dados que estamos aqui a considerar.

2.3.5.5. Anchor modeling

Rönnbäck et al. (2010a) propõem uma técnica ágil de modelação de dados, Anchor modeling (AM), que permite efectuar extensões ao DW em vez de modificações, ficando sempre disponíveis as versões anteriores, às quais o software existente pode continuar a aceder sem necessitar ser alterado.

Os autores alegam que os modelos Anchor são construídos com base num número reduzido de conceitos, o que, juntamente com guias de orientação, minimiza a introdução de erros. No entanto, são utilizadas 12 definições para entidades e atributos, e 5 guias de orientação, o que nos parece excessivo para um modelo como o que idealizamos, simples e não propício a ambiguidade.

DIM Alinhamento DIM Atributo Empresa DIM Zona Produto DIM 040 Empresa NossaEmpresa1 DIM 009 Zona400 Produto 2535 DIM 038 Empresa NossaEmpresa1 DIM 009 Zona400 Produto 2542 DIM 117 Empresa NossaEmpresa1 DIM 010 Zona410 Produto 2535 DIM 116 Empresa NossaEmpresa1 DIM 010 Zona410 Produto 2542 DIM 044 Empresa NossaEmpresa1 DIM 038 Zona400 Produto 2337 DIM 009 Empresa NossaEmpresa2 DIM 040 Zona410 Produto 2337 DIM 010 Empresa NossaEmpresa2 DIM 044 Zona400 Produto 2337 DIM 084 Empresa NossaEmpresa2 DIM 044 Zona410 Produto 2337 DIM 106 Empresa NossaEmpresa2 DIM 084 Zona400 Produto 2535 DIM 105 Empresa NossaEmpresa2 DIM 084 Zona400 Produto 2542 DIM 040 Linha Linha 2 DIM 084 Zona410 Produto 2535 DIM 038 Linha Linha 2 DIM 084 Zona410 Produto 2542 DIM 117 Linha Linha 10 DIM 105 Zona410 Produto 2535 DIM 116 Linha Linha 10 DIM 105 Zona410 Produto 2542 DIM 044 Linha Linha 3 DIM 106 Zona400 Produto 2535 DIM 009 Linha Linha 1 DIM 106 Zona400 Produto 2542 DIM 010 Linha Linha 1 DIM 116 Zona400 Produto 2337 DIM 084 Linha Linha 7 DIM 117 Zona410 Produto 2337 DIM 106 Linha Linha 8 DIM 105 Linha Linha 8 DIM 040 Supervisor CR 007 Produto Zona DIM 038 Supervisor CR 005 Produto Zona DIM 117 Supervisor CR 029 Produto 2337 Zona400 DIM 116 Supervisor CR 027 Produto 2535 Zona410 DIM 044 Supervisor CR 008 Produto 2542 DIM 009 Supervisor CR 004 DIM 010 Supervisor CR 004 DIM 084 Supervisor CR 019 DIM 106 Supervisor CR 023 DIM 105 Supervisor CR 023

Visitas Vendas Produto Zona DIM Visitas Produto Zona Vendas Produto 2337 Zona400 DIM 038 17 Produto 2337 Zona400 500 Produto 2337 Zona400 DIM 044 8 Produto 2337 Zona410 2000 Produto 2337 Zona400 DIM 116 21 Produto 2535 Zona400 3300 Produto 2337 Zona410 DIM 040 13 Produto 2535 Zona410 7000 Produto 2337 Zona410 DIM 044 14 Produto 2542 Zona400 670 Produto 2337 Zona410 DIM 117 26 Produto 2542 Zona410 1600 Produto 2535 Zona400 DIM 009 18 Produto 2535 Zona400 DIM 084 21 Produto 2535 Zona400 DIM 106 15 Produto 2535 Zona410 DIM 010 9 Produto 2535 Zona410 DIM 084 18 Produto 2535 Zona410 DIM 105 28 Produto 2542 Zona400 DIM 009 12 Produto 2542 Zona400 DIM 084 9 Produto 2542 Zona400 DIM 106 13 Produto 2542 Zona410 DIM 010 28 Produto 2542 Zona410 DIM 084 14 Produto 2542 Zona410 DIM 105 18 Figura 15. Modelo EAV aplicado à entidade DIM a partir da 2NF.

O modelo Anchor é construído sobre os seguintes conceitos:

. Anchor - entidade principal (dimensão ou evento); . Knot - entidade com poucas instâncias fixas e invariáveis com o tempo; . Attribute - propriedade dum Anchor: - Static Attribute - propriedade que não necessita manter histórico de alterações; - Historized Attribute - propriedade que necessita manter histórico; - Knotted static Attribute - propriedade fixa que não necessita manter histórico; - Knotted historized Attribute - propriedade fixa potencialmente variável ao longo do tempo relativamente ao Anchor; . Tie - associação entre dois ou mais Anchors e opcionalmente Knots: - Static Tie - associação que não necessita manter histórico de alterações, não envolvendo Knots; - Historized Tie - associação que necessita manter histórico, não envolvendo Knots; - Knotted Static Tie - associação que não necessita manter histórico de alterações, envolvendo Knots; - Knotted Historized Tie - associação que necessita manter histórico, envolvendo Knots.

Criticamos esta classificação por ser complexa, de apreensão não-imediata, incorporando nuances susceptíveis de gerar discussão e radicalismo de posições (por ventura em maior grau do que actualmente já sucede com os modelos tradicionais), sem, em nossa opinião, necessidade para a análise de negócio.

Aplicando a metodologia recomendada – no nosso caso simples bastando apenas os conceitos de Anchors, Historized Ties e Static Attributes - e utilizando o software Anchor Modeler disponibilizado na web (Rönnbäck & Krumlinde, 2012) aplicamos o modelo ao nosso exemplo (Figura 16), e convertemos para SQL (Figura 17)3, a Figura 18 mostrando, à semelhança dos modelos anteriormente testados e usando nomenclatura semelhante, o conteúdo das tabelas.

3 O software impõe alguma da nomenclatura recomendada para AM.

É interessante, tal como na abordagem EAV, a estratégia de redução do número de colunas, o que evita ineficiências a nível de acesso aos dados, algo que normalmente é contornado com a partição ou fragmentação vertical de tabelas, operação de administração de bases de dados (Bouman & Dongen, 2009; Connolly & Begg, 2005). Com este modelo, tal pode ser simplesmente evitado.

No entanto, o facto de o controlo de versionamento do AM apenas ser conseguido à custa de rotinas em SQL dinâmico, responsáveis pelo acrescento de campos e tabelas, leva a concluir que tal controlo poderia ser igualmente obtido com outro modelo, nomeadamente o relacional normalizado na 3NF, com o qual existe correspondência total conforme os autores demonstram (Rönnbäck, Regardt, Bergholtz, Johannesson, & Wohed, 2010b) e comprovámos utilizando a ferramenta disponibilizada.

Além disso, o excessivo número de tabelas (17) e o facto de não serem suficientemente genéricas, ou seja sendo sempre necessária a criação de uma nova tabela para cada entidade ou evento novo, levam-nos a prosseguir na busca de outra solução.

2.3.5.6. Data Vault

Jovanovic, Bojicic, Knowles, e Pavlic (2012) criticam a modelação AM também pelo excessivo número de conceitos, implicando a necessidade de a priori decidir irreversivelmente que elementos necessitam ou não registar histórico, pela sobrecarga cognitiva da representação dessa separação e do conceito dispensável e arbitrário de Knot, e pela falta de experiência comprovada do modelo na prática, comparativamente à modelação Data Vault (DV), apesar de reconhecerem a equiparação das duas quanto à potencial melhoria do desempenho do DW e quanto à adequação para modelar a área de armazenamento intermédio (staging area), com carácter permanente de acordo com a filosofia de DW de próxima geração DW 2.0 (Inmon, Strauss, & Neushloss, 2008).

Figura 16. Modelo Anchor do exemplo

Figura 17. Modelo Anchor do exemplo convertido em relacional (SQL)

Anchors Historized Ties (2D) Attributes DIM DIM->Supervisor Vendas_Euros

1:n DIM Tempo DIM Supervisor Venda_ID Euros DIM 009 Mar-12 DIM 040 CR 007 VI2337_400_40969 500

Dimensões DIM 010 Mar-12 DIM 038 CR 005 VI2337_400_41000 500 DIM 038 Mar-12 DIM 117 CR 029 VI2337_410_40969 2000 DIM 040 Mar-12 DIM 116 CR 027 VI2337_410_41000 2000 DIM 044 Mar-12 DIM 044 CR 008 VI2535_400_40969 3300 DIM 084 Mar-12 DIM 009 CR 004 VI2535_400_41000 3300 DIM 105 Mar-12 DIM 010 CR 004 VI2535_410_40969 7000 DIM 106 Mar-12 DIM 084 CR 019 VI2535_410_41000 7000 DIM 116 Mar-12 DIM 106 CR 023 VI2542_400_40969 670 DIM 117 Mar-12 DIM 105 CR 023 VI2542_410_40969 1600 Abr-12 DIM 040 CR 007 Supervisor Abr-12 DIM 038 CR 005 Visitas_NumVisitas Supervisor Abr-12 DIM 117 CR 029 Visita_ID NumVisitas CR 004 Abr-12 DIM 116 CR 027 VI2337_400_038_40969 17 CR 005 Abr-12 DIM 044 CR 004 VI2337_400_038_41000 17 CR 007 Abr-12 DIM 009 CR 004 VI2337_400_044_40969 8 CR 008 Abr-12 DIM 010 CR 004 VI2337_400_044_41000 8 CR 019 Abr-12 DIM 084 CR 019 VI2337_400_116_40969 21 CR 023 Abr-12 DIM 106 CR 023 VI2337_400_116_41000 21 CR 027 Abr-12 DIM 105 CR 023 VI2337_410_040_40969 13 CR 029 VI2337_410_040_41000 13 Supervisor->Linha VI2337_410_044_40969 14 Linha Tempo Supervisor Linha VI2337_410_117_40969 26 Linha Mar-12 CR 007 Linha 2 VI2337_410_117_41000 26 Linha 1 Mar-12 CR 005 Linha 2 VI2535_400_009_40969 18 Linha 10 Mar-12 CR 029 Linha 10 VI2535_400_009_41000 18 Linha 2 Mar-12 CR 027 Linha 10 VI2535_400_084_40969 21 Linha 3 Mar-12 CR 008 Linha 3 VI2535_400_084_41000 21 Linha 7 Mar-12 CR 004 Linha 1 VI2535_400_106_40969 15 Linha 8 Mar-12 CR 019 Linha 7 VI2535_400_106_41000 15 Mar-12 CR 023 Linha 8 VI2535_410_010_40969 9 Empresa Abr-12 CR 007 Linha 1 VI2535_410_010_41000 9 Empresa Abr-12 CR 005 Linha 1 VI2535_410_084_40969 18 NossaEmpresa1 Abr-12 CR 029 Linha 10 VI2535_410_084_41000 18 NossaEmpresa2 Abr-12 CR 027 Linha 10 VI2535_410_105_40969 28 Abr-12 CR 004 Linha 1 VI2535_410_105_41000 28 Produto Abr-12 CR 019 Linha 7 VI2542_400_009_40969 12 Produto Abr-12 CR 023 Linha 8 VI2542_400_084_40969 9 Produto 2337 VI2542_400_106_40969 13 Produto 2535 Linha->Empresa VI2542_410_010_40969 28 Produto 2542 Tempo Linha Empresa VI2542_410_084_40969 14 Mar-12 Linha 2 NossaEmpresa1 VI2542_410_105_40969 18 Zona Mar-12 Linha 10 NossaEmpresa1 Zona Mar-12 Linha 3 NossaEmpresa1 Historized Tie (3D) Zona400 Mar-12 Linha 1 NossaEmpresa2 CoordenadasVendas Zona410 Mar-12 Linha 7 NossaEmpresa2 Tempo Venda_ID Produto Zona Mar-12 Linha 8 NossaEmpresa2 Mar-12 VI2337_400_40969 Produto 2337 Zona400 Vendas Abr-12 Linha 10 NossaEmpresa1 Mar-12 VI2337_410_40969 Produto 2337 Zona410 Venda_ID VI2535_400_40969 Factos Abr-12 Linha 1 NossaEmpresa2 Mar-12 Produto 2535 Zona400 VI2337_400_40969 Abr-12 Linha 7 NossaEmpresa2 Mar-12 VI2535_410_40969 Produto 2535 Zona410 VI2337_400_41000 Abr-12 Linha 8 NossaEmpresa2 Mar-12 VI2542_400_40969 Produto 2542 Zona400 VI2337_410_40969 Abr-12 VI2542_410_40969 Produto 2542 Zona410 VI2337_410_41000 Produto->Empresa Abr-12 VI2337_400_41000 Produto 2337 Zona400 VI2535_400_40969 Tempo Produto Empresa Abr-12 VI2337_410_41000 Produto 2337 Zona410 VI2535_400_41000 Mar-12 Produto 2337 NossaEmpresa1 Abr-12 VI2535_400_41000 Produto 2535 Zona400 VI2535_410_40969 Mar-12 Produto 2535 NossaEmpresa2 Abr-12 VI2535_410_41000 Produto 2535 Zona410 VI2535_410_41000 Mar-12 Produto 2542 NossaEmpresa2 VI2542_400_40969 Abr-12 Produto 2337 NossaEmpresa1 Historized Tie (4D) VI2542_410_40969 Abr-12 Produto 2535 NossaEmpresa2 CoordenadasVisitas Tempo Visita_ID Produto Zona DIM Visitas Mar-12 VI2337_400_038_40969Produto 2337 Zona400 DIM 038 Visita_ID DIM<->Zona Mar-12 VI2337_400_044_40969Produto 2337 Zona400 DIM 044

n:n VI2337_400_038_40969 Tempo DIM Zona Mar-12 VI2337_400_116_40969Produto 2337 Zona400 DIM 116 VI2337_400_038_41000 Mar-12 DIM 009 Zona400 Mar-12 VI2337_410_040_40969Produto 2337 Zona410 DIM 040 VI2337_400_044_40969 Mar-12 DIM 010 Zona410 Mar-12 VI2337_410_044_40969Produto 2337 Zona410 DIM 044 VI2337_400_044_41000 Mar-12 DIM 038 Zona400 Mar-12 VI2337_410_117_40969Produto 2337 Zona410 DIM 117 VI2337_400_116_40969 Mar-12 DIM 040 Zona410 Mar-12 VI2535_400_009_40969Produto 2535 Zona400 DIM 009 VI2337_400_116_41000 Mar-12 DIM 044 Zona400 Mar-12 VI2535_400_084_40969Produto 2535 Zona400 DIM 084 VI2337_410_040_40969 Mar-12 DIM 044 Zona410 Mar-12 VI2535_400_106_40969Produto 2535 Zona400 DIM 106 VI2337_410_040_41000 Mar-12 DIM 084 Zona400 Mar-12 VI2535_410_010_40969Produto 2535 Zona410 DIM 010 VI2337_410_044_40969 Mar-12 DIM 084 Zona410 Mar-12 VI2535_410_084_40969Produto 2535 Zona410 DIM 084 VI2337_410_117_40969 Mar-12 DIM 105 Zona410 Mar-12 VI2535_410_105_40969Produto 2535 Zona410 DIM 105 VI2337_410_117_41000 Mar-12 DIM 106 Zona400 Mar-12 VI2542_400_009_40969Produto 2542 Zona400 DIM 009 VI2535_400_009_40969 Mar-12 DIM 116 Zona400 Mar-12 VI2542_400_084_40969Produto 2542 Zona400 DIM 084 VI2535_400_009_41000 Mar-12 DIM 117 Zona410 Mar-12 VI2542_400_106_40969Produto 2542 Zona400 DIM 106 VI2535_400_084_40969 Abr-12 DIM 009 Zona400 Mar-12 VI2542_410_010_40969Produto 2542 Zona410 DIM 010 VI2535_400_084_41000 Abr-12 DIM 010 Zona410 Mar-12 VI2542_410_084_40969Produto 2542 Zona410 DIM 084 VI2535_400_106_40969 Abr-12 DIM 038 Zona400 Mar-12 VI2542_410_105_40969Produto 2542 Zona410 DIM 105 VI2535_400_106_41000 Abr-12 DIM 040 Zona410 Abr-12 VI2337_400_038_41000Produto 2337 Zona400 DIM 038 VI2535_410_010_40969 Abr-12 DIM 044 Zona400 Abr-12 VI2337_400_044_41000Produto 2337 Zona400 DIM 044 VI2535_410_010_41000 Abr-12 DIM 084 Zona400 Abr-12 VI2337_400_116_41000Produto 2337 Zona400 DIM 116 VI2535_410_084_40969 Abr-12 DIM 084 Zona410 Abr-12 VI2337_410_040_41000Produto 2337 Zona410 DIM 040 VI2535_410_084_41000 Abr-12 DIM 105 Zona410 Abr-12 VI2337_410_117_41000Produto 2337 Zona410 DIM 117 VI2535_410_105_40969 Abr-12 DIM 106 Zona400 Abr-12 VI2535_400_009_41000Produto 2535 Zona400 DIM 009 VI2535_410_105_41000 Abr-12 DIM 116 Zona400 Abr-12 VI2535_400_084_41000Produto 2535 Zona400 DIM 084 VI2542_400_009_40969 Abr-12 DIM 117 Zona410 Abr-12 VI2535_400_106_41000Produto 2535 Zona400 DIM 106 VI2542_400_084_40969 Abr-12 VI2535_410_010_41000Produto 2535 Zona410 DIM 010 VI2542_400_106_40969 Abr-12 VI2535_410_084_41000Produto 2535 Zona410 DIM 084 VI2542_410_010_40969 Abr-12 VI2535_410_105_41000Produto 2535 Zona410 DIM 105 VI2542_410_084_40969 VI2542_410_105_40969 Figura 18. Modelo Anchor em tabelas relacionais na 6NF.

O modelo DV, patenteado, inicialmente apresentado e desenvolvido na indústria por Linstedt (2001; 2002), conceptualmente revisto e sistematizado por Jovanovic e Bojicic (2012) como Conceptual Data Vault (C-DV), apenas utiliza três conceitos, Hubs (entidades e eventos), Links (associações) e Satellites (atributos).

No caso do modelo de negócio do nosso exemplo, a estrutura DV mapearia para tabelas relacionais da mesma forma que AM, devido à equivalente filosofia estrutural essencial.

2.3.5.7. Metodologias ágeis em bases de dados

Em 2001, um grupo multidisciplinar formou a Agile Alliance, com o objectivo de fazer face ao habitual insucesso dos projectos de desenvolvimento informático nas organizações, tendo definido os seguintes valores fundamentais (Ambler, 2003):

. Privilegiar indivíduos e interacções em detrimento de processos e ferramentas. . Valorizar mais o facto do software funcionar, do que a documentação em si. . Valorizar a colaboração e comunicação com os utilizadores, em detrimento de acordos assinados. . Incentivar a resposta à mudança em vez do simples seguimento de um plano.

Ambler (2003) crê que estes valores devem orientar também os esforços de desenvolvimento que envolvem dados, contribuindo para minimizar as consequências dos problemas que esta área defronta:

. Conflito de visões e prioridades, entre programadores, arquitectos e administradores de bases de dados (DBA), gestores e utilizadores. . Excessiva especialização de tarefas. . Formas diferentes de trabalhar:

- iterativa e incremental tendencialmente já adoptada pelos programadores através de metodologias ágeis como Unified Process, Extreme Programming (XP), Scrum, DSDM, Crystal Clear ou FDD; vs - ainda sequencial na área dos dados. . Racionais diferentes na tecnologia: - objectos e componentes na programação; vs - bases de dados e ficheiros estáticos. . Gestão de projectos fossilizada em práticas de desenvolvimento obsoletas. . Fraca comunicação, arrogância, autoritarismo, e jogos políticos a nível de toda a organização, a deitarem areia na engrenagem dos projectos. . Fraca documentação, escassa ou inútil. . Inadequação, afastada da realidade, da arquitectura, das linhas de orientação e dos esforços de modelação.

Com base em literatura e experiência, consideramos a visão e os princípios do desenvolvimento ágil, incluindo a sua aplicação à modelação de dados, como extremamente salutares, oportunos e imprescindíveis à redução das taxas catastróficas de insucesso em projectos de BI - 70 a 80% (Kernochan, 2011) - e DW - 30 a 50% (Ariyachandra, 2005) -, contribuindo para minorar as consequências do problema de investigação que identificámos.

No entanto, sendo efectivamente a abordagem ágil humana uma forma de aceitar e resolver da melhor forma, interessada, proactiva e responsável, os problemas que podem surgir, mais partido se poderá ainda tirar dela se simultaneamente se conseguir minimizar à partida esses mesmos problemas através duma solução tecnológica. Essa é a meta que norteará a nossa investigação.

3. MÉTODOS E MATERIAIS

3.1. MÉTODOS

Em primeiro lugar, foi estudada e comentada no capítulo anterior, literatura respeitante a modelos de dados habitualmente adoptados em BI, e também foi consultada outra investigação, recente e inovadora, com potencial para ajudar a responder à questão de investigação.

Com base no conhecimento adquirido, e raciocínio dedutivo e indutivo, será formulado um novo conceito de modelo de dados como potencial solução.

Seguidamente, para testar o novo conceito, será utilizada uma abordagem experimental focada num cenário delimitado de requisitos de análise, consistindo nos seguintes pontos:

. Será definido um modelo relacional tradicional simulando um cenário onde habitualmente ocorre o problema de investigação: um negócio com várias hierarquias de gestão e análise, e métricas de avaliação com uma complexidade suficiente para pôr à prova a robustez do modelo desenvolvido.

. Além disso, os registos simulando factos serão carregados em quantidade suficiente para reproduzir um ambiente empresarial exigente, tornando possível também aferir a capacidade de resposta do modelo a volume de dados.

. Será criada uma base de dados onde será Implementado o modelo relacional, e a partir do qual um cubo OLAP também será gerado.

. Será criada outra base de dados para implementar o novo modelo, serão comparados os modelos, serão eventualmente despoletados novos processos de reflexão para endereçar insuficiências detectadas, e serão

repetidos estes passos as vezes consideradas necessárias para uma resposta satisfatória à questão de investigação.

. Será eventualmente criada uma base de dados adicional para comparação com outra abordagem encontrada na literatura, passível de implementação no modelo relacional, que revele potencial de resolução do problema de investigação.

Os seguintes factores comparadores medirão a implicação, em cada modelo, de alterações ao modelo de negócio.

Factores cuja minimização constitui o objectivo desta investigação:

. Esforço - complexidade e quantidade de passos necessários para implementar e alterar o DW e software dele dependente; . Skills – correspondente nível de know-how necessário; . Risco – probabilidade de insucesso no processo; e . Complexidade do conceito.

Outros factores implicados que idealmente também deverão ser mínimos:

. Tempo de resposta duma consulta padrão; . Tempo eventualmente adicional ao processamento inicial dos dados; e . Espaço em disco utilizado.

3.2. MATERIAIS

Para desenvolvimento e teste da solução, foram utilizados: . Software - RDBMS: Microsoft SQL Server 2012, Developer Edition, 64 bits, versão 11.0.2218.0

- Software para construção de cubo OLAP em Analysis Services: Microsoft Visual Studio 2010, versão 10.0.40219.1 SP1Rel Microsoft .NET Framework versão 4.5.50709 SP1Rel Microsoft SQL Server Analysis Services Designer, versão 11.0.2100.60 - Sistema operativo: Microsoft Windows 7 Professional, 64 bits, Service Pack 1 . Hardware - PC portátil Clevo (índice de desempenho Windows 6,4) Processador: Intel® Core™ i7-2760QM, 2.4 GHz Memória instalada (RAM): 8 GB Disco de alojamento das bases de dados: SATA 750 GB, 7200 rpm

Foram criadas 5 bases de dados relacionais numa única instância do servidor RDBMS, cada uma replicando os dados simulados de teste de acordo com um modelo distinto, permitindo aferir a viabilidade e o comportamento de 3 evoluções do conceito de solução, em comparação com o modelo tradicional relacional e a recente abordagem Anchor Model: . Modelo Relacional: R . Modelo Anchor: AM . Modelo Solução 1ª evoluçaõ: Z . Modelo Solução 2ª evolução: Z_d . Modelo Solução 3ª evolução: Z+

Todos os testes às implementações nas bases de dados relacionais foram efectuados em iguais circunstâncias, sem nenhum software aplicacional a correr no PC para além do MS SQL Server, sempre após compactação de cada base de dados e reconstrução dos índices de todas as tabelas, para garantir um funcionamento igualmente óptimo em cada caso.

Adicionalmente, foi criada uma base de dados OLAP em tecnologia MS Analysis Services (OLAP CUB) na qual foi gerado um cubo (R) através de uma solução de desenvolvimento em Visual Studio (OLAP CUB.sln), para obter a outra referência tradicional de implementação em data warehousing, complementar: o cubo multidimensional.

4. RESULTADOS E DISCUSSÃO

4.1. DESCRIÇÃO DO MODELO DE NEGÓCIO SUBJACENTE AO MODELO DE DADOS A TESTAR

No modelo de negócio tradicional da indústria farmacêutica de medicamentos sujeitos a receita médica (MSRM), o essencial da actividade promocional fica a cargo de Delegados de Informação Médica (DIM), que promovem os produtos da empresa a médicos potencialmente prescritores dos mesmos, visitando-os (Decreto-Lei nº 176/2006 Artigo 157.º; Fórum Estudante, 2006). Estas visitas são habitualmente registadas em plataformas de Customer Relationship Management (CRM) por cada DIM (Brosnan, 2012; Oracle, 2007), e controladas pelo respectivo responsável hierárquico directo, que pode ser denominado Supervisor, Chefe Regional, Regional Sales Manager, Area Manager entre outras possibilidades.

Acima deste existe uma hierarquia com um número de níveis que pode variar conforme os casos, compreendendo por exemplo Chefes Nacionais e/ou Directores, indo até à Administração ou Direcção-Geral, e eventualmente níveis internacionais. Nos anos mais recentes, devido à crise económica generalizada e especialmente aos cortes na Saúde (Reis, 2012), as estruturas de força de vendas têm-se caracterizado por um extremo dinamismo, com constantes reestruturações, hierárquicas e territoriais, o que reforça a pertinência do exemplo utilizado para testar um modelo que se pretende ágil.

O modelo de negócio farmacêutico é sui generis no sentido em que os DIM são “vendedores” que nunca fecham nenhuma venda com quem visitam. O médico prescreve um medicamento a um paciente, que o avia numa farmácia. Por motivos éticos e legais próprios ao mercado sensível da saúde, não é permitido cruzar dados de forma a conhecer quais os produtos que foram prescritos por um determinado médico (Decreto-Lei nº 176/2006 Artigo 158.º nº 5).

Apenas se permite divulgar as vendas discriminadas por produtos agregando-as por zonas geográficas com um número mínimo de farmácias que torne teoricamente impossível o rastreio da informação até ao nível do médico prescritor, a granularidade

dos dados terminando, portanto, numa pequena agregação do território nacional (BIU ou Brick) (Oracle, 2007), que costuma abranger vários centros de saúde em volta dos quais existem farmácias (Sinfic SA). Esta tarefa regulamentada de recolha de dados é actualmente efectuada por apenas duas empresas (IMS Health e HmR) fornecedoras de dados à indústria farmacêutica (Fonseca, 2012).

Apesar de, por exemplo, uma receita prescrita no Sul poder ser aviada no Norte, o inverso também é possível, e a indústria, à falta de melhor informação, tem aceite que o nível de Vendas duma zona é um bom indicador para o desempenho dum DIM que aí efectua visitas (Oracle, 2007).

Deste modo são habitualmente atribuídas aos DIM zonas pertencentes à classificação utilizada pelo fornecedor de dados de Vendas, para as quais são estabelecidos objectivos de Vendas que, somados, constituem o objectivo global do DIM, pelo qual será avaliado num determinado período.

Também é comum estabelecer objectivos de Visitas para cada DIM, que podem também contribuir ou não para a respectiva avaliação, servindo em qualquer caso para controlar a actividade e o seguimento duma estratégia. Aqui pode ser exercido um controle mais fino pela supervisão, ao nível do médico ou tipo de médico, facilitado por uma plataforma de CRM.

Do acima exposto derivamos a granularidade (detalhe mais fino possível) na origem dos registos dos eventos de negócio do exemplo:

. Vendas são obtidas por Zona e Produto (Apresentação) . Visitas são obtidas por DIM, Médico e Produto (Marca)

Note-se que as empresas adquirem informação regional de Vendas discriminada ao nível da apresentação (ex: 20mg 30 comprimidos) apenas para fins de análises finas de Marketing, pois a nível de gestão da Força de Vendas não tem relevância, uma vez que a promoção se efectua pela Marca como um todo.

4.2. DESCRIÇÃO DOS DADOS UTILIZADOS PARA TESTE

4.2.1. Estrutura de Eventos

O modelo de dados que aqui será desenvolvido tem a finalidade de servir necessidades de Análise de Vendas da área comercial dum Grupo farmacêutico, ou seja terá a granularidade de Vendas limitada ao que lhe é relevante, e a de Visitas limitada ao que for suficiente para permitir o cruzamento com Vendas, ou seja:

. Vendas por Zona e Produto (Marca) . Visitas por DIM, Zona e Produto (Marca)

Destacamos o facto de as visitas serem definidas pelo cruzamento de três dimensões, enquanto as vendas o são pelo cruzamento de apenas duas. É obviamente relevante a discriminação das visitas por DIM, pois cada um regista as suas, mas as vendas de cada zona são as que aí foram atribuídas sem ser possível identificar quem e em quanto foi mais ou menos responsável por elas.

Uma abordagem de registo poderia ser repetir as Vendas por cada DIM, pois é esse valor que conta para cada avaliação individual. No entanto, tal traria dificuldades ao cálculo agregado de Vendas a níveis superiores de hierarquia, pois as vendas das zonas em que trabalha mais do que um DIM ficariam duplicadas.

4.2.2. Estrutura de Dimensões

A estrutura do exemplo utilizado no capítulo de revisão de literatura era uma aproximação, reduzida para fins demonstrativos, e introdutória da estrutura que a seguir se apresenta.

O modelo a desenvolver destina-se a servir um Grupo farmacêutico, constituído por Empresas, cuja gestão comercial se reparte por Linhas comerciais, cujas Vendas são orientadas por Supervisores, aos quais reportam os DIM, que partilham Regiões,

cada uma delas composta por Zonas distintas. Cada empresa comercializa os seus próprios produtos.

O Grupo subscreve um serviço de fornecimento de dados que lhe dá acesso a vendas suas e da concorrência, disponibilizando as seguintes hierarquias de produto:

. Produto  Denominação Comum Internacional do princípio activo (DCI)  Classe Terapêutica . Produto  Empresa detentora de Autorização de Introdução no Mercado (AIM)

Além disso, o Grupo criou internamente para fins estratégicos e de análise as seguintes hierarquias de produto adicionais:

. Produto  Conjunto de Produtos (utilizado para agregar alguns produtos do Grupo, com um objectivo estratégico) . Produto  Mercado Configurado (utilizado para agregar alguns produtos dentro e/ou fora do Grupo, para configurar mercados que vão para além de uma simples caracterização por Classe Terapêutica ou DCI)

4.2.3. Modelação

A descrição das estruturas referidas acima, por si só, já constitui um modelo, verbal, da realidade do negócio (Beck, 2007).

Necessitando passar esse conhecimento da linguagem natural para dentro do sistema de BI, um passo intermédio consiste em traduzi-lo para um modelo não- técnico e simples mas agora livre de ambiguidades, como o modelo Entidade- Associação - Entity-Relationship (ER) (Chen, 1976) -, que é uma representação gráfica das entidades e associações entre elas (Connolly & Begg, 2005).

Com este modelo, conceptual e lógico, pretende-se simultaneamente um entendimento consensual pelas pessoas do negócio, e um esquema mapeável para

uma estrutura técnica, permitindo o iníco do desenvolvimento pela equipa de sistemas. Provavelmente por essa razão, o modelo ER é a abordagem mais utilizada para modelação de dados, e, não existindo nenhum standard de notação único, têm surgido desde a sua criação diversas e variadas versões (Halpin & Morgan, 2008).

Sugere-se na Figura 19 uma versão simples do modelo ER, no qual as caixas representam entidades, e as linhas associações. A terminação em pé-de-galo representa o lado n (muitos) de uma associação de 1 para n.

Para ilustração, os factos estão a azul, as hierarquias de produto a verde, a hierarquia organizacional a laranja claro, e a estrutura geográfica a laranja escuro. Note-se que Empresa e Grupo são membros de duas hierarquias simultaneamente: Organizacional e Produto.

Grupo Classe Terap.

Empresa DCI

Linha Conjunto Prod.

Merc.Config. Supervisor Produto

DIM

Região/DIM Visitas

Zona/DIM

Zona Vendas

Figura 19. Modelo ER simples.

4.2.4. Dados

4.2.4.1. Factos

Foram simulados dados recriando dezoito meses de actividade (Janeiro 2011 a Junho 2012) dum Grupo farmacêutico fictício chamado NossoGrupo, considerando-se um outro agrupamento, Concorrência, para agregar todas as empresas concorrentes.

A actividade compreende vendas e visitas. Da Concorrência, apenas existe acesso a dados de vendas.

. Há 8.103.269 registos de vendas, em Euros e Unidades. . Há 101.399 registos de Actividades Promocionais de Tipo 1 (Visitas a Médicos) . Há 62.214 registos de Actividades Promocionais de Tipo 2 (Visitas a Enfermeiros) . Há 279.324 registos de Objectivos de Venda em Euros.

4.2.4.2. Dados de Estruturas

Foi simulada e atribuída ao mês Março 2012 a seguinte estrutura (instanciação ou concretização do modelo definido em 4.2.3):

. NossoGrupo tem 3 empresas, 11 linhas comerciais, 30 supervisores de vendas e 107 DIM. . Para exercer as suas actividades de promoção e vendas subdividiu o país em 146 regiões, que agregam as 410 zonas geográficas, definidas pelo fornecedor de dados de vendas. . Existem no total 187 empresas no mercado trabalhando 2483 produtos, 141 dos quais detidos pelo NossoGrupo. . Os produtos classificam-se em 358 DCI, por sua vez agregadas em 74 classes terapêuticas.

. Os DIM trabalham em média 9 regiões / 44 zonas. . Foram definidos 43 Mercados Configurados que classificam 2392 produtos, e 8 Conjuntos de Produtos classificando 44 produtos.

4.3. DESCRIÇÃO DO PROCESSO DE BI CONSIDERADO

Externamente ao sistema de BI são decididas pontualmente estruturas (dimensões, hierarquias, alocações, métricas, cálculos), e com carácter regular (mensal) são gerados factos (que registam eventos que vão ocorrendo).

Ambos os tipos de dados necessitam ser carregados para dentro do DW para aí ficarem organizados de forma a que as aplicações de consulta os consigam explorar, de acordo com as selecções feitas pelo utilizador, exibindo os dashboards pretendidos.

Figura 20. O processo de BI.

O processo está ilustrado na Figura 20. As setas representam os subprocessos de transformação de dados:

. o primeiro (setas a entrar no DW), vulgarmente designado Extract- Transform-Load (ETL) (Kimball & Caserta, 2004), carrega ciclicamente os dados externos para dentro do data warehouse, tendo de os adaptar a este; . o segundo (seta a sair do DW), que consiste nos algoritmos de consulta, lê, selecciona, filtra, agrega e calcula os dados (já arrumados no DW) na hora, a pedido.

Do exposto depreende-se que, a pedido (seta da direita) sempre terão de ser obviamente feitas, para além da leitura (acesso), a selecção e o filtro dos dados, pois só no momento é que o utilizador decide o que quer consultar.

Mas já quanto à agregação e cálculo dos dados, há opção entre atribuir estas tarefas ao processo de consulta efectuando-as no momento, ou ao processo de ETL, pré-calculando, pré-agregando e armazenando ciclicamente. É comum utilizar-se esta segunda alternativa (materializar resultados de consultas) com a intenção de melhorar tempos de acesso (Agrawal et al., 2009).

Na decisão há que optar entre velocidade da consulta, tempo de processamento do ETL e espaço em disco utilizado (Harinarayan, Rajaraman, & Ullman, 1996). Há que ponderar também se é preferível concentrar as eventuais necessidades de alterações exclusivamente no ETL, ou ter também de precaver a necessidade de alteração ao front-end de consulta, que envolve custos adicionais e de outro tipo.

Considerando o enorme número de combinações possíveis de parâmetros seleccionáveis simultaneamente, habitualmente não existe nenhuma escolha óptima quanto ao grau de pré-processamento, sendo o problema – Materialized View Selection (MVS) - considerado como de tipo np-complete - sem nenhuma forma determinística de resolução (Golumbic, 2004) -, ao ser estudado na perspectiva da minimização da soma de todos os tempos de acesso (Harinarayan et al., 1996).

Logo, a escolha que for efectuada será sempre uma solução de compromisso, dentro de muitas possíveis, por pré-processamento parcial, não sendo forçoso ter de se optar entre tudo ou nada.

Qualquer dos processos (ETL e consulta) é complexo e requer tempo e trabalho para ser alterado, o que, como se depreende, acontecerá sempre que houver alterações ao DW, pois o primeiro escreve nele, e o segundo lê-o. Daí fazer sentido a procura duma solução ideal em que nunca seja necessário alterar o DW, ou em que as alterações não tenham impacto nem no input nem no output, ou que permitam gerir esse impacto rapidamente e de forma totalmente automática.

4.4. DESCRIÇÃO DO DASHBOARD PRETENDIDO

4.4.1. Indicadores de Marketing e Vendas MI e Evol

Existem dois indicadores (KPI) de marketing comummente utilizados na indústria farmacêutica que permitem a comparação de desempenho face ao mercado: . o Índice Evolutivo, ou Evolution Index (Evol), e . o Índice de Mercado, ou Índice de Penetração ou Market Index (MI).

O Evol, comparando o crescimento dum produto com o crescimento do mercado, fornece uma indicação da dinâmica de evolução da quota de mercado, alicerçada em dois momentos distintos.

O MI apresenta também uma perspectiva sobre a penetração no mercado, embora estática, mas introduzindo adicionalmente uma comparação a nível da geografia, caracterizadora da actividade da indústria farmacêutica.

Também noutras indústrias comerciais que necessitam constantemente de aferir a sua posição dentro do mercado, são utilizadas variantes a estes indicadores, de entre uma panóplia de métricas de marketing, provenientes directamente da actividade comercial, geralmente obtidas de forma heurística e intuitiva, existindo escasso suporte na literatura (Ambler, 2000; Farris, Bendle, Pfeifer, & Reibstein, 2006; Weller, 2004).

Num formato ou noutro, as organizações necessitarão sempre de métricas para diagnosticar o seu desempenho em várias vertentes de análise, pelo que a utilização no presente estudo dos indicadores MI e Evol da indústria farmacêutica é valiosa, estes comportando a complexidade de cálculo que tipicamente um sistema de BI deverá suportar, sendo ao mesmo tempo de entendimento imediato.

As fórmulas de cálculo do MI e do Evol encontram-se detalhadas na Tabela 2, junto com as fórmulas auxiliares, e um exemplo de cálculo.

Conceito Definição Cálculo Exemplo Actual Anterior (0)▼ (1)▼

VPR Vendas Regionais do Produto 20 24

VMR Vendas Regionais do Mercado 90 84

VPN Vendas Nacionais do Produto 2.500 2.600

VMN Vendas Nacionais do Mercado 10.000 11.000 MS (Market Share) % de Vendas do Produto em relação ao Regional Mercado de Referência, a nível Regional MSR = VPR / VMR 22,2% 28,6% MS (Market Share) Nacional % de Vendas do Produto em relação ao Mercado de Referência, a nível Nacional MSN = VPN / VMN 25,0% 23,6% GMS (Geographical Market Share) do Produto % de Vendas do Produto na Região em relação a todo o território Nacional GMSP = VPR / VPN 0,80% 0,92% GMS (Geographical Market Share) do Mercado % de Vendas do Mercado na Região em relação a todo o território Nacional GMSM = VMR / VMN 0,90% 0,76%

MI = MSR/MSN x 100 = (VPR/VMR) / (VPN/ VMN) Índice de Penetração do Produto = MS Ml (Market Index) Regional em relação ao MS Nacional x 100 89 121 (2 perspectivas) = (VPR/VPN) / (VMR/ VMN) x 100 = GMS do Produto em relação ao GMS do Mercado = GMSP / GMSM x 100 89 121

GIP (Product Growth Index) Índice de Crescimento das Vendas do Produto (do Momento Anterior 1 para o Momento Actual 0) GIP = VP0 / VP1 x 100 83,33 96,15 GIM (Market Growth Index) Índice de Crescimento das Vendas do Mercado (do Momento Anterior 1 para o Momento Actual 0) GIM = VM0 / VM1 x 100 107,14 90,91

Índice de Evolução das Vendas = Crescimento Evol = GIP / GIM X 100 do Produto em relação ao Crescimento do Evol (Regional ou = (VP0 / VP1) / (VM0 / VM1) Mercado (do Momento Anterior 1 para o Nacional) Momento Actual 0) x 100 78 106

(2 perspectivas) = (VP0 / VM0) / (VP1 / VM1) = Índice de Crescimento da Quota de x 100 Mercado (do Momento Anterior 1 para o Momento Actual 0) = MS0 / MS1 x 100 78 106 Tabela 2. Fórmulas de cálculo do MI e do Evol.

Note-se que, tanto um indicador como o outro, podem ser entendidos (e calculados) de duas formas diversas, embora obtendo-se obviamente o mesmo resultado. Uma reflexão sobre a dupla abordagem, em ambos os indicadores, constitui um exercício facilitador da interiorização dos conceitos desta área de negócio.

Foi utilizado um índice 0 ou 1 para significar o período corrente ou anterior, respectivamente, quando é relevante tal distinção, como no caso do Evol, que por se tratar dum rácio de crescimentos, necessita desses dois períodos para o cálculo.

Foi utilizado um índice P ou M para referir Produto ou Mercado, distinção necessária para o cálculo das métricas que dão origem aos KPI MI e Evol, pois ambos comparam desempenho de Produto com desempenho de Mercado.

Um terceiro índice, R ou N, distingue se os cálculos se aplicam às vendas Regionais ou Nacionais, nos casos em que a distinção é relevante, como nos casos da Market Share (MS) geográfica e MI.

A descrição do exemplo calculado na Tabela 2 e respectiva interpretação permitirá apreender o racional básico da utilização dos KPI de mercado MI e Evol:

. Actividade analisada: um DIM promove um produto em determinada região.

. Questão: que tal o seu desempenho mais recente?

VPR são as vendas, na região do DIM, do produto que promove, e VMR são as vendas, na mesma região, de todos os produtos do mesmo mercado.

Logo, MSR = VPR / VMR = 22%, é a MS do produto na região do DIM.

Como podemos saber se 22% é ou não uma boa quota de mercado?

Um critério geralmente aceite é comparar esta quota regional (da responsabilidade do DIM) com a quota nacional (da responsabilidade de todos os que promovem o mesmo produto) MSN = VPN / VMN.

Fazêmo-lo através do MI, que é o rácio destas duas quotas de mercado multiplicado por 100, neste caso obtendo-se 89, que por se encontrar abaixo de 100 indica que o desempenho está um pouco abaixo da média.

Um outro critério consiste em avaliar se a quota de nercado tem vindo a melhorar ou piorar, bastando comparar a quota de mercado do DIM com a do ano anterior, também através de rácio e multiplicando por 100.

O resultado é um Evol de 78, bastante aquém de 100, denotando, em conjunto com o MI também baixo, uma situação a carecer de atenção.

4.4.2. Necessidade de um dashboard

Esta análise, pelo sentido estratégico que demonstra e pela transparência implícita, tem vindo a ser largamente utilizada. No entanto, um DIM não trabalha só um produto nem só uma zona, e logo a análise de todos os seus indicadores numa tabela torna-se fastidiosa. No caso do supervisor, tal seria agravado, por ter de controlar todos os seus DIM, e também ver a agregação de toda a área de sua responsabilidade, o mesmo se passando para níveis superiores da hierarquia.

Uma solução de leitura fácil e rica é o dashboard da Figura 21, em que os eixos do gráfico de bolhas, representando o MI e o Evol, traçam quadrantes nos quais se podem identificar rápida e inequivocamente os perfis de comportamento, obtendo-se ainda a informação adicional de volume de vendas pelo tamanho das bolhas.

Por outro lado, é necessário que o dashboard seja interactivo, pois seria pouco prático, do ponto de vista quer da elaboração quer da análise, a distribuição de relatórios com um enorme número de gráficos, um para cada combinação de produto e geografia, percorrendo os vários níveis de agregação.

Mesmo para cada combinação de parâmetros seleccionada, várias configurações do dashboard são logicamente possíveis (bolhas representando produtos ou regiões,

por exemplo) devendo a Gestão do negócio decidir, de acordo com a estratégia que deseja seguir, a pertinência de quais opções disponibilizar e a quem.

Figura 21. Dashboard para Análise de Vendas.

Uma possível opção com interesse para análise estratégica consiste no detalhe de todos os produtos (incluindo concorrência) que operam no mercado de um mix de produtos da companhia analisada, numa determinada região, tal como aparece configurado na Figura 21.

Apresentando interesse concreto do ponto de vista de Gestão, e também uma complexidade que importa validar, envolvendo referência a dimensões exteriores ao âmbito da consulta (Nacional e Mercado), será esta a configuração utilizada nos testes do presente estudo, e que em seguida descrevemos em detalhe.

4.4.3. Configuração do dashboard pretendido

A configuração do dashboard que aqui vamos considerar é a seguinte:

. Métricas (recapitulando):

- O eixo horizontal representa o MI. - O eixo vertical representa o Evol. - As áreas das bolhas representam Vendas.

. Filtros:

- O utilizador pode escolher uma instância dum nível duma hierarquia de Produto (por ex. o Conjunto de Produtos 4), - e fazer o mesmo relativamente à Geografia (por ex: DIM 042).

. Outras selecções:

- O utilizador pode também optar pelo tipo de mercado de referência subjacente aos cálculos de MI e Evol – um nível duma hierarquia de produto (por ex: DCI), - e ainda por um outro nível duma hierarquia de produto (por ex: o próprio Produto) cujas instâncias serão representadas pelas bolhas, dando o detalhe da consulta.

Podemos então descrever a funcionalidade do dashboard da seguinte forma:

Para quaisquer selecções de mês e filtros (uma instância de qualquer nível da hierarquia de produto, mais uma instância de qualquer nível da hierarquia geográfica), as bolhas representam todas as instâncias dum nível seleccionado de detalhe da hierarquia de produto, sendo o seu tamanho proporcional às vendas, e as suas coordenadas o MI e o Evol calculados com referência a um nível de mercado seleccionado na hierarquia de produto.

A Figura 21 fornece um exemplo ilustrativo do resultado das seguintes selecções efectuadas:

. Mês: ……………………………………………………………………………………..…..Março 2012 . Filtros: Produto: - Nível: ………………………………………………………Conjunto de Produtos - Instância: ……………………………………………..Conjunto de Produtos 4 Geografia: - Nível: ………………………………………………………………………………….DIM - Instância: …………………………………………………………………….DIM 042 . Nível de Detalhe de Produto: ………………………………………………..………..Produto . Nível de Mercado de Referência: ……………………………………………………………DCI

No dashboard obtido, as bolhas representam a importância e posição dos produtos do conjunto nº4 e concorrentes, face ao mercado constituído pela união de todas as respectivas DCI, na região do DIM 042, em Março de 2012.

4.4.4. Alinhamento com o objectivo da investigação

Pelo acima exposto, tanto a escolha do modelo de negócio como a do dashboard revelam relevância para o objectivo da investigação, ao envolverem um nível de complexidade suficiente para permitir validar um modelo que se pretende largamente generalizável, nomeadamente nos seguintes aspectos: . Hierarquias múltiplas e complexas (n para n, e partilhadas); . Estruturas com grande volatilidade; . Eventos com dimensionalidades diferentes e necessitando cruzar-se; . Necessidade de múltiplas perspectivas de análise; e . Métricas complexas: - não aditivas (necessitando de pré-cálculo ou cálculo extremamente eficiente para cada nível de agregação), e - exigindo cruzamento de hierarquias e níveis distintos de uma mesma dimensão (ex: Produto simultaneamente por Conjunto de Produtos e DCI, e Geografia simultaneamente Regional e Nacional).

Figura 22. Modelo físico relacional (base de dados R).

4.5. IMPLEMENTAÇÃO DO MODELO RELACIONAL

4.5.1. Modelo físico (R)

De acordo com o diagrama normalizado ER da Figura 19, foi criado fisicamente o modelo em MS SQL Server numa nova base de dados R, estando representada a estrutura de tabelas e associações do modelo físico na Figura 22, colorida para ilustração4.

Adicionalmente foram assinaladas com círculos as dimensões elementares das estruturas, que são as que definem os eventos.

O script das tabelas de R encontra-se no Apêndice 1 .

4.5.2. Consulta de dados

De acordo com os requisitos para o dashboard, é necessário construir uma consulta com os seguintes parâmetros

. Mês de análise . Métrica base (Unidades ou Euros) . Dimensão geográfico-organizacional a considerar . Instância da dimensão geográfico-organizacional a analisar . Dimensão de Produto a considerar . Instância da dimensão de Produto a analisar . Dimensão de Produto como nível de detalhe (bolhas) . Dimensão de Produto como nível de mercado (para determinação de concorrentes e cálculos)

4 Para fins ilustrativos convencionou-se colorir tudo o que tem a ver com produto a verde, estrutura organizacional a laranja, geográfica a rosa, tempo a azul, métricas originais a branco e métricas calculadas a cinzento.

A Figura 23 mostra os registos resultantes da consulta despoletada pelo utilizador, que representam a informação necessária para popular o gráfico do dashboard.

Figura 23. Registos de uma consulta efectuada.

A linguagem utilizada para a programação da consulta é a Structured Query Language (SQL), standard para definição (DDL) e manipulação (DML) de dados, parte integrante da maioria dos RDBMS, como é o caso do MS SQL Server aqui utilizado.

A Figura 24 e a Figura 25 mostram a estrutura da consulta, ou seja, as ligações entre tabelas que são necessárias efectuar pela consulta para obter os resultados desejados.

Conforme foi observado na Tabela 2, os cálculos de MI e Evol decompõem-se, por definição, em métricas auxiliares. A Figura 24 mostra a camada inferior da consulta

que calcula em primeiro lugar simultaneamente as métricas MS regional (MSR) e MS

nacional (MSN).

MS regional

MS nacional

Figura 24. Camada inferior da consulta: cálculo de MS regional e MS nacional.

Numa camada superior, representada no fundo da Figura 25, define-se o cálculo

do MI a partir da MSR e da MSN, e o do Evol a partir apenas da MSR (do ano actual e do ano anterior).

Um terceiro patamar cola os resultados do MI e do Evol num mesmo registo para cada bolha (join) e finalmente no topo (lookup) junta-se os nomes dos elementos que correspondem às bolhas, pois necessitam ser apresentados no dashboard.

Figura 25. Camada superior da consulta: cálculo algébrico sobre as métricas auxiliares e organização dos registos para entrega ao dashboard.

É importante enfatizar a distinção lógica fundamental entre as camadas de consulta inferior (Figura 24) e superiores (Figura 25).

Estas últimas apresentam (no âmbito limitado a este cálculo de KPI) um nível de abstracção total, pois o que fazem é sempre igual qualquer que seja a estrutura do negócio (meros cálculo algébrico e projecção de registos para um formato fixo), enquanto que o oposto ocorre com a camada inferior, altamente dependente da definição de negócio, pois liga explicitamente (hardcode) tabelas cujos nomes são as entidades do negócio.

No Apêndice 2 encontra-se a listagem da consulta, repartida pelas suas componentes: quatro funções e uma stored procedure

Correndo a consulta, obtemos 103 registos5 (Apêndice 3) e um tempo médio de 2,017 segundos, tendo sido utilizados os parâmetros da Tabela 3.

. Mês: ……………………………………………………………………………………..…………. 201203 . Métrica Base: ……………………………………………………………………………….…..…Euros . Filtros: Produto: - Nível: ………………………………………………………Conjunto de Produtos - Instância: ……………………………………………..Conjunto de Produtos 4 Geografia: - Nível: ………………………………………………………………………………….DIM - Instância: …………………………………………………………………….DIM 042 . Nível de Detalhe de Produto: …………………………………………………………..Produto . Nível de Mercado de Referência: ………………………………………………………………DCI

Tabela 3. Parâmetros de consulta de teste

5 Por poder acontecer, como neste caso, existirem demasiadas bolhas para uma boa visibilidade da informação, na prática convém no final filtrar apenas alguns registos de acordo com algum critério (volume de vendas ou MI, por ex), de maneira a obter a legibilidade da ilustração, como no exemplo da Figura 21. Não considerámos, nas consultas a testar, esse passo adicional, pois seria igual em todas as implementações, não contribuindo para a comparação e prejudicando a compreensão.

Figura 26. Dos dados ao dashboard – modelo relacional com e sem cubo.

4.5.3. Modelo relacional com cubo de pré-agregação

Considerando melhorar o tempo da consulta, prejudicado pelo desenho normalizado da base de dados que implica efectuar ligações (joins) encadeadas (Connolly & Begg, 2005; Moody & Kortink, 2000), a solução habitual consiste em pré- agregar e pré-calcular os dados ficando o resultado da operação, comummente denominado cubo, armazenado persistentemente (Hamel & Hall, 2005).

O que providencia o ganho de performance é, por um lado, o facto de os dados já estarem pré-calculados, por outro o facto de esse cubo existir só para análise, estando optimizado em termos de indexação para leitura – conceito de On-line Analytical Processing (OLAP) - , e não tendo de partilhar a execução com os processos de operações diárias intermitentes e repetitivas envolvendo escrita, classificados como On-Line Transaction Processing (OLTP) (Atkinson & Vieira, 2012) .

Por essa razão, um cubo não necessita forçosamente ser construído numa tecnologia ou modelo distinto do relacional que lhe dá origem (Celko, 2006; Thomsen, 2002; Todman, 2001). No caso do cenário de negócio aqui simulado, os dados operacionais chegam por ficheiros externos, podendo o servidor relacional estar dedicado exclusivamente a OLAP, não existindo conflito de utilizações.

Mesmo nas organizações em que o processo de BI culmina num modelo dimensional com tecnologia própria OLAP, é quase sempre gerada uma base de dados relacional dedicada - recomendada como melhor prática na literatura sob o nome de “Staging Area” (Hobbs, Hillson, Lawande, & Smith, 2005) -, onde acabam por existir tabelas desnormalizadas que serão replicadas no servidor OLAP, transformadas num formato multidimensional (MOLAP), ou como simples cópias directamente utilizadas por este, caso que se designa por OLAP relacional (ROLAP), também sendo possível a pré-agregação de dados ser repartida pelas duas tecnologias: OLAP híbrido (HOLAP) (Todman, 2001).

Neste exemplo, vai ser criado um cubo relacional que reproduz exactamente o formato da consulta ad-hoc, sendo esta adaptada para agora inserir os resultados numa tabela (cubo), e executada para diversas selecções que pretendemos disponibilizar.

Embora autores como Pendse, citado em Hamel e Hall (2005), e Datta e Thomas (1999) interpretem o conceito de cubo como um verdadeiro modelo representativo de dados multidimensionais, um cubo geralmente é considerado e funciona como um simples repositório de consultas materializadas (Hamel & Hall, 2005), conforme aqui vamos criar.

É impossível pré-calcular todas as combinações possíveis de dimensões, pelos constrangimentos de disponibilidade de armazenamento, tempo de carregamento e custos de manutenção (Agrawal et al., 2009). Além disso, a dimensão do cubo tornar- se-ia tão grande que acabaria por prejudicar mais do que beneficiar o tempo de acesso. Logo, na prática recorrer-se-á sempre a uma solução de compromisso. Neste caso, para efeitos de teste, limitamo-nos a criar um pequeno cubo que abrange um número relativamente reduzido de selecções.

Com esta abordadgem, necessitamos criar uma nova consulta final ad-hoc simples para ir buscar os resultados directamente ao cubo, em vez de os calcular como anteriormente de raíz com base nos factos elementares.

E a lógica anterior de obtenção dos registos mantém-se mas agora desemboca no cubo, tabela desnormalizada, que surge como um interface antes da consulta ad- hoc, como se observa na Figura 26, que ilustra todo o processo desde a base de dados em modelo relacional até ao dashboard, para ambas as implementações: com e sem cubo.

Este algoritmo, que pertencia à seta que saía do DW na Figura 20, agora transformado para funcionar com intervalos de parâmetros e gerar registos persistentes, passa a ser pocessado ciclicamente, incluído no processo de ETL à entrada do DW.

No Apêndice 4 encontra-se a consulta que foi convertida em parte de ETL, e no Apêndice 5 a nova consulta ad-hoc simples, de acesso directo ao cubo.

Para este teste, optou-se por criar um cubo que se limita a reproduzir as combinações de selecções geradas pelos parâmetros da Tabela 4. De seguida, executou-se a consulta ad-hoc com os parâmetros, mais restritos, de consulta (Tabela

3), como no ensaio anterior, surgindo os mesmos 103 registos, mas agora mais rapidamente, a uma média de 0,189 segundos (cerca de 10 vezes mais rapidamente), ou seja quase instantaneamente, cumprindo as expectativas relativas a um pré-cálculo que evita cálculos complexos no momento.

. Mês: ……………………………………………………………………………………...…………..201203 . Métrica Base: ……………………………………………………………………………….…..…Euros . Filtros: Produto: - Nível: ………………………………………………………Conjunto de Produtos - Instância: ………………………………………………………………………..Tudo Geografia: - Nível: ………………………………………………………………………………….DIM - Instância: ………………………………………………………………………….Tudo . Nível de Detalhe de Produto: …………………………………………………………..Produto . Nível de Mercado de Referência: ………………………………………………………………DCI

Tabela 4. Parâmetros de criação do cubo de teste6

Esta melhoria é conseguida obviamente em troca duma maior ocupação de espaço em disco, pois passa a existir uma tabela adicional com informação redundante7.

Neste momento dispomos duma implementação típica para uma aplicação que disponibiliza dashboards do género do que estamos a testar: em SQL no modelo relacional (com tabelas de estrutura normalizadas e associadas entre si), optimizada pela utilização de chaves indexadas desfragmentadas e por uma pré-agregação deliberadamente desnormalizada mas também indexada, que se traduz num desempenho muito satisfatório, com consultas a rondar os zero segundos.

6 A escolha de Tudo em todas as selecções implicaria o pré-cálculo de todas as combinações possíveis, se tal fosse viável. 7 Por neste caso se ter criado um cubo muito delimitado, a comparação efectiva de tamanho da base de dados antes e depois da criação do cubo não é relevante para aferir da implicação real desta opção .

4.6. IDENTIFICAÇÃO DE ALTERNATIVA AO MODELO RELACIONAL

4.6.1. Necessidade

O que é então possível melhorar? A pergunta remete-nos para a questão fundamental de investigação:

. Existe forma de minimizar o impacto na estrutura de armazenamento de dados e nas consultas que aí acedem8, causado por uma alteração ao modelo de negócio da organização?

4.6.2. Potencial circunstância impactante

Para obter a resposta a esta questão, vamos começar por identificar e isolar uma possível alteração ao modelo de negócio, aferir do impacto da sua implementação no modelo lógico e físico, e então avaliar medidas para reduzir ou eliminar tal impacto.

Vamos supor uma alteração simples que se traduz no seguinte requisito: . Passam a existir Strategic Business Units (SBU), que agrupam Linhas comerciais, independentemente da Empresa, conforme a Tabela 5.

Linha SBU Linha 1 SBU A Linha 2 SBU A Linha 3 SBU A Linha 4 SBU A Linha 5 SBU A Linha 6 SBU B Linha 7 SBU B Linha 8 SBU B Linha 9 SBU C Linha 10 SBU C Linha 11 SBU C Tabela 5. Relação Linha Comercial - SBU

8 As áreas de impacto estão assinaladas com barras vermelhas na Figura 26.

Grupo Classe Terap.

SBU Empresa DCI

Linha Conjunto Prod.

Merc.Config.

Supervisor Produto

DIM

Região/DIM Visitas

Zona/DIM

Zona Vendas

Figura 27. Modelo ER – nova entidade SBU

4.6.3. Avaliação de impacto

4.6.3.1. Impacto na estrutura de armazenamento

A nova estrutura genérica reflecte-se no modelo ER da Figura 27, com a alteração assinalada a vermelho, cuja concretização requer as seguintes tarefas em SQL:

1. Criação da tabela SBU:

CREATE TABLE [dbo].[SBU]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, CONSTRAINT [PK_SBU] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]

2. Introdução dos registos representando as SBU:

INSERT INTO [dbo].[SBU] ([ID],[Name])

SELECT 'SBU A', 'SBU A' UNION ALL SELECT 'SBU B', 'SBU B' UNION ALL SELECT 'SBU C', 'SBU C'

3. Alteração à tabela Linha para criação dum novo campo que será a chave externa para associação à nova tabela recém-criada:

ALTER TABLE [dbo].[Linha] ADD SBU nvarchar(24) NULL

4. Estabelecimento da associação entre a tabela Linha e a tabela SBU:

ALTER TABLE [dbo].[Linha] WITH CHECK ADD CONSTRAINT [FK_Linha_SBU] FOREIGN KEY([SBU]) REFERENCES [dbo].[SBU] ([ID])

5. Preenchimento das associações de cada Linha à respectiva SBU:

UPDATE [dbo].[Linha] SET [SBU] ='SBU A' WHERE [ID] in ('Linha 1', 'Linha 2', 'Linha 3', 'Linha 4', 'Linha 5')

UPDATE [dbo].[Linha] SET [SBU] ='SBU B' WHERE [ID] in ('Linha 6', 'Linha 7', 'Linha 8')

UPDATE [dbo].[Linha] SET [SBU] ='SBU C' WHERE [ID] in ('Linha 9', 'Linha 10', 'Linha 11')

Constatamos 5 passos necessários, 3 dos quais (1, 3 e 4) envolvendo reestruturação do esquema físico da base de dados (operações de DDL), o que implica paragem do sistema, tarefas especializadas de administração de base de dados, e novo arranque, impacto que se pretende evitar.

4.6.3.2. Impacto na consulta aos dados

Conforme mostra a Figura 24, nas consultas da primeira camada o cruzamento entre dimensões efectua-se referindo explicitamente as respectivas tabelas; ou seja, para filtrar pela nova SBU, novo código tem de ser escrito referindo e associando a nova tabela.

Refira-se que, mesmo independentemente de alterações às estruturas, as consultas apresentam também à partida o problema de apenas dizerem respeito a uma única combinação de níveis de parâmetros seleccionados. Ou seja, para o dashboard ser inteiramente funcional para além do âmbito restrito do presente teste, todas as configurações possíveis de consultas devem estar previamente codificadas, o que apresenta os seguintes inconvenientes graves:

. esforço na implementação inicial, e não só nas alterações, implicando tempo, especialização e risco, e

. necessidade de executar as consultas por SQL dinâmico, única forma de o próprio código constituir uma variável, com prejuízo na performance, e dificuldade na depuração (Connolly & Begg, 2005).

4.6.4. Objectivo de redução de impacto

O ideal seria não haver necessidade de fazer absolutamente nada em resposta a alterações no negócio, mas tal é evidentemente impossível, pois o conhecimento que consiste nas novas regras tem sempre de ser introduzido no DW: não é evidentemente possível o sistema adivinhar quando e quais os novos níveis hierárquicos que a Gestão decide.

Por isso há passos que são sempre irredutíveis, neste caso verifica-se serem apenas os passos 2 e 5, que consistem em passar para dentro do DW a informação de . novas instâncias de entidades criadas, e . novas associações entre instâncias criadas.

4.6.5. Estratégia de redução de impacto

Para tal simplicidade da informação efectivamente necessária para um sistema como o que estamos a considerar, verifica-se serem suficientes os conceitos de instância e de associação, libertando-nos da discussão que habitualmente envolve modelos com maior complexidade de elementos, para decidir a classificação em entidades, atributos, membros, nós, objectos, vários tipos de associações, ou outras definições da literatura (Thomsen, 2002).

Pensando nestes termos, concluímos que o modelo de que necessitamos, só com instâncias e associações, é um modelo de grafos (Diestel, 2010), tal como era o modelo network (Bachman, 1969; Codd, 1970), que no entanto foi abandonado no mundo empresarial por ser considerado inferior ao relacional.

Não obstante, a revisão efectuada da literatura indicia que as grandes limitações do modelo foram a não-independência dos dados em relação às plataformas de hardware e software, e a falta de uma linguagem de alto nível, declarativa, impedindo o grau de abstracção lógica que um DBMS deveria proporcionar, e não tanto uma inadequação do modelo lógico em si (Codd, 1970).

Surge então a ideia de implementar um modelo network / grafo sobre tabelas do modelo relacional, aproveitando simultaneamente a plataforma provada do RDBMS como gestor de bases de dados, e a flexibilidade lógica que proporciona uma estrutura em rede.

No caso específico da alteração a implementar (criação e associação da entidade SBU), podemos ver na Figura 28 a comparação entre o modelo relacional e o modelo de grafos, destacando-se no primeiro a abstracção a nível de tabelas, simplificando o entendimento da realidade e o estabelecimento de regras (impedir a associação de algo diferente duma Linha, por exemplo um produto, à SBU).

Figura 28. Modelo ER vs modelo de grafos

No entanto, a nível de implementação concreta (instanciação), o modelo de grafos é vantajoso em termos de flexibilidade, permitindo associações de n para n sem recurso a tabelas de conexão (por ex: tabela Zona/DIM), associações ocasionais (por exemplo, um empregado que também é cliente, sem ser necessário criar uma modelação própria para cada excepção) e hierarquias assimétricas em geral (Bachman, 1969).

Ao utilizar um modelo de grafos, em que não existe explicitação de entidades, conseguimos eliminar duma só vez criações e alterações de tabelas, logo os passos 1, 3 e 4 de manutenção acima referidos, conforme o objectivo de redução de impacto, indiciando ser esta a estratégia a seguir.

4.6.6. Desenvolvimento do conceito

Há agora que decidir a melhor forma de colocar, em tabelas do modelo relacional, as instâncias (ou nós na terminologia de grafos) e respectivas associações.

Por definição, os nós são atómicos, e as suas eventuais características são atribuídas por ligação binária a outros nós (Diestel, 2010), logo é viável definir apenas duas tabelas, cuja configuração imutável serve o objectivo de independência e simplicidade da estrutura: uma tabela de uma só coluna (chave) para os nós, e outra de duas colunas (chave) para as associações (Figura 29).

No entanto, perdeu-se o conceito, inerente ao pensamento humano, de entidade, que se traduz intuitivamente em tabelas, aspecto a que o modelo relacional deve parte da sua popularidade. Mesmo os ficheiros dos primeiros sistemas de suporte à decisão geralmente representavam tabelas (Connolly & Begg, 2005).

Concretamente, no dashboard previsto, é necessário escolher dimensões (níveis de hierarquias) que agora não existem por si, e que no modelo relacional existiam sob forma de tabelas que funcionavam como receptáculos. Por isso, é necessário repôr de alguma forma a definição de entidades.

Uma solução possível é criar as entidades como nós e associá-las aos outros nós, como representado a vermelho na Figura 30.

100

Nó Associação Linha 1 Linha 1 SBU A Linha 2 Linha 2 SBU A Linha 3 Linha 3 SBU A Linha 4 Linha 4 SBU A Linha 5 Linha 5 SBU A Linha 6 Linha 6 SBU B Linha 7 Linha 7 SBU B Linha 8 Linha 8 SBU B Linha 9 Linha 9 SBU C Linha 10 Linha 10 SBU C Linha 11 Linha 11 SBU C SBU A Linha 1 Linha SBU B Linha 2 Linha SBU C Linha 3 Linha Linha Linha 4 Linha SBU Linha 5 Linha Linha 6 Linha Linha 7 Linha Linha 8 Linha Linha 9 Linha Linha 10 Linha Linha 11 Linha SBU A SBU SBU B SBU SBU C SBU Figura 30. Entidades acrescentadas e associadas como nós.

101

Efectivamente, agora conseguimos assegurar toda a informação de que dispúnhamos no relacional. E como qualquer nova definição de tabela ou de associação não requer nenhuma criação física, apenas uma inserção de registos, não exigindo nem paragem do sistema nem mão-de-obra especializada, continua a cumprir-se o objectivo pretendido.

No entanto, esta solução apenas será válida se claramente as vantagens superarem as desvantagens. Analisando melhor o que obtivemos, o maior problema com que nos depararamos agora, no mundo real, é necessitarmos de garantir chaves distintas para todas as instâncias de entidades do negócio, o que é impossível de conseguir entre entidades diferentes (por exemplo, um produto pode ter o mesmo código que um cliente por casualidade).

Uma outra questão é a da repetição do registo de cada instância, primeiro na tabela de nós, depois na tabela de associações para registar a entidade que a caracteriza, o que é fastidioso e propício a erros e falhas de integridade.

Sendo esta solução radical, não existindo mais irredutibilidade possível dos dados, e sabendo-se que apresenta um esquema inalterável, mas também os inconvenientes referidos, vamos tentar obter uma solução menos extrema, e o mais possível fácil de entender e manejar, enquanto continuando a evitar alterações ao esquema.

4.6.7. Aperfeiçoamento do conceito

Continuando a aproveitar o despojamento do exemplo para melhor foco no conceito, acrescentamos-lhe agora apenas a entidade Empresa para exemplificar associações a mais que uma entidade, que ilustram melhor diferenças entre modelos.

Vamos observar lado a lado, na Figura 31, a solução relacional (rígida mas intuitiva) e a solução extrema (flexível mas mais complexa), e do confronto procurar induzir uma solução intermédia óptima para o objectivo da investigação).

102

Modelo Relacional Modelo Extremo

Nó Associação ID_Nó ID_1 ID_2 Linha Linha 1 Linha SBU Linha 2 Linha Empresa Linha 3 Linha Linha 1 Linha 4 Linha Linha SBU Linha 2 Linha 5 Linha ID_Linha SBU Empresa ID_SBU Linha 3 Linha 6 Linha Linha 1 SBU A Empresa2 SBU A Linha 4 Linha 7 Linha Linha 2 SBU A Empresa1 SBU B Linha 5 Linha 8 Linha Linha 3 SBU A Empresa1 SBU C Linha 6 Linha 9 Linha Linha 4 SBU A Empresa3 Linha 7 Linha 10 Linha Linha 5 SBU A Empresa3 Linha 8 Linha 11 Linha Linha 6 SBU B Empresa3 Linha 9 SBU A SBU Linha 7 SBU B Empresa2 Empresa Linha 10 SBU B SBU Linha 8 SBU B Empresa2 ID_Empresa Linha 11 SBU C SBU Linha 9 SBU C Empresa3 Empresa1 SBU A Empresa1 Empresa Linha 10 SBU C Empresa1 Empresa2 SBU B Empresa2 Empresa Linha 11 SBU C Empresa3 Empresa3 SBU C Empresa3 Empresa Empresa1 Linha 1 SBU A Empresa2 Linha 2 SBU A Empresa3 Linha 3 SBU A Linha 4 SBU A Linha 5 SBU A Linha 6 SBU B Linha 7 SBU B Linha 8 SBU B Linha 9 SBU C Linha 10 SBU C Linha 11 SBU C Linha 1 Empresa2 Linha 2 Empresa1 Linha 3 Empresa1 Linha 4 Empresa3 Linha 5 Empresa3 Linha 6 Empresa3 Linha 7 Empresa2 Linha 8 Empresa2 Linha 9 Empresa3 Linha 10 Empresa1 Linha 11 Empresa3

SBU Empresa

Linha Figura 31. Modelos ER, relacional e de grafos (extremo).

103

O modelo ER é conceptual, de alto nível, descrevendo a realidade (“as Linhas pertencem a Empresas e SBUs”), podendo traduzir-se numa qualquer implementação lógica, como neste caso: ou no modelo relacional ou neste modelo extremo.

O modelo lógico relacional, por se encontrar por definição também a um nível elevado, o da relação/tabela/entidade), confunde-se, quando na forma abreviada em que não revela atributos, com o modelo ER.

Quanto ao modelo lógico extremo, o seu diagrama de rede completo encontra- se na Figura 32, com as entidades a funcionarem como simples nós.

Linha Linha 1

Linha 2

Linha 3

Linha 4

SBU A Linha 5 Empresa 1

SBU SBU B Linha 6 Empresa 2 Empresa

SBU C Linha 7 Empresa 3

Linha 8

Linha 9

Linha 10

Linha 11

Figura 32. Modelo lógico em rede extremo (grafos).

Bachman (1969), na sua definição de Data Structure Diagram (DSD) – modelo semelhante ao modelo ER como se pode observar na parte inferior da Figura 33 -, associado ao modelo de dados em rede, descreve uma distinção clara (ortogonal nas suas palavras) entre Entidades (Classes) e Associações (Sets).

104

Tal corresponde, logicamente, à Figura 33, na qual as Entidades (Empresa, Linha e SBU) não desaparecem, mas passam a constituir classes à parte, deixando de ser simples nós asssociados. Linha

Linha 1

Linha 2

SBU Linha 3 Empresa

Linha 4

SBU A Linha 5 Empresa 1

SBU B Linha 6 Empresa 2

SBU C Linha 7 Empresa 3

Linha 8

Linha 9

Linha 10

Linha 11

SBU Empresa

Linha

Figura 33. Modelo lógico em rede e respectivo DSD.

Designaremos então provisoriamente por modelo Z uma possível representação do modelo em rede sobre tabelas do modelo relacional (cujo conceito se ilustra na Figura 34), conseguida pela evolução do modelo de grafos através das seguintes alterações:

105

. Um campo adicional identifica a entidade de cada instância na tabela de nós, passando a constituir chave a combinação do ID de entidade com o ID da instância. . Para reflectir a nova chave na tabela de associação, duas novas colunas são aí criadas.

Nó Associação ID_Tabela ID_Item ID_Tabela_1 ID_Item_1 ID_Tabela_2 ID_Item_2 Linha Linha 1 Linha Linha 1 SBU SBU A Linha Linha 2 Linha Linha 2 SBU SBU A Linha Linha 3 Linha Linha 3 SBU SBU A Linha Linha 4 Linha Linha 4 SBU SBU A Linha Linha 5 Linha Linha 5 SBU SBU A Linha Linha 6 Linha Linha 6 SBU SBU B Linha Linha 7 Linha Linha 7 SBU SBU B Linha Linha 8 Linha Linha 8 SBU SBU B Linha Linha 9 Linha Linha 9 SBU SBU C Linha Linha 10 Linha Linha 10 SBU SBU C Linha Linha 11 Linha Linha 11 SBU SBU C SBU SBU A Linha Linha 1 Empresa Empresa2 SBU SBU B Linha Linha 2 Empresa Empresa1 SBU SBU C Linha Linha 3 Empresa Empresa1 Empresa Empresa1 Linha Linha 4 Empresa Empresa3 Empresa Empresa2 Linha Linha 5 Empresa Empresa3 Empresa Empresa3 Linha Linha 6 Empresa Empresa3 Linha Linha 7 Empresa Empresa2 Linha Linha 8 Empresa Empresa2 Linha Linha 9 Empresa Empresa3 Linha Linha 10 Empresa Empresa1 Linha Linha 11 Empresa Empresa3

Figura 34. Modelo Z.

Codd (1990) aponta como uma das razões porque um modelo binário como o modelo em rede não seria capaz de substituir o relacional, o facto de, existindo n atributos numa relação (tabela), a conversão, consistindo em n relações binárias (a chave e um atributo de cada vez), implicar a criação de n tabelas, o que é problemático se n for elevado9.

9 É o que acontece com o Anchor model (Rönnbäck et al, 2010a).

106

A presente abordagem Z evita esse inconveniente, ao unir todas as n micro- tabelas numa única, a tabela de nós. Tal apenas se consegue pela concessão que aqui é assumida, de admitir um formato único para todos os atributos e chaves, com o seguinte racional:

1. A opção por uma formatação única tem precisamente o objectivo de conseguir a união de todas as possíveis tabelas numa única, inalterável, e permitir um tratamento genérico dos dados.

2. O objectivo deste modelo de dados está focado e limitado a data warehousing e OLAP, onde a informação de cada atributo serve essencialmente para determinar dimensões e hierarquias e habitualmente consiste em apenas um nome, não existindo a necessidade de guardar campos mais especificamente formatados, como em formulários ou écrans de interacção OLTP.

3. Actualmente, o espaço em disco encontra-se cada vez mais acessível e disponível, pelo que atribuir um comprimento fixo suficientemente grande (no exemplo são utilizados 24 caracteres) para um campo universal já não resulta problemático10, como ainda era no início dos anos 1990.

Com apenas duas tabelas de estrutura fixa, todas as tarefas administrativas de criação ou destruição de tabelas, associações entre tabelas, e campos, deixam de existir, minimizando o esforço necessário a alterações no DW devidas a alterações no negócio, ou seja conseguindo alinhamento total com o objectivo da investigação.

Acrescentando o elemento Tempo, obtemos na Figura 35 a aplicação do racional Z aos dados finais do exemplo que acompanhou a revisão de literatura, permitindo a comparação da nova estrutura proposta com a estrutura de dimensões dos modelos estudados.

10 Além disso, um eventual desperdício de armazenamento será compensado por ganhos implícitos ao modelo aqui estudado, como será abordado mais adiante.

107

Tabelas Associações Tempo Tabela Item Tempo Tabela_1 Item_1 Tabela_2 Item_2 Mar-12 DIM DIM 040 Mar-12 DIM DIM 040 Supervisor CR 007 Mar-12 DIM DIM 038 Mar-12 DIM DIM 038 Supervisor CR 005 Mar-12 DIM DIM 117 Mar-12 DIM DIM 117 Supervisor CR 029 Mar-12 DIM DIM 116 Mar-12 DIM DIM 116 Supervisor CR 027 Mar-12 DIM DIM 044 Mar-12 DIM DIM 044 Supervisor CR 008 Mar-12 DIM DIM 009 Mar-12 DIM DIM 009 Supervisor CR 004 Mar-12 DIM DIM 010 Mar-12 DIM DIM 010 Supervisor CR 004 Mar-12 DIM DIM 084 Mar-12 DIM DIM 084 Supervisor CR 019 Mar-12 DIM DIM 106 Mar-12 DIM DIM 106 Supervisor CR 023 Mar-12 DIM DIM 105 Mar-12 DIM DIM 105 Supervisor CR 023 Abr-12 DIM DIM 040 Abr-12 DIM DIM 040 Supervisor CR 007 Abr-12 DIM DIM 038 Abr-12 DIM DIM 038 Supervisor CR 005 Abr-12 DIM DIM 117 Abr-12 DIM DIM 117 Supervisor CR 029 Abr-12 DIM DIM 116 Abr-12 DIM DIM 116 Supervisor CR 027 Abr-12 DIM DIM 044 Abr-12 DIM DIM 044 Supervisor CR 004 Abr-12 DIM DIM 009 Abr-12 DIM DIM 009 Supervisor CR 004 Abr-12 DIM DIM 010 Abr-12 DIM DIM 010 Supervisor CR 004 Abr-12 DIM DIM 084 Abr-12 DIM DIM 084 Supervisor CR 019 Abr-12 DIM DIM 106 Abr-12 DIM DIM 106 Supervisor CR 023 Abr-12 DIM DIM 105 Abr-12 DIM DIM 105 Supervisor CR 023 Mar-12 Supervisor CR 007 Mar-12 Supervisor CR 007 Linha Linha 2 Mar-12 Supervisor CR 005 Mar-12 Supervisor CR 005 Linha Linha 2 Mar-12 Supervisor CR 029 Mar-12 Supervisor CR 029 Linha Linha 10 Mar-12 Supervisor CR 027 Mar-12 Supervisor CR 027 Linha Linha 10 Mar-12 Supervisor CR 008 Mar-12 Supervisor CR 008 Linha Linha 3 Mar-12 Supervisor CR 004 Mar-12 Supervisor CR 004 Linha Linha 1 Mar-12 Supervisor CR 019 Mar-12 Supervisor CR 019 Linha Linha 7 Mar-12 Supervisor CR 023 Mar-12 Supervisor CR 023 Linha Linha 8 Abr-12 Supervisor CR 007 Abr-12 Supervisor CR 007 Linha Linha 1 Abr-12 Supervisor CR 005 Abr-12 Supervisor CR 005 Linha Linha 1 Abr-12 Supervisor CR 029 Abr-12 Supervisor CR 029 Linha Linha 10 Abr-12 Supervisor CR 027 Abr-12 Supervisor CR 027 Linha Linha 10 Abr-12 Supervisor CR 004 Abr-12 Supervisor CR 004 Linha Linha 1 Abr-12 Supervisor CR 019 Abr-12 Supervisor CR 019 Linha Linha 7 Abr-12 Supervisor CR 023 Abr-12 Supervisor CR 023 Linha Linha 8 Mar-12 Linha Linha 2 Mar-12 Linha Linha 2 Empresa NossaEmpresa1 Mar-12 Linha Linha 10 Mar-12 Linha Linha 10 Empresa NossaEmpresa1 Mar-12 Linha Linha 3 Mar-12 Linha Linha 3 Empresa NossaEmpresa1 Mar-12 Linha Linha 1 Mar-12 Linha Linha 1 Empresa NossaEmpresa2 Mar-12 Linha Linha 7 Mar-12 Linha Linha 7 Empresa NossaEmpresa2 Mar-12 Linha Linha 8 Mar-12 Linha Linha 8 Empresa NossaEmpresa2 Abr-12 Linha Linha 10 Abr-12 Linha Linha 10 Empresa NossaEmpresa1 Abr-12 Linha Linha 1 Abr-12 Linha Linha 1 Empresa NossaEmpresa2 Abr-12 Linha Linha 7 Abr-12 Linha Linha 7 Empresa NossaEmpresa2 Abr-12 Linha Linha 8 Abr-12 Linha Linha 8 Empresa NossaEmpresa2 Mar-12 Empresa NossaEmpresa1 Mar-12 Produto Produto 2337 Empresa NossaEmpresa1 Mar-12 Empresa NossaEmpresa2 Mar-12 Produto Produto 2535 Empresa NossaEmpresa2 Abr-12 Empresa NossaEmpresa1 Mar-12 Produto Produto 2542 Empresa NossaEmpresa2 Abr-12 Empresa NossaEmpresa2 Abr-12 Produto Produto 2337 Empresa NossaEmpresa1 Mar-12 Zona Zona400 Abr-12 Produto Produto 2535 Empresa NossaEmpresa2 Mar-12 Zona Zona410 Mar-12 DIM DIM 009 Zona Zona400 Abr-12 Zona Zona400 Mar-12 DIM DIM 010 Zona Zona410 Abr-12 Zona Zona410 Mar-12 DIM DIM 038 Zona Zona400 Mar-12 Produto Produto 2337 Mar-12 DIM DIM 040 Zona Zona410 Mar-12 Produto Produto 2535 Mar-12 DIM DIM 044 Zona Zona400 Mar-12 Produto Produto 2542 Mar-12 DIM DIM 044 Zona Zona410 Abr-12 Produto Produto 2337 Mar-12 DIM DIM 084 Zona Zona400 Abr-12 Produto Produto 2535 Mar-12 DIM DIM 084 Zona Zona410 Mar-12 DIM DIM 105 Zona Zona410 Mar-12 DIM DIM 106 Zona Zona400 Mar-12 DIM DIM 116 Zona Zona400 Mar-12 DIM DIM 117 Zona Zona410 Abr-12 DIM DIM 009 Zona Zona400 Abr-12 DIM DIM 010 Zona Zona410 Abr-12 DIM DIM 038 Zona Zona400 Abr-12 DIM DIM 040 Zona Zona410 Abr-12 DIM DIM 044 Zona Zona400 Abr-12 DIM DIM 084 Zona Zona400 Abr-12 DIM DIM 084 Zona Zona410 Abr-12 DIM DIM 105 Zona Zona410 Abr-12 DIM DIM 106 Zona Zona400 Abr-12 DIM DIM 116 Zona Zona400 Abr-12 DIM DIM 117 Zona Zona410 Figura 35. Modelo Z - estrutura de dimensões do exemplo da revisão de literatura.

108

4.7. IMPLEMENTAÇÃO DO MODELO Z

4.7.1. Modelo físico

O conceito a testar estando identificado, para a sua implementação (criando uma base de dados Z) vai-se efectuar ainda o seguinte ajuste no sentido de o tornar totalmente funcional e aplicável a uma utilização real: acrescento de uma coluna na tabela de nós, de maneira a poder registar-se, para além do código identificador único (ID), um nome para cada nó.

Estando o modelo relacional fundado em lógica matemática, é trivial criar algoritmos de conversão entre este e outro modelo lógico (Codd, 1990). Assim, foram criadas duas rotinas na base de dados UTI (Apêndices 6 e 7):

. UTI_Build_Z (para criar um modelo Z a partir dum modelo relacional) e . UTI_Build_R (para criar um modelo relacional a partir dum modelo Z),

A rotina UTI_Build_Z recebe como parâmetros o nome do modelo relacional a converter, e uma data para atribuir aos registos de estrutura. Corremos a rotina, colocando ‘R’ como nome da base de dados onde se encontra o modelo relacional, e ‘201203’ como mês. O resultado é a criação duma base de dados com o nome “Z_R_201203” seguido de um carimbo temporal (timestamp), que renomeámos Z.

A nova base de dados apenas contém duas tabelas, Tables (tabela de tabelas de nós) e Groups (tabela de associações entre nós11), preenchidas com todos os elementos que constituem a estrutura existente na base de dados R, e tendo estabelecidas as chaves primárias, e externas que as relacionam entre si (Figura 36).

11 Convencionados chamarem-se ChildTable e ParentTable devido ao tipo da maioria de relações habituais, mas efectivamente servindo para configurar qualquer tipo de associação.

109

Figura 36. Modelo físico Z.

Todas as estruturas de dimensões do modelo relacional encontram-se inteiramente reproduzidas nestas duas tabelas, de que a Figura 37 e a Figura 38 mostram alguns registos. Para fins de simplicidade e clareza neste estudo, as chaves de instâncias (nós) foram aqui definidas como iguais aos nomes.

Figura 37. Tabela Tables.

110

Figura 38. Tabela Groups.

Em seguida, importamos para a base de dados Z as tabelas de factos elementares Facts_2D (que incluem todos os factos relativos a eventos bidimensionais, como vendas) e Facts_3D (eventos tridimensionais, como visitas) a partir de R, para completar os dados.

4.7.2. Avaliação de impacto de alterações em Z

Para obtermos a mesma alteração que foi efectuada no modelo relacional, correspondente ao modelo ER da Figura 27, necessitamos efectuar em Z apenas os seguintes dois passos, que podem ser concretizados por simples cópia e colagem a partir de uma folha de cálculo:

1. Introdução dos registos representando as SBU:

INSERT INTO [dbo].[Tables] ([TimeItemID],[TableID],[TableItemID],[TableItemName])

SELECT '201203', '0', 'SBU', 'SBU' UNION ALL SELECT '201203', 'SBU', 'SBU A', 'SBU A' UNION ALL SELECT '201203', 'SBU', 'SBU B', 'SBU B' UNION ALL SELECT '201203', 'SBU', 'SBU C', 'SBU C'

111

2. Preenchimento das associações de cada Linha à respectiva SBU

INSERT INTO [dbo].[Groups] ([TimeItemID],[ChildTableID],[ChildTableItemID], [ParentTableID],[ParentTableItemID])

SELECT '201203', 'Linha', 'Linha 1', 'SBU', 'SBU A' UNION ALL SELECT '201203', 'Linha', 'Linha 2', 'SBU', 'SBU A' UNION ALL SELECT '201203', 'Linha', 'Linha 3', 'SBU', 'SBU A' UNION ALL SELECT '201203', 'Linha', 'Linha 4', 'SBU', 'SBU A' UNION ALL SELECT '201203', 'Linha', 'Linha 5', 'SBU', 'SBU A'

UNION ALL SELECT '201203', 'Linha', 'Linha 6', 'SBU', 'SBU B' UNION ALL SELECT '201203', 'Linha', 'Linha 7', 'SBU', 'SBU B' UNION ALL SELECT '201203', 'Linha', 'Linha 8', 'SBU', 'SBU B'

UNION ALL SELECT '201203', 'Linha', 'Linha 9', 'SBU', 'SBU C' UNION ALL SELECT '201203', 'Linha', 'Linha 10', 'SBU', 'SBU C' UNION ALL SELECT '201203', 'Linha', 'Linha 11', 'SBU', 'SBU C'

Desta forma, confirmamos a validade da implementação Z, pois a sua génese fora fundamentada pela redução das tarefas de manutenção a estas duas operações de manipulação de dados (DML), poupando trabalho e sobretudo evitando uma paragem do sistema.

4.7.3. Consulta de dados

Apenas é necessáro agora alterar o algoritmo da consulta para conseguir referenciar as “tabelas” no novo formato, e testar o resultado.

É essencialmente a camada inferior da consulta que necessita ser convertida, pois agora o acesso não se faz através das várias tabelas de entidades, mas através da única tabela Tables, a Figura 39 substituindo a Figura 24. O script completo da consulta redesenhada encontra-se no Apêndice 8.

Correndo a nova consulta, com os mesmos parâmetros utilizados anteriormente sobre o modelo relacional (Tabela 3), obtêm-se os mesmos registos, mas agora a uma média de 19,789 segundos, ou seja cerca de 10 vezes mais lentamente.

Logo, depreende-se que a utilização de uma única tabela na mesma consulta, simulando várias tabelas relacionando-se entre si, implica radicalmente uma

112

deterioração no desempenho, que ainda assim pode ser teoricamente equacionada face à vantagem de independência do modelo que permite reduzir a complexidade de manutenção.

MS regional

MS nacional

Figura 39. Camada inferior da consulta para o modelo Z.

4.7.4. Modelo Z com cubo de pré-agregação (Z_c)

Tal como no caso do modelo relacional, a razão principal para o tempo elevado de consulta é a ocorrência de vários joins encadeados ao longo das hierarquias (Moody & Kortink, 2000), pelo que teoricamente a utilização de um cubo pré-agregado deverá neste caso também resultar.

113

Modelo de dados

Figura 40. Dos dados ao dashboard - modelo relacional (c/cubo) vs Z_c

114

Da mesma forma que anteriormente, a consulta pode ser adaptada para passar a carregar um cubo, e uma nova ad-hoc, igual à do relacional pois o cubo é idêntico (Apêndice 5), passa a aceder directamente aos dados pré-calculados.

Testamos novamente, agora obtendo uma velocidade média de 0,150 segundos, ligeiramente melhor que no caso da implementação do cubo com o modelo relacional, indicando-nos termos já conseguido um modelo que responde ao objectivo da investigação, pois consegue reduzir a manutenção necessária em relação ao modelo tradicional, com a vantagem acrescida de não necessitar para tal de qualquer compromisso a nível de desempenho.

A Figura 40, pela eliminação da barra vermelha inferior, destaca onde se encontra a mais-valia do modelo desenvolvido em Z face ao relacional: ao nível do modelo de dados, por tornar universal a estrutura de entidades.

A nível de estrutura de eventos/factos, que se mantém, esta continua dependente da respectiva dimensionalidade, cuja probabilidade de alteração é no entanto inferior à da estrutura de entidades, assinalando-se com uma barra mais clara.

Note-se que, apesar de agora existir uma tabela genérica, esta tem de ser utilizada na consulta um número de vezes variável conforme os níveis de hierarquias escolhidos (joins encadeados), pelo que a consulta mantém um grau de inflexibilidade indesejado (barra vermelha).

4.7.5. Modelo Z com associações directas (Z_d)

Reflectindo no facto de que o encadeamento de joins prejudica a performance e também a flexibilidade (Connolly & Begg, 2005; Moody & Kortink, 2000), deduz-se que qualquer melhoria ao modelo deverá passar pela sua eliminação.

A forma de eliminar joins intermédios é, logicamente e por definição, executar joins directos. Para tal, há que explicitar todas as associações na base de dados, o que,

115

no modelo Z, é bastante mais fácil que no modelo relacional (que implica a alteração às tabelas para criação de novos campos). No modelo Z, basta acrescentar registos à tabela de associações.

Tal operação, pela sua simplicidade e carácter genérico, pode ser executada por um algoritmo (Apêndice 9) generalizável a qualquer caso de negócio, que assim automatiza a criação das associações directas correspondentes a associações indirectas, e assim cria uma materialização de todas as associações possíveis, com as seguintes vantagens em relação a uma materialização de consultas (cubo):

. esta nova materialização é puramente lógica, logo polivalente e não limitada a um formato arbitrário, como no caso do cubo, neste estudo formatado para uma consulta específica;

. menor espaço gasto em disco, pois não estão materializados os cálculos, e as redundâncias estão minimizadas a associações binárias;

. sendo possíveis todas as combinações, não é necessário recorrer a soluções de compromisso na pré-agregação.

O inconveniente em relação ao cubo será previsivelmente a performance, na medida em que os cálculos são efectuados no momento; no entanto teoricamente a penalização não será tão grande como no cálculo sem nenhuma materialização prévia, pois apenas se vai utilizar agora joins de primeiro grau.

Para testar o conceito, criamos uma base de dados Z_d, para a qual copiamos da Z, as tabelas de estruturas Tables e Groups, e de factos elementares Facts_2D e Facts_3D, e corremos a rotina que cria as associações directas em Groups.

Com qualquer associação possível definida directamente, a consulta de informação de dashboard agora apenas necessita utilizar um único nível no acesso a cada hierarquia, podendo ser tornada genérica a quaisquer parâmetros de consulta (Apêndice 10).

116

MS regional

MS nacional

Figura 41. Camada inferior da consulta para o modelo Z_d.

A Figura 41 mostra o esquema da nova camada inferior da consulta, única que foi

necessário alterar. No cálculo da MSR verifica-se não só a economia de joins na hierarquia geográfica, com apenas uma ligação, mas sobretudo a invariabilidade dessa estrutura em Z_d, contrariamente a Z (Figura 39), em que o número de joins depende do nível seleccionado da hierarquia: neste caso, 3 para DIM, mas seriam 4 para Supervisor, 5 para Linha, etc12.

Note-se que embora existindo invariabilidade da consulta à estrutura de entidades, tal como apontado anteriormente em relação ao próprio modelo de dados, e por essa razão, persiste rigidez quanto à estrutura de eventos.

Testando a consulta como nos casos anteriores com os parâmetros da Tabela 3, obtém-se agora um tempo médio de 1,195 segundos, mantendo-se melhores as

12 No caso da hierarquia de produto, 3 joins são sempre e apenas necessários em Z_d (para os níveis de filtro e de detalhe, e para o mercado de referência), número que casualmente coincidiu com Z, onde maior número será necessário para níveis hierárquicos superiores.

117

soluções com cubo conforme esperado, no entanto muito razoável sendo cerca de metade do tempo da consulta relacional sem cubo (R).

Assim, neste ponto, o modelo Z_d é o que melhor se alinha com o objectivo da investigação, pois consegue, tanto no modelo como na consulta, uma generalização em relação à estrutura de entidades (tabelas de dimensões no modelo relacional) – evitando a paragem do sistema para reconfiguração -, e não necessita do esforço e recursos para criação de um cubo, ao que acresce tal ser conseguido sem grande penalização no desempenho.

4.7.6. Modelo relacional com associações directas

Tal como se testou a estratégia de pré-agregação em cubo no modelo Z à semelhança do modelo relacional, por simetria de raciocínio surge a questão da eventual pertinência de adaptar a estratégia de associações directas também ao modelo relacional – prosseguindo no sentido de isolar experimentalmente os efeitos de cada abordagem.

No entanto, é facilmente perceptível que se trata de uma via que não interessa a esta investigação, porque apenas traria um eventual benefício de performance pela redução de joins, mas continuaria a necessitar do mesmo número de tabelas, e da sua alteração para acrescento de uma coluna adicional para cada associação, pelo que não garantiria a independência nem do modelo nem das consultas.

118

4.8. IDENTIFICAÇÃO DE ALTERNATIVA AO MODELO DE FACTOS

4.8.1. Necessidade

Ao modelo Z_d apenas falta satisfazer a condição de independência em relação à estrutura de eventos. No caso estudado, é a razão para a existência de duas tabelas de factos elementares com número diferente de colunas (dimensões), pois o modelo implica existirem pelo menos sempre tantas quantas as diferentes dimensionalidades.

Para cumprir o objectivo de se conseguir um modelo totalmente transversal a diversos tipos de negócio, há que equacionar como configurar uma tabela que aceite factos com dimensionalidades diferentes, sem necessitar ser alterada, e assegurando as respectivas consultas.

4.8.2. Solução

Uma potencial solução consistiria num número de colunas suficientemente grande, mas tal abordagem apresenta os seguintes aspectos negativos: . dificuldade de determinar o que significa “suficientemente grande”; . risco de ainda assim poder-se exceder esse número; . esparsidade dos dados em colunas vazias nas dimensionalidades mais baixas desperdiçando espaço em disco; . dificuldade na identificação de cada coluna, por poder servir diferentes eventos; . implica que as consultas, para serem genéricas, utilizem também sempre todas as colunas, o que seria ineficiente.

Não se optando pela distribuição das dimensões por colunas, a alternativa deverá ser uma abordagem vertical dos factos, com uma única coluna de valores, identificada pelas colunas tempo, tipo de métrica, e referência de cruzamento de dimensões, este último campo estando descodificado numa tabela própria, com as coordenadas também na vertical, permitindo referenciar um número ilimitado de dimensões.

119

Visitas Factos Coordenadas Tempo Métrica TabelaProd ItemProd TabelaGeo ItemGeo TabelaOrg ItemOrg Valor Tempo Coordenada Métrica Valor Coordenada Tabela Item Mar-12 Visitas Produto Produto 2337 Zona Zona400 DIM DIM 038 17 Mar-12 P2337Z400D038 Visitas 17 P2337Z400D038 Produto Produto 2337 Mar-12 Visitas Produto Produto 2337 Zona Zona400 DIM DIM 044 8 Mar-12 P2337Z400D044 Visitas 8 P2337Z400D038 Zona Zona400 Mar-12 Visitas Produto Produto 2337 Zona Zona400 DIM DIM 116 21 Mar-12 P2337Z400D116 Visitas 21 P2337Z400D038 DIM DIM 038 Mar-12 Visitas Produto Produto 2337 Zona Zona410 DIM DIM 040 13 Mar-12 P2337Z410D040 Visitas 13 P2337Z400D044 Produto Produto 2337 Mar-12 Visitas Produto Produto 2337 Zona Zona410 DIM DIM 044 14 Mar-12 P2337Z410D044 Visitas 14 P2337Z400D044 Zona Zona400 Mar-12 Visitas Produto Produto 2337 Zona Zona410 DIM DIM 117 26 Mar-12 P2337Z410D117 Visitas 26 P2337Z400D044 DIM DIM 044 Mar-12 Visitas Produto Produto 2535 Zona Zona400 DIM DIM 009 18 Mar-12 P2535Z400D009 Visitas 18 P2337Z400D116 Produto Produto 2337 Mar-12 Visitas Produto Produto 2535 Zona Zona400 DIM DIM 084 21 Mar-12 P2535Z400D084 Visitas 21 P2337Z400D116 Zona Zona400 Mar-12 Visitas Produto Produto 2535 Zona Zona400 DIM DIM 106 15 Mar-12 P2535Z400D106 Visitas 15 P2337Z400D116 DIM DIM 116 Mar-12 Visitas Produto Produto 2535 Zona Zona410 DIM DIM 010 9 Mar-12 P2535Z410D010 Visitas 9 P2337Z410D040 Produto Produto 2337 Mar-12 Visitas Produto Produto 2535 Zona Zona410 DIM DIM 084 18 Mar-12 P2535Z410D084 Visitas 18 P2337Z410D040 Zona Zona410 Mar-12 Visitas Produto Produto 2535 Zona Zona410 DIM DIM 105 28 Mar-12 P2535Z410D105 Visitas 28 P2337Z410D040 DIM DIM 040 Mar-12 Visitas Produto Produto 2542 Zona Zona400 DIM DIM 009 12 Mar-12 P2542Z400D009 Visitas 12 P2337Z410D044 Produto Produto 2337 Mar-12 Visitas Produto Produto 2542 Zona Zona400 DIM DIM 084 9 Mar-12 P2542Z400D084 Visitas 9 P2337Z410D044 Zona Zona410 Mar-12 Visitas Produto Produto 2542 Zona Zona400 DIM DIM 106 13 Mar-12 P2542Z400D106 Visitas 13 P2337Z410D044 DIM DIM 044 Mar-12 Visitas Produto Produto 2542 Zona Zona410 DIM DIM 010 28 Mar-12 P2542Z410D010 Visitas 28 P2337Z410D117 Produto Produto 2337 Mar-12 Visitas Produto Produto 2542 Zona Zona410 DIM DIM 084 14 Mar-12 P2542Z410D084 Visitas 14 P2337Z410D117 Zona Zona410 Mar-12 Visitas Produto Produto 2542 Zona Zona410 DIM DIM 105 18 Mar-12 P2542Z410D105 Visitas 18 P2337Z410D117 DIM DIM 117 Abr-12 Visitas Produto Produto 2337 Zona Zona400 DIM DIM 038 17 Abr-12 P2337Z400D038 Visitas 17 P2535Z400D009 Produto Produto 2535 Abr-12 Visitas Produto Produto 2337 Zona Zona400 DIM DIM 044 8 Abr-12 P2337Z400D044 Visitas 8 P2535Z400D009 Zona Zona400 Abr-12 Visitas Produto Produto 2337 Zona Zona400 DIM DIM 116 21 Abr-12 P2337Z400D116 Visitas 21 P2535Z400D009 DIM DIM 009 Abr-12 Visitas Produto Produto 2337 Zona Zona410 DIM DIM 040 13 Abr-12 P2337Z410D040 Visitas 13 P2535Z400D084 Produto Produto 2535 Abr-12 Visitas Produto Produto 2337 Zona Zona410 DIM DIM 117 26 Abr-12 P2337Z410D117 Visitas 26 P2535Z400D084 Zona Zona400 Abr-12 Visitas Produto Produto 2535 Zona Zona400 DIM DIM 009 18 Abr-12 P2535Z400D009 Visitas 18 P2535Z400D084 DIM DIM 084 Abr-12 Visitas Produto Produto 2535 Zona Zona400 DIM DIM 084 21 Abr-12 P2535Z400D084 Visitas 21 P2535Z400D106 Produto Produto 2535 Abr-12 Visitas Produto Produto 2535 Zona Zona400 DIM DIM 106 15 Abr-12 P2535Z400D106 Visitas 15 P2535Z400D106 Zona Zona400 Abr-12 Visitas Produto Produto 2535 Zona Zona410 DIM DIM 010 9 Abr-12 P2535Z410D010 Visitas 9 P2535Z400D106 DIM DIM 106 Abr-12 Visitas Produto Produto 2535 Zona Zona410 DIM DIM 084 18 Abr-12 P2535Z410D084 Visitas 18 P2535Z410D010 Produto Produto 2535 Abr-12 Visitas Produto Produto 2535 Zona Zona410 DIM DIM 105 28 Abr-12 P2535Z410D105 Visitas 28 P2535Z410D010 Zona Zona410 Mar-12 P2337Z400 Vendas 500 P2535Z410D010 DIM DIM 010 Vendas Mar-12 P2337Z410 Vendas 2000 P2535Z410D084 Produto Produto 2535 Tempo Métrica TabelaProd ItemProd TabelaGeo ItemGeo Valor Mar-12 P2535Z400 Vendas 3300 P2535Z410D084 Zona Zona410 Mar-12 Vendas Produto Produto 2337 Zona Zona400 500 Mar-12 P2535Z410 Vendas 7000 P2535Z410D084 DIM DIM 084 Mar-12 Vendas Produto Produto 2337 Zona Zona410 2000 Mar-12 P2542Z400 Vendas 670 P2535Z410D105 Produto Produto 2535 Mar-12 Vendas Produto Produto 2535 Zona Zona400 3300 Mar-12 P2542Z410 Vendas 1600 P2535Z410D105 Zona Zona410 Mar-12 Vendas Produto Produto 2535 Zona Zona410 7000 Abr-12 P2337Z400 Vendas 500 P2535Z410D105 DIM DIM 105 Mar-12 Vendas Produto Produto 2542 Zona Zona400 670 Abr-12 P2337Z410 Vendas 2000 P2542Z400D009 Produto Produto 2542 Mar-12 Vendas Produto Produto 2542 Zona Zona410 1600 Abr-12 P2535Z400 Vendas 3300 P2542Z400D009 Zona Zona400 Abr-12 Vendas Produto Produto 2337 Zona Zona400 500 Abr-12 P2535Z410 Vendas 7000 P2542Z400D009 DIM DIM 009 Abr-12 Vendas Produto Produto 2337 Zona Zona410 2000 P2542Z400D084 Produto Produto 2542 Abr-12 Vendas Produto Produto 2535 Zona Zona400 3300 P2542Z400D084 Zona Zona400 Abr-12 Vendas Produto Produto 2535 Zona Zona410 7000 P2542Z400D084 DIM DIM 084 P2542Z400D106 Produto Produto 2542 P2542Z400D106 Zona Zona400 P2542Z400D106 DIM DIM 106 P2542Z410D010 Produto Produto 2542 P2542Z410D010 Zona Zona410 P2542Z410D010 DIM DIM 010 P2542Z410D084 Produto Produto 2542 P2542Z410D084 Zona Zona410 P2542Z410D084 DIM DIM 084 P2542Z410D105 Produto Produto 2542 P2542Z410D105 Zona Zona410 P2542Z410D105 DIM DIM 105 P2337Z400 Produto Produto 2337 P2337Z400 Zona Zona400 P2337Z410 Produto Produto 2337 P2337Z410 Zona Zona410 P2535Z400 Produto Produto 2535 P2535Z400 Zona Zona400 P2535Z410 Produto Produto 2535 P2535Z410 Zona Zona410 P2542Z400 Produto Produto 2542 P2542Z400 Zona Zona400 P2542Z410 Produto Produto 2542 P2542Z410 Zona Zona410 Figura 42. Modelação genérica de factos – conceito e exemplo.

120

A Figura 42 mostra como é possível implementar o conceito, passando alguns registos das tabelas de Vendas e Visitas para uma tabela genérica de Factos, cujas referências são descodificadas numa tabela de Coordenadas, identificando o cruzamento de dimensões a que dizem respeito (o exemplo aqui é novamente o mesmo que foi utilizado ao longo da revisão de literatura).

4.9. IMPLEMENTAÇÃO DO NOVO MODELO DE FACTOS

4.9.1. Modelo físico (Z+)

A Figura 43 mostra do lado esquerdo a representação de factos elementares como foi utilizada nos testes anteriores (R, R_c, Z, Z_c e Z_d) e o novo modelo, a implementar em nova base de dados Z+, mantendo-se a representação de dimensões (no topo), que já era genérica.

Z Z+ Figura 43. Modelação genérica de factos – implementação.

121

Os factos elementares podem ser carregados no novo formato a partir de R, Z ou Z_d através de um algoritmo de conversão (Apêndice 11).

MS regional

MS nacional

Figura 44. Camada inferior da consulta para o modelo Z+.

4.9.2. Consulta de dados

Novamente é necessário alterar o algoritmo da camada inferior da consulta (a partir da versão Z_d) para acomodar um novo formato de tabela (Apêndice 12), passando a consulta a satisfazer plenamente o objectivo da investigação, pois não

122

necessita mais ser alterada por alteração das estruturas nem de dimensões (entidades) nem de eventos (Figura 44).

Testando a consulta como anteriormente com os parâmetros da Tabela 3, obteve-se um tempo médio de 5,469 segundos, cerca de 5 vezes mais lento que em Z_d, no entanto ainda aceitável se for prevista variabilidade frequente na dimensionalidade de eventos, com base em requisitos de negócio e/ou aplicacionais.

É mais provável que tal ocorra em alguma aplicação específica - como por exemplo num contexto de Sistemas Integrados (Caetano & Costa, 2012) - do que em Gestão, pois aí o modelo do evento de Venda ou Actividade, uma vez definido, não tende a variar.

Exemplo disso é a própria indústria farmacêutica, caracterizada actualmente por uma extrema variabilidade a nível de estruturas organizacionais, geográficas e de produtos, mas onde as definições de venda e visita se mantêm, pois havendo conceitos novos (como e-detailing, novos tipos de clientes, ou outras actividades) estes habitualmente são registados com métricas distintas, salvaguardando a dimensionalidade dos registos.

A Figura 45 resume os avanços conseguidos no sentido do objectivo da investigação13, partindo do modelo relacional, as barras vermelhas representando nos pontos críticos inflexibilidade total, as barras mais claras inflexibilidade apenas a alteração na estrutura de eventos, e a sua ausência significando flexibilidade total:

. Modelo relacional: inflexibilidade no modelo de dados e nas consultas. . Modelo Z: inflexibilidade parcial no modelo de dados e total nas consultas. . Modelo Z_d: inflexibilidade parcial no modelo e nas consultas. . Modelo Z+: flexibilidade total.

13 Para a determinação da flexibilidade é irrelevante a utilização ou não de cubo de pré- agregação nos casos R_c e Z_c, só tendo influído na performance.

123

Figura 45. Evolução dos modelos no sentido da generalização.

124

4.10. MODELO DIMENSIONAL

Para obter um outro ponto de referência com práticas habituais em Data warehousing (relacional+dimensional), construímos também um cubo em Microsoft Analysis Services, servidor de cubos OLAP, em modo de armazenamento MOLAP.

Tal efectuou-se criando um projecto de BI em Visual Studio, e conectando-o à base de dados relacional R, ficando a ser utilizado o mesmo modelo (normalizado a mais de 3NF, ou seja um modelo Snowflake). Como o cubo OLAP depende sempre do modelo relacional, qualquer que seja a implementação, MOLAP, ROLAP ou HOLAP, a sua flexibilidade fica limitada à desse modelo.

Em termos de consulta, métricas sofisticadas como o MI e o Evol são de codificação complexa e árdua (Halpin & Morgan, 2008; Vassiliadis & Sellis, 1999) na linguagem que suporta OLAP em SQL Server, MDX (Whitehorn, Zare, & Pasumansky, 2002), e esta não conta com a ajuda de ferramentas gráficas.

Correndo a consulta OLAP (Apêndice 13) correspondente à selecção que temos testado, obtém-se um tempo médio de 0,774 segundos, ligeiramente inferior ao do modelo relacional original, mas superior aos tempos obtidos com um cubo relacional, tanto no modelo relacional como no modelo Z.

Codd et al. (1993) redigiram um mandato sobre o que devem oferecer as aplicações OLAP aos utilizadores, nomeadamente mantê-los afastados de qualquer pormenor técnico extrâneo ao simples entendimento do negócio nas suas dimensões e métricas.

A vantagem dum cubo OLAP é supostamente a fácil navegação em consultas ad- hoc. No entanto, essa flexibilidade depende de ferramentas próprias para o efectuar, e não do cubo em si. Alguma evolução tem existido nesse sentido, como por exemplo o suporte nativo que é dado em folha de cálculo (Excel) através de Pivot Tables que permitem navegar na hierarquia de um cubo gerado em Analysis Services, e trabalhar com a informação usando a funcionalidade da folha de cálculo.

125

No entanto, o Excel (versão 2010) não permite ainda associar um gráfico de bolhas a uma Pivot Table, pelo que no exemplo que testamos em que o objectivo é disponibilizar um gráfico de bolhas no dashboard, a vantagem de se conseguir sem qualquer esforço uma ferramenta que permite navegar nos dados intuitivamente pelas hierarquias não poderia ser aproveitada. No caso de um dashboard como o que se pretende, com a actual tecnologia e com métricas e parâmetros complexos, deverá ser sempre criada uma aplicação de front-end.

Tendo de ser desenvolvida uma aplicação, a implementação de mecanismos de navegação deverá ser feita, em qualquer caso, recorrendo à respectiva linguagem de manipulação de dados, SQL no relacional, MDX no dimensional, esta com a dificuldade acrescida da sua maior complexidade (Vassiliadis & Sellis, 1999), e sobretudo inflexibilidade estando coerctada pela disciplina dimensional – útil para eliminar a possibilidade de inconsistências mas um obstáculo para dashboards específicos e/ou combinados.

Por outro lado, aproveitando a simplicidade e carácter genérico do modelo Z, é possível definir algoritmos de navegação polivalentes para todos os casos de negócio. Estas rotinas, implementadas em SQL, podem oferecer a funcionalidade que assim deixa de ser necessário programar na aplicação. O mesmo algoritmo poderia ser implementado nativamente em outras ferramentas (como o Excel) permitindo a utilização destes novos cubos relacionais minimalistas como um standard, da mesma forma que ocorre com os cubos OLAP.

Um cubo OLAP requer sempre passos de administração e manutenção adicionais aos que têm de ser efectuados na base de dados relacional. Além disso, os processos de actualização e administração de MDBMS apresentam mais dificuldade que os RDBMS (Vassiliadis & Sellis, 1999).

Como mostra a Figura 46, o modelo dimensional apenas reproduz o que está definido no relacional. Se quiséssemos ter criado um modelo Star teríamos de tê-lo configurado no modelo relacional em tabelas, ou em forma de consultas (views).

126

Figura 46. Modelo dimensional Snowflake

A lógica de cálculo das métricas no OLAP reparte-se pela consulta e por métricas calculadas, em ambos os casos desenvolvidas em linguagem MDX, cuja complexidade superior à do SQL é agravada pela falta de ajuda gráfica. Além disso, devido à lógica dimensional estrita implementada pela linguagem, toda a consulta (incluindo a camada superior) é agora mais rígida, piorando neste aspecto em relação ao modelo relacional: a área de inflexibilidade (barra vermelha da Figura 47) é a maior de todos os modelos aqui estudados.

127

Figura 47. Dos dados ao dashboard - modelo relacional vs dimensional (OLAP)

128

Por todos estes aspectos, não vemos vantagem numa ferramenta típica de OLAP para a utilização aqui equacionada, muito menos quando o objectivo é a flexibilidade.

4.11. ANCHOR MODEL

Rönnbäck e Krumlinde (2012) disponibilizam online um modelador para aplicação do seu modelo Anchor, no qual as entidades e os eventos são modelados como Anchors (quadrados), as associações como Ties (losangos) e os atributos como Attributes (círculos) (Rönnbäck et al., 2010a).

As associações podem ter um elemento tempo associado, opção que escolhemos para obter a mesma funcionalidade de manter histórico versátil como no modelo Z. O resultado da aplicação da estrutura do nosso caso ao modelo é a Figura 48.

Convertendo em tabelas em SQL através da funcionalidade que incorpora o modelador, e adaptando-as simplesmente para o mesmo tipo de dados utilizado em toda a experiência (com os modelos relacional e Z), obtemos a estrutura da Figura 49, onde se nota a estratégia de normalização extrema por subdivisão, passando-se das 19 tabelas do modelo relacional (já normalizado acima da 3NF) para 50.

Carregamos as tabelas com os dados da experiência, adaptamos a consulta - essencialmente a camada inferior (Apêndice 14) - e corremo-la obtendo um tempo médio de 4,032 segundos, cerca de quatro vezes mais lento do que Z_d e próximo de Z+.

129

Figura 48. Anchor model do caso estudado

130

Figura 49. Anchor model implementado no modelo relacional.

4.12. SINTESE DOS RESULTADOS

No sentido de comparar objectivamente as diversas implementações testadas nos factores subjacentes às questões de investigação, estabelecemos um sistema de pontuação de acordo com o seguinte critério.

. Factores relacionados com o objectivo de investigação: - Esforço Tarefa trivial (preenchimento de registos): 1 ponto Controlar e despoletar uma tarefa automatizada: 2 pontos Tarefa de alteração de estrutura ou software: 3 pontos

131

- Skills Nenhum específico: 0 pontos DBA: 1 ponto DBA com domínio de OLAP: 2 pontos - Risco Baixo: 1 ponto Médio: 2 pontos Elevado: 3 pontos - Simplicidade: número de tabelas do modelo

. Factores implicados: - Tempo de resposta duma consulta padrão: segundos com precisão ao milésimo - Tempo eventual de pré-processamento de cubos ou relações: minutos e segundos - Espaço em disco utilizado: Megabytes (MB)14

A Tabela 6 e a Tabela 7 discriminam como foi obtido o cálculo do esforço, aplicando a pontuação a cada tarefa necessária a cada tipo de alteração aos requisitos de negócio. As pontuações obtidas (score) em todos os factores foram normalizadas estatisticamente através do método z-score (Tabela 8).

Para cada modelo, calcularam-se duas médias do z-score: . Média dos factores-objectivo para aferir a capacidade efectiva de contribuir para a resolução do problema de investigação; e . Média de todos os factores para aferir da validade e viabilidade do modelo, tendo em conta todos os impactos da sua implementação.

Com base em cada uma destas médias, estabeleceram-se os dois rankings de modelos da Tabela 9.

14 O espaço em disco considerado foi, em cada caso implementado no modelo relacional, o obtido após compactação da base de dados (DBCC SHRINKDATABASE) e desfragmentação de todos os índices, à excepção de R_c e Z_c onde se convencionou um valor significativo representando o impacto e compromisso variável da opção de materialização em cubo relacional.

132

R: Relacional R_c: Relacional c/ cubo Z: Z básico Z_c: Z c/ cubo Alteração / Exemplo DW Consulta DW Consulta DW Consulta DW Consulta

Alterar consulta Alterar consulta Preencher Alterar consulta Preencher Alterar consulta Criar tabela 3 3 Criar tabela 3 3 1 3 1 3 base base tabela base tabela base Preencher Preencher Preencher Preencher 1 1 1 1 tabela tabela associações associações Dimensão nova: Reprocessar Criar campo 3 Criar campo 3 2 cubo SBU acima da Criar associação 3 Criar associação 3 Linha Preencher Preencher 1 1 associações associações Reprocessar 2 cubo Criar tabela de Alterar consulta Criar tabela de Alterar consulta Alterar consulta Alterar consulta 3 3 3 3 Declarar métrica 1 3 Declarar métrica 1 3 factos base factos base base base Evento (métrica) Criar Alterar consulta Criar Alterar consulta Criar tabela de Alterar consulta Criar tabela de Alterar consulta 3 3 3 3 3 3 3 3 novo: associações final associações final factos final factos final Recriar cubo 3 Recriar cubo 3 Actividade com 4 Reprocessar Reprocessar dimensões: 2 2 cubo cubo Org+Geo+Prod+C anal

Alterar consulta Alterar consulta Alterar consulta Alterar consulta 3 Recriar cubo 3 3 3 Recriar cubo 3 3 final final final final Reprocessar Reprocessar 2 2 Dashboard novo: cubo cubo

Filtro por mais uma dimensão (3)

Alterar consulta Alterar consulta Declarar métrica Alterar consulta Declarar métrica Alterar consulta 3 Recriar cubo 3 3 1 3 1 3 base base nova base nova base Alterar consulta Reprocessar Alterar consulta Alterar consulta Alterar consulta Métrica 3 2 3 3 Recriar cubo 3 3 final cubo final final final calculada nova: Reprocessar 2 cubo Preço médio = Valores / Unidades

Estrutura do Depende de tabelas e selecções 3 Depende de tabelas e selecções 3 Depende de selecções 2 Depende de selecções 2 cálculo

38 55 27 44 Tabela 6. Esforço necessário para implementar alterações em cada modelo.

Relativamente à resposta concreta ao problema de investigação, Z+ é o modelo com melhores resultados, pois cumpre na totalidade o que é pretendido: nenhuma alteração na estrutura de dimensões ou de eventos que caracterizam o negócio, implica alterações estruturais ao modelo de dados. É seguido pelo modelo Z_d em que tal implicação apenas ocorre com as estruturas de eventos.

133

Z_d: Z c/ associações directas Z+: Z c/ assoc.directas + gener.factos D - Dimensional AM - Anchor model Alteração / Exemplo DW Consulta DW Consulta DW Consulta DW Consulta

Preencher Preencher Alterar cálculo Alterar consulta 1 1 Recriar cubo 3 3 Criar 2 tabelas 6 3 tabela tabela métricas base Preencher Preencher Preencher 2 1 1 Criar dimensão 3 Alterar consulta 3 2 associações associações tabelas Dimensão nova: Reprocessar Reprocessar Alterar Criar tabela 2 2 3 3 associações associações hierarquia associação SBU acima da Reprocessar Preencher 2 1 Linha cubo associações

Declarar métrica Alterar consulta Declarar métrica Alterar consulta Alterar cálculo Criar 2 tabelas Alterar consulta 1 3 1 3 Recriar cubo 3 3 6 3 nova base nova final métricas para factos base Evento (métrica) Criar tabela de Alterar consulta Criar tabela Alterar consulta 3 3 Criar métrica 3 Alterar consulta 3 3 3 novo: factos final asociação final Reprocessar 2 Actividade com 4 cubo dimensões: Org+Geo+Prod+C anal

Alterar consulta Alterar consulta Alterar cálculo Alterar consulta 3 3 3 3 final final métricas final Alterar consulta 3 Dashboard novo:

Filtro por mais uma dimensão (3)

Declarar métrica Alterar consulta Declarar métrica Alterar consulta Reprocessar Alterar cálculo Alterar consulta 1 3 1 3 2 3 3 nova base nova final cubo métricas base Alterar consulta Alterar consulta Métrica 3 Alterar consulta 3 3 final final calculada nova:

Preço médio = Valores / Unidades

Estrutura do Depende de selecção de factos 1 Independente 0 Depende de selecções 2 Depende de tabelas e selecções 3 cálculo

25 15 47 42 R+D= 85

Tabela 7. Esforço necesssário para implementar alterações em cada modelo (cont.).

Nas posições inferiores, qualquer modelo apresenta um grau maior ou menor de rigidez que se consubstancia no próprio problema de investigação, pelo que não se consideram alternativas válidas, não sendo excepção a abordagem de nova geração AM, similar na estrutura fragmentada 6NF de tabelas à também recente DV.

134

Tendo em conta adicionalmente os aspectos de performance e de espaço em disco, os dois melhores modelos trocam de posição, o Z+ ficando penalizado por um maior tempo de resposta da consulta e pela maior necessidade de armazenamento, o que leva a considerar o modelo Z_d como o ideal para um negócio do tipo do caso testado, em que alterações a nível de dimensões e hierarquias são frequentes enquanto os eventos são tendencialmente imutáveis. O modelo Z+, por seu lado, representa o óptimo para contextos de alta diversidade e variabilidade de registo de factos, como nomeadamente os que envolvem sistemas integrados.

4.13. DESIGNAÇÃO ESCOLHIDA

Pela característica fundamental de eliminarem esforços de arquitectura, desenvolvimento, implementação e manutenção, sob uma visão versátil que decompõe toda e qualquer realidade – ou universo de discurso (UoD) - numa rede de entidades associadas, os produtos validados desta investigação passam a partilhar a designação Zero Effort Entity-Network, distinguindo-se as duas variantes pelos seguintes acrónimos:

. ZeEN: modelo com estrutura genérica de dimensões, e materialização de associações (aqui implementado na base de dados Z_d); e . ZeEN+: modelo com estruturas genéricas de dimensões e também eventos, e materialização de associações (base de dados Z+).

135

Relacional

Relacional Relacional c/cubo

Z básico Z

Z c/cubo Z

Z c/ associações associações c/ Z directas

Z c/ c/ Z assoc.directas + assoc.directas gener.factos

Dimensional

Relacional + Relacional Dimensional

Anchor model Anchor Score R R_c Z Z_c Z_d Z+ D R + D AM Esforço 38 55 27 44 25 15 47 85 42 Skills 1 1 0 1 0 0 2 2 1 Risco 2 2 1 1 1 1 2 3 2

OBJECTIVO Nº tabelas 17 18 4 5 4 4 17 34 50

Tempo Consulta 2,017 0,189 19,789 0,15 1,195 5,469 0,774 0,774 4,032 Tempo proc. cubo 0 12:16 0 12:16 01:16 01:16 01:51 01:51 00:00 Espaço disco 2872 2872 2934 4029 85 2957 4629

IMPLICAÇÃO Z-score R R_c Z Z_c Z_d Z+ D R + D AM Esforço -0,2 0,6 -0,7 0,1 -0,8 -1,3 0,2 2,1 0,0 Skills 0,2 0,2 -1,1 0,2 -1,1 -1,1 1,4 1,4 0,2 Risco 0,5 0,5 -0,9 -0,9 -0,9 -0,9 0,5 2,0 0,5

OBJECTIVO Nº tabelas 0,4 0,5 -0,9 -0,8 -0,9 -0,9 0,4 2,1 3,7 Média Objectivo 0,23 0,46 -0,91 -0,36 -0,93 -1,06 0,66 1,91 1,10 Tempo Consulta -0,3 -0,6 2,6 -0,6 -0,4 0,3 -0,5 -0,5 0,0 Tempo proc. cubo -0,8 1,7 -0,8 1,7 -0,5 -0,5 -0,4 -0,4 -0,8 Espaço disco -0,6 1,7 -0,6 1,7 -0,6 -0,5 -0,6 -0,6 -0,5

IMPLICAÇÃO Média Total -0,10 0,67 -0,35 0,21 -0,75 -0,72 0,16 0,88 0,45

Tabela 8. Quantificação dos factores implicados nas questões de investigação.

Resposta ao Objectivo Relevância Total

Z c/ assoc.directas + gener.factos Z+ 1 Z_d Z c/ associações directas Z c/ associações directas Z_d 2 Z+ Z c/ assoc.directas + gener.factos Z básico Z 3 Z Z básico Z c/cubo Z_c 4 R Relacional Relacional R 5 D Dimensional Relacional c/cubo R_c 6 Z_c Z c/cubo Dimensional D 7 AM Anchor Model Anchor Modell AM 8 R_c Relacional c/cubo Relacional + Dimensional R+D 9 R+D Relacional + Dimensional Tabela 9. Ranking dos modelos.

136

5. CONCLUSÕES

5.1. CUMPRIMENTO DO OBJECTIVO DE INVESTIGAÇÃO

Foi concebido um novo modelo de dados (ZeEN), que, comparado com os dois modelos tradicionalmente utilizados (relacional e dimensional) e com a recente abordagem ágil Anchor modeling, revelou vantagens claras considerando o objectivo da investigação de minimizar o impacto no modelo de dados e aplicações dele dependentes, de alterações à estrutura da realidade modelada, traduzindo-se em flexibilidade, simplicidade, facilidade, e minimização de custo, tempo e risco de implementação e manutenção, mantendo níveis de performance aceitáveis.

Desta forma, o modelo ZeEN apresenta o valor de contribuir para a redução de custos e melhoria da taxa de sucesso dos projectos de Data warehousing e BI em geral.

5.1.1. Esforço e impacto Zero

Para responder a alterações na estrutura de negócio, o esforço e grau de especialização técnica necessários no modelo ZeEN são mínimos, pois tanto novos elementos como novas entidades e associações podem ser criados apenas por mero preenchimento de registos, sem necessidade de conhecimentos técnicos, operações de administração de bases de dados, nem paragem do sistema de BI.

5.1.2. Simplicidade, imutabilidade e determinismo

A existência no modelo ZeEN de apenas duas tabelas invariáveis de estrutura dimensional, iguais para todos os modelos de negócio, minimiza o risco e esforço associados a complexidade, contribuindo para uma abordagem ágil de desenvolvimento ao eliminar possíveis pontos de discórdia fútil, origem de frustração, desmotivação, e de perdas de tempo e produtividade (Ambler, 2003).

Um outro ponto de decisão arbitrária também é eliminado, ao ser abandonado no modelo ZeEN o conceito tradicional de cubo, que mais não é do que um conjunto de consultas materializadas (Gupta, Harinarayan, & Quass, 1995), deixando de ser necessário optar por quais eleger. No modelo ZeEN efectua-se, para fins de

137

optimização de performance, a materialização de relações indirectas, o que, diferentemente da materialização selectiva de consultas em cubos, é efectuado deterministicamente e na totalidade, sem necessidade de escolhas.

5.1.3. Compromisso aceitável

A abordagem ZeEN consegue as mais-valias referidas ao cumprir o objectivo de investigação, sem inviabilizar o desempenho tanto em consulta como em pré- processamento, e apenas gerando uma ocupação de espaço de armazenamento marginalmente superior.

5.2. DUAS VARIANTES, PARA DIFERENTES NECESSIDADES

A variante ZeEN+ leva o conceito de modelo genérico mais além que a variante ZeEN, garantindo com apenas mais duas tabelas invariáveis também a modelação de quaisquer estruturas de eventos (factos) sem limite na dimensionalidade, conseguindo-o à custa de uma penalização no desempenho, sem esta no entanto ser inviabilizadora. Esta variante é pois indicada nos casos em que o impacto da variabilidade e/ou diversidade de eventos supere em importância a necessidade do melhor desempenho.

5.3. APROVEITAMENTO DE INFRA-ESTRUTURA E KNOW-HOW EXISTENTES

Ambas as variantes ZeEN tiram partido de tecnologia já existente e globalmente disseminada, pois podem ser implementadas, conforme foi testado e mostrado, sobre o modelo relacional.

O determinismo do conceito explorado permite a conversão automática entre o modelo ZeEN e o relacional, em ambos os sentidos, pelo que se podem prefigurar usos adicionais a Data warehousing, como construir um modelo relacional sem esforço para fins de discussão ou de alimentar um sistema OLAP, ou a partir dum modelo relacional existente facilitar a migração para o novo modelo ZeEN. Desta forma também se garante uma minimização de risco em caso de mudança de política, pois o trabalho efectuado sob qualquer das metodologias (tradicional relacional ou nova ZeEN) pode ser sempre transferido para a outra na totalidade e sem esforço nem demora.

138

5.4. POSSÍVEL STANDARD PARA DATA WAREHOUSING

O modelo ZeEN, pelo seu determinismo e versatilidade, permitindo estabelecer qualquer tipo de associação (incluindo n:n e hierarquias não-balanceadas) adequa-se a constituir um standard para Data warehousing, em ambientes não só de negócio como de sistemas integrados, permitindo, sem qualquer adaptação e online, a integração, migração e evolução de dados.

O modelo ZeEN afigura-se ideal para o contexto de Data warehousing de nova geração DW 2.0 (Jovanovic et al., 2012; Knowles, 2012), que preconiza uma staging area de armazenamento persistente onde o histórico fica sempre disponível com todo o detalhe original, à semelhança do que já provaram os modelos Anchor model (Rönnbäck et al., 2010a) e Conceptual Data Vault (Jovanovic & Bojicic, 2012), com os quais o modelo ZeEN partilha a filosofia orientada a colunas, à qual acrescenta ainda maior simplicidade e flexibilidade.

O modelo ZeEN, pelo seu determinismo e simetria, adequa-se a uma exploração dimensional, evitando às organizações a duplicação de dados, estruturas, processos e sistemas que actualmente ocorre com a utilização simultânea do modelo relacional standard e de um modelo OLAP (para o qual não existe standard aceite) para fins de Data warehousing (Thomsen, 2002).

Por não exigir paragem do sistema para configurar alterações de estrutura, o modelo ZeEN adequa-se por excelência ao também emergente conceito de BI e Data warehousing em tempo real (Asghar, Fong, & Hussain, 2009).

5.5. CONTRIBUTOS PARA O CONHECIMENTO

5.5.1. Filosofia ZeEN

O modelo ZeEN como implementação de um conceito sobre o modelo relacional apresenta uma nova abordagem que integra sinergicamente: . as vantagens de um DBMS de 2ªgeração (Codd, 1970); . a simplicidade e versatilidade do modelo network da 1ª geração de DBMS – conceito de grafo (Bachman, 1969);

139

. a intuição de um modelo multidimensional (Codd et al., 1993); e . a mesma mecânica de partição vertical subjacente à comprovada organização colunar Entity-Attribute-Value (Dinu et al., 2006).

5.5.2. Materialização de relações indirectas

O conceito de materialização de relações indirectas criando-as como relações directas artificiais proporciona de forma determinística uma equiparação e optimização de desempenho universal de todas as consultas possíveis, evitando simultaneamente por um lado a degradação de desempenho devida a quantidade de joins encadeados, e por outro a arbitrariedade (de uma aproximação à solução do problema np-complete de MVS), e o tempo e espaço de armazenamento consumidos pelo processamento de um cubo.

5.5.3. Flexibilidade temporal

A implementação de uma coluna associando um elemento temporal a cada instância e associação de entidades, e a cada facto, assegura registos com a máxima granularidade e integridade histórica, enquanto simultaneamente permite o potencial de cruzar perspectivas diferentes (por ex. analisando um histórico de venda ao longo de vários anos, mas mantendo fixa a estrutura organizacional, correspondente a um determinado mês). A estrutura também permite, se considerado necessário por economia, a utilização de um código temporal representando invariabilidade quando o tipo de dimensão o justifique15.

5.5.4. Separação clara dos conceitos e estruturas de dimensões e eventos

O modelo ZeEN nas suas duas variantes fundamenta-se numa distinção conceptual entre a modelação de eventos (algo que é medido no cruzamento de n dimensões), e a modelação de dimensões, apenas associadas binariamente entre si (e a eventos), conceito simples essencial para a clareza e aplicabilidade universal do modelo.

15 Por exemplo, aconselhado na definição da própria dimensão Tempo, para evitar a repetição inútil e exaustiva da sua declaração.

140

6. LIMITAÇÕES E RECOMENDAÇÕES PARA TRABALHOS FUTUROS

6.1. DEMONSTRAÇÃO TEÓRICA FORMAL

O novo modelo ZeEN foi proposto com base experimental, carecendo de uma demonstração algébrica formal como a que suportou a proposta do modelo relacional de Codd (1970), a qual deverá ter lugar em desenvolvimentos futuros de investigação.

6.2. ACOMODAÇÃO DE DIFERENTES TIPOS E DOMÍNIOS DE DADOS

O facto de todas as entidades/atributos serem modelados numa única tabela leva a que tenham de partilhar o mesmo tipo de dados. Na variante ZeEN+, tal acontece também com os valores das métricas que caracterizam os factos. No entanto, a nível de domínios poderá ser utilizada uma técnica de redução, como a mesodata (De Vries & Roddick, 2007), para configurá-los distintamente de acordo com cada entidade e facto.

6.3. MÁQUINA UNIVERSAL DE ANÁLISE (ZEEN#)

A variante ZeEN+ abstrai totalmente as definições de dimensões e de eventos, evitando, sempre que estas apresentem alterações, a alteração da consulta do dashboard. No entanto esta última, apesar de parametrizada, corresponde a uma necessidade delimitada a um determinado tipo de dashboard, como aqui foi considerado. Seria interessante desenvolver um algoritmo de consulta também totalmente genérico (sem limite no número de filtros, métricas e níveis de detalhe) que, em conjunto com o modelo ZeEN+, proporcionasse uma solução universal para qualquer configuração de análise.

6.4. DETECÇÃO AUTOMÁTICA DE FONTES

Em conjugação com o conceito de máquina universal acima mencionado, a concepção de algoritmos de carregamento (ETL) que se adaptem automaticamente a qualquer estrutura-fonte (Peukert et al., 2012), poderá contribuir para a obtenção de um sistema de Data warehousing (e BI) totalmente autonómico (Mateen et al., 2010).

141

6.5. ACOMODAÇÃO DE METADATA E OUTROS DADOS AUXILIARES

Por inclusão de colunas adicionais nas tabelas, à semelhança da coluna temporal aqui implementada, ou através de tabelas colunares satélites, à semelhança de DV (Jovanovic & Bojicic, 2012), deverá ser estudada a acomodação de dados auxiliares, como, por exemplo: . permissões de acesso; . campos auxiliares de cálculo para, nomeadamente, aplicações financeiras (por ex. Conta de Resultados), permitindo indicar o sentido de operações aditivas; e/ou . incorporação no DW de parâmetros (Han, Lakshmanan & Ng, 1999) e/ou resultados de Data Mining (DM) em OLAP - On-line Analytical Mining (OLAM) -, contínuo sobre dados e sobre padrões de uso em todos os níveis hierárquicos (Chen, Gangopadhyay, Karabatis, McGuire, & Welty, 2009).

6.6. CONSIDERAÇÕES TEMPORAIS ADICIONAIS

É comum a necessidade de diversas perspectivas temporais na análise de um mesmo negócio. Poderá apresentar vantagem uma pré-agregação temporal juntamente com a introdução de campo(s) adicional(is) para identificar: . perspectivas (semana, mês, ano, etc.); . desfasamentos (período anterior, ou período homólogo, por ex.); e/ou . agregações temporais (dados semestrais, trimestrais, de períodos corridos ou absolutos, etc.)

6.7. LINGUAGEM DE CÁLCULO

Na presente investigação, deparámo-nos ainda com a complexidade e rigidez na declaração das métricas complexas de marketing utilizadas, quer no modelo relacional em SQL – envolvendo encadeamento de consultas – quer no OLAP em MDX – envolvendo declaração de métricas calculadas, através duma sintaxe intricada e limitada. Esta necessidade de intervenção especializada cada vez que uma nova métrica é solicitada em requisitos, constitui a derradeira limitação a que nem a acima sugerida máquina universal ZeEN# dá resposta.

142

É pois de importância fundamental para Data warehousing o desenvolvimento de suporte à declaração simples, intuitiva, e ilimitada de expressões matemáticas, podendo eventualmente criar-se categorias específicas; por exemplo e para contemplar casos comuns como o que testámos, sugerimos uma Marketing Query Language (MQL) para cálculo de KPI de marketing, com uma convenção para referir mercados, regiões, e outros conceitos próprios como quotas de mercado.

6.8. LINGUAGEM DE NAVEGAÇÃO

Sendo uma das regras do conceito de OLAP (Codd et al., 1993) a exploração intuitiva dos dados pelo utilizador, sem conhecimentos técnicos, e a estrutura determinística do modelo ZeEN prestando-se a tal, deverão ser desenvolvidos algoritmos e uma linguagem de navegação, com comandos simples como UP, DOWN, LEFT, RIGHT, para evoluir através da estrutura de dimensões, facilitando a utilização para análise de dashboards como o que aqui foi apresentado. Tal linguagem terá o potencial de ser incorporada nativamente em ferramentas e em API, permitindo disponibilizar em várias plataformas (por ex., Excel) a exploração multi-dimensional de bases de dados ZeEN, tal como hoje é já possível com cubos OLAP de vários tipos.

6.9. TECNOLOGIA NOVA

As linguagens de cálculo e de navegação em DW ZeEN poderão ser estabelecidas como sublinguagens de uma nova linguagem (ZeQL) de manipulação, definição e análise de dados multidimensionais, reunindo os âmbitos de OLAP e OLAM, e recolhendo os melhores aspectos de sintaxes de exploração já existentes, como SQL, MDX, DMX, DAX, XML, XMLA, e LC (Microsoft, 2012; Spofford, Harinath, Webb, Huang, & Civardi, 2006; Thomsen, 2002).

Tal seria feito em conjunto com uma definição teoricamente fundamentada dum modelo conceptual OLAP, que ainda não existe com aceitação generalizada (Malinowski, 2010), e com o desenho de raíz de um DBMS (ZeDMS) com o objectivo de optimizar performance, escalabilidade e robustez, aproveitando o hardware para aceleração de OLAP e OLAM, à semelhança do que foi desenvolvido pela indústria de processamento gráfico (Vaidya & Lee, 2011).

143

7. APÊNDICES

7.1. SCRIPT DAS TABELAS DO MODELO RELACIONAL (R)

USE [R] GO

CREATE TABLE [dbo].[Classe Terapêutica]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, CONSTRAINT [PK_Classe Terapêutica] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Conjunto Produtos]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, CONSTRAINT [PK_Conjunto Produtos] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[DCI]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, [Classe Terapêutica] [nvarchar](24) NULL, CONSTRAINT [PK_DCI] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[DIM]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, [Supervisor] [nvarchar](24) NULL, CONSTRAINT [PK_DIM] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Empresa]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, [Grupo] [nvarchar](24) NULL, CONSTRAINT [PK_Empresa] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Facts_2D]( [TimeItemID] [nvarchar](24) NOT NULL, [MetricID] [nvarchar](24) NOT NULL, [MetricValue] [float] NOT NULL, [BaseProd] [nvarchar](24) NOT NULL,

144

[BaseGeo] [nvarchar](24) NOT NULL, CONSTRAINT [PK_Facts_2D] PRIMARY KEY CLUSTERED ( [TimeItemID] ASC, [MetricID] ASC, [BaseProd] ASC, [BaseGeo] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Facts_3D]( [TimeItemID] [nvarchar](24) NOT NULL, [MetricID] [nvarchar](24) NOT NULL, [MetricValue] [float] NOT NULL, [BaseOrg] [nvarchar](24) NOT NULL, [BaseProd] [nvarchar](24) NOT NULL, [BaseGeo] [nvarchar](24) NOT NULL, CONSTRAINT [PK_Facts_3D] PRIMARY KEY CLUSTERED ( [TimeItemID] ASC, [MetricID] ASC, [BaseOrg] ASC, [BaseProd] ASC, [BaseGeo] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Grupo]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, CONSTRAINT [PK_Grupo] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Linha]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, [Empresa] [nvarchar](24) NULL, [SBU] [nvarchar](24) NULL, CONSTRAINT [PK_Linha] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Mercado Configurado]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, CONSTRAINT [PK_Mercado Configurado] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Metric]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, CONSTRAINT [PK_Metric] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Produto]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, [Empresa] [nvarchar](24) NULL,

145

[Mercado Configurado] [nvarchar](24) NULL, [DCI] [nvarchar](24) NULL, [Conjunto Produtos] [nvarchar](24) NULL, CONSTRAINT [PK_Produto] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Região]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, CONSTRAINT [PK_Região] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Região/DIM]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, [Região] [nvarchar](24) NULL, [DIM] [nvarchar](24) NULL, CONSTRAINT [PK_Região/DIM] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Supervisor]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, [Linha] [nvarchar](24) NULL, CONSTRAINT [PK_Supervisor] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[TimeItem]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, CONSTRAINT [PK_TimeItem] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Zona]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, CONSTRAINT [PK_Zona] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Zona/DIM]( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, [Zona] [nvarchar](24) NULL, [Região/DIM] [nvarchar](24) NULL, CONSTRAINT [PK_Zona/DIM] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO

146

ALTER TABLE [dbo].[DCI] WITH CHECK ADD CONSTRAINT [FK_DCI_Classe Terapêutica] FOREIGN KEY([Classe Terapêutica]) REFERENCES [dbo].[Classe Terapêutica] ([ID]) GO

ALTER TABLE [dbo].[DCI] CHECK CONSTRAINT [FK_DCI_Classe Terapêutica] GO

ALTER TABLE [dbo].[DIM] WITH CHECK ADD CONSTRAINT [FK_DIM_Supervisor] FOREIGN KEY([Supervisor]) REFERENCES [dbo].[Supervisor] ([ID]) GO

ALTER TABLE [dbo].[DIM] CHECK CONSTRAINT [FK_DIM_Supervisor] GO

ALTER TABLE [dbo].[Empresa] WITH CHECK ADD CONSTRAINT [FK_Empresa_Grupo] FOREIGN KEY([Grupo]) REFERENCES [dbo].[Grupo] ([ID]) GO

ALTER TABLE [dbo].[Empresa] CHECK CONSTRAINT [FK_Empresa_Grupo] GO

ALTER TABLE [dbo].[Facts_2D] WITH CHECK ADD CONSTRAINT [FK_Facts_2D_Metric] FOREIGN KEY([MetricID]) REFERENCES [dbo].[Metric] ([ID]) GO

ALTER TABLE [dbo].[Facts_2D] CHECK CONSTRAINT [FK_Facts_2D_Metric] GO

ALTER TABLE [dbo].[Facts_2D] WITH CHECK ADD CONSTRAINT [FK_Facts_2D_Produto] FOREIGN KEY([BaseProd]) REFERENCES [dbo].[Produto] ([ID]) GO

ALTER TABLE [dbo].[Facts_2D] CHECK CONSTRAINT [FK_Facts_2D_Produto] GO

ALTER TABLE [dbo].[Facts_2D] WITH CHECK ADD CONSTRAINT [FK_Facts_2D_TimeItem] FOREIGN KEY([TimeItemID]) REFERENCES [dbo].[TimeItem] ([ID]) GO

ALTER TABLE [dbo].[Facts_2D] CHECK CONSTRAINT [FK_Facts_2D_TimeItem] GO

ALTER TABLE [dbo].[Facts_2D] WITH CHECK ADD CONSTRAINT [FK_Facts_2D_Zona] FOREIGN KEY([BaseGeo]) REFERENCES [dbo].[Zona] ([ID]) GO

ALTER TABLE [dbo].[Facts_2D] CHECK CONSTRAINT [FK_Facts_2D_Zona] GO

ALTER TABLE [dbo].[Facts_3D] WITH CHECK ADD CONSTRAINT [FK_Facts_3D_DIM] FOREIGN KEY([BaseOrg]) REFERENCES [dbo].[DIM] ([ID]) GO

ALTER TABLE [dbo].[Facts_3D] CHECK CONSTRAINT [FK_Facts_3D_DIM] GO

ALTER TABLE [dbo].[Facts_3D] WITH CHECK ADD CONSTRAINT [FK_Facts_3D_Metric] FOREIGN KEY([MetricID]) REFERENCES [dbo].[Metric] ([ID]) GO

ALTER TABLE [dbo].[Facts_3D] CHECK CONSTRAINT [FK_Facts_3D_Metric] GO

ALTER TABLE [dbo].[Facts_3D] WITH CHECK ADD CONSTRAINT [FK_Facts_3D_Produto] FOREIGN KEY([BaseProd]) REFERENCES [dbo].[Produto] ([ID]) GO

ALTER TABLE [dbo].[Facts_3D] CHECK CONSTRAINT [FK_Facts_3D_Produto] GO

ALTER TABLE [dbo].[Facts_3D] WITH CHECK ADD CONSTRAINT [FK_Facts_3D_TimeItem] FOREIGN KEY([TimeItemID]) REFERENCES [dbo].[TimeItem] ([ID]) GO

ALTER TABLE [dbo].[Facts_3D] CHECK CONSTRAINT [FK_Facts_3D_TimeItem] GO

ALTER TABLE [dbo].[Facts_3D] WITH CHECK ADD CONSTRAINT [FK_Facts_3D_Zona] FOREIGN KEY([BaseGeo]) REFERENCES [dbo].[Zona] ([ID]) GO

147

ALTER TABLE [dbo].[Facts_3D] CHECK CONSTRAINT [FK_Facts_3D_Zona] GO

ALTER TABLE [dbo].[Linha] WITH CHECK ADD CONSTRAINT [FK_Linha_Empresa] FOREIGN KEY([Empresa]) REFERENCES [dbo].[Empresa] ([ID]) GO

ALTER TABLE [dbo].[Linha] CHECK CONSTRAINT [FK_Linha_Empresa] GO

ALTER TABLE [dbo].[Linha] WITH CHECK ADD CONSTRAINT [FK_Linha_SBU] FOREIGN KEY([SBU]) REFERENCES [dbo].[SBU] ([ID]) GO

ALTER TABLE [dbo].[Linha] CHECK CONSTRAINT [FK_Linha_SBU] GO

ALTER TABLE [dbo].[Produto] WITH CHECK ADD CONSTRAINT [FK_Produto_Conjunto Produtos] FOREIGN KEY([Conjunto Produtos]) REFERENCES [dbo].[Conjunto Produtos] ([ID]) GO

ALTER TABLE [dbo].[Produto] CHECK CONSTRAINT [FK_Produto_Conjunto Produtos] GO

ALTER TABLE [dbo].[Produto] WITH CHECK ADD CONSTRAINT [FK_Produto_DCI] FOREIGN KEY([DCI]) REFERENCES [dbo].[DCI] ([ID]) GO

ALTER TABLE [dbo].[Produto] CHECK CONSTRAINT [FK_Produto_DCI] GO

ALTER TABLE [dbo].[Produto] WITH CHECK ADD CONSTRAINT [FK_Produto_Empresa] FOREIGN KEY([Empresa]) REFERENCES [dbo].[Empresa] ([ID]) GO

ALTER TABLE [dbo].[Produto] CHECK CONSTRAINT [FK_Produto_Empresa] GO

ALTER TABLE [dbo].[Produto] WITH CHECK ADD CONSTRAINT [FK_Produto_Mercado Configurado] FOREIGN KEY([Mercado Configurado]) REFERENCES [dbo].[Mercado Configurado] ([ID]) GO

ALTER TABLE [dbo].[Produto] CHECK CONSTRAINT [FK_Produto_Mercado Configurado] GO

ALTER TABLE [dbo].[Região/DIM] WITH CHECK ADD CONSTRAINT [FK_Região/DIM_DIM] FOREIGN KEY([DIM]) REFERENCES [dbo].[DIM] ([ID]) GO

ALTER TABLE [dbo].[Região/DIM] CHECK CONSTRAINT [FK_Região/DIM_DIM] GO

ALTER TABLE [dbo].[Região/DIM] WITH CHECK ADD CONSTRAINT [FK_Região/DIM_Região] FOREIGN KEY([Região]) REFERENCES [dbo].[Região] ([ID]) GO

ALTER TABLE [dbo].[Região/DIM] CHECK CONSTRAINT [FK_Região/DIM_Região] GO

ALTER TABLE [dbo].[Supervisor] WITH CHECK ADD CONSTRAINT [FK_Supervisor_Linha] FOREIGN KEY([Linha]) REFERENCES [dbo].[Linha] ([ID]) GO

ALTER TABLE [dbo].[Supervisor] CHECK CONSTRAINT [FK_Supervisor_Linha] GO

ALTER TABLE [dbo].[Zona/DIM] WITH CHECK ADD CONSTRAINT [FK_Zona/DIM_Região/DIM] FOREIGN KEY([Região/DIM]) REFERENCES [dbo].[Região/DIM] ([ID]) GO

ALTER TABLE [dbo].[Zona/DIM] CHECK CONSTRAINT [FK_Zona/DIM_Região/DIM] GO

ALTER TABLE [dbo].[Zona/DIM] WITH CHECK ADD CONSTRAINT [FK_Zona/DIM_Zona] FOREIGN KEY([Zona]) REFERENCES [dbo].[Zona] ([ID]) GO

ALTER TABLE [dbo].[Zona/DIM] CHECK CONSTRAINT [FK_Zona/DIM_Zona] GO

148

7.2. SCRIPT DA CONSULTA ON-THE-FLY DO MODELO RELACIONAL (R)

 Stored procedure (sp): o RPT_Dat_Conc_OTF  Funções (Table-Valued) auxiliares: o RPT_Dat_Conc_MSn o RPT_Dat_Conc_MSr o RPT_Dat_Conc_MI o RPT_Dat_Conc_Evol

USE [R] GO -- ======-- Description: Dados de Consulta de Dashboard calculados On-The-Fly no Modelo Relacional -- Junta MI e Evol calculados por funções, e nome dos elementos-detalhe -- ======

CREATE procedure [dbo].[RPT_Dat_Conc_OTF] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo) @Dim_1_ItemID nvarchar(24) = 'DIM 042', @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) AS begin

SELECT meat.TimeItemID, meat.Dim_1_ID, meat.Dim_1_ItemID, meat.Dim_2_ID, meat.Dim_2_ItemID, meat.Dim_2sub_ID, meat.Dim_2sub_ItemID, Produto.Name AS Dim_2sub_Item, meat.Pr, meat.MI, meat.Evol

FROM (SELECT COALESCE (MI.TimeItemID, Evol.TimeItemID) AS TimeItemID, COALESCE (MI.Dim_1_ID, Evol.Dim_1_ID) AS Dim_1_ID, COALESCE (MI.Dim_1_ItemID, Evol.Dim_1_ItemID) AS Dim_1_ItemID, COALESCE (MI.Dim_2_ID, Evol.Dim_2_ID) AS Dim_2_ID, COALESCE (MI.Dim_2_ItemID, Evol.Dim_2_ItemID) AS Dim_2_ItemID, COALESCE (MI.Dim_2sub_ID, Evol.Dim_2sub_ID) AS Dim_2sub_ID, COALESCE (MI.Dim_2sub_ItemID, Evol.Dim_2sub_ItemID) AS Dim_2sub_ItemID, COALESCE (MI.Pr, 0) AS Pr, COALESCE (MI.MI, 0) AS MI, COALESCE (Evol.Evol, 0) AS Evol

INNER JOIN Produto ON meat.Dim_2sub_ItemID = Produto.ID end GO

149

-- ======-- Description: Calcula Market Share Nacional On-The-Fly no Modelo Relacional -- ======

CREATE FUNCTION [dbo].[RPT_Dat_Conc_MSn] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN ( SELECT Facts.TimeItemID, @Dim_2_ID AS Dim_2_ID, Produto.[Conjunto Produtos] AS Dim_2_ItemID, @Dim_2sub_ID AS Dim_2sub_ID,Dim_2_Detail.ID AS Dim_2sub_ItemID, SUM(Facts.MetricValue) AS Pn, sum(SUM(Facts.MetricValue) ) over () AS Mn, SUM(Facts.MetricValue) / sum(SUM(Facts.MetricValue) ) over () * 100 AS MSn

FROM Produto INNER JOIN DCI AS Dim_2_Mkt ON Produto.DCI = Dim_2_Mkt.ID INNER JOIN Facts_2D AS Facts INNER JOIN Produto AS Dim_2_Detail ON Facts.BaseProd = Dim_2_Detail.ID ON Dim_2_Mkt.ID = Dim_2_Detail.DCI

WHERE ( Facts.MetricID = @MetricID)

GROUP BY Facts.TimeItemID, Produto.[Conjunto Produtos], Dim_2_Detail.ID

HAVING (Facts.TimeItemID = @TimeItemID) AND ( Produto.[Conjunto Produtos] = @Dim_2_ItemID) ) GO

-- ======-- Description: Calcula Market Share Regional On-The-Fly no Modelo Relacional -- ======

CREATE FUNCTION [dbo].[RPT_Dat_Conc_MSr] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo) @Dim_1_ItemID nvarchar(24) = 'DIM 042', @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN ( SELECT Facts.TimeItemID, @Dim_1_ID AS Dim_1_ID, [Região/DIM].DIM AS Dim_1_ItemID, @Dim_2_ID AS Dim_2_ID, Produto.[Conjunto Produtos] AS Dim_2_ItemID, @Dim_2sub_ID S Dim_2sub_ID, Dim_2_Detail.ID AS Dim_2sub_ItemID, SUM(Facts.MetricValue) AS Pr, sum( SUM(Facts.MetricValue) ) over () AS Mr, SUM(Facts.MetricValue) / sum( SUM(Facts.MetricValue) ) over () * 100 AS MSr

FROM Zona INNER JOIN Facts_2D AS Facts ON Zona.ID = Facts.BaseGeo INNER JOIN [Região/DIM] INNER JOIN [Zona/DIM] ON [Região/DIM].ID = [Zona/DIM].[Região/DIM] ON Zona.ID = [Zona/DIM].Zona INNER JOIN Produto AS Dim_2_Detail ON Facts.BaseProd = Dim_2_Detail.ID INNER JOIN DCI AS Dim_2_Mkt ON Dim_2_Detail.DCI = Dim_2_Mkt.ID INNER JOIN Produto ON Dim_2_Mkt.ID = Produto.DCI

150

WHERE ( Facts.MetricID = @MetricID)

GROUP BY Facts.TimeItemID, [Região/DIM].DIM, Produto.[Conjunto Produtos], Dim_2_Detail.ID

HAVING (Facts.TimeItemID = @TimeItemID) AND ( [Região/DIM].DIM = @Dim_1_ItemID) AND ( Produto.[Conjunto Produtos] = @Dim_2_ItemID) ) GO

-- ======

-- Description: Calcula MI On-The-Fly no Modelo Relacional -- pelo rácio entre MSR e MSN calculados por funções -- ======

CREATE FUNCTION [dbo].[RPT_Dat_Conc_MI] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo) @Dim_1_ItemID nvarchar(24) = 'DIM 042', @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN ( SELECT MSr.TimeItemID, MSr.Dim_1_ID, MSr.Dim_1_ItemID, MSr.Dim_2_ID, MSr.Dim_2_ItemID, MSr.Dim_2sub_ID, MSr.Dim_2sub_ItemID, MSr.Pr, MSr.MSr, MSr.MSr / MSn.MSn * 100 AS MI

FROM dbo.RPT_Dat_Conc_MSr ( @TimeItemID, @Dim_1_base, @Dim_1_ID, @Dim_1_ItemID, @Dim_2_base, @Dim_2_ID, @Dim_2_ItemID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MSr

INNER JOIN dbo.RPT_Dat_Conc_MSn ( @TimeItemID , @Dim_2_base, @Dim_2_ID, @Dim_2_ItemID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MSn

ON MSr.TimeItemID = MSn.TimeItemID AND MSr.Dim_2_ID = MSn.Dim_2_ID AND MSr.Dim_2_ItemID = MSn.Dim_2_ItemID AND MSr.Dim_2sub_ID = MSn.Dim_2sub_ID AND MSr.Dim_2sub_ItemID = MSn.Dim_2sub_ItemID ) GO

151

-- ======-- Description: Calcula Evol On-The-Fly no Modelo Relacional -- pelo rácio da MSR entre dois períodos, calculada por função -- ======

CREATE FUNCTION [dbo].[RPT_Dat_Conc_Evol] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo) @Dim_1_ItemID nvarchar(24) = 'DIM 042', @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN ( SELECT MSr0.TimeItemID, MSr0.Dim_1_ID, MSr0.Dim_1_ItemID, MSr0.Dim_2_ID, MSr0.Dim_2_ItemID, MSr0.Dim_2sub_ID, MSr0.Dim_2sub_ItemID, MSr0.MSr / MSr1.MSr * 100 AS Evol

FROM dbo.RPT_Dat_Conc_MSr ( @TimeItemID, @Dim_1_base, @Dim_1_ID, @Dim_1_ItemID, @Dim_2_base, @Dim_2_ID, @Dim_2_ItemID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MSr0

INNER JOIN dbo.RPT_Dat_Conc_MSr ( @TimeItemID- 100, @Dim_1_base, @Dim_1_ID, @Dim_1_ItemID, @Dim_2_base, @Dim_2_ID, @Dim_2_ItemID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MSr1

ON MSr0.TimeItemID -100 = MSr1.TimeItemID AND MSr0.Dim_1_ID = MSr1.Dim_1_ID AND MSr0.Dim_1_ItemID = MSr1.Dim_1_ItemID AND MSr0.Dim_2_ID = MSr1.Dim_2_ID AND MSr0.Dim_2_ItemID = MSr1.Dim_2_ItemID AND MSr0.Dim_2sub_ID = MSr1.Dim_2sub_ID AND MSr0.Dim_2sub_ItemID = MSr1.Dim_2sub_ItemID ) GO

152

7.3. OUTPUT DA CONSULTA PARA O DASHBOARD (R)

TimeItemID Dim_1_ID Dim_1_ItemID Dim_2_ID Dim_2_ItemID Dim_2sub_ID Dim_2sub_ItemID Dim_2sub_Item Pr MI Evol 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1157 Produto 1157 130,41 203 0 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1159 Produto 1159 7685,6 158,7 189,1 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1160 Produto 1160 4309,96 182,8 180 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1161 Produto 1161 894,07 128,9 73,72 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1162 Produto 1162 1068,32 203 2415 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1163 Produto 1163 1086,72 73,14 427,4 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1346 Produto 1346 5127,16 104,8 0 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1465 Produto 1465 37706,1 108,7 108,2 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1470 Produto 1470 88822,2 99,93 124 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1471 Produto 1471 4338,61 121,1 253,4 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1472 Produto 1472 1497,29 69,63 61,98 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1473 Produto 1473 539,79 42,75 372,7 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1474 Produto 1474 3,68 203 0 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1475 Produto 1475 1041,44 76,41 117,8 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1476 Produto 1476 1630,95 76,15 78,42 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1477 Produto 1477 11592 116,2 84,13 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1478 Produto 1478 1017,74 87,64 85,31 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1479 Produto 1479 4087,18 110,7 90,42 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1480 Produto 1480 6645,05 110,5 139,8 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1481 Produto 1481 13981 89,88 144 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1482 Produto 1482 1768,83 80,82 77,3 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1483 Produto 1483 3163,8 105,3 114,3 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1485 Produto 1485 15873,5 75,77 119,3 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1488 Produto 1488 65,95 117,7 3,426 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1489 Produto 1489 6929,98 105,1 253,5 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1490 Produto 1490 6051,75 74,72 149 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1491 Produto 1491 10,48 144,9 1,736 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1492 Produto 1492 8535,83 70,97 127,3 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1493 Produto 1493 10394,1 96,01 180,6 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1494 Produto 1494 3621,7 83,99 250,8 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1497 Produto 1497 70479,6 94,74 96,47 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1498 Produto 1498 643,23 86,16 49,34 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1500 Produto 1500 259,14 196,5 402,9 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1504 Produto 1504 402,35 128,8 125,8 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1505 Produto 1505 1890,52 121,1 127,8 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1603 Produto 1603 45040,4 107,5 92,75 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1604 Produto 1604 67713,9 110,5 84,41 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1606 Produto 1606 10080,9 110,9 148,6 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1608 Produto 1608 9332,42 53,86 71,54 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1609 Produto 1609 10175,2 129,2 142,9 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1610 Produto 1610 28581,3 58,75 76,21 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1611 Produto 1611 1652,13 27,83 197,2 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1613 Produto 1613 6250,89 113,4 190,8 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1614 Produto 1614 31432,5 120,3 48,72 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1615 Produto 1615 16186,1 83,4 123,5 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1616 Produto 1616 3147,65 114,6 23,03 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1617 Produto 1617 8986,32 71,3 100,6 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1618 Produto 1618 10237,6 109,2 64,18 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1619 Produto 1619 43603 105,1 67,93 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1620 Produto 1620 2662,99 63,28 115,5 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1621 Produto 1621 2259,87 76,79 67,15

153

TimeItemID Dim_1_ID Dim_1_ItemID Dim_2_ID Dim_2_ItemID Dim_2sub_ID Dim_2sub_ItemID Dim_2sub_Item Pr MI Evol 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1622 Produto 1622 15805,9 96,54 158,4 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1623 Produto 1623 10013,9 82,6 136,5 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1624 Produto 1624 42813,7 103,7 83,39 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1626 Produto 1626 37725,3 113,8 70,62 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1627 Produto 1627 4724,59 77,15 136,8 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1628 Produto 1628 3038,38 109,6 27,89 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1630 Produto 1630 53156,2 101,1 103,9 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1631 Produto 1631 92160,2 106,5 100,3 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1632 Produto 1632 34832,1 106,5 86,65 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1633 Produto 1633 38358,7 91,64 262,8 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1634 Produto 1634 4670,38 146,2 57,15 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1635 Produto 1635 13252,6 82,7 281,1 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1636 Produto 1636 11730,1 100,9 54,49 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1638 Produto 1638 13409,9 84,73 78,8 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1640 Produto 1640 2098,05 121,9 287,2 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1641 Produto 1641 44057,1 99,1 77,11 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1642 Produto 1642 14568,3 118,7 60,42 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 184 Produto 184 16805,3 98,45 88,01 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 185 Produto 185 18036,3 101,3 87,73 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1853 Produto 1853 181,74 166,6 0 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2073 Produto 2073 8092,78 108,3 170,8 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2074 Produto 2074 5708,38 142,4 160,6 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 227 Produto 227 40782,2 92,46 106,8 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2318 Produto 2318 1818,33 132,2 0 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2332 Produto 2332 7436,36 108,5 94,51 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2333 Produto 2333 10526,3 108,4 98,67 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2358 Produto 2358 26,88 64 0 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2370 Produto 2370 4517,94 171,8 0 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2496 Produto 2496 50790,1 85,69 0 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2522 Produto 2522 1694,07 83,04 2,445 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2531 Produto 2531 2870,27 187,4 0 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2541 Produto 2541 29,76 203 0 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2554 Produto 2554 128,48 173,7 0 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 683 Produto 683 8353,06 94,01 111,4 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 774 Produto 774 6239,16 148,6 153,6 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 923 Produto 923 446,12 115,1 2008 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 924 Produto 924 6257,81 140,3 176,6 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 925 Produto 925 8923,18 105,9 147,6 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 926 Produto 926 1756,47 125,4 0 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 928 Produto 928 12210,5 103,7 133,8 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 929 Produto 929 4894,47 122,3 369,3 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 930 Produto 930 14807,1 119,2 218,5 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 931 Produto 931 50893,4 120,5 166,7 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 932 Produto 932 14433,7 126,5 106,4 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 933 Produto 933 5939,74 111,7 117,7 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 935 Produto 935 22692 124,8 125,4 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 936 Produto 936 17297 125,8 143,4 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 937 Produto 937 8404,44 111,3 151,3 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 938 Produto 938 21647,7 110,5 184 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 939 Produto 939 5932,98 116 1082 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 940 Produto 940 17564,4 72,52 130 201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 941 Produto 941 13,09 203 35,02

154

7.4. SCRIPT DA ROTINA DE CRIAÇÃO DO CUBO (R)

USE [R] GO -- ======-- Description: Criação do cubo com os dados de Consulta de Dashboard no Modelo Relacional -- Junta MI e Evol calculados por funções, e nome dos elementos-detalhe -- ======

CREATE procedure [dbo].[ETL_Dat_Conc_MT] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo)

@Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod)

@Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) AS begin if exists (select * from R.sys.objects where type ='U' and name ='Cube_Conc') drop table R.dbo.Cube_Conc

SELECT meat.TimeItemID, meat.Dim_1_ID, meat.Dim_1_ItemID, meat.Dim_2_ID, meat.Dim_2_ItemID, meat.Dim_2sub_ID, meat.Dim_2sub_ItemID, Produto.Name AS Dim_2sub_Item, meat.Pr, meat.MI, meat.Evol

INTO Cube_Conc

FROM (SELECT @TimeItemID AS TimeItemID, @Dim_1_ID AS Dim_1_ID, COALESCE (MI.Dim_1_ItemID, Evol.Dim_1_ItemID) AS Dim_1_ItemID, @Dim_2_ID AS Dim_2_ID, COALESCE (MI.Dim_2_ItemID, Evol.Dim_2_ItemID) AS Dim_2_ItemID, @Dim_2sub_ID AS Dim_2sub_ID, COALESCE (MI.Dim_2sub_ItemID, Evol.Dim_2sub_ItemID) AS Dim_2sub_ItemID, COALESCE (MI.Pr, 0) AS Pr, COALESCE (MI.MI, 0) AS MI, COALESCE (Evol.Evol, 0) AS Evol

FROM dbo.ETL_Dat_Conc_MI ( @TimeItemID, @Dim_1_base, @Dim_1_ID, @Dim_2_base, @Dim_2_ID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MI FULL OUTER JOIN dbo.ETL_Dat_Conc_Evol ( @TimeItemID, @Dim_1_base, @Dim_1_ID, @Dim_2_base, @Dim_2_ID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS Evol

ON MI.TimeItemID = Evol.TimeItemID AND MI.Dim_1_ID = Evol.Dim_1_ID AND MI.Dim_1_ItemID = Evol.Dim_1_ItemID AND MI.Dim_2_ID = Evol.Dim_2_ID AND MI.Dim_2_ItemID = Evol.Dim_2_ItemID AND MI.Dim_2sub_ID = Evol.Dim_2sub_ID AND MI.Dim_2sub_ItemID = Evol.Dim_2sub_ItemID) AS meat INNER JOIN Produto ON meat.Dim_2sub_ItemID = Produto.ID exec (' ALTER TABLE R.[dbo].[Cube_Conc] ALTER COLUMN TimeItemID nvarchar(24) NOT NULL ALTER TABLE R.[dbo].[Cube_Conc] ALTER COLUMN Dim_1_ID nvarchar(24) NOT NULL ALTER TABLE R.[dbo].[Cube_Conc] ALTER COLUMN Dim_1_ItemID nvarchar(24) NOT NULL ALTER TABLE R.[dbo].[Cube_Conc] ALTER COLUMN Dim_2_ID nvarchar(24) NOT NULL ALTER TABLE R.[dbo].[Cube_Conc] ALTER COLUMN Dim_2_ItemID nvarchar(24) NOT NULL ALTER TABLE R.[dbo].[Cube_Conc] ALTER COLUMN Dim_2sub_ID nvarchar(24) NOT NULL ALTER TABLE R.[dbo].[Cube_Conc] ALTER COLUMN Dim_2sub_ItemID nvarchar(24) NOT NULL ')

155

exec(' ALTER TABLE [dbo].[Cube_Conc] ADD CONSTRAINT [PK_Cube_Conc] PRIMARY KEY CLUSTERED ( [TimeItemID] ASC, Dim_1_ID ASC, Dim_1_ItemID ASC, Dim_2_ID ASC, Dim_2_ItemID ASC, Dim_2sub_ID ASC, Dim_2sub_ItemID ASC ) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ' ) end go

-- ======-- Description: Calcula Market Share Nacional no Modelo Relacional para alimentar cubo -- ======

CREATE FUNCTION [dbo].[ETL_Dat_Conc_MSn] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod)

@Dim_2sub_ID varchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN

( SELECT Facts.TimeItemID, @Dim_2_ID AS Dim_2_ID, Produto.[Conjunto Produtos] AS Dim_2_ItemID, @Dim_2sub_ID AS Dim_2sub_ID, Dim_2_Detail.ID AS Dim_2sub_ItemID, SUM(Facts.MetricValue) AS Pn, sum( SUM(Facts.MetricValue) ) over (partition by Produto.[Conjunto Produtos]) AS Mn, SUM(Facts.MetricValue) / sum( SUM(Facts.MetricValue) ) over (partition by Produto.[Conjunto Produtos])*100 AS MSn

WHERE (Facts.MetricID = @MetricID)

GROUP BY Facts.TimeItemID, Produto.[Conjunto Produtos], Dim_2_Detail.ID

HAVING (Facts.TimeItemID = @TimeItemID) ) GO

-- ======-- Description: Calcula Market Share Regional no Modelo Relacional para alimentar cubo -- ======

CREATE FUNCTION [dbo].[ETL_Dat_Conc_MSr] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo)

@Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod)

@Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS

156

RETURN

( SELECT Facts.TimeItemID, @Dim_1_ID AS Dim_1_ID, [Região/DIM].DIM AS Dim_1_ItemID, @Dim_2_ID AS Dim_2_ID, Produto.[Conjunto Produtos] AS Dim_2_ItemID, @Dim_2sub_ID AS Dim_2sub_ID, Dim_2_Detail.ID AS Dim_2sub_ItemID, SUM(Facts.MetricValue) AS Pr, sum(SUM(Facts.MetricValue)) over (partition by [Região/DIM].DIM,Produto.[Conjunto Produtos]) AS Mr, SUM(Facts.MetricValue) / sum(SUM(Facts.MetricValue)) over (partition by [Região/DIM].DIM,Produto.[Conjunto Produtos])*100 AS MSr

WHERE (Facts.MetricID = @MetricID)

GROUP BY Facts.TimeItemID, [Região/DIM].DIM, Produto.[Conjunto Produtos], Dim_2_Detail.ID

HAVING (Facts.TimeItemID = @TimeItemID) ) GO

-- ======-- Description: Calcula MI no Modelo Relacional para alimentar cubo -- pelo rácio entre MSR e MSN calculados por funções -- ======

CREATE FUNCTION [dbo].[ETL_Dat_Conc_MI] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo)

@Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod)

@Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN

( SELECT MSr.TimeItemID, MSr.Dim_1_ID, MSr.Dim_1_ItemID, MSr.Dim_2_ID, MSr.Dim_2_ItemID, MSr.Dim_2sub_ID, MSr.Dim_2sub_ItemID, MSr.Pr, MSr.MSr, MSr.MSr / MSn.MSn * 100 AS MI

FROM dbo.ETL_Dat_Conc_MSr (@TimeItemID, @Dim_1_base, @Dim_1_ID, @Dim_2_base, @Dim_2_ID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MSr

INNER JOIN dbo.ETL_Dat_Conc_MSn (@TimeItemID, @Dim_2_base, @Dim_2_ID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MSn

ON MSr.TimeItemID = MSn.TimeItemID AND MSr.Dim_2_ID = MSn.Dim_2_ID AND MSr.Dim_2_ItemID = MSn.Dim_2_ItemID AND MSr.Dim_2sub_ID = MSn.Dim_2sub_ID AND MSr.Dim_2sub_ItemID = MSn.Dim_2sub_ItemID ) GO

157

-- ======-- Description: Calcula Evol no Modelo Relacional para alimentar cubo -- pelo rácio da MSR entre dois períodos, calculada por função -- ======

CREATE FUNCTION [dbo].[ETL_Dat_Conc_Evol] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo)

@Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod)

@Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN

( SELECT MSr0.TimeItemID, MSr0.Dim_1_ID, MSr0.Dim_1_ItemID, MSr0.Dim_2_ID, MSr0.Dim_2_ItemID, MSr0.Dim_2sub_ID, MSr0.Dim_2sub_ItemID, MSr0.MSr/MSr1.MSr * 100 AS Evol

FROM dbo.ETL_Dat_Conc_MSr (@TimeItemID, @Dim_1_base, @Dim_1_ID, @Dim_2_base, @Dim_2_ID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MSr0

INNER JOIN dbo.ETL_Dat_Conc_MSr (@TimeItemID- 100, @Dim_1_base, @Dim_1_ID, @Dim_2_base, @Dim_2_ID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MSr1

7.5. SCRIPT DA CONSULTA ON-THE-FLY DOS MODELOS RELACIONAL (R) E Z SOBRE CUBO

USE [R] GO -- ======-- Description: Dados de Consulta de Dashboard pré-calculados -- recolhidos directamente do cubo no Modelo Relacional -- ======

CREATE procedure [dbo].[RPT_Dat_Conc_Cub] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo) @Dim_1_ItemID nvarchar(24) = 'DIM 042', @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência )

AS begin

158

SELECT TimeItemID, Dim_1_ID, Dim_1_ItemID, Dim_2_ID, Dim_2_ItemID, Dim_2sub_ID, Dim_2sub_ItemID, Dim_2sub_Item,

Pr, MI, Evol

FROM Cube_Conc

WHERE (TimeItemID = @TimeItemID) AND (Dim_1_ID = @Dim_1_ID) AND (Dim_1_ItemID = @Dim_1_ItemID) AND (Dim_2_ID = @Dim_2_ID) AND (Dim_2_ItemID = @Dim_2_ItemID) AND (Dim_2sub_ID = @Dim_2sub_ID) end GO

7.6. SCRIPT DA ROTINA DE CRIAÇÃO DUM MODELO Z A PARTIR DUM MODELO RELACIONAL

USE [UTI] GO -- ======-- Description: criação dum modelo Z a partir dum modelo relacional -- -- ======

CREATE PROCEDURE [dbo].[UTI_Build_Z] @ModeloRelacional nvarchar(50) = 'M1', @TimeItemID nvarchar(24) = '201203' AS declare @TimeStamp nvarchar(50) = GETDATE() declare @NAME_DB nvarchar(50) = 'Z_'+ @ModeloRelacional +'_'+ @TimeItemID +'_'+ @TimeStamp BEGIN

--CRIAR BASE DE DADOS: exec( 'IF EXISTS (SELECT name FROM sys.databases WHERE name = '''+ @NAME_DB + ''') DROP DATABASE ['+ @NAME_DB +']') exec ( 'CREATE DATABASE [' + @NAME_DB + '] ON PRIMARY ' + '( NAME = ''' + @NAME_DB + ''', FILENAME = N''D:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\' + @NAME_DB + '.mdf'' , SIZE = 10000KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ) ' + ' LOG ON ' + '( NAME = ''' + @NAME_DB + '_log'', FILENAME = N''D:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\' + @NAME_DB + '_log.ldf'' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%) ') exec ('ALTER DATABASE [' + @NAME_DB + '] SET COMPATIBILITY_LEVEL = 100') exec ('IF (1 = FULLTEXTSERVICEPROPERTY(''IsFullTextInstalled'')) ' + 'begin EXEC [' + @NAME_DB + '].[dbo].[sp_fulltext_database] @action = ''enable'' end') exec ('ALTER DATABASE [' + @NAME_DB + '] SET ANSI_NULL_DEFAULT OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET ANSI_NULLS OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET ANSI_PADDING OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET ANSI_WARNINGS OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET ARITHABORT OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET AUTO_CLOSE OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET AUTO_CREATE_STATISTICS ON') exec ('ALTER DATABASE [' + @NAME_DB + '] SET AUTO_SHRINK OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET AUTO_UPDATE_STATISTICS ON') exec ('ALTER DATABASE [' + @NAME_DB + '] SET CURSOR_CLOSE_ON_COMMIT OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET CURSOR_DEFAULT GLOBAL') exec ('ALTER DATABASE [' + @NAME_DB + '] SET CONCAT_NULL_YIELDS_NULL OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET NUMERIC_ROUNDABORT OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET QUOTED_IDENTIFIER OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET RECURSIVE_TRIGGERS OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET DISABLE_BROKER') exec ('ALTER DATABASE [' + @NAME_DB + '] SET AUTO_UPDATE_STATISTICS_ASYNC OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET DATE_CORRELATION_OPTIMIZATION OFF')

159

exec ('ALTER DATABASE [' + @NAME_DB + '] SET TRUSTWORTHY OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET ALLOW_SNAPSHOT_ISOLATION OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET PARAMETERIZATION SIMPLE') exec ('ALTER DATABASE [' + @NAME_DB + '] SET READ_COMMITTED_SNAPSHOT OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET HONOR_BROKER_PRIORITY OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET READ_WRITE') exec ('ALTER DATABASE [' + @NAME_DB + '] SET RECOVERY SIMPLE') exec ('ALTER DATABASE [' + @NAME_DB + '] SET MULTI_USER') exec ('ALTER DATABASE [' + @NAME_DB + '] SET PAGE_VERIFY CHECKSUM') exec ('ALTER DATABASE [' + @NAME_DB + '] SET DB_CHAINING OFF')

--CRIAR TABELAS: exec ( 'if exists (select * from [' + @NAME_DB + '].sys.objects where type =''U'' and name =''Groups'') drop table [' + @NAME_DB + '].dbo.Groups' ) exec ( 'if exists (select * from [' + @NAME_DB + '].sys.objects where type =''U'' and name =''Tables'') drop table [' + @NAME_DB + '].dbo.Tables' ) exec (' CREATE TABLE [' + @NAME_DB + '].[dbo].[Tables]( [TimeItemID] [nvarchar](24) NOT NULL, [TableID] [nvarchar](24) NOT NULL, [TableItemID] [nvarchar](24) NOT NULL, [TableItemName] [nvarchar](500) NULL, CONSTRAINT [PK_Tables] PRIMARY KEY CLUSTERED ( [TimeItemID] ASC, [TableID] ASC, [TableItemID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] ') exec (' CREATE TABLE [' + @NAME_DB + '].[dbo].[Groups]( [TimeItemID] [nvarchar](24) NOT NULL, [ChildTableID] [nvarchar](24) NOT NULL, [ChildTableItemID] [nvarchar](24) NOT NULL, [ParentTableID] [nvarchar](24) NOT NULL, [ParentTableItemID] [nvarchar](24) NOT NULL, CONSTRAINT [PK_Groups] PRIMARY KEY CLUSTERED ( [TimeItemID] ASC, [ChildTableID] ASC, [ChildTableItemID] ASC, [ParentTableID] ASC, [ParentTableItemID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]

ALTER TABLE [' + @NAME_DB + '].[dbo].[Groups] WITH CHECK ADD CONSTRAINT [FK_Groups_Tables] FOREIGN KEY( [TimeItemID], [ChildTableID], [ChildTableItemID]) REFERENCES [dbo].[Tables] ( [TimeItemID], [TableID], [TableItemID])

ALTER TABLE [' + @NAME_DB + '].[dbo].[Groups] CHECK CONSTRAINT [FK_Groups_Tables]

ALTER TABLE [' + @NAME_DB + '].[dbo].[Groups] WITH CHECK ADD CONSTRAINT [FK_Groups_Tables1] FOREIGN KEY( [TimeItemID], [ParentTableID], [ParentTableItemID]) REFERENCES [dbo].[Tables] ([TimeItemID], [TableID], [TableItemID])

ALTER TABLE [' + @NAME_DB + '].[dbo].[Groups] CHECK CONSTRAINT [FK_Groups_Tables1] ') exec(' DECLARE @TableID nvarchar(24) DECLARE @TableName nvarchar(500) DECLARE @TableItemID nvarchar(24) DECLARE @TableItemName nvarchar(500)

DECLARE @ChildTableID nvarchar(24) DECLARE @ParentTableID nvarchar(24) DECLARE @ChildTableName nvarchar(500) DECLARE @ParentTableName nvarchar(500)

DECLARE tables_cursor CURSOR FOR

160

select NAME, name from [' + @ModeloRelacional + '].sys.objects where type =''U'' and name not like ''sys%'' and name not like ''Cube_%'' and name not like ''Facts_%'' --ROW_NUMBER() OVER (ORDER BY name) OPEN tables_cursor

FETCH NEXT FROM tables_cursor INTO @TableID, @TableName print @TableID+ @TableName ; WHILE @@FETCH_STATUS = 0

BEGIN exec('' INSERT INTO [' + @NAME_DB + '].[dbo].[Tables] ([TimeItemID] ,[TableID] ,[TableItemID] ,[TableItemName]) SELECT '''''+@TimeItemID+''''' TimeItemID, ''''0'''' TableID, ''''''+@TableID+'''''' TableItemID, ''''''+@TableName+'''''' TableItemName UNION ALL SELECT '''''+@TimeItemID+''''' TimeItemID, ''''''+@TableID+'''''' TableID, ID TableItemID, Name TableItemName FROM [' + @ModeloRelacional + '].dbo.[''+@TableName+''] '')

FETCH NEXT FROM tables_cursor INTO @TableID, @TableName print @TableID+ @TableName;

END

CLOSE tables_cursor DEALLOCATE tables_cursor ')

----CRIAR RELAÇÕES: exec(' DECLARE @ChildTableID nvarchar(24) DECLARE @ChildTableName nvarchar(500) DECLARE @ChildTableItemID nvarchar(24)

DECLARE @ParentTableID nvarchar(24) DECLARE @ParentTableName nvarchar(500) DECLARE @ParentTableItemID nvarchar(24)

DECLARE groups_cursor CURSOR FOR SELECT Tables.TableItemID ChildTableID, obj.name ChildTableName, Tables_1.TableItemID AS ParentTableID, col.name AS ParentTableName FROM [' + @ModeloRelacional + '].sys.syscolumns AS col INNER JOIN [' + @ModeloRelacional + '].sys.sysobjects AS obj ON col.id = obj.id INNER JOIN [' + @NAME_DB + '].dbo.Tables AS Tables ON obj.name = Tables.TableItemName INNER JOIN [' + @NAME_DB + '].dbo.Tables AS Tables_1 ON col.name = Tables_1.TableItemName WHERE (obj.type = ''U'') AND (Tables.TimeItemID = N'''+@TimeItemID+''') AND (Tables.TableID = N''0'') AND (Tables_1.TimeItemID = N'''+@TimeItemID+''') AND (Tables_1.TableID = N''0'') AND (NOT (col.name IN (N''ID. Name'')))

OPEN groups_cursor

FETCH NEXT FROM groups_cursor INTO @ChildTableID, @ChildTableName, @ParentTableID, @ParentTableName

print @ChildTableID + '' '' + @ChildTableName+ '' '' + @ParentTableID+ '' '' + @ParentTableName

WHILE @@FETCH_STATUS = 0

BEGIN exec('' insert into [' + @NAME_DB + '].dbo.Groups SELECT '''''+@TimeItemID+''''' TimeItemID,

161

''''''+@ChildTableID+'''''' ChildTableID, ID ChildTableItemID, ''''''+@ParentTableID+'''''' ParentTableID, [''+@ParentTableName+''] ParentTableItemID

FROM [' + @ModeloRelacional + '].[dbo].[''+@ChildTableName+'']

WHERE [''+@ParentTableName+''] IS NOT NULL '')

FETCH NEXT FROM groups_cursor INTO @ChildTableID, @ChildTableName, @ParentTableID, @ParentTableName END

CLOSE groups_cursor DEALLOCATE groups_cursor

') END GO

7.7. SCRIPT DA ROTINA DE CRIAÇÃO DUM MODELO RELACIONAL A PARTIR DUM MODELO Z

USE [UTI] GO -- ======-- Description: criação dum modelo relacional a partir dum modelo ZeEN -- -- ======

CREATE PROCEDURE [dbo].[UTI_Build_R] @ModeloZ nvarchar(24) = 'M5', @TimeItemID nvarchar(24) = '201203'

AS declare @TimeStamp nvarchar(50)= GETDATE() declare @NAME_DB nvarchar(50) = 'R_'+ @ModeloZ +'_'+ @TimeItemID +'_'+ @TimeStamp

BEGIN

-- CRIAR BASE DE DADOS exec( 'IF EXISTS (SELECT name FROM sys.databases WHERE name = '''+ @NAME_DB + ''') DROP DATABASE ['+ @NAME_DB+']' ) exec ( 'CREATE DATABASE [' + @NAME_DB + '] ON PRIMARY ' + '( NAME = ''' + @NAME_DB + ''', FILENAME = N''D:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\' + @NAME_DB + '.mdf'' , SIZE = 10000KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ) ' + ' LOG ON ' + '( NAME = ''' + @NAME_DB + '_log'', FILENAME = N''D:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\' + @NAME_DB + '_log.ldf'' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%) ') exec ('ALTER DATABASE [' + @NAME_DB + '] SET COMPATIBILITY_LEVEL = 100') exec ('IF (1 = FULLTEXTSERVICEPROPERTY(''IsFullTextInstalled'')) ' + 'begin EXEC [' + @NAME_DB + '].[dbo].[sp_fulltext_database] @action = ''enable'' end') exec ('ALTER DATABASE [' + @NAME_DB + '] SET ANSI_NULL_DEFAULT OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET ANSI_NULLS OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET ANSI_PADDING OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET ANSI_WARNINGS OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET ARITHABORT OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET AUTO_CLOSE OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET AUTO_CREATE_STATISTICS ON') exec ('ALTER DATABASE [' + @NAME_DB + '] SET AUTO_SHRINK OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET AUTO_UPDATE_STATISTICS ON') exec ('ALTER DATABASE [' + @NAME_DB + '] SET CURSOR_CLOSE_ON_COMMIT OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET CURSOR_DEFAULT GLOBAL') exec ('ALTER DATABASE [' + @NAME_DB + '] SET CONCAT_NULL_YIELDS_NULL OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET NUMERIC_ROUNDABORT OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET QUOTED_IDENTIFIER OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET RECURSIVE_TRIGGERS OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET DISABLE_BROKER')

162

exec ('ALTER DATABASE [' + @NAME_DB + '] SET AUTO_UPDATE_STATISTICS_ASYNC OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET DATE_CORRELATION_OPTIMIZATION OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET TRUSTWORTHY OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET ALLOW_SNAPSHOT_ISOLATION OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET PARAMETERIZATION SIMPLE') exec ('ALTER DATABASE [' + @NAME_DB + '] SET READ_COMMITTED_SNAPSHOT OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET HONOR_BROKER_PRIORITY OFF') exec ('ALTER DATABASE [' + @NAME_DB + '] SET READ_WRITE') exec ('ALTER DATABASE [' + @NAME_DB + '] SET RECOVERY SIMPLE') exec ('ALTER DATABASE [' + @NAME_DB + '] SET MULTI_USER') exec ('ALTER DATABASE [' + @NAME_DB + '] SET PAGE_VERIFY CHECKSUM') exec ('ALTER DATABASE [' + @NAME_DB + '] SET DB_CHAINING OFF')

--CRIAR TABELAS: exec('

DECLARE @TableID nvarchar(24) DECLARE @TableName nvarchar(500) DECLARE @TableItemID nvarchar(24) DECLARE @TableItemName nvarchar(500)

DECLARE @ChildTableID nvarchar(24) DECLARE @ParentTableID nvarchar(24) DECLARE @ChildTableName nvarchar(500) DECLARE @ParentTableName nvarchar(500)

DECLARE tables_cursor CURSOR FOR SELECT TableItemID TableID, TableItemName TableName FROM [' + @ModeloZ + '].dbo.Tables WHERE (TimeItemID = ''' + @TimeItemID+ ''') AND (TableID = N''0'')

OPEN tables_cursor

FETCH NEXT FROM tables_cursor INTO @TableID, @TableName print @TableID+ @TableName ; WHILE @@FETCH_STATUS = 0

BEGIN exec ('' --criar tabela CREATE TABLE [' + @NAME_DB + '].[dbo].[''+@TableName+'']( [ID] [nvarchar](24) NOT NULL, [Name] [nvarchar](500) NULL, CONSTRAINT [PK_''+@TableName+''] PRIMARY KEY CLUSTERED ( [ID] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]) ON [PRIMARY]'')

--preencher tabela exec (''INSERT INTO [' + @NAME_DB + '].[dbo].[''+@TableName+''] ([ID],[Name]) SELECT TableItemID, TableItemName FROM [' + @ModeloZ + '].dbo.Tables WHERE TimeItemID = ''''' + @TimeItemID + ''''' AND TableID = '''''' + @TableID + '''''''')

FETCH NEXT FROM tables_cursor INTO @TableID, @TableName print @TableID+ @TableName; END

CLOSE tables_cursor DEALLOCATE tables_cursor

--CRIAR ASOCIAÇÕES: exec('' DECLARE groups_cursor CURSOR FOR SELECT [' + @ModeloZ + '].dbo.Groups.ChildTableID, [' + @ModeloZ + '].dbo.Groups.ParentTableID, [' + @ModeloZ + '].dbo.Tables.TableItemName AS ChildTableName, Tables_1.TableItemName AS ParentTableName FROM [' + @ModeloZ + '].dbo.Groups INNER JOIN [' + @ModeloZ + '].dbo.Tables ON [' + @ModeloZ + '].dbo.Groups.TimeItemID = [' + @ModeloZ + '].dbo.Tables.TimeItemID AND [' + @ModeloZ + '].dbo.Groups.ChildTableID =[' + @ModeloZ + '].dbo.Tables.TableItemID INNER JOIN [' + @ModeloZ + '].dbo.Tables AS Tables_1 ON [' + @ModeloZ + '].dbo.Groups.TimeItemID = Tables_1.TimeItemID AND [' + @ModeloZ + '].dbo.Groups.ParentTableID = Tables_1.TableItemID

163

WHERE ([' + @ModeloZ + '].dbo.Groups.TimeItemID = '''''+ @TimeItemID+''''') AND ([' + @ModeloZ + '].dbo.Tables.TableID = N''''0'''') AND (Tables_1.TableID = N''''0'''') GROUP BY [' + @ModeloZ + '].dbo.Groups.ChildTableID, [' + @ModeloZ + '].dbo.Groups.ParentTableID, [' + @ModeloZ + '].dbo.Tables.TableID, [' + @ModeloZ + '].dbo.Tables.TableItemName, Tables_1.TableItemName '')

OPEN groups_cursor

FETCH NEXT FROM groups_cursor INTO @ChildTableID, @ParentTableID, @ChildTableName, @ParentTableName print @ChildTableID+ @ParentTableID+ '' '' + @ChildTableName+ @ParentTableName;

WHILE @@FETCH_STATUS = 0

BEGIN

--acrescentar campo atributo

exec (''ALTER TABLE [' + @NAME_DB + '].[dbo].[''+@ChildTableName+''] ADD [''+@ParentTableName+''] nvarchar(24)'')

--preencher atributo exec (''UPDATE child SET [''+@ParentTableName+''] = Groups.ParentTableItemID FROM [' + @NAME_DB + '].[dbo].[''+@ChildTableName+''] child INNER JOIN [' + @ModeloZ + '].dbo.Groups Groups ON child.ID = Groups.ChildTableItemID WHERE (Groups.TimeItemID = ''''' + @TimeItemID + ''''') AND (Groups.ChildTableID = '''''' + @ChildTableID + '''''') AND (Groups.ParentTableID = '''''' + @ParentTableID + '''''')'')

--criar associação exec(''ALTER TABLE [' + @NAME_DB + '].[dbo].[''+@ChildTableName+''] ADD FOREIGN KEY ([''+@ParentTableName+'']) REFERENCES [''+@ParentTableName+''](ID)'')

FETCH NEXT FROM groups_cursor INTO @ChildTableID, @ParentTableID, @ChildTableName, @ParentTableName print @ChildTableID+ @ParentTableID+ '' '' + @ChildTableName+ @ParentTableName;

END

CLOSE groups_cursor DEALLOCATE groups_cursor

') END

7.8. SCRIPT DA CONSULTA ON-THE-FLY DO MODELO Z

 Stored procedure (sp): o RPT_Dat_Conc_OTF  Funções (Table-Valued) auxiliares: o RPT_Dat_Conc_MSn o RPT_Dat_Conc_MSr o RPT_Dat_Conc_MI o RPT_Dat_Conc_Evol USE [Z] GO -- ======-- Description: Dados de Consulta de Dashboard calculados On-The-Fly nos Modelos Z e Z_d -- Junta MI e Evol calculados por funções, e nome dos elementos-detalhe -- ======

164

@Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) AS begin

SELECT meat.TimeItemID, meat.Dim_1_ID, meat.Dim_1_ItemID, meat.Dim_2_ID, meat.Dim_2_ItemID, meat.Dim_2sub_ID, meat.Dim_2sub_ItemID, Tables.TableItemName AS Dim_2sub_Item, meat.Pr, meat.MI, meat.Evol FROM ( SELECT COALESCE (MI.TimeItemID, Evol.TimeItemID) AS TimeItemID, COALESCE (MI.Dim_1_ID, Evol.Dim_1_ID) AS Dim_1_ID, COALESCE (MI.Dim_1_ItemID, Evol.Dim_1_ItemID) AS Dim_1_ItemID, COALESCE (MI.Dim_2_ID, Evol.Dim_2_ID) AS Dim_2_ID, COALESCE (MI.Dim_2_ItemID, Evol.Dim_2_ItemID) AS Dim_2_ItemID, COALESCE (MI.Dim_2sub_ID, Evol.Dim_2sub_ID) AS Dim_2sub_ID, COALESCE (MI.Dim_2sub_ItemID, Evol.Dim_2sub_ItemID) AS Dim_2sub_ItemID, COALESCE (MI.Pr, 0) AS Pr, COALESCE (MI.MI, 0) AS MI, COALESCE (Evol.Evol, 0) AS Evol

FROM dbo.RPT_Dat_Conc_MI (@TimeItemID, @Dim_1_base, @Dim_1_ID, @Dim_1_ItemID, @Dim_2_base, @Dim_2_ID, @Dim_2_ItemID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MI FULL OUTER JOIN dbo.RPT_Dat_Conc_Evol (@TimeItemID, @Dim_1_base, @Dim_1_ID, @Dim_1_ItemID, @Dim_2_base, @Dim_2_ID, @Dim_2_ItemID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS Evol ON MI.TimeItemID = Evol.TimeItemID AND MI.Dim_1_ID = Evol.Dim_1_ID AND MI.Dim_1_ItemID = Evol.Dim_1_ItemID AND MI.Dim_2_ID = Evol.Dim_2_ID AND MI.Dim_2_ItemID = Evol.Dim_2_ItemID AND MI.Dim_2sub_ID = Evol.Dim_2sub_ID AND MI.Dim_2sub_ItemID = Evol.Dim_2sub_ItemID) AS meat INNER JOIN Tables ON meat.TimeItemID = Tables.TimeItemID AND meat.Dim_2sub_ID = Tables.TableID AND meat.Dim_2sub_ItemID = Tables.TableItemID end GO

-- ======-- Description: Calcula Market Share Nacional On-The-Fly no Modelo Z -- ======

( SELECT Facts.TimeItemID, Dim_2_Filter.ParentTableID Dim_2_ID, Dim_2_Filter.ParentTableItemID Dim_2_ItemID, Dim_2_Detail.ChildTableID AS Dim_2sub_ID, Dim_2_Detail.ChildTableItemID AS Dim_2sub_ItemID, SUM(Facts.MetricValue) AS Pn, sum( SUM(Facts.MetricValue) ) over () AS Mn, SUM(Facts.MetricValue) / sum( SUM(Facts.MetricValue) ) over ()*100 AS MSn

165

FROM Facts_2D AS Facts INNER JOIN Groups AS Dim_2_Detail ON Facts.TimeItemID = Dim_2_Detail.TimeItemID AND Facts.BaseProd = Dim_2_Detail.ChildTableItemID INNER JOIN Groups AS Dim_2_Mkt ON Dim_2_Detail.TimeItemID = Dim_2_Mkt.TimeItemID AND Dim_2_Detail.ParentTableID = Dim_2_Mkt.ParentTableID AND Dim_2_Detail.ParentTableItemID = Dim_2_Mkt.ParentTableItemID INNER JOIN Groups AS Dim_2_Filter ON Dim_2_Mkt.TimeItemID = Dim_2_Filter.TimeItemID AND Dim_2_Mkt.ChildTableID = Dim_2_Filter.ChildTableID AND Dim_2_Mkt.ChildTableItemID = Dim_2_Filter.ChildTableItemID

WHERE (Facts.MetricID = @MetricID) AND (Dim_2_Mkt.ParentTableID = @Dim_2_Mkt) AND (Dim_2_Filter.ChildTableID = N'Produto')

GROUP BY Facts.TimeItemID, Dim_2_Detail.ChildTableID, Dim_2_Detail.ChildTableItemID, Dim_2_Filter.ParentTableID, Dim_2_Filter.ParentTableItemID

HAVING (Facts.TimeItemID = @TimeItemID) AND (Dim_2_Detail.ChildTableID = @Dim_2sub_ID) AND (Dim_2_Filter.ParentTableID = @Dim_2_ID) AND (Dim_2_Filter.ParentTableItemID = @Dim_2_ItemID) ) GO

-- ======-- Description: Calcula Market Share Regional On-The-Fly no Modelo Z -- ======

CREATE FUNCTION [dbo].[RPT_Dat_Conc_MSr] ( @TimeItemID_str nvarchar(24) = '201203', -- YYYYMM @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo) @Dim_1_ItemID nvarchar(24) = 'DIM 042', @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN ( SELECT Facts.TimeItemID, Dim_1_Filter.ParentTableID AS Dim_1_ID, Dim_1_Filter.ParentTableItemID AS Dim_1_ItemID, Dim_2_Filter.ParentTableID AS Dim_2_ID, Dim_2_Filter.ParentTableItemID AS Dim_2_ItemID, Dim_2_Detail.ChildTableID AS Dim_2sub_ID, Dim_2_Detail.ChildTableItemID AS Dim_2sub_ItemID, SUM(Facts.MetricValue) AS Pr, sum(SUM(Facts.MetricValue)) over () AS Mr, SUM(Facts.MetricValue) / sum(SUM(Facts.MetricValue) ) over () * 100 AS MSr

FROM Facts_2D AS Facts INNER JOIN Groups AS Dim_2_Detail ON Facts.BaseProd = Dim_2_Detail.ChildTableItemID INNER JOIN Groups AS Dim_2_Mkt ON Dim_2_Detail.TimeItemID = Dim_2_Mkt.TimeItemID AND Dim_2_Detail.ParentTableID = Dim_2_Mkt.ParentTableID AND Dim_2_Detail.ParentTableItemID= Dim_2_Mkt.ParentTableItemID INNER JOIN Groups AS Dim_2_Filter ON Dim_2_Mkt.TimeItemID = Dim_2_Filter.TimeItemID AND Dim_2_Mkt.ChildTableID = Dim_2_Filter.ChildTableID AND Dim_2_Mkt.ChildTableItemID = Dim_2_Filter.ChildTableItemID

INNER JOIN Groups AS Zona ON Facts.BaseGeo = Zona.ParentTableItemID INNER JOIN Groups AS [Zona/DIM] ON Zona.TimeItemID = [Zona/DIM].TimeItemID AND Zona.ChildTableID = [Zona/DIM].ChildTableID AND Zona.ChildTableItemID = [Zona/DIM].ChildTableItemID INNER JOIN Groups AS Dim_1_Filter ON [Zona/DIM].TimeItemID = Dim_1_Filter.TimeItemID AND [Zona/DIM].ParentTableID = Dim_1_Filter.ChildTableID AND [Zona/DIM].ParentTableItemID = Dim_1_Filter.ChildTableItemID AND Dim_2_Filter.TimeItemID = Dim_1_Filter.TimeItemID

WHERE (Facts.MetricID = @MetricID) AND (Dim_2_Mkt.ParentTableID = @Dim_2_Mkt) AND (Dim_2_Filter.ChildTableID = N'Produto') AND ([Zona/DIM].ChildTableID = N'Zona/DIM') AND (Zona.ParentTableID = N'Zona') AND ([Zona/DIM].ParentTableID = N'Região/DIM')

166

GROUP BY Facts.TimeItemID, Dim_2_Detail.ChildTableItemID, Dim_2_Detail.ChildTableID, Dim_2_Filter.ParentTableID, Dim_2_Filter.ParentTableItemID, Dim_1_Filter.ParentTableID, Dim_1_Filter.ParentTableItemID, Dim_2_Filter.TimeItemID

HAVING (Facts.TimeItemID = @TimeItemID) AND (Dim_2_Detail.ChildTableID = @Dim_2sub_ID) AND (Dim_2_Filter.ParentTableID = @Dim_2_ID) AND (Dim_2_Filter.ParentTableItemID = @Dim_2_ItemID) AND (Dim_1_Filter.ParentTableID = @Dim_1_ID) AND (Dim_1_Filter.ParentTableItemID = @Dim_1_ItemID) AND (Dim_2_Filter.TimeItemID = @TimeItemID_str) ) GO

-- ======-- Description: Calcula MI On-The-Fly nos Modelos Z, Z_d e Z+ -- pelo rácio entre MSR e MSN calculados por funções -- ======

ALTER FUNCTION [dbo].[RPT_Dat_Conc_MI] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo) @Dim_1_ItemID nvarchar(24) = 'DIM 042', @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN ( SELECT MSr.TimeItemID, MSr.Dim_1_ID, MSr.Dim_1_ItemID, MSr.Dim_2_ID, MSr.Dim_2_ItemID, MSr.Dim_2sub_ID, MSr.Dim_2sub_ItemID, MSr.Pr, MSr.MSr, MSr.MSr / MSn.MSn * 100 AS MI

FROM dbo.RPT_Dat_Conc_MSr (@TimeItemID, @TimeItemID, @Dim_1_base, @Dim_1_ID, @Dim_1_ItemID, @Dim_2_base, @Dim_2_ID, @Dim_2_ItemID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MSr

INNER JOIN RPT_Dat_Conc_MSn ( @TimeItemID , @Dim_2_base, @Dim_2_ID, @Dim_2_ItemID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MSn

ON MSr.TimeItemID = MSn.TimeItemID AND MSr.Dim_2_ID = MSn.Dim_2_ID AND MSr.Dim_2_ItemID = MSn.Dim_2_ItemID AND MSr.Dim_2sub_ID = MSn.Dim_2sub_ID AND MSr.Dim_2sub_ItemID = MSn.Dim_2sub_ItemID ) GO

-- ======-- Description: Calcula Evol On-The-Fly nos Modelos Z, Z_d e Z+ -- pelo rácio da MSR entre dois períodos, calculada por função -- ======

CREATE FUNCTION [dbo].[RPT_Dat_Conc_Evol] (

167

@TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo) @Dim_1_ItemID nvarchar(24) = 'DIM 042', @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN ( SELECT MSr0.TimeItemID, MSr0.Dim_1_ID, MSr0.Dim_1_ItemID, MSr0.Dim_2_ID, MSr0.Dim_2_ItemID, MSr0.Dim_2sub_ID, MSr0.Dim_2sub_ItemID, MSr0.MSr / MSr1.MSr * 100 AS Evol FROM dbo.RPT_Dat_Conc_MSr (@TimeItemID, @TimeItemID, @Dim_1_base, @Dim_1_ID, @Dim_1_ItemID, @Dim_2_base, @Dim_2_ID, @Dim_2_ItemID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MSr0

INNER JOIN dbo.RPT_Dat_Conc_MSr ( @TimeItemID, @TimeItemID- 100, @Dim_1_base, @Dim_1_ID, @Dim_1_ItemID, @Dim_2_base, @Dim_2_ID, @Dim_2_ItemID, @Dim_2sub_ID, @MetricID, @Dim_2_Mkt) AS MSr1

7.9. MATERIALIZAÇÃO DE ASSOCIAÇÕES INDIRECTAS (Z_D)

USE [Z_d] GO -- ======-- Description: Materialização de todas as associações possíveis (atalhos) -- que caracteriza o Modelo Z_d -- ======

CREATE procedure [dbo].[ETL_FullRel]

AS begin

Declare @counter int = 1

-- Associar tabelas com elas próprias – necessário para respeitar a lógica simples do algoritmo de consulta DELETE FROM Groups WHERE ChildTableID = ParentTableID and ChildTableItemID = ParentTableItemID

INSERT INTO Groups (TimeItemID, ChildTableID, ChildTableItemID, ParentTableID, ParentTableItemID) SELECT TimeItemID, TableID, TableItemID, TableID AS Expr1, TableItemID AS Expr4 FROM Tables

-- Caso especial pela associação n para n: inverter associação Zona/DIM -> Zona, criando Zona -> Zona/DIM DELETE FROM Groups WHERE (ChildTableID = 'Zona')

168

AND (ParentTableID = 'Zona/DIM')

INSERT INTO Groups (TimeItemID, ChildTableID, ChildTableItemID, ParentTableID, ParentTableItemID) SELECT TimeItemID, ParentTableID, ParentTableItemID, ChildTableID, ChildTableItemID FROM Groups AS Groups_1 WHERE (ChildTableID = 'Zona/DIM') AND (ParentTableID = 'Zona')

-- Estabelecer ssociações directas redundantes em toda as hierarquias WHILE @counter <> 0

BEGIN

SELECT @COUNTER = count(*) FROM (SELECT Groups_3.TimeItemID, Groups_3.ChildTableID, Groups_3.ChildTableItemID, Groups_1.ParentTableID, Groups_1.ParentTableItemID FROM Groups AS Groups_3 INNER JOIN Groups AS Groups_1 ON Groups_3.TimeItemID = Groups_1.TimeItemID AND Groups_3.ParentTableID = Groups_1.ChildTableID AND Groups_3.ParentTableItemID =Groups_1.ChildTableItemID) AS nextlevel LEFT OUTER JOIN Groups AS Groups_2 ON nextlevel.TimeItemID = Groups_2.TimeItemID AND nextlevel.ChildTableID = Groups_2.ChildTableID AND nextlevel.ChildTableItemID =Groups_2.ChildTableItemID AND nextlevel.ParentTableID = Groups_2.ParentTableID AND nextlevel.ParentTableItemID=Groups_2.ParentTableItemID WHERE (Groups_2.TimeItemID IS NULL)

INSERT INTO Groups (TimeItemID, ChildTableID, ChildTableItemID, ParentTableID, ParentTableItemID) SELECT DISTINCT nextlevel.TimeItemID, nextlevel.ChildTableID, nextlevel.ChildTableItemID, nextlevel.ParentTableID, nextlevel.ParentTableItemID FROM (SELECT Groups_3.TimeItemID, Groups_3.ChildTableID, Groups_3.ChildTableItemID, Groups_1.ParentTableID, Groups_1.ParentTableItemID FROM Groups AS Groups_3 INNER JOIN Groups AS Groups_1 ON Groups_3.TimeItemID = Groups_1.TimeItemID AND Groups_3.ParentTableID = Groups_1.ChildTableID AND Groups_3.ParentTableItemID =Groups_1.ChildTableItemID) AS nextlevel LEFT OUTER JOIN Groups AS Groups_2 ON nextlevel.TimeItemID = Groups_2.TimeItemID AND nextlevel.ChildTableID = Groups_2.ChildTableID AND nextlevel.ChildTableItemID =Groups_2.ChildTableItemID AND nextlevel.ParentTableID = Groups_2.ParentTableID AND nextlevel.ParentTableItemID=Groups_2.ParentTableItemID WHERE (Groups_2.TimeItemID IS NULL)

END

-- Associações cruzadas -- Conjunto Produtos -> DCI INSERT INTO Groups (TimeItemID, ChildTableID, ChildTableItemID, ParentTableID, ParentTableItemID) SELECT mixedlevel.TimeItemID, mixedlevel.ChildTableID, mixedlevel.ChildTableItemID, mixedlevel.ParentTableID, mixedlevel.ParentTableItemID FROM (SELECT DISTINCT Groups.TimeItemID, Groups.ParentTableID AS ChildTableID, Groups.ParentTableItemID AS ChildTableItemID, Groups_1.ParentTableID, Groups_1.ParentTableItemID FROM Groups INNER JOIN Groups AS Groups_1

169

ON Groups.TimeItemID = Groups_1.TimeItemID AND Groups.ChildTableID = Groups_1.ChildTableID AND Groups.ChildTableItemID = Groups_1.ChildTableItemID WHERE (Groups.ChildTableID = N'Produto') AND (Groups.ParentTableID = N'Conjunto Produtos') AND (Groups_1.ParentTableID = N'DCI')) AS mixedlevel LEFT OUTER JOIN Groups AS Groups_2 ON mixedlevel.TimeItemID = Groups_2.TimeItemID AND mixedlevel.ChildTableID = Groups_2.ChildTableID AND mixedlevel.ChildTableItemID=Groups_2.ChildTableItemID AND mixedlevel.ParentTableID = Groups_2.ParentTableID AND mixedlevel.ParentTableItemID=Groups_2.ParentTableItemID WHERE (Groups_2.TimeItemID IS NULL) end GO

Nota: casos de carácter excepcional, como por ex.hierarquias envolvendo associações n-n, e associações cruzadas entre hierarquias, tratados de forma especial no código acima, também são passíveis de generalização algoritmíca, o que será estabelecido em trabalho futuro

7.10. SCRIPT DA CONSULTA ON-THE-FLY DO MODELO Z_D

 Stored procedure (sp): o RPT_Dat_Conc_OTF – esta camada é igual à do Modelo Z (Apêndice 8)  Funções (Table-Valued) auxiliares: o RPT_Dat_Conc_MSn o RPT_Dat_Conc_MSr o RPT_Dat_Conc_MI – esta camada é igual à do Modelo Z (Apêndice 8) o RPT_Dat_Conc_Evol – esta camada é igual à do Modelo Z (Apêndice 8) USE [Z_d] GO -- ======-- Description: Calcula Market Share Nacional On-The-Fly no Modelo Z_d -- ======

CREATE FUNCTION [dbo].[RPT_Dat_Conc_MSn] ( @TimeItemID_str nvarchar(24)= '201203', -- YYYYMM (estrutura) @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN

( SELECT Facts.TimeItemID, Dim_2_Filter.ChildTableID Dim_2_ID, Dim_2_Filter.ChildTableItemID Dim_2_ItemID, Dim_2_Detail.ParentTableID AS Dim_2sub_ID, Dim_2_Detail.ParentTableItemID AS Dim_2sub_ItemID, SUM(Facts.MetricValue) AS Pn, sum( SUM(Facts.MetricValue) ) over () as Mn, SUM(Facts.MetricValue) / sum( SUM(Facts.MetricValue) ) over () * 100 as MSn

FROM Groups AS Dim_2_Filter INNER JOIN Facts_2D AS Facts INNER JOIN Groups AS Dim_2_Mkt ON Facts.BaseProd = Dim_2_Mkt.ChildTableItemID ON Dim_2_Filter.ParentTableID = Dim_2_Mkt.ParentTableID AND Dim_2_Filter.ParentTableItemID = Dim_2_Mkt.ParentTableItemID INNER JOIN Groups AS Dim_2_Detail ON Facts.BaseProd = Dim_2_Detail.ChildTableItemID

WHERE (Dim_2_Mkt.ChildTableID = @Dim_2_base) AND (Facts.MetricID = @MetricID) AND (Dim_2_Mkt.ParentTableID = @Dim_2_Mkt) AND (Dim_2_Detail.TimeItemID = @TimeItemID_str) AND (Dim_2_Detail.ChildTableID = @Dim_2_base)

GROUP BY Facts.TimeItemID, Dim_2_Mkt.TimeItemID, Dim_2_Filter.TimeItemID,

170

Dim_2_Filter.ChildTableID, Dim_2_Filter.ChildTableItemID, Dim_2_Detail.ParentTableID, Dim_2_Detail.ParentTableItemID

HAVING (Facts.TimeItemID = @TimeItemID) AND (Dim_2_Mkt.TimeItemID = @TimeItemID_str) AND (Dim_2_Filter.TimeItemID = @TimeItemID_str) AND (Dim_2_Filter.ChildTableID = @Dim_2_ID) AND (Dim_2_Filter.ChildTableItemID = @Dim_2_ItemID) AND (Dim_2_Detail.ParentTableID = @Dim_2sub_ID) ) GO

-- ======-- Description: Calcula Market Share Regional On-The-Fly no Modelo Z_d -- ======

CREATE FUNCTION [dbo].[RPT_Dat_Conc_MSr] ( @TimeItemID_str nvarchar(24) = '201203', -- YYYYMM @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo) @Dim_1_ItemID nvarchar(24) = 'DIM 042', @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN ( SELECT Facts.TimeItemID, Dim_1_Filter.ParentTableID AS Dim_1_ID, Dim_1_Filter.ParentTableItemID AS Dim_1_ItemID, Dim_2_Filter.ChildTableID AS Dim_2_ID, Dim_2_Filter.ChildTableItemID AS Dim_2_ItemID, Dim_2_Detail.ParentTableID AS Dim_2sub_ID,Dim_2_Detail.ParentTableItemID AS Dim_2sub_ItemID, SUM(Facts.MetricValue) AS Pr, sum( SUM(Facts.MetricValue) ) over () AS Mr, SUM(Facts.MetricValue) / sum( SUM(Facts.MetricValue) ) over () * 100 AS MSr

FROM Groups AS Dim_2_Filter INNER JOIN Facts_2D AS Facts INNER JOIN Groups AS Dim_2_Mkt ON Facts.BaseProd = Dim_2_Mkt.ChildTableItemID INNER JOIN Groups AS Dim_1_Filter ON Facts.BaseGeo = Dim_1_Filter.ChildTableItemID ON Dim_2_Filter.ParentTableID = Dim_2_Mkt.ParentTableID AND Dim_2_Filter.ParentTableItemID = Dim_2_Mkt.ParentTableItemID INNER JOIN Groups AS Dim_2_Detail ON Facts.BaseProd = Dim_2_Detail.ChildTableItemID

GROUP BY Facts.TimeItemID, Dim_1_Filter.ParentTableID, Dim_1_Filter.ParentTableItemID, Dim_2_Mkt.TimeItemID, Dim_1_Filter.TimeItemID, Dim_2_Filter.TimeItemID, Dim_2_Filter.ChildTableID, Dim_2_Filter.ChildTableItemID, Dim_2_Detail.ParentTableID, Dim_2_Detail.ParentTableItemID

HAVING (Facts.TimeItemID = @TimeItemID) AND (Dim_1_Filter.ParentTableID = @Dim_1_ID) AND (Dim_1_Filter.ParentTableItemID = @Dim_1_ItemID) AND (Dim_2_Mkt.TimeItemID = @TimeItemID_str) AND (Dim_1_Filter.TimeItemID = @TimeItemID_str) AND (Dim_2_Filter.TimeItemID = @TimeItemID_str) AND (Dim_2_Filter.ChildTableID = @Dim_2_ID) AND (Dim_2_Filter.ChildTableItemID = @Dim_2_ItemID) AND (Dim_2_Detail.ParentTableID = @Dim_2sub_ID) ) GO

171

7.11. SCRIPT DE CARREGAMENTO DOS FACTOS DE Z_D PARA Z+

truncate table [Z+].dbo.coordmap_ go truncate table [Z+].dbo.facts go

--Factos Visitas

INSERT INTO [Z+].dbo.Facts (CoordID, TimeItemID, MetricID, MetricValue) SELECT 'DIM_' + BaseOrg + '+Produto_' + BaseProd + '+Zona_' + BaseGeo AS CoordID, TimeItemID, MetricID, MetricValue FROM z_d.dbo.Facts_3D go

--Factos Vendas

INSERT INTO [Z+].dbo.Facts (CoordID, TimeItemID, MetricID, MetricValue) SELECT 'Produto_' + BaseProd + '+Zona_' + BaseGeo AS CoordID, TimeItemID, MetricID, MetricValue FROM z_d.dbo.Facts_2D go

--Coordenadas Visitas

INSERT INTO [Z+].dbo.CoordMap_ (CoordID, TableID, TableItemID) SELECT distinct 'DIM_' + BaseOrg + '+Produto_' + BaseProd + '+Zona_' + BaseGeo AS CoordID, 'DIM' as tableid, BaseOrg as tableitemid FROM z_d.dbo.Facts_3D go

INSERT INTO [Z+].dbo.CoordMap_ (CoordID, TableID, TableItemID) SELECT distinct 'DIM_' + BaseOrg + '+Produto_' + BaseProd + '+Zona_' + BaseGeo AS CoordID, 'Produto' as tableid, BaseProd as tableitemid FROM z_d.dbo.Facts_3D go

INSERT INTO [Z+].dbo.CoordMap_ (CoordID, TableID, TableItemID) SELECT distinct 'DIM_' + BaseOrg + '+Produto_' + BaseProd + '+Zona_' + BaseGeo AS CoordID, 'Zona' as tableid, BaseGeo as tableitemid FROM z_d.dbo.Facts_3D go

172

--Coordenadas Vendas

INSERT INTO [Z+].dbo.CoordMap_ (CoordID, TableID, TableItemID) SELECT distinct 'Produto_' + BaseProd + '+Zona_' + BaseGeo AS CoordID, 'Produto' as tableid, BaseProd as tableitemid FROM z_d.dbo.Facts_2D go

INSERT INTO [Z+].dbo.CoordMap_ (CoordID, TableID, TableItemID) SELECT distinct 'Produto_' + BaseProd + '+Zona_' + BaseGeo AS CoordID, 'Zona' as tableid, BaseGeo as tableitemid FROM z_d.dbo.Facts_2D go

7.12. SCRIPT DA CONSULTA ON-THE-FLY DO MODELO Z+

 Stored procedure (sp): o RPT_Dat_Conc_OTF – esta camada é igual à do Modelo Z (Apêndice 8)  Funções (Table-Valued) auxiliares: o RPT_Dat_Conc_MSn o RPT_Dat_Conc_MSr o RPT_Dat_Conc_MI – esta camada é igual à do Modelo Z (Apêndice 8) o RPT_Dat_Conc_Evol – esta camada é igual à do Modelo Z (Apêndice 8) USE [Z+] GO -- ======-- Description: Calcula Market Share Nacional On-The-Fly no Modelo Z+ -- ======

( SELECT Facts_1.TimeItemID, Dim_2_Filter.ChildTableID AS Dim_2_ID, Dim_2_Filter.ChildTableItemID AS Dim_2_ItemID, Dim_2_Detail.ParentTableID AS Dim_2sub_ID, Dim_2_Detail.ParentTableItemID AS Dim_2sub_ItemID, SUM(Facts_1.MetricValue) AS Pn, sum( SUM(Facts_1.MetricValue)) over() AS Mn, SUM(Facts_1.MetricValue) / sum( SUM(Facts_1.MetricValue)) over()*100 AS MSn

FROM Facts AS Facts_1 INNER JOIN CoordMap ON Facts_1.CoordID = CoordMap.coordid INNER JOIN CoordMap AS CoordMap_1 ON Facts_1.CoordID = CoordMap_1.coordid INNER JOIN Groups AS Dim_2_Filter INNER JOIN Groups AS Dim_2_Mkt ON Dim_2_Filter.ParentTableID = Dim_2_Mkt.ParentTableID AND Dim_2_Filter.ParentTableItemID = Dim_2_Mkt.ParentTableItemID ON CoordMap_1.tableid = Dim_2_Mkt.ChildTableID AND CoordMap_1.tableitemid = Dim_2_Mkt.ChildTableItemID INNER JOIN Groups AS Dim_2_Detail ON CoordMap.tableid = Dim_2_Detail.ChildTableID AND CoordMap.tableitemid = Dim_2_Detail.ChildTableItemID

173

WHERE (Dim_2_Mkt.ChildTableID = @Dim_2_base) AND (Facts_1.MetricID = @MetricID) AND (Dim_2_Mkt.ParentTableID = @Dim_2_Mkt) AND (Dim_2_Detail.TimeItemID = @TimeItemID_str) AND (Dim_2_Detail.ChildTableID = @Dim_2_base)

GROUP BY Facts_1.TimeItemID, Dim_2_Mkt.TimeItemID, Dim_2_Filter.TimeItemID, Dim_2_Filter.ChildTableID, Dim_2_Filter.ChildTableItemID, Dim_2_Detail.ParentTableID, Dim_2_Detail.ParentTableItemID

HAVING (Dim_2_Mkt.TimeItemID = @TimeItemID_str) AND (Dim_2_Filter.TimeItemID = @TimeItemID_str) AND (Dim_2_Filter.ChildTableID = @Dim_2_ID) AND (Dim_2_Filter.ChildTableItemID = @Dim_2_ItemID) AND (Dim_2_Detail.ParentTableID = @Dim_2sub_ID) AND (Facts_1.TimeItemID = @TimeItemID) ) GO

-- ======-- Description: Calcula Market Share Regional On-The-Fly no Modelo Z+ -- ======CREATE FUNCTION [dbo].[RPT_Dat_Conc_MSr] ( @TimeItemID_str nvarchar(24) = '201203', -- YYYYMM @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo) @Dim_1_ItemID nvarchar(24) = 'DIM 042', @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência

) RETURNS TABLE AS RETURN ( SELECT Facts.TimeItemID, Dim_1_Filter.ParentTableID AS Dim_1_ID,Dim_1_Filter.ParentTableItemID AS Dim_1_ItemID, Dim_2_Filter.ChildTableID AS Dim_2_ID,Dim_2_Filter.ChildTableItemID AS Dim_2_ItemID, Dim_2_Detail.ParentTableID AS Dim_2sub_ID,Dim_2_Detail.ParentTableItemID AS Dim_2sub_ItemID, SUM(Facts.MetricValue) AS Pr, sum( SUM(Facts.MetricValue) ) over () AS Mr, SUM(Facts.MetricValue) / sum( SUM(Facts.MetricValue) ) over () * 100 AS MSr

FROM CoordMap INNER JOIN Facts INNER JOIN CoordMap AS CoordMap_1 ON Facts.CoordID = CoordMap_1.coordid ON CoordMap.coordid = Facts.CoordID INNER JOIN CoordMap AS CoordMap_2 ON Facts.CoordID = CoordMap_2.coordid INNER JOIN Groups AS Dim_2_Mkt INNER JOIN Groups AS Dim_2_Filter ON Dim_2_Mkt.ParentTableID = Dim_2_Filter.ParentTableID AND Dim_2_Mkt.ParentTableItemID = Dim_2_Filter.ParentTableItemID ON CoordMap_1.tableid = Dim_2_Mkt.ChildTableID AND CoordMap_1.tableitemid = Dim_2_Mkt.ChildTableItemID INNER JOIN Groups AS Dim_1_Filter ON CoordMap.tableid = Dim_1_Filter.ChildTableID AND CoordMap.tableitemid = Dim_1_Filter.ChildTableItemID INNER JOIN Groups AS Dim_2_Detail ON CoordMap_2.tableid = Dim_2_Detail.ChildTableID AND CoordMap_2.tableitemid = Dim_2_Detail.ChildTableItemID

174

HAVING (Dim_1_Filter.ParentTableID = @Dim_1_ID) AND (Dim_1_Filter.ParentTableItemID = @Dim_1_ItemID) AND (Dim_2_Mkt.TimeItemID = @TimeItemID_str) AND (Dim_1_Filter.TimeItemID = @TimeItemID_str) AND (Dim_2_Filter.TimeItemID = @TimeItemID_str) AND (Dim_2_Filter.ChildTableID = @Dim_2_ID) AND (Dim_2_Filter.ChildTableItemID = @Dim_2_ItemID) AND (Dim_2_Detail.ParentTableID = @Dim_2sub_ID) AND (Facts.TimeItemID = @TimeItemID) ) GO

7.13. SCRIPT DA CONSULTA ON-THE-FLY DO MODELO DIMENSIONAL

 Métricas calculadas (MDX ecpressions)  Consulta (MDX query) -- ======-- MÉTRICAS CALCULADAS -- ======CALCULATE;

CREATE MEMBER CURRENTCUBE.[Measures].MSr AS ([Measures].[Metric Value], produto.produto.currentmember, [regiãoDIM].[DIM].currentmember) /([Measures].[Metric Value], produto.produto.[All], [regiãoDIM].[DIM].currentmember),

VISIBLE = 1 ;

CREATE MEMBER CURRENTCUBE.[Measures].MSr1 AS ([Measures].[Metric Value], produto.produto.currentmember, [regiãoDIM].[DIM].currentmember, Parallelperiod([Time Item].[ID].[ID], 12) ) /([Measures].[Metric Value], produto.produto.[All], [regiãoDIM].[DIM].currentmember, Parallelperiod([Time Item].[ID].[ID], 12)), VISIBLE = 1 ;

CREATE MEMBER CURRENTCUBE.[Measures].MSn AS ([Measures].[Metric Value], produto.produto.currentmember, [regiãoDIM].[DIM].[All] )

/([Measures].[Metric Value], produto.produto.[All], [regiãoDIM].[DIM].[All] ), VISIBLE = 1 ;

CREATE MEMBER CURRENTCUBE.[Measures].MI AS ([Measures].[MSr]/[Measures].[MSn]*100 ), VISIBLE = 1;

CREATE MEMBER CURRENTCUBE.[Measures].Evol AS iif(measures.msr1=0,null, ([Measures].msr/measures.msr1*100 )), VISIBLE = 1;

-- ======-- CONSULTA -- ======SELECT

NON EMPTY { [Measures].[Metric Value], [Measures].[MI], [Measures].[Evol] } ON COLUMNS,

NON EMPTY { ([Time Item].[ID].[ID].ALLMEMBERS * [RegiãoDIM].[DIM].[DIM].ALLMEMBERS * [Produto].[DCI - ID].[DCI - ID].ALLMEMBERS * [Produto].[Produto].[Produto].ALLMEMBERS ) }

175

ON ROWS

FROM ( SELECT ( { [Produto].[DCI - ID].&[DCI155], [Produto].[DCI - ID].&[DCI181], [Produto].[DCI - ID].&[DCI219], [Produto].[DCI - ID].&[DCI233], [Produto].[DCI - ID].&[DCI286] } ) ON COLUMNS

FROM ( SELECT ( { [Metric].[ID].&[Euros] } ) ON COLUMNS

FROM ( SELECT ( { [RegiãoDIM].[DIM].&[DIM 042] } ) ON COLUMNS

FROM ( SELECT ( { [Time Item].[ID].&[201203] } ) ON COLUMNS

FROM [R]))))

7.14. SCRIPT DA CAMADA INFERIOR DA CONSULTA ON-THE-FLY APLICADA A AM

USE [AM] GO -- ======-- Description: Calcula Market Share Nacional -- ======CREATE FUNCTION [dbo].[RPT_Dat_Conc_MSn] ( @TimeItemID nvarchar(24) = '201203', -- YYYYMM

@Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4',

@Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod)

@MetricID nvarchar(24) = 'Euros',

@Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN ( SELECT PR_oQue_ZO_onde_VE_foiVendido.PR_oQue_ZO_onde_VE_foiVendido_ChangedAt AS TimeItemID, @Dim_2_ID AS Dim_2_ID, PR_PertenceA_CP_Classifica.CP_ID_Classifica AS Dim_2_ItemID, @Dim_2sub_ID AS Dim_2sub_ID, PR_PertenceA_DC_Classifica.PR_ID_PertenceA AS Dim_2sub_ItemID, SUM(VE_EU_Vendas_euros.VE_EU_Vendas_euros) AS Pn, sum(SUM(VE_EU_Vendas_euros.VE_EU_Vendas_euros) ) over () as Mn, SUM(VE_EU_Vendas_euros.VE_EU_Vendas_euros) / sum(SUM(VE_EU_Vendas_euros.VE_EU_Vendas_euros) ) over () * 100 as MSn FROM VE_EU_Vendas_euros INNER JOIN VE_Vendas ON VE_EU_Vendas_euros.VE_ID = VE_Vendas.VE_ID INNER JOIN PR_oQue_ZO_onde_VE_foiVendido ON VE_Vendas.VE_ID = PR_oQue_ZO_onde_VE_foiVendido.VE_ID_foiVendido INNER JOIN PR_PertenceA_DC_Classifica ON PR_oQue_ZO_onde_VE_foiVendido.PR_ID_oQue = PR_PertenceA_DC_Classifica.PR_ID_PertenceA AND PR_oQue_ZO_onde_VE_foiVendido.PR_oQue_ZO_onde_VE_foiVendido_ChangedAt = PR_PertenceA_DC_Classifica.PR_PertenceA_DC_Classifica_ChangedAt INNER JOIN PR_PertenceA_DC_Classifica AS PR_PertenceA_DC_Classifica_1 ON PR_PertenceA_DC_Classifica.PR_PertenceA_DC_Classifica_ChangedAt = PR_PertenceA_DC_Classifica_1.PR_PertenceA_DC_Classifica_ChangedAt AND PR_PertenceA_DC_Classifica.DC_ID_Classifica = PR_PertenceA_DC_Classifica_1.DC_ID_Classifica INNER JOIN PR_PertenceA_CP_Classifica ON PR_PertenceA_DC_Classifica_1.PR_PertenceA_DC_Classifica_ChangedAt = PR_PertenceA_CP_Classifica.PR_PertenceA_CP_Classifica_ChangedAt AND PR_PertenceA_DC_Classifica_1.PR_ID_PertenceA = PR_PertenceA_CP_Classifica.PR_ID_PertenceA GROUP BY PR_PertenceA_CP_Classifica.CP_ID_Classifica, PR_PertenceA_DC_Classifica.PR_ID_PertenceA, PR_oQue_ZO_onde_VE_foiVendido.PR_oQue_ZO_onde_VE_foiVendido_ChangedAt HAVING (PR_PertenceA_CP_Classifica.CP_ID_Classifica = @Dim_2_ItemID) AND (PR_oQue_ZO_onde_VE_foiVendido.PR_oQue_ZO_onde_VE_foiVendido_ChangedAt = @TimeItemID) )

176

-- ======-- Description: Calcula Market Share Regional -- ======

CREATE FUNCTION [dbo].[RPT_Dat_Conc_MSr] ( @TimeItemID_str nvarchar(24) = '201203', -- YYYYMM

@TimeItemID nvarchar(24) = '201203', -- YYYYMM

@Dim_1_base nvarchar(24) = 'Zona', -- BaseGeo @Dim_1_ID nvarchar(24) = 'DIM', -- Filtro 1 (Geo) @Dim_1_ItemID nvarchar(24) = 'DIM 042',

@Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4',

@Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod)

@MetricID nvarchar(24) = 'Euros',

@Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN ( SELECT PR_PertenceA_DC_Classifica.PR_PertenceA_DC_Classifica_ChangedAt, PR_oQue_ZO_onde_VE_foiVendido.PR_oQue_ZO_onde_VE_foiVendido_ChangedAt AS TimeItemID, @Dim_1_ID AS Dim_1_ID, DI_eResponsavelPor_RD_TemResponsavel.DI_ID_eResponsavelPor AS Dim_1_ItemID, @Dim_2_ID AS Dim_2_ID, PR_PertenceA_CP_Classifica.CP_ID_Classifica AS Dim_2_ItemID, @Dim_2sub_ID AS Dim_2sub_ID, PR_PertenceA_DC_Classifica.PR_ID_PertenceA AS Dim_2sub_ItemID, SUM(VE_EU_Vendas_euros.VE_EU_Vendas_euros) AS Pr, sum(SUM(VE_EU_Vendas_euros.VE_EU_Vendas_euros) ) over () as Mr, SUM(VE_EU_Vendas_euros.VE_EU_Vendas_euros) / sum(SUM(VE_EU_Vendas_euros.VE_EU_Vendas_euros) ) over () * 100 as MSr FROM VE_EU_Vendas_euros INNER JOIN VE_Vendas ON VE_EU_Vendas_euros.VE_ID = VE_Vendas.VE_ID INNER JOIN PR_oQue_ZO_onde_VE_foiVendido ON VE_Vendas.VE_ID = PR_oQue_ZO_onde_VE_foiVendido.VE_ID_foiVendido INNER JOIN PR_PertenceA_DC_Classifica ON PR_oQue_ZO_onde_VE_foiVendido.PR_ID_oQue = PR_PertenceA_DC_Classifica.PR_ID_PertenceA INNER JOIN PR_PertenceA_DC_Classifica AS PR_PertenceA_DC_Classifica_1 ON PR_PertenceA_DC_Classifica.PR_PertenceA_DC_Classifica_ChangedAt = PR_PertenceA_DC_Classifica_1.PR_PertenceA_DC_Classifica_ChangedAt AND PR_PertenceA_DC_Classifica.DC_ID_Classifica = PR_PertenceA_DC_Classifica_1.DC_ID_Classifica INNER JOIN PR_PertenceA_CP_Classifica ON PR_PertenceA_DC_Classifica_1.PR_PertenceA_DC_Classifica_ChangedAt = PR_PertenceA_CP_Classifica.PR_PertenceA_CP_Classifica_ChangedAt AND PR_PertenceA_DC_Classifica_1.PR_ID_PertenceA = PR_PertenceA_CP_Classifica.PR_ID_PertenceA INNER JOIN DI_eResponsavelPor_RD_TemResponsavel INNER JOIN ZD_PerenceA_RD_Agrupa ON DI_eResponsavelPor_RD_TemResponsavel.RD_ID_TemResponsavel = ZD_PerenceA_RD_Agrupa.RD_ID_Agrupa AND DI_eResponsavelPor_RD_TemResponsavel.DI_eResponsavelPor_RD_TemResponsavel_ChangedAt = ZD_PerenceA_RD_Agrupa.ZD_PerenceA_RD_Agrupa_ChangedAt INNER JOIN ZO_eLocalDe_ZD_LocalizaSeEm ON ZD_PerenceA_RD_Agrupa.ZD_ID_PerenceA = ZO_eLocalDe_ZD_LocalizaSeEm.ZD_ID_LocalizaSeEm AND ZD_PerenceA_RD_Agrupa.ZD_PerenceA_RD_Agrupa_ChangedAt = ZO_eLocalDe_ZD_LocalizaSeEm.ZO_eLocalDe_ZD_LocalizaSeEm_ChangedAt ON PR_oQue_ZO_onde_VE_foiVendido.ZO_ID_onde = ZO_eLocalDe_ZD_LocalizaSeEm.ZO_ID_eLocalDe AND PR_PertenceA_CP_Classifica.PR_PertenceA_CP_Classifica_ChangedAt = ZO_eLocalDe_ZD_LocalizaSeEm.ZO_eLocalDe_ZD_LocalizaSeEm_ChangedAt GROUP BY PR_PertenceA_CP_Classifica.CP_ID_Classifica, PR_PertenceA_DC_Classifica.PR_ID_PertenceA, PR_oQue_ZO_onde_VE_foiVendido.PR_oQue_ZO_onde_VE_foiVendido_ChangedAt, DI_eResponsavelPor_RD_TemResponsavel.DI_ID_eResponsavelPor, PR_PertenceA_DC_Classifica.PR_PertenceA_DC_Classifica_ChangedAt HAVING (PR_PertenceA_CP_Classifica.CP_ID_Classifica = @Dim_2_ItemID) AND (PR_oQue_ZO_onde_VE_foiVendido.PR_oQue_ZO_onde_VE_foiVendido_ChangedAt = @TimeItemID) AND (DI_eResponsavelPor_RD_TemResponsavel.DI_ID_eResponsavelPor = @Dim_1_ItemID) AND (PR_PertenceA_DC_Classifica.PR_PertenceA_DC_Classifica_ChangedAt = @TimeItemID_str) ) GO

177

8. REFERÊNCIAS BIBLIOGRÁFICAS

Agrawal, V., Sundararaghavan, P. S., Ahmed, M. U., & Nandkeolyar, U. (2009). View Materialization in a Data Cube: Optimization Models and Heuristics. In K. Siau & J. Erickson (Eds.), Advanced Principles for Improving Database Design, Systems Modeling, and Software Development. Hershey, PA: IGI Global. doi:10.4018/978- 1-60566-172-8

Ambler, S. W. (2003). Agile database techniques: effective strategies for the agile software developer. Indianapolis, IN: Wiley Publishing.

Ambler, T. (2000). Marketing Metrics. Business Strategy Review, 11(2), 59–66. doi:10.1111/1467-8616.00138

Asghar, S., Fong, S., & Hussain, T. (2009). Business Intelligence Modeling: A Case Study of Disaster Management Organization in Pakistan. 2009 Fourth International Conference on Computer Sciences and Convergence Information Technology, 673–678. doi:10.1109/ICCIT.2009.318

Astrahan, M. M., Blasgen, M. W., Chamberlin, D. D., K.P.Eswaran, J.N.Gray, Griffiths, P. P., King, W. F., et al. (1976). System R: relational approach to database management. ACM Transactions on Database Systems (TODS), 1(2), 97–137.

Atkinson, P., & Vieira, R. (2012). Beginning Microsoft SQL Server 2012 Programming. Indianapolis, IN: John Wiley & Sons, Inc.

Bachman, C. W. (1969). Data structure diagrams. ACM Sigmis Database, 4-10.

Beck, C. E. (2007). A Communications Model for Knowledge Sharing. In A. F. Salam & J. R. Stevens (Eds.), Semantic Web Technologies and E-Business: Toward the Integrated Virtual Organization and Business Process Automation. Hershey, PA: Idea Group Publishing.

Ben-Gan, I. (2012). Microsoft SQL Server 2012 T-SQL Fundamentals. Sebastopol, CA: O’Reilly Media, Inc.

Bernstein, P. A. (1976). Synthesizing third normal form relations from functional dependencies. ACM Transactions on Database Systems, 1(4), 277–298. doi:10.1145/320493.320489

Bouman, R., & Dongen, J. Van. (2009). Pentaho solutions: business intelligence and data warehousing with pentaho and mysql. Indianapolis, IN: Wiley.

Brosnan, A. (2012). Ovum Decision Matrix: Selecting a CRM Vendor in the Life Sciences Industry (pp. 1–27).

178

Caetano, T. V, & Costa, C. J. (2012). Data Warehousing num contexto de Sistemas Integrados. CAPSI 2012.

Celko, J. (2006). Joe Celko’s Analytics and OLAP in SQL. San Francisco, CA: Morgan Kaufmann Publishers.

Chen, P. (1976). The entity-relationship model—toward a unified view of data. ACM Transactions on Database Systems (TODS), 1(1), 9–36.

Chen, Z., Gangopadhyay, A., Karabatis, G., McGuire, M., & Welty, C. (2009). Semantic Integration and Knowledge Discovery for Environmental Research. In K. Siau & J. Erickson (Eds.), Advanced Principles for Improving Database Design, Systems Modeling, and Software Development. Hershey, PA: IGI Global. doi:10.4018/978-1-60566-172-8

Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377–387.

Codd, E. F. (1979). Extending the database relational model to capture more meaning. ACM Transactions on Database Systems, 4(4), 397–434. doi:10.1145/320107.320109

Codd, E. F. (1980). Data models in database management. ACM SIGMOD Record, 112–114.

Codd, E. F. (1990). The relational model for database management: version 2. Addison-Wesley Publishing Co.

Codd, E. F., Codd, S., & Salley, C. (1993). Providing OLAP (on-line analytical processing) to user analysts: An IT mandate, 1993. Arbor Software, now Hyperion Solutions Corp., 3–5.

Cody, W. F., Kreulen, J. T., Krishna, V., & Spangler, W. S. (2002). The integration of business intelligence and knowledge management. IBM Systems Journal, 41(4), 697–713. doi: 10.1147/sj.414.0697

Collier, K. (2011). Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing. Crawfordsville, IN: Addison-Wesley.

Connolly, T., & Begg, C. (2005). Database systems: a practical approach to design, implementation, and management (4th ed.). Essex, England: Pearson Education.

Corr, L. C., & Stagnitto, J. (2012). Agile Data Warehouse Design. Decisionone Consulting (Revision.). Leeds, UK: DecisionOne Press.

179

Curino, C. A., Moon, H. J., & Zaniolo, C. (2009). Automating database schema evolution in information system upgrades. Proceedings of the Second International Workshop on Hot Topics in Software Upgrades - HotSWUp ’09, 1. doi:10.1145/1656437.1656444

Curino, C. A., Tanca, L., Moon, H. J. M., & Zaniolo, C. (2008). Schema evolution in wikipedia: toward a web information system benchmark. In International Conference on Enterprise Information Systems.

Date, C. J. (2012). Database Design and Relational Theory: Normal Forms and All That Jazz. Sebastopol, CA: O’Reilly.

Date, C. J., & Fagin, R. (1992). Simple conditions for guaranteeing higher normal forms in relational databases. ACM Transactions on Database Systems, 17(3), 465–476. doi:10.1145/132271.132274

Date, C. J., Darwen, H., & Lorentzos, N. A. (2003). Temporal Data & the Relational Model: A Detailed Investigation into the Application of Interval and Relation Theory to the Problem of Temporal Database Management. San Francisco, CA: Morgan Kaufmann Publishers.

Datta, A., & Thomas, H. (1999). The cube data model: a conceptual model and algebra for on-line analytical processing in data warehouses. Decision Support Systems, 27(3), 289–301. doi:10.1016/S0167-9236(99)00052-4

Davidson, L., & Moss, J. M. (2012). Pro SQL Server 2012 Relational Database Design and Implementation. Apress.

Decreto-Lei no 176/2006 – Estatuto do Medicamento (2006).Diário da República, 167(I).

De Vries, D., & Roddick, J. F. (2007). The case for mesodata: An empirical investigation of an evolving database system. Information and Software Technology, 49(9-10), 1061–1072. doi:10.1016/j.infsof.2006.11.001

Diestel, R. (2010). Graph Theory (4th ed.). New York, NY: Springer.

Dinu, V., Nadkarni, P., & Brandt, C. (2006). Pivoting approaches for bulk extraction of Entity-Attribute-Value data. Computer methods and programs in biomedicine, 82(1), 38–43. doi:10.1016/j.cmpb.2006.02.001

Fagin, R. (1977). Multivalued dependencies and a new normal form for relational databases. ACM Transactions on Database Systems (TODS), 2(3), 262–278.

Farris, P. W., Bendle, N. T., Pfeifer, P. E., & Reibstein, D. J. (2006). Marketing metrics: 50+ metrics every executive should master. Upper Saddle River, NJ: Pearson Education.

180

Fonseca, P. (2012). Quotas de mercado dos medicamentos genéricos. Diário As Beiras. Retrieved from http://www.asbeiras.pt/2012/07/opiniao-quotas-de-mercado-dos- medicamentos-genericos/

Fórum Estudante (2006). Delegado de Informação Médica. Profissões com Futuro. Retrieved from http://cdp.portodigital.pt/

French, C. D. (1995). “One size fits all” database architectures do not work for DSS. SIGMOD’95 (pp. 449–450). San Jose, CA: ACM.

Golfarelli, M. (2008). DFM as a Conceptual Model for Data Warehouse. Encyclopedia of Data Warehousing and Mining, …, (3), 638–640.

Golfarelli, M., Mandreoli, F., Penzo, W., Rizzi, S., & Turricchia, E. (2012). OLAP query reformulation in peer-to-peer data warehousing. Information Systems, 37(5), 393–411. doi:10.1016/j.is.2011.06.003

Golfarelli, M., Rizzi, S., & Biondi, P. (2011). myOLAP: An Approach to Express and Evaluate OLAP Preferences. IEEE Transactions on Knowledge and Data Engineering, 23(7), 1050–1064. doi:10.1109/TKDE.2010.196

Golumbic, M. C. (2004). Algorithmic graph theory and perfect graphs (2nd ed.). Amsterdam, NL: Elsevier B.V.

Gupta, A., Harinarayan, V., & Quass, D. (1995). Aggregate-Query Processing in Data Warehousing Environments. 21st VLDB Conference. Zurich, CH.

Halpin, T., & Morgan, T. (2008). Information modeling and relational databases (2nd ed.). San Francisco, CA: Morgan Kaufmann Publishers.

Hamel, L., & Hall, T. (2005). A brief tutorial on database queries, data mining, and OLAP. The Encyclopedia of Data Warehousing and Mining, (401).

Han, J., Lakshmanan, L., & Ng, R. (1999). Constraint-based, multidimensional data mining. Computer.

Hannula, M., & Pirttimäki, V. (2003). Business intelligence empirical study on the top 50 Finnish companies. Journal of American Academy of Business, (March).

Harinarayan, V., Rajaraman, A., & Ullman, J. D. (1996). Implementing Data Cubes Efficiently. Proceedings of the ACM-SIGMOD International Conference on Management of Data (pp. 205–216). Montreal, CA.

Hobbs, L., Hillson, S., Lawande, S., & Smith, P. (2005). Oracle Database 10g Data Warehousing. Oxford, UK: Elsevier Digital Press.

Inmon, W. H. (1999). Data Marts and the Data Warehouse: Information Architecture for the Millenium. California: Informix.

181

Inmon, W. H. (2005). Building the data warehouse (4th ed.). Indianapolis, IN: Wiley Publishing.

Inmon, W. H., Strauss, D., & Neushloss, G. (2008). DW 2.0: The Architecture for the Next Generation of Data Warehousing. Burlington, MA: Morgan Kaufman.

Johnston, T., & Weis, R. (2010). Managing time in relational databases: how to design, update and query temporal data. Burlington, MA: Morgan Kaufmann Publishers.

Jourdan, Z., Rainer, R. K., & Marshall, T. E. (2008). Business Intelligence: An Analysis of the Literature. Information Systems Management, 25(2), 121–131. doi:10.1080/10580530801941512

Jovanovic, V., & Bojicic, I. (2012). Conceptual Data Vault Model. SAIS Conference, 131–136.

Jovanovic, V., Bojicic, I., Knowles, C., & Pavlic, M. (2012). Persistent Staging Area Models for Data Warehouses. Issues in Information Systems, 13(1), 121–132.

Kent, W. (1983). A simple guide to five normal forms in relational database theory. Communications of the ACM, 26(2), 120–125.

Kernochan, W. (2011). Why Most Business Intelligence Projects Fail. Enterprise Apps Today. Retrieved November 15, 2012, from http://www.enterpriseappstoday.com/business-intelligence/why-most-business- intelligence-projects-fail-1.html

Kimball, R. (1997). A Dimensional Modeling Manifesto: Drawing the Line Between Dimensional Modeling and ER Modeling Techniques. DBMS and Internet Systems.

Kimball, R., & Caserta, J. (2004). The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning Conforming, and Delivering Data. Wiley. Indianapolis, IN: Wiley Publishing.

Kimball, R., & Ross, M. (2010). The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence. Indianaplois, IN: Wiley Publishing.

Knowles, C. (2012). 6NF Conceptual Models and Data Warehousing 2.0. Proceedings of the Southern Association for Information Systems Conference (pp. 160–165). Atlanta, GA.

Kobielus, J. (2010). What’s Not BI? Oh, Don’t Get Me Started....Oops Too Late...Here Goes.... Retrieved from http://blogs.forrester.com/james_kobielus/10-04-30- what%E2%80%99s_not_bi_oh_don%E2%80%99t_get_me_startedoops_too_lateh ere_goes, April 30, 2010.

182

La-Ongsri, S., Roddick, J. F., & De Vries, D. (2008). Accommodating mesodata into conceptual modelling methodologies. Information and Software Technology, 50(5), 424–435. doi:10.1016/j.infsof.2007.05.001

Larson, B. (2009). Delivering Business Intelligence with Microsoft SQL Server 2008. New York, NY: McGraw-Hill.

Linstedt, D. E. (2001). Patent-Method And System of Data Warehousing. Pat: US 2002/0161778 A1

Linstedt, D. E. (2002). Data Vault Series 1 - Data Vault Overview. The Data Administration Newsletter. Retrieved from http://www.tdan.com/view- articles/5054

Lönnqvist, A., & Pirttimäki, V. (2006). The Measurement of Business Intelligence. Information Systems Management, 23(1), 32–40. doi:10.1201/1078.10580530/45769.23.1.20061201/91770.4

Luhn, H. P. (1957). A preliminary proposal for a business intelligence system. IBM Research Center.

Luhn, H. P. (1958). A business intelligence system. IBM Journal of Research and Development, (October), 314–319.

Malinowski, E. (2010). Improving Expressive Power in Modeling Data Warehouse and OLAP Applications. In P. N. S.-B. Furtado (Ed.), Evolving Application Domains of Data Warehousing and Mining: Trends and Solutions. Hershey, PA: Information Science Reference.

Mateen, A., Raza, B., Sher, M., Awais, M. M., & Hussain, T. (2010). Evolution of autonomic Database Management Systems. 2010 The 2nd International Conference on Computer and Automation Engineering (ICCAE), 1, 33–37. doi:10.1109/ICCAE.2010.5452007

Microsoft. (2012). SQL Server 2012 Tutorials: Analysis Services - Data Mining. Microsoft.

Moody, D. L., & Kortink, M. A. R. (2000). From enterprise models to dimensional models: a methodology for data warehouse and data mart design. Proceedings of the International Workshop on Design and Management of Data Warehouses (DMDW’2000) (Vol. 2000, pp. 1–12).

Nadkarni, P. N., & Brandt, C. (1998). Data extraction and ad hoc query of an entity- attribute-value database. Journal of the American Medical Informatics Association : JAMIA, 5(6), 511–27

Nagabhushana, S. (2006). Data Warehousing Olap And Data Mining. New Delhi: New Age International.

183

Negash, S. (2004). Business Intelligence. Communications of the Association for Information Systems, 13, 177–195.

Negash, S., & Gray, P. (2008). Business Intelligence. In F. Burstein & C. W. Holsapple (Eds.), Handbook on Decision Support Systems 2: Variations. Berlin: Springer- Verlag.

Oracle. (2007). Siebel Life Sciences Guide Version 7.7 Rev. C. Oracle.

Pedersen, T. B., & Jensen, C. S. (2001). Multidimensional database technology. Computer, (December)

Pendse, N. (2008). What is OLAP ? The BI Verdict. Retrieved November 15, 2012, from http://www.bi- verdict.com/fileadmin/dl_temp/0493635e66cd5c7af3f2626b88033c8a/fasmi.htm?u ser_id=

Peukert, E., Eberius, J., & Rahm, E. (2012). A Self-Configuring Schema Matching System. 2012 IEEE 28th International Conference on Data Engineering (pp. 306– 317). Ieee. doi:10.1109/ICDE.2012.21

Ponniah, P. (2001). Data warehousing fundamentals: a comprehensive guide for IT professionals. New York, NY: John Wiley & Sons, Inc.

Ponniah, P. (2007). Data modeling fundamentals: a practical guide for IT professionals. Hoboken, NJ: John Wiley & Sons, Inc.

Power, D.J. (2007). A Brief History of Decision Support Systems. DSSResources.COM, World Wide Web, http://DSSResources.COM/history/dsshistory.html, version 4.0, March 10, 2007.

Rainardi, V. (2008). Building a data warehouse: with examples in SQL Server. New York, NY: Apress.

Raisinghani, M. (Ed.). (2004). Business intelligence in the digital economy: opportunities, limitations and risks. Hershey PA: Idea Group Publishing.

Ramakrishnan, R., & Gehrke, J. (2003). Database management systems (3rd ed.). New York, NY: McGraw-Hill.

Reis, M. F. (2012). Indústria farmacêutica rejeita meta prevista para a redução da despesa em 2013. Retrieved October 10, 2012, from http://www.ionline.pt/dinheiro/industria-rejeita-meta-prevista-reducao-da-despesa- 2013

Rizzi, S., Abelló, A., Lechtenbörger, J., & Trujillo, J. (2006). Research in data warehouse modeling and design: dead or alive? DOLAP’06 9th ACM international workshop on Data warehousing and OLAP (pp. 3–10). New York, NY: ACM.

184

Roddick, J., & De Vries, D. (2006). Reduce, reuse, recycle: practical approaches to schema integration, evolution and versioning. Advances in Conceptual Modeling- Theory and Practice, 4231, 209–216

Rönnbäck, L., & Krumlinde, V. (2012). Anchor Modeler. Retrieved from http://www.anchormodeling.com/modeler/latest/

Rönnbäck, L., Regardt, O., Bergholtz, M., Johannesson, P., & Wohed, P. (2010a). Anchor modeling — Agile information modeling in evolving data environments. Data & Knowledge Engineering, 69(12), 1229–1253. doi:10.1016/j.datak.2010.10.002

Rönnbäck, L., Regardt, O., Bergholtz, M., Johannesson, P., & Wohed, P. (2010b). From Anchor Model to Relational Database. Retrieved from http://www.anchormodeling.com/wp-content/uploads/2010/09/AM-RDB.pdf

Rud, O.P. (2009). Business intelligence success factors: tools for aligning your business in the global economy. Hoboken, NJ: Wiley & Sons.

Sabanovic, A. (2008). Business Intelligence Software: Customers’ Understanding, Expectations and Needs. University of Kristianstad.

Sen, A., & Sinha, A. (2005). A comparison of data warehousing methodologies. Communications of the ACM, 48(3), 79–84.

Silberschatz, A., Korth, H. F., & Sudarshan, S. (2011). Database system concepts (6th ed.). New York, NY: McGraw-Hill.

Simsion, G. C., & Witt, G. C. (2005). Data modeling essentials (3rd ed.). San Francisco, CA: Morgan Kaufmann Publishers.

Sinfic SA. (n.d.). Uma Solução de Inteligência de Negócio para Melhorar a Quota de Mercado. Retrieved November 15, 2012, from http://www.sinfic.pt/SinficWeb/displayconteudo.do2?numero=23855

Speelpenning, J., Daux, P., & Gallus, J. (2001). Data Modeling and Relational Database Design (Vol. 1). Redwood Shores, CA: Oracle Corporation.

Spofford, G., Harinath, S., Webb, C., Huang, D. H., & Civardi, F. (2006). MDX Solutions Second Edition With Microsoft® SQLServerTM Analysis Services 2005 and Hyperion® Essbase (2nd ed.). Indianapolis, IN: Wiley Publishing.

Stephens, R. (2009). Beginning database design solutions. Indianapolis, IN: Wiley Publishing.

Stern, N., & Stern, R. A. (1993). Programação Estruturada em COBOL (6th ed.). Rio de Janeiro, RJ: Editora Guanabara Koogan.

185

Taitslin, M. A. (2011). Comparison of expressive power of some query languages for databases. Proceedings of the Steklov Institute of Mathematics, 274(1), 273–288. doi:10.1134/S0081543811060174

Teorey, T., Lightstone, S., Nadeau, T., & Jagadish, H. V. (2011). Database Modeling and Design (5th ed.). Burlington, MA: Morgan Kaufmann Publishers.

Thomsen, E. (2002). OLAP Solutions: Building Multidimensional Information Systems (2nd ed.). New York, NY: John Wiley & Sons, Inc.

Thomsen, E. (2003). BI’ s Promised Land. Intelligent Enterprise.

Todman, C. (2001). Designing a data warehouse: supporting customer relationship management. Upper Saddle River, NJ: Prentice-Hall.

Turban, E., Sharda, R., Aronson J.E., & King, D. (2007). Business Intelligence: a Managerial Approach. New Jersey: Pearson Education

Vaidya, P., & Lee, J. J. (2011). A Novel Multicontext Coarse-Grained Reconfigurable Architecture (CGRA) For Accelerating Column-Oriented Databases. ACM Transactions on Reconfigurable Technology and Systems, 4(2), 1–30. doi:10.1145/1968502.1968504

Vassiliadis, P., & Sellis, T. (1999). A survey of logical models for OLAP databases. ACM SIGMOD Record, 28(4), 64–69. doi:10.1145/344816.344869

Watson, H. J., & Ariyachandra, T. (2005). Data Warehouse Architectures : Factors in the Selection Decision and the Success of the Architectures. Athens, GA.

Weller, V. (2004). Performance Measurements Exposed. Double Helix Group.

Whitehorn, M., Zare, R., & Pasumansky, M. (2002). Fast track to MDX (2nd ed.). Nottingham, UK: Springer.

186