ईआरपी डेटाबेस का विसामान्यीकरण और सॉफ्टवेयर विकास पर इसका प्रभाव: टोर्टुगा में एक मधुशाला खोलना

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

यह कैसे सुनिश्चित करें कि हर कोई खुश है? आप ऐसी प्रणाली को डिजाइन करने और बनाए रखने में पागल होने से कैसे बच सकते हैं? यदि न केवल सामान्य समुद्री डाकू और नाविक ही मधुशाला में आने लगें तो क्या करें?

सब कुछ कटौती के अधीन है. लेकिन चलिए क्रम से चलते हैं।

1. सीमाएँ और धारणाएँ

उपरोक्त सभी बातें केवल रिलेशनल डेटाबेस पर लागू होती हैं। संशोधन, विलोपन और सम्मिलन विसंगतियों के रूप में अपसामान्यीकरण के परिणाम, जो इंटरनेट सहित अच्छी तरह से कवर किए गए हैं, पर विचार नहीं किया जाता है। इस प्रकाशन के दायरे से बाहर ऐसे मामले हैं जहां क्लासिक उदाहरणों के साथ असामान्यीकरण एक सामान्य स्थान है: पासपोर्ट श्रृंखला और संख्या, दिनांक और समय, आदि।

यह पोस्ट गणितीय शब्दों के संदर्भ के बिना, सामान्य रूपों की सहज और व्यावहारिक रूप से लागू परिभाषाओं का उपयोग करती है। जिस रूप में उन्हें वास्तविक व्यावसायिक प्रक्रियाओं (बीपी) की जांच और औद्योगिक सॉफ्टवेयर के डिजाइन में लागू किया जा सकता है।

यह तर्क दिया जाता है कि डेटा वेयरहाउस, रिपोर्टिंग टूल और एकीकरण समझौतों (जो जानकारी के सारणीबद्ध प्रतिनिधित्व का उपयोग करते हैं) का डिज़ाइन ईआरपी सिस्टम डेटाबेस के डिज़ाइन से भिन्न होता है, जिसमें खपत में आसानी होती है और इसे प्राप्त करने के लिए सचेत असामान्यीकरण का उपयोग अखंडता पर पूर्वता ले सकता है। सुरक्षा डेटा. मैं इस राय को साझा करता हूं, और जो नीचे वर्णित है वह पूरी तरह से ईआरपी सिस्टम के मास्टर डेटा और लेनदेन संबंधी डेटा मॉडल पर लागू होता है।

सामान्य रूपों की व्याख्या एक ऐसे उदाहरण का उपयोग करके दी गई है जो अधिकांश पाठकों के लिए रोजमर्रा के स्तर पर समझने योग्य है। हालाँकि, एक दृश्य चित्रण के रूप में, पैराग्राफ 4-5 में, जानबूझकर "काल्पनिक" कार्य का जानबूझकर उपयोग किया गया था। यदि आप ऐसा नहीं करते हैं और कुछ पाठ्यपुस्तक उदाहरण लेते हैं, उदाहरण के लिए, बिंदु 2 से समान ऑर्डर स्टोरेज मॉडल, तो आप खुद को ऐसी स्थिति में पा सकते हैं जहां पाठक का ध्यान प्रक्रिया के प्रस्तावित अपघटन से एक मॉडल में स्थानांतरित हो जाएगा, व्यक्तिगत अनुभव और धारणा के लिए कि आईएस में डेटा संग्रहीत करने के लिए प्रक्रियाओं और मॉडलों का निर्माण कैसे किया जाना चाहिए। दूसरे शब्दों में, दो योग्य आईटी विश्लेषकों को लें, एक यात्रियों को परिवहन करने वाले तर्कशास्त्रियों को सेवाएं प्रदान करें, दूसरा माइक्रोचिप्स के उत्पादन के लिए मशीनों का परिवहन करने वाले तर्कशास्त्रियों को। स्वचालित बीपी पर पहले से चर्चा किए बिना, रेलवे यात्रा के बारे में जानकारी संग्रहीत करने के लिए एक डेटा मॉडल बनाने के लिए उनसे पूछें।

इस बात की गैर-शून्य संभावना है कि प्रस्तावित मॉडल में आपको न केवल विशेषताओं का एक अलग सेट मिलेगा, बल्कि संस्थाओं के अलग-अलग सेट भी मिलेंगे, क्योंकि प्रत्येक विश्लेषक उससे परिचित प्रक्रियाओं और कार्यों पर भरोसा करेगा। और ऐसी स्थिति में यह कहना असंभव है कि कौन सा मॉडल "सही" है, क्योंकि कोई मूल्यांकन मानदंड नहीं है।

2. सामान्य रूप

डेटाबेस का पहला सामान्य रूप सभी गुणों की परमाणुता की आवश्यकता है।
विशेष रूप से, यदि ऑब्जेक्ट ए में गैर-कुंजी विशेषताएँ ए और बी हैं, जैसे कि सी = एफ (ए, बी) और ऑब्जेक्ट ए का वर्णन करने वाली तालिका में आप विशेषता सी का मान संग्रहीत करते हैं, तो डेटाबेस में पहले सामान्य फॉर्म का उल्लंघन होता है . उदाहरण के लिए, यदि ऑर्डर विनिर्देश एक मात्रा को इंगित करता है, जिसकी माप की इकाइयाँ उत्पाद के प्रकार पर निर्भर करती हैं: एक मामले में यह टुकड़े हो सकते हैं, दूसरे में लीटर, तीसरे पैकेज में टुकड़ों से युक्त (Good_count_WR के ऊपर के मॉडल में) , तो डेटाबेस में विशेषताओं की परमाणुता का उल्लंघन होता है। इस मामले में, यह कहने के लिए कि ऑर्डर विनिर्देश का तालिका क्लस्टर क्या होना चाहिए, आपको आईएस में कार्य प्रक्रिया के लक्षित विवरण की आवश्यकता है, और चूंकि प्रक्रियाएं भिन्न हो सकती हैं, इसलिए कई "सही" संस्करण हो सकते हैं।

डेटाबेस का दूसरा सामान्य रूप आईएस में कार्य प्रक्रिया से संबंधित प्रत्येक इकाई के लिए पहले फॉर्म और उसकी अपनी तालिका का अनुपालन आवश्यक है। यदि एक तालिका में निर्भरताएँ c=f1(a) और d=f2(b) हैं और कोई निर्भरता c=f3(b) नहीं है, तो तालिका में दूसरे सामान्य रूप का उल्लंघन किया जाता है। उपरोक्त उदाहरण में, ऑर्डर तालिका में ऑर्डर और पते के बीच कोई निर्भरता नहीं है। सड़क या शहर का नाम बदलें और आदेश की आवश्यक विशेषताओं पर आपका कोई प्रभाव नहीं पड़ेगा।

तीसरा सामान्य प्रपत्र डेटाबेस दूसरे सामान्य रूप के अनुपालन और विभिन्न संस्थाओं की विशेषताओं के बीच कार्यात्मक निर्भरता की अनुपस्थिति की आवश्यकता होती है। इस नियम को इस प्रकार तैयार किया जा सकता है: "जिस चीज़ की गणना की जा सकती है उसकी गणना की जानी चाहिए।" दूसरे शब्दों में, यदि दो ऑब्जेक्ट ए और बी हैं। ऑब्जेक्ट ए की विशेषताओं को संग्रहीत करने वाली तालिका में, विशेषता सी प्रकट होती है, और ऑब्जेक्ट बी में विशेषता बी होती है, जैसे कि सी = एफ 4 (बी) मौजूद है, तो तीसरा सामान्य रूप उल्लंघन किया जाता है. नीचे दिए गए उदाहरण में, ऑर्डर रिकॉर्ड पर टुकड़ों की मात्रा विशेषता (Total_count_WR) स्पष्ट रूप से तीसरे सामान्य फॉर्म का उल्लंघन करने का दावा करती है

