Bolta de date încearcă să rezolve problema abordării schimbărilor din mediul înconjurător prin separarea cheilor de afaceri (care nu suferă mutații atât de des, deoarece identifică în mod unic o entitate de afaceri) și asociațiile dintre aceste chei de afaceri, de atributele descriptive ale acestor chei.
Cele de afaceri și asociațiile lor sunt atribute structurale, formând scheletul modelului de date. Metoda boltei de date are ca una dintre axiomele sale principale faptul că cheile de afaceri reale se schimbă numai atunci când se schimbă afacerea și, prin urmare, sunt cele mai stabile elemente din care se poate deriva structura unei baze de date istorice. Dacă folosiți aceste chei drept coloana vertebrală a unui depozit de date, puteți organiza restul datelor în jurul lor. Acest lucru înseamnă că alegerea cheilor corecte pentru hub-uri este de primă importanță pentru stabilitatea modelului dumneavoastră. Cheile sunt stocate în tabele cu câteva constrângeri asupra structurii. Aceste tabele cu chei se numesc hub-uri.
Hub-uriEdit
Hub-urile conțin o listă de chei unice de afaceri cu o tendință scăzută de schimbare. Hub-urile conțin, de asemenea, o cheie surogat pentru fiecare element Hub și metadate care descriu originea cheii de business. Atributele descriptive pentru informațiile din Hub (cum ar fi descrierea cheii, eventual în mai multe limbi) sunt stocate în structuri numite tabele satelit, care vor fi discutate mai jos.
Hub conține cel puțin următoarele câmpuri:
- o cheie surogat, utilizată pentru a conecta celelalte structuri la această tabelă.
- o cheie de afaceri, driverul pentru acest hub. Cheia operațională poate fi formată din mai multe câmpuri.
- sursa înregistrării, care poate fi utilizată pentru a vedea ce sistem a încărcat mai întâi fiecare cheie operațională.
- opțional, puteți avea și câmpuri de metadate cu informații despre actualizările manuale (utilizator/timp) și data extragerii.
Un hub nu are voie să conțină mai multe chei de afaceri, cu excepția cazului în care două sisteme livrează aceeași cheie de afaceri, dar cu coliziuni care au semnificații diferite.
Huburile ar trebui să aibă în mod normal cel puțin un satelit.
Exemplu de hubEdit
Acesta este un exemplu pentru un hub-table care conține mașini, numit „Car” (H_CAR). Cheia de conducere este numărul de identificare al vehiculului.
| Fieldname | Description | Mandatory? | Comentariu | |
|---|---|---|---|---|
| H_CAR_ID | Identificare de secvență și cheie surogat pentru hub | Nu | Recomandat, dar opțional | |
| VEHICLE_ID_ID_NR | Cheia comercială care conduce acest hub. Poate fi mai mult de un câmp pentru o cheie de business compozită | Yes | ||
| H_RSRC | Sursa de înregistrare a acestei chei atunci când este încărcată pentru prima dată | Yes | ||
| LOAD_AUDIT_ID | Un ID într-un tabel cu informații de audit, cum ar fi timpul de încărcare, durata încărcării, numărul de linii, etc. | Nu |
LinksEdit
Asocierile sau tranzacțiile dintre cheile de afaceri (care leagă, de exemplu, hub-urile pentru client și produs între ele prin intermediul tranzacției de cumpărare) sunt modelate cu ajutorul tabelelor de legături. Aceste tabele sunt, practic, tabele de îmbinare mulți-la-mulți, cu unele metadate.
Legăturile se pot lega de alte legături, pentru a face față schimbărilor de granularitate (de exemplu, adăugarea unei noi chei la o tabelă de bază de date ar schimba granulația tabelului de bază de date). De exemplu, dacă aveți o asociere între client și adresă, ați putea adăuga o referință la o legătură între hub-urile pentru produs și compania de transport. Aceasta ar putea fi o legătură numită „Livrare”. Trimiterea unei legături în altă legătură este considerată o practică proastă, deoarece introduce dependențe între legături care îngreunează încărcarea paralelă. Deoarece o legătură către o altă legătură este același lucru cu o nouă legătură cu hub-urile din cealaltă legătură, în aceste cazuri, crearea legăturilor fără a face referire la alte legături este soluția preferată (pentru mai multe informații, consultați secțiunea privind practicile de încărcare).
Legăturile leagă uneori hub-urile de informații care nu sunt suficiente prin ele însele pentru a construi un hub. Acest lucru se întâmplă atunci când una dintre cheile de activitate asociate de legătură nu este o cheie de activitate reală. Ca exemplu, să luăm un formular de comandă având ca cheie „număr de comandă” și linii de comandă care sunt codificate cu un număr semialeatoriu pentru a le face unice. Să spunem, „număr unic”. Această din urmă cheie nu este o cheie comercială reală, deci nu este un hub. Cu toate acestea, trebuie să o folosim pentru a garanta granularitatea corectă a legăturii. În acest caz, nu folosim un hub cu o cheie surogat, ci adăugăm cheia comercială „număr unic” în sine la legătură. Acest lucru se face numai în cazul în care nu există nicio posibilitate de a utiliza vreodată cheia operațională pentru o altă legătură sau ca cheie pentru atribute într-un satelit. Această construcție a fost numită de Dan Linstedt pe forumul său (acum dispărut) „peg-legged link”.
Link-urile conțin cheile surogat pentru hub-urile care sunt legate, propria lor cheie surogat pentru legătură și metadatele care descriu originea asocierii. Atributele descriptive pentru informațiile privind asocierea (cum ar fi ora, prețul sau suma) sunt stocate în structuri numite tabele satelit care sunt discutate mai jos.
Exemplu de legăturăEdit
Acesta este un exemplu pentru o tabelă de legătură între două hub-uri pentru mașini (H_CAR) și persoane (H_PERSON). Legătura se numește „Driver” (L_DRIVER).
| Fieldname | Description | Mandatory? | Comentariu | |
|---|---|---|---|---|
| L_DRIVER_ID | Identificare de secvență și cheie surogat pentru legătură | Nu | Recomandat, dar opțional | |
| H_CAR_ID | cheie surogat pentru butucul mașinii, prima ancoră a legăturii | Da | ||
| H_PERSON_ID | cheie substitutivă pentru hub-ul persoanei, a doua ancoră a legăturii | Yes | ||
| L_RSRC | Furnizorul de înregistrări al acestei asociații la prima încărcare | Yes | ||
| LOAD_AUDIT_ID | Un ID într-un tabel cu informații de audit, cum ar fi timpul de încărcare, durata încărcării, numărul de linii, etc. | Nu |
SatellitesEdit
Centrele și legăturile formează structura modelului, dar nu au atribute temporale și nu dețin atribute descriptive. Acestea sunt stocate în tabele separate numite sateliți. Acestea constau în metadate care le leagă de hub-ul sau legătura lor părinte, metadate care descriu originea asocierii și a atributelor, precum și o linie temporală cu datele de început și de sfârșit pentru atribut. În timp ce hub-urile și legăturile oferă structura modelului, sateliții oferă „carnea” modelului, contextul pentru procesele de afaceri care sunt capturate în hub-uri și legături. Aceste atribute sunt stocate atât în ceea ce privește detaliile problemei, cât și cronologia și pot varia de la destul de complexe (toate câmpurile care descriu profilul complet al unui client) la destul de simple (un satelit pe o legătură cu doar un indicator de validitate și o cronologie).
De obicei, atributele sunt grupate în sateliți în funcție de sistemul sursă. Cu toate acestea, atributele descriptive, cum ar fi dimensiunea, costul, viteza, cantitatea sau culoarea, se pot schimba în ritmuri diferite, astfel încât puteți, de asemenea, să împărțiți aceste atribute în sateliți diferiți în funcție de rata lor de schimbare.
Toate tabelele conțin metadate, care descriu minimal cel puțin sistemul sursă și data la care această intrare a devenit valabilă, oferind o vedere istorică completă a datelor pe măsură ce intră în depozitul de date.
Exemplu de satelitEdit
Acesta este un exemplu pentru un satelit pe legătura șoferilor între hub-urile pentru mașini și persoane, numit „Asigurarea șoferului” (S_DRIVER_INSURANCE). Acest satelit conține atribute care sunt specifice asigurării relației dintre mașină și persoana care o conduce, de exemplu, un indicator care indică dacă acesta este șoferul principal, numele companiei de asigurări pentru această mașină și persoană (ar putea fi, de asemenea, un hub separat) și un rezumat al numărului de accidente care implică această combinație de vehicul și șofer. De asemenea, este inclusă o trimitere la un tabel de căutare sau de referință numit R_RISK_CATEGORY care conține codurile pentru categoria de risc în care se consideră că se încadrează această relație.
| Fieldname | Description | Mandatory? | Comentariu | |
|---|---|---|---|---|
| S_DRIVER_INSURANCE_ID | Identificare de secvență și cheie surogat pentru satelitul de pe legătură | Nu | Recomandat, dar opțional | |
| L_DRIVER_ID | (surogat) cheie primară pentru legătura cu șoferul, părintele satelitului | Da | ||
| S_SEQ_NR | Numărul de ordine sau de secvență, pentru a impune unicitatea în cazul în care există mai mulți sateliți valabili pentru o cheie părinte | Nu(**) | Acest lucru se poate întâmpla dacă, de exemplu, aveți un hub COURSE și numele cursului este un atribut, dar în mai multe limbi diferite. | |
| S_LDTS | Data de încărcare (startdate) pentru validitatea acestei combinații de valori de atribute pentru cheia părinte L_DRIVER_ID | Da | ||
| S_LDTS | Data de sfârșit a încărcării (enddate) pentru validitatea acestei combinații de valori de atribute pentru cheia părinte L_DRIVER_ID | Nu | ||
| IND_PRIMARY_DRIVER | Indicator care arată dacă șoferul este șoferul principal pentru acest vehicul | Nu (*) | ||
| INSURANCE_COMPANY | Numele companiei de asigurări pentru acest vehicul și acest șofer | Nu (*) | ||
| NR_OF_ACCIDENTE | Numărul de accidente produse de acest conducător auto în acest vehicul | Nu (*) | ||
| R_RISK_CATEGORY_CD | Categoria de risc pentru acest conducător auto. Aceasta este o referință la R_R_RISK_CATEGORY | Nu (*) | ||
| S_RSRC | Sursa de înregistrare a informațiilor din acest satelit la prima încărcare | Da | ||
| LOAD_AUDIT_ID | Un ID într-un tabel cu informații de audit, cum ar fi timpul de încărcare, durata încărcării, numărul de linii, etc. | Nu |
(*) cel puțin un atribut este obligatoriu.(**) numărul de secvență devine obligatoriu dacă este necesar pentru a impune unicitatea pentru mai mulți sateliți valabili pe același hub sau legătură.
Tabele de referințăEdit
Tabelele de referință sunt o parte normală a unui model sănătos de boltă de date. Ele au rolul de a preveni stocarea redundantă a datelor de referință simple care sunt menționate foarte des. În mod mai formal, Dan Linstedt definește datele de referință după cum urmează:
Toată informația considerată necesară pentru a rezolva descrierile din coduri sau pentru a traduce cheile în (sic) o manieră coerentă. Multe dintre aceste câmpuri sunt de natură „descriptivă” și descriu o stare specifică a altor informații mai importante. Ca atare, datele de referință trăiesc în tabele separate de tabelele brute din Data Vault.
Tabelele de referință sunt referite din Satellites, dar nu sunt niciodată legate cu chei străine fizice. Nu există o structură prescrisă pentru tabelele de referință: folosiți ceea ce funcționează cel mai bine în cazul dvs. specific, de la simple tabele de căutare până la mici seifuri de date sau chiar stele. Acestea pot fi istorice sau nu au istoric, dar se recomandă să vă limitați la cheile naturale și să nu creați chei surogat în acest caz. În mod normal, seifurile de date au o mulțime de tabele de referință, la fel ca orice alt Data Warehouse.
Exemplu de referințăEdit
Acesta este un exemplu de tabel de referință cu categorii de risc pentru șoferii de vehicule. Acesta poate fi referit din orice satelit din depozitul de date. Deocamdată îl referim din satelitul S_DRIVER_INSURANCE. Tabelul de referință este R_RISK_CATEGORY.
| Fieldname | Description | Mandatory? |
|---|---|---|
| R_RISK_CATEGORY_CD | Codul categoriei de risc | Da |
| RISK_CATEGORY_DESC | Descrierea categoriei de risc | Nu (*) |
(*) cel puțin un atribut este obligatoriu.