Alles tussen DV en de datamarts klakkeloos in de grote T stoppen lijkt mij geen goed idee, dat kan nl wel erg groot en oncontroleerbaar worden. Ik zie nog steeds emplooi voor additionele DWH benaderingen om zo die grote T die tussen de DV en de data marts ontstaat te overbruggen/beheersen. Ik denk bijvoorbeeld aan een ‘Bussiness’ (model) gedreven DWH in DV stijl (zoals oa. BIready dat doet) die gevoed wordt met de geschoonde data vanuit de DV. Of extra DV entiteiten die alleen geschoonde en geconformeerde gegevens bevatten/aangeven die dan eenvoudig naar de data marts geexproteerd kunnen worden.

Misschien moeten we Data Vault meer zien in het licht van evolutie van een HDS(Historical Data Stage) naar de IHDS(Integrated Historical Data Stage), en een business gedreven DV als de opvolger van het huidige datawarehouse.

Het hangt er vanaf hoe je de big T implementeert. Beheersbaarheid is zeker een issue; waar in het overall proces je ze ook onderbrengt, het aantal business rules dat toegepast moet worden, en de complexiteit ervan, blijft gelijk. Je big T-implementatie moet daar dus tegenkunnen.

Bij mijn huidige opdrachtgever hebben we de grote T geformaliseerd door tussen EDW (de DV) en datamart een “EDW-plus” in te richten, waarin we de resultaten van de toepassing van de business rules bewaren. De grote T is dus niet alleen een stap in het proces, maar ook een aparte omgeving binnen het dwh geworden.
In het EDW-plus komen enkele van de benaderingen terug die jij ook schetst. Dus: extra DV-entiteiten voor geïntegreerde/geconformeerde gegevens, extra satellites voor afgeleide gegevens, hermodellering richting specifieke business-informatiebehoeften e.d.
De slag om tot een dimensioneel model (of welk ander formaat je kiest voor je datamart) te komen, is van daaruit inderdaad relatief eenvoudig.

Lidwine, bedankt voor je commentaar.

Ik zou bijna gaan concluderen dat om de grote T te implementeren hergebruik van de DV modelleertechniek voor een (gedeeltelijke) business (model) gedreven aanpak in feite een best practice (aan het worden) is .
Mits dit natuurlijk echt nodig is voor de datamarts.

Waar ik mij wel zorgen over maak is of je ook naar zo’n aanpak toe kan evolueren. Stel je begint met een puur DV. Waarna er meestal al snel een aantal extra hubs, links en sattelieten bij komen om de geschoonde en geconformeerde data weer te geven die nodig is in je datamarts. Wanneer en hoe ga je dat op een gegeven moment afsplitsen in een ‘eigen’ business DV? Of moet je met de planning al rekening gaan houden met een business DV, en is het dus een vast onderdeel van je architectuur. Dit laatste maakt een ‘complete’ DV(DV+business DV) architectuur nl wel minder flexibel.

Minder flexibel…dat hoeft niet. Zoals wij het nu inrichten, definiëren we het EDW+ wel van meet af aan als onderdeel van de architectuur; maar het plus-gedeelte is een optionele tussenstap, niet verplicht - als er geen bewerkingen op de gegevens uitgevoerd hoeven worden, hoeven ze ook niet in het EDW+ gedupliceerd te worden.
De datamarts kunnen dus opgebouwd worden op basis van bewerkte/geschoonde/geïntegreerde data uit het EDW+, maar ook op basis van “ruwe” data rechtstreeks uit het EDW (of een combinatie van beide); daarmee creëer je juist extra flexibiliteit voor je processing, terwijl de onderverdeling overzichtelijk blijft.

(Feitelijk is er dus in onze architectuur geen aparte “business DV”-component aan te wijzen; al zou je EDW en EDW+ samen als een conceptuele business DV kunnen beschouwen.)

Bedankt voor je uitwerking,

Ik maak hieruit op dat jou EDW en EDW+ alleen conceptueel gescheiden zijn, maar logisch (en mischien wel fysiek) een geheel vormen.

Nee, ze zijn ook logisch gescheiden. Zo maken we bijv. aparte logische datamodellen en logische dataflow ontwerpen voor het EDW en EDW+. Momenteel vormen ze dus alleen fysiek één geheel.

Naarmate de DV breder toegepast gaat worden, zullen er langzamerhand wel best practices voor de inrichting van de big T ontstaan; op dit moment is er natuurlijk nog weinig uitgekristalliseerd. Wat zijn jouw ervaringen hiermee?

Jou oplossing is dus een soort duale oplossing waarbij er 2 DV zijn op 2 niveaus(ruwe data en geschoonde data) die allebei als bron voor de datamarts dienen.

Mijn eigen (niet DV) ervaring is dat de grote T voor veel organisaties ook het grote struikelblok is. Het beheersen en reduceren ervan is vaak een belangrijke succesfactor voor een duurzaam DWH. Een mismacth tussen deze T en de organsiatie levert mijns inziens regelmatig problemen op, zekrer op de lange termijn.

