Question 1:

Table Demonstrating Anomalies

Transformation to 1NF:

Transformed 1NF Table:

Transformed 2NF Tables:

| OrderID | CustomerName | Address

|---------|--------------|-----------------|

| 1001 | Fady14 | Street A |

| 1002 | Jana14 | Street B |

| 1003 | Fady14 | Street A |

| 1004 | Rana14 | Street C |

| 1005 | Jana14 | Street B |

| 1006 | Fady14 | Street A |

- ProductOrder:
| OrderID | ProductName | ProductCategory | Quantity | Price |

| 1001 | Laptop14 | Electronics |2 | 800 |

| 1002 | Mouse14 | Electronics |1 | 50 |

| 1003 | Keyboard14 | Electronics |1 | 100 |

| 1004 | Laptop14 | Electronics |3 | 800 |

| 1005 | Monitor14 | Electronics |1 | 300 |

| 1006 | Mouse14 | Electronics |2 | 50 |

# Justification for Compliance with 3NF

The transformed 2NF tables do not fully comply with the Third Normal Form (3NF) because the
“Address” attribute in the “Order” table depends on “CustomerName” and not on the primary key
(OrderID).

Transformation to 3NF:
1. Remove transitive dependencies.

2. Create separate tables for attributes that depend on non-prime attributes.

Transformed 3NF Tables:

Customer:

| CustomerID | CustomerName | Address

|1 | Fady14 | Street A |

|2 | Jana14 | Street B |

|3 | Rana14 | Street C |

Order:

| OrderID | CustomerID |

| 1001 | 1 |

| 1002 | 2 |
| 1003 | 1 |

| 1004 | 3 |

| 1005 | 2 |

| 1006 | 1 |

-ProductOrder:
| OrderID | ProductName | ProductCategory | Quantity | Price

| 1001 | Laptop14 | Electronics |2 | 800 |

| 1002 | Mouse14 | Electronics |1 | 50 |

| 1003 | Keyboard14 | Electronics |1 | 100 |

| 1004 | Laptop14 | Electronics |3 | 800 |

| 1005 | Monitor14 | Electronics |1 | 300 |

| 1006 | Mouse14 | Electronics |2 | 50 |

Question 2:
Entity-Relationship Diagram (ERD) and Database Design for Employee and Project
Management System

1. Entity-Relationship Diagram (ERD) The ERD for managing employees and projects is
designed using UMLET, illustrating the following entities and their relationships:

 Entities:
o Employee
 Attributes: employeeID26 (Primary Key), name26, position26
 Constraints:
 employeeID26 is unique.
 Name26 cannot be null.
 Position26 must be one of {Manager, Developer, Analyst}.
o Project
 Attributes: projectID26 (Primary Key), projectName26, startDate26
 Constraints:
 projectID26 is unique.
 projectName26 cannot be null.
 startDate26 must be a valid date.

Relationship:
  Assignment (Many-to-Many Relationship between Employee and Project)
o Attributes: assignmentDate26
o Constraints:
 employeeID26 and projectID26 must exist in their respective entities.

2. Constraints per Entity

 Employee:
o employeeID26(Primary Key, Unique)
o name26 (Not Null)
o position26(Must be valid as {Manager, Developer, Analyst})
 Project:
o projectID26(Primary Key, Unique)
o projectName26 (Not Null)
o startDate26 (Valid Date)

3. Textual Notation for Entities

 Employee:
o Primary Key: employeeID26
o Attributes: name26, position26
o Constraints:
 employeeID14 must be unique.
 Name26cannot be null.
 Position26 must belong to a set {Manager, Developer, Analyst}.
 Project:
o Primary Key: projectID26
o Attributes: projectName14, startDate26
o Constraints:
 projectID26 must be unique.
 projectName26 cannot be null.
 startDate26 must be a valid date.

4. Relation-for-Relationship Representation

 Employee_Project_Assignment (Bridge Table for Many-to-Many Relationship)

o Attributes: employeeID26(Foreign Key), projectID14 (Foreign Key),
assignmentDate26
o Primary Key: (employeeID14, projectID26)
o Constraints:
 employeeID26references Employee(employeeID26).
 projectID26references Project(projectID26).

5. Posted-Key Representation The posted-key representation indicates how primary and

foreign keys are mapped:

 Employee:
o Primary Key: employeeID26
 Project:
 Primary Key: projectID26
o
 Employee_Project_Assignment:
o Primary Key: (employeeID26, projectID26)
o Foreign Keys:
 employeeID26references Employee(employeeID26)
 projectID26 references Project(projectID26)

Justification: The bridge table Employee_Project_Assignment ensures normalization and

avoids redundancy, maintaining data integrity while allowing flexible many-to-many
relationships between employees and projects.

6. ERD for Employee and Enterprise Relationship

Entities:

 Employee
o Attributes: employeeID26, name26, position26
 Enterprise
o Attributes: enterpriseID26, enterpriseName26, location26

Relationship:

 Employment (One-to-Many from Enterprise to Employee)

o Attributes: hireDate26
o Constraints:
 Each employeeID26 references one enterpriseID26

7. Posted-Key Representation for Employee and Enterprise ERD

 Employee:
o Primary Key: employeeID26
o Foreign Key: enterpriseID26 (references Enterprise(enterpriseID26))
 Enterprise:
o Primary Key: enterpriseID26
 Relationship
o Primary Key for Employment: (employeeID26)