Scribd
Upload
18 views

Hamilton Street Railway Master Database

Uploaded by

Saahil Karnik
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
18 views

Hamilton Street Railway Master Database

Uploaded by

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

Hamilton

Street Railway
Master
Database
- Saahil Karnik -Zaheeruddin Siddiqui
- Karan Parmar -Abdul Mohsin Ahmed
- Shrajna Shetty -Aman Khan
Outline

 Hamilton Street Railway (HSR) is a public


transport agency providing bus service in the
Hamilton area.

 We have designed a database that tracks the


activity and operations of its bus fleet so they
can analyze the utilization of buses and its
resources in serving customers.
Executive Summary

We have designed the Hamilton Street Railway Master


Database system, which has many robust and productive
features.
 Organized and stored individual data items in table format.
 Displayed relationships / associations among entities as
shown in Entity Relationship diagrams (ERDs).
 Included details of physical data store organization
including field name, field types, field size and other
related metadata.
 Exercised access and content controls, allowable values
used for specific data items, list of users allowed to read or
update data items via customized views.
Initial Phase to Design Phase
 Collecting Requirements
Documentation of the most common concerns and expected
features by collaborating with current customers and relevant
stakeholders.
 Conceptual Modelling
Cognitive perception of the data and its related processes by
identifying entities, defining attributes, establishing relationships
and business rules.
 Logical Modelling
Clear pictorial representation of the data with all its child
elements and high-level functionality. Primarily involved in
designing the system with 4 core components which interact with
each other resulting in child elements
 Physical Database Design
ERD-based development of the database which comprises the
table columns with involved relationships. Using these core and
child entities, we normalized the flow of data and designed the
Entity Relationship Diagram.
ERD (Original)
ERD (Updated)
Physical Schema
The most important entities and their attributes are:
• Person- Name, Gender, Date of birth,
Address(Street/City/Province), Occupation.
Maintenance Personnel, Passenger Type, Driver
etc. are derived from Person.
• Route- Route#, Name. Route Stop, and Event are
derived from Route.
• Bus- Years in Operation, No. Of Seats,
Manufacturer, Route ID, Schedule, Stop, Service
are derived from Bus.
Business Rules
 Event Information: Each event representing a
closure or disruption in a specific route must have
a unique identifier, name, description, start date
and time, end date and time, and affected route(s)
recorded.
 Closure Events: Events representing closures or
disruptions must specify the affected route(s) and
the duration of the closure (start and end date and
time).
 Alternate Services: During closures, passengers
must be informed about alternate routes, services
or transportation options to minimize
inconvenience.
 Bus Information: Each bus must have a unique
identifier, years in operation, number of seats,
manufacturer, advertising revenue, and fuel type
recorded.
 Route and Stop Information: Routes and stops
must have unique identifiers and names. A route
contains multiple stops, and a stop may belong to
multiple routes.
Business Rules
(Continued)
 Recording Closure Reasons: The reason for the closure
event (e.g., track maintenance, emergency repair) must be
recorded for tracking and analysis purposes.
 Coordination with Maintenance: Closure events may be
initiated due to maintenance activities, and there must be
coordination between maintenance personnel and
operations staff to ensure timely completion of
maintenance work and restoration of service
 No Service during Closure: During the duration of a
closure event, no buses will operate on the affected
route(s).
 Communication of Closure: Closure events must be
communicated to passengers through appropriate
channels (e.g., website, mobile app, signage at stops) to
inform them about service disruptions.
 Sites must have their name, address, phone number,
capacity, and category recorded.
Application

 Any transit system can use this application to


store the details of customers, routes, and
vehicles used.
 Aids the management to view snapshots of each
significant entity and immediately root out
problems.
 Helps provide insights to efficiently manage
company resources – vehicles, drivers.
 Helps management to effectively chart out new
routes and stops to maximize revenue and
increase customer convenience.
Sales & Service
Expansion
• With the driver models and their respective
infractions data, we get insights into trends of
drivers committing traffic infractions. This aids
in planning and preventing losses through fines
and any other legal issues.
• We can build new route and transit option for the
future reference as per sales, supply and demand
of the city population
Financial Gain

• With this database, the requirements and


concerns of the customers and the employees can
be analyzed and easily addressed.
• Such a comprehensive database with support for
business intelligence tools will help the
management maximize the resources available.
• This assures increasing profitability.
Summary

• So, with this intuitive master


database, HSR would have the
cutting-edge expertise to take
smart business decisions.
• It endears the customers and bus
drivers.
• It ensures that there are no data
gaps and keeps track of all the
processes involved in this.
Thank
you

You might also like