Acadezi branded
Acadezi logo

๐Ÿ“Š Fundamentals of Database Systems

Chapter 4: Enhanced Entity Relationship (EER) Modeling โ€“ detailed organized explanation

๐Ÿ“„ SLIDE 1 โ€“ Learning Objectives
Seventh Edition

๐ŸŽฏ Chapter 4: Enhanced Eโ€‘R (EER) Modeling

  • 4.1 EER stands for Enhanced ER or Extended ER.
  • 4.2 EER Model Concepts โ€“ includes all basic ER concepts plus additional ones.
  • 4.3 EER is used to model applications more completely and accurately; includes objectโ€‘oriented concepts like inheritance.
  • 4.4 Knowledge Representation and Ontology Concepts.

EER ู‡ูŠ ุงู…ุชุฏุงุฏ ู„ู€ ER ูˆุชุถูŠู ู…ูุงู‡ูŠู… ู…ุซู„: ุงู„ูƒุงุฆู†ุงุช ุงู„ูุงุฆู‚ุฉ/ุงู„ูุฑุนูŠุฉุŒ ุงู„ุชุฎุตุต/ุงู„ุชุนู…ูŠู…ุŒ ุงู„ูุฆุงุช (Union)ุŒ ูˆุฑุงุซุฉ ุงู„ุณู…ุงุช ูˆุงู„ุนู„ุงู‚ุงุชุŒ ูˆุงู„ู‚ูŠูˆุฏ.

๐Ÿ“„ SECTION 4.2 โ€“ EER Model Concepts

๐Ÿงฉ EER Additional Concepts

Includes all modeling concepts of basic ER plus:

  • Subclasses / Superclasses
  • Specialization / Generalization
  • Categories (UNION types)
  • Attribute and relationship inheritance

Also includes constraints on specialization/generalization.

๐Ÿ“˜ ุดุฑุญ ุชุนู„ูŠู…ูŠ โ€“ ู…ุง ู‡ูˆ ู†ู…ูˆุฐุฌ EERุŸ

ููŠ ุงู„ูุตูˆู„ ุงู„ุณุงุจู‚ุฉ ุชุนู„ู…ู†ุง ู†ู…ูˆุฐุฌ ER ุงู„ุฐูŠ ูŠุนุชู…ุฏ ุนู„ู‰ ูƒูŠุงู†ุงุช ูˆุนู„ุงู‚ุงุช ุจุณูŠุทุฉ. ู„ูƒู† ุนู†ุฏ ุชุตู…ูŠู… ู‚ูˆุงุนุฏ ุจูŠุงู†ุงุช ุญู‚ูŠู‚ูŠุฉุŒ ู†ุฌุฏ ุฃู† ุงู„ุนุงู„ู… ุงู„ูˆุงู‚ุนูŠ ูŠุญุชูˆูŠ ุนู„ู‰ ุชูุงุตูŠู„ ุฃูƒุซุฑ ุชุนู‚ูŠุฏุงู‹. ุนู„ู‰ ุณุจูŠู„ ุงู„ู…ุซุงู„: ุงู„ู…ูˆุธููˆู† ู„ูŠุณูˆุง ูƒู„ู‡ู… ู…ุชุดุงุจู‡ูŠู†ุŒ ูู‡ู†ุงูƒ ู…ู‡ู†ุฏุณูˆู† ูˆุณูƒุฑุชุงุฑูŠุฉ ูˆู…ุฏุฑุงุกุŒ ูˆู„ูƒู„ ู…ุฌู…ูˆุนุฉ ุฎุตุงุฆุต ุฅุถุงููŠุฉ. ู‡ู†ุง ูŠุฃุชูŠ ุฏูˆุฑ ู†ู…ูˆุฐุฌ EER (ุงู„ู†ู…ุฐุฌุฉ ุงู„ู…ูˆุณุนุฉ ู„ู„ูƒูŠุงู†ุงุช ูˆุงู„ุนู„ุงู‚ุงุช) ุงู„ุฐูŠ ูŠุถูŠู ู…ูุงู‡ูŠู… ู‚ูˆูŠุฉ ู…ุซู„:

  • Subclasses/Superclasses (ุงู„ูƒุงุฆู†ุงุช ุงู„ูุฑุนูŠุฉ ูˆุงู„ูุงุฆู‚ุฉ) โ€“ ู„ุชู…ุซูŠู„ ุงู„ุชุตู†ูŠูุงุช ุงู„ู…ุฎุชู„ูุฉ.
  • Specialization/Generalization (ุงู„ุชุฎุตุต ูˆุงู„ุชุนู…ูŠู…) โ€“ ุทุฑู‚ ุจู†ุงุก ู‡ุฐู‡ ุงู„ุชุตู†ูŠูุงุช.
  • Categories (UNION types) (ุงู„ูุฆุงุช) โ€“ ุนู†ุฏู…ุง ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ุงู„ูƒุงุฆู† ู…ู† ุนุฏุฉ ุฃู†ูˆุงุน ู…ุฎุชู„ูุฉ.
  • Inheritance (ุงู„ูˆุฑุงุซุฉ) โ€“ ุญูŠุซ ุชุฑุซ ุงู„ูƒุงุฆู†ุงุช ุงู„ูุฑุนูŠุฉ ุตูุงุช ุงู„ูƒุงุฆู†ุงุช ุงู„ูุงุฆู‚ุฉ.
  • Constraints (ุงู„ู‚ูŠูˆุฏ) โ€“ ู‚ูŠูˆุฏ ุนู„ู‰ ูƒูŠููŠุฉ ุชูˆุฒูŠุน ุงู„ูƒุงุฆู†ุงุช ุจูŠู† ุงู„ุชุตู†ูŠูุงุช.

