マルチバリュー

マルチバリューは、NoSQLの一種で多次元のデータベースである。もともとはPick Operating Systemとして開発されたデータベースで、PICKの同義語と捉えられている。 マルチバリューの商用データベース製品は、ロケット・ソフトウェア、Zumasys、Revelation、Ladybridge、InterSystemsNorthgate 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として分類できるであろう。データモデルは、JSONXMLとよくなじみ、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は、基本の型はいずれも配列で持つことができる。

マルチバリュー 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メールアドレスを示す複数の行を持つ一人の人を出力し、人が持つ他のデータは繰り返さない。

脚注

  1. Nelson, Don (1965年). General Information Retrieval Language and System (GIRLS)”. 2016年3月8日閲覧。
  2. Historical”. Microdata Alumni. 2016年3月8日閲覧。
  3. NPS Reality”. Northgate Public Services. 2016年3月8日閲覧。
  4. MultiValue Symbol”. 2016年3月8日閲覧。
  5. MultiValue Family Tree”. zumasys (2002年). 2016年3月8日閲覧。
  6. MultiValue Family Tree”. zumasys (2015年). 2016年3月8日閲覧。
  7. Post-Relational Database Reference”. 2016年3月8日閲覧。

関連項目

外部リンク

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.