モデルのインポート¶
概要¶
[Import Model] 機能を使用すると、以下のモデリングツールで作成したモデルを Virtual DataPort にインポートできます。
ER/Studio Data Architect
ERwin Data Modeler
IBM InfoSphere Data Architect
SAP PowerDesigner
Sparx Systems Enterprise Architect
セマンティクスの Web 標準 RDF Schema (RDFS) および Web Ontology Language (OWL) に準拠するモデル
モデルのインポートツールは、上記のデータモデルを Virtual DataPort モデルに変換します。つまり、エンティティ、属性、リレーションシップを抽出し、同等のインターフェイスビューとアソシエーションを Virtual DataPort に作成します。
モデルのインポートツールでは、データモデルの反復的な性質を考慮して、Virtual DataPort モデルとの完全同期または増分同期を実行できます。

データのモデリング¶
モデリングツールを使用して、物理データモデルと論理データモデルを設計します。これらのモデルでは、ビジネス機能に必要な特定の エンティティ 、 属性 、 リレーションシップ を表します。

モデリングツールは、モデリングやビジネスデータポリシー (必須フィールドや必要な形式など) の実施に役立ちます。データ仮想化 (DV) 開発者がこれらのモデルを実装する場合、ポリシーに従う必要があります。
Virtual DataPort などのデータ仮想化ソリューションとモデリングツールは、双方向による統合が可能です。
Virtual DataPort からモデリングツールへの統合:
Virtual DataPort では、ほとんどのモデリングツールで使用可能な JDBC/ODBC などの標準インターフェイスを通じてメタデータを公開し、Denodo データモデルをインポートします。Virtual DataPort が公開するメタデータには、ビューと、そのビューの間のリレーションシップが含まれ、ビュー間のアソシエーションはプライマリキーと外部キーのリレーションシップで表示されます。
モデリングツールから Virtual DataPort への統合:
Virtual DataPort では、ビューとアソシエーションをグラフィカルに作成することも、VQL で作成することもできます。モデルのインポートツール では、モデリングツールで生成されたモデルから インターフェイスのビューとアソシエーションを作成する プロセスを自動化します。参照制約は、Denodo Virtual DataPort での登録条件を満たすアソシエーションに対して登録されます。
インターフェイス は、フィールドの定義と別のビュー (実装ビュー) への参照のみで構成される特殊なタイプのビューです。インターフェイスを使用して トップダウン設計 を行うことができます。この方法では、最初に インターフェイス のフィールドを定義し、後からインターフェイスの 実装ビュー に関連付けます。
トップダウン設計に従って Virtual DataPort でデータサービスを設計する場合、データを取り込むためのアクセスロジックと統合ロジックを実装する前に、 インターフェイス ビューから標準モデルを定義して公開できるため、データ仮想化開発者の作業と、データサービス上に情報や運用のソリューションを構築するクライアントアプリケーション開発者の作業が切り離されます。
RDFS と OWL のオントロジー¶
OWL は、クラス、オブジェクトのプロパティ、データ型のプロパティでデータ構造を表現します。モデルのインポートツールでは、OWL のメタデータをエンティティ-リレーションシップモデルに変換する必要がありますが、OWL の (非常に複雑な) セマンティクスのすべてに対応しているわけではありません。モデルのインポートツールで OWL のどの概念をどのように Virtual DataPort に変換するかについて説明します。
OWL クラスは、Virtual DataPort でインターフェイスに変換されます。クラスはタグのサブクラスを使用して階層状にまとめることができますが、Virtual DataPort にはこの継承の概念がないため、すべてのサブクラスは独自の属性とアソシエーションで個別に作成され、結果として生じる各インターフェイスビューにスーパークラスの属性とアソシエーションが追加されます。
データ型のプロパティは、インターフェイスビューの列に変換され、これらの列の型は常にテキストとして変換されます。
オブジェクトのプロパティは、Virtual DataPort のビュー間のアソシエーションを定義します。カーディナリティは上限と下限で制限されます。カーディナリティの境界が明示されていない場合は、1:n のカーディナリティが使用されます。リレーションの両側が 1:n のカーディナリティを表す場合、このアソシエーションは Virtual DataPort で同期できません。Virtual DataPort ではアソシエーションを n:m で直接 (リレーションシップビューを使用せず) モデリングすることに対応していないためです。
OWL には、逆方向にすることができるオブジェクトのプロパティ (双方向のリレーションシップを定義する方法) があります。Virtual DataPort では双方向のアソシエーションしかないため、OWL 側で逆方向が定義されていない場合でも、Virtual DataPort のアソシエーションは常に双方向になります。アソシエーションに参加するクラスは、オブジェクトのプロパティの範囲とドメインのタグから、あるいはオブジェクトのプロパティに範囲とドメインのタグがない場合はサブクラスの制限から抽出されます。ただし、逆側はオブジェクトのプロパティからしか抽出できず、制限からは抽出できません。アプリケーションではオブジェクトのプロパティ内のエンティティの結合に対応し、この結合が制限内にある場合、Virtual DataPort の結合の各エンティティに対するアソシエーションを作成します。
OWL にはプライマリキーの概念がないため、すべてのインターフェイスで「self_uri」という属性が作成され、アソシエーションのマッピングで使用されます。さらに 1:n の反対側に、オブジェクトのプロパティの名前で別の属性が作成されます。この属性は、マッピングの条件でアソシエーションの反対側で使用されます。
このドキュメントの最後にある「 モデルのインポートツールでサポートされるタグ 」では、モデルのインポートツールでサポートされる OWL 構文についてさらに詳しく説明しています。
使用法¶
このツールを開くには、[Tools] メニュー > [Import model] をクリックします。次に、以下のパラメータを入力する必要があります。
モデリングツールで作成されたモデルを含むファイル。
インポートするモデルのタイプ。
エレメントの比較と作成が行われる Virtual DataPort データベース。
エレメントが作成されるターゲットフォルダ。これはオプションのパラメータです。

