1. CS4433 Database Systems
Relational Model

2. ER Model vs. Relational Model
Both are used to model data
ER model has many concepts
Entities, relationships, attributes, etc.
Well-suited for capturing the app. requirements
Not well-suited for computer implementation
Relational model
Has just a single concept: relation
World is represented with a collection of tables
Well-suited for efficient manipulations on computers

3. Name of Table (Relation) Column (Field, Attribute)
Relation: An Example
Name of Table (Relation)
Column (Field, Attribute)
Products
Name
Price
Category
Manufacturer
Gizmo
19.99
Gadgets
Gizmo works
Power gizmo
29.99
Single touch
149.99
Photography
Canon
Multi touch
203.99
househould
Hitachi
Row (Record, Tuple)
Domain (Atomic type)

4. Relations Schema vs. instance = columns vs. rows
Schema of a relation: R(A1, A2, …, Ak)
Relation name
Attribute names
Attribute types (domains)
Schema of a database: R1(…), R2(…),…, Rn(…)
A set of relation schemas
Questions
When do you determine a schema (instance)?
How often do you change your mind?

5. Relations The database maintains a current database state
Updates to the data happen very frequently
Insert a tuple
delete a tuple
update an attribute in a tuple
Updates to the schema are relatively rare, and rather painful. Why?

6. Steps for Transforming a ER model to Relational Design

7. Create a Table for Each Entity
EMPLOYEE (EmployeeNumber, EmployeeName, Phone, , HireDate, ReviewDate, EmpCode)
Primary key is designated by the key symbol
Note shadowless table

8. Specify Column Properties: Null Status
Null status indicates whether or not the value of the column can be NULL.

9. Specify Column Properties: Data Type
Generic data types:
CHAR(n)
VARCHAR(n)
DATE
TIME
MONEY
INTEGER
DECIMAL

10. Specify Column Properties: Data Type + Null Status

11. Defining a Database Schema
A database schema comprises declarations for the relations (“tables”) of the database
Simplest form of creation is:
CREATE TABLE <name> (
<list of elements> );
And you may remove a relation from the database schema by:
DROP TABLE <name>;

12. Elements of Table Declarations
The principal element is a pair consisting of an attribute and a type
The most common types are:
INT or INTEGER (synonyms)
REAL or FLOAT (synonyms)
CHAR(n ) = fixed-length string of n characters
VARCHAR(n ) = variable-length string of up to n characters

13. Example: Create Table
CREATE TABLE Sells ( bar CHAR(20), beer VARCHAR(20), price REAL );

14. Dates and Times DATE and TIME are types in SQL
The form of a date value is DATE ‘yyyy-mm-dd’
Example: DATE ‘ ’ for Sept. 30, 2002
The form of a time value is TIME ‘hh:mm:ss’ with an optional decimal point and fractions of a second following
Example: TIME ‘15:30:02.5’ = two and a half seconds after 3:30PM

15. Declaring Keys
An attribute or list of attributes may be declared PRIMARY KEY or UNIQUE
Each says the attribute(s) so declared functionally determines all the attributes of the relation schema
Single attribute keys
CREATE TABLE Beers (
name CHAR(20) UNIQUE,
manf CHAR(20) );

16. Multi-attribute Keys
CREATE TABLE Sells ( bar CHAR(20), beer VARCHAR(20), price REAL, PRIMARY KEY (bar, beer) );

17. PRIMARY KEY vs. UNIQUE Standard SQL requires these distinctions
There can be only one PRIMARY KEY for a relation, but several UNIQUE attributes
No attribute of a PRIMARY KEY can ever be NULL in any tuple. But attributes declared UNIQUE may have NULL’s, and there may be several tuples with NULL
SQL standard also allows DBMS implementers to make their own distinctions between PRIMARY KEY and UNIQUE
Example: some DBMS might automatically create an index (data structure to speed search) in response to PRIMARY KEY, but not UNIQUE

18. Other Declarations for Attributes
Two other declarations we can make for an attribute are:
NOT NULL means that the value for this attribute may never be NULL
DEFAULT <value> says that if there is no specific value known for this attribute’s component in some tuple, use the stated <value>
CREATE TABLE Drinkers (
name CHAR(30) PRIMARY KEY,
addr CHAR(50)
DEFAULT ‘123 Monroe St.’,
phone CHAR(16) );

19. Example for NULL and DEFAULT
Suppose we insert the fact that Sally is a drinker, but we know neither her address nor her phone
An INSERT with a partial list of attributes makes the insertion possible:
INSERT INTO Drinkers(name)
VALUES(‘Sally’);
If we had declared phone NOT NULL, this insertion would have been rejected
Name
Address
Phone
‘Sally’
‘123 Monroe St.’
NULL

20. Foreign Keys
A Foreign Key is a field whose values are keys in another relation
Must correspond to primary key of the second relation
Like a `logical pointer’
Enrolled
Students
CREATE TABLE Enrolled
( sid CHAR(20), cid CHAR(20), grade CHAR(2),
PRIMARY KEY (sid,cid),
FOREIGN KEY (sid) REFERENCES Students,
FOREIGN KEY (cid) REFERENCES Courses )

21. Referential Integrity
Consider relations Students and Enrolled; sid in Enrolled is a foreign key that references Students
What should be done if an Enrolled tuple with a non-existent student id is inserted?
Reject it!
What should be done if a Students tuple is deleted?
Also delete all Enrolled tuples that refer to it
Disallow deletion of a Students tuple that is referred to
Set sid in Enrolled tuples that refer to it to a default sid
In SQL, also: set sid in Enrolled tuples to NULL
Similar if primary key of Students tuple is updated

22. Adding Attributes
We may change a relation schema by adding a new attribute (“column”) by:
ALTER TABLE <name> ADD
<attribute declaration>;
Example:
ALTER TABLE Bars ADD
phone CHAR(16) DEFAULT ‘unlisted’;

23. Deleting Attributes Remove an attribute from a relation schema by:
ALTER TABLE <name>
DROP <attribute>;
Example: we don’t really need the license attribute for bars:
ALTER TABLE Bars DROP license;

24. Translating ER Diagram to Rel. Design
Basic cases
entity set E = relation with attributes of E
relationship R = relation with attributes being keys of related entity sets + attributes of R
Special cases
combining two relations
translating weak entity sets
translating is-a relationships and subclasses

25. Translating ER Diagrams
since
lot
name
ssn
dname
did
budget
Manages
Employees
Departments
Translation to
relational model?
1-to-1
1-to-Many
Many-to-1
Many-to-Many

26. ER Diagram to Relations
Relational schema
e.g.account=(bname, acct_no, bal)
E/R diagram E
E = ( a1, …, an )
a1 … an E1 R1 E2
R1= ( a1, b1, c1, …, ck )
a1 …. an
c1 …. ck
b1 …. bm

27. ER Diagram to Relations
a1 …. an
c1 …. ck
b1 …. bm
Could have :
R1= ( a1, b1, c1, …, ck )
Put b1 as the key for R1, it is also the key for E2=(b1, …., bn)
Usual strategy (combination)
ignore R1
Add a1, c1, …., ck to E2 instead, i.e.
E2=(b1, …., bn, a1, c1, …, ck)

28. ER Diagram to Relations? R1 ? E2 E1
a1 …. an
c1 …. ck
b1 …. bm
E1 = ( a1, …, an )
E2 = ( b1, …, bm ) R1
R1 = ( a1, b1, c1 …, ck )
E1 = ( a1, …, an ) R1
E2 = ( b1, …, bm , a1, c1, …, ck)
E1 = ( a1, …, an , b1, c1, …, ck) R1
E2 = ( b1, …, bm ) R1
Treat as n:1 or 1:m

29. Entity Set to Relation Employees ssn name lot CREATE TABLE Employees
( ssn CHAR(11),
name CHAR(20),
lot INTEGER,
PRIMARY KEY(ssn) )

30. Relationship Set to Relation
many-to-many
since
lot
name
Employees
ssn
dname
budget
did
Departments
Works_In

31. Relationship Set to Relation
In translating a many-to-many relationship set to a relation, attributes of the relation must include:
Keys for each participating entity set (as foreign keys)
This set of attributes forms a superkey for the relation
All descriptive attributes
CREATE TABLE Works_In(
ssn CHAR(1),
did INTEGER,
since DATE,
PRIMARY KEY (ssn, did),
FOREIGN KEY (ssn) REFERENCES Employees,
FOREIGN KEY (did) REFERENCES Departments )

32. Translating ER Diagrams
Each dept has at most one manager, according to the key constraint on Manages.
since
lot
name
ssn
dname
did
budget
Manages
Employees
Departments
Translation to
relational model?

33. Translating ER Diagrams
Map relationship set to a (virtual) Manages table:
Note that did is the key now!
Separate tables for Employees and Departments
Since each department has a unique manager, we could instead combine Manages and Departments
CREATE TABLE Manages(
ssn CHAR(11),
did INTEGER,
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees,
FOREIGN KEY (did) REFERENCES Departments )
CREATE TABLE Dept_Mgr(
did INTEGER,
dname CHAR(20),
budget REAL,
ssn CHAR(11),
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees )

34. Review: Participation Constraints
Does every department have a manager?
If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial).
If Manages becomes a table (1st approach) every did value in Departments table must appear in a row of the Manages table (with a non-null ssn value!)

35. Participation Constraints in SQL
We can capture participation constraints involving one entity set in a binary relationship, but little else (without resorting to CHECK constraints).
CREATE TABLE Dept_Mgr(
did INTEGER,
dname CHAR(20),
budget REAL,
mgr_ssn CHAR(11) NOT NULL,
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (mgr_ssn) REFERENCES Employees (ssn),
ON DELETE NO ACTION)

36. Weak Entities
A weak entity can be identified uniquely only by considering the primary key of another (owner) entity.
Owner entity set, weak entity set must participate in a one-to-many relationship set (1 owner, many weak entities).
Weak entity set must have total participation in this identifying relationship set.
name
cost
ssn
pname
lot
age
Employees
Policy
Dependents

37. ER Diagram to Relations
Weak Entity sets
E1 = ( a1, …, an ) IR E1 E2
E2 = (a1, b1, …, bm )
a1 …. an
b1 …. bm
Sub-classes a1 … an
Method 1 (ER):
E = ( a1, …, an ) E1
S1 = (a1, b1, …, bm )
Isa
S2 = ( a1, c1 …, ck )
Method 2 (OO): S1 S2
S1 = (a1,…, an, b1, …, bm )
c1 …. ck
S2 = ( a1, …, an, c1 …, ck )
b1 …. bm

38. Translating Weak Entity Sets
Weak entity set and identifying relationship set are translated into a single table
When the owner entity is deleted, all owned weak entities must also be deleted
lot
name
age
pname
Dependents
Employees
ssn
Policy
cost )
CREATE TABLE Dep_Policy (
pname CHAR(20),
age INTEGER,
cost REAL,
ssn CHAR(11) NOT NULL,
PRIMARY KEY (pname, ssn),
FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE CASCADE)

39. Another Example loginname hostname IP Logins At Hosts time
Hosts(hostname, IP)
Logins(loginname, hostname, time)
At(loginName, hostName)
At becomes part of Logins

40. Ternary Relationships (cont.)
Many-Many-Many relationship
Same as many-many: create table Contract with foreign keys to other 3 tables
qty
Parts
Contract
Departments
Suppliers

41. Translating ISA Hierarchies to Relations
name
ssn
lot
Employees
hourly_wages
hours_worked
ISA
contractid
Hourly_Emps
Contract_Emps
Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? (Allowed/disallowed)
Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (Yes/no)

42. Translating ISA Hierarchies to Relations
General approach (ER approach)
3 relations: Employees, Hourly_Emps and Contract_Emps
Hourly_Emps: Every employee is recorded in Employees. For hourly emps, extra info recorded in Hourly_Emps (hourly_wages, hours_worked, ssn)
must delete Hourly_Emps tuple if referenced Employees tuple is deleted
Queries involving all employees easy, those involving just Hourly_Emps require a join to get some attributes
Alternative: Just Hourly_Emps and Contract_Emps (OO approach)
Hourly_Emps: ssn, name, lot, hourly_wages, hours_worked
Each employee must be in one of these two subclasses

43. Summary: ER Diagram to Relations? R1 ? E2 E1
a1 …. an
c1 …. ck
b1 …. bm
E1 = ( a1, …, an )
E2 = ( b1, …, bm ) R1
R1 = ( a1, b1, c1 …, ck )
E1 = ( a1, …, an ) R1
E2 = ( b1, …, bm , a1, c1, …, ck)
E1 = ( a1, …, an , b1, c1, …, ck) R1
E2 = ( b1, …, bm ) R1
Treat as n:1 or 1:m

44. Summary: ER Diagram to Relations
Weak Entity sets
E1 = ( a1, …, an ) IR E1 E2
E2 = (a1, b1, …, bm )
a1 …. an
b1 …. bm
Sub-classes a1 … an
Method 1 (ER):
E = ( a1, …, an ) E1
S1 = (a1, b1, …, bm )
Isa
S2 = ( a1, c1 …, ck )
Method 2 (OO): S1 S2
S1 = (a1,…, an, b1, …, bm )
c1 …. ck
S2 = ( a1, …, an, c1 …, ck )
b1 …. bm