Binnen de DV aanpak zelf zie op dit moment 2 (uitersten) van aanpakken om de grote T klein te krijgen:

Als een zeer systematische aanpak zou de neiging hebben om een tweelaags DV te maken waarbij de onderste laag met brondata (standaard bottom up DV) met evt analyses van die brondata in zijn geheel omgezet wordt naar een bovenste DV die volledig topdown (business/analyse model) gedreven is. Deze toplaag stuurt dan (de meeste) datamarts aan.
Hiermee hak je de grote T effectief in twee delen. Dit vergt echter wel een volledig systematische DV naar DV transformatie van *alle* gegevens. Ook degradeer ik nu de oorspronkelijke DV naar meer en meer een ‘historical staging’ rol. alleen de bovenste DV is voor de gemiddelde gebruiker toegankelijk (de onderste is voor auditors/analisten ed).
Overigens kan ik me voorstellen dat bij zeer grote en/of complexe organisaties dat er zelfs meerdere business DV’s zijn die allen gebaseerd zijn op één DV met brondata.

Een heel pragmatische aanpak is om informatie over data- kwaliteit en transformatie volledig in het DV op te slaan, en een alleen een (logische) toegangslaag te maken waarmee je de een business view krijgt van je onderliggende DV data.

Natuurlijk kun je eindeloos variëren tussen deze twee strategieën.

Ik ben niet van mening dat de grote T zoveel mogenlijk buiten de DV gehouden wordt, dwz opweg naar de datamarts, aangezien die transformaties daar veel minder systematisch, herbruikbaar en controleerbaar zijn. Datamarts moeten in mijn ogen zo goed mogenlijk centraal gestuurd worden. Dat impliceert een overzichtelijke T tussen EDW en Datamrts

De uitdaging is naar mijn idee om het Centrale Data Warehouse stabiel qua structuur te houden en om redundantie in functionaliteit (ETL) te voorkomen
De stabiliteit van het CDW kan de Data Vault-methode worden geborgd door de logische business keys als basis te nemen voor het model. Hiermee bereik je dat het model van de CDW gebaseerd wordt op de logische structuur van de business die veel stabieler is dan de technische structuur van de bronsystemen. Een lastig punt daarbij is dat noch de organisatie noch het bronsysteem zorgvuldig omgaat met het definiëren van business keys.
Een uitdaging van de modelleurs van het CDW om dit vanuit de business boven tafel te krijgen!

Tussen bron en CDW krijg je zo een transformatieslag tussen bron en bedrijfsmodel.
In feite gaat het meer om een mapping dan een transformatie.
Elke sleutel en attribuut in het CDW is terug te voeren tot een gegeven in de bron. Gegevens die redundant in bronnen voorkomen (zoals de klantnaam) hoef je echter in principe maar één keer op te nemen als ze dezelfde betekenis hebben.

Omdat je zo in het CDW verschillende bronnen in een gemeenschappelijke structuur hebt ondergebracht die een afspiegeling is van het businessmodel wordt de transformatie tussen CDW en datamarts eenvoudiger.

Hiermee is de redundantie niet of slechts deels opgelost, In het CDW hebben we immers de basisgegevens (one statement of the facts) en niet de afgeleide gegevens (user- or department specific versions of the truth). Idealiter zou je dit via een business rules engine willen regelen; zover zijn we echter nog niet. Vooralsnog lijkt een laag na het CDW met afgeleide gegevens een geschikte oplossing.

Who wants to hear something refreshing? Easy is as easy does is what I always say. So I found an easy way to make money. This thing I found is actually some software. The fact is, that this software is 100% legal, “white hat” and ethical, that even giant enterprises use it. The software needs very little babysitting so it’s basically set it up and forget it. Some people are tempted to exploit this software and use it for unethical web promotion but the owner is asking that everyone who is lucky enough to get it, please try to respect the laws of the internet. It really is as simple as downloading the software and then pushing a button. Basically what it does is bring a stream of free visitors to any website. You might be tempted to try to disect this software in order to ’see the magic’ but why bother? All you really need to know is that you can download it (if the link hasn’t been taken down yet) and then push a button and watch the magic. Test it out -> http://tinyurl.com/pbcsites

I think this website has very excellent written content content.

When you need cash now, but payday is still too far away, apply for loans online can be the answer to your problems.

We are not a payday advance lender. Simply fill out the short application and we will identify lenders that can provide you with a short term cash loan. We will attempt to match you with a lender most likely to provide you the cash you need

If you are matched with a lender, the lender will contact you to complete the process, review the terms of your loan and discuss repayment adn extension options. The money will be electronically deposited into your bank account. When the loan is due , you cash advance fees are automatically deducted from you bank account by apply for loans online. http://www.applyforloansonline.us/

I like this site so a lot, saved to favorites .