Sie sind auf Seite 1von 22

SQL Training

RDBMS Concepts

21 April 2019
Disclaimer

© All rights reserved. Attra Infotech Pvt. Ltd 2010


No part of this document may be reproduced, stored in a retrieval system or transmitted in any form
or by any means, electronic, mechanical, recording, photocopying or otherwise without the prior
permission of Attra.
The contents of this document are provided to the customer in commercial confidence solely for the
purpose of evaluating whether a relationship should be considered or the contract should be awarded
to Attra.
All trade marks and logos in this presentation are the properties of the respective owners.

For inquiries regarding this document please contact:


Prasad Guntupalli
ATTRA Infotech Pvt. Ltd
AMR Tech Park II, No. 23 & 24, 2nd Floor
Hongasandra, Hosur Main Road
Bangalore – 560068, India
Tel: +91 80 4197 0900
Fax: +91 80 4197 0901
Email: prasad.guntupalli@attra.com.au

2
Agenda
This PPT will provide an overview of following:
Relational Database Management System (RDBMS)
RDBMS Concepts
Data Model Overview
Relational Database Management System
(RDBMS)
A database is a collection of Data. Examples of databases, which we use in
our daily life, is an Attendance Register, Telephone Directory, Email Contacts,
etc...

Database Management System(DBMS): A database management system


is a collection of programs written to manage a database. That is, it acts as a
interface between user and database.

Relational Database Management System(DBMS): A DBMS that is based


on relational model is called as RDBMS.
Consists of a number of tables and single schema (definition of tables and
attributes)
Students (sid, name, login, age, gpa)
Students identifies the table
sid, name, login, age, gpa identify attributes
sid is primary key

4
Example of a Table
Table Name: Students
Columns:
sid (string); name (string); login (string); age (integer); gpa (real)

sid name login age gpa


50000 Dave dave@cs 19 3.3
53666 Jones jones@cs 18 3.4
53688 Smith smith@ee 18 3.2
53650 Smith smith@math 19 3.8
53831 Madayan madayan@music 11 1.8
53832 Guldu guldu@music 12 2.0

5
RDBMS Concepts

Data Models

Keys and Identifiers

Integrity and Consistency

Normalization
Data Model

A data model consists of notations for expressing:

data structures

integrity constraints

operations
Data Model - Data Structures

All data models have notation for defining:


attribute types
entity types
relationship types
FLIGHT-SCHEDULE DEPT-AIRPORT

FLIGHT# AIRLINE WEEKDAY PRICE FLIGHT# AIRPORT-CODE

101 delta mo 156 101 atl

545 american we 110 912 cph

912 scandinavian fr 450 545 lax

242 usair mo 231


Data Model - Constraints
Constraints express rules that cannot be expressed by the data
structures alone:
Static constraints apply to database state
Dynamic constraints apply to change of database state
E.g., “All FLIGHT-SCHEDULE entities must have precisely one DEPT-
AIRPORT relationship

FLIGHT-SCHEDULE DEPT-AIRPORT

FLIGHT# AIRLINE WEEKDAY PRICE FLIGHT# AIRPORT-CODE

101 delta mo 156 101 atl


545 american we 110 912 cph
912 scandinavian fr 450 545 lax
242 usair mo 231 242 bos
Data Model - Operations

Operations support change and retrieval of data:


insert FLIGHT-SCHEDULE(97, delta, tu, 258);
insert DEPT-AIRPORT(97, atl);
select FLIGHT#, WEEKDAY from FLIGHT-SCHEDULE where
AIRLINE=‘delta’;

FLIGHT-SCHEDULE DEPT-AIRPORT

FLIGHT# AIRLINE WEEKDAY PRICE FLIGHT# AIRPORT-CODE

101 delta mo 156 101 atl

545 american we 110 912 cph

912 scandinavian fr 450 545 lax

242 usair mo 231 242 bos

97 delta tu 258 97 atl


Keys and Identifiers

Keys (or identifiers) are uniqueness constraints


A key on FLIGHT# in FLIGHT-SCHEDULE will force all FLIGHT#’s to be
unique in FLIGHT-SCHEDULE
Consider the following keys on DEPT-AIRPORT:

FLIGHT# AIRPORT-CODE FLIGHT# AIRPORT-CODE FLIGHT# AIRPORT-CODE FLIGHT# AIRPORT-CODE

FLIGHT-SCHEDULE DEPT-AIRPORT

