CHAPTER FOUR

DESIGN PHASE
Outline
Introduction
System Design
4.1 Process\ Data Flow Diagram
4.1.1 Data Flow Diagram
4.1.2 Site Map
4.2 Database Design
4.2.1 Conceptual Model
4.2.1.1 Entity Relationship Diagram
4.2.2 Logical Model
4.2.3 Physical Model
4.3 Network Design
4.4 User Interface Design
4.4.1Input Design
4.4.2 Output Design
Conclusion
Introduction

In chapter three user requirements have been collected. Also, alternatives solutions have been
compared in order to select the most suitable alternative which was developing new student
performance reporting system.

In this chapter, the designer will design the candidate system beginning by conceptual model, to the
logical model which shows the shape of the system and at the end the physical model will be
designed.

System Design

Systems design is the process of defining the architecture, components, modules, interfaces,
and data for a system to satisfy specified requirements. 1

4.1 Process\ Data Flow Diagram

4.1.1 Data Flow Diagram

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information
system, modeling itsprocess aspects. Often they are a preliminary step used to create an overview of
the system which can later be elaborated. DFDs can also be used for the visualization of data
processing (structured design).

A DFD shows what kinds of data will be input to and output from the system, where the data will
come from and go to, and where the data will be stored. It does not show information about the
timing of processes, or information about whether processes will operate in sequence or in parallel
(which is shown on a flowchart).2
4.1.2 Site Map

A site map (or sitemap) is a list of pages of a web site accessible to crawlers or users. It can
be either a document in any form used as a planning tool for web design, or a web page that lists the
pages on a web site, typically organized in hierarchical fashion. This helps visitors and search
engine bots find pages on the site.3

4.2 Database Design

Database design is the process of producing a detailed data model of a database. This logical data
model contains all the needed logical and physical design choices and physical storage parameters
needed to generate a design in a Data Definition Language, which can then be used to create a
database. A fully attributed data model contains detailed attributes for each entity.

The term database design can be used to describe many different parts of the design of an
overall database system. Principally, and most correctly, it can be thought of as the logical design of
the base data structures used to store the data. In the relational model these are the tables and views.
In an object database the entities and relationships map directly to object classes and named
relationships. However, the term database design could also be used to apply to the overall process of
designing, not just the base data structures, but also the forms and queries used as part of the overall
database application within the database management system (DBMS).

The process of doing database design generally consists of a number of steps which will be carried
out by the database designer. Usually, the designer must:

 Determine the relationships between the different data elements.

 Superimpose a logical structure upon the data on the basis of these relationships.4
4.2.1 Conceptual Model

A conceptual schema or conceptual data model is a map of concepts and their relationships. This
describes the semantics of an organization and represents a series of assertions about its nature.
Specifically, it describes the things of significance to an organization (entity classes), about which it
is inclined to collect information, and characteristics of (attributes) and associations between pairs of
those things of significance (relationships).5

4.2.1.1 Entity Relationship Diagram

An entity-relationship (ER) diagram is a specialized graphic that illustrates the relationships

between entities in a database. ER diagrams often use symbols to represent three different types of
information. Boxes are commonly used to represent entities. Diamonds are normally used to
represent relationships and ovals are used to represent attributes.6

Within the relational model the final step can generally be broken down into two further steps
that of determining the grouping of information within the system, generally determining what are
the basic objects about which information is being stored, and then determining the relationships
between these groups of information, or objects. This step is not necessary with an Object database.7

Table 4.1 represents Entity-Relationship Diagram for the SPFS:

 Legend
Symbol Description

Entity

Weak Entity

Relationship

Identifying
Relationship

Attribute

Key Attribute
(primary key)

Multivalued
Attribute

Composite
Attribute

Derived
Attribute

Entity Relationship Diagram Revision

No. Date description

1:1 Developed by: Bailasan Checked by: Eng. Basma Elzein Nov1st 2012

Table 4.1 : Entity-Relationship Diagram

Main components of the ER:

1) Entity: An entity is a something of interest to the system about which information is kept.

Table 4.2 shows types of entities:

Notation title Description

Strong Entity Entity that is independent of
other entities.

Weak Entity Entity that existence depends

on another entity.

Associative Entity An associative entity is an element

of the entity–relationship model. The
database relational model does not
offer direct support to many-to-
many relationships, even though
such relationships happen frequently
in normal usage. The solution to this
problem is the creation of another
table to hold the necessary
information for this relationship.
This new table is called an
associative entity.
Table 4.2: entities types

2) Attribute: the following table shows types of attributes

Notation title Description

Attribute a property or descriptor of an
entity, for example, Customer
Name is an attribute of the
entity Customer. Each attribute
will eventually be represented
by one or more entity attributes
in the physical database
structure.
 Composite Attribute An attribute is considered
composite if it comprises two or
more other attributes.

Derived Attribute If an attribute's value can be determined

