Q. What is Functional Dependency?

Write algorithm to find minimal cover for

set of Functional Dependency. Construct the minimal cover m for set of
functional dependency. E={ B  A, D  A, AB  D}
Definition of Functional Dependency:
A functional dependency is a constraint between two sets of attributes from the database.
 Given a relation R, a set of attributes X in R is said to functionally determine another
attribute Y, also in R, (written X Y) if and only if each X value is associated with at
most one Y value.
 X is the determinant set and Y is the dependent attribute. Thus, given a tuple and the
values of the attributes in X, one can determine the corresponding value of the Y
attribute.
Q. Explain informal design guidelines for relational schema design.
Four informal guidelines that may be used as measures to determine the quality of relation
schema design:
1. Making sure that the semantics of the attributes is clear in the schema
2. Reducing the redundant information in tuples
3. Reducing the NULL values in tuples
4. Disallowing the possibility of generating spurious tuples These measures are not always
independent of one another.

Guideline 1
 Design a relation schema so that it is easy to explain its meaning
 Do not combine attributes from multiple entity types and relationship types into a
single relation
 If a relation schema corresponds to one entity type or one relationship type, it is
straightforward to interpret and to explain its meaning
 If the relation corresponds to a mixture of multiple entities and relationships,
semantic ambiguities will result and the relation cannot be easily explained.
 Both the relation schemas have clear semantics
 A tuple in the EMP_DEPT relation schema represents a single employee but includes
additional information - the name (Dname) of the department for which the
employee works and the Social Security number (Dmgr_ssn) of the department
manager.
 A tuple in the EMP_PROJ relates an employee to a project but also includes the
employee name (Ename), project name (Pname), and project location (Plocation).
 Logically correct but they violate Guideline 1 by mixing attributes from distinct real-
world entities:
 EMP_DEPT mixes attributes of employees and departments
 EMP_PROJ mixes attributes of employees and projects and the WORKS_ON relationship
 They may be used as views, but they cause problems when used as base relations.
GUIDELINE2:
 Design the base relation schemas so that no insertion, deletion, or modification
anomalies are present in the relations
 If any anomalies are present, note them clearly and make sure that the programs
that update the database will operate correctly
 The second guideline is consistent with and, in a way, a restatement of the first
guideline
 These guidelines may sometimes have to be violated in order to improve the
performance of certain queries.

Few examples where NULL Values are generated:-

 The attribute does not apply to this tuple. For example, Visa_status may not apply to
U.S. students.
 The attribute value for this tuple is unknown. For example, the Date_of_birth may be
unknown for an employee.
 The value is known but absent; that is, it has not been recorded yet. For example, the
Home_Phone_Number for an employee may exist, but may not be available and
recorded yet.
GUIDELINE 3:
 As far as possible, avoid placing attributes in a base relation whose values may
frequently be NULL
 If NULLs are unavoidable, make sure that they apply in exceptional cases only and do
not apply to a majority of tuples in the relation
 Using space efficiently and avoiding joins with NULL values are the two overriding
criteria that determine whether to include the columns that may have NULLs in a
relation or to have a separate relation for those columns with the appropriate key
columns
 For example, if only 15 percent of employees have individual offices, there is little
justification for including an attribute Office_number in the EMPLOYEE relation;
rather, a relation EMP_OFFICES(Essn, Office_number) can be created to include
tuples for only the employees with individual offices.
GUIDELINE4:
Design relation schemas so that they can be joined with equality conditions on attributes
that are appropriately related (primary key, foreign key) pairs in a way that guarantees that
no spurious tuples are generated Avoid relations that contain matching attributes that are
not (foreign key, primary key) combinations because joining on such attributes may
produce spurious tuples.
Q. Explain the types of update anomalies in SQL with an example.

Insertion Anomaly:

An insertion anomaly occurs when you cannot insert data into a table unless other
unrelated data is also present.
This is due to poor relational schema design where one table holds information about
multiple entities.

Insertion anomalies can be differentiated into two types, illustrated by the following
examples based on the EMP_DEPT relation:
1. To insert a new employee tuple into EMP_DEPT, we must include either the attribute
values for the department that the employee works for, or NULLs
- For example, to insert a new tuple for an employee who works in department number 5,
we must enter all the attribute values of department 5 correctly so that they are consistent
with the corresponding values for department 5 in other tuples in EMP_DEPT
- In the design of Employee in fig 1, we do not have to worry about this consistency
problem because we enter only the department number in the employee tuple; all other
attribute values of department 5 are recorded only once in the database, as a single tuple in
the DEPARTMENT relation
2. It is difficult to insert a new department that has no employees as yet in the EMP_DEPT
relation. The only way to do this is to place NULL values in the attributes for employee
- This violates the entity integrity for EMP_DEPT because Ssn is its primary key
- This problem does not occur in the design of Figure 1 because a department is entered in
the DEPARTMENT relation whether or not any employees work for it, and whenever an
employee is assigned to that department, a corresponding tuple is inserted in EMPLOYEE.
Deletion Anomalies:
The problem of deletion anomalies is related to the second insertion anomaly situation just
discussed
- If we delete from EMP_DEPT an employee tuple that happens to represent the last
employee working for a particular department, the information concerning that
department is lost from the database
- This problem does not occur in the database of Figure 2 because DEPARTMENT tuples are
stored separately.

Modification Anomalies:
 In EMP_DEPT, if we change the value of one of the attributes of a particular
department say, the manager of department 5 we must update the tuples of all
employees who work in that department; otherwise, the database will become
inconsistent
 If we fail to update some tuples, the same department will be shown to have two
different values for manager in different employee tuples, which would be wrong.

