এডগার এফ. কড্ডের রিলেশনাল মডেল: কেন এসকিউএল ব্যবসা জিতল

মূল ভাবনা: সম্পর্কিত টেবিল হিসেবে ডেটা

সরলভাবে, রিলেশনাল মডেল তথ্যকে টেবিল (কড্ড যাকে “relations” বলতেন) হিসাবে সংরক্ষণ করে এবং শেয়ার করা মানের মাধ্যমে সেগুলোকে লিঙ্ক করা যায়।

একটি টেবিল হলো সুসজ্জিত গ্রিড:

• সারি (rows) একক বস্তুকে বোঝায় (একজন কাস্টমার, একটি ইনভয়েস, একটি পেমেন্ট)।
• কলাম (columns) সেই বস্তুগুলোর অ্যাট্রিবিউট বোঝায় (কাস্টমারের নাম, ইনভয়েসের তারিখ, পরিমাণ)।

কেন ব্যবসায়িক ডেটার জন্য এটা গুরুত্বপূর্ণ ছিল

ব্যবসায় ডেটা বিচ্ছিন্নভাবে রাখা হয় না। একটি বিক্রয় জড়িত থাকে কাস্টমার, পণ্য, দাম, বিক্রেতা এবং তারিখ—প্রতিটি ভিন্ন গতিতে বদলে যায় এবং বিভিন্ন দলের মালিকানায় থাকে। প্রারম্ভিক সিস্টেমগুলো প্রায়শই এই ডিটেইলগুলোকে কঠোরভাবে জোড়া-কাটা স্ট্রাকচারে রাখত, যা পরিবর্তন করা কঠিন করেছিল। রিপোর্টিং ধীর, পরিবর্তন ঝুঁকিপূর্ণ, এবং “সরল প্রশ্ন” অপ্রত্যাশিতভাবে ব্যয়বহুল ছিল।

রিলেশনাল মডেল একটি পরিষ্কার পথ দেখায়: ভিন্ন ধারণার জন্য আলাদা টেবিল রাখুন, তারপর প্রয়োজন হলে সেগুলোকে সংযুক্ত করুন। প্রতিটি ইনভয়েস রেকর্ডে কাস্টমারের সব বিবরণ বারবার কপি করার বদলে, কাস্টমারকে একবার সংরক্ষণ করে ইনভয়েস থেকে রেফারেন্স করুন। এতে বিরোধ কমে (একই কাস্টমারের ভিন্ন বানান) এবং আপডেট করা অনেক বেশি প্রত্যাশাযোগ্য হয়।

প্রত্যাশা নির্ধারণ: এমনিকুই কনসিস্টেন্সি যা বিশ্বাসযোগ্য

ভালভাবে সংজ্ঞায়িত টেবিল ও সংযোগের নিয়ম জোর দিয়ে মডেল একটি নতুন প্রত্যাশা স্থাপন করল: ডাটাবেস যত বাড়বে ততই অসংগতিকে প্রতিরোধে সাহায্য করবে—বিশেষ করে যখন অনেক মানুষ এবং সিস্টেম লেখে।

একটা প্রিভিউ: SQL কীভাবে এটা অনুসরণ করল

কড্ডের মডেল নিজে কোনো কুয়েরি ভাষা ছিল না, কিন্তু এটা একটি ভাষার অনুপ্রেরণা দিয়েছিল। যদি ডেটা সম্পর্কিত টেবিলগুলোতে থাকে, আপনাকে দরকার একটি স্ট্যান্ডার্ড উপায়:

• আপনি যে সারিগুলি চান সেগুলো নির্বাচন করা,\n- প্রয়োজন হলে টেবিলগুলো মিলানো,\n- রিপোর্টের জন্য রেজাল্ট সারাংশ করা।

এই পথই নিয়ে গেল SQL-এ, যা মডেলটিকে ব্যবহারিক করে তুলল যাতে প্রতিদিনের টিমগুলো ব্যবসায়িক ডেটার ওপর প্রশ্ন করতে পারে এবং পুনরাবৃত্ত, অডিটেবল উত্তর পেতে পারে।

কড্ডের আগে: প্রারম্ভিক ডেটা সিস্টেম কেন কষ্টকর ছিল

রিলেশনাল মডেলের আগেও অনেক প্রতিষ্ঠান গুরুত্বপূর্ণ তথ্য ফাইল-এ রাখত—প্রতিটি অ্যাপ্লিকেশনের জন্য আলাদা ফাইল। পে-রোলের আলাদা রেকর্ড, ইনভেন্টরির আলাদা, কাস্টমার সার্ভিসের আলাদা “কাস্টমার”—প্রতিটি সিস্টেম বিচ্ছিন্নভাবে কাজ করত, এবং সেই বিচ্ছিন্নতা পূর্বাভাসযোগ্য কষ্ট তৈরি করত।

ফাইল-ভিত্তিক সিস্টেম: তাড়াতাড়ি শুরু, বড় হতে কঠিন

প্রারম্ভিক ডেটা প্রসেসিং সাধারণত কাস্টম ফাইল ফর্ম্যাট এবং একক উদ্দেশ্যের জন্য লেখা প্রোগ্রামের চারপাশে তৈরি হত। ডেটার কাঠামো (প্রতিটি ফিল্ড কোথায় থাকে, রেকর্ড কীভাবে সাজানো) সেই কোডের সঙ্গে কড়াভাবে জড়িত থাকত। এর মানে ছোট একটি পরিবর্তন—একটি নতুন ফিল্ড যোগ করা, পণ্যের ক্যাটাগরি নাম পরিবর্তন—হোক সবকিছুতে একাধিক প্রোগ্রাম পুনরায় লেখা লাগত।

ডুপ্লিকেশন ত্রুটি ও অতিরিক্ত কাজ সৃষ্টি করে

কারণ দলগুলো সহজে একটি একক উৎস শেয়ার করতে পারত না, তারা ডেটা কপি করত। কাস্টমারের ঠিকানা বিক্রয় ফাইল, শিপিং ফাইল, বিলিং ফাইলে থাকতে পারত।

একটি ঠিকানা বদলে গেলে প্রতিটি কপিতে আপডেট দরকার। যদি কোনো সিস্টেম বাদ পড়ে যায়, অসংগতি দেখা দেয়: ইনভয়েস ভুল জায়গায় যায়, শিপমেন্ট বিলম্বিত হয়, এবং সাপোর্ট এজেন্টরা দেখতে পায় ভিন্ন “তথ্য” বিভিন্ন স্ক্রিনে। ডেটা ক্লীনআপ এককালীন কাজ না থেকে নিয়মিত প্রকল্পে পরিণত হয়।

রিপোর্টিং ও অ্যাড-হক প্রশ্ন কষ্টদায়ক ছিল

ব্যবসায়িক ব্যবহারকারীরাও প্রশ্ন করত—“কোন কাস্টমাররা পণ্য X কিনেছিল এবং পরে রিটার্ন করেছে?”—কিন্তু উত্তর পাওয়ার জন্য ফাইলগুলোকে হাতে-কলমে জোড়া লাগত। দলগুলো প্রায়শই একশ ব্যচ্ছিন্ন রিপোর্টিং এক্সট্রাক্ট তৈরি করত, যা আরও কপি ও মিসম্যাচের সুযোগ দেয়।

ফলাফল: রিপোর্টিং সাইকেল ধীর ছিল, এবং “দ্রুত প্রশ্ন” ইঞ্জিনিয়ারিং কাজ হয়ে পড়ত।

ব্যবসা যা চেয়েছিল

সংগঠনগুলো প্রয়োজন করত এমন শেয়ার করা ডেটা যা একাধিক অ্যাপ্লিকেশন নির্ভর করতে পারে, কম অসংগতি ও কম ডুপ্লিকেট প্রচেষ্টা নিয়ে। পাশাপাশি তারা চাইত এমন উপায় যাতে নতুন প্রশ্ন করা যায় বিনা রিকনস্ট্রাকশন। সেই ফাঁকেই কড্ডর মূল ধারণা জন্ম নিল: ডেটা নির্ভরযোগ্য, অ্যাপ-নিরপেক্ষ ভাবে সংজ্ঞায়িত করুন, যেন সিস্টেমগুলো ভাঙা ছাড়াই বিকশিত হতে পারে।

এডগার এফ. কড্ড কে ছিলেন?

এডগার এফ. কড্ড ছিলেন একজন ব্রিটিশ কম্পিউটার বিজ্ঞানী, যিনি বেশিরভাগ কেরিয়ার IBM-এ কাটিয়েছেন এবং তথ্য সংরক্ষণ ও পুনরুদ্ধারের উপায় নিয়ে কাজ করেছেন। 1960-এ দশকে বেশিরভাগ “ডাটাবেস” সিস্টেম ছিল সাবধানভাবে পরিচালিত ফাইল ক্যাবিনেটের মতো: ডেটা কড়া, প্রি-ডিফাইন্ড স্ট্রাকচারে ছিল, এবং সেই স্ট্রাকচার পরিবর্তন করলে অ্যাপ্লিকেশনগুলো প্রায়ই পুনরায় লেখার দরকার হতো। সেই ভঙ্গুরতা টিমগুলোর হতাশা সৃষ্টি করত কারণ ব্যবসা বাড়ছিল এবং চাহিদা বদলাচ্ছিল।

1970-এর পেপার যা আলোচনা বদলে দিল

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" সংখ্যা ক্ষেত্রের ভিতরে রাখা।

“রিলেশনাল” বলতে স্প্রেডশীট নয়, সম্পর্ক বোঝায়

“রিলেশনাল” নামটি নির্দেশ করে কিভাবে ফ্যাক্টগুলো রিলেশনগুলোর মধ্যে যুক্ত হতে পারে (যেমন কাস্টমার থেকে অর্ডার), যাতে বিলিং, রিপোর্টিং, অডিটিং, কাস্টমার সাপোর্ট সহ সাধারণ ব্যবসায়িক কাজগুলো পুনরাবৃত্তি ছাড়া করা যায়।

কী ও সম্পর্ক: ডেটা ঠিক রাখার ঢাল

টেবিল নিজে উপকারী, কিন্তু ব্যবসায়িক ডেটা তখনই অর্থপূর্ন হয় যখন আপনি নির্ভরযোগ্যভাবে ফ্যাক্টগুলো সংযোগ করতে পারেন: কোন কাস্টমার কোন অর্ডার করেছে, কোন আইটেম সেগুলোতে ছিল, কত চার্জ করা হয়েছিল। কী-গুলো হল সেই মেকানিজম যা সেই সংযোগগুলো নির্ভরযোগ্য করে।

প্রাইমারি কী: স্থিতিশীল শনাক্তকারী

একটি প্রাইমারি কী হলো একটি কলাম (বা কলাম সেট) যার মান একটি সারিকে ইউনিকভাবে চিহ্নিত করে। এটাকে সারির “নেম ট্যাগ” ভাবুন। গুরুত্বপূর্ণ অংশ হলো স্থিতিশীলতা: নাম, ইমেইল, ঠিকানা বদলে যেতে পারে, কিন্তু একটি অভ্যন্তরীণ আইডি বদলানো উচিত নয়।

একটি ভালো প্রাইমারি কী ডুপ্লিকেট বা অস্পষ্ট রেকর্ড প্রতিরোধ করে। যদি দুই কাস্টমারের একই নাম থাকে, প্রাইমারি কী তাদের আলাদা করবে।

ফরেইন কী: টেবিলগুলোর মধ্যে লিঙ্ক

একটি ফরেইন কী একটি কলাম যা অন্য টেবিলের প্রাইমারি কী-কে সংরক্ষণ করে। এভাবেই সম্পর্কগুলো কপি না করে উপস্থাপিত হয়।

উদাহরণ মডেল:

• customers (customer_id PK, name, email)
• orders (order_id PK, customer_id FK → customers.customer_id, order_date)
• order_items (order_item_id PK, order_id FK → orders.order_id, product, quantity, price)

কনস্ট্রেইন্ট: “ওরফান” ও সংঘাত প্রতিরোধ করা

ফরেইন কী কনস্ট্রেইন্ট গার্ডরেল হিসেবে কাজ করে। এগুলো প্রতিরোধ করে:

• অরফান রেকর্ড: এমন একটি অর্ডার যে একটি বিদ্যমান নয় এমন customer_id নির্দেশ করে।
• বিরোধপূর্ণ আপডেট: কোনো কাস্টমার মুছে ফেলা যার অর্ডারগুলো এখনও তাদের দিকে ইঙ্গিত করে (ক্যাসকেড ডিলিটের মত নিয়ম স্পষ্টভাবে নেয়া না হলে)।

প্রায়োগিক দিক থেকে কী ও কনস্ট্রেইন্ট টিমগুলোকে রিপোর্ট ও ওয়ার্কফ্লো বিশ্বাস করার যোগ্য করে তোলে। যখন ডাটাবেস সম্পর্কগুলো প্রয়োগ করে, বিলিং, ফুলফিলমেন্ট এবং কাস্টমার সাপোর্টে কম বাগ ঢুকবে—কারণ ডেটা নিঃশব্দে অসম্ভব অবস্থা গ্রহণ করতে পারবে না।

নরমালাইজেশন: পরিষ্কার ডেটা, কম বিস্ময়

নরমালাইজেশন রিলেশনাল মডেলের উপায় যাতে ডেটা বড় হয়ে গেলেও বিরোধে না পড়ে। যখন একই তথ্য একাধিক জায়গায় সংরক্ষণ করা হয়, একটি কপি আপডেট করা আর অন্যটি ভুল থেকে গেলে সমস্যা হয়। এটাই কিভাবে ইনভয়েসগুলো ভুল ঠিকানায় যায়, রিপোর্ট মেলেনা, বা একজন কাস্টমার এক স্ক্রিনে “inactive” আর অন্যে “active” দেখা যায়।

নরমালাইজেশন কি প্রতিরোধ করতে চায়

ব্যবহারিকভাবে, নরমালাইজেশন সাধারণ সমস্যাগুলো কমায়:

• ডুপ্লিকেশন: একই তথ্য (যেমন কাস্টমার ঠিকানা) অনেক সারিতে পুনরাবৃত্তি হওয়া।
• আপডেট অ্যানোমালি: এক পরিবর্তনে একাধিক সম্পাদনার দরকার পড়া, ফলে আংশিক আপডেট হয়।

এছাড়া ইনসার্ট অ্যানোমালি (নতুন কাস্টমার যোগ করতে পারছ না যতক্ষণ তারা অর্ডার না করে) এবং ডিলিট অ্যানোমালি (শেষ অর্ডার মুছে দিলে একমাত্র কাস্টমার তথ্যও চলে যায়) এড়ানোও লক্ষ্য।

1NF, 2NF, 3NF — ধারণাগত ব্যাখ্যা

কঠোর তত্ত্ব ছাড়াই কয়েকটি মৌলিক ধারণা:

প্রথম নরমাল ফর্ম (1NF): প্রতিটি ফিল্ডকে অ্যাটোমিক রাখুন। যদি একজন কাস্টমারের একাধিক ফোন নম্বর থাকে, এক সেলে সেগুলো মিশাবেন না; আলাদা টেবিল বা আলাদা সারি ব্যবহার করুন।

সেকেন্ড নরমাল ফর্ম (2NF): যদি একটি টেবিলের পরিচয় একাধিক কলামের উপর নির্ভর করে (কম্পোজিট কি), নিশ্চিত করুন নন-কী ডিটেইলগুলো পুরো কী-র উপর নির্ভর করে। উদাহরণ: একটি অর্ডার লাইনে সেই লাইনের পরিমাণ ও দাম থাকা উচিত, কাস্টমার ঠিকানা নয়।

থার্ড নরমাল ফর্ম (3NF): পাশের তথ্য দূর করুন যা অন্য কোথাও থাকা উচিৎ। যদি একটি টেবিলে CustomerId এবং একই সাথে CustomerCity থাকে, সাধারনত সিটি কাস্টমার টেবিলে থাকা উচিত, প্রতিটি অর্ডারে কপি করা ঠিক নয়।

ট্রেডঅফ ও “ভালো পর্যাপ্ত” পন্থা

আরো নরমালাইজেশন সাধারণত বেশি টেবিল এবং বেশি JOIN মানে—এটা কনসিস্টেন্সি বাড়ায়, কিন্তু রিপোর্টিং জটিল করতে পারে এবং মাঝে মাঝে পারফর্ম্যান্স প্রভাব ফেলে। অনেক দল কোর এন্টিটিগুলোর জন্য 3NF লক্ষ্য করে (customers, products, invoices), তারপর পড়ার ভারি ড্যাশবোর্ডগুলোর জন্য পরিমাপ করে নির্বাচিতভাবে ডেনরমালাইজ করেন—তবে একটি অথরিটেটিভ সোর্স অফ ট্রুথ প্রাইমারি কী/ফরেইন কী দিয়ে বজায় রাখা হয়।

রিলেশনাল বীজগণিত: কুয়েরির পেছনের যুক্তি

রিলেশনাল বীজগণিত হলো রিলেশনাল মডেলের পিছনে থাকা “গণিত”: ছোট কিন্তু নির্দিষ্ট অপারেশনগুলোর সেট যা একটি টেবিলকে অন্য একটি টেবিলে রূপান্তর করে।

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

প্রধান অপারেশনগুলো (সরল ভাষায়)

রিলেশনাল বীজগণিত এমন ব্লক সংজ্ঞায়িত করে যেগুলোকে মিলিয়ে বড় কুয়েরি গঠিত হয়। তিনটির উল্লেখযোগ্য:

• Select: আপনি যেসব সারি চান সেগুলো বাছাই করুন।

  উদাহরণ: “শুধুমাত্র গত মাসের অর্ডার” বা “শুধুমাত্র ফ্রান্সের কাস্টমার।” একই কলাম রেখে সারি কমানো।

• Project: আপনি যেসব কলাম চান সেগুলো বাছাই করুন।

  উদাহরণ: “কাস্টমারের নাম ও ইমেইল দেখান।” যথারীতি সারি একই (তাত্ত্বিকভাবে), কিন্তু অনাবশ্যক কলাম সরানো।

• Join: বিভিন্ন টেবিল থেকে সম্পর্কিত তথ্য মিলান।

  উদাহরণ: “প্রতিটি অর্ডারে কাস্টমার ডিটেইল যোগ করুন,” একটি শেয়ার করা শনাক্তকরণ (যেমন customer_id) ব্যবহার করে। আউটপুট একটি নতুন টেবিল যেখানে প্রতিটি সারি আলাদাভাবে সংরক্ষিত ফিল্ডগুলো একসাথে নিয়ে আসে।

কেন JOIN ব্যবসায়িক ডেটার কেন্দ্রীয়

ব্যবসায়িক ডেটা স্বভাবগতভাবে বিষয়ভিত্তিকভাবে বিভক্ত: কাস্টমার, অর্ডার, ইনভয়েস, পণ্য, পেমেন্ট। এই বিভাজন প্রতিটি তথ্য একবার সংরক্ষণ করতে সাহায্য করে (যা মিসম্যাচ কমায়), কিন্তু একই সময়ে উত্তর পেতে প্রায়শই সেগুলো পুনরায় মিলাতে হয়।

JOIN-ই সেই পুনরায় মিলানোর আনুষ্ঠানিক উপায়, অর্থ রক্ষা করে। কাস্টমারের নাম প্রতিটি অর্ডারে কপি করার বদলে, কাস্টমারকে একবার সংরক্ষণ করে রিপোর্টে JOIN করুন।

প্রত্যাশাযোগ্য ফলাফল, না করে বিস্ময়

কারণ রিলেশনাল বীজগণিত সেট-ভিত্তিক অপারেশন হিসেবে সংজ্ঞায়িত, প্রতিটি ধাপের প্রত্যাশা স্পষ্ট:

• ফিল্টারিং কোন সারি অন্তর্ভুক্ত হবে তা প্রভাবিত করে।
• প্রজেকশন কোন কলাম দেখা যাবে তা প্রভাবিত করে।
• জয়িং কিভাবে ফ্যাক্টগুলো জুড়বে তা প্রভাবিত করে।

এটাই ধারণাগত ঘাড় যেখানে পরে SQL ব্যবহারিকভাবে দাঁড়ালো: কুয়েরিগুলো নির্দিষ্ট রূপান্তরের সিকোয়েন্স হয়ে যায়, কেবলচাত্ত্বিক ডেটা ফেরত না এনে এলোমেলো ফেচ নয়।

তত্ত্ব থেকে SQL: রিলেশনাল মডেল কিভাবে ব্যবহারযোগ্য হল

কড্ডের রিলেশনাল মডেল কি বর্ণনা করেছিল তা হলো ডেটা কী (রিলেশন, কী, অপারেশন) — কিন্তু এইকে দিনের ব্যবহার উপযোগী করে তোলার জন্য একটি বন্ধুত্বপূর্ণ উপায় দরকার ছিল। 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- অপারেশনাল ড্যাশবোর্ড যা সেকেন্ডে ফিল্টার ও অ্যাগ্রিগেট করে

বাস্তবে SQL কী সহজ করল

বিগতভাবে ব্যবসায়িক সফটওয়্যারের জন্য, JOIN ও অ্যাগ্রিগেশনের সংমিশ্রণ একটি বড় বিপ্লব ছিল। ফাইন্যান্স টিম ইনভয়েস রিকনসাইল করতে পারল; প্রোডাক্ট টিম কনভারশন ফানেল বিশ্লেষণ করতে পারল; অপারেশন টিম ইনভেন্টরি ও ফুলফিলমেন্ট মনিটর করতে পারল—সবাই একই শেয়ার করা, স্ট্রাকচার্ড ডেটা মডেলের ওপর কুয়েরি করে।

এই ব্যবহারযোগ্যতা একটি বড় কারণ কেন রিলেশনাল মডেল গবেষণা জগতের বাইরে এসে দৈনন্দিন টুল হয়ে উঠল।

স্কেলে বিশ্বাস: কনসিস্টেন্সি, ট্রানজেকশন, এবং ACID

ব্যবসায়িক সিস্টেমগুলো বিশ্বাসের ওপর টিকে থাকে। শুধু ডেটা "সংরক্ষণ" করা যথেষ্ট নয়—ডাটাবেসকে সঠিক ব্যালান্স, সঠিক ইনভেন্টরি কাউন্ট, এবং বিশ্বাসযোগ্য অডিট ট্রেইল প্রদান করতে হবে এমনকি যখন অনেকেই একই সময়ে সিস্টেম ব্যবহার করে।

ট্রানজেকশন: এক ব্যবসায়িক কাজ, একক ইউনিট হিসেবে বিবেচিত

একটি ট্রানজেকশন এক সেট পরিবর্তনকে একটি ব্যবসায়িক অপারেশন হিসেবে গ্রুপ করে। ভাবুন: “$100 স্থানান্তর”, “একটি অর্ডার চালান”, বা “পে-রোল পোস্ট করুন।” এগুলো একাধিক টেবিল ও সারি স্পর্শ করতে পারে।

কী ধারণা হলো সব-অথবা-কিছুই:

• যদি প্রতিটি ধাপ সফল হয়, ট্রানজেকশন commit হয়।
• যদি কোনো ধাপ ব্যর্থ হয় (নেটওয়ার্ক সমস্যা, ভ্যালিডেশন ত্রুটি, ক্র্যাশ), ট্রানজেকশন roll back হয় এবং ডাটাবেস আগের অবস্থায় ফিরে আসে।

এভাবেই আপনি এমন পরিস্থিতি এড়ান যেখানে একটি অ্যাকাউন্ট থেকে টাকা কেটে নেওয়া হয়েছে কিন্তু অন্য অ্যাকাউন্টে পৌঁছায়নি, অথবা ইনভেন্টরি কমে গেছে কিন্তু অর্ডার রেকর্ড হয়নি।

ACID, সরল ভাষায়

ACID হলো সেই গ্যারান্টিগুলো যার ওপর ব্যবসা নির্ভর করে:

• Atomicity: সব-অথবা-কিছুই নীতি।
• Consistency: ডাটাবেস আপনার নিয়ম ভাঙবে না (যেমন পরিমাণ নেতিবাচক হবে না)।
• Isolation: সমান্তরাল কাজগুলি অপরস্পরকে অবাঞ্ছিতভাবে প্রভাবিত করে না।
• Durability: একবার নিশ্চিত হয়ে গেলে ক্র্যাশের পরও ফলাফল থাকে।

কনস্ট্রেইন্ট + ট্রানজেকশন: সিস্টেম কিভাবে সততা বজায় রাখে

কনস্ট্রেইন্ট (প্রাইমারি কী, ফরেইন কী, চেক) অবৈধ অবস্থা রেকর্ড হওয়া থেকে रोक দেয়। ট্রানজেকশন নিশ্চিত করে যে টেবিল জুড়ে সম্পর্কিত আপডেটগুলো একসাথে আসে।

প্রায়োগিকভাবে: একটি অর্ডার সংরক্ষিত হয়, তার লাইন আইটেমগুলো সংরক্ষিত হয়, ইনভেন্টরি কমে, এবং একটি অডিট লগ লেখা হয়—সবই একসাথে হবে অথবা একটিও হবে না। এই সংমিশ্রণই SQL ডাটাবেসগুলোকে বড় আকারের ব্যবসায়িক সফটওয়্যার সাপোর্ট করার যোগ্য করে তোলে।

কেন SQL ডাটাবেস ব্যবসায়িক সফটওয়্যারের মেরুদন্ড হয়ে উঠলো

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

দৈনন্দিন ব্যবসায়িক ওয়ার্কফ্লোর জন্য একটি স্বাভাবিক মিল

ব্যবসায়িক প্রক্রিয়াগুলো কনসিসটেন্সি ও ট্রেসিবিলিটির ওপর নির্মিত। যখন ফাইনান্স প্রশ্ন করে, “কোন ইনভয়েসগুলো অন-পেইড?” বা সাপোর্ট জিজ্ঞাসা করে, “এই কাস্টমারের কোন প্লান আছে?”, উত্তরগুলো যে কোন টুল বা টিম জিজ্ঞাসা করুক একই হওয়া উচিত। রিলেশনাল ডাটাবেসগুলো তথ্য একবার সংরক্ষণ করে, সব জায়গায় রেফারেন্স করার নকশা দেয়, যে বিরোধগুলো ব্যয়বহুল পুনরায় কাজের উৎস।

স্ট্যান্ডার্ড টুলিং SQL-কে ডিফল্ট বানায়

যখন SQL ব্যাপকভাবে ছড়িয়ে পড়ল, তার চারপাশে একটি ইকোসিস্টেম তৈরি হলো: রিপোর্টিং টুল, BI ড্যাশবোর্ড, ETL পাইপলাইন, কানেক্টর, প্রশিক্ষণ। সেই সামঞ্জস্য গ্রহণে খরচ কমিয়েছে। আপনার ডেটা যদি রিলেশনাল ডাটাবেসে থাকে, সাধারণত সাধারণ রিপোর্টিং ও অ্যানালিটিক্স ওয়ার্কফ্লোতে প্লাগ-ইন করা সহজ হয়—কাস্টম গ্লু কোড ছাড়াই।

অ্যাপ বদলে যায়; ডেটা চুক্তি হওয়া উচিত নয়

অ্যাপ্লিকেশন দ্রুত বদলে যায়—নতুন ফিচার, UI, ইন্টেগ্রেশন। একটি ভাল ডিজাইন করা স্কিমা একটি টিকিয়ে রাখার চুক্তির মতো কাজ করে: পরিষেবাগুলো ও স্ক্রিন বদলেও কোর টেবিল ও সম্পর্ক ডেটার মান স্থিতিশীল রাখে। এই স্থিরতা SQL ডাটাবেসগুলোকে নির্ভরযোগ্য কেন্দ্র বানায়।

স্কিমা মালিকানা ও দায়িত্ব পরিষ্কার করে

স্কিমা কেবল ডেটা সংগঠিত করে না—এগুলি দায়িত্বও পরিষ্কার করে। টিমগুলো সংজ্ঞায়িত করতে পারে কি একটি “Customer”, কোন ক্ষেত্রগুলো প্রয়োজনীয়, এবং রেকর্ডগুলো কিভাবে সংযুক্ত। প্রাইমারি ও ফরেইন কী দিয়ে দায়িত্ব স্পষ্ট হয়: কে রেকর্ড তৈরি করে, কে আপডেট করতে পারে, এবং ব্যবসার প্রদত্ত নিয়ম কি বজায় রাখতে হবে।

সীমাবদ্ধতা, সমালোচনা, এবং বিকল্পগুলোর উত্থান

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

কোথায় কঠোর স্কিমা দ্রুত পরিবর্তন ধীর করে

রিলেশনাল স্কিমা একটি চুক্তি—টেবিল, কলাম, টাইপ, কনস্ট্রেইন্টগুলো কি “বৈধ ডেটা” তা সংজ্ঞায়িত করে। শেয়ার করা বোঝাপড়ার জন্য এটা চমৎকার, কিন্তু যখন প্রোডাক্ট দ্রুত বিকশিত হয় তখন এটি টিমকে ধীর করতে পারে।

নতুন ক্ষেত্র সাপ্তাহিকভাবে পাঠানোর সময় মাইগ্রেশন, ব্যাকফিল এবং ডিপ্লয়মেন্ট সমন্বয় বাঁধা হয়ে দাঁড়ায়—বিশেষত বড় টেবিল বা ২৪/৭ অনলাইন সিস্টেম থাকার ক্ষেত্রে।

NoSQL কেন উঠল (এবং কি লক্ষ্য করেছিল)

“NoSQL” রিলেশনাল ধারণা পুরোপুরি প্রত্যাখ্যান করেছিলো না, বরং নির্দিষ্ট ব্যথার পয়েন্টকে লক্ষ্য করে।

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

এগুলো অনেক সময় কনসিস্টেন্সি বা সমৃদ্ধ JOIN-কে ত্যাগ করে গতি, নমনীয়তা বা বিতরণ লাভ করে।

মিশ্র বাস্তবতা: রিলেশনাল + নন-রিলেশনাল

অধুনা স্ট্যাকগুলো পলিগ্লট: কোর ব্যবসায়িক রেকর্ডের জন্য রিলেশনাল ডাটাবেস, পাশাপাশি অনুষ্ঠানের স্ট্রীম, সার্চ ইনডেক্স, ক্যাশ, বা কনটেন্ট/অ্যানালিটিক্সের জন্য ডকুমেন্ট স্টোর। রিলেশনাল মডেল এখনও সত্যের উৎস, অন্য স্টোরগুলো পড়া-ভারী বা বিশেষ কুয়েরির জন্য কাজ করে।

টিমগুলোর সিদ্ধান্ত পয়েন্ট

নির্বাচন করলে লক্ষ্য রাখুন:

• কনসিস্টেন্সি প্রয়োজনীয়তা: এমন ট্রানজেকশন দরকার কি যা কখনো ভুল হতে পারে না?\n- কুয়েরি জটিলতা: কি আপনি JOIN, রিপোর্টিং ও অ্যাড-হক প্রশ্নে নির্ভর করবেন?\n- স্কেল প্যাটার্ন: লেখার-ভারী ইনজেশন, গ্লোবাল ডিস্ট্রিবিউশন, না কি স্পাইকি ট্র্যাফিক?

ভালো ডিফল্ট হচ্ছে কোর ডেটার জন্য SQL, তারপর যেখানে রিলেশনাল মডেল দৃশ্যত সীমিত সেইখানে বিকল্প যোগ করা।

আজকের জন্য প্রয়োগযোগ্য পাঠ: ব্যবসায়িক অ্যাপ বানাতে টিমদের জন্য শিক্ষা

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

ব্যবহারিক টেবিল-ডিজাইন টেকঅওয়ে

