1. Definition and Properties Constraints and Schemas Update
Relational Model
Definition and Properties
Constraints and Schemas Update
ER | EER  Relational
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

2. Relational Model: Definition and Properties
Relational Model represents database as a collection of relations.
A relation may be considered as a table of values, where each row represents a collection of related values, forming an instance, a fact, corresponding with an entity in an entity-set.
Table-name and columns-names are used to interpret the meaning of values in each row and define relational schema.
Each value in a column is drawn by from the same value-set (data-type).
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

3. Relational Model: Definition and Properties
In original definition of Relational Model:
Tables are called relations;
Rows – tuples;
Column-names – attributes;
Data-type – domain.
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

4. Relational Model: Definition and Properties
Domain is a set of allowable values for one or more attributes
Degree is a number of attributes in a relation.
Cardinality is a number of tuples in a relation.
Alternative terminology
Formal terms Alternative 1 Alternative 2
Relation Table File
Tuple Row Record
Attribute Column Field
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

5. Properties of Relations
Relation name is distinct from all other relations.
Each cell of relation contains exactly one atomic (single) value.
Each attribute has a distinct name within relation.
Values of an attribute (column) are all from the same domain.
Order of attributes has no significance.
Each tuple is distinct; there are no duplicate tuples.
Order of tuples has no significance, theoretically. To ensure efficiency, tuples in a table are ordered according to primary key.
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

6. Relational Constraints (1)
Key constraints (uniqueness constraint):
Superkey (Key) –
Formally - a set of attributes of a relation R is called Superkey (SK), if no any two distinct tuples t1 and t2 in a state r of R have the same value for attributes belonging to SK:
t1[SK] <> t2[SK]
Informally - an attribute or a set of attributes that uniquely identifies a tuple within a relation.
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

7. Relational Constraints (2)
Key (candidate key) is a minimal Superkey — a Superkey from which we cannot remove an attribute and still, the remaining set of attributes, is Superkey (the uniqueness constraint holds).
Primary Key - candidate key selected to identify tuples uniquely within relation.
Alternate Keys - candidate keys that are not selected to be the primary key.
Foreign Key - An attribute or set of attributes within one relation that matches candidate key of some (possibly the same) relation.
Selection of PK affects performance!
Defining foreign keys ensures database integrity!
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

8. Relational integrity (1)
Null
Represents a value for an attribute that is currently unknown or is not applicable for this tuple.
Deals with incomplete or exceptional data.
Null represents the absence of a value and is not the same as zero or spaces, which are values.
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

9. Relational integrity (2)
2 principal rules for the relational model:
Entity Integrity
In a base relation, no attribute of a primary key can be null.
Referential Integrity
If foreign key exists in a relation, either the foreign key value must match a candidate key value of some tuple in its home relation or foreign key value must be wholly null.
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

10. Relational integrity (3)
Enterprise Constraints
Additional rules specified by users or database administrators.
Eg., the maximum number of staff in a branch.
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

11. Company Database: Relational Schema
EMPLOYEE
Fname
Minit
Lname
SSN
Bdate
Address
Sex
Salary
SupSSN
DNO
WORKS_ON
ESSN
PNO
Hours
DEPARTMENT
Dname
Dnumber
MGRSSN
MGRSDate
PROJECT
Pname
Pnumber
Plocation
DNum
LOCATION
D_num
D_location
DEPENDENT
ESSN
D_name
Sex
Bdate
Relationship
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

12. Company Database: Relational State
EMPLOYEE
Fname
Minit
Lname
SSN
Bdate
Address
Sex
Salary
SupSSN
DNO
John B
Smith
…TX… M
30000 5
Franklin T
Wong
40000
Alicia J
Zelaya F
25000 4
Jennifer S
Wallace
43000
Ramesh K
Narayan
38000
Joyce A
English
Ahmad V
Jabbar
James E
Borg
55000
Null 1
DEPARTMENT
Dname
Dnumber
MGRSSN
MGRSDate
Research 5
Administration 4
Headquarter 1
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

13. Transition Constraints: Insert
The Insert Operation can violate any of the four types of constraints discussed:
Domain constraints can be violated if an attribute is given value that does not appear in the corresponding domain.
Key constraints can be violated if a key value in the new tuple t already exists in another tuple in the relation r(R).
Entity integrity can be violated if the primary key of the new tuple t is null.
Referential integrity can be violated if the value of any foreign key in t refers to a tuple that does not exist in the referenced relation.
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

