←講義のツボメニューへ
データベースのスキーマ設計
【2000.05.12 １限 第４回】
データベースのスキーマ設計
- 「スキーマ」＝データベースの論理的構造のこと。
- データ操作の効率はスキーマ設計の良し悪しで決まるが、上手なスキーマ設計のためのノウハウがある。
Ｑ１．図５−１のような発注書がある。これは、お菓子屋が卸問屋宛てに出す発注書である。このとき、発注書を管理するデータベースのスキーマを、あなただったら、どのようにしますか？換言すれば、データベースの中に何をデータ要素として格納しますか？
- 考え方
- 井沢フーズが自社のために管理するとすれば、発注するのは通常「井沢フーズ」であって、井沢フーズに関するデータはいらない。
- 上から順番に見ていって、”発注番号”、”発注先のお菓子問屋の名前”、”発注年月日”、”品名”、”数量”、”単価”。
- 金額は”数量”と”単価”をかければすぐに計算できるからデータベースに入れる必要はない。
- 消費税も税率をかければすぐ求められるし、税込合計金額も足し算で求められるのでいらない。
- ”扱い者”は必要。
- 以上に基づき表の形にすると、以下の（ａ）〜（ｃ）の３通りの表現方法がありえる。
※注：取引先に同名の会社が現れても大丈夫なように、ここでは”取引先ＩＤ”という属性を設けている。
データの正規化
- 第１正規形
- 図５−２（ａ）：ただ単に表にしたもので、リレーションが１つ。
- （（復習））「正規化」＝データを２次元の表の形に並べる事。このときリレーショナルモデルでは１個の欄に１つしか値を入れられない、というルールがあり、そのルールを満たすものを「正規形である」という。
- 実際のリレーショナルデータベースのスキーマ設計ではもっとデータ構造を変形して、より効率的な、そしてより正当性の保ちやすいスキーマになるように正規形の作業を進めていく。
- 単に２次元の表にしただけの正規形は、正確には「第１正規形」と呼ばれる。
Ｑ２．図５−２（ａ）のリレーションにおける主キーは何か？
- 第２正規形
- 図５−２（ａ）の問題点、改善点：何度も何度も同じことが書かれている。（”発注番号”、”取引先ＩＤ”、”会社名”、”日付”、”扱い者”）
- 記憶領域の無駄使いで、データ量が多くなるととりわけ深刻化。
- （→）図５−２（ｂ）のように表を分割する事により効率化可能。
- （メリット）：どこか一ヶ所変更すれば、同じ変更を何度もしなくてよい。
- 上記メリットが生まれるためには、どのような方針の元に表を分割すればよいか：
- ”発注番号”が決まると、”取引先ＩＤ”が一意に決まる。このように、どちらかの属性値を決めてやると、もう片方の属性値が決まる事を、「関数的に従属している（functionally dependent）」という。単に「従属している」ということもある。
ex）属性”取引先ＩＤ”は、属性”発注番号”に従属している。（”発注番号”→”取引先ＩＤ”と表記。）
- （ａ）内の「→」は従属関係を表現している。
- このほかに、”数量”と”単価”は、いずれも”発注番号”と”品名”のペアに従属している。（”発注番号”，”品名”→”数量”、”発注番号”，”品名”→”単価”）
- （ａ）の属性の中で、”数量”と”単価”を残して、”発注番号”にだけ従属している属性を分離したのが（ｂ）。”数量”と”単価”の方には、”発注番号”と”品名”のペアをつけている。
- 複数の属性が主キーを構成しているとき、主キーのすべての属性ではなく一部の属性から主キー以外の属性へ生じている従属性のことを「部分従属性（partial dependency）」という。
- 第１正規形において、部分従属性がなくなるように表を分割して得られたものを、「第２正規形」という。
- 第３正規型
- 図５−２（ｂ）において、”発注番号”→”取引先ＩＤ”に加え、”取引先ＩＤ”→”会社名”という関係がある。よって、”取引先ＩＤ”を仲介として、”発注番号”→”会社名”という関係も成立している。
- このように、ある属性を介して間接的に２つの属性が従属関係にある場合、「推移的従属性（transitive dependency）がある」という。
- 第２正規型から推移的従属性がなくなるよう、表を分割すると、第３正規型が得られる。
- 高次の正規型ほど重複が排除されており、データの更新に適している。
- 第２正規型は第１正規型の特別な場合、第３正規型は第２正規型の特別な場合である。すなわち、第１正規型に正規化した時点で、すでに第３正規型になってる場合もあり得る。
- 第３正規型の意義：キーでない属性（＝「非キー属性」）が互いに独立であること。どれか一つの値を更新しても、他の属性への影響を及ぼさない。
- 超キー、候補キー、主キー
- 主キーの組み合わせ：何通りもあることがある。
- 「超キー（super key）」＝すべての属性の値を決定し得る、属性の組み合わせのことを「超キー」という。属性一つの場合も含む。
- 超キーの中から、冗長な属性を取り除いた極小なもののみの属性の組み合わせにしたものを、候補キー（candidate key）という。
- 候補キーの中から、そのリレーションのキーとして採用したものを、「主キー（primary key）」という。
３．Ｅ−Ｒモデル
- ここまでで具体例として採用した「お菓子屋の発注の世界」では、具体的な「発注書」という形があらかじめ与えられ、いわばデータベース化するに当たってある程度のモデル化がサービスされていた。
- 本筋では、データベース化する対象世界をモデル化するところからの手法について論じる。
- 絵を描く場合の下書きに相当するこのステップは、「概念レベル（conceptual model）のモデル化」と呼ばれる。
- 概念レベルのモデル化をするための道具として有名なものに、1976年、Peter Chenによって考案された「Ｅ−Ｒモデル（Entity-Relationship model;実体関連モデル）」がある。
- Ｅ−Ｒモデル：
- 世の中を「実体（entitiy）」と「関連（relationship）」に分けて考える。
- 「実体」＝実世界の中で我々が認識するものや事柄のこと（例：会社、大学、学生、商品など）
- 「関連」＝実体と実体の間に生じる関連を、「関連（relationship）」ととらえる。
ex）大学と学生の間には、”所属”という関連があり、会社と商品の間には、”販売”という関連がある。
注）リレーショナルモデルの別名／和名「関係モデル」。和訳ははっきり決まっているので、混同しないように注意。
- 「Ｅ−Ｒダイアグラム」＝Ｅ−Ｒモデルを用いて対象世界を表現するときに、視覚的な表記を行うために用いる記法。
(a)ex）お菓子やＳＡＮの対象世界を発注書を見ずにＥ−Ｒダイアグラムで表記した一例が図５−４
(b)長方形で囲んだのが実体
(c)菱形が関連
(d)楕円で囲んだものが、実体や関連の性質を表す「属性」
(e)「１」、「Ｎ」などの数字は、「一対多」、「多対多」などの関係を表現している
(f)図５−５にあるとおり、何を実体ととらえ、何を関連ととらえるかは、設計者の見方による。一意ではない。
リレーショナルデータモデルでの表現
- Ｅ−Ｒモデルからリレーショナルモデルへの変換規則
種々提案されたが、以下が最善として固定、認知された。
- Ｅ−Ｒモデルの実体の処理：リレーションへ変換する（例：図５−４→図５−６では、”取引先業者”、”発注書”、”商品”
- Ｅ−Ｒモデルの関連の処理：
(a)多対多の関連：リレーションへ変換した上で、関連に参加している２つの実体の主キーを底雨声に追加し、これらを主キーとする。（例：図５−４→図５−６では、”発注項目”
(b)１対多の関連：リレーションは作らず、多の方の属性に１の方の主キーを加えて、これを外部キーとする。（例：図５−４→図５−６では、”発注先”）
←講義のツボメニューへ
←鈴木研究室ホームへ