Sie sind auf Seite 1von 9

Information and Seat

Reservation System called


BREEZE

Mark Anthony Raymundo


Luzvi Dabuet
Creators
Submitted to Prof. Rosita Canlas in
compliance to the requirement for Database
Management Systems (PBDIT 4013)

Introduction:
How to Ride Trains on the Philippine General Railway

Part I: Database Planning


I. Enterprise Modeling and Early Conceptual Data Modeling
A. Conceptual Model showing transaction on how to ride the trains
of the Philippine General Railway
PGR currently uses the conventional way
of accommodating its passengers. Travel
time to every station was already
scheduled for its trains, but the load of
passengers is undeniably no match to the
number of trains available for them. This
incident makes long queue of passengers
every time of the day, especially during
rush hour. This instance then forces the
passengers to find an alternative way of
going to their respective destinations,
thus a reduction to the number of
potential clients for the company.
Those who have persisted on staying
have terrible comments on how the
system works, which has a very bad implication on the reputation of the
company. By looking at the conceptual model above, you will notice that
there is no control on the number of passengers who can ride on the train,
despite the fact that the number of trains are limited, not to mention time

constraints and other form of perils and incidences that can affect the
performance of the train and the personnel of the company.
B. Entity-Relationship Model showing transaction on how to ride the
trains of the Philippine General Railway

1:1

1:1

M:1

1:M

M:1

1:M

As per the current system, a passenger can buy a ticket for himself or
several tickets for him and his companions. Once the passengers go
inside the train, the inspectors will check their ticket for an assurance that
those inside the train are the once who has made their payment. These
inspectors are assigned by the company to stay on their respective train
designations for their entire shift.

II. Mission
Company:
The PGR shall provide safe, reliable and affordable railway services as a
socio-economic development tool within the framework of the
metropolitan infrastructure system, while ensuring sustainable operations
so that optimum service can be rendered at a minimum passenger and
freight prices.

Information Technology:
We aim to improve the current system of Philippine General Railway
Company in order to give their client secured and comfortable trip. On its
financial aspect, we would like to assure that every resource is being
utilized and used optimally in order to save finances in the long run.

III. Vision
Company:
Philippine General Railway envisions an improved, sustainable railway
system running from Caloocan to Alabang City. The company will be the
name when it comes to transactional organization. The clients will be
accommodated at their best by giving them secured trip and ease of
access to the transportation system.

Information Technology:
Philippine General Railway will have an effective tool that it can use to
manage the passengers in order for both parties to save time and effort.

IV. Scope and Boundaries of the Database Application

To reduce complexity of existing system.


Effective management of time.
To make work easy, simple and error free.
Effective utilization of available resource.
To enhance the efficiency and diversification of services activities.
User friendly.
Interactive graphical user interface.

The scope of project define the project feasibility, the technology , finance
, time and resources best define in technology whether the defects can be
reduced in the project and up which level financially, whether the overall
project cost is affordable. Time describe the whether the projection
finishing point will be achieve on time or before time resources required
should be available at the rate of cost and time.

V. User
To see the different types of agents on responsible in running the current
ticketing system in PGR, please check the Use-Case Diagram Below:

Conductor
/ Inspector

Part II: Requirement Collection and Analysis


Functional Requirements
1. Performance requirements:

User Satisfaction - The system is such that it stands up to the


user expectations.

Response Time - The response of all the operation is good. This


has been made possible by careful programming.

Error Handling - Response to user errors and undesired situations


has been taken care of to ensure that the system operates without
halting.

Safety and Robustness - The system is able to avoid or tackle


disastrous action. In other words, it should be foul proof. The system
safeguards against undesired events, without human intervention.

Portable - The software should not be architecture specific. It


should be easily transferable to other platforms if needed.

User friendliness - The system is easy to learn and understand. A


native user can also use the system effectively, without any
difficulties.

2. Design constraint:

There are a number of factors in the clients environment that may


restrict the choices of a designer. Such factors include standards that
must be followed, resource limits, operating environment, reliability
and security requirements and policies that may have an impact on the
design of the system. An SRAS (Software Requirements Analysis and
Specification) should identify and specify all such constraints.

Standard Compliance - This specifies the requirements for the


standards the system must follow. The standards may include the
report format and accounting properties.

Hardware Limitations - The software may have to operate on


some existing or predetermined hardware, thus imposing
restrictions on the design. Hardware limitations can include the
types of machines to be used, operating system available on the
system, languages supported and limits on primary and secondary
storage.

Reliability and Fault Tolerance - Fault tolerance requirements


can place a major constraint on how the system is to be designed.
Fault tolerance requirements often make the system more complex
and expensive. Requirements about system behaviour in the face of
certain kinds of faults are specified. Recovery requirements are
often an integral part here, detailing what the system should do I
some failure occurs to ensure certain properties. Reliability
requirements are very important for critical applications.

Security - Security requirements are particularly significant in


defence systems and database systems. They place restrictions on
the use of certain commands, control access to data, provide
different kinds of access requirements for different people, require
the use of passwords and cryptography techniques and maintain a
log of activities in the system.

3. Hardware requirements:
For the hardware requirements the SRS specifies the logical
characteristics of each interface b/w the software product and the
hardware components. It specifies the hardware requirements like
memory restrictions, cache size, the processor, RAM size etc... those
are required for the software to run.
Minimum Hardware Requirements

Processor Pentium III

Hard disk drive 40 GB

RAM 128 MB

Cache 512 kb

Preferred Hardware Requirements

Processor Pentium IV

Hard disk drive 80 GB

RAM 256 MB

Cache 512 kb

4. Software requirements:

Any window based operating system with DOS support are primary
requirements for software development. Windows XP, FrontPage and
dumps are required. The systems must be connected via LAN and
connection to internet is mandatory.

Non-Functional Requirements:
1. Security:
The system use passwords in order to avoid unauthorized users have
access on the database they are not intended to use or even see. The
systems back-end servers shall only be accessible to authenticated
management.
2. Reliability:
The reliability of the overall project depends on the reliability of the
separate components. The main pillar of reliability of the system is the
backup of the database which is continuously maintained and updated to
reflect the most recent changes. Also the system will be functioning inside
a container. Thus the overall stability of the system depends on the
stability of container and its underlying operating system.
3. Availability:
The system should be available at all times, meaning the user can access
it using a web browser, only restricted by the down time of the server on
which the system runs. A customer friendly system which is in access of
people around the world should work 24 hours. In case of a of a hardware
failure or database corruption, a replacement page will be shown. Also in
case of a hardware failure or database corruption, backups of the
database should be retrieved from the server and saved by the Organizer.
Then the service will be restarted. It means 24/7 availability.
4. Maintainability:
A commercial database is used for maintaining the database and the
application server takes care of the site. In case of a failure, a reinitialization of the project will be done. Also the software design is being
done with modularity in mind so that maintainability can be done
efficiently.
5. Supportability:

The code and supporting modules of the system will be well documented
and easy to understand.

I. Conceptual Data Model


organization of PNR once

showing the operational


the proposal has been

implemented

II.
Use
Diagram

Case

To see the
types of users
utilize
the
once
it
is
implemented,
check
the
Diagram

different
who
can
project
please
Use-Case
Below:

Part III: Database Design


I. Logical Data Model showing the flow of operations of
PNR once the proposal has been implemented