Documente Academic
Documente Profesional
Documente Cultură
2
Course Objectives
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
Oriented
DBMS
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
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
# 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
28 @
!
Normalization
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)
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.
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)
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
EMP DEPT
36 !
Relational Algebra Operators
UNION
ORD_JUL ORD_AUG
INTERSECT
DIFFERENCE
relational databases (including concepts of domain and key and the two integrity
rules)
38 !