ファイルの record とは異なる ITEM という考え方
本稿は、RDBMSの実務経験を前提とした技術者向けの覚書である。
MultiValue DBMSを知らなくても、RDB設計に違和感を覚えた人を想定している。
なお、本稿は MultiValue DBMS の採用を勧めるものではなく、主眼は、データを「行」ではなく「存在単位」として設計する視点を提示することにある。
PICK OSの子孫であるMultiValue系DBMSにおいては、RDBMSでいうところのROW（行、タプル）またファイルシステムでのRECORDに相当するものを ITEM （アイテム）と呼び、カラムまたはフィールド相当を ATTRIBUTE（属性）と呼ぶ。
ITEM の構造は ATTRIBUTE の中に VALUE が1個以上入っているというシンプルなものである（VALUEがNULLである場合も含む）。注意点として「値」として「VALUE」が基本単位であるということ。従来概念から類推するような「フィールドの値が分割されたもの」という考えとは大きく異なる。これは ITEM を設計する即ち結果として属性に意味を持たせる上で大変重要な基本視点となる。尚、ここでいうレベルのVALUE とは概念値であり、物理的な長さの制限は無く、型も持たない。型はより上位概念である FILE（RDBMSにおけるテーブルに相当）として扱う際に、そのメタデータである辞書部（DICTIONARY FILE）のITEMによって規定される。つまりSQLに相当するような照会言語はこの辞書部を通してVALUEを扱う。
補足（RDBMS使用者は読み飛ばして構いません）： subvalue について
因みに、上図では混乱を避けるため除いたが subvalue という単位も存在する。これは VALUE が分割されたものであって基本単位ではなく、基本単位の一部である。また実装されているマルチバリュー用照会言語（UniVerseでのRetrieve等）では、設計当初より この区別が明確ではない。加えて、ここでは紙面の都合上説明していないが、仮想フィールド等でTRANS関数にて読み込まれたVALUEは必ずsubvalueとしてシフトダウンされる（但し再度シフトアップして戻すことは可能）等いろいろ難しい（これらはNested relation としてMultiValueを捉えたときにVALUEを補佐するものとしてsubvalue が必要になることがわかる証なのだが）。
よって簡単に言えば、subvalueは刹那的に使用するよう心がけるべきであると言える。
考察： ITEM は論理モデル？
現在では、ITEMとは従来ファイルシステムのRECORDを発展させた「論理構造モデル」として捉えるべきであろう（1980年代におけるPICKでは同時に物理構造でもあった）。またこれは PICK OS後に現れたオブジェクトに近似しているとも言える。
ITEM は必ず任意でユニークな ID（=ITEM ID） を有する。これはRDBMS風に見れば PK（プライマリーキー）に相当する。実際、マルチバリューを無視すればたいていの ITEM は ITEM ID を PK とする第3正規形で表されることが多い。しかし私は、この ITEM ID は PK よりも OID（オブジェクト識別子 Object IDentifier）により近いものではないか（この場合は論理OIDを指す）と考えている。参考として、下記に一般書籍より抜粋した文章を記す：
『RDBMSの関係モデルにおいては、各レコードを値の組み合わせとして表現し、その表現が等しければ同じレコードとみなす。これを一般に「値に基づく表現 value-based representation」と呼ぶ。一方、オブジェクトの場合は、まずオブジェクトが存在し、それに性質が付随する形になる。つまり、性質が同一でも同じオブジェクトとは限らないのである。これをオブジェクト識別性と言い「識別子IDに基づく表現 IDentity-based representation」と呼ぶ。特に、オブジェクトの永続性（persistency）とは、この ID の生存期間に関する性質を言う。データベースにとっては永続性を扱うことが本質的なことなので、この視点は特に重要である。』（以上「新データベース論 横田一正、宮崎収兄著 共立出版」より抜粋して加筆）
つまり、一般に ITEM ID は通常の PK よりも、その役割は重要ということである。永続性ということを考えれば、後々変更を伴うような ID をつけるべきではないというわけだ。理想的にはアプリケーションに依存するような ID を持たせなければ可能だ。しかし、実際にはMultivalueシステムにおいてもITEM IDによるリレーションを全く抜きにして設計することは大きなシステムではナンセンスであり、よって性能の観点からアプリケーション依存するようなIDを命名せざるを得ない箇所が必ず存在する。ならばどうすべきか。
ITEM ID の命名においてはアプリケーションというよりも、その仕事自体の本質に依存する「意味」を持たせてしまうことである。問題は依存することではなく、不安定であるということ。だから安定した名であれば良い（この辺りがエンジニアリングが数学などとは大きく異なる点である。「完全」ではなく「妥当」イイカゲン（良い加減）の調和を探せるかがエンジニアの腕の見せ所だ。実際にid命名を含む優れたデータモデルは仕事依存する。もし仕事依存しないデータモデルを作りたいならORマッピングで十分だ。セマンティックギャップの問題が無い仕事など人がやる価値はない）。
それでもIDに意味を持たせたくないなら別の見方をしよう。ID ではなく ITEM がそれ自体単体として意味を持つようにする（実は「関係が意味単位として完結」しているというRDB教義の本質でもある）。つまり悪いERモデル（＝ERモデルの適用方法が適切でないモデル）の断片的ROWのようにならないことである。マルチバリューモデルを採用できれば、RDBMSの正規形に比較してテーブルの数を極端に減らすことが可能であり、それぞれのテーブル自体がそれ自身で完結したもの（他の関連テーブルを見なくとも意味がわかるということ）にしやすい。一般に小～中規模のシステムにおいて大変有効な手段である。
いずれにしても、UniVerse等、現Multivalue DBMSが基本的に ITEM ID を中心に考えていることがわかる例としては、このITEM IDの集合を扱うことを大前提として色々な命令が備えられている点である。例えば、検索条件の対象としてITEMの中身を調べ、その結果として該当したITEMのID群（これをselect-list （選択リスト）と呼ぶ）に名前をつけて刹那的にも永続的にも保持（これをsave-list と呼ぶ）しておくような命令が完備している。そして必要に応じてこれらを単体として、又は複数の save-list として呼び出し、それらの「和・積・差」または補集合をとって絞込み、それら結果をあらゆるコマンドやプログラムから利用することができるようにしている。
UniVerse DBMSにおける ITEM ID 操作例：
下記はある２つの検索結果群 JINJIIDS と SALESIDS の積(intersect)をとり、それに新たに SHOUKYUIDS と
名前を付けて保持する命令である。
MERGE.LIST JINJIIDS INTERSECT SALESIDS TO SHOUKYUIDS
本稿は2014年に書いた原文をもとに、表記のみを最小限整えたものである。