ERP տվյալների բազաների ապանորմալացում և դրա ազդեցությունը ծրագրային ապահովման մշակման վրա. Պանդոկ բացել Տորտուգայում

Բարեւ Ձեզ! Ես Անդրեյ Սեմենովն եմ, ես Sportmaster-ի ավագ վերլուծաբան եմ։ Այս գրառման մեջ ես ուզում եմ բարձրացնել ERP համակարգի տվյալների բազաների ապանորմալացման հարցը։ Մենք կանդրադառնանք ընդհանուր պայմաններին, ինչպես նաև կոնկրետ օրինակին. ասենք, որ դա կլինի հիանալի մենաշնորհային պանդոկ ծովահենների և նավաստիների համար: Որում ծովահեններին և նավաստիներին պետք է տարբեր կերպ մատուցել, քանի որ այս լավ պարոնների գեղեցկության և սպառողական օրինաչափությունների գաղափարները զգալիորեն տարբերվում են:

Ինչպե՞ս ուրախացնել բոլորին: Ինչպե՞ս կարող եք խուսափել խելագարությունից՝ նախագծելով և պահպանելով նման համակարգը: Ի՞նչ անել, եթե ոչ միայն սովորական ծովահեններն ու նավաստիները սկսեն գալ պանդոկ:

Ամեն ինչ կտրվածքի տակ է։ Բայց արի գնանք հերթականությամբ։

1. Սահմանափակումներ և ենթադրություններ

Վերոնշյալ բոլորը վերաբերում են միայն հարաբերական տվյալների բազաներին: Դենորմալացման հետևանքները փոփոխման, ջնջման և տեղադրման անոմալիաների տեսքով, որոնք լավ լուսաբանված են, այդ թվում՝ ինտերնետում, հաշվի չեն առնվում: Այս հրապարակման շրջանակներից դուրս կան դեպքեր, երբ ապանորմալացումը սովորական տեղ է, դասական օրինակներով՝ անձնագրի սերիա և համար, ամսաթիվ և ժամ և այլն:

Գրառումն օգտագործում է նորմալ ձևերի ինտուիտիվ և գործնականում կիրառելի սահմանումներ՝ առանց մաթեմատիկական տերմինների հղումների։ Այն ձևով, որով դրանք կարող են կիրառվել իրական բիզնես գործընթացների (BP) փորձաքննության և արդյունաբերական ծրագրերի նախագծման համար:

Ենթադրվում է, որ տվյալների պահեստների, հաշվետվական գործիքների և ինտեգրման համաձայնագրերի նախագծումը (որոնք օգտագործում են տեղեկատվության աղյուսակային ներկայացում) տարբերվում են ERP համակարգի տվյալների բազաների նախագծումից, քանի որ սպառման հեշտությունը և դրա հասնելու համար գիտակցված ապանորմալացման օգտագործումը կարող է գերակայություն ունենալ ամբողջականությունից: պաշտպանության տվյալները։ Ես կիսում եմ այս կարծիքը, և ստորև նկարագրվածը վերաբերում է բացառապես հիմնական տվյալների և ERP համակարգերի գործարքային տվյալների մոդելներին:

Սովորական ձևերի բացատրությունը տրվում է ընթերցողների մեծամասնության համար ամենօրյա մակարդակում հասկանալի օրինակի միջոցով: Այնուամենայնիվ, որպես տեսողական նկարազարդում, 4-5-րդ պարբերություններում միտումնավոր օգտագործվել է «գեղարվեստական» առաջադրանք: Եթե ​​դուք դա չանեք և չվերցնեք դասագրքերի օրինակ, օրինակ, նույն պատվերի պահպանման մոդելը 2-րդ կետից, դուք կարող եք հայտնվել մի իրավիճակում, երբ ընթերցողի ուշադրությունը կտեղափոխվի գործընթացի առաջարկվող տարրալուծումից մոդելի, անձնական փորձին և ընկալմանը, թե ինչպես պետք է կառուցվեն IS-ում տվյալների պահպանման գործընթացները և մոդելները: Այսինքն՝ երկու որակյալ ՏՏ վերլուծաբան վերցրեք, մեկը թող ծառայություններ մատուցի ուղեւորներ տեղափոխող լոգիստիկներին, մյուսը՝ միկրոչիպերի արտադրության մեքենաներ տեղափոխող լոգիստիկներին։ Խնդրեք նրանց, առանց ավտոմատացված BP-ների նախօրոք քննարկման, ստեղծել տվյալների մոդել՝ երկաթուղային ճանապարհորդության մասին տեղեկատվության պահպանման համար:

