-1

私のテーブルは次のとおりです。

instructors(instructorID(PK), name, address, contact_details, pps_number,
            job_desc, specialty)
admin(adminID(PK), name, address, contact_details, pps_number, job_desc)
equipment(equipmentID(PK), type_of_equipment, last_used_by, class_used_for,
          date_used)
members(memberID(PK), name, address, contact_number, payment_type,
        membership_paid)
receipt(receiptID(PK), date_and_time, supplier) 
classes(classID(PK), weights, abs, core_strength)

誰かがこれらを正規化する方法を教えてもらえますか?

4

1 に答える 1

4

「鍵、鍵全体、そして鍵以外の何物でもない、だからコッドを助けてくれ」

それが 3NF テーブルに関する「ことわざ」です。簡単に言えば、各テーブルには主キー (1NF) が含まれている必要があります。2NF は「キー全体」です。これは、各テーブル内のすべての属性がテーブルの主キーに依存する必要があることを意味します。3NFは「鍵に他ならない」。非キー属性が「キー以外のもの」に依存することを要求すると、3NF が保証されます。これは、非キー属性が、特定のテーブルの主キー自体以外の属性に依存できないことを意味します。

例えば：

instructors(instructorID(PK), name, address, contact_details, pps_number, job_desc, specialty)

このテーブルには主キーがあるため、1NF に適合します。2NF は、すべての属性がキーに依存すると述べています。このテーブルでは、個人的には、エンティティと属性の関係に関する限り、job_desc と専門分野がインストラクター自体に依存しているとは思いません。このために、実際にその属性を新しいテーブルに分割します。

instructors(instructorID(PK), name, address, contact_details, pps_number, job_ID)
jobs(job_ID, job_desc, specialty)

インストラクター テーブルは 2NF に適合するようになりました。次に、第 3 正規形です。3NF は「キーに他ならない」ということです。これは、非キー属性が、特定のテーブルの主キー自体以外の属性に依存できないことを意味します。

インストラクターの属性を見てみましょう。instructorID(PK) - PK 自体。

name - インストラクター自身にのみ依存します。

住所 - インストラクター自身にのみ依存します。

contact_details - インストラクター自身にのみ依存します。

pps_number - これが何なのかわからないので、残すべきかどうかはわかりません。

job_ID - インストラクター自身にのみ依存します。

このテーブルは現在、3NF を満たしています。

これは、私がかなり役立つと思った正規化に関する追加情報です。

http://en.wikipedia.org/wiki/Third_normal_form

于 2014-01-03T13:46:15.367 に答える