MODULE –II DBMS -18CS53

Module 2: The Relational Data Model

Relational Model Concepts

The principles of the relational model were first outlined by Dr. E.F. Codd in 1970 in a classic paper called
“A relational Model of Data for Large Shared Data Banks”. In this paper, Dr. Codd proposed the
relational model for the database.

The more popular models used at the time were hierarchical and network, or even simple flat file data
structures. Relational database management systems soon became very popular especially for their
ease of use and flexibility in structure. In addition, a number of innovative vendors, such as Oracle,
supplemented the RDBMS with a suite of powerful application development and user products,
providing a total solution.

Components of the Relational Model

 Collections of objects or relations that store the data
 A set of operators that can act on the relations to produce other relations
 Data integrity for accuracy and consistency
Definition of a Relational Database
A relational database is a collection of relations or two-dimensional tables.

Database

EMP DEPT

EMPNO ENAME DEPTNO DEPTNO DNAME LOC

7839 King 10 10 Accounting New York

20 Research Dallas
7698 Blake 30 30 Sales Chicago
40 Operations Boston
7782 G L Asst.Professor,
SUNIL Clark 10 Dept of CSE,SVIT . Page 1
7566 Jones 20
MODULE –II DBMS -18CS53
A relational database is a collection of relations or two-dimensional tables to store information.

For Example, you might want to store information about all the employees in your company. In a
relational database, you create several tables to store different pieces of information about your
employees, such as an employee table, a department table and a salary table

Informal Definitions

 Informally, a relation looks like a table of values.

 A relation typically contains a set of rows.
 The data elements in each row represent certain facts that correspond to a real-world entity or
relationship.
 In the formal model, rows are called tuples
 Each column has a column header that gives an indication of the meaning of the data items in
that column.
 In the formal model, the column header is called an attribute name (or just attribute).

Example of a Relation

 The data type describing the types of values that can appear in each columns is called a domain.

 Key of a Relation:
 Each row has a value of a data item (or set of items) that uniquely identifies that row in
the table called the key
Eg:- In the STUDENT table, SSN is the key.

 Sometimes row-ids or sequential numbers are assigned as keys to identify the rows in a
table called artificial key or surrogate key

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 2

MODULE –II DBMS -18CS53
Formal Definitions – Schema

 The Schema (or description) of a Relation:

 Denoted by R(A1, A2, .....An)
 R is the name of the relation
 The attributes of the relation are A1, A2, .....An
 The degree of the relation is n (the number of its attributes).
 Example:
