Question

Currently I have a database with the following relationships:

One Client has multiple Entities (via Client Name – this is unique)

One Entity has multiple EntityServices (via Entity ID)

One Service has multiple EntityServices (via Service Name – basically a table of service lines)

Now this is all working fine, but I want to create a table by the name of EngagementLetters. It should have the following relationships:

One Client has multiple EngagementLetters (via Client Name)

One EngagementLetters has multiple EntityServices (via Engagement Letter ID)

and the tricky one: all EntityServices under a single EngagementLetter must have the same Client

I’ve been able to create the above except for the last point. It’s stumped me, I have no idea how to do it! Would anyone be able to help with this?

Cheers,

Andrew

Answer 1

      Client
     ^      ^
     |      |
     |      Entities   Service
     Eletter      ^          ^
        ^         |          |
        |_______ EntityServices

Like this?

“One Client has multiple EngagementLetters (via Client Name – this is unique)”

why Client Name? you used Client Id for the relationship with entity. It is fine to make client name unique, but it is not good practice to use a different key for different relationships. Foreign keys should typically point to the primary key (which i presume is client id?)

“and the tricky one: all EntityServices under a single EngagementLetter must have the same Client”

What do you mean? Is there a relationship between EntityServices and client? there is one via Entities, do you mean the client id derived from the related entities parent row? Is this in some way related to the client linked to by engagement letter?

If you simply want to enforce the rule as you state it, you should consider creating a new table that links to both client and engagement letter, and link to there from entity services. However this is only a good choice if you can make the case that the client/engagement letter combination is some kind of object – not just an abstract construct to implement this particular business rule.

If it’s just that, a business rule, then you should use triggers or application logic to enforce it, and reserve foreign keys only for representing relationships between data structures.