半構造化データ

半構造化データ（はんこうぞうかデータ、英:Semi-structured data）は、リレーショナルデータベースや他の形式のデータテーブルに関連付けられたデータモデルの表構造には従わないが、意味的要素を分離し、データ内のレコードとフィールドの階層を強制するためのタグやその他のマーカーを含む構造化データの形式である。したがって、自己記述型構造とも呼ばれる。

半構造化データでは、同じクラスに属するエンティティがグループ化されていても異なる属性を持つことがあり、属性の順序は重要ではない。

インターネットの出現以来、全文ドキュメントやデータベースが唯一のデータ形式ではなくなり、異なるアプリケーションが情報交換のための媒体を必要とするようになったため、半構造化データの発生が増加している。オブジェクト指向データベースでは、半構造化データがよく見られる。

種類半構造化データを記述するためのフォーマットは、ドキュメント志向であるマークアップ言語とデータ志向であるデータシリアライゼーション言語に大別される。これらは、データ交換や設定ファイルの記述において、相互に補完・代替される関係にある。

マークアップ言語

XML

XML、電子メール、EDI、その他のマークアップ言語、はすべて半構造化データの形式である。オブジェクト交換モデル（Object Exchange Model）は、データ構造を自己記述する手段としてXMLより前に作成された。XMLは、SOAPの原則を利用して開発されたWebサービスによって普及した。

ここで「半構造化」と説明されている一部のデータ型、特にXMLは、リレーショナルテーブルや行と同じ機能レベルでの構造的厳密性を欠いているという印象を持たれがちである。実際、XMLを本質的に半構造化されたもの（以前は「非構造化」と呼ばれていた）とする見方は、データ中心の幅広いアプリケーションへの利用を妨げてきた。通常は半構造化の典型と考えられるドキュメントでさえ、人間の読者による使いやすさを損なうことなく、XML Schemaによって強制され、商用およびカスタムのソフトウェアプログラムの両方で処理されるデータベーススキーマとほぼ同じ厳密さで設計できる。

この事実から、XMLは人間中心のフローと階層、および非常に厳密な要素構造とデータ型付けの機能を持つ「柔軟な構造」を持っていると呼ばれるかもしれない。

しかし、XMLが「人間が読める形式」であるという概念は、ある程度までしか通用しない。Microsoft Office 2007以降のバージョンで実装されているMicrosoft WordドキュメントのコンテンツのXML表現など、XMLの一部の一実装や方言では、特定の問題領域を反映する数十、あるいは数百もの異なる種類のタグを利用している。Wordの場合は、文字、段落、ドキュメントレベルでのフォーマット、スタイルの定義、引用の組み込みなどであり、これらは複雑な方法で相互にネストされている。採用されているXMLスキーマを理解するソフトウェアの支援に加えて、特定のXML実装に関する非常に深い事前の理解がなければ、構造のエラーを見つけることはおろか、そのようなXMLドキュメントの一部を読んで理解することさえ不可能である。そのようなテキストは、（ラテンアルファベットを使用する）スワヒリ語で書かれた本が、その言語の単語を知らないアメリカ人や西ヨーロッパ人にとって理解できないのと同じように、「人間が理解できる」ものではない。つまり、タグはその領域に不慣れな人にとっては無意味な記号なのである。

データシリアライゼーション言語（データシリアライゼーションフォーマット）

JSON

JSON（JavaScript Object Notation）は、人間が読めるテキストを使用してデータオブジェクトを送信するオープン標準フォーマットである。JSONは、RESTの原則を利用して開発されたWebサービスによって普及した。MongoDBやCouchbaseなどのデータベースは、半構造化データアーキテクチャの利点を活用して、データをネイティブにJSON形式で保存する。

YAML

JSONと同様にデータを記述するためのシリアライズ形式。可読性をあげるために、インデントを用いて階層を表す仕様になっている。名称そのものが「YAML Ain't Markup Language」という再帰的頭字語になっており、ドキュメントのマークアップではなく純粋なデータ構造の記述に特化している。JSONと違ってコメントの記述が可能である。

長所と短所

長所

アプリケーションからデータベースにオブジェクトを永続化するプログラマは、オブジェクトリレーショナルインピーダンスミスマッチ（オブジェクト指向言語のデータ構造とRDBのデータ構造が異なり、データ連携時に不整合や実装の複雑化が生じる問題）について心配する必要はなく、多くの場合、軽量ライブラリを介してオブジェクトをシリアライズできる。ネストされたデータまたは階層データのサポートにより、エンティティ間の複雑な関係を表すデータモデルが簡素化されることがよくある。オブジェクトのリストをサポートすることで、リストをリレーショナルデータモデルに面倒な変換を行う必要がなくなり、データモデルが簡素化される。

短所

従来のリレーショナルデータモデルには、一般的で既製のクエリ言語であるSQLがある。「ガベージイン、ガベージアウト」になりやすい。データモデルから制約を取り除くことで、データアプリケーションを操作するために必要な事前の検討が少なくなる。

半構造化モデル半構造化モデルは、データとスキーマの間に分離がないデータベースモデルであり、使用される構造の量は目的に依存する。

このモデルの利点は以下の通りである。

スキーマによって制約できない一部のデータソースの情報を表現できる。異なるタイプのデータベース間でのデータ交換のための柔軟なフォーマットを提供する。（ブラウジングの目的で）構造化データを半構造化データとして表示するのに役立つ場合がある。スキーマは簡単に変更できる。データ転送フォーマットはポータブルである可能性がある。

半構造化データベースモデルを使用する際の主なトレードオフは、リレーショナルモデルのようなより制約のある構造ほど効率的にクエリを実行できないことである。通常、半構造化データベースのレコードは一意のIDで保存され、ディスク上の場所へのポインターで参照される。これにより、ナビゲーションクエリやパスベースのクエリは非常に効率的になるが、多くのレコードを検索する場合（SQLでは典型的）、ポインターをたどってディスク上をシークする必要があるため、それほど効率的ではない。

オブジェクト交換モデル（OEM）は半構造化データを表現する1つの標準であり、別の方法としてXMLがある。

半構造化データ

Źródło i licencja