Relationships و طراحی ارتباط جداول

T-SQL | One-to-One، One-to-Many و Many-to-Many

Relationship تنها افزودن Foreign Key نیست؛ Cardinality، Optional بودن، مالکیت داده و رفتار حذف بخشی از طراحی‌اند. مدل صحیح Queryهای آینده و یکپارچگی داده را ساده‌تر می‌کند.

متن این فصل با رویکرد مرجع فنی و قابل استفاده در پروژه واقعی تنظیم شده است؛ مثال‌ها در امتداد مدل StoreDb نوشته شده‌اند و اصطلاحات اصلی SQL Server و T-SQL به‌صورت یکدست به‌کار می‌روند.

1. مفاهیم و قراردادهای اصلی

Relationship تنها افزودن Foreign Key نیست؛ Cardinality، Optional بودن، مالکیت داده و رفتار حذف بخشی از طراحی‌اند. مدل صحیح Queryهای آینده و یکپارچگی داده را ساده‌تر می‌کند.

در طراحی پایگاه داده، Syntax تنها بخشی از مسئله است. نوع داده، Constraint، الگوی دسترسی، Transaction و هزینه اجرای Query باید هم‌زمان با نیاز Domain در نظر گرفته شوند.

2. ساختار و Syntax پایه

Customers به Orders رابطه One-to-Many دارد و Products به Tags از Junction Table استفاده می‌کند. در One-to-One، Unique روی Foreign Key سمت وابسته رابطه را محدود می‌کند.

CREATE TABLE dbo.ProductTags
(
    ProductId int NOT NULL,
    TagId int NOT NULL,
    CONSTRAINT PK_ProductTags PRIMARY KEY (ProductId, TagId),
    CONSTRAINT FK_ProductTags_Products FOREIGN KEY (ProductId) REFERENCES dbo.Products(Id),
    CONSTRAINT FK_ProductTags_Tags FOREIGN KEY (TagId) REFERENCES dbo.Tags(Id)
);

3. سناریوی StoreDb

یک Product می‌تواند چند Tag داشته باشد و هر Tag روی چند Product قرار گیرد. Key ترکیبی از ثبت Duplicate همان رابطه جلوگیری می‌کند.

نمونه‌های این فصل بر مدل فروشگاهی StoreDb بنا شده‌اند تا ارتباط مفاهیم میان فصل‌ها حفظ شود و Queryها در یک Context یکپارچه قابل بررسی باشند.

INSERT INTO dbo.ProductTags (ProductId, TagId)
VALUES
(1, 1),
(1, 2),
(2, 2);

4. اصول طراحی و Performance

طراحی پایدار باید هم صحت داده و هم هزینه اجرای عملیات را پوشش دهد. انتخاب ساده‌تر زمانی ترجیح دارد که Contract داده را روشن‌تر و رفتار Optimizer را قابل پیش‌بینی‌تر نگه دارد.

• Cardinality از Rule Domain استخراج شود.
• Junction Table در صورت داشتن Attribute به Entity مستقل تبدیل شود.
• Delete Behavior با Ownership واقعی هماهنگ باشد.
• Optional بودن با NULL در Foreign Key بیان شود.

5. خطاهای رایج و نکات ایمنی

دستورهای SQL می‌توانند مستقیماً داده و ساختار را تغییر دهند؛ بنابراین بازبینی Context، تعداد Rowهای هدف و اثر Transaction قبل از اجرای تغییرات اهمیت عملی دارد.

• قرار دادن TagId واحد در Products برای مدل چندبه‌چند.
• One-to-One بدون Unique.
• Cascade چندمرحله‌ای ناخواسته.
• تکرار داده Parent در Child به‌جای Foreign Key.

6. چک‌لیست نهایی فصل

• نوع هر Relationship مشخص است.
• Junction Table کلید مناسب دارد.
• Optional/Required بودن روشن است.
• رفتار حذف مستند و تست شده است.

7. جمع‌بندی

خروجی این فصل باید به تصمیمی قابل اتکا در طراحی یا Query منجر شود؛ صحت داده، قابلیت نگهداری و رفتار Performance سه معیار ثابت برای ارزیابی نمونه‌ها هستند.