Assignment 3

advertisement
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
Download