H

یادداشت‌های مدل EER و نگاشت ER-to-Relational + مفاهیم پایه رابطه‌ای

مفاهیم پایه EER و دلایل استفاده از آن

  • EER مخفف Extended ER یا Enhanced ER است. این مدل، مفاهیم مدل ER پایه (مانند موجودیت‌ها، ویژگی‌ها و روابط) را شامل می‌شود و با افزودن مفاهیم تکمیلی برای مدل‌سازی دقیق‌تر و جامع‌تر سیستم‌های پیچیده داده‌ها، قابلیت‌های آن را گسترش می‌دهد.

  • مفاهیم تکمیلی EER: این مفاهیم شامل زیر کلاس/ابر کلاس (Subclass/Superclass)، تخصص‌سازی / تعمیم (Specialization/Generalization)، دسته‌بندی یا Union-type و وراثت صفات و روابط (Attribute & Relationship Inheritance) هستند. این قابلیت‌ها به مدل‌ساز اجازه می‌دهند تا پیچیدگی‌های دنیای واقعی را با دقت بیشتری نمایش دهد، به‌ویژه در سیستم‌هایی که موجودیت‌ها می‌توانند دارای ویژگی‌های مشترک و در عین حال تفاوت‌های خاص باشند.

  • هدف: هدف اصلی EER مدل‌سازی مفهومی دقیق‌تر برای برنامه‌های واقعی و پشتیبانی از مفاهیم شی‌گرا مانند وراثت است. این امر به طراحی پایگاه داده‌ای منجر می‌شود که هم انعطاف‌پذیرتر و هم از لحاظ مفهومی به ساختارهای واقعی نزدیک‌تر است.

  • EER از برخی جنبه‌های شی‌گرایی، مانند مفهوم وراثت و سلسله‌مراتب کلاس‌ها، استفاده می‌کند تا مدل‌سازی مفهومی را دقیق‌تر کرده و قابلیت reuse را در مدل افزایش دهد.

زیر کلاس/ابر کلاس (Subclass / Superclass) و وراثت

  • زیرکلاس: یک زیرکلاس مجموعه خاصی از اعضای یک کلاس بزرگتر (ابرکلاس) است که ویژگی‌ها و/یا روابط خاص خود را نیز دارد. به‌عنوان مثال، «دانشجوی کارشناسی» یک زیرکلاس از موجودیت کلی‌تر «دانشجویان» است. زیرکلاس‌ها ویژگی‌ها، روابط و معنای اضافی‌ای دارند که برای تمام اعضای ابرکلاس صادق نیست.

  • ابرکلاس: ابرکلاس کلاس عمومی‌تری است که زیرکلاس‌ها را در بر می‌گیرد. هر موجودیت در زیرکلاس به‌طور خودکار عضوی از ابرکلاس نیز محسوب می‌شود.

  • وراثت: وراثت در EER به دو صورت اصلی دسته‌بندی می‌شود:

    • تخصص‌سازی / Specialization (رویکرد بالا به پایین): این فرایند شامل شناسایی زیرکلاس‌های متمایز از یک ابرکلاس موجود است. به عبارت دیگر، شما از یک موجودیت کلی شروع کرده و آن را به موجودیت‌های خاص‌تر تقسیم می‌کنید. به‌عنوان مثال، موجودیت EMPLOYEE می‌تواند به زیرکلاس‌های SECRETARY، TECHNICIAN یا ENGINEER تخصیص یابد.

    • تعمیم / Generalization (رویکرد پایین به بالا): این فرایند شامل ترکیب (تجمیع) چندین کلاس موجود با ویژگی‌های مشترک در یک ابرکلاس واحد است. به‌عنوان مثال، اگر موجودیت‌های CAR و TRUCK را داشته باشیم، می‌توانیم یک ابرکلاس به نام VEHICLE برای آن‌ها تعریف کنیم که ویژگی‌های مشترک آن‌ها را در خود جای دهد.

  • دسته‌بندی / Union-Type (Category): این مفهوم زمانی به کار می‌رود که یک زیرکلاس با موجودیت‌هایی از چند کلاس والد (superclass) مختلف سروکار دارد. برای مثال، یک «عضو» (MEMBER) می‌تواند هم یک «دانشجو» (STUDENT) باشد و هم یک «استاد» (INSTRUCTOR). در این حالت، MEMBER خود یک ابرکلاس از STUDENT و INSTRUCTOR نیست، بلکه یک مجموعه از نمونه‌های آن دو است. این نوع رابطه با نماد U در زیر مثلث تخصص‌سازی در دیاگرام EER نشان داده می‌شود.

  • ارث بری صفات و روابط: زیر کلاس‌ها می‌توانند تمام صفات (attributes) و روابط (relationships) تعریف شده برای ابرکلاس خود را به ارث ببرند. این بدان معناست که دیگر نیازی به تکرار تعریف این ویژگی‌ها و روابط در هر زیرکلاس نیست، که باعث افزایش انسجام و کاهش افزونگی در مدل می‌شود. (این مفهوم شباهت زیادی به وراثت در برنامه‌نویسی شیءگرایی دارد).

  • IS-A رابطه: این رابطه نشان می‌دهد که یک زیرکلاس از یک ابرکلاس خاص است (مثلاً SECRETARY IS-A EMPLOYEE). این مفهوم اساسیترین پایه برای مدل‌سازی سلسله‌مراتب وراثت در EER است و با یک خط به مثلث تخصص‌سازی متصل می‌شود.

نکات کلیدی درباره IS-A

  • هویت موجودیت: زیر کلاس واقعاً همان موجودیت جهان واقعی با نقشی (یا حالت) متفاوت در ابرکلاس است. به عنوان مثال، یک فرد خاص می‌تواند در نقش یک EMPLOYEE و هم‌زمان در نقش یک STUDENT ظاهر شود، و در هر دو مورد همان شیء واقعی (فرد) است.

  • وابستگی به ابرکلاس: یک موجودیت نمی‌تواند تنها عضو زیر کلاس باشد؛ باید حتماً عضو ابرکلاس باشد (در حالت معمول). این بدان معناست که برای اینکه یک موجودیت SECRETARY باشد، ابتدا باید یک EMPLOYEE باشد.

  • عضویت چندگانه در زیرکلاس‌ها: یک موجودیت ابرکلاس می‌تواند عضو چند زیر کلاس باشد (این مفهوم اجازه مدل‌سازی وراثت چندگانه را در ساختارهایی مانند سره‌شکل (lattice) می‌دهد). برای مثال، یک EMPLOYEE می‌تواند هم یک ENGINEER و هم یک MANAGER باشد.

  • مثال‌ها: SECRETARY IS-A EMPLOYEE، TECHNICIAN IS-A EMPLOYEE. این مثال‌ها نشان می‌دهند که هر منشی یا تکنسین در واقع یک کارمند نیز هست و ویژگی‌های کلی کارمندی را به ارث می‌برد.

