Պահեստային տարածքի կառուցումը երկար և լուրջ նախաձեռնություն է:
Ծրագրի կյանքում շատ բան կախված է նրանից, թե որքան լավ են մտածված օբյեկտի մոդելը և բազային կառուցվածքը սկզբում:
Ընդհանուր ընդունված մոտեցումը եղել և մնում է աստղային սխեման երրորդ նորմալ ձևի հետ համատեղելու տարբեր տարբերակներ: Որպես կանոն, ըստ սկզբունքի՝ նախնական տվյալներ՝ 3NF, ցուցափեղկերը՝ աստղ։ Այս մոտեցումը, ժամանակի ընթացքում փորձարկված և մեծ քանակությամբ հետազոտություններով աջակցված, առաջին (և երբեմն միակ) բանն է, որ գալիս է փորձառու DWH մասնագետի մտքում, երբ մտածում է, թե ինչպիսին պետք է լինի վերլուծական պահեստը:
Մյուս կողմից, բիզնեսն ընդհանրապես և հաճախորդների պահանջները, մասնավորապես, հակված են արագ փոփոխության, և տվյալները հակված են աճել թե՛ «խորությամբ», թե՛ «լայնությամբ»: Եվ հենց այստեղ է հայտնվում աստղի գլխավոր թերությունը՝ սահմանափակ ճկունություն.
Եվ եթե ձեր հանգիստ և հարմարավետ կյանքում որպես DWH ծրագրավորող հանկարծ.
- խնդիրն առաջացավ «գոնե ինչ-որ բան արագ անել, և հետո կտեսնենք»;
- ի հայտ եկավ արագ զարգացող նախագիծ՝ նոր աղբյուրների միացմամբ և բիզնես մոդելի վերամշակմամբ առնվազն շաբաթը մեկ անգամ.
- հայտնվել է հաճախորդ, ով չի պատկերացնում, թե ինչպիսին պետք է լինի համակարգը և ինչ գործառույթներ այն պետք է կատարի ի վերջո, բայց պատրաստ է փորձարկել և հետևողականորեն կատարելագործել ցանկալի արդյունքը՝ հետևողականորեն մոտենալով դրան.
- Ծրագրի մենեջերը հայտնվեց բարի լուրով. «Եվ հիմա մենք ունենք արագաշարժ»:
Կամ, եթե դուք պարզապես հետաքրքրված եք պարզել, թե ինչպես կարող եք կառուցել պահեստային տարածքներ, բարի գալուստ կտրվածք:
Ի՞նչ է նշանակում «ճկունություն»:
Նախ, եկեք սահմանենք, թե ինչ հատկություններ պետք է ունենա համակարգը, որպեսզի կոչվի «ճկուն»:
Առանձին-առանձին, հարկ է նշել, որ նկարագրված հատկությունները պետք է վերաբերվեն հատուկ համակարգը, ոչ թե գործընթաց դրա զարգացումը։ Հետևաբար, եթե ցանկանում էիք կարդալ Agile-ի մասին՝ որպես զարգացման մեթոդաբանության, ավելի լավ է կարդալ այլ հոդվածներ։ Օրինակ, հենց այնտեղ՝ Հաբրեում, շատ հետաքրքիր նյութեր կան (օրինակ и Իսկ ).
Սա չի նշանակում, որ մշակման գործընթացը և տվյալների պահեստի կառուցվածքը բոլորովին կապ չունեն: Ընդհանուր առմամբ, պետք է զգալիորեն ավելի հեշտ լինի զարգացնել արագաշարժ շտեմարան ճկուն ճարտարապետության համար: Այնուամենայնիվ, գործնականում ավելի հաճախ կան ընտրանքներ Agile-ով դասական DWH-ի մշակմամբ՝ ըստ Kimbal-ի և DataVault-ի՝ ըստ Waterfall-ի, քան մեկ նախագծի վրա իր երկու ձևով ճկունության երջանիկ զուգադիպություններ:
Այսպիսով, ի՞նչ հնարավորություններ պետք է ունենա ճկուն պահեստը: Այստեղ երեք կետ կա.
- Վաղ առաքում և արագ շրջադարձ - սա նշանակում է, որ իդեալականորեն առաջին բիզնես արդյունքը (օրինակ՝ առաջին աշխատանքային հաշվետվությունները) պետք է հնարավորինս շուտ ստանալ, այսինքն՝ նույնիսկ մինչև ամբողջ համակարգի ամբողջական նախագծումը և ներդրումը: Ավելին, յուրաքանչյուր հաջորդ վերանայումը նույնպես պետք է հնարավորինս քիչ ժամանակ պահանջի:
- Կրկնվող ճշգրտում - սա նշանակում է, որ յուրաքանչյուր հաջորդ բարելավումը իդեալականորեն չպետք է ազդի արդեն իսկ գործող ֆունկցիոնալության վրա: Հենց այս պահն է, որ հաճախ դառնում է ամենամեծ մղձավանջը խոշոր նախագծերում. վաղ թե ուշ, առանձին օբյեկտները սկսում են այնքան շատ կապեր ձեռք բերել, որ ավելի հեշտ է դառնում տրամաբանությունը ամբողջությամբ կրկնել մոտակայքում գտնվող պատճենում, քան դաշտ ավելացնել գոյություն ունեցող աղյուսակում: Եվ եթե դուք զարմացած եք, որ գոյություն ունեցող օբյեկտների վրա բարելավումների ազդեցության վերլուծությունը կարող է ավելի շատ ժամանակ խլել, քան իրենք բարելավումները, դուք, ամենայն հավանականությամբ, դեռ չեք աշխատել բանկային կամ հեռահաղորդակցության խոշոր տվյալների պահեստների հետ:
- Մշտապես հարմարվում է փոփոխվող բիզնես պահանջներին - Օբյեկտի ընդհանուր կառուցվածքը պետք է նախագծվի ոչ միայն հաշվի առնելով հնարավոր ընդլայնումը, այլ այն ակնկալիքով, որ այս հաջորդ ընդլայնման ուղղությունը նախագծման փուլում նույնիսկ հնարավոր չէր երազել:
Եվ այո, այս բոլոր պահանջների կատարումը մեկ համակարգում հնարավոր է (իհարկե, առանձին դեպքերում և որոշ վերապահումներով)։
Ստորև ես կքննարկեմ տվյալների պահեստների համար ամենահայտնի արագաշարժ նախագծման մեթոդաբանություններից երկուսը. Խարիսխի մոդել и Տվյալների պահոց. Փակագծերից դուրս են մնացել այնպիսի հիանալի տեխնիկա, ինչպիսիք են, օրինակ, EAV, 6NF (իր մաքուր տեսքով) և NoSQL լուծումների հետ կապված ամեն ինչ, ոչ այն պատճառով, որ դրանք ինչ-որ կերպ ավելի վատն են, և նույնիսկ այն պատճառով, որ այս դեպքում հոդվածը սպառնում է ձեռք բերել: միջին դիսերի ծավալը. Պարզապես այս ամենը կապված է մի փոքր այլ դասի լուծումների հետ՝ կա՛մ տեխնիկայի, որը կարող եք օգտագործել կոնկրետ դեպքերում՝ անկախ ձեր նախագծի ընդհանուր ճարտարապետությունից (ինչպես EAV), կամ գլոբալ այլ տեղեկատվության պահպանման պարադիգմների հետ (օրինակ՝ գրաֆիկական տվյալների բազաները): և այլ տարբերակներ NoSQL):
«Դասական» մոտեցման խնդիրները և դրանց լուծումները ճկուն մեթոդաբանություններում
«Դասական» մոտեցում ասելով ես նկատի ունեմ հին լավ աստղին (անկախ հիմքում ընկած շերտերի կոնկրետ իրականացումից, թող ինձ ներեն Քիմբալի, Ինմոնի և CDM-ի հետևորդները):
1. Միացումների կոշտ կարդինալություն
Այս մոդելը հիմնված է տվյալների հստակ բաժանման վրա Չափս и փաստեր. Եվ սա, անիծյալ, տրամաբանական է. չէ՞ որ տվյալների վերլուծությունը դեպքերի ճնշող մեծամասնությունում հանգում է որոշակի թվային ցուցանիշների (փաստերի) վերլուծությանը որոշակի բաժիններում (չափերում):
Այս դեպքում օբյեկտների միջև կապերը հաստատվում են աղյուսակների միջև փոխհարաբերությունների տեսքով, օգտագործելով օտար բանալին: Սա բավականին բնական է թվում, բայց անմիջապես հանգեցնում է ճկունության առաջին սահմանափակմանը. կապերի կարդինալության խիստ սահմանում.
Սա նշանակում է, որ սեղանի նախագծման փուլում դուք պետք է ճշգրիտ որոշեք յուրաքանչյուր զույգ առնչվող օբյեկտների համար, թե արդյոք դրանք կարող են վերաբերվել նույնքան շատ-շատերին, թե՞ միայն 1-ից-շատերին և «որ ուղղությամբ»: Սա ուղղակիորեն որոշում է, թե որ աղյուսակը կունենա առաջնային բանալին, իսկ որը` արտաքին բանալին: Այս վերաբերմունքի փոփոխությունը, երբ ստացվում են նոր պահանջներ, ամենայն հավանականությամբ կհանգեցնի բազայի վերամշակմանը:
Օրինակ, «դրամական անդորրագիր» օբյեկտը նախագծելիս, դուք, հենվելով վաճառքի բաժնի երդման վրա, սահմանեցիք գործողության հնարավորությունը. մեկ առաջխաղացում մի քանի ստուգողական դիրքերի համար (բայց ոչ հակառակը).
Եվ որոշ ժամանակ անց գործընկերները ներկայացրեցին նոր մարքեթինգային ռազմավարություն, որով նրանք կարող են գործել նույն դիրքով մի քանի առաջխաղացումներ միաժամանակ. Եվ հիմա դուք պետք է փոփոխեք աղյուսակները՝ հարաբերությունները բաժանելով առանձին օբյեկտի:
(Բոլոր ստացված օբյեկտները, որոնցում այժմ միացված է առաջխաղացման ստուգումը, նույնպես պետք է բարելավվեն):
Հարաբերություններ տվյալների պահոցում և խարիսխ մոդելում
Այս իրավիճակից խուսափելը բավականին պարզ դարձավ. դա անելու համար պետք չէ վստահել վաճառքի բաժնին: բոլոր կապերը սկզբում պահվում են առանձին աղյուսակներում և մշակել այն որպես շատ-շատ-շատ:
Այս մոտեցումն առաջարկվեց Դեն Լինստեդտ որպես պարադիգմայի մաս Տվյալների պահոց և լիովին աջակցվում է Լարս Ռյոնբակ в Խարիսխ մոդել.
Արդյունքում մենք ստանում ենք ճկուն մեթոդաբանությունների առաջին տարբերակիչ առանձնահատկությունը.
Օբյեկտների միջև հարաբերությունները չեն պահվում մայր սուբյեկտների ատրիբուտներում, այլ օբյեկտի առանձին տեսակ են:
В Տվյալների պահոց նման կապող աղյուսակները կոչվում են կապ, իսկ ներսում Խարիսխ մոդել - Tie. Առաջին հայացքից նրանք շատ նման են, չնայած նրանց տարբերությունները չեն ավարտվում անվանմամբ (որը կքննարկվի ստորև): Երկու ճարտարապետություններում էլ կապի աղյուսակները կարող են կապվել ցանկացած թվով սուբյեկտներ (պարտադիր չէ 2):
Այս ավելորդությունն առաջին հայացքից զգալի ճկունություն է ապահովում փոփոխությունների համար: Նման կառույցը հանդուրժող է դառնում ոչ միայն գոյություն ունեցող հղումների կարդինալության փոփոխությունների, այլև նորերի ավելացման նկատմամբ. եթե այժմ չեկային դիրքը նաև հղում ունի այն բացող գանձապահի հետ, ապա նման հղումի տեսքը պարզապես կդառնա: հավելում գոյություն ունեցող աղյուսակների վրա՝ առանց որևէ գոյություն ունեցող օբյեկտների և գործընթացների վրա ազդելու:
2. Տվյալների կրկնօրինակում
Երկրորդ խնդիրը, որը լուծվում է ճկուն ճարտարապետություններով, ավելի քիչ ակնհայտ է և բնորոշ է առաջին հերթին: SCD2 տիպի չափումներ (երկրորդ տիպի չափերը կամաց-կամաց փոփոխվող), թեև ոչ միայն դրանք։
Դասական պահեստում չափսը սովորաբար աղյուսակ է, որը պարունակում է փոխարինող բանալի (որպես PK) և առանձին սյունակներում բիզնես բանալիների և ատրիբուտների մի շարք:
Եթե չափանիշը աջակցում է տարբերակմանը, տարբերակի վավերականության սահմանները ավելացվում են ստանդարտ դաշտերի շարքին, և մի քանի տարբերակներ հայտնվում են պահեստում աղբյուրի մեկ տողի համար (մեկը տարբերակված հատկանիշների յուրաքանչյուր փոփոխության համար):
Եթե չափսը պարունակում է առնվազն մեկ հաճախակի փոփոխվող տարբերակված հատկանիշ, նման չափման տարբերակների թիվը տպավորիչ կլինի (նույնիսկ եթե մնացած ատրիբուտները չեն տարբերակվում կամ երբեք չեն փոխվում), իսկ եթե կան մի քանի նման հատկանիշներ, ապա տարբերակների քանակը կարող է. դրանց քանակից երկրաչափական աճ է գրանցվում: Այս չափումը կարող է զգալի քանակությամբ սկավառակի տարածություն զբաղեցնել, չնայած այն պահում է տվյալների մեծ մասը, որոնք պարզապես այլ տողերի անփոփոխ հատկանիշի արժեքների կրկնօրինակներն են:
Միևնույն ժամանակ, այն նույնպես շատ հաճախ է օգտագործվում ապանորմալացում — որոշ ատրիբուտներ դիտավորյալ պահվում են որպես արժեք, և ոչ որպես հղում դեպի տեղեկատու կամ այլ չափ: Այս մոտեցումը արագացնում է տվյալների հասանելիությունը՝ նվազեցնելով միացումների քանակը չափորոշիչ մուտք գործելու ժամանակ:
Սովորաբար դա հանգեցնում է նույն տեղեկատվությունը պահվում է միաժամանակ մի քանի վայրերում. Օրինակ, բնակության շրջանի և հաճախորդի կատեգորիայի մասին տեղեկատվությունը կարող է միաժամանակ պահպանվել «Հաճախորդ» չափումներում և «Գնումներ», «Առաքում» և «Զանգերի կենտրոնի զանգեր» փաստերում, ինչպես նաև «Հաճախորդ - Հաճախորդների մենեջեր»: «Հղման աղյուսակ.
Ընդհանուր առմամբ, վերը նկարագրվածը վերաբերում է սովորական (չտարբերակված) չափսերին, սակայն տարբերակվածներում դրանք կարող են ունենալ այլ մասշտաբ. աղյուսակներ, բայց հարակից օբյեկտների նոր տարբերակների կասկադային տեսքին. երբ Աղյուսակ 1-ն օգտագործվում է Աղյուսակ 2-ը կառուցելու համար, իսկ Աղյուսակ 2-ը՝ Աղյուսակ 3-ը և այլն: Նույնիսկ եթե Աղյուսակ 1-ի ոչ մի հատկանիշ ներառված չէ Աղյուսակ 3-ի կառուցման մեջ (և ներառված են Աղյուսակ 2-ի այլ ատրիբուտներ, որոնք ստացվել են այլ աղբյուրներից), այս կառուցվածքի տարբերակումը նվազագույնը կհանգեցնի լրացուցիչ ծախսերի, իսկ առավելագույնը` լրացուցիչ ծախսերի: տարբերակները Աղյուսակ 3. որն ընդհանրապես կապ չունի դրա հետ և ավելի ներքև՝ շղթայով:
3. Վերամշակման ոչ գծային բարդություն
Միևնույն ժամանակ, մեկ այլ խանութի հիման վրա կառուցված յուրաքանչյուր նոր ցուցափեղկ ավելացնում է այն վայրերի թիվը, որտեղ տվյալները կարող են «տարբերվել», երբ փոփոխություններ են կատարվում ETL-ում: Սա, իր հերթին, հանգեցնում է յուրաքանչյուր հաջորդ վերանայման բարդության (և տևողության) ավելացման:
Եթե վերը նշվածը նկարագրում է հազվադեպ փոփոխված ETL գործընթացներով համակարգեր, դուք կարող եք ապրել նման պարադիգմում, պարզապես պետք է համոզվեք, որ նոր փոփոխությունները ճիշտ են կատարվել բոլոր առնչվող օբյեկտներում: Եթե վերանայումները հաճախակի են լինում, մի քանի կապեր պատահաբար «բացակայելու» հավանականությունը զգալիորեն մեծանում է:
Եթե, ի լրումն, հաշվի առնենք, որ «տարբերակված» ETL-ը զգալիորեն ավելի բարդ է, քան «չտարբերակվածը», ապա այս ամբողջ հաստատությունը հաճախակի թարմացնելիս սխալներից խուսափելը բավականին դժվար է դառնում:
Օբյեկտների և ատրիբուտների պահպանում Data Vault-ում և Anchor Model-ում
Ճկուն ճարտարապետությունների հեղինակների առաջարկած մոտեցումը կարելի է ձևակերպել հետևյալ կերպ.
Պետք է տարանջատել, թե ինչ է փոխվում այն, ինչ մնում է նույնը։ Այսինքն՝ պահեք բանալիները ատրիբուտներից առանձին։
Այնուամենայնիվ, չպետք է շփոթել տարբերակված չէ հետ հատկանիշ անփոփոխԱռաջինը չի պահպանում իր փոփոխությունների պատմությունը, բայց կարող է փոխվել (օրինակ՝ մուտքագրման սխալը ուղղելիս կամ նոր տվյալներ ստանալիս), երկրորդը երբեք չի փոխվում։
Տեսակետները տարբերվում են այն հարցում, թե կոնկրետ ինչը կարելի է անփոփոխ համարել Տվյալների պահոցում և խարիսխ մոդելում:
Ճարտարապետական տեսանկյունից Տվյալների պահոց, կարելի է համարել անփոփոխ բանալիների ամբողջ հավաքածու - բնական (կազմակերպության TIN, ապրանքի կոդը սկզբնական համակարգում և այլն) և փոխարինող: Այս դեպքում մնացած ատրիբուտները կարելի է բաժանել խմբերի՝ ըստ փոփոխությունների աղբյուրի և/կամ հաճախականության և Յուրաքանչյուր խմբի համար պահեք առանձին սեղան տարբերակների անկախ հավաքածուով։
Պարադիգմում Խարիսխ մոդել համարվում է անփոփոխ միայն փոխնակ բանալի Բնահյութ. Մնացած ամեն ինչ (ներառյալ բնական ստեղները) իր հատկանիշների հատուկ դեպքն է: Որտեղ բոլոր ատրիբուտները լռելյայնորեն անկախ են միմյանցից, այնպես որ յուրաքանչյուր հատկանիշի համար a առանձին սեղան.
В Տվյալների պահոց աղյուսակները, որոնք պարունակում են էության բանալիներ, կոչվում են Հուբամի. Հաբերը միշտ պարունակում են դաշտերի ֆիքսված շարք.
- Բնական էության բանալիներ
- Փոխնակ բանալի
- Հղում դեպի աղբյուրը
- Գրանցեք ավելացման ժամանակը
Գրառումներ Hubs-ում երբեք չփոխվել և չունենալ տարբերակներ. Արտաքինից, հանգույցները շատ նման են ID-քարտեզի տիպի աղյուսակներին, որոնք օգտագործվում են որոշ համակարգերում՝ փոխարինողներ ստեղծելու համար, այնուամենայնիվ, խորհուրդ է տրվում օգտագործել բիզնես բանալիների մի շարք հեշ՝ որպես փոխարինողներ Data Vault-ում: Այս մոտեցումը հեշտացնում է աղբյուրներից հարաբերությունների և ատրիբուտների բեռնումը (փոխանակում ստանալու համար անհրաժեշտ չէ միանալ հանգույցին, պարզապես հաշվարկել բնական բանալու հեշը), բայց կարող է առաջացնել այլ խնդիրներ (կապված, օրինակ, բախումների, պատյանների և տպագրության համար չտպելու համար): նիշերը լարային ստեղների մեջ և այլն: .p.), հետևաբար այն ընդհանուր առմամբ ընդունված չէ:
Բոլոր այլ օբյեկտների ատրիբուտները պահվում են հատուկ աղյուսակներում, որոնք կոչվում են Արբանյակներ. Մեկ հանգույցը կարող է ունենալ մի քանի արբանյակներ, որոնք պահում են ատրիբուտների տարբեր խմբեր:
Արբանյակների միջև ատրիբուտների բաշխումը տեղի է ունենում սկզբունքի համաձայն համատեղ փոփոխություն — մի արբանյակում կարող են պահվել չտարբերակված ատրիբուտներ (օրինակ՝ ծննդյան ամսաթիվ և SNILS անհատի համար), մյուսում՝ հազվադեպ փոփոխվող տարբերակները (օրինակ՝ ազգանունը և անձնագրի համարը), երրորդում՝ հաճախ փոփոխվողները։ (օրինակ՝ առաքման հասցե, կատեգորիա, վերջին պատվերի ամսաթիվը և այլն): Այս դեպքում տարբերակավորումն իրականացվում է առանձին արբանյակների մակարդակով, և ոչ թե ամբողջ կազմակերպությունը, ուստի խորհուրդ է տրվում ատրիբուտները բաշխել այնպես, որ տարբերակների խաչմերուկը մեկ արբանյակի ներսում լինի նվազագույն (ինչը նվազեցնում է պահպանված տարբերակների ընդհանուր թիվը: )
Նաև տվյալների բեռնման գործընթացը օպտիմալացնելու համար տարբեր աղբյուրներից ստացված ատրիբուտները հաճախ ներառվում են առանձին արբանյակներում:
Արբանյակները շփվում են հանգույցի հետ միջոցով օտար բանալի (որը համապատասխանում է 1-ից շատ կարդինալությանը): Սա նշանակում է, որ մի քանի ատրիբուտների արժեքներ (օրինակ, մի քանի կոնտակտային հեռախոսահամարներ մեկ հաճախորդի համար) աջակցվում են այս «լռելյայն» ճարտարապետությամբ:
В Խարիսխ մոդել սեղանները, որոնք պահում են բանալիները, կոչվում են Խարիսխներ. Եվ նրանք պահպանում են.
- Միայն փոխնակ բանալիներ
- Հղում դեպի աղբյուրը
- Գրանցեք ավելացման ժամանակը
Դիտարկվում են բնական բանալիները խարիսխի մոդելի տեսանկյունից սովորական հատկանիշներ. Այս տարբերակը կարող է թվալ ավելի դժվար հասկանալի, բայց այն շատ ավելի մեծ հնարավորություն է տալիս օբյեկտի նույնականացման համար:
Օրինակ, եթե նույն էության մասին տվյալները կարող են ստացվել տարբեր համակարգերից, որոնցից յուրաքանչյուրն օգտագործում է իր բնական բանալին: Data Vault-ում դա կարող է հանգեցնել մի քանի հանգույցների բավականին ծանր կառուցվածքների (մեկը յուրաքանչյուր աղբյուրի + միավորող հիմնական տարբերակ), մինչդեռ Anchor մոդելում յուրաքանչյուր աղբյուրի բնական բանալին ընկնում է իր սեփական հատկանիշի մեջ և կարող է օգտագործվել անկախ բեռնելիս: մնացած բոլորը։
Բայց այստեղ կա նաև մեկ ստոր կետ. եթե տարբեր համակարգերի ատրիբուտները համակցված են մեկ ամբողջության մեջ, ամենայն հավանականությամբ, կան որոշ «Սոսնձման» կանոնները, որով համակարգը պետք է հասկանա, որ տարբեր աղբյուրներից ստացված գրառումները համապատասխանում են կազմակերպության մեկ օրինակին:
В Տվյալների պահոց այս կանոնները, ամենայն հավանականությամբ, կորոշեն կազմավորումը Վարպետ կազմակերպության «փոխնակ հանգույց»: և ոչ մի կերպ չազդել Հաբերի վրա, որոնք պահում են բնական աղբյուրի բանալիները և դրանց սկզբնական հատկանիշները: Եթե ինչ-որ պահի միաձուլման կանոնները փոխվեն (կամ այն ատրիբուտները, որոնցով այն կատարվում է, թարմացվեն), բավական կլինի փոխնակ հանգույցները վերափոխել:
В Խարիսխի մոդել նման կազմակերպությունը, ամենայն հավանականությամբ, կպահվի այնտեղ միակ խարիսխը. Սա նշանակում է, որ բոլոր ատրիբուտները, անկախ նրանից, թե որ աղբյուրից են նրանք գալիս, կապված կլինեն նույն փոխանորդին: Սխալ կերպով միավորված գրառումների առանձնացումը և, ընդհանուր առմամբ, նման համակարգում միաձուլման արդիականության մոնիտորինգը կարող է շատ ավելի դժվար լինել, հատկապես, եթե կանոնները բավականին բարդ են և հաճախ փոխվում են, և նույն հատկանիշը կարելի է ձեռք բերել տարբեր աղբյուրներից (թեև դա, իհարկե, այդպես է. հնարավոր է, քանի որ հատկանիշի յուրաքանչյուր տարբերակ պահպանում է իր աղբյուրի հղումը):
Ամեն դեպքում, եթե ձեր համակարգը պետք է իրականացնի ֆունկցիոնալությունը կրկնօրինակում, գրառումների միաձուլում և MDM այլ տարրեր, արժե հատուկ ուշադրություն դարձնել արագաշարժ մեթոդոլոգիաներում բնական բանալիների պահպանման ասպեկտներին: Հավանական է, որ Data Vault-ի ավելի ծավալուն դիզայնը հանկարծ ավելի ապահով կլինի միավորման սխալների առումով:
Խարիսխի մոդել ապահովում է նաև լրացուցիչ օբյեկտի տեսակ, որը կոչվում է Հանգույց դա ըստ էության առանձնահատուկ է այլասերված տեսակի խարիսխ, որը կարող է պարունակել միայն մեկ հատկանիշ։ Ենթադրվում է, որ հանգույցները պետք է օգտագործվեն հարթ գրացուցակներ պահելու համար (օրինակ՝ սեռը, ամուսնական կարգավիճակը, հաճախորդների սպասարկման կատեգորիան և այլն): Ի տարբերություն խարիսխի, հանգույցի չունի կապված հատկանիշների աղյուսակներ, և նրա միակ հատկանիշը (անունը) միշտ պահվում է նույն աղյուսակում՝ բանալիով։ Հանգույցները կապված են խարիսխների հետ կապի աղյուսակներով (Tie) այնպես, ինչպես խարիսխները միացված են միմյանց:
Հանգույցների օգտագործման վերաբերյալ հստակ կարծիք չկա: Օրինակ, , ով ակտիվորեն նպաստում է Ռուսաստանում խարիսխի մոդելի կիրառմանը, կարծում է (ոչ անհիմն), որ ոչ մի տեղեկատու գրքի համար չի կարելի վստահորեն պնդել, որ այն միշտ կլինի ստատիկ և մեկ մակարդակ, ուստի ավելի լավ է անմիջապես օգտագործել լիարժեք խարիսխ բոլոր օբյեկտների համար:
Data Vault-ի և Anchor մոդելի միջև մեկ այլ կարևոր տարբերություն առկայությունն է կապերի հատկանիշներ:
В Տվյալների պահոց Հղումները նույն ամբողջական օբյեկտներն են, ինչ Hubs-ը և կարող են ունենալ սեփական հատկանիշները: Մեջ Խարիսխի մոդել Հղումները օգտագործվում են միայն խարիսխները և չեն կարող ունենալ իրենց սեփական հատկանիշները. Այս տարբերությունը հանգեցնում է էապես տարբեր մոդելավորման մոտեցումների փաստեր, որը կքննարկվի հետագա:
Փաստերի պահպանում
Մինչ այս մենք խոսում էինք հիմնականում չափումների մոդելավորման մասին։ Փաստերը մի փոքր պակաս պարզ են.
В Տվյալների պահոց փաստերի պահպանման տիպիկ օբյեկտ է Հղում, որի արբանյակներում ավելացվում են իրական ցուցանիշներ։
Այս մոտեցումը ինտուիտիվ է թվում: Այն ապահովում է հեշտ մուտք դեպի վերլուծված ցուցանիշներ և ընդհանուր առմամբ նման է ավանդական փաստերի աղյուսակին (միայն ցուցանիշները պահվում են ոչ թե բուն աղյուսակում, այլ «հարևան» աղյուսակում): Բայց կան նաև որոգայթներ. մոդելի բնորոշ փոփոխություններից մեկը՝ փաստի բանալին ընդլայնելը, անհրաժեշտ Link-ին նոր օտար բանալի ավելացնելով. Եվ դա, իր հերթին, «կոտրում է» մոդուլյարությունը և պոտենցիալ առաջացնում է այլ օբյեկտների փոփոխությունների անհրաժեշտություն:
В Խարիսխի մոդել Կապը չի կարող ունենալ իր սեփական հատկանիշները, ուստի այս մոտեցումը չի աշխատի. բացարձակապես բոլոր ատրիբուտներն ու ցուցիչները պետք է կապված լինեն մեկ կոնկրետ խարիսխի հետ: Սրանից եզրակացությունը պարզ է. Յուրաքանչյուր փաստ նույնպես իր խարիսխի կարիք ունի. Որոշ բաների համար, որոնք մենք սովոր ենք ընկալել որպես փաստեր, դա կարող է բնական թվալ, օրինակ՝ գնման փաստը կարող է կատարելապես կրճատվել մինչև «պատվեր» կամ «անդորրագիր», կայք այցելելը նիստին և այլն: Բայց կան նաև փաստեր, որոնց համար այդքան էլ հեշտ չէ գտնել նման բնական «փոխադրող օբյեկտ», օրինակ՝ ապրանքների մնացորդները պահեստներում ամեն օրվա սկզբին։
Համապատասխանաբար, խարիսխի մոդելում փաստերի բանալին ընդլայնելիս մոդուլյարության հետ կապված խնդիրներ չեն առաջանում (բավական է պարզապես նոր հարաբերություն ավելացնել համապատասխան խարիսխին), սակայն փաստերի ցուցադրման մոդելի ձևավորումն ավելի քիչ միանշանակ է. կարող են հայտնվել «արհեստական» խարիսխներ։ որոնք անհասկանալի կերպով ցուցադրում են բիզնես օբյեկտի մոդելը:
Ինչպես է ձեռք բերվում ճկունությունը
Ստացված շինարարությունը երկու դեպքում էլ պարունակում է զգալիորեն ավելի շատ աղյուսակներքան ավանդական չափումը: Բայց դա կարող է տեւել զգալիորեն պակաս սկավառակի տարածություն տարբերակված ատրիբուտների նույն հավաքածուով, ինչ ավանդական հարթությունը: Բնականաբար, այստեղ ոչ մի կախարդանք չկա. ամեն ինչ նորմալացման մասին է: Բաշխելով ատրիբուտները արբանյակների վրա (Տվյալների պահոցում) կամ առանձին աղյուսակներում (խարիսխ մոդել), մենք կրճատում ենք (կամ ամբողջությամբ վերացնում) որոշ ատրիբուտների արժեքների կրկնօրինակում մյուսները փոխելիս.
Համար Տվյալների պահոց շահումները կախված կլինեն արբանյակների միջև ատրիբուտների բաշխումից և համար Խարիսխի մոդել — գրեթե ուղիղ համեմատական է մեկ չափման օբյեկտի տարբերակների միջին թվին:
Այնուամենայնիվ, տարածքի խնայողությունը կարևոր, բայց ոչ հիմնական առավելությունն է ատրիբուտները առանձին պահելու համար: Հարաբերությունների առանձին պահպանման հետ մեկտեղ այս մոտեցումը դարձնում է խանութը մոդուլային դիզայն. Սա նշանակում է, որ նման մոդելում ինչպես անհատական ատրիբուտներ, այնպես էլ ամբողջ նոր առարկայական տարածքներ ավելացնելը նման է վերնաշենք գոյություն ունեցող օբյեկտների վրա՝ առանց դրանք փոխելու: Եվ հենց դա է, որ ճկուն է դարձնում նկարագրված մեթոդաբանությունները։
Սա նաև հիշեցնում է կտորների արտադրությունից զանգվածային արտադրության անցումը. եթե ավանդական մոտեցմամբ մոդելի յուրաքանչյուր աղյուսակ եզակի է և պահանջում է հատուկ ուշադրություն, ապա ճկուն մեթոդաբանություններում այն արդեն ստանդարտ «մասերի» հավաքածու է: Մի կողմից, կան ավելի շատ աղյուսակներ, և տվյալների բեռնման և առբերման գործընթացները պետք է ավելի բարդ տեսք ունենան: Մյուս կողմից նրանք դառնում են բնորոշ. Ինչը նշանակում է, որ կարող է լինել ավտոմատացված և մետատվյալների վրա հիմնված. «Ինչպե՞ս ենք դնելու այն» հարցը, որի պատասխանը կարող է զբաղեցնել բարելավումների նախագծման աշխատանքների զգալի մասը, այժմ պարզապես չարժե (ինչպես նաև աշխատանքային գործընթացների վրա մոդելի փոփոխության ազդեցության մասին հարցը. )
Սա չի նշանակում, որ նման համակարգում վերլուծաբաններ ընդհանրապես պետք չեն. ինչ-որ մեկը դեռ պետք է աշխատի ատրիբուտներով օբյեկտների շարքով և պարզի, թե որտեղ և ինչպես բեռնել այդ ամենը: Բայց աշխատանքի ծավալը, ինչպես նաև սխալի հավանականությունն ու արժեքը զգալիորեն կրճատվում են: Ե՛վ վերլուծության փուլում, և՛ ETL-ի մշակման ընթացքում, որը զգալի մասով կարող է կրճատվել մինչև մետատվյալների խմբագրում։
Dark կողմը
Վերոհիշյալ բոլորը երկու մոտեցումներն էլ դարձնում են իսկապես ճկուն, տեխնոլոգիապես առաջադեմ և հարմար են կրկնվող բարելավման համար: Իհարկե, կա նաև «քսուքի տակառ», որի մասին, կարծում եմ, արդեն կարող եք կռահել։
Տվյալների տարրալուծումը, որը ընկած է ճկուն ճարտարապետության մոդուլյարության հիմքում, հանգեցնում է աղյուսակների քանակի ավելացմանը և, համապատասխանաբար, գլխավերեւում միանալ նմուշառման ժամանակ: Պարզապես չափման բոլոր հատկանիշները ստանալու համար դասական խանութում մեկ ընտրությունը բավարար է, բայց ճկուն ճարտարապետությունը կպահանջի միացումների մի ամբողջ շարք: Ավելին, եթե հաշվետվությունների համար այս բոլոր միացումները հնարավոր լինի գրել նախօրոք, ապա կրկնակի կտուժեն վերլուծաբանները, ովքեր սովոր են SQL գրել ձեռքով։
Կան մի քանի փաստեր, որոնք հեշտացնում են այս իրավիճակը.
Մեծ չափերի հետ աշխատելիս դրա բոլոր հատկանիշները գրեթե երբեք չեն օգտագործվում միաժամանակ: Սա նշանակում է, որ կարող են լինել ավելի քիչ միացումներ, քան թվում է մոդելի առաջին հայացքից: Data Vault-ը կարող է նաև հաշվի առնել համօգտագործման ակնկալվող հաճախականությունը արբանյակներին ատրիբուտներ հատկացնելիս: Միևնույն ժամանակ, Hubs-ը կամ Anchors-ն իրենք հիմնականում անհրաժեշտ են բեռնման փուլում փոխարինողներ ստեղծելու և քարտեզագրելու համար և հազվադեպ են օգտագործվում հարցումներում (սա հատկապես ճիշտ է Anchors-ի համար):
Բոլոր միացումները կատարվում են բանալիով: Բացի այդ, տվյալների պահպանման ավելի «սեղմված» եղանակը նվազեցնում է սկանավորման աղյուսակների ծախսերը, որտեղ դա անհրաժեշտ է (օրինակ, երբ զտվում է ըստ հատկանիշի արժեքի): Սա կարող է հանգեցնել այն փաստի, որ մի շարք միացումներով նորմալացված տվյալների բազայից նմուշառումը կլինի նույնիսկ ավելի արագ, քան մեկ տողում բազմաթիվ տարբերակներով մեկ ծանր հարթության սկանավորումը:
Օրինակ, այստեղ ներս Հոդվածը պարունակում է Anchor մոդելի կատարման մանրամասն համեմատական թեստ մեկ աղյուսակից նմուշով:
Շատ բան կախված է շարժիչից: Շատ ժամանակակից հարթակներ ունեն ներքին միացման օպտիմալացման մեխանիզմներ: Օրինակ, MS SQL-ը և Oracle-ը կարող են «բաց թողնել» միացումները աղյուսակներին, եթե նրանց տվյալները չեն օգտագործվում որևէ տեղ, բացառությամբ այլ միացումների և չեն ազդում վերջնական ընտրության վրա (աղյուսակ/միանալու վերացում), և MPP Vertica-ն: , ապացուցել է, որ հիանալի շարժիչ է Anchor Model-ի համար՝ հաշվի առնելով հարցումների պլանի որոշ ձեռքով օպտիմալացում: Մյուս կողմից, Anchor Model-ը պահելը, օրինակ, Click House-ում, որն ունի սահմանափակ միանալու աջակցություն, դեռ այնքան էլ լավ գաղափար չէ:
Բացի այդ, երկու ճարտարապետության համար էլ կան հատուկ շարժումներ, հեշտացնելով տվյալների հասանելիությունը (ինչպես հարցումների կատարման տեսանկյունից, այնպես էլ վերջնական օգտագործողների համար): Օրինակ, Point-in-Time աղյուսակներ Տվյալների պահոցում կամ սեղանի հատուկ գործառույթներ Anchor մոդելում:
Ընդհանուր
Դիտարկվող ճկուն ճարտարապետությունների հիմնական էությունը դրանց «դիզայնի» մոդուլյարությունն է։
Այս հատկությունն է, որը թույլ է տալիս.
- Մետատվյալների տեղակայման և հիմնական ETL ալգորիթմների գրման հետ կապված նախնական նախապատրաստումից հետո, արագ տրամադրել հաճախորդին առաջին արդյունքը մի քանի զեկույցների տեսքով, որոնք պարունակում են տվյալներ ընդամենը մի քանի աղբյուրի օբյեկտներից: Անհրաժեշտ չէ ամբողջությամբ մտածել (նույնիսկ վերին մակարդակում) ամբողջ օբյեկտի մոդելը:
- Տվյալների մոդելը կարող է սկսել աշխատել (և օգտակար լինել) ընդամենը 2-3 օբյեկտի հետ, այնուհետև աճում է աստիճանաբար (Խարիսխի մոդել Նիկոլայ գեղեցիկ համեմատություն միցելիումի հետ):
- Բարելավումների մեծ մասը, ներառյալ թեմայի ընդլայնումը և նոր աղբյուրների ավելացումը չի ազդում առկա ֆունկցիոնալության վրա և չի վտանգում կոտրելու այն, ինչն արդեն աշխատում է.
- Ստանդարտ տարրերի տարրալուծման շնորհիվ նման համակարգերում ETL պրոցեսները նույն տեսքն ունեն, դրանց գրառումը ձեռնտու է ալգորիթմացմանը և, ի վերջո, ավտոմատացում.
Այս ճկունության գինն է Արտադրողականություն. Սա չի նշանակում, որ նման մոդելների վրա անհնար է հասնել ընդունելի կատարողականի: Ավելի հաճախ, քան ոչ, ձեզ կարող է պարզապես անհրաժեշտ լինել ավելի շատ ջանք և ուշադրություն մանրուքների նկատմամբ՝ ձեր ուզած չափորոշիչներին հասնելու համար:
Apps
Կազմակերպության տեսակները Տվյալների պահոց
Լրացուցիչ տեղեկություններ Data Vault-ի մասին.
Կազմակերպության տեսակները Խարիսխ մոդել
Լրացուցիչ մանրամասներ Anchor Model-ի մասին.
Համառոտ աղյուսակ՝ դիտարկված մոտեցումների ընդհանուր հատկանիշներով և տարբերություններով.
Source: www.habr.com