データベースを設計するとき、繰り返しデータセットを別のテーブルにシフトする傾向があることに気づきました。たとえば、私が人々のテーブルを持っていて、各人が州に住んでいるとしましょう。次に、これらの繰り返し状態を別のテーブルに移動し、外部キーで参照します。
ただし、州に関するデータをこれ以上保存していなかった場合はどうなりますか。次に、StateIDとStateが入ったテーブルを作成します。このアクションは正しいですか？状態はusersテーブルの主キーに依存しているので、それを独自のテーブルにシフトすることは何かに役立ちますか？
ありがとう、
テーブルを第2正規形に配置するプロセスでは、テーブル内の繰り返しデータのサブセットを削除して、それらを独自のテーブルに配置する必要があると思います。
状態の省略形を独自のテーブルに移動することは、データベースを正規化する方法です。これは、「ユーザー」テーブルを更新の異常から保護します。たとえば、何らかの理由でケンタッキーの略語「KY」が「KQ」に更新されたとします。状態テーブルの主キーを含むユーザーテーブルに外部キーを配置することにより、すべてのユーザーのこのエントリを修正するために、状態テーブルを1回更新するだけで済みます。
そうは言っても、州の略語が頻繁に変更されないことは私たちには非常に明白に思えます。したがって、データベースに状態に関する詳細情報を格納する必要がないという事実を知っている場合は、状態フィールドをユーザーテーブルに残すことは論理的で基本的に適切です。そのような非正規化は一般的です。これにより、ユーザーテーブル内のデータの可読性が向上し、結合を実行するオーバーヘッドが削減されます。しかし、それは好みです。
Stateテーブルは、usersテーブルとキーの関係を持たないようにする必要があり、状態に関するデータのみを含める必要があります。
各テーブルを可能な限り単純に保つために、ユーザーデータをユーザーテーブルに保持し、状態データを状態テーブルに保持してから、ユーザーとの両方に対して外部キー関係を持つ結合テーブルを作成することができます。状態テーブル。
つまり、正規化の形式についてはわかりません。