Bij de kreet Data Vault wordt al vrij snel gedacht aan data warehousing. Dit is echter niet het enige domein waarvoor deze modelleringtechniek/architectuur nuttig is. In deze post wil ik eens aandacht besteden aan de toepasbaarheid van Data Vault in een datamigratiestraat. Een typisch data migratie traject houdt in ieder geval in dat:

1. data van een of meer brondatabases naar een nieuwe doeldatabase wordt overgezet. In het geval van meerdere bronnen is vaak data-integratie nodig.
2. data uit het bronsysteem moet waar nodig worden opgeschoond. Als het bewaken van datakwaliteit in het bronsysteem gebrekkig is, levert dit eigenlijk gegarandeerd vervuiling op. Een ander bekend fenomeen is het gegeven dat bepaalde velden in bronsystemen zijn gebruikt voor andere doeleinden dan waarvoor ze oorspronkelijk bedoeld zijn.
3. entiteiten in de bronsystemen moeten worden getransformeerd naar entiteiten in de doeldatabase. Dit is soms kinderlijk eenvoudig maar in andere gevallen is dit een pittige opgave.
4. er doorgaans meerdere iteraties nodig zijn om tot uiteindelijk resultaat te komen. Vaak moet er zoveel worden verspijkerd aan de oude data alvorens deze naar het doelsysteem kan worden overgezet dat dit onmogelijk in een enkele conversieslag kan worden gedaan. Voortschrijdend inzicht is eerder regel dan uitzondering. Er vindt dan een proefmigratie plaats, die vervolgens wordt geëvalueerd door mensen die inhoudelijk op de hoogte zijn van de over te zetten data. De uitkomsten van de evaluatie worden vervolgens verwerkt in een nieuwe proefmigratie, etc. Ook kan deze evaluatie leiden tot het verbeteren van de datakwaliteit in de bronsystemen.

Belangrijk is dat iedere iteratie in het migratietraject herhaalbaar en traceerbaar is. De data in de bronsystemen is echter doorgaans in beweging tijdens dit traject. Al is het maar vanwege het verbeteren van datakwaliteit in de bronsystemen naar aanleiding van een proefmigratie. Om herhaalbaarheid van iedere iteratie te garanderen is het noodzakelijk dat er “foto’s” genomen worden van de bronsystemen. Voor dit doel kan per bronsysteem een Source Data Vault (sDV) worden aangelegd (of liever nog: genereren). De sDV bevat enkel de volledige (inhoudelijk) ongewijzigde data op verschillende peilmomenten in het betreffende bronsysteem.

Voor data-integratie en datatransformaties zijn soms vertaaltabellen nodig. Deze kunnen worden ondergebracht in een Helper Database. Als we streng in de leer zijn en we willen gaan voor 100% reproduceerbaarheid van iedere iteratie in het migratietraject dan zouden we ook van deze vertaalinformatie de historie moeten gaan bijhouden.

Niet iedere opschoonactie of transformatie is volledig te automatiseren. Menselijke tussenkomst is dan noodzakelijk. Onze migratie architectuur moet ruimte bieden voor handmatige ingrepen die niet plaats vinden in de bronsystemen maar ergens verderop in de migratiestraat. Om hier herhaalbaarheid te kunnen garanderen is het noodzakelijk dat het handmatig ingrijpen op gestructureerde wijze gebeurt. Dit kan door handmatige wijzigingen te zien als zijnde afkomstig uit een correctiesysteem dat we behandelen als bronsysteem. En net als voor alle andere bronsystemen wordt ook voor dit systeem een sDV aangelegd. Deze speciale sDV noem ik Correctie Data Vault (cDV). Hier wordt de historie van de correcties bewaard. Voor de duidelijkheid, het correctiesysteem is geen echt systeem, het is in feite een set correctiebestanden volgens een vast stramien. Dit kunnen bijvoorbeeld Excel bestanden zijn met in iedere rij een te vervangen data-item, gecombineerd met vervangende data. Of Excel bestanden met de sleutels van de entiteiten (of relaties) die niet meegaan in de migratie.  Om maar eens wat te noemen. Deze correctiebestanden worden ingelezen in de cDV.

De bouwstenen voor de migratie zijn dus sDV’s, de cDV en de Helper DB. Als we een proefconversie voorbereiden, zullen deze allereerst gevuld moeten worden. Alle gegevens in deze bouwstenen worden vervolgens op een bepaalde wijze opgeschoond, bewerkt en gecombineerd zodat nieuwe data ontstaat, die geschikt is om te importeren in het doelsysteem. De wijze waarop dit gebeurd, is sterk onderhevig aan voortschrijdende inzichten. Om 100% reproduceerbaarheid van deze stap te garanderen is het natuurlijk noodzakelijk om alle versiebeheer toe te passen op de gebruikte bewerkingen (programmacode dus). Daarnaast is het handig (maar niet strikt noodzakelijk) om de uitkomst van deze bewerkingen historisch op te slaan in een speciaal hiervoor bestemde Migratie Data Vault (mDV). Dit maakt het vergelijken van de uitkomsten van verschillende iteraties eenvoudiger. Ook kan hierin voor ieder data-item worden vastgelegd uit welke bewerking het precies afkomstig is. Dit is met name handig naarmate de betreffende bewerking complexer is. Daar waar het simpele bewerkingen betreft, zou eventueel kunnen worden volstaan met een view op de betreffende sDV.

De mDV vormt uiteindelijk de bron van waaruit het doelsysteem wordt geladen.

In onderstaande afbeelding is het hierboven beschrevene nog eens schematisch weergegeven. De letters A, B en C geven aan waar na iedere iteratie verbeteringen kunnen worden aangebracht.

schematische weergave van de datamigratiestraat

Data-integratie speelt een belangrijke rol bij datawarehousing en dataconversietrajecten. Eigenlijk heeft data-integratie veel weg van het maken van een grote legpuzzel. Verspreid in de tijd en over verschillende systemen, wordt allerhande informatie opgeslagen over entiteiten die voor een organisatie van belang zijn. Deze verspreide datafragmenten vormen de stukjes van de legpuzzel. De uitdaging voor de datawarehouse architect bestaat hier uit het bij elkaar zoeken van deze puzzelstukjes zodat een zo compleet mogelijk beeld ontstaat van deze entiteiten. Ook moet er vaak een zo goed mogelijke reconstructie gemaakt worden van hoe deze entiteiten zijn veranderd in de tijd. Dat dit lang niet altijd even eenvoudig is zal ik in dit artikel illustreren aan de hand van de data-integratieproblemen die ik bij de ontwikkeling van het product Boven-wijs ben tegengekomen.

Lees dit artikel verder op: XR Magazine http://j.mp/L4Ktc2

Pas sprak ik met een collega over de vraag waarom we nog steeds met zijn allen zitten te programmeren voor het realiseren van een informatiesysteem. Dit terwijl, als je er door je oogharen naar kijkt, er bij de meeste systemen steeds weer sprake van is dezelfde functionaliteit: het vast leggen van attributen van een entiteiten, het aan elkaar koppelen van entiteiten, of het opvragen van attributen van entiteiten in een of ander vorm. Toch zitten we steeds weer opnieuw en opnieuw te programmeren. Waarom genereren we het gros van de informatiesystemen niet gewoon in hun geheel? Een van de oorzaken is ongetwijfeld het feit dat informatiesystemen naast de grote gemene deler die ze hebben, ook hele specifieke eigenschappen hebben die precies op maat zijn voor een bepaald type gebruiker, situatie of platform. Deze specifieke functionaliteit is vaak lastig op generieke wijze te modeleren (bijvoorbeeld met een Model Driven Design tool) en vervolgens te genereren.  Eenmalig genereren en daarna handmatig uitbreiden lukt nog wel maar onderhoud plegen vanuit een functioneel model is al snel lastig. Kort gezegd: hoe meer je genereert, hoe meer flexibiliteit je inlevert.

De laatste jaren houd ik me voornamelijk bezig met data warehousing. Reuze interessante materie maar in het bouwproces zie ik wel veel herhaling van hetzelfde. Onwillekeurig dringt zich dan de weer vraag bij mij op: Waarom zit ik nog steeds te coderen? Gelukkig ben ik niet de enige met dit soort gedachten. Zo zijn de jongens (en meisjes?) van Qosqo al druk doende met de ontwikkeling van het product Quipu waarmee op basis van de structuur van bronbestanden Data Vaults gegenereerd kunnen worden met bijbehorende ETL. Ik denk echter dat codegeneratie binnen de data warehousing context nog veel breder kan worden toegepast. Ik zou een data warehouse architectuur willen kunnen ontwikkelen zonder perse toe te moeten werken naar een specifieke architectuur, en zonder me vast te pinnen op een bepaalde wijze van datamodellering. Ik zou graag op enkel op basis van een specifatie van de brondata en de requirements die gelden voor het data warehouse een volledig functionerende data warehouse architectuur willen kunnen genereren. Het maakt mij dan niet uit of het resultaat een Data Vault, Anchor Model, Historical Staging Area, Dimensional Model of een of andere mengvorm is. De te gebruiken modelleringstechniek is typisch iets dat ik buiten de requirements zou willen houden op basis waarvan de data warehouse architectuur gegenereerd gaat worden.

