In een HSA wordt het bronsysteem als het ware gevolgd. Iedere nacht wordt de HSA bijgewerkt en bevat een kopie van de bron. Het enige verschil met de bron is dat wij alle mutaties vasthouden in een aparte tabel. Hierdoor kunnen wij alle mutaties terugvinden die ooit zijn gedaan op de brontabel. Deze mutaties worden in een aparte tabel opgeslagen, de zogenaamde HIS tabel. De laatste stand van zaken (1:1 kopie van de bron) wordt bewaard in een registratietabel, de REG tabel. De HIS tabel is voorzien van een tijdstrook.
{module Easy Adsense Content}
Je zult je afvragen wat het grote voordeel hiervan is. Waarom zou je alle mutaties van een bronsysteem willen bewaren? Het antwoord hierop is eenvoudig. Je kunt nooit voorspellen welke informatievragen er in de toekomst naar voren komen. Wanneer je namelijk je stermodel maakt moet je direct beslissen voor welke velden je wel/geen historie wilt bewaren (Type I / Type II ). Door een HSA te gebruiken kun je deze keuze later eenvoudig veranderen, je kunt je dimensies en feiten namelijk geheel met terugwerkende kracht opbouwen omdat je de historie nog hebt. En wat te doen als er een TYPE II veld bijkomt in de dimensie? Deze kun je nu met terugwerkende kracht en met volledige historie opbouwen!
Kortom, de voordelen zijn groot. Nog een voordeel is dat de ETL die de HSA gaat vullen gegenereerd kan worden, het truukje dat je doet is immers iedere keer hetzelfde! Op dit moment hebben wij scripts die speciaal voor SQL-server de HSA genereert en vult. Wij kunnen dus snel nieuwe bronnen aansluiten in onze HSA. Het leuke hieraan is dat wij alvast een bronsysteem kunnen gaan volgen die nog niet op het Datawarehouse is aangesloten zodat wij alvast historie opbouwen.
{module Easy Adsense Content}