このモデルはどのような通常の形で、なぜですか？

Question

正規化の理解に問題があります。誰かが、このリレーショナルモデルの標準形式とその理由を説明してください。

顧客（得意先（PK）、FirstNameとlastNameの、streetNo、通り、郊外、郵便番号、状態、にphoneNumber、EMAILADDRESS、オーダーID（FK））

注文（オーダーID（PK）、orderDateTime 、paymentStatus、productQuantity、のproductID（FK））

商品（のproductID（PK）、商品名、productDescription、currentUnitPrice、INSTOCK、ステータス、カテゴリID、カテゴリ名）

販売員（salesPersonID（PK）、のfirstName、lastNameの、電子メール、にphoneNumber、supervisorID（FK）、のorderID（FK））

OrderContents（orderContentsID（PK）、日付、割引、streetNo、ストリート、郊外、郵便番号、状態、paymentStatus）

パートナー（PARTNERID（PK）のcompanyName、streetNo、通り、郊外、郵便番号、状態とLastName、FirstNameとにphoneNumber、電子メール、orderContentsID（FK）、salesPersonID（FK））

Answer 1

私はあなたのスキーマは2NFではないと主張し、したがって1NFです。表を2NFにするには、主キーの列に部分的な依存関係があってはなりません。 Customersテーブルを検討してください。 customerIDにプライマリキーのラベルを付けましたが、実際には、これは機能しません。これは、特定の顧客が複数の注文を持つ可能性があるためです。実際には、主キーは(customerID, orderID)の組み合わせです。しかし、これは、顧客の住所の列（例： postCodeは、複合主キーに依存します。具体的には、同一の顧客アドレス情報が現れ、これは冗長な複数のレコードが存在する可能性がある。

スキーマの2NF（それの少なくとも一部）を作るために、あなたは新しい顧客とその注文の間だけの関係を格納するテーブルCustomerOrders、そして他には何を作成することができます。

CustomersOrders(customerID, orderID) (PK) 

その後、リファクタリングオーダーIDを削除することによって、あなたのCustomers表：それが現在立っているよう

Customers (customerID (PK), firstName, lastName, streetNo, street, suburb, postCode, 
      state, phoneNumber,emailAddress) 

だから、私はあなたのスキーマを信じては1NFですが、あなたは少しの作業で2NFにそれを持って来ることができるかもしれません。

2NFのreferenceは、あなたのスキーマによく似た例です。