1.

Requirements Collection and Analysis

2. Create Conceptual Schema
3. Actual Implementation of the Database
4. Physical Design
 The company is organized into DEPARTMENTs.
Each department has a name, number and an
employee who manages the department. We keep
track of the start date of the department manager.
A department may have several locations.
 Each department controls a number of PROJECTs.
Each project has a unique name, unique number
and is located at a single location.
 We store each EMPLOYEE’s social security number,
address, salary, sex, and birthdate.
 Each employee works for one department but
may work on several projects.
 We keep track of the number of hours per
week that an employee currently works on
each project.
 We also keep track of the direct supervisor of
each employee.
 Each employee may have a number of
DEPENDENTs.
 For each dependent, we keep track of their
name, sex, birthdate, and relationship to the
employee.
 Entity is a thing or object in the real world with an
independent existence.
 Each entity has Attributes - the particular
properties that describe it.
 The attribute values that describe each entity
become a major part of the data stored in the
database.
 Composite versus Simple/Atomic Attributes

 Composite attributes can be divided into

smaller subparts, which represent more basic
attributes with independent meanings.
 Ex. Address -> Street_Address, City, State,
City,Zip-code

 Simple/ Atomic Attributes

 Attributes that are not divisible
 Ex: USN, SSN, Gender
 Single-Valued versus Multivalued Attributes

 Attributes having a single value for a specific

entity is called Single-Valued Attribute.
 Example: Age

 Attributes having set of values for an entity is

called multi-valued attributes.
 Example: Colors of a Car, Student Degrees
 Stored versus Derived Attributes
 Derived attributes are those attributes which
can be derived from other attribute(s).
 Example: Age

 NULL Values
 NULL can be used if we do not know the value of
an attribute for a particular entity- Unknown
Category
 Two categories:
 Attribute value exists but is missing
 Not known if the attribute values exists or not

 It can also be used if a particular entity does not

have an applicable value for an attribute- Not
Applicable Category
 Complex Attributes

 Composite and Multivalued Attributes can be

nested.
 We can represent the nesting by grouping the
components of a composite attribute between
parentheses() and separating the components
with commas, and by displaying multivalued
attributes between braces {}
 Such attributes are called Complex Attributes.
 Ex: A publisher can have offices at different
places, each with different addresses and each
office having multiple phones.
 {Address_phone({phone},address(house_no,
street, city, state, pin_code))}
 Entity type defines a collection of entities that
have same attributes.
 Entities can share the same attributes, but each
entity will have its own value for each attribute.
 The collection of all entities of a particular entity
type in the database at any point in time is called
an entity set or entity collection.
 Entity type is represented as a rectangular box
enclosing the entity type name in it.
 Attribute names are enclosed in ovals and are
attached to their entity types with straight lines.
 Also called as the key constraint or uniqueness
constraint.
 An entity type usually has one or more attributes
that identify each individual entity uniquely.
 Such an attribute is called a key attribute.
 Each key attribute has its name underlined in the
oval, while representing in the ER Diagram.
 Each simple attribute of an entity types is associated
with a value set or domain of values, which specifies a
set of values that may be assigned to that attribute.
 If the range of ages allowed for employees between 18
to 70, we can specify the value set of the Age attribute of
EMPLOYEE to be the set of integer numbers between
18 to 70.
 Similarly, we can specify the value set for the Name
attribute as being the set of strings of alphabetic
characters separated by blank characters and so on.
 Value sets are not specifically represented in the ER
Diagram.
 They are similar to data types.
 We can identify four initial entity types in the
COMPANY database:
 DEPARTMENT
 PROJECT
 EMPLOYEE
 DEPENDENT
 The initial design is typically not complete
 ER model has three main concepts:
 Entities (and their entity types and entity sets)
 Attributes (simple, composite, multivalued)
 Relationships (and their relationship types and
relationship sets)
 Relationships: A relationship relates two or more
distinct entities with a specific meaning.
 For example, EMPLOYEE John Smith works on the
ProductX PROJECT, or EMPLOYEE Franklin Wong
manages the Research DEPARTMENT.
 Relationship Types: Relationships of the same
type are grouped or typed into a relationship
type.
 For example, the WORKS_ON relationship type in
which EMPLOYEEs and PROJECTs participate, or
the MANAGES relationship type in which
EMPLOYEEs and DEPARTMENTs participate.
 Relationship Instances:
 In ER diagram, Relationship types are displayed as
diamond-shaped boxes, which are connected by
straight lines to the rectangular boxes representing
the participating entity types.
 In the above figure WORKS_FOR is relationship
type and r1, r2,r3,…..r7 are relationship
instances.
 Relationship Degree: The degree of the
relationship is the number of participating entity
types.
 A relationship type with degree 1 is termed unary
 A relationship type with degree 2 is termed binary.
 A relationship type with degree 3 is termed
ternary.
 Ternary relationship
 Role Names :
 Each Entity type that participates in a
relationship plays a particular role in the
relationship.
 The role name signifies the role that a
participating entity from the entity type plays in
each relationship instance.
 Example: Suppose we have two Entity types
EMPLOYEE and DEPARTMENT and the
relationship is WORKS_FOR. Then EMPLOYEE
plays the role of an worker and DEPARTMENT
plays the role of an employer.
 Recursive Relationships:
 Same Entity types participates more than once in