ู‡ุฐู‡ ุงู„ู…ูุงู‡ูŠู… ุชุฌุนู„ ุงู„ู†ู…ูˆุฐุฌ ุฃูƒุซุฑ ุฏู‚ุฉ ูˆู‚ุฏุฑุฉ ุนู„ู‰ ุชู…ุซูŠู„ ุงู„ูˆุงู‚ุนุŒ ูˆู‡ูŠ ุชุดุจู‡ ู…ูุงู‡ูŠู… ุงู„ุจุฑู…ุฌุฉ ุงู„ูƒุงุฆู†ูŠุฉ (OOP) ู…ุซู„ ุงู„ูˆุฑุงุซุฉ.

๐Ÿ“„ 4.2.2.1 โ€“ Subclasses & Superclasses

๐Ÿ”น Subclasses and Superclasses

What is a subclass?

An entity type may have additional meaningful subgroupings of its entities โ€“ these are called subclasses (or subtypes).

Example: EMPLOYEE can be grouped into: SECRETARY, ENGINEER, TECHNICIAN (based on job), MANAGER (role), SALARIED_EMPLOYEE, HOURLY_EMPLOYEE (based on pay method).

Each subclass is a subset of the superclass EMPLOYEE. EMPLOYEE is the superclass for each.

๐Ÿ“Œ ISโ€‘A Relationships

These are called ISโ€‘A relationships: SECRETARY ISโ€‘A EMPLOYEE, TECHNICIAN ISโ€‘A EMPLOYEE, etc.

Important: An entity that is a member of a subclass represents the same real-world entity as some member of the superclass. The subclass member is the same entity in a distinct specific role.

An entity cannot exist in the database merely by being a member of a subclass; it must also be a member of the superclass. A member of the superclass can optionally be included in any number of its subclasses.

Examples:
  • A salaried employee who is also an engineer belongs to two subclasses: ENGINEER and SALARIED_EMPLOYEE.
  • A salaried employee who is also an engineering manager belongs to three subclasses: MANAGER, ENGINEER, SALARIED_EMPLOYEE.

Figure 4.1 โ€“ EER notation for subclasses and specialization

๐Ÿ“˜ ุดุฑุญ ุชุนู„ูŠู…ูŠ โ€“ ุงู„ูƒุงุฆู†ุงุช ุงู„ูุฑุนูŠุฉ ูˆุงู„ูุงุฆู‚ุฉ (Subclasses & Superclasses)

ุงู„ู‡ุฏู: ุชู…ุซูŠู„ ุฃู† ุงู„ูƒูŠุงู†ุงุช ููŠ ุงู„ูˆุงู‚ุน ู„ูŠุณุช ูƒู„ู‡ุง ู…ุชุดุงุจู‡ุฉุŒ ุจู„ ู„ู‡ุง ุชุตู†ูŠูุงุช ูุฑุนูŠุฉ.

Superclass (ูƒุงุฆู† ูุงุฆู‚) ู‡ูˆ ูƒูŠุงู† ุนุงู…ุŒ ู…ุซู„ EMPLOYEE. Subclass (ูƒุงุฆู† ูุฑุนูŠ) ู‡ูˆ ู…ุฌู…ูˆุนุฉ ุฌุฒุฆูŠุฉ ู…ู† ู‡ุฐุง ุงู„ูƒูŠุงู†ุŒ ู…ุซู„ ENGINEER. ุงู„ุนู„ุงู‚ุฉ ุจูŠู†ู‡ู…ุง ุชุณู…ู‰ ISโ€‘A (ู‡ูˆ ู†ูˆุน ู…ู†).

ู‚ูˆุงุนุฏ ู…ู‡ู…ุฉ:

  • ุงู„ูƒุงุฆู† ููŠ subclass ู‡ูˆ ู†ูุณ ุงู„ูƒูŠุงู† ููŠ superclassุŒ ู„ูƒู† ุจุฏูˆุฑ ู…ุญุฏุฏ. ู…ุซู„ุงู‹: ุฃุญู…ุฏ ู‡ูˆ ู…ูˆุธูุŒ ูˆู‡ูˆ ุฃูŠุถุงู‹ ู…ู‡ู†ุฏุณ. ู„ุง ูŠูˆุฌุฏ ุดุฎุตุงู† ู…ู†ูุตู„ุงู†.
  • ู„ุง ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ู‡ู†ุงูƒ ูƒุงุฆู† ููŠ subclass ุฏูˆู† ุฃู† ูŠูƒูˆู† ู…ูˆุฌูˆุฏุงู‹ ููŠ superclass. (ู„ุง ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ู‡ู†ุงูƒ ู…ู‡ู†ุฏุณ ุฏูˆู† ุฃู† ูŠูƒูˆู† ู…ูˆุธูุงู‹).
  • ุงู„ูƒุงุฆู† ููŠ superclass ูŠู…ูƒู† ุฃู† ูŠู†ุชู…ูŠ ุฅู„ู‰ ุนุฏุฉ subclasses. ู…ุซู„ุงู‹: ู…ูˆุธู ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ู…ู‡ู†ุฏุณุงู‹ ูˆู…ุฏูŠุฑุงู‹ ููŠ ู†ูุณ ุงู„ูˆู‚ุช.

ู…ุซุงู„ ู…ู† ุงู„ุญูŠุงุฉ: ููŠ ุฌุงู…ุนุฉุŒ ู„ุฏูŠู†ุง ูƒูŠุงู† PERSON. ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ู„ู‡ subclasses: STUDENT, PROFESSOR, STAFF. ูƒู„ ุดุฎุต ู‡ูˆ ุฃุญุฏ ู‡ุฐู‡ ุงู„ุฃุฏูˆุงุฑ (ุฃูˆ ุฃูƒุซุฑ). ุงู„ุตูุงุช ุงู„ู…ุดุชุฑูƒุฉ (ุงู„ุงุณู…ุŒ ุงู„ุนู†ูˆุงู†) ู…ูˆุฌูˆุฏุฉ ููŠ PERSONุŒ ูˆุงู„ุตูุงุช ุงู„ุฎุงุตุฉ (ู…ุซู„ ุงู„ุชุฎุตุต ู„ู„ุทุงู„ุจ) ุชุถุงู ููŠ subclass.

๐Ÿ“„ 4.2.2.4 โ€“ Attribute and Relationship Inheritance

