少し観点を変えて回答してみます。
「利用」テーブル、「利用実績」テーブル以外にも目を通してみると、
全てのテーブルが「ID列」を保有しています。
このことから提示されたテーブル設計の根底には、
先ずサロゲートキー(代替キー)を利用するという設計思想が読み取れます。
#サロゲートキーの導入の狙い
サロゲートキーとは、
データ構造上一意に定まるものば別にもあるけど、
シンプルな代替キー(主キー)を用意してやろうという考え方、
または利用しているフレームワークの恩恵を受けるために、
その全てのテーブルにサロゲートキーを振るルールに統一するという大まかにはこの2パターンで適用されることが多い設計方針です。
さて今回質問者さんは、
利用実績には事業所ID、利用者IDの2つ持つ方が自然でらと考えておられるようですが、
この考え方自体は間違いではありません。
今回のようなサロゲートキーを導入しないテーブル設計では、
質問者さんの言うような設計も考えられるでしょう。
ただ今回は前提としてサロゲートキーが導入された設計となっているので、
逆に利用実績でも事業所ID、利用者IDを持つことは事実を冗長に管理することとなってしまいます。
それはサロゲートキーが、
テーブル内の一意を保証するデータ構造を代わりに提供しているからです。
なので他のテーブル(「利用実績」など)から参照する際は、
サロゲートキー(ID列)が利用情報を取得するためのキー(外部キー的な役割)を担うことになるのです。
(逆にサロゲートキーを用意しているのにそれを参照キーにしないのは、完全な無駄と言えそう・・・)
データもID列ベースで全て辿れるので、設計上の致命的なミスもありませんしね。
#サロゲートキー導入のメリット
サロゲートキー導入の一番のメリットは、
参照するためのキー(外部キー)を単純に出来る所です。
例えば6項目でようやくデータ上一意に定まる複合主キーを考えてみてください。
このテーブルに対して他のテーブルが参照キーを張る場合、
仮にサロゲートキーが導入されていなければ、
参照する側のテーブルも漏れなく6項目を持つ必要がありますよね?
1つのテーブルだけならいいですが、
万一複数テーブルを参照するテーブルで、
それぞれ複合主キーとなっている場合は、漏れなくその項目を参照側テーブルに用意しないとデータ整合性が保証できないため、
そのテーブル独自で用意するカラム以外のカラムが多くなり、
ぱっと見わかりにくいテーブルになってしまいますよね。
(流石に極端な例かとは思いますが)
#サロゲートキー導入のデメリット
もちろんいいことばかりでなく、
デメリットも抱えています。
それはサロゲートキーを用意することで、
本来の自然キーを表現できなくなる可能性を秘めていることです。
例えば利用テーブルが、
本来は事業所ID、利用者IDで一意であるとします。
この2つの項目に一意制約が張られていないと、
漏れなく重複データが出来上がってしまいます。
ならば一意制約を付ければ良いと考えると思いますが、これでも主キーの機能を果たすにはまだ足りません。
それは一意制約だけではNULLが許容されてしまうためです。
なので主キーと同等の働きをさせるには、一意制約、非NULL制約をつけてあげなければなりません。
これが1つ目のデメリットです。
もう1つのデメリットは、
何も考えずにサロゲートキーを適用すると機能がダブり完全な無駄なカラムとなる可能性を秘めていることです。
例えば顧客コードで完全に一意に定まるデータに対して、ID列を追加した場合を考えてみてください。
この時にIDが果たす役割に何か恩恵が感じられるでしょうか?
(※データのライフサイクルを管理したいという理由でIDを採番するのはありかと思いますがね)