در یک فایل ساده، نام زبان‌آموز کنار نام کلاس و شماره تماس نوشته شده است. با ثبت‌نام همان فرد در کلاس دوم، اطلاعات تماس دوباره تکرار می‌شود. حالا اگر شماره عوض شود، باید چند ردیف اصلاح شود و ممکن است یکی جا بماند. طراحی رابطه جدول‌های پایگاه داده از همین مسئله ملموس شروع می‌شود.
برای تمرین، یک آموزشگاه فرضی را در نظر می‌گیریم که زبان‌آموز در آن می‌تواند در چند کلاس شرکت کند و هر کلاس نیز چند زبان‌آموز دارد. هدف این مثال، طراحی هسته ثبت‌نام است؛ پرداخت، حضور و غیاب و برنامه جلسات فعلاً خارج از محدوده‌اند تا رابطه‌ها واضح بمانند.
قواعد کسب‌وکار را پیش از رسم جدول بنویسید
سه جمله برای شروع کافی است: هر زبان‌آموز یک شناسه مستقل دارد؛ هر کلاس یک اجرای مشخص از یک دوره است؛ هر ثبت‌نام، یک زبان‌آموز را به یک کلاس وصل می‌کند. همین جمله‌ها مانع می‌شوند «دوره مکالمه» را با «کلاس مکالمه پاییز، گروه عصر» یکسان بگیریم.
قانون دیگری هم لازم است: آیا یک زبان‌آموز می‌تواند در یک کلاس بیش از یک ثبت‌نام داشته باشد؟ در این مثال پاسخ منفی است. اگر لغو و ثبت‌نام مجدد در سامانه واقعی مطرح باشد، باید تصمیم بگیرید سابقه چگونه نگهداری شود. طراحی داده بدون پاسخ به این پرسش، ممکن است در اولین حالت استثنا دچار مشکل شود.
موجودیت را از اطلاعات مربوط به آن جدا کنید
زبان‌آموز، کلاس و ثبت‌نام سه مفهوم مستقل‌اند. نام و تلفن متعلق به زبان‌آموز است؛ ظرفیت متعلق به کلاس؛ تاریخ ثبت‌نام متعلق به رابطه میان این دو. اگر تاریخ ثبت‌نام را در جدول زبان‌آموز بگذاریم، برای فردی با چند کلاس فقط یک تاریخ خواهیم داشت.
| جدول | نمونه ستون‌ها | نقش |
|---|---|---|
| Students | StudentId، Name، Phone | مشخصات فرد |
| Courses | CourseId، Title | تعریف دوره |
| Classes | ClassId، CourseId، Capacity | اجرای یک دوره |
| Enrollments | EnrollmentId، StudentId، ClassId، EnrolledAt | اتصال فرد به کلاس |
شناسه‌های این جدول‌ها برای ارتباط استفاده می‌شوند. نام فرد کلید مناسبی برای اتصال نیست، چون ممکن است تکراری باشد یا اصلاح شود. شماره تلفن نیز لزوماً برای هر فرد یکتا و همیشگی نیست؛ مثلاً دو عضو خانواده ممکن است یک شماره تماس اعلام کنند.
رابطه چندبه‌چند را با جدول واسط نشان دهید
یک دوره می‌تواند چند کلاس داشته باشد، پس رابطه Courses با Classes در این مدل یک‌به‌چند است. اما زبان‌آموز و کلاس رابطه چندبه‌چند دارند. جدول Enrollments هر ثبت‌نام را به صورت یک ردیف نگه می‌دارد و دو رابطه یک‌به‌چند ایجاد می‌کند.
فرض کنید زبان‌آموز ۱۰ در کلاس‌های ۲۱ و ۲۲ ثبت‌نام کرده است. دو ردیف ثبت‌نام خواهیم داشت که StudentId آن‌ها یکسان و ClassId متفاوت است. برای شمارش زبان‌آموزان کلاس ۲۱، ردیف‌های مربوط به همان کلاس را بررسی می‌کنیم؛ لازم نیست ستون‌هایی مانند Class1 و Class2 و Class3 به جدول افراد اضافه کنیم.
برای جلوگیری از ثبت‌نام تکراری در این مدل ساده، ترکیب StudentId و ClassId باید یکتا باشد. کلید خارجی نیز باید مانع اتصال ثبت‌نام به فرد یا کلاسی شود که وجود ندارد. این قواعد فقط در فرم ورود داده مطرح نیستند؛ طراحی پایگاه داده باید از یکپارچگی رابطه‌ها پشتیبانی کند.
نرمال‌سازی را با یک تغییر اطلاعات توضیح دهید
اگر عنوان دوره در هر ثبت‌نام کپی شود، اصلاح نام دوره به تغییر تعداد زیادی ردیف نیاز دارد. نگهداری عنوان در جدول Courses این تکرار را کم می‌کند. راهنمای نرمال‌سازی مایکروسافت نیز بر سامان دادن جدول‌ها و رابطه‌ها برای کاهش تکرار و وابستگی نامناسب تأکید دارد.
البته هر مقدار تکراری الزاماً اشتباه نیست. برای مثال، مبلغ توافق‌شده هنگام ثبت‌نام ممکن است یک واقعیت تاریخی مستقل باشد و با قیمت جاری دوره تفاوت داشته باشد. پیش از حذف تکرار، بپرسید این ستون «اطلاعات جاری» را نشان می‌دهد یا «وضعیت زمان وقوع رویداد» را. پاسخ به این پرسش از اجرای مکانیکی قواعد مفیدتر است.
مدل را با سه سناریوی کوچک امتحان کنید
سناریوی اول، ثبت دو زبان‌آموز هم‌نام است. آیا شناسه مستقل، آن‌ها را از هم جدا می‌کند؟ سناریوی دوم، تغییر شماره تماس فردی است که در دو کلاس حضور دارد. آیا یک محل مشخص برای اصلاح دارید؟ سناریوی سوم، حذف کلاسی است که ثبت‌نام دارد. آیا سیاست حذف و نگهداری سابقه معلوم است؟
لازم نیست پاسخ سناریوی سوم همیشه حذف آبشاری باشد. در بسیاری از سامانه‌ها، بستن یا غیرفعال کردن کلاس با حذف فیزیکی فرق دارد. این انتخاب باید از نیاز نگهداری سابقه بیاید. برای آزمون نام‌ها و داده‌های فارسی نیز مطلب داده تست فارسی برای برنامه‌نویسی به طراحی نمونه‌های واقعی‌تر کمک می‌کند.
همین مثال را به ارائه درسی تبدیل کنید
در ارائه، ابتدا جدول شلوغ اولیه را نشان دهید، سپس سه مسئله تکرار شماره، چند کلاس و سابقه ثبت‌نام را مطرح کنید. بعد مدل اصلاح‌شده را معرفی کنید. این ترتیب باعث می‌شود مخاطب دلیل ایجاد هر جدول را بفهمد و فقط چند تعریف حفظ نکند.
پاورپوینت اصول طراحی پایگاه داده برای مرور سرفصل‌ها و آماده‌سازی چارچوب ارائه قابل بررسی است. مثال آموزشگاه را خودتان به آن اضافه و قواعدش را توضیح دهید. اگر زمان ارائه کوتاه است، از روش ساخت ارائه علمی متمرکز استفاده کنید و پرداخت یا حضور و غیاب را به توسعه بعدی تمرین بسپارید.
