संपूर्ण संबंध समस्या

Question

मेरे पास इस तरह से संबंधित 4 टेबल हैं (यह एक उदाहरण है):

Company:
ID
Name
CNPJ

Department:
ID
Name
Code
ID_Company 

Classification:
ID
Name
Code
ID_Company

Workers:
Id 
Name
Code
ID_Classification
ID_Department

मान लीजिए कि मेरे पास एक classificationहै id = 20, id_company = 1। और एक है departmentकि id_company = 2(किसी अन्य कंपनी का प्रतिनिधित्व करता है)।

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

Comments

'वर्गीकरण ’क्या है?

— जेहाद केरकी

मुझे लगता classificationहै कि स्थिति अर्थात सचिव, चौकीदार, अधिपति आदि के अनुरूप है

— एरिक

क्या आप इस बात को लागू करना चाहते हैं कि एक कार्यकर्ता को उसी विभाग से संबंधित होना चाहिए जो वर्गीकरण करता है?

— लेनार्ट

शायद विभागों, वर्गीकरण (और यहां तक ​​कि कार्यकर्ता) को सभी कंपनियों के आधार पर कमजोर संस्थाओं के रूप में देखा जाना चाहिए। तब कंपनी की कुंजी विभागों, वर्गीकरण और कार्यकर्ता की कुंजी का हिस्सा होगी। एक कमजोर इकाई एक इकाई जिसका अस्तित्व किसी अन्य संस्था के अस्तित्व पर निर्भर है।

— चमत्कार 173

Answer 1

आपका मुद्दा इस तथ्य से उपजा है कि आपके मॉडल से एक इकाई प्रकार गायब है। निम्नलिखित ERD पर विचार करें:

ध्यान दें कि मैंने एक प्रतिच्छेदन इकाई प्रकार के बीच जोड़ा है DEPARTMENTऔर CLASSIFICATION। यह नया निकाय प्रकार: POSITIONआपके मॉडल में निहित जानकारी को प्रदान करता है, एक विशेष विभाग के पास विभिन्न वर्गीकरणों की नौकरियों का एक सेट है।

POSITIONएक स्पष्ट इकाई के रूप में अपने मॉडल को जोड़ने के कुछ फायदे हैं।

1. यह उस समस्या से बचता है जो आप WORKERसंभावित रूप से विभिन्न कंपनियों में विभागों और वर्गीकरण को सौंपे जाने से चिंतित हैं ।
2. यह आपको अन्य विधेय के लिए एक स्थान देता है जो किसी पद पर लागू हो सकता है, जैसे वेतन ग्रेड, आदि।
3. यह आपको इस तथ्य को रिकॉर्ड करने की अनुमति देता है कि कोई स्थिति मौजूद है, भले ही WORKERवर्तमान में कोई एस नहीं है , जो संभवतः उपयोगी जानकारी है।

ध्यान दें कि एक विभाग के लिए परिभाषित की जा रही स्थिति की समस्या से बचने के लिए और एक वर्गीकरण जो विभिन्न कंपनियों में हैं, मैंने दोनों की कुंजियों का विस्तार किया है DEPARTMENTऔर CLASSIFICATIONयह उन कारणों के लिए अच्छा है जो आप टोड एवरेट के उत्तर में लंबाई के बारे में पढ़ सकते हैं।

BEWARE ऊपर का मॉडल एक सरलीकरण मानता है। विशेष रूप से, यह मानता है कि प्रत्येक स्थिति केवल एक बार दर्ज की जाती है। यह आपके व्यावसायिक नियमों के अनुकूल हो भी सकता है और नहीं भी। यदि आपको POSITIONकिसी कंपनी के भीतर एक ही विभाग और वर्गीकरण के लिए कई रिकॉर्ड की आवश्यकता है, तो आप एक सरोगेट कुंजी प्रस्तुत कर सकते हैं POSITION।

Answer 2

मुझे नहीं लगता कि आपको रिश्तों में कोई समस्या है। मुझे लगता है कि इसके बजाय समस्या यह है कि प्रत्येक तालिका के लिए सरोगेट कुंजी (यानी Ids) का उपयोग करके परिणामस्वरूप डेटाबेस उन श्रमिकों को सम्मिलित करने से रोकने में असमर्थ है जिनके विभाग एक कंपनी के हैं जबकि वर्गीकरण दूसरे का है और इसके विपरीत। इसे समझने का एक अच्छा तरीका ईआर डायग्रामिंग टूल का उपयोग करके स्कीमा की कल्पना करना है। मैं Oracle डेटा मॉडलर टूल का उपयोग करूंगा जो एक मुफ्त डाउनलोड है।

ईआर डायग्राम

जैसा कि यह खड़ा है, आपके पास 2 कंपनियां हो सकती हैं - कहते हैं IBMऔर Microsoft। IBMएक Software Developmentविभाग हो सकता है , और Microsoft का एक Desktop Softwareविभाग हो सकता है । IBM का Software Engineerवर्गीकरण हो सकता है, और Microsoft का Software Developerवर्गीकरण हो सकता है। अब, क्योंकि आपके पास सरोगेट कुंजी है Departmentऔर Classificationतथ्य यह Software Developmentहै कि एक IBMविभाग है और भविष्य के बाल संबंधों के लिए Desktop Softwareएक Microsoftविभाग खो गया है। यही हाल इनका भी है Classification। इसलिए गलती से असाइन करना आसान है Harlan Mills, जो विभाग IBMमें एक कर्मचारी Software Developmentहै, Software Developerजिसका एक वर्गीकरण एक हैMicrosoftवर्गीकरण! इसी तरह, कार्यकर्ता को सही वर्गीकरण और गलत विभाग दिया जा सकता है! यहाँ एक आरेख है जो पहला उदाहरण दिखा रहा है:

