Az adattárház a környezet változásainak kezelését az üzleti kulcsok (amelyek nem mutálódnak annyira gyakran, mivel egyedileg azonosítják az üzleti entitást) és az ezen üzleti kulcsok közötti kapcsolatokat az ezen kulcsok leíró attribútumaitól.
Az üzleti kulcsok és asszociációik strukturális attribútumok, amelyek az adatmodell vázát alkotják. Az adattár módszer egyik fő axiómája, hogy a valódi üzleti kulcsok csak akkor változnak, amikor az üzleti tevékenység változik, és ezért ezek a legstabilabb elemek, amelyekből a történeti adatbázis struktúrája levezethető. Ha ezeket a kulcsokat használja az adattárház gerinceként, akkor a többi adatot ezek köré szervezheti. Ez azt jelenti, hogy a csomópontok megfelelő kulcsainak kiválasztása elsődleges fontosságú a modell stabilitása szempontjából. A kulcsokat táblákban tárolja, amelyek szerkezetére néhány megkötés vonatkozik. Ezeket a kulcstáblákat huboknak nevezzük.
HubsEdit
A hubok egyedi, alacsony változtatási hajlandóságú üzleti kulcsok listáját tartalmazzák. A hubok tartalmaznak egy helyettesítő kulcsot is minden egyes hubelemhez, valamint az üzleti kulcs eredetét leíró metaadatokat. A hubon található információk leíró attribútumait (például a kulcs leírását, esetleg több nyelven) a Szatelit tábláknak nevezett struktúrákban tárolják, amelyekről alább lesz szó.
A hub legalább a következő mezőket tartalmazza:
- egy helyettesítő kulcs, amely a többi struktúrát ehhez a táblához kapcsolja.
- egy üzleti kulcs, az adott hub meghajtója. Az üzleti kulcs több mezőből is állhat.
- a rekord forrása, amelyből látható, hogy az egyes üzleti kulcsokat melyik rendszer töltötte be először.
- választhatóan metaadatmezők is lehetnek, amelyek a kézi frissítésekre (felhasználó/idő) és a kivonás dátumára vonatkozó információkat tartalmazzák.
Egy hub nem tartalmazhat több üzleti kulcsot, kivéve, ha két rendszer ugyanazt az üzleti kulcsot szállítja, de eltérő jelentésű ütközésekkel.
A huboknak általában legalább egy műholddal kell rendelkezniük.
Hub-példaEdit
Ez egy példa egy autókat tartalmazó, “Car” (H_CAR) nevű hub-táblára. A vezetési kulcs a jármű azonosító száma.
| Fieldname | Description | Mandatory? | Kommentár |
|---|---|---|---|
| H_CAR_ID | Sorozatazonosító és helyettesítő kulcs a hubhoz | Nem | Szükséges, de nem kötelező |
| VEHICLE_ID_NR | Az üzleti kulcs, amely ezt a hubot vezérli. Lehet egynél több mező egy összetett üzleti kulcs esetében | Igen | |
| H_RSRC | Ez a kulcs rekord forrása az első betöltéskor | Igen | |
| LOAD_AUDIT_ID | Egy ID egy olyan táblába, amely ellenőrzési információkat tartalmaz, például a betöltés ideje, a betöltés időtartama, a sorok száma stb. | Nem |
LinkEdit
Az üzleti kulcsok közötti asszociációk vagy tranzakciók (amelyek például az ügyfél és a termék csomópontjait kapcsolják össze egymással a vásárlási tranzakción keresztül) link táblák segítségével modellezhetők. Ezek a táblák alapvetően sok-sok összekötő táblák, némi metaadattal.
A linkek kapcsolódhatnak más linkekhez, hogy kezelni tudják a granularitás változásait (például egy új kulcs hozzáadása egy adatbázis-táblához megváltoztatja az adatbázis-tábla szemcsézettségét). Például, ha van egy asszociáció az ügyfél és a cím között, akkor hozzáadhat egy hivatkozást a termék és a szállítmányozó cég csomópontjai közötti linkre. Ez lehetne egy “Szállítás” nevű hivatkozás. Egy hivatkozás hivatkozása egy másik hivatkozásban rossz gyakorlatnak számít, mert olyan függőségeket vezet be a hivatkozások között, amelyek megnehezítik a párhuzamos betöltést. Mivel egy másik linkre való hivatkozás ugyanolyan, mint egy új link a másik link csomópontjaival, ezekben az esetekben a linkek létrehozása más linkekre való hivatkozás nélkül az előnyösebb megoldás (további információkért lásd a betöltési gyakorlatokról szóló részt).
A linkek néha olyan információkhoz kapcsolják a csomópontokat, amelyek önmagukban nem elegendőek egy csomópont felépítéséhez. Ez akkor fordul elő, ha a link által társított üzleti kulcsok egyike nem valódi üzleti kulcs. Példaként vegyünk egy rendelési űrlapot, amelynek kulcsa a “rendelés száma”, és olyan rendelési sorokat, amelyek egy félig véletlenszerű számmal vannak kulccsal ellátva, hogy egyedivé tegyék őket. Mondjuk, hogy “egyedi szám”. Ez utóbbi kulcs nem valódi üzleti kulcs, tehát nem hub. Azonban szükségünk van rá, hogy garantálni tudjuk a kapcsolat megfelelő granularitását. Ebben az esetben nem használunk hubot helyettesítő kulccsal, hanem magát az “egyedi szám” üzleti kulcsot adjuk hozzá a linkhez. Erre csak akkor kerül sor, ha nincs lehetőség arra, hogy az üzleti kulcsot valaha is felhasználjuk egy másik hivatkozáshoz vagy egy műhold attribútumainak kulcsaként. Ezt a konstrukciót Dan Linstedt a (már megszűnt) fórumán “peg-legged link”-nek nevezte.
A linkek tartalmazzák a kapcsolt csomópontok helyettesítő kulcsait, a saját helyettesítő kulcsukat a linkhez és a társítás eredetét leíró metaadatokat. Az asszociációra vonatkozó információk leíró attribútumait (például az időt, az árat vagy az összeget) a szatellit tábláknak nevezett struktúrákban tárolják, amelyeket alább tárgyalunk.
Link példaSzerkesztés
Ez egy példa egy link-táblára két csomópont között autók (H_CAR) és személyek (H_PERSON) számára. A link neve “Sofőr” (L_DRIVER).
| Mezőnév | leírás | Kényszer? | Kommentár |
|---|---|---|---|
| L_DRIVER_ID | Sorozatazonosító és helyettesítő kulcs a Linkhez | Nem | Szükséges, de nem kötelező |
| H_CAR_ID | helyettesítő kulcs a kocsi hubhoz, a link első horgonya | Igen | |
| H_PERSON_ID | helyettesítő kulcs a személy hubhoz, a kapcsolat második horgonya | Igen | |
| L_RSRC | Az első betöltéskor ennek a társításnak a rekordforrása | Igen | |
| LOAD_AUDIT_ID | Egy ID az ellenőrzési információkat tartalmazó táblába, például a betöltési idő, a betöltés időtartama, a sorok száma stb. | Nem |
SatellitesEdit
A csomópontok és linkek alkotják a modell szerkezetét, de nem rendelkeznek időbeli attribútumokkal és nem tartalmaznak leíró attribútumokat. Ezeket külön táblákban tároljuk, amelyeket műholdaknak nevezünk. Ezek olyan metaadatokból állnak, amelyek összekapcsolják őket a szülő hubjukkal vagy linkjükkel, az asszociáció és az attribútumok eredetét leíró metaadatokból, valamint az attribútum kezdő és befejező dátumát tartalmazó idővonalból. Míg a hubok és linkek a modell szerkezetét adják, addig a műholdak a modell “húsát”, a hubokban és linkekben rögzített üzleti folyamatok kontextusát. Ezeket az attribútumokat mind az ügy részletei, mind az idővonal tekintetében tárolják, és a meglehetősen összetettől (az ügyfelek teljes profilját leíró összes mező) az egészen egyszerűig (egy műhold egy hivatkozáson, amely csak egy érvényességi mutatót és egy idővonalat tartalmaz) terjedhetnek.
Az attribútumok általában forrásrendszer szerint vannak a műholdakba csoportosítva. Az olyan leíró attribútumok azonban, mint a méret, a költség, a sebesség, a mennyiség vagy a szín különböző sebességgel változhatnak, ezért ezeket az attribútumokat is feloszthatjuk különböző műholdakba a változásuk sebessége alapján.
Minden táblázat tartalmaz metaadatokat, amelyek minimálisan leírják legalább a forrásrendszert és azt a dátumot, amikor ez a bejegyzés érvényessé vált, így teljes múltbeli képet kapunk az adatokról, amint azok bekerülnek az adattárházba.
Szatellit példaSzerkesztés
Ez egy példa a gépkocsik és a személyek csomópontjai közötti, a “Sofőrbiztosítás” (S_DRIVER_INSURANCE) nevű járművezetői kapcsolatra vonatkozó műholdra. Ez a műhold olyan attribútumokat tartalmaz, amelyek az autó és az azt vezető személy közötti kapcsolat biztosítására jellemzőek, például egy jelzőt, hogy ez az elsődleges vezető-e, az adott autó és személy biztosítótársaságának nevét (lehet egy külön csomópont is) és egy összefoglalót a jármű és a vezető ezen kombinációját érintő balesetek számáról. Tartalmaz egy hivatkozást egy R_RISK_CATEGORY nevű kereső- vagy referenciatáblára is, amely tartalmazza annak a kockázati kategóriának a kódjait, amelybe ez a kapcsolat tartozik.
| Fieldname | Description | Mandatory? | Kommentár |
|---|---|---|---|
| S_DRIVER_INSURANCE_ID | Sorozatazonosító és helyettesítő kulcs a műholdhoz a kapcsolaton | Nem | Szükséges, de nem kötelező |
| L_DRIVER_ID | (helyettesítő) elsődleges kulcs a vezetői kapcsolathoz, a műhold szülője | Igen | |
| S_SEQ_NR | Sorrend- vagy sorszám, az egyediség kikényszerítésére, ha egy szülő kulcshoz több érvényes műhold tartozik | Nem(**) | Ez akkor fordulhat elő, ha például van egy COURSE csomópont, és a kurzus neve egy attribútum, de több különböző nyelven. |
| S_LDTS | Load Date (startdate) az L_DRIVER_ID | Yes | |
| S_LEDTS | Load End Date (végdátum) az attribútumértékek ezen kombinációjának érvényességére a szülői kulcshoz L_DRIVER_ID | No | |
| IND_PRIMARY_DRIVER | Indikátor, hogy a a járművezető az elsődleges vezetője ennek a járműnek | Nem (*) | |
| INSURANCE_COMPANY | A jármű és a járművezető biztosítótársaságának neve | Nem (*) | |
| NR_OF_ACCIDENTS | A járművezető által ezzel a járművel okozott balesetek száma | Nem (*) | |
| R_RISK_CATEGORY_CD | A járművezető kockázati kategóriája. Ez egy hivatkozás a R_RISK_CATEGORY | Nem (*) | |
| S_RSRC | Az ebben a műholdban lévő információk rekordforrása az első betöltéskor | Igen | |
| LOAD_AUDIT_ID | Az ellenőrzési információkat tartalmazó táblázat azonosítója, például a betöltési idő, a betöltés időtartama, a sorok száma stb. | Nem |
(*) legalább egy attribútum kötelező.(**) a sorszám akkor válik kötelezővé, ha az egyediség érvényesítéséhez szükséges több érvényes műhold esetében ugyanazon a hubon vagy linken.
Referencia táblákSzerkesztés
A referencia táblák egy egészséges adattároló modell normális részei. Azért vannak, hogy megakadályozzák a sokszor hivatkozott egyszerű referenciaadatok redundáns tárolását. Formálisabban Dan Linstedt a következőképpen definiálja a referenciaadatokat:
Minden olyan információ, amelyet szükségesnek tartanak a leírások kódokból való feloldásához, vagy a kulcsok konzisztens módon történő lefordításához (sic). Sok ilyen mező “leíró” jellegű, és a többi fontosabb információ egy adott állapotát írja le. Mint ilyenek, a referenciaadatok a nyers Data Vault tábláktól különálló táblákban élnek.
A referencia táblákra a Satellitekből hivatkoznak, de soha nem kötődnek fizikai idegen kulcsokkal. A referenciatábláknak nincs előírt szerkezete: azt használja, ami az adott esetben a legjobban működik, az egyszerű keresőtábláktól kezdve a kis adattárházakig vagy akár a csillagokig. Lehetnek történeti vagy történettel nem rendelkező referenciatáblák, de ajánlott a természetes kulcsokhoz ragaszkodni, és ebben az esetben nem létrehozni helyettesítő kulcsokat. Általában az adattárházak sok referenciatáblával rendelkeznek, mint bármely más adattárház.
ReferenciapéldaSzerkesztés
Ez egy példa a járművezetők kockázati kategóriáit tartalmazó referenciatáblára. Az adattárház bármelyik műholdjáról hivatkozható. Most az S_DRIVER_INSURANCE műholdról hivatkozunk rá. A referenciatábla a R_RISK_CATEGORY.
| Fieldname | Description | Mandatory? |
|---|---|---|
| R_RIZK_CATEGORY_CD | A kockázati kategória kódja | Igen |
| RIZK_CATEGORY_DESC | A kockázati kategória leírása | Nem (*) |
(*) legalább egy attribútum kötelező.