Resources:

3-Data Modeling Using the Entity-Relationship (ER) Model

=>In this chapter, we follow the traditional approach of concentrating on the database structures and constraints
during conceptual database design.

The design of application programs is typically covered in software engineering courses.

We present the modeling concepts of the Entity-Relationship (ER) model, which is a popular high-level
conceptual data model.
This model and its variations are frequently used for the conceptual design of database applications, and
many database design tools employ its concepts.

We describe the basic data-structuring concepts and constraints of the ER model and discuss their use in the
design of conceptual schemas for database applications.
We also present the diagrammatic notation associated with the ER model, known as ER diagrams

=>Object modeling methodologies such as the Unified Modeling Language (UML) are becoming increasingly
popular in both database and software design.
These methodologies go beyond database design to specify detailed design of software modules and their
interactions using various types of diagrams.

An important part of these methodologies—namely, class diagrams—are similar in many ways to the ER
diagrams.
In class diagrams, operations on objects are specified, in addition to specifying the database schema
structure.
Operations can be used to specify the functional requirements during database design.

3.1 Using High-Level Conceptual Data Models for Database Design

Figure 7.1 shows a simplified overview of the database design process. The first step shown is requirements
collection and analysis. During this step, the database designers interview prospective database users to
understand and document their data requirements. The result of this step is a concisely written set of users’
requirements.
These requirements should be specified in as detailed and complete a form as possible. In parallel with
specifying the data requirements, it is useful to specify the known functional requirements of the application.
These consist of the user defined operations (or transactions) that will be applied to the database, including
both retrievals and updates.
In software design, it is common to use data flow diagrams, sequence diagrams, scenarios, and other
techniques to specify functional requirements.
3.2 A Sample Database Application
In this section we describe a sample database application, called COMPANY.

■ The company is organized into departments. Each department has a unique name, a unique number, and a
particular employee who manages the department. We keep track of the start date when that employee began
managing the department. A department may have several locations.

■ A department controls a number of projects, each of which has a unique name, a unique number, and a single
location.

■ We store each employee’s name, Social Security number,2 address, salary, sex (gender), and birth date. An
employee is assigned to one department, but may work on several projects, which are not necessarily controlled
by the same department. We keep track of the current number of hours per week that an employee works on
each project. We also keep track of the direct supervisor of each employee (who is another employee).

■ We want to keep track of the dependents of each employee for insurance purposes. We keep each
dependent’s first name, sex, birth date, and relationship to the employee.

3.3.1 Entities and Attributes Entities and Their Attributes.

The basic object that the ER model represents is an entity, which is a thing in the real world with an
independent existence.
An entity may be an object with a physical existence (for example, a particular person, car, house, or
employee) or it may be an object with a conceptual existence
(for instance, a company, a job, or a university course).

Each entity has attributes—the particular properties that describe it.

For example, an EMPLOYEE entity may be described by the employee’s name, age, address, salary, and job.

### Several types of attributes occur in the ER model: simple versus composite, single valued versus
multivalued, and stored versus derived.
The concept of a NULL value for an attribute.
NULL Values. In some cases, a particular entity may not have an applicable value for an attribute.
Complex attributes For example, if a person can have more than one residence and each residence can
have a single address and multiple phones, an attribute Address_phone for a person can be specified as shown
in Figure 7.5.4 Both Phone and Address are themselves composite attributes.

{Address_phone( {Phone(Area_code,Phone_number)},Address(Street_address
(Number,Street,Apartment_number),City,State,Zip) )} A complex attribute: Address_phone.
3.3.3 Initial Conceptual Design of the COMPANY Database
1. 1. An entity type DEPARTMENT with attributes Name, Number, Locations, Manager, and
Manager_start_date. Location is the only multivalued attribute. We can specify that both Name and
Number are (separate) key attributes because each was specified to be unique.

2. An entity type PROJECT with attributes Name, Number, Location, and Controlling_department. Both
Name and Number are (separate) key attributes.

3. An entity type EMPLOYEE with attributes Name, Ssn, Sex, Address, Salary, Birth_date, Department, and
Supervisor. Both Name and Address may be composite attributes; however, this was not specified in the
requirements. We must go back to the users to see if any of them will refer to the individual components of
Name—First_name, Middle_initial, Last_name—or of Address.

4. An entity type DEPENDENT with attributes Employee, Dependent_name, Sex, Birth_date, and
Relationship (to the employee).
3.4 Relationship Types, Relationship Sets, Roles, and Structural Constraints

There are several implicit relationships among the various entity types.
In fact, whenever an attribute of one entity type refers to another entity type, some relationship exists.
For example, the attribute Manager of DEPARTMENT refers to an employee who manages the department; the
attribute Controlling_department of PROJECT refers to the department that controls the project; the attribute

Supervisor of EMPLOYEE refers to another employee (the one who supervises this employee); the attribute
Department of EMPLOYEE refers to the department for which the employee works; and so on. In the ER model,
these references should not be represented as attributes but as relationships.
4.The Enhanced Entity-Relationship (EER) Model
Since the late 1970s, however, designers of database applications have tried to design more accurate
database schemas that reflect the data properties and constraints more precisely.

