Depozite de date – Dimensiuni în schimbare lentă – Implementare

Cheie surogat de tip 2 cu atribut de tip 3

În multe implementări pentru dimensiuni în schimbare lentă (SCD) de tip 2 și tip 6, cheia surogat din dimensiune este pusă în tabelul de fapte în locul cheii naturale atunci când datele de fapt sunt încărcate în depozitul de date. Cheia surogat este selectată pentru o anumită înregistrare a faptului, pe baza datei sale de intrare în vigoare și a Data_Start și End_Date din tabelul de dimensiuni. Acest lucru permite unirea cu ușurință a datelor de fapt cu datele de dimensiune corecte pentru data efectivă corespunzătoare.

Iată tabelul Furnizorilor așa cum l-am creat mai sus folosind metodologia hibridă de tip 6:

Supplier_Key	Supplier_Code	Supplier_Name	Current_State	Historical_State	Start_Date	End_Date	Current_Flag
123	ABC	Acme Supply Co	NY	CA	01-Jan-2000	21-Dec-2004	N
124	ABC	Acme Supply Co	NY	IL	22-Dec-2004	03-Feb-2008	N
125	ABC	Acme Supply Co	NY	NY	04-Feb-2008	31-Dec-9999	Y

Odată ce tabelul Livrare conține Supplier_Key corectă, aceasta poate fi conectată cu ușurință la tabelul Furnizori folosind cheia respectivă. Următorul SQL preia, pentru fiecare înregistrare de fapt, starea curentă a furnizorului și starea în care se afla furnizorul la momentul livrării:

SELECT
delivery.delivery_cost,
supplier.supplier_name,
supplier.historical_state,
supplier.current_state
FROM delivery
INNER JOIN supplier
ON delivery.supplier_key = supplier.supplier_key

Implementare pură tip 6

Având o cheie surogat de tip 2 pentru fiecare secțiune de timp poate cauza probleme dacă dimensiunea este supusă modificării.

O implementare pură de tip 6 nu folosește acest lucru, dar folosește o cheie surogat pentru fiecare element de date master (de exemplu, fiecare furnizor unic are o singură cheie surogat).

Acest lucru evită orice modificări ale datelor de bază care au un impact asupra datelor tranzacțiilor existente.

De asemenea, permite mai multe opțiuni la interogarea tranzacțiilor.

Iată tabelul Furnizorilor folosind metodologia pură de tip 6:

Supplier_Key	Supplier_Code	Supplier_Name	Supplier_State	Start_Date	End_Date
456	ABC	Acme Supply Co	CA	0i-Jan-2000	2l-Dec-2004
456	ABC	Acme Supply Co	IL	22-Dec-2004	03-Feb-2008
456	ABC	Acme Supply Co	NY	04-Feb-2008	3i-Dec-9999

Următorul exemplu arată cum trebuie extinsă interogarea pentru a se asigura că o singură înregistrare a furnizorului este preluată pentru fiecare tranzacție.

SELECT
supplier.supplier_code,
supplier.supplier_state
FROM supplier
INNER JOIN delivery
ON supplier.supplier_key = delivery.supplier_key
AND delivery.delivery_date BETWEEN supplier.start_date AND supplier.end_date

O înregistrare a faptelor cu o dată în vigoare (Delivery_Date) de 9 august 2001 va fi conectată la Supplier_Code ABC, cu un Supplier_State de „CA”. O înregistrare a faptelor cu o dată în vigoare de 11 octombrie 2007 va fi, de asemenea, legată de același Supplier_Code ABC, dar cu un Supplier_State de „IL”.

Deși este mai complexă, există o serie de avantaje ale acestei abordări, inclusiv:

1. Integritatea referențială prin DBMS este acum posibilă, dar nu se poate folosi Supplier_Code ca cheie externă în tabelul Product și folosind Supplier_Key ca cheie externă fiecare produs este legat pe un interval de timp specific.
2. Dacă există mai multe date pe fapt (de exemplu, data comenzii, data livrării, data plății facturii), se poate alege data de utilizat pentru o interogare.
3. Puteți face interogări „ca acum”, „ca la momentul tranzacției” sau „ca la un moment dat” schimbând logica filtrului de dată.
4. Nu trebuie să reprocesați tabelul Fact dacă există o modificare în tabelul de dimensiuni (de exemplu, adăugarea de câmpuri suplimentare retroactiv care modifică intervalele de timp sau dacă cineva face o greșeală în datele din tabelul de dimensiuni, le puteți corecta uşor).
5. Puteți introduce date bitemporale în tabelul de dimensiuni.
6. Puteți asocia acest fapt cu mai multe versiuni ale tabelului de dimensiuni pentru a permite raportarea aceleași informații cu date de intrare diferite, în aceeași interogare.