from the values of other attributes, then
the attribute is derivable, and is said to
be a derived attribute.

Table 4.3: attributes types

Entity Definition:
The following table below shows the definition of entities for the SPFS:

Title Type Description Identifier

Parent Strong Entity Represents parent in PID
the school
Report Strong Entity Represents ReportID

performance report to
be generated
Director Strong Entity Represents the director DirectorID

of the school
Teacher Strong Entity Represents the teacher TID

in the school who will

be responsible for
some students
Administrator Strong Entity Represents AdminID

administrator of the
system who will be
responsible for creating
accounts
Student Strong Entity Represents student SID

who will be evaluated

regulary
Feedback Weak Entity Feedback from parents FID

to the director
regarding performance
report
Table 4.4: entities definition

Definition of Attributes:
The following table describes attributes regarding the above ER diagram for SPFS:
 Parent entity
Title type description Null
PID Identifier The ID of the parent NOT NULL

PName text Name of the parent NOT NULL

PAddress text Address of the parent NULL

PPhone number Mobile number of the of NOT NULL

the parent

Table 4.5: Parent entity

 Report Entity
Title type description Null
ReportID Identifier NOT NULL

ReportType text The type of the report NOT NULL

Table 4.6: Report Entity

 4.2.2 Logical Model

Logical data models represent the abstract structure of some domain of information. They are often
diagrammatic in nature and are most typically used in business processes that seek to capture things
of importance to an organization and how they relate to one another. Once validated and approved,
the logical data model can become the basis of a physical data model and inform the design of a
database.

Logical data models should be based on the structures identified in a preceding conceptual data
model, since this describes the semantics of the information context, which the logical model should
also reflect. Even so, since the logical data model anticipates implementation on a specific computing
system, the content of the logical data model is adjusted to achieve certain efficiencies. 8

1. Mapping Strong Entities: attributes associated with strong entity will be mapped into
relations.

From: PID
PName

PAddress

Parent

To:
Parent

PID PAddress PName

 2. Mapping One-to-Many relationship: identifier of the one side will be the foreign key in
the many side.

From
AdminID
AdminName

Administrator

register

Student

SID SName

To

Student

SID AdminID SName

Administrator

AdminID AdminName
 Parent
PID PName PAddress PPhone

ReportID PID TID DirectorID ReportType

Report

Teacher
TID TName TAddress TPhone

DirectorID DirectorName

Director

Feedback

FID FDate DirectorID

AdminID AdminName

Administrator

Student

SID SName AdminID

4.2.3 Physical Model

Program
A physical data model (or database design) is a representation of a data design which takes into
account the facilities and constraints of a given database management system. In the lifecycle of
a project it typically derives from a logical data model, though it may be reverse-engineered from
a given database implementation. A complete physical data model will include all the database
artifacts required to create relationships between tables or to achieve performance goals, such as
indexes, constraint definitions, linking tables, partitioned tables or clusters. Analysts can usually
use a physical data model to calculate storage estimates; it may include specific storage
allocation details for a given database system.9
Several Database Management Systems are available to choose from such as SQL server 2008,
DB2 and MySQL.
SQL server 2008 has been chosen to be used to create the database for the Equipment
Management System.

4.2.3.1 Data Storage Calculations

The following is the calculation of physical storage required for the implementation phase:
1. Calculating Row size:

Row is an instance of an entity. Size of each row measured in bits as the following:

Column name Data type length

PID Varchar 100

PName Varchar 100

PAddress Varchar 100

PPhone numeric 5

total 305

Figure 4.1: Row size Calculation

2. Calculating Table size
Table consists of number of rows. To calculate the total size of a table multiply the row size in the
previous step by the number of rows in the table. Total number of parents is estimated to be 500.
Multiplying by the row size (305) the result is 152500 bits the total size of the parent table.

4.3 Network Design

A computer network, often simply referred to as a network, is a collection of hardware components and
computers interconnected by communication channels that allow sharing of resources and
information. Where at least one process in one device is able to send/receive data to/from at least one
process residing in a remote device, then the two devices are said to be in a network. 10

4.3.1 Networking of Student Performance follow up system

The most suitable network Structure adopted to be used in our system is the Client-Server network where
nodes are known clients and servers are there to control access to the database software. Our application
is a three tires application. i.e., client, server and database. Client has the user interface that is connected
to the server which will control access to the database in the third tier.

The following diagram shows network of our system:

 Figure4.2: SPFS network architecture

At the bottom of the application is the database tier which consists of the database
management system that administers the database containing our data. One level over
the database tier is the middle tier which contains the application logic and
communicates data between the two separated tiers. The topmost level is the client
tier which is the browser that will open our website.

Conclusion

In this chapter we have introduced the system design phase where requirements have been translated
into a system design, logical design has been finalized and physical design has been figured. In the
next chapter we will introduce the system implementation.