リレーショナル・データベースの専用言語 SQL は、よくできた言語だとつくづくよく思っています。わたしは SQL92 というバージョンからおつきあいしています。

ただ、SQL は、他のプログラム言語と親和しにくいと感じられることがしばしばです。これまでに多くのプログラムインターフェースが登場してきましたが、正規化ルールにしたがって、実際のデータ群を分解してテーブルに Insert、Update する。トランザクションを制御する。Select では、非正規化された大量のデータをすべて変数（あるいはフィールド）に写す（あるいはマッピングしておく）など、これらのプログラミング上の煩雑さは大きなままです。

また、リレーショナル・データベースのカラム変更の容易さに比べて、プログラム対応は煩雑となることがしばしばです。

わたしは、だいぶ以前のことですが、EXCEL でデータベースのカラムを定義しておいて、マクロでテーブル定義の SQL 文を出力し、C 言語向けにカラムと対応した構造体と変数を出力するといったようなものを作ったことがありましたが、その効果は限定的でした。その当時は、データフォーマットの調整や、データの変数コピーの煩雑さ、そして、Insert、Update よりも Select の非正規化データの処理のプログラミングなどの煩雑さなどを解決できなかったことを思い出します。

さて、今は、オブジェクト指向設計・実装が主流ですから、クラス設計・実装において、このようなリレーショナル・データベースに対するプログラミングの煩雑さをどうやって軽減するか、プロジェクトのたびによく問題にあがることでした。特に非正規化の Select は、複数エンティティのリレーションによって発生し、その条件も内容も流動しやすく、プロセスごとに非正規化を考えると似たような SQL 文が多数発生しやすくなる、といったようなことをふまえて、どのようにクラス設計にするかが問題の中心となることも多かったと思います。

そして、プログラミングにおいては、SQL 文のコーデイング、カラムとフィールドの対応、条件の設定など、単純ではありますが、システムが大きいほどカラムも SQL 文も多くなり、そのコーディング量は膨大となり、単純ミスも発生しやすい作業でした。

O/R マッピングは、このようなプログラミング上の煩雑さを軽減するために考案された手法で、無償で公開されているO/R マッピングフレームワークもあります。

このような O/R マッピングの取り組みに、わたしはこの記事の最初にあるような SQL 言語に対する思い以上に感心しています。

最近では、モデリングに UML の使用が普及していますが、ER モデリングも使われ続けていて、整合性の調整の手間が気になることがしばしばありました。

オブジェクト指向設計・実装とリレーショナル・データベースの相性は、よいといえるものではありませんが、工夫してなんとかつきあっているといった感じでしょうか。

このごろは、XML データベースが書籍や雑誌で扱われるようになりました。オブジェクト指向との相性はよさそうです。これまでのリレーショナル・データベースの正規化・非正規化を主体に考えるのではなく、オブジェクト思考にまかせて考えればよいのかもしれません。

ただ、リレーショナル・データベースと SQL は、EUC のような作業と相性がよいといえそうです。このように考えると、O/R マッピングは、引き続き必要な技術となるのでしょう。しかし、そのような作業でも、思考・アプローチをかえれば、リレーショナルでなくとも本来の目的を達成できるのかもしれません。

Business Intelligence の略称で BI です。

定義としては、業務システムなどで蓄積される企業内の膨大なデータから分析・加工して、企業活動に活用することをいうとされています。

方式としては、ETL（Extract Transform Load）で基幹系システムなどに蓄積されたデータを抽出・加工し、データウェアハウス（Data WareHouse）のデータベースにロードする。そして、OLAP（Online Analytical Processing）あるいはデータマイニングによって分析、あるいは、レポーティングを行うというようなことです。

OLAPとデータマイニングの違いは？

一般的には次のようにいわれます。

OLAPは、データウェアハウスなどに集められた大量のデータをキューブと呼ばれる多次元構造データベースに格納し、これを様々な角度から検索・集計するものです。スライス＆ダイス、ドリルダウンなどの機能を用います。

データマイニングは、大量のデータを統計的手法で分析するものです。ニューラルネットワーク、ディシジョンツリーなどが手法としてあげられます。

さて、大規模なデータウェアハウスを必要としないで分析時間もスピードアップしたBI（リアルタイムBIと呼ばれる）の登場も話題としてあるようです。

