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

データモデリング方法及び装置及びプログラム Download PDF

Info

Publication number
JP2011154653A
JP2011154653A JP2010017302A JP2010017302A JP2011154653A JP 2011154653 A JP2011154653 A JP 2011154653A JP 2010017302 A JP2010017302 A JP 2010017302A JP 2010017302 A JP2010017302 A JP 2010017302A JP 2011154653 A JP2011154653 A JP 2011154653A
Authority
JP
Japan
Prior art keywords
xml
access pattern
logical
entity
design
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2010017302A
Other languages
English (en)
Other versions
JP5090481B2 (ja
Inventor
Toshibumi Enomoto
俊文 榎本
Nobuyuki Kobayashi
伸幸 小林
Gengo Suzuki
源吾 鈴木
Masashi Yamamuro
雅司 山室
Noburo Taniguchi
展郎 谷口
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2010017302A priority Critical patent/JP5090481B2/ja
Publication of JP2011154653A publication Critical patent/JP2011154653A/ja
Application granted granted Critical
Publication of JP5090481B2 publication Critical patent/JP5090481B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

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

Description

本発明は、データモデリング方法及び装置及びプログラムに係り、特に、構造化データである多数のXMLデータのような構造化データを取り扱うシステムの設計において、具体的なXMLデータ構造を設計するためのデータモデリング方法及び装置及びプログラムに関する。
一定量以上のデータの管理が必要となる情報システムを設計する場合、データベース管理システム(DBMS)が利用され、そのために、通常、データモデリングと呼ばれるシステムで管理するデータ構造の設計作業が行われる。
データモデリングは、システムで利用するDBMSを対象に、以下の3種類のデータモデリングを順次設計していく。
(1)概念データモデル:
DBMSに依存しない抽象的なデータモデルであり、情報の意味的な側面を記述する。
(2)論理データモデル:
DBMSが対象とするモデルに依存したデータモデルで、例えば、関係データベース(RDB)の場合、テーブル(表)、カラム(列)等から構成されるリレーショナルモデルとなり、概念データモデルからの変形が行われる。
(3)物理データモデル:
データベースの物理的な内部構造を決定するものであり、性能を考慮し、論理データモデルから変形が行われる。
これらのデータベースモデルを設計することを、それぞれ、概念設計、論理設計、物理設計と呼ぶ。
一般に、データモデリングの技法として、実体関連図(ER図)(例えば、非特許文献1参照)や統一モデリング言語(UML)のクラス図が用いられる。また、従来はDBMSには関係データベース(RDB)が用いられている。
そして、上記技法に対する支援ツールが用意されており、ER図は、概念、論理、物理データモデルを描画することができ、そこから自動的にRDBスキーマ(テーブル定義、カラム定義DDL)を出力する、といった機能を持つものもある。
以下に、従来手法であるRDB向けのデータモデリングについて、ER図を用いて説明する。
<概念設計>
まず、概念設計では、エンティティ(事象/人/物などの管理対象)と、リレーションシップ(エンティティ間の関連)、さらに、属性(エンティティのデータ項目)を洗い出す。例として、学校の生徒を管理するシステムの概念データモデルをER図として図18に示す。このようなER図を支援ツールを用いて描画することができる。
表記法として、IDEF1Xと呼ばれる記法を用いており、図18において、「クラス」、「生徒」、「部活動」、「試験成績」、といった情報のまとまりがエンティティである。同図において、エンティティ間を結んでいる線がリレーションシップを表しており、黒丸はエンティティの関係が1:N(1対多)である「N」側を表している。一般に、「1」側を「親(エンティティ)」、「N」側を「子(エンティティ)」と呼ぶ。従って、「クラス」と「生徒」の関係は1:Nであり、「生徒」と「試験成績」の関係も1:Nである。双方に黒丸がある「部活動」と「生徒」の関係はM:N(多対多)を表している。エンティティの中に書かれているものが属性で、区切り線の上にある属性(群)が「主キー」と呼ばれ、情報を一意に決定することができる項目である。
概念データモデルは、データの冗長性と不整合を回避した正規形であることが求められるため、実際の設計作業では、エンティティの洗い出し、リレーションシップの洗い出し、正規化(正規形とする作業)といった手順により、作成・修正を繰り返して完成させていく。
また、同じデータモデルをUMLのクラス図で表したものを図19に示す。ER図とほぼ同等の情報を記述できるため、こちらを用いてデータモデリングが行われる場合も多い。
<論理設計>
次に、論理設計では、リレーショナルモデル(表モデル)の制約を満たすよう、概念データモデルからの変形を行う。例えば、リレーショナルモデルでは、M:Nの関係はそのままでは表現できず、中間に新しいエンティティを新設し、1:Nでそれぞれにリレーションシップを作成する必要がある。
また、RDBでは、エンティティはテーブルに対応し、属性はカラムに対応する。そしてリレーションシップは外部キーと呼ばれる属性を追加することで表現する。図18をRDB向けに変形させたER図の例を図20に示す。M:N関係の部活動と生徒の間に「部活動−生徒関連」というエンティティが追加されている。また、「(FK)」と書かれている属性が外部キー属性であり、例えば、生徒のクラスコード(FK)は、クラスの主キーであるクラスコードと同一値を保持することでリレーションシップを表現する、ということを意味している。
支援ツールによっては、図18の概念データモデルから、(半)自動的にこのような論理データモデルを作成するものもある(新規追加されたエンティティ名などは仮の名称となるため、編集は必要であるため、半自動と表現している)。
<物理設計>
物理設計は、主に性能向上を目的に行われる。RDBにおいて一般的にコストが高い処理は結合処理である。
例えば、図20に対し、「生徒」と「試験成績」を同時に取得する処理を頻繁に行う場合、「生徒」と「試験成績」の2つのテーブル間の結合処理が必要となり、取得に時間がかかることが懸念される。そこで、物理設計ではあえて正規形を崩し、「試験成績」を「生徒」のエンティティ(=テーブル)に含めてしまう(テーブル統合を行う)ことで、性能向上を図ったデータモデルを選択するといったことを行う場合がある。その例を図21に示す。この場合、さらに「試験成績」は、3つまでしか保持できないという制限も加えられている。
支援ツールを用いて論理データモデルから物理データモデルのER図を編集した後、RDBスキーマを自動的に出力させることができる。
<XML及びXMLDB>
XML(Extensible Markup Language)とはマークアップ言語の一つで、XMLで記述されたデータは構造化され、構造に意味を持ったデータである。図22はXMLデータとその構造を示した図である。従って、XMLデータは木構造モデルであり、各節をノードと呼ぶ。特に、根のノードをルート要素、値(記述内容)をテキストノード、タグ中に記述されたものを属性(データモデルの属性と区別するため、以降『XML属性』と呼ぶ)、テキストノードとXML属性以外のノードを要素と呼ぶ。また、データ全体をXMLドキュメントと呼ぶ。
このようなXMLデータを管理する機能を有するデータベースがXMLDBである。
RDBのリレーショナルモデルに比べると、表現力が高いことが長所であり、それが故に、逆に取り扱いが難しいことが短所である。
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.
従来のRDBのデータモデリングでは、物理設計において、性能向上のため正規形を崩してしまう場合がある。正規形を崩してしまうと、データの一貫性の確保などの保守性が低下してしまうという問題がある。また、XMLDBは、RDBに比べて表現力は高いが、取り扱いが難しいという問題がある。
本発明は、上記の点に鑑みなされたもので、物理設計において正規形の維持と性能向上の両立を図ることが可能なデータモデリング方法及び装置及びプログラムを提供することを目的とする。
図1は、本発明の原理構成図である。
本発明(請求項1)は、ユーザの端末300と接続され、構造化文書のXMLを格納するデータベース(XMLDB)のXMLデータ構造を設計するデータモデリング装置であって、
論理データモデルを表す実態関連図(ER図)の各エンティティに対応する論理XMLを定義し、論理XML定義情報としてER図の情報と共に論理XML定義情報記憶手段に格納する論理モデル設計手段110と、
入力されたアプリケーションのアクセスパターンを取得してアクセスパターン記憶手段140に格納するアクセスパターン入力手段121と、
論理XML定義情報記憶手段130の論理XML定義情報とアクセスパターン記憶手段140のアクセスパターンに基づいて、エンティティ毎に個別の更新処理のアクセスがなされる場合には外部キーによりリレーションシップを表現する基本形式とし、複数のエンティティがまとめてアクセスさせる場合には複数のエンティティを統合した木構造により表現する統合形式としてエンティティを物理データモデル記憶手段150に格納するXMLコレクション設計手段122と、
物理データモデル記憶手段150からエンティティを取得し、該エンティティの属性へのアクセスパターンに基づいて同時にアクセスされている属性群を抽出し、階層化を行い、物理データモデルとして該物理データモデル記憶手段の内容を更新するXML文書形式設計手段123と、
物理データモデル記憶手段150から物理データモデルを取得して、該物理データモデルに対応するXMLスキーマを作成し、XMLスキーマ記憶手段160に格納するXMLスキーマ生成手段124と、を有する。
また、本発明(請求項2)のXMLコレクション設計手段122は、
アクセスパターン記憶手段140のアクセスパターンから、アプリケーション毎の各エンティティへのアクセス頻度、参照または更新の頻度、または、条件に合致する対象データ数のいずれかに基づいて、基本形式または統合形式のいずれかを選択する手段を含む。
また、本発明(請求項3)のXML文書形式設計手段123は、
抽出された属性群について、属性へのアクセスパターンによりグループ化を行う。
また、本発明(請求項4)のXML文書形式設計手段123は、
属性へのアクセスパターンから同時にアクセスされている属性群を抽出し、あるアプリケーションから抽出された該属性群が他のアプリケーションと競合または重複しており、完全に包含関係がある場合には階層化したグループ化を行い、グループ名を設定する手段を含む。
図2は、本発明の原理を説明するための図である。
本発明(請求項5)は、ユーザの端末と接続され、構造化文書のXMLを格納するデータベース(XMLDB)のXMLデータ構造を設計するデータモデリング方法であって、
論理XML定義情報を格納するXML定義情報記憶手段と、アクセスパターン記憶手段と、物理データモデル記憶手段と、XMLスキーマ記憶手段とを有する装置において、
論理データモデルを表す実態関連図(ER図)の各エンティティに対応する論理XMLを定義し、論理XML定義情報としてER図の情報と共に論理XML定義情報記憶手段に格納する論理モデル設計ステップ(ステップ1)と、
入力されたアプリケーションのアクセスパターンを取得してアクセスパターン記憶手段に格納するアクセスパターン入力ステップ(ステップ2)と、
論理XML定義情報記憶手段の論理XML定義情報とアクセスパターン記憶手段のアクセスパターンに基づいて、エンティティ毎に個別の更新処理のアクセスがなされる場合には外部キーによりリレーションシップを表現する基本形式とし、複数のエンティティがまとめてアクセスさせる場合には複数のエンティティを統合した木構造により表現する統合形式としてエンティティを物理データモデル記憶手段に格納するXMLコレクション設計ステップ(ステップ3)と、
物理データモデル記憶手段からエンティティを取得し、該エンティティの属性へのアクセスパターンに基づいて同時にアクセスされている属性群を抽出し、階層化を行い、物理データモデルとして該物理データモデル記憶手段の内容を更新するXML文書形式設計ステップ(ステップ4)と、
物理データモデル記憶手段から物理データモデルを取得して、該物理データモデルに対応するXMLスキーマを作成し、XMLスキーマ記憶手段に格納するXMLスキーマ生成ステップと、を行う。
また、本発明(請求項6)は、XMLコレクション設計ステップにおいて、
アクセスパターン記憶手段のアクセスパターンから、アプリケーション毎の各エンティティへのアクセス頻度、参照または更新の頻度、または、条件に合致する対象データ数のいずれかに基づいて、基本形式または統合形式のいずれかを選択する。
また、本発明(請求項7)は、XML文書形式設計ステップにおいて
抽出された前記属性群について、属性へのアクセスパターンによりグループ化を行う。
また、本発明(請求項8)は、XML文書形式設計ステップにおいて、
属性へのアクセスパターンから同時にアクセスされている属性群を抽出し、あるアプリケーションから抽出された該属性群が他のアプリケーションと競合または重複しており、完全に包含関係がある場合には階層化したグループ化を行い、グループ名を設定する。
本発明(請求項9)は、請求項1乃至4のいずれか1項に記載のデータモデリング装置を構成する各手段としてコンピュータを機能させるためのデータモデリングプログラムである。
上記のように本発明によれば、XMLDB向けのデータモデリングにおいて、概念設計は従来の関係データベース(RDB)向けの手法をそのまま適用し、論理設計はXMLの木構造モデルの表現力を利用することで簡素化し、物理設計はエンティティ間のリレーションシップを主キー、外部キー属性による表現と、1つのXMLドキュメント内の構造による表現の2種類から、アプリケーションの振る舞い(アクセスパターン)を考慮し、XMLコレクションの形式(基本形式・統合形式)選択することにより、正規形を維持したまま、性能を向上させることができる。さらに、利便性の高いデータ構造を設計することができる。
本発明の原理構成図である。 本発明の原理を説明するための図である。 本発明の方法と従来の方法の比較を示す図である。 本発明の一実施の形態におけるモデリング装置の構成図である。 本発明の一実施の形態における木構造モデルによるM:N関係の表現例である。 本発明の一実施の形態における2種類のリレーションシップの表現例である。 本発明の一実施の形態におけるER図の表記の拡張(統合形式の表記)を示す図である。 本発明の一実施の形態におけるXMLコレクション設計部の動作のフローチャートである。 本発明の一実施の形態におけるグループ化の表記とXML表現への対応を示す図である。 本発明の一実施例におけるモデリング装置の画面イメージである。 本発明の一実施例の論理XMLの例である。 本発明の一実施例のエンティティへのアクセスパターン例である。 本発明の一実施例の属性へのアクセスパターン例である。 本発明の一実施例のXMLコレクション設計後のER図の例である。 本発明の一実施例のグループ化後の物理データモデルのER図の例である。 本発明の一実施例のXMLデータの例(XMLコレクションとそのデータ構造)である。 本発明の一実施例のXMLスキーマの例である。 概念データモデルのER図の例である。 UMLのクラス図の例である。 RDB向け論理データモデルのER図の例である。 RDB向け物理データモデルのER図の例である。 XMLデータとその構造の例である。
以下、図面と共に本発明の実施の形態を説明する。
概念設計はDBMS非依存であるため、従来の方法をそのまま用い、論理設計及び物理設計の方法について提案する。特に、物理設計において、正規形の維持と性能向上の両立を図る方法を提案する。
また、支援ツールによる自動化方法も同時に提案する。
まず、従来のRDB向けと比較した全体の手順を図3に示す。同図において、太線で囲んだ「論理XMLの設計」「XMLコレクションの設計」「XML文書形式の設計」が本発明で提案する部分であり、以下に説明する。それ以外の部分は従来と同様の方法を用いるものとし、その説明は省略する。
本発明では、XMLDB向けのデータモデリングについて説明する。
図4は、本発明の一実施の形態におけるモデリング装置の構成を示す。
同図に示すモデリング装置100は、ユーザ端末300と接続されており、概念/論理モデル管理部110、物理モデル管理部120、概念/論理モデルデータ(論理XML定義情報)記憶部130、アクセスパターン記憶部140、物理モデルデータ記憶部150、XMLスキーマ記憶部160から構成される。
物理モデル管理部120は、アクセスパターン入力部121、XMLコレクション設計部122、XML文書形式設計部123、XMLスキーマ生成部124を有する。
概念/論理モデル管理部110は、端末300でユーザが描画したER図やUMLクラス図を、概念/論理モデルデータ(論理XML定義情報)として概念/論理モデルデータ記憶部130に格納する。
物理モデル管理部120のアクセスパターン入力部121は、端末300でユーザが入力したアクセスパターンをアクセスパターン記憶部140に格納する。但し、入力はCSV(Comma Separated Values)ファイルを渡すような形式であってもよい。
物理モデル管理部120のXMLコレクション設計部122は、端末300からユーザが実行を選択(ボタン押す等)すると、概念/論理モデルデータ記憶部130とアクセスパターン記憶部140の情報を参照してXMLコレクション(XMLドキュメントの種類)設計を行う。この際、必要に応じて、ユーザとのインタラクションも含むものとする。そしてXMLコレクション設計結果を物理モデルデータとして物理モデルデータ記憶部150に格納する。
物理モデル管理部120のXML文書形式設計部123は、端末300でユーザが属性群のグループ化を直接指定(描画)し、実行を選択(ボタンを押すなどの操作)すると、XML文書形式の設計を行い、アクセスパターン記憶部140と物理モデルデータ記憶部150のデータに基づいてユーザが直接指定していない箇所のグループ化を行う。グループ化を行う際に、必要に応じて、端末300とのインタラクションも含むものとする。そして設計結果を物理モデルデータ記憶部150に格納(更新)する。
物理モデル管理部120のXMLスキーマ生成部124は、端末300からユーザが実行を選択(ボタンを押す等の操作)すると、物理モデルデータ記憶部150のデータに基づいて、XMLスキーマを作成し、XMLスキーマ記憶部160に格納する。
以下、図3の流れに沿って、XMLDB向け論理設計、ML向け物理設計の順に説明する。
<論理設計>(論理XMLの設計)
当該論理設計は、概念/論理モデル管理部110によって行われる。
まず、RDB向けの論理設計では、リレーショナルモデルへの制限により、ER図の変形(リレーショナルモデルへの正規化)が必要であったが、XMLDB向けの場合は、木構造モデルの表現力の高さにより変形は不要である。具体的には、M:N関係も外部キー属性を繰り返し項目として表現することが可能である。
例えば、図18の部活動と生徒のM:Nの関係を図5に示すような木構造モデルのデータ構造とすることで表現できる。生徒エンティティに中間ノード「部活動リスト」を作成し、部活動の主キーに対応した外部キー『部活動コード(FK)』を繰り返し要素として複数保持させている。
次に、概念/論理モデル管理部110は、ER図と対応した「論理XML」を定義し、概念/論理モデルデータ記憶部130に格納する。RDBの場合、エンティティは論理テーブル、属性は論理カラム、リレーションシップは外部キー属性として論理カラムに対応させるが、論理XMLの場合、以下の対応とする。
・エンティティ:1つの論理XMLに対応させる。
・属性:論理XML内のノードに対応させる(要素で表現するか、XML属性で表現するかは特に規定しない)
・リレーションシップ:表現形式は特に規定しない(リレーションシップの具体的なデータ設計は物理設計で行うため、ここでは情報保持以上の作業は行わない)。
従って、従来のデータモデリング技法の支援ツールもそのまま利用できる(概念データモデルの描画ができればよい)。
<物理設計>
次に、物理モデル管理部120における、XMLDB向けの物理設計について記すが、まずはその基礎となる考え方について説明する。
・リレーションシップの表現は、2種類(基本形式と統合形式)の表現方法から選択できる。
−主キー、外部キー属性の追加(RDBと同様の方法);
−XMLドキュメント内の木構造による表現(1エンティティ=1種類のXMLドキュメントである必要はない。複数エンティティを1種類のXMLドキュメントで表現することもできる)。
・エンティティ内の属性は、中間ノードを追加し、階層化を行うこともできる。
前者のリレーションシップの2種類の表現方法についての例を、図6に示す。左側が従来の外部キーによる表現(基本形式)で、エンティティ毎に2種理のXMLドキュメントに分けられ、「学籍番号」により関係が保持されている。右側が、XMLの木構造による表現(統合形式)の一例であり、1種類のXMLドキュメントに、「生徒」エンティティと「試験成績」エンティティが統合され、木構造の親・子ノードの関係で表されている。また、「試験成績」エンティティが繰り返し項目となっているのは、「生徒」と「試験成績」が1:Nの関係であるためである。
このように、リレーションシップは2種類の表現方法があり、外部キーによる表現を『基本形式』、木構造による表現を『統合形式』と以降呼ぶこととする。また、XMLドキュメントの種類を、『XMLコレクション』と以降呼ぶこととする。つまり、リレーションシップを持つ2つのエンティティは、基本形式では2つのXMLコレクションとなり(図6左側)、統合形式では、1つのXMLコレクションに対応する(図6右側)。
統合形式は、基本的には1:Nの「1」側の親エンティティを中心に、「N」側の子エンティティを繰り返しノードとして表現することができる。さらに、子エンティティに対して別のエンティティとの1:Nのリレーションシップがあれば、入れ子的に統合形式を適用することもできる。この場合も、データは冗長になることはなく、正規形を崩すことなく表現できることが重要なポイントである。
但し、無制限というわけではなく、以下の条件を満たす範囲となるが、従来のRDBと比較すると広範囲になる。
[条件]
・ある子エンティティが複数の親エンティティを持つ場合、1つの親に対してのみ、統合形式で表現し、残りのリレーションシップは基本形式で表現する。
・M:N関係のリレーションシップは基本形式で表現する(統合形式で表現しない)。
また、以降の説明のために、ER図の表記を拡張し、図7に示すように、点線で囲んだエンティティ群(厳密にはリレーションシップ群)は統合形式の適用を表すこととする。
モデリング技法の支援ツールにおいては、統合形式の表記を新しく用意する必要がある。もちろん、点線で囲む以外に、リレーションシップの線の書式を変えるといった、他の様々な表記が考えられる。
<XMLコレクションの設計>
次に、XMLコレクション設計部122の処理について説明する。
XMLコレクションは、リレーションシップの表現により決定されることを前述した。また、XMLコレクションは、RDBのテーブルに相当するものであり、RDBの場合と同様、性能向上を観点に設計されたものである。
基本形式と統合形式では、期待できる性能の特徴が異なり、一般的には以下となる。
・基本形式が性能有利な場合:
エンティティ毎に個別の更新系のアクセスがなされる場合。特に、親エンティティの挿入、削除、子エンティティの挿入、外部キーの更新時が有利である。
・統合形式が性能有利な場合:
双方のエンティティをまとめてアクセスされる場合。結合検索(参照)、一括挿入、一括削除時が有利である。
すなわち、統合形式は2つのエンティティがまとまった状態で管理されるため、まとまったアクセスが有利であり、その反面、更新系のアクセスの際に、一方の変更がそれだけでは済まず、もう一方の変更も引き起こす場合があり、基本形式が有利となる。
従って、XMLコレクション設計部122は、XMLコレクションを、業務アプリケーション(AP)がどのエンティティにどういう頻度でどのようにアクセスするかといった振る舞いを考慮して有利な形式を選択し、設計する。
APの振る舞いを整理したものを、ここでは「エンティティへのアクセスパターン」と呼び、XMLコレクションの設計作業の前に「アクセスパターンの整理」作業でアクセスパターン入力部121で作成され、アクセスパターン記憶部140に格納される。
アクセスパターンの整理作業は、従来手法でも同様に行われており、
・APの洗い出し;
・AP毎の各エンティティへのアクセス頻度、参照/更新、ヒット数(条件に合致する対象データ数)
・各エンティティ毎のデータ件数、分布
といった情報が整理される。
論理データモデルのER図と、エンティティへのアクセスパターンを入力して行う、XMLコレクションの設計手順を図8に示す。これは、支援ツールにより(半)自動化することもできる。
以下に図8の動作を説明する。
ユーザにより、画面イメージの「XMLコレクション設計」ボタンが押下されたタイミングで、システムがリレーションシップを全て走査すると、XMLコレクション設計部122は、物理データモデル記憶部150からリレーションシップを持つエンティティの組を選択する(ステップ101)。XMLコレクション設計部122は、概念/物理モデルデータ記憶部130を参照して、ステップ101で選択されたエンティティの組がM:N関係かを判定し、M:Nであれば(ステップ102、Yes)『基本形式』を選択する(ステップ107)。M:N関係でない場合は、アクセスパターン記憶部140を参照して、まとめてアクセスするAPがあるかを判定し(ステップ102)、ない場合は(ステップ103、No)『基本形式』を選択する(ステップ107)。一方、まとめてアクセスするAPがある場合には(ステップ103、Yes)、個別に更新系のアクセスするAPはあるかを判定し、ない場合は(ステップ104、No)『統合形式』を選択する(ステップ106)。ある場合は(ステップ104、Yes)双方のAP群を総合的に判断し、統合が有利であると推定できる場合は(ステップ105、Yes)、『統合形式』を選択する(ステップ106)。有利でないと推定した場合は(ステップ105、No)、『基本形式』を選択する(ステップ107)。
なお、上記のステップ105において、「AP群を総合的に判断する方法」としては、自動的に判断する方法として、アクセス頻度と更新/参照コストの比率を事前に決定しておき、アクセス頻度×コストの総和が高い方が有利になる形式を選択する方法等が考えられる。
上記の処理を全てのエンティティの組について行った場合は(ステップ108、Yes)、『統合形式』が選択された範囲において、複数の親エンティティへのリレーションシップがある場合、最も有利となる1つの親エンティティを選択し、それ以外は『基本形式』に変更する(ステップ109)。
上記のステップ105の処理は、アクセスパターン記憶部140を参照して、2つのエンティティにまとめてアクセスするAP群と、個別に更新系のアクセスを行うAP群が競合した場合は、両派の性能への影響を検討し、判断を行う必要がある。この際、アクセス頻度が重要な指標になるが、他にもデータ件数やヒット数(条件に合致する対象データ数)などのアクセスパターンの情報全般を考慮するべきである。なお、アクセス頻度については、アクセスパターン記憶部140を参照するものとする。アクセス頻度は、その頻度により高、中、低のようにレベルで表しても、アクセス回数自体で表してもよい。
また、上記のステップ109において、複数の親エンティティへの統合は正規形を崩してしまうため、1つの親エンティティを選択する必要がある。これもステップ105と同様に、アクセス頻度等からの統合的な検討が必要となる。
ステップ105,109の支援ツールにおける(半)自動化方法としては、
・各種の指標群を入力とした特定の計算式やルールを定め、自動的に判断する方法;
・指標群や計算結果などをユーザ(設計者)に提示し、ユーザに判断を求める方法;
が考えられる。
上記の手順により、APから複数のエンティティにまとめてアクセスされるものについては、『統合形式』で、個別の更新系アクセスが行われるものについては『基本形式』でXMLコレクションを設計し、性能向上を図ると共に、データモデルの正規形も維持できるため、性能向上と保守性の両立を図ることができる。
また、本発明の範囲外であるが、更なる性能向上を優先したい場合、上記に加えて従来のRDBの場合と同様の方法で正規形を崩して設計を行うことも可能である。
<XML文書形式の設計>
次に、XML文書形式設計部123が行うXML文書形式の設計処理について説明する。
XMLの木構造モデルの表現力を活用し、より利便性の高いデータ構造とするため、XML文書形式設計部123は、エンティティ内の属性の階層化を行う。これも、アクセスパターン記憶部140のAPのアクセスパターンにより判断するが、より詳細な情報である、エンティティ内の属性へのアクセスパターンから判断する。これは、エンティティ毎に、各APがどういう頻度でどの属性にアクセスするかといった振る舞いを整理したものである。これも、「アクセスパターンの整理」作業により従来も行われており、属性毎にアクセスされるAP、参照/更新の種別等が整理され、アクセスパターン記憶部140に格納されている。
XML文書形式の設計手順を以下に示す。XML文書形式設計部123は、各エンティティ毎に以下の処理を行う。
(1) XML文書形式設計部123は、アクセスパターン記憶部140を参照し、属性へのアクセスパターンから、同時にアクセスされている属性群を抽出する。
(2) XML文書形式設計部123は、上記の(1)であるAPから抽出した属性群が他のAPのものと競合していない場合は、そのままグループ化(グループ名の設定と所属属性群の決定)を行う。
抽出した属性群の範囲が、競合/重複している場合は、
・完全に包含関係がある場合は、階層化したグループ化を行う;
・参照よりも、挿入/更新・削除を優先する;
・アクセス頻度等の処理コストから優先するものを検討する;
といった観点から、総合的にグループ化を行い、グループ名を設定する。
(3)APでの内部処理において、利便性の高い構造が明確な場合は、更なるグループ化を行う。ここで、利便性の高い構造が明確か否かを判定する場合に、例えば、APで「住所」「氏名」「年齢」「職業」を画面に表示する場合に、「氏名」「年齢」を見出しのように表示し、それ以外は小さく表示する、といったように異なる処理となった場合、それぞれグループ化されていれば、利便性が高いと判定することができる。
この際、グループ名は全てのエンティティ名と当該エンティティ内の属性名とは異なる名称にする方がよい。
図9に、グループ化した場合の拡張したER図表記(左側)とXML表現のデータ構造例(右側)を示す。XML文書形式設計部123は、ER図表記では、グループ化のグループ名の記述と、グループに所属する属性をインデントにより表現するよう、表記を拡張している。
支援ツールによる(半)自動化方法としては、図9のようなグループ化を表す表記方法を追加するが、上記設計手順の完全自動化は困難であるため、各種指標などを設計者の端末300に提示し、ユーザに判断を求める方法が考えられる。
XML表現においては、グループ名を要素名とした中間ノード(ルート要素でも最下層の要素でもない中間的な要素)として表現するのが自然である。
従来のRDBにおいては、APが必要とする項目(エンティティ内の属性)のみを列挙指定したクエリ(SQLの「SELECT」句)を発行することで、データ転送量を必要最低限に抑え、性能向上を図ることが行われている。XMLDBにおいても同様の方法により性能向上を図ることができるが、木構造データモデルの利点を活かし、上記のグループ化を行うことで、ここの属性の列挙の代わりにグループ名を指定することができ、性能向上だけでなく、クエリの簡素化による保守性も向上する。
<XMLスキーマの作成>
最後に、XMLスキーマ作成部124におけるXMLスキーマの作成処理について説明する。
ER図と対応した最終的なXML表現を規定する。XMLコレクションをXMLドキュメントに対応させることと、論理XMLの規定を前提に、不足している
・リレーションシップの表現。具体的には、基本形式のキー属性の表現と統合形式の構造表現:
・M:N関係の外部キー表現:
を定める。
そして、それに基づいて、物理モデルデータ記憶部150の物理データモデルに対応したXMLスキーマを作成し、XMLスキーマ記憶部160に格納する。
従来のRDBスキーマの作成と同様、XML表現の定義から、支援ツールによってXMLスキーマを自動生成することができる。
本発明自体では、特定のXML表現への定義は特に規定しない。全ての情報が保存され、アクセスや操作がしやすい表現を検討し、決定すべきである。
以下に、実施例として、図18の概念データモデルを対象に、ER図をベースとした設計例を示す。
図10は、本発明の一実施例のモデリング装置の画面イメージである。
<論理設計>(論理XMLの設計)
最初に、概念/論理モデル管理部110における論理設計について述べる。
当該論理設計では、ER図の変形は特に行わないものとする。
ER図の表現に対する論理XMLの定義を以下のように定める。
・エンティティ:
ルート要素をエンティティ要素とし、要素名(タグ名)をエンティティ名とする。
・属性:
エンティティ要素直下の要素とする。要素名(タグ名)を属性名とし、テキストノードに値を格納する。
図11は、本発明の一実施例の論理XMLの例であり、上記の定義により、図18のER図に対応させた論理XMLを示している。なお、同図において、リレーションシップについては省略している。
図10に示す画面イメージにおいて、ユーザによって『概念/論理モデル』タブが選択されると、ER図を描画することができ、上記の論理XMLの定義情報を概念/論理モデルデータ記憶部130で保持するものとする。
<物理設計>
まず、物理モデル管理部120のアクセスパターン入力部121は、アクセスパターン整理作業が行われた図12に示すエンティティへのアクセスパターンを取得する。
この例では、5つのAPを縦軸に、各エンティティへのアクセスを表形式にまとめており、AP毎のアクセス頻度(高/中/低)と、アクセスの種別を、C(新規作成)、B(参照)、U(更新)、D(削除)で表している。
また、生徒のエンティティの、属性のアクセスパターンとして図13に示すパターンが得られたとする。同図の例では、生徒のエンティティにアクセスする4つのAPを縦軸に、同じ表形式としている。
図10に示す画面イメージにおいて、「物理モデル」のタブが選択され、「アクセスパターンの入力」ボタンが押下され、アクセスパターンが入力される。これにより、アクセスパターン入力部121は、図12に示すエンティティへのアクセスパターンと、図13に示す属性のアクセスパターンをアクセスパターン記憶部140に格納する。
<XMLコレクションの設計>
以下では、XMLコレクション設計部122において、図18のER図に対し、アクセスパターン記憶部140に格納されている図12に示すアクセスパターンから、図8に示した手順で設計を行った例を示す。
また、競合時の判断は、アクセスパターン記憶部140に格納されているAPのアクセス頻度を参照して行うものとする。
[1]『基本形式』選択:
図8のステップ101で「クラス(親)と生徒(子)」の組を選択した場合は、M:Nの関係ではなく(ステップ102、No)、クラス一覧取得APで、まとめて参照しており(ステップ103、Yes)、生徒の情報変更APで生徒(子)のみを更新している(ステップ104、Yes)。アクセス頻度は、クラスの一覧取得AP<生徒の情報変更APとなっているので(ステップ105、No)、『基本形式』を選択する(ステップ107)。
[2]『基本形式』選択:
図8のステップ101で「部活動(親)と生徒(子)」の組を選択した場合は、M:N関係である(ステップ102、Yes)ので、『基本形式』を選択する(ステップ107)。
[3]『統合形式』選択:
図9のステップ101で「生徒(親)と試験成績(子)」の組を選択した場合は、M:Nの関係ではなく(ステップ102、No)、生徒の姓・名と試験結果の取得APで、まとめて参照しており(ステップ103、Yes)、生徒の情報変更APで、生徒(親)のみ更新しており、また、試験結果の登録APで試験成績(子)のみを作成している(ステップ104、Yes)。アクセス頻度は、「生徒の姓・名と試験結果の取得AP>生徒の情報変更AP+試験結果の登録AP」であるので(ステップ105、Yes)、『統合形式』を選択する(ステップ106)。
ステップ108において、全ての処理を行ったものとし、複数の親への『統合形式』の選択はない、とする。
図10に示すモデリング装置の画面イメージに対して、『XMLコレクション設計』ボタンを押下することで、自動的に上記の結果をER図描画に反映することができる。従って、ER図は図14に示すようになる。「生徒」と「試験成績」は『統合形式』の点線で囲まれ、「生徒」には「クラス」と「部活動」の『基本形式』の外部キーが追加されている。
<XML文書形式の設計>
次に、XML文書形式設計部123の具体例を以下に示す。
アクセスパターン記憶部140の図13のアクセスパターンから、「生徒」エンティティでは、3つのAPから姓と名が同時に参照されていることがわかる。よって、XML文書形式設計部123は、姓と名を「名前」でグループ化し、物理モデルデータ記憶部150に格納する。
例えば、ユーザが図10に示す画面イメージ(図10)において、「生徒」エンティティを選択し、「XML文書形式設計」ボタンを押下すると、XML文書形式設計部123は、物理モデルデータ記憶部150を参照し、「生徒」エンティティの属性毎のアクセスパターンだけを端末300に表示し、ユーザが行う判断の支援をすることができる。
図14の例に対して、XML文書形式設計部123がグループ化を行った後の最終的なデータモデルのER図を図15に示す。
<XMLスキーマの生成>
最後に、XMLスキーマ生成部124の具体例を以下に示す。
ER図に対するXML表現の対応を、以下のように規定する。論理XMLの規定に加えて、
・XMLコレクションで1番親となるエンティティ名をルート要素名とする;
・基本形式の外部キー属性は、通常の属性と同様に、要素名(タグ名)を属性名とし、テキストノードに値を格納する要素とする;
・統合形式の子エンティティは、親エンティティの要素直下に「エンティティ名+"リスト"」という名前の中間ノードを作成し、繰り返し要素とする;
・M:N関係の外部キー属性は、「属性名+"リスト"」という名前の中間ノードを作成し、外部キー属性を繰り返し要素として表現する;
また、通常は、各種名称には論理名とは別の物理名を定義し、最終的なデータには物理名を付与するが、本実施例では、物理名と論理名は同じ設定とする。
上記の規定を適用したXMLデータ(3つのXMLコレクションのデータ構造)のイメージを図16に示す。
上記の規定は物理モデルデータ記憶部150に格納されているものとし、支援ツール(図10)では、端末300から「スキーマ作成」ボタンが押下されると、物理モデルデータ記憶部150の論理XMLも含めた規定から自動的に図17に示すようなXMLスキーマ(XML Schemaによる記述例)を生成することができる。
なお、上記の概念/論理モデル管理部110、物理モデル管理部120の動作をプログラムとして構築し、データモデリング装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
また、構築されたプログラムをハードディスクや、フレキシブルディスク・CD−ROM等の可搬記憶媒体に格納し、コンピュータにインストールする、または、配布することが可能である。
なお、本発明は、上記の実施の形態及び実施例に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。
100 モデリング装置
110 概念/論理モデル設計手段、概念/論理モデル管理部
120 物理モデル管理部
121 アクセスパターン入力手段、アクセスパターン入力部
122 XMLコレクション設計手段、XMLコレクション設計部
123 XML文書形式設計手段、XML文書形式設計部
124 XMLスキーマ生成手段、XMLスキーマ生成部
130 論理XML定義情報記憶手段、概念/論理モデルデータ記憶部
140 アクセスパターン記憶手段、アクセスパターン記憶部
150 物理データモデル記憶手段、物理データモデル記憶部
160 XMLスキーマ記憶手段、XMLスキーマ記憶部
300 端末

Claims (9)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010017302A JP5090481B2 (ja) 2010-01-28 2010-01-28 データモデリング方法及び装置及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010017302A JP5090481B2 (ja) 2010-01-28 2010-01-28 データモデリング方法及び装置及びプログラム

Publications (2)

Publication Number Publication Date
JP2011154653A true JP2011154653A (ja) 2011-08-11
JP5090481B2 JP5090481B2 (ja) 2012-12-05

Family

ID=44540545

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010017302A Active JP5090481B2 (ja) 2010-01-28 2010-01-28 データモデリング方法及び装置及びプログラム

Country Status (1)

Country Link
JP (1) JP5090481B2 (ja)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011257812A (ja) * 2010-06-04 2011-12-22 Fujitsu Ltd スキーマ定義生成装置、スキーマ定義生成方法およびスキーマ定義生成プログラム
KR101166763B1 (ko) 2011-12-02 2012-07-25 김춘기 웹 상에서 xml 문서의 데이터를 데이터베이스에 통합하는 방법
JP2013149121A (ja) * 2012-01-20 2013-08-01 Nippon Telegr & Teleph Corp <Ntt> データ検索システム、データ検索方法及びデータ検索プログラム
KR20150084634A (ko) * 2014-01-14 2015-07-22 한국과학기술원 대형 소셜 네트워크 시스템을 위한 다수의 노드에 분산 저장된 데이터베이스에서 노드간 조인을 회피하는 방법
CN110619185A (zh) * 2019-09-25 2019-12-27 北京世冠金洋科技发展有限公司 一种数据处理方法、装置及电子设备
CN114578775A (zh) * 2022-03-07 2022-06-03 江西鑫铂瑞科技有限公司 一种总控制台图形化在线建模方法及系统
CN117389984A (zh) * 2023-09-06 2024-01-12 苏州数设科技有限公司 工业软件对象模型的构建方法、装置、介质及电子设备
US11983487B2 (en) 2020-02-25 2024-05-14 Nippon Telegraph And Telephone Corporation Document creation support apparatus, document creation support method and document creation support program

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009544064A (ja) * 2006-03-23 2009-12-10 マイクロソフト コーポレーション 増分ビューの保守を用いたマッピングアーキテクチャ

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009544064A (ja) * 2006-03-23 2009-12-10 マイクロソフト コーポレーション 増分ビューの保守を用いたマッピングアーキテクチャ

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011257812A (ja) * 2010-06-04 2011-12-22 Fujitsu Ltd スキーマ定義生成装置、スキーマ定義生成方法およびスキーマ定義生成プログラム
KR101166763B1 (ko) 2011-12-02 2012-07-25 김춘기 웹 상에서 xml 문서의 데이터를 데이터베이스에 통합하는 방법
US8762398B2 (en) 2011-12-02 2014-06-24 Chun Gi Kim Method of integrating data of XML document with database on web
JP2013149121A (ja) * 2012-01-20 2013-08-01 Nippon Telegr & Teleph Corp <Ntt> データ検索システム、データ検索方法及びデータ検索プログラム
KR20150084634A (ko) * 2014-01-14 2015-07-22 한국과학기술원 대형 소셜 네트워크 시스템을 위한 다수의 노드에 분산 저장된 데이터베이스에서 노드간 조인을 회피하는 방법
KR101650005B1 (ko) 2014-01-14 2016-08-22 한국과학기술원 대형 소셜 네트워크 시스템을 위한 다수의 노드에 분산 저장된 데이터베이스에서 노드간 조인을 회피하는 방법
CN110619185A (zh) * 2019-09-25 2019-12-27 北京世冠金洋科技发展有限公司 一种数据处理方法、装置及电子设备
CN110619185B (zh) * 2019-09-25 2020-09-04 北京世冠金洋科技发展有限公司 一种数据处理方法、装置及电子设备
US11983487B2 (en) 2020-02-25 2024-05-14 Nippon Telegraph And Telephone Corporation Document creation support apparatus, document creation support method and document creation support program
CN114578775A (zh) * 2022-03-07 2022-06-03 江西鑫铂瑞科技有限公司 一种总控制台图形化在线建模方法及系统
CN114578775B (zh) * 2022-03-07 2023-04-25 江西鑫铂瑞科技有限公司 一种总控制台图形化在线建模方法及系统
CN117389984A (zh) * 2023-09-06 2024-01-12 苏州数设科技有限公司 工业软件对象模型的构建方法、装置、介质及电子设备

Also Published As

Publication number Publication date
JP5090481B2 (ja) 2012-12-05

Similar Documents

Publication Publication Date Title
JP5090481B2 (ja) データモデリング方法及び装置及びプログラム
US7512633B2 (en) Conversion of hierarchically-structured HL7 specifications to relational databases
CN101727320B (zh) 用于识别数据库更改对应用的影响的方法和系统
US20130006968A1 (en) Data integration system
US11288290B2 (en) Building reports
AU2005225020B2 (en) Complex data access
US20050010550A1 (en) System and method of modelling of a multi-dimensional data source in an entity-relationship model
US9785725B2 (en) Method and system for visualizing relational data as RDF graphs with interactive response time
US9495475B2 (en) Method of representing an XML schema definition and data within a relational database management system using a reusable custom-defined nestable compound data type
EP1222569A1 (en) Method and systems for making olap hierarchies summarisable
US11334549B2 (en) Semantic, single-column identifiers for data entries
JPWO2007020850A1 (ja) 情報処理方法、情報処理装置および情報処理プログラム
CN102768674B (zh) 一种基于路径结构的xml数据存储方法
JPWO2005119516A1 (ja) 配列の生成方法、情報処理装置、及び、プログラム
US20170193036A1 (en) Framework for joining datasets
de la Vega et al. Mortadelo: Automatic generation of NoSQL stores from platform-independent data models
US9805112B2 (en) Method and structure for managing multiple electronic forms and their records using a static database
JP2007087216A (ja) 階層型辞書作成装置、プログラムおよび階層型辞書作成方法
US20070255685A1 (en) Method and system for modelling data
US20080046440A1 (en) Method And System For Enforcing User-Defined Relational Limitations In A Recursive Relational Database Table
US20080294673A1 (en) Data transfer and storage based on meta-data
Nguyen et al. Singleton Property Graph: Adding A Semantic Web Abstraction Layer to Graph Databases.
CN113342325A (zh) 可视化建模方法、系统、电子设备及存储介质
CN113221528B (zh) 基于openEHR模型的临床数据质量评估规则的自动生成与执行方法
Jackson Thirty years (and more) of databases

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120703

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120815

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120904

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120912

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150921

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5090481

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350