হায়ারার্কিক্যাল ডাটাবেস মডেল কী?
হায়ারার্কিক্যাল মডেল ডেটাকে ট্রি-লাইক স্ট্রাকচারে রিপ্রেজেন্ট করে যেখানে প্রতিটি রেকর্ডের জন্য একটি একক পেরেন্ট থাকে। অর্ডার মেইনটেইন করতে একটি সর্ট ফিল্ড থাকে যা সিবলিং নোডকে রেকর্ডেড মানরে রাখে। এই মডেলগুলো মূলত আর্লি মেইনফ্রেম ডাটাবেস ম্যানেজমেন্ট সিস্টেমের জন্য ডিজাইন করা হয়েছিল, যেমন IBM-এর Information Management System (IMS)।
এই মডেল স্ট্রাকচার দুটি/বিভিন্ন টাইপের ডেটার মধ্যে One-to-One এবং One-to-Many রিলেশনশিপ অনুমতি দেয়। এটি রিয়েল ওয়ার্ল্ডের অনেক রিলেশনশিপ বর্ণনা করতে খুব সহায়ক: টেবিল অফ কন্টেন্টস, নেস্টেড ও সর্টেড ইনফরমেশন।
হায়ারার্কিক্যাল স্ট্রাকচার স্টোরেজে রেকর্ডের ফিজিক্যাল অর্ডার হিসেবে ব্যবহৃত হয়। পয়েন্টার এবং সিকোয়েনশিয়াল অ্যাক্সেস কাম্বাইন করে ডেটা স্ট্রাকচারে নেভিগেট করে রেকর্ড অ্যাক্সেস করা যায়। তাই যখন প্রতিটি রেকর্ডের জন্য ফুল পাথ অন্তর্ভুক্ত নয়, তখন কিছু ডাটাবেস অপারেশনের জন্য এই স্ট্রাকচার উপযুক্ত নয়।
এই টাইপের ডাটাবেসে ডেটা হায়ারার্কিক্যালি স্ট্রাকচারড থাকে এবং সাধারণত একটি ইনভার্টেড ট্রি হিসেবে ডেভেলপ করা হয়। স্ট্রাকচারের "root" হলো ডাটাবেসে একটি সিঙ্গেল টেবিল এবং অন্যান্য টেবিল রুট থেকে বাহির হওয়া ব্রাঞ্চের মতো কাজ করে। নিচের ডায়াগ্রাম একটি টিপিক্যাল হায়ারার্কিক্যাল ডাটাবেস স্ট্রাকচার দেখাচ্ছে।
Agents Database (এজেন্ট ডাটাবেস)
উপরোক্ত ডায়াগ্রামে, একটি এজেন্ট একাধিক এন্টারটেইনার বুক করে, এবং প্রতিটি এন্টারটেইনার আবার তার নিজের শিডিউল রাখে। এজেন্টের কর্তব্য একাধিক ক্লায়েন্ট মেইনটেইন করা যাদের এন্টারটেইনমেন্ট প্রয়োজন। ক্লায়েন্ট এজেন্টের মাধ্যমে এনগেজমেন্ট বুক করে এবং তার সার্ভিসের জন্য পেমেন্ট করে।
এই ডাটাবেস মডেলে একটি রিলেশনশিপ পেরেন্ট/চাইল্ড টার্ম দ্বারা রিপ্রেজেন্ট করা হয়। একটি পেরেন্ট টেবিল এক বা একাধিক চাইল্ড টেবিলের সাথে লিঙ্ক করা যাবে, কিন্তু একটি একক চাইল্ড টেবিল শুধু একটি পেরেন্ট টেবিলের সাথে লিঙ্ক করা যাবে। টেবিলগুলো স্পষ্টভাবে পয়েন্টার/ইন্ডেক্স বা টেবিলের মধ্যে রেকর্ডের ফিজিক্যাল অ্যারেঞ্জমেন্ট দ্বারা লিঙ্কড থাকে।
একজন ব্যবহারকারী রুট টেবিল থেকে শুরু করে ট্রিয়ের নিচে টার্গেট ডেটা পর্যন্ত নেভিগেট করে ডেটা অ্যাক্সেস করতে পারে। ব্যবহারকারীকে ডাটাবেস স্ট্রাকচার ভালোভাবে জানতে হয় যাতে জটিলতা ছাড়া ডেটা অ্যাক্সেস করা যায়।
সুবিধা
- টেবিল স্ট্রাকচারের মধ্যে স্পষ্ট লিঙ্ক থাকায় ব্যবহারকারী খুব দ্রুত ডেটা রিট্রিভ করতে পারে।
- রেফারেনশিয়াল ইন্টিগ্রিটি বিল্ট-ইন এবং স্বয়ংক্রিয়ভাবে এনফোর্সড থাকে। ফলে চাইল্ড টেবিলের একটি রেকর্ড অবশ্যই পেরেন্ট টেবিলের একটি এক্সিস্টিং রেকর্ডের সাথে লিঙ্কড থাকতে হবে। পেরেন্ট টেবিলে রেকর্ড ডিলিট হলে সমস্ত অ্যাসোসিয়েটেড চাইল্ড রেকর্ডও ডিলিট হয়ে যায়।
অসুবিধা
- যখন একজন ব্যবহারকারী একটি চাইল্ড টেবিলে রেকর্ড স্টোর করতে চায় যা বর্তমানে কোনো পেরেন্ট টেবিল রেকর্ডের সাথে রিলেটেড নয়, তখন রেকর্ডিংয়ে সমস্যা হয় এবং ব্যবহারকারীকে পেরেন্ট টেবিলে একটি অডিশনাল এন্ট্রি করতে হয়।
- এই টাইপের ডাটাবেস জটিল রিলেশনশিপ সাপোর্ট করতে পারে না, এবং রিডান্ডেন্সি সমস্যাও থাকে যা ইনকনসিস্টেন্ট রেকর্ডিংয়ের কারণে ভুল বা পুরনো তথ্য সৃষ্টি করতে পারে।
পূর্বের ডায়াগ্রামের ডাটাবেস ডায়াগ্রাম ব্যবহার করে একটি উদাহরণ বিবেচনা করুন। একজন ব্যবহারকারী Entertainers টেবিলে এন্টারটেইনার জন্য নতুন রেকর্ড ইনসার্ট করতে পারবে না যতক্ষণ না এন্টারটেইনার Agents টেবিলে একটি নির্দিষ্ট এজেন্টের অধীনে অ্যাসাইন করা হয়, কারণ চাইল্ড টেবিল (Entertainers) এর একটি রেকর্ড অবশ্যই পেরেন্ট টেবিল (Agents) এর একটি রেকর্ডের সাথে রিলেটেড হতে হবে। তাই এই টাইপের ডাটাবেস রিডান্ডেন্ট ডেটা সমস্যা থেকে গ্রস্ত। উদাহরণস্বরূপ, যদি ক্লায়েন্ট এবং এন্টারটেইনার মধ্যে Many-to-Many রিলেশনশিপ থাকে; একটি এন্টারটেইনার অনেক ক্লায়েন্টের জন্য পারফর্ম করবে, এবং একটি ক্লায়েন্ট অনেক এন্টারটেইনার হায়ার করবে। এই ধরনের রিলেশনশিপ হায়ারার্কিক্যাল ডাটাবেসে সহজে মডেল করা যায় না, তাই ডেভেলপাররা Schedule এবং Engagements টেবিলে রিডান্ডেন্ট ডেটা ঢুকাতে বাধ্য হয়।
- Schedule টেবিলে এখন ক্লায়েন্ট ডেটা থাকবে যাতে ক্লায়েন্ট নাম, ঠিকানা, ফোন নম্বর থাকে যেন প্রতিটি এন্টারটেইনার কে জন্য এবং কোথায় পারফর্ম করছে তা দেখা যায়। এই ডেটা রিডান্ডেন্ট কারণ এটি Clients টেবিলেও সংরক্ষিত আছে।
- Engagements টেবিলে এখন এন্টারটেইনার ডেটা থাকবে যাতে এন্টারটেইনার নাম, ফোন নম্বর, টাইপ থাকে যেন কোনো এন্টারটেইনার কোনো ক্লায়েন্টের জন্য পারফর্ম করছে তা ইন্ডিকেট করে। এই ডেটাও রিডান্ডেন্ট কারণ এটি Entertainers টেবিলে সংরক্ষিত আছে।
এই রিডান্ডেন্সির সমস্যা হলো এটি ভুল তথ্য সৃষ্টি করতে পারে কারণ এটি একটি একক ডেটা ইনকনসিস্টেন্টলি ইনসার্ট করার সম্ভাবনা খুলে দেয়।
এই সমস্যা সমাধান করতে একটি হায়ারার্কিক্যাল ডাটাবেস স্পেসিফিকালি এন্টারটেইনার জন্য এবং অন্যটি স্পেসিফিকালি এজেন্টের জন্য তৈরি করা যেতে পারে। Entertainers ডাটাবেসে শুধু Entertainers টেবিলের ডেটা থাকবে, এবং রিভাইজড Agents ডাটাবেসে Agents, Clients, Payments, এবং Engagements টেবিলের ডেটা থাকবে। লজিক্যাল চাইল্ড রিলেশনশিপ ডিফাইন করে Agents ডাটাবেসের Engagements টেবিল এবং Entertainers ডাটাবেসের Entertainers টেবিলের মধ্যে সম্পর্ক স্থাপন করা যাবে। এই রিলেশনশিপ inplace থাকলে আপনি বিভিন্ন ইনফরমেশন রিট্রিভ করতে পারবেন, যেমন একটি দেয়া ক্লায়েন্টের জন্য বুকড এন্টারটেইনার লিস্ট বা একটি দেয়া এন্টারটেইনারের পারফরম্যান্স শিডিউল। নিচের ডায়াগ্রাম পুরো চিত্র বর্ণনা করছে।
হায়ারার্কিক্যাল ডাটাবেস ১৯৭০-এর দশকে মেইনফ্রেমের द्वारा ব্যবহৃত টেপ স্টোরেজ সিস্টেমের জন্য খুব উপযুক্ত ছিল এবং সেসিস্টেমে ভিত্তিক সংস্থাগুলোতে খুব জনপ্রিয়। কিন্তু, যদিও হায়ারার্কিক্যাল ডাটাবেস দ্রুত এবং ডায়রেক্ট ডেটা অ্যাক্সেস প্রদান করত এবং বেশ কিছু পরিস্থিতিতে উপযোগী ছিল, তবুও স্পষ্ট হয়ে গেলো যে ডেটা রিডান্ডেন্সি এবং ডেটার মধ্যে জটিল রিলেশনশিপের বড় होती সমস্যা সমাধান করতে একটি নতুন ডাটাবেস মডেল দরকার।
এই ডাটাবেস মডেলের আকর্ষণ নির্দিষ্ট টাইপের ডেটা স্টোরেজের জন্য উপযোগী, কিন্তু এটি অত্যন্ত versatile নয় এবং কিছু নির্দিষ্ট ব্যবহারের মধ্যে সীমাবদ্ধ।
উদাহরণস্বরূপ, যেখানে একটি কোম্পানির প্রতিটি ব্যক্তি একটি দেয়া ডিপার্টমেন্টে রিপোর্ট করতে পারে, সেখানে ডিপার্টমেন্টকে পেরেন্ট রেকর্ড হিসেবে ব্যবহার করা যাবে এবং প্রতিটি কর্মী সেকেন্ডারি রেকর্ড হিসেবে কাজ করবে, যারা সিঙ্গেল পেরেন্ট রেকর্ডের সাথে লিঙ্কড থাকবে একটি হায়ারার্কিক্যাল স্ট্রাকচারে।
