ईआरपी डेटाबेसचे सामान्यीकरण आणि सॉफ्टवेअर डेव्हलपमेंटवर त्याचा प्रभाव: टॉर्टुगामध्ये एक भोजनालय उघडणे

नमस्कार! माझे नाव आंद्रे सेमेनोव्ह आहे, मी स्पोर्टमास्टरचा वरिष्ठ विश्लेषक आहे. या पोस्टमध्ये मला ईआरपी सिस्टम डेटाबेसच्या सामान्यीकरणाचा मुद्दा मांडायचा आहे. आम्ही सामान्य परिस्थिती, तसेच एक विशिष्ट उदाहरण पाहू - चला असे म्हणूया की हे समुद्री चाच्यांसाठी आणि खलाशींसाठी एक अद्भुत मक्तेदारी भोजनालय असेल. ज्यामध्ये समुद्री चाच्यांना आणि खलाशांना वेगवेगळ्या प्रकारे सेवा दिली पाहिजे, कारण या चांगल्या सज्जनांच्या सौंदर्य आणि ग्राहक पद्धतींच्या कल्पना लक्षणीय भिन्न आहेत.

सर्वांना आनंदी कसे करावे? अशा प्रणालीची रचना आणि देखरेख करण्यासाठी तुम्ही वेडे कसे होऊ शकता? केवळ नेहमीचे समुद्री चाचे आणि खलाशी खानावळीत येऊ लागले तर काय करावे?

सर्व काही कट अंतर्गत आहे. पण क्रमाने जाऊया.

1. मर्यादा आणि गृहीतके

वरील सर्व फक्त रिलेशनल डेटाबेसेसवर लागू होतात. बदल, हटवणे आणि अंतर्भूत करण्याच्या विसंगतींच्या स्वरुपात विकृतीचे परिणाम, जे इंटरनेटसह चांगल्या प्रकारे संरक्षित आहेत, विचारात घेतले जात नाहीत. या प्रकाशनाच्या व्याप्तीच्या बाहेर अशी प्रकरणे आहेत जिथे विकृतीकरण एक सामान्य स्थान आहे, क्लासिक उदाहरणांसह: पासपोर्ट मालिका आणि संख्या, तारीख आणि वेळ इ.

पोस्टमध्ये गणितीय संज्ञांचा संदर्भ न घेता, सामान्य स्वरूपांच्या अंतर्ज्ञानी आणि व्यावहारिकपणे लागू होणार्‍या व्याख्या वापरल्या आहेत. ज्या फॉर्ममध्ये ते वास्तविक व्यवसाय प्रक्रिया (BP) आणि औद्योगिक सॉफ्टवेअरच्या डिझाइनच्या परीक्षेसाठी लागू केले जाऊ शकतात.

असा युक्तिवाद केला जातो की डेटा वेअरहाऊसची रचना, अहवाल साधने आणि एकत्रीकरण करार (जे माहितीचे सारणीबद्ध प्रतिनिधित्व वापरतात) ईआरपी सिस्टम डेटाबेसच्या डिझाइनपेक्षा उपभोगाच्या सुलभतेमध्ये भिन्न आहेत आणि ते साध्य करण्यासाठी जागरूक विकृतीकरणाचा वापर अखंडतेपेक्षा प्राधान्य देऊ शकतो. संरक्षण डेटा. मी हे मत सामायिक करतो, आणि जे खाली वर्णन केले आहे ते पूर्णपणे मुख्य डेटा आणि 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. जर खालीलपैकी काही किंवा सर्व अटी पूर्ण केल्या असतील तर कठोर अर्थाने तिसरे सामान्य स्वरूप प्राप्त करणे ईआरपी प्रणाली तयार करण्याच्या वास्तविक सरावात व्यावहारिक असू शकत नाही:

