Systems Analysis And Design

Chapter Four: Systems Design

• Information 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
technical or implementation concerns of the
new system
 Designing Forms and Reports
• A form is a business document containing
some predefined data and often includes
some areas where additional data are to be
filled in
• Examples of business forms are product order
forms, employment applications, and class
registration sheets
• A report is a business document containing
only predefined data; it is a passive document
used solely for reading or viewing
• Examples of reports are invoices, weekly sales
summaries by region and salesperson, and a
pie chart of population by age categories
• Gaining an understanding of questions listed
below is a required first step in the creation of any
form or report
1. Who will use the form or report?
2. What is the purpose of the form or report?
3. When is the form or report needed and used?
4. Where does the form or report need to be delivered
and used?
5. How many people need to use or view the form or
report?
• Design specifications are the major
deliverables of designing forms and reports
and are inputs to the system implementation
and operation phase.
• Design specifications have three sections:
1. Narrative overview
2. Sample design
3. Testing and usability assessment
Narrative Overview
• The narrative overview provides a general
overview of the characteristics of the target
users, tasks, system, and environmental factors
in which the form or report will be used
• Its purpose is to explain to those who will
actually develop the final form, why this form
exists, and how it will be used so that they can
make the appropriate implementation decisions
Sample Design
• The sample design presents the look and feel
of the actual form or report using some
standard development tools.
Testing and usability assessment
• Here the focus is on assessment of the forms
and reports using different parameters like
consistency, accuracy and the like.
Designing Interfaces and Dialogues
• Interface and dialogue design focuses on how
information is provided to and captured from
users
• The grammatical rules followed by each person
during a conversation are analogous to the
human-computer interface
• A good human-computer interface provides a
uniform structure for finding, viewing, and
invoking the different components of a system
• Similar to designing forms and reports, the
process of designing interfaces and dialogues
is a user-focused activity
• You follow a prototyping methodology of
iteratively collecting information, constructing
a prototype, assessing usability, and making
refinements
 Designing Interfaces
1. Designing Layouts
To ease user training and data recording, use
standard formats for computer-based forms
and reports similar to paper-based forms and
reports for recording or reporting information

A typical paper-based form and its computer-

based counterpart are shown in the next slide
2. Structuring Data Entry
– You should consider several guidelines when
structuring data-entry fields on a form
– See the guidelines for structuring data entry in
the next slide
3. Controlling Data Input
• One objective of interface design is to reduce data-entry
errors
• As data are entered into an information system, steps
must be taken to ensure that the input is valid
• Systems analysts are expected to anticipate the types of
errors users may make and design features into the
system’s interfaces to avoid, detect, and correct data-
entry mistakes
• See the guideline for detecting data errors in the next
slide
 Designing Dialogues
• The process of designing the overall
sequences that users follow to interact with
an information system is called dialogue
design
• A dialogue is the sequence in which
information is displayed to and obtained from
a user
• The primary design guideline for designing
dialogues is consistency; dialogues need to be
consistent in sequence of actions, keystrokes,
and terminology
• In other words, use the same labels for the
same operations on all screens and the same
location of the same information on all
displays.
 Designing the Dialogue Sequence
• Your first step in dialogue design is to define
the sequence.
• A method for designing and representing
dialogues is dialogue diagramming.
• Dialogue diagrams have only one symbol, a
box with three sections; each box represents
one display (which might be a full screen or a
specific form or window) within a dialogue
• The three sections of the box are used as follows
1. Top: Contains a unique display reference number
used by other displays for referencing it
2. Middle: Contains the name or description of the
display
3. Bottom: Contains display reference numbers that
can be accessed from the current display
• See the example in the next slide
31
33
 Deliverables and Outcomes
• Logical database is the representation of
data using a model like relational database
model, which represents data in simple
tables with common columns to link related
tables.
• Physical database is the representation of
relations into files

34
 Process of Database Design
 Logical Design
› Four key steps:
1. Develop a logical data model for each known user interface
for the application using normalization principles
2. Combine normalized data requirements from all user
interfaces into one consolidated logical database model
3. Translate the conceptual E-R data model for the application
into normalized data requirements
4. Compare the consolidated logical database design with the
translated E-R model and produce one final logical database
model for the application

35
 Process of Database Design
 Physical Design
› Based upon results of logical database design
› Key decisions:
1. Choosing storage format for each attribute from the logical
database model
2. Grouping attributes from the logical database model into
physical records
3. Arranging related records in secondary memory (hard disks
and magnetic tapes) so that records can be stored,
retrieved, and updated rapidly
4. Selecting media and structures for storing data to make
access more efficient

