19381895 rdbms concepts

8/9/2019 19381895 RDBMS Concepts

http://slidepdf.com/reader/full/19381895-rdbms-concepts 1/38

© Tata Consultancy Services ltd. September 3, 2009 1

RDBMS Concepts



2

Course Prerequisites

A basic understanding of SQL in Oracle

Understanding of a procedural language



3

To provide an overview of the basic RDBMS Concepts

To provide an insight into the architecture andcomponents

of a Database System.

Course Objectives



4

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



5

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

!



6

Needs of Computerized Systems

Management of

Data

that needs to be stored

Business functions

that need to be performed

!



Evolution of the Database Model

Files based system

1970 1985 1990 19951975 1980 2000

Hierarchical DBMS

Network DBMS

Relational DBMS

Distributed DBMS

Object

Oriented

DBMS

Object Relational DBMS

!



File-Based SystemsDrawbacks:

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

!



File-Based Systems

CheckingA/c

Application

CheckingA/c

Data file(s)

Loan

Installment

Application

Loan

Installment

Data file(s)

Savings

A/c

Application

SavingsA/c

Data file(s)

!



CheckingA/cApplication

(All Data)Data Base

SavingsA/c

Application

LoanInstallmentApplication

Database

Management

System(DBMS)

Any NewApplication

- Integrated

- Shared

Database Management SystemsA database is a collection of

storedoperational data used by

application

systems of a particular enterprise

!



Database Management SystemsFunctions:

Data Definition Data Manipulation

Planned

Unplanned

Data Security & Integrity

Data Recovery & Concurrency

Data Dictionary Maintenance

Performance

!



Database Management Systems

Physical/ Internal

How the data is stored

[ DATA FILES ]

Conceptual/ Logical

What data and How it is organized logically

[ TABLE SPACE, SEGMENTS ]

User/ External

What the user sees

[ TABLES, VIEWS … ]

3-Level DBMS Architecture

!



Database Management SystemsAdvantages:

Minimal Data Redundancy

Data Consistency

Data Integration

Data Sharing Enforcement of Standards

Application Development Ease

Better Controls

Data Independence

!




The Entity-Relationship data model is based on aperception of the real world which consists of basicobjects called entities and relationships among theseobjects.

!




Entity

Attribute

Domain

Relation

Cardinality

Key

Constraint

!



ER Model: EntityEntity:

Is an object that exists, and is distinguishable from otherobjects, 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.

!



ER Model: Attribute and DomainAttribute: (Characteristics)

Is a feature which qualifies an entity, and about whichdata 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

!



ER Model: RelationshipRelationship:

Is an association among several entities, and aboutwhich 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 thesame type

May have descriptive attributes

!



ER Model: RelationshipCardinality:

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

!



ER Model: KeyKey:

A key is an attribute or set of attributes of an entitywhich can be used to identify it.

Super Key

is a set of one or more attributes which, takencollectively, allows an entity to be uniquelyidentified in an entity set

Candidate Key

is a super key for which no proper subset is a superkey (i.e., a minimal super key)

Primary Key

is a candidate key chosen by the database designeras the principle means of identifying entities within

an entity set!



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) inanother entity wherein they serve as a primarykey

!



ER Model: ConstraintsConstraints:

Key Constraints: These are constraints implied by the existence of candidate keys. The table definition includes aspecification implying uniqueness of the attributesconstituting the primary key or alternate keys. Aprimary key constraint also implies a no-nulls constraint.

Referential Constraints:

Constraints implied by the existence of foreign keys inthe table definition.

Other Constraints:

Constraints enforcing checks of business logic of theapplication in the table definition.

!

ER Model: Example



ER Model: Example

Cheques

# Chq No

* Cust No.

* Amount

* Date* Amount

* To name

0 Comments

# primary key

* mandatory

0 optional

Optional

Mandatory

Only one

Many

Cust Account

# Customer

No.

# Account Type

# Account No.

* Date opened

* Balance

0 Last Activity

Has/ Issued from

Legend:

ER Diagram for:

Cheques are issued from Customer Account

!



24

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 thesame account

Key - Cheque No. is a Primary Key

Constraint - Amount should be not NULL

!

Reducing ER diagrams to Tables



25


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 thetable)

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

!

R d i ER di T bl



26


Tuple:

A row in a table is referred to as a tuple (rhymes with‘couple’)

Example: An instance of a Book - (1, ‘Backup andRecovery’, ‘Rama Velpuri’)

Properties of Relationships:

No duplicate tuples

Tuples are unordered

Attributes are unordered

Attribute values are atomic (cannot be decomposed)

!



N li ti



28

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

!

N li ti



29

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

!



30

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 eachother

Employee number (X) <--> Driving licensenumber (Y)

!



31

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)

!



32

NormalizationInvoice 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

ABC Company INVOICE

(NOTE: See the appendix #@)

!

R l ti l Al b O t



33

Relational Algebra Operators

SELECT

PROJECT

PRODUCT

DIVIDE

JOIN

UNION

INTERSECTDIFFERENCE

!



34


SELECT employees with department number 10

PROJECT name and salary from employee

σdept#=10(DEPT)

Πname, salary(EMP)

!



35


PRODUCT of employee with departmenta

b

x

yz

a

aabb

b

X =

x

yzxy

z

EMP X DEPT

DIVIDE Orders containing item numbers X and Z

xz

aa

abb

xy

zxy

÷ a=

Πord#, Item#(ORD_ITEMS)÷

ΠItem#(σitem#=‘X’ or ‘Z’(ITEMS))

!



36


a1a2

b1b2

c1c2

b1b2

a1a2

b1b2

c1c2

JOIN of employee with department

EMP DEPT

=

!



37


Πcust# (ORD_JUL)∩ Πcust#(ORD_AUG)

INTERSECT

Πcust# (ORD_JUL) - Πcust#(ORD_AUG)

DIFFERENCE

UNION

ORD_JUL ∪ ORD_AUG

!



Relational DatabaseA database system may be defined as fully relational

if it supports

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

a language that is at least as powerful as relational algebra

19381895 rdbms concepts

Documents