डेटा को उसकी सही जगह रखें

🌐 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 से बनाई गई इमेज

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

मॉड्यूल 4 (कुल 6 में से) — अध्याय अर्थ के लिए डेटा मॉडलिंग, Data Architect कोर्स का अध्याय 2। हर मॉड्यूल अपने आप में पूरा है। पिछला: लॉजिकल मॉडल बनाएँ · अगला: तीसरे नॉर्मल फ़ॉर्म तक डिज़ाइन करें, फिर पीछे हटें

यह मॉड्यूल किस सवाल का जवाब देता है: नॉर्मलाइज़ेशन मुझे यह पता लगाने में कैसे मदद करता है कि डेटा असल में कहाँ का है?

हमारे पास एक लॉजिकल मॉडल है: एंटिटी, संबंध, एट्रिब्यूट और की। अब मैं डेटा मॉडलिंग का एक सबसे अहम सवाल पूछना चाहता हूँ: क्या यह डेटा सच में यहीं का है?

सुनने में आसान लगता है। है नहीं। मैंने ऐसे बहुत-से सिस्टम देखे हैं जहाँ हर फ़ील्ड बनाते समय समझ में आता था। समस्या यह नहीं थी कि फ़ील्ड बेतुके थे; समस्या यह थी कि तथ्य ग़लत जगह स्टोर किए गए थे। एक डिलीवरी में ऐसी जानकारी है जो असल में किसी डिस्ट्रिब्यूशन सेंटर का वर्णन करती है। एक ही पता सैकड़ों रिकॉर्ड पर दिखता है। एक फ़ील्ड में कॉमा से अलग तीन वैल्यू हैं। बिज़नेस के एक तथ्य में बदलाव का मतलब है 10,000 रिकॉर्ड अपडेट करना। यही वह समस्या है जिसे हल करने में नॉर्मलाइज़ेशन (normalization) हमारी मदद करता है, और डेटाबेस की शब्दावली में दबने से पहले, पूरा विचार यह है: हर तथ्य को वहीं रखें जहाँ का वह है। इस मॉड्यूल की बाकी हर बात हमें यह काम ज़्यादा व्यवस्थित ढंग से करने में मदद करती है।

नॉर्मलाइज़ेशन क्या है?

नॉर्मलाइज़ेशन डेटा को इस तरह व्यवस्थित करना है कि हर तथ्य एक ही बार, अपनी सही जगह पर स्टोर हो। जब एक टेबल बहुत सारे काम कर रही हो, तो हम उसे ऐसी टेबलों में बाँट देते हैं जिनमें से हर एक एक ही चीज़ का वर्णन करती है, और उन्हें की से जोड़ते हैं।

यह झंझट क्यों? क्योंकि एक बार स्टोर किया गया तथ्य एक ही बार बदलना पड़ता है। नॉर्मलाइज़ेशन दोहराव (redundancy) को रोकता है, यानी एक ही तथ्य का कई रिकॉर्ड में कॉपी होना, और उसके साथ वे असंगतियाँ भी जो तब घुस आती हैं जब एक कॉपी अपडेट हो और बाकी नहीं। इसीलिए यह Salesforce जैसे ट्रांज़ैक्शनल सिस्टम के लिए ठीक बैठता है, जहाँ दिन भर रिकॉर्ड बनते और अपडेट होते रहते हैं।

हम नॉर्मलाइज़ेशन कदमों में करते हैं, जिन्हें नॉर्मल फ़ॉर्म (normal forms) कहते हैं, और हर कदम एक ही सवाल पूछता है:

• पहला नॉर्मल फ़ॉर्म (1NF): हर फ़ील्ड में एक वैल्यू, और कुछ ऐसा जो हर पंक्ति को यूनिक तौर पर पहचाने।
• दूसरा नॉर्मल फ़ॉर्म (2NF): हर तथ्य उस पूरी चीज़ का वर्णन करता है जो पंक्ति को पहचानती है, सिर्फ़ उसके एक हिस्से का नहीं।
• तीसरा नॉर्मल फ़ॉर्म (3NF): हर तथ्य इसी चीज़ का वर्णन करता है, किसी ऐसी दूसरी चीज़ का नहीं जिससे यह जुड़ी है।

