S Y S T E M S A N A LY S I S

& D ATA B A S E
MANAGEMENT
SYSTEMS
INFS7007

3
Recap
• Planning Phase
• Feasibility Analysis
• Database environment
• Components of DBMS environment
• ANSI/SPARC 3 level architecture
• SQL - Create and Drop

2
Outline
• Analysis Phase
• Introduction to Data Modelling
• Basics of ER Modelling
• The Relational Model
• ER Model vs Relational Model
• SQL – literals, select, insert, delete and update table

3
SYSTEMS
ANALYSIS
AND
DESIGN
PART A
Information Systems
• HOW to create a new information system?
▪ Systems Development Life Cycle (SDLC)
I. Planning
II. Analysis
a. System Proposal
III. Design
IV. Implementation
V. Maintenance

5
Recall - Planning Phase Questions
• Why should we select this project?
• Is this project feasible?
• Which variant of SDLC will be used in this project?
• What is the project plan?
• Who will be involved?
• How to coordinate and manage the project?
• How to minimise the potential risks?

6
Planning vs Analysis
Planning Phase
• Why should we select this
project?
• How the project team will
build it?
• How to manage the project?
Analysis Phase
• Who will use the system?
• What the system will do?
• Where and when it will be
used?
7
Analysis Phase
• The project team
▪ Investigates any current system(s),
▪ identifies improvement opportunities, and
▪ develops a concept for the new system
• Steps in Analysis Phase are
1. Understand the existing situation (the as-is system)
2. Identify improvements
3. Define requirements for the new one (the to-be system)

8
Analysis Phase Main Tasks
• Analysis strategy: what are the focuses and strategies of the
analysis phase?
• Requirement gathering: what the system will do? What are the
business rules in the scenario?
Requirement analysis
Use case analysis
Process modelling
Data modelling
• System proposal: combine business requirements, system concepts,
business rules and models together as a document.
9
Analysis Strategy
• Problem analysis: focuses on problems
• Root cause analysis: focuses on solutions to the problems
• Duration analysis: focuses on time
• Activity-based costing: focuses on costs
• Informal benchmarking: focuses on benchmarks
• Outcome analysis: focuses on outcomes
• Technology analysis: focuses on technologies
• Activity elimination: focuses on eliminating activities

10
Business Requirements & Business Rules
• Business requirements:
▪ What the system will do?
▪ How to deliver, satisfy or meet the requirements?

• Business rules:
▪ What are the operations, definitions and constraints that apply
to the business?

11
Requirement Gathering
• Explicit requirements:
▪ Business requirements/rules that are explicitly stated.

• Implicit requirements
▪ Business requirements/rules that are hidden.

Explicit Moderate Implicit

Easy Hard

12
Requirement Analysis - Categories
• Business requirements: what the business needs?
e.g., place a new customer order
• User requirements: what the user wants?
e.g., list all available products in stock
• Functional requirements: what the system should do?
e.g., check the shopping cart
• Non-functional requirements: what the system should have?
e.g., respond every request in 2 seconds
• System requirements: how the system should be built?
e.g., how big the data storage is
13
Requirement Analysis - Techniques
• Eliciting requirements techniques
▪ Interview
▪ JAD session
▪ Questionnaire
▪ Document analysis
▪ Observation
▪ Common sense reasoning

14
Requirement Analysis
Techniques - Interview
• Closed-Ended questions
▪ How many telephone orders are received per day?
▪ How do customers place orders?
▪ What information is missing from the monthly sales report?

• Open-Ended questions
▪ What do you think about the way invoices are currently processed?
▪ What are some of the problems you face on a daily basis?
▪ What are some of the improvements you would like to see in the
▪ way invoices are processed?

• Probing questions
▪ Why?
▪ Can you give me an example?
▪ Can you explain that in a bit more detail?

15
Requirement Analysis
Techniques - JAD
Joint Application Development
(JAD) a special type of group
meeting to identify system
requirements
Reduced time for requirements
collection

16
Requirement Analysis
Techniques - Questionnaire
• Set of written questions to
obtain information (facts)
• questionnaires must:
▪ very clearly written
▪ must leave little room for
misunderstanding
• Closed-ended questions e.g.
“How often does a network
problem occur: once an hour,
once a day, or once a week?”

