परिवर्तनशील तालिका में परिवर्तनशील इकाई को परिवर्तित करने का तरीका न जानें

Question

परिचय और विस्तृत जानकारी:

निम्नलिखित उदाहरण मेरे सामने आई समस्या का चित्रण करता है:

जानवरों की एक दौड़ है, जो एक बिल्ली या एक कुत्ता हो सकता है । बिल्ली या तो स्याम देश या फ़ारसी हो सकती है । कुत्ता एक जर्मन शेफर्ड या लैब्राडोर रिट्रीवर हो सकता है ।

पशु एक मजबूत इकाई है, जबकि इसकी दौड़ एक विशेषता है जो दो प्रस्तावित मूल्यों (बिल्ली या एक कुत्ता) में से एक हो सकती है। ये दोनों मूल्य जटिल हैं (मैंने समस्या को स्पष्ट करने के लिए केवल कुत्ते / बिल्ली के प्रकार को यहां जोड़ा है, लेकिन बिल्ली का / कुत्ते का नाम और अन्य सामान का गुच्छा भी हो सकता है)।

मुसीबत:

मैं नहीं जानता कि इस उदाहरण के लिए संबंधपरक तालिकाओं का निर्माण कैसे करें।

समस्या हल करने के लिए मेरा प्रभाव:

मैंने चेन के अंकन का उपयोग करते हुए ईआर आरेख को खींचने की कोशिश की है, जो समस्या का प्रतिनिधित्व करता है लेकिन एक शुरुआत होने के नाते मुझे नहीं पता कि क्या मैंने इसे सही किया। यहाँ मुझे क्या मिला है:

मैं माफी मांगता हूं अगर मैंने कुछ गलत किया है, तो कृपया मुझे सही करें अगर ऐसा है तो। मैं केवल "नि: शुल्क समाधान" प्राप्त करना नहीं चाहता हूं, बल्कि यह भी जानना चाहता हूं कि इस समस्या से कैसे निपटें ताकि मैं इसे भविष्य में अपने दम पर हल कर सकूं।

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

Animal< # Animal_ID, race, other attributes >
Cat < # Cat_ID, $ Animal_ID, breed >
Dog < # Dog_ID, $ Animal_ID, breed >

मुझे वास्तव में मेरे समाधान के बारे में बुरा लग रहा है और मुझे डर है कि यह गलत है, इसलिए नीचे का प्रश्न।

प्रशन:

• मैं अपने उदाहरण को ईआर आरेख में कैसे बदल सकता हूं?
• कैसे उस ईआर आरेख को संबंधपरक तालिकाओं में बदलना है?

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

धन्यवाद।

Comments

TERTeorey, D.Yang, JPFry: 1986 से विस्तारित पेपर -रिलेशनशिप मॉडल का उपयोग करके तार्किक डेटाबेस के लिए एक तार्किक डिजाइन पद्धति । यह सीधा है और मेरे पसंदीदा पत्रों में से एक है।

— चमत्कार 173

Answer 1

इस परिदृश्य के लिए उचित संरचना सबक्लास / इनहेरिटेंस मॉडल है, और इस उत्तर में प्रस्तावित अवधारणा के लगभग समान है: विषम मूल्य की सूची का आदेश दिया ।

इस प्रश्न में प्रस्तावित मॉडल वास्तव में काफी करीब है Animalजिसमें इकाई में प्रकार (यानी race) और सभी प्रकार के गुण हैं। हालाँकि, दो छोटे बदलाव की जरूरत है:

1. अपनी संबंधित संस्थाओं से Cat_ID और Dog_ID फ़ील्ड निकालें:

   यहां मुख्य अवधारणा है कि है सब कुछ एक है Animal, की परवाह किए बिना race: Cat, Dog, Elephant, और इतने पर। उस शुरुआती बिंदु को देखते हुए, किसी भी विशेष raceको Animalवास्तव में एक अलग पहचानकर्ता की आवश्यकता नहीं है:

   1. Animal_IDअद्वितीय है
   2. Cat, Dog, और किसी भी अतिरिक्त raceसंस्थाओं भविष्य में जोड़ा, स्वयं ही, पूरी तरह से किसी विशेष का प्रतिनिधित्व नहीं करते हैं Animal; वे केवल, जिसका अर्थ है जब मूल इकाई में निहित जानकारी के साथ संयोजन में उपयोग किया है Animal।

   इसलिए, Animal_IDमें संपत्ति Cat, Dog, आदि संस्थाओं दोनों पी और करने के लिए वापस आ गया है FK Animalइकाई।

2. के बीच का अंतर breed:

   सिर्फ इसलिए कि दो गुणों का हिस्सा एक ही नाम नहीं है का मतलब जरूरी है कि उन गुणों ही कर रहे हैं, भले ही नाम ही किया जा रहा है का तात्पर्य एक ऐसे रिश्ते। इस मामले में, आपके पास वास्तव में क्या है CatBreedऔर DogBreedअलग प्रकार के "प्रकार" के रूप में

प्रारंभिक नोट्स

1. SQL Microsoft SQL सर्वर (यानी T-SQL) के लिए विशिष्ट है। मतलब, डेटाटाइप्स के बारे में सावधान रहें क्योंकि वे सभी आरडीबीएमएस के समान नहीं हैं। उदाहरण के लिए, मैं उपयोग कर रहा हूं VARCHARलेकिन अगर आपको मानक ASCII सेट के बाहर कुछ भी स्टोर करने की आवश्यकता है, तो आपको वास्तव में उपयोग करना चाहिए NVARCHAR।
2. "प्रकार" तालिकाओं के आईडी क्षेत्रों ( Race, CatBreed, और DogBreed) कर रहे हैं नहीं , क्योंकि वे आवेदन स्थिरांक (यानी वे आवेदन का हिस्सा हैं) है कि में स्थिर देखने मान रहे हैं ऑटो incrementing (T-SQL के मामले में यानी पहचान) डेटाबेस और enumC # (या अन्य भाषाओं) में दर्शाया गया है। यदि मान जोड़े जाते हैं, तो उन्हें नियंत्रित स्थितियों में जोड़ा जाता है। मैं एप्लिकेशन के माध्यम से आने वाले उपयोगकर्ता डेटा के लिए ऑटो-इन्क्रीमेंट फ़ील्ड का उपयोग आरक्षित करता हूं।
3. मेरे द्वारा उपयोग किया जाने वाला नामकरण सम्मेलन मुख्य वर्ग के नाम से शुरू होने वाले प्रत्येक उपवर्ग तालिका का नाम है, उपवर्ग नाम के बाद। यह तालिकाओं को व्यवस्थित करने में मदद करता है और साथ ही स्पष्ट रूप से इंगित करता है (FK को देखे बिना) मुख्य इकाई तालिका में उपवर्ग तालिका का संबंध।
4. कृपया दृश्य के संबंध में एक नोट के लिए अंत में "फाइनल एडिट" अनुभाग देखें।

"नस्ल" को "रेस" के रूप में -विशिष्ट दृष्टिकोण

तालिकाओं का यह पहला सेट लुकअप / प्रकार तालिकाएँ हैं:

CREATE TABLE Race
(
  RaceID INT NOT NULL PRIMARY KEY
  RaceName VARCHAR(50) NOT NULL
);

CREATE TABLE CatBreed
(
  CatBreedID INT NOT NULL PRIMARY KEY,
  BreedName VARCHAR(50),
  CatBreedAttribute1 INT,
  CatBreedAttribute2 VARCHAR(10)
  -- other "CatBreed"-specific properties as needed
);

CREATE TABLE DogBreed
(
  DogBreedID INT NOT NULL PRIMARY KEY,
  BreedName VARCHAR(50),
  DogBreedAttribute1 TINYINT
  -- other "DogBreed"-specific properties as needed
);

यह दूसरी सूची मुख्य "पशु" इकाई है:

CREATE TABLE Animal
(
  AnimalID INT NOT NULL IDENTITY(1, 1) PRIMARY KEY,
  RaceID INT NOT NULL, -- FK to Race
  Name VARCHAR(50)
  -- other "Animal" properties that are shared across "Race" types
);

ALTER TABLE Animal
  ADD CONSTRAINT [FK_Animal_Race]
  FOREIGN KEY (RaceID)
  REFERENCES Race (RaceID);

तालिकाओं का यह तीसरा सेट मानार्थ उप-वर्ग इकाइयाँ हैं जो प्रत्येक Raceकी परिभाषा को पूरा करती हैं Animal:

CREATE TABLE AnimalCat
(
  AnimalID INT NOT NULL PRIMARY KEY, -- FK to Animal
  CatBreedID INT NOT NULL, -- FK to CatBreed
  HairColor VARCHAR(50) NOT NULL
  -- other "Cat"-specific properties as needed
);

ALTER TABLE AnimalCat
  ADD CONSTRAINT [FK_AnimalCat_CatBreed]
  FOREIGN KEY (CatBreedID)
  REFERENCES CatBreed (CatBreedID);

ALTER TABLE AnimalCat
  ADD CONSTRAINT [FK_AnimalCat_Animal]
  FOREIGN KEY (AnimalID)
  REFERENCES Animal (AnimalID);


CREATE TABLE AnimalDog
(
  AnimalID INT NOT NULL PRIMARY KEY, -- FK to Animal
  DogBreedID INT NOT NULL, -- FK to DogBreed
  HairColor VARCHAR(50) NOT NULL
  -- other "Dog"-specific properties as needed
);

ALTER TABLE AnimalDog
  ADD CONSTRAINT [FK_AnimalDog_DogBreed]
  FOREIGN KEY (DogBreedID)
  REFERENCES DogBreed (DogBreedID);

ALTER TABLE AnimalDog
  ADD CONSTRAINT [FK_AnimalDog_Animal]
  FOREIGN KEY (AnimalID)
  REFERENCES Animal (AnimalID);

साझा breedप्रकार का उपयोग करने वाला मॉडल "अतिरिक्त नोट्स" अनुभाग के बाद दिखाया गया है।

अतिरिक्त नोट्स

1. की अवधारणा breedभ्रम के लिए एक केंद्र बिन्दु हो रहा है। यह jcolebrand (प्रश्न पर एक टिप्पणी में) द्वारा सुझाया गया था जो कि breedविभिन्न raceएस में साझा की गई संपत्ति है , और अन्य दो उत्तरों ने इसे अपने मॉडलों में इस तरह एकीकृत किया है। हालांकि, यह एक गलती है, क्योंकि breedविभिन्न मूल्यों के लिए साझा नहीं किए गए हैं race। हां, मैं इस बात से अवगत हूं कि दो अन्य प्रस्तावित मॉडल इस मुद्दे को हल करने का प्रयास करते raceहैं breed। जबकि यह तकनीकी रूप से रिश्ते के मुद्दे को हल करता है, यह गैर-सामान्य गुणों के बारे में क्या करना है, के समग्र मॉडलिंग प्रश्न को हल करने में मदद नहीं करता है, और न ही इसे कैसे संभालना raceहै breed। लेकिन, इस मामले में कि इस तरह की संपत्ति को सभी में मौजूद होने की गारंटी दी गई थीAnimals, मैं इसके लिए एक विकल्प (नीचे) भी शामिल करूंगा।
2. Vijayp और DavidN द्वारा प्रस्तावित मॉडल (जो समान प्रतीत होते हैं) इसलिए काम नहीं करते हैं:
   1. वे या तो
      1. गैर-सामान्य गुणों को संग्रहीत करने की अनुमति न दें (कम से कम किसी व्यक्ति के व्यक्तिगत उदाहरणों के लिए नहीं Animal), या
      2. आवश्यकता है कि सभी संपत्तियों के लिए सभी संपत्तियों raceको उस Animalइकाई में संग्रहीत किया जाए जो इस डेटा का प्रतिनिधित्व करने का एक बहुत ही सपाट (और लगभग गैर-संबंधपरक) तरीका है। हां, लोग ऐसा हर समय करते हैं, लेकिन इसका मतलब है कि उन विशेष गुणों के लिए प्रति पंक्ति कई NULL फ़ील्ड्स हैं raceजो उस विशेष के लिए नहीं हैं और यह जानने के लिए कि प्रति पंक्ति के कौन से फ़ील्ड raceउस रिकॉर्ड के विशेष से संबद्ध हैं ।
   2. वे एक जोड़ने के लिए अनुमति नहीं देते raceके Animalभविष्य नहीं है कि में breedएक संपत्ति के रूप में। और सभी, भले ही Animalएक है breed, कि क्या पहले से के बारे में उल्लेख किया गया है की वजह से संरचना को बदल नहीं होगा breedकि: breedपर निर्भर है race(यानी breedके लिए Catएक ही चीज़ नहीं है breedके लिए Dog)।

"नस्ल" के रूप में आम- / साझा- संपत्ति दृष्टिकोण

कृपया ध्यान दें:

1. नीचे दिए गए मॉडल के रूप में SQL को उसी डेटाबेस में चलाया जा सकता है:

   1. Raceतालिका में एक ही है
   2. Breedतालिका नया है
   3. तीन Animalतालिकाओं के साथ संलग्न किया गया है2