तीसरे के आगे और भी फ़ॉर्म हैं। उनके बारे में मैं बाद में थोड़ा कहूँगा, और यह भी कि हम आमतौर पर तीसरे पर क्यों रुक जाते हैं। पहले, तीनों कदमों को होते हुए देखते हैं।

हम नॉर्मलाइज़ क्यों करते हैं?

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

बैठो, रुको, मॉडल करो

शुरुआत: कच्ची स्प्रेडशीट। मैं स्क्रीन पर कुछ कुत्ते डालता हूँ, और फिर कमरे के लोग अपने कुत्ते जोड़ते हैं। कुछ ही मिनटों में हमारे पास एक बड़ी सूची होती है: कुत्ता, उसके जन्म का साल, उसका मालिक कौन है, मालिक कहाँ रहता है, नस्ल, उसे किसने ब्रीड किया, और वह कौन-से करतब जानता है।

कुत्ता	जन्म	मालिक	ZIP	शहर	नस्ल	ब्रीडर	करतब
Bella	2017	Marcus	80202	Denver	लैब्राडोर	Maple Ridge	बैठो, रुको, हाथ मिलाओ
Milo	2019	Marcus	80202	Denver	पूडल	Golden Meadow	बैठो, लोटो
Max	2022	Ana	64105	Kansas City	मिक्स्ड		बैठो, मरने का नाटक
Luna	2020	Kenji	98101	Seattle	हस्की	Cascade	बैठो, रुको, घूमो
Rocky	2024	Priya	30301	Atlanta	बीगल	Maple Ridge	बैठो
Coco	2014	Ana	64105	Kansas City	चिहुआहुआ	Little Paws	हाथ मिलाओ, घूमो

यह काम करती है। हर स्प्रेडशीट पहले दिन काम करती है। लेकिन देखिए कि अभी से क्या ग़लत है। मैं हर वह कुत्ता कैसे ढूँढूँ जो हाथ मिलाओ जानता है? Ana का ZIP दो पंक्तियों में है, और Marcus का भी: अगर कोई एक को अपडेट करे और दूसरे को नहीं, तो क्या होगा? Maple Ridge दो बार आता है, और Kansas City भी। और Max आश्रय-घर से आया था, तो उसका कोई ब्रीडर है ही नहीं।

कदम 1: पहला नॉर्मल फ़ॉर्म। दो नियम। हर फ़ील्ड में एक ही वैल्यू हो, तो करतबों की कॉमा वाली सूची हटानी होगी। और हर पंक्ति को कुछ ऐसा चाहिए जो उसे यूनिक तौर पर पहचाने। कुत्ते का नाम नहीं; Max नाम के बहुत सारे कुत्ते हैं। एक ID: अपने-आप बनने वाला ID या GUID। करतब अपनी अलग पंक्तियों में निकल आते हैं, हर कुत्ते और हर करतब के लिए एक पंक्ति। और जब किसी करतब की अपनी पंक्ति हो, तो उस बात की जगह बनती है जो कॉमा वाली सूची में कभी कही ही नहीं जा सकती थी: करतब कितना कठिन है, यह कुत्ता उसे कितना अच्छा करता है, और उसने यह कब सीखा।

कुत्ता (Dog ID से पहचाना जाता है)

Dog ID	नाम	जन्म	मालिक	ZIP	शहर	नस्ल	ब्रीडर
D-001	Bella	2017	Marcus	80202	Denver	लैब्राडोर	Maple Ridge
D-002	Milo	2019	Marcus	80202	Denver	पूडल	Golden Meadow
D-003	Max	2022	Ana	64105	Kansas City	मिक्स्ड
D-004	Luna	2020	Kenji	98101	Seattle	हस्की	Cascade
D-005	Rocky	2024	Priya	30301	Atlanta	बीगल	Maple Ridge
D-006	Coco	2014	Ana	64105	Kansas City	चिहुआहुआ	Little Paws

कुत्ते का करतब (Dog ID + करतब से पहचाना जाता है)

