Chapter 13 Enhanced Entity-Relationship Modeling Ahmed M. Zeki ITIS 216 ITBIS 385

Objectives Limitations of basic concepts of the ER model and requirements to represent more complex applications using additional data modeling concepts. Most useful additional data modeling concept of Enhanced ER (EER) model is called specialization/generalization. A diagrammatic technique for displaying specialization/generalization in an EER diagram using UML. / 45

Enhanced ER Model ER model is adequate for building data models of traditional administrative DB systems Stock control Product ordering Customer invoicing Since 1980s there has been an increase in emergence of new DB applications with more demanding requirements. / 45

Examples of such applications: Computer Aided Design (CAD) Computer Aided Manufacturing (CAM) Computer Aided Software Engineering (CASE) tools Office Information Systems (OIS) Multimedia Systems Digital Publishing Geographical Information Systems (GIS) Basic concepts of ER modeling are not sufficient to represent requirements of newer, more complex applications.  Development of additional ‘semantic’ modeling concepts. / 45

Specialization/Generalization Associated with special types of entities knows as : Superclass: an entity type that includes one or more distinct sub-groupings of its occurrences, which require to be represented in a data model Subclass: a distinct subgrouping of occurrences of an entity type, which require to be represented in a data model / 45

Ex: entities that are members of the Staff entity type may be classified as Manager SalesPersonnel Secretary The relationship between a superclass and any one of its sublacsses is called a superclass/subclass relationship Ex: Staff/Manager / 45

Each member of a subclass is also a member of the superclass. i.e. the entity in the subclass is the same entity in the superclass Superclass/subclass relationship is one-to- one (1:1). Superclasses may contain overlapping or distinct subclasses. A member of staff who is both a manager and a member of SalesPersonnel.  we say that Manager and SalesPersonnel are overlapping subclasses of the Staff superclass. / 45

Not all members of a superclass need be a member of a subclass Ex: members of staff without a distinct job role such as a Manager or a member of SalesPersonnel We use superclasses and subclasses to avoid describing different types of staff with possible different attributes within a single entity. Ex: SalesPersonnel may have special attributes such as salesArea and carAllowence / 45

If all staff attributes and those specific to particular jobs are described by a single staff entity, this may result in a lot of nulls for the job-specific attributes. Partially filled. Many Nulls / 45

Clearly SalesPersonnel have common attributes with other staff, such as staffNo, name, position, and salary. It is the unshared attributes that cause problems when we try to represent all members of staff within a single entity. There are also relationships that are only associated with particular types of staff (subclass) but not with staff. Ex: SalesPersonnel may have distinct relationships that are not appropriate for all staff such as SalesPersonnel Uses Car. / 45

Why using Superclasses and Subclasses in the ER models? To avoid describing similar concepts more than once  saving time for the designer and making the ER diagram more readable. To add more semantic info to the design in a form that is familiar to many people. Ex: the assertions that ‘Manager IS-A member of staff” “flat IS-A type of property”, communicates significant semantic content in a concise form. / 45

Attribute Inheritence An entity in a subclass represents the same realworld object as in the superclass, and may possess subclass-specific attributes, as well as those associated with the superclass. Ex: a member of the SalesPersonnel subclass inherits all the attributes of the Staff superclass such as staffNo, name, position, and salary together with those specifically associated with the SalesPersonnel subclass such as salesArea and carAllowance. / 45

A subclass is an entity in its own right and so it may also have one or more subclasses. An entity and its subclasses and their subclasses and so on, is called a type hierarchy. / 45

Type hierarchies are known by a variety of names including: Specialization hierarchy Ex: Manager is a specialization of Staff Generalization hierarchy Ex: Staff is a generalization of Manager IS-A hierarchy Ex: Manager IS-A member of staff / 45

A subclass with more than one superclass is called shared subclass. i.e. a member of ahsared subclass must be a member of the associated superclasses. The attributes of the superclasses are inherited by the shared subclass, which may also have its own additional attributes. This process is referred to as multiple inheritance. / 45

Specialization Specialization Process of maximizing differences between members of an entity by identifying their distinguishing characteristics. It is a top-down approach to defining a set of superclasses and their related subclasses. The set of subclasses is defined on the basis of some distinguishing characteristics of the entities in the superclasse. / 45

Specialization When we identify a set of subclasses of an entity type, we then: associate attributes specific to each subclass (where necessary), and also identify any relationships between each subclass and other entity types or subclasses (where necessary). / 45

Specialization Ex: in a model, all members of staff are represented as an entity called Staff. To apply the process of specialization on the Staff entity, we attempt to identify differences between members of this entity such as members with distinctive attributes and/or relationships, such as Manager, SalesPersonnel and Secretary which have distinctive attributes  we identify them as subclasses of a specialized Staff superclass. / 45

Generalization Generalization Process of minimizing differences between entities by identifying their common characteristics. Is a bottom-up approach, which results in the identification of a generalized superclass from the original entity types. Reverse of specialization. / 45

Generalization Ex: in a model has Manager, SalesPersonnel, and Secretary represented as distinct entity types. By applying the generalization on these entities we attempt to identify similarities between them such as common attributes and relationships. These entities share attributes common to all staff  we identify Manager, SalesPersonnel and Secretary as (job roles) subclasses of a generalized Staff superclass. / 45

Specialization / Generalization Common attributes Relationship applicable to only one subclass Describes the constraints on the relationship between the superclass and its subclasses Attributes specific to a given subclass are listed in the box. / 45

Specialization / Generalization Can be a member of more than one Every member of Staff must have a contract of employment Either Full or part time, not both We may have several specialization of the same entity / 45

Specialization / Generalization Example of type hierarchy: A member of Staff need not have an additional job role such as Manager SalesPersonnel or Secretary A member of this is a member of the Secretary and Staff  attributes of Staff and Secretary are inheritied by AssistantSecretary which also has its onw attributes. A member of this must be a member of the above 2 parent superclasses as well as the Staff superclasses  Attributes of Staff, Manager, & SalesPersonnel are inherited by SalesManager No need to put Or, And for single subclass / 45

Constraints on Speci/Gener Participation Constraints Determines whether every member in the superclass must participate as a member of a subclass It can be: Mandatory participation Every member in the superclass must also be a member of a subclass (use {Mandatory} below the triangle) Optional participation A member of a superclass need not belong to any of its subclasses (use {Optional} below the triangle / 45

Constraints on Speci/Gener Disjoint Constraints 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 / 45

Constraints on Speci/Gener Only applies when a superclass has more than one subclass. If the subclass are disjoint then an entity occurrence can be a member of only one of the subclasses. Use ‘Or’ next to the participation constraint. If the sublcass are nondisjoint then an entity occurrence may be a member of more than one subclass, use ‘And’ next to the participation constraint. / 45

Constraints on Speci/Gener Categories of constraints of specialization and generalization: Mandatory and disjoint Optional and disjoint Mandatory and nondisjoint Optional and nondisjoint / 45

Worked Example The inclusion of the Spec./Gene. is optional in building EER model. The choice to use it or not is dependent on the complexity of the enterprise and whether using the additional concepts of the EER model will help the process of DB design. There are several instances where there is a potential to use Spec./Gener: / 45

Fig 11.1 / 45

Worked Example Three options in representing the Staff entity: Represent all members of staff as a generalized Staff entity Create three distinct entities Staff, Manager, and Supervisor Represent the Manager and Supervisor as subclasses of a Staff superclass. The option we select is based on the commonality of attributes and relationships associated with each entity. / 45

Worked Example For example all attributes of the Staff entity are represented in the Manager and Supervisor entities, including the same primary key (staffNo). The supervisor entity does not have any additional attributes representing this job role. Both Manager and Supervisor entities are associated with distinct relationships (Manager Manages Branch) and (Supervisor Supervises Staff). / 45

Worked Example Based on this information, we select the 3rd option and create Manager and Supervisor subclasses of the Staff superclass. Not all members of staff are Managers or Supervisors. A single member of staff can’t be both a Manager and a Supervisor. / 45

Worked Example Relationship between owners. There are 2 types of owners: PrivateOwner BusiensssOwner Three options in modeling the owners: Leave PrivateOwner and BusienssOwner as two distinct entities. Represent both types of owners as a generalized Owner entity. Represent the PrivateOwner and BusinessOwner as subclasses of Owner superclass. / 45

Worked Example To decide, examine the attributes and relationships associated with these entities: PrivateOwner and BusinessOwner share the common attributes: address and telNo. They both also have similar relationship with property for rent (i.e. PrivateOwner Pwons PropertyForRent and BusinessOwner Powns PropertyForRent) / 45

Worked Example Both types of owner also have different attributes: PrivateOwner has distinct attributes bName, bType, and contactName. We create a superclass called Owner, with PrivateOwner and BusinessOwner as subclasses: An owner must be either a private owner or a business owner, but can’t be both. / 45

Worked Example There are several persons with common characteristics described in the data requirements specification for the Branch user views. For example, member of staff, private property owners, and clients all have number and name attributes. / 45

Worked Example  we create a Person superclass with Staff (including Manager and Supervisor subclasses), PrivateOwner, and Client as subclasses. / 45

Worked Example To what extent we wish to use Spec./Gener to represent the Branch user views? To simplify EER we chose only (a) and (b), but not (c) because the use of spec/gener in this case places too much emphasis on the relationship between entities that are persons rather than emphasizing the relationship between these entities and some of the core entities such as Branch and PropertyForRent. The option to use Spec./Gener is a subjective decision.  Optional step. / 45

Fig 12.8 / 45

Aggregation Represent a “Has-a” or “is-part-of” relationship entity types, where one represents the “whole” and the other the “part”. It does not change the meaning of navigation across the relationship between the whole and its parts, nor does it link the lifetimes of the whole and its parts. Ex: Branch Has Staff. / 45

Aggregation Use open diamond at one end of the relationship line, next to the entity that represents the ‘whole’. Staff staffNo Branch branchNo < Has 1..* 1..1 0..1 1..1 Oversees v 0..100 PropertyForRent propertyNo < Offers 1..* / 45

Composition A specific form of aggregation that represents an association between entities, where there is a strong ownership and coincidental lifetime between the ‘whole’ and the ‘part’. Aggregation is entirely conceptual and does nothing more than distinguish a ‘whole’ from a ‘part’. / 45

Composition In a composite, the ‘whole’ is responsible for the disposition of the ‘parts’, which means that the composition must manage the creation and destruction of its ‘parts’. i.e. an object may only be part of one composite at a time. / 45

Composition Example: Displays relationship relates the Newspaper entity to the Advert entity.  an Advert entity (part) belongs to exactly one Newspaper entity (whole). This is in contrast to aggregation, in which a part may be shared by many wholes. Ex: a staff entity may be ‘a part of’ one or more Branches entities. Advert 1..* Display ^ 1..1 Newspaper newspaperName / 45

Composition The option to use aggregation and composition, and to what extent, are subjective decisions. They should only be used when there is a requirement to emphasize special relationships between entity types such as ‘has-a’ or ‘is-part- of’, which has implications on the creation, update, and deletion of these closely related entities. We should only use them when the enterprise data is too complex to easily represent using only the basic concepts of ER model. / 45