0% found this document useful (0 votes)
31 views24 pages

Chapter 5 - From Conceptual Design To Relational Implementation

Uploaded by

Ibrahima Diallo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
31 views24 pages

Chapter 5 - From Conceptual Design To Relational Implementation

Uploaded by

Ibrahima Diallo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 24

Chapter 5: From

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

SavingsAccount ( SavingsAccountID, CustomerID)


◦ Foreign Key: CustomerID references Customer
Relationships (1:M)

CheckingAccount (CheckingAccountID, CustomerID)


◦ Foreign Key: CustomerID references Customer

Customer (CustomerID)

In any one-many relationship, the relation describing the set on


the many side contains the foreign key that points to the other
relation.
Relationships (M:M)

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

Customer (CustomerID) HasCheckingAccount (CustomerID, CheckingAccountID) CheckingAccount (CheckingAccountID)


Foreign Key: CustomerID references Customer
Foreign Key: CheckingAcccountID references CheckingAccount
Example (Association Class with Attributes)

Title

Student (StudentID, Name)


Course (CourseID, Title)
Enrollment (StudentID, CourseID, Grade)
Foreign Key: StudentID references Student
Foreign Key: CourseID references Course
Recursive Relationships
Incorrect, but intuitive:
Employee (EmployeeID, FirstName, LastName, Phone, HireDate, EmployeeID)
Foreign Key: EmployeeID references Employee

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]

Other data types for binary, media, and other data.


SQL DDL for Customer Table Revisited
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) )
SQL DDL for Sale Table
CREATE TABLE Sale (
SaleID INT NOT NULL,
SaleDate DATE NOT NULL,
Tax NUMERIC(8,2) NOT NULL,
Shipping NUMERIC(8,2) NOT NULL,
CustomerID INT,
PRIMARY KEY (SaleID),
FOREIGN KEY (CustomerID) REFERENCES Customer ON
DELETE SET NULL)
Primary Keys
Two ways to define primary keys (if PK is a single field):
CREATE TABLE Customer (
CustomerID INT NOT NULL,
…,
PRIMARY KEY (CustomerID) )
CREATE TABLE Customer (
CustomerID INT NOT NULL PRIMARY KEY)
Foreign Keys
Create Table Sale(
…,
CustomerID INT,
Foreign Key (CustomerID) references Customer On Delete Set Null)
What does, “On Delete Set Null” mean?
◦ If a customer is deleted, any sales for that customer will be updated to reflect NULL for the CustomerID
Options:
◦ Set Null – deletion of customer results in CustomerID set to NULL for all sales related to that customer
◦ Restrict – deletion of customer not allowed if there are sales for that customer
◦ Cascade – deletion of customer results in deletion of any sales for that customer
◦ Set Default – deletion of customer results in CustomerID set to default (dummy) value for all sales
related to that customer
SQL DDL Statements
Create – add a database object (table, column, PK/FK)
Drop – delete a database object (table, column, PK/FK)
Alter – change a database table
Examples:
◦ Alter Table Employee Add CellPhone VarChar(255);
◦ Alter Table Employee Drop CellPhone;
◦ Alter Table Customer Add Primary key CustomerID;
◦ Alter Table Product Add Foreign Key (ManufacturerID) references Manufacturer On Delete
Cascade;

You might also like