Dog ID	करतब	कठिनाई	कौशल-स्तर	सीखा
D-001	बैठो	आसान	माहिर	2017-11
D-001	रुको	आसान	माहिर	2018-01
D-001	हाथ मिलाओ	मध्यम	अच्छा	2018-06
D-002	बैठो	आसान	माहिर	2020-02
D-002	लोटो	कठिन	सीख रहा है	2023-05
D-003	बैठो	आसान	अच्छा	2022-06
D-003	मरने का नाटक	कठिन	सीख रहा है	2024-03
D-004	बैठो	आसान	माहिर	2020-11
D-004	रुको	आसान	अच्छा	2021-01
D-004	घूमो	मध्यम	माहिर	2021-06
D-005	बैठो	आसान	सीख रहा है	2025-02
D-006	हाथ मिलाओ	मध्यम	माहिर	2015-06
D-006	घूमो	मध्यम	सीख रहा है	2025-04

अब “हर वह कुत्ता जो हाथ मिलाओ जानता है” एक आसान सवाल है। लेकिन ध्यान दें कि कुत्ते का करतब किससे पहचाना जाता है: एक चीज़ से नहीं, दो चीज़ों के मेल से, कुत्ता और करतब। इस बात को पकड़े रखें।

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

करतब

Trick ID	करतब	कठिनाई
T-01	बैठो	आसान
T-02	रुको	आसान
T-03	हाथ मिलाओ	मध्यम
T-04	लोटो	कठिन
T-05	मरने का नाटक	कठिन
T-06	घूमो	मध्यम

कुत्ते का करतब (Dog ID + Trick ID)

Dog ID	Trick ID	कौशल-स्तर	सीखा
D-001	T-01	माहिर	2017-11
D-001	T-02	माहिर	2018-01
D-001	T-03	अच्छा	2018-06
D-002	T-01	माहिर	2020-02
D-002	T-04	सीख रहा है	2023-05
D-003	T-01	अच्छा	2022-06
D-003	T-05	सीख रहा है	2024-03
D-004	T-01	माहिर	2020-11
D-004	T-02	अच्छा	2021-01
D-004	T-06	माहिर	2021-06
D-005	T-01	सीख रहा है	2025-02
D-006	T-03	माहिर	2015-06
D-006	T-06	सीख रहा है	2025-04

कुत्ते के करतब की यह टेबल वही है जो हमें मॉड्यूल 2 में मिली थी, और डेटा मॉडलिंग में इसका एक नाम है: जंक्शन (junction), या जैसा मैं कहता हूँ, तार्किक जंक्शन ऑब्जेक्ट (logical junction object)। एक कुत्ता कई करतब जानता है; एक करतब कई कुत्ते जानते हैं। जंक्शन उनके बीच बैठता है, और यह ख़ाली पाइपलाइन नहीं है: इसमें वे तथ्य हैं जो ख़ुद संबंध के हैं, कौशल-स्तर और तारीख़। मॉड्यूल 6 में हम इससे फिर मिलेंगे, और अध्याय 3 में देखेंगे कि Salesforce “junction object” शब्द को ज़्यादा सीमित अर्थ में इस्तेमाल करता है: Salesforce Junction Object दो master-detail संबंधों वाला एक कस्टम ऑब्जेक्ट है (अध्याय 3, मॉड्यूल 7)।

कदम 3: तीसरा नॉर्मल फ़ॉर्म। अब कुत्ते वाली टेबल पर वापस। उस पर सब कुछ Dog ID से पहचाना जाता है, इसलिए दूसरे नॉर्मल फ़ॉर्म के पास कहने को कुछ नहीं। तीसरा नॉर्मल फ़ॉर्म एक अलग सवाल पूछता है: यह तथ्य कुत्ते का वर्णन करता है, या किसी ऐसी दूसरी चीज़ का जिससे कुत्ता जुड़ा है? नस्ल अपने आप में एक चीज़ है: लैब्राडोर लैब्राडोर ही है, कुत्ता कोई भी हो, और उसके बारे में तथ्य, जैसे उसका आकार, नस्ल के हैं, Bella के नहीं। ZIP और शहर मालिक का वर्णन करते हैं, कुत्ते का नहीं: Ana वहीं रहती है, हम उसका कोई भी कुत्ता देखें। ब्रीडर के ब्योरे ब्रीडर का वर्णन करते हैं। इनमें से हर एक किसी दूसरे तथ्य के बारे में तथ्य है, इसलिए हर एक अपनी टेबल में चला जाता है, और कुत्ता फ़ॉरेन की (foreign key) से उसकी ओर इशारा करता है:

