10

আমার কাছে 3 টি টেবিল রয়েছে:

সম্প্রদায়
পোস্ট
পছন্দ

আমি যখন ইআর মডেলটি ডিজাইন করি তখন এটির একটি চক্রীয় নির্ভরতা থাকে:

         1: এন
লোক -------- <পোস্ট

         1: এন
পোস্ট ---------- <লাইক

         1: এন
লোক -------- <লাইক

যুক্তিটি হ'ল:

1 জন ব্যক্তির অনেক পোস্ট থাকতে পারে।
1 পোস্টে অনেক লাইক রয়েছে।
1 জন ব্যক্তি অনেক পোস্ট পছন্দ করতে পারে (তৈরি ব্যক্তি তার নিজের পোস্ট পছন্দ করতে পারে না)।

আমি এই ধরণের চক্র নকশাকে কীভাবে সরিয়ে ফেলতে পারি? নাকি আমার ডিবি ডিজাইন ভুল?

— Ragu
সূত্র

10

ব্যবসার নীতি

আপনি যে ব্যবসায়িক বিধি উপস্থাপন করেছেন সেগুলি সম্পর্কে কিছু মন্তব্য করা যাক:

একজন Personসৃষ্টি শূন্য এক বা অধিকের Posts ।
একজন Postপায় জিরো-ওয়ান বা অধিকের Likes ।
একজন Personটেপা শূন্য এক বা অধিকের Likes , কোনটা প্রতিটি সংক্রান্ত একটি নির্দিষ্ট Post ।

যৌক্তিক মডেল

তারপরে, এই জাতীয় জবাবের সেট থেকে, আমি চিত্র 1-এ প্রদর্শিত দুটি লজিকাল স্তরের আইডিইএফ ¹ এক্স ^[1] ডেটা মডেল পেয়েছি ।

চিত্র 1 - লোক এবং পোস্ট ডেটা মডেল

বিকল্প ক

আপনি অপশন একটি মডেল দেখতে পারেন, PersonId মাইগ্রেট ^[2] থেকে Personথেকে Postএকটি বিদেশী কী (এফ কে) হিসেবে, কিন্তু এটা পায় ভূমিকা নাম ^[3] এর AuthorIdএকসঙ্গে সঙ্গে, এবং এই বৈশিষ্ট্য তোলে আপ, PostNumber, প্রাথমিক কী (পি কে) এর Postসত্তা প্রকার।

আমি অনুমান করে একটি Likeশুধুমাত্র একটি নির্দিষ্ট সাথে বিদ্যমান পারেন Post, তাই আমি একটি সেট আপ Likeপি কে যে তিনটি ভিন্ন গুণাবলীর গঠিত: PostAuthorId, PostNumberএবং LikerId। এর সংমিশ্রণ PostAuthorIdএবং PostNumberএটি এমন একটি এফকে যা পিকেকে যথাযথ উল্লেখ করে Post। LikerIdপরিবর্তে, এমন একটি এফকে যা উপযুক্ত সংযোগ স্থাপন করে Person.PersonId।

এই কাঠামোর সহায়তায়, আপনি নিশ্চিত হন যে কোনও দৃ determined়প্রতিজ্ঞ ব্যক্তি কেবল Likeএকই ঘটনার একমাত্র ঘটনা প্রকাশ করতে পারে Post।

কোনও পোস্ট লেখককে তার নিজের পোস্ট পছন্দ করা থেকে বিরত করার পদ্ধতি

যেহেতু আপনি কোনও ব্যক্তিকে তার রচিত পোস্টগুলি পছন্দ করতে পারে এমন সম্ভাবনাটি মঞ্জুর করতে চান না , একবার বাস্তবায়নের পর্যায়ে, আপনার এমন একটি পদ্ধতি স্থাপন করা উচিত যা প্রতিটি INSERT চেষ্টার Like.PostAuthorIdমানের সাথে তুলনা Like.LikerIdকরে। যদি মানগুলি মিলে যায়, (ক) আপনি সন্নিবেশটিকে প্রত্যাখ্যান করেন, যদি সেগুলি মেলে না (খ) আপনি প্রক্রিয়াটি চালিয়ে যেতে দিন।

আপনার ডাটাবেসে এই কাজটি সম্পাদন করার জন্য, আপনি এটি ব্যবহার করতে পারেন:

একটি চেক চুক্তি তবে অবশ্যই, এই পদ্ধতিটি মাইএসকিউএল বাদ দেয়, যেহেতু এটি এখন পর্যন্ত এই প্ল্যাটফর্মে কার্যকর করা হয়নি, আপনি এখানে এবং এখানে দেখতে পারেন ।
একটি এসিডি লেনদেনের ভিতরে কোড লাইন ।
একটি ট্রিগারের মধ্যে কোড লাইনগুলি , যা নিয়ম লঙ্ঘনের প্রচেষ্টা নির্দেশ করে একটি কাস্টম বার্তা দিতে পারে।

বিকল্প বি

লেখক যদি এমন কোনও বৈশিষ্ট্য না হয়ে থাকেন যা প্রাথমিকভাবে আপনার ব্যবসায়িক ডোমেনে পোস্ট পোস্ট করে তবে আপনি অপশন বিতে বর্ণিত একটি কাঠামোর সাথে যেতে পারেন ption

এই পদ্ধতির বিষয়টিও নিশ্চিত করে যে কোনও পোস্ট একবারে একই ব্যক্তি একবারে পছন্দ করতে পারে।

_{তথ্য সম্পর্কিত মডেলিংয়ের জন্য ইন্টিগ্রেশন সংজ্ঞা ( আইডিইএফ 1 এক্স ) একটি অত্যন্ত প্রস্তাবযোগ্য ডেটা মডেলিং কৌশল যা ১৯৯৩ সালের ডিসেম্বর মাসে মার্কিন যুক্তরাষ্ট্রের ন্যাশনাল ইনস্টিটিউট অফ স্ট্যান্ডার্ডস অ্যান্ড টেকনোলজি ( এনআইএসটি ) দ্বারা একটি স্ট্যান্ডার্ড হিসাবে সংজ্ঞায়িত হয়েছিল ।}

_{2. আইডিইএফ 1 এক্স কী মাইগ্রেশনটিকে "পিতা-মাতা বা জেনেরিক সত্তার প্রাথমিক কীটি তার সন্তান বা বিভাগের সত্তায় একটি বিদেশী কী হিসাবে রাখার মডেলিং প্রক্রিয়া" হিসাবে সংজ্ঞায়িত করে ।}

