Modelo Tese MGI / MEGI - run.unl.pt · do sistema, redesenho e reimplementação do data warehouse,...

MODELO ZeEN

Miguel Nuno da Silva Gomes Rodrigues Gago

Uma abordagem minimalista

para o desenho de data warehouses

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

iii

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

TÍTULO

Nome completo do Candidato

Subtítulo

Dissertação / Trabalho de Projeto / Relatório de

Estágio apresentada(o) como requisito parcial para

obtenção do grau de Mestre em Estatística e Gestão

de Informação

TÍTULO

Nome completo do Candidato

Subtítulo

Dissertação / Trabalho de Projeto / Relatório de Estágio

apresentada(o) como requisito parcial para obtenção do

grau de Mestre em Gestão de Informação

iv

Ao meu Pai, o Engenheiro Armando Rodrigues Gago, que me ensinou

a procurar sempre mais além.

v

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.

vi

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

vii

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

viii

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

ix

Í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

x

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

xi

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

xii

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

xiii

Í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

xiv

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

xv

Í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

xvi

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

17

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

18

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

19

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

20

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

21

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

22

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?

23

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.

24

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;

25

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.

26

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.

27

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)

28

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.

29

2.3. MODELOS DE DADOS1

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).

30

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

31

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

32

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).

33

Figura 2. Modelo hierárquico.

Figura 3. Modelo em rede.

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

Zona Dim Supervisor Linha Empresa Produto

DIM 038 CR 005 Linha 2 NossaEmpresa1 Produto 2337

DIM 116 CR 027 Linha 10



Zona400

Produto 2535

DIM 044 CR 008 Linha 3 NossaEmpresa2

Produto 2542


DIM 010

DIM 105

Zona410

DIM 040 CR 007

DIM 117 CR 029

34

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).

35

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.

36

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.

Figura 5. 1NF.

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 116 Zona400 CR 027 Linha 10 NossaEmpresa1 Produto 2337 Zona410 2000 DIM 040 13


Zona410 DIM 117 26


Produto 2542 DIM 084 21


Produto 2542 Zona410 7000 DIM 010 9


Zona410 Produto 2542 DIM 105 28


Produto 2542 DIM 084 9


Produto 2542 Zona410 1600 DIM 010 28

DIM 084 14

DIM 105 18

TudoNumaTabela

Produto Zona DIM Supervisor Linha Empresa Vendas Visitas

Produto 2337 Zona400 DIM 038 CR 005 Linha 2 NossaEmpresa1 500 17


















37

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.

38

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.

EstruturaOrganizacional Alinhamento

DIM Supervisor Linha Empresa DIM Zona Produto

DIM 040 CR 007 Linha 2 NossaEmpresa1 DIM 009 Zona400 Produto 2535










DIM 084 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 Zona410 DIM 040 13

Produto 2337 Zona410 DIM 044 14 Produto Zona


Produto 2535 Zona400 DIM 009 18 Produto 2337 Zona400


Produto 2535 Zona400 DIM 106 15 Produto 2542


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






Alinhamento

Produto Zona EstruturaOrg

Vendas

Visitas

39

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).

Figura 7. 3NF / BCNF.

DIM Supervisor Alinhamento

DIM Supervisor Supervisor Linha DIM Zona Produto

DIM 040 CR 007 CR 007 Linha 2 DIM 009 Zona400 Produto 2535








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 NossaEmpresa2 DIM 106 Zona400 Produto 2542

Produto 2337 Zona400 DIM 044 8 Linha 8 NossaEmpresa2 DIM 116 Zona400 Produto 2337







Produto 2535 Zona400 DIM 106 15 Produto 2542


Produto 2535 Zona410 DIM 084 18 Vendas

Produto 2535 Zona410 DIM 105 28 Produto Zona Vendas







Alinhamento

2NF Produto Zona EstruturaOrg

Vendas

Visitas

Linha

Alinhamento Supervisor

3NF / BCNF Produto Zona DIM

Vendas

Visitas

Empresa

Linha

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

Produto Zona DIM

Vendas

Visitas

40

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.

41

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.

42

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

DIM Supervisor AlinhGeo

DIM Supervisor Supervisor Linha DIM Zona

DIM 040 CR 007 CR 007 Linha 2 DIM 009 Zona400








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 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 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





Empresa

Linha

AlinhGeo Supervisor

Produto Zona DIM

Vendas

Visitas

43

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.

44

Figura 9. Modelo relacional monotemporal.

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 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 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



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











Tempo

Empresa Linha

AlinhGeo Supervisor

Produto Zona DIM

Vendas

Visitas

45

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”).

46

Figura 10. Modelo dimensional Star.

Figura 11. Modelo dimensional Constellation.

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









