Dimensionele database - ster en snowflake modellen

[Mike Jarod]

Ten eerste, ik heb geen flauw idee waar in welk subforum ik deze zou moeten plaatsen. Een search levert bijna geen relevante hits op dus dat geeft me geen hint waar dit thuis zou horen.

Op mijn werk maken we veel gebruik van relationele databases. Voornamelijk DB2 en Oracle. Hier ben ik redelijk goed in op weg, en een heleboel bedrijfskritische scripts zijn in SQL en PL/SQL geschreven. Voornamelijk maken we vergelijkingen tussen meerdere systemen, of binnen 1 systeem. Sommige script bevatten 1000en regels SQL.

Nu wil mijn bedrijf over gaan stappen op een data warehouse systeem van dimensionele databases. Dit is iets wat ik nooit op school heb gehad, en waar ik moeite mee heb om het te begrijpen. Ik heb al eea uitgelegd gekregen en ik begrijp dat je op een andere manier tegen je data aan gaat kijken. Probleem is dat niemand binnen mijn bedrijf er echt verstand van lijkt te hebben, en dat ze erg makkelijk op zich in laten praten door consultants van een partij die het data warehouse systeem wil verkopen.

Hier een beschrijving van dimensionele databases.

Ik begrijp dat de voordelen voornamelijk bij rapportage en analyse gaan liggen. Door een goede database opbouw kan je schijnbaar zeer makkelijk queries uitvoeren door wat dingen te sleuren en te pleuren in een query applicatie zoals Oracle Discoverer. Als je dezelfde acties uit zou willen voeren met SQL dan zou je heel veel tabellen moeten joinen etc. Dit ben ik gewend dus vind dat niet erg. Voor het management is SQL natuurlijk geen optie, die moeten gewoon met weinig moeite de gegevens kunnen zien die ze willen. Daarom zijn ze zo geil op deze nieuwe methodiek.

De voordelen zijn me dus wel duidelijk (werkwijze en onderliggende gedachte nog niet), maar er komt ook nog eens bij dat ze op termijn al onze relationele databases uit willen faseren. Ik heb een database tot mijn beschikking met downloads uit diverse bronsystemen, waar ik met SQL vergelijkingen op uitvoer. Dit kan varieren van 'zoek alle errors uit tabel x' tot complete analyses van bedrijfsprocessen door scripts. Ook krijg ik geen schrijfrechten op dit data warehouse, dus tijdelijke tabellen maken is er niet bij.

Dit vind ik dus allemaal eng, ik kan niet inschatten of mijn huidige scripts om te zetten zijn naar een dimensionele database met stermodellen en snowflakes. Aangezien de bronapplicaties relationeel zijn, en mijn queries en denkwijzen dus ook, lijkt het me zeer omslachtig om gewoon alle errors uit tabel x naar boven te halen. Met SQL is dat een mini query.

De vraag Zijn hier mensen die ervaring hebben met dit soort databases en mij kunnen vertellen wat ik er wel en niet mee kan? Vooral de beperkingen ben ik in geinteresseerd. De enige bronnen die ik verder heb zijn de consultants die alles mooier brengen dan het is, ik wil graag praktijkervaringen. Bedankt.

[D4Skunk]

Bij een van mijn klanten worden dimensionele databases redelijk intensief gebruikt; ze werken nl met SAP.

Wat mij vooral opvalt, is dat het merendeel van de applicaties nooit gemigreerd wordt, maar gewoon verder op relationele databases draait, en er een synchronisatie-laag is die diezelfde data aanlevert/omzet naar een dimensioneel model (fact & dimension tables).

Het lijkt me dan ook eerlijkgezegd nogal bizar dat je al je bestaande applicaties hiervoor zou ombouwen, tenzij je alles binnen dit datawarehouseconcept gaat gaan inpassen (enorme kostprijs imho !!!).

Op querygebied moet je je echt geen zorgen maken, gezien zo'n tool -je zegt het zelf al- voorziet in alle mogelijkheden om je data te query-en.

