Modern Database Management - Chapter 3 Vocabulary

Enhanced E-R Model

An enhanced entity-relationship (EER) model is an advanced extension of the traditional E-R model, designed to incorporate more complex data modeling constructs. It provides a richer set of tools and techniques to represent intricate relationships, behaviors, and constraints within a database system.

Supertypes and Subtypes

• Enhanced E-R (EER) Model:

  • Extends the original E-R model.

  • Introduces constructs like supertypes, subtypes, and advanced features.

  • Enhances representation of complex relationships and data structures.

• Subtype:

  • A subgrouping of entities within an entity type.

  • Possesses attributes distinct from other subgroupings.

  • Inherits attributes and relationships from its supertype.

  • Has unique attributes applicable only to the subtype.

• Supertype:

  • A generic entity type related to one or more subtypes.

  • Contains attributes common to all subtypes.

  • Represents shared characteristics among its subtypes.

• Attribute Inheritance:

  • Subtype entities inherit all attributes and relationships of the supertype.

  • Ensures consistency and reduces data redundancy.

  • A subtype instance is also a supertype instance.

  • Any instance of a subtype is considered an instance of its supertype.

Relationships and Subtypes

• Relationships at the supertype level imply participation of all subtypes.

  • Simplifies the model by defining relationships at the highest applicable level.

• Subtype instances may participate in relationships unique to that subtype.

  • Shown at the subtype level.

  • Specific to the subtype and do not apply to other subtypes or the supertype.

Generalization and Specialization

• Generalization: Defining a more general entity type from specialized entity types (Bottom-Up).

  • Example: Car, Truck, and Motorcycle entity types generalized into a Vehicle supertype.

  • Vehicle supertype contains shared attributes like Vehicle ID, Make, and Model.

  • Simplifies querying and reporting across all vehicle types.

• Specialization: Defining subtypes of a supertype (Top-Down).

  • Example: A Part entity type specialized into Manufactured Part and Purchased Part.

  • Manufactured Part subtype has attributes like Production Date and Batch Number.

  • Purchased Part subtype has attributes like Supplier and Purchase Order Number.

Constraints in Supertype/Subtype Relationships

• Completeness Constraints: Determine if a supertype instance must be a member of at least one subtype.

  • Ensures all instances of the supertype are properly categorized.

  • Total Specialization Rule: Every supertype instance must be a member of a subtype (double line notation).

    • No supertype instances exist without being part of a subtype.

  • Partial Specialization Rule: Supertype instance is not required to be a member of any subtype (single line notation).

    • Allows supertype instances that do not belong to any defined subtype.

    • Provides flexibility in representing entities that may not fit into specific subtypes.

    • Explanation:

      • In a partial specialization, a supertype entity can exist without needing to be classified under any of its subtypes.

      • This is useful when some entities within the supertype have characteristics that do not align with any of the defined subtypes.

    • Example:

      • Consider a Vehicle supertype with Car and Truck subtypes.

      • With partial specialization, a Vehicle instance might exist that is neither a Car nor a Truck (e.g., a motorcycle).

      • This contrasts

• Disjointness Constraints: Determine if a supertype instance can be a member of multiple subtypes simultaneously.

  • Ensures instances are correctly categorized into one or more subtypes.

  • Disjoint Rule: A supertype instance can be only one of the subtypes.

    • An instance can only belong to one subtype at a time.

  • Overlap Rule: A supertype instance can be more than one of the subtypes.

    • Allows an instance to belong to multiple subtypes simultaneously.

• Subtype Discriminator: An attribute of the supertype that determines the target subtype(s).

  • Used to identify which subtype(s) a supertype instance belongs to.

  • Disjoint: A simple attribute with alternative values indicating possible subtypes.

    • Example: Employee supertype with Employee Type discriminator.

    • Values: 'H' for Hourly, 'S' for Salaried, and 'C' for Consultant.

    • Facilitates easy identification of employee type.

  • Overlapping: A composite attribute with subparts pertaining to different subtypes.

    • Each subpart contains a Boolean value indicating membership in the associated subtype.

    • Example: PART supertype with subtypes MANUFACTURED PART and PURCHASED PART.

    • Part Type discriminator is a composite attribute with Manufactured? and Purchased? boolean sub-attributes.

    • If Manufactured? = “Y”, then it’s a manufactured part.

    • If Purchased? = “Y”, then it’s a purchased part.

Entity Clusters

• EER diagrams can become difficult to read with numerous entities and relationships.

  • Complex diagrams can be hard to understand and maintain.

• Entity cluster: A set of entity types and associated relationships grouped into a single abstract entity type.

  • Simplifies diagrams and enhances understanding.

• Solution: Group entities and relationships into entity clusters for better readability.

  • Involves identifying related entities and grouping them into a higher-level entity.

Packaged Data Models

• Predefined data models (universal or industry-specific).

  • Provide a starting point for data modeling projects.

  • Customizable to fit specific needs.

• Universal data model: A generic data model reusable as a starting point for data modeling (a "pattern").

  • Designed to be flexible and adaptable to various business contexts.

Advantages of Packaged Data Models

• Use proven model components.

  • Based on established best practices and industry standards.

• Save time and cost.

  • Reduce time and effort required to develop a data model from scratch.

• Reduce likelihood of data model errors.

  • Tested and refined over time, reducing the risk of errors.

• Easier to evolve and modify over time.

  • Designed to be flexible and adaptable to changing business requirements.

• Aid in requirements determination.

  • Provide a framework for identifying and documenting data requirements.

• Easier to read.

  • Use standard notation and conventions, making them easier to understand.

• Supertype/subtype hierarchies promote reuse.

  • Allow reuse of common attributes and relationships.

• Many-to-many relationships enhance model flexibility.

  • Allow representation of complex relationships between entities.

• Vendor-supplied data models foster integration