データベースの理論的な部分を
を基に学んでいく。
今日のまとめ
- データベースとは計算機上での利用を前提としたデータの集まりおよび管理するシステムの総称を指す。
- データベースの概念としては1970年に発表された関係データベースを基にした関係データベース管理システム(RDBMS)が一般的になっている。
- 関係データベースは数学の意味での関係をデータベースへ応用したものである。データベースにおいては関係をリレーションと呼ぶ。データベースにおいてテーブルはリレーションを表示するための手段にすぎず、関係データベースの本質はリレーションである。
- しかしデータ量の飛躍的増大など時代のニーズを受けて既存のRDBMSに囚われないデータベース管理システム(NoSQL)の開発が進んでいる。
1. はじめに
データベースはもともと、ある目的を持って集められたデータを意味する。最近は計算機上での利用を前提としたデータの集まりおよび管理するシステムの総称として用いる。後者を特に指す場合には、データベース管理システム(DBMS)と呼ぶ。
1.1 データベースの歴史
データベースの概念は1960年代に磁気テープなどのシーケンシャルアクセス*1の記憶装置からディスクやドラムなどのランダムアクセスが可能な記憶装置が使われるようになっていく過程で生まれた。
1970年にIBMのE.F. Coddが発表した「関係データベース(RDB)」により、数学を背景とした理論的な概念が評価され、さまざまな研究者や企業が関係データベース管理システム(RDBMS)を開発するようになった。これにより問い合わせ言語の標準化が議論され、1986年にはが定まり、その翌年にはこれが国際規格になった。1992年に改訂されとなり、ここで標準的なコマンドの規格が定義された。
日本ではなどを詐称する形でというデータベース言語に関する規格が制定されている。
1.2 NoSQL
RDBMSは広くされるようになるにつれて、逆にRDBMSでは上手く扱うことのできないデータに対してRDBMSとは異なるDBMSが提案されるようになった。1980年代中盤にはオブジェクト指向型言語の興隆を受けてオブジェクトDBMS(Object DBMS: ODBMS)が利用されるようになった。
次に1990年代中盤に登場したXML(eXtensible Markup Language)を転機としてインターネットを前提としたデータ利用に向けて開発が進んだ。これによりRDBMSが苦手とする階層型データの定義が容易になるとともに柔軟にデータ構造を変更できるようになった。また2001年にXQueryがW3C(World Wide Web Consortium)の草案として提案され、操作も標準化された*2。
いまはデータベースで扱うデータ量が飛躍的に増大したことを受け、大量のデータを効率的に扱うための新しいDBMSの開発に関するニーズが高まっている。
こうしたRDBMSとは異なる新しいDBMSはNoSQLと呼ばれるようになった。
2. 関係データベースの基本
関係データベースの基本として、まずはデータの関係モデルを考える。
が提案したデータの関係モデル( )は数学の集合論における「関係」*3の理論をデータベースに応用したものである。
この議論をするために、まずは直積集合を導入する。
2.1. データのリレーションによる表現
直積集合を構成する集合は数の集合でなくとも良い。
例:
野球選手に関するデータベースを作ることを考える。簡単のため、2人の選手を考え、その名前を(選手名)、チームを2つ(チーム名)とし、「はに所属する」、「はに所属する」というデータを得たとする。
このデータを表現するのにタプルを用いてと書くことができる。したがってこれらの選手に関するデータは集合
で表現できる。
選手名の集合をチーム名の集合をとすれば、
で与えられ、タプルの集合はこのの部分集合である。すなわち選手に関するデータを関係モデルで表現したはリレーションである。
実際には各集合が何に関する集合なのかを分かりやすくすべく、として
と書く(出力される。)。
2.2 リレーションのテーブルによる表示
データのリレーションはテーブルの形でユーザに表示させる。テーブルの横の並びを行といい、縦の並びは列という。各データが入力される枠をセルないしフィールドと呼ぶ。
関係データベースを構成するリレーションを作成するのに際し、互いに異なる個の属性に着目する場合を考える。
まず各属性に付随する集合を定める。これは属性が取り得る値の集合であり、属性のドメインという。データは各対象の属性に関する値を成分とするタプルとして表現される。それらのタプルから構成される有限集合は項リレーションである。すなわち
である。
2.2.1 テーブルに関する注意
テーブルはデータのリレーションをユーザが目視できるようにするための装置であり、データの実態はあくまでもリレーションであり、これは直積集合の部分集合であるから、「集合」である。そのため
各対象が集合の要素として属するか否かが焦点であり、要素の順番や回数は関知しない。
ことに注意しなければならない。したがって
- 要素の現れる順番は関知しないことから、テーブルの行の並びは任意で自由に変更できる。
- 要素の現れる回数は関知しないことから、テーブルに同一行が現われてもその重複に意味は無い。
である。
列の並びは直積集合を構成する集合の順番に依存する。そのため、行とは異なり数学的には並びを変更できない。ただし属性を互いに意味を識別できるように命名すれば列の順番を変えても誤解は生じないため、列の並びも任意で自由に変更できるとする立場も存在する。
2.2.2 関係スキーマ
リレーションをテーブルとして表示すると、テーブルがデータであるリレーションに加え、その枠からも構成されることが視覚的に分かる。
属性が(この並びで)テーブルの枠を構成するという事を
と書いて関係スキーマと呼ぶ。を関係スキーマ名という。関係スキーマを構成する属性の列をで表す。
実際にデータベースを構築する際は、まず関係スキーマが設計され、次にデータが入力される。すなわち枠である関係スキーマが与えられ、に含まれる属性に付随するドメインの直積集合の部分集合、すなわち項関係のリレーションとしてデータを獲得した結果、テーブルが構成される。
- 関係スキーマ:
- データのリレーション:
関係スキーマはデータベースの運用を始める前に充分に熟慮した上で設計されるべき対象であり、運用開始以降は原則変更されない。関係スキーマはデータに先立つのである。