• स्वयंचलित प्रक्रिया क्वचितच बदलाच्या अधीन असतात,
• संशोधन आणि विकासासाठी मुदती घट्ट आहेत,
• डेटा अखंडतेसाठी आवश्यकता तुलनेने कमी आहेत (औद्योगिक सॉफ्टवेअरमधील संभाव्य त्रुटींमुळे सॉफ्टवेअर ग्राहकांचे पैसे किंवा क्लायंटचे नुकसान होत नाही)
• आणि यासारखे

वर्णन केलेल्या परिस्थितीत, काही वस्तूंचे जीवनचक्र आणि त्यांचे गुणधर्म ओळखणे आणि त्यांचे वर्णन करणे हे आर्थिक कार्यक्षमतेच्या दृष्टिकोनातून न्याय्य असू शकत नाही.

3. आधीपासून तयार केलेल्या IS मधील डेटा मॉडेलच्या विकृतीकरणाचे कोणतेही परिणाम कोड आणि चाचणीच्या सखोल प्राथमिक अभ्यासाद्वारे कमी केले जाऊ शकतात.

4. डीनोर्मलायझेशन हा डेटा स्त्रोतांच्या संशोधनाच्या टप्प्यापासून आणि व्यावसायिक प्रक्रियेची रचना करण्याच्या टप्प्यापासून, अंमलबजावणीच्या कालावधीपासून सिस्टम विकासाच्या कालावधीपर्यंत मजूर खर्च हस्तांतरित करण्याचा एक मार्ग आहे.

5. डेटाबेसच्या तिसऱ्या सामान्य स्वरूपासाठी प्रयत्न करणे उचित आहे जर:

• स्वयंचलित व्यवसाय प्रक्रियेतील बदलाची दिशा सांगणे कठीण आहे
• अंमलबजावणी आणि/किंवा विकास कार्यसंघामध्ये श्रमांची कमकुवत विभागणी आहे
• इंटिग्रेशन सर्किटमध्ये समाविष्ट असलेल्या सिस्टम्स त्यांच्या स्वतःच्या योजनांनुसार विकसित होतात
• डेटा विसंगतीमुळे कंपनी ग्राहक किंवा पैसे गमावू शकते

6. डेटा मॉडेलची रचना विश्लेषकाद्वारे केवळ लक्ष्यित व्यवसाय प्रक्रियेचे मॉडेल आणि IS मधील प्रक्रियेच्या संबंधात केली पाहिजे. जर विकसक डेटा मॉडेल डिझाइन करत असेल, तर त्याला स्वतःला विषय क्षेत्रात इतके विसरावे लागेल की, विशेषत: त्याला विशेषता मूल्यांमधील फरक समजेल - अणू गुणधर्म वेगळे करण्यासाठी एक आवश्यक अट. अशा प्रकारे, असामान्य कार्ये घेणे.

4 चित्रणासाठी समस्या

समजा तुमच्याकडे बंदरात एक लहान रोबोटिक खानावळ आहे. तुमचा बाजार विभाग: खलाशी आणि चाचे जे बंदरात येतात आणि त्यांना विश्रांतीची गरज असते. तुम्ही खलाशांना थाईमसह चहा आणि समुद्री चाच्यांना दाढी वाढवण्यासाठी रम आणि हाडांच्या पोळ्या विकता. टॅव्हर्नमध्येच सेवा रोबोट होस्टेस आणि रोबोट बारटेंडरद्वारे प्रदान केली जाते. तुमच्या उच्च गुणवत्तेबद्दल आणि कमी किमतींबद्दल धन्यवाद, तुम्ही तुमच्या प्रतिस्पर्ध्यांना हुसकावून लावले आहे, जेणेकरुन जहाजातून उतरणारे प्रत्येकजण तुमच्या टॅव्हर्नमध्ये येतात, जे बंदरातील एकमेव आहे.

टेव्हर्न इन्फॉर्मेशन सिस्टम कॉम्प्लेक्समध्ये खालील सॉफ्टवेअर असतात:

