はじめに
ロケータとは、そのデータが物理ストレージ上のどこにあるのかを示す機能、値のこと。
各DB製品ごとに独自仕様のロケータを持っている。
SQLではキーを利用するが論理的なものなので、本来は物理的ストレージとは無縁のものである。
物理的なロケータをキーやサロゲートキーのように扱うことは、RDBの思想から外れる。
ROWID
OracleDB等に存在するロケータ。
HDDなどのディスクにおける行の物理アドレスを示す。
HDDヘッドはダイレクトに物理アドレスにアクセスできるので、
RoWIDを指定する検索は、アクセスパスとしては最速である。
しかし、これを扱うということは、行がストレージ上に物理的に並ぶことを前提にしているので、
ハッシュや分散データベースのような技術との相性は悪い。
IDENTITY
データが追加される度に一意となる値を自動生成する。
その性質上、主キー制約やユニーク制約をつける。
IDENTITY列やシーケンスなどの自動インクリメントの機能は、
物理的なロケータをユーザに意識させるため、RDBの方針に反している。
※リレーショナルデータベースが満たすべき12の法則(コッドの12の法則)から抜粋
データベースを扱うアプリケーションは、データの物理的レベルにおける表現形式に依存せず、物理的変更があってもアプリケーションは影響を受けない
IDENTITY列の問題
その値が妥当かどうかを確認する手段がない。
SQLServerなどではIDENTITY列は1テーブルに1つしか作れない。
IDENTITYを持つテーブルに対して、同じINSERT文を複数回実行すると結果が毎回異なる。(RDBMSとしては、全ての行について全ての属性が同じ値なら結果は同じになるはず)
一意を示す識別子
データベース全体で一意となる識別子を生成する方法もいくつかある。
GUID
- Microsoftが提唱している
- 物理ロケータやUTC時間、ネットワークアドレスなどを組み合わせて生成する
- ソートできる順序性をもたない
- 集計関数を含むクエリに使えない
- 製品依存のものが多いので、移行が難しい
UUID
- オープンソースコミュニティが提唱している
- 分散システムでも一意に識別するために生まれた
- いくつもバージョンがある
- 第5世代のUUIDはURL,FQDN,オブジェクト識別子などからSHA-1ハッシュ関数によって生成される
その他
重複行について
関係データベースの生みの親、エドガー・F・コッドとしては、
関係データベースにおいて重複行は許さない方針だったようです。
集合論的な考えに基づくと重複行は発生し得ないですね。
しかし、標準SQLとしては重複行を許しています。
「テーブルはエンティティ、クラス、エンティティの関係を表すこともできる」というオブジェクト指向なデータの見方をしているからで、非正規化されたデータをデータベースで扱えるようにするために許容しているようです。
シーケンス生成関数
後半は、どのように一意な値を生成するかという話でした。
数列、素数、乱数を使って値を生成するよ、という話が載っています。(割愛)
小難しい話だったので読み飛ばしました。
最後に
この章のポイントは
「物理ロケータはリレーショナルデータベース本来の方針に反するものなので、安易に採用するべきではない」
ということに尽きると思います。
メリットとデメリットを押さえた上で使いたいところですね。