リレーショナルモデルのデータベース（1）
こんにちは。次世代システム研究室のB.V.Mです。宜しくお願いします。
(外国人で言葉遣いが間違いましたらご容赦ください。)
IT業界にてデータベース設計の作業は常に発生されていると思います。でも、設計書が作成して上司にレビュー依頼したらいくつかのご指摘が受けられるかと思います。「改善する方法は何でしょうか」と考えました。もちろんたくさんタスクを対応して、データベースのテーブルを設計して経験と知識を身につけると思います。ですが、根本的にデータベースについてどのように理解すべきか確認した方が良いかと思います。それで本を探していました。読んでいる本は下記のように記載されていました。
どの分野の専門家も、それぞれの分野の基礎を理解している必要がある。したがって、読者がデータベースの専門家であれば、リレーショナルモデルを理解している必要がある。
（データベース実践講義・1ページ）
「SQL の知識でリレーショナルモデルが理解できるか」という質問が浮かぶと思います。この本を読んで、SQLの知識とリレーショナルモデルがどのように違うのが理解できます。その本はC.J.Dateさんのデータベース実践講義(エンジニアのためのリレーショナル理論)です。購入リンクは参考リンクに記載しております。本の内容を紹介しながら注意点、面白いところを紹介しようと思います。皆様にデータベース設計の際、役に立つと思います。
目次
1. 概要
まず注意点がありまして、この注意点はかなり気に入りました。SQL ≠ リレーショナルモデル （データベース実践講義・1ページ）
まずはSQLとリレーショナルモデルは別々なものです。
「SQL」は、リレーショナルデータベースにおけるデータの操作を行うための言語です。 一方で、「リレーショナルモデル」は、データベースの基本的な概念や設計に関する理論です。この観点から見るともちろん違うと思います。そして、リレーショナルモデルは、データベースにおける基本的な概念や設計に関する理論であり、それに対してSQLはその実装に関する言語である。 そのため、SQLがリレーショナルモデルに対してのみ使用されるわけではなく、他のモデルやアーキテクチャにも使用することができる。
質問：SQLとリレーショナルモデルの用語はどう違いますか。
SQL このような用語を使用しています：テーブル（table）、行（row）、列（column）
リレーショナルモデルしている：関係（relation）、タプル（tuple）、属性（attribute）という正式な用語になります。
もちろんSQLを使用している「ユーザーフレンドリ」な用語です。ですが、関係はテーブル？タプルは行？属性は列？
全部答えはどうなるでしょうか？リレーショナルモデルでの用語は、SQLによって実装されることを意味しているため、関係はテーブル、タプルは行、属性は列に相当することが多いですが、答えは関係はテーブルではない、タプルは行ではない、属性は列ではないという回答になります。なぜなら下の文で解説いたします。
ちなみにリレーショナルモデルはどのような重要なものですか。下記の文を読んでください。
「理論なくして実践に浮かれる者は、舵と羅針盤を持たずして船に乗り込み、どこへ向か
うのかも皆目検討のつかぬ操舵手のごとし。実践は十分な理論の上にこそ成り立つ」
（データベース実践講義・4ページ）
この文は、理論を理解しないで実践をすることは、漕ぎ出す船のように目的地に到達することができないことを表しています。これは、リレーショナルモデルについても同じことが言えます。
2.型と関係
「すべての関係（およびすべての関係変数）のすべての属性が、何らかの型を持つものとして定義される。」です。属性は型を持つということです。型はドメインとも呼ばれるもので、基本的には、値の概念的なプールである。型に関する内容は下記のような2つ点が発表されます。ドメイン制約の対象となる比較と「ドメインチェックオーバーライド」で、ドメインが実際には型です。
データ値の原子性と第 1 正規形の節で、型の複雑さが任意です。
2.1ドメインが実際には型
ドメイン制約の対象となる比較してドメインが実際には型を証明したいと思います。例として、以下のような型を持っているデータベースを定義します。
（データベース実践講義・25ページ）
サプライヤ
SNO: SNO
SNAME : NAME
STATUS : INTEGER
CITY : CHAR
部品
PNO: PNO
PNAME : NAME
COLOR : COLOR
WEIGHT : WEIGHT
CITY : CHAR
出荷
SNO : SNO
PNO : PNO
CNO : CNO
QTY : QTY
顧客
CNO: CNO
CNAME : CNAME
リレーショナルモデルでは、2つの値が等しいかどうかを評価できるのは、同じドメインに属している条件が必要です。
たとえば、サプライヤと部品の例では、以下の比較は有効である。
SP.SNO = S.SNO /* 有効 */
これに対し、以下の比較は有効ではない。
SP.PNO = S.SNO /* 無効 */
（データベース実践講義・26ページ）
でももしこのような質問があればどうしますか。「これらの顧客の中に私たちが取り引きしているサプライヤも含まれているのか」。
この質問が妥当なものです。→その時、S.SNAME = C.CNAMEの比較は有効でしょう？答えはまだです。代数演算子の一部に対して、ドメインチェックオーバーライド（Domain Check Override)があります。それによってS.SNAME = C.SNAMEの比較は有効になります。実はその比較するとき表す文字列に変換するTHE_CHAR関数が用意されて、比較する演算子は以下のようになるだろう。
THE_CHAR ( SNAME ) = THE_CHAR ( C.CNAME )SNAMEとCNAMEは別々のドメインです。THE_CHARによって物理的に表現される可能性があります。ですが、もしTHE_CHARがなかったら
S.SNAME = C.CNAMEを比較すると異なる型のため型を同じにする方法がないです。
ですので、ドメインが実際には型ということが分かりました。
2.2型の複雑さが任意
通常は、そうした「単一の値」が原子的（atomic）と見なされる、という補足が付く。だが、後者の条件からある当然の疑問が浮かぶ。データが原子的であるとはいったいどういう意味なのか。例えば：
● 整数。素数への分解できます。
● 固定小数点数。整数部と小数部への分解できます。
● 日時。年、月、日および時、分、秒への分解できます。
● 文字列。もちろん文字への分解できます。
（データベース実践講義・31ページ）
結局、「オブジェクト/リレーショナル」システムとは、関係に任意の複雑さの属性値を持つことができます。
これはおそらく、「正しいオブジェクト/リレーショナルシステムとは、単に 正しい型をサポートするリレーショナルシステムである」と理解してもよいです。
ですので、型の複雑さが任意です。
→型の複雑さが任意ですが、DB設計の時型は注意すべきは何でしょうか？
2.3型とは
型を定義の注意点：新しい型を定義するためには、少なくとも以下の作業が必要だと本に記載されています。
1. 型の名前を指定する（当然である）。
2. 型を構成する値を指定する。
3. 型の値の隠れた物理表現を指定する。前述のように、これは実装の問題であって、モデルの問題ではない。
4. その型の値および変数に適用される演算子を指定する。
5. 結果を返す演算子については、その結果の型を指定する。
（データベース実践講義・35ページ）
→ドメインは方で、型の複雑さが任意ですが演算子を指定すると演算子の結果の型を指定するのを注意必要です。型を定義するの際、その型はどのように利用されるか、演算子をちゃんと指定し、演算子の結果の型を注意しないといけないです。現在のプロジェクトにもあるSETTING_VALUEというドメイン（型）があって、そのSETTING_VALUEの演算子と演算子の結果をちゃんと定義指定から実装しています。
3.タプルと関係
これはタプルですか。
上記はタプルの図ですが、タプルではないです。（データベース実践講義・43ページ）
3.1タプルとは
リレーショナルモデルにてタプルの定義はT1、T2、…、Tn（n ≥ 0）が型名であり、それらが必ずしも異なるとは限らないとする。各Ti に識別可能な属性名 Ai を関連付ける。これによって生じる n 個の属性名と型名の組みは、それぞれ属性である。各属性を Ti 型の値 vi に関連付ける。それによって生じる n 個の属性と値の組みは、それぞれコンポーネントである。そのように定義された n 個のコンポーネントからなる集合（t）は、属性 A1、A2、…、An のタプル値（または略してタプル）である。値 n は t の次数であり、次数 1 のタプルは単項、次数 2 のタプルは2項、次数 3 のタプルは3項である。一般に、次数 n のタプルは n 項である。n 個の属性からなる集合は、t の見出しである。
（データベース実践講義・44ページ）
上記の定義がかなり分かりにくいかもしれませんが、簡単に説明すると：
1つコンポーネントは属性と値の組みです。
タプルは見出しとコンポーネントから構成されます。
上記の例のタプルのフォマットは下記のようになります。
TUPLE { SNO SNO, SNAME NAME, STATUS INTEGER, CITY CHAR } （データベース実践講義・45ページ）
従って、さっきの例はタプルとして表現したら下記のようになります：
TUPLE { SNO SNO('S1'), SNAME NAME('Smith'),STATUS 20, CITY 'London' }
（データベース実践講義・45ページ）
→型がなくなった、見出しと属性と値しかないです。データベースの設計はタプルから注目してその後型を定義します。3.2重要な帰結
本からタプルに関する重要な帰結が下記のように2つがあります。null を含むタプルは存在しないこと
タプルの部分集合はすべてタプルであり、見出しの部分集合はすべて見出しである
リレーショナルモデルにてnull が禁止される理由が多いです。下記のようなことです。
●null を含んだ「型」は型ではない（型には値が含まれるため）
●null を含んだ「タプル」はタプルではない（タプルには値が含まれるため）
●null を含んだ「関係」は関係ではない（関係にはタプルが含まれ、タプルには null が含まれないため）
（データベース実践講義・69ページ）
結論的に「null が含まれたデータベースから正しい結果が得られることは確信できない。」です。
リレーショナルモデルと言ったらnullが含まないです。
→逆に、実際にテーブルとレコードを設定するが、Nullを利用するのが結構あります。確実にテーブルにNullがあっても使用できています。というのはNullを使ってもちゃんとNullの値の意味を定義すべきです。Nullが持つ場合ちゃんと妥当な理由を説明しないといけないです。
感想
リレーショナルモデルは、データベースにおける基本的な概念や設計に関する理論であり、それに対してSQLはその実装に関する言語であります。 リレーショナルモデルを理解することで、データベースを設計し、データを管理する上での最適な方法を理解し、正確かつ効率的にデータを扱うことができます。 リレーショナルモデルの理論なしには、データベースを適切に管理することができないため、重要性が高いと思えます。本がまだ全部読みきれないですが、これまでいくつかの帰結が出ていると思います。例えばテーブル設計する時関係とタプルを考えて、論理的にタプルで考えた方が良いです。まずはタプルで設計して、その後PK、型など考えるべきです。
そして対照している物事は論理的に考えて、どういう属性があって、その属性はどのような値が持っているかしっかり考えるべきだと思われています。
