Assignment 3 ISQS 6338: Database Management Systems Jeffrey P. Morris 11/16/2009 Assignment 3 Jeff Morris Table of Contents Assignment 1 (Revised) ........................................................................................................................................................ 1 Introduction ........................................................................................................................................................................ 1 Objects ................................................................................................................................................................................ 1 Relationships ....................................................................................................................................................................... 1 Assignment 2 (Revised) ........................................................................................................................................................ 3 Initial Relational Data Model .............................................................................................................................................. 3 Definition of Attributes ....................................................................................................................................................... 3 Manufacturer .................................................................................................................................................................. 3 VehicleModel .................................................................................................................................................................. 3 Color ................................................................................................................................................................................ 4 Vehicle ............................................................................................................................................................................. 4 FuelType .......................................................................................................................................................................... 4 Feature ............................................................................................................................................................................ 4 Normalization of Relations ................................................................................................................................................. 5 Final Relational Data Model ................................................................................................................................................ 6 Validation of Relational Data Model ................................................................................................................................... 7 Non-Functional Requirements ............................................................................................................................................ 9 Volume ............................................................................................................................................................................ 9 Indexes ............................................................................................................................................................................ 9 Integrity Constraints ....................................................................................................................................................... 9 Assignment 3 ....................................................................................................................................................................... 10 Physical Database Design .................................................................................................................................................. 10 VehicleModel ................................................................................................................................................................ 10 VehicleModelColor........................................................................................................................................................ 10 Color .............................................................................................................................................................................. 10 Vehicle ........................................................................................................................................................................... 11 Manufacturer ................................................................................................................................................................ 11 VehicleFeature .............................................................................................................................................................. 11 Feature .......................................................................................................................................................................... 12 VehicleFuelType ............................................................................................................................................................ 12 FuelType ........................................................................................................................................................................ 12 Database Size (Disk Space Requirement).......................................................................................................................... 13 Page ii Assignment 3 Jeff Morris Page iii Assignment 3 Jeff Morris Assignment 1 (Revised) Introduction AD is a car dealership wishing to optimize their business by utilizing database technologies. Business rules were defined in the initially analysis and are further displayed in the object types, relationships and an object-oriented data model. To allow AD to use database technologies, we will first need to analyze all of the object types related to this business problem. Next, we need to define the relationship between these object types. Lastly, we can create an object-oriented data model. Objects Below are the objects discovered during the analysis: Manufacturer: The Attributes are ManufacturerID, MfrName, MfrStreet, MfrCity, MfrState, MfrZip, MfrCountry, and MfrPhone Vehicle: The Attributes are VIN, VehicleDescription, VehicleBasePrice, VehicleBaseCost, VehicleFreightPrepCost, VehicleTaxCost and VehicleLicenseFee VehicleModel: The Attributes are ModelName, ModelYear, ModelType, and ModelDescription Feature: The Attributes are FeatureID, FeatureName, FeatureDescription, FeatureCost, and FeaturePrice Color: The Attributes are ColorID, ColorName, ColorDescription, and ColorType FuelType: The Attributes are FuelID, FuelName, FuelDescription, and OctaneRating Relationships After analysis of the business rules, the following relationships exist in our model: A many to many relationship between FuelType and Vehicle named “Used By” A many to many relationship between Feature and Vehicle named “Has Feature” A many to many relationship between Color and VehicleModel named “Has Color” A one to many relationship between VehicleModel and Vehicle named “Has Models” A one to many relationship between Manufacturer and VehicleModel named “Makes” A one to many relationship between Color and Vehicle named “Available In” Page 1 Assignment 3 Jeff Morris Object-Oriented Data (OOD) Model VehicleModelColor Manufacturer -ManufacturerID -MfrName -MfrStreet -MfrCity -MfrState -MfrZip -MfrCountry -MfrPhone VehicleModel -Makes 1 * -ModelName -ModelYear -ModelType -ModelDescription -ModelStartYear Color * 1..* -ColorID -ColorName -ColorDescription -ColorType -Has Color 1 * 1 -Has Models Vehicle FuelType -FuelID -FuelName -FuelDescription -OctaneRating * * -Used By VehicleFuelType -Avaliable In -VIN -VehicleDescription -VehicleBasePrice -VehicleBaseCost -VehicleFreightPrepCost -VehicleTaxCost -VehicleLicenseFee * Feature * * -Has Feature VehicleFeature Page 2 -FeatureID -FeatureName -FeatureDescription -FeatureCost -FeaturePrice Assignment 3 Jeff Morris Assignment 2 (Revised) Initial Relational Data Model Please note that a primary key is indicated by underling the attribute(s). A foreign key is shown in italics. VehicleModel (ModelName, ModelYear, ModelType, ModelDescription, ModelStartYear, ManufacturerID) VehicleModelColor (ModelName, ColorID) Color(ColorID, ColorName, ColorDescription, ColorType) Vehicle (VIN, VehicleDescription, VehicleBasePrice, VehicleBaseCost, VehicleFreightPrepCost, VehicleTaxCost, VehicleLicenseFee, ColorID, ModelName) Manufacturer (ManufacturerID, MfrName, MfrStreet, MfrCity, MfrState, MfrZip, MfrCountry, MfrPhone) VehicleFeature (VIN, FeatureID) Feature (FeatureID, FeatureName, FeatureDescription, FeatureCost, FeaturePrice) VehicleFuelType (VIN, FuelID) FuelType (FuelID, FuelName, FuelDescription, OctaneRating) Definition of Attributes In this section, we will provide a description of each attribute to better help the user understand what each attribute represents. This will also help to describe relations and distinguish attributes as a primary key or foreign key. Manufacturer ManufacturerID: This will serve as the primary key for the manufacturer table. It will contain a unique id generated for each manufacturer. It will be defined as an integer type data, which can support a value from 1 to 99,999. MfrName: This will store the name of the manufacturer. It can contain any alphanumeric data type. MfrStreet: This will store the street address of the manufacturer. It can contain any alphanumeric data type. MfrCity: This will store the city of the manufacturer. It can contain any alphanumeric data type. MfrState: This will store the state of the manufacturer. It can contain two char data types. MfrCountry: This will store the name of the country where the manufacturer is from. It can contain any alphanumeric data type. MfrPhone: It is used to store the telephone of a manufacturer. It holds an alphanumeric data. It should be large enough to store international telephone numbers. VehicleModel ModelName: This will be used to store the name of the model. It can contain any alphanumeric data type. ModelYear: This will be used to store the year this particular model was produced. It will contain any numeric data type. ModelType: This will store the type of vehicle model. It will contain any alphanumeric data type. ModelDescription: This will store the description of the vehicle model. It will contain any alphanumeric data type. ModelStartYear: This will be used to store the start year this particular model was produced. It will contain any numeric data type. Page 3 Assignment 3 Jeff Morris Color ColorID: This will serve as the primary key for the color table. It will contain a unique id generated for each color. It will be defined as an integer type data, which can support a value from 1 to 99,999. ColorName: This will be used to store the name of the color. It can contain any alphanumeric data type. ColorDescription: This will store the description of the color. It will contain any alphanumeric data type. ColorType: This will store the type of color. It will contain any alphanumeric data type. Vehicle VIN: This attribute is used to store the VIN number of a book. This will act as a primary key for the vehicle table as it is assumed that each book has a unique VIN number. It can contain any alphanumeric data type. VehicleDescription: This will store the description of the vehicle. It will contain any alphanumeric data type. VehicleBasePrice: This will store the starting price of the vehicle. It will contain any money data type. VehicleBaseCost: This will store the cost of the vehicle. It will contain any money data type. VehicleFreightPrepCost: This will store any costs associated with shipping a vehicle. It will contain any money data type. VehicleTaxCost: This will store the tax cost associated with a vehicle. It will contain any money data type. VehicleLicenseFee: This will store any associated license fees associated with a vehicle. It will contain any money data type. FuelType FuelID: This will serve as the primary key for the fuel type table. It will contain a unique id generated for each fuel type. It will be defined as an integer type data, which can support a value from 1 to 99,999. FuelName: This will be used to store the name of the fuel type. It can contain any alphanumeric data type. FuelDescription: This will be used to provide a description about the fuel type. It can contain any alphanumeric data type. OctaneRating: This will store the octane rating for the fuel. It will contain any numeric data type. Feature FeatureID: This will serve as the primary key for the feature table. It will contain a unique id generated for each feature. It will be defined as an integer type data, which can support a value from 1 to 99,999. FeatureName: This will be used to store the name of the feature. It can contain any alphanumeric data type. FeatureDescription: This will store the description of the feature. It will contain any alphanumeric data type. FeatureCost: This will store the cost associated with a feature. It will contain any money data type. FeaturePrice: This will store the price associated with a feature. It will contain any money data type. Page 4 Assignment 3 Jeff Morris Normalization of Relations It is important to ensure that a data model is normalized to eliminate the possibility of update, insert and deletion anomalies. To properly do this, one must make sure that only one value is contained per tuple. A 2NF relation will make sure there are no partial dependencies between the primary key and non-key attributes. Finally, a 3NF relation will eliminate transitive dependency between primary keys and non-key attributes. VehicleModel (ModelName, ModelYear, ModelType, ModelDescription, ModelStartYear, ManufacturerID) The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute contains only one value for each row. The above relation is also in 2NF because there is no question of partial dependency between the primary key and the non-key attributes. The VehicleModel relation is also in 3NF because each non-key attribute is not dependent on any other VehicleModelColor (ModelName, ColorID) The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute contains only one value for each row. The above relation is also in 2NF because there is no question of partial dependency between the primary key and the non-key attributes. The VehicleModelColor relation is also in 3NF because each non-key attribute is not dependent on any other Color(ColorID, ColorName, ColorDescription, ColorType) The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute contains only one value for each row. The above relation is also in 2NF because there is no question of partial dependency between the primary key and the non-key attributes. The Color relation is also in 3NF because each non-key attribute is not dependent on any other Vehicle (VIN, VehicleDescription, VehicleBasePrice, VehicleBaseCost, VehicleFreightPrepCost, VehicleTaxCost, VehicleLicenseFee, ColorID, ModelName) The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute contains only one value for each row. The above relation is also in 2NF because there is no question of partial dependency between the primary key and the non-key attributes. The Vehicle relation is also in 3NF because each non-key attribute is not dependent on any other Manufacturer (ManufacturerID, MfrName, MfrStreet, MfrCity, MfrState, MfrZip, MfrCountry, MfrPhone) The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute contains only one value for each row. The above relation is also in 2NF because there is no question of partial dependency between the primary key and the non-key attributes. The Manufacturer relation is also in 3NF because each non-key attribute is not dependent on any other VehicleFeature (VIN, FeatureID) The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute contains only one value for each row. The above relation is also in 2NF because there is no question of partial dependency between the primary key and the non-key attributes. The VehcielFeature relation is also in 3NF because each non-key attribute is not dependent on any other Page 5 Assignment 3 Jeff Morris Feature (FeatureID, FeatureName, FeatureDescription, FeatureCost, FeaturePrice) The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute contains only one value for each row. The above relation is also in 2NF because there is no question of partial dependency between the primary key and the non-key attributes. The Feature relation is also in 3NF because each non-key attribute is not dependent on any other VehicleFuelType (VIN, FuelID) The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute contains only one value for each row. The above relation is also in 2NF because there is no question of partial dependency between the primary key and the non-key attributes. The VehicleFuelType relation is also in 3NF because each non-key attribute is not dependent on any other FuelType (FuelID, FuelName, FuelDescription, OctaneRating) The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute contains only one value for each row. The above relation is also in 2NF because there is no question of partial dependency between the primary key and the non-key attributes. The FuelType relation is also in 3NF because each non-key attribute is not dependent on any other Final Relational Data Model Please note that a primary key is indicated by underling the attribute(s). A foreign key is shown in italics. Below is the final relational data model: VehicleModel (ModelName, ModelYear, ModelType, ModelDescription, ModelStartYear, ManufacturerID) VehicleModelColor (ModelName, ColorID) Color(ColorID, ColorName, ColorDescription, ColorType) Vehicle (VIN, VehicleDescription, VehicleBasePrice, VehicleBaseCost, VehicleFreightPrepCost, VehicleTaxCost, VehicleLicenseFee, ColorID, ModelName) Manufacturer (ManufacturerID, MfrName, MfrStreet, MfrCity, MfrState, MfrZip, MfrCountry, MfrPhone) VehicleFeature (VIN, FeatureID) Feature (FeatureID, FeatureName, FeatureDescription, FeatureCost, FeaturePrice) VehicleFuelType (VIN, FuelID) FuelType (FuelID, FuelName, FuelDescription, OctaneRating) Page 6 Assignment 3 Jeff Morris Validation of Relational Data Model To make sure we have covered all the business requirements and setup proper relationships between each model, we will provide the required models to properly execute each query mentioned below. Query #1: How many models do we carry from a manufacturer (name)? Given: Manufacture Name Relations: Manufacturer (ManufacturerID, MfrName) VehicleModel (ModelName, ManufacturerID) Query #2: Do we have any vehicles of a particular model? Given: Model Name Relations: VehicleModel (ModelName) Vehicle (VIN, VehicleDescription, ModelName) Query #3: Do we have any vehicle in stock with air conditioning and GPS navigation? Given: Feature Names: Air Conditioning and GPS Navigation Relations: VehicleFeature(FeatureName, VIN) Query #4: Do we have any vehicle manufactured by Ford for under $16,000? Given: Manufacturer Name, Price Relations: Manufacturer (ManufacturerID, MfrName) VehicleModel (ModelName, ManufacturerID) Vehicle (VIN, ModelName, VehicleBasePrice) VehicleFeature (VIN, FeatureName) Feature (FeatureName, FeaturePrice) Query #5: What's the profit margin on a vehicle? Given: VIN Relations: Vehicle (VIN, VehicleBasePrice, VehicleBaseCost, VehicleFreightPrepCost, VehicleTaxCost, VehicleLicenseFee) VehicleFeature (VIN, FeatureID) Feature (FeatureID, FeatureCost, FeaturePrice) Query #6: How many colors does a vehicle come in? Given: VIN Relations: VehicleModelColor (ModelName, ColorID) Page 7 Assignment 3 Jeff Morris Query #7: How many colors of a vehicle are there in AD's stock? Given: VIN Relations: Vehicle (VIN, ModelName) VehicleModelColor (ModelName, ColorID) Color (ColorID, ColorName) Query #8: What are different types of fuel used by a vehicle? Given: Vehicle Relations: VehicleFuelType (VIN, FuelID) Query #9: How many vehicles do we have in stock from a manufacturer (name)? Given: Manufacturer Name Relations: Manufacturer (ManufacturerID, MfrName) VehicleModel (ModelName , ManufacturerID) Vehicle (VIN, VehicleDescription, ModelName) As proven above, the relational data model has all the necessary relations and attributes needed to fulfill the business requirements and queries. Therefore, they is no need to change the model. Page 8 Assignment 3 Jeff Morris Non-Functional Requirements Volume It is important to appropriately assign data type values to each attributes based on the number projected. Relation Manufacturer VehicleModel Vehicle FuelType Feature Color VehicleModelColor VehicleFuelType VehicleFeature 20 Estimated Number of Rows Comments As per user requirements 120 Six models per manufacturer 1,200 10 cars per model/manufacturer 10 As per user requirements 25 As per user requirements 20 As per user requirements 600 About 5 colors/model 2,400 Two fueltypes per vehicle 6,000 Five features per vehicle Indexes To speed up response time and ease of access, it is imperative to maintain proper indexes An index should be created on MfrName, ModelName, and VIN Integrity Constraints To properly enforce business rules, it is important to properly declare constraints A Vehicle can only have one Color A Vehicle must have at least one Fuel Type A Vehicle can only have one VehicleModel A VehicleModel can only have one Manufacturer A VehicleModel must have at least one Color Page 9 Assignment 3 Jeff Morris Assignment 3 Physical Database Design Now that we have our logical database design finalized, it is time to turn those platform-independent models into one that a platform-specific database management system. For our purposes, we have decided to utilize the latest database technology sold by Microsoft, SQL Server 2008. First, we need to define all of the attributes, their data type, if the attribute will accept a null value and whether or not it should be indexed. We will assume that there is an automatic index for Primary and Foreign Keys. Lastly, we will specify additional attributes that should be indexed based on the rules set earlier. VehicleModel Attribute (Field) Data Type Null (Yes or No) Index Security ModelName Varchar (15) No Yes (Primary) N/A ModelYear Varchar (4) No No N/A ModelType Varchar (15) No No N/A ModelDescription Varchar (25) Yes No N/A ModelStartYear Varchar (4) No No N/A ManufacturerID Integer (4 Bytes) No Yes (Foreign) N/A VehicleModelColor Attribute (Field) Data Type Null (Yes or No) Index Security ModelName Varchar (15) No Yes (Primary), Foreign N/A ColorID Integer (4 Bytes) No Yes (Primary), Foreign N/A Color Attribute (Field) Data Type Null (Yes or No) Index Security ColorID Integer (4 Bytes) No Yes (Primary) N/A ColorName Varchar (15) No Yes N/A ColorDescription Varchar (25) Yes No N/A ColorType Varchar (15) No No N/A Page 10 Assignment 3 Jeff Morris Vehicle Attribute (Field) Data Type Null (Yes or No) Index Security VIN Varchar(6) No Yes (Primary) N/A VehicleDescription Varchar (25) Yes No N/A VehicleBasePrice Money (8 bytes) No No N/A VehicleBaseCost Money (8 bytes) No No N/A VehicleFreightPrepCost Money (8 bytes) No No N/A VehicleTaxCost Money (8 bytes) No No N/A VehicleLicenseFee Money (8 bytes) No No N/A ColorID Integer (4 Bytes) No Yes (Foreign) N/A ModelName Varchar (15) No Yes (Foreign) N/A Manufacturer Attribute (Field) Data Type Null (Yes or No) Index Security ManufacturerID Integer (4 Bytes) No Yes (Primary) N/A MfrName Varchar (20) No Yes N/A MfrStreet Varchar (30) Yes No N/A MfrCity Varchar (20) Yes No N/A MfrState Varchar (2) Yes No N/A MfrZip Varchar (10) Yes No N/A MfrCountry Varchar (15) No Yes N/A MfrPhone Varchar (10) Yes No N/A VehicleFeature Attribute (Field) Data Type Null (Yes or No) Index Security VIN Varchar(6) No Yes (Primary), Foreign N/A FeatureID Integer (4 Bytes) No Yes (Primary), Foreign N/A Page 11 Assignment 3 Jeff Morris Feature Attribute (Field) Data Type Null (Yes or No) Index Security FeatureID Integer (4 Bytes) No Yes (Primary) N/A FeatureName Varchar (30) No Yes N/A FeatureDescription Varchar (50) Yes No N/A FeatureCost Money (8 bytes) No No N/A FeaturePrice Money (8 bytes) No No N/A VehicleFuelType Attribute (Field) Data Type Null (Yes or No) Index Security VIN Varchar(6) No Yes (Primary), Foreign N/A FuelID Integer (4 Bytes) No Yes (Primary), Foreign N/A FuelType Attribute (Field) Data Type Null (Yes or No) Index Security FuelID Integer (4 Bytes) No Yes (Primary) N/A FuelName Varchar(15) No Yes N/A FuelDescription Varchar (25) Yes No N/A OctaneRating Tinyint (2) No No N/A Page 12 Assignment 3 Jeff Morris Database Size (Disk Space Requirement) It is important to estimate the total size of the database based upon the table sizes and volumes. We will follow the following guidelines to compute the database size in bytes. 1. Compute the basic size of each table by adding the attribute-sizes and multiplying it by the table-volume. 2. Add 40% as overhead for each index (including PK and FKs) 3. Compute the database size by adding the sizes of all tables. 4. Multiply the number in step 3 by 1.5 to account for unexpected future growth. Basic Size of One Row VehicleModel VehicleModelColor Color Vehicle Manufacturer VehicleFeature Feature VehicleFuelType FuelType Basic Size of a Table Index Overhead Total for Each Table Total Database Size 67 8,040 9,648 17,688 26,532 19 11,400 9,120 20,520 30,780 59 1,180 472 1,652 2,478 90 108,000 129,600 237,600 356,400 111 2,220 1,776 3,996 5,994 10 60,000 48,000 108,000 162,000 100 2,500 2,000 4,500 6,750 10 24,000 19,200 43,200 64,800 46 460 184 644 966 Estimated Database Size Table. Showing the computation of the size of the AD Car Dealership database. We see that the estimated database size is about .656 MB (megabytes). Page 13 656,700