Chapter Four

System design

1
 Objectives
 At the end of this lesson students will be able to:
 Define System design
 List the deliverables under system design
 Define Logical data Modeling
 Explain the Steps to produce logical data model
 Explain the three stages of normalization
 Transform E-R diagram in to relational model

2
 Introduction
 Systems Design is the third phase in the systems development life
cycle in which specifications that would allow initial deployment
are provided
 The Design phase of the SDLC includes steps to design the interfaces
to the system and the database for the system.
 In this lesson, the E-R models produced during Analysis are used to
produce the database design.
 Deliverables for the Design phase of the SDLC are both logical and
physical database designs and interface design

3
 Logical database design
 It is the specifications of what must the database include with out
considering how we are going to include them and its purposes are:
 To structure the data in stable structures that are not likely to change
over time and that have minimal redundancy
 To develop a database that reflects the actual data requirements of the
system (as seen in the forms and reports of the system – the database
design is often carried out in parallel with the interface design for this
reason)

4
 Purposes cont…
 To develop a logical data design from which the physical database
design can be derived. Most systems today use RDBMS (Relational
Database Management Systems), so this usually involves building a
relational model
 To translate a relational database into a technical file and database
design

5
 Steps to produce logical data model
 Develop a logical data model for each known user
interface (forms and reports) in the application, using
normalization principles.
 Combine the normalised data requirements from all user
interfaces into one consolidated model
 Translate the E-R data model for the application into
normalised data requirements

6
 Steps to produce logical data model
 Combine the translated E-R model with the consolidated
data model created from the user interfaces to produce
one final logical database model for the application (as
there may be duplication between the models produced
from the E-R model and the user interfaces)

7
 Review of the Relational Database
Model
 Attributes of the entity type= columns
 DataValues for a single entity= rows

EmpID Name Department Salary

100 Sara Negash Information Technology 100000
101 Andy King Administration 100000
102 Terri O'Sullivan Finance 90000
103 Tekle Haimanot Information Technology 88000
105 Terhas GebreSelassie Marketing 120000
 Employee ( EmpID, Name, Department, Salary)

8
 What is a relation table
 cells/tuples of the table are simple /atomicity
 column are from the same set of values /domain or data type.
The values in a column could also have rules
 Each row is unique. The uniqueness is guaranteed because each row
has a non-empty primary key value.

9
 Normalization
 It is the Removing of the data redundancy
 Why normalization?
 allows users to insert, update and delete the rows in a table without
errors or inconsistencies.
 There are stages of normalization

10
 First Normal Form (1NF)

11
  What is wrong with the above table?
 What if the salary for Emp_ID 100 changes?
 What is the primary key for the above table?
 What partial dependencies are there on the key and non-Key
attributes of the above table?

12
 EMPLOYEE1
Emp_ID Name Department Salar Cour Date_Compl
y se eted
100 Sara Negash Information Technology 100000 C++ 30/11/2003
100 Sara Negash Information Technology 100000 Report 15/10/2003
Writing
101 Andy King Administration 800000 Report 20/6/2003
Writing
102 Terri O'Sullivan Finance 90000 Report 20/6/2003
Writing
102 Terri O'Sullivan Finance 90000 Investm 15/7/2003
ents
103 Tekle Haimanot Information Technology 88000 Investm 15/7/2003
ents
105 Terhas Girma Marketing 120000 Surveys 30/8/2003
105 Terhas Girma Marketing 120000 Survey 10/9/2003
Analysi
s
13 Second normal form
 Second Normal Form (2NF)
 Functional dependency:
 Is a relationship between two attributes.
If a particular value of one attribute (A) in a relation uniquely determines
the value of another attribute (B) in the same relation, then there is a
functional dependency between attributes A and B.
If we know the value of A, then we can determine a unique value for B. In
this case, B is functionally dependent on A.

Can be denoted A  B. Or, in other words, A determines B.

Are there any Functional dependencies?

14
  A relation is in second normal form (2NF) if every non-
primary-key attribute is functionally dependent on the
whole primary key.

 Emp_ID  Name,Department,Salary
 Emp_ID,Course  Date_Completed
 EMPLOYEE (Emp_ID, Name, Department, Salary)
 EMP_COURSE (Emp_ID, Course, Date_Completed)

15
 EMPLOYEE

Emp_ID Name Department Salary

100 Sara Negash Information Technology 100000
100 Sara Negash Information Technology 100000
101 Andy King Administration 100000
102 Terri O'Sullivan Finance 90000
102 Terri O'Sullivan Finance 90000
103 Tekle Haimanot Information Technology 88000
105 Terhas Girma Marketing 120000
105 Terhas Girma Marketing 120000
16
 EMP_COURSE
Course Date_Complet
Emp_ID ed
100 C++ 30/11/2003
100 Report 15/10/2003
Writing
101 Report 20/6/2003
Writing
102 Report 20/6/2003
Writing
102 Investment 15/7/2003
s
103 Investment 15/7/2003
s
105 Surveys 30/8/2003
106 Survey 10/9/2003
Analysis
17
 Third Normal Form (3NF)
 Take for example, a relation named VEHICLE, where the
Registration_No is the primary key:
VEHICLE (Registration_No, Owner, Model, Manufacturer, Engine_Size)
 Is there any functional dependency between non primary key
attributes?

18
  Model Manufacturer, Engine_Size
 VEHICLE1 (Model, Manufacturer, Engine_Size)
 REGISTRATION (Registration_No, Owner, Model)

19
 Foreign Keys & Referential
Integrity
 REGISTRATION (Registration_No, Owner, Model)
 A foreign key must satisfy referential integrity
 in our example, the values of Model in the REGISTRATION relation
must be a value that exists in the Model attribute in the VEHICLE1
relation.
 Referential integrity is important principle of relational model.

20
 Transforming E-R Diagrams into
Relations

21
 Steps
1. Represent entities
2. Represent relationships
3. Normalize the relations
4. Merge the relations

22
 Transforming cont…
 initial relations
 COMPUTER (ComputerID, Name, Location)
 STAFF (StaffID, Name, FathersName)

23
 Transforming cont…

24
 Transforming cont…
 To start with
 EMPLOYEE (Emp_ID, Name, FathersName, Salary)
 DEPARTMENT (Dept_ID, Name)
 PROJECT (ProjectID, Name)

25
 Binary 1-to-Many Relationships
 EMPLOYEE (Emp_ID, Name, FathersName, Salary, Dept_ID)
 DEPARTMENT (Dept_ID, Name)
 PROJECT (ProjectID, Name)

26
 Binary 1-to-1 Relationship
 EMPLOYEE (Emp_ID, Name, FathersName, Salary, Dept_ID)
 DEPARTMENT (Dept_ID, Name, Manager_Emp_ID)
 PROJECT (ProjectID, Name)

27
 Unary 1-to-1 Relationship?

28
 Binary and Higher Degree
Many-to-Many Relationships
 Look the Works_on relationship between EMPLOYEE and PROJECT,
we add a new relation, EMPLOYEE_PROJECT:
 EMPLOYEE (Emp_ID, Name, FathersName, Salary, Dept_ID)
 DEPARTMENT (Dept_ID, Name, Manager_Emp_ID)
 PROJECT (ProjectID, Name)
 EMPLOYEE_PROJECT (Emp_ID, ProjectID)

29
 Many- to- Many with associative entity
 COMPUTER (ComputerID, Name, Location)
 STAFF (StaffID, Name, FathersName)
 OPERATING_SYSTEM (ComputerID, OpSys_Name)
 MAINTENANCE (MaintenanceID, ComputerID, StaffID,
MaintenanceDate, Notes)

30
 Unary 1-to-Many

 EMPLOYEE (Emp_ID, Name, FathersName, Salary, Manager_EmpID)

31
 Unary Many-to-Many Relationships

 ITEM (Item_Number, Name, Cost)

 ITE_BILL (Item_Number, Component_Number, Quantity)

32
 User Interface Design

33
 Introduction
 Systems Design is the third of five phases in the systems development
life cycle
• Now you will work on a physical design that will meet the
specifications described in the system requirements document
• Tasks will include user interface design, data design, and system
architecture
• Deliverable is system design specification

34
 Introduction
• User interface (UI) Consists of all the hardware, software, screens,
menus, functions, outputs, and features that affect two-way
communications between the user and the computer
• User interface design is the first task in the systems design phase of
the SDLC
• Designing the interface is extremely important, because everyone
wants a system that is easy to learn and use

35
 Evolution of the User Interface
– As information management evolved from centralized data
processing to dynamic, enterprise-wide systems, the primary focus
of UI also shifted — from the IT department to the users themselves
– User-centered system Requires an understanding of human-
computer interaction & user-centered design principles

36
 Human-computer interaction (HCI)
• Human-computer interaction (HCI) describes the
relationship between computers and people who
use them to perform their jobs
• Graphical user interface (GUI)
– Main objective is to create a user-friendly design that is easy to learn
and use
 What are the users Rights on this era?

37
 3.1 User-centred approach

Use a User-centred design approach

Three key principles:
- Early and continuous focus on users and their tasks
- Empirically measure user behaviours
- Use prototypes to observe behaviour
- Design iteratively

38
 3.2 Ben Shneiderman’s 8 Golden Rules

The following guidelines are Ben

Shneiderman’s 8 Golden Rules for
Interface Design

[Link]
m/6-tips-for-a-great-flex-ux-part-5

[Link]
/projects/ui_design.html

39
 3.2 Golden Rules – Rule 1

1. Strive for consistency

 Consistency refers:
 to the way information is
arranged on forms
 the names, and arrangement of
menu items
 the size and shape of icons
 and the sequence followed to
execute tasks should be
consistent throughout the
system

 Inconsistency in interface results

 Longer time to learn
 Will be harder for users to
40 remember
 3.2 Golden Rules – Rule 1
Inconsistent examples

41
 3.2 Golden Rules – Rule 1

Inconsistent examples

42
 3.2 Golden Rules – Rule 1

Consistency example - Windows

Windows consistent menus – File, Edit, View

Even for new applications user knows where

to go to load and save files, cut and paste,
change view, etc.
43
 3.2 Golden Rules – Rule 2

2. Cater for diverse users

Eg. Offer experienced, frequent users shortcuts

44
 3.2 Golden Rules – Rule 3

3. Offer informative feedback

 Inform user that their actions
was received
 Include feedback when
something is complete
 Make sure that the feedback is:
 Informative
 Clear
 Concise

45
 3.2 Golden Rules – Rule 3

Feedback examples

46
 3.2 Golden Rules – Rule 4

4. Design dialogues that yield closure

 Organise sequences of actions:
 Beginning
 Middle
 End

 Ensure that users know when a

conversation or task is at end:
 Users should know when a task
is completed

47
 3.2 Golden Rules – Rule 5

5. Prevent errors
Message types
 Error messages: alerts users of a
problem that has already occurred.
 Warning: alerts users of a
condition that might cause a problem in
the future.
 Information: highlights a
statement or fact
Effective error messages:
 Inform users that a problem occurred
 Explain why it happened
and provide a solution so users
can fix the problem
48
 3.2 Golden Rules – Rule 5
Characteristics of poor error messages

 Unnecessary error
messages

 Meaningless message - users

learn that there is an error but:
 has no idea what it is
 or what to do about it

49
 3.2 Golden Rules – Rule 5

Characteristics of poor error messages

 Incomprehensible error
messages

50
 3.2 Golden Rules – Rule 5

Characteristics of poor error messages

Incorrect error
message

 Irrelevant issues in problem

statement

Correct error message

A better way:
The program can determine if access was
denied, so this problem should be reported with
a specific error message.

51
 3.2 Golden Rules – Rule 5

Characteristics of poor error message

 Avoid over-communicating Incorrect error
 Generally, users don't read, they message
scan
 reduce the text down to its
essentials
 Should not require motivation to
read
Correct error message
A better way:
The program can determine if access was
denied, so this problem should be reported
with a specific error message.
52
 3.2 Golden Rules – Rule 5

User input errors

Example 1: Incorrect input
(No control)
 Whenever possible, prevent
or reduce user input errors
by:
 Using controls that are
constrained to valid values
 Providing good format examples
Example 2: Incorrect input

 Use balloons for non-critical, single-

point user input problems detected
while in a text box.
– If error message placed immediately
after the text box difficult to see.

53
 3.2 Golden Rules – Rule 5

User input errors

 Use in-place errors for
delayed error detection
 There can be multiple in-
place errors at a time

54
 3.2 Golden Rules – Rule 5

The use of sound and text in error messages

Incorrect error message

 Sound
 Generally, error messages
should not be accompanied with
a sound effect or beep
 Doing so is jarring and
unnecessary
Correct error message

 Text
 Remove any redundant text
 Avoid technical jargon
55
 3.2 Golden Rules – Rule 5

The use of text in error messages

Example: Inappropriate error message
 When designing error messages,
use an ENCOURAGING tone
 Avoid using the following words:
 Error, failure
.. use problem
 Failed to Example: More appropriate error
message
.. use unable to
 Illegal, invalid, bad
.. use incorrect
 Abort, kill, terminate
.. use stop
56
 Catastrophic, fatal
 3.2 Golden Rules – Rule 5

The use of text in error messages

Example: Inappropriate error message – it
blames the user by using the active voice
 Don't use phrasing that blames the
user

 Avoid using you and your in the

phrasing.

Example: Appropriate error message

 Use the passive voice when the user
is the subject

57
 3.2 Golden Rules – Rule 6

6. Permit easy reversal of actions

 Users need to feel that they can cancel or reverse an action
 Provide tools for reversal of their actions – buttons or menu bar
options

58
 3.2 Golden Rules – Rule 7

7. Reduce short-term memory load

Humans have limited capacity for processing info in short-term memory

 7 +/- 2 chunks of information, 20-30 seconds

 Avoid interfaces where users have to remember information from one

screen to the next

59
 3.2 Golden Rules – Rule 7

Short-term memory: Implications for UI design

• Change the colour of visited links so you know where you’ve been

60
 3.2 Golden Rules – Rule 8

8. Support internal locus of control

 Experienced users want to be in
charge while interacting with the
system
 They do not like:
 Tedious data entry
 Surprising system actions
 No help messages
 Complex error message
 Being forced to remember

61
 Chapter end

62