7.7 डेटा मॉडलिंग और सिमेंटिक लेयर

अवलोकन और प्रेरणा

एक डेटा मॉडल एक निर्णय है कि आपका डेटा क्या अर्थ रखता है, यह तय करने से पहले कि डेटा कहाँ रहता है। यह उन चीज़ों को नाम देता है जिनकी आपके व्यवसाय को परवाह है, उन विशेषताओं को जो उन्हें वर्णित करती हैं, और उनके बीच के संबंधों को। स्टोरेज, इंडेक्स, फ़ाइल फ़ॉर्मेट, और क्वेरी इंजन सब बाद में आते हैं। यह क्रम मायने रखता है क्योंकि आपके डेटा का अर्थ हर उस तकनीक से अधिक जीवित रहता है जिसका आप इसे रखने के लिए उपयोग करते हैं। वेयरहाउस बदल दिए जाते हैं, टेबल फ़ॉर्मेट बदलते हैं, और क्वेरी इंजन आते-जाते रहते हैं, लेकिन “customer,” “order,” और “active user” को इन सब में वर्षों तक एक ही चीज़ का मतलब होना चाहिए।

एक छोटी टीम के लिए, मॉडलिंग अक्सर अंतर्निहित होती है। एक इंजीनियर पूरी स्कीमा अपने दिमाग में रखता है, और “revenue” की एक साझा समझ जीवित रहती है क्योंकि असहमत होने के लिए केवल तीन लोग हैं। बड़े डेवलपर संगठनों, उद्यमों, और सरकारी एजेंसियों के पैमाने पर, वह अनौपचारिकता ठीक उसी तरह ढह जाती है जैसा अध्याय 7.1 (डेटा रणनीति और गवर्नेंस) में वर्णित है। दर्जनों टीमें सैकड़ों टेबल बनाती हैं, प्रत्येक का अपना विचार होता है कि एक “session” क्या है या एक उपयोगकर्ता कब “active” गिना जाता है। दो डैशबोर्ड एक ही सप्ताह के लिए दो अलग-अलग संख्याएँ दिखाते हैं, और एक नेतृत्व बैठक इस बहस में बदल जाती है कि किसकी क्वेरी सही है बजाय इसके कि आगे क्या करना है। खराब मॉडलिंग खुद की घोषणा नहीं करती। यह महीनों बाद सुलह कार्य, विफल ऑडिट, और ऐसे आँकड़ों पर लिए गए निर्णयों के रूप में सामने आती है जिनका कोई बचाव नहीं कर सकता।

यह अध्याय उस काम को जानबूझकर करने के बारे में है। यह कॉन्सेप्चुअल, लॉजिकल, और फिज़िकल मॉडल को कवर करता है; एंटिटी-रिलेशनशिप मॉडलिंग को; कब नॉर्मलाइज़ करें और कब डीनॉर्मलाइज़ करें; ट्रांज़ैक्शनल बनाम एनालिटिकल वर्कलोड के लिए मॉडलिंग कैसे भिन्न है; फ़ैक्ट और डाइमेंशन के साथ डायमेंशनल मॉडलिंग; और वह सिमेंटिक लेयर जो हर व्यावसायिक मीट्रिक की एक गवर्न्ड परिभाषा रखती है। फ़ायदा अपने आप में सुंदरता नहीं है। यह है कि “active user” और “revenue” हर जगह एक ही चीज़ का मतलब रखें, ताकि आपकी टीमें संख्याओं पर भरोसा कर सकें और इसकी वजह से तेज़ी से आगे बढ़ सकें।

यह भी देखें: अध्याय 3.4 (डेटा आर्किटेक्चर और स्टोरेज), अध्याय 7.3 (एनालिटिक्स और बिज़नेस इंटेलिजेंस), और अध्याय 11.5 (की परफ़ॉर्मेंस इंडिकेटर)।

मुख्य सिद्धांत

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