• कुत्ता: Dog ID, नाम, जन्म, Owner ID, Breed ID, Breeder ID
• मालिक: Owner ID, नाम, ZIP, शहर
• नस्ल: Breed ID, नस्ल, आकार
• ब्रीडर: Breeder ID, नाम, शहर
• करतब और कुत्ते का करतब, कदम 2 से

अब Ana एक बार स्टोर है, और उसके दोनों कुत्ते उसकी ओर इशारा करते हैं। Maple Ridge एक बार स्टोर है, और नस्ल की टेबल हर नस्ल के तथ्यों को, जैसे उसके आकार को, एक घर देती है, जिन्हें रखने की स्प्रेडशीट में कोई जगह नहीं थी। फ़ॉरेन की ख़ाली हो सकती है: Max का कोई Breeder ID नहीं है, और यह एक ईमानदार जवाब है, कोई कमी नहीं। फिर मैं कमरे के सामने एक चालाक सवाल फेंकता हूँ: मालिक को कुत्ता कब मिला, वह तारीख़ कहाँ जाएगी? कुत्ते पर। इस मॉडल में एक कुत्ते का एक समय में एक ही मालिक होता है, इसलिए वह तारीख़ कुत्ते के अपने मालिक से संबंध का वर्णन करती है।

आप एक कदम और आगे जाकर शहर को ZIP से अलग कर सकते हैं; पाठ्यपुस्तकें ऐसा करती हैं। व्यवहार में पता एक साथ ही रहता है, और वैसे भी Kansas City दो राज्यों में है, यह अच्छी याद दिलाता है कि असली दुनिया हमारी पाठ्यपुस्तकें नहीं पढ़ती।

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

Click to enlarge

इसे समझने के लिए किसी को Salesforce का एक भी शब्द नहीं चाहिए था। बस कुत्ते, उनके आसपास के लोग, और वे क्या जानते हैं।

अब इसे Steve Trucking पर लागू करें

कुत्तों से ये चालें देखना आसान हो जाता है। असली बिज़नेस में ये मायने रखती हैं, क्योंकि बड़े पैमाने पर वही ग़लतियाँ असली पैसा खाती हैं। तो वही तीन सवाल Steve Trucking पर ले चलते हैं। सोचिए कि वह अपनी डिलीवरी ऐसे रखती है:

डिलीवरी	रिटेल पार्टनर	डिस्ट्रिब्यूशन सेंटर	DC का शहर	क्रू	ट्रक
1001	Keystone	Keystone Phoenix DC	Phoenix	क्रू 12	117
1002	Keystone	Keystone Phoenix DC	Phoenix	क्रू 8	122
1003	Keystone	Keystone Phoenix DC	Phoenix	क्रू 12	117

पहली नज़र में यहाँ कुछ भी पेचीदा नहीं है। लेकिन डिस्ट्रिब्यूशन सेंटर को देखिए। हम वहाँ से निकलने वाली हर डिलीवरी पर “Keystone Phoenix DC, Phoenix” दोहराते हैं: Steve Trucking नौ DC से रोज़ लगभग 3,300 डिलीवरी करती है, यानी हर एक से रोज़ कुछ सौ। अगर वह DC कहीं और चला जाए तो क्या होगा? हम कितने रिकॉर्ड बदलेंगे, और अगर एक छूट गया तो क्या होगा? तब डेटा कहता है कि DC एक साथ दो शहरों में है। यह है अपडेट विसंगति (update anomaly)। अगर हम किसी नए DC को उसकी पहली डिलीवरी से पहले सेट अप करना चाहें तो? अगर हम किसी DC की आख़िरी डिलीवरी डिलीट कर दें: क्या हमने वह इकलौती जगह भी डिलीट कर दी जहाँ उसके बारे में कुछ भी स्टोर था?