2. यहां तक ​​कि Breedअब एक सामान्य संपत्ति होने के बावजूद , यह Raceमुख्य / मूल इकाई में उल्लेखित नहीं है (भले ही यह तकनीकी रूप से सही हो) नहीं लगता है। तो, दोनों RaceIDऔर BreedIDमें प्रतिनिधित्व कर रहे हैं Animal2। RaceIDविख्यात के बीच एक बेमेल को रोकने के लिए Animal2और BreedIDयह एक अलग के लिए है RaceID, मैंने दोनों पर एक एफके जोड़ा है RaceID, BreedIDजो Breedतालिका में उन क्षेत्रों के एक संदर्भ को संदर्भित करता है। मैं आमतौर पर एक UNIQUE CONSTRAINT को FK की ओर इशारा करते हुए घृणा करता हूं, लेकिन ऐसा करने के लिए कुछ वैध कारणों में से एक है। UNIQUE CONSTRAINT तार्किक रूप से एक "वैकल्पिक कुंजी" है, जो इसे इस उपयोग के लिए वैध बनाती है। कृपया यह भी ध्यान दें कि Breedटेबल पर अभी भी पीके है BreedID।
   1. संयुक्त क्षेत्रों और किसी भी संकलक पर केवल एक पीके के साथ नहीं जाने का कारण यह है कि यह उसी के BreedIDलिए अलग-अलग मूल्यों को दोहराया जाएगा RaceID।
   2. स्विच करने का कारण जो कि PK और UNIQUE CONSTRAINT के आसपास नहीं है, यह केवल इसका उपयोग नहीं हो सकता है BreedID, इसलिए यह अभी भी उपलब्ध Breedहोने के बिना एक विशिष्ट मूल्य को संदर्भित करना संभव RaceIDहै।
3. जबकि निम्नलिखित मॉडल काम करता है, इसमें एक साझा की अवधारणा के संबंध में दो संभावित खामियां Breedहैं (और यही कारण है कि मैं Race-स्पेशल Breedटेबल पसंद करता हूं )।
   1. एक निहित धारणा है कि सभी मूल्यों में Breedसमान गुण हैं। इस मॉडल में Dog"नस्लों" और Elephant"नस्लों" के बीच असमान गुण होने का कोई आसान तरीका नहीं है । हालांकि, अभी भी ऐसा करने का एक तरीका है, जिसे "फाइनल एडिट" सेक्शन में नोट किया गया है।
   2. एक Breedसे अधिक दौड़ को साझा करने का कोई तरीका नहीं है । मुझे यकीन नहीं है कि अगर ऐसा करना वांछनीय है (या शायद जानवरों की अवधारणा में नहीं, लेकिन संभवतः अन्य स्थितियों में जो इस प्रकार के मॉडल का उपयोग कर रहे हैं), लेकिन यह यहां संभव नहीं है।

CREATE TABLE Race
(
  RaceID INT NOT NULL PRIMARY KEY,
  RaceName VARCHAR(50) NOT NULL
);

CREATE TABLE Breed
(
  BreedID INT NOT NULL PRIMARY KEY,
  RaceID INT NOT NULL, -- FK to Race
  BreedName VARCHAR(50)
);

ALTER TABLE Breed
  ADD CONSTRAINT [UQ_Breed]
  UNIQUE (RaceID, BreedID);

ALTER TABLE Breed
  ADD CONSTRAINT [FK_Breed_Race]
  FOREIGN KEY (RaceID)
  REFERENCES Race (RaceID);

CREATE TABLE Animal2
(
  AnimalID INT NOT NULL IDENTITY(1, 1) PRIMARY KEY,
  RaceID INT NOT NULL, -- FK to Race, FK to Breed
  BreedID INT NOT NULL, -- FK to Breed
  Name VARCHAR(50)
  -- other properties common to all "Animal" types
);

ALTER TABLE Animal2
  ADD CONSTRAINT [FK_Animal2_Race]
  FOREIGN KEY (RaceID)
  REFERENCES Race (RaceID);

-- This FK points to the UNIQUE CONSTRAINT on Breed, _not_ to the PK!
ALTER TABLE Animal2
  ADD CONSTRAINT [FK_Animal2_Breed]
  FOREIGN KEY (RaceID, BreedID)
  REFERENCES Breed (RaceID, BreedID);