_{৩. ভূমিকার নামটি হ'ল বিদেশী কী অ্যাট্রিবিউটের সাথে সম্পর্কিত এন্টিটিউটের সংশ্লিষ্ট প্রাসঙ্গিক প্রকারের প্রসঙ্গে এই বৈশিষ্ট্যের অর্থ প্রকাশ করার জন্য নির্ধারিত একটি বর্ণচিহ্ন। ১৯ 1970০ সাল থেকে ডাঃ ইএফ কোড্ড তার বড় মাপের কাগজটিতে "বৃহত্তর শেয়ারড ডেটা ব্যাঙ্কের জন্য ডেটার রিলেশনাল মডেল" শিরোনামের ভূমিকা নামকরণের প্রস্তাব দিয়েছিলেন । এর অংশ হিসাবে, আইডিইএফ 1 এক্স-রক্ষামূলক বিশ্বস্ততা সম্পর্কিত সম্পর্কিত আচরণগুলি - এছাড়াও এই পদ্ধতির সমর্থন করে adv}

— MDCCL
সূত্র

6

আমি এখানে কিছু চক্রযুক্ত দেখতে পাচ্ছি না। আছে মানুষ এবং পোস্ট এবং এই সত্ত্বা মধ্যে দুটি স্বাধীন সম্পর্ক। আমি এই সম্পর্কের একটি বাস্তবায়ন হিসাবে পছন্দ দেখতে পাবেন ।

একজন ব্যক্তি অনেকগুলি পোস্ট লিখতে পারেন, একটি পোস্ট একজন ব্যক্তি লিখেছেন: 1:n
একজন ব্যক্তি অনেক পোস্ট পছন্দ করতে পারেন একটি পোস্ট অনেক মানুষ পছন্দ করেছে করা যেতে পারে: n:m
এন এম সম্পর্ক অন্য সম্পর্ক সঙ্গে বাস্তবায়িত করা যাবে না: likes।

বেসিক বাস্তবায়ন

বেসিক বাস্তবায়ন পোস্টগ্র্রেএসকিউএল এর মতো দেখতে পারে :

CREATE TABLE person (
  person_id serial PRIMARY KEY
, person    text NOT NULL
);

CREATE TABLE post (
  post_id   serial PRIMARY KEY
, author_id int NOT NULL  -- cannot be anonymous
     REFERENCES person ON UPDATE CASCADE ON DELETE CASCADE  -- 1:n relationship
, post      text NOT NULL
);

CREATE TABLE likes (  -- n:m relationship
  person_id int REFERENCES person ON UPDATE CASCADE ON DELETE CASCADE
, post_id   int REFERENCES post ON UPDATE CASCADE ON DELETE CASCADE
, PRIMARY KEY (post_id, person_id)
);

বিশেষত নোট করুন যে কোনও পোস্টে অবশ্যই একজন লেখক ( NOT NULL) থাকতে হবে, যখন পছন্দগুলির অস্তিত্ব isচ্ছিক। বিদ্যমান লাইক জন্য অবশ্য postএবং person আবশ্যক উভয় রেফারেন্সড করা (দ্বারা জারি PRIMARY KEYউভয় কলাম তোলে NOT NULLস্বয়ংক্রিয়ভাবে (আপনি স্পষ্টভাবে এই সীমাবদ্ধতার যোগ পারে, redundantly) যাতে বেনামী লাইক এছাড়াও অসম্ভব হয়।

এন: মি বাস্তবায়নের জন্য বিশদ:

পোস্টগ্রেএসকিউএল-তে একাধিক থেকে অনেকের সম্পর্ক কীভাবে কার্যকর করা যায়?

স্ব-পছন্দ প্রতিরোধ করুন

আপনি আরও লিখেছেন:

(তৈরি ব্যক্তি নিজের পোস্ট পছন্দ করতে পারে না)।

এটি উপরের বাস্তবায়নে এখনও প্রয়োগ করা হয়নি। আপনি একটি ট্রিগার ব্যবহার করতে পারে ।
বা এই দ্রুত / আরও নির্ভরযোগ্য সমাধানগুলির মধ্যে একটি:

একটি ব্যয়ের জন্য রক-সলিড

এটা হতে দরকার হয় তবে শিলা কঠিন , আপনার কাছ থেকে এফ কে প্রসারিত পারে likesথেকে postঅন্তর্ভুক্ত করা author_idredundantly। তারপরে আপনি সাধারণ CHECKবাধা দিয়ে অজাচারকে অস্বীকার করতে পারেন ।

CREATE TABLE likes (
  person_id int REFERENCES person ON UPDATE CASCADE ON DELETE CASCADE
, post_id   int 
, author_id int NOT NULL
, CONSTRAINT likes_pkey PRIMARY KEY (post_id, person_id)
, CONSTRAINT likes_post_fkey FOREIGN KEY (author_id, post_id)
     REFERENCES post(author_id, post_id) ON UPDATE CASCADE ON DELETE CASCADE
, CONSTRAINT no_self_like CHECK (person_id <> author_id)
);

এই প্রয়োজন একটি অন্যথায় এছাড়াও অপ্রয়োজনীয় UNIQUEমধ্যে বাধ্যতা post:

ALTER TABLE post ADD CONSTRAINT post_for_fk_uni UNIQUE (author_id, post_id);

আমি সেখানে থাকা অবস্থায় একটি দরকারী সূচক সরবরাহauthor_id করতে প্রথমে রেখেছি ।

আরও সঙ্গে সম্পর্কিত উত্তর:

"দুটি টেবিল দূরে" সীমাবদ্ধতা প্রয়োগ করছে

একটি `CHECK`সীমাবদ্ধতা সহ সস্তা

উপরের "বেসিক বাস্তবায়ন" এর উপর বিল্ডিং।

CHECKপ্রতিবন্ধকতা অপরিবর্তনীয় বোঝানো হয়। একটি চেকের জন্য অন্যান্য সারণিগুলি উল্লেখ করা কখনই অপরিবর্তনীয় নয়, আমরা ধারণাটি এখানে কিছুটা আপত্তি করছি। আমি NOT VALIDসঠিকভাবে প্রতিফলিত করতে সীমাবদ্ধতা ঘোষণা করার পরামর্শ দিই । বিবরণ:

ডাম্প পুনরুদ্ধার করার সময় সমস্ত সীমাবদ্ধতা এবং টেবিল চেকগুলি অক্ষম করুন

CHECKএই বিশেষ ক্ষেত্রে একটি সীমাবদ্ধতা যুক্তিসঙ্গত বলে মনে হয়, কারণ কোনও পোস্টের লেখক এমন একটি বৈশিষ্ট্যের মতো লাগে যা কখনও পরিবর্তন হয় না। নিশ্চিত হতে সেই ক্ষেত্রের আপডেটগুলি বাতিল করুন।

আমরা একটি ফাংশন জালIMMUTABLE :

CREATE OR REPLACE FUNCTION f_author_id_of_post(_post_id int)
  RETURNS int AS
'SELECT p.author_id FROM public.post p WHERE p.post_id = $1'
LANGUAGE sql IMMUTABLE;

আপনার টেবিলগুলির আসল স্কিমা দিয়ে 'সর্বজনীন' প্রতিস্থাপন করুন।
এই CHECKসীমাবদ্ধতার মধ্যে এই ফাংশনটি ব্যবহার করুন :

ALTER TABLE likes ADD CONSTRAINT no_self_like_chk
   CHECK (f_author_id_of_post(post_id) <> person_id) NOT VALID;

— এরউইন ব্র্যান্ডস্টেটার
সূত্র

4

আমি মনে করি আপনি কীভাবে আপনার ব্যবসায়ের বিধি বর্ণনা করেছেন সেজন্য এটি নির্ধারণ করতে আপনার অসুবিধা হচ্ছে।

মানুষ এবং পোস্টগুলি "অবজেক্ট"। যেমন একটি ক্রিয়াপদ হয়।

আপনার সত্যিই মাত্র 2 টি ক্রিয়া রয়েছে:

একজন ব্যক্তি এক বা একাধিক পোস্ট তৈরি করতে পারেন
অনেক ব্যক্তি অনেক পোস্ট পছন্দ করতে পারেন। (আপনার শেষ 2 বিবৃতি সংকলন)

"পছন্দগুলি" সারণীতে প্রাথমিক কী হিসাবে ব্যক্তি_যুক্ত এবং পোস্ট_আইড থাকবে।

— নিকোলাস ডি ফন্টেনে
সূত্র

কীভাবে 3 টেবিলের মধ্যে একটি চক্রীয় নির্ভরতা (বৃত্তাকার রেফারেন্স) এড়ানো যায়?