0% found this document useful (0 votes)
20 views25 pages

Chapter Two

The document discusses designing user interfaces and databases for a system. It covers designing forms, reports, and interfaces. It provides guidelines for formatting text, tables, lists, and dialogues in interfaces. It also discusses logical and physical database design, including normalization.

Uploaded by

teddy demissie
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
20 views25 pages

Chapter Two

The document discusses designing user interfaces and databases for a system. It covers designing forms, reports, and interfaces. It provides guidelines for formatting text, tables, lists, and dialogues in interfaces. It also discusses logical and physical database design, including normalization.

Uploaded by

teddy demissie
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 25

Chapter II

System Design

1 Compiled Yilkal B.
Chapter Outline

➢ Designing the human interface

▪ Interface Prototype

➢ Designing databases

▪ Logical Database Design

▪ Physical Database Design

▪ Normalization
Compiled
2 Yilkal B. 2
Systems design
➢ System analysts must complete two important activities in the systems design phase:
I. Designing the human/User interface (I/O interface)
II. Designing databases and
I. User interface (UI) design is the process designers use to build interfaces in
software or computerized devices, focusing on looks or style.
➢ Designers aim to create interfaces which users find easy to use and pleasurable.
➢ UI design refers to graphical user interfaces and other forms. e.g., voice-controlled
interfaces.
II. Database design is the organization of data according to a database model.
➢ The designer determines what data must be stored and how the data elements interrelate.
➢ With this information, they can begin to fit the data to the database model.
➢ Database design involves classifying data and
Compiled Yilkalidentifying
B. interrelationships. 3
I. Designing the Human Interface (I/O Interface)
Designing Forms & Reports
➢ Forms and reports are integrally related to the DFD and E-R diagrams developed
during requirements structuring.
➢ For example, every input form is associated with a data flow entering a process on a
DFD, and every output form or report is a data flow produced by a process on a DFD.
➢ Form: A business document that contains some predefined data and may include some
areas where additional data are to be filled in. an instance of a form is typically based
on one database record.
➢ Report: A business document that contains only predefined data; it is a passive
document used only for reading or viewing.
➢ A report typically contains dataCompiled
from many
Yilkal B. unrelated records or transactions. 5
Cntd…
➢ Designing forms and reports is a user focused activity that typically follows a
prototyping approach.
➢ Understanding the skills and abilities of the users helps you create an effective design.
➢ the fundamental questions you have to understand when designing forms and
reports are presented below.
1. Who will use the from 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 or used?
5. How many people need to use or view the form or report?

Compiled Yilkal B. 5
Cntd…
➢ Incase of designing forms and reports, design specifications are the major deliverables
and are inputs to the systems implementation and operation phase.
➢ Design specifications have three sections:
1. Narrative Overview
2. Sample Design
3. Testing and Usability Assessment
1. 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 or
report, why this form or report exists and how it will be used.
▪ So that, they can make the appropriate implementation decision.
Compiled Yilkal B. 5
Cntd…
2. In the second section of the specification you will show a sample design of the
form or report.
▪ This design may be hand drawn using a coding sheet although in most
instances it is developed using CASE or standard development tools.
3. The final section of the specification provides all testing and usability
assessment information.
➢ Some specification information may be irrelevant when designing certain forms
or reports.

Compiled Yilkal B. 5
General Formatting Guidelines
➢ Several guidelines for formatting information while designing forms and reports have
emerged as highlighted below.
➢ These guidelines reflect some of the general truth of formatting most types of
information.

Compiled Yilkal B. 5
Displaying Text
➢ The display and formatting of system help screens, which often contain lengthy textual
descriptions and examples.
➢ The following the simple guidelines that have emerged from systems design research.
appear in Table 2.

Compiled Yilkal B. 5
Designing Tables and Lists
➢ The usability information displayed on tables and alphanumeric lists is likely to be
much more influenced by effective layout than most other types of information display.
➢ As with the display of textual information, tables and lists can also be greatly
enhanced by following a few simple guidelines. This are summarized below.

Compiled Yilkal B. 5
Designing Interfaces and Dialogues
➢ Interface and dialogue design focuses on how information is provided to and captured from
users.
➢ Dialogues are analogous to a conversation between two people .
➢ The design of interfaces and dialogues involves defining the manner in which humans and
computers exchange information.
➢ A good human-computer 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.
➢ The deliverables and outcome from system interface and dialogue design is the creation of a
design specification.
➢ This specification is similar to the specification produced for form and report designs with
one exception( additional , the ways users canYilkal
Compiled moveB. from one display to another.) 11
Guidelines for the Design of Human-Computer Dialogues

➢ Consistency: dialogues should be consistent in sequence of actions, keystrokes, and


terminology (e.g., use the same labels for the same operations on all screens and the
same location of the same information on all displays).
➢ Shortcuts and Sequences: allow advanced users to take shortcuts using special keys
(e.g., CTRL-C to copy highlighted text). A natural sequence of steps should be followed
(e.g., enter first name before last name, if appropriate).
➢ Feedback: feedback should be provided for every user action (e.g., confirm that a record
has been added, rather than simply putting another blank from on the screen).
➢ Closure: dialogues should be logically grouped and have beginning, middle, and end
(e.g., the last in the sequence of screens should indicate that there are no more screens).

Compiled Yilkal B. 12
Cntd…
➢ Error Handling: all errors should be detected and reported. Suggestions on how to proceed
should be made (e.g., suggest why such errors occur and what the user can do to correct the
error).
➢ Reversal: dialogues should, when possible, allow the user to reverse actions (e.g., undo a
deletion); data should not be deleted without confirmation.
➢ Control: dialogues should make the user (especially an experienced user) feel in control
of the system (e.g., provide a consistent response time at a pace acceptable to the user).
➢ Ease: dialogues should provide simple means for users to enter information and
navigate between screens (e.g., provide means to move forward, backward, and to a
specific screen, such as first and last)