CREATE TABLE AnimalCat2
(
  AnimalID INT NOT NULL PRIMARY KEY, -- FK to Animal
  HairColor VARCHAR(50) NOT NULL
);

ALTER TABLE AnimalCat2
  ADD CONSTRAINT [FK_AnimalCat2_Animal2]
  FOREIGN KEY (AnimalID)
  REFERENCES Animal2 (AnimalID);

CREATE TABLE AnimalDog2
(
  AnimalID INT NOT NULL PRIMARY KEY,
  HairColor VARCHAR(50) NOT NULL
);

ALTER TABLE AnimalDog2
  ADD CONSTRAINT [FK_AnimalDog2_Animal2]
  FOREIGN KEY (AnimalID)
  REFERENCES Animal2 (AnimalID);

अंतिम संपादन (उम्मीद है ;-)

1. प्रकारों के बीच असमान गुणों को संभालने की संभावना (और फिर कठिनाई) के संबंध में Breed, यह एक ही उपवर्ग / विरासत अवधारणा को रोजगार देना संभव है , लेकिन Breedमुख्य इकाई के रूप में। इस सेटअप में Breedतालिका में सभी प्रकार के Breed(जैसे कि Animalतालिका) के गुण सामान्य RaceIDहोंगे और Breedयह उसी प्रकार का प्रतिनिधित्व करेगा (जैसा वह Animalतालिका में करता है )। तो फिर तुम जैसे उपवर्ग तालिकाओं के लिए होता है BreedCat, BreedDog, और इतने पर। छोटी परियोजनाओं के लिए इसे "ओवर-इंजीनियरिंग" माना जा सकता है, लेकिन इसे उन स्थितियों के लिए एक विकल्प के रूप में उल्लेख किया जा रहा है, जो इससे लाभान्वित होंगी।

2. दोनों दृष्टिकोणों के लिए, यह कभी-कभी पूर्ण इकाइयों के लिए शॉर्ट-कट के रूप में दृश्य बनाने में मदद करता है। उदाहरण के लिए, विचार करें:

   CREATE VIEW Cats AS
      SELECT  an.AnimalID,
              an.RaceID,
              an.Name,
              -- other "Animal" properties that are shared across "Race" types
              cat.CatBreedID,
              cat.HairColor
              -- other "Cat"-specific properties as needed
      FROM    Animal an
      INNER JOIN  AnimalCat cat
              ON  cat.AnimalID = an.AnimalID
      -- maybe add in JOIN(s) and field(s) for "Race" and/or "Breed"
   

3. तार्किक संस्थाओं का हिस्सा नहीं होने के बावजूद, तालिकाओं में ऑडिट फ़ील्ड रखना काफी सामान्य है, जब रिकॉर्ड डाला और अपडेट किया जा रहा हो, तो कम से कम यह महसूस करें। तो व्यावहारिक रूप में:
   1. तालिका में एक CreatedDateफ़ील्ड जोड़ा जाएगा Animal। किसी भी उपवर्ग तालिकाओं (जैसे AnimalCat) में इस क्षेत्र की आवश्यकता नहीं है क्योंकि दोनों तालिकाओं के लिए डाली जा रही पंक्तियों को एक ही समय में लेनदेन के भीतर किया जाना चाहिए।
   2. एक LastModifiedDateफ़ील्ड को Animalतालिका और सभी उपवर्ग तालिकाओं में जोड़ा जाएगा । यह फ़ील्ड केवल तभी अपडेट की जाती है जब उस विशेष तालिका को अपडेट किया जाता है: यदि कोई अपडेट होता है, AnimalCatलेकिन Animalकिसी विशेष के लिए नहीं है AnimalID, तो केवल LastModifiedDateफ़ील्ड AnimalCatसेट की जाएगी।

Comments

किसी तरह मुझे वह अहसास हो जाता है जो तुम समझती हो कि मेरी समस्या क्या है। मैं आपके लिंक किए गए उत्तर को एक रूप दूंगा, और इसे ध्यान से अध्ययन करूंगा। तालिकाओं की बस एक सरल परिभाषा बहुत अच्छी होगी (यदि SQL प्रश्न आपके लिए इस समय लिखने के लिए बहुत अधिक हैं)। यदि आप अपनी पोस्ट को SQL क्वेरी या टेबल परिभाषाओं के साथ अपडेट करने का निर्णय लेते हैं, तो कृपया मुझे एक टिप्पणी छोड़ दें। फिर से धन्यवाद। सादर।

