【第7回】E.F.Coddの遺産 -ECObjectsのDB設計ウラ話

現在データベースといえばリーレーショナルDB、リレーショナルといえばデータベースと置き換えるくらい、E.F.コッド博士の提唱したこのモデルは現在のコンピュータのアーキテクチャとして普及している仕組みになっています。
現在のオラクルやSQLサーバー、サイベース等々のデータべースはすべてこのリレー ショナルモデルを製品化したものです。このデータベースが普及する以前はデータベースといえばCODASYL型(ネットワーク型)と呼ばれたデータベースが最先端のアーキテクチャでありました(筆者はこの手の話が得意なのですが、本稿はデータベースの歴史を語る採用情報ではないので、これ以上は深入りしません。悪しからず)。
リレーショナル・モデルはIBMサンノゼ研究所のE.F.コッド博士によって1970年に提唱されました。
1970年6月の「大規模な共有データバンクのためのリレーショナル・モデル」(”A Relational Model of Data for Large Shared Data Banks”)と題した論文がはじまりです。その後、そのリレーショナル・モデルを製品化したDB2やオラクルが登場し、オープン化の波に乗って普及し始め、今日ではコンピューターのスタンダードなアキテクチャになっています。
その後、晩年になってE.F.コッド博士は超人のごとく研究を続けていて、1993年にまた絶大な足跡を残します。
OLAP(On-Line Analytical Processing)と多次元データベースです。
彼は1993年になって「アナリストのためにオンライン分析を:情報技術からの要請」(”Providing OLAP to User-Analysts:An IT Mandate”)と題した論文を、彼の妻である、S.B.コッドとの連名で発表しました。そこからデータウェアハウスと呼ばれる多次元DB が生まれたのです。

実は、ECObjects のDB 設計は、このE.F.コッド博士の思想の進化と共通する、あるポイントをもっています。
筆者はOLAP の理論がE.F.コッド博士によって提唱されたことをつい最近まで知らず、彼が自分の理論を進化させたことを知りませんでした。
筆者はその思想の進化に非常に興味深いものを感じました。
なぜならその考え方は、ECObjectsのDB設計理論と同じだったからでした。
そしてそれは偶然に考えだされたものではなく、明らかにE.F.コッド博士と共通の筋道で導出されたモデルなのです。

その経緯を以下に説明してみましょう(あまりにも荒唐無稽なのでここから先は推理小説かSF 小説を読むように理解していただきたい)。

リレーショナルDB の設計は正規化(Normalization)という手法で設計されます。ここで正規化とは何かをマイクロソフトのサイトから引用してみましょう。
(以下、引用)



<正規化の説明>

正規化とは、データベース内のデータを構築する手順のことです。正規化には、冗長性および矛盾する従属関係を除去することによって、データの保護とより柔 軟なデータベースの作成を意図する規則に従って、テーブルを作成する作業とテーブル間のリレーションシップを確立する作業が含まれます。

冗長なデータがあると、ディスク領域が浪費され、保守上の問題点が生じます。
複数の場所に存在するデータの変更が必要な場合、すべての場所でそれらのデータが同一になるように変更する必要があります。顧客の住所を変更する際に、データが保存されているのが顧客テーブルのみで、データベース内の他のテーブルに存在しない場合、変更作業を簡単に行えます。

 ”矛盾する従属関係” とは何でしょうか。特定の顧客の住所を探す場合に顧客テーブルを調べることは直感的に行えますが、その顧客を担当している社員の給与を調べるために、顧客テーブルを参照するのは適切ではありません。

社員の給与は、社員に関連付けられているか社員に従属するため、社員テーブルに移動する必要があります。しかし、矛盾する従属関係があると、データを見つけるパスが存在しないか破損している場合があるために、データの参照が困難になります。

データベースの正規化にはいくつかの規則があり、それぞれの規則を適用した状態は “正規形” と呼ばれます。
最初の規則に従っているデータベースは “第1正規形” であるといわれます。
最初の3つの規則に従っているデータベースは “第3正規形” であると見なされます。他のレベルの正規化も可能ですが、第3正規形がほとんどのアプリケーションで最も高いレベルと見なされています。

多くの規則や規格がそうであるように、現実のシナリオは常に規則に完全に適合しているとは限りません。一般的に、正規化を行うと追加テーブルが必要となる ため、わずらわしいと感じるユーザーもいます。正規化の最初の3つの規則のいずれかに従わずに設計する場合、冗長データや矛盾する従属関係など、アプリケーションで発生する可能性のある問題点を考慮しておく必要があります。

以下は、正規化の例です。

第1正規形
・各テーブルで繰り返し現れるグループを除去します。
・関連するデータごとに1つのテーブルを作成します。
・関連するデータ セットを主キーで識別します。
類似したデータを格納するために、1つのテーブルで複数のフィールドを使用しないようにします。
たとえば、在庫項目が2つの製造元から納入される場合、在庫レコードで “製造元コード 1” フィールドおよび “製造元コード 2” フィールドを使用して、その項目を追跡するケースを考えてみます。
3つ目の製造元を追加するにはどうしますか。単にフィールドを追加しただけでは、プログラムとテーブルの変更が必要となり、製造元の数が動的に変化する場 合に効率的に対応することができません。この場合は、すべての製造元の情報を別の製造元テーブルに格納し、項目番号キーを使用して製造元テーブルを在庫 テーブルにリンクするか、製造元コードキーを使用して在庫テーブルを製造元テーブルにリンクします。


第2正規形

・複数のレコードに該当する値のセットごとに1つのテーブルを作成します。
・これらのテーブルを外部キーと関連付けます。
レコードが、テーブルの主キー (必要な場合は、複合キー) 以外に従属しないようにする必要があります。たとえば、財務システムにおける顧客の住所を考えてみます。住所は顧客テーブルに必要ですが、受注、出荷、請求、売掛金、および回収の各テーブルでも必要です。これらのテーブルに顧客の住所を個別のエントリとして格納するのではなく、顧客テーブルまたは別の住所 テーブルのいずれか1つに格納します。


第3正規形
・キーに従属しないフィールドを除去します。
レコードに、キーの一部ではない値が含まれる場合、その値を別テーブルに分離します。一般的に、一連のフィールドの内容が、テーブル内の複数のレコードに適用されるときは、それらのフィールドを別のテーブルに配置することを検討します。
たとえば、社員募集テーブルに、志願者の大学の名前と住所が含まれているとします。
しかし、大学に募集要項を送付するには、大学の完全な一覧を必要とします。
大学の情報が志願者テーブルに格納されている場合、現在志願者がいない大学の一覧を取得する方法はありません。この場合、別に大学テーブルを作成し、大学コード キーを使用して志願者テーブルにリンクします。

例外 : 第3正規形を遵守することが理論上望ましくても、常に実用的とは限りません。顧客テーブルで、起こり得る内部フィールドの従属関係をすべて除去するには、都市、郵便番号、顧客担当者、顧客クラス、および複数のレコードで重複する可能性があるその他すべての要因に対して個別にテーブルを作成する必要がありま す。理論上、正規化は実践する価値がありますが、小さいテーブルを数多く作成するとパフォーマンスが低下し、開くことのできるファイルおよびメモリの容量を超える場合があります。
第3正規形は、頻繁に変更されるデータに対してのみ適用する方がより現実に即しています。従属フィールドが残っている場合、それらのいずれかが変更されるときに、関連付けられたすべてのフィールドの確認がユーザーによって行われるようにアプリケーションを設計します。


その他の正規形

ボイスコッド正規形 (BCNF) とも呼ばれる第4正規形、および第5正規形が存在しますが、実用的な設計と見なされることはほとんどありません。これらの規則を無視すると、完全なデータベース設計とはならないことがありますが、機能的には影響しません。

この資料は米国 Microsoft Corporationから提供されているKnowledge BaseのArticle ID 209534 (最終更新日2001-01-06)を基に作成したものです。(以上、引用終り)



この正規化はいくつかの問題を理論提唱された当初から持っていました。
一般論では正規化はこういわれています。

E.F.コッド博士の理論を完全に実装するためには、正規化は必要十分条件で不可欠である。よって、すべてのスキーマは第3正規形まで落とすべきである。
もし、表が増えすぎるというなら、第3から第2正規形に戻せばよい。
そうしないと、美しい設計とは言えない。
ところが現実的には以下のような問題が多発しました。

 


<問題点>

(1)E.F.コッドの理論は集合論なので、集合の∪と∩の記号を駆使してデータを演算しているが、現実のコンピュータのアーキテクチャでは、∪と∩の度にI/Oとデットロックが発生するので、正規化し過ぎたDBは効率が悪く遅くなる。

(2)また、分散化して1つのデータがスキーマ内で一意に管理されるため、データの発生と、(特に)消滅がとらえられない。特に、データを消すことが出来なくなるので、データベースは肥大化し続けてガベージコレクションすることが出来なくなる(DBベンダーは喜ぶ)

(3)第1→第2→第3正規形に正規化することによって表の数は等比級数的に増加する。
1→10→100この時に100の表を10にまた集約させることは、技術的にとても困難であるし、データの概念は日々変わるので、関係従属、推移従属であると推定されたモデルはシステムを運用する間に変化してしまうものである。
その時には間違った従属関係が歪んだデータモデルを作ることになる(要するにビジネスモデルの変化に対応できないDBとなってしまう)。

(4)トランザクションのDBを正規化すると、データがうまく再現出来なくなる。
例えば、会社名マスタにあるA社の社名が、9月に有限会社A社→株式会社エー社に変更になって、8月の注文書を再度印刷したりすると、株式会社エー社の社名で伝票が発行されることになる(ゆえに、トランザクションデータ(ECObjectsでいうと、フロー型のモデル)は正規化してはならない)。



ECObjectsでは以上のような正規化の問題点を加味して、第一正規形のままで(すなわち複合キー)スキーマを作って第2正規形第3正規形に相当するモデルをViewで表現することにしたのです。

実はこれは一種のOLAP のモデルになるのです。
多元化した軸情報をView で表現することによって実現するわけです。

これが統合化部品表の正体なのです。

このアーキテクチャが実装されるためにはViewが更新可能になったOracleのVer.7.3の出現を待たなくてはならなかったのは言うまでもありません。1997年ころの話です。

筆者はのちに、E.F.コッド博士の晩年の仕事がOLAP だったことを知って「なるほど、コッドさんは判っていたんだ」と思いました。
ちなみに、ECObjectsの設計指針を紹介しておきましょう。


◆正規化の実用的なルール

(1)基本的には第1正規形のままでよい。
 それをViewを駆使してキーを1意にしたり、キーを抽出したりするデータモデルがフレシキブルでよい

(2)第1→第2、第2→第3 にする時には、そうしなくてはならない明確な理由が必要

(3)トランザクションデータは正規化しない