وراثت و تعبیه ویژگی‌ها/روابط

  • وراثت Attribute Inheritance: تمام ویژگی‌های تعریف شده برای ابرکلاس به‌طور خودکار به تمام زیر کلاس‌های آن ارث می‌رسند. برای مثال، اگر EMPLOYEE دارای ویژگی‌هایی مانند SSN (شماره ملی)، Name (نام)، و Salary (حقوق) باشد، زیرکلاس‌های SECRETARY، TECHNICIAN و ENGINEER نیز این ویژگی‌ها را خواهند داشت.

  • وراثت Relationship Inheritance: تمام روابطی که ابرکلاس در آن شرکت می‌کند، به زیر کلاس‌ها نیز انتقال می‌یابد. اگر EMPLOYEE با DEPARTMENT در رابطه "Works_For" باشد، زیرکلاس‌های آن (مثل SECRETARY) نیز به‌طور ضمنی در همین رابطه شرکت خواهند کرد.

  • نکته مهم: زیر کلاس‌ها می‌توانند ویژگی‌ها و روابط اضافی مخصوص به خود داشته باشند که تنها برای آن زیرکلاس خاص (و نه برای ابرکلاس یا سایر زیرکلاس‌ها) تعریف می‌شوند. به‌عنوان مثال، SECRETARY می‌تواند ویژگی TypingSpeed و TECHNICIAN می‌تواند ویژگی ToolUsed را داشته باشد.

SPECIALIZATION و GENERALIZATION: دو رویکرد مدل‌سازی

  • Specialization (تخصیص): این یک فرایند بالا به پایین است که طی آن یک موجودیت کلی (ابرکلاس) به یک یا چند موجودیت خاص‌تر (زیرکلاس) بر اساس تفاوت‌های بارز در ویژگی‌ها یا نقش‌هایشان تقسیم می‌شود. این فرایند معمولاً پس از شناسایی یک موجودیت اصلی آغاز می‌شود و به سمت شناسایی موجودیت‌های پیچیده‌تر با نقش‌های متمایز پیش می‌رود.

  • Generalization (تعمیم): این یک فرایند پایین به بالا است که طی آن چندین کلاس موجودیت با ویژگی‌های مشترک یا فعالیت‌های مشابه در یک ابرکلاس واحد ترکیب می‌شوند. هدف آن شناسایی نقاط مشترک بین موجودیت‌های خاص‌تر و ایجاد یک موجودیت عمومی‌تر برای کاهش تکرار و بهبود سازماندهی مدل است.

  • در طراحی واقعی پایگاه داده، معمولاً از هر دو فرایند Specialization و Generalization به‌صورت ترکیبی و تعاملی استفاده می‌شود تا به یک مدل مفهومی کامل و بهینه دست یابیم.

  • مدل‌سازی مثال:

    • EMPLOYEE یک ابرکلاس است که می‌تواند زیرکلاس‌های SECRETARY، TECHNICIAN، ENGINEER و MANAGER را داشته باشد. این یک نمونه از Specialization است.

    • می‌توان زیر کلاس‌های HOURLYEMPLOYEE و SALARIEDEMPLOYEE را به‌عنوان زیرکلاس‌های تخصصیِ MANAGER یا حتی EMPLOYEE در نظر گرفت تا روش‌های پرداخت را متمایز کنیم. این نشان‌دهنده لایه‌های مختلف تخصص‌سازی است.

نمایش تخصص‌سازی (Specialization) در EER

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

  • در دیاگرام EER، زیر کلاس‌ها با خطوط IS-A که از زیرکلاس به مثلث تخصص‌سازی و سپس به ابرکلاس متصل می‌شوند، نشان داده می‌شوند. مثلث تخصص‌سازی نقطه‌ای است که در آن شعب تخصص‌سازی آغاز می‌شوند.

  • مثال تصویری از EMPLOYEE: می‌توان EMPLOYEE را با سه تخصص اصلی به SECRETARY، TECHNICIAN، ENGINEER و همچنین زیرکلاس‌های اضافی مانند MANAGER و HOURLYEMPLOYEE / SALARIEDEMPLOYEE نشان داد. این نمودار سلسله‌مراتب کامل‌تر و پیچیده‌تری از روابط IS-A را نشان می‌دهد.

اجزای نمایش تخصص‌سازی در دیاگرام EER

  • ابرکلاس (Superclass): موجودیت عمومی و پایه که ویژگی‌ها و روابط مشترک را دارا است.

  • زیر کلاس‌ها (Subclasses): موجودیت‌های تخصصی‌تر که از ابرکلاس منشعب شده و ویژگی‌ها و روابط اضافی نیز می‌توانند داشته باشند.

  • رابطه IS-A: یک خط که زیرکلاس را به ابرکلاس مرتبط می‌کند و بیان‌گر مفهوم "… است یک …" می‌باشد.

  • مثلث تخصص‌سازی (Participation Triangle): این مثلث نمادی است که به خطوط IS-A متصل شده و نقطه تجمیع یا انشعاب تخصص‌سازی را نشان می‌دهد. درون یا کنار این مثلث، محدودیت‌های گسستگی (Disjointness) و کامل بودن (Completeness) نیز مشخص می‌شوند.

انواع قیدها در تخصص‌سازی/تعمیم

