CSE - 220

Database Management Systems

Subrat K Dash
LNMIIT

Database Application Design

Database
Application

Database

Application
Programs

Focus is on Database design structures and constraints

Conceptual Schema based on Relational Data model
Entity-Relationship (ER) Model
Subrat K Dash, LNMIIT

Phases of Database Design

Subrat K Dash, LNMIIT

Example A sample description of a

mini-world (A 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, address, salary, sex, 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 number of hours per week that an employee works on each project.
We also keep track of the direct supervisor of each 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.

Subrat K Dash, LNMIIT

ER Model Concepts
Entities and Attributes
Entities are specific objects or things in the mini-world with an
independent existence (physical or conceptual). For example a particular
person, an EMPLOYEE John Smith, the Research DEPARTMENT, an
institute LNMIIT.
Attributes are properties used to describe an entity. For example an
EMPLOYEE entity may have a Name, SSN, Address, Sex, BirthDate
A specific entity will have a value for each of its attributes. For example a
specific employee entity may have Name='John Smith', SSN='123456789',
Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55'

Each attribute has a value set (or domain of values) associated with it.
Typically specified using basic data types like integer, string, subrange,
enumerated type,
Subrat K Dash, LNMIIT

Example Entity, Attribute, Attribute

values

Subrat K Dash, LNMIIT

Types of Attributes (1)

Atomic (Simple)
Each entity has a single atomic value for the attribute. For example, SSN or
Sex.

Composite
The attribute may be composed of several components. For example,
Address (Apt#, House#, Street, City, State, ZipCode, Country) or Name
(FirstName, MiddleName, LastName). Composition may form a hierarchy
where some components are themselves composite.

Subrat K Dash, LNMIIT

Types of Attributes (2)

Single-valued
Attributes having a single value for a particular entity
Ex: Age, Height

Multi-valued
An entity may have multiple values for that attribute. For example,
Color of a CAR or PreviousDegrees of a STUDENT. Denoted as {Color}
or {PreviousDegrees}

Complex
Composite and multi-valued attributes may be nested arbitrarily to
any number of levels although this is rare. For example,
PreviousDegrees of a STUDENT is a composite multi-valued attribute
denoted by {PreviousDegrees (College, Year, Degree, Field)}.
Subrat K Dash, LNMIIT

Types of Attributes (3)

Stored
Attributes whose values are stored explicitly

Derived
Attributes whose values can be derived from some
other attributes (Age is derivable from DOB) or related
entities.

Null Values a special value

An entity may not have an applicable value for an attribute
When the value of an attribute is not known
Subrat K Dash, LNMIIT

Entity Types and Key Attributes

Entities with the same basic attributes are grouped or typed into an
entity type. For example, the EMPLOYEE entity type or the PROJECT
entity type.
An attribute of an entity type for which each entity must have a
unique value is called a key attribute of the entity type. For
example, SSN of EMPLOYEE.

A key attribute may be composite. For example, VehicleTagNumber

is a key of the CAR entity type with components (Number, State).
An entity type may have more than one key. For example, the CAR
entity type may have two keys:
VehicleIdentificationNumber (popularly called VIN) and
VehicleTagNumber (Number, State), also known as license_plate number.
Subrat K Dash, LNMIIT

Example Entity Type and Entity Set

Subrat K Dash, LNMIIT

ER Diagram notations for ER Schemas

Meaning

ENTITY TYPE
WEAK ENTITY TYPE
RELATIONSHIP TYPE
IDENTIFYING RELATIONSHIP TYPE
ATTRIBUTE
KEY ATTRIBUTE
MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE
DERIVED ATTRIBUTE
TOTAL PARTICIPATION OF E2 IN R
CARDINALITY RATIO 1:N FOR E1:E2 IN R
STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R

Subrat K Dash, LNMIIT

Example A sample description of a

mini-world (A 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, address, salary, sex, 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 number of hours per week that an employee works on each project.
We also keep track of the direct supervisor of each 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.

Subrat K Dash, LNMIIT

Example Initial conceptual design

An entity type DEPARTMENT with attributes Name, Number, Locations,
Manager, and ManagerStartDate. Locations is the only multivalued
attribute. We can specify that both Name and Number are (separate) key
attributes, because each was specified to be unique.
An entity type PROJECT with attributes Name, Number, Location, and
ControllingDepartment. Both Name and Number are (separate) key
attributes.

An entity type EMPLOYEE with attributes Name, SSN (for social security
number), Sex, Address, Salary, BirthDate, 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-FirstName,
Middlelnitial, LastName-or of Address.
An entity type DEPENDENT with attributes Employee, DependentName,
Sex, BirthDate, and Relationship (to the employee).
Subrat K Dash, LNMIIT

Example ER Diagram

Subrat K Dash, LNMIIT

ER Diagram notations for ER Schemas

Meaning

ENTITY TYPE
WEAK ENTITY TYPE
RELATIONSHIP TYPE
IDENTIFYING RELATIONSHIP TYPE
ATTRIBUTE
KEY ATTRIBUTE
MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE
DERIVED ATTRIBUTE
TOTAL PARTICIPATION OF E2 IN R
CARDINALITY RATIO 1:N FOR E1:E2 IN R
STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R

Subrat K Dash, LNMIIT

Relationship and Relationship Types

Relationship relates two or more distinct entities
with a specific meaning.
An attribute of one entity type refers to another entity
type

Relationships of the same type are grouped or

typed into a relationship type
Degree of a relationship no. of entity types
involved
Unary, Binary, Ternary, , n-ary
Subrat K Dash, LNMIIT

Example Binary relationship

Entity Type

Relationship Type

Subrat K Dash, LNMIIT

Example Recursive relationship

Subrat K Dash, LNMIIT

Structural Constraints
1. Cardinality ratio (Mapping cardinalities)
Maximum number of relationship instances that an entity
can participate in
1:1, 1:N, N:1, M:N
Shown by placing appropriate number on the relationship

Subrat K Dash, LNMIIT

Structural Constraints
2. Participation constraint
Minimum number of relationship instances that each
entity can participate in Minimum cardinality constraint
Total participation (existence dependency)
Every EMPLOYEE must work for a DEPARTMENT
Displayed as a double line in ER diagram

Partial
Each DEPARTMENT is managed by an EMPLOYEE (but all
EMPLOYEES do not manage DEPARTMENTS)
Displayed as a single line in ER diagram
Subrat K Dash, LNMIIT

Example ER Diagram

Subrat K Dash, LNMIIT

Entity Types
Strong entity types
Have key attribute(s)

Weak entity types

Do not have a key attribute

A weak entity must participate in an identifying relationship

type with an owner or identifying entity type
Entities are identified by the combination of:
A partial key of the weak entity type
The particular entity they are related to in the identifying entity type

Subrat K Dash, LNMIIT

Example Weak entity type

Identifying entity type

Identifying relationship type

Weak entity type
Partial key

Subrat K Dash, LNMIIT

Attributes of relationship types

A relationship can have attributes
Example: HoursPerWeek of WORKS_ON
Describes number of hours per week that an
EMPLOYEE works on a PROJECT
Attributes of 1:1 or 1:N relationship types can be
migrated to one of the participating entity types.
In 1:N, only to the N-side of the relationship

Subrat K Dash, LNMIIT

Alternative (min, max) notation for

relationship structural constraints
Specified on each participation of an entity type E
in a relationship type R
Specifies that each entity e in E participates in at
least min and at most max relationship instances
in R
Default(no constraint): min=0, max=n
Must have min max, min 0, max 1

min=0 implies partial participation whereas

min>0 implies total participation
Subrat K Dash, LNMIIT

Example
A department has exactly one manager and an
employee can manage at most one department.

An employee can work for exactly one department but

a department can have any number of employees.
.
Subrat K Dash, LNMIIT

Sample Example

Subrat K Dash, LNMIIT

ER Diagram Exercise
A university keeps track of each student's name, student
number, social security number, current address and
phone, permanent address and phone, birthdate, sex, class
(freshman, sophomore, ..., graduate), major department,
minor department (if any), and degree program (B.A., B.S.,
..., Ph.D.). Some user applications need to refer to the city,
state, and zip of the student's permanent address, and to
the student's last name. Both social security number and
student number have unique values for each student.
Each department is described by a name, department code,
office number, office phone, and college. Both name and
code have unique values for each department.

Subrat K Dash, LNMIIT

ER Diagram Exercise cont

Each course has a course name, description, course
number, number of semester hours, level, and offering
department. The value of course number is unique for each
course.
Each section has an instructor, semester, year, course, and
section number. The section number distinguishes different
sections of the same course that are taught during the
same semester/year; its values are 1, 2, 3, ..., up to the
number of sections taught during each semester.
A grade report has a student, section, letter grade, and
numeric grade (0, 1, 2, 3, 4 for F, D, C, B, A, respectively).

Subrat K Dash, LNMIIT

ER Diagram Solution!

Subrat K Dash, LNMIIT

Limitation with ER notation

Do not support SPECIALIZATION (the process
of defining a set of subclasses of an entity
type) and GENERALIZATION (the process of
defining a generalized entity type from the
given entity types) abstractions

Subrat K Dash, LNMIIT

Enhanced Entity-Relationship (EER)

Model
Additional concepts
Subclass, superclass, superclass/subclass
relationship (IS-A relationship), specialization,
generalization, categories, attribute inheritance
Includes object oriented concepts

Subrat K Dash, LNMIIT

Concepts Subclass, Superclass

An entity type may have subgroups of its entities that
are meaningful and need to be represented explicitly
Example
EMPLOYEE may be grouped into SECRETARY, ENGINEER,
MANAGER, TECHNICIAN etc.
EMPLOYEE is called a superclass
Each subgroups is called a subclass

The relationship is called a superclass/subclass

relationship (IS-A relationship).
Subrat K Dash, LNMIIT

Specialization
Is the process of defining a set of
subclasses of a superclass
Example: {SECRETARY, ENGINEER,
TECHNICIAN} is a specialization of
EMPLOYEE based upon job type.

A superclass may have several

specializations
Example: Another specialization of
EMPLOYEE based on method of
pay is {SALARIED_EMPLOYEE,
HOURLY_EMPLOYEE}.
Subrat K Dash, LNMIIT

Example
An entity that is
member of a subclass
inherits all attributes of
the entity as a member
of the superclass
It also inherits all
relationships

Add additional specific

attributes to subclasses
May involve subclasses
with additional specific
relationship types

Subrat K Dash, LNMIIT

Example

Specific
attribute

Specific
relationship
types
Subrat K Dash, LNMIIT

Generalization
The reverse of the specialization process

Several classes with common features are generalized

into a superclass; original classes become its subclasses
Example
CAR, TRUCK generalized into VEHICLE; both CAR, TRUCK
become subclasses of the superclass VEHICLE.
We can view {CAR, TRUCK} as a specialization of VEHICLE

Alternatively, we can view VEHICLE as a generalization of

CAR and TRUCK
Subrat K Dash, LNMIIT

Constraints on Specialization and

Generalization (1)

If we can determine exactly those entities that will become members of each
subclass by a condition, the subclasses are called predicate-defined (or conditiondefined) subclasses
Condition is a constraint that determines subclass members
Display a predicate-defined subclass by writing the predicate condition next to the line
attaching the subclass to its superclass

If all subclasses in a specialization have membership condition on same attribute

of the superclass, specialization is called an attribute defined-specialization
Attribute is called the defining attribute of the specialization
Example: JobType is the defining attribute of the specialization {SECRETARY, TECHNICIAN,
ENGINEER} of EMPLOYEE

If no condition determines membership, the subclass is called user-defined

Membership in a subclass is determined by the database users by applying an operation to
add an entity to the subclass
Membership in the subclass is specified individually for each entity in the superclass by the
user
Subrat K Dash, LNMIIT

Constraints on Specialization and

Generalization (2)
Disjointness Constraint
Specifies that the subclasses of the specialization must be disjointed
Specified by d in EER diagram
If not disjointed, overlap; that is the same entity may be a member of
more than one subclass of the specialization
Specified by o in EER diagram

Completeness Constraint
Total specifies that every entity in the superclass must be a member of
some subclass in the specialization/ generalization
Shown in EER diagrams by a double line

Partial allows an entity not to belong to any of the subclasses

Shown in EER diagrams by a single line
Subrat K Dash, LNMIIT

Constraints on Specialization and

Generalization (3)
Hence, we have four types of specialization /
generalization
Disjoint, total
Disjoint, partial
Overlapping, total
Overlapping, partial

Note: Generalization usually is total because the

superclass is derived from the subclasses.
Subrat K Dash, LNMIIT

Hierarchies, Lattices and Shared

Subclasses
A subclass may itself have further subclasses specified on it
Forms a hierarchy or a lattice
Hierarchy has a constraint that every subclass has only one
superclass (called single inheritance)
In a lattice, a subclass can be subclass of more than one superclass
(called multiple inheritance)
In a lattice or hierarchy, a subclass inherits attributes not only of its
direct superclass, but also of all its predecessor superclasses
A subclass with more than one superclass is called a shared subclass

Subrat K Dash, LNMIIT

Example

Subrat K Dash, LNMIIT

Example

Subrat K Dash, LNMIIT

UNION Types

Subrat K Dash, LNMIIT