Ոչ զրոյական հավանականություն կա, որ առաջարկվող մոդելներում դուք կգտնեք ոչ միայն նկատելիորեն տարբեր ատրիբուտների շարք, այլև սուբյեկտների տարբեր խմբեր, քանի որ յուրաքանչյուր վերլուծաբան կհիմնվի իրեն ծանոթ գործընթացների և առաջադրանքների վրա: Եվ նման իրավիճակում հնարավոր չէ ասել, թե որ մոդելն է «ճիշտ», քանի որ չկա գնահատման չափանիշ։

2. Նորմալ ձեւեր

Տվյալների բազայի առաջին նորմալ ձևը պահանջում է բոլոր հատկանիշների ատոմականություն:
Մասնավորապես, եթե A օբյեկտն ունի ոչ առանցքային հատկանիշներ a և b, այնպես, որ c=f(a,b) և A օբյեկտը նկարագրող աղյուսակում պահում եք c հատկանիշի արժեքը, ապա տվյալների բազայում խախտվում է առաջին նորմալ ձևը: . Օրինակ, եթե պատվերի հստակեցումը ցույց է տալիս մի քանակ, որի չափման միավորները կախված են ապրանքի տեսակից. մի դեպքում այն ​​կարող է լինել կտորներ, մյուս դեպքում լիտր, երրորդում՝ կտորներից բաղկացած փաթեթներում (վերևի Good_count_WR մոդելում) , ապա տվյալների բազայում խախտվում է ատրիբուտների ատոմականությունը։ Այս դեպքում, որպեսզի ասեք, թե ինչ պետք է լինի պատվերի ճշգրտման աղյուսակային կլաստերը, ձեզ անհրաժեշտ է IS-ում աշխատանքային գործընթացի նպատակային նկարագրություն, և քանի որ գործընթացները կարող են տարբեր լինել, կարող են լինել բազմաթիվ «ճիշտ» տարբերակներ:

Տվյալների բազայի երկրորդ նորմալ ձևը պահանջում է համապատասխանություն առաջին ձևին և իր աղյուսակին յուրաքանչյուր սուբյեկտի համար, որը կապված է IS-ում աշխատանքային գործընթացի հետ: Եթե ​​մեկ աղյուսակում առկա են c=f1(a) և d=f2(b) կախվածություններ, իսկ c=f3(b) կախվածություն չկա, ապա աղյուսակում երկրորդ նորմալ ձևը խախտվում է։ Վերևի օրինակում պատվերի և հասցեի միջև կախվածություն չկա Պատվերի աղյուսակում: Փոխեք փողոցի կամ քաղաքի անունը, և դուք ոչ մի ազդեցություն չեք ունենա պատվերի հիմնական հատկանիշների վրա:

Երրորդ նորմալ ձևի տվյալների բազա պահանջում է համապատասխանություն երկրորդ նորմալ ձևի հետ և տարբեր սուբյեկտների ատրիբուտների միջև ֆունկցիոնալ կախվածության բացակայություն: Այս կանոնը կարող է ձևակերպվել հետևյալ կերպ՝ «այն ամենը, ինչ կարելի է հաշվարկել, պետք է հաշվարկվի»։ Այլ կերպ ասած, եթե կան երկու օբյեկտներ A և B: A օբյեկտի ատրիբուտները պահող աղյուսակում դրսևորվում է C հատկանիշը, իսկ B առարկան ունի b հատկանիշ, այնպես որ գոյություն ունի c=f4(b), ապա երրորդ նորմալ ձևը. խախտվում է. Ստորև բերված օրինակում Պատվերի գրառման մեջ «Կտորների քանակ» հատկանիշը (Total_count_WR) ակնհայտորեն պնդում է, որ խախտում է երրորդ նորմալ ձևը:

