Alleen een datawarehouse of ook data marts?

[FaceDown]

Wij zitten tijdelijk met twee verschillende ERP systemen vanwege een fusie. Over minimaal een jaar zullen we pas over gaan op 1 ERP systeem.

We gaan nu een datawarehouse implementeren om sales report, financial reports etc te maken. De data hiervoor wordt uit de ERP systemen getrokken.

Een tijd terug (toen ik nog student was ) heb ik een module datawarehousing gehad. Verder ben ik me aan het inlezen om de materie weer wat op te frissen.

Nu zie ik in schema's vaak data marts voorbij komen. Dat wil zeggen; data wordt uit verschillende systemen getrokken en door een ETL-proces (extraction, transformation, loading) in een datawarehouse geladen. Vaak zie je dat van hieruit de data nog eens in verschillende data marts verdwijnt, elk bedoeld voor 1 specifieke afdeling (sales, marketing, production etc).

Ik lees echter nergens wat voor specifieke voordelen die data marts nu bieden. Waarom niet OLAP-tools rechtstreeks in het datawarehouse laten graven? Heeft dit te maken met rechtenkwesties, maw dat sales mensen niet in data van finance mogen komen? Of is dit ook in een datawarehouse zelf te beperken?
Bestaan deze datamarts dus in feite uit bepaalde tabellen die uit het datawarehouse worden gehaald en waar mensen behorend tot een bepaalde afdeling in zouden mogen grasduinen?

De bedoeling is om SQL Server 2005 te gaan gebruiken, met Analysis Services, Reporting Services etc.

[Xiphalon]

Rechten inderdaad, of storageproblemen (liever 5x50 gb op elk een losse server dan 200 op 1 server), performance dat soort dingen

[FaceDown]

Maar is het niet zo dat je rechten op je cubes kan instellen? Dan heb je dat probleem getackled. Het performanceprobleem speelt hier niet zo omdat er hooguit enkele personen tegelijk data op zullen vragen (en het grootste gedeelte van de tijd niemand).

[Boss]

Kan denk ik ook met performance te maken te hebben. Door de (zelfde) data vooraf al in verschillende vormen te kneden en onder verschillende vormen op te slaan, kan je voorkomen dat je daarna zware queries op grote datasets moet gaan draaien. Zeker als je weet welke rapporten favoriet zijn bij sales en bij marketing kan je daar best wat voorbereidingen in treffen.

[JeroenB]

Ik herinner me van datawarehousing dat "performance" altijd een geldig antwoord is op vragen als "waarom doen we dat zo-en-zo?"

Daarnaast kun je datamarts zowel als pre-stap (eerst data verzamelen in datamarts en daarna afgeleide informatie laten samenkomen in het datawarehouse) als post-stap (eerst alles in een datawarehouse verzamelen en dan daar weer subsets van verplaatsen naar specifieke datamarts).

Zelf zou ik uitgaan van een datawarehouse en pas over datamarts nadenken als er performance-problemen zijn (waarmee ik niet wil zeggen dat je pas achteraf de boel moet ombouwen, maar dat datamarts pas het overwegen waard zijn als je hebt vastgesteld dat de route met alleen een datawarehouse voor problemen gaat zorgen).

[EfBe]

'datamart' klinkt als een buzzword bedacht door high-payed consultants om hun te hoge rekeningen te rechtvaardigen.

Een cube is alleen nuttig als je de data die van belang is voor het eindresultaat ook kan gebruiken in die cube. Dit houdt dus in dat opsplitsen van data wel leuk lijkt, maar dat opsplitsen dus ook kan zorgen voor problemen wanneer je een cube wilt runnen die dus data uit meerdere delen nodig heeft en daardoor dus teveel tijd kost of zelfs helemaal niet mogelijk is.

Dus opsplitsen moet met beleid gebeuren en dus alleen wanneer dat echt nodig is. Je moet wel erg veel data tezamen in 1 database proppen wil je tegen die problemen aanlopen. Tja, reports kosten tijd, het loont veelal meer de moeite data op te splitsen al naar gelang de data archiveerbaar is of niet. Aggregated reports over archived data zijn zelden reports die je veel draait, waardoor je actuele dataset kleiner kan zijn en je reports op die data dus efficienter.

Maar dat begint ook al te vaag te klinken om er wezenlijk iets mee te kunnen, zoals alles wat ERP heet of eraan gerelateerd is.

[riZZy]

OLAP-tools hebben vaak ook een datamodel nodig dat dimensioneel opgezet is.
Dit terwijl je je datawarehouse zelf waarschijnlijk (voor schaalbaarheid) relationeel wil opzetten.

Dan kun je er voor kiezen om een datamart bovenop je datawarehouse te zetten. Dit biedt dan inderdaad vaak ook performancewinst.

[Boss]

