0% found this document useful (0 votes)
8 views

Module 2 Dbms 1st Internal

Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

Module 2 Dbms 1st Internal

Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 34

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

You might also like