36
 Relational Database Model
 Data represented as a set of related tables or relations
 Relation
› A named, two-dimensional table of data. Each
relation consists of a set of named columns and an
arbitrary number of unnamed rows
› Properties
 Entries in cells are simple
 Entries in columns are from the same set of values
 Each row is unique
 The sequence of columns can be interchanged without
changing the meaning or use of the relation
 The rows may be interchanged or stored in any sequence

37
 Relational Database Model

• Well-Structured Relation
– A relation that contains a minimum amount of
redundancy and allows users to insert, modify,
and delete the rows without errors or
inconsistencies

38
 Normalization

 The process of converting complex data

structures into simple, stable data structures
 Eliminates redundancy

39
 Normalization
• Second Normal Form (2NF)
– Each non-primary key attribute is identified by the whole key (called
full functional dependency)
• Third Normal Form (3NF)
– Non-primary key attributes do not depend on each other (called
transitive dependencies)
• The result of normalization is that every non-
primary key attribute depends upon the whole
primary key and nothing but the primary key.

40
 Functional Dependencies and
Primary Keys

• Functional Dependency
– A particular relationship between two attributes. For 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.
– Instances (or sample data) in a relation do not prove the
existence of a functional dependency
– Knowledge of problem domain is the most reliable method
for identifying functional dependency

41
 Functional Dependencies and
Primary Keys

• Second Normal Form (2NF)

– A relation is in second normal form (2NF) if any
of the following conditions apply:
1. The primary key consists of only one attribute
2. No non-primary key attribute exists in the relation
3. Every non-primary key attribute is functionally
dependent on the full set of primary key attributes

42
 Functional Dependencies and
Primary Keys

• Conversion to second normal form (2NF)

– To convert a relation into 2NF, decompose the
relation into new relations using the attributes
called determinants that determine other
attributes
– The determinants become the primary key of the
new relation

43
 Functional Dependencies and
Primary Keys
• EMPLOYEE2 below is an example of a relation
that is not in second normal form.
– EMPLOYEE2(Emp_ID, Name, Dept, Salary, Course,
Date_Completed)
• The functional dependencies in this relation
are the following:
– Emp_ID:Name, Dept, Salary
– Emp_ID, Course:Date_Completed

44
 Functional Dependencies and
Primary Keys
• EMPLOYEE2 is decomposed into the following
two relations:
– EMPLOYEE1(Emp_ID, Name, Dept, Salary)
– EMP_COURSE(Emp_ID, Course, Date_Completed)

45
 Functional Dependencies and
Primary Keys

• Third Normal Form (3NF)

– A relation is in third normal form (3NF) if it is in
second normal form (2NF) and there are no
functional (transitive) dependencies between two
(or more) non-primary key attributes
– To convert a relation into 3NF, decompose the
relation into two relations using the two
determinants

46
 Functional Dependencies and
Primary Keys
• Consider the relation below:
– SALES(Customer_ID, Customer_Name, Salesperson,
Region)
• The following functional dependencies exist in
the SALES relation where Customer_ID is the
primary key :
– Customer_ID:Customer_Name, Salesperson, Region
– Salesperson:Region (Each salesperson is assigned to
a unique region.)

47
 Functional Dependencies and
Primary Keys
• SALES relation is decomposed into two
relations to convert it into 3NF as follows:
– SALES1(Customer_ID, Customer_Name,
Salesperson)
– SPERSON(Salesperson, Region)

48
49
 Functional Dependencies and
Primary Keys

• Foreign Key
– An attribute that appears as a nonprimary key attribute in
one relation and as a primary key attribute (or part of a
primary key) in another relation
• Referential Integrity
– An integrity constraint specifying that the value (or
existence) of an attribute in one relation depends on the
value (or existence) of the same attribute in another
relation

50
 Transforming E-R Diagrams into Relations

• It is useful to transform the conceptual data

model into a set of normalized relations
• Steps:
– Represent entities
– Represent relationships
– Normalize the relations
– Merge the relations

51
 Transforming E-R Diagrams into Relations

1. Represent Entities
– Each regular entity is transformed into a relation
– The identifier of the entity type becomes the primary
key of the corresponding relation
– The primary key must satisfy the following two
conditions
a. The value of the key must uniquely identify every row in the
relation
b. The key should be non-redundant

52
53
 Transforming E-R Diagrams into Relations
