COMP102: Introduction to Databases, 13

Size: px

Start display at page:

Download "COMP102: Introduction to Databases, 13"

Silvester Holland
5 years ago
Views:

1 COMP102: Introduction to Databases, 13 Dr Muhammad Sulaiman Khan Department of Computer Science University of Liverpool U.K. 7 March, 2011

2 Logical Database Design: Enhanced ER Modeling

3 Specific topics for today: The limitations of the basic ER modeling concepts and the requirements to model more complex applications using enhanced data modeling concepts. The main concepts of the Enhanced Entity Relationship (EER) model called specialization/generalization. UML notation for displaying specialization/generalization in an EER diagram. How to create tables that represent specialization/generalization in an EER model.

4 The Enhanced Entity Relationship (EER) model Basic concepts are often perfectly adequate for the representation of the data requirements for many different database applications. However, basic concepts can be limiting when modeling more complex database applications with a large amount of data a and/or data with complex interrelationships. Stimulated need to develop additional semantic modeling concepts. Original ER model with additional semantic concepts is referred to as the Enhanced Entity Relationship (EER) model. One of the most useful concepts of the EER model is called specialization/generalization.

5 Specialization/generalization Associated with special types of entities known as superclasses and subclasses, and the process of attribute inheritance. Superclass: An entity that includes one or more distinct groupings of its occurrences, which require to be represented in a data model. Subclass: A distinct grouping of occurrences of an entity type, which require to be represented in a data model. Superclass/subclass relationship: Superclass/subclass relationship is one-to-one (1:1). Each member of a subclass is also a member of the superclass but has a distinct role.

6 Superclasses and subclasses We can use superclasses and subclasses to avoid describing different types of entities with possibly different attributes within a single entity. Can also show relationships that are only associated with particular subclasses and not with superclass. Adds more semantic information to the design of a form: manager IS-A member of Staff, van IS-A type of vehicle.

7 Example: AllStaff table holding details of all staff:

8 Attribute inheritance An entity occurrence in a subclass represents the same real world object as in the superclass. Hence, a member of a subclass inherits those attributes associated with the superclass, but may also have subclass-specific attributes. Example: SalesPersonnel is subclass of the superclass Staff: Inherited attributes of subclass SalesPersonnel: staffno, name, position, salary, branchno. Subclass-specififc attributes of subclass SalesPersonnel: salesarea, vehlicenseno, carallowance. An entity and its subclasses and their subclacces, and so on, is called type hierarchy. Type hierarchy is also known under many different names: Specialization hierarchy: e.g., Manager is specialization of Staff. Generalization hierarchy: e.g., Staff is generalization of Manager. IS-A hierarchy: e.g., Manager IS-A (member of) Staff. Shared subclass: Subclass having more than one superclass.

9 Specialization/generalization Specialization: The top-down process of maximizing the differences between members of an entity by identifying their distinguishing characteristics. Given superclass(es) it leads to identifying subclass(es). Generalization: The bottom-up process of minimizing the differences between entities by identifying their common characteristics. Given subclass(es) it leads to identifying superclass(es).

10 Example: Staff entity with subclasses representing job roles (UML diagram): Note: multiplicuty of Manager in Manages is 1..1; multiplicity of Staff in Manages was 0..1.

11 Example: Entity Staff: Shared subclass and a subclass with its own subclass (UML diagram):

12 Example: from the previous slide, contd.: Subclass SalesManager is a shared subclass. Thus: Member of the subclass SalesManager is also a member of classes Manager, SalesPersonnel, and Staff. Also: Attributes of the superclass Staff, and attributes of the subclasses Manager and SalesPersonnel are inherited by the SalesManager subclass, which also has its own attribute called salestarget. Subclass Secretary has its own subclass AssistantSecretary.

13 Constraints on specialization/generalization Two constraints may apply to a specialization/generalization called participation constraints and disjoint constraints. Participation constraint: Determines whether every occurrence in the superclass must participate as a member of a subclass. May be mandatory (i.e., every entity occurrence in the superclass must be a member of a subclass) or optional (i.e., any entity occurrence in the superclass need not belong to any of the subclasses). Disjoint constraint: Describes the relationship between members of the subclasses and indicates whether it is possible for a member of a superclass to be a member of one, or more than one, subclass. Applies only if the superclass has more than one subclass. May be disjoint (i.e., if subclasses are pair-wise disjoint, Or) or nondisjoint (i.e., if some of the subclasses are non-disjoint, And).

14 Example: Vehicle entity into vehicle types (UML diagram):

15 Constraints on specialization/generalization There are four categories of constraints of specialization and generalization: mandatory and disjoint; optional and disjoint; mandatory and nondisjoint; optional and nondisjoint.

Creating tables to represent specialization/generalization (i.e., translating EER diagram into tables (relational model): For each superclass/subclass relationship in EER model, designate the

16 Creating tables to represent specialization/generalization (i.e., translating EER diagram into tables (relational model): For each superclass/subclass relationship in EER model, designate the superclass as the parent entity (table) and the subclass as the child entity (table). How many tables is required to represent such relationship depends on the participation and disjoint constraints.

17 Creating tables to represent specialization/generalization, contd. Although, the table in the previous slide presents only general guidelines of how to model the specialization/generalization relationships with tables, there are further factors that influence the final modeling: whether the subclasses are involved in distinct relationships; the number of attributes that are distinct to each subclass; the relative number of entity occurrences represented by the superclass and by each subclass. Note: Compare these issues with modeling ER 1:1 relationship with optional participation on both sides as tables that we discussed in Lecture 12.

18 Example: Tables representing Staff and the Branch entities: Based on previous example with Staff superclass and subclasses Manager, SalesPersonnel, and Secretary; constraints are { Optional, Nondisjoint (And) }:

19 Example: Tables representing the Vehicle entity: Based on previous example with Vehicle superclass and subclasses Van, Bus, and Car; constraints are { Mandatory, Disjoint (Or) }:

Lecture 10. Spring 2018 Borough of Manhattan Community College

Lecture 10. Spring 2018 Borough of Manhattan Community College Lecture 10 Spring 2018 Borough of Manhattan Community College 1 Chapter Objectives In this lecture you will learn: The limitations of the basic concepts of the Entity-Relationship (ER) model and the requirements