0 comments
Various 
Deze week is Lars Rönnbäck in Nederland in het kader van een themaweek over Anchor Modeling, georganiseerd door de Nederlandse Data Vault gebruikersgroep. Vanmiddag gaf hij een gastcollege over ‘zijn’ modelleringstechniek op de HAN in Arnhem. In dit college leerden we als deelnemer de techniek kennen en natuurlijk vooral de voordelen ervan. Overigens is de échte grondlegger van Anchor Modeling een collega van Lars: Olle Regardt. Hij maakte in 2003 zijn eerste datawarehouse volgens de technieken die later zijn doorontwikkeld tot Anchor Modeling zoals het vandaag de dag wordt gepresenteerd.
Anchor Modeling is, net als de Data Vault methode, ontstaan vanuit de behoefte beter om te kunnen gaan met veranderingen. Veel ‘traditionele’ datawarehouses, halen net een levensduur van vijf jaar, voordat besloten wordt ze maar te herbouwen. En in de tussentijd is er vaak al heel wat verbouwd aan het datawarehouse. Wat maakt Anchor Modeling nu uniek en is het zoveel anders dan bijv. Data Vault?
Anchor Modeling combineert normalisatie en emulatie. Normalisatie tot de zesde normaalvorm, wat praktisch betekent dat iedere attribuut die je modelleert in een aparte tabel belandt. Emulatie omdat men de eigenschappen van een temporal database emuleert. Een temporal database houdt simpel gezegd automatisch historie bij. Hoewel er al wel temporal databases op de markt zijn, is er nog geen implementatie die volledig temporal genoemd mag worden. Lars positioneert Anchor Modeling aan de business kant, in het domein van een bedrijf en haar processen, waar Data Vault veel meer aan de data kant en Kimball’s dimensional modeling veel meer aan de gebruikerskant zit. Je modelleert dus de business in zesde normaalvorm waarbij je vier soorten objecten onderscheidt: anchors (de entiteiten), attributes, knots (codetabellen) en ties (relaties tussen anchors). Voor alle objecten is een naamgevingsconventie gedefinieerd. Bij Anchor Modeling hoort ook een eigen tekentechniek gebaseerd op ER met extensies.
Natuurlijk is de eerste vraag die rijst bij het zien van een Anchor Model als hierboven: hoe ga je dat ooit queriën? En welke performance gaat dat geven? Ook hier heeft Anchor Modeling een antwoord op. Om het queriën makkelijker te maken, worden er een viertal perspectives gedefinieerd die middels geparametriseerde views of table valued functions worden geïmplementeerd (het modeling tool genereert deze perspectives automatisch!). Deze vereenvoudigen het model tot iets wat gewoon derde normaalvorm lijkt. En dankzij moderne database features als table (of join) elimination, schijnt een Anchor Model database ook nog een snelle performance te geven. Kanttekening is wel dat er weinig échte grote Anchor Model database implementaties zijn. De grootste die Lars noemt, is 1 TB groot. Ook geeft de zesde normaalvorm juist voordelen tijdens het queriën, met name wanneer je filtert op een attribuutwaarde.
De werkelijke kracht van Anchor Modeling schuilt in de enrome flexibiliteit die het biedt voor wijzigingen in het schema. Wijzigingen zijn per definitie uitbreidingen op het model (op enkele uitzonderingen daar gelaten, bijv. bij fouten). Ga maar na: iedere attribuut die je toe wilt voegen, wordt simpelweg een nieuwe tabel met foreign keys naar de anchor tabel waar de attribuut bij hoort. Technisch gezien zijn alle wijzigingen dan ook CREATE TABLE statements en in principe geen ALTER TABLE statements. Je zou zelfs het recht tot updaten van een database kunnen weigeren aan ontwikkelaars.
Om een Anchor Model te modelleren met de bijbehorende statements om de fysieke database te maken, heeft Lars en zijn team een modelleertool gemaakt. Geheel open source en als cloudoplossing beschikbaar via de Anchor Modeling website. Hou er wel rekening mee dat het tool alleen in een HTML5 browser werkt, waarbij ondersteuning voor IE9 nog ontbreekt. Chrome is bijvoorbeeld een goed werkend alternatief. De tool ziet er erg indrukwekkend uit, ware het niet vanwege de niet belangrijke, maar wel o zo fraaie ‘interactive, force-directed layout engine’. Open maar een voorbeeld model en verplaats een anchor en je weet wat ik bedoel. De tool genereert niet alleen alle create scripts voor de tabellen, maar ook de eerder genoemde perspectives die het queriën vereenvoudigen.
Na een verkoelend drankje (en dat hadden we wel nodig in de op deze tropische dag snikhete en benauwde aula van de HAN) probeerde Martijn Evers, voorzitter van de Nederlandse Data Vault gebruikersgroep, de strijd tussen Data Vault en Anchor Modeling te beslechten. Ook hij benadrukte nog eens een belangrijk verschil tussen de beide methodieken: bij Data Vault staat de data centraal, bij Anchor Modeling is het model heilig. In eerste instantie lijkt daardoor het ETL proces om een Anchor Model database te laden moeilijker te implementeren dan voor een Data Vault. Voor de laatste kun je dat juist automatisch genereren, maar dat is dan alleen het geval voor de Raw of Source Data Vault. Verder ‘downstream’ loop je ook bij de Business Data Vault tegen de zelfde problematiek aan. Iets wat Lars ook in de afsluitende panel discussie, waarin oa. ook Data Vault guru Ronald Damhof, Tom Breur en Harm van der Lek plaats namen, nog eens aanstipte. Nog een voordeel van Anchor Modeling is de manier waarop met metadata omgegaan kan worden. Omdat iedere attribuut een eigen tabel heeft, is het heel eenvoudig per attribuut metadata op te nemen.
Na deze leerzame middag, weet ik véél meer van Anchor Modeling af dan tot nu toe. Ik vind het een interessante modelleertechniek. Is het beter dan Data Vault? Ach, zoals gebruikelijk zal dat weer afhangen van een aantal factoren. De oproep van Ronald Damhof om eens een vergelijking te maken in een echte case, lijkt mij dan ook een hele zinvolle!
Wil je meer weten over Anchor Modeling, neem dan eens een kijkje op de website www.anchormodeling.com.