3. Նորմալացման կիրառման իմ մոտեցումը

1. Միայն թիրախային ավտոմատացված բիզնես գործընթացը կարող է վերլուծաբանին տրամադրել չափորոշիչներ՝ տվյալների պահպանման մոդել ստեղծելիս սուբյեկտների և ատրիբուտների նույնականացման համար: Գործընթացի մոդելի ստեղծումը պարտադիր պայման է տվյալների նորմալ մոդել ստեղծելու համար:

2. Խիստ իմաստով երրորդ նորմալ ձևի ձեռքբերումը կարող է գործնականում չլինել ERP համակարգերի ստեղծման իրական պրակտիկայում, եթե բավարարված են հետևյալ պայմաններից մի քանիսը կամ բոլորը.

• ավտոմատացված գործընթացները հազվադեպ են ենթարկվում փոփոխության,
• Հետազոտության և զարգացման ժամկետները խիստ են,
• Տվյալների ամբողջականության պահանջները համեմատաբար ցածր են (արդյունաբերական ծրագրային ապահովման հնարավոր սխալները չեն հանգեցնում ծրագրային ապահովման հաճախորդի կողմից փողի կամ հաճախորդների կորստի)
• եւ այլն:

Նկարագրված պայմաններում որոշ օբյեկտների կյանքի ցիկլի և դրանց հատկանիշների նույնականացման և նկարագրման ծախսերը կարող են արդարացված չլինել տնտեսական արդյունավետության տեսանկյունից:

3. Արդեն ստեղծված IS-ում տվյալների մոդելի ապանորմալացման ցանկացած հետևանք կարող է մեղմվել կոդի մանրակրկիտ նախնական ուսումնասիրության և փորձարկման միջոցով:

4. Ապանորմալացումը աշխատանքի ծախսերը տվյալների աղբյուրների հետազոտման և բիզնես գործընթացի նախագծման փուլից դեպի զարգացման փուլ, ներդրման շրջանից համակարգի զարգացման փուլ տեղափոխելու միջոց է:

5. Ցանկալի է ձգտել տվյալների բազայի երրորդ նորմալ ձևին, եթե.

• Ավտոմատացված բիզնես գործընթացների փոփոխության ուղղությունը դժվար է կանխատեսել
• Իրականացման և/կամ զարգացման թիմում առկա է աշխատանքի թույլ բաժանում
• Ինտեգրացիոն շղթայում ընդգրկված համակարգերը զարգանում են ըստ իրենց սեփական պլանների
• Տվյալների անհամապատասխանությունը կարող է հանգեցնել նրան, որ ընկերությունը կորցնի հաճախորդներ կամ գումար

6. Տվյալների մոդելի նախագծումը պետք է իրականացվի վերլուծաբանի կողմից միայն նպատակային բիզնես գործընթացի մոդելների և IS-ում գործընթացի հետ կապված: Եթե ​​մշակողը նախագծում է տվյալների մոդել, նա պետք է ընկղմվի առարկայի տարածքում այնքանով, որ, մասնավորապես, հասկանա հատկանիշի արժեքների տարբերությունը՝ անհրաժեշտ պայման ատոմային ատրիբուտները մեկուսացնելու համար: Այսպիսով՝ ստանձնելով անսովոր գործառույթներ։

4 Պատկերազարդման խնդիր

