ERP მონაცემთა ბაზების დენორმალიზაცია და მისი გავლენა პროგრამული უზრუნველყოფის შემუშავებაზე: ტავერნის გახსნა თორტუგაში

გამარჯობა! მე მქვია ანდრეი სემენოვი, ვარ Sportmaster-ის უფროსი ანალიტიკოსი. ამ პოსტში მინდა დავაყენო ERP სისტემის მონაცემთა ბაზების დენორმალიზაციის საკითხი. განვიხილავთ ზოგად პირობებს, ასევე კონკრეტულ მაგალითს - ვთქვათ, ეს იქნება მშვენიერი მონოპოლიური ტავერნა მეკობრეებისთვის და მეზღვაურებისთვის. რომელშიც მეკობრეებს და მეზღვაურებს სხვანაირად უნდა მოემსახურონ, რადგან სილამაზის იდეები და ამ კარგი ბატონების სამომხმარებლო ნიმუშები მნიშვნელოვნად განსხვავდება.

როგორ გავხადოთ ყველა ბედნიერი? როგორ შეგიძლიათ თავიდან აიცილოთ სიგიჟე ასეთი სისტემის დიზაინისა და შენარჩუნებისას? რა უნდა გააკეთოს, თუ არა მხოლოდ ჩვეულებრივი მეკობრეები და მეზღვაურები დაიწყებენ ტავერნაში მოსვლას?

ყველაფერი ჭრის ქვეშაა. მაგრამ მოდით წავიდეთ თანმიმდევრობით.

1. შეზღუდვები და ვარაუდები

ყოველივე ზემოთქმული ეხება მხოლოდ რელაციურ მონაცემთა ბაზებს. დენორმალიზაციის შედეგები მოდიფიკაციის, წაშლისა და ჩასმის ანომალიების სახით, რომლებიც კარგად არის დაფარული, მათ შორის ინტერნეტში, არ არის გათვალისწინებული. ამ პუბლიკაციის ფარგლებს გარეთ არის შემთხვევები, როდესაც დენორმალიზაცია ჩვეულებრივი ადგილია, კლასიკური მაგალითებით: პასპორტის სერია და ნომერი, თარიღი და დრო და ა.შ.

პოსტი იყენებს ნორმალური ფორმების ინტუიციურ და პრაქტიკულად გამოსაყენებელ განმარტებებს მათემატიკური ტერმინების მითითების გარეშე. იმ ფორმით, რომლითაც ისინი შეიძლება გამოყენებულ იქნას რეალური ბიზნეს პროცესების (BP) ექსპერტიზაზე და სამრეწველო პროგრამული უზრუნველყოფის დიზაინზე.

არგუმენტირებულია, რომ მონაცემთა საწყობების დიზაინი, საანგარიშო ინსტრუმენტები და ინტეგრაციის შეთანხმებები (რომლებიც იყენებენ ინფორმაციის ცხრილის სახით წარმოდგენას) განსხვავდება ERP სისტემის მონაცემთა ბაზების დიზაინისგან იმით, რომ მოხმარების სიმარტივე და მისი მიღწევისთვის შეგნებული დენორმალიზაციის გამოყენება შეიძლება უპირატესობდეს მთლიანობას. დაცვის მონაცემები. მე ვიზიარებ ამ მოსაზრებას და ის, რაც ქვემოთ არის აღწერილი, ეხება ექსკლუზიურად ERP სისტემების ძირითად მონაცემებსა და ტრანზაქციის მონაცემთა მოდელებს.

