संबंध खींचें

🌐 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 द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

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

यह मॉड्यूल किस सवाल का जवाब देता है: संभावित एंटिटी (entities) को मैं कॉन्सेप्चुअल डेटा मॉडल में कैसे बदलूँ?

बोर्ड पर हमारे पास संज्ञाएँ हैं। अब मैं बॉक्स के बीच की रेखाओं के बारे में जानना चाहता हूँ, क्योंकि एंटिटी का ढेर अभी असल में डेटा मॉडल नहीं है। अर्थ का बड़ा हिस्सा संबंधों में ही रहता है। एक रिटेल पार्टनर (Retail Partner) डिस्ट्रिब्यूशन सेंटर चलाता है। एक मैनिफ़ेस्ट (Manifest) में डिलीवरी की सूची होती है। एक डिलीवरी किसी प्राप्तकर्ता (Recipient) के पास जाती है। एक क्रू (Crew) एक ट्रक चलाता है। इनमें से हर बात मुझे बिज़नेस के बारे में कुछ बताती है, और हर बात मुझे पूछने के लिए एक और सवाल देती है।

बिज़नेस की भाषा से शुरू करें

मैं अब भी Salesforce की बात नहीं करना चाहता। मैं यह नहीं पूछ रहा कि यह lookup संबंध होना चाहिए या master-detail संबंध, न Salesforce Junction Object के बारे में सोच रहा हूँ, न यह तय कर रहा हूँ कि पैरेंट रिकॉर्ड डिलीट होने पर क्या होगा। मैं बिज़नेस के संबंध को समझने की कोशिश कर रहा हूँ।

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

ये Salesforce के सवाल नहीं हैं। ये बिज़नेस के सवाल हैं, और इनके जवाब मॉडल को पूरी तरह बदल सकते हैं।

रेखाओं को पढ़ें

आगे बढ़ने से पहले मैं आपको वह भाषा देना चाहता हूँ जो हम यहाँ से हर डायग्राम पर इस्तेमाल करेंगे। यह छोटी-सी भाषा है। दो बॉक्स के बीच की रेखा कहती है कि दोनों चीज़ें आपस में जुड़ी हैं, और उसके सिरों पर बने निशान बताते हैं कितने।

एक सादी रेखा से शुरू करें, बिना किसी निशान के। व्हाइटबोर्ड पर मैं यहीं से शुरू करता हूँ: मुझे पता है कि ये दो संज्ञाएँ जुड़ी हैं, बस अभी पूछा नहीं कि कैसे। फिर सिरों पर निशान आते हैं। रेखा के आर-पार एक छोटी खड़ी लकीर, यानी क्रॉस, का मतलब है एक। क्रोज़ फ़ुट (crow’s foot), वह सिरा जो चिड़िया के पंजे की तरह तीन में बँट जाता है, उसका मतलब है कई। इसी मॉड्यूल में आगे आप पहले निशान के पास एक दूसरा निशान देखेंगे, एक लकीर या एक गोला, और वह एक अलग सवाल का जवाब देता है: क्या एक भी न हो, ऐसा हो सकता है?

याद रखने लायक एक ही नियम: हर निशान को उसी बॉक्स पर पढ़ें जिसे वह छूता है। बॉक्स के सबसे पास वाला निशान बताता है कि ज़्यादा से ज़्यादा कितने हो सकते हैं; उसके बाद वाला निशान बताता है कि कम से कम कितने।

Click to enlarge

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

Steve Trucking से पहले, मॉड्यूल 1 के कुत्तों पर वापस चलते हैं। हमारे पास पाँच बॉक्स थे: मालिक (Owner), ब्रीडर (Breeder), कुत्ता (Dog), नस्ल (Breed) और करतब (Trick)। अब मैं उनके बीच की रेखाओं के बारे में पूछता हूँ।

एक या कई? एक मालिक के पास एक से ज़्यादा कुत्ते हो सकते हैं; Ana के पास दो हैं। एक कुत्ते का एक मालिक होता है, कम से कम हमारे मॉडल में। यह one-to-many है: मालिक की तरफ़ एक लकीर, कुत्ते की तरफ़ क्रोज़ फ़ुट। ब्रीडर का आकार भी यही है: एक ब्रीडर कई कुत्ते ब्रीड करता है।

