リレーショナル・データベースの「関係」にまつわるオハナシ
言葉
関係データベース、RDBMS。
話。
「参照整合性みたいな感じで関係を持っているからRDBMSと言うんだよ」
一理あり、一見筋も通っていそうだけど、ほんとに?
SQLの習慣では、リレーションを「テーブル (table)」、属性を「列(column)」、タプルを「行(row)」と呼ぶ。
数学的なリレーションの話
RDBMSはリレーション(テーブル)を使っているから、そういう名前がつけられたものなんだけど、そもそもリレーションってタプル(行)の集合だから、タプルは属性を原子的な値に写像するものなのです。
例えば、
{name: 'Takaya Hashiguchi', p.age: 25}
属性は、属性ヘッダ行(つまり列)で定義されてて、ドメインや制約型がついてることもある。
例えば、
{name: string, age: int}
これがリレーショナルな構造を表現する要点。
RDBMS、リレーショナル・データベース
名前は数学的だけど、実装は割りと実用的。
なぜ、数学的な話を持ちだしたかというと、リレーショナル・データベースが数学的な「関係」であることを強調したいから。外部キーを使って他のテーブルと「関係」を持つからじゃない。
そうした制約は関係のない話。
リレーショナル・データベースは、数学的な側面があんまり表に出ていない。
出さないようにしている?
でも、ユーザは強力なクエリを表現できるし、システムも規定のパターンで最適化できるから、リレーショナルモデルの力は数学によるところが大っきいと思う。
RDBMSは集合論から派生した関係代数をもとにして構築されてて、射影、選択、結合(デカルト積、つまりJOIN)などを組み合わせたもの。
nameだけを返す、つまり -> SELECT x.name
People を x に改名する、つまり -> FROM People x
age が nullのところを選択する、つまり -> WHERE x.age IS NULL
リレーションを物理テーブル(配列の配列。DB入門で永遠と繰り返されるアレ)と考えちゃうと、開発現場では苦しくなってくる。
例えば、すべての行をイテレートするようなコードを書きかねない。弊社にはある。
リレーションのクエリは、どちらかと言えば宣言型だし、関係代数に変換できる組関係演算という数学をもとにしたものなので、RDBMSの実装は、代数を変換する過程でクエリを最適化できる(というか、しているはず)。
{t:{name}| ∃ x:{name,age} (x ∈ People ∧ x.age = ω ∧ t.name=x.name)}
上記は以下のSQLと同じもの。
SELECT x.name FROM People x WHERE x.age IS NULL