ソリューション

MarkLogicデータハブサービス

データ統合を高速化し、データガバナンスとセキュティを強化します。インフラストラクチャの購入や管理は不要です。

詳細はこちら

学習

MarkLogicを最大限に活用

ニュース、製品情報、イベントに関する最新情報をメールボックスに直接配信

登録

コミュニティ

MarkLogicを最大限に活用

ニュース、製品情報、イベントに関する最新情報をメールボックスに直接配信

登録

会社情報

MarkLogicを最大限に活用

ニュース、製品情報、イベントに関する最新情報をメールボックスに直接配信

登録

マトリックスからの脱出

マルチモデルデータベースでデータを解放

リレーショナルデータベースは、断片化された行と列の世界にユーザーを閉じ込めます。この強固なマトリックス(=行と列の世界)があらゆる行動の足かせになります。ユーザーは機械の奴隷となり、厳格な規則に縛られ、その専制政治によって世界が支配されてしまいます。今こそリレーショナルデータベースのマトリックスから脱出しましょう。現代的なマルチモデルアプローチでデータを統合し、データを解放して無限の可能性を手にしてください。

ビジネスの「360ビュー」(全体像)が求められる

データはすばやく統合する必要がある

ビジネスに関するデータはますます増加し、データソースもかつてないほど多くなっています。しかしこれらのデータは、リレーショナルモデルの形で複数サイロに分断されて格納されています(登録データベース、フルフィルメント/CRMシステム、提供プラットフォームなど)。こうしたデータをすばやく統合してビジネスの全体像を把握しなければ、データを実際の活動に利用できません。

ETLがアジャイル性(スピード感)を阻止

多種多様なリレーショナルデータベースからのデータを結合する場合、データの抽出/変換/ロード(=ETL)が必須です。その結果、プロセスに時間がかかり、複雑になり、コストが増加します。

データは常に変化している

新たなアプリケーションでは、データを新しい形で表現する必要があります。M&Aにより、管理しなければならないデータの量や種類も変わってきます。新しいコンプライアンス規則により、データの扱い方が変わります。ビジネスのデジタルトランスフォーメーションを進めるには、データをリアルタイムで使用できる必要があります。

「ビジネスを遂行」しながら「ビジネスを観察」

デジタルトランスフォーメーションを推進する際には、「ビジネスを遂行(run the business)」するためのオペレーショナルデータのリアルタイム活用がこれまで以上に増えていきます。これらのデータは複数の業務部門の異なるデータベースに格納されている可能性があります。このように運用上分断されているデータの統合において、時間がかかり過ぎたり、新規ビジネス要件に対応する柔軟性がない場合、デジタルトランスフォーメーションには致命的な問題となります。

同時に、分析的な「ビジネスを観察(observe the business)」する業務においては、用途別にサイロを増やすことなくサイロを管理するのが望ましいでしょう。

ここで問題なのは、リレーショナルデータベースではデータのリアルタイム統合が困難であり、コストもかさむということです。

リレーショナルの問題点

リレーショナルモデルではシンプルなものも複雑になる

シンプルなER図を考えてみましょう。顧客が商品を購入するというトランザクションです。概念的には、非常にシンプルなER図となるはずです。しかし、リレーショナルデータベースに柔軟性がないため、シンプルなER(エンティティ/リレーション)も複雑になります。さらに、リレーショナルデータベースでは似たような情報が別の方法でモデリングされていることもあるため、データの統合が困難です。

すべてのジョインに意味があるわけではない

Blue Gear Auto Parts社のスキーマはシンプルですが、問題があることに気付くでしょう。「Tlines」という結合テーブルを使用していますが、これは私たちが考えるトランザクションとは一致していません。一つのトランザクションには複数の商品が、また一つの商品は複数のトランザクションに含まれる可能性があります。つまり、商品情報の格納には、別途、結合テーブルが必要です。結合テーブルが存在するのは、リレーショナルデータベースには柔軟性がなくデータを行と列の形にあてはめないといけないからです。

スキーマがわかりにくいことがある

リレーショナルスキーマも直感的にわかりにくいものです。たとえば、このCustomerテーブルの「Addr」は何を意味するのでしょうか? テーブルをよく見れば、「Addr」が住所の番地部分であることに気付くでしょう。

情報が変化すると、リレーショナルデータモデルの柔軟性のなさがさらに問題となります。たとえば、顧客レコードに2つ目の住所や電話番号を追加したいとします。この場合、リレーショナルモデルでは新たな結合テーブルが必要になり、スキーマがさらに複雑になります。

柔軟性に欠けるスキーマによるデータの質の低下

