エンティティリレーションシップダイアグラムでの自動車販売店コンテキストのモデリング
自動車販売店の概念データベースモデルを作成しています。私はクライアントに話しかけ、すべての要件を収集し、エンティティリレーションシップダイアグラムはすべて正しいと思いました。しかし、私は以下に詳述する要件をどのように表すかわからないことに気付きました。
シナリオの説明
ディーラーは車検と整備と修理。これが発生すると、サービスチケットが生成されます。 サービスチケットは顧客に属し、車両に関連しています、そして、次の要件があります（これは、私が地球上でどのように描くのか理解できない部分です）：
- サービスチケットには、1つ以上のサービス（エンティティタイプとして識別）、検査のいずれかを含めることができます（エンティティタイプとして認識される）および/または修理（エンティティタイプとして分類される）。
ご質問
私の興味のある文脈を説明した：
誰かが私に関係をモデル化する方法、およびデータベースでそれを維持する方法について正しい方向を教えてもらえますか？特定の
ServiceTicketが関連している必要があります少なくとも、 one特定Service、one特定Inspectionおよび/またはone決定Repair、さらに、multipleこれらの種類のエンティティのインスタンスも含まれている可能性がありますか？ServiceTicketにこれらのエンティティタイプの3つすべてのzeroオカレンスが含まれている可能性があるが、-少なくとも1つが含まれている必要があることをどのように表現しますか？
この問題は頭を悩ませてきました。最初、ServiceTicketとその3つの間に0対多のカーディナリティを定義しましたが、そのような描写は、少なくとも3つのうちの1つ。私の教科書では、この図に対する答えは何もないようです。優れたDBAになるには、これをどのように表現するかを知っている必要があると感じています。
サービス、検査、修理はすべて一部のworkのインスタンスです。本当にサービス、検査、修理が個別のエンティティとして必要な場合は、チケットと1 .. *の関係を持つスーパーエンティティWorkを作成し、サービス、検査、修理を継承しますそれ（1..1）。多くの場合、おそらくWorkがあり、Typeはservice、inspection、またはrepairのいずれかです。
それでは、次の名前のテーブルを作成します。Service_WorkとService_idを一意の識別子またはprimary_key制約として使用します。
このテーブル内のオブジェクトには、Inspections_Typeという名前が付けられており、foreign_keyは、Inspectionsテーブルを参照しており、Inspection_Ticketにはさまざまなタイプがあります。
検査が完了すると、Quote_Ticketが作成され、foreign_key関係がInspection_Ticketsに関連付けられます。顧客はこれを受け取り、修理を続行するか、修理しないかを決定します。
修理テーブルの場合、各repair_idは、primary_keyおよびService_Typeとしての異なる種類のService_idであり、Service_TimeおよびService_Costは、Final_Cost_Invoiceを顧客に提供するために使用できる属性です。
これらのアイデアがお役に立てば幸いです。私はあなたの質問が本当に好きで、このグループに参加してさらに共有することにします。