0または1から0または1の関係をモデル化する？それは事ですか？

Question

私は、作業しているリレーショナルデータベースの正しいデザインを見つけようと壁を打ちました。

定義：

• クライアント：サービスを取得するために、ショップに入ってくる人。
• ユーザー：クライアントが要求するサービスを実行するユーザー。
• 予約：特定の時点で店舗の場所にいるというクライアントとユーザーの間の合意。
• ショップ： サービスを提供しているユーザーのセット。
• サービス：私はサポートしようとしている技術的なプロセス

ユースケース：

• クライアントがショップを呼び出し、 ユーザーからサービスを取得する予定を設定します。
• クライアントがショップの場所に移動し、 ユーザーからのサービスが必要です。

問題： Aサービスは、クライアントとユーザーとの関係を持っていますが、これもサービスに関連している（1が実際に存在する場合）の予定はありません。

アポイントメントが作成された場合、アポイントメントは実際には通っていない可能性があるため、空のサービスを作成することはできません。サービスには、予定。また、サービスは、ユーザー、クライアント、および予定がある場合にのみサービスではなく、有効なサービスであるためには他の属性が必要です。

私はAppoitmentとServiceの両方でUserとClientを繰り返すことが正しいとは思えません。これは、将来的に何らかの整合性の問題があるかもしれないからです。

この問題にはどのようなアプローチが適していますか？

Answer 1

私は次のように始まり、新しいビジネスルールが登場したときに適応します。

まず、クライアントの「ベース」のテーブル、Shopes、ユーザー、およびサービス（行うことができる作業）

CLIENT 
ClientId 
Name 
ContactInformation 

SHOP 
ShopId 
Name 
OtherAttribues 

USER 
UserId 
ShopId 
Name 
Etc 

(Note: Assumes a user works in only one shop, otherwise you need a many-to-many 
    table joining SHOP and USER. See further reminders below.) 

SERVICE 
ServiceId 
Name 
FurtherAttributes 

(This is the “master list” of all available services that can be done. “ServiceEvent” 
    is used to record actual work being done.) 

次に、複雑な表：

SERVICEEVENT 
ServiceEventId 
ClientId (who the work was done for) 
UserId (who did the work work. Add ShopId if a User can work in multiple shops) 
ServiceId (what work was done) 
FurtherAttributes (time, cost, etc.) 

(This is used to record actual work that was done--or perhaps, is being done?) 

APPOINTMENT 
AppointmentId 
ClientId (who the work will be done for) 
UserId  (who will be doing the work. Add ShopId if a User can work in multiple shops.) 
ServiceId (What work will be done) 
ServiceEventId NULLABLE (the ServiceEvent, if any, produced by this Appointment) 
Status  (indicate pending, cancelled, completed, etc.) 
FurtherAppointmentAttributes (when the appointment was made, etc.) 
FurtherServiceEventAttributes (optional? data used to populate ServiceEvent, when it comes time to do so) 

(Should consider creating a lookup table for "Status".) 

「アポイントメント"と" ServiceEvent "は本当に2つの異なるものです。それらは似ていますが、それぞれが他のもの（キャンセルされた予定、ウォークインサービスイベント）なしで存在することができるので、両方ともすべてのキーが必要です。アポイントメントを介して生成されたServiceEventは、アポイントメントからデータを読み込み、それをServiceEventに挿入するルーチンによって作成されます。

これらの間のリンク（外部キー）はいずれのテーブルにもあり得ます。理想的にはすべての予定がServiceEventを生成するので、私はAppointmentに入れますが、その逆は真実ではありません。