データ処理システム
【課題】
少なくとも２つのデータ集合体について、いずれかで追加、変更などがあった場合に、それらの関係性を維持したまま、相手方のデータ集合体にデータを反映可能とする、データ処理システムを提供することを目的とする。
【解決手段】
第２のデータ集合体に登録されたデータが所定の記述子で記述されたデータを取得するデータ取得部と、取得したデータに基づいてオブジェクトを生成するオブジェクト生成部と、生成したオブジェクトが２以上ある場合に、それらの参照関係を内部属性に基づいて判定する参照関係処理部と、生成したオブジェクトを第１のデータ集合体に保存する保存処理部と、参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるＩＤを抽出し、参照側となるオブジェクトの参照を示す内部属性を抽出したＩＤで更新する関係更新部と、を有するデータ処理システムである。
少なくとも２つのデータ集合体について、いずれかで追加、変更などがあった場合に、それらの関係性を維持したまま、相手方のデータ集合体にデータを反映可能とする、データ処理システムを提供することを目的とする。
【解決手段】
第２のデータ集合体に登録されたデータが所定の記述子で記述されたデータを取得するデータ取得部と、取得したデータに基づいてオブジェクトを生成するオブジェクト生成部と、生成したオブジェクトが２以上ある場合に、それらの参照関係を内部属性に基づいて判定する参照関係処理部と、生成したオブジェクトを第１のデータ集合体に保存する保存処理部と、参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるＩＤを抽出し、参照側となるオブジェクトの参照を示す内部属性を抽出したＩＤで更新する関係更新部と、を有するデータ処理システムである。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、少なくとも２つのデータベースやデータファイルなどにおける、データの集合体（以下、「データ集合体」という）について、データ集合体のいずれかで、データの追加、変更などがあった場合に、データの相互間の関係性を維持したまま、相手方のデータ集合体にデータを反映可能とする、データ処理システムに関する。
【背景技術】
【０００２】
コンピュータ端末では、さまざまなデータ集合体がその処理のために用いられる。そしてそれらは、互いに関係づけられる場合がある。たとえばデータ集合体がリレーショナルデータベースの場合、レコードを特定するためにプライマリーキーが用いられている。そして、あるテーブルにおける特定のレコードを参照する場合に、当該参照先のレコードのプライマリーキーにより、参照先を特定する。
【０００３】
たとえば、システムＡとシステムＢとがある場合を想定する。システムＢには、contactとconnectの２つのテーブルが存在しているとする（図４）。システムＢにおけるテーブルconnectのレコードconnect_id=20のデータは、テーブルcontactのcontact_idが１０のレコードを参照しているので、これら２つのデータには関係性がある。他方、システムＡには、システムＢと同名のテーブルcontactが存在しているとする（図５）。
【０００４】
そして、システムＢの２つのテーブルが、システムＡにそのまま反映されたとする。しかし、反映先のシステムＡにおいては、contact_idとしてすでに「１０」が使われている。この場合、システムＡでは、システムＢから受け取ったテーブルcontactのレコードcontact_id=10については、すでに使用されていることから使用できない。そこで、ほかのプライマリーキー、たとえば「１５」が割り当てられる。このとき、システムＡにおけるテーブルcontact、connectは、図６のようになる
【０００５】
図６において、テーブルconnectにおけるレコードconnect_id=20のデータは、テーブルcontact_id=10のレコードを参照したままとなっている。しかし上述のように、システムＡにおいてシステムＢから受け取ったテーブルcontactのレコードcontact_id=10については、新たにcontact_id=15が割り当てられているから、本来参照すべき正しいレコードは、contact_id=15のレコードである。このように、テーブルcontactにおいてcontact_idの新たな割り当てが行われたにもかかわらず、テーブルconnectにおいて、参照先となるcontact_idの変更が行われなかったことから、かかるデータの関係性の異常が発生する。
【０００６】
従って、システムＢから転送された２つのテーブルの関係性が、システムＡでは保たれないこととなり、システムＡにおけるテーブルconnectのconnect_id=20のデータは、テーブルcontactのcontact_id=10である別のデータに関係づけられてしまう。
【０００７】
そこで、かかる問題点を解決するために、たとえば下記特許文献１に示すような装置が用いられる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平１０−１４９３０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら上記特許文献１によれば、ステータスフラグを用いて処理を行わなければならず、不要なデータが増えてしまう。レコードが１つであればフラグが増えても問題がないが、大量のレコードとなった場合にはそれだけでもデータ量の増加を招いてしまう。また、ステータスフラグを用いずに変換テーブルを用いる方法もあり得るが、この場合には、別途、変換テーブルを作成、管理する必要がある。
【課題を解決するための手段】
【００１０】
本発明者は上記技術的課題に鑑み、本願発明におけるデータ処理システムを発明した。
【００１１】
第１の発明は、第２のデータ集合体に登録されたデータを第１のデータ集合体に反映させるデータ処理システムであって、前記データ処理システムは、前記第２のデータ集合体に登録されたデータに基づいて生成された、少なくともモデルとタイプとＩＤとを属性として含む記述子で記述されたデータを取得するデータ取得部と、前記データ取得部で取得したデータの記述子における所定の属性をオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成するオブジェクト生成部と、前記生成したオブジェクトが２以上ある場合に、それらの参照関係を前記内部属性に基づいて判定する参照関係処理部と、前記生成したオブジェクトを前記第１のデータ集合体に保存する保存処理部と、前記参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるＩＤを抽出し、参照側となるオブジェクトの参照を示す内部属性を前記抽出したＩＤで更新する関係更新部と、を有するデータ処理システムである。
【００１２】
本発明のように構成することで、仮に被参照側となるデータのプライマリーキーなどの識別情報（ＩＤ）が変更されたとしても、その内部属性は変わるが、その関係性を判定するオブジェクト名自体は変更されないので、それぞれの関係性を維持することが可能となる。
【００１３】
上述の発明において、前記オブジェクト生成部は、前記記述子における、少なくともモデルとタイプとＩＤとをオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成する、データ処理システムのように構成することもできる。
【００１４】
オブジェクト名としては、少なくともモデルとタイプとＩＤとを含むことが好ましい。
【００１５】
また上述の発明において、前記オブジェクト生成部は、前記記述子における、少なくともモデルとタイプとＩＤとをオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成し、前記保存処理部は、前記生成したオブジェクトの保存の際に、前記第１のデータ集合体において、前記記述子におけるＩＤの属性と同一のＩＤが使用されている場合には、前記ＩＤとは異なるＩＤを割り当て、前記生成したオブジェクトの内部属性におけるＩＤを、前記割り当てたＩＤで更新した上で、前記オブジェクトを前記第１のデータ集合体に保存する、データ処理システムのように構成することもできる。
【００１６】
上述の技術的効果を達成するために、本発明のように構成することもできる。
【００１７】
第２の発明は、データ集合体に登録されたデータをほかのデータ集合体に渡すことで反映させるコンピュータシステムであって、前記データ集合体に登録されたデータのうち、前記ほかのデータ集合体に送るデータを抽出し、少なくとも、データの種別を特定する文字列であるモデルと、データを受け入れるシステムで既存のデータかどうかの種別を表すタイプと、データを一意に特定するための値であるＩＤとを少なくとも含む記述子によって、前記抽出したデータを生成し、前記記述子によって記述されたデータを、前記ほかのデータ集合体を備えるコンピュータシステムに送り、前記記述子における属性に従ってオブジェクトを生成させることで、前記ほかのデータ集合体に登録させる、コンピュータシステムである。
【００１８】
本発明のように構成しても第１の発明と同様の技術的効果を得ることができる。
【００１９】
本発明のプログラムをコンピュータ端末で読み込み、実行することで、上述のデータ処理システムを実現することができる。すなわち、第２のデータ集合体に登録されたデータを第１のデータ集合体に反映させるコンピュータ端末を、前記第２のデータ集合体に登録されたデータに基づいて生成された、少なくともモデルとタイプとＩＤとを属性として含む記述子で記述されたデータを取得するデータ取得部、前記データ取得部で取得したデータの記述子における所定の属性をオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成するオブジェクト生成部、前記生成したオブジェクトが２以上ある場合に、それらの参照関係を前記内部属性に基づいて判定する参照関係処理部、前記生成したオブジェクトを前記第１のデータ集合体に保存する保存処理部、前記参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるＩＤを抽出し、参照側となるオブジェクトの参照を示す内部属性を前記抽出したＩＤで更新する関係更新部、として機能させるデータ処理プログラムのように構成することもできる。
【発明の効果】
【００２０】
本発明のデータ処理システムを用いることによって、あるデータ集合体から、別のデータ集合体にデータを反映する場合に、データ相互間の関係性に変更があったとしても、フラグを用いずにデータ間の関係性を維持することが可能となる。
【図面の簡単な説明】
【００２１】
【図１】本発明のデータ処理システムの全体の構成の一例を模式的に示す概念図である。
【図２】コンピュータ端末のハードウェア構成の一例を模式的に示す概念図である。
【図３】本発明のデータ処理システムを用いたフローチャートの一例を模式的に示す図である。
【図４】システムＢにおけるテーブルの一例を模式的に示す図である。
【図５】システムＡにおけるテーブルの一例を模式的に示す図である。
【図６】システムＡにおけるテーブルの一例を模式的に示す図である。
【図７】本発明におけるデータの記述子の一例を模式的に示す図である。
【図８】Cena記述子の表記方法の一例を模式的に示す図である。
【図９】データの登録画面の一例を模式的に示す図である。
【図１０】登録されるデータの一例を模式的に示す図である。
【図１１】図１０に基づくオブジェクトの一例を模式的に示す図である。
【図１２】２つのオブジェクト間における参照関係を模式的に示す図である。
【図１３】関係性を示す画面の一例を模式的に示す図である。
【図１４】システムＡにおけるデータの保存の一例を模式的に示す図である。
【図１５】システムＡにおけるデータの関係を保存した一例を模式的に示す図である。
【図１６】関係性が反映されてデータが保存された結果を示す画面の一例を模式的に示す図である。
【図１７】システムＢからシステムＡに送られるデータの一例である。
【図１８】データの保存の一例を模式的に示す図である。
【図１９】保存前と保存後のCena記述子の関係の一例を示す図である。
【図２０】関係性の変換が行われた場合の一例を模式的に示す図である。
【発明を実施するための形態】
【００２２】
本発明のデータ処理システム１の説明をするにあたり、本明細書における用語を定義する。
【００２３】
本発明のデータ処理システム１で処理対象とする情報を「データ」とする。ここでデータとは、データ処理システム１における何らかの資源、たとえばデータベースのレコードやファイルなどを意味する。つまり本発明のデータ処理システム１を用いることで操作する対象である。
【００２４】
データベースのデータの一例を、図７に示す。図７（ａ）では、データベースのテーブルcontact、connectの定義を示し、その定義を備えたレコードが図７（ｂ）である。
【００２５】
本発明のデータ処理システム１では、データへの操作を簡便に行うため、データを表すオブジェクトを生成し、処理を実行する。ここでオブジェクトとは、関係するデータを一つの塊と捉え、さらにデータに関係する処理を一緒に示すものであって、メモリ上のスペースが取られているデータである。たとえばJavaScriptにおける配列などもオブジェクトとして定義される。
【００２６】
そしてオブジェクトによってデータベースの各レコードが表現されるのがＯＲＭ（Object Relation Mapping）である。ＯＲＭにおいては、オブジェクトには属性が存在し、データベースのレコードの各項目に対応する。また、オブジェクトから別のオブジェクトへの参照を可能とすることで、リレーショナルデータベースの関係を、オブジェクト間の参照とすることができる。
【００２７】
また本発明のデータ処理システム１では、上述のデータを操作するため、データを一意に表現する記述子を用いる。この記述子を本明細書では「Cena記述子」と呼ぶ。
【００２８】
Cena記述子には少なくともモデル（Model）、タイプ（Type）、ＩＤの各属性を備えており、さらに属性としてスキーマ（Schema）を備えていても良い。すなわち、Cena記述子は、モデル、タイプ、ＩＤ、あるいはスキーマ、モデル、タイプ、ＩＤを含んでいる。
【００２９】
スキーマとは、記述子の記述方法あるいはデータの参照方法を指定する文字列である。記述子の記述方法あるいはデータの参照方法があらかじめ定まっている場合には、省略することが可能である。たとえばスキーマとして「Rdb」が指摘された場合には、「Rdb」（リレーショナルデータベース）の参照方法であることを示す。また「Cena」とあった場合には、本発明のデータ処理システム１で用いる記述子に基づく参照方法であることを示す。従って、スキーマは、いわば、プロトコルの種別を指定するので、任意に設定可能である。
【００３０】
モデルとは、データの種別を特定する文字列である。オブジェクトのインスタンスとして表すのに必要なクラス名、データベースのテーブル名、ＤＩ（Dependency Injection）を用いる場合のモデル名称などがある。
【００３１】
たとえば、モデルが一番単純なデータベースのテーブル名を表すとした場合、
object=Sql.table(Model);
となる。また、モデルがクラス名を表し、各オブジェクトを生成する場合には、
object=new Model()；
となる。また、モデルをfactoryと呼ばれるメソッドから作成する場合には、
object=Model.factory();
となる。さらに、別のオブジェクトからオブジェクトを生成する場合には、
object=Dl.factory(Model);
となる。このように、モデルは必ずしもテーブル名やクラス名ではないが、オブジェクト（データ）の種別を特定するための文字列となる。
【００３２】
タイプとは、データを受け入れたシステムで既存のデータかどうかの判断種別を示す文字列である。たとえばサーバ（図１のシステム２）上のデータを「get」とし、クライアント（図１のシステム３）で作成されたデータには「new」を記述する。
【００３３】
ＩＤとは、データを一意に特定するための値であり、データベースであればプライマリーキーが該当する。ＩＤを用いることによって、モデルおよびタイプごとに一意にデータを特定できる。
【００３４】
以上に基づけば、ある特定のデータは、「モデル、タイプ、ＩＤ」の３属性を有する記述子によって特定される。また別の場合によっては、「スキーマ、モデル、タイプ、ＩＤ」の４属性を有する記述子によって特定されることもある。なお、Cena記述子を構成する属性については上記以外の属性が含まれていても良く、属性の数に制限はない。
【００３５】
たとえば、図４をCena記述子を用いて示す。テーブルcontactの各レコードをdao_contactというクラスで表している場合、そのモデルはdao_contactとなる。そしてデータはすでにシステムＢに存在しているのでタイプは「get」であり、プライマリーキーは「１０」となる。すなわち、Cena.dao_contact.get.10のCena記述子で示される。なお、以下の説明では、ＯＲＭを用いた場合で説明する。
【００３６】
データを一意に指定した次には、指定したデータに対して操作を行うことが可能となる。操作には、プロパティの設定、関係の設定、データそのものに対する操作などがある。つまり、データには属性としてプロパティが含まれている。たとえば、図４において、テーブルcontactは、nameをプロパティとして含んでいる。また、特殊な属性として関係（リレーション）がある。関係とは、ほかのデータを参照するもので、単なる値であるプロパティとは区別される。たとえば、図４において、テーブルconnectはプロパティとしてmethod（メソッド）を含み、リレーションとしてcontact_id='10'と関係している。このように、オブジェクト（データ）のCena記述子に操作内容や操作に必要なデータを追加して表現をする。
【００３７】
データを指定するCena記述子に操作内容（Action）を追加することもできる。たとえば、上述のcontact_id='10'を削除する場合、そのデータは、Cena.dao_contact.get.10によって指定される。このCena記述子に、削除の操作を示すAction='del'を追加する。すなわちCena記述子はCena.dao_contact.get.10.delとなる。
【００３８】
さらにデータを指定するCena記述子に操作内容（Action）と必要なプロパティ名を追加し、データを指定するCena記述子とすることもできる。たとえば、上述のcontact_id='10'の名前を変更する場合、そのデータは、Cena.dao_contact.get.10によって指定される。このCena記述子に、変更の操作を示すAction='set'とプロパティ（name）を追加し、新たな値、たとえば「特許 三郎」を指定する。そうするとCena記述子は、「Cena.dao_contact.get.10.set.name='特許 三郎'」となる。
【００３９】
さらにデータを指定するCena記述子に操作内容（Action）と必要なプロパティ名を追加し、参照するデータを表すCena記述子とすることもできる。たとえば、上述のconnect_id='20'の関係を変更する場合、そのデータは、Cena.dao_connect.get.20によって指定される。このCena記述子に、関係の変更の操作を示すAction='rel'とプロパティ（contact_id）を追加し、参照するデータのCena記述子、たとえばcontact_id='20'と関係することを指定する。そうするとCena記述子は、Cena.dao_connect.get.10.rel.contact_id=Cena.dao_contact.get.20となる。
【００４０】
すなわち、Cena記述子においては、従来はそのデータベースにおけるプライマリーキーのみ（あるいはＩＤのみ）によってデータを一意に特定していたのに対し、少なくともデータの種類を特定する文字列であるモデルと、データの種別を特定する文字列であるタイプと、データを一意に特定する値であるＩＤとを用いて特定することで、データの種別なども併せて当該Cena記述子のみからデータを一意に特定することができる。さらには、属性としてさまざまなものを指定できる。
【００４１】
以上のように定められるCena記述子にはいくつかの表記方法を用いることができる。たとえば文字列表記、配列表記、ＪＳＯＮ表記などがある。これを模式的に示すのが図８である。なお、Cena記述子としては、上記に限定されず、少なくともモデル、タイプ、ＩＤ、あるいはスキーマ、モデル、タイプ、ＩＤを含む属性から構成されれば、如何なる表現方法を採っても良い。文字列表記は、Cena記述子の各属性を文字列と「．」（ピリオド）で区切ることで表記する。配列表記は、Cena記述子の各属性を配列の各属性として代入することで表記する。ＪＳＯＮ表記（JavaScript Object Notation）に基づく表記である。
【００４２】
次に、上述のように構成されるCena記述子を用いて、本発明におけるデータ処理システム１の構成、処理を説明する。図１に、データ処理システム１の全体の構成の一例を模式的に示す。なおデータ処理システム１におけるデータ集合体としては、データベース、データファイル、音楽ファイル、映像ファイルなど如何なるものであっても良く、データの集合体であればよい。また、データ処理システム１は、図１では、それぞれにデータ集合体を備える２つのコンピュータ端末（システム３、システム２）の場合であって、一のコンピュータ端末から他方のコンピュータ端末にデータが転送されることで、そのデータが追加、反映される場合の処理を示しているが、これが一つのコンピュータ端末で実現されていても良い。
【００４３】
コンピュータ端末は、プログラムの演算処理を実行するＣＰＵなどの演算装置２０と、情報を記憶するＲＡＭやハードディスクなどの記憶装置２１と、ディスプレイ（画面）などの表示装置２２と、キーボードやポインティングデバイス（マウスやテンキーなど）などの入力装置２３と、演算装置２０の処理結果や記憶装置２１に記憶する情報をインターネットやＬＡＮなどのネットワークを介して送受信する通信装置２４とを有している。コンピュータ上で実現する各機能（各手段）は、その処理を実行する手段（プログラムやモジュールなど）が演算装置２０に読み込まれることでその処理が実行される。各機能は、記憶装置２１に記憶した情報をその処理において使用する場合には、該当する情報を当該記憶装置２１から読み出し、読み出した情報を適宜、演算装置２０における処理に用いる。図２にコンピュータ端末のハードウェア構成の一例を模式的に示す。また、コンピュータ端末は、複数のコンピュータまたはサーバに、その機能が分散配置されていても良い。
【００４４】
本発明における各手段は、その機能が論理的に区別されているのみであって、物理上あるいは事実上は同一の領域を為していても良い。
【００４５】
データ処理システム１には、少なくとも２以上のデータ集合体と、そのデータ集合体に対する処理を実行する各種の処理部とを有する。
【００４６】
データ集合体は、上述のようにデータの集合体である。なお本明細書の以下の説明ではデータ集合体としてデータベースの場合を説明するが、それに限るものではなく、同様に処理を実現することができる。
【００４７】
データ処理システムにおける処理部は、データ集合体におけるデータについて、データの関係性を維持したまま、他のデータ集合体に反映させる処理を実現する。処理部としては、データ取得部１１とオブジェクト生成部１２と参照関係処理部１３と保存処理部１４と関係更新部１５とを有する。
【００４８】
データ取得部１１は、ほかのデータ集合体からCena記述子によるデータを取得する。たとえば図１の場合、第２のデータ集合体２Ｄ（データベースＢ）から、第１のデータ集合体３Ｄ（データベースＡ）に反映させるデータを取得する。ここで取得するデータは、上述のCena記述子で記述されている。
【００４９】
オブジェクト生成部１２は、データ取得部１１で取得したデータに基づいて、オブジェクトを生成する。オブジェクトを生成するには、Cena記述子を構成する属性を抽出し、抽出した属性を、それぞれオブジェクトの属性とすることで生成する。
【００５０】
参照関係処理部１３は、生成したオブジェクトが２以上ある場合に、それらの参照関係があるかを判定する。すなわち、オブジェクト生成部１２で生成したオブジェクトにおける、参照関係を示す属性に基づき、オブジェクト同士の参照関係を判定する。
【００５１】
そして参照関係処理部１３は、参照関係があることを判定すると、それぞれを関係づけて、関係づけたオブジェクトについて、そのタイプが、データの反映先で生成されたことを示すもの（たとえば「get」）であるかを判定する。
【００５２】
保存処理部１４は、参照関係処理部１３で生成したオブジェクトを、データ集合体（データベース）に保存する。オブジェクトを保存する際には、そのオブジェクトを示すCena記述子のうち、先頭から所定数（たとえば先頭から３あるいは４など）の属性を抽出し、それをオブジェクト名とし、オブジェクト名と属性とを対応づけて第１のデータ集合体３Ｄに保存する。またこの際に、オブジェクトの属性を更新して保存することとなる。また保存したオブジェクトの属性におけるタイプを、「get」にして更新する。ここで、タイプが「get」になるのは、当該オブジェクトが第２のデータ集合体を備えるシステム２から取得したからである。すなわち、もともとシステム３のオブジェクトではないため、「get」に更新して保存する。
【００５３】
関係更新部１５は、保存処理部１４がデータ集合体で保存処理を実行後、データ集合体での関係を表すことが可能となるので、関係更新部１５は、関係性があるオブジェクトから、保存されたオブジェクトにおけるＩＤを読み込み、それを、関係づけられているレコードに反映して記憶させる。
【００５４】
次に、本発明のデータ処理システム１の処理を図３のフローチャートを用いて説明する。以下の説明では、サーバであるシステム２のデータベース（データベースＢ）からデータをシステム３に転送し、システム３のデータベース（データベースＡ）で登録する場合を説明する。
【００５５】
まずシステム２で、図９に示すデータの登録画面からデータの入力が行われることで、データベースＢにデータが追加されたとする。この追加されたデータについて、上述のCena記述子を用いると図１０に示すようになる。
【００５６】
つまり、名前として「特許 三郎」、性別として「男性」、分類として「仕事」、日付として「２０１１−０１−０１」を入力すると、それがテーブルcontactのレコード（クラス）dao_contactのプライマリーキー「１０」に対応づけて記憶される。また、連絡方法として「Facebook」、参照データ（関連づけるデータ）として「Cena.dao_contact.new.10」、分類として「ＴＥＬ」を入力すると、それが、テーブルconnectのレコード（クラス）dao_connectのプライマリーキー「１１」に対応づけて記憶される。そしてこれらに基づいて、Cena記述子に変換される。なお、データに対する属性の入力の代わりに、プルダウンメニューなどで選択入力可能としても良い。特に参照データについては、関連づける相手先のレコードやプライマリーキーなどに基づいて、自動的に入力されるようにしてもよい。これによって入力ミスなどを防止することができる。
【００５７】
具体的には、テーブルcontactのレコードdao_contactにおけるCena記述子Cena.dao_contact.new.10に対して、属性、つまり名前「特許 三郎」、性別「男性」、分類「仕事」および日付が「２０１１年１月１日」を対応付けてデータベースＢに記憶する。また、テーブルconnectのレコードdao_connectにおけるCena記述子Cena.dao_connect.new.11に対して、属性、つまり連絡方法「Facebook」、その参照データ「Cena.dao_contact.new.10」および分類「ＴＥＬ」を対応づけてデータベースＢに記憶する。なお、図１０では説明の便宜上、当該Cena記述子に対しては名前のみを示しており、それ以外は図から省略しているが、以下の処理でも名前の場合と同様に処理可能である。
【００５８】
また、上述では２つのレコードから２つのオブジェクトの場合を示したが、レコードを自己参照して、１つのレコードから２つのオブジェクトを生成する場合もある。
【００５９】
以上のようにしてシステム２で生成したCena記述子によるデータについて、所定の操作をすることで、システム３に転送する。
【００６０】
このようにして転送されたデータ（Cena記述子で記述されるデータ）を、システム３のデータ処理システム１のデータ取得部１１で取得する（Ｓ１００）。
【００６１】
データ取得部１１で取得したデータ（Cena記述子で記述されるデータ）に基づいて、データ処理システム１のオブジェクト生成部１２は、オブジェクトを生成する（Ｓ１１０）。これはデータ取得部１１で取得した、Cena記述子での記述のうち、スキーマ、モデル、タイプ、ＩＤの最初の４属性に基づいて、オブジェクトを生成する。すなわち、先頭のスキーマの文字列によって、Cena記述子で記述されていることを特定することで、２番目の属性をモデル、３番目の属性をタイプ、４番目の属性をＩＤとして特定できるので、それに基づきオブジェクトの属性を生成する。またそれ以外の部分についてはオブジェクトの属性を生成する。
【００６２】
すなわち、Cena.dao_contact.new.10では、先頭の属性の文字列によりCena記述子であることを特定できるので、２番目の属性がモデル、つまりデータの種別（データベースの場合にはテーブル名）を特定し、３番目の属性がタイプ、つまりデータの種別（新たに追加されたデータ（new）か、システム３で作成されたデータ（get）か）を特定し、４番目の属性がＩＤ、つまりデータを一意に特定する値であることを特定し、それぞれをオブジェクトの属性とする。また、さらに、それ５番目以降の属性については、それぞれを値としてオブジェクトの属性とする。
【００６３】
このようにシステム３から取得したデータのうち、先頭から所定数（たとえば４番目）の属性に基づいてオブジェクトを生成する。なお先頭にスキーマを用いない場合（つねにCena記述子を用いることが特定されている場合など）では、スキーマを用いずに自動的にオブジェクト生成部１２がオブジェクトを生成する。図１０に基づく２つのオブジェクトが図１１である。２つのオブジェクトとなるのは、モデルが２つ、すなわちデータベースのテーブルが２つだからである。
【００６４】
Ｓ１１０において、オブジェクト生成部１２がオブジェクトを生成すると、参照関係処理部１３が、生成したオブジェクト間における参照関係が存在するかを判定する。すなわち、オブジェクトの各属性を参照し、参照関係があるかを判定する（Ｓ１２０）。
【００６５】
参照関係がなければＳ１６０以降の処理を実行する。一方、参照関係がある場合には、Ｓ１３０以降の処理を実行する。
【００６６】
図１１の場合、オブジェクトCena.dao_connect.new.11では、オブジェクトCena.dao_contact.new.10を参照している（rel.contact_id=Cena.dao_contact.new.10）。従って、参照関係処理部１３は、参照関係があると判定できる。これを模式的に示すのが図１２である。
【００６７】
参照関係処理部１３で参照関係があることを判定すると、参照関係処理部１３は，参照関係があると判定したオブジェクトについて、それぞれを関係づける（Ｓ１３０）。そして関係づけることによって、システム３において、図１３に示すような画面を表示装置２２で表示し、これを反映することの入力を受け付ける。図１３では、ＩＤを表示しているが、表示しないように構成することもできる。また、上述の関係づけはいわゆるデータ間の紐付けで行われればよい。
【００６８】
また、参照関係処理部１３で参照関係がないと判定した場合にも、対応する画面を表示する表示装置２２で表示をし、それを反映することの入力を受け付けてもよいし、受け付けずにそのまま処理を行っても良い。
【００６９】
そしてＳ１３０でオブジェクトの関係づけを参照関係処理部１３が行うと、参照関係処理部１３が、関係づけられるオブジェクトのタイプが「get」（データの反映先であるシステム３以外のシステムで作成されたデータであることを示すタイプ）であるかを判定する（Ｓ１４０）。なおタイプとしては「get」のほかに、「new」があり、これは、データの反映先であるシステム３で作成されたデータであることを示すタイプである。つまり、Ｓ１４０では、反映先のシステムで作成したデータであるかを判定している。
【００７０】
タイプが「get」である場合には、システム３で作成したデータではないので、そのオブジェクトのＩＤを取得する。ここでは、ＩＤとして、オブジェクトCena.dao_contact.new.10については「１０」を、オブジェクトCena.dao_connect.new.11については「１１」を取得することとなる（Ｓ１５０）。なお、タイプが「new」である場合には、システム３で作成したデータなので、Ｓ１６０以降の処理を実行する。
【００７１】
Ｓ１５０までの処理が終了後、すなわち、Ｓ１１０でオブジェクト生成部１２で生成したオブジェクトおよびＳ１３０で関係づけたオブジェクト間の関係の作成が完了したら、オブジェクト生成部１２で生成したオブジェクトを、保存処理部１４が、システム３のデータベースＡに保存する（Ｓ１６０）。これによって、オブジェクトにおけるプライマリーキー（ＩＤ）などの属性もデータベースＡに反映されることとなる。
【００７２】
なお、Ｓ１６０で保存する場合には、そのオブジェクトを示すCena記述子のうち、先頭から所定数（たとえば先頭から３あるいは４など）の属性を抽出し、それをオブジェクト名とし、オブジェクト名と属性とを対応づけて保存する。また、オブジェクトの属性を更新して保存する。この場合、システム３は、システム２から受け取ったデータを保存したので、タイプは「get」となる。これを模式的に示すのが図１４である。なお、図１４では、テーブルcontactでは、すでにＩＤの「１０」が使われており、「１５」が割り当てられたとする。
【００７３】
図１４の場合、図１０に示すCena記述子に基づいてオブジェクトが生成されている。すなわち、図１０に示すCena記述子の場合、先頭から４属性までをオブジェクト名とするので、「Cena.dao_contact.new.10」がオブジェクト名となる。そして各Cena記述子に基づいて、オブジェクト名に対応づけてそれぞれ当該オブジェクトの属性が保存されることとなる。
【００７４】
このように、Ｓ１６０における保存の処理によって、オブジェクト内部の属性は変更されうるが、同じオブジェクトとして認識されるため、オブジェクト間の関係には影響がない。つまり、図１４では、テーブルdao_contactにおいて、contact_idとして「１０」がすでに使用されていることから、保存の際には、自動的に「１５」が割り当てられた。これによってオブジェクトCena.dao_contact.new.10の内部の属性のＩＤは変わったが、オブジェクトを表すCena記述子そのものは変更がなく、オブジェクト間の関係も保持されたままとなる。
【００７５】
またＳ１６０で関係を保存する際に、相手のオブジェクトのタイプを確認することもできる。もしタイプが「get」であれば、当該オブジェクトのＩＤは反映先のデータベースでのプライマリーキー（ＩＤ）と一致する。そこでオブジェクトが保存される前にＩＤを取得しておき、関係をデータベース上に保存することが可能である。また、タイプが「new」の場合には、ＩＤが変更される場合があるため、関係先のオブジェクトが保存された後のＩＤを用いる。
【００７６】
以上のようにして、Ｓ１２０で判定した、オブジェクトのすべての関係性について、その関係性を保存したかを判定し（Ｓ１７０）、すべての関係が保存された場合にはその処理を終了する。一方、そうでない場合には、Ｓ１８０以降の処理を実行する。すなわちデータ処理システム１は、関係更新部１５において、関係更新処理を実行する（Ｓ１８０）。
【００７７】
すなわち、保存処理部１４がデータベースＡに保存処理を実行後、データベースＡ上での関係を表すことが可能となる。従って、関係更新部１５は、関係しているオブジェクトから保存されたオブジェクトにおけるＩＤ（プライマリーキー）を読み込み（Ｓ１８０)、Cena記述子におけるタイプに基づくレコード上に保存する（Ｓ１９０）。
【００７８】
上述の例の場合、オブジェクトCena.dao_connect.new.11に関係するオブジェクトCena.dao_contact.new.10が保存される際に、当該オブジェクトに割り当てられる最終的なＩＤ（プライマリーキー）が「１５」で割り当てられているので、割り当てられたＩＤ「１５」を関係更新部１５が読み込む（Ｓ１８０）。そして、オブジェクトCena.dao_connect.new.11のcontact_idを、読み込んだ「１５」として決定してその関係を保存する（Ｓ１９０）。これを模式的に示すのが図１５である。またこの関係性が反映されてデータが保存された結果を示す画面の一例が図１６である。
【００７９】
以上のような処理を実行することで、２つのデータベースにおいて、データの追加・変更等がある場合にも、フラグを用いずにデータ間の連携を保持することが可能となる。
【００８０】
また、オブジェクトとして、配列または連想配列を用いて上述の処理と同様の処理を実行することが可能となる。すなわち、配列に反映するデータを保存し、Cena記述子で配列を読み込めば良い。
【００８１】
まず転送の対象となるデータから配列を生成する。この配列は、上述のCena記述子を用いて配列の参照が行われるようにする。次に、各レコード間の関係がCena記述子を用いて表されているので、Cena記述子から関係する配列を求め、配列間の関係として表す。そして、必要な配列および配列間の関係の生成が完了後、配列を実際のデータベースに保存する。保存したら、配列のデータを、保存された内容に更新する。またデータが、転送を受け取ったシステム（ここではシステム３）に保存されたことから、タイプが「get」に更新される。保存の処理が終了後、データベースでの関係を表すことが可能となるので、関係している配列から、保存されたＩＤ（プライマリーキー）を読み込み、関係づけて自身のレコード上に保存する。
【００８２】
以上のような処理を実行することで、配列または連想配列を用いた場合でも処理が実現可能となる。
【００８３】
また本発明のデータ処理システム１で用いるCena記述子を用いて関係を表す場合、その関係性を簡単に保持することが可能となる。以下にこの点について説明する。なお、以下の処理は、上述の図３のフローチャートと同様の部分もある。
【００８４】
上述と同様に、システム２で追加されたデータを、システム３で登録する場合を説明する。従って、システム２からシステム３には、たとえば図１７に示すデータが送られる。図１７の場合、テーブルdao_contactにプライマリーキー「１０」のレコードとして「特許 三郎」が追加され、テーブルdao_connectにプライマリーキー「１１」のレコードとしてFacebook、当該レコードが、テーブルdao_contactにプライマリーキー「１０」のレコードと関係づけられている場合を示している。
【００８５】
システム３で、システム２から図１７のデータを取得すると、それをデータベースＡに保存する。またデータベースＡでは、すでにＩＤ「１０」が使用されている場合、使用されていないＩＤ、たとえば「１５」が割り当てられる。
【００８６】
また、オブジェクトをデータベースＡに保存することで、タイプは「get」に代わり、テーブルcontactのＩＤは「１５」で保存される。これを模式的に示すのが図１８である。
【００８７】
そしてデータベースＡへの保存前と保存後のCena記述子の関係を作成する。図１８の場合、図１９のようになる。そしてデータベースＡの保存前と保存後との関係から、保存前のCena記述子を、保存後のCena記述子に変換する。
【００８８】
上述の例では、テーブルdao_contactにおいて、ＩＤが「contact_id=15」に変更されたことから、テーブルdao_connectでその関係性の変換が行われる。すなわち、Cena.dao_contact.new.10がCena.dao_contact.get.15に変換される。これを模式的に示すのが図２０である。
【００８９】
このようにCena記述子は、すべてのデータ（システム上に存在するデータおよび新たに登録するデータ）を一意に指定している。つまり、Cena記述子自体も一意の文字列であるため、単純なテキストの変換を行うことで、それらの関係性を更新することができる。これは、データベースに保存する際に、Cena記述子からＩＤ（データベースの場合にはプライマリーキー）を取得することで抜き出す。
【００９０】
また、システム３とシステム２とで同期を取る場合には、Cena記述子の変更履歴を用いて、反映元（システム２）のデータベースと転送を受け取った側のデータベースを同期することが可能である。以上の処理で得られた変更履歴を転送元のシステム（システム２）へ転送し、転送元のシステム（システム２）では、その変更履歴を用いて、データベース上のＩＤ（データベースの場合、プライマリーキー）および関係を更新することが可能となる。
【産業上の利用可能性】
【００９１】
上述したデータ処理システム１によって、あるデータ集合体から、別のデータ集合体にデータを反映する場合に、データの関係性に変更があったとしても、フラグを用いずにデータ間の連携を維持することが可能となる。
【符号の説明】
【００９２】
１：データ処理システム
２：システム
２Ｄ：第２のデータ集合体
３：システム
３Ｄ：第１のデータ集合体
１１：データ取得部
１２：オブジェクト生成部
１３：参照関係処理部
１４：保存処理部
１５：関係更新部
２０：演算装置
２１：記憶装置
２２：表示装置
２３：入力装置
２４：通信装置
３１：第１のデータ集合体
３２：第２のデータ集合体
【技術分野】
【０００１】
本発明は、少なくとも２つのデータベースやデータファイルなどにおける、データの集合体（以下、「データ集合体」という）について、データ集合体のいずれかで、データの追加、変更などがあった場合に、データの相互間の関係性を維持したまま、相手方のデータ集合体にデータを反映可能とする、データ処理システムに関する。
【背景技術】
【０００２】
コンピュータ端末では、さまざまなデータ集合体がその処理のために用いられる。そしてそれらは、互いに関係づけられる場合がある。たとえばデータ集合体がリレーショナルデータベースの場合、レコードを特定するためにプライマリーキーが用いられている。そして、あるテーブルにおける特定のレコードを参照する場合に、当該参照先のレコードのプライマリーキーにより、参照先を特定する。
【０００３】
たとえば、システムＡとシステムＢとがある場合を想定する。システムＢには、contactとconnectの２つのテーブルが存在しているとする（図４）。システムＢにおけるテーブルconnectのレコードconnect_id=20のデータは、テーブルcontactのcontact_idが１０のレコードを参照しているので、これら２つのデータには関係性がある。他方、システムＡには、システムＢと同名のテーブルcontactが存在しているとする（図５）。
【０００４】
そして、システムＢの２つのテーブルが、システムＡにそのまま反映されたとする。しかし、反映先のシステムＡにおいては、contact_idとしてすでに「１０」が使われている。この場合、システムＡでは、システムＢから受け取ったテーブルcontactのレコードcontact_id=10については、すでに使用されていることから使用できない。そこで、ほかのプライマリーキー、たとえば「１５」が割り当てられる。このとき、システムＡにおけるテーブルcontact、connectは、図６のようになる
【０００５】
図６において、テーブルconnectにおけるレコードconnect_id=20のデータは、テーブルcontact_id=10のレコードを参照したままとなっている。しかし上述のように、システムＡにおいてシステムＢから受け取ったテーブルcontactのレコードcontact_id=10については、新たにcontact_id=15が割り当てられているから、本来参照すべき正しいレコードは、contact_id=15のレコードである。このように、テーブルcontactにおいてcontact_idの新たな割り当てが行われたにもかかわらず、テーブルconnectにおいて、参照先となるcontact_idの変更が行われなかったことから、かかるデータの関係性の異常が発生する。
【０００６】
従って、システムＢから転送された２つのテーブルの関係性が、システムＡでは保たれないこととなり、システムＡにおけるテーブルconnectのconnect_id=20のデータは、テーブルcontactのcontact_id=10である別のデータに関係づけられてしまう。
【０００７】
そこで、かかる問題点を解決するために、たとえば下記特許文献１に示すような装置が用いられる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平１０−１４９３０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら上記特許文献１によれば、ステータスフラグを用いて処理を行わなければならず、不要なデータが増えてしまう。レコードが１つであればフラグが増えても問題がないが、大量のレコードとなった場合にはそれだけでもデータ量の増加を招いてしまう。また、ステータスフラグを用いずに変換テーブルを用いる方法もあり得るが、この場合には、別途、変換テーブルを作成、管理する必要がある。
【課題を解決するための手段】
【００１０】
本発明者は上記技術的課題に鑑み、本願発明におけるデータ処理システムを発明した。
【００１１】
第１の発明は、第２のデータ集合体に登録されたデータを第１のデータ集合体に反映させるデータ処理システムであって、前記データ処理システムは、前記第２のデータ集合体に登録されたデータに基づいて生成された、少なくともモデルとタイプとＩＤとを属性として含む記述子で記述されたデータを取得するデータ取得部と、前記データ取得部で取得したデータの記述子における所定の属性をオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成するオブジェクト生成部と、前記生成したオブジェクトが２以上ある場合に、それらの参照関係を前記内部属性に基づいて判定する参照関係処理部と、前記生成したオブジェクトを前記第１のデータ集合体に保存する保存処理部と、前記参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるＩＤを抽出し、参照側となるオブジェクトの参照を示す内部属性を前記抽出したＩＤで更新する関係更新部と、を有するデータ処理システムである。
【００１２】
本発明のように構成することで、仮に被参照側となるデータのプライマリーキーなどの識別情報（ＩＤ）が変更されたとしても、その内部属性は変わるが、その関係性を判定するオブジェクト名自体は変更されないので、それぞれの関係性を維持することが可能となる。
【００１３】
上述の発明において、前記オブジェクト生成部は、前記記述子における、少なくともモデルとタイプとＩＤとをオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成する、データ処理システムのように構成することもできる。
【００１４】
オブジェクト名としては、少なくともモデルとタイプとＩＤとを含むことが好ましい。
【００１５】
また上述の発明において、前記オブジェクト生成部は、前記記述子における、少なくともモデルとタイプとＩＤとをオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成し、前記保存処理部は、前記生成したオブジェクトの保存の際に、前記第１のデータ集合体において、前記記述子におけるＩＤの属性と同一のＩＤが使用されている場合には、前記ＩＤとは異なるＩＤを割り当て、前記生成したオブジェクトの内部属性におけるＩＤを、前記割り当てたＩＤで更新した上で、前記オブジェクトを前記第１のデータ集合体に保存する、データ処理システムのように構成することもできる。
【００１６】
上述の技術的効果を達成するために、本発明のように構成することもできる。
【００１７】
第２の発明は、データ集合体に登録されたデータをほかのデータ集合体に渡すことで反映させるコンピュータシステムであって、前記データ集合体に登録されたデータのうち、前記ほかのデータ集合体に送るデータを抽出し、少なくとも、データの種別を特定する文字列であるモデルと、データを受け入れるシステムで既存のデータかどうかの種別を表すタイプと、データを一意に特定するための値であるＩＤとを少なくとも含む記述子によって、前記抽出したデータを生成し、前記記述子によって記述されたデータを、前記ほかのデータ集合体を備えるコンピュータシステムに送り、前記記述子における属性に従ってオブジェクトを生成させることで、前記ほかのデータ集合体に登録させる、コンピュータシステムである。
【００１８】
本発明のように構成しても第１の発明と同様の技術的効果を得ることができる。
【００１９】
本発明のプログラムをコンピュータ端末で読み込み、実行することで、上述のデータ処理システムを実現することができる。すなわち、第２のデータ集合体に登録されたデータを第１のデータ集合体に反映させるコンピュータ端末を、前記第２のデータ集合体に登録されたデータに基づいて生成された、少なくともモデルとタイプとＩＤとを属性として含む記述子で記述されたデータを取得するデータ取得部、前記データ取得部で取得したデータの記述子における所定の属性をオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成するオブジェクト生成部、前記生成したオブジェクトが２以上ある場合に、それらの参照関係を前記内部属性に基づいて判定する参照関係処理部、前記生成したオブジェクトを前記第１のデータ集合体に保存する保存処理部、前記参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるＩＤを抽出し、参照側となるオブジェクトの参照を示す内部属性を前記抽出したＩＤで更新する関係更新部、として機能させるデータ処理プログラムのように構成することもできる。
【発明の効果】
【００２０】
本発明のデータ処理システムを用いることによって、あるデータ集合体から、別のデータ集合体にデータを反映する場合に、データ相互間の関係性に変更があったとしても、フラグを用いずにデータ間の関係性を維持することが可能となる。
【図面の簡単な説明】
【００２１】
【図１】本発明のデータ処理システムの全体の構成の一例を模式的に示す概念図である。
【図２】コンピュータ端末のハードウェア構成の一例を模式的に示す概念図である。
【図３】本発明のデータ処理システムを用いたフローチャートの一例を模式的に示す図である。
【図４】システムＢにおけるテーブルの一例を模式的に示す図である。
【図５】システムＡにおけるテーブルの一例を模式的に示す図である。
【図６】システムＡにおけるテーブルの一例を模式的に示す図である。
【図７】本発明におけるデータの記述子の一例を模式的に示す図である。
【図８】Cena記述子の表記方法の一例を模式的に示す図である。
【図９】データの登録画面の一例を模式的に示す図である。
【図１０】登録されるデータの一例を模式的に示す図である。
【図１１】図１０に基づくオブジェクトの一例を模式的に示す図である。
【図１２】２つのオブジェクト間における参照関係を模式的に示す図である。
【図１３】関係性を示す画面の一例を模式的に示す図である。
【図１４】システムＡにおけるデータの保存の一例を模式的に示す図である。
【図１５】システムＡにおけるデータの関係を保存した一例を模式的に示す図である。
【図１６】関係性が反映されてデータが保存された結果を示す画面の一例を模式的に示す図である。
【図１７】システムＢからシステムＡに送られるデータの一例である。
【図１８】データの保存の一例を模式的に示す図である。
【図１９】保存前と保存後のCena記述子の関係の一例を示す図である。
【図２０】関係性の変換が行われた場合の一例を模式的に示す図である。
【発明を実施するための形態】
【００２２】
本発明のデータ処理システム１の説明をするにあたり、本明細書における用語を定義する。
【００２３】
本発明のデータ処理システム１で処理対象とする情報を「データ」とする。ここでデータとは、データ処理システム１における何らかの資源、たとえばデータベースのレコードやファイルなどを意味する。つまり本発明のデータ処理システム１を用いることで操作する対象である。
【００２４】
データベースのデータの一例を、図７に示す。図７（ａ）では、データベースのテーブルcontact、connectの定義を示し、その定義を備えたレコードが図７（ｂ）である。
【００２５】
本発明のデータ処理システム１では、データへの操作を簡便に行うため、データを表すオブジェクトを生成し、処理を実行する。ここでオブジェクトとは、関係するデータを一つの塊と捉え、さらにデータに関係する処理を一緒に示すものであって、メモリ上のスペースが取られているデータである。たとえばJavaScriptにおける配列などもオブジェクトとして定義される。
【００２６】
そしてオブジェクトによってデータベースの各レコードが表現されるのがＯＲＭ（Object Relation Mapping）である。ＯＲＭにおいては、オブジェクトには属性が存在し、データベースのレコードの各項目に対応する。また、オブジェクトから別のオブジェクトへの参照を可能とすることで、リレーショナルデータベースの関係を、オブジェクト間の参照とすることができる。
【００２７】
また本発明のデータ処理システム１では、上述のデータを操作するため、データを一意に表現する記述子を用いる。この記述子を本明細書では「Cena記述子」と呼ぶ。
【００２８】
Cena記述子には少なくともモデル（Model）、タイプ（Type）、ＩＤの各属性を備えており、さらに属性としてスキーマ（Schema）を備えていても良い。すなわち、Cena記述子は、モデル、タイプ、ＩＤ、あるいはスキーマ、モデル、タイプ、ＩＤを含んでいる。
【００２９】
スキーマとは、記述子の記述方法あるいはデータの参照方法を指定する文字列である。記述子の記述方法あるいはデータの参照方法があらかじめ定まっている場合には、省略することが可能である。たとえばスキーマとして「Rdb」が指摘された場合には、「Rdb」（リレーショナルデータベース）の参照方法であることを示す。また「Cena」とあった場合には、本発明のデータ処理システム１で用いる記述子に基づく参照方法であることを示す。従って、スキーマは、いわば、プロトコルの種別を指定するので、任意に設定可能である。
【００３０】
モデルとは、データの種別を特定する文字列である。オブジェクトのインスタンスとして表すのに必要なクラス名、データベースのテーブル名、ＤＩ（Dependency Injection）を用いる場合のモデル名称などがある。
【００３１】
たとえば、モデルが一番単純なデータベースのテーブル名を表すとした場合、
object=Sql.table(Model);
となる。また、モデルがクラス名を表し、各オブジェクトを生成する場合には、
object=new Model()；
となる。また、モデルをfactoryと呼ばれるメソッドから作成する場合には、
object=Model.factory();
となる。さらに、別のオブジェクトからオブジェクトを生成する場合には、
object=Dl.factory(Model);
となる。このように、モデルは必ずしもテーブル名やクラス名ではないが、オブジェクト（データ）の種別を特定するための文字列となる。
【００３２】
タイプとは、データを受け入れたシステムで既存のデータかどうかの判断種別を示す文字列である。たとえばサーバ（図１のシステム２）上のデータを「get」とし、クライアント（図１のシステム３）で作成されたデータには「new」を記述する。
【００３３】
ＩＤとは、データを一意に特定するための値であり、データベースであればプライマリーキーが該当する。ＩＤを用いることによって、モデルおよびタイプごとに一意にデータを特定できる。
【００３４】
以上に基づけば、ある特定のデータは、「モデル、タイプ、ＩＤ」の３属性を有する記述子によって特定される。また別の場合によっては、「スキーマ、モデル、タイプ、ＩＤ」の４属性を有する記述子によって特定されることもある。なお、Cena記述子を構成する属性については上記以外の属性が含まれていても良く、属性の数に制限はない。
【００３５】
たとえば、図４をCena記述子を用いて示す。テーブルcontactの各レコードをdao_contactというクラスで表している場合、そのモデルはdao_contactとなる。そしてデータはすでにシステムＢに存在しているのでタイプは「get」であり、プライマリーキーは「１０」となる。すなわち、Cena.dao_contact.get.10のCena記述子で示される。なお、以下の説明では、ＯＲＭを用いた場合で説明する。
【００３６】
データを一意に指定した次には、指定したデータに対して操作を行うことが可能となる。操作には、プロパティの設定、関係の設定、データそのものに対する操作などがある。つまり、データには属性としてプロパティが含まれている。たとえば、図４において、テーブルcontactは、nameをプロパティとして含んでいる。また、特殊な属性として関係（リレーション）がある。関係とは、ほかのデータを参照するもので、単なる値であるプロパティとは区別される。たとえば、図４において、テーブルconnectはプロパティとしてmethod（メソッド）を含み、リレーションとしてcontact_id='10'と関係している。このように、オブジェクト（データ）のCena記述子に操作内容や操作に必要なデータを追加して表現をする。
【００３７】
データを指定するCena記述子に操作内容（Action）を追加することもできる。たとえば、上述のcontact_id='10'を削除する場合、そのデータは、Cena.dao_contact.get.10によって指定される。このCena記述子に、削除の操作を示すAction='del'を追加する。すなわちCena記述子はCena.dao_contact.get.10.delとなる。
【００３８】
さらにデータを指定するCena記述子に操作内容（Action）と必要なプロパティ名を追加し、データを指定するCena記述子とすることもできる。たとえば、上述のcontact_id='10'の名前を変更する場合、そのデータは、Cena.dao_contact.get.10によって指定される。このCena記述子に、変更の操作を示すAction='set'とプロパティ（name）を追加し、新たな値、たとえば「特許 三郎」を指定する。そうするとCena記述子は、「Cena.dao_contact.get.10.set.name='特許 三郎'」となる。
【００３９】
さらにデータを指定するCena記述子に操作内容（Action）と必要なプロパティ名を追加し、参照するデータを表すCena記述子とすることもできる。たとえば、上述のconnect_id='20'の関係を変更する場合、そのデータは、Cena.dao_connect.get.20によって指定される。このCena記述子に、関係の変更の操作を示すAction='rel'とプロパティ（contact_id）を追加し、参照するデータのCena記述子、たとえばcontact_id='20'と関係することを指定する。そうするとCena記述子は、Cena.dao_connect.get.10.rel.contact_id=Cena.dao_contact.get.20となる。
【００４０】
すなわち、Cena記述子においては、従来はそのデータベースにおけるプライマリーキーのみ（あるいはＩＤのみ）によってデータを一意に特定していたのに対し、少なくともデータの種類を特定する文字列であるモデルと、データの種別を特定する文字列であるタイプと、データを一意に特定する値であるＩＤとを用いて特定することで、データの種別なども併せて当該Cena記述子のみからデータを一意に特定することができる。さらには、属性としてさまざまなものを指定できる。
【００４１】
以上のように定められるCena記述子にはいくつかの表記方法を用いることができる。たとえば文字列表記、配列表記、ＪＳＯＮ表記などがある。これを模式的に示すのが図８である。なお、Cena記述子としては、上記に限定されず、少なくともモデル、タイプ、ＩＤ、あるいはスキーマ、モデル、タイプ、ＩＤを含む属性から構成されれば、如何なる表現方法を採っても良い。文字列表記は、Cena記述子の各属性を文字列と「．」（ピリオド）で区切ることで表記する。配列表記は、Cena記述子の各属性を配列の各属性として代入することで表記する。ＪＳＯＮ表記（JavaScript Object Notation）に基づく表記である。
【００４２】
次に、上述のように構成されるCena記述子を用いて、本発明におけるデータ処理システム１の構成、処理を説明する。図１に、データ処理システム１の全体の構成の一例を模式的に示す。なおデータ処理システム１におけるデータ集合体としては、データベース、データファイル、音楽ファイル、映像ファイルなど如何なるものであっても良く、データの集合体であればよい。また、データ処理システム１は、図１では、それぞれにデータ集合体を備える２つのコンピュータ端末（システム３、システム２）の場合であって、一のコンピュータ端末から他方のコンピュータ端末にデータが転送されることで、そのデータが追加、反映される場合の処理を示しているが、これが一つのコンピュータ端末で実現されていても良い。
【００４３】
コンピュータ端末は、プログラムの演算処理を実行するＣＰＵなどの演算装置２０と、情報を記憶するＲＡＭやハードディスクなどの記憶装置２１と、ディスプレイ（画面）などの表示装置２２と、キーボードやポインティングデバイス（マウスやテンキーなど）などの入力装置２３と、演算装置２０の処理結果や記憶装置２１に記憶する情報をインターネットやＬＡＮなどのネットワークを介して送受信する通信装置２４とを有している。コンピュータ上で実現する各機能（各手段）は、その処理を実行する手段（プログラムやモジュールなど）が演算装置２０に読み込まれることでその処理が実行される。各機能は、記憶装置２１に記憶した情報をその処理において使用する場合には、該当する情報を当該記憶装置２１から読み出し、読み出した情報を適宜、演算装置２０における処理に用いる。図２にコンピュータ端末のハードウェア構成の一例を模式的に示す。また、コンピュータ端末は、複数のコンピュータまたはサーバに、その機能が分散配置されていても良い。
【００４４】
本発明における各手段は、その機能が論理的に区別されているのみであって、物理上あるいは事実上は同一の領域を為していても良い。
【００４５】
データ処理システム１には、少なくとも２以上のデータ集合体と、そのデータ集合体に対する処理を実行する各種の処理部とを有する。
【００４６】
データ集合体は、上述のようにデータの集合体である。なお本明細書の以下の説明ではデータ集合体としてデータベースの場合を説明するが、それに限るものではなく、同様に処理を実現することができる。
【００４７】
データ処理システムにおける処理部は、データ集合体におけるデータについて、データの関係性を維持したまま、他のデータ集合体に反映させる処理を実現する。処理部としては、データ取得部１１とオブジェクト生成部１２と参照関係処理部１３と保存処理部１４と関係更新部１５とを有する。
【００４８】
データ取得部１１は、ほかのデータ集合体からCena記述子によるデータを取得する。たとえば図１の場合、第２のデータ集合体２Ｄ（データベースＢ）から、第１のデータ集合体３Ｄ（データベースＡ）に反映させるデータを取得する。ここで取得するデータは、上述のCena記述子で記述されている。
【００４９】
オブジェクト生成部１２は、データ取得部１１で取得したデータに基づいて、オブジェクトを生成する。オブジェクトを生成するには、Cena記述子を構成する属性を抽出し、抽出した属性を、それぞれオブジェクトの属性とすることで生成する。
【００５０】
参照関係処理部１３は、生成したオブジェクトが２以上ある場合に、それらの参照関係があるかを判定する。すなわち、オブジェクト生成部１２で生成したオブジェクトにおける、参照関係を示す属性に基づき、オブジェクト同士の参照関係を判定する。
【００５１】
そして参照関係処理部１３は、参照関係があることを判定すると、それぞれを関係づけて、関係づけたオブジェクトについて、そのタイプが、データの反映先で生成されたことを示すもの（たとえば「get」）であるかを判定する。
【００５２】
保存処理部１４は、参照関係処理部１３で生成したオブジェクトを、データ集合体（データベース）に保存する。オブジェクトを保存する際には、そのオブジェクトを示すCena記述子のうち、先頭から所定数（たとえば先頭から３あるいは４など）の属性を抽出し、それをオブジェクト名とし、オブジェクト名と属性とを対応づけて第１のデータ集合体３Ｄに保存する。またこの際に、オブジェクトの属性を更新して保存することとなる。また保存したオブジェクトの属性におけるタイプを、「get」にして更新する。ここで、タイプが「get」になるのは、当該オブジェクトが第２のデータ集合体を備えるシステム２から取得したからである。すなわち、もともとシステム３のオブジェクトではないため、「get」に更新して保存する。
【００５３】
関係更新部１５は、保存処理部１４がデータ集合体で保存処理を実行後、データ集合体での関係を表すことが可能となるので、関係更新部１５は、関係性があるオブジェクトから、保存されたオブジェクトにおけるＩＤを読み込み、それを、関係づけられているレコードに反映して記憶させる。
【００５４】
次に、本発明のデータ処理システム１の処理を図３のフローチャートを用いて説明する。以下の説明では、サーバであるシステム２のデータベース（データベースＢ）からデータをシステム３に転送し、システム３のデータベース（データベースＡ）で登録する場合を説明する。
【００５５】
まずシステム２で、図９に示すデータの登録画面からデータの入力が行われることで、データベースＢにデータが追加されたとする。この追加されたデータについて、上述のCena記述子を用いると図１０に示すようになる。
【００５６】
つまり、名前として「特許 三郎」、性別として「男性」、分類として「仕事」、日付として「２０１１−０１−０１」を入力すると、それがテーブルcontactのレコード（クラス）dao_contactのプライマリーキー「１０」に対応づけて記憶される。また、連絡方法として「Facebook」、参照データ（関連づけるデータ）として「Cena.dao_contact.new.10」、分類として「ＴＥＬ」を入力すると、それが、テーブルconnectのレコード（クラス）dao_connectのプライマリーキー「１１」に対応づけて記憶される。そしてこれらに基づいて、Cena記述子に変換される。なお、データに対する属性の入力の代わりに、プルダウンメニューなどで選択入力可能としても良い。特に参照データについては、関連づける相手先のレコードやプライマリーキーなどに基づいて、自動的に入力されるようにしてもよい。これによって入力ミスなどを防止することができる。
【００５７】
具体的には、テーブルcontactのレコードdao_contactにおけるCena記述子Cena.dao_contact.new.10に対して、属性、つまり名前「特許 三郎」、性別「男性」、分類「仕事」および日付が「２０１１年１月１日」を対応付けてデータベースＢに記憶する。また、テーブルconnectのレコードdao_connectにおけるCena記述子Cena.dao_connect.new.11に対して、属性、つまり連絡方法「Facebook」、その参照データ「Cena.dao_contact.new.10」および分類「ＴＥＬ」を対応づけてデータベースＢに記憶する。なお、図１０では説明の便宜上、当該Cena記述子に対しては名前のみを示しており、それ以外は図から省略しているが、以下の処理でも名前の場合と同様に処理可能である。
【００５８】
また、上述では２つのレコードから２つのオブジェクトの場合を示したが、レコードを自己参照して、１つのレコードから２つのオブジェクトを生成する場合もある。
【００５９】
以上のようにしてシステム２で生成したCena記述子によるデータについて、所定の操作をすることで、システム３に転送する。
【００６０】
このようにして転送されたデータ（Cena記述子で記述されるデータ）を、システム３のデータ処理システム１のデータ取得部１１で取得する（Ｓ１００）。
【００６１】
データ取得部１１で取得したデータ（Cena記述子で記述されるデータ）に基づいて、データ処理システム１のオブジェクト生成部１２は、オブジェクトを生成する（Ｓ１１０）。これはデータ取得部１１で取得した、Cena記述子での記述のうち、スキーマ、モデル、タイプ、ＩＤの最初の４属性に基づいて、オブジェクトを生成する。すなわち、先頭のスキーマの文字列によって、Cena記述子で記述されていることを特定することで、２番目の属性をモデル、３番目の属性をタイプ、４番目の属性をＩＤとして特定できるので、それに基づきオブジェクトの属性を生成する。またそれ以外の部分についてはオブジェクトの属性を生成する。
【００６２】
すなわち、Cena.dao_contact.new.10では、先頭の属性の文字列によりCena記述子であることを特定できるので、２番目の属性がモデル、つまりデータの種別（データベースの場合にはテーブル名）を特定し、３番目の属性がタイプ、つまりデータの種別（新たに追加されたデータ（new）か、システム３で作成されたデータ（get）か）を特定し、４番目の属性がＩＤ、つまりデータを一意に特定する値であることを特定し、それぞれをオブジェクトの属性とする。また、さらに、それ５番目以降の属性については、それぞれを値としてオブジェクトの属性とする。
【００６３】
このようにシステム３から取得したデータのうち、先頭から所定数（たとえば４番目）の属性に基づいてオブジェクトを生成する。なお先頭にスキーマを用いない場合（つねにCena記述子を用いることが特定されている場合など）では、スキーマを用いずに自動的にオブジェクト生成部１２がオブジェクトを生成する。図１０に基づく２つのオブジェクトが図１１である。２つのオブジェクトとなるのは、モデルが２つ、すなわちデータベースのテーブルが２つだからである。
【００６４】
Ｓ１１０において、オブジェクト生成部１２がオブジェクトを生成すると、参照関係処理部１３が、生成したオブジェクト間における参照関係が存在するかを判定する。すなわち、オブジェクトの各属性を参照し、参照関係があるかを判定する（Ｓ１２０）。
【００６５】
参照関係がなければＳ１６０以降の処理を実行する。一方、参照関係がある場合には、Ｓ１３０以降の処理を実行する。
【００６６】
図１１の場合、オブジェクトCena.dao_connect.new.11では、オブジェクトCena.dao_contact.new.10を参照している（rel.contact_id=Cena.dao_contact.new.10）。従って、参照関係処理部１３は、参照関係があると判定できる。これを模式的に示すのが図１２である。
【００６７】
参照関係処理部１３で参照関係があることを判定すると、参照関係処理部１３は，参照関係があると判定したオブジェクトについて、それぞれを関係づける（Ｓ１３０）。そして関係づけることによって、システム３において、図１３に示すような画面を表示装置２２で表示し、これを反映することの入力を受け付ける。図１３では、ＩＤを表示しているが、表示しないように構成することもできる。また、上述の関係づけはいわゆるデータ間の紐付けで行われればよい。
【００６８】
また、参照関係処理部１３で参照関係がないと判定した場合にも、対応する画面を表示する表示装置２２で表示をし、それを反映することの入力を受け付けてもよいし、受け付けずにそのまま処理を行っても良い。
【００６９】
そしてＳ１３０でオブジェクトの関係づけを参照関係処理部１３が行うと、参照関係処理部１３が、関係づけられるオブジェクトのタイプが「get」（データの反映先であるシステム３以外のシステムで作成されたデータであることを示すタイプ）であるかを判定する（Ｓ１４０）。なおタイプとしては「get」のほかに、「new」があり、これは、データの反映先であるシステム３で作成されたデータであることを示すタイプである。つまり、Ｓ１４０では、反映先のシステムで作成したデータであるかを判定している。
【００７０】
タイプが「get」である場合には、システム３で作成したデータではないので、そのオブジェクトのＩＤを取得する。ここでは、ＩＤとして、オブジェクトCena.dao_contact.new.10については「１０」を、オブジェクトCena.dao_connect.new.11については「１１」を取得することとなる（Ｓ１５０）。なお、タイプが「new」である場合には、システム３で作成したデータなので、Ｓ１６０以降の処理を実行する。
【００７１】
Ｓ１５０までの処理が終了後、すなわち、Ｓ１１０でオブジェクト生成部１２で生成したオブジェクトおよびＳ１３０で関係づけたオブジェクト間の関係の作成が完了したら、オブジェクト生成部１２で生成したオブジェクトを、保存処理部１４が、システム３のデータベースＡに保存する（Ｓ１６０）。これによって、オブジェクトにおけるプライマリーキー（ＩＤ）などの属性もデータベースＡに反映されることとなる。
【００７２】
なお、Ｓ１６０で保存する場合には、そのオブジェクトを示すCena記述子のうち、先頭から所定数（たとえば先頭から３あるいは４など）の属性を抽出し、それをオブジェクト名とし、オブジェクト名と属性とを対応づけて保存する。また、オブジェクトの属性を更新して保存する。この場合、システム３は、システム２から受け取ったデータを保存したので、タイプは「get」となる。これを模式的に示すのが図１４である。なお、図１４では、テーブルcontactでは、すでにＩＤの「１０」が使われており、「１５」が割り当てられたとする。
【００７３】
図１４の場合、図１０に示すCena記述子に基づいてオブジェクトが生成されている。すなわち、図１０に示すCena記述子の場合、先頭から４属性までをオブジェクト名とするので、「Cena.dao_contact.new.10」がオブジェクト名となる。そして各Cena記述子に基づいて、オブジェクト名に対応づけてそれぞれ当該オブジェクトの属性が保存されることとなる。
【００７４】
このように、Ｓ１６０における保存の処理によって、オブジェクト内部の属性は変更されうるが、同じオブジェクトとして認識されるため、オブジェクト間の関係には影響がない。つまり、図１４では、テーブルdao_contactにおいて、contact_idとして「１０」がすでに使用されていることから、保存の際には、自動的に「１５」が割り当てられた。これによってオブジェクトCena.dao_contact.new.10の内部の属性のＩＤは変わったが、オブジェクトを表すCena記述子そのものは変更がなく、オブジェクト間の関係も保持されたままとなる。
【００７５】
またＳ１６０で関係を保存する際に、相手のオブジェクトのタイプを確認することもできる。もしタイプが「get」であれば、当該オブジェクトのＩＤは反映先のデータベースでのプライマリーキー（ＩＤ）と一致する。そこでオブジェクトが保存される前にＩＤを取得しておき、関係をデータベース上に保存することが可能である。また、タイプが「new」の場合には、ＩＤが変更される場合があるため、関係先のオブジェクトが保存された後のＩＤを用いる。
【００７６】
以上のようにして、Ｓ１２０で判定した、オブジェクトのすべての関係性について、その関係性を保存したかを判定し（Ｓ１７０）、すべての関係が保存された場合にはその処理を終了する。一方、そうでない場合には、Ｓ１８０以降の処理を実行する。すなわちデータ処理システム１は、関係更新部１５において、関係更新処理を実行する（Ｓ１８０）。
【００７７】
すなわち、保存処理部１４がデータベースＡに保存処理を実行後、データベースＡ上での関係を表すことが可能となる。従って、関係更新部１５は、関係しているオブジェクトから保存されたオブジェクトにおけるＩＤ（プライマリーキー）を読み込み（Ｓ１８０)、Cena記述子におけるタイプに基づくレコード上に保存する（Ｓ１９０）。
【００７８】
上述の例の場合、オブジェクトCena.dao_connect.new.11に関係するオブジェクトCena.dao_contact.new.10が保存される際に、当該オブジェクトに割り当てられる最終的なＩＤ（プライマリーキー）が「１５」で割り当てられているので、割り当てられたＩＤ「１５」を関係更新部１５が読み込む（Ｓ１８０）。そして、オブジェクトCena.dao_connect.new.11のcontact_idを、読み込んだ「１５」として決定してその関係を保存する（Ｓ１９０）。これを模式的に示すのが図１５である。またこの関係性が反映されてデータが保存された結果を示す画面の一例が図１６である。
【００７９】
以上のような処理を実行することで、２つのデータベースにおいて、データの追加・変更等がある場合にも、フラグを用いずにデータ間の連携を保持することが可能となる。
【００８０】
また、オブジェクトとして、配列または連想配列を用いて上述の処理と同様の処理を実行することが可能となる。すなわち、配列に反映するデータを保存し、Cena記述子で配列を読み込めば良い。
【００８１】
まず転送の対象となるデータから配列を生成する。この配列は、上述のCena記述子を用いて配列の参照が行われるようにする。次に、各レコード間の関係がCena記述子を用いて表されているので、Cena記述子から関係する配列を求め、配列間の関係として表す。そして、必要な配列および配列間の関係の生成が完了後、配列を実際のデータベースに保存する。保存したら、配列のデータを、保存された内容に更新する。またデータが、転送を受け取ったシステム（ここではシステム３）に保存されたことから、タイプが「get」に更新される。保存の処理が終了後、データベースでの関係を表すことが可能となるので、関係している配列から、保存されたＩＤ（プライマリーキー）を読み込み、関係づけて自身のレコード上に保存する。
【００８２】
以上のような処理を実行することで、配列または連想配列を用いた場合でも処理が実現可能となる。
【００８３】
また本発明のデータ処理システム１で用いるCena記述子を用いて関係を表す場合、その関係性を簡単に保持することが可能となる。以下にこの点について説明する。なお、以下の処理は、上述の図３のフローチャートと同様の部分もある。
【００８４】
上述と同様に、システム２で追加されたデータを、システム３で登録する場合を説明する。従って、システム２からシステム３には、たとえば図１７に示すデータが送られる。図１７の場合、テーブルdao_contactにプライマリーキー「１０」のレコードとして「特許 三郎」が追加され、テーブルdao_connectにプライマリーキー「１１」のレコードとしてFacebook、当該レコードが、テーブルdao_contactにプライマリーキー「１０」のレコードと関係づけられている場合を示している。
【００８５】
システム３で、システム２から図１７のデータを取得すると、それをデータベースＡに保存する。またデータベースＡでは、すでにＩＤ「１０」が使用されている場合、使用されていないＩＤ、たとえば「１５」が割り当てられる。
【００８６】
また、オブジェクトをデータベースＡに保存することで、タイプは「get」に代わり、テーブルcontactのＩＤは「１５」で保存される。これを模式的に示すのが図１８である。
【００８７】
そしてデータベースＡへの保存前と保存後のCena記述子の関係を作成する。図１８の場合、図１９のようになる。そしてデータベースＡの保存前と保存後との関係から、保存前のCena記述子を、保存後のCena記述子に変換する。
【００８８】
上述の例では、テーブルdao_contactにおいて、ＩＤが「contact_id=15」に変更されたことから、テーブルdao_connectでその関係性の変換が行われる。すなわち、Cena.dao_contact.new.10がCena.dao_contact.get.15に変換される。これを模式的に示すのが図２０である。
【００８９】
このようにCena記述子は、すべてのデータ（システム上に存在するデータおよび新たに登録するデータ）を一意に指定している。つまり、Cena記述子自体も一意の文字列であるため、単純なテキストの変換を行うことで、それらの関係性を更新することができる。これは、データベースに保存する際に、Cena記述子からＩＤ（データベースの場合にはプライマリーキー）を取得することで抜き出す。
【００９０】
また、システム３とシステム２とで同期を取る場合には、Cena記述子の変更履歴を用いて、反映元（システム２）のデータベースと転送を受け取った側のデータベースを同期することが可能である。以上の処理で得られた変更履歴を転送元のシステム（システム２）へ転送し、転送元のシステム（システム２）では、その変更履歴を用いて、データベース上のＩＤ（データベースの場合、プライマリーキー）および関係を更新することが可能となる。
【産業上の利用可能性】
【００９１】
上述したデータ処理システム１によって、あるデータ集合体から、別のデータ集合体にデータを反映する場合に、データの関係性に変更があったとしても、フラグを用いずにデータ間の連携を維持することが可能となる。
【符号の説明】
【００９２】
１：データ処理システム
２：システム
２Ｄ：第２のデータ集合体
３：システム
３Ｄ：第１のデータ集合体
１１：データ取得部
１２：オブジェクト生成部
１３：参照関係処理部
１４：保存処理部
１５：関係更新部
２０：演算装置
２１：記憶装置
２２：表示装置
２３：入力装置
２４：通信装置
３１：第１のデータ集合体
３２：第２のデータ集合体
【特許請求の範囲】
【請求項１】
第２のデータ集合体に登録されたデータを第１のデータ集合体に反映させるデータ処理システムであって、
前記データ処理システムは、
前記第２のデータ集合体に登録されたデータに基づいて生成された、少なくともモデルとタイプとＩＤとを属性として含む記述子で記述されたデータを取得するデータ取得部と、
前記データ取得部で取得したデータの記述子における所定の属性をオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成するオブジェクト生成部と、
前記生成したオブジェクトが２以上ある場合に、それらの参照関係を前記内部属性に基づいて判定する参照関係処理部と、
前記生成したオブジェクトを前記第１のデータ集合体に保存する保存処理部と、
前記参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるＩＤを抽出し、参照側となるオブジェクトの参照を示す内部属性を前記抽出したＩＤで更新する関係更新部と、
を有することを特徴とするデータ処理システム。
【請求項２】
前記オブジェクト生成部は、
前記記述子における、少なくともモデルとタイプとＩＤとをオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成する、
ことを特徴とする請求項１に記載のデータ処理システム。
【請求項３】
前記オブジェクト生成部は、
前記記述子における、少なくともモデルとタイプとＩＤとをオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成し、
前記保存処理部は、
前記生成したオブジェクトの保存の際に、前記第１のデータ集合体において、前記記述子におけるＩＤの属性と同一のＩＤが使用されている場合には、前記ＩＤとは異なるＩＤを割り当て、
前記生成したオブジェクトの内部属性におけるＩＤを、前記割り当てたＩＤで更新した上で、前記オブジェクトを前記第１のデータ集合体に保存する、
ことを特徴とする請求項１または請求項２に記載のデータ処理システム。
【請求項４】
データ集合体に登録されたデータをほかのデータ集合体に渡すことで反映させるコンピュータシステムであって、
前記データ集合体に登録されたデータのうち、前記ほかのデータ集合体に送るデータを抽出し、
少なくとも、データの種別を特定する文字列であるモデルと、データを受け入れるシステムで既存のデータかどうかの種別を表すタイプと、データを一意に特定するための値であるＩＤとを少なくとも含む記述子によって、前記抽出したデータを生成し、
前記記述子によって記述されたデータを、前記ほかのデータ集合体を備えるコンピュータシステムに送り、前記記述子における属性に従ってオブジェクトを生成させることで、前記ほかのデータ集合体に登録させる、
ことを特徴とするコンピュータシステム。
【請求項５】
第２のデータ集合体に登録されたデータを第１のデータ集合体に反映させるコンピュータ端末を、
前記第２のデータ集合体に登録されたデータに基づいて生成された、少なくともモデルとタイプとＩＤとを属性として含む記述子で記述されたデータを取得するデータ取得部、
前記データ取得部で取得したデータの記述子における所定の属性をオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成するオブジェクト生成部、
前記生成したオブジェクトが２以上ある場合に、それらの参照関係を前記内部属性に基づいて判定する参照関係処理部、
前記生成したオブジェクトを前記第１のデータ集合体に保存する保存処理部、
前記参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるＩＤを抽出し、参照側となるオブジェクトの参照を示す内部属性を前記抽出したＩＤで更新する関係更新部、
として機能させることを特徴とするデータ処理プログラム。
【請求項１】
第２のデータ集合体に登録されたデータを第１のデータ集合体に反映させるデータ処理システムであって、
前記データ処理システムは、
前記第２のデータ集合体に登録されたデータに基づいて生成された、少なくともモデルとタイプとＩＤとを属性として含む記述子で記述されたデータを取得するデータ取得部と、
前記データ取得部で取得したデータの記述子における所定の属性をオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成するオブジェクト生成部と、
前記生成したオブジェクトが２以上ある場合に、それらの参照関係を前記内部属性に基づいて判定する参照関係処理部と、
前記生成したオブジェクトを前記第１のデータ集合体に保存する保存処理部と、
前記参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるＩＤを抽出し、参照側となるオブジェクトの参照を示す内部属性を前記抽出したＩＤで更新する関係更新部と、
を有することを特徴とするデータ処理システム。
【請求項２】
前記オブジェクト生成部は、
前記記述子における、少なくともモデルとタイプとＩＤとをオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成する、
ことを特徴とする請求項１に記載のデータ処理システム。
【請求項３】
前記オブジェクト生成部は、
前記記述子における、少なくともモデルとタイプとＩＤとをオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成し、
前記保存処理部は、
前記生成したオブジェクトの保存の際に、前記第１のデータ集合体において、前記記述子におけるＩＤの属性と同一のＩＤが使用されている場合には、前記ＩＤとは異なるＩＤを割り当て、
前記生成したオブジェクトの内部属性におけるＩＤを、前記割り当てたＩＤで更新した上で、前記オブジェクトを前記第１のデータ集合体に保存する、
ことを特徴とする請求項１または請求項２に記載のデータ処理システム。
【請求項４】
データ集合体に登録されたデータをほかのデータ集合体に渡すことで反映させるコンピュータシステムであって、
前記データ集合体に登録されたデータのうち、前記ほかのデータ集合体に送るデータを抽出し、
少なくとも、データの種別を特定する文字列であるモデルと、データを受け入れるシステムで既存のデータかどうかの種別を表すタイプと、データを一意に特定するための値であるＩＤとを少なくとも含む記述子によって、前記抽出したデータを生成し、
前記記述子によって記述されたデータを、前記ほかのデータ集合体を備えるコンピュータシステムに送り、前記記述子における属性に従ってオブジェクトを生成させることで、前記ほかのデータ集合体に登録させる、
ことを特徴とするコンピュータシステム。
【請求項５】
第２のデータ集合体に登録されたデータを第１のデータ集合体に反映させるコンピュータ端末を、
前記第２のデータ集合体に登録されたデータに基づいて生成された、少なくともモデルとタイプとＩＤとを属性として含む記述子で記述されたデータを取得するデータ取得部、
前記データ取得部で取得したデータの記述子における所定の属性をオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成するオブジェクト生成部、
前記生成したオブジェクトが２以上ある場合に、それらの参照関係を前記内部属性に基づいて判定する参照関係処理部、
前記生成したオブジェクトを前記第１のデータ集合体に保存する保存処理部、
前記参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるＩＤを抽出し、参照側となるオブジェクトの参照を示す内部属性を前記抽出したＩＤで更新する関係更新部、
として機能させることを特徴とするデータ処理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２０１２−１６４２４７（Ｐ２０１２−１６４２４７Ａ）
【公開日】平成２４年８月３０日（２０１２．８．３０）
【国際特許分類】
【出願番号】特願２０１１−２５６４１（Ｐ２０１１−２５６４１）
【出願日】平成２３年２月９日（２０１１．２．９）
【特許番号】特許第４７８２８９５号（Ｐ４７８２８９５）
【特許公報発行日】平成２３年９月２８日（２０１１．９．２８）
【出願人】（５１１０３５５４６）
【Ｆターム（参考）】
【公開日】平成２４年８月３０日（２０１２．８．３０）
【国際特許分類】
【出願日】平成２３年２月９日（２０１１．２．９）
【特許番号】特許第４７８２８９５号（Ｐ４７８２８９５）
【特許公報発行日】平成２３年９月２８日（２０１１．９．２８）
【出願人】（５１１０３５５４６）
【Ｆターム（参考）】
[ Back to top ]