Running head: HUFFMAN TRUCKING
Huffman Trucking: Database Design and Development
Huffman Trucking started out as a single owner, single truck and trailer, operating in the Cleveland Ohio area back in 1936 doing local contract hauls. Today, Huffman Trucking is a National carrier with 1,400 employees, 800 tractors, 2,100 trailers, and 260 roll-on/roll-off units, operating from 3 logistical hubs located in Los Angeles, California, St. Louis, Missouri, and Bayonne, New Jersey and its central maintenance facility located in Cleveland Ohio (Apollo Group Inc., 2005). With the growth through the years, Huffman Trucking has maintained their competitiveness by being an industry leader in leveraging technology to the maximum to provide customer service and business efficiencies (Apollo Group Inc., 2005). In the means to maintain this competitiveness, Huffman Trucking hired Smith Systems Consulting to develop a report of entities and attributes that will be needed for a Fleet Truck Maintenance Database. Upon receipt of Smith’s report detailing the entities and attributes needed, our IT Manager submitted a Service Request SR-ht-003 to design a Fleet Truck Maintenance Database. In the following paragraphs LTA will discuss the database architecture briefly and primary keys, which play a vital role in an Entity-Relational Database. The discussions of the different types of mistakes that are made in the design phase that led to a poor database design are also discussed. Mistakes include the lack of careful planning, proper normalization of data, poor naming conventions, lack of sufficient documentation and extensive testing. The ERD for the database will be revealed along with the choice of the program to manage the database and allow for versatility for various platforms, applications, and features. Huffman Trucking’s fleet truck maintenance records are fairly straight-forward, therefore, a basic database design architecture is recommended as a start in the entry of information, and importing of current database records into the new basic database. By starting simple, this database can be upgraded over time, as the company grows and the fleet grows. The important items to consider when designing a new database include: ease of use for the users, the production of query reporting, as well as financial records, parts orders, maintenance records, and purchase orders. “A good model and a proper database design form the foundation of an information system. Building the data layer is often the first critical step towards implementing a new system, and getting it right requires attention to detail and a whole lot of careful planning. A database, like any computer system, is a model of a small piece of the real world. And, like any model, it’s a narrow representation that disregards much of the complexity of the real thing” (Malone, 2007).
A primary key, which is a record or an attribute, uniquely identifies a table. Primary keys make mapping relational data simple, in order to uniquely identify each entry in the database. The concept of some sort of unique value is common in database designing — using account numbers to identify part numbers, vendor numbers, and maintenance work orders. These are also known as natural keys, common entities that are used to uniquely identify objects. Generally, if the data that is being modeled has a decent natural key, or identifier, that information should not be used as a primary key. Natural keys should not be used as primary keys, as the purpose of the primary key is to uniquely identify a value in a database record. Several primary key characteristics are the primary key must be able to identify each row in a table. The primary key should not describe the characteristics of the entity. A part number ID of “2566” is usually preferred over “Air Filter.” The value of a primary key should never change. Changing a primary...
Please join StudyMode to read the full document