تفاوت CDM، LDM و PDM در طراحی پایگاه‌داده (با مثال و نمودار)

وقتی در درس پایگاه‌داده یا یک پروژه‌ی نرم‌افزاری می‌خواهی دیتابیس طراحی کنی، همه‌چیز را یک‌جا و مستقیم با CREATE TABLE شروع نمی‌کنند. طراحی در سه سطح انجام می‌شود: مدل مفهومی (CDM)، مدل منطقی (LDM) و مدل فیزیکی (PDM). این مقاله تفاوت این سه را با یک مثال واحد و نمودار توضیح می‌دهد.

چرا طراحی در سه سطح انجام می‌شود؟

هر سطح یک سؤال متفاوت را جواب می‌دهد و مخاطب متفاوتی دارد. CDM را می‌توان با مدیر پروژه یا مشتری مرور کرد چون هیچ اصطلاح فنی ندارد؛ LDM را تحلیل‌گر و طراح بررسی می‌کنند؛ و PDM همان چیزی است که مدیر پایگاه‌داده (DBA) روی سرور می‌سازد. با جدا کردن این سطح‌ها، اگر روزی DBMS عوض شود (مثلاً از MySQL به SQL Server)، فقط PDM دوباره تولید می‌شود و تحلیل اصلی دست نمی‌خورد.

مقایسه‌ی سریع CDM، LDM و PDM

مثال واحد: سیستم ثبت‌نام دانشگاه

فرض کن می‌خواهیم دانشجوها، درس‌ها و ثبت‌نام آن‌ها را مدل کنیم. هر دانشجو می‌تواند چند درس بردارد و هر درس چند دانشجو دارد؛ یعنی بین دانشجو و درس رابطه‌ی چندبه‌چند است. همین مثال را در هر سه سطح می‌بینیم.

۱) مدل مفهومی (CDM)

در CDM فقط موجودیت‌ها، صفت‌ها و ارتباط‌ها را مشخص می‌کنیم. هنوز از کلید خارجی یا نوع داده خبری نیست. ارتباط «ثبت‌نام» مستقیماً بین دو موجودیت کشیده می‌شود و کاردینالیتی (حداقل و حداکثر مشارکت) روی دو سر آن نوشته می‌شود:

۲) مدل منطقی (LDM)

در LDM مدل را به قالب رابطه‌ای (جدول) می‌بریم. چون در مدل رابطه‌ای نمی‌توان رابطه‌ی چندبه‌چند را مستقیم نگه داشت، یک جدول واسط (Enrollment) اضافه می‌شود که دو کلید خارجی دارد. کلیدهای اصلی و خارجی در همین مرحله مشخص می‌شوند:

۳) مدل فیزیکی (PDM)

در PDM تصمیم می‌گیریم هر ستون در SQL Server (یا هر DBMS هدف) چه نوعی داشته باشد، چه قیدهایی لازم است و کدام ستون‌ها ایندکس بگیرند:

و اسکریپتی که از PDM تولید می‌شود:

CREATE TABLE Student (
  StudentNo INT IDENTITY(1,1) PRIMARY KEY,
  FullName  NVARCHAR(100) NOT NULL,
  BirthDate DATE NULL
);

CREATE TABLE Course (
  CourseCode CHAR(6) PRIMARY KEY,
  Title      NVARCHAR(100) NOT NULL,
  Credits    TINYINT NOT NULL CHECK (Credits BETWEEN 1 AND 6)
);

CREATE TABLE Enrollment (
  StudentNo  INT     NOT NULL REFERENCES Student(StudentNo),
  CourseCode CHAR(6) NOT NULL REFERENCES Course(CourseCode),
  Grade      DECIMAL(4,2) NULL,
  CONSTRAINT PK_Enrollment PRIMARY KEY (StudentNo, CourseCode)
);

-- ایندکس برای جستجوی سریع ثبت‌نام‌های یک درس
CREATE INDEX IX_Enrollment_Course ON Enrollment (CourseCode);

چطور از یک سطح به سطح بعد برویم؟

از CDM به LDM

• هر موجودیت تبدیل به یک جدول می‌شود و شناسه‌ی آن کلید اصلی می‌شود.
• رابطه‌ی یک‌به‌چند با افزودن کلید خارجی در سمت «چند» پیاده می‌شود.
• رابطه‌ی چندبه‌چند با یک جدول واسط و دو کلید خارجی پیاده می‌شود.
• صفت‌های چندمقداری (مثل چند شماره‌ی تلفن) به جدول جداگانه تبدیل می‌شوند.

جزئیات این قواعد در مقاله‌ی تبدیل نمودار ER به جدول آمده است.

از LDM به PDM

• برای هر ستون نوع داده و طول مناسب انتخاب می‌شود (مثل NVARCHAR(100) برای نام فارسی).
• قیدها (NOT NULL، UNIQUE، CHECK، DEFAULT) تعریف می‌شوند.
• ایندکس‌ها بر اساس الگوی جستجو ساخته می‌شوند.
• قاعده‌های نام‌گذاری DBMS و تنظیماتی مثل IDENTITY یا پارتیشن‌بندی اعمال می‌شود.

این سه مدل در ابزارها چه شکلی دارند؟

ابزارهایی مثل Power Designer برای هر سطح یک نوع مدل دارند و می‌توانند از CDM، PDM تولید کنند و از PDM اسکریپت SQL بسازند. ابزارهای سبک‌تر مثل draw.io یا dbdiagram.io بیشتر برای نمودار منطقی و فیزیکی مناسب‌اند. استفاده‌ی عملی از این ابزارها در یکی از مقاله‌های بعدی سایت توضیح داده خواهد شد.

اشتباه‌های رایج دانشجویان

• قرار دادن کلید خارجی در CDM؛ در مدل مفهومی ارتباط خودش کار کلید خارجی را می‌کند و نباید ستون FK کشیده شود.
• تعیین نوع داده در مدل مفهومی؛ نوع داده کار PDM است.
• رسم رابطه‌ی چندبه‌چند مستقیم در LDM بدون جدول واسط.
• نداشتن کلید اصلی برای جدول واسط یا انتخاب نادرست کلید ترکیبی.
• یکسان نبودن نام‌ها بین سه مدل؛ نام موجودیت و جدول باید قابل‌ردیابی باشد.

جمع‌بندی

CDM تحلیل است، LDM ساختار رابطه‌ای مستقل از ابزار است و PDM پیاده‌سازی برای یک DBMS مشخص. اگر این سه را با یک مثال واحد پیش ببری، هم برای امتحان و پروژه‌ی دانشگاه آماده‌ای و هم طراحی تمیزتری خواهی داشت. برای تمرین، درس مدل‌های ER و پروژه‌های سایت را ببین.