リレーショナルデータモデルの硬直性により、別のジレンマも生じます。いったん設計したスキーマを変更するには、今あるものを捨てて最初から作り直すしかありません。将来のニーズ予測を反映したスキーマを作成するにはどうすればいいのでしょうか? また、ビジネスが変化し、データのモデリングを変更する必要が生じた場合は、どうすればいいのでしょうか?

まず、新しいスキーマを設計しデータをETL処理するという、時間とコストがかかる選択肢があります。あるいは、この処理をとばして、データを既存のスキーマに無理やりあてはめることもできます。しかしこの場合、スキーマがデータに合わないためデータの品質が低下します。

Blue Gear Auto Parts社は携帯電話を想定していなかったため、このスキーマでは電話番号を1つしか登録できません。ここではスキーマを設計し直すのではなく、このフィールドに2つの番号を無理やり入れています。

リレーショナルデータモデルには、柔軟性に欠け、変化を拒むという根本的な欠点があります。この欠点がビジネスのアジャイル性(スピード感)を損います。

同一の関係を異なるモデルで表現すると複雑さが増す

Blue Gear Auto Parts社とは異なり、Red Motor Equipment社のスキーマでは、顧客の電話番号と住所を複数登録できます。Red Motor Equipment社のこの業務部門は、おそらく請求情報と配送先情報を処理するために2つの住所を使用していますが、Blue Gear Auto Parts社では配送先住所しか扱っていません。

複雑なスキーマ

より現実的なデータスキーマ

現実では、データのスキーマはもっと複雑です。これは、シンプルなビジネスアプリケーションのスキーマの例です。数万件のテーブルを処理するERPアプリケーションスキーマがどれほど複雑になるか想像してください。

スキーマを統合するとさらに複雑になる

Blue Gear Auto Parts社がRed Motor Equipment社を買収し、2社のデータを統合するケースを考えてみましょう。

この場合、Blue Gear Auto Parts社は、2社のソーススキーマのすべてのデータを格納する、1つのスキーマを作成しなければなりません。その結果、より複雑な「スーパー」スキーマが生み出されます。その過程で、Blue Gear Auto Parts社は、保持する情報と捨てる情報を判断する必要があります。

Red Motor Equipment社には、Blue Gear Auto Parts社より多くの情報があります。現時点では請求先住所は不要かもしれませんが、今後その状況が変化する可能性もあります。

複雑化を避けられない

「スーパー」スキーマはこの図のような構造になるでしょう。このスキーマにはより多くのテーブルが結合されており、さらに複雑になっています。

Blue Gear Auto Parts社は、この「スーパー」スキーマを単純化し、管理しやすくしたいと考えるでしょう。しかし、スキーマを単純化するには、スキーマを特定のユースケースに合わせて設計するしかありません。Blue Gear Auto Parts社がこれを始めた場合、データサイロとETLという無限サイクルに陥ることになります。

サイロ化の原因

ビジネスが変化すれば、データの表現方法も変える必要がある

この場合、リレーショナルデータベースでは、別個のサイロを置いてそのなかに異なるバージョンのデータを準備するしかありません。ソースデータのオリジナルとその変更バージョン、また個々のビジネスニーズに合わせたさらに多くのデータバリエーションが生まれることになります。また、データを変更するたびに何かを捨てることになり、データリネージの追跡が困難になります。

Blue Gear Auto Parts社のシンプルなケースを見てみましょう。Blue Gear Auto Parts社がRed Motor Equipmentを買収した状況において、データは統合した方が良いでしょう。ETLはコストが高く複雑で、システム停止が必然的に発生します。このため、特定のアプリケーションで必要になるまでデータを結合しないという選択肢もありえます。

ETLコストを考慮すると最低限のデータしか利用できない

現時点で、Blue Gear Auto Parts社は、顧客プロファイル把握のために顧客のあらゆる情報を必要としています。そのため、Blue Gear Auto Parts社とRed Motor Equipment社の顧客データをETL処理する必要があります。その後、製品と顧客を分析して、どの顧客が製品に関心を持つかに関する予測を改善できます。その後数年すれば、Blue Gear Auto Parts社では、監査に備えて売上データを統合する必要が出てくるでしょう。その際、監査プロセスの対象外となる情報を削除するために、データを再びETL処理します。その後、データを収益ダッシュボードに表示させるために、データをさらにETL処理します。

わざわざサイロを作ろうとする人はいない

それではこれから先はどうなるのでしょうか? Blue Gear Auto Parts社は、新たなビジネスニーズが生じるたびにデータをETL処理することになります。これによりビジネスに悪影響が出ます。

リレーショナルの柔軟性のなさが多種多様なデータソースを生み出す

