Google Sheet থেকে রিলেশনাল স্কিমা: ধাপে ধাপে মডেলিং পরিকল্পনা

কেন স্প্রেডশীট ডাটাবেস হলে গোছানো থাকে না

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

ডেটা বাড়ার সঙ্গে সঙ্গে একই সমস্যা বারবার দেখা যায়। আপনি ডুপ্লিকেট পাবেন কারণ কাস্টমার বা প্রোডাক্ট রাখার একক জায়গা নেই। দুইটি সারি একই বিষয়ে ভিন্ন মান বললে conflicting values হবে, যেমন ফোন নম্বর। ফিল্টার ও রিপোর্টিং হতাশাজনক হয় কারণ কিছু কলাম তালিকা লুকায় ("Tags", "Products", "Attendees") বা ফরম্যাট মিশে যায় ("$1,200", "1200", "1.2k").

Google Sheet থেকে রিলেশনাল স্কিমায় যাতায়াত বেশিরভাগ ক্ষেত্রেই নিরাপত্তার কথা। একটি ডাটাবেস পরিষ্কার স্ট্রাকচার জোর দেয় যাতে আপনি কুয়েরি, ভ্যালিডেট এবং আপডেট করতে পারেন নতুন বিরোধ না সৃষ্টি করে।

একটি উপযোগী মানসিক মডেল: এক সারি একটি বাস্তব জিনিসকে প্রতিনিধিত্ব করা উচিত। যদি একটি সারি একই সঙ্গে একটি ডীল, একটি কাস্টমার, এবং প্রোডাক্টের একটি তালিকা বোঝায়, পরে তাদের যেকোনো একটিকে আপডেট করা কষ্টকর হবে।

দ্রুত পরীক্ষা: একক সারি কখনো কি একই ফিল্ডের জন্য দুইটি মান দরকার?

• একটি অর্ডারের একাধিক প্রোডাক্ট থাকতে পারে
• একটি প্রকল্পে একাধিক টিম মেম্বার থাকতে পারে
• একটি কাস্টমারের একাধিক ঠিকানা থাকতে পারে

যদি উত্তর হ্যাঁ, তাহলে এটা “wide row” সমস্যা নয়। এটা “অলাদা টেবিল” সমস্যা। একবার আপনি এটা পরিষ্কারভাবে মডেল করলে, আপনি দুর্বল ম্যানুয়াল এডিটের উপর নির্ভর না করে ফর্ম ও ভ্যালিডেশন বানাতে পারবেন।

শুরু করুন: শিটটি আসলে কী বোঝায় তা নির্ধারণ করে

একটি স্প্রেডশীট organizado দেখা গেলেও তা বিভিন্ন মানুষের কাছে বিভিন্ন অর্থ বহন করতে পারে। Google Sheet থেকে relational schema-তে রূপান্তর করার আগে, ঠিক করুন শিটটি কী ট্র্যাক করছে।

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

এরপর হেডার ও নোটে লুকিয়ে থাকা নামগুলি বের করুন। এগুলো সাধারণত আপনার ভবিষ্যৎ টেবিল হবে: customers, orders, products, invoices, tickets, agents, locations. যদি একটি কলাম দুইটি নাম মিশিয়ে রাখে (যেমন “Customer + Company”), আপনি এক জায়গায় একাধিক জিনিস স্টোর করছেন।

আগে সংজ্ঞায় একমত হোন

অর্থে ছোট ফারাকগুলো পরে বড় ক্লিনআপে পরিণত হয়। বেসিকগুলো সম্পর্কে স্পষ্ট হন:

• একটি “order” কী হিসেবে গণ্য (একটি quote, একটি পেইড পারচেজ, নাকি উভয়)?
• একটি “customer” কী (ব্যক্তি, কোম্পানি, না উভয়)?
• একটি অর্ডারে কি একাধিক প্রোডাক্ট হতে পারে?
• একটি ইমেইল কি একাধিক কাস্টমারের সাথে থাকতে পারে?
• “status” দেখাতে চায় কি (বর্তমান অবস্থা না ইতিহাস)?

উদাহরণ: যদি আপনার শিটে প্রতি সারি একটি “Order” বোঝায় কিন্তু “Products” সেলে কমা-সেপারেটেড তালিকা থাকে, ঠিক করুন সেই সারিটি চেকআউট, শিপমেন্ট, নাকি ইনভয়েস প্রতিনিধিত্ব করে। প্রতিটি পছন্দ ভিন্ন স্কিমার দিকে নিয়ে যাবে।

মূল শিটের একটি কপি read-only হিসেবে ফ্রিজ করে রাখুন। আপনি এটি ব্যবহার করবেন নতুন টেবিলগুলো এখনও একই প্রশ্নগুলোর উত্তর দেয় কি না যাচাই করতে।

শিটকে পরিষ্কার করুন যাতে স্ট্রাকচার দৃশ্যমান হয়

Google Sheet থেকে relational schema-তে যাওয়ার আগে, শিটটিকে রিপোর্ট নয় বরং ডেটার মতো করে সাজান। ডাটাবেস ধারাবাহিক সারি ও কলাম প্রত্যাশা করে। অলংকারি লেআউট এমন প্যাটার্ন লুকিয়ে দেয় যা আপনি মডেল করতে চান।

merged সেল, বহু হেডার রো, এবং ডেটা রেঞ্জের ভেতরে subtotals মতো লেআউট কৌশলগুলো সরান। একটি হেডার রো রাখুন এবং তারপর শুধুই রেকর্ডের সারি রাখুন। যদি টোটাল দরকার হয়, আলাদা summary ট্যাব-এ রাখুন যাতে আসল রেকর্ডগুলোর সাথে মিশে না যায়।

এরপর প্রতিটি কলামে ফরম্যাট একরকম করুন। একটি ডেটাবোার এটা অনুমান করতে পারে না যে “1/2/24”, “2024-02-01”, এবং “Feb 1” একই তারিখ। একই নিয়ম ফোন নম্বর, কারেন্সি, এবং নামের ক্ষেত্রেও প্রযোজ্য। এক ফরম্যাট বেছে নিন এবং প্রতিটি জায়গায় সেটি ব্যবহার করুন, যদিও এটা কড়া মনে হতে পারে।

একটি ছোট ক্লিনআপ যেটা সাধারণত ফলপ্রসূ:

• নিশ্চিত করুন প্রতিটি সারি একটি জিনিস প্রতিনিধিত্ব করে (একটি অর্ডার, এক কাস্টমার, এক টিকেট)।
• খালি spacer সারি ও কলামগুলো সরান।
• “N/A”, “-”, এবং empty strings এক রুলে রূপান্তর করুন যা আপনি বজায় রাখবেন।
• কোন কলাম গণিত সূত্র দ্বারা নির্ধারিত এবং কোনগুলো মানুষ টাইপ করে তা চিহ্নিত করুন।

অবশেষে, যেসব সেলে একাধিক মান আছে সেগুলো চিহ্নিত করুন, যেমন একটি কলামে “red, blue, green”. স্কিমা এখনই ঠিক করবেন না—শুধু চিহ্নিত করুন যাতে পরে এসব কলাম আলাদা সারিতে পরিণত হবে।

পুনরাবৃত্ত গ্রুপ ও তালিকা লুকিয়ে রাখার ফিল্ড চিহ্নিত করুন

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

যে প্যাটার্নগুলো সাধারণত বলে “এটা আলাদা টেবিল হওয়া উচিত”

স্ক্যান করুন এ রকম আকৃতি:

• নাম্বার করা কলামগুলো যেমন Item 1, Item 2, Item 3 বা Phone 1, Phone 2.
• repeated ব্লকগুলো যেমন Home এবং Work-এর জন্য address ফিল্ডের ডুপ্লিকেট।
• সেলে কমা, লাইনে ব্রেক, বা “and” দিয়ে একাধিক মান কম্বাইন আছে (উদাহরণ: “Mouse, Keyboard, Monitor”).
• একটি কলাম দুইটি ধারণা মিশায়, যেমন “Approved 2025-01-10” বা “Alex (Manager)”.
• একটি সারি দুইটি স্তর একসাথে প্রতিনিধিত্ব করে, যেমন একটি Order সারি যা একই সঙ্গে Order Items সব গুলো রাখার চেষ্টা করে।

