Het doel van SMR…
Bij gebruik van ETL ten behoeve van een datawarehouse hebben wijzigingen in brondatabases vaak impact. De mate van impact hangt uiteraard af van de aard en omvang van de wijzigingen maar ook van de 'intelligentie' van de ETL, of berer; de mate waarin de ETL om kan gaan met dergelijke wijzigingen. Vaak ontbreekt deze intelligentie en is het aan de beheerders om tijdig actie te ondernemen en de ETL aan te passen aan de gewijzigde brondatabase.
In de praktijk is echter niet altijd tijdig bekend of er wijzigingen zijn of welke dat precies zijn en of die invloed hebben. In dat geval is het gevolg vaak dat de ETL 'omvalt' in de productieomgeving.
Soms informeert de leverancier (extern of intern) de beheerders m.b.t. wijzigingen maar dat is zeker niet altijd het geval. Het gevaar daarbij is dat de databasewijziging in de acceptatieomgeving met succes was getest en al enige tijd zonder problemen in productie draait waarna plotseling de ETL 'omvalt'.
Voorbeeld: een kolomdefinitie wijzigt van 50 naar 100 tekens, pas wanneer er daadwerkelijk meer dan 50 tekens worden gebruikt treedt er een fout op in de ETL omdat 'iets' niet meer past, in veel gevallen zal die foutsituatie het eerst in de productieomgeving voorkomen.
Om productieverstoring te voorkomen is het daarom van belang dat elke wijziging zo snel mogelijk wordt gesignaleerd – dus liefst zelfs vóór het testen – zodat hier rekening mee gehouden kan worden en problemen kunnen worden voorkomen.
De oplossing voor bovengenoemd probleem is relatief simpel; door een repository bij te houden van de metadata van betreffende brondatabases is het mogelijk om deze periodiek te vergelijken met de bron en evt. wijzigingen daarin meteen te signaleren (detecteren en rapporteren).
Dit is nu precies wat SMR doet.
Bekijk de video... (in het Engels)