Ik ben zelf voorstander van een dataset op basis van je datamart (gewone database) en niet op je OLAP-cube. De eerste reden is dat wanneer je op je datamart een dataset maakt je geen kennis hoeft te hebben van MDX, hetgeen moeilijk te leren is. Je kunt volstaan met SQL. Daarnaast zijn rapporten statisch en niet bedoeld voor analyse. OLAP is met name geschikt om data weer te geven op geaggregeerd niveau waarbij snelheid een belangrijke rol speelt.

Kortom, bouw je rapporten niet op een cube maar op een gewone database

Ik ben wel benieuwd hoe je op zo'n moment om gaat met de beveiliging van je data. Uiteraard geldt dit bij lang niet alle rapportages, maar wanneer het rapport gegevens benaderd die afdeling specifiek zijn dan is de data afscherming d.m.v. rollen toch wel een welkome aanvulling.
Bij de projecten waar ik aan gewerkt heb was het uitgangspunt dat de rapporten hun data alleen uit de kubus haalden. Er zijn een aantal situaties waarbij je er niet aan ontkomt om de kubus links te laten liggen en direct het datawarehouse aanspreekt.

Dit leverde voor ons zowel voor als nadelen op. Het grootste nadeel dat we ondervonden was de query taal MDX. Intern konden we er goed mee uit de voeten, maar zodra een klant zelf rapportages wil bouwen ontkomt hij er niet aan om enigzins kennis van MDX op te doen. De query's die reporting services voorschotelt presteren niet altijd even fijntjes. Zoals gezegd heb je wel het voordeel van data-afscherming in je kubus.

Ik ben benieuwd hoe jullie hier tegenaan kijken.

Mark,

Zodra een gebruiker een rapport-parameter wil kiezen wordt zijn gebruikersnaam doorgegeven aan een SQL-functie. Deze kijkt vervolgens in een beveiligingstabel welke parameters hij mag kiezen. Ga uit van bijvoorbeeld afdelingen. Gebruiker XXX mag alleen afdeling XXX zien. Zodra hij een parameter 'Afdeling' wil kiezen gaat er op de achtergrond in de tabel gekeken worden welke hij mag zien. Er is een tabel aanwezig met alle gebruikerscodes en welke afdelingen deze mogen zien. Snap je het principe?

Die SQL functie is dat een standaard SQL Server functionaliteit of iets wat je zelf bouwt?

Want wat gebeurt er op het moment dat datawarehouse beheerders zelf rapporten gaan definiëren? Moeten zij dan zelf rekening houden dat die functie aangeroepen wordt of is er een technische koppeling die daar automatisch voor zorgt?

Zelf gebouwde functie. Wij gebruiken een rapportageportal bovenop Report Manager. De parameters kies je in deze portal en worden vervolgens doorgegeven aan het rapport. Zodra de gebruiker zich in op de portal bevindt wordt er al een validatieslag gemaakt om de parameterbox te vullen, dit doet de functie.

Hoi Johan vdk,
Ik ben niet tevreden over samenwerking reporting services en cubes. Door dan te gaan sql'en, herbouwen van business logica , zoals hierboven is vernoemd leidt tot rework, dit is al voldoende valide om andere keuzes te maken in de presentatietooling binnen de MS BI stack, of daar buiten. Immers, wie zegt dat je reporting services moet gebruiken? en als de klant het afdwingt, staat het vrij om af te zwaaien voor een eervoller bestaan. Die jongens van SSRS product team hebben blijkbaar 1 of meer MS-architectuur briefings gemist bij MS , aangezien het excel team al langer op SSAS werkzaam was , hebben die het wel begrepen.

Toelichting:

Volgens de MS architectuur is de OLAP kubus de "single version of truth" beleveraar op elk niveau. Ik ga er helemaal in mee, taak van de specialist in DWH traject is namelijk een business repository te bouwen, liefst zo sterk mogelijk , en daar leent de cube zich , op zijn plek in het proces, prima voor. Die business repository dient zich te lenen voor de organisatie om zelf, met daarvoor geeigende structuren in rollen en procedures, onbeperkt op los te gaan. Middels het shared dimension en shared facts model kan je Ansi-sparc conform , a la semantische laag of framework zoals andere vendors het noemen, een ontkoppelpunt maken en zo consistent, eenmalig, toetsbare definities opleveren. Waar die definities terecht komen in rapporten/analyses is aan de organisatie te beslissen, maar dit dient met eigen effort te doen te zijn (applicatiebeheerder , analist who ever).