Visitas

Tempo Produto Zona DIM Visitas

Mar-12 Produto 2337 Zona400 DIM 038 17







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 105 28 Produto 2542 NossaEmpresa2






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 2535 Zona400 DIM 106 15 Abr-12 Produto 2337 Zona400 500




Zona Zona

Produto Produto

Tempo Tempo

Visitas Vendas

DIM

Zona

Produto

DIM

Tempo

Vendas

Visitas

47

Figura 12. Modelo dimensional Star Cluster.

Figura 13. Modelo dimensional Constellation Cluster.

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









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 2542 Zona410 DIM 105 18 Vendas

Abr-12 Produto 2337 Zona400 DIM 038 17 Tempo Produto Zona Vendas











Zona Zona

Produto Produto

Tempo Tempo

Empresa

Visitas Vendas

DIM

Empresa

Produto Zona

DIM

Tempo

Vendas

Visitas

48

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.

49

Figura 14. Modelo dimensional Snowflake.

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 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 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









Empresa

Zona Zona Empresa

Linha

Produto Produto

Tempo Tempo

Supervisor

Visitas Vendas

DIM

50

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

suportadas

transacções consultas complexas

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)

51

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

52

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).

53

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.

54

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).

55

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.

56

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

57

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,

58

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.

59

Figura 15. Modelo EAV aplicado à entidade DIM a partir da 2NF.

DIM Alinhamento

DIM Atributo Empresa DIM Zona Produto

DIM 040 Empresa NossaEmpresa1 DIM 009 Zona400 Produto 2535










DIM 040 Linha Linha 2 DIM 084 Zona410 Produto 2535








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





Visitas Vendas

Produto Zona DIM Visitas Produto Zona Vendas



















60

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.

61

É 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).

62

Figura 16. Modelo Anchor do exemplo

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

63

Figura 18. Modelo Anchor em tabelas relacionais na 6NF.

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

DIM Tempo DIM Supervisor Venda_ID Euros

DIM 009 Mar-12 DIM 040 CR 007 VI2337_400_40969 500

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






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 Abr-12 Linha 1 NossaEmpresa2 Mar-12 VI2535_400_40969 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

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












VI2535_400_084_40969 Abr-12 DIM 009 Zona400 Mar-12 VI2542_410_010_40969Produto 2542 Zona410 DIM 010



VI2535_400_106_41000 Abr-12 DIM 040 Zona410 Abr-12 VI2337_400_038_41000Produto 2337 Zona400 DIM 038








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 105VI2542_410_084_40969

VI2542_410_105_40969

n:n

Dim

en

sõe

sFa

cto

s

1:n

64

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:

65

- 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.

66

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

67

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

68

- 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.

69

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

70

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.

71

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,

72

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

73

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.

Figura 19. Modelo ER simples.

Grupo Classe Terap.

Empresa DCI

Linha Conjunto Prod.

Merc.Config.

Supervisor Produto

DIM

Região/DIM Visitas

Zona/DIM

Zona Vendas

74

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.

75

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.

76

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.

77

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.

78

Tabela 2. Fórmulas de cálculo do MI e do Evol.

Conceito Definição Cálculo Exemplo

Actual (0)▼

Anterior (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) Regional

% de Vendas do Produto em relação ao 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%

Ml (Market Index) (2 perspectivas)

Índice de Penetração do Produto = MS Regional em relação ao MS Nacional

MI = MSR/MSN x 100 = (VPR/VMR) / (VPN/ VMN) x 100 89 121

= GMS do Produto em relação ao GMS do Mercado

= (VPR/VPN) / (VMR/ VMN) x 100 = 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

Evol (Regional ou Nacional) (2 perspectivas)

Índice de Evolução das Vendas = Crescimento do Produto em relação ao Crescimento do Mercado (do Momento Anterior 1 para o Momento Actual 0)

Evol = GIP / GIM X 100 = (VP0 / VP1) / (VM0 / VM1) x 100 78 106

= Índice de Crescimento da Quota de Mercado (do Momento Anterior 1 para o Momento Actual 0)

= (VP0 / VM0) / (VP1 / VM1) x 100 = MS0 / MS1 x 100 78 106

79

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.

80

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,

81

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.

82

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.

83

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).

84

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

85

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.

86

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.

87

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).

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.

MS regional

MS nacional

88

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

89

É 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:


- 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

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.

Tabela 3. Parâmetros de consulta de teste

90

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

91

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.

92

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

93

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:


- 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 .

94

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.

Tabela 5. Relação Linha Comercial - SBU

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

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

95

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:

Grupo Classe Terap.

SBU Empresa DCI

Linha Conjunto Prod.

Merc.Config.

Supervisor Produto

DIM

Região/DIM Visitas

Zona/DIM

Zona Vendas

96

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')

97

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).

98

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).

99

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).

100

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.

101

Figura 29. Nós e associações no modelo de grafos.

Figura 30. Entidades acrescentadas e associadas como nós.

Nó Associação

Linha 1 Linha 1 SBU A





Linha 6 Linha 6 SBU B



Linha 9 Linha 9 SBU C



SBU A

SBU B

SBU C

Nó Associação












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

102

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).

103

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

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



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

104

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.

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).

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

105

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.

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:

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

106

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.

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).

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 6 Linha Linha 6 SBU SBU B



Linha Linha 9 Linha Linha 9 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



Linha Linha 7 Empresa Empresa2





107

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.

108

Figura 35. Modelo Z - estrutura de dimensões do exemplo da revisão de literatura.

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










Abr-12 DIM DIM 040 Abr-12 DIM DIM 040 Supervisor CR 007










Mar-12 Supervisor CR 007 Mar-12 Supervisor CR 007 Linha Linha 2








Abr-12 Supervisor CR 007 Abr-12 Supervisor CR 007 Linha Linha 1







Mar-12 Linha Linha 2 Mar-12 Linha Linha 2 Empresa NossaEmpresa1






Abr-12 Linha Linha 10 Abr-12 Linha Linha 10 Empresa NossaEmpresa1




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



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




Abr-12 DIM DIM 009 Zona Zona400











109

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.

110

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.

111

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'

112

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.


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

113

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.

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.

MS regional

MS nacional

114

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

Mo

de

lo d

e d

ado

s

115

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,

116

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).

117

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.

MS regional

MS nacional

118

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.

119

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.

120

Figura 42. Modelação genérica de factos – conceito e exemplo.

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
















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









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 DIM DIM 010



P2542Z410D084 DIM DIM 084



P2542Z410D105 DIM DIM 105

P2337Z400 Produto Produto 2337

P2337Z400 Zona Zona400











121

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.

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

Z Z+

122

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).

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


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

MS regional

MS nacional

123

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.

124

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

125

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.

126

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).

127

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.

128

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

129

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+.

130

Figura 48. Anchor model do caso estudado

131

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

132

- 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.

133

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.

Criar tabela 3Alterar consulta

base3 Criar tabela 3

Alterar consulta

base3

Preencher

tabela1

Alterar consulta

base3

Preencher

tabela1

Alterar consulta

base3

Preencher

tabela1

Preencher

tabela1

Preencher

associações1

Preencher

associações1

Criar campo 3 Criar campo 3Reprocessar

cubo2

Criar associação 3 Criar associação 3

Preencher

associações1

Preencher

associações1

Reprocessar

cubo2

Criar tabela de

factos3

Alterar consulta

base3

Criar tabela de

factos3

Alterar consulta

base3 Declarar métrica 1

Alterar consulta

base3 Declarar métrica 1

Alterar consulta

base3

Criar

associações3

Alterar consulta

final3

Criar

associações3

Alterar consulta

final3

Criar tabela de

factos3

Alterar consulta

final3

Criar tabela de

factos3

Alterar consulta

final3

Recriar cubo 3 Recriar cubo 3

Reprocessar

cubo2

Reprocessar

cubo2

Alterar consulta

final3 Recriar cubo 3

Alterar consulta

final3

Alterar consulta


Alterar consulta

final3

Reprocessar

cubo2

Reprocessar

cubo2

Alterar consulta

base3 Recriar cubo 3

Alterar consulta

base3

Declarar métrica

nova1

Alterar consulta

base3

Declarar métrica

nova1

Alterar consulta

base3

Alterar consulta

final3

Reprocessar

cubo2

Alterar consulta

final3

Alterar consulta


Alterar consulta

final3

Reprocessar

cubo2

Estrutura do

cálculo3 3 2 2Depende de tabelas e selecções Depende de tabelas e selecções

38 55 27 44

Consulta DW Consulta DW Consulta

Dimensão nova:

SBU acima da

Linha

Z_c: Z c/ cubo

Evento (métrica)

novo:

Actividade com 4

dimensões:

Org+Geo+Prod+C

anal

Dashboard novo:

Filtro por mais

uma dimensão

(3)

Métrica

calculada nova:

Preço médio =

Valores /

Unidades

Depende de selecções Depende de selecções

Alteração /

Exemplo

R: Relacional R_c: Relacional c/ cubo Z: Z básico

DW DW Consulta

134

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.

Preencher

tabela1

Preencher

tabela1 Recriar cubo 3

Alterar cálculo

métricas3 Criar 2 tabelas 6

Alterar consulta

base3

Preencher

associações1

Preencher