FLIGHT# AIRLINE WEEKDAY PRICE FLIGHT# AIRPORT-CODE

101 delta mo 156 101 atl

545 american we 110 912 cph

912 scandinavian fr 450 545 lax

242 usair mo 231 242 bos


Integrity and Consistency

Integrity: does the model reflect reality well?


Consistency: is the model without internal conflicts?

a FLIGHT# in FLIGHT-SCHEDULE cannot be null because it models the


existence of an entity in the real world
a FLIGHT# in DEPT-AIRPORT must exist in FLIGHT-SCHEDULE because
it doesn’t make sense for a non-existing FLIGHT-SCHEDULE entity to
have a DEPT-AIRPORT
FLIGHT-SCHEDULE DEPT-AIRPORT

FLIGHT# AIRLINE WEEKDAY PRICE FLIGHT# AIRPORT-CODE

101 delta mo 156 101 atl


545 american we 110 912 cph
912 scandinavian fr 450 545 lax
242 usair mo 231 242 bos
Normalization

 Normalization - process of removing data redundancy by

decomposing relations in a Database.

 De normalization - carefully introduced redundancy to

improve query performance.

 The decomposition approach starts with one relation and

the relation is decomposed into more number of


relations to remove insert, delete and update anomalies.

 1NF, 2NF, 3NF and BCNF can be achieved by this

approach.
Un normalized Form

A relation is said to be in Un normalized Form (0NF) if


the values of any of its attributes (fields) are non-atomic.
In other words more than one value is associated with
each instance of the attribute.

S# PQ
P# QTY

S1 P1 300
P2 200
P3 400
P4 200

S2 P1 300
P2 400

S3 P2 200
First Normal Form

A Relation is said to be in First Normal Form (1 NF) if the values of each


attribute of the relation are atomic. In other words, only one value is
associated with each attribute and the value is not a set or a list of values.

Functional Dependency
Given a relation R, attribute Y of R is functionally dependent on attribute X if
and only if each X-value in R has associated with it precisely one Y-value in
R (at any one time)

Full Functional Dependency


Attribute Y is fully functionally dependent on attribute X if it is functionally
dependent on X And Functionally dependent on any proper subset of X
Second Normal Form

A relation R is in Second Normal Form (2 NF) if it is in the 1NF and every


non key attribute is full functionally dependent on the primary key.

Third Normal Form


A relation R is in Third Normal Form (3 NF) if and only if it is in the 2NF and
every non-key attribute is non-transitively dependent on the primary key.

Boyce Codd Normal Form


A relation R is in Boyce/Codd Normal Form (BCNF) if and only if every
determinant is a candidate key.

An attribute, possibly composite, on which some other attribute is fully


functionally dependent is a determinant
Normalization
FLIGHT-SCHEDULE unnormalized FLIGHT-WEEKDAY

FLIGHT# AIRLINE WEEKDAYS PRICE FLIGHT# WEEKDAY

101 mo
101 delta mo,fr 156
545 mo
545 american mo,we,fr 110
912 fr
912 scandinavian fr 450
101 fr

FLIGHT-SCHEDULE redundant 545 we

FLIGHT# AIRLINE WEEKDAY PRICE 545 fr

101 delta mo 156


FLIGHT-SCHEDULE just right!
545 american mo 110
FLIGHT# AIRLINE PRICE
912 scandinavian fr 450
101 delta 156
101 delta fr 156
545 american 110
545 american we 110
912 scandinavian 450
545 american fr 110
Data Model Overview

Entity-Relationship (ER)-Model
Hierarchical Model
Network Model
Relational Model
ER-Model - Data Structures

entity type

relationship composite
type attribute

attribute

multi-valued subset
attribute relationship
type

derived
attribute
ER-Model - Integrity Constraints

E1 1 n A
R E2

cardinality: 1:n for E1:E2 in R key attribute

(min,max)
E1 E
R E2

(min,max) participation of E2 in R

E1 E2 E3
E1 R E2 disjoint
d
total participation of E2 in R x exclusion

p partition
E1 R E2

weak entity type E2; identifying relationship type R


ER Model - Example
visa
required

dept domestic international


time flight flight

airport airport
name code dept
1 airport n p weekdays

airport airport flight


add schedule
1 arrival n
airport 1
zip flight#
city
arrival
time
street instance
of

customer# date
n

n n flight
customer reserva-
name customer tion instance

seat#
Thank You