(vervolg)

een opgeleverde definitie in een business repository is vergelijkbaar met een artikel in de logistiek: ga je constant met reporting services aan de gang, dan loop je telkens met de klant mee naar het schap, herbenoemt het artikel (de definitie) , gaat het terughalen naar de balie, en rekent vervolgens af.
A). als je producten verkoopt , op schappen legt en netjes verpakt herkennen ze het zelf wel, (business repository uitleggen en documenteren) B). De DWH/Bi specialist kan zich met zinvoller dingen bezig houden het magazijn vullen, adviseren en de zaak netjes op het schap leggen (de business repository). Operational efficiency. Of A en B uitkomen, is afhankelijk van de presentatietool.

De rigiditeit van de SSRS reporting tool maakt het wel weer geschikt om dashboard grafiekjes te plaatsen waarin rigide doorlooppaden een uniform doorloopperspectief op de werkelijkheid afdwingen. Maar dan hebben we het vaak over een beperkte set reports.Daarvoor mag je wel even tweaken.

Als we de MS BI-stack beschouwen is het zinvol, indien daartoe ruimte voor is bij een opdracht, te kijken naar de tooling en de trade-offs die te maken zijn. Ben je veroordeeld tot SSRS wellicht zinvol om een andere opdracht te zoeken , concessies aan de backend (herbouw logica) is niet bepaald de DWH specialist zijn favoriete werk gezien die de evt ramp al kan overzien in de toekomst. De stack is sql server + sharepoint BI. Je presentatietooling hangt dus primair af van de keuzes die je maakt in licensing. Neemt je klant alleen SQL Server af, prima: dan zal die of SSRS in moeten zetten (het beschreven SSRS winkelmodel) of het kleine broertje report builder om toch zelf naar het schap te kunnen lopen. De report builder client-tool is in 2005 nogal beperkt dat je eindgebruiker zich nog steeds beperkt voelt

Vergelijken we de kracht van een pivot (in sharepoint, excel services) met de traditionele reportelementen (tabellen, grafiekjes) dan wint de pivot in versaliteit met glans. Je kan je dan ook afvragen of het tijdperk van de rigide tools (reporting services en report builder) niet zo'n beetje voorbij is.

Redenen waarom je de kubus zou gebruiken:
- commit aan de MS architectuur, is handig naar de toekomst toe (je mag aannemen dat de vendor daar logische sprongen in maakt)
- ontkomen aan het inefficiente winkelmodel : gedetailleerde sterke business repository opleveren en niet met hand en spandiensten reporting de tijd verdoen, laat staan logica dubbel uitvoeren
- Dimension security is veel gedetailleerder dan relationele database security. Makkelijker op te stellen, en met cell-security kan je afdalen tot de unieke value (gaat je relationeel niet lukken tenzij tig functies te gebruiken)
- T-sql is geschikt voor data-logistiek in het voortraject, voor het verschuiven van verzamelingen van A naar B, echter ongeschikt voor analyse, op event gecentreerde analyse na. Middels kubussen verleg je de aggregaties van het DWH naar de kubus, dat is exact 1 van de redenen van multidimensionale modellen, door dimensioneel te modelleren is exact te herleiden waar te aggregeren en is eea aan aggregatieniveau eenvoudig instelbaar, dat is de "OLAP engine".
- leaf-level reporting kan ook met kubussen, hoewel dit iets trager zal zijn dan het alternatief met de stored procedure die op views werkt op het DWH (om ansi-sparc compliant te zijn)

Ben je niet tevreden over de presentatietools, koop je simpelweg iets anders voor de presentatie, iets wat nog altijd vaak gebeurt op de MS stack.
Het herbouwen van business logica , zoals hierboven wordt genoemd is vanuit dwh/data-logistiek oogpunt toch uiteindelijk riskante situatie en leidt tot rework, is op zichzelf al voldoende valide om andere keuzes te maken in de presentatietooling in de MS BI stack, of daar buiten.