RDBMS Concepts

© Tata Consultancy Services ltd. July 7, 2018 1

 Course Prerequisites
 A basic understanding of SQL in Oracle
 Understanding of a procedural language

2
 Course Objectives

 To provide an overview of the basic RDBMS Concepts

 To provide an insight into the architecture and components

of a Database System.

3
 Session Outline

 RDBMS : Description
 Evolution of the Database Model
 Entity Relationship Model
 Integrity Rules
 Normalization
 Integrity Rules
 ER Diagrams
 ER Model
 Relational Algebra Operators
 Relational Database

4
 RDBMS Concepts
 Evolution of the database model
 Approaches to Data Management
 File Based Systems
 DBMS
 The Entity Relationship Model
 Normalization
 Relational Algebra
 Codd ’s Rules
 ORDBMS

5 !
 Needs of Computerized Systems

Management of

 Data
 that needs to be stored
 Business functions
 that need to be performed

6 !
 Evolution of the Database Model
Files based system

Hierarchical DBMS

Network DBMS

Relational DBMS
Distributed DBMS

Object Relational DBMS

Object
Oriented
DBMS

1970 1975 1980 1985 1990 1995 2000

7 !
 File-Based Systems
Drawbacks:
 Data redundancy and inconsistency
 Poor handling of unanticipated queries
 Concurrent access anomalies
 Security problems
 Integrity problems
 Application dependent on
 Storage structure of data
 Access strategy of data

8 @
!
 File-Based Systems

Checking Checking
A/c A/c
Application Data file(s)

Savings Savings
A/c A/c
Application Data file(s)

Loan Loan
Installment Installment
Application Data file(s)

9 !
 Database Management Systems
A database is a collection of stored
Checking operational data used by application
A/c
systems of a particular enterprise
Application

Savings Database
A/c Management (All Data)
Application System(DBMS) Data Base

- Integrated
Loan
Installment - Shared
Application
Any New
Application

10 @
!
 Database Management Systems
Functions:
 Data Definition
 Data Manipulation
 Planned
 Unplanned
 Data Security & Integrity
 Data Recovery & Concurrency
 Data Dictionary Maintenance
 Performance

11 !
 Database Management Systems
3-Level DBMS Architecture
User/ External
What the user sees
[ TABLES, VIEWS … ]

Conceptual/ Logical
What data and How it is organized logically
[ TABLE SPACE, SEGMENTS ]

Physical/ Internal
How the data is stored
[ DATA FILES ]

12 !
 Database Management Systems
Advantages:
 Minimal Data Redundancy
 Data Consistency
 Data Integration
 Data Sharing
 Enforcement of Standards
 Application Development Ease
 Better Controls
 Data Independence

13 !
 The Entity Relationship Model
The Entity-Relationship data model is based on a perception of the real world
which consists of basic objects called entities and relationships among these
objects.

14 @
!
 The Entity Relationship Model

 Entity
 Attribute
 Domain
 Relation
 Cardinality
 Key
 Constraint

15 !
 ER Model: Entity
Entity:
 Is an object that exists, and is distinguishable from other objects, and about
which data needs to be stored in the system
 Maybe concrete (person, book) or abstract (holiday, concept)
Hint: Identified by nouns
 Entity Set is a set of entities of the same type
eg: A set of all persons who are allowed to issue books at the library can be
defined as entity set Member.

16 !
 ER Model: Attribute and Domain
Attribute: (Characteristics)
 Is a feature which qualifies an entity, and about which data needs to be
stored
 Maybe concrete (name, identity number) or abstract (status)
eg: A Member has a Member ID, Name, Address
A Book has a Book ID, Name, Author
Domain: (Data Type + Format + Validation)
 Each attribute has a set of permitted values, called the domain of that
attribute
eg: Status can have any one of these values at a time:
Issued, Available, Lost

17 !
 ER Model: Relationship
Relationship:
 Is an association among several entities, and about which data needs to
be stored
eg: A Member requests books from the library
Hint: Identified by Verbs

 A relationship set is a set of relationships of the same type

 May have descriptive attributes

18 !
 ER Model: Relationship
Cardinality:
 Expresses the number of instances of the entity to which another entity can be
associated via a relation.
 Types:
 One to One
 A copy of a Book can be issued by only one Member at a time

 One to Many
 A Member can issue many Books

 Many to Many
 An author can write many books, and a book can be written by many
authors

19 !
 ER Model: Key
Key:
A key is an attribute or set of attributes of an entity which can be used to
identify it.
 Super Key
is a set of one or more attributes which, taken collectively, allows an
entity to be uniquely identified in an entity set
 Candidate Key
is a super key for which no proper subset is a super key (i.e., a minimal
super key)
 Primary Key
is a candidate key chosen by the database designer as the principle
means of identifying entities within an entity set

20 !
 ER Model: Key
Key:
Alternate Key
is a candidate key that is not a primary key
Foreign Key
is an attribute or set of attributes that exist in one entity and
reference similar attribute(s) in another entity wherein they serve as
a primary key

21 !
 ER Model: Constraints
Constraints:
Key Constraints:
These are constraints implied by the existence of candidate keys. The table
definition includes a specification implying uniqueness of the attributes
constituting the primary key or alternate keys. A primary key constraint also
implies a no-nulls constraint.
Referential Constraints:
Constraints implied by the existence of foreign keys in the table definition.
Other Constraints:
Constraints enforcing checks of business logic of the application in the table
definition.

22 !
 ER Model: Example
ER Diagram for:
Cheques are issued from Customer Account

Cust Account Cheques

# Customer # Chq No
Has/ Issued from
No. * Cust No.
# Account Type * Amount
# Account No. * Date
* Date opened * Amount
* Balance * To name
0 Last Activity Legend: 0 Comments
Optional # primary key
Mandatory
* mandatory
Only one
Many 0 optional

23 @
!
 ER Model: Example
 Entity - Cust Account
 Attribute - Account No, Date Opened ...
 Domain - Date Opened should be valid date
 Relation - Cheques are “issued from” Cust account.
 Cardinality - Many cheques can be written from the same account
 Key - Cheque No. is a Primary Key
 Constraint - Amount should be not NULL

24 !
 Reducing ER diagrams to Tables
 The database should conform to the E-R diagram
 Each entity should have a table
 Each table will have as many columns as the number of attributes of the
entity (which are unique in the table)
 Attributes should conform to their domain characteristics
 Constraints on attributes can be represented as check constraints, not null
or unique constraints
 Relationships between entities on should be represented as referential key
constraints or tables

25 @
!
 Reducing ER diagrams to Tables
Tuple:
A row in a table is referred to as a tuple (rhymes with ‘couple’)
Example: An instance of a Book - (1, ‘Backup and Recovery’, ‘Rama
Velpuri’)

Properties of Relationships:
 No duplicate tuples
 Tuples are unordered
 Attributes are unordered
 Attribute values are atomic (cannot be decomposed)

26 !
 Integrity Rules
Integrity Rules:
 No component of the Primary Key can be null
 The database must not contain any unmatched foreign key values
 Issues to consider at design time:
 Can the foreign key accept nulls
 What to do in case of deletes/updates of parent
 restrict
 cascade
 nullify

27 @
!
 Normalization
Normalization: A relation is said to be in normal form if it satisfies a
set of constraints

Universe of relations (normalized and unnormalized)

1NF relations (normalized relations)
2NF relations
3NF relations
BCNF (Boyce Codd) relations
4NF relations
PJ/ NF (5NF Projection Join) relations

28 @
!
 Normalization

 FIRST Normal form (1NF)

 if it contains atomic values only

 SECOND Normal form (2NF)

 if it is in 1NF and every non-key attribute is dependent on the primary
key

 THIRD Normal form (3NF)

 if it is in 2NF and every non-key attribute is non-transitively
dependent on the primary key

29 @
!
 Normalization
 Functional Dependency
 Unique value of one attribute can always be determined if we know the
value of another.
Independent variable (X), dependent variable (Y)
invoice number (X) --> Order date (Y)

 Total Dependency
 When both the variables are dependent on each other
 Employee number (X) <--> Driving license number (Y)

30 !
 Normalization

 Full Dependency
 When one attribute is always dependent on at least two other attributes
 Invoice Number (X) Part number (Y)
 Order Quantity (Z)

 Transitive Dependency
 If Y depends on X and X depends on Y
 Invoice (X) --> Customer Number (Y) --> Customer Name (Z)

 Course (X) --> Department (Y) --> College (Z)



31 !
 Normalization
ABC Company INVOICE
Invoice Number: 4001
Date: 22/5/98
Customer ID: C0051
Name: Mr. Babu Dave
Address: B-10, Sada society, Borivali (W), Mumbai - 400 092.

Sr. Part Name Qty Unit Qty

No. No. Price Price
------------------------------------------------------------------------
1. U90 U-pin box 3 10 30
2. E12 Big eraser box 2 30 60
------------------------------------------------------------------------
TOTAL: 90

Terms and conditions: TC035

Sales person: S04

(NOTE: See the appendix #@)

32 !
 Relational Algebra Operators
SELECT

PROJECT

PRODUCT

DIVIDE

JOIN

UNION

INTERSECT

DIFFERENCE

33 !
Relational Algebra Operators
SELECT employees with department number 10

dept#=10(DEPT)

PROJECT name and salary from employee

name, salary(EMP)

34 !
 Relational Algebra Operators
a x a x PRODUCT of employee with department
X =
b y a y
z a z
b x EMP X DEPT
b y
b z

a x DIVIDE
x =
a y  a
Orders containing item numbers X and Z
z
a z
b x
b y ord#, Item#(ORD_ITEMS)

Item#(item#=‘X’ or ‘Z’(ITEMS))
35 !
 Relational Algebra Operators

a1 b1 b1 c1 = a1 b1 c1
a2 b2 b2 c2 a2 b2 c2

JOIN of employee with department

EMP DEPT

36 !
Relational Algebra Operators
UNION
ORD_JUL  ORD_AUG

INTERSECT

cust# (ORD_JUL)  cust#(ORD_AUG)

DIFFERENCE

cust# (ORD_JUL) - cust#(ORD_AUG)

37 !
 Relational Database
A database system may be defined as fully relational
if it supports

 relational databases (including concepts of domain and key and the two integrity
rules)

 a language that is at least as powerful as relational algebra

38 !