The central maintenance facility for Huffman Trucking is presently sited in Cleveland,

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

next three years and will be included in the support cost.

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

understands the challenges involved in a high-performance transactional situation such as this

one. For the case of Huffman trucking, this may not be an issue. The third requirement will be to

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.

Impacts and Benefits

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.

•Less likely to miss maintenance leading to reduced unscheduled maintenance.

•Allow data sharing across Huffman Trucking Corporation.

•Standardized record keeping across all of the companies locations

•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

not limited to the following:

•Automated parts ordering

•Automated settlement with parts vendors

•Automated maintenance schedule proposals based on historical trends.

 •Enable maintenance to be performed in any of Huffman’s hubs regardless of the vehicles

home hub location very good.

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

maintenance schedules will be inconsistent between hubs.

Deliverables and Measurement

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.

Business Rules in Design

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

maximize the return on capital investment.

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

additional inventory is on hand for unscheduled maintenance.

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

report or automatically initiated. biz rules are good.

Proposed Design and Solution

The proposed solution is to create a shared concept database using Microsoft Access. No

additional software will need to be purchased, as Microsoft Access is already Huffman

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.

Entity Description - Data Dictionary

The following is a data dictionary describing the purpose of each of the table their names,

attributes, primary and foreign keys, as well as its purpose.

Table 1. Data Dictionary

Entity Attribute Name

Type Attribute Description

Entity Description

Vendor’s Vendor id Number

Primary key (PK) that helps identifies a unique vendor.

Vendor name Text Vendor names associated with parts.

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

Catalog ID Number PK that helps identifies a unique part:

Vendor id Number FK to Vendors

Part name Text Name given to a part.

Part description Text Long description of a part

Part type Text the part type or category it falls into

Manufacturer id Number FK to Manufacturers

Quantity on hand Number Number on hand for a specific part

Reorder point Number Reorder point when running low.

 Reorder quantity Number Reorder quantity when reorder is made.

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.

Contacts Contact id Number PK Contact type Text PK - OC = Order Contact, BC

= Billing Contact.

vendor_id Number PK & FK to Vendorsaddress_1 Text Contact address line 1address_2

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

entity will reduce maintenance and improve data consistency.

Parts Purchasing History transaction_id Number PK that helps identify a unique

transaction.

catalog_id Number FK to Parts Catalogue quantity_purchased Number Quantity

purchased quantity_ordered Number Quantity ordered Price Currency Price per

partShippingCurrencyShipping cost associated with the purchaseTaxCurrencyTax associated

with the purchaseFOBBoolean Free on board indicator.

This entity outlines the Parts that Huffman Trucking has purchased from its Vendors. A

transaction is considered a purchase of a specific part.

Inventory Activitytransaction_idNumberPK unique inventory activity. Compound key

with typetransaction_typeTextPK part of the unique key.

DateDateDate of the activity and is related to the transaction typePriceCurrencyAmount

of the activityQuantityNumberQuantity of activity, related to the transaction typeThis entity

outlines inventory activity, such as adds or deletes. A delete would be damaged part returned to a

Vendor.

Transaction Typestransaction_typeTextPK that helps identify a unique transaction.

transaction_descriptionTextTransaction long descriptionThis entity is a reference table

and simply helps identify the Transaction type. This entity will reduce maintenance and improve

data consistency and relates to the Inventory Activity entity.

Manufacturersmanufacturer_idNumberPK that helps identify a unique

manufacturermanufacturer_nameTextManufacturer long nameThis entity relates to the Parts

Catalogue along with the Tire Maintenance entity. In short a part has one and only one Vendor,

but a Vendor can have one or more parts.

Vehicle_Typesvehicle_type_idNumberPK to uniquely identify the various types of

vehiclesDescriptionTextDescription of the vehicle typeThis entity is a reference table and simply

helps identify the Vehicle description. This entity will ensure consistency.

VehiclesVINTextPK-Logical key that identifies a unique

vehiclevehicle_type_idNumberFK to vehicle_typeclass_codeTextClassification of the

vehiclegross_weightNumberWeight of the vehicleMileageNumberMileage of the vehicle at time

of purchasepurchase_priceNumberPurchase price of the

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

vehicle_maintenace, tire_maintenance, and maintenance_work_order entities. The vehicle table

relates to the vehicle_maintenance and tire_maintenance as a 1 to 1 and acts as more or less a

summary table, whereas the relationship between the vehicle and maintenance_work_order is 1

to many.

Vehicle_MaintenanceVINTextPK-Logical key that identifies a unique vehicle.

maintenance_type_idNumberReference to

maintenance_work_orderlast_maintenance_dateDateReference to last time the vehicle was

servicednext_maintenance_dateDateCalculated field based on the value of the

last_maintenance_dateunder_warranty_flagBoolean Y/N variable if the vehicle is under

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.

tire_maintenanceVINTextPK-Logical key that identifies a unique

vehicletire_barcodeNumberNumber that uniquely identifies a single tire.

tire_maint_typeTexttype of service specifically to tires on a

vehiclemanufacturer_idNumberFK - ID that ties back to specific manufacturer.

tire_maintenance_dateDateDate the tires were last serviced or

installedrotation_mileageNumberNumber of miles per rotationrotation_scheduleDateNext

scheduled tire rotationdisposal_dateDateDate which tires were disposedThis entity is used to

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.

maintenance_work_orderwork_order_idAutoNumberPK which uniquely identifies a

specific work order.

VINTextFK-This will link a work order to a specific vehicle

tablemaintenance_type_idNumberFK - ID identifying the type of maintenance that was done.

date_startedDateDate the maintenance begandate_completedDateDate when maintenance

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.

maintenance_work_order_linework_order_line_idAutoNumberPK - Surrogate key that

will uniquely identify each job/work order being done on the vehicle.

work_order_idNumberFK - foreign key to

maintenance_work_orderline_descriptionTextline Descriptionassigned_toTextName of the

mechanichoursNumberLength of jobdate_startedDateDate started for a particular line

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.

Orderscatalogue_idNumberPK- compound key that will join to the parts_catalgue

tablework_order_line_idNumberPK -compound key that will join to the

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.

maintenance_typesmaintenance_type_idAutoNumberPK - Surrogate key that will

uniquely identify each maintenance type.

level_codeNumberNumber designating the degree of scopedescriptionTextDescription of

a particular jobavg_hours_requiredNumberAvg shop time needed to complete the

jobrecommended_scheduleNumberRecommended time between services for a particular

servicemaximum_scheduleNumberMaximum time between services for a particular serviceThis

entity is a reference table and simply helps identify the various types of maintenance. This entity

will reduce data maintenance and improve data consistency.

Excellent list of entities and their descriptions! Entity Relationship Diagram – Good ERD!

References University of Phoenix. (2006). Huffman Trucking VOP Site. Retrieved

February 19, 2006, from University of Phoenix VOP:

https://ecampus.phoenix.edu/secure/aapd/CIST/VOP/Business/Huffman/InterSite1/Huff

manInterPort.htmUniversity of Phoenix. (2006). Huffman Trucking: Entities and

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

%20Maintenance.docOverall, an excellent assignment!