リレーショナルモデルのデータベース（2）
こんにちは。次世代システム研究室のB.V.Mです。宜しくお願いします。
データベースをより良い設計を提供したいため、データベースの根本知識を元理解すべきでリレーショナルモデルをリサーチしていました。前期、リレーショナルモデルのデータベース（1） で型と関係、タプルと関係に関する注意点、役に立つ結論を抽出して紹介させていただきました。今回は関係変数、リレーショナル代数、データベース設計理論に関するの情報を共有しようと思います。
目次
1. 関係変数
前回、リレーショナル代入の対象は関係変数であることがわかりました。今から候補キー、外部キー、関係と型などについて深く見てみたいと思います。（データベース実践講義・65ページ）
関係変数が関係を値に持つことを許可された変数であることと、INSERT、DELETE、UPDATE の対象となるのは関係ではなく関係変数であることを説明した。
まず、リレーショナル代入はタプルを変更、更新だけではなく集合レベルで動いているのを理解しておきましょう。普通はレコード変更するのを理解していますが、ここでレコード（タプル）の変更によりテーブル（関係変数）が変更されました。量の変更により質が変更されたこととも思われます。リレーショナルモデルにおいては関係変数が変更されます。A関数からB関数に変更されてみたいです。
（データベース実践講義・65ページ）
リレーショナル代入は、どのような構文で表現するとしても、集合レベルの演算であることをまず強調しておきたい。
したがって、INSERTはタプルの集合をターゲットの関係変数に挿入し、DELETEはタプルの集合をターゲットの関係変数から削除する。また、UPDATEはターゲットの関係変数に含まれているタプルの集合を更新する。
1.1 候補キー
（データベース実践講義・67ページ）
定義:
K が関係変数 R の見出しの部分集合であるとすれば、K は以下の特性を両方とも有する場 合に限り、R の候補キー(または単にキー)である。
一意性
R が取り得る値に、K の値が同じである 2 つの異なるタプルが含まれることはない。
既約性
一意性を持つ K の真部分集合は存在しない。
候補キーは特定したらタプルも１つしか特定できないです。主キーは候補キーの１つケースだけです。キーについて下記の３つな注意点があります。
（データベース実践講義・67ページ）
1. キーの概念は関係変数には適用されるが、関係には適用されない。
2. キーがあるということは、特定の整合性制約（具体的には、特定の一意性制約）が適用されることを意味するからである。整合性制約は変数には適用されるが、値には適用されない。
3. キー値がタプルであることだ。
簡単に説明すると、まずはキーは関係変数に適用されるのを注意しました。キーは整合性制約が適用されています。最後にキーは関係変数の一部なのでキーはタプルです。
1.2 外部キー
リレーショナルモデルで外部キーの定義は下記のようになります。（データベース実践講義・69ページ）
R1 および R2 が関係変数であり、必ずしも異なるとは限らず、なおかつ K が R1 のキーで あるとする。FK は R2 の見出しの部分集合であり、属性名を変更することにより、K と まったく同じ属性を持つものとする。そうすると、R2 のすべてのタプルの FK 値が、その 時点において R1 の(必然的に一意な)特定のタプルの K 値と等しい場合に限り、FK は外部キーである。
外部キーはみんな慣れていると思いますが、注意点が一つだけと思います。それは外部キーはまず、関係変数の候補キーです。
1.3 ビュー
リレーショナルモデルでビューの定義は下記のようになります。（データベース実践講義・71ページ）
ビューまたは仮想関係変数 V は、ある時点 t に特定のリレーショナル式を評価した結果を、 t 時点の値として持つ関係変数である。問題の式は、V の定義時に指定され、少なくとも 1 つの関係変数に言及していなければならない。
ビューの特徴は閉包性、命名があるのはみんな存じていると思います。ビューは基底関係変数と同様のルックアンドフィールです。それでビューと関係変数について下記のように結論が出ていました。
（データベース実践講義・74ページ）
どの関係変数が基底であり、どの関係変数が仮想であるかに関する原則がない
1.4 関係と型
（データベース実践講義・71ページ）
データベースは常に真の命題を集めたものとして考えることができる。
型は話題にできるものの集合であり、関係はそうしたものに関する(真の)声明である
データーベースに保存しているレコード、あるいは関係変数にあるタプルはそもそも、何に表したいか、その基本のものはあまり考えなかった私です。真の命題を集合と考えるべきです。以前、それは必然なことと思っていたかと思います。疑惑がなかったです。ですが、その命題は全然「偽」の命題可能性もあります。ですが、規約として私たちはデータベースは常に真の命題を集合で作ります。
2.リレーショナル代数
本により、オリジナルの 8 つの演算子(制限、射影、積、交わり、和、差、結合、商があります。各演算子の定義は再度ここで説明しないと思いますが、気になる点があれば上げさせていただきます。リレーショナル代数について本に下記の内容が書かれました。（データベース実践講義・87ページ）
1. 演算子は汎用的である。要するに、考えられるすべての関係に適用される。
2. 演算子は読み取り専用である。
3. 関係変数名は、対応する関係変数そのものを表すわけではなく、その時点でその関係変数に含まれている関係の現在の値を表す。
4. INSERT、DELETE、 UPDATE(およびリレーショナル代入)がリレーショナル演算子であることは確かだが、それらは代数の一部ではない。
関係代数なので演算子は汎用的があるのは納得しやすいと思います。「演算子は読み取り専用である。」について、INSERT、DELETE、 UPDATEは変更ではないですか？でも、「4.」にも書かれて、それはリレーショナル代入の演算子です。実はINSERT、DELETE、 UPDATEは元々のA1関数から修正して、新しい関数A2に変更されて、入れ替えたということです。
2.1 閉包
代数演算は閉包があります。閉包はみんな存じていると思うが、閉包について質問が下記のようにあります。（データベース実践講義・117ページ）
従来の算術において数値閉包が重要であることと同様の理由により、閉包はリレーショナ ルモデルでも重要である。ただし、従来の算術では、閉包が正しく作用しない状況が 1 つ ある。それは、ゼロによる除算である。リレーショナル代数にも似たような状況が存在するか。
回答はそのような問題はないです。たとえば
r DIVIDEBY z上記の質問によりz が TABLE_DEE または TABLE_DUM のいずれかであるとすれば、その時 r DIVIDEBY zは
r JOIN zになります。
2.2 SQL
SQL の SELECT … FROM … WHERE 実は複数の演算子から組み合わせました。詳細は下記のようになります。（データベース実践講義・100ページ）
SELECT S.SNO, S.SNAME, S.STATUS, S.CITY AS SCITY,
P.PNO, P.PNAME, P.COLOR, P.WEIGHT, P.CITY AS PCITY
FROM S, P
WHERE S.CITY <> P.CITY
この SQL 式は、以下の 3 つの手順で実装されると考えることができる。
1. FROM 節が実行され、テーブル S および P のデカルト積が得られる(これをリレーショナ ルに行うとしたら、デカルト積を計算する前に、都市属性の名前を変更する必要があるだ ろう。SQL では、テーブルの列が左から右へ順序付けされ、その位置によって 2 つの都市 列を区別できるため、あとからの名前変更でうまく逃げることができる。便宜上、詳細は 無視することにする)。
2. 次に、WHERE 節が実行され、2 つの都市値が等しい行を削除することにより、デカルト積 の制限が得られる†。
3. 最後に、SELECT 節が実行され、SELECT 節で指定された列に基づく制限の射影が得られ る(もちろん、この例の SELECT 節では名前変更も行われている。そして後述するように、 リレーショナル拡張演算子に近い機能も提供される。さらに、DISTINCT が指定されない 限り、一般に重複は排除されない。だが便宜上、これらの点もすべて無視することにしたい)。
SQL文の実行手順は3つの手順で行われます。
-
- 最初にFROM節が実行され、テーブルSとPのデカルト積が取得されます。
- 次に、WHERE節が実行され、都市値が等しい行が削除されます。
- 最後に、SELECT節が実行され、指定された列に基づく制限の射影が得られます。
3 データベース設計理論
（データベース実践講義・100ページ）
関係変数 R の「総」関係変数制約は、R の述語に対す るシステムの近似値として捉えられる。
。。。
論理設計とは、基本的には、述語をできるだけていねいに定義し、それらの 述語を関係変数や制約にマッピングするプロセスにほかならない。
データベース設計は述語でシステムの意味を述語で関係変数や制約にマッピングすることです。
3.1 設計理論の立場
（データベース実践講義・148ページ）
設計理論そのものは、リレーショナルモデルには含まれない。どちらかと言えば、リレーショナルモデルに基づいて構築された独立した理論である(リレーショナルモデル理論全体の一部として 捉えるのがふさわしいが、繰り返し言うように、モデル自体の一部ではない)。ただし、たとえば 射影演算子や結合演算子といったモデルの一部である基本概念に基づいている。
設計理論はそもそもリレーショナルモデルに含まれないです。リレーショナルモデルをもとに作られたの理論です。リレーショナルモデルは基礎ですが、設計理論はそれだけではないです、他の理論ももちろん必要です。それでも設計は「データベース設計はきわめて主観的である」ものです（本の149ページ）。
データベース設計の時、正規形をしていて、第 1 正規形、第 2 正規形、第 3 正規形などです。正規形の数は大きくなるほどよいは誰も存じているが、どのくらいまでに良いか質問になります。
3.2 関数従属性とボイスコッド正規形
正規形にするのはデータベースのが確かに大切ですが、もっと大事のことは「無損失分解」です。元のR関係変数から色々小関係変数に分解されも元のRの意味を保つのが大事です。例えば：
（データベース実践講義・154ページ）
今回は関係変数 SNS と CS に分解する(関係変数 CS は先の分解と同じだが、関係変数 SNS は属性 SNO、SNAME、CITY ではなく SNO、SNAME、 STATUS を持つ。図 7-3 を参照)。この場合、(a) SNS と CS はどちらも BCNF だが、(b)分解が無 損失ではなく「有損失」であることは明らかである。
から
になりました。
この場合：例えばサプライヤ S2 の所在地がパリとア テネのどちらであるかがわからないので、情報が失われています。
Ian Heathが1971 年に発表した以下の定理に よって提供されてました。
（データベース実践講義・154ページ）
A、B、C が関係変数 R の見出しの部分集合であり、A、B、C の(集合理論の)和がその見 出しに等しいとする。AB は、A と B の(集合理論の)結合を表し、AC についても同様とす る。R が FD A → B を満たすとすれば、R は AB と AC での射影の結合に等しい。
先ほどのテーブルの設計の例は情報が失われました。その原因はFD – Function dependency（依存関係）正しく定義しなかたからです。
Function dependency – FD
FDとは、関数従属性(Functional Dependency)の略称で、ある関係の中で、ある属性または属性集合が他の属性または属性集合に従属していることを示す制約条件です。
正しくのは下記のようになります。
（データベース実践講義・154ページ）
RS { SNO, SNAME, CITY}
RS { CITY, STATUS }
CONSTRAINT RSC
RS = JOIN { RS { SNO, SNAME, CITY }, RS { CITY, STATUS } } ;
ルール（関数従属）はCITYがSTATUSを決めます。なので分けたら { SNO, SNAME, CITY}と { CITY, STATUS } ２つ関係変数になります。それは常識です。
でが、それはすべて常識ではないのか。「Statusが重複可能性があり、そしてCITYの属性なのでそれは当然だ」や「StatusでCityを決めるなら明らかに不適切だ」という意見があるかもしれません。でも正規化された常識です。
（データベース実践講義・155ページ）
原理は確かに常識だが、それらは正規化された常識なのである(常識が常識 であるとしても、それが何かを正確に述べるのはそう簡単ではない)。
3.3 結合従属性と第 5 正規形
（データベース実践講義・156ページ）
定義:
A、B、…、Z を関係変数 R の見出しの部分集合であるとすれば、R の妥当な値であるすべ ての関係が A、B、…、Z での射影の結合に等しい場合に限り、R は以下の結合従属性を満 たす。
☆ { A, B, …, Z }
JD ☆{ A, B, …, Z }は、「スター A、B、…、Z」と読む。この定義から、以下のことがわかる。
● 関係変数 R が、JD ☆{ A, B, …, Z }を満たす場合に限り、A、B、…、Z での射影に無損失分解 できることがすぐにわかる。
● (前節で述べたように)R が特定の FD を満たす場合には、特定の射影に無損失分解できる (すなわち、特定の JD を満たす)ことから、すべての FD が JD であることもすぐにわかる。
ボイスコッド正規形 – BCNF（Boyce–Codd Normal Form）は歴史的には意味を持つが実際にそんなに厳密に実装されていないです。第５正規型の方が目指した方が良いです。
5NFは、最後の正規形であり、一般的な結合従属性に関連する唯一の正規形である、理論的には重要です。BCNFから5NFになりたい条件：
（データベース実践講義・156ページ）
BCNFの関係スキーマに複合キーが存在しない場合、その関係スキーマは5NFであるという定理があります。
3.4 正規化目標
（データベース実践講義・162ページ）
正規化の目標は以下のとおり。
● 現実の世界を「うまく」表現すること。つまり、直感的に理解しやすく、将来的に発展させ やすい設計を実現すること。
● 冗長性を削減すること。
● それによって、更新不整合を回避すること。
● 特定の整合性制約の記述と適用を単純化すること。
「現実の世界を表現すること」これは大事です。データーベースは元々現実の正解を表したいからです。
正規化により冗長性を削減することが誰も存じていると思いますが、注意点があります。それは、最後までに分解する必要ない場合もあります。例えば
ADDR { STREET, CITY, STATE, ZIP }
からZCS { ZIP, CITY, STATE } KEY { ZIP }
ZS { ZIP, STREET } KEY { ZIP, STREET }
に分けられますが、結果として、関係変数 ZCS と ZS は、単体では更新できなくなります。更新の際両方更新しないといけないです。感想
リレーショナルモデルは、データベースにおける基本的な概念や設計に関する理論であり、それに対してSQLはその実装に関する言語であります。 リレーショナルモデルを理解することで、データベースを設計し、データを管理する上での最適な方法を理解し、正確かつ効率的にデータを扱うことができます。 リレーショナルモデルの理論なしには、データベースを適切に管理することができないため、重要性が高いと思えます。この本がほとんど読んでも、これから実際問題が出て、再度論理から見てデータベースを設計した方が良いと思います。