3. सामान्यीकरण लागू करने के प्रति मेरा दृष्टिकोण

1. केवल एक लक्ष्य स्वचालित व्यवसाय प्रक्रिया ही डेटा भंडारण मॉडल बनाते समय विश्लेषक को संस्थाओं और विशेषताओं की पहचान करने के लिए मानदंड प्रदान कर सकती है। सामान्य डेटा मॉडल बनाने के लिए एक प्रक्रिया मॉडल बनाना एक शर्त है।

2. यदि निम्नलिखित में से कुछ या सभी शर्तें पूरी होती हैं, तो ईआरपी सिस्टम बनाने के वास्तविक अभ्यास में तीसरे सामान्य फॉर्म को प्राप्त करना व्यावहारिक नहीं हो सकता है:

• स्वचालित प्रक्रियाएँ शायद ही कभी परिवर्तन के अधीन होती हैं,
• अनुसंधान और विकास के लिए समय सीमा सख्त है,
• डेटा अखंडता की आवश्यकताएं अपेक्षाकृत कम हैं (औद्योगिक सॉफ़्टवेयर में संभावित त्रुटियों से सॉफ़्टवेयर ग्राहक को धन या ग्राहकों की हानि नहीं होती है)
• आदि

वर्णित शर्तों के तहत, कुछ वस्तुओं के जीवन चक्र और उनकी विशेषताओं को पहचानने और उनका वर्णन करने की लागत आर्थिक दक्षता के दृष्टिकोण से उचित नहीं हो सकती है।

3. पहले से निर्मित आईएस में डेटा मॉडल के असामान्यकरण के किसी भी परिणाम को कोड और परीक्षण के गहन प्रारंभिक अध्ययन से कम किया जा सकता है।

4. असामान्यीकरण श्रम लागत को डेटा स्रोतों पर शोध करने और व्यवसाय प्रक्रिया को डिजाइन करने के चरण से विकास चरण तक, कार्यान्वयन अवधि से सिस्टम विकास की अवधि तक स्थानांतरित करने का एक तरीका है।

5. डेटाबेस के तीसरे सामान्य रूप के लिए प्रयास करना उचित है यदि:

• स्वचालित व्यावसायिक प्रक्रियाओं में परिवर्तन की दिशा का अनुमान लगाना कठिन है
• कार्यान्वयन और/या विकास टीम के भीतर श्रम का कमजोर विभाजन है
• एकीकरण सर्किट में शामिल सिस्टम अपनी योजनाओं के अनुसार विकसित होते हैं
• डेटा असंगति के परिणामस्वरूप कंपनी को ग्राहकों या धन की हानि हो सकती है

6. डेटा मॉडल का डिज़ाइन केवल लक्ष्य व्यवसाय प्रक्रिया के मॉडल और आईएस में प्रक्रिया के संबंध में एक विश्लेषक द्वारा किया जाना चाहिए। यदि कोई डेवलपर डेटा मॉडल डिज़ाइन कर रहा है, तो उसे विषय क्षेत्र में इस हद तक डूबना होगा कि, विशेष रूप से, वह विशेषता मूल्यों के बीच अंतर को समझ सके - परमाणु विशेषताओं को अलग करने के लिए एक आवश्यक शर्त। इस प्रकार, असामान्य कार्य करना।

चित्रण के लिए 4 समस्या

मान लीजिए कि आपके पास बंदरगाह में एक छोटा रोबोटिक सराय है। आपका बाज़ार खंड: नाविक और समुद्री डाकू जो बंदरगाह में आते हैं और उन्हें विश्राम की आवश्यकता होती है। आप नाविकों को थाइम युक्त चाय बेचते हैं, और समुद्री डाकुओं को दाढ़ी बनाने के लिए रम और हड्डी की कंघी बेचते हैं। मधुशाला में सेवा स्वयं एक रोबोट परिचारिका और एक रोबोट बारटेंडर द्वारा प्रदान की जाती है। आपकी उच्च गुणवत्ता और कम कीमतों के कारण, आपने अपने प्रतिस्पर्धियों को बाहर कर दिया है, ताकि जहाज से उतरने वाला हर कोई आपके सराय में आ सके, जो बंदरगाह में एकमात्र है।

मधुशाला सूचना प्रणाली परिसर में निम्नलिखित सॉफ्टवेयर शामिल हैं:

• किसी ग्राहक के बारे में एक प्रारंभिक चेतावनी प्रणाली जो विशिष्ट विशेषताओं के आधार पर उसकी श्रेणी को पहचानती है
• रोबोट परिचारिकाओं और रोबोट बारटेंडरों के लिए नियंत्रण प्रणाली
• बिक्री स्थल तक गोदाम और वितरण प्रबंधन प्रणाली
• आपूर्तिकर्ता संबंध प्रबंधन प्रणाली (एसयूआरपी)

प्रक्रिया:

प्रारंभिक चेतावनी प्रणाली जहाज छोड़ने वाले लोगों को पहचान लेती है। यदि कोई व्यक्ति सफाचट है, तो वह उसकी पहचान एक नाविक के रूप में करती है; यदि कोई व्यक्ति दाढ़ी रखता हुआ पाया जाता है, तो उसकी पहचान समुद्री डाकू के रूप में की जाती है।

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

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

जबकि प्रारंभिक चेतावनी प्रणाली आपके आंतरिक आईटी द्वारा विकसित की गई हो सकती है, बार रोबोट प्रबंधन कार्यक्रम विशेष रूप से आपके व्यवसाय के लिए किसी बाहरी ठेकेदार द्वारा बनाया गया हो सकता है। और गोदामों के प्रबंधन और आपूर्तिकर्ताओं के साथ संबंधों के लिए सिस्टम बाजार से अनुकूलित पैकेज्ड समाधान हैं।

5. असामान्यीकरण के उदाहरण और सॉफ्टवेयर विकास पर इसका प्रभाव

व्यवसाय प्रक्रिया को डिज़ाइन करते समय, साक्षात्कार किए गए विषय विशेषज्ञों ने सर्वसम्मति से कहा कि दुनिया भर में समुद्री डाकू रम पीते हैं और अपनी दाढ़ी को हड्डी की कंघी से कंघी करते हैं, और नाविक थाइम के साथ चाय पीते हैं और हमेशा क्लीन शेव रहते हैं।

ग्राहक प्रकारों की एक निर्देशिका दो मानों के साथ दिखाई देती है: 1 - समुद्री डाकू, 2 - नाविक, कंपनी के संपूर्ण सूचना सर्किट के लिए सामान्य।

क्लाइंट अधिसूचना प्रणाली तुरंत छवि प्रसंस्करण के परिणाम को मान्यता प्राप्त ग्राहक और उसके प्रकार के पहचानकर्ता (आईडी) के रूप में संग्रहीत करती है: नाविक या समुद्री डाकू।

मान्यता प्राप्त वस्तु आईडी
ग्राहक श्रेणी

100500
समुद्री डाकू

100501
समुद्री डाकू

100502
नाविक

आइये एक बार फिर से इस बात पर ध्यान दें

1. हमारे नाविक वास्तव में मुंडा लोग हैं
2. हमारे समुद्री डाकू वास्तव में दाढ़ी वाले लोग हैं

इस मामले में किन समस्याओं को दूर करने की आवश्यकता है ताकि हमारी संरचना तीसरे सामान्य रूप के लिए प्रयास करे:

• विशेषता परमाणुता उल्लंघन - ग्राहक श्रेणी
• विश्लेषित तथ्य और निष्कर्ष को एक तालिका में मिलाना
• विभिन्न संस्थाओं की विशेषताओं के बीच निश्चित कार्यात्मक संबंध।

सामान्यीकृत रूप में, हमें दो तालिकाएँ मिलेंगी:

• स्थापित सुविधाओं के एक सेट के रूप में मान्यता परिणाम,

मान्यता प्राप्त वस्तु आईडी
चेहरे के बाल

100500
Да

