Logisch Data Warehouse
De logica van een logisch data warehouse – deel 2

In deel 1 van dit blog artikel heb ik uitgelegd hoe je structuur aanbrengt in je logische data warehouse met een functionele architectuur. De volgende stap is uiteraard de vertaling van die architectuur naar een technische inrichting. Voor dit artikel ga ik ervan uit dat we daarbij gebruik maken van een platform voor datavirtualisatie, bijvoorbeeld Denodo. Zo’n platform is enorm flexibel in te richten en dwingt weinig af in je keuzes. Een fijne eigenschap, maar dat vereist wel dat je regels hanteert voor een logische en gestructureerde technische inrichting van het platform.

Structuur

De keuze voor een logisch data warehouse wordt vaak gemaakt om de levertijd van informatie drastisch te verbeteren. En terecht. Daarvoor is een gestructureerde inrichting van je datavirtualisatieplatform wel essentieel. Zonder logica ligt chaos alweer snel op de loer en weet niemand meer waar hij nu eigenlijk naar zit te kijken. Dat gaat niet allen ten koste van de ontwikkelsnelheid. Ook het snel uitleveren van nieuwe versies wordt een stuk lastiger en foutgevoeliger als niet exact duidelijk is welke objecten tot welke release behoren.

Handvaten

Ik kan je niet één vaste manier geven waarop je je virtuele omgeving moet inrichten. De keuzes zijn voor ieder project of organisatie weer anders. De technische omgeving, de omvang van je organisatie, de organisatiestructuur, de toepassingen, allemaal factoren die de inrichting beïnvloeden. Toch zijn er een aantal vaste handvaten die je kunt gebruiken om je eigen technische inrichting te kiezen, bijvoorbeeld het aanbrengen van een goede mappenstructuur, naamgevingsconventies en gebruik van virtual databases per bedrijfsonderdeel. Voordat ik die uitleg een – hopelijk overbodige – waarschuwing: documenteer al je inrichtingskeuzes goed én vooraf, en pas binnen één virtuele omgeving alle gebruikte standaarden consequent toe!

Mappenstructuur

We beginnen bij het begin: het aanbrengen van een mappenstructuur die aansluit bij de architectuurlagen zoals ik die in deel 1 van dit blog artikel beschreef. Met deze structuur zijn alle technische stappen op een logische plek in het datavirtualisatieplatform terug te vinden. Dat ziet er als volgt uit:

  1. Connectielaag: de basis
    1. Data sources: In deze map worden alle in het project gebruikte connecties naar databronnen vastgelegd. Iedere connectie naar een bron krijgt zijn eigen submap. Wanneer er sprake is van heel veel verschillende bronnen is het raadzaam ze nog onder te verdelen naar type bron (JDBC, XML, SQL server, Oracle, etc.). Het bekijken van databronnen in deze map wordt niet gehinderd door de onderliggende technische complexiteit (zoals van hiërarchische XML bestanden of multidimensionele objecten) omdat die wordt weggenomen door de connector van het datavirtualisatieplatform.
    2. Base views: De connectielaag bevat ook een map voor de zgn. base views. Base views zijn de primaire verwijzing naar de data in de bronsystemen. De connector van het platform naar de databron zorgt er altijd voor dat de base views te gebruiken zijn als ‘normale’ views (rijen en kolommen) ongeacht de structuur en locatie van de bron.
  2. Datalaag: integratie en combinatie
    1. Derived views source: Hier worden ‘combinatie-views’ vastgelegd voor de integratie van gegevens binnen eenzelfde bron, als voorbereidende stap op de integratie met data van andere bronnen of op het opbouwen van het informatiemodel (in de data mart laag).
    2. Derived views integrated sources: Deze map bevat ook ‘combinatie-views’, maar dan voor de integratie van gegevens tussen verschillende databronnen, bijvoorbeeld de koppeling tussen twee verschillende productregistraties uit verschillende systemen.
    3. Stored procedures: In deze map staan alle stored procedures die gemaakt worden in het datavirtualisatie project. Het datavirtualisatieplatform bevat een uitgebreide verzameling stored procedures (vergelijkbaar met een database), extra functionaliteit kan echter eenvoudig worden toegevoegd.
  3. Data mart-laag: opbouw informatie
    1. Final views: Hier staan de gevirtualiseerde tabellen (views dus) die gebruikt worden voor publicatie: data marts, datasets, dimensie- & feitentabellen etc. Dit is ook de plek waar business logica en rekenregels worden toegepast om bijvoorbeeld de gewenste aantallen of bedragen te bepalen (winst na belasting, bruto omzet, unieke aantallen etc.).
  4. Presentatielaag: publicatie informatie- en/of analysemodel. Externe afnemers of rapportagetools krijgen alleen toegang tot de views uit deze map. Dit is ook de plek van databeveiliging en toegangscontrole. Bijvoorbeeld door het afschermen van bepaalde attributen (column masking) of het weglaten van bepaalde delen van de data (row level security). Gepubliceerde web services worden ook hier vastgelegd.
    1. Interfaces: Een interface is een speciaal type view die alleen de definities en naamgeving van de kolommen en datatypes bevat. Interfaces helpen bij het opbouwen van views in de data mart laag, waarbij het informatiemodel (het ontwerp van de data mart) leidend is en de herkomst van data uit onderliggende bronnen gefaseerd kan worden toegevoegd of later eenvoudig kan worden gewijzigd. Daarmee is een interface een krachtig hulpmiddel om de gewenste ontkoppeling tussen rapportages en business logica te bereiken. De interface bevindt zich direct op het snijpunt van de business logica die is vastgelegd in het datavirtualisatieplatform met de uitwisseling van deze gegevens met afnemers van de informatie. De interface is dus de technische implementatie van ‘ontkoppeling en hergebruik van logica’ in het logisch data warehouse.
    2. Associations: Hier worden de definities van associaties onderhouden. Het concept van de association kennen we uit de datamodellering. Het beschrijft de relatie tussen elementen van twee objecten, een structurele afhankelijkheid tussen twee objecten. Een virtuele database, opgebouwd met een datavirtualisatieplatform, functioneert en presteert prima zonder vastgelegde relaties. Maar voor gebruikers of software tools die toegang krijgen tot de gevirtualiseerde database kan het van belang zijn dat relaties zijn aangeduid en gedefinieerd. Bijvoorbeeld voor een beter begrip van de samenhang van de data bij de gebruiker of voor efficiëntie bij de opbouw van rapportages.
    3. Data services: Deze map wordt gebruikt voor de registratie en configuratie van web services en API’s (bijvoorbeeld REST, SOAP, widgets, JMS). Ook worden hier de verschillende toegangsmethodes voor de web service of API geadministreerd (HTTP, WSS, basic/digest, met of zonder LDAP etc.).

