Een van de meest krachtige concepten achter ODI is misschien wel het scheiden van de logische opzet van een Data Warehouse en de fysieke implementatie daarvan in verschillende omgevingen.
Om in de termen van het product te spreken, onderkennen we in de Designer een logisch model – een datamodel – dat we kunnen implementeren in verschillende fysieke omgevingen, zoals een ontwikkelomgeving, testomgeving en productie omgeving.
Dit leggen we vast in de Topology van ODI door middel van:
- Een “logical architecture”. In het plaatje hierboven wordt het de “logical view” genoemd. In feite beschrijft de logical architecture op welke manier een datamodel in een soortgelijke groep technologie wordt omgegaan. Dit klinkt misschien cryptisch, dus aan de hand van een voorbeeld zullen we dit toelichten:
Stel dat we een data warehouse willen ontwerpen en bouwen, en alle feiten en dimensies in een Oracle database willen opslaan. Deze Oracle database heeft bepaalde kenmerken die van toepassing zijn op alle dimensies en feiten die met deze technologie worden beheerd.
Het feit dat de tabellen in een Oracle database worden opgeslagen, zegt nog niets over de daadwerkelijk plaats waar dit gebeurt.
- Een “physical architecture”. In het plaatje hierboven wordt dit de “Physical Resources” genoemd. In feite beschrijft dit de plaats (de server) waar de tabellen uit een datamodel worden opgeslagen.
In het bovenstaande voorbeeld van ons data warehouse betekent dit dat de tabellen worden opgeslagen in een Oracle database genaamd DEV voor de ontwikkelomgeving (die werkt op server dev035), UAT voor de testomgeving (die werkt op server uat100), etc.
De physical architecture beschrijft dus de technische details (de plaats) en de technologie, en zal altijd 1 technologie bevatten.
Binnen de physical architecture neem je ook altijd de definitie op van de ODI Agents.
- Een “context”. Dit is een verbinding tussen een logical en physical architecture. Dus in ons voorbeeld hebben we 1 data warehouse model voor de techologie Oracle database, die in 3 verschillende omgevingen worden geïnstalleerd en gebruikt, en waarbij er dus ook 3 contexten zijn.
De standaard context die altijd aanwezig is, is de global context. De context is ook van belang bij het deployen en uitvoeren van ETL (ELT) code.
Voor de topology geldt ook een zogenaamde best practice. En voordat je die leest, moet je misschien nogmaals eerst het bovenstaande lezen.
Best Practice
Tijdens de inrichting van een ODI omgeving is het begrijpen van de concepten van de topology dermate belangrijk. In de praktijk gaat er namelijk nogal eens wat fout op dit gebied, zoals:
- Het niet expliciet opnemen van een context. Dit kan ertoe leiden dat ETL code niet werkt voor een bepaalde context. Zorg dus altijd voor een context waarin de logical en physical architectures worden gekoppeld.
- Het opgeven van een bepaalde context terwijl dit niet echt noodzakelijk is. Bij mappings en procedures kun je als eigenschap een context opgeven. Dit is niet verstandig, omdat bij het uitvoeren van de ETL code altijd gevraagd wordt in welke context deze uitgevoerd moet worden. Laat dus de standaardwaarde voor de context staan.