MODULE 2
Introduction to Databases
Database Management System
Subject Code: 18CS53
CONTENTS
• Relational Model: Relational Model Concepts
– Relational Model Constraints and relational database schemas
– Update operations
– transactions and dealing with constraint violations.
• Relational Algebra:
– Unary and Binary relational operations
– additional relational operations (aggregate, grouping, etc.)
– Examples of Queries in relational algebra.
• Mapping Conceptual Design into a Logical Design:
-- Relational Database Design using ER-to-Relational mapping.
• SQL:
• SQL data definition and data types
• Specifying constraints in SQL
• Retrieval queries in SQL, INSERT, DELETE, and UPDATE statements in SQL
• Additional features of SQL.
Relational Model Concepts
• The relational model represents the database
as a collection of relations.
• A Relation is a mathematical concept based on
the ideas of sets
• The model was first proposed by Dr. E.F. Codd
of IBM Research in 1970 in the following
paper:
– "A Relational Model for Large Shared Data Banks,"
Communications of the ACM, June 1970 Slide 5- 4
Why Relations?
• Very simple model.
• Often matches how we think about data.
• Abstract model that underlies SQL, the most
important database language today.
Slide 5- 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 is called an
attribute name (or just attribute)
Slide 5- 6
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.
• Domain is the set of allowable values for one or more
attributes.
– For example, the domain of Cust-id is 6 digit numbers.
Slide 5- 9
Comparative Terms
Formal Oracle
Relation schema Table description
Relation Table
Tuple Row
Attribute Column
Domain Value set
• Notation
•
Course (courseno, subject, equipment)
•
Student(studno,name,hons)
• Enrol(studno,courseno,labmark)
Slide 5- 10
Relational Model Terminology
• Tuple is a row of a relation.
• Degree is the number of attributes in a relation.
• Cardinality is the number of tuples in a relation.
• Relational Database is a collection of normalized relations
with distinct relation names.
Slide 5- 11
Definition Summary
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
Slide 5- 12
Example – A relation STUDENT
Slide 5- 13
Properties of Relations
• Relation name is distinct from all other relation names in
relational schema.
• Each cell of relation contains exactly one atomic (single)
value.
• Each attribute has a distinct name.
• Values of an attribute are all from the same domain.
• Each tuple is distinct; there are no duplicate tuples.
Slide 5- 14
Properties of Relations
• Order of attributes has no significance.
• Order of tuples has no significance, theoretically.
• A special null value is used to represent values that are
unknown or inapplicable to certain tuples.
– Represents the absence of a value and is not the same as zero or
spaces, which are values.
Slide 5- 15
Relational Integrity Constraints
• Constraints are conditions that must hold on all valid relation
states.
• There are three main types of constraints in the relational
model:
– Key constraints
– Entity integrity constraints
– Referential integrity constraints
• Another implicit constraint is the domain constraint
– Every value in a tuple must be from the domain of its attribute
(or it could be null, if allowed for that attribute)
Slide 5- 16
Key Constraints
• Superkey:
– An attribute, or a set of attributes whose
values together uniquely identify a tuple
in a relation.
• Key or Candidate Key:
– A "minimal" superkey
– A superkey K such that removal of any attribute from K
results in a set of attributes that is not a superkey
(does not possess the superkey uniqueness property)
Slide 5- 17
Key Constraints (continued)
• Primary Key
– a candidate key chosen to be the main key for
the relation.
– One for each relation
• Alternate Keys
– Candidate keys that are not selected to be
primary key.
• Foreign Key
– Attribute, or set of attributes, within one
relation that matches candidate key in other or
same relation.
• Keys can be composite Slide 5- 18
Key Constraints (continued)
• Example: Consider the CAR relation schema:
– CAR(State, Reg#, SerialNo, Make, Model, Year)
– CAR has two keys:
• Key1 = {State, Reg#}
• Key2 = {SerialNo}
– Both are also superkeys of CAR
– {SerialNo, Make} is a superkey but not a key.
• 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
Slide 5- 19
Key Constraints (continued)
• If a relation has several candidate keys, one is chosen
arbitrarily to be the primary key.
– The primary key attributes are underlined.
• Example: Consider the CAR relation schema:
– CAR(State, Reg#, SerialNo, Make, Model, Year)
– We chose SerialNo as the primary key
• The primary key value is used to uniquely identify each tuple
in a relation
– Provides the tuple identity
• Also used to reference the tuple from another tuple
– General rule: Choose as primary key the smallest of the
candidate keys (in terms of size)
Slide 5- 20
CAR table with two candidate keys –
License_Number chosen as Primary Key
Slide 5- 21
Entity Integrity
• Entity Integrity:
– The primary key attributes PK of each relation cannot have
null values.
• This is because primary key values are used to identify the
individual tuples.
• 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.
Slide 5- 22
Referential Integrity
• A constraint involving two relations
– 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.
Slide 5- 23
Referential Integrity (or foreign key)
Constraint
• 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 a
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. Slide 5- 24
General Constraints
• Additional rules specified by users or database
administrators that define or constrain some
aspect of the enterprise.
Slide 5- 25
Displaying a relational database schema
and its constraints
• Each relation schema can be displayed as a row of attribute
names
• The name of the relation is written above the attribute names
• The primary key attribute (or attributes) will be underlined
• A foreign key (referential integrity) constraints is displayed as
a directed arc (arrow) from the foreign key attributes to the
referenced table
– Can also point the the primary key of the referenced relation for
clarity
• Next slide shows the COMPANY relational schema diagram
Slide 5- 26
Referential Integrity Constraints for COMPANY DB
Slide 5- 27
Populated database state
• Each relation will have many tuples in its
current relation state
• Whenever the database is changed, a new state
arises
• Basic operations for changing the database:
– INSERT a new tuple in a relation
– DELETE an existing tuple from a relation
– MODIFY an attribute of an existing tuple
• Next slide shows an example state for the
COMPANY database
Slide 5- 28
Populated database state for COMPANY
Slide 5- 29
Update Operations on Relations
• INSERT a tuple.
• DELETE a tuple.
• MODIFY a tuple.
• Integrity constraints 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.
Slide 5- 30
Update Operations on Relations
• In case of integrity violation, several actions
can be taken:
– Cancel the operation that causes the violation
(RESTRICT or REJECT option)
– Perform the operation but inform the user of the
violation
– Trigger additional updates so the violation is
corrected (CASCADE option, SET NULL option)
– Execute a user-specified error-correction routine
Slide 5- 31
Possible violations for each operation
• INSERT may violate any of the 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:
• if the primary key value is null in the new tuple
Slide 5- 32
Possible violations for each 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 handled by several actions: RESTRICT, CASCADE, SET NULL
(see Chapter 8 for more details)
– RESTRICT option: reject the deletion
– CASCADE option: propagate the new primary key value into the
foreign keys of the referencing tuples
– 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
Slide 5- 33
Possible violations for each 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
Slide 5- 34