Home » Articole » Articole » Calculatoare » Baze de date » Depozite de date: Dimensiuni în schimbare lentă

Depozite de date: Dimensiuni în schimbare lentă

postat în: Baze de date 0

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

Rețele de comunicații 5G
Rețele de comunicații 5G

Descoperă cum 5G transformă lumea și pregătește-te să fii parte din viitor.

Nu a fost votat 14.32 lei32.94 lei Selectează opțiunile Acest produs are mai multe variații. Opțiunile pot fi alese în pagina produsului.
Tehnologia Blockchain - Bitcoin
Tehnologia Blockchain – Bitcoin

Transformă-ți perspectiva asupra tehnologiei blockchain și începe să descoperi oportunitățile digitale de mâine!

Nu a fost votat 23.89 lei57.41 lei Selectează opțiunile Acest produs are mai multe variații. Opțiunile pot fi alese în pagina produsului.
Statistica pentru afaceri
Statistica pentru afaceri

Instrumentul esențial pentru decizii inteligente în mediul de afaceri!

Nu a fost votat 19.11 lei40.94 lei Selectează opțiunile Acest produs are mai multe variații. Opțiunile pot fi alese în pagina produsului.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *