ডোনাল্ড চেম্বলিন এবং SQL: ডাটাবেসে সহজে প্রশ্ন করার উপায়

কেন ডোনাল্ড চেম্বলিন এবং SQL এখনও গুরুত্বপূর্ণ\n\nডোনাল্ড ডি. চেম্বলিন হয়তো সবাই জানে এমন নাম নন, তবুও তার কাজ ডেটা নিয়ে অধিকাংশ সফটওয়্যার দল কীভাবে কাজ করে তা নীরবে গঠন করেছে। IBM-এ একজন গবেষক হিসেবে চেম্বলিন SQL (প্রথমে SEQUEL নামে) সহ-আবিষ্কার করেন—একটি ভাষা যা দৈনন্দিন ডেভেলপারদের, এমনকি অ-বিশেষজ্ঞদেরও বড় ডাটাবেস থেকে সহজে প্রশ্ন করার উপায় দিয়েছে।\n\nSQL-এর আগমনের আগে, স্টোর করা ডেটা থেকে উত্তর পেতে প্রায়ই কাস্টম প্রোগ্রাম লিখতে হত বা শক্তিশালী কিন্তু অপ্রাঞ্জল টুল ব্যবহার করতে হত। চেম্বলিন আলাদা একটি ধারনা পুশ করেছিলেন: কম্পিউটারকে ধাপে ধাপে কীভাবে ডেটা খুঁজে বের করতে হবে না বলে, বরং আপনি যা চান তা এমনভাবে বর্ণনা করা উচিত যা প্রায় সাধারণ ইংরেজির মত পড়ে।\n\n### এক সরল ধারণা, বিশাল ফলাফল\n\nSQL-এর মূলেই একটি আশ্চর্যজনকভাবে মানুষের পাঠ্য উপযোগী পদ্ধতি রয়েছে:\n\n- আপনি কোন ডেটা চান তা নাম দেন (SELECT)\n- কোথায় আছে তা বলেন (FROM)\n- শর্তগুলো বর্ণনা করেন (WHERE)\n\nএখন এটা স্বাভাবিক শোনালেও, তখন এটি একটি বড় পরিবর্তন ছিল। এটি “ডাটাবেসে কুয়েরি করা”কে বিশেষজ্ঞদের কাজ থেকে এমন কিছুতে পরিণত করল যা শেখানো, ভাগ করা, পর্যালোচনা এবং উন্নত করা যায়—সফটওয়্যারের যেকোন অংশের মত।\n\n### এই লেখাটি কী করবে (এবং কী করবে না)\n\nএটি SQL কীভাবে এসেছে এবং কেন এটি এত বিস্তৃতভাবে ছড়িয়ে পড়ল তার একটি বাস্তবসম্মত ইতিহাস।\n\nআপনাকে অ্যাডভান্সড ম্যাথ, ফরমাল লজিক বা গভীর ডাটাবেস থিওরি জানতে হবে না। আমরা মূলত কি সমস্যাগুলো SQL সমাধান করল, কেন এর ডিজাইন গ্রহণযোগ্য ছিল, এবং কীভাবে এটি ব্যাকএন্ড ইঞ্জিনিয়ারিং থেকে অ্যানালিটিকস, প্রোডাক্ট ও অপারেশনে ডিফল্ট দক্ষতা হয়ে উঠল সে দিকে ফোকাস করব।\n\nআপনি যদি কখনো একটি তালিকা ফিল্টার করেছেন, ফলাফল গ্রুপ করেছেন, বা দুই সেট তথ্য জয়েন করেছেন, তাহলে আপনি ইতিমধ্যে সেই চিন্তার দিকে কাজ করেছেন যা SQL জনপ্রিয় করেছিল। চেম্বলিনের স্থায়ী অবদান ছিল সেই চিন্তাকে এমন একটি ভাষায় রূপান্তর করা যে মানুষ বাস্তবে ব্যবহার করতে পারে।\n\n## SQL-এর আগে ডেটা কাজ দেখতে কেমন ছিল\n\nSQL-এর আগে বেশিরভাগ সংস্থা “ডাটাবেসে কুয়েরি” করত না। তারা ফাইলে ডেটা রেখে কাজ করত—প্রতিটি অ্যাপ্লিকেশনের জন্য প্রায়ই একটি ফাইল—যা সেই প্রোগ্রামটিই ম্যানেজ করত যা সেটি তৈরি করেছিল। পেরল-কে আলাদা ফাইল ছিল, ইনভেন্টরির আলাদা; গ্রাহক রেকর্ড অনেক সিস্টেম জুড়ে বিভক্ত থাকতে পারত।\n\nফাইল-ভিত্তিক পদ্ধতি কাজ করত যতক্ষণ না ব্যবসাগুলো এমন উত্তর চাইছিল যে সেটা সিস্টেম-ছাড়িয়ে যায়: “কোন গ্রাহকরা পণ্য X কিনেছে এবং তাদেরও বকেয়া ইনভয়েস আছে?” এমন ভিউ পেতে হলে এমন ডেটা জোড়া লাগত যা একত্রিত করার জন্য ডিজাইন করা হয়নি।\n\n### শেয়ার্ড ডেটা থেকে ছড়িয়ে থাকা ফাইলগুলো\n\nপ্রাথমিক অনেক সিস্টেমে ডেটা ফরম্যাট প্রোগ্রামের সাথে ঘনিষ্ঠভাবে জড়িত ছিল। কোথাও একটি পরিবর্তন—যেমন গ্রাহকের ফোন নম্বর যোগ করা—তাহলে প্রোগ্রাম পুনরায় লিখতে, ফাইল রূপান্তর করতে ও ডকুমেন্টেশন আপডেট করতে হত। এমনকি যখন “ডাটাবেস সিস্টেম” আসতে শুরু করল, অনেকেই তবুও নিম্ন-স্তরের অ্যাক্সেস মেথড দেখিয়েছিল যা প্রশ্ন করার বদলে প্রোগ্রামিংয়ের মত মনে হতো।\n\n### কেন প্রাথমিক ডেটা অ্যাক্সেস এত কঠিন ছিল\n\nআপনি যদি তথ্য পেতে চাইতেন, সাধারণত আপনার দুটি অপশন থাকত:\n\n- বিশেষজ্ঞদের কাছে কাস্টম প্রোগ্রাম অনুরোধ করা যাঁরা ফাইল স্ট্রাকচারগুলো বোঝেন।\n- কঠোর রিপোর্টে নির্ভর করা যা নির্দিষ্ট সময়ে (দৈনিক, সাপ্তাহিক) রান করত এবং সংকীর্ণ উদ্দেশ্যের জন্য ডিজাইন করা ছিল।\n\nউভয় অপশনই সহজ অনুসন্ধানকে সমর্থন করত না। সামান্য শব্দ পরিবর্তন—তারিখ সীমা যোগ করা, অঞ্চলভিত্তিক গ্রুপিং, রিটার্ন বাদ দেওয়া—নতুন ডেভেলপমেন্ট টাস্কে পরিণত হতে পারত। ফলে একটি বাধা তৈরি হত: প্রশ্নকারীকে কোড লিখতে পারা লোকদের জন্য অপেক্ষা করতে হত।\n\n### অনুপস্থিত অংশ: একটি সাধারণ ভাষা\n\nসংস্থাগুলো যা হারিয়েছিল তা ছিল ডেটা প্রশ্ন প্রকাশ করার একটি ভাগ করা উপায়—কোনো কিছু যা মেশিনের জন্য যথাযথ কিন্তু মানুষের জন্যও পাঠযোগ্য। ব্যবসায়ী “গ্রাহক”, “অর্ডার”, “টোটাল” চিন্তা করে। সিস্টেমগুলো ছিল ফাইল লেআউট এবং প্রোসেজুরাল ধাপ ঘিরে।\n\nএই বিভেদই কুয়েরি ভাষার চাহিদা তৈরি করল: এমন একটি ধারাবাহিক, পুনঃব্যবহারযোগ্য উপায় যা প্রতিবার নতুন প্রোগ্রাম না লিখেই আপনি কী চান তা বলে দিতে পারে। এবং সেই প্রয়োজন SQL-কে সাফল্যের মঞ্চ তৈরি করে দিল।\n\n## রিলেশনাল ধারণা যা মঞ্চ তৈরি করল\n\nSQL থাকতে হলে ডাটাবেস জগতের আগে ডেটা সম্পর্কে ভাবার একটি পরিষ্কার উপায় দরকার ছিল। রিলেশনাল মডেল সেটাই দিল: একটি সোজা, ধারাবদ্ধ কাঠামো যেখানে তথ্য টেবিলে (রিলেশন) রাখা হয়, সারি ও কলাম নিয়ে।\n\n### পরিষ্কার লক্ষ্য: কাস্টম-ওয়্যারিংয়ের বদলে সঙ্গতি\n\nরিলেশনাল মডেলের মূল প্রতিশ্রুতি সহজ ছিল: প্রতিটি অ্যাপ্লিকেশনের জন্য একক, কঠোরভাবে বজায় রাখা ডেটা স্ট্রাকচার বানানো বন্ধ করুন। বরং ডেটা একটি স্ট্যান্ডার্ড ফরমে রাখুন এবং বিভিন্ন প্রোগ্রাম আলাদা আলাদা প্রশ্ন করতে পারুক ডেটা সংগঠন পরিবর্তন না করেই।\n\nএই পরিবর্তন গুরুত্বপূর্ণ ছিল কারণ এটি দুই জিনিসকে আলাদা করে দিল যা আগে জড়িয়ে থাকত:\n\n- কীভাবে ডেটা সংরক্ষিত হয় (ভালভাবে সংজ্ঞায়িত কলামের টেবিল)\n- কীভাবে ডেটা ব্যবহৃত হয় (প্রশ্নগুলো দিন-দিন পরিবর্তিত হতে পারে)\n\nযখন এসব আলাদা হয়, ডেটা ভাগ করা সহজ হয়, আপডেট নিরাপদ হয়, এবং নির্দিষ্ট অ্যাপ্লিকেশনের কিউরগির ওপর এর নির্ভরশীলতা কমে যায়।\n\n### Edgar F. Codd-এর প্রভাব—হিরো গল্প নয়\n\nEdgar F. Codd, IBM-এ কাজ করে, এই ধারণা ফরমালাইজ করে দিয়েছিলেন এবং কেন এটা ফিক্সড-রেকর্ড পথ অনুসরণের চেয়ে ভালো তা ব্যাখ্যা করেছিলেন। পূর্ণ একাডেমিক পটভূমি না জেনেও আমরা তার প্রভাবকে বুঝতে পারি: তিনি শিল্পকে এমন একটি মডেল দিলেন যা যুক্তি করা, পরীক্ষা করা ও উন্নত করা যায়।\n\n### কেন এটা বাস্তবে নতুন ধরনের কুয়েরি ভাষা দাবি করত\n\nএকবার ডেটা টেবিলে থাকলে, স্বাভাবিক পরবর্তী প্রশ্ন হল: সাধারণ মানুষ কীভাবে যা দরকার তা চায়? স্টোরেজ লোকেশন নির্দেশ করে নয়, বরং ফলাফল বর্ণনা করে।\n\nওই “আপনি যা চান সেটা বর্ণনা করুন” পদ্ধতি—এই কলামগুলো বাছুন, এই সারিগুলো ফিল্টার করুন, এই টেবিলগুলো মিলান—একটি মানুষের জন্য সহজ কুয়েরি ভাষার পথ তৈরি করল। SQL তাই রিলেশনাল তত্ত্বকে দৈনন্দিন কাজে নিয়ে আসার জন্য তৈরি করা হয়েছিল।\n\n## IBM System R এবং একটি ভালো কুয়েরি ভাষার খোঁজ\n\nIBM System R প্রথমে কোনো বাণিজ্যিক পণ্য ছিল না—এটি একটি গবেষণা প্রকল্প যা একটি বাস্তব প্রশ্নের উত্তর খুঁজছিল: Edgar F. Codd-এর রিলেশনাল মডেল বাস্তবে, বাস্তব স্কেলে, বাস্তব ব্যবসায়িক ডেটার সঙ্গে কাজ করতে পারে কি না?\n\nসেই সময়ে অনেক ডাটাবেস সিস্টেম শারীরিক অ্যাক্সেস পথ এবং রেকর্ড-বাই-রেকর্ড লজিকের মাধ্যমে নেভিগেট করা হত। রিলেশনাল ডাটাবেস ভিন্ন কিছু প্রতিশ্রুত করেছিল: ডেটা টেবিলে রাখুন, সম্পর্ক পরিষ্কারভাবে বর্ণনা করুন, এবং সিস্টেমটি কীভাবে ফলাফলগুলো উদ্ধার করবে তা বের করে নিক। কিন্তু সেই প্রতিশ্রুতি কাজ করার জন্য দুটি জিনিস একসাথে কাজ করতে হতো: একটি রিলেশনাল ইঞ্জিন যা ভাল পারফর্ম করে এবং একটি কুয়েরি ভাষা যা সাধারণ ডেভেলপাররা (এবং কিছু অ-ডেভেলপার) ব্যবহার করতে পারে।\n\n### System R কী প্রমাণ করার চেষ্টা করছিল\n\nSystem R, IBM-এর সান হোসে রিসার্চ ল্যাবরেটরিতে 1970-এর দশকে তৈরি, একটি প্রোটোটাইপ রিলেশনাল ডাটাবেস ম্যানেজমেন্ট সিস্টেম তৈরির এবং রিলেশনাল ধারণাকে স্ট্রেস-টেস্ট করার লক্ষ্য রাখে।\n\nএকইভাবে গুরুত্বপূর্ণ ছিল এমন কৌশলগুলো অন্বেষণ করা—বিশেষ করে কুয়েরি অপ্টিমাইজেশন। যদি ব্যবহারকারীরা উচ্চ-স্তরের অনুরোধ লিখতেন ("এই শর্ত মেলানো রেকর্ডগুলো নিয়ে আসুন"), সিস্টেমটিকে সেই অনুরোধগুলোকে স্বয়ংক্রিয়ভাবে কার্যকর অপারেশনে অনুবাদ করতে হবে।\n\n### চেম্বলিনের ভূমিকা ও দলের প্রেক্ষাপট\n\nDonald Chamberlin, IBM-এর গবেষণা পরিবেশে কাজ করে, অনুশীলনে অনুপস্থিত টুকরোটি নিয়ে মনোনিবেশ করেছিলেন: রিলেশনাল ডেটার উপর প্রশ্ন করার জন্য একটি ব্যবহারিক ভাষা। সহযোগীদের (বিশেষত Raymond Boyce) সঙ্গে তিনি এমন একটি কুয়েরি ভাষা গঠন করার ওপর কাজ করেছিলেন যা মানুষের প্রাকৃতিকভাবে ডেটা চাহিদা বর্ণনা করার সাথে খাপ খাইয়ে যায়।\n\nএটি শূন্যে ভাষা ডিজাইন ছিল না। System R প্রতিক্রিয়া-লুপ প্রদান করত: যদি কোনো ভাষা ফিচার কার্যকরভাবে বাস্তবায়ন করা না যেত, তা টিকে থাকতে পারত না। কোনো ফিচার যদি সাধারণ কাজগুলোকে সহজ করে, তা ত্বরিতই গতি পেল।\n\n### ভাষার প্রয়োজনীয়তাগুলো অনন্য কেন ছিল\n\nCodd রিলেশনাল মডেল ফরমাল গণিতে (রিলেশনাল আলজেবরা ও রিলেশনাল ক্যালকুলাস) বর্ণনা করেছিলেন। এসব শক্তিশালী ছিল, কিন্তু দৈনন্দিন কাজের জন্য খুব একাডেমিক ছিল। System R-কে এমন একটি ভাষা দরকার ছিল যা:\n\n- ঘোষণামূলক (আপনি কি চান বলুন, কীভাবে তা তোলা হবে তা নয়)\n- পাঠযোগ্য যাতে শেখানো ও ভাগ করা যায়\n- কঠোর পারফর্ম্যান্সসহ বাস্তবে বাস্তবায়নযোগ্য\n\nএই সন্ধান—একটি কর্মরত রিলেশনাল প্রোটোটাইপ দ্বারা ভিত্তি করে—SEQUEL এবং পরে SQL-এর পথ তৈরি করল।\n\n## SEQUEL থেকে SQL: মানুষের পক্ষে বন্ধুত্বপূর্ণ ডিজাইন\n\nDonald Chamberlin এবং তাঁর সহযোগীরা তাদের নতুন ভাষার নাম প্রথমে রাখেছিলেন SEQUEL, যার পূর্ণরূপ Structured English Query Language। নাম থেকেই মূল ধারণা স্পষ্ট: ডেটা নেভিগেট করার জন্য প্রোসেজুরাল কোড লিখার বদলে আপনি এমনভাবে লিখবেন যা প্রায়ই সাধারণ ইংরেজির মতো অনুভব হয়—আপনি যা চান সেটা বলবেন।\n\nপরবর্তীতে SEQUEL সংক্ষিপ্ত করে SQL রাখা হয় (চাপের কারণে—ছোট, সহজে বলা যায়, ট্রেডমার্ক বিবেচনায় সুবিধাজনক)। কিন্তু “স্ট্রাকচারড ইংলিশ” উদ্দেশ্য ঠিক অনুরূপ রয়ে গেল।\n\n### অনুরোধের মত পড়ে এমন একটি ভাষা\n\nডিজাইনের লক্ষ্য ছিল ডাটাবেস কাজকে একটি পরিষ্কার অনুরোধের মত করা:\n\n- SELECT সেই তথ্য বেছে নিন যা আপনি চান\n- FROM কোথা থেকে তা আসছে\n- WHERE কোন শর্তগুলো সত্য হওয়া উচিত\n\nএই গঠন মানুষের মস্তিষ্কে একটি ধারাবদ্ধ মডেল দিয়েছিল। আপনাকে কোনো বিক্রেতার বিশেষ নেভিগেশন রুল শিখতে হতো না; একটি পাঠযোগ্য প্যাটার্ন শিখলেই হয়—প্রশ্ন করা শিখলেন।\n\n### ছোট উদাহরণ: ফিল্টার, সাজানো, সংক্ষেপ করা\n\nকল্পনা করুন একটি ব্যাবসায়িক প্রশ্ন: “কেই গ্রাহকরা ক্যালিফোর্নিয়াতে সবচেয়ে বেশি খরচ করেছে এই বছরে?” SQL আপনাকে সেই ইচ্ছেটিকে সরাসরি প্রকাশ করতে দেয়:\n\n```sql

SELECT customer_id, SUM(amount) AS total_spent FROM orders WHERE state = 'CA' AND order_date >= '2025-01-01' GROUP BY customer_id ORDER BY total_spent DESC; sql SELECT customer_name, COUNT(*) AS order_count FROM orders JOIN customers ON orders.customer_id = customers.customer_id WHERE orders.status = 'Shipped' GROUP BY customer_name; sql SELECT product, SUM(revenue) FROM sales WHERE sale_date >= '2025-01-01' GROUP BY product;