SuperNova

Misschien is het je opgevallen dat deze opbouw en indeling overeenkomsten vertoont met de SuperNova, een techniek voor datamodellering om gegevens uit een data vault beschikbaar te maken voor analyse en rapportage met behulp van datavirtualisatie. Voor een uitgebreide uitleg over SuperNova verwijs ik je graag naar de whitepaper “Data Vault and Data Virtualization: Double Agility” van Rick van der Lans. Interessant leesvoer, omdat SuperNova naar mijn mening ook heel goed gebruikt kan worden voor allerlei andere vormen van data dan alleen gegevens in een data vault model.

Versiebeheer

Datavirtualisatie biedt geweldige mogelijkheden voor ‘agile BI development’. In nauw overleg met business gebruikers kunnen informatieproducten heel snel opgeleverd worden. Maar ook bij agile werken, is een stabiele dienstverlening van groot belang. Dat begint met het inrichten van versiebeheer. Door goed versiebeheer is het altijd duidelijk wie wanneer welk object (bijv. een view) heeft gewijzigd en kun je altijd terug naar een eerdere versie. Bij het werken in teamverband en bij het uitrollen van releases met gewijzigde functionaliteit van de logisch data warehouse, is versiebeheer onmisbaar. De voor de hand liggende manier om dit in te richten is het koppelen van een tool voor versiebeheer. Dat maakt het mogelijk om ongehinderd door te ontwikkelen op het datavirtualisatieplatform terwijl gewijzigde functionaliteit geautomatiseerd uit wordt gerold.

In een datavirtualisatieplatform als Denodo kunnen meerdere ontwikkelaars aan hetzelfde project werken. Door de directe koppeling met het versiebeheersysteem (check-in, check-out) is het direct duidelijk wie met welke wijzigingen bezig is. Ook is het mogelijk wijzigingen als één logisch geheel te markeren om zo een release samen te stellen die uit meerdere wijzigingen bestaat, en in één keer van de ontwikkelomgeving – via test en eventueel acceptatie – naar de productieomgeving kan worden overgezet (deployment).

Centraal regelen of lokale vrijheid?

