Need help with first ER diagram

Question

This is my first time doing the diagram. My teacher isn't the best at helping out or responding to questions so I've come here to ask for further assistance. I think I've mostly got it correct, but there are a few things I'm still stuck on and don't think are accurate.

This is what the assignment asks of us:

"Create a database schema design based on the following (simplified) requirements of the COMPANY Database:

• The company is organized into DEPARTMENTs. Each department has a name, number and an employee who manages the department. We keep track of the start date of the department manager. A department may have several locations.

• Each department controls a number of PROJECTs. Each project has a unique name, unique number and is located at a single location.

• We store each EMPLOYEE’s social security number, address, salary, gender, and birthdate. Each employee works for one department but may work on several projects. We keep track of the number of hours per week that an employee currently works on each project. We also keep track of the direct supervisor of each employee.

• Each employee may have a number of DEPENDENTs. For each dependent, we keep track of their name, gender, birth date, and relationship to the employee.

• Each entity should contain a name, attributes, PK/FK, and Datatypes. Remember, every time you encounter a many-to-many relationship, you need to add a bridge table."

My issues come with how locations and the manager/supervisor part are supposed to be put into the graph. I'm not so sure if they should be put as bridge tables.

Thanks guys.

Answer 1

Each project has a unique name, unique number and is located at a single location.

The Project to Location relationship is backwards (I'm assuming, without more context). Each project has one location, but each location can have many projects

The relationship between Department and Location is likely wrong, and might be unnecessary. I'm imagining each location can have many departments, and we're told each department can have many locations. So, at a minimum, this is many to many. But it's possible it can be removed entirely. If the departments location is defined by the location of its projects, the we can get the departments locations via the projects table, making this relationship unnecessary. The counter example to this, would be if it's possible to say "This department has this location", even if the department doesn't have any projects in that location. In which case, we'd need a bridge table to complete the relationship.

I think the employee table needs its own employee id. Using SSN, is very unwise. I'd also recommend canning the manager id in this table (see below).

As for the Manager table, I think this is sort of correct. Whilst each department has only one manager at a time. We're told this.

We keep track of the start date of the department manager.

Which I gather to mean, we're keeping track of historical managers. In which case a one-to-many relationship fits here. However, I think this table also needs the department number. I also think it should have the employee number, not a manager id. Then the relationship with the employee and manager table is via the employee id.