Razvoj PODATKOVNEGA TREZORA in prehod v POSLOVNI PODATKOVNI TREZOR

V prejšnjem članku sem govoril o osnovah PODATKOVNEGA SEFORA, opisal glavne elemente PODATKOVNEGA SEFORA in njihov namen. S tem teme PODATKOVNEGA SEFORA ne moremo šteti za izčrpanega, treba je govoriti o naslednjih korakih v razvoju PODATKOVNEGA SEFORA.

In v tem prispevku se bom osredotočil na razvoj PODATKOVNEGA SEFORA in prehoda na BUSINESS DATA VAULT ali preprosto POSLOVNI SEF.

Vzroki za nastanek TREZORA POSLOVNIH PODATKOV

Opozoriti je treba, da DATA VAULT, čeprav ima določene prednosti, ni brez pomanjkljivosti. Ena od teh pomanjkljivosti je težava pri pisanju analitičnih poizvedb. Poizvedbe imajo precejšnje število JOIN-jev, koda je dolga in okorna. Prav tako se podatki, ki vstopajo v DATA VAULT, ne spreminjajo, zato s poslovnega vidika DATA VAULT v svoji čisti obliki nima absolutne vrednosti.

Da bi odpravili te pomanjkljivosti, je bila metodologija DATA VAULT razširjena z elementi, kot so:

  • PIT (point in time) tabele;
  • mize BRIDGE;
  • VNAPREJ DOLOČENE IZPELJAVE.

Oglejmo si podrobneje namen teh elementov.

PIT mize

Običajno lahko en poslovni subjekt (HUB) vsebuje podatke z različnimi stopnjami posodabljanja, na primer, če govorimo o podatkih, ki označujejo osebo, lahko rečemo, da imajo informacije o telefonski številki, naslovu ali e-pošti višjo stopnjo posodabljanja kot npr. polno ime, podatki o potnem listu, zakonski stan ali spol.

Zato morate pri določanju satelitov upoštevati njihovo pogostost posodabljanja. Zakaj je pomembno?

Če v isto tabelo shranjujete atribute z različnimi stopnjami posodabljanja, boste morali dodati vrstico v tabelo vsakič, ko se posodobi najpogosteje spremenjen atribut. Rezultat je povečanje prostora na disku in podaljšanje časa izvajanja poizvedbe.

Zdaj, ko smo satelite razdelili po pogostosti posodabljanja in lahko neodvisno nalagamo podatke vanje, bi morali zagotoviti, da lahko prejemamo posodobljene podatke. Bolje, brez uporabe nepotrebnih JOIN-ov.

Naj pojasnim, da morate na primer pridobiti trenutne (glede na datum zadnje posodobitve) informacije od satelitov, ki imajo različne stopnje posodabljanja. Če želite to narediti, ne boste morali samo narediti JOIN, ampak tudi ustvariti več ugnezdenih poizvedb (za vsak satelit, ki vsebuje informacije) z izbiro največjega datuma posodobitve MAX (Datum posodobitve). Z vsakim novim JOIN-om se takšna koda poveča in zelo hitro postane težko razumljiva.

PIT tabela je namenjena poenostavitvi tovrstnih poizvedb, PIT tabele se polnijo sočasno z zapisovanjem novih podatkov v DATA VAULT. Tabela PIT:

Razvoj PODATKOVNEGA TREZORA in prehod v POSLOVNI PODATKOVNI TREZOR

Tako imamo informacije o pomembnosti podatkov za vse satelite v vsakem trenutku. Z uporabo JOIN-ov v tabelo PIT lahko popolnoma odpravimo ugnezdene poizvedbe, seveda pod pogojem, da se PIT polni vsak dan in brez vrzeli. Tudi če so v PIT vrzeli, lahko najnovejše podatke dobite samo z eno ugnezdeno poizvedbo do samega PIT-a. Ena ugnezdena poizvedba bo obdelana hitreje kot ugnezdene poizvedbe za vsak satelit.

MOST

Tabele BRIDGE se uporabljajo tudi za poenostavitev analitičnih poizvedb. Kar pa se razlikuje od PIT-a, je sredstvo za poenostavitev in pospešitev zahtev med različnimi vozlišči, povezavami in njihovimi sateliti.

Tabela vsebuje vse potrebne ključe za vse satelite, ki se pogosto uporabljajo v poizvedbah. Poleg tega lahko po potrebi zgoščene poslovne ključe dopolnite s ključi v besedilni obliki, če so za analizo potrebna imena ključev.

Dejstvo je, da bo brez uporabe BRIDGE v procesu sprejemanja podatkov, ki se nahajajo v satelitih, ki pripadajo različnim vozliščem, potrebno narediti JOIN ne le samih satelitov, temveč tudi povezav, ki povezujejo vozlišča.

Prisotnost ali odsotnost BRIDGE je določena s konfiguracijo pomnilnika in potrebo po optimizaciji hitrosti izvajanja poizvedbe. Težko je najti univerzalen primer BRIGE.

VNAPREJ DOLOČENE IZPELJAVE

Druga vrsta objektov, ki nas približajo TEZORU POSLOVNIH PODATKOV, so tabele, ki vsebujejo vnaprej izračunane kazalnike. Takšne tabele so zelo pomembne za poslovanje, saj vsebujejo informacije, agregirane po danih pravilih in omogočajo razmeroma enostaven dostop do njih.

Z arhitekturnega vidika PREDEFINED DERIVATIONS niso nič drugega kot še en satelit določenega vozlišča. Tako kot navaden satelit vsebuje poslovni ključ in datum nastanka zapisa v satelitu. Tu pa se podobnosti končajo. Nadaljnjo sestavo atributov takšnega "specializiranega" satelita določijo poslovni uporabniki na podlagi najbolj priljubljenih, vnaprej izračunanih indikatorjev.

Središče, ki vsebuje informacije o zaposlenem, lahko na primer vključuje satelit z indikatorji, kot so:

  • Minimalna plača;
  • Najvišja plača;
  • Povprečna plača;
  • Kumulativna vsota obračunanih plač itd.

Logično je, da v tabelo PIT istega vozlišča vključite VNAPREJ DEFINIRANE IZPELJAVE, potem lahko enostavno pridobite podatkovne rezine za zaposlenega na točno določen datum.

ZAKLJUČEK

Kot kaže praksa, je uporaba DATA VAULT s strani poslovnih uporabnikov nekoliko težavna iz več razlogov:

  • Koda poizvedbe je zapletena in okorna;
  • Obilje JOIN-jev vpliva na uspešnost poizvedb;
  • Pisanje analitičnih poizvedb zahteva izjemno znanje načrtovanja shranjevanja.

Za poenostavitev dostopa do podatkov je DATA VAULT razširjen z dodatnimi objekti:

  • PIT (point in time) tabele;
  • mize BRIDGE;
  • VNAPREJ DOLOČENE IZPELJAVE.

Naslednji članek Po mojem mnenju nameravam povedati najbolj zanimivo stvar za tiste, ki delajo z BI. Predstavil bom načine za ustvarjanje tabel dejstev in dimenzijskih tabel na podlagi DATA VAULT.

Materiali članka temeljijo na:

  • Na publikacije Kenta Graziano, ki poleg podrobnega opisa vsebuje modelne diagrame;
  • Knjiga: "Gradnja razširljivega podatkovnega skladišča z DATA VAULT 2.0";
  • Članek Osnove podatkovnega trezorja.

Vir: www.habr.com

Dodaj komentar