Los van het dimensionele databases verhaal, denk ik dat het voor zo'n grote projecten nooit onverstandig is om eens een tweede mening te vragen.
Wat ik persoonlijk bij al mijn klanten aanraad in zo'n geval, is dat ze een onafhankelijk consultant met expertise op dit gebied tegen betaling het project laten inschatten. Deze consultant moet van voorafaan weten dat hij het project niet zal mogen uitvoeren, enkel inschatten, zodat je een min of meer eerlijke inschatting krijgt.
Bij dergelijke grote projecten is het schering en inslag om de kostprijs wat lager te leggen, en dan achteraf het budget naar omhoog te trekken, om zo de opdracht toch binnen te halen.

[killercow]

Management moet niet janken,

Managers geilen inderdaad op de statistieken etc die zou zouden kunnen klikken en sleuren, maar als puntje bij paaltje komt blijken de volgende problemen zich voor te doen, ongeacht het systeem/ de methodiek/ de data of het bedrijf:

* Ze weten niet wat ze willen zien, dus hoe maak je er dan een query voor
* Ze weten niet hoe ze het moeten klikken en slepen, (wedden dat 95% mapjes in outlook nog lastig vindt?, laat staan filters)
* Ze vragen alsnog de whizzkids erbij om de query in elkaar te stoppen.
* Ze hebben geen idee van de data die opgeslagen is, en hebben ook geen idee wat je er wel en niet mee zou kunnen.
* Ze begrijpen niet hoe data uberhaupt opgeslagen wordt,

* omdat de whizzkid het toch moet code, kun je net zo goed met je huidige data/database werken, ze hebben alleen nog nooit de moeite genomen te begrijpen wat er in de db aan data zit, en zullen dus nooit zinnige vragen kunnen bedenken van wat ze eruit kunnen halen.

Een andere methodiek/db lost niks op aan het probleem dat de manager niet geintresseerd is. Hoe vaak maakt een programmeur niet een query die iets weergeeft WAARNA de manager zegt, das handig! maar niet doorvraagt of dat ook voor x/y mogelijk is.

In ieder geval, dat zijn mijn ervaringen.

[JaQ]

Misschien een stomme opmerking, maar als er totaal geen ervaring in je organisatie is met dit soort technologie, dan lijkt mij het enigzins overstandig om zo'n groot project te starten. Zometeen zit je voor de rest van je leven aan een leverancier vast omdat er binnen je eigen organisatie te weinig kennis aanwezig is. Uiteraard is technologische vooruitgang belangrijk, misschien zelfs wel noodzakelijk, maar niet ten koste van alles. Ik zou zelf dus eerst proberen te kijken naar alternatieven waarmee je met je reeds aanwezige kennis uit de voeten kan. _{groot argument richting management: extra opleidingskosten bij nieuwe technologie}

Dit lijkt IMHO een beetje op de eeuwige discussie over linux vs windows, of Oracle vs SQL-Server, of IIS vs Apache (welke van de 2 beter is dus). Het hangt voor het grootste deel af van de kennis binnen de organisatie, voor de rest is het (grofweg) lood om oud ijzer.

[Soultaker]

D4Skunk schreef op donderdag 27 april 2006 @ 10:03:
Wat mij vooral opvalt, is dat het merendeel van de applicaties nooit gemigreerd wordt, maar gewoon verder op relationele databases draait, en er een synchronisatie-laag is die diezelfde data aanlevert/omzet naar een dimensioneel model (fact & dimension tables).

Dit is inderdaad de crux: de het dimensionele databaseschema bestaat vaak vooral in de ontwerpfase en wordt later geconverteerd naar een 'klassiek' relationeel schema. Kennis van relationele databases is dus best wel belangrijk,

Verder is een dimensionale database geen alles-overkoepelende techniek dus het is gewoon idioot om je relationele databases ermee te willen vervangen. In een dimensionele database worden gewoon andere soorten gegevens opgeslagen.

[The Eagle]