๐Ÿงฌ Inheritance

An entity that is a member of a subclass inherits:

  • All attributes of the entity as a member of the superclass.
  • All relationships of the entity as a member of the superclass.

Example: SECRETARY, TECHNICIAN, ENGINEER inherit attributes Name, SSN, โ€ฆ, from EMPLOYEE. Every SECRETARY entity will have values for those inherited attributes.

Subclasses can also have specific (local) attributes (e.g., TypingSpeed for SECRETARY) and participate in specific relationship types (e.g., BELONGS_TO for HOURLY_EMPLOYEE).

๐Ÿ“˜ ุดุฑุญ ุชุนู„ูŠู…ูŠ โ€“ ุงู„ูˆุฑุงุซุฉ (Inheritance)

ุงู„ูˆุฑุงุซุฉ ู‡ูŠ ู…ูŠุฒุฉ ู‚ูˆูŠุฉ ููŠ EER. ุจุจุณุงุทุฉุŒ ุงู„ูƒุงุฆู† ููŠ subclass ูŠุฑุซ ูƒู„ ุงู„ุตูุงุช ูˆุงู„ุนู„ุงู‚ุงุช ุงู„ู…ูˆุฌูˆุฏุฉ ููŠ superclass. ู‡ุฐุง ูŠุนู†ูŠ ุฃู†ู†ุง ู„ุง ู†ุญุชุงุฌ ุฅู„ู‰ ุฅุนุงุฏุฉ ุชุนุฑูŠู ุงู„ุงุณู… ูˆุงู„ุฑู‚ู… ุงู„ู‚ูˆู…ูŠ ... ู„ูƒู„ ู…ู‡ู†ุฏุณ. ู‡ูŠ ู…ูˆุฌูˆุฏุฉ ุชู„ู‚ุงุฆูŠุงู‹.

ู…ุซุงู„: ูƒู„ SECRETARY ู„ู‡ ุงุณู… (Name) ูˆุฑู‚ู… ุถู…ุงู† ุงุฌุชู…ุงุนูŠ (SSN) ู…ู† EMPLOYEE. ุจุงู„ุฅุถุงูุฉ ุฅู„ู‰ ุฐู„ูƒุŒ ูŠู…ูƒู† ู„ู„ุณูƒุฑุชูŠุฑ ุฃู† ูŠูƒูˆู† ู„ู‡ ุณู…ุฉ ู…ุญู„ูŠุฉ ู…ุซู„ TypingSpeed (ุณุฑุนุฉ ุงู„ุทุจุงุนุฉ) ู„ุง ุชูˆุฌุฏ ุนู†ุฏ ุงู„ู…ูˆุธููŠู† ุงู„ุขุฎุฑูŠู†.

ูƒุฐู„ูƒุŒ ุงู„ุนู„ุงู‚ุงุช (ู…ุซู„ Works_For) ุงู„ุชูŠ ูŠุดุงุฑูƒ ููŠู‡ุง ุงู„ู…ูˆุธู ุชูƒูˆู† ู…ูˆุฑูˆุซุฉ ู„ู„ุณูƒุฑุชูŠุฑ. ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ู„ู„ุณูƒุฑุชูŠุฑ ุฃูŠุถุงู‹ ุนู„ุงู‚ุงุช ุฎุงุตุฉ ุจู‡.

ุชุดุจูŠู‡: ุงู„ูˆุฑุงุซุฉ ู…ุซู„ ุงู„ู…ูŠุฑุงุซ ููŠ ุงู„ุนุงุฆู„ุฉ: ุงู„ุฃุจ (superclass) ู„ู‡ ู…ู…ุชู„ูƒุงุช (ุตูุงุช)ุŒ ูˆุงู„ุฃุจู†ุงุก (subclasses) ูŠุฑุซูˆู† ู‡ุฐู‡ ุงู„ู…ู…ุชู„ูƒุงุชุŒ ูˆูŠู…ูƒู† ุฃู† ูŠุถูŠููˆุง ู…ู…ุชู„ูƒุงุช ุฎุงุตุฉ ุจู‡ู….

๐Ÿ“„ 4.2.2.2 โ€“ Specialization

โฌ‡๏ธ Specialization (topโ€‘down)

Specialization is the process of defining a set of subclasses of a superclass based on some distinguishing characteristics.

Examples:

  • {SECRETARY, ENGINEER, TECHNICIAN} based on job type.
  • MANAGER based on role.
  • {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE} based on method of pay.

We can have several specializations of the same superclass.

๐Ÿ“˜ ุดุฑุญ ุชุนู„ูŠู…ูŠ โ€“ ุงู„ุชุฎุตุต (Specialization)

ุงู„ุชุฎุตุต ู‡ูˆ ุนู…ู„ูŠุฉ ู…ู† ุงู„ุฃุนู„ู‰ ุฅู„ู‰ ุงู„ุฃุณูู„ (top-down). ู†ุจุฏุฃ ุจูƒูŠุงู† ุนุงู… (superclass) ุซู… ู†ู‚ุณู…ู‡ ุฅู„ู‰ ูƒุงุฆู†ุงุช ูุฑุนูŠุฉ (subclasses) ุจู†ุงุกู‹ ุนู„ู‰ ุตูุงุช ู…ู…ูŠุฒุฉ.

ู…ุซุงู„: ู„ุฏูŠู†ุง EMPLOYEE. ู†ู„ุงุญุธ ุฃู† ุงู„ู…ูˆุธููŠู† ูŠุฎุชู„ููˆู† ููŠ ูˆุธุงุฆูู‡ู…. ู„ุฐู„ูƒ ู†ุตู†ุน ุชุฎุตุตุงู‹ ูŠุณู…ู‰ Job_Specialization ูŠุชุถู…ู† {ENGINEER, SECRETARY, TECHNICIAN}. ูˆู†ุตู†ุน ุชุฎุตุตุงู‹ ุขุฎุฑ ูŠุณู…ู‰ Pay_Specialization ูŠุชุถู…ู† {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}.

