تحلیل و بازبینی نمودار ER: چک‌لیست و اشتباه‌های رایج با مثال
کشیدن نمودار فقط نیمی از کار است؛ نیمه‌ی دیگر خواندن و نقد آن است. استاد در تصحیح پروژه، همکار در بازبینی کد و خودت در ماه‌های بعد همین کار را می‌کنید. این درس یک روش منظم برای تحلیل نمودار می‌دهد.
روش اول: نمودار را به جمله تبدیل کن
هر ارتباط را از هر دو جهت با کاردینالیتی‌اش بخوان. اگر جمله بی‌معنی یا غلط بود، نمودار ایراد دارد:
| کاردینالیتی | جمله‌ی خوانده‌شده |
|---|---|
| Customer (0,n) — Order (1,1) | هر مشتری صفر یا چند سفارش دارد؛ هر سفارش دقیقاً به یک مشتری تعلق دارد. |
| Student (0,n) — Course (0,n) | هر دانشجو صفر یا چند درس را ثبت‌نام می‌کند؛ هر درس صفر یا چند دانشجو دارد. |
| Employee (0,1) — Manager (0,n) | هر کارمند حداکثر یک مدیر دارد (مدیرکل ندارد)؛ هر مدیر صفر یا چند کارمند را مدیریت می‌کند. |
چک‌لیست بازبینی
| بخش | سؤال بازبینی |
|---|---|
| ۱. موجودیت‌ها | هر موجودیت یک «چیز» واقعی است؟ نام مفرد و یکتاست؟ موجودیت اضافی یا جاافتاده نیست؟ |
| ۲. صفت‌ها | صفت محاسبه‌ای (مثل سن) یا چندمقداری (چند تلفن در یک ستون) نیست؟ |
| ۳. کلیدها | هر جدول کلید اصلی دارد؟ کلید مناسب (یکتا و پایدار) است؟ |
| ۴. ارتباط‌ها | هر ارتباط نام معنادار دارد؟ چندبه‌چندی بدون جدول واسط نیست؟ |
| ۵. کاردینالیتی | حداقل و حداکثر هر دو سر مشخص و مطابق قواعد کسب‌وکار است؟ |
| ۶. نرمال‌سازی | تکرار داده یا وابستگی انتقالی (3NF) ندارد؟ |
| ۷. نمادگذاری | نمادگذاری در کل نمودار یکدست است؟ نمودار خوانا و بدون تقاطع اضافی است؟ |
| ۸. قابل‌پیاده‌سازی | می‌توان از آن اسکریپت SQL ساخت که همه‌ی نیازها و قواعد را پوشش دهد؟ |
اشتباه ۱: رابطه‌ی چندبه‌چند بدون جدول واسط
در نمودار منطقی، رابطه‌ی M:N را مستقیم نمی‌توان پیاده کرد. «ثبت‌نام» هم صفت دارد (نمره) که به هیچ‌یک از دو جدول تعلق ندارد.
اشتباه ۲: جدول بدون کلید اصلی و صفت‌های ناسالم
اشتباه ۳: کاردینالیتی برعکس
نمودار می‌گوید «هر درس چند استاد دارد و هر استاد فقط یک درس». اما در واقعیت یک استاد چند درس می‌دهد و هر درس (در سیستم ما) یک استاد دارد. جمله را بخوان و با صورت مسئله مقایسه کن؛ اگر جهت برعکس باشد، کلید خارجی در جدول اشتباه قرار می‌گیرد (CourseId در Teacher به‌جای TeacherId در Course).
اشتباه ۴: تکرار داده و نقض نرمال‌سازی
وقتی در جدول Employee ستون‌های DeptName و DeptManager برای هر کارمند تکرار می‌شوند، تغییر نام یک بخش باید در صدها ردیف انجام شود. راه‌حل: جدول Department جداگانه و فقط DeptId در Employee (به نرمال‌سازی مراجعه کن).
اشتباه ۵: ترکیب سطح‌ها
- نوشتن نوع داده و
INT IDENTITYدر مدل مفهومی (CDM). - گذاشتن کلید خارجی به‌عنوان صفت در CDM؛ ارتباط خودش کار FK را می‌کند.
- نشان دادن ایندکس و قید فیزیکی در مدل منطقی.
- نام‌های متفاوت یک شیء در سه مدل (ردیابی ناممکن می‌شود).
معیار نمره‌دهی پیشنهادی برای تحلیل پروژه
| معیار | امتیاز |
|---|---|
| تحلیل نیازمندی و تطابق مدل با آن | ۲۰٪ |
| درستی موجودیت‌ها، صفت‌ها و کلیدها | ۲۰٪ |
| درستی ارتباط‌ها و کاردینالیتی | ۲۰٪ |
| نرمال‌سازی (حداقل 3NF) با توضیح | ۲۰٪ |
| خوانایی نمودار و یکدستی نمادگذاری | ۱۰٪ |
| اسکریپت اجراپذیر و نمونه‌پرس‌وجوها | ۱۰٪ |
تمرین: مدل کتابخانه را در طراح تعاملی باز کن و چک‌لیست بالا را روی آن اجرا کن. بعد به تمرین‌های حل‌شده برو.
تمرین‌های خودآزمایی
اول خودت جواب بده، بعد پاسخ را باز کن و مقایسه کن.
۱در نمودار یک فروشگاه، بین Customer و Product مستقیم رابطه‌ی چندبه‌چند «خرید» کشیده شده است و تعداد خرید روی خط نوشته‌اند. چه ایرادی دارد و چطور اصلاحش می‌کنی؟نمایش پاسخ
چندبه‌چند در مدل منطقی باید با جدول واسط شکسته شود و «تعداد» صفتِ رابطه است. بهتر است زنجیره‌ی Customer → Order → OrderItem ← Product مدل شود و Quantity و قیمت در زمان خرید در OrderItem نگه‌داری شود (چون یک مشتری ممکن است یک محصول را چند بار و در چند سفارش بخرد).
۲جدول Employee ستون‌های DeptName و DeptManager دارد که برای هر کارمند تکرار می‌شوند. کدام ناهنجاری و چه فرم نرمالی نقض شده است؟نمایش پاسخ
وابستگی انتقالی (EmployeeId → DeptId → DeptName, DeptManager) و در نتیجه 3NF نقض شده و ناهنجاری به‌روزرسانی داریم. راه‌حل: جدول Department جدا با کلید اصلی DeptId و کلید خارجی در Employee.
۳چرا ستون Age در کنار BirthDate ایراد دارد؟نمایش پاسخ
Age قابل‌محاسبه از تاریخ تولد است (داده‌ی مشتق‌شده) و هر روز تغییر می‌کند؛ ذخیره‌اش باعث ناسازگاری می‌شود. فقط BirthDate را نگه دار و سن را در پرس‌وجو محاسبه کن.