Relational Data Model

Outline

 Relational Model Concepts

 Relational Model Constraints and Relational
Database Schemas
 Update Operations and Dealing with Constraints
 Reading Suggestion:
• Chapters 5, 7, 12
 Overall
 The first commercial implementations of the relational model became available in
the early 1980s, such as the SQL/DS system on the MVS operating system by IBM
and the Oracle DBMS. Since then, the model has been implemented in a large number of
commercial systems, as well as a number of open source systems. Current popular
commercial relational DBMSs (RDBMSs) include DB2 (from IBM), Oracle (from Oracle),
Sybase DBMS (now from SAP), and SQLServer and Microsoft Access (from Microsoft).
In addition, several open source systems, such as MySQL and PostgreSQL, are
available.
In this chapter, we concentrate on describing the basic principles of the relational model
of data. We begin by defining the modeling concepts and notation of the relational model
in Section 5.1. Section 5.2 is devoted to a discussion of relational constraints that are
considered an important part of the relational model and are automatically enforced in
most relational DBMSs. Section 5.3 defines the update operations of the relational
model, discusses how violations of integrity constraints are handled.
 Relational Model Concepts
 The relational model of data is based on the
concept of a relation
 A relation is a mathematical concept based on the
ideas of sets
 The model was first proposed by Dr. E.F. Codd of
IBM in 1970 in the following paper:
"A Relational Model for Large Shared Data Banks,"
Communications of the ACM, June 1970

4
 Relational Model Concepts
 Relational data model: represents a database in the form of
relations - 2-dimensional table with rows and columns of
data. A database may contain one or more such tables. A
relation schema is used to describe a relation
 Relation schema: R(A1, A2,…, An) is made up of a relation
name R and a list of attributes A1, A2, . . ., An. Each
attribute Ai is the name of a role played by some domain D
in the relation schema R. R is called the name of this relation
 The degree of a relation is the number of attributes n of its
relation schema.
 Domain D: D is called the domain of Ai and is denoted by
dom(Ai). It is a set of atomic values and a set of integrity
constraints
STUDENT(Name, SSN, HomePhone, Address, OfficePhone, Age, GPA)
Degree = ??
dom(GPA) = ??

5
 Relational Model Concepts
 Tuple: row/record in table
 Cardinality: number of tuples in a table
 Database schema S = {R1, R2,…, Rm}

6
 Relational Model Concepts
 A relation (or relation state, relation instance) r of the
relation schema R(A1, A2, . . ., An), also denoted by r(R), is
a set of n-tuples r = {t1, t2, . . ., tm}. Each n-tuple t is an
ordered list of n values t = <v1, v2, . . ., vn>, where each
value vi, i=1..n, is an element of dom(Ai) or is a special null
value. The ith value in tuple t, which corresponds to the
attribute Ai, is referred to as t[Ai]

Relational data model

Database schema
Relation schema
Relation
Tuple
Attribute

7
 Relational Model Concepts
 A relation can be
conveniently represented
by a table, as the example
shows
 The columns of the tabular
relation represent attributes
 Each attribute has a distinct
name, and is always
referenced by that name,
never by its position
 Each row of the table
represents a tuple. The
ordering of the tuples is
immaterial and all tuples
must be distinct

8
Relational Model Concepts
Alternative Terminology for Relational Model

9
 Relational Model Concepts
Notes
Informal Terms Formal Terms
Table Relation
Column Header Attribute
All possible Column Domain
Values
Row Tuple

Table Definition Schema of a Relation

Populated Table State of the Relation

10
 Relational Model Constraints
and Relational Database Schemas
 Constraints are conditions that must hold on all
valid relation instances. There are three main
categories of constraints:

11
 Relational Model Constraints
and Relational Database Schemas
 1. Constraints that are inherent in the data model. We
call these inherent
 model-based constraints or implicit constraints.
 2. Constraints that can be directly expressed in the
schemas of the data model. We call these schema-
based constraints or explicit constraints.
 3. Constraints that cannot be directly expressed in
the schemas of the data model, and hence must be
expressed and enforced by the application programs
or in some other way. We call these application-
based or semantic constraints or business rules.
 1. Domain Constraints
 Domain constraints specify that within each tuple, the value of each attribute A
must be an atomic value from the domain dom(A).
 The data types associated with domains typically include standard numeric data
types for integers (such as short integer, integer, and long integer) and real
numbers (float and double-precision float). Characters, Booleans, fixed-length
strings, and variable-length strings are also available, as are date, time,
timestamp, and other special data types.
 Domains can also be described by a subrange of values from a data type or as
an enumerated data type in which all possible values are explicitly listed.

13
2. Key Constraints and Constraints on NULL
Values
 Superkey of R: A set of attributes SK of R such that no two
tuples in any valid relation instance r(R) will have the same
value for SK. That is, for any distinct tuples t1 and t2 in
r(R), t1[SK]  t2[SK]
 Key of R: A "minimal" superkey; that is, a superkey K such