De hierboven beschreven technische indeling van één datavirtualisatie project werkt goed bij een kleine tot middelgrote implementatie. Als een centraal BI-team de datavirtualisatielaag opbouwt en onderhoudt in één bedrijf is dit de gangbare indeling. Wordt datavirtualisatie breder ingezet en vervult het logisch data warehouse functies binnen allerlei business units, dan zal ook de noodzaak toenemen om bepaalde zaken centraal te regelen maar andere activiteiten juist te decentraliseren en vrijgeven. Aan de ene kant speelt het belang van continuïteit en gelijkvormigheid van vaste rapportages (bijv. de maandrapportage of gestandaardiseerde rapportages aan externe toezichthouders). Daar tegenover staat juist de kracht van differentiatie (bijv. verschillende analyse en rapportagetools op dezelfde data of data aanbieden via data services) en innovatie op basis van data-analyse (de mogelijkheid om te ‘spelen’ met data op zoek naar nieuwe inzichten).

Centraal regelen

Het voordeel van centraal regelen is dat nieuwe data snel en betrouwbaar kan worden toegevoegd. Logische taken om centraal te regelen zijn dus:

  • Regie over definities, logica, autorisatie, bronontsluiting
  • Opbouw van een virtueel enterprise data warehouse met centraal gereguleerde, auditeerbare informatie en herhaalbare processen.
  • Opbouwen van datamarts voor rapportages met een statisch karakter, zoals rapportages voor externe verantwoording met een duidelijke vastgelegde definitie en structuur. Continuïteit en herhaalbaarheid zijn hierbij van groot belang.

Lokale vrijheid

Een datavirtualisatieplatform biedt veel mogelijkheden voor het lokaal beschikbaar stellen van data zodat gebruikers zelfstandig gegevens kunnen combineren en met hun eigen tools kunnen analyseren. Niet alleen voor eigen rapportages of visualisaties, maar ook om data te koppelen met andere datasets, zodat zo voor hun eigen domein (land, business unit, functie, procesrol etc.) relevante informatie kunnen opbouwen.

Lokaal vrijgeven van datavirtualisatie is in diverse situaties zinvol:

  • Voor het combineren en analyseren van bekende en nieuwe data, gebruikmakend van andere tools dan die ‘standaard’ zijn binnen de organisatie.
  • Voor het ontsluiten van nieuwe databronnen, bestanden en webservices. Omdat er geen fysieke ETL-programmatuur ontwikkeld hoeft te worden, kan dit heel snel!
  • Voor het combineren van eigen datasets met data uit het centraal beheerde logische data warehouse. Voor de centrale data kijkt iedereen (met eigen tools) naar dezelfde definities.
  • Om datascientists snel te voorzien van data waarmee ze kunnen ‘spelen’.

Lokale vrijheid

Centrale virtuele database en toch lokale vrijheid

Mooi natuurlijk, al die verschillende ritmes en toepassingen van data in een logisch data warehouse. Maar hoe implementeer je dat? Het ligt voor de hand om te beginnen met het realiseren van een centrale virtuele database. Die database zorgt voor de connectie naar en ontkoppeling van de bronsystemen die data leveren. Zo hoef je de technische complexiteit van de databron maar één keer te doorgronden en je voorkomt dat systemen op verschillende momenten en met verschillende methodes benaderd worden. Vervolgens ga je aan de slag om een aantal zaken die voor alle gebruikers van de data in de virtuele database van belang zijn in te regelen:

  • Organisatiebreed definiëren van dimensies, organisatiehiërarchieën, klanten, financiële metrics, projecten, budgetten, functies etc.
  • Vastleggen van business rules over informatie in de virtuele database.
  • Autorisatie en toegang tot de data.

Deze centraal opgebouwde virtuele database kan vanzelfsprekend benaderd worden met de rapportage- en analysetools. Maar het is ook mogelijk functionaliteit van het datavirtualisatieplatform vrij te geven aan business units waarmee zij zelf eigen datavirtualisatie-elementen kunnen toevoegen aan de centrale (virtuele) data. Zo kan de opbouw van datavirtualisatie ook gedecentraliseerd worden. Uiteraard binnen de grenzen van de autorisaties.

Centrale virtuele database

Conclusie

Ik hoop dat ik je hiermee een aantal goede handvaten heb gegeven voor het logisch en gestructureerd opbouwen van je logisch data warehouse. Als je de goede keuzes maakt bij de inrichting, kan datavirtualisatie de levertijd van informatie drastisch verkorten. Nog los van de kostenbesparing, lagere ontwikkeltijd en grotere flexibiliteit voor eindgebruikers. Maar daarvoor moet je het wel logisch aanpakken! Eenmaal ontstane chaos is niet zo makkelijk meer op te ruimen.

Natuurlijk is er nog veel meer te vertellen over het implementeren van (of migreren naar) een logisch data warehouse. Over diverse onderwerpen schreven we eerder al blog artikelen. De komende tijd gaan in we nog dieper in op de return on investment van een logisch data warehouse, het landschap van datavirtualisatieproducten en de samenhang tussen data governance en het logisch data warehouse.