ู„ู…ุงุฐุง ู†ุณุชุฎุฏู… ุงู„ุชุฎุตุตุŸ ู„ุฃู† ูƒู„ ู…ุฌู…ูˆุนุฉ ูุฑุนูŠุฉ ู‚ุฏ ุชุญุชุงุฌ ุฅู„ู‰ ุตูุงุช ุฅุถุงููŠุฉ ู„ุง ุชู†ุทุจู‚ ุนู„ู‰ ุจุงู‚ูŠ ุงู„ู…ูˆุธููŠู†. ู…ุซู„ุงู‹: ุงู„ู…ู‡ู†ุฏุณ ู‚ุฏ ูŠูƒูˆู† ู„ู‡ ุชุฎุตุต (Civil, Software) ู„ุง ู†ุญุชุงุฌู‡ ู„ู„ุณูƒุฑุชูŠุฑ.

๐Ÿ“„ 4.2.2.2 โ€“ Generalization

โฌ†๏ธ Generalization (bottomโ€‘up)

Generalization is the reverse of specialization. Several classes with common features are generalized into a superclass; original classes become its subclasses.

Example: CAR and TRUCK are generalized into VEHICLE. Both become subclasses of VEHICLE.

Figure 4.3 โ€“ Generalization

In practice, a combination of both processes is usually employed.

๐Ÿ“˜ ุดุฑุญ ุชุนู„ูŠู…ูŠ โ€“ ุงู„ุชุนู…ูŠู… (Generalization)

ุงู„ุชุนู…ูŠู… ู‡ูˆ ุนูƒุณ ุงู„ุชุฎุตุต. ู†ุจุฏุฃ ู…ู† ุงู„ุฃุณูู„ ุฅู„ู‰ ุงู„ุฃุนู„ู‰ (bottom-up). ู„ุฏูŠู†ุง ุนุฏุฉ ูƒูŠุงู†ุงุช ูุฑุนูŠุฉุŒ ู†ู„ุงุญุธ ุฃู†ู‡ุง ุชุดุชุฑูƒ ููŠ ุตูุงุช ู…ุนูŠู†ุฉุŒ ูู†ู‚ูˆู… ุจุฅู†ุดุงุก ูƒูŠุงู† ูุงุฆู‚ (superclass) ูŠุฌู…ุน ู‡ุฐู‡ ุงู„ุตูุงุช ุงู„ู…ุดุชุฑูƒุฉ.

ู…ุซุงู„: ู„ุฏูŠู†ุง CAR ูˆ TRUCK. ูƒู„ุงู‡ู…ุง ู„ู‡ ุฑู‚ู… ุชุนุฑูŠู (Vehicle_id) ูˆุทุฑุงุฒ (Model). ูŠู…ูƒู†ู†ุง ุฅู†ุดุงุก VEHICLE ูƒู€ superclass ูŠุญุชูˆูŠ ุนู„ู‰ ู‡ุฐู‡ ุงู„ุตูุงุช ุงู„ู…ุดุชุฑูƒุฉุŒ ูˆุชุตุจุญ CAR ูˆ TRUCK ูƒุงุฆู†ุงุช ูุฑุนูŠุฉ (subclasses).

ููŠ ุงู„ุชุทุจูŠู‚ุงุช ุงู„ุนู…ู„ูŠุฉ: ุบุงู„ุจุงู‹ ู…ุง ู†ุณุชุฎุฏู… ุฎู„ูŠุทุงู‹ ู…ู† ุงู„ุชุฎุตุต ูˆุงู„ุชุนู…ูŠู…. ู†ุจุฏุฃ ุจุชุญุฏูŠุฏ ุงู„ูƒูŠุงู†ุงุช ุงู„ุฑุฆูŠุณูŠุฉ ุซู… ู†ู†ู‚ุญ ุงู„ู†ู…ูˆุฐุฌ ุจุฅุถุงูุฉ ุงู„ุชุฎุตุตุงุช ุฃูˆ ุงู„ุชุนู…ูŠู…ุงุช ุญุณุจ ุงู„ุญุงุฌุฉ.

๐Ÿ“„ Types of Specialization

๐Ÿท๏ธ Types of Specialization

  • Predicate-defined (condition-defined): based on a condition (e.g., Job-type = 'Engineer').
  • Attribute-defined: a special case where condition is on the same attribute (defining attribute). Example: JobType is defining attribute for {SECRETARY, TECHNICIAN, ENGINEER}.
  • User-defined: membership is defined by the user on an entityโ€‘byโ€‘entity basis.

Figure 4.4 โ€“ Attribute-defined specialization on Job_type

๐Ÿ“˜ ุดุฑุญ ุชุนู„ูŠู…ูŠ โ€“ ุฃู†ูˆุงุน ุงู„ุชุฎุตุต

