Anchor Modeling intrigeert mij al een tijdje. Zo’n anderhalf jaar geleden kreeg ik hiervan voor het eerst een artikel in DB/M, geschreven door Ronald Kunenborg, onder ogen. Wat mij meteen aansprak was de elegantie van de modelleringmethode. Verder viel op dat het in een bepaald opzicht nogal extreem was. Ik zal niet ontkennen dat juist dat extreme ook wel stiekem een zekere aantrekkingskracht op mij uitoefende. Anchor Modeling is namelijk extreem in die zin dat een data warehouse vormgegeven volgens deze methodiek een enorme hoeveelheid tabellen kent. Juist op dat moment had ik net de keuze gemaakt voor de Data Vault aanpak voor het Boven-wijs project dat toen net van start was gegaan.
Ook bij een Data Vault model was het al even wennen gezien de grote hoeveelheid tabellen die er bij komen kijken. Gegeven een logisch datamodel met twee entiteiten met ieder vijf attributen en tussen de entiteiten een één op veel relatie, dan resulteert dit in een fysiek datamodel in de derde normaalvorm van slechts twee tabellen, waarvan er een middels een foreign key refereert naar de ander.
Volgens de Data Vault methode komen we al snel op vijf tabellen: voor iedere entiteit een Hub, tussen de twee Hubs een Link en voor iedere Hub minimaal één Satellite om de attributen in onder te brengen. Voor een beknopte uitleg van DV zie een van mijn eerdere posts.
Modelleren we echter volgens de Anchor Modeling methodiek, dan komen we op een fysiek datamodel van maarliefst 13 tabellen!: voor iedere entiteit een Anchor, tussen de twee Anchors een Tie en voor ieder attribuut een Attribute tabel. In onderstaande afbeelding is deze situatie gevisualiseerd: de rode blokken zijn Anchors, de cirkels zijn Attributes, de grijze ruit is een Tie.
Anchor Modeling kent vier typen objecten:
Anchor
Deze representeert het bestaan van een entiteit. Het bestaat enkel uit een surrogaatsleutel. Het Anchor is vergelijkbaar met de Hub in Data Vault. Echter in een Anchor tabel wordt geen unieke business key opgeslagen zoals dit wel in de Hub gebeurt.
Knot
Deze representeert een eindige set vaste waarden. Het bestaat uit een surrogaatsleutel en een veld waarin de ermee geassocieerde waarde wordt opgeslagen. Bijvoorbeeld een knot voor de eigenschap geslacht {(1, Man), (2, Vrouw)} is goed denkbaar. De Knot is de tegenhanger van van de Reference table in Data Vault.
Attribute
Deze representeert een eigenschap van een Anchor. Deze bevat een veld met daarin de waarde van de eigenschap OF een referentie naar een specifiek record in een Knot tabel.
Tie
Deze representeert een relatie tussen twee of meer Anchors en eventueel een Knot. Een Tie kan geen Attributes hebben. Het is dus de tegenhanger van een Link zonder Satellites in Data Vault. Als van een relatie eigenschappen moeten worden bewaard, moet de relatie worden gemodelleerd als een Anchor, waar dan Attributes aan gekoppeld kunnen worden.
Voor alle objecttypen geldt dat er een veld in opgenomen mag worden met een verwijzing naar metadata.
De objecttypen Attribute en Tie kunnen static of historized zijn. In het eerste geval wordt er geen historie bewaard van het bewuste object, in het tweede geval wel. Dit gaat met behulp van een extra datum veld (ValidFrom).
Dit is de methode in een notendop.
Het apart onderbrengen van een attribuut in zijn eigen tabel zoals de Anchor Modeling methode predikt, kan zorgen voor onoverzichtelijkheid. Een beetje serieus data warehouse gaat al snel over tientallen entiteiten met in totaal honderden attributen. Wanneer we een dergelijk model handmatig moeten onderhouden zien we al snel door de bomen het bos niet meer. Bovendien rijst de vraag, of een dergelijk data warehouse fatsoenlijk te bevragen is, als er een substantiële hoeveelheid data in zit. Om informatie over een bepaalde entiteit op te halen, moeten vele joins gelegd worden tussen het corresponderende Anchor en alle ermee verbonden Attributes. Kortom we hebben standaard te maken met complexe queries en mogelijk trage queries. Dit alles in overweging nemend, heb ik destijds, ondanks dat ik de modeleerwijze heel elegant vind, besloten het maar op Data Vault te houden.
Echter, recentelijk heb ik een open gast college bijgewoond bij de HAN waar mede-bedenker Lars Rönnbäck een lezing hield over Anchor Modeling. Een aantal van mijn twijfels heeft hij hier (deels) weggenomen:
- Hij gaf aan dat Anchor Modeling nog klein is. Maar hoe dan ook zijn er enkele toepassingen van deze methodiek in gebruik in Zweden, o.a. in de financiële sector (niet de minst kritische sector). Het werkt dus echt in de praktijk, naar het schijnt naar tevredenheid. Prettig om te weten.
- Er werd een artikel aan de toehoorders uitgereikt waarin onder andere een experiment stond beschreven waaruit grofweg afgeleid kan worden dat naarmate het data warehouse meer data bevat, de query performance onder diverse condities, relatief beter wordt, vergeleken met de situatie waarin alle data in enkele tabel is opgeslagen. Dit geldt met name naarmate er meer attributen in het spel zijn. Dit experiment is reproduceerbaar en kan hier worden gedownload. Wat meer experimenten zijn wel gewenst. Zo zou het bijvoorbeeld heel interessant zijn, te zien hoe snel het laden van een Anchor database verloopt, vergeleken met bijvoorbeeld het laden van een enkele tabel of een Data Vault.
- Op www.anchormodeling.com is een mooi vormgegeven en prettig werkend online Anchor Modeling tool ontwikkeld waarmee op grafische wijze een Anchor Model kan worden gemaakt. Er is goed nagedacht over het hanteerbaar maken van de grote hoeveelheid symbolen die je met elkaar moet verbinden bij een datamodel van enige omvang. De DDL om het gemaakte model vervolgens om te zetten in een database wordt automatisch gegenereerd. Jammer genoeg wordt momenteel alleen SQL Server ondersteund, maar er wordt gewerkt aan het ondersteunen van andere databases zoals Oracle. Op deze site staan overigens diverse korte instructiefilmpjes waarin je snel wegwijs met de modeling tool. Het tool is overigens Open Source.
- Naast DDL voor het definiëren van tabellen worden er ook diverse hulpobjecten (views, functions) gegenereerd die het uitvragen van het data warehouse aanzienlijk makkelijker maken. Voor ieder Anchor in het model is er bijvoorbeeld een zogenaamde ‘latest’ view waarmee je een Anchor en alle bijbehorende Attributes kunt opvragen zoals deze momenteel gelden. Ook is er een point-in-time functie waarmee je een Anchor met zijn Attributes kunt opvragen zoals deze golden op een bepaald moment in de tijd.
- Verschillende databases maken gebruik van het zogenaamde ‘table elimination’ principe. Dit principe zorgt ervoor dat als een view bestaat uit meerdere aan elkaar gejoinde tabellen en er wordt informatie opgevraagd uit slechts enkele van deze tabellen, dan worden de voor de betreffende vraag irrelevante tabellen geëlimineerd uit het queryplan. Als bijvoorbeeld op de bovengenoemde ‘latest’ view behorend bij een Anchor met vijf Attributes een query wordt uitgevoerd waarbij slechts een Attribute wordt opgevraagd, worden de vier overige Attributes en de Anchor table buiten het query plan gehouden. Dit is voor een Anchor database zeer belangrijk mechanisme, gezien de performance winst die dit oplevert.
- Er is een naming convention die helpt orde te scheppen in de vele objecten die voorkomen in een Anchor Model.
Kortweg kunnen we concluderen dat er veel mogelijk is (wat deels al gedaan is) om een Anchor Modeling tot een werkbare modelleringtechniek te maken. Verder wordt er gewerkt door de bedenkers van de techniek aan verdere onderbouwing door middel van experimenten. Ik denk dat dit alles ook hard nodig is, om de drempel om deze techniek toe te passen, te verlagen. Anchor Modeling is een techniek die niet zomaar afgeserveerd kan worden als een extreme rariteit. Daarvoor is er te goed over nagedacht. Het is het dan ook waard om er eens in te duiken.