सिफारिशें

तीन स्तरों पर, क्रम में मॉडल करें

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

ट्रांज़ैक्शनल सिस्टम को नॉर्मलाइज़ करें, एनालिटिकल को जानबूझकर डीनॉर्मलाइज़ करें

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

एनालिटिक्स के लिए डायमेंशनल मॉडलिंग का उपयोग करें

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

ग्रेन तय करें और बदलते डाइमेंशन को स्पष्ट रूप से संभालें

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

हर मीट्रिक की एकल परिभाषा के रूप में एक सिमेंटिक लेयर बनाएँ

यह वह सिफारिश है जो पूरे अध्याय की कीमत चुकाती है। एक सिमेंटिक लेयर आपकी फिज़िकल टेबल और उनका उपभोग करने वाले हर टूल के बीच बैठती है, और यह हर व्यावसायिक मीट्रिक की एक गवर्न्ड परिभाषा रखती है। “Active user” को एक बार परिभाषित किया जाता है, कोड के रूप में, उसके सटीक तर्क के साथ: कौन से इवेंट गिनते हैं, किस विंडो पर, किन आंतरिक खातों को छोड़कर। “Revenue” को एक बार परिभाषित किया जाता है, इसमें शामिल है कि रिफंड, छूट, और मुद्रा रूपांतरण को कैसे संभाला जाता है। हर डैशबोर्ड, नोटबुक, रिपोर्ट, और रिवर्स-ETL जॉब उस परिभाषा को पढ़ता है बजाय इसके कि इसे किसी बेस्पोक क्वेरी में फिर से लागू करे। जब परिभाषा बदलती है, तो यह एक स्थान पर बदलती है और हर उपभोक्ता एक साथ अपडेट होता है। यह वह तंत्र है जो गवर्न्ड मीट्रिक परिभाषाओं को आकांक्षी के बजाय वास्तविक बनाता है, और यह ठीक वही है जिसे अध्याय 11.5 (की परफ़ॉर्मेंस इंडिकेटर) माँगता है इसका सीधा कार्यान्वयन। मीट्रिक परिभाषाओं को वर्जन्ड कोड के रूप में मालिकों, समीक्षा, और परीक्षणों के साथ मानें, ठीक वैसे ही जैसे अध्याय 7.1 आपसे डेटा को एक उत्पाद के रूप में मानने के लिए कहता है।

परंपराएँ, नामकरण, और दस्तावेज़ीकरण स्थापित करें

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

मॉडल को विकसित होने योग्य रखें

आपका मॉडल बदलेगा, इसलिए परिवर्तन के लिए डिज़ाइन करें। मौजूदा कॉलम को फिर से उपयोग करने के बजाय कॉलम जोड़ें। सरोगेट कुंजियों का उपयोग करें ताकि स्रोत सिस्टम की नैचुरल कुंजी में बदलाव आपके वेयरहाउस में न फैले। मीट्रिक परिभाषाओं को वर्जन करें और उन्हें चल रहे डैशबोर्ड के नीचे चुपचाप बदलने के बजाय सूचना के साथ पदावनत करें। परिवर्तनों को वर्जन कंट्रोल में, परीक्षित और समीक्षित रखें, ताकि “active user” का क्या मतलब है इसमें बदलाव एक diff और एक स्वीकृतकर्ता वाला पुल रिक्वेस्ट हो, BI टूल में एक चुपचाप संपादन नहीं। एक ऐसा मॉडल जिसे आप सुरक्षित रूप से विकसित नहीं कर सकते वह एक ऐसा मॉडल बन जाता है जिसके चारों ओर लोग घूम जाते हैं, और छाया परिभाषाएँ यही हैं कि कैसे एकल सत्य स्रोत मर जाता है।

ट्रेड-ऑफ़: पक्ष और विपक्ष

दृष्टिकोण	पक्ष	विपक्ष	सबसे अच्छा फिट
नॉर्मलाइज़्ड (3NF)	सही राइट, कोई रिडंडेंसी नहीं, लचीला	धीमे एनालिटिकल जॉइन, जटिल क्वेरी	OLTP और परिचालन सिस्टम
स्टार स्कीमा (Kimball)	तेज़, सहज, विश्लेषक-अनुकूल	कुछ रिडंडेंसी, बनाए रखने के लिए ETL	अधिकांश एनालिटिक्स और BI
स्नोफ्लेक स्कीमा	कम स्टोरेज, साफ़ डाइमेंशन	अधिक जॉइन, अधिक जटिलता	बड़े, कड़े गवर्न्ड डाइमेंशन
डेटा वॉल्ट	पूरा इतिहास, ऑडिटेबल, चुस्त लोड	कई टेबल, खड़ी सीखने की अवस्था	अत्यधिक विनियमित, ऑडिट-भारी
मॉडल पर सिमेंटिक लेयर	हर जगह एक परिभाषा, टूल-अज्ञेय	अग्रिम निर्माण, स्वामित्व की आवश्यकता	बहु-टीम, बहु-टूल संगठन

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. जब दो डैशबोर्ड एक ही मीट्रिक के लिए अलग-अलग संख्याएँ दिखाते हैं, तो किसकी परिभाषा जीतती है, और वह परिभाषा भौतिक रूप से कहाँ रहती है? यह प्रश्न उजागर करता है कि क्या आपके पास वास्तव में एक एकल सत्य स्रोत है या आप केवल यह मानते हैं। अधिकांश बड़ी टीमों में ईमानदार उत्तर यह है कि “active user” को एक दर्जन अलग-अलग क्वेरी में फिर से परिभाषित किया जाता है, और विजेता वह होता है जो बैठक में सबसे ज़ोर से बहस करता है। वास्तविक साक्ष्य लाएँ: एक मीट्रिक चुनें, हर जगह ढूँढें जहाँ इसकी गणना होती है, और तर्क की पंक्ति-दर-पंक्ति तुलना करें। आपको लगभग निश्चित रूप से विंडो, बहिष्करण, और किनारे के मामलों के बारे में शांत असहमतियाँ मिलेंगी। उत्तर को एक सिमेंटिक लेयर बनाने का निर्णय चलाना चाहिए जहाँ हर मीट्रिक को समीक्षित कोड के रूप में एक बार परिभाषित किया जाता है, ताकि प्रश्न लोगों के बारे में होना बंद हो जाए और एक वर्जन्ड कलाकृति के बारे में होने लगे। जब तक उस परिभाषा का एक एकल भौतिक घर नहीं है, हर सुलह अस्थायी है।

2. आपकी सबसे महत्वपूर्ण फ़ैक्ट टेबल का ग्रेन क्या है, और क्या कमरे में हर कोई इसे उसी तरह बता सकता है? ग्रेन वह शांत नींव है जिस पर अधिकांश मॉडलिंग विफलताएँ वापस जाती हैं। यदि आधी टीम कहती है “प्रति ऑर्डर एक पंक्ति” और दूसरी आधी कहती है “प्रति लाइन आइटम एक पंक्ति,” तो आपके पास एक दोगुनी-गिनती बग है जो एक राजस्व रिपोर्ट में सामने आने की प्रतीक्षा कर रही है। वास्तविक टेबल लाएँ और हर व्यक्ति से एक पंक्ति को एक वाक्य में वर्णित करने के लिए कहें। यहाँ असहमति सुधारने वाली एक संचार समस्या नहीं है; यह एक डिज़ाइन दोष है जिसे इसके ऊपर और माप ढेर होने से पहले ठीक करना है। उत्तर को मॉडल के दस्तावेज़ीकरण में लिखा जाना चाहिए और समीक्षा में लागू किया जाना चाहिए, क्योंकि एक बार जब विश्लेषक एक अस्पष्ट ग्रेन पर क्वेरी बनाते हैं, तो अस्पष्टता आपके सुधारने से तेज़ी से फैलती है।

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

