Example: COMPANY Database Application
Example: COMPANY Database Application
The COMPANY database is a classic example used to demonstrate conceptual database design using the ER model. It models a miniworld that includes employees, departments, projects, and dependents, along with their relationships and constraints.
1. Purpose of the COMPANY Database
The COMPANY database is designed to:
-
Maintain employee information
-
Track departmental organization
-
Manage projects and employee participation
-
Store employee dependents for insurance purposes
This database supports common business operations such as employee management, project allocation, and departmental control.
2. Identified Entity Types
From the requirements, we identify the following entity types:
-
EMPLOYEE
-
DEPARTMENT
-
PROJECT
-
DEPENDENT (weak entity)
3. Entity Descriptions with Sample Data
3.1 EMPLOYEE Entity
Stores personal and job-related information about employees.
Attributes
-
Ssn (Primary Key)
-
Name (Fname, Minit, Lname)
-
Address
-
Salary
-
Sex
-
Birth_date
Sample EMPLOYEE Data
| Ssn | Name | Address | Salary | Sex | Birth_date |
|---|---|---|---|---|---|
| 123456789 | John A Smith | 2311 Kirby, Houston TX | 60000 | M | 1969-03-15 |
| 987654321 | Alicia J Brown | 45 Main St, Dallas TX | 75000 | F | 1985-08-21 |
3.2 DEPARTMENT Entity
Represents organizational units within the company.
Attributes
-
Dnumber (Primary Key)
-
Dname (Unique)
-
Locations (Multivalued)
-
Manager (FK → EMPLOYEE)
-
Mgr_start_date
Sample DEPARTMENT Data
| Dnumber | Dname | Locations | Manager_Ssn | Mgr_start_date |
|---|---|---|---|---|
| 5 | Research | Houston, Dallas | 123456789 | 2018-01-01 |
| 4 | Accounting | Chicago | 987654321 | 2020-06-15 |
3.3 PROJECT Entity
Represents projects controlled by departments.
Attributes
-
Pnumber (Primary Key)
-
Pname (Unique)
-
Location
-
Controlled_by (FK → DEPARTMENT)
Sample PROJECT Data
| Pnumber | Pname | Location | Dnumber |
|---|---|---|---|
| 1 | ProductX | Houston | 5 |
| 2 | ProductY | Dallas | 5 |
| 3 | PayrollSystem | Chicago | 4 |
3.4 DEPENDENT Entity (Weak Entity)
Stores dependents of employees for insurance purposes.
Attributes
-
Dependent_name (Partial Key)
-
Sex
-
Birth_date
-
Relationship
-
Employee_Ssn (FK → EMPLOYEE)
📌 A DEPENDENT cannot exist without an EMPLOYEE.
Sample DEPENDENT Data
| Employee_Ssn | Dependent_name | Sex | Birth_date | Relationship |
|---|---|---|---|---|
| 123456789 | Anna | F | 2012-05-10 | Daughter |
| 123456789 | Mark | M | 2015-11-02 | Son |
4. Identified Relationships
4.1 WORKS_FOR
-
Between EMPLOYEE and DEPARTMENT
-
Many employees work for one department
-
Each employee belongs to exactly one department
4.2 MANAGES
-
Between EMPLOYEE and DEPARTMENT
-
One employee manages one department
-
Includes attribute Mgr_start_date
4.3 CONTROLS
-
Between DEPARTMENT and PROJECT
-
One department controls many projects
4.4 WORKS_ON
-
Between EMPLOYEE and PROJECT
-
Many-to-many relationship
-
Attribute: Hours_per_week
4.5 DEPENDENTS_OF
-
Identifying relationship between EMPLOYEE and DEPENDENT
-
One employee may have multiple dependents
5. How This Maps to an ER Diagram
-
Rectangles → Entity types (EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT)
-
Diamonds → Relationships (WORKS_FOR, MANAGES, WORKS_ON, CONTROLS)
-
Ovals → Attributes
-
Double rectangles → Weak entity (DEPENDENT)
-
Double diamonds → Identifying relationship (DEPENDENTS_OF)
Refer Figure 3.2
6. Why This Example Is Important
-
Demonstrates real-world complexity
-
Illustrates keys, weak entities, multivalued attributes, and relationship attributes
-
Commonly used in exams, labs, and ER modeling practice
-
Serves as a foundation for:
-
ER → Relational mapping
-
SQL schema design
-
Normalization
-

Comments
Post a Comment