Kiezen tussen langzaam veranderende dimensietypen
Ontwerptheorie van stervormige schema's verwijst naar veelvoorkomende SCD-typen. De meest voorkomende zijn Type 1 en Type 2. In de praktijk kan een dimensietabel een combinatie van geschiedenistraceringsmethoden ondersteunen, waaronder Type 3 en Type 6. Laten we het verschil in deze SCD-typen leren kennen.
Type 1 SCD
Een SCD van type 1 weerspiegelt altijd de meest recente waarden en wanneer wijzigingen in brongegevens worden gedetecteerd, worden de dimensietabelgegevens overschreven. Deze ontwerpbenadering is gebruikelijk voor kolommen met aanvullende waarden, zoals het e-mailadres of telefoonnummer van een klant. Wanneer een e-mailadres of telefoonnummer van een klant wordt gewijzigd, werkt de dimensietabel de rij van de klant bij met de nieuwe waarden. Het is alsof de klant altijd deze contactgegevens had. Het sleutelveld, zoals CustomerID, blijft hetzelfde, zodat de records in de feitentabel automatisch worden gekoppeld aan de bijgewerkte klantrecord.
Type 2 SCD
Een SCD van type 2 ondersteunt versiebeheer van dimensieleden. Vaak slaat het bronsysteem geen versies op, dus het laadproces van het datawarehouse detecteert en beheert wijzigingen in een dimensietabel. In dit geval moet de dimensietabel een surrogaatsleutel gebruiken om een unieke verwijzing naar een versie van het dimensielid op te geven. Het bevat ook kolommen die de geldigheid van het datumbereik van de versie definiëren (bijvoorbeeld StartDate en EndDate) en mogelijk een vlagkolom (bijvoorbeeld IsCurrent) om eenvoudig te filteren op huidige dimensieleden.
Adventure Works wijst bijvoorbeeld verkopers toe aan een verkoopregio. Wanneer een verkoper een regio verplaatst, moet er een nieuwe versie van de verkoper worden gemaakt om ervoor te zorgen dat historische feiten gekoppeld blijven aan de voormalige regio. Ter ondersteuning van een nauwkeurige historische analyse van de verkoop door verkoper moet de dimensietabel versies van verkopers en hun bijbehorende regio's opslaan. De tabel moet ook waarden voor de begin- en einddatum bevatten om de geldigheid van de tijd te definiëren. Huidige versies kunnen een lege einddatum definiëren (of 12-31-9999), wat aangeeft dat de rij de huidige versie is. De tabel moet ook een surrogaatsleutel definiëren omdat de zakelijke sleutel (in dit geval werknemer-id) niet uniek is.
Het is belangrijk te begrijpen dat wanneer de brongegevens geen versies opslaan, u een tussenliggend systeem (zoals een datawarehouse) moet gebruiken om wijzigingen te detecteren en op te slaan. Het laadproces van de tabel moet bestaande gegevens behouden en wijzigingen detecteren. Wanneer een wijziging wordt gedetecteerd, moet het laadproces van de tabel de huidige versie verlopen. Deze wijzigingen worden vastgelegd door de EndDate waarde bij te werken en een nieuwe versie in te voegen met de StartDate waarde die begint met de vorige EndDate waarde. Gerelateerde feiten moeten ook een op tijd gebaseerde zoekactie gebruiken om de dimensiesleutelwaarde op te halen die relevant is voor de feitendatum.
Type 3 SCD
Een SCD van type 3 ondersteunt het opslaan van twee versies van een dimensielid als afzonderlijke kolommen. De tabel bevat een kolom voor de huidige waarde van een lid plus de oorspronkelijke of vorige waarde van het lid. In Type 3 worden dus extra kolommen gebruikt om één sleutelexemplaren van de geschiedenis bij te houden, in plaats van extra rijen op te slaan om elke wijziging bij te houden, zoals in een SCD van type 2.
Dit type tracering kan worden gebruikt voor een of twee kolommen in een dimensietabel. Het is niet gebruikelijk om deze te gebruiken voor veel leden van dezelfde tabel. Het wordt vaak gebruikt in combinatie met Type 1- of Type 2-leden.
Type 6 SCD
Een Type 6 SCD combineert Type 1, 2 en 3. Wanneer er een wijziging plaatsvindt in een Type 2-lid, maakt u een nieuwe rij met de juiste Begindatum en Einddatum. In type 6-ontwerp slaat u ook de huidige waarde op in alle versies van die entiteit, zodat u eenvoudig kunt rapporteren over de huidige waarde of de historische waarde.
Met behulp van het voorbeeld van de verkoopregio splitst u de kolom Regio in CurrentRegion en HistoricalRegion. De CurrentRegion meest recente waarde wordt altijd weergegeven en de HistoricalRegion regio die geldig was tussen de StartDate en EndDate. Voor dezelfde verkoper zou elke record dus de meest recente regio hebben ingevuld CurrentRegion , terwijl HistoricalRegion het gebiedsveld in het SCD-voorbeeld van type 2 precies werkt.
