The Relational Data Model
Chapter 4
Data and Its Structure
• Data is actually stored as bits, but it is
difficult to work with data at this
level.
• It is convenient to view data at
different levels of abstraction.
• Schema: Description of data at some level.
Each level has its own schema.
• We will be concerned with three schemas:
physical, conceptual, and external.
2
Physical Data Level
• Physical schema describes details of how data
is stored: tracks, cylinders, indices etc.
• Early applications worked at this level -
explicitly dealt with details.
• Problem:_Routines hardcoded to deal with
physical representation.
- Changes to data structure difficult to make.
- Application code becomes complex since it must deal
with details.
- Rapid implementation of new features impossible.
3
Conceptual Data Level
• Hides details.
- In the relational model, the conceptual schema
presents data as a set of tables.
• DBMS maps from conceptual to physical
schema automatically.
• Physical schema can be changed
without changing application:
- DBMS must change mapping from conceptual
to physical.
• Referred to as physical data independence.
4
Conceptual Data Level (can't)
Application
l Conceptual
view of data
DBMS Physical
view of data
5
External Data Level
• In the relational model, the external schema also
presents data as a set of relations.
• An external schema specifies a view of the
data in terms of the conceptual level. It is
tailored to the needs of a particular category of
users.
- Portions of stored data should not be seen by some
users.
• Students should not see faculty salaries.
• Faculty should not see billing data.
- Information that can be derived from stored data
might be viewed as if it were stored.
• GPA not stored, calculated when needed. 6
External Data Level (con't)
• Application is written in terms of an external schema.
• A view is computed when accessed (not stored).
• Different external schemas can be provided to different
categories of users.
• Translation from external to conceptual done
automatically by DBMS at run time.
• Conceptual schema can be changed without changing
application:
- Mapping from external to conceptual must be
changed.
• Referred to as conceptual data independence.
7
Levels of Abstraction
View 1 View2 View3 External
schemas
Conceptual schema
Physical schema
8
Data Model
• Schema: description of data at some level
(e.g., tables, attributes, constraints,
domains)
• Model: tools and language for describing:
- Conceptual and external schema
• Data definition language (DDL)
- Integrity constraints, domains (DDL)
- Operations on data
• Data manipulation language (DML)
- Directives that influence the physical schema
(affects performance, not semantics)
• Storage definition language (SDL) 9
Relational Model
• A particular way of structuring data (relations)
• Simple
• Mathematically based
- Expressions (queries) can be analyzed by DBMS
- Transformed to equivalent expressions automatically
(query optimization)
• Optimizers have limits (=> programmer needs to know
how queries are evaluated and optimized)
10
Relation Instance
• Relation is a set of tuples
- Tuple ordering immaterial
- No duplicates
- Cardinality of relation = number of tuples
• All tuples in a relation have the same
structure; constructed from the same set
of attributes
- Attributes named (=> ordering immaterial)
- Value of an attribute drawn from the attribute's
domain
- Arity = number of attributes
11
Relation Instance (Example)
Id Name Address Status
1111111 John 123 main freshman
2345678 Mary 456 cedar sophmore
t433322 Art 77 so. 3rd seni or
•
7654321 Pat 88 no. 4th sophmore
Student 12
Relation Schema
• Relation name
• Attribute names and domains
• Integrity constraints - e.g.,:
- The values of a particular attribute in all tuples
are uni• que
- The values of a particular attribute in all tuples
are greater than 0
• Default values
13
Relational Database
• Finite set of relations
• Each relation consists of a schema and an
instance
• Database schema = set of relation
schemas
(and other things)
• Database instance = set of
(corresponding) 14
relation instances
Database Schema (Example)
• Student (Id: INT, Name: STRING, Address:
STRING, Status: STRING)
• Professor (Id: INT, Name: STRING, Deptld:
DEPTS)
• Course (Deptld: DEPTS, CrsName: STRING,
CrsCode: COURSES)
• Transcript (CrsCode: COURSES, Studld: INT,
Grade: GRADES, Semester: SEMESTERS)
• Department(Deptld: DEPTS, Name: STRING)
15
Integrity Constraints
• Part of schema
• Restriction on state (or sequence of states) of data
base
• Enforced by DBMS
• Intra-relational - involve only one relation
- Part of relation schema
- e.g., all Ids are unique
• Inter-relational - involve several relations
- Part of relation schema or database schema
16
Kinds of Integrity Constraints
• Static - limitation on state of database
- Syntactic (structural)
• e.g., all values in a column must be unique
- Semantic (involve meaning of attributes)
• e.g., cannot register for more than 18 credits
• Dynamic - limitation on sequence of
database states (supported by some DBMSs,
but not in current SQL standard)
• e.g., cannot raise salary by more than 5%
17
Key Constraint
• Values in a column (or columns) of a
relation are unique: at most one row in a
relation instance can contain a particular
value(s)
• Key - set of attributes satisfying
key constraint
- e.g., Id in Student,
- e.g., (Studld, CrsCode, Semester) in
Transcript
18
Key Constraint (con't)
• Minimality - no subset of a key is a key
- (Studld, CrsCode) is not a key of Transcript
• Superkey - set of attributes containing key
- (Id, Name) is a superkey of Student
• Every relation has a key
• Relation can have several keys:
- primary key (Id in Student) - (cannot be
null)
- candidate key ((Name, Address) in Student)
19
Foreign Key
• Constraint
Referential integrity => Item named in one relation
must correspond to tuple(s) in another that describes the
item
- Transcript (CrsCode) references Course(CrsCode)
- Professor(Deptld) references Department(Deptld)
• al is a foreign key of Rl referring to a2 in R2 => if v is a
value of al, there is a unique tuple of R2 in
which a2 has value v
- This is a special case of referential integrity: a2 must be a
candidate key of R2 (CrsCode is a key of Course)
- If no row exists in R2 => violation of referential integrity
- Not all rows of R2 need to be referenced.: relationship is not
symmetric (some course might
not be taught)
- Value of a foreign key might not be specified (Deptld column of 20
some professor might be null)
Foreign Key
Constraint
(Example)
a2
a v
v
l v5
3
l vl
v v6
2 v2
v v7
3
v v
4'I\' 4
Rl '' • I
I
R2
Foreign I
I
I
vkey Candidatekey
3
21
Foreign Key (con't)
• Names of al and a2 need not be the sarne.
- With tables:
Teaching(CrsCode: COURSES, Sem: SEMESTERS, Profld: INT)
Professor(Id: INT, Name: STRING, Deptld: DEPTS)
Profld attribute of Teaching references Id attribute of
Professor
• R1 and R2 need not be distinct.
- Employee(Id:INT, Mgrld:INT, ....)
• Employee(Mgrld) references Employee(Id)
- Every manager is also an employee and hence has a unique
row in Employee
22
Foreign Key (con't)
• Foreign key might consist of several columns
- (CrsCode, Semester) of Transcript references
(CrsCode, Sem) of Teaching
• Rl (al, ...an) references R2(b1, ... bn)
- There exists a 1 - 1 relationship between al, ... an
and bl, ... bn
- ai and bi have same domains (although not
necessarily the same names)
- b1,... bn is a candidate key of R2
23
Inclusion Dependency
• Referential integrity constraint that is not
a foreign key constraint
• Teaching(CrsCode, Semester) references
Transcript(CrsCode, Semester) (no
empty classes)
- Reverse relationship is a foreign key
• Target attributes are not a candidate key
• No simple enforcement mechanism in
SQL 24
Semantic Constraints
• Domain, primary key, and foreign key are
examples of structural (syntactic)
constraints
• Semantic constraints express rules of
application:
- e.g., number of registered students < maximum
enrollment
25
SQL
• Language for describing database schema
and operations on tables
• Data Definition Language (DDL):
sublanguage of SQL for describing
schema
26
Tables
• SQL entity that corresponds to a relation
• An element of the database schema
• SQL-92 is current standard but will be
replaced by SQL:1999
• Database vendors generally deviate from
standard
27
Table Declaration
CREATE TABLE Student (
Id: INTEGER,
Name: CHAR(20),
Address: CHAR(50),
Status: CHAR (10))
Id Name Address Status
101222333 John 10 Cedar St Freshman
234567890 Mary 22 Main St Sophomore
Student 28
Primary/Candidate Keys
CREATE TABLE Course (
CrsCode:CHAR(6),
CrsName: CHAR(20),
Deptld: CHAR(4),
Descr: CHAR(l00),
PRIMARY KEY
(CrsCode),
UNIQ UE (Deptld,
CrsName))
-- candidate key
29
Null
• Problem: Not all information might be
known when row is inserted (e.g., Grade
might be missing from Transcript)
• A column might not be applicable for a
particular row (e.g., MaidenName if row describes
a male)
• Solution: Use place holder - null
- Not a value of any domain (although called null value)
• Indicates the absence of a value
- Not allowed in certain situations
• Primary key, column constrained by NOT NULL 30
Default Value
- Value assigned if attribute value in a row is
not specified
CREATE TABLE Student (
Id: INTEGER,
Name: CHAR(20) NOT
NULL,
Address: CHAR(50),
Status: CHAR(l0)
DEFAULT 'freshman',
31
PRIMARY KEY (Id))
Semantic Constraints
• Used for application dependent conditions
• Each row in table must satisfy condition
• Example: limit attribute values
CREATE TABLE Transcript (
Studld: INTEGER,
CrsCode: CHAR(6),
Semester: CHAR(6),
Grade: CHAR(l),
CHECK (Grade IN ('A' 'B' 'C' 'D' '
CHECK (Studld > 0 AND
' ' '< '
Studld 32
'F'))
1000000000))
Semantic Constraints (can't)
• Example: relate values of attributes in
different columns
CREATE TABLE Employee (
Id: INTEGER,
Name: CHAR(20),
Salary: INTEGER,
MngrSalary:
INTEGER,
CHECK ( MngrSalary
> Salary))
33
Constraints -
• Problems
Problem 1: Empty table always satisfies all
CHECK constraints
CREATE TABLE Employee (
Id: INTEGER,
Name: CHAR(20),
Salary: INTEGER,
MngrSalary: INTEGER,
CHECK ( 0 < (SELECT
COUNT (*) FROM
Employee)))
- If Employee is empty, there are no rows on which to
evaluate the CHECK condition. 34
Constraints -
•
Problems
Problem 2: Interrelational constraints are asymmetric
CREATE TABLE Employee (
Id: INTEGER,
Name: CHAR(20),
Salary: INTEGER,
MngrSalary: INTEGER,
CHECK ((SELECT
COUNT (*) FROM
Manager)<
(SELECT
COUNT (*) 35
FROM
Assertion
• Element of schema (like table)
• Symmetrically specifies an inter-relational
constraint
• Applies to entire database (not just
the individual rows of a single table)
- hence it works even if Employee is
empty
CREATE ASSERTION DontFireEveryone
36
CHECK (0 < SELECT COUNT (*)
Assertion
CREATE ASSERTION KeepEmployeesDown
CHECK (NOT EXISTS(
SELECT * FROM Employee E
WHERE E.Salary > E.MngrSalary))
37
Assertions and Inclusion
Dependency
CREATE ASSERTION NoEmptyCourses
CHECK (NOT EXISTS (
SELECT FROM Teaching T
Courses * -- for each row in T check
with no WHERE -- the following condition
students NOT EXISTS (
Students in SELECT * FROM Transcript R
a particular WHERE T.CrsCode = R.CrsCode
course. AND T.Semester = R.Semester) ) )
38
Constraint Checking
• Automatically checked
- After each statement (IMMEDIATE) or
- After a transaction completes (DEFERRED)
• Protects database from errors
• Enforces enterprise rules
39
D01nains
• Possible attribute values can be specified
- Using a CHECK constraint or
- Creating a new domain
• Domain can be used in several declarations
• Domain is a schema element
CREATE DOMAIN Grades CHAR (1)
CHECK (VALUE IN ('A', 'B', 'C', ' D' , 'F'))
CREATE TABLE Transcript (
.... Grade: GRADES, 40
.....)
Foreign Key Constraint
CREATE TABLE Teaching
( Profld: INTEGER,
CrsCode: CHAR (6),
Semester: CHAR (6),
PRIMARY KEY (CrsCode,
Semester),
FOREIGN KEY (CrsCode)
REFERENCES Course,
FOREIGN KEY (Profld)
REFERENCES Professor
(Id) )
41
Foreign Key Constraint
CrsCode
CrsCode Profld X
X
y
Course
..- "
Id
Teaching
Professor 42
Circularity in Foreign
Key
al a2 a3 bl b2 b3
Constraint
A y X y B
X
candidate key : al candidate key : bl
foreign key: a3 references B(bl) foreign key : b3 references A(al)
Problem 1: Creation of A requires existence of B and vice versa
Solution 1: CREATE TABLE A( ......), (* no foreign key*)
CREATE TABLE B ( ......), (*
foreign key included*)
ALTER TABLE A
ADD CONSTRAINT
FOREIGN KEY (a3)cons
REFERENCES B (bl) 43
Circularity in Foreign Key Constraint
• Problem 2 : Insertion of row in A requires
prior existence of row in B and vice
versa
• Solution 2 : DEFERRED constraint check -
insert both rows within a single
transaction
CREATE TABLE Dept(.....
Deptid: CHAR (4),
Mngrid : INTEGER,
PRIMARY KEY Deptid,
FOREIGN KEY
(Mngrid)
REFERENCES
FOREIGN KEY (Deptid) REFERENCES Dept ( Deptid)) 44
Employee (Id))
Recognizing vs. Handling Events
• Constraints enable DBMS to recognize a bad state
and reject the statement or transaction that creates it
• More generally, it would be nice to have a
mechanism that allows a user to specify an action to
be taken if a particular situation (possibly a
transition to a bad state) occurs
• SQL-92 provides a limited form of such a
mechanism for handling foreign key violations
45
Handling Foreign Key Violations
• Insertion into A: Reject if no row exists
in B containing foreign
key of inserted row
• Deletion from B:
- NO ACTION: Reject if row(s) in A
references row to be deleted (default response)
A X -
--- -.
, X
B
- 46
Handling Foreign Key Violations
• Deletion from B (can't):
- SET NULL: Set value of foreign key
in referencing row(s) in A to null
l - - - - - + - - - - - - - - - - 1 1
A null B
47
Handling Foreign Key Violations
• Deletion from B (con't):
- SET DEFAULT: Set value of foreign key in
referencing row(s) in A to default value (y)
A B
48
Handling Foreign Key Violations
• Deletion from B (con't):
- CASCADE: Delete referencing row(s) in A
as well
1 - - - - - - - - - - - - - - - - - - - - - - < I
A , I-------+ - -------
B
49
Handling Foreign Key Violations
• Update foreign key in A: Reject if no
row exists in B containing new foreign
key
• Update candidate key in B (to z)
- NO ACTION: Reject if row(s) in A
references row to be updated (default response)
- SET NULL: Set value of foreign key to null
- SET DEFAULT: Set value of foreign key to default
- CASCADE: Propagate z to foreign key
A z -
------ z
B
50
Handling Foreign Key Violations
• The action taken to repair the violation of a
foreign key constraint in A may cause a
violation of a foreign key constraint in C
• The action specified in C controls how that
violation is handled;
• If the entire chain of violations cannot be resolved,
the initial deletion from B is rejected.
y
X .
-----.
y
--
-----.
X
C A B 51
Specifying Actions
CREATE TABLE Teaching (
Profld INTEGER,
CrsCode CHAR (6),
Semester CHAR (6),
PRIMARY KEY (CrsCode,
Semester),
FOREIGN KEY (Profld)
REFERENCES Professor
(Id)
ON DELETE NO ACTION
ON UPDATE CASCADE,
FOREIGN KEY (CrsCode)
REFERENCES Course 52
Triggers
• A more general mechanism for
handling events
- Not in SQL-92, but is in SQL:1999
• Schema element (like table, assertion, ...
)
CREATE TRIGGER CrsChange
AFTER UPDATE OF CrsCode, Semester ON
Transcript
WHEN (Grade IS NOT
53
NULL) ROLLBACK
Views
• Schema element
• Part of external schema
• A (virtual) table constructed from (actual) tables
- Can be accessed in queries like any other table
- Not materialized, constructed when accessed
- Similar to a subroutine in ordinary programming
54
Views - Examples
CREATE VIEW CoursesTaken (Studld, CrsCode, Semester) AS
SELECT T.Studld, T.CrsCode, T.Semester
FROM Transcript T
-- part of external schema suitable for use in Bursar's office
CREATE VIEW CoursesITook (CrsCode, Semester, Grade) AS
SELECT T.CrsCode, T.Semester, T.Grade
FROM Transcript T
WHERE T.Studld = '123456789'
-- part of external schema suitable for use by student
with Id 123456789 55
Modifying the Schema
ALTER TABLE Student
ADD COLUMN Gpa INTEGER DEFAULT 0
ALTER TABLE Student
ADD CONSTRAINT GpaRange
CHECK (Gpa >= 0 AND Gpa <= 4)
ALTER TABLE Transcript
DROP CONSTRAINT Cons --constraint names are useful
DROP TABLE Employee
DROP ASSERTION DontFireEveryone 56
Access Control
• Database might contain sensitive information
• Access has to be limited:
- Users have to be identified -
authentication
• Generally done with passwords
- Each user must be limited to modes of access
appropriate to that user - authorization
• SQL:92 provides tools for specifying an
authorization policy but does not
support authentication (vendor
57
specific)
Controlling Authorization in SQL
GRANT access list
ON table
TO user list
access modes:SELECT, INSERT, DELETE, UPDATE, REFERENCE
GRANT UPDATE (Grade) ON Transcript TO prof_smith
- Only the Grade column can be updated
GRANT SELECT ON Transcript TO joe
- Individual columns cannot be specified for SELECT
access; all columns of Transcript can be read
- Access to individual columns controlled through views
GRANT SELECT ON CoursesTaken TO joe
58
Controlling Authorization in SQL
Using Views
GRANT access
ON view
TO user_list
59
Authorization:
• REFERENCE
Foreign key constraint enforces relationship
between tables that can be exploited to:
- Control access:
CREATE TABLE DontDismissMe
( Id INTEGER,
FOREIGN KEY (Id) REFERENCES Student
ON DELETE NO ACTION
--prevents deletion of
referenced row )
- Reveal information: successful insertion into
DontDissmissMe means a row with foreign key value
exists INSERT
in Student
INTO DontDismissMe (' 111111111') 60