Q, What is a Normalization? Explain the 1NF, 2NF & 3NF with examples.
Normalization is a process of organizing data in a database to remove redundancy
(duplicate data) and avoid anomalies (problems during insert, update, or delete
operations).

1. First Normal Form (1NF):

Definition:

A relation is in 1NF if each column contains atomic (single) values and each record is unique.
There should be no multiple values in a single cell.

Example (1NF):

RollNo Name Course

101 Ravi DBMS

101 Ravi Java

102 Meena Python

102 Meena DBMS

2. Second Normal Form (2NF):

Definition:

A relation is in 2NF if it is in 1NF and every non-key attribute is fully dependent on the entire primary
key.

Example (2NF):

Student Table:

RollNo Name

101 Ravi

102 Meena

Enrollment Table:

RollNo Course

101 DBMS

101 Java

102 Python

3. Third Normal Form (3NF):

Definition:

A relation is in 3NF if it is in 2NF and no non-key attribute is dependent on another non-key attribute.
All non-key attributes should depend only on the primary key.

Example (3NF):

Student Table:

RollNo Name DeptID

101 Ravi D01

102 Meena D02

Department Table:

DeptID DeptName

D01 Computer Sci

D02 Electronics
Q. Illustrate insert, delete, update, alter & drop commands in SQL.

🔹 1. INSERT Command:

Used to add new records to a table.

Syntax:

INSERT INTO table_name (column1, column2, ...)

VALUES (value1, value2, ...);

Example:

INSERT INTO Students (RollNo, Name, Branch)

VALUES (101, 'Ravi', 'CSE');

🔹 2. DELETE Command:

Used to remove records from a table.

Syntax:

DELETE FROM table_name

WHERE condition;

Example:

DELETE FROM Students

WHERE RollNo = 101;

🔹 3. UPDATE Command:

Used to modify existing data in a table.

Syntax:

UPDATE table_name
SET column1 = value1, column2 = value2
WHERE condition;

Example:

UPDATE Students
SET Branch = 'ECE'
WHERE RollNo = 102;

🔹 4. ALTER Command:

Used to change the structure of the table (add/remove/modify columns).

Syntax Examples:
  Add a new column:

ALTER TABLE Students

ADD Email VARCHAR(50);

 Modify a column data type:

ALTER TABLE Students

MODIFY Name VARCHAR(100);

 Drop a column:

ALTER TABLE Students

DROP COLUMN Email;

🔹 5. DROP Command:

Used to delete the entire table (structure + data).

Syntax:

DROP TABLE table_name;

Example:

DROP TABLE Students;

✅ Summary Table:

Command Purpose
INSERT Add new data to a table
DELETE Remove data from a table
UPDATE Change existing data in a table
ALTER Change the structure of a table
DROP Delete the entire table and data
Q. Consider two sets of functional dependency. F={AC, ACD,
EAD, EH} E= {ACD, EAH}. Are they Equivalent?

Q. Explain Armstrong inference rules.

✅ Armstrong’s Axioms / Inference Rules

What are Armstrong’s Axioms?

➡ Armstrong’s Axioms are a set of rules used to infer all functional dependencies from a given set of
functional dependencies.
➡ These rules help in finding closure and are sound (correct) and complete.

The 3 Basic Armstrong Axioms:

No. Name Meaning Example

1 Reflexivity If Y ⊆ X, then X → Y {RollNo, Name} → RollNo
2 Augmentation If X → Y, then XZ → YZ RollNo → Name gives RollNo, Dept → Name, Dept
If X → Y and Y → Z, then X → RollNo → Dept and Dept → HOD, then RollNo →
3 Transitivity
Z HOD
Additional Derived Rules (Using the Basic Axioms):

No. Name Meaning

4 Union If X → Y and X → Z, then X → YZ
5 Decomposition If X → YZ, then X → Y and X → Z
6 Pseudo-transitivity If X → Y and YW → Z, then XW → Z

Summary of the 3 Basic Rules:

1. Reflexivity:
If a set contains attributes, it can determine those same attributes.
2. Augmentation:
You can add extra attributes to both sides of a functional dependency.
3. Transitivity:
If A determines B and B determines C, then A determines C.

Q. Illustrate the following with suitable examples:

(i) Datatypes in SQL (ii) Substring Pattern Matching in SQL.

(i) Datatypes in SQL

In SQL, datatypes define the type of data that can be stored in a column.

Data Type Description Example

CHAR(n) Fixed-length character string CHAR(10): 'ABC '
VARCHAR(n) Variable-length character string VARCHAR(20): 'Computer'
INT / INTEGER Integer numbers 101, -25
DECIMAL(p,s) Decimal numbers with precision DECIMAL(5,2): 123.45
FLOAT Floating-point numbers 45.6789
DATE Date values '2024-06-01'
TIME Time values '10:30:00'
BOOLEAN Logical values (TRUE / FALSE) TRUE, FALSE

Example Query Using Datatypes:

CREATE TABLE Students (
RollNo INT,
Name VARCHAR(50),
DOB DATE,
Marks DECIMAL(5,2)
);

(ii) Substring Pattern Matching in SQL (LIKE operator)

SQL uses the LIKE operator for pattern matching with wildcards:
  % → Matches any number of characters (including zero characters)
 _ → Matches exactly one character

✔ Examples:

Pattern Example Meaning

'A%' Strings that start with 'A'
'%son' Strings that end with 'son'
'%com%' Strings that contain 'com' anywhere
'S_m' Strings that start with 'S', have any one character, then 'm'

✔ Example Query:
SELECT * FROM Employees
WHERE Name LIKE 'A%'; -- Names starting with A
SELECT * FROM Products
WHERE ProductName LIKE '%book'; -- Names ending with 'book'