"第2のデータ集合体に登録されたデータを第1のデータ集合体に反映させるデータ処理システムであって、前記データ処理システムは、前記第2のデータ集合体に登録されたデータに基づいて生成された、少なくともモデルとタイプとIDとを属性として含む記述子で記述されたデータを取得するデータ取得部と、前記データ取得部で取得したデータの記述子における所定の属性をオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成するオブジェクト生成部と、前記生成したオブジェクトが2以上ある場合に、それらの参照関係を前記内部属性に基づいて判定する参照関係処理部と、前記生成したオブジェクトを前記第1のデータ集合体に保存する保存処理部と、前記参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるIDを抽出し、参照側となるオブジェクトの参照を示す内部属性を前記抽出したIDで更新する関係更新部と、を有することを特徴とするデータ処理システム。前記オブジェクト生成部は、前記記述子における、少なくともモデルとタイプとIDとをオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成する、ことを特徴とする請求項1に記載のデータ処理システム。前記オブジェクト生成部は、前記記述子における、少なくともモデルとタイプとIDとをオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成し、前記保存処理部は、前記生成したオブジェクトの保存の際に、前記第1のデータ集合体において、前記記述子におけるIDの属性と同一のIDが使用されている場合には、前記IDとは異なるIDを割り当て、前記生成したオブジェクトの内部属性におけるIDを、前記割り当てたIDで更新した上で、前記オブジェクトを前記第1のデータ集合体に保存する、ことを特徴とする請求項1または請求項2に記載のデータ処理システム。データ集合体に登録されたデータをほかのデータ集合体に渡すことで反映させるコンピュータシステムであって、前記データ集合体に登録されたデータのうち、前記ほかのデータ集合体に送るデータを抽出し、少なくとも、データの種別を特定する文字列であるモデルと、データを受け入れるシステムで既存のデータかどうかの種別を表すタイプと、データを一意に特定するための値であるIDとを少なくとも含む記述子によって、前記抽出したデータを生成し、前記記述子によって記述されたデータを、前記ほかのデータ集合体を備えるコンピュータシステムに送り、前記記述子における属性に従ってオブジェクトを生成させることで、前記ほかのデータ集合体に登録させる、ことを特徴とするコンピュータシステム。第2のデータ集合体に登録されたデータを第1のデータ集合体に反映させるコンピュータ端末を、前記第2のデータ集合体に登録されたデータに基づいて生成された、少なくともモデルとタイプとIDとを属性として含む記述子で記述されたデータを取得するデータ取得部、前記データ取得部で取得したデータの記述子における所定の属性をオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成するオブジェクト生成部、前記生成したオブジェクトが2以上ある場合に、それらの参照関係を前記内部属性に基づいて判定する参照関係処理部、前記生成したオブジェクトを前記第1のデータ集合体に保存する保存処理部、前記参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるIDを抽出し、参照側となるオブジェクトの参照を示す内部属性を前記抽出したIDで更新する関係更新部、として機能させることを特徴とするデータ処理プログラム。しかしながら上記特許文献1によれば、ステータスフラグを用いて処理を行わなければならず、不要なデータが増えてしまう。レコードが1つであればフラグが増えても問題がないが、大量のレコードとなった場合にはそれだけでもデータ量の増加を招いてしまう。また、ステータスフラグを用いずに変換テーブルを用いる方法もあり得るが、この場合には、別途、変換テーブルを作成、管理する必要がある。本発明者は上記技術的課題に鑑み、本願発明におけるデータ処理システムを発明した。第1の発明は、第2のデータ集合体に登録されたデータを第1のデータ集合体に反映させるデータ処理システムであって、前記データ処理システムは、前記第2のデータ集合体に登録されたデータに基づいて生成された、少なくともモデルとタイプとIDとを属性として含む記述子で記述されたデータを取得するデータ取得部と、前記データ取得部で取得したデータの記述子における所定の属性をオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成するオブジェクト生成部と、前記生成したオブジェクトが2以上ある場合に、それらの参照関係を前記内部属性に基づいて判定する参照関係処理部と、前記生成したオブジェクトを前記第1のデータ集合体に保存する保存処理部と、前記参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるIDを抽出し、参照側となるオブジェクトの参照を示す内部属性を前記抽出したIDで更新する関係更新部と、を有するデータ処理システムである。本発明のように構成することで、仮に被参照側となるデータのプライマリーキーなどの識別情報IDが変更されたとしても、その内部属性は変わるが、その関係性を判定するオブジェクト名自体は変更されないので、それぞれの関係性を維持することが可能となる。上述の発明において、前記オブジェクト生成部は、前記記述子における、少なくともモデルとタイプとIDとをオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成する、データ処理システムのように構成することもできる。オブジェクト名としては、少なくともモデルとタイプとIDとを含むことが好ましい。また上述の発明において、前記オブジェクト生成部は、前記記述子における、少なくともモデルとタイプとIDとをオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成し、前記保存処理部は、前記生成したオブジェクトの保存の際に、前記第1のデータ集合体において、前記記述子におけるIDの属性と同一のIDが使用されている場合には、前記IDとは異なるIDを割り当て、前記生成したオブジェクトの内部属性におけるIDを、前記割り当てたIDで更新した上で、前記オブジェクトを前記第1のデータ集合体に保存する、データ処理システムのように構成することもできる。上述の技術的効果を達成するために、本発明のように構成することもできる。第2の発明は、データ集合体に登録されたデータをほかのデータ集合体に渡すことで反映させるコンピュータシステムであって、前記データ集合体に登録されたデータのうち、前記ほかのデータ集合体に送るデータを抽出し、少なくとも、データの種別を特定する文字列であるモデルと、データを受け入れるシステムで既存のデータかどうかの種別を表すタイプと、データを一意に特定するための値であるIDとを少なくとも含む記述子によって、前記抽出したデータを生成し、前記記述子によって記述されたデータを、前記ほかのデータ集合体を備えるコンピュータシステムに送り、前記記述子における属性に従ってオブジェクトを生成させることで、前記ほかのデータ集合体に登録させる、コンピュータシステムである。本発明のように構成しても第1の発明と同様の技術的効果を得ることができる。本発明のプログラムをコンピュータ端末で読み込み、実行することで、上述のデータ処理システムを実現することができる。すなわち、第2のデータ集合体に登録されたデータを第1のデータ集合体に反映させるコンピュータ端末を、前記第2のデータ集合体に登録されたデータに基づいて生成された、少なくともモデルとタイプとIDとを属性として含む記述子で記述されたデータを取得するデータ取得部、前記データ取得部で取得したデータの記述子における所定の属性をオブジェクト名として抽出し、前記記述子における属性をオブジェクトの内部属性とし、前記オブジェクト名と前記内部属性とを対応づけることでオブジェクトを生成するオブジェクト生成部、前記生成したオブジェクトが2以上ある場合に、それらの参照関係を前記内部属性に基づいて判定する参照関係処理部、前記生成したオブジェクトを前記第1のデータ集合体に保存する保存処理部、前記参照関係処理部で判定した参照関係に基づいて、被参照側となるオブジェクトの内部属性におけるIDを抽出し、参照側となるオブジェクトの参照を示す内部属性を前記抽出したIDで更新する関係更新部、として機能させるデータ処理プログラムのように構成することもできる。本発明のデータ処理システムを用いることによって、あるデータ集合体から、別のデータ集合体にデータを反映する場合に、データ相互間の関係性に変更があったとしても、フラグを用いずにデータ間の関係性を維持することが可能となる。本発明のデータ処理システム1の説明をするにあたり、本明細書における用語を定義する。本発明のデータ処理システム1で処理対象とする情報をデータとする。ここでデータとは、データ処理システム1における何らかの資源、たとえばデータベースのレコードやファイルなどを意味する。つまり本発明のデータ処理システム1を用いることで操作する対象である。データベースのデータの一例を、図7に示す。図7aでは、データベースのテーブルcontact、connectの定義を示し、その定義を備えたレコードが図7bである。本発明のデータ処理システム1では、データへの操作を簡便に行うため、データを表すオブジェクトを生成し、処理を実行する。ここでオブジェクトとは、関係するデータを一つの塊と捉え、さらにデータに関係する処理を一緒に示すものであって、メモリ上のスペースが取られているデータである。たとえばJavaScriptにおける配列などもオブジェクトとして定義される。そしてオブジェクトによってデータベースの各レコードが表現されるのがORMObjectRelationMappingである。ORMにおいては、オブジェクトには属性が存在し、データベースのレコードの各項目に対応する。また、オブジェクトから別のオブジェクトへの参照を可能とすることで、リレーショナルデータベースの関係を、オブジェクト間の参照とすることができる。また本発明のデータ処理システム1では、上述のデータを操作するため、データを一意に表現する記述子を用いる。この記述子を本明細書ではCena記述子と呼ぶ。Cena記述子には少なくともモデルModel、タイプType、IDの各属性を備えており、さらに属性としてスキーマSchemaを備えていても良い。すなわち、Cena記述子は、モデル、タイプ、ID、あるいはスキーマ、モデル、タイプ、IDを含んでいる。スキーマとは、記述子の記述方法あるいはデータの参照方法を指定する文字列である。記述子の記述方法あるいはデータの参照方法があらかじめ定まっている場合には、省略することが可能である。たとえばスキーマとしてRdbが指摘された場合には、Rdbリレーショナルデータベースの参照方法であることを示す。またCenaとあった場合には、本発明のデータ処理システム1で用いる記述子に基づく参照方法であることを示す。従って、スキーマは、いわば、プロトコルの種別を指定するので、任意に設定可能である。モデルとは、データの種別を特定する文字列である。オブジェクトのインスタンスとして表すのに必要なクラス名、データベースのテーブル名、DIDependencyInjectionを用いる場合のモデル名称などがある。たとえば、モデルが一番単純なデータベースのテーブル名を表すとした場合、objectSqltableとなる。また、モデルがクラス名を表し、各オブジェクトを生成する場合には、objectnewModel;となる。また、モデルをfactoryと呼ばれるメソッドから作成する場合には、objectModelfactoryとなる。さらに、別のオブジェクトからオブジェクトを生成する場合には、objectDlfactoryとなる。このように、モデルは必ずしもテーブル名やクラス名ではないが、オブジェクトデータの種別を特定するための文字列となる。タイプとは、データを受け入れたシステムで既存のデータかどうかの判断種別を示す文字列である。たとえばサーバ図1のシステム2上のデータをgetとし、クライアント図1のシステム3で作成されたデータにはnewを記述する。IDとは、データを一意に特定するための値であり、データベースであればプライマリーキーが該当する。IDを用いることによって、モデルおよびタイプごとに一意にデータを特定できる。以上に基づけば、ある特定のデータは、モデル、タイプ、IDの3属性を有する記述子によって特定される。また別の場合によっては、スキーマ、モデル、タイプ、IDの4属性を有する記述子によって特定されることもある。なお、Cena記述子を構成する属性については上記以外の属性が含まれていても良く、属性の数に制限はない。たとえば、図4をCena記述子を用いて示す。テーブルcontactの各レコードをdaocontactというクラスで表している場合、そのモデルはdaocontactとなる。そしてデータはすでにシステムBに存在しているのでタイプはgetであり、プライマリーキーは10となる。すなわち、Cenadaocontactget10のCena記述子で示される。なお、以下の説明では、ORMを用いた場合で説明する。データを一意に指定した次には、指定したデータに対して操作を行うことが可能となる。操作には、プロパティの設定、関係の設定、データそのものに対する操作などがある。つまり、データには属性としてプロパティが含まれている。たとえば、図4において、テーブルcontactは、nameをプロパティとして含んでいる。また、特殊な属性として関係リレーションがある。関係とは、ほかのデータを参照するもので、単なる値であるプロパティとは区別される。たとえば、図4において、テーブルconnectはプロパティとしてmethodメソッドを含み、リレーションとしてcontactid10と関係している。このように、オブジェクトデータのCena記述子に操作内容や操作に必要なデータを追加して表現をする。データを指定するCena記述子に操作内容Actionを追加することもできる。たとえば、上述のcontactid10を削除する場合、そのデータは、Cenadaocontactget10によって指定される。このCena記述子に、削除の操作を示すActiondelを追加する。すなわちCena記述子はCenadaocontactget10delとなる。さらにデータを指定するCena記述子に操作内容Actionと必要なプロパティ名を追加し、データを指定するCena記述子とすることもできる。たとえば、上述のcontactid10の名前を変更する場合、そのデータは、Cenadaocontactget10によって指定される。このCena記述子に、変更の操作を示すActionsetとプロパティnameを追加し、新たな値、たとえば特許三郎を指定する。そうするとCena記述子は、Cenadaocontactget10setname特許三郎となる。さらにデータを指定するCena記述子に操作内容Actionと必要なプロパティ名を追加し、参照するデータを表すCena記述子とすることもできる。たとえば、上述のconnectid20の関係を変更する場合、そのデータは、Cenadaoconnectget20によって指定される。このCena記述子に、関係の変更の操作を示すActionrelとプロパティcontactidを追加し、参照するデータのCena記述子、たとえばcontactid20と関係することを指定する。そうするとCena記述子は、Cenadaoconnectget10relcontactidCenadaocontactget20となる。すなわち、Cena記述子においては、従来はそのデータベースにおけるプライマリーキーのみあるいはIDのみによってデータを一意に特定していたのに対し、少なくともデータの種類を特定する文字列であるモデルと、データの種別を特定する文字列であるタイプと、データを一意に特定する値であるIDとを用いて特定することで、データの種別なども併せて当該Cena記述子のみからデータを一意に特定することができる。さらには、属性としてさまざまなものを指定できる。以上のように定められるCena記述子にはいくつかの表記方法を用いることができる。たとえば文字列表記、配列表記、JSON表記などがある。これを模式的に示すのが図8である。なお、Cena記述子としては、上記に限定されず、少なくともモデル、タイプ、ID、あるいはスキーマ、モデル、タイプ、IDを含む属性から構成されれば、如何なる表現方法を採っても良い。文字列表記は、Cena記述子の各属性を文字列と.ピリオドで区切ることで表記する。配列表記は、Cena記述子の各属性を配列の各属性として代入することで表記する。JSON表記JavaScriptObjectNotationに基づく表記である。次に、上述のように構成されるCena記述子を用いて、本発明におけるデータ処理システム1の構成、処理を説明する。図1に、データ処理システム1の全体の構成の一例を模式的に示す。なおデータ処理システム1におけるデータ集合体としては、データベース、データファイル、音楽ファイル、映像ファイルなど如何なるものであっても良く、データの集合体であればよい。また、データ処理システム1は、図1では、それぞれにデータ集合体を備える2つのコンピュータ端末システム3、システム2の場合であって、一のコンピュータ端末から他方のコンピュータ端末にデータが転送されることで、そのデータが追加、反映される場合の処理を示しているが、これが一つのコンピュータ端末で実現されていても良い。コンピュータ端末は、プログラムの演算処理を実行するCPUなどの演算装置20と、情報を記憶するRAMやハードディスクなどの記憶装置21と、ディスプレイ画面などの表示装置22と、キーボードやポインティングデバイスマウスやテンキーなどなどの入力装置23と、演算装置20の処理結果や記憶装置21に記憶する情報をインターネットやLANなどのネットワークを介して送受信する通信装置24とを有している。コンピュータ上で実現する各機能各手段は、その処理を実行する手段プログラムやモジュールなどが演算装置20に読み込まれることでその処理が実行される。各機能は、記憶装置21に記憶した情報をその処理において使用する場合には、該当する情報を当該記憶装置21から読み出し、読み出した情報を適宜、演算装置20における処理に用いる。図2にコンピュータ端末のハードウェア構成の一例を模式的に示す。また、コンピュータ端末は、複数のコンピュータまたはサーバに、その機能が分散配置されていても良い。本発明における各手段は、その機能が論理的に区別されているのみであって、物理上あるいは事実上は同一の領域を為していても良い。データ処理システム1には、少なくとも2以上のデータ集合体と、そのデータ集合体に対する処理を実行する各種の処理部とを有する。データ集合体は、上述のようにデータの集合体である。なお本明細書の以下の説明ではデータ集合体としてデータベースの場合を説明するが、それに限るものではなく、同様に処理を実現することができる。データ処理システムにおける処理部は、データ集合体におけるデータについて、データの関係性を維持したまま、他のデータ集合体に反映させる処理を実現する。処理部としては、データ取得部11とオブジェクト生成部12と参照関係処理部13と保存処理部14と関係更新部15とを有する。データ取得部11は、ほかのデータ集合体からCena記述子によるデータを取得する。たとえば図1の場合、第2のデータ集合体2DデータベースBから、第1のデータ集合体3DデータベースAに反映させるデータを取得する。ここで取得するデータは、上述のCena記述子で記述されている。オブジェクト生成部12は、データ取得部11で取得したデータに基づいて、オブジェクトを生成する。オブジェクトを生成するには、Cena記述子を構成する属性を抽出し、抽出した属性を、それぞれオブジェクトの属性とすることで生成する。参照関係処理部13は、生成したオブジェクトが2以上ある場合に、それらの参照関係があるかを判定する。すなわち、オブジェクト生成部12で生成したオブジェクトにおける、参照関係を示す属性に基づき、オブジェクト同士の参照関係を判定する。そして参照関係処理部13は、参照関係があることを判定すると、それぞれを関係づけて、関係づけたオブジェクトについて、そのタイプが、データの反映先で生成されたことを示すものたとえばgetであるかを判定する。保存処理部14は、参照関係処理部13で生成したオブジェクトを、データ集合体データベースに保存する。オブジェクトを保存する際には、そのオブジェクトを示すCena記述子のうち、先頭から所定数たとえば先頭から3あるいは4などの属性を抽出し、それをオブジェクト名とし、オブジェクト名と属性とを対応づけて第1のデータ集合体3Dに保存する。またこの際に、オブジェクトの属性を更新して保存することとなる。また保存したオブジェクトの属性におけるタイプを、getにして更新する。ここで、タイプがgetになるのは、当該オブジェクトが第2のデータ集合体を備えるシステム2から取得したからである。すなわち、もともとシステム3のオブジェクトではないため、getに更新して保存する。関係更新部15は、保存処理部14がデータ集合体で保存処理を実行後、データ集合体での関係を表すことが可能となるので、関係更新部15は、関係性があるオブジェクトから、保存されたオブジェクトにおけるIDを読み込み、それを、関係づけられているレコードに反映して記憶させる。次に、本発明のデータ処理システム1の処理を図3のフローチャートを用いて説明する。以下の説明では、サーバであるシステム2のデータベースデータベースBからデータをシステム3に転送し、システム3のデータベースデータベースAで登録する場合を説明する。まずシステム2で、図9に示すデータの登録画面からデータの入力が行われることで、データベースBにデータが追加されたとする。この追加されたデータについて、上述のCena記述子を用いると図10に示すようになる。つまり、名前として特許三郎、性別として男性、分類として仕事、日付として2011-01-01を入力すると、それがテーブルcontactのレコードクラスdaocontactのプライマリーキー10に対応づけて記憶される。また、連絡方法としてFacebook、参照データ関連づけるデータとしてCenadaocontactnew10、分類としてTELを入力すると、それが、テーブルconnectのレコードクラスdaoconnectのプライマリーキー11に対応づけて記憶される。そしてこれらに基づいて、Cena記述子に変換される。なお、データに対する属性の入力の代わりに、プルダウンメニューなどで選択入力可能としても良い。特に参照データについては、関連づける相手先のレコードやプライマリーキーなどに基づいて、自動的に入力されるようにしてもよい。これによって入力ミスなどを防止することができる。具体的には、テーブルcontactのレコードdaocontactにおけるCena記述子Cenadaocontactnew10に対して、属性、つまり名前特許三郎、性別男性、分類仕事および日付が2011年1月1日を対応付けてデータベースBに記憶する。また、テーブルconnectのレコードdaoconnectにおけるCena記述子Cenadaoconnectnew11に対して、属性、つまり連絡方法Facebook、その参照データCenadaocontactnew10および分類TELを対応づけてデータベースBに記憶する。なお、図10では説明の便宜上、当該Cena記述子に対しては名前のみを示しており、それ以外は図から省略しているが、以下の処理でも名前の場合と同様に処理可能である。また、上述では2つのレコードから2つのオブジェクトの場合を示したが、レコードを自己参照して、1つのレコードから2つのオブジェクトを生成する場合もある。以上のようにしてシステム2で生成したCena記述子によるデータについて、所定の操作をすることで、システム3に転送する。このようにして転送されたデータCena記述子で記述されるデータを、システム3のデータ処理システム1のデータ取得部11で取得するS100。データ取得部11で取得したデータCena記述子で記述されるデータに基づいて、データ処理システム1のオブジェクト生成部12は、オブジェクトを生成するS110。これはデータ取得部11で取得した、Cena記述子での記述のうち、スキーマ、モデル、タイプ、IDの最初の4属性に基づいて、オブジェクトを生成する。すなわち、先頭のスキーマの文字列によって、Cena記述子で記述されていることを特定することで、2番目の属性をモデル、3番目の属性をタイプ、4番目の属性をIDとして特定できるので、それに基づきオブジェクトの属性を生成する。またそれ以外の部分についてはオブジェクトの属性を生成する。すなわち、Cenadaocontactnew10では、先頭の属性の文字列によりCena記述子であることを特定できるので、2番目の属性がモデル、つまりデータの種別データベースの場合にはテーブル名を特定し、3番目の属性がタイプ、つまりデータの種別新たに追加されたデータnewか、システム3で作成されたデータgetかを特定し、4番目の属性がID、つまりデータを一意に特定する値であることを特定し、それぞれをオブジェクトの属性とする。また、さらに、それ5番目以降の属性については、それぞれを値としてオブジェクトの属性とする。このようにシステム3から取得したデータのうち、先頭から所定数たとえば4番目の属性に基づいてオブジェクトを生成する。なお先頭にスキーマを用いない場合つねにCena記述子を用いることが特定されている場合などでは、スキーマを用いずに自動的にオブジェクト生成部12がオブジェクトを生成する。図10に基づく2つのオブジェクトが図11である。2つのオブジェクトとなるのは、モデルが2つ、すなわちデータベースのテーブルが2つだからである。S110において、オブジェクト生成部12がオブジェクトを生成すると、参照関係処理部13が、生成したオブジェクト間における参照関係が存在するかを判定する。すなわち、オブジェクトの各属性を参照し、参照関係があるかを判定するS120。参照関係がなければS160以降の処理を実行する。一方、参照関係がある場合には、S130以降の処理を実行する。図11の場合、オブジェクトCenadaoconnectnew11では、オブジェクトCenadaocontactnew10を参照しているrelcontactidCenadaocontactnew10。従って、参照関係処理部13は、参照関係があると判定できる。これを模式的に示すのが図12である。参照関係処理部13で参照関係があることを判定すると、参照関係処理部13は,参照関係があると判定したオブジェクトについて、それぞれを関係づけるS130。そして関係づけることによって、システム3において、図13に示すような画面を表示装置22で表示し、これを反映することの入力を受け付ける。図13では、IDを表示しているが、表示しないように構成することもできる。また、上述の関係づけはいわゆるデータ間の紐付けで行われればよい。また、参照関係処理部13で参照関係がないと判定した場合にも、対応する画面を表示する表示装置22で表示をし、それを反映することの入力を受け付けてもよいし、受け付けずにそのまま処理を行っても良い。そしてS130でオブジェクトの関係づけを参照関係処理部13が行うと、参照関係処理部13が、関係づけられるオブジェクトのタイプがgetデータの反映先であるシステム3以外のシステムで作成されたデータであることを示すタイプであるかを判定するS140。なおタイプとしてはgetのほかに、newがあり、これは、データの反映先であるシステム3で作成されたデータであることを示すタイプである。つまり、S140では、反映先のシステムで作成したデータであるかを判定している。タイプがgetである場合には、システム3で作成したデータではないので、そのオブジェクトのIDを取得する。ここでは、IDとして、オブジェクトCenadaocontactnew10については10を、オブジェクトCenadaoconnectnew11については11を取得することとなるS150。なお、タイプがnewである場合には、システム3で作成したデータなので、S160以降の処理を実行する。S150までの処理が終了後、すなわち、S110でオブジェクト生成部12で生成したオブジェクトおよびS130で関係づけたオブジェクト間の関係の作成が完了したら、オブジェクト生成部12で生成したオブジェクトを、保存処理部14が、システム3のデータベースAに保存するS160。これによって、オブジェクトにおけるプライマリーキーIDなどの属性もデータベースAに反映されることとなる。なお、S160で保存する場合には、そのオブジェクトを示すCena記述子のうち、先頭から所定数たとえば先頭から3あるいは4などの属性を抽出し、それをオブジェクト名とし、オブジェクト名と属性とを対応づけて保存する。また、オブジェクトの属性を更新して保存する。この場合、システム3は、システム2から受け取ったデータを保存したので、タイプはgetとなる。これを模式的に示すのが図14である。なお、図14では、テーブルcontactでは、すでにIDの10が使われており、15が割り当てられたとする。図14の場合、図10に示すCena記述子に基づいてオブジェクトが生成されている。すなわち、図10に示すCena記述子の場合、先頭から4属性までをオブジェクト名とするので、Cenadaocontactnew10がオブジェクト名となる。そして各Cena記述子に基づいて、オブジェクト名に対応づけてそれぞれ当該オブジェクトの属性が保存されることとなる。このように、S160における保存の処理によって、オブジェクト内部の属性は変更されうるが、同じオブジェクトとして認識されるため、オブジェクト間の関係には影響がない。つまり、図14では、テーブルdaocontactにおいて、contactidとして10がすでに使用されていることから、保存の際には、自動的に15が割り当てられた。これによってオブジェクトCenadaocontactnew10の内部の属性のIDは変わったが、オブジェクトを表すCena記述子そのものは変更がなく、オブジェクト間の関係も保持されたままとなる。またS160で関係を保存する際に、相手のオブジェクトのタイプを確認することもできる。もしタイプがgetであれば、当該オブジェクトのIDは反映先のデータベースでのプライマリーキーIDと一致する。そこでオブジェクトが保存される前にIDを取得しておき、関係をデータベース上に保存することが可能である。また、タイプがnewの場合には、IDが変更される場合があるため、関係先のオブジェクトが保存された後のIDを用いる。以上のようにして、S120で判定した、オブジェクトのすべての関係性について、その関係性を保存したかを判定しS170、すべての関係が保存された場合にはその処理を終了する。一方、そうでない場合には、S180以降の処理を実行する。すなわちデータ処理システム1は、関係更新部15において、関係更新処理を実行するS180。すなわち、保存処理部14がデータベースAに保存処理を実行後、データベースA上での関係を表すことが可能となる。従って、関係更新部15は、関係しているオブジェクトから保存されたオブジェクトにおけるIDプライマリーキーを読み込みS180、Cena記述子におけるタイプに基づくレコード上に保存するS190。上述の例の場合、オブジェクトCenadaoconnectnew11に関係するオブジェクトCenadaocontactnew10が保存される際に、当該オブジェクトに割り当てられる最終的なIDプライマリーキーが15で割り当てられているので、割り当てられたID15を関係更新部15が読み込むS180。そして、オブジェクトCenadaoconnectnew11のcontactidを、読み込んだ15として決定してその関係を保存するS190。これを模式的に示すのが図15である。またこの関係性が反映されてデータが保存された結果を示す画面の一例が図16である。以上のような処理を実行することで、2つのデータベースにおいて、データの追加変更等がある場合にも、フラグを用いずにデータ間の連携を保持することが可能となる。また、オブジェクトとして、配列または連想配列を用いて上述の処理と同様の処理を実行することが可能となる。すなわち、配列に反映するデータを保存し、Cena記述子で配列を読み込めば良い。まず転送の対象となるデータから配列を生成する。この配列は、上述のCena記述子を用いて配列の参照が行われるようにする。次に、各レコード間の関係がCena記述子を用いて表されているので、Cena記述子から関係する配列を求め、配列間の関係として表す。そして、必要な配列および配列間の関係の生成が完了後、配列を実際のデータベースに保存する。保存したら、配列のデータを、保存された内容に更新する。またデータが、転送を受け取ったシステムここではシステム3に保存されたことから、タイプがgetに更新される。保存の処理が終了後、データベースでの関係を表すことが可能となるので、関係している配列から、保存されたIDプライマリーキーを読み込み、関係づけて自身のレコード上に保存する。以上のような処理を実行することで、配列または連想配列を用いた場合でも処理が実現可能となる。また本発明のデータ処理システム1で用いるCena記述子を用いて関係を表す場合、その関係性を簡単に保持することが可能となる。以下にこの点について説明する。なお、以下の処理は、上述の図3のフローチャートと同様の部分もある。上述と同様に、システム2で追加されたデータを、システム3で登録する場合を説明する。従って、システム2からシステム3には、たとえば図17に示すデータが送られる。図17の場合、テーブルdaocontactにプライマリーキー10のレコードとして特許三郎が追加され、テーブルdaoconnectにプライマリーキー11のレコードとしてFacebook、当該レコードが、テーブルdaocontactにプライマリーキー10のレコードと関係づけられている場合を示している。システム3で、システム2から図17のデータを取得すると、それをデータベースAに保存する。またデータベースAでは、すでにID10が使用されている場合、使用されていないID、たとえば15が割り当てられる。また、オブジェクトをデータベースAに保存することで、タイプはgetに代わり、テーブルcontactのIDは15で保存される。これを模式的に示すのが図18である。そしてデータベースAへの保存前と保存後のCena記述子の関係を作成する。図18の場合、図19のようになる。そしてデータベースAの保存前と保存後との関係から、保存前のCena記述子を、保存後のCena記述子に変換する。上述の例では、テーブルdaocontactにおいて、IDがcontactid15に変更されたことから、テーブルdaoconnectでその関係性の変換が行われる。すなわち、Cenadaocontactnew10がCenadaocontactget15に変換される。これを模式的に示すのが図20である。このようにCena記述子は、すべてのデータシステム上に存在するデータおよび新たに登録するデータを一意に指定している。つまり、Cena記述子自体も一意の文字列であるため、単純なテキストの変換を行うことで、それらの関係性を更新することができる。これは、データベースに保存する際に、Cena記述子からIDデータベースの場合にはプライマリーキーを取得することで抜き出す。また、システム3とシステム2とで同期を取る場合には、Cena記述子の変更履歴を用いて、反映元システム2のデータベースと転送を受け取った側のデータベースを同期することが可能である。以上の処理で得られた変更履歴を転送元のシステムシステム2へ転送し、転送元のシステムシステム2では、その変更履歴を用いて、データベース上のIDデータベースの場合、プライマリーキーおよび関係を更新することが可能となる。"