উদাহরণ: যদি আপনার সেলস ট্র্যাকার Order ID, Customer, Product 1, Qty 1, Product 2, Qty 2 ব্যবহার করে, আপনি বাধার সম্মুখীন হবেন। কিছু অর্ডারে 1 আইটেম আছে, কিছুতে 8। শিটটা বা তো পাশ বরাবর বাড়বে না তাও ডেটা হারাতে শুরু করবে। রিলেশনাল মডেলে, “Orders” একটি টেবিল হবে এবং “Order Items” আরেকটি টেবল হবে যাতে প্রতি প্রোডাক্টের জন্য একটি সারি থাকবে।

“সেলে তালিকা” ক্ষেত্রে প্রতিটি মানকে আলাদা রেকর্ড হিসেবে ব্যাহত করুন। একটি সেলে “Email, SMS” থাকলে সাধারণত একটি আলাদা টেবিল (বা join টেবিল) দরকার যা চ্যানেলগুলো পরিষ্কারভাবে ট্র্যাক করবে।

মিশ্র কলামগুলো শান্ত কিন্তু একইভাবে ঝুঁকিপূর্ণ। সেগুলোকে শিগগিরই আলাদা করুন যাতে প্রতিটি ফিল্ড এক স্পষ্ট তথ্য রাখে।

আপনি যে সত্তাগুলো পেয়েছেন সেগুলো থেকে টেবিল তৈরি করুন

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

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

চূড়ান্ত করার আগে প্রতিটি টেবিলের জন্য এক বাক্যের উদ্দেশ্য লিখুন। যদি আপনি একটি টেবিল বর্ণনা করতে না পারেন ও বাক্যে “এবং এছাড়াও” বলতে হয়, তা সাধারণত খুব বিস্তৃত।

কিছু ব্যবহারিক নিয়ম:

• একই জিনিস বর্ণনা করে এমন ও একই lifecycle শেয়ার করা অ্যাট্রিবিউটগুলো একসাথে রাখুন (customer name এবং customer email)।
• যা একাধিকবার উপস্থিত হতে পারে তা আলাদা টেবিলে সরান (multiple order items, multiple addresses)।
• যদি একটি সেলে তালিকা থাকে (কমা-সেপারেটেড ভ্যালু, repeated কলাম), তা আলাদা টেবিল।
• যদি দুটি সেট ফিল্ড আলাদা কারণে পরিবর্তিত হয়, আলাদা রাখুন (order status বনাম customer contact info)।

এরপর কলামগুলো স্পষ্ট ও সুনির্দিষ্ট নাম দিন। সাধারণ নামগুলোর দিকে ঝুঁকুন এবং “Info” বা “Details” মতো অস্পষ্ট লেবেল এড়িয়ে চলুন।

এমন কী কী কী (Primary) কী বেছে যা সময়ের সঙ্গে স্থিতিশীল থাকবে

প্রতি টেবলের জন্য একটি primary key আগে নির্বাচন করুন। একটি ভাল কী হলো বিরক্তিকর: এটা কখনো বদলায় না, সবসময় উপস্থিত থাকে, এবং একটি সারিই শনাক্ত করে।

Natural keys (বাস্তব-জগতের মান) কাজ করতে পারে, কিন্তু কেবল যদি সেগুলো সত্যিই স্থিতিশীল হয়। একটি SKU প্রায়ই ভাল natural key কারণ তা স্থায়ী রাখার উদ্দেশ্যে তৈরি। ইমেইল ঠিকানাগুলো স্থিতিশীল শোনালেও মানুষ ইমেইল বদলে দেয়, ইনবক্স শেয়ার করে, এবং ডুপ্লিকেট তৈরি করে। নাম, ফোন নম্বর, ও ঠিকানা বদলে যায় এবং ইউনিক নাও হতে পারে।

একটি নিরাপদ ডিফল্ট হলো auto-generated ID (যেমন customer_id, order_id). বাস্তব-জগতের শনাক্তকারী সাধারণ ফিল্ড হিসেবে রাখুন এবং যেখানে ব্যবসায়িক নিয়ম করে দেয় সেখানে uniqueness নিয়ম দিন। কেউ ইমেইল বদলে দিলেও customer_id একই থাকবে এবং সম্পর্কিত অর্ডারগুলো ঠিক কাস্টমারের দিকে ইঙ্গিত করবে।

সাধারণ কী নিয়ম:

• বাস্তব-জগত শনাক্তকারী বদলাতে পারে, অনুপস্থিত হতে পারে, বা পুনরায় ব্যবহার হতে পারে বলে auto ID ব্যবহার করুন।
• Natural key ব্যবহার করুন কেবল যখন আপনি তা নিয়ন্ত্রন করেন এবং তা স্থায়ী হওয়ার মতো ডিজাইন করা (উদাহরণ: SKU)।
• যেগুলো ডুপ্লিকেট হলে ভুল হবে সেগুলোকে unique হিসাবে চিহ্নিত করুন।
• NULL কেবল তখনই অনুমোদন করুন যখন “অজানা” একটি গ্রহণযোগ্য অবস্থা; না হলে মান বাধ্যতামূলক রাখুন।
• লিখে রাখুন “unique” মানে কি (টেবিল-স্তরে, কোম্পানি-স্তরে, না সময়কালের ভিত্তিতে)।

উদাহরণ: Contacts টেবিলে contact_id কে primary key হিসেবে ব্যবহার করুন। email কেবল তখনই unique রাখুন যখন আপনার নিয়ম এক contact = এক email। phone খালি রাখতে দিন কারণ সবাই ফোন শেয়ার করে না বা দেয় না।

অনুমান না করে সম্পর্ক ম্যাপ করুন

অধিকাংশ বড় ভুল গুলো সম্পর্ক অনুমান করার সময় হয়। একটি সরল নিয়ম ব্যবহার করুন: যদি এক সারি অনেক কিছুর “মালিক” হয়, তা one-to-many। foreign key রাখুন “many” সাইডে।

উদাহরণ: এক Customer অনেক Orders থাকতে পারে। Orders টেবিলে customer_id রাখুন। যদি আপনি Customers-এ কমা-সেপারেটেড অর্ডার নম্বর রাখেন, দ্রুত ডুপ্লিকেট ও মিসিং ডেটা দেখা যাবে।

Many-to-many হল সাধারণ স্প্রেডশীট ফাঁদ। যদি একটি Order অনেক Products রাখতে পারে এবং একটি Product অনেক Orders-এ থাকতে পারে, তখন একটি join টেবিল দরকার (সাধারণত line items নামে)। এতে সাধারণত order_id, product_id, এবং quantity ও প্রাপ্ত সময়ের দাম থাকে।

One-to-one সম্পর্ক বিরল। সেটা তখনই মানায় যখন অতিরিক্ত ডেটা ঐচ্ছিক বা প্রাইভেসি/পারফরম্যান্স কারণে আলাদা রাখা হয় (উদাহরণ: User এবং UserProfile)। যদি আপনি কেবল একটি শিটের দুইটি ট্যাবের কারণে টেবিল ভাগ করে ফেলেন, সেটা সতর্কতার সংকেত।

ইতিহাসের ডেটার জন্য আলাদা স্ট্রাকচার দরকার। যদি মান সময়ে পরিবর্তিত হয় (status, price, address), একটি মাত্র কলাম overwrite করা এড়ান। পরিবর্তনগুলো history টেবিলে রো হিসেবে সঞ্চয় করুন যাতে আপনি জবাব দিতে পারেন "কোন ঐ তারিখে কী সত্য ছিল?"।

বিরোধ প্রতিরোধ করার জন্য যথেষ্টভাবে নরমালাইজ করুন

সহজ নিয়ম: একটি বিষয় এক জায়গায় রাখুন। যদি একটি কাস্টমারের ফোন নম্বর পাঁচটি সারিতে থাকে, কেউ চারটি আপডেট করবে এবং একটি ভুলে যাবে।

নরমালাইজেশন সরল ভাষায়:

1NF, 2NF, 3NF বাস্তবিকভাবে

First normal form (1NF) মানে প্রতিটি সেল এক মান রাখে। যদি একটি কলামে “red, blue, green” বা “SKU1|SKU2|SKU3” থাকে, সেটা লুকানো তালিকা। এটি সম্পর্কিত টেবিলে রোতে ভাঙুন।

Second normal form (2NF) প্রায়ই line items-এ দেখা যায়। যদি আপনার OrderItems টেবিলের কী (OrderID, ProductID) হয়, তাহলে CustomerName সেখানে থাকা উচিত নয়। সেটি order-এ নির্ভর করে, product-এ নয়।

Third normal form (3NF) মানে non-key ফিল্ডগুলো অন্য non-key ফিল্ডের ওপর নির্ভর করবে না। উদাহরণ: ZipCode এবং City একই সঙ্গে আছে এবং City ZipCode দ্বারা নির্ধারিত হলে আপনি mismatch ঝুঁকি নিচ্ছেন।

একটি দ্রুত স্ব-চেক:

• একই মান কি একের বেশি জায়গায় এডিট করা যেতে পারে?
• একটি পরিবর্তন কি অনেক সারি আপডেট করতে বলবে?
• আপনি কি ID থেকে বের করে নেওয়া লেবেলগুলো স্টোর করছেন?
• টোটালগুলো কি তাদের কাঁচা সারির পাশে স্টোর করা আছে যেগুলো এগুলো উৎপন্ন করে?

কখন ডিনরমালাইজ করা যায়

মূলত রিড-হেভি রিপোর্টিংয়ের জন্য ডিনরমালাইজ করুন, এবং সেটি নিরাপদভাবে করুন: রিপোর্ট টেবিলকে একটি কপি হিসেবে ধরুন যা পুনর্নির্মাণ করা যায়। normalized টেবিলগুলো সোর্স-অব-ট্রুথ রাখুন।

Derived মান যেমন totals, balances, এবং status কপি না করে কেবল তখনই রাখুন যখন পারফরম্যান্সের কারণে দরকার এবং পুনঃহিসাবের একটি স্পষ্ট নিয়ম থাকে। একটি ব্যবহারিক পদ্ধতি: কাঁচা ট্রানজাকশনগুলো স্টোর করুন, কুয়েরিতে টোটাল হিসাব করুন, এবং কেবল পারফরম্যান্স দরকার হলে টোটাল ক্যাশ করুন।

ভবিষ্যতে ক্লিনআপ দরকার করে এমন সাধারণ মডেলিং ফাঁদগুলো

অনেকগুলো “শিটে কাজ করেছিল” সমস্যা টুল নয়, অর্থাৎ অর্থ থেকে আসে। লক্ষ্য হল প্রতিটি সারি একটি স্পষ্ট বিষয়ে একরকমভাবে বলুক, প্রতিবার।

সাধারণ ফাঁদগুলো:

• নেমকে ID হিসেবে ব্যবহার করা। “John Smith” একটি ইউনিক আইডেন্টিফায়ার নয়, এবং নাম বদলে যায়। একটি জেনারেটেড ID ব্যবহার করুন (বা একটি ভেরিফাই করা ইমেইল/ফোন), এবং display names লেবেল হিসেবে বিবেচনা করুন।
• তালিকাগুলো এক সেলে প্যাক করা। এটা সহজ দেখায়, কিন্তু সার্চ, ভ্যালিডেশন, এবং রিপোর্টিং ভাঙে। তালিকা সম্পর্কিত টেবিলে থাকা উচিত।
• বর্তমান অবস্থা এবং ইতিহাস মিশানো। একটি lone Status কলাম একই সঙ্গে সাম্প্রতিক স্ট্যাটাস এবং কীভাবে এটা পরিবর্তিত হয়েছে—দুটোই বলতে পারে না। যদি timing গুরুত্বপূর্ণ হয়, স্ট্যাটাস পরিবর্তনগুলো ইভেন্ট হিসেবে টাইমস্ট্যাম্প সহ রাখুন।
• এক টেবিলকে অনেক জিনিস বোঝাতে ওভারলোড করা। একটি Contacts শিট যা customers, vendors, এবং employees একসাথে রাখে সাধারণত এমন ফিল্ড জেনারেট করে যা কেবল কিছু সারির জন্য প্রযোজ্য। ভূমিকা অনুযায়ী ভাগ করুন, অথবা একটি shared Person টেবিল রাখুন এবং role-specific টেবিল যোগ করুন।
• প্রয়োজনীয় বনাম ঐচ্ছিক ফিল্ডগুলো উপেক্ষা করা। যদি কী ফিল্ডগুলো খালি থাকতে পারে, আপনি এমন সারি পাবেন যা সঠিকভাবে join হতে পারবেন না। কী দরকার তা সিদ্ধান্ত নিন এবং প্রাথমিকেই enforce করুন।

আপনার Orders টেবিলে যদি Item 1, Item 2, Item 3 মত কলাম থাকে, আপনি একটি repeating group দেখছেন। পরিকল্পনা করুন Orders টেবিল এবং OrderItems টেবিল তৈরি করার।

স্কিমা লক করার আগে দ্রুত চেকলিস্ট

স্কিমা লক করার আগে একটি চূড়ান্ত পাস করে নিন। বেশিরভাগ ডাটাবেসের পরে ব্যথা ছোট শর্টকাট থেকে আসে যা প্রথমে ক্ষুদ্র মনে হত।

জিজ্ঞাসা করুন প্রতিটি টেবিল একটি সরল প্রশ্নের উত্তর দেয় কি না। “Customers” মানে কাস্টমার, কাস্টমার এবং তাদের সর্বশেষ অর্ডার এবং কল নোট নয়। যদি আপনি একটি টেবিল এক বাক্যে বর্ণনা করতে না পারেন, তা মিশ্রিত হচ্ছে।

চূড়ান্ত চেকগুলো:

• আপনি কি কলাম (বা কলামের সেট) নির্দেশ করতে পারেন যা প্রতিটি সারিকে ইউনিকভাবে চিহ্নিত করবে, এমনকি নাম বদলালে?
• কোনো সেলে একের বেশি মান আছে কি (কমা-সেপারেট ট্যাগ, একাধিক ইমেইল, Item1/Item2 কলাম)? যদি আছে, তা child টেবিলে ভাগ করুন।
• প্রতিটি সম্পর্ক উদ্দেশ্যমাফিকভাবে foreign key হিসেবে সংরক্ষিত আছে কি? many-to-many হলে join টেবিল আছে কি?
• গুরুত্বপূর্ণ ফিল্ডগুলো কি নিয়ম পেয়েছে (required যেখানে মিসিং ডেটা প্রক্রিয়াটি ভেঙে দেয়, unique যেখানে ডুপ্লিকেট ক্ষতিকর)?
• আপনি কি একটি তথ্য (customer address, product price, employee role) একবারে এক জায়গায় আপডেট করতে পারবেন?

রিয়েলিটি টেস্ট: কল্পনা করুন কেউ একই কাস্টমারকে সামান্য ভিন্ন বানান দিয়ে দুইবার ঢুকিয়েছে। যদি আপনার স্কিমা সেটা সহজ করে দেয়, একটি ভাল কী বা uniqueness নিয়ম যোগ করুন।

উদাহরণ: একটি সেলস ট্র্যাকার শিটকে পরিষ্কার টেবিলে রূপান্তর

একটি সেলস ট্র্যাকার কল্পনা করুন যেখানে প্রতি সারি একটি ডিল। এতে কলাম রয়েছে: Customer Name, Customer Email, Deal Amount, Stage, Close Date, Products (কমা-সেপারেটেড তালিকা), এবং Notes (ক্লোজ-ডাউন নোট অনেক সময় এক সেলে একাধিক)।

একটি সারি দুইটি repeating group লুকায়: products (এক ডিল একাধিক প্রোডাক্ট থাকতে পারে) এবং notes (এক ডিল অনেক নোট থাকতে পারে)। কনভার্সনগুলো প্রায়ই এখানেই ভুল হয়, কারণ সেলে তালিকাগুলো কুয়েরি করা কঠিন এবং বিরোধ তৈরি করা সহজ।

একটি পরিষ্কার “পরবর্তী” মডেল যা কাজের আচরণকে মিলে:

• Customers (CustomerId, Name, Email)
• Deals (DealId, CustomerId, Amount, Stage, CloseDate)
• Products (ProductId, Name, SKU)
• DealProducts (DealId, ProductId, Quantity, UnitPrice)
• DealNotes (NoteId, DealId, NoteText, CreatedAt)

CustomerId, DealId, এবং ProductId স্থায়ী পরিচায়ক। DealProducts many-to-many সম্পর্ক সমাধান করে: একটি ডিল অনেক প্রোডাক্ট থাকতে পারে, এবং একটি প্রোডাক্ট অনেক ডিল-এ থাকতে পারে। DealNotes নোটগুলো আলাদা রাখে, যাতে “Note 1, Note 2, Note 3” কলাম না করতে হয়।

মডেল করার আগে “প্রোডাক্ট অনুযায়ী রাজস্ব” মত রিপোর্ট তৈরি করার জন্য স্ট্রিং ভাগ করা ও টাইপিংয়ের সামঞ্জস্য নিয়ে আশা করা লাগত। মডেলিং করার পরে এটা DealProducts এবং Products ও Deals জয়েন করে সহজ কুয়েরি হয়ে যায়।

পরবর্তী ধাপ: স্কিমা থেকে কাজ করা অ্যাপে যাওয়া

যখন আপনার স্কিমা কাগজে ঠিক মনে হয়, সেটাকে বাস্তব ডাটাবেসে নিয়ে যান এবং বাস্তব ডেটা দিয়ে টেস্ট করুন। সবকিছু একসাথে ইমপোর্ট করবেন না। প্রথমে ছোট ব্যাচ লোড করুন, যা ভাঙে তা ঠিক করুন, তারপর আবার বাড়ান।

ঝুঁকি কম রাখার বাস্তবধর্মী অর্ডার:

• টেবিল ও সম্পর্কগুলো তৈরি করুন।
• 50 থেকে 200 সারি ইমপোর্ট করুন, টোটাল যাচাই করুন, এবং র্যান্ডম রেকর্ড স্পট-চেক করুন।
• ম্যাপিং সমস্যা (ভুল কলাম, মিসিং ID, ডুপ্লিকেট) ঠিক করে পুনরায় ইমপোর্ট করুন।
• যখন স্থিতিশীল হয়, বাকি ডেটা লোড করুন।

শুরুতেই validation নিয়ম যোগ করুন যাতে খারাপ শিটের অভ্যাস ফিরে না আসে। required ফিল্ডগুলো বাধ্যতামূলক করুন, অনুমোদিত মান সীমাবদ্ধ করুন (যেমন status), ফরম্যাট ভ্যালিডেট করুন (ডেট ও ইমেইল), এবং foreign keys ব্যবহার করুন যাতে আপনি এমন অর্ডার তৈরি করতে না পারেন যার কোনো বিদ্যমান কাস্টমার নেই।

তারপর শিট-কে আপডেটের জন্য ব্যবহার বন্ধ করুন। যখন মানুষদের কাছে সহজ ফর্ম ও পরিষ্কার ওয়ার্কফ্লো থাকে তখন ডেটা সুরক্ষা অনেক সহজ হয়।

যদি আপনি স্কিমা কোড লিখে নয়, বরং একটি কার্যকর অভ্যন্তরীণ টুলে পরিণত করতে চান, AppMaster (appmaster.io) সহায়তা করতে পারে: আপনি টেবিল ও সম্পর্ক ভিজুয়ালি মডেল করেন, তারপর একই মডেল থেকে প্রোডাকশন-রেডি ব্যাকএন্ড, ওয়েব অ্যাপ, এবং নেটিভ মোবাইল অ্যাপ জেনারেট করেন।