Aggregated reports over archived data zijn zelden reports die je veel draait, waardoor je actuele dataset kleiner kan zijn en je reports op die data dus efficienter.

Zjin dat niet juist de enige reports die je vaak draait? Managers en dat soort figuren willen elke dag totalen (aggregated) zien en die vergelijken met andere totalen. Maar voor de boekhouding moet je toch echt losse records bewaren.

Volgens mij zit de performance winst eerder in het uitwerken van joined tabels waardoor je meer redundancy in je totale data krijgt, maar de query snelheid hoger wordt op grote datasets.

[EfBe]

Boss schreef op woensdag 15 november 2006 @ 11:43:
[...]

Zjin dat niet juist de enige reports die je vaak draait? Managers en dat soort figuren willen elke dag totalen (aggregated) zien en die vergelijken met andere totalen. Maar voor de boekhouding moet je toch echt losse records bewaren.

Volgens mij zit de performance winst eerder in het uitwerken van joined tabels waardoor je meer redundancy in je totale data krijgt, maar de query snelheid hoger wordt op grote datasets.

Gearchiveerde data verandert niet. Dus 1 keer zo'n report draaien en je kunt hem t.a.t. opvragen alszijnde het rapport over die data.

Denormalizatie kan helpen, maar het vermijden van onzinnig telkens weer reports draaien van data die niet verandert helpt veel meer.

[JeroenB]

EfBe schreef op woensdag 15 november 2006 @ 13:21:
Gearchiveerde data verandert niet. Dus 1 keer zo'n report draaien en je kunt hem t.a.t. opvragen alszijnde het rapport over die data.

Het probleem is dat die rapporten aggregaties zijn van andere datasets, oftewel ze zijn steeds in beweging: dan moet je of de hele query opnieuw draaien, of je moet een (relatief kleine) query doen over de nieuwe data en dan alle oude data updaten daarmee. Dat kan in principe tijd schelen maar zal in de praktijk een complexe aangelegenheid kunnen worden denk ik.

[FaceDown]

riZZy schreef op woensdag 15 november 2006 @ 11:37:
OLAP-tools hebben vaak ook een datamodel nodig dat dimensioneel opgezet is.
Dit terwijl je je datawarehouse zelf waarschijnlijk (voor schaalbaarheid) relationeel wil opzetten.

Dan kun je er voor kiezen om een datamart bovenop je datawarehouse te zetten. Dit biedt dan inderdaad vaak ook performancewinst.

Correct my if i'm wrong, maar als je een relationeel datawarehouse hebt, dan kun je toch cubes definieren die per definitie multidimensioneel zijn? OLAP tools laat je dan toch gebruik maken van deze cubes?

Verder kan ik me goed vinden in de voorgestelde aanpak van JeroenB, om eerst een datawarehouse te 'proberen' en in geval van performanceproblemen (die ik absoluut niet verwacht gezien het beperkt aantal personen dat gebruik gaat maken van het DW) het definieren van data marts als zijnde subsets van het DW.

[ Voor 19% gewijzigd door FaceDown op 15-11-2006 15:26 ]

[riZZy]

Uitstapje: Kun je op het moment dat je een cube hebt gemaakt op je (relationele) datawarehouse, dat niet zien als zijnde een datamart?

Er zijn iig OLAP-tools (waarmee je de cube maakt) die niet overweg kunnen met relationele bronnen. Nu zijn er bedrijven die dat oplossen met views op het datawarehouse, maar echt lekker gaat dat nooit performen.

[FaceDown]

Misschien haal ik ook wel een aantal zaken door de war. Ik ging er vanuit dat je een datawarehouse maakt (relationele db met bijv SQL Server 2005). In SQL Server 2005 kun je vervolgens cubes definieren. In deze cubes kun je vervolgens met bijvoorbeeld excel en de SQL Server Analysis Services addin voor excel gaan graven en reports gaan maken.
Ik dacht dat alleen het 'excel-gedeelte' in dit geval OLAP was, maar het definieren van cubes hoort daar ook bij dan?

[Siliakus]

Misschien even een kleine uitleg:

OLAP is een set functies in een database dat (gespecialiseerde) analytische queries op gegevens mogelijk maakt. De gegevens kunnen beschikbaar zijn in een multidimensionaal datamodel (MOLAP) of een relationeel datamodel (ROLAP).

Het onderscheid is moeilijk te maken, maar rule-of-thumb is: MOLAP = cube, ROLAP = star of snowflake model.

Verder ben ik niet zo thuis in de MS product stack op dit gebied, maar gegevens opvragen vanuit Excel lijkt me niet haalbaar. SQL SAS zal wel een reporting tool zijn dan? Waarschijnlijk heeft dit dan iets van een export functionaliteit waardoor de gevonden data in excel gebruikt kunnen worden.