マルチバリュー

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

歴史編集

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

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

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

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

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

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

過去50年以上続くデータモデルに関する一つの有力な理論は^[1]、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は、基本の型はいずれも配列で持つことができる。