14. Transition Constraints: Insert – Examples (1)
<‘Cecilia’, ‘F’, ‘Kolonsky’, null, ‘ ’, ‘6357 Windy Lane, Katy, TX’, F, 28000, null, 4>
This insertion violates the entity integrity constraint (null for the primary key SSN)  Rejected!
<‘Alicia’, ‘J’, ‘Zelaya’, ‘ ’, ‘ ’, ‘6357 Windy Lane, Katy, TX’, F, 28000, ‘ ’, 4>
This insertion violates the key constraint because another tuple with the same SSN value already exists in the EMPLOYEE relation  Rejected!
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

15. Transition Constraints: Insert – Examples (2)
<‘Cecilia’, ‘F’, ‘Kolonsky’, ‘ ’, ‘ ’, ‘6357 Windy Lane, Katy, TX’, F, 28000, ‘ ’, 7>
This insertion violates the referential integrity constraint specified on DNO because no DEPARTMENT tuple exists with DNUMBER = 7  Rejected or cascade request for insertion a new tuple into Department!
<‘Cecilia’, ‘F’, ‘Kolonsky’, ‘ ’, ‘ ’, ‘6357 Windy Lane, Katy, TX’, F, 28000, null, 4>
This insertion satisfies all constraints Accepted!
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

16. Transition Constraints: Delete
The Delete Operation can violate only referential integrity: If the tuple being deleted is referenced via a foreign key from other tuples in the database.
To specify which tuples to delete, a conditions defined on relation’s attributes have to be specified
Example:
Delete the tuple from WORKS_ON where ESSN = ‘ ’ and PNO = 10
 Accepted!
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

17. Transition Constraints: Delete - Examples
Delete the EMPLOYEE tuple where SSN = ‘ ’  Rejected! This deletion is not acceptable, because FK in WORKS_ON refers to this tuple. Executing deletion will result in violation of referential integrity. Delete the EMPLOYEE tuple where SSN = ‘ ’ This deletion will result in referential integrity violations. The tuple involved is referenced by FK from the EMPLOYEE, DEPARTMENT, WORKS_ON, and DEPENDENT relations.
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

18. Transition Constraints: Update
The Update Operation
The Update operation is used to change the values of one or more attributes in a tuple (or tuples) of some relation R. It is necessary to specify a condition on the attributes of the relation to select the tuple (or tuples) to be modified.
Examples
Update the SALARY of the EMPLOYEE tuple where SSN = ‘ ’ to 28000
Acceptable! (Why?)
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

19. Transition Constraints: Update - Examples
Update the DNO of the EMPLOYEE tuple with SSN = ‘ ’ to 1 Acceptable! (Why?) Update the DNO of the EMPLOYEE tuple with SSN = ‘ ’ to 7 Unacceptable, because it violates referential integrity. Update the SSN of the EMPLOYEE tuple with SSN = ‘ ’ to ‘ ’ Unacceptable, because it violates primary key and referential integrity constraints.
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

20. Q & A Attention ! Next class Quiz 1 Basic concepts, ER and EER
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

21. ER-to-Relational Mapping Algorithms
Step 1: Mapping of Regular Entity Types
Step 2: Mapping of Weak Entity Types
Step 3: Mapping of Binary 1:1 Relationship Types
Step 4: Mapping of Binary 1:N Relationship Types
Step 5: Mapping of Binary M:N Relationship Types
Step 6: Mapping of Multivalued Attributes
Step 7: Mapping of N-ary Relationship Types
Step 8: Options for Mapping Specialization or Generalization
Step 9: Mapping of Union Types (Categories)
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

22. Step 1: Mapping of Regular Entity Types
For each regular (strong) entity type E in the ER schema, create a relation R that includes all the simple attributes of E. Include only the atomic component attributes of a composite attribute. Choose one of the key attributes of E as primary key for R. If the chosen key of E is composite, the set of simple attributes that form it will together form the primary key of R.
Sal Fn
Nam
Min Ln
Addr
Sex BD
SSN
EMPLOYEE
EMPLOYEE
Fname
Minit
Lname
SSN
Bdate
Address
Sex
Salary
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

23. Step 2: Mapping of Weak Entity Types
For each weak entity type W in the ER schema with owner entity type E, create a relation R, and include all simple attributes of W as attributes of R. In addition, include as foreign key attributes of R the primary key attribute(s) of the relation(s) E. The primary key of R is the combination of the primary key(s) of the owner(s) and the partial key of the weak entity type W, if any.
Sal Fn
Nam
Min Ln
Addr
Sex BD
SSN
EMPLOYEE
Name
Sex
BDate
Relation
DEPENDENT
DEPENDENT
ESSN
D_name
Sex
Bdate
Relationship
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

24. Step 3: Mapping of Binary 1:1 Relationship Types
For each binary 1:1 relationship type R in the ER schema, identify the relations S and T that correspond to the entity types participating in R. Choose one of the relations—S, and include as foreign key in S the primary key of T. It is better to choose an entity type with total participation in R in the role of S. Include all the simple attributes (or simple components of composite attributes) of the 1:1 relationship type R as attributes of S.
Sal Fn
Nam
Min Ln
Addr
Sex BD
SSN
EMPLOYEE
Number
Location
Name
DEPARTMENT
NumEmp
Manage 1
Start_Date T S
DEPARTMENT
Dname
Dnumber
MGRSSN
MGRSDate
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

25. Step 4: Mapping of Binary 1:N Relationship Types
For each regular binary 1:N relationship type R, identify the relation S that represents the participating entity type at the N-side of the relationship type. Include as foreign key in S the primary key of the relation T that represents the other entity type participating in R; this is because each entity instance on the N-side is related to at most one entity instance on the 1-side of the relationship type. Include any attributes of the relationship type as attributes of S.
Sal Fn
Nam
Min Ln
Addr
Sex BD
SSN
EMPLOYEE
Number
Location
Name
DEPARTMENT
NumEmp
Works_for N 1 S T
EMPLOYEE
Fname
Minit
Lname
SSN
Bdate
Address
Sex
Salary
DNO
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

26. Step 5: Mapping of Binary M:N Relationship Types
For each binary M:N relationship type R, create a new relation S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types; their combination will form the primary key of S. Also include any simple attributes of the M:N relationship type as attributes of S.
Works_on N M
hours
Name
Location
Number
PROJECT
Sal Fn
Nam
Min Ln
Addr
Sex BD
SSN
EMPLOYEE
WORKS_ON
Pname
Pnumber
Plocation
DNum
ESSN
PNO
Hours
EMPLOYEE
Fname
Minit
Lname
SSN
Bdate
Address
Sex
Salary
DNO
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

27. Step 6: Mapping of Multivalued Attributes
For each multivalued attribute A of entity E, create a new relation R. This relation R will include an attribute(s) corresponding to A, plus the primary key K of E as a foreign key in R referencing the relation created for E. The primary key of R is the combination of A and K. If the multivalued attribute is composite, we include its atomic components.
Number
Location
Name
DEPARTMENT
NumEmp
LOCATION
D_num
D_location
DEPARTMENT
Dname
Dnumber
MGRSSN
MGRSDate
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

28. Step 7: Mapping of N-ary Relationship Types
For each n-ary relationship type R, where n > 2, create a new relation S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types. Also include any simple attributes of the n-ary relationship type as attributes of S. The primary key of S is usually a combination of all the foreign keys that reference the relations representing the participating entity types.
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model

29. Correspondence between ER and Relational Models
ER MODEL
RELATIONAL MODEL
Entity type
Entity relation
1:1 or 1:N relationship type
Foreign key (or relationship relation)
M:N relationship type
Relationship relation and two foreign keys
n-ary relationship type
Relationship relation and n foreign keys
Simple attribute
Attribute
Composite attribute
Set of simple component attributes
Multivalued attribute
Relation and foreign key
Value set
Domain
Key attribute
Primary (or secondary) key
D. Christozov / G.Tuparov
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model
INF 280 Database Systems: SQL - Single Table queries 29 29

30. Step 8: Mapping Specialization or Generalization
Convert each specialization with m subclasses {S1, S2, . . ., Sm} and (generalized) superclass C, where the attributes of C are {k, a1, . . ., an} and k is the (primary) key, into relation schemas using one of the four following options:
D. Christozov / G.Tuparov
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model
INF 280 Database Systems: SQL - Single Table queries 30 30

31. Step 8: Option A Multiple relations—superclass and subclasses
Create a relation L for C
Create a relation Li for each subclass Si, with the attributes
D. Christozov / G.Tuparov
D. Christozov / G.Tuparov
INF 280 Database Systems: SQL - Single Table queries
INF 280 Database Systems: Relational Model 31 31

32. Step 8: Option 8B Multiple relations—subclass relations only
Create a relation Li for each subclass Si, with the attributes
D. Christozov / G.Tuparov
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model
INF 280 Database Systems: SQL - Single Table queries 32 32

