Beruflich Dokumente
Kultur Dokumente
Ohio and at the moment has facility locations in California, St. Louis, Los Angeles, Bayonne,
Missouri, and New Jersey. To successfully supervise their production, it is highly critical that
Huffman Trucking will be capable of allocating information rather quickly regarding the vehicles
maintenance and preservation in relation with each of its hubs, this should also include a parts
inventory and vendor data sheets. Huffman Trucking executive management staff requests a fair
resolution with the purpose that would permit the different hubs to share the important
information between their various locations. Smith Consulting developed entities and attributes
for Fleet Truck Maintenance but did not develop the database. In an effort to better document our
applications, Entity-Relationship Diagrams are also needed. The expected results should convey
and deliver the creation of Entity-Relationship Diagrams for Fleet Truck Maintenance. Smith
Consulting was actually engaged to distribute an ERD and feature a fair proposal to Huffman
Trucking that outlines a well-rounded database solution within the HUBS different locations.
The main intention is to convey the projected database to life and put into service a shared
database across the line to Huffman’s other various locations upon request.
Project Overview
Huffman Trucking desires to advance and make certain that maintenance is performed
and tracked for the entire fleet of trucks across all of the company’s other locations.
Additionally, the project will minimize down time for vehicles in their fleet by ensuring
parts are on hand to perform the maintenance. Having these needs met with minimize potential
revenue lost due to unavailable vehicles. The goal of the project is to create the entity
relationship diagrams that will support the creation of a shared database that can be accessed by
all of Huffman Trucking various locations. The project should take no longer then five weeks to
accomplish. If more time is needed, a request will be submitted within the first two weeks of the
project. The life cycle of the database depends on the growth and needs of Huffman Trucking
Company. A yearly analysis will be performed to determine necessary enhancements over the
Assumptions while the scope of the proposal attempts to be objective as possible, some
assumptions are inherent. The team is assuming that Smith Consulting accurately interpreted all
of the entities. Secondly, it is being assumed that Huffman has the necessary infrastructure or the
means to put into operation the appropriate infrastructure, hardware, software, and licensing.
Therefore, assuming these components will not limit or influence the ERD. In a real life
situation, one always has some working assumptions that one needs to document and clarify with
the client.
Requirements
In order to ensure a successful ERD, several tasks will need to be executed. The first
requirement will be to define the business rules of Huffman’s current maintenance program. This
will be conveyed by drafting a Data Flow Diagram. One of the constraints we are presented with
is the potential lack of documentation. One way to overcome this constraint will be to interview
subject matter experts and the key players involved in the maintenance process. The second
requirement will be to draft an Entity-Relationship Diagram (ERD) based upon the business
rules and the entities, which were captured by Smith Consulting. All of Huffman’s hubs will use
the database and with that, will need to be robust enough to handle the volume. In addition, data
anomalies such as redundancies must be eliminated by normalizing the tables. One of the
challenges will be to find a balance between normalization and performance. Our project team
construct a prototype of the ERD in Microsoft Access. The prototype will then be populated with
a small sample of data. This will ensure the ERD will be robust and has in fact eliminated any
data anomalies.
The cost of Huffman Trucking project includes, but is not limited to programmers,
personnel for implementation, training personnel, project analysis, yearly analysis, and support
personnel for a three-year period. Any enhancements during this period will be extra and
determined at the time of request. The total cost shall not exceed $80,000.
Benefits regarding this effort include but are not limited to the following:•More efficient
maintenance program.
•Reduced parts and labor overhead connected with inventory and ordering.
•Establishing an environment that will support a new record keeping front-end that can be
made available through the intranet website. There will also be several opportunities that will
grow from this project. In the future, analysis of this data will lead to even more improvements
in the maintenance program here at Huffman. Opportunities regarding this effort include but are
If this project is not implemented, it will not be possible to automatically share data for
each of the trucking hubs. Parts ordering and settlement will continue to be done in an inefficient
and decentralized way. Parts inventory will not be able to be shared between hubs and
The required deliverables are Entity Relationship Diagram’s for the Fleet Truck
Maintenance. This project will accomplish that goal by leveraging the resources of this learning
team to develop a concept database allowing for the validation of the data and entities, and will
ultimately result in the creation of a valid ERD for the Fleet Truck Maintenance data systems.
Within the scope of this project, it will be very easy to measure the progress and eventual
success of this project. Within the five-week timeframe of this project, we will design the data
structure, implemented in a conceptual database, which will allow us to create and validate the
ERD. At the completion of each of these goals a status report will be submitted to management.
As with any data design project, many business rules and impacts will have to be
considered. The vehicle maintenance nature of this system will require that an inventory be kept
that can reflect the status of parts available for maintaining the fleets vehicles. Scheduling
maintenance for the fleet of vehicles also becomes important in ensuring that the fleet is properly
maintained. Regular maintenance is critical in extending the useful life of the vehicles to
In order to effectively maintain the fleet, it becomes imperative that Huffman Trucking
have sufficient parts in inventory so that maintenance is not deferred while parts are being
acquired. A well designed maintenance system will ensure that inventory is sufficient for
upcoming nominal maintenance, vehicles in the fleet are maintained when necessary, and
Certain business rules will need to be implemented in the database to maintain the
integrity of the system. Parts removed from inventory to be used in servicing a vehicle must be
reflected accurately in the database. This becomes the basis of triggering to order new parts in
maintaining necessary levels of inventory. The coming maintenance of a vehicle should also
trigger an event to ensure that the parts anticipated to be needed for that maintenance are on
hand. If the anticipated parts are not in inventory, then an order should be recommended by
The proposed solution is to create a shared concept database using Microsoft Access. No
Trucking’s approved corporate standard. This will also keep the cost of this project down.
This solution will include a split database application design, simply meaning that there
will be a Microsoft Access front-end and a separate Microsoft Access back-end. ok The reason
for the split design is in the event the volume of data increases the Microsoft Access back-end
can be up-scaled to a more robust database solution such as Microsoft SQL Server. ability to
upsize is important.
Alternative Solutions
The only alternative to creating a central database for fleet truck maintenance would be to
create a completely proprietary system unique to Huffman Trucking. This would require more
development time as well as training. The nonstandard nature of the system would also make it
more difficult to maintain and upgrade as the need arises. correct and will be expensive to
implement.
Contingency Plan
The contingency plan will be to continue with the manual record keeping system that
exists today at Huffman Trucking until the new and improved database solution can be delivered.
Additional Information
This project will be delivered in a phased approach. The first will be the delivery of the
database itself and an application front-end, followed up with a data conversion/input of existing
corporate data. The application will be deployed to one location where it will go through pilot
testing before being deployed to the remaining locations. The database will be created first and
the data conversion will be performed one location at a time. Until each location is transferred to
the new system, they will continue with the existing process.
Implementation/Database Design
Based on the original content provided by Smith consulting, a database design was
obtained by first analyzing the key subjects, entities, and attributes. The key subjects are the
following: Vehicle, Work Order, Maintenance, Parts, Manufactures, and Contacts along with
several entities to support each of the subjects. This is sometimes referred to as a user view.
Hence, rather than attempting to build the entire database at once, individual user views were
created. Each of these user views are represented by a collection of tables. The tables were then
normalized to third normal form (3NF). Accordingly, each of the tables will be joined by a series
of primary and foreign keys thereby creating relationships among them. This approach will allow
the design to be broken into smaller pieces, thus focusing on one entity at a time. Eventually,
these smaller designs were merged into a cumulative design for the entire database.
The following is a data dictionary describing the purpose of each of the table their names,
Entity Description
This entity outlines all of the Vendors that the Huffman Trucking Company utilizes. The
Vendor entity relates to the Parts Catalog and Contacts entities. A Vendor may have 1 or many
parts they provide. A Vendor may have 1 or more contacts, billing or order.
Parts catalog
This entity outlines all of the Parts that Huffman Trucking has on hand. A part has
several types of basic information such as a name, type, etc. A part is related to a Vendor that
Huffman orders from and also relates to a Manufacturer that creates the part.
= Billing Contact.
Text Contact address line 1City Text Contact city State Text Contact state Zip
Number Contact Zip contact_first_name Text Contact first name contact_last_name Text
Contact last name contact_phone Number Contact phone number contact_fax Number Contact
fax number This entity outlines the Contacts for the Vendors that Huffman Trucking does
business with. A Vendor may have 1 or more contacts, such as a Billing Contact and an Order
Contact.
Contact types contact_type Text PK that helps identify a unique contact type. This
attribute is an intelligent key vs. a non-intelligent key, which can be used on its own to perform
basic filtering.
contact_type_description Text Contact type long description. Ex: Order Contact, Billing
Contact.
This entity is a reference table and simply helps identify the Vendor contact type. This
transaction.
This entity outlines the Parts that Huffman Trucking has purchased from its Vendors. A
outlines inventory activity, such as adds or deletes. A delete would be damaged part returned to a
Vendor.
and simply helps identify the Transaction type. This entity will reduce maintenance and improve
Catalogue along with the Tire Maintenance entity. In short a part has one and only one Vendor,
helps identify the Vehicle description. This entity will ensure consistency.
vehicleaccumulated_depreciationCurrencyAmount depreciation in
dollarsCapacityNumberAmount of freight the vehicle can haulThis entity stores the primary
characteristics of the vehicles Huffman Trucking owns. This entity relates to the
summary table, whereas the relationship between the vehicle and maintenance_work_order is 1
to many.
maintenance_type_idNumberReference to
warrantyThis entity is primarily a summary table which will store information as to the current
state of maintenance on a vehicle, and a method to track last maintenance and next maintenance
attributes for a vehicle. This entity has a 1 to 1 relationship with the vehicle entity.
track what types of tires are installed on each vehicle and what the state of said maintenance is
for that vehicle / tire combination. It relates to the vehicle table having a 1 to 1 relationship.
was completedThis entity will act as the primary table for tracking the maintenance of a single
vehicle. That is, it will relate to the vehicle table via the VIN. Hence, a vehicle can have a single
or many work orders where as a single work order can only relate to one vehicle.
will uniquely identify each job/work order being done on the vehicle.
itemdate_completedDateDate ended for a particular line itemThis is a child table to the parent
table maintenance_work_order that is joined by the work_order_id. The purpose of this table is
to track each line item/job that makes up a work order. Therefore, a work order can have one or
more line items but a single line item can only belong to one work order. In addition,
maintenance_work_order_line will also join to the orders table via the work_order_line_id. This
will ultimately allow the tracking of each individual part to be associated to a specific
maintenance line item by then joining to the parts catalogue.
maintenance_work_order_line tableThis table will serve as an associative table that will bridge
the gap between the maintenance_work_order_line table and the parts_catalogue table. This will
allow a work order line to have one or many parts and a single part or many parts can belong to a
maintenance_work_order_line.
entity is a reference table and simply helps identify the various types of maintenance. This entity
Excellent list of entities and their descriptions! Entity Relationship Diagram – Good ERD!
https://ecampus.phoenix.edu/secure/aapd/CIST/VOP/Business/Huffman/InterSite1/Huff
Attributes for Fleet Truck Maintenance. Retrieved February 19, 2006, from University of
Phoenix VOP:
https://ecampus.phoenix.edu/secure/aapd/CIST/VOP/Business/Huffman/IT/Databases/Hu
ffmanDatabasesEntities%20and%20Attributes%20for%20Fleet%20Truck