Initial Conceptual Design of the COMPANY Database

 

Initial Conceptual Design of the COMPANY Database

After analyzing the data requirements of the COMPANY miniworld, the first step in conceptual database design is to identify the major entity types and their attributes. At this stage, the focus is on what data must be stored, not yet on how entities are related. Relationships are refined later.

Based on the given requirements, four main entity types are identified.


1. DEPARTMENT Entity Type

The DEPARTMENT entity represents the organizational units of the company.

Attributes

  • Name (key)

  • Number (key)

  • Locations (multivalued)

  • Manager

  • Manager_start_date

Design Notes

  • Both Name and Number are unique, so each can serve as a key.

  • A department may operate at multiple locations, hence Locations is multivalued.

  • Manager-related attributes are included initially but will later be modeled as relationships.


2. PROJECT Entity Type

The PROJECT entity represents projects controlled by departments.

Attributes

  • Name (key)

  • Number (key)

  • Location

  • Controlling_department

Design Notes

  • Each project has a unique name and number.

  • A project is associated with one department, initially represented as an attribute.

  • This association will later be refined into a relationship.


3. EMPLOYEE Entity Type

The EMPLOYEE entity represents people working in the company.

Attributes

  • Ssn (key)

  • Name (composite: Fname, Minit, Lname)

  • Sex

  • Address

  • Salary

  • Birth_date

  • Department

  • Supervisor

Design Notes

  • SSN uniquely identifies employees.

  • Name is modeled as a composite attribute to allow access to individual components.

  • Address is kept as a simple attribute after user consultation.

  • Department and Supervisor attributes represent associations that will later be converted into relationships.


4. DEPENDENT Entity Type

The DEPENDENT entity stores information about employees’ dependents for insurance purposes.

Attributes

  • Dependent_name

  • Sex

  • Birth_date

  • Relationship

  • Employee

Design Notes

  • Dependents do not exist independently of employees.

  • The Employee attribute indicates association with an EMPLOYEE entity.

  • This entity will later be identified as a weak entity type.


5. Employee–Project Work Information

One key requirement is to store:

  • Which projects an employee works on

  • The number of hours per week spent on each project

Initial Representation

This is initially modeled as a multivalued composite attribute:

  • Works_on (Project, Hours) — attached to EMPLOYEE

Design Decision

  • This approach captures the requirement but is temporary.

  • In the next design step, this will be refined into a many-to-many relationship between EMPLOYEE and PROJECT with Hours as a relationship attribute.


6. Nature of This Design Stage

This design is preliminary and conceptual:

  • Focuses on entity identification

  • Some attributes represent implicit relationships

  • Refinement occurs when relationship concepts are formally introduced





Key Takeaways

✔ Four core entity types: EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
✔ Keys and multivalued attributes identified early
✔ Composite attributes used where user requirements demand
✔ Complex associations postponed for refinement into relationships


Pedagogical Insight

This stage demonstrates that conceptual design is iterative. Initial modeling captures requirements clearly, while later refinements improve correctness and expressiveness using relationships and constraints.

Comments

Popular posts from this blog

Database Management Systems DBMS PCCST402 Semester 4 KTU CS 2024 Scheme

Database Management Systems DBMS PCCST402 Scheme and Syllabus

Introduction to Database Management System -DBMS