4. कौन से डाइमेंशन को हर टीम में एक ही चीज़ का मतलब होना चाहिए, और हर एक के स्वामित्व के लिए कौन जवाबदेह है? कॉनफ़ॉर्म्ड डाइमेंशन वे हैं जो मार्केटिंग, वित्त, और संचालन को अपने डेटा को जोड़ने और तुलनीय उत्तर पाने देते हैं, लेकिन तभी जब “customer,” “product,” “region,” और “date” प्रति टीम एक निजी प्रति के बजाय एक सहमत परिभाषा रखते हैं। प्रतिस्पर्धी खिंचाव स्वायत्तता है: हर टीम अपनी गति से अपनी दुनिया को मॉडल करना चाहती है, और एक साझा डाइमेंशन को बाध्य करना उन्हें अल्पकालिक रूप से धीमा कर देता है जबकि यह एस्टेट में लाभदायक होता है। दो या तीन डाइमेंशन लाएँ जो सबसे अधिक क्रॉस-टीम रिपोर्ट में दिखाई देते हैं, आज मौजूद हर संस्करण को सूचीबद्ध करें, और देखें कि उनकी कुंजियाँ और विशेषताएँ वास्तव में कितनी भिन्न हैं। हर कॉनफ़ॉर्म्ड डाइमेंशन के लिए एक मालिक का नाम बताएँ, क्योंकि बिना मालिक वाला एक साझा डाइमेंशन एक तिमाही के भीतर निजी प्रतियों में वापस बह जाता है। उद्यम और सरकारी सेटिंग में, जहाँ एक विभाग की संख्या की सार्वजनिक रूप से दूसरे से तुलना की जाती है, एक असंगत डाइमेंशन एक ईमानदार तुलना और एक आकस्मिक असत्य के बीच का अंतर है, इसलिए जल्दी तय करें कि कौन से डाइमेंशन केंद्रीय रूप से गवर्न्ड हैं और कौन से स्थानीय रहते हैं।

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

6. क्या आपको सिमेंटिक लेयर बनानी चाहिए या खरीदनी चाहिए, और एक बार यह मौजूद होने पर हर मीट्रिक परिभाषा को अद्यतन रखने के लिए कौन जवाबदेह है? एक सिमेंटिक लेयर केवल तभी एक एकल सत्य स्रोत देती है जब इसका स्वामित्व और रखरखाव हो, इसलिए टूल का चुनाव उतना मायने नहीं रखता जितना यह उत्तर कि “revenue” का क्या मतलब है इसमें बदलाव की समीक्षा कौन करता है और जब एक परिभाषा बासी हो जाती है तो कौन ज़िम्मेदार है। प्रतिस्पर्धी विचार वास्तविक हैं: एक निर्माण आपको नियंत्रण देता है और आपके स्टैक में फिट बैठता है लेकिन एक इंजीनियरिंग बोझ जोड़ता है, जबकि एक मीट्रिक्स टूल खरीदना तेज़ है फिर भी लॉक-इन और एक परिभाषा भाषा का जोखिम रखता है जिसे आप पूरी तरह से नियंत्रित नहीं करते। अपने कुछ सबसे उच्च-दांव वाले मीट्रिक लाएँ, वे टूल जो आज उनका उपभोग करते हैं, और एक ईमानदार पठन कि क्या वर्तमान में कोई उन परिभाषाओं का मालिक है या वे केवल मौजूद हैं। पहले से तय करें कि क्या परिभाषाएँ नामित मालिकों और परीक्षणों के साथ वर्जन्ड कोड के रूप में रहती हैं, क्योंकि एक सिमेंटिक लेयर जिसे कोई बनाए नहीं रखता वह उन्हीं बिखरी हुई परिभाषाओं में सड़ जाती है जिन्हें इसे बदलना था। उद्यम और सरकारी रिपोर्टिंग में, जहाँ एक सार्वजनिक डैशबोर्ड पर एक मीट्रिक को एक दस्तावेज़ीकृत, समीक्षित परिभाषा से ट्रेस करने योग्य होना चाहिए, वह स्वामित्व और एक संख्या की वंशावली साबित करने की क्षमता वही है जो सिमेंटिक लेयर को एक सुविधा से एक ऑडिटेबल नियंत्रण में बदल देती है।