Een dimensionele db wordt meestal ook gewoon in een relationele DB gedaan hoor
Je moet het je een beetje voorstellen als een vierkant dat je uitbreidt naar een kubus.
Voorbeeld:
Gegeven verloop A is uitgezet tegen verloop B (in een blokgrafiek). Wat je nu doet is een extra dimensie toevoegen. Vaak zal de eerste dimensie de tijd zijn; men wil dan weten hoe het verloop van A tegen B in de loop der tijden aangepast wordt. In het simpelste geval is dit te realiseren door aan de tabel een datetime veld toe te voegen, Je gegevens worden dan met een tijdsindicatie opgeslagen, waardoor je historische gegevens ook op kunt vragen.
Nu is de tijd maar een voorbeeld, je zou ook nog tegen andere dingen uit kunnen zetten. Dat worden dan ook weer extra velden in de DB. Let er wel op dat dit dan waarschijnlijk key-velden zijn; immers, hier ga je op zoeken

[riZZy]

Helaas heb ik niet veel tijd voor deze reactie, maar toch even het volgende:

Een dimensionele opzet van een datawarehouse zorgt ervoor dat veel vragen veel makkelijker (en sneller) zijn op te lossen. Tevens werken geavanceerde querytools en managementinformatiesystemen hier ook veel beter mee. Je kan bv denken aan een portal, waar de manager zelf zijn informatie bij elkaar kan klikken. (evt met deels voorgedefinieerde rapporten). Mijn indruk is dat managers juiste precies weten wat ze willen. (al is dat vaak niet de informatie waarop ze zouden moeten sturen, maar dan wijk ik wel erg van het topic af).

Wat wel erg handig is (al eerder genoemd) dat de dimensionele laag boven de relationele laag staat. Zo kun je bijvoorbeeld historie bijhoduden in de relationele laag en in de dimensionele laag alleen de informatie van de laatste periode stoppen.

Kortom als toevoeging op een relationeel datawarehouse heeft het m.i. zeker toegevoegde waarde.

[ Voor 3% gewijzigd door riZZy op 28-04-2006 15:27 ]

[Mike Jarod]

Bedankt voor de reacties

Ik merk dat ik niet duidelijk genoeg ben geweest. We hebben bronapplicaties (relationeel). Van deze bronapplicaties heb ik downloads in een omgeving waar we veel scripts voor hebben geschreven (in deze omgeving hebben we bijna alle rechten). Nu komt er dus een data warehouse (waar we alleen leesrechten op krijgen), en willen ze op termijn die download omgeving uitfaseren. Dus niet de bronapplicaties! Wij zullen dus al onze scripts moeten herschrijven om dezelfde gegevens uit het data warehouse te krijgen. Omdat ik data warehouses nog niet goed begrijp, ben ik op zoek naar ervaringen om te kijken of wij ons werk wel kunnen blijven doen.

Zover ik het nu begrijp, is zo'n data warehouse voor ons wel een goede toevoeging, maar geen vervanging. Onze huidige werkwijze is vaak ad-hoc, we downloaden diverse tabellen richting onze omgeving om er queries op uit te voeren. De datasets zijn soms extreem groot dus zijn we gedwongen tijdelijke tabellen aan te maken met indexes om alles te versnellen en overzichtelijk te houden. In het warehouse krijgen we alleen leesrechten, en het lijkt mij onmogelijk om nu al te kunnen inventariseren welke tabellen er nodig zijn (deels wel), omdat er zoveel ad-hoc dingen zijn.

Vwb het commentaar op het management. Helemaal mee eens. Maar met trappen zonder inhoud kom ik nergens, ik moet met argumenten komen, vandaar dit topic.

Volgende week heb ik een gesprek geregeld tussen technici zoals ik en de consultants, en dan mogen ze uit gaan leggen dat wij met een data warehouse nog steeds alle werkzaamheden uit kunnen voeren. Als ze dan verkooppraatjes gaan houden vallen ze snel door de mand omdat er technici bij zitten.

Als ik jullie reacties goed lees, dan is een data warehouse een goede toevoeging voor management zaken, maar niet voor ad-hoc spul en diepe technische / proces analyses. Ik zal dan ook in dat gesprek met de consultants goed navragen hoe dit soort technische dingen te doen zijn.

[riZZy]

Hou je ons op de hoogte? Ik ben benieuwd hoe dit verder verloopt!

