If the score is calculated, it probably should not be stored at all - rather calculated when needed.
According to your relationships, one company can only ever have one instance of a particular indicator. If that's not the way it's supposed to be, then the design is incorrect. I'd use a composite index in DialogIndicator, not a composite PK regardless. The use of a composite PK in Progress looks odd, but then we know nothing about the process.
You cannot simply link the 2 fields and enforce referential integrity if it is the plan to do so as in the other relationships - because DialongIndicatorID is not a unique field. By using a composite PK in the table, you'd be forced to add a 3rd field to the composite PK because you cannot have a composite pk and a primary pk in the same table as I understand it.
Might be a good idea to research db normalization, or provide a detailed overview of the process that the db supports. I'm also thinking that company names belong in their own table.
Last edited by Micron; 09-10-2021 at 02:01 PM.
Reason: added info
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.