1 Ids प्रतिनिधित्व करते हैं IBM, और 2 Ids प्रतिनिधित्व करते हैं Microsoft। मैं लाल परिदृश्य में प्रकाश डाला गया है जहां Harlan Millsऔर Bill Gatesगलत विभागों, जो 10 विभाग 200 वर्गीकरण ईद और इसके विपरीत करने के लिए जुड़े ईद द्वारा कल्पना है को सौंपा है।

हल करने के लिए विकल्प

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

दूसरा विकल्प है कि हर टेबल के लिए सरोगेट कीज का इस्तेमाल न किया जाए । इसके बजाय, केवल के लिए किराए की कुंजी का उपयोग Companyतालिका, जो मौलिक है और कोई माता-पिता है, और फिर बनाने की पहचान करने के लिए रिश्तों को Departmentऔर Classificationबच्चे टेबल। Departmentऔर Classificationतालिकाओं अब की एक पी है Company Idके साथ साथ एक अनुक्रम संख्या या नाम उन्हें अलग करने के लिए। फिर, से रिश्ते Departmentऔर Classificationकरने के लिए Workerभी हो जाते हैं identifyingऔर इस तरह के पी Workerहो जाता है Company Id, के साथ साथ Department Number(मैं इस उदाहरण में एक क्रम संख्या का उपयोग कर रहा), के साथ साथ Classification Number। परिणाम वहाँ केवल है one Company Idमें Workerमेज। अब ए को असाइन करना असंभव हैWorkerएक करने के लिए Departmentएक में Companyऔर एक को Classificationदूसरे में Company।

यह असंभव क्यों है? यह असंभव है क्योंकि स्कीमा Workerऔर के बीच संदर्भात्मक अखंडता को लागू करता है Departmentऔर Classification। एक प्रयास एक डालने के लिए किया जाता है Workerएक के लिए Departmentएक में Companyऔर एक और Classificationएक और की, संयोजन है कि इसी माता पिता तालिका में मौजूद नहीं है एक रेफेरेंन्शिअल सत्यनिष्ठा उल्लंघन को गति प्रदान और डालने से काम नहीं चलेगा होगा।

यहाँ दूसरे विकल्प के कार्यान्वयन का एक अद्यतन आरेख है:

पसंदीदा विकल्प

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

यह एक महान प्रश्न है क्योंकि यह बिल्कुल दिखाता है कि क्यों हर तालिका को संभालने के लिए एक सरोगेट कुंजी की आवश्यकता होती है एक बुरा विचार है। फैबियन पास्कल के पास इस विषय पर एक उत्कृष्ट ब्लॉग पोस्ट है जिसमें दिखाया गया है कि न केवल एक सरोगेट कुंजी डेटा अखंडता के दृष्टिकोण से एक बुरा विचार हो सकती है, इसके परिणामस्वरूप कुछ पुनर्प्राप्ति धीमी हो सकती है।शारीरिक स्तर पर ठीक-ठाक होने के कारण जॉइन की आवश्यकता होती है, चाबी ठीक से कैस्केड की गई थी, अनावश्यक होगी। एक और दिलचस्प विषय यह प्रश्न बताता है कि एक डेटाबेस यह सुनिश्चित नहीं कर सकता है कि इसमें डाला गया सभी डेटा वास्तविक दुनिया के संबंध में सटीक है। इसके बजाय, यह केवल यह सुनिश्चित कर सकता है कि इसमें डाला गया डेटा उसके द्वारा घोषित नियमों के अनुरूप है। इस मामले में हम यह सुनिश्चित करने के लिए कैस्केडिंग कुंजी दृष्टिकोण का उपयोग करके सबसे अच्छा संभव कर सकते हैं कि डीबीएमएस उस नियम के संबंध में डेटा को सुसंगत रख सकता है जिसे किसी Workerदिए गए की Companyजरूरत है Classificationऔर Departmentउसी को सौंपा जाना चाहिए Company। लेकिन, अगर वास्तविक दुनिया Microsoftमें एक विभाग कहा जाता है, Desktop Softwareलेकिन डेटाबेस का उपयोगकर्ता विभाग के बजाय जोर देता हैSoftware Development DBMS कुछ भी नहीं कर सकता है, लेकिन मान लें कि यह एक सही तथ्य दिया गया है।

Answer 3

जिस तरह से मैं इस प्रश्न को समझता हूं, 'वर्कर्स टेबल' का ID_Classification फ़ील्ड केवल संबंधित कार्यकर्ता की कंपनी के लिए परिभाषित वर्गीकरणों को अनुमति देना चाहिए। इसलिए, सत्यापन (एक RULE या TRIGGERS के माध्यम से संलग्न करके) इस आवश्यकता को संबोधित करने के लिए श्रमिक /ID_Classification फ़ील्ड में डाली गई / अपडेट की गई जानकारी पर्याप्त है।

Answer 4

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

यदि आप किसी कंपनी में वर्गीकरण / स्थिति को आसानी से खोजने के लिए ऐसा कर रहे हैं, तो कृपया वर्गीकरण-श्रमिकों-विभागों को जोड़ने और वर्गीकरण की कंपनी आईडी को पुनः प्राप्त करने के लिए एक सरल क्वेरी / दृश्य जोड़ें ।

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