a relationship type in different roles, in such
cases the role name becomes essential for
distinguishing the meaning of each participation.
Such relationship types are called recursive
relationships..
 Also called as self-referencing relationships.
 Example:
 Relationship: SUPERVISION
 Participating Entity type: EMPLOYEE
 EMPLOYEE Entity type participates twice in the
relationship SUPERVISION once in the role of a
supervisor and once in the role of a
supervisee.
2 types of relationship constraints(structural
constraints)
1.Cardinality Ratio
2.Participation constraints
1. Cardinality Ratios for Binary Relationships
 The Cardinality ratio for a binary relationship
specifies the maximum number of relationship
instances that an entity can participate in.
 The possible cardinality ratios for binary
relationship types are 1:1, 1:N, N:1 and M:N.
 Cardinality ratios for binary relationships are
represented on ER diagrams by displaying 1,M and
N on the diamonds.
 Participation Constraint specifies whether the
existence of an entity depends on its being related
to another entity via the relationship type.
 This constraint specifies the minimum number of
relationship instances that each entity can
participate in.
 It is also called as the minimum cardinality
constraint.
 There are two types of participation constraints
 Total Participation
 Partial Participation
 Each entity in the entity set must participate in
the relationship.
 Example: If a company policy states that every
employee must work for a department, then an
employee entity can exist only if it participates in at
least one WORKS_FOR relationship instance.
 Total participation is represented using double
lines in ER diagram.
 Also called as existence dependency.

EMPLOYEE WORKS DEPARTMENT

_FOR
  The entity in the entity set may or may NOT participate in
the relationship.
 Example: Every employee is not expected to manage a
department, so the participation of EMPLOYEE in the
MANAGES relationship type is partial.
 Partial participation is represented by a single line in the ER
Diagram.

EMPLOYEE MANAGES DEPARTMENT

 Cardinality ratio and participation constraints are
together called as Structural Constraints.
 Relationship types can also have attributes, similar to
those of entity types.
 Ex: To record the number of hours per week that an
employee works on a project, we can include an
attribute Hours for the WORKS_ON relationship type.
 Another example is to include the date on which a
manager started managing a department via an
attribute StartDate for the MANAGES relationship type.
 The attributes of 1:1 relationship types can be migrated
to one of the participating entity types.
 Ex: the StartDate attribute for the MANAGES
relationship can be attribute of either EMPLOYEE OR
DEPARTMENT. This is because MANAGES is a 1:1
relationship.
 The attributes of 1:N or N:1 relationship types can be
migrated only to the entity type on the N-side of the
relationship.
 Ex: If the WORKS_FOR relationship also has an attribute
StartDate that indicates when an employee started
working for a departmemt, this attribute can be
included as an attribute of EMPLOYEE.
 This is because each employee entity participate in
atmost one relatioship instance in WORKS_FOR.
 The attributes of M:N relationship types can be
determined by the combination of participating entities
and not by any single entity.
 Entity types that do not have any key attributes of
their own are called weak entity types.
 The entity types that have a key attribute of their
are called strong entity types.
 How to identify the entities belonging to a weak
entity type?
 By being related to specific entities from another
entity type in combination with one of their
attribute values.
 The other entity type is called as the identifying
or owner entity type.
 The relationship type that relates a weak entity
type to its owner the identifying relationship.
 Weak entity type always has a total participation
constraint with respect to its identifying
relationship, because a weak entity cannot be
identified without an owner entity.
 Consider the entity type DEPENDENT, related to
EMPLOYEE, which is used to keep track of the
dependents of each employee via 1:N relationship.
The attributes of DEPENDENT are
dependent_name, birthdate and relationship.
 Two dependents of distinct employees may have
the same values for dependent_name, birthdate
and relationship, but they are still distinct entities.
They are identified as distinct entities only after
determining the employee entity to which each is
related. Each employee entity is said to own the
dependent entities that are related to it.
 A weak entity type normally has a partial key,
which is the set of attributes that can uniquely
identify weak entities related to the same owner
entity.
 Inour example, if we assume that no two
dependents of the same employee ever have the
same name, the attribute dependent_name of
DEPENDENT is the partial key.
 In an ER diagram, weak entity types can be
represented using double rectangular box and
Identifying relationship is represented using
double Diamond.
 Partial Key is represented with dotted underline.
 The company is organized into DEPARTMENTs.
Each department has a name, number and an
employee who manages the department. We keep
track of the start date of the department manager.
A department may have several locations.
 Each department controls a number of PROJECTs.
Each project has a unique name, unique number
and is located at a single location.
 We store each EMPLOYEE’s social security number,
address, salary, sex, and birthdate.
 Each employee works for one department but
may work on several projects.
 We keep track of the number of hours per
week that an employee currently works on
each project.
 We also keep track of the direct supervisor of
each employee.
 Each employee may have a number of
DEPENDENTs.
 For each dependent, we keep track of their
name, sex, birthdate, and relationship to the
employee.
 Specifies that each entity e in E participates in at least
min and at most max relationship instances in R at any
point in time.
 Min=0 implies partial participation, whereas min>0
implies total participation.
 min=0, max=n (signifying no limit)
 Must have minmax, min0, max 1
 Example:
 A department has exactly one manager and an
employee can manage at most one department.
 Specify (0,1) for participation of EMPLOYEE in MANAGES
 Specify (1,1) for participation of DEPARTMENT in MANAGES
 An employee can work for exactly one department
but a department can have any number of
employees.
 Specify (1,1) for participation of EMPLOYEE in
WORKS_FOR
 Specify (0,n) for participation of DEPARTMENT in
WORKS_FOR