CUSTOMER (Cust-id, Cust-name, Address, Phone#)

 CUSTOMER is the relation name.

 Defined over the four attributes:Cust-id, Cust-name, Address, Phone#

 Each attribute has a domain or a set of valid values.

 For example, the domain of Cust-id is 6 digit numbers.
 The Schema (or description) of a Relation:
 Denoted by R(A1, A2, .....An)
 R is the name of the relation
 The attributes of the relation are A1, A2, .....An
 The degree of the relation is n (the number of its attributes).
 Example:
CUSTOMER (Cust-id, Cust-name, Address, Phone#)

 CUSTOMER is the relation name.

 Defined over the four attributes:Cust-id, Cust-name, Address, Phone#
 Each attribute has a domain or a set of valid values.
 For example, the domain of Cust-id is 6 digit numbers.

 A tuple is an ordered set of values (enclosed in angled brackets ‘< … >’).

 Each value is derived from an appropriate domain.
 A row in the CUSTOMER relation is a 4-tuple and would consist of four values, for example:
 <632895, "John Smith", "101 Main St. Atlanta, GA 30332", "(404) 894-2000">
 This is called a 4-tuple as it has 4 values.
 A tuple (row) in the CUSTOMER relation.
 A relation is a set of such tuples (rows).
 A domain has a logical definition:
 Example: “University_Seat_Number” is the set of 10 characters valid in VTU university.
 “Academic_Dept_Code” is a set of academic department codes such as ‘CS’, ‘IS’, ‘EC’,
etc,.
 A domain also has a data-type or a format defined for it.
 Dates have various formats such as year, month, day formatted as yyyy-mm-dd, or as
dd-mmm-yyyy etc.
 The attribute name designates the role played by a domain in a relation:
 Example: The domain Date may be used to define two attributes named “Invoice-date”
and “Payment-date” with different meanings.

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 3

MODULE –II DBMS -18CS53

Characteristics of Relations
 Ordering of tuples in a relation r(R):
 Tuples ordering is not part of a relation definition because it is defined as a set of tuples.
 Many logical orders can be specified on the relation.
 There is no preference for one logical ordering over another.
 When a relation is implemented as a file, a physical ordering may be specified on the
records of the file.
 Ordering of values within each tuple:
 The tuple is an ordered list, so the ordering of values in a tuple is important.
 At a logical level, the order is not important as long as the correspondence between the
attribute and its value is mentioned.

 Values and NULLs in the tuple:

 All values are considered atomic (indivisible).
 Each value in a tuple must be from the domain of the attribute for that column.
 If tuple t = <v1, v2, …, vn> is a tuple (row) in the relation state r of R(A1, A2, …, An)
 Then each vi must be a value from dom(Ai)
 A special null value is used to represent values that are unknown or inapplicable to
certain tuples.
 Interpretation (Meaning) of a Relation:
- The relational schema can be interpreted as a declaration or type of assertion.

- For example, schema of the STUDENT relation interprets that, a student entity has Name,

USN, Home_phone, Address, Office_phone, Age, Gpa.

- Alternative interpretation of a relation schema is as a predicate, that values in each tuple

are interpreted as values that satisfy the predicate.

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 4

MODULE –II DBMS -18CS53
Relational Model Notation

 R(A1, A2, …., An) denotes a relation schema R of degree n (n attributes).

 r(R) is a relation state of relation schema R.
 t[Ai] and t.Ai refer to the value vi in t for attribute Ai.
 The letters Q, R, S denote relation names.
 The letters q, r, s denote relation states.
 The letters t, u, v denote tuples.
 The dot notation R.A can be used to identify the attributes (e.g. Student.Name or Student.Age).

Relational model constraints

 Constraints on databases can generally be divided into three main categories:
- Inherent model-based or Implicit constraints:- Constraints that are inherent in the data
model.

- Schema-based or explicit constraints:- Constraints that can be directly expressed in schema of

the data model using DDL.

- Application-based or semantic constraints or business rules:- Constraints expressed and

enforced using application programs.

Schema-based constraints

 Schema based constraints in the relational model are:

 Domain constraints
 Key constraints and constraints on NULL values
 Entity integrity constraints
 Referential integrity constraints
 Domain constraint
 Every value in a tuple must be from the domain of its attribute and must be atomic (or
it could be null, if allowed for that attribute).
 Key Constraints
 As a relation is defined as a set of tuple, thus no two tuples can have the same
combination of values for all their attributes.
 Usually, there are other subset of attributes (superkey SK) with this constraint: ti[SK] ≠
tj[SK]  i, j
 It is called uniqueness constraint that no two distinct tuples in r can have the same
values for SK.
 A superkey can have redundant attributes.
 A key K of R is a superkey of R with the additional property that removing any attribute
A from K leaves a set of attributes K’ that is not a superkey of R.
 A key satisfies two constraints:
 - Two distinct tuples in any state of the relation cannot have identical values for (all)
attributes in the key.

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 5

MODULE –II DBMS -18CS53
 - It is a minimal superkey – that is , a superkey from which we cannot remove any
attributes and still have the uniqueness property in condition 1 hold.
 Key is determined from the meaning of the attributes, and the property is time-
invariant.
 It must continue to hold when we insert new tuples in the relation
 Example:
 The attribute {SSN} in the Student relation is a key.
 Any set includes {SSN} is a superkey of the relation student. Eg:- {SSN, Name, Age}
 In general:
 Any key is a superkey (but not vice versa).
 Any set of attributes that includes a key is a superkey.
 A minimal superkey is also a key.
 A relation schema may have more than one key.
 Such keys are called the candidate keys.
 The primary key is one of the candidate keys which is selected to identify tuples in the
relation.
 The attributes that form the primary key are underlined in the schema.
 The primary key value is used to uniquely identify each tuple in a relation.
 Null Constraint:
 Not Null constraint specifies that an attribute must have a valid value (e.g. Student
name).
Relational Database Schema
 A relational database schema S is a set of relation schemas that belong to the same database.
 S is the name of the whole database schema.
 S = {R1, R2, …, Rm} and a set of integrity constraints IC.
 R1, R2, …, Rm are the names of the individual relation schemas within the database S.
 The integrity constraints are specified on a DB schema and are expected to hold on every DB
state.
 Example: Company Database

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 6

MODULE –II DBMS -18CS53

Entity Integrity Constraints

 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).
 If PK has several attributes, null is not allowed in any of these attributes.
 Note: Other attributes of R may be constrained to disallow null values, even though they are
not members of the primary key.

Referential Integrity Constraints

 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 referential integrity constraint can be displayed in a relational database schema as a directed
arc from R1.FK to R2.PK.
 Referential integrity constraint is based on foreign key (FK) concept
 A set of attributes FK in relation schema R1 is a foreign key of R1 that references relation R2 if it
satisfies the following two rules:
 The attributes in FK have the same domain(s) as the primary key attribute PK of R2.
 A value of FK in a tuple t1 of the current state r1(R1) either occurs as a value of PK for
some tuple t2 in the current state r2(R2) (t1[FK]=t2[PK]) or is null.
 A foreign key can refer to its own relation.
 Referential integrity constraints typically arise from the relationship among the entities.

Other Types of Constraints

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 7
MODULE –II DBMS -18CS53
 State constraints
- define the constraints that a valid state of the database must satisfy.

Ex: Domain constraints, Key Constraints, Entity Integrity constraints, Referential

Integrity constraints

Transition constraints

- defined to deal with state changes in the database.

Ex: the salary of an employee can only increase. Such constraints typically enforced by
the application programs or specified using active rules and triggers.

Update Operations on Relations

 The basic update operations of the relational model are:
 Insert
 Delete
 Update (or Modify)
 All integrity constraints specified on the database schema should not be violated by the update
operations.
 Several update operations may have to be grouped together.
 Updates may propagate to cause other updates automatically.
 This may be necessary to maintain integrity constraints.
 The basic update operations of the relational model are:
 Insert
 Delete
 Update (or Modify)
 All integrity constraints specified on the database schema should not be violated by the update
operations.
 Several update operations may have to be grouped together.
 Updates may propagate to cause other updates automatically.
 This may be necessary to maintain integrity constraints.
The Insert Operation
 INSERT may violate any of the four types of constraints:
 Domain constraint:
 if one of the attribute values provided for the new tuple is not of the specified
attribute domain.
 Key constraint:
 if the value of a key attribute in the new tuple already exists in another tuple in
the relation.
 Referential integrity:
 if a foreign key value in the new tuple references a primary key value that does
not exist in the referenced relation.
 Entity integrity:

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 8

MODULE –II DBMS -18CS53
 if the primary key value is null in the new tuple.
 Example:-
 Operation
Insert <‘Vinod’, ’S’, ‘Joseph’, NULL, ‘1986-04-05’, ‘#123, Bangalore’, F,

28000, NULL, 4> into EMPLOYEE

Result: Violates Entity IC , so it is rejected.

 Operation
Insert <‘Alice’, ’J’, ‘Zelaya’, ‘999887777’, ‘1986-04-05’, ‘#334, Bangalore’, F,

28000, ‘98764321’, 4> into EMPLOYEE

Result: Violates Key IC , so it is rejected.

 Operation
Insert <‘Cecilia’, ’F’, ‘Kolonsky’, ‘677678989’, ‘1986-04-05’, ‘#454, Bangalore’,

F, 28000, ‘99876436’, 7> into EMPLOYEE

Result: Violates Referential IC , so it is rejected

The Delete Operation

 DELETE may violate only referential integrity:
 If the primary key value of the tuple being deleted is referenced from other tuples in the
database.
 Can be remedied by several actions: RESTRICT, CASCADE, SET NULL .
 RESTRICT option: reject the deletion.
 CASCADE option: propagate deletion by deleting tuples that reference
the tuple that is deleted.
 SET NULL option: set the foreign keys of the referencing tuples to NULL.
 One of the above options must be specified during database design for each foreign key
constraint.
 Example:
 Operation
Delete the WORKS_ON tuple with ESSN-’999887777’ and Pno=10.

Result: Acceptable. Deletes exactly one tuple

 Operation
Delete the EMPLOYEE tuple with SSN= ‘999887777’.

Result: Not Acceptable. Violates Referential IC.

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 9

MODULE –II DBMS -18CS53
 Operation
Delete the EMPLOYEE tuple with SSN= ‘333445555’.

Result: Not Acceptable. Violates Referential IC.

The Update Operation

 UPDATE may violate domain constraint and NOT NULL constraint on an attribute being
modified.
 Any of the other constraints may also be violated, depending on the attribute being updated:
 Updating the primary key (PK):
 Similar to a DELETE followed by an INSERT.
 Need to specify similar options to DELETE.
 Updating a foreign key (FK):
 May violate referential integrity.
 Updating an ordinary attribute (neither PK nor FK):
 Can only violate domain constraints.

Operation

 Update the salary of an EMPLOYEE tuple with SSN =‘999887777’

to 28000.

Result: Acceptable

Operation

 Update the Dno of the EMPLOYEE tuple with SSN=‘999887777’ to 7.

Result: Violates Referential IC

 Operation
Update the SSN of the EMPLOYEE tuple with SSN=‘999887777’ to ‘987654321’.

Result: Violates Primary key constraints

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 10

MODULE –II DBMS -18CS53

ER-to-Relational Mapping
Step 1

» For each regular entity type E in the ER schema, create a relation R that includes all the simple
attributes of E

» For composite attributes, use the simple component attributes.

» Choose one of the key attributes of E as the primary key for R.

» If the chosen key was a composite, the set of simple attributes that form it will together be the
primary key of R.

Step 2

» For each weak entity type W in the ER schema with owner entity type E, create a relation R that
includes all simple attributes (or simple components of composites) of W.

» Include as foreign key attributes of R the primary key attribute of the relation that corresponds to the
owner entity type E.

» The primary key of R is the combination of the primary key of the owner and the partial key of the
weak entity type, if any.

Step 3
» 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 (say S). Include as a foreign key in S the primary key of T.

» It is better to choose an entity type with total participation in R for the role of S.

» Include the simple attributes of R as attributes of S.

Step 4

» For each binary 1:N relationship type R, identify the relation S that represents the entity type
participating at the N-side of the relationship

» Include as a foreign key in S the primary key of the relation T that represents the other entity type
participating in R.

» Include the simple attributes of R as attributes of S.

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 11

MODULE –II DBMS -18CS53
Step 5

» 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 participating entity types.

» Their combination will form the primary key.

» Include any attributes of R as attributes of S.

Step 6

» For each multi-valued attribute A, create a new relation R.

» R will include an attribute corresponding to A, plus the primary key attribute K of the relation that has
A as an attribute.

» The primary key of R is the combination of A and K.

Step 7

» For each n-ary relationship type R, where n>2, create a new relation S.

» Include as foreign key attributes in S the primary keys of the relations that represent the participating
entity types

» Include any attributes of R.

» The primary key of S is usually a combination of all the foreign keys in S.

ER TO RELATIONAL MAPPING Example

The ER model is convenient for representing an initial, high-level database design. Given an ER diagram
describing a databa'3e, a standard approach is taken to generating a relational database schema that
closely approximatesthe ER design. We now describe how to translate an ER diagram into a collection of
tables with associated constraints, that is, a relational database schema.

3.5.1 Entity Sets to Tables

An entity set is mapped to a relation in a straightforward way: Each attribute of the entity set becomes
an attribute of the table. Note that we know both the domain of each attribute and the (primary) key of
an entity set.

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 12

MODULE –II DBMS -18CS53

3.5.2 Relationship Sets (without Constraints) to Tables

A relationship set, like an entity set, is mapped to a relation in the relational model.

To represent a relationship, we must be able to identify each participating entity and give values to the
descriptive attributes of the relationship. Thus, the attributes of the relation include:

• The primary key attributes of each participating entity set, as foreign key fields.

• The descriptive attributes of the relationship set.

The set of nondescriptive attributes is a superkey for the relation. If there are no key constraints, this set
of attributes is a candidate key.

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 13

MODULE –II DBMS -18CS53

CREATE TABLE Works_In2 ( ssn CHAR(11), did INTEGER, address CHAR(20) , since DATE, PRIMARY KEY
(8sn, did, address), FOREIGN KEY (ssn) REFERENCES Employees, FOREIGN KEY (address) REFERENCES
Locations, FOREIGN KEY (did) REFERENCES Departments);

3.5.3 Translating Relationship Sets with Key Constraints

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 14

MODULE –II DBMS -18CS53
If a relationship set involves n entity sets and somem of them are linked via arrows in the ER diagTam,
the key for anyone of these m entity sets constitutes a key for the relation to which the relationship set
is mapped.

The following SQL statement, defining a DepLMgr relation that captures the information in both
Departments and Manages, illustrates the approach to translating relationship sets with key constraints:

CREATE TABLE DepLMgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR (11) , since DATE,
PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees)

