Dimensiunile din gestionarea datelor și depozitarea datelor conțin date relativ statice despre astfel de entități, cum ar fi locații geografice, clienți sau produse. Datele capturate de dimensiunile în schimbare lentă (Slowly Changing Dimensions, SCD) se schimbă lent, dar imprevizibil, mai degrabă decât conform unui program obișnuit.
Unele scenarii pot cauza probleme de integritate referenţială.
De exemplu, o bază de date poate conține un tabel de fapte care stochează înregistrările vânzărilor. Acest tabel de fapte ar fi legat de dimensiuni prin intermediul cheilor externe. Unul dintre aceste dimensiuni poate conține date despre agenții de vânzări ai companiei: de exemplu, birourile regionale în care lucrează. Cu toate acestea, oamenii de vânzări sunt uneori transferați de la un birou regional la altul. În scopul raportării istorice a vânzărilor, poate fi necesar să se păstreze o evidență a faptului că o anumită persoană de vânzări a fost desemnată la un anumit birou regional la o dată anterioară, în timp ce acel agent de vânzări este acum repartizat într-un birou regional diferit.
Tratarea acestor probleme implică metodologii de gestionare a SCD denumite tip 0 până la 6. SCD de tip 6 sunt uneori numite SCD hibride.
Tip 0: Păstrează originalul
Metoda de tip 0 este pasivă. Gestionează modificările dimensionale și nu se efectuează nicio acțiune. Valorile rămân așa cum erau în momentul în care înregistrarea dimensiunii a fost inserată pentru prima dată. În anumite circumstanțe, istoria este păstrată cu un Tip 0. Tipuri de ordin mai mari sunt folosite pentru a garanta păstrarea istoriei, în timp ce Tipul 0 oferă cel mai mic control sau deloc. Acesta este rar folosit.
Tip 1: Suprascrie
Această metodologie suprascrie vechile date cu date noi și, prin urmare, nu urmărește datele istorice. Exemplu de tabel furnizor:
Supplier_Key | Supplier_Code | Supplier_Name | Supplier_State |
123 | ABC | Acme Supply Co | CA |
În exemplul de mai sus, Supplier_Code este cheia naturală, iar Supplier_Key este o cheie surogat. Din punct de vedere tehnic, cheia surogat nu este necesară, deoarece rândul va fi unic prin cheia naturală (Suppplier_Code). Cu toate acestea, pentru a optimiza performanța la îmbinări, utilizați mai degrabă chei întregi decât chei cu caractere (cu excepția cazului în care numărul de octeți din cheia de caractere este mai mic decât numărul de octeți din cheia întreg).
Dacă furnizorul își mută sediul în Illinois, înregistrarea va fi suprascrisă:
Supplier_Key | Supplier_Code | Supplier_Name | Supplier_State |
123 | ABC | Acme Supply Co | IL |
Dezavantajul metodei de tip 1 este că nu există istoric în depozitul de date. Are totuși avantajul că este ușor de întreținut.
Dacă s-a calculat un tabel agregat care rezumă faptele în funcție de stare, acesta va trebui recalculat când se schimbă Supplier_State.
Tip 2: Adaugă un rând nou
Această metodă urmărește datele istorice prin crearea mai multor înregistrări pentru o anumită cheie naturală în tabelele dimensionale cu chei surogat separate și/sau numere de versiune diferite. Istoricul nelimitat este păstrat pentru fiecare inserție.
De exemplu, dacă furnizorul se mută în Illinois, numerele de versiune vor fi incrementate secvenţial:
Supplier_Key | Supplier_Code | Supplier_Name | Supplier_State | Version. |
123 | ABC | Acme Supply Co | CA | 0 |
124 | ABC | Acme Supply Co | IL | 1 |
O altă metodă este să adăugați coloane „dată efectivă”.
Supplier_Key | Supplier_Code | Supplier_Name | Supplier_State | Start_Date | End_Date |
123 | ABC | Acme Supply Co | CA | 01-Jan-2000 | 21-Dec-2004 |
124 | ABC | Acme Supply Co | IL | 22-Dec-2004 | NULL |
Null End_Date din rândul doi indică versiunea tuplului curent. În unele cazuri, poate fi utilizată o dată superioară standardizată substitutivă (de exemplu, 9999-12-31) ca dată de încheiere, astfel încât câmpul să poată fi inclus într-un index și astfel încât să nu fie necesară înlocuirea cu valori nule la interogare.
Tranzacțiile care fac referire la o anumită cheie surogat (Supplier_Key) sunt apoi legate permanent la intervalele de timp definite de acel rând din tabelul de dimensiuni care se schimbă lent. Un tabel agregat care rezumă faptele în funcție de stare continuă să reflecte starea istorică, adică starea în care se afla furnizorul la momentul tranzacției; nu este necesară nicio actualizare. Pentru a face referire la entitate prin cheia naturală, este necesar să eliminați constrângerea unică, care face imposibilă integritatea referențială de către DBMS.
Dacă există modificări retroactive aduse conținutului parametrului sau dacă sunt adăugate noi atribute la dimensiune (de exemplu, o coloană Sales_Rep) care au date efective diferite de cele deja definite, atunci aceasta poate duce la necesitatea tranzacțiilor existente. actualizat pentru a reflecta noua situație. Aceasta poate fi o operațiune costisitoare a bazei de date, așa că SCD-urile de tip 2 nu sunt o alegere bună dacă modelul dimensional este supus modificării.
Tip 3: Adaugă un nou atribut
Această metodă urmărește modificările folosind coloane separate și păstrează istoricul limitat. Tipul 3 păstrează istoricul limitat, deoarece este limitat la numărul de coloane desemnate pentru stocarea datelor istorice. Structura inițială a tabelului în Tipul 1 și Tipul 2 este aceeași, dar Tipul 3 adaugă coloane suplimentare. În exemplul următor, a fost adăugată o coloană suplimentară la tabel pentru a înregistra starea inițială a furnizorului – este stocat doar istoricul anterior.
Supplier_Key | Supplier_Code | Supplier_Name | Original_Supplier_State | Effective_Date | Current_Supplier_State |
123 | ABC | Acme Supply Co | CA | 22-Dec-2004 | IL |
Această înregistrare conține o coloană pentru starea inițială și starea curentă — nu se pot urmări modificările dacă furnizorul se mută a doua oară.
O variantă a acestui lucru este crearea câmpului Previous_Supplier_State în loc de Original_Supplier_State, care ar urmări doar cea mai recentă modificare istorică.
Tip 4: Adaugă tabel istoric
Metoda de tip 4 este de obicei denumită „tabele de istorie”, în care un tabel păstrează datele curente, iar un tabel suplimentar este folosit pentru a păstra o evidență a unora sau a tuturor modificărilor. Ambele chei surogat sunt menționate în tabelul Fact pentru a îmbunătăți performanța interogării.
Pentru exemplul de mai sus, numele tabelului original este Supplier, iar tabelul istoric este Supplier_History.
Supplier | |||
Supplier_key | Supplier_Code | Supplier_Name | Supplier_State |
124 | ABC | Acme & Johnson Supply Co | IL |
Supplier_History | ||||
Supplier_key | Supplier_Code | Supplier_Name | Supplier_State | Create_Date |
123 | ABC | Acme Supply Co | CA | 14-June-2003 |
124 | ABC | Acme & Johnson Supply Co | IL | 22-Dec-2004 |
Această metodă seamănă cu modul în care funcționează tabelele de auditare a bazei de date și tehnicile de modificare a captării datelor.
Tip 6: Hibrid
Metoda de tip 6 combină abordările tipurilor 1, 2 și 3 (1 + 2 + 3 = 6). O posibilă explicație a originii termenului a fost că a fost inventat de Ralph Kimball în timpul unei conversații cu Stephen Pace din Kalido. Ralph Kimball numește această metodă „Modificări imprevizibile cu suprapunere într-o singură versiune” în The Data Warehouse Toolkit.
Tabelul Supplier începe cu o înregistrare pentru furnizorul nostru din exemplu:
Supplier_Key | Row_Key | Supplier_Code | Supplier_Name | Current_State | Historical_State | Start_Date | End_Date | Current_Flag |
123 | 1 | ABC | Acme Supply Co | CA | CA | 01-Jan-2000 | 31-Dec-2009 | Y |
Current_State și Historical_State sunt aceleași. Atributul opțional Current_Flag indică faptul că aceasta este înregistrarea curentă sau cea mai recentă pentru acest furnizor.
Când Acme Supply Company se mută în Illinois, adăugăm o nouă înregistrare, ca în procesarea de tip 2, totuși este inclusă o cheie de rând pentru a ne asigura că avem o cheie unică pentru fiecare rând:
Supplier_Key | Row_Key | Supplier_Code | Supplier_Name | Current_State | Historical_State | Start_Date | End_Date | Current_Flag |
123 | 1 | ABC | Acme Supply Co | IL | CA | 01-Jan-2000 | 21-Dec-2004 | N |
123 | 2 | ABC | Acme Supply Co | IL | IL | 22-Dec-2004 | 31-Dec-2009 | Y |
Suprascriem informațiile Current_Flag din prima înregistrare (Row_Key = 1) cu informațiile noi, ca în procesarea de tip 1. Creăm o nouă înregistrare pentru a urmări modificările, ca în procesarea de tip 2. Și stocăm istoricul într-o a doua coloană State (Historical_State), care încorporează procesarea de tip 3.
De exemplu, dacă furnizorul s-ar reloca din nou, am adăuga o altă înregistrare la dimensiunea Supplier și am suprascrie conținutul coloanei Current_State:
Supplier_Key | Row_Key | Supplier_Code | Supplier_Name | Current_State | Historical_State | Start_Date | End_Date | Current_Flag |
123 | 1 | ABC | Acme Supply Co | NY | CA | 01-Jan-2000 | 21-Dec-2004 | N |
123 | 2 | ABC | Acme Supply Co | NY | IL | 22-Dec-2004 | 03-Feb-2008 | N |
123 | 3 | ABC | Acme Supply Co | NY | NY | 04-Feb-2008 | 31-Dec-2009 | Y |
Rețineți că, pentru înregistrarea curentă (Current_Flag = ‘Y’), Current_State și Historical_State sunt întotdeauna aceleași.
Sursa: Drew Bentley, Business Intelligence and Analytics. © 2017 Library Press, Licență CC BY-SA 4.0. Traducere și adaptare: Nicolae Sfetcu
Lasă un răspuns