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

dbms notes

The document outlines a syllabus for a database management system (DBMS) course, covering topics such as DBMS definitions, keys, relational algebra, ER models, SQL, NoSQL, functional dependency, normalization, transaction management, concurrency control, and indexing. Each chapter provides detailed subtopics, including definitions, properties, and examples relevant to the study of databases. The course aims to equip students with a comprehensive understanding of both theoretical and practical aspects of DBMS.

Uploaded by

jacksharma189
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views

dbms notes

The document outlines a syllabus for a database management system (DBMS) course, covering topics such as DBMS definitions, keys, relational algebra, ER models, SQL, NoSQL, functional dependency, normalization, transaction management, concurrency control, and indexing. Each chapter provides detailed subtopics, including definitions, properties, and examples relevant to the study of databases. The course aims to equip students with a comprehensive understanding of both theoretical and practical aspects of DBMS.

Uploaded by

jacksharma189
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

Syllabus

Thursday, January 16, 2025 8:55 AM

• Chapter 1 :
○ Definition of DBMS
○ DIKW pyramid
○ Architecture of DBMS (3 Layer, Schema, Tier)
 DBMS users
 DBMS Language
 DBMS models.
• Chapter 2 : Keys
○ Super Key
○ Candidate Key
○ Primary Key
○ Secondary key
○ Alternate Key
○ Foreign Key
○ Composite Key
○ Surrogate Key
○ Partial Key
○ Unique Key
• Chapter 3 :
○ Relational Algebra :
 Basic (6)
 Advanced (4).
○ Relational Calculus : DRC and TRC
• Chapter 4 :
○ ER Models
 Entity Type
 Relational Type
 ER Model Constraints
 Cardinality Constraints
 Participation Constraints
 Attributes
 Key Constraints
 Weak entity set
 ER model conversion to Relational model
 Advanced Features
• Chapter 5 : SQL (structured query language)
○ Components of SQL :
 DDL
 DML
 TCL
 DQL
○ Operations of SQL :
○ Integrity Constraints
○ SQL Query
○ PL/SQL
○ Triggers/Cursors/Functions
• Chapter 6 : NoSQL
○ Comparison with SQL
○ Types of NoSQL
○ Architecture of NoSQL
• Chapter 7 : Functional Dependency (most important)
○ About FD
○ Properties of FD
○ DBMS anomalies
○ Lossless decomposition
○ Dependency preserving
○ Canonical Cover
○ Evaluate Keys by FD
• Chapter 8 : Normalization
○ Types of Normalization
 1NF
 2NF
 3NF
 BCNF
 4NF
 5NF
• Chapter 9 : Transaction Management
○ ACID properties
○ Serializability
○ Types of Serializability
 View
 Conflict
○ Problems in Transaction :
 Dirty Read
 Dirty Update
 Dirty Write
• Chapter 10 : Concurrency Control
○ Lock based protocol
○ Deadlock
○ Starvation
○ 2 Phase locking
○ Strict, conservative
○ Regressive
○ Time stamp ordering protocol (using tree and graph)
• Chapter 11 : Indexing
○ Indexing methods
○ Indexing types
 Single Level :
□ Dense
□ Sparse
 Multi Level Indexing
 B Tree and B+ Tree
○ Recovery Management
 Types of Recoveries
 Techniques of Recovery
□ Rollback Recovery
□ Commit (Redo)
□ Checkpoint Recovery
Chapter 1
Monday, January 20, 2025 8:59 AM

Data : anything which is real and has no meaning


Information : meaningful representation of data related to each other
after processing.

DIKW Chart :

• Collection of related data is called database


• DBMS softwares : oracle, sql server, db2, postgre, mariaDB, couchDB,
MS Access, neo4j, dynamoDB, split, MongoDB.

Types of Data :

Unstructured Structured
• Data which is not in fixed and • Data which is in fixed and
predefined structured predefined structure

Conditions for RDBMS


• Structured format (like tabular)
• Inter related
Every RDBMS is a DBMS but no vice versa

File System DBMS


Redundancy is possible Redundancy is not possible
Consistency : not provided Consistency is provided (normalization)
Security : no authentication Security : Authentication is provided
Constraints : no constraints Constraints provided
Backup and recovery is not Backup and recovery is provided
provided
Transaction management not One of the most important feature is
possible Transaction
Concurrency control is not Concurrency control is provided
possible

DBMS Architecture :
1. 3 Layer Architecture
• Level 1 : View level/external level/high level (used by end user and
developed by programmer)
• Level 2 : middle level / logical level/ conceptual level (handled by DB
Team or DBA)
• Level 3 : internal level/ lower level/ physical level (DB Design)
• Secondary storage (where database is saved)