Ik zie het als volgt voor me: In een data warehouse architectuur zijn, functioneel gezien, een aantal lagen te onderscheiden:

• De inputlaag, oftewel de databronnen. Deze zijn een gegeven en moeten dus enkel goed beschreven worden bijvoorbeeld in de vorm van een logisch datamodel per bron en bepaalde eigenschappen van de bron (verderop geef enkele voorbeelden).
• De opslaglaag. Het hart van het data warehouse. Deze moet na analyse van de wensen van de gebruikers en de beschikbare databronnen worden vormgegeven. Modelleren kan in de vorm van logisch datamodel, uitgebreid met wat specifieke eigenschappen (zie verderop).
• De outputlaag. Hiermee interacteert de gebruiker. De outputlaag is typisch het product van een transformatieproces met als input de opslaglaag en een verzameling business rules. Doorgaans wordt data in deze laag ontsloten door bijvoorbeeld BI tools zoals een cube, een dashboard met KPI’s, standaardrapporten of een voor gebruikers begrijpelijke informatielaag (zoals de Universe van BO en de Catalog van Cognos).  Maar alles is hier in principe mogelijk. Er kan gebruik worden gemaakt van logische datamodellen om de basisdata te beschrijven die beschikbaar moeten zijn om de gewenste output mogelijk te maken.

Tussen de input- en de opslaglaag en de opslag- en de outputlaag  kunnen mappings gedefinieerd worden. Deze vormen dan de basis voor het genereren van de benodigde ETL code.

De input- en opslaglagen zijn mijns inziens volledig functioneel te modelleren op een min of meer declaratieve wijze. De outputlaag is de lastigste en kan mogelijk niet volledig gemodelleerd worden zonder te vervallen in een verkapt soort programmeren (waar we juist vanaf willen). Dit is vooral het geval als er zeer exotische (en die komen vaker voor dan ons lief is) business rules het spel zijn.

Delen van de data warehouse architectuur die declaratief te modeleren zijn

Toch is er ook iets te zeggen voor een eenvoudige basistaal waarin procedurele beschrijvingen van business rules kunnen worden vastgelegd. Een dergelijke taal biedt namelijk een platformonafhankelijke wijze waarop allerhande transformaties kunnen worden vastgelegd. Als we het vervolgens voor elkaar krijgen alle business rules met deze beperkte taal volledig te modelleren, kunnen we ook het onderhoud op de resulterende data warehouse architectuur via dit model blijven doen.  Anders blijft altijd de noodzaak bestaan om na het genereren van een nieuwe versie van de data warehouse architectuur handmatige correcties op de niet gegenereerde code uit te voeren.

Wat winnen we met een dergelijke benadering:

1. We kunnen alle benodige datastructuren genereren op basis van het model.
2. We kunnen alle benodigde ETL genereren op basis van het model.
3. Na wijzigingen in het model kunnen we ook de migratie van de oplossing gebaseerd op het oude model naar de oplossing gebaseerd op het  nieuwe model automatiseren.
4. We zijn niet afhankelijk van de onderliggende techniek omdat we het systeem volledig functioneel hebben beschreven. Komt er nieuwe technologie in beeld, dan kan m.b.v. de bijbehorende code generator het nieuwe systeem gegenereerd worden.

Voor ieder platform een codegenerator

Hieronder noem ik enkele zaken die zoal moeten worden vastgelegd in het functionele model van de BI oplossing. Het is uiteraard slechts een schot voor de boeg.

Informatie rondom de inputlaag

• Welk type databron betreft het?(csv, Excel sheets, xml, tabellen in een Oracle database, Webservice, …)
• Moet de brondata continue of per interval worden bijgeladen?
• Hebben we per laadbatch de beschikking over een volledige of onvolledige foto van het bronsysteem of  alleen de delta’s
• Mag de databron live worden benaderd voor BI doeleinden of niet?
• Per bronbestand: Welke entiteiten,relaties en attributen zijn er?
• Per entiteit: Hoe kan deze uniek te geïdentificeerd worden  (of is er misschien een foutkans, zie ook een vorige blogpost)?

Informatie rondom de data in de opslaglaag

• Welke entiteiten,relaties en attributen hebben we?
• Wat willen we wel en wat willen we niet historisch bewaren?
• Welk attribuut in de inputlaag, correspondeert met welk attribuut in de opslaglaag?

Informatie rondom de data in de outputlaag

• Per outputvorm (cube, dashboard etc): Welke KPI’s, meetwaarden en dimensies onderscheiden we?
• Welke entiteiten in de opslagstructuur hebben we nodig om een KPI, meetwaarde of dimensie te creeeren?
• Per outputvorm: Hoe vaak moet data ververst worden?