قیدها (Constraints) محدودیت‌هایی هستند که بر نحوه عضویت موجودیت‌ها در زیرکلاس‌ها اعمال می‌شوند و برای تعریف دقیق‌تر مدل EER حیاتی‌اند:

  • Disjointness Constraint (محدودیت گسستگی): این قید تعیین می‌کند که آیا یک موجودیت از ابرکلاس می‌تواند به بیش از یک زیرکلاس تعلق داشته باشد یا خیر.

    • Disjoint (ناپیوسته - D): یک موجودیت از ابرکلاس تنها می‌تواند به یکی از زیر کلاس‌ها تعلق داشته باشد. این بدان معناست که زیرکلاس‌ها از یکدیگر متمایز هستند و هیچ همپوشانی ندارند (مثلاً یک فرد نمی‌تواند همزمان Male و Female باشد). در نمودار با حرف D درون مثلث نشان داده می‌شود.

    • Overlapping (پیوسته - O): یک موجودیت از ابرکلاس می‌تواند به چندین زیر کلاس مختلف تعلق داشته باشد. این بدان معناست که زیرکلاس‌ها می‌توانند همپوشانی داشته باشند (مثلاً یک فرد می‌تواند همزمان STUDENT و EMPLOYEE باشد). در نمودار با حرف O درون مثلث نشان داده می‌شود.

  • Completeness Constraint (محدودیت کامل بودن): این قید تعیین می‌کند که آیا هر موجودیت در ابرکلاس باید به یکی از زیرکلاس‌ها تعلق داشته باشد یا خیر.

    • Total Specialization (کامل): هر موجودیت در ابرکلاس (والد) باید حتماً در حداقل یکی از زیر کلاس‌ها باشد. این به معنای "شامل تمام موارد" است. با یک خط دوتایی از ابرکلاس به مثلث نشان داده می‌شود.

    • Partial Specialization (ناقص): ممکن است برخی موجودیت‌های ابرکلاس (والد) در هیچ کدام از زیر کلاس‌ها نباشند. این به معنای "اختیاری" بودن عضویت است. با یک خط تکی از ابرکلاس به مثلث نشان داده می‌شود.

  • چهار ترکیب اصلی: با ترکیب این دو نوع قید، می‌توانیم چهار حالت اصلی برای تخصص‌سازی یا تعمیم داشته باشیم:

    1. Disjoint, Total: هر موجودیت باید دقیقاً به یکی از زیرکلاس‌ها تعلق داشته باشد.

    2. Disjoint, Partial: یک موجودیت می‌تواند به هیچ زیرکلاسی، یا دقیقاً به یکی از زیرکلاس‌ها تعلق داشته باشد.

    3. Overlapping, Total: هر موجودیت باید به حداقل یکی از زیرکلاس‌ها تعلق داشته باشد، و می‌تواند به بیش از یکی هم تعلق داشته باشد.

    4. Overlapping, Partial: یک موجودیت می‌تواند به هیچ زیرکلاسی، یا به یک یا چند زیرکلاس تعلق داشته باشد.

نمایش انواع SPECIALIZATION/GENERALIZATION

  • برای نمایش تخصص‌سازی در یک دیاگرام EER، ما از ابرکلاس EMPLOYEE و زیرکلاس‌های آن مانند SECRETARY, TECHNICIAN, ENGINEER استفاده می‌کنیم. روابط IS-A که از هر زیرکلاس به مثلث تخصص‌سازی متصل می‌شوند، ساختار سلسله‌مراتبی را نشان می‌دهند. محدودیت‌های گسستگی و کامل بودن (مانند D برای Disjoint و P یا T برای Partial/Total) درون یا کنار مثلث برای تعریف دقیق‌تر معنایی مدل قرار می‌گیرند.

  • EER همچنین می‌تواند موارد پیچیده‌تری مانند Union Type (Category) و Shared Subclass را نمایش دهد، که در آن‌ها یک زیرکلاس ممکن است از چندین ابرکلاس مختلف به ارث ببرد یا یک موجودیت میان چندین ابرکلاس به اشتراک گذاشته شود.

تقسیم‌بندی: Hierarchy در تخصص و lattice در وراثت

  • Hierarchy (وراثت تک‌گانه یا سلسله‌مرتبه): در یک سلسله‌مرتبه تخصص‌سازی، هر زیرکلاس تنها یک سوپرکلاس (Parent) مستقیم دارد. این ساختار شبیه یک درخت است که در آن هر گره به جز ریشه، فقط یک والد دارد. مثال: Person -> Employee -> Manager.

  • Lattice (وراثت چندگانه یا شبکه): در یک Lattice، یک زیرکلاس می‌تواند چندین سوپرکلاس داشته باشد. این اجازه می‌دهد تا یک موجودیت ویژگی‌ها و رفتارهای خود را از چندین نسل پدر و مادر به ارث ببرد، که منجر به ساختاری پیچیده‌تر و شبکه‌ای می‌شود. مثال: Graduate Assistant ممکن است هم Student و هم Employee باشد.

  • واقعیت عملی: اکثر مدل‌های پایگاه داده و سیستم‌های شی‌گرا از ترکیبی از هر دو Hierarchy و Lattice برای انعطاف‌پذیری بیشتر و مدل‌سازی دقیق‌تر سناریوهای جهان واقعی استفاده می‌کنند.

Shared Subclass و Union Types

  • Shared Subclass: این وضعیت زمانی رخ می‌دهد که یک زیرکلاس مشخصی بین چند سوپرکلاس متفاوت مشترک باشد و از همه آن‌ها ویژگی‌ها و روابط خاصی را ارث می‌برد. این مفهوم به ساختار Lattice اشاره دارد.

  • Union Type یا Category (همچنین به عنوان Intersection Subclass شناخته می‌شود): یک زیرکلاس است که از ترکیب موجودیت‌های مختلف از سوپرکلاس‌های مختلف تشکیل می‌شود، اما این سوپرکلاس‌ها لزوماً خویشاوند (parent-child) نیستند. به عنوان مثال، یک موجودیت "RegisteredVehicleOwner" می‌تواند یا یک "Person" باشد یا یک "Company". در این حالت، "RegisteredVehicleOwner" یک Category است که شامل نمونه‌هایی از "Person" و "Company" می‌شود و نه یک زیرکلاس مستقیم از هر دوی آن‌ها به طور همزمان. این مفهوم با یک مثلث و حرف 'U' در دیاگرام EER نشان داده می‌شود و یک خط به هر یک از سوپرکلاس‌های مربوطه متصل می‌شود.

مثال‌های کامل‌تر از مدل EER

  • EMPLOYEE به عنوان ابرکلاس:

    • SUBCLASSES: SECRETARY، TECHNICIAN، ENGINEER. این زیرکلاس‌ها می‌توانند ویژگی‌های خاص خود را داشته باشند (مانند TypingSpeed برای SECRETARY یا SkillSet برای TECHNICIAN).

    • دسته‌های دیگر: MANAGER (ممکن است به عنوان specialization دیگری از EMPLOYEE باشد که با زیرکلاس‌های دیگر همپوشانی داشته باشد، یا یک موجودیت با ارتباطات خاص مستقل از تخصص‌سازی اولیه).

    • HOURLYEMPLOYEE و SALARIEDEMPLOYEE به‌عنوان زیرکلاس‌های حقوقیِ هزینه‌دهی که نشان‌دهنده دسته‌بندی بر اساس نوع پرداخت هستند، که می‌توانند از EMPLOYEE یا MANAGER منشعب شوند.

  • رابطه‌های مرتبط:

    • MANAGES: یک ارتباط دودویی بین EMPLOYEE (در نقش Manager) و PROJECT یا DEPARTMENT. این ارتباط نشان می‌دهد که یک کارمند (مدیر) مسئولیت مدیریت یک پروژه یا دپارتمان را بر عهده دارد.

    • BELONGS_TO: ارتباط بین EMPLOYEE و DEPARTMENT که هر کارمند به یک دپارتمان خاص تعلق دارد.

    • WORKSON: یک رابطه M:N بین EMPLOYEE (در نقش Worker) و PROJECT (در نقش AssignedProject) همراه با یک صفت توصیفی مانند Hours (مثلاً ( ext{EmpSSN}, ext{ProjNo}, ext{Hours})).

    • TRADEUNION: رابطه‌ای که نشان می‌دهد EMPLOYEE یا گروه‌های کاری به یک اتحادیه صنفی مشخص (TradeUnion) وابسته هستند.

نکته‌های مهم درباره نمایش IS-A

  • هویت موجودیت و نقش: IS-A نشان می‌دهد که زیرکلاس همان موجودیت ابرکلاس در نقش خاص یا با ویژگی‌های تخصصی‌تر است. هویت موجودیت در سراسر سلسله‌مراتب حفظ می‌شود.

  • عضویت در ابرکلاس اجباری: یک موجودیت نمی‌تواند به‌تنهایی صرفاً عضوِ زیرکلاس باشد؛ برای عضویت در زیرکلاس، باید حتماً عضو ابرکلاس هم باشد. این یک اصل بنیادی است.

  • وراثت چندگانه (Lattice): ابرکلاس ممکن است عضو چند زیر کلاس باشد. این مفهوم، امکان مدل‌سازی وراثت چندگانه (Lattice inheritance) را فراهم می‌آورد که در آن یک زیرکلاس می‌تواند از ویژگی‌ها و رفتارهای چندین ابرکلاس به طور همزمان ارث ببرد.

نمایش تفضیلیِ تعمیم و تخصص

  • Generalization (تعمیم): این فرایند، یکپارچه‌سازی و تجمیع از پایین به بالا است که از مجموعه‌ای از موجودیت‌ها (یا زیرکلاس‌ها) شروع شده و یک ابرکلاس عمومی‌تر ساخته می‌شود. ویژگی‌ها و روابط مشترک در این ابرکلاس جای می‌گیرند تا تکرار اطلاعات کاهش یابد و ساختار مدل ساده‌تر شود. مثلاً، موجودیت‌های مختلف خودرو (CAR, TRUCK, MOTORCYCLE) می‌توانند به موجودیت کلی VEHICLE تعمیم یابند.

  • Specialization (تخصص‌سازی): این فرایند، ایجاد و تقسیم‌بندی از بالا به پایین است که از یک ابرکلاس شروع شده و زیر کلاس‌های خاص‌تر و متمایزتری با ویژگی‌ها و روابط منحصربه‌فرد ایجاد می‌شود. مثلاً، موجودیت PERSON می‌تواند به زیرکلاس‌های EMPLOYEE و STUDENT تخصیص یابد.

  • هر دو مفهوم از دیدگاه برنامه‌نویسی شیءگرا (OOP) الهام گرفته شده‌اند و به‌طور گسترده در مدل‌سازی پایگاه داده (با ER/EER) و طراحی نرم‌افزار (با UML) برای ایجاد ساختارهای داده‌ای منعطف و قابل نگهداری استفاده می‌شوند.