Ենթադրենք, դուք նավահանգստում ունեք փոքրիկ ռոբոտացված պանդոկ: Ձեր շուկայի հատվածը՝ նավաստիներ և ծովահեններ, ովքեր մտնում են նավահանգիստ և ընդմիջման կարիք ունեն: Նավաստիներին ուրցով թեյ եք վաճառում, իսկ ծովահեններին մորուքը սանրելու համար ռոմ և ոսկորների սանրեր։ Բուն պանդոկում ծառայությունը մատուցում են ռոբոտ տանտիրուհին և ռոբոտ բարմենը։ Ձեր բարձր որակի և ցածր գների շնորհիվ դուք դուրս եք մղել ձեր մրցակիցներին, որպեսզի նավից իջնող բոլորը գան ձեր պանդոկը, որը միակն է նավահանգստում։

Պանդոկի տեղեկատվական համակարգերի համալիրը բաղկացած է հետևյալ ծրագրերից.

• Հաճախորդի մասին վաղ նախազգուշացման համակարգ, որը ճանաչում է իր կատեգորիան՝ հիմնվելով բնորոշ հատկանիշների վրա
• Ռոբոտ տանտիրուհիների և ռոբոտ բարմենների կառավարման համակարգ
• Պահեստի և առաքման կառավարման համակարգ մինչև վաճառքի կետ
• Մատակարարների հետ հարաբերությունների կառավարման համակարգ (SURP)

