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