EXP-01

Concept design with E-R Model

Draw an ER diagram for the following

There are two entity sets Employee and Department. These entity sets are participating in a relationship works in. The
relationship set is converted into relation with attributes EmpNo from Employee relation, D_id from Department relation
and Since, the attribute of the relationship set itself.
Symbols Used in ER Model
ER Model is used to model the logical view of the system from a data perspective which consists of these symbols:

Rectangles: Rectangles represent Entities in the ER Model.

Ellipses: Ellipses represent Attributes in the ER Model.
Diamond: Diamonds represent Relationships among Entities.
Lines: Lines represent attributes to entities and entity sets with other relationship types.
Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
Double Rectangle: Double Rectangle represents a Weak Entity.

Symbols used in ER Diagram

Components of ER Diagram
ER Model consists of Entities, Attributes, and Relationships among Entities in a Database System.
Entity=>
An Entity may be an object with a physical existence – a particular person, car, house, or employee – or it may
be an object with a conceptual existence – a company, a job, or a university course.
To draw an ER diagram for the described scenario, we have two entities — Employee and Department — and a
relationship set called "works in." Here's how we can represent it:

Step-by-step breakdown:

1. Entity Sets:An Entity is an object of Entity Type and a set of all entities is called an entity set.
o Employee: This entity set represents employees and includes attributes like EmpNo (Employee
Number).
o Department: This entity set represents departments and includes attributes like D_id (Department
ID).
2. Relationship Set:A Relationship Type represents the association between entity types. The relationship type is
represented by a diamond and connecting the entities with lines.
o
Works in: This relationship links employees to departments, indicating that an employee works in
a department. The relationship will have an additional attribute Since that captures the year or date
when the employee started working in the department.
3. Attributes of Entities:Attributes are the properties that define the entity type.
o Employee has an attribute EmpNo.
o Department has an attribute D_id.
o The Works in relationship has an attribute Since.
4. ER Diagram Components:
o Entities: Represented by rectangles, the Employee and Department entities will be placed in
separate rectangles.
o Relationship: Represented by a diamond, the "works in" relationship will be placed between
Employee and Department.
o Attributes: Represented by ovals, the attributes EmpNo for Employee, D_id for Department, and
Since for the relationship will be connected to their respective entities/relationship.

ER Diagram Layout:

 Employee (Entity):
o EmpNo (attribute)
 Department (Entity):
o D_id (attribute)
 Works in (Relationship):
o Since (attribute)

Now, here is a textual representation of the ER diagram layout:

+----------------+ +------------------+
| Employee | | Department |
|------------------| |--------------------|
| EmpNo | | D_id |
+----------------+ +------------------+
| |
| |
| |
+----------------------------------------+
| Works in (Relationship) |
|------------------------------------------|
| Since |
+----------------------------------------+
| |
| |
Explanation:

 Employee and Department are connected to the Works in relationship through lines, indicating that
employees work in departments.
 The Since attribute is associated with the Works in relationship, as it reflects when the employee started
working in that department.
 EXP-02

Relational Model

Convert the above ER diagram into Relational Model

To convert the provided ER diagram into a Relational Model, we need to translate the entities and relationships
into relations (tables) and their respective attributes. Here is how we would approach it:

Entities and Attributes

1. Employee Entity:
o Attributes: EmpNo (Employee Number)
o Relation: Employee(EmpNo)
2. Department Entity:
o Attributes: D_id (Department ID)
o Relation: Department(D_id)

Relationship and Attributes

3. Works in Relationship:
o Attributes: Since (the date or year the employee started working in the department)
o Relation: WorksIn(EmpNo, D_id, Since)

Steps for Conversion:

1. Employee Relation: This table represents the Employee entity with its primary key, EmpNo.

Employee(EmpNo)

oEmpNo is the primary key.

2. Department Relation: This table represents the Department entity with its primary key, D_id.

Department(D_id)

o D_id is the primary key.

3. WorksIn Relation: This table represents the relationship between Employee and Department, with an
additional attribute, Since. It consists of two foreign keys: EmpNo from the Employee table and D_id from
the Department table.

WorksIn(EmpNo, D_id, Since)

o EmpNo is a foreign key referencing Employee(EmpNo).

o D_id is a foreign key referencing Department(D_id).
o The primary key of the WorksIn relation will be a composite key consisting of EmpNo and D_id
(since an employee can only work in one department at a time, but the relationship can be
repeated for different employees or departments).

The relation also includes the Since attribute which is specific to the relationship.

Final Relational Model:

1. Employee Relation:

Employee(EmpNo)
 o EmpNo (Primary Key)
2. Department Relation:

Department(D_id)

oD_id (Primary Key)

3. WorksIn Relation:

WorksIn(EmpNo, D_id, Since)

o EmpNo (Foreign Key referencing Employee(EmpNo))

o D_id (Foreign Key referencing Department(D_id))
o Since (Attribute of the relationship)
o Primary Key: (EmpNo, D_id)

Summary:

 The Employee and Department entities are converted into separate relations.
 The WorksIn relationship is converted into a relation with foreign keys pointing to the Employee and
Department relations, and an additional attribute Since representing the start date.
 EXP=>03

Normalization
Consider the following table.

a) Normalize the given Relation. Consider the given schema is in first normal form
and Schema(Student id ,Student name, Project Id, Project name, City, country, ZIP)

Eid E.Name Ph.no ProjId ProjName ProjLeader EmpCity City

Zip
101 John 98765623,998234123 P03 Project103 Grey ModelTown 110033
102 John 89023467 P01 Project101 Christia n Badarpur 110044
103 Ryan 76213908 P04 Project104 Hudson Naraina 110028
104 stephine 98132452 P02 Project102 Petro HariNagar 110064
Primary key(Studentid,Projectid)

Fd’s: Project Id-->Project name

country->ZIP,ZIP

b) Normalize the given Table to the BCNF

Consider the set of
Functional_Dependencies..

Eid->EName,Ph.no,Empcity,CityZip PrimaryKey=(EmpId,ProjId)

ProjId->ProjName, ProjLeader

EmpId,ProjId->ProjLeader

EmpCity->CityZip

ProjId->ProjLeader

To solve this problem, we need to normalize the given relation step by step to bring it into Boyce-Codd Normal
Form (BCNF) while considering the provided functional dependencies (FDs).

Step 1: Understanding the Given Schema and Functional Dependencies

The initial schema is as follows:

Schema: Student id, Student name, Project Id, Project name, City, country, ZIP

We are given the following table data:

Eid E.Name Ph.no ProjId ProjName ProjLeader EmpCity City Zip

101 John 98765623, 998234123 P03 Project103 Grey ModelTown Grey 110033

102 John 89023467 P01 Project101 Christia Badarpur Christia 110044

103 Ryan 76213908 P04 Project104 Hudson Naraina Hudson 110028

104 Stephine 98132452 P02 Project102 Petro HariNagar Petro 110064

Functional Dependencies (FDs) provided:

1. (ProjId -> ProjName)

2. (Country -> ZIP)
3. (ZIP -> City)

Primary Key: (EmpId, ProjId)

Step 2: Decompose the relation into 1NF (First Normal Form)

The table provided is already in 1NF because:

 All columns contain atomic values (no repeating groups or arrays).

 Each row has a unique identifier (Primary key is (EmpId, ProjId)).

So, we will move on to the next step.

Step 3: Decompose the relation into 2NF (Second Normal Form)

2NF Condition:

 The relation is in 2NF if it is in 1NF and all non-prime attributes are fully functionally dependent on the primary
key.
 To satisfy this, we must remove partial dependencies (if any), where non-prime attributes are dependent on a part
of the primary key rather than the whole primary key.

In this case, the primary key is (EmpId, ProjId).

 FDs like (ProjId -> ProjName) and (Country -> ZIP) suggest that ProjName depends only on ProjId, and ZIP depends
only on Country. Hence, these are partial dependencies.
 We need to decompose the relation to remove these partial dependencies.

Step 4: Decompose the relation into 3NF (Third Normal Form)

3NF Condition:

 A relation is in 3NF if it is in 2NF and no transitive dependencies exist, i.e., non-prime attributes must not depend
on other non-prime attributes.

Looking at the FDs:

 (ZIP -> City) is a transitive dependency because City depends on ZIP, and ZIP depends on Country. So, we will
decompose to remove this transitive dependency.

Step 5: Decompose the relation into BCNF (Boyce-Codd Normal Form)

BCNF Condition:

 A relation is in BCNF if, for every functional dependency, the left-hand side is a superkey.

Let's examine the FDs:

 (ProjId -> ProjName) violates BCNF because ProjId is not a superkey for the original relation (EmpId, ProjId). We
need to decompose the relation so that the left-hand side of every FD is a superkey.
Step 6: Decompose the Relation

We decompose the relation into several smaller relations to remove partial, transitive dependencies, and to
satisfy BCNF.

1. Relation 1: Employee Project Information (with functional dependencies)

 This relation will contain the information about the employee's project involvement.

EmpId ProjId ProjLeader EmpCity

101 P03 Grey ModelTown

102 P01 Christia Badarpur

103 P04 Hudson Naraina

104 P02 Petro HariNagar

Functional Dependencies:

 (EmpId, ProjId) -> ProjLeader, EmpCity

2. Relation 2: Project Information (with functional dependencies)

 This relation will store details of projects.

ProjId ProjName

P03 Project103

P01 Project101

P04 Project104

P02 Project102

Functional Dependency:

 (ProjId -> ProjName)

3. Relation 3: Country and ZIP Information

 This relation will store details about countries and ZIP codes.

Country ZIP

Grey 110033

Christia 110044

Hudson 110028

Petro 110064
Functional Dependency:

 (Country -> ZIP)

4. Relation 4: ZIP and City Information

 This relation stores the information about ZIP and corresponding cities.

ZIP City

110033 Grey

110044 Christia

110028 Hudson

110064 Petro

Functional Dependency:

 (ZIP -> City)

Step 7: Resulting Relations and Their Keys

 Employee Project Information: (EmpId, ProjId) is the primary key.
 Project Information: (ProjId) is the primary key.
 Country and ZIP Information: (Country) is the primary key.
 ZIP and City Information: (ZIP) is the primary key.
 EXP=>04
Practicing DDL commands

DDL (Data Definition Language) commands are used to define, modify, or remove database structures like
tables, schemas, indexes, and more. Here’s a quick rundown of common DDL commands:

1. CREATE: Used to create new database objects (like tables, views, or indexes).
2. ALTER: Used to modify existing database objects.
3. DROP: Used to delete existing database objects.
4. TRUNCATE: Used to delete all records in a table but keep the table structure.
5. RENAME: Used to rename an existing database object.

Examples of DDL commands:

1. CREATE TABLE:
This command creates a new table in the database.

CREATE TABLE Students (

StudentID INT PRIMARY KEY,
FirstName VARCHAR(50),
LastName VARCHAR(50),
DateOfBirth DATE
);

2. ALTER TABLE:
This command is used to modify an existing table.

ALTER TABLE Students ADD Email VARCHAR(100);

3. DROP TABLE:
This command deletes an existing table and all of its data.

DROP TABLE Students;

4. TRUNCATE TABLE:
This command removes all records from a table without deleting the table itself.

TRUNCATE TABLE Students;

5. RENAME TABLE:
This command renames an existing table.

RENAME TABLE Students TO Alumni;