Ik realiseer me dat dit een wel zeer globale schets is, en dat er nog het nodige denkwerk verzet moet worden om tot een werkende oplossing te komen. Het is echter de moeite waard om dit verder uit te werken. Alleen zo kunnen we uiteindelijk zeggen: “The coding finally stops!” Ik wil iedere lezer dan ook aanmoedigen om hierop te schieten en zijn/haar ideeën met mij te delen. Wellicht zijn er al vergaande ontwikkelingen in deze richting waarvan ik geen weet heb. Ik verneem ze graag!

Uitbesteden is in. Tegenwoordig kunnen we op ICT gebied ongeveer alles uitbesteden waarvan we vinden dat we er zelf niet goed in zijn of geen energie in willen stoppen. In plaats van dure licenties en hardware aan te schaffen en te investeren in kennis om bepaalde software te kunnen beheren en ontwikkelen, kunnen we nu voor een maandbedrag gebruik maken van diensten en software van derden. Software-as-a-service (SAAS) dus. Door de keuze voor een SAAS oplossing worden we ontzorgt en kunnen we ons volledig richten op de dingen waar we wèl goed in zijn.

Een speciaal geval van SAAS is BI-as-a-service (BIAAS). De gebruiker hoeft zelf geen BI tools te installeren maar benadert deze doorgaans via de web browser. De BI tool bevindt zich vaak ergens in ‘the cloud’ en haalt haar data uit een data warehouse waarvan de ontwikkeling en het beheer ook is uitbesteed. Het data warehouse en de rompslomp eromheen, bevinden zich buiten het zicht van de afnemer van BIAAS. Het enige dat hij er eventueel merkt is dat er op gezette tijden data aan de operationele systemen die hij in gebruik heeft, wordt onttrokken om in het data warehouse te laden.

Dat BIAAS de nodige voordelen biedt moge duidelijk zijn. Toch zou een afnemer van BIAAS er goed aan doen om er voor waken dat de BI omgeving te veel een black box wordt. Voor zover het zuiver technische aangelegenheden betreft is het prima dat de afnemer hier niets van mee krijgt. Business intelligence is echter niet alleen een technische aangelegenheid. Het onderliggende data warehouse is niet los te koppelen van degene die het gebruikt. Het is niet inwisselbaar zoals software voor tekstverwerking, spreadsheets, projectplanning of e-mail. Managementinformatie is per definitie gebaseerd op data die heel bedrijfseigen is.

Het is belangrijk dat een bedrijf dat BIAAS afneemt in grote lijnen op de hoogte is van het data acquisitieproces die de BI toepassing van informatie voorziet. Men moet weten hoe deze data wordt schoongemaakt, getransformeerd en geïntegreerd tijdens het laden van het data warehouse. Welke data wordt beschouwd als ’onbruikbaar’ en wordt niet geladen. Hoe wordt data ‘verrijkt’ en ‘verbeterd’ en waarom? In dit soort zaken moet men inzicht hebben, om in staat te zijn de managementinformatie die aan het data warehouse wordt onttrokken op waarde te schatten.

Laatst was ik op het Data Vault Automation Seminar waar een van de sprekers het had over ‘knowledge partnership’. Het bedrijf waarvoor de spreker werkte, een ICT dienstverlener, bouwde in opdracht BI oplossingen voor haar klanten. Deze BI oplossingen werden uiteindelijk door de klant zelf in beheer genomen. In de eerste fase nam de dienstverlener 100% het voortouw, in daaropvolgende fasen werd onder begeleiding de klant steeds meer betrokken bij het ontwikkelproces. Net zolang totdat de klant al het werk zelf kon doen. Al doende werd op deze manier de klant voorzien van de kennis hij nodig om op eigen benen te staan aangaande het beheer, het onderhoud en de doorontwikkeling van de BI oplossing. De dienstverlener en haar klant gingen een knowledge partnership aan. Nu ging het hier niet om een BIAAS oplossing, maar de gedachte sprak mij erg aan. Openheid versus geslotenheid. Deze klanten kloppen in de toekomst heus wel weer aan bij deze dienstverlener, juist door deze openheid.

Een bedrijf dat op zoek is naar een BIAAS oplossing zou er goed aan doen een aanbieder te zoeken die met hen een knowledge partnership wil aangaan. De focus moet hier dan niet liggen op de techniek, want die moet op de achtergrond blijven. De focus zou juist moeten liggen op dat deel van de oplossing die specifiek is voor de afnemer van de service: de data. Zo kan voorkomen worden dat de BIAAS oplossing een black box wordt.

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 Data Vault, zie deze blog post.

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 rode cirkels zijn Attributes, de grijze ruit, geflankeerd door twee grijze bolletjes 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 werkelijk prachtig 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 wordt gemaakt 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.