Գործընթացը `

Վաղ նախազգուշացման համակարգը ճանաչում է նավը լքող մարդկանց: Եթե ​​մարդը սափրված է, ապա նա ճանաչվում է որպես նավաստի, իսկ եթե հայտնաբերվում է, որ մարդը մորուք ունի, ապա նա ճանաչվում է որպես ծովահեն:

Մտնելով պանդոկ՝ հյուրը լսում է ռոբոտ տանտիրուհուց իր կատեգորիային համապատասխան ողջույնը, օրինակ՝ «Հո-հո-հո, սիրելի ծովահեն, գնա No սեղանի մոտ...

Հյուրը գնում է նշված սեղանի մոտ, որտեղ ռոբոտ-բարմենն արդեն նրա համար ապրանքներ է պատրաստել՝ համապատասխան կատեգորիայի։ Ռոբոտ-բարմենը տեղեկատվություն է փոխանցում պահեստային համակարգին, որ առաքման հաջորդ մասը պետք է ավելացվի, պահեստի IS-ը, հիմնվելով պահեստում մնացած մնացորդների վրա, կառավարման համակարգում ստեղծում է գնման հարցում:

Թեև վաղ նախազգուշացման համակարգը կարող է մշակված լինել ձեր ներքին ՏՏ-ի կողմից, բար ռոբոտի կառավարման ծրագիրը կարող է ստեղծվել արտաքին կապալառուի կողմից՝ հատուկ ձեր բիզնեսի համար: Իսկ պահեստների կառավարման և մատակարարների հետ հարաբերությունների համակարգերը շուկայական հարմարեցված փաթեթավորված լուծումներ են:

5. Ապանորմալացման օրինակներ և դրա ազդեցությունը ծրագրային ապահովման մշակման վրա

Բիզնես գործընթաց նախագծելիս հարցված մասնագետները միաձայն հայտարարեցին, որ ամբողջ աշխարհում ծովահենները ռոմ են խմում և մորուքը սանրում են ոսկրային սանրերով, իսկ նավաստիները թեյ են խմում ուրցով և միշտ սափրված են:

Հաճախորդների տեսակների գրացուցակ է հայտնվում երկու արժեքով. 1 - ծովահեններ, 2 - նավաստիներ, որոնք ընդհանուր են ընկերության ողջ տեղեկատվական շրջանի համար:

Հաճախորդների ծանուցման համակարգը անմիջապես պահպանում է պատկերի մշակման արդյունքը որպես ճանաչված հաճախորդի նույնացուցիչ (ID) և դրա տեսակը՝ նավաստի կամ ծովահեն:

Ճանաչված օբյեկտի ID
Հաճախորդի կատեգորիա

100500
Ծովահեն

100501
Ծովահեն

100502
Նավաստին

Եվս մեկ անգամ նշենք, որ

1. Մեր նավաստիները իրականում սափրված մարդիկ են
2. Մեր ծովահեններն իրականում մորուքավոր մարդիկ են

Այս դեպքում ինչ խնդիրներ պետք է վերացվեն, որպեսզի մեր կառույցը ձգտի երրորդ նորմալ ձևի.

• հատկանիշի ատոմականության խախտում - Հաճախորդի կատեգորիա
• վերլուծված փաստն ու եզրակացությունը մեկ աղյուսակում խառնելով
• ֆիքսված ֆունկցիոնալ հարաբերություն տարբեր սուբյեկտների ատրիբուտների միջև:

Նորմալացված ձևով մենք կստանանք երկու աղյուսակ.

• ճանաչման արդյունքը սահմանված հատկանիշների մի շարքի տեսքով,

Ճանաչված օբյեկտի ID
Դեմքի մազեր

100500
Այո

100501
Այո

100502
Ոչ

• հաճախորդի տեսակի որոշման արդյունքը որպես IS-ում ներդրված տրամաբանության կիրառում սահմանված բնութագրերը մեկնաբանելու համար

Ճանաչված օբյեկտի ID
Նույնականացման ID
Հաճախորդի կատեգորիա

100500
100001
Ծովահեն

100501
100002
Ծովահեն

100502
100003
Նավաստին

Ինչպե՞ս կարող է տվյալների պահպանման նորմալացված կազմակերպությունը նպաստել IP համալիրի զարգացմանը: Ենթադրենք, դուք հանկարծ նոր հաճախորդներ եք ստանում: Թող ճապոնացի ծովահենները լինեն, ովքեր մորուք չունեն, բայց քայլում են թութակն ուսին, իսկ բնապահպան ծովահենները, որոնց հեշտությամբ կարող եք ճանաչել Գրետայի կապույտ պրոֆիլով ձախ կրծքին:

Բնապահպանական ծովահենները, բնականաբար, չեն կարող օգտագործել ոսկրային սանրեր և պահանջում են վերամշակված ծովային պլաստիկից պատրաստված անալոգիա:

Դուք պետք է վերամշակեք ծրագրի ալգորիթմները նոր մուտքերի համաձայն: Եթե ​​պահպանվեին նորմալացման կանոնները, ապա դուք պետք է լրացնեիք միայն որոշ համակարգերի որոշ պրոցեսի ճյուղերի մուտքերը և նոր ճյուղեր ստեղծեք միայն այն դեպքերի համար և այն IS-ներում, որտեղ կարևոր է դեմքի մազերը: Բայց քանի որ կանոնները չեն պահպանվել, դուք ստիպված կլինեք վերլուծել ամբողջ կոդը, ամբողջ միացումում, որտեղ օգտագործվում են հաճախորդի տիպի գրացուցակի արժեքները և հստակ սահմանեք, որ մի դեպքում ալգորիթմը պետք է հաշվի առնի պրոֆեսիոնալ հաճախորդի ակտիվությունը և այլ ֆիզիկական հատկանիշները:

Այն ձևով, որը որոնում նորմալացնելու համար մենք կստանանք երկու աղյուսակ՝ գործառնական տվյալներով և երկու գրացուցակով.

• ճանաչման արդյունքը սահմանված հատկանիշների մի շարքի տեսքով,

Ճանաչված օբյեկտի ID
Գրետան ձախ կրծքին
Թռչուն ուսին
Դեմքի մազեր

100510
1
1
1

100511
0
0
1

100512

1
0

• հաճախորդի տեսակի որոշման արդյունքը (թող դա լինի հատուկ դիտում, որտեղ ցուցադրվում են գրացուցակների նկարագրությունները)

Արդյո՞ք հայտնաբերված ապանորմալացումը նշանակում է, որ համակարգերը չեն կարող փոփոխվել նոր պայմաններին համապատասխանելու համար: Իհարկե ոչ. Եթե ​​պատկերացնենք, որ բոլոր տեղեկատվական համակարգերը ստեղծվել են մեկ թիմի կողմից՝ անձնակազմի զրոյական շրջանառությամբ, զարգացումները լավ փաստագրված են, և տեղեկատվությունը թիմում փոխանցվում է առանց կորուստների, ապա անհրաժեշտ փոփոխությունները կարող են կատարվել աննշան ջանքերով։ Բայց եթե վերադառնանք խնդրի սկզբնական պայմաններին, 1,5 ստեղնաշար կջնջվի միայն համատեղ քննարկումների արձանագրություններ տպելու համար, ևս 0,5-ը՝ գնումների ընթացակարգերի մշակման համար։

Վերոնշյալ օրինակում խախտված են բոլոր երեք նորմալ ձևերը, փորձենք դրանք խախտել առանձին։

Առաջին նորմալ ձևի խախտում.

Ենթադրենք, ապրանքները մատակարարների պահեստներից առաքվում են ձեր պահեստ՝ վերցնելով ձեր պանդոկին պատկանող 1.5 տոննա կշռող գազել: Ձեր պատվերների չափը այնքան փոքր է մատակարարների շրջանառության համեմատ, որ դրանք միշտ կատարվում են մեկ առ մեկ՝ չսպասելով արտադրությանը: Ձեզ անհրաժեշտ են նման բիզնես գործընթացով առանձին աղյուսակներ՝ տրանսպորտային միջոցներ, տրանսպորտային միջոցների տեսակներ, արդյոք անհրաժեշտ է արդյոք տարանջատել պլանն ու փաստը մեկնած մատակարարներին ձեր պատվերների մեջ:

Պարզապես պատկերացրեք, թե որքան «լրացուցիչ» կապեր պետք է գրեն ձեր ծրագրավորողները, եթե օգտագործեք ստորև բերված մոդելը ծրագիր մշակելու համար:

Ենթադրենք, մենք որոշեցինք, որ առաջարկվող կառուցվածքն անհարկի բարդ է, մեր դեպքում, պլանի և պատվերի գրանցման մեջ փաստի առանձնացումը ավելորդ տեղեկատվություն է, իսկ ստացված պատվերի ճշգրտումը վերաշարադրվում է՝ ելնելով ժամանած ապրանքների ընդունման արդյունքներից, հազվադեպ սխալներից: - Անբավարար որակի ապրանքների դասակարգումը և ժամանումը կարգավորվում են IS-ից դուրս:
Եվ հետո մի օր տեսնում ես, թե ինչպես է ամբողջ պանդոկի դահլիճը լցված վրդովված ու անճաշակ ծովահեններով։ Ինչ է պատահել?

Ստացվում է, որ ձեր բիզնեսի աճին զուգահեռ աճել է ձեր սպառումը: Ժամանակին ղեկավարության որոշում է կայացվել, որ եթե գազելը ծանրաբեռնված է ծավալով և/կամ քաշով, ինչը չափազանց հազվադեպ է, մատակարարը նախապատվությունը տալիս է բեռին հօգուտ խմիչքի:

Չառաքված ապրանքներն ավարտվեցին հաջորդ պատվերով և մեկնեցին նոր չվերթով, պանդոկի պահեստում նվազագույն մնացորդի առկայությունը թույլ տվեց չնկատել բաց թողնված դեպքերը:

Վերջին մրցակիցը փակվեց նավահանգստում, և գազելի ծանրաբեռնվածության ծակված դեպքը, որը շրջանցվեց առաջնահերթությունների հիման վրա՝ նվազագույն մնացորդի բավարարության և մեքենայի պարբերական բեռնաթափման ենթադրության հիման վրա, դարձավ սովորական պրակտիկա: Ստեղծված համակարգը իդեալականորեն կաշխատի դրանում ներդրված ալգորիթմներին համապատասխան և կզրկվի պլանավորված պատվերների կատարման համակարգված ձախողմանը հետևելու ցանկացած հնարավորությունից: Միայն վնասված հեղինակությունը և դժգոհ հաճախորդները կկարողանան բացահայտել խնդիրը:

Ուշադիր ընթերցողը կարող է նկատել, որ 2-րդ և 5-րդ բաժինների պատվերի ճշգրտման (T_ORDER_SPEC) պատվիրված քանակը կարող է բավարարել կամ չբավարարել առաջին նորմալ ձևի պահանջը: Ամեն ինչ կախված է նրանից, թե հաշվի առնելով ապրանքների ընտրված տեսականին, ըստ էության տարբեր չափման միավորները կարող են ընկնել նույն դաշտում:

Երկրորդ նորմալ ձևի խախտում.

Քանի որ ձեր կարիքները մեծանում են, դուք գնում եք ևս մի քանի տարբեր չափերի մեքենաներ: Վերոնշյալ համատեքստում տրանսպորտային միջոցների գրացուցակի ստեղծումը համարվում էր ավելորդ, արդյունքում՝ առաքման և պահեստի կարիքները սպասարկող տվյալների մշակման բոլոր ալգորիթմները ընկալում են բեռի տեղաշարժը մատակարարից պահեստ որպես բացառապես 1,5 տոննա կշռող թռիչք: գազել. Այսպիսով, նոր տրանսպորտային միջոցներ ձեռք բերելու հետ մեկտեղ, դուք դեռ ստեղծում եք տրանսպորտային միջոցների գրացուցակ, բայց այն վերջնականացնելիս դուք պետք է վերլուծեք բոլոր ծածկագրերը, որոնք վկայակոչում են բեռի շարժը, պարզելու համար, թե արդյոք յուրաքանչյուր կոնկրետ վայրում ակնարկվում են բնութագրերին: հենց այն մեքենայից, որտեղից սկսվել է բիզնեսը:

Երրորդ նորմալ ձևի խախտում.

Ինչ-որ պահի սկսում ես ստեղծել հավատարմության ծրագիր, հայտնվում է սովորական հաճախորդի գրառումը: Ինչու՞, օրինակ, ժամանակ ծախսել՝ ստեղծելով նյութական տեսակետներ, որոնք պահում են առանձին հաճախորդին վաճառքի մասին խմբավորված տվյալներ՝ հաշվետվություններ ներկայացնելու և վերլուծական համակարգեր փոխանցելու համար, եթե հավատարմության ծրագրի սկզբում այն ​​ամենը, ինչ հետաքրքրում է հաճախորդին, կարող է տեղադրվել հաճախորդի գրառումներում: ? Եվ, իրոք, առաջին հայացքից իմաստ չկա։ Բայց ամեն անգամ, երբ ձեր բիզնեսը միացնում է, օրինակ, վաճառքի նոր ուղիները, ձեր վերլուծաբանների մեջ պետք է լինի մեկը, ով կհիշի, որ նման ագրեգացիոն հատկանիշ գոյություն ունի:

Յուրաքանչյուր նոր գործընթաց նախագծելիս, օրինակ՝ վաճառքը ինտերնետում, վաճառքը դիստրիբյուտորների միջոցով, որոնք կապված են ընդհանուր հավատարմության համակարգին, ինչ-որ մեկը պետք է նկատի ունենա, որ բոլոր նոր գործընթացները պետք է ապահովեն տվյալների ամբողջականությունը կոդի մակարդակում: Հազար աղյուսակներով արդյունաբերական տվյալների բազայի համար սա անհնարին խնդիր է թվում:

Փորձառու ծրագրավորողը, իհարկե, գիտի, թե ինչպես վերացնել վերը նշված բոլոր խնդիրները, բայց, իմ կարծիքով, փորձառու վերլուծաբանի խնդիրը դրանք ջրի երես հանելը չէ։

Ցանկանում եմ իմ երախտագիտությունը հայտնել առաջատար ծրագրավորող Եվգենի Յարուխինին՝ հրապարակման պատրաստման ընթացքում ունեցած արժեքավոր արձագանքի համար։

Գրականություն

https://habr.com/en/post/254773/
Քոնոլի Թոմաս, Բեգ Քերոլայն. Տվյալների բազա. Դիզայն, իրականացում և աջակցություն: Տեսություն և պրակտիկա

Source: www.habr.com