これは、シリーズの第 3 部である、5 つの正規形です。最初の 2 つの部分 (チュートリアル) のタイトルは、最初の正規形で、その後に 2 番目の正規形が続きます。シリーズのこのパートでは、第 3 正規形について説明します。
説明はストーリーラインに従います。父親が亡くなり、息子にいくらかのお金を残しました。息子はそのお金をコンビニエンスストアに投資することにしました。コンビニエンス ストアとも呼ばれるコンビニエンス ストアは、サプライヤーから日用品を受け取り、近所の個々の顧客に販売する小さな小売業です。
この時点ですでに店頭に在庫があり、すでに一部の販売が行われています。ビジネスの所有者である息子には、このチュートリアルで店員と呼ばれる従業員がいます。所有者と従業員は、製品を記録した後、供給を受けて販売することができます。
しかし、店を始める前は、店主も従業員も正体について何も知りませんでした。そのため、彼らはすべてをトランザクションとして 1 つのテーブルと 1 つの練習帳に記録していました。彼らはコンピューターを持っていませんでした。
読者であるあなたは、このチュートリアル シリーズの 5 つのパートを完了しました。あなたはデータベース開発者です。コンビニのオーナーはあなたの友達です。あなたは 2 日前にその店を訪れ、最初の通常の形でテーブルを作成する方法を経営者と店員に教えました。また、昨日ショップを訪れ、最初の正規形から 2 番目の正規形でテーブルを作成する方法をトレーニングしました。
今日、あなたはショップを訪問して、2 番目の正規形から 3 番目の正規形のテーブルを作成する方法をトレーニングしました。彼らが現在持っているすべての表は、第 2 正規形です。テーブル (名前と列見出し) は次のとおりです。
商品(商品ID、カテゴリID、商品)
カテゴリー(categoryID、カテゴリー)
Sales(saleID、顧客、従業員、日付)
SaleDetails(saleID, productID, numberSold, SellingPrice)
注文（注文ID、サプライヤー、従業員、日付）
OrderDetails(注文ID、商品ID、購入数、価格)
単一キーまたは複合キーには下線が引かれています。
過去 2 日間に教えられたことを要約した後、何もできないようになる前に、所有者は次のように尋ねます。
「顧客や従業員の電話番号、住所などはどうですか?
製品の在庫数、再注文レベルなどはどうですか?
それらには独自の別個のテーブルが必要ですか、それとも現在のテーブルに適合させる必要がありますか?」
データベース開発者であるあなたは、次のように答えます。
「おめでとう、店長！あなたは間接的に第 3 正規形の問題を提起しました。」
あなたは続けます。
その他必要な列
他の必要な列は、1NF と 2NF にある前のテーブルに最初に追加されます。以前の列名の一部が変更されています。
少なくとも、カテゴリ テーブルには次の列が必要です。
カテゴリー(カテゴリーID、カテゴリー名、説明)
説明は、カテゴリを説明する短い段落です。このカテゴリ テーブルは、1NF、2NF、および 3NF に既に存在します。 3NF については、次のように説明されています。
Products テーブルには、少なくとも次の列が必要です。
製品(productID、categoryID、supplierID、productName、unitPrice、quantityInStock、reorderLevel)
各製品が販売されているため、製品を再注文する必要があるときに製品のレベル (数) が低くなるため、顧客が店に来て製品を持たないようにする必要があります。そのような欠席はビジネスにとって良くありません。 quantityInStock は、特定の商品の在庫数です。これには、店舗にあるものと棚にあるものが含まれます。
categoryID と supplyID は外部キーです。そのため、一重下線ではなく破線の下線が付けられています。外部キーについては後述します。シリーズの前の部分 (第 2 正規形) では、categoryID は主キーの一部であり、到達方法により 1 つの下線が引かれていました。ただし、以下の説明から、categoryID が外部キー (破線の下線付き) であることは明らかです。
この製品テーブルは、1NF、2NF、および 3NF に既に存在します。以下の 3NF にある理由を参照してください。
少なくとも、SaleDetails テーブルには次の列が必要です。
SaleDetails(saleID、productID、unitSellingPrice、数量、割引)
ほとんどの場合、割引値はゼロであると予想されます。割引とは、ショップが顧客に提供する割引です。
OrderDetails テーブルには、少なくとも次の列が必要です。
OrderDetails(orderID、productID、unitCostPrice、数量、割引)
ほとんどの場合、割引値はゼロであると予想されます。ここでの割引は、サプライヤーがショップに与える割引です。
以下に示すように、Products テーブルは 2NF または 3NF と見なすことができます。 Sales テーブルと Order テーブルには 3NF の問題があります。問題と解決策の説明には、Sales テーブルのみを使用します。 Orders テーブルと Products テーブルの 3NF も同様の理由で引用されます。
列を追加すると、Sales テーブルは次のようになります。
売上 (saleID, dateSold customerName, phone, address, city, region, postCode, Country, employee)
元のテーブルの customer 列が 7 つの列に置き換えられました。顧客は近隣の人々であるため、都市、地域 (州)、郵便番号、および国の列のセルは空のままにすることができますが、この記事では空のままにしません。
1NF と 2NF の両方のルールに違反していないため、この Sales テーブルはまだ 2NF にあります。ただし、Sales テーブルの行では、顧客 (名前) が 7 つの顧客行のセルに置き換えられていることに注意してください。
注: 住所セルには、番地、通りまたは道路の名前、町の名前がすべてコンマで区切られています。都市は、いくつかの町で構成されていると見なすことができます。これらの特定の文字列コンポーネントはカンマで区切られていますが、3 つのセル値ではなく、1 つのセル値を形成します。
また、employee 列も 7 つの列に置き換える必要があります。ただし、教育の時間とスペースを節約するために、このチュートリアルではそれを行いません。したがって、データを含む Sales テーブルは次のようになります。
Sales テーブル – 2NF – customerID なし
データ型 SaleID 列は整数、またはより適切には自動インクリメントです。 dateSold 列のデータ型は数字ではなく日付です。これは、数字ではない文字「/」が含まれているためです。 phone 列を含む残りの列のデータ型は文字列 (またはテキスト) です。電話の値には、数字ではない文字「-」が含まれています。
シリーズの前の部分と同様に、各行で customer (name) が 7 つのセルに置き換えられていることに注意してください。そのうちの 1 つはまだ customer-name です。これは、顧客データがエンティティであることを意味します。現在、customer-name は、他の 6 つのデータを続けて識別します。このテーブルがプログラムされている場合、各行の顧客エンティティを整数 (自動インクリメントではない) で識別すると便利です。その場合、customerID 列が customerName の前にある必要があります。前の表は次のようになります。
Sales テーブル – 2NF – customerID あり
1、2、および 3 の 3 つの customerID があり、John Smith の場合は 1 が 5 回、James Taylor の場合は 2 が 2 回、Susan Wright の場合は 3 が 1 回発生します。
一部の customerID とその依存先が繰り返されることに注意してください。
第 3 正規形の規則
次の規則に従う場合、テーブルは第 3 正規形です。
- すでに第 2 正規形になっているはずです。
- また、推移的な依存関係を持つべきではありません。
すると、事務員（従業員）の一人が「推移的な依存関係とは何ですか？」と尋ねます。そして、データベース開発者であるあなたは、「それは良い質問です!」と答えます。
推移的な依存関係
確かに、SaleID は行内のすべての値を識別します。ただし、customerID はその 7 つのデータ値を識別しますが、その行の SaleID によって識別される残りの値は識別しません。別の言い方をすれば、SaleID は各行の 10 個のセル値に依存します。ただし、customerID は同じ行の 7 つのセル値に依存しますが、customerID は、SaleID および SaleID が依存する他の値には依存しません。
このような customerID の依存関係は、推移的な依存関係です。また、customerID は外部キーと呼ばれ、このチュートリアル シリーズ The Five Normal Forms ではダッシュの下線が引かれています。
非主要属性 (非主要セル値) が他の非主要属性に依存し、問題の非主要属性 (たとえば、customerID とその依存先) が主キーとセルの残りの部分に依存していないとします。行の値。次に、それは推移的な依存関係です。
外部キーとその依存先を持つ以前の Sales テーブルは、会計上の問題 (異常) を引き起こします。
2NFから3NFまでの販売表
外部キーとその依存先によって引き起こされる問題を解決するには、外部キーとその依存先を削除して、繰り返しのない新しいテーブルを形成します。ただし、外部キーが主キーに依存していなくても、主キーは外部キーに依存しています。したがって、外部キーのコピーは親テーブルに残す必要があります。この時点で、新しい販売テーブルは 1NF、2NF、および 3NF に準拠しています。親テーブルです。前の Sales テーブルの新しい子テーブルも、1NF、2NF、および 3NF に準拠しています。外部キーとその依存先を持つ子テーブルの名前は、Customers です。適切な名前が見つからない場合は、分析で何か問題が発生しています。 3NF の新しい Sales テーブルは次のとおりです。
3NFの最終販売表
3NF のこのテーブルには、2NF のテーブルと同じ数の行がありますが、列が少なくなっています。
3NF でのこの最終的な Sales テーブルのテーブル表記は次のとおりです。
Sales(saleID、dateSold、customerID、employeeID)
saleID は、1 つの下線が付いた主キーです。 customerID は、ダッシュの下線が付いた外部キーです。 employeeID もダッシュ下線付きの外部キーです。 2NF の Sales テーブルの従業員の状況は、顧客の状況と同じであることに注意してください。別のテーブルを形成するには、employeeID とその依存先を切り離す必要があります。 employeeID のコピーが残ります。
注: salesID、customerID、および employeeID は複合キーを形成しません。 saleID は、customerID と employeeID に依存しています。
saleID と customerID の関係は多対 1 です。
3NF の顧客テーブル
このテーブルには、2NF Sales テーブルの 9 行ではなく 3 行があります。このテーブルでは、customerID が主キーです。これは Sales テーブルの外部キーと同じですが、繰り返しはありません。 Sales テーブルの外部キーと Customer テーブルの主キーは、両方のテーブルをリンクします。
1NF に違反しないように、Customer テーブルで繰り返される行は削除されています。
ご覧のとおり、テーブルを 3NF に配置すると、行の繰り返し (冗長性) の問題も解決されます。
Customers テーブルのテーブル表記は次のとおりです。
顧客 (顧客 ID、顧客名、電話番号、住所、都市、地域、郵便番号、国)
Products テーブルの再検討
上記の表記形式の製品テーブルは次のとおりです。
製品(productID、categoryID、supplierID、productName、unitPrice、quantityInStock、reorderLevel)
ここでの主キーは productID です。 categoryID と supplyID は外部キーです。 Customer テーブルと同様に、categoryID が主キーである Categories テーブルと、supplierID が主キーである Supplier テーブルがあります。
unitPrice、quantityInStock、および reorderLevel のセルの値が固定のままである場合、Products テーブルはそのままで真に 3NF です。これらの値が変更される場合、Products テーブルはそのまま 2NF になります。チュートリアル シリーズのこの部分では、これらの値は時間の経過とともに固定されていると想定しています。
すべてのテーブル
すべてのテーブルが 3NF になりました。それらは次のように示されます。
従業員 (employeeID、名前、電話番号、住所、都市、地域、郵便番号、国、生年月日、雇用日、リリース日)
サプライヤー (サプライヤー ID、名前、電話番号、住所、都市、地域、郵便番号、国)
製品(productID、categoryID、supplierID、productName、unitPrice、quantityInStock、reorderLevel)
カテゴリー(カテゴリーID、カテゴリー名、説明)
Sales(saleID、dateSold、customerID、employeeID)
SaleDetails(saleID, productID, numberSold, SellingPrice)
顧客 (顧客 ID、顧客名、電話番号、住所、都市、地域、郵便番号、国)
注文 (orderID、dateSold、supplierID、employeeID)
OrderDetails(注文ID、商品ID、購入数、価格)
冗長性とアカウンティングの問題 (挿入、削除、および更新による異常) を防ぐために、初心者が作成した 1 つのテーブルから最大 9 つの専門的なテーブルが作成されました。初心者のテーブルだけでは、経済的損失につながります。
スタッフのテスト
この時点で、経営者を含むすべての従業員は、1NF、2NF、および 3NF を理解しているはずです。ただし、それらはテストする必要があります。所有者を含む全員が異なる場所に座ってテストを完了します。 1 問のテストで、所要時間は 1 時間です。内容は次のとおりです。
問題: 1NF、2NF、および 3NF のルールを使用して、上記の 9 つの表すべてが既に第 1 正規形、第 2 正規形、および第 3 正規形であることを証明してください。顧客とサプライヤーは実体である必要はありません。表のデータは、表の表記をバックアップする必要があります。
彼らがテストを完了している間、あなたはデータベース開発者として、スナックとビールを飲みに出かけ、1 時間後に戻ってきます。
近未来と遠未来
データベース開発者であるあなたが外出している間に、全員がテストに合格した場合にどのようなアドバイスを与えるかについても検討します。
また、あなたが彼らを訓練している間、そして彼らがテストを受けている今、顧客はサービスを受けずに出入りしています。それはビジネスにとって良くないことであり、データベース開発者であるあなたはそれを知っています。一部の顧客は、競合店に行って二度と戻ってこない場合があります。
データベース開発者であるあなたは 30 歳です。友人である店主も30歳。事務員（従業員）は 18 歳から 24 歳までの年齢層です。経営者のために働くために必要なすべての資質は、健康であること、読み書きができること、足し算、引き算、掛け算、割り算ができることでした。 、およびコンピュータとインターネットを使用できること。
テーブルが 3NF にある場合、ほとんどの脆弱性はデータベースから削除されています。多くの商用データベースは 3NF を超えておらず、企業や企業は快適です。
したがって、全員がテストに合格した場合は、店員に行って作業を続けるように依頼します。また、コンビニエンス ショップを所有できるように、給料の一部を貯蓄するようにアドバイスします。明日も引き続き、4NFと5NFで店主のみの調教です。 4NF と 5NF の知識があれば、既知の脆弱性はすべて排除されます。
評価
1 時間後、データベース開発者であるあなたが戻ってきます。あなたは彼らのスクリプトをマークします。素晴らしいニュースです！所有者を含め、全員がそれぞれ100％を持っています。万歳！それは素晴らしいです！
先生と生徒の皆さん、おめでとうございます。
このチュートリアルでは、結論を出す以外に何もする必要はありません。
結論
次のルールのいずれにも違反していない場合、テーブルは第 1 正規形です。
- テーブル内のすべての列には、一意のヘッダー名が必要です。
- 各セルの値は 1 つだけである必要があります。
- 列に格納される値は同じ型である必要があります。
- 行は別個である必要があります。
- 列または行の順序は重要ではありません。
次の規則のいずれにも違反していない場合、表は第 2 正規形です。
- テーブルは既に第 1 正規形になっている必要があります。
- 部分依存があってはなりません。
次の規則のいずれにも違反していない場合、テーブルは第 3 正規形です。
- すでに第 2 正規形になっている必要があります。
- また、推移的な依存関係があってはなりません。
データベース開発者であるあなたは、店員に十分に学習したことを伝えます。アドバイスを提供し、デフォルトで仕事に戻ってステーションにとどまるように依頼します。
明日、4NF と 5NF のトレーニングのために彼のオフィスで行われるように、所有者のみと予約を設定します。
