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
ii
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
DIM 009 CR 004 Linha 1
DIM 106 CR 023 Linha 8
Zona400
Produto 2535
DIM 044 CR 008 Linha 3 NossaEmpresa2
Produto 2542
DIM 084 CR 019 Linha 7
DIM 010
DIM 105
Zona410
DIM 040 CR 007
DIM 117 CR 029
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 117 Zona410 CR 029 Linha 10 NossaEmpresa1 Produto 2337 DIM 116 21
DIM 116 Zona400 CR 027 Linha 10 NossaEmpresa1 Produto 2337 Zona410 2000 DIM 040 13
DIM 044 Zona400 CR 008 Linha 3 NossaEmpresa1 Produto 2337 DIM 044 14
Zona410 DIM 117 26
DIM 009 Zona400 CR 004 Linha 1 NossaEmpresa2 Produto 2535 Produto 2535 Zona400 3300 DIM 009 18
Produto 2542 DIM 084 21
DIM 010 Zona410 CR 004 Linha 1 NossaEmpresa2 Produto 2535 DIM 106 15
Produto 2542 Zona410 7000 DIM 010 9
DIM 084 Zona400 CR 019 Linha 7 NossaEmpresa2 Produto 2535 DIM 084 18
Zona410 Produto 2542 DIM 105 28
DIM 106 Zona400 CR 023 Linha 8 NossaEmpresa2 Produto 2535 Produto 2542 Zona400 670 DIM 009 12
Produto 2542 DIM 084 9
DIM 105 Zona410 CR 023 Linha 8 NossaEmpresa2 Produto 2535 DIM 106 13
Produto 2542 Zona410 1600 DIM 010 28
DIM 084 14
DIM 105 18
TudoNumaTabela
Produto Zona DIM Supervisor Linha Empresa Vendas Visitas
Produto 2337 Zona400 DIM 038 CR 005 Linha 2 NossaEmpresa1 500 17
Produto 2337 Zona400 DIM 044 CR 008 Linha 3 NossaEmpresa1 500 8
Produto 2337 Zona400 DIM 116 CR 027 Linha 10 NossaEmpresa1 500 21
Produto 2337 Zona410 DIM 040 CR 007 Linha 2 NossaEmpresa1 2000 13
Produto 2337 Zona410 DIM 044 CR 008 Linha 3 NossaEmpresa1 2000 14
Produto 2337 Zona410 DIM 117 CR 029 Linha 10 NossaEmpresa1 2000 26
Produto 2535 Zona400 DIM 009 CR 004 Linha 1 NossaEmpresa2 3300 18
Produto 2535 Zona400 DIM 084 CR 019 Linha 7 NossaEmpresa2 3300 21
Produto 2535 Zona400 DIM 106 CR 023 Linha 8 NossaEmpresa2 3300 15
Produto 2535 Zona410 DIM 010 CR 004 Linha 1 NossaEmpresa2 7000 9
Produto 2535 Zona410 DIM 084 CR 019 Linha 7 NossaEmpresa2 7000 18
Produto 2535 Zona410 DIM 105 CR 023 Linha 8 NossaEmpresa2 7000 28
Produto 2542 Zona400 DIM 009 CR 004 Linha 1 NossaEmpresa2 670 12
Produto 2542 Zona400 DIM 084 CR 019 Linha 7 NossaEmpresa2 670 9
Produto 2542 Zona400 DIM 106 CR 023 Linha 8 NossaEmpresa2 670 13
Produto 2542 Zona410 DIM 010 CR 004 Linha 1 NossaEmpresa2 1600 28
Produto 2542 Zona410 DIM 084 CR 019 Linha 7 NossaEmpresa2 1600 14
Produto 2542 Zona410 DIM 105 CR 023 Linha 8 NossaEmpresa2 1600 18
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 038 CR 005 Linha 2 NossaEmpresa1 DIM 009 Zona400 Produto 2542
DIM 117 CR 029 Linha 10 NossaEmpresa1 DIM 010 Zona410 Produto 2535
DIM 116 CR 027 Linha 10 NossaEmpresa1 DIM 010 Zona410 Produto 2542
DIM 044 CR 008 Linha 3 NossaEmpresa1 DIM 038 Zona400 Produto 2337
DIM 009 CR 004 Linha 1 NossaEmpresa2 DIM 040 Zona410 Produto 2337
DIM 010 CR 004 Linha 1 NossaEmpresa2 DIM 044 Zona400 Produto 2337
DIM 084 CR 019 Linha 7 NossaEmpresa2 DIM 044 Zona410 Produto 2337
DIM 106 CR 023 Linha 8 NossaEmpresa2 DIM 084 Zona400 Produto 2535
DIM 105 CR 023 Linha 8 NossaEmpresa2 DIM 084 Zona400 Produto 2542
DIM 084 Zona410 Produto 2535
DIM 084 Zona410 Produto 2542
DIM 105 Zona410 Produto 2535
Visitas DIM 105 Zona410 Produto 2542
Produto Zona DIM Visitas DIM 106 Zona400 Produto 2535
Produto 2337 Zona400 DIM 038 17 DIM 106 Zona400 Produto 2542
Produto 2337 Zona400 DIM 044 8 DIM 116 Zona400 Produto 2337
Produto 2337 Zona400 DIM 116 21 DIM 117 Zona410 Produto 2337
Produto 2337 Zona410 DIM 040 13
Produto 2337 Zona410 DIM 044 14 Produto Zona
Produto 2337 Zona410 DIM 117 26 Produto Zona
Produto 2535 Zona400 DIM 009 18 Produto 2337 Zona400
Produto 2535 Zona400 DIM 084 21 Produto 2535 Zona410
Produto 2535 Zona400 DIM 106 15 Produto 2542
Produto 2535 Zona410 DIM 010 9
Produto 2535 Zona410 DIM 084 18 Vendas
Produto 2535 Zona410 DIM 105 28 Produto Zona Vendas
Produto 2542 Zona400 DIM 009 12 Produto 2337 Zona400 500
Produto 2542 Zona400 DIM 084 9 Produto 2337 Zona410 2000
Produto 2542 Zona400 DIM 106 13 Produto 2535 Zona400 3300
Produto 2542 Zona410 DIM 010 28 Produto 2535 Zona410 7000
Produto 2542 Zona410 DIM 084 14 Produto 2542 Zona400 670
Produto 2542 Zona410 DIM 105 18 Produto 2542 Zona410 1600
Alinhamento
Produto Zona EstruturaOrg
Vendas
Visitas
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 038 CR 005 CR 005 Linha 2 DIM 009 Zona400 Produto 2542
DIM 117 CR 029 CR 029 Linha 10 DIM 010 Zona410 Produto 2535
DIM 116 CR 027 CR 027 Linha 10 DIM 010 Zona410 Produto 2542
DIM 044 CR 008 CR 008 Linha 3 DIM 038 Zona400 Produto 2337
DIM 009 CR 004 CR 004 Linha 1 DIM 040 Zona410 Produto 2337
DIM 010 CR 004 CR 019 Linha 7 DIM 044 Zona400 Produto 2337
DIM 084 CR 019 CR 023 Linha 8 DIM 044 Zona410 Produto 2337
DIM 106 CR 023 DIM 084 Zona400 Produto 2535
DIM 105 CR 023 Linha DIM 084 Zona400 Produto 2542
Linha Empresa DIM 084 Zona410 Produto 2535
Linha 2 NossaEmpresa1 DIM 084 Zona410 Produto 2542
Linha 10 NossaEmpresa1 DIM 105 Zona410 Produto 2535
Visitas Linha 3 NossaEmpresa1 DIM 105 Zona410 Produto 2542
Produto Zona DIM Visitas Linha 1 NossaEmpresa2 DIM 106 Zona400 Produto 2535
Produto 2337 Zona400 DIM 038 17 Linha 7 NossaEmpresa2 DIM 106 Zona400 Produto 2542
Produto 2337 Zona400 DIM 044 8 Linha 8 NossaEmpresa2 DIM 116 Zona400 Produto 2337
Produto 2337 Zona400 DIM 116 21 DIM 117 Zona410 Produto 2337
Produto 2337 Zona410 DIM 040 13
Produto 2337 Zona410 DIM 044 14 Produto Zona
Produto 2337 Zona410 DIM 117 26 Produto Zona
Produto 2535 Zona400 DIM 009 18 Produto 2337 Zona400
Produto 2535 Zona400 DIM 084 21 Produto 2535 Zona410
Produto 2535 Zona400 DIM 106 15 Produto 2542
Produto 2535 Zona410 DIM 010 9
Produto 2535 Zona410 DIM 084 18 Vendas
Produto 2535 Zona410 DIM 105 28 Produto Zona Vendas
Produto 2542 Zona400 DIM 009 12 Produto 2337 Zona400 500
Produto 2542 Zona400 DIM 084 9 Produto 2337 Zona410 2000
Produto 2542 Zona400 DIM 106 13 Produto 2535 Zona400 3300
Produto 2542 Zona410 DIM 010 28 Produto 2535 Zona410 7000
Produto 2542 Zona410 DIM 084 14 Produto 2542 Zona400 670
Produto 2542 Zona410 DIM 105 18 Produto 2542 Zona410 1600
Alinhamento
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 038 CR 005 CR 005 Linha 2 DIM 010 Zona410
DIM 117 CR 029 CR 029 Linha 10 DIM 038 Zona400
DIM 116 CR 027 CR 027 Linha 10 DIM 040 Zona410
DIM 044 CR 008 CR 008 Linha 3 DIM 044 Zona400
DIM 009 CR 004 CR 004 Linha 1 DIM 044 Zona410
DIM 010 CR 004 CR 019 Linha 7 DIM 084 Zona400
DIM 084 CR 019 CR 023 Linha 8 DIM 084 Zona410
DIM 106 CR 023 DIM 105 Zona410
DIM 105 CR 023 Linha DIM 106 Zona400
Linha Empresa DIM 116 Zona400
Linha 2 NossaEmpresa1 DIM 117 Zona410
Linha 10 NossaEmpresa1
Visitas Linha 3 NossaEmpresa1
Produto Zona DIM Visitas Linha 1 NossaEmpresa2
Produto 2337 Zona400 DIM 038 17 Linha 7 NossaEmpresa2
Produto 2337 Zona400 DIM 044 8 Linha 8 NossaEmpresa2
Produto 2337 Zona400 DIM 116 21
Produto 2337 Zona410 DIM 040 13
Produto 2337 Zona410 DIM 044 14 Produto Zona
Produto 2337 Zona410 DIM 117 26 Produto Empresa Zona
Produto 2535 Zona400 DIM 009 18 Produto 2337 NossaEmpresa1 Zona400
Produto 2535 Zona400 DIM 084 21 Produto 2535 NossaEmpresa2 Zona410
Produto 2535 Zona400 DIM 106 15 Produto 2542 NossaEmpresa2
Produto 2535 Zona410 DIM 010 9
Produto 2535 Zona410 DIM 084 18 Empresa Vendas
Produto 2535 Zona410 DIM 105 28 Empresa Produto Zona Vendas
Produto 2542 Zona400 DIM 009 12 NossaEmpresa1 Produto 2337 Zona400 500
Produto 2542 Zona400 DIM 084 9 NossaEmpresa2 Produto 2337 Zona410 2000
Produto 2542 Zona400 DIM 106 13 Produto 2535 Zona400 3300
Produto 2542 Zona410 DIM 010 28 Produto 2535 Zona410 7000
Produto 2542 Zona410 DIM 084 14 Produto 2542 Zona400 670
Produto 2542 Zona410 DIM 105 18 Produto 2542 Zona410 1600
Empresa
Linha
AlinhGeo Supervisor
Produto Zona DIM
Vendas
Visitas
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 038 CR 005 Mar-12 CR 005 Linha 2 Mar-12 DIM 010 Zona410
Mar-12 DIM 117 CR 029 Mar-12 CR 029 Linha 10 Mar-12 DIM 038 Zona400
Mar-12 DIM 116 CR 027 Mar-12 CR 027 Linha 10 Mar-12 DIM 040 Zona410
Mar-12 DIM 044 CR 008 Mar-12 CR 008 Linha 3 Mar-12 DIM 044 Zona400
Mar-12 DIM 009 CR 004 Mar-12 CR 004 Linha 1 Mar-12 DIM 044 Zona410
Mar-12 DIM 010 CR 004 Mar-12 CR 019 Linha 7 Mar-12 DIM 084 Zona400
Mar-12 DIM 084 CR 019 Mar-12 CR 023 Linha 8 Mar-12 DIM 084 Zona410
Mar-12 DIM 106 CR 023 Abr-12 CR 007 Linha 1 Mar-12 DIM 105 Zona410
Mar-12 DIM 105 CR 023 Abr-12 CR 005 Linha 1 Mar-12 DIM 106 Zona400
Abr-12 DIM 040 CR 007 Abr-12 CR 029 Linha 10 Mar-12 DIM 116 Zona400
Abr-12 DIM 038 CR 005 Abr-12 CR 027 Linha 10 Mar-12 DIM 117 Zona410
Abr-12 DIM 117 CR 029 Abr-12 CR 004 Linha 1 Abr-12 DIM 009 Zona400
Abr-12 DIM 116 CR 027 Abr-12 CR 019 Linha 7 Abr-12 DIM 010 Zona410
Abr-12 DIM 044 CR 004 Abr-12 CR 023 Linha 8 Abr-12 DIM 038 Zona400
Abr-12 DIM 009 CR 004 Abr-12 DIM 040 Zona410
Abr-12 DIM 010 CR 004 Linha Abr-12 DIM 044 Zona400
Abr-12 DIM 084 CR 019 Tempo Linha Empresa Abr-12 DIM 084 Zona400
Abr-12 DIM 106 CR 023 Mar-12 Linha 2 NossaEmpresa1 Abr-12 DIM 084 Zona410
Abr-12 DIM 105 CR 023 Mar-12 Linha 10 NossaEmpresa1 Abr-12 DIM 105 Zona410
Mar-12 Linha 3 NossaEmpresa1 Abr-12 DIM 106 Zona400
Mar-12 Linha 1 NossaEmpresa2 Abr-12 DIM 116 Zona400
Mar-12 Linha 7 NossaEmpresa2 Abr-12 DIM 117 Zona410
Visitas Mar-12 Linha 8 NossaEmpresa2
Tempo Produto Zona DIM Visitas Abr-12 Linha 10 NossaEmpresa1 Zona
Mar-12 Produto 2337 Zona400 DIM 038 17 Abr-12 Linha 1 NossaEmpresa2 Tempo Zona Tempo
Mar-12 Produto 2337 Zona400 DIM 044 8 Abr-12 Linha 7 NossaEmpresa2 Mar-12 Zona400 Tempo
Mar-12 Produto 2337 Zona400 DIM 116 21 Abr-12 Linha 8 NossaEmpresa2 Mar-12 Zona410 Mar-12
Mar-12 Produto 2337 Zona410 DIM 040 13 Abr-12 Zona400 Abr-12
Mar-12 Produto 2337 Zona410 DIM 044 14 Produto Abr-12 Zona410
Mar-12 Produto 2337 Zona410 DIM 117 26 Tempo Produto Empresa
Mar-12 Produto 2535 Zona400 DIM 009 18 Mar-12 Produto 2337 NossaEmpresa1 Vendas
Mar-12 Produto 2535 Zona400 DIM 084 21 Mar-12 Produto 2535 NossaEmpresa2 Tempo Produto Zona Vendas
Mar-12 Produto 2535 Zona400 DIM 106 15 Mar-12 Produto 2542 NossaEmpresa2 Mar-12 Produto 2337 Zona400 500
Mar-12 Produto 2535 Zona410 DIM 010 9 Abr-12 Produto 2337 NossaEmpresa1 Mar-12 Produto 2337 Zona410 2000
Mar-12 Produto 2535 Zona410 DIM 084 18 Abr-12 Produto 2535 NossaEmpresa2 Mar-12 Produto 2535 Zona400 3300
Mar-12 Produto 2535 Zona410 DIM 105 28 Mar-12 Produto 2535 Zona410 7000
Mar-12 Produto 2542 Zona400 DIM 009 12 Empresa Mar-12 Produto 2542 Zona400 670
Mar-12 Produto 2542 Zona400 DIM 084 9 Tempo Empresa Mar-12 Produto 2542 Zona410 1600
Mar-12 Produto 2542 Zona400 DIM 106 13 Mar-12 NossaEmpresa1 Abr-12 Produto 2337 Zona400 500
Mar-12 Produto 2542 Zona410 DIM 010 28 Mar-12 NossaEmpresa2 Abr-12 Produto 2337 Zona410 2000
Mar-12 Produto 2542 Zona410 DIM 084 14 Abr-12 NossaEmpresa1 Abr-12 Produto 2535 Zona400 3300
Mar-12 Produto 2542 Zona410 DIM 105 18 Abr-12 NossaEmpresa2 Abr-12 Produto 2535 Zona410 7000
Abr-12 Produto 2337 Zona400 DIM 038 17
Abr-12 Produto 2337 Zona400 DIM 044 8
Abr-12 Produto 2337 Zona400 DIM 116 21
Abr-12 Produto 2337 Zona410 DIM 040 13
Abr-12 Produto 2337 Zona410 DIM 117 26
Abr-12 Produto 2535 Zona400 DIM 009 18
Abr-12 Produto 2535 Zona400 DIM 084 21
Abr-12 Produto 2535 Zona400 DIM 106 15
Abr-12 Produto 2535 Zona410 DIM 010 9
Abr-12 Produto 2535 Zona410 DIM 084 18
Abr-12 Produto 2535 Zona410 DIM 105 28
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
DIM 117 CR 029 Linha 10 NossaEmpresa1
DIM 116 CR 027 Linha 10 NossaEmpresa1
DIM 044 CR 008 Linha 3 NossaEmpresa1
DIM 009 CR 004 Linha 1 NossaEmpresa2
DIM 010 CR 004 Linha 1 NossaEmpresa2
DIM 084 CR 019 Linha 7 NossaEmpresa2
DIM 106 CR 023 Linha 8 NossaEmpresa2
DIM 105 CR 023 Linha 8 NossaEmpresa2
Visitas
Tempo Produto Zona DIM Visitas
Mar-12 Produto 2337 Zona400 DIM 038 17
Mar-12 Produto 2337 Zona400 DIM 044 8
Mar-12 Produto 2337 Zona400 DIM 116 21
Mar-12 Produto 2337 Zona410 DIM 040 13
Mar-12 Produto 2337 Zona410 DIM 044 14
Mar-12 Produto 2337 Zona410 DIM 117 26
Mar-12 Produto 2535 Zona400 DIM 009 18
Mar-12 Produto 2535 Zona400 DIM 084 21 Produto Zona
Mar-12 Produto 2535 Zona400 DIM 106 15 Produto Empresa Zona
Mar-12 Produto 2535 Zona410 DIM 010 9 Produto 2337 NossaEmpresa1 Zona400
Mar-12 Produto 2535 Zona410 DIM 084 18 Produto 2535 NossaEmpresa2 Zona410
Mar-12 Produto 2535 Zona410 DIM 105 28 Produto 2542 NossaEmpresa2
Mar-12 Produto 2542 Zona400 DIM 009 12
Mar-12 Produto 2542 Zona400 DIM 084 9
Mar-12 Produto 2542 Zona400 DIM 106 13
Mar-12 Produto 2542 Zona410 DIM 010 28
Mar-12 Produto 2542 Zona410 DIM 084 14
Mar-12 Produto 2542 Zona410 DIM 105 18 Vendas
Abr-12 Produto 2337 Zona400 DIM 038 17 Tempo Produto Zona Vendas
Abr-12 Produto 2337 Zona400 DIM 044 8 Mar-12 Produto 2337 Zona400 500
Abr-12 Produto 2337 Zona400 DIM 116 21 Mar-12 Produto 2337 Zona410 2000
Abr-12 Produto 2337 Zona410 DIM 040 13 Mar-12 Produto 2535 Zona400 3300
Abr-12 Produto 2337 Zona410 DIM 117 26 Mar-12 Produto 2535 Zona410 7000
Abr-12 Produto 2535 Zona400 DIM 009 18 Mar-12 Produto 2542 Zona400 670
Abr-12 Produto 2535 Zona400 DIM 084 21 Mar-12 Produto 2542 Zona410 1600
Abr-12 Produto 2535 Zona400 DIM 106 15 Abr-12 Produto 2337 Zona400 500
Abr-12 Produto 2535 Zona410 DIM 010 9 Abr-12 Produto 2337 Zona410 2000
Abr-12 Produto 2535 Zona410 DIM 084 18 Abr-12 Produto 2535 Zona400 3300
Abr-12 Produto 2535 Zona410 DIM 105 28 Abr-12 Produto 2535 Zona410 7000
Zona Zona
Produto Produto
Tempo Tempo
Visitas Vendas
DIM
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
DIM 117 CR 029 Linha 10 NossaEmpresa1
DIM 116 CR 027 Linha 10 NossaEmpresa1
DIM 044 CR 008 Linha 3 NossaEmpresa1
DIM 009 CR 004 Linha 1 NossaEmpresa2
DIM 010 CR 004 Linha 1 NossaEmpresa2
DIM 084 CR 019 Linha 7 NossaEmpresa2
DIM 106 CR 023 Linha 8 NossaEmpresa2
DIM 105 CR 023 Linha 8 NossaEmpresa2
Visitas
Tempo Produto Zona DIM Visitas Empresa
Mar-12 Produto 2337 Zona400 DIM 038 17 Empresa
Mar-12 Produto 2337 Zona400 DIM 044 8 NossaEmpresa1
Mar-12 Produto 2337 Zona400 DIM 116 21 NossaEmpresa2
Mar-12 Produto 2337 Zona410 DIM 040 13
Mar-12 Produto 2337 Zona410 DIM 044 14
Mar-12 Produto 2337 Zona410 DIM 117 26
Mar-12 Produto 2535 Zona400 DIM 009 18
Mar-12 Produto 2535 Zona400 DIM 084 21 Produto Zona
Mar-12 Produto 2535 Zona400 DIM 106 15 Produto Empresa Zona
Mar-12 Produto 2535 Zona410 DIM 010 9 Produto 2337 NossaEmpresa1 Zona400
Mar-12 Produto 2535 Zona410 DIM 084 18 Produto 2535 NossaEmpresa2 Zona410
Mar-12 Produto 2535 Zona410 DIM 105 28 Produto 2542 NossaEmpresa2
Mar-12 Produto 2542 Zona400 DIM 009 12
Mar-12 Produto 2542 Zona400 DIM 084 9
Mar-12 Produto 2542 Zona400 DIM 106 13
Mar-12 Produto 2542 Zona410 DIM 010 28
Mar-12 Produto 2542 Zona410 DIM 084 14
Mar-12 Produto 2542 Zona410 DIM 105 18 Vendas
Abr-12 Produto 2337 Zona400 DIM 038 17 Tempo Produto Zona Vendas
Abr-12 Produto 2337 Zona400 DIM 044 8 Mar-12 Produto 2337 Zona400 500
Abr-12 Produto 2337 Zona400 DIM 116 21 Mar-12 Produto 2337 Zona410 2000
Abr-12 Produto 2337 Zona410 DIM 040 13 Mar-12 Produto 2535 Zona400 3300
Abr-12 Produto 2337 Zona410 DIM 117 26 Mar-12 Produto 2535 Zona410 7000
Abr-12 Produto 2535 Zona400 DIM 009 18 Mar-12 Produto 2542 Zona400 670
Abr-12 Produto 2535 Zona400 DIM 084 21 Mar-12 Produto 2542 Zona410 1600
Abr-12 Produto 2535 Zona400 DIM 106 15 Abr-12 Produto 2337 Zona400 500
Abr-12 Produto 2535 Zona410 DIM 010 9 Abr-12 Produto 2337 Zona410 2000
Abr-12 Produto 2535 Zona410 DIM 084 18 Abr-12 Produto 2535 Zona400 3300
Abr-12 Produto 2535 Zona410 DIM 105 28 Abr-12 Produto 2535 Zona410 7000
Zona Zona
Produto Produto
Tempo Tempo
Empresa
Visitas Vendas
DIM
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 116 CR 027 CR 027 Linha 10
DIM 044 CR 008 CR 008 Linha 3
DIM 009 CR 004 CR 004 Linha 1
DIM 010 CR 004 CR 019 Linha 7
DIM 084 CR 019 CR 023 Linha 8
DIM 106 CR 023
DIM 105 CR 023
Visitas Linha
Tempo Produto Zona DIM Visitas Linha Empresa
Mar-12 Produto 2337 Zona400 DIM 038 17 Linha 2 NossaEmpresa1
Mar-12 Produto 2337 Zona400 DIM 044 8 Linha 10 NossaEmpresa1
Mar-12 Produto 2337 Zona400 DIM 116 21 Linha 3 NossaEmpresa1
Mar-12 Produto 2337 Zona410 DIM 040 13 Linha 1 NossaEmpresa2
Mar-12 Produto 2337 Zona410 DIM 044 14 Linha 7 NossaEmpresa2
Mar-12 Produto 2337 Zona410 DIM 117 26 Linha 8 NossaEmpresa2
Mar-12 Produto 2535 Zona400 DIM 009 18
Mar-12 Produto 2535 Zona400 DIM 084 21
Mar-12 Produto 2535 Zona400 DIM 106 15 Produto Zona
Mar-12 Produto 2535 Zona410 DIM 010 9 Produto Empresa Zona
Mar-12 Produto 2535 Zona410 DIM 084 18 Produto 2337 NossaEmpresa1 Zona400
Mar-12 Produto 2535 Zona410 DIM 105 28 Produto 2535 NossaEmpresa2 Zona410
Mar-12 Produto 2542 Zona400 DIM 009 12 Produto 2542 NossaEmpresa2
Mar-12 Produto 2542 Zona400 DIM 084 9
Mar-12 Produto 2542 Zona400 DIM 106 13
Mar-12 Produto 2542 Zona410 DIM 010 28
Mar-12 Produto 2542 Zona410 DIM 084 14
Mar-12 Produto 2542 Zona410 DIM 105 18 Empresa Vendas
Abr-12 Produto 2337 Zona400 DIM 038 17 Empresa Tempo Produto Zona Vendas
Abr-12 Produto 2337 Zona400 DIM 044 8 NossaEmpresa1 Mar-12 Produto 2337 Zona400 500
Abr-12 Produto 2337 Zona400 DIM 116 21 NossaEmpresa2 Mar-12 Produto 2337 Zona410 2000
Abr-12 Produto 2337 Zona410 DIM 040 13 Mar-12 Produto 2535 Zona400 3300
Abr-12 Produto 2337 Zona410 DIM 117 26 Mar-12 Produto 2535 Zona410 7000
Abr-12 Produto 2535 Zona400 DIM 009 18 Mar-12 Produto 2542 Zona400 670
Abr-12 Produto 2535 Zona400 DIM 084 21 Mar-12 Produto 2542 Zona410 1600
Abr-12 Produto 2535 Zona400 DIM 106 15 Abr-12 Produto 2337 Zona400 500
Abr-12 Produto 2535 Zona410 DIM 010 9 Abr-12 Produto 2337 Zona410 2000
Abr-12 Produto 2535 Zona410 DIM 084 18 Abr-12 Produto 2535 Zona400 3300
Abr-12 Produto 2535 Zona410 DIM 105 28 Abr-12 Produto 2535 Zona410 7000
Empresa
Zona Zona Empresa
Linha
Produto Produto
Tempo Tempo
Supervisor
Visitas Vendas
DIM
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 038 Empresa NossaEmpresa1 DIM 009 Zona400 Produto 2542
DIM 117 Empresa NossaEmpresa1 DIM 010 Zona410 Produto 2535
DIM 116 Empresa NossaEmpresa1 DIM 010 Zona410 Produto 2542
DIM 044 Empresa NossaEmpresa1 DIM 038 Zona400 Produto 2337
DIM 009 Empresa NossaEmpresa2 DIM 040 Zona410 Produto 2337
DIM 010 Empresa NossaEmpresa2 DIM 044 Zona400 Produto 2337
DIM 084 Empresa NossaEmpresa2 DIM 044 Zona410 Produto 2337
DIM 106 Empresa NossaEmpresa2 DIM 084 Zona400 Produto 2535
DIM 105 Empresa NossaEmpresa2 DIM 084 Zona400 Produto 2542
DIM 040 Linha Linha 2 DIM 084 Zona410 Produto 2535
DIM 038 Linha Linha 2 DIM 084 Zona410 Produto 2542
DIM 117 Linha Linha 10 DIM 105 Zona410 Produto 2535
DIM 116 Linha Linha 10 DIM 105 Zona410 Produto 2542
DIM 044 Linha Linha 3 DIM 106 Zona400 Produto 2535
DIM 009 Linha Linha 1 DIM 106 Zona400 Produto 2542
DIM 010 Linha Linha 1 DIM 116 Zona400 Produto 2337
DIM 084 Linha Linha 7 DIM 117 Zona410 Produto 2337
DIM 106 Linha Linha 8
DIM 105 Linha Linha 8
DIM 040 Supervisor CR 007 Produto Zona
DIM 038 Supervisor CR 005 Produto Zona
DIM 117 Supervisor CR 029 Produto 2337 Zona400
DIM 116 Supervisor CR 027 Produto 2535 Zona410
DIM 044 Supervisor CR 008 Produto 2542
DIM 009 Supervisor CR 004
DIM 010 Supervisor CR 004
DIM 084 Supervisor CR 019
DIM 106 Supervisor CR 023
DIM 105 Supervisor CR 023
Visitas Vendas
Produto Zona DIM Visitas Produto Zona Vendas
Produto 2337 Zona400 DIM 038 17 Produto 2337 Zona400 500
Produto 2337 Zona400 DIM 044 8 Produto 2337 Zona410 2000
Produto 2337 Zona400 DIM 116 21 Produto 2535 Zona400 3300
Produto 2337 Zona410 DIM 040 13 Produto 2535 Zona410 7000
Produto 2337 Zona410 DIM 044 14 Produto 2542 Zona400 670
Produto 2337 Zona410 DIM 117 26 Produto 2542 Zona410 1600
Produto 2535 Zona400 DIM 009 18
Produto 2535 Zona400 DIM 084 21
Produto 2535 Zona400 DIM 106 15
Produto 2535 Zona410 DIM 010 9
Produto 2535 Zona410 DIM 084 18
Produto 2535 Zona410 DIM 105 28
Produto 2542 Zona400 DIM 009 12
Produto 2542 Zona400 DIM 084 9
Produto 2542 Zona400 DIM 106 13
Produto 2542 Zona410 DIM 010 28
Produto 2542 Zona410 DIM 084 14
Produto 2542 Zona410 DIM 105 18
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
Linha 10 Mar-12 CR 029 Linha 10 VI2535_400_009_41000 18
Linha 2 Mar-12 CR 027 Linha 10 VI2535_400_084_40969 21
Linha 3 Mar-12 CR 008 Linha 3 VI2535_400_084_41000 21
Linha 7 Mar-12 CR 004 Linha 1 VI2535_400_106_40969 15
Linha 8 Mar-12 CR 019 Linha 7 VI2535_400_106_41000 15
Mar-12 CR 023 Linha 8 VI2535_410_010_40969 9
Empresa Abr-12 CR 007 Linha 1 VI2535_410_010_41000 9
Empresa Abr-12 CR 005 Linha 1 VI2535_410_084_40969 18
NossaEmpresa1 Abr-12 CR 029 Linha 10 VI2535_410_084_41000 18
NossaEmpresa2 Abr-12 CR 027 Linha 10 VI2535_410_105_40969 28
Abr-12 CR 004 Linha 1 VI2535_410_105_41000 28
Produto Abr-12 CR 019 Linha 7 VI2542_400_009_40969 12
Produto Abr-12 CR 023 Linha 8 VI2542_400_084_40969 9
Produto 2337 VI2542_400_106_40969 13
Produto 2535 Linha->Empresa VI2542_410_010_40969 28
Produto 2542 Tempo Linha Empresa VI2542_410_084_40969 14
Mar-12 Linha 2 NossaEmpresa1 VI2542_410_105_40969 18
Zona Mar-12 Linha 10 NossaEmpresa1
Zona Mar-12 Linha 3 NossaEmpresa1 Historized Tie (3D)
Zona400 Mar-12 Linha 1 NossaEmpresa2 CoordenadasVendas
Zona410 Mar-12 Linha 7 NossaEmpresa2 Tempo Venda_ID Produto Zona
Mar-12 Linha 8 NossaEmpresa2 Mar-12 VI2337_400_40969 Produto 2337 Zona400
Vendas Abr-12 Linha 10 NossaEmpresa1 Mar-12 VI2337_410_40969 Produto 2337 Zona410
Venda_ID 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
VI2337_400_044_40969 Mar-12 DIM 010 Zona410 Mar-12 VI2337_410_044_40969Produto 2337 Zona410 DIM 044
VI2337_400_044_41000 Mar-12 DIM 038 Zona400 Mar-12 VI2337_410_117_40969Produto 2337 Zona410 DIM 117
VI2337_400_116_40969 Mar-12 DIM 040 Zona410 Mar-12 VI2535_400_009_40969Produto 2535 Zona400 DIM 009
VI2337_400_116_41000 Mar-12 DIM 044 Zona400 Mar-12 VI2535_400_084_40969Produto 2535 Zona400 DIM 084
VI2337_410_040_40969 Mar-12 DIM 044 Zona410 Mar-12 VI2535_400_106_40969Produto 2535 Zona400 DIM 106
VI2337_410_040_41000 Mar-12 DIM 084 Zona400 Mar-12 VI2535_410_010_40969Produto 2535 Zona410 DIM 010
VI2337_410_044_40969 Mar-12 DIM 084 Zona410 Mar-12 VI2535_410_084_40969Produto 2535 Zona410 DIM 084
VI2337_410_117_40969 Mar-12 DIM 105 Zona410 Mar-12 VI2535_410_105_40969Produto 2535 Zona410 DIM 105
VI2337_410_117_41000 Mar-12 DIM 106 Zona400 Mar-12 VI2542_400_009_40969Produto 2542 Zona400 DIM 009
VI2535_400_009_40969 Mar-12 DIM 116 Zona400 Mar-12 VI2542_400_084_40969Produto 2542 Zona400 DIM 084
VI2535_400_009_41000 Mar-12 DIM 117 Zona410 Mar-12 VI2542_400_106_40969Produto 2542 Zona400 DIM 106
VI2535_400_084_40969 Abr-12 DIM 009 Zona400 Mar-12 VI2542_410_010_40969Produto 2542 Zona410 DIM 010
VI2535_400_084_41000 Abr-12 DIM 010 Zona410 Mar-12 VI2542_410_084_40969Produto 2542 Zona410 DIM 084
VI2535_400_106_40969 Abr-12 DIM 038 Zona400 Mar-12 VI2542_410_105_40969Produto 2542 Zona410 DIM 105
VI2535_400_106_41000 Abr-12 DIM 040 Zona410 Abr-12 VI2337_400_038_41000Produto 2337 Zona400 DIM 038
VI2535_410_010_40969 Abr-12 DIM 044 Zona400 Abr-12 VI2337_400_044_41000Produto 2337 Zona400 DIM 044
VI2535_410_010_41000 Abr-12 DIM 084 Zona400 Abr-12 VI2337_400_116_41000Produto 2337 Zona400 DIM 116
VI2535_410_084_40969 Abr-12 DIM 084 Zona410 Abr-12 VI2337_410_040_41000Produto 2337 Zona410 DIM 040
VI2535_410_084_41000 Abr-12 DIM 105 Zona410 Abr-12 VI2337_410_117_41000Produto 2337 Zona410 DIM 117
VI2535_410_105_40969 Abr-12 DIM 106 Zona400 Abr-12 VI2535_400_009_41000Produto 2535 Zona400 DIM 009
VI2535_410_105_41000 Abr-12 DIM 116 Zona400 Abr-12 VI2535_400_084_41000Produto 2535 Zona400 DIM 084
VI2542_400_009_40969 Abr-12 DIM 117 Zona410 Abr-12 VI2535_400_106_41000Produto 2535 Zona400 DIM 106
VI2542_400_084_40969 Abr-12 VI2535_410_010_41000Produto 2535 Zona410 DIM 010
VI2542_400_106_40969 Abr-12 VI2535_410_084_41000Produto 2535 Zona410 DIM 084
VI2542_410_010_40969 Abr-12 VI2535_410_105_41000Produto 2535 Zona410 DIM 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:
- 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
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:
- Nível: ………………………………………………………Conjunto de Produtos
- Instância: ………………………………………………………………………..Tudo
Geografia:
- Nível: ………………………………………………………………………………….DIM
- Instância: ………………………………………………………………………….Tudo
Nível de Detalhe de Produto: …………………………………………………………..Produto
Nível de Mercado de Referência: ………………………………………………………………DCI
Tabela 4. Parâmetros de criação do cubo de teste6
Esta melhoria é conseguida obviamente em troca duma maior ocupação de
espaço em disco, pois passa a existir uma tabela adicional com informação
redundante7.
Neste momento dispomos duma implementação típica para uma aplicação que
disponibiliza dashboards do género do que estamos a testar: em SQL no modelo
relacional (com tabelas de estrutura normalizadas e associadas entre si), optimizada
pela utilização de chaves indexadas desfragmentadas e por uma pré-agregação
deliberadamente desnormalizada mas também indexada, que se traduz num
desempenho muito satisfatório, com consultas a rondar os zero segundos.
6 A escolha de Tudo em todas as selecções implicaria o pré-cálculo de todas as combinações
possíveis, se tal fosse viável. 7 Por neste caso se ter criado um cubo muito delimitado, a comparação efectiva de tamanho da
base de dados antes e depois da criação do cubo não é relevante para aferir da implicação real desta opção .
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 2 Linha 2 SBU A
Linha 3 Linha 3 SBU A
Linha 4 Linha 4 SBU A
Linha 5 Linha 5 SBU A
Linha 6 Linha 6 SBU B
Linha 7 Linha 7 SBU B
Linha 8 Linha 8 SBU B
Linha 9 Linha 9 SBU C
Linha 10 Linha 10 SBU C
Linha 11 Linha 11 SBU C
SBU A
SBU B
SBU C
Nó Associação
Linha 1 Linha 1 SBU A
Linha 2 Linha 2 SBU A
Linha 3 Linha 3 SBU A
Linha 4 Linha 4 SBU A
Linha 5 Linha 5 SBU A
Linha 6 Linha 6 SBU B
Linha 7 Linha 7 SBU B
Linha 8 Linha 8 SBU B
Linha 9 Linha 9 SBU C
Linha 10 Linha 10 SBU C
Linha 11 Linha 11 SBU C
SBU A Linha 1 Linha
SBU B Linha 2 Linha
SBU C Linha 3 Linha
Linha Linha 4 Linha
SBU Linha 5 Linha
Linha 6 Linha
Linha 7 Linha
Linha 8 Linha
Linha 9 Linha
Linha 10 Linha
Linha 11 Linha
SBU A SBU
SBU B SBU
SBU C SBU
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
Empresa2 Linha 2 SBU A
Empresa3 Linha 3 SBU A
Linha 4 SBU A
Linha 5 SBU A
Linha 6 SBU B
Linha 7 SBU B
Linha 8 SBU B
Linha 9 SBU C
Linha 10 SBU C
Linha 11 SBU C
Linha 1 Empresa2
Linha 2 Empresa1
Linha 3 Empresa1
Linha 4 Empresa3
Linha 5 Empresa3
Linha 6 Empresa3
Linha 7 Empresa2
Linha 8 Empresa2
Linha 9 Empresa3
Linha 10 Empresa1
Linha 11 Empresa3
SBU Empresa
Linha
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 2 Linha Linha 2 SBU SBU A
Linha Linha 3 Linha Linha 3 SBU SBU A
Linha Linha 4 Linha Linha 4 SBU SBU A
Linha Linha 5 Linha Linha 5 SBU SBU A
Linha Linha 6 Linha Linha 6 SBU SBU B
Linha Linha 7 Linha Linha 7 SBU SBU B
Linha Linha 8 Linha Linha 8 SBU SBU B
Linha Linha 9 Linha Linha 9 SBU SBU C
Linha Linha 10 Linha Linha 10 SBU SBU C
Linha Linha 11 Linha Linha 11 SBU SBU C
SBU SBU A Linha Linha 1 Empresa Empresa2
SBU SBU B Linha Linha 2 Empresa Empresa1
SBU SBU C Linha Linha 3 Empresa Empresa1
Empresa Empresa1 Linha Linha 4 Empresa Empresa3
Empresa Empresa2 Linha Linha 5 Empresa Empresa3
Empresa Empresa3 Linha Linha 6 Empresa Empresa3
Linha Linha 7 Empresa Empresa2
Linha Linha 8 Empresa Empresa2
Linha Linha 9 Empresa Empresa3
Linha Linha 10 Empresa Empresa1
Linha Linha 11 Empresa Empresa3
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
Mar-12 DIM DIM 038 Mar-12 DIM DIM 038 Supervisor CR 005
Mar-12 DIM DIM 117 Mar-12 DIM DIM 117 Supervisor CR 029
Mar-12 DIM DIM 116 Mar-12 DIM DIM 116 Supervisor CR 027
Mar-12 DIM DIM 044 Mar-12 DIM DIM 044 Supervisor CR 008
Mar-12 DIM DIM 009 Mar-12 DIM DIM 009 Supervisor CR 004
Mar-12 DIM DIM 010 Mar-12 DIM DIM 010 Supervisor CR 004
Mar-12 DIM DIM 084 Mar-12 DIM DIM 084 Supervisor CR 019
Mar-12 DIM DIM 106 Mar-12 DIM DIM 106 Supervisor CR 023
Mar-12 DIM DIM 105 Mar-12 DIM DIM 105 Supervisor CR 023
Abr-12 DIM DIM 040 Abr-12 DIM DIM 040 Supervisor CR 007
Abr-12 DIM DIM 038 Abr-12 DIM DIM 038 Supervisor CR 005
Abr-12 DIM DIM 117 Abr-12 DIM DIM 117 Supervisor CR 029
Abr-12 DIM DIM 116 Abr-12 DIM DIM 116 Supervisor CR 027
Abr-12 DIM DIM 044 Abr-12 DIM DIM 044 Supervisor CR 004
Abr-12 DIM DIM 009 Abr-12 DIM DIM 009 Supervisor CR 004
Abr-12 DIM DIM 010 Abr-12 DIM DIM 010 Supervisor CR 004
Abr-12 DIM DIM 084 Abr-12 DIM DIM 084 Supervisor CR 019
Abr-12 DIM DIM 106 Abr-12 DIM DIM 106 Supervisor CR 023
Abr-12 DIM DIM 105 Abr-12 DIM DIM 105 Supervisor CR 023
Mar-12 Supervisor CR 007 Mar-12 Supervisor CR 007 Linha Linha 2
Mar-12 Supervisor CR 005 Mar-12 Supervisor CR 005 Linha Linha 2
Mar-12 Supervisor CR 029 Mar-12 Supervisor CR 029 Linha Linha 10
Mar-12 Supervisor CR 027 Mar-12 Supervisor CR 027 Linha Linha 10
Mar-12 Supervisor CR 008 Mar-12 Supervisor CR 008 Linha Linha 3
Mar-12 Supervisor CR 004 Mar-12 Supervisor CR 004 Linha Linha 1
Mar-12 Supervisor CR 019 Mar-12 Supervisor CR 019 Linha Linha 7
Mar-12 Supervisor CR 023 Mar-12 Supervisor CR 023 Linha Linha 8
Abr-12 Supervisor CR 007 Abr-12 Supervisor CR 007 Linha Linha 1
Abr-12 Supervisor CR 005 Abr-12 Supervisor CR 005 Linha Linha 1
Abr-12 Supervisor CR 029 Abr-12 Supervisor CR 029 Linha Linha 10
Abr-12 Supervisor CR 027 Abr-12 Supervisor CR 027 Linha Linha 10
Abr-12 Supervisor CR 004 Abr-12 Supervisor CR 004 Linha Linha 1
Abr-12 Supervisor CR 019 Abr-12 Supervisor CR 019 Linha Linha 7
Abr-12 Supervisor CR 023 Abr-12 Supervisor CR 023 Linha Linha 8
Mar-12 Linha Linha 2 Mar-12 Linha Linha 2 Empresa NossaEmpresa1
Mar-12 Linha Linha 10 Mar-12 Linha Linha 10 Empresa NossaEmpresa1
Mar-12 Linha Linha 3 Mar-12 Linha Linha 3 Empresa NossaEmpresa1
Mar-12 Linha Linha 1 Mar-12 Linha Linha 1 Empresa NossaEmpresa2
Mar-12 Linha Linha 7 Mar-12 Linha Linha 7 Empresa NossaEmpresa2
Mar-12 Linha Linha 8 Mar-12 Linha Linha 8 Empresa NossaEmpresa2
Abr-12 Linha Linha 10 Abr-12 Linha Linha 10 Empresa NossaEmpresa1
Abr-12 Linha Linha 1 Abr-12 Linha Linha 1 Empresa NossaEmpresa2
Abr-12 Linha Linha 7 Abr-12 Linha Linha 7 Empresa NossaEmpresa2
Abr-12 Linha Linha 8 Abr-12 Linha Linha 8 Empresa NossaEmpresa2
Mar-12 Empresa NossaEmpresa1 Mar-12 Produto Produto 2337 Empresa NossaEmpresa1
Mar-12 Empresa NossaEmpresa2 Mar-12 Produto Produto 2535 Empresa NossaEmpresa2
Abr-12 Empresa NossaEmpresa1 Mar-12 Produto Produto 2542 Empresa NossaEmpresa2
Abr-12 Empresa NossaEmpresa2 Abr-12 Produto Produto 2337 Empresa NossaEmpresa1
Mar-12 Zona Zona400 Abr-12 Produto Produto 2535 Empresa NossaEmpresa2
Mar-12 Zona Zona410 Mar-12 DIM DIM 009 Zona Zona400
Abr-12 Zona Zona400 Mar-12 DIM DIM 010 Zona Zona410
Abr-12 Zona Zona410 Mar-12 DIM DIM 038 Zona Zona400
Mar-12 Produto Produto 2337 Mar-12 DIM DIM 040 Zona Zona410
Mar-12 Produto Produto 2535 Mar-12 DIM DIM 044 Zona Zona400
Mar-12 Produto Produto 2542 Mar-12 DIM DIM 044 Zona Zona410
Abr-12 Produto Produto 2337 Mar-12 DIM DIM 084 Zona Zona400
Abr-12 Produto Produto 2535 Mar-12 DIM DIM 084 Zona Zona410
Mar-12 DIM DIM 105 Zona Zona410
Mar-12 DIM DIM 106 Zona Zona400
Mar-12 DIM DIM 116 Zona Zona400
Mar-12 DIM DIM 117 Zona Zona410
Abr-12 DIM DIM 009 Zona Zona400
Abr-12 DIM DIM 010 Zona Zona410
Abr-12 DIM DIM 038 Zona Zona400
Abr-12 DIM DIM 040 Zona Zona410
Abr-12 DIM DIM 044 Zona Zona400
Abr-12 DIM DIM 084 Zona Zona400
Abr-12 DIM DIM 084 Zona Zona410
Abr-12 DIM DIM 105 Zona Zona410
Abr-12 DIM DIM 106 Zona Zona400
Abr-12 DIM DIM 116 Zona Zona400
Abr-12 DIM DIM 117 Zona Zona410
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.
4.7.3. Consulta de dados
Apenas é necessáro agora alterar o algoritmo da consulta para conseguir
referenciar as “tabelas” no novo formato, e testar o resultado.
É essencialmente a camada inferior da consulta que necessita ser convertida,
pois agora o acesso não se faz através das várias tabelas de entidades, mas através da
única tabela Tables, a Figura 39 substituindo a Figura 24. O script completo da consulta
redesenhada encontra-se no Apêndice 8.
Correndo a nova consulta, com os mesmos parâmetros utilizados anteriormente
sobre o modelo relacional (Tabela 3), obtêm-se os mesmos registos, mas agora a uma
média de 19,789 segundos, ou seja cerca de 10 vezes mais lentamente.
Logo, depreende-se que a utilização de uma única tabela na mesma consulta,
simulando várias tabelas relacionando-se entre si, implica radicalmente uma
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
Mar-12 Visitas Produto Produto 2337 Zona Zona410 DIM DIM 040 13 Mar-12 P2337Z410D040 Visitas 13 P2337Z400D044 Produto Produto 2337
Mar-12 Visitas Produto Produto 2337 Zona Zona410 DIM DIM 044 14 Mar-12 P2337Z410D044 Visitas 14 P2337Z400D044 Zona Zona400
Mar-12 Visitas Produto Produto 2337 Zona Zona410 DIM DIM 117 26 Mar-12 P2337Z410D117 Visitas 26 P2337Z400D044 DIM DIM 044
Mar-12 Visitas Produto Produto 2535 Zona Zona400 DIM DIM 009 18 Mar-12 P2535Z400D009 Visitas 18 P2337Z400D116 Produto Produto 2337
Mar-12 Visitas Produto Produto 2535 Zona Zona400 DIM DIM 084 21 Mar-12 P2535Z400D084 Visitas 21 P2337Z400D116 Zona Zona400
Mar-12 Visitas Produto Produto 2535 Zona Zona400 DIM DIM 106 15 Mar-12 P2535Z400D106 Visitas 15 P2337Z400D116 DIM DIM 116
Mar-12 Visitas Produto Produto 2535 Zona Zona410 DIM DIM 010 9 Mar-12 P2535Z410D010 Visitas 9 P2337Z410D040 Produto Produto 2337
Mar-12 Visitas Produto Produto 2535 Zona Zona410 DIM DIM 084 18 Mar-12 P2535Z410D084 Visitas 18 P2337Z410D040 Zona Zona410
Mar-12 Visitas Produto Produto 2535 Zona Zona410 DIM DIM 105 28 Mar-12 P2535Z410D105 Visitas 28 P2337Z410D040 DIM DIM 040
Mar-12 Visitas Produto Produto 2542 Zona Zona400 DIM DIM 009 12 Mar-12 P2542Z400D009 Visitas 12 P2337Z410D044 Produto Produto 2337
Mar-12 Visitas Produto Produto 2542 Zona Zona400 DIM DIM 084 9 Mar-12 P2542Z400D084 Visitas 9 P2337Z410D044 Zona Zona410
Mar-12 Visitas Produto Produto 2542 Zona Zona400 DIM DIM 106 13 Mar-12 P2542Z400D106 Visitas 13 P2337Z410D044 DIM DIM 044
Mar-12 Visitas Produto Produto 2542 Zona Zona410 DIM DIM 010 28 Mar-12 P2542Z410D010 Visitas 28 P2337Z410D117 Produto Produto 2337
Mar-12 Visitas Produto Produto 2542 Zona Zona410 DIM DIM 084 14 Mar-12 P2542Z410D084 Visitas 14 P2337Z410D117 Zona Zona410
Mar-12 Visitas Produto Produto 2542 Zona Zona410 DIM DIM 105 18 Mar-12 P2542Z410D105 Visitas 18 P2337Z410D117 DIM DIM 117
Abr-12 Visitas Produto Produto 2337 Zona Zona400 DIM DIM 038 17 Abr-12 P2337Z400D038 Visitas 17 P2535Z400D009 Produto Produto 2535
Abr-12 Visitas Produto Produto 2337 Zona Zona400 DIM DIM 044 8 Abr-12 P2337Z400D044 Visitas 8 P2535Z400D009 Zona Zona400
Abr-12 Visitas Produto Produto 2337 Zona Zona400 DIM DIM 116 21 Abr-12 P2337Z400D116 Visitas 21 P2535Z400D009 DIM DIM 009
Abr-12 Visitas Produto Produto 2337 Zona Zona410 DIM DIM 040 13 Abr-12 P2337Z410D040 Visitas 13 P2535Z400D084 Produto Produto 2535
Abr-12 Visitas Produto Produto 2337 Zona Zona410 DIM DIM 117 26 Abr-12 P2337Z410D117 Visitas 26 P2535Z400D084 Zona Zona400
Abr-12 Visitas Produto Produto 2535 Zona Zona400 DIM DIM 009 18 Abr-12 P2535Z400D009 Visitas 18 P2535Z400D084 DIM DIM 084
Abr-12 Visitas Produto Produto 2535 Zona Zona400 DIM DIM 084 21 Abr-12 P2535Z400D084 Visitas 21 P2535Z400D106 Produto Produto 2535
Abr-12 Visitas Produto Produto 2535 Zona Zona400 DIM DIM 106 15 Abr-12 P2535Z400D106 Visitas 15 P2535Z400D106 Zona Zona400
Abr-12 Visitas Produto Produto 2535 Zona Zona410 DIM DIM 010 9 Abr-12 P2535Z410D010 Visitas 9 P2535Z400D106 DIM DIM 106
Abr-12 Visitas Produto Produto 2535 Zona Zona410 DIM DIM 084 18 Abr-12 P2535Z410D084 Visitas 18 P2535Z410D010 Produto Produto 2535
Abr-12 Visitas Produto Produto 2535 Zona Zona410 DIM DIM 105 28 Abr-12 P2535Z410D105 Visitas 28 P2535Z410D010 Zona Zona410
Mar-12 P2337Z400 Vendas 500 P2535Z410D010 DIM DIM 010
Vendas Mar-12 P2337Z410 Vendas 2000 P2535Z410D084 Produto Produto 2535
Tempo Métrica TabelaProd ItemProd TabelaGeo ItemGeo Valor Mar-12 P2535Z400 Vendas 3300 P2535Z410D084 Zona Zona410
Mar-12 Vendas Produto Produto 2337 Zona Zona400 500 Mar-12 P2535Z410 Vendas 7000 P2535Z410D084 DIM DIM 084
Mar-12 Vendas Produto Produto 2337 Zona Zona410 2000 Mar-12 P2542Z400 Vendas 670 P2535Z410D105 Produto Produto 2535
Mar-12 Vendas Produto Produto 2535 Zona Zona400 3300 Mar-12 P2542Z410 Vendas 1600 P2535Z410D105 Zona Zona410
Mar-12 Vendas Produto Produto 2535 Zona Zona410 7000 Abr-12 P2337Z400 Vendas 500 P2535Z410D105 DIM DIM 105
Mar-12 Vendas Produto Produto 2542 Zona Zona400 670 Abr-12 P2337Z410 Vendas 2000 P2542Z400D009 Produto Produto 2542
Mar-12 Vendas Produto Produto 2542 Zona Zona410 1600 Abr-12 P2535Z400 Vendas 3300 P2542Z400D009 Zona Zona400
Abr-12 Vendas Produto Produto 2337 Zona Zona400 500 Abr-12 P2535Z410 Vendas 7000 P2542Z400D009 DIM DIM 009
Abr-12 Vendas Produto Produto 2337 Zona Zona410 2000 P2542Z400D084 Produto Produto 2542
Abr-12 Vendas Produto Produto 2535 Zona Zona400 3300 P2542Z400D084 Zona Zona400
Abr-12 Vendas Produto Produto 2535 Zona Zona410 7000 P2542Z400D084 DIM DIM 084
P2542Z400D106 Produto Produto 2542
P2542Z400D106 Zona Zona400
P2542Z400D106 DIM DIM 106
P2542Z410D010 Produto Produto 2542
P2542Z410D010 Zona Zona410
P2542Z410D010 DIM DIM 010
P2542Z410D084 Produto Produto 2542
P2542Z410D084 Zona Zona410
P2542Z410D084 DIM DIM 084
P2542Z410D105 Produto Produto 2542
P2542Z410D105 Zona Zona410
P2542Z410D105 DIM DIM 105
P2337Z400 Produto Produto 2337
P2337Z400 Zona Zona400
P2337Z410 Produto Produto 2337
P2337Z410 Zona Zona410
P2535Z400 Produto Produto 2535
P2535Z400 Zona Zona400
P2535Z410 Produto Produto 2535
P2535Z410 Zona Zona410
P2542Z400 Produto Produto 2542
P2542Z400 Zona Zona400
P2542Z410 Produto Produto 2542
P2542Z410 Zona Zona410
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+.
4.9.2. Consulta de dados
Novamente é necessário alterar o algoritmo da camada inferior da consulta (a
partir da versão Z_d) para acomodar um novo formato de tabela (Apêndice 12),
passando a consulta a satisfazer plenamente o objectivo da investigação, pois não
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
final3 Recriar cubo 3
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
final3 Recriar cubo 3
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
final3 Recriar cubo 3
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 1161 Produto 1161 894,07 128,9 73,72
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1162 Produto 1162 1068,32 203 2415
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1163 Produto 1163 1086,72 73,14 427,4
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1346 Produto 1346 5127,16 104,8 0
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1465 Produto 1465 37706,1 108,7 108,2
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1470 Produto 1470 88822,2 99,93 124
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1471 Produto 1471 4338,61 121,1 253,4
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1472 Produto 1472 1497,29 69,63 61,98
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1473 Produto 1473 539,79 42,75 372,7
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1474 Produto 1474 3,68 203 0
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1475 Produto 1475 1041,44 76,41 117,8
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1476 Produto 1476 1630,95 76,15 78,42
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1477 Produto 1477 11592 116,2 84,13
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1478 Produto 1478 1017,74 87,64 85,31
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1479 Produto 1479 4087,18 110,7 90,42
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1480 Produto 1480 6645,05 110,5 139,8
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1481 Produto 1481 13981 89,88 144
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1482 Produto 1482 1768,83 80,82 77,3
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1483 Produto 1483 3163,8 105,3 114,3
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1485 Produto 1485 15873,5 75,77 119,3
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1488 Produto 1488 65,95 117,7 3,426
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1489 Produto 1489 6929,98 105,1 253,5
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1490 Produto 1490 6051,75 74,72 149
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1491 Produto 1491 10,48 144,9 1,736
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1492 Produto 1492 8535,83 70,97 127,3
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1493 Produto 1493 10394,1 96,01 180,6
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1494 Produto 1494 3621,7 83,99 250,8
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1497 Produto 1497 70479,6 94,74 96,47
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1498 Produto 1498 643,23 86,16 49,34
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1500 Produto 1500 259,14 196,5 402,9
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1504 Produto 1504 402,35 128,8 125,8
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1505 Produto 1505 1890,52 121,1 127,8
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1603 Produto 1603 45040,4 107,5 92,75
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1604 Produto 1604 67713,9 110,5 84,41
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1606 Produto 1606 10080,9 110,9 148,6
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1608 Produto 1608 9332,42 53,86 71,54
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1609 Produto 1609 10175,2 129,2 142,9
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1610 Produto 1610 28581,3 58,75 76,21
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1611 Produto 1611 1652,13 27,83 197,2
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1613 Produto 1613 6250,89 113,4 190,8
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1614 Produto 1614 31432,5 120,3 48,72
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1615 Produto 1615 16186,1 83,4 123,5
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1616 Produto 1616 3147,65 114,6 23,03
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1617 Produto 1617 8986,32 71,3 100,6
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1618 Produto 1618 10237,6 109,2 64,18
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1619 Produto 1619 43603 105,1 67,93
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1620 Produto 1620 2662,99 63,28 115,5
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1621 Produto 1621 2259,87 76,79 67,15
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 1622 Produto 1622 15805,9 96,54 158,4
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1623 Produto 1623 10013,9 82,6 136,5
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1624 Produto 1624 42813,7 103,7 83,39
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1626 Produto 1626 37725,3 113,8 70,62
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1627 Produto 1627 4724,59 77,15 136,8
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1628 Produto 1628 3038,38 109,6 27,89
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1630 Produto 1630 53156,2 101,1 103,9
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1631 Produto 1631 92160,2 106,5 100,3
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1632 Produto 1632 34832,1 106,5 86,65
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1633 Produto 1633 38358,7 91,64 262,8
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1634 Produto 1634 4670,38 146,2 57,15
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1635 Produto 1635 13252,6 82,7 281,1
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1636 Produto 1636 11730,1 100,9 54,49
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1638 Produto 1638 13409,9 84,73 78,8
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1640 Produto 1640 2098,05 121,9 287,2
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1641 Produto 1641 44057,1 99,1 77,11
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1642 Produto 1642 14568,3 118,7 60,42
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 184 Produto 184 16805,3 98,45 88,01
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 185 Produto 185 18036,3 101,3 87,73
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 1853 Produto 1853 181,74 166,6 0
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2073 Produto 2073 8092,78 108,3 170,8
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2074 Produto 2074 5708,38 142,4 160,6
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 227 Produto 227 40782,2 92,46 106,8
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2318 Produto 2318 1818,33 132,2 0
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2332 Produto 2332 7436,36 108,5 94,51
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2333 Produto 2333 10526,3 108,4 98,67
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2358 Produto 2358 26,88 64 0
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2370 Produto 2370 4517,94 171,8 0
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2496 Produto 2496 50790,1 85,69 0
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2522 Produto 2522 1694,07 83,04 2,445
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2531 Produto 2531 2870,27 187,4 0
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2541 Produto 2541 29,76 203 0
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 2554 Produto 2554 128,48 173,7 0
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 683 Produto 683 8353,06 94,01 111,4
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 774 Produto 774 6239,16 148,6 153,6
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 923 Produto 923 446,12 115,1 2008
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 924 Produto 924 6257,81 140,3 176,6
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 925 Produto 925 8923,18 105,9 147,6
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 926 Produto 926 1756,47 125,4 0
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 928 Produto 928 12210,5 103,7 133,8
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 929 Produto 929 4894,47 122,3 369,3
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 930 Produto 930 14807,1 119,2 218,5
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 931 Produto 931 50893,4 120,5 166,7
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 932 Produto 932 14433,7 126,5 106,4
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 933 Produto 933 5939,74 111,7 117,7
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 935 Produto 935 22692 124,8 125,4
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 936 Produto 936 17297 125,8 143,4
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 937 Produto 937 8404,44 111,3 151,3
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 938 Produto 938 21647,7 110,5 184
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 939 Produto 939 5932,98 116 1082
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 940 Produto 940 17564,4 72,52 130
201203 DIM DIM 042 Conjunto Produtos Conj.Prod. 4 Produto Produto 941 Produto 941 13,09 203 35,02
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
Stored procedure (sp):
o RPT_Dat_Conc_OTF
Funções (Table-Valued) auxiliares:
o RPT_Dat_Conc_MSn
o RPT_Dat_Conc_MSr
o RPT_Dat_Conc_MI
o RPT_Dat_Conc_Evol
USE [Z] GO -- ===================================================================================================== -- Description: Dados de Consulta de Dashboard calculados On-The-Fly nos Modelos Z e Z_d -- Junta MI e Evol calculados por funções, e nome dos elementos-detalhe -- ===================================================================================================== 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,
ChildTableID, ChildTableItemID, ParentTableID, ParentTableItemID)
SELECT TimeItemID, ParentTableID, ParentTableItemID, ChildTableID, ChildTableItemID
FROM Groups AS Groups_1 WHERE (ChildTableID = 'Zona/DIM') AND (ParentTableID = 'Zona') -- Estabelecer ssociações directas redundantes em toda as hierarquias WHILE @counter <> 0 BEGIN SELECT @COUNTER = count(*) FROM (SELECT Groups_3.TimeItemID,
Groups_3.ChildTableID, Groups_3.ChildTableItemID, Groups_1.ParentTableID, Groups_1.ParentTableItemID
FROM Groups AS Groups_3 INNER JOIN Groups AS Groups_1 ON Groups_3.TimeItemID = Groups_1.TimeItemID AND Groups_3.ParentTableID = Groups_1.ChildTableID AND Groups_3.ParentTableItemID =Groups_1.ChildTableItemID) AS nextlevel LEFT OUTER JOIN Groups AS Groups_2 ON nextlevel.TimeItemID = Groups_2.TimeItemID AND nextlevel.ChildTableID = Groups_2.ChildTableID AND nextlevel.ChildTableItemID =Groups_2.ChildTableItemID AND nextlevel.ParentTableID = Groups_2.ParentTableID AND nextlevel.ParentTableItemID=Groups_2.ParentTableItemID WHERE (Groups_2.TimeItemID IS NULL) INSERT INTO Groups (TimeItemID,
ChildTableID, ChildTableItemID, ParentTableID, ParentTableItemID)
SELECT DISTINCT nextlevel.TimeItemID, nextlevel.ChildTableID, nextlevel.ChildTableItemID, nextlevel.ParentTableID, nextlevel.ParentTableItemID
FROM (SELECT Groups_3.TimeItemID,
Groups_3.ChildTableID, Groups_3.ChildTableItemID, Groups_1.ParentTableID, Groups_1.ParentTableItemID
FROM Groups AS Groups_3 INNER JOIN Groups AS Groups_1 ON Groups_3.TimeItemID = Groups_1.TimeItemID AND Groups_3.ParentTableID = Groups_1.ChildTableID AND Groups_3.ParentTableItemID =Groups_1.ChildTableItemID) AS nextlevel LEFT OUTER JOIN Groups AS Groups_2 ON nextlevel.TimeItemID = Groups_2.TimeItemID AND nextlevel.ChildTableID = Groups_2.ChildTableID AND nextlevel.ChildTableItemID =Groups_2.ChildTableItemID AND nextlevel.ParentTableID = Groups_2.ParentTableID AND nextlevel.ParentTableItemID=Groups_2.ParentTableItemID WHERE (Groups_2.TimeItemID IS NULL) END -- Associações cruzadas -- Conjunto Produtos -> DCI INSERT INTO Groups (TimeItemID,
ChildTableID, ChildTableItemID, ParentTableID, ParentTableItemID)
SELECT mixedlevel.TimeItemID, mixedlevel.ChildTableID, mixedlevel.ChildTableItemID, mixedlevel.ParentTableID, mixedlevel.ParentTableItemID
FROM (SELECT DISTINCT Groups.TimeItemID,
Groups.ParentTableID AS ChildTableID, Groups.ParentTableItemID AS ChildTableItemID, Groups_1.ParentTableID, Groups_1.ParentTableItemID
FROM Groups INNER JOIN Groups AS Groups_1
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
Stored procedure (sp):
o RPT_Dat_Conc_OTF – esta camada é igual à do Modelo Z (Apêndice 8)
Funções (Table-Valued) auxiliares:
o RPT_Dat_Conc_MSn
o RPT_Dat_Conc_MSr
o RPT_Dat_Conc_MI – esta camada é igual à do Modelo Z (Apêndice 8)
o RPT_Dat_Conc_Evol – esta camada é igual à do Modelo Z (Apêndice 8)
USE [Z_d] GO -- ===================================================================================================== -- Description: Calcula Market Share Nacional On-The-Fly no Modelo Z_d -- ===================================================================================================== CREATE FUNCTION [dbo].[RPT_Dat_Conc_MSn] ( @TimeItemID_str nvarchar(24)= '201203', -- YYYYMM (estrutura) @TimeItemID nvarchar(24) = '201203', -- YYYYMM @Dim_2_base nvarchar(24) = 'Produto', -- BaseProd @Dim_2_ID nvarchar(24) = 'Conjunto Produtos', -- Filtro 2 (Prod) @Dim_2_ItemID nvarchar(24) = 'Conj.Prod. 4', @Dim_2sub_ID nvarchar(24) = 'Produto', -- Detalhe (Prod) @MetricID nvarchar(24) = 'Euros', @Dim_2_Mkt nvarchar(24) = 'DCI' -- Mercado de Referência ) RETURNS TABLE AS RETURN ( SELECT Facts.TimeItemID,
Dim_2_Filter.ChildTableID Dim_2_ID, Dim_2_Filter.ChildTableItemID Dim_2_ItemID, Dim_2_Detail.ParentTableID AS Dim_2sub_ID,
Dim_2_Detail.ParentTableItemID AS Dim_2sub_ItemID, SUM(Facts.MetricValue) AS Pn,
sum( SUM(Facts.MetricValue) ) over () as Mn, SUM(Facts.MetricValue) /
sum( SUM(Facts.MetricValue) ) over () * 100 as MSn FROM Groups AS Dim_2_Filter INNER JOIN Facts_2D AS Facts INNER JOIN Groups AS Dim_2_Mkt ON Facts.BaseProd = Dim_2_Mkt.ChildTableItemID
ON Dim_2_Filter.ParentTableID = Dim_2_Mkt.ParentTableID AND Dim_2_Filter.ParentTableItemID = Dim_2_Mkt.ParentTableItemID
INNER JOIN Groups AS Dim_2_Detail ON Facts.BaseProd = Dim_2_Detail.ChildTableItemID WHERE (Dim_2_Mkt.ChildTableID = @Dim_2_base) AND (Facts.MetricID = @MetricID) AND (Dim_2_Mkt.ParentTableID = @Dim_2_Mkt) AND (Dim_2_Detail.TimeItemID = @TimeItemID_str) AND (Dim_2_Detail.ChildTableID = @Dim_2_base) GROUP BY Facts.TimeItemID,
Dim_2_Mkt.TimeItemID, Dim_2_Filter.TimeItemID,
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_
(CoordID, TableID, TableItemID)
SELECT distinct 'Produto_' + BaseProd + '+Zona_' + BaseGeo AS CoordID, 'Produto' as tableid, BaseProd as tableitemid
FROM z_d.dbo.Facts_2D go INSERT INTO [Z+].dbo.CoordMap_
(CoordID, TableID, TableItemID)
SELECT distinct 'Produto_' + BaseProd + '+Zona_' + BaseGeo AS CoordID, 'Zona' as tableid, BaseGeo as tableitemid
FROM z_d.dbo.Facts_2D go
7.12. SCRIPT DA CONSULTA ON-THE-FLY DO MODELO Z+
Stored procedure (sp):
o RPT_Dat_Conc_OTF – esta camada é igual à do Modelo Z (Apêndice 8)
Funções (Table-Valued) auxiliares:
o RPT_Dat_Conc_MSn
o RPT_Dat_Conc_MSr
o RPT_Dat_Conc_MI – esta camada é igual à do Modelo Z (Apêndice 8)
o RPT_Dat_Conc_Evol – esta camada é igual à do Modelo Z (Apêndice 8)
USE [Z+] GO -- ===================================================================================================== -- Description: Calcula Market Share Nacional On-The-Fly no Modelo Z+ -- ===================================================================================================== 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.
Communications of the ACM, 26(2), 120–125.
Kernochan, W. (2011). Why Most Business Intelligence Projects Fail. Enterprise Apps
Today. Retrieved November 15, 2012, from
http://www.enterpriseappstoday.com/business-intelligence/why-most-business-
intelligence-projects-fail-1.html
Kimball, R. (1997). A Dimensional Modeling Manifesto: Drawing the Line Between
Dimensional Modeling and ER Modeling Techniques. DBMS and Internet
Systems.
Kimball, R., & Caserta, J. (2004). The Data Warehouse ETL Toolkit: Practical
Techniques for Extracting, Cleaning Conforming, and Delivering Data. Wiley.
Indianapolis, IN: Wiley Publishing.
Kimball, R., & Ross, M. (2010). The Kimball Group Reader: Relentlessly Practical
Tools for Data Warehousing and Business Intelligence. Indianaplois, IN: Wiley
Publishing.
Knowles, C. (2012). 6NF Conceptual Models and Data Warehousing 2.0. Proceedings
of the Southern Association for Information Systems Conference (pp. 160–165).
Atlanta, GA.
Kobielus, J. (2010). What’s Not BI? Oh, Don’t Get Me Started....Oops Too Late...Here
Goes.... Retrieved from http://blogs.forrester.com/james_kobielus/10-04-30-
what%E2%80%99s_not_bi_oh_don%E2%80%99t_get_me_startedoops_too_lateh
ere_goes, April 30, 2010.
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.
Communications of the ACM, 48(3), 79–84.
Silberschatz, A., Korth, H. F., & Sudarshan, S. (2011). Database system concepts (6th
ed.). New York, NY: McGraw-Hill.
Simsion, G. C., & Witt, G. C. (2005). Data modeling essentials (3rd ed.). San
Francisco, CA: Morgan Kaufmann Publishers.
Sinfic SA. (n.d.). Uma Solução de Inteligência de Negócio para Melhorar a Quota de
Mercado. Retrieved November 15, 2012, from
http://www.sinfic.pt/SinficWeb/displayconteudo.do2?numero=23855
Speelpenning, J., Daux, P., & Gallus, J. (2001). Data Modeling and Relational
Database Design (Vol. 1). Redwood Shores, CA: Oracle Corporation.
Spofford, G., Harinath, S., Webb, C., Huang, D. H., & Civardi, F. (2006). MDX
Solutions Second Edition With Microsoft® SQLServerTM
Analysis Services 2005
and Hyperion® Essbase (2nd ed.). Indianapolis, IN: Wiley Publishing.
Stephens, R. (2009). Beginning database design solutions. Indianapolis, IN: Wiley
Publishing.
Stern, N., & Stern, R. A. (1993). Programação Estruturada em COBOL (6th ed.). Rio
de Janeiro, RJ: Editora Guanabara Koogan.
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.
Top Related