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

& D ATA B A S E
MANAGEMENT
SYSTEMS
INFS7007

2
Recap
• Software Crisis
• System Development Life Cycle (SDLC)
• Database – What and Why
• SQL

2
Outline
• Planning Phase
• Feasibility Analysis
• Database environment
• Components of DBMS environment
• ANSI/SPARC 3 level architecture
• SQL

3
SYSTEMS
ANALYSIS
AND
DESIGN
PART A
Information Systems
• HOW to create a new information system?
▪ Systems Development Life Cycle (SDLC)
I. Planning
a. System Request Project
b. Feasibility Analysis Initiation
c. Project Workplan
d. Staffing Plan Project
e. Project Standards Management
f. Risk Assessment
II. Analysis
III. Design
IV. Implementation
V. Maintenance

5
Work Plan
• Fundamental process of understanding WHY an information
system should be built.
• Determines HOW the project team will go about building it.
• Two steps:
1. Project initiation -> system request -> feasibility analysis
2. Project management -> project plan

6
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?

7
Project Selection
• Why choose this project
1. Size: how big it is?
2. Cost: how much it will cost?
3. Purpose: what is the purpose?
4. Length: how long it will take?
5. Risk: how likely it will succeed or fail?
6. Scope: who will be affected?
7. Economic value: how much money expected?

8
Feasibility Analysis
• Is it feasible?
▪ Technical feasibility: do we have the background to do it?
▪ Economic feasibility: do we have enough resource, including
time, staff and so on to build it?
▪ Organizational feasibility: will this project benefit us?

9
Systems Development Life Cycle (SDLC)
• Almost all projects are
developed by using the
Systems Development Life
Cycle (SDLC). But there are
several variants.

10
SDLC Variants
• Which variant of the SDLC?
▪ Waterfall
▪ Parallel
▪ V-Model
▪ Iterative
▪ System prototyping
▪ Throwaway prototyping
▪ Agile Development
❖ It depends. See Figure 2-9 in the SAD textbook
11
12
13
Methodology Selection Criteria

14
Work Plan
• Dynamic schedule that records and track all of the tasks that
need to be accomplished
• Identify (sub)tasks
▪ Task name & scope: what is the task?
▪ Time frame: how long it will take?
▪ Staff: who will be involved in this task?
▪ Dependency: is this task based on previous ones?
▪ Status: what is the current status?

15
Project Staffing
• Who is involved?
• Which task is assigned to whom?
• Communication complexity
• 8 – 10
• Motivation -> performance
• Conflict -> cohesiveness

16
Project Management
• How to coordinate and manage the project?

Coordination Management Issues

CASE tool System size Estimation refinement

Standards Time New requirements

Documentation Cost Timeboxing

17
Risk Management
• How to minimise risk?
• Risk assessment
▪ Risk description
▪ Likelihood
▪ Potential impact
▪ Possible solutions
• Overly optimistic schedule: margins of error
• Failing to monitor the schedule: progress report
• Failing to update the schedule: timeboxing/version
• Adding people to late project: isolated subtasks

18
Planning Phase Summary

19
 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 -> File-based Info Systems are mostly
Obsolete … Why?
• Program-Data Dependence
All file-based programs maintain metadata for each file they use. A
change in a file’s data characteristics requires the modification of
the data access programs.
• File Structure Dependence
Changes in a file structure/format requires modifications on all the
related programs. A change in a file structure requires the
modification of all the related programs that use that file. Change of
data requires changing all related programs.

21
Program-Data Independence

• Recall: A database is not owned just by one organisational

department – it is usually shared by many departments.
• A database holds both the actual data and metadata (‘data
about data’).
• The metadata is the ‘system catalog’ or ‘data dictionary’.
• It is this self describing nature of the database that
provides program-data independence.

22
What are DBMS
A database management system (DBMS) is a
computer program (or more typically, a suite of
them) designed to manage a database, a large
set of structured data, and run operations on the
data requested by numerous users.

23
Advantages of DBMS
• Easier Sharing of data
• Control of data redundancy
• Improved data consistency
• Improved data standards (via rules …)
• Improved data security
• Improved data integrity (constraints)
• Balancing of conflicting requirements
• Faster development of new applications
24
Advantages of DBMS
• Better data accessibility for users (no need to go
through traditional IT department)
• Economy of scale (Horizontal/vertical)
• Improved control over concurrency
• Improved backup and recovery procedures
• Increased productivity
• Reduced maintenance costs through program-data
independence
25
Advantages of DBMS
• Better data accessibility for users (no need to go
through traditional IT department)
• Economy of scale (Horizontal/vertical)
• Improved control over concurrency
SCALABILITY
• Improved backup ◼Horizontal:
and recovery procedures
across different departments
◼Vertical: across different stages of project or
• Increased productivity
service development
• Reduced maintenance costs through program-data
independence
26
Disadvantages of DBMS
• High cost of DBMS
• Higher cost of Hardware (additional memory and
processing power)
• Higher Conversion Costs (when database is initially
implemented)
• Increased vulnerability (due to all data in central location)
• Complexity of DBMS
• Size of DBMS

27
Components of DBMS

28
Components of DBMS Environment
• Hardware
– Can range from a PC to a network of computers (single,
multi, central, distributed ..)
• Software
– DBMS, operating system, network software (if
necessary) and also the application programs
• Data
– Used by the organisation, and a description of this data
called the schema (structure of the database)
29
Components of DBMS Environment
continued…
• Procedures
– Instructions and rules that should be applied to the design
and use of the database and DBMS.
– E.g. how to: log on, use a particular appl. program,
start/stop database, handle failures
• People
– End users
– Data administrators, database administrators
– Other automated machine interfaces (Automated stock
monitoring services), etc …
30
People’s Roles in the Database Environment
• Data Administrators (DA)
• Database Administrators (DBA)
• Database Designers (Logical and Physical)
• Application Programmers
• End Users (naïve and sophisticated)