ნორმალური ფორმების ახსნა მოცემულია მაგალითის გამოყენებით, რომელიც გასაგებია ყოველდღიურ დონეზე მკითხველთა უმეტესობისთვის. თუმცა, როგორც ვიზუალური ილუსტრაცია, 4-5 აბზაცებში განზრახ „გამოგონილი“ დავალება იყო გამოყენებული. თუ ამას არ გააკეთებთ და აიღებთ სახელმძღვანელოს მაგალითს, მაგალითად, იმავე შეკვეთის შენახვის მოდელს მე-2 პუნქტიდან, შეიძლება აღმოჩნდეთ სიტუაციაში, როდესაც მკითხველის ყურადღება გადაინაცვლებს პროცესის შემოთავაზებული დაშლისგან მოდელად. პირადი გამოცდილება და აღქმა, თუ როგორ უნდა აშენდეს პროცესები და მოდელები IS-ში მონაცემების შესანახად. სხვა სიტყვებით რომ ვთქვათ, აიღეთ ორი კვალიფიციური IT ანალიტიკოსი, მიეცით ერთმა მომსახურება გაუწიოს მგზავრების გადამყვან ლოგისტიკოსებს, მეორე კი მიკროჩიპების წარმოებისთვის მანქანების გადამზიდველ ლოჯისტიკოსებს. სთხოვეთ მათ, ავტომატური 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, საცავში დარჩენილი ნაშთებიდან გამომდინარე, წარმოქმნის შესყიდვის მოთხოვნას მართვის სისტემაში.

მიუხედავად იმისა, რომ ადრეული გაფრთხილების სისტემა შეიძლება შემუშავებული იყოს თქვენი შიდა IT-ის მიერ, ბარის რობოტის მართვის პროგრამა შესაძლოა შექმნილი იყოს გარე კონტრაქტორის მიერ სპეციალურად თქვენი ბიზნესისთვის. და საწყობების მართვის სისტემები და მომწოდებლებთან ურთიერთობა არის ბაზრიდან მორგებული შეფუთული გადაწყვეტილებები.

5. დენორმალიზაციის მაგალითები და მისი გავლენა პროგრამული უზრუნველყოფის შემუშავებაზე

ბიზნეს პროცესის შემუშავებისას, გამოკითხულმა ექსპერტებმა ერთხმად განაცხადეს, რომ მთელ მსოფლიოში მეკობრეები სვამენ რომს და წვერს ძვლის სავარცხლებით ივარცხნიან, მეზღვაურები კი ჩაის თმით და ყოველთვის გაპარსულნი არიან.

კლიენტის ტიპების დირექტორია ჩნდება ორი მნიშვნელობით: 1 - მეკობრეები, 2 - მეზღვაურები, საერთო კომპანიის მთელი საინფორმაციო სქემისთვის.

კლიენტის შეტყობინებების სისტემა დაუყოვნებლივ ინახავს გამოსახულების დამუშავების შედეგს, როგორც აღიარებული კლიენტის იდენტიფიკატორად (ID) და მის ტიპს: მეზღვაური ან მეკობრე.

აღიარებული ობიექტის ID
კლიენტის კატეგორია

100500
Pirate

100501
Pirate

100502
მეზღვაური

კიდევ ერთხელ აღვნიშნოთ, რომ

1. ჩვენი მეზღვაურები რეალურად გაპარსული ხალხია
2. ჩვენი მეკობრეები სინამდვილეში წვერიანი ადამიანები არიან

რა პრობლემები უნდა აღმოიფხვრას ამ შემთხვევაში, რათა ჩვენი სტრუქტურა მიისწრაფვის მესამე ნორმალური ფორმისკენ:

• ატრიბუტის ატომურობის დარღვევა - კლიენტის კატეგორია
• გაანალიზებული ფაქტისა და დასკვნის ერთ ცხრილში შერევა
• ფიქსირებული ფუნქციური ურთიერთობა სხვადასხვა ერთეულების ატრიბუტებს შორის.

ნორმალიზებული ფორმით, ჩვენ მივიღებთ ორ ცხრილს:

• აღიარების შედეგი დადგენილი მახასიათებლების ნაკრების სახით,

აღიარებული ობიექტის ID
სახის თმა

100500
დიახ

100501
დიახ

100502
არარის

• კლიენტის ტიპის განსაზღვრის შედეგი, როგორც IS-ში ჩართული ლოგიკის გამოყენება დადგენილი მახასიათებლების ინტერპრეტაციისთვის

აღიარებული ობიექტის ID
საიდენტიფიკაციო ID
კლიენტის კატეგორია

100500
100001
Pirate

100501
100002
Pirate

100502
100003
მეზღვაური

როგორ შეუძლია მონაცემთა შენახვის ნორმალიზებულმა ორგანიზაციამ ხელი შეუწყოს IP კომპლექსის განვითარებას? ვთქვათ, თქვენ მოულოდნელად მიიღეთ ახალი კლიენტები. დაე, იაპონელი მეკობრეები იყვნენ, რომლებსაც წვერი არ აქვთ, მაგრამ თუთიყუშით მხარზე დადიან და გარემოსდამცველი მეკობრეები, მათ ადვილად ამოცნობთ გრეტას ცისფერი პროფილის მარცხენა მკერდზე.

გარემოსდაცვითი მეკობრეები, ბუნებრივია, ვერ გამოიყენებენ ძვლის სავარცხლებს და მოითხოვენ ანალოგს, რომელიც დამზადებულია გადამუშავებული ზღვის პლასტმასისგან.

თქვენ უნდა გადააკეთოთ პროგრამის ალგორითმები ახალი შეყვანის შესაბამისად. თუ დაიცავთ ნორმალიზაციის წესებს, მაშინ თქვენ მოგიწევთ მხოლოდ შეავსოთ შეყვანები ზოგიერთი პროცესის ფილიალებისთვის ზოგიერთ სისტემაში და შექმნათ ახალი ფილიალები მხოლოდ იმ შემთხვევებისთვის და იმ IS-ებში, სადაც სახის თმას აქვს მნიშვნელობა. მაგრამ, რადგან წესები არ იყო დაცული, თქვენ მოგიწევთ გაანალიზოთ მთელი კოდი, მთელ წრეში, სადაც გამოიყენება კლიენტის ტიპის დირექტორიას მნიშვნელობები და ნათლად დაადგინოთ, რომ ერთ შემთხვევაში ალგორითმი უნდა ითვალისწინებდეს პროფესიონალს. კლიენტის აქტივობა და სხვა ფიზიკურ მახასიათებლებში.

იმ ფორმით, რომ ცდილობს ნორმალიზებისთვის, ჩვენ მივიღებთ ორ ცხრილს ოპერატიული მონაცემებით და ორი დირექტორიით:

• აღიარების შედეგი დადგენილი მახასიათებლების ნაკრების სახით,

აღიარებული ობიექტის ID
გრეტა მარცხენა მკერდზე
ჩიტი მხარზე
სახის თმა

100510
1
1
1

100511
0
0
1

100512

1
0

• კლიენტის ტიპის განსაზღვრის შედეგი (მოდით, ეს იყოს მორგებული ხედი, რომელშიც ნაჩვენებია დირექტორიებიდან აღწერილობები)

ნიშნავს თუ არა გამოვლენილი დენორმალიზაცია, რომ სისტემები არ შეიძლება შეიცვალოს ახალი პირობების დასაკმაყოფილებლად? Რათქმაუნდა არა. თუ წარმოვიდგენთ, რომ ყველა საინფორმაციო სისტემა შეიქმნა ერთი გუნდის მიერ, პერსონალის ნულოვანი ბრუნვით, განვითარებული მოვლენები კარგად არის დოკუმენტირებული და ინფორმაცია გუნდში ზარალის გარეშე გადაიცემა, მაშინ საჭირო ცვლილებები შეიძლება განხორციელდეს უმნიშვნელო ძალისხმევით. მაგრამ თუ დავუბრუნდებით პრობლემის საწყის პირობებს, 1,5 კლავიატურა წაიშლება მხოლოდ ერთობლივი განხილვის ოქმების დასაბეჭდად და კიდევ 0,5 შესყიდვის პროცედურების დამუშავებისთვის.

ზემოხსენებულ მაგალითში სამივე ნორმალური ფორმა დარღვეულია, ვცადოთ მათი ცალ-ცალკე დარღვევა.

პირველი ნორმალური ფორმის დარღვევა:

