マルチバリュー

**マルチバリュー**は、NoSQLの一種で多次元のデータベースである。もともとはPick Operating Systemとして開発されたデータベースで、PICKの同義語と捉えられている。
マルチバリューの商用データベース製品は、ロケット・ソフトウェア、Zumasys、Revelation、Ladybridge、InterSystems、Northgate Information Solutions、ONgroupやその他の会社から提供されている。これらのデータベースは、すべての属性が一つの値のみを持つのではなく、値のリストを持てる属性をサポートしているという点において、関係データベースとは異なる。データモデルは実際には関係モデルよりも前からあるが、ポスト・関係データベースの一種としてMUMPSに分類される。SQLのデータベース管理システムツールと違って、ほとんどのマルチバリュー・データベースは、SQLを使ってあるいはSQLを使わずにアクセスできる。

## 歴史
Don Nelsonは、マルチバリューデータモデルを1960年代の初めから中ごろにデザインした。Dick Pickは、TRWの開発者として、1965年にUSの陸軍のために、このモデルをはじめて実装した。軍用に書かれたものだったので、Pickはこのソフトウェアがパブリック・ドメインになると考えた。これが、はじめて裁判所によって扱われたマルチバリュー・データベースに関する議論である。

Ken Simmsは、S-BASICとしても知られているDataBASIC を1970年代の中ごろに書いた。これは、ダートマスBASICをベースに、データ管理機能を拡張したものである。

3つのマルチバリューの実装 - PICKバージョンR77、Microdata Reality 3.x、Prime Information 1.0 - は、とてもよく似ていた。特にすべてのロゴをデザインした

International SpectrumとSpectrum Manufactures Associationによる標準化の試みにもかかわらず、マルチバリューの実装において標準は定まっていない。その後、いくつかは合流したが、これらは分岐していった。これらのマルチバリュー・データベース開発の流れは、一つはPICKバージョンR83からの、一つはMicrodata Realityから、一つはPrime Informationからの枝分かれして分類できるであろう。

この違いのために、いくつかの実装が、言語の方言をサポートするために提供されている。類似点や相違点を記述しようとする試みは、Post-Relational Database Reference(PRDB)にて確認できる。

業界内のマーケティングやその他のグループは、数年にわたって、マルチバリュー・データベースをレガシーとする分類に反対し、プレ関係データベース、ポスト関係データベース、関係データベース、組み込みデータベースとして分類してきた。現在は、NoSQLとして分類できるであろう。データモデルは、JSONやXMLとよくなじみ、SQLを使ってあるいはSQLを使わずにアクセスできる。

過去50年以上続くデータモデルに関する一つの有力な理論は、21世紀の新しいデータベース実装により、費用をおさえたデータベース・ソリューションの提供につながる。歴史的にみて、SQLトランザクションに関する業界のベンチマークでは、マルチバリュー・アプリケーションの機能を関係データベースのフレームワークに取り込むために、試行失敗のエピソードがかなりあるが、ベンチマークテストとは異なる説がある。

40年以上の歴史があるにもかかわらず、マルチバリュー業界の多くは現在も残っており、さまざまなマルチバリューの実装がオブジェクト指向型のData/BASIC、AJAXフレームワークのサポートを採用している。これらのデータベースの利用にSQLを使う必要がないため（使うことは可能だが）、NoSQLの傘下に入れるのが適切である。実際、マルチバリューの開発者は、最初にNoSQL領域のスキルを得ていた。マルチバリューは、マルチバリュー領域における複数のベンダーの成熟したデータモデルであり、長期に渡り拡張されてきた。

## データモデルの例
マルチバリュー・データベースでは、
* データベースあるいはスキーマは、"アカウント" という
* テーブルあるいは コレクションは、"ファイル" という
* 列あるいはフィールドは、"フィールド" あるいは "属性" といい、"マルチバリュー属性" と "サブバリュー属性" からなり、1つの属性に複数の値を保存できる
* 行あるいはドキュメントは、"レコード" あるいは "アイテム" という
データは、2つのファイル－RAWデータを保存するための "ファイル" とRAWデータの表示形式を保存するための "ディクショナリー" －に保存される。

例えば、”PERSON”というファイル(テーブル)があるとする。ファイルには、"eMailAddress" という属性がある。"eMailAddress" フィールドは、一つのレコードに複数のEメールアドレスの値を持つことができる。リスト [joe@example.com, jdb@example.net, joe_bacde@example.org]を保存でき、関連するレコードは、一つのクエリの中で取得できる。伝統的な関係データベースの世界で、これと同じ1対多の関係を扱うには、1件の "PERSON" レコードに関係する複数のEメールアドレスの値を保存する別のテーブルを作成して持つことになる。しかし、最近の関係データベースでは、このマルチバリューのデータモデルもサポートするものがある。例えば、PostgreSQLは、基本の型はいずれも配列で持つことができる。

## マルチバリュー DataBASIC
Javaのように、典型的なData/BASICコンパイラは、Pコードにコンパイルし、Pマシン 内で動く（jBASEは除く）。マルチバリュー・データベースが複数あるのと同じくらい多くの異なる実装（コンパイラ）がある。PHPのように、Data/BASIC言語はすべての型のキャストが可能である。

## マルチバリュー・クエリー言語
異なるマルチバリューの実装に対応して、ENGLISH、ACCESS、AQL、UniQuery、Retrieve、CMQLや多くのほかの名前で知られており、マルチバリュー・クエリー言語は、さまざまな点でSQLとは異なる。各クエリーは、スキーマ内の一つのディクショナリーに対して発行する。そして仮想ファイルや、データの参照を通したデータベースへのポータルとして解釈される。
:LIST PERSON LAST_NAME FIRST_NAME EMAIL_ADDRESSES WITH LAST_NAME LIKE "Van..."
上記ステートメントは、姓が "Van" で始まる人の姓、名、Eメールアドレスをすべてリストする。一つのエントリーは、複数のEメールアドレスを示す複数の行を持つ一人の人を出力し、人が持つ他のデータは繰り返さない。

## 脚注

## 関連項目
*Rocket U2 (UniVerse and UniData)
*OpenInsight by Revelation
*OpenQM by Ladybridge Systems
*Reality by Northgate-IS
*Caché by InterSystems
*Pick Operating System

## 外部リンク
* DB-Engines Ranking of Multivalue DBMS by popularity, updated monthly