نقشه کلی الگوریتم نگاشت ER-to-Relational

  • هدف: تبدیل دیاگرام‌های ER/EER به طرحواره‌های رابطه‌ای (جدول‌ها، ویژگی‌ها و کلیدها) که می‌توانند در یک سیستم مدیریت پایگاه داده رابطه‌ای (RDBMS) پیاده‌سازی شوند. این فرایند یک گام حیاتی در طراحی پایگاه داده است.

  • گام‌های اصلی:

    1. Mapping of Regular Entity Types: برای هر موجودیت قوی (که کلید اصلی خود را دارد) در دیاگرام ER، یک جدول جداگانه در مدل رابطه‌ای تعریف می‌شود. تمام ویژگی‌های ساده آن موجودیت به ستون‌های جدول نگاشت می‌شوند. یکی از کلیدهای اصلی (Key Attributes) موجودیت به‌عنوان کلید اصلی (Primary Key - PK) جدول انتخاب می‌شود.

      • اگر کلید از چند جزء تشکیل شود (کلید ترکیبی)، کلید اصلی جدول شامل تمام اجزای کلیدی می‌شود.

    2. Mapping of Weak Entity Types: موجودیت‌های ضعیف (که وجود آنها به موجودیت قوی مالکشان وابسته است) به صورت یک جدول جداگانه نگاشت می‌شوند. کلید اصلی موجودیت مالک (Owning Entity) به‌عنوان کلید خارجی (Foreign Key - FK) در جدول موجودیت ضعیف آورده می‌شود. این کلید خارجی به همراه کلید جزئی (Partial Key) خود موجودیت ضعیف (اگر وجود داشته باشد) به‌عنوان کلید اصلی ترکیبی (Composite Primary Key) آن جدول عمل می‌کند.

    3. Mapping of Binary 1:1 Relationship Types: برای هر رابطه دودویی یک به یک، دو روش اصلی وجود دارد:

      • Foreign Key Approach: کلید اصلی یکی از دو موجودیت شرکت‌کننده (به‌عنوان مثال، از موجودیت S1) به‌عنوان کلید خارجی در جدول موجودیت دیگر (S2) قرار داده می‌شود. اگر مشارکت (Participation) در رابطه کامل باشد (برای هر دو طرف)، می‌توان دو جدول را یکی کرد.

      • Merged Relation: در برخی موارد، به‌ویژه اگر مشارکت هر دو موجودیت در رابطه کامل باشد، می‌توان کلیدها و ویژگی‌های هر دو موجودیت را در یک جدول واحد ترکیب کرد و یک جدول جدید ایجاد نمود. این کار می‌تواند در صورت عدم نیاز به تفکیک معنایی قوی انجام شود.

    4. Mapping of Binary 1:N Relationship Types: در سمت 'N' (سمت چندگانه) رابطه، کلید اصلی موجودیت از سمت '1' (سمت یگانه) به‌عنوان کلید خارجی به جدول موجودیت سمت 'N' اضافه می‌شود. این کلید خارجی به کلید اصلی جدول سمت '1' ارجاع می‌دهد.

      • مثال: DEPARTMENT(DNUMBER{ ext{PK}}) و EMPLOYEE(Ssn{ ext{PK}}, Dno_{ ext{FK REFERENCES DEPARTMENT(DNUMBER)}}). در اینجا Dno در جدول EMPLOYEE یک کلید خارجی است که به DNUMBER در جدول DEPARTMENT ارجاع می‌دهد.

    5. Mapping of Binary M:N Relationship Types: برای هر رابطه دودویی چند به چند، یک جدول میانی (Relationship Relation) جدید ایجاد می‌شود. این جدول شامل کلیدهای اصلی هر دو موجودیت شرکت‌کننده در رابطه به‌عنوان کلیدهای خارجی است و این کلیدهای خارجی با هم کلید اصلی ترکیبی جدول میانی را تشکیل می‌دهند. همچنین هر ویژگی توصیفی که به خود رابطه تعلق دارد، به این جدول اضافه می‌شود.

      • مثال: برای رابطه WORKSON بین EMPLOYEE و PROJECT با صفت Hours، یک جدول میانی به نام WORKSON(EmpSSN{ ext{FK}}, ProjNo{ ext{FK}}, Hours) ایجاد می‌شود که کلید اصلی آن { ext{EmpSSN, ProjNo}} است.

    6. Mapping of Multivalued Attributes: برای هر خصیصه چند مقداری (مانند Locations برای Department)، یک رابطه/جدول جدید ایجاد می‌شود. این جدول شامل کلید خارجی به کلید اصلی جدول اصلی (که خصیصه چند مقداری متعلق به آن است) و ستونی برای نگهداری مقادیر چندمقداری است. کلید اصلی این جدول میانی، ترکیبی از کلید خارجی و ستون مقادیر چندمقداری خواهد بود.

      • مثال: برای DLocation چند مقداری از DEPARTMENT، جدول DEPTLOCATIONS(DNUMBER{ ext{FK}}, DLOCATION) با کلید ترکیبی (DNUMBER, DLOCATION) ایجاد می‌شود.

    7. Mapping of N-nary Relationship Types: برای رابطه‌های N-تایی (با N > 2)، یک جدول جدید ایجاد می‌شود. این جدول شامل کلیدهای اصلی هر یک از موجودیت‌های شرکت‌کننده در رابطه به‌عنوان کلیدهای خارجی است. این کلیدهای خارجی با هم کلید اصلی ترکیبی جدول جدید را تشکیل می‌دهند. همچنین، هر ویژگی ساده‌ای که به خود رابطه N-تایی تعلق دارد، به‌عنوان یک ستون به این جدول اضافه می‌شود.

      • مثال: رابطه سه‌گانه SUPPLY بین SUPPLIER, PART, PROJECT با صفت QUANTITY به جدول SUPPLY(SName{ ext{FK}}, PartNo{ ext{FK}}, ProjName_{ ext{FK}}, Quantity) نگاشت می‌شود.

    8. Options for Mapping Specialization or Generalization: برای نگاشت تخصص‌سازی یا تعمیم، چندین گزینه وجود دارد (مانند نگاشت به یک جدول واحد، نگاشت به جدول برای هر زیرکلاس، یا نگاشت به جدول برای ابرکلاس و جدول برای هر زیرکلاس با کلید خارجی). انتخاب گزینه به محدودیت‌های خاص (مانند گسستگی و کامل بودن) و نیازهای عملکردی بستگی دارد.

    9. Mapping of Union Types (Categories): برای دسته‌بندی‌ها (Union-types)، از روشی استفاده می‌شود که یک جدول برای Category ایجاد می‌شود. این جدول دارای کلید اصلی مخصوص به خود است و شامل چندین کلید خارجی (یکی برای هر سوپرکلاس شرکت‌کننده) می‌شود که هر کدام می‌تواند NULL باشد. Only one of these foreign keys will hold a value for any given tuple in the category table, indicating from which superclass the tuple originated.

نمادها و نمودارهای جایگزین

  • در طول تاریخ، دیاگرام‌های ER/EER از نمادهای خاصی (مانند مستطیل برای موجودیت، لوزی برای رابطه و بیضی برای ویژگی) استفاده کرده‌اند. با این حال، ابزارهای طراحی مدرن و محیط‌های توسعه اغلب از نمادهای جایگزین و استاندارد شده‌ای مانند نمودار کلاس UML (Unified Modeling Language) استفاده می‌کنند که مفاهیم مشابهی را با رویکرد شیءگرایانه نمایش می‌دهند.

  • یادیگری: بسیاری از نمادها را می‌توان به صورت جایگزین نشان داد؛ به‌عنوان مثال، یک کلاس در UML می‌تواند یک موجودیت در ER را نشان دهد، وassociation (ارتباط) در UML معادل رابطه در ER است. درک این مفاهیم جایگزین برای کار با ابزارهای مختلف ضروری است.

تفاوت ER/EER و UML

  • ER/EER (Entity-Relationship / Extended Entity-Relationship): هدف اصلی آن مدل‌سازی مفهومی داده برای طراحی پایگاه داده است. تمرکز بر موجودیت‌ها، ویژگی‌ها، روابط و نحوه ذخیره‌سازی داده‌ها است. EER قابلیت‌های وراثت و تخصص‌سازی/تعمیم را به ER اضافه می‌کند.

  • UML Class Diagram (نمودار کلاس UML): هدف اصلی آن مدل‌سازی شیء‌گرا، طراحی و ساختاردهی نرم‌افزار است. تمرکز بر کلاس‌ها، اشیاء، ویژگی‌ها، متدها و روابط بین آن‌ها (مانند وراثت، ترکیب، تجمیع) است. UML یک استاندارد بسیار گسترده‌تر است که برای مدل‌سازی جنبه‌های مختلف سیستم‌های نرم‌افزاری استفاده می‌شود. در حالی که نمودارهای کلاس UML می‌توانند برای طراحی پایگاه داده استفاده شوند، اما مدل‌سازی داده یک زیرمجموعه از قابلیت‌های آن‌ها است.

  • ** تفاوت اصلی در نمایش وراثت، روابط و هم‌نشانی آنها است.** ER/EER بیشتر بر ساختار داده‌ای متمرکز است، در حالی که UML بر رفتار و ساختار شی‌گرایانه سیستم تمرکز دارد. هر دو برای طراحی پایگاه داده و سیستم‌های نرم‌افزاری با رویکردهای مختلف استفاده می‌شوند، اما EER معمولاً گزینه "زبان مادری" برای طراحی پایگاه داده‌های رابطه‌ای است.

