Ch2 ER Model

8/18/2019 Ch2 ER Model

1/23

Chapter 2 : E-R Model

Syllabus:

1. Basic Conceptsa.

Introductionb. Overview of the Design Processc.

Design Phases

User RequirementsConceptual DesignLogical DesignPhysical Design

2. The Entity-Relationship (E-R) Modela. Entity and their Attributes

Entity

Attributes Attribute Value Attribute Types

o Simple versus Composite;

o

Single-valued versus Multivalued; ando Stored versus Derived.

Complex Attribute

Value Set (Domain) of Attribute

Null valueb. Entity Types ad Entity Sets, Key Attributes

Entity TypeEntity SetKey Attributes

c. Relationship Types, Relationship Sets, RolesRelationshipRelationship Type and Relationship Set

ParticipationRelationship InstanceRole names and Recursive Relationship SetDescriptive AttributesDegree of a Relationship Type

3. Mapping/Structural Constraintsa.

Cardinality Ratios for Binary RelationshipsOne to one

One to manyMany to oneMany to many

b. Participation Constraint

Total ParticipationPartial Participation

4. E-R Diagram

a. Basic Structureb. Mapping Cardinalityc.

Complex Constraintsd. Complex Attributes

e. Roles5. Weak Entity set6. Design Issues7. Extended E-R features8.

Design of an E-R Database Schema

9.

Reduction of an E-R schema to Tables


2/23

Year wise marks distribution:

Month Year Marks

Dec 2008 12

Jun 2009 10

Dec 2009 25

Jun 2010 16

Dec 2010 33

Jun 2011 10

Dec 2011 15

Jun 2012 20

1. Basic Concepts

1.a IntroductionIn this chapter we will learn to design a database schema. We focus on the entity-

relationship data model (E-R), which provides a means of identifying entities to berepresented in the database and how those entities are related. Ultimately, the databasedesign will be expressed in terms of a relational database design and an associated set ofconstraints. We show in this chapter how an E-R design can be transformed into a set of

relation schemas and how some of the constraints can be captured in that design.

1.b Overview of the Design Process

The task of creating a database application is a complex one, involving several tasks such asdesign of the database schema, design of the programs that access and update the data,

and design of a security scheme to control access to data. The needs of the users play a

central role in the design process. In this chapter, we focus on the design of the databaseschema, although we briefly outline some of the other design tasks later in the chapter.

The design of a complete database application environment that meets the needs of theenterprise being modeled requires attention to a broad set of issues. These additionalaspects of the expected use of the database influence a variety of design choices at thephysical, logical, and view levels.

1.c Design Phases

For small applications, it may be feasible for a database designer who understands theapplication requirements to decide directly on the relations to be created, their attributes,and constraints on the relations. However, such a direct design Process is difficult for real-

world applications, since they are often highly complex. Often no one person understands

the complete data needs of an application. The database designer must interact with usersof the application to understand the needs of the application, represent them in a high-levelfashion that can be understood by the users, and then translate the requirements into lowerlevels of the design. A high level data model serves the database designer by providing aconceptual framework in which to specify, in a systematic fashion, the data requirements ofthe database users, and a database structure that fulfills these requirements.

User Requirements

The initial phase of database design is to characterize fully the data needs of theprospective database users. The database designer needs to interact extensively withdomain experts and users to carry out this task. The outcome of this phase is a specificationof user requirements. While there are techniques for diagrammatically representing userrequirements, in this chapter we restrict ourselves to textual descriptions of userrequirements.


3/23

Conceptual Design

Next, the designer chooses a data model and, by applying the concepts of the chosen datamodel, translates these requirements into a conceptual schema of the database. Theschema developed at this conceptual-design phase provides a detailed overview of theenterprise. The entity-relationship model, which we study in the rest of this chapter, is

typically used to represent the conceptual design. Stated in terms of the entity-relationship

model, the conceptual schema specifies the entities that are represented in the database,the attributes of the entities, the relationships between the entities, and constraints on theentities and relationships. Typically, the conceptual-design phase results in the creation ofan entity-relationship diagram that provides a graphic representation of the schema.

The designer reviews the schema to confirm that all data requirements are indeed satisfiedand are not in conflict with one another. She can also examine the design to remove anyredundant features. Her focus at this point is describing the data and their relationships,rather than on specifying physical storage details.

A fully developed conceptual schema also indicates the functional requirements of theenterprise. In a specification of functional requirements, users describe the kinds ofoperations (or transactions) that will be performed on the data. Example operations includemodifying or updating data, searching for and retrieving specific data, and deleting data. At

