Az előző cikkben beszéltem a DATA VAULT alapjairól, ismertettem a DATA VAULT főbb elemeit és azok célját. Ez nem tekinthető kimerültnek a DATA VAULT témakörében, beszélni kell a DATA VAULT fejlődésének következő lépéseiről.
Ebben a cikkben a DATA VAULT fejlesztésére és a BUSINESS DATA VAULT-ra vagy egyszerűen a BUSINESS VAULT-ra való átállásra fogok összpontosítani.
A BUSINESS DATA VAULT megjelenésének okai
Meg kell jegyezni, hogy a DATA VAULT bizonyos erősségei ellenére nem mentes a hátrányaitól. Az egyik ilyen hátrány az elemző lekérdezések írásának nehézsége. A lekérdezésekben jelentős számú JOIN van, a kód hosszú és nehézkes. Emellett a DATA VAULT-ba bevitt adatok semmilyen átalakuláson nem mennek keresztül, ezért üzleti szempontból a DATA VAULT-nak tiszta formájában nincs abszolút értéke.
Ezen hiányosságok kiküszöbölése érdekében a DATA VAULT módszertana olyan elemekkel bővült, mint:
- PIT (időpont) táblázatok;
- BRIDGE asztalok;
- ELŐRE MEGHATÁROZOTT DERIVÁCIÓK.
Nézzük meg közelebbről ezeknek az elemeknek a célját.
SZJA táblázatok
Jellemzően egy üzleti entitás (HUB) különböző frissítési gyakoriságú adatokat tartalmazhat, például ha egy személyt jellemző adatokról beszélünk, akkor azt mondhatjuk, hogy egy telefonszámra, címre vagy e-mailre vonatkozó információ magasabb frissítési sebességgel rendelkezik, mint mondjuk teljes név, útlevéladatok, családi állapot vagy nem.
Ezért a műholdak meghatározásakor szem előtt kell tartani a frissítési gyakoriságukat. Miért fontos?
Ha különböző frissítési gyakoriságú attribútumokat tárol ugyanabban a táblázatban, akkor minden alkalommal hozzá kell adnia egy sort a táblázathoz, amikor a leggyakrabban módosított attribútumot frissíti. Az eredmény a lemezterület növekedése és a lekérdezés végrehajtási idejének növekedése.
Most, hogy a műholdakat felosztottuk frissítési gyakoriság szerint, és önállóan tudunk rájuk adatokat betölteni, gondoskodnunk kell a naprakész adatok vételéről. Jobban, felesleges JOIN használata nélkül.
Hadd magyarázzam el, hogy például aktuális (az utolsó frissítés dátumának megfelelő) információkat kell beszereznie olyan műholdakról, amelyeknek különböző frissítési gyakorisága van. Ehhez nem csak egy JOIN-t kell végrehajtania, hanem több beágyazott lekérdezést is létre kell hoznia (minden egyes információt tartalmazó műholdra) a maximális frissítési dátum MAX (Frissítési dátum) kiválasztásával. Minden egyes új JOIN-nel az ilyen kód növekszik, és nagyon gyorsan nehezen érthetővé válik.
A PIT tábla az ilyen lekérdezések egyszerűsítésére szolgál; a PIT táblák egyidejűleg töltődnek fel az új adatok DATA VAULT-ba írásával. PIT táblázat:
Így minden egyes időpontban információval rendelkezünk az adatok relevanciájáról minden műholdra vonatkozóan. A PIT táblához való JOIN-ok használatával teljesen kiküszöbölhetjük a beágyazott lekérdezéseket, természetesen azzal a feltétellel, hogy a PIT-et minden nap kitöltik, és hiányosságok nélkül. Még ha vannak is hiányosságok az SZJA-ban, a naprakész adatok csak egy beágyazott lekérdezéssel szerezhetők be magának az SZJA-nak. Egy beágyazott lekérdezés gyorsabban dolgoz fel, mint az egyes műholdak beágyazott lekérdezései.
HÍD
A BRIDGE táblákat az analitikai lekérdezések egyszerűsítésére is használják. Ami azonban különbözik a PIT-től, az a különböző hubok, linkek és műholdaik közötti kérések egyszerűsítése és felgyorsítása.
A táblázat tartalmazza az összes szükséges kulcsot az összes műholdhoz, amelyeket gyakran használnak a lekérdezésekben. Ezenkívül, ha szükséges, a kivonatolt üzleti kulcsok kiegészíthetők szöveges kulcsokkal, ha a kulcsok neveire szükség van az elemzéshez.
A helyzet az, hogy a BRIDGE használata nélkül a különböző hubokhoz tartozó műholdakon található adatok vétele során nemcsak maguknak a műholdaknak, hanem a hubokat összekötő linkeknek is JOIN-t kell létrehozniuk.
A BRIDGE jelenlétét vagy hiányát a tárolási konfiguráció és a lekérdezés végrehajtási sebességének optimalizálása határozza meg. Nehéz a BRIGE egyetemes példájával előállni.
ELŐRE MEGHATÁROZOTT DERIVÁCIÓK
Egy másik típusú objektum, amely közelebb visz minket az ÜZLETI ADAT-VAULT-hoz, az előre kiszámított mutatókat tartalmazó táblázatok. Az ilyen táblázatok nagyon fontosak az üzleti életben, adott szabályok szerint összesített információkat tartalmaznak, és viszonylag könnyen hozzáférhetővé teszik.
Építészetileg az ELŐRE DEFINÍTOTT DERIVÁCIÓK nem mások, mint egy bizonyos csomópont egy másik műholdja. Ez, mint egy normál műhold, egy üzleti kulcsot és a műhold rekordjának létrehozásának dátumát tartalmazza. Itt azonban véget érnek a hasonlóságok. Egy ilyen „specializált” műhold attribútumainak további összetételét az üzleti felhasználók határozzák meg a legnépszerűbb, előre kiszámított mutatók alapján.
Például egy olyan hub, amely egy alkalmazottról információkat tartalmaz, tartalmazhat egy műholdat olyan jelzőkkel, mint például:
- Minimálbér;
- Maximális fizetés;
- Átlagos fizetés;
- Felhalmozott bérek összege stb.
Logikus, hogy az ELŐRE MEGHATÁROZOTT SZÁRMAZÉKOKAT ugyanannak a hubnak a SZJA táblájában szerepelteti, így könnyen beszerezhet adatszeleteket egy konkrétan kiválasztott időpontban egy alkalmazott számára.
Következtetések
Amint azt a gyakorlat mutatja, a DATA VAULT üzleti felhasználók általi használata több okból is kissé nehézkes:
- A lekérdezési kód bonyolult és nehézkes;
- A JOIN-ok bősége befolyásolja a lekérdezések teljesítményét;
- Az elemző lekérdezések írása a tárolótervezés kiemelkedő ismeretét igényli.
Az adathozzáférés egyszerűsítése érdekében a DATA VAULT további objektumokkal bővül:
- PIT (időpont) táblázatok;
- BRIDGE asztalok;
- ELŐRE MEGHATÁROZOTT DERIVÁCIÓK.
Következő Azt tervezem, hogy véleményem szerint a legérdekesebb dolgot elmondom azoknak, akik a BI-vel dolgoznak. Bemutatom a DATA VAULT alapú ténytáblák és dimenziótáblák létrehozásának módjait.
A cikk anyagai a következőkön alapulnak:
- tovább Kenta Graziano, amely a részletes leírás mellett modelldiagramokat is tartalmaz;
- Könyv: „Skálázható adattárház építése DATA VAULT 2.0-val”;
- cikk .
Forrás: will.com