Storing additional FK in a table

Why must the employees working on a project strictly belong to the same division that owns the project? That sounds more like a business rule that you can leave up to your application to enforce rather than something that requires DRI.

But let's say you need to enforce this using DRI. You said you have a many-to-many table associating employees with projects. Assuming you are using SQL Server, you could expand this table as follows:

CREATE TABLE dbo.Employee_Project (
     ProjectID            INT
   , ProjectDivisionID    INT

   , EmployeeID           INT
   , EmployeeDivisionID   INT

   , Hours                INT

   , CONSTRAINT FK_Project FOREIGN KEY (ProjectID, ProjectDivisionID) 
        REFRENCES dbo.Project(ProjectID, DivisionID)

   , CONSTRAINT FK_Employee FOREIGN KEY (EmployeeID, EmployeeDivisionID) 
        REFERENCES dbo.Employee(EmployeeID, DivisionID)

   , CONSTRAINT CK_EmployeeProjectSameDivision CHECK (ProjectDivisionID = EmployeeDivisionID)
);

This is what's going on here:

• We have two composite foreign keys here, one for Employee and one for Project, so we can have the DivisionID for both entities in the same table and guaranteed by DRI to be correct.
• These composite foreign keys require a UNIQUE index on the referenced tables. So in addition to your primary keys on EmployeeID and ProjectID in those tables, you'll need unique keys on (EmployeeID, DivisionID) and (ProjectID, DivisionID).
• The CHECK constraint guarantees that an employee can only be assigned to a project owned by the same division.

If you want to see another example of this design pattern, here's the answer I gave to a design problem that had similar requirements.

If you are running a video rental store, then whether or not your children eat depends very much on a video appearing in as many reservations as possible.

In your example, RESERVATION is a weak entity which relies on both the FK to CUSTOMER and the FK to VIDEO in addition to a further attribute, perhaps date, to comprise its primary key.

It is not possible for a M:N relationship to be supporting for a weak entity (although the intersection table which resolves a M:N relationship can be a weak entity). This is because a supporting relationship needs to be to a particular entity object. A set of entity objects can't identify something in relational algebra.

It is possible for a 1:1 relationship to be supporting for a weak entity, although this would be rare "in the wild". I could imagine it coming up in the context of situations that would typically be 1:M, but where there is a business rule that restricts the child to one at a time.