Note that ssn can take on null values.

3.5.4 Translating Relationship Sets with Participation Constraints

Consider the ER diagram in Figure 3.13, which shows two relationship sets, Manages and "Works_In.

Every department is required to have a manager, due to the participation constraint, and at most one
manager, due to the key constraint.

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 15

MODULE –II DBMS -18CS53
It also captures the participation constraint that every department must have a manager: Because ssn
cannot take on null values, each tuple of Dep-Mgr identifies a tuple in Employees (who is the manager).
The NO ACTION specification, which is the default and need not be explicitly specified, ensures that an
Employees tuple cannot be deleted while it is pointed to by a Dept-Mgr tuple.

3.5.5 Translating Weak Entity Sets

A weak entity set always participates in a one-to-many binary relationship and has a key constraint and
total participation.we must take into account that the weak entity has only a partial key. Also, when an
owner entity is deleted, we want all owned weak entities to be deleted.

3.5.6 Translating Class Hierarchies

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 16

MODULE –II DBMS -18CS53

3.5.7 Translating ER Diagrams with Aggregation

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 17

MODULE –II DBMS -18CS53
3.5.8 ER to Relational: Additional Examples

CREATE TABLE Dependents (pnameCHAR(20) , age INTEGER, policyid INTEGER, PRIMARY KEY (pname,
policyid), FOREIGN KEY (policyid) REFERENCES Policies ON DELETE CASCADE);

SUNIL G L Asst.Professor, Dept of CSE,SVIT . Page 18