リレーショナルの視点から見たMarkLogic：パート2

投稿者: デイヴィッド・カーレット

投稿日: 2020年2月18 0 Comments

データモデリング – リレーショナルからMarkLogicへ

本記事は、リレーショナルデータベースのバックグラウンドを持つユーザーに向けたブログシリーズの第2回です。MarkLogicによるデータの統合とアクセスにはどのような違いがあるかを理解するのに役立ちます。

要約：

MarkLogicのデータモデリングは、ユーザーデータへのアクセスに関する特定のプロジェクト目標の達成に焦点を絞った反復プロセスです。一方、リレーショナルアプローチでは大掛かりな事前のデータモデリングとETLが必要です。
MarkLogicでのベストプラクティスは、受信/読み込み時のままデータを保持し、拡張およびハーモナイズは追加項目として行う方法です。
MarkLogicは3層アーキテクチャのスマートデータベースであるため、従来のミドルティア機能の一部をデータ層に移行するのが最適です。
MarkLogic TDE（Template-Driven Extraction）により、例えばBIツールのようなエンドユーザーアプリケーションをサポートするために、ドキュメントデータのSQLビューを作成できます。

データモデリングはITの重要な要素です。事実、コンピュータが発明されて以降のコンピュータサイエンスにおいて、データディクショナリは最も重要なイノベーションに位置付けられています。データディクショナリがあれば、データを作成したアプリケーションの内部の知識をまったく持たないユーザーやアプリケーションも、そのデータを理解してアクセスできます。

しかし近年は、データモデリングがプロジェクトの期限超過や失敗の主な原因になっています。これは、大規模なITプロジェクトに必要なデータモデリングや変換が原因で、実際の開発が開始する前に期限を過ぎてしまう事例が多く発生しているためです。

MarkLogicでのデータモデリングは、この問題を最小限に抑えます。MarkLogicでのモデリングはリレーショナル環境でのモデリングと異なりますが、これには様々な理由があります。

読み込む前だけでなく、読み込んだ後にもデータをモデリングできます。
MarkLogic では、すべての属性をモデリングする必要はありません。
MarkLogicでは、データのすべてのドキュメント/レコードが異なるスキーマを持つことができます。
MarkLogicのユニバーサルインデックスは、データ（属性名）に埋め込まれた暗黙的なスキーマをデータとして扱い、正式なモデリングなしで、構造化クエリなどの実用的な機能を公開します。このとき、正式なデータディクショナリ/スキーマは必要ありません。

これらすべてが、従来のシステムと比較してモデリングやETLを大幅に削減できる、まったく異なるモデリング体験を実現します。

モデリングを考える

MarkLogicで効果的にデータモデリングを行う場合、複雑なシステムでは段階的に実行し、成果物の要件に合わせて調整する必要がある点を理解することが重要です。

リレーショナルシステムでのモデリングは、ウォーターフォールアプローチです。スキーマを定義し、ETLプロセスを作成して、データを読み込む前にこのモデルに適合するようデータを変換します。単純なケースであれば、これで十分機能します。

しかし、複数の重複するソースシステムを統合する必要がある場合、ウォーターフォールアプローチでは破綻します。モデリングやETLの作業は時に長期間を要し、開発を開始する前にプロジェクト期限を超過してしまうことすらあります。これが多くの大規模ITプロジェクトの失敗要因になっています。

MarkLogicを使用する場合、長期目標の理解は必要ですが、次のプロジェクトの成果物を完成するために必要なモデリングに集中するべきです。最初のプロジェクトで行った作業はデータベースに組み込まれ、次のプロジェクトの基盤になります。1つのプロジェクトで行われた作業が、孤立したサイロに閉じ込められることはありません。

通常、ユーザーが必要とするデータアクセスを最初に検討する必要があります。明示的にモデリングする必要があるデータ要素には、WHERE節の列（集約が必要なもの）と、広い意味でハーモナイズが必要なもの（同じ内容でフィールド名が異なるものや単位が異なるもの）があります。

次の成果物にとって重要ではないフィールドのハーモナイズは、それが必要となるタイミングまで延期することができます。ユニバーサルインデックスと検索は強力で、さらにMarkLogicはモデリングされていないデータも保持するため、明示的にモデリングやハーモナイズを行わなくても、すべてのデータへのアクセスが確保されるからです。正式にモデリングされていないデータ要素の構造化検索も、モデリングされていないデータに対するGoogleスタイルの検索も、変わらず実行できます。正式にモデリングまたはハーモナイズされていなくても、常にすべてのデータをドキュメントに表示できます。

一部のデータ要素をモデリングしないことにより、リレーショナルデータベースと比較して、MarkLogicではコストが格段に低くなります。

データの理解

前述したとおり、データディクショナリの主なメリットの1つはデータを理解可能にする点です。MarkLogicでは、データは正式なモデリングなしでも理解しやすい方法で保存されます。ほとんどの場合は引き続きモデリングが必要ですが、データディクショナリの有無が理解しやすさに与える影響は小さくなりました。

リレーショナルでは列と行の長方形でのモデリングが要求されるため、複雑なオブジェクトは分割され、別々の項目として保存されます。そのため、ユーザーは簡単にデータの調査や理解ができません。実際、あまりにも難しすぎるため、多くの場合、複雑なシステムにおけるデータへのアクセスは、アクセスの訓練を受けた熟練のDBAのみに制限されています。

ドキュメントまたはオブジェクトとして整理されたデータは、リレーショナルデータより簡単に理解できます。MarkLogicでは、データを生成したドメインの専門家が作成したとおりにそのデータが保存されます。このため、データのあらゆる側面を完全にモデリングすることは、それほど重要ではありません。

これは、正式なモデリングが重要ではないという意味ではありません。少なくとも、個別のドキュメントやレコードの例を見るのではなく、データの概念を詳しく見ることが頻繁に必要となります。ODBC/JDBCを介してデータにアクセスする場合は、もちろん正式なスキーマが必要です。

MarkLogicと3層アーキテクチャ – スマートデータベースとしてのMarkLogic

3層アーキテクチャは、アプリケーション開発の一般的なアプローチです。ビジネスロジックがミドルティアで保持され、データはデータ層に保存され、ユーザーインターフェイスには独自の層があります。ビジネスロジックをデータ層と、特にUI層から排除すると、新しいUI（携帯電話など）やデータストアを使用する場合にビジネスロジックを重複実装する必要がなくなるため、これは好ましい方法と考えられます。

MarkLogicはこのアプローチに対応していますが、MarkLogicを最大限に活用するためには、従来のミドルティア機能の一部をデータ層に移行する必要があります。

その理由の1つとして、MarkLogicでは変換コードをデータモデルの一部として含むことができる点が挙げられます。この機能がデータ層に備わっている場合、データインフラストラクチャを劇的に改善できる可能性があります。元のデータと標準データ、および変換を1つの場所にまとめることで、出自とリネージに関する問題が大幅に減少します。

2つ目の理由としては、MarkLogicがスマートデータベースである点が挙げられます。MarkLogicでは、セマンティックとドキュメントデータを統合することで、リレーショナルベースのシステムで理解できるよりはるかに深くデータを理解できます。セマンティックトリプルは、概念を特定のデータ要素にリンクし、階層関係の作成とドキュメントへのリンクを可能にします。これらのトリプルをMarkLogicに読み込むことで、MarkLogicはユーザーが所属する業界や組織のドメイン知識にアクセスできるようになり、より正確で高精度のデータアクセスが可能になります。

通常、MarkLogicでのデータモデリングには、ユーザーの組織とアプリケーションの対象領域を記述するオントロジーを含める必要があります。さらに、エンティティ間の関係も記述しなければなりません。

モデリングの仕組み

リレーショナルシステムには、データベースにある各テーブルの構造（各データ列に配置できるデータの種類を含む）、テーブル間のリンク（外部キーを介して実装）、各テーブルに関連付けられたインデックスを定義するスキーマがあります。このスキーマは受動的で、データを記述します。すべてのデータは、このスキーマに適合しなければなりません。