დავუშვათ, საქონელი მიეწოდება თქვენს საწყობში მომწოდებლების სასაწყობეებიდან ერთი 1.5 ტონიანი გაზელის გამოყენებით, რომელიც ეკუთვნის თქვენს ტავერნას. თქვენი შეკვეთების ზომა იმდენად მცირეა მომწოდებლების ბრუნვასთან შედარებით, რომ ისინი ყოველთვის სრულდება ერთი-ერთზე წარმოების მოლოდინის გარეშე. გჭირდებათ თუ არა ცალკე ცხრილები ასეთი ბიზნესპროცესით: მანქანები, მანქანების ტიპები, აუცილებელია თუ არა განცალკევება გეგმა და ფაქტი თქვენს შეკვეთებში გამგზავრებულ მომწოდებლებთან?

წარმოიდგინეთ, რამდენი "დამატებითი" კავშირის დაწერა მოუწევთ თქვენს პროგრამისტებს, თუ ქვემოთ მოცემულ მოდელს გამოიყენებთ პროგრამის შესაქმნელად.

ვთქვათ, გადავწყვიტეთ, რომ შემოთავაზებული სტრუქტურა ზედმეტად რთულია; ჩვენს შემთხვევაში, შეკვეთის ჩანაწერში გეგმის და ფაქტის გამიჯვნა ზედმეტი ინფორმაციაა, ხოლო გენერირებული შეკვეთის სპეციფიკაცია გადაწერილია ჩამოსული საქონლის მიღების შედეგების საფუძველზე, იშვიათი შეცდომა. -არაადეკვატური ხარისხის საქონლის დახარისხება და ჩამოსვლა რეგულირდება IS-ის გარეთ.
და შემდეგ ერთ დღეს ხედავ, თუ როგორ ივსება მთელი ტავერნის დარბაზი აღშფოთებული და მოუსვენარი მეკობრეებით. Რა მოხდა?

გამოდის, რომ რაც უფრო იზრდებოდა თქვენი ბიზნესი, ასევე გაიზარდა თქვენი მოხმარება. ოდესღაც მენეჯმენტის გადაწყვეტილება მიიღეს, რომ თუ გაზელი გადატვირთული იყო მოცულობით და/ან წონით, რაც ძალზე იშვიათია, მიმწოდებელი პრიორიტეტს ანიჭებდა დატვირთვას სასმელების სასარგებლოდ.

მიუწვდომელი საქონელი დასრულდა შემდეგი შეკვეთით და დარჩა ახალი რეისით; ტავერნაში საწყობში მინიმალური ბალანსის არსებობამ შესაძლებელი გახადა არ შეემჩნია გამოტოვებული შემთხვევები.

ბოლო კონკურენტი დაიხურა პორტში და გაზელის გადატვირთვის პუნქციური შემთხვევა, რომელიც გვერდის ავლით პრიორიტეტიზაციას ეფუძნებოდა მინიმალური ბალანსისა და ავტომობილის პერიოდული გადატვირთვის ვარაუდის საფუძველზე, ჩვეულებრივი პრაქტიკა გახდა. შექმნილი სისტემა იდეალურად იმუშავებს მასში ჩადებული ალგორითმების შესაბამისად და მოკლებული იქნება ყოველგვარ შესაძლებლობას თვალყური ადევნოს დაგეგმილი შეკვეთების სისტემურ შეუსრულებლობას. მხოლოდ დაზიანებული რეპუტაცია და უკმაყოფილო მომხმარებლები შეძლებენ პრობლემის აღმოჩენას.

ყურადღებიანმა მკითხველმა შეიძლება შეამჩნია, რომ შეკვეთის რაოდენობა შეკვეთის სპეციფიკაციაში (T_ORDER_SPEC) სექცია 2 და ნაწილი 5 შეიძლება აკმაყოფილებდეს ან არ აკმაყოფილებდეს პირველი ნორმალური ფორმის მოთხოვნას. ეს ყველაფერი დამოკიდებულია იმაზე, შეიძლება თუ არა, საქონლის შერჩეული ასორტიმენტის გათვალისწინებით, არსებითად განსხვავებული საზომი ერთეული მოხვდეს იმავე სფეროში.

