The Relational Data Model

and Relational Database

Constraints

1
What is a data model?
Data model
An integrated collection of concepts for
describing data, relationships between
data, and constraints on the data used by
an organization.
A model
Is a representation of ‘real world’ objects
and events, and their associations.
It concentrates on the essential, inherent
aspects of an organization and ignores the
accidental properties.
2
A data model can be thought of as
comprising three components:
(1) A structural part, consisting of a set of
rules that define how the database is to be
constructed;
(2) A manipulative part, defining the types
of operations (transactions) that are
allowed on the data (this includes the
operations that are used for updating or
retrieving data and for changing the
structure of the database);
(3) Possibly a set of integrity rules, which
ensures that the data is accurate. 3
 Relational Model
 Concepts
The relational model represents the
database as a collection of relations
 The relational Model of Data is based on
the concept of a Relation
 When a relation is thought of as a table of
values, each row in the table represents a
collection of related data values.
 The table name and column names are
used to help in interpreting the meaning of
the values in each row
 A Relation is a mathematical concept
based on the ideas of sets 4
 Relational Model Concepts
For example,
The given table below is called STUDENT because
each row represents facts about a particular student
entity.

5
 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 Slide 5- 6
is
called an attribute name (or just attribute)
Example of a Relation

Slide 5- 7
 Informal Definitions
 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
 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 Slide 5- 8
 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
 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.
Slide 5- 9
 For example, the domain of Cust-id is 6 digit
 Formal Definitions - Tuple
 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)
Slide 5- 10
 Formal Definitions - Domain
 A domain has a logical definition:
 Example: “USA_phone_numbers” are the set of 10 digit phone
numbers valid in the U.S.
 A domain also has a data-type or a format defined for
it.
 The USA_phone_numbers may have a format: (ddd)ddd-dddd
where each d is a decimal digit.
 Dates have various formats such as year, month,
date formatted as yyyy-mm-dd, or as dd mm,yyyy
etc.

 The attribute name designates the role played by a

domain in a relation:
 Used to interpret the meaning of the data elements

corresponding to that attribute

 Example: The domain Date may be used to define two
attributes named “Invoice-date” and “Payment-date” with
Slide 5- 11
different meanings
 Formal Definitions - State
 The relation state is a subset of the
Cartesian product of the domains of its
attributes
 each domain contains the set of all possible
values the attribute can take.
 Example: attribute Cust-name is defined
over the domain of character strings of
maximum length 25
 dom(Cust-name) is varchar(25)
 The role these strings play in the
CUSTOMER relation is that of the name of
a customer.
Slide 5- 12
 Formal Definitions - Summary
 Formally,
 Given R(A1, A2, .........., An)
 r(R)  dom (A1) X dom (A2) X ....X dom(An)
 R(A1, A2, …, An) is the schema of the relation
 R is the name of the relation
 A1, A2, …, An are the attributes of the relation
 r(R): a specific state (or "value" or “population”) of
relation R – this is a set of tuples (rows)
 r(R) = {t1, t2, …, tn} where each ti is an n-tuple
 ti = <v1, v2, …, vn> where each vj element-of dom(Aj)

Slide 5- 13
 Formal Definitions - Example
 Let R(A1, A2) be a relation schema:
 Let dom(A1) = {0,1}
 Let dom(A2) = {a,b,c}
 Then: dom(A1) X dom(A2) is all possible
combinations:
{<0,a> , <0,b> , <0,c>, <1,a>, <1,b>, <1,c> }

 The relation state r(R)  dom(A1) X dom(A2)

 For example: r(R) could be {<0,a> , <0,b> , <1,c> }
 this is one possible state (or “population” or “extension”) r
of the relation R, defined over A1 and A2.
 It has three 2-tuples: <0,a> , <0,b> , <1,c>
Slide 5- 14
Informal and Formal Definitions

