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

Lecture 1

The document outlines the course CSC-313 Advanced Database Systems, detailing course information, textbooks, course contents, marks distribution, and policies. It covers topics such as database normalization, functional dependency, anomalies, and various normal forms. Additionally, it emphasizes the importance of avoiding cheating and plagiarism in assignments.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

Lecture 1

The document outlines the course CSC-313 Advanced Database Systems, detailing course information, textbooks, course contents, marks distribution, and policies. It covers topics such as database normalization, functional dependency, anomalies, and various normal forms. Additionally, it emphasizes the importance of avoiding cheating and plagiarism in assignments.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 24

CSC-313 Advanced Database Systems

Lecture 1
Introduction
By
Farah
Shaheen

Acknowledgement:
Department of Information Technology – The UniversityLecture slides material from
of Haripur
Stuart Russell
Course Information

 Course Title: Advanced Database Systems


 Course Code: CSC-313
 Credit Hours: 2-1
 Semester: Spring 2024
 Email: [email protected]

Department of Information Technology – The University of Haripur


6
Books
 Textbook:
Coronel, C., & Morris, S. (2016). Database systems:
design, implementation, & management (Latest ed.).
Cengage Learning.
 Reference:
• Ramakrishnan, R., & Gehrke, J. (2003). Database Management Systems
(3rd Ed.). WCB/McGraw Hill.
• Elmasri, R., & Navathe, S. B. (2016). Fundamentals of Database Systems
(Global Ed.). Pearson Education Limited.
• Hoffer, J., Venkataraman, R., & Topi, H. (2015). Modern database management (Latest
ed.). Prentice Hall Press.
• Silberschatz, A., Korth, H. F., & Sudarshan, S. (2002). Database system concepts
(4 Ed.). New York:McGraw-Hill.
• Garcia-Molina, H. (2008). Database systems: the complete book (Latest ed.).
Pearson Education India.

Department of Information Technology – The University of Haripur


Course Contents
Advanced Normalization, Multi-Valued Functional Dependency, Database Security,
Possible threats to database, Computer-Based Counter Measures, Authorization
and
Authentication. Access Controls.
Backup and Recovery, Views, Integrity Constraints, Encryption, RAID, Database
Concwrency, Transactions and Its ACID Properties, Anomalies due to concurent
execution of transaction and Concurency Control, Serializability, Lock-Based
Concwrency Control, handling Deadlocks in concwrency, Time-Stamping technique
for concurency control, Optimistic Methods, Granularity of Data Items, Database
Recovery, Transactions and Recovery, Recovery Facilities (Backup, Log File,
Check-Pointing), Recovery Protocols, Deferred Updates.
Immediate Updates, Shadow Paging, Query Optimization Techniques (Join
Ordering, Nested Query Planning, Cost Estimation), Distributed Databases, DDBMS,
Homogeneous vs. Heterogeneous DDBMS, Distribution Transparencies, Distributed
Database Design, Data allocation, Fragmentation, Object Oriented Database and
OODBMS, Comparison of OO Data Modeling vs. Conceptual Data Modeling

Department of Information Technology – The University of Haripur


Marks Distribution
 Written Exams
– Mid-term 25%
– Final-term 40%
– Quizzes 10%
 Assignments 5%
 Lab 15%
 Lab project 10%

Department of Information Technology – The University of Haripur


10
Policies
 No extensions in assignment deadlines.
 Quizzes will be unannounced.
 Never cheat.
– “Better fail NOW or else will fail somewhere LATER in life”
 Plagiarism will also have strict penalties.

A
ht

Department of Information Technology – The University of Haripur


11
Database Anomalies

Department of Information Technology – The University of Haripur


Database Anomalies
 Database anomalies are the problems in the relations
that occur due to redundancy in the relations.
 Affects: Process of inserting, deleting and updating.
 Important data may be lost.
 Need to remove the anomalies from the database.
 Types:
 Insertion: Occurs when a new record is inserted in the relation.
 Deletion: Occurs when a record is deleted from the relation.
 Modification: Occurs when a record is updated in the relation.

Department of Information Technology – The University of Haripur


14
Normalization
 The task of database design starts with unnormalized
set of relations.
 The process of producing a simpler and more reliable