क्या एक भी न हो, ऐसा हो सकता है? Max आश्रय-घर (pound) से आया था, तो उसका कोई ब्रीडर है ही नहीं। ब्रीडर वाले सिरे पर गोला आता है: एक कुत्ते का शून्य या एक ब्रीडर होता है। लेकिन हर कुत्ते का एक मालिक ज़रूर होता है, इसलिए उस सिरे पर दूसरी लकीर आती है: ठीक एक।

कई से कई? एक कुत्ता कई करतब जानता है, और एक करतब, मान लीजिए बैठो, कई कुत्ते जानते हैं। यह many-to-many है, और ठीक यहीं मैं किसी छिपी अवधारणा को ढूँढने जाता हूँ। क्या इस कुत्ते के इस करतब को जानने के बारे में कुछ है? वह उसे कितनी अच्छी तरह करता है, और उसने कब सीखा। इस संबंध के अपने तथ्य हैं, इसलिए यह अपने आप में एक चीज़ बन जाता है: कुत्ते का करतब (Dog Trick), जिसमें कुत्ते का नाम पहले है, क्योंकि उसे चलाने वाला कुत्ता ही है।

हर रेखा का मतलब क्या है? मालिक कुत्ते का मालिक है। ब्रीडर उसे ब्रीड करता है। कुत्ता अपने करतब जानता है। रेखाओं को नाम दें, और कोई भी मॉडल को आपको वापस पढ़कर सुना सकता है।

अभी, या समय के साथ? क्या किसी को परवाह है कि Bella आज बैठो में कितनी अच्छी है, या वह वहाँ तक कैसे पहुँची? अगर कोई ट्रेनर हर कुछ महीनों में उसे जाँचता है, तो हर जाँच अपना एक रिकॉर्ड है: करतब का मूल्यांकन (Trick Assessment), तारीख, कौशल-स्तर और जाँचने वाले के नाम के साथ, उस कुत्ते के करतब के नीचे जिसका वह हिस्सा है। जो संबंध एक चीज़ बन गया, उसका भी अपना इतिहास हो सकता है।

नस्ल को मैं अभी किसी से नहीं जोड़ रहा। यह अब भी मॉड्यूल 1 वाला सवाल है, अपना अलग बॉक्स या कुत्ते पर लिखा एक शब्द, और मॉड्यूल 4 इसे तय करता है।

Click to enlarge

इनमें से हर सवाल असली बिज़नेस पर भी ठीक इसी तरह काम करता है। अब ये सवाल Steve Trucking से पूछते हैं।

पूछें “एक या कई?”

किसी संबंध के बारे में सबसे पहले मैं उसकी कार्डिनैलिटी (cardinality) समझना चाहता हूँ। यह डेटाबेस का शब्द है; सवाल इससे कहीं आसान है: इनमें से कितने, उनमें से कितनों से जुड़ सकते हैं? कॉन्सेप्चुअल (अवधारणात्मक) स्तर पर तीन बुनियादी पैटर्न हैं।

प्रक्रिया का यह एक अहम कदम है: दो अलग संज्ञाएँ लें और उनका संबंध समझें। ज़्यादातर मामलों में यह one-to-many या many-to-one होता है। one-to-one से आपका सामना बहुत कम ही होगा।

One-to-many हर जगह है। एक रिटेल पार्टनर के कई डिस्ट्रिब्यूशन सेंटर हैं। एक मैनिफ़ेस्ट में कई डिलीवरी हैं। एक रूट में लगभग दस स्टॉप होते हैं। जब मैं ऐसी भाषा सुनता हूँ, तो रेखा खींचना शुरू कर देता हूँ।

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

Click to enlarge

One-to-one संबंध होते हैं, लेकिन कम, और जब मुझे कोई मिलता है तो मैं कुछ सवाल पूछता हूँ। क्या ये सच में दो अलग संज्ञाएँ हैं, या एक ही? अगर अलग हैं, तो उनके बीच one-to-one संबंध क्या है? और क्या यह हमेशा one-to-one रहेगा, या सिर्फ़ अभी one-to-one है? डेटा मॉडल डिज़ाइन करने में ये अहम सवाल हैं। किसी भी सुबह एक क्रू और एक ट्रक one-to-one दिखते हैं: दो लोग, एक ट्रक, एक रूट। एक महीने में देखें तो नहीं, और इस मॉडल का सबसे दिलचस्प संबंध वहीं छिपा है।

