半構造化データ

半構造化データ^[1]は、リレーショナルデータベースやその他の形式のデータテーブルに関連付けられたデータモデルの表形式構造に従わない構造化データの形式ですが、それでも意味要素を分離し、データ内のレコードとフィールドの階層を強制するためのタグやその他のマーカーが含まれています。そのため、自己記述型構造とも呼ばれます。

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

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

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

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

この事実を考慮すると、XML は、人間中心のフローと階層、および非常に厳密な要素構造とデータ型設定が可能な「柔軟な構造」を備えていると言えるでしょう。

ただし、XML を「人間が読める」という概念は、ある程度までしか解釈できません。Office 2007 以降のバージョンで実装されている Microsoft Word 文書の内容の XML 表現など、XML の実装/方言の中には、特定の問題領域 (Word の場合は、文字、段落、文書レベルでの書式設定、スタイルの定義、引用の挿入など) を反映する数十または数百の異なる種類のタグが使用され、これらのタグは複雑に相互にネストされています。このような XML 文書の一部を読んで理解することさえも、構造のエラーを見つけることは言うまでもなく、特定の XML 実装を事前に十分に理解し、使用されている XML スキーマを理解するソフトウェアの支援がなければ不可能です。このようなテキストは、スワヒリ語 (ラテン アルファベットを使用) で書かれた本が、その言語を一言も知らないアメリカ人や西ヨーロッパ人にとって「人間が理解できる」ものではないのと同じです。タグは、その領域に詳しくない人にとっては意味のない記号です。

JSONまたは JavaScript Object Notation は、人間が読めるテキストを使用してデータ オブジェクトを送信するオープン標準形式です。JSON は、REST原則を利用して開発された Web サービスによって普及しました。

MongoDBやCouchbaseなどのデータベースは、半構造化データ アーキテクチャの利点を活用して、データをネイティブに JSON 形式で保存します。

• アプリケーションからデータベースにオブジェクトを永続化するプログラマーは、オブジェクトリレーショナルインピーダンスミスマッチを心配する必要はなく、軽量ライブラリを介してオブジェクトをシリアル化できる場合がよくあります。
• ネストされたデータや階層化されたデータのサポートにより、エンティティ間の複雑な関係を表すデータ モデルが簡素化されることがよくあります。
• オブジェクトのリストのサポートにより、リストをリレーショナル データ モデルに変換する煩雑な作業が回避され、データ モデルが簡素化されます。

• 従来のリレーショナル データ モデルには、一般的な既成のクエリ言語であるSQLがあります。
• 「ゴミを入れればゴミが出る」傾向があり、データ モデルから制約を取り除くことで、データ アプリケーションを操作するために必要な事前の考慮が少なくなります。

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

このモデルの利点は次のとおりです。

• スキーマによって制約できない一部のデータ ソースの情報を表すことができます。
• 異なるタイプのデータベース間でデータを交換するための柔軟な形式を提供します。
• 構造化データを半構造化データとして表示すると便利です（閲覧目的の場合）。
• スキーマは簡単に変更できます。
• データ転送形式は移植可能です。

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

オブジェクト交換モデル(OEM) は半構造化データを表現するための標準の 1 つであり、もう 1 つの方法はXMLです。

• 半構造化モデル
• ノーSQL
• 非構造化データ
• 構造化データ

• UPenn データベース グループ – 半構造化データと XML
• 半構造化データ分析: リレーショナル プラットフォームか Hadoop プラットフォームか? (IBM 著)