100501
Да

100502
नहीं

• स्थापित विशेषताओं की व्याख्या करने के लिए आईएस में अंतर्निहित तर्क के अनुप्रयोग के रूप में ग्राहक के प्रकार को निर्धारित करने का परिणाम

मान्यता प्राप्त वस्तु आईडी
पहचान आईडी
ग्राहक श्रेणी

100500
100001
समुद्री डाकू

100501
100002
समुद्री डाकू

100502
100003
नाविक

एक सामान्यीकृत डेटा भंडारण संगठन आईपी कॉम्प्लेक्स के विकास को कैसे सुविधाजनक बना सकता है? मान लीजिए कि आपको अचानक नए ग्राहक मिल गए। जापानी समुद्री डाकू हों, जिनकी भले ही दाढ़ी न हो, लेकिन वे अपने कंधे पर तोता लेकर चलते हैं, और पर्यावरणवादी समुद्री डाकू हों, आप उन्हें बायीं छाती पर ग्रेटा की नीली प्रोफ़ाइल से आसानी से पहचान सकते हैं।

पर्यावरणीय समुद्री डाकू, स्वाभाविक रूप से, हड्डी के कंघों का उपयोग नहीं कर सकते हैं और पुनर्नवीनीकृत समुद्री प्लास्टिक से बने एनालॉग की मांग करते हैं।

आपको नए इनपुट के अनुसार प्रोग्राम एल्गोरिदम को फिर से काम करने की आवश्यकता है। यदि सामान्यीकरण नियमों का पालन किया गया था, तो आपको केवल कुछ प्रणालियों में कुछ प्रक्रिया शाखाओं के लिए इनपुट को पूरक करना होगा और केवल उन मामलों के लिए और उन आईएस में नई शाखाएं बनानी होंगी जहां चेहरे के बाल मायने रखते हैं। लेकिन, चूंकि नियमों का पालन नहीं किया गया, इसलिए आपको पूरे सर्किट में, जहां क्लाइंट प्रकार निर्देशिका के मूल्यों का उपयोग किया जाता है, पूरे कोड का विश्लेषण करना होगा और स्पष्ट रूप से स्थापित करना होगा कि एक मामले में एल्गोरिदम को पेशेवर को ध्यान में रखना चाहिए ग्राहक की गतिविधि, और अन्य भौतिक विशेषताओं में।

उस रूप में करना है सामान्यीकृत करने के लिए, हमें परिचालन डेटा और दो निर्देशिकाओं के साथ दो तालिकाएँ मिलेंगी:

• स्थापित सुविधाओं के एक सेट के रूप में मान्यता परिणाम,

मान्यता प्राप्त वस्तु आईडी
बायीं छाती पर ग्रेटा
कंधे पर पक्षी
चेहरे के बाल

100510
1
1
1

100511
0
0
1

100512

1
0

• क्लाइंट प्रकार निर्धारित करने का परिणाम (इसे एक कस्टम दृश्य होने दें जिसमें निर्देशिकाओं के विवरण प्रदर्शित होते हैं)

क्या ज्ञात असामान्यीकरण का मतलब यह है कि सिस्टम को नई स्थितियों को पूरा करने के लिए संशोधित नहीं किया जा सकता है? बिल्कुल नहीं। यदि हम कल्पना करें कि सभी सूचना प्रणालियाँ शून्य स्टाफ टर्नओवर के साथ एक टीम द्वारा बनाई गई थीं, विकास को अच्छी तरह से प्रलेखित किया गया है और जानकारी बिना नुकसान के टीम के भीतर स्थानांतरित की गई है, तो आवश्यक परिवर्तन नगण्य रूप से कम प्रयास के साथ किए जा सकते हैं। लेकिन अगर हम समस्या की मूल स्थितियों पर लौटते हैं, तो 1,5 कीबोर्ड केवल संयुक्त चर्चा के मुद्रण प्रोटोकॉल के लिए मिटा दिए जाएंगे और अन्य 0,5 खरीद प्रक्रियाओं को संसाधित करने के लिए मिटा दिए जाएंगे।