جمع‌بندی فصل EER

  • مفاهیم کلیدی: در این فصل، مفاهیم اساسی مانند موجودیت‌ها، روابط، ویژگی‌ها، کلیدها، و همچنین مفاهیم افزوده EER مانند زیرکلاس/ابرکلاس، تخصص‌سازی/تعمیم و دسته‌بندی بررسی شد.

  • وراثت: مفهوم وراثت نقش محوری در EER دارد و شامل وراثت ویژگی‌ها و روابط بین ابرکلاس‌ها و زیرکلاس‌ها می‌شود، که به طراحی مدل‌های داده‌ای با قابلیت استفاده مجدد و انعطاف‌پذیری بالا کمک می‌کند.

  • قیدها: محدودیت‌های گسستگی (Disjointness) و کامل بودن (Completeness) ابزارهای قدرتمندی برای تعیین دقیق محدودیت‌های عضویت موجودیت‌ها در زیرکلاس‌ها هستند.

  • انواع وراثت: مدل‌سازی وراثت می‌تواند به دو صورت سلسله‌مراتبی (Hierarchy - وراثت تک‌گانه) یا شبکه‌ای (Lattice - وراثت چندگانه) باشد. همچنین Shared Subclass و Union Type نیز برای مدل‌سازی سناریوهای پیچیده‌تر به کار می‌روند.

  • نمایش تخصص‌سازی: رابطه IS-A که از طریق مثلث تخصص‌سازی بین ابرکلاس و زیرکلاس نمایش داده می‌شود، قلب نمایش سلسله‌مراتب در EER است.

  • نگاشت ER-to-Relational: گام‌های ۱ تا ۹ الگوریتم نگاشت برای تبدیل دیاگرام‌های ER/EER به طرحواره‌های رابطه‌ای، همراه با توضیحات و مثال‌های مربوطه، ارائه شد. این فرایند اساسی برای پیاده‌سازی مدل‌های مفهومی در پایگاه داده‌های رابطه‌ای است.

  • نکته مهم: در طراحی پایگاه داده‌های واقعی، ترکیبی از هر دو فرایند Specialization و Generalization کاربرد دارد و اغلب به عنوان تکمیل کننده همدیگر استفاده می‌شوند تا مدل داده‌ای منعطف و دقیق ایجاد شود.

فصل پنجم: مدل رابطه‌ای (Relational Model)

مفاهیم پایه مدل رابطه‌ای

  • مدل رابطه‌ای یکی از پراستفاده‌ترین و موفق‌ترین مدل‌های داده‌ای است که بر پایه مفهوم ریاضی "رابطه" بنا شده است.

  • سازماندهی داده‌ها: داده‌ها به صورت روابط (Relations) یا جداول سازماندهی می‌شوند. این جداول ساختاری دوبعدی دارند که از سطرها و ستون‌ها تشکیل شده‌اند.

  • جداول، سطرها، ستون‌ها: هر رابطه یک جدول است که سطرها (Tuples) و ستون‌ها (Attributes) دارد. سطرها نماینده‌ی نمونه‌های منفرد یک موجودیت (یا یک نمونه از رابطه) هستند و ستون‌ها (که به آن‌ها فیلد یا خصیصه هم گفته می‌شود) نمایانگر ویژگی‌های آن موجودیت‌اند.

  • تعریف رسمی از عناصر مدل رابطه‌ای:

    • Relation: یک جدول که مجموعه‌ای از سطور (tuples) است.

    • Attribute: یک ویژگی یا ستون در جدول که دارای نام منحصر به فرد است.

    • Tuple: یک سطر در جدول که مجموعه‌ای از مقادیر مرتبط برای هر Attribute است و یک شیء یا رابطه جهان واقعی را نشان می‌دهد.

    • Domain: مجموعه مقادیر مجاز و قانونی برای یک ویژگی خاص. مقادیر خارج از دامنه مجاز نیستند.

  • مبنای ریاضی: مدل رابطه‌ای را می‌توان به صورت رسمی با ترکیب مستقیم جبر مجموعه‌ها و منطق (به‌ویژه منطق مرتبه اول) تعریف کرد، که این ویژگی آن را بسیار پایدار و قدرتمند می‌سازد.

  • پیاده‌سازی متداول: SQL (Structured Query Language) به‌عنوان استانداردترین و پرکاربردترین زبان برای پیاده‌سازی، مدیریت و پرس‌وجو از پایگاه داده‌های رابطه‌ای شناخته شده است.

تعاریف غیررسمی و رسمی عناصر مدل رابطه‌ای

  • Relation (رابطه): یک جدول با نامی یکتا که شامل مجموعه‌ای از n-تایی‌ها (tuples) است، به‌طوری که برای هر صفت، مقداردهی دقیق و از دامنه خودش است. می‌توان آن را به عنوان یک زیرمجموعه از ضرب دکارتی دامنه‌ها در نظر گرفت: R imes D1 imes D2 imes ext{…} imes D_n

  • Attribute (ویژگی): یک نام و نوع داده‌ای مشخص برای یک ستون در رابطه. هر ویژگی اطلاعات خاصی درباره موجودیت را ذخیره می‌کند.

  • Tuple (رکورد): یک سطر واحد در جدول که یک نمونه از موجودیتی را که توسط مقادیر Attribute تشریح می‌شود، نمایش می‌دهد. هر Tuple مجموعه‌ای از جفت‌های (Attribute, Value) است.

  • Domain: دامنه مقادیر مجاز برای هر ویژگی، که نوع داده (مانند INTEGER, VARCHAR, DATE) و احتمالا محدودیت‌های دیگر (مانند NOT NULL, CHECK) را مشخص می‌کند. مقادیر در هر سلول رابطه باید اتمی (Atomic) باشند، به این معنی که نمی‌توانند به اجزای کوچکتر تجزیه شوند (عدم وجود مقادیر چندبخشی یا پیچیده در یک سلول واحد).

  • Schema (طرحواره یک رابطه): ساختار منطقی یک رابطه، شامل نام رابطه و لیست تمام خصائص آن به همراه دامنه‌شان. به عنوان مثال، EMPLOYEE (SSN, Name, BirthDate, Salary).

  • Database Schema (طرحواره پایگاه داده): مجموعه‌ای از چند Relation Schema (طرحواره‌های رابطه) که با هم یک پایگاه داده کامل را تشکیل می‌دهند و ارتباطات بین جداول را نیز مشخص می‌کنند.

