マルチバリュー

マルチバリューは、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は、基本の型はいずれも配列で持つことができる。 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メールアドレスを示す複数の行を持つ一人の人を出力し、人が持つ他のデータは繰り返さない。 ^ a b Nelson, Don (1965年). “General Information Retrieval Language and System (GIRLS)”. 2016年3月8日閲覧。 ^ “Historical”. Microdata Alumni. 2016年3月8日閲覧。 ^ “NPS Reality”. Northgate Public Services. 2016年3月8日閲覧。 ^ “MultiValue Symbol”. 2016年3月8日閲覧。 ^ “MultiValue Family Tree”. zumasys (2002年). 2016年3月8日閲覧。 ^ “MultiValue Family Tree”. zumasys (2015年). 2016年3月8日閲覧。 ^ “Post-Relational Database Reference”. 2016年3月8日閲覧。 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