Kira Morris

System Analysis and Design

12/3/2017

Speedy Wheels

Consider designing a system that needs to store information about vehicles and drivers

employed by "Speedy wheels," a delivery company

The reason why the system should be supported by a database, and not a file system.

Storing the information pertaining to the company’s vehicles and drivers in a database

would prove more efficient than a file system for several reasons Listed below are a few reasons

why DBMS is better than file system-

1. Search Facility- DBMS facilitates search options in better way as compared to file system.

Searching and query options are already available in DBMS.

2. Data Integrity- DBMS maintains data integrity by enforcing the constraints by adding

appropriate code.

3. Data Isolation- DBMS is a centralized system which maintains the data isolation. Format of

similar type of data remains same.

4. Redundancy - While storing the company’s information in a file system, the storing and

deletion of said information can be such a tedious task. A DBMS however can simplify and

automate this process for ease of use.

A vehicle tracking system DBMS example.

1. They do provide a highly efficient method for handling multiple types of data.
 2. Tasks are done manually, hence taking more time is now easier.

3. Data is usually categorized and is structured to suiting the needs of the company or the

organization.

4. Usually the data entered into the system is accessed on a routine basis by the assigned

users, with every single user having an assigned password to gaining access to part of the

system. Also, this allows multiple users to access and use the system at the same time in

different ways.

5. The relational databases usually use multiple tables and define relationships between

them using a schema, in addition to data elements.

6. Usually the query language provides a way in which to find the specific types of data in

every record, then returning the results that match the inputted criteria.

Description of at least five conceptual things/entities that might comprise the model.

Below is the ER diagram of Speedy wheels, a delivery company. It consist of set of

entities, their attributes and relationship between entities. Primary key are mentioned as

underlined attributes. Primary keys are used to maintain data integrity. The entities included in a

system like this are the driver, the vehicles, the journey/routes taken, required fuel, and costs,

 The driver entity details the drivers information

 The vehicles entity will describes the details of each vehicle used

 The journey entity lays out the routes and destinations.

 The entity entitled fuel type dictates the vehicles required fuel

 Fuel costs as an entity is pretty self explanatory

 Driver

Vehicles Transport cost

Fuel-type

Fuel cost
Journey details

Explanation of at least three relationships among the entities of your model.

 One-to-one (1:1). One driver to one vehicle.

 One-to-many (1: M). One driver to many journey details.

 Many-to-many (M: N). Many fuel types to many fuel costs.

Description and justification for at least three attributes of each of the entities.

Dotted shape- shows the derived attributes usually based on another attribute.

Solid shape – shows the key attribute plus is the unique, the distinguishing characteristic of the

entity.

Two-lane solid shape- shows the multivalued attribute that can have more than one value.

 Driver – Name, ID, Contact details, Company status

 Vehicles – License, Model, Year, Driver

  Journey - Directions, Destinations, Customers

 Fuel – Types used by each company vehicle, Station stops, Regular or Diesel

 Costs – Fuel needed to fill tank, Fuel for full routes, Taxes

Justification for the choice of the primary identifier of each entity; specifically, whether you

suggest using natural or surrogate key.

The primary/natural key for the vehicles and driver would be the journey because it will

determine who goes where, leaving them as surrogate keys.

The fuel types would be the natural key for the costs because it depends on what’s bought.

References

1. Graves, Steve. "COTS Databases For Embedded Systems", Embedded Computing

Design magazine, January 2007. Retrieved on August 13, 2008.

2. "Re: Comments to Access Board Docket Number 2007-1" (PDF). Office of Technical

Information Services, APTA. January 20, 2009. p. 3. Retrieved 2009-11-26.

3. itl.nist.gov (1993) Integration Definition for Information Modeling (IDEFIX). 21

December 1993.