15
Relational Model
• It was proposed by E.F. Codd in 1970 to model data
in the form of relations or tables.
• It represents how data is stored in Relational
Databases.
• A relational database stores data in the form of
relations.
• Each relation has columns and rows which are
formally called attributes and tuples respectively.
• Each tuple in relation is a real-world entity.
16
Relational Model Diagram
― The figure below will help you identify the relation,
attributes, and tuples in a relational model.
― It is an Employee relation and it is having entries of
6 employees (tuples) in it.

17
Terminology
― Relations / Tables – Relations are saved in the table
format. A table has two properties rows and columns.
Rows represent records and columns represent
attributes.
― Attribute: Attributes are the properties which define a
relation.
― Tuple: It is nothing but a single row of a table.
― Degree / arity: The total number of attributes in a
relation.
― Cardinality: Total number of rows present in the Table.
― Domain: Set of possible values for an attribute
― Relation instance: It is a finite set of tuples. They never
have duplicate tuples.
― Relation Schema: It represents the name of the relation
with its attributes. 18
Characteristics of a relation
―Each relation in a database must have
a distinct or unique name.
―Each attribute must have a distinct
name (no two attributes should have
the same name).
―Duplicate tuples must not be present
in a relation.
―Each tuple must have exactly one
data value for an attribute.
―No ordering is required for tuples,
19
 RELATIONAL MODEL
CONSTRAINTS
Constraint means a condition.
Therefore database tables or
relations are created based on
constraints or conditions
Constraints are conditions that must
hold on all valid relation states.

20
Relational Integrity Constraints
― They are referred to as conditions that are applied
to the table to ensure the correctness of the data in
the database.
― These constraints are checked before performing
any operation in database. If there is a violation in
any of constrains, operation will fail.
― Thus, integrity constraint is used to guard against
accidental damage to the database.
― They are mostly divided into the following main
categories:
― Key Constraints
― Domain Constraints
― Entity Integrity Constraints
― Referential Integrity Constraints
21
Key Constraints
A Key Constraint is a statement that a certain
minimal subset of the fields of a relation is a unique
identifier for a tuple.
The following are the types of key constraints-
1. Super Key
2. Candidate key.
3. Primary key
4. Secondary or Alternative key
5. unique key
6. Foreign key.
22
Example:
Relation: STUDENT
STUD_NO NAME AGE MOBILE_NO
512 Akshay 20 9876723452
513 Krishna 23 9991165674
546 Vivek 20 7898756543
557 Raghu 21 8987867898
595 Krishna 22 9876543210

Relation: STUDENT-COURSE
STUD_NO COURSE_NO COURSE_NAME
512 C1 DBMS
546 C2 PYTHON
512 C2 PYTHON 23
Super Key
― A single attribute or set of attributes that can be
uniquely identify all attributes of a particular
relation is called supper key.
― Super key contains one or more than one attribute

― The set of attributes which can uniquely identify a tuple is

known as Super Key. For Example, STUD_NO, (STUD_NO,
STUD_NAME), MOBILE_NO, etc.
― Adding zero or more attributes to candidate key generates a
super key.
― Super Key is a superset of Candidate key.

― A candidate key is a superkey but vice versa is not true.

24
Candidate Key
― The minimal set of attributes which can uniquely
identify a tuple is known as a candidate key. For
example, STUD_NO in STUDENT relation.
― A candidate key can never be NULL or empty and its value should
be unique.
― Candidate keys are selected from are selected from the set of
super keys, the only thing we take care while selecting candidate
key is: It should not have any redundant attributes.
― There can be more than one candidate keys for
table. For example, STUD_NO, as well as
MOBILE_NO both, are candidate keys for relation
STUDENT.

― The candidate key can be simple or composite. For Example,

{STUD_NO, COURSE_NO} is a composite candidate key for
relation STUDENT_COURSE. 25
Difference between Super Key and Candidate Key
― A single attribute or set of attributes that can be
uniquely identify all attributes of a particular relation
is called supper key.
― On the other hands, a super key that is a proper subset of another
super key is called candidate key.
― All candidate keys are super keys but the inverse is
not true

― The set of super keys is verified to find candidate keys whereas,

the set of candidate keys is verified to select a single primary key

