*** 各種正規化の基本情報
- 正規形の種類
- 非正規形
- 第1正規形 (1NF)
- 第2正規形 (2NF)
- 第3正規形 (3NF)
- ボイスコッド正規形 (BCNF)
- 第4正規形 (4NF)
- 第5正規形 (5NF/PJNF)
- 非正規形の例
注文テーブル
| 注文番号 | 注文日時 | 商品ID | 商品名 | 単価 | 数量 | 金額 | 合計金額 | 消費税 | 顧客ID | 名前 | 電話番号 | 支払い方法 |
|----------+----------+--------+------------+--------------+-------+--------------+----------+--------+--------+----------+--------------+------------|
| 101 | 2009-8-1 | 1 3 5 | 砂糖 塩 米 | 500 500 1000 | 1 1 1 | 500 500 1000 | 2000 | 100 | P02 | 山田花子 | 03-4567-8901 | クレジット |
| 102 | 2009-8-1 | 6 | 味噌 | 700 | 1 | 700 | 700 | 35 | P05 | 田中太郎 | 012-345-6789 | 代引 |
| 103 | 2009-8-2 | 6 5 | 味噌 米 | 700 1000 | 1 2 | 700 2000 | 2700 | 135 | P10 | 鈴木一浪 | 04-5678-9012 | クレジット |
- これが第一正規形でない理由
- 商品IDや商品名などについて、単一のフィールド
に複数の値が入っている。これを繰返しグループ
と呼ぶ。繰返しグループがあると非正規形である
と見做す。
- 第一正規形を作る手順
- 1. テーブルにキーを設定する。
- 2. テーブルの繰返しグループを別のテーブルに分
離する。
- 3. 導出項目を削除する。
- 第一正規形の例
注文テーブル
| 注文番号 | 注文日時 | 顧客ID | 名前 | 電話番号 | 支払い方法 |
|----------+----------+--------+----------+--------------+------------|
| 101 | 2009-8-1 | P02 | 山田花子 | 03-4567-8901 | クレジット |
| 102 | 2009-8-1 | P05 | 田中太郎 | 012-345-6789 | 代引 |
| 103 | 2009-8-2 | P10 | 鈴木一浪 | 04-5678-9012 | クレジット |
キー : 注文番号
注文明細テーブル
| 注文番号 | 商品ID | 商品名 | 単価 | 数量 |
|----------+--------+--------+------+------|
| 101 | 1 | 砂糖 | 500 | 1 |
| 101 | 3 | 塩 | 500 | 1 |
| 101 | 5 | 米 | 1000 | 1 |
| 102 | 6 | 味噌 | 700 | 1 |
| 103 | 6 | 味噌 | 700 | 1 |
| 103 | 5 | 米 | 1000 | 2 |
キー：{注文番号,商品ID}
- これが第二正規形でない理由
- 部分関数従属が存在する。部分関数従属とは、キー
の一部で確定する非キー属性が存在するというこ
と。
- ここでは、キーの一部である商品IDが決まれば商
品名と単価は決まってしまうということ。
- 第二正規形の例
注文テーブル
| 注文番号 | 注文日時 | 顧客ID | 名前 | 電話番号 | 支払い方法 |
|----------+----------+--------+----------+--------------+------------|
| 101 | 2009-8-1 | P02 | 山田花子 | 03-4567-8901 | クレジット |
| 102 | 2009-8-1 | P05 | 田中太郎 | 012-345-6789 | 代引 |
| 103 | 2009-8-2 | P10 | 鈴木一浪 | 04-5678-9012 | クレジット |
キー : 注文番号
注文明細テーブル
| 注文番号 | 商品ID | 数量 |
|----------+--------+------|
| 101 | 1 | 1 |
| 101 | 3 | 1 |
| 101 | 5 | 1 |
| 102 | 6 | 1 |
| 103 | 6 | 1 |
| 103 | 5 | 2 |
キー：{注文番号,商品ID}
商品テーブル
| 商品ID | 商品名 | 単価 |
|--------+--------+------|
| 1 | 砂糖 | 500 |
| 3 | 塩 | 500 |
| 5 | 米 | 1000 |
| 6 | 味噌 | 700 |
キー：{商品ID}
- これが第三正規形でない理由
- 推移関数従属がある。推移関数従属とは非キーど
うしの間に関数従属性があること。
- この例では、注文テーブルについて、顧客IDが決
まれば、名前などは定まる、というところ。
- 第三正規形の例
注文テーブル
| 注文番号 | 注文日時 | 顧客ID | 支払い方法 |
|----------+----------+--------+------------|
| 101 | 2009-8-1 | P02 | クレジット |
| 102 | 2009-8-1 | P05 | 代引 |
| 103 | 2009-8-2 | P10 | クレジット |
キー : 注文番号
顧客テーブル
| 顧客ID | 名前 | 電話番号 |
|--------+----------+--------------|
| P02 | 山田花子 | 03-4567-8901 |
| P05 | 田中太郎 | 012-345-6789 |
| P10 | 鈴木一浪 | 04-5678-9012 |
キー : 顧客ID
注文明細テーブル
| 注文番号 | 商品ID | 数量 |
|----------+--------+------|
| 101 | 1 | 1 |
| 101 | 3 | 1 |
| 101 | 5 | 1 |
| 102 | 6 | 1 |
| 103 | 6 | 1 |
| 103 | 5 | 2 |
キー：{注文番号,商品ID}
商品テーブル
| 商品ID | 商品名 | 単価 |
|--------+--------+------|
| 1 | 砂糖 | 500 |
| 3 | 塩 | 500 |
| 5 | 米 | 1000 |
| 6 | 味噌 | 700 |
キー：{商品ID}
- これがボイスコッド正規形でない理由
- 理由はない。これはボイスコッド正規形でもある。
- 第三正規形のほとんどがボイスコッド正規形でも
ある。
- 第三正規形だがボイスコッド正規形ではない例
注文明細テーブル
| 注文番号 | 商品ID | 数量 | 商品検査担当 |
|----------+--------+------+--------------|
| 101 | 1 | 1 | たろう |
| 101 | 3 | 1 | じろう |
| 101 | 5 | 1 | さぶろう |
| 102 | 6 | 1 | しろう |
| 103 | 6 | 1 | ごろう |
| 103 | 5 | 2 | とめきち |
キー：{注文番号,商品ID}
- 次のビジネスルールとする。
- 一つの注文番号には複数の商品が含まれる。
- 商品検査担当各人は、各自担当する商品IDはひ
とつとする。ひとつの商品IDについて、複数の
商品検査担当がいることはある。
- 一つの注文番号に同じ商品が複数個含まれると
きは、同じ商品IDについては一人の商品検査担
当者が担当する。
- このテーブルがBCNFでない理由。
- 非キー属性からキー属性への関数従属がある。
- すなわち、商品検査担当が決まると、商品IDが
決まる。
- BCNFの例
注文明細テーブル
| 注文番号 | 数量 | 商品検査担当 |
|----------+------+--------------|
| 101 | 1 | たろう |
| 101 | 1 | じろう |
| 101 | 1 | さぶろう |
| 102 | 1 | しろう |
| 103 | 1 | ごろう |
| 103 | 2 | とめきち |
キー：{注文番号,商品ID}
商品検査担当テーブル
| 商品検査担当 | 商品ID |
|--------------+--------|
| たろう | 1 |
| じろう | 3 |
| さぶろう | 5 |
| しろう | 6 |
| ごろう | 6 |
| とめきち | 5 |
キー：{商品検査担当}
- さて、この例が第四正規形でない理由
- これは第四正規形ではない。
- 第四正規形はテーブルの全ての属性がキーである
場合、すなわち、テーブル間の関連を規程するテー
ブルについての話だからだ。第五正規形も同じ。
- この例はそもそもそういうテーブルが無いので、
第四正規形ではない。
- 第四正規形ではない例
チーム-メンバ-道具関連テーブル
| チーム名 | メンバー名 | 道具名 |
|----------+------------+--------------|
| サクラ | 鈴木 | ポンポン |
| サクラ | 田中 | ポンポン |
| モモ | 佐々木 | バトン |
| サクラ | 鈴木 | ユニフォーム |
| モモ | 山本 | ユニフォーム |
| サクラ | 田中 | ユニフォーム |
| モモ | 山本 | バトン |
| モモ | 佐々木 | ユニフォーム |
キー：{チーム名,メンバー名,道具名}
- これは、現実を調べると、チーム名が決まれば、
メンバーがもつべき道具は決まるという状況であ
るとする。
チーム-メンバ-道具関連テーブル
| チーム名 | メンバー名 | 道具名 |
|----------+------------+--------------|
| サクラ | 鈴木 | ポンポン |
| サクラ | 鈴木 | ユニフォーム |
| サクラ | 田中 | ポンポン |
| サクラ | 田中 | ユニフォーム |
| モモ | 佐々木 | バトン |
| モモ | 佐々木 | ユニフォーム |
| モモ | 山本 | バトン |
| モモ | 山本 | ユニフォーム |
キー：{チーム名,メンバー名,道具名}
- そこで次のように分解するのが第四正規化。
チーム-メンバ関連テーブル
| チーム名 | メンバー名 |
|----------+------------|
| サクラ | 鈴木 |
| サクラ | 田中 |
| モモ | 佐々木 |
| モモ | 山本 |
キー：{チーム名,メンバー名}
チーム-道具関連テーブル
| チーム名 | 道具名 |
|----------+--------------|
| サクラ | ポンポン |
| サクラ | ユニフォーム |
| モモ | バトン |
| モモ | ユニフォーム |
キー：{チーム名,道具名}
- さて、第五正規化も関連テーブルについてである。
第四正規化とは別の状況についての正規化である。
チーム-会場-演目関連テーブル
| チーム名 | 会場 | 演目 |
|----------+------+----------------|
| チームA | 東京 | ポンポンダンス |
| チームA | 東京 | ブレイクダンス |
| チームB | 福岡 | チアリーダ |
| チームA | 静岡 | ポンポンダンス |
| チームB | 東京 | ブレイクダンス |
キー：{チーム名,会場,演目}
- この状況だとキーのすべての属性が決まらないとデー
タを投入できない。そこで決まった情報から投入で
きるようにするにはどういう分割をすればいいかと
いうのが第五正規化。答は次のとおり。
チーム-会場関連テーブル
| チーム名 | 会場 |
|----------+------|
| チームA | 東京 |
| チームB | 福岡 |
| チームA | 静岡 |
| チームB | 東京 |
キー：{チーム名,会場}
チーム-演目関連テーブル
| チーム名 | 演目 |
|----------+----------------|
| チームA | ポンポンダンス |
| チームA | ブレイクダンス |
| チームB | チアリーダ |
| チームB | ブレイクダンス |
キー：{チーム名,演目}
会場-演目関連テーブル
| 会場 | 演目 |
|------+----------------|
| 東京 | ポンポンダンス |
| 東京 | ブレイクダンス |
| 福岡 | チアリーダ |
| 静岡 | ポンポンダンス |
| 東京 | ブレイクダンス |
キー：{会場,演目}
- 以上で正規形の羅列はおしまい。
- さて、テーブルをなぜ正規化するかというモチベー
ションは次のとおり。
- データライフサイクルの問題
- 適切に正規化されていないと、データの登録や削
除が煩雑になったり、テーブルのデータが揃わな
いので部分的な情報を登録できなかったりなど
の支障がでる。
- 重複更新
- データ生存期間中であっても、適切に正規化さ
れていないことにより、ひとつの情報について
複数のテーブルや行を更新しなければいけない
ことが発生する。
うーん。これに時間をとられすぎた。
こつこつ。
0 件のコメント:
コメントを投稿