This was particularly important for newer applications of database technology, such as databases for
engineering design and manufacturing (CAD/CAM),telecommunications, complex software systems, and
Geographic Information Systems (GIS), among many other applications.

These types of databases have more complex requirements than do the more traditional applications. This led to
the development of additional semantic data modeling concepts that were incorporated into conceptual data
models such as the ER model.

In this chapter, we describe features that have been proposed for semantic data models, and show how the ER
model can be enhanced to include these concepts, leading to the Enhanced ER (EER).

We start by incorporating the concepts of class/subclass relationships and type inheritance into the ER model.
Then,We add the concepts of specialization and generalization.

4.1 Subclasses, Superclasses, and Inheritance

Specialization
Generalization
4.3 Constraints and Characteristics of Specialization and Generalization Hierarchies
If all subclasses in a specialization have their membership condition on the same attribute of the superclass,
the specialization itself is called an attribute-defined specialization, and the attribute is called the defining
attribute of the specialization.

We display an attribute-defined specialization by placing the defining attribute name next to the arc from the
circle to the superclass, as shown in Figure 8.4
Two other constraints may apply to a specialization. The first is the disjointness (or disjointedness) constraint,
which specifies that the subclasses of the specialization must be disjoint.

Disjoint Constraint:(d) This means that an entity can belong to only one subtype. In other words, if an entity
instance is classified under one subtype, it cannot be classified under any other subtype. It ensures that
subtypes do not overlap.
Consider a scenario where we have an entity called "Vehicle," which has subtypes "Car" and "Truck." Disjoint
Constraint
Example: If we enforce a disjoint constraint, it means that a vehicle instance can only be classified as either a
car or a truck, but not both. For instance, a vehicle cannot be both a car and a truck simultaneously.
Overlap Constraint: (o) This allows an entity to belong to more than one subtype simultaneously. In this case,
subtypes can overlap, meaning an entity instance can be classified under multiple subtypes.

Overlap Constraint Example: If we allow overlap, then a vehicle instance could potentially be classified as both a
car and a truck. For example, a vehicle might be classified as both a car and a truck if it possesses
characteristics of both types.
=>The second constraint on specialization is called the 1.completeness (or totalness) constraint, which may be
total or partial.
A total specialization constraint specifies that every entity in the superclass must be a member of at least one
subclass in the specialization.
For example, if every EMPLOYEE must be either an HOURLY_EMPLOYEE or a SALARIED_EMPLOYEE, then
the specialization {HOURLY_EMPLOYEE, SALARIED_EMPLOYEE} in Figure 8.1 is a total specialization of
EMPLOYEE. This is shown in EER diagrams by using a double line to connect the superclass to the circle.

=>A single line is used to display a 2.partial specialization, which allows an entity not to belong to any of the
subclasses. For example, if some EMPLOYEE entities do not belong to any of the subclasses {SECRETARY,
ENGINEER, TECHNICIAN} in Figures 8.1 and 8.4, then that specialization is partial.

Notice that the disjointness and completeness constraints are independent. Hence, we have the following four
possible constraints on specialization:
■ Disjoint, total
■ Disjoint, partial
■ Overlapping, total
■ Overlapping, partial

Disjoint, Total: This constraint requires that every entity instance in the superclass must belong to exactly one
of the subclasses. There can be no overlapping, and every instance must be classified. This is a strict constraint
where there is no room for undefined cases. It ensures that each entity belongs exclusively to one subtype.
Disjoint, Partial: With this constraint, every entity instance in the superclass must belong to at least one of the
subclasses, but it may belong to more than one. There is still no overlapping allowed, but some instances might
not fit into any of the defined subclasses. This constraint allows for some flexibility in classification.

Overlapping, Total: In this case, every entity instance must belong to at least one subclass, and it can belong to
more than one subclass. Overlapping is allowed, meaning some instances may fit into multiple subclasses.
There are no undefined cases; every entity must be classified.

Overlapping, Partial: This constraint allows for the most flexibility. Entities can belong to more than one
subclass, and some instances may not belong to any subclass. Overlapping is allowed, and there may be
undefined cases where instances do not fit into any defined subclass.

Each of these constraints has different implications for the modeling of the relationships between the superclass
and its subclasses, and the choice depends on the specific requirements and characteristics of the domain being
modeled.

Certain insertion and deletion rules apply to specialization (and generalization) as a consequence of the
constraints specified earlier. Some of these rules are as follows:
■ Deleting an entity from a superclass implies that it is automatically deleted from all the subclasses to
which it belongs.
■ Inserting an entity in a superclass implies that the entity is mandatorily inserted in all predicate-defined
(or attribute-defined) subclasses for which the entity satisfies the defining predicate.
■ Inserting an entity in a superclass of a total specialization implies that the entity is mandatorily inserted in
at least one of the subclasses of the specialization.
4.4 Modeling of UNION Types Using Categories

It is sometimes necessary to represent a single superclass/subclass relationship with more than one superclass,
where the superclasses represent different entity types. In this case, the subclass will represent a collection of
objects that is a subset of the UNION of distinct entity types; we call such a subclass a union type or a
category.
CREATE TABLE UnionType (
id INT PRIMARY KEY,
common_attribute1 VARCHAR(50),
common_attribute2 VARCHAR(50),
-- Add more common attributes as needed
);

CREATE TABLE Vehicle (

id INT PRIMARY KEY,
vehicle_attribute VARCHAR(50),
-- Other vehicle-specific attributes
FOREIGN KEY (id) REFERENCES UnionType(id)
);

CREATE TABLE Appliance (

id INT PRIMARY KEY,
appliance_attribute VARCHAR(50),
-- Other appliance-specific attributes
 FOREIGN KEY (id) REFERENCES UnionType(id)
);
The concepts of aggregation and association play important roles in modeling relationships between entities in a
database or in object-oriented programming. Let's break down these concepts as described in the provided text:

Aggregation:
Aggregation is an abstraction concept for building composite objects from their component objects. There are
three cases where aggregation can be related to the EER model:

Aggregating Attribute Values: In this case, attribute values of an object are aggregated to form the whole
object. For example, an address object might be composed of street, city, state, and zip code attributes.

Representing Aggregation Relationship as an Ordinary Relationship: Aggregation relationships, where one

object is composed of other objects, can be represented as ordinary relationships in the EER model. This means
that the relationship between the composite object and its components is treated as a regular relationship.

Combining Related Objects into a Higher-Level Aggregate Object: This case involves combining objects
related by a specific relationship instance into a higher-level aggregate object. This can be useful when the
higher-level aggregate object needs to be related to another object. The relationship between the primitive
objects and their aggregate object is termed as IS-A-PART-OF, and the inverse relationship is called
IS-A-COMPONENT-OF.

Association:
Association is used to associate objects from several independent classes. It's somewhat similar to the second
use of aggregation. In the EER model, association is represented by relationship types, while in UML, it's
represented by associations. This abstract relationship is termed as IS-ASSOCIATED-WITH.
In summary, aggregation is about building composite objects from their component objects, while association is
about establishing relationships between objects from different classes or entities. Both concepts are crucial for
modeling complex systems effectively, whether in databases or in object-oriented programming paradigms.

Higher-Level Aggregate Class: One approach to represent complex relationships is to create a higher-level
aggregate class composed of multiple entities and relate this aggregate class to other entities. For example, in
the context of a job recruitment system, you might create an aggregate class composed of COMPANY,
JOB_APPLICANT, and INTERVIEW, and relate this aggregate class to JOB_OFFER.

Composite or Molecular Object: Some data models allow the creation of composite or molecular objects,
where multiple entities are combined into a single object. This approach is akin to creating a higher-level
aggregate class.

Relationships Among Relationships: Some models permit relationships among relationships. In the context of
the job recruitment system, this would mean allowing relationships between entities such as COMPANY,
JOB_APPLICANT, INTERVIEW, and JOB_OFFER directly, without the need for intermediate entities.

ER Model Representation: In the ER model, representing complex relationships often involves creating
additional entity types to accurately capture the relationships. For example, to represent the relationship between
JOB_OFFER and INTERVIEW, a new weak entity type INTERVIEW might be created and related to
JOB_OFFER.
5.Relational Database Design by ER- and EER-to-Relational Mapping
This chapter discusses how to design a relational database schema based on a conceptual schema design.
Figure 7.1 presented a high-level view of the database design process, and in this chapter we focus on the
logical database design or data model mapping step of database design.
We present the procedures to create a relational schema from an Entity-Relationship (ER) or an Enhanced
ER (EER) schema.

5.1.1 ER-to-Relational Mapping Algorithm

In this section we describe the steps of an algorithm for ER-to-relational mapping. We use the COMPANY
database example to illustrate the mapping procedure. The COMPANY ER schema is shown again in Figure 9.1,
and the corresponding COMPANY relational database schema is shown in Figure 9.2 to illustrate the mapping
step.
The table provides a correspondence between elements in the Entity-Relationship (ER) model and their
counterparts in the relational model. Here's a summary of the mapping:

Entity Type in ER model corresponds to an Entity Relation in the relational model. Each entity type becomes a
table in the relational schema.

Relationship Types in ER model, whether it's a 1:1, 1:N, M:N, or n-ary relationship, are represented in the
relational model using Foreign Keys. For M:N and n-ary relationships, a separate Relationship Relation is
introduced along with foreign keys from the participating entities.

Attributes in the ER model are represented as Attributes in the relational model. This includes both simple
attributes and composite attributes.

Multivalued Attributes in ER model are represented as a separate Relation in the relational model, linked to the
main entity relation through a foreign key.

Value Set Domain in ER model is represented by Key Attributes in the relational model, which form the primary
or secondary keys of the entity relation.

Overall, this mapping provides a clear way to translate the structural elements of an ER diagram into a relational
schema, ensuring that the integrity and semantics of the data model are preserved during the conversion
process.