Oracle Data Integrator is een van de vele hulpmiddelen voor datatransport (ETL). Zoals we tegenwoordig wel vaker zien met tools, is dat er weinig onderscheid zit in de functionaliteit die deze tools bieden. Naar onze mening zijn Knowledge Modules (hierna afgekort als KM’s) een onderdeel binnen ODI dat het product zeer krachtig maakt, en daarmee is het een onderscheidend feature van ODI ten opzichte van andere ETL tools.
Wat zijn Knowlegde Modules?
KM’s zijn een soort code templates. Ze worden toegepast op een stap binnen een ODI mapping, en voeren daarna een veelheid aan handelingen uit. Dit bespaart een bouwer van ETL code (mappings) uiteindelijk dus werk.
Een KM bouw je met een soort ‘metataal’, en bevat dus allerlei tags. Deze tags zijn bijvoorbeeld van toepassing op tabel- en kolomnamen, en krijgen dus door de gebruikte tabellen en kolommen in de mapping een concrete betekenis.
Met alleen een KM kun je niets. Het wordt pas betekenisvolle code op het moment dat een KM aan een stap in een mapping is toegekend.
Soorten KM’s
KM’s zijn er 6 soorten, elk voor een specifiek doel.
De KM’s voor Loading, Integration en Checks worden het meest toegepast. Een Integration KM is er eigenlijk altijd.
De Check KM
De Check KM werkt in dit geval nadat de gegevens zijn ingelezen. Op basis van een set regels (business rules) worden alle rijen in een apart “error table” geplaatst die niet voldoen aan de gestelde regels. Per business rule kun je zelf een foutomschrijving specificeren.
Het komt er dus op neer dat je dezelfde template code kunt toepassen op verschillende mappings. Afhankelijk van de tabel kun je zelf de juiste business rules opnemen in het ODI model.
In de praktijk worden de Check KM’s vooral toepast nadat de gegevens in de staging area van een Data Warehouse zijn ingelezen.
De Loading KM
De Loading KM werkt tussen bron en doel, die zich vanuit technisch oogpunt in een aparte omgeving bevinden, bijvoorbeeld een bestand als bron en een database tabel als doel. Of twee databases die fysiek in een aparte omgeving staan.
De Loading KM zorgt ervoor dat de twee omgevingen met elkaar verbonden worden. In dit geval pas je de LKM toe op het zogenaamde “access point” in de mapping. Een access point is de verbinding tussen de bron en de doeldata, en bevindt zich bij de doeldata.
De Integration KM
De Integration KM zorgt ervoor dat de gegevens met de juiste stappen in de doeltabel terecht komen. De IKM staat gespecificeerd bij elke doeltabel in een mapping.
De Journalizing KM
Tot slot de Journalizing KM. Deze zorgt ervoor dat een Changed Data Capture mechanisme wordt toegepast op de bron, om alle mutaties in de bron beschikbaar te krijgen in de doelomgeving.
In ODI wordt gebruik gemaakt van GoldenGate om alle wijzigingen in de bron te repliceren naar de staging area in de doelomgeving (bijv. Data Warehouse).a
KM’s in detail
Als we ODI gaan gebruiken, dan worden al heel veel KM’s meegeleverd voor direct gebruik. Op basis van de 6 rubrieken die we hiervoor hebben beschreven zijn de KM’s ingedeeld.
Voor de drie meest gebruikte KM rubrieken zijn de volgende KM’s beschikbaar:
- Loading KM
- LKM Oracle to Oracle (DB Link). Leest data vanuit een brondatabase in een doeldatabase via een database link.
- LKM File to Oracle (SQLLDR). Leest data vanuit een bronbestand in een doeldatabase met behulp van SQL Loader.
- LKM SQL to SQL. Leest data vanuit een brondatabase via SQL in, en schrijft daarna de data weg in de doeldatabase met SQL. Dit is veruit de meest generieke en breed toepasbare KM voor Loading.
- Integration KM
Er zijn vier soorten smaken om gegevens weg te schrijven:
Append. Voegt alle data toe aan de doeltabel. Optioneel kan de doeltabel eerst worden geleegd. Vooral toepasbaar voor de staging area in een Data Warehouse.
Control Append. Voegt alle data toe (net als Append), maar kan tussentijds ook nog datacontroles uitvoeren.
Incremental Update. Leest nieuwe rijen in, en verwerkt de gewijzigde rijen door de oude waarden te overschrijven met de nieuwe (SCD type 1).
Slowly Changing Dimension. Verwerkt data in de doeltabel voor een SCD type 2. Is dus in feite een incremental update die rekening houdt met historie.
Uiteindelijk leidt dit tot 5 soorten IKM’s:
IKM Oracle Incremental Update (MERGE). Is “incremental update” met behulp van een Oracle (SQL) merge commando. Niet altijd even zuinig met schrijven, want alle data die in de bron staat wordt 1:1 overgezet, of deze inhoudelijk nu anders is of hetzelfde.
IKM SQL to File Append. Is een “append” om data vanuit een bestand toe te voegen aan een tabel met behulp van een SQL insert command.
IKM SQL Incremental Update. Leest data vanuit een ODI staging tabel in een doeltabel, waarbij de tabellen in dezelfde database staan. Leest en schrijft dus met SQL select en insert/update commando’s, en is daardoor zeer breed toepasbaar.
IKM SQL to SQL Append. Leest data vanuit een tabel in een doeltabel, waarbij de tabellen aparte databases staan. Leest en schrijft dus met SQL select en insert commando’s, en is daardoor zeer breed toepasbaar.
- Check KM
- CKM SQL. Controleert de data nadat deze in een data server is gezet die SQL ‘praat’.
- CKM Oracle. Controleert de data nadat deze in een Oracle data server is gezet. Is dus minder generiek dan de CKM SQL.
Vervolg…
Binnenkort een uitgewerkt voorbeeld over een KM die Slowly Changing Dimensions (type 2) ondersteunt. Deze KM is breed inzetbaar, dus ook voor Data Vault toepassingen en toestandsmodellen (tijdvakken in een feit als alternatief voor een snapshot table).