Introduction to

Database Systems

Week 4

1
Fact-Finding
Techniques
Chapter - 11

2
 ▪ There are many occasions during DSDL when it is
critical that the database developer captures the
necessary facts to build the required database system.
▪ The necessary facts include, for example, the
Fact terminology used within the enterprise, problems
encountered using the current system, opportunities
Finding sought from the new system, necessary constraints on
the data and users of the new system, and a prioritized
set of requirements for the new system.
▪ These facts are captured using fact-finding techniques.
▪ Fact finding is the formal process of using techniques
such as interviews and questionnaires to collect facts
about systems, requirements, and preferences.
 ▪ Fact-finding is particularly crucial to the early stages of
the lifecycle, including the database planning, system
definition, and requirements collection and analysis
stages
▪ Fact-finding is also used during database design and
When fact the later stages of the lifecycle, but to a lesser extent.
Finding ▪ For example, during physical database design, fact-
finding becomes technical as the database developer
technique attempts to learn more about the DBMS selected for
used? the database system.
▪ Also, during the final stage, operational maintenance,
fact-finding is used to determine whether a system
requires tuning to improve performance or further
development to include new requirements.
▪ Table present in book on page no (377) denote the
major facts which captured during DSDL stage.
 ▪ A database developer normally uses
several fact-finding techniques during a
single database project
Fact
Finding • Examining documentation
• Interviewing
Techniques • Observing the enterprise in operation
• Research
• Questionnaires
 ▪ Examine the documents

Examining
Documentation
 ▪ There are two types of interview:
unstructured and structured.
▪ Open-ended questions vs Closed-ended
questions.

Interviewing
Observing the
Enterprise in
Operation
Research
 ▪ Free-format questions and Fixed-format
questions

Questionnaires
Entity–Relationship
Modeling
Chapter - 12

11
 ▪ A semantic data model, used for the
graphical representation of the
conceptual database design
▪ Major components are
E-R Data
Model • Entities
• Attributes
• Relationships
 Entity
Relationship
(ER)
diagram
 ▪ Term used to mean three
different meanings
• Entity type
 A group of objects with the same properties,
which are identified by the enterprise as
Entity having an independent existence.
• Entity instance
 A uniquely identifiable object of an entity
type.
• Entity set
▪ A collection of uniquely identifiable object of an
entity type.
 ▪ A name/label assigned to
items/objects that exist in an
environment and that have similar
Entity properties
Type ▪ It could be person, place, event or
even concept
▪ Distinguishable from other entity
types on the basis of properties
 ▪ A particular object belonging to a
particular entity type
▪ A uniquely identifiable object of an
Entity entity type.
Instance
and • Entity Type: MSStudent
Entity Set • Entity Instance: Hamzala
• Entity Set: Students
 ▪ Entity types can be classified into
Types of
Entity
• Regular/Strong/Independent
Types • Weak/Dependent
 ▪ A strong/regular entity type is the
one whose instances can exist
Strong independently, i.e., without being
Entity Types linked to other instances
▪ Strong ETs have their own identity
 ▪ An entity type whose instances
Weak cannot exist without being linked
with instances of some other entity
Entity Types type, i.e., they cannot exist
independently
 ▪ Singular noun recommended
Naming ▪ Organization specific names
Entity
▪ Write in capitals
Types
▪ Abbreviations can be used
 Regular Entity Type NAME

Weak Entity Type NAME

Entity
Symbols EMPPLOYEE DEPENDENTS

BOOK BOOKCOPY
 ▪ An attribute of an entity type is a
defining property or quality of the
instances of that entity type.
Attributes ▪ Entity instances of same entity type
have the same attributes. (e.g.
Student Identification, Student
Name)
 ▪ Every attribute has a domain
Attribute ▪ Each attribute is associated with a
set of values called a domain.
Domain
▪ The attributes in an entity set get the
values from the same do
 ▪ Each represented as an oval, linked
with an ET symbol
Symbols
for
Attributes
 ▪ Single vs composite
Types of ▪ Single valued vs multi-valued
Attributes
▪ Stored vs derived
 ▪Simple Attribute: An attribute
composed of a single component with
an independent existence. It can not
be further divided. Some times Called
Atomic.
Single • Position and Salary.
vs
composite ▪Composite Attribute: An attribute
composed of multiple components,
each with an independent existence.
• Address
 ▪Single-valued Attribute: An attribute
that holds a single value for each
occurrence of an entity type.
Single-Valued • Branch Number
vs
Multi-Valued ▪Multi-valued Attribute: An attribute
that holds multiple values for each
occurrence of an entity type.
• Phone Number
 ▪Derived Attribute: An attribute that
Derived represents a value that is derivable
from the value of a related attribute or
vs set of attributes, not necessarily in the
Stored same entity type.
• Duration
 Simple

Symbols Composite
for
Attributes
Multi-valued

Derived
 Experience empId empName

Example EMPLOYEE address

dateHired emp_Qual street houseNo

 ▪ An attribute or set of attributes to
identify an entity instance uniquely
▪ Types
• Super key
Keys
• Candidate key
• Primary key
• Composite
 StudID Roll No First Name LastName Email

1 11 Tom Wright [email protected]

2 12 Nick Wright [email protected]

3 13 Tom Natan [email protected]

Example
• Super key (StudID, RollNo, Email,
(StudID,RollNo), (StudID,Email)..etc )
• Candidate key (StudID, Roll No, Email)
• Primary key (StudID, Roll No, Email)
• Composite ((StudID,RollNo), (StudID,
Email))
 ▪Relationship type: A set of meaningful
associations among entity types.

Relationship ▪Relationship Occurrence: A uniquely

identifiable association, which includes
one occurrence from each
participating entity type.
Relationship
Representation
 Individual
Occurrences
of HAS
relationship
type
 ▪ STUDENT and CLASS have ENROLL
relationship
Naming ▪ However, it can also be named as STD_CLS
 ▪ Entities involved in a relationship are
called its participants
▪ The participation of an entity in a
relationship is total participation
when all entities of that set might be
Participants participant in the relationship
otherwise it is partial participation.

• if every Part is supplied by a

Supplier
 ▪ The number of participating entity
types in a relationship is called
degree of relationship type.
▪ Unary Relationship
Degree of
Relationship ▪ A Binary relationship is the one that
Type links two entity sets e.g. STUDENT-
CLASS

▪ A Ternary relationship is the one

that involves three entities e.g.
STUDENT-CLASS-FACULTY.
 Degree of
Relationship
Type
 ▪ Relationships can be formally
described in an ordered pair form.
▪ For Example,
Enroll = {(S1001, ART103A), (S1020,
CS201A), (S1002, CSC201A)}
Relationship
Example {(S1013, MCS4, Adnan),
Types (S1023, MCS3, Ahmed)}

▪ Entire set is relationship set and each

ordered pair is an instance of the
relationship.
 ▪ Number of instances of one entity
type that can possibly be related to
instances of other entity type
Cardinality
of
▪ Types of Cardinalities
Relationships • One to One (1:1)
• One to Many (1:*)
• Many to Many (*:*)
One to One
(1:1)
One to Many
(1:*)
Many to Many
(*:*)
Thank You

45