ধারণাগতভাবে বলতে গেলে, যদিও আপনার ব্যবসায়ের পরিবেশে আদেশ এবং ঠিকানা ঘনিষ্ঠভাবে যুক্ত এমন ধারণা, তারা কার্যকরভাবে দুটি পৃথক সত্তার প্রকার, প্রতিটি তার নিজস্ব প্রয়োগযোগ্য বৈশিষ্ট্য (বা বৈশিষ্ট্য) এবং সীমাবদ্ধতার সাথে সেট করে।
অতএব, পূর্ববর্তী মন্তব্যে যেমন বলা হয়েছে, আমি @ এরিকের সাথে একমত , এবং আপনার অন্যান্য ডাটাবেসের মধ্যে ঘোষণা করে আপনার ডাটাবেসের যৌক্তিক বিন্যাসটি পরিচালনা করা উচিত:
- ঠিকানার তথ্য টুকরো রাখতে একটি স্বতন্ত্র টেবিল ;
- গ্রাহক- বিশদ বিবরণ ধরে রাখতে একটি টেবিল ;
- অর্ডার ডেটা পয়েন্টগুলি সংযুক্ত করার জন্য একটি টেবিল ; এবং
- গ্রাহক এবং ঠিকানা (এস) এর মধ্যে সংযুক্তি সম্পর্কে তথ্য ধারণ করার জন্য একটি সারণী ;
যেমন আমি নীচে উদাহরণ দিয়ে দেব।
এক্সপোসিটোরি IDEF1X ডায়াগ্রাম
একটি ছবি এক হাজার শব্দের মূল্যবান, তাই আমি আমার পরামর্শ দিয়ে খোলা কিছু সম্ভাবনার চিত্রিত করতে চিত্র 1 এ দেখানো IDEF1X চিত্রটি তৈরি করেছি:
গ্রাহক , ঠিকানা এবং তাদের সমিতি
প্রদর্শিত হিসাবে, সত্তা ধরণের গ্রাহক a এবং ঠিকানার মধ্যে কার্ডিনালিটির অনুপাতের সাথে আমি অনেকগুলি থেকে বহু (এম: এন) কার্ডিনিলিটি অনুপাতের সাথে একটি সমিতি চিত্রিত করেছি ; এই পদ্ধতির ভবিষ্যতের নমনীয়তা সরবরাহ করবে কারণ আপনি জানেন যে কোনও গ্রাহক সময়ের সাথে একাধিক ঠিকানা রাখতে পারেন বা এমনকি একই সাথে এবং একই ঠিকানাটি একাধিক গ্রাহক ভাগ করে নিতে পারেন ।
একটি নির্দিষ্ট ঠিকানা একাধিক (1: এম) গ্রাহকরা বিভিন্ন উপায়ে ব্যবহার করতে পারেন ; উদাহরণস্বরূপ, এটি শারীরিক হিসাবে সংজ্ঞায়িত করা যেতে পারে , এবং / অথবা এটি শিপিংয়ের জন্য এবং / অথবা বিলিংয়ের জন্য সেট করা যেতে পারে । সম্ভবত, একই ঠিকানা উদাহরণটি একই সাথে উপরোক্ত প্রতিটি উদ্দেশ্যকে পরিবেশন করতে পারে, বা এটি দুটি ব্যবহার করতে পারে যখন পৃথক ঠিকানার উপস্থিতিগুলি অন্যটি আবরণ করে।
একটি কিছু ব্যবসায়ের পরিবেশে, একজন গ্রাহক ব্যক্তি বা সংস্থা হতে পারে(এমন পরিস্থিতি যা কিছুটা স্বতন্ত্র বিন্যাসকে বোঝায়,একটি সুপারটাইপ-সাব-টাইপ কাঠামোর বিষয়ে এই উত্তরে যেমন বর্ণনা করা হয় ) তবে সরল উদাহরণ দেওয়ার লক্ষ্যে আমি সিদ্ধান্ত নিয়েছিলাম এখানে সম্ভাবনা অন্তর্ভুক্ত না। আপনার ডাটাবেসে আপনার যদি সেই পরিস্থিতিটি আবশ্যক হয় তবে পূর্ববর্তী লিঙ্কটির পোস্টটি প্রয়োজনীয়তা সমাধানের পদ্ধতিটি দেখায়।
অর্ডার , ঠিকানা , গ্রাহক ঠিকানা এবং ঠিকানা ভূমিকা
সাধারণত, একটি আদেশের জন্য কেবল দুই প্রকারের ঠিকানা দরকার হয় , একটি শিপিংয়ের জন্য এবং একটি বিলিংয়ের জন্য । এই ভাবে, একই ঠিকানা উদাহরণস্বরূপ উভয় পূরণ করতে পারে ভূমিকা একটি পৃথক জন্য অর্ডার , কিন্তু প্রতিটি ভূমিকা নিজ নিজ সম্পত্তি, অর্থাত, দ্বারা অঙ্কিত হয় ShippingAddressId বা BillingAddressId ।
দুটি মাল্টি-প্রপার্টি বিদেশী কীগুলির সহায়তায় কাস্টমারএড্রেস এসোসিয়েটিভ সত্তা টাইপের মাধ্যমে অর্ডার ঠিকানার সাথে সংযুক্ত করা হয়েছে , অর্থাৎ,
- ( CustomerNumber , ShippingAddressId ), এবং ( CustomerNumber , BillingAddressId ),
উভয়ই গ্রাহক অ্যাড্রেস মাল্টি-প্রপার্টি প্রাথমিক কী হিসাবে দেখানো হয়েছে as
- ( গ্রাহক সংখ্যা , ঠিকানাআইডি )
… যা এমন ব্যবসায়ের নিয়মকে প্রতিনিধিত্ব করতে সহায়তা করে যা এই শর্ত দেয় যে (ক) একটি আদেশের উদাহরণটি অবশ্যই (খ) নির্দিষ্ট গ্রাহকের সাথে সম্পর্কিত যে ঠিকানার সাথে এই আদেশটি তৈরি হয়েছিল , এবং (সি) এলোমেলো অ- গ্রাহকের সাথে কখনও যুক্ত হবে না - সম্পর্কিত ঠিকানা ।
(1) ঠিকানা এবং (2) গ্রাহক ঠিকানা ঠিকানা সমিতির জন্য ইতিহাস
আপনি পরিবর্তন সম্ভাবনা সরবরাহ করতে চান, ঠিকানা তথ্য টুকরা, তারপর আপনি সমস্ত ডেটা পরিবর্তন ট্র্যাক রাখতে হবে। এই পদ্ধতিতে আমি ঠিকানাটিকে একটি " নিরীক্ষণযোগ্য " সত্তার ধরণ হিসাবে চিত্রিত করেছি যা তার নিজস্ব ঠিকানা ইতিহাস বজায় রাখে ।
যেহেতু একটা মধ্যে একটি সংযোগ প্রকৃতি গ্রাহক এবং একটি ঠিকানা এক অথবা একাধিক পরিবর্তন ভোগা করতে পারেন আমি ভাল হিসাবে শক্তি কর্মদক্ষতার দ্বারা একটি "মূল্যায়নযোগ্য" এক হিসাবে যেমন একটি অ্যাসোসিয়েশন পরিচালনার সম্ভাবনা ফোটানো হয়েছে 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)
);
আপনি যদি একবার নজর দিতে চান তবে এসকিউএল সার্ভার 2017 এ চলে এমন এই ডিবি <> ফিডেলে আমি এটি পরীক্ষা করেছি ।
Historyটেবিল
আপনার প্রশ্ন থেকে নিম্নলিখিত অংশগুলি খুব গুরুত্বপূর্ণ:
আমি যা খুঁজছি তা হল আমি কীভাবে আমার ঠিকানাগুলি সেট আপ করতে পারি তাই আমি যখন এগুলি সম্পাদনা করি তখন অর্ডারটি কোনও গ্রাহক তার ঠিকানা আপডেট করে বা স্থানান্তরিত করে এই বিষয়টি দ্বারা প্রভাবিত হয় না।
AddressHistoryএবং CustomerAddressHistoryনিশ্চিত একটি ইন টেবিল এইড অর্ডার দ্বারা প্রভাবিত হয় না ঠিকানার পরিবর্তন যেমন সমস্ত "পূর্ববর্তী" সারি নিজ নিজ রেখে দেওয়া উচিত Historyটেবিল এবং যখন প্রয়োজন জানতে চাওয়া হতে পারে। আপডেট এবং এই দুটি টেবিলের মুছে ফেলা অপারেশন নিষিদ্ধ করা উচিত (ইতিহাস পরিবর্তন করার চেষ্টা এমনকি নেতিবাচক আইনি জড়িত থাকতে পারে)।
ব্যবধান মানের মধ্যে ঘিরা মধ্যে বেষ্টন AddressHistory.CreatedDateTimeএবং AddressHistory.AuditedDateTimeসমগ্র ঘোরা সময়কাল সময় একটি নির্দিষ্ট "অতীত" Addressসারি গণ্য করা হয়েছিল "বর্তমান", "বর্তমান" বা "কার্যকর"। একই CustomerAddressHistoryমতামতগুলি সারিগুলিতে প্রযোজ্য ।
CustomerAddress.IsActiveবিট (বুলিয়ান) কলাম নির্দেশ কিনা একটি নির্দিষ্ট বোঝানো হয় Addressসারি "ব্যবহারযোগ্য" একটি করে Customerসারি বা নয়; উদাহরণস্বরূপ, যদি এটি 'মিথ্যা' হিসাবে সেট করা থাকে তবে এটি এই সত্যটি প্রকাশ করে যে কোনও গ্রাহক সেই ঠিকানাটি আর ব্যবহার করছেন না এবং তাই এটি নতুন আদেশগুলির জন্য ব্যবহার করা যাবে না ।
দ্রষ্টব্য : অন্যদিকে, আমি এমন কিছু সিস্টেম দেখেছি যেখানে প্রতিটি বার নতুন আদেশ কার্যকর করা হলে ঠিকানার তথ্য প্রবেশ করাতে হবে (কিছু সময় বারবার), এবং পূর্ববর্তী আদেশগুলির জন্য ব্যবহৃত ঠিকানা (এস) কখনও মুছে ফেলা হয় না (তাই) আদেশ দ্বারা প্রভাবিত হয় না ঠিকানার পরিবর্তন)।
কর্মের এই কোর্সটি নির্ধারিতভাবে অতিরিক্তভাবে অতিরিক্ত অর্থের পরিমাণ জড়িত করতে পারে তবে এটি সম্ভবত আপনার ব্যবসায়ের ডোমেনের সঠিক তথ্যের প্রয়োজনীয়তার উপর নির্ভর করে কাজ করতে পারে, তাই আপনি এর উপকারিতা এবং মতগুলিও মূল্যায়ন করতে পছন্দ করতে পারেন।
তথ্য পুনরুদ্ধার
একটি এর "বর্তমান", "বর্তমান" বা "কার্যকর" সংস্করণ ঠিকানা সংঘটন একটি সারিতে যেমন অন্তর্ভুক্ত হবে Addressটেবিল, কিন্তু একটি পূর্ববর্তী "রাজ্যের" নির্বাচন ঠিকানা থেকে AddressHistory(অথবা থেকে CustomerAddressHistory) টেবিল সহজ, এবং এটা may আপনার এসকিউএল কোডিং দক্ষতা বাড়ানোর জন্য একটি আকর্ষণীয় অনুশীলন হয়ে উঠুন।
আপনি মন্তব্যে যে পরিস্থিতিগুলির উল্লেখ করেছেন তার মধ্যে একটির প্রতি শ্রদ্ধার সাথে , আপনি যদি Addressতার থেকে পৃথক সারির "দ্বিতীয় থেকে শেষ সংস্করণ" পুনরুদ্ধার করতে চান তবে আপনাকে সেই বিশেষ মানটি এবং সেই সাথে যেটি নির্দিষ্ট মানের সাথে মিলবে তা বিবেচনা করতে হবে।AddressHistoryMAX(AddressHistory.AuditedDateTime)AddressHistory.AddressIdAddress.AddressId
এক্ষেত্রে - কমপক্ষে রিলেশনাল ডাটাবেস তৈরি করার সময়, প্রথমে সম্পর্কিত ধারণাগত স্কিমা (প্রযোজ্য ব্যবসায়ের নিয়মের উপর ভিত্তি করে ) সংজ্ঞায়িত করা বেশ সুবিধাজনক এবং এর পরে তার পরবর্তী যৌক্তিক ডিডিএল ব্যবস্থা ঘোষণা করুন । একবার আপনি এই মৌলিক উপাদানগুলির স্থিতিশীল এবং নির্ভরযোগ্য সংস্করণগুলি (যা অবশ্যই সময়ের সাথে সাথে বিকশিত হতে পারে) অর্জন করার পরে, পরিচালনা করার সর্বোত্তম উপায়গুলি (INSERT, আপডেট, মোছা এবং নির্বাচন পরিচালনা বা এর সংমিশ্রনের মাধ্যমে) বিশ্লেষণ এবং নির্ধারণ করার সময় এটি তথ্য সম্পর্কিত।
শেষ ব্যবহারকারীদের উপলব্ধি, মতামত এবং অ্যাপ্লিকেশন প্রোগ্রাম (গুলি) সহায়তা
স্পষ্টতই, বিমূর্ততার বাহ্যিক স্তরে, ঠিকানা সম্পর্কিত তথ্য (শেষ ব্যবহারকারীরা দ্বারা) একটি আদেশের অংশ হিসাবে অনুধাবন করা হয় , এবং এতে কোনও ভুল নেই, তবে এর অর্থ এই নয় যে মডেলারদের গুরুত্বপূর্ণ অংশগুলি ডিজাইন করতে হবে প্রশ্ন মত ডাটাবেস। এই মুহুর্তে, যদি প্রয়োজন হয়, যেমন, একটি "সম্পূর্ণ" অর্ডার (খুব সম্ভাব্য) মুদ্রণ করতে পারেন, আপনি কয়েকটি যোগ অপারেটর এবং যেখানে বিধি (বৈধতার সময়কালের বিষয়ে বিবেচনা করে) এর সাহায্যে এটি অন-ডিমান্ডের "পুনরুত্পাদন" করতে পারেন , ইত্যাদি) হতে পারে ভবিষ্যতের ব্যবহারের জন্য দৃশ্যে স্থির করে, প্রাসঙ্গিক ফলাফলটি প্রাসঙ্গিক ফলাফল প্রেরণ সম্পর্কিত অ্যাপ্লিকেশন প্রোগ্রামগুলিতে প্রেরণ করুন যা পরিবর্তিতভাবে প্রয়োজনীয়ভাবে তার ফর্ম্যাটটিকে বাড়িয়ে তুলতে পারে।
অবশ্যই, যখন কোনও অর্ডার কার্যকর করা হচ্ছে তখন অ্যাপ্লিকেশন প্রোগ্রামগুলি খুব সহায়ক হবে ; উদাহরণস্বরূপ, একটি ডেস্কটপ / মোবাইল অ্যাপ্লিকেশন উইন্ডো বা একটি ওয়েব পৃষ্ঠা এটি করতে পারে:
- জড়িত গ্রাহক "ব্যবহারযোগ্য" (মাধ্যমে ) হিসাবে প্রতিষ্ঠিত কেবলমাত্র ঠিকানা (গুলি) প্রদর্শন করুন ;
CustomerAddress.IsActive
- গ্রাহক বিলিং পরিষেবা (মাধ্যমে ) সক্ষম করেছেন এমন সমস্ত ঠিকানা একসাথে তালিকাভুক্ত করুন ; এবং
CustomerAddress.IsBilling
- গ্রাহক শিপিং পরিষেবা (মাধ্যমে ) জন্য গ্রাহকরা যে সমস্ত ঠিকানা নির্ধারণ করেছেন তা গোষ্ঠীভুক্ত করুন ;
CustomerAddress.IsShipping
জিইউআইতে (যেমন, কম্পিউটারাইজড সিস্টেমের বিমূর্তকরণের বাহ্যিক স্তরের) সমস্ত জড়িত প্রক্রিয়াগুলিকে এই পদ্ধতিতে সহায়তা করা।
প্রস্তাবিত পড়া
আপনি সাউন্ড ডাটাবেস সাহিত্য সম্পর্কে কিছু পয়েন্টার (এখন সরিয়ে দেওয়া মন্তব্যে) অনুরোধ করেছেন; তাই হিসাবে তাত্ত্বিক উপাদান, আমি অত্যন্ত আপনাকে পরামর্শ দিচ্ছি সব কাজ দ্বারা লিখিত পড়া ডঃ মতিন Codd , একটি টুরিং পুরস্কার , প্রাপক এবং অবশ্যই একমাত্র জন্মদাতা এর ডেটার রিলেশনাল মডেল (হয়তো এখন আগের তুলনায় অনেক বেশি প্রাসঙ্গিক)। এই তালিকায় তাঁর দুর্দান্ত প্রভাবশালী কিছু নিবন্ধ এবং কাগজপত্র অন্তর্ভুক্ত রয়েছে।
উপরোক্ত তালিকায় অন্তর্ভুক্ত নয় এমন দুটি গুরুত্বপূর্ণ কাজ হ'ল যথাযথভাবে, তাঁর এসিএম টিউরিং অ্যাওয়ার্ড লেকচারটি রিলেশনাল ডাটাবেস: 1981 সাল থেকে উত্পাদনের জন্য একটি প্রাক্টিকাল ফাউন্ডেশন , এবং তার বইটি ডেটাবেস ম্যানেজমেন্টের জন্য সম্পর্কিত সম্পর্কিত মডেল: সংস্করণ 2 প্রকাশিত হয়েছিল 1990 সালে।
উপর ধারণাগত নকশা সামনে, তথ্য মডেলিং জন্য ইন্টিগ্রেটেড সংজ্ঞা (IDEF1X) একটি গম্ভীরভাবে সুপারিশের পন্থা যা মার্কিন ডিসেম্বর 1993 সালে একটি প্রমিত হিসেবে সংজ্ঞায়িত করা হয় স্ট্যান্ডার্ড ন্যাশনাল ইন্সটিটিউট অফ ও প্রযুক্তি (, NIST)।