that removal of any attribute from K results in a set of
attributes that is not a superkey
Example: The CAR relation schema:
CAR(State, Reg#, SerialNo, Make, Model, Year) has two keys
Key1 = {State, Reg#}
Key2 = {SerialNo}, which are also superkeys. {SerialNo, Make} is a
superkey but not a key
 If a relation has several candidate keys, one is chosen
arbitrarily to be the primary key. The primary key attributes
are underlined

14
2. Key Constraints and Constraints on NULL
Values
 The CAR relation, with two candidate keys:
License_Number and Engine_Serial_Number

15
 3. Relational Databases and Relational
Database Schemas
 Relational Database Schema: A set S of relation schemas
that belong to the same database. S is the name of the
database
S = {R1, R2, ..., Rn}
 Figure 5.5 shows a relational database schema that we call
COMPANY = {EMPLOYEE, DEPARTMENT,
 DEPT_LOCATIONS, PROJECT, WORKS_ON,
DEPENDENT}.

16
3. Relational Databases and Relational
Database Schemas

17
3. Relational Databases and Relational
Database Schemas

18
4. Entity Integrity, Referential Integrity, and
Foreign Keys
 Entity Integrity: The primary key attributes PK of
each relation schema R in S cannot have null
values in any tuple of r(R). This is because primary
key values are used to identify the individual tuples.
t[PK]  null for any tuple t in r(R)
  Note: Other attributes of R may be similarly
constrained to disallow null values, even though
they are not members of the primary key

19
 4 Entity Integrity, Referential Integrity, and
Foreign Keys
Referential Integrity
A constraint involving two relations (the previous constraints
involve a single relation)
Used to specify a relationship among tuples in two relations:
the referencing relation and the referenced relation
Tuples in the referencing relation R1 have attributes FK
(called foreign key attributes) that reference the primary key
attributes PK of the referenced relation R2. A tuple t1 in R1 is
said to reference a tuple t2 in R2 if t1[FK] = t2[PK]
A referential integrity constraint can be displayed in a
relational database schema as a directed arc from R1.FK to R2

20
4. Entity Integrity, Referential Integrity,
and Foreign Keys
Referential Integrity

21
4. Entity Integrity, Referential Integrity,
and Foreign Keys
Foreign keys
 The value in the foreign key column (or columns) FK of the the referencing
relation R1 can be either:
• (1) a value of an existing primary key value of the corresponding primary key
PK in the referenced relation R2,, or
• (2) a NULL
 In case (2), the FK in R1 should not be a part of its own primary key
 The conditions for a foreign key, given below, specify a referential integrity
constraint between the two relation schemas R1 and R2. A set of attributes FK
in relation schema R1 is a foreign key of R1 that references relation R2 if it
satisfies the following rules:
 1. The attributes in FK have the same domain(s) as the primary key attributes
PK of R2
 2. For every tuple t2 of R2, there is always a tuple t1 of R1 such that t2[FK] =
t1[PK]

22
Referential integrity constraints displayed on the COMPANY
relational database schema

23
 4. Entity Integrity, Referential Integrity, and Foreign Keys
Other Types of Constraints

 Semantic Integrity Constraints:

- based on application semantics and cannot be expressed
by the model per se
- E.g., “the max. no. of hours per employee for all projects
he or she works on is 56 hrs per week”
- A constraint specification language may have to be used
to express these
- SQL-99 allows triggers and ASSERTIONS to allow for
some of these
 State/static constraints (so far)
 Transition/dynamic constraints: e.g., “the salary of
an employee can only increase”

24
 Relational Data Model
 Basic Concepts: relational data model, relation
schema, domain, tuple, cardinality & degree,
database schema, etc.
 Relational Integrity Constraints
• key, primary key & foreign key
• entity integrity constraint
• referential integrity
 Update Operations and Dealing with Constraint
Violations

25
 III. Update Operations and Dealing with Constraint
Violations

 1. INSERT a tuple
 2. DELETE a tuple
 3. Update a tuple
 
 Integrity constraints should not be violated by the
update operations

26
 3.1 The Insert Operation
 Insertion: to insert a new tuple t into a relation R.
When inserting a new tuple, it should make sure
that the database constraints are not violated:
• The value of an attribute should be of the correct data
type (i.e. from the appropriate domain).
• The value of a prime attribute (i.e. the key attribute) must
not be null
• The key value(s) must not be the same as that of an
existing tuple in the same relation
• The value of a foreign key (if any) must refer to an
existing tuple in the corresponding relation
 Options if the constraints are violated

27
 3.1 The Insert Operation
 ■ Operation:
 Insert <‘Cecilia’, ‘F’, ‘Kolonsky’, NULL, ‘1960-04-05’, ‘6357 Windy Lane, Katy,
 TX’, F, 28000, NULL, 4> into EMPLOYEE.
 Result: This insertion violates the entity integrity constraint (NULL for the
 primary key Ssn), so it is rejected.
 ■ Operation:
 Insert <‘Alicia’, ‘J’, ‘Zelaya’, ‘999887777’, ‘1960-04-05’, ‘6357 Windy Lane, Katy,
 TX’, F, 28000, ‘987654321’, 4> into EMPLOYEE.
 Result: This insertion violates the key constraint because another tuple with
 the same Ssn value already exists in the EMPLOYEE relation, and so it is
 rejected.
 ■ Operation:
 Insert <‘Cecilia’, ‘F’, ‘Kolonsky’, ‘677678989’, ‘1960-04-05’, ‘6357 Windswept,
 Katy, TX’, F, 28000, ‘987654321’, 7> into EMPLOYEE.
 Result: This insertion violates the referential integrity constraint specified on
 Dno in EMPLOYEE because no corresponding referenced tuple exists in
 DEPARTMENT with Dnumber = 7.
 ■ Operation:
 Insert <‘Cecilia’, ‘F’, ‘Kolonsky’, ‘677678989’, ‘1960-04-05’, ‘6357 Windy Lane,
 Katy, TX’, F, 28000, NULL, 4> into EMPLOYEE.
 Result: This insertion satisfies all constraints, so it is acceptable

28
 3.1 The Insert Operation
 Options if the constraints are violated
 If an insertion violates one or more constraints, the default
option is to reject the insertion. In this case, it would be
useful if the DBMS could provide a reason to the user as to
why the insertion was rejected. Another option is to attempt
to correct the reason for rejecting the insertion, but this is
typically not used for violations caused by Insert; rather, it is
used more often in correcting violations for Delete and
Update.

29
 3.2 The Delete Operation
 Deletion: to remove an existing tuple t from a
relation R. When deleting a tuple, the following
constraints must not be violated:
• The tuple must already exist in the database
• The referential integrity constraint is not violated

30
 3.2 The Delete Operation
■ Operation:
Delete the WORKS_ON tuple with Essn = ‘999887777’ and Pno = 10.
Result: This deletion is acceptable and deletes exactly one tuple.
■ Operation:
Delete the EMPLOYEE tuple with Ssn = ‘999887777’.
Result: This deletion is not acceptable, because there are tuples in
WORKS_ON that refer to this tuple. Hence, if the tuple in EMPLOYEE is
deleted, referential integrity violations will result.
■ Operation:
Delete the EMPLOYEE tuple with Ssn = ‘333445555’.
Result: This deletion will result in even worse referential integrity violations,
because the tuple involved is referenced by tuples from the EMPLOYEE,
DEPARTMENT, WORKS_ON, and DEPENDENT relations.

31
 3.2 The Delete Operation
 Options if the constraints are violated:
 Several options are available if a deletion operation causes a violation.
The first option, called restrict, is to reject the deletion. The second
option, called cascade, is to attempt to cascade (or propagate) the
deletion by deleting tuples that reference the tuple that is being deleted.
For example, in operation 2, the DBMS could automatically delete the
offending tuples from WORKS_ON with Essn = ‘999887777’. A third
option, called set null or set default, is to modify the referencing attribute
values that cause the violation; each such value is either set to NULL or
changed to reference another default valid tuple. Notice that if a
referencing attribute that causes a violation is part of the primary key, it
cannot be set to NULL; otherwise, it would violate entity integrity.

32
 3.3 The Update Operation
 Update(Modification): to change values of some attributes of an existing tuple t in a
relation R
■ Operation:
 Update the salary of the EMPLOYEE tuple with Ssn = ‘999887777’ to 28000.
 Result: Acceptable.
■ Operation:
 Update the Dno of the EMPLOYEE tuple with Ssn = ‘999887777’ to 1.
 Result: Acceptable.
■ Operation:
 Update the Dno of the EMPLOYEE tuple with Ssn = ‘999887777’ to 7.
 Result: Unacceptable, because it violates referential integrity.
■ Operation:
 Update the Ssn of the EMPLOYEE tuple with Ssn = ‘999887777’ to ‘987654321’.
Result: Unacceptable, because it violates primary key constraint by repeating a value that
already exists as a primary key in another tuple; it violates referential integrity constraints
because there are other relations that refer to the existing value of Ssn.


 3.3 The Update Operation
 Options if the constraints are violated:
 Updating an attribute that is neither part of a primary key nor part of a
foreign key usually causes no problems; the DBMS need only check to
confirm that the new value is of the correct data type and domain. Modifying
a primary key value is similar to deleting one tuple and inserting another in
its place because we use the primary key to identify tuples
 Hence, the issues discussed earlier in both Sections 3.1 (Insert) and 3.2
(Delete) come into play. If a foreign key attribute is modified, the DBMS
must make sure that the new value refers to an existing tuple in the
referenced relation (or is set to NULL). Similar options exist to deal with
referential integrity violations caused by Update as those options discussed
for the Delete operation. In fact, when a referential integrity constraint is
specified in the DDL, the DBMS will allow the user to choose separate
options to deal with a violation caused by Delete and a violation caused by
Update

34