ETLを行うたびに、新しいサイロが誕生します。このため一元的なデータソースを実現できません。その代わり、組織内に複数バージョンのデータが存在することになります。ソースデータのオリジナルとその変更バージョン、また個々のビジネスニーズに合わせたさらに多くのデータバリエーションが生まれることになります。さらに、こうした複数のサイロ間でデータリネージ、出自、品質をトラッキングするのは不可能なので、データガバナンスも困難を極めます。

MarkLogicのアプローチ

データを柔軟にモデル化

MarkLogicなどのドキュメントデータベースのデータモデルは、より柔軟です。左側の顧客レコードはリレーショナルデータモデルで表現されたものであり、柔軟性のない行と列に無理やりあてはめられています。

右側は同じ顧客レコードをJSONドキュメントとして表現したものです。ドキュメントモデルの階層構造を用いて、データをドキュメントのように自然に整理しています。配列(配送先住所、請求先住所)と入れ子配列(電話番号)を使用しています。

MarkLogicは極めて柔軟

MarkLogicに情報を追加する場合、単に手持ちの情報をすべて追加するだけです。手元にない情報についてはそのままにしておいてください。電話番号や住所などは自然に階層情報として表示されます。別のテーブルを作成する必要はありません。さらに、MarkLogicはデータの追加時にインデックスを付けるため、すぐにクエリで検索できます。

データを容易にハーモナイズ

データベースに読み込む前にデータを変換する従来のETL処理は不要です。MarkLogicの柔軟なドキュメントデータモデルでは、必要なデータを必要なときにハーモナイズできます。このハーモナイズは、データをトラッキングして管理できる完全にトランザクショナルなデータベース内で行われます。

この例では、郵便番号をハーモナイズしています。ハーモナイズされた「カノニカル」(標準)モデルでは、いずれのデータモデルも「Postal」という名前でまとめられます。

MarkLogicでは、データの一部をカノニカルモデル部分に容易に追加できます。これにより、データに対して一貫性のある検索ができます。モデルは、ビジネスニーズの変化に合わせて進化させることができます。その際、元の生データを破損しないで保持できます。

データリネージを把握

MarkLogicでは、データのモデリングにエンベロープパターンを使用します。この部分に当該ドキュメントに関するメタデータを容易に追加して、データの出自とリネージを保持できます。メタデータ、ソースデータ、カノニカルデータを同一ドキュメント内にすべて格納して検索できます。

エンティティ = ドキュメント

ドキュメントデータモデルは、ビジネスエンティティをモデル化する際の最も柔軟で反復的なアプローチです。

リレーショナルデータベースでは意味がわかりにくい

リレーショナルデータベースは、ER(エンティティ/リレーション)を表すには不向きです。たとえば、Red Motor Equipment社の顧客レコードを見るとジョインが多数あり、テーブル間に関係があることを示しています。しかしこれらの関係の意味を理解するのは困難です。

MarkLogicでのER(エンティティ/リレーション)

同じ顧客レコードをMarkLogicで表現するとこのようになります。

この顧客が「バッテリー」と「ジャンプスターター」を含むトランザクションを完了したことが一目瞭然です。これによりERがはるかに理解しやすくなります。

セマンティックの力

セマンティックでさらに発見

リレーショナルデータモデルでは、データを検索するにはスキーマを理解する必要があります。MarkLogicは違います。

MarkLogicは、セマンティックによりエンティティ/リレーションを分かりやすく表現します。これにより、すばやくかつ簡単にクエリを実行してデータを発見できます。 MarkLogicでは、セマンティックな関係性として豊かな意味を表現できます。関係を明示的に定義しておき、この「関係の意味」に対して直接クエリを実行できます。さらに、「関係の意味」から推論し、新たな情報を作成することもできます。

トリプルによりエンティティとコンセプトを関係づける

リレーショナルデータベースでは、主キーや外部キーでジョイン(結合)して、データをまとめます。しかし、このようなキーによる関係づけからは、その関係が持つ本来の意味は何も分かりません。関係の本来の意味は、アプリケーションコードの中に埋もれています。こうしたジョインの中には、ビジネスにおける本当の関係性を示すものもあります。しかし、リレーショナルモデルにおける、すべてテーブルの行としてしか表現できないという制約による疑似的な関係性もあります。この2つを見分けるにはどうしたらよいでしょうか? これはモデルのセマンティック(意味性)に関する知識がなければ不可能です。

セマンティックがあれば、このトランザクションにコンテキストと明示的な意味を与えることができます。たとえば、MarkLogicでは、同じデータを「顧客2001であるKaren Benderが、製品7001であるバッテリーを購入」のように定義できます。

トリプルを使用することで、セマンティックはデータの関係性を最適な方法でモデル化できます。トリプルは、主語、述語、目的語で構成されています。外部キー、入れ子クエリ、複雑なジョインは不要です。ドキュメントモデルをセマンティックと組み合わせることで、すべてのデータにマルチモデルでアプローチできます。

