Ngembangake fasilitas panyimpenan minangka tugas sing dawa lan serius.
Kathah ing gesang project gumantung carane uga model obyek lan struktur dhasar wis panginten metu ing wiwitan.
Pendekatan sing ditrima umum wis lan tetep dadi macem-macem varian kanggo nggabungake skema bintang karo wangun normal katelu. Minangka aturan, miturut prinsip: data awal - 3NF, showcases - lintang. Pendekatan iki, sing diuji wektu lan didhukung dening riset akeh, minangka sing pertama (lan kadhangkala mung) sing ana ing pikirane spesialis DWH sing berpengalaman nalika mikir babagan apa gudang analitis.
Ing sisih liya, bisnis umume lan syarat pelanggan utamane cenderung ganti kanthi cepet, lan data cenderung tuwuh "jero" lan "jembar". Lan ing kene ana kekurangan utama lintang - winates keluwesan.
Lan yen ing urip sing sepi lan nyaman minangka pangembang DWH dumadakan:
- tugas muncul "kanggo nindakake paling sethithik kanthi cepet, banjur kita bakal weruh";
- muncul proyek sing berkembang kanthi cepet, kanthi sambungan sumber anyar lan ngolah ulang model bisnis paling sethithik sepisan seminggu;
- pelanggan wis muncul sing ora ngerti apa sistem kudu katon lan apa fungsi pungkasanipun kudu nindakake, nanging wis siyap kanggo eksprimen lan terus-terusan nyaring asil sing dikarepake nalika terus-terusan nyedhaki;
- Manajer proyek teka karo kabar apik: "Lan saiki kita wis lincah!"
Utawa yen sampeyan mung kasengsem ing mangerteni carane liya sampeyan bisa mbangun fasilitas panyimpenan - welcome to cut!
Apa tegese "fleksibilitas"?
Pisanan, ayo nemtokake sifat apa sing kudu diduweni sistem supaya bisa diarani "fleksibel".
Dhewe, kudu dielingake yen sifat sing diterangake kudu ana hubungane khusus sistem, ora kanggo proses perkembangane. Mula, yen sampeyan pengin maca babagan Agile minangka metodologi pangembangan, luwih becik maca artikel liyane. Contone, ing kono, ing Habré, ana akeh bahan sing menarik (kayata и lan ).
Iki ora ateges proses pangembangan lan struktur gudang data ora ana hubungane. Sakabèhé, kudu luwih gampang ngembangake repositori Agile kanggo arsitektur tangkas. Nanging, ing laku, luwih kerep ana opsi karo Agile pembangunan DWH klasik miturut Kimbal lan DataVault - miturut Waterfall, saka seneng coincidences keluwesan ing loro formulir ing siji project.
Dadi, kemampuan apa sing kudu diduweni kanggo panyimpenan fleksibel? Ana telung titik ing kene:
- Pangiriman awal lan giliran cepet - Iki tegese saenipun asil bisnis pisanan (contone, laporan kerja pisanan) kudu dipikolehi sedini mungkin, yaiku, sadurunge kabeh sistem wis dirancang lan dileksanakake kanthi lengkap. Kajaba iku, saben revisi sakteruse uga kudu njupuk wektu sethithik.
- Refinement iteratif - iki tegese saben dandan sakteruse ngirim saenipun ora mengaruhi fungsi sing wis digunakake. Iki wayahe asring dadi ngipi elek paling gedhe ing proyèk gedhe - cepet utawa mengko, obyek individu wiwiti ndarbeni akeh sambungan sing dadi luwih gampang kanggo rampung mbaleni logika ing salinan toko saka kanggo nambah lapangan menyang meja ana. Lan yen sampeyan kaget yen nganalisa pengaruh modifikasi ing obyek sing wis ana bisa njupuk wektu luwih akeh tinimbang modifikasi kasebut, sampeyan bisa uga durung bisa nggarap gudang data gedhe ing perbankan utawa telekomunikasi.
- Ajeg adaptasi kanggo ngganti syarat bisnis - struktur obyek sakabèhé kudu dirancang ora mung njupuk menyang akun expansion bisa, nanging karo pangarep-arep sing arah expansion sabanjuré iki malah ora bisa ngimpi ing tataran desain.
Lan ya, nyukupi kabeh syarat kasebut ing siji sistem bisa (mesthi, ing kasus tartamtu lan sawetara leladen).
Ing ngisor iki aku bakal nimbang loro metodologi desain tangkas sing paling populer kanggo gudang data - Model jangkar и Gudang Data. Ditinggalake saka kurung ana teknik sing apik banget kayata, contone, EAV, 6NF (ing wangun murni) lan kabeh sing ana gandhengane karo solusi NoSQL - ora amarga padha luwih elek, lan ora amarga ing kasus iki artikel kasebut bakal ngancam bakal entuk. volume rata-rata disser. Mung kabeh iki ana hubungane karo solusi saka kelas sing rada beda - salah siji kanggo teknik sing bisa digunakake ing kasus tartamtu, preduli saka arsitektur sakabèhé saka project (kaya EAV), utawa kanggo global paradigma panyimpenan informasi liyane (kayata grafik database. lan opsi liyane NoSQL).
Masalah pendekatan "klasik" lan solusi ing metodologi fleksibel
Miturut pendekatan "klasik" Maksudku lintang lawas apik (preduli saka implementasine tartamtu saka lapisan ndasari, bisa pandherekipun Kimball, Inmon lan CDM ngapura kula).
1. Cardinalitas kaku sambungan
Model iki adhedhasar divisi data sing jelas ukuran и kanyatan. Lan iki, sial, logis - sawise kabeh, analisis data ing mayoritas kasus teka mudhun kanggo analisis indikator numerik tartamtu (fakta) ing bagean tartamtu (dimensi).
Ing kasus iki, sambungan antarane obyek ditetepake ing wangun hubungan antarane tabel nggunakake tombol manca. Iki katon cukup alami, nanging langsung nyebabake watesan keluwesan pisanan - definisi ketat saka kardinalitas sambungan.
Iki tegese ing tataran desain meja, sampeyan kudu nemtokake kanthi akurat kanggo saben pasangan obyek sing gegandhengan apa padha bisa hubungane minangka akeh-kanggo-akeh, utawa mung 1-kanggo-akeh, lan "ing arah". Iki langsung nemtokake tabel sing bakal duwe kunci utama lan sing duwe kunci asing. Ngganti sikap iki nalika syarat anyar ditampa paling kamungkinan mimpin kanggo reworking saka basa.
Contone, nalika ngrancang obyek "kuitansi awis", sampeyan, ngandelake sumpah departemen sales, nyedhiyakake kemungkinan tumindak siji promosi kanggo sawetara posisi mriksa (nanging ora kosok balene):
Lan sawise sawetara wektu, kolega ngenalake strategi marketing anyar sing bisa tumindak ing posisi sing padha sawetara promosi ing wektu sing padha. Lan saiki sampeyan kudu ngowahi tabel kanthi misahake hubungan kasebut dadi obyek sing kapisah.
(Kabeh obyek asale sing disambungake mriksa promosi saiki uga kudu ditambahake).
Hubungan ing Data Vault lan Model Jangkar
Nyingkiri kahanan iki dadi cukup prasaja: sampeyan ora kudu ngandelake departemen sales kanggo nindakake iki. kabeh sambungan pisanan disimpen ing tabel kapisah lan proses minangka akeh-kanggo-akeh.
Pendekatan iki diusulake Dan Linstedt minangka bagéan saka paradigma Gudang Data lan didhukung kanthi lengkap Lars Rönnbäck в Model Jangkar.
Akibaté, kita entuk fitur khas pisanan saka metodologi fleksibel:
Hubungan antarane obyek ora disimpen ing atribut entitas induk, nanging minangka jinis obyek sing kapisah.
В Gudang Data tabel linking kuwi diarani link, lan ing Model Jangkar - Tie. Sepisanan, padha banget, sanajan bedane ora mungkasi jeneng (sing bakal dibahas ing ngisor iki). Ing loro arsitektur, tabel link bisa nyambung nomer entitas apa wae (ora kudu 2).
Redundansi iki, ing pandang sepisanan, nyedhiyakake keluwesan sing signifikan kanggo modifikasi. Struktur kasebut dadi toleran ora mung kanggo owah-owahan ing kardinalitas tautan sing wis ana, nanging uga nambah sing anyar - yen saiki posisi cek uga duwe link menyang kasir sing mbukak, tampilan link kasebut mung bakal dadi. tambahan ing tabel sing wis ana tanpa mengaruhi obyek lan proses sing ana.
2. Duplikasi data
Masalah kapindho sing ditanggulangi dening arsitektur fleksibel kurang jelas lan ana ing wiwitan. Pengukuran tipe SCD2 (alon-alon ngganti dimensi saka jinis liya), sanajan ora mung.
Ing gudang klasik, ukuran biasane tabel sing ngemot kunci pengganti (minangka PK) lan sakumpulan kunci bisnis lan atribut ing kolom sing kapisah.
Yen dimensi ndhukung versi, wates validitas versi ditambahake menyang set standar lapangan, lan sawetara versi katon ing gudang kanggo siji baris ing sumber (siji kanggo saben owah-owahan ing atribut versi).
Yen dimensi ngemot paling ora siji atribut versi sing kerep diganti, jumlah versi dimensi kasebut bakal nyengsemake (sanajan atribut sing isih ana ora versi utawa ora tau diganti), lan yen ana sawetara atribut kasebut, jumlah versi bisa tuwuh kanthi eksponensial saka jumlahe. Dimensi iki bisa njupuk akeh ruang disk, sanajan akeh data sing disimpen mung duplikat nilai atribut sing ora bisa diganti saka baris liyane.
Ing wektu sing padha, uga asring banget digunakake denormalisasi - sawetara atribut sengaja disimpen minangka nilai, lan ora minangka link menyang buku referensi utawa dimensi liyane. Pendekatan iki nyepetake akses data, nyuda jumlah gabungan nalika ngakses dimensi.
Biasane iki ndadékaké kanggo informasi sing padha disimpen bebarengan ing sawetara panggonan. Contone, informasi babagan wilayah panggonan lan kategori klien bisa disimpen bebarengan ing dimensi "Klien" lan fakta "Tuku", "Pangiriman" lan "Telpon Pusat Telpon", uga ing "Klien - Manajer Klien". "meja link kab.
Umumé, sing diterangake ing ndhuwur ditrapake kanggo dimensi biasa (non-versi), nanging ing versi sing bisa uga duwe ukuran sing beda: tampilan versi anyar saka obyek (utamane ing retrospect) ndadékaké ora mung kanggo nganyari kabeh sing gegandhengan. tabel, nanging kanggo katon runtun versi anyar saka obyek related - nalika Tabel 1 digunakake kanggo mbangun Tabel 2, lan Tabel 2 digunakake kanggo mbangun Tabel 3, etc. Sanajan ora ana siji atribut saka Tabel 1 sing melu ing pambangunan Tabel 3 (lan atribut liyane saka Tabel 2 sing dipikolehi saka sumber liyane sing melu), versi konstruksi iki bakal nyebabake minimal kanggo overhead tambahan, lan maksimal nganti ekstra. versi ing Tabel 3. kang ora ana apa-apa apa karo, lan luwih mudhun chain.
3. Kompleksitas nonlinier saka rework
Ing wektu sing padha, saben storefront anyar sing dibangun ing basis liyane nambah jumlah panggonan ing ngendi data bisa "diverge" nalika owah-owahan ing ETL. Iki, ing siji, ndadékaké kanggo nambah ing kerumitan (lan durasi) saben revisi sakteruse.
Yen ing ndhuwur njlèntrèhaké sistem karo proses ETL arang diowahi, sampeyan bisa manggon ing paradigma kuwi - sampeyan mung kudu nggawe manawa modifikasi anyar wis bener digawe kanggo kabeh obyek related. Yen revisi kerep kedadeyan, kemungkinan ora sengaja "ilang" sawetara sambungan mundhak sacara signifikan.
Kajaba iku, kita nganggep manawa ETL "versi" luwih rumit tinimbang "non-versi", dadi angel banget kanggo ngindhari kesalahan nalika asring nganyari kabeh fasilitas iki.
Nyimpen obyek lan atribut ing Data Vault lan Model Jangkar
Pendekatan sing diusulake dening penulis arsitektur fleksibel bisa dirumusake kaya ing ngisor iki:
Sampeyan perlu kanggo misahake apa owah-owahan saka apa tetep padha. Yaiku, nyimpen kunci kanthi kapisah saka atribut.
Nanging, siji kudu ora bingung ora versi atribut karo ora owah: sing pisanan ora nyimpen riwayat owah-owahan, nanging bisa diganti (contone, nalika mbenerake kesalahan input utawa nampa data anyar); sing kapindho ora tau owah.
Sudut pandang beda-beda babagan apa sing bisa dianggep ora bisa diganti ing Data Vault lan Model Jangkar.
Saka sudut pandang arsitektur Gudang Data, bisa dianggep ora owah kabèh set tombol - alam (TIN saka organisasi, kode produk ing sistem sumber, etc.) lan surrogate. Ing kasus iki, atribut sing isih bisa dipérang dadi klompok miturut sumber lan / utawa frekuensi owah-owahan lan Njaga tabel kapisah kanggo saben klompok karo pesawat independen saka versi.
Ing paradigma Model Jangkar dianggep ora owah mung kunci pengganti intine. Kabeh liyane (kalebu kunci alami) mung kasus khusus saka atribut kasebut. ing ngendi kabeh atribut bebas saka saben liyane minangka standar, dadi kanggo saben atribut a meja kapisah.
В Gudang Data tabel sing ngemot tombol entitas diarani Hubami. Hub tansah ngemot set lapangan sing tetep:
- Tombol Entitas Alam
- Kunci pengganti
- Link menyang sumber
- Rekam nambah wektu
Kiriman ing Hubs tau ngganti lan ora duwe versi. Externally, hub banget padha karo tabel jinis ID-map digunakake ing sawetara sistem kanggo generate surrogates, Nanging, disaranake nggunakake hash saka pesawat saka tombol bisnis minangka surrogates ing Data Vault. Pendekatan iki simplifies loading sesambetan lan kawicaksanan saka sumber (ora perlu kanggo nggabungake hub kanggo njaluk surrogate, mung ngetung hash saka tombol alam), nanging bisa nimbulaké masalah liyane (gegandhengan, contone, kanggo tabrakan, cilik lan non-printable). karakter ing tombol senar, etc. .p.), Mulane iku ora umum ditampa.
Kabeh atribut entitas liyane disimpen ing tabel khusus sing disebut Satelit. Siji hub bisa duwe sawetara satelit sing nyimpen macem-macem atribut.
Distribusi atribut ing antarane satelit dumadi miturut prinsip owah-owahan bebarengan - ing siji satelit, atribut non-versi bisa disimpen (contone, tanggal lair lan SNILS kanggo individu), ing liyane - arang ngganti versi (contone, jeneng mburi lan nomer paspor), ing katelu - asring ganti. (contone, alamat pangiriman, kategori, tanggal pesenan pungkasan, lsp). Ing kasus iki, versi ditindakake ing tingkat satelit individu, lan dudu entitas sakabèhé, saéngga dianjurake kanggo nyebarake atribut supaya persimpangan versi ing siji satelit minimal (sing nyuda jumlah total versi sing disimpen. ).
Uga, kanggo ngoptimalake proses loading data, atribut sing dipikolehi saka macem-macem sumber asring kalebu ing satelit individu.
Satelit komunikasi karo Hub liwat kunci asing (sing cocog karo kardinalitas 1-kanggo-akeh). Iki tegese sawetara nilai atribut (contone, sawetara nomer telpon kontak kanggo siji klien) didhukung dening arsitektur "standar" iki.
В Model Jangkar tabel sing nyimpen tombol disebut Jangkar. Lan padha tetep:
- Mung kunci pengganti
- Link menyang sumber
- Rekam nambah wektu
Tombol alam saka sudut pandang Model Jangkar dianggep atribut biasa. Opsi iki bisa uga katon luwih angel dingerteni, nanging menehi ruang lingkup sing luwih akeh kanggo ngenali obyek kasebut.
Contone, yen data babagan entitas sing padha bisa teka saka sistem sing beda-beda, saben-saben nggunakake kunci alami dhewe. Ing Data Vault, iki bisa nyebabake struktur sing rada rumit saka sawetara hub (siji saben sumber + versi master sing nggabungake), dene ing model Anchor, kunci alami saben sumber dadi atribut dhewe lan bisa digunakake nalika mbukak kanthi bebas saka kabeh liyane.
Nanging ana uga siji titik insidious kene: yen atribut saka sistem beda digabungake ing siji entitas, paling kamungkinan ana sawetara aturan "gluing", kanthi sistem kasebut kudu ngerti manawa cathetan saka macem-macem sumber cocog karo siji conto entitas kasebut.
В Gudang Data aturan iki paling kamungkinan bakal nemtokake tatanan "pengganti hub" entitas master lan ora ana pengaruh ing Hub sing nyimpen kunci sumber alam lan atribut asline. Yen ing sawetara titik owah-owahan aturan gabung (utawa atribut sing dileksanakake dianyari), iku bakal cukup kanggo ngowahi format hub surrogate.
В Model jangkar entitas kuwi paling kamungkinan bakal disimpen ing jangkar mung. Iki tegese kabeh atribut, ora preduli saka sumber apa wae, bakal digandhengake karo pengganti sing padha. Misahake rekaman sing digabung kanthi salah lan, ing umum, ngawasi relevansi penggabungan ing sistem kasebut bisa dadi luwih angel, utamane yen aturan kasebut cukup rumit lan kerep diganti, lan atribut sing padha bisa dipikolehi saka sumber sing beda-beda (sanajan mesthine bisa, amarga saben versi atribut nduweni pranala menyang sumbere).
Ing kasus apa wae, yen sistem sampeyan kudu ngetrapake fungsi kasebut deduplikasi, nggabungake rekaman lan unsur MDM liyane, iku worth mbayar manungsa waé khusus kanggo aspèk nyimpen tombol alam ing metodologi tangkas. Mesthine desain Data Vault sing luwih gedhe bakal dadi luwih aman babagan kesalahan gabungan.
Model jangkar uga menehi jinis obyek tambahan disebut Simpul iku ateges khusus jinis degenerate jangkar, sing bisa ngemot mung siji atribut. Node kasebut mesthine digunakake kanggo nyimpen direktori sing rata (contone, jender, status perkawinan, kategori layanan pelanggan, lsp.). Beda karo Jangkar, Knot ora duwe tabel atribut sing gegandhengan, lan mung atribut (jeneng) tansah disimpen ing meja sing padha karo tombol. Node disambungake menyang Jangkar kanthi tabel dasi (Tie) kanthi cara sing padha karo Jangkar sing disambungake.
Ora ana pendapat sing jelas babagan panggunaan Nodes. Tuladhane, , sing aktif nyengkuyung panggunaan Model Jangkar ing Rusia, percaya (ora wajar) yen ora ana buku referensi siji-sijine bisa nyatakake kanthi pasti tansah bakal statis lan siji-tingkat, supaya iku luwih apik kanggo langsung nggunakake jangkar lengkap kanggo kabeh obyek.
Bentenane penting liyane antarane Data Vault lan model Anchor yaiku kasedhiyan atribut saka sambungan:
В Gudang Data Link minangka obyek lengkap sing padha karo Hubs, lan bisa diduweni atribut dhewe. ing Model jangkar Link digunakake mung kanggo nyambung jangkar lan ora bisa duwe atribut dhewe. Bedane iki nyebabake pendekatan pemodelan sing beda banget kanyatan, kang bakal rembugan luwih.
Panyimpenan kasunyatan
Sadurunge iki, kita ngomong utamane babagan model pangukuran. Kasunyatane rada kurang jelas.
В Gudang Data obyek khas kanggo nyimpen kanyatan yaiku Link, ing satelit sing ditambahake indikator nyata.
Pendekatan iki katon intuisi. Nyedhiyakake akses gampang menyang indikator sing dianalisis lan umume padha karo tabel fakta tradisional (mung indikator sing disimpen ora ana ing tabel kasebut, nanging ing tabel "tangga"). Nanging ana uga pitfalls: salah sawijining modifikasi khas model - ekspansi kunci fakta - mbutuhake nambahake kunci manca anyar menyang Link. Lan iki, ing siji, "ngrusak" modularitas lan duweni potensi nimbulaké perlu kanggo modifikasi kanggo obyek liyane.
В Model jangkar Sambungan ora bisa duwe atribut dhewe, mula pendekatan iki ora bisa digunakake - pancen kabeh atribut lan indikator kudu disambung menyang siji jangkar tartamtu. Kesimpulan saka iki prasaja - Saben kasunyatan uga mbutuhake jangkar dhewe. Kanggo sawetara sing biasa kita ngerteni minangka kasunyatan, iki bisa uga katon alami - umpamane, kasunyatan tuku bisa dikurangi dadi obyek "pesenan" utawa "kuitansi", ngunjungi situs menyang sesi, lsp. Nanging ana uga kasunyatan sing ora gampang kanggo nemokake "obyek operator" alam - contone, sisa barang ing gudang ing awal saben dina.
Mulane, masalah modularitas nalika ngembangake kunci fakta ing model Anchor ora muncul (cukup mung nambah Hubungan anyar menyang Jangkar sing cocog), nanging ngrancang model kanggo nampilake fakta kurang jelas; Jangkar "artifisial" bisa uga katon. sing nampilake model obyek bisnis kanthi cara sing ora jelas.
Carane keluwesan wis ngrambah
Konstruksi asil ing loro kasus ngandhut Ngartekno luwih tabeltinimbang pangukuran tradisional. Nanging bisa uga njupuk papan disk Ngartekno kurang kanthi set atribut versi sing padha karo ukuran tradisional. Alami, ora ana sihir ing kene - kabeh babagan normalisasi. Kanthi nyebarake atribut ing Satelit (ing Data Vault) utawa tabel individu (Model Jangkar), kita nyuda (utawa ngilangi kabeh) duplikasi nilai sawetara atribut nalika ngganti liyane.
Kanggo Gudang Data winnings bakal gumantung ing distribusi atribut antarane Satelit, lan kanggo Model jangkar - meh proporsional langsung karo jumlah rata-rata versi saben obyek pangukuran.
Nanging, penghematan ruang minangka kauntungan penting, nanging ora utama, kanggo nyimpen atribut kanthi kapisah. Bebarengan karo panyimpenan kapisah saka sesambetan, pendekatan iki ndadekake toko desain modular. Iki tegese nambahake atribut individu lan kabeh area subyek anyar ing model kasebut katon kaya superstruktur liwat sakumpulan obyek sing wis ana tanpa ngganti. Lan iki sing ndadekake metodologi sing diterangake fleksibel.
Iki uga meh padha karo transisi saka produksi potongan menyang produksi massal - yen ing pendekatan tradisional saben tabel model unik lan mbutuhake perhatian khusus, banjur ing metodologi fleksibel wis dadi set standar "bagean". Ing tangan siji, ana luwih tabel, lan proses loading lan njupuk data kudu katon luwih rumit. Ing tangan liyane, padha dadi khas. Tegese bisa uga ana otomatis lan metadata mimpin. Pitakonan "kepiye carane kita bakal lay iku?", Jawaban sing bisa njupuk munggah bagean penting saka karya ing ngrancang dandan, saiki mung ora worth iku (uga pitakonan bab impact saka ngganti model ing proses kerja. ).
Iki ora ateges analis ora dibutuhake ing sistem kasebut - ana wong sing isih kudu nggarap set obyek kanthi atribut lan ngerteni ing endi lan carane mbukak kabeh. Nanging jumlah karya, uga kemungkinan lan biaya kesalahan, suda sacara signifikan. Loro-lorone ing tahap analisis lan sajrone pangembangan ETL, sing ing bagean sing penting bisa dikurangi kanggo nyunting metadata.
Sisi gelap
Kabeh sing kasebut ing ndhuwur ndadekake loro pendekatan kasebut pancen fleksibel, maju kanthi teknologi lan cocog kanggo perbaikan berulang. Mesthi, ana uga "laras ing ointment", kang aku wis bisa guess bab.
Dekomposisi data, sing ndasari modularitas arsitektur fleksibel, nyebabake paningkatan jumlah tabel lan, kanthi mangkono, nduwur sirah kanggo gabung nalika sampling. Kanggo entuk kabeh atribut ukuran, ing toko klasik, siji pilih cukup, nanging arsitektur sing fleksibel bakal mbutuhake seri gabungan. Kajaba iku, yen kabeh iki gabung kanggo laporan bisa ditulis luwih dhisik, analis sing wis biasa nulis SQL kanthi tangan bakal nandhang tikel kaping pindho.
Ana sawetara fakta sing nggawe kahanan iki luwih gampang:
Nalika nggarap dimensi gedhe, kabeh atribute meh ora tau digunakake bebarengan. Iki tegese bisa uga ana luwih sithik gabung tinimbang sing katon ing model kasebut. Data Vault uga bisa njupuk menyang akun frekuensi samesthine nuduhake nalika allocating atribut kanggo satelit. Ing wektu sing padha, Hub utawa Jangkar dhewe dibutuhake utamane kanggo ngasilake lan pemetaan pengganti ing tahap loading lan arang digunakake ing pitakon (iki utamane bener kanggo Jangkar).
Kabeh gabung karo kunci. Kajaba iku, cara sing luwih "dikompres" kanggo nyimpen data nyuda nduwur sirah tabel mindhai sing dibutuhake (contone, nalika nyaring kanthi nilai atribut). Iki bisa nyebabake kasunyatan manawa sampling saka database sing dinormalisasi kanthi akeh gabungan bakal luwih cepet tinimbang mindhai siji dimensi abot kanthi akeh versi saben baris.
Contone, ing kene Artikel kasebut ngemot tes komparatif sing rinci babagan kinerja model Anchor kanthi sampel saka siji tabel.
Kathah gumantung ing mesin. Akeh platform modern duwe mekanisme optimasi gabungan internal. Contone, MS SQL lan Oracle bisa "skip" gabung menyang tabel yen data ora digunakake ing ngendi wae kajaba kanggo gabung liyane lan ora mengaruhi pilihan final (tabel / eliminasi gabung), lan MPP Vertica , wis kabukten dadi mesin sing apik banget kanggo Model Jangkar, diwenehi sawetara optimasi manual saka rencana query. Ing sisih liya, nyimpen Model Jangkar, umpamane, ing Click House, sing duwe dhukungan gabungan sing winates, durung katon minangka ide sing apik banget.
Kajaba iku, kanggo loro arsitektur ana gerakane khusus, nggawe akses data luwih gampang (saka sudut pandang kinerja query lan kanggo pangguna pungkasan). Tuladhane, Tabel Point-In-Time ing Data Vault utawa fungsi tabel khusus ing model Anchor.
Total
Inti saka arsitektur fleksibel sing dianggep minangka modularitas "desain".
Iki properti sing ngidini:
- Sawise sawetara persiapan awal sing ana gandhengane karo penyebaran metadata lan nulis algoritma ETL dhasar, cepet nyedhiyani customer karo asil pisanan ing wangun saperangan saka laporan ngemot data saka mung sawetara obyek sumber. Ora perlu mikir kanthi lengkap (sanajan ing tingkat paling dhuwur) kabeh model obyek.
- Model data bisa diwiwiti (lan migunani) kanthi mung 2-3 obyek, banjur tuwuh alon-alon (babagan model Anchor Nikolai perbandingan apik karo miselium).
- Paling dandan, kalebu nggedhekake area subyek lan nambah sumber anyar ora mengaruhi fungsi ana lan ora nuduhke resiko bejat soko sing wis digunakake.
- Thanks kanggo dekomposisi dadi unsur standar, proses ETL ing sistem kasebut katon padha, tulisane cocog karo algoritma lan, pungkasane, otomatis.
Rega saka keluwesan iki kinerja. Iki ora ateges ora bisa entuk kinerja sing bisa ditampa ing model kasebut. Luwih asring tinimbang ora, sampeyan mung mbutuhake gaweyan lan perhatian luwih rinci kanggo entuk metrik sing dikarepake.
app
Jinis entitas Gudang Data
Informasi liyane babagan Data Vault:
Jinis entitas Model Jangkar
Rincian liyane babagan Model Jangkar:
Tabel ringkesan kanthi fitur umum lan beda saka pendekatan sing dianggep:
Source: www.habr.com