ईआरपी डाटाबेसको सामान्यीकरण र सफ्टवेयर विकासमा यसको प्रभाव: टोर्टुगामा एक टेभर्न खोल्दै

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

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

सबै कुरा काटिएको छ। तर क्रम मा जाऔं।

1. सीमितता र मान्यताहरू

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

पोस्टले गणितीय सर्तहरूको सन्दर्भ बिना सामान्य रूपहरूको सहज र व्यावहारिक रूपमा लागू हुने परिभाषाहरू प्रयोग गर्दछ। जसमा तिनीहरू वास्तविक व्यापार प्रक्रिया (BP) र औद्योगिक सफ्टवेयरको डिजाइनको परीक्षामा लागू गर्न सकिन्छ।

यो तर्क गरिएको छ कि डाटा गोदामहरूको डिजाइन, रिपोर्टिङ उपकरणहरू र एकीकरण सम्झौताहरू (जसले जानकारीको तालिका प्रतिनिधित्वहरू प्रयोग गर्दछ) ERP प्रणाली डाटाबेसहरूको डिजाइनबाट उपभोगको सहजतामा फरक छ र यसलाई प्राप्त गर्न सचेत विकृतिकरणको प्रयोगले अखण्डतालाई प्राथमिकता दिन सक्छ। सुरक्षा डाटा। म यो राय साझा गर्छु, र तल वर्णन गरिएको कुरा मास्टर डाटा र ERP प्रणालीहरूको लेनदेन डेटा मोडेलहरूमा मात्र लागू हुन्छ।

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

त्यहाँ एक गैर-शून्य सम्भावना छ कि प्रस्तावित मोडेलहरूमा तपाईंले विशेषताहरूको एक उल्लेखनीय भिन्न सेट मात्र फेला पार्नुहुनेछ, तर संस्थाहरूको भिन्न सेटहरू पनि पाउनुहुनेछ, किनभने प्रत्येक विश्लेषकले उहाँलाई परिचित प्रक्रियाहरू र कार्यहरूमा भर पर्नेछ। र यस्तो अवस्थामा कुन मोडेल "सही" हो भन्न असम्भव छ, किनभने त्यहाँ कुनै मूल्याङ्कन मापदण्ड छैन।

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 दृष्टान्तको लागि समस्या

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

Tavern सूचना प्रणाली जटिल निम्न सफ्टवेयर समावेश गर्दछ:

• एक ग्राहकको बारेमा प्रारम्भिक चेतावनी प्रणाली जसले विशेषता सुविधाहरूको आधारमा यसको कोटी पहिचान गर्दछ
• रोबोट होस्टेस र रोबोट बारटेन्डरहरूको लागि नियन्त्रण प्रणाली
• गोदाम र वितरण व्यवस्थापन प्रणाली बिक्रीको बिन्दुमा
• आपूर्तिकर्ता सम्बन्ध व्यवस्थापन प्रणाली (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) मा अर्डर गरिएको मात्रा पहिलो सामान्य फारमको आवश्यकता पूरा गर्न सक्छ वा नहुन सक्छ। यो सबै निर्भर गर्दछ कि, वस्तुहरूको चयन गरिएको वर्गीकरण दिएर, अनिवार्य रूपमा मापनका विभिन्न एकाइहरू एउटै क्षेत्रमा पर्न सक्छन्।

दोस्रो सामान्य रूप को उल्लङ्घन:

तपाईंको आवश्यकताहरू बढ्दै जाँदा, तपाईंले विभिन्न साइजका केही थप गाडीहरू खरिद गर्नुहुन्छ। माथिको सन्दर्भमा, गाडीको डाइरेक्टरीको सिर्जनालाई अनावश्यक मानिएको थियो; फलस्वरूप, डेलिभरी र गोदामको आवश्यकताहरू पूरा गर्ने सबै डाटा प्रोसेसिङ एल्गोरिदमहरूले आपूर्तिकर्ताबाट गोदाममा कार्गोको आवागमनलाई विशेष रूपमा १.५-टनको उडानको रूपमा बुझ्छन्। हरिण। त्यसोभए, नयाँ सवारी साधनहरूको खरिदसँगै, तपाईंले अझै पनि सवारी साधनको डाइरेक्टरी सिर्जना गर्नुहुन्छ, तर यसलाई अन्तिम रूप दिंदा, तपाईंले प्रत्येक विशिष्ट स्थानमा सन्दर्भहरू विशेषताहरूमा निहित छन् कि छैनन् भनेर पत्ता लगाउन कार्गोको आवागमनलाई सन्दर्भ गर्ने सबै कोडहरू विश्लेषण गर्नुपर्नेछ। जुन गाडीबाट व्यवसाय सुरु भयो।

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

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

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

एक अनुभवी विकासकर्ता, निस्सन्देह, माथि उल्लेखित सबै समस्याहरू कसरी रोक्ने भनेर जान्दछन्, तर, मेरो विचारमा, अनुभवी विश्लेषकको कार्य तिनीहरूलाई प्रकाशमा ल्याउनु होइन।

म प्रमुख विकासकर्ता Evgeniy Yarukhin लाई प्रकाशनको तयारीको क्रममा उनको बहुमूल्य प्रतिक्रियाको लागि मेरो कृतज्ञता व्यक्त गर्न चाहन्छु।

साहित्य

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

स्रोत: www.habr.com