Chapter 5 - From Conceptual Design To Relational Implementation
Chapter 5 - From Conceptual Design To Relational Implementation
Conceptual Design to
Relational Implementation
DATABASE MANAGEMENT AND DESIGN
Why Translate?
Conceptual design leads to better models
Relational designs are more ready for implementation
Transforming Base Sets and Attributes
Base (entity) set – not derived from another set (not a subset or
relationship set)
Step 1 – Use base (entity) name as relation (table) name
Step 2 – Use base attributes as relation attributes
Step 3 – Add necessary primary keys (they will likely already be
there)
Base Set Example
Base (entity) name – Sale
Attributes – ProductName, Amount
Primary key – SaleID
Schema:
Sale (SaleID, ProductName, Amount)
Specialization/Generalization
Person Set:
Person (PersonID, SSN, Name, Address)
Married Person Set (notice inheritance):
Married Person (PersonID, SSN, Name,
Address, SpouseName)
◦ Foreign Key: PersonID references Person
To avoid redundancy:
Person (PersonID, SSN, Name, Address)
Married Person (PersonID, SpouseName)
◦ Foreign Key: PersonID references Person
Relationships (1:1)
Customer (CustomerID, CheckingAccountID, SavingsAccountID)
Foreign Key: CheckingAccountID references CheckingAccount
Foreign Key: SavingsAccountID references SavingsAccount
CheckingAccount ( CheckingAccountID, CustomerID)
◦ Foreign Key: CustomerID references Customer
SavingsAccount ( SavingsAccountID, CustomerID)
◦ Foreign Key: CustomerID references Customer
Customer ( CustomerID)
CheckingAccount ( CheckingAccountID, CustomerID)
◦ Foreign Key: CustomerID references Customer
Customer (CustomerID)
To transform many-many relationships, we create, in addition to the relations for the two sets,
an intersection relation
Customer (CustomerID)
CheckingAccount (CheckingAccountID)
HasCheckingAccount (CustomerID, CheckingAccountID)
◦ Foreign Key: CustomerID references Customer
◦ Foreign Key: CheckingAcccountID references CheckingAccount
An Intersection Relation for a Many-Many Relationship
Title
This solution is incorrect, because the Employee relation has two attributes
named EmployeeID, and no two attributes in a relation may have the same
name.
Correct:
Employee (EmployeeID, FirstName, LastName, Phone, HireDate, SupervisorID)
Foreign Key: SupervisorID references Employee
Summary
After all translation from conceptual model to relations of specific constructs is complete,
then the resulting schema should be reviewed for redundancy.
All the relations are normalized to Fourth Normal Form. The reason for this is as follows:
§ Functional dependencies, as defined in the relational model, are attributes, one-one
relationships or one-many relationships. The process for converting each of these to
attributes in a relation guaranteed they would only be dependent on key attributes. Thus,
each relation will be 3NF.
§ The multi-valued attributes of the relational model occur only in (binary) many-many
relationships. Since these are converted to relations whose composite keys consist of the
keys of the individual sets, they are guaranteed to be 4NF.
Transformation Example: Red Cat Shoes
On My Educator:
Chapter 5
Section 5-2
Figure 5.12
Creating Tables
Step 1 – Name the Table
Step 2 – Add column names and constraints
Step 3 – Add table constraints (primary and foreign key)
Example:
Customer (CustomerID, FirstName, LastName, StreetAddress, City, State,
PostalCode)
Sale (SaleID, SaleDate, Tax, Shipping, CustomerID)
◦ Foreign Key: CustomerID references Customer
SQL DDL for Customer Table
CREATE TABLE Customer (
CustomerID INT NOT NULL,
FirstName CHAR(30) NOT NULL,
LastName CHAR(30) NOT NULL,
StreetAddress VARCHAR(50) NOT NULL,
City VARCHAR(50) NOT NULL,
State CHAR(2) NOT NULL,
PostalCode CHAR(6) NOT NULL,
PRIMARY KEY (CustomerID) )
Common Column (Attribute) Constraints
Data type – defines the characteristics of the data stored in the column
Identity – used to create an auto populating field (ex auto-numbering primary key) accepts
options arguments of seed (initial value) and increment (step value)
◦ Create TABLE Sale (SaleID INT Identity(1000,5),…)
◦ First SaleID will be 1000, the second will be 1005
Not NULL – prohibits a new record with a null value for the column
Unique – prohibits a new record with a duplicate value for this column
Primary key – combines the NOT NULL and UNIQUE constraints
Check – specifies that values entered into a column satisfy a specified condition
◦ Create TABLE Sale (…,Value Money CHECK (Value>0),…)
◦ Any value entered for the Value field must be greater than 0
Number Data Types SQL Server
Data type Range Storage
bigint -2^63 (-9,223,372,036,854,775,808) to 2^63-1 (9,223,372,036,854,775,807) 8 Bytes
int -2^31 (-2,147,483,648) to 2^31-1 (2,147,483,647) 4 Bytes
smallint -2^15 (-32,768) to 2^15-1 (32,767) 2 Bytes
tinyint 0 to 255 1 Byte
bit 0, 1 1 bit
decimal Precision (p) and Scale (s) à decimal (p,s), 1<=p<=38 (default 18) varies
numeric Same as decimal varies
money -922,337,203,685,477.5808 to 922,337,203,685,477.5807 8 Bytes
smallmoney - 214,748.3648 to 214,748.3647 4 Bytes
Note: approximate number data types, float and real, are also defined by SQL Server
Character Data Types SQL Server
Data type Range Storage
char char(n) where n is a defined # of characters; n is between 1 and 8000. n Bytes
varchar varchar(n) where n is a defined # of characters; n is between 1 and 8000. Actual # of
‘Max’ is 2 GB characters
nchar nchar(n) where n is a defined # of characters; n is between 1 and 4000 n Bytes
nvarchar nvarchar(n) where n is a defined # of characters; n is between 1 and 4000. Actual # of
‘Max’ is 2 GB characters
text and ntext types are eliminated in next iteration of SQL Server
Date & Time Data Types SQL Server
Data type Format Range
time hh:mm:ss[.nnnnnnn]
date YYYY-MM-DD 0001-01-01 through 9999-12-31
datetime2 YYYY-MM-DD hh:mm:ss[.nnnnnnn]