33. Step 8: Option 8C Single relation with one type attribute
This option is for a specialization whose subclasses are disjoint, and t is defining attribute, that indicates the subclass to which each tuple belongs.
This option has the potential for generating a large number of null values.
Create a single relation L, such that
D. Christozov / G.Tuparov
D. Christozov / G.Tuparov
INF 280 Database Systems: SQL - Single Table queries
INF 280 Database Systems: Relational Model 33 33

34. Step 8: Option 8D Single relation with multiple type attributes
Create a single relation schema L such that
This option is for a specialization whose subclasses are overlapping (but may also work for a disjoint) specialization, and each ti, 1  i  m, is a Boolean attribute indicating whether a tuple belongs to subclass Si.
D. Christozov / G.Tuparov
D. Christozov / G.Tuparov
INF 280 Database Systems: SQL - Single Table queries
INF 280 Database Systems: Relational Model 34 34

35. Step 9: Mapping of Union Types (Categories)
Mapping Shared Subclasses (Multiple Inheritance):
Any of options 8A – 8D may apply.
STEP 9: For mapping of UNION Types (Categories), a new surrogate key attribute is specified, because the primary keys of the super-classes are different and may not use any of them to identify all entities in the category. The surrogate key is introduce in any of the super-classes relations as a foreign key to specify the correspondence.
PERSON u
owner
bank
company
person
OWNER
SSN …
OwnerID
OwnerID
BANK
COMPANY
BName …
OwnerID
CName …
OwnerID
D. Christozov / G.Tuparov
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model
INF 280 Database Systems: SQL - Single Table queries 35 35

36. Example from Lecture 2: Map ER  R
Quack Consulting is a computer consulting firm. It keeps the list of its clients (id, name, phone). Each of them may have many different projects (id, description, start_date, due_to, team_leader). A project may consists of several tasks (project_id, task_id, consultant, description, start, due_to). Only one consultant is ever assigned to a given task. The time a consultant works for a project is recorded in time table. In order to choose the appropriate consultant for a client information about consultants and his/her specialty (including the billing_rate) is maintain as well as some comments about his/her qualities important for Quack Consulting.
D. Christozov / G.Tuparov
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model
INF 280 Database Systems: SQL - Single Table queries 36 36

37. Example from Lecture 2: Map ER  R
Fancy Fruits is a specialty grocery store supplying a variety of boxed fruits to its customers. The entities are customers, orders, stock, and vendors. The stock keeps track to current inventory (quantities on-hand of the items and current price). The vendors lists the wholesalers who supply Fancy Fruits with items, it includes the cost of item for Fancy Fruit and geographical region, where the wholesaler is located (Hint: Consider that one vendor could supply a number of items and one item could be supplied by a number of vendors - different regions and costs). The customer also store information about the region of the customer as well as customer_name and phone. Orders defined the quantities of given item ordered by a customer
D. Christozov / G.Tuparov
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model
INF 280 Database Systems: SQL - Single Table queries 37 37

38. Example from Lecture 2: Map ER  R
Retailers M Id
Name
Price
On_hand
Products
Codes
D_code
D_Price
Purchase
Date
Quantity
C_Id
address
Customers
Dealers d N
orders
D. Christozov / G.Tuparov
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model
INF 280 Database Systems: SQL - Single Table queries 38 38

39. Example from Lecture 2: Map ER  R
Recipes
R_Id
Description
Activities
Ingredients
I_Id
Name
On_hand
Goods
Price
Cook N 1 M
Suppliers
Supplies
Quantity
Address
D. Christozov / G.Tuparov
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model
INF 280 Database Systems: SQL - Single Table queries 39 39

40. Example from Lecture 2: Map ER  R
BANK BRANCH
BANK OFFICE
LOAN
CUSTOMER
ACCOUNT
DEBIT CARD
A - C
GRANTS
L - C
OPENS
BRANCHES
Code
Name
Address
ISSUES
Loan No
Type
Amount
Rate
Period
Clinum
SSN
Telephone
Employer
Home
Mobile
Business
Acct No
Comfort Ins
Start Date N 1 M
Entity-Relationship
Database Diagram
D. Christozov / G.Tuparov
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model
INF 280 Database Systems: SQL - Single Table queries 40 40

41. INF 280 Database Systems: Relational Model
Q & A
Attention ! Next class
Quiz 2: ER  R
D. Christozov / G.Tuparov
INF 280 Database Systems: Relational Model