उपरोक्त उदाहरण में, सभी तीन सामान्य रूपों का उल्लंघन किया गया है, आइए उन्हें अलग से उल्लंघन करने का प्रयास करें।

पहले सामान्य रूप का उल्लंघन:

मान लीजिए कि आपूर्तिकर्ताओं के गोदामों से सामान आपके गोदाम तक 1.5-टन के एक गजल का उपयोग करके पिक-अप द्वारा पहुंचाया जाता है जो आपके सराय से संबंधित है। आपके ऑर्डर का आकार आपूर्तिकर्ताओं के टर्नओवर के सापेक्ष इतना छोटा है कि वे हमेशा उत्पादन की प्रतीक्षा किए बिना एक-एक करके पूरे किए जाते हैं। ऐसी व्यवसाय प्रक्रिया के साथ, क्या आपको अलग-अलग तालिकाओं की आवश्यकता है: वाहन, वाहनों के प्रकार, क्या दिवंगत आपूर्तिकर्ताओं को आपके आदेशों में योजना और तथ्य को अलग करना आवश्यक है?

ज़रा कल्पना करें कि यदि आप किसी प्रोग्राम को विकसित करने के लिए नीचे दिए गए मॉडल का उपयोग करते हैं तो आपके प्रोग्रामर को कितने "अतिरिक्त" कनेक्शन लिखने होंगे।

मान लें कि हमने तय किया है कि प्रस्तावित संरचना अनावश्यक रूप से जटिल है; हमारे मामले में, ऑर्डर रिकॉर्ड में योजना और तथ्य को अलग करना अनावश्यक जानकारी है, और उत्पन्न ऑर्डर विनिर्देश को आने वाले माल की स्वीकृति के परिणामों के आधार पर फिर से लिखा जाता है, दुर्लभ गलती -अपर्याप्त गुणवत्ता वाले सामान की ग्रेडिंग और आगमन का निपटान आईएस के बाहर किया जाता है।
और फिर एक दिन आप देखते हैं कि कैसे पूरा मधुशाला हॉल क्रोधित और अव्यवस्थित समुद्री डाकुओं से भर जाता है। क्या हुआ?

इससे पता चलता है कि जैसे-जैसे आपका व्यवसाय बढ़ा, वैसे-वैसे आपकी खपत भी बढ़ी। एक समय की बात है, एक प्रबंधन निर्णय लिया गया था कि यदि किसी गजल पर मात्रा और/या वजन में अधिक भार डाला गया था, जो बेहद दुर्लभ था, तो आपूर्तिकर्ता पेय के पक्ष में भार को प्राथमिकता देगा।

डिलीवर न किया गया माल अगले ऑर्डर में समाप्त हो गया और एक नई उड़ान पर चला गया; मधुशाला के गोदाम में न्यूनतम शेष राशि की उपस्थिति ने लापता मामलों पर ध्यान न देना संभव बना दिया।

अंतिम प्रतियोगी बंदरगाह पर बंद हो गया, और वाहन के न्यूनतम संतुलन और आवधिक अंडरलोडिंग की पर्याप्तता की धारणा के आधार पर प्राथमिकता द्वारा दरकिनार किए गए गज़ेल ओवरलोड का पंचर मामला आम बात बन गया। बनाई गई प्रणाली आदर्श रूप से इसमें अंतर्निहित एल्गोरिदम के अनुसार काम करेगी और नियोजित आदेशों को पूरा करने में व्यवस्थित विफलता को ट्रैक करने के किसी भी अवसर से वंचित हो जाएगी। केवल क्षतिग्रस्त प्रतिष्ठा और असंतुष्ट ग्राहक ही समस्या का पता लगा पाएंगे।

एक चौकस पाठक ने देखा होगा कि धारा 2 और धारा 5 में ऑर्डर विनिर्देश (T_ORDER_SPEC) में ऑर्डर की गई मात्रा पहले सामान्य फॉर्म की आवश्यकता को पूरा कर भी सकती है और नहीं भी। यह सब इस बात पर निर्भर करता है कि, वस्तुओं के चयनित वर्गीकरण को देखते हुए, माप की अनिवार्य रूप से विभिन्न इकाइयाँ एक ही क्षेत्र में आ सकती हैं।

