この例の SQL データベースのテーブルをどのように設計すればよいか、少し混乱しています。
私はCustomerエンティティを持っています。顧客は多くのPetエンティティを所有できます。すべてのペットには独自の が必要MedicalHistoryです。しかし、一部のペットは女性なので、FemaleMedicalHistory. 最後に、すべての FemaleMedicalHistory に多くのBirthレコードを含めることができます。
同じフィールドに加えて、テーブルを指す何かを含む のサブクラスFemaleMedicalHistoryのようです。これは正しいですか？MedicalHistoryBirth
これらの関係をテーブルにどのようにモデル化しますか? MedicalHistory&FemaleMedicalHistoryテーブルは同じ主キー (例: mid) を共有する必要がありますか?
編集：
これは私が念頭に置いていたものでしたが、それが適合するかどうかはわかりません：
@LePhleg：「medical_history」はそれ自体では非常に悪い考えであり、これにより「medical_history_female」テーブルを定義することになりました。少数のフィールド (mid、pid、curdate、治療の種類、および詳細) のみを含むテーブルを作成し、多数の行を含むテーブルを作成することをお勧めします。各行は、各ペットの治療記録になります。この構造により、「medical_history_female」テーブルと「births」テーブルの両方が不要になります。出産は、(新しい) 病歴に保存されるイベントです。
したがって、1 匹の動物 (雌犬としましょう) について、medical_history テーブルにいくつかのイベントが存在する可能性があります。
私はKISSの原則に従っているので、ペットと出生記録の間で1対多として設計します-出生表にはペットに関する情報が含まれていますが、医療履歴ではありませんか? また、「誕生」とは？私はテーブルとその属性にもっと意味のある名前を付けます.テーブル/属性名にすべての文字を保存しようとするのは20世紀です.