University関連24時間365日対応カスタマーサポートパートナー企業MarkLogicイベントMarkLogicデータハブサービスデータ統合を高速化し、データガバナンスとセキュティを強化します。インフラストラクチャの購入や管理は不要です。関連リンクコンサルティングサービスMarkLogicの顧客に会うリソースを表示するMarkLogicデータハブサービスデータ統合を高速化し、データガバナンスとセキュティを強化します。インフラストラクチャの購入や管理は不要です。MarkLogicマトリックスからの脱出マルチモデルデータベースでデータを解放リレーショナルデータベースは、断片化された行と列の世界にユーザーを閉じ込めます。この強固なマトリックス(=行と列の世界)があらゆる行動の足かせになります。ユーザーは機械の奴隷となり、厳格な規則に縛られ、その専制政治によって世界が支配されてしまいます。今こそリレーショナルデータベースのマトリックスから脱出しましょう。現代的なマルチモデルアプローチでデータを統合し、データを解放して無限の可能性を手にしてください。MarkLogicMarkLogicデータベース詳細はこちらビジネスの「360ビュー」(全体像)が求められるデータはすばやく統合する必要があるビジネスに関するデータはますます増加し、データソースもかつてないほど多くなっています。これらのデータは、リレーショナルモデルの形で複数サイロに分断されて格納されています(登録データベース、フルフィルメント/CRMシステム、提供プラットフォームなど)。したデータをすばやく統合してビジネスの全体像を把握しなければ、データを実際の活動に利用できません。多種多様なリレーショナルデータベースからのデータを結合する場合、データの抽出/変換/ロード(=ETL)が必須です。その結果、プロセスに時間がかかり、複雑になり、コストが増加します。データは常に変化している新たなアプリケーションでは、データを新しい形で表現する必要があります。M&Aにより、管理しなければならないデータの量や種類も変わってきます。新しいコンプライアンス規則により、データの扱い方が変わります。ビジネスのデジタルトランスフォーメーションを進めるには、データをリアルタイムで使用できる必要があります。business)」するためのオペレーショナルデータのリアルタイム活用がこれまで以上に増えていきます。これらのデータは複数の業務部門の異なるデータベースに格納されている可能性があります。このように運用上分断されているデータの統合において、時間がかかり過ぎたり、新規ビジネス要件に対応する柔軟性がない場合、デジタルトランスフォーメーションには致命的な問題となります。business)」する業務においては、用途別にサイロを増やすことなくサイロを管理するのが望ましいでしょう。ここで問題なのは、リレーショナルデータベースではデータのリアルタイム統合が困難であり、コストもかさむということです。リレーショナルの問題点リレーショナルモデルではシンプルなものも複雑になるシンプルなER図を考えてみましょう。顧客が商品を購入するというトランザクションです。概念的には、非常にシンプルなER図となるはずです。リレーショナルデータベースに柔軟性がないため、シンプルなER(エンティティ/リレーション)も複雑になります。リレーショナルデータベースでは似たような情報が別の方法でモデリングされていることもあるため、データの統合が困難です。Parts社のスキーマはシンプルですが、問題があることに気付くでしょう。「Tlines」という結合テーブルを使用していますが、これは私たちが考えるトランザクションとは一致していません。一つのトランザクションには複数の商品が、また一つの商品は複数のトランザクションに含まれる可能性があります。商品情報の格納には、別途、結合テーブルが必要です。結合テーブルが存在するのは、リレーショナルデータベースには柔軟性がなくデータを行と列の形にあてはめないといけないからです。スキーマがわかりにくいことがあるリレーショナルスキーマも直感的にわかりにくいものです。テーブルをよく見れば、「Addr」が住所の番地部分であることに気付くでしょう。情報が変化すると、リレーショナルデータモデルの柔軟性のなさがさらに問題となります。顧客レコードに2つ目の住所や電話番号を追加したいとします。この場合、リレーショナルモデルでは新たな結合テーブルが必要になり、スキーマがさらに複雑になります。柔軟性に欠けるスキーマによるデータの質の低下リレーショナルデータモデルの硬直性により、別のジレンマも生じます。設計したスキーマを変更するには、今あるものを捨てて最初から作り直すしかありません。ビジネスが変化し、データのモデリングを変更する必要が生じた場合は、どうすればいいのでしょうか?まず、新しいスキーマを設計しデータをETL処理するという、時間とコストがかかる選択肢があります。この処理をとばして、データを既存のスキーマに無理やりあてはめることもできます。この場合、スキーマがデータに合わないためデータの品質が低下します。Parts社は携帯電話を想定していなかったため、このスキーマでは電話番号を1つしか登録できません。ここではスキーマを設計し直すのではなく、このフィールドに2つの番号を無理やり入れています。リレーショナルデータモデルには、柔軟性に欠け、変化を拒むという根本的な欠点があります。この欠点がビジネスのアジャイル性(スピード感)を損います。Equipment社のスキーマでは、顧客の電話番号と住所を複数登録できます。Parts社では配送先住所しか扱っていません。複雑なスキーマより現実的なデータスキーマ現実では、データのスキーマはもっと複雑です。これは、シンプルなビジネスアプリケーションのスキーマの例です。数万件のテーブルを処理するERPアプリケーションスキーマがどれほど複雑になるか想像してください。Equipment社を買収し、2社のデータを統合するケースを考えてみましょう。Parts社は、2社のソーススキーマのすべてのデータを格納する、1つのスキーマを作成しなければなりません。その結果、より複雑な「スーパー」スキーマが生み出されます。Parts社は、保持する情報と捨てる情報を判断する必要があります。Parts社より多くの情報があります。現時点では請求先住所は不要かもしれませんが、今後その状況が変化する可能性もあります。複雑化を避けられない「スーパー」スキーマはこの図のような構造になるでしょう。このスキーマにはより多くのテーブルが結合されており、さらに複雑になっています。Parts社は、この「スーパー」スキーマを単純化し、管理しやすくしたいと考えるでしょう。スキーマを単純化するには、スキーマを特定のユースケースに合わせて設計するしかありません。Parts社がこれを始めた場合、データサイロとETLという無限サイクルに陥ることになります。サイロ化の原因ビジネスが変化すれば、データの表現方法も変える必要があるこの場合、リレーショナルデータベースでは、別個のサイロを置いてそのなかに異なるバージョンのデータを準備するしかありません。ソースデータのオリジナルとその変更バージョン、また個々のビジネスニーズに合わせたさらに多くのデータバリエーションが生まれることになります。データを変更するたびに何かを捨てることになり、データリネージの追跡が困難になります。Parts社のシンプルなケースを見てみましょう。Equipmentを買収した状況において、データは統合した方が良いでしょう。ETLはコストが高く複雑で、システム停止が必然的に発生します。このため、特定のアプリケーションで必要になるまでデータを結合しないという選択肢もありえます。Parts社は、顧客プロファイル把握のために顧客のあらゆる情報を必要としています。Equipment社の顧客データをETL処理する必要があります。その後、製品と顧客を分析して、どの顧客が製品に関心を持つかに関する予測を改善できます。Parts社では、監査に備えて売上データを統合する必要が出てくるでしょう。その際、監査プロセスの対象外となる情報を削除するために、データを再びETL処理します。その後、データを収益ダッシュボードに表示させるために、データをさらにETL処理します。Parts社は、新たなビジネスニーズが生じるたびにデータをETL処理することになります。これによりビジネスに悪影響が出ます。リレーショナルの柔軟性のなさが多種多様なデータソースを生み出すETLを行うたびに、新しいサイロが誕生します。このため一元的なデータソースを実現できません。その代わり、組織内に複数バージョンのデータが存在することになります。ソースデータのオリジナルとその変更バージョン、また個々のビジネスニーズに合わせたさらに多くのデータバリエーションが生まれることになります。した複数のサイロ間でデータリネージ、出自、品質をトラッキングするのは不可能なので、データガバナンスも困難を極めます。MarkLogicのアプローチデータを柔軟にモデル化MarkLogicなどのドキュメントデータベースのデータモデルは、より柔軟です。左側の顧客レコードはリレーショナルデータモデルで表現されたものであり、柔軟性のない行と列に無理やりあてはめられています。右側は同じ顧客レコードをJSONドキュメントとして表現したものです。ドキュメントモデルの階層構造を用いて、データをドキュメントのように自然に整理しています。)と入れ子配列(電話番号)を使用しています。MarkLogicは極めて柔軟MarkLogicに情報を追加する場合、単に手持ちの情報をすべて追加するだけです。手元にない情報についてはそのままにしておいてください。電話番号や住所などは自然に階層情報として表示されます。別のテーブルを作成する必要はありません。MarkLogicはデータの追加時にインデックスを付けるため、すぐにクエリで検索できます。データを容易にハーモナイズデータベースに読み込む前にデータを変換する従来のETL処理は不要です。MarkLogicの柔軟なドキュメントデータモデルでは、必要なデータを必要なときにハーモナイズできます。このハーモナイズは、データをトラッキングして管理できる完全にトランザクショナルなデータベース内で行われます。この例では、郵便番号をハーモナイズしています。ハーモナイズされた「カノニカル」(標準)モデルでは、いずれのデータモデルも「Postal」という名前でまとめられます。MarkLogicでは、データの一部をカノニカルモデル部分に容易に追加できます。これにより、データに対して一貫性のある検索ができます。モデルは、ビジネスニーズの変化に合わせて進化させることができます。その際、元の生データを破損しないで保持できます。データリネージを把握MarkLogicでは、データのモデリングにエンベロープパターンを使用します。この部分に当該ドキュメントに関するメタデータを容易に追加して、データの出自とリネージを保持できます。メタデータ、ソースデータ、カノニカルデータを同一ドキュメント内にすべて格納して検索できます。ドキュメントドキュメントデータモデルは、ビジネスエンティティをモデル化する際の最も柔軟で反復的なアプローチです。リレーショナルデータベースでは意味がわかりにくいリレーショナルデータベースは、ER(エンティティ/リレーション)を表すには不向きです。Equipment社の顧客レコードを見るとジョインが多数あり、テーブル間に関係があることを示しています。これらの関係の意味を理解するのは困難です。MarkLogicでのER(エンティティ/リレーション)同じ顧客レコードをMarkLogicで表現するとこのようになります。この顧客が「バッテリー」と「ジャンプスターター」を含むトランザクションを完了したことが一目瞭然です。これによりERがはるかに理解しやすくなります。セマンティックの力セマンティックでさらに発見リレーショナルデータモデルでは、データを検索するにはスキーマを理解する必要があります。MarkLogicは違います。MarkLogicは、セマンティックによりエンティティ/リレーションを分かりやすく表現します。これにより、すばやくかつ簡単にクエリを実行してデータを発見できます。MarkLogicでは、セマンティックな関係性として豊かな意味を表現できます。関係を明示的に定義しておき、この「関係の意味」に対して直接クエリを実行できます。「関係の意味」から推論し、新たな情報を作成することもできます。トリプルによりエンティティとコンセプトを関係づけるリレーショナルデータベースでは、主キーや外部キーでジョイン(結合)して、データをまとめます。このようなキーによる関係づけからは、その関係が持つ本来の意味は何も分かりません。関係の本来の意味は、アプリケーションコードの中に埋もれています。したジョインの中には、ビジネスにおける本当の関係性を示すものもあります。リレーショナルモデルにおける、すべてテーブルの行としてしか表現できないという制約による疑似的な関係性もあります。これはモデルのセマンティック(意味性)に関する知識がなければ不可能です。セマンティックがあれば、このトランザクションにコンテキストと明示的な意味を与えることができます。Benderが、製品7001であるバッテリーを購入」のように定義できます。トリプルを使用することで、セマンティックはデータの関係性を最適な方法でモデル化できます。外部キー、入れ子クエリ、複雑なジョインは不要です。ドキュメントモデルをセマンティックと組み合わせることで、すべてのデータにマルチモデルでアプローチできます。MarkLogicでは、セマンティックな関係性として豊かな意味を表現できます。意味を明示的に定義し、その意味に対して直接クエリできます。その意味から推論を引き出し、新たな情報を作成することもできます。セマンティックに基づくさまざまなアプリケーションセマンティックはデータにインテリジェンスをもたらし、以前は困難だったデータに基づく行動を実現します。例:セマンティックを使用することで、同じものだがデータソースごとに名称が異なるものを定義できます。Pack」と呼んでいるとします。セマンティックでは、これらを同じ製品だと定義できます。Starter」で検索すると、名称は異なるがこれと同一の製品も返されます。情報を関連付けて(ある製品とその付属品など)リコメンデーションシステムを作成したり、顧客の購入の理解を深めたりできます。Parts社は、バッテリーとジャンプスターターを互いに関連付けて同時購入を促すことができます。セマンティックによりこういった関係性を作成しておけば、Karenがオンラインストアでバッテリーを購入した際に、リコメンデーションシステムがジャンプスターターを提案できます。この2つの事例は、セマンティックの利用法のほんの一部にすぎません。セマンティックを活用することで、情報の関連付けを解除したり、情報を関連付けてデータのグラフを作成したり、アラートなどを設定できます。MarkLogicリレーショナル:ステップ1統合したいスキーマをすべて集めます。ステップ2利用しないデータを決めます。保持するすべてのデータを対象とする新しいスキーマを設計します。ステップ3ETLコード(ソースからのデータ抽出/新しいスキーマへの変換/そのターゲットスキーマを持つ新規データベースへの読み込み)を記述します。ステップ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でデータを解放しましょう。Corporationの商標です。その他の商標はそれぞれの所有者に帰属します。