کلیدها و محدودیت‌های داده‌ای

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

  • کلید (Key): مجموعه‌ای از یک یا چند ویژگی که سطرها را به طور یکسان در یک جدول متمایز می‌کند. هیچ دو سطری در یک رابطه نمی‌توانند در مقادیر کلید یکسان باشند.

  • Superkey (فوق کلید): هر مجموعه‌ای از یک یا چند ویژگی که می‌تواند یک سطر را به‌طور منحصربه‌فرد در یک رابطه شناسایی کند. یک Superkey ممکن است شامل ویژگی‌های اضافی باشد که برای شناسایی منحصربه‌فرد ضروری نیستند. به‌عنوان مثال، در جدول EMPLOYEE (SSN, Name, Address, Phone), {SSN} یک Superkey است. {SSN, Name} نیز یک Superkey است.

  • Candidate Key (کلید کاندیدا): یک Superkey مینیمال (کوچک‌ترین) است؛ یعنی زیرمجموعه هیچ Superkey دیگری نیست. Candidate Keyها کلیدهای ممکن و بالقوه برای شناسایی یکتای هر سطر در رابطه هستند. هر Relation حداقل یک Candidate Key دارد.

  • Primary Key (کلید اصلی): یکی از Candidate Keyها است که توسط طراح پایگاه داده برای شناسایی یکتا هر سطر در رابطه انتخاب می‌شود. این کلید برای ارجاع از سایر جداول (از طریق کلید خارجی) به کار می‌رود و باید NOT NULL و UNIQUE باشد.

  • Surrogate Key (کلید جایگزین یا کلید مصنوعی): یک کلید داخلی یا مصنوعی است (معمولاً یک عدد ترتیبی اتوماتیک مانند AUTO_INCREMENT یا IDENTITY) که تنها به‌منظور یکتایی و بدون هیچ معنای تجاری ایجاد می‌شود. از این کلیدها زمانی استفاده می‌شود که کلیدهای طبیعی پیچیده، طولانی یا تغییرپذیر باشند.

  • تفاوت کلید و ابر کلید: هر Candidate Key یک Superkey است، اما هر Superkey الزاماً یک Candidate Key نیست (زیرا ممکن است مینیمال نباشد و شامل ویژگی‌های اضافی باشد).

محدودیت‌های یکپارچگی (Integrity Constraints)

محدودیت‌های یکپارچگی، قوانینی هستند که برای حفظ صحت و ثبات داده‌ها در پایگاه داده اعمال می‌شوند:

  • Entity Integrity Constraint (یکپارچگی موجودیت): مقدار کلید اصلی (Primary Key) هرگز نباید NULL باشد. این تضمین می‌کند که هر سطر در جدول یک شناسایی یکتا و معتبر دارد.

  • Referential Integrity Constraint (یکپارچگی ارجاعی): اگر یک کلید خارجی (Foreign Key) در یک جدول (جدول ارجاع دهنده) وجود داشته باشد، مقدار آن باید یا به یک مقدار کلید اصلی معتبر در جدول ارجاع شونده اشاره کند، یا اگر تعریف شده باشد، می‌تواند NULL باشد. این محدودیت برای حفظ پیوستگی بین جداول و جلوگیری از ارجاع به داده‌های ناموجود است.

  • Domain Constraint (محدودیت قلمرو): مقدار هر ستون (Attribute) باید از دامنه مجاز مربوط به آن ستون پیروی کند. این شامل نوع داده (Integer, String, Date) و هرگونه محدودیت اضافی (مانند محدودیت طولی، یا محدوده عددی) است.

مفاهیم عملی قلمروی SQL

  • SQL (Structured Query Language): زبان SQL ابزار اصلی تعامل با پایگاه داده‌های رابطه‌ای است و برای تعریف طرحواره، درج، به‌روزرسانی، حذف و بازیابی داده‌ها استفاده می‌شود.

  • تفاوت بین مدل رسمی و پیاده‌سازی: در سطح عملیاتی مانند SQL، به‌علاوه قواعد مدل رابطه‌ای رسمی، محدودیت‌های فنی و کارایی (مانند نوع داده‌ها، ایندکس‌ها، بهینه‌سازی کوئری‌ها) نیز مطرح می‌شود که در مدل رسمی کمتر به آن‌ها پرداخته می‌شود. SQL با دستوراتی مانند CREATE TABLE, PRIMARY KEY, FOREIGN KEY REFERENCES, NOT NULL, CHECK محدودیت‌های یکپارچگی را پیاده‌سازی می‌کند.

نمونه‌های عملی و مفهومی

  • نمونه‌ای از رابطه CAR: فرض کنید یک جدول CAR(License ext{}number{ ext{PK}}, Engine ext{}serial ext{}number, Make, Model, Year) داریم. در اینجا، License ext{}number و Engine ext{}serial ext{}number هر دو Candidate Key هستند. می‌توانیم License ext{}number را به‌عنوان کلید اصلی (Primary Key) انتخاب کنیم.

  • نقش دامنه‌ها و مقادیر اتمی: مقادیر در هر سلول باید اتمی باشند. به‌عنوان مثال، یک سلول برای Phone_Number نباید شامل چندین شماره تلفن باشد؛ اگر نیاز به ذخیره چندین شماره تلفن برای یک موجودیت باشد، باید از یک جدول جداگانه برای Phone_Numbers استفاده شود. NULL تنها برای مقادیر نامشخص یا مفقود استفاده می‌شود (و نه برای یک مقدار 0 یا یک رشته خالی).

  • مثال‌های مفهومی از طرح‌های دیتابیس: طرح COMPANY اغلب برای نشان دادن نحوه نگاشت یک مدل ER به relational استفاده می‌شود. این طرح شامل جداولی مانند EMPLOYEE, DEPARTMENT, DEPTLOCATIONS, PROJECT, WORKSON, DEPENDENT است که نشان می‌دهد چگونه موجودیت‌ها و روابط آن‌ها به جداول، کلیدهای اصلی و خارجی تبدیل می‌شوند.

نمودارها و نمایش‌های جایگزین در SQL/رویه‌ها

  • طرح ساده‌ای از طرحواره COMPANY در SQL شامل جداولی مانند:

    • DEPARTMENT (Dname, Dnumber PK, Mgr_ssn FK, Mgr_start_date)

    • EMPLOYEE (Fname, Minit, Lname, Ssn PK, Bdate, Address, Sex, Salary, Super_ssn FK, Dno FK)

    • PROJECT (Pname, Pnumber PK, Plocation, Dnum FK)

    • WORKS_ON (Essn FK, Pno FK, Hours) - PK میانی (Essn, Pno)

    • DEPENDENT (Essn FK, Dependent_name PK, Sex, Bdate, Relationship)

  • این جداول با استفاده از کلیدهای اصلی و خارجی به یکدیگر متصل می‌شوند و نمایش می‌دهند که چگونه ارتباطات (مانند WORKS_ON، DEPENDENT) در مدل ER/EER به جداول و محدودیت‌های رابطه‌ای نگاشت می‌شوند. نگاشت‌های چند مقداری و چندطرفه نیز با ایجاد جداول اضافی برای پوشش آن‌ها در مدل رابطه‌ای، در گام‌های قبلی توضیح داده شد.