• क्लायंटबद्दल प्रारंभिक चेतावणी प्रणाली जी वैशिष्ट्यपूर्ण वैशिष्ट्यांवर आधारित त्याची श्रेणी ओळखते
• रोबोट होस्टेस आणि रोबोट बारटेंडरसाठी नियंत्रण प्रणाली
• वेअरहाऊस आणि डिलिव्हरी मॅनेजमेंट सिस्टम ते पॉइंट ऑफ सेल
• पुरवठादार संबंध व्यवस्थापन प्रणाली (SURP)

प्रक्रिया:

लवकर चेतावणी प्रणाली जहाज सोडणाऱ्या लोकांना ओळखते. जर एखादी व्यक्ती क्लीन-शेव्हन असेल तर ती त्याला खलाशी म्हणून ओळखते; जर एखादी व्यक्ती दाढी ठेवलेली आढळली तर त्याला समुद्री डाकू म्हणून ओळखले जाते.

खानावळीत प्रवेश केल्यावर, अतिथी त्याच्या श्रेणीनुसार रोबोट होस्टेसकडून अभिवादन ऐकतो, उदाहरणार्थ: "हो-हो-हो, प्रिय समुद्री डाकू, टेबल नंबरवर जा ..."

अतिथी निर्दिष्ट टेबलवर जातो, जिथे रोबोट बारटेंडरने श्रेणीनुसार त्याच्यासाठी आधीच वस्तू तयार केल्या आहेत. यंत्रमानव बारटेंडर गोदाम प्रणालीला माहिती प्रसारित करतो की वितरणाचा पुढील भाग वाढविला जावा; वेअरहाऊस IS, स्टोरेजमधील शिल्लक शिल्लकवर आधारित, व्यवस्थापन प्रणालीमध्ये खरेदी विनंती व्युत्पन्न करते.

तुमच्‍या अंतर्गत IT द्वारे प्रारंभिक चेतावणी प्रणाली विकसित केली गेली असल्‍यावर, बार रोबोट व्‍यवस्‍थापन कार्यक्रम कदाचित तुमच्‍या व्‍यवसायासाठी बाह्य कॉन्‍ट्रॅक्टरने तयार केला असावा. आणि वेअरहाऊस व्यवस्थापित करण्यासाठी आणि पुरवठादारांशी नातेसंबंध हे बाजारपेठेतील सानुकूलित पॅकेज केलेले समाधान आहेत.

5. डिनोर्मलायझेशनची उदाहरणे आणि सॉफ्टवेअर डेव्हलपमेंटवर त्याचा प्रभाव

व्यवसाय प्रक्रियेची रचना करताना, मुलाखत घेतलेल्या विषय तज्ञांनी एकमताने सांगितले की जगभरातील समुद्री चाचे रम पितात आणि त्यांच्या दाढी हाडांच्या कंगव्याने बांधतात आणि खलाशी थाईमसह चहा पितात आणि नेहमी स्वच्छ मुंडण करतात.

क्लायंट प्रकारांची निर्देशिका दोन मूल्यांसह दिसते: 1 - समुद्री डाकू, 2 - नाविक, कंपनीच्या संपूर्ण माहिती सर्किटसाठी सामान्य.

क्लायंट सूचना प्रणाली प्रतिमा प्रक्रियेचा परिणाम ओळखल्या जाणार्‍या क्लायंटचा अभिज्ञापक (आयडी) आणि त्याचा प्रकार: नाविक किंवा समुद्री डाकू म्हणून त्वरित संग्रहित करते.

ओळखले जाणारे ऑब्जेक्ट आयडी
क्लायंट श्रेणी

100500
चाचा

100501
चाचा

100502
खलाशी

हे आपण पुन्हा एकदा लक्षात घेऊया

1. आमचे खलाशी खरे तर मुंडण केलेले लोक आहेत
2. आमचे समुद्री चाचे प्रत्यक्षात दाढीवाले लोक आहेत

या प्रकरणात कोणत्या समस्या दूर करणे आवश्यक आहे जेणेकरून आमची रचना तिसऱ्या सामान्य स्वरूपासाठी प्रयत्न करेल:

