1) EMPLOYEE(EMPNO, ENAME, SAL, DEPTNO, DNAME, LOC)
Assumptions & FDs
Key: EMPNO
Functional dependencies (FDs):
o EMPNO → ENAME, SAL, DEPTNO
o DEPTNO → DNAME, LOC
Hence: EMPNO → DEPTNO → DNAME, LOC (a transitive dependency)
Current normal form
1NF (values are atomic) and 2NF (key is single-attribute, so no partial dependency)
Not 3NF/BCNF due to the transitive dependency EMPNO → DNAME, LOC via DEPTNO.
Normalize to 3NF (and BCNF)
Decompose on DEPTNO → DNAME, LOC:
Relations
EMP(EMPNO, ENAME, SAL, DEPTNO)
DEPT(DEPTNO, DNAME, LOC)
SQL sketch
-- 3NF/BCNF design
CREATE TABLE DEPT (
DEPTNO INT PRIMARY KEY,
DNAME VARCHAR(50) NOT NULL,
LOC VARCHAR(50) NOT NULL
);
CREATE TABLE EMP (
EMPNO INT PRIMARY KEY,
ENAME VARCHAR(50) NOT NULL,
SAL NUMBER(10,2) NOT NULL,
DEPTNO INT NOT NULL REFERENCES DEPT(DEPTNO)
);
2) STUDENT(ROLLNO, NAME, AGE, EXAM, MARKS, GRADE)
Assumptions & FDs
A student can appear in multiple exams, so natural key: (ROLLNO, EXAM)
FDs:
o ROLLNO → NAME, AGE (student attributes)
o (ROLLNO, EXAM) → MARKS
o Often, MARKS → GRADE (grading rule), creating a transitive dependency inside results.
Current normal form
1NF (atomic).
Not 2NF because NAME and AGE depend only on part of the composite key (ROLLNO).
Even after 2NF, not 3NF if GRADE is determined by MARKS (transitive).
Normalize to 3NF
Step to 2NF (remove partial dependency)
STUDENT(ROLLNO, NAME, AGE)
RESULT(ROLLNO, EXAM, MARKS, GRADE)
Step to 3NF (remove transitive MARKS → GRADE)
Option A (computed grade): keep only MARKS in RESULT and compute GRADE in queries.
Option B (lookup table): separate the grading policy.
Relations (3NF)
STUDENT(ROLLNO, NAME, AGE)
RESULT(ROLLNO, EXAM, MARKS) with PK (ROLLNO, EXAM)
GRADE_POLICY(LOW_MARK, HIGH_MARK, GRADE) -- or EXAM_GRADE(EXAM, LOW,
HIGH, GRADE) if per-exam rules differ
SQL sketch
CREATE TABLE STUDENT (
ROLLNO INT PRIMARY KEY,
NAME VARCHAR(60) NOT NULL,
AGE INT
);
CREATE TABLE RESULT (
ROLLNO INT NOT NULL,
EXAM VARCHAR(40) NOT NULL,
MARKS INT NOT NULL,
PRIMARY KEY (ROLLNO, EXAM),
FOREIGN KEY (ROLLNO) REFERENCES STUDENT(ROLLNO)
);
-- Optional if grade is table-driven
CREATE TABLE GRADE_POLICY (
LOW_MARK INT NOT NULL,
HIGH_MARK INT NOT NULL,
GRADE CHAR(2) NOT NULL,
PRIMARY KEY (LOW_MARK, HIGH_MARK)
);
3) EMPLOYEE–PROJECT(EMPNO, PROJECT_NO, NO_OF_DAYS, CUSTOMERNAME)
(EMPNO, PROJECT_NO) together form a composite primary key.)
Problem asked: “What kind of problem does this table have and how to solve it?”
Diagnosis
FDs (typical in such schemas):
o (EMPNO, PROJECT_NO) → NO_OF_DAYS
o PROJECT_NO → CUSTOMERNAME (each project belongs to one customer)
Partial dependency of CUSTOMERNAME on part of the key (PROJECT_NO), so the table violates
2NF.
Normalization fix (to 3NF/BCNF)
Split the project/customer info from the assignment facts:
Relations
EMP_PROJECT(EMPNO, PROJECT_NO, NO_OF_DAYS) — PK (EMPNO, PROJECT_NO)
PROJECT(PROJECT_NO, CUSTOMERNAME) — PK PROJECT_NO
o (Optionally) CUSTOMER(CUSTOMER_ID, CUSTOMERNAME, …) and let PROJECT
reference CUSTOMER_ID if customers repeat across projects.
SQL sketch
CREATE TABLE PROJECT (
PROJECT_NO INT PRIMARY KEY,
CUSTOMERNAME VARCHAR(80) NOT NULL
);
CREATE TABLE EMP_PROJECT (
EMPNO INT NOT NULL,
PROJECT_NO INT NOT NULL,
NO_OF_DAYS INT NOT NULL,
PRIMARY KEY (EMPNO, PROJECT_NO),
FOREIGN KEY (PROJECT_NO) REFERENCES PROJECT(PROJECT_NO)
);