მეორე ნორმალური ფორმის დარღვევა:

რაც უფრო იზრდება თქვენი საჭიროებები, თქვენ ყიდულობთ კიდევ რამდენიმე მანქანას სხვადასხვა ზომის. ზემოაღნიშნულ კონტექსტში, ავტომობილის კატალოგის შექმნა ზედმეტად ითვლებოდა; შედეგად, მონაცემთა დამუშავების ყველა ალგორითმი, რომელიც ემსახურება მიწოდების და საწყობის საჭიროებებს, აღიქვამს ტვირთის გადაადგილებას მიმწოდებლიდან საწყობში, როგორც ექსკლუზიურად 1,5 ტონიანი ფრენის. გაზელი. ასე რომ, ახალი მანქანების შეძენასთან ერთად, თქვენ კვლავ ქმნით სატრანსპორტო საშუალების დირექტორიას, მაგრამ მისი დასრულებისას, თქვენ მოგიწევთ გაანალიზოთ ყველა კოდი, რომელიც მიუთითებს ტვირთის მოძრაობაზე, რათა გაარკვიოთ, არის თუ არა თითოეულ კონკრეტულ ადგილას მითითებები მახასიათებლებზე. იმ მანქანისა, საიდანაც დაიწყო ბიზნესი.

მესამე ნორმალური ფორმის დარღვევა:

რაღაც მომენტში იწყებ ლოიალობის პროგრამის შექმნას, ჩნდება რეგულარული მომხმარებლის ჩანაწერი. მაგალითად, რატომ უნდა დახარჯოთ დრო მატერიალური ხედების შექმნაზე, რომლებიც ინახავს ცალკეულ კლიენტზე გაყიდვების აგრეგირებულ მონაცემებს ანგარიშგებაში გამოსაყენებლად და ანალიტიკურ სისტემებში გადასატანად, თუ ლოიალურობის პროგრამის დასაწყისში ყველაფერი, რაც მომხმარებელს აინტერესებს, შეიძლება განთავსდეს კლიენტის ჩანაწერში. ? და, მართლაც, ერთი შეხედვით, აზრი არ აქვს. მაგრამ ყოველ ჯერზე, როცა თქვენი ბიზნესი აკავშირებს, მაგალითად, გაყიდვების ახალ არხებს, თქვენს ანალიტიკოსებს შორის უნდა იყოს ვინმე, ვინც დაიმახსოვრებს, რომ ასეთი აგრეგაციის ატრიბუტი არსებობს.

ყოველი ახალი პროცესის შემუშავებისას, მაგალითად, გაყიდვები ინტერნეტში, გაყიდვები დისტრიბუტორების მეშვეობით, რომლებიც დაკავშირებულია საერთო ლოიალობის სისტემასთან, ვინმემ უნდა გაითვალისწინოს, რომ ყველა ახალმა პროცესმა უნდა უზრუნველყოს მონაცემთა მთლიანობა კოდის დონეზე. ინდუსტრიული მონაცემთა ბაზისთვის, რომელსაც აქვს ათასი ცხრილი, ეს შეუძლებელი ამოცანაა.

გამოცდილმა დეველოპერმა, რა თქმა უნდა, იცის, როგორ შეაჩეროს ყველა ზემოთ ნახსენები პრობლემა, მაგრამ, ჩემი აზრით, გამოცდილი ანალიტიკოსის ამოცანა არ არის მათი გამოტანა.

მსურს მადლობა გადავუხადო წამყვან დეველოპერს ევგენი იარუხინს პუბლიკაციის მომზადების დროს მისი ღირებული გამოხმაურებისთვის.

ლიტერატურა

https://habr.com/en/post/254773/
კონოლი თომასი, ბეგ ქეროლაინი. Მონაცემთა ბაზა. დიზაინი, განხორციელება და მხარდაჭერა. თეორია და პრაქტიკა

წყარო: www.habr.com