this stage of conceptual design, the designer can review the schema to ensure it meetsfunctional requirement.

The Process of moving from an abstract data model to the implementation of the databaseproceeds in two final design phases.

Logical Design

The designer maps the high level conceptual schema onto the implementation data model of

the database system that will be used. The implementation data model is typically therelational data model, and this step typically consists of mapping the conceptual schemadefined using the entity-relationship model into a relation schema.

Physical DesignFinally, the designer uses the resulting system specific database schema in the subsequentphysical-design phase, in which the physical features of the database are specified. Thesefeatures include the form of file organization and the internal storage structures.

The physical schema of a database can be changed relatively easily after an application hasbeen built. However, changes to the logical schema are usually harder to carry out, sincethey may affect a number of queries and updates scattered across application code. It istherefore important to carry out the database design phase with care, before building therest of the database application.

2. The Entity-Relationship (E-R) Model

The entity-relationship (E-R) data model was developed to facilitate database design by

allowing specification of an enterprise schema that represents the overall logical structure ofa database. The E-R model is very useful in mapping the meanings and interactions of real-world enterprises onto a conceptual schema.

The E-R data model employs three basic concepts:1.

Entity Sets,2. Relationship Sets, and3. Attributes

E-R model also has an associated diagrammatic representation, the E-R diagram, which westudy later in this chapter.


4/23

Figure 2-1: Two entities employee e1 and company c1

2.a Entity and Their Attributes

Entity

The basic object that the ER model represents is an entity, which is a "thing" or "object" in

the real world with an independent existence and that is distinguishable from all otherobjects.

An entity may be an object with a physical existence—a particular person, car, house, or

employee—or it may be an object with a conceptual existence—a company, a job, or auniversity course.

Figure 2-1 shows two entities and the values of their attributes. The employee entity e1 has

four attributes: Name, Address, Age, and Home_Phone; their values are "John Smith,""2311 Kirby, Houston, Texas 77001," "55," and "713-749-2630," respectively. The companyentity c1 has three attributes: Name, Headquarters, and President; their values are "SuncoOil," "Houston," and "John Smith," respectively.

Attributes

Each entity has attributes—the particular properties that describe it. An entity isrepresented by a set of attributes. Attributes are descriptive properties possessed by eachmember of an entity set. The attribute for an entity expresses that the database stores

similar information for each entity; however, each entity may have its own value for eachattribute.

For example, an employee entity may be described by the employee’s name, age, address,

salary , and job. Possible attributes of the instructor entity are ID, name, dept_name, andsalary . In real life, there would be further attributes, such as street number, apartmentnumber, state, postal code, and country, but we omit them to keep our examples simple.

Attribute Value

Each entity has a value for each of its attributes. The attribute values that describe each

entity become a major part of the data stored in the database.For instance, a particular instructor entity may have the value 12121 for ID, the value Wu

for name, the value Finance for dept_name, and the value 90000 for salary .

Attribute Types

Several types of attributes occur in the ER model:Simple versus Composite;Single-valued versus Multivalued; and

Stored versus Derived.


5/23

Figure 2-2: composite attributes name and address

Simple (Atomic) versus Composite Attributes

Attributes that are not divisible are called simple or atomic attributes. In our examplesthus far, the attributes have been simple. For example, ID attribute of instructor entity.

Composite attributes, on the other hand, can be divided into subparts (that is, otherattributes. For example, an attribute name could be structured as a composite attributeconsisting of first_name, middle_initial , and last_name.

Using composite attributes in a design schema is a good choice if a user will wish to refer toan entire attribute on some occasions and to only a component of the attribute on otheroccasions.

Suppose student entity has address attribute, then it can be defined as composite attributewith the attributes street , city , state and zip_code. Composite attributes help us to grouptogether related attributes, making the modeling cleaner.

Note also that a composite attribute may appear as a hierarchy. In the composite attributeaddress its component attribute street can be further divided into street_number ,street_name, and apartment_number . Figure 2-2 depicts these examples of compositeattributes.

Single-valued Versus Multivalued Attributes

Most attributes have a single value for a particular entity; such attributes are called single-valued. For example, Age is a single-valued attribute of person. The ID attribute of student refers to only one student.

In some cases an attribute can have a set of values for the same entity. For example, phone_number attribute of instructor . An instructor may have zero, one, or several phonenumbers, and different instructors may have different numbers of phones. This type of

attribute is said to be multivalued.

As another example, an attribute dependent_name of the instructor would be multivalued,since any particular instructor may have zero, one, or more dependents.

To denote that an attribute is multivalued, we enclose it in braces, for example

{ phone_number } or {dependent_name }.Where appropriate, upper and lower bounds may be placed on the number of values in a

multivalued attribute. For example, a university may limit the number of phone numbersrecorded for a single instructor to two. Placing bounds in this case expresses that the

phone_number attribute of the instructor entity may have between zero and two values.

Stored versus Derived Attributes

In some cases two (or more) attribute values are related—for example, the Age andBirthDate attributes of a person. For a particular person entity, the value of Age can bedetermined from the current (today’s) date and the value of that person’s BirthDate. The

Age attribute is hence called a derived attribute and is said to be derivable from the

BirthDate attribute, which is called a stored attribute. The value of a derived attribute is

not stored but is computed when required.Some attribute values can be derived from related entities; for example, an attribute


6/23


7/23


8/23

Figure 2-3: Relationship Set advisor

Note: Whenever an attribute of one entity type refers to another entity type, some

relationship exists.

Relationship Type and Relationship Set

Figure 2-4: works_for relationship set

A relationship type R among n entity types defines a set of associations—or a relationship

set—among entities from these types. As for entity types and entity sets, a relationship typeand its corresponding relationship set are customarily referred to by the same name R.

A relationship set is a set of relationships of the same type. Consider the two entity sets

instructor and student . We define the relationship set advisor to denote the associationbetween instructors and students. Figure 2-3 depicts this association.

As another example, consider the two entity sets student and section. We can define the

relationship set takes to denote the association between a student and the course sectionsin which that student is enrolled.

As another example, consider a relationship type works_for between the two entity types

employee and department , which associates each employee with the department theemployee works for. Each relationship instance in the relationship set WORKS_FORassociates one employee entity and one department entity. Figure 2-4 illustrates this

example, where each relationship instance is shown connected to the employee anddepartment entities that participate in. In the miniworld represented by Figure 2-4,


9/23


10/23

Figure 2-5: Relationship set advisor

Figure 2-6: Ternary relationship set supply

Degree of a Relationship Type

The degree of a relationship type is the number of participating entity types. Hence, the

WORKS_FOR relationship is of degree two. A relationship type of degree two is calledbinary, and one of degree three is called ternary. An example of a ternary relationship isSUPPLY, shown in Figure 2-6, where each relationship instance associates three entities—asupplier s, a part p, and a project j—whenever s supplies part p to project j. Relationshipscan generally be of any degree, but the ones most common are binary relationships.Higher-degree relationships are generally more complex than binary relationships.

3. Mapping/Structural Constraints

An E-R enterprise schema may define certain constraints to which the contents of a

database must conform.

Relationship types usually have certain constraints that limit the possible combinations ofentities that may participate in the corresponding relationship set. These constraints are

determined from the miniworld situation that the relationships represent. For example, inFigure 03.09, if the company has a rule that each employee must work for exactly onedepartment, then we would like to describe this constraint in the schema. We candistinguish two main types of relationship constraints:

1.

Cardinality Ratio (Mapping Cardinalities) and2.

Participation Constraints.


11/23

3.a Cardinality Ratios for Binary Relationships

Mapping Cardinalities or cardinality ratios, express the number of entities to which anotherentity can be associated via a relationship set. Mapping cardinalities are most useful in

describing binary relationship sets, although they can contribute to the description ofrelationship sets that involve more than two entity sets.

For a binary relationship set R between entity sets A and B, the mapping cardinality must be

one of the following:

1. One-to-one (1:1)2. One-to-many (1:N)

3. Many-to-one (N:1))4. Many-to-many (M:N)

One-to-one: An entity in A is associated with at most one entity in B, and an entity in B isassociated with at most one entity in A.

One-to-one (1:1) One-to-Many (1:N)

Figure 2-7: Cardinality Ratio One-one and One-to-Many

Note: Some elements in A and B may not be mapped to any elements in the other set

One-to-many: An entity in A is associated with any number (zero or more) of entities in B.

An entity in B, however, can be associated with at most one entity in A.

Many-to-one: An entity in A is associated with at most one entity in B. An entity in B,however, can be associated with any number (zero or more) of entities in A.

Many-to-many: An entity in A is associated with any number (zero or more) of entities inB, and an entity in B is associated with any number (zero or more) of entities in A.

Many-to-one (N:1) Many-to-many (M:N)