শুরুতে আপনার ব্যবসার বাস্তব-পদার্থগুলোকে টেবিল হিসেবে মডেল করুন (Customers, Orders, Payments) এবং সম্পর্কগুলো দিয়ে সংযুক্ত করুন।

কয়েকটি নিয়ম যা পরে অধিকাংশ ব্যথা রোধ করে:

• প্রতিটি টেবিলকে একটি স্থিতিশীল প্রাইমারি কী দিন (সাধারণত একটি সারোগেট ID)। নাম বা ইমেইলে নির্ভর করবেন না।
• রিলেশনগুলোর জন্য ফরেইন কী ব্যবহার করুন যাতে ডাটাবেস ভাঙা রেফারেন্স থামাতে পারে (একটি Order যে মিসিং Customer-কে নির্দেশ করবে না)।
• পুনরাবৃত্ত বা মাল্টি-ভ্যালু ক্ষেত্রগুলো আলাদা টেবিলে রাখুন (উদাহরণ: CustomerPhones—phone1, phone2, phone3 না করে)।
• “ফ্যাক্ট” এবং “লেবেল” আলাদা রাখুন: পরিমাণ ও কারেন্সি কোড আলাদাভাবে সংরক্ষণ করুন, ফরম্যাট করা স্ট্রিং নয়।

আপনি যদি এই নীতিগুলো থেকে একটি প্রকৃত প্রোডাক্ট বানান, তবে এমন টুলিং থাকা সুবিধাজনক যা স্কিমার উদ্দেশ্য ও অ্যাপ কোডকে সমন্বয় রাখে। উদাহরণস্বরূপ, Koder.ai একটি React + Go + PostgreSQL অ্যাপ চ্যাট প্রম্পট থেকে জেনারেট করতে পারে, যা একটি নরমালাইজড স্কিমা (টেবিল, কী, সম্পর্ক) প্রোটোটাইপ করা সহজ করে—তবে এখনও ডাটাবেসকে সত্যির উৎস হিসেবে রাখে এবং যখন আপনি পুরো নিয়ন্ত্রণ নিতে চান তখন সোর্স কোড এক্সপোর্ট দেয়।

ডাটাবেস পদ্ধতি বেছে নেওয়ার সময় জিজ্ঞেস করার মতো প্রশ্ন

যদি আপনার ডেটার শক্ত কোর জাচাই-গ্যারান্টি দরকার থাকে, জিজ্ঞেস করুন:

• কি আমাদের একাধিক আপডেট জুড়ে ট্রানজেকশন দরকার (অর্ডার তৈরি + স্টক রিজার্ভ + পেমেন্ট রেকর্ড)?\n- কি আমরা অ্যাড-হক কুয়েরি রিপোর্টিং ও অডিটের জন্য ভরসা করব?\n- কি ডেটা বিভিন্ন এন্টিটিগুলোর মধ্যে যোগ করা হবে (customers ↔ orders ↔ shipments)?

যদি উত্তর প্রায়ই “হ্যাঁ” হয়, একটি রিলেশনাল ডাটাবেস সাধারণত সহজতম পথ।

কিছু প্রচলিত ভুল ধারণা বাদ দিন

“SQL স্কেল করতে পারে না” বলা খুব বিস্তৃত। SQL সিস্টেম অনেক উপায়ে স্কেল করে (ইন্ডেক্স, ক্যাশিং, রিড রিপ্লিকা, প্রয়োজন হলে শার্ডিং)। অধিকাংশ টিম সত্যিকারের ডাটাবেস সীমা পড়ার আগে মডেলিং ও কুয়েরির সমস্যা সম্মুখীন হয়।

“নরমালাইজেশন সব কিছুকে ধীর করে”—এটাও অসম্পূর্ণ। নরমালাইজেশন অনোমালি কমায়; পারফর্ম্যান্স ইন্ডেক্স, কুয়েরি ডিজাইন এবং নির্বাচিত ডেনরমালাইজেশনের মাধ্যমে পরিচালনা করা যায়।

কড্ডের স্থায়ী প্রভাব

কড্ড টিমগুলোকে একটি ভাগ করা চুক্তি দিলেন: সম্পর্কিত টেবিলগুলোতে ডেটা সাজানো, সুসংজ্ঞায়িত অপারেশন দিয়ে ম্যানিপুলেশন, এবং কনস্ট্রেইন্ট দিয়ে রক্ষা। এই চুক্তির ফলে প্রতিদিনের সফটওয়্যার বছরের পর বছর বিকশিত হলেও মৌলিক প্রশ্নগুলো—“কি ঘটেছে, কখন এবং কেন?”—এবং তাদের উত্তরগুলোর নির্ভরযোগ্যতা বজায় থাকে।