database structure.
 Create a suitable set of relations for storing data.
 Different stages of normalization known as normal
forms.
 1st NF, 2nd NF, 3rd NF, 4th NF, 5th NF
 Each normal form has a certain conditions.

Department of Information Technology – The University of Haripur


15
Functional Dependency
 Functional dependency is a relationship between
attributes.
 It means that, if the value of one attribute is known, it is possible
to obtain the value of another attribute.
 Example,
 Relation: STUDENT
 STUDENT (Reg#, StudentName, Class, Email)
 If value of Reg# is known, it is possible to obtain the value of
StudentName.
 An attribute (StudentName) is functionally dependent on
attribute Reg#. Or Reg# determines the value of
StudentName
 Reg# StudentName

Department of Information Technology – The University of Haripur


16
Functional Dependency
 Generally, An attribute B is functionally dependent on attribute
A, if the value of A determines the value of B.

 If A and B are attributes or sets of attributes of relations R, B is


functionally dependent on A if each value of A in R has exactly
one associated value of B in R.

 It is possible to determine all the three fields using Reg#,


 Reg# StudentName, Class, Email

Department of Information Technology – The University of Haripur


16
1st Normal Form
 A relation is in the 1st normal form if it does not contain a
repeating group.
 Repeating Group: is a set of one or more data items that may
occur a variable number of times in a tuple.
 Every Attribute is atomic.
 Every tuple should be unique.
 Each cell in a relation should contain only one value.
Accountant Skill Skill Proficienc Accountan Accountan Group Group City Group
Number Number Category y Number t Name t Age Number Superviso
r

21 113 Systems 3 Ali 55 52 ISD Babar

35 113 Systems 5 Daud 32 44 LHR Ghafoor


179 Tax 1
204 Audit 6

50 179 Tax 2 Chohan 40 44 LHR Ghafoor

77 148 Consulting 6 Zahid 52 52 ISD Babar


179 Tax 6

Department of Information Technology – The University of Haripur


16
1st Normal Form
 Convert the relation into normal form, repeating groups should
be removed.
Primary Key

Group
Accountant Skill Skill Proficienc Accountan Accountan Group
Group City Superviso
Number Number Category y Number t Name t Age Number
r

21 113 Systems 3 Ali 55 52 ISD Babar

35 113 Systems 5 Daud 32 44 LHR Ghafoor

35 179 Tax 1 Daud 32 44 LHR Ghafoor

35 204 Audit 6 Daud 32 44 LHR Ghafoor

50 179 Tax 2 Chohan 40 44 LHR Ghafoor

77 148 Consulting 6 Zahid 52 52 ISD Babar

77 179 Tax 6 Zahid 52 52 ISD Babar

Department of Information Technology – The University of Haripur


16
Problems in 1st Normal Form
 Update Anomaly:
 Suppose the user want to change the name of Accountant Number 35 to “M. Daud”.
He has to the name in all records in which Accountant Number 35 appears. This
process of updating can be very lengthy.
 Insert Anomaly:
 Suppose the user wants to add another skull number in the table. It is not possible
until an Accountant with that skill exists because both Skill Number and Accountant
Number are used as primary key in the above table.
 Delete Anomaly:
 Suppose the user wants to delete the record of supervisor Ghafoor. If he deletes the
whole record in which Ghafoor appears, the information about Accountants will also
be lost.

Department of Information Technology – The University of Haripur


16
Full Functional Dependency
 In a relation R, attribute B of R is fully functionally dependent on an
attribute or set of attributes A of R is functionally dependent on A but not
functionally dependent on any other proper subset of A.
 Suppose there is a relation MARKS as follows:
 MARKS (Reg#, Subject, Marks)
 Assume that one student is studying many subjects. Both Reg# and
Subject are required to determine a particular marks. It can be written as:
 Reg#, Subject  Marks
 Here, marks is fully functionally dependent on both fields because it is
not functionally dependent on either Reg# or Subject alone.

Department of Information Technology – The University of Haripur


16
2nd Normal Form
 A relation is in 2nd NF, if
 1) It is in 1st NF
 2) All it`s nonkey attributes are fully functionally dependent on the whole
key. It means that none of non-key attributes are related to a part of key.
 The previous relation is in 1st NF. But some attributes which are not
depending on the whole primary key.
 Example: Accountant Name, Accountant Age and group information is
determined by Accountant Number and is no dependent in Skill Number.

Department of Information Technology – The University of Haripur


16
2nd Normal Form
 Here is the relation created from the previous relation, which all attributes
are fully dependent in primary key Accountant Number.

Primary Key

Accountant Accountant Accountant Group Group


Group City
Number Name Age Number Supervisor

21 Ali 55 52 ISD Babar

35 Daud 32 44 LHR Ghafoor

50 Chohan 40 44 LHR Ghafoor

77 Zahid 52 52 ISD Babar

Department of Information Technology – The University of Haripur


16
2nd Normal Form
 Similarly, another relation Skill  The attributes of all relations are
can be created in which all the fully dependent on the primary
fields are fully dependent on the keys.
primary key as follows:
Primary Key

Accountant
Skill Number Proficiency
Primary Key Number

21 113 3
Skill
Skill Category
Number 35 113 5

113 Systems 35 179 1

179 Tax 35 204 6

204 Audit 50 179 2

77 148 6
148 Consulting
77 179 6

Department of Information Technology – The University of Haripur


16
Transitive Dependency
 A condition in which an attribute in which an attribute is dependent on an
attribute that is not part of the primary key.
 Example: Suppose there is a relation BOOK as follows:
 BOOK(BookID, BookDescription, CategoryID, CategoryDescription)
 We can write,
 BookIDCategoryID, CategoryID CategoryDescription
 A transitive dependency occours when one non-key attribute determines
another non-key attribute.
 In the above example, BookID determines CategoryID and CategoryID
determines CategoryDescription.
 CategoryDesacription is transitively dependent on BookID attribute.
Department of Information Technology – The University of Haripur
16
3rd Normal Form
 A relation is in 3rd normal form if,
 1) It is in 2nd normal form.
 2) if no non-key attribute is dependent on another non-key attribute. It means that all non-key
attributes are functionally dependent only on primary key. (No transitive dependency in a
relation).
 The accountant table in 2 nd NF contains some attributes which are depending on non-key
attributes, for example, Group City, and Group Supervisor are depending on a non-key field
Group Number.

Department of Information Technology – The University of Haripur


16
3rd Normal Form
Primary Key

Accountant Accountant Accountant Group


Number Name Age Number

21 Ali 55 52

35 Daud 32 44

50 Chohan 40 44

77 Zahid 52 52

The second table is created from the Accountant table in 1st NF is as follows.

Primary Key

Group Group
Group City
Number Supervisor

52 ISD Babar

44 LHR Ghafoor

Department of Information Technology – The University of Haripur


16
3rd Normal Form
The skill and Proficiency tables in 2nd NF contains no attributes, which is depending on a non-key attributes.
It is already in 3rd NF.

Primary Key

Accountant
Skill Number Proficiency
Primary Key Number

21 113 3
Skill
Skill Category
Number 35 113 5

113 Systems 35 179 1

179 Tax 35 204 6

204 Audit 50 179 2

77 148 6
148 Consulting
77 179 6

Department of Information Technology – The University of Haripur


16
Boyce-codd Normal Form (BCNF)
 A relation is in BCNF if and only if every determinant is a candidate key.
 Identify all determinants and make sure that all these determinants are candidate keys.
Primary Key

ProjectID PartID QuantityUsed PartName


 Dependencies:
101 P01 20 CD-R
 (ProjectID, PartID)QtyUsed 112 P05 6 Zip Disk

 PartIDPartName 194 P01 12 CD-R

 PartNamePartID 194 P02 1


Box floppy
disks
 Assume PartName is unique 194 P05 3 Zip Disk

 Satisfies 2nd NF
 No transitive dependencies, so the relation is in 3 rd NF
 PartID and PartName are ignored by 3 rd NF rule because they are both key attributes.

Department of Information Technology – The University of Haripur


16
Boyce-Codd Normal Form (BCNF)
Primary Key

ProjectID PartID QuantityUsed

101 P01 20

112 P05 6

194 P01 12

194 P02 1

194 P05 3

Primary Key

PartID PartName

P01 CD-R

Box floppy
P02
Disks

P05 Zip disk

Department of Information Technology – The University of Haripur


16

You might also like