Figure 2-8: Cardinality Ratio One-one and One-to-Many


12/23

The appropriate mapping cardinality for a particular relationship set obviously depends onthe real-world situation that the relationship set is modeling. For example, consider theadvisor relationship set. If, in a particular university, a student can be advised by only oneinstructor and an instructor can advise several students, then the relationship set from

instructor to student is one-to-many. If a student can be advised by several instructors (as

in case of students advised jointly), the relationship set is many-to-many.

3.b Participation constraints

The participation constraint specifies whether the existence of an entity depends on itsbeing related to another entity via the relationship type. There are two types of participationconstraints—

1. Total Participation and2. Partial Participation

Total Participation

The participation of an entity set E in a relationship set R is said to be total if every entity inE participates in at least one relationship in R.

Partial Participation

If only some entities in E participate in relationships in R, the participation of entity set E inrelationship R is said to be partial.

For example, we expect every student entity to be related to at least one instructor throughthe advisor relationship. Therefore the participation of student in the relationship set advisor is total.

In contrast, an instructor need not advise any student. Hence, it is possible that only someof the instructor entities are related to the student entity set through the advisor relationship, and the participation of instructor in the advisor relationship set is thereforepartial.

4. E-R Diagram

E-R diagram can express the overall logical structure of a database graphically. E-Rdiagrams are simple and clear-qualities that may well account in large part for the

widespread use of the E-R model.

4.a Basic structure

Such a diagram consists of the following major components:

Rectangles divided into two parts: Represent entity sets. The first part contains thename of the entity set. The second part contains the names of all the attributes of the entityset. Attributes that are part of the primary key are underlined.

Figure 2-9: Entity set instructor

Diamonds: Represent relationship set


13/23

Figure 2-10: Relationship set advisor

Undivided rectangles: Represent the attributes of a relationship set. Attributes that arepart of the primary key are underlined.

Figure 2-10: attributes of a relationship set

Lines: Link entity sets to relationship sets.

Dashed lines: Link attributes of a relationship set to the relationship set. (Figure 2-10)

Double lines: Indicate total participation of entity in a relationship set.

Figure 2-11: weak entity set and total participation

Double diamonds: Represents identifying relationship sets linked to weak entity sets.

4.b Mapping Cardinality

The relationship set advisor , between the instructor and student entity sets may be one-to-one, one-to-many, many-to-one, or many-to-many. To distinguish among these types, wedraw either a directed line (→) or an undirected line (-) between the relationship set and

the entity set in question.

One-to-one:

We draw a directed line from the relationship set advisor to both entity sets instructor and

student. This indicates that an instructor may advise at most one student, and a studentmay have at most one advisor.

Figure 2-12: one-to-one

One-to-many:

We draw a directed line from the relationship set advisor to the entity set instructor andundirected line to the entity set student . This indicates that an instructor may advise many


14/23

students, and a student may have at most one advisor.

Figure 2-13: one-to-many

Many-to-one:

We draw a undirected line from the relationship set advisor to the entity set instructor and adirected line to the entity set student. This indicates that an instructor may advise at most

one student, but a student may have many advisors.

Many-to-many:

We draw a undirected line from the relationship set advisor to both entity sets instructorand student. This indicates that an instructor may many students, and a student may have

many advisors.

Figure 2-14: many-to-many

4.c Complex constraints

E-R diagrams also provide a way to indicate more complex constraints on the number of

times each entity participates in relationships in a relationship set. An line may have anassociated minimum and maximum cardinality, shown in the form l..h, where l is the

minimum and, h the maximum cardinality.

Figure 2-15: Complex constraint

A minimum value of 1 indicates total participation of the entity set in the relationship set;that is, each entity in the entity set occurs in at least one relationship in that relationship

set. A maximum value of 1 indicates that the entity participates in at most one relationship,while a maximum value * indicates no limit.

The line between advisor and student has a cardinality constraint of 1..1, meaning the

minimum and the maximum cardinality are both 1. That is, each student must have exactlyone advisor.

If both edges have maximum value of 1, the relationship is one-to-one. If we had specified

a cardinality limit of 1..* on the left edge, we would be saying that each instructor mustadvise at least one student. Alternative – double line from student to advisor and directedline from advisor to instructor.

4.d Complex Attributes


15/23

Figure 2-15: Roles

Figure 2-15 shows how composite attributes can be represented in the E-R notation. Here, a

composite attribute name, with component attributes first_name, middle_name, last_name replaces the simple attribute name of instructor .

Figure also shows multivalued attribute phone_number , denoted by ―{ phone_number }‖.

A derived attribute age is shown as age().

4.e Roles

We indicate roles in E-R diagrams by labeling the lines that connect diamonds to rectangles.

Figure 2-16: Roles

5. Weak Entity Set

An entity set may not have sufficient attributes to form a primary key. Such an entity set istermed a weak entity set. An entity set that has a primary key is termed a strong entityset.

Consider the entity set payment , which has the three attributes: payment_number , payment_date, and payment_amout

Payment numbers are typically sequential numbers, starting from 1, generated separatelyfor each loan. Thus although each payment entity is distinct, payments for different loansmay share the same payment number. Thus, this entity set does not have a primary key; itis a weak entity set.

For a weak entity set to be meaningful, it must be associated with another entity set, calledthe identifying or owner entity set. Every weak entity must be associated with an

identifying entity; that is, the weak entity set is said to be existence dependent on theidentifying entity set. The identifying entity set is said to own the weak entity set that it

identifies.The relationship associating the weak entity set with the identifying entity set is called theidentifying relationship. The identifying relationship is many-to-one from the weak entity


16/23

set to the identifying entity set, and the participation of the weak entity set in therelationship is total.

In our example, the identifying entity set for payment is loan, and a relationshiploan_payment that associates payment entities with their corresponding loan entities is theidentifying relationship. Although a weak entity set does not have a primary key, we

nevertheless need a means of distinguishing among all those entities in the weak entity set

that depend on one particular strong entity.

The discriminator of a weak entity set is a set of attributes that allows this distinction to

be made. For example, the discriminator of the weak entity set payment is the attribute payment_number , since, for each loan, a payment number uniquely identifies one singlepayment for that loan. The discriminator of a weak entity set is also called the partial key of the entity set.

The primary key of a weak entity set is formed by the primary key of the identifying entityset, plus the weak entity set's discriminator. In the case of the entity set payment, its

primary key is {loan_number , payment_number }, where loan_number is the primary key ofthe identifying entity set, namely loan and payment_number distinguishes payment entitieswithin the same loan.

The identifying relationship set should have no descriptive attributes, since any required

attributes can be associated with the weak entity set. A weak entity set can participate inrelationships other than the identifying relationship. For instance, the payment entity couldparticipate in a relationship with the account entity set, identifying the account from which

the payment was made.

A weak entity set may participate as owner in an identifying relationship with another weakentity set. It is also possible to have a weak entity set with more than one identifying entity

set. A particular weak entity would then be identified by a combination of entities, one fromeach identifying entity set

The primary key of the weak entity set would consist of the union of the primary keys of the

identifying entity sets, plus the discriminator of the weak entity set. In E-R diagrams, aweak entity set is depicted via a rectangle, like a strong entity set, but there are two maindifferences:

1.

The discriminator (partial key) of a weak entity is underlined with a dashed, ratherthan a solid line.

2. The relationship set connecting the weak entity set to the identifying strong entityset is depicted by a double diamond.

Figure 2-17: weak entity set payment

In some cases, the database designer may choose to express a weak entity set as a

multivalued composite attribute of the owner entity set. In our example, this alternativewould require, that the entity set loan have a multivalued, composite attribute payment,consisting of payment_number , payment_date, and payment_amount .

A weak entity set may be more appropriately modeled as an attribute if it participates inonly the identifying relationship, and if it has few attributes. Conversely, a weak entity setrepresentation will more aptly model a situation where the set participates in relationshipsother than the identifying relationship, and where the weak entity set has several attributes.

7. Extended E-R Features

Although the basic E-R concepts can model most database features, some aspects of adatabase may be more aptly expressed by certain extensions to the basic E-R model.

The ER modeling concepts discussed so far are sufficient for representing many database


17/23

schemas for "traditional" database applications, which mainly include data-processingapplications in business and industry. Since the late 1970s, however, newer applications of

database technology have become commonplace; these include databases for engineeringdesign and manufacturing (CAD/CAM), telecommunications, images and graphics,multimedia, data mining, data warehousing, geographic information systems (GIS), anddatabases for indexing the World Wide Web, among many other applications. These types of

databases have more complex requirements than do the more traditional applications. Torepresent these requirements as accurately and clearly as possible, designers of databaseapplications must use additional semantic data modeling concepts. Various semantic data

models have been proposed in the literature.

The ER model can be enhanced to include these concepts, leading to the enhanced-ER orEER model.