ये एक ही समस्या के अलग-अलग लक्षण हैं: हमने अलग-अलग चीज़ों के तथ्य आपस में मिला दिए। डिस्ट्रिब्यूशन सेंटर के तथ्य डिस्ट्रिब्यूशन सेंटर के साथ रहें। डिलीवरी के तथ्य डिलीवरी के साथ। क्रू के तथ्य क्रू के साथ। व्यावहारिक भाषा में यही नॉर्मलाइज़ेशन है।

पहला नॉर्मल फ़ॉर्म: दोहराई जाने वाली संरचना को न छिपाएँ

पहले नॉर्मल फ़ॉर्म, यानी 1NF, से शुरू करते हैं, जहाँ लोग कभी-कभी नॉर्मलाइज़ेशन को ज़रूरत से ज़्यादा मुश्किल बना देते हैं।

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

Click to enlarge

1NF का व्यावहारिक सबक: दोहराई जाने वाली संरचना को फ़ील्ड के अंदर न छिपाएँ। अगर बिज़नेस बताता है कि कोई चीज़ कई बार हो सकती है, तो सुनें। हो सकता है कोई और एंटिटी बाहर निकलने की कोशिश कर रही हो।

असली org में आप यह हर समय देखेंगे। किसी को कई भाषाओं में विवरण चाहिए, तो वे Description_English नाम का फ़ील्ड बनाते हैं, फिर Description_French, फिर Description_German। या किसी अप्रूवल के लिए कुछ लोग चाहिए, तो हमें मिलते हैं Approver 1, Approver 2, Approver 3। जब रिव्यू में मुझे ऐसा मिलता है, तो हाथ पर चपत, अपना डेटा मॉडल ठीक करो। एक या दो, शायद, अगर बिज़नेस में सच में कभी एक या दो से ज़्यादा नहीं होते। उससे आगे कुछ भी हो तो वह चाइल्ड ऑब्जेक्ट होना चाहिए: भाषा के साथ एक Translation, अप्रूवर के साथ एक Approval Step। अगली भाषा, या चौथा अप्रूवर, एक नया रिकॉर्ड बनता है, न कि नया फ़ील्ड और एक डिप्लॉयमेंट।

दूसरा नॉर्मल फ़ॉर्म: पूरी चीज़ का वर्णन करें

दूसरा नॉर्मल फ़ॉर्म, यानी 2NF, तब मायने रखता है जब कोई रिकॉर्ड कई चीज़ों के मेल से पहचाना जाता है। डिलीवरी आइटम को लीजिए। उसका अपना रिकॉर्ड ID है, लेकिन हर एक Delivery + Product के हिसाब से यूनिक है। मान लीजिए हम डिलीवरी, प्रोडक्ट, मात्रा और प्रोडक्ट का विवरण स्टोर करते हैं।

मात्रा यहाँ समझ में आती है: यह इस प्रोडक्ट का इस डिलीवरी पर वर्णन करती है। लेकिन प्रोडक्ट का विवरण मेल का वर्णन नहीं करता; वह प्रोडक्ट का वर्णन करता है। इसे हर डिलीवरी आइटम पर रख दें, और हर बार जब फ़्रिज का वह मॉडल किसी और ट्रक पर जाता है, हम इसे दोहराते हैं। यही संकेत है कि वह तथ्य कहीं और का है।

तो 2NF का सवाल है: क्या यह एट्रिब्यूट उस पूरी चीज़ का वर्णन करता है जिसे मैं पहचान रहा हूँ, या उसके सिर्फ़ एक हिस्से का? अगर यह सिर्फ़ प्रोडक्ट का वर्णन करता है, तो Product के साथ जाता है। अगर यह इस ख़ास डिलीवरी पर प्रोडक्ट की जगह का वर्णन करता है (मात्रा, इंस्टॉल होना है या नहीं), तो डिलीवरी आइटम पर जाता है। बहुत-से एडमिन कभी सोच-समझकर यह नहीं कहेंगे, “अब मैं दूसरा नॉर्मल फ़ॉर्म लागू कर रहा हूँ।” कोई बात नहीं। मुझे इससे कहीं ज़्यादा परवाह है कि आप यह पूछना सीखें: यह तथ्य असल में किसका वर्णन करता है?

तीसरा नॉर्मल फ़ॉर्म: दूसरे तथ्यों के बारे में तथ्य स्टोर न करें

अब वह, जिसकी रोज़ की मॉडलिंग में मुझे सबसे ज़्यादा परवाह है: तीसरा नॉर्मल फ़ॉर्म, यानी 3NF।

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

पाठ्यपुस्तक का क्लासिक उदाहरण पता है: ZIP कोड, शहर और राज्य हर रिकॉर्ड पर एक साथ स्टोर, जबकि शहर और राज्य आमतौर पर ZIP से ही निकल आते हैं। वही आकार, वही सवाल।

Click to enlarge

3NF का व्यावहारिक सवाल है: यह तथ्य इस चीज़ का वर्णन करता है, या किसी ऐसी दूसरी चीज़ का जिससे यह चीज़ जुड़ी है? मैं चाहता हूँ कि आप यह लगातार पूछते रहें।

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

Click to enlarge

वही तीन सवाल, वही नतीजा: हर तथ्य एक जगह।

1NF, 2NF और 3NF को समझने का एक आसान तरीका

आप नॉर्मलाइज़ेशन पर डेटाबेस का पूरा कोर्स बिता सकते हैं। हम ऐसा नहीं करेंगे। इस कोर्स के लिए मैं चाहता हूँ कि आपके पास एक काम करने वाले आर्किटेक्ट जितनी समझ हो:

• 1NF: क्या मैं किसी फ़ील्ड या रिकॉर्ड के अंदर कई वैल्यू या दोहराई जाने वाली संरचनाएँ छिपा रहा हूँ?
• 2NF: क्या यह तथ्य उस पूरी चीज़ का वर्णन करता है जिसे मैं पहचान रहा हूँ?
• 3NF: क्या यह तथ्य सच में इस एंटिटी का वर्णन करता है, या इससे जुड़ी किसी चीज़ का?

ये डेटाबेस की पाठ्यपुस्तक वाली परिभाषाएँ नहीं हैं। ये ऐसे सवाल हैं जिन्हें मैं डिज़ाइन करते हुए सच में इस्तेमाल कर सकता हूँ।

हाँ, नॉर्मलाइज़ेशन और आगे जाता है: Boyce-Codd Normal Form (BCNF) ज़्यादा पेचीदा की वाले मॉडल के लिए 3NF के आसपास के नियम कसता है, और चौथा, पाँचवाँ और यहाँ तक कि छठा नॉर्मल फ़ॉर्म भी है। ये दोहराव के ज़्यादा दुर्लभ रूपों से निपटते हैं, वे जो रोज़ के बिज़नेस रिकॉर्ड से कम और असामान्य की-संरचनाओं से ज़्यादा आते हैं। बहुत सारी थ्योरी, और मेरे अनुभव में Salesforce पर हम जिस तरह के सिस्टम बनाते हैं, उनके लिए उस सिरदर्द के लायक नहीं। बिज़नेस सिस्टम में दबाव आमतौर पर उल्टी दिशा में होता है: यूज़र, रिपोर्टिंग और परफ़ॉर्मेंस के लिए तीसरे नॉर्मल फ़ॉर्म से पीछे हटने की संभावना उससे आगे जाने से कहीं ज़्यादा है। वह अगला मॉड्यूल है। जानें कि आगे के फ़ॉर्म मौजूद हैं, लेकिन हम जो ज़्यादातर करते हैं उसके लिए 1NF से 3NF तक हमें वे सारे सोचने के औज़ार दे देते हैं जिनकी हमें ज़रूरत है।

तीसरे नॉर्मल फ़ॉर्म के लिए डिज़ाइन करें

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

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

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

आर्किटेक्ट यहाँ क्या तय करता है

लॉजिकल मॉडल को नॉर्मलाइज़ करते हुए मैं इन चीज़ों को ढूँढ रहा होता हूँ:

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

इसलिए नहीं कि हर फ़िज़िकल सिस्टम को पूरी तरह नॉर्मलाइज़्ड रहना चाहिए। बिल्कुल उल्टा। अगले मॉड्यूल में हम यूज़र, रिपोर्टिंग, स्केल, एनालिटिक्स और AI के लिए जानबूझकर साफ़ मॉडल से हटेंगे, और यह जानते हुए हटेंगे कि हम ठीक-ठीक क्या सौदा कर रहे हैं।