次のリレーショナル スキーマを検討してください。
(第 3 正規形で) 完全に正規化し、機能の依存関係を特定しようとしています。ただし、無限の研究により、次の方法を回避することはできません。
- リレーショナル スキーマを完全に正規化する
- 機能依存関係の特定
これについてどうすればいいですか?
次のリレーショナル スキーマを検討してください。
(第 3 正規形で) 完全に正規化し、機能の依存関係を特定しようとしています。ただし、無限の研究により、次の方法を回避することはできません。
これについてどうすればいいですか?
従業員は顧客になることができ、いつかマネージャーになる可能性があります。パーティー モデルを使用します。「従業員」または「顧客」は当事者が果たす役割であるべきです。パーティーには多くの役割があります
人は住所を持たないことも、1 つの住所を持っていることも、複数の住所を持っていることもあります。複数のユーザーが同じアドレスを共有できます。Address テーブルと PersonAddress ジャンクション テーブルを使用します。電話番号も同じ。
おそらく、個人の顧客と組織の顧客 (会社または共有アカウント) が必要になるでしょう。パーティー モデルを使用します。
他のすべてのテーブルが id 列を使用しているのに、Branch が BranchId を使用しないのはなぜですか?
顧客が従業員に割り当てられていますか? 従業員が休暇中の場合はどうなりますか?
Branch の「市」と「町」はなぜですか?