👂🏾 🚹 👨🏻‍🌾 ईआरपी डेटाबेस सिस्टम का विघटन और सॉफ्टवेयर विकास पर इसका प्रभाव: टोर्टुगा पर एक सराय खोलें 🧕🏻 ✂️ 🥨

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

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

1. सीमाएँ और मान्यताएँ

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

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

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

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

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

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

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

डेटाबेस का दूसरा सामान्य रूपआईपी में काम करने की प्रक्रिया से संबंधित प्रत्येक इकाई के लिए पहले फॉर्म और इसकी अपनी तालिका के अनुपालन की आवश्यकता है। यदि एक तालिका में निर्भरताएं 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. पहले से निर्मित आईपी में डेटा मॉडल के निरूपण के किसी भी परिणाम को कोड और परीक्षण के गहन प्रारंभिक अध्ययन से रोका जा सकता है।

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

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

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

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

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

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

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

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

प्रक्रिया:

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

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

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

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

5. सॉफ्टवेयर विकास पर विकृति और उसके प्रभाव के उदाहरण

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

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

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

मान्यता प्राप्त वस्तु आईडी	ग्राहक श्रेणी
100500	समुद्री डाकू
100,501	समुद्री डाकू
100,502	नाविक

एक बार फिर, हम ध्यान दें कि

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

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

एटॉमिक उल्‍लंघन की विशेषता - क्‍लाइंट श्रेणी
एक तालिका में विश्लेषित तथ्य और निष्कर्ष का मिश्रण
विभिन्न संस्थाओं की विशेषताओं के बीच निश्चित कार्यात्मक संबंध।

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

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

मान्यता प्राप्त वस्तु आईडी	चेहरे के बाल
100500	हाँ
100,501	हाँ
100,502	नहीं

स्थापित संकेतों की व्याख्या के लिए आईएस में एम्बेडेड तर्क के एक आवेदन के रूप में ग्राहक के प्रकार का निर्धारण करने का परिणाम है

मान्यता प्राप्त वस्तु आईडी	पहचान आईडी	ग्राहक श्रेणी
100500	100001	समुद्री डाकू
100,501	100,002	समुद्री डाकू
100,502	100,003	नाविक

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

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

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

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

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


100510	1	1	1
100511	0	0	1
100512		1	0

( , )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

साहित्य

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