Many-to-many संबंध ख़ास तौर पर दिलचस्प होते हैं, क्योंकि वे अक्सर बताते हैं कि बिज़नेस में कोई और अवधारणा है। क्या एक क्रू समय के साथ एक से ज़्यादा ट्रक चला सकता है? हाँ। क्या एक ट्रक को एक से ज़्यादा क्रू चला सकते हैं? उसकी पूरी ज़िंदगी में, बिल्कुल। तो क्रू और ट्रक के बीच many-to-many संबंध है। लेकिन अब मैं और जानना चाहता हूँ। क्या बिज़नेस को परवाह है कि किसी क्रू के पास ट्रक कब था? किस रूट के लिए, किस दिन? असाइनमेंट किसने किया? अगर संबंध ख़ुद ऐसी जानकारी रखता है जिसकी हमें परवाह है, तो हमने बिज़नेस की एक और अवधारणा खोज ली है: क्रू असाइनमेंट (Crew Assignment)।

यह मॉडलिंग की एक अहम आदत है। कभी-कभी सबसे दिलचस्प चीज़ वह संज्ञा नहीं होती जो हमने पहले सुनी। वह दो संज्ञाओं के बीच के संबंध में छिपी होती है।

संबंध भी चीज़ें बन सकते हैं

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

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

अगर आप Salesforce की दुनिया से आ रहे हैं, तो शायद आप सोच रहे होंगे, “यह तो जंक्शन ऑब्जेक्ट (junction object) है।” आप ग़लत नहीं हैं। लेकिन मैं वहाँ से शुरू नहीं करना चाहता। डिलीवरी आइटम पहले एक बिज़नेस अवधारणा है, Salesforce Junction Object बाद में। पहले बिज़नेस, फिर इम्प्लीमेंटेशन।

इन संबंध-एंटिटी के लिए मेरी कुछ आदतें, चाहे आख़िर में वे कहीं भी बनाई जाएँ।

इसे नाम दें। अगर बिज़नेस के पास इसके लिए पहले से कोई शब्द है, तो उन्हीं का शब्द लें। अगर नहीं है, तो दोनों पैरेंट के नाम लेकर उन्हें जोड़ दें। एक ऑर्डर और एक प्रोडक्ट के बारे में सोचें। उनके बीच की चीज़ है Order Item: ऑर्डर, और ऑर्डर पर रखा आइटम। यह दोनों पैरेंट का चाइल्ड है, और Salesforce में यह आख़िर में Salesforce Junction Object बन सकता है। लेकिन कौन-सा नाम पहले आए: Item Order या Order Item? देखें कि हर पैरेंट किस तरह का डेटा है। प्रोडक्ट रेफ़रेंस डेटा है; ऑर्डर ट्रांज़ैक्शनल है, और उसे चलाने वाला ऑर्डर ही है। तो यह Order Item है, या Order Product, ठीक वैसे ही जैसे Salesforce में Opportunity Product है। Steve Trucking में यह डिलीवरी आइटम (Delivery Item) है। चलाने वाला नाम पहले आता है, और फिर आप जो भी सूची देखेंगे, उसमें रिकॉर्ड अपने मालिक के बगल में ही आएगा।

इसे अपनी अलग की दें। यह कहने का मन होता है कि डिलीवरी आइटम का ID Delivery और Product से मिलकर बनता है, और वहीं रुक जाएँ। वह कंपाउंड की (compound key) है, और कंपाउंड की से निपटना कहीं ज़्यादा मुश्किल है: रिकॉर्ड की ओर इशारा करने वाले हर सिस्टम को दोनों हिस्से साथ रखने पड़ते हैं। संबंध-एंटिटी को उसका अपना ID दें, और Delivery और Product के मेल को यूनिक होने के नियम की तरह रखें, रिकॉर्ड ID की तरह नहीं।

Click to enlarge

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

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

संबंधों का अर्थ कार्डिनैलिटी से आगे है

किसी संबंध को समझने के लिए “one-to-many” काफ़ी नहीं है। मैं यह भी जानना चाहता हूँ कि संबंध का मतलब क्या है।

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

Click to enlarge

वैकल्पिकता भी मायने रखती है

“कितने?” के भीतर एक और सवाल छिपा है: क्या संबंध ज़रूरी है? क्या कोई डिलीवरी रूट पर डाले जाने से पहले मौजूद हो सकती है? उसे होना ही पड़ता है: मैनिफ़ेस्ट डिलीवरी से एक-दो दिन पहले आता है, और रूट पिछली शाम को तय होते हैं। क्या कोई डिलीवरी बिना रिटेल पार्टनर के मौजूद हो सकती है? नहीं; हर डिलीवरी किसी पार्टनर के मैनिफ़ेस्ट से आती है। यही है वैकल्पिकता (optionality)।

फिर से, सीधे Salesforce के Required (अनिवार्य) चेकबॉक्स पर न कूदें। “हर डिलीवरी का एक रिटेल पार्टनर होना ही चाहिए” कहने और “रिकॉर्ड बनाते समय Salesforce को रिटेल पार्टनर फ़ील्ड अनिवार्य करना चाहिए” कहने में फ़र्क है। हो सकता है दोनों का इम्प्लीमेंटेशन आख़िर में एक ही हो, लेकिन ये एक ही बात नहीं हैं। पहला बिज़नेस का नियम है; दूसरा उसे लागू करने का एक तरीका है। आर्किटेक्ट के तौर पर हम दूसरा तय करने से पहले पहला समझना चाहते हैं।

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

Click to enlarge

समय संबंधों को बदल देता है

यह सवाल मैं बहुत पूछता हूँ: आपका मतलब अभी से है, या समय के साथ से?

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

Click to enlarge

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

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

Click to enlarge

इसलिए जब कोई मुझे किसी संबंध के बारे में बताता है, तो मैं सिर्फ़ यह नहीं पूछता कि चीज़ें कैसे जुड़ी हैं। मैं पूछता हूँ: क्या वह संबंध बदलता है, और क्या हमें उसके इतिहास की परवाह है?

कॉन्फ़िगर करने से पहले खींचें

हमारा Steve Trucking मॉडल काम का बनता जा रहा है। हमें पता है कि कौन-से संबंध one-to-many हैं, कहाँ एक many-to-many किसी और अवधारणा को छिपाए हुए है, कौन-से संबंध वैकल्पिक हैं, और कौन-से समय के साथ बदलते हैं। और हमने अब तक एक भी Salesforce ऑब्जेक्ट नहीं बनाया। यह जानबूझकर है।

Click to enlarge

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

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

कॉन्सेप्चुअल मॉडल में संबंधों पर काम करते हुए मैं यह तय कर रहा होता हूँ:

• बिज़नेस की मुख्य एंटिटी एक-दूसरे से कैसे जुड़ी हैं।
• हर संबंध one-to-one, one-to-many या many-to-many है, अभी और समय के साथ।
• हर संबंध अनिवार्य है या वैकल्पिक।
• क्या कोई many-to-many संबंध किसी अर्थपूर्ण बिज़नेस अवधारणा को छिपाए हुए है।
• क्या संबंध समय के साथ बदलता है, और क्या हमें उसका इतिहास चाहिए।

Lookup या master-detail, जंक्शन कॉन्फ़िगरेशन, कैस्केड का व्यवहार और शेयरिंग फ़िज़िकल फ़ैसले हैं; हम वहाँ पहुँचेंगे। अभी हम उससे ज़्यादा अहम सवाल का जवाब दे रहे हैं: यह बिज़नेस असल में चलता कैसे है? एक बार जब हम एंटिटी और उनके बीच के संबंध समझ लेते हैं, तो उनका वर्णन करने वाले ब्योरे जोड़ना शुरू कर सकते हैं। तभी हमारा कॉन्सेप्चुअल मॉडल एक लॉजिकल (तार्किक) डेटा मॉडल बनने लगता है।