वैचारिक रूप से, हालांकि, आपके व्यावसायिक वातावरण में ऑर्डर और एड्रेस ऐसे विचार हैं जो निकटता से जुड़े हैं, वे दो अलग-अलग इकाई प्रकारों में हैं, जिनमें से प्रत्येक लागू गुणों (या विशेषताओं) और बाधाओं के अपने सेट के साथ है।
इसलिए, जैसा कि पहले टिप्पणियों में कहा गया था, मैं @ एरिक के साथ सहमत हूं , और आपको अपने डेटाबेस के तार्किक लेआउट को अन्य तत्वों के बीच घोषित करना चाहिए:
- जानकारी का पता रखने के लिए एक असतत तालिका ;
- ग्राहक- विशिष्ट विवरण को बनाए रखने के लिए एक तालिका ;
- आदेश डेटा बिंदुओं को संलग्न करने के लिए एक तालिका ; तथा
- ग्राहक (एस) और पते (एस) के बीच संघों के बारे में तथ्य शामिल करने के लिए एक तालिका ;
जैसा कि मैं नीचे अनुकरण करूँगा।
एक्सपोजिटरी IDEF1X आरेख
एक तस्वीर एक हजार शब्दों के लायक है, इसलिए मैंने अपने सुझाव से खोली गई कुछ संभावनाओं को स्पष्ट करने के लिए चित्र 1 में दिखाया गया IDEF1X चित्र बनाया :
ग्राहक , पता और उनके संघ
जैसा कि प्रदर्शित किया गया है, मैंने कई प्रकार के कई (एम: एन) कार्डिनिटी अनुपात के साथ इकाई प्रकार के ग्राहक के रूप में और पते के साथ एक सहयोग को चित्रित किया है ; यह दृष्टिकोण भविष्य में लचीलापन प्रदान करेगा, क्योंकि जैसा कि आप जानते हैं, एक ग्राहक समय के साथ, या एक साथ कई पते रख सकता है , और एक ही पते को कई ग्राहकों द्वारा साझा किया जा सकता है ।
एक विशेष पते का उपयोग कई तरीकों से एक-से-कई (1: एम) ग्राहकों द्वारा किया जा सकता है ; उदाहरण के लिए, इसे भौतिक के रूप में परिभाषित किया जा सकता है , और / या इसे शिपिंग के लिए , और / या बिलिंग के लिए सेट किया जा सकता है । शायद, एक ही पता उदाहरण एक ही समय में पूर्वोक्त उद्देश्यों में से प्रत्येक की सेवा कर सकता है, या यह दो उपयोगों को कवर कर सकता है जबकि एक अलग पता घटना शेष को कवर करती है।
एक कुछ व्यापार वातावरण में, एक ग्राहक या तो एक हो सकता है व्यक्ति या एक संगठन (स्थिति यह है कि एक से थोड़ा अलग व्यवस्था अर्थ होगा, के रूप में विस्तृत इस जवाब में एक महाप्रकार-उप-प्रकार संरचना के बारे में), लेकिन एक सरलीकृत उदाहरण प्रदान करने के उद्देश्य के साथ, मैंने तय कर लिया उस संभावना को यहां शामिल नहीं करना है। यदि आपको अपने डेटाबेस में उस स्थिति को कवर करने की आवश्यकता होती है, तो पिछले लिंक की पोस्ट, उक्त आवश्यकता को हल करने की विधि को दर्शाती है।
आदेश , पता , CustomerAddress और पता भूमिका
आमतौर पर, ऑर्डर के लिए केवल दो प्रकार के पते की आवश्यकता होती है , एक शिपिंग के लिए और एक बिलिंग के लिए । इस तरह, एक ही पता उदाहरण दोनों भर सकूं भूमिकाएँ एक व्यक्ति के लिए आदेश है, लेकिन प्रत्येक भूमिका संबंधित संपत्ति, यानी, द्वारा चित्र है ShippingAddressId या BillingAddressId ।
आदेश के साथ जुड़ा हुआ है पता के माध्यम से CustomerAddress , दो बहु संपत्ति विदेशी चाबियाँ, यानी की सहायता से साहचर्य इकाई प्रकार
- ( CustomerNumber , ShippingAddressId ), और ( CustomerNumber , BillingAddressId ),
दोनों की ओर इशारा करते CustomerAddress बहु संपत्ति प्रमुख के रूप में दिखाया गया है कुंजी
- ( CustomerNumber , AddressId )
... जो कि एक व्यावसायिक नियम का प्रतिनिधित्व करने में मदद करता है जो (क) एक आदेश उदाहरण को विशेष रूप से (बी) पते के साथ जोड़ा जाना चाहिए, जो पहले उस विशिष्ट ग्राहक के साथ जुड़ा हुआ है जिसने उस आदेश को बनाया है , और कभी नहीं (सी) एक यादृच्छिक गैर- ग्राहक के साथ - संबंधित पता ।
(1) पता और (2) ग्राहक सेवा संघ के लिए इतिहास
यदि आप जानकारी के पते के टुकड़े को संशोधित करने की संभावना की आपूर्ति करना चाहते हैं, तो आपको सभी डेटा परिवर्तनों का ट्रैक रखना होगा। इस तरीके से मैंने एड्रेस को एक " ऑडिटेबल " इकाई प्रकार के रूप में दर्शाया है जो अपने खुद के एड्रेसहिस्ट्री को बनाए रखता है ।
के बाद से एक के बीच एक कनेक्शन की प्रकृति ग्राहक और एक पता भी एक या अधिक संशोधनों ग्रस्त हो सकते हैं, मैं भी के आधार पर एक "ऑडिट किए जाने योग्य" एक के रूप में इस तरह के एक संघ से निपटने में possiblity दर्शाया है CustomerAddressHistory इकाई प्रकार।
इस संबंध में, विभिन्न कारक प्रश्नोत्तर सं। 1 और क्यू एंड ए नं। 2 , एक डेटाबेस में अस्थायी क्षमताओं को सक्षम करने के बारे में - वास्तव में प्रासंगिक हैं।
चित्रण एसक्यूएल-डीडीएल तार्किक लेआउट
नतीजतन, ऊपर दिखाए गए आरेख के संदर्भ में, मैंने निम्नलिखित तार्किक-स्तरीय व्यवस्था की घोषणा की (जिसे आप अपनी आवश्यकताओं को सटीकता के साथ पूरा करने के लिए अनुकूलित कर सकते हैं):
-- 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 domain.
-- As one would expect, you are free to utilize
-- your preferred (or required) naming conventions.
CREATE TABLE Customer (
CustomerNumber INT NOT NULL,
SpecificAttribute CHAR(30) NOT NULL,
ParticularAttribute CHAR(30) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Customer_PK PRIMARY KEY (CustomerNumber)
);
CREATE TABLE Address (
AddressId INT NOT NULL,
SpecificAttribute CHAR(30) NOT NULL,
ParticularAttribute CHAR(30) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Address_PK PRIMARY KEY (AddressId)
);
CREATE TABLE CustomerAddress (
CustomerNumber INT NOT NULL,
AddressId INT NOT NULL,
IsPhysical BIT NOT NULL,
IsShipping BIT NOT NULL,
IsBilling BIT NOT NULL,
IsActive BIT NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT CustomerAddress_PK PRIMARY KEY (CustomerNumber, AddressId),
CONSTRAINT CustomerAddressToCustomer_FK FOREIGN KEY (CustomerNumber)
REFERENCES Customer (CustomerNumber),
CONSTRAINT CustomerAddressToAddress_FK FOREIGN KEY (AddressId)
REFERENCES Address (AddressId)
);
CREATE TABLE MyOrder (
CustomerNumber INT NOT NULL,
OrderNumber INT NOT NULL,
ShippingAddressId INT NOT NULL,
BillingAddressId INT NOT NULL,
SpecificAttribute CHAR(30) NOT NULL,
ParticularAttribute CHAR(30) NOT NULL,
OrderDate DATE NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Order_PK PRIMARY KEY (CustomerNumber, OrderNumber),
CONSTRAINT OrderToCustomer_FK FOREIGN KEY (CustomerNumber)
REFERENCES Customer (CustomerNumber),
CONSTRAINT OrderToShippingAddress_FK FOREIGN KEY (CustomerNumber, ShippingAddressId)
REFERENCES CustomerAddress (CustomerNumber, AddressId),
CONSTRAINT OrderToBillingAddress_FK FOREIGN KEY (CustomerNumber, BillingAddressId)
REFERENCES CustomerAddress (CustomerNumber, AddressId)
);
CREATE TABLE AddressHistory (
AddressId INT NOT NULL,
AuditedDateTime DATETIME NOT NULL,
SpecificAttribute CHAR(30) NOT NULL,
ParticularAttribute CHAR(30) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT AddressHistory_PK PRIMARY KEY (AddressId, AuditedDateTime),
CONSTRAINT AddressHistoryToAddress_FK FOREIGN KEY (AddressId)
REFERENCES Address (AddressId)
);
CREATE TABLE CustomerAddressHistory (
CustomerNumber INT NOT NULL,
AddressId INT NOT NULL,
AuditedDateTime DATETIME NOT NULL,
IsPhysical BIT NOT NULL,
IsShipping BIT NOT NULL,
IsBilling BIT NOT NULL,
IsActive BIT NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT CustomerAddressHistory_PK PRIMARY KEY (CustomerNumber, AddressId, AuditedDateTime),
CONSTRAINT CustomerAddressHistoryToCustomerAddress_FK FOREIGN KEY (CustomerNumber, AddressId)
REFERENCES CustomerAddress (CustomerNumber, AddressId)
);
यदि आप एक नज़र रखना चाहते हैं, तो मैंने इसे इस db <> फिडेल में परीक्षण किया जो SQL Server 2017 पर चलता है।
Historyटेबल
आपके प्रश्न के निम्नलिखित अंश बहुत महत्वपूर्ण हैं:
मैं जिस चीज की तलाश कर रहा हूं वह यह है कि मैं अपने पते कैसे सेट कर सकता हूं, इसलिए जब मैं उन्हें संपादित करता हूं, तो आदेश इस तथ्य से प्रभावित नहीं होता है कि ग्राहक अपने पते को अपडेट करता है या स्थानांतरित करता है।
AddressHistoryऔर CustomerAddressHistoryयह सुनिश्चित करना कि एक में तालिकाओं सहायता आदेश से प्रभावित नहीं है पता , परिवर्तन के रूप में सभी "पिछला" पंक्तियों संबंधित में बनाए रखा जाना चाहिए Historyमेज और जरूरत पड़ने पर पूछे जा सकते हैं। इन दो तालिकाओं पर अद्यतन और DELETE संचालन निषिद्ध होना चाहिए (इतिहास को बदलने की कोशिश करना नकारात्मक नकारात्मक प्रभाव भी हो सकता है)।
अंतराल मूल्यों में संलग्न के बीच घेर AddressHistory.CreatedDateTimeऔर AddressHistory.AuditedDateTimeपूरे के लिए खड़ा है अवधि के दौरान जो एक निश्चित "अतीत" Addressपंक्ति समझा था "वर्तमान", "वर्तमान" या "प्रभावी"। इसी तरह के विचार CustomerAddressHistoryपंक्तियों पर लागू होते हैं।
CustomerAddress.IsActiveबीआईटी (बुलियन) स्तंभ का कहना है कि क्या एक निश्चित होती है Addressपंक्ति "प्रयोग करने योग्य" एक के द्वारा होता है Customerपंक्ति या नहीं; उदाहरण के लिए, यदि यह 'गलत' पर सेट है, तो यह इस तथ्य को बताएगा कि ग्राहक अब उस पते का उपयोग नहीं कर रहा है और इसलिए इसका उपयोग नए आदेशों के लिए नहीं किया जा सकता है ।
नोट : दूसरी ओर, मैंने कुछ सिस्टम देखे हैं जिसमें हर बार जब एक नया ऑर्डर प्रभावित होता है तो पता दर्ज करना पड़ता है (कुछ समय बार-बार), और पिछले आदेशों के लिए उपयोग किए जाने वाले पते (तों) को कभी मिटाया नहीं जाता है (इसलिए आदेश से प्रभावित नहीं हैं पता परिवर्तन)।
कार्रवाई के इस पाठ्यक्रम में निश्चित रूप से अतिरेक की पर्याप्त मात्रा शामिल हो सकती है, लेकिन यह एक संभावना है कि आपके व्यापार डोमेन की सटीक सूचनात्मक आवश्यकताओं पर काम कर सकता है- इसलिए आप इसके पेशेवरों और विपक्षों का भी मूल्यांकन कर सकते हैं।
डेटा की पुनःप्राप्ति
एक के "वर्तमान", "वर्तमान" या "प्रभावी" संस्करण पता घटना में एक पंक्ति के रूप में निहित होना चाहिए Addressमेज, लेकिन एक के पिछले "राज्यों" का चयन पता से AddressHistory(या से CustomerAddressHistory) तालिका आसान है, और यह हो सकता है अपने SQL कोडिंग कौशल को बढ़ाने के लिए एक दिलचस्प अभ्यास हो।
किसी एक स्थिति के संबंध में, जो आपने टिप्पणियों में उल्लिखित है, यदि आप किसी व्यक्तिगत Addressपंक्ति से "दूसरा से अंतिम संस्करण" प्राप्त करना चाहते हैं, तो आपको AddressHistoryइसे ध्यान में रखना होगा MAX(AddressHistory.AuditedDateTime)और AddressHistory.AddressIdयह विशेष Address.AddressIdमूल्य से मेल खाता है ।
इस संबंध में - संबंधपरक डेटाबेस का निर्माण करते समय कम से कम , यह पहले से संबंधित वैचारिक स्कीमा (लागू व्यापार नियमों के आधार पर ) को परिभाषित करने के लिए काफी सुविधाजनक है और इसके बाद इसकी बाद की तार्किक डीडीएल व्यवस्था की घोषणा करता है । एक बार जब आप इन मूलभूत तत्वों के स्थिर और विश्वसनीय संस्करण प्राप्त कर लेते हैं (जो कि, निश्चित रूप से, समय के साथ विकसित हो सकते हैं), तो यह हेरफेर करने के लिए सर्वोत्तम तरीकों का विश्लेषण और निर्धारण करने का समय है (INSERT, UPDATE, DELETE और SELECT संचालन या संयोजन के माध्यम से) डेटा के विषय में।
अंतिम-उपयोगकर्ता की धारणा, विचार और एप्लिकेशन प्रोग्राम (ओं) को सहायता
स्पष्ट रूप से, अमूर्तता के बाहरी स्तर पर, पता जानकारी एक आदेश का हिस्सा होने के रूप में माना जाता है (और एक आदेश के भाग के रूप में) , और इसके साथ कुछ भी गलत नहीं है, लेकिन इसका मतलब यह नहीं है कि मॉडलर्स को महत्वपूर्ण भागों को डिजाइन करना होगा डेटाबेस में सवाल की तरह है कि। इस बिंदु पर, अगर वहाँ की जरूरत है, उदाहरण के लिए, एक "पूर्ण" आदेश (बहुत संभव) मुद्रित करें , तो आप कुछ जॉय ऑपरेटर और WHERE क्लॉस की मदद से इसकी मांग "पुन: पेश" कर सकते हैं (संबंधित वैधता अवधि को देखते हुए) , आदि) शायद भविष्य में खपत के लिए विचारों में तय किया गया है, संबंधित आवेदन कार्यक्रम (ओं) के लिए निर्धारित उचित परिणाम भेजना, जो बदले में, आवश्यक के रूप में इसकी स्वरूपण को बढ़ा सकता है।
बेशक, जब एक आदेश प्रभावित हो रहा हो तो एप्लिकेशन प्रोग्राम भी बहुत मददगार होगा ; उदाहरण के लिए, एक डेस्कटॉप / मोबाइल ऐप विंडो या एक वेब पेज:
- केवल उस पते (तों) को प्रदर्शित करें जिसे शामिल ग्राहक ने "प्रयोग करने योग्य" (के माध्यम से
CustomerAddress.IsActive) के रूप में स्थापित किया है ;
- सूची एक साथ सभी पतों कि ग्राहक (के माध्यम से बिलिंग सेवा के लिए सक्षम है
CustomerAddress.IsBilling); तथा
- सभी पते जिन्हें ग्राहक ने शिपिंग सेवा (के माध्यम से
CustomerAddress.IsShipping) के लिए परिभाषित किया है ;
इस तरीके से जीयूआई (यानी, कम्प्यूटरीकृत प्रणाली के अमूर्त के बाहरी स्तर) में सभी शामिल प्रक्रियाओं की सुविधा।
पढ़ने का सुझाव दिया
आपने ध्वनि डेटाबेस साहित्य के बारे में कुछ संकेत (अब हटाए गए टिप्पणियों में) का अनुरोध किया; इसलिए, सैद्धांतिक सामग्री के लिए, मैं अत्यधिक सलाह देता हूं कि आप डॉ। ईएफ कोडड , ट्यूरिंग अवार्ड प्राप्तकर्ता द्वारा लिखे गए सभी कार्यों को पढ़ें और निश्चित रूप से, डेटा के रिलेशनल मॉडल के एकमात्र प्रवर्तक (शायद अब पहले से कहीं अधिक प्रासंगिक हैं)। इस सूची में उनके कुछ जबरदस्त प्रभावशाली लेख और कागजात शामिल हैं।
उपरोक्त सूची में शामिल दो महत्वपूर्ण कार्य, ठीक हैं, उनके एसीएम ट्यूरिंग अवार्ड लेक्चर फॉर रिलेटिव डेटाबेस: ए प्रैक्टिकल फाउंडेशन फॉर प्रोडक्टिविटी , 1981 से, और उनकी पुस्तक ने डेटाबेस प्रबंधन के लिए रिलेशनल मॉडल , संस्करण 2 को स्पष्ट किया , जो प्रकाशित हुआ था। 1990 में।
पर वैचारिक डिजाइन सामने, सूचना मॉडलिंग के लिए एकीकृत परिभाषा (IDEF1X) एक गंभीरता से सिफ़ारिश लायक तकनीक है कि अमेरिका द्वारा दिसंबर 1993 में एक मानक के रूप में परिभाषित किया गया है राष्ट्रीय मानक संस्थान और प्रौद्योगिकी (NIST)।