Chapter Four: System Design

System Design involves tasks focusing on the specification of a detailed computer based
solution: also called physical design to differentiate from data modeling, which is
basically a logical design.

System analysis emphasized the business-problem while system design focuses on the
Solution (technical or implementation) concerns of the new system.

System design transform results of analysis to a certain design model, accordingly:

DFD input to Architectural Design

E-R / data model input to Database Design

System requirement
Specification (SRS) input to interface design

Deliverables: architectural design, database design and interface designs.

 Architectural design: representation of the architecture of a software system.
o The common tool used here is system structure chart (SSC) which is a
hierarchical diagram that shows how an information system is organized
(Read more about SSC)
o It is basically transformation of DFDs into a more procedural way.
 Database Design: transformation of E-R diagrams and data requirement from
interfaces of reports and the like into database i.e. structure the data in stable
structure, called normalized tables/ relations
• Having minimal redundancy
• Not likely to change over time.
o The data objects and relationships defined in the E-R diagram and detailed
data content depicted in the data dictionary provide the basis for the
database design activity.
 Interface Design:- refers to the concept of designing how the software
communicates within itself (with systems that interoperate with it), and with
humans who use it.
o An interface implies flow of information and a specific type of behavior.

Types of Design: Logical and physical Design

The design phase can be broadly classified into logical and physical designs.
 Logical design; a stage where the “look and feel” of all system inputs, outputs
and interfaces and dialogues are defined.
o Broadly speaking, it specifies means to capture inputs, give output and the
interaction between users and the system, and how data should be
organized and stored.
o Specifically,
• Designing forms and reports (the inputs & outputs)
• Designing interfaces and dialogues: the interaction
• Designing logical database (structure of the database) this is the
1
 conceptual data modeling
Note: the above design list need not necessarily be sequentially performed.

 Physical Design (Architectural Design): designing the system and program

structure.
 That means, translating (transforming) the process and logic in DFD (that
was depicted in the logic modeling) into a form that can directly be used
by programmers.
 Important relationship between physical design and earlier stages (phases)
o Every function / process in DFDs must be transformed into program and
program module.
o Programs will accept or produce data through the forms and reports.

Deliverables (outcomes) of System Design Phase

 Database Design
o Data base and file design occurs in two steps:
i. Developing logical database model: describe organization used by a DBMs
(database management System) – like Ms Access, Oracle, or SQL server,
the most common is a relational database model. Logical database design is
derived not only from E-R models, but also from forms and report layouts
of the system.
ii. Physical database design activities include transformation of the logical
database model into a format suitable for the selected DBMs and specify
computer programmers, database administrators, network managers, and
others on how to implement the new information system.
As mentioned above, database design is transforming an E-R model and the data
specifications design into a normalized relation(table).

A relation is a named, two-dimensional table of data, having set of named columns and
an arbitrary number of unnamed rows,

Each column in a relation corresponds to an attribute of that relation and each row of a
relation corresponds to a records that contains data values for an entity.

Well-structured relation corresponds to a records that contain a minimum amount of

redundancy and allows users to insert, modify and delete the rows without errors or
inconsistencies.

It is the process of converting complex data structures into simple, stable data structures
using a process called normalization.

Normalization: performed based on well-accepted principles and rules, There are three
steps of normalization.

Un normalized => (1st Normal Form) => (2nd Normal Form) => (3rd Normal Form)

2
The result of normalizations is that every no primary key attribute depends upon the
whole primary key and nothing but the primary

Normalization is based on the analysis of functional dependence.

Functional dependency and primary keys

Functional dependency is a relationship between two attributes, in a given relation,

attribute B is functionally dependent on attribute A if, for every valid value of A, that
value of A uniquely determines the value of B.
Example: you can express the structure of a relation by the following shorthand:
EMPLOYEE1 (Emp-ID, Name, Dept, Salary)

EMPLOYEE 1 (with sample data)

Emp-ID Name Dept Salary

100 Margaret Simpson Marketing 42,000
140 Allen Beeton Accounting 39,000
110 Chris Lucero Inf. Systems 41,500
190 Lorenzo Davis Finance 38,000

The functional dependence of B on A is a represented by an arrow as: A => B

(eg. Emp- ID => Name : - for a given Emp-ID value, there can be only one Name
value associated with it).

Consider the following relation (EMPLOYEE 2) that contains data about employees and
the courses they have completed.

EMPLOYEE 2
Emp-ID Name Dept Salary Course Date_ Completed
100 Margaret Simpson Marketing 42,000 CCNA 6/19/2002
100 Margaret Simpson Marketing 42,000 Core Java 10/7/2002
110 Chris Lucero Inf. Systems 41,500 CCNA 1/22/2002
110 Chris L. Finance 41,500 C++ 4/22/2002
190 Lorenzo Davis Finance 38,000 Core Java 5/7/2002
150 Susan M. Marketing 38,500 CCNA 6/19/2002
150 Susan M. Marketing 38,500 E-Business 8/12/2002

Notice the redundancy in EMPLOYEE 2, where Emp-ID, Name, Dept, and salary values
for employees 100,110 and 150 appear in we must record this fact in two rows.

The problem with this relation is that it contains data about two entities: EMPLOYEE
and COURSE

In normalization, we divide EMPLOYE 2 into two relations, EMPLOYEE 1 (above) and

the following EMP_COURSE relation having a primary key combining Emp-ID and
Course.

3
EMP_COURSE

Emp-ID Course Date _ completed

100 CCNA 6/19/2002
100 Core Java 10/7/2002
110 CCNA 1/22/2002
110 C++ 4/22/2002
190 Core Java 5/7/2002
150 CCNA 6/19/2002
150 E-Business 8/12/2002
An attribute may be functionally dependent on two (or more) attributes, rather than on a
single attribute,

Example, (Emp-ID, course) => Date_completed. In this case, Date_completed cannot

be determined by either Emp-ID or Course alone, because the
Date_completed is characteristic of an employee taking a course.

To get 1st Normal form:

Remove all repeating groups
Identify primary keys
i.e. breaking or dividing the relation into two or more (like the case from Employee2 to
EMPLOYEE1 and EMP_COURSE)

Second Normal Form (2NF)

A relation is in 2NF if every no primary key attribute is functionally dependent on the
whole primary key, i.e. not on part, but on fullest of the primary key,
Remove partial dependencies to get 2NF relation.

A 2NF is satisfied if any one of the following conditions apply.

1. The primary key consists of only one attribute
2. Every non primary key attribute is functionally dependent on the full set of
primary key attributes.

Third Normal form (3NF)

 A relation is in 3NF if it is in 2NF and there are no functional dependencies
between two (or more) non primary key attributes. (a functional dependency
between non primary key attributes is also called a transitive dependency).
 Consider the following TREATMENT Relation.

Patient-ID Patient_Name Physician Ward

1570 Anderson Hicks ICU
1575 Simith Paul IPD
1460 Arnold Hicks ICU
1589 John Mark Medical
1560 Mike Paul IPD

 TREATMENT relation is its 2NF because it has only one primary key attribute.
 The following functional dependencies exist in the above relation
1. Patient_ID, Patient_Name, Physician, Ward (Patient_Id is the primary key)

4
 2. Physician => Ward (each physician is assigned to a unique ward) this is
transitive dependency.

 A relation like the above create data maintenance problems and need to be changed
into 3NF.
 To change TREATMENT relation it into 3NF, decompose it into two relations, based
on Patient_ID and physician as:

TREATMENT1 (Patient_ID, Patient_Name, Physician)

PHYSICIAN (Physician, ward)

 Physician is a foreign key in the treatment relation,

 A foreign key is an attribute that appears as a non-primary key attribute in one
relation and as a primary key attribute (or part of a primary key) in another relation.

Sometimes, you may not need to go through all the steps of normalization, i.e. a relation
may already be in the 3NF at the 1st step.

Transforming E-R Diagrams into Relations (Tables)

o Future information need of the system (the relations in the database) are derived
both from system input output interfaces and the E-R diagrams developed during
conceptual data modeling
o Transforming an E-R diagram into normalized relations and then merging all the
relations into one final, consolidated set of relations can be accomplished in four
steps.
1. Represent Entities: each entity type in the E-R diagram becomes a relation, the
identifier of the entity becomes primary key of the relation, and other attributes of
the entity become non primary key attributes of the relation.
2. Represent relationships; each relationship in an E-R diagram must be represented
in the relational database design, this may be by using foreign keys or by creating
a separate relation to represent a relationship.
3. Normalize the relations: remove unnecessary redundancy from relations created
in steps 1 and 2 using normalization
4. Merge the relations; all the relations created so far are gathered from sources like
E-R diagrams and user views, etc. so, there may be redundant relations (two or
more relations about the same entity type) that must be merged and renormalized

Representing relationships of E-R diagrams

 1 : 1 (One to one) cardinality

o The primary key attribute of any one of the relations (tables) will be
moved as a foreign key attribute in any of the other relation (table)
 1 : n (One to many) cardinality
o The primary key attribute of the relation in the many side, will be taken
as a foreign key attribute to the relation in the many side
 n : n (Many to many) cardinality
o A new relation will be created and both primary key attributes of two
tables will be moved to this new relation, and both will be taken as a
composite primary key attribute.

5
Physical Database Design

 The tasks we saw so far are activities of logical database design.

 Physical database design involves the following activities
o Designing fields of tables: choosing the data types, set calculated (or
computed or derived) fields, setting default values, range controls, etc.
o Designing physical tables in the database.
 Activities here take into account the technology required in processing, accessing
etc.
Interface Design

o A good human computer interface provides a unifying structure for finding,

viewing and invoking the different components of a system.
o Interface design is basically
o User focused activity
o Employs (user) prototyping methodology
o Interface may be designed to allow:
o Command based interactions
o Menu based interaction
o Object-based interaction: icons, symbols
o Natural language interaction

These are the means or methods by which users interact with the system.
o Points to be considered in designing interfaces;

o Flexibility: users should be able to move freely between fields

o Consistency
o Reduce data entry errors by structuring the data entry. Like by providing default
values, making clear the type of data of units required for entry.
o Providing feedback, like status information to tell the user what is going on, error
and warning messages.
o Designing help: general and context sensitive help
o Use simple grammatically correct sentences (forms) and be consistent with user
terminology.