テーブルの上には、構造化ビューを作成できます。ビューは異なるテーブル間のデータをリンクして1つにまとめ、そのビューのユーザーが必要としない列を非表示にできます。

MarkLogicでは、当社のエンティティサービスを使用してリレーショナルアプローチを実行できます。ただし、MarkLogicスキーマは単なるテーブルには収まりきらない能性があります。

通常、MarkLogicでのデータモデリングは段階的です。このアプローチでは、まず明示的なスキーマがないか、限定的なスキーマのみの状態でデータが読み込まれます。さらなるハーモナイズが必要と判断されると、スキーマと変換が拡張されます（変更は入力データだけでなく、既存データにも適用されます）。データセット全体には引き続きアクセスでき、正式にモデリングされていない側面でも検索やクエリを実行できます。データのSQLビューは、正式なスキーマが定義されていない場合も作成できます。

正式なモデリング – エンティティサービス

MarkLogicでは、エンティティサービスと呼ばれる機能を使用して正式なデータディクショナリが作成されます。

MarkLogicとリレーショナルシステムの重要な違いとしては、この種類の規範的スキーマを使用する場合、一部のデータ変換はデータディクショナリの明示的な一部であり、モデリングの外で処理される別の手順ではない点が挙げられます。また、エクスポート/リロードを実行したり、データへのアクセスを遮断したりすることなく、定期的にデータモデルを拡張してデータ属性を追加できます。これは、常にデータを受信したとおりに保持し、追加項目として拡張やハーモナイズを行うことをMarkLogicのベストプラクティスとしているからこそ可能な方法です。リレーショナルシステムでの実行は難しいでしょう。

モデリング – 要点

エンティティサービスでは、データモデルはドキュメントとトリプルの組み合わせとして、JSONまたはXMLで定義されます。モデルの基礎は、グラフィカルツールを介してエンティティサービスで定義でき、オントロジーを使用して拡張できます。

モデルが構築されると、MarkLogicは混合データを標準モデルに変換するプロセスを作成します。このプロセスは、エンティティの記述とともに定義されるため、MarkLogicはモデルの一部としてデータ形式と変換を組み合わせることができます。

MarkLogicはコード生成を実行して、エンティティ間におけるリンクの自動作成、リネージのトラッキング、モデルのSQLビューの生成、混合データを共通モデルや他のタスクに読み込むためのテンプレートを有効にします。

SQLを使用したビューの作成

MarkLogic Template Driven Extraction (TDE)を使用して、ドキュメントデータのSQLビューを作成できます。
このようなビューから、

FPML data in document view

簡単にこのようなビューに変換できます。

FPML data in SQL view

MarkLogicは、複雑なドキュメント指向データを取得し、ユーザーがSQLを介してドキュメント内のデータ配置を記述するテンプレートを使用できるようにします。

ビューは、複雑なオブジェクト指向の基礎データセットを取り出して、フラットなSQLビューに追加できます。

SQLビューを定義しても、データへのアクセスが制限されることは決してありません。
同じ基礎データはXMLやJSONとしてアクセスでき、REST呼び出し, MarkLogic Java Client API、その他のメソッドでもアクセスできます。

MarkLogicで、MarkLogicデータベース内におけるデータアクセスの主要形式をSQLに制限することは、MarkLogicベースのアプリケーションを構築する方法として最適とは言えません。
なぜなら、アプリケーションがアプリケーション自体をごまかすことになるからです。リレーショナルテクノロジーの表現力や能力は、MarkLogicのそれをはるかに下回ります。

とは言え、MarkLogicにはSQLビューに含まれないデータ属性に対しても、ユニバーサルインデックスなどの機能にアクセスできるSQL拡張機能があります。

多くの場合、BIツールなど一部のアプリケーションでは、SQLビューはエンドユーザーがMarkLogicの正式なデータモデルにアクセスするための主な方法です。