SQL では、 UNION ALL ＆ NOT EXISTS がわたしの得意技でした。同じような SQL 結果を得るのに、LEFT JOIN 句がありましたが、LEFT JOIN 句では、DBMS によって結果を得るまでのレスポンススピードが大きく異なることが多かったのに対して、UNION ALL ＆ NOT EXISTS では、DBMS による差異がほとんどありませんでした。

UNION ALL ＆ NOT EXISTS を利用した SQL の例です。

試験情報、試験分類の２つのテーブルを試験分類コードで結合します。試験情報レコードに対する試験分類レコードは０か１存在します。

(SELECT a.ID,a.試験通番,a.試験名称,a.試験名短縮,a.試験記号,a.試験分類コード,a.表示順位,a.無効区分,a.作成日,a.更新日,b.ID,b.試験分類名称,b.試験分類名短縮,b.表示順位,a.試験コメント,a.試験情報１,a.試験情報２,a.試験情報３

FROM 試験情報 a,試験分類 b

WHERE a.試験分類コード=b.試験分類コード AND a.無効区分='0' AND b.無効区分='0')

UNION ALL

(SELECT a.ID,a.試験通番,a.試験名称,a.試験名短縮,a.試験記号,a.試験分類コード,a.表示順位,a.無効区分,a.作成日,a.更新日,0,'','',0,a.試験コメント,a.試験情報１,a.試験情報２,a.試験情報３

FROM 試験情報 a 

WHERE a.無効区分='0' AND

NOT EXISTS

(SELECT * FROM 試験分類 b WHERE a.試験分類コード=b.試験分類コード AND b.無効区分='0') )

ORDER BY 14,11,7,1 

UNION ALL 以前の SELECT 文では、試験分類コードで結合できる全レコードが対象となり、UNION ALL 以後の SELECT 文では、NOT EXISTS の条件で試験分類コードで結合できない試験情報テーブルのレコードが対象となります。そして、この SQL文の実行結果として、その両方のレコードが得られるというものです。

なお、UNION ALL では、その前後の SELECT 文で出力するカラムの数が一致している必要があります。また、ORDER BY 以降の数字は、それぞれの SELECT 文に指定しているカラムの位置の順番にあたります。

データベース設計における正規形について、情報処理技術者試験の午前問題を基に見てみることにします。なお、試験問題の全文については、情報処理技術者試験センターのＷｅｂサイト http://www.jitec.jp/ にて公開されています。

まずは、平成１９年度テクニカルエンジニア（データベース）午前試験問題の問２４からです。

問２４　第１、第２、第３正規形とそれらの特徴ａからｃの組み合わせとして、適切なものはどれか。

ａ：どの非キー属性も、主キーの真部分集合に対して関数従属しない。

ｂ：どの非キー属性も、推移的に関数従属しない。

ｃ：繰返し属性が存在しない。

	第１正規形	第２正規形	第３正規形
ア	ａ	ｂ	ｃ
イ	ａ	ｃ	ｂ
ウ	ｃ	ａ	ｂ
エ	ｃ	ｂ	ａ

答えは、ウ。

正規形の説明では、候補キーという用語がよく登場します。冗長がなく一意性を有する属性が候補キーとなります。その候補キーの中から主キー（Primary Key）が選ばれます。また、非キー属性は、候補キー以外の属性をいいます。

第２正規形は、第１正規形で、かつ、すべての非キー属性がすべての候補キーに対して完全関数従属するときのことをいいます。

関数従属とは、たとえば、属性Ａの値を決めると常に属性Ｂの値が定まるとき、ＢはＡに関数従属するといいます。（この場合、Ａ→Ｂと表記します。）

そして、完全関数従属は、非キー属性が、候補キーを構成する複数の属性について関数従属しているような場合に、非キー属性には、候補キーを構成する一部の属性について関数従属（部分関数従属）はない、というような意味です。

なお、集合ＡがＢの部分集合で、かつ、Ｂと等しくないとき、集合Ａは集合Ｂの真部分集合であるといいます。「どの非キー属性も、主キーの真部分集合に対して関数従属しない。」とは、どの非キー属性も主キーを構成する一部の属性に対して関数従属するものではない、というようなことになりましょうか。まだ、第２正規化の余地があるということになります。

第３正規形は、第２正規形で、かつ、非キー属性のすべてが候補キーに非推移的に関数従属するときのことをいいます。

推移的に関数従属とは、たとえば、属性Ａの値を決めると常に属性Ｂの値が定まり、なおかつ、そのときの属性Ｂの値により常に属性Ｃの値が定まるとき、ＣはＡに推移的に関数従属するといいます。

第３正規形は、非キー属性の中に、候補キーに推移的に関数従属する属性がないことになります。

ちなみに、関数従属について、平成１７年度テクニカルエンジニア（データベース）午前試験問題の問２４もみてみます。

問２４　関数従属に関する記述のうち、適切なものはどれか。ここで、Ａ、Ｂ、Ｃはある関係の属性の集合とする。

ア　ＢがＡに関数従属し、ＣがＡに関数従属すれば、ＣはＢに関数従属する。

イ　ＢがＡの部分集合であり、ＣがＡに関数従属すれば、ＣはＢに関数従属する。

ウ　ＢがＡの部分集合であれば、ＡはＢに関数従属する。

エ　ＢとＣの和集合がＡに関数従属すれば、ＢとＣはそれぞれがＡに関数従属する。

答えは、エ。

さて、ＲＤＢのテーブル設計において、正規化は、必須のスキルです。ただ、必ずしも第３正規形まで進めればよいものでもなく、レコード件数やリレーションの複雑さに応じて、部分的に第２正規化そして部分的に第３正規化を行う、といったことも行われます。実際に非正規化の際にパフォーマンスが悪くなる、といったことはよくあることです。ＤＢＭＳの性能に応じて、ということになりましょうか。あるいは、アプリケーションプログラムで調整可能な範囲で、ということにもなりましょうか。

スキーマ（schema）は、「データベースの構造」というような意味になります。元々は、「概要」や「大要」といった意味です。

ＡＮＳＩ／ＳＰＡＲＣ３層スキーマでは、データベースの構造について、概念スキーマ、外部スキーマ、内部スキーマの３層を定義しています。

それぞれの層の説明の例としてよくあげられるのは、概念スキーマについては table 定義、外部スキーマについては　view 定義、内部スキーマについては、物理ファイル定義です。

このＡＮＳＩ／ＳＰＡＲＣ３層スキーマに関して、平成１７年度情報処理技術者試験テクニカルエンジニア（データベース）午前試験問題の問２１をみてみます。なお、試験問題の全文については、情報処理技術者試験センターのＷｅｂサイト http://www.jitec.jp/ にて公開されています。

問２１　ＡＮＳＩ／ＳＰＡＲＣ３層スキーマに関する記述として、適切でないものはどれか。

ア　ＡＮＳＩ／ＳＰＡＲＣ３層スキーマの意義は、物理的データ独立性及び論理的データ独立性を確保することである。

イ　外部スキーマは、実世界が変化しても応用プログラムができるだけ影響と受けないようにするための考え方である。

ウ　関係データベースのビューやネットワークデータベースのサブスキーマは、概念スキーマに相当する。

エ　内部スキーマは、直接編成ファイルやＶＳＡＭファイルなどの物理ファイルを用いて、概念スキーマをコンピュータ上に実装するための記述である。

答えは、ウ。

この問題に関連して、わたしが個人的に感じていることをちょっと書いてみます。

アは、物理的データの独立性及び論理的データ独立性についての記述です。理論としてよくみることのある説明です。実際には、物理的データ構造を意識せずに論理的データを扱うことができますが、それはＤＢＭＳごとのしくみによって実現されているものがほとんどのように思えます。完全な独立性が確保されるかというと、そうともいえないこともありそうです。

イも理論としてよくみることのある説明です。ただ、実際には、外部スキーマの代表例である view を利用することがそれほど多くはないように思えます。メンテナンスや管理が煩雑になりますし、結局のところ、なんらかの変化がおきた時には応用プログラム（アプリケーションプログラム）にもなんらかの影響が及ぶことがほとんどなので、構造上の複雑さを避けるために外部スキーマを設けないことも多いと感じます。むしろ、応用プログラム（アプリケーションプログラム）が外部スキーマを兼ねているとも感じられます。

エについて、直接編成ファイルやＶＳＡＭファイルというと、汎用機やオフコンが思い浮かびます。現在の現役エンジニアの方のうち、何人くらいの方が扱ったことがあるのだろう？と、ふと思いました。ちなみに「内部スキーマは、物理ファイルを用いて、概念スキーマをコンピュータ上に実装するための記述である。」という説明でも、理解できそうな気もします。