3. FUNCTIONAL DEPENDENCIES
• What is Functional Dependency
• Functional dependency in DBMS, as the name suggests is a relationship between
attributes of a table dependent on each other. Introduced by E. F. Codd, it helps in
preventing data redundancy and gets to know about bad designs.
• To understand the concept thoroughly, let us consider P is a relation with attributes
A and B. Functional Dependency is represented by -> (arrow sign)
• Then the following will represent the functional dependency between attributes with
an arrow sign −
• A->B
5. EXAMPLE
• The following is an example that would make it easier to understand functional
dependency −
• We have a <Department> table with two attributes − DeptId and DeptName.
• DeptId = Department ID
DeptName = Department Name
• The DeptId is our primary key. Here, DeptId uniquely identifies
the DeptName attribute. This is because if you want to know the department
name, then at first you need to have the DeptId.
7. CONT….
• Therefore, the above functional dependency between DeptId and DeptName can
be determined as DeptId is functionally dependent on DeptName.
• DeptId -> DeptName
8. FIRST TO BCNF NORMAL FORM
• If a relation contain composite or multi-valued attribute, it violates first normal form
or a relation is in first normal form if it does not contain any composite or multi-
valued attribute.
• A relation is in first normal form if every attribute in that relation is singled valued
attribute.
• Example 1 – Relation STUDENT in table 1 is not in 1NF because of multi-valued
attribute STUD_PHONE. Its decomposition into 1NF has been shown in table 2.
10. SECOND NORMAL FORM –
• To be in second normal form, a relation must be in first normal form and relation
must not contain any partial dependency. A relation is in 2NF if it has No Partial
Dependency, i.e., no non-prime attribute (attributes which are not part of any
candidate key) is dependent on any proper subset of any candidate key of the
table.
• Partial Dependency – If the proper subset of candidate key determines non-prime
attribute, it is called partial dependency.
• Example 1 – Consider table-3 as following below.
12. CONT….
• Example 2 – Consider following functional dependencies in relation R (A, B , C, D )
• AB -> C [A and B together determine C]
• BC -> D [B and C together determine D]
• In the above relation, AB is the only candidate key and there is no partial
dependency, i.e., any proper subset of AB doesn’t determine any non-prime
attribute.
13. THIRD NORMAL FORM –
• A relation is in third normal form, if there is no transitive dependency for non-prime
attributes as well as it is in second normal form.
A relation is in 3NF if at least one of the following condition holds in every non-trivial
function dependency X –> Y
• X is a super key.
• Y is a prime attribute (each element of Y is part of some candidate key).
• Example 2 – Consider relation R(A, B, C, D, E)
A -> BC,
CD -> E,
B -> D,
E -> A
All possible candidate keys in above relation are {A, E, CD, BC} All attribute are on right
sides of all functional dependencies are prime.
14. BOYCE-CODD NORMAL FORM
(BCNF) –
• A relation R is in BCNF if R is in Third Normal Form and for every FD, LHS is super
key.
• A relation is in BCNF iff in every non-trivial functional dependency X –> Y, X is a
super key.
• Example 2 –For example consider relation R(A, B, C)
A -> BC,
B ->
A and B both are super keys so above relation is in BCNF.
• Key Points –
• BCNF is free from redundancy.
• If a relation is in BCNF, then 3NF is also also satisfied.
15. CONT….
• If all attributes of relation are prime attribute, then the relation is always in 3NF.
• A relation in a Relational Database is always and at least in 1NF form.
• Every Binary Relation ( a Relation with only 2 attributes ) is always in BCNF.
• If a Relation has only singleton candidate keys( i.e. every candidate key consists of only 1
attribute), then the Relation is always in 2NF( because no Partial functional dependency
possible).
• Sometimes going for BCNF form may not preserve functional dependency. In that case go
for BCNF only if the lost FD(s) is not required, else normalize till 3NF only.
• There are many more Normal forms that exist after BCNF, like 4NF and more. But in real
world database systems it’s generally not required to go beyond BCNF.
16. INTEGRITY AND RECOVERY
• INTEGRITY:
• It refers to accuracy or validation of the data.
• Integrity contributes to maintaining a secure database by preventing the data from
becoming invalid and giving misleading results.
• It consists of following aspects : System and object privileges control access to applications
tables and system commands so that only authorized users can change the data.
• Integrity constraints are applied to maintain the correctness and validity of the data in the
database.
• Database must be protected from viruses so firewalls and anti-viruses should be used.
• Ensures that access to the network is controlled and data is not vulnerable to attacks during
transmission across network.
17. THREE MAIN INTEGRITY PROBLEMS
ARE
• Lost updates
• Uncommitted data
• Inconsistent retrieval
18. DATABASE RECOVERY
• The process of restoring database to a correct state in the case of failure. E.g.
• system crashes
• Media failures
• Application software errors
• Natural physical disasters
• carelessness
19. BASIC RECOVERY CONCEPTS
•Backup mechanism – it makes periodic backup copies of the database.
• Logging concept – that keeps the track of current state of transaction and the
changes made in the database.
• Check pointing mechanism – that enables update to be made permanent.
20. CONT…
• The choice of the best possible strategy depends upon the
• Extent of damage that had occurred to the database.
• If there has been a physical damage like disk crash then the last backup copy of the
data is restored.
• However if database has become inconsistent but not physically damaged then
changes caused inconsistency must be undone.
It may also be required to redo some transactions so as to ensure that the updates
are reflected in the database
21. SECURITY OF DATABASE
• Database security refers to the collective measures used to protect and secure a database or database
management software from illegitimate use and malicious cyber threats and attacks.
• Database security procedures are aimed at protecting not just the data inside the database, but the database
management system and all the applications that access it from intrusion, misuse of data, and damage.
• It is a broad term that includes a multitude of processes, tools and methodologies that ensure security within
a database environment.
• Database security covers and enforces security on all aspects and components of databases. This includes:
• Data stored in database.
• Database server.
• Database management system (DBMS).
• Other database workflow applications.
• Database security is generally planned, implemented and maintained by a database administrator and or
other information security professional.