Pagbuo ng DATA VAULT at paglipat sa BUSINESS DATA VAULT

Sa nakaraang artikulo, napag-usapan ko ang tungkol sa mga pangunahing kaalaman ng DATA VAULT, inilarawan ang mga pangunahing elemento ng DATA VAULT at ang kanilang layunin. Sa puntong ito, ang paksa ng DATA VAULT ay hindi maituturing na ubos na, kinakailangang pag-usapan ang mga susunod na hakbang sa ebolusyon ng DATA VAULT.

At sa artikulong ito, tututukan ko ang pagbuo ng DATA VAULT at ang paglipat sa BUSINESS DATA VAULT o simpleng BUSINESS VAULT.

Mga dahilan ng paglitaw ng BUSINESS DATA VAULT

Dapat tandaan na ang DATA VAULT, na may ilang mga kalakasan, ay walang mga pagkukulang nito. Ang isa sa mga kakulangan na ito ay ang kahirapan sa pagsulat ng mga analytical na query. Ang mga query ay may malaking bilang ng mga JOIN, ang code ay mahaba at masalimuot. Gayundin, ang data na pumapasok sa DATA VAULT ay hindi napapailalim sa anumang mga pagbabago, samakatuwid, mula sa punto ng negosyo, ang DATA VAULT sa purong anyo nito ay walang walang kundisyong halaga.

Upang maalis ang mga pagkukulang na ito, ang pamamaraan ng DATA VAULT ay pinalawak ng mga elemento tulad ng:

  • Mga talahanayan ng PIT (point in time);
  • mga talahanayan ng BRIDGE;
  • PREDEFINED DERIVATIONS.

Tingnan natin ang layunin ng mga elementong ito.

Mga talahanayan ng PIT

Bilang isang panuntunan, ang isang bagay sa negosyo (HUB) ay maaaring maglaman ng data na may iba't ibang mga rate ng pag-update, halimbawa, kung pinag-uusapan natin ang tungkol sa data na nagpapakilala sa isang tao, maaari nating sabihin na ang impormasyon tungkol sa isang numero ng telepono, address o email ay may mas mataas na rate ng pag-update kaysa sabihin, buong pangalan, mga detalye ng pasaporte, marital status o kasarian.

Samakatuwid, kapag tinutukoy ang mga satellite, dapat isaisip ng isa ang dalas ng kanilang pag-renew. Bakit ito mahalaga?

Kung mag-iimbak ka ng mga attribute na may iba't ibang mga rate ng pag-update sa parehong talahanayan, kakailanganin mong magdagdag ng isang row sa talahanayan sa tuwing ina-update ang pinaka-madalas na pagbabagong katangian. Bilang isang resulta, mayroong isang pagtaas sa dami ng puwang sa disk, isang pagtaas sa oras ng pagpapatupad ng mga query.

Ngayong pinaghiwalay na natin ang mga satellite ayon sa rate ng pag-update, at maaari tayong mag-load ng data sa mga ito nang hiwalay, kailangan nating tiyakin na makakakuha tayo ng up-to-date na data. Mas mabuti nang hindi gumagamit ng mga hindi kinakailangang JOIN.

Hayaan akong ipaliwanag, halimbawa, kailangan mong makakuha ng up-to-date (sa petsa ng huling update) na impormasyon mula sa mga satellite na may iba't ibang mga rate ng pag-update. Upang gawin ito, kakailanganin mo hindi lamang na gumawa ng isang SUMALI, ngunit din upang lumikha ng ilang mga nested query (para sa bawat satellite na naglalaman ng impormasyon) na may pagpipilian ng maximum na petsa ng pag-update MAX (Petsa ng pag-update). Sa bawat bagong SUMALI, lumalaki ang naturang code, at napakabilis na nagiging mahirap maunawaan.

Ang talahanayan ng PIT ay idinisenyo upang pasimplehin ang mga naturang query, ang mga talahanayan ng PIT ay pinupunan nang sabay-sabay sa pagsusulat ng bagong data sa DATA VAULT. PIT table:

Pagbuo ng DATA VAULT at paglipat sa BUSINESS DATA VAULT

Kaya, mayroon kaming impormasyon tungkol sa kaugnayan ng data para sa lahat ng satellite sa bawat punto ng oras. Gamit ang mga JOIN sa talahanayan ng PIT, maaari nating ganap na alisin ang mga nested na query, siyempre sa kondisyon na ang PIT ay napupunan araw-araw at walang mga puwang. Kahit na may mga gaps sa PIT, makakakuha ka lang ng up-to-date na data gamit ang isang nested query sa PIT mismo. Ang isang nested query ay gagana nang mas mabilis kaysa sa nested query para sa bawat satellite.

