実体についての事実を読み出す

われわれの圏はトポスであると仮定する．そこでは，始対象initial objectと終対象terminal objectを持つ．集合圏では始対象は空集合，終対象は要素が一個の集合である．記号でそれぞれ，0と1で表す．あるモデルクラスCのインスタンスは，1からC（クラスCをモデル化した圏の対象）へのある射で表される．これをx としたとき，1.x をCでのxの値を表記するものとする．クラスCのある属性をattrとすれば，表記 1.x.attr はその値を表すものとする．これがOOP表記での x.attr に対応することは明らかであろう．属性がメソッドの場合は，attrの部分を関数表記するだけである．通常の圏論では射を矢印で表し，その名前を矢印の上に書くが，表現力の弱いHTMLでそれを表すのは面倒なので，以降，このようなドット記法を使うことにする．

圏では射の合成は射である（という約束）から，属性をたどることでクラスを渡り歩くことが出来る．また，トポスであることを仮定しているから，属性の直和，直積を作ること，および部分対象，ベキ対象を作ること，などが出来，さらに分配則が成り立つ．トポスを仮定することによって，したいこと（たとえば関数を使うメソッドの導入など）がかなり自由に出来るだけでなく，集合概念をよりダイナミックなものにしてくれるのである（後述）．

先述したように，あるモデルクラスの属性すべてを各属性射の直積として表すことが出来る（より一般的には，直和の直積として表せるが，詳細は後述予定）．それをAttrとしたとき，その値は，組tupleで表される．モデルクラスの属性のうち，（計算の都合により設けた属性ではなく）実世界での実体の属性と見なされるものは，事実属性（fact attributes）と呼び，それらの直積をFactとする．FactのグラフがDBのテーブルであるから，テーブルは，<x, x.Fact>の表記の集合である．ここでxは変動する実体のある時点での状態であり，x.Factは事実属性の値の組である．実体自体の識別子run_idや状態の時点の指定はメタデータで行われる．

このようにして，ある実体のある時点における状態の事実をDBのテーブルを読み出すことによって知ることが出来る．

R3は，この考えに基づき実体の事実を記録し，読み出す機構としてRDBを利用する．伝統的RDBは，実体の属性を表すものという基本的な概念がなく，任意の対象の関係relation（つまり対象の直積）表現として考えられたため，適用の自由度が大きすぎ，その結果，実装の場でさまざまな問題を生じ，それを避ける（苦肉の？）手段として，いくつもの正規形条件と呼ぶ制約が考えられている．上述のようにテーブルをFactのグラフとして考えるならば，これらの条件の本質部分はおのずから満たされるため，実装者が考慮すべき条件としては無意味になってしまう．しかも，モデルクラスとの自然な対応があるため，いわゆるO/R マッピングの不整合問題はほとんど生じない（継承などでは不自然で技巧的な処理が必要）．