• Every layer is bidirectional


• Property of this model : Data Independence : If there are any changes
made in software/hardware at any level, data should not be affected
in any manner
i. Logical Data independence (changes made in the structure of
database like in constraints, indexes, keys etc.)
ii. Physical Data independence (like in hard drive)

2. Schema (HW)
• Logical architecture at each level is called Schema
• Schema architecture is the logical design of each level

3. Tier Architecture :
• There are only 2 types of architecture, tier 3 is just and upgrade of
tier 2
• Tier 1 : when the user is directly connected to the DBMS

• Tier 2 : when the user is connected to the application and then it is


connected to DBMS (called client-server architecture)
○ Drawbacks :
 Can't be used in large scale due to less throughput and high
time consumption

• Tier 3 :
Types of DBMS Users
1. Naïve / Native / End User
a. Intended only for one user
2. Application Programmer user
a. Working on frontend
3. Sophisticated user
a. Working on the backend of the application
4. Specialized user
a. Working on a specific branch of the application
5. DB Developer
a. Team that constructs the DB
6. DBA (Database Admin)
a. To manage / to create / to provide support is the
responsibility of DBA
b. Roles and responsibilities of DBA :
i. To manage Database
ii. To secure the database
iii. Secondary storage access/ define the storage rules
iv. Administrative work with the concern of its team
v. Daily basis maintenance related with the DBMS
1) Regularly check the security
2) Backup
3) Check the definitions of storage
7. Casual User
a. Uses irregularly / not quite often
8. Regular User

9. Online User
a. Works on a live compiler (on the web)
10. Offline User
a. Works on an installed version
DBMS Language
• To create, manipulate, control, the database and its activities
• Components :
i. DDL (Data definition language)
• It is used to design the structure of DBMS (tables)
• Commands of DDL :
1. CREATE : creates the structure of table
2. DROP : drop the table permanently and it cannot be rolled
back
3. TRUNCATE : permanently deletes the data of the table
4. ALTER : used to modify table name, column name, add the
column, delete the column and define the definition of the
data or change the definition of the data.
5. RENAME : change the name of the table
6. COMMENT : adds comment
ii. DML (Data Manipulation language)
• It is used to manipulate the query of DBMS
• Commands of DML (all can be rolled back) :
1. SELECT : is used to select the column or row or complete
table
2. INSERT : to insert the data into the table (single or multiple)
3. DELETE : to delete the data from table (single or multiple)
4. UPDATE : update the data into table
5. CALL : to call PL/SQL or java commands
6. LOCK : to control the concurrency of table
7. EXPLAIN PLAN : to identify or recognize or create the path.
iii. DCL (Data Control language)
iv. TCL (Transaction Control language)
• Used to control the transaction of dbms
• Commands of TCL (can be rolled back unless committed)
1. COMMIT :
2. ABORT
3. ROLLBACK
v. DQL (Data Query Language)
Chapter 2 (Keys)
Monday, February 3, 2025 8:59 AM

DBMS Keys
Sid Sno Fullname Age
1 1

# Primary Key
• Derived from candidate key
• Unique + Not Null
• There is a single primary key always

# Composite Key
• Composition of more than one keys

# Alternate/Secondary Key
• All keys in candidate keys after removing all primary keys
are alternate keys

# Unique Key
• Unique + Null

# Surrogate Key

# Foreign Key
• Primary key of a table(reference table) used as a unique
identifier for another table(referencing table) is called
foreign key
• Referential integrity (imp)
○ Referential Integrity in Reference table
 INSERT : may or may not be violated
 DELETE : may or may not be violated (if deleted,
then its called cascading delete)
 UPDATE : may or may not be violated (if updated,
then its called cascading updated)
○ Referential Integrity in Referencing table
 INSERT : may or may not be violated (if violated, its
called cascading insert)
 DELETE : may or may not be violated
 UPDATE : may or may not be violated (if updated,
then its called cascading updated)
ER Models
Tuesday, February 4, 2025 10:32 AM

• In 1970 by Peter Chenn