associações1 Criar dimensão 3 Alterar consulta 3

Preencher 2

tabelas2

Reprocessar

associações2

Reprocessar

associações2

Alterar

hierarquia3

Criar tabela

associação3

Reprocessar

cubo2

Preencher

associações1

Declarar métrica

nova1

Alterar consulta

base3

Declarar métrica

nova1

Alterar consulta


Alterar cálculo

métricas3

Criar 2 tabelas

para factos6

Alterar consulta

base3

Criar tabela de

factos3

Alterar consulta

final3 Criar métrica 3 Alterar consulta 3

Criar tabela

asociação3

Alterar consulta

final3

Reprocessar

cubo2

Alterar consulta

final3

Alterar consulta

final3

Alterar cálculo

métricas3

Alterar consulta

final3

Alterar consulta 3

Declarar métrica

nova1

Alterar consulta

base3

Declarar métrica

nova1

Alterar consulta

final3

Reprocessar

cubo2

Alterar cálculo

métricas3

Alterar consulta

base3

Alterar consulta

final3 Alterar consulta 3

Alterar consulta

final3

Estrutura do

cálculo1 0 2 3

R+D=

DW Consulta DW

25

Dimensão nova:

SBU acima da

Linha

Depende de selecções

Z_d: Z c/ associações directas Z+: Z c/ assoc.directas + gener.factos D - Dimensional

Evento (métrica)

novo:

Actividade com 4

dimensões:

Org+Geo+Prod+C

anal

Dashboard novo:

Filtro por mais

uma dimensão

(3)

Métrica

calculada nova:

Preço médio =

Valores /

Unidades

Alteração /

Exemplo

85

DW Consulta Consulta

Depende de selecção de factos Independente

15 47

AM - Anchor model

DW Consulta

Depende de tabelas e selecções

42

135

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+).

136

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

Tabela 9. Ranking dos modelos.

Rel

acio

nal

Rel

acio

nal

c/cu

bo

Z b

ásic

o

Z c/

cub

o

Z c/

ass

oci

açõ

es

dir

ecta

s

Z c/

asso

c.d

irec

tas

+

gen

er.f

acto

s

Dim

ensi

on

al

Rel

acio

nal

+

Dim

ensi

on

al

An

cho

r m

od

el

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

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

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

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

Média Total -0,10 0,67 -0,35 0,21 -0,75 -0,72 0,16 0,88 0,45IMP

LIC

AÇ

ÃO

IMP

LIC

AÇ

ÃO

Z-score

Score

OB

JEC

TIV

OO

BJE

CTI

VO

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

137

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

138

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.

139

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);

140

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.

141

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).

142

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.

143

É 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).

144

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,

145

[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,

146

[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

147

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

148

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

149

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

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 Produto

ON meat.Dim_2sub_ItemID = Produto.ID end GO

150

-- ===================================================================================================== -- 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

151

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

152

-- ===================================================================================================== -- 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

153

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 1477 Produto 1477 11592 116,2 84,13




201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1481 Produto 1481 13981 89,88 144
































154

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 941 Produto 941 13,09 203 35,02

155

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 ')

156

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

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) ) 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

157

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 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 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

158

-- ===================================================================================================== -- 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

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

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

159

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')

160

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

161

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,

162

''''''+@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')

163

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

164

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


o RPT_Dat_Conc_OTF


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 -- ===================================================================================================== 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',

165

@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 -- ===================================================================================================== 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_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

166

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')

167

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] (

168

@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

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

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')

169

AND (ParentTableID = 'Zona/DIM') INSERT INTO Groups (TimeItemID,


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,


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,


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

170

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


o RPT_Dat_Conc_OTF – esta camada é igual à do Modelo Z (Apêndice 8)


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,

171

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 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) AND (Dim_1_Filter.ChildTableID = @Dim_1_base) 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

172

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

173

--Coordenadas Vendas INSERT INTO [Z+].dbo.CoordMap_


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_


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+


o RPT_Dat_Conc_OTF – esta camada é igual à do Modelo Z (Apêndice 8)


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+ -- ===================================================================================================== 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_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

174

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

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) AND (Dim_1_Filter.ChildTableID = @Dim_1_base)

175

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.ParentTableItemID, Dim_2_Detail.ParentTableID

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 ) }

176

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) )

177

GO -- ===================================================================================================== -- 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

178

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).

179

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.

180

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.

181

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.

182

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.


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.

183

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.

184

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.

185

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.


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.

186

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.

Modelo Tese MGI / MEGI - run.unl.pt · do sistema, redesenho e reimplementação do data warehouse,...

Documents

Transcript of Modelo Tese MGI / MEGI - run.unl.pt · do sistema, redesenho e reimplementação do data warehouse,...