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
Locationsis 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
Post a Comment