In this section, we discuss the extended E-R features ofSpecialization,Generalization,

Higher- and Lower-level Entity SetsAttribute Inheritance, andAggregation

7.a Specialization

An entity set may include sub groupings of entities that are distinct in some way from otherentities in the set. For instance, a subset of entities within an entity set may have attributesthat are not shared by all the entities in the entity set. The E-R model provides a means forrepresenting these distinctive entity groupings.

As an example, consider an entity set person may be further classified as one of thefollowing: employee, student .

Each of these person types is described by a set of attributes that includes all the attributesof entity set person plus possibly additional attributes.

For example, employee entities may be described further by the attribute salary , whereas

student entities may be described further by the attribute tot_cred . The process of

designating sub groupings within an entity set is called specialization. The specialization ofperson allows us to distinguish among person entities according to whether they correspondto employees or students.

In general, a person could be an employee, a student, both, or neither. As anotherexample, suppose the university divides students into two categories: graduate andundergraduate. Graduate students have an office assigned to them. Undergraduate students

are assigned to a residential college.

Each of these student types is described by a set of attributes that includes all the attributesof the entity set student plus additional attributes. The university could create two

specializations of student , namely graduate and undergraduate. Student entities aredescribed by the attributes ID, name, address and tot_cred .

The entity set graduate would have all the attributes of student and an additional attribute

office_number . The entity set undergraduate would have all the attributes of student , andan additional attribute residential_college. We can apply specialization repeatedly to refine adesign.

For instance, university employees may be further classified as one of the following:instructor , secretary . Each of these employee types is described by a set of attributes thatincludes all the attributes of entity set employee plus additional attributes. For example,instructor entities may be described further by the attribute rank while secretary entities aredescribed by the attribute hours_per_week .

Further, secretary entities may participate in a relationship secretary_for between thesecretary and employee entity sets, which identifies the employees who are assisted by asecretary. An entity set may be specialized by more than one distinguishing feature. In ourexample, the distinguishing feature among employee entities is the job the employee

performs.Another, coexistent, specialization could be based on whether the person is a temporary


18/23

(limited-term) employee or a permanent employee, resulting in the entity setstemporary_employee and permanent_employee. When more than one specialization is

formed on an entity set, a particular entity may belong to multiple specializations. Forinstance, a given employee may be a temporary employee who is a secretary.

In terms of an E-R diagram, specialization is depicted by a hollow arrow-head pointing from

the specialized entity to the other entity. We refer to this relationship as the ISA

relationship, which stands for ―is a‖ and represents, for example, that an instructor ―is a‖employee.

Figure 2-18: specialization example

The way we depict specialization in an E-R diagram depends on whether an entity may

belong to multiple specialized entity sets or if it must belong to at most one specializedentity set. The former case (multiple sets permitted) is called overlapping specialization,while the latter case (at most one permitted) is called disjoint specialization.

For an overlapping specialization (as is the case for student and employee as specializationsof person), two separate arrows are used. For a disjoint specialization (as is the case forinstructor and secretary as specializations of employee), a single arrow is used.

The specialization relationship may also be referred to as a superclass-subclass relationship.Higher- and lower-level entity sets are depicted as regular entity sets – that is, asrectangles containing the name of entity set.

7.b Generalization

The refinement from an initial entity set into successive levels of entity sub groupings

represents a top-down design process in which distinctions are made explicit. The designprocess may also proceed in a bottom-up manner, in which multiple entity sets aresynthesized into a higher level entity set on the basis of common features.

The database designer may have first identified instructor entity set with attributesinstructor_id , instructor_name, instructor_salary , and rank secretary entity set attributes secretary_id , secretary_name, secretary_salary , and

hours_per_week . There are similarities between the instructor entity set and the secretary entity set in the sense that they have several attributes that are conceptually the sameacross the two entity sets: namely, the identifier, name, and salary attributes.

This commonality can be expressed by generalization, which is a containment relationshipthat exists between a higher-level entity set and one or more lower-level entity sets. In ourexample, employee is the higher-level entity set and instructor and secretary are lower-level entity sets.

In this case, attributes that are conceptually the same had different names in the two lower-level entity sets. To create a generalization, the attributes must be given a common nameand represented with the higher-level entity person. We can use the attribute names ID,name, address.

Higher- and lower-level entity sets also may be designated by the terms superclass andsubclass, respectively. The person entity set is the superclass of the employee and student


19/23

subclasses. For all practical purposes, generalization is a simple inversion of specialization.

