今日はエドガー・コッドの命日。
データベースの研究者です。恥ずかしながら、僕も今回の記事を書く際に初めて知りました。
「リレーショナルデータベース」というアイディアを最初に出した人です。
以前に、別のデータベース研究者の方の誕生日で、データベースの話を少し書いています。
なので、詳細はそちらを読んでいただくことにして、データベースの概念をざっくりと説明。
データベースというと特殊なものと思われがちですが、データを蓄積してあればデータベースです。
テキストファイルで書き溜めたものでもいいし、ノートにまとめたものだってかまわない。
もう少しデータベースらしく考えるには、必要なデータを速やかに取り出せる必要があります。
ノートに順次書いたデータベースは、おそらくデータを探すのが大変なはず。
しかし、同じように本に書かれたものでも、辞書は簡単に目的の「データ」を探し出せます。
コンピューター以前に、パンチカードの時代がありました。
これは、元々国勢調査などの目的のために考案されたものです。
1928年に IBM が考案したカードは、１枚のカードに、0～9の数字を80個記録できます。
たとえば、国勢調査であれば、一人の人間に対して、選択項目が 10 個までの質問を、80個できることになります。
一人分のデータがカード１枚の「データ」となり、カードを集めてデータベースを作れるのです。
カード集計機を使えば、データによってカードを並び変えることも、抽出することも、集計することも出来ました。
データを自在に操れるのです。これは、データベースの革命と言えました。
コンピューター時代にもパンチカードは使われ続け、1960年代に入り、同等の動作をコンピューターで行おうという動きが広がります。
IBM も含め、大手コンピューター企業が、コンピューターを使用したデータベースを競うように作成します。
しかし、この「データベース」は、パンチカードを動かすという「物理動作」を無くして高速化した、という程度で、概念としてはパンチカードと変わっていませんでした。
そこに、本日の紹介人物、エドガー・コッドが現れます。
彼は、1948年に IBM に入社し、在職のまま大学に入って研究を行なっています。
＃日本では大学は「社会人の前に勉強するところ」ですが、アメリカでは、いつでも勉強をしたい人が通う場所です。
社会人になり、仕事で必要だから入る、会社が金を出して入れさせる、ということも珍しくはありません。
そして 1969年、IBM の研究所で、全く新しいアイディアに基づくデータベースの論文を発表します。
それが「リレーショナルデータベース」でした。
パンチカード１枚には、80桁の数字を記録できました。
これをもう少し汎用的に考え、「１行のテキストに、複数のデータ列がある」と考えます。
パンチカードの束がデータベースであるならば、複数行のテキストもデータベースです。
ここまでは言い方を変えただけで、特に複雑なことはありません。
表計算ソフト…たとえばエクセルに沢山データを蓄えて「データベース」としている人もいると思います。同じことです。
たとえば、お店の商品台帳をデータベース化したとします。
商品が無くなったら、メーカーに連絡を入れて追加発注しなくてはなりません。
住所と電話番号も、商品ごとに記載しておくべきでしょうか？
それは、あまりにも手間が多いです。
ここはメーカー台帳を別に用意するべきでしょう。
商品台帳とメーカー台帳を別々に作ります。
商品を元にメーカー名を調べ、メーカー名を元にメーカー台帳を調べれば連絡先がわかります。
ここまでは、パンチカード形式でも問題なく実現できます。
ある時、メーカーが社名変更したとします。メーカー台帳のメーカー名を書き変えます。
しかし、これは「商品のメーカー名を元に、メーカー台帳を調べる」という流れを壊してしまいます。
商品台帳の方のメーカー名も、同じように書き変えなくてはなりません。
データが何万件あるかわかりませんが…まぁ、今のコンピューターなら一瞬でしょう。
でも、もっといい方法があります。
メーカー名も、メーカー台帳の方にだけ書いておき、商品の方のメーカーには「メーカー台帳のメーカー番号」だけを書き込むのです。
メーカー名で調べる代わりに、メーカー番号で調べる。
この番号は、メーカー台帳の中で一意に決まっていれば、どんなものでも問題ありません。
これで解決？
いや、これでは、今度は別の問題が起こります。
商品台帳を見て、商品を作っているメーカー名を知りたいだけで、いちいちメーカー台帳を調べなくてはならないのです。
これは手間が増えてしまいます。
説明が長くなりましたが、このくらいまで「データベースを使いこなす」ようになって、やっとリレーショナルデータベース（以下 RDB ）の優位性が出てきます。
RDB では、データベースの表（ここでは、商品台帳とメーカー台帳）の間の関係性を記述することで、データを適切に扱えるようになります。
データとしては、上に書いたように商品台帳とメーカー台帳が別々に保存されています。
しかし、商品台帳のメーカー番号欄は、メーカー台帳のメーカー番号と一致している、と教えてやるだけで、商品名とそのメーカー名を同時に取り出せるようになるのです。
データベースなのですから、それまでの「パンチカード」式のシステムで出来たことは、当然全てできます。
これが、複数の表にまたがっていても検索可能なのです。
たとえば、商品がアンパンなのだけど、作っているメーカーが神奈川県にある物だけを全て抽出、なんてことができます。
RDB でなければ、アンパンを全て探し出してメーカー番号を調べ、メーカー番号からメーカーの所在を調べ、神奈川のものだけを抽出…という手順が必要となります。
＃もちろん、RDB の内部ではそのような手順を使っています。
しかし、RDB が面倒な部分を請け負うことで、RDB 利用のアプリケーションは簡単に作れるようになるのです。
さて、コッドがこのシステムを論文として発表した時、IBM はパンチカードを元としたデータベースを作成・販売していました。
せっかく開発したこの「商品」を否定するような論文に、IBM は反発します。
しかし、コッドの論文は世界に広まってしまいました。
他社も論文を元としたシステムの開発を開始し、IBM も開発に着手せざるを得なくなります。
そこで、IBM は SyetemR と呼ばれる、RDB 開発プロジェクトを開始します。
ただし、このプロジェクトにコッドは招聘されませんでした。
あくまでも IBM が自主的に開始したプロジェクトであり、社内の１研究員に過ぎないコッドの意見を聞いたわけではないのです。
SystemR では SEQUEL という言語が開発され、これが後の SQL になります。
IBM が最初の SQL データベースを発表し、他社も後を追うように SQL を使用するデータベースを発表していきます。
SQL はコッドが考えた言語ではなく、SystemR の成果でした。
すぐに「SQL を利用していれば RDB である」という誤解が広まり、それまで作られていた、パンチカードを模倣したようなデータベースを SQL 対応にしたような製品も出てきます。
コッドはこれに反発します。内部的にパンチカード同様のシステムはもちろん、IBM の製品すらも、コッドが当初考えていた「理想のデータベース」には程遠いものでした。
コッドはこれらのデータベースを批判し、RDB を規定する「コッドの12の規則」を発表します。
しかし、それは彼が勤めている IBM を批判することでもありました。
彼は会社に居づらくなり、独立してコンサルティング会社を設立します。
その後、コッドは OLAP という、新たな概念のデータベースを提唱しています。
これは現在、実際に広く利用されています。
RDB は、複数の表を利用していたため、メモリの節約などのメリットがある一方で、速度的には不利でした。
OLAP では、データ内のどんな要素についての集計・分類などでも、高速に答えを出すように考えられています。
たとえば、日本全国にチェーン店を持つお店が、毎日のように全ての売り上げデータをデータとして蓄積しているとしましょう。
これは、非常に大きなデータですが、OLAP ではこの集計を瞬時に行えます。
関東地方に住む30代の女性によく売れているお菓子の銘柄ベスト５…とか、条件を与えれば瞬時に集計してくれるのです。
こうしたシステムがあることが前提で、人間が想像もしていなかった項目からデータの相関性を自動的に見つけ出す「データマイニング」や、非常に多数のデータを扱う「ビッグデータ」などの、現在でも続く流行が生まれてくることになります。
コッドは、データベースの世界に２度の革命を起こしたのです。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |