क्या यह ईआर आरेख इसके बजाय एक त्रिगुट संबंध का उपयोग करना चाहिए

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

यह उन तीन संस्थाओं पर कई बोधगम्य संबंधों में से एक है।

हाँ ऐसा होता है। लेकिन इन आरेख बाइनरी संबंधों के संदर्भ में टर्नरी संबंध व्यक्त किया जा सकता है। (और इसके विपरीत नहीं।)

प्रत्येक तालिका - आधार चर या क्वेरी परिणाम - कुछ विशेष संबंधों में भाग लेने वाली पंक्तियों को रखता है। हम रिश्ते को एक predicate द्वारा चिह्नित कर सकते हैं। --ए स्टेटमेंट टेम्प्लेट एट्रिब्यूट्स द्वारा पैरामीटर किया गया।

एक तालिका उन पंक्तियों को रखती है जिनके गुणों के लिए मूल्य इसके विधेय से एक सही बयान देता है। आधार चर का विधेय DBA द्वारा दिया जाता है।

-- shipped item ItemNumber is received by retail center UniqueId
SELECT * FROM ReceivedFrom
-- shipped item ItemNumber takes transportation event ScheduleNumber
SELECT * FROM ShippedVia

एक क्वेरी एक्सप्रेशन का विधेय उसके ऑपरेटरों और तर्कों से बनाया गया है। उदाहरण के लिए, दो तालिकाओं के प्राकृतिक जॉइन का विधेय AND तालिकाओं का विधेय है।

-- shipped item ItemNumber is received by retail center UniqueId
       and takes transportation event ScheduleNumber
SELECT * FROM ReceivedFrom NATURAL JOIN ShippedVia

बेशक, टर्नरी रिलेशनशिप की आपकी विशेष अवधारणा यह सटीक क्वेरी/टेबल नहीं हो सकती है। लेकिन एक व्यावहारिक UPS डेटाबेस में मूलभूत संबंधों के लिए तालिकाएँ होंगी जिनके संदर्भ में किसी भी प्रासंगिक संबंध को व्यक्त किया जा सकता है।

(सामान्यीकरण "... और ..." फॉर्म की भविष्यवाणी को "..." के लिए अलग-अलग भविष्यवाणियों में विभाजित करता है जब यह संभव और सहायक होता है; मूल तालिका घटकों के जॉइन द्वारा वापस दी जाती है।)