1. BBM 471 – Database Management Systems
Fall 2013
Dr. Nazlı İkizler Cinbiş

2. Relational Model (İlişkisel Veri Modeli)
Chapter 3 in the textbook

3. DB Modeling & Implementation
Ideas
Database
Model
(E/R, ODL)
Relational
Schema
Physical
storage
Complex
file organization
and index
structures.
Diagrams (E/R)
Tables:
column names: attributes
rows: tuples

4. Example of a Relation Relation = Table attributes (or columns) tuples
(or rows) 4

5. Relational terminology
Relation is composed of tuples (çoklular)
Tuple = sequence of attribute values
Attribute has atomic types
Relation schema: (İlişki Şeması)
relation name + attribute names + attribute types
STUDENT
Database schema: set of relation schemas
INSTRUCTOR
COURSE

6. Concepts Review Relational Model is made up of tables
A row of table = a relational instance/tuple
A column of table = an attribute
A table = a schema/relation
Cardinality = number of rows
Degree = number of columns

7. Example of a Relation attributes (or columns) tuples (or rows)
Cardinality = 12
Degree = 4 7

8. Attribute Types
The set of allowed values for each attribute is called the domain(alan) of the attribute
Attribute values are (normally) required to be atomic; that is, indivisible
The special value null is a member of every domain
The null value causes complications in the definition of many operations 8

9. Relation Schema and Instance
A1, A2, …, An are attributes
R = (A1, A2, …, An ) is a relation schema
Example:
instructor = (ID, name, dept_name, salary)
Formally, given sets D1, D2, …. Dn a relation r is a subset of D1 x D2 x … x Dn Thus, a relation is a set of n-tuples (a1, a2, …, an) where each ai  Di
The current values (relation instance) of a relation are specified by a table
An element t of r is a tuple, represented by a row in a table 9

10. Relations are Unordered
Order of tuples is irrelevant (tuples may be stored in an arbitrary order)
Example: instructor relation with unordered tuples 10

11. Properties of Relations
Relations are sets, so the following must hold:
The order of tuples is not important
All the rows must be different (No duplicates)
The relation should have at least one key
The order of attributes is not important
All the values in the attributes belong to a domain, hence have same type.
Relationship values are simple, sets or structs, composite values are not allowed. 11

12. Keys
Let K  R
K is a superkey of R if values for K are sufficient to identify a unique tuple of each possible relation r(R)
Example: {ID} and {ID,name} are both superkeys of instructor.
Superkey K is a candidate key if K is minimal Example: {ID} is a candidate key for Instructor
One of the candidate keys is selected to be the primary key. 12

13. Reduction of an E-R Schema to Tables
Primary keys allow entity sets and relationship sets to be expressed uniformly as tables.
A database which conforms to an E-R diagram can be represented by a collection of tables.
For each entity set and relationship set there is a unique table which is assigned the name of the corresponding entity set or relationship set.
Each table has a number of columns which have unique names.

14. How to convert a E/R diagram to a set of relations?
price
name
category
Start Year
name
makes
Company
Product
Stock price

15. How to translate an ER diagram to a relational schema
Basic cases
Entity set E => relation with attributes of E
Relationship R => relation with attributes being keys of related entity sets + attributes of R

16. Entity Sets Entity set Students Name Address SSN Rel: Students ssn
John
Howard
Name
South Carolina
Park Avenue
Address
SSN
Rel: Students

17. How to convert a relationship to a relation
price
name
category
Start Year
name
makes
Company
Product
Stock price
Makes (watch out for attribute name conflicts)
Product_ Name
Product_ Category
Company_ Name
Start_Year
Gizmo
Gadgets
GizmoWorks
1963

18. Multiway relationships & roles
Students
Courses
TAs
tutors
graders
enrolls
TA_SSN
Name
SSN
CourseID
Different roles treated as different entity sets
Key: keys of the many entities

19. Multiway relationships & roles
Students
TAs
Courses
SSN
Name
George
Dick
TA_SSN
Name
Wesley
Howard
John
CourseID
Name C
Databases C
Software
Enrolls(S_SSN, Course_ID, Tutor_SSN, Grader_SSN)
S_SSN
CourseID
Tutor_SSN
Grader_SSN C