ูƒูŠู ู†ุญุฏุฏ ู…ู† ูŠู†ุชู…ูŠ ุฅู„ู‰ ุฃูŠ subclassุŸ ู‡ู†ุงูƒ ุซู„ุงุซ ุทุฑู‚:

  • Predicate-defined (ู…ุญุฏุฏ ุจุดุฑุท): ู†ุถุน ุดุฑุทุงู‹ ุนู„ู‰ ู‚ูŠู…ุฉ ุณู…ุฉ. ู…ุซู„ุงู‹: ุฅุฐุง ูƒุงู†ุช ู‚ูŠู…ุฉ ุงู„ุณู…ุฉ Job_type ุชุณุงูˆูŠ "Engineer" ูุฅู† ุงู„ู…ูˆุธู ูŠู†ุชู…ูŠ ุฅู„ู‰ subclass ENGINEER.
  • Attribute-defined (ู…ุญุฏุฏ ุจุณู…ุฉ): ู‡ุฐุง ู†ูˆุน ุฎุงุต ู…ู† ุงู„ุชุฎุตุต ุนู†ุฏู…ุง ูŠูƒูˆู† ุงู„ุดุฑุท ู…ุนุชู…ุฏุงู‹ ุนู„ู‰ ู†ูุณ ุงู„ุณู…ุฉ ู„ูƒู„ ุงู„ู€ subclasses. ุงู„ุณู…ุฉ ุชุณู…ู‰ defining attribute. ู…ุซุงู„: ุณู…ุฉ JobType ุชุญุฏุฏ ุงู„ุนุถูˆูŠุฉ ููŠ {SECRETARY, TECHNICIAN, ENGINEER}. ููŠ ุงู„ุฑุณู…ุŒ ู†ูƒุชุจ ุงุณู… ุงู„ุณู…ุฉ ุจุฌุงู†ุจ ุงู„ุฎุท.
  • User-defined (ู…ุญุฏุฏ ู…ู† ุงู„ู…ุณุชุฎุฏู…): ู„ุง ูŠูˆุฌุฏ ุดุฑุท ุขู„ูŠ. ุงู„ู…ุณุชุฎุฏู… (ุฃูˆ ุงู„ู…ุจุฑู…ุฌ) ู‡ูˆ ู…ู† ูŠู‚ุฑุฑ ูŠุฏูˆูŠุงู‹ ุฃูŠ ูƒุงุฆู† ูŠู†ุชู…ูŠ ู„ุฃูŠ subclass. ู‡ุฐุง ู…ู†ุงุณุจ ุนู†ุฏู…ุง ู„ุง ูŠู…ูƒู† ุงู„ุชุนุจูŠุฑ ุนู† ุงู„ุนุถูˆูŠุฉ ุจุดุฑุท ุจุณูŠุท.
๐Ÿ“„ 4.2.3 โ€“ Constraints on Specialization/Generalization

โš ๏ธ Two Basic Constraints

1. Disjointness Constraint

  • Disjoint (d): an entity can be a member of at most one subclass of the specialization. (Example: EMPLOYEE cannot be both SALARIED and HOURLY.)
  • Overlapping (o): an entity may be a member of more than one subclass. (Example: a person can be both STUDENT and EMPLOYEE.)

2. Completeness (Exhaustiveness) Constraint

  • Total (double line): every entity in the superclass must be a member of some subclass.
  • Partial (single line): an entity may not belong to any subclass.

๐Ÿ“Š Four Combinations

Disjoint, TotalEvery entity belongs to exactly one subclass, no overlap. (Example: Employee โ†’ Hourly/Salaried, must be one)
Disjoint, PartialAn entity can be in at most one subclass, but some may be in none. (Example: Vehicle โ†’ Car/Motorcycle, but some vehicles are neither)
Overlapping, TotalEvery entity belongs to at least one subclass, may belong to several. (Example: Person โ†’ Student/Employee, every person must be at least one)
Overlapping, PartialEntities may belong to one or more subclasses, or none. (Example: BankAccount โ†’ Savings/Checking, a customer may have both, one, or a basic account)

Figure 4.4 (disjoint partial) and Figure 4.5 (overlapping total)

๐Ÿ“˜ ุดุฑุญ ุชุนู„ูŠู…ูŠ โ€“ ุงู„ู‚ูŠูˆุฏ (Constraints)

ุนู†ุฏ ุชุตู…ูŠู… ุงู„ุชุฎุตุตุŒ ู†ุญุชุงุฌ ุฅู„ู‰ ุชุญุฏูŠุฏ ู‚ูŠุฏูŠู† ุฑุฆูŠุณูŠูŠู†:

ุฃูˆู„ุงู‹: ู‚ูŠุฏ ุงู„ุชุจุงูŠู† (Disjointness) โ€“ ูˆูŠุฑู…ุฒ ู„ู‡ ุจู€ d ุฃูˆ o

  • Disjoint (d): ุงู„ูƒุงุฆู† ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ุนุถูˆุงู‹ ููŠ subclass ูˆุงุญุฏ ูู‚ุท. ู…ุซุงู„: ู…ูˆุธู ู„ุง ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ููŠ ู†ูุณ ุงู„ูˆู‚ุช ู…ูˆุธูุงู‹ ุจุฑุงุชุจ ุดู‡ุฑูŠ ูˆู…ูˆุธูุงู‹ ุจุงู„ุณุงุนุฉ. ู‡ุฐุงู† ุงู„ู†ูˆุนุงู† ู…ุชู†ุงููŠุงู†.
  • Overlapping (o): ุงู„ูƒุงุฆู† ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ุนุถูˆุงู‹ ููŠ ุนุฏุฉ subclasses. ู…ุซุงู„: ุดุฎุต ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ุทุงู„ุจุงู‹ ูˆู…ูˆุธูุงู‹ ููŠ ู†ูุณ ุงู„ูˆู‚ุช. ุงู„ุฃุฏูˆุงุฑ ุบูŠุฑ ู…ุชู†ุงููŠุฉ.

ุซุงู†ูŠุงู‹: ู‚ูŠุฏ ุงู„ุงูƒุชู…ุงู„ (Completeness) โ€“ ูˆูŠุฑู…ุฒ ู„ู‡ ุจู†ูˆุน ุงู„ุฎุท

  • Total (ุฎุท ู…ุฒุฏูˆุฌ): ูƒู„ ูƒุงุฆู† ููŠ superclass ูŠุฌุจ ุฃู† ูŠู†ุชู…ูŠ ุฅู„ู‰ subclass ูˆุงุญุฏ ุนู„ู‰ ุงู„ุฃู‚ู„. ู…ุซุงู„: ูƒู„ ู…ูˆุธู ุฅู…ุง ุจุฑุงุชุจ ุดู‡ุฑูŠ ุฃูˆ ุจุงู„ุณุงุนุฉ. ู„ุง ูŠูˆุฌุฏ ู…ูˆุธู ุฎุงุฑุฌ ู‡ุฐูŠู† ุงู„ู†ูˆุนูŠู†.
  • Partial (ุฎุท ู…ูุฑุฏ): ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ู‡ู†ุงูƒ ูƒุงุฆู†ุงุช ููŠ superclass ู„ุง ุชู†ุชู…ูŠ ุฅู„ู‰ ุฃูŠ subclass. ู…ุซุงู„: ู…ุฑูƒุจุฉ ูŠู…ูƒู† ุฃู† ุชูƒูˆู† ุณูŠุงุฑุฉ ุฃูˆ ุฏุฑุงุฌุฉุŒ ู„ูƒู† ู‚ุฏ ุชูƒูˆู† ู‡ู†ุงูƒ ู…ุฑูƒุจุงุช ุฃุฎุฑู‰ (ุดุงุญู†ุฉ) ู„ูŠุณุช ู…ุตู†ูุฉ.

