Skip to content

Wordperfect is tot Word als SQL is tot MDX

5 februari 2010
tags: ,

Afgelopen week heb ik mijn collega geholpen bij het maken van rapporten op basis van een OLAP kubus. Het deed mij terugdenken aan mijn studententijd. Dit was in de tijd dat Microsoft echt begon op te rukken. Windows was een feit en Word deed de intrede. Van huis uit was ik Wordperfect gewend. Met veel vallen en opstaan heb ik die ***functietoetsen uit mijn hoofd geleerd en zoals met alles nieuw: je leert er op je eigen manier mee omgaan.

De overgang naar Word verliep alles behalve soepel want ik probeerde natuurlijk alles op dezelfde manier te doen als in Wordperfect. Het grote verschil tussen Wordperfect en Word is dat Wordperfect instellingen deed op zinsniveau en Word op woordniveau. En dat is gewoon een totaal andere benadering van tekstverwerking. Zo is het ook met SQL en MDX rapporten: het is een totaal andere benadering van data.

Nu moet je niet denken dat ik SQL of MDX zit te kloppen. Ik heb gelukkig een front-end tool die dat voor mij doet. Maar de functies die de front-end tool aanbiedt zijn wezenlijk verschillend omdat ze op een andere benadering van data berusten. SQL is ‘veld’ gericht en MDX is ‘waarde’ gericht. Ook is de relatie tussen dimensie en feit anders. Bij SQL wordt de waarde van een dimensieveld alleen getoond als er voor die betreffende dimensie een meetwaarde feit is. Bij MDX hoeft dit niet het geval te zijn. De waarden van een dimensieveld worden ook getoond als er geen meetwaarde feit voor is.

Pisa, Pink Lady

Dit betekent dat het filteren van getoonde waarden van een dimensie voor een bepaalde meetwaarde in een rapport wezenlijk anders plaatsvinden. Stel je hebt een foto van jezelf voor de toren van Pisa. Wanneer je een filter op jezelf zou zetten in een SQL omgeving, dan wordt jij uit de foto geknipt. Je wilde niet de toren zien, maar alleen jezelf. Je hebt nu ook geen idee van de context meer. Als je dit stukje foto aan je moeder zou laten zien, dan zou ze niet zeggen gôh was dat niet in Pisa.

Als dezelfde foto in een MDX omgeving zou zijn en je zou er een filter(slicer) op jezelf overheen gooien, dan zou de foto als geheel blijven bestaan. Alles om je heen zou alleen bijvoorbeeld in grijze tinten worden weergegeven. Jij springt eruit, maar je bent de context niet meteen kwijt. Nu herkent je moeder meteen waar de foto van is.

Je ziet dat dit meteen een uitdaging oplevert. Want wat als ik in de MDX omgeving hetzelfde resultaat wil bereiken als in de SQL omgeving? Je moet dan expliciet aangeven voor de foto dat je alles dat niet voldoet aan jezelf NIET getoond wil hebben. Pas dan heb je hetzelfde resultaat in de SQL omgeving. Ik geeft toe dat dit omslachtiger is dan in een SQL omgeving. Maar die relatieve onafhankelijkheid tussen de waarden van een dimensie en waarden van de feiten geven ook een ongelofelijke vrijheid.

Je kunt in een MDX rapport heel eigen zinnen creëren omdat je beschikt over de laagste bouwstenen: de waarden zelf. Als je in een SQL omgeving expliciet iets met bepaalde waarden wilt doen, dan is dat lastiger omdat dit uitgaat van ‘zinnen’: alle waarden die bij een bepaald veld horen. Dan krijg je vaak verschrikkelijke if-then-else constructies of meerdere queries die ten grondslag liggen aan een rapport.

Ik moest weer heel erg wennen na een periode van veel MDX rapporten te hebben gemaakt om terug te gaan naar SQL rapporten. Beide hebben voor- en nadelen. Heb je nog nooit MDX-rapporten gemaakt: probeer het! Het is even doorbijten, maar echt de moeite waard!

No comments yet

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s

%d bloggers op de volgende wijze: