JP2011154653A - データモデリング方法及び装置及びプログラム - Google Patents

Abstract

【課題】 XMLDB向けのデータモデリングの物理設計において正規形の維持と性能向上の両立を図る。
【解決手段】 本発明は、XMLDB向けのデータモデリングにおいて、概念設計は従来のRDB向けの手法を適用し、論理設計はXMLの木構造モデルを用いて簡素化し、物理設計は、エンティティ間のリレーションシップを従来の技術の主キーと外部キー属性による表現（基本形式）とXMLドキュメント内の構造による構造による表現（統合形式）により、アプリケーションの振る舞い（ＡＰパターン）を考慮して、XML文書形式の設計において、同時にアクセスされている属性群を抽出し、属性群が他のＡＰと競合していない場合にはグループ化し、競合する場合は所定の条件により総合的にグループ化して物理データモデルを生成し、物理データモデルに対応したスキーマを生成する。
【選択図】 図１

Description

本発明は、データモデリング方法及び装置及びプログラムに係り、特に、構造化データである多数のXMLデータのような構造化データを取り扱うシステムの設計において、具体的なXMLデータ構造を設計するためのデータモデリング方法及び装置及びプログラムに関する。

一定量以上のデータの管理が必要となる情報システムを設計する場合、データベース管理システム（DBMS）が利用され、そのために、通常、データモデリングと呼ばれるシステムで管理するデータ構造の設計作業が行われる。

データモデリングは、システムで利用するDBMSを対象に、以下の３種類のデータモデリングを順次設計していく。

（１）概念データモデル：
DBMSに依存しない抽象的なデータモデルであり、情報の意味的な側面を記述する。

（２）論理データモデル：
DBMSが対象とするモデルに依存したデータモデルで、例えば、関係データベース（RDB）の場合、テーブル（表）、カラム（列）等から構成されるリレーショナルモデルとなり、概念データモデルからの変形が行われる。

（３）物理データモデル：
データベースの物理的な内部構造を決定するものであり、性能を考慮し、論理データモデルから変形が行われる。

これらのデータベースモデルを設計することを、それぞれ、概念設計、論理設計、物理設計と呼ぶ。

一般に、データモデリングの技法として、実体関連図（ER図）（例えば、非特許文献１参照）や統一モデリング言語（UML）のクラス図が用いられる。また、従来はDBMSには関係データベース（RDB）が用いられている。

そして、上記技法に対する支援ツールが用意されており、ER図は、概念、論理、物理データモデルを描画することができ、そこから自動的にRDBスキーマ（テーブル定義、カラム定義DDL）を出力する、といった機能を持つものもある。

以下に、従来手法であるRDB向けのデータモデリングについて、ER図を用いて説明する。

＜概念設計＞
まず、概念設計では、エンティティ（事象／人／物などの管理対象）と、リレーションシップ（エンティティ間の関連）、さらに、属性（エンティティのデータ項目）を洗い出す。例として、学校の生徒を管理するシステムの概念データモデルをER図として図１８に示す。このようなER図を支援ツールを用いて描画することができる。

表記法として、IDEF1Xと呼ばれる記法を用いており、図１８において、「クラス」、「生徒」、「部活動」、「試験成績」、といった情報のまとまりがエンティティである。同図において、エンティティ間を結んでいる線がリレーションシップを表しており、黒丸はエンティティの関係が１：N(１対多)である「N」側を表している。一般に、「１」側を「親（エンティティ）」、「N」側を「子（エンティティ）」と呼ぶ。従って、「クラス」と「生徒」の関係は１：Nであり、「生徒」と「試験成績」の関係も１：Nである。双方に黒丸がある「部活動」と「生徒」の関係はＭ：Ｎ(多対多)を表している。エンティティの中に書かれているものが属性で、区切り線の上にある属性（群）が「主キー」と呼ばれ、情報を一意に決定することができる項目である。

概念データモデルは、データの冗長性と不整合を回避した正規形であることが求められるため、実際の設計作業では、エンティティの洗い出し、リレーションシップの洗い出し、正規化（正規形とする作業）といった手順により、作成・修正を繰り返して完成させていく。

また、同じデータモデルをＵＭＬのクラス図で表したものを図１９に示す。ＥＲ図とほぼ同等の情報を記述できるため、こちらを用いてデータモデリングが行われる場合も多い。

＜論理設計＞
次に、論理設計では、リレーショナルモデル（表モデル）の制約を満たすよう、概念データモデルからの変形を行う。例えば、リレーショナルモデルでは、Ｍ：Ｎの関係はそのままでは表現できず、中間に新しいエンティティを新設し、１：Ｎでそれぞれにリレーションシップを作成する必要がある。

また、ＲＤＢでは、エンティティはテーブルに対応し、属性はカラムに対応する。そしてリレーションシップは外部キーと呼ばれる属性を追加することで表現する。図１８をＲＤＢ向けに変形させたＥＲ図の例を図２０に示す。Ｍ：Ｎ関係の部活動と生徒の間に「部活動−生徒関連」というエンティティが追加されている。また、「（ＦＫ）」と書かれている属性が外部キー属性であり、例えば、生徒のクラスコード（ＦＫ）は、クラスの主キーであるクラスコードと同一値を保持することでリレーションシップを表現する、ということを意味している。

支援ツールによっては、図１８の概念データモデルから、（半）自動的にこのような論理データモデルを作成するものもある（新規追加されたエンティティ名などは仮の名称となるため、編集は必要であるため、半自動と表現している）。

＜物理設計＞
物理設計は、主に性能向上を目的に行われる。ＲＤＢにおいて一般的にコストが高い処理は結合処理である。

例えば、図２０に対し、「生徒」と「試験成績」を同時に取得する処理を頻繁に行う場合、「生徒」と「試験成績」の２つのテーブル間の結合処理が必要となり、取得に時間がかかることが懸念される。そこで、物理設計ではあえて正規形を崩し、「試験成績」を「生徒」のエンティティ（＝テーブル）に含めてしまう（テーブル統合を行う）ことで、性能向上を図ったデータモデルを選択するといったことを行う場合がある。その例を図２１に示す。この場合、さらに「試験成績」は、３つまでしか保持できないという制限も加えられている。

支援ツールを用いて論理データモデルから物理データモデルのＥＲ図を編集した後、ＲＤＢスキーマを自動的に出力させることができる。

＜XML及びXMLＤＢ＞
XML（Extensible Markup Language）とはマークアップ言語の一つで、XMLで記述されたデータは構造化され、構造に意味を持ったデータである。図２２はXMLデータとその構造を示した図である。従って、XMLデータは木構造モデルであり、各節をノードと呼ぶ。特に、根のノードをルート要素、値（記述内容）をテキストノード、タグ中に記述されたものを属性（データモデルの属性と区別するため、以降『XML属性』と呼ぶ）、テキストノードとXML属性以外のノードを要素と呼ぶ。また、データ全体をXMLドキュメントと呼ぶ。

このようなXMLデータを管理する機能を有するデータベースがXMLＤＢである。

ＲＤＢのリレーショナルモデルに比べると、表現力が高いことが長所であり、それが故に、逆に取り扱いが難しいことが短所である。

Chen, Peter P. (1976年). "The entity-Relationship Model-Toward a Unified View of Data", ACM Transactions on Database Systems, Vol. 1, No.1, 1976, pp. 9-36.

従来のＲＤＢのデータモデリングでは、物理設計において、性能向上のため正規形を崩してしまう場合がある。正規形を崩してしまうと、データの一貫性の確保などの保守性が低下してしまうという問題がある。また、XMLDBは、RDBに比べて表現力は高いが、取り扱いが難しいという問題がある。

本発明は、上記の点に鑑みなされたもので、物理設計において正規形の維持と性能向上の両立を図ることが可能なデータモデリング方法及び装置及びプログラムを提供することを目的とする。

図１は、本発明の原理構成図である。

本発明（請求項１）は、ユーザの端末３００と接続され、構造化文書のXMLを格納するデータベース（XMLDB）のXMLデータ構造を設計するデータモデリング装置であって、
論理データモデルを表す実態関連図（ＥＲ図）の各エンティティに対応する論理ＸＭＬを定義し、論理ＸＭＬ定義情報としてＥＲ図の情報と共に論理ＸＭＬ定義情報記憶手段に格納する論理モデル設計手段１１０と、
入力されたアプリケーションのアクセスパターンを取得してアクセスパターン記憶手段１４０に格納するアクセスパターン入力手段１２１と、
論理XML定義情報記憶手段１３０の論理XML定義情報とアクセスパターン記憶手段１４０のアクセスパターンに基づいて、エンティティ毎に個別の更新処理のアクセスがなされる場合には外部キーによりリレーションシップを表現する基本形式とし、複数のエンティティがまとめてアクセスさせる場合には複数のエンティティを統合した木構造により表現する統合形式としてエンティティを物理データモデル記憶手段１５０に格納するXMLコレクション設計手段１２２と、
物理データモデル記憶手段１５０からエンティティを取得し、該エンティティの属性へのアクセスパターンに基づいて同時にアクセスされている属性群を抽出し、階層化を行い、物理データモデルとして該物理データモデル記憶手段の内容を更新するXML文書形式設計手段１２３と、
物理データモデル記憶手段１５０から物理データモデルを取得して、該物理データモデルに対応するXMLスキーマを作成し、XMLスキーマ記憶手段１６０に格納するXMLスキーマ生成手段１２４と、を有する。

また、本発明（請求項２）のXMLコレクション設計手段１２２は、
アクセスパターン記憶手段１４０のアクセスパターンから、アプリケーション毎の各エンティティへのアクセス頻度、参照または更新の頻度、または、条件に合致する対象データ数のいずれかに基づいて、基本形式または統合形式のいずれかを選択する手段を含む。

また、本発明（請求項３）のXML文書形式設計手段１２３は、
抽出された属性群について、属性へのアクセスパターンによりグループ化を行う。

また、本発明（請求項４）のXML文書形式設計手段１２３は、
属性へのアクセスパターンから同時にアクセスされている属性群を抽出し、あるアプリケーションから抽出された該属性群が他のアプリケーションと競合または重複しており、完全に包含関係がある場合には階層化したグループ化を行い、グループ名を設定する手段を含む。

図２は、本発明の原理を説明するための図である。

本発明（請求項５）は、ユーザの端末と接続され、構造化文書のXMLを格納するデータベース（XMLDB）のXMLデータ構造を設計するデータモデリング方法であって、
論理XML定義情報を格納するXML定義情報記憶手段と、アクセスパターン記憶手段と、物理データモデル記憶手段と、XMLスキーマ記憶手段とを有する装置において、
論理データモデルを表す実態関連図（ＥＲ図）の各エンティティに対応する論理ＸＭＬを定義し、論理ＸＭＬ定義情報としてＥＲ図の情報と共に論理ＸＭＬ定義情報記憶手段に格納する論理モデル設計ステップ（ステップ１）と、
入力されたアプリケーションのアクセスパターンを取得してアクセスパターン記憶手段に格納するアクセスパターン入力ステップ（ステップ２）と、
論理XML定義情報記憶手段の論理XML定義情報とアクセスパターン記憶手段のアクセスパターンに基づいて、エンティティ毎に個別の更新処理のアクセスがなされる場合には外部キーによりリレーションシップを表現する基本形式とし、複数のエンティティがまとめてアクセスさせる場合には複数のエンティティを統合した木構造により表現する統合形式としてエンティティを物理データモデル記憶手段に格納するXMLコレクション設計ステップ（ステップ３）と、
物理データモデル記憶手段からエンティティを取得し、該エンティティの属性へのアクセスパターンに基づいて同時にアクセスされている属性群を抽出し、階層化を行い、物理データモデルとして該物理データモデル記憶手段の内容を更新するXML文書形式設計ステップ（ステップ４）と、
物理データモデル記憶手段から物理データモデルを取得して、該物理データモデルに対応するXMLスキーマを作成し、XMLスキーマ記憶手段に格納するXMLスキーマ生成ステップと、を行う。

また、本発明（請求項６）は、XMLコレクション設計ステップにおいて、
アクセスパターン記憶手段のアクセスパターンから、アプリケーション毎の各エンティティへのアクセス頻度、参照または更新の頻度、または、条件に合致する対象データ数のいずれかに基づいて、基本形式または統合形式のいずれかを選択する。

また、本発明（請求項７）は、XML文書形式設計ステップにおいて
抽出された前記属性群について、属性へのアクセスパターンによりグループ化を行う。

また、本発明（請求項８）は、XML文書形式設計ステップにおいて、
属性へのアクセスパターンから同時にアクセスされている属性群を抽出し、あるアプリケーションから抽出された該属性群が他のアプリケーションと競合または重複しており、完全に包含関係がある場合には階層化したグループ化を行い、グループ名を設定する。

本発明（請求項９）は、請求項１乃至４のいずれか１項に記載のデータモデリング装置を構成する各手段としてコンピュータを機能させるためのデータモデリングプログラムである。

上記のように本発明によれば、XMLDB向けのデータモデリングにおいて、概念設計は従来の関係データベース（RDB）向けの手法をそのまま適用し、論理設計はXMLの木構造モデルの表現力を利用することで簡素化し、物理設計はエンティティ間のリレーションシップを主キー、外部キー属性による表現と、１つのXMLドキュメント内の構造による表現の２種類から、アプリケーションの振る舞い（アクセスパターン）を考慮し、XMLコレクションの形式（基本形式・統合形式）選択することにより、正規形を維持したまま、性能を向上させることができる。さらに、利便性の高いデータ構造を設計することができる。

本発明の原理構成図である。 本発明の原理を説明するための図である。 本発明の方法と従来の方法の比較を示す図である。 本発明の一実施の形態におけるモデリング装置の構成図である。 本発明の一実施の形態における木構造モデルによるＭ：Ｎ関係の表現例である。 本発明の一実施の形態における２種類のリレーションシップの表現例である。 本発明の一実施の形態におけるＥＲ図の表記の拡張（統合形式の表記）を示す図である。 本発明の一実施の形態におけるXMLコレクション設計部の動作のフローチャートである。 本発明の一実施の形態におけるグループ化の表記とXML表現への対応を示す図である。 本発明の一実施例におけるモデリング装置の画面イメージである。 本発明の一実施例の論理ＸＭＬの例である。 本発明の一実施例のエンティティへのアクセスパターン例である。 本発明の一実施例の属性へのアクセスパターン例である。 本発明の一実施例のXMLコレクション設計後のＥＲ図の例である。 本発明の一実施例のグループ化後の物理データモデルのＥＲ図の例である。 本発明の一実施例のXMLデータの例（XMLコレクションとそのデータ構造）である。 本発明の一実施例のXMLスキーマの例である。 概念データモデルのＥＲ図の例である。 ＵＭＬのクラス図の例である。 RDB向け論理データモデルのＥＲ図の例である。 RDB向け物理データモデルのＥＲ図の例である。 XMLデータとその構造の例である。

以下、図面と共に本発明の実施の形態を説明する。

概念設計はＤＢＭＳ非依存であるため、従来の方法をそのまま用い、論理設計及び物理設計の方法について提案する。特に、物理設計において、正規形の維持と性能向上の両立を図る方法を提案する。

また、支援ツールによる自動化方法も同時に提案する。

まず、従来のＲＤＢ向けと比較した全体の手順を図３に示す。同図において、太線で囲んだ「論理XMLの設計」「XMLコレクションの設計」「XML文書形式の設計」が本発明で提案する部分であり、以下に説明する。それ以外の部分は従来と同様の方法を用いるものとし、その説明は省略する。

本発明では、XMLＤＢ向けのデータモデリングについて説明する。

図４は、本発明の一実施の形態におけるモデリング装置の構成を示す。

同図に示すモデリング装置１００は、ユーザ端末３００と接続されており、概念／論理モデル管理部１１０、物理モデル管理部１２０、概念／論理モデルデータ（論理XML定義情報）記憶部１３０、アクセスパターン記憶部１４０、物理モデルデータ記憶部１５０、XMLスキーマ記憶部１６０から構成される。

物理モデル管理部１２０は、アクセスパターン入力部１２１、XMLコレクション設計部１２２、XML文書形式設計部１２３、XMLスキーマ生成部１２４を有する。

概念／論理モデル管理部１１０は、端末３００でユーザが描画したＥＲ図やＵＭＬクラス図を、概念／論理モデルデータ（論理XML定義情報）として概念／論理モデルデータ記憶部１３０に格納する。

物理モデル管理部１２０のアクセスパターン入力部１２１は、端末３００でユーザが入力したアクセスパターンをアクセスパターン記憶部１４０に格納する。但し、入力はＣＳＶ(Comma Separated Values)ファイルを渡すような形式であってもよい。

物理モデル管理部１２０のXMLコレクション設計部１２２は、端末３００からユーザが実行を選択（ボタン押す等）すると、概念／論理モデルデータ記憶部１３０とアクセスパターン記憶部１４０の情報を参照してXMLコレクション(XMLドキュメントの種類)設計を行う。この際、必要に応じて、ユーザとのインタラクションも含むものとする。そしてXMLコレクション設計結果を物理モデルデータとして物理モデルデータ記憶部１５０に格納する。

物理モデル管理部１２０のXML文書形式設計部１２３は、端末３００でユーザが属性群のグループ化を直接指定（描画）し、実行を選択（ボタンを押すなどの操作）すると、XML文書形式の設計を行い、アクセスパターン記憶部１４０と物理モデルデータ記憶部１５０のデータに基づいてユーザが直接指定していない箇所のグループ化を行う。グループ化を行う際に、必要に応じて、端末３００とのインタラクションも含むものとする。そして設計結果を物理モデルデータ記憶部１５０に格納（更新）する。

物理モデル管理部１２０のXMLスキーマ生成部１２４は、端末３００からユーザが実行を選択（ボタンを押す等の操作）すると、物理モデルデータ記憶部１５０のデータに基づいて、XMLスキーマを作成し、XMLスキーマ記憶部１６０に格納する。

以下、図３の流れに沿って、XMLＤＢ向け論理設計、ＭＬ向け物理設計の順に説明する。

＜論理設計＞（論理XMLの設計）
当該論理設計は、概念／論理モデル管理部１１０によって行われる。

まず、ＲＤＢ向けの論理設計では、リレーショナルモデルへの制限により、ＥＲ図の変形（リレーショナルモデルへの正規化）が必要であったが、XMLＤＢ向けの場合は、木構造モデルの表現力の高さにより変形は不要である。具体的には、Ｍ：Ｎ関係も外部キー属性を繰り返し項目として表現することが可能である。

例えば、図１８の部活動と生徒のＭ：Ｎの関係を図５に示すような木構造モデルのデータ構造とすることで表現できる。生徒エンティティに中間ノード「部活動リスト」を作成し、部活動の主キーに対応した外部キー『部活動コード（ＦＫ）』を繰り返し要素として複数保持させている。

次に、概念／論理モデル管理部１１０は、ＥＲ図と対応した「論理XML」を定義し、概念／論理モデルデータ記憶部１３０に格納する。ＲＤＢの場合、エンティティは論理テーブル、属性は論理カラム、リレーションシップは外部キー属性として論理カラムに対応させるが、論理XMLの場合、以下の対応とする。

・エンティティ：１つの論理XMLに対応させる。

・属性：論理XML内のノードに対応させる（要素で表現するか、XML属性で表現するかは特に規定しない）
・リレーションシップ：表現形式は特に規定しない（リレーションシップの具体的なデータ設計は物理設計で行うため、ここでは情報保持以上の作業は行わない）。

従って、従来のデータモデリング技法の支援ツールもそのまま利用できる（概念データモデルの描画ができればよい）。

＜物理設計＞
次に、物理モデル管理部１２０における、XMLＤＢ向けの物理設計について記すが、まずはその基礎となる考え方について説明する。

・リレーションシップの表現は、２種類（基本形式と統合形式）の表現方法から選択できる。

−主キー、外部キー属性の追加（ＲＤＢと同様の方法）；
−XMLドキュメント内の木構造による表現（１エンティティ＝１種類のXMLドキュメントである必要はない。複数エンティティを１種類のXMLドキュメントで表現することもできる）。

・エンティティ内の属性は、中間ノードを追加し、階層化を行うこともできる。

前者のリレーションシップの２種類の表現方法についての例を、図６に示す。左側が従来の外部キーによる表現（基本形式）で、エンティティ毎に２種理のXMLドキュメントに分けられ、「学籍番号」により関係が保持されている。右側が、XMLの木構造による表現（統合形式）の一例であり、１種類のXMLドキュメントに、「生徒」エンティティと「試験成績」エンティティが統合され、木構造の親・子ノードの関係で表されている。また、「試験成績」エンティティが繰り返し項目となっているのは、「生徒」と「試験成績」が１：Ｎの関係であるためである。

このように、リレーションシップは２種類の表現方法があり、外部キーによる表現を『基本形式』、木構造による表現を『統合形式』と以降呼ぶこととする。また、XMLドキュメントの種類を、『XMLコレクション』と以降呼ぶこととする。つまり、リレーションシップを持つ２つのエンティティは、基本形式では２つのXMLコレクションとなり（図６左側）、統合形式では、１つのXMLコレクションに対応する（図６右側）。

統合形式は、基本的には１：Ｎの「１」側の親エンティティを中心に、「Ｎ」側の子エンティティを繰り返しノードとして表現することができる。さらに、子エンティティに対して別のエンティティとの１：Ｎのリレーションシップがあれば、入れ子的に統合形式を適用することもできる。この場合も、データは冗長になることはなく、正規形を崩すことなく表現できることが重要なポイントである。

但し、無制限というわけではなく、以下の条件を満たす範囲となるが、従来のＲＤＢと比較すると広範囲になる。

［条件］
・ある子エンティティが複数の親エンティティを持つ場合、１つの親に対してのみ、統合形式で表現し、残りのリレーションシップは基本形式で表現する。

・Ｍ：Ｎ関係のリレーションシップは基本形式で表現する（統合形式で表現しない）。

また、以降の説明のために、ＥＲ図の表記を拡張し、図７に示すように、点線で囲んだエンティティ群（厳密にはリレーションシップ群）は統合形式の適用を表すこととする。

モデリング技法の支援ツールにおいては、統合形式の表記を新しく用意する必要がある。もちろん、点線で囲む以外に、リレーションシップの線の書式を変えるといった、他の様々な表記が考えられる。

＜XMLコレクションの設計＞
次に、XMLコレクション設計部１２２の処理について説明する。

XMLコレクションは、リレーションシップの表現により決定されることを前述した。また、XMLコレクションは、ＲＤＢのテーブルに相当するものであり、ＲＤＢの場合と同様、性能向上を観点に設計されたものである。

基本形式と統合形式では、期待できる性能の特徴が異なり、一般的には以下となる。

・基本形式が性能有利な場合：
エンティティ毎に個別の更新系のアクセスがなされる場合。特に、親エンティティの挿入、削除、子エンティティの挿入、外部キーの更新時が有利である。

・統合形式が性能有利な場合：
双方のエンティティをまとめてアクセスされる場合。結合検索（参照）、一括挿入、一括削除時が有利である。

すなわち、統合形式は２つのエンティティがまとまった状態で管理されるため、まとまったアクセスが有利であり、その反面、更新系のアクセスの際に、一方の変更がそれだけでは済まず、もう一方の変更も引き起こす場合があり、基本形式が有利となる。

従って、XMLコレクション設計部１２２は、XMLコレクションを、業務アプリケーション（ＡＰ）がどのエンティティにどういう頻度でどのようにアクセスするかといった振る舞いを考慮して有利な形式を選択し、設計する。

ＡＰの振る舞いを整理したものを、ここでは「エンティティへのアクセスパターン」と呼び、XMLコレクションの設計作業の前に「アクセスパターンの整理」作業でアクセスパターン入力部１２１で作成され、アクセスパターン記憶部１４０に格納される。

アクセスパターンの整理作業は、従来手法でも同様に行われており、
・ＡＰの洗い出し；
・ＡＰ毎の各エンティティへのアクセス頻度、参照／更新、ヒット数（条件に合致する対象データ数）
・各エンティティ毎のデータ件数、分布
といった情報が整理される。

論理データモデルのＥＲ図と、エンティティへのアクセスパターンを入力して行う、XMLコレクションの設計手順を図８に示す。これは、支援ツールにより（半）自動化することもできる。

以下に図８の動作を説明する。

ユーザにより、画面イメージの「ＸＭＬコレクション設計」ボタンが押下されたタイミングで、システムがリレーションシップを全て走査すると、XMLコレクション設計部１２２は、物理データモデル記憶部１５０からリレーションシップを持つエンティティの組を選択する（ステップ１０１）。XMLコレクション設計部１２２は、概念／物理モデルデータ記憶部１３０を参照して、ステップ１０１で選択されたエンティティの組がＭ：Ｎ関係かを判定し、Ｍ：Ｎであれば（ステップ１０２、Ｙｅｓ）『基本形式』を選択する（ステップ１０７）。Ｍ：Ｎ関係でない場合は、アクセスパターン記憶部１４０を参照して、まとめてアクセスするＡＰがあるかを判定し（ステップ１０２）、ない場合は（ステップ１０３、Ｎｏ）『基本形式』を選択する（ステップ１０７）。一方、まとめてアクセスするＡＰがある場合には（ステップ１０３、Ｙｅｓ）、個別に更新系のアクセスするＡＰはあるかを判定し、ない場合は（ステップ１０４、Ｎｏ）『統合形式』を選択する（ステップ１０６）。ある場合は（ステップ１０４、Ｙｅｓ）双方のＡＰ群を総合的に判断し、統合が有利であると推定できる場合は（ステップ１０５、Ｙｅｓ）、『統合形式』を選択する（ステップ１０６）。有利でないと推定した場合は（ステップ１０５、Ｎｏ）、『基本形式』を選択する（ステップ１０７）。

なお、上記のステップ１０５において、「ＡＰ群を総合的に判断する方法」としては、自動的に判断する方法として、アクセス頻度と更新／参照コストの比率を事前に決定しておき、アクセス頻度×コストの総和が高い方が有利になる形式を選択する方法等が考えられる。

上記の処理を全てのエンティティの組について行った場合は（ステップ１０８、Ｙｅｓ）、『統合形式』が選択された範囲において、複数の親エンティティへのリレーションシップがある場合、最も有利となる１つの親エンティティを選択し、それ以外は『基本形式』に変更する（ステップ１０９）。

上記のステップ１０５の処理は、アクセスパターン記憶部１４０を参照して、２つのエンティティにまとめてアクセスするＡＰ群と、個別に更新系のアクセスを行うＡＰ群が競合した場合は、両派の性能への影響を検討し、判断を行う必要がある。この際、アクセス頻度が重要な指標になるが、他にもデータ件数やヒット数（条件に合致する対象データ数）などのアクセスパターンの情報全般を考慮するべきである。なお、アクセス頻度については、アクセスパターン記憶部１４０を参照するものとする。アクセス頻度は、その頻度により高、中、低のようにレベルで表しても、アクセス回数自体で表してもよい。

また、上記のステップ１０９において、複数の親エンティティへの統合は正規形を崩してしまうため、１つの親エンティティを選択する必要がある。これもステップ１０５と同様に、アクセス頻度等からの統合的な検討が必要となる。

ステップ１０５，１０９の支援ツールにおける（半）自動化方法としては、
・各種の指標群を入力とした特定の計算式やルールを定め、自動的に判断する方法；
・指標群や計算結果などをユーザ（設計者）に提示し、ユーザに判断を求める方法；
が考えられる。

上記の手順により、ＡＰから複数のエンティティにまとめてアクセスされるものについては、『統合形式』で、個別の更新系アクセスが行われるものについては『基本形式』でXMLコレクションを設計し、性能向上を図ると共に、データモデルの正規形も維持できるため、性能向上と保守性の両立を図ることができる。

また、本発明の範囲外であるが、更なる性能向上を優先したい場合、上記に加えて従来のＲＤＢの場合と同様の方法で正規形を崩して設計を行うことも可能である。

＜XML文書形式の設計＞
次に、XML文書形式設計部１２３が行うXML文書形式の設計処理について説明する。

XMLの木構造モデルの表現力を活用し、より利便性の高いデータ構造とするため、XML文書形式設計部１２３は、エンティティ内の属性の階層化を行う。これも、アクセスパターン記憶部１４０のＡＰのアクセスパターンにより判断するが、より詳細な情報である、エンティティ内の属性へのアクセスパターンから判断する。これは、エンティティ毎に、各ＡＰがどういう頻度でどの属性にアクセスするかといった振る舞いを整理したものである。これも、「アクセスパターンの整理」作業により従来も行われており、属性毎にアクセスされるＡＰ、参照／更新の種別等が整理され、アクセスパターン記憶部１４０に格納されている。

XML文書形式の設計手順を以下に示す。XML文書形式設計部１２３は、各エンティティ毎に以下の処理を行う。

（１） XML文書形式設計部１２３は、アクセスパターン記憶部１４０を参照し、属性へのアクセスパターンから、同時にアクセスされている属性群を抽出する。

（２） XML文書形式設計部１２３は、上記の（１）であるＡＰから抽出した属性群が他のＡＰのものと競合していない場合は、そのままグループ化（グループ名の設定と所属属性群の決定）を行う。

抽出した属性群の範囲が、競合／重複している場合は、
・完全に包含関係がある場合は、階層化したグループ化を行う；
・参照よりも、挿入／更新・削除を優先する；
・アクセス頻度等の処理コストから優先するものを検討する；
といった観点から、総合的にグループ化を行い、グループ名を設定する。

（３）ＡＰでの内部処理において、利便性の高い構造が明確な場合は、更なるグループ化を行う。ここで、利便性の高い構造が明確か否かを判定する場合に、例えば、ＡＰで「住所」「氏名」「年齢」「職業」を画面に表示する場合に、「氏名」「年齢」を見出しのように表示し、それ以外は小さく表示する、といったように異なる処理となった場合、それぞれグループ化されていれば、利便性が高いと判定することができる。

この際、グループ名は全てのエンティティ名と当該エンティティ内の属性名とは異なる名称にする方がよい。

図９に、グループ化した場合の拡張したＥＲ図表記（左側）とXML表現のデータ構造例（右側）を示す。XML文書形式設計部１２３は、ＥＲ図表記では、グループ化のグループ名の記述と、グループに所属する属性をインデントにより表現するよう、表記を拡張している。

支援ツールによる（半）自動化方法としては、図９のようなグループ化を表す表記方法を追加するが、上記設計手順の完全自動化は困難であるため、各種指標などを設計者の端末３００に提示し、ユーザに判断を求める方法が考えられる。

XML表現においては、グループ名を要素名とした中間ノード（ルート要素でも最下層の要素でもない中間的な要素）として表現するのが自然である。

従来のＲＤＢにおいては、ＡＰが必要とする項目（エンティティ内の属性）のみを列挙指定したクエリ（ＳＱＬの「SELECT」句）を発行することで、データ転送量を必要最低限に抑え、性能向上を図ることが行われている。XMLＤＢにおいても同様の方法により性能向上を図ることができるが、木構造データモデルの利点を活かし、上記のグループ化を行うことで、ここの属性の列挙の代わりにグループ名を指定することができ、性能向上だけでなく、クエリの簡素化による保守性も向上する。

＜XMLスキーマの作成＞
最後に、XMLスキーマ作成部１２４におけるXMLスキーマの作成処理について説明する。

ＥＲ図と対応した最終的なXML表現を規定する。XMLコレクションをXMLドキュメントに対応させることと、論理XMLの規定を前提に、不足している
・リレーションシップの表現。具体的には、基本形式のキー属性の表現と統合形式の構造表現：
・Ｍ：Ｎ関係の外部キー表現：
を定める。

そして、それに基づいて、物理モデルデータ記憶部１５０の物理データモデルに対応したXMLスキーマを作成し、XMLスキーマ記憶部１６０に格納する。

従来のＲＤＢスキーマの作成と同様、XML表現の定義から、支援ツールによってXMLスキーマを自動生成することができる。

本発明自体では、特定のXML表現への定義は特に規定しない。全ての情報が保存され、アクセスや操作がしやすい表現を検討し、決定すべきである。

以下に、実施例として、図１８の概念データモデルを対象に、ER図をベースとした設計例を示す。

図１０は、本発明の一実施例のモデリング装置の画面イメージである。

＜論理設計＞（論理XMLの設計）
最初に、概念／論理モデル管理部１１０における論理設計について述べる。

当該論理設計では、ER図の変形は特に行わないものとする。

ER図の表現に対する論理XMLの定義を以下のように定める。

・エンティティ：
ルート要素をエンティティ要素とし、要素名（タグ名）をエンティティ名とする。

・属性：
エンティティ要素直下の要素とする。要素名（タグ名）を属性名とし、テキストノードに値を格納する。

図１１は、本発明の一実施例の論理XMLの例であり、上記の定義により、図１８のER図に対応させた論理XMLを示している。なお、同図において、リレーションシップについては省略している。

図１０に示す画面イメージにおいて、ユーザによって『概念／論理モデル』タブが選択されると、ER図を描画することができ、上記の論理XMLの定義情報を概念／論理モデルデータ記憶部１３０で保持するものとする。

＜物理設計＞
まず、物理モデル管理部１２０のアクセスパターン入力部１２１は、アクセスパターン整理作業が行われた図１２に示すエンティティへのアクセスパターンを取得する。

この例では、５つのＡＰを縦軸に、各エンティティへのアクセスを表形式にまとめており、ＡＰ毎のアクセス頻度（高／中／低）と、アクセスの種別を、Ｃ（新規作成）、Ｂ（参照）、Ｕ（更新）、Ｄ（削除）で表している。

また、生徒のエンティティの、属性のアクセスパターンとして図１３に示すパターンが得られたとする。同図の例では、生徒のエンティティにアクセスする４つのＡＰを縦軸に、同じ表形式としている。

図１０に示す画面イメージにおいて、「物理モデル」のタブが選択され、「アクセスパターンの入力」ボタンが押下され、アクセスパターンが入力される。これにより、アクセスパターン入力部１２１は、図１２に示すエンティティへのアクセスパターンと、図１３に示す属性のアクセスパターンをアクセスパターン記憶部１４０に格納する。

＜XMLコレクションの設計＞
以下では、XMLコレクション設計部１２２において、図１８のＥＲ図に対し、アクセスパターン記憶部１４０に格納されている図１２に示すアクセスパターンから、図８に示した手順で設計を行った例を示す。

また、競合時の判断は、アクセスパターン記憶部１４０に格納されているＡＰのアクセス頻度を参照して行うものとする。

［１］『基本形式』選択：
図８のステップ１０１で「クラス（親）と生徒（子）」の組を選択した場合は、Ｍ：Ｎの関係ではなく（ステップ１０２、Ｎｏ）、クラス一覧取得ＡＰで、まとめて参照しており（ステップ１０３、Ｙｅｓ）、生徒の情報変更ＡＰで生徒（子）のみを更新している（ステップ１０４、Ｙｅｓ）。アクセス頻度は、クラスの一覧取得ＡＰ＜生徒の情報変更ＡＰとなっているので（ステップ１０５、Ｎｏ）、『基本形式』を選択する（ステップ１０７）。

［２］『基本形式』選択：
図８のステップ１０１で「部活動（親）と生徒（子）」の組を選択した場合は、Ｍ：Ｎ関係である（ステップ１０２、Ｙｅｓ）ので、『基本形式』を選択する（ステップ１０７）。

［３］『統合形式』選択：
図９のステップ１０１で「生徒（親）と試験成績（子）」の組を選択した場合は、Ｍ：Ｎの関係ではなく（ステップ１０２、Ｎｏ）、生徒の姓・名と試験結果の取得ＡＰで、まとめて参照しており（ステップ１０３、Ｙｅｓ）、生徒の情報変更ＡＰで、生徒（親）のみ更新しており、また、試験結果の登録ＡＰで試験成績（子）のみを作成している（ステップ１０４、Ｙｅｓ）。アクセス頻度は、「生徒の姓・名と試験結果の取得ＡＰ＞生徒の情報変更ＡＰ＋試験結果の登録ＡＰ」であるので（ステップ１０５、Ｙｅｓ）、『統合形式』を選択する（ステップ１０６）。

ステップ１０８において、全ての処理を行ったものとし、複数の親への『統合形式』の選択はない、とする。

図１０に示すモデリング装置の画面イメージに対して、『XMLコレクション設計』ボタンを押下することで、自動的に上記の結果をＥＲ図描画に反映することができる。従って、ＥＲ図は図１４に示すようになる。「生徒」と「試験成績」は『統合形式』の点線で囲まれ、「生徒」には「クラス」と「部活動」の『基本形式』の外部キーが追加されている。

＜XML文書形式の設計＞
次に、XML文書形式設計部１２３の具体例を以下に示す。

アクセスパターン記憶部１４０の図１３のアクセスパターンから、「生徒」エンティティでは、３つのＡＰから姓と名が同時に参照されていることがわかる。よって、XML文書形式設計部１２３は、姓と名を「名前」でグループ化し、物理モデルデータ記憶部１５０に格納する。

例えば、ユーザが図１０に示す画面イメージ（図１０）において、「生徒」エンティティを選択し、「XML文書形式設計」ボタンを押下すると、XML文書形式設計部１２３は、物理モデルデータ記憶部１５０を参照し、「生徒」エンティティの属性毎のアクセスパターンだけを端末３００に表示し、ユーザが行う判断の支援をすることができる。

図１４の例に対して、XML文書形式設計部１２３がグループ化を行った後の最終的なデータモデルのＥＲ図を図１５に示す。

＜XMLスキーマの生成＞
最後に、XMLスキーマ生成部１２４の具体例を以下に示す。

ＥＲ図に対するXML表現の対応を、以下のように規定する。論理XMLの規定に加えて、
・XMLコレクションで１番親となるエンティティ名をルート要素名とする；
・基本形式の外部キー属性は、通常の属性と同様に、要素名（タグ名）を属性名とし、テキストノードに値を格納する要素とする；
・統合形式の子エンティティは、親エンティティの要素直下に「エンティティ名＋"リスト"」という名前の中間ノードを作成し、繰り返し要素とする；
・Ｍ：Ｎ関係の外部キー属性は、「属性名＋"リスト"」という名前の中間ノードを作成し、外部キー属性を繰り返し要素として表現する；
また、通常は、各種名称には論理名とは別の物理名を定義し、最終的なデータには物理名を付与するが、本実施例では、物理名と論理名は同じ設定とする。

上記の規定を適用したXMLデータ（３つのXMLコレクションのデータ構造）のイメージを図１６に示す。

上記の規定は物理モデルデータ記憶部１５０に格納されているものとし、支援ツール（図１０）では、端末３００から「スキーマ作成」ボタンが押下されると、物理モデルデータ記憶部１５０の論理XMLも含めた規定から自動的に図１７に示すようなXMLスキーマ（XML Schemaによる記述例）を生成することができる。

なお、上記の概念／論理モデル管理部１１０、物理モデル管理部１２０の動作をプログラムとして構築し、データモデリング装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

また、構築されたプログラムをハードディスクや、フレキシブルディスク・ＣＤ−ＲＯＭ等の可搬記憶媒体に格納し、コンピュータにインストールする、または、配布することが可能である。

なお、本発明は、上記の実施の形態及び実施例に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。

１００ モデリング装置
１１０ 概念／論理モデル設計手段、概念／論理モデル管理部
１２０ 物理モデル管理部
１２１ アクセスパターン入力手段、アクセスパターン入力部
１２２ XMLコレクション設計手段、XMLコレクション設計部
１２３ XML文書形式設計手段、XML文書形式設計部
１２４ XMLスキーマ生成手段、XMLスキーマ生成部
１３０ 論理XML定義情報記憶手段、概念／論理モデルデータ記憶部
１４０ アクセスパターン記憶手段、アクセスパターン記憶部
１５０ 物理データモデル記憶手段、物理データモデル記憶部
１６０ XMLスキーマ記憶手段、XMLスキーマ記憶部
３００ 端末

Claims (9)

1. ユーザの端末と接続され、構造化文書のXML(Extensible Markup Language)を格納するデータベース（XMLDB）のXMLデータ構造を設計するデータモデリング装置であって、
   論理データモデルを表す実態関連図（ＥＲ図）の各エンティティに対応する論理ＸＭＬを定義し、論理ＸＭＬ定義情報としてＥＲ図の情報と共に論理ＸＭＬ定義情報記憶手段に格納する論理モデル設計手段と、
   入力されたアプリケーションのアクセスパターンを取得してアクセスパターン記憶手段に格納するアクセスパターン入力手段と、
   前記ＥＲ図からリレーションシップを持つエンティティの組が指定されると、前記論理XML定義情報記憶手段の前記論理XML定義情報と前記アクセスパターン記憶手段のアクセスパターンに基づいて、エンティティ毎に個別の更新処理のアクセスがなされる場合には外部キーによりリレーションシップを表現する基本形式とし、複数のエンティティがまとめてアクセスさせる場合には複数のエンティティを統合した木構造により表現する統合形式としてエンティティを物理データモデル記憶手段に格納するXMLコレクション設計手段と、
   前記物理データモデル記憶手段からエンティティを取得し、該エンティティの属性へのアクセスパターンに基づいて同時にアクセスされている属性群を抽出し、階層化を行い、物理データモデルとして該物理データモデル記憶手段の内容を更新するXML文書形式設計手段と、
   前記物理データモデル記憶手段から前記物理データモデルを取得して、該物理データモデルに対応するXMLスキーマを作成するXMLスキーマ生成手段と、
   を有することを特徴とするデータモデリング装置。
2. 前記XMLコレクション設計手段は、
   前記アクセスパターン記憶手段のアクセスパターンから、アプリケーション毎の各エンティティへのアクセス頻度、参照または更新の頻度、または、条件に合致する対象データ数のいずれかに基づいて、前記基本形式または前記統合形式のいずれかを選択する手段を含むことを特徴とする請求項１記載のデータモデリング装置。
3. 前記XML文書形式設計手段は、
   抽出された前記属性群について、属性へのアクセスパターンによりグループ化を行う
   手段を含む
   ことを特徴とする請求項１記載のデータモデリング装置。
4. 前記XML文書形式設計手段は、
   前記属性へのアクセスパターンから同時にアクセスされている属性群を抽出し、あるアプリケーションから抽出された該属性群が他のアプリケーションと競合または重複しており、完全に包含関係がある場合には階層化したグループ化を行い、グループ名を設定する手段を含むことを特徴とする請求項３記載のデータモデリング装置。
5. ユーザの端末と接続され、構造化文書のXML(Extensible Markup Language)を格納するデータベース（XMLDB）のXMLデータ構造を設計するデータモデリング方法であって、
   論理XML定義情報を格納するXML定義情報記憶手段と、アクセスパターン記憶手段と、物理データモデル記憶手段と、XMLスキーマ記憶手段とを有する装置において、
   論理データモデルを表す実態関連図（ＥＲ図）の各エンティティに対応する論理ＸＭＬを定義し、論理ＸＭＬ定義情報としてＥＲ図の情報と共に前記論理ＸＭＬ定義情報記憶手段に格納する論理モデル設計ステップと、
   入力されたアプリケーションのアクセスパターンを取得して前記アクセスパターン記憶手段に格納するアクセスパターン入力ステップと、
   前記ＥＲ図からリレーションシップを持つエンティティの組が指定されると、前記論理XML定義情報記憶手段の前記論理XML定義情報と前記アクセスパターン記憶手段のアクセスパターンに基づいて、エンティティ毎に個別の更新処理のアクセスがなされる場合には外部キーによりリレーションシップを表現する基本形式とし、複数のエンティティがまとめてアクセスさせる場合には複数のエンティティを統合した木構造により表現する統合形式としてエンティティを物理データモデル記憶手段に格納するXMLコレクション設計ステップと、
   前記物理データモデル記憶手段からエンティティを取得し、該エンティティの属性へのアクセスパターンに基づいて同時にアクセスされている属性群を抽出し、階層化を行い、物理データモデルとして該物理データモデル記憶手段の内容を更新するXML文書形式設計ステップと、
   前記物理データモデル記憶手段から前記物理データモデルを取得して、該物理データモデルに対応するXMLスキーマを作成し、XMLスキーマ記憶手段に格納するXMLスキーマ生成ステップと、
   を行うことを特徴とするデータモデリング方法。
6. 前記XMLコレクション設計ステップにおいて、
   前記アクセスパターン記憶手段のアクセスパターンから、アプリケーション毎の各エンティティへのアクセス頻度、参照または更新の頻度、または、条件に合致する対象データ数のいずれかに基づいて、前記基本形式または前記統合形式のいずれかを選択することを特徴とする請求項５記載のデータモデリング方法。
7. 前記XML文書形式設計ステップにおいて、
   抽出された前記属性群について、属性へのアクセスパターンによりグループ化を行う
   ことを特徴とする請求項５記載のデータモデリング方法。
8. 前記XML文書形式設計ステップにおいて、
   前記属性へのアクセスパターンから同時にアクセスされている属性群を抽出し、あるアプリケーションから抽出された該属性群が他のアプリケーションと競合または重複しており、完全に包含関係がある場合には階層化したグループ化を行い、グループ名を設定することを特徴とする請求項７記載のデータモデリング方法。
9. 請求項１乃至４のいずれか１項に記載のデータモデリング装置を構成する各手段としてコンピュータを機能させるためのデータモデリングプログラム。

Images