データベースの移行が難しいのは、列名を書き換える作業が多いからだけではありません。顧客と注文、社員と部署、作品と作者のように、表どうしの関係まで壊さずに移さなければならないからです。表を一枚ずつ眺める方法では、複数の経路から得られる情報が一致するという制約を見落としやすくなります。
圏論的データベースは、スキーマを圏、実際のデータを集合値関手として表します。この見方はSQLを置き換える万能製品ではありません。スキーマ、インスタンス、移行を同じ合成の文法で扱い、変更がどこへ波及するかを数学的に記述する研究です。小さな例から、その利点と限界を確かめます。
表の一覧では捉えきれないデータベースの構造
学校のデータベースにStudent、Course、Departmentという表があるとします。StudentからCourseへ履修先を示す参照があり、CourseからDepartmentへ開講部局を示すなら、学生から部局へ二段階でたどれるでしょう。別にStudentからDepartmentへの所属参照を持つ場合、二つの経路が同じ意味かどうかも問題になります。
データベース設計では、表だけでなく外部キーと経路の等式も欠かせません。圏は対象、射、合成、恒等射を持つため、この組をそのまま記述できます。表名を対象、外部キーを射、参照の連鎖を射の合成として扱うわけです。
小さな圏として表すデータベーススキーマ
圏論的モデルでは、スキーマSを小さな圏とします。対象Student、Course、Departmentを置き、射takes: Student → Course、offeredBy: Course → Departmentを置けば、合成offeredBy∘takes: Student → Departmentも自動的に存在します。
スキーマに直接belongsTo: Student → Departmentを加え、belongsTo = offeredBy∘takesという経路等式を課すこともできます。この等式は、学生の所属部局が履修科目の開講部局と一致するという強い制約です。現実には一人が複数科目を履修するため単純な関数では足りません。まず一対多関係を別対象Enrollmentとして分解する必要があります。
集合値関手として入る実際のデータ
スキーマS上のインスタンスIは、SからSetへの関手I: S → Setです。各対象へ行の集合を割り当て、各射へ行の集合間の関数を割り当てます。Studentには学生レコードの集合、Courseには科目レコードの集合、takesには各学生を履修科目へ送る関数が入るでしょう。
関手であるため、恒等射は恒等関数へ、射の合成は関数の合成へ送られます。スキーマで二つの経路が等しいなら、データ上でも対応する二つの参照結果は一致しなければなりません。構造上の制約が、インスタンスへ自動的に引き継がれる仕組みです。
属性を型へ向かう射として組み込む
学生名や生年月日、科目名のような属性も射として表せます。StudentからStringへname、StudentからDateへbirthDateという射を置き、StringやDateをデータ型の対象として扱います。
初期の単純な集合値関手モデルでは、文字列や数値の演算、比較、制約の扱いが弱いという課題がありました。そのため代数的データベースでは、多ソート代数理論を組み込み、整数の加算や文字列操作などを原理的に扱う拡張が研究されています。「何でも圏にすれば解決する」のではなく、具体的なデータ型の性質を追加する必要があるのです。
自然変換がデータを保ったままインスタンスを移す
同じスキーマS上に二つのインスタンスIとJがあるとき、自然変換η: I ⇒ Jは各表の行を対応先の行へ送ります。ただし、表ごとの写像は外部キーと整合しなければなりません。
学生Aliceを別システムの学生A102へ移し、Aliceの履修科目をMathからM01へ移すなら、先に学生を移してから新システムの履修参照をたどる結果と、旧システムで履修科目をたどってから科目を移す結果が一致します。自然性の正方形が、参照関係を壊さないレコード移送の条件になります。
スキーマ写像として働く関手
スキーマSから別のスキーマTへの関手F: S → Tは、表と参照をT側の表と参照経路へ対応させます。部署を持つ旧スキーマを、組織単位というより一般的な表を持つ新スキーマへ移す、といった設計変更を記述できます。
Fは射の合成と経路等式を保つため、参照の意味を無制限に変える写像ではありません。スキーマ変更のうち、どの構造を保存するのかが明示されます。この関手から、代表的な三種類のデータ移行関手Δ、Σ、Πが導かれます。
引き戻しΔが新しい見方で既存データを参照する
F: S → TとT上のインスタンスJがあるとき、ΔF(J)=J∘FによってS上のインスタンスを得られます。スキーマ関手Fに沿ってデータを引き戻す操作で、単純な合成として定義できます。
新しいスキーマの一部だけを旧スキーマの形で見せるビューや、列・表の選択に近い働きを持ちます。Δは情報を実際に複製して移す場合だけでなく、別のスキーマ越しに同じデータを見る方法を与えます。
左Kan拡張Σがデータをまとめて前へ送る
ΔFには左随伴ΣFが存在する条件もあるでしょう。ΣはS上のインスタンスをT側へ押し進め、対応するデータを余極限によってまとめます。複数の表を一つへ統合したり、新しい識別子を導入したりする移行と関係するのです。
左随伴が余極限を保つという一般則が、ここで具体的なデータ統合へ現れます。ただし、実務上の重複排除やキー生成を自動的に正しく判断するわけではありません。Σが作るのは、与えたスキーマ写像に対する標準的な移行です。意味上の同一人物かどうかといった判断は、モデルの外から与える必要があります。
右Kan拡張Πが整合する組合せを集める
ΔFの右随伴ΠFは、極限を使って整合するデータの組を作ります。関係データベースの結合や、複数の条件を同時に満たす結果の構成に近い側面があります。
Σが選択肢をまとめる余極限的な操作なら、Πは条件をそろえる極限的な操作です。射影、和、結合といった異なるデータ操作を、随伴する三関手Σ ⊣ Δ ⊣ Πの関係として統一できる点が、関手的データ移行の大きな成果です。
経路等式がデータ品質の制約になる
スキーマ圏に経路等式を置くと、インスタンスはその等式を必ず守ります。社員から直属上司を経て部門へ行く経路と、社員から直接所属部門へ行く経路を等しくすれば、上司と部下が同一部門であるという規則を表せます。
もっとも、現実の企業では兼務や部門横断チームがあり、この規則が不適切な場合もあります。圏論は制約の正しさを保証せず、選んだ制約を一貫して適用します。モデルが簡潔であるほど現実も単純だとは限らないため、経路等式を置く前に意味を吟味しなければなりません。
関手圏がスキーマ上の全インスタンスをまとめる
固定したスキーマS上のインスタンスと自然変換は、関手圏[S,Set]を作ります。個々のデータベースだけでなく、同じ設計に従う全データベースと、それらの間の構造を保つ移送を一つの圏として扱えます。
この関手圏には極限と余極限が点ごとに存在し、インスタンスの結合や統合を圏論的に組み立てられます。スキーマを圏と見るだけでなく、データベースの集合全体にも再び圏の構造が現れるのです。
SQLとの競争ではなく意味を保つ移行の理論
圏論的データベースは、成熟した関係データベース管理システムを直ちに置き換えるものではありません。トランザクション、索引、アクセス制御、障害復旧、性能最適化など、実用システムに欠かせない課題は別にあります。
強みは、スキーマとデータ移行を数学的対象として明示し、移行を合成できる点です。二段階の移行を一つの関手として考えられれば、途中の都合に依存しない設計を検討できるでしょう。企業間・研究分野間で異なるデータモデルをつなぐとき、意味をどこまで保存したかを議論する共通言語になります。
関係モデルから関手的モデルへ至る背景
関係データベースは、表を関係として扱う数学的基盤を持っています。圏論的モデルはその代わりに、参照経路と合成を前面へ出しました。David Spivakが2010年に発表した関手的データ移行の枠組みでは、スキーマを圏、インスタンスをSet値関手とし、スキーマ写像から三種類の移行関手を導いています。
重要なのは、既存の関係モデルが誤っていたという主張ではありません。関係代数が一つのデータベース内部の問い合わせに強いのに対し、関手的な方法は異なるスキーマ間の移行と合成を統一的に記述します。焦点の違いが、新しい数学を必要としたのです。
同じデータを別スキーマで見る往復の検査
スキーマSからTへ移したデータを再びSへ戻したとき、元と同じになるとは限りません。表を統合すれば区別が失われ、新しいキーを生成すれば元の識別子へ一意に戻れない場合があります。随伴Σ ⊣ Δ ⊣ Πは、往復が逆関数になるとは主張していません。
代わりに単位と余単位から、元のデータと往復後のデータとの標準的な比較が得られるでしょう。移行で何が増え、何が忘れられたかを比較射として調べられるのです。「移せたか」だけでなく「戻したときにどの情報が残るか」という問いが、移行設計の精度を上げます。
圏論がデータに与えるのは関係の設計図
データベースの圏論的モデルで中心にあるのは、表を抽象語へ言い換えることではありません。外部キーを合成可能な射として扱い、経路等式を制約として表し、スキーマ変更から標準的な移行を導くことです。
極限と余極限、随伴、関手が、ここでは一つの実務的な問題へ合流します。圏論はデータの内容を決めませんが、関係を保って内容を動かすための設計図を与えるのです。