विचाराधीन कारोबारी माहौल के आपके विवरण के अनुसार, एक सुपर- टाइप -सबटाइप संरचना मौजूद है जो आइटम को सम्मिलित करती है - सुपर- टाइप - और इसके प्रत्येक श्रेणियाँ , कार , नाव और विमान (दो और के साथ जो ज्ञात नहीं थे) - उपप्रकारों-।
मैं इस तरह के परिदृश्य का प्रबंधन करने के लिए निम्नलिखित विधि का विस्तार करूंगा।
व्यापार नियम
प्रासंगिक वैचारिक स्कीमा का परिसीमन शुरू करने के लिए , अब तक निर्धारित किए गए कुछ सबसे महत्वपूर्ण व्यावसायिक नियम ( केवल तीन श्रेणियों के लिए विश्लेषण को प्रतिबंधित करना , चीजों को यथासंभव संक्षिप्त रखना) निम्नानुसार तैयार किए जा सकते हैं:
- एक उपयोगकर्ता शून्य-एक-या-कई आइटम का मालिक है
- एक आइटम एक विशिष्ट त्वरित पर ठीक एक उपयोगकर्ता के स्वामित्व में है
- एक आइटम समय-समय पर अलग - अलग बिंदुओं पर एक से कई उपयोगकर्ताओं के स्वामित्व में हो सकता है
- एक आइटम को ठीक एक श्रेणी में वर्गीकृत किया गया है
- एक आइटम हर समय है,
- या तो एक कार
- या एक नाव
- या एक विमान
चित्रण IDEF1X आरेख
चित्र 1 IDEF1X 1 आरेख प्रदर्शित करता है जिसे मैंने पिछले योगों के साथ-साथ अन्य व्यावसायिक नियमों के समूह के लिए बनाया था जो कि प्रासंगिक हैं:
महाप्रकार
एक ओर, मद , महाप्रकार, उपहार गुण † या विशेषताओं है कि करने के लिए सभी आम हैं श्रेणियाँ , यानी,
- CategoryCode- एक विदेशी कुंजी (FK) के रूप में निर्दिष्ट किया गया है, जो श्रेणी.CategoryCode और उप-प्रकार भेदभाव के रूप में कार्य करता है , अर्थात, यह उप-प्रकार की सटीक श्रेणी को इंगित करता है जिसके साथ किसी दिए गए आइटम को कनेक्ट किया जाना चाहिए-,
- OwnerId- एक FK के रूप में प्रतिष्ठित है जो User.UserId को इंगित करता है , लेकिन मैंने इसे एक भूमिका नाम 2 दिया है ताकि इसके विशेष निहितार्थों को और अधिक सटीक रूप से दर्शाया जा सके-
- फू ,
- बार ,
- बाज और
- बनाया गया डेटाइम ।
उप प्रकार
दूसरी ओर, गुण per जो प्रत्येक विशेष श्रेणी से संबंधित हैं , अर्थात
- Qux और Corge ;
- अंगूर , गरारे और प्लुग ;
- Xyzzy , गिरना , Wibble और Flob ;
इसी उपप्रकार बॉक्स में दिखाए जाते हैं।
पहचानकर्ता
फिर, Item.ItemId प्राथमिक कुंजी (PK) ने अलग-अलग भूमिका नामों के साथ उपप्रकारों के लिए 3 माइग्रेट किया है , अर्थात
पारस्परिक रूप से अनन्य संघों
जैसा कि दर्शाया गया है, प्रत्येक सुपरर्टाइप घटना और (बी) इसके पूरक उपप्रकार उदाहरण के बीच एक-से-एक (1: 1) कार्डिनैलिटी का संबंध या संबंध है ।
विशेष उप-प्रकार प्रतीक तथ्य यह है कि उप-प्रकारों परस्पर अनन्य हैं, यानी चित्रण है, एक ठोस मद घटना केवल एक ही उप-प्रकार उदाहरण के पूरक जा सकता है: या तो एक कार , या एक विमान , या एक नाव (दो या अधिक से कभी नहीं)।
Employed , place मैंने कुछ प्रकार की एंटिटी प्रॉपर्टीज़ को राइट करने के लिए क्लासिक प्लेसहोल्डर नामों को नियोजित किया, क्योंकि प्रश्न में उनकी वास्तविक संप्रदायों की आपूर्ति नहीं की गई थी।
एक्सपोजिटरी तार्किक-स्तरीय लेआउट
नतीजतन, एक एक्सपोज़रिटरी लॉजिकल डिज़ाइन पर चर्चा करने के लिए, मैंने निम्नलिखित एसईएफ-डीडीएल बयानों को आईडीईएफ 1 एक्स आरेख के आधार पर प्रदर्शित किया है और ऊपर वर्णित है:
-- You should determine which are the most fitting
-- data types and sizes for all your table columns
-- depending on your business context characteristics.
-- Also, you should make accurate tests to define the
-- most convenient INDEX strategies based on the exact
-- data manipulation tendencies of your business context.
-- As one would expect, you are free to utilize
-- your preferred (or required) naming conventions.
CREATE TABLE UserProfile (
UserId INT NOT NULL,
FirstName CHAR(30) NOT NULL,
LastName CHAR(30) NOT NULL,
BirthDate DATE NOT NULL,
GenderCode CHAR(3) NOT NULL,
Username CHAR(20) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT UserProfile_PK PRIMARY KEY (UserId),
CONSTRAINT UserProfile_AK1 UNIQUE ( -- Composite ALTERNATE KEY.
FirstName,
LastName,
GenderCode,
BirthDate
),
CONSTRAINT UserProfile_AK2 UNIQUE (Username) -- ALTERNATE KEY.
);
CREATE TABLE Category (
CategoryCode CHAR(1) NOT NULL, -- Meant to contain meaningful, short and stable values, e.g.; 'C' for 'Car'; 'B' for 'Boat'; 'P' for 'Plane'.
Name CHAR(30) NOT NULL,
--
CONSTRAINT Category_PK PRIMARY KEY (CategoryCode),
CONSTRAINT Category_AK UNIQUE (Name) -- ALTERNATE KEY.
);
CREATE TABLE Item ( -- Stands for the supertype.
ItemId INT NOT NULL,
OwnerId INT NOT NULL,
CategoryCode CHAR(1) NOT NULL, -- Denotes the subtype discriminator.
Foo CHAR(30) NOT NULL,
Bar CHAR(30) NOT NULL,
Baz CHAR(30) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Item_PK PRIMARY KEY (ItemId),
CONSTRAINT Item_to_Category_FK FOREIGN KEY (CategoryCode)
REFERENCES Category (CategoryCode),
CONSTRAINT Item_to_User_FK FOREIGN KEY (OwnerId)
REFERENCES UserProfile (UserId)
);
CREATE TABLE Car ( -- Represents one of the subtypes.
CarId INT NOT NULL, -- Must be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
Qux CHAR(30) NOT NULL,
Corge CHAR(30) NOT NULL,
--
CONSTRAINT Car_PK PRIMARY KEY (CarId),
CONSTRAINT Car_to_Item_FK FOREIGN KEY (CarId)
REFERENCES Item (ItemId)
);
CREATE TABLE Boat ( -- Stands for one of the subtypes.
BoatId INT NOT NULL, -- Must be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
Grault CHAR(30) NOT NULL,
Garply CHAR(30) NOT NULL,
Plugh CHAR(30) NOT NULL,
--
CONSTRAINT Boat_PK PRIMARY KEY (BoatId),
CONSTRAINT Boat_to_Item_FK FOREIGN KEY (BoatId)
REFERENCES Item (ItemId)
);
CREATE TABLE Plane ( -- Denotes one of the subtypes.
PlaneId INT NOT NULL, -- Must be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
Xyzzy CHAR(30) NOT NULL,
Thud CHAR(30) NOT NULL,
Wibble CHAR(30) NOT NULL,
Flob CHAR(30) NOT NULL,
--
CONSTRAINT Plane_PK PRIMARY KEY (PlaneId),
CONSTRAINT Plane_to_Item_PK FOREIGN KEY (PlaneId)
REFERENCES Item (ItemId)
);
जैसा कि प्रदर्शित किया गया है, सुपर बेसिटी प्रकार और उप-प्रकार के प्रत्येक को संबंधित बेस टेबल द्वारा दर्शाया गया है ।
स्तंभ CarId, BoatIdऔर PlaneId, उपयुक्त तालिकाओं के PKs के रूप में विवश, FK के माध्यम से वैचारिक स्तर के एक-से-एक संघ का प्रतिनिधित्व करने में मदद करते हैं §ItemId स्तंभ की ओर इशारा करते हैं , जो Itemतालिका के PK के रूप में विवश है । यह दर्शाता है कि, एक वास्तविक "जोड़ी" में, सुपरपेप और उपप्रकार दोनों पंक्तियों को एक ही पीके मान द्वारा पहचाना जाता है; इस प्रकार, यह उल्लेख करने के लिए अवसर से अधिक है
- (क) एक संलग्न अतिरिक्त पकड़ प्रणाली नियंत्रित सरोगेट मूल्यों के लिए स्तंभ ‖ (ख) टेबल उपप्रकार के लिए खड़े करने के लिए (ग) है पूरी तरह से ज़रूरत से ज़्यादा ।
§ आदेश समस्याओं और त्रुटियों के विषय में (विशेष रूप से विदेशी) प्रमुख बाधा परिभाषाओं -situation आप टिप्पणियां- में निर्दिष्ट रोकने के लिए, यह बहुत महत्वपूर्ण है को ध्यान में रखना है अस्तित्व-निर्भरता कि हाथ में अलग-अलग तालिकाओं के बीच जगह लेता है, के रूप में में एक उदाहरण प्रस्तुत किया एक्सप्लोजिट डीडीएल संरचना में तालिकाओं की घोषणा के आदेश, जो मैंने इस एसक्यूएल फिडेल में भी आपूर्ति की थी ।
‖ जैसे, MySQL पर निर्मित डेटाबेस की एक तालिका में AUTO_INCREMENT संपत्ति के साथ एक अतिरिक्त कॉलम को जोड़ना ।
अखंडता और स्थिरता विचार
यह इंगित करना महत्वपूर्ण है कि, आपके व्यावसायिक वातावरण में, आपको (1) यह सुनिश्चित करना होगा कि प्रत्येक "सुपरपाइप" पंक्ति हर समय अपने संबंधित "उपप्रकार" समकक्ष द्वारा पूरक हो, और, बदले में (2) गारंटी जो कहे "सुपरस्क्रिप्ट" पंक्ति के "विभेदक" कॉलम में निहित मूल्य के साथ "सबटाइप" पंक्ति संगत है।
ऐसी परिस्थितियों को घोषणात्मक तरीके से लागू करना बहुत ही सुरुचिपूर्ण होगा लेकिन, दुर्भाग्य से, प्रमुख SQL प्लेटफार्मों में से किसी ने भी ऐसा करने के लिए उचित तंत्र प्रदान नहीं किया है, जहाँ तक मुझे पता है। इसलिए, ACID लेन-देन के भीतर प्रक्रियात्मक कोड का सहारा लेना काफी सुविधाजनक है, ताकि ये परिस्थितियाँ आपके डेटाबेस में हमेशा मिलें। अन्य विकल्प TRIGGERS को नियोजित करेंगे, लेकिन वे चीजों को बेकार कर देते हैं, इसलिए बोलने के लिए।
उपयोगी विचारों की घोषणा
ऊपर बताए गए की तरह एक तार्किक डिजाइन होने के नाते, यह एक या एक से अधिक दृश्य बनाने के लिए बहुत व्यावहारिक होगा, अर्थात, व्युत्पन्न टेबल जिसमें स्तंभ शामिल होते हैं जो संबंधित बेस टेबल के दो या अधिक से अधिक होते हैं । इस तरह, आप कर सकते हैं, उदाहरण के लिए, सीधे उन विचारों से सीधे चुनें, जब आप हर बार "संयुक्त" जानकारी प्राप्त करने के लिए सभी जोइनों को लिखने के बिना।
नमूना डेटा
इस संबंध में, हम कहते हैं कि आधार तालिका नीचे दिखाए गए नमूना डेटा के साथ "पॉपुलेटेड" हैं:
--
INSERT INTO UserProfile
(UserId, FirstName, LastName, BirthDate, GenderCode, Username, CreatedDateTime)
VALUES
(1, 'Edgar', 'Codd', '1923-08-19', 'M', 'ted.codd', CURDATE()),
(2, 'Michelangelo', 'Buonarroti', '1475-03-06', 'M', 'michelangelo', CURDATE()),
(3, 'Diego', 'Velázquez', '1599-06-06', 'M', 'd.velazquez', CURDATE());
INSERT INTO Category
(CategoryCode, Name)
VALUES
('C', 'Car'), ('B', 'Boat'), ('P', 'Plane');
-- 1. ‘Full’ Car INSERTion
-- 1.1
INSERT INTO Item
(ItemId, OwnerId, CategoryCode, Foo, Bar, Baz, CreatedDateTime)
VALUES
(1, 1, 'C', 'This datum', 'That datum', 'Other datum', CURDATE());
-- 1.2
INSERT INTO Car
(CarId, Qux, Corge)
VALUES
(1, 'Fantastic Car', 'Powerful engine pre-update!');
-- 2. ‘Full’ Boat INSERTion
-- 2.1
INSERT INTO Item
(ItemId, OwnerId, CategoryCode, Foo, Bar, Baz, CreatedDateTime)
VALUES
(2, 2, 'B', 'This datum', 'That datum', 'Other datum', CURDATE());
-- 2.2
INSERT INTO Boat
(BoatId, Grault, Garply, Plugh)
VALUES
(2, 'Excellent boat', 'Use it to sail', 'Everyday!');
-- 3 ‘Full’ Plane INSERTion
-- 3.1
INSERT INTO Item
(ItemId, OwnerId, CategoryCode, Foo, Bar, Baz, CreatedDateTime)
VALUES
(3, 3, 'P', 'This datum', 'That datum', 'Other datum', CURDATE());
-- 3.2
INSERT INTO Plane
(PlaneId, Xyzzy, Thud, Wibble, Flob)
VALUES
(3, 'Extraordinary plane', 'Traverses the sky', 'Free', 'Like a bird!');
--
फिर, एक लाभप्रद दृश्य वह है जो स्तंभों को इकट्ठा करता है Item, Carऔर UserProfile:
--
CREATE VIEW CarAndOwner AS
SELECT C.CarId,
I.Foo,
I.Bar,
I.Baz,
C.Qux,
C.Corge,
U.FirstName AS OwnerFirstName,
U.LastName AS OwnerLastName
FROM Item I
JOIN Car C
ON C.CarId = I.ItemId
JOIN UserProfile U
ON U.UserId = I.OwnerId;
--
स्वाभाविक रूप से, एक समान दृष्टिकोण का पालन किया जा सकता है ताकि आप "पूर्ण" का चयन कर सकें Boatऔर एक ही तालिका (एक व्युत्पन्न एक, इन मामलों में) Planeसे सीधे जानकारी प्राप्त कर सकें ।
कि आप -यदि निम्नलिखित दृश्य परिभाषा के साथ परिणाम sets- में शून्य के निशान की उपस्थिति के बारे में कोई आपत्ति नहीं है के बाद, आप कर सकते हैं, जैसे, "इकट्ठा" टेबल से कॉलम Item, Car, Boat, Planeऔर UserProfile:
--
CREATE VIEW FullItemAndOwner AS
SELECT I.ItemId,
I.Foo, -- Common to all Categories.
I.Bar, -- Common to all Categories.
I.Baz, -- Common to all Categories.
IC.Name AS Category,
C.Qux, -- Applies to Cars only.
C.Corge, -- Applies to Cars only.
--
B.Grault, -- Applies to Boats only.
B.Garply, -- Applies to Boats only.
B.Plugh, -- Applies to Boats only.
--
P.Xyzzy, -- Applies to Planes only.
P.Thud, -- Applies to Planes only.
P.Wibble, -- Applies to Planes only.
P.Flob, -- Applies to Planes only.
U.FirstName AS OwnerFirstName,
U.LastName AS OwnerLastName
FROM Item I
JOIN Category IC
ON I.CategoryCode = IC.CategoryCode
LEFT JOIN Car C
ON C.CarId = I.ItemId
LEFT JOIN Boat B
ON B.BoatId = I.ItemId
LEFT JOIN Plane P
ON P.PlaneId = I.ItemId
JOIN UserProfile U
ON U.UserId = I.OwnerId;
--
यहां दिखाए गए विचारों का कोड केवल उदाहरण है। बेशक, कुछ परीक्षण अभ्यास और संशोधन करने से प्रश्नों पर (भौतिक) निष्पादन में तेजी लाने में मदद मिल सकती है। इसके अलावा, आपको उक्त विचारों को हटाने या कॉलम जोड़ने की आवश्यकता हो सकती है क्योंकि व्यवसाय को निर्देश की आवश्यकता होती है।
नमूना डेटा और सभी दृश्य परिभाषाओं को इस एसक्यूएल फिडेल में शामिल किया गया है ताकि उन्हें "एक्शन" में देखा जा सके।
डेटा हेरफेर: एप्लिकेशन प्रोग्राम (ओं) कोड और स्तंभ उपनाम
एप्लिकेशन प्रोग्राम (एस) कोड का उपयोग (यदि आप "सर्वर-साइड विशिष्ट कोड" से क्या मतलब है) और स्तंभ उपनाम अन्य महत्वपूर्ण बिंदु हैं जो आप अगली टिप्पणियों में लाए हैं:
मैंने सर्वर-साइड विशिष्ट कोड के साथ [एक जॉइन] समस्या को हल करने का प्रबंधन किया, लेकिन मैं वास्तव में ऐसा नहीं करना चाहता हूं -और- सभी कॉलमों में उपनाम जोड़ना "तनावपूर्ण" हो सकता है।
बहुत अच्छी तरह से समझाया, बहुत-बहुत धन्यवाद। हालाँकि, जैसा कि मुझे संदेह था, मुझे कुछ कॉलम के समान होने के कारण सभी डेटा को सूचीबद्ध करते समय परिणाम सेट में हेरफेर करना होगा, क्योंकि मैं बयान को साफ रखने के लिए कई उपनामों का उपयोग नहीं करना चाहता।
यह इंगित करने के लिए उपयुक्त है कि एप्लिकेशन प्रोग्राम कोड का उपयोग करते समय परिणाम सेट की प्रस्तुति (या चित्रमय) सुविधाओं को संभालने के लिए एक बहुत ही उपयुक्त संसाधन है, निष्पादन गति के मुद्दों को रोकने के लिए पंक्ति-दर-पंक्ति आधार पर डेटा पुनर्प्राप्ति से बचना सर्वोपरि है। इसका उद्देश्य SQL मंच के (ठीक) सेट इंजन द्वारा प्रदान किए गए मजबूत डेटा हेरफेर साधनों के माध्यम से टोटको में उचित डेटा सेट को "लाना" होना चाहिए ताकि आप अपने सिस्टम के व्यवहार को अनुकूलित कर सकें।
इसके अलावा, एक निश्चित दायरे में एक या एक से अधिक स्तंभों का नाम बदलने के लिए उपनामों का उपयोग करना तनावपूर्ण हो सकता है, लेकिन व्यक्तिगत रूप से, मैं ऐसे संसाधन को एक बहुत शक्तिशाली उपकरण के रूप में देखता हूं जो (i) को प्रासंगिक बनाने में मदद करता है और (ii) संबंधित को बताए गए अर्थ और इरादे को अस्वीकार करता है। कॉलम; इसलिए, यह एक पहलू है जिसे ब्याज के डेटा के हेरफेर के संबंध में पूरी तरह से विचार किया जाना चाहिए।
इसी तरह के परिदृश्य
साथ ही आप मदद की मिल सकती है पदों की इस श्रृंखला और पदों के इस समूह के जो दो अन्य मामलों है कि पारस्परिक रूप से विशिष्ट उपप्रकार साथ महाप्रकार-उप प्रकार संघों में शामिल हैं पर मेरी ले होते हैं।
मैंने एक व्यावसायिक वातावरण के लिए एक समाधान का प्रस्ताव भी किया है जिसमें एक सुपर-टाइप-उपप्रकार क्लस्टर शामिल है जहाँ उपप्रकार इस (नए) उत्तर में परस्पर अनन्य नहीं हैं ।
एंडनोट्स
1 सूचना मॉडलिंग के लिए एकीकरण परिभाषा ( IDEF1X ) एक अत्यधिक अनुशंसित डेटा मॉडलिंग तकनीक है जिसेदिसंबर 1993 में यूएस नेशनल इंस्टीट्यूट ऑफ स्टैंडर्ड एंड टेक्नोलॉजी (NIST)द्वारा मानक के रूप में स्थापित किया गया था। यह मजबूत पर (क) सैद्धांतिक कार्यों में से कुछ ने लिखी आधारित है एकमात्र प्रवर्तक की संबंधपरक मॉडल , यानी, डॉ एफई कॉड ; डॉ। पीपी चेन द्वारा विकसित(बी) इकाई-संबंध दृश्य ; और (ग) रॉबर्ट जी ब्राउन द्वारा निर्मित लॉजिकल डाटाबेस डिजाइन तकनीक पर भी।
2 आईडीईएफ 1 एक्स में, एक भूमिका नाम एक विशिष्ट लेबल है जिसे एफके संपत्ति (या विशेषता) को सौंपा गया है ताकि अर्थ यह व्यक्त किया जा सके कि यह अपने संबंधित इकाई प्रकार के दायरे में है।
3 IDEF1X मानक प्रमुख प्रवासन को "एक बच्चे के रूप में अपने बच्चे या श्रेणी की इकाई में एक मूल या जेनेरिक इकाई की प्राथमिक कुंजी रखने की मॉडलिंग प्रक्रिया" एक विदेशी कुंजी के रूप मेंपरिभाषित करता है।
Itemतालिका में एकCategoryCodeकॉलम शामिल है । जैसा कि "अखंडता और स्थिरता विचार" शीर्षक वाले खंड में वर्णित है: