Need help with construct the data model

Using the Erwin Software construct a logical data model using the IE notation to fit the following circumstances.

The company employee administrative database stores information about the employees, the department and the projects of a company. The following data have been identified in the requirements collection and analysis phase and they are to be represented in the enterprise. The company is organized into departments. Each department has a unique name, a unique number and a particular employee who manages the department. The database keeps track of the start date when an employee began managing the department. A department controls number of projects. Each project has a unique name, unique number and a single location. The database also stores the number of work hours budgeted for each project. The database stores each employees name, pin number, address, salary, sex, birth date, date hired and date he/she terminates employment. An employee is assigned to one department but he/she may work on several projects, which are not necessarily controlled by the same department. The database also keeps tracks of the number of hours an employee already worked on a project and the direct supervisor of each employee if he/she has one. (Note that an employee need not have an assigned supervisor).

The database will keep track of the dependents of each employee for insurance purposes, including each dependent's first name, sex, birth date, and relationship to the employee.

Note: Supervisor is not considered as an entity, because a supervisor is an employee himself and no need to store data separately.

Note: It is said that a department has a manager. But it is NOT an attribute of a Department, as manager should already be an instance of Employee.

(We DO NOT use an instance of another entity as an attribute)

Number of hours an employee worked on a project is neither an attribute of Project nor Employee. it is a Relationship attribute and should only be mentioned in the ERD.

Start date of managing a department is not an attribute of Employee or Departments, but it is a Relationship attribute.

NOTE

Actually, there is the proverbial method in the madness. The design and implementation of recursive relationships are actually rather complex things. Fortunately, even complex design issues become manageable in a familiar data environment.

Recursive relationships are common enough - or should be - to merit attention and the development of expertise in their implementation. In many manufacturing industries, incredibly detailed part tracking is mandatory. For example, the implementation of the recursive relationship "PART contains PART" is especially desirable in the aviation manufacturing businesses. Such businesses are required by federal law to maintain absolute parts tracing records. If a complex part fails, it must be possible to follow all the trails to all the component parts that may have been involved in the part's failure.