चेकपॉइंट 1, Steve Trucking का डेटा डिज़ाइन बनाएँ और उसका बचाव करें

🌐 28 अन्य भाषाओं में भी उपलब्ध

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मौलिक, परिदृश्य पर आधारित अभ्यास। यह कभी असली परीक्षा के सवालों पर आधारित नहीं है। यह “मैं इसे कैसे आर्किटेक्ट करता” शैली में लिखा गया है: मकसद अपनी समझ को सामने रखना है, कोई अक्षर चुनना नहीं। यह चुनौती Data Architect कोर्स के भाग 1 को पूरा करती है; मेरा हल चेकपॉइंट 1 में आता है, इसलिए पहले इसे ख़ुद आज़माएँ।

परिदृश्य

Steve Trucking एक लास्ट-माइल डिलीवरी कंपनी है। बड़े रिटेल पार्टनर (Retail Partners) अप्लायंस, टीवी और फ़र्नीचर बेचते हैं; Steve Trucking के दो-व्यक्ति वाले क्रू उन्हें रिटेल पार्टनर्स के ग्राहकों (प्राप्तकर्ता, Recipients) तक पहुँचाते हैं, उनमें से कुछ इंस्टॉल करते हैं और पुराने सामान उठा ले जाते हैं। Steve Trucking brief के खंड 1–8 पढ़ें। खंड 9 (देर से आए बदलाव) को अभी छोड़ दें; वे कोर्स के अंत में आते हैं।

ज़रूरतें

brief के खंड 5 (R1–R15) और खंड 6 (S1–S5) की हर चीज़। इस चेकपॉइंट में जिन पर सबसे ज़्यादा ज़ोर है:

• R1. हर रिटेल पार्टनर के मैनिफ़ेस्ट उसके अपने फ़ॉर्मेट में लें (SFTP फ़ाइल, API, EDI) और बिना दोबारा टाइप किए उन्हें रूट, स्टॉप और लाइन आइटम में बदलें।
• R3. हर रिटेल पार्टनर के DC मैनेजर पोर्टल में अपनी डिलीवरी, अपवाद, फ़ोटो और क्लेम देखते हैं, और कभी किसी दूसरे पार्टनर के नहीं।
• R4. मैनिफ़ेस्ट उसी दिन बदले जाते हैं; रूटिंग के बाद के बदलाव संभालने होंगे।
• S2. किसी रिटेल पार्टनर को कभी भी दूसरे पार्टनर की डिलीवरी, कीमतें, वॉल्यूम या प्राप्तकर्ता नहीं दिखने चाहिए।
• S3. प्राप्तकर्ता का ट्रैकिंग लिंक सिर्फ़ वही एक डिलीवरी दिखाता है, बिना किसी अकाउंट के, और उसकी मियाद खत्म हो जाती है।
• S4. प्राप्तकर्ताओं के पते, फ़ोन नंबर और डिलीवरी नोट्स निजी डेटा हैं; क्रू उन्हें सिर्फ़ अपने स्टॉप के लिए, सिर्फ़ उसी दिन देखते हैं।

पाबंदियाँ

• हर कामकाजी दिन लगभग 3,300 डिलीवरी, साल में एक मिलियन, हर साल 30% की बढ़त; हर डिलीवरी पर लगभग 1.6 लाइन आइटम और आठ स्टेटस बदलाव; साल में चार से पाँच मिलियन फ़ोटो; दिन में लगभग 200,000 GPS रीडिंग।
• US में एक Salesforce org, जिसमें पहले से Service Cloud, Field Service और एक पार्टनर पोर्टल चल रहा है; MuleSoft का लाइसेंस है; Data 360 का लाइसेंस है लेकिन इम्प्लीमेंट नहीं हुआ।
• तीन रिटेल पार्टनर, इंटीग्रेशन की तीन शैलियाँ; नौ डिस्ट्रिब्यूशन सेंटर।

आपका काम

भाग 1 का डिज़ाइन बनाएँ और उसका बचाव करें। अध्याय 1–6 में जो सीखा है, उसका इस्तेमाल करें:

1. लैंडस्केप (अध्याय 4): Steve के लेआउट में Steve Trucking का मौजूदा सिस्टम लैंडस्केप बनाएँ, हर तीर पर लिखा हो कि क्या चलता है और कैसे।
2. मॉडल (अध्याय 2): डिलीवरी डोमेन को पहले कॉन्सेप्चुअल रूप से, फिर लॉजिकल रूप से मॉडल करें। रिटेल पार्टनर, डिस्ट्रिब्यूशन सेंटर, मैनिफ़ेस्ट, डिलीवरी, लाइन आइटम, रूट, ट्रक, क्रू, इंस्टॉल चेकलिस्ट, फ़ोटो, हस्ताक्षर, अपवाद और प्राप्तकर्ता। (चुनौती D1।)
3. फ़िज़िकल डिज़ाइन (अध्याय 3): इनमें से कौन-से स्टैंडर्ड ऑब्जेक्ट हैं (Field Service में work orders, service appointments, service resources और service territories हैं) और कौन-से कस्टम? पार्टनर यूज़र्स और प्राप्तकर्ताओं को कौन-से लाइसेंस चाहिए? हर तरह का डेटा कहाँ रहता है: org में, core से बाहर, warehouse में?
4. Key (यह अध्याय): कौन-सी key किसी रिटेल पार्टनर की ऑर्डर लाइन को आपकी डिलीवरी से मिलाती है, और जब रूटिंग के बाद मैनिफ़ेस्ट बदलता है तो क्या होता है? (चुनौती D3।)
5. प्राप्तकर्ता (यह अध्याय): एक Contact, एक person account, या दोनों में से कोई नहीं? इसका तर्क संबंध, वॉल्यूम, पार्टनर्स के अलगाव और डेटा के जीवनचक्र से दें।
6. एकीकृत करें या नहीं (यह अध्याय): प्राप्तकर्ता कई पार्टनर्स के मैनिफ़ेस्ट में आते हैं, कभी-कभी साल में एक से ज़्यादा बार। क्या आप उन्हें एकीकृत (unify) करेंगे, या जान-बूझकर नहीं? S2 को देखते हुए जोखिम क्या है? (चुनौती DC1, देर से आए बदलावों के बिना।)
7. अधिकार: पाँच अहम फ़ील्ड (पार्टनर का ऑर्डर रेफ़रेंस, डिलीवरी स्टेटस, प्राप्तकर्ता का फ़ोन नंबर, डिलीवरी विंडो, पार्टनर का कानूनी नाम) के लिए बताएँ कि उसे कौन बनाता है, उसका मालिक कौन है, कौन-सा सिस्टम आधिकारिक है और उसे कौन बदल सकता है।

हर फ़ैसले को दोनों विकल्पों के साथ लिखें, फिर अपनी पसंद: “मेरी पेशेवर राय में…”

चर्चा

मेरा हल है चेकपॉइंट 1: Steve Trucking, मैं इसे कैसे आर्किटेक्ट करता। अपनी सोच की तुलना करें, सिर्फ़ अपने बॉक्स की नहीं। जहाँ आपने अलग चुना, क्या आप बता सकते हैं कि आपको क्या मिलेगा और आप क्या छोड़ेंगे?

डिज़ाइन समीक्षा

अपना डिज़ाइन अभी सँभालकर रखें। भाग 2 उसे वॉल्यूम, क्वेरी, इंटीग्रेशन, माइग्रेशन, ट्रांज़ैक्शन और सिक्योरिटी के सामने परखता है, और अध्याय 18 का समीक्षा कार्ड तीसरे साल में उसकी जाँच करता है।

परीक्षा के जिन उद्देश्यों का अभ्यास हुआ

• DM-1, DM-2 (डेटा मॉडल डिज़ाइन; मॉडल शेयरिंग का सम्मान करता है)
• MDM-1, MDM-2, MDM-3, MDM-4 (मास्टरिंग, अधिकार, मैचिंग, ट्रेस करने की क्षमता)
• SDM-1 (लाइसेंस), SDM-3 (एक ही नज़र, और कब उसे नहीं बनाना चाहिए)