दूसरे सामान्य फॉर्म का उल्लंघन:

जैसे-जैसे आपकी ज़रूरतें बढ़ती हैं, आप विभिन्न आकारों के कुछ और वाहन खरीदते हैं। उपरोक्त संदर्भ में, एक वाहन निर्देशिका का निर्माण निरर्थक माना गया था; परिणामस्वरूप, डिलीवरी और गोदाम की जरूरतों को पूरा करने वाले सभी डेटा प्रोसेसिंग एल्गोरिदम आपूर्तिकर्ता से गोदाम तक कार्गो की आवाजाही को विशेष रूप से 1,5-टन की उड़ान के रूप में देखते हैं चिकारा. इसलिए, नए वाहनों की खरीद के साथ, आप अभी भी एक वाहन निर्देशिका बनाते हैं, लेकिन इसे अंतिम रूप देते समय, आपको कार्गो की आवाजाही का संदर्भ देने वाले सभी कोड का विश्लेषण करना होगा ताकि यह पता लगाया जा सके कि प्रत्येक विशिष्ट स्थान में विशेषताओं के संदर्भ निहित हैं या नहीं उसी वाहन का जिससे व्यापार शुरू हुआ।

तीसरे सामान्य रूप का उल्लंघन:

किसी बिंदु पर आप एक वफादारी कार्यक्रम बनाना शुरू करते हैं, एक नियमित ग्राहक का रिकॉर्ड दिखाई देता है। उदाहरण के लिए, ऐसे भौतिक दृश्य बनाने में समय क्यों व्यतीत करें जो रिपोर्टिंग में उपयोग के लिए एक व्यक्तिगत ग्राहक को बिक्री पर एकत्रित डेटा संग्रहीत करते हैं और विश्लेषणात्मक प्रणालियों में स्थानांतरित करते हैं, यदि वफादारी कार्यक्रम की शुरुआत में ग्राहक की रुचि वाली हर चीज को ग्राहक के रिकॉर्ड पर रखा जा सकता है ? और, वास्तव में, पहली नज़र में, इसका कोई मतलब नहीं है। लेकिन जब भी आपका व्यवसाय जुड़ता है, उदाहरण के लिए, नए बिक्री चैनल, तो आपके विश्लेषकों में से कोई ऐसा होना चाहिए जो याद रखेगा कि ऐसी एकत्रीकरण विशेषता मौजूद है।

प्रत्येक नई प्रक्रिया को डिज़ाइन करते समय, उदाहरण के लिए, इंटरनेट पर बिक्री, एक सामान्य वफादारी प्रणाली से जुड़े वितरकों के माध्यम से बिक्री, किसी को यह ध्यान रखना चाहिए कि सभी नई प्रक्रियाओं को कोड स्तर पर डेटा अखंडता सुनिश्चित करनी चाहिए। एक हजार तालिकाओं वाले औद्योगिक डेटाबेस के लिए, यह एक असंभव कार्य जैसा लगता है।

बेशक, एक अनुभवी डेवलपर जानता है कि ऊपर उल्लिखित सभी समस्याओं को कैसे रोका जाए, लेकिन, मेरी राय में, एक अनुभवी विश्लेषक का काम उन्हें प्रकाश में लाना नहीं है।

मैं प्रकाशन की तैयारी के दौरान उनकी बहुमूल्य प्रतिक्रिया के लिए प्रमुख डेवलपर एवगेनी यारुखिन के प्रति अपना आभार व्यक्त करना चाहता हूं।

साहित्य

https://habr.com/en/post/254773/
कोनोली थॉमस, बेग कैरोलिन। डेटाबेस। डिजाइन, कार्यान्वयन और समर्थन। सिद्धांत और अभ्यास

स्रोत: www.habr.com