• Design at logical /conceptual level of DBMS Architecture
• ER model is use to design the DBMS with the help of graphical
symbols
• Components :
1. Entity : It is a real world object which logically or physically exists
(tuple in a record is an entity)
2. Entity Set : collection of entities (record itself as a collection of
tuples)
• Types of Entity Sets :
1. Strong entity set : primary key exists in this set
(represented by rectangle by default). It is also called
owner entity set or identifying entity set.
2. Weak entity set : no primary key exists (represented by
double rectangles). It is also called dependent entity set. It
does not exist without strong entity set.
3. Relationship set : association/relation of an entity of an entity set
with an entity of another entity set is called relationship set. It is
represented by a diamond.
• Types of relationship set
1. Strong relationship set : represented by single diamond
2. Weak relationship set : represented by double diamond
4. Relationship constraints / characteristics / rules / conditions
1. Uniqueness : two entities can only have a unique relation
which no other entity can have.
2. Relationship type / degree (3 types and 5 degrees):
a) Types
i) One to one (1:1)
ii) One to many (or many to one) (1:N, N:1)
iii) Many to many (N:N)
b) Degrees
i) Unary : self related (degree 1)
ii) Binary : 2 entities related (degree 2)
iii) Tertiary : one entity related to 2 entities with the
same relation (degree 3)
iv) Quaternary
v) N-ary
3. Key constraints

# Converting ER Diagrams to table


Rules
1. if a relation in one to one, then relationship set table
will not be formed, entity set table will be formed (with
primary key of any one added to another)
2. If a relation is one to many or many to one, then
relationship set table will not be formed (primary key of
the entity with 1 as entity to relation will be added to
the entity with many as relation to many, vice versa for
many to one)
3. If a relation is many to many, then relationship table
will be formed.
4. If an entity set has multi valued attributes, then
multivalued attribute table will be formed separately
(with primary key of the entity set)
5. Descriptive attribute in relationship set when many to
many relation exists will be added to a table with the
primary keys of both the entity sets

# Participation
1. Total participation :

# Weak Entity set


• Represented by double rectangle
Rules
1. Strong to relation will be partial participation
2. Relation to weak will be total participation
3. In Weak entity set, there is one attribute that behaves
like the primary key but it is not the primary key (its
called discriminator attribute, represented by dashed
underline)
4. Weak entity set primary key = strong entity primary key
+ discriminator

# Features of ER Model :
1. Specialization
2. Generalization
3. Attribute Inheritance
4. Aggregation
Chapter 7 : Functional Dependency
Tuesday, February 11, 2025 10:43 AM

Functional dependency is a set of rules which specify the


relationship between the set of attributes or attributes

If t1X => t2X


then t1Y = t2Y

FD has 4 types :
1. Trivial
• If an attribute determines itself
• Eg: if x -> y then y -> x
• Trivial FD always show reflexive properties
• Trivial FD is always a valid FD
2. Non Trivial :
• If x determines y then X ∩ Y = ɸ
• It never shows reflexive properties
• Maybe valid or invalid
3. Multivalued
4. Transitive

# Armstrong's Axiom / Inference Rule / Properties of FD


(3 Primary, 4 secondary)
1. Reflexive property : X -> X, where X
2. Transitive property :

# Attribute Closure
• Why : to find out the candidate key in relational table in
FD3
• If from an attribute, value of set of attributes can be
determined.
• Representation : X+

# (imp) Prime attribute : in a relation, the attributes which a


candidate key recognizes are called prime attributes, other than
them, all are non-prime attributes

# Canonical Cover / Minimal Cover / Irreducible set


• Use splitting / decomposition property
• Remove extraneous attribute
• Remove redundancy
Chapter 8 : Normalization
Tuesday, February 11, 2025 11:05 AM

Normalization is a process to remove/reduce redundancy in


RDBMS

Redundancy causes :
1. Functional Dependency
• 3 types of Anomalies
 INSERT anomaly :
 DELETE anomaly :
 UPDATE anomaly :
2. Multivalued Attributes :
• Representation : A -> -> B
• Conditions
1. if Xt1 = Xt3, then Xt3 = Xt4
2. If t1Y = t3Y, then t2Y= t4Y
3. If Zt1 = Zt4, then Zt2 = Zt3
Z Y Z
2 a h
 2 b q
2 a q
2 b h

Note : Multivalued attributes are not allowed in RDBMS

To remove normalization we use 2 methods :


a. Dependency preserving
b. Lossless decomposition :
• If an FD exists, then we can break it in FD1, FD2,
FD3, if U(FD1 = FD2 = FD3) = null set
Removal of Redundancy :
1. Lossless decomposition
2. Dependency preserving

Normalization tells us the attribute location after


decomposing it from a table.

If a table goes up to 3NF then its redundancy is very less or it


is the best RDBMS

Forms of Normalization :
 1NF
 2NF
 3NF
 BCNF (3.5 NF)
 4NF
 5NF

# 1NF (first normal form)


• Every attribute should be atomic
• Every domain of the attribute in the table should be
atomic
• All relational tables are by default 1NF
• The attribute that creates problem, then remove it and
move it to another table (decomposed)

# 2NF
• It must be in 1NF
• All FDs should be fully functional
• No partial FDs
• Fully FD conditions :

You might also like