03-1
システム間データ連携におけるセマンティック層の活用
Plactical Design of Semantic Layer in Inter-system Data Integration
山中
遼太
Ryota Yamanaka
日本オラクル株式会社
Oracle Corporation Japan
Abstract: Semantic technologies posess great capability for integrating data from different systems,
while other standard architectures such as dementional model have been used for building integrated data warehouses. In this report, we discuss the plactical design for introducing semantic layer to existing inter-system data integration. As a result, we conclude that the semantic layer does not alternate the roles of data warehouse and data mart but they should be built together.
1. はじめに
セマンティック・ウェブを実現するための技術と して，RDF や SPARQL といったセマンティック技 術の標準が策定され，これらを実装するためのモデ リング・ツール，データ変換ツール，RDF を格納 および検索するためのデータベース管理システムが 利用可能になった．相互運用性を高めるためにセマ ンティック技術が有用であることが示され，インタ ーネットだけでなく，組織内のイントラネット上の システムにおいても複数のシステムのデータを統合 するための手法としてセマンティック技術をどのよ うに活用できるかが注目されている[1]． その一方，従来からシステム間データ連携におい ては，複数の情報源から得られるデータをデータウ ェアハウスに統合，アプリケーションに最適なデー タマートの構築，するといった設計手法が確立し， このためのデータ変換のツールも充実している．そ こで，既存のシステム間データ連携の設計ノウハウ やツールを利用しつつセマンティック層を導入する ためには，従来のデータストアとのデータの受け渡 し順序や必要なデータ変換を考慮する必要がある． また，アプリケーションからデータを参照する際に 既存システム同様の充分なレスポンスを実現するた めの設計上の工夫も重要である． そこで，本報告では，一般的なシステム間データ 連携を概観した後，セマンティック層を導入する際 の検討課題を挙げ，最適な設計を議論する．（ただ し，セマンティック層を導入することによる相互運 用性の向上といったメリットの有無については，本 報告では議論しない．）2. 背景
ここでは，一般的なシステム間データ連携におけ るデータストアとデータ変換の役割について記述す る．その上で，セマンティック層を活用する際の課 題を挙げる．2.1. データストア
システム間データ連携におけるデータの格納場所 （データストア）として，ソースデータ，データウ ェアハウス，データマートについて説明する．各デ ータストアはコストや検索性能に対して最適なデー タベース管理システムまたはファイルシステムを用 いてデータを格納している． まず，情報源となるデータ（ソースデータ）は複 数存在しており，これらの連携が目的とされる．ソ ースデータの格納には，関係データベースやファイ ルシステムを使用している場合が多いが，近年は HDFS（Hadoop Distributed File System），KVS（Key Value Store），ドキュメント型データベースなどの 非関係データベース（NOSQL データベース）が用 いられる場合もある．非関係データベースは未整形 データを格納および検索するために最適であること が多く，このような未整形データの管理を目的とし たデータストアはデータレイクと呼ばれる．システ ム間データ連携のソースデータとして，この他にレ ガシーシステム上のデータが含まれることも多い． 次に，データウェアハウスは，分析のため複数の システムのデータを統合したもので，格納されるデ ータは一般的に，サブジェクト指向，統合されてい ること，更新されないこと，時系列な過去データを03-2 含むこと，といった特性を持つとされる[2]．関係 データベース上に構築されることが多く，ビジネ ス・インテリジェンス（BI）アプリケーションから 参照される．近年では，ログ解析など大量のデータ を分析する目的で，データウェアハウスを構築せず に，データレイク上のデータを視覚化するアプリケ ーションも利用されている． データマートは，アプリケーションの検索性能要 件に応じて個別に性能最適に設計されるデータスト アである．通常は関係データベース上に構築された データウェアハウスのデータを切り出し，非正規化 など適切に変換されたデータを同じく関係データベ ース上のデータマートにロードする． 図1: 一般的なデータストアの位置づけ セマンティック層では，オントロジーを参照する ことにより，一つの組織内でマスタ情報管理を閉じ ることなく，組織の外部のデータと，一意なID を 共有したり，関係性を定義したりすることができ る．このような役割を持つデータストアは，セマン ティック・データレイクと呼ばれることもあるが， ここでは，データレイクとしての用途を強調してい ないため，セマンティック層と呼ぶこととする．セ マンティック層のデータは，一般的にRDF データ ベース（トリプルストアと呼ばれることもある）に 格納され，アプリケーションからアクセスする際の 標準としてSPARQL クエリを使用できる．
2.2. データ変換
システム間データ連携においては，通常，ソース データをデータウェアハウスにロードできるように データ変換が必要となる．この処理には，不必要な 文字列を除去するなどソースデータのみに基づく処 理もある一方，複数ソースデータのキーや値を一致 させるといった，データウェアハウスのマスタ情報 の参照が必要と処理もある．さらに，データウェア ハウスのスキーマに基いて，複数のソースデータを 結合，正規化するといった処理もここに含まれる． SQL のような宣言的な言語でデータ変換を明示的 に記述可能な場合もあるが，曖昧さを考慮した単語 の突合や，さらにはテキストマイニングや機械学習 の利用など，SQL では記述できない場合も多い[3]. 上記のようなデータ変換に加えて，セマンティッ ク層の構築においては，データのRDF への変換が 必要となる．この変換は，スクリプト言語などによ る手続き型プログラミングによって都度実装される 場合も多い一方，表データやXML データからの宣 言的なマッピングも提案されている．本報告では， データストアに関係データベースが使用される一般 的なシステム間データ連携において実用的な手法と して，表形式からRDF へのデータ変換のマッピン グ記述を検討する．このようなマッピング記述とし て，W3C では Direct Mapping と R2RML の二つの 標準が策定しており[4]，前者はあるシステムに閉 じたデータの利用を想定しているのに対し，後者は 外部システムの語彙を参照するなど詳細な定義が可 能である．その他にもマッピング記述は提案されて きたが[5]，近年では R2RML が標準的に利用されて いる． 図2: RDF Mapping の位置づけ2.3. 検討課題
以上の背景を踏まえ，セマンティック層をシステ ム間データ連携に活用する際には以下の三つの検討 課題が考えられる． 図3: セマンティック層を活用する際の検討課題 第一に，RDF マッピングを導入によって，従来 のデータ変換の一部を代替する，もしくは省くこと ができるかどうか．第二に，ソースデータを統合す るために，データウェアハウスを設計することなく セマンティック層を構築することができるかどう か．第三に，セマンティック層をアプリケーション で活用する際にどのようなデータマートを構築する ことができるか．これらを検討することで，システ ム間データ連携においてセマンティック層を活用す る際に，同時に構築すべきデータストアとその間の データ変換を整理できると考えられる．03-3
3. 検討
上記の三つの課題に関する机上検討は，いずれも データ変換に着目しており，新たに導入が必要なデ ータ変換である，表データからRDF へのマッピン グの役割を明確にすることは重要である．このデー タ変換にはR2RML 仕様が使用されることを想定し て検討するが，特定の仕様について議論することが 目的ではないため，以後ではこの処理を単に「RDF マッピング」と呼ぶこととする．3.1. データ変換
表1 は主なデータ変換処理について，それぞれの データ変換がRDF マッピングで定義可能であるか どうかを示している．注目すべき点として，データ 変換の処理はSQL によって記述可能なものが多い が，RDF マッピングは関係データベースのビュー を定義してこの返り値を生成するトリプルの値に設 定することが可能（R2RML における rr:sqlQuery） であるため，基本的にSQL で定義できる変換は RDF マッピング内で記述することができる． 一方，SQL で定義できない処理や SQL を使った 場合にも明示的に多段階に分割した方がよい処理 は，RDF マッピングで記述できることはない． SQL で記述できる処理であれば，RDF マッピング の前に実施しておくことが可能なはずであり，SQL によるデータ変換を切り出して実行しておくこと で，RDF マッピングの運用性を向上させる設計の ほうがより実用的であると考えられる． 表1: 主なデータ変換の R2RML による記述可否3.2. データウェアハウス
データウェアハウスに格納されるデータの特性 が，サブジェクト指向であること，統合されている こと，更新されないこと，時系列な過去データを含 むこと，であることは先述したが，これらの特性は セマンティック層のデータにも同様に求められるも のである．特に「サブジェクト指向であること」は データウェアハウス内で各サブジェクトについてデ ータが充分に正規化されていることを意味してお り，これはセマンティック層とのデータの整合性を 担保するために重要である． ここで，RDF マッピングは正規化された（3NF の）表データに対して適用することが想定されてい るという点（ただし，これはR2RML の仕様などに は記載されていない）に注意する．図4, 5 は，部門 と社員が一対多の関係をもつ場合で，データが正規 化されていない例である．正規化されていない （2NF の）表に対して RDF マッピングを実施する 場合には，重複したトリプルが生成されるだけでな く，矛盾したトリプルが生成される場合があること を示している．これに対して，図6 では，正規化さ れたデータに対するRDF マッピングにより重複や 矛盾のないトリプルが生成されている． トリプルの重複をRDF データベース上で除去す ることや，オントロジーを用いたデータ検証により 不正データを検出することは可能ではあるが，これ らの問題はRDF マッピングの前にデータを正規化 しておくことでより前段階で回避することができ る．そうすることで，関係データベースでは検証で きない制約（例えば，データ・プロパティの個数） をオントロジーで明示的に検証でき，実用性の高い 運用が可能となる． 図4: 重複を生じるマッピングの例 図5: 矛盾を生じるマッピングの例03-4 図6: 正規化されたデータのマッピングの例 適切にサブジェクト指向であるデータウェアハウ スでは，何をサブジェクト（セマンティック層のリ ソースに対応）とするかが定義されており，それに 従ってデータが正規化されている．この定義はセマ ンティック層の構築においても必要で，表データの 中でどの列をリソースとするかをRDF マッピング のみで定義するのでなく，データウェアハウス設計 におけるサブジェクトの定義と一貫性をもたせるこ とが現実的な手法である．このことから，RDF マ ッピングを使用したセマンティック層の構築には， 適切にデータが正規化されたデータストアとしての データウェアハウスが必須であると考えられる．
3.3. データマート
データウェアハウスを関係データベース上に構築 する場合，一般的にデータ量の増加によりレスポン ス性能が劣化する可能性がある．また，データの非 正規化など，スキーマを変更することでクエリに対 する性能を最適化できる場合があるため，データマ ートが設計される．多くのRDF データベースは関 係データベース同様，データの増加がレスポンス性 能に影響する可能性があるため[6]，RDF データベ ース上に構築したセマンティック層に対してもデー タマートが必要となることが想定される． このようなデータマートとして，アプリケーショ ンの検索対象となり得るデータのみを絞り込んで格 納したRDF データベースを用いる他，RDF データ ベース以外のデータベース管理システム上に実装す ることも可能である．アプリケーション開発の実績 の多い関係データベースの他，より単純な構造のデ ータを低レスポンスで検索できるKVS，または， RDF が持つグラフ構造からより直接的にデータ変 換が可能なグラフ型データベースの利用も注目され ている．図7, 8 はそれぞれ関係データベースとグラ フ型データベースを用いてデータマートを構築する 例である．いずれの場合も，SPARQL クエリを用い てデータを抽出することで，非正規化された表デー タや，リソース同士の関係をノードとエッジで表現 するグラフデータを生成することができる．この場 合，社員ID からその所在地を検索する，ある社員 と同じ部門に所属する社員を検索する，といった処 理にそれぞれ最適なデータマートを構築できる． 図7: 関係データベースを使用する例 図8: グラフ型データベースを使用する例 データ統合後のセマンティック層ではリソース同 士の複雑な関係性が発生することが多いため，グラ フ型データベースのような柔軟なデータ構造を定義 できるデータベース管理システムはセマンティック 層に対するデータマートとして活用できることが多 い．図9 は，セマンティック層のリソース同士に新 たな関係性が追加された際に，抽出されたグラフデ ータが直感的に把握しやすいデータ構造となってい ることを示している． 図9: リソース同士の関係性が追加される例03-5
4. まとめ
本報告では，一般的なシステム間データ連携にお いてセマンティック層を活用する場合に，データ変 換，データウェアハウス，データマートを設計する 際の検討課題を議論した（図10）． 一般的なシステムでは関係データベースを用いて データが扱われているため，RDF マッピングによ るデータ変換に着目し，このためにデータの正規化 が必要なことから，データウェアハウスの設計がセ マンティック層と併存することが重要であることを 示した．また，データ統合後のセマンティック層の データからデータマートを作成することができ，複 雑な関係性もグラフ型データベースなどの非関係デ ータベースで扱えることを示唆した．以上のような 設計を考慮することにより，一般的なシステム間デ ータ連携において，相互運用性や外部データとの統 合といったセマンティック層の優位点を活用するこ とができると考えられる． 図10: セマンティック層を活用する際の位置づけ参考文献
[1] Decker, Stefan, et al. The semantic web: The roles of
XML and RDF. IEEE Internet computing 4.5 (2000):
63-73.
[2] Inmon, William H., Derek Strauss, and Genia Neushloss. DW 2.0: The architecture for the next
generation of data warehousing. Morgan Kaufmann,
2010.
[3] Kimball, Ralph, and Margy Ross. The data warehouse toolkit: The definitive guide to dimensional modeling. John Wiley & Sons, 2013.
[4] Souripriya Das, Seema Sundara, and Richard Cyganiak.
R2RML: RDB to RDF Mapping Language. W3C
Recommendation 27 September 2012.
[5] Matthias Hert, Gerald Reif, and Harald C. Gall. A
comparison of RDB-to-RDF mapping languages.
Proceedings of the 7th International Conference on Semantic Systems. ACM, 2011.
[6] Curé, Olivier, and Guillaume Blin. RDF database systems: triples storage and SPARQL query processing. Morgan Kaufmann, 2014.
