Хадгалах байгууламжийг хөгжүүлэх нь урт бөгөөд ноцтой ажил юм.
Төслийн амьдралын ихэнх хэсэг нь объектын загвар болон суурь бүтцийг эхэндээ хэр сайн бодож байгаагаас хамаарна.
Нийтээр хүлээн зөвшөөрөгдсөн хандлага нь одны бүдүүвчийг гурав дахь хэвийн хэлбэртэй хослуулах янз бүрийн хувилбарууд байсаар ирсэн бөгөөд хэвээр байна. Дүрмээр бол зарчмын дагуу: анхны өгөгдөл - 3NF, үзүүлэн - од. Цаг хугацаагаар туршсан, их хэмжээний судалгаагаар дэмжигдсэн энэхүү арга нь DWH-ийн туршлагатай мэргэжилтнүүдийн аналитик агуулах ямар байх ёстой талаар бодоход хамгийн түрүүнд (заримдаа цорын ганц) зүйл юм.
Нөгөөтэйгүүр, бизнес ерөнхийдөө, ялангуяа хэрэглэгчийн шаардлага хурдан өөрчлөгдөж, өгөгдөл нь "гүнзгий" болон "өргөн" өсөх хандлагатай байдаг. Эндээс л одны гол сул тал гарч ирдэг - хязгаарлагдмал уян хатан байдал.
Хэрэв таны DWH хөгжүүлэгчийн нам гүм, тухтай амьдралд гэнэт:
- "Ядаж ямар нэг зүйлийг хурдан хий, тэгвэл бид харах болно" гэсэн даалгавар гарч ирэв;
- Долоо хоногт ядаж нэг удаа шинэ эх сурвалжийг холбож, бизнесийн загварыг дахин боловсруулах хурдацтай хөгжиж буй төсөл гарч ирэв;
- систем нь ямар байх ёстойг, эцсийн дүндээ ямар функцийг гүйцэтгэх ёстойг мэдэхгүй ч туршилт хийж, хүссэн үр дүндээ байнга ойртохын зэрэгцээ байнга сайжруулахад бэлэн үйлчлүүлэгч гарч ирэв;
- Төслийн менежер "Одоо бид уян хатан боллоо!" Гэж сайхан мэдээ дуулгав.
Эсвэл та агуулахын агуулахыг хэрхэн яаж барьж болохыг олж мэдэхийг хүсч байвал зах зээлд тавтай морилно уу!
"Уян хатан байдал" гэж юу гэсэн үг вэ?
Эхлээд "уян хатан" гэж нэрлэгдэхийн тулд систем ямар шинж чанартай байх ёстойг тодорхойлъё.
Тодорхойлсон шинж чанарууд нь тусгайлан хамаарах ёстой гэдгийг тусад нь дурдах нь зүйтэй систем, үгүй үйл явц түүний хөгжил. Тиймээс, хэрэв та Agile-ийн талаар хөгжлийн арга зүй болгон уншихыг хүсч байвал бусад нийтлэлүүдийг уншсан нь дээр. Жишээлбэл, яг тэнд Хабре дээр маш олон сонирхолтой материал байдаг (жишээ нь и Тэгээд ).
Энэ нь мэдээллийн агуулахын хөгжүүлэлтийн үйл явц болон бүтэц нь огт хамааралгүй гэсэн үг биш юм. Ерөнхийдөө, Agile архитектурт зориулсан Agile репозиторыг хөгжүүлэх нь илүү хялбар байх ёстой. Гэсэн хэдий ч практик дээр Кимбал ба DataVault-ийн дагуу сонгодог DWH-ийн Agile хөгжүүлэлтийн сонголтууд байдаг - Хүрхрээний дагуу нэг төсөл дээр хоёр хэлбэрийн уян хатан байдлын аз жаргалтай давхцлаас илүү.
Тэгэхээр уян хатан хадгалалт ямар чадвартай байх ёстой вэ? Энд гурван цэг байна:
- Эрт хүргэлт, хурдан эргэлт - Энэ нь бизнесийн анхны үр дүнг (жишээлбэл, анхны ажлын тайланг) аль болох эрт, өөрөөр хэлбэл бүхэл бүтэн системийг бүрэн боловсруулж, хэрэгжүүлэхээс өмнө авах ёстой гэсэн үг юм. Түүнчлэн, дараагийн засвар бүр нь аль болох бага хугацаа шаардагдах ёстой.
- Давталттай сайжруулалт - энэ нь дараагийн сайжруулалт бүр аль хэдийн ажиллаж байгаа функцэд нөлөөлөхгүй байх ёстой гэсэн үг юм. Энэ мөч нь томоохон төслүүдийн хамгийн том хар дарсан зүүд болж хувирдаг - эрт орой хэзээ нэгэн цагт бие даасан объектууд маш олон холболттой болж эхэлдэг тул одоо байгаа хүснэгтэд талбар нэмэхээс илүү ойролцоох хуулбар дахь логикийг бүрэн давтах нь илүү хялбар болно. Хэрэв та одоо байгаа объектуудад сайжруулалт хийх нөлөөг шинжлэх нь сайжруулалтаас илүү их цаг зарцуулж байгаад гайхаж байгаа бол та банк, харилцаа холбооны томоохон мэдээллийн агуулахтай хараахан ажиллаж амжаагүй байх магадлалтай.
- Өөрчлөгдөж буй бизнесийн шаардлагад байнга дасан зохицох - объектын ерөнхий бүтцийг зөвхөн боломжит өргөтгөлийг харгалзан төлөвлөхөөс гадна дараагийн өргөтгөлийн чиглэлийг дизайны үе шатанд мөрөөдөж ч болохгүй гэсэн хүлээлттэй байх ёстой.
Тийм ээ, эдгээр бүх шаардлагыг нэг системд хангах боломжтой (мэдээжийн хэрэг, зарим тохиолдолд, зарим тайлбартай).
Доор би мэдээллийн агуулахын хамгийн алдартай хоёр аргыг авч үзэх болно. Зангууны загвар и Өгөгдлийн сан. Жишээлбэл, EAV, 6NF (цэвэр хэлбэрээр) болон NoSQL шийдлүүдтэй холбоотой бүх зүйл зэрэг маш сайн техникүүд хаалтанд үлджээ - энэ нь ямар нэгэн байдлаар муу учраас биш, тэр ч байтугай энэ тохиолдолд нийтлэл олж авах аюул заналхийлсэн учраас биш юм. дундаж диссерийн эзлэхүүн. Энэ бүхэн нь төслийн ерөнхий архитектураас үл хамааран тодорхой тохиолдлуудад ашиглаж болох арга техникүүд (EAV гэх мэт) эсвэл дэлхийн бусад мэдээлэл хадгалах парадигмуудтай (график мэдээллийн сан гэх мэт) арай өөр ангиллын шийдлүүдтэй холбоотой юм. болон бусад сонголтууд NoSQL).
"Сонгодог" аргын асуудлууд ба тэдгээрийн уян хатан арга зүй дэх шийдэл
"Сонгодог" арга барил гэж би хуучин сайн одыг хэлж байна (давхаргын тодорхой хэрэгжилтээс үл хамааран Кимбалл, Инмон, ЦДМ-ийн дагалдагчид намайг уучлах болтугай).
1. Холболтын хатуу кардинал байдал
Энэ загвар нь өгөгдлийг тодорхой хуваахад суурилдаг Хэмжээ и баримтууд. Энэ нь, хараал идсэн, логик юм - эцэст нь ихэнх тохиолдолд өгөгдлийн дүн шинжилгээ нь тодорхой хэсгүүдэд (хэмжээст) тодорхой тоон үзүүлэлтүүдийг (баримтуудыг) шинжлэхэд хүргэдэг.
Энэ тохиолдолд объектуудын хоорондын холболтыг гадаад түлхүүр ашиглан хүснэгт хоорондын харилцааны хэлбэрээр тогтооно. Энэ нь нэлээд байгалийн харагддаг, гэхдээ тэр даруй уян хатан байдлын анхны хязгаарлалтад хүргэдэг - холболтын үндсэн байдлын хатуу тодорхойлолт.
Энэ нь хүснэгтийн дизайны үе шатанд та хос объект тус бүрээр олон-олон, эсвэл зөвхөн 1-ээс олон гэсэн утгатай, аль чиглэлд хамааралтай болохыг нарийн тодорхойлох ёстой гэсэн үг юм. Энэ нь аль хүснэгтэд үндсэн түлхүүр, аль нь гадаад түлхүүртэй байхыг шууд тодорхойлдог. Шинэ шаардлага ирэх үед энэ хандлагыг өөрчлөх нь баазыг дахин боловсруулахад хүргэдэг.
Жишээлбэл, "бэлэн мөнгөний баримт" объектыг зохион бүтээхдээ та борлуулалтын хэлтсийн тангараг дээр тулгуурлан арга хэмжээ авах боломжийг тавьсан. хэд хэдэн шалгалтын албан тушаалд нэг дэвших (гэхдээ эсрэгээр биш):
Хэсэг хугацааны дараа хамт ажиллагсад нь ижил байр суурь дээр ажиллах боломжтой маркетингийн шинэ стратегийг нэвтрүүлэв нэгэн зэрэг хэд хэдэн урамшуулал. Одоо та харилцааг тусдаа объект болгон хуваах замаар хүснэгтүүдийг өөрчлөх хэрэгтэй.
(Одоо урамшууллын чектэй холбогдсон бүх үүсмэл объектуудыг сайжруулах шаардлагатай байна).
Data Vault болон Anchor загвар дахь харилцаа холбоо
Энэ нөхцөл байдлаас зайлсхийх нь маш энгийн зүйл болсон: үүнийг хийхийн тулд борлуулалтын хэлтэст итгэх шаардлагагүй. бүх холболтыг эхлээд тусдаа хүснэгтэд хадгалдаг мөн үүнийг олон-олон болгон боловсруулах.
Энэ аргыг санал болгосон Дан Линстедт парадигмын нэг хэсэг болгон Өгөгдлийн сан мөн бүрэн дэмжиж байна Ларс Рённбек в Зангуу загвар.
Үүний үр дүнд бид уян хатан аргачлалын анхны онцлог шинж чанарыг олж авдаг.
Объектуудын хоорондын харилцаа нь эцэг эхийн шинж чанаруудад хадгалагддаггүй, харин тусдаа төрлийн объект юм.
В Өгөгдлийн сан ийм холбох хүснэгтүүдийг гэж нэрлэдэг Холбоос, дотор нь Зангуу загвар - Tie. Эхлээд харахад тэд маш төстэй боловч тэдгээрийн ялгаа нь нэрээр дуусдаггүй (үүнийг доор авч үзэх болно). Архитектурын аль алинд нь холбоосын хүснэгтүүдийг холбож болно дурын тооны аж ахуйн нэгж (заавал 2 биш).
Энэхүү илүүдэл нь эхлээд харахад өөрчлөлт хийхэд ихээхэн уян хатан байдлыг бий болгодог. Ийм бүтэц нь одоо байгаа холбоосуудын үндсэн байдлын өөрчлөлтөд төдийгүй шинээр нэмэгдэхэд тэсвэртэй болдог - хэрэв одоо чекийн байрлал нь түүнийг нээсэн касстай холбоотой байвал ийм холбоосын дүр төрх зүгээр л болж хувирна. Одоо байгаа объект, процесст нөлөөлөхгүйгээр одоо байгаа хүснэгтүүд дээр нэмэлт.
2. Өгөгдлийн давхардал
Уян хатан архитектураар шийдсэн хоёр дахь асуудал нь тийм ч тодорхой бус бөгөөд эхний ээлжинд угаасаа байдаг. SCD2 төрлийн хэмжилт (хоёр дахь төрлийн хэмжээсийг аажмаар өөрчлөх), гэхдээ зөвхөн тэдгээр нь биш.
Сонгодог агуулахад хэмжээс нь ихэвчлэн орлуулагч түлхүүр (PK хэлбэрээр) болон тусдаа багана дахь бизнесийн түлхүүр, шинж чанаруудыг агуулсан хүснэгт юм.
Хэмжээ нь хувилбар гаргахыг дэмждэг бол хувилбарын хүчинтэй байдлын хил хязгаарыг стандарт талбарт нэмж оруулах ба эх сурвалжийн нэг мөрөнд хэд хэдэн хувилбарууд гарч ирнэ (хувилбарын шинж чанаруудын өөрчлөлт бүрт нэг).
Хэрэв хэмжээс нь дор хаяж нэг байнга өөрчлөгддөг хувилбартай шинж чанарыг агуулж байвал ийм хэмжигдэхүүний хувилбаруудын тоо гайхалтай байх болно (үлдсэн шинж чанарууд нь хувилбараар өөрчлөгдөөгүй эсвэл хэзээ ч өөрчлөгдөөгүй байсан ч) бөгөөд хэрэв хэд хэдэн ийм шинж чанарууд байгаа бол хувилбаруудын тоо тэдний тооноос экспоненциалаар өсдөг. Энэ хэмжээс нь ихээхэн хэмжээний дискний зай эзэлдэг ч хадгалдаг өгөгдлийн ихэнх нь бусад мөрүүдийн хувиршгүй шинж чанарын утгуудын хуулбар юм.
Үүний зэрэгцээ энэ нь маш олон удаа ашиглагддаг хэвийн бус байдал - зарим шинж чанаруудыг лавлах ном эсвэл өөр хэмжигдэхүүнтэй холбох холбоос биш харин үнэ цэнэ болгон зориудаар хадгалдаг. Энэ арга нь өгөгдлийн хандалтыг хурдасгаж, хэмжээст хандах үед нэгдэх тоог багасгадаг.
Ихэвчлэн энэ нь хүргэдэг ижил мэдээлэл хэд хэдэн газарт нэгэн зэрэг хадгалагддаг. Жишээлбэл, оршин суугаа бүс нутаг, үйлчлүүлэгчийн ангиллын талаархи мэдээллийг "Үйлчлүүлэгч" хэмжээсүүд болон "Худалдан авалт", "Хүргэлт", "Дуудлагын төвийн дуудлага" баримтууд, мөн "Үйлчлүүлэгч - Үйлчлүүлэгч менежер" хэсэгт нэгэн зэрэг хадгалах боломжтой. ” холбоос хүснэгт.
Ерөнхийдөө дээр дурьдсан зүйл нь ердийн (хувилбаргүй) хэмжигдэхүүнүүдэд хамаатай боловч хувилбарт нь өөр масштабтай байж болно: объектын шинэ хувилбар (ялангуяа эргэн харахад) нь зөвхөн холбогдох бүх зүйлийг шинэчлэхэд хүргэдэг. хүснэгтүүд, гэхдээ холбогдох объектуудын шинэ хувилбаруудын шатлалтай харагдах байдал - 1-р хүснэгтийг бүтээхэд 2-р хүснэгт, 2-р хүснэгтийг барихад 3-р хүснэгтийг ашиглах үед гэх мэт. Хүснэгт 1-ийн нэг ч шинж чанар 3-р хүснэгтийг бүтээхэд оролцоогүй байсан ч (мөн бусад эх сурвалжаас авсан Хүснэгт 2-ын бусад шинж чанаруудыг оролцуулсан) энэ бүтээцийг хувилбар болгох нь хамгийн багадаа нэмэлт зардал, хамгийн ихдээ нэмэлт зардалд хүргэдэг. 3-р хүснэгтэд байгаа хувилбарууд нь үүнтэй огт холбоогүй бөгөөд цаашлаад гинжин хэлхээнд.
3. Дахин боловсруулах шугаман бус нарийн төвөгтэй байдал
Үүний зэрэгцээ, өөр нэг дэлгүүрийн үндсэн дээр баригдсан шинэ дэлгүүрийн нүүр хуудас бүр нь ETL-д өөрчлөлт оруулах үед өгөгдөл "ялгах" газруудын тоог нэмэгдүүлдэг. Энэ нь эргээд дараагийн засвар бүрийн нарийн төвөгтэй байдал (болон үргэлжлэх хугацаа) нэмэгдэхэд хүргэдэг.
Хэрэв дээр дурдсан нь ховор өөрчлөгддөг ETL процесс бүхий системийг дүрсэлсэн бол та ийм парадигмд амьдрах боломжтой - та зөвхөн холбогдох бүх объектод шинэ өөрчлөлтүүдийг зөв хийсэн эсэхийг шалгах хэрэгтэй. Хэрэв засварууд байнга хийгдвэл хэд хэдэн холболтыг санамсаргүйгээр "алгах" магадлал эрс нэмэгддэг.
Нэмж дурдахад бид "хувилбартай" ETL нь "хувилбаргүй"-ээс хамаагүй илүү төвөгтэй гэдгийг харгалзан үзвэл энэ байгууламжийг бүхэлд нь байнга шинэчлэх үед алдаа гарахаас зайлсхийхэд хэцүү болно.
Data Vault болон Anchor Model-д объект болон шинж чанаруудыг хадгалах
Уян хатан архитектурын зохиогчдын санал болгож буй хандлагыг дараах байдлаар томъёолж болно.
Юу нь өөрчлөгддөг, юу нь хэвээр үлдэж байгааг ялгах шаардлагатай. Өөрөөр хэлбэл түлхүүрүүдийг шинж чанаруудаас тусад нь хадгална.
Гэсэн хэдий ч хүн андуурч болохгүй хувилбаргүй шинж чанар өөрчлөгдөөгүй: эхнийх нь өөрчлөлтийн түүхийг хадгалдаггүй, гэхдээ өөрчлөгдөж болно (жишээлбэл, оролтын алдааг засах эсвэл шинэ өгөгдөл хүлээн авах үед); хоёр дахь нь хэзээ ч өөрчлөгддөггүй.
Өгөгдлийн сан болон зангуу загварт яг юуг өөрчлөх боломжгүй гэж үзэж болох талаар үзэл бодлын өөр өөр байдаг.
Архитектурын үүднээс Өгөгдлийн сан, өөрчлөгдөөгүй гэж үзэж болно бүхэл бүтэн түлхүүрүүд - байгалийн (байгууллагын TIN, эх систем дэх бүтээгдэхүүний код гэх мэт) болон орлуулагч. Энэ тохиолдолд үлдсэн шинж чанаруудыг өөрчлөлтийн эх үүсвэр ба/эсвэл давтамжийн дагуу бүлэгт хувааж болно Бүлэг бүрийн хувьд тусдаа хүснэгтийг хөтөл бие даасан багц хувилбаруудтай.
Парадигмд Зангуу загвар өөрчлөгдөөгүй гэж үзнэ зөвхөн орлуулагч түлхүүр мөн чанар. Бусад бүх зүйл (байгалийн түлхүүрүүдийг оруулаад) түүний шинж чанаруудын зөвхөн онцгой тохиолдол юм. Хаана бүх шинж чанарууд нь анхдагчаар бие биенээсээ хамааралгүй байдаг, тиймээс шинж чанар бүрийн хувьд a тусдаа ширээ.
В Өгөгдлийн сан аж ахуйн нэгжийн түлхүүрүүдийг агуулсан хүснэгтүүдийг дууддаг Хубами. Hub нь үргэлж тогтмол талбаруудыг агуулдаг:
- Байгалийн нэгжийн түлхүүрүүд
- Орлогч түлхүүр
- Эх сурвалж руу холбох
- Нэмэх цагийг тэмдэглэ
Hubs дахь нийтлэлүүд хэзээ ч өөрчлөгдөхгүй, ямар ч хувилбар байхгүй. Гаднах байдлаар, төвүүд нь орлуулагч үүсгэхийн тулд зарим системд ашигладаг ID-map төрлийн хүснэгтүүдтэй маш төстэй байдаг ч Data Vault-д орлуулагч болгон бизнесийн түлхүүрүүдийн багцыг ашиглахыг зөвлөж байна. Энэ арга нь эх сурвалжаас ачаалах харилцаа, шинж чанарыг хялбаршуулдаг (орлон тоглогч авахын тулд төв рүү нэгдэх шаардлагагүй, зүгээр л байгалийн түлхүүрийн хэшийг тооцоолно), гэхдээ бусад асуудал үүсгэж болно (жишээлбэл, мөргөлдөх, тохиолдол, хэвлэх боломжгүй гэх мэт). тэмдэгт тэмдэгтүүд гэх мэт .p.), тиймээс үүнийг ерөнхийд нь хүлээн зөвшөөрдөггүй.
Бусад бүх аж ахуйн нэгжийн шинж чанарууд гэж нэрлэгддэг тусгай хүснэгтэд хадгалагддаг Хиймэл дагуулууд. Нэг төв нь өөр өөр шинж чанаруудыг хадгалах хэд хэдэн хиймэл дагуултай байж болно.
Хиймэл дагуулуудын хооронд шинж чанаруудын хуваарилалт нь зарчмын дагуу явагддаг хамтарсан өөрчлөлт - нэг хиймэл дагуул дээр хувилбаргүй шинж чанаруудыг хадгалах боломжтой (жишээлбэл, төрсөн огноо, хувь хүний SNILS), нөгөөд - ховор өөрчлөгддөг хувилбарууд (жишээлбэл, овог, паспортын дугаар), гуравдугаарт - байнга өөрчлөгддөг. (жишээ нь, хүргэх хаяг, ангилал, сүүлчийн захиалгын огноо гэх мэт). Энэ тохиолдолд хувилбарыг бүхэлд нь биш харин бие даасан хиймэл дагуулын түвшинд хийдэг тул нэг хиймэл дагуулын доторх хувилбаруудын огтлолцол хамгийн бага байхын тулд шинж чанаруудыг хуваарилахыг зөвлөж байна (энэ нь хадгалагдсан хувилбаруудын нийт тоог бууруулдаг). ).
Мөн өгөгдөл ачаалах процессыг оновчтой болгохын тулд янз бүрийн эх сурвалжаас олж авсан шинж чанаруудыг ихэвчлэн хиймэл дагуулуудад оруулдаг.
Хиймэл дагуулууд нь Hub-тай дамжуулан холбогддог гадаад түлхүүр (энэ нь 1-ээс олон кардиналтай тохирч байна). Энэ нь олон шинж чанарын утгыг (жишээлбэл, нэг үйлчлүүлэгчийн олон холбоо барих утасны дугаар) энэхүү "өгөгдмөл" архитектурт дэмждэг гэсэн үг юм.
В Зангуу загвар Түлхүүрийг хадгалах хүснэгтүүдийг дууддаг Зангуу. Мөн тэд хадгалдаг:
- Зөвхөн орлуулагч түлхүүрүүд
- Эх сурвалж руу холбох
- Нэмэх цагийг тэмдэглэ
Зангуу загварын үүднээс байгалийн түлхүүрүүдийг авч үздэг ердийн шинж чанарууд. Энэ сонголт нь ойлгоход илүү хэцүү мэт санагдаж болох ч энэ нь объектыг тодорхойлоход илүү өргөн боломжийг олгодог.
Жишээлбэл, нэг аж ахуйн нэгжийн тухай мэдээлэл нь өөр өөр системээс ирж болох бөгөөд тус бүр нь өөрийн гэсэн натурал түлхүүрийг ашигладаг. Data Vault-д энэ нь хэд хэдэн төвүүдийн нэлээд төвөгтэй бүтцийг бий болгоход хүргэдэг (эх сурвалж тус бүрд нэг + нэгтгэх мастер хувилбар), харин Anchor загварт эх үүсвэр бүрийн байгалийн түлхүүр нь өөрийн гэсэн шинж чанарт багтдаг бөгөөд үүнийг бие даан ачаалах үед ашиглаж болно. бусад бүх хүмүүс.
Гэхдээ энд бас нэг нууцлаг зүйл бий: хэрэв өөр өөр системүүдийн шинж чанаруудыг нэг байгууллагад нэгтгэсэн бол зарим нь байж магадгүй юм. "наалт" хийх дүрэм, үүгээр систем нь өөр өөр эх сурвалжаас авсан бүртгэл нь тухайн байгууллагын нэг инстанцтай тохирч байгааг ойлгох ёстой.
В Өгөгдлийн сан Эдгээр дүрмүүд нь формацийг тодорхойлох магадлалтай Мастер аж ахуйн нэгжийн "орлогч төв" байгалийн эх түлхүүрүүд болон тэдгээрийн анхны шинж чанаруудыг хадгалдаг Hub-д ямар ч байдлаар нөлөөлөхгүй. Хэзээ нэгэн цагт нэгтгэх дүрэм өөрчлөгдвөл (эсвэл түүнийг гүйцэтгэх шинж чанарууд шинэчлэгдвэл) орлуулагч төвүүдийг дахин форматлахад хангалттай.
В Зангууны загвар ийм аж ахуйн нэгж хадгалагдах магадлал өндөр цорын ганц зангуу. Энэ нь ямар ч эх сурвалжаас үл хамааран бүх шинж чанарууд нь ижил орлуулагчтай холбоотой байх болно гэсэн үг юм. Алдаатай нэгтгэсэн бүртгэлийг салгах, ерөнхийдөө ийм системд нэгтгэх хамаарлыг хянах нь илүү хэцүү байх болно, ялангуяа дүрэм нь нэлээд төвөгтэй бөгөөд байнга өөрчлөгддөг бол ижил шинж чанарыг өөр өөр эх сурвалжаас олж авах боломжтой (гэхдээ мэдээжийн хэрэг боломжтой, учир нь атрибутын хувилбар бүр өөрийн эх сурвалжтай холбоосыг хадгалдаг).
Ямар ч тохиолдолд, хэрэв таны систем функцийг хэрэгжүүлэх ёстой бол давхардал, бүртгэл болон бусад MDM элементүүдийг нэгтгэх, Agile аргачлалд байгалийн түлхүүрүүдийг хадгалах асуудалд онцгой анхаарал хандуулах нь зүйтэй. Том хэмжээтэй Data Vault загвар нь нэгдэх алдааны хувьд гэнэт илүү аюулгүй байх магадлалтай.
Зангууны загвар гэж нэрлэгддэг нэмэлт объектын төрлийг мөн өгдөг Зангилаа энэ нь үндсэндээ онцгой юм муудсан төрлийн зангуу, энэ нь зөвхөн нэг шинж чанарыг агуулж болно. Зангилаанууд нь хавтгай лавлах (жишээ нь, хүйс, гэр бүлийн байдал, харилцагчийн үйлчилгээний ангилал гэх мэт) хадгалахад ашиглагдах ёстой. Зангуугаас ялгаатай нь зангилаа холбоотой шинж чанарын хүснэгт байхгүй байна, мөн түүний цорын ганц шинж чанар (нэр) нь түлхүүртэй нэг хүснэгтэд үргэлж хадгалагддаг. Зангилаанууд нь зангуунууд хоорондоо холбогддогтой адил зангиа хүснэгтээр (Tie) холбогддог.
Зангилааны хэрэглээний талаар тодорхой санал бодол байхгүй байна. Жишээлбэл, Орос улсад зангууны загварыг ашиглахыг идэвхтэй сурталчилж буй , (үндэслэлгүй биш) нэг лавлах номонд ч үүнийг баттай хэлж чадахгүй гэж үзэж байна. үргэлж Энэ нь статик, нэг түвшний байх тул бүх объектод нэн даруй бүрэн эрхт Anchor ашиглах нь дээр.
Data Vault болон Anchor загвар хоёрын өөр нэг чухал ялгаа нь бэлэн байдал юм холболтын шинж чанарууд:
В Өгөгдлийн сан Холбоосууд нь Hub-тай ижил бүрэн эрхт объект бөгөөд байж болно өөрийн шинж чанарууд. The Зангууны загвар Холбоосыг зөвхөн зангуу болон холбоход ашигладаг өөрийн гэсэн шинж чанартай байж болохгүй. Энэ ялгаа нь загварчлалын арга барилд ихээхэн ялгаатай байдаг баримтууд, цаашид хэлэлцэх болно.
Баримт хадгалах
Үүнээс өмнө бид хэмжилтийн загварчлалын талаар голчлон ярьсан. Баримт нь арай бага тодорхой байна.
В Өгөгдлийн сан баримт хадгалах ердийн объект юм Холбоос, тэдгээрийн хиймэл дагуулуудад бодит үзүүлэлтүүд нэмэгдсэн.
Энэ арга нь зөн совинтой юм шиг санагддаг. Энэ нь дүн шинжилгээ хийсэн үзүүлэлтүүдэд хялбар хандах боломжийг олгодог бөгөөд ерөнхийдөө уламжлалт баримтын хүснэгттэй төстэй (зөвхөн үзүүлэлтүүдийг хүснэгтэд биш, харин "хөрш" хүснэгтэд хадгалдаг). Гэхдээ бас бэрхшээлүүд байдаг: загварын ердийн өөрчлөлтүүдийн нэг нь баримтын түлхүүрийг өргөжүүлэх шаардлагатай байдаг. Link-д шинэ гадаад түлхүүр нэмж байна. Энэ нь эргээд модулийг "эвдэж", бусад объектод өөрчлөлт оруулах хэрэгцээг үүсгэж болзошгүй юм.
В Зангууны загвар Холболт нь өөрийн гэсэн шинж чанартай байж болохгүй, тиймээс энэ арга нь ажиллахгүй - үнэхээр бүх шинж чанар, үзүүлэлтүүд нь тодорхой нэг зангуутай холбогдсон байх ёстой. Эндээс гаргасан дүгнэлт нь энгийн - Баримт бүрт өөрийн гэсэн зангуу хэрэгтэй. Бидний зарим зүйлийг баримт болгон хүлээн зөвшөөрч дассан зүйлсийн хувьд энэ нь байгалийн юм шиг санагдаж магадгүй юм - жишээлбэл, худалдан авалтын баримтыг "захиалга" эсвэл "хүлээн авах" объект болгон төгс багасгаж, сайтад зочлох гэх мэт байж болно. Гэхдээ ийм байгалийн "тээвэрлэгч объект" -ийг олоход тийм ч хялбар биш баримтууд байдаг - жишээлбэл, өдөр бүрийн эхэнд агуулах дахь барааны үлдэгдэл.
Үүний дагуу Anchor загварт баримтын түлхүүрийг өргөжүүлэхэд модульчлагдсан асуудал гарахгүй (харгалзах Anchor-д шинэ харилцаа нэмэхэд л хангалттай), харин баримтуудыг харуулах загвар зохион бүтээх нь хоёрдмол утгагүй, "хиймэл" зангуу гарч ирж магадгүй юм. бизнесийн объектын загварыг тодорхой бус байдлаар харуулдаг.
Уян хатан байдал хэрхэн бий болдог
Хоёр тохиолдолд үүссэн барилгын ажилд агуулна мэдэгдэхүйц илүү ширээуламжлалт хэмжилтээс илүү. Гэхдээ авч магадгүй дискний зай мэдэгдэхүйц бага уламжлалт хэмжигдэхүүнтэй ижил хувилбартай шинж чанаруудтай. Мэдээжийн хэрэг, энд ид шид байхгүй - энэ нь хэвийн болгох явдал юм. Хиймэл дагуулууд (өгөгдлийн сан дахь) эсвэл бие даасан хүснэгтүүд (зангуу загвар) даяар шинж чанаруудыг түгээснээр бид багасгадаг (эсвэл бүрмөсөн устгадаг) бусдыг өөрчлөх үед зарим шинж чанаруудын утгын давхардал.
Хэрэгтэй Өгөгдлийн сан ялалт нь хиймэл дагуулуудын хооронд шинж чанаруудын хуваарилалтаас хамаарна Зангууны загвар - хэмжилтийн объектын хувилбаруудын дундаж тоотой бараг шууд пропорциональ байна.
Гэсэн хэдий ч зай хэмнэх нь шинж чанаруудыг тусад нь хадгалах нь чухал боловч гол давуу тал биш юм. Хамтдаа харилцаа тусдаа хадгалах, энэ арга нь дэлгүүр болгодог модульчлагдсан загвар. Энэ нь ийм загварт бие даасан шинж чанарууд болон бүхэл бүтэн шинэ сэдвийн хэсгүүдийг нэмэх нь иймэрхүү харагдаж байна гэсэн үг юм дээд бүтэц тэдгээрийг өөрчлөхгүйгээр одоо байгаа объектуудын багц дээр. Энэ нь тайлбарласан арга зүйг уян хатан болгодог зүйл юм.
Энэ нь мөн хэсэгчилсэн үйлдвэрлэлээс масс үйлдвэрлэл рүү шилжихтэй адил юм - хэрэв уламжлалт аргаар загварын хүснэгт бүр өвөрмөц бөгөөд онцгой анхаарал шаарддаг бол уян хатан аргачлалын хувьд энэ нь аль хэдийн стандарт "хэсгүүдийн" багц юм. Нэг талаас, илүү олон хүснэгтүүд байгаа бөгөөд өгөгдлийг ачаалах, сэргээх үйл явц нь илүү төвөгтэй харагдах ёстой. Нөгөө талаар тэд болдог ердийн. Энэ нь байж магадгүй гэсэн үг автоматжуулсан болон мета өгөгдөлд тулгуурласан. "Бид үүнийг яаж тавих вэ?" Гэсэн асуултын хариулт нь сайжруулалт хийх ажлын нэлээд хэсгийг эзэлдэг бөгөөд одоо үнэ цэнэтэй биш юм (мөн загварыг өөрчлөх нь ажлын процесст үзүүлэх нөлөөллийн талаархи асуулт юм. ).
Энэ нь ийм системд шинжээчид огт хэрэггүй гэсэн үг биш юм - хэн нэгэн шинж чанар бүхий олон тооны объектуудыг судалж, хаана, хэрхэн ачаалахаа олж мэдэх шаардлагатай хэвээр байна. Гэхдээ ажлын хэмжээ, алдаа гарах магадлал, өртөг мэдэгдэхүйц буурдаг. Шинжилгээний үе шатанд болон ETL-ийг боловсруулах явцад хоёуланд нь мета өгөгдлийг засварлахад ихээхэн хэмжээгээр бууруулж болно.
Хар тал
Дээр дурдсан бүхэн нь хоёуланг нь үнэхээр уян хатан, технологийн хувьд дэвшилтэт, давтан сайжруулахад тохиромжтой болгодог. Мэдээжийн хэрэг, та аль хэдийн таамаглаж магадгүй гэж бодож байгаа "тос доторх торх" бас байдаг.
Уян хатан архитектурын модульчлагдсан байдлын үндэс болох өгөгдлийн задрал нь хүснэгтийн тоог нэмэгдүүлэхэд хүргэдэг бөгөөд үүний дагуу дээгүүр дээж авах үед нэгдэх. Хэмжээний бүх шинж чанарыг олж авахын тулд сонгодог дэлгүүрт нэг сонголт хийхэд хангалттай, гэхдээ уян хатан архитектур нь бүхэл бүтэн цуврал холболтыг шаарддаг. Түүгээр ч үл барам, хэрэв эдгээр бүх тайлангуудын нэгдлийг урьдчилан бичиж чадвал SQL-г гараар бичиж дассан шинжээчид хоёр дахин зовох болно.
Энэ байдлыг хөнгөвчлөх хэд хэдэн баримт байдаг:
Том хэмжээтэй ажиллахдаа түүний бүх шинж чанаруудыг нэгэн зэрэг бараг ашигладаггүй. Энэ нь загвар дээр анх харахад харагдахаас цөөн тооны холболт байж магадгүй гэсэн үг юм. Data Vault нь хиймэл дагуулуудад шинж чанаруудыг хуваарилахдаа хуваалцах хүлээгдэж буй давтамжийг харгалзан үзэх боломжтой. Үүний зэрэгцээ, Hub эсвэл Anchors нь ачаалах үе шатанд орлуулагч үүсгэх, зураглахад шаардлагатай байдаг бөгөөд асуулгад бараг ашиглагддаггүй (энэ нь ялангуяа Anchors-ийн хувьд үнэн юм).
Бүх холболтууд нь түлхүүрээр хийгддэг. Нэмж дурдахад, өгөгдлийг хадгалах илүү "шахсан" арга нь шаардлагатай газарт сканнердах хүснэгтийн ачааллыг бууруулдаг (жишээлбэл, атрибутын утгаар шүүх үед). Энэ нь нэг мөрөнд олон хувилбар бүхий нэг хүнд хэмжээсийг сканнердсанаас ч олон тооны холболттой хэвийн мэдээллийн сангаас түүвэрлэх нь бүр ч хурдан болоход хүргэж болзошгүй юм.
Жишээлбэл, энд Нийтлэлд нэг хүснэгтээс авсан дээж бүхий Anchor загварын гүйцэтгэлийн нарийвчилсан харьцуулсан туршилтыг багтаасан болно.
Хөдөлгүүрээс их зүйл шалтгаална. Орчин үеийн олон платформууд нэгдэх оновчтой болгох дотоод механизмтай байдаг. Жишээлбэл, MS SQL болон Oracle нь өгөгдөл нь бусад холболтоос бусад газарт ашиглагдаагүй, эцсийн сонголтод нөлөөлөхгүй (хүснэгт/нэгдлийг арилгах) болон MPP Vertica бол хүснэгтүүдийн нэгдлийг "алгаж" болно. , асуулгын төлөвлөгөөг гар аргаар оновчтой болгосноор Anchor Model-д маш сайн хөдөлгүүр болох нь батлагдсан. Нөгөөтэйгүүр, Anchor Model-г жишээлбэл, нэгдэх дэмжлэг хязгаарлагдмал Click House дээр хадгалах нь тийм ч сайн санаа биш бололтой.
Үүнээс гадна, хоёр архитектурын хувьд байдаг тусгай хөдөлгөөнүүд, өгөгдлийн хандалтыг хөнгөвчлөх (асуулгын гүйцэтгэлийн үүднээс болон эцсийн хэрэглэгчдийн хувьд). Жишээлбэл, Цаг хугацааны хүснэгтүүд Data Vault эсвэл хүснэгтийн тусгай функцууд Anchor загварт.
Нийт
Уян хатан архитектурын гол мөн чанар нь тэдний "дизайн" -ын модульчлагдсан байдал юм.
Энэ өмч нь дараахь зүйлийг зөвшөөрдөг.
- Мета өгөгдлийг байршуулах, үндсэн ETL алгоритмуудыг бичихтэй холбоотой эхний бэлтгэлийн дараа, Эхний үр дүнг хэрэглэгчдэд хурдан өгөх хэдхэн эх сурвалжийн өгөгдлийг агуулсан хэд хэдэн тайлан хэлбэрээр. Объектын загварыг бүхэлд нь (дээд түвшинд ч гэсэн) бодож үзэх шаардлагагүй.
- Өгөгдлийн загвар нь зөвхөн 2-3 объекттой ажиллаж эхлэх боломжтой (мөн ашигтай байж болно). аажмаар өснө (Анкорын загвар өмсөгч Николайгийн тухай мицелитэй сайхан харьцуулалт).
- Сэдвийн хүрээг өргөжүүлэх, шинэ эх сурвалж нэмэх зэрэг ихэнх сайжруулалтууд одоо байгаа функцэд нөлөөлөхгүй бөгөөд аль хэдийн ажиллаж байгаа зүйлийг эвдэх эрсдэлгүй.
- Стандарт элементүүдэд задаргаа хийсний ачаар ийм систем дэх ETL процессууд ижил харагдаж, тэдгээрийн бичвэр нь алгоритмчлалд тустай бөгөөд эцэст нь автоматжуулалт.
Энэ уян хатан байдлын үнэ нь гүйцэтгэл. Энэ нь ийм загварт хүлээн зөвшөөрөгдсөн гүйцэтгэлд хүрэх боломжгүй гэсэн үг биш юм. Ихэнх тохиолдолд та хүссэн хэмжигдэхүүндээ хүрэхийн тулд илүү их хүчин чармайлт, нарийн ширийн зүйлийг анхаарч үзэх хэрэгтэй.
апп-ууд
Аж ахуйн нэгжийн төрлүүд Өгөгдлийн сан
Data Vault-ийн талаарх дэлгэрэнгүй мэдээлэл:
Аж ахуйн нэгжийн төрлүүд Зангуу загвар
Anchor Model-ийн талаарх дэлгэрэнгүй мэдээлэл:
Харгалзан үзэх хандлагын нийтлэг шинж чанар, ялгаа бүхий хураангуй хүснэгт:
Эх сурвалж: www.habr.com