— AlwaysLearningNewStuff

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

— AlwaysLearningNewStuff

@AlwaysLearningNewStuff हाय। यह संदेश पहले ही मिल गया है, लेकिन इसे तुरंत प्राप्त करने का समय नहीं है। मैं आपके नाम के ऊपर क्लिक करके नए प्रश्न को खोजने में सक्षम था और यह आपके सभी प्रश्नों को दिखाता है :-)।

— सोलोमन रटज़की

मैं इस सवाल का जिक्र कर रहा था । संक्षेप में: मेरे पास सामान्य विशेषता के साथ 3 संस्थाएं हैं D, इसलिए मैं आपके उत्तर से विधि लागू करना चाहता था। दो संस्थाओं में सामान्य विशेषता है Eजो तीसरी इकाई में मौजूद नहीं है। क्या मुझे इस तथ्य को अनदेखा करना चाहिए और मानक समाधान लागू करना चाहिए, या क्या मेरे डिजाइन को और अधिक अनुकूलित करने का एक तरीका है?

— AlwaysLearningNewStuff 21

Answer 2

सबसे पहले, आप ईआर मॉडलिंग और संबंधपरक मॉडलिंग के बीच अंतर करने के लिए अच्छा कर रहे हैं। कई newbies नहीं है।

यहाँ कुछ buzzwords हैं जिनका उपयोग आप वेब पर उपयोगी लेख देखने के लिए कर सकते हैं।

आपका मामला वर्ग / उपवर्ग का एक क्लासिक मामला है या, यदि आप चाहें, तो टाइप / उपप्रकार।

ईआर मॉडलिंग में उपयोग किया जाने वाला वाक्यांश "सामान्यीकरण / विशेषज्ञता" है। और कई लेख इसे ईईआर (एन्हांसड एंटिटी-रिलेशनशिप) मॉडलिंग के तहत दिखाते हैं। यह ईआर मॉडलिंग की पीटर चेन की मूल प्रस्तुति में नहीं था। इसे बाद में जोड़ा गया था। पीडीएफ के रूप में जीन / कल्पना के एक बहुत अच्छे सारांश के लिए, यहां क्लिक करें

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

सिंगल टेबल इनहेरिटेंस का बड़ा फायदा सादगी है। यह सब एक तालिका में संग्रहीत है। बड़ा दोष बहुत सारे NULLS है। इससे स्थान और समय बर्बाद हो सकता है और तर्क भ्रमित हो सकता है।

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

अंत में, इस क्षेत्र में एक टैग है जो आपके जैसे प्रश्नों को एक साथ एकत्रित करता है।
यह रहा: उपप्रकार

Comments

+1 जो मुझे भ्रमित कर रहा है वह है टेबल आरेखों में प्राथमिक कुंजियों की कमी। विशेष रूप से "क्लासटेबल इनहेरिटेंस" में मैं यह नहीं देख सकता कि ये सभी टेबल एक ही प्राथमिक कुंजी द्वारा जुड़े हुए हैं।

— चमत्कार 173

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

— वाल्टर मिती

Answer 3

मैं संभव डिजाइन के रूप में देखते हैं

तालिका Race

RaceId- PK- Int
RaceName - Varchar(50)

तालिका Breed

BreedId - PK- Int
RaceId - FK - Int
BreedName - varchar(50)

तालिका Animal

AnimalId - PK- Int
BreedId - FK - Int
Other Columns....

ऊपर दिए गए ये PK ऑटो-इन्क्रिमेंटिंग कॉलम होंगे। Animalतालिका के अन्य स्तंभों को तदनुसार नाम दिया जा सकता है।

Comments

इसके अतिरिक्त, मैं जानवरों की तालिका में रेस और प्रकार (ट्रिगर हो सकता है) की कुंजी के साथ एक फ़ील्ड जोड़ूंगा ताकि बाद में अनुक्रमित करने के लिए गति में सुधार हो सके।

— फेलिप अल्केबार

Answer 4

आपकी वर्तमान पद्धति खराब नहीं है। हालांकि, यदि आप बाद में (पक्षी, मछली, आदि) अधिक दौड़ लगाने जा रहे हैं, तो प्रत्येक के लिए एक अलग तालिका बनाना बोझिल हो सकता है। मैं निम्नलिखित की तरह कुछ सुझाएगा:

Animal < # Animal_ID, Breed_ID, other attributes >
Breed < # Breed_ID, Race_ID >
Race < # Race_ID >

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