Je kan zeker niet vertellen welk consultancybedrijf het is?
Tot slot, met welke tools willen ze het datawarehouse gaan bouwen?
(vb: Oracle Warehouse Builder, Informatica, SAS)

[Croga]

Wat ik mij in deze vooral afvraag:

Waarom wordt er gekozen voor een "Datawarehouse" oplossing terwijl je in feite een Business Intelligence systeem nodig hebt (als ik naar de beschrijvingen kijk).

Door te kiezen voor een datawarehouse zullen alle toepassingen zelf gebouwd moeten worden. Het probleem hierbij is, zoals jij al beschrijft, dat je alles op laag niveau zult moeten doen. Zelf toepassingen bouwen met behulp van SQL/PLSQL op een dimensionele database is haast niet te doen.

Door gebruik te maken van een BI systeem worden alle low-level handelingen uit handen genomen. Je kunt simpelweg selecteren welke gegevens je wilt zien en het BI systeem bouwt de bijbehorende queries. Eventuele conversies van het bronsysteem naar het warehouse zul je weliswaar zelf moeten doen, maar daarna wordt alles een stuk makkelijker.

De opmerking die gemaakt wordt over "management weet toch niet wat ze willen" is in mijn ervaring ondertussen behoorlijk achterhaald. Met de juiste consultants weet het management tegenwoordig heel goed te beschrijven wat ze willen zien. De consultant moet dan natuurlijk wel genoeg kennis van dit soort systemen hebben om een beetje te kunnen sturen....
En als je eenmaal weet wat het management wil zien is het ook vrij eenvoudig om een bijbehorend BI systeem in te richten.

[riZZy]

Croga, een Business Intelligence systeem werkt alleen op basis van goed gemodelleerde data. Het datawarehouse kun je dan zien als 'motor' van de BI-tool.

Of ken jij systemen die dat in 1 keer kunnen? (In feite gebruik je natuurlijk wel weer een BI-tool om de data in de juiste vorm te krijgen, maar dat ter zijde.)

Volgens mij kun je niet spreken van een BI-oplossing in plaats van een datawarehouse. Het datawarehouse maakt de BI-oplossing mogelijk (of is zelfs een onderdeel daarvan). Je hoeft bovendien niet alle systemen zelf te bouwen, wanneer je kiest voor een datawarehouse.

[Croga]

riZZy schreef op dinsdag 02 mei 2006 @ 12:43:
Of ken jij systemen die dat in 1 keer kunnen? (In feite gebruik je natuurlijk wel weer een BI-tool om de data in de juiste vorm te krijgen, maar dat ter zijde.)

SAP BW is een datawarehouse wat meteen business intelligence systeem is.

Aangezien mijn enige ervaring op dit vlak binnen SAP BW zit is het voor mij moeilijk deze twee los van elkaar te zien. De gegevens in het datawarehouse van SAP BW zijn nagenoeg nutteloos als ze niet met de BI tools aangeroepen worden. Een SQL query schrijven over een dimensionele database lijkt mij persoonlijk een haast wel criminele aangelegenheid De tabellen waar je rekening mee moet houden zijn zo enorm talrijk en ondoorzichtig.....

Aan de andere kant is het in principe wel het ultieme relationele model. De hoofd-tabel bevat nagenoeg alleen maar relationele informatie richting de dimensies, die ook nagenoeg alleen relationele informatie bevatten richting de attributen. Zowel object-georienteerd gesproken als vanuit transactioneel standpunt is het dus de meest zuivere vorm die je kunt krijgen. Maar het model is geoptimaliseerd voor analytische doeleinden en veel minder voor gegevens opslag.

[Vozze]

Als je echt wat meer wilt weten van dimensioneel modelleren, raad ik je aan om "The Datawarehouse Toolkit" van Ralph Kimball te lezen. Het is af toe wat droge stof, maar helpt je wel om een solide model te bouwen.