モデルのインポートツールは現在、以下のファイルタイプに対応しています。
IDERA ER/Studio Data Architect: 論理または物理 モデルが含まれる .dm1 ファイル。
ERwin Data Modeler: 論理または物理 モデルが含まれる .xml ファイル。
IBM InfoSphere Data Architect: 論理または物理 モデルが含まれる .ldm ファイル。
SAP PowerDesigner: 論理または物理 モデルが含まれる .ldm ファイル。
Sparx Systems Enterprise Architect: .xml ファイル。
RDFS と OWL のオントロジー: .owl および .rdf / .rdfs。
このパラメータを入力して [Analyze Model] ボタンを押すと、モデルのインポートツールではエンティティ、属性、リレーションシップを解析し、それらに関する情報を表示します。どのような場合も、エンティティ間で名前が繰り返される可能性がありますが、Virtual DataPort では許可されません。このため、モデルのインポートツールでは、エンティティ名に「_x」を追加して (x は数字) 名前を変更します。ツールには、以下の内容が表示されます。
モデルの作成に使用されるモデリングツール。

エレメントごとに以下の内容が表示されます。
Virtual DataPort サーバーに関するエレメントのステータス: [New]、[Updated]、[In sync]。
エレメントの名前。
エレメントのタイプ。使用可能な値は [Interface] または [Association] です。
Virtual DataPort での最終変更日。エレメントがすでに Virtual DataPort サーバーにある場合のみ。
エレメントの詳細を表示するボタン。

表にある特定のエレメントの [inspect] ボタンを押すと、以下の内容が表示されます。
検査対象のエレメントのタイプが [Interface] の場合、そのインターフェイスのアソシエーションのリスト。エレメントが [Association] の場合、選択されたエレメントと他のエレメントとのリレーションシップや多重度が表示されます。
Virtual DataPort にエレメントを作成する際に必要な VQL。
エレメントのステータスが [Updated] の場合、分析されたファイルのエレメントと Virtual DataPort のエレメントとの間の変更点。可能な値は [Added]、[Updated]、[Deleted] です。

[Refresh] ボタンをクリックすると、モデルのインポートツールでは、表示されているエレメントを Virtual DataPort カタログで検索し、上記の情報を表示します。
その後、表のエレメントのチェックボックスや、インターフェイスとアソシエーションのチェックボックスを使用して、必要なエレメントを選択できます。
[Update server] をクリックして、選択したエレメントを更新します。
エレメントが新規の場合は、そのエレメントが作成されます。
エレメントが既存の場合は、新しい定義に従ってエレメントが変更されます。

更新プロセスでは、ダミーのインターフェイス実装を作成できます。これを選択すると、モデルのインポートツールでは、モデル内の各インターフェイスの実装に使用される 1 行の null 値でビューを作成します。
以下の画像は、このマニュアルで例示されているモデルの更新プロセスの結果です。importedModels フォルダには、3 つのインターフェイスと 2 つのアソシエーションがあり、そのインターフェイスに対応するダミー実装があります。


制限事項¶
プライマリキー
インターフェイスビューにはプライマリキーがないため、モデルのプライマリキーは反映されません。実行時、インターフェイスのプライマリキーは、その 実装ビュー から自動的に「継承されます」。
null 以外の制約
プライマリキーと同様に、インターフェイスビューでは、null 以外の制約など、列に対する他のタイプの制約を定義できません。そのため、これらの制約はモデルのインポート時に無視されます。
強制的な同期操作は行わない
現在のバージョンのツールでは、すでに「OK」状態としたエレメントを 強制的に 同期することはありません。
STRUCT 型と ARRAY 型
IBM InfoSphere Data Architect からモデルをインポートする場合、BIG SQL の型である STRUCT と ARRAY は TEXT に変換されます。
多対多のアソシエーションの論理モデル
論理モデルの多対多のアソシエーションを Virtual DataPort に変換することはできません。このタイプのアソシエーションには対応していません。たとえば、IBM InfoSphere Data Architect の論理モデルに多対多のアソシエーションを含めることはできますが、これは Virtual DataPort と同期できず、インターフェイスのステータスでは同期不可と表示されます。
マッピングのないアソシエーション
条件マッピング のないアソシエーションでは Virtual DataPort サーバーと同期できず、インターフェイスのステータスは同期不可と表示されます。
同期参照制約
現在のバージョンでは、Virtual DataPort のアソシエーションで、参照制約のプロパティがチェックされているかどうかを検出できません。そのため、Virtual DataPort に関するアソシエーションのステータスを取得する場合、このプロパティは無視されます。
RDFS と OWL のデータ型
OWL クラスの属性のすべてのデータ型は、 text 型として Virtual DataPort に変換されます。
ER/Studio での次元モデル: モデルのインポートツールでは、次元モデルはサポートされていません。サポートされているのはリレーショナルモデルのみです。
モデルのインポートツールでサポートされるタグ¶
これは、モデルのインポートツールでサポートされるタグとそのコンテキストを示す表です。Virtual DataPort 構造体に変換するには、どのタグもコンテキスト内にあるようにします。
タグ |
コンテキスト |
---|---|
<owl:DatatypeProperty> |
|
<owl:ObjectProperty> |
|
<rdfs:domain> |
<owl:ObjectProperty> <owl:DatatypeProperty> |
<rdfs:range> |
<owl:ObjectProperty> <owl:DatatypeProperty> |
<owl:inverseOf> |
<owl:ObjectProperty> |
<owl:Class> |
|
<rdfs:Class> |
|
<rdfs:subClassOf> |
<owl:Class> <rdfs:Class> |
<owl:Restriction> |
<rdfs:subClassOf> |
<owl:onProperty /> |
<owl:Restriction> |
<owl:allValuesFrom> |
<owl:Restriction> |
<owl:someValuesFrom> |
<owl:Restriction> |
<owl:hasValue> |
<owl:Restriction> |
<owl:onClass> |
<owl:Restriction> |
<owl:maxCardinality> |
<owl:Restriction> |
<owl:maxQualifiedCardinality> |
<owl:Restriction> |
<owl:minCardinality> |
<owl:Restriction> |
<owl:minQualifiedCardinality> |
<owl:Restriction> |
<owl:cardinality> |
<owl:Restriction> |
<owl:qualifiedCardinality> |
<owl:Restriction> |
<owl:unionOf> |
<owl:allValuesFrom><owl:Class> |
<rdf:rest> |
<owl:unionOf> |
<rdf:first> |
<owl:unionOf> |