2. Represent Relationships
– Binary 1:N and 1:1 Relationships
• A binary one-to-many (1:N) relationship in an E-R diagram
is represented by adding the primary key attribute (or
attributes) of the entity on the one side of the relationship
as a foreign key in the relation that is on the many side of
the relationship.
• For a binary or unary one-to-one (1:1) relationship
between the two entities A and B (for a unary relationship,
A and B would be the same entity type), the relationship
can be represented by any of the following choices:
1. Adding the primary key of A as a foreign key of B
2. Adding the primary key of B as a foreign key of A
3. Both of the above
54
55
 Transforming E-R Diagrams into Relations

2. Represent Relationships (continued)

– Binary and Higher-Degree M:N Relationships
• Suppose that a binary many-to-many (M:N)
relationship (or associative entity) exists
between two entity types A and B. For such a
relationship, we create a separate relation C.
The primary key of this relation is a composite
key consisting of the primary key for each of the
two entities in the relationship.

56
57
Transforming E-R Diagrams into Relations

– Unary 1:N Relationships

• Relationship between instances of a single entity type
• Utilize a recursive foreign key
– A foreign key in a relation that references the primary key values of
that same relation
– Unary M:N Relationships
• Create a separate relation
• Primary key of new relation is a composite of two attributes that
both take their values from the same primary key

58
59
60
 Transforming E-R Diagrams into Relations

3. Merging Relations (View Integration)

› Purpose is to remove redundant relations
› View Integration Problems
• Synonyms
 Two different names used for the same attribute
 When merging, get agreement from users on a single,
standard name
• Homonyms
 A single attribute name that is used for two or more different
attributes
 Resolved by creating a new name
• Dependencies between nonkeys
 Dependencies may be created as a result of view integration
 In order to resolve, the new relation must be normalized

61
 Physical Database Design
• Physical Database Design is involved with how
data are stored and related based on a
particular DBMS.
• It involves two major activities:
– Designing Fields
– Designing Physical Tables

62
 Designing Fields
• A field is the smallest unit of data recognized
by database management systems
• In general, each attribute from each
normalized relation is represented as one or
more fields
• The basic decisions concerning a field are:
– the type of data (or storage type) and
– data integrity controls for the field.

63
 Choosing Data Types
• A data type is a coding scheme for representing
organizational data.
• The specific database management software to be
used dictates which data type choices are available
• Selecting a data type balances four objectives that will
vary in degree of importance for different applications:
– Minimize storage space
– Represent all possible values of the field
– Improve data integrity for the field
– Support all data manipulations desired on the field

64
 Controlling Data Integrity
• The five popular data integrity control methods are:
– default value: is the value a field will assume unless an explicit
value is entered for the field
– input mask: is a pattern of codes that restricts the width and
possible values for each position within a field
– range control: is a limited set of permissible values both
numeric and alphabetic data may have
– referential integrity: is a constraint specifying that the value (or
existence) of an attribute in one relation depends on the value
(or existence) of the same attribute in another relation
– null value control: is a constraint that insures that mandatory
fields are given a value.

65
 Designing Physical Tables
• A relational database is a set of related tables (tables are
related by foreign keys referencing primary keys)
• a physical table is a named set of rows and columns that
specifies the fields in each row of the table.
• A physical table may or may not correspond to one relation
• Whereas normalized relations possess properties of well-
structured relations, the design of a physical table has two
goals different from those of normalization:
– efficient use of secondary storage and
– data-processing speed.

66
 Designing Physical Tables
• Denormalization is the process of splitting or
combining normalized relations into physical
tables based on affinity of use of rows and fields.
• By placing data used together close to one
another on disk, the number of disk I/O
operations needed to retrieve all the data needed
in a program is minimized.

67
Designing Physical Tables

68
 File Organization
• File Organization is a technique for physically
arranging the records of a file.
• The basic three families of file organizations
used in most file management environments
are:
– Sequential
– indexed, and
– hashed

69
 Sequential File Organization
• The rows in the file are stored in sequence according to a
primary key value
• To locate a particular row, a program must normally scan
the file from the beginning until the desired row is located
• Sequential files are fast if you want to process rows
sequentially, but they are essentially impractical for
random row retrievals
• Deleting rows can cause wasted space or the need to
compress the file
• Adding or updating rows requires rewriting the file

70
 Indexed File Organizations
• The rows are stored either sequentially or
nonsequentially, and an index is created that
allows software to locate individual rows.
• The main disadvantages of indexed file
organizations are the extra space required to
store the indexes and the extra time necessary
to access and maintain indexes.

71
 Hashed File Organizations
• In hashed file organization, the address of each
row is determined using an algorithm that
converts a primary key value into a row address
• rows are located nonsequentially as dictated by
the hashing algorithm. Thus, sequential data
processing is impractical.
• On the other hand, retrieval of random rows is
fast

72
73