20. Relationship -> Relation
name
name
addr
type
People
Likes
Likes(person, sport)
Sports
Married
husband
wife
Married(husband, wife)
Buddies 1 2
Buddies(name1, name2)
Favorite
Favorite(person, sport)

21. Combining Relations OK to combine into one relation:
The relation for an entity-set E
The relations for many-one relationships of which E is the “many.”
Example: People(name, addr) and Favorite(person, sport) combine to make Fan(name, addr, favSport).

22. Risk with Many-Many Relationships
Combining People with Likes would be a mistake. It leads to redundancy, as:
name addr sport
Sally 123 Maple Basketball
Sally 123 Maple Tennis
Redundancy

23. How to convert a weak entity set to a relation
affiliation
Team
University
schedule
sport
name
address
Team
Sport
Schedule
University_Name
Basketball
<long string>
Hacettepe University
Do include all the attributes in the key for Team.
Don’t include a separate relation for Affiliation. (why?) 23

24. Converting weak ESs – differences
StudioName
address
Crew_ID
Crew
Unit-of
Studio C2
Miramax C1
Disney
Crew_ID
StudioName
Crew
Atts of Crew Rel are:
attributes of Crew
key attributes of supporting ESs
Supporting relships are omitted

25. Weak entity sets - relationships
StudioName
address
Crew_ID
Unit-of
Crew
Studio
Subscribes
1260 7th Av.NY
BlueCross
1250 6th Av.NY
Aetna
Address
IName
Insurance
IName
Address
Insurance

26. Weak entity sets - relationships
Non-supporting relationships for weak ESs are converted
keys include entire weak ES key
StudioName
address
Crew_ID
Unit-of
Crew
Studio
Subscribes
IName
C21
C22
Crew_ID
Aetna
BlueCross
Insurer
Universal
Disney
StudioName
Subscribes
Insurance
Address

27. Handling Weak Entity Sets
Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own, nonkey attributes.
A supporting relationship is redundant and yields no relation (unless it has attributes).

28. Example: Weak Entity Set -> Relation
name
name
Logins At
Hosts
location
billTo
Hosts(hostName, location)
Logins(loginName, hostName, billTo)
At(loginName, hostName, hostName2)
At becomes part of
Logins
Must be the same

29. Exercise 1 Convert the E/R diagram to a relational database schema.
row
seat
Booking
Customers
Flights
phone
aircraft
number
SSN
address
day
name

30. How to translate a subclass
Product
topic
platforms
ageGroup
memory
isa
isa
Educational
Product
Software
Product
isa
isa
Educational-method
Educ-software
Product

31. Three ways to translate subclasses
Object-oriented : each entity belongs to exactly one class; create a relation for each class, with all its attributes.
E/R style : create one relation for each subclass, with only the key attribute(s) and attributes attached to that entity set;
Use null : create one relation; entities have nulls in attributes that don’t belong to them.

32. Option #1: the OO Approach
4 tables: each object can only belong to a single table
Product(name, price, category, manufacturer)
EducationalProduct( name, price, category, manufacturer,
ageGroup, topic)
SoftwareProduct( name, price, category, manufacturer,
platforms, requiredMemory)
EducationalSoftwareProduct( name, price, category, manufacturer,
ageGroup, topic, platforms,
requiredMemory)
DRAWBACK: Redundancy

33. Option #2: the E/R Approach
Product(name, price, category, manufacturer)
EducationalProduct( name, ageGroup, topic)
SoftwareProduct( name, platforms, requiredMemory)
No need for a relation EducationalSoftwareProduct unless
it has a specialized attribute:
EducationalSoftwareProduct(name, educational-method)
DRAWBACK: Have to reach multiple tables

34. Option #3: The Null Value Approach
Have one table:
Product ( name, price, manufacturer, age-group, topic,
platforms required-memory, educational-method)
Some values in the table will be NULL, meaning that the attribute
not make sense for the specific product.
Saves space unless there are lots of attributes that are usually NULL
DRAWBACK: Redundancy and too many meanings for NULL

35. Representing Aggregation
Name
SSN
Name
Advisor
Student
Professor
Dept
SID
Name
member
Primary Key of Advisor
Dept
SID
Code
1234 04
5678 08
Code
Primary key of Dept