26
Primary Key
― A primary key is being selected from the group of candidate
keys
― Primary Key (cannot have null value) - attribute(s) that uniquely
identify a tuple in a table.
― There can be more than one candidate key in a relation out of
which one can be chosen as a primary key.
― For Example, STUD_NO as well as MOBILE_NO both are
candidate keys for relation STUDENT but STUD_NO can be
chosen as primary key.
Properties of Primary Keys
― A relation can have only one primary key
― Each value in a primary key must be unique
― Primary key cannot contain NULL values

27
Note:
―Super Key is the broadest unique
identifier;
―Candidate Key is a subset of
super key;
―Primary Key is a subset of
candidate key

28
Secondary or Alternative key
―The candidate key other than the primary key
is called an alternate key / Secondary key.

―For Example, STUD_NO, as well as MOBILE_NO

both, are candidate keys for relation STUDENT
but STUD_PHONE will be alternate key.

29
Unique Key
Unique key is the same as primary with the
difference being the existence of null value.
Unique key field allows one value as NULL value.

Similar to primary key but having NULL value.

Eg PhoneNo, Contact and Email Address. This is
because it may happen to have someone with
no PhoneNo or Email. So Unique key will allow
acceptance of NULL value.

30
Foreign Key
― Foreign Keys are the columns of a table that point to
the primary key of another table
― Key used to create a relationship between two tables
― Here in below tables DeptIDof Department table is
Primary Key where as DeptIDof Employee is an
Foreign key.
― It means it has referred to another table. This concept
is also know as Referential Integrity.

31
Entity integrity constraint
― Entity integrity constraint ensures that the primary key attribute
in a relation, should not accept a null value.

― This is because the primary key attribute value uniquely defines

an entity in a relation.
Example: Consider the following Student table
Roll_n
Name Age
o
Aksha
S001 20
y
Krishn
S013 23
a
S056 Vivek 20
Not allowed as primary key can’t contain a NULL value. 32
Raghu 21
Referential Integrity Constraints
• A referential integrity constraint is specified between two
tables.
• It states that if a foreign key exists in a relation then either
the foreign key value must match a primary key value of
some tuple in its parent relation or the foreign key value
must be null.
The rules are:
1. You can't delete a record from a primary table if matching
records exist in a child table.
2. You can't change a primary key value in the primary table if that
record has child records.
3. You can't enter a value in the foreign key field of the child table
that doesn't exist in the primary key of the parent table.
4. However, you can enter a Null value in the foreign key, specifying
that the records are unrelated. 33
Example
• Consider 2 relations “Dept" and “Emp" Where “D_No" is the
primary key in the “Dept" relation and foreign key in the “Emp"
relation.
• In this, if a foreign key in Emp table refers to the Primary Key of
Dept table, then every value of the Foreign Key in Emp table must
be null or be available in Dept Table.

34
Domain Constraint
• Domain constraint defines the domain or set of values
for an attribute.
• It specifies that the value taken by the attribute must
be from its domain only.
• Example: Consider the following Student table
Roll_no Name Age
S001 Akshay 20
S013 Krishna 23
S056 Vivek Z
S054 Raghu 21

• Here, value ‘Z’ is not allowed since only positive integer

values can be taken by the age attribute.

35
Discussion Questions
Define the following terms as they apply to the relational model of data:
i. Domain
ii. Attribute
iii. N-tuple
iv. Relation schema
v. Relation state
vi. Degree of a relation
vii. Relational database schema
viii. Relational database state
ix. Why are tuples in a relation not ordered?
x. Why are duplicate tuples not allowed in a relation?
xi. What is the difference between a key and a super key?
xii. Why do we designate one of the candidate keys of a relation to be the
primary key?
xiii. Discuss the characteristics of relations that make them different from
ordinary tables and files.
xiv. Discuss the various reasons that lead to the occurrence of NULL values in
relations.
xv. Discuss the entity integrity and referential integrity constraints. Why each is
considered important?
xvi. Define foreign key. What is this concept used for?
xvii. What is a transaction? How does it differ from an Update operation? 36
Any Queries?

37
Thank you

38