• attribute atomicity violation - क्लायंट श्रेणी
• विश्लेषण केलेले तथ्य आणि निष्कर्ष एका टेबलमध्ये मिसळणे
• भिन्न घटकांच्या गुणधर्मांमधील निश्चित कार्यात्मक संबंध.

सामान्यीकृत स्वरूपात, आम्हाला दोन टेबल्स मिळतील:

• ओळखीचा परिणाम स्थापित वैशिष्ट्यांच्या संचाच्या स्वरूपात,

ओळखले जाणारे ऑब्जेक्ट आयडी
चेहर्यावरील केस

100500
होय

100501
होय

100502
कोणत्याही

• स्थापित वैशिष्ट्यांचा अर्थ लावण्यासाठी IS मध्ये एम्बेड केलेल्या लॉजिकचा अनुप्रयोग म्हणून क्लायंटचा प्रकार निश्चित करण्याचा परिणाम

ओळखले जाणारे ऑब्जेक्ट आयडी
ओळख आयडी
क्लायंट श्रेणी

100500
100001
चाचा

100501
100002
चाचा

100502
100003
खलाशी

सामान्यीकृत डेटा स्टोरेज संस्था आयपी कॉम्प्लेक्सचा विकास कसा सुलभ करू शकते? समजा तुम्हाला अचानक नवीन क्लायंट मिळाले. ते जपानी समुद्री चाचे असू द्या ज्यांना दाढी नसेल, परंतु ते त्यांच्या खांद्यावर पोपट घेऊन चालतात आणि पर्यावरणवादी समुद्री चाचे, तुम्ही त्यांना ग्रेटाच्या डाव्या छातीवर असलेल्या निळ्या प्रोफाइलद्वारे सहजपणे ओळखू शकता.

पर्यावरणीय समुद्री चाचे, नैसर्गिकरित्या, हाडांच्या पोळ्या वापरू शकत नाहीत आणि पुनर्नवीनीकरण केलेल्या समुद्री प्लास्टिकपासून बनवलेल्या अॅनालॉगची मागणी करतात.

तुम्हाला नवीन इनपुट्सनुसार प्रोग्राम अल्गोरिदम पुन्हा कार्य करण्याची आवश्यकता आहे. जर सामान्यीकरण नियमांचे पालन केले गेले असेल, तर तुम्हाला फक्त काही प्रणालींमधील काही प्रक्रिया शाखांसाठी इनपुट पूरक करावे लागतील आणि फक्त त्या केसेससाठी आणि ज्या IS मध्ये चेहऱ्यावरील केस महत्त्वाचे आहेत त्यांच्यासाठी नवीन शाखा तयार कराव्या लागतील. परंतु, नियमांचे पालन न केल्यामुळे, तुम्हाला संपूर्ण सर्किटमध्ये संपूर्ण कोडचे विश्लेषण करावे लागेल, जेथे क्लायंट प्रकार निर्देशिकेची मूल्ये वापरली जातात आणि स्पष्टपणे स्थापित करा की एका बाबतीत अल्गोरिदमने व्यावसायिकांना विचारात घेतले पाहिजे. क्लायंटची क्रियाकलाप आणि इतर भौतिक वैशिष्ट्यांमध्ये.

त्या स्वरूपात शोधतो सामान्यीकृत करण्यासाठी, आम्हाला ऑपरेशनल डेटा आणि दोन डिरेक्टरीसह दोन टेबल्स मिळतील:

• ओळखीचा परिणाम स्थापित वैशिष्ट्यांच्या संचाच्या स्वरूपात,

ओळखले जाणारे ऑब्जेक्ट आयडी
डाव्या छातीवर ग्रेटा
खांद्यावर पक्षी
चेहर्यावरील केस

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/
कॉनोली थॉमस, बेग कॅरोलिन. डेटाबेस. डिझाइन, अंमलबजावणी आणि समर्थन. सिद्धांत आणि सराव

स्त्रोत: www.habr.com