In een voorgaand artikel schreef ik over het voordeel van het afhandelen van wijzigingen binnen een dimensie volgens het Kimball Slowly Changing Dimension Type 2 principe, het aanmaken van een nieuwe rij binnen een dimensie. Er is uitgelegd wat de voordelen van deze methode zijn en hoe het werkt. Hieronder staat beschreven wat de voordelen zijn van het gebruik van T-SQL scripts ten opzichte van een ETL-Tool voor het bijwerken van een dimensie.
Wat controleer je?
Het bijwerken van een dimensie is saai. Negen van de tien keer doe je hetzelfde truukje opnieuw. Je pakt een datastroom uit een bronsysteem en een datastroom uit een dimensie. Deze houd je tegen elkaar aan en vervolgens controleer je altijd drie dingen:
- Zijn er wijzingen opgetreden;
- Zijn er deletes;
- Zijn er logische deletes.
Een wijziging is een verandering van een veld in een bronsysteem die impact heeft op een attribuut binnen een dimensie, bijvoorbeeld: de achternaam van een klant is veranderd doordat hij is getrouwd. Een delete is een record dat fysiek niet meer aanwezig is binnen een bronsysteem en een logische delete is een record dat met een markering als verwijderd is gekenmerkt.
Tool of SQL?
Voor het controleren van deze drie eigenschappen zijn verschillende methoden. Je kunt een ETL-tool gebruiken zoals SQL Server Integration Services of je kunt zelf een script bouwen / genereren die deze controle voor je doet. Ik ben altijd een voorstander geweest van tools. Tools zijn zelf-documenterend en nemen veel werk uit handen. Nu ik met een project bezig ben waarbij veel acties met SQL worden afgehandeld zonder tools zie ik steeds meer de voordelen van het links laten liggen van tools.
Voordelen:
- Voorkomt problemen met versieovergang
- Genereerbaar
- Werkt altijd
- Beheersbaarheid
Nadelen:
- Complexer en minder overzichtelijk
- Meer initieel ontwikkelwerk
ETL tools zijn zelf-documentered. Door gebruik te maken van tools zoals een Dataflowtask of een Derived Column zie je wat er gebeurd. Ook zijn tools sneller te begrijpen dan lappen code. Tot slot is het bouwen van je eigen ETL natuurlijk veel meer werk. Toch pluk je hier denk ik op langere termijn de vruchten van. Staat je oplossing eenmaal dan is het datawarehouse schaalbaarder en beter beheersbaar. Tot zover mijn mening over het gebruik van SQL vs TOOLS.
Tags
