-Each Bureau has employees that only work at the bureau level (think CEO's,CIO's,etc) and employees that work at the many office level
-Each office has people who only work at the office level (maybe managers, chief,s etc) and people who work at the many divisions levels
-Each division has people who work only at the division level (division chiefs, for example) and employees who work on projects
-Also, each division has projects that are run by division staff (employees, not the high level divisions chiefs)
These rules imply that each employee has a role that requires they work either only for a bureau, an office, or a division, or requires they work for a given bureau and many offices, or an office and many divisions, or a division, and that only employees who work for a division but are not division staff run projects. The schema shown however asserts only that employees work for a division in any given role and that any of them can run a project. Changes are needed to bring the schema into line with rules.
The simplest way to address the business rules is to add tables to associate employees to offices and bureaus in addition to divisions. Each employee would then be associated to each organization level in which they work. Employees working only at a bureau, or office, or division would only be associated to that level. Employees working at a bureau who also work at many offices would be associated to the bureau in that associative table and then also associated to the many offices by that associative table. Note this approach only addresses where each employee actually works and not the rules as to which roles can work at which organizational levels. To address the rules more discovery and modeling is required and is beyond the scope of this answer.
Secondly, the business rules imply that an employee has a single role - say a CIO or office manager or division chief - and not a role per associated location. The schema can be brought into agreement with this rule, if correct, by making the role table a parent of the employee table such that each employee is assigned a single role. Now this implication may or may not be true. Perhaps an employee can have only a single role at a moment in time, but many over time. In this case temporal columns are also required. Perhaps an employee really can have many roles at the same time at different organization levels, in which case the role would not be determined by the employee. Ultimately, more clarity is needed on the full scope of the business rules by having the subject matter expert review the model and determine if it represents accurately the rules by which they operate. It is vital to fully understand and document the functional dependencies and natural keys in order to arrive at the correct logical design. Right now the diagram does not show any natural keys so even if the functional dependencies were presented it would not be possible to determine if the logical design is in agreement with them. Finally, the diagram shows that each parent entity is optional and I doubt that is really the case. A business SME can determine under what circumstances the parent occurrence is optional, and for each of those circumstances more work is needed to determine why the parent occurrence is optional and resolve it so it is no longer optional.
I hope these points help in improving the design to meet all the informational objectives.