Specialization stems from a single entity set; it emphasizes differences among entitieswithin the set by creating distinct lower-level entity sets. These lower-level entity sets mayhave attributes, or may participate in relationships, that do not apply to all the entities inthe higher-level entity set. Indeed, the reason a designer applies specialization is to

represent such distinctive features.

If student and employee have exactly the same attributes as person entities, and participatein exactly the same relationships as person entities, there would be no need to specialize

the person entity set. Generalization proceeds from the recognition that a number of entitysets share some common features (namely, they are described by the same attributes andparticipate in the same relationship sets).

On the basis of their commonalities, generalization synthesizes these entity sets into asingle, higher-level entity set. Generalization is used to emphasize the similarities amonglower-level entity sets and to, hide the differences; it also permits an economy of

representation in that shared attributes are not repeated.

7.c Attribute inheritance

A crucial property of the higher- and lower-level entities created by specialization and

generalization is attribute inheritance. The attributes of the higher-level entity sets are saidto be inherited by the lower-level entity sets. For example, student and employee inherit

the attributes of person.

Thus, student is described by its ID, name, and address attributes, and additionally atot_cred attribute; employee is described by its ID, name, and address attributes, and

additionally a salary attribute. A lower-level entity set (or subclass) also inheritsparticipation in the relationship sets in which its higher-level entity (or superclass)participates.

Attribute inheritance applies through all tiers of lower-level entity sets. For example,suppose the person entity set participates in a relationship person_dept with department .Then, the student , employee, instructor and secretary entity sets, which are subclasses of

the person entity set, also implicitly participate in the person_dept relationship with

department . The above entity sets can participate in any relationships in which the person entity set participates.

Whether a given portion of an E-R model was arrived at by specialization or generalization,the outcome is basically the same:

A higher-level entity set with attributes and relationships that apply to all of itslower-level entity sets

Lower-level entity sets with distinctive features that apply only within a particularlower-level entity set

In what follows, although we often refer to only generalization, the properties that we

discuss belong fully to both processes.

Figure 2-18 depicts a hierarchy of entity sets. In the figure, employee is a lower-level entityset of person and a higher-level entity set of the instructor and secretary entity sets. In a

hierarchy, a given entity set may be involved as a lower-level entity set in only one ISArelationship; that is, entity sets in this diagram have only single inheritance.

If an entity set is a lower-level entity set in more than one ISA relationship, then the entity

set has multiple inheritance, and the resulting structure is said to be a lattice.

7.d Constraints on Generalizations

To model an enterprise more accurately, the database designer may choose to place certainconstraints on a particular generalization.

1) Which entities can be members of a given lower-level entity seta. Conditioned-definedb.

User-defined

2) Whether or not entities may belong to more than one lower-level entity set within a

single generalizationa. Disjoint


20/23

b.

Overlapping3) Whether or not an entity in the higher-level entity set must belong to at least one of

the lower-level entity sets within the generalization / specializationa. Total generalization / specializationb. Partial generalization / specialization

One type of constraint involves determining which entities can be members of a givenlower-level entity set. Such membership may be one of the following:

Conditioned-definedUser-defined

Conditioned-defined

In condition-defined lower-level entity sets, membership is evaluated on the basis of

whether or not an entity satisfies an explicit condition or predicate. For example, assumethat the higher-level entity set student has the attribute student_type. All student entitiesare evaluated on the defining student_type attribute. Only those entities that satisfy thecondition student_type = ―graduate" are allowed to belong to the lower-level entity set

graduate_student .

All entities that satisfy the condition student_type = ―undergraduate" are included inundergraduate_student . Since all the lower-level entities are evaluated on the basis of the

same attribute (in this case, on student_type), this type of generalization is said to beattribute-defined.

User-defined

User-defined lower-level entity sets are not constrained by a membership condition; rather,

the database user assigns entities to a given entity set. For instance, let us assume that,after 3 months of employment, university employees are assigned to one of four workteams. We therefore represent the teams as four lower-level entity sets of the higher-levelemployee entity set.

A given employee is not assigned to a specific team entity automatically on the basis of an

explicit defining condition. Instead, the user in charge of this decision makes the teamassignment on an individual basis. The assignment is implemented by an operation thatadds an entity to an entity set.

A second type of constraint relates to whether or not entities may belong to more than onelower-level entity set within a single generalization. The lower-level entity sets may be oneof the following:

DisjointOverlapping

Disjoint

A disjointness constraint requires that an entity belong to no more than one lower-level

