৩০ আগ, ২০২৫·8 মিনিট
এডগার এফ. কড্ডের রিলেশনাল মডেল: কেন এসকিউএল ব্যবসা জিতল
জানুন কিভাবে এডগার এফ. কড্ডের রিলেশনাল মডেল ডেটাকে টেবিল, কী এবং নিয়মে রূপান্তর করল—এবং কীভাবে এটি এসকিউএল ডাটাবেসকে ব্যবসায়িক অ্যাপ চালানোর পথে নিয়ে এল।
জানুন কিভাবে এডগার এফ. কড্ডের রিলেশনাল মডেল ডেটাকে টেবিল, কী এবং নিয়মে রূপান্তর করল—এবং কীভাবে এটি এসকিউএল ডাটাবেসকে ব্যবসায়িক অ্যাপ চালানোর পথে নিয়ে এল।
সরলভাবে, রিলেশনাল মডেল তথ্যকে টেবিল (কড্ড যাকে “relations” বলতেন) হিসাবে সংরক্ষণ করে এবং শেয়ার করা মানের মাধ্যমে সেগুলোকে লিঙ্ক করা যায়।
একটি টেবিল হলো সুসজ্জিত গ্রিড:
ব্যবসায় ডেটা বিচ্ছিন্নভাবে রাখা হয় না। একটি বিক্রয় জড়িত থাকে কাস্টমার, পণ্য, দাম, বিক্রেতা এবং তারিখ—প্রতিটি ভিন্ন গতিতে বদলে যায় এবং বিভিন্ন দলের মালিকানায় থাকে। প্রারম্ভিক সিস্টেমগুলো প্রায়শই এই ডিটেইলগুলোকে কঠোরভাবে জোড়া-কাটা স্ট্রাকচারে রাখত, যা পরিবর্তন করা কঠিন করেছিল। রিপোর্টিং ধীর, পরিবর্তন ঝুঁকিপূর্ণ, এবং “সরল প্রশ্ন” অপ্রত্যাশিতভাবে ব্যয়বহুল ছিল।
রিলেশনাল মডেল একটি পরিষ্কার পথ দেখায়: ভিন্ন ধারণার জন্য আলাদা টেবিল রাখুন, তারপর প্রয়োজন হলে সেগুলোকে সংযুক্ত করুন। প্রতিটি ইনভয়েস রেকর্ডে কাস্টমারের সব বিবরণ বারবার কপি করার বদলে, কাস্টমারকে একবার সংরক্ষণ করে ইনভয়েস থেকে রেফারেন্স করুন। এতে বিরোধ কমে (একই কাস্টমারের ভিন্ন বানান) এবং আপডেট করা অনেক বেশি প্রত্যাশাযোগ্য হয়।
ভালভাবে সংজ্ঞায়িত টেবিল ও সংযোগের নিয়ম জোর দিয়ে মডেল একটি নতুন প্রত্যাশা স্থাপন করল: ডাটাবেস যত বাড়বে ততই অসংগতিকে প্রতিরোধে সাহায্য করবে—বিশেষ করে যখন অনেক মানুষ এবং সিস্টেম লেখে।
কড্ডের মডেল নিজে কোনো কুয়েরি ভাষা ছিল না, কিন্তু এটা একটি ভাষার অনুপ্রেরণা দিয়েছিল। যদি ডেটা সম্পর্কিত টেবিলগুলোতে থাকে, আপনাকে দরকার একটি স্ট্যান্ডার্ড উপায়:
এই পথই নিয়ে গেল SQL-এ, যা মডেলটিকে ব্যবহারিক করে তুলল যাতে প্রতিদিনের টিমগুলো ব্যবসায়িক ডেটার ওপর প্রশ্ন করতে পারে এবং পুনরাবৃত্ত, অডিটেবল উত্তর পেতে পারে।
রিলেশনাল মডেলের আগেও অনেক প্রতিষ্ঠান গুরুত্বপূর্ণ তথ্য ফাইল-এ রাখত—প্রতিটি অ্যাপ্লিকেশনের জন্য আলাদা ফাইল। পে-রোলের আলাদা রেকর্ড, ইনভেন্টরির আলাদা, কাস্টমার সার্ভিসের আলাদা “কাস্টমার”—প্রতিটি সিস্টেম বিচ্ছিন্নভাবে কাজ করত, এবং সেই বিচ্ছিন্নতা পূর্বাভাসযোগ্য কষ্ট তৈরি করত।
প্রারম্ভিক ডেটা প্রসেসিং সাধারণত কাস্টম ফাইল ফর্ম্যাট এবং একক উদ্দেশ্যের জন্য লেখা প্রোগ্রামের চারপাশে তৈরি হত। ডেটার কাঠামো (প্রতিটি ফিল্ড কোথায় থাকে, রেকর্ড কীভাবে সাজানো) সেই কোডের সঙ্গে কড়াভাবে জড়িত থাকত। এর মানে ছোট একটি পরিবর্তন—একটি নতুন ফিল্ড যোগ করা, পণ্যের ক্যাটাগরি নাম পরিবর্তন—হোক সবকিছুতে একাধিক প্রোগ্রাম পুনরায় লেখা লাগত।
কারণ দলগুলো সহজে একটি একক উৎস শেয়ার করতে পারত না, তারা ডেটা কপি করত। কাস্টমারের ঠিকানা বিক্রয় ফাইল, শিপিং ফাইল, বিলিং ফাইলে থাকতে পারত।
একটি ঠিকানা বদলে গেলে প্রতিটি কপিতে আপডেট দরকার। যদি কোনো সিস্টেম বাদ পড়ে যায়, অসংগতি দেখা দেয়: ইনভয়েস ভুল জায়গায় যায়, শিপমেন্ট বিলম্বিত হয়, এবং সাপোর্ট এজেন্টরা দেখতে পায় ভিন্ন “তথ্য” বিভিন্ন স্ক্রিনে। ডেটা ক্লীনআপ এককালীন কাজ না থেকে নিয়মিত প্রকল্পে পরিণত হয়।
ব্যবসায়িক ব্যবহারকারীরাও প্রশ্ন করত—“কোন কাস্টমাররা পণ্য X কিনেছিল এবং পরে রিটার্ন করেছে?”—কিন্তু উত্তর পাওয়ার জন্য ফাইলগুলোকে হাতে-কলমে জোড়া লাগত। দলগুলো প্রায়শই একশ ব্যচ্ছিন্ন রিপোর্টিং এক্সট্রাক্ট তৈরি করত, যা আরও কপি ও মিসম্যাচের সুযোগ দেয়।
ফলাফল: রিপোর্টিং সাইকেল ধীর ছিল, এবং “দ্রুত প্রশ্ন” ইঞ্জিনিয়ারিং কাজ হয়ে পড়ত।
সংগঠনগুলো প্রয়োজন করত এমন শেয়ার করা ডেটা যা একাধিক অ্যাপ্লিকেশন নির্ভর করতে পারে, কম অসংগতি ও কম ডুপ্লিকেট প্রচেষ্টা নিয়ে। পাশাপাশি তারা চাইত এমন উপায় যাতে নতুন প্রশ্ন করা যায় বিনা রিকনস্ট্রাকশন। সেই ফাঁকেই কড্ডর মূল ধারণা জন্ম নিল: ডেটা নির্ভরযোগ্য, অ্যাপ-নিরপেক্ষ ভাবে সংজ্ঞায়িত করুন, যেন সিস্টেমগুলো ভাঙা ছাড়াই বিকশিত হতে পারে।
এডগার এফ. কড্ড ছিলেন একজন ব্রিটিশ কম্পিউটার বিজ্ঞানী, যিনি বেশিরভাগ কেরিয়ার IBM-এ কাটিয়েছেন এবং তথ্য সংরক্ষণ ও পুনরুদ্ধারের উপায় নিয়ে কাজ করেছেন। 1960-এ দশকে বেশিরভাগ “ডাটাবেস” সিস্টেম ছিল সাবধানভাবে পরিচালিত ফাইল ক্যাবিনেটের মতো: ডেটা কড়া, প্রি-ডিফাইন্ড স্ট্রাকচারে ছিল, এবং সেই স্ট্রাকচার পরিবর্তন করলে অ্যাপ্লিকেশনগুলো প্রায়ই পুনরায় লেখার দরকার হতো। সেই ভঙ্গুরতা টিমগুলোর হতাশা সৃষ্টি করত কারণ ব্যবসা বাড়ছিল এবং চাহিদা বদলাচ্ছিল।
1970 সালে কড্ড একটি পেপার প্রকাশ করেছিলেন—“A Relational Model of Data for Large Shared Data Banks”—যা একটি চমকপ্রদ সরল ধারণা দিল: ডেটা সম্পর্কিত টেবিল হিসেবে উপস্থাপন করুন এবং এগুলোকে কুয়েরি ও মিলানোর জন্য একটি ফর্মাল অপারেশন সেট ব্যবহার করুন।
উপরোক্ত স্তরে পেপারটি যুক্তি করেছিল যে:
কড্ড তার প্রস্তাবকে গাণিতিকভাবে (সেট থিওরি ও লজিক) ভিত্তি দিয়েছিলেন। এটা কেবল একাডেমিক শান নয়—এটি ডাটাবেস ডিজাইনের জন্য স্পষ্ট, পরীক্ষাযোগ্য ভিত্তি দিল। একটি ফর্মাল মডেল থাকলে আপনি যুক্তি করতে পারেন কোন কুয়েরি ঠিক, কোন দুটি কুয়েরি সমতুল্য, এবং কীভাবে এক্সিকিউশন অপটিমাইজ করা যাবে ফলাফল না বদলে করে। ব্যবসায়িক সফটওয়্যারের জন্য এটার অর্থ হলো সিস্টেম স্কেল করলে ও বিকশিত হলে কম আজব ঝামেলা।
সেই সময় অনেক সিস্টেম নির্ভর করত হায়ারার্কিকাল বা নেটওয়ার্ক মডেলে যেখানে ডেভেলপাররা নির্দিষ্ট পথ ধরে ডেটা “নেভিগেট” করতেন। কড্ড বললেন ডাটাবেসই ভারি কাজটা করতে হবে। অ্যাপ্লিকেশনগুলোর উচিত স্টোরেজ লেআউট জানা নয়; তারা চাওয়া ফলাফল বর্ণনা করুক, আর ডাটাবেস দক্ষ উপায়ে তা তৈরি করুক।
এই কনসেপ্ট আলাদা দায়িত্ব বন্টন করল এবং SQL এবং এমন ডাটাবেসের মঞ্চ সাজাল যা বছরের পর বছর চাহিদা বদলানোর সঙ্গে বাঁচতে পারে।
কড্ডের রিলেশনাল মডেল একটি সরল ধারণা দিয়ে শুরু করে: তথ্য রিলেশন-এ সংরক্ষণ করুন—যা অধিকাংশ মানুষ টেবিল হিসেবে চিনতে অভ্যস্ত—কিন্তু এগুলোকে “স্মার্ট স্প্রেডশীট” হিসেবে না দেখে ডেটা বর্ণনা করার একটি নির্দিষ্ট উপায় হিসেবে বিবেচনা করুন। একটি রিলেশন হলো আপনার ব্যবসার যতথ্য—কাস্টমার, ইনভয়েস, পেমেন্ট, পণ্য, শিপমেন্ট—সম্পর্কিত বিবৃতি সেট।
একটি রিলেশন এক ধরনের ফ্যাক্ট প্যাটার্ন উপস্থাপন করে। উদাহরণ: একটি Orders রিলেশন বলতে পারে “একটি অর্ডারের একটি ID, একটি তারিখ, একটি কাস্টমার এবং একটি টোটাল আছে।” মূল পয়েন্ট হচ্ছে প্রতিটি রিলেশনের একটি স্পষ্ট মানে আছে, এবং প্রতিটি কলাম সেই মানের অংশ।
একটি সারি (কড্ড যাকে টিউপল বলতেন) হলো সেই ফ্যাক্টের একটি নির্দিষ্ট উদাহরণ: একটি নির্দিষ্ট অর্ডার। রিলেশনাল মডেলে সারিগুলোর কোনো স্বতন্ত্র “অবস্থান” নেই—সারি ৫ বিশেষ নয়—জিনিসগুলোর মান ও তাদের নিয়মই গুরুত্বপূর্ণ।
একটি কলাম (একটি অ্যাট্রিবিউট) রিলেশনের একটি নির্দিষ্ট গুণ। যেমন OrderDate, CustomerID, TotalAmount। কলামগুলো শুধু লেবেল নয়; এগুলো নির্ধারণ করে কোন ধরনের মান গ্রহণ করা যাবে।
একটি ডোমেইন হলো একটি অ্যাট্রিবিউটের জন্য অনুমোদিত মানের সেট—যেমন OrderDate-এর জন্য তারিখ, TotalAmount-এর জন্য ধনাত্মক সংখ্যা, অথবা Status-এর জন্য একটি নিয়ন্ত্রিত কোড লিস্ট ( যেমন Pending, Paid, Refunded )। ডোমেইন অনিশ্চয়তা কমায় এবং সূক্ষ্ম ত্রুটি প্রতিরোধ করে, যেমন ভিন্ন ফরম্যাটের তারিখ বা "N/A" সংখ্যা ক্ষেত্রের ভিতরে রাখা।
“রিলেশনাল” নামটি নির্দেশ করে কিভাবে ফ্যাক্টগুলো রিলেশনগুলোর মধ্যে যুক্ত হতে পারে (যেমন কাস্টমার থেকে অর্ডার), যাতে বিলিং, রিপোর্টিং, অডিটিং, কাস্টমার সাপোর্ট সহ সাধারণ ব্যবসায়িক কাজগুলো পুনরাবৃত্তি ছাড়া করা যায়।
টেবিল নিজে উপকারী, কিন্তু ব্যবসায়িক ডেটা তখনই অর্থপূর্ন হয় যখন আপনি নির্ভরযোগ্যভাবে ফ্যাক্টগুলো সংযোগ করতে পারেন: কোন কাস্টমার কোন অর্ডার করেছে, কোন আইটেম সেগুলোতে ছিল, কত চার্জ করা হয়েছিল। কী-গুলো হল সেই মেকানিজম যা সেই সংযোগগুলো নির্ভরযোগ্য করে।
একটি প্রাইমারি কী হলো একটি কলাম (বা কলাম সেট) যার মান একটি সারিকে ইউনিকভাবে চিহ্নিত করে। এটাকে সারির “নেম ট্যাগ” ভাবুন। গুরুত্বপূর্ণ অংশ হলো স্থিতিশীলতা: নাম, ইমেইল, ঠিকানা বদলে যেতে পারে, কিন্তু একটি অভ্যন্তরীণ আইডি বদলানো উচিত নয়।
একটি ভালো প্রাইমারি কী ডুপ্লিকেট বা অস্পষ্ট রেকর্ড প্রতিরোধ করে। যদি দুই কাস্টমারের একই নাম থাকে, প্রাইমারি কী তাদের আলাদা করবে।
একটি ফরেইন কী একটি কলাম যা অন্য টেবিলের প্রাইমারি কী-কে সংরক্ষণ করে। এভাবেই সম্পর্কগুলো কপি না করে উপস্থাপিত হয়।
উদাহরণ মডেল:
ফরেইন কী কনস্ট্রেইন্ট গার্ডরেল হিসেবে কাজ করে। এগুলো প্রতিরোধ করে:
প্রায়োগিক দিক থেকে কী ও কনস্ট্রেইন্ট টিমগুলোকে রিপোর্ট ও ওয়ার্কফ্লো বিশ্বাস করার যোগ্য করে তোলে। যখন ডাটাবেস সম্পর্কগুলো প্রয়োগ করে, বিলিং, ফুলফিলমেন্ট এবং কাস্টমার সাপোর্টে কম বাগ ঢুকবে—কারণ ডেটা নিঃশব্দে অসম্ভব অবস্থা গ্রহণ করতে পারবে না।
নরমালাইজেশন রিলেশনাল মডেলের উপায় যাতে ডেটা বড় হয়ে গেলেও বিরোধে না পড়ে। যখন একই তথ্য একাধিক জায়গায় সংরক্ষণ করা হয়, একটি কপি আপডেট করা আর অন্যটি ভুল থেকে গেলে সমস্যা হয়। এটাই কিভাবে ইনভয়েসগুলো ভুল ঠিকানায় যায়, রিপোর্ট মেলেনা, বা একজন কাস্টমার এক স্ক্রিনে “inactive” আর অন্যে “active” দেখা যায়।
ব্যবহারিকভাবে, নরমালাইজেশন সাধারণ সমস্যাগুলো কমায়:
এছাড়া ইনসার্ট অ্যানোমালি (নতুন কাস্টমার যোগ করতে পারছ না যতক্ষণ তারা অর্ডার না করে) এবং ডিলিট অ্যানোমালি (শেষ অর্ডার মুছে দিলে একমাত্র কাস্টমার তথ্যও চলে যায়) এড়ানোও লক্ষ্য।
কঠোর তত্ত্ব ছাড়াই কয়েকটি মৌলিক ধারণা:
প্রথম নরমাল ফর্ম (1NF): প্রতিটি ফিল্ডকে অ্যাটোমিক রাখুন। যদি একজন কাস্টমারের একাধিক ফোন নম্বর থাকে, এক সেলে সেগুলো মিশাবেন না; আলাদা টেবিল বা আলাদা সারি ব্যবহার করুন।
সেকেন্ড নরমাল ফর্ম (2NF): যদি একটি টেবিলের পরিচয় একাধিক কলামের উপর নির্ভর করে (কম্পোজিট কি), নিশ্চিত করুন নন-কী ডিটেইলগুলো পুরো কী-র উপর নির্ভর করে। উদাহরণ: একটি অর্ডার লাইনে সেই লাইনের পরিমাণ ও দাম থাকা উচিত, কাস্টমার ঠিকানা নয়।
থার্ড নরমাল ফর্ম (3NF): পাশের তথ্য দূর করুন যা অন্য কোথাও থাকা উচিৎ। যদি একটি টেবিলে CustomerId এবং একই সাথে CustomerCity থাকে, সাধারনত সিটি কাস্টমার টেবিলে থাকা উচিত, প্রতিটি অর্ডারে কপি করা ঠিক নয়।
আরো নরমালাইজেশন সাধারণত বেশি টেবিল এবং বেশি JOIN মানে—এটা কনসিস্টেন্সি বাড়ায়, কিন্তু রিপোর্টিং জটিল করতে পারে এবং মাঝে মাঝে পারফর্ম্যান্স প্রভাব ফেলে। অনেক দল কোর এন্টিটিগুলোর জন্য 3NF লক্ষ্য করে (customers, products, invoices), তারপর পড়ার ভারি ড্যাশবোর্ডগুলোর জন্য পরিমাপ করে নির্বাচিতভাবে ডেনরমালাইজ করেন—তবে একটি অথরিটেটিভ সোর্স অফ ট্রুথ প্রাইমারি কী/ফরেইন কী দিয়ে বজায় রাখা হয়।
রিলেশনাল বীজগণিত হলো রিলেশনাল মডেলের পিছনে থাকা “গণিত”: ছোট কিন্তু নির্দিষ্ট অপারেশনগুলোর সেট যা একটি টেবিলকে অন্য একটি টেবিলে রূপান্তর করে।
এই নির্দিষ্টতা গুরুত্বপূর্ণ—নিয়ম যদি স্পষ্ট হয়, কুয়েরির ফলাফলও স্পষ্ট হয়। আপনি ভবিষ্যদ্বাণী করতে পারেন কোন সারি ফিল্টার হবে, কোন কলাম দেখানো হবে, এবং কিভাবে টেবিলগুলো মিলবে—অধিকারবিহীন আচরণ বা ম্যানুয়াল নেভিগেশনের উপর নির্ভর না করেই।
রিলেশনাল বীজগণিত এমন ব্লক সংজ্ঞায়িত করে যেগুলোকে মিলিয়ে বড় কুয়েরি গঠিত হয়। তিনটির উল্লেখযোগ্য:
Select: আপনি যেসব সারি চান সেগুলো বাছাই করুন।
উদাহরণ: “শুধুমাত্র গত মাসের অর্ডার” বা “শুধুমাত্র ফ্রান্সের কাস্টমার।” একই কলাম রেখে সারি কমানো।
Project: আপনি যেসব কলাম চান সেগুলো বাছাই করুন।
উদাহরণ: “কাস্টমারের নাম ও ইমেইল দেখান।” যথারীতি সারি একই (তাত্ত্বিকভাবে), কিন্তু অনাবশ্যক কলাম সরানো।
Join: বিভিন্ন টেবিল থেকে সম্পর্কিত তথ্য মিলান।
উদাহরণ: “প্রতিটি অর্ডারে কাস্টমার ডিটেইল যোগ করুন,” একটি শেয়ার করা শনাক্তকরণ (যেমন customer_id) ব্যবহার করে। আউটপুট একটি নতুন টেবিল যেখানে প্রতিটি সারি আলাদাভাবে সংরক্ষিত ফিল্ডগুলো একসাথে নিয়ে আসে।
ব্যবসায়িক ডেটা স্বভাবগতভাবে বিষয়ভিত্তিকভাবে বিভক্ত: কাস্টমার, অর্ডার, ইনভয়েস, পণ্য, পেমেন্ট। এই বিভাজন প্রতিটি তথ্য একবার সংরক্ষণ করতে সাহায্য করে (যা মিসম্যাচ কমায়), কিন্তু একই সময়ে উত্তর পেতে প্রায়শই সেগুলো পুনরায় মিলাতে হয়।
JOIN-ই সেই পুনরায় মিলানোর আনুষ্ঠানিক উপায়, অর্থ রক্ষা করে। কাস্টমারের নাম প্রতিটি অর্ডারে কপি করার বদলে, কাস্টমারকে একবার সংরক্ষণ করে রিপোর্টে JOIN করুন।
কারণ রিলেশনাল বীজগণিত সেট-ভিত্তিক অপারেশন হিসেবে সংজ্ঞায়িত, প্রতিটি ধাপের প্রত্যাশা স্পষ্ট:
এটাই ধারণাগত ঘাড় যেখানে পরে SQL ব্যবহারিকভাবে দাঁড়ালো: কুয়েরিগুলো নির্দিষ্ট রূপান্তরের সিকোয়েন্স হয়ে যায়, কেবলচাত্ত্বিক ডেটা ফেরত না এনে এলোমেলো ফেচ নয়।
কড্ডের রিলেশনাল মডেল কি বর্ণনা করেছিল তা হলো ডেটা কী (রিলেশন, কী, অপারেশন) — কিন্তু এইকে দিনের ব্যবহার উপযোগী করে তোলার জন্য একটি বন্ধুত্বপূর্ণ উপায় দরকার ছিল। SQL সেই ফাঁকটা পুরণ করল: রিলেশনাল ধারণাগুলোকে এমন একটি পাঠযোগ্য ভাষায় রূপান্তর করল যা বিশ্লেষক, ডেভেলপার এবং ডাটাবেস প্রোডাক্টগুলো ভাগ করতে পারে।
SQL রিলেশনাল বীজগণিতে অনুপ্রাণিত, কিন্তু এটি কড্ডের মূল তত্ত্বের নিখুঁত বাস্তবায়ন নয়।
একটি বড় পার্থক্য হলো SQL কীভাবে অনুপস্থিত বা অজানা মানকে (missing/unknown) আচরণ করে। ক্লাসিক রিলেশনাল তত্ত্ব দুই-মূল্যযুক্ত লজিকে (true/false) কাজ করে, আর SQL introduce করে NULL, ফলে তিন-মূল্যযুক্ত লজিক (true/false/unknown) আসে। আরেকটি পার্থক্য: রিলেশনাল তত্ত্ব সেটের সঙ্গে কাজ করে (ডুপ্লিকেট নেই), কিন্তু SQL টেবিল প্রায়শই duplicate rows অনুমোদন করে যদি না আপনি স্পষ্টভাবে রোধ করেন।
এই পার্থক্য সত্ত্বেও, SQL মূল প্রতিশ্রুতি বজায় রাখল: আপনি ফলাফল বর্ণনা করুন (ডিক্লেরেটিভ কুয়েরি), আর ডাটাবেস কার্যকর ধাপ নির্ধারণ করে।
কড্ড 1970-এ তার ভিত্তিপ্রস্তর পেপার প্রকাশ করলেন। 1970-এর দশকে IBM প্রাথমিক প্রোটোটাইপ (বিশেষত System R) তৈরি করেছিল যা দেখালো রিলেশনাল ডাটাবেস বাস্তবে পর্যাপ্ত দক্ষতা দেখাতে পারে এবং উচ্চ-স্তরের কুয়েরি ভাষাকে কার্যকর পরিকল্পনায় রূপান্তর করা যায়।
একই সময়ে একাডেমিয়া ও বানিজ্যিক প্রচেষ্টা SQL-কে এগিয়ে নিয়ে গেল। 1980-এর শেষভাগে ANSI/ISO стандар্ডাইজেশন ভেন্ডরদের মধ্যে একটি সাধারণ ভাষার দিকে মিলিত হতে সাহায্য করল—যদিও প্রতিটি প্রোডাক্টের নিজস্ব এক্সটেনশন ছিল।
SQL প্রশ্ন করার খরচ কমিয়ে দিল। প্রতিটি রিপোর্টের জন্য কাস্টম প্রোগ্রাম লেখার বদলে, টিমরা সরাসরি প্রশ্ন লিখতে পারল:
GROUP BY ব্যবহার করে অঞ্চল ও মাস অনুযায়ী বিক্রয়\n- অর্ডার, সাবস্ক্রিপশন ও ক্যান্সেলেশনের যোগ দিয়ে কাস্টমার চুর্ন কহার্ড তৈরি করা\n- অপারেশনাল ড্যাশবোর্ড যা সেকেন্ডে ফিল্টার ও অ্যাগ্রিগেট করেবিগতভাবে ব্যবসায়িক সফটওয়্যারের জন্য, JOIN ও অ্যাগ্রিগেশনের সংমিশ্রণ একটি বড় বিপ্লব ছিল। ফাইন্যান্স টিম ইনভয়েস রিকনসাইল করতে পারল; প্রোডাক্ট টিম কনভারশন ফানেল বিশ্লেষণ করতে পারল; অপারেশন টিম ইনভেন্টরি ও ফুলফিলমেন্ট মনিটর করতে পারল—সবাই একই শেয়ার করা, স্ট্রাকচার্ড ডেটা মডেলের ওপর কুয়েরি করে।
এই ব্যবহারযোগ্যতা একটি বড় কারণ কেন রিলেশনাল মডেল গবেষণা জগতের বাইরে এসে দৈনন্দিন টুল হয়ে উঠল।
ব্যবসায়িক সিস্টেমগুলো বিশ্বাসের ওপর টিকে থাকে। শুধু ডেটা "সংরক্ষণ" করা যথেষ্ট নয়—ডাটাবেসকে সঠিক ব্যালান্স, সঠিক ইনভেন্টরি কাউন্ট, এবং বিশ্বাসযোগ্য অডিট ট্রেইল প্রদান করতে হবে এমনকি যখন অনেকেই একই সময়ে সিস্টেম ব্যবহার করে।
একটি ট্রানজেকশন এক সেট পরিবর্তনকে একটি ব্যবসায়িক অপারেশন হিসেবে গ্রুপ করে। ভাবুন: “$100 স্থানান্তর”, “একটি অর্ডার চালান”, বা “পে-রোল পোস্ট করুন।” এগুলো একাধিক টেবিল ও সারি স্পর্শ করতে পারে।
কী ধারণা হলো সব-অথবা-কিছুই:
এভাবেই আপনি এমন পরিস্থিতি এড়ান যেখানে একটি অ্যাকাউন্ট থেকে টাকা কেটে নেওয়া হয়েছে কিন্তু অন্য অ্যাকাউন্টে পৌঁছায়নি, অথবা ইনভেন্টরি কমে গেছে কিন্তু অর্ডার রেকর্ড হয়নি।
ACID হলো সেই গ্যারান্টিগুলো যার ওপর ব্যবসা নির্ভর করে:
কনস্ট্রেইন্ট (প্রাইমারি কী, ফরেইন কী, চেক) অবৈধ অবস্থা রেকর্ড হওয়া থেকে रोक দেয়। ট্রানজেকশন নিশ্চিত করে যে টেবিল জুড়ে সম্পর্কিত আপডেটগুলো একসাথে আসে।
প্রায়োগিকভাবে: একটি অর্ডার সংরক্ষিত হয়, তার লাইন আইটেমগুলো সংরক্ষিত হয়, ইনভেন্টরি কমে, এবং একটি অডিট লগ লেখা হয়—সবই একসাথে হবে অথবা একটিও হবে না। এই সংমিশ্রণই SQL ডাটাবেসগুলোকে বড় আকারের ব্যবসায়িক সফটওয়্যার সাপোর্ট করার যোগ্য করে তোলে।
SQL ডাটাবেসগুলো কেবল ট্রেন্ডি হওয়ার কারণে বিজয়ী হয়নি—তারা ঠিক সেইভাবে মিলেছে যেমনটি অধিকাংশ সংস্থা আগে থেকেই চিন্তা ও কাজ করে। একটি কোম্পানির কাজ পূর্ণ হয় পুনরাবৃত্ত, কাঠামোবদ্ধ বস্তুগুলো দিয়ে: কাস্টমার, ইনভয়েস, পণ্য, পেমেন্ট, কর্মচারী। প্রতিটির স্পষ্ট অ্যাট্রিবিউট আছে এবং এগুলো একে অপরের সাথে সম্পর্কিত। রিলেশনাল মডেল সেই বাস্তবতাকে সুন্দরভাবে ম্যাপ করে: একটি কাস্টমারের বহু অর্ডার থাকতে পারে, একটি অর্ডারের লাইন আইটেমগুলো আছে, পেমেন্ট ইনভয়েসে মিলিত হয়।
ব্যবসায়িক প্রক্রিয়াগুলো কনসিসটেন্সি ও ট্রেসিবিলিটির ওপর নির্মিত। যখন ফাইনান্স প্রশ্ন করে, “কোন ইনভয়েসগুলো অন-পেইড?” বা সাপোর্ট জিজ্ঞাসা করে, “এই কাস্টমারের কোন প্লান আছে?”, উত্তরগুলো যে কোন টুল বা টিম জিজ্ঞাসা করুক একই হওয়া উচিত। রিলেশনাল ডাটাবেসগুলো তথ্য একবার সংরক্ষণ করে, সব জায়গায় রেফারেন্স করার নকশা দেয়, যে বিরোধগুলো ব্যয়বহুল পুনরায় কাজের উৎস।
যখন SQL ব্যাপকভাবে ছড়িয়ে পড়ল, তার চারপাশে একটি ইকোসিস্টেম তৈরি হলো: রিপোর্টিং টুল, BI ড্যাশবোর্ড, ETL পাইপলাইন, কানেক্টর, প্রশিক্ষণ। সেই সামঞ্জস্য গ্রহণে খরচ কমিয়েছে। আপনার ডেটা যদি রিলেশনাল ডাটাবেসে থাকে, সাধারণত সাধারণ রিপোর্টিং ও অ্যানালিটিক্স ওয়ার্কফ্লোতে প্লাগ-ইন করা সহজ হয়—কাস্টম গ্লু কোড ছাড়াই।
অ্যাপ্লিকেশন দ্রুত বদলে যায়—নতুন ফিচার, UI, ইন্টেগ্রেশন। একটি ভাল ডিজাইন করা স্কিমা একটি টিকিয়ে রাখার চুক্তির মতো কাজ করে: পরিষেবাগুলো ও স্ক্রিন বদলেও কোর টেবিল ও সম্পর্ক ডেটার মান স্থিতিশীল রাখে। এই স্থিরতা SQL ডাটাবেসগুলোকে নির্ভরযোগ্য কেন্দ্র বানায়।
স্কিমা কেবল ডেটা সংগঠিত করে না—এগুলি দায়িত্বও পরিষ্কার করে। টিমগুলো সংজ্ঞায়িত করতে পারে কি একটি “Customer”, কোন ক্ষেত্রগুলো প্রয়োজনীয়, এবং রেকর্ডগুলো কিভাবে সংযুক্ত। প্রাইমারি ও ফরেইন কী দিয়ে দায়িত্ব স্পষ্ট হয়: কে রেকর্ড তৈরি করে, কে আপডেট করতে পারে, এবং ব্যবসার প্রদত্ত নিয়ম কি বজায় রাখতে হবে।
রিলেশনাল ডাটাবেসগুলো তাদের স্থান জিতেছে কারণ তারা পূর্বাভাসযোগ্য ও নিরাপদ, কিন্তু প্রতিটি ওয়ার্কলোডের জন্য সেরা নয়। অনেক SQL সিস্টেমের সমালোচনা আসলে এক টুল সব জায়গায় ব্যবহারের বিরুদ্ধে।
রিলেশনাল স্কিমা একটি চুক্তি—টেবিল, কলাম, টাইপ, কনস্ট্রেইন্টগুলো কি “বৈধ ডেটা” তা সংজ্ঞায়িত করে। শেয়ার করা বোঝাপড়ার জন্য এটা চমৎকার, কিন্তু যখন প্রোডাক্ট দ্রুত বিকশিত হয় তখন এটি টিমকে ধীর করতে পারে।
নতুন ক্ষেত্র সাপ্তাহিকভাবে পাঠানোর সময় মাইগ্রেশন, ব্যাকফিল এবং ডিপ্লয়মেন্ট সমন্বয় বাঁধা হয়ে দাঁড়ায়—বিশেষত বড় টেবিল বা ২৪/৭ অনলাইন সিস্টেম থাকার ক্ষেত্রে।
“NoSQL” রিলেশনাল ধারণা পুরোপুরি প্রত্যাখ্যান করেছিলো না, বরং নির্দিষ্ট ব্যথার পয়েন্টকে লক্ষ্য করে।
এগুলো অনেক সময় কনসিস্টেন্সি বা সমৃদ্ধ JOIN-কে ত্যাগ করে গতি, নমনীয়তা বা বিতরণ লাভ করে।
অধুনা স্ট্যাকগুলো পলিগ্লট: কোর ব্যবসায়িক রেকর্ডের জন্য রিলেশনাল ডাটাবেস, পাশাপাশি অনুষ্ঠানের স্ট্রীম, সার্চ ইনডেক্স, ক্যাশ, বা কনটেন্ট/অ্যানালিটিক্সের জন্য ডকুমেন্ট স্টোর। রিলেশনাল মডেল এখনও সত্যের উৎস, অন্য স্টোরগুলো পড়া-ভারী বা বিশেষ কুয়েরির জন্য কাজ করে।
নির্বাচন করলে লক্ষ্য রাখুন:
ভালো ডিফল্ট হচ্ছে কোর ডেটার জন্য SQL, তারপর যেখানে রিলেশনাল মডেল দৃশ্যত সীমিত সেইখানে বিকল্প যোগ করা।
কড্ডের রিলেশনাল মডেল শুধু ইতিহাস নয়—এটি অভ্যাসের সেট যা ব্যবসায়িক ডেটাকে সহজে বিশ্বাসযোগ্য, পরিবর্তনযোগ্য এবং রিপোর্টযোগ্য করে। আপনার অ্যাপ যদি মিশ্র স্টোর ব্যবহার করেও থাকে, রিলেশনাল চিন্তাভাবনা এখনও সিস্টেম অব রেকর্ডের জন্য শক্তিশালী ডিফল্ট।
শুরুতে আপনার ব্যবসার বাস্তব-পদার্থগুলোকে টেবিল হিসেবে মডেল করুন (Customers, Orders, Payments) এবং সম্পর্কগুলো দিয়ে সংযুক্ত করুন।
কয়েকটি নিয়ম যা পরে অধিকাংশ ব্যথা রোধ করে:
phone1, phone2, phone3 না করে)।আপনি যদি এই নীতিগুলো থেকে একটি প্রকৃত প্রোডাক্ট বানান, তবে এমন টুলিং থাকা সুবিধাজনক যা স্কিমার উদ্দেশ্য ও অ্যাপ কোডকে সমন্বয় রাখে। উদাহরণস্বরূপ, Koder.ai একটি React + Go + PostgreSQL অ্যাপ চ্যাট প্রম্পট থেকে জেনারেট করতে পারে, যা একটি নরমালাইজড স্কিমা (টেবিল, কী, সম্পর্ক) প্রোটোটাইপ করা সহজ করে—তবে এখনও ডাটাবেসকে সত্যির উৎস হিসেবে রাখে এবং যখন আপনি পুরো নিয়ন্ত্রণ নিতে চান তখন সোর্স কোড এক্সপোর্ট দেয়।
যদি আপনার ডেটার শক্ত কোর জাচাই-গ্যারান্টি দরকার থাকে, জিজ্ঞেস করুন:
যদি উত্তর প্রায়ই “হ্যাঁ” হয়, একটি রিলেশনাল ডাটাবেস সাধারণত সহজতম পথ।
“SQL স্কেল করতে পারে না” বলা খুব বিস্তৃত। SQL সিস্টেম অনেক উপায়ে স্কেল করে (ইন্ডেক্স, ক্যাশিং, রিড রিপ্লিকা, প্রয়োজন হলে শার্ডিং)। অধিকাংশ টিম সত্যিকারের ডাটাবেস সীমা পড়ার আগে মডেলিং ও কুয়েরির সমস্যা সম্মুখীন হয়।
“নরমালাইজেশন সব কিছুকে ধীর করে”—এটাও অসম্পূর্ণ। নরমালাইজেশন অনোমালি কমায়; পারফর্ম্যান্স ইন্ডেক্স, কুয়েরি ডিজাইন এবং নির্বাচিত ডেনরমালাইজেশনের মাধ্যমে পরিচালনা করা যায়।
কড্ড টিমগুলোকে একটি ভাগ করা চুক্তি দিলেন: সম্পর্কিত টেবিলগুলোতে ডেটা সাজানো, সুসংজ্ঞায়িত অপারেশন দিয়ে ম্যানিপুলেশন, এবং কনস্ট্রেইন্ট দিয়ে রক্ষা। এই চুক্তির ফলে প্রতিদিনের সফটওয়্যার বছরের পর বছর বিকশিত হলেও মৌলিক প্রশ্নগুলো—“কি ঘটেছে, কখন এবং কেন?”—এবং তাদের উত্তরগুলোর নির্ভরযোগ্যতা বজায় থাকে।
রিলেশনাল মডেল ডেটা টেবিল (রিলেশন) আকারে সংরক্ষণ করে, যেখানে:
এর মূল সুবিধা হলো আলাদা টেবিলগুলোকে শেয়ার করা শনাক্তকরণ ব্যবহার করে যুক্ত করা যায়, ফলে প্রতিটি তথ্য একবারই রাখা যায় এবং রিপোর্ট বা ওয়ার্কফ্লোতে পুনরায় মিলিয়ে নেওয়া যায়।
ফাইল-ভিত্তিক সিস্টেমে ডেটা বিন্যাস অ্যাপ্লিকেশন কোডের সঙ্গে কড়াভাবে জড়িত থাকত। এর ফলে বাস্তব সমস্যাগুলো দেখা দিত:
রিলেশনাল ডাটাবেস ডেটা সংজ্ঞা কোনো একক অ্যাপ থেকে আলাদা করে দিল এবং সার্বজনীন কুইরি সহজ করে তুললো।
একটি প্রাইমারি কী (PK) টেবিলের প্রতিটি সারি অনন্যভাবে সনাক্ত করে এবং সময়ের সাথে স্থিতিশীল থাকা উচিত।
প্র্যাকটিক্যাল নির্দেশনা:
customer_id) ব্যবহার করুন।একটি ফরেইন কী (FK) এমন একটি কলাম যার মান অন্য টেবিলের প্রাইমারি কী-র সঙ্গে মিলতে হবে। এটি সম্পূর্ণ রেকর্ড কপি না করে সম্পর্ক প্রদর্শনের উপায়।
উদাহরণ প্যাটার্ন:
orders.customer_id references customers.customer_idFK কনস্ট্রেইন্ট চালু থাকলে ডাটাবেস প্রতিরোধ করতে পারে:
নরমালাইজেশন মূলত ডেটা অনিয়মতা কমানোর উপায়: প্রতিটি সত্যকে সম্ভব হলে একবারই সংরক্ষণ করা। এটি সাহায্য করে প্রতিরোধ করতে:
সাধারণ লক্ষ্যমাত্রা হলো কোর এন্টিটিগুলির জন্য , এবং পরে পরিমাপ করে দরকার পড়লে নির্বাচিতভাবে ডেনরমালাইজেশন করা।
ভাল 1NF নিয়ম: এক ফিল্ড, একটি মান।
যদি আপনি phone1, phone2, phone3 এর মতো কলাম বানাতে শুরু করেন, তবেঃ
একটি আলাদা টেবিলে ভাগ করুন:
customer_phones(customer_id, phone_number, type)রিলেশনাল বীজগণিত (relational algebra) হলো রিলেশনাল কনসেপ্টগুলোর পেছনে মৌলিক অপারেশনগুলির সেট:
প্রতিদিন SQL ব্যবহারে আপনাকে সরাসরি relational algebra লিখতে হবে না, কিন্তু এই ধারণাগুলো বোঝা SQL ফলাফলের পেছনে যুক্তি বুঝতে সাহায্য করে এবং ভুল JOIN-এ ডেটা নকল হওয়া রোধ করে।
SQL রিলেশনাল ধারণাগুলো ব্যবহারযোগ্য করে তুললো কারণ এটি একটি ডিক্লারেটিভ উপায় দিল—আপনি ফলাফল বর্ণনা করেন, ডাটাবেস কার্যকর প্ল্যান বানায়।
প্রধান ব্যবহারিক সুবিধা:
GROUP BY)যদিও SQL পুরোপুরি Codd-এর তত্ত্ব নয়, তবু এটি সম্পর্কিত টেবিলগুলোর ওপর নির্ভরযোগ্য প্রশ্নের ধারাবাহিক কাজকে বাস্তবায়িত করেছে।
একটি ট্রানজেকশন একাধিক পরিবর্তনকে একটি একক ব্যবসায়িক অপারেশন হিসেবে গ্রুপ করে। উদাহরণ: “$100 ট্রান্সফার”, “অর্ডার পাঠানো”, “পে-রোল পোস্ট করা” — এগুলো একাধিক টেবিল ও সারি স্পর্শ করে।
মূল ধারণা: সব-অথবা-কিছুই (all-or-nothing):
ACID সংক্ষেপে:
রিলেশনাল ডাটাবেসগুলো ব্যবসায়িক কাজের সঙ্গে মিলে যায় কারণ একটি কোম্পানিতে বারবার প্রবাহমান গঠন থাকে: কাস্টমার, ইনভয়েস, পণ্য, পেমেন্ট। প্রতিটিটির নির্দিষ্ট অ্যাট্রিবিউট থাকে এবং একে অপরের সাথে সম্পর্ক আছে। রিলেশনাল মডেল এই বাস্তবতাটিকে সুন্দরভাবে ম্যাপ করে: একটি কাস্টমারের অনেক অর্ডার থাকতে পারে, একটি অর্ডার লাইন আইটেম আছে ইত্যাদি।
আরও কারণসমূহ:
রিলেশনাল DB গুলো নির্ভরযোগ্য হলেও সব কাজের জন্য সেরা নয়। SQL সিস্টেমের সমালোচনাগুলো প্রায়ই একটিই টুল সবাইই ব্যবহার করার ওপর ভিত্তি করে আসে।
কখন সীমাবদ্ধতা অনুভূত হয়:
আধুনিক আর্কিটেকচারে প্রায়শই পলিগলট: রিলেশনাল DB কোর সিস্টেম অফ রেকর্ড হিসেবে, এবং অন্যান্য স্টোর পড়ার জন্য বা স্পেশালাইজড কুয়েরির জন্য ব্যবহৃত হয়। সিদ্ধান্ত নেবার সময় দেখুন:
কড্ডের রিলেশনাল মডেল কেবল ইতিহাস নয়—এটি এমন অভ্যাসের সেট যা ব্যবসায়িক ডেটাকে সহজে বিশ্বাসযোগ্য, পরিবর্তনযোগ্য এবং রিপোর্টযোগ্য করে তোলে। যদি আপনার অ্যাপ মিশ্র স্টোর ব্যবহার করেও থাকে, রিলেশনাল ভাবনা আজও সিস্টেম অব রেকর্ডের জন্য শক্তিশালী ডিফল্ট।
প্র্যাকটিক্যাল টেবিল ডিজাইনের টেকঅওয়ে:
এতে ফোন নম্বর সার্চ, ভ্যালিডেশন ও আপডেট করা সহজ হয় এবং “মিসিং কলাম” সমস্যাগুলো এড়ানো যায়।
কনস্ট্রেইন্ট + ট্রানজেকশন মিলিয়ে সিস্টেমকে সৎ রাখে: সবকিছু একসাথে লেখা হয় বা একসাথে বাতিল করা হয়।
সাধারণ ডিফল্ট: কোর ডেটার জন্য SQL, যেখানে প্রয়োজন সেখানে বিকল্প যোগ করুন।
কিছু প্রশ্ন যা ডাটাবেস পছন্দ করার সময় জিজ্ঞেস করবেন:
সাধারণ ভুল ধারণা ড্রপ করুন:
কড্ডের স্থায়ী প্রভাব: সম্পর্কিত টেবিল, সুসংজ্ঞায়িত অপারেশন এবং কনস্ট্রেইন্ট—এই চুক্তিই ইভেন্টগুলোকে বছর কাটিয়ে প্রশ্নের জবাব দিতে সাহায্য করে: “কি ঘটেছে, কখন এবং কেন?”