En la antaŭa artikolo, mi parolis pri la bazaĵoj de DATA VAULT, priskribis la ĉefajn elementojn de DATA VAULT kaj ilian celon. Je ĉi tiu punkto, la temo de DATA VAULT ne povas esti konsiderata elĉerpita, necesas paroli pri la sekvaj paŝoj en la evoluo de DATA VAULT.
Kaj en ĉi tiu artikolo, mi fokusiĝos pri la disvolviĝo de DATA VAULT kaj la transiro al BUSINESS DATA VAULT aŭ simple BUSINESS VAULT.
Kialoj por la apero de BUSINESS DATA VAULT
Oni devas rimarki, ke DATA VAULT, havanta certajn fortojn, ne estas sen siaj mankoj. Unu el ĉi tiuj malavantaĝoj estas la malfacileco por verki analizajn demandojn. Demandoj havas signifan nombron da JOIN-oj, la kodo estas longa kaj maloportuna. Ankaŭ, la datumoj, kiuj eniras la DATA VAULT, ne estas submetataj al ajnaj transformoj, tial, de komerca vidpunkto, DATA VAULT en sia pura formo ne havas senkondiĉan valoron.
Estas por forigi ĉi tiujn mankojn, ke la DATA VAULT-metodaro estis vastigita kun tiaj elementoj kiel:
- PIT (punkto en tempo) tabeloj;
- BRIDGE tabloj;
- PREDEFINITAS DERIVADOJ.
Ni rigardu pli proksime al la celo de ĉi tiuj elementoj.
PIT-tabloj
Ĝenerale, unu komerca objekto (HUB) povas enhavi datumojn kun malsamaj ĝisdatigaj tarifoj, ekzemple, se ni parolas pri datumoj karakterizantaj homon, ni povas diri, ke informoj pri telefonnumero, adreso aŭ retpoŝto havas pli altan ĝisdatigprocenton ol. diru, plena nomo, pasportdetaloj, edzeca stato aŭ sekso.
Tial, kiam oni determinas satelitojn, oni devas memori la oftecon de ilia renovigo. Kial ĝi estas grava?
Se vi stokas atributojn kun malsamaj ĝisdatigaj tarifoj en la sama tabelo, vi devos aldoni vicon al la tabelo ĉiufoje kiam la plej ofte ŝanĝita atributo estas ĝisdatigita. Kiel rezulto, estas pliiĝo en la kvanto de diskospaco, pliiĝo en la ekzekuttempo de petoj.
Nun kiam ni apartigis la satelitojn per ĝisdatigo, kaj ni povas ŝargi datumojn en ili sendepende, ni devas certigi, ke ni povas akiri ĝisdatigitajn datumojn. Pli bone sen uzi nenecesajn ALIGojn.
Mi klarigu, ekzemple, ke vi devas ricevi ĝisdatigitajn (ĝis la dato de la lasta ĝisdatigo) informojn de satelitoj kun malsamaj ĝisdatigaj tarifoj. Por fari tion, vi devos ne nur fari ALIGON, sed ankaŭ krei plurajn nestitajn demandojn (por ĉiu satelito enhavanta informojn) kun elekto de la maksimuma ĝisdato-dato MAX (Dato de ĝisdatigo). Kun ĉiu nova JOIN, tia kodo kreskas, kaj tre rapide fariĝas malfacile komprenebla.
La PIT-tabelo estas dizajnita por simpligi tiajn demandojn, PIT-tabeloj estas plenigitaj samtempe kiam novaj datenoj estas skribitaj al la DATA VOLVO. PIT-tablo:
Tiel, ni havas informojn pri la graveco de datenoj por ĉiuj satelitoj ĉe ĉiu punkto en tempo. Uzante JOINojn sur la PIT-tabelo, ni povas tute forigi nestitajn demandojn, kompreneble kun la kondiĉo, ke la PIT estas plenigita ĉiutage kaj sen mankoj. Eĉ se estas mankoj en la PIT, vi povas nur akiri ĝisdatajn datumojn uzante unu nestitan demandon al la PIT mem. Unu nesta demando funkcios pli rapide ol nestitaj demandoj por ĉiu satelito.
PONTO
BRIDGE-tabeloj ankaŭ estas uzataj por simpligi analizajn demandojn. Tamen, la diferenco de PIT estas rimedo por simpligi kaj akceli petojn inter diversaj naboj, ligiloj kaj iliaj satelitoj.
La tabelo enhavas ĉiujn necesajn ŝlosilojn por ĉiuj satelitoj, kiuj estas ofte uzataj en demandoj. Krome, se necese, haŝitaj komercaj ŝlosiloj povas esti kompletigitaj per ŝlosiloj en teksta formo, se la nomoj de la ŝlosiloj estas necesaj por analizo.
La fakto estas, ke sen uzi BRIDGE, en la procezo de akiro de datumoj lokitaj en satelitoj apartenantaj al malsamaj naboj, estos necese ALIGI ne nur al la satelitoj mem, sed ankaŭ al la ligiloj ligantaj la naboj.
La ĉeesto aŭ foresto de BRIDGE estas determinita de la konserva agordo, la bezono optimumigi la rapidecon de demanda ekzekuto. Estas malfacile elpensi universalan ekzemplon de BRIGE.
PREDEFINITAS DERIVADOJ
Alia speco de objektoj, kiuj proksimigas nin al BUSINESS DATA VAULT, estas tabeloj enhavantaj antaŭkalkulitajn indikilojn. Tiaj tabeloj estas vere gravaj por komerco, ili enhavas informojn kunigitajn laŭ donitaj reguloj kaj faras ĝin relative facile alirebla.
Arkitekture, PREDEFINITAS DERIVADOJ estas nenio pli ol alia satelito de certa nabo. Ĝi, kiel regula satelito, enhavas komercan ŝlosilon kaj la daton, kiam la rekordo estis kreita en la satelito. Ĉi tie tamen finiĝas la similecoj. La plia konsisto de la atributoj de tia "specialigita" satelito estas determinita de komercaj uzantoj surbaze de la plej popularaj, antaŭkalkulitaj indikiloj.
Ekzemple, nabo enhavanta informojn pri dungito povas inkluzivi sateliton kun indikiloj kiel ekzemple:
- Minimuma salajro;
- Maksimuma salajro;
- Meza salajro;
- Akumula totalo de akumulitaj salajroj, ktp.
Estas logike inkluzivi PREDEFINITITAJ DERIVAĴOJN en la PIT-tabelo de la sama nabo, tiam vi povas facile akiri dungitajn datumtranĉaĵojn por specifa dato.
KONKLUJOJ
Kiel praktiko montras, la uzo de DATA VAULT de komercaj uzantoj estas iom malfacila pro pluraj kialoj:
- La demandkodo estas kompleksa kaj maloportuna;
- La abundo de JOIN-oj influas demandan rendimenton;
- Verki analizajn demandojn postulas elstaran scion pri la stokstrukturo.
Por simpligi datumaliron, DATA VAULT estas etendita kun kromaj objektoj:
- PIT (punkto en tempo) tabeloj;
- BRIDGE tabloj;
- PREDEFINITAS DERIVADOJ.
Poste Mi planas rakonti, laŭ mi, la plej interesan por tiuj, kiuj laboras kun BI. Mi prezentos manierojn krei tabelojn - faktojn kaj tabelojn - dimensiojn bazitajn sur DATA VAULT.
La materialoj de la artikolo baziĝas sur:
- En Kenta Graziano, kiu, krom detala priskribo, enhavas modelajn diagramojn;
- Libro: "Konstruado de Skalebla Datuma Stokejo kun DATA VAULT 2.0";
- Artikolo .
fonto: www.habr.com