Următorul exemplu arată cum poate fi utilizată o anumită dată, cum ar fi „2012-01-01 00:00:00” (care ar putea fi data și ora actuală).

SELECT
supplier.supplier_code,
supplier.supplier_state
FROM supplier
INNER JOIN delivery
ON supplier.supplier_key = delivery.supplier_key
AND ‘2012-01-01 00:00:00’ BETWEEN supplier.start_date AND supplier.end_date

Atât cheia surogat, cât și cheia naturală

O implementare alternativă este să plasați atât cheia surogat, cât și cheia naturală în tabelul de fapte. Acest lucru permite utilizatorului să selecteze înregistrările de dimensiune adecvate pe baza:

• datei principale de intrare în vigoare din dosarul faptelor (mai sus),
• informațiilor cele mai recente sau actuale,
• oricărei altă dată asociată cu înregistrarea faptelor.

Această metodă permite legături mai flexibile către dimensiune, chiar dacă s-a folosit abordarea de tip 2 în loc de tipul 6.

Iată tabelul Furnizorilor, așa cum ar fi fost creat folosind metodologia de tip 2:

Supplier_Key	Supplier_Code	Supplier_Name	Supplier_State	Start_Date	End_Date	Current_Flag
123	ABC	Acme Supply Co	CA	01-Jan-2000	21-Dec-2004	N
124	ABC	Acme Supply Co	IL	22-Dec-2004	03-Feb-2008	N
125	ABC	Acme Supply Co	NY	04-Feb-2008	31-Dec-9999	Y

Următorul SQL preia cele mai recente Supplier_Name și Supplier_State pentru fiecare înregistrare de fapt:

SELECT
delivery.delivery_cost,
supplier.supplier_name,
supplier.supplier_state
FROM delivery
INNER JOIN supplier
ON delivery.supplier_code = supplier.supplier_code
WHERE supplier.current_flag = ‘Y’

Dacă în înregistrarea faptului există date multiple, faptul poate fi alăturat dimensiunii utilizând o altă dată în loc de data efectivă principală. De exemplu, tabelul Livrare poate avea o dată în vigoare principală Delivery_Date, dar poate avea și o Order_Date asociată cu fiecare înregistrare.

Următorul SQL preia Supplier_Name și Supplier_State corecte pentru fiecare înregistrare de fapte pe baza Order_Date:

SELECT
delivery.delivery_cost,
supplier.supplier_name,
supplier.supplier_state
FROM delivery
INNER JOIN supplier
ON delivery.supplier_code = supplier.supplier_code
AND delivery.order_date BETWEEN supplier.start_date AND supplier.end_date

Câteva precauții:

• Integritatea referenţială de către DBMS nu este posibilă, deoarece nu există un unic pentru a crea relaţia.
• Dacă relația este făcută cu surogat pentru a rezolva problema de mai sus, atunci se termină cu o entitate legată de o anumită secțiune de timp.
• Dacă interogarea de alăturare nu este scrisă corect, este posibil să returneze rânduri duplicate și/sau să ofere răspunsuri incorecte.
• Este posibil ca în cazul comparării datei aceasta să nu funcționeze bine.
• Unele instrumente de business intelligence nu gestionează bine generarea de alăturări complexe.
• Procesele ETL necesare pentru crearea tabelului de dimensiuni trebuie proiectate cu atenție pentru a se asigura că nu există suprapuneri în perioadele de timp pentru fiecare element de date de referință distinct.
• Multe dintre problemele de mai sus pot fi rezolvate folosind diagrama mixtă a unui model scd de mai jos.

Combinarea tipurilor

Diferite tipuri SCD pot fi aplicate diferitelor coloane ale unui tabel. De exemplu, putem aplica Tipul 1 la coloana Supplier_Name și Tipul 2 la coloana Supplier_State din același tabel.

 (Model SCD)

Sursa: Drew Bentley, Business Intelligence and Analytics. © 2017 Library Press, Licență CC BY-SA 4.0. Traducere și adaptare: Nicolae Sfetcu