17
Requirement Analysis
Techniques – D.A.
• Document analysis technique is
used to understand the as-is
system
• Review current system
documentation
▪ Paper reports
▪ Memorandums
▪ Policy manuals
▪ User training manuals
▪ Organisation charts
▪ forms
• Examine the system

18
Requirement Analysis
Techniques – Observation
• Observe Employees and
information flow
• Check the validity of
information gathered
previously via interviews and
questionnaires
• what you see may not be what
you really want

19
R E Q U I R E M E N T
A N A L Y S I S
T E C H N I Q U E S
– C O M M O N
S E N S E

20
Analysis Phase Summary

21
A Case Study – Hotel Reservation
• Explicit requirements:
▪ Hotel Manager: how many guests booked a room?
▪ Hotel Manager: what is the ratio of empty rooms?
▪ Guest: book a particular room under a certain price.
▪ Guest: find the cheapest room available on a particular
day.

22
Analysis Strategy
• Problem Analysis - asking the users and managers to identify
problems with the as-is system and describe how to solve them in
the to-be system
• Root Cause Analysis - ideas produced by problem analysis tend to be
solutions to problems
• Duration Analysis - detailed examination of the amount of time it
takes to perform each process in the current as-is system
• Activity-Based Costing - examines the cost of each major process or
step in a business process rather than the time taken

23
Analysis Strategy
• Informal Benchmarking - studying how other organisations perform a business
process in order to learn how your organisation can do something better
• Outcome Analysis - focuses on understanding the fundamental outcomes that
provide value to customers
• Technology analysis - have the analysts and managers develop a list of
important and interesting technologies and then identify how each and every
technology could be applied to the business process and how the business
would benefit
• Activity Elimination - analysts and managers work together to identify how the
organisation could eliminate each and every activity in the business process,
how the function could operate without it, and what effects are likely to occur

24
A Case Study – Hotel Reservation
• Requirements analysis:
▪ Interview e.g., calculate the total revenue of a particular day
▪ JAD e.g., working with managers, customers
▪ Questionnaire e.g., are you satisfied with the current service
▪ Document analysis e.g., analyse the current bills
▪ Observation e.g., each room can only be booked by one guest
▪ Common sense e.g., there are some rooms empty

25
 D A T A B A S E
M A N A G E M E N T
S Y S T E M S
PART B
Recall - ANSI-SPARC 3 Level Architecture
Users should not have direct access to the physical data.

The way users perceive

the data is the
EXTERNAL level

The CONCEPTUAL level provides the

DBA can
mapping details, and aids the change
separation/independence between conceptual
other two levels Logical structure of entire database structure of
database
The way the operating without
system and DBMS perceive
the data is the INTERNAL affecting all
level How data is organised users.

DB administrator should be able to change database

storage structure without affecting the user view. 27
What is Data Model
• “Integrated collection of concepts for
describing data, relationships between data,
and constraints on the data in an
organization.” - Connolly & Begg, p.93/95

28
Modelling is a Process Different
of Abstraction ... modelling
purposes lead
to different
abstractions

Veterinary
Grandma surgeon

29
Particulars of a Data Model
• Purpose: to represent data in an understandable and manageable
way
• 3 components
▪ Structural part – rules according to which DB can be constructed
▪ Manipulative part – defines the types of operations allowed on the data
(how the data will be manipulated)
▪ Integrity constraints – ensure the data to be accurate
• Categories of data models
▪ Object-based (multi-dimensions)
▪ Record-based (2 dimensions)
▪ physical

30
Manipulative: e.g. whether Structural: defines the core
Particulars
relations can be joined oftoa Data Model of the data and the
produce other relations. relationships involved.
• Purpose: to represent data in an understandable and manageable
The way
manipulation may be The model structure can be
• 3 via
done components
relational algebras. described in terms of entities,
▪ Structural part – rules according to which DBrelations, tuples attributes
can be constructed
▪ Manipulative part – defines the types of operations allowed on
and domains the data
etc.
Physical data
(how the datamodels
will be manipulated)
▪ Integrity
describe how constraints – ensureinthe data to be accurate
data is stored
Categoriesrepresenting
a• computer, of data models
▪ Object-based
information (multi-dimensions)
such as record
▪ Record-based (2 dimensions)
structures,
▪ physical record ordering, and
access paths.
31
Variety of Data Models
• Object-Based Data Models Focus of
▪ Entity-Relationship
▪ Semantic
this subject
▪ Functional
▪ Object-Oriented (OODBMS, ORDBMS).
• Record-Based Data Models
▪ Relational Data Model
▪ Network Data Model
▪ Hierarchical Data Model
• Physical Data Models
▪ How data is stored - the info on record structures, record ordering, access
paths etc

32
 A semantic data model is an
Variety of Data Models abstraction which defines how the
stored symbols relate to the real
• Object-Based Data Models world. Thus, the model must be a
Focus of
▪ Entity-Relationship true representation of the real
▪ Semantic
this subject
world.
▪ Functional
▪ Object-Oriented
A function model is (OODBMS, ORDBMS).
a graphical
• Record-Based
representation Data
of an Models
enterprise's
▪ Relational Data Model
functions withinData
▪ Network a defined
Model scope
▪ Hierarchical
(to describe Data Modeland
the functions
• Physical Data Models
processes)
▪ How data is stored - the info on record structures, record ordering, access
paths etc

33
Network

Relational

Hierarchical 34
Concept of the Entity-Relationship Model
• Entity – can be objects with
▪ a physical existence, e.g. motor vehicle, animal, passport
▪ an abstract existence, e.g. a sale, a university course, a project
plan

Guest Room

Entities are represented in diagrams by rectangles…

35
Relationship
• Relationship – describes the association between entities
▪ E.g. for a relationship between a customer entity and a book
entity we say “a customer buys a book”, the relationship is “buys”
• (Binary) relationships are shown as a line connecting associated
entities, labelled with the name of the relationship.
• The ► symbol (an arrow) is used to indicate the direction that a
reader should use to interpret the relationship.

buys ►
Customer Book

36
Attributes
• An attribute is a property of an entity or a relationship type. E.g.
▪ Date of birth
▪ Blood type Employee
▪ Height
dateOfBirth
▪ Religious belief
bloodType
height
religiousBelief

• In the ER diagram, attributes are itemised inside the entity or

relationship rectangles
37
Multiplicities in a Relationship
• Show the maximum and minimum number of possible
occurrences of an entity type involved in a relationship
• One-to-one (1:1) book ►
• One-to-many (1:*) Guest Room
0..1 0..1
• Many-to-many (*:*) guestNo 0..1 1..* roomNo
• On both sides name 1..* 0..* hotelNo
▪ Left: minimum (0 or 1) çdateOfBirth ç
type
▪ Right: maximum (1 or *) address price

38
Keys in ER Modelling
• Candidate key – a set of minimum number of attributes that
uniquely identifies each occurrence of an entity type (p.415/381)
▪ An entity may have more than 1 candidate key.
• Primary key – the candidate key that is selected to uniquely
identify each occurrence of an entity type.
• Composite key – a candidate key that contains 2 or more attributes.
Guest book ► Room
guestNo {PK} 0..1 0..* roomNo {PK}
name hotelNo {PK}
ç ç
dateOfBirth type
address price
39
Relational Model Terminology –
Relation/Table
• A relation is a table with columns and rows
▪ Only applies to logical structure of the database, not the physical
structure
RelationName( attribute1, attribute2, … attributen)
Branch( branchNo, street, city, postcode)

40
Relational Model Terminology –
Attribute/Column
• An Attribute is a named column of a relation.
RelationName( attribute1, attribute2, … attributen)
Branch( branchNo, street, city, postcode)

41
Relational Model Terminology –
Tuple/Record/Row
• A Tuple is a row of a relation.
RelationName( attribute1, attribute2, … attributen)
Branch( branchNo, street, city, postcode)

42
Relational Keys Terminology – Primary Key
• Primary key is an attribute, or set of attributes, that
uniquely identifies a row in a relation
RelationName( attribute1, attribute2, … attributen)
Branch( branchNo, street, city, postcode)

43
Relational Keys Terminology – Foreign Key
• Foreign key is an attribute, or set of attributes,
within one relation that matches the candidate key
of some (possibly the same) attributes in another
relation
Staff(staffNo, fName, lName, position, sex, DOB, salary, branchNo)

Branch( branchNo, street, city, postcode)

44
ER Model vs Relational Model
ER Model Relational Model
---------------------------- ----------------------------
Entity Relation
Relationship Foreign key
Attributes Column
Constraints Constraints
Primary key Primary key

Conceptual Logical

45
ER Model vs Relational Model
ER Model Relational Model
---------------------------- ----------------------------
Entity Relation
Relationship Foreign key
Attributes Column
Constraints Constraints
Primary key Primary key

Conceptual Logical

46
SQL
PART C
SQL Basics
• SQL is case insensitive
• Each SQL statement should end with a semicolon
• SQL is operating on tables
• SQL is a programming language
• SQL has different versions and extensions

48
Data Type
Data type Description
char(n) Character string with fixed length n
varchar(n) Character string with variable length n
boolean True or False
integer Integer numerical with variable length 10
numeric(p,s) Exact numerical with precision p and scale s
date Date value year, month and day
more ……

49
Literals
• Literals are constants used in SQL statements.
• All non-numeric literals must be enclosed in single
quotes (e.g. 'London' ).
• All numeric literals must not be enclosed in quotes
(e.g. 650.00).

50
SELECT Statement
SELECT [ DISTINCT | ALL ]
{* | [columnNames [AS newName]] [,...] }
FROM TableName [alias] [, ...]
[ WHERE condition ] Do 1st

[ GROUP BY columnList ] Do 2nd

[ HAVING condition ] Do 3rd

[ ORDER BY columnList ] Do last

51
SELECT Statement
FROM Specifies table(s) to be used.
WHERE Specifies conditions to filter the rows.
GROUP BY Forms groups of rows with the same
column value/s.
HAVING Filters groups subject to some
condition.
SELECT Specifies which columns are to appear
in the output.
ORDER BY Specifies the order of the output
52
SELECT Statement
• Order of the clauses cannot be changed.
• Only SELECT and FROM are mandatory.
Can use * as an
abbreviation for ‘all
• SELECT * FROM Staff; columns’

• SELECT staffNo, fName, lName, address,

position, sex, DOB, salary, branchNo
FROM Staff;
53
 columnList is optional; if

SQL - Insert omitted, SQL assumes a list

of all columns in their original
CREATE TABLE order

INSERT INTO TableName [ (columnList) ]

VALUES (dataValueList);

INSERT INTO Staff

VALUES ('SG16', 'Alan', 'Brown', 'Assistant', 'M', NULL, 8300,
'B003');

INSERT INTO Branch (branchNo, street, city, postcode)

VALUES ('B005', '22 Deer Rd’, 'London', 'SW1 4EH');

54
SQL - Insert
• Any columns omitted may have to be declared as allowing
NULL when the table was created, unless a DEFAULT clause
was specified when creating column.
• dataValueList must match columnList as follows:
▪ The number of items in each list must be the same.
▪ Must be direct correspondence in position of items in two
lists.
▪ The data type of each item in dataValueList must be
compatible with the data type of corresponding column.

55
SQL - Delete
searchCondition is optional; if
omitted, all rows are deleted from
the table. This does not delete the
table. If search_condition is
specified, only those rows that
• DELETE FROM TableName satisfy the condition are deleted.
[WHERE searchCondition];
• DELETE FROM Staff
WHERE staffNo = 101;
• DELETE FROM Staff
WHERE staffNo = 101 AND lName = ‘Lee’;
• DELETE FROM Staff
WHERE staffNo = 101 OR lName = ‘Lee’;
56

SQL - Update
• UPDATE TableName
SET columnName1 = dataValue1
[, columnName2 = dataValue2...]
[ WHERE searchCondition ]
• UPDATE Staff
SET salary = salary*1.03;
• UPDATE Staff
SET position = 'Manager', salary = 18000
WHERE staffNo = 'SG14';
SET clause specifies
names of one or more
columns that are to be
updated
WHERE clause is optional: if
omitted, named columns are
updated for all rows in table. If
specified, only those rows that
satisfy searchCondition are
updated.
57
Reading

• Wiley – Chapter
3
• Pearson –
Chapters 2.3, 4,
6.1-6.3.2 and
7.1-7.2

58