আমি কি ট্রানসিটিভ বিদেশী কী যুক্ত করব?


11

সাধারণ উদাহরণ: গ্রাহকদের একটি টেবিল রয়েছে।

create table Customers (
  id integer,
  constraint CustomersPK primary key (id)
)

ডাটাবেসের অন্যান্য সমস্ত ডেটার সাথে একটি লিঙ্ক করা উচিত Customer, সুতরাং উদাহরণস্বরূপ Ordersদেখতে যেমন:

create table Orders (
  id integer,
  customer integer,
  constraint OrdersPK primary key (customer, id),
  constraint OrdersFKCustomers foreign key (customer) references Customers (id)
)

ধরুন এখন এখানে কোনও টেবিলের লিঙ্ক রয়েছে Orders:

create table Items (
  id integer,
  customer integer,
  order integer,
  constraint ItemsPK primary key (customer, id),
  constraint ItemsFKOrders foreign key (customer, order) references Orders (customer, id)
)

আমি থেকে একটি পৃথক বিদেশী কী যোগ করা উচিত Itemsকাছে Customers?

...
constraint ItemsFKCustomers foreign key (customer) references Customers (id)

পরিবর্তে একটি ছবি: আমি কী ড্যাশযুক্ত লাইন / এফকে যুক্ত করব?

সরল উদাহরণ স্কিমা


সম্পাদনা: আমি টেবিলগুলিতে প্রাথমিক কী সংজ্ঞা যুক্ত করেছি। আমি উপরে যে বক্তব্যটি দিয়েছি তাতে পুনরায় পুনরাবৃত্তি করতে চাই: নির্ভুলতা / সুরক্ষা ব্যবস্থা হিসাবে গ্রাহকরা মূলত ডাটাবেসটি সিল করেন। সুতরাং, সমস্ত প্রাথমিক কীতে customerআইডি থাকে contain


2
না, আপনার করা উচিত নয়। অতিরিক্ত এফকে দেওয়ার দরকার নেই। সীমাবদ্ধতা প্রয়োগ করা হয়েছে অন্য দুটি এফকে দ্বারা।
ypercubeᵀᴹ

@ টাইপব্যুরো কি এলোপাতাড়ি এফকে রাখার জন্য কোনও পারফরম্যান্সের শাস্তি রয়েছে? আপনি যে কোনও সুবিধার কথা ভাবতে পারেন? ...
ভেক্টর

1
@ ওয়েক্টোর, পারফরম্যান্সের দিকগুলি সম্ভবত একটি আরডিবিএম থেকে অন্যটিতে পরিবর্তিত হতে পারে, তবে সাধারণত, আপনি যুক্ত প্রতিটি নতুন এফকে জন্য আপনি একটি পারফরম্যান্স ইফেক্ট পান কারণ পিকে / এফকে টেবিলগুলির মধ্যে একটিতে প্রতিটি সন্নিবেশ / আপডেট / মুছে ফেলা উচিত বাধ্যতা। বড় পিকে টেবিল সহ, এই পারফরম্যান্স পেনাল্টিটি বেশ তীব্র হতে পারে।
ড্যানিয়েল হুটমাচার

উত্তর:


6

আমি মনে করি এটিই আসল ধারণা।

এখানে চিত্র বর্ণনা লিখুন

প্রথমে লক্ষ্য করার বিষয়টি হ'ল লাইন আইটেম টেবিলের পিকে তিনটি বৈশিষ্ট্য রয়েছে {CustomerID, CustomerOrderNo, OdrerItemNo}, যেমন আপনার উদাহরণে কেবল দু'জনের বিপরীতে।

দ্বিতীয় বিষয় লক্ষণীয় হ'ল idকোনও গুণাবলীর জন্য জেনেরিক নাম ব্যবহারের ফলে বিভ্রান্তি ।

CustomerOrderNoআদর্শভাবে (1,2,3 ..) প্রতিটি গ্রাহকের এবং জন্য হওয়া উচিত OrderItemNoপ্রতিটি আদেশের জন্য (1,2,3 ...)।

ভাল, যদি সম্ভব হয় তবে এটি দুর্দান্ত, তবে আগের সর্বাধিক মান, এর মতো সন্ধানের জন্য একটি প্রশ্নের প্রয়োজন

select max(CustomerOrderNo)
from Order 
where CustomerID = specific_customer ; 

যা উচ্চ-লেনদেন-ভলিউম পরিবেশে প্রায়শই পছন্দ করা হয় না, তাই এটি প্রয়োজনীয়ভাবে একই উদ্দেশ্যে পরিবেশন করে একটি অটো-ইনক্রিমেন্ট দ্বারা প্রতিস্থাপিত হওয়া সাধারণ বিষয়। এটি সত্য যে এই অটো-ইনক্রিমিটটি এখন অনন্য, তাই এটি কেইওয়াই হিসাবে ব্যবহার করা যেতে পারে - তবে আপনি এটির জন্য প্রয়োজনীয় আপস হিসাবে এটি বেছে নিতে বেছে নিতে পারেন OrderItemNo

সুতরাং, কিছু নামকরণ CustomerOrderNo -> OrderNoএবং OrderItemNo-> দিয়ে ItemNoআপনি এই মডেলটিতে আসতে পারেন

এখানে চিত্র বর্ণনা লিখুন

সুতরাং এখন আপনি নীচের দিকে তাকান Orderঅনন্য

{OrderNo}             -- PK
{CustomerID, OrderNo} -- superkey,  AK on the diagram.

নোট যা এফকে হিসাবে পরিবেশন {CustomerID, OrderNo}করার জন্য প্রচার করা হয় LineItem

আপনি যদি কিছুটা স্ক্রিন্ট করেন তবে এটি আপনার উদাহরণের নিকটে, তবে PKs {ItemNo} and {OrderNo}কেবলমাত্র - যেমন আপনার উদাহরণ থেকে দুটি কলাম পিকে রয়েছে।

এখন প্রশ্ন, কেন এই জাতীয় কিছু সহজ করা হয় না?

এখানে চিত্র বর্ণনা লিখুন

কোনটি জরিমানা, কিন্তু প্রবর্তন পাথ নির্ভরতা - আপনি যোগ দিতে পারবেন না LineItemসঙ্গে Customerসরাসরি ব্যবহার করা আবশ্যক Orderযোগদানের হবে।


সম্ভব হলে আমি প্রথম কেসটিকেই পছন্দ করি - আপনি নিজের পছন্দটি বেছে নিন। এবং অবশ্যই, সেখান থেকে সরাসরি এফ কে প্রয়োজন নেই LineItemকরার Customerএই তিনটি ক্ষেত্রেই।


আমি আশেপাশে অনুসন্ধান করেছিলাম, তবে আমি "২ য় ডিগ্রি ট্রানজিটিভ রিলেশনশিটি" (যদিও আমার পরিভাষাটিও খুব ভুল) হিসাবে উল্লেখ করা হবে তার জন্য ব্যাপকভাবে গৃহীত শব্দ হিসাবে "পথ নির্ভরতা" ব্যবহার হচ্ছে না
দাই

2

"আইটেম" সরাসরি "গ্রাহক" উল্লেখ করা উচিত নয়, কারণ এটি আইটেমের "ক্রম" দ্বারা অন্তর্ভুক্ত। সুতরাং, আপনার "গ্রাহক" কলামগুলির কোনও "আইটেম" টেবিলের প্রয়োজন হবে না।

বিদ্যমান বিদেশী কী দিয়ে গ্রাহকের সাথে আইটেমটির সম্পর্ক নিশ্চিত করা হয়েছে।

যদি অর্ডার.আইডি একটি পরিচয় কলাম হয়, তবে সামগ্রিকভাবে আইটেমস কাস্টমারের অপসারণ বিবেচনা করুন।


1
ধন্যবাদ, আমি লক্ষ্য করি না যে "গ্রাহক" এছাড়াও "আইটেম" থেকে "অর্ডার" পর্যন্ত প্রথম এফকে অন্তর্ভুক্ত ছিল। আমি সেই অনুযায়ী আমার উত্তরটি বিস্তারিতভাবে বর্ণনা করেছি।
ড্যানিয়েল হুটমাচার

@ ড্যানিয়েলহুটমাচার আমি আমার টেবিলগুলির প্রাথমিক কীগুলি ধারণ করতে প্রশ্নটি সম্পাদনা করেছি। এটি আপনার সম্পাদনায় উল্লেখ করা অদ্ভুত এফকে ব্যাখ্যা করে explains
ভেক্টর

ঠিক আছে, আমি আমার উত্তর আপডেট করেছি। :)
ড্যানিয়েল হুটমাচার

আমি অনুমান করছি যে customerসমস্ত টেবিলে থাকা (এবং এভাবে ডিবি সিলোইন করা) একটি অস্বাভাবিক পদ্ধতি approach আমাকে অবশ্যই স্বীকার করতে হবে যে এটি আমার পূর্ববর্তী কাজে আমি দেখেছি something এটি কি আপনার কোনও ধারণা রাখে? এর আগে এমন ডিজাইন দেখেছেন?
ভেক্টর

আমি বলব এটি একটি ডেটাওয়ারহাউস (স্টার স্কিমা) পদ্ধতির মত দেখাচ্ছে, যেখানে আপনি যোগদানগুলি দূর করতে ইচ্ছাকৃতভাবে ডেটা অস্বীকৃতি করতে চান। বা প্রাথমিক কীটি যৌগিক হতে পারে, যেমন গ্রাহক এ এর ​​প্রথম, দ্বিতীয়, তৃতীয় আদেশ, গ্রাহক বি এর প্রথম, দ্বিতীয় আদেশ ইত্যাদি - যখন একার অর্ডার আইডি কলামটি অনন্য নয়।
ড্যানিয়েল হুটমাচার
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.