Compiled Yilkal B. 5
II. Designing databases
➢ A Database is a shared collection of related data which is used to support the
activities of a particular organization.
➢ A database can be viewed as a repository of data that is defined once and then is
accessed by various users.
➢ A database has the following properties:
• It is a representation of some aspect of the real world.
• A database is logical, coherent and internally consistent.
• A database is designed, built, and populated with data for a specific purpose.
• Each data item is stored in a field,
• A combination of fields makes up a table.
➢ A Database Management System (DBMS) is a collection of programs that enable
users to create, maintain databasesCompiled
and control
Yilkal B. all the access to the databases. 14
Cntd…
➢ Logical and physical database design has five purposes:

1. Structure the data in stable structures that are not likely to change over time and that

have minimal redundancy.

2. Develop a logical database design that reflects the actual data requirements that exist

in the form and reports of an information system.

3. Develop a logical database design from which we can do physical database design.

4. Translate a relational database model into a technical file and database design.

5. Choose data storage technologies (such as floppy disks, CD-ROM, or optical disk)
Compiled Yilkal B. 15
Cntd…

➢ File and database design occurs in two steps.


➢ You begin by developing a logical database model,
▪ which describes data using a notation that corresponds to a data organization
used by a database management system.
▪ The most common style for a logical model is the relational database model (data
represented as set of related tables or relations).
➢ Once you develop a clear and precise logical database model, you are ready to prescribe
the technical specifications for computer files and databases in which to store the
ultimately (A physical database design provides these specifications).

Compiled Yilkal B. 16
Cntd…
➢ Logical database design driven is not only from the previously developed E-R data
model for the application but also from form and report layouts.
➢ In logical database design you use a process called normalization.
➢ which is a way to build a data model that has the properties of
▪ simplicity,
▪ Non-redundancy, and
▪ minimal maintenance.
➢ Normalization is the process of converting complex data structures into simple, stable,
data structure..

Compiled Yilkal B. 17
Cntd…
➢ As revision, here are the most commonly used normal forms:
1. First normal form(1NF): an attribute (column) of a table cannot hold multiple
values. It should hold only atomic values.
2. Second normal form(2NF): A table is said to be in 2NF if both the following
conditions hold:
▪ Table is in 1NF (First normal form)
▪ No non-prime attribute is dependent on the proper subset of any candidate key of table.
▪ An attribute that is not part of any candidate key is known as non-prime attribute.
3. Third normal form(3NF): A table design is said to be in 3NF if both the following
conditions hold:
▪ Table must be in 2NF
▪ Transitive functional dependency of non-prime
Compiled attribute
Yilkal B. on any super key should be removed.
18
Cntd…
➢ for each functional dependency X-> Y at least one of the following conditions hold:
▪ X is a super key of table
▪ Y is a prime attribute of table
➢ An attribute that is a part of one of the candidate keys is known as prime attribute.
4. Fourth Normal Form(4NF):
▪ it comes into picture when Multi-valued Dependency occur in any relation.
▪ In this tutorial we will learn about Multi-valued Dependency, how to remove it
and how to make any table satisfy the fourth normal form.

Compiled Yilkal B. 19
Cntd…

Compiled Yilkal B. 20
Cntd…
❑ There are four key steps in logical database modeling and design.
1. Develop a logical data model for each known user interface (form and report) for the
application using normalization principle.
2. Confine normalized data requirements from all user interfaces into one consolidated
logical database model; this step is called view integration.
3. Translate the conceptual E-R data model for the application developed without
explicit consideration of specific user interfaces, into normalized data requirements.
4. Compare the consolidated logical database design with the translated E-R model and
produce, through view integration, one final logical database model for the application.
❑ During physical database design, you use the results of these four key logical database
design steps.
Compiled Yilkal B. 21
Transforming E-R Diagrams into Relations

➢ Transforming an E-R diagram into normalized relations and then merging all relations
into one final, consolidated set of relation can be accomplished into four steps.
1. Represent entities: each entity type in the E-R diagram becomes a relation.
▪ A relation is a named, two dimensional table of data.
▪ Each relation consists of a set of named columns and an arbitrary number of
unnamed rows.
▪ The identifier of the entity becomes the primary key of the relation, and other
attributes of the entity type become non primary key attributes of the relation.
2. Represent relationships: each relationship in E-R diagram must be represented in the
relational database design. How we represent a relationship depends on its nature.

Compiled Yilkal B. 5
Cntd…
3. Normalize the relation: the relations created in step 1 and step 2 may have unnecessary
redundancy.
➢ So, we need to normalize these relations to make them well structured.
4. Merge the relation: there may be redundant relations (two or more relations that
describe the same entity type) that must be merged and renormalized to remove the
redundancy.

Compiled Yilkal B. 5
Designing Physical Tables
➢ A relational database is a set of related tables (tables are related by foreign key
referencing primary keys).
➢ In logical database design you grouped into a relation those attributed that
concern some unifying, normalized business concept, such as a customer,
product, or employee.
➢ In contrast, a physical table is a named set of rows and columns that specifies
the fields in each row of the table.
➢ The design a physical table has two goals different from those of normalization:
▪ efficient use of secondary storage and
▪ Efficient use data processing
Compiled Yilkal B. 24
End of chapter Two
Any Question?

Compiled Yilkal B. 25

You might also like