Ik begrijp dus dat het datawarehouse (DWH) door een externe partij gebouwd gaat worden? Welke rol krijg jij na het bouwtraject? Word je verantwoordelijk voor de rapportage?
Als het DWH door die partij goed neer wordt gezet, scheelt dit jou een hoop werk. Het laden van het DWH zal automatisch gaan en waarschijnlijk zal dit ondere andere met behulp van de huidige scripts gaan gebeuren. Wanneer het DWH er eenmaal staat, dan kan een rapportbouwer een aantal objecten bij elkaar slepen en op die manier een rapport bouwen. Denk hierbij aan de omzet per maand, vergeleken met vorig jaar, afgezet tegen budget etc.

Croga schreef op dinsdag 02 mei 2006 @ 11:44:
Wat ik mij in deze vooral afvraag:

Waarom wordt er gekozen voor een "Datawarehouse" oplossing terwijl je in feite een Business Intelligence systeem nodig hebt (als ik naar de beschrijvingen kijk).

Door te kiezen voor een datawarehouse zullen alle toepassingen zelf gebouwd moeten worden. Het probleem hierbij is, zoals jij al beschrijft, dat je alles op laag niveau zult moeten doen. Zelf toepassingen bouwen met behulp van SQL/PLSQL op een dimensionele database is haast niet te doen.

Welke toepassingen moeten gebouwd worden dan? Wanneer het datawarehouse (DWH) eenmaal staat (of met behulp van PL/SQL of met een ETL-tool gemaakt), dan zijn er een aantal rapportagetools die als het ware de SQL afvuren op het DWH, door het kiezen van een aantal objecten die een manager (of ieder ander persoon) graag in een rapport wenst te zien.
De TS geeft zelf Oracle Discoverer als voorbeeld, maar er zijn er nog andere, zoals: BusinessObjects, Cognos en MicroStrategy. Allemaal wel wat prijziger dan Discoverer, maar deze toepassingen bestaan gewoon en hoeven niet geschreven te worden.

Offtopic: over welke partij hebben we het eigenlijk? Ben daar samen met riZZy wel benieuwd naar.

[ Voor 89% gewijzigd door Vozze op 02-05-2006 14:21 ]

[riZZy]

Croga schreef op dinsdag 02 mei 2006 @ 13:19:
[...]
Een SQL query schrijven over een dimensionele database lijkt mij persoonlijk een haast wel criminele aangelegenheid De tabellen waar je rekening mee moet houden zijn zo enorm talrijk en ondoorzichtig.....

oei, dat doe ik zo'n beetje de halve week.
Dan is het in het begin wel even leren waar alles staat ja. (hebben ongeveer 100 tabellen en een tiental sterren)

SAP BW biedt dan een geintergreerd systeem, zoals maar weinig tools dat bieden. Meestal is er een verschillende tool voor het vullen van het datawarehouse en een andere voor de reporting/managementinformatiekant. Echter ook SAP BW heeft gewoon een datwarehouse, wat in feitte al een onderdeel is van je BI-inrichting.

Lekker leesbare stof over dimensioneel modelleren is: "De 6 Artikelen van Harm van der Lek"

[Mike Jarod]

Was ik weer

Vandaag dus dat gesprek gehad met die consultant. Zoals te verwachten viel, was het gewoon een geval van miscommunicatie aan beide kanten. Ik dacht te moeilijk over het data warehouse systeem, en de consultants wisten niet wat wij allemaal deden.

Ik was bang dat alles stermodellen etc zou gaan worden. Dit is niet het geval. In de toekomst gaan we gezamelijk kijken welke data er in een ster gemodelleerd kan gaan worden om performance etc te verbeteren. Dit zal een klein deel worden. De rest blijven gewoon relationele modellen direct uit de bronsystemen.

De consultant gaf toe dat er niet goed genoeg gekeken was naar de behoeften van de eindgebruiker. Ze kregen het idee dat we 'domme' eindgebruikers waren, en dat het juist heel handig zou zijn om data op zo'n manier te modelleren zodat je minimale query kennis nodig hebt. Dit hadden ze dus verkeerd, ons niveau is duidelijk een stuk hoger, en daar gaan ze rekening mee houden. Ook gaf hij toe dat we met onze werkzaamheden gewoon (beperkte) schrijfruimte moeten krijgen op het data warehouse systeem, deels omdat onze queries zo heftig zijn (we hebben bv queries die al getuned zijn maar die 14 uur draaien oid), en deels om ad-hoc werkzaamheden uit te kunnen voeren.

Waar ik dan wel van baal is dat we dus in dat nieuwe systeem, het oude systeem over gaan zetten. Positieve kant is dat we goed kunnen kijken wat we wel en niet nodig hebben, en sommige dingen kunnen optimaliseren door sterren etc. Nadeel is dat dit (IMO) onnodig geld kost, hier gaan we intern nog wat mensen op aanspreken.

[D4Skunk]

Croga schreef op dinsdag 02 mei 2006 @ 13:19:
[...]


Een SQL query schrijven over een dimensionele database lijkt mij persoonlijk een haast wel criminele aangelegenheid De tabellen waar je rekening mee moet houden zijn zo enorm talrijk en ondoorzichtig.....

[...]

offtopic:
Zo'n queries optimaliseren terwijl je geen rechten hebt om een explain plan te laten lopen, kan ook wel een helse taak zijn

Mike Jarod schreef op donderdag 04 mei 2006 @ 19:55:
Was ik weer

Vandaag dus dat gesprek gehad met die consultant. Zoals te verwachten viel, was het gewoon een geval van miscommunicatie aan beide kanten. Ik dacht te moeilijk over het data warehouse systeem, en de consultants wisten niet wat wij allemaal deden.

Klassiek probleem bij consultancy; de consultant heeft bv bij een vorige klant eens Cognos gebruikt, en gaat die dan bij de volgende klant ook proberen aan te raden, terwijl dit (nog) niet nodig is.
Als je het probleem nog niet kent, is het nog wat te vroeg om al met oplossingen aan te komen....

Ik was bang dat alles stermodellen etc zou gaan worden. Dit is niet het geval. In de toekomst gaan we gezamelijk kijken welke data er in een ster gemodelleerd kan gaan worden om performance etc te verbeteren. Dit zal een klein deel worden. De rest blijven gewoon relationele modellen direct uit de bronsystemen.

Lijkt me al iets beter...

De consultant gaf toe dat er niet goed genoeg gekeken was naar de behoeften van de eindgebruiker. Ze kregen het idee dat we 'domme' eindgebruikers waren, en dat het juist heel handig zou zijn om data op zo'n manier te modelleren zodat je minimale query kennis nodig hebt. Dit hadden ze dus verkeerd, ons niveau is duidelijk een stuk hoger, en daar gaan ze rekening mee houden. Ook gaf hij toe dat we met onze werkzaamheden gewoon (beperkte) schrijfruimte moeten krijgen op het data warehouse systeem, deels omdat onze queries zo heftig zijn (we hebben bv queries die al getuned zijn maar die 14 uur draaien oid), en deels om ad-hoc werkzaamheden uit te kunnen voeren.

Dito hierboven; bizar dat men al de oplossing kent als het probleem nog niet gedefiniëerd is...
Als je queries hebt die 14 uur draaien, kan je imho beter eens een dba vragen. Bij een klant van mij worden queries uitgevoerd met ettelijke gigs aan data, en heb ik dmv wat optimalisaties (2 uurtjes werk) bv 1 reeks van rapportqueries herleid van 4 u naar 30 secs....

Waar ik dan wel van baal is dat we dus in dat nieuwe systeem, het oude systeem over gaan zetten. Positieve kant is dat we goed kunnen kijken wat we wel en niet nodig hebben, en sommige dingen kunnen optimaliseren door sterren etc. Nadeel is dat dit (IMO) onnodig geld kost, hier gaan we intern nog wat mensen op aanspreken.

Het lijkt me dat de scope en objectives jou en/of het management niet geheel duidelijk zijn. Hebben jullie een gedetailleerd projectplan ? Ik heb atm de indruk dat de consultant z'n opdracht is : alles wat optimaliseren.
Stel een duidelijk projectplan op, met targets en planningen, zo blijf je binnen je budget, en weten beide partijen wat ze van elkaar mogen verwachten, en kan er zich ook geen probleem vormen rond facturaties etc....