You are on page 1of 147

The Many-to-Many

Revolution





ADVANCED DIMENSIONAL MODELING WITH
MICROSOFT SQL SERVER ANALYSIS SERVICES








produced by













!"# %&'()*+)%&'( ,#-+./*0+'
Advanced dlmenslonal modellng wlLh MlcrosofL SCL Server Analysls Servlces

1/*"+23 Marco 8usso, AlberLo lerrarl
4/5.06"#73 verslon 2.0 8evlslon 1 - CcLober 10, 2011
8+'*&9*3 marco.russo@sqlbi.com and alberto.ferrari@sqlbi.com - www.sqlbi.com

:/;;&2(3 1hls paper descrlbes how Lo leverage Lhe many-Lo-many dlmenslon relaLlonshlps, a feaLure LhaL
debuLed avallable wlLh Analysls Servlces 2003 and ls now avallable by uslng uAx ln Lhe new 8lSM 1abular
avallable ln Analysls Servlces uenall". AfLer lnLroduclng Lhe maln concepLs, Lhe paper dlscusses varlous
lmplemenLaLlon Lechnlques ln Lhe form of deslgn paLLerns: for each model, Lhere ls a descrlpLlon of a
buslness scenarlo LhaL could beneflL from Lhe model, followed by an explanaLlon of lLs lmplemenLaLlon.
A separaLe download (avallable on hLLp://www.sqlbl.com/manyLomany.aspx) conLalns SCL Server daLabase
and Analysls Servlces pro[ecLs wlLh Lhe same sample daLa used ln Lhls paper. 8lSM 1abular examples are
avallable as owerlvoL for Lxcel workbooks.

19<'+=.#7>;#'*63 we would llke Lo Lhank Lhe many peer revlewers LhaL helped us Lo lmprove Lhls
documenL: 8ryan 8aLchelder, Chrls Webb, uarren Cosbell, Creg Calloway, !on Axon, Mark Plll, eLer koller,
San[ay nayyar, ScoLL 8arreLL, 1eo Lachev, CranL alsley, !avler Culllen.
l would also llke Lo Lhank 1.k. Anand, Marln 8ezlc, Marlus uumlLru, !effrey Wang, Ashvlnl Sharma and
Akshal Mlrchandanl who answered Lo our quesLlons.
TABLE OF CONTENTS
I NTRODUCTI ON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
MULTI DI MENSI ONAL MODELS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
A Note about Visual totals ............................................................................................................................... 7
A Note about Naming Convention & Cube Design Best Practices ...................................................... 7
A Note about UDM and BISM acronyms ..................................................................................................... 7
CLASSICAL MANY-TO-MANY RELATIONSHIP ............................................................................................................ 8
Business scenario .............................................................................................................................................. 8
Implementation ................................................................................................................................................. 8
CASCADING MANY-TO-MANY RELATIONSHIP ........................................................................................................ 13
Business scenario ............................................................................................................................................ 13
Implementation ............................................................................................................................................... 16
SURVEY .................................................................................................................................................................... 24
Business scenario ............................................................................................................................................ 25
Implementation ............................................................................................................................................... 25
DISTINCT COUNT ..................................................................................................................................................... 33
Business scenario ............................................................................................................................................ 33
Implementation .............................................................................................................................................. 34
Performance .................................................................................................................................................... 45
MULTIPLE GROUPS .................................................................................................................................................. 48
Business scenario ........................................................................................................................................... 48
Implementation .............................................................................................................................................. 49
CROSS-TIME ............................................................................................................................................................ 54
Business scenario ........................................................................................................................................... 54
Implementation ............................................................................................................................................... 55
TRANSITION MATRIX .............................................................................................................................................. 63
Business scenario ........................................................................................................................................... 63
Implementation .............................................................................................................................................. 65
MULTIPLE PARENT/CHILD HIERARCHIES ............................................................................................................. 70
Business scenario ........................................................................................................................................... 70
Implementation ............................................................................................................................................... 72
HIERARCHY RECLASSIFICATION WITH UNARY OPERATOR ................................................................................... 80
Business scenario ........................................................................................................................................... 80
Implementation .............................................................................................................................................. 82
Pandllng of Lhe unary operaLor ............................................................................................................................................. 83
uslng SCL Lo expand Lhe expresslons .................................................................................................................................... 83
8ulldlng Lhe model ................................................................................................................................................................. 86
CONSIDERATIONS ABOUT MULTIDIMENSIONAL MODELS .................................................................................... 94
Links ................................................................................................................................................................... 94
TABULAR MODELS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
A Note about UDM and BISM acronyms .................................................................................................. 96
Modeling Patterns with many-to-many .................................................................................................. 96
CLASSICAL MANY-TO-MANY RELATIONSHIP ......................................................................................................... 98

Business scenario ........................................................................................................................................... 98
BISM Implementation ................................................................................................................................... 98
Denali Implementation .............................................................................................................................. 103
Performance Analysis ................................................................................................................................. 103
CASCADING MANY-TO-MANY RELATIONSHIPS ................................................................................................... 104
Business scenario .......................................................................................................................................... 105
BISM Implementation .................................................................................................................................. 107
SURVEY ................................................................................................................................................................... 112
Business Scenario ......................................................................................................................................... 112
BISM Implementation .................................................................................................................................. 114
Denali Implementation ............................................................................................................................... 119
Performance Analysis ................................................................................................................................. 120
MULTIPLE GROUPS ................................................................................................................................................ 122
TRANSITION MATRIX ............................................................................................................................................. 124
Transition Matrix with Snapshot Table ................................................................................................... 126
SNAPSHOT TABLE IN THE SLOWLY CHANGING DIMENSION SCENARIO ............................................................. 127
SNAPSHOT TABLE IN THE HISTORICAL ATTRIBUTE TRACKING SCENARIO ........................................................ 130
TRANSITION MATRIX WITH CALCULATED COLUMNS .......................................................................................... 133
BASKET ANALYSIS ................................................................................................................................................... 138
Denali Implementation ............................................................................................................................... 143
CONSIDERATIONS ABOUT MULTIDIMENSIONAL MODELS ................................................................................... 147
Links .................................................................................................................................................................. 147




The Many-to-Many Revolution 5

Introduction
SCL Server Analysls Servlces lnLroduced modellng many-Lo-many relaLlonshlps beLween dlmenslons ln
verslon 2003. AL a flrsL glance, we may Lend Lo underesLlmaLe Lhe lmporLance of Lhls feaLure: afLer all,
many oLher CLA englnes do noL offer many-Lo-many relaLlonshlps. ?eL, Lhls lack dld noL llmlL Lhelr
adopLlon and, apparenLly, only a few buslnesses really requlre lL.
1he SCL Server Analysls Servlces verslon LhaL wlll be released ln 2012 (currenLly codenamed uenall") wlll
lnLroduce a new modellng (8lSM, 8uslness lnLelllgence SemanLlc Model) cholce LhaL ls called 8lSM
1abular" and wlll rename Lhe former uuM (unlfled ulmenslonal Model) Lo 8lSM MulLldlmenslonal".
uuM/8lSM MulLldlmenslonal models can leverage many-Lo-many relaLlonshlps helplng you Lo presenL daLa
from dlfferenL perspecLlves LhaL are noL feaslble wlLh a LradlLlonal sLar schema. 1hls opened a brand new
world of opporLunlLles LhaL Lranscends Lhe llmlLs of LradlLlonal CLA. AL Lhe same Llme, whlle 8lSM 1abular
wlll noL dlrecLly supporL many-Lo-many relaLlonshlps beLween Lables, you wlll be able Lo express such
relaLlonshlps by uslng uAx formulas.
1he uAx language can be used ln owerlvoL for Lxcel, whlch baslcally ls SSAS runnlng ln process lnslde
Lxcel and provldes a good meLhod Lo proLoLype complex cubes, learn Lhe uAx language and experlmenL
wlLh Lhe modellng feaLures we are descrlblng here.
ln Lhls paper, we wlll explore many dlfferenL uses of many-Lo-many relaLlonshlps ln boLh 8lSM
MulLldlmenslonal and 8lSM 1abular, ln order Lo glve us more cholces Lo model effecLlvely buslness needs,
lncludlng:
Classlcal many-Lo-many
Cascadlng many-Lo-many
Survey
ulsLlncL CounL
MulLlple Croups
Cross-1lme
1ranslLlon MaLrlx
MulLlple Plerarchles
Plerarchy 8eclasslflcaLlon wlLh unary operaLor
8askeL Analysls
1he paper wlll flrsL presenL Lhe 8lSM MulLldlmenslonal models, and Lhen Lhe 8lSM 1abular models. MosL of
Lhe models correspond Lo Lhe 8lSM MulLldlmenslonal and one ls unlque Lo 8lSM 1abular (8askeL Analysls).
?ou can read Lhese Lwo secLlons of Lhe paper lndependenLly.
AlLhough you do noL have Lo, we recommend readlng Lhe models ln Lhe presenLed order, because ofLen
one bullds upon a prevlous model and we have arranged Lhem ln order of complexlLy.
www. sql bi . com


6 The Many-to-Many Revolution
lL ls fundamenLal Lo undersLand how many-Lo-many relaLlonshlps work wlLhln Analysls Servlces (ln boLh
8lSM MulLldlmenslonal and 8lSM 1abular) ln order Lo use Lhem for dlfferenL purposes: mlnor
lmplemenLaLlon deLalls such as Lhe relaLlonshlps beLween dlmenslons and measure groups could have
ma[or deslgn repercusslons slnce small changes may lead Lo dlfferenL resulLs and confuslon Lo Lhe end
users. 1he Lheory of chaos applles wonderfully Lo Lhe usage of many-Lo-many relaLlonshlps.
Lach model has a brlef lnLroducLlon, followed by a buslness scenarlo LhaL may beneflL from lLs use and an
explanaLlon of lLs lmplemenLaLlon. Lach model uses only Lhe mlnlmal seL of dlmenslons LhaL are necessary
Lo explaln Lhe concepL behlnd lL and a small daLaseL LhaL demonsLraLes Lhe underlylng behavlor.

The Many-to-Many Revolution 7

Multidimensional Models
1hls secLlon presenLs Lhe many-Lo-many relaLlonshlps applled Lo 8lSM MulLldlmenslonal / uuM models.
A NOTE ABOUT VISUAL TOTALS
1here ls an lmporLanL warnlng abouL Lhe use of Lhe vlsual1oLals Mux funcLlon and Lhe correspondlng CLA
feaLure. vlsual 1oLals apply only Lo one level aL a Llme wlLh many-Lo-many dlmenslons. ln Lhe Llnks secLlon,
you wlll flnd a llnk Lo a documenL wrlLLen by 8lchard 1kachuk LhaL explalns Lhls llmlLaLlon
A NOTE ABOUT NAMING CONVENTION & CUBE DESIGN BEST PRACTICES
1he examples ln Lhls documenL do noL follow besL pracLlces ln namlng convenLlon and cube deslgn for
Analysls Servlces. !usL Lo make an example, we kepL Lhe preflx ulm and lacL Lo Lhe enLlLles ln Analysls
Servlces and we dlrecLly map SCL Server Lables, lnsLead of uslng vlews deflned on Lhe daLabase ln order Lo
decouple Lhe Lwo layers. 1hese and oLher suggesLlons are lncluded ln Lhe SCL8l MeLhodology paper and ln
Lhe LxperL Cube uevelopmenL wlLh MlcrosofL SCL Server 2008 Analysls Servlces book (see llnks aL Lhe end
of Lhe documenL).
A NOTE ABOUT UDM AND BISM ACRONYMS
ln 2011, MlcrosofL announced LhaL 8lSM (8uslness lnLelllgence SemanLlc Model) ls Lhe new acronym LhaL
groups all Lhe models LhaL you can creaLe wlLh Analysls Servlces. uuM (unlfled ulmenslonal Model) ls Lhe
name LhaL, slnce SCL Server 2003, ldenLlfled a mulLldlmenslonal model for Analysls Servlces. SLarLlng wlLh
SCL Server uenall", whlch wlll probably be released ln 2012, Lhere wlll be Lwo Lypes of modellng posslble
ln Analysls Servlces: 8lSM MulLldlmenslonal, whlch corresponds Lo Lhe prevlous uuM, and 8lSM 1abular,
whlch relles on a new sLorage englne (verLlpaq) and requlres a dlfferenL approach Lo model many-Lo-many
relaLlonshlps. ln Lhls parL of Lhe paper, we only conslder Lhe 8lSM MulLldlmenslonal model and we used Lhe
prevlous uuM acronym, because all Lhe Lechnlques descrlbed here can be used wlLh any verslon of uuM
slnce SCL Server Analysls Servlces 2003.
www. sql bi . com


8 The Many-to-Many Revolution
Classical many-to-many relationship
1hls common slLuaLlon may beneflL from many-Lo-many relaLlonshlps. We wlll analyze a slLuaLlon where we
have a very slmple many-Lo-many relaLlonshlp beLween Lwo dlmenslons. Lven lf Lhe case ls very slmple, lL ls
sLlll useful Lo analyze lL ln deLall because, laLer, Lhose deLalls wlll geL more complex and we need Lo
undersLand Lhem very well.
BUSINESS SCENARIO
Pere ls a Lyplcal buslness scenarlo drawn from Lhe bank buslness: we have a facL Lable LhaL descrlbes a
measure (ln Lhls case an accounL balance Laken aL a glven polnL of Llme) for a glven enLlLy (a bank accounL)
LhaL can be [olned Lo many members of anoLher dlmenslon (a [olnL accounL owned by several cusLomers).
1hose of you famlllar wlLh Lhe classlcal" mulLldlmenslonal model can already see Lhe dlfflculLy. lL ls noL
easy Lo descrlbe Lhe non-aggregablllLy of measures [olned Lo dlmenslons wlLh a many-Lo-many relaLlonshlp.
ln Lhls case, each bank accounL can have one or more owners and each owner can have one or more
accounLs buL we should noL add Lhe cash of an owner Lo hls/her [olnL owners.

Figure 1 Cl assical many-to-many diagram
1here are many oLher scenarlos where Lhe classlcal many-Lo-many relaLlonshlp appears. 8ecause lL ls Lhe
slmplesL of all many-Lo-many relaLlonshlps, we use Lhls example Lo descrlbe ln deLall how many-Lo-many
relaLlonshlps work ln Analysls Servlces. We do noL wanL Lo descrlbe all Lhe Lyplcal slLuaLlons where we can
use Lhe classlcal many-Lo-many relaLlonshlp.
IMPLEMENTATION
1he lmporLanL Lhlng Lo remember ls LhaL we use a many-Lo-many relaLlonshlp Lo correlaLe dlmenslons. ln
CLA cubes, Lhe relaLlonshlp ls always beLween facLs and dlmenslons. We need Lo lnLroduce an
lnLermedlaLe facL Lable LhaL deflnes Lhe many-Lo-many relaLlonshlp beLween Lhe dlmenslons. 1hls facL Lable
wlll [oln Lo boLh dlmenslons and acL as a brldge beLween Lhem. 1yplcally, Lhls speclal" facL Lable has no
measures.
Bridge_AccountCustomer
PK,FK1 ID_Account
PK,FK2 ID_Customer
Dim_Account
PK ID_Account
Account
Dim_Customer
PK ID_Customer
CustomerName
Dim_Date
PK ID_Date
Date
Fact_Balance
PK ID_Balance
FK1 ID_Account
FK2 ID_Date
Amount

The Many-to-Many Revolution 9


Figure 2 Relational model with many-to-many relationship
When you deflne relaLlonshlps beLween Lhe dlmenslons and Lhe measure groups, you speclfy LhaL ulm
CusLomer ls [olned Lo lacL 8alance Lhrough Lhe 8rldge AccounL CusLomer measure group (as deflned by Lhe
selecLed lLem ln llgure 3).

Figure 3 UDM with many-to-many relationship
lease noLe LhaL llgure 3 shows Lhe resulLs of Lhe auLo bulld" feaLure of Lhe Cube wlzard: Lhe wlzard does
a good [ob ln Lhls case deLecLlng LhaL Lhe many-Lo-many relaLlonshlp beLween lacL 8alance and ulm
CusLomer ls vla Lhe 8rldge Lable. ln subsequenL models, we wlll Lake Lhese relaLlonshlps one-sLep furLher by
addlng oLher dlmenslon-measure group relaLlonshlps manually. When Lhe golng ls geL Lough, Lhe auLo bulld
feaLure wlll be of no help, only our braln wlll be useful.
We can furLher descrlbe Lhe many-Lo-many relaLlonshlp uslng Lhe ueflne 8elaLlonshlp" dlalog box (llgure
4) LhaL ls dlsplayed when you cllck on Lhe buLLon conLalned ln Lhe lnLersecLlng cell (Lhe hlghllghLed cell ln
llgure 3). 1hls dlalog box ls avallable for every comblnaLlon beLween dlmenslons and measure groups and lL
allows you Lo selecL Lhe Lype of relaLlonshlp.
www. sql bi . com


10 The Many-to-Many Revolution

Figure 4 Many-to-many relationship dialog box
When we deflne Lhe relaLlonshlp, we can cross Lhe Lwo dlmenslons and see Lhe resulLs shown ln llgure 3.
We creaLed four cusLomers (Luke, Mark, aul and 8oberL) and slx accounLs ln Lhe LesL Lables. Lach accounL
[olns Lo one or more cusLomers (Lhe accounL name ls a concaLenaLlon of Lhe accounL holders) and Lhe
balance for each accounL ls always 100 aL Lhe daLe used by Lhe query, as you can see ln llgure 3.

Figure 5 Many-to-many relationship result
lor each cusLomer, we can ldenLlfy Lhe accounLs LhaL he owns and, for each accounL, we can see Lhe
balance repeaLed for each owner. WhaL ls lnLeresLlng ls LhaL Lhe LoLal for each accounL (row) ls always 100
(Crand 1oLal row) and Lhe balance for all accounLs ls 600 (100 * 6), lnsLead of Lhe sum of Lhe cusLomers
balance, whlch would be 800 buL dolng LhaL would sum Lhe same accounL mulLlple Llmes. 1hls ls Lhe flrsL
example of Lhe greaL power of Lhe many Lo many dlmenslonal modellng Lools.
llgure 6 beLLer hlghllghLs Lhe parLlcular aggregablllLy of AmounL and CounL ln respecL of ulm CusLomer. ?ou
can easlly see LhaL Lhey are noL slmply summed up buL LhaL Lhe many-Lo-many relaLlonshlp ls worklng
maklng Lhe LoLal of Lhe column dlfferenL from Lhe sum of all Lhe rows.

The Many-to-Many Revolution 11


Figure 6 Measures aggregation by Customer Name
We could obLaln Lhe same resulL wlLhouL many-Lo-many relaLlonshlps buL only wlLh some sLunLs and
Lradeoffs ln Lerms of processlng Llme or query performance (compared Lo resulLs we can obLaln wlLh
Analysls Servlces and many-Lo-many relaLlonshlps).
now, leL us make some conslderaLlon abouL Lhe counL measure LhaL ls avallable ln Lhe 8rldge AccounL
CusLomer measure group. We sald LhaL - normally - Lhe brldge Lable does noL conLaln measures.
neverLheless, we are lnLeresLed ln looklng aL whaL happens when we use Lhem.
Lven lf lL seems Lo be very slmllar Lo Lhe lacL 8alance CounL measure, lL has an lmporLanL dlfference LhaL
we can observe by querylng dlfferenL daLa. LeL us look aL daLa relaLed Lo !an-06 ln llgure 7.

Figure 7 Account Mark-Paul is missing in Jan-06 data
Pere you can see LhaL Lhe balance for Lhe accounL Mark-aul ls mlsslng from Lhe query resulLs and for Lhls
reason we do noL have a correspondlng row. 1hls wlll have consequences ln Lhe measures exposed by Lhe
lacL 8alance CounL and 8rldge AccounL CusLomer measure groups.

Figure 8 Counts with no rel ationship between Dim Date and Bridge
llgure 8 shows query resulLs for Lhe Lwo dlfferenL counL measures.
1he lacL 8alance CounL wlll counL rows ln Lhe lacL 8alance measure group: ln Lhls query, lL
represenLs how many balances are presenL for each cusLomer wlLhln a glven perlod. Slnce each
www. sql bi . com


12 The Many-to-Many Revolution
accounL has only one balance for each monLh, lL could also be mlsLaken for Lhe number of
accounLs LhaL a cusLomer has, buL Lhe Crand 1oLal proves LhaL Lhls assumpLlon ls lncorrecL.
1he 8rldge AccounL CusLomer CounL measure provldes always Lhe number of accounLs for each
cusLomer correcLly. We obLaln Lhls value by dlrecLly counLlng Lhe number of rows ln Lhe 8rldge
AccounL CusLomer measure group. Powever, Lhls number ls Llme lnvarlanL from a daLe,
because lLs measure group has no relaLlonshlp wlLh Lhe Llme dlmenslon (ulm uaLe).
lf we add Lhe relaLlonshlp beLween Lhe 8rldge AccounL CusLomers measure group and Lhe uaLe dlmenslon,
we can see values LhaL are more lnLeresLlng. We do LhaL by sLaLlng LhaL 8rldge AccounL CusLomers relaLes
Lo ulm uaLe Lhrough lacL 8alance. WhaL we are dolng ls slmply reverslng Lhe relaLlonshlp (see llgure 9).

Figure 9 Many-to-many relationship between Dim Date and Bridge Account Customer
1he resulL ls LhaL now Lhe uaLe dlmenslon lnfluences Lhe values reporLed by Lhe brldge Lables, we can see lL
ln llgure 10.

Figure 10 Counts with many-to-many relationship between Dim Date and Bridge Account
Customer
numbers have changed somewhaL (changes are hlghllghLed). now Lhe correcL lnLerpreLaLlon of Lhe 8rldge
AccounL CusLomer CounL measure ls LhaL lL represenLs Lhe number of comblnaLlons beLween cusLomers
and accounLs havlng aL leasL one balance ln Lhe consldered perlod.
1hls explalns Lhe lower value ln !an-06 for Mark and aul (a correspondlng accounL balance ls mlsslng ln
LhaL monLh) whlle Lhe Crand 1oLal ls sLlll Lhe same (lL lncludes boLh uec-03 and !an-06, so Lhe accounL
Mark-aul has aL leasL one balance).
We encourage you Lo experlmenL wlLh your daLa uslng many-Lo-many relaLlonshlps. 1hls wlll really help you
Lo undersLand Lhe lmpllcaLlons of havlng or noL havlng a relaLlonshlp beLween a dlmenslon and a brldge
measure group. lL ls only when you really masLer LhaL concepL aL Lhls slmple level (only Lwo measure
groups lnvolved) LhaL you can go furLher wlLh advanced dlmenslonal modellng Lechnlques, whlch leverage
many-Lo-many relaLlonshlps.

The Many-to-Many Revolution 13

Cascading many-to-many relationship
When we apply Lhe many-Lo-many relaLlonshlp several Llmes ln a cube, we have Lo pay aLLenLlon lf Lhere ls
a chaln of many-Lo-many relaLlonshlps. As we have seen ln Lhe classlcal many-Lo-many relaLlonshlp
scenarlo, dlmenslons LhaL apparenLly do noL relaLe Lo a brldge measure group could enhance Lhe analyLlcal
capablllLles of our model.
We wlll call Lhe slLuaLlon where Lhere ls a chaln of many-Lo-many relaLlonshlps a cascadlng many-Lo-many
relaLlonshlp".

Figure 11 Cascading many-to-many relationship diagram
ln Lhe plcLure, we can see LhaL - ln order Lo assoclaLe a caLegory Lo a LransacLlon - we need Lo Lraverse Lwo
many-Lo-many relaLlonshlps: Lhe flrsL one from accounL Lo cusLomer and Lhe second one from cusLomer Lo
caLegory.
BUSINESS SCENARIO
A Lyplcal scenarlo ls Lhe case when a dlmenslon far from Lhe maln facL Lable (a dlmenslon LhaL relaLes Lo
one brldge facL Lable) ls lnvolved ln an exlsLlng many-Lo-many relaLlonshlp and has anoLher many-Lo-many
relaLlonshlp wlLh anoLher dlmenslon.

Bridge_AccountCustomer
PK,FK1 ID_Account
PK,FK2 ID_Customer
Bridge_CustomerCategory
PK,FK2 ID_Customer
PK,FK1 ID_Category
Dim_Account
PK ID_Account
Account
Dim_Category
PK ID_Category
CategoryName
Dim_Customer
PK ID_Customer
CustomerName
Dim_Date
PK ID_Date
Date
Dim_Type
PK ID_Type
Type
Fact_Transaction
PK ID_Transaction
FK1 ID_Account
FK3 ID_Type
FK2 ID_Date
Amount
www. sql bi . com


14 The Many-to-Many Revolution
lor example, conslder Lhls sllghLly modlfled bank accounL scenarlo, wlLh a dlfferenL facL LhaL we wanL Lo
conslder:
AccounL LransacLlons: 1ransacLlons facL Lable relaLed Lo ulm uaLe, ulm AccounL and ulm 1ype.
Lach accounL can have one or more owners (cusLomers)
ulm AccounL has a many-Lo-many relaLlonshlp wlLh ulm CusLomer
Lach customer can be c|ass|f|ed |nto one or more categor|es ulm CusLomer has a many-Lo-
many relaLlonshlp wlLh ulm CaLegorles
AlLhough we could have used Lhe prevlous balance accounLs scenarlo, Lhe new schema adds Lhe ulm 1ype
dlmenslon so we need Lo use Lhe many-Lo-many relaLlonshlp ln a bldlrecLlonal way.
ln order Lo undersLand Lhe examples, we need Lo descrlbe some of Lhe daLa LhaL we wlll use ln our
lmplemenLaLlon. 1able 1 shows Lhe de-normallzed facL Lable. Lven lf Lhe uaLe dlmenslon ls noL sLrlcLly
necessary for Lhls explanaLlon, we wlll keep lL ln Lhe model because lL ls a common dlmenslon ln a slmllar
scenarlo and lL ls useful Lo see how lL relaLes Lo Lhe oLher dlmenslons.
Account 1ype Date Amount
Mark Cash deposlL 20031130 1000.00
aul Cash deposlL 20031130 1000.00
8oberL Cash deposlL 20031130 1000.00
Luke Salary 20031130 1000.00
Mark-8oberL Salary 20031130 1000.00
Mark-aul Cash deposlL 20031130 1000.00
Mark A1M wlLhdrawal 20031203 -200.00
8oberL CredlL card sLaLemenL 20031210 -300.00
aul CredlL card sLaLemenL 20031213 -300.00
Luke A1M wlLhdrawal 20031213 -200.00
Tabl e 1 Fact tabl e transaction data
1he 1ype dlmenslon ls very lmporLanL for our purposes: lL descrlbes Lhe Lype of Lhe LransacLlon and lL ls
useful Lo group LransacLlons across oLher dlmenslons.
LeL us see some klnd of quesLlons Lhe user may ask based on Lhls daLa:
WhaL ls Lhe salary/lncome for Lhe l1 enLhuslasL" caLegory?
Pow many dlfferenL LransacLlon Lypes lnvolve Lhe 8ally drlver" caLegory?
WhaL cusLomer caLegorles have A1M wlLhdrawal LransacLlons?
WlLhln Lhe facL Lable, Lhere ls noL enough lnformaLlon Lo provlde answers Lo Lhose quesLlons buL all LhaL we
need ls sLored ln Lables (dlmenslons) reachable Lhrough Lhe many-Lo-many relaLlonshlps. We only have Lo
creaLe Lhe correcL relaLlonshlps beLween dlmenslons. 1able 2 conLalns Lhe relaLlonshlp exlsLlng beLween
cusLomers and caLegorles ln our sample daLa.

The Many-to-Many Revolution 15

Customer Category
Mark l1 enLhuslasL
8oberL l1 enLhuslasL
aul 8ally drlver
8oberL 8ally drlver
Luke 1raveler
Mark 1raveler
aul 1raveler
8oberL 1raveler
Tabl e 2 Customers-categories relationship
now, Lo glve an answer Lo Lhe flrsL quesLlon (WhaL ls Lhe salary/lncome for Lhe l1 enLhuslasL" caLegory?)
we need an addlLlonal clarlflcaLlon.
lf we conslder Lhe accounLs owned by only one person, Lhen Lhere are no cusLomers belonglng
Lo Lhe l1 enLhuslasL" caLegory who geL a salary lncome.
lf we conslder [olnL accounLs (e.g. Mark and 8oberL boLh own Lhe same accounL), Lhen Lhelr
owners recelve a salary lncome even lf we do noL know who ls really earnlng money.
lrom Mark's perspecLlve, he recelves a salary lncome of 1000. Cn Lhe oLher slde, 8oberL geLs a salary
lncome of 1000 Loo! Powever, unforLunaLely for Lhem, from Lhe perspecLlve of l1 enLhuslasL" caLegory we
cannoL counL Lhe same salary lncome Lwo Llmes, so Lhe l1 enLhuslasL" salary lncome ls sLlll 1000 and noL
2000. 1he Lough reallLy ls LhaL Mark and 8oberL have Lo share Lhls slngle salary lncome, because we have
no oLher way Lo know whlch of Lhem ls really recelvlng Lhls lncome, because we recorded Lhe LransacLlon
agalnsL Lhelr [olnL accounL.
1hls problem ls very common ln a bank envlronmenL: one of Lhe posslble SCL query soluLlons presenLed
below demonsLraLes Lhe dlfflculLy of Lackllng Lhls klnd of problem uslng a generlc query bullder (see Lhe
subquery ln Lhe WPL8L condlLlon of Lhe maln SCL query).
!"#"$% !'() *+,-./01+ 2 -! -./01+
345( 367+8%961:67+;/1 *+
<=="4 >5<= ?;.8%@AB C+
5= C+,<?8%@AB D *+,<?8%@AB
-=? C+,%@AB D E!6F69@G
HI"4" <?8-77/01+ <= )
!"#"$% <?8-77/01+
345( 367+FB::8$0:+/.B9$6+BJ/9@ *77
<=="4 >5<= ?;.8$6+BJ/9@ C7
5= C7,<?8$6+BJ/9@ D *77,<?8$6+BJ/9@
<=="4 >5<= 367+FB::8-77/01+$0:+/.B9 67
5= 67,<?8$0:+/.B9 D *77,<?8$0:+/.B9
HI"4" $6+BJ/9@=6.B D E<% B1+K0:;6:+G
2

lor Lhls reason, we would llke Lo resolve slmllar quesLlons wlLh a plvoL Lable.
now leL us conslder Lhe second quesLlon: Pow many dlfferenL LransacLlon Lypes are used by Lhe 8ally
drlver" caLegory?
1here are Lwo cusLomers belonglng Lo Lhe 8ally drlver" caLegory: aul and 8oberL. 1hese Lwo cusLomers
own four accounLs, whlch ln our facL Lable geL any LransacLlon Lype oLher Lhan A1M wlLhdrawal".
www. sql bi . com


16 The Many-to-Many Revolution
1herefore, Lhe answer wlll be Lhree LransacLlon Lypes: Cash deposlL (for an amounL of 3000), Salary (1000)
and CredlL card sLaLemenL (-600.00). 1he SCL query consLrucL could be very slmllar Lo Lhe prevlous one.
!"#"$% $5'=%) ?<!%<=$% *+,<?8%@AB 2 -! %961:67+;/1%@AB:
345( 367+8%961:67+;/1 *+
HI"4" <?8-77/01+ <= )
!"#"$% <?8-77/01+
345( 367+FB::8$0:+/.B9$6+BJ/9@ *77
<=="4 >5<= ?;.8$6+BJ/9@ C7
5= C7,<?8$6+BJ/9@ D *77,<?8$6+BJ/9@
<=="4 >5<= 367+FB::8-77/01+$0:+/.B9 67
5= 67,<?8$0:+/.B9 D *77,<?8$0:+/.B9
HI"4" $6+BJ/9@=6.B D E46FF@ C9;LB9G
2

1he Lhlrd quesLlon (WhaL cusLomer caLegorles have A1M wlLhdrawal LransacLlons?) requlres a dlfferenL
approach: sLarLlng from a seL of LransacLlons (fllLered by Lype) we need Lo geL relaLed cusLomers and Lhen
relaLed caLegorles. ln such a case a query bullder could glve us a worklng query, buL lL should be noLed how
poLenLlally slow Lhe query could be, because lL could generaLe a large seL of rows before applylng Lhe
ulS1lnC1 clause.
!"#"$% ?<!%<=$% C7,$6+BJ/9@=6.B
345( 367+8%961:67+;/1 *+
<=="4 >5<= ?;.8%@AB C+
5= C+,<?8%@AB D *+,<?8%@AB
-=? C+,%@AB D E-%( M;+KC96M6FG
<=="4 >5<= 367+FB::8-77/01+$0:+/.B9 *67
5= *67,<?8-77/01+ D *+,<?8-77/01+
<=="4 >5<= 367+FB::8$0:+/.B9$6+BJ/9@ *77
5= *77,<?8$0:+/.B9 D *67,<?8$0:+/.B9
<=="4 >5<= ?;.8$6+BJ/9@ C7
5= C7,<?8$6+BJ/9@ D *77,<?8$6+BJ/9@
We could opLlmlze Lhe SCL query buL ln a way LhaL ls dlfflculL Lo obLaln wlLh a generlc query bullder. Lven
ln Lhls case, a worklng plvoL Lable would be a dream LhaL becomes reallLy for an end user.
now we have enough requlremenLs Lo deslgn and LesL a mulLldlmenslonal model LhaL enables a plvoL Lable
Lo solve Lhls klnd of problems wlLh a few cllcks.
IMPLEMENTATION
llgure 12 shows Lhe relaLlonal schema of our model: we have Lwo brldge Lables (or facLless facL Lables) LhaL
[oln Lwo cascadlng" many-Lo-many relaLlonshlps, Lhe flrsL one beLween ulm AccounL and ulm CusLomer
and Lhe second one beLween ulm CusLomer and ulm CaLegory.

The Many-to-Many Revolution 17


Figure 12 Relational model with cascading many-to-many relationships
lf we creaLe Lhe cube wlLh Lhe auLo bulld feaLure of Cube Wlzard, we end up wlLh a model LhaL correcLly
ldenLlfles dlmenslon and facL Lables. Powever, Lhe problem of mlsslng relaLlonshlps beLween dlmenslons
and measure groups we have already seen ln Lhe prevlous scenarlo ls ampllfled here, as we can see ln
llgure 13. 1he wlzard ls noL able Lo flnd cascadlng many-Lo-many relaLlonshlps. A reason for Lhls behavlor ls
LhaL deflnlng all Lhe many-Lo-many relaLlonshlps could negaLlvely affecL performance.

Figure 13 Dimension relationship obtained by cube wizard/auto build feature
unforLunaLely, Lhe many gray boxes LhaL are presenL ln llgure 13 wlll produce meanlngless resulLs when we
wlll query Lhe dlmenslon and measure group aL correspondlng coordlnaLes. lor example, as shown ln
llgure 14, we cannoL see Lhe amounL of LransacLlons for each cusLomer caLegory. 1hlngs are worse when
we Lry Lo spllL Lhe AmounL measure by LransacLlon Lype (see llgure 13).
www. sql bi . com


18 The Many-to-Many Revolution

Figure 14 Categories are not rel ated to amount measure

Figure 15 Categories stil l do not spl it amount measure
AL Lhls polnL, Lhe problem seems Lo be Lhe mlsslng relaLlonshlp beLween ulm CaLegory and Lhe lacL
1ransacLlon measure group. 1o deflne lL, we can cllck on Lhe buLLon ln Lhe gray box of Lhe ueflne
8elaLlonshlp dlalog box, and Lhen selecL Lhe only avallable lnLermedlaLe measure group once we have
chosen Lhe Many-Lo-Many relaLlonshlp Lype (llgure 16 beLLer summarlze Lhls selecLlon).

Figure 16 Intermediate measure groups avail abl e for Dim Category
now we can reprocess Lhe cube, buL Lhe resulLs wlll be Lhe same and wrong as llgure 14 and llgure 13
show. 8efore clalmlng lL ls a bug of Analysls Servlces (lL ls noL), look aL Lhe new dlmenslon relaLlonshlp
summary ln llgure 17. 1here are sLlll a loL of gray boxes and Lhe lnLermedlaLe measure group beLween ulm
CaLegory and lacL 1ransacLlon ls noL Lhe same as Lhe one beLween ulm CusLomer and lacL 1ransacLlon
(one ls 8rldge CusLomer CaLegory and Lhe oLher ls 8rldge AccounL CusLomer).

The Many-to-Many Revolution 19


Figure 17 Dimension relationship after Dim Category manual definition
1o undersLand whaL ls happenlng and why, you need Lo reallze LhaL Analysls Servlces enLlLles, llke
dlmenslons and measure groups, are LoLally separaLed and dlsconnecLed from Lhe underlylng relaLlonal
schema. SubsequenLly, Analysls Servlces has noL enough lnformaLlon Lo relaLe correcLly cusLomer
caLegorles wlLh accounL LransacLlons. We Lold Analysls Servlces LhaL a caLegory ls relaLed Lo accounL
LransacLlons Lhrough Lhe 8rldge CusLomer CaLegory measure group, buL Lo go from a caLegory Lo a
LransacLlon we need Lo geL all Lhe cusLomers for LhaL caLegory (8rldge CusLomer CaLegory) and Lhen all Lhe
accounLs for Lhls seL of cusLomers (Lhrough 8rldge AccounL CusLomer). now Lhe problem should be clear:
we have noL lnformed Analysls Servlces abouL Lhe relaLlonshlp beLween ulm CaLegory and 8rldge AccounL
CusLomer. lor Lhls reason, lL ls sLlll a gray box. We can flll Lhls vold by cllcklng on Lhe . buLLon: Lhls Llme our
dlalog box shows up Lwo posslble lnLermedlaLe measure groups (llgure 18).

Figure 18 Difficult choice for Dim Category intermediate measure group
We need Lo choose 8rldge CusLomer CaLegory as Lhe lnLermedlaLe measure group, because Lhls ls Lhe only
posslble brldge facL Lable LhaL we Lraverse walklng from ulm CusLomer Lo 8rldge AccounL CusLomer lnLo
www. sql bi . com


20 The Many-to-Many Revolution
Lhe relaLlonal schema (llgure 12). Powever, why does Lhe lnLermedlaLe measure group" dropdown
lnclude Lhe lacL 1ransacLlon as a posslble lnLermedlaLe measure group? Slmply because we prevlously
deflned a (wrong) relaLlonshlp beLween ulm CaLegory and lacL 1ransacLlon uslng 8rldge CusLomer CaLegory
as Lhe lnLermedlaLe measure group (revlew llgure 16). lf we would reLurn Lo Lhe sLage lmmedlaLely afLer
Lhe Cube Wlzard, we would have seen only one cholce (Lhe rlghL one) deflnlng a many-Lo-many relaLlonshlp
beLween ulm CaLegory and 8rldge AccounL CusLomer.
AL Lhls polnL, we sLlll need Lo correcL Lhe relaLlonshlp beLween ulm CaLegory and lacL 1ransacLlon: lL has Lo
be 8rldge AccounL CusLomer lnsLead of 8rldge CusLomer CaLegory LhaL we chose prevlously. now, lf we
redeflne Lhls relaLlonshlp, Lhe dropdown llsLs boLh cholces, because ulm CaLegory has many relaLlonshlps
wlLh oLher measure groups. 1he resulLlng dlmenslon usage schema ls summarlzed ln llgure 19.

Figure 19 Correct Dim Category many-to-many relationship assignments
1o verlfy LhaL Lhls ls correcL, we can reLry Lhe querles LhaL falled ln llgure 14 and llgure 13. 1hls Llme we geL
Lhe correcL numbers, as we can see ln llgure 20 and llgure 21.

Figure 20 Categories are correctl y rel ated to amount measure

Figure 21 Categories correctl y spl it amount measure
now, prepare a cup of your favorlLe coffee and remember well whaL you are learnlng here: lL wlll save you
a loL of Llme when your favorlLe cube geLs several cascadlng many-Lo-many relaLlonshlps. 1he concepL of

The Many-to-Many Revolution 21

cascadlng many-Lo-many relaLlonshlps ls a fundamenLal one on whlch we wlll bulld Lhe resL of Lhe models
descrlbed ln Lhls book.
We use Lhe relaLlonshlp beLween a dlmenslon and a measure group Lo Lell Analysls Servlces how Lo relaLe
dlmenslon members Lo facL measures. When Lhe relaLlonshlp ls regular, lL ls slmple. When Lhe relaLlonshlp
ls many-Lo-many, the |ntermed|ate measure group must refer to a measure group that conta|ns a va||d
re|at|onsh|p w|th a d|mens|on that re|ates v|a a regu|ar re|at|onsh|p to the target measure group. 1hls
should explaln why cholces were good or bad ln our prevlous examples. ln Lhls lasL example, Lhe 8rldge
AccounL CusLomer measure group had Lo be used Lo relaLe ulm CaLegory Lo Lhe lacL 1ransacLlon measure
group. 1hls laLLer measure group ls Lhe only one LhaL has a dlmenslon (l.e. AccounL) LhaL relaLes dlrecLly Lo
Lhe lacL 1ransacLlon measure group.
Cfflclal documenLaLlon explalns Lhls concepL ln Lerms of granularlLy, whlch ls formally correcL buL much less
lnLulLlve. ln oLher words, when you deflne a many-Lo-many relaLlonshlp beLween a measure group and a
dlmenslon, you have Lo choose Lhe lnLermedlaLe measure group (brldge Lable) LhaL ls nearesL Lo Lhe
measure group, conslderlng all Lhe posslble measure groups LhaL you can cross golng from Lhe measure
group Lo Lhe consldered dlmenslon.
We Lhlnk LhaL Lhe ueflne 8elaLlonshlp dlalog could be boLh clearer and smarLer and maybe lL wlll be ln Lhe
fuLure. lor example, lL could fllLer ouL Lhe cholces LhaL are probably wrong. unforLunaLely, ln several
release cycles of Analysls Servlces MlcrosofL has noL prlorlLlzed such a feaLure.
We should sLlll check lf we meeL all oLher buslness requlremenLs:
llgure 22 shows Lhe rlghL answers Lo Lhe second quesLlon (Pow many dlfferenL LransacLlon
Lypes are used by Lhe 8ally drlver" caLegory?).
llgure 23 answers correcLly Lo Lhe Lhlrd quesLlon (WhaL caLegorles of cusLomers have A1M
wlLhdrawal LransacLlons?).
noLe LhaL, ln flgure 37, Lhe Crand 1oLal row ls noL Lhe sum of prevlous rows and LhaL lL ls coherenL wlLh Lhe
naLure of Lhe many-Lo-many relaLlonshlp.

Figure 22 Transaction types for Ral l y driver category

Figure 23 Category of customers who did ATM withdrawal s
www. sql bi . com


22 The Many-to-Many Revolution
AL Lhls polnL, we should deLermlne lf Lhe remalnlng gray boxes could sLlll lead Lo lssues wlLh oLher querles.
ln facL, lf we are lnLeresLed ln Lhe counL measure produced by Lhe brldge Lable, Lhey deflnlLely do. lor
example, lf for whaLever reason you would choose Lo address Lhe Lhlrd quesLlon uslng Lhe 8rldge CusLomer
CaLegory CounL measure lnsLead of Lhe AmounL measure (lL ls noL such a useful number, buL you should
noL ask wheLher a number ls useful whlle lL ls wrong), you would obLaln Lhe sLrange resulL of llgure 24.

Figure 24 Wrong results using Factless Customer Category Count measure
numbers aslde (ln Lhls query Lhe measure should represenL Lhe number of cusLomers for each caLegory
LhaL made aL leasL one A1M wlLhdrawal LransacLlon, buL lL does noL), Lhe caLegory llsL ls wrong. 1he reason
should be obvlous: Lhere are no valld relaLlonshlps beLween ulm 1ype and 8rldge CusLomer CaLegory
measure group, whlch conLalns Lhe measure we used ln our query. AL Lhls polnL, we musL choose beLween
maklng Lhls measure lnvlslble or flxlng Lhls measure. 1he second approach ls beLLer lf, ln Lhe fuLure, we
mlghL expand Lhe uuM: more deflned relaLlonshlps wlll make Lhe cube easler Lo explaln. Powever, Lhe flrsL
approach ls easler Lo malnLaln and could resulL ln fasLer querles, buL you should remember Lo hlde such a
meanlngless measure from Lhe end user. lor Lhe sake of compleLeness for Lhls secLlon, we wlll proceed by
compleLlng Lhe dlmenslon relaLlonshlp schema, removlng all Lhe no relaLlonshlp" gray cells.

Figure 25 Compl ete cube model for cascading many-to-many relationships
ln llgure 23 we flnallzed Lhe uuM dlmenslon usage by deflnlng relaLlonshlps beLween all dlmenslons and
all measure groups. CfLenLlmes, all Lhe many-Lo-many relaLlonshlps (all Lhe cells) of a dlmenslon usage
column polnL Lo Lhe same lnLermedlaLe measure group. 1hls ls common because only Lhe measure groups
based on a Lrue brldge facL Lable have dlfferenL lnLermedlaLe measure groups for dlfferenL dlmenslons, e.g.
Lhe 8rldge AccounL CusLomer measure group.
We worked on complex uuMs LhaL have dlfferenL lnLermedlaLe measure groups for dlfferenL dlmenslons
llnked wlLh many-Lo-many relaLlonshlps. SomeLlmes, lL happens even for sLandard" measure groups
conLalnlng real facL measures (and noL only a CounL measure as ln Lhe case of a brldge Lable). Cnce you

The Many-to-Many Revolution 23

undersLand how Lo choose Lhe correcL lnLermedlaLe measure group for a dlmenslon, you should be able Lo
handle slmllar slLuaLlons.
As we already polnLed ouL, removlng all Lhe gray cells" ln Lhe dlmenslon usage maLrlx ls noL necessarlly a
besL pracLlce" LhaL you should follow ln all cases. MalnLalnlng all Lhese relaLlonshlps ln an evolvlng cube (lL
ls normal Lo add dlmenslons and measure groups over Llme ln real llfe) could be exLremely dlfflculL and
error-prone. uo lL only when lL ls necessary. Lven ln Lhls paper, Lhere are scenarlos LhaL do noL requlre a
compleLe dlmenslon usage maLrlx.
A slmple rule of Lhumb: lf we wanL Lo make vlslble any measure derlved by an lnLermedlaLe measure group
(correspondlng Lo a brldge Lable), we wlll have Lo deflne dlmenslons relaLlonshlps for all lnLermedlaLe
measure groups LhaL are Lraversed ln order Lo connecL Lhe measure Lo oLher lnLeresLlng dlmenslons, even lf
Lhe vlslble measure ls only a row counL (Lhe only measure you should geL from a real brldge Lable).
now we can geL Lhe rlghL answer for Lhe Lhlrd quesLlon (WhaL cusLomer caLegorles have A1M wlLhdrawal
LransacLlons?) even wlLh Lhe 8rldge CusLomer CaLegory CounL measure, as we can see ln llgure 26.

Figure 26 Right results using Factless Customer Category Count measure
Cnce you have masLered cascadlng many-Lo-many relaLlonshlps, you wlll deflnlLely have galned Lhe ablllLy
Lo creaLe rlcher mulLldlmenslonal models, such as Lhe ones LhaL follow.
www. sql bi . com


24 The Many-to-Many Revolution
Survey
1he survey scenarlo ls a common example of a more general case where we have many aLLrlbuLes
assoclaLed wlLh a case (one cusLomer, one producL, and so on). We wanL Lo normallze Lhe model because
we do noL wanL Lo change Lhe uuM each Llme we add a new aLLrlbuLe Lo daLa (e.g. addlng a new dlmenslon
or changlng an exlsLlng one).
1he common scenarlo ls a quesLlonnalre conslsLlng of quesLlons LhaL have predeflned answers wlLh boLh
slmple and mulLlple cholces. 1he nalve soluLlon ls Lo deflne a facL Lable and Lhree dlmenslons:
ulm CuesLlons wlLh Lhe quesLlons.
ulm Answers for Lhe answers provlded by cusLomers
ulm CusLomer for Lhe cusLomer who answered a speclflc quesLlon
1he facL Lable wlll conLaln a value lndlcaLlng Lhe exacL answer from Lhe cusLomer, ln Lhe case of mulLlple
cholces.
8ecause we do noL need Lo analyze quesLlons wlLhouL answers, a beLLer soluLlon ls Lo have only one Lable
for boLh quesLlons and answers. 1hls wlll reduce Lhe number of dlmenslons wlLhouL havlng any lnfluence
on Lhe expresslvlLy of Lhe model and wlll make Lhe compleLe soluLlon slmpler Lo boLh navlgaLe and creaLe.
1he sLar schema model (one facL Lable wlLh answers [olned wlLh a quesLlons/answers dlmenslon and a case
dlmenslon) ls fully queryable uslng SCL.
Powever, once we move Lo uuM Lhlngs become harder: whlle lL ls very slmple Lo compare dlfferenL
answers Lo Lhe same quesLlon, lL could be very dlfflculL Lo correlaLe frequency counLs of answers Lo more
Lhan one quesLlon. lor example, lf we have a quesLlon asklng for sporLs pracLlced (mulLlple cholces) and
anoLher one asklng for [ob performed, probably we would llke Lo know whaL paLLern of sLaLlsLlcal
relaLlonshlps - lf any - exlsL beLween Lhe Lwo correspondlng seLs of answers.
1he normal way Lo model lL ls havlng Lwo dlfferenL aLLrlbuLes (or dlmenslons) LhaL users can comblne on
rows and columns of a plvoL Lable. unforLunaLely, havlng an aLLrlbuLe for each quesLlon ls noL very flexlble.
Moreover, we wlll have Lo change Lhe sLar schema Lo accommodaLe havlng a slngle row ln Lhe facL Lable for
each case. 1hls makes lL very dlfflculL Lo handle any mulLlple-cholce quesLlon.
lnsLead, we can change our perspecLlve and leverage many-Lo-many relaLlonshlps. We can bulld a flnlLe
number (as many as we wanL) of quesLlons/answers dlmenslons, dupllcaLlng many Llmes Lhe orlglnal one
and provldlng Lhe user wlLh a number of fllLer" dlmenslons LhaL can be crossed lnLo a plvoL Lable or can be
used Lo fllLer daLa LhaL, for each case, saLlsfy deflned condlLlons for dlfferenL quesLlons.
1hls ls Lhe flrsL Llme LhaL we are dupllcaLlng daLa from Lhe relaLlonal model ln order Lo accommodaLe Lhe
needs of uuM, We shall see ln subsequenL chapLers LhaL Lhe same Lechnlque wlll be useful qulLe ofLen,
every Llme we wlll need Lo make a Lable behave llke boLh a dlmenslon and brldge Lable. uslng vlews, we
can dupllcaLe Lables as many Llmes as we need wlLhouL havlng Lo worry abouL space opLlmlzaLlon.
8emember LhaL Lhe survey scenarlo ls usable ln many slmllar clrcumsLances: classlflcaLlon of producL
characLerlsLlcs (for lnsLance Lagglng") and baskeL analysls are [usL Lwo among many examples of
appllcaLlons of Lhls Lechnlque.

The Many-to-Many Revolution 25

BUSINESS SCENARIO
LeL us explore Lhe survey scenarlo ln more deLall. uaLa was loaded lnLo Lhe sLar schema shown ln llgure 27.
ulm_CuesLlonsAnswers conLalns boLh quesLlons and answers. We could have deflned Lwo lndependenL
dlmenslons (resulLlng ln a snowflake schema) buL lL ls a cholce we do noL recommend for Lwo reasons: Lhe
flrsL ls Lhe malnLenance cosL Lo updaLe surrogaLe keys, Lhe second ls LhaL Lhere ls no reason Lo query
quesLlons wlLhouL answers (Lyplcally, you wlll make vlslble only a hlerarchy CuesLlon-Answer on Lhe uuM).

Figure 27 Relational Survey star schema
Cur users wanL Lo query Lhls model ln a lvoL1able and wanL Lo avold wrlLlng even a slngle row of Mux. A
Lyplcal query could be Pow many cusLomers play boLh soccer and hockey?" We can calculaLe lL uslng an
SCL soluLlon wlLh CCun1(*) expresslon, whlle a more correcL one could be CCun1(ulS1lnC1 lu_CusLomer)
ln a more general case (useful lf you add more complex fllLer condlLlons).

!"#"$% $5'=% )N2
345( 367+8-1:MB9: 6O
<=="4 >5<= ?;.8P0B:+;/1:-1:MB9: QO
5= QO,<?8P0B:+;/1-1:MB9 D 6O,<?8P0B:+;/1-1:MB9
<=="4 >5<= 367+8-1:MB9: 6R
5= 6R,<?8$0:+/.B9 D 6O,<?8$0:+/.B9
<=="4 >5<= ?;.8P0B:+;/1:-1:MB9: QR
5= QR,<?8P0B:+;/1-1:MB9 D 6R,<?8P0B:+;/1-1:MB9
HI"4" QO,-1:MB9 D E!/77B9G
-=? QR,-1:MB9 D EI/7SB@G

Addlng more condlLlons would requlre new lnnL8 !Clns (Lwo for each condlLlon) Lo Lhe query. lor Lhls and
oLher reasons, lL would be very dlfflculL Lo geL a parameLerlzed query LhaL auLomaLlcally solves Lhls
problem.
Moreover, we wanL Lo be able Lo change surveys ln Lhe fuLure, keeplng Lhem compaLlble wlLh exlsLlng daLa
and querles (aL leasL for ldenLlcal quesLlons LhaL use Lhe same answers). Cne day we could add more
quesLlons and answers, wlLhouL requlrlng a cube or dlmenslon full process, allowlng lncremenLal updaLes of
any enLlLy.
IMPLEMENTATION
1o lmplemenL a cube based on Lhe sLar schema shown ln llgure 27 we deflne a slngle CuesLlonsAnswers
dlmenslon (see llgure 28). ln Lhls way, Lhe user can fllLer rows of lacL_Answers Lable (or cells of Lhe derlved
cube). Powever, we do noL wanL Lo calculaLe Lhe number of answers. lnsLead, we wanL Lo fllLer cusLomers
Dim_Customers
PK ID_Customer
I1 COD_Customer
Customer
Dim_QuestionsAnswers
PK ID_QuestionAnswer
U1 COD_Question
Question
U1 COD_Answer
Answer
Fact_Answers
PK ID_Answer
FK1 ID_Customer
FK2 ID_QuestionAnswer
Value
www. sql bi . com


26 The Many-to-Many Revolution
LhaL saLlsfy a glven condlLlon, Lhen fllLer cusLomers LhaL saLlsfy anoLher condlLlon and, aL Lhe end, we need
Lo geL Lhe lnLersecLlon beLween Lhese Lwo seLs of cusLomers.

Figure 28 Dimension QuestionsAnswers
We need Lo deslgn a dlmenslonal model LhaL uses Lhe same CuesLlonsAnswers dlmenslon several Llmes,
allowlng us Lo comblne dlfferenL answers and quesLlons for Lhe same cusLomer. We wlll call Lhe resulLlng
dlmenslons lllLer 1", lllLer 2", and so on. 1o make an analogy, Lhls approach ls slmllar Lo deflnlng allases
ln a SCL query whenever you wanL Lo refer Lo Lhe same Lable mulLlple Llmes wlLh dlfferenL fllLer and/or [oln
condlLlons.
users wlll be able Lo selecL any comblnaLlon of Lhose dlmenslons and fllLer on Lhem. 1hls wlll resulL ln a
query LhaL applles all Lhe fllLers (loglcal Anu). Powever, Lhe Anu condlLlon wlll be applled only Lo Lhose facL
rows LhaL belong Lo Lhe same cusLomer. noLe LhaL we seek Lo evaluaLe Lhe number of cusLomers who have
speclflc characLerlsLlcs based on Lhe survey: ln Lhls case, our maln facL Lable, ln Lhe cube, ls noL Lhe
lacL_Answers facL Lable, buL ulm_CusLomers lLself!
1o model our cube, we need Lo relaLe each cusLomer Lo all answers for LhaL cusLomer, as we would de-
normallze Lhe lacL_Answers facL Lable Lo have a column for each CuesLlonsAnswers member. lrom a
pracLlcal polnL of vlew, Lhere ls a many-Lo-many relaLlonshlp beLween CusLomers and each
CuesLlonsAnswers dlmenslons (renamed Lo lllLer n") we added Lo Lhe cube. ln order Lo do LhaL, we use
Lhe lacL_Answers facL Lable as Lhe brldge facL Lable of a many-Lo-many relaLlonshlp, and we use Lhe
ulm_CusLomers dlmenslon Lable as a facL Lable (Lo geL Lhe cusLomers counL).
Lach lllLer" dlmenslon wlll use Lhe same physlcal brldge Lable Lo reference Lhe CuesLlonsAnswers
dlmenslon. lL ls convenlenL Lo deflne a loglcal vlew (named query) lnLo Lhe uaLa Source vlew (uSv) Lo
creaLe n dlfferenL measures groups ln Lhe cube (each one has Lo be relaLed Lo a dlfferenL Lable)
1
. Pere, n ls
Lhe number of lllLer" dlmenslons we have chosen.
1he brldge Lable ls repeaLed ln Lhe uSv deflnlng several named querles wlLh Lhe same query lnslde. ln Lhls
way, we can use Lhe Cube LdlLor for Lhls model: normally, vlsual SLudlo edlLor would noL allow you Lo
creaLe many dlfferenL measure groups based on Lhe same facL Lable, unless you deflne a ulsLlncL CounL
measure. AlLernaLlvely, you could manually deflne dlfferenL measure groups relaLed Lo Lhe same facL Lable
by modlfylng Lhe cube xML deflnlLlon uslng a LexL edlLor.

11
1he careful reader should scream and ask why we are uslng a named query lnsLead of a daLabase vlew for Lhese fllLer dlmenslons. 1he
answer ls LhaL Lhese fllLer dlmenslon belong Lo Lhe compleLely prlvaLe area of Lhe cube. 1hey represenL a Lechnlcal means needed Lo creaLe
Lhe uuM model. As Lhere ls no reason Lo share Lhls lnformaLlon wlLh anybody else, a named query hldden ln Lhe pro[ecL ls a good place for
Always remember LhaL you should noL Lake any slngle hlnL ln Lhls book as lL ls, you always have Lo Lhlnk and, lf you belleve someLhlng can be
done beLLer ln your case overrldlng our hlnLs, you wlll be welcome Lo do lL, as we normally do. ?our braln wlll work much beLLer Lhan any seL
of predeflned rules.

The Many-to-Many Revolution 27

1he source of Lhe named query ls very slmple:

!"#"$%
<?8-1:MB9T
<?8$0:+/.B9T
<?8P0B:+;/1-1:MB9T
U6F0B
345( 367+8-1:MB9:

ln Lhe example, we wlll use Lhree lllLer" dlmenslons. 1herefore, we need Lhree allases for Lhe
lacL_Answers facL Lable. We deflned a named query vlew for each one lnsLead of uslng Lhe real facL Lable.
llgure 29 shows Lhe resulLlng uSv.

Figure 29 Survey model Data Source View
We can use Lhe Cube Wlzard Lo sLarL Lhe cube modellng. AfLer Lhe flrsL Lwo sLeps (accepL Lhe defaulLs) we
come Lo Lhe ldenLlfy lacL and ulmenslon 1ables sLep. We need Lo change Lhe suggesLed selecLlon as shown
ln llgure 30. We use ulm_CusLomers as lacL and ulmenslon and we excluded Lhe lacL_Answers Lable
(lnsLead, we wlll use Lhe named querles based on Lhe vlacL_Answers vlews).
www. sql bi . com


28 The Many-to-Many Revolution

Figure 30 Cube Wizard sel ection for Survey Cube
ln Lhe nexL sLep (8evlew Shared ulmenslons), we choose all dlmenslons from Lhe avallable dlmenslons"
llsL. ln Lhe SelecL Measures sLep LhaL follows, we make a llfLlng Lo defaulL measure names, as shown ln
llgure 31.

Figure 31 Esthetic changes to measure names
We accepL Lhe defaulLs ln Lhe sLeps LhaL follow and we name Lhe cube Survey. Cnce we compleLe Lhe Cube
Wlzard, Lhe Cube ueslgner opens and shows Lhe resulLlng cube sLrucLure (see llgure 32). Lach Answersn
measure group wlll conLaln daLa needed Lo bulld Lhree dlfferenL lllLer dlmenslons based on CuesLlons
Answers dlmenslon.
We need Lo add role-playlng dlmenslons" Lo Lhe cube Lo bulld Lhe Lhree lllLer dlmenslons (shown ln Lhe
ulmenslon pane ln llgure 32).

The Many-to-Many Revolution 29


Figure 32 Resulting Survey Cube Structure
1o add a dlmenslon we can use Lhe ulmenslon usage Lab and cllck on Lhe Add Cube ulmenslon buLLon. We
add Lhe CuesLlons Answers dlmenslon Lhree Llmes and we rename Lhem Lo lllLern", where n ls a
progresslve number Lo dlsLlngulsh Lhe fllLer dlmenslon (ln Lhls case ranglng from one Lo Lhree). We wlll
rename Lhe orlglnal CuesLlons Answers dlmenslon Lo lllLer1.
As we learned ln prevlous scenarlos, we have Lo seL up useful relaLlonshlps beLween dlmenslons and
measures groups. llgure 33 shows Lhe relaLlonshlps we need. lf you conslder Lhe CusLomer Measure Croup
only, you reallze LhaL we have a facL dlmenslon (ulm_CusLomers) relaLed many Llmes Lo CuesLlons Answers
(used Lhree Llmes as a role-playlng dlmenslon) Lhrough a dlfferenL brldge facL Lable each Llme.
www. sql bi . com


30 The Many-to-Many Revolution

Figure 33 Dimension Usage for Survey Cube
8efore analyzlng Lhe resulLs on a plvoL Lable, look aL sample daLa used ln Lhe LesL. We have four cusLomers
(8lll, LllsabeLh, !ohn and Mark) and a survey for each cusLomer. osslble quesLlons and answers of Lhe
survey are shown ln 1able 3.
uest|on Answer
SporLs 1ennls
SporLs Colf
SporLs Soccer
SporLs Pockey
!ob Lmployee
!ob SLudenL
!ob ueslgner
Age Age
Tabl e 3 Dim_QuestionsAnswers data
1he survey daLa ls vlslble ln 1able 4.
Customer uest|on Answer
8lll Age 28
8lll !ob ueslgner
8lll SporLs Pockey
8lll SporLs Soccer
LllsabeLh Age 31
LllsabeLh !ob ueslgner
LllsabeLh SporLs Colf
LllsabeLh SporLs 1ennls
!ohn Age 29
!ohn !ob SLudenL
!ohn SporLs Soccer
Mark Age 30
Mark !ob Lmployee
Mark SporLs Colf
Mark SporLs Soccer
Mark SporLs 1ennls
Tabl e 4 vFact_AnswersN data

The Many-to-Many Revolution 31

lease noLe LhaL only 8lll plays boLh Soccer and Pockey. 1hls wlll be useful for Lhe nexL conslderaLlons.
now, we can process Lhe cube and see lf lL works as expecLed.
ln llgure 34, we puL a lllLer dlmenslon on rows and anoLher lllLer dlmenslon on columns and we selecLed
only Lhe answer Pockey for rows and only Lhe answer Soccer for columns, because we wanLed Lo llmlL Lhe
resulLs Lo a speclflc case.

Figure 34 Query between members of the same dimension
We can also lnLersecL more answers and quesLlons lnLo Lhe same plvoL Lable reporL. llgure 33 shows LhaL
many cusLomers play Lwo sporLs and whaL Lhey are, whaL ls Lhe relaLlonshlp beLween [obs and sporLs, and
so on. 1here ls a cerLaln daLa redundancy because Lhe daLa ls mlrrored dlagonally from Lop-lefL Lo boLLom-
rlghL. 1hls klnd of analysls ls bldlrecLlonal and Lhe order of answers provlded by cusLomers ls unlmporLanL.

Figure 35 Cross sel ection between members of the same dimension
1he flnal Louch ls Lo query who Lhe cusLomers wlLh speclflc characLerlsLlcs are. ln llgure 36, we double
cllcked on Lhe lnLersecLlon beLween column Colf and row 1ennls Lo geL a drlll Lhrough and we geL Lhe
people who play boLh golf and Lennls. ?ou can check ln 1able 4 LhaL Lhe resulL ls correcL.
www. sql bi . com


32 The Many-to-Many Revolution

Figure 36 Drillthrough on Golf-Tennis cel l
lL ls posslble Lo use Lhe Survey model for many scenarlos LhaL presenL slmllar challenges. lor example, we
could apply Lhe same Lechnlque Lo alarms and/or dlagnosLlcs generaLed on lLems (cusLomers, cars).
AnoLher scenarlo ls Lhe analysls of cross-sell opporLunlLles. 1here are many daLa mlnlng models Lo do LhaL
buL, someLlmes, a graphlcal ouLpuL helps Lo vlsuallze all of Lhe relaLlonshlps beLween speclflc lLems: Lhe
plvoL Lable ls Lhe slmplesL way Lo obLaln lL.

The Many-to-Many Revolution 33

Distinct Count
ulsLlncL counL measures are very useful and commonly requlred. unforLunaLely, Analysls Servlces
lmplemenLaLlon of dlsLlncL counL ls very resource-lnLenslve. 1he algorlLhm used Lo process a dlsLlncL counL
measure querles Lhe source daLa uslng an C8uL8 8? clause. lor Lhls reason, a separaLe measure group ls
requlred for each dlsLlncL counL measure (SSAS generaLes a query for each parLlLlon/measure group). 1hls
Lechnlque requlres a long processlng Llme and places sLralns on Lhe source 8u8MS when Lhe cube ls fully
processed (assumlng no lncremenLal updaLe). Moreover, SSAS has a relaLlvely slow response Llme when Lhe
end user querles Lhe dlsLlncL counL measure due Lo Lhe speclflc meLhod of querylng Lhe dlsLlncL counL
measure.
Looklng aL daLa ln a creaLlve way, lnsLead of uslng Lhe uuM naLlve dlsLlncL counL supporL, we can bulld an
alLernaLlve model based on many-Lo-many relaLlonshlps LhaL produces Lhe same resulLs buL wlLh
poLenLlally fasLer processlng Llmes and equlvalenL or even fasLer response Llmes.
As esLabllshed by Lhe whlLepaper
http://www.microsoft.com/downloads/details.aspx?FamilyID=3494E712-C90B-4A4E-
AD45-01009C15C665&displaylang=en
Lhe performance of many-Lo-many ls dlrecLly relaLed Lo Lhe row counL ln Lhe lnLermedlaLe measure group.
So replaclng a dlsLlncL counL measure wlLh a works besL when you are deallng wlLh low cardlnallLy dlsLlncL
counLs (e.g. dlsLlncL employee counL, raLher Lhan dlsLlncL web sesslons counL). Moreover, lf you have
several dlsLlncL counL measures over Lhe same facL Lable, leveraglng Lhe many-Lo-many dlsLlncL counL
Lechnlque wlll save you from havlng Lo process Lhe mulLlple coples of LhaL measure group.
1he usage of many-Lo-many relaLlonshlps ls parLlcularly advanLageous when you wanL Lo bulld a dlsLlncL
counL on a slowly changlng dlmenslon (SCu) dlmenslon.
BUSINESS SCENARIO
MarkeLlng analysls ofLen requlres dlsLlncL counL measures for cusLomers and producLs sold. 1hese
measures are lmporLanL Lo evaluaLe averages as sales for dlsLlncL cusLomer, sales for dlsLlncL producL, and
so on.
lor slmpllclLy, we deflne a relaLlonal schema wlLh only Lwo dlmenslons: uaLe and CusLomers. 1o descrlbe
beLLer Lhe changlng seL of aLLrlbuLes relaLed Lo lL, we creaLed Lhe CusLomers dlmenslon as a slowly
changlng dlmenslon (SCu). We show Lhe relaLlonal model ln llgure 37. lor Lhe sake of slmpllclLy,
dlmenslons here have only Lhe essenLlal aLLrlbuLes. A real model would have many more aLLrlbuLes LhaL
would [usLlfy Lhe presence of a 1ype ll SCu for CusLomers.
www. sql bi . com


34 The Many-to-Many Revolution

Figure 37 Relational model with slowly changing dimension (SCD) Type II
As we have an SCu dlmenslon, we need a dlsLlncL counL of cusLomers applled Lo Lhe CCu_CusLomer
aLLrlbuLe and noL Lo Lhe lu_CusLomer surrogaLe key. We wlll analyze several posslble lmplemenLaLlons LhaL
provlde Lhe deslred resulLs, conslderlng boLh performance and lmpacL on Lhe relaLlonal and
mulLldlmenslonal models.
IMPLEMENTATION
We would llke Lo lnLroduce a slmpler model Lhan Lhe one based on Lhe CusLomers SCu, because lL ls
lmporLanL Lo undersLand how a many-Lo-many relaLlonshlp works when we use lL Lo obLaln a value
equlvalenL Lo a dlsLlncL counL measure.
ln order Lo do LhaL, we wlll conslder Lhe slmpler relaLlonal model lllusLraLed ln llgure 38: ulm_CusLomers ls
a 1ype l SCu. ?ou wlll noLlce LhaL we removed all Lhe deLall noL requlred for Lhe example.

Figure 38 Relational model without SCD (or SCD Type I)

Dim_Date
PK ID_Date
U1 Date
Fact_Sales
PK ID_Sales
FK2 ID_Date
FK1,FK3 ID_Customer
Quantity
Amount
Dim_Customers (SCD)
PK ID_Customer
U1 COD_Customer
CustomerName
ScdState
U1 ScdStartDate
ScdEndDate
Dim_Customers
PK ID_Customer
U1 COD_Customer
CustomerName
Dim_Date
PK ID_Date
U1 Date
Fact_Sales
PK ID_Sales
FK2 ID_Date
FK1,FK3 ID_Customer
Quantity
Amount

The Many-to-Many Revolution 35

We can easlly bulld a cube wlLh Lhe Lwo dlmenslons and sLandard measures (Sum of CuanLlLy, Sum of
AmounL and lacL Sales CounL). As you can see ln llgure 39, we added a ?ear aLLrlbuLe Lo Lhe uaLe
dlmenslon (calculaLed as ?LA8(uaLe)) and a ulsLlncL CounL of lu_CusLomer (we called lL CusLomers ulsLlncL
CounL ln Lhe ulsLlncL CusLomers measure group).

Figure 39 Regular distinct count cube model
ln llgure 39, you can look aL sample daLa loaded lnLo Lhe daLa marL. noLe LhaL ulm_CusLomers has nlne
cusLomers, numbered from CusLomer 1 Lo CusLomer 9.
Date Customer uant|ty Amount
01/01/2006 CusLomer 3 20 493.67
01/01/2006 CusLomer 3 3 6438.27
01/01/2006 CusLomer 6 7 7330.34
02/01/2006 CusLomer 3 28 2201.90
02/01/2006 CusLomer 3 23 911.03
06/01/2006 CusLomer 9 3 6342.61
07/01/2006 CusLomer 6 20 3437.42
10/01/2006 CusLomer 1 1 1084.36
10/01/2006 CusLomer 6 2 1000.29
10/01/2006 CusLomer 9 20 9319.23
Tabl e 5 Fact_Sal es sampl e data
llgure 40 shows Lhe plvoL Lable resulLs. We have only flve dlsLlncL cusLomers who made 10 sale
LransacLlons. 1he plvoL Lable shows also Lhe numbers aL Lhe day level (lowesL graln) of Lhe daLe dlmenslon.
www. sql bi . com


36 The Many-to-Many Revolution

Figure 40 Regular distinct count results
now, we can add a measure LhaL counLs Lhe number of rows ln ulm_CusLomers and Lhen comparlng Lhe
resulLs. We conflgure Lhe new Measure dlalog box as shown ln llgure 41.

Figure 41 New Measure based on Count of Rows of Dim_Customers
llgure 42 shows Lhe updaLed cube sLrucLure afLer renamlng Lhe measure.

The Many-to-Many Revolution 37


Figure 42 Customers Count added to cube model
AL Lhls polnL, we need Lo deflne a relaLlonshlp beLween Lhe CusLomers measure group and Lhe cube
dlmenslons: lf we dld noL, Lhe reporL would show Lhe LoLal row counL of all rows ln ulm_CusLomers for any
query we wlll do. 1o avold Lhls, we use Lhe ulmenslon usage dlalog Lo seL up a many-Lo-many relaLlonshlp
wlLh Lhe uaLe dlmenslon uslng lacL Sales as Lhe lnLermedlaLe measure group (see llgure 43).

Figure 43 Many-to-Many rel ationship between Customers and Date
now, we can compare Lhe CusLomer CounL produced by Lhe many-Lo-many relaLlonshlp wlLh Lhe
CusLomers ulsLlncL CounL obLalned wlLh Lhe regular ulsLlncL CounL aggregaLe funcLlon. As llgure 44 shows,
Lhe numbers are Lhe same regardless of Lhe selecLed daLe, buL Lhe Crand 1oLals are dlfferenL. 1he reason ls
LhaL ln absence of a uaLe selecLlon Lhere ls no need Lo apply a fllLer on CusLomers based on Lhe many-Lo-
many relaLlonshlp wlLh Lhe uaLe dlmenslon. 1herefore, we have a value of 3 for CusLomers ulsLlncL CounL
and 9 for CusLomers CounL.
www. sql bi . com


38 The Many-to-Many Revolution

Figure 44 Customers Count compared to Customers Distinct Count
?ou mlghL Lhlnk LhaL Lhe CusLomer CounL column ls useless because lL ls noL conslsLenL wlLh Lhe CusLomers
ulsLlncL CounL measure. Powever, mosL of Lhe Llme, a query lncludes a selecLlon of an lnvolved dlmenslon.
lf we use Lhe ?ear aLLrlbuLe lnsLead of Lhe uaLe aLLrlbuLe, we see Lhe lnLeresLlng daLa ln llgure 43.

Figure 45 Use of Year attribute instead of Date attribute
1he ?ear 2006 ls exacLly whaL we are lnLeresLed ln. lf you conslder LhaL we usually need Lo counL Lhe
cusLomer only lf he dld aL leasL one sale LransacLlon overall (we assume LhaL a cusLomer ls noL a prospecL),
Lhen lL should be reasonable Lo expecL LhaL Lhe CusLomers CounL measure ls ln pracLlce Lhe same as Lhe
CusLomers ulsLlncL CounL measure.

Figure 46 Customers dril l through for standard distinct count measure
Some modelers mlghL favor Lhe use of many-Lo-many relaLlonshlps Lo deflne a dlsLlncL counL measure [usL
for a slmple feaLure you obLaln as a slde effecL. lf we deflne a drlllLhrough acLlon (named CusLomers ln our
case) Lo geL Lhe llsL of cusLomers behlnd a glven cell, we wlll geL Lhe resulLs shown ln llgure 46 afLer drllllng
Lhrough Lhe CusLomers ulsLlncL CounL measure for 2006. ln comparlson, llgure 47 shows Lhe same
drlllLhrough resulLs for Lhe CusLomers CounL measure for 2006.
Pere, we obLaln Lhe llsL of dlsLlncL cusLomers whlle Lhls ls noL Lhe case wlLh Lhe CusLomers ulsLlncL CounL
measure (see llgure 46 agaln). lf you use a dlsLlncL counL measure, conslder a dlsLlncL fllLer on Lhe
drlllLhrough resulLs Lo ellmlnaLe dupllcaLed cusLomers. 1hls ls noL necessary wlLh a many-Lo-many

The Many-to-Many Revolution 39

relaLlonshlp. 1he reason for Lhls behavlor ls LhaL Lhe drlllLhrough acLlon on Lhe CusLomers ulsLlncL CounL
measure wlll reLurn Lhe llsL of LransacLlons made by Lhose cusLomers. lnsLead of Lhls, Lhe drlllLhrough
acLlon on Lhe CusLomer CounL measure wlll reLurn Lhe llsL of cusLomers fllLered from Lhe brldge Lable of our
many-Lo-many relaLlonshlp.

Figure 47 Customers dril l through for Customers Count (obtained by many-to-many
relationship)
We are ready Lo lnLroduce Lhe slowly changlng dlmenslon ln Lhls scenarlo. When evaluaLlng Lhe dlsLlncL
counL of cusLomers ln a 1ype ll SCu who have made a LransacLlon, we cannoL rely on Lhe dlsLlncL counL of
Lhe cusLomer surrogaLe key ln Lhe facL dlmenslon.
1hree feaslble soluLlons are as follows:
So|ut|on A. CreaLe a unlque cusLomer dlmenslon: Lhls means dupllcaLlng Lhe cusLomer
dlmenslon, aL leasL for Lhe mosL recenL verslon of each member
So|ut|on 8. CreaLe a ulsLlncL CounL measure on Lhe appllcaLlon key of Lhe cusLomer dlmenslon:
Lhe measure ls deflned lnLo a measure group LhaL has slmllar relaLlonshlp Lo Lhe one we [usL
used Lo evaluaLe Lhe cusLomer counL measure Lhrough a many-Lo-many relaLlonshlp
So|ut|on C. ueflne a soluLlon LhaL ls slmllar Lo soluLlon 8, subsLlLuLlng Lhe dlsLlncL counL
measure wlLh anoLher counL measure derlved from a many-Lo-many relaLlonshlp
Lach one of Lhese soluLlons has lLs poslLlve and negaLlve aspecLs. 1o LesL all of Lhese cases, we need Lo
modlfy our daLa. 1able 6 shows LhaL CusLomer 6 has Lwo verslons (lL changed on 03/01/2006). lor Lhls
reason, we have sLlll 9 cusLomers buL 10 dlfferenL rows ln ulm_CusLomers, and we have 3 dlfferenL
cusLomers who made LransacLlons buL 6 dlfferenL cusLomer surrogaLe keys referenced ln Lhe facL Lable.
Date Customer uant|ty Amount
01/01/2006 CusLomer 3 20 493.67
01/01/2006 CusLomer 3 3 6438.27
01/01/2006 CusLomer 6 v1 7 7330.34
02/01/2006 CusLomer 3 28 2201.90
02/01/2006 CusLomer 3 23 911.03
06/01/2006 CusLomer 9 3 6342.61
07/01/2006 CusLomer 6 v2 20 3437.42
10/01/2006 CusLomer 1 1 1084.36
10/01/2006 CusLomer 6 v2 2 1000.29
10/01/2006 CusLomer 9 20 9319.23
Tabl e 6 Fact_Sal es SCD sampl e data
www. sql bi . com


40 The Many-to-Many Revolution
llgure 48 shows Lhe new uaLa Source vlew. lL uses addlLlonal vlews LhaL slmulaLe whaL we could have
achleved by modlfylng Lhe relaLlonal schema of our uaLa MarL. When Lo use vlews agalnsL maLerlallzed
Lables ls anoLher Loplc by lLself, whlch we have Lo evaluaLe conslderlng Lhe processlng Llme, Lhe number of
dlsLlncL counL measures and Lhe complexlLy of exlsLlng L1L processes (we should modlfy Lhem lf we change
Lhe daLa marL schema). 1he vlew vlacL_Sales_unlque adds Lhe CCu_CusLomer aL Lhe facL Lable level, whlch
ls necessary Lo lmplemenL SoluLlon A. SoluLlon 8 does noL need any new elemenLs. 1o lmplemenL SoluLlon
C we have Lo add Lwo vlews: vulm_CusLomersunlque slmulaLes a cusLomer dlmenslon conLalnlng only a
unlque row for cusLomers (wlLhouL changlng aLLrlbuLes), vCusLomersScd slmulaLes a brldge Lable LhaL [olns
each unlque cusLomer member (vulm_CusLomersunlque) wlLh lLs verslons (ulm_CusLomers).

Figure 48 Data Source View to implement different distinct count strategies
ln Lhe slmplesL scenarlo (SoluLlon A), we creaLe a unlque cusLomer ld aL Lhe facL Lable level and Lhen deflne
a dlsLlncL counL measure on lL. llgure 49 shows LhaL we could have used vlacL_Sales_unlque vlew Lo bulld
boLh lacL Sales measure group measures and Lhe A CounL measure on Lhe A CusLomers measure group.
Powever, Lhere ls no beneflL on dolng so. A dlsLlncL counL measure needs a dedlcaLed measure group (A
CusLomers) LhaL SSAS wlll process wlLh a separaLed query Lo Lhe facL Lable. ln Lhls case, we wanL Lo llmlL Lhe
[oln beLween lacL_Sales and ulm_CusLomers only for Lhe CCu_CusLomer dlsLlncL counL evaluaLlon. lrom
Lhls polnL of vlew, we could ellmlnaLe Lhe oLher measures (CuanLlLy and AmounL) from
vlacL_Sales_unlque. 1hls ls only an aesLheLlc Louch wlLhouL lmprovemenLs on Lhe performance slde, buL lL
makes a loL of sense from Lhe malnLenance polnL of vlew and ln order noL Lo confuse people wlLh Lwo
coples of Lhe same Lable.

The Many-to-Many Revolution 41


Figure 49 Case A with standard distinct count measure on fact tabl e
Cnce we creaLed Lhe A CusLomers measure group, we need Lo relaLe lL Lo cube dlmenslons, as shown ln
llgure 30. 1he relaLlonshlps are very slmple and ldenLlcal Lo Lhose wlLh oLher measure groups.

Figure 50 Case A Dimension Usage
We can look aL resulLs obLalned wlLh A CounL measure (llgure 31). 1he CusLomers ulsLlncL CounL measure
ls 6 for 2006 because lL counLs Lhe number of rows ln ulm_CusLomers, we have Lwo verslons for CusLomer
6 (v1 and v2) so lL ls counLed Lwlce here. 1he new A CounL measure has Lhe rlghL number of 3 and lL ls Lhe
number we wanL Lo see.

Figure 51 Case A resul ts


www. sql bi . com


42 The Many-to-Many Revolution
AlLhough we have solved Lhe buslness problem, we could face some performance lssues, whlch we wlll
dlscuss furLher ln Lhe erformance secLlon. Powever, lL ls necessary Lo noLe someLhlng here:
SSAS wlll obLaln A ulsLlncL CounL measure Lhrough an C8uL8 8? query LhaL uses Lhe measure
expresslon as Lhe key Lo sorL.
1he appllcaLlon key we are uslng Lo evaluaLe Lhe dlsLlncL counL could be a long sLrlng. We have
Lo handle lL ln Lhe cube, even lf lL ls noL lnLeresLlng Lo Lhe end user.
We used a vlew Lo avold dupllcaLlng cusLomer dlmenslon daLa ln a CusLomers unlque
dlmenslon, buL Lhls vlew conLalns a [oln and wlll be querled uslng an C8uL8 8? clause. 1hls
could be very heavy on large facL Lables and large dlmenslons.
ulsLlncL CounL measures on Analysls Servlces 2003 are noL very scalable when Lhe slze of daLa
grows. SLarLlng from 2008 forward, Lhe algorlLhm has been lmproved buL lL sLlll requlres a
careful plannlng of Lhe parLlLlons Lo provlde fasL parallel compuLaLlon of dlsLlncL counLs.
SoluLlon 8 sLlll uses a dlsLlncL measure, buL Lhls Llme we do noL use a vlew. lnsLead, we rely on Lhe uuM
facL dlmenslon feaLure. llgure 32 shows LhaL Lhe 8 CounL measure on a dlsLlncL counL of Lhe
CCu_CusLomer fleld ln ulm_CusLomers Lable (LhaL ls used boLh as a dlmenslon and as a facL Lable).

Figure 52 Case B with distinct count measure on customer dimension
1he 8 CusLomers measure group has a dlrecL relaLlonshlp wlLh Lhe CusLomers dlmenslon (Lhe relaLlonshlp
Lype ls lacL") and a many-Lo-many relaLlonshlp wlLh uaLe dlmenslon vla Lhe lacL Sales measure group.
ApparenLly, Lhls ls a sLrange relaLlonshlp because a row ln ulm_CusLomers as facL Lable has a one-Lo-one
relaLlonshlp wlLh ulm_CusLomers as CusLomers dlmenslon (lL ls Lhe same Lable!). Powever, Lhe reallLy ls
LhaL each cusLomer can be relaLed Lo many daLes and each daLe can be relaLed Lo many cusLomers, and
lacL_Sales deflnes exacLly Lhls relaLlonshlp. llgure 33 shows Lhe resulLlng ulmenslon usage.

The Many-to-Many Revolution 43


Figure 53 Case B Dimension Usage
AL Lhe end, we have slmllar resulLs Lo Lhose obLalned wlLh SoluLlon A: llgure 34 shows Lhe 8 counL resulLs.
1he only dlfference ls LhaL when Lhere ls no fllLer on uaLe dlmenslon (Lhe Crand 1oLal row) Lhe 8 counL
shows Lhe overall number of unlque cusLomers lnsLead of conslderlng only Lhe cusLomers who made aL
leasL one LransacLlon. We already dlscussed Lhls ln Lhe conLexL of Lhe prevlous scenarlo when we dld noL
have a slowly changlng dlmenslon for CusLomers.

Figure 54 Case B resul ts
WhaL ls Lhe blggesL dlfference beLween SoluLlon A and SoluLlon 8? ln SoluLlon A, we had Lo bulld a vlew (or
a perslsLed dlmenslon Lable) Lo llnk Lhe unlque cusLomers dlmenslon Lo Lhe lacL_Sales Lable. ln SoluLlon 8,
we do noL need lL. SSAS makes Lhe processlng query only agalnsL Lhe cardlnallLy of ulm_CusLomers Lable
and noL agalnsL Lhe cardlnallLy of Lhe more populaLed lacL_Sales Lable. 1hls mlghL resulL ln slgnlflcanLly
beLLer performances.
ln SoluLlon C, we apply Lhe lesson we learned aL Lhe beglnnlng of Lhls chapLer, when we used a many-Lo-
many relaLlonshlp Lo geL Lhe same resulLs of a dlsLlncL counL measure. ln Lhls way, we wlll remove Lhe need
for a dlsLlncL counL measure and relaLed lmpllcaLlons.
llgure 33 shows LhaL Lhe model becomes relaLlvely more complex. We need Lo bulld a facL dlmenslon
(vulm_CusLomersunlque) where Lhe number of rows equals Lhe number of unlque CusLomers we have.
unforLunaLely, we cannoL exLend Lhe model we prevlously deflned for SoluLlon 8 because Lhe facL
dlmenslon we used (ulm_CusLomers) cannoL serve as an lnLermedlaLe measure group ln a many-Lo-many
relaLlonshlp. lor Lhls reason, we creaLed a vlew (vCusLomersScd) LhaL serves as a brldge Lable beLween
ulm_CusLomers and vulm_CusLomersunlque.
www. sql bi . com


44 The Many-to-Many Revolution

Figure 55 Case C with distinct count measure by many-to-many relationship
1he CusLomers SCu measure group has a row for each row ln ulm_CusLomers, wlLh a one-Lo-one
relaLlonshlp. 1he C CusLomers measure group has a row for each unlque cusLomer. 1o deflne a relaLlonshlp
beLween Lhese Lwo measure groups, lL ls necessary Lo have a dlmenslon shared by boLh measure groups.
1hls role ls fulfllled by Lhe CusLomersunlque dlmenslon, whlch has Lhe same cardlnallLy as C CusLomers.
Whlle we can ldenLlfy a one-Lo-many relaLlonshlp beLween Lhe CusLomers SCu and C CusLomers measure
group, a beLLer approach ls Lo leverage Lhe uuM many-Lo-many relaLlonshlp.
1he CusLomers SCu measure group plays a very lmporLanL role llnklng Lhe C CusLomers measure group wlLh
all Lhe oLher measure groups of a cube. llgure 36 shows Lhe ulmenslon usage seLup requlred Lo lmplemenL
case C.

Figure 56 Case C Dimension Usage
1he CusLomersunlque dlmenslon plays an lmporLanL role ln Lhe deflnlLlon of Lhe correcL relaLlonshlp
beLween measure groups. neverLheless, lLs conLenL may noL be useful for end user reporLlng. lor Lhls
reason, lL ls ofLen convenlenL Lo hlde Lhls dlmenslon from end users.
AnoLher lnLeresLlng aspecL ls LhaL Lhe CusLomersunlque dlmenslon has Lhe cusLomer appllcaLlon key as a
prlmary key of Lhe dlmenslon. lf Lhe appllcaLlon key (CCu_CusLomer, ln Lhls case) ls very long, lL could
become a poLenLlal performance boLLleneck and lL wlll consume more space for daLa sLorage. ln real
pro[ecL, we ofLen use a perslsLenL dlmenslon Lable lnsLead of a vlew, [usL Lo geL a surrogaLe key (of Lype

The Many-to-Many Revolution 45

lnLeger) lnsLead of Lhe large appllcaLlon key (more Lhan 20 characLers) we geL from Lhe CL1. llgure 37
shows Lhe resulLs.

Figure 57 Case C resul ts
Whlle Lhe CusLomer SCu CounL measure ls noL useful, Lhe C CounL behaves exacLly as Lhe 8 CounL measure.
As we sald before, lL ls lnLeresLlng Lo conslder Lhe lmplemenLaLlon of Lhe dlsLlncL counL measures wlLh
many-Lo-many relaLlonshlps ln order Lo galn performance lmprovemenLs. ln Lhe nexL pages, we wlll look aL
performances.
PERFORMANCE
1here are Lwo maln observable dlfferences when we query a cube LhaL has dlsLlncL counL measures
obLalned wlLh dlfferenL meLhods:
usage of more processors and l/C
LffecLlveness ln cachlng Lhe query resulLs
1o undersLand performance lmpacL, we have Lo undersLand how Analysls Servlces resolves querles for
Lhese klnds of measures.
A classlcal" dlsLlncL counL measure works ln Lhls way:
AL processlng Llme, SSAS adds an C8uL8 8? clause Lo Lhe query senL Lo Lhe relaLlonal englne for
each cube parLlLlon Lo order daLa by Lhe dlsLlncL counL measure expresslon. ln Lhe besL-case
scenarlo, you do noL have [olns beLween Lhe facL Lable and oLher Lables, buL when you have
mllllons of rows Lhe C8uL8 8? clause could be very slow and lL may requlre many resources
(memory and dlsk for Lemporary Lable).
noLe LhaL Lhls affecLs Lhe performance of Lhe relaLlonal englne. 1he processlng Llme of dlsLlncL
counL measures could be very long. Powever, lL can be lmproved uslng lncremenLal updaLes
raLher Lhan processlng Lhe enLlre cube (lullrocess opLlon).
1hls explalns why Lhe ulsLlncL CounL measure needs a separaLe measure group ln uuM.
Cur hypoLhesls ls LhaL SSAS dedlcaLes an lndex for a dlsLlncL counL measure and Lhe correcL
order of lLems ls necessary Lo use a memory-efflclenL algorlLhm.
AL query Llme, SSAS makes a sequenLlal scan of Lhe dlsLlncL counL parLlLlon for each query
lnvolvlng a dlsLlncL counL measure. Cuery response Llme depends on boLh Lhe number of rows
ln Lhe facL Lable and Lhe number of dlfferenL dlsLlncL values of Lhe measure.
www. sql bi . com


46 The Many-to-Many Revolution
lor some reason, SSAS cannoL enLlrely cache Lhe query and a subsequenL query conLalnlng a
dlsLlncL counL measure requlres more or less Lhe same Llme (probably Lhe Llme lmprovemenL
depends from Lhe ellmlnaLlon of dlsk l/C wlLh all necessary daLa already ln server memory).
Lven a full measure group opLlmlzaLlon (bulldlng 100 of posslble aggregaLlon) does noL
lmprove slgnlflcanLly Lhls Lype of querles.
A measure lnvolvlng a many-Lo-many relaLlonshlp works as follows:
AL processlng Llme, SSAS reads Lhe brldge Lable used by Lhe many-Lo-many relaLlonshlp ln no
parLlcular order (llke a regular facL Lable). 1here ls no pressure on Lhe relaLlonal englne even
wlLh mllllons of rows. neverLheless, as a many-Lo-many relaLlonshlp relaLes members of Lwo
dlfferenL dlmenslons, lL should be rare Lo have more Lhan 10 mllllon rows Lo process.
AL query Llme, SSAS reads Lhe facL Lable lnLo memory Lo evaluaLe Lhe many-Lo-many
relaLlonshlp Lhrough Lhe brldge measure group. lL does so malnly Lo [oln Lhe Lwo measure
groups aL query Llme and lL needs Lo [oln Lhem aL Lhe lowesL level of each dlmenslon (common
Lo boLh measure groups). AggregaLlons aL Lhe proper granularlLy level mlghL lmprove
performance, reduclng Lhe number of rows consldered, accordlng wlLh Lhe sllcers used ln a
query.
1he englne does a hash [oln for Lhls purpose (unllke Lhe SCL Server query englne, Analysls
Servlces does noL have mulLlple [oln algorlLhms Lo choose from). 1he hash [oln does a lookup
on Lhe brldge measure group (or Lo one of lLs aggregaLlon lf posslble, ln order Lo reduce Lhe
workload), bullds a hash lndex on lL, scans Lhe facL measure group and comblnes Lhe Lwo
resulLs LogeLher.
As you can lmaglne, Lhls operaLlon requlres enough vlrLual memory Lo load and evaluaLe Lhe
daLaseLs. 1he resoluLlon of Lhe [oln can exhausLs Lhe Lwo glgabyLes addressable memory space
ln a 32-blL sysLem. A 64-blL sysLem does noL exhausL Lhe vlrLual memory, buL lL ls lmporLanL
LhaL enough physlcal 8AM ls avallable Lo avold paglng of memory. lf Lhe memory ls enough, Lhe
flrsL query may be very slow, whlle ln a Lwo glgabyLes user memory address space a facL Lable
wlLh 100 mllllon rows [olned Lo an lnLermedlaLe measure group wlLh 1 mllllon rows could fall
Lhe query exhausLlng Lhe address space of Lhe Analysls Servlces process. lL could be very slow
Lhe flrsL Llme, buL subsequenL querles are very fasL (lmmedlaLe response) because Analysls
Servlces caches very well prevlous resulLs.
Conslder LhaL Lhe crlLlcal condlLlon for Lhe memory usage ls a comblnaLlon of slzes of Lhe Lwo
Lables, a small brldge Lable consumes less memory Lhan a large one applled Lo Lhe same 100
mllllon rows facL Lable. ?ou can apply Lhe Lechnlques descrlbed ln Lhe Analysls Servlces Many-
Lo-Many ulmenslons: Cuery erformance CpLlmlzaLlon 1echnlques" whlLepaper (see Llnks
secLlon).
unforLunaLely, Lhese Lwo Lechnlques Lo calculaLe a dlsLlncL counL measure (Lhe classlc" one and Lhe one
based on many-Lo-many dlmenslon relaLlonshlps) have boLh some shorLcomlngs. lf we could warm up Lhe
cache afLer cube processlng (for example by execuLlng a scheduled Mux query), users would probably favor
Lhe performance of a dlsLlncL counL measure based on many-Lo-many relaLlonshlps. 1haL ls because each
Llme Lhe end user changes a selecLlon or a fllLer wlLh Lhe classlc" model, Lhe user wlll experlence
performance degradaLlon. ConsequenLly, lnLeracLlve reporLs Lyplcally run fasLer wlLh Lhe many-Lo-many
relaLlonshlp Lechnlque. 1he performance degradaLlon assoclaLed wlLh Lhe classlc" dlsLlncL counL model ls a
mlnor lssue wlLh sLaLlc reporLs, especlally wlLh 8eporLlng Servlces cached reporLs.

The Many-to-Many Revolution 47

1he real problem wlLh uslng many-Lo-many relaLlonshlp ls Lhe llmlL of facL Lable rows you can query. We
should evaluaLe carefully Lhe use of many-Lo-many relaLlonshlps when you have lnLermedlaLe measure
groups geLLlng daLa from facL Lable wlLh more Lhan 1 mllllon of rows. 8efer Lo many-Lo-many opLlmlzaLlon
whlLepaper ln Lhe Llnks secLlon.
llnally, please conslder we compared Lhe classlcal ulsLlncL CounL measure wlLhouL a parLlcular
opLlmlzaLlon. ?ou should look aL Lhe Analysls Servlces ulsLlncL CounL CpLlmlzaLlon whlLe paper (see Llnks
secLlon) ln order Lo know how Lo opLlmlze Lhe regular dlsLlncL counL measure. lL could be expenslve aL
processlng Llme, buL lL can lmprove performance aL query Llme more Lhan you can Lo wlLh Lhe many-Lo-
many relaLlonshlp approach.
www. sql bi . com


48 The Many-to-Many Revolution
Multiple groups
8l users Lend Lo love freedom, Lhls ls a facL of reallLy. Among all Lhe oLher klnds of freedom Lhey llke, a very
frequenL one ls Lhe ablllLy Lo group lLems from dlmenslons ln dlverse and unpredlcLable ways, ln order Lo
have Lhelr speclflc way of looklng aL dlmenslon members.
We bulld aLLrlbuLes Lo help Lhem ln aggregaLlng dlmenslon members buL, ln a Lyplcal cube dlmenslon, we
deflne aLLrlbuLes aL Lhe daLa warehouse's deslgn sLage. Addlng an aLLrlbuLe ls an operaLlon LhaL requlres
changes ln all layers of Lhe 8l soluLlon.
Whlle a rlgld deslgn ls good for performance opLlmlzaLlon, Lhls ls a severe llmlLaLlon for end users llke
markeLlng analysLs, who Lry Lo [ump over Lhese llmlLs by exLracLlng daLa from Lhe daLa warehouse, worklng
wlLh Lhem offllne. 1hey need Lo make cusLom groups of dlmenslon elemenLs based on some characLerlsLlcs
LhaL Lhey dld noL known before and LhaL probably wlll change over Llme.
1here are many examples of Lhls slLuaLlon, buL we can generallze lL by assumlng LhaL a user may wanL Lo
group some dlmenslon members LogeLher, assoclaLlng Lhem wlLh a group name. Moreover, a slngle
dlmenslon member mlghL belong Lo several groups.
1he MulLlple Croups" model we are golng Lo lnLroduce has an lnLeresLlng characLerlsLlc: we wlll base lL on
a flxed relaLlonal and mulLldlmenslonal schema, and Lhe user wlll be able Lo deflne new groups uslng a daLa
drlven meLhodology. Moreover, groups are lmmedlaLely avallable Lo all cllenLs and a new group can be
added by only reprocesslng a small measure group (correspondlng Lo Lhe brldge Lable for a many-Lo-many
relaLlonshlp), glvlng Lhe opporLunlLy Lo creaLe soluLlons LhaL enable a user Lo creaLe cusLom groups on Lhe
fly.
BUSINESS SCENARIO
1yplcally, sales analysls lnvolves Lhe creaLlon of speclflc groups of cusLomer and producL dlmenslon
members. 1hese groups can be based on evenLs (e.g. who has been lncluded ln a mall campalgn), on
proflllng analysls (e.g. could be Lhe resulL of a manual segmenLaLlon or a daLa mlnlng clusLerlng model) or
on oLher arblLrary daLa.
1he classlcal approach for cusLom grouplng ls Lo deflne a Lable for each Lype of group, wlLh a fleld for each
group aLLrlbuLe and a fleld for cusLomer key. 1he Lable wlll conLaln a row for each cusLomer LhaL belongs Lo
each group.
lor example, lmaglne LhaL we need Lo segmenL cusLomers wlLh some proflle and wanL Lo Lrack cusLomers
who recelved malllng offers for our producLs: llgure 38 shows a canonlcal soluLlon LhaL uses a separaLe
Lable for each klnd of group.

The Many-to-Many Revolution 49


Figure 58 Mul tipl e grouping made with a tabl e for each kind of group
We could lmplemenL a correspondlng uuM wlLh Lhe CusLomer dlmenslon relaLed Lo CusLomerroflle and
CusLomerMalllng dlmenslons wlLh Lwo dlfferenL many-Lo-many relaLlonshlps. 1he key polnL here ls LhaL lf a
cusLomer could belong Lo more Lhan one group, we need Lo go for many-Lo-many relaLlonshlps.
AL Lhls polnL, a more normallzed and uuM-frlendly way Lo handle Lhls scenarlo ls shown ln llgure 39.

Figure 59 Mul tipl e grouping with expl icit many-to-many relationships
1hls model allows us Lo use a slngle group" dlmenslon Lable for any klnd of grouplng, buL lL does noL glve
us enough flexlblllLy: lf a new group requlres a new Lable ln Lhe daLa warehouse, lL wlll also requlre changes
Lo Lhe L1L processes and uuM.
IMPLEMENTATION
A poLenLlal weakness of Lhe model (see llgure 39) resldes ln Lhe cusLomer-proflllng requlremenL. ln Lhe real
world, we can have many proflles, buL for each proflle, a cusLomer can have only one raLlng (or no raLlng aL
all). unforLunaLely, we cannoL lmplemenL Lhls requlremenL wlLh a consLralnL ln Lhe relaLlonal daLabase. Cne
way Lo lmplemenL Lhls level of conLrol on Lhe model shown ln llgure 38 would be a unlque lndex on Lhe
rofllename and lu_CusLomer flelds. Powever, daLa lnLegrlLy ls ouL of our scope here. AfLer all, a daLa marL
Dim_Customers
PK ID_Customer
I1 COD_Customer
Customer
Dim_Date
PK ID_Date
I1 Date
Fact_Balance
PK ID_Sale
FK1 ID_Customer
FK2 ID_Date
Amount
Dim_CustomerMailing
PK ID_CustomerMailing
FK1 ID_Customer
Mailing
Dim_CustomerProfile
PK ID_CustomerProfile
FK1 ID_Customer
ProfileName
ProfileRating
Fact_Balance
PK ID_Sale
FK1 ID_Customer
FK2 ID_Date
Amount
Dim_Customers
PK ID_Customer
I1 COD_Customer
Customer
Dim_Date
PK ID_Date
I1 Date
Dim_Mailing
PK ID_Mailing
Mailing
Dim_Profile
PK ID_Profile
ProfileName
ProfileRating
Factless_CustomerMailing
PK ID_CustomerMailing
FK1 ID_Mailing
FK2 ID_Customer
Factless_CustomerProfile
PK ID_CustomerProfile
FK1 ID_Profile
FK2 ID_Customer
www. sql bi . com


50 The Many-to-Many Revolution
has Lo be loaded wlLh correcL daLa and we wlll delegaLe Lhls check responslblllLy Lo Lhe L1L plpellne, buL we
wlll see LhaL Lhls noLe wlll be lmporLanL ln our flnal conslderaLlons for Lhls scenarlo.
lf we conslder Lhe whole scenarlo, we can ldenLlfy Lhese requlremenLs:
A cusLomer can belong Lo many groups
A group can have many cusLomers
A group can have a characLerlsLlc name and a value" LexLual aLLrlbuLe (see llgure 60).
lease noLe LhaL ln Lhe nexL lmplemenLaLlon CCu_Croupname and CCu_Croupvalue flelds are appllcaLlon
keys LhaL we wlll use Lo lmplemenL grouplng.

Figure 60 Mul tipl e grouping with a generic fl exibl e model
SomeLlmes we can use Lhe group name as a sorL of group caLegory and Lhe group value as Lhe real group
name. CLher Llmes, we can use Lhe group value for segmenLlng Lhe group populaLlon. 1able 7 shows boLh
varlanLs. 1he Malllng group name ldenLlfles a caLegory of malllngs and a cusLomer could belong Lo any
(even all) of Lhe posslble groups deflned by Croup value (ln Lhls example, romo Sprlng and romo lall are
Lwo malllngs we have made Lo Lwo dlfferenL and parLlally overlapplng groups of cusLomers). 1he roflle
group name ldenLlfles a slngle group where each cusLomer musL belong Lo only one of Lhe posslble group
values: 8eLall, AffluenL, rlvaLe or CorporaLe.
Group Name Group Va|ue
Malllng romo Sprlng
Malllng romo lall
roflle 8eLall
roflle AffluenL
roflle rlvaLe
roflle CorporaLe
Tabl e 7 Groups dimension sampl e data
1he lnLeresLlng parL ls LhaL addlng a new group does noL requlre any sLrucLural change ln Lhe model. lor
example, a new romo WlnLer malllng needs only a new record ln Lhe ulm_Croups Lable and a correcL
populaLlon of Lhe 8rldge CusLomerCroup Lable: glven a new lu_Croup, lL ls only necessary Lo geL a llsL of
lu_CusLomer Lo do Lhls populaLlon.
Dim_Customers
PK ID_Customer
I1 COD_Customer
Customer
Dim_Date
PK ID_Date
I1 Date
Dim_Groups
PK ID_Group
I1 COD_GroupName
I1 COD_GroupValue
GroupName
GroupValue
Fact_Balance
PK ID_Sale
FK1 ID_Customer
FK2 ID_Date
Amount
Bridge_CustomerGroup
PK ID_CustomerGroup
FK1 ID_Customer
FK2 ID_Group

The Many-to-Many Revolution 51

We can creaLe Lhe cube wlLh Lhe auLo bulld feaLure of Lhe Cube Wlzard. 1he resulLlng model would
correcLly ldenLlfy dlmenslon and facL Lables buL, as we have seen before, we have Lo deflne manually some
of Lhe mlsslng relaLlonshlps beLween dlmenslons and measure groups.

Figure 61 Cube structure for mul tipl e grouping
As you can see ln llgure 61, we have Lwo measure groups for a LoLal of Lhree measures.
lacL 8alance CounL ls Lhe number of rows for Lhe lacL 8alance Lable.
8rldge CusLomer Croup CounL ls Lhe number of cusLomers for selecLed group(s). lrom anoLher
polnL of vlew, lL ls also Lhe number of groups Lo whlch a cusLomer belongs, dependlng on whlch
dlmenslon you are uslng Lo sllce or fllLer daLa.
lf users do noL need Lo analyze a group populaLlon, you can hlde Lhe 8rldge CusLomer Croup CounL
measure. CLherwlse, lL would be a good ldea renamlng lL Lo a more meanlngful name.

Figure 62 Cube wizard dimension usage resul ts for mul tipl e grouping
llgure 62 shows LhaL ln Lhls case only Lhe uaLe dlmenslon has Lo be relaLed Lo 8rldge CusLomer Croup. We
can flll Lhe gray cell wlLh anoLher many-Lo-many relaLlonshlp (Lhe flrsL one was creaLed by Lhe wlzard), as
shown ln llgure 63.
www. sql bi . com


52 The Many-to-Many Revolution

Figure 63 Compl eted dimension usage for mul tipl e grouping
llgure 64 shows a sample reporL uslng Lhls model. 1he fllLer ls seL on a speclflc daLe (remember LhaL Lhe
8alance AmounL ls a measure LhaL cannoL be summed over Llme), whlle Lhe Croup name and Croup value
dlmenslons are placed on Lhe rows.
1he Lwo malllng groups (romo lall and romo Sprlng) parLlally conLaln same members. ln facL, 1oLal row
for Malllng group name ls less Lhan Lhe sum of each slngle group value row. We have a dlfferenL slLuaLlon
for roflle group name. A cusLomer should belong Lo only one of Lhe posslble chlld group values, whlch ls
Lhe case wlLh our sample daLa.

Figure 64 Sampl e query for mul tipl e groups
Pavlng analyzed Lhe 8alance AmounL measure, we can apply Lhe same conslderaLlons for Lhe lacL 8alance
CounL measure. 1yplcally, lL ls used as Lhe denomlnaLor Lo geL an average amounL balance lnsLead of Lhe
LoLal balance (Sum aggregaLlon). lL ls lmporLanL Lo noLe LhaL lacL 8alance CounL could be lower Lhan 8rldge
CusLomer Croup CounL, even for a slngle Croup value row. 1hls happens when aL leasL one cusLomer
assoclaLed wlLh Lhe group has no reglsLered balance for Lhe chosen daLe.
A furLher conslderaLlon abouL 8rldge CusLomer Croup CounL measure ls LhaL lL ls aggregaLed as a regular
measure and lL has noL Lo be confused wlLh Lhe number of !"##$%$&' cusLomers belonglng Lo a group. 1hls ls
parLlcularly lmporLanL when you are conslderlng Lhe LoLal for a Croup name, grouplng all lLs Croup value
chlldren: Lhls ls anoLher good reason Lo hlde Lhls measure from end users.
Whlle lL could be posslble addlng oLher aLLrlbuLes Lo Lhe Croups dlmenslon, you have Lo be very careful ln
dolng so. lf you wanL a generlc way Lo group lLems of a dlmenslon, lL ls lmporLanL Lo leave Lhe group
dlmenslon deslgn as generlc as posslble. Addlng an aLLrlbuLe used only wlLh some speclflc groups would be
a bad way Lo make Lhlngs easy Lo use and Lo read.
A flnal conslderaLlon ls abouL Lhe overall performance. lrom a query sLandpolnL, lL ls noL posslble Lo deflne
aggregaLlons aL a group level for Lhe lacL 8alance measure group (llke any oLher many-Lo-many
relaLlonshlps, lL has Lo be evaluaLed aL query Llme). neverLheless, ln our experlence Lhe query response

The Many-to-Many Revolution 53

Llme could sLlll be accepLable for many real-world scenarlos. MosL lmporLanL, Lhls query-Llme calculaLlon
has a very poslLlve lmpacL on Lhe processlng-Llme. lf you need Lo add daLa Lo form a new group, lL ls
necessary Lo process only ulm Croups dlmenslon and 8rldge CusLomer Croup measure group and Lhese
processes can be done lncremenLally! lor Lhls reason, we suggesL LhaL you Lo conslder Lhls scenarlo even
for on-Lhe-fly modlflcaLlons of cusLom groups made by end users, wlLhouL relylng on cllenL-based soluLlons.
8emember LhaL we need L1L processes Lo updaLe and process group-relaLed sLrucLures. 1he end user
should noL be able Lo manlpulaLe Lhe ulm_Croups dlmenslon, because Lhls mlghL lead Lo lnconslsLenL daLa.
www. sql bi . com


54 The Many-to-Many Revolution
Cross-Time
AlmosL all measures ln a daLa warehouse are Llme-dependenL. 1he classlcal sLar schema has a facL Lable
LhaL conLalns numerlc measures and many dlmenslon Lables LhaL deflne Lhe graln of any slngle measure.
1hls ls a good model (especlally lf you bulld an CLA cube on lL) for analyzlng sales over a glven perlod.
neverLheless, lL does noL show how Lhe dlsLrlbuLlon of dlmenslon aLLrlbuLes changes over Llme. lor Lhls
reason, klmball's advlce ls Lo deflne a separaLe facL Lable LhaL Lake snapshoLs" of dlmenslon sLaLe over
Llme.
Powever, snapshoL facL Lables mlghL noL saLlsfy all reporLlng needs. lor example, lL ls hard Lo query for Lhe
change of an aLLrlbuLe dlsLrlbuLlon beLween Lwo daLes. We can leverage Lhe many-Lo-many relaLlonshlp
feaLure ln order Lo solve Lhe problem. We wlll call cross-Llme" Lhe Lechnlque LhaL comblnes Llme
snapshoLs" and many-Lo-many relaLlonshlps Lo enhance analysls capablllLles lnslde cllenL Lools.
BUSINESS SCENARIO
Whlle we can apply Lhe cross-Llme Lechnlque Lo any slowly changlng dlmenslon, we wlll use as a Lyplcal
scenarlo one LhaL lnvolves Lhe cusLomer dlmenslon. CusLomer aLLrlbuLes change over Llme and SCu Lracks
Lhe hlsLory changes. Powever, lL ls noL easy Lo analyze Lhe SCu changes wlLhouL a Lwo-sLep operaLlon LhaL
wlll requlre flrsL Lhe selecLlon of a seL of cusLomers wlLh cerLaln aLLrlbuLes aL a speclflc daLe and Lhen Lhe
usage of Lhls selecLlon Lo query daLa and see measures or aLLrlbuLe values on a dlfferenL daLe.
1yplcally, Lhe exlsLlng sLar schema may look llke Lhe one lllusLraLed ln llgure 63. Pere, we have a facL Lable
wlLh meanlngful measures (ln Lhls case 8alance ls a non-addlLlve measure over 1lme), a daLe dlmenslon and
a CusLomer SCu 1ype ll dlmenslon.
lease noLe LhaL we have creaLed a snowflake schema for cusLomers because Lhe appllcaLlon key ls already
ln normal form ln Lhe ulm_CusLomerunlque Lable. 1hls model also makes lL easler Lo model dlsLlncL counL
measures as we have seen before.

Figure 65 Relational star schema with unique dimension
Cur users may need Lo analyze how cusLomers have changed occupaLlon from !anuary Lo uecember 2003.
Dim_CustomerScd
PK ID_CustomerScd
FK1 ID_CustomerUnique
ScdDateStart
ScdDateEnd
ScdState
Occupation
Household
Marriage
Dim_CustomerUnique
PK ID_CustomerUnique
CODE_Customer
Name
Dim_Date
PK ID_Date
Year
MonthNumber
DayMonth
Fact_Balance
PK ID_Balance
FK2 ID_Date
FK1 ID_CustomerScd
Balance

The Many-to-Many Revolution 55

1hls flrsL quesLlon can be answered by Lhe SCL query shown below, whlch ls noL so easy Lo bulld wlLh a
query bullder.
!"#"$%
7O,5770A6+;/1 -! >61069@5770A6+;/1T
7R,5770A6+;/1 -! ?B7B.VB95770A6+;/1T
$5'=%)N2 -! $0:+/.B9:
345( ?;.8$0:+/.B9!7C 7O
<=="4 >5<= ?;.8$0:+/.B9!7C 7R
5= 7R,<?8$0:+/.B9'1;Q0B D 7O,<?8$0:+/.B9'1;Q0B
-=? ERWWXORWOG YD 7R,!7C?6+B!+69+
-=? )ERWWXORWOG ZD 7R,!7C?6+B"1C 54 7R,!7C?6+B"1C <! ='##2
HI"4" ERWWXWOWOG YD 7O,!7C?6+B!+69+
-=? )ERWWXWOWOG ZD 7O,!7C?6+B"1C 54 7O,!7C?6+B"1C <! ='##2
[45'\ ]^ 7O,5770A6+;/1T 7R,5770A6+;/1
Moreover, changlng Lhe analyzed aLLrlbuLe requlres a dlfferenL synLax slnce lL could noL be parameLerlzed.
WhaL wlll happen lf Lhe end user wanLs Lo analyze balances for year 2003 for cusLomers who had a SLudenL
occupaLlon ln !anuary, lrrespecLlve of Lhelr currenL occupaLlon? 1o answer Lhls second quesLlon, we can use
SCL agaln, buL Lhls mlghL noL be pracLlcal Lo analyze lf Lhe end users use CLA browsers, such as plvoL Lable
or plvoL charL. Moreover, Lhe end user wrlLlng a SCL query mlghL mlsmaLch one of Lhe [olns geLLlng wrong
resulLs.
!"#"$% V,<?8?6+BT !'() V,]6F617B 2
345( 367+8]6F617B V
<=="4 >5<= ?;.8$0:+/.B9!7C 7
5= 7,<?8$0:+/.B9!7C D V,<?8$0:+/.B9!7C
<=="4 >5<= ?;.8$0:+/.B9'1;Q0B 0
5= 0,<?8$0:+/.B9'1;Q0B D 7,<?8$0:+/.B9'1;Q0B
<=="4 >5<= ?;.8$0:+/.B9!7C 7_
5= 7_,<?8$0:+/.B9'1;Q0B D 0,<?8$0:+/.B9'1;Q0B
HI"4" 7_,5770A6+;/1 D E!+0CB1+G
-=? ERWWXWOWOG YD 7_,!7C?6+B!+69+
-=? )ERWWXWOWOG ZD 7_,!7C?6+B"1C
54 7_,!7C?6+B"1C <! ='##2
[45'\ ]^ V,<?8?6+B
ldeally, we would llke Lo Lrack dlfferences ln aLLrlbuLes beLween dlfferenL snapshoLs and relaLe sLandard
measures (llke balance ln our sample) behavlor over Llme for a group of cusLomers aL a glven polnL of Llme.
IMPLEMENTATION
ScduaLeSLarL and ScduaLeLnd do noL glve us an easy way Lo geL Lhe seL of valld cusLomers aL a cerLaln daLe
perlod, especlally lf we wanL Lo do lL from a plvoL Lable reporL. 1he classlcal soluLlon ls Lo de-normallze Lhe
schema.
We could geL a compleLe denormallzaLlon of cusLomer aLLrlbuLes by maklng a snapshoL Lable for Lhem.
Slnce we already have a SCu 1ype ll cusLomer dlmenslon, we can shorLcuL Lhe lmplemenLaLlon process by
maklng a snapshoL Lable LhaL only sLores Lhe relaLlonshlp beLween a daLe perlod and a cusLomer verslon. ln
Lhls way, we can obLaln Lhe prevlously dlscussed compleLe aLLrlbuLe snapshoL Lable by only [olnlng Lwo
Lables (Lhls soluLlon saves dlsk space and execuLlon Llme).
1he Lrlcky parL ls Lo make lL posslble for Lhe user Lo selecL all Lhe cusLomer verslons LhaL had a parLlcular
aLLrlbuLe value for a parLlcular daLe perlod. We wlll use many-Lo-many dlmenslons Lo model Lhe soluLlon.
www. sql bi . com


56 The Many-to-Many Revolution
1o relaLe dlfferenL verslons of Lhe same cusLomer, we sLore Lhe unlque cusLomer ldenLlflcaLlon ln a
snapshoL Lable Loo. llgure 66 lllusLraLes Lhe resulLlng relaLlonal model where we named Lhe snapshoL Lable
as 8rldge_CusLomerSnapshoL. 1hls Lable wlll be Lhe brldge Lable LhaL relaLes dlfferenL uaLe and CusLomer
dlmenslons.

Figure 66 Relational schema enable to cross-time anal ysis
We need Lo make a mlnor change Lo Lhe daLa source vlew (llgure 67) by addlng Lhe v8rldge_CusLomerScd
vlew. As we have already seen for ulsLlncL CounL scenarlo, we cannoL use a facL dlmenslon as an
lnLermedlaLe measure group ln a many-Lo-many relaLlonshlp.
Dim_CustomerScd
PK ID_CustomerScd
FK1 ID_CustomerUnique
ScdDateStart
ScdDateEnd
ScdState
Occupation
Household
Marriage
Dim_CustomerUnique
PK ID_CustomerUnique
CODE_Customer
Name
Dim_Date
PK ID_Date
Year
MonthNumber
DayMonth
Fact_Balance
PK ID_Balance
FK2 ID_Date
FK1 ID_CustomerScd
Balance
Bridge_CustomerSnapshot
PK ID_CustomerSnapshot
FK3 ID_Date
FK2 ID_CustomerUnique
FK1 ID_CustomerScd

The Many-to-Many Revolution 57


Figure 67 Cross-Time Data Source View and cube structure
We wlll bulld Lhls flrsL cube uslng role-playlng dlmenslons:
uaLe dlmenslon represenLs Lhe daLe for balance measure group
uaLe SnapshoL dlmenslon represenLs Lhe daLe for a parLlcular snapshoL (ln Lhe sample uuM, we
used a monLhly snapshoL, buL we could choose a dlfferenL granularlLy).
CusLomer 8egular dlmenslon references Lo Lhe 8alance measure group (lL ls Lhe regular"
dlmenslon for LransacLlonal measures) and Lhus ls lndlrecLly relaLed Lo Lhe uaLe dlmenslon.
CusLomer SnapshoL dlmenslon relaLes Lo uaLe SnapshoL and we wlll use lL Lo selecL a group of
cusLomers for a parLlcular snapshoL.
1he ulm_CusLomerunlque dlmenslon becomes Lhe brldge beLween CusLomer SnapshoL and CusLomer Scd
measure groups. 1he former mlrrors Lhe snapshoL lnformaLlon, whlle Lhe laLLer supporLs Lhe many-Lo-many
relaLlonshlp beLween CusLomer 8egular and CusLomer Scd dlmenslons. noLe LhaL we can use CusLomer
unlque dlmenslon Lo query daLa for a parLlcular cusLomer glven lLs appllcaLlon key.
llgure 68 shows Lhe resulLlng dlmenslon usage maLrlx. lf we Lry Lo use Lhe cube wlzard, Lhe dlmenslon
usage maLrlx wlll be very dlfferenL. Cnce auLo bulld compleLes, we wlll need Lo add role-playlng dlmenslons
www. sql bi . com


58 The Many-to-Many Revolution
and Lo change many dlmenslon usage seLLlngs. lnsLead, we suggesL deflnlng Lhe dlmenslon usage manually,
Lo reduce Lhe chance of forgeLLlng Lo ad[usL some relaLlonshlps.

Figure 68 Dimension Usage for Cross-Time cube
8efore querylng Lhe cube, lL ls lmporLanL Lo make Lhe purpose of Lhe measures clear, because Lhey are noL
very lnLulLlve aL flrsL glance.
8alance and 8alance CounL are regular measures comlng from Lhe lacL_8alance Lable. lf we
need an average balance, we should dlvlde 8alance by 8alance CounL.
CusLomer SnapshoL CounL shows how many cusLomers are presenL ln Lhe snapshoL for Lhe
currenL daLe selecLlon. When we selecL a slngle snapshoL daLe, CusLomer SnapshoL CounL
shows Lhe number of cusLomers for LhaL snapshoL aL LhaL daLe.
CusLomer Scd CounL mlghL be noL very useful Lo users because lL shows Lhe number of
cusLomer verslons for Lhe currenL selecLlon. lor example, lf we choose a slngle cusLomer, lL wlll
show Lhe number of dlfferenL verslons sLored ln ulm_CusLomerScd (a SCu 1ype ll CusLomer
ulmenslon) for LhaL cusLomer. 1o avold confuslon, lL would be beLLer Lo hlde CusLomer Scd
CounL and CusLomer SnapshoL CounL.
llgure 69 show a sample reporL. We fllLered daLa by !anuary 2003 (dlmenslon uaLe SnapshoL ln fllLer area),
and we placed ?ear/MonLh of uaLe dlmenslon on rows and CusLomer SnapshoL CccupaLlon aLLrlbuLe on
columns. As you can see, we had Lhree cusLomers ln !anuary snapshoL: one was a sLudenL and Lwo were
Leachers.

The Many-to-Many Revolution 59


Figure 69 Cross-Time resul ts for snapshot customer occupation attribute
lf we place Lhe CusLomer 8egular CccupaLlon aLLrlbuLe on columns, we geL Lhe resulLs shown ln llgure 70.
We can deduce LhaL Lhe sLudenL we had ln !anuary became an employee ln March. lf we had fllLered by
SLudenL, we would have obLalned Lhe same resulL wlLhouL Lhe 1eacher column.

Figure 70 Cross-Time resul ts for regul ar customer occupation attribute
now we have a powerful Lool Lo produce reporLs LhaL cross snapshoLs, LransacLlonal" dlmenslons and
aLLrlbuLes. 1hls ls very useful Lo saLlsfy our second ob[ecLlve (occupaLlon change beLween !anuary and
uecember) prevlously descrlbed ln Lhe buslness scenarlo, buL sLlll does noL compleLely saLlsfy Lhe flrsL one
(balances for cusLomers who were sLudenLs ln !anuary). ln facL, lf we wanL Lo compare Lhe !anuary
snapshoL wlLh Lhe uecember cusLomer daLa, we need Lo make a prlor assumpLlon LhaL all cusLomers ln
!anuary have balances ln uecember. lf Lhls ls correcL, we can auLhor Lhe reporL shown ln llgure 71.
www. sql bi . com


60 The Many-to-Many Revolution

Figure 71 Cross-Time resul ts comparing a snapshot with a date
lL seems all good, buL lL does noL work well when we choose dlfferenL monLhs for Lhe uaLe dlmenslons. ln
llgure 72, we chose !an/leb for uaLe SnapshoL dlmenslon and nov/uec for uaLe dlmenslon. now, lL ls
dlfflculL Lo undersLand how many cusLomers we really have. We would have run lnLo Lhe same problem
before, lf only a cusLomer had mulLlple balances for Lhe same daLe. 1herefore, dlvldlng by Lhe number of
monLhs selecLed ls noL a valld soluLlon.

Figure 72 Cross-Time resul ts comparing mul tipl e periods
1he lasL sLep Lo obLaln Lhe flnal model ls Lhe mosL complex one. We have Lo add a dlsLlncL counL measure
Lo geL Lhe rlghL number of cusLomers under any condlLlons. 1hls ls ofLen Lhe case when we have a SCu 1ype
ll dlmenslon ln our cube.
llgure 73 shows Lhe new cube sLrucLure. Whlle Lhe uaLa Source vlew ls unchanged, we have a new
measure group (CusLomer unlque) LhaL conLalns a new measure (CusLomers ulsLlncL CounL) LhaL should be
vlslble Lo end users. ulm_CusLomerunlque ls assumed also Lo be a facL Lable role oLher Lhan lLs own
dlmenslon role.

The Many-to-Many Revolution 61


Figure 73 Cross-Time Data Source View and cube structure (with distinct)
We need Lo relaLe Lhe new measure group correcLly Lo exlsLlng dlmenslons (see llgure 74). lL ls lmporLanL
Lo deflne all relaLlonshlps beLween CusLomer unlque and all cube dlmenslons oLher Lhan CusLomer unlque
dlmenslon as many-Lo-many relaLlonshlps.

Figure 74 Dimension Usage for Cross Time cube (with distinct customers)
Cnce done, we can geL Lhe correcL resulLs for our flrsL ob[ecLlve (see llgure 73), l.e. how cusLomers have
changed occupaLlon from !anuary Lo uecember 2003.
www. sql bi . com


62 The Many-to-Many Revolution

Figure 75 Cross-Time resul ts comparing mul tipl e periods with distinct count
1hls reporL sLlll does noL allow us Lo compare dlfferenL snapshoLs, because we assume LhaL we can LreaL
Lhe regular daLe dlmenslon as anoLher snapshoL dlmenslon. 1hls could be a valld assumpLlon because Lhe
balance facL Lable ls a dlfferenL klnd of snapshoL Lable. neverLheless, Lhls would noL be Lhe case lf we had a
sales or movemenLs facL Lable lnsLead of Lhe one wlLh balances. We wlll presenL a beLLer model LhaL meeLs
Lhese requlremenLs ln Lhe nexL secLlon LlLled 1ranslLlon MaLrlx. Powever, Lhe dlsLlncL counL measure ls
ofLen requlred by end users Lo ease Lhe analysls of daLa when grouplng more perlods boLh ln snapshoL
and/or ln regular uaLe dlmenslons, especlally when we have a more complex cube wlLh oLher dlmenslons
and relaLlonshlps wlLh oLher measure groups.

The Many-to-Many Revolution 63

Transition Matrix
Pas any user ever asked you for how many cases a glven aLLrlbuLe has changed beLween Lwo daLes? A
Lyplcal quesLlon wlLh cusLomer segmenLaLlon could be Pow many cusLomers classlfled as Lype A ln 2004
have been converLed Lo Lype 8 ln 2003?"
ln such cases, klmball suggesLs LhaL we conslder a snapshoL facL Lable. 1hls ls a good approach, buL ln Lhe
uuM we cannoL relaLe Lhe same Llme dlmenslon Lwlce Lo a facL Lable wlLhouL havlng Lwo dlfferenL daLe
columns. Cne posslble soluLlon could be Lo generaLe Lhe CarLeslan producL of Lhe Llme dlmenslon, buL Lhls
could be very expenslve ln Lerms of sLorage space and processlng Llme.
1he many-Lo-many relaLlonshlp allows us Lo dupllcaLe Lhe Llme dlmenslon ln Lhe uuM wlLhouL dupllcaLlon
of sLorage. 8y Lhe Lerm LranslLlon maLrlx", we wlll refer Lo a model LhaL makes lL posslble Lo analyze Lhe
sLaLe LranslLlon of analyzed elemenLs beLween Lwo daLes even when resulLs are dlsplayed ln a plvoL Lable
reporL.
BUSINESS SCENARIO
ln general, every Llme we have a facL repeaLed over Llme agalnsL Lhe same dlmenslon members, we could
analyze how relaLed aLLrlbuLes change over Llme for LhaL dlmenslon member. A good example of lL ls Lhe
credlL raLlng of a cusLomer. ln Lhls scenarlo, we have a monLhly updaLe of Lhe cusLomer raLlngs and we are
lnLeresLed ln analyzlng Lhelr changes. llgure 76 shows Lhe relaLlonal schema for Lhls daLa.

Figure 76 Relational rating star schema
1hls sLar schema allows us Lo creaLe a slmple uuM, wlLh 8aLlng, CusLomer and uaLe dlmenslons. 1he facL
Lable has Lwo measures: Lhe credlL amounL auLhorlzed and used for each cusLomer on a speclflc daLe.
Cne poLenLlal source of confuslon ls LhaL we would expecL a regular sLar schema Lo have Lwo compleLely
lndependenL dlmenslons for 8aLlng and CusLomer, whlle our CusLomer dlmenslon ls a referenced
dlmenslon (a sorL of a snowflake schema deslgn) LhaL relaLes Lo Lhe facL Lable Lhrough Lhe 8aLlng
dlmenslon. Powever, Lhere are good reasons Lo go for Lhls deslgn, as we wlll see nexL.
lacL_8aLlngvalues ls a sorL of snapshoL facL Lable wlLh perlodlc (probably monLhly) updaLes. lor each
snapshoL, we have currenL amounLs (AmounLused and AmounLAuLhorlzed) and a relaLed raLlng. Chances
are LhaL we wlll noL updaLe Lhe cusLomer raLlng frequenLly and regularly. We could have an orlglnal raLlng
Lable wlLh Lwo daLe flelds (uaLeSLarL and uaLeLnd) lndlcaLlng Lhe valldlLy perlod of a cerLaln raLlng (lL ends
when raLlng changes for any reason).
Slmllarly, we could creaLe ulm_8aLlng wlLh Lhe same crlLerla, maklng lL a 1ype ll SCu. lor Lhe sake of
slmpllclLy, we do noL have SCu canonlcal flelds (uaLeSLarL, uaLeLnd, CurrenL flag), because Lhey are noL
relevanL for Lhe examples.
Dim_Customer
PK ID_Customer
CODE_Customer
Dim_Date
PK ID_Date
Date
Year
Month
Day
Dim_Rating
PK ID_Rating
FK1 ID_Customer
Rating
Classification
Segmentation
Fact_RatingValues
PK ID_RatingValues
FK2 ID_Rating
FK1 ID_Date
AmountUsed
AmountAuthorized
www. sql bi . com


64 The Many-to-Many Revolution
lL ls lmporLanL Lo noLe LhaL Lhe L1L musL ensure Lhe conslsLency beLween Lhose SCu daLes and Lhe
lacL_8aLlngvalues snapshoL, because lL conLalns Lhe only daLe used by our analysls. 1able 8 shows Lhe
hlsLory of raLlng changes used ln our scenarlo. lor Lhe sake of slmpllclLy agaln, AmounLused and
AmounLAuLhorlzed values wlll be respecLlvely 30 and 100 for all lacL_8aLlngvalues rows.
DateStart DateLnd Customer kat|ng C|ass|f|cat|on Segmentat|on
01/01/2003 13/04/2003 lrank AA8 Class A 8eLall
16/04/2003 21/06/2003 lrank AA8 Class A AffluenL
22/06/2003 lrank AAC Class A AffluenL
01/01/2003 14/03/2003 Mark AAA Class A rlvaLe
13/03/2003 08/03/2003 Mark AAA Class A AffluenL
09/03/2003 Mark AA8 Class A AffluenL
01/01/2003 11/02/2003 aul AAA Class A rlvaLe
12/02/2003 17/03/2003 aul AA8 Class 8 rlvaLe
18/03/2003 aul AA8 Class C rlvaLe
Tabl e 8 Ratings used for sample data in transition matrix model
8aLlng, ClasslflcaLlon and SegmenLaLlon are lndependenL aLLrlbuLes LhaL are cusLomer-relaLed and mlghL
change over Llme. Cur goal ls Lo analyze Lhe cusLomer changes from one aLLrlbuLe sLaLe Lo anoLher over
Llme. 1he Lyplcal quesLlon we would llke Lo answer ls Pow many cusLomers wlLh raLlng AAA have been
downgraded Lo AA8 from !anuary Lo !une?"
1hls scenarlo ls very slmllar Lo Lhe survey model we have dlscussed before. 1he maln dlfference ls LhaL we
have Lwo classes of dlmenslons Lo dupllcaLe" ln query (uaLe and 8aLlng) as we can see ln Lhe followlng
code wlLh a posslble SCL soluLlon.
!"#"$% $5'=%)N2
345( 367+846+;1JU6F0B: 9LO
<=="4 >5<= ?;.846+;1J 9O
5= 9O,<?846+;1J D 9LO,<?846+;1J
<=="4 >5<= ?;.8?6+B CO
5= CO,<?8?6+B D 9LO,<?8?6+B
<=="4 >5<= ?;.846+;1J 9R
5= 9O,<?8$0:+/.B9 D 9R,<?8$0:+/.B9
<=="4 >5<= 367+846+;1JU6F0B: 9LR
5= 9R,<?846+;1J D 9LR,<?846+;1J
<=="4 >5<= ?;.8?6+B CR
5= CR,<?8?6+B D 9LR,<?8?6+B
HI"4" CO,<?8?6+B D ERWWXWO`OG
-=? CR,<?8?6+B D ERWWXWa`WG
-=? 9O,46+;1J D E---G
-=? 9R,46+;1J D E--]G
AnoLher common requesL could be Lo produce a LranslLlon maLrlx of raLlngs from !anuary Lo !une: Lhe
followlng SCL sLaLemenL shows Lhe lvC1 SCL query LhaL generaLes Lhe resulLs ln 1able 9.

The Many-to-Many Revolution 65

!"#"$%
46+;1J>61069@ -! 46+;1JT
b---cT b--]cT b--$c
345( )
!"#"$%
9O,46+;1J -! 46+;1J>61069@T
9R,46+;1J -! 46+;1J>01B
345( 367+846+;1JU6F0B: 9LO
<=="4 >5<= ?;.846+;1J 9O
5= 9O,<?846+;1J D 9LO,<?846+;1J
<=="4 >5<= ?;.8?6+B CO
5= CO,<?8?6+B D 9LO,<?8?6+B
<=="4 >5<= ?;.846+;1J 9R
5= 9O,<?8$0:+/.B9 D 9R,<?8$0:+/.B9
<=="4 >5<= 367+846+;1JU6F0B: 9LR
5= 9R,<?846+;1J D 9LR,<?846+;1J
<=="4 >5<= ?;.8?6+B CR
5= CR,<?8?6+B D 9LR,<?8?6+B
HI"4" CO,<?8?6+B D ERWWXWO`OG
-=? CR,<?8?6+B D ERWWXWa`WG
2 -! 46+;1J:
\<U5% )
$5'=%)46+;1J>01B2
354 46+;1J>01B <= ) ---T --]T --$2
2 -! \;L/+%6VFB

kat|ng AAA AA8 AAC
AAA 0 2 0
AA8 0 0 1
Tabl e 9 Transition matrix with SQL
Lach row represenLs a raLlng ln !anuary and each column shows a raLlng ln !une. We can say LhaL Lwo
cusLomers who were raLed AAA ln !anuary (Mark and aul) have been declasslfled Lo AA8 ln !une (even lf
Lhe daLe of Lhe raLlng change could be anywhere beLween Lhese Lwo daLes). Moreover, Lhe cusLomer who
was raLed AA8 ln !anuary (lrank) has been declasslfled Lo AAC ln !une. 1ough Llmes for credlL raLlngs!
As before, SCL soluLlons are noL very flexlble or easy Lo bulld for an end user. A plvoL Lable LhaL can
generaLe Lhe resulLs shown ln 1able 9 would be greaLly appreclaLed.
IMPLEMENTATION
We wlll lmplemenL a uuM wlLh Lhree dlmenslons: uaLe, CusLomer and 8aLlng. 1hese dlmenslons
correspond Lo Lhe dlmenslon Lables shown ln llgure 76.
1he cube needs Lo dupllcaLe some dlmenslons: we need Lwo uaLe dlmenslons and Lwo 8aLlng dlmenslons.
1he end user would selecL Lwo daLes Lo see Lwo dlfferenL raLlngs, one for each selecLed daLe. We wlll use
agaln Lhe Lechnlque dlscussed ln Lhe Survey model, where we used role-playlng dlmenslons. 1hen we wlll
change relaLlonshlps wlLh Lhe measure groups by uslng vlews represenLlng dlfferenL and lndependenL
brldge Lables, alLhough Lhey dupllcaLe Lhe same orlglnal daLa.
As ln Lhe Survey model, we need Lo malnLaln Lhe relaLlonshlp beLween Lhe selecLed aLLrlbuLes (raLlngs ln
Lhls case) of Lhe same cusLomer. lor Lhls reason, we creaLe Lwo named vlews LhaL we wlll use as brldge
Lables beLween Lhe CusLomer and Lhe 8aLlng dlmenslons.
www. sql bi . com


66 The Many-to-Many Revolution
!"#"$%
<?846+;1JT
<?8$0:+/.B9
345( ?;.846+;1J
1hese vlews use ulm_8aLlng, whlch ls already a sorL of brldge Lable, because lL relaLes raLlng and
cusLomers.
As we have Lwo lndependenL measure groups (facL Lables) beLween CusLomer and 8aLlng dlmenslons, we
also need Lwo lndependenL measure groups beLween 8aLlng and uaLe dlmenslons. 8efore golng furLher,
look aL llgure 77 Lo geL a compleLe plcLure of Lhe model we are golng Lo bulld.

Figure 77 Transition Matrix cube structure
Whlle we already have lacL_8aLlngvalues facL Lable Lo relaLe 8aLlng and uaLe, we need anoLher named
vlew (v8rldge_8aLlng, deflned ln slde box) Lo geL an lndependenL alLernaLlve relaLlonshlp beLween Lhese
dlmenslons.
!"#"$%
<?846+;1JT
<?8?6+B
345( 367+846+;1JU6F0B:
We do noL need Lo dupllcaLe Lhe oLher lacL_8aLlngvalues measures (AmounLused and AmounLAuLhorlzed).
1he Lwo vlews dlscussed above are v8rldge_CusLomerA and v8rldge_CusLomer8. 1hey serve as a source for
Lhe 8rldge C8 A and 8rldge C8 8 measure groups. 1hese measure groups conLaln only one measure (row
counL) LhaL wlll be useful Lo deflne Lhe requlred many-Lo-many relaLlonshlps. We need CounL A and CounL
8 measures, used ln 8aLlng A and 8aLlng 8 measure groups, Lo make many-Lo-many relaLlonshlps work.

The Many-to-Many Revolution 67

Why do Lhese vlews, measure groups and dlmenslons have sufflxes A and 8? 1o undersLand Lhls, look aL
llgure 78.

Figure 78 Transition Matrix dimension usage
We can flgure A and 8 as Lwo axes ln our LranslLlon maLrlx: lf A ls Lhe sLarLlng polnL (l.e. Lhe raLlng on a
cerLaln daLe), Lhen 8 ls Lhe endlng one (Lhe raLlng on anoLher daLe). 1he same sufflx ls used ln measure
groups and role-playlng dlmenslons. 1he 8aLlng A measure group has a dlrecL relaLlonshlp wlLh Lhe 8aLlng A
and uaLe A dlmenslons. lL also has a referenced dlmenslon relaLlonshlp wlLh CusLomer Lhrough Lhe 8aLlng A
dlmenslon and has many-Lo-many relaLlonshlps wlLh Lhe 8aLlng 8 and uaLe 8 dlmenslons. 1he opposlLe ls
Lrue for Lhe 8aLlng 8 measure group (lL has a regular relaLlonshlp wlLh 8-sufflxed dlmenslons and many-Lo-
many relaLlonshlps wlLh A-sufflxed dlmenslons).
1he oLher Lwo measure groups work as llnks beLween Lhe 8aLlng and CusLomer dlmenslon: lL ls very
lmporLanL Lo observe carefully Lhe relaLlonshlps used ln Lhls case. 1he brldge measure groups (8rldge C8 *)
have Lo connecL Lhe raLlng of a cusLomer wlLh all Lhe daLes ln whlch Lhls raLlng exlsLs for LhaL cusLomer.
1hus, 8rldge C8 A has a dlrecL relaLlonshlp wlLh 8aLlng A and CusLomer dlmenslon, whlle Lhe many-Lo-many
relaLlonshlp wlLh uaLe A has Lo be deflned Lhrough Lhe 8aLlng A measure group. Llkewlse, 8rldge C8 8 goes
dlrecLly Lo Lhe 8aLlng 8 and CusLomer dlmenslons and goes Lo uaLe 8 Lhrough Lhe 8aLlng 8 measure group.
All relaLlonshlps beLween a measure group and dlmenslons wlLh a dlfferenL sufflx musL be many-Lo-many
relaLlonshlps uslng a lacLless C8 measure group as an lnLermedlaLe one. 1he raLlng measure groups use a
lacLless C8 wlLh Lhe same sufflx, whlle lacLless measure groups use Lhe oLher lacLless C8 measure group as
lnLermedlaLe one. lf you are sLarLlng Lo geL confused, remember Lhe rule of Lhumb we suggesLed for
deallng wlLh cascadlng many-Lo-many scenarlos: we have Lo choose Lhe lnLermedlaLe measure group LhaL ls
nearesL Lo Lhe measure group [we are sLarLlng from], conslderlng all Lhe posslble measure groups LhaL we
can cross golng from Lhe measure group Lo Lhe dlmenslon of lnLeresL. lf we look aL Lhe daLa source vlew ln
llgure 77 followlng Lhe llnks beLween dlmenslons and measure groups, lL should be easy Lo apply Lhls rule.
As we have seen ln llgure 77, only Lhe 8aLlng A measure group has AmounL-* measures: lf we wanL Lo
name measures more speclflcally Lhan uslng A and 8 sufflxes (e.g. wlLh SLarL" end Lnd"), Lhen lL could be
a good ldea Lo dupllcaLe Lhe AmounL-* measures ln boLh measure groups, [usL Lo glve more flexlblllLy Lo Lhe
end user.
Pere ls a poLenLlal source of confuslon when querylng Lhe cube. When we use role-playlng dlmenslons, we
can change Lhe dlmenslon name buL noL lnLernal hlerarchles and/or aLLrlbuLes names. lf Lhe CLA browser
does noL show Lhe dlmenslon name near Lhe aLLrlbuLe, Lhe end user wlll have Lo pay aLLenLlon Lo whlch
aLLrlbuLes he ls uslng ln order Lo undersLand Lhe meanlng of resulLs: Lhls ls (sadly) Lhe case for Lxcel. ?ou
have Lo dupllcaLe Lhe physlcal dlmenslon lnsLead of uslng Lhe role-playlng dlmenslons lf you wanL Lo change
hlerarchles and/or aLLrlbuLe names beLween Lhese Lwln dlmenslons.
www. sql bi . com


68 The Many-to-Many Revolution
llgure 79 shows Lhe resulLlng reporL wlLh 8aLlng A on columns, CusLomer and uaLe A (level MonLhs) on
rows and Lhe AmounL AuLhorlzed measure ln Lhe daLa area. 1hls reporL shows Lhe underlylng daLa aL Lhe
maxlmum granularlLy. We can see all snapshoLs avallable for all cusLomers, where Lhe amounL ls dlsplayed
ln Lhe column correspondlng Lo Lhe raLlng LhaL cusLomer has on Lhe monLh for Lhe maLchlng row.

Figure 79 Amount Authorized by Customer, Month and Rating
So far, we have noL used Lhe 8-sufflxed dlmenslons. We wlll do so ln Lhe followlng example.
ln llgure 80, we geL all Lhe answers for our lnlLlal buslness scenarlo. 1he fllLer area conLalns !anuary
(selecLed from Lhe uaLe A dlmenslon) and Lhe columns conLalns 8aLlng aLLrlbuLe from Lhe 8aLlng A
dlmenslon. 1he rows are a CarLeslan producL of Lhe monLhs and raLlngs avallable from Lhe uaLe 8 and
8aLlng 8 dlmenslons. lor each monLh, Lhere ls a row for each posslble raLlng. 1he meanlng of each daLa cell
ls how many cusLomers wlLh [column raLlng] ln !anuary have [row raLlng] ln [row monLh name]".
Cbvlously, !anuary rows have Lhe same raLlng as shown ln Lhe correspondlng columns. We can see LhaL
!une has Lwo orlglnal AAA cusLomers who Lurned lnLo AA8 and one AA8 who Lurned lnLo AAC: Lhls ls Lhe
same daLa presenLed ln 1able 9, excepL LhaL Lhe meanlng of Lhe rows and columns ls lnverLed.

The Many-to-Many Revolution 69


Figure 80 Transition Matrix of Ratings between January and other months
8esldes allowlng us Lo use a plvoL Lable for LranslLlon maLrlx querles, our model also slmpllfles dlrecL
querles: Lhe nexL llsLlng shows Lhe Mux query LhaL produces Lhe same resulL shown ln 1able 9, buL lL has a
synLax LhaL ls much easler Lo wrlLe and undersLand Lhan Lhe SCL one we used before.
!"#"$%
b46+;1J ]c,46+;1J,46+;1J 5= WT
=5= "(\%^ b46+;1J -c,46+;1J,46+;1J 5= O
345( b(R( %961:;+;/1 (6+9;dc
HI"4" )
b?6+B -c,b(/1+Kc,bOcT
b?6+B ]c,b(/1+Kc,bacT
(B6:09B:,b$/01+ -c 2
1he only dlfference ls LhaL Lhe query reLurns null values lnsLead of zeros.
www. sql bi . com


70 The Many-to-Many Revolution
Multiple Parent/Child Hierarchies
arenL-chlld dlmenslons are a useful feaLure of Analysls Servlces. We can use Lhem Lo model hlerarchlcal
and fasL changlng dlmenslons llke sales or employee organlzaLlons. A very annoylng llmlLaLlon of Lhls
feaLure ls LhaL you can deflne only one parenL-chlld hlerarchy ln a dlmenslon. ln Lhe real world, Lhls can be
an lssue.
lor example, ln Lhe mlddle of a company reorganlzaLlon, someone mlghL need Lo analyze alLernaLlvely Lhe
presenL wlLh Lhe eyes of Lhe pasL (acLual daLa for prevlous organlzaLlon hlerarchy) and Lhe pasL wlLh Lhe
eyes of Lhe presenL (pasL daLa for acLual organlzaLlon hlerarchy).
1he mulLlple hlerarchles" ls a model LhaL uses Lhe many-Lo-many relaLlonshlp feaLure: lL allows us Lo
asslgn a slngle leaf member Lo many dlfferenL loglcal parenL-chlld hlerarchles, by uslng a slngle physlcal
parenL-chlld hlerarchy.
BUSINESS SCENARIO
As usual, leL us explore a buslness scenarlo LhaL applles Lo many dlfferenL slLuaLlons. ln Lhls case, we have a
branch organlzaLlon and we wanL Lo show lL under dlfferenL hlerarchles: one ls Lhe reglonal hlerarchy,
whlch has an lmpacL on loglsLlcal and Lechnlcal aspecLs, Lhe oLher ls Lhe markeL hlerarchy, responslble for
cusLomer markeL analysls. 1able 10 shows us Lhe hlerarchles assoclaLed wlLh each company branch.
8ranch keg|ona| n|erarchy Market n|erarchy
n?01 norLh WesL CorporaLe / LnLerprlse
n?02 norLh WesL / new ?ork CorporaLe / Small
n?03 norLh WesL / new ?ork rlvaLe
8C01 norLh WesL CorporaLe / Small
8C02 norLh WesL / 8osLon CorporaLe / Small
8C03 norLh WesL / 8osLon rlvaLe
Tabl e 10 Branch Hierarchies
CfLenLlmes, we may face Lhe lssue LhaL Lhe hlerarchles change over Llme, boLh ln Lhe number of hlerarchles
and ln Lhe hlerarchy's daLa. As usual, we do noL wanL Lo change Lhe relaLlonal and dlmenslonal schemas
each Llme we need Lo modlfy Lhese loglcal vlews.
1he relaLlonal model Lo work around Lhls lssue ls relaLlvely slmple: llgure 81 shows LhaL we have a
ulm_8ranch dlmenslon Lable LhaL conLalns real branches and a ulm_8ranchPlerarchles dlmenslon Lable
LhaL assoclaLes each ulm_8ranch row Lo many dlfferenL hlerarchles. As always, Lhe L1L process musL
malnLaln daLa lnLegrlLy ln Lhese Lables.

The Many-to-Many Revolution 71


Figure 81 Relational schema for Multiple Hierarchies
1he ulm_8ranchPlerarchles Lable deflnes dlfferenL hlerarchles for Lhe same branch. We can obLaln a slngle
parenL-chlld hlerarchy by fllLerlng Lhe rows ln ulm_8ranchPlerarchles for a speclflc Plerarchy aLLrlbuLe
value.
A ulm_8ranch row should exlsL only once for each hlerarchy and a row ln ulm_8ranchPlerarchles musL
have a reference Lo an lu_8ranch only for Lhe leaf members of Lhe hlerarchy. lnLermedlaLe nodes mlghL noL
have a correspondlng lu_8ranch: ln Lhls case, lL ls necessary Lo deflne a value for 8ranchnameCverrlde,
whlch ls Lhe name Lo glve Lo Lhe node. lf we do noL deflne 8ranchnameCverrlde, Lhe node/leaf name ls Lhe
branch name referenced by lu_8ranch.
1o undersLand beLLer how Lhls model ls populaLed, we can look aL Lhe dlmenslons members. 1able 11
shows Lhe ulm_8ranch daLa. As explalned, we have only branches LhaL have correspondlng measures ln
lacL_8alance and lL ls noL necessary Lo have rows for Lhe lnLermedlaLe nodes of a hlerarchy.
ID_8ranch CCD_8ranch 8ranch
1 n?01 n?01
2 n?02 n?02
3 n?03 n?03
4 8C01 8C01
3 8C02 8C02
6 8C03 8C03
Tabl e 11 Dim_Branch content
1he Lwo hlerarchles are ln ulm_8ranchPlerarchles, as shown ln 1able 12. We use Lhe fleld
8ranchnameCverrlde only for lnLermedlaLe hlerarchy nodes, even lf lL could be useful Lo rename a leaf
name for a parLlcular hlerarchy Loo. When lLs value ls nuLL Lhen we use Lhe branch name referenced by
lu_8ranch as Lhe name of Lhe lLem ln Lhe hlerarchy.
Dim_Branch
PK ID_Branch
U1 COD_Branch
Branch
Dim_BranchHierarchies
PK ID_BranchHierarchy
Hierarchy
BranchNameOverride
FK1 ID_Branch
FK2 ID_BranchHierarchyParent
Dim_Customer
PK ID_Customer
U1 COD_Customer
Customer
Dim_Date
PK ID_Date
U1 Date
Year
Month
Day
Fact_Balance
PK ID_Sale
FK2 ID_Customer
FK3 ID_Date
FK1 ID_Branch
Amount
www. sql bi . com


72 The Many-to-Many Revolution
ID_8ranch-
n|erarch|es
n|erarchy 8ranchName-
Cverr|de
ID_8ranch ID_8ranch-
n|erarchyarent
1 8eglonal 1 7
2 8eglonal 2 8
3 8eglonal 3 8
4 8eglonal 4 7
3 8eglonal 3 9
6 8eglonal 6 9
7 8eglonal norLh WesL
8 8eglonal new ?ork 7
9 8eglonal 8osLon 7
10 MarkeL 1 17
11 MarkeL 1 18
12 MarkeL 2 19
13 MarkeL 3 18
14 MarkeL 4 18
13 MarkeL 3 19
16 MarkeL CorporaLe
17 MarkeL LnLerprlse 16
18 MarkeL Small 16
19 MarkeL rlvaLe
Tabl e 12 Dim_BranchHierarchies content
1o keep Lhlngs slmple, each branch has a slngle cusLomer and a slngle balance amounL for each daLe and
Lhe balance amounL ls Lhe same for all cusLomers on LhaL daLe (1able 12 shows Lhe same balance amounL
of 100 for !anuary).
Cur goal ls Lo query a uuM LhaL has many parenL-chlld hlerarchles for Lhe 8ranch dlmenslon. 1he query
resulLs should auLomaLlcally show only Lhe members of Lhe selecLed hlerarchy.
IMPLEMENTATION
1he relaLlonal model shown ln llgure 81 ls close Lo Lhe envlsloned uuM. Powever, Analysls Servlces does
noL dlrecLly supporL Lhe relaLlonshlp LhaL exlsLs beLween ulm_8ranch and ulm_8ranchPlerarchles, because
we have a one-Lo-many relaLlonshlp whlle only many-Lo-one relaLlonshlps can be lmplemenLed Lhrough
referenced dlmenslons.
We already solved an analogous problem ln Lhe MulLlple Croups scenarlo uslng a many-Lo-many
relaLlonshlp Lhrough Lhe expanded model shown ln llgure 82. We deflne a vlew LhaL corresponds Lo
8rldge_8ranchPlerarchles ln our model.
!"#"$%
<?8]9617KI;B9697K@T
<?8]9617K
345( ?;.8]9617KI;B9697K;B:
HI"4" <?8]9617K <! =5% ='##
1hls query fllLers all rows LhaL do noL relaLe Lo a branch: Lhese rows ln our sample are all lnLermedlaLe
nodes ln Lhe hlerarchles.

The Many-to-Many Revolution 73


Figure 82 Relational schema expanded for Multiple Hierarchies
We have four dlmenslons ln our uuM: Lhe only one LhaL deserves more aLLenLlon ls Lhe one based on
ulm_8ranchPlerarchles. llrsL, we creaLe a named vlew called vulm_8ranchPlerarchles, whlch we wlll use as
a source for Lhe dlmenslon.
!"#"$%
K,<?8]9617KI;B9697K@T
K,<?8]9617KT
K,<?8]9617KI;B9697K@\69B1+T
K,I;B9697K@T
$5-#"!$" )K,]9617K=6.B5LB99;CBT V,$5?8]9617K2 -! $5?8]9617KT
$5-#"!$" )K,]9617K=6.B5LB99;CBT V,]9617K2 -! ]9617K
345( ?;.8]9617KI;B9697K;B: K
#"3% >5<= ?;.8]9617K V
5= K,<?8]9617K D V,<?8]9617K
1hls ls necessary because we have Lo deflne Lhe name of all Lhe nodes and leaves for all Lhe hlerarchles.
Cur relaLlonal model deflnes an overrlde mechanlsm for Lhe node name LhaL has Lo be resolved for Analysls
Servlces.
1hen, we creaLe Lhe dlmenslon 8ranch Plerarchles shown ln llgure 83. lL has a slngle parenL-chlld hlerarchy
(Plerarchlzed 8ranch) and an aLLrlbuLe (Plerarchy) conLalnlng Lhe names of Lhe avallable hlerarchles.
lllLerlng by Lhls aLLrlbuLe, users wlll be able Lo see only nodes and leaves of Lhe deslred hlerarchy.
Fact_Balance
PK ID_Sale
FK2 ID_Customer
FK3 ID_Date
FK1 ID_Branch
Amount
Dim_Branch
PK ID_Branch
U1 COD_Branch
Branch
Dim_Customer
PK ID_Customer
U1 COD_Customer
Customer
Dim_Date
PK ID_Date
U1 Date
Year
Month
Day
Dim_BranchHierarchies
PK ID_BranchHierarchy
Hierarchy
BranchNameOverride
FK1 ID_Branch
FK2 ID_BranchHierarchyParent
Bridge_BranchHierarchies
PK,FK1 ID_BranchHierarchy
PK,FK2 ID_Branch
www. sql bi . com


74 The Many-to-Many Revolution

Figure 83 Dimension Branch Hierarchies
lL ls lmporLanL Lo undersLand whaL keys and names we use for Lhe dlmenslon aLLrlbuLes. 1able 13 shows
Lhe mosL lmporLanL properLles used. noLe LhaL Lhe lnsLanceSelecLlon properLy for Plerarchy aLLrlbuLe
should be seL Lo MandaLorylllLer (so LhaL a cllenL appllcaLlon LhaL supporLs Lhls properLy could suggesL Lhe
selecLlon of a member Lo end users).
Attr|bute Name n|erarchy
V|s|b|e
Usage key Co|umn Name Co|umn
8ranch for
Plerarchy
lalse key lu_8ranchPlerarchy 8ranch
Plerarchlzed
8ranch
1rue arenL lu_8ranchPlerarchyarenL (none)
Plerarchy 1rue 8egular Plerarchy (none)
Tabl e 13 Dim_BranchHierarchies attributes properties definition
llgure 84 shows LhaL by browslng Lhe Plerarchlzed 8ranch hlerarchy we can geL all Lhe hlerarchles:
CorporaLe and rlvaLe are Lop-level nodes for Lhe MarkeL hlerarchy, whlle norLh WesL ls Lhe only Lop-level
node for Lhe 8eglonal hlerarchy. lf we fllLer by Lhe Plerarchy aLLrlbuLe, Lhen we can only browse Lhe nodes
of Lhe selecLed hlerarchy.

The Many-to-Many Revolution 75


Figure 84 Browse Branch Hierarchies dimension without fil tering
1he cube deflnlLlon shown ln llgure 83 has Lwo measure groups, one for Lhe facLs (lacL 8alance) and Lhe
oLher (8ranch Plerarchles) for Lhe many-Lo-many relaLlonshlp beLween 8ranch and 8ranch Plerarchles
dlmenslons.
www. sql bi . com


76 The Many-to-Many Revolution

Figure 85 Mul tipl e Hierarchies Cube Structure
AL Lhls polnL, Lhe dlmenslon usage shown ln llgure 86 should be easy Lo grasp. Slnce Lhe 8ranch Plerarchles
measure group has only a hldden measure, we do noL need any relaLlonshlp beLween Lhls measure group
and Lhe CusLomer and uaLe dlmenslons. 1hls ls why Lhe 8ranch Plerarchles measure group has only Lwo
regular relaLlonshlps wlLh 8ranch and 8ranch Plerarchles dlmenslon. 1he lacL 8alance measure group has a
many-Lo-many relaLlonshlp wlLh Lhe 8ranch Plerarchles dlmenslon uslng Lhe 8ranch Plerarchles measure
group as lnLermedlaLe.

Figure 86 Mul tipl e Hierarchies Dimension Usage
8rowslng Lhe cube wlLh a nCn LM1? clause glve us Lhe expecLed resulLs. ln llgure 87 we show Lhree
querles made Lo Lhe cube.

The Many-to-Many Revolution 77


Figure 87 Sampl e queries using mul tipl e hierarchies
1he flrsL query has 8rand Plerarchy name as Lhe flrsL row fleld and 8ranch Plerarchles lmmedlaLely nexL. lL
ls easy Lo see LhaL Lhe Lwo hlerarchles show Lhe same daLa (Lhe LoLal ls always 600) even lf Lhe same row
(8001 for example) appears more Lhan once.
Movlng 8rand Plerarchy name Lo Lhe fllLer area (l.e. Lhe second and Lhlrd querles), we are able Lo see Lhe
mulLlple hlerarchles" as one slngle hlerarchy. 1he fllLerlng for Lhe Plerarchy name does Lhe maglc maklng
mulLlple hlerarchles avallable ln SSAS.
uslng Plerarchy name as a fllLer seems Lo be Lhe besL opLlon, neverLheless, we have Lo be aware of cllenL
llmlLaLlons. lf, for example, we use Lxcel Lo navlgaLe Lhrough Lhe mulLlple hlerarchles, we wlll soon dlscover
LhaL Lhe CLA browser ls noL smarL enough Lo fllLer dlmenslon browslng when we already puL a fllLer on
Lhe Lable, as you can see ln llgure 88.
www. sql bi . com


78 The Many-to-Many Revolution

Figure 88 Excel does not filter dimension correctly
lL ls easy Lo see LhaL Lxcel mlxes Lhe nodes from boLh hlerarchles ln Lhe fleld selecLlon wlndow, forclng on
Lhe user a very non-lnLulLlve experlence. 1he problem resldes ln Lhe cllenL capablllLles and noL ln Lhe cube
sLrucLure. neverLheless, Lhls ls a problem and we need Lo face and solve lL.
noLe LhaL lf we deflne a subcube by applylng a dlmenslon fllLer ln Lhe area above plvoL Lable uslng 8luS (see
llgure 89), Lhe Cube 8rowser wlll show Lhe fllLered members only, buL Lhls does noL happen lf you place Lhe
fllLer ln Lhe fllLer area, because of a dlfferenL fllLerlng lmplemenLaLlon.

The Many-to-Many Revolution 79


Figure 89 Dimension filter lets filter dimension browsing too
ln Lhe case Lhe CLA browser does noL supporL subcube fllLerlng, or lL may be Loo complex for Lhe end user
Lo use Lhls feaLure, we could deflne a slngle Lop-level member for each hlerarchy LhaL corresponds Lo Lhe
name of Lhe hlerarchy. We always use Lhls sLraLegy when we need Lo faclllLaLe Lhe use of legacy" cllenLs,
llke Lxcel 2003, wlLh Lhls model.
1he MulLlple Plerarchles model allows Lhe creaLlon of a new hlerarchy wlLhouL Lhe need Lo resLrucLure
elLher Lhe relaLlonal or Lhe dlmenslonal schemas. ln addlLlon, changes only need an lncremenLal updaLe of
Lhe 8ranch Plerarchles dlmenslon and measure group. lL ls lnLeresLlng for such on-Lhe-fly modlflcaLlons as
Lhose suggesLed aL Lhe end of Lhe MulLlple Croups scenarlo: you could provlde a user lnLerface Lo creaLe
new hlerarchles LhaL become avallable on Lhe server lmmedlaLely for all users, wlLhouL Lhe need for a full
process.
Cne very lmporLanL noLe regards unary operaLors. When we deflne a parenL/chlld hlerarchy ln SSAS, we
have Lhe opLlon of chooslng as an aLLrlbuLe as Lhe unary operaLor LhaL deflnes how SSAS aggregaLes Lhe
values on Lhe parenL/chlld hlerarchy. ?ou can choose Lo sum up some nodes, subLracL oLhers and so on.
Clearly, we do noL wanL Lo explaln here how Lhe unary operaLor feaLure works, lf you need lL Lhen you
already know lL.
WhaL ls lmporLanL ls LhaL, due Lo Lhe lnLernal archlLecLure of SSAS, Lhe unary operaLor does noL work
correcLly when many-Lo-many relaLlonshlps relaLe a facL Lable wlLh Lhe hlerarchy we reallzed. 1hls ls Lrue
even for SCL Server 2008. We wlll show shorLly a new and much more complex model LhaL wlll leL you
deflne unary operaLors wlLh mulLlple hlerarchles and glves some more advanLages over unary operaLor.
neverLheless, we always need Lo be aware LhaL Lhe model of slmple mulLlple hlerarchles and Lhe unary
operaLor are Lwo concepLs LhaL cannoL be mlxed. lf you need Lhe unary operaLor, carefully read Lhe nexL
chapLer Plerarchy 8eclasslflcaLlon wlLh unary CperaLor" Lo learn how Lo lmplemenL unary operaLor wlLh
mulLlple hlerarchles.
www. sql bi . com


80 The Many-to-Many Revolution
Hierarchy Reclassification with Unary Operator
8alance reclasslflcaLlon ls a very common need when we have a balance sheeL LhaL ls useful for accounLlng,
buL we would llke Lo see lL under dlfferenL hlerarchles as each hlerarchy glves us a dlfferenL vlew of Lhe
same daLa and ls good for dlfferenL analyses. 8alance reclasslflcaLlon ls a varlaLlon of Lhe MulLlple
Plerarchles model, buL hldes some subLle dlfferences. lL ls a model more complex Lhan mulLlple hlerarchles
are because, ln balance sheeLs, we normally have Lo deal wlLh Lhe unary operaLor feaLure of Analysls
Servlces. SSAS uses Lhe unary operaLor Lo deLermlne how a speclflc balance value should be aggregaLed on
lLs parenL. unforLunaLely, unary operaLors cannoL be used when you make calculaLlon over a many-Lo-
many relaLlonshlp, whlch ls used Lo bulld Lhe mulLlple hlerarchles model.
BUSINESS SCENARIO
Suppose we have a cusLomer wlLh a soluLlon LhaL leL hlm lnvesLlgaLe on hls balance sheeL wlLh excel
worksheeLs llke Lhe one ln llgure 90.

Figure 90 Standard Bal ance Sheet
1he cube sLrucLure ls sLralghLforward and we wlll dlscuss lL laLer. 1he lmporLanL Lhlng Lo noLe ls LhaL our
user wanLs Lo see poslLlve numbers for expenses and revenues buL, on Lhe grand LoLal, he clearly wanLs Lo
subLracL expenses from revenues, ln order Lo see hls flnal proflLs.

The Many-to-Many Revolution 81

1hls ls Lhe perfecL slLuaLlon where Lhe unary operaLor feaLure ls good. Moreover, Lhe poslLlve slgn for Lhe
expenses aL Lhe leaf level ls mandaLory, because we use Lhe same numbers somewhere for oLher analyses
LhaL do noL lnclude Lhe balance sheeL.
now, our user wanLs Lo have more Lhan one hlerarchy Lo analyze hls balance sheeL. Pe recognlzes LhaL he
mlghL be lnLeresLed ln a dlfferenL hlerarchy LhaL shows Lhe same daLa buL sLarLs wlLh Lhe producL, ln order
Lo deLecL proflLs on a producL basls (SCL, Cfflce, vlsual SLudlo). Moreover, he mlghL be lnLeresLed ln a Lhlrd
hlerarchy LhaL sLarLs wlLh Lhe leaves of Lhe sLandard one Lo deLecL Lhe LoLal of expenses and revenues for
employees, llcenses and so on. More generally, we, as good 8l analysLs, wanL Lo glve hlm a Lool LhaL leLs
hlm creaLe any klnd of hlerarchy, rearranglng Lhe leaves of Lhe orlglnal hlerarchy under a new sLrucLure
LhaL he can bulld by hls own.
1he flnal soluLlon we wanL Lo bulld has Lhese characLerlsLlcs:
Lach leaf of Lhe orlglnal balance sheeL may be moved anywhere ln Lhe new hlerarchy
users can move only leaves, Lhe lnLermedlaLe nodes of Lhe orlglnal hlerarchy have no daLa
assoclaLed wlLh Lhem and so we cannoL use Lhem Lo bulld a new hlerarchy. We mlghL wanL Lo
relax Lhls rule by provldlng Lhe capablllLy Lo move lnLermedlaLe nodes buL, for Lhe sake of
slmpllclLy, we adopL lL.
Lach leaf mlghL change lLs slgn ln Lhe new hlerarchy (SCL 2003 expenses are poslLlves ln Lhe
orlglnal hlerarchy, buL we mlghL wanL Lo aggregaLe Lhem as negaLlve on Lhe producL hlerarchy,
whlle reLalnlng Lhe values ln Lhe facL Lable as poslLlve).
1he new hlerarchy does noL need Lo lnclude all Lhe leaves of Lhe orlglnal hlerarchy. lf we
conslder a much more complex balance sheeL, lL ls obvlous LhaL some klnds of analysls do noL
need Lo look aL all Lhe leaves. Some analysls mlghL concenLraLe on a subseL of daLa, lgnorlng
Lhe oLhers and sLlll belng a good analysls.
1he user mlghL declde LhaL many leaves ln Lhe orlglnal hlerarchy should be aggregaLed under a
slngle node ln Lhe new hlerarchy. ln Lhe prevlous example, Lhe new dlmenslon mlghL lnclude a
uevelopmenL producLs" node LhaL condenses boLh SCL 2003 and vlsual SLudlo Lrees, wlLhouL
golng down Lo Lhe slngle leaf level. 1hls can be useful Lo produce a hlghly aggregaLed hlerarchy
LhaL shows only Lop nodes qulckly.
All Lhe hlerarchles wlll be conLalned ln a slngle dlmenslon. We wlll use Lhe MulLlple Plerarchles
paLLern Lo malnLaln all Lhe user-deflned hlerarchles lnLo a slngle dlmenslon. Clearly, we wlll
exLend lL Lo fulflll our new needs.
As we wlll see, Lhls model ls a derlvaLlon of Lhe MulLlple Plerarchles model, buL lnLroduces several levels of
complexlLy and lL needs a much more lnLrlcaLe uuM model. We wlll need Lo creaLe an adequaLe L1L phase
and so we wlll go deep ln Lhe descrlpLlon of some of Lhe L1L sLeps needed Lo bulld Lhe model.
1he mosL common scenarlo for Plerarchy 8eclasslflcaLlon ls LhaL of Lhe balance sheeL LhaL we wlll descrlbe
ln Lhe lmplemenLaLlon. Powever, we can use Lhe same model Lo creaLe reclasslflcaLlon whenever we face a
parenL/chlld hlerarchy.
8efore Lhe Lechnlcal deLalls, look aL Lhe mosL classlcal balance sheeL daLabase model ln llgure 91.
www. sql bi . com


82 The Many-to-Many Revolution

Figure 91 Standard Bal ance Sheet model
We have a balance sheeL wlLh a parenL/chlld hlerarchy, Lhe sLandard daLe dlmenslon and some operaLlons
LhaL belong Lo a speclflc balance node and LhaL compose lLs LoLal.
1hls slmple model ls useful for a slngle parenL/chlld hlerarchy. 1he unaryCperaLor column ln Lhe
ulm_8alance dlmenslon ls Lhe fleld used as Lhe unary operaLor ln Lhe parenL/chlld speclflcaLlon.
IMPLEMENTATION
1he lmplemenLaLlon of Lhe 8alance 8eclasslflcaLlon model needs Lo use a more complex sLrucLure, shown
ln llgure 92.

Figure 92 Bal ance Recl assification Model
LeL us revlew Lhe sLrucLure ln more deLall:
Dim_Balance
PK ID_Balance
FK1 ID_BalanceFather
COD_Balance
Balance
UnaryOperator
Dim_Date
PK ID_Date
Date
Fact_Operations
PK ID_FactOperation
FK1 ID_Balance
FK2 ID_Date
Amount
!"#$%&'&()*
!" #$%&'(')*+
+,- .!$%&'&()*+&/0*1
34!$%&'&()*
%&'&()*
5(&1647*1&/81
+&)/$47*1&/"8(9
!" #$%,'*-./+0'-12)
+,- .!$!&/*
+,: .!$%&'&()*
;#8<(/
!"#$!&/*
!" #$%$'-+
!&/*
%1"=>*%&'&()*?"*1&1)0"*9
!" #$%&0134+&'(')*+51+0'0*67
+,- .!$%&'&()*
+,@ .!$%&'&()*?"*1&1)06A8=*
+,: 5(&1647*1&/81
!"#$%&'&()*?"*1&1)0"*9
!" #$%&'(')*+51+0'0*67823+
%&'&()*?"*1&1)06
+,- .!$%&'&()*?"*1&1)06A8=*+&/0*1
%&'&()*?"*1&1)06A8=*
5(&1647*1&/81
!"#$5(&1647*1&/81
!" 9)'07./+0'-20

The Many-to-Many Revolution 83

1he brldge Lable acLs as a brldge beLween Lhe orlglnal balance sheeL and Lhe new dlmenslon
ulm_8alancePlerarchles LhaL, followlng Lhe MulLlple Plerarchles model, wlll conLaln all Lhe
hlerarchles separaLed by Lhe 8alancePlerarchy column.
We wlll noL use ulm_8alance's unaryCperaLor column, we wlll use Lhe column wlLh Lhe same
name ln ulm_8alancePlerarchles lnsLead, wlLh Lhe same meanlng buL wlLhouL Lhe SSAS bullL-ln
mechanlsm Lo handle unary operaLors, whlch do noL work wlLh many-Lo-many relaLlonshlps.
As one of Lhe requlslLes of Lhe model ls LhaL some of Lhe leaves ln ulm_8alance appear under
only one node of Lhe new hlerarchy, lL ls posslble LhaL many rows ln Lhe brldge Lable reference
only a slngle row ln ulm_8alancePlerarchles, for one slngle hlerarchy. 1hls could be useful ln
Lhe MulLlple Plerarchles paLLern, buL ln Lhls model lL ls noL only an opLlon, lL ls one of Lhe
fundamenLals of Lhe model. keep lL ln mlnd, as lL wlll be useful laLer.
Moreover, we need a unary operaLor ln Lhe brldge Lable ln order Lo deflne lf Lhe balance row
wlll be summed Lo or subLracLed from Lhe LoLal of Lhe 8alancePlerarchy node. 1he
ulm_unaryCperaLor dlmenslon conLalns only Lwo rows: one for SuM and one for Su818AC1.
1he careful reader should remember LhaL we already sald LhaL unary operaLors do noL work
when used wlLh many Lo many relaLlonshlps. ln facL, Lhe unaryCperaLor columns of boLh
ulm_8alance and ulm_8alancePlerarchles are noL used by Lhls mulLldlmenslonal model. We
have lnLroduced Lhem Lo make Lhlngs clearer, buL we wlll end up wlLh a model LhaL does noL
rely on Lhe unaryCperaLor feaLure of SSAS. lnsLead, Lhe ulm_unaryCperaLor dlmenslon wlll
Lake care of Lhe lnLerpreLaLlon of unary operaLors, wlLh Lhe help of some Mux code. Powever,
ln Lhe demo code we generaLe Lhe unaryCperaLor ln Lhe 8rldge8alancePlerarchles vlew
sLarLlng from Lhe ulm_8alancePlerarchles unaryCperaLor, by leveraglng on a SCL query LhaL
expand Lhe orlglnal hlerarchy lnLo Lhe compleLe llsL of accounLs (leaf nodes) LhaL have Lo be
aggregaLed for each hlerarchy node.
Cne problem LhaL was sLlll open ln Lhe MulLlple Plerarchles model ls Lhe facL LhaL some cllenLs do noL fllLer
dlmenslons based on oLher fllLers. lor lnsLance, even lf we make a fllLer for 8alancePlerarchy name, Lhe
cllenL wlll sLlll leL us choose among all Lhe nodes ln Lhe ulm_8alancePlerarchy parenL/chlld hlerarchy. ln
Lhls model, we wlll address Lhe problem and show Lhe flnal soluLlon LhaL uses Lhe hlerarchy names as rooL
nodes of Lhe compleLe hlerarchy.
!"#$%&#' )* +,- .#"/0 )1-/"+)/
1he flrsL problem we have Lo face ls Lhe facL LhaL we cannoL rely on Lhe unary operaLor feaLure of Analysls
Servlces. 1hus, we wlll need Lo handle Lhe complexlLy of unary operaLor by ourselves.
We have deflned a speclflc dlmenslon (ulm_unaryCperaLor) LhaL wlll leL us deflne, Lhrough Lhe relaLlonshlp
wlLh Lhe brldge Lable, whlch operaLlon Lo use for each of Lhe nodes from ulm_8alance. uslng some slmple
Mux code, we can dlvlde values from Lhe facL Lable ln SuM and Su818AC1, compuLe Lhe dlfference
beLween Lhem and Lhe show Lhe resulL Lo Lhe user. 1herefore, lf Lhe L1L compuLes correcLly Lhe values ln
Lhe brldge Lable, Lhe handllng of Lhe unary operaLor seems sLralghLforward.
1he problem ls LhaL we cannoL assoclaLe a unlque operaLlon Lo a node, when aggregaLed aL Lhe balance
hlerarchy level. 1o undersLand Lhe problem, suppose LhaL you have a balance composed of only four
lndependenL nodes (C, u, l, C) and LhaL we wanL Lo creaLe on lL a sLrucLure (A,8,L) llke Lhls:
www. sql bi . com


84 The Many-to-Many Revolution
n|erarchy Node 8a|ance kemarks
A A ls Lhe rooL node, lL conLalns (8 - L)
+8 -C 8 ls an lnLermedlaLe node, lL conLalns u - C
+u
-L +l L ls an lnLermedlaLe node, lL conLalns l - C
-C
Tabl e 14 Bal ance recl assification formul as
lL ls qulLe easy Lo see LhaL Lhe slgn of C, for example, ls noL deflnable a prlorl". When C ls aggregaLed Lo L
lL needs Lo have Lhe MlnuS slgn (Lhe compleLe expresslon of L ls (l-C)) whlle, when lL ls aggregaLed Lo A, lL
wlll have a LuS slgn (Lhe compleLe expresslon of A ls (u-C-l+C)).
We cannoL mark C wlLh a speclflc slgn. lLs slgn depends on Lhe paLh LhaL we are Lraverslng ln Lhe Lree Lo
reach lL. SSAS unary operaLor handles all LhaL buL, as we cannoL use LhaL feaLure, we need Lo flnd a uuM
model LhaL solves Lhe problem.
lL wlll be very helpful LhaL Lhe facL LhaL a slngle row ln Lhe hlerarchy dlmenslon can reference many rows ln
Lhe balance sheeL dlmenslon and each of Lhose rows can have a slgn. lf we expand, for each node ln Lhe
hlerarchy, Lhe compleLe expresslon LhaL compuLes lLs value from Lhe balance sheeL, we wlll be able Lo
deflne a speclflc slgn of each balance row when aggregaLed Lo each row ln Lhe hlerarchy. ln oLher words,
Lhe slgn ls unlque when we know Lhe 8alance Plerarchy node and Lhe 8alance node.
ln Lhe followlng Lable, we show, for each node ln Lhe hlerarchy, Lhe expanded expresslon based solely on
balance rows.
n|erarchy Node Lxpress|on SUM SU81kAC1
A u-C-l+C u C C l
+8 u-C u C
-L l-C l C
Tabl e 15 Bal ance recl assification formul as expanded
now, even lf Lhe C node does noL have a speclflc slgn Lhrough all Lhe hlerarchy (lL appears boLh on Lhe SuM
and Su818AC1 columns), lL does have a speclflc slgn for a slngle hlerarchy node. lf, wlLh Lhls sLrucLure, we
wanL Lo compuLe Lhe value of Lhe A node, we can Lake Lhe sum of u and C and subLracL from lL Lhe sum of
C and l. We wlll show Lhe Mux code LhaL does Lhls compuLaLlon laLer.
WhaL ls lmporLanL Lo undersLand aL Lhls polnL ls Lhe facL LhaL, due Lo Lhe lack of Lhe unary operaLor feaLure,
we wlll need Lo use Lhe brldge Lable Lo hold Lhe compleLe expanded expresslon of each hlerarchy node
along wlLh Lhe slgn of each balance row when aggregaLed Lo LhaL speclflc hlerarchy node. Moreover, Lhe
L1L phase of Lhls model geLs compllcaLed. We wlll need Lo wrlLe some recurslve code Lo Lraverse Lhe
hlerarchy Lree and deflne, for each node, Lhe compleLe expresslon.
We are now compuLlng, for each hlerarchy node, Lhe compleLe value. 1herefore, we need Lo Lell SSAS noL
Lo perform any compuLaLlon by lLself. 8y defaulL, SSAS wlll sum up chlldren Lo Lhelr faLher, causlng each
node Lo have a much hlgher value Lhan expecLed.
1here ls a unary operaLor LhaL wlll Lell SSAS Lo lgnore Lhe chlldren durlng compuLaLlon of Lhe faLher: lL ls Lhe
Lllde characLer ~". 1herefore, Lo make Lhe hlerarchy work as we wanL, we wlll need Lo deflne Lhe unary
operaLor value for all Lhe nodes ln Lhe parenL/chlld hlerarchy Lo Lllde.

The Many-to-Many Revolution 85

23&#' 456 +) -71"#$ +,- -71/-33&)#3
1he formula expanslon L1L and Lhe conflguraLlon phases of Lhls model are complex. We wanL Lo Lake a
closer look aL code LhaL handles Lhe balance reclasslflcaLlon.
ln Lhe conflguraLlon, we have a Lable (Conflg_8rldge8alancePlerarchles) LhaL conLalns Lhe assoclaLlons
beLween hlerarchles and balance accounLs sLaLlng, for each hlerarchlcal leaf node, Lhe balance accounLs
and Lhe unary operaLor LhaL wlll be used for Lhe aggregaLlon of Lhe balance accounL lnLo Lhe hlerarchlcal
one.
1hls Lable should conLaln, among all Lhe oLher hlerarchles, a sLandard hlerarchy named 8ALAnCL SPLL1"
LhaL ls a perfecL copy of Lhe orlglnal balance sheeL hlerarchy. 1hls hlerarchy ls very useful for some
purposes:
lL glves Lhe user Lhe ablllLy Lo use only one parenL/chlld sLrucLure Lo analyze boLh Lhe sLandard
and Lhe user-deflned hlerarchles. We wlll see LhaL Lhls ls mandaLory: ln order Lo make Lhe
model work, we wlll need Lo remove Lhe parenL/chlld hlerarchy from Lhe soluLlon, avoldlng any
lnLerference beLween Lhe SSAS unary operaLor and our model.
lL musL show exacLly Lhe daLa LhaL we can check agalnsL Lhe orlglnal hlerarchy. We wlll
exLenslvely use lL Lo verlfy LhaL boLh Lhe L1L and SSAS compuLaLlons are correcL.
1he L1L LhaL creaLes Lhe hlerarchles ls sLralghLforward and we wlll noL descrlbe lL. 1he only complex parL ls
Lhe expanslon of Lhe formulas needed Lo compuLe each hlerarchy node uslng Lhe balance sheeL nodes. We
wlll need Lo Lraverse Lhe Lree and evaluaLe Lhe relaLed formula for each node.
1raverslng Lhe Lree uslng SCL ls easy uslng recurslve querles. neverLheless, we need a more complex
algorlLhm, as we wanL Lo compuLe Lhe flnal formula for each node of Lhe Lree.
1he Lrlck ls Lo perform a compleLe Lraversal of Lhe Lree conslderlng each slngle node as Lhe rooL of a
subLree LhaL need Lo be compleLely Lraversed and flaLLened, ln order Lo be able Lo reconsLrucL, for each
slngle node, Lhe compleLe formula LhaL compuLes lLs value. 1he followlng ls Lhe deflnlLlon of Lhe
8rldge8alancePlerarchles vlew used for Lhe 8rldge 8alance Plerarchles lnLermedlaLe measure group. As we
sald, Lhe relaLlonshlp beLween leaf nodes ln ulm_8alancePlerarchles dlmenslon and accounLs ln
ulm_8alance are deflned by Lhe Conflg_8rldge8alancePlerarchles Lable, whlch mlghL conLaln a llsL of
accounLs for a slngle node ln Lhe hlerarchy. 1hls ls common ln balance reclasslflcaLlon. Powever, remember
LhaL relaLlonshlps for lnLermedlaLe nodes ln Lhe hlerarchy wlll be generaLed by Lhls vlew. 8emember Lhls
when you populaLe Lhe Conflg_8rldge8alancePlerarchles Lable, oLherwlse you mlghL obLaln dupllcaLed
rows ln Lhe resulL of Lhls vlew.
www. sql bi . com


86 The Many-to-Many Revolution
H<%I
$/.V;1B5AB96+/9: )!;J1OT !;J1RT 4B:0F+!;J12 -! )
!"#"$% EeGT EeGT EeG
'=<5= -## !"#"$% EeGT EfET EfE
'=<5= -## !"#"$% EfET EeGT EfE
'=<5= -## !"#"$% EfET EfET EeG
2T
]6F617B%9BB%96LB9:B9 -! )
!"#"$%
<?8]6F617BI;B9697K@4//+ D ],<?8]6F617BI;B9697K@=/CBT
<?8]6F617BI;B9697K@=/CB D ],<?8]6F617BI;B9697K@=/CBT
'169@5AB96+/9 D ],'169@5AB96+/9T
]6F617BI;B9697K@=/CB D ],]6F617BI;B9697K@=/CB
345( ?;.8]6F617BI;B9697K;B: ]
'=<5= -##
!"#"$%
<?8]6F617BI;B9697K@4//+ D %,<?8]6F617BI;B9697K@4//+T
<?8]6F617BI;B9697K@=/CB D ],<?8]6F617BI;B9697K@=/CBT
'169@5AB96+/9 D )!"#"$% $6:+ )4B:0F+!;J1 -! $I-4 )O22
345( $/.V;1B5AB96+/9:
HI"4" !;J1O D ],'169@5AB96+/9 -=? !;J1R D %,'169@5AB96+/92T
]6F617BI;B9697K@=/CB D ],]6F617BI;B9697K@=/CB
345(
]6F617B%9BB%96LB9:B9 %
<=="4 >5<= ?;.8]6F617BI;B9697K;B: ]
5= ],<?8]6F617BI;B9697K@=/CB36+KB9 D %,<?8]6F617BI;B9697K@=/CB
-=? ],<?8]6F617BI;B9697K@=/CB36+KB9 ZY ],<?8]6F617BI;B9697K@=/CB2T
4B7/1:+907+I;B9697K@ -! )
!"#"$%
%,<?8]6F617BI;B9697K@4//+T
%,<?8]6F617BI;B9697K@=/CBT
],<?8]6F617BT
]6F617BI;B9697K@=/CB D %,]6F617BI;B9697K@=/CBT
'169@5AB96+/9 D )!"#"$% $-!% )4B:0F+!;J1 -: $K69 )O22
345( $/.V;1B5AB96+/9:
HI"4" !;J1O D ],'169@5AB96+/9 -1C !;J1R D
%,'169@5AB96+/92T
5],$5?8]6F617BT
5],]6F617B
345(
]6F617B%9BB%96LB9:B9 %
#"3% 5'%"4 >5<= $/1*;J8]9;CJB]6F617BI;B9697K;B: ]
5= ],<?8]6F617BI;B9697K@=/CB D %,<?8]6F617BI;B9697K@=/CB
#"3% 5'%"4 >5<= ?;.8]6F617B 5]
5= 5],<?8]6F617B D ],<?8]6F617B
HI"4" ]6F617B <! =5% ='##
2
!"#"$%
<?8]6F617BI;B9697K@4//+T
<?8]6F617BT
<?8'169@5AB96+/9
345(
4B7/1:+907+I;B9697K@
#"3% 5'%"4 >5<= ?<(8'169@5AB96+/9
5= 4B7/1:+907+I;B9697K@,'169@5AB96+/9 D ?;.8'169@5AB96+/9,'169@5AB96+/9
1he query seems complex buL, ln reallLy, lL ls a slmple Lree Lraversal query wlLh Lhe pecullarlLy of Lhe
lu_8alancePlerarchy8ooL node LhaL wlll ldenLlfy, for each expanded expresslon, Lhe sLarLlng node. We wlll
use Lhe resulLs of Lhls query ln Lhe 8rldge8alancePlerarchles vlew, ln order Lo llnk each node wlLh Lhe
expanded expresslon LhaL compuLes lL. 1ake some Llme Lo undersLand Lhe query before golng on wlLh Lhe
model, because Lhls query ls bulldlng Lhe mosL complex Lable of Lhe model lLself.
8.&%$&#' +,- 9)$-%
uslng Lhe Lables descrlbed, Lhe resulLlng uuM model ls Lhe one shown ln llgure 93.

The Many-to-Many Revolution 87


Figure 93 Bal ance Recl assification UDM Model
1hls model ls very slmllar Lo LhaL of Lhe MulLlple Plerarchles. 1he maln dlfferences are:
1he ulm unary CperaLor ls used Lo dlvlde beLween nodes Lo sum or subLracL from Lhe LoLal
1he brldge Lable conLalns Lhe compleLe expresslon LhaL compuLes Lhe LoLal of each node ln Lhe
ulm 8alance Plerarchles.
1he dlmenslon usage pane ls sLralghLforward. We use Lhe brldge Lable Lo llnk Lhe facL Lable Lo boLh Lhe
balance hlerarchy dlmenslon and Lhe unary operaLor. 1here ls noLhlng sLrange here, [usL some many-Lo-
many relaLlonshlps llke you can see ln llgure 94.

Figure 94 Bal ance Recl assification UDM Model
1he lasL operaLlon LhaL we need Lo do ls Lo seL Lhe unary operaLor for all Lhe nodes ln Lhe ulm 8alance
Plerarchles dlmenslon Lo ~". We have done lL addlng a column (CubeunaryCperaLor) LhaL evaluaLes Lo ~
for each node ln Lhe mulLlple hlerarchles' dlmenslon.
www. sql bi . com


88 The Many-to-Many Revolution
We are now able Lo query Lhe cube analyzlng Lhe mulLlple hlerarchles. ln llgure 93 we puL a fllLer on Lhe
year, used Lhe ulm 8alance Plerarchles on Lhe row and puL Lhe ulm unary CperaLor on Lhe columns.

Figure 95 Excel Query with the Unary Operator
LveryLhlng seems good. We are now able Lo show all Lhe hlerarchles on one slngle excel worksheeL. We
have a slmple problem Lo solve LhaL ls relevanL Lo Lhe grand LoLal: lL always compuLes Lhe sum of lLs
chlldren. A slmple Mux Scope wlll solve Lhe problem, as you can see ln llgure 96.

The Many-to-Many Revolution 89


Figure 96 MDX code to compute the correct total with unary operators
WlLh Lhe Mux code, Lhe resulL ls exacLly whaL we wanLed Lo see. lease noLe LhaL we have SCCLd on Lhe
ulm unary CperaLor dlmenslon. lL mlghL be beLLer, dependlng on your speclflc needs, Lo use Lhe SCCL by
fllLerlng Lhe descendanLs of Lhe parenL/chlld hlerarchy ln order Lo use Lhe unary operaLor only when Lhe
hlerarchy ls selecLed, avoldlng any confuslon Lo Lhe user. ln llgure 97 you can see Lhe resulL of Lhe SCCL
calculaLlon [usL deflned.

Figure 97 Excel Query after MDX code to compute operators
www. sql bi . com


90 The Many-to-Many Revolution
Cne blg advanLage of havlng a slngle parenL/chlld dlmenslon LhaL has Lhe hlerarchy names as flrsL nodes ls
LhaL Lhe selecLlon of a speclflc hlerarchy ls very easy wlLh excel. lf you fllLer on Lhe ulm 8alance Plerarchles
dlmenslon, you wlll geL a very user-frlendly lnLerface llke shown ln llgure 98.

Figure 98 Fil tering the hierarchies is very easy
1he work ls noL flnlshed yeL. ?ou mlghL have noLlced LhaL Lhere ls no grand LoLal for Lhe rows ln any of Lhe
querles we have shown up Lo now. 1hls ls correcL. 1he many hlerarchles cannoL be mlxed up because of
Lhelr values represenLlng compleLely dlfferenL concepLs. Powever, even lf lL ls correcL, lL brlngs a very
annoylng problem: Lhe All" member of Lhe ulm 8alance Plerarchles evaluaLes Lo nuLL. ln oLher words,
Lhere ls no All" member for Lhls dlmenslon.
1he problem of noL havlng an All" member ln Lhe dlmenslon ls LhaL, ln order Lo be able Lo make any query
on Lhe cube wlLhouL Lhe ulm 8alance Plerarchles dlmenslon, we wlll have Lo mark Lhe dlmenslon hlerarchy
wlLh Lhe aLLrlbuLe lsAggregaLable" Lo lALSL. 1hls wlll make Lhe compuLaLlon worklng, buL lL ls a vlable
soluLlon only for very small 8l soluLlons. CLherwlse, SSAS wlll need Lo scan Lhe dlmenslon for each query,

The Many-to-Many Revolution 91

even for Lhose LhaL do noL conLaln lL. WlLh a medlum slzed soluLlon, Lhls ls deflnlLely a bad slLuaLlon and Lhe
user wlll be very unhappy abouL performances.
lorLunaLely, Lhere ls a good soluLlon Lo Lhe problem even lf lL lnvolves some Lrlcks Lo fool SSAS and make lL
work Lhe way we wanL lL Lo do. We wlll Lell SSAS LhaL Lhere ls no relaLlon aL all beLween Lhe facL Lable and
Lhe ulm 8alance Plerarchles dlmenslon. ln Lhls way, SSAS wlll compuLe all Lhe querles lgnorlng Lhe non-
aggregaLable dlmenslon. Powever, dolng Lhls, we wlll have no relaLlonshlps beLween Lhe ulm 8alance
Plerarchles and Lhe facL Lable: ln Lhls way, we are loslng Lhe ablllLy Lo use Lhe dlmenslon. We wlll solve Lhls
lssue by creaLlng a new dlmenslon LhaL we wlll call 8alance Plerarchles lLA1", whlch wlll conLaln exacLly
Lhe same nodes as ulm 8alance Plerarchles buL wlll noL conLaln any parenL/chlld hlerarchy. 1he name
lLA1" comes from Lhe facL LhaL Lhls dlmenslon ls ldenLlcal Lo lLs parenL/chlld source buL has no
parenL/chlld hlerarchles. WhaL ls Lhe advanLage of Lhe flaL chlld agalnsL Lhe hlerarchlcal one? 1he flaL
dlmenslon ls aggregaLable, whlle Lhe hlerarchlcal one ls noL.
AfLer Lhe creaLlon of Lhe new dlmenslon, we need Lo change Lhe dlmenslon usage by removlng Lhe
relaLlonshlp wlLh Lhe ulm 8alance Plerarchles and Lhen by movlng lL Lo Lhe flaL dlmenslon, as shown ln
llgure 99.

Figure 99 Dimension Usage with the FLAT dimension
1he querles wlLh Lhe flaL dlmenslon are very crypLlc, because Lhe dlmenslon, as lLs name lmplles, ls flaL and
does noL conLaln any hlerarchy, as you can see ln llgure 100.

Figure 100 Dimension Usage with the FLAT dimension
www. sql bi . com


92 The Many-to-Many Revolution
Powever, ln Lhls way we are able Lo make compuLaLlons worklng on an aggregaLable dlmenslon. 1he nexL
sLep wlll be LhaL of llnklng Lhe aggregaLable dlmenslon Lo Lhe hlerarchlcal one.
Mux funcLlon SLr1oMember" can asslsL us here. Slnce Lhe flaL and hlerarchlcal dlmenslons are Lhe same,
Lhey share Lhe prlmary lus. 1herefore, we know LhaL Lhe value of a node ln Lhe flaL hlerarchy ls Lhe same as
Lhe value ln Lhe hlerarchlcal one. We need Lo wrlLe some Mux code (llke Lhe one shown ln llgure 101) LhaL
wlll redlrecL Lhe querles made on Lhe hlerarchlcal dlmenslon Lo Lhe non-hlerarchlcal one.

Figure 101 MDX code for the redirection
1hls code wlll make Lhe brldge beLween Lhe flaL and Lhe hlerarchlcal dlmenslons and ls Lhe flnal Louch of
Lhls model. now SSAS wlll show Lhe values Laken from Lhe aggregaLable dlmenslon lnLo Lhe hlerarchlcal
one.
We mlghL declde Lo hlde Lhe flaL dlmenslon from Lhe model lf lL golng Lo confuse Lhe end user.
neverLheless, we need Lo conslder LhaL Lhe flaL dlmenslon mlghL come ln handy when Lhe user wanLs Lo
selecL a slngle node from Lhe hlerarchy Lo sllce lL uslng oLher dlmenslons. lL ls ofLen easler Lo selecL a node
from a flaL hlerarchy (when Lhe user knows exacLly whaL he wanLs Lo search for).
Cne lnLeresLlng quesLlon ls ls Lhls soluLlon equlvalenL Lo Lhe usage of unary CperaLors"? 1he answer ls
deflnlLely no, Lhere are some dlfferences buL Lhey are noL so easy Lo undersLand aL flrsL glance.
unary CperaLor ln Analysls Servlces works aL Lhe aggregaLlon level, whlle our soluLlon does noL
lnfluence aggregaLlons. 1hls means LhaL lf you analyze Lhe aggregaLlon of all amounL" uslng
Lhe sLandard parenL/chlld hlerarchy wlLh Lhe unary operaLor, you wlll geL Lhe LoLal compuLed
uslng Lhe unary operaLor (ln our example, you would geL Lhe dlfference beLween proflLs and
expenses). lor Lhls reason, we wlll need Lo remove Lhe unary operaLor from Lhe orlglnal
hlerarchy, because we do noL wanL lL Lo lnLerfere wlLh our lmplemenLaLlon of Lhe unary
operaLor.
Cur model ls dlfferenL from Lhe same lmplemenLaLlon wlLh many dlmenslons each havlng a
slngle parenL/chlld hlerarchy. lor Lhe same reason as before, lf you develop many parenL/chlld
hlerarchles wlLh unary operaLors Lhey wlll lnLerfere each oLher glvlng you very sLrange values.

The Many-to-Many Revolution 93

Moreover, havlng more Lhan one parenL/chlld hlerarchy wlLh unary operaLor wlll lead Lo very
poor performances, because Lhe dlfferenL hlerarchles wlll work on Lhe same daLa, slowlng
down all querles.
Cur model does noL handle operaLlons aparL from sum and subLracLlon. 1he model mlghL be
modlfled ln order Lo use oLher operaLlon, buL lL would become very complex and dlfflculL Lo
check. neverLheless, ln our experlence, sum and subLracLlon are Lhe mosL (lf noL Lhe only)
useful operaLlons.
1he 8alance 8eclasslflcaLlon model ls noL an easy one Lo lmplemenL. lL requlres aLLenLlon and paLlence boLh
durlng Lhe L1L developmenL and Lhe cube deslgn, buL lL glves Lo Lhe users a very easy way of lnLeracL wlLh
Lhe flnal soluLlon. Moreover, as wlLh all Lhe complex models, lL remalns hard Lo apply unLll you deeply
undersLand lL. AfLerwards, lL wlll become a very nlce Lool Lo presenL Lo users wlLh no secreLs aL all for you.
www. sql bi . com


94 The Many-to-Many Revolution
Considerations about Multidimensional Models
We examlned several models LhaL leverage on Lhe uuM many-Lo-many relaLlonshlps feaLure Lo solve real
world buslness problems. 1here are many oLher uses and scenarlos LhaL we have noL consldered here.
Many-Lo-many relaLlonshlps opened a wlde world of opporLunlLles. l hope LhaL Lhe models presenLed ln
Lhls paper wlll help you Lo approach Lhls new revoluLlonary world of daLa analysls.
1he mosL lmporLanL Lechnlque Lo masLer wlLh many-Lo-many relaLlonshlps ln Analysls Servlces ls Lhe use of
cascadlng many-Lo-many relaLlonshlps. 1he oLher sklll you have Lo acqulre ls Lhe ablllLy Lo creaLe a
relaLlonal model LhaL can easlly be represenLed ln a uuM, even lf Lhe relaLlonal model by lLself cannoL be
easlly querled by SCL. 8y leveraglng Lhe many-Lo-many relaLlonshlps, you may need relaLlvely slmple Mux
querles lnsLead of raLher complex SCL querles wlLh one or more subquerles.
unforLunaLely, several releases of Analysls Servlces have noL lmproved Lhe deslgner experlence ln creaLlng
a uuM wlLh many-Lo-many relaLlonshlps. lL can be very dlfflculL Lo add a measure group or a dlmenslon Lo
a uuM wlLh several many-Lo-many relaLlonshlps: many of Lhe cholces LhaL are offered when you selecL Lhe
lnLermedlaLe measure group do noL make sense, a beLLer order or a slmple hlnL suggesLlng Lhe mosL
probable rlghL cholce would have been more helpful.
erformance analysls and scalablllLy are areas LhaL requlre a furLher sLudy relaLed Lo daLa volume, Mux
querles and speclflc models. 8ecommendaLlons presenLed ln Lhls documenL mlghL refer Lo LesLs made ln
2003/2006. lmproved server memory and performance mlghL have enlarged Lhe llmlLs Lo whlch Lhe usage
of many-Lo-many relaLlonshlps can be used and should always be checked ln Lhe cusLomer's real scenarlo.
ln general, Lhe flexlblllLy provlded by Lhese models ls much more lmporLanL LhaL posslble degradaLlon ln
performance. WlLhouL preclse rules Lo anLlclpaLe performance lssues as a resulL of uslng Lhe many-Lo-many
relaLlonshlps, Lhe mosL effecLlve pracLlce ls Lo run LesLs measurlng Lhe response Llmes wlLh your own daLa.
leedbacks are mosL welcome: wrlLe us aL info@sqlbi.com!
LINKS
http://www.sqlbi.com/articles/many2many/ : Lhe pro[ecL home page for Lhls paper and
relaLed resources
http://www.sqlbi.com: communlLy dedlcaLed Lo 8uslness lnLelllgence wlLh SCL Server
http://sqlblog.com/blogs/marco_russo : blog of Marco 8usso (auLhor)
http://sqlblog.com/blogs/alberto_ferrari : blog of AlberLo lerrarl(auLhor)
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=137 : Analysls
Servlces Many-Lo-Many ulmenslons: Cuery erformance CpLlmlzaLlon 1echnlques (besL
pracLlces whlLe paper by SCLCA1 Leam)
http://www.sqlserveranalysisservices.com/OLAPPapers/IntroToMMDimensionsV2.htm :
lnLroducLlon Lo Many-Lo-Many ulmenslons by 8lchard 1kachuk (conLalns an explanaLlon of
vlsual 1oLal llmlLaLlons)
http://www.sqlbi.com/articles/sqlbi-methodology/ : Lhe SCL8l MeLhodology paper for besL
pracLlces ln 8l soluLlon deslgn

The Many-to-Many Revolution 95

http://www.amazon.com/gp/product/1847197221/?tag=se04-20 P 01( <,,X
MWQF(30 Y:<( I($(-,F*(&0 /)01 2)'3,+,40 567 5(3$(3 ?AAb "&%-8+)+ 5(3$)'(+N
/3)00(& <8 2%3', 9:++,; "-<(30, =(33%3) %&# Y13)+ Z(<<
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=891 P "&%-8+)+
5(3$)'(+ I)+0)&'0 Y,:&0 DF0)*)a%0),&
www. sql bi . com


96 The Many-to-Many Revolution
Tabular Models
1hls secLlon presenLs Lhe many-Lo-many relaLlonshlps applled Lo 8lSM 1abular.
A NOTE ABOUT UDM AND BISM ACRONYMS
ln 2011, MlcrosofL announced LhaL 8lSM (8uslness lnLelllgence SemanLlc Model) ls Lhe new acronym LhaL
groups all Lhe models LhaL you can creaLe wlLh Analysls Servlces. Whlle lnlLlally 8lSM was only referrlng Lo
Lhe models LhaL relles on Lhe new verLlpaq englne, Lhere are now Lwo cholces of modellng ln 8lSM: 8lSM
MulLldlmenslonal, formerly known as uuM, and 8lSM 1abular, Lhe one based on Lhe verLlpaq englne. ln
Lhls secLlon, we wlll refer Lo 8lSM 1abular by only uslng Lhe 8lSM acronym. ln a fuLure revlslon of Lhls
documenL, we wlll rename 8lSM Lo 8lSM 1abular and/or 1abular, ln order Lo beLLer polnL Lo Lhe correcL
deflnlLlon.
MODELING PATTERNS WITH MANY-TO-MANY
ln 2010, MlcrosofL lnLroduced owerlvoL and Lhe uAx programmlng language, along wlLh Lhe news LhaL
Lhe same daLa-modellng englne would be used for Lhe new 8l semanLlc model, avallable wlLh MlcrosofL SCL
Server uenall. 8oLh owerlvoL and 8lSM (8l SemanLlc Model) rely on Lhe same core Lechnology. 1hus,
from now on, we wlll refer Lo 8lSM as Lhe daLa-modellng Lool avallable ln boLh.
8lSM 1abular unexpecLedly lacks Lhe opLlon Lo handle many-Lo-many relaLlonshlps naLlvely. 1hus, lf we [usL
look aL Lhe surface, lL seems LhaL 8lSM ls one sLep back ln Lhe pasL, removlng Lhe supporL for such a
powerful daLa modellng opLlon. neverLheless, Lhe uAx programmlng language can easlly supersede Lhls
llmlLaLlon slnce we wlll be able Lo use many-Lo-many relaLlonshlps ln 8lSM Lhrough some uAx codlng. ln
Lhe nexL chapLers, we are golng Lo look aL several daLa models LhaL can be lmplemenLed Lhrough Lhe usage
of Lhe many-Lo-many paLLern ln uAx.
An advanLage of MulLldlmenslonal models ls Lhe ablllLy Lo seLup many-Lo-many dlmenslons ln a declaraLlve
way, whlch applles Lo all measures ln a measure group. lf a user does noL fllLer or sllce by a many-Lo-many
dlmenslon, Lhen Lhe many-Lo-many relaLlonshlps do noL affecL performance and Lhe query ls noL resolved
Lhrough Lhe brldge Lable. ln Lhe 1abular model, you musL creaLe one calculaLed measure per numerlc
column per many-Lo-many dlmenslon. 1he number of calculaLlons can qulckly grow exponenLlally.
Moreover, lncludlng many-Lo-many Lype calculaLlons wlll affecL query performance even when noL fllLerlng
by Lhese many-Lo-many dlmenslons ln a 1abular model.
We added some performance measuremenLs for many of Lhe scenarlos. When measurlng Lhe performance
of a 8l soluLlon, lL ls noL very lnLeresLlng Lo check aL mllllseconds. Moreover, such a measuremenL would
have Lurned lnLo a Loo complex descrlpLlon, loslng Lhe focus on daLa modellng. Cur maln lnLeresL ls ln Lhe
user experlence. ln our oplnlon, a 8l soluLlon ls well deslgned lf Lhe querles are answered ln a maLLer of Lwo
or Lhree seconds. lf Lhe user need Lo walL more Lo geL an answer, Lhen Lhe lnLeracLlve naLure of lvoL1able
ls broken. ln some very cases, we declded LhaL 10 seconds were Lhe upper llmlL, buL Lhls happened only for
very complex daLa models where Lhe user ls wllllng Lo walL some seconds Lo geL an answer.


The Many-to-Many Revolution 97

1hus, aL Lhe end of each scenarlo you wlll flnd some conslderaLlons abouL Lhe opLlmal slze of each lnvolved
Lable. All daLa for Lhe LesLs has been generaLed wlLh RedGate SQL Data Generator, uslng random values
for mosL of Lhe columns. We found Lhls Lool really lnvaluable Lo creaLe LesL seLs of dlfferenL slzes and wlLh
dlfferenL characLerlsLlcs. AL Lhe end, havlng daLa avallable proved Lo be very useful because a daLa model ls
worLhless lf lL brlngs poor performances. Pavlng Lhe ablllLy Lo LesL performances wlLh dlfferenL daLa seLs leL
us focus on Lhe mosL complex scenarlos where opLlmlzaLlons were sLlll needed.
www. sql bi . com


98 The Many-to-Many Revolution
Classical many-to-many Relationship
We wlll analyze a slLuaLlon where we have a very slmple many-Lo-many relaLlonshlp beLween Lwo
dlmenslons. Lven lf Lhe case ls very slmple, lL ls sLlll useful Lo analyze lL ln deLall because, laLer, Lhose deLalls
wlll geL more complex and we need Lo undersLand Lhem very well.
BUSINESS SCENARIO
Pere ls a Lyplcal buslness scenarlo drawn from Lhe bank buslness: we have a facL Lable LhaL descrlbes a
measure (ln Lhls case banklng LransacLlons) for a glven enLlLy (a bank accounL) LhaL can be [olned Lo many
members of anoLher dlmenslon (a [olnL accounL owned by several cusLomers).
1hose of you famlllar wlLh Lhe classlcal" mulLldlmenslonal model can already see Lhe dlfflculLy. lL ls noL
easy Lo descrlbe Lhe non-aggregaLlve naLure of measures [olned Lo dlmenslons wlLh a many-Lo-many
relaLlonshlp. ln Lhls case, each bank accounL can have one or more owners and each owner can have one or
more accounLs buL we should noL add Lhe cash of an owner Lo hls/her [olnL owners.
!"#$ &' !"#$ ())'*#& + ,*-&'./0
Bridge_AccountCustomer
PK,FK1 ID_Account
PK,FK2 ID_Customer
Dim_Account
PK ID_Account
Account
Dim_Customer
PK ID_Customer
CustomerName
Dim_Date
PK ID_Date
Date
Dim_Type
PK ID_Type
Type
Fact_Transaction
PK ID_Transaction
FK1 ID_Account
FK3 ID_Type
FK2 ID_Date
Amount

Figure 102 Cl assical many-to-many diagram
1here are many oLher scenarlos where Lhe classlcal many-Lo-many relaLlonshlp appears. 8ecause lL ls Lhe
slmplesL of all many-Lo-many relaLlonshlps, we use Lhls example Lo descrlbe ln deLall how many-Lo-many
relaLlonshlps work ln 8lSM.
BISM IMPLEMENTATION
1he flrsL Lhlng Lo say abouL 8lSM ls LhaL many-Lo-many are slmply noL supporLed. 1hls does noL mean LhaL
we wlll noL be able Lo make Lhem work, oLherwlse Lhls whlLepaper would end here, buL LhaL ln order Lo
leverage many-Lo-many we wlll need Lo wrlLe some uAx code and, mosL lmporLanL, undersLand whaL ls
golng on under Lhe cover ln Lerms of evaluaLlon conLexLs. 1hls seL of lnformaLlon wlll be lnvaluable wlLh Lhe
followlng scenarlos, where Lhe golng geLs Lhough.

The Many-to-Many Revolution 99

lf we sLarL querylng Lhls daLa model wlLh a lvoL1able, Lhe flrsL resulL ls, as expecLed, noL worklng (see
llgure 103).

Figure 103 Many-to-many showing wrong results
We can see LhaL Lhe same amounL ls repeaLed for all of Lhe cusLomers. Cn Lhe oLher hand, Lhe ulm_1ype
works flne slnce lL ls relaLed dlrecLly Lo Lhe facL Lable. ulm_CusLomer has only an lndlrecL relaLlonshlp wlLh
Lhe lacL_1ransacLlon Lable Lhrough Lhe many-Lo-many sLrucLure bullL by 8rldge_AccounLCusLomer.
ln order Lo undersLand how Lo make many-Lo-many work, lL ls lmporLanL Lo noLe a few Lhlngs:
lf we fllLer ulm_CusLomer, Lhe Lable 8rldge_AccounLCusLomer ls fllLered Loo. neverLheless,
auLomaLlc fllLer propagaLlon sLops Lhere due Lo Lhe dlrecLlon of Lhe relaLlonshlp. 1hus, Lhe
ulm_AccounL Lable ls noL fllLered.
lf we fllLer Lhe ulm_AccounL Lable, Lhe facL Lable ls fllLered Loo due Lo auLomaLlc propagaLlon of
Lhe fllLer conLexL Lhrough relaLlonshlps.
1he laLLer sLaLemenL can be easlly seen ln llgure 104.

Figure 104 Direct relationship lead to correct results
8ecause ulm_AccounL has a dlrecL relaLlonshlp wlLh Lhe facL Lable, lL works flne as a sllcer for Lhe
LransacLlons.
1hus, Lo solve our scenarlo lL wlll be enough Lo fllLer Lhe ulm_AccounL Lable by wrlLlng some code LhaL
Lakes Lhe exlsLlng fllLer on ulm_CusLomer and bullds a new fllLer, on ulm_AccounL, LhaL shows only Lhe
accounLs of Lhe selecLed cusLomers.
now, how can we deLecL whlch accounLs are Lled Lo Lhe selecLed cusLomers? We need Lo check, for each
accounL, lf Lhere ls a row ln Lhe 8rldge_AccounLCusLomer LhaL ls relaLed Lo a selecLed cusLomer. lnsLead of
showlng Lhe flnal formula, leL us bulld lL sLep-by-sLep.
We can creaLe a slmple measure llke Lhls:
=0.5*$0:+/.B9: gD $5'=%45H! )]9;CJB8-77/01+$0:+/.B92
www. sql bi . com


100 The Many-to-Many Revolution
When used ln a lvoL1able wlLh Lhe accounLs on rows, lL glves Lhe lnLeresLlng (and expecLed) resulL shown
ln llgure 103.

Figure 105 COUNTROWS of the bridge tabl e
1he measure slmply counLs, for each accounL, Lhe number of cusLomers Lled Lo Lhe accounL. 1he grand
LoLal ls clearly lncorrecL, because lL counLs a slngle cusLomer for each accounL Lo whlch he belongs. 1hls ls
noL lnLeresLlng because we are noL golng Lo use Lhe formula Lo counL Lhe cusLomers aL Lhe grand LoLal
level.
lf we slmply add a sllcer Lo Lhe prevlous lvoL1able and selecL Mark, we wlll geL Lhe resulL shown ln llgure
106.

Figure 106 FILTERED COUNTROWS of the bridge tabl e
lllLerlng Lhe cusLomer has no effecL on Lhe AmounL, buL Lhe number of cusLomers" column has changed
lLs values and ls now showlng 1" for Lhe accounLs LhaL belong Lo Mark. 1he reason ls LhaL Lhe
8rldge_AccounLCusLomer ls fllLered by Lhe sllcer (Lhe fllLer on cusLomer ls propagaLed Lo Lhe brldge). 1hus,
none of Lhe cusLomers LhaL are selecLed ylelds a value of zero.
AL Lhls polnL, Lhe procedure should be preLLy clear: Lo move Lhe fllLer from Lhe cusLomer Lo Lhe accounLs,
we need Lo deLecL all Lhe accounLs for whlch Lhe numCfCusLomers measure has a value greaLer Lhan zero.
1he flrsL formula mlghL be llke Lhls:
-./01+(R( gD

$-#$'#-%" )
!'( )367+8%961:67+;/1b-./01+c2T
3<#%"4 )
?;.8-77/01+T
b=0.5*$0:+/.B9:c Y W
2
2
We creaLe a fllLer conLexL on ulm_AccounL conLalnlng only Lhe accounLs for whlch Lhe numCfCusLomers ls
greaLer Lhan zero. AfLer havlng applled Lhls fllLer, Lhe ulm_AccounL Lable ls fllLered, showlng only Lhe
accounLs of selecLed cusLomers and Lhe SuM of amounL ylelds a correcL resulL, as lL can be seen ln Lhe
llgure 107.

The Many-to-Many Revolution 101


Figure 107 First version of amountm2m
1he non-addlLlve naLure of many-Lo-many becomes evldenL lf we add Lhe cusLomers on Lhe rows and
remove Lhe fllLer. 1he resulL ls lllusLraLed ln llgure 108.

Figure 108 Final result of amountm2m
lL ls very easy Lo check LhaL Lhe grand LoLal ls noL Lhe sum of Lhe slngle amounLs, as lL ls expecLed from such
a formula. AL Lhe grand LoLal level, each accounL ls counLed only once, even lf lL appears under more Lhan
one cusLomer.
now, Lhe flnal Louch ls Lo remove Lhe helper measure numCfCusLomers, whlch ls useful only Lo compuLe
Lhe AmounLM2M measure, and lncorporaLe lLs code lnslde a slngle formula. A flrsL Lrlal mlghL be:
-./01+(R(8H9/1J gD

$-#$'#-%" )
!'( )367+8%961:67+;/1b-./01+c2T
3<#%"4 )
?;.8-77/01+T
!"#$%&"'( *+,-./012334567!587490,: ; <
2
2
lf we use Lhls formula ln Lhe lvoL1able, we geL Lhe wrong resulL shown ln llgure 109.
www. sql bi . com


102 The Many-to-Many Revolution

Figure 109 Missing a calculate leads to wrong results
AL Lhe leaf level Lhe values are correcL (because Lhe fllLer from AccounL ls worklng), whereas aL Lhe
cusLomer level (yellow cells) all values are lncorrecLly compuLed as 3000.
1he reason ls LhaL, ln order Lo fllLer Lhe brldge Lable uslng Lhe accounL, Lhe accounL should be presenL ln Lhe
fllLer conLexL, so LhaL exlsLlng relaLlonshlp ls consldered. ln our formula Lhe accounL ls lLeraLed by Lhe row
conLexL lnLroduced by llL1L8 buL ls never pushed lnLo a fllLer conLexL. 1he prevlous formula worked
because, durlng Lhe llL1L8 lLeraLlon, we were calllng a measure LhaL, by deflnlLlon, ls compuLed as lf lL was
auLomaLlcally surrounded by a CALCuLA1L. CALCuLA1L Lransforms Lhe row conLexL lnLo a fllLer conLexL,
maklng lL follow relaLlonshlps and fllLerlng, ln Lurn, Lhe facL Lable.
ln order Lo make our formula work, lL ls enough Lo use an expllclL CALCuLA1L ln place of Lhe lmpllclL one:
-./01+(R( gD

$-#$'#-%" )
!'( )367+8%961:67+;/1b-./01+c2T
3<#%"4 )
?;.8-77/01+T
!2=!#=2%> *!"#$%&"'( *+,-./012334567!587490,: ; <:
2
2
lease, Lake a look aL Lhe hlghllghLed parL of Lhe formula and Lake Lhe Llme necessary Lo undersLand lL,
because lL ls Lhe core of any many-Lo-many formula we are golng Lo wrlLe from now on.
1he key ls Lo move Lhe fllLer from Lhe farLhesL Lable Lo Lhe nearesL one uslng Lhe brldge Lo check lf Lhe
accounL rows should be made vlslble or noL, dependlng on Lhe selecLlon on cusLomers. 1he lnnermosL
CALCuLA1L ls needed Lo converL Lhe row conLexL lnLo a fllLer one so LhaL Lhe brldge Lable ls fllLered from
Lwo sldes: Lhe cusLomers from Lhe orlglnal fllLer conLexL and Lhe accounLs from Lhe lLeraLlon. When boLh
fllLers are acLlve, Lhe number of rows vlslble ln Lhe brldge Lable ls elLher zero or one: zero for accounLs LhaL
should be hldden, one for accounLs LhaL should be vlslble.
Cnce you masLer Lhls formula, all of Lhe remalnlng scenarlos wlll be affordable. lf you do noL fully
undersLand lL, Lhen all of Lhe followlng scenarlo wlll be lmposslble Lo undersLand because Lhey all use Lhe
same paLLern Lo make many-Lo-many relaLlonshlps work ln 8lSM.

The Many-to-Many Revolution 103

DENALI IMPLEMENTATION
ln Lhe prevlous paragraphs, we have shown Lhe formula LhaL works ln uAx 1.0, Lhe verslon of Lhe language
avallable ln owerlvoL. ln Lhe new verslon of SCL Server codename uenall", Lhere ls a new way Lo auLhor
Lhe same formula by means of uslng Lhe new SuMMA8lZL funcLlon.
-./01+(R( gD

$-#$'#-%" )
!'( )367+8%961:67+;/1b-./01+c2T
(#??2&@A> *+,-./012334567!587490,B C-912334567D@C12334567E:
2
1he performance of Lhls new formula are beLLer, because we do noL use an lLeraLor, lnsLead we ask uAx Lo
reLurns us Lhe values of ulmAccounL[lu_AccounL] whlch can be reached Lhrough Lhe relaLlonshlp exlsLlng
from Lhe brldge Lo ulm_AccounL. lL ls lmporLanL Lo noLe LhaL we need Lo use ulm_AccounL[lu_AccounL] and
noL 8rldge_AccounLCusLomer[lu_AccounL] as Lhe summarlzed column. 1he laLLer, ln facL, wlll noL fllLer Lhe
facL Lable.
Avoldlng Lhe usage of Lhe lLeraLor, verLlpaq ls able Lo push Lhe relaLlonshlp down Lo Lhe sLorage englne,
provldlng beLLer performance over blg Lables.
ln Lhls paper, we wlll use boLh Lypes of formulas, dependlng on Lhe conLexL. We feel LhaL Lhe llL1L8 verslon
ls easler Lo undersLand, because lL shows clearly Lhe algorlLhm whlle Lhe SuMMA8lZL verslon ls fasLer and
more conclse. 1hus, for educaLlonal purposes, we wlll normally provlde Lhe descrlpLlon of Lhe formulas wlLh
Lhe llL1L8 verslon and provlde Lhe SuMMA8lZL verslon of Lhe same formula aL Lhe end, so LhaL Lhe reader
can appreclaLe Lhe dlfference and have boLh worklng formulas aL hand.
PERFORMANCE ANALYSIS
lrom Lhe performance polnL of vlew, lL ls lnLeresLlng Lo noLe LhaL Lhls formula conLalns a slngle lLeraLlon,
whlch ls Lhe one lnLroduced by llL1L8. 1hls means LhaL Lhe Llme requlred Lo reLrleve a value ls dependenL
on Lhree facLors:
Slze of Lhe LransacLlon Lable
Slze of Lhe accounL Lable
Slze of Lhe brldge Lable
uurlng our LesLs lL Lurned ouL LhaL Lhe slze of Lhe LransacLlon Lable ls noL very lmporLanL, a 30 mllllon rows
Lable ls compuLed preLLy fasL. 1he algorlLhm ls much more senslble Lo Lhe slze of Lhe accounL and of Lhe
brldge Lable. Moreover, normally Lhe Lwo Lables have a slmllar cardlnallLy because each accounL ls llnked Lo
many cusLomers, so Lhey share Lhe overall slze.
www. sql bi . com


104 The Many-to-Many Revolution
Cascading many-to-many Relationships
When we apply Lhe many-Lo-many relaLlonshlp several Llmes ln a cube, we have Lo pay aLLenLlon lf Lhere ls
a chaln of many-Lo-many relaLlonshlps. As we have seen ln Lhe classlcal many-Lo-many relaLlonshlp
scenarlo, dlmenslons LhaL apparenLly do noL relaLe Lo a brldge measure group could be meanlngful and
lmporLanL for Lhe enhancemenL of Lhe analyLlcal capablllLles of our model.
We call Lhe slLuaLlon where Lhere ls a chaln of many-Lo-many relaLlonshlps a cascadlng many-Lo-many
relaLlonshlp".
!"#$ &' !"#$ ())'*#& + ,*-&'./0
!"#$ 1' !"#$ ,*-&'./0 + ,"&/2'0$
Bridge_AccountCustomer
PK,FK1 ID_Account
PK,FK2 ID_Customer
Bridge_CustomerCategory
PK,FK2 ID_Customer
PK,FK1 ID_Category
Dim_Account
PK ID_Account
Account
Dim_Category
PK ID_Category
CategoryName
Dim_Customer
PK ID_Customer
CustomerName
Dim_Date
PK ID_Date
Date
Dim_Type
PK ID_Type
Type
Fact_Transaction
PK ID_Transaction
FK1 ID_Account
FK3 ID_Type
FK2 ID_Date
Amount

Figure 110 Cascading many-to-many diagram
ln Lhe plcLure, we can see LhaL - ln order Lo assoclaLe a caLegory Lo a LransacLlon - we need Lo Lraverse Lwo
dlfferenL many-Lo-many relaLlonshlps: Lhe flrsL one from accounL Lo cusLomer and Lhe second one from
cusLomer Lo caLegory. We say LhaL Lhe chaln sLarLs from Lhe ulmCaLegory and ends Lo ulm_AccounL,
Lraverslng Lwo many-Lo-many relaLlonshlps.

The Many-to-Many Revolution 105

BUSINESS SCENARIO
A Lyplcal scenarlo ls Lhe case when a dlmenslon far from Lhe maln facL Lable (a dlmenslon LhaL relaLes Lo
one brldge facL Lable) ls lnvolved ln an exlsLlng many-Lo-many relaLlonshlp and has anoLher many-Lo-many
relaLlonshlp wlLh anoLher dlmenslon.
lor example, conslder bank accounL scenarlo shown ln Lhe prevlous plcLure. 1he maln characLerlsLlcs of Lhe
daLa model are:
AccounL LransacLlons: 1ransacLlons facL Lable relaLed Lo ulm uaLe, ulm AccounL and ulm 1ype.
Lach accounL can have one or more owners (cusLomers): ulm AccounL has a many-Lo-many
relaLlonshlp wlLh ulm CusLomer Lhrough a brldge Lable.
Lach cusLomer can be classlfled lnLo one or more caLegorles: ulm CusLomer has a many-Lo-
many relaLlonshlp wlLh ulm CaLegorles Lhrough anoLher brldge Lable.
ln order Lo undersLand Lhe examples, we need Lo descrlbe some of Lhe daLa LhaL we wlll use ln our
lmplemenLaLlon. 1he nexL Lable shows Lhe denormallzed facL Lable. Lven lf Lhe uaLe dlmenslon ls noL
sLrlcLly necessary for Lhls explanaLlon, we wlll keep lL ln Lhe model because lL ls a common dlmenslon ln a
slmllar scenarlo and lL ls useful Lo see how lL relaLes Lo Lhe oLher dlmenslons.
Account 1ype Date Amount
Mark Cash deposlL 20031130 1000.00
aul Cash deposlL 20031130 1000.00
8oberL Cash deposlL 20031130 1000.00
Luke Salary 20031130 1000.00
Mark-8oberL Salary 20031130 1000.00
Mark-aul Cash deposlL 20031130 1000.00
Mark A1M wlLhdrawal 20031203 -200.00
8oberL CredlL card sLaLemenL 20031210 -300.00
aul CredlL card sLaLemenL 20031213 -300.00
Luke A1M wlLhdrawal 20031213 -200.00
Tabl e 16 Denormalized model for cascading many-to-many
1he 1ype dlmenslon ls very lmporLanL for our purposes: lL descrlbes Lhe Lype of Lhe LransacLlon and lL ls
useful Lo group LransacLlons across oLher dlmenslons.
LeL us see some klnd of quesLlons Lhe user may ask upon Lhese daLa:
WhaL ls Lhe salary/lncome for Lhe l1 enLhuslasL" caLegory?
Pow many dlfferenL LransacLlon Lypes lnvolve Lhe 8ally drlver" caLegory?
WhaL cusLomer caLegorles have A1M wlLhdrawal LransacLlons?
WlLhln Lhe facL Lable, Lhere ls noL enough lnformaLlon Lo provlde answers Lo Lhose quesLlons buL all whaL
we need ls sLored ln Lables (dlmenslons) reachable Lhrough Lhe many-Lo-many relaLlonshlps. We only have
Lo creaLe Lhe correcL relaLlonshlps beLween dlmenslons. 1he followlng Lable conLalns Lhe relaLlonshlp
exlsLlng beLween cusLomers and caLegorles ln our sample daLa:
www. sql bi . com


106 The Many-to-Many Revolution
Customer Category
Mark l1 enLhuslasL
8oberL l1 enLhuslasL
aul 8ally drlver
8oberL 8ally drlver
Luke 1raveler
Mark 1raveler
aul 1raveler
8oberL 1raveler
Tabl e 17 Relationships between customers and categories
now, Lo glve an answer Lo Lhe flrsL quesLlon (WhaL ls Lhe salary/lncome for Lhe l1 enLhuslasL" caLegory?)
we need an addlLlonal clarlflcaLlon.
lf we conslder Lhe accounLs owned by only one person, Lhen Lhere are no cusLomers belonglng
Lo Lhe l1 enLhuslasL" caLegory who geL a salary lncome.
lf we conslder [olnL accounLs (e.g. Mark and 8oberL boLh own Lhe same accounL), Lhen Lhelr
owners recelve a salary lncome even lf we do noL know who ls really galnlng money.
lrom Mark's perspecLlve, he recelves a salary lncome of 1000. Cn Lhe oLher slde, 8oberL geLs a salary
lncome of 1000 Loo! Powever, unforLunaLely for Lhem, from Lhe perspecLlve of l1 enLhuslasL" caLegory we
cannoL counL Lhe same salary lncome Lwo Llmes, so Lhe l1 enLhuslasL" salary lncome ls sLlll 1000 and noL
2000. 1he Lough reallLy ls LhaL Mark and 8oberL have Lo share Lhls slngle salary lncome, because we have
no oLher way Lo know whlch of Lhem ls really recelvlng Lhls lncome, because we recorded Lhe LransacLlon
agalnsL Lhelr [olnL accounL.
8efore looklng aL Lhe lmplemenLaLlon, leL us Lry Lo answer Lhe prevlous Lhree quesLlons wlLh a lvoL1able.
We wlll use only a lvoL1able wlLh some sllcers Lo answer all of Lhem.
WhaL ls Lhe salary/lncome for Lhe l1 enLhuslasL" caLegory?
1o solve Lhls problem lL ls enough Lo selecL Lhe Lype and caLegory from Lhe sllcer and we geL
Lhe resulL shown ln llgure 111.

Figure 111 Cascading m2m example

The Many-to-Many Revolution 107

ln Lhe prevlous flgure lL ls evldenL LhaL Lhe value of 1,000.00 ls shown for boLh Mark and
8oberL, because lL belongs Lo Lhe currenL accounL owned by boLh even lf, aL Lhe caLegory level,
lL ls sLlll 1,000.00.
Pow many dlfferenL LransacLlon Lypes lnvolve Lhe 8ally drlver" caLegory?
Lven ln Lhls case Lhe quesLlon can be answered by easlly changlng Lhe fllLers ln Lhe sllcers, as
you can see ln llgure 112.

Figure 112 Cascading m2m example
1he rally drlvers are aul and 8oberL and Lhe LransacLlon Lypes are shown ln Lhe columns.
WhaL cusLomer caLegorles have Cash ueposlL LransacLlons?
SelecLlng Lhe Lype of LransacLlon, we easlly geL Lhe llsL of caLegorles (l1 enLhuslasL, 1raveler and
8ally urlver) llke Lhose you can see ln llgure 113.

Figure 113 Cascading m2m example
BISM IMPLEMENTATION
ln order Lo solve Lhls scenarlo, we are golng Lo develop a modlfled verslon of Lhe formula we have already
seen for Lhe classlcal many-Lo-many relaLlonshlp. 1he ma[or modlflcaLlon needed ls Lo Lake lnLo accounL Lhe
cascadlng naLure of Lhe new relaLlonshlp.
1he orlglnal formula for many-Lo-many had Lhe need Lo push" a fllLer conLexL from Lhe Lable used Lo sllce
daLa lnLo Lhe Lable on Lhe oLher slde of Lhe brldge relaLlonshlp, ln effecL forclng Lhe brldge Lable Lo geL
double fllLered" so Lo creaLe a fllLer on Lhe dlmenslon LhaL ls dlrecLly relaLed wlLh Lhe facL Lable. ln Lhe
cascadlng many-Lo-many we wlll need Lo do Lhe same process walklng Lwo sLeps lnsLead of a slngle one.
www. sql bi . com


108 The Many-to-Many Revolution
lor example, lf Lhe user selecLs a caLegory, we wlll need Lo Lake Lhe fllLer conLexL of Lhe ulmCaLegory Lable
and push lL Lo a fllLer conLexL on ulm_AccounL, Lraverslng Lhe Lwo many-Lo-many deflned by
8rldge_CusLomerCaLegory flrsL and 8rldge_CusLomerAccounL nexL.
WlLh Lhls descrlpLlon ln mlnd, Lhe formula ls sLralghLforward:
-./01+3/9$6+BJ/9@ D

$-#$'#-%" )
$-#$'#-%" )
!'( )367+8%961:67+;/1b-./01+c2T
3<#%"4 )
?;.8-77/01+T
$-#$'#-%" )$5'=%45H! )]9;CJB8-77/01+$0:+/.B92 Y W2
2
2T
3<#%"4 )
?;.8$0:+/.B9T
$-#$'#-%" )$5'=%45H! )]9;CJB8$0:+/.B9$6+BJ/9@2 Y W2
2
2
lL ls composed by Lwo nesLed CALCuLA1L. 1he ouLer one fllLers Lhe cusLomers based on Lhe caLegory, Lhe
lnner one fllLers Lhe accounLs based on Lhe cusLomers (whlch are fllLered by Lhe prevlous CALCuLA1L). 1he
formula makes evldenL Lhe cascadlng naLure of Lhe relaLlonshlp.
1he complexlLy of Lhls formula ls clearly dependlng on Lhe slze of Lhe brldge Lables, because lL ls composed
by Lwo fllLers, each of whlch needs Lo lLeraLe one of Lhe Lwo brldge Lables. 8ecause Lhe Lwo fllLer
operaLlons are carrled on sequenLlally, Lhe complexlLy should be relaLed Lo Lhe producL of Lhe slze of Lhe
Lwo brldge Lables.
ln uenall, Lhe same formula can be wrlLLen as
-./01+3/9$6+BJ/9@ D

$-#$'#-%" )
$-#$'#-%" )
!'( )367+8%961:67+;/1b-./01+c2T
!'((-4<h" )]9;CJB8-77/01+$0:+/.B9T ?;.8-77/01+b<?8-77/01+c2
2T
!'((-4<h" )]9;CJB8$0:+/.B9$6+BJ/9@T ?;.8$0:+/.B9b<?8$0:+/.B9c2
2
As usual, Lhe uenall verslon ls much more compacL, even lf lLs behavlor ls somehow less clear, aL flrsL
glance.
uurlng performance LesLlng, we have noLlced LhaL Lhe lvoL1able ls able Lo answer very qulckly regardless
of Lhe slze of Lhe facL Lable. We LesLed 10 and 30 mllllons of rows ln Lhe lacL Lable and performance dld noL
change slgnlflcanLly, leadlng Lo a good user experlence. 1hlngs changed when we sLarLed Lo change Lhe
number of cusLomers and, consequenLly, Lhe slze of Lhe brldge Lables. We have used Lhe followlng
parameLers for daLa generaLlon:
Lach cusLomer has an average of 1.2 accounLs (l.e. 12 accounLs every 10 cusLomers) and
belongs Lo an average of 3.4 caLegorles.

The Many-to-Many Revolution 109

We LesLed an lncreaslng number of cusLomers and deLecLed LhaL Lhe opLlmal user experlence ls
wlLh 200.000 cusLomers, whlch means 680.000 rows ln Lhe 8rldge_CusLomerCaLegory and
240.000 rows ln Lhe 8rldge_AccounLCusLomer.
ln such a scenarlo, all of Lhe querles reLurn resulLs ln less Lhan 2/3 seconds.
lL ls lnLeresLlng Lo noLe LhaL Lhls model supporLs even much more complex calculaLlons wlLh a mlnlmum
efforL. lor example, lf we wanL Lo compuLe Lhe number of dlsLlncL accounLs per caLegory LhaL have
LransacLlons ln a perlod of Llme, we can wrlLe Lhls formula:
?;:+;17+-77/01+: D

$-#$'#-%" )
$-#$'#-%" )
!"#$%&"'( *C@(%@$!% *FG371%,G68G37-46D@C12334567E::T
3<#%"4 )
?;.8-77/01+T
$-#$'#-%" )$5'=%45H! )]9;CJB8-77/01+$0:+/.B92 Y W2
2
2T
3<#%"4 )
?;.8$0:+/.B9T
$-#$'#-%" )$5'=%45H! )]9;CJB8$0:+/.B9$6+BJ/9@2 Y W2
2
2
1he only changed parL ls Lhe lnnermosL calculaLlon, whlch now counLs Lhe number of dlsLlncL accounLs. 1he
Llme requlred for Lhe compuLaLlon of Lhls formula ls noL slgnlflcanLly dlfferenL Lhan Lhe slmpler SuM,
resulLlng ln 4/3 seconds for Lhe mosL complex querles (l.e. coverlng all of Lhe caLegorles and all of Lhe
LransacLlons, sllced by year on Lhe columns).
1hls paLLern can be easlly adapLed wlLh cascadlng relaLlonshlps LhaL need Lo Lraverse more Lhan Lwo sLeps.
?ou should Lake care of selecLlng Lhe correcL orderlng of fllLers, sLarLlng wlLh Lhe farLhesL one from Lhe facL
Lable and movlng one sLep afLer each oLher ln Lhe dlrecLlon of Lhe facL Lable.
neverLheless, before leavlng Lhls scenarlo, lL ls worLh conslderlng dlfferenL modellng opLlons LhaL are
avallable ln 8lSM. 8ecause ln 8lSM many-Lo-many are noL handled dlrecLly by Lhe sysLem, we are free Lo
choose a dlfferenL daLa model Lo reduce Lhe number of sLeps ln Lhe compuLaLlon. 1he ldea ls Lo flaLLen Lhe
cascadlng relaLlonshlp uslng a slngle Lable LhaL holds Lhe compleLe chaln of relaLlonshlps beLween
cusLomers, accounLs and caLegorles. 1hls new daLa model ls clearly exposed ln Lhe llgure 114.
www. sql bi . com


110 The Many-to-Many Revolution
!"#$"%&'( *"'+ ,- *"'+ ./",,0'0%
Dim_Date
PK ID_Date
Date
Dim_Account
PK ID_Account
Account
Dim_Type
PK ID_Type
Type
Dim_Customer
PK ID_Customer
CustomerName
Dim_Category
PK ID_Category
CategoryName
Fact_Transaction
PK ID_Transaction
FK1 ID_Account
FK3 ID_Type
FK2 ID_Date
Amount
Bridge_AccountCustomerCategory
FK1 ID_Account
FK3 ID_Customer
FK2 ID_Category

Figure 114 Fl attened cascading many-to-many diagram
ln Lhls daLa model, Lhe scenarlo ls LhaL of a classlcal many-Lo-many relaLlonshlp, Lhe cascadlng sLrucLure ls
gone. We call Lhls daLa model Lhe flaLLened cascadlng many-Lo-many". Such a daLa sLrucLure can be easlly
creaLed uslng a SCL query llke Lhe followlng one:
!"#"$%
-$,<?8-77/01+T
$$,<?8$0:+/.B9T
$$,<?8$6+BJ/9@
345(
(R(8$6:76C;1J,]9;CJB8$0:+/.B9$6+BJ/9@ $$
<=="4 >5<= (R(8$6:76C;1J,]9;CJB8-77/01+$0:+/.B9 -$
5= $$,<?8$0:+/.B9 D -$,<?8$0:+/.B9
1hls leads Lo Lhe Lable shown ln llgure 113, where we have puL Lhe denormallzed names Lo make lL clearer.

Figure 115 Fl attened cascading table

The Many-to-Many Revolution 111

?ou can see LhaL, ln Lhe boxed area, Lhe accounL Mark-8oberL ls repeaLed for each caLegory Lo whlch Mark
or 8oberL belong. uslng such a sLrucLure Lhe formula becomes easler Lo wrlLe, slnce lL ls ldenLlcal Lo Lhe
classlcal many-Lo-many one:
-./01+3F6++B1BCD

$-#$'#-%" )
!'( )367+8%961:67+;/1b-./01+c2T
3<#%"4 )
?;.8-77/01+T
$-#$'#-%" )$5'=%45H! )]9;CJB8-77/01+$0:+/.B9$6+BJ/9@22 Y W
2
2
Moreover, Lhls flnal formula runs fasLer Lhan Lhe prevlous one, whlch means LhaL you wlll be able Lo handle
blgger Lables wlLhouL compromlslng Lhe user experlence.
1hus, Lhe cascadlng many-Lo-many model can be easlly solved ln 8lSM uslng elLher Lhe cascadlng paLLern or
a flaLLened one. 1he laLLer glves beLLer resulLs ln Lerms of slmpllclLy of formulas and query speed.
www. sql bi . com


112 The Many-to-Many Revolution
Survey
1he survey scenarlo ls a common example of a more general case where we have many aLLrlbuLes
assoclaLed wlLh a case (one cusLomer, one producL, and so on). We wanL Lo normallze Lhe model because
we do noL wanL Lo change Lhe daLa model each Llme we add a new aLLrlbuLe (e.g. addlng a new dlmenslon
or changlng an exlsLlng one).
1he common scenarlo ls a quesLlonnalre conslsLlng of quesLlons LhaL have predeflned answers wlLh boLh
slmple and mulLlple cholces. 1he classlcal relaLlonal soluLlon ls Lo deflne a facL Lable and Lhree dlmenslons:
ulm CuesLlons wlLh Lhe quesLlons.
ulm Answers for Lhe answers provlded by cusLomers
ulm CusLomer for Lhe cusLomer who answered a speclflc quesLlon
1he facL Lable wlll conLaln a value lndlcaLlng Lhe exacL answer from Lhe cusLomer, ln Lhe case of mulLlple
cholces.
Powever, slnce we do noL need Lo analyze quesLlons wlLhouL answers, a beLLer soluLlon ls Lo have only one
Lable for boLh quesLlons and answers. 1hls wlll reduce Lhe number of dlmenslons wlLhouL havlng any
lnfluence on Lhe expresslvlLy of Lhe model and wlll make Lhe compleLe soluLlon slmpler Lo boLh navlgaLe
and creaLe. 1he sLar schema model (one facL Lable wlLh answers [olned wlLh a quesLlons/answers
dlmenslon and a case dlmenslon) ls fully queryable uslng SCL.
Powever, once we move Lo uuM or 8lSM Lhlngs become harder: whlle lL ls very slmple Lo compare
dlfferenL answers Lo Lhe same quesLlon, lL could be very dlfflculL Lo correlaLe frequency counLs of answers
Lo more Lhan one quesLlon. lor example, lf we have a quesLlon asklng for sporLs pracLlced (mulLlple
cholces) and anoLher one asklng for [ob performed, probably we would llke Lo know whaL paLLern of
sLaLlsLlcal relaLlonshlps - lf any - exlsL beLween Lhe Lwo correspondlng seLs of answers.
1he normal way Lo model lL ls havlng Lwo dlfferenL aLLrlbuLes (or dlmenslons) LhaL users can comblne on
rows and columns of a plvoL Lable. unforLunaLely, havlng an aLLrlbuLe for each quesLlon ls noL very flexlble
and becomes a real problem as Lhe number of quesLlons grows over Llme. We wlll need Lo change Lhe sLar
schema Lo accommodaLe havlng a slngle row ln Lhe facL Lable for each case. 1hls makes lL very dlfflculL Lo
handle any mulLlple-cholce quesLlon.
lnsLead, we can change our perspecLlve and leverage many-Lo-many relaLlonshlps. We can bulld a flnlLe
number (as many as we wanL) of quesLlons/answers dlmenslons, dupllcaLlng many Llmes Lhe orlglnal one
and provldlng Lhe user wlLh a number of fllLer" dlmenslons LhaL can be crossed lnLo a plvoL Lable or can be
used Lo fllLer daLa LhaL, for each case, saLlsfy deflned condlLlons for dlfferenL quesLlons.
BUSINESS SCENARIO
LeL us explore Lhe survey scenarlo ln more deLall. uaLa ls conLalned ln Lhe relaLlonal schema shown ln
llgure 116.

The Many-to-Many Revolution 113

Dim_Customers
PK ID_Customer
Customer
FK1 ID_Category
Dim_Questions
PK ID_Question
Question
Fact_Answers
FK2 ID_Answer
FK1 ID_Customer
Dim_Answers
PK ID_Answer
FK1 ID_Question
Answer
Dim_Categories
PK ID_Category
Category

Figure 116 Survey many-to-many diagram
Lach cusLomer belongs Lo a caLegory, and glves several answers Lo Lhe quesLlonnalre. Lach answer ls Lhen
relaLed Lo Lhe quesLlon. Lach cusLomer can provlde more Lhan one answer Lo each quesLlon (l.e. mulLlple
cholces are supporLed by Lhls daLa model).
1hls model ls good Lo sLore Lhe raw daLa buL, from Lhe analyLlcal polnL of vlew, lL ls noL very easy Lo query.
1herefore, we are golng Lo bulld a query model on Lop of Lhls sLrucLure, whlch ls composed by:
1wo lllLer Lables, whlch we wlll can lllLer1 and lllLer2. Lach fllLer Lable ls composed by [olnlng
ulm_Answers and ulm_CuesLlons, merglng Lhem lnLo a slngle enLlLy LhaL conLalns boLh
answers and quesLlons. Cbvlously, Lhe query should be loaded Lwlce ln Lhe daLa model Lo
creaLe Lhe Lwo fllLer dlmenslons.
Cne CusLomer Lable, creaLed by [olnlng CusLomers and CaLegorles and denormallzlng Lhe daLa
sLrucLure.
1he facL Lable, as lL ls presenL ln Lhe relaLlonal model.
1he analyLlcal model ls shown ln llgure 117.
Filter1
PK ID_Answer
Question
Answer
Filter2
PK ID_Answer
Question
Answer
Answers
FK1,FK2 ID_Answer
FK3 ID_Customer
Customers
PK ID_Customer
Customer
Category

Figure 117 Survey analytical diagram
1hls new daLaseL wlll be used ln a lvoL1able Lo perform cross querles. lor example, we can fllLer a speclflc
quesLlon ln lllLer1 and Lhe see Lhe proflle of people who answered LhaL quesLlon, llke ln Lhe reporL shown
ln llgure 118.
www. sql bi . com


114 The Many-to-Many Revolution

Figure 118 Survey report example
ln Lhls speclflc reporL we are looklng aL [ob, movles preferences and oLher characLerlsLlcs of all Lhe people
dlvlded beLween Male and lemale.
BISM IMPLEMENTATION
8efore we dlve lnLo Lhe uAx code, leL us focus on Lhe algorlLhm. ln order Lo calculaLe Lhe numbers we need
Lo:
ldenLlfy Lhe cusLomers LhaL answered Male or lemale Lo Lhe Cender quesLlon, whlch ls
selecLed Lhrough lllLer1. 1he answer of lllLer1 ls, ln Lhe example, on Lhe columns.
Check whaL Lhose cusLomers answered agalnsL lllLer2 (l.e. CuesLlon2 and Answer2, on Lhe
rows ln Lhe example), compuLe Lhe values and show Lhem ln Lhe lvoL1able.
Slnce we have a llmlLaLlon ln Lhe relaLlonshlp deflnlLlon ln 8lSM, we cannoL creaLe a relaLlonshlp beLween
lu_Answer ln Answers and Lhe Lwo lllLer Lables, because Lhe column lu_Answer can be used only for one
relaLlonshlp. 1hus, ln Lhe 8lSM daLa model we are noL golng Lo leverage Lhe relaLlonshlps ln Lhe model. All
of Lhe relaLlonshlps beLween lllLer 1 and 2 and Lhe Answers Lable wlll be emulaLed by uAx code.
LeL us sLarL wlLh sLep 1, l.e. ldenLlfy Lhe cusLomer LhaL has glven a speclflc answer Lo Lhe quesLlon fllLered
by lllLer1. 1he uAx code ls noL very hard Lo wrlLe:
$0:+/.B9$/01+3;F+B9O D

<3 )
$5'=%45H! )U-#'"! )3;F+B9Ob<?8-1:MB9c22 D OT
$-#$'#-%" )
$5'=%45H! )$0:+/.B9:2T
3<#%"4 )
$0:+/.B9:T
$-#$'#-%" )
$5'=%45H! )-1:MB9:2T
-1:MB9:b<?8-1:MB9c D U-#'"! )3;F+B9Ob<?8-1:MB9c22
Y W
2
2
2

The Many-to-Many Revolution 115

1he lnlLlal ll ls needed because Lhe compuLaLlon can be carrled on lf and only lf Lhe currenL fllLer conLexL
conLalns a slngle answer. lf Lhls ls Lhe case, we use a classlcal many-Lo-many formula wlLh Lhe slmple
addlLlon of a fllLer Lo Lhe Answers Lable LhaL makes vlslble only Lhe rows LhaL are ln relaLlonshlp wlLh Lhe
only answer selecLed ln lllLer1.
1he uenall verslon of Lhe same formula looks lnLeresLlng Loo, because of Lhe need Lo use CALCuLA1L1A8LL
as one of Lhe fllLer for Lhe ouLermosL CALCuLA1L:
D<3 )
$5'=%45H! )U-#'"! )3;F+B9Ob<?8-1:MB9c22 D OT
$-#$'#-%" )
$5'=%45H! )$0:+/.B9:2T
$-#$'#-%"%-]#" )
!'((-4<h" )-1:MB9:T $0:+/.B9:b<?8$0:+/.B9c2T
-1:MB9:b<?8-1:MB9c D U-#'"! )3;F+B9Ob<?8-1:MB9c2
2
2
2
1he CALCuLA1L1A8LL ls needed Lo emulaLe Lhe relaLlonshlp beLween Answers and lllLer1. 8y modlfylng
Lhe daLa model addlng an lnacLlve relaLlonshlp beLween Answers and lllLer1, as ln flgure llgure 119, we can
rely on uSL8LLA1lCnSPl and geL a new formula.

Figure 119 Inactive rel ationships in the Survey data model
1he formula wlLh uSL8LLA1lCnSPl ls clearer:
D<3 )
I-!5="U-#'" )3;F+B9Ob<?8-1:MB9c2T
$-#$'#-%" )
$5'=%45H! )$0:+/.B9:2T
$-#$'#-%"%-]#" )
!'((-4<h" )-1:MB9:T $0:+/.B9:b<?8$0:+/.B9c2T
'!"4"#-%<5=!I<\ )-1:MB9:b<?8-1:MB9cT 3;F+B9Ob<?8-1:MB9c2
2
2
2
ln Lhe formula, we have made use of PASCnLvALuL Loo, whlch makes lL easler Lo read,
1hls flrsL formula, ln any of lLs flavors, produces a reporL llke Lhe one ln llgure 120.
www. sql bi . com


116 The Many-to-Many Revolution
! We will now continue the description on the 1.0 version of the formula
because the Denali version is not working and will cause Excel to crash,
due to some bug in the beta release of PowerPivot.
At the end of this chapter, we have added the Denali formula with some
explanation about how it works but, at the Denali CTP3 release time, the
only working solution is the 1.0 version of the formula.

Figure 120 First trial of survey formul a
now, Lhe lnLeresLlng parL ls LhaL Lhe CCun18CWS ln Lhe formula ls evaluaLed ln a fllLer conLexL where only
Lhe cusLomers LhaL have answered Lo Lhe quesLlon ln lllLer1 are vlslble. 1hus, ln LhaL conLexL, we can use a
slmllar paLLern Lo verlfy whaL Lhose cusLomers have answered Lo Lhe quesLlon evenLually fllLered by lllLer2.
lL ls Llme Lo look aL Lhe compleLe formula for Lhe survey model:

The Many-to-Many Revolution 117

$0:+/.B9$/01+ D
<3 )
$5'=%45H! )U-#'"! )3;F+B9Ob<?8-1:MB9c22 D O ii $5'=%45H! )U-#'"! )3;F+B9Rb<?8-1:MB9c22 D
OT
$-#$'#-%" )
!2=!#=2%> *
!"#$%&"'( *!587490,8:B
F@=%>& *
!587490,8B
!2=!#=2%> *
!"#$%&"'( *268H0,8:B
268H0,8D@C1268H0,E I J2=#>( *F-K70,LD@C1268H0,E::
; <
:
:B
3<#%"4 )
$0:+/.B9:T
$-#$'#-%" )
$5'=%45H! )-1:MB9:2T
-1:MB9:b<?8-1:MB9c D U-#'"! )3;F+B9Ob<?8-1:MB9c22
Y W
2
2
2
?ou can easlly see LhaL Lhe lnner parL of Lhe formula (Lhe hlghllghLed one) follows Lhe same paLLern of Lhe
orlglnal one. 1he blg dlfference ls LhaL Lhls Llme Lhe formula ls evaluaLed ln a fllLer conLexL LhaL ls already
fllLered based on lllLer 2 Lo show only Lhe cusLomer who answered a speclflc answer on lllLer 1. ln oLher
words, boLh fllLers lnLersecL each oLher. Moreover, Lhe hlghllghLed formula compuLes Lhe number of
cusLomers who answered a speclflc quesLlon ln lllLer2, followlng Lhe relaLlonshlp from Answer Lo lllLer2
uslng uAx code, exacLly as we dld for lllLer1.
lf we use Lhls formula ln a lvoL1able, we geL Lhe lnLeresLlng resulL shown ln llgure 121.

Figure 121 Final survey example
www. sql bi . com


118 The Many-to-Many Revolution
1hls reporL ls lnLeresLlng, because lL shows, for each cusLomer who answered Lo Lhe Cender quesLlon,
whlch oLher quesLlons he answered (lncludlng Lhe answers). 1here are a couple of Lhlngs Lo noLe here,
looklng aL Lhe hlghllghLed parL of Lhe flgure:
lL seems LhaL somebody has answered boLh Male and lemale Lo Lhe same quesLlon. lf you look
carefully aL Lhe prevlous flgure, where all Lhe cusLomers are shown, you wlll easlly check LhaL
Leonard 8lLLer" ls Lhe gullLy. 1hls happens wlLh random generaLed daLa, we do noL need Lo
worry abouL LhaL buL lL ls nlce Lo see LhaL Lhe problem ls evldenL ln Lhe reporL and can be
addressed.
1he oLher polnL ls LhaL, because we have already fllLered Lhe Cender quesLlon, we mlghL noL be
lnLeresLed ln looklng agaln aL Lhe Cender quesLlon on Lhe rows. We already know LhaL we are
looklng aL people LhaL have answered Male or lemale Lo Lhe Cender quesLlon.
1he laLLer lssue ls Lhe mosL lnLeresLlng one, because lL has a very neaL soluLlon ln uAx by means of uslng
fllLer conLexLs. WhaL we really wanL Lo ask ls Clven Lhe quesLlon ln lllLer1, shown whaL people have
answered Lo oLher quesLlons, l do noL really mlnd Lhe quesLlon l have already selecLed, only dlfferenL
ones".
1he flnal formula looks llke Lhls:
$0:+/.B9$/01+ D
D<3 )
$5'=%45H! )U-#'"! )3;F+B9Ob<?8-1:MB9c22 D O ii $5'=%45H! )U-#'"! )3;F+B9Rb<?8-1:MB9c22 D
OT
$-#$'#-%" )
$-#$'#-%" )
$5'=%45H! )$0:+/.B9:2T
3<#%"4 )
$0:+/.B9:T
$-#$'#-%" )
$5'=%45H! )-1:MB9:2T
-1:MB9:b<?8-1:MB9c D U-#'"! )3;F+B9Rb<?8-1:MB9c22
Y W
2
2T
3<#%"4 )
$0:+/.B9:T
$-#$'#-%" )
$5'=%45H! )-1:MB9:2T
-1:MB9:b<?8-1:MB9c D U-#'"! )3;F+B9Ob<?8-1:MB9c22
Y W
2T
F-K70,LDM5087-46 LE N; J2=#>( *F-K70,ODM5087-46 OE:
2
2
We have added a condlLlon Lo Lhe ouLer CALCuLA1L where we baslcally say LhaL we are noL lnLeresLed, ln
Lhe counL, ln Lhe slLuaLlon where Lhe quesLlon ln lllLer2 ls Lhe same quesLlon already selecLed ln lllLer1.
1hls slmple condlLlon removes Lhe annoylng dupllcaLes. 1he flnal reporL ls Lhe one shown aL Lhe beglnnlng
of Lhls secLlon and shown agaln ln llgure 122.

The Many-to-Many Revolution 119


Figure 122 Survey with more checks leads to better results
lllLer1 now selecLs Lhe Cender quesLlon and Lhe same quesLlon ls no longer shown on Lhe rows, because lL
would be useless Lo repeaL Lhe same lnformaLlon.
Clearly, Lhe presence of oLher aLLrlbuLes ln Lhe cusLomer Lable, llke Lhe CaLegory, makes lnvesLlgaLlon of
lnformaLlon even more lnLeresLlng. 1he formula works flne even lf we add more fllLers Lo Lhe CusLomers
Lable by means of selecLlng a speclflc caLegory, as we show ln Lhe reporL ln llgure 123, where Lhe quesLlon
ln lllLer2 has been flxed and Lhe caLegory has been added Lo Lhe rows.

Figure 123 Adding other columns to the pivot table makes analysis more interesting
DENALI IMPLEMENTATION
As we sald durlng Lhe descrlpLlon, Lhe uenall verslon of Lhe formula ls noL worklng ln Lhe release used Lo
creaLe Lhls documenL. neverLheless, we feel LhaL lL ls lmporLanL Lo show Lhe compleLe formula so LhaL you
can Lry worklng on lL when Lhe nexL verslon of SCL Server wlll be avallable.
Pere ls Lhe compleLe formula:
www. sql bi . com


120 The Many-to-Many Revolution
<3 )
I-!5="U-#'" )3;F+B9Ob<?8-1:MB9c2 ii I-!5="U-#'" )3;F+B9Rb<?8-1:MB9c2T
$-#$'#-%" )
$-#$'#-%" )
$5'=%45H! )$0:+/.B9:2T
$-#$'#-%"%-]#" )
!'((-4<h" )-1:MB9:T $0:+/.B9:b<?8$0:+/.B9c2T
'!"4"#-%<5=!I<\ )-1:MB9:b<?8-1:MB9cT 3;F+B9Rb<?8-1:MB9c2
2
2T
$-#$'#-%"%-]#" )
!'((-4<h" )-1:MB9:T $0:+/.B9:b<?8$0:+/.B9c2T
'!"4"#-%<5=!I<\ )-1:MB9:b<?8-1:MB9cT 3;F+B9Ob<?8-1:MB9c2
2T
3;F+B9RbP0B:+;/1 Rc ZY U-#'"! )3;F+B9ObP0B:+;/1 Oc2
2
2
?ou can see LhaL Lhe formula ls much more eleganL and clear when compared wlLh Lhe prevlous verslon.
unforLunaLely, due Lo a bug ln Lhe beLa release of Lhe producL, Lhls formula wlll crash Lhe englne. 1he
problem seems Lo be relaLed wlLh uSL8LLA1lCnSPl and Lhls sllghLly modlfled verslon of Lhe same formula
works flne:
<3 )
I-!5="U-#'" )3;F+B9Ob<?8-1:MB9c2 ii I-!5="U-#'" )3;F+B9Rb<?8-1:MB9c2T
$-#$'#-%" )
$-#$'#-%" )
$5'=%45H! )$0:+/.B9:2T
$-#$'#-%"%-]#" )
!'((-4<h" )-1:MB9:T $0:+/.B9:b<?8$0:+/.B9c2T
268H0,8D@C1268H0,E I J2=#>( *F-K70,LD@C1268H0,E:
2
2T
$-#$'#-%"%-]#" )
!'((-4<h" )-1:MB9:T $0:+/.B9:b<?8$0:+/.B9c2T
'!"4"#-%<5=!I<\ )-1:MB9:b<?8-1:MB9cT 3;F+B9Ob<?8-1:MB9c2
2T
3;F+B9RbP0B:+;/1 Rc ZY U-#'"! )3;F+B9ObP0B:+;/1 Oc2
2
2
Slmply avoldlng Lhe lnnermosL uSL8LLA1lCnSPl makes Lhe formula work even wlLh C13 of uenall.
PERFORMANCE ANALYSIS
1he formula ln Lhe Survey ls preLLy complex. 1hus, we performed some LesLs ln order Lo check how far lL
can be pushed wlLh volumes of daLa. 1he maln parameLers are:
number of cusLomers (dlmenslon)
number of answers (facL Lable)
number of quesLlons (dlmenslon)
uaLa was generaLed randomly and we LesLed baslcally Lwo dlfferenL scenarlos:
Iew quest|ons, w|th many customers and, obv|ous|y, many answers

The Many-to-Many Revolution 121

ln Lhls scenarlo we kepL Lhe number of quesLlons very low (3 quesLlons only, wlLh 20 answers ln
LoLal) and we lncreased Lhe number of cusLomers up Lo 1 mllllon. 1he number of answers ls
always 3 Llmes Lhe number of cusLomers, so LhaL - on average - each cusLomer provlded 3
answers.
We used, as a LesL, Lhe same reporL shown ln Lhe prevlous flgures.
1he performances are very good up Lo 100.000 cusLomers (and 300.000 answers), because Lhe
reporL ls rendered ln less Lhan 2 seconds. Powever, Lhey become unaccepLable aL 1 mllllon
cusLomers and 3 mllllon answers, because Lhe reporL ls flnlshed ln 20 seconds, whlch ls below
our usablllLy llmlL even lf sLlll reasonable for such amounL of cusLomers.
Many quest|ons, w|th average customers and many answers
ln Lhls scenarlo, we lncreased Lhe number of quesLlons Lo 100, Lhen 1,000 and flnally 10,000.
1he number of cusLomers has been flxed Lo 100,000 whlle Lhe number of answers has been
lncreased Lo 20 Llmes Lhe number of cusLomers. 1he goal of Lhls LesL was Lo deLermlne Lhe
complexlLy of Lhe formula ln relaLlon Lo Lhe number of quesLlons.
8ecause Lhe lncreaslng number of quesLlons would make Lhe reporL unusable, we used a
dlfferenL reporL LhaL fllLers boLh a quesLlon ln lllLer1 and a quesLlon ln lllLer2, ln order Lo avold
a huge and lncreaslng number of cells ln Lhe reporL.
uslng owerlvoL 1.0, 1000 quesLlons ls Lhe llmlL and 100 ls Lhe good number". As soon as Lhe
number of quesLlons reaches 1,000, Lhe performance of Lhe lvoL1able are preLLy bad and aL
10,000 lL ls no longer usable.
1he same LesL, made on verslon 2 of owerlvoL, shows LhaL 10,000 quesLlons ls sLlll a
reasonable number. 1he reporL ls rendered ln a few seconds and provldes a good experlence.
1hus, Lhe concluslon ls LhaL Lhe daLa model and Lhe formula are very sLrongly Lled Lo Lhe number of
quesLlons: lncreaslng Lhe number over 100 (10,000 ln uenall) leads Lo poor performances. Cn Lhe oLher
hand, Lhe number of cusLomers and of answers can be preLLy blg, leadlng Lo a good experlence even wlLh 1
mllllon of cusLomers.
www. sql bi . com


122 The Many-to-Many Revolution
Multiple Groups
users wanL Lo group lLems ln many and unpredlcLable ways. lor example, we mlghL wanL Lo group all Lhe
cusLomers who llve ln a speclflc clLy and have some characLerlsLlcs ln a group, glve LhaL group a name and
Lhen analyze Lhe behavlor of Lhls group of cusLomers. Lven lf we can leverage a lvoL1able Lo perform all of
Lhls, a very useful feaLure ls LhaL of savlng Lhe group under a name, so LhaL we can reLrleve Lhe selecLlon
very qulckly.
A slmple daLa model LhaL fulfllls Lhls requlremenL ls shown ln llgure 124.
!"#$ &' !"#$ ()'*+ ,-./#/&/'#
Dim_Customers
PK ID_Customer
COD_Customer
Customer
Dim_Date
PK ID_Date
Date
Dim_Groups
PK ID_Group
GroupName
Fact_Sales
PK ID_Sale
FK1 ID_Customer
FK2 ID_Date
Amount
Bridge_CustomerGroup
PK ID_CustomerGroup
FK1 ID_Customer
FK2 ID_Group

Figure 124 Mul tipl e groups diagram
8y means of uslng a many-Lo-many relaLlonshlp, we can group cusLomers under groups. 1hls paLLern ls
ldenLlcal Lo a classlcal many-Lo-many model. 1he lnLeresLlng polnL ls ln Lhe usage we are dolng of Lhe daLa
model, noL ln Lhe uAx formulas we are golng Lo wrlLe. Moreover, focuslng on Lhe usage, we wanL Lo spend
some Llme dlscusslng how we can lmplemenL Lhls paLLern ln boLh Lhe server verslon of 8lSM (l.e. 1abular)
or ln Lhe cllenL one (l.e. owerlvoL).
ln facL, Lhe mulLlple groups paLLern ls very useful ln a self-servlce 8l envlronmenL, where each user can
deflne a cusLom grouplng ln a very flexlble way. unforLunaLely, slnce changlng Lhe group deflnlLlon requlres
an updaLe of Lhe daLa ln Lhe model, Lhls flexlblllLy ls somehow losL ln a mulLl user envlronmenL where daLa
resldes on a server.
1he formula for Lhe AmounLM2M ls sLralghLforward:
-./01+(R( D

$-#$'#-%" )
!'( )367+8!6FB:b-./01+c2T
3<#%"4 )
?;.8$0:+/.B9:T
$-#$'#-%" )$5'=%45H! )]9;CJB8$0:+/.B9[9/0A2 Y W2
2
2
WlLh Lhls baslc formula, we geL Lhe deslred resulL of cusLom grouplng of cusLomers, as you can see ln llgure
123.

The Many-to-Many Revolution 123


Figure 125 Excel custom grouping with slicers
lL ls worLh noLlng LhaL Lxcel 2010 sllcers really shlne wlLh Lhls daLa model slnce Lhey make Lhe fllLerlng of
groups very convenlenL.
now, Lhe lnLeresLlng dlscusslon abouL Lhls daLa model ls abouL how a user can updaLe Lhe brldge Lable
conLalnlng Lhe cusLom grouplngs. ln a server drlven envlronmenL, Lhe Lable has Lo reslde ln an Analysls
Servlces daLabase. ln such a scenarlo, l1 needs Lo bulld some mechanlsm Lo leL Lhe user updaLe Lhe Lable
and reprocess Lhe brldge Lable on Lhe server. 1hls can be done wlLh some codlng and Lhe usage of Lhe AMC
llbrarles.
lf Lhe model ls bullL lnslde owerlvoL, Lhen a much easler lmplemenLaLlon can be done by uslng llnked
Lables. 8y means of creaLlng an Lxcel Lable LhaL ls Lhen llnked ln owerlvoL, we can very easlly updaLe Lhe
groups wlLhouL Lhe need Lo make server Lrlps. ln such a scenarlo, lL mlghL be useful Lo denormallze Lhe daLa
model creaLlng a brldge Lable LhaL does noL conLaln Lhe cusLomer and group keys. 1he brldge Lable can be
creaLed ln a compleLely denormallzed way llke ln Lhe model shown ln llgure 126.
Dim_Customers
PK ID_Customer
COD_Customer
Customer
Fact_Sales
PK ID_Sale
FK1 ID_Customer
FK2 ID_Date
Amount
Dim_Date
PK ID_Date
Date
Groups
Customer
GroupName
GroupValue

Figure 126 Denormalized structure for multiple groups on PowerPivot
8ecause verLlpaq compresses daLa ln a very good way, we can easlly puL Lhe name of Lhe cusLomer, group
and value dlrecLly lnslde Lhe brldge Lable, leLLlng Lhe user load names ln Lhe Lxcel Lable lnsLead of complex
ldenLlflers. Clearly, Lhe formula needs Lo be updaLed Lo reflecL Lhe changes ln Lhe daLa model, buL lL ls very
easy Lo wrlLe.
We do noL provlde performance analysls for Lhls daLa model for a couple of reasons:
1he group dlmenslon ls normally very small, so performance ls noL a blg lssue when many-Lo-
many relaLlonshlps are used ln Lhls Lype of scenarlo.
1he daLa model ls ldenLlcal Lo a classlcal many-Lo-many one. 1hus, Lhe same performance
conslderaLlons apply here.
www. sql bi . com


124 The Many-to-Many Revolution
Transition Matrix
1ranslLlon MaLrlx ls a very common scenarlo where we wanL Lo analyze Lhe changes ln a parLlcular aLLrlbuLe
of a Lable. A common example ls for cusLomer segmenLaLlon: how many cusLomers classlfled wlLh raLlng A
ln 2010 have been classlfled Lype 8 ln 2011"?
1here are baslcally Lwo dlfferenL daLa model LhaL could be used Lo model Lhls scenarlo:
Slowly changlng dlmenslon of Lype 2, where we save a new verslon of a cusLomer every Llme
Lhe raLlng (or any oLher aLLrlbuLe) changes. 1he facL Lable polnLs Lo Lhe currenL verslon of Lhe
cusLomer aL Lhe Llme Lhe facL has been recorded.
PlsLorlcal aLLrlbuLe Lracklng. ln Lhls scenarlo, Lhe raLlng of Lhe cusLomer ls saved ln Lhe facL
Lable and Lhe cusLomer ls LreaLed as an SCu of Lype 1, wlLhouL hlsLorlcal Lracklng of Lhe
aLLrlbuLes.
ln llgure 127 you can see Lhese Lwo daLa models.
S|ow|y Chang|ng D|mens|on 1ype 2 n|stor|ca| Attr|bute 1rack|ng w|th kat|ng
D|mens|on
Dim_Customer
PK ID_Customer
Customer
ScdStartDate
ScdEndDate
Rating
Dim_Date
PK ID_Date
Date
Year
Month
Day
Fact_Sales
PK ID_Sale
FK1 ID_Date
FK2 ID_Customer
Amount

Dim_Customer
PK ID_Customer
Customer
Dim_Date
PK ID_Date
Date
Year
Month
Day
Dim_Rating
PK ID_Rating
Rating
Fact_Sales
PK ID_Sale
FK1 ID_Date
FK2 ID_Customer
Amount
FK3 ID_Rating

Figure 127 Transition matrix diagrams
lL ls worLh noLlng LhaL Lhe second model ls noL a compleLely correcL one because, lf no sales happen when a
cusLomer changes Lhe raLlng, Lhen Lhe raLlng change lLself wlll noL be sLored lnslde Lhe daLa model.
neverLheless, boLh daLa models are wldely used and we wanL Lo dlscuss boLh even lf, from a daLa-modellng
polnL of vlew, we sLrongly suggesL Lo avold Lhe PlsLorlcal ALLrlbuLe 1racklng ln a 8lSM 1abular model. ln
MulLldlmenslonal, Lhe usage of Lhe PA1 daLa model ls someLlmes necessary due Lo performance reasons.
lrom Lhe analyLlcal polnL of vlew, Lhls scenarlo clearly requlres Lwo calendar Lables: one wlll leL us selecL
Lhe sLarLlng polnL, Lhe oLher wlll be used for Lhe end polnL. 1he daLa model wlll perform Lhe compuLaLlon

The Many-to-Many Revolution 125

by selecLlng Lhe cusLomer LhaL had a speclflc raLlng aL Lhe sLarLlng polnL, and by sllclng Lhem wlLh Lhe raLlng
Lhey had aL Lhe endlng polnL.
We wlll see Lwo of Lhe posslble soluLlons Lo Lhls scenarlo:
Snapshot tab|e: Lo lmplemenL Lhls soluLlon we wlll need Lo creaLe a snapshoL of Lhe raLlng and
use LhaL Lable Lo perform Lhe compuLaLlon.
Ca|cu|ated co|umns: Lhls soluLlon does noL requlre Lhe creaLlon of a snapshoL Lable and
leverages on Lhe calculaLed columns.
Lach of Lhese daLa models can be lmplemenLed over Lhe SCu or Lhe PA1 scenarlos, leadlng Lo four dlfferenL
formulas LhaL we need Lo analyze.
We sLarL wlLh Lhls seL of daLa:
Customer kat|ng StartDate LndDate
Mark AAA 20030131 20030331
Mark AA8 20030331
au| AAA 20030131 20030228
au| AA8 20030228
Irank AA8 20030131 20030630
Irank AAC 20030630
Tabl e 18 Customer data for the Transition Matrix Model
We have Lhree cusLomers who changed Lhelr raLlng ln dlfferenL Llme perlods and, aL Lhe end, we wanL Lo be
able Lo plvoL over Lhe daLa model Lo produce resulLs llke Lhe one shown ln llgure 128.

Figure 128 Transition matrix Example
WhaL does Lhls reporL show? We have flxed a daLe on Lhe uaLeSnapshoL sllcers (30/04/2003 ln Lhe
example) and we wanL Lo analyze Lhe cusLomers who had a speclflc raLlng aL LhaL daLe, showlng how Lhelr
raLlng changed over Llme. lor example, Mark had a raLlng of AAA aL Aprll 2003 and Lhe reporL shows LhaL lL
had Lhe same raLlng unLll Aprll and Lhen swlLched Lo AA8 on May.
www. sql bi . com


126 The Many-to-Many Revolution
TRANSITION MATRIX WITH SNAPSHOT TABLE
A snapshoL Lable records Lhe values of Lhe aLLrlbuLes ln dlfferenL polnLs ln Llme. lor example, ln our
scenarlo we can creaLe a monLhly snapshoL LhaL would look llke Lhls:
DateSnapshot CustomerSnapshot kat|ngSnapshot
200S0131 lrank AA8
200S0131 Mark AAA
200S0131 aul AAA
200S0228 lrank AA8
200S0228 Mark AAA
200S0228 aul AA8
200S0331 lrank AA8
200S0331 Mark AAA
200S0331 aul AA8
200S0430 lrank AA8
200S0430 Mark AAA
200S0430 aul AA8
200S0S31 lrank AA8
200S0S31 Mark AA8
200S0S31 aul AA8
200S0630 lrank AAC
200S0630 Mark AA8
200S0630 aul AA8
Tabl e 19 Snapshot tabl e
Lach cusLomer ls repeaLed for each monLh, recordlng Lhe value of Lhe raLlng aL Lhe end of LhaL monLh. lL ls
clear LhaL snapshoL Lables have Lhe annoylng characLerlsLlc of flxlng Lhe Llme wlndow. ln Lhls case, havlng
creaLed a monLhly snapshoL, we wlll noL be able Lo perform analyses LhaL have a greaLer granularlLy Lhan
Lhe monLh. neverLheless, snapshoL Lables can be easlly creaLed Lhrough some L1L code sLarLlng from Lhe
orlglnal daLa.

The Many-to-Many Revolution 127

Snapshot Table in the Slowly Changing Dimension
Scenario
1he analyLlcal daLa model of Lhe snapshoL Lable ln Lhe slowly changlng dlmenslon paLLern looks llke Lhe one
ln llgure 129.
!"#$ &' !"#$ ()*+,)+*-
Dim_Customer
PK ID_Customer
Customer
scdStartDate
scdEndDate
Rating
Fact_Sales
PK ID_Sale
FK2 ID_Date
FK1 ID_Customer
Amount
RatingSnapshot
PK,FK1 ID_Date
PK,FK2 Customer
PK Rating
Dim_Date
PK ID_Date
Date
Year
Month
Day
Dim_DateSnapshot
PK ID_Date
Date
Year
Month
Day

Figure 129 Transition matrix SCD Diagram
1he many-Lo-many sLrucLure ls beLween Lhe daLe and Lhe cusLomer dlmenslons, Lhrough Lhe snapshoL. lL ls
very lmporLanL Lo noLe LhaL Lhe relaLlonshlp beLween Lhe snapshoL and Lhe cusLomer dlmenslon ls noL a
real relaLlonshlp. ln facL, Lhe cusLomer dlmenslon has a surrogaLe key LhaL mlghL change durlng Lhe monLh
and, ln consequence of LhaL, we need Lo Lrack Lhe relaLlonshlp uslng Lhe cusLomer code or Lhe cusLomer
name. ln our example, we used Lhe cusLomer name ln order Lo reduce Lhe number of columns ln Lhe Lables.
ln a real world scenarlo, we would use Lhe cusLomer naLural key. 1hls means LhaL a slngle row ln Lhe
snapshoL Lable mlghL be relaLed Lo more Lhan one row ln Lhe cusLomer Lable for Lhe same cusLomer. 1hls
slLuaLlon ls deflnlLely someLhlng we need Lo Lake lnLo accounL when wrlLlng Lhe uAx formulas, because we
wlll noL be able Lo deslgn Lhe relaLlonshlp lnslde Lhe daLa model. neverLheless, we already know how Lo use
uAx Lo mlmlc relaLlonshlps. 1hus, we wlll leverage advanced uAx fllLerlng lnsLead of followlng Lhe classlcal
usage of relaLlonshlps.
Moreover, lL ls worLh noLlng LhaL Lhe snapshoL ls noL relaLed Lo Lhe daLe dlmenslon buL Lo a new daLe
dlmenslon called ulm_uaLeSnapshoL. 1hls ls necessary because we are golng Lo use Lhe Lwo daLes for
dlfferenL purposes: one ls used Lo fllLer Lhe snapshoL Lable, Lhe oLher one ls used Lo fllLer Lhe sales Lable.
lL ls now Llme Lo sLarL Lhlnklng Lo Lhe algorlLhm. LeL us sLarL recalllng Lhe buslness scenarlo: we wanL Lo
counL Lhe number of cusLomers who had a speclflc raLlng ln a polnL ln Llme and analyze Lhe changes ln Lhelr
raLlng over Llme. 1hus, we know LhaL Lhe daLe of Lhe snapshoL wlll be flxed and we wanL Lo be able Lo fllLer
all Lhe cusLomers who had a raLlng aL LhaL daLe.
We can sLarL wlLh Lhe classlcal paLLern of many-Lo-many Lo selecL Lhe cusLomers who have a raLlng aL a
speclflc daLe:
www. sql bi . com


128 The Many-to-Many Revolution
=0.5*$0:+/.B9: D

$-#$'#-%" )
$5'=%45H! )?;.8$0:+/.B9:2T
3<#%"4 )
?;.8$0:+/.B9:T
$-#$'#-%" )
$5'=%45H! )46+;1J!16A:K/+2T
&G7-6/(6GP8Q47D!587490,(6GP8Q47E I >2&=@>& *C-91!587490,8D!587490,E:
2 Y W
2
2
1hls formula compuLes Lhe number of cusLomers afLer havlng fllLered Lhe ones LhaL have a speclflc raLlng as
deflned by Lhe snapshoL Lable. lL ls worLh Lo noLe Lhe addlLlonal condlLlon lnslde Lhe lnner CALCuLA1L,
whlch ls used Lo force Lhe formula Lo Lake lnLo accounL Lhe relaLlonshlp" beLween Lhe snapshoL and Lhe
cusLomer dlmenslon Lhrough Lhe cusLomer name.
neverLheless, Lhls formula ls noL sLlll maklng whaL lL ls supposed Lo do. ln facL, Lhe fllLer on Lhe cusLomer
name always reLurns all Lhe lnsLances of Lhe cusLomer, regardless of Lhe daLe. ln facL, lf we fllLer Lhe daLe
dlmenslon, LhaL fllLer wlll have no effecL on Lhe cusLomer dlmenslon, because Lhere are no relaLlonshlps
LhaL Lle Lhe cusLomer and Lhe daLe LogeLher. Agaln, we need Lo leverage uAx Lo lmpose such a fllLer
condlLlon, seeklng only Lhe lnsLances of Lhe cusLomer LhaL are acLlve ln Lhe daLe perlod selecLed. 1hls
conslderaLlon wlll lead us Lo Lhe flnal formula:
=0.5*$0:+/.B9: D

$-#$'#-%" )
$5'=%45H! )C@(%@$!% *C-91!587490,8D!587490,E:2T
3<#%"4 )
?;.8$0:+/.B9:T
$-#$'#-%" )
$5'=%45H! )46+;1J!16A:K/+2T
46+;1J!16A:K/+b$0:+/.B9!16A:K/+c D "-4#<"4 )?;.8$0:+/.B9:b$0:+/.B9c2
2 Y W ii
C-91!587490,8D83.(7G,7CG70E NI ?2R *C-91CG70D@C1CG70E: SS
*
C-91!587490,8D83.>6.CG70E ; ?@$ *C-91CG70D@C1CG70E: TT
@(+=2$U *C-91!587490,8D83.>6.CG70E:
:
2
2
8y leveraglng Lhe scdSLarLuaLe and scdLnduaLe, we furLher resLrlcL Lhe fllLer on Lhe cusLomers ln order Lo
conslder only Lhe lnsLances of Lhe cusLomers LhaL are acLlve ln Lhe daLe selecLlon. Moreover, knowlng LhaL
durlng a Llme perlod a cusLomer mlghL be reLurned more Lhan once (for example, lL mlghL have changed
raLlng Lhree Llmes ln a monLh), we have changed Lhe CCun18CWS counLlng Lhe dlsLlncL cusLomer names
lnsLead of Lhe number of rows. ln Lhls way, we always counL dlfferenL lnsLances of Lhe same cusLomer only
once.
WlLh Lhls knowledge, we can now analyze Lhe Lable ln llgure 130 and glve a correcL meanlng Lo Lhe LoLal for
2003, where Mark ls counLed wlLh raLlng AAA and AA8 as one cusLomer buL ls counLed only once on Lhe
grand LoLal slnce Lhe Lwo lnsLances do noL need Lo be summed up.

The Many-to-Many Revolution 129


Figure 130 Transition matrix SCD Example
lL ls evldenL LhaL we can use Lhe same paLLern Lo compuLe oLher values, as Lhe amounL sold or any oLher
lnLeresLlng lnformaLlon.
www. sql bi . com


130 The Many-to-Many Revolution
Snapshot Table in the Historical Attribute Tracking
Scenario
1he brldge Lable ln Lhe scenarlo wlLh PlsLorlcal ALLrlbuLe 1racklng ls sllghLly dlfferenL and can be seen ln
llgure 131.
!"#$ &' !"#$ ()*+,)+*-
Dim_Customer
PK ID_Customer
Customer
Dim_Date
PK ID_Date
Date
Year
Month
Day
Dim_Rating
PK ID_Rating
Rating
Fact_Sales
PK ID_Sale
FK1 ID_Date
FK2 ID_Customer
FK3 ID_Rating
Amount
RatingSnapshot
PK,FK2 ID_Rating
PK,FK3 ID_Date
PK,FK1 ID_Customer
Dim_DateSnapshot
PK ID_Date
Date
Year
Month
Day
Dim_RatingSnapshot
PK ID_Rating
Rating

Figure 131 Transition matrix HAT diagram
1he maln dlfferences beLween Lhe prevlous daLa model and Lhls one are:
1he presence of a raLlng dlmenslon. 1he 8aLlng dlmenslon can be avolded, lncludlng Lhe raLlng
dlrecLly lnslde Lhe snapshoL. Powever, ln Lhls case we declded Lo keep lL as a separaLe
dlmenslon Lo malnLaln coherence wlLh Lhe raLlng dlmenslon LhaL models Lhe hlsLorlcal raLlng.
lrom an lmplemenLaLlon polnL of vlew, Lhe Lwo dlmenslons can be creaLed as Lwo dlfferenL
vlews of Lhe same relaLlonal Lable.
1he relaLlonshlp wlLh Lhe cusLomer ls a classlcal relaLlonshlp, because each cusLomer ls presenL
only once ln Lhe dlmenslon: no SCu has been creaLed for Lhe cusLomers ln Lhls daLa model.
ln Lhls scenarlo, Lhe flrsL complex parL ls Lhe creaLlon of Lhe snapshoL Lable because, havlng Lhe aLLrlbuLe
Lracklng lnslde Lhe facL Lable, some varlaLlons mlghL be mlsslng. neverLheless, Lhls ls an lssue relaLed Lo Lhe
L1L code and ls noL someLhlng we need Lo dlscuss here.
When lL comes Lo wrlLlng Lhe uAx formula, we can now leverage Lhe relaLlonshlps Lo fllLer Lhe snapshoL
Lable wlLh Lhe cusLomers. 1hus, Lhe complex parL of Lhe prevlous scenarlo ls mlsslng now. neverLheless,
slnce we wanL Lo counL Lhe number of cusLomers, we need Lo perform Lhe fllLerlng of Lhe cusLomers ln Lwo
sLeps:
llrsL, we fllLer Lhe cusLomers who had a speclflc raLlng aL Lhe daLe lndlcaLed by Lhe
ulmuaLeSnapshoL daLe. 1hls wlll be done by uslng Lhe classlcal many-Lo-many paLLern.

The Many-to-Many Revolution 131

1hen, we sLlll need Lo fllLer Lhe cusLomers who have a speclflc raLlng aL Lhe daLe lndlcaLed by
Lhe ulm_uaLe. 8emember LhaL, Lhls Llme, Lhe lnformaLlon abouL Lhe raLlng ls no longer
avallable ln Lhe ulm_CusLomer. 1hls Llme, Lhe lnformaLlon ls sLored lnslde Lhe lacL_Sales Lable.
1hus, we wlll use a slmllar paLLer Lo LhaL of Lhe many-Lo-many Lo fllLer only Lhe cusLomers LhaL,
ln Lhe speclfled daLe range, have aL leasL one sale wlLh Lhe speclfled raLlng.
WlLh Lhese conslderaLlons ln mlnd, Lhe formula ls (almosL) sLralghLforward:
?;.8$0:+/.B9: D

$-#$'#-%" )
$5'=%45H! )
3<#%"4 )
?;.8$0:+/.B9:T
$-#$'#-%" )$5'=%45H! )367+8!6FB:22 Y W
2
2T
3<#%"4 )
?;.8$0:+/.B9:T
$-#$'#-%" )$5'=%45H! )46+;1J!16A:K/+22 Y W
2
2
?ou can easlly see, ln Lhe formula, Lhe presence of Lhe Lwo-sLeps fllLerlng, one conslderlng Lhe
8aLlngSnapshoL Lable as Lhe brldge Lable ln a classlcal many-Lo-many relaLlonshlp, Lhe oLher (Lhe
lnnermosL) uslng Lhe lacL_Sales as a brldge Lable ln a second many-Lo-many relaLlonshlp beLween Lhe
cusLomers and Lhe raLlngs.
ln Lhls scenarlo, Lhe formula Lo counL Lhe cusLomer ls sllghLly more complex Lhan any formula LhaL slmply
needs Lo aggregaLe values from Lhe facL Lable. ln facL, ln Lhls scenarlo Lhe formula ls more slmllar Lo a
cascadlng many-Lo-many relaLlonshlp. lf we were Lo aggregaLe values from Lhe facL Lable, Lhen Lhe
lnnermosL CALCuLA1L could be avolded because a fllLer on ulm_8aLlng dlrecLly applles Lo Lhe facL Lable,
whereas lL needs an addlLlonal sLep Lo be applled Lo Lhe cusLomers.
1he uenall formula, for Lhe same scenarlo, ls ldenLlcal Lo Lhe Cascadlng many-Lo-many paLLern and we
leave lL as an exerclse Lo Lhe reader.
lrom a performance polnL of vlew, Lhls formula ls deflnlLely slower Lhan Lhe prevlous one, requlrlng an
addlLlonal CALCuLA1L sLep over Lhe lacL_Sales Lable. 8ecause we expecL Lhe lacL_Sales Lable Lo be Lhe
blggesL among all of our Lables, avoldlng Louchlng lL would be welcome.
lf no sales have been recorded when a cusLomer had a speclflc raLlng, Lhen Lhe lnformaLlon abouL Lhe
raLlng change wlll noL be reporLed by Lhe query ln a correcL way. Lven lf we can wrlLe formula LhaL slmply
uses Lhe snapshoL Lable Lo gaLher all raLlng varlaLlons, we already know LhaL our sysLem wlll reporL wrong
daLa ln case more Lhan a slngle varlaLlon happens ln a slngle monLh. 1here ls no soluLlon Lo Lhls lssue: as we
have already dlscussed, Lhe PA1 daLa model ls noL Lhe besL one Lo use whenever Lhere ls Lhe need Lo Lrack
aLLrlbuLe varlaLlons.
1hus, Lhese are Lhe concluslons:
1he SCu daLa model leads Lo very fasL formulas and always reLurns correcL lnformaLlon abouL
raLlng varlaLlons.
1he PA1 daLa model has a more complex (and slower) formula Lo compuLe Lhe counL of
cusLomers, due Lo Lhe presence of a cascadlng many-Lo-many relaLlonshlp.
www. sql bi . com


132 The Many-to-Many Revolution
1he PA1 daLa model can reLurn lncompleLe daLa lf daLa ls mlsslng from Lhe facL Lable
(someLhlng LhaL wlll deflnlLely happen when Lhe cusLomer sLops buylng from us).
1hese are Lhe reasons for whlch we sLrongly suggesL Lo avold uslng Lhe PA1 daLa model and always use a
more canonlcal SCu of Lype 2 handllng ln order Lo record aLLrlbuLe varlaLlons. 1he daLa model ls more
accuraLe and Lhe formulas are easler Lo wrlLe.

The Many-to-Many Revolution 133

Transition Matrix with Calculated Columns
1here ls an lnLeresLlng alLernaLlve Lo Lhe creaLlon of a snapshoL Lable LhaL lmplles Lhe usage of calculaLed
columns. 1hls soluLlon ls lnLeresLlng ln some scenarlos:
When Lhe Llme granularlLy of Lhe aLLrlbuLe changlng can be flxed aL a hlgh level (l.e. aL Lhe year
level) and Lhe daLa model ls sLored on a server. ln Lhls case, we lose some flexlblllLy buL we geL
a much slmpler model boLh Lo query and Lo develop.
When Lhe daLa model ls Lo be querled by uslng owerlvoL for Lxcel. ln Lhls case, we can
leverage Lhe lnLeracLlve naLure of owerlvoL and dynamlcally compuLe calculaLed columns
Lhanks Lo user deflned parameLers ln llnked Lables.
1he baslc ldea of uslng calculaLed columns ls Lo creaLe, aL Lhe cusLomer level, a calculaLed column LhaL
conLalns Lhe value of Lhe raLlng aL a speclfled polnL ln Llme. lor example, we mlghL wanL Lo creaLe one
calculaLed column ln Lhe cusLomer Lable LhaL conLalns 8aLlng2003, one for 8aLlng2006 and so on. lL ls clear
LhaL, uslng Lhls soluLlon, we wlll noL be able Lo look aL Lhe cusLomers who had a speclflc raLlng aL March
2003, because Lhe only column avallable would be LhaL of Lhe year 2003. neverLheless, for mosL of Lhe
lnLeresLlng analysls, a yearly snapshoL ls a good compromlse because we can analyze cusLomers who had a
raLlng aL Lhe beglnnlng of 2003 and analyze how Lhelr raLlng changed durlng Lhe year. 1he flxed daLe ls only
LhaL of Lhe selecLlon" raLlng.
Cbvlously, such a model wlll need Lo be updaLed each year and we wlll need Lo add a new column for each
year. 8ecause ln our small example we have daLa for a slngle year, we are golng Lo creaLe a calculaLed
column for each monLh. 1he code ls noL very dlfflculL Lo wrlLe:
46+;1J8RWWX8WO gD

$-#$'#-%" )
U-#'"! )?;.8$0:+/.B9:b46+;1Jc2T
3<#%"4 )
-## )?;.8$0:+/.B9:2T
?;.8$0:+/.B9:b$0:+/.B9c D "-4#<"4 )?;.8$0:+/.B9:b$0:+/.B9c2 ii
?;.8$0:+/.B9:b!7C!+69+?6+Bc D $-#$'#-%" )
(-j )?;.8$0:+/.B9:b!7C!+69+?6+Bc2T
?;.8$0:+/.B9:b!7C!+69+?6+Bc ZD RWWXWO`OT
-## )?;.8$0:+/.B9:2T
?;.8$0:+/.B9:b$0:+/.B9c D "-4#<"4 )?;.8$0:+/.B9:b$0:+/.B9c2
2
2
2
8y means of replaclng Lhe consLanL 20030131 wlLh 20030228, we can easlly add new columns for each
monLh of Lhe year. ln llgure 132 you can see Lhe ulm_CusLomers Lable wlLh Lhree calculaLed columns:
www. sql bi . com


134 The Many-to-Many Revolution

Figure 132 Transition matrix with cal culated columns
uslng Lhese columns ln a lvoL1able, lL ls sLralghLforward Lo perform Lhe selecLlon of Lhe cusLomers who
had a speclflc raLlng ln a polnL ln Llme (for example, !anuary 2003). neverLheless, Lo counL Lhe number of
such cusLomers we sLlll need Lo apply a fllLer over Lhe ulm_CusLomers Lo counL only Lhe cusLomers who
were acLlve ln Lhe selecLed perlod ln Llme. 1he uAx code LhaL performs Lhls calculaLlon ls somewhaL slmllar
Lo prevlous formulas:
=0.5*$0:+/.B9: D

$-#$'#-%" )
$5'=%45H! )?<!%<=$% )?;.8$0:+/.B9:b$0:+/.B9c22T
3<#%"4 )
?;.8$0:+/.B9:T
?;.8$0:+/.B9:b:7C!+69+?6+Bc ZD (-j )?;.8?6+Bb<?8?6+Bc2 ii
)
?;.8$0:+/.B9:b:7C"1C?6+Bc Y (<= )?;.8?6+Bb<?8?6+Bc2 kk
<!]#-=l )?;.8$0:+/.B9:b:7C"1C?6+Bc2
2
2
2
1he only Lhlng Lo noLe ls Lhe need of a ulS1lnC1 lnslde Lhe CCun18CWS, ln order Lo counL Lhe cusLomers
once even lf Lhey appear several Llmes ln Lhe selecLed Llme perlod due Lo many updaLes ln Lhe aLLrlbuLe.
lf we wanL Lo aggregaLe values from Lhe facL Lable, Lhen Lhe formulas wlll be much easler Lo wrlLe because
Lhe fllLerlng of Lhe cusLomers acLlve ln Lhe selecLed Llme perlod wlll be auLomaLlcally performed by Lhe
relaLlonshlp beLween Lhe facL Lable and Lhe calendar Lable.
8efore dlvlng lnLo Lhe deLalls of calculaLed columns ln Lhe PA1 model, lL ls worLh Lo spend some words on
Lhe pros and cons of Lhe calculaLed column approach:
S|mp|er data mode|. AparL from any oLher conslderaLlon, Lhls ls Lhe greaLesL advanLage of
uslng calculaLed columns lnsLead of Lhe prevlous complex daLa models. 8emember LhaL havlng
a slmpler daLa model ofLen means galnlng a loL ln Lerms of query speed and user experlence.
1he prevlous models always had Lwo daLe dlmenslons: one for Lhe sales facL Lable and one for
Lhe snapshoL one. ln our experlence, havlng more Lhan one calendar Lable ls qulLe always a
nulsance and Lhe calculaLed column daLa model avolds Lhls.
uery speed. 1hls daLa model uses calculaLed columns, whlch are compuLed aL process Llme,
reduclng Lo a mlnlmum Lhe efforL needed Lo answer even complex querles.
L1L: Lhls daLa model does noL requlre any klnd of L1L, because Lhere ls no need Lo creaLe a
snapshoL Lable (whlch ls commonly creaLed by an L1L sLep). 1hls slmple conslderaLlon makes lL
Lhe perfecL soluLlon for self-servlce 8l scenarlos where speed of developmenL ls normally Lhe
maln declslon drlver.

The Many-to-Many Revolution 135

I|ex|b|||ty. lrom a flexlblllLy polnL of vlew, Lhe complex daLa models are obvlously Lhe besL.
neverLheless, we sLrongly suggesL checklng wheLher Lhls flexlblllLy ls really needed or noL. We
are noL saylng LhaL flexlblllLy ls noL one of Lhe ma[or goals of any 8l soluLlon buL, because Lhls
flexlblllLy comes aL a cosL, we advlse Lo double check your opLlons before Laklng a cholce.
Ma|ntenance. 1he calculaLed column approach needs some malnLenance. Lvery Llme we wlll
need a new column, we wlll have Lo spend some Llme Lo deflne lL lnslde Lhe daLa model. 1hls ls
a clear dlsadvanLage of Lhe soluLlon, and you should be aware of LhaL.
1he lasL Lwo polnLs are clear dlsadvanLages and cannoL be easlly addressed ln a server-drlven 8l soluLlon,
l.e. when Lhe daLa model ls hosLed ln a server (ShareolnL or SSAS). neverLheless, ln a scenarlo where we
are [usL uslng owerlvoL for Lxcel Lo analyze daLa, Lhere ls a slmple soluLlon LhaL qulckly solves boLh
problems.
LeL us recall Lhe formula of Lhe calculaLed column:
46+;1J8RWWX8WO D

$-#$'#-%" )
U-#'"! )?;.8$0:+/.B9:b46+;1Jc2T
3<#%"4 )
-## )?;.8$0:+/.B9:2T
?;.8$0:+/.B9:b$0:+/.B9c D "-4#<"4 )?;.8$0:+/.B9:b$0:+/.B9c2 ii
?;.8$0:+/.B9:b!7C!+69+?6+Bc D $-#$'#-%" )
(-j )?;.8$0:+/.B9:b!7C!+69+?6+Bc2T
?;.8$0:+/.B9:b!7C!+69+?6+Bc ZD L<<V<OWOT
-## )?;.8$0:+/.B9:2T
?;.8$0:+/.B9:b$0:+/.B9c D "-4#<"4 )?;.8$0:+/.B9:b$0:+/.B9c2
2
2
2
Lach calculaLed column wlll be ldenLlcal Lo Lhls one excepL for Lhe consLanL LhaL conLalns Lhe daLe of Lhe
raLlng (hlghllghLed ln Lhe prevlous formula). lf we were able Lo Lransform LhaL consLanL lnLo a parameLer,
deflnable by Lhe user, Lhen we would be able Lo marry Lhe flexlblllLy of Lhe complex daLa models wlLh Lhe
slmpllclLy of Lhe calculaLed column approach.
Lucklly, Lhls can be easlly accompllshed by uslng a parameLer Lable. We can deflne an Lxcel Lable llke Lhe
one ln llgure 133.

Figure 133 Transition matrix: parameter table with PowerPivot
1hls Lable, named arameLers", conLalns only one row and one column and should be loaded lnslde
owerlvoL as a llnked Lable. lf, ln Lhe fuLure, we wlll need more parameLers, we could always add columns
Lo Lhe Lable. lL ls mandaLory LhaL only one row exlsLs ln Lhe Lable Lo make Lhe soluLlon works.
www. sql bi . com


136 The Many-to-Many Revolution
8ecause Lhe Lable has only one row, Lhe expresslon vALuLS (arameLers[uaLeCfPlsLorlcal8aLlng]) wlll
always conLaln a slngle value. 1hus, uAx wlll auLomaLlcally converL lL lnLo a scalar value whenever lL ls
needed. We can deflne Lhe calculaLed column as:
!16A:K/+846+;1J D

$-#$'#-%" )
U-#'"! )?;.8$0:+/.B9:b46+;1Jc2T
3<#%"4 )
-## )?;.8$0:+/.B9:2T
?;.8$0:+/.B9:b$0:+/.B9c D "-4#<"4 )?;.8$0:+/.B9:b$0:+/.B9c2 ii
?;.8$0:+/.B9:b!7C!+69+?6+Bc D $-#$'#-%" )
(-j )?;.8$0:+/.B9:b!7C!+69+?6+Bc2T
?;.8$0:+/.B9:b!7C!+69+?6+Bc ZD J2=#>( *XG,G9070,8DCG70"YZ-874,-3GK&G7-6/E:T
-## )?;.8$0:+/.B9:2T
?;.8$0:+/.B9:b$0:+/.B9c D "-4#<"4 )?;.8$0:+/.B9:b$0:+/.B9c2
2
2
2
1hls column wlll be recompuLed each Llme Lhe arameLer Lable ls refreshed and wlll conLaln Lhe value of
Lhe raLlng aL Lhe Llme conLalned ln Lhe Lxcel Lable. 1hus, Lo perform analyses aL any polnL ln Llme, we wlll
need Lo refresh Lhe llnked Lable, geL Lhe calculaLed column recompuLed and use Lhe SnapshoL_8aLlng
column Lo sllce daLa.
Clearly, because Lhls approach needs a refresh of Lhe daLa model, Lhls can work wlLh owerlvoL for Lxcel
only and ls noL affordable ln a mulLl-user soluLlon based on a server, lncludlng owerlvoL for ShareolnL.
neverLheless, for slmple self-servlce 8l, Lhls ls by far Lhe besL approach Lo Lhe 1ranslLlon MaLrlx scenarlo.
1he lasL Loplc ls Lhe calculaLed column approach wlLh Lhe PA1 daLa model. Whlle Lhe loglc ls noL very
dlfferenL, Lhls Llme Lhe uAx formula ls much more compllcaLed, because Lhe raLlngs, Lhls Llme, are sLored
lnslde Lhe facL Lable. 1hus, Lo compuLe Lhe raLlng aL a polnL ln Llme we need Lo:
Search for Lhe lasL sale of Lhe cusLomer before Lhe deslred daLe
CompuLe Lhe lu_8aLlng of LhaL sale
Search ln Lhe ulm_8aLlng for Lhe LexLual represenLaLlon of LhaL raLlng 1he compleLe formula ls
Lhe followlng one:

The Many-to-Many Revolution 137

46+;1J8RWWX8WR D

$-#$'#-%" )
U-#'"! )?;.846+;1Jb46+;1Jc2T
3<#%"4 )
?;.846+;1JT
?;.846+;1Jb<?846+;1Jc D $-#$'#-%" )
U-#'"! )367+8!6FB:b<?846+;1Jc2T
3<#%"4 )
367+8!6FB:T
367+8!6FB:b<?8?6+Bc D $-#$'#-%" )
(-j )367+8!6FB:b<?8?6+Bc2T
367+8!6FB:b<?8$0:+/.B9c D "-4#<"4 )?;.8$0:+/.B9:b<?8$0:+/.B9c2T
-## )367+8!6FB:2T
367+8!6FB:b<?8?6+Bc ZD L<<V<LL[
2
2T
367+8!6FB:b<?8$0:+/.B9c D "-4#<"4 )?;.8$0:+/.B9:b<?8$0:+/.B9c2
2
2
2
Whenever we wrlLe a formula wlLh Lhree nesLed CALCuLA1L funcLlons, we know LhaL lL wlll be hard Lo
undersLand. 1ake your Llme and sLudy lL carefully, lL ls worLh Lhe efforL. We cannoL expecL Lhls calculaLed
column Lo be compuLed very qulckly because, for each cusLomer, lL needs Lo make a round over Lhe facL
Lable Lo geL Lhe lasL raLlng asslgned Lo Lhe cusLomer and we expecL Lhe facL Lable Lo be a blg one.
neverLheless, as we have already polnLed ouL before, Lhe PA1 model ls noL very convenlenL ln 8lSM
because Lhe formulas are complex and noL very fasL, buL lf you need Lo face such a daLa model, aL leasL you
have learned how Lo handle lL.
www. sql bi . com


138 The Many-to-Many Revolution
Basket Analysis
8askeL Analysls ls Lhe search for correlaLlons beLween evenLs sLored ln Lhe facL Lable. lor Lhls example, we
are golng Lo use Lhe AdvenLureWorks uWP daLabase, because lL besL flLs Lhe scenarlo.
1he quesLlon we wanL Lo answer ls of all Lhe cusLomers who boughL a mounLaln blke, how many have
never boughL a mounLaln Llre Lube?"
1here are Lwo dlfferenL Loplcs LhaL make Lhls an lnLeresLlng scenarlo:
We wlll need Lo use Lhe many-Lo-many paLLern uslng Lhe facL Lable as Lhe brldge one Lo solve Lhe problem
wlLh 1abular
We are golng Lo search for mlsslng values (cusLomers who have noL boughL a mounLaln Llre Lube) lnsLead of
exlsLlng ones. 1hls wlll make Lhe formula somehow harder and shows Lhe Lremendous power of 8lSM
1abular because Lhe flnal soluLlon wlll be very fasL, whlle requlrlng no changes Lo Lhe exlsLlng daLa model
LeL us sLarL Laklng a look aL a slmpllfled verslon of Lhe AdvenLureWorks daLa warehouse. ln Lhe dlagram
shown ln llgure 134, we have removed many columns from Lhe orlglnal Lables, because we are lnLeresLed
ln Lhe model and noL ln Lhe deLalls of each enLlLy.

Figure 134 AdventureWorks Data Warehouse diagram
1hls daLa model ls noL yeL enough. 8ecause we wanL Lo fllLer Lwo klnds of producLs (MounLaln 8lke and
MounLaln 1lre 1ube) and perform dlfferenL compuLaLlons wlLh Lhese selecLlons, we need Lwo lnsLances of
Lhe ulmroducL Lable ln our analyLlcal daLa model. lL ls enough Lo load Lhe ulmroducL Lwlce ln Lhe daLa
model, glvlng lL anoLher name Lo make lL evldenL lLs dlfferenL meanlng, as you can see ln llgure 133.

The Many-to-Many Revolution 139


Figure 135 Basket Anal ysis Anal ytical Model
1he new Lable does noL have any relaLlonshlp wlLh Lhe facL Lable because Lhe only avallable roducLkey has
already been used Lo relaLe Lhe facL Lable wlLh ulmroducL. 1hus, we wlll use uAx Lo mlmlc Lhe relaLlonshlp
ln all of our formulas.
AL Lhe end of Lhe chapLer, we wlll show Lhe same scenarlo solved wlLh Lhe uenall lmplemenLaLlon of
verLlpaq, where Lhere ls Lhe opLlon Lo creaLe more Lhan one relaLlonshlp uslng a slngle key. We declded Lo
show boLh soluLlons (prlor Lo uenall and wlLh uenall) for educaLlonal purposes: undersLandlng Lhe formula
wlLhouL Lhe capablllLy Lo creaLe many relaLlonshlps ls useful.
LeL us sLarL from Lhe flnal resulL. We wanL Lo be able Lo use a lvoL1able Lo query Lhe model and produce a
reporL llke Lhe one ln llgure 136.
www. sql bi . com


140 The Many-to-Many Revolution

Figure 136 Basket Anal ysis PivotTabl e
8efore dlvlng lnLo Lhe formula, leL us spend a few words on Lhe resulL:
PavlngroducL compuLes Lhe number of cusLomers who boughL a mounLaln blke and aL leasL
one Llre Lube
noLPavlngroducL compuLes Lhe number of cusLomers who boughL a mounLaln blke and no
Llre Lubes.
We used Lhe fllLer Lable Lo fllLer several models, whlch resulL ln many producLs and Lhe formula need Lo
Lake Lhls scenarlo lnLo accounL: we do noL wanL Lo force our user Lo selecL a slngle producL
Whlle lL ls noL clearly vlslble ln Lhe flgure, Lhe values shown are always 1lme1ouaLe. 1hls means LhaL we
wanL Lo see who boughL a mounLaln blke and a mounLaln Llre Lube any Llme before 2003 or any Llme
before 2004. 1hus, Lhe values ln 2004 for Lhe measures conLaln Lhe same values of 2003 plus Lhe values for
2004. 1hls does noL mean LhaL Lhe formula ls addlLlve, lL means LhaL all Lhe Llme before Lhe selecLed perlod
need Lo be Laken lnLo accounL.
now, leL us sLarL Lo auLhor Lhe formula LhaL wlll compuLe Lhe Lwo measures. We sLarL wlLh PavlngroducL,
whlch ls somehow easler Lo creaLe. 1he key polnLs are:
We need Lo fllLer Lhe cusLomer who have boughL one of Lhe producLs selecLed by roducLlllLer any Llme
before Lhe end of Lhe selecLed perlod
lor Lhese cusLomers, we need Lo check wheLher Lhey have boughL one of Lhe producLs selecLed by
ulmroducL ln Lhe same perlod
LeL us sLarL wlLh Lhe flrsL polnL. 1he seL of cusLomers who boughL one of Lhe producLs ln lllLerroducL can
be compuLed ln Lhls way:

The Many-to-Many Revolution 141

3<#%"4 )
?;.$0:+/.B9T
!'(j )
\9/C07+3;F+B9T
$-#$'#-%" )
$5'=%45H! )367+<1+B91B+!6FB:2T
2== *FG37@670,607(GK08:B
FG37@670,607(GK08D!587490,U0\E I >2&=@>& *C-9!587490,D!587490,U0\E:B
FG37@670,607(GK08DX,4.537U0\E I >2&=@>& *X,4.537F-K70,DX,4.537U0\E:B
3<#%"4 )
-## )?;.%;.B2T
?;.%;.Bb%;.BlB@c ZD (-j )?;.%;.Bb%;.BlB@c2
2
2
2 Y W
2
1here are some lnLeresLlng Lechnlques used ln Lhls formula:
Lven lf Lhe paLLern ls very slmllar Lo Lhe classlcal many-Lo-many, we are now maklng a SuMx over
roducLlllLer and check lf Lhe flnal resulL of SuMx ls greaLer Lhan zero. Lach lLeraLlon over roducLlllLer
checks for a slngle producL. ln Lhls way, Lhe fllLer reLurns all Lhe cusLomers who boughL aL leasL one of Lhe
producLs fllLered by Lhe sllcer.
1he hlghllghLed rows are used Lo mlmlc Lhe relaLlonshlp beLween roducLlllLer and Lhe facL Lable. lL ls
worLh Lo noLe LhaL we need Lo use fllLers Lo add boLh Lhe relaLlonshlp wlLh ulmCusLomer and roducLlllLer
because Lhe ALL (lacLlnLerneLSales) removes all Lhe fllLers on Lhe Lable, whlch ls requlred ln order Lo clear
Lhe fllLer auLomaLlcally lnLroduced by Lhe relaLlonshlp wlLh ulmroducL.
1he fllLer on ulm1lme ls requlred Lo make Lhe compuLaLlon conslder all Lhe perlods of Llme before Lhe end
of Lhe currenLly selecLed perlod. 1he calculaLlon conslders all Lhe lndlvlduals who have boughL a mounLaln
blke any Llme before 2003".
now, Lhls fllLer ls noL very useful as a fllLer alone, lL needs Lo be used lnslde a CALCuLA1L Lo compuLe Lhe
values we are lnLeresLed ln. 1he formula for PavlngroducL ls, aL Lhls polnL, sLralghLforward:
www. sql bi . com


142 The Many-to-Many Revolution
I6L;1J\9/C07+gD
$-#$'#-%" )
$5'=%45H! )?<!%<=$% )367+<1+B91B+!6FB:b$0:+/.B9lB@c22T
3<#%"4 )
-## )?;.%;.B2T
?;.%;.Bb%;.BlB@c ZD (-j )?;.%;.Bb%;.BlB@c2
2T
3<#%"4 )
?;.$0:+/.B9T
!'(j )
\9/C07+3;F+B9T
$-#$'#-%" )
$5'=%45H! )367+<1+B91B+!6FB:2T
-## )367+<1+B91B+!6FB:2T
367+<1+B91B+!6FB:b$0:+/.B9lB@c D "-4#<"4 )?;.$0:+/.B9b$0:+/.B9lB@c2T
367+<1+B91B+!6FB:b\9/C07+lB@c D "-4#<"4 )\9/C07+3;F+B9b\9/C07+lB@c2T
3<#%"4 )
-## )?;.%;.B2T
?;.%;.Bb%;.BlB@c ZD (-j )?;.%;.Bb%;.BlB@c2
2
2
2 Y W
2
2
1he flnal fllLer of Lhe flrsL CALCuLA1L ls Lhe fllLer we have already dlscussed, Lhe CCun18CWS slmply
counLs Lhe number of cusLomers, Lhe only parL of Lhe formula LhaL needs some aLLenLlon ls Lhe dupllcaLe
fllLer over Lhe ulm1lme, whlch appears boLh ln Lhe ouLer and ln Lhe lnner calculaLe.
1he condlLlon ls noL dupllcaLed, lndeed. lf you look carefully aL Lhe uAx formula you wlll dlscover LhaL Lhe
llL1L8 over ulmCusLomer and Lhe llL1L8 over ulm1lme ln Lhe ouLer CALCuLA1L are compuLed ln parallel
lnslde Lhe same fllLer conLexL and Lhey conLrlbuLe Lo change Lhe fllLer conLexL of Lhe CCun18CWS.
neverLheless, Lhese Lwo fllLers do noL lnLeracL wlLh each oLher.
Moreover, Lhe Lwo fllLers over Llme represenL dlfferenL meanlngs:
1he ouLer one means: who have boughL a mounLaln Llre Lube any Llme before now"
1he lnner one means: who have boughL a mounLaln blke any Llme before now"
1hus, changlng Lhe way Lhe Lwo fllLers over Llme are applled you can easlly change Lhe semanLlcs of Lhe
formula Lo maLch your exacL speclflcaLlons.
WhaL makes 8askeL Analysls a very lnLeresLlng scenarlo ls LhaL you can use Lhe very same Lechnlque Lo
compuLe Lhe value of noLPavlngroducL. 1he formula of noLPavlngroducL ls Lhe followlng:

The Many-to-Many Revolution 143

=/+I6L;1J\9/C07+: gD
$-#$'#-%" )
!"#$%&"'( *
F@=%>& *
C-9!587490,B
!2=!#=2%> *!"#$%&"'( *FG37@670,607(GK08:: I <
:
:B
3<#%"4 )
-## )?;.%;.B2T
?;.%;.Bb%;.BlB@c ZD (-j )?;.%;.Bb%;.BlB@c2
2T
3<#%"4 )
?;.$0:+/.B9T
!'(j )
\9/C07+3;F+B9T
$-#$'#-%" )
$5'=%45H! )367+<1+B91B+!6FB:2T
-## )367+<1+B91B+!6FB:2T
367+<1+B91B+!6FB:b$0:+/.B9lB@c D "-4#<"4 )?;.$0:+/.B9b$0:+/.B9lB@c2T
367+<1+B91B+!6FB:b\9/C07+lB@c D "-4#<"4 )\9/C07+3;F+B9b\9/C07+lB@c2T
3<#%"4 )
-## )?;.%;.B2T
?;.%;.Bb%;.BlB@c ZD (-j )?;.%;.Bb%;.BlB@c2
2
2
2 Y W
2
2
1he only change ls ln Lhe hlghllghLed parL of Lhe formula, whlch now counLs Lhe number of cusLomers who
dld noL buy any producL, among Lhe fllLered ones. All Lhe resL of Lhe formula ls ldenLlcal Lo Lhe prevlous
one.
lL ls lnLeresLlng Lo noLe LhaL ln uAx you can compuLe dlfferenL values uslng Lhe same paLLern. Maklng Lhe
same compuLaLlon ln MulLldlmenslonal wlLh Mux ls very complex and Lhe besL way Lo perform Lhe
compuLaLlon of noLPavlngroducL ls Lo change Lhe daLa model addlng a Lable and some L1L. 1hls addlLlonal
sLep ls noL necessary ln 1abular and clearly shows Lhe power of 1abular.
DENALI IMPLEMENTATION
All Lhe code shown up Lo now works wlLh owerlvoL 1.0 and we declded Lo show lL for educaLlonal
purposes, because Lhe code ln uAx 1.0 clearly shows Lhe Lechnlque LhaL need Lo be used. neverLheless, we
wanL Lo exLend Lhls chapLer wlLh some flnal conslderaLlons wrlLlng Lhe very same formula wlLh uenall.
! A note of warning. These formulas, in the CTP3 version of Denali, might
make PowerPivot to crash. As it happened with the previous scenario, the
usage of USERELATIONSHIP can cause problems to the beta release of the
product.

1he mosL lnLeresLlng feaLure we can leverage ln uenall, regardlng Lhls formula, ls Lhe capablllLy Lo creaLe
more Lhan one relaLlonshlp uslng Lhe same column and mark Lhese relaLlonshlps as lnacLlve. An lnacLlve
www. sql bi . com


144 The Many-to-Many Revolution
relaLlonshlp ls a relaLlonshlp LhaL holds Lrue buL ls noL used by defaulL by Lhe verLlpaq englne. lf we wanL Lo
wake Lhe relaLlonshlp up, we need Lo use Lhe uSL8LLA1lCnSPl keyword.
LeL us sLarL wlLh Lhe daLa model ln uenall shown ln llgure 137.

Figure 137 Basket Anal ysis Data Diagram in PowerPivot Denal i
?ou can clearly see Lhe Lwo doLLed llnes connecLlng lacLlnLerneLSales wlLh boLh roducLlllLer and
ulmroducL. 1hese doLLed llnes represenL lnacLlve relaLlonshlps. 1hus, fllLerlng ulmroducL or roducLlllLer
wlll noL resulL ln a cross fllLerlng of lacLlnLerneL sales.
WlLh Lhls new daLa model, Lhe formula of PavlngroducL becomes:
I6L;1J\9/C07+: gD

$-#$'#-%" )
$5'=%45H! )
3<#%"4 )
?;.$0:+/.B9T
$-#$'#-%" )
$/01+4/M: )367+<1+B91B+!6FB:2T
'!"4"#-%<5=!I<\ )367+<1+B91B+!6FB:b\9/C07+lB@cT ?;.\9/C07+b\9/C07+lB@c2
2 Y W
ii
$-#$'#-%" )
$/01+4/M: )367+<1+B91B+!6FB:2T
'!"4"#-%<5=!I<\ )367+<1+B91B+!6FB:b\9/C07+lB@cT \9/C07+3;F+B9b\9/C07+lB@c2
2 Y W
2
2T
3<#%"4 )
-## )?;.%;.B2T
?;.%;.Bb%;.BlB@c ZD (-j )?;.%;.Bb%;.BlB@c2
2
2

The Many-to-Many Revolution 145

1here are several aspecLs of Lhls new formula LhaL make lL appeallng:
lL ls much clearer Lhan Lhe prevlous ones. Pavlng Lhe chance Lo model Lhe relaLlonshlp lnslde
Lhe daLa model makes lL easler boLh Lo wrlLe and Lo undersLand Lhe formula.
lL ls fasLer. ln general, ln uenall, Lhe usage of uSL8LLA1lCnSPl resulLs ln fasLer querles when
compared Lo Lhe usage of llL1L8 Lo mlmlc Lhe relaLlonshlp, due Lo lnLernal opLlmlzaLlons
lnLroduced by Lhe handllng of relaLlonshlps.
1here ls only one lLeraLlon over ulmCusLomer, agalnsL Lhe Lwo we needed Lo develop ln Lhe
prevlous formulas
llnally, Lhe formula for noLPavlngroducLs ls sLralghLforward, much easler Lhan before:
=/+I6L;1J\9/C07+: gD

$-#$'#-%" )
$5'=%45H! )
3<#%"4 )
?;.$0:+/.B9T
$-#$'#-%" )
$/01+4/M: )367+<1+B91B+!6FB:2T
'!"4"#-%<5=!I<\ )367+<1+B91B+!6FB:b\9/C07+lB@cT ?;.\9/C07+b\9/C07+lB@c2
: I <
ii
$-#$'#-%" )
$/01+4/M: )367+<1+B91B+!6FB:2T
'!"4"#-%<5=!I<\ )367+<1+B91B+!6FB:b\9/C07+lB@cT \9/C07+3;F+B9b\9/C07+lB@c2
2 Y W
2
2T
3<#%"4 )
-## )?;.%;.B2T
?;.%;.Bb%;.BlB@c ZD (-j )?;.%;.Bb%;.BlB@c2
2
2
1he only dlfference from Lhe Lwo formulas now belng Lhe LesL for equals Lo zero" lnsLead of greaLer Lhan
zero" ln Lhe check agalnsL ulmroducL.
1he many-Lo-many paLLern ls sLlll here, ln Lhe Lwo lnnermosL CALCuLA1L buL Lhe lnLroducLlon of lnacLlve
relaLlonshlps leads Lo formulas LhaL are easler Lo wrlLe and, as a dlrecL consequence, easler Lo use and
adopL.
?ou mlghL have noLlced LhaL, Lhls Llme, we dld noL use Lhe SuMMA8lZL paLLern Lo compuLe Lhe many-Lo-
many fllLer. 1here ls a reason for LhaL. 1he PavlngroducL can be wrlLLen uslng Lhe SuMMA8lZL Lechnlque
ln Lhls way:
www. sql bi . com


146 The Many-to-Many Revolution
I6L;1J\9/C07+: gD

$-#$'#-%" )
$-#$'#-%" )
$5'=%45H! )?;.$0:+/.B92T
$-#$'#-%"%-]#" )
!'((-4<h" )367+<1+B91B+!6FB:T ?;.$0:+/.B9b$0:+/.B9lB@c2T
'!"4"#-%<5=!I<\ )367+<1+B91B+!6FB:b\9/C07+lB@cT ?;.\9/C07+b\9/C07+lB@c2
2T
$-#$'#-%"%-]#" )
!'((-4<h" )367+<1+B91B+!6FB:T ?;.$0:+/.B9b$0:+/.B9lB@c2T
'!"4"#-%<5=!I<\ )367+<1+B91B+!6FB:b\9/C07+lB@cT \9/C07+3;F+B9b\9/C07+lB@c2
2
2T
3<#%"4 )
-## )?;.%;.B2T
?;.%;.Bb%;.BlB@c ZD (-j )?;.%;.Bb%;.BlB@c2
2
2
Agaln, Lhe uenall synLax ls very clear and makes Lhe formula shlne.
1he problem ls wlLh noLPavlngroducL. ln facL, ln noLPavlngroducL we are lnLeresLed ln cusLomers who
dld noL buy Lhe producL. SuMMA8lZL wlll easlly flnd poslLlve relaLlonshlps buL ls noL well sulLed Lo search
for non-exlsLlng ones.
ln Lhls case, however, lL ls enough Lo noLe LhaL LhaL elLher a cusLomer has boughL a producL or he has noL.
1hus, lf we counL all cusLomers who have boughL a producL ln roducLlllLer and subLracL from Lhls value Lhe
ones who have boughL a producL ln ln ulmroducL, we wlll be able Lo compuLe Lhe noLPavlngroducLs
value wlLh a slmple subLracLlon.


The Many-to-Many Revolution 147

Considerations About Multidimensional Models
Many-Lo-many, alLhough noL handled naLlvely ln verLlpaq, can be easlly managed wlLh Lhe uAx language,
as we have demonsLraLed ln Lhe prevlous chapLers and Lhey beneflL from Lhe Lremendous speed of Lhe
verLlpaq englne.
1he only Lhlng LhaL ls really needed Lo work wlLh many-Lo-many ln uAx ls a good undersLandlng of how Lhe
CALCuLA1L funcLlon works whlch baslcally means havlng a good knowledge of Lhe uAx language. 1abular
daLa models are slmple, alLhough noL very easy Lo undersLand aL flrsL glance.
Cne lnLeresLlng polnL of many-Lo-many ln verLlpaq ls Lhe facL LhaL many dlfferenL formulas can be
compuLed wlLhouL changlng Lhe daLa model and wlLhouL Lhe need Lo creaLe L1L sLeps Lo feed a complex
model, creaLed for a speclflc soluLlon. 1he 8askeL Analysls daLa model ls a clear demonsLraLlon of Lhe
power of Lhe uAx language and Lhe verLlpaq englne: wlLhouL any modellng sLep we can compuLe very
complex and lnLeresLlng measures.
Moreover, lL ls worLh Lo noLe LhaL - ln general - 1abular models are easler Lo wrlLe and opLlmlze when
compared agalnsL MulLldlmenslonal ones. A good measure of Lhls sLaLemenL ls Lhe lengLh of Lhe 1abular
secLlons compared wlLh Lhe MulLldlmenslonal one. We needed far few pages and llnes of code Lo explaln
Lhe same model ln 1abular Lhan ln MulLldlmenslonal whlle, hopefully, keeplng Lhe same clarlLy ln Lhe
explanaLlon.
LINKS
http://www.sqlbi.com/articles/many2many/ : Lhe pro[ecL home page for Lhls paper and
relaLed resources
http://www.sqlbi.com : communlLy dedlcaLed Lo 8uslness lnLelllgence wlLh SCL Server
http://sqlblog.com/blogs/marco_russo : blog of Marco 8usso (auLhor)
http://sqlblog.com/blogs/alberto_ferrari : blog of AlberLo lerrarl(auLhor)
http://www.sqlbi.com/articles/sqlbi-methodology/ : Lhe SCL8l MeLhodology
paper for besL pracLlces ln 8l soluLlon deslgn
http://www.amazon.com/gp/product/1847197221/?tag=se04-20 : Lhe book
LxperL Cube uevelopmenL wlLh MlcrosofL SCL Server 2008 Analysls Servlces"
wrlLLen by Marco 8usso, AlberLo lerrarl and Chrls Webb
http://www.amazon.com/dp/0735640580/?tag=se04-20 : Lhe book
owerlvoL for Lxcel 2010: Clve your daLa meanlng" wrlLLen by Marco 8usso
and AlberLo lerrarl.
http://www.powerpivotworkshop.com : 1wo-day workshop on owerlvoL and Lhe uAx
language, Lhe perfecL place where Lo Louch Lhe karma of uAx wlLh Lhe auLhor of Lhls paper.
http://tinyurl.com/optimizeM2M : Analysls Servlces Many-Lo-Many ulmenslons: Cuery
erformance CpLlmlzaLlon 1echnlques

You might also like