Database System Concepts, 6th Ed.
©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
Chapter 2: Intro to Relational Model
©Silberschatz, Korth and Sudarshan2.2Database System Concepts - 6th Edition
Example of a Relation
attributes
(or columns)
tuples
(or rows)
Table instructor
©Silberschatz, Korth and Sudarshan2.3Database System Concepts - 6th Edition
Attribute Types
 The set of allowed values for each attribute is called the domain
of the attribute (denoted as D)
 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
©Silberschatz, Korth and Sudarshan2.4Database System Concepts - 6th Edition
Relation Schema and Instance
 A1, A2, …, An are attributes
 with the corresponding domains D1, D2, …. Dn
 R = (A1, A2, …, An ) is a relation schema
Example: INSTRUCTOR = (ID, name, dept_name, salary)
 Formally, given sets D1, D2, …. Dn corresponding to attributes in
schema R a relation r is a subset of
r  D1  D2  …  Dn
Thus, a relation is a set of n-tuples (a1, a2, …, an) where each ai  Di
 An element t of r is a tuple, represented by a row in a table
 Notation: instructor(INSTRUCTOR) or
instructor(ID, name, dept_name, salary)
 The current values (relation instance) of a relation are specified by a
table
©Silberschatz, Korth and Sudarshan2.5Database System Concepts - 6th Edition
Relations are Unordered
 Order of tuples is irrelevant (tuples may be stored in an arbitrary order)
 Example: instructor relation with unordered tuples
©Silberschatz, Korth and Sudarshan2.6Database System Concepts - 6th Edition
Database
 A database consists of multiple relations
 Information about an enterprise is broken up into parts
instructor - ID, name , salary, department
student - ID, name, program, credits, advisor
advisor - ID, name, topic
 Bad design:
university (instructor_ID, name, dept_name, salary, student_ID, …)
results in
 repetition of information (e.g., two students have the same instructor)
 the need for null values (e.g., represent an student with no advisor)
 Normalization theory (Chapter 7) deals with how to design “good”
relational schemas
©Silberschatz, Korth and Sudarshan2.7Database System Concepts - 6th Edition
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: instructor(ID, name, dept_name, salary)
 Some superkeys: {ID} {ID, name} {name, dept_name}
 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.
 Which one?
 Foreign key constraint: Value in one relation must appear in another
 Referencing relation
 Referenced relation
©Silberschatz, Korth and Sudarshan2.8Database System Concepts - 6th Edition
Schema Diagram for University Database
Foreign keys are emphasized by arrows.
©Silberschatz, Korth and Sudarshan2.9Database System Concepts - 6th Edition
Relational Query Languages
 Language in which user requests information from the database.
 Procedural vs. non-procedural (or declarative)
 “Pure” languages:
 Relational algebra – procedural language
 Tuple relational calculus – declarative language
 Domain relational calculus – declarative language
 Pure languages form underlying basis of query languages that people
use.
 E.g. SQL
©Silberschatz, Korth and Sudarshan2.10Database System Concepts - 6th Edition
Relational Query Languages
 Why relational algebra?
 It is simple
 Few operators only …
 An expression specifies the procedure to evaluate it
 We know what to do first, second, …
 SQL
 can be complicated (many keywords, …)
 does not give the recipe
Database System Concepts, 6th Ed.
©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
End of Chapter 2