ู…ู† ู‡ุฐูŠู† ุงู„ู‚ูŠุฏูŠู†ุŒ ู†ุญุตู„ ุนู„ู‰ ุฃุฑุจุน ุญุงู„ุงุช (ุฃู†ุธุฑ ุงู„ุฌุฏูˆู„). ูู‡ู… ู‡ุฐู‡ ุงู„ุญุงู„ุงุช ูŠุณุงุนุฏ ููŠ ุชุตู…ูŠู… ู‚ุงุนุฏุฉ ุจูŠุงู†ุงุช ุฏู‚ูŠู‚ุฉ.

๐Ÿ“„ Specialization/Generalization Hierarchies & Lattices

๐ŸŒฒ Hierarchies and Lattices

  • Hierarchy: every subclass has only one superclass (single inheritance) โ€“ a tree structure.
  • Lattice: a subclass can have more than one superclass (multiple inheritance) โ€“ called a shared subclass.

Example: ENGINEERING_MANAGER is a subclass of both ENGINEER and MANAGER (shared subclass).

Figure 4.6 โ€“ Specialization lattice with shared subclass ENGINEERING_MANAGER

Inheritance in lattice: a subclass inherits attributes of all its direct and predecessor superclasses.

Figure 4.7 โ€“ Specialization lattice for UNIVERSITY database

๐Ÿ“˜ ุดุฑุญ ุชุนู„ูŠู…ูŠ โ€“ ุงู„ุชุฏุฑุฌุงุช ูˆุงู„ุดุจูƒุงุช (Hierarchies & Lattices)

ุนู†ุฏู…ุง ู†ุจุฏุฃ ููŠ ุจู†ุงุก ุชุฎุตุตุงุช ู…ุชุนุฏุฏุฉุŒ ู‚ุฏ ุชุชุดูƒู„ ู„ุฏูŠู†ุง ู‡ูŠุงูƒู„:

  • Hierarchy (ุชุฏุฑุฌ): ูƒู„ subclass ู„ู‡ superclass ูˆุงุญุฏ ูู‚ุท. ู‡ุฐุง ูŠุดุจู‡ ุงู„ูˆุฑุงุซุฉ ุงู„ูˆุญูŠุฏุฉ (single inheritance). ู…ุซุงู„: EMPLOYEE โ† ENGINEER โ† SOFTWARE_ENGINEER. ู„ุง ูŠูˆุฌุฏ ุณูˆู‰ ู…ุณุงุฑ ูˆุงุญุฏ ู„ู„ูˆุฑุงุซุฉ.
  • Lattice (ุดุจูƒุฉ): ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ู„ู„ู€ subclass ุฃูƒุซุฑ ู…ู† superclass ูˆุงุญุฏ. ู‡ุฐุง ูŠุณู…ู‰ ุงู„ูˆุฑุงุซุฉ ุงู„ู…ุชุนุฏุฏุฉ (multiple inheritance) ูˆุงู„ู€ subclass ูŠุณู…ู‰ shared subclass. ู…ุซุงู„: ENGINEERING_MANAGER ู‡ูˆ ู…ู‡ู†ุฏุณ (ENGINEER) ูˆู…ุฏูŠุฑ (MANAGER) ููŠ ู†ูุณ ุงู„ูˆู‚ุช. ู„ุฐู„ูƒ ูŠุฑุซ ุตูุงุช ุงู„ู…ู‡ู†ุฏุณ ูˆุตูุงุช ุงู„ู…ุฏูŠุฑ ู…ุนุงู‹.

ู…ู„ุงุญุธุฉ ู…ู‡ู…ุฉ: ููŠ ุงู„ุดุจูƒุฉุŒ ุงู„ู€ subclass ูŠุฑุซ ุตูุงุช ุฌู…ูŠุน ุงู„ู€ superclasses ุงู„ู…ุจุงุดุฑุฉ ูˆุบูŠุฑ ุงู„ู…ุจุงุดุฑุฉ. ู‡ุฐุง ูŠูˆูุฑ ู‚ูˆุฉ ุชุนุจูŠุฑูŠุฉ ูƒุจูŠุฑุฉ ู„ูƒู†ู‡ ูŠุถูŠู ุชุนู‚ูŠุฏุงู‹.

๐Ÿ“„ 4.2.2.3 โ€“ Categories (UNION Types)

๐Ÿ”ท Categories (Union Types)

In some cases, we need a single superclass/subclass relationship with more than one superclass โ€“ a category or UNION type.

Example: In a vehicle registration database, an owner can be a PERSON, a BANK, or a COMPANY. We create a category OWNER that is a subset of the union of these three entity types.

A category member must exist in at least one of its superclasses (typically just one).

Difference from shared subclass:

  • Shared subclass: subset of the intersection of its superclasses (must exist in all superclasses).
  • Category: subset of the union (exists in at least one).

Figure 4.8 โ€“ Two categories: OWNER and REGISTERED_VEHICLE

๐Ÿ“˜ ุดุฑุญ ุชุนู„ูŠู…ูŠ โ€“ ุงู„ูุฆุงุช (Categories / Union Types)