entity set. In our example, an student entity can satisfy only one condition for thestudent_type attribute; an entity can be either a graduate student or an undergraduate student, but cannot be both.

Overlapping

In overlapping generalizations, the same entity may belong to more than one lower-levelentity set within a single generalization. For an illustration, consider the employee work-

team example, and assume that certain employees participate in more than one work team.A given employee may therefore appear in more than one of the team entity sets that arelower-level entity sets of employee. Thus, the generalization is overlapping.

In figure 2-18 we assume a person may be both an employee and a student . We show this

overlapping generalization via separate arrows; one from employee to person and anotherfrom student to person. However, the generalization of instructor and secretaries is disjoint.


21/23

We show this using a single arrow.

A final constraint, the completeness constraint on a generalization or specialization,specifies whether or not an entity in the higher-level entity set must belong to at least one

of the lower-level entity sets within the generalization / specialization. This constraint maybe one of the following:

Total generalization or specialization: Each higher-level entity must belong to alower-Ievel entity set

Partial generalization or specialization: Some higher-level entities may notbelong to any lower-level entity set

Partial generalization is the default. We can specify total generalization in an E-R diagramby using adding the keyword ―total‖ in the diagram and drawing a dashed line from thekeyword to the corresponding hollow arrow-head to which it applies (for a total

generalization), or to the set of hollow arrow-heads to which it applies (for an overlappinggeneralization).

The student generalization is total: All student entities must be either graduate or

undergraduate. Because the higher-level entity set arrived at through generalization is

generally composed of only those entities in the lower-level entity sets, the completenessconstraint for a generalized higher-level entity set is usually total.

When the generalization is partial, a higher-level entity is not constrained to appear in alower-level entity set. The work team entity sets illustrate a partial specialization. Sinceemployees are assigned to a team only after 3 months on the job, some employee entities

may not be members of any of the lower-level team entity sets.

We may characterize the team entity sets more fully as a partial, overlapping specializationof employee. The generalization of graduate_student and undergraduate_student into

student is a total, disjoint generalization. The completeness and disjointness constraints,however, do not depend on each other.

Constraint patterns may also be partial-disjoint and total-overlapping. We can see that

certain insertion and deletion requirements follow from the constraints that apply to a given

generalization or specialization. For instance, when a total completeness constraint is inplace, an entity inserted into a higher-level entity set must also be inserted into at least oneof the lower-level entity sets.

With a condition-defined constraint, all higher-level entities that satisfy the condition mustbe inserted into that lower-level entity set. Finally, an entity that is deleted from a higher-level entity set also is deleted from all the associated lower-level entity sets to which it

belong.

7.e Aggregation

One limitation of the E-R model is that it cannot express relationships among relationships.

Aggregation is an abstraction concept for building composite objects from their component

objects. There are three cases where this concept can be related to the EER model.

1.

The first case is the situation where we aggregate attribute values of an object toform the whole object.

2. The second case is when we represent an aggregation relationship as an ordinaryrelationship.

3. The third case, which the EER model does not provide for explicitly, involves thepossibility of combining objects that are related by a particular relationship instance

into a higher-level aggregate object. This is sometimes useful when the higher-levelaggregate object is itself to be related to another object. We call the relationshipbetween the primitive objects and their aggregate object IS-A-PART-OF; the inverseis called IS-A-COMPONENT-OF.

In order to understand the different uses of aggregation better, consider the ER schemashown in Figure 2-19(a), which stores information about interviews by job applicants to

various companies. The class COMPANY is an aggregation of the attributes (or componentobjects) CName (company name) and CAddress (company address), whereas


22/23

JOB_APPLICANT is an aggregate of Ssn, Name, Address, and Phone. The relationshipattributes ContactName and ContactPhone represent the name and phone number of the

person in the company who is responsible for the interview. Suppose that some interviewsresult in job offers, while others do not. We would like to treat INTERVIEW as a class toassociate it with JOB_OFFER. The schema shown in Figure 2-19(b) is incorrect because itrequires each interview relationship instance to have a job offer. The schema shown in

Figure 2-19(c) is not allowed, because the ER model does not allow relationships amongrelationships (although UML does).

Figure 2-19: Aggregation Example

One way to represent this situation is to create a higher-level aggregate entity composed ofCOMPANY, JOB_APPLICANT, and INTERVIEW and to relate this entity to JOB_OFFER, as

shown in Figure 2-19(d).

6. Design Issues

Will be updated soon…


23/23

Ch2 ER Model

Documents

Transcript of Ch2 ER Model