では第一正規化 第二正規化 第３正規化 を学びます。
Contents
データベース – 第1正規形（1NF）
第1正規形（1NF）は、組織化されたデータベースの基本規則を設定します
- テーブル内のデータを作るため、必要なデータ項目を定義します。
- 関連するデータ項目をテーブルに配置します。
- 繰り返しデータグループがないことを確認します。
- 主キーがあることを確認します。
1NFの最初のルール
データ項目を定義する必要があります。これは、格納されるデータを調べ、データを列に整理し、各列に含まれるデータのタイプを定義し、最後に関連する列を独自のテーブルに配置することを意味します。
たとえば、会議の場所に関するすべての列をロケーションテーブルに、メンバーに関連する列をMemberDetailsテーブルに配置します。
1NFの第2ルール
次のステップは、データの繰り返しグループが存在しないようにすることです。次の表があるとします。
CREATE TABLE CUSTOMERS( ID INT NOT NULL, NAME VARCHAR (20) NOT NULL, AGE INT NOT NULL, ADDRESS CHAR (25), ORDERS VARCHAR(155) );
複数の注文を持つ単一の顧客に対してこの表を移入すると、次のようになります。
| ID | 名 | 年齢 | 住所 | 注文 |
|---|---|---|---|---|
| 100 | 中村 | 36 | 大阪区豊中 | キャノンXL-200 |
| 100 | 中村 | 36 | 大阪区豊中 | バッテリーXL-200 |
| 100 | 中村 | 36 | 大阪区豊中 | 三脚大 |
しかし、1NFごとに、データの繰り返しグループが存在しないようにする必要があります。したがって、上記の表を2つの部分に分けて、次のプログラムに示すようにキーを使用して結合してみましょう。
CUSTOMERSテーブル –
CREATE TABLE CUSTOMERS( ID INT NOT NULL, NAME VARCHAR (20) NOT NULL, AGE INT NOT NULL, ADDRESS CHAR (25), PRIMARY KEY (ID) );
このテーブルには、次のレコードがあります。要するに顧客情報はこれだけですね
| ID | 名 | 年齢 | 住所 |
|---|---|---|---|
| 100 | 中村 | 36 | 大阪区豊中 |
ORDERSテーブル -注文する方には３種目あるためIDがそれぞれのアイテムに振られてます
CREATE TABLE ORDERS( ID INT NOT NULL, CUSTOMER_ID INT NOT NULL, ORDERS VARCHAR(155), PRIMARY KEY (ID) );
この表には次のレコードがあります。
| ID | 顧客ID | 注文 |
|---|---|---|
| 10 | 100 | キャノンXL-200 |
| 11 | 100 | バッテリーXL-200 |
| 12 | 100 | 三脚大 |
1NFの第3ルール
最初の正規形の最終規則は、各テーブルのPrimaryキーを作成することです。
データベース – 第2正規形（2NF）
2番目の標準形式では、1NFのすべての規則を満たしている必要があり、主キーに列の部分的な依存性がない必要があります。
顧客と注文の関係を考慮して、顧客ID、顧客名、注文IDと注文の詳細、および購入日を保存したい 場合
CREATE TABLE CUSTOMERS( CUST_ID INT NOT NULL, CUST_NAME VARCHAR (20) NOT NULL, ORDER_ID INT NOT NULL, ORDER_DETAIL VARCHAR (20) NOT NULL, SALE_DATE DATETIME, PRIMARY KEY (CUST_ID, ORDER_ID) );
このような形になります。
この表は最初の正規形です。最初の正規形のすべての規則に従うという点で。この表では、主キーはCUST_IDとORDER_IDで構成されます
それらを組み合わせると、同じ顧客が同じことをほとんど注文しないと仮定すると、それらはユニークなIDとなります。
ただし、主キーと列の部分的な依存関係があるため、表は2番目の正規形ではありません。CUST_NAMEはCUST_IDに依存しており、顧客の名前と購入者の間に実際のリンクはありません。注文の詳細と購入日はORDER_IDにも依存しますが、CUST_IDとORDER_DETAILまたはSALE_DATE間にリンクがないため、CUST_IDに依存しません。
このテーブルを2番目の正規形に準拠させるには、列を3つのテーブルに分割する必要があります。
まず、以下のコードブロックに示すように顧客の詳細を格納するテーブルを作成します。
CREATE TABLE CUSTOMERS( CUST_ID INT NOT NULL, CUST_NAME VARCHAR (20) NOT NULL, PRIMARY KEY (CUST_ID) );
次に各注文の詳細を格納するテーブルを作成する
CREATE TABLE ORDERS( ORDER_ID INT NOT NULL, ORDER_DETAIL VARCHAR (20) NOT NULL, PRIMARY KEY (ORDER_ID) );
最後に、CUST_IDとORDER_IDだけを格納する3番目のテーブルを作成して、顧客のすべての注文を追跡します。
REATE TABLE CUSTMERORDERS( CUST_ID INT NOT NULL, ORDER_ID INT NOT NULL, SALE_DATE DATETIME, PRIMARY KEY (CUST_ID, ORDER_ID) );
データベース – 第3正規形（3NF)
次の条件が満たされている場合、表は第3正規形になります。
- 第2の正規形の条件がクリアされていること
- プライマリキー以外のすべてのフィールドは、プライマリキーと関係している
これらの非プライマリフィールドの依存関係は、データ間にあります。たとえば、次の表では、通りの名前、市区町村、市町村が郵便番号に縛られることはありません。
CREATE TABLE CUSTOMERS( CUST_ID INT NOT NULL, CUST_NAME VARCHAR (20) NOT NULL, DOB DATE, STREET VARCHAR(200), CITY VARCHAR(100), STATE VARCHAR(100), ZIP VARCHAR(12), EMAIL_ID VARCHAR(256), PRIMARY KEY (CUST_ID) );
郵便番号と住所の間の依存関係は推移的依存関係と呼ばれます。3番目の正規形を遵守するには、Street、City、およびStateの各フィールドを独自のテーブルに移動して、郵便番号テーブルという形で作ります。
CREATE TABLE ADDRESS( ZIP VARCHAR(12), STREET VARCHAR(200), CITY VARCHAR(100), STATE VARCHAR(100), PRIMARY KEY (ZIP) );
次のステップは、以下に示すようにCUSTOMERSテーブルを変更することになる。
CREATE TABLE CUSTOMERS( CUST_ID INT NOT NULL, CUST_NAME VARCHAR (20) NOT NULL, DOB DATE, ZIP VARCHAR(12), EMAIL_ID VARCHAR(256), PRIMARY KEY (CUST_ID) );
推移依存性を削除する利点は、主に2つあります。第1に、データの複製量が減少し、データベースが小さくなります。
2番目の利点は、データの完全性です。複製されたデータが変更されると、特にデータベース内のさまざまな場所に分散されている場合、一部のデータのみを更新する大きなリスクがあります。
たとえば、住所と郵便番号のデータが3つまたは4つの異なるテーブルに格納されている場合、郵便番号の変更は、その3つまたは4つのテーブルのすべてのレコードに波及する必要があります。
では次に参りましょう！ちょっと難しかったですね 笑
