リレーショナルデータベーステーブル、データの重複の危険？

Question

ここに...私は飛行機のチャーター会社のための仮想的なデータベースを作成しようとしていると私は私が従業員のために作成する必要がありますどのように多くのテーブルの上に立ち往生少しだが、問題への基本的な導入である：

従業員は従業員が多く、従業員は乗組員と非乗員で構成され、乗組員はパイロット、乗務員、飛行エンジニア、ロードマスターであり、非乗員は管理者、受付係などがあります。すべての従業員が乗組員で​​はありません。

すべての乗組員は医療検査を頻繁に受ける必要があり、これらの検査の記録を保存する必要があります。すべての乗組員にも免許と認定が必要です。これらの免許と認定の詳細は保存する必要があります。

フライトが予約されている場合、航空機の種類と予約の種類によって、少なくとも1人の乗組員が予約に割り当てられます。したがって、小型航空機の場合、1人のパイロットだけが乗組員で​​す。しかし、それがジェット機なら、2人のパイロットと乗組員が乗組員を形成します。

私の問題はこれです。クルーとクルー以外の従業員で構成されたテーブルと、ライセンス/認定と医療検査の別の2つのテーブルを作成する必要がありますか？ （ライセンス/認証と医療のテストテーブルを持つ従業員表を関係）

それとも

私だけにライセンス/認証と医療のテストテーブルを割り当て、すべての従業員と乗組員のための別のテーブルで基本的なテーブルを作成する必要があります乗組員のテーブル？このようにして、乗組員は乗組員以外のメンバーから分離されるので、乗組員と医療および認証テーブルの関係は、従業員テーブル全体から切り離すことができます。ここでデータの重複が心配です。

事前に感謝します。

Answer 1

「すべきか」という質問は、モデルをよく理解していなくても、それを使用するつもりはありません。最初の質問は、単にダイアグラムに示されているモデルを実装するだけではないという理由です。この図は、最初のオプションが意図されていることを示しています。しかし、従属表は意図/使用法がかなり暗いです。

• すべての乗組員が同じテストを受け、同じ認定を取得する必要はありません。
• テーブルに「フラグ」列（license_or_test）が表示されると、IMOに問題が発生します。
• 図に基づいて、Crewの主キーはEmployeeと同じです。それは従属テーブルにも流れていなければなりません。
• 予約が特定の顧客に関連付けられている場合、テーブルにcompany_idを含める必要はありません。
• お客様がFK to Companyを持っている場合、航空会社はどうしてですか？
• あなたは飛行について議論しますが、あなたのスキーマでそれを表現するものは何もありません。おそらくそれがあなたがBookingsの意味ですか？次の項目を参照してください。
• あなたの決定にかかわらず、一致してください。乗務員以外のテーブルには複数の名前を使用します。あなたは乗組員という言葉も使います。フライトと予約。

さらに、飛行に依存するスキーマを単純化したと付け加えます。特定のフライトでは、特定のメンバーで構成される「クルー」があります。通常、これは複数の従業員（パイロット、副操縦士など）で構成されます。ライセンスの問題に取り組むことで、パイロットはフライトの副操縦士として機能することができます。私はEmployee_IDがBookingsに入っている理由を理解していませんが、多分あなたは別の用途を考えています。

アプローチを選んでどこに行くかをお勧めします。または両方を行う。同じモデルを表す異なるスキーマを共同で共同作業することで、より多くのことを学ぶことができます。