BRIDGE

Ginagamit din ang mga talahanayan ng BRIDGE upang pasimplehin ang mga analytical na query. Gayunpaman, ang pagkakaiba sa PIT ay isang paraan ng pagpapasimple at pagpapabilis ng mga kahilingan sa pagitan ng iba't ibang hub, link at kanilang mga satellite.

Ang talahanayan ay naglalaman ng lahat ng kinakailangang key para sa lahat ng satellite na kadalasang ginagamit sa mga query. Bilang karagdagan, kung kinakailangan, ang mga na-hash na susi ng negosyo ay maaaring dagdagan ng mga susi sa anyo ng teksto, kung ang mga pangalan ng mga susi ay kailangan para sa pagsusuri.

Ang katotohanan ay nang hindi gumagamit ng BRIDGE, sa proseso ng pagkuha ng data na matatagpuan sa mga satellite na kabilang sa iba't ibang mga hub, kinakailangan na SUMALI hindi lamang sa mga satellite mismo, kundi pati na rin sa mga link na kumukonekta sa mga hub.

Ang presensya o kawalan ng BRIDGE ay tinutukoy ng pagsasaayos ng imbakan, ang pangangailangan na i-optimize ang bilis ng pagpapatupad ng query. Mahirap makabuo ng isang pangkalahatang halimbawa ng BRIGE.

PREDEFINED DERIVATIONS

Ang isa pang uri ng mga bagay na naglalapit sa atin sa BUSINESS DATA VAULT ay mga talahanayan na naglalaman ng mga paunang nakalkulang indicator. Ang ganitong mga talahanayan ay talagang mahalaga para sa negosyo, naglalaman ang mga ito ng impormasyong pinagsama-sama ayon sa ibinigay na mga patakaran at ginagawa itong medyo madaling ma-access.

Sa arkitektura, ang PREDEFINED DERIVATIONS ay hindi hihigit sa isa pang satellite ng isang partikular na hub. Ito, tulad ng isang regular na satellite, ay naglalaman ng isang susi ng negosyo at ang petsa na ginawa ang rekord sa satellite. Gayunpaman, dito nagtatapos ang pagkakatulad. Ang karagdagang komposisyon ng mga katangian ng naturang "espesyalisadong" satellite ay tinutukoy ng mga gumagamit ng negosyo batay sa pinakasikat, paunang nakalkula na mga tagapagpahiwatig.

Halimbawa, ang isang hub na naglalaman ng impormasyon tungkol sa isang empleyado ay maaaring may kasamang satellite na may mga indicator tulad ng:

  • Pinakamababang pasahod;
  • Pinakamataas na suweldo;
  • Average na suweldo;
  • Pinagsama-samang kabuuan ng mga naipon na sahod, atbp.

Lohikal na isama ang PREDEFINED DERIVATIONS sa PIT table ng parehong hub, pagkatapos ay madali kang makakakuha ng mga slice ng data ng empleyado para sa isang partikular na petsa.

Konklusyon

Tulad ng ipinapakita ng kasanayan, ang paggamit ng DATA VAULT ng mga user ng negosyo ay medyo mahirap sa ilang kadahilanan:

  • Ang query code ay kumplikado at masalimuot;
  • Ang kasaganaan ng mga JOIN ay nakakaapekto sa pagganap ng query;
  • Ang pagsulat ng mga analytical na query ay nangangailangan ng isang natitirang kaalaman sa istraktura ng bodega.

Upang gawing simple ang pag-access ng data, ang DATA VAULT ay pinalawak ng mga karagdagang bagay:

  • Mga talahanayan ng PIT (point in time);
  • mga talahanayan ng BRIDGE;
  • PREDEFINED DERIVATIONS.

Susunod Artikulo Plano kong sabihin, sa aking opinyon, ang pinaka-kawili-wili para sa mga nagtatrabaho sa BI. Magpapakita ako ng mga paraan upang lumikha ng mga talahanayan - mga katotohanan at talahanayan - mga sukat batay sa DATA VAULT.

Ang mga materyales ng artikulo ay batay sa:

Pinagmulan: www.habr.com

Magdagdag ng komento