MarkLogicでは、セマンティックな関係性として豊かな意味を表現できます。意味を明示的に定義し、その意味に対して直接クエリできます。また、その意味から推論を引き出し、新たな情報を作成することもできます。

セマンティックに基づくさまざまなアプリケーション

セマンティックはデータにインテリジェンスをもたらし、以前は困難だったデータに基づく行動を実現します。例:

セマンティックを使用することで、同じものだがデータソースごとに名称が異なるものを定義できます。例えばBlue Gear Auto Parts社はポータブルジャンプスターターを「Jump Starter」と呼び、Red Motor Equipment社は「Jumper Pack」と呼んでいるとします。セマンティックでは、これらを同じ製品だと定義できます。Blue Gear Auto Parts社がRed Motor Equipment社と合併した後に「Jump Starter」で検索すると、名称は異なるがこれと同一の製品も返されます。

情報を関連付けて(ある製品とその付属品など)リコメンデーションシステムを作成したり、顧客の購入の理解を深めたりできます。例えば、Blue Gear Auto Parts社は、バッテリーとジャンプスターターを互いに関連付けて同時購入を促すことができます。セマンティックによりこういった関係性を作成しておけば、Karenがオンラインストアでバッテリーを購入した際に、リコメンデーションシステムがジャンプスターターを提案できます。

この2つの事例は、セマンティックの利用法のほんの一部にすぎません。セマンティックを活用することで、情報の関連付けを解除したり、情報を関連付けてデータのグラフを作成したり、アラートなどを設定できます。

リレーショナル vs MarkLogic

リレーショナル:

ステップ1
統合したいスキーマをすべて集めます。スキーマの意味、用途、共通部分を明らかにします。

ステップ2
利用しないデータを決めます。保持するすべてのデータを対象とする新しいスキーマを設計します。

ステップ3
ETLコード(ソースからのデータ抽出/新しいスキーマへの変換/そのターゲットスキーマを持つ新規データベースへの読み込み)を記述します。

ステップ4
検索で使用できるインデックスを作成します。

ステップ5
アプリケーションを構築します。

ステップ1~5を繰り返す
ビジネスニーズが変化するたびに、このステップを繰り返します。

MarkLogic:

ステップ1
まずソーススキーマを2、3個、サンプルレコードをいくつか入手します。

ステップ2
これらをMarkLogicにそのまま読み込み、MarkLogicのビルトインの検索機能を使用して現状のデータを理解します。

ステップ3
ハーモナイズを反復し、アジャイルにモデルを構築します。

ステップ4
必要に応じてデータにアクセスします。

MarkLogicデータベース

エンタープライズ仕様。卓越した柔軟性

MarkLogicでは、単に一つのアプリケーションを構築できるだけではありません。無限の可能性を持つ、すべてのデータを格納するプラットフォームを構築できます。最初は一つの使用方法しかないかもしれませんが、そこで利用されているデータは、他の多くの使用方法でも活用できます。個々のアプリケーション用に新たなサイロを生み出すことはありません。

MarkLogicのオペレーショナルデータハブ

この図は、MarkLogicのオペレーショナルデータハブ(ODH)を社内アーキテクチャに組み込んだものを表しています。さまざまなデータソースからのデータを読み込んだあと、価値を提供しています。このプラットフォームにおいて、MarkLogicには、多様なデータ(JSON、XML、テキスト、地理情報、セマンティックトリプルなど)が格納され、インデックスを利用することで高速な検索が実現されています。さらに、高速なデータアクセスおよびアプリケーション開発のためのAPIにより、短時間でビジネス価値をもたらします。MarkLogicのODHがあれば、データが変化してもビジネスの妨げにはなりません。

ビジネスの360°ビュー(全体像)

MarkLogicは、業界をリードするセキュリティ、プライバシー、コンプライアンス、ライフサイクル管理機能により、データガバナンス規則を順守します。このシステムは、完全なマルチドキュメントACIDトランザクションを実現するだけでなく、信頼性と可用性に優れています。MarkLogicは、オンプレミスやクラウドを問わず、高可用性とレプリケーション機能を発揮し、要求が高い環境でもデータのスムーズな流れを維持できます。

MarkLogicがあれば、必要に応じてデータを徐々に変更できます。つまり、リスクを抑えながら迅速に業務を進めていくことができます。また最も重要なこととして、完了したプロジェクトは組織の資産となり、これをビジネスニーズに応じて進化させることができます。

あなたのデータにはもっと価値があります

MarkLogicの柔軟なデータモデルにより、 コストを抑えながらデータを迅速に統合できます。MarkLogicでデータを解放しましょう。

無料版MarkLogicをダウンロード

MarkLogicソリューションの詳細

電子書籍をダウンロードしてさらに詳しく