ডাটাবেস মডেলিং করার সময় আমাদের কখন দুর্বল সত্তাগুলি ব্যবহার করা উচিত?

Question

এটি মূলত দুর্বল সত্তা কী সম্পর্কে একটি প্রশ্ন? আমাদের কখন তাদের ব্যবহার করা উচিত? তাদের কীভাবে মডেল করা উচিত?

সাধারণ সত্তা এবং দুর্বল সত্তার মধ্যে প্রধান পার্থক্য কী? ডোমেন চালিত ডিজাইন করার সময় কি দুর্বল সত্তাগুলি মান অবজেক্টের সাথে মিল রাখে?

প্রশ্নে এখানে বিষয়টিকে ধরে রাখতে সহায়তা করা উইকিপিডিয়া থেকে নেওয়া একটি উদাহরণ যা এই প্রশ্নগুলির উত্তর দেওয়ার জন্য লোকেরা ব্যবহার করতে পারে:

এই উদাহরণে OrderItemদুর্বল সত্তা হিসাবে মডেল করা হয়েছিল, তবে কেন এটি সাধারণ সত্তা হিসাবে মডেল করা যায় না তা আমি বুঝতে পারি না।
আর একটি প্রশ্ন হ'ল আমি যদি আদেশের ইতিহাস ট্র্যাক করতে চাই (তবে এটির স্থিতির পরিবর্তনগুলি) কি এটি একটি সাধারণ বা দুর্বল সত্তা?

Answer 1

সাধারণত "দুর্বল" সত্তার নিম্নলিখিত বৈশিষ্ট্য রয়েছে।

1.  It is existence-dependent on another entity, i.e., 
    it cannot exist without the entity with which it has a relationship.

2.  It inherits at least part of it's primary key from the entity to which 
    it is related. 


    i.e. -> A weak entity's primary key must be a composite key that includes 
       the primary key of the entity on which it is existence-dependent.

আমি বলব যে বাস্তবে আপনি প্রতি সেটের জন্য কোনও কিছুকে "দুর্বল" সত্তা তৈরি করার সিদ্ধান্ত নেবেন না ; আপনি পরিবর্তে তথ্যকে মডেল করার চেষ্টা করছেন তার প্রতিনিধিত্ব করার জন্য ডেটা গঠন করবেন। যদি আপনি এটি করার পরে, আপনি কোনও নির্দিষ্ট সত্তার দিকে নজর দেন এবং এটিতে কোনও "দুর্বল" সত্তার বৈশিষ্ট্য রয়েছে, আপনি কোনও কারণে এটি স্পষ্টভাবে কল করতে বা প্রয়োজনের জন্য বোধ করেন তবে সেই অনুযায়ী আপনি এটি ডকুমেন্ট বা ডায়াগ্রাম করতে পারেন if আনুষ্ঠানিকতা।

Comments

হুমমম তাহলে আমার উদাহরণটা কী? এখানে OrderItemউপর নির্ভরশীল Orderকোন orderItemsএকটি একাত্মতার ছাড়া উপস্থিত করতে order, কিন্তু আমি দেখতে পারছি না কেন আমি ব্যবহার করতে পারবেন না ItemLineNumberএকমাত্র একটি আইটেম সনাক্ত করতে ?! আসলে আমি স্বতন্ত্রতার জন্য বীমা ItemLineNumberতৈরি করতে একটি অটো তৈরি intকরতে পারি এবং orderIDদুটি সত্তাকে একসাথে যুক্ত করার জন্য একটি বিদেশী কী ব্যবহার করতে পারি ?!

— সানগো

যদি আপনি নিজের অর্ডার আইটেমটিকে একটি অনন্যভাবে চিহ্নিত সিক্যুয়াল আইডির জন্য সংজ্ঞায়িত করেন এবং অর্ডারআইড কীটির অংশ না হয় তবে আপনি অর্ডার আইটেমগুলি প্রথম অর্ডার নাগরিক হিসাবে বিবেচনা করছেন এবং সত্যই কোনও দুর্বল সত্তা নেই। আপনি চাইলে অন্য টেবিলগুলি পৃথকভাবে অর্ডারআইটেমগুলিতে এফকে করতে পারেন; অর্ডারআইটেমগুলি পেতে ইতোমধ্যে একটি অর্ডারআইড থাকা অপ্রয়োজনীয়। অন্যদিকে আপনি যদি অর্ডারআইডির সাথে অর্ডার আইটেম এবং অর্ডারের সাথে সম্পর্কিত একটি সিকোয়েন্সআইড (বা অনুরূপ) কীড করেন তবে আপনার দুর্বল সত্তা থাকবে এবং স্বতন্ত্র লাইন আইটেমগুলি কেবল অর্ডারআইডি এবং সিকোয়েন্সআইডি ব্যবহার করে উল্লেখযোগ্য হবে। উদ্দেশ্য হিসাবে মডেল ব্যবহার।

— এড হেস্টিংস

এছাড়াও, একটি স্পর্শকাতর মন্তব্য, এটি প্রতিটি টেবিলকে তার নিজস্ব অনুক্রমিক প্রাথমিক কী দিতে এবং একক ক্ষেত্রের পিকে-> এফকে সম্পর্কগুলির সাথে সম্পর্কগুলি যতটা সম্ভব সহজ রাখা খুব লোভনীয় হতে পারে। এটি বিশেষত সাধারণ ডাটাবেসের জন্য দুর্দান্ত এবং এটির পক্ষে যুক্তি করা সহজ। যাইহোক, যখন আরও জটিল এবং / বা পরিশীলিত সম্পর্কের সংমিশ্রণ কীগুলি মডেলিং করা যায় তখন খুব দরকারী হয়ে ওঠে এবং আপনাকে মডেল বাছাইয়ের আরও বিকল্প দেয়।

— এড হেস্টিংস

Answer 2

একটি OrderItemএকটি আদেশ অথবা একটি পণ্য ছাড়া উপস্থিত হতে পারবেন না। সুতরাং এটি দুর্বল যেহেতু এটি নির্ভরতাগুলি নিয়ন্ত্রণ করে।

যদি আপনি উদাহরণস্বরূপ অর্ডারটি সরিয়ে থাকেন তবে আইটেমটি কোথায় পাঠানো উচিত তা আপনার জানার কোনও উপায় নেই। অথবা আপনি যদি পণ্যটি সরিয়ে থাকেন তবে কী শিপিং করবেন তা আপনি জানেন না।

Answer 3

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

ইআর ডায়াগ্রাম ব্যবসায়ের প্রয়োজনীয়তা অনুসারে ডিজাইন করা উচিত।

Answer 4

দেখুন, একটি আদেশে অনেকগুলি অর্ডার আইটেম রয়েছে (মাল্টিভ্যালুইড অ্যাট্রিবিউট)। এইভাবে নিয়ম অনুসারে আমরা আলাদা টেবিল তৈরি করি।

এখন, ধরা যাক 2 গ্রাহকের একই অর্ডার রয়েছে e উভয়ই একই দাম, ছাড়, একই তারিখ ইত্যাদিতে আইফোন কিনে। সুতরাং আদর্শভাবে অর্ডারটাইম সম্পর্কের ক্ষেত্রে আইফোনের ক্রমের জন্য দুটি সঠিক টিপল থাকতে হবে। তবে কোনও সম্পর্কের সীমাবদ্ধতা অনুসারে, সমস্ত টিপলগুলি অনন্য হওয়া উচিত। সুতরাং এখন পর্যন্ত একই আইটেম_লাইন_নম্বরের কোন সমস্যায় দুটি অর্ডার সম্পর্কিত করা যাক। এখন গ্রাহকের একটি বাতিল বিবেচনা করুন। আইফোনের অর্ডারও রয়েছে আইটেম_লাইন_বারের টিপল মুছে ফেলা হবে। এখন অন্য গ্রাহকরা যারা আইফোন কিনেছেন তারাও এম: 1 এর চিঠিপত্রের কারণে মোছা হয়ে যায়। সুতরাং শেষ পর্যন্ত ডাটাবেসটি অসঙ্গতিপূর্ণ। এজন্য আমরা একটি ডেস্ক্রিপ্টর কী ব্যবহার করব যা অর্ডার হবে ordered কোনও আদেশ দেওয়া আইফোন মোছার ফলে ডাটাবেস দুর্নীতি হয় না।