ู…ุดูƒู„ุฉ ุฌุฏูŠุฏุฉ: ุฃุญูŠุงู†ุงู‹ ู†ุญุชุงุฌ ุฅู„ู‰ ุชู…ุซูŠู„ ูƒุงุฆู† ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ู…ู† ุนุฏุฉ ุฃู†ูˆุงุน ู…ุฎุชู„ูุฉ ุชู…ุงู…ุงู‹. ู…ุซุงู„: ู…ู† ูŠู…ูƒู†ู‡ ุงู…ุชู„ุงูƒ ุณูŠุงุฑุฉุŸ ูŠู…ูƒู† ุฃู† ูŠูƒูˆู† ุดุฎุตุงู‹ (PERSON)ุŒ ุฃูˆ ุจู†ูƒุงู‹ (BANK) ู„ู‡ ุญู‚ ุงู„ุญุฌุฒ (lien)ุŒ ุฃูˆ ุดุฑูƒุฉ (COMPANY).

ุงู„ุญู„: ู†ู†ุดุฆ category (ูุฆุฉ) ุงุณู…ู‡ุง OWNER. ู‡ุฐู‡ ุงู„ูุฆุฉ ู‡ูŠ ุงุชุญุงุฏ (union) ู„ู„ูƒูŠุงู†ุงุช ุงู„ุซู„ุงุซุฉ. ุฃูŠ ุฃู† ุงู„ุนุถูˆ ููŠ OWNER ูŠุฌุจ ุฃู† ูŠูƒูˆู† ู…ูˆุฌูˆุฏุงู‹ ููŠ ูˆุงุญุฏ ุนู„ู‰ ุงู„ุฃู‚ู„ ู…ู† ู‡ุฐู‡ ุงู„ูƒูŠุงู†ุงุช (ูˆู„ูŠุณ ุจุงู„ุถุฑูˆุฑุฉ ูƒู„ู‡ุง).

ุงู„ูุฑู‚ ุจูŠู† category ูˆ shared subclass:

  • Shared subclass (ู…ุซู„ ENGINEERING_MANAGER) ูŠุดุชุฑุท ุฃู† ูŠูƒูˆู† ุงู„ูƒุงุฆู† ู…ูˆุฌูˆุฏุงู‹ ููŠ ุฌู…ูŠุน ุงู„ู€ superclasses (ุชู‚ุงุทุน โ€“ intersection).
  • Category (ู…ุซู„ OWNER) ูŠุดุชุฑุท ุฃู† ูŠูƒูˆู† ุงู„ูƒุงุฆู† ู…ูˆุฌูˆุฏุงู‹ ููŠ ูˆุงุญุฏ ุนู„ู‰ ุงู„ุฃู‚ู„ ู…ู† ุงู„ู€ superclasses (ุงุชุญุงุฏ โ€“ union).

ููŠ ุงู„ู…ุฎุทุทุงุชุŒ ู†ุฑู…ุฒ ู„ู„ูุฆุฉ ุจุฏุงุฆุฑุฉ ุฏุงุฎู„ู‡ุง ุญุฑู U (Union).

๐Ÿ“„ Formal Definitions of EER Model

๐Ÿ“ Formal Definitions

  • Class C: a type of entity with a corresponding set of entities (could be entity type, subclass, superclass, or category).
  • Subclass S of C: S inherits all attributes and relationships of C; the set of entities of S is always a subset of the set of entities of C.
  • Specialization Z = {Sโ‚, Sโ‚‚, ..., Sโ‚™} with superclass G. Z is total if union of all Sแตข = G; otherwise partial. Z is disjoint if Sแตข โˆฉ Sโฑผ = โˆ… for iโ‰ j; otherwise overlapping.
  • Predicate-defined subclass: S = G[p], where p is a condition on attributes of G.
  • Attribute-defined specialization: if a predicate A = cแตข is used for each subclass (A is the defining attribute).
  • Category (UNION type) T: T โІ (Dโ‚ โˆช Dโ‚‚ โˆช ... โˆช Dโ‚™) where Dแตข are defining superclasses. T is a subset of the union.
๐Ÿ“˜ ุดุฑุญ ุชุนู„ูŠู…ูŠ โ€“ ุชุนุฑูŠูุงุช ุฑุณู…ูŠุฉ

ู„ู„ุฏู‚ุฉุŒ ู†ุนุฑู ู‡ุฐู‡ ุงู„ู…ูุงู‡ูŠู… ุฑูŠุงุถูŠุงู‹:

  • Class: ุฃูŠ ู†ูˆุน ูƒูŠุงู† (entity type, subclass, superclass, category).
  • Subclass S ู…ู† C: S ู…ุฌู…ูˆุนุฉ ุฌุฒุฆูŠุฉ ู…ู† CุŒ ูˆุชุฑุซ ูƒู„ ุตูุงุช ูˆุนู„ุงู‚ุงุช C.
  • Specialization Z = {Sโ‚, Sโ‚‚, ..., Sโ‚™} ู…ุน superclass G. Z ู‡ูˆ total ุฅุฐุง ูƒุงู† ุงุชุญุงุฏ Sแตข = G (ุฃูŠ ุฃู† ูƒู„ ูƒุงุฆู† ููŠ G ูŠู†ุชู…ูŠ ู„ู€ subclass). Z ู‡ูˆ partial ุฅุฐุง ูƒุงู† ุงู„ุงุชุญุงุฏ ู…ุฌู…ูˆุนุฉ ุฌุฒุฆูŠุฉ ู…ู† G. Z ู‡ูˆ disjoint ุฅุฐุง ูƒุงู†ุช ุงู„ู…ุฌู…ูˆุนุงุช ู…ู†ูุตู„ุฉ (ู„ุง ูŠูˆุฌุฏ ุนู†ุตุฑ ู…ุดุชุฑูƒ).
  • Predicate-defined subclass: S = G[p] ุญูŠุซ p ุดุฑุท ุนู„ู‰ ุณู…ุงุช G. ู…ุซุงู„: ENGINEER = EMPLOYEE[Job_type = 'Engineer'].
  • Attribute-defined specialization: ุฅุฐุง ูƒุงู† ุงู„ุดุฑุท ู„ูƒู„ subclass ู‡ูˆ ู‚ูŠู…ุฉ ู…ุญุฏุฏุฉ ู„ู†ูุณ ุงู„ุณู…ุฉ. ู…ุซุงู„: ู„ูƒู„ subclass ุดุฑุท ุนู„ู‰ ุณู…ุฉ Job_type.
  • Category T: T โІ (Dโ‚ โˆช Dโ‚‚ โˆช ... โˆช Dโ‚™). ุฃูŠ ุฃู† ูƒู„ ุนู†ุตุฑ ููŠ T ู‡ูˆ ุนู†ุตุฑ ููŠ ูˆุงุญุฏ ุนู„ู‰ ุงู„ุฃู‚ู„ ู…ู† ุงู„ู€ superclasses.
๐Ÿ“„ Alternative Diagrammatic Notations

๐Ÿ”„ UML and Other Notations

EER diagrams use specific notation, but many design tools use alternatives like UML class diagrams.

Figure 4.10 โ€“ UML class diagram for specialization/generalization

Other notations exist for displaying attributes, cardinality ratios, (min, max) constraints, etc.

Figure A.1 โ€“ Alternative notations

ู‡ู†ุงูƒ ุฑู…ูˆุฒ ุจุฏูŠู„ุฉ ู„ุชู…ุซูŠู„ EER ู…ุซู„ UML class diagrams ูˆุฑู…ูˆุฒ ุฃุฎุฑู‰ ู„ู„ุณู…ุงุช ูˆุงู„ุนู„ุงู‚ุงุช ูˆุงู„ู‚ูŠูˆุฏ.

๐Ÿ“‹ COMPREHENSIVE SUMMARY

๐Ÿ“Œ Chapter 4 โ€“ EER Modeling: All Key Concepts

  • EER extends ER with: subclasses/superclasses, specialization/generalization, categories (UNION), inheritance, and constraints.
  • Subclass ISโ€‘A superclass; inherits attributes/relationships; can have local attributes.
  • Specialization (topโ€‘down): defining subclasses from a superclass. Generalization (bottomโ€‘up): combining classes into a superclass.
  • Types of specialization: predicate-defined, attribute-defined, user-defined.
  • Constraints: disjoint (d) vs overlapping (o); total (double line) vs partial (single line). Four combinations.
  • Hierarchy: single inheritance; Lattice: multiple inheritance (shared subclass).
  • Category (UNION type): subclass of more than one superclass (member in at least one).
  • Formal definitions: class, subclass, specialization, category.
  • Alternative notations: UML, various (min, max) notations.
๐Ÿ“˜ ุงู„ุฎู„ุงุตุฉ ุงู„ุชุนู„ูŠู…ูŠุฉ โ€“ ู…ุง ุชุนู„ู…ู†ุงู‡ ููŠ ู‡ุฐุง ุงู„ูุตู„
  • EER ู‡ูˆ ุงู…ุชุฏุงุฏ ู„ู€ ER ูŠุณู…ุญ ุจุชู…ุซูŠู„ ุฃูƒุซุฑ ุฏู‚ุฉ ู„ู„ูˆุงู‚ุน.
  • Subclasses (ูƒุงุฆู†ุงุช ูุฑุนูŠุฉ) ุชู…ุซู„ ุชุตู†ูŠูุงุช ุฏุงุฎู„ ุงู„ูƒุงุฆู† ุงู„ูุงุฆู‚ (superclass). ุงู„ุนู„ุงู‚ุฉ ู‡ูŠ ISโ€‘A.
  • Specialization (ุชุฎุตุต) ู‡ูˆ ุนู…ู„ูŠุฉ ุชู‚ุณูŠู… superclass ุฅู„ู‰ subclasses. Generalization (ุชุนู…ูŠู…) ู‡ูˆ ุนูƒุณู‡ุง.
  • ุงู„ู€ subclass ูŠุฑุซ (inherits) ูƒู„ ุตูุงุช ูˆุนู„ุงู‚ุงุช ุงู„ู€ superclassุŒ ูˆูŠู…ูƒู† ุฃู† ูŠุถูŠู ุตูุงุช ู…ุญู„ูŠุฉ.
  • ู‡ู†ุงูƒ ุฃู†ูˆุงุน ู…ู† ุงู„ุชุฎุตุต: ู…ุญุฏุฏ ุจุดุฑุทุŒ ู…ุญุฏุฏ ุจุณู…ุฉุŒ ู…ุญุฏุฏ ู…ู† ุงู„ู…ุณุชุฎุฏู….
  • ุงู„ู‚ูŠูˆุฏ: disjoint (d) ูˆ overlapping (o) (ู„ุชุญุฏูŠุฏ ุฅู…ูƒุงู†ูŠุฉ ุงู„ุงู†ุชู…ุงุก ู„ุนุฏุฉ subclasses)ุŒ ูˆ total/partial (ุฎุท ู…ุฒุฏูˆุฌ/ู…ูุฑุฏ) ู„ุชุญุฏูŠุฏ ู…ุง ุฅุฐุง ูƒุงู† ูƒู„ ูƒุงุฆู† ููŠ superclass ูŠุฌุจ ุฃู† ูŠู†ุชู…ูŠ ู„ู€ subclass.
  • Hierarchy: ูˆุฑุงุซุฉ ูˆุญูŠุฏุฉ. Lattice: ูˆุฑุงุซุฉ ู…ุชุนุฏุฏุฉ (shared subclass).
  • Category (Union type): ูุฆุฉ ุชู…ุซู„ ุงุชุญุงุฏ ุนุฏุฉ superclasses ู…ุฎุชู„ูุฉ (ุงู„ุนุถูˆ ููŠ ูˆุงุญุฏ ู…ู†ู‡ุง ุนู„ู‰ ุงู„ุฃู‚ู„).

๐Ÿ“˜ ACADEZI โ€“ clear, detailed, organized, bilingual

ู†ุชู…ู†ู‰ ู„ูƒู… ุงู„ุชูˆููŠู‚ ูˆุงู„ู†ุฌุงุญ

ุฌู…ูŠุน ุงู„ุญู‚ูˆู‚ ู…ุญููˆุธุฉ ACADEZI 2026 ©