نکته‌های کلیدی برای مرور (مختصر برای آماده‌سازی امتحان)

  • تفاوت ER/EER و UML: ER/EER بیشتر برای مدل‌سازی مفهومی داده برای طراحی پایگاه داده به کار می‌رود، در حالی که UML (نمودارهای کلاس) برای مدل‌سازی شیءگرا و طراحی نرم‌افزار گسترده‌تر است. هر دو ابزار با مفاهیم وراثت سروکار دارند اما با تمرکز متفاوت.

  • نگاشت ER-to-Relational: باید گام‌های اصلی این نگاشت را با توجه به نوع موجودیت (قوی/ضعیف) و نوع رابطه (۱:۱، ۱:N، N:M، چندارزشی، N-ary و تخصص‌سازی/تعمیم) به‌درستی درک و اعمال کنید. این بخش از مهم‌ترین قسمت‌های طراحی پایگاه داده است.

  • قواعد کلیدی در محدودیت‌های یکپارچگی: Entity Integrity (کلید اصلی NULL نمی‌تواند باشد)، Referential Integrity (کلید خارجی باید به PK معتبر اشاره کند یا NULL باشد) و Domain Constraints (مقادیر در دامنه مجاز خود باشند) از اصول اساسی هستند.

  • مفاهیم کلیدها: تفاوت بین Superkey, Candidate Key, Primary Key و Foreign Key را کاملاً درک کنید. Surrogate Keys نیز در موارد خاص برای شناسایی یکتا کاربرد دارند.

  • در دو فصل ابتدایی تا فصل ۵، مفاهیم پایه‌ای ER/EER و سپس مدل رابطه‌ای و مبانی SQL مرور می‌شود و به‌هم مرتبط هستند، بطوریکه طراحی مفهومی با ER/EER به طراحی عملی با relational و پیاده‌سازی در SQL می‌رسد.

نکته‌های فرعی و مثال‌های تکمیلی

  • مثال‌های متعدد از EMPLOYEE، SECRETARY، TECHNICIAN، ENGINEER و MANAGER: این مثال‌ها به صورت مکرر برای نشان دادن روابط IS-A، تخصص‌سازی و نقش هر کدام در نمودارها استفاده می‌شوند تا درک عمیق‌تری از مفهوم سلسله‌مراتب وراثت و دسته‌بندی ارائه دهند.

  • Generalization و Specialization عملی: در عمل، طراحان پایگاه داده اغلب از ترکیبی از هر دو رویکرد استفاده می‌کنند. به‌عنوان مثال، ابتدا موجودیت‌های Student و Teacher می‌توانند به Person تعمیم یابند و سپس Person می‌تواند به MalePerson و FemalePerson بر اساس جنسیت تقسیم شود (Specialization).

  • رابطه‌های N-ary (چندطرفه): در نقشه‌های N-ary مانند SUPPLY، رابطه‌ای سه‌گانه بین SUPPLIER، PART، و PROJECT وجود دارد. این رابطه با یک جدول جداگانه (مثلاً SUPPLY) نمایش داده می‌شود که شامل کلیدهای خارجی به هر سه موجودیت شرکت‌کننده (مثلاً SupplierID{ ext{FK}}, PartID{ ext{FK}}, ProjectID_{ ext{FK}}) و همچنین هر ویژگی مرتبط با خودِ رابطه (مانند QUANTITY) است. کلید اصلی جدول SUPPLY ترکیبی از این کلیدهای خارجی است.

فرمول‌ها و نمادهای ریاضی (LaTeX)

  • حالت یک رابطه (State of a Relation) R با Attributeها A1, A2, ext{…}, An: این حالت توسط مجموعه‌ای از سطرها (tuples) در هر لحظه خاص تعریف می‌شود و زیرمجموعه‌ای از حاصلضرب دکارتی دامنه‌ها است:
    State(R) ext{ } orall    {ti ext{ of } R} (ti[Aj] ext{ } ext{is in } dom(Aj)) ext{ and } ( ext{State}(R) ext{ is finite})

  • کلیدهای اصلی، کلیدهای کاندیدا و کلید جایگزین (نمونه‌ها):

    • Primary Key (PK): یک Candidate Key منتخب و منحصر به فرد برای هر جدول.

    • Candidate Key (CK): هر کلید مینیمالی که به طور منحصربه‌فرد سطرها را شناسایی می‌کند. (CK
      ightarrow R و CK'
      ot
      ightarrow R ext{ for any } CK' ext{ proper subset of } CK)

    • Superkey (SK): هر مجموعه‌ای از Attributeها که منحصربه‌فرد است. (SK
      ightarrow R)

  • کلیدهای ترکیبی (Composite Key): کلیدی که از چندین ویژگی تشکیل شده است. اگر K یک کلید ترکیبی باشد، آنگاه:
    PK = ext{{A1, A2, ext{…}, Ak}}

  • نگاشت رابطه دودویی ext{M:N} (Many-to-Many) با جدول میانی:

    • ایجاد جدول جدید (Relation Schema) برای رابطه MN. این جدول دارای کلیدهای خارجی به هر دو طرف رابطه است و کلید اصلی آن ترکیبی از این دو کلید خارجی خواهد بود.

    • فرض کنید رابطه R بین موجودیت‌های E1 (با PK1) و E2 (با PK2) باشد. جدول میانی TR خواهد بود: TR (PK1{ ext{FK}}, PK2{ ext{FK}}, ext{AttributesofR})

    • کلید اصلی جدول میانی: PK{Mid} = (PK1{ ext{FK}}, PK2_{ ext{FK}})

  • نگاشت چند مقداری (Multivalued attributes):

    • ایجاد یک رابطه جدید (جدول) برای نگهداری مقدارهای متعدد از یک Attribute.

    • فرض کنید Attribute M از موجودیت E (با PKE) چند مقداری باشد. جدول جدید TM خواهد بود:
      TM (PKE{ ext{FK}}, M{ ext{value}})

    • کلید اصلی این جدول ترکیبی: PK{TM} = (PKE{ ext{FK}}, M_{ ext{value}})

پایان

  • این notes به‌طور جامع از مفاهیم EER (Extended Entity-Relationship) و نگاشت ER-to-Relational تا مبانی مدل رابطه‌ای و مفاهیم SQL (Structured Query Language) را پوشش می‌دهد و می‌تواند به عنوان یک منبع قابل‌اعتماد و جامع برای مطالعه و مرور قبل از امتحان عمل کند. این مطالب به دانشجویان کمک می‌کند تا هم پایه‌های نظری و هم جنبه‌های عملی طراحی و پیاده‌سازی پایگاه‌های داده را درک کنند.