36. Constraints (Kısıtlamalar)

40. Veri Tutarlılığı

42. Referential integrity
When one table has a foreign key to another table, the concept of referential integrity states that you may not add a record to the table that contains the foreign key unless there is a corresponding record in the linked table.

43. Referential Integrity Constraints
Idea: prevent “dangling tuples” (e.g.: a loan with a bname, Kenmore, when no Kenmore tuple in branch)
Referencing
Relation
(e.g. loan)
Referenced
Relation
(e.g. branch)
“foreign key”
bname
primary key
bname
Ref Integrity:
ensure that:
foreign key value  primary key value
(note: need not to ensure , i.e., not all branches have to have loans)

46. Other kinds of constraints
Domain constraints
E.g. date: must be after 1980
Enumerated type: grades A through F, no E
No special E/R notation just write near line
General constraints:
A class may have no more than 100 students; a student may not have more than 6 courses:
Enroll
Students
<=100
<=6
Courses

47. Relational Queries

48. Relational Queries
Query languages: Allow manipulation and retrieval of data from a database.
Relational model supports simple, powerful QLs:
Strong formal foundation based on logic.
Allows for much optimization.
Query Languages != programming languages!
QLs not intended to be used for complex calculations.
QLs support easy, efficient access to large data sets.

49. Formal Relational Query Languages
Two mathematical Query Languages form the basis for “real” languages (e.g. SQL), and for implementation:
Relational Algebra: More operational, very useful for representing execution plans.
Relational Calculus: Lets users describe what they want, rather than how to compute it. (Nonoperational,declarative.)

50. What is Relational Algebra?
An algebra whose operands are relations or variables that represent relations.
Operators are designed to do the most common things that we need to do with relations in a database.
The result is an algebra that can be used as a query language for relations.

51. Core Relational Algebra
Union, intersection, and difference.
Usual set operations, but both operands must have the same relation schema.
Selection: picking certain rows.
Projection: picking certain columns.
Products and joins: compositions of relations.
Renaming of relations and attributes.

52. Selection
R1 := σC (R2)
C is a condition (as in “if” statements) that refers to attributes of R2.
R1 is all those tuples of R2 that satisfy C.

53. Example: Selection Relation Sells: cafe drink price Joe’s Coffee 2.50
Joe’s Tea 2.75
Sue’s Coffee 2.50
Sue’s Tea 3.00
JoeMenu := σcafe=“Joe’s”(Sells):
cafe drink price
Joe’s Coffee 2.50
Joe’s Tea 2.75

54. Selection keeps only the tuples that satisfy a particular condition
Diagnosis
Patient
Disease
Temperature
Winslett
Strep
98.9
Zhai
Meningitis
101.1
Han
Ebola
96.6
Hantavirus
98.6
Chang
Cholera
102.3
Find all patients who have a fever
sTemperature > 98.6 (Diagnosis)
You can also write this as
[Temperature > 98.6] (Diagnosis)

55. Selection conditions can be relatively complex
Attribute names
Patient
Disease
Salary
Constants
“Winslett”
“Meningitis”
40,000
= < > ≤ ≠
Patient = “Winslett”
Salary < 40,000
and or not
Patient = “Winslett” and Temperature > 98.6

57. Projection
R1 := πL (R2)
L is a list of attributes from the schema of R2.
R1 is constructed by looking at each tuple of R2, extracting the attributes on list L, in the order specified, and creating from those components a tuple for R1.
Eliminate duplicate tuples, if any.
Result is a set of tuples, so no duplicates is allowed in a set representation.

58. Example: Projection Relation Sells: cafe drink price Joe’s Coffee 2.50
Joe’s Tea 2.75
Sue’s Coffee 2.50
Sue’s Tea 3.00
Prices := πdrink,price(Sells):
drink price
Coffee 2.50
Tea 2.75
Tea 3.00

62. Extended Projection
Using the same πL operator, we allow the list L to contain arbitrary expressions involving attributes:
Arithmetic on attributes, e.g., A+B->C.
Duplicate occurrences of the same attribute.

63. Example: Extended Projection
R = ( A B )
1 2
3 4
πA+B->C,A,A (R) = C A1 A2
3 1 1
7 3 3