31
 DA is responsible for the management
People’s Roles in the Database
of the Environment
data resource including
database planning, development and
• Data Administrators (DA)maintenance of standards, policies
and procedures, and
• Database Administrators (DBA)
conceptual/logical database design.
• Database Designers (Logical and Physical)
Application
DBA• is responsibleProgrammers
for the physical
• End Users
realization (naïve
of the and sophisticated)
database, including
physical database design and
implementation, security and integrity
control, maintenance of the operating
system. (p.71) 32
 End Users Application Database
Naïve Programmers Administrator
Users Casual Users

Pre-written Interactive Programs written Commands to

Programs Query in Java, C++, RPG, create and
Language COBOL containing modify
calls to DBMS DB structure

Database Management System (DBMS)

Database (repository)
33
Basic Database Aspects
• Meta-data repository (data dictionary) - storage of all “data
about data” such as field names and formats, screen and
report formats, editing and other data integrity rules, etc.
• Data repository - actual storage facility of data entered into
the database
• Database interface - link between the data contained in the
database and the external world, which may be a human or a
computer program (e.g. ODBC – Open Database Connectivity)
• CASE tools (optional) - automatically generate the database
design
34
 D

ANSI-SPARC, 3 Level Architecture

A
T
A
B
ANSI - American National Standards Institute A
S
SPARC - Standards Planning and Requirements Committee E

E
• This conceptual architecture N
V
▪ provides a basis for understanding some of the functionality of a I
R
DBMS, and O
▪ emphasises the implementation-independent layers needed N
M
to separate application programs from the data. E
N
T

35
 DBA can change

ANSI-SPARC 3 Level Architecture conceptual structure of

database without
affecting all users.
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

mapping details, and aids the
separation/independence between
other two levels Logical structure of entire database

The way the operating

system and DBMS perceive
the data is the INTERNAL
level How data is organised

DB administrator should be able to change database

storage structure without affecting the user view. 36
Objectives of 3 Level Architecture… users
• All users should be able to access the same data.
• A user’s view is immune to changes made in other views.
• Users should not need to know physical database storage
details.

37
Objectives of 3 Level Architecture… DBA
• DBA should be able to change the database storage
structure without affecting the users’ views.
• Internal structure of a database should be unaffected by
the changes to physical aspects of storage.
• DBA should be able to change the conceptual structure of
a database without affecting all users.

38
3 Types of Schema
• Internal schemas at the internal level are to describe the data
storage structures and the access paths.
▪ Definition of stored records, methods of representation, data
fields, indexes and storage structures
• Conceptual schemas at the conceptual level are to describe the
structure and constraints for the whole database.
▪ Describe all entities, attributes, relationships, integrity
constraints
• External schemas at the external level are to describe the
various user views.

39
Which part of DB is
relevant to which user

What data is stored in the DB, and the relationships among the data

A physical
level exists
below the
internal level,
How the data is stored in the DB
and is
managed by
the operating
system
40 40
Differences Among 3 Levels of ANSI-SPARC
Architecture

maps to derived

41
Data Independence
• Logical Data Independence refers to the immunity of external
schemas to changes in the conceptual schema.
▪ Hence, any changes in conceptual schema (e.g. addition/removal
of entities) should not require changes to the external schema or
rewriting of the application programs.
▪ Logical model changes due to such as the addition of new record
types, new data items and new relationships should be possible
without affecting the existing external views.
▪ The users who requested such changes should be able to see
them, but other users, those not interested in the changes,
should not be affected.
42
Data Independence … continued
• Physical Data Independence refers to the immunity of
conceptual schema to changes in the internal schema.
▪ Changes in Internal schema (e.g. using different file
organisations, storage structures/devices) should not require
changes to the conceptual or external schemas.

43
SQL
PART C
Recall -> Structured Query Language (SQL)
• De facto standard programming language for relational
database
• Data Definition Language (DDL) - Create, Drop, Alter, Rename,
Truncate
• Data Manipulation Language (DML) - Insert, Update, Delete,
Merge
• Query Language - Select
• Data Control Language (DCL)
• Transaction Control
• Procedure & Function
45
SQL - Create
Square brackets [ ]
CREATE TABLE TableName ( indicate optional
field1_name data_type [ constraint ], terms

field2_name data_type [ constraint ],

more of the same …
PRIMARY KEY (attrib_p1 [, attrib_p2 ...]),
FOREIGN KEY (attrib_f1 [, attrib_f2 ...])
REFERENCES foreignTableName,
more of the same …
);
46
 SQL - Create
CREATE TABLE Student ( CREATE TABLE Student (
studentNo numeric(8), studentNo numeric(8) PRIMARY KEY,
firstName varchar(20) NOT NULL, firstName varchar(20) NOT NULL,
lastName varchar(20) NOT NULL, lastName varchar(20) NOT NULL,
address varchar(30), address varchar(30)
PRIMARY KEY (studentNo) );
);

47
SQL - Drop
DROP TABLE TableName;

DROP TABLE Student;

48
Conventions at Creating Table Structures
• Use one line per column (attribute) for definition.
• Use spaces to line up the attribute characteristics and constraints.
• Table names are often initiated with capitals.
• Use NOT NULL specification if needed.
• Primary key attributes contain a NOT NULL specification implicitly.
• RDBMS will automatically enforce referential integrity for foreign
keys.
• Command sequence ends with a semicolon.

49
Reading

• Wiley –
Chapters 1 and
2
• Pearson –
Chapters 1, 2,
7.3.2 and 7.3.4

50