क्षेत्र लेंस

स्टार्टअप। मॉडलिंग प्रतीक्षा कर सकती है, लेकिन परिभाषाएँ नहीं। दो इंजीनियरों और वेयरहाउस बनाने के लिए कोई रनवे न होने पर, अपने ट्रांसफ़ॉर्मेशन टूल में एक छोटी सिमेंटिक लेयर रखें और उन दो या तीन मीट्रिक को परिभाषित करें जिन्हें आपका बोर्ड वास्तव में देखता है, “active user” और “revenue,” एक बार परीक्षित कोड के रूप में। डेटा वॉल्ट और विस्तृत डायमेंशनल स्कीमा छोड़ें; एक पतला स्टार और मुट्ठी भर गवर्न्ड परिभाषाएँ आपको डिलीवरी धीमी किए बिना संगत संख्याएँ खरीदती हैं। फ़ायदा यह है कि बोर्ड तैयारी किसकी क्वेरी सही है इसकी बहस होना बंद कर देती है।

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

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

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

उदाहरण

स्टार्टअप। एक Series A कंपनी के पास तीन स्थानों में रहने वाली “active user” की तीन परिभाषाएँ थीं: उत्पाद एनालिटिक्स टूल, वित्त स्प्रेडशीट, और निवेशक डेक। संख्याएँ कभी मेल नहीं खातीं, और हर बोर्ड तैयारी एक हड़बड़ी में बदल जाती। दो इंजीनियरों ने अपने ट्रांसफ़ॉर्मेशन टूल में एक छोटी सिमेंटिक लेयर पेश की, “active user” और “monthly recurring revenue” को एक बार परीक्षित कोड के रूप में परिभाषित करते हुए, सटीक विंडो और बहिष्करण के साथ लिखा गया। हर डैशबोर्ड अब उन परिभाषाओं को पढ़ता है। बोर्ड-तैयारी बहस गायब हो गई, और एक नए विश्लेषक को ऑनबोर्ड करना गोत्रीय ज्ञान के एक सप्ताह से एक दस्तावेज़ीकृत मॉडल पढ़ने में बदल गया। यह सीधे अध्याय 7.4 (उत्पाद एनालिटिक्स और प्रयोग) में वर्णित अनुशासन से जुड़ता है, जहाँ “active” की एक स्थिर परिभाषा वह है जो प्रयोग परिणामों को तुलनीय बनाती है।

उद्यम। एक वैश्विक खुदरा विक्रेता मार्केटिंग, वित्त, आपूर्ति श्रृंखला, मर्चेंडाइजिंग, और स्टोर में पाँच बिज़नेस-इंटेलिजेंस टूल चलाता था, और प्रत्येक ने “gross margin” को थोड़ा अलग तरीके से फिर से आविष्कार किया था। उन्होंने कॉनफ़ॉर्म्ड डाइमेंशन के साथ एक Kimball-शैली के वेयरहाउस के ऊपर एक सिमेंटिक लेयर बनाई, ताकि “product,” “store,” और “date” हर फ़ैक्ट टेबल और हर टूल में एक ही चीज़ का मतलब रखें। हर मीट्रिक को एक बार परिभाषित किया गया और हर जगह उपभोग किया गया। सुलह बैठकें जो हुआ करती थीं जो प्रति तिमाही दिन खा जाती थीं, ज़्यादातर गायब हो गईं, और जब वित्त ने बदला कि रिटर्न मार्जिन को कैसे प्रभावित करते हैं, तो परिवर्तन सभी पाँच टूलों में एक साथ फैल गया। कॉनफ़ॉर्म्ड डाइमेंशन वे थे जो स्वतंत्र टीमों को संदेह के बजाय आत्मविश्वास के साथ अपने डेटा को जोड़ने देते थे।

सरकार। एक राष्ट्रीय सरकार को स्वास्थ्य, श्रम, और शिक्षा एजेंसियों में तुलनीय रिपोर्टिंग की आवश्यकता थी, जिनमें से प्रत्येक ने ऐतिहासिक रूप से “household,” “region,” और “employment” को अपने तरीके से परिभाषित किया था। एक क्रॉस-एजेंसी निकाय ने साझा संदर्भ डेटा और मानक परिभाषाएँ स्थापित कीं: भूगोल और जनसांख्यिकी के लिए कैनोनिकल डाइमेंशन टेबल, और मुख्य संकेतकों की गवर्न्ड परिभाषाएँ, कार्यप्रणाली और वर्जन्ड रिलीज़ के साथ प्रकाशित। व्यक्तिगत एजेंसियाँ अपना खुद का परिचालन डेटा मॉडल करती हैं लेकिन राष्ट्रीय स्तर पर रिपोर्ट की गई किसी भी चीज़ के लिए साझा डाइमेंशन और परिभाषाओं के अनुरूप होती हैं। परिणाम यह है कि एक एजेंसी की एक संख्या की दूसरे से ईमानदारी से तुलना की जा सकती है, और जनता किसी भी प्रकाशित संकेतक को एक दस्तावेज़ीकृत परिभाषा तक वापस ट्रेस कर सकती है, अध्याय 7.1 में कवर की गई पारदर्शिता बाध्यताओं का समर्थन करते हुए।

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

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

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

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

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

चर्चा के लिए विचार

1. अपनी तीन सबसे महत्वपूर्ण मीट्रिक चुनें। आज आपके टूल में प्रत्येक की कितनी अलग-अलग परिभाषाएँ मौजूद हैं, और उन्हें एक में ढहाने के लिए क्या लगेगा?
2. एक अनकही ग्रेन ने कहाँ एक वास्तविक रिपोर्टिंग त्रुटि पैदा की, और इसे नोटिस करने में कितना समय लगा?
3. आपके किन डाइमेंशन को पहले टीमों में अनुरूप बनाया जाना चाहिए, और उनका मालिक कौन है?
4. क्या आपकी मीट्रिक परिभाषाएँ समीक्षा के साथ वर्जन कंट्रोल में हैं, या एक BI टूल के भीतर चुपचाप संपादन योग्य हैं?
5. एक धीरे-धीरे बदलते डाइमेंशन ने आखिरी बार आपका इतिहास कब फिर से लिखा बिना किसी के नोटिस किए, और अगली बार आप इसे कैसे पकड़ेंगे?
6. यदि आपने कल अपना वेयरहाउस इंजन बदल दिया, तो आपके मॉडल के अर्थ का कितना हिस्सा उस चाल में जीवित रहेगा?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• Ralph Kimball and Margy Ross, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling.
• Bill Inmon, Building the Data Warehouse.
• Dan Linstedt and Michael Olschimke, Building a Scalable Data Warehouse with Data Vault 2.0.
• Peter Chen, “The Entity-Relationship Model: Toward a Unified View of Data,” ACM Transactions on Database Systems.
• E. F. Codd, “A Relational Model of Data for Large Shared Data Banks,” Communications of the ACM.
• C. J. Date, An Introduction to Database Systems.
• Lars Rönnbäck and colleagues, writings on anchor modeling.
• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge.