JP2003511796A - 統合型データベース結合システム - Google Patents
統合型データベース結合システムInfo
- Publication number
- JP2003511796A JP2003511796A JP2001530749A JP2001530749A JP2003511796A JP 2003511796 A JP2003511796 A JP 2003511796A JP 2001530749 A JP2001530749 A JP 2001530749A JP 2001530749 A JP2001530749 A JP 2001530749A JP 2003511796 A JP2003511796 A JP 2003511796A
- Authority
- JP
- Japan
- Prior art keywords
- data
- database
- database system
- oltp
- key
- 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
Links
- 238000000034 method Methods 0.000 claims abstract description 79
- 230000008859 change Effects 0.000 claims description 31
- 238000012545 processing Methods 0.000 claims description 31
- 238000013507 mapping Methods 0.000 claims description 29
- 230000008569 process Effects 0.000 claims description 16
- 238000003860 storage Methods 0.000 claims description 9
- 238000012790 confirmation Methods 0.000 claims description 8
- 238000012986 modification Methods 0.000 claims description 6
- 230000004048 modification Effects 0.000 claims description 6
- 230000004044 response Effects 0.000 claims description 4
- 238000012795 verification Methods 0.000 claims description 2
- 230000000153 supplemental effect Effects 0.000 claims 4
- 238000004590 computer program Methods 0.000 claims 3
- 244000309464 bull Species 0.000 claims 1
- 238000012937 correction Methods 0.000 claims 1
- 230000010354 integration Effects 0.000 abstract description 15
- 230000005540 biological transmission Effects 0.000 description 37
- 230000006870 function Effects 0.000 description 34
- 239000003795 chemical substances by application Substances 0.000 description 25
- 238000010586 diagram Methods 0.000 description 25
- 230000000875 corresponding effect Effects 0.000 description 23
- 230000010076 replication Effects 0.000 description 13
- 238000000605 extraction Methods 0.000 description 10
- 230000004927 fusion Effects 0.000 description 8
- 230000009471 action Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 7
- 238000012546 transfer Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 230000008878 coupling Effects 0.000 description 4
- 238000010168 coupling process Methods 0.000 description 4
- 238000005859 coupling reaction Methods 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 239000000284 extract Substances 0.000 description 3
- 238000001914 filtration Methods 0.000 description 3
- 239000011232 storage material Substances 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 230000008676 import Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 238000012384 transportation and delivery Methods 0.000 description 2
- 101000642819 Solanum tuberosum Soluble starch synthase 1, chloroplastic/amyloplastic Proteins 0.000 description 1
- 101000642821 Triticum aestivum Starch synthase 1, chloroplastic/amyloplastic Proteins 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- SILSDTWXNBZOGF-KUZBFYBWSA-N chembl111058 Chemical compound CCSC(C)CC1CC(O)=C(\C(CC)=N\OC\C=C\Cl)C(=O)C1 SILSDTWXNBZOGF-KUZBFYBWSA-N 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 230000009469 supplementation Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Vehicle Body Suspensions (AREA)
- Error Detection And Correction (AREA)
- Steering-Linkage Mechanisms And Four-Wheel Steering (AREA)
- Credit Cards Or The Like (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Storage Device Security (AREA)
- Optical Communication System (AREA)
- Iron Core Of Rotating Electric Machines (AREA)
- Measuring Pulse, Heart Rate, Blood Pressure Or Blood Flow (AREA)
Abstract
(57)【要約】
企業やその他の組織において、データ内容のオーバラップした大規模なデータセットが様々なデータベースシステム内に格納されており、それらのデータベースのデータ構造は互いに互換性のないものである。本発明は、そのような構造的に互換性のないデータベースシステムの統合にかかわり、たとえばこのようなシステム間のデータ交換に関する。これによれば種々の方法が提案され、その目的は、そのようなデータベースシステムを双方向で問題なくデータ交換ができるよう互いに融合させることである。たとえばシステムを超えて共有されている様々なシステムのデータの新たなエントリおよび変更が実現される。
Description
【０００１】
本発明は、構造的に互換性のない種々のデータベースシステムの統合に関する
。
。
【０００２】
データベースシステムは電子データ処理の数多くの適用事例において大きな役
割を果たしている。
割を果たしている。
【０００３】
それらのデータベースシステムは通常、本来のデータベース（データバンク）
とデータベース管理システムによって構成されている。そしてそれらは、データ
ベースに格納されているデータが多種多様に処理されるような広範囲に及ぶコン
ピュータアプリケーションの基礎を成すことが多い。
とデータベース管理システムによって構成されている。そしてそれらは、データ
ベースに格納されているデータが多種多様に処理されるような広範囲に及ぶコン
ピュータアプリケーションの基礎を成すことが多い。
【０００４】
企業ＥＤＰの分野において重要な実例はいわゆるＥＲＰ（Enterprise Resourc
e Planning）システムであり、たとえばドイツ連邦共和国 Walldorf のSAP 社に
よる OLTP-R/3 などである。それらによって人事や販売や在庫管理など様々な企
業分野におけるＥＤＰ支援を、１つの共通の中央データベースに基づき実現する
ことができる。この種のシステムはバックオフィスシステムと呼ばれることが多
い。
e Planning）システムであり、たとえばドイツ連邦共和国 Walldorf のSAP 社に
よる OLTP-R/3 などである。それらによって人事や販売や在庫管理など様々な企
業分野におけるＥＤＰ支援を、１つの共通の中央データベースに基づき実現する
ことができる。この種のシステムはバックオフィスシステムと呼ばれることが多
い。
【０００５】
データベースシステムの別の重要な実例はカスタマサポートシステムであり、
それらはしばしばＳＦＡ（Sales Force Automation）またはＣＲＭ（Customer R
elation Management）システムと呼ばれる。この種のシステムは殊に、カスタマ
アドバイス、カスタマサポートならびに販売におけるＥＤＰ要求に合わせてカス
タマイズされている。これには、企業の外勤従業員にポータブルコンピュータを
装備させ、このコンピュータによりデータベースシステムのモバイルクライアン
ト（mobile client）として、個々の外勤従業員が必要とするデータ（たとえば
その従業員の地区のカスタマに関するデータやその従業員の販売状況に関するデ
ータ）をもつ固有のローカルデータベースが提供される。このようなシステム（
フロントオフィスシステムと呼ばれることが多い）には、やはりデータベースを
有する中央コンピュータが含まれており、そのデータベースにはモバイルクライ
アントのデータの総計が格納されている。つまりこれはオフライン分散型データ
ベースシステムである。モバイルクライアントのほかにＣＲＭシステムの中央コ
ンピュータとは他の外部のシステムも通信を行うことができ、たとえばカスタマ
のＥＤＰシステムなどがそれを行うことができ、このシステムは一時的にまたは
定常的なデータコネクションを介して中央コンピュータに接続される。
それらはしばしばＳＦＡ（Sales Force Automation）またはＣＲＭ（Customer R
elation Management）システムと呼ばれる。この種のシステムは殊に、カスタマ
アドバイス、カスタマサポートならびに販売におけるＥＤＰ要求に合わせてカス
タマイズされている。これには、企業の外勤従業員にポータブルコンピュータを
装備させ、このコンピュータによりデータベースシステムのモバイルクライアン
ト（mobile client）として、個々の外勤従業員が必要とするデータ（たとえば
その従業員の地区のカスタマに関するデータやその従業員の販売状況に関するデ
ータ）をもつ固有のローカルデータベースが提供される。このようなシステム（
フロントオフィスシステムと呼ばれることが多い）には、やはりデータベースを
有する中央コンピュータが含まれており、そのデータベースにはモバイルクライ
アントのデータの総計が格納されている。つまりこれはオフライン分散型データ
ベースシステムである。モバイルクライアントのほかにＣＲＭシステムの中央コ
ンピュータとは他の外部のシステムも通信を行うことができ、たとえばカスタマ
のＥＤＰシステムなどがそれを行うことができ、このシステムは一時的にまたは
定常的なデータコネクションを介して中央コンピュータに接続される。
【０００６】
慣用のバックオフィスシステムも慣用のフロントオフィスシステムも非常に複
雑である。それらのシステムのためには様々なコンポーネント間の通信能力、デ
ータ保全性およびデータの同期を確保するためにパワフルな方法がそれぞれ必要
とされ、その際、著しく多くのユーザ数を通信に含めることができるよう考慮し
なければならない。
雑である。それらのシステムのためには様々なコンポーネント間の通信能力、デ
ータ保全性およびデータの同期を確保するためにパワフルな方法がそれぞれ必要
とされ、その際、著しく多くのユーザ数を通信に含めることができるよう考慮し
なければならない。
【０００７】
先に挙げた形式の大規模なシステムについて広範囲にわたりこの問題が解決さ
れている一方で、構造的に互換性はないがかなりの部分で同じ（業務）データを
管理しているデータベースシステムを互いに融合させる確かな方法はまだない。
たとえばＥＲＰシステムでは通常、企業のカスタマに関する大規模なデータセッ
ト（たとえば住所、仲介者、処理されたオーダや仕入れ状況に関するデータなど
、また、補充交換部品納入に重要なカスタマのマシン装備に関するデータなど）
が格納されている。広範囲にわたり一致しているデータセットはＣＲＭシステム
においても必要とされる。しかし実際には両方のシステムは、相互に互換性のな
いまったく異なるデータ構造をもっている。
れている一方で、構造的に互換性はないがかなりの部分で同じ（業務）データを
管理しているデータベースシステムを互いに融合させる確かな方法はまだない。
たとえばＥＲＰシステムでは通常、企業のカスタマに関する大規模なデータセッ
ト（たとえば住所、仲介者、処理されたオーダや仕入れ状況に関するデータなど
、また、補充交換部品納入に重要なカスタマのマシン装備に関するデータなど）
が格納されている。広範囲にわたり一致しているデータセットはＣＲＭシステム
においても必要とされる。しかし実際には両方のシステムは、相互に互換性のな
いまったく異なるデータ構造をもっている。
【０００８】
たとえば価格決定（pricing）は、種々のアプリケーションにおいてＥＤＰサ
ポートを受けて実行されるタスクである。（たとえば原価、個数、運搬費、およ
び場合によっては特別な条件を考慮した）一貫した業務の流れが基礎を成してい
るにもかかわらず、種々のデータベースシステムへの実装は完全に異なっている
ことがよくあり、つまり業務処理のインプリメントに利用されるアルゴリズム（
いわゆるビジネスロジック "Businesslogik"）は非常に異なっている。とはいえ
当然ながら、価格決定を種々異なるシステムにおいてできりかぎり等しく取り扱
えるようにして同じ結果が得られるようにする必要がある。
ポートを受けて実行されるタスクである。（たとえば原価、個数、運搬費、およ
び場合によっては特別な条件を考慮した）一貫した業務の流れが基礎を成してい
るにもかかわらず、種々のデータベースシステムへの実装は完全に異なっている
ことがよくあり、つまり業務処理のインプリメントに利用されるアルゴリズム（
いわゆるビジネスロジック "Businesslogik"）は非常に異なっている。とはいえ
当然ながら、価格決定を種々異なるシステムにおいてできりかぎり等しく取り扱
えるようにして同じ結果が得られるようにする必要がある。
【０００９】
本発明の課題は、構造的に互換性のないデータベースシステムを、双方向で問
題なくデータ交換できるよう相互に融合することである。ここでシステムの「融
合」とは、技術レベルでの結合を超えて、データ同期を実現し、それぞれ異なる
システムにおいてほぼ同じ動作が得られるような制御ロジックの交換を可能とす
ることである。複数のサブシステムから成る統合された１つの結合システムへの
このような融合を、ここではセマンティック・システムインテグレーション（"s
emantic system integration"）と称する。このためにはたとえば、 −システムの確実な技術的結合 −融合されたシステムにおける有効データの同期合わせ −融合されたシステムをコントロールするためのカスタマ固有の整合（カスタマ
イズデータ）の同期合わせ −データ変更の食い違いや他のデータ不一致が発生したときの適切なコンフリク
ト解消法 が必要とされる。
題なくデータ交換できるよう相互に融合することである。ここでシステムの「融
合」とは、技術レベルでの結合を超えて、データ同期を実現し、それぞれ異なる
システムにおいてほぼ同じ動作が得られるような制御ロジックの交換を可能とす
ることである。複数のサブシステムから成る統合された１つの結合システムへの
このような融合を、ここではセマンティック・システムインテグレーション（"s
emantic system integration"）と称する。このためにはたとえば、 −システムの確実な技術的結合 −融合されたシステムにおける有効データの同期合わせ −融合されたシステムをコントロールするためのカスタマ固有の整合（カスタマ
イズデータ）の同期合わせ −データ変更の食い違いや他のデータ不一致が発生したときの適切なコンフリク
ト解消法 が必要とされる。
【００１０】
オンラインでもオフラインでも安定したコネクションを形成するため、実証済
みのハードウェアテクノロジーおよびソフトウェアテクノロジーを利用すること
ができる。この場合、キューメカニズムが重要な役割を果たし、これによれば各
データ単位が正確に１回で伝送され（guaranteed delivery）、データが精確に
決められた順序で伝送されるようになる（In-Order-Processing）。セマンティ
ックなシステム統合のこのような部分的な観点については詳しく説明する必要は
ない。
みのハードウェアテクノロジーおよびソフトウェアテクノロジーを利用すること
ができる。この場合、キューメカニズムが重要な役割を果たし、これによれば各
データ単位が正確に１回で伝送され（guaranteed delivery）、データが精確に
決められた順序で伝送されるようになる（In-Order-Processing）。セマンティ
ックなシステム統合のこのような部分的な観点については詳しく説明する必要は
ない。
【００１１】
これに対し、前述の他の要求の実現のためには非常に難しい問題点があり、殊
に一般に出発点となり得るのは、様々なデータベースシステムがソフトウェア製
品の様々な「世界」に属する可能性のあることである。本発明の課題は、このよ
うな問題点を解決するシステムコンポーネントおよび方法を提供することである
。
に一般に出発点となり得るのは、様々なデータベースシステムがソフトウェア製
品の様々な「世界」に属する可能性のあることである。本発明の課題は、このよ
うな問題点を解決するシステムコンポーネントおよび方法を提供することである
。
【００１２】
種々のデータベースシステムのデータモジュールはそれぞれ異なっている。し
たがってそれらのデータ構造を相互にマッピングしなければならない。しかもデ
ータ内容の整合が必要とされる（たとえば用語の使い方としてあるシステムの「
カスタマ customer」は別のシステムでは「バイヤ buyer」に対応している）。
これら両方の機能は、互換性のない２つのシステム間のデータ交換においてスタ
ンダードな役割設定である。慣用のシステム統合はこのような形式のコネクショ
ンに関するものである。これによれば、統合システム全体において有効でなけれ
ばならないデータの新たなエントリを、複数のシステムのうち中央システムと称
する１つのシステムにおいてのみ、データベース結合システム全体に対して有効
に実施することができる。しかしこのことは多くの事例において、たとえばＣＲ
ＭシステムとＥＲＰシステムとの融合においては不十分である。なぜならばその
場合、重要な新たなデータは企業のヘッドオフィスにおいても（つまりＥＲＰシ
ステムにおいても）カスタマサポートにおいても（つまりＣＲＭシステムにおい
ても）生じるものであり、新たに取り込まれた後には結合システム全体で利用で
きなければならないからである。
たがってそれらのデータ構造を相互にマッピングしなければならない。しかもデ
ータ内容の整合が必要とされる（たとえば用語の使い方としてあるシステムの「
カスタマ customer」は別のシステムでは「バイヤ buyer」に対応している）。
これら両方の機能は、互換性のない２つのシステム間のデータ交換においてスタ
ンダードな役割設定である。慣用のシステム統合はこのような形式のコネクショ
ンに関するものである。これによれば、統合システム全体において有効でなけれ
ばならないデータの新たなエントリを、複数のシステムのうち中央システムと称
する１つのシステムにおいてのみ、データベース結合システム全体に対して有効
に実施することができる。しかしこのことは多くの事例において、たとえばＣＲ
ＭシステムとＥＲＰシステムとの融合においては不十分である。なぜならばその
場合、重要な新たなデータは企業のヘッドオフィスにおいても（つまりＥＲＰシ
ステムにおいても）カスタマサポートにおいても（つまりＣＲＭシステムにおい
ても）生じるものであり、新たに取り込まれた後には結合システム全体で利用で
きなければならないからである。
【００１３】
システムを超えてクロスシステムないしはシステムワイドに供給されるデータ
の新たなエントリを結合システムの各サブシステムにおいて実行できるようにし
ようという場合（つまり新たなエントリ実行後にけつごうしすてむのすべてのサ
ブシステムにおいて利用できるようにしようという場合）、そのためにはいかな
る時点でもデータオブジェクト識別のためシステムを超えて一義的なプライマリ
キーを利用できるようにしなければならない。その際、このようなプライマリキ
ーを数値範囲の割り当てやＧＵＩＤ（Global Unified Identifier）キーの割り
当てによって生成することが知られている。とはいえこれら両方のやり方は汎用
的に利用できるものではない。
の新たなエントリを結合システムの各サブシステムにおいて実行できるようにし
ようという場合（つまり新たなエントリ実行後にけつごうしすてむのすべてのサ
ブシステムにおいて利用できるようにしようという場合）、そのためにはいかな
る時点でもデータオブジェクト識別のためシステムを超えて一義的なプライマリ
キーを利用できるようにしなければならない。その際、このようなプライマリキ
ーを数値範囲の割り当てやＧＵＩＤ（Global Unified Identifier）キーの割り
当てによって生成することが知られている。とはいえこれら両方のやり方は汎用
的に利用できるものではない。
【００１４】
数値範囲の割り当てのためには、関与するデータベースシステムにおいてキー
を生成するために同じアルゴリズムが必要とされる。このことはそれぞれ異なる
メーカのシステムにおいて保証することはできない。また、同じメーカの種々の
システムであっても、様々なキー生成手順の実装されていることが多い。
を生成するために同じアルゴリズムが必要とされる。このことはそれぞれ異なる
メーカのシステムにおいて保証することはできない。また、同じメーカの種々の
システムであっても、様々なキー生成手順の実装されていることが多い。
【００１５】
また、ＧＵＩＤを用いた一義的なキーの生成を利用できるのは、関与している
すべてのシステムがＧＵＩＤ手順を利用しているときだけである。このこともや
はり多くの事例において保証できないことである。
すべてのシステムがＧＵＩＤ手順を利用しているときだけである。このこともや
はり多くの事例において保証できないことである。
【００１６】
本発明の第１の観点によれば、このことから生じる問題点を解決するため、２
つのデータベースシステムＡとＢとの間でデータを交換するための以下のような
方法が提案される。すなわちこの方法によれば、データベースシステムの各々は
、格納されているデータオブジェクトの一義的な識別のため、各データオブジェ
クトごとにプライマリキー生成ロジックを用いてシステム固有のプライマリキー
を生成し、両方のデータベースシステムＡおよびＢのプライマリキー生成ロジッ
クは互いに独立している。ここにおいて、ソースデータベースシステムＡからタ
ーゲットデータベースシステムＢへ伝送されるデータオブジェクトについて、シ
ステムを超えてクロスシステムで共有される新しいエントリに必要とされる一義
的な識別を可能にするため、 ａ）ソースデータベースシステムＡからターゲットデータベースシステムＢへ
伝送すべきデータオブジェクトのプライマリキーをキーマッピングテーブルと比
較するステップを実行し、該キーマッピングテーブルは、すでに２つのプライマ
リキーの生成されているすべてのデータオブジェクトのプライマリキーを有して
おり、 ｂ）プライマリキーが前記キーマッピングテーブル内にまだ存在していなけれ
ば、自動的にターゲットデータベースシステムＢのプライマリキーを生成してデ
ータオブジェクト内に格納し、ソースデータベースシステムＡのプライマリキー
といっしょに前記キーマッピングテーブルに格納するステップと、 ｃ）ソースデータベースシステムＡのプライマリキーが前記キーマッピングテ
ーブル内で見つけられたならば、ターゲットシステムＢの対応するプライマリキ
ーをデータオブジェクトに格納するステップを実行する。
つのデータベースシステムＡとＢとの間でデータを交換するための以下のような
方法が提案される。すなわちこの方法によれば、データベースシステムの各々は
、格納されているデータオブジェクトの一義的な識別のため、各データオブジェ
クトごとにプライマリキー生成ロジックを用いてシステム固有のプライマリキー
を生成し、両方のデータベースシステムＡおよびＢのプライマリキー生成ロジッ
クは互いに独立している。ここにおいて、ソースデータベースシステムＡからタ
ーゲットデータベースシステムＢへ伝送されるデータオブジェクトについて、シ
ステムを超えてクロスシステムで共有される新しいエントリに必要とされる一義
的な識別を可能にするため、 ａ）ソースデータベースシステムＡからターゲットデータベースシステムＢへ
伝送すべきデータオブジェクトのプライマリキーをキーマッピングテーブルと比
較するステップを実行し、該キーマッピングテーブルは、すでに２つのプライマ
リキーの生成されているすべてのデータオブジェクトのプライマリキーを有して
おり、 ｂ）プライマリキーが前記キーマッピングテーブル内にまだ存在していなけれ
ば、自動的にターゲットデータベースシステムＢのプライマリキーを生成してデ
ータオブジェクト内に格納し、ソースデータベースシステムＡのプライマリキー
といっしょに前記キーマッピングテーブルに格納するステップと、 ｃ）ソースデータベースシステムＡのプライマリキーが前記キーマッピングテ
ーブル内で見つけられたならば、ターゲットシステムＢの対応するプライマリキ
ーをデータオブジェクトに格納するステップを実行する。
【００１７】
これによれば、関与しているデータベースシステムが固有のプライマリキー生
成ロジックを使用しており、それらのロジックが互いにチューニングされていな
いような事例であっても、システムを超えて一義的なプライマリキーの生成（つ
まりはシステムを超えて共有される新たなエントリの実行）が実現される。この
場合、関与しているシステムの制御データメモリ（レポジトリ）内にキーロジッ
クが定義される。また、キージェネレータを用いて両方のロジックが互いにマッ
ピングされる。
成ロジックを使用しており、それらのロジックが互いにチューニングされていな
いような事例であっても、システムを超えて一義的なプライマリキーの生成（つ
まりはシステムを超えて共有される新たなエントリの実行）が実現される。この
場合、関与しているシステムの制御データメモリ（レポジトリ）内にキーロジッ
クが定義される。また、キージェネレータを用いて両方のロジックが互いにマッ
ピングされる。
【００１８】
第２の観点によれば本発明は、第１のデータベースシステムＡ内のデータセッ
トにおいて実行された変更に基づき第２のデータベースシステムＢ内のデータセ
ットを更新する方法に関する。この場合、第１のデータベースシステムＡのデー
タセットは、第２のデータベースシステムＢには関連しないデータも、第２のデ
ータベースシステムＢに関連するデータも有しており、各データベースシステム
におけるデータを、それぞれシステム固有のプライマリキーを有するデータオブ
ジェクトのかたちで処理し、該データを第２のデータベースシステムＢにおいて
両方のシステム固有のプライマリキーとともに格納する。この場合、以下のステ
ップの少なくとも一部分が実行される。すなわち、 ａ）第２のデータベースシステムＢには関連しないデータＤＲ／３をデータオ
ブジェクトから分離するステップと、 ｂ）第１のデータベースシステムＡから第２のデータベースシステムＢへデー
タオブジェクトを転送するステップと、 ｃ）データベースシステムＢに固有のキーを生成し、生成されたキーをデータ
オブジェクトに追加するステップと、 ｄ）生じたデータオブジェクトを第２のデータベースシステムＢの格納ルーチ
ンに組み込み、該データオブジェクト中に含まれているデータを第２のデータベ
ースシステムＢのデータベースに格納するステップの少なくとも一部を実行する
。有利にはすべてのステップａ）〜ｄ）が実行される。
トにおいて実行された変更に基づき第２のデータベースシステムＢ内のデータセ
ットを更新する方法に関する。この場合、第１のデータベースシステムＡのデー
タセットは、第２のデータベースシステムＢには関連しないデータも、第２のデ
ータベースシステムＢに関連するデータも有しており、各データベースシステム
におけるデータを、それぞれシステム固有のプライマリキーを有するデータオブ
ジェクトのかたちで処理し、該データを第２のデータベースシステムＢにおいて
両方のシステム固有のプライマリキーとともに格納する。この場合、以下のステ
ップの少なくとも一部分が実行される。すなわち、 ａ）第２のデータベースシステムＢには関連しないデータＤＲ／３をデータオ
ブジェクトから分離するステップと、 ｂ）第１のデータベースシステムＡから第２のデータベースシステムＢへデー
タオブジェクトを転送するステップと、 ｃ）データベースシステムＢに固有のキーを生成し、生成されたキーをデータ
オブジェクトに追加するステップと、 ｄ）生じたデータオブジェクトを第２のデータベースシステムＢの格納ルーチ
ンに組み込み、該データオブジェクト中に含まれているデータを第２のデータベ
ースシステムＢのデータベースに格納するステップの少なくとも一部を実行する
。有利にはすべてのステップａ）〜ｄ）が実行される。
【００１９】
さらに別の観点によれば本発明は、第２のデータベースシステムＢ内のデータ
セットにおいて実行された変更に基づき第１のデータベースシステムＡ内のデー
タセットを更新する方法に関する。これによれば第２のデータベースシステムＢ
のデータセットは、第１のデータベースシステムＡに関連しないデータも第１の
データベースシステムＡに関連するデータも有しており、各データベースシステ
ムにおけるデータをデータオブジェクトのかたちで処理し、該データオブジェク
トはそれぞれシステム固有のプライマリキーを有しており、第１のデータベース
システムＡ内のデータをそのシステム固有のプライマリキーとのみいっしょに格
納する。この場合、以下のステップの少なくとも１つが実行される。すなわち、 ａ）第１のデータベースシステムＡに関連しないデータＤＭＳをデータオブジ
ェクトから分離し、該データを第２のデータベースシステムＢ内に保管するステ
ップと、 ｂ）前記データオブジェクトを第２のデータベースシステムＢから第１のデー
タベースシステムＡへ転送するステップと、 ｃ）第２のデータベースシステムＢのためのシステム固有のキーを前記データ
オブジェクトから分離し、該キーを第１のデータベースシステムＡに保管するス
テップと、 ｄ）生じたデータオブジェクトを第１のデータベースシステムＡの格納ルーチ
ンに取り込み、該データオブジェクトに含まれているデータを第１のデータベー
スシステムＡのデータベースに格納するステップの少なくとも一部を実行する。
有利にはすべてのステップａ）〜ｄ）が実行される。
セットにおいて実行された変更に基づき第１のデータベースシステムＡ内のデー
タセットを更新する方法に関する。これによれば第２のデータベースシステムＢ
のデータセットは、第１のデータベースシステムＡに関連しないデータも第１の
データベースシステムＡに関連するデータも有しており、各データベースシステ
ムにおけるデータをデータオブジェクトのかたちで処理し、該データオブジェク
トはそれぞれシステム固有のプライマリキーを有しており、第１のデータベース
システムＡ内のデータをそのシステム固有のプライマリキーとのみいっしょに格
納する。この場合、以下のステップの少なくとも１つが実行される。すなわち、 ａ）第１のデータベースシステムＡに関連しないデータＤＭＳをデータオブジ
ェクトから分離し、該データを第２のデータベースシステムＢ内に保管するステ
ップと、 ｂ）前記データオブジェクトを第２のデータベースシステムＢから第１のデー
タベースシステムＡへ転送するステップと、 ｃ）第２のデータベースシステムＢのためのシステム固有のキーを前記データ
オブジェクトから分離し、該キーを第１のデータベースシステムＡに保管するス
テップと、 ｄ）生じたデータオブジェクトを第１のデータベースシステムＡの格納ルーチ
ンに取り込み、該データオブジェクトに含まれているデータを第１のデータベー
スシステムＡのデータベースに格納するステップの少なくとも一部を実行する。
有利にはすべてのステップａ）〜ｄ）が実行される。
【００２０】
本発明のさらに別の観点によれば、複数のデータベースシステムを有する統合
システム内におけるデータの新たなエントリまたは変更のための方法が提案され
る。これによれば、前記統合システムにおけるデータベースシステムのうち任意
の１つのデータベース内で共有されるデータを新たにエントリする際にデータコ
ンフリクトを避けるため、各データベースシステム間で交換可能な各データオブ
ジェクトごとに前記データベースシステムの一方を管理する側のシステムＦＳと
して定義し、該管理する側のシステムＦＳのデータセットにも属するデータオブ
ジェクトのデータを、管理される側のシステムＧＳにおいて新たにエントリまた
は変更するたびに、システムを超えた確認アルゴリズムを実行し、該アルゴリズ
ムにおいて、 ａ）変更を含むデータオブジェクトを管理する側のシステムＦＳ（ＯＬＴＰ−
Ｒ／３）に伝送し、 ｂ）管理する側のシステムＦＳ内で、変更の承認または少なくとも部分的な拒
否として応答メッセージを生成し、 ｃ）応答メッセージを含むデータオブジェクトを管理される側のシステムＧＳ
（ＭＳ）へ送り戻す。
システム内におけるデータの新たなエントリまたは変更のための方法が提案され
る。これによれば、前記統合システムにおけるデータベースシステムのうち任意
の１つのデータベース内で共有されるデータを新たにエントリする際にデータコ
ンフリクトを避けるため、各データベースシステム間で交換可能な各データオブ
ジェクトごとに前記データベースシステムの一方を管理する側のシステムＦＳと
して定義し、該管理する側のシステムＦＳのデータセットにも属するデータオブ
ジェクトのデータを、管理される側のシステムＧＳにおいて新たにエントリまた
は変更するたびに、システムを超えた確認アルゴリズムを実行し、該アルゴリズ
ムにおいて、 ａ）変更を含むデータオブジェクトを管理する側のシステムＦＳ（ＯＬＴＰ−
Ｒ／３）に伝送し、 ｂ）管理する側のシステムＦＳ内で、変更の承認または少なくとも部分的な拒
否として応答メッセージを生成し、 ｃ）応答メッセージを含むデータオブジェクトを管理される側のシステムＧＳ
（ＭＳ）へ送り戻す。
【００２１】
次に、図面に示された実施例に基づき本発明について詳しく説明する。そこで
説明する特徴は、本発明の有利な実施形態を実現する目的で個別に用いることも
できるし、互いに組み合わせて使用することもできる。
説明する特徴は、本発明の有利な実施形態を実現する目的で個別に用いることも
できるし、互いに組み合わせて使用することもできる。
【００２２】
図１は、オフライン分散型データベースにおける本発明による結合システムの
環境の外観を示す図である。
環境の外観を示す図である。
【００２３】
図２は、本発明において適用されるフロントオフィスシステムのアーキテクチ
ャに関する概観をＣＲＭシステムの実例で示す図である。
ャに関する概観をＣＲＭシステムの実例で示す図である。
【００２４】
図３は、図２によるシステムのフローコントロールの典型的な流れをデータア
ップロードプロセスの実例として示す図である。
ップロードプロセスの実例として示す図である。
【００２５】
図４は、図２によるシステムで適用されるデータオブジェクト（”ＢＤｏｃ”
）の構造を示す図である。
）の構造を示す図である。
【００２６】
図５は、本発明に従って互いに結合された２つのシステムにおいてデータのア
ップロードおよびダウンロード時にはたらくコンポーネントのアーキテクチャを
示す図である。
ップロードおよびダウンロード時にはたらくコンポーネントのアーキテクチャを
示す図である。
【００２７】
図６は、ダウンロードの事例に関する図３に応じたフローチャートを示す図で
ある。
ある。
【００２８】
図７は、関与するデータベースシステムに他のデータベースシステム内に含ま
れているデータを初回にダウンロードするためのコンポーネントのアーキテクチ
ャを示す図である。
れているデータを初回にダウンロードするためのコンポーネントのアーキテクチ
ャを示す図である。
【００２９】
図８は、必要とされるプライマリキーをシステムを超えて供給する方法を説明
するための原理図である。
するための原理図である。
【００３０】
図９は、ＢＤｏｃおよび属するキーマッピングテーブルのセグメント構造に関
する実例を示す図である。
する実例を示す図である。
【００３１】
図１０は、いくらか複雑なセグメント構造を有する図９によるＢＤｏｃの構造
に関する実例である。
に関する実例である。
【００３２】
図１１は、本発明に適したデータマージ手順の原理を説明する図である。
【００３３】
図１２は、初回ダウンロードにおける基本コンポーネントの共働の様子を示す
基本原理である。
基本原理である。
【００３４】
図１３および図１４は、本発明に適したネットフィールド伝送手順を説明する
ための２つの図である。
ための２つの図である。
【００３５】
図１５は、データを同期合わせする手順を説明するための基本コンポーネント
の原理図である。
の原理図である。
【００３６】
図１６は、本発明に適した「コンペア」モジュールの機能を説明するための基
本原理図である。
本原理図である。
【００３７】
図１７は、本発明に適したデータアップデート時のコンフリクトを解消する手
順の原理図である。
順の原理図である。
【００３８】
これらの図面に実例として示されている本発明による統合された結合システム
の適用事例は、販売ＥＤＰソリューション（Sales Force Automation; SFA）と
中央ＥＲＰシステムとの統合に関する。図１には、その種のシステムの周囲環境
に関する概観が描かれている。
の適用事例は、販売ＥＤＰソリューション（Sales Force Automation; SFA）と
中央ＥＲＰシステムとの統合に関する。図１には、その種のシステムの周囲環境
に関する概観が描かれている。
【００３９】
外勤従業員（Sales Representative）ＳＲは外勤フィールドＦＤで働いており
、その従業員はカスタマ（Customer）Ｃと相談してたとえばカスタマの注文をと
る。外勤従業員ＳＲは各々ポータブルコンピュータをもっており、これをモバイ
ルクライアント（Mobile Client）ＭＣとも称し、ローカルデータベース（Local Database）ＬＤに属している。ポータブルコンピュータはネットワークのノー
ドを成しており、これは常にネットワークと接続されているわけではなく、した
がってオフラインノードと称する。
、その従業員はカスタマ（Customer）Ｃと相談してたとえばカスタマの注文をと
る。外勤従業員ＳＲは各々ポータブルコンピュータをもっており、これをモバイ
ルクライアント（Mobile Client）ＭＣとも称し、ローカルデータベース（Local Database）ＬＤに属している。ポータブルコンピュータはネットワークのノー
ドを成しており、これは常にネットワークと接続されているわけではなく、した
がってオフラインノードと称する。
【００４０】
モバイルクライアントＭＣはたとえばマーケッティング情報を提供し、殊にカ
スタマや製品の基本データ（マスタデータ）を格納している。外勤従業員ＳＲは
たとえば注文情報を入力し、また、未処理の注文や処理済みの注文についての状
況の情報を得る。これらの機能を一時的に自律的に実現できるようにする目的で
、そのために必要とされるすべてのデータがローカルデータベースＬＤに格納さ
れている。
スタマや製品の基本データ（マスタデータ）を格納している。外勤従業員ＳＲは
たとえば注文情報を入力し、また、未処理の注文や処理済みの注文についての状
況の情報を得る。これらの機能を一時的に自律的に実現できるようにする目的で
、そのために必要とされるすべてのデータがローカルデータベースＬＤに格納さ
れている。
【００４１】
企業の本部（Head Office）にはバックオフィスシステムが存在しており、こ
れによって有利にはオンライントランザクションプロセッシングを行うことがで
きる。ここに示されている実例ではこれはＯＬＴＰ−Ｒ／３システムである。図
面および以下の説明ではそのシステムの用語で表すが、汎用性を制約するわけで
はない。これにはデータベースＯＬＴＰ−ＤＢが含まれている。その基本データ
は内勤従業員（In-House-Employee）ＩＨＥによってメンテナンスされる。
れによって有利にはオンライントランザクションプロセッシングを行うことがで
きる。ここに示されている実例ではこれはＯＬＴＰ−Ｒ／３システムである。図
面および以下の説明ではそのシステムの用語で表すが、汎用性を制約するわけで
はない。これにはデータベースＯＬＴＰ−ＤＢが含まれている。その基本データ
は内勤従業員（In-House-Employee）ＩＨＥによってメンテナンスされる。
【００４２】
ローカルエリアネットワーク（Local Area Network）ＬＡＮを介してＯＬＴＰ
−Ｒ／３システムはフロントオフィスサーバと接続されており、これをミドルウ
ェアサーバ（ＭＳ Middleware Server）と呼ぶが、はやり汎用性を制約するわけ
ではない。このシステムもデータベースＣＤ（Condolidated Database）を有し
ている。
−Ｒ／３システムはフロントオフィスサーバと接続されており、これをミドルウ
ェアサーバ（ＭＳ Middleware Server）と呼ぶが、はやり汎用性を制約するわけ
ではない。このシステムもデータベースＣＤ（Condolidated Database）を有し
ている。
【００４３】
ＭＳシステムには、モバイルクライアントＭＣのほかにオプションの別のシス
テムを接続することができる。図示されているように、本部ＨＯには外部システ
ムＢＷが配置されており、これはたとえばいわゆる "Business Information War
ehouse" として企業にとって重要な販売情報を分析する。これはデータベースＢ
Ｗ−ＤＢを有している。図示されている事例の場合、これはバックオフィスサー
バＯＬＴＰ−Ｒ／３からもＭＳシステムからもデータを受け取る。外勤フィール
ドＦＤにおいてたとえば、ネットワーク内の付加的なノードを成すカスタマシス
テム（Customer System）ＣＳを常に（オンライン）または一時的に（オフライ
ン）ＭＳシステムと接続することができる。このようにすればたとえば、カスタ
マの注文を外勤従業員を介在することなく処理することができる。
テムを接続することができる。図示されているように、本部ＨＯには外部システ
ムＢＷが配置されており、これはたとえばいわゆる "Business Information War
ehouse" として企業にとって重要な販売情報を分析する。これはデータベースＢ
Ｗ−ＤＢを有している。図示されている事例の場合、これはバックオフィスサー
バＯＬＴＰ−Ｒ／３からもＭＳシステムからもデータを受け取る。外勤フィール
ドＦＤにおいてたとえば、ネットワーク内の付加的なノードを成すカスタマシス
テム（Customer System）ＣＳを常に（オンライン）または一時的に（オフライ
ン）ＭＳシステムと接続することができる。このようにすればたとえば、カスタ
マの注文を外勤従業員を介在することなく処理することができる。
【００４４】
このように図示されているネットワークは種々のデータソース（モバイルクラ
イアントＭＣ、ＯＬＴＰ−Ｒ／３、オプションの外部システムＢＷおよびカスタ
マシステムＣＳ）を有しているが、それらは互いに独立していない。それらはＭ
Ｓシステムによって結合され、このシステムによれば各サブスクライバが自身に
必要とされる許された情報を受け取るようになる。図示されている事例の場合、
ミドルウェアサーバＭＳは同時にこのような結合機能も果たし、これとモバイル
クライアントから成るＣＲＭシステムの中央コンピュータを成しており、これは
オフライン分散型データベースシステムである。これが中央データベースシステ
ムＯＬＴＰ−Ｒ／３と融合される。しかしながら本発明の基本原理をデータベー
スシステム融合に関する他の事例にも適用可能であり、つまりたとえば、２つま
たは複数の中央データベースシステムの融合あるいは２つまたは複数の分散型デ
ータベースシステムの融合にも適用することができる。
イアントＭＣ、ＯＬＴＰ−Ｒ／３、オプションの外部システムＢＷおよびカスタ
マシステムＣＳ）を有しているが、それらは互いに独立していない。それらはＭ
Ｓシステムによって結合され、このシステムによれば各サブスクライバが自身に
必要とされる許された情報を受け取るようになる。図示されている事例の場合、
ミドルウェアサーバＭＳは同時にこのような結合機能も果たし、これとモバイル
クライアントから成るＣＲＭシステムの中央コンピュータを成しており、これは
オフライン分散型データベースシステムである。これが中央データベースシステ
ムＯＬＴＰ−Ｒ／３と融合される。しかしながら本発明の基本原理をデータベー
スシステム融合に関する他の事例にも適用可能であり、つまりたとえば、２つま
たは複数の中央データベースシステムの融合あるいは２つまたは複数の分散型デ
ータベースシステムの融合にも適用することができる。
【００４５】
ＭＳシステムのデータベースＭＳ−ＤＢには、その特有の機能（たとえばカス
タマリレーションシップマネージメント Customer Relationship Management CR
M）に必要とされるすべての情報が含まれている。これは統合データベースＣＤ
（consolidated data base）とも呼ばれる。なぜならばこれには（直前のデータ
交換時点で）ポータブルコンピュータにおけるすべてのローカルデータベースＬ
Ｄの内容が含まれているからである。これにより、ローカルデータベースＬＤに
必要なデータを供給して、たとえばデータの変更を伝達したり必要に応じてロー
カルデータベースＬＤをリストアすることができるようになる。
タマリレーションシップマネージメント Customer Relationship Management CR
M）に必要とされるすべての情報が含まれている。これは統合データベースＣＤ
（consolidated data base）とも呼ばれる。なぜならばこれには（直前のデータ
交換時点で）ポータブルコンピュータにおけるすべてのローカルデータベースＬ
Ｄの内容が含まれているからである。これにより、ローカルデータベースＬＤに
必要なデータを供給して、たとえばデータの変更を伝達したり必要に応じてロー
カルデータベースＬＤをリストアすることができるようになる。
【００４６】
ポータブルコンピュータは所定のインターバルで、実例として毎日夕方、たと
えば電話回線、インターネットまたはイントラネットを介して、ＭＳシステムと
接続される。この場合、直前の接続以来収集されたデータがＭＳシステムに伝送
される。しかもポータブルコンピュータはその機会に、それぞれ先行する期間に
おける自身の固有の処理データと、（必要なかぎり）他のポータブルコンピュー
タおよび別のシステムの新たな入力データを受け取る。
えば電話回線、インターネットまたはイントラネットを介して、ＭＳシステムと
接続される。この場合、直前の接続以来収集されたデータがＭＳシステムに伝送
される。しかもポータブルコンピュータはその機会に、それぞれ先行する期間に
おける自身の固有の処理データと、（必要なかぎり）他のポータブルコンピュー
タおよび別のシステムの新たな入力データを受け取る。
【００４７】
相互に接続されたシステムの有効データは（この実例ではカスタマやオーダな
ど業務処理に関連するので）ビジネスデータと呼ばれる。ＯＬＴＰ−Ｒ／３シス
テムの場合にはそこからビジネスオブジェクト（"BDoc"）が形成され、これは別
の処理のためのデータコンテナとして用いられる。たとえばある特定のオーダの
ためのビジネスオブジェクトはそのデータベース内に格納されているそのオーダ
に属するすべてのデータを有しており、これはそれらのデータがどのようにその
論理構造（リレーショナルデータベースのテーブル）内にあるかとは無関係であ
る。この構造はＯＬＴＰ−Ｒ／３システムにとって知られているものであり、同
じようにして他のバックオフィスシステムにも適用される。
ど業務処理に関連するので）ビジネスデータと呼ばれる。ＯＬＴＰ−Ｒ／３シス
テムの場合にはそこからビジネスオブジェクト（"BDoc"）が形成され、これは別
の処理のためのデータコンテナとして用いられる。たとえばある特定のオーダの
ためのビジネスオブジェクトはそのデータベース内に格納されているそのオーダ
に属するすべてのデータを有しており、これはそれらのデータがどのようにその
論理構造（リレーショナルデータベースのテーブル）内にあるかとは無関係であ
る。この構造はＯＬＴＰ−Ｒ／３システムにとって知られているものであり、同
じようにして他のバックオフィスシステムにも適用される。
【００４８】
関与するシステムにおいてビジネスデータを処理するのに必要とされる制御デ
ータは、個々のデータベースにおける論理的に別個の部分に格納されており、こ
れをレポジトリと称する。
ータは、個々のデータベースにおける論理的に別個の部分に格納されており、こ
れをレポジトリと称する。
【００４９】
ＯＬＴＰ−Ｒ／３システムへの伝送について、伝送基準は広範囲にわたりスタ
ティックである。これはひとたび設定されると、個々の企業における業務の流れ
の変更を比較的長い期間で変える必要がないかぎり、そのまま保持される。
ティックである。これはひとたび設定されると、個々の企業における業務の流れ
の変更を比較的長い期間で変える必要がないかぎり、そのまま保持される。
【００５０】
これに対し、ポータブルコンピュータへのデータ伝送は高度にダイナミックで
ある。たとえば特定の販売地区に対する外勤従業員の管轄は頻繁に変わる可能性
が多い。このような変更によってそのつどデータ伝送のための基準の変更が生じ
る。それというのも、それぞれ必要とされる最小データだけをポータブルコンピ
ュータへ伝送すべきだからである。同じ理由で、ポータブルコンピュータ内で古
くなったデータを消去しなければならず、他方、最近になって重要になったデー
タを追加する必要がある。データ伝送基準は有利には、ＭＳシステム内でいわゆ
るパブリケーション（publication）およびサブスクリプション（subscription
）として格納される。モバイルクライアントＭＣへの伝送基準およびデータの更
新プロセスを、以下ではリアライメント（realignment）と称する。
ある。たとえば特定の販売地区に対する外勤従業員の管轄は頻繁に変わる可能性
が多い。このような変更によってそのつどデータ伝送のための基準の変更が生じ
る。それというのも、それぞれ必要とされる最小データだけをポータブルコンピ
ュータへ伝送すべきだからである。同じ理由で、ポータブルコンピュータ内で古
くなったデータを消去しなければならず、他方、最近になって重要になったデー
タを追加する必要がある。データ伝送基準は有利には、ＭＳシステム内でいわゆ
るパブリケーション（publication）およびサブスクリプション（subscription
）として格納される。モバイルクライアントＭＣへの伝送基準およびデータの更
新プロセスを、以下ではリアライメント（realignment）と称する。
【００５１】
特定のデータは１つよりも多くのポータブルコンピュータにとって重要である
ので、ポータブルコンピュータへの伝送時にコピーする必要がある。１つよりも
多くの受信側へのこのような伝送を、以下ではレプリケーション（replication
）と称する。
ので、ポータブルコンピュータへの伝送時にコピーする必要がある。１つよりも
多くの受信側へのこのような伝送を、以下ではレプリケーション（replication
）と称する。
【００５２】
図２には、ＭＳシステムのアーキテクチャに関する概観が示されている。左側
にはモバイルクライアントＭＣが描かれ、下方にはＯＬＴＰ−Ｒ／３システムお
よび外部システムＢＷが描かれている。図の他の部分には、データベースＣＤお
よびそれに属するメッセージ伝送サーバ（Message Transfer Server）ＭＴＳを
含めてＭＳシステムが示されている。
にはモバイルクライアントＭＣが描かれ、下方にはＯＬＴＰ−Ｒ／３システムお
よび外部システムＢＷが描かれている。図の他の部分には、データベースＣＤお
よびそれに属するメッセージ伝送サーバ（Message Transfer Server）ＭＴＳを
含めてＭＳシステムが示されている。
【００５３】
ＭＳシステムは有利にはＲ／３テクノロジーをベースとして実装されている。
したがってその機能を複数のマシンに分散させることができ、たとえばデータベ
ースのために１つの別個のマシンを使用し、要求処理のために１つまたは複数の
マシンを使用することができる。メッセージ伝送サーバとして動作するマシンは
、全体としてアドミニストレーションステーション（アドミンステーション Adm
in Station）ＡＳと称する。メッセージ伝送サーバＭＴＳおよびそれに属するア
ドミニストレーションコンソール（アドミンコンソール Admin Console）ＡＣは
有利には、Windows NT （登録商標）によって動作する１つのマシンにインスト
ールされる。その結果生じる可能性のあるマシンの境界は図中、破線で描かれて
いる。
したがってその機能を複数のマシンに分散させることができ、たとえばデータベ
ースのために１つの別個のマシンを使用し、要求処理のために１つまたは複数の
マシンを使用することができる。メッセージ伝送サーバとして動作するマシンは
、全体としてアドミニストレーションステーション（アドミンステーション Adm
in Station）ＡＳと称する。メッセージ伝送サーバＭＴＳおよびそれに属するア
ドミニストレーションコンソール（アドミンコンソール Admin Console）ＡＣは
有利には、Windows NT （登録商標）によって動作する１つのマシンにインスト
ールされる。その結果生じる可能性のあるマシンの境界は図中、破線で描かれて
いる。
【００５４】
フロントオフィスシステムにおけるデータの伝送のためにデータコンテナが使
用され、これをＢＤｏｃと称する。これはモバイルクライアントＭＣとＭＳシス
テムとの間の通信にも用いられる。この場合、様々な種類のＢＤｏｃを区別する
ことができる： −ポータブルコンピュータＭＣとフロントオフィスサーバＣＲＭ−ＭＳとの間で
トランザクション結果とステータス情報を伝送するため、トランザクションＢＤ
ｏｃが使用される。それらを以下のようにさらに区別することができる： トランザクションＢＤｏｃはトランザクション結果をモバイルクライアントＭ
ＣからＭＳシステムへ搬送する。この場合、モバイルクライアントがＢＤｏｃを
成し、これはトランザクションの結果を有しており、それをＭＳシステムへ送信
する。
用され、これをＢＤｏｃと称する。これはモバイルクライアントＭＣとＭＳシス
テムとの間の通信にも用いられる。この場合、様々な種類のＢＤｏｃを区別する
ことができる： −ポータブルコンピュータＭＣとフロントオフィスサーバＣＲＭ−ＭＳとの間で
トランザクション結果とステータス情報を伝送するため、トランザクションＢＤ
ｏｃが使用される。それらを以下のようにさらに区別することができる： トランザクションＢＤｏｃはトランザクション結果をモバイルクライアントＭ
ＣからＭＳシステムへ搬送する。この場合、モバイルクライアントがＢＤｏｃを
成し、これはトランザクションの結果を有しており、それをＭＳシステムへ送信
する。
【００５５】
承認ＢＤｏｃ（Confirmation BDoc）は、ＭＳシステムによるトランザクショ
ンＢＤｏｃの処理成功を表す。トランザクションＢＤｏｃの処理がうまくいった
ならば、ＢＤｏｃのステータスがそれ相応に変化し、それを送ったモバイルクラ
イアントへ承認メッセージとしてＢＤｏｃが送り戻される。この承認メッセージ
には、たとえばＯＬＴＰ−Ｒ／３システムによって提供された付加的なデータあ
るいは統合データベースＣＤの変更された値も含まれている。その際、承認ＢＤ
ｏｃには、変更された値だけまたはすべての値が含まれている。
ンＢＤｏｃの処理成功を表す。トランザクションＢＤｏｃの処理がうまくいった
ならば、ＢＤｏｃのステータスがそれ相応に変化し、それを送ったモバイルクラ
イアントへ承認メッセージとしてＢＤｏｃが送り戻される。この承認メッセージ
には、たとえばＯＬＴＰ−Ｒ／３システムによって提供された付加的なデータあ
るいは統合データベースＣＤの変更された値も含まれている。その際、承認ＢＤ
ｏｃには、変更された値だけまたはすべての値が含まれている。
【００５６】
インポートＢＤｏｃは、他のモバイルクライアントＭＣまたは外部のシステム
のトランザクション結果をＭＳシステムからモバイルクライアントＭＣへ伝送す
る。インポートＢＤｏｃにも、変更された値だけがまたはすべての値が含まれて
いる。さらにインポートＢＤｏｃは、モバイルクライアントＭＣとは別のソース
からのデータ変更をＭＳシステムからモバイルクライアントへ伝送するためにも
利用される。
のトランザクション結果をＭＳシステムからモバイルクライアントＭＣへ伝送す
る。インポートＢＤｏｃにも、変更された値だけがまたはすべての値が含まれて
いる。さらにインポートＢＤｏｃは、モバイルクライアントＭＣとは別のソース
からのデータ変更をＭＳシステムからモバイルクライアントへ伝送するためにも
利用される。
【００５７】
エラーＢＤｏｃ（Error BDoc）は、トランザクションＢＤｏｃの処理にあたり
ＭＳシステムにおいてエラーの発生したことを表す。この場合、エラーセグメン
トがＢＤｏｃに挿入され、送信を行ったモバイルクライアントＭＣへエラーＢＤ
ｏｃとして送り戻される。エラーセグメントは、種々のエラー状態を表示するた
めに種々のレコードを有することができる。さらにエラーＢＤｏｃには、「先行
の状態のイメージ」（before images）としてもとの値も含まれている。すべて
のフィールドは、統合データベースＣＤの目下の内容で満たされている。
ＭＳシステムにおいてエラーの発生したことを表す。この場合、エラーセグメン
トがＢＤｏｃに挿入され、送信を行ったモバイルクライアントＭＣへエラーＢＤ
ｏｃとして送り戻される。エラーセグメントは、種々のエラー状態を表示するた
めに種々のレコードを有することができる。さらにエラーＢＤｏｃには、「先行
の状態のイメージ」（before images）としてもとの値も含まれている。すべて
のフィールドは、統合データベースＣＤの目下の内容で満たされている。
【００５８】
−サービス指向ＢＤｏｃは、ＭＳシステムからポータブルコンピュータＭＣへバ
イナリデータを伝送するために使用される。
イナリデータを伝送するために使用される。
【００５９】
−バルク指向ＢＤｏｃ（Bulk oriented BDoc）は、たとえば初回のデータダウン
ロード時などにＭＳシステムからモバイルクライアントＭＣへ大量のデータを伝
送するために使用される。
ロード時などにＭＳシステムからモバイルクライアントＭＣへ大量のデータを伝
送するために使用される。
【００６０】
さらにＢＤｏｃは、搬送された内容に関して種々のＢＤｏｃに細分化すること
ができる。ＢＤｏｃをたとえば「カスタマ」、「オーダ」などとすることができ
る。
ができる。ＢＤｏｃをたとえば「カスタマ」、「オーダ」などとすることができ
る。
【００６１】
ＢＤｏｃおよび殊にその構造についての詳細な説明はあとで行うことにする。
【００６２】
ＭＳシステムにおけるデータ処理は、「サービス」もしくは「アダプタ」と呼
ばれるファンクションモジュールを用いて行われる。サービスは、ＢＤｏｃに適
用できる特別なファンクションを提供する。アダプタは特殊なタイプのサービス
であり、これによればＭＳシステム外におけるシステムとのコネクションが可能
となる。
ばれるファンクションモジュールを用いて行われる。サービスは、ＢＤｏｃに適
用できる特別なファンクションを提供する。アダプタは特殊なタイプのサービス
であり、これによればＭＳシステム外におけるシステムとのコネクションが可能
となる。
【００６３】
モバイルクライントＭＳとミドルウェアサーバＭＳとの通信もそれらのローカ
ルデータベースＬＤとの通信も、もっぱらトランザクション層（Transaction La
yer）ＴＬを介して行われる。パートレプリケートデータベースネットワークシ
ステム（part-replicated data base network system）の実例としてのミドルウ
ェアサーバＭＳとモバイルクライアントとのデータ交換にについての詳細は、国
際出願 PCT/DE00/01552 に示されており、これを本出願の参考文献とする。
ルデータベースＬＤとの通信も、もっぱらトランザクション層（Transaction La
yer）ＴＬを介して行われる。パートレプリケートデータベースネットワークシ
ステム（part-replicated data base network system）の実例としてのミドルウ
ェアサーバＭＳとモバイルクライアントとのデータ交換にについての詳細は、国
際出願 PCT/DE00/01552 に示されており、これを本出願の参考文献とする。
【００６４】
図２には描かれているＭＳシステムにおける各コンポーネントの機能は、以下
のような特徴を有している。
のような特徴を有している。
【００６５】
メッセージ伝送サーバＭＴＳはモバイルクライアントＭＣからＢＤｏｃを受け
取り、ＢＤｏｃをそのモバイルクライアントに伝送する。データ伝送はそれぞれ
１つのモバイルクライアントＭＣによって導入される。たとえばその目的で、Mi
crosoft の通信テクノロジーＤＣＯＭを利用することができる。
取り、ＢＤｏｃをそのモバイルクライアントに伝送する。データ伝送はそれぞれ
１つのモバイルクライアントＭＣによって導入される。たとえばその目的で、Mi
crosoft の通信テクノロジーＤＣＯＭを利用することができる。
【００６６】
モバイルクライアントＭＣからＭＳシステムへのＢＤｏｃの伝送は到来メッセ
ージ用アダプタ（Inbound Message Adapter）ＩＭＡによって行われる一方、逆
方向で伝送されるメッセージは送出メッセージ用アダプタ（Outbound Message A
dapter）ＯＭＡによって伝送される。このようなデータ伝送は、ｑＲＦＣ（queu
ed Remote Function Call）と称するプロトコルによって行われる。これは処理
の順序を決定するためにキュー（queue）を利用するリモートファンクションコ
ールプロトコルである。
ージ用アダプタ（Inbound Message Adapter）ＩＭＡによって行われる一方、逆
方向で伝送されるメッセージは送出メッセージ用アダプタ（Outbound Message A
dapter）ＯＭＡによって伝送される。このようなデータ伝送は、ｑＲＦＣ（queu
ed Remote Function Call）と称するプロトコルによって行われる。これは処理
の順序を決定するためにキュー（queue）を利用するリモートファンクションコ
ールプロトコルである。
【００６７】
ＭＳシステムの中央コンポーネントはフローコントロール（Flow Control）Ｆ
Ｃである。フローコントロールＦＣはＢＤｏｃの処理を行い、到来するＢＤｏｃ
を適正な順序でサービスおよびアダプタへルーティングし、必要であればエラー
処理プロシージャをトリガする。これはすべてのサービスおよびアダプタに対し
同じインタフェースを介して行われる。他方、このインタフェースにおけるメイ
ンパラメータはＢＤｏｃである。フローはＢＤｏｃタイプ固有に制御データメモ
リ（レポジトリ Repository）内で定義されている。
Ｃである。フローコントロールＦＣはＢＤｏｃの処理を行い、到来するＢＤｏｃ
を適正な順序でサービスおよびアダプタへルーティングし、必要であればエラー
処理プロシージャをトリガする。これはすべてのサービスおよびアダプタに対し
同じインタフェースを介して行われる。他方、このインタフェースにおけるメイ
ンパラメータはＢＤｏｃである。フローはＢＤｏｃタイプ固有に制御データメモ
リ（レポジトリ Repository）内で定義されている。
【００６８】
ＯＬＴＰ−Ｒ／３システムおよびＢＷシステムなど外部のシステムは、それぞ
れ固有のアダプタＯＬＴＰ−ＡＤもしくはＢＷ−ＡＤを介してＭＳシステムと接
続されている。つまり外部システムはやはり各々固有のアダプタタイプをもって
おり、これもＢＤｏｃ固有にレポジトリ内に定義されている。アダプタおよびそ
れに接続された外部システムとの間のデータ伝送チャネルのプロトコルおよびデ
ータ構造は、外部システムのタイプに固有のものである。
れ固有のアダプタＯＬＴＰ−ＡＤもしくはＢＷ−ＡＤを介してＭＳシステムと接
続されている。つまり外部システムはやはり各々固有のアダプタタイプをもって
おり、これもＢＤｏｃ固有にレポジトリ内に定義されている。アダプタおよびそ
れに接続された外部システムとの間のデータ伝送チャネルのプロトコルおよびデ
ータ構造は、外部システムのタイプに固有のものである。
【００６９】
データベースサービス（Consolidated Database Service）ＣＤＳは、統合デ
ータベース（consolidated database）ＣＤに相応のデータを格納するために用
いられる。このサービスＣＤＳは、データをデータベースに書き込むときにデー
タ一致性のチェックを実行しない。そのようなチェックは、データをＭＳシステ
ムへ伝送するコンポーネント（たとえばモバイルクライアントＭＣまたはＯＬＴ
Ｐ−Ｒ／３システム）によって実行する必要がある。データベースＣＤの読み出
しのため他のサービスはサービスＣＤＳを利用するのではなく、図示されていな
い特別なハンドラを利用し、これはサービス、アダプタまたは他のハンドラから
呼び出される。
ータベース（consolidated database）ＣＤに相応のデータを格納するために用
いられる。このサービスＣＤＳは、データをデータベースに書き込むときにデー
タ一致性のチェックを実行しない。そのようなチェックは、データをＭＳシステ
ムへ伝送するコンポーネント（たとえばモバイルクライアントＭＣまたはＯＬＴ
Ｐ−Ｒ／３システム）によって実行する必要がある。データベースＣＤの読み出
しのため他のサービスはサービスＣＤＳを利用するのではなく、図示されていな
い特別なハンドラを利用し、これはサービス、アダプタまたは他のハンドラから
呼び出される。
【００７０】
レプリケーションおよびリアライメントモジュールＲＰＭは２つの主要な役割
をもっている。レプリケーションパートは処理されたＢＤｏｃを引き継ぎ、その
受け取り側を決定する。いっそう迅速に処理するため、そのために必要とされる
情報がルックアップテーブルから読み出される。目下処理されているＢＤｏｃに
基づきルックアップ情報の変更の必要性をレプリケーションパートが確認すると
、そのレプリケーションパートはリアライメントハンドラをトリガする。リアラ
イメントハンドラはレプリケーションルールを評価して、必要とされるルックア
ップ情報を生成する。さらにリアライメントハンドラは受け取り側に対し新たな
データを提供し、不必要なデータを消去する命令を出す。この目的でリアライメ
ントハンドラは特別なハンドラを用いる。
をもっている。レプリケーションパートは処理されたＢＤｏｃを引き継ぎ、その
受け取り側を決定する。いっそう迅速に処理するため、そのために必要とされる
情報がルックアップテーブルから読み出される。目下処理されているＢＤｏｃに
基づきルックアップ情報の変更の必要性をレプリケーションパートが確認すると
、そのレプリケーションパートはリアライメントハンドラをトリガする。リアラ
イメントハンドラはレプリケーションルールを評価して、必要とされるルックア
ップ情報を生成する。さらにリアライメントハンドラは受け取り側に対し新たな
データを提供し、不必要なデータを消去する命令を出す。この目的でリアライメ
ントハンドラは特別なハンドラを用いる。
【００７１】
ＭＳサーバをカスタマ固有に整合するため（カスタマイズするため）、および
論理的なデータの流れについてシステム全体を管理するために、アドミニストレ
ーションコンソールＡＣが利用される。
論理的なデータの流れについてシステム全体を管理するために、アドミニストレ
ーションコンソールＡＣが利用される。
【００７２】
図３にはデータアップロードオペレーションの実例として、ＭＳシステムにお
けるフローコントロールの典型的な流れが示されている。この場合、フローコン
トロールＦＣのメッセージプロセッサ（Message Processer）ＭＰによって実行
されるステップが、ＭＰ−ＦＣと付された列に描かれている。第１および第３の
列には、サービスにより実行される処理ステップが示されている。最後の列には
、ＯＬＴＰ−Ｒ／３システムによって実行される処理ステップが示されている。
けるフローコントロールの典型的な流れが示されている。この場合、フローコン
トロールＦＣのメッセージプロセッサ（Message Processer）ＭＰによって実行
されるステップが、ＭＰ−ＦＣと付された列に描かれている。第１および第３の
列には、サービスにより実行される処理ステップが示されている。最後の列には
、ＯＬＴＰ−Ｒ／３システムによって実行される処理ステップが示されている。
【００７３】
この流れは、新たなＢＤｏｃを受け取ったため、メッセージ伝送サーバＭＴＣ
が（ＲＦＣを介して）到来メッセージＩＭＡのためのアダプタを呼び出したとき
に始まる。到来メッセージＩＭＡのためのアダプタによってメッセージプロセッ
サＭＰ−ＦＣがスタートする。
が（ＲＦＣを介して）到来メッセージＩＭＡのためのアダプタを呼び出したとき
に始まる。到来メッセージＩＭＡのためのアダプタによってメッセージプロセッ
サＭＰ−ＦＣがスタートする。
【００７４】
実行すべき流れはメッセージプロセッサＭＰによって決定される。この場合、
基本的に２つのフロープロシージャを区別することができ、１つは少なくとも部
分的にＯＬＴＰ−Ｒ／３システムに関連するＢＤｏｃタイプの処理のためのもの
であり、１つはその他のＢＤｏｃ（ＭＳシステム内でのみ巡回する）のためのも
のである。
基本的に２つのフロープロシージャを区別することができ、１つは少なくとも部
分的にＯＬＴＰ−Ｒ／３システムに関連するＢＤｏｃタイプの処理のためのもの
であり、１つはその他のＢＤｏｃ（ＭＳシステム内でのみ巡回する）のためのも
のである。
【００７５】
個々のＢＤｏｃタイプのためにレポジトリに格納されているフロー定義に依存
して、メッセージプロセッサＭＰは呼び出される第１のサービスもしくはアダプ
タを決定する。（少なくとも部分的に）ＯＬＴＰ−Ｒ／３システムに関連するＢ
Ｄｏｃのタイプのために、第１のサービスとしてＯＬＴＰ−Ｒ／３アダプタＯＬ
ＴＰ−ＡＤが呼び出される。その他のＢＤｏｃのためにはＯＬＴＰ−Ｒ／３アダ
プタは呼び出されない。ＢＤｏｃのタイプのためにＯＬＴＰ−Ｒ／３アダプタを
呼び出すか否かの判定は、フローの決定時に下されており、つまりこのフロー内
では下されない。
して、メッセージプロセッサＭＰは呼び出される第１のサービスもしくはアダプ
タを決定する。（少なくとも部分的に）ＯＬＴＰ−Ｒ／３システムに関連するＢ
Ｄｏｃのタイプのために、第１のサービスとしてＯＬＴＰ−Ｒ／３アダプタＯＬ
ＴＰ−ＡＤが呼び出される。その他のＢＤｏｃのためにはＯＬＴＰ−Ｒ／３アダ
プタは呼び出されない。ＢＤｏｃのタイプのためにＯＬＴＰ−Ｒ／３アダプタを
呼び出すか否かの判定は、フローの決定時に下されており、つまりこのフロー内
では下されない。
【００７６】
ＯＬＴＰ−Ｒ／３アダプタＯＬＴＰ−ＡＤが呼び出されるとそのアダプタは、
ＢＤｏｃが本当にＯＬＴＰ−Ｒ／３システムに関連するものなのかを決定する。
このことは必ずしもあてはまらない。それというのもＯＬＴＰ−Ｒ／３システム
に対する関連性はＢＤｏｃにのみ左右されるのではなく、その内容にも左右され
る可能性があるからである。１つの実例は、ビジネスオブジェクトタイプ「カス
タマ」のＢＤｏｃである。このようなＢＤｏｃにカスタマに関する情報が含まれ
ているならば、それはＯＬＴＰ−Ｒ／３システムへ送られるが、販売渉外担当（
sales and distribution contact）に関する情報が含まれているなら、それはＭ
Ｓシステム内にしか格納されない。
ＢＤｏｃが本当にＯＬＴＰ−Ｒ／３システムに関連するものなのかを決定する。
このことは必ずしもあてはまらない。それというのもＯＬＴＰ−Ｒ／３システム
に対する関連性はＢＤｏｃにのみ左右されるのではなく、その内容にも左右され
る可能性があるからである。１つの実例は、ビジネスオブジェクトタイプ「カス
タマ」のＢＤｏｃである。このようなＢＤｏｃにカスタマに関する情報が含まれ
ているならば、それはＯＬＴＰ−Ｒ／３システムへ送られるが、販売渉外担当（
sales and distribution contact）に関する情報が含まれているなら、それはＭ
Ｓシステム内にしか格納されない。
【００７７】
ＢＤｏｃがＯＬＴＰ−Ｒ／３システムに関連するとＯＬＴＰ−Ｒ／３アダプタ
が判定したならば、そのアダプタはそれに対してコールを送り、進行中のフロー
を中断する。ＯＬＴＰ−Ｒ／３システムにおける処理の終了後、それによってＯ
ＬＴＰ−Ｒ／３アダプタへコールが送られ、そのアダプタは結果を引き継ぎ、フ
ローを再びスタートさせて、フローコントロールＦＣのメッセージプロセッサＭ
Ｐを呼び出す。
が判定したならば、そのアダプタはそれに対してコールを送り、進行中のフロー
を中断する。ＯＬＴＰ−Ｒ／３システムにおける処理の終了後、それによってＯ
ＬＴＰ−Ｒ／３アダプタへコールが送られ、そのアダプタは結果を引き継ぎ、フ
ローを再びスタートさせて、フローコントロールＦＣのメッセージプロセッサＭ
Ｐを呼び出す。
【００７８】
メッセージプロセッサＭＰ−ＦＣは、どのサービスを次に呼び出すべきである
のかを決定する。ＢＤｏｃがＯＬＴＰ−Ｒ／３システムに関連していないことを
ＯＬＴＰ−Ｒ／３アダプタが検出すると、そのアダプタはメッセージプロセッサ
ＭＰ−ＦＣへコントロールを戻し、この場合もそのプロセッサは次に呼び出すべ
きサービスを決定する。
のかを決定する。ＢＤｏｃがＯＬＴＰ−Ｒ／３システムに関連していないことを
ＯＬＴＰ−Ｒ／３アダプタが検出すると、そのアダプタはメッセージプロセッサ
ＭＰ−ＦＣへコントロールを戻し、この場合もそのプロセッサは次に呼び出すべ
きサービスを決定する。
【００７９】
通常、ＯＬＴＰ−Ｒ／３アダプタのあとにデータベースサービスＣＤＳが呼び
出される。このサービスは、ＢＤｏｃに含まれているデータを統合データベース
ＣＤ内で持続させる。
出される。このサービスは、ＢＤｏｃに含まれているデータを統合データベース
ＣＤ内で持続させる。
【００８０】
データが首尾よく統合データベースＣＤ内に書き込まれると、通常はレプリケ
ーションおよびリアライメントサービスＲＰＭが呼び出される。このサービスの
機能は、ＢＤｏｃがレプリケーション情報に作用を及ぼすか否かをチェックする
ことである。作用を及ぼすのであればリアライメントハンドラに対し、ルックア
ップ情報を更新しビジネスデータ分配のためにＢＤｏｃを生成するオーダが形成
される。レプリケーションおよびリアライメントサービスＲＰＭの第２のアクシ
ョンは、目下のＢＤｏｃに受け取り側リストを追加することである。
ーションおよびリアライメントサービスＲＰＭが呼び出される。このサービスの
機能は、ＢＤｏｃがレプリケーション情報に作用を及ぼすか否かをチェックする
ことである。作用を及ぼすのであればリアライメントハンドラに対し、ルックア
ップ情報を更新しビジネスデータ分配のためにＢＤｏｃを生成するオーダが形成
される。レプリケーションおよびリアライメントサービスＲＰＭの第２のアクシ
ョンは、目下のＢＤｏｃに受け取り側リストを追加することである。
【００８１】
さらに、メッセージ伝送サービスＭＴＳによりＢＤｏｃをその受け取り側へ伝
達するために準備処理する目的で、送出メッセージＯＭＡ用のアダプタが呼び出
される。
達するために準備処理する目的で、送出メッセージＯＭＡ用のアダプタが呼び出
される。
【００８２】
アップロードが失敗した場合にはリジェクトサービスＲＳが呼び出される。Ｂ
ＤｏｃはエラーＢＤｏｃとして（つまりエラー情報を含むＢＤｏｃとして）マー
キングされる。アップデートオペレーションにおいてリジェクトサービスは有効
な値を統合データベースＣＤから読み出す。すべてのオペレーションにおいて、
モバイルクライアントＭＣの先行の状態がマークされる。ついでＢＤｏｃは、そ
れを送ってきたポータブルコンピュータへ送り戻される。そこにおいて相応のト
ランザクションが新たに実行される。
ＤｏｃはエラーＢＤｏｃとして（つまりエラー情報を含むＢＤｏｃとして）マー
キングされる。アップデートオペレーションにおいてリジェクトサービスは有効
な値を統合データベースＣＤから読み出す。すべてのオペレーションにおいて、
モバイルクライアントＭＣの先行の状態がマークされる。ついでＢＤｏｃは、そ
れを送ってきたポータブルコンピュータへ送り戻される。そこにおいて相応のト
ランザクションが新たに実行される。
【００８３】
図３には（リジェクトサービスＲＳを除いて）成功経路だけが書き込まれてい
る。当然ながらエラー処理ルーチンも設けられているが、それについてはここで
は詳しく説明しない。
る。当然ながらエラー処理ルーチンも設けられているが、それについてはここで
は詳しく説明しない。
【００８４】
次に、図４を参照しながらＢＤｏｃの構造について詳しく説明する。この図の
上部にはＢＤｏｃタイプの定義構造が示されており、これはＭＳシステムのレポ
ジトリに格納されている。さらに下部には、同様にレポジトリ内に格納されてい
るＢＤｏｃ自体の構造が描かれている。
上部にはＢＤｏｃタイプの定義構造が示されており、これはＭＳシステムのレポ
ジトリに格納されている。さらに下部には、同様にレポジトリ内に格納されてい
るＢＤｏｃ自体の構造が描かれている。
【００８５】
ＢＤｏｃは、ＢＤｏｃヘッダＢＤｏｃ−ＨおよびＢＤｏｃボディＢＤｏｃ−Ｂ
から成る。ＢＤｏｃヘッダＢＤｏｃヘッダ−Ｈにはコントロール情報が含まれて
おり、たとえばＢＤｏｃのタイプ（「カスタマ」、「オーダ」．．．）、その送
り手（モバイルクライアントＭＣ）ならびにタイムスタンプなどが含まれている
。さらにプライマリキーの複製も含まれていると、パフォーマンスの理由から有
利である。
から成る。ＢＤｏｃヘッダＢＤｏｃヘッダ−Ｈにはコントロール情報が含まれて
おり、たとえばＢＤｏｃのタイプ（「カスタマ」、「オーダ」．．．）、その送
り手（モバイルクライアントＭＣ）ならびにタイムスタンプなどが含まれている
。さらにプライマリキーの複製も含まれていると、パフォーマンスの理由から有
利である。
【００８６】
ＢＤｏｃボディＢＤｏｃ−Ｂにはデータが含まれている。データレコード（Da
ta Record）ＤＲには本来のデータが含まれている。この構造は属するデータセ
グメント（Data Segment）ＤＳの定義中で規定されている。このセグメントは、
実際の物理的なテーブルにおける一種のテーブルビューを成している。オプショ
ンとしてＢＤｏｃにはさらに、１つまたは複数のエラーレコードＥＲ（Error Re
cord）をもつエラーセグメントＥＳも含まれる。
ta Record）ＤＲには本来のデータが含まれている。この構造は属するデータセ
グメント（Data Segment）ＤＳの定義中で規定されている。このセグメントは、
実際の物理的なテーブルにおける一種のテーブルビューを成している。オプショ
ンとしてＢＤｏｃにはさらに、１つまたは複数のエラーレコードＥＲ（Error Re
cord）をもつエラーセグメントＥＳも含まれる。
【００８７】
各データ領域は規定の長さをもっている。それらの領域はキーとデータフィー
ルドから成る。それらの領域に消去情報が含まれているならば、キーフィールド
だけに有効なデータが含まれている。また、それらの領域に「インサート」情報
または「アップデート」情報が含まれているならば、すべてのデータフィールド
に有効なデータが含まれているかまたは、変更されていないフィールドにプリセ
ット値（たとえば０．０）が含まれている。フィールドが満たされているのか利
用されていないのかを表す目的で、いわゆる「送信ビット」が使用される。この
場合、レプリケーションおよびリアライメントにあたり考慮しなければならない
プライマリキーとフィールドが常に（変更された否かとは無関係に）送られる。
送信ビットがセットされるのは、値が実際に変更されたときだけである。
ルドから成る。それらの領域に消去情報が含まれているならば、キーフィールド
だけに有効なデータが含まれている。また、それらの領域に「インサート」情報
または「アップデート」情報が含まれているならば、すべてのデータフィールド
に有効なデータが含まれているかまたは、変更されていないフィールドにプリセ
ット値（たとえば０．０）が含まれている。フィールドが満たされているのか利
用されていないのかを表す目的で、いわゆる「送信ビット」が使用される。この
場合、レプリケーションおよびリアライメントにあたり考慮しなければならない
プライマリキーとフィールドが常に（変更された否かとは無関係に）送られる。
送信ビットがセットされるのは、値が実際に変更されたときだけである。
【００８８】
ＢＤｏｃタイプの定義つまり階層的におかれた要素から成る個々のＢＤｏｃタ
イプ固有の構造に関する情報ＢＤｏｃは、ＢＤｏｃタイプの定義（"BDoc Type D
efinition"）内に含まれており、これはＢＤｏｃボディ定義ＢＤｏｃ−ＢＤとＢ
Ｄｏｃセグメント定義ＢＤｏｃ−ＳＤから成る。ＢＤｏｃボディ定義ＢＤｏｃ−
ＢＤは正確に１つのルートセグメントを有しており、これにはただ１つのデータ
レコードだけが含まれている。この条件は遵守しなければならず、その目的はＢ
Ｄｏｃ中に含まれている情報がそれぞれ個々のノードシステムへ伝達できるよう
にまたは別のやり方で処理できるようにするためである。たとえばタイプ「カス
タマ」のＢＤｏｃ中には、ただひとりのカスタマに関する情報だけしか格納して
はならず、そうすることによってカスタマ情報を個々に所期のように個々のカス
タマごとに相応のノードシステムへ導くことができるようになるからである。相
前後するセグメントのデータレコードには依存するデータが含まれており、たと
えばカスタマのマシン装備に関するデータなどが含まれている。当然ながらこの
場合、１つのセグメントに対し複数のレコードを設けることができる。
イプ固有の構造に関する情報ＢＤｏｃは、ＢＤｏｃタイプの定義（"BDoc Type D
efinition"）内に含まれており、これはＢＤｏｃボディ定義ＢＤｏｃ−ＢＤとＢ
Ｄｏｃセグメント定義ＢＤｏｃ−ＳＤから成る。ＢＤｏｃボディ定義ＢＤｏｃ−
ＢＤは正確に１つのルートセグメントを有しており、これにはただ１つのデータ
レコードだけが含まれている。この条件は遵守しなければならず、その目的はＢ
Ｄｏｃ中に含まれている情報がそれぞれ個々のノードシステムへ伝達できるよう
にまたは別のやり方で処理できるようにするためである。たとえばタイプ「カス
タマ」のＢＤｏｃ中には、ただひとりのカスタマに関する情報だけしか格納して
はならず、そうすることによってカスタマ情報を個々に所期のように個々のカス
タマごとに相応のノードシステムへ導くことができるようになるからである。相
前後するセグメントのデータレコードには依存するデータが含まれており、たと
えばカスタマのマシン装備に関するデータなどが含まれている。当然ながらこの
場合、１つのセグメントに対し複数のレコードを設けることができる。
【００８９】
セグメントがＢＤｏｃタイプの定義中で階層構造をとっているのに対し、ＢＤ
ｏｃの物理的な再生においてはそのような階層はない。階層関係は、依存するセ
グメントのデータレコードＤＲがそれらの上位のデータレコードのキーを有する
ことにより、ＢＤｏｃ内に収容されている。トランザクションＢＤｏｃの場合に
はさらに（エラーレコード Error Record ＥＲをもつオプションのエラーセグメ
ントを除いて）依存しないセグメントが設けられており、これをルートセグメン
トと称する。
ｏｃの物理的な再生においてはそのような階層はない。階層関係は、依存するセ
グメントのデータレコードＤＲがそれらの上位のデータレコードのキーを有する
ことにより、ＢＤｏｃ内に収容されている。トランザクションＢＤｏｃの場合に
はさらに（エラーレコード Error Record ＥＲをもつオプションのエラーセグメ
ントを除いて）依存しないセグメントが設けられており、これをルートセグメン
トと称する。
【００９０】
変更されたデータがＭＳシステムへ伝送される場合、モバイルクライアントＭ
Ｃが変更前に有していた値がＭＳシステムにとって重要である可能性がある。そ
のような「先行状態のイメージ」（before image）は固有のデータ領域に伝達さ
れ、それらは相応に特徴づけられている。
Ｃが変更前に有していた値がＭＳシステムにとって重要である可能性がある。そ
のような「先行状態のイメージ」（before image）は固有のデータ領域に伝達さ
れ、それらは相応に特徴づけられている。
【００９１】
外部のシステムＢＷおよびインストールファイルをモバイルクライアントＭＣ
へ伝送するために、サービス指向ＢＤｏｃが用いられる。サービス指向ＢＤｏｃ
のボディは、一般情報をもつルートセグメントとバイナリデータを含むメモセグ
メントから成る。
へ伝送するために、サービス指向ＢＤｏｃが用いられる。サービス指向ＢＤｏｃ
のボディは、一般情報をもつルートセグメントとバイナリデータを含むメモセグ
メントから成る。
【００９２】
バルク指向ＢＤｏｃは、モバイルクライントの最初のセットアップ（Initial
Client Setup）およびリアライメント中のデータ伝送のために使用される。バル
ク指向ＢＤｏｃもタイプ固有に（つまりたとえばオブジェクトタイプ「カスタマ
」などのために）定義されている。とはいえそれらは、そのルートセグメントに
ただ１つのレコードだけしか収容してはならない、という制約を受けない。した
がってたとえばバルク指向ＢＤｏｃは複数のカスタマのデータを一度に伝送する
ことができる。
Client Setup）およびリアライメント中のデータ伝送のために使用される。バル
ク指向ＢＤｏｃもタイプ固有に（つまりたとえばオブジェクトタイプ「カスタマ
」などのために）定義されている。とはいえそれらは、そのルートセグメントに
ただ１つのレコードだけしか収容してはならない、という制約を受けない。した
がってたとえばバルク指向ＢＤｏｃは複数のカスタマのデータを一度に伝送する
ことができる。
【００９３】
ＯＬＴＰ−Ｒ／３アダプタＯＬＴＰ−ＡＤは、ＯＬＴＰ−Ｒ／３システムをＭ
Ｓシステムとリンクする。これはデータを双方向で伝送するために用いられる。
データたとえばカスタマの注文がモバイルクライアントＭＣに入力され、ＯＬＴ
Ｐ−Ｒ／３システムに転送される場合、これを「アップロード」と呼ぶ。データ
がＯＬＴＰ−Ｒ／３システムに入力され、そこからＭＳシステムへ転送される場
合、これを「ダウンロード」と称する。
Ｓシステムとリンクする。これはデータを双方向で伝送するために用いられる。
データたとえばカスタマの注文がモバイルクライアントＭＣに入力され、ＯＬＴ
Ｐ−Ｒ／３システムに転送される場合、これを「アップロード」と呼ぶ。データ
がＯＬＴＰ−Ｒ／３システムに入力され、そこからＭＳシステムへ転送される場
合、これを「ダウンロード」と称する。
【００９４】
この場合、３つのタイプのダウンロードを区別することができる。初回のデー
タダウンロード（Initial Download）によって、ＭＳシステムの統合データベー
スＣＤはオペレーションの開始にあたりＯＬＴＰ−Ｒ／３システムからのデータ
で満たされる。オンラインユーザがデータをＯＬＴＰ−Ｒ／３システムへ入力し
、変更されたオブジェクトがＭＳシステムへ転送されるとき、デルタダウンロー
ドが行われる。このようなデルタダウンロードは、すべてのデータ形式について
可能なわけではない。これらの機能が利用できないならば、第３のダウンロード
メカニズムが使用され、これを以下では同期メカニズムと称する。
タダウンロード（Initial Download）によって、ＭＳシステムの統合データベー
スＣＤはオペレーションの開始にあたりＯＬＴＰ−Ｒ／３システムからのデータ
で満たされる。オンラインユーザがデータをＯＬＴＰ−Ｒ／３システムへ入力し
、変更されたオブジェクトがＭＳシステムへ転送されるとき、デルタダウンロー
ドが行われる。このようなデルタダウンロードは、すべてのデータ形式について
可能なわけではない。これらの機能が利用できないならば、第３のダウンロード
メカニズムが使用され、これを以下では同期メカニズムと称する。
【００９５】
図５には、アップロードおよびダウンロードにおいて有効なＭＳシステムおよ
びＯＬＴＰ−Ｒ／３システムのコンポーネントが示されている。ＭＳシステムの
構成部分は、ＢＤｏｃの処理に必要とされるプロセスステップをコーディネート
するためのフローコントロールＦＣ、ＯＬＴＰ−Ｒ／３アダプタＯＬＴＰ−ＡＤ
ならびに３つのエージェントであり、それらはキージェネレータ（Keygenerator
）ＫＧ、マッピングエージェントＭＡおよびマージエージェント（Merging-Agen
t）ＭＥＡと称する。これらのエージェントはＯＬＴＰ−Ｒ／３アダプタのため
の補助機能を果たす。
びＯＬＴＰ−Ｒ／３システムのコンポーネントが示されている。ＭＳシステムの
構成部分は、ＢＤｏｃの処理に必要とされるプロセスステップをコーディネート
するためのフローコントロールＦＣ、ＯＬＴＰ−Ｒ／３アダプタＯＬＴＰ−ＡＤ
ならびに３つのエージェントであり、それらはキージェネレータ（Keygenerator
）ＫＧ、マッピングエージェントＭＡおよびマージエージェント（Merging-Agen
t）ＭＥＡと称する。これらのエージェントはＯＬＴＰ−Ｒ／３アダプタのため
の補助機能を果たす。
【００９６】
ＭＳシステムの構成部分はスタンダードＢＡＰＩ（Business Application Pro
gramming Interface）ＳＢを呼び出すためのコールフレームＣＦであり、これは
ＢＤｏｃの処理中に呼び出すことができる。スタンダードＢＡＰＩは変更を持続
的なものにするため、アップデートファンクションモジュールＵＦＭを呼び出す
。
gramming Interface）ＳＢを呼び出すためのコールフレームＣＦであり、これは
ＢＤｏｃの処理中に呼び出すことができる。スタンダードＢＡＰＩは変更を持続
的なものにするため、アップデートファンクションモジュールＵＦＭを呼び出す
。
【００９７】
アップデータファンクションモジュールＵＦＭは変更のたびにイベントを発し
、これはイベントディストリビュータＥＤへ伝達される。このような伝達に対す
るリアクションとして、イベントディストリビュータはすべてのサブスクライバ
を始動させる。とりわけこれにより、サブスクライバとしてエントリされている
結果伝送部（Results Sender）ＲＳが呼び出される。そして変更されたデータは
結果伝送部ＲＳからＭＳシステムへ伝送される。１つのメモリ領域であるキーリ
ファレンス（Key Reference）ＫＲには、フロントオフィスシステムＭＳのキー
ＫＭＳとオブジェクトリファレンスＯＲが格納されている。また、１つのメモリ
領域である補助データ（Additional MS-Data）ＡＭＤには、ＯＬＴＰ−Ｒ／３シ
ステムにより搬送しなければならないがそれ自体にとっては重要ではないデータ
（たとえばフロントオフィスシステムのキーなど）が含まれている。ＭＳシステ
ムからはＯＬＴＰ−Ｒ／３システムへは、それに関連しないデータは伝送されな
い。
、これはイベントディストリビュータＥＤへ伝達される。このような伝達に対す
るリアクションとして、イベントディストリビュータはすべてのサブスクライバ
を始動させる。とりわけこれにより、サブスクライバとしてエントリされている
結果伝送部（Results Sender）ＲＳが呼び出される。そして変更されたデータは
結果伝送部ＲＳからＭＳシステムへ伝送される。１つのメモリ領域であるキーリ
ファレンス（Key Reference）ＫＲには、フロントオフィスシステムＭＳのキー
ＫＭＳとオブジェクトリファレンスＯＲが格納されている。また、１つのメモリ
領域である補助データ（Additional MS-Data）ＡＭＤには、ＯＬＴＰ−Ｒ／３シ
ステムにより搬送しなければならないがそれ自体にとっては重要ではないデータ
（たとえばフロントオフィスシステムのキーなど）が含まれている。ＭＳシステ
ムからはＯＬＴＰ−Ｒ／３システムへは、それに関連しないデータは伝送されな
い。
【００９８】
コールフレームＣＦおよび結果伝送部ＲＳだけが、ここで述べた機能のために
付加的にインプリメントされたＯＬＴＰ−Ｒ／３システムの構成部である。
付加的にインプリメントされたＯＬＴＰ−Ｒ／３システムの構成部である。
【００９９】
アップロードは以下のようにして行われる。ＭＳシステムにおいてＢＤｏｃが
処理される。この処理のステップとしてＯＬＴＰ−Ｒ／３アダプタが呼び出され
る。そしてこれは、ＢＤｏｃがＯＬＴＰ−Ｒ／３システムに関連するか否かにつ
いて判定する。関連するのであれば、ＢＡＰＩ呼出部ＢＣはそのＢＤｏｃをマー
クする。これにより保証されるのは、同じキュー内にある別のＢＤｏｃも処理さ
れないようにすることである。ＯＬＴＰ−Ｒ／３システムに関連のないその種の
ＢＤｏｃも必ずキュー内に存在する。その理由は、キュー内のＢＤｏｃと先行の
ＢＤｏｃとの依存性が場合によっては存在するからである。ＢＤｏｃの構造は、
ＯＬＴＰ−Ｒ／３システムの対応するＢＡＰＩのパラメータ構造にマッピングさ
れる。ついでそのＢＡＰＩのコールフレームがＯＬＴＰ−Ｒ／３システムにおい
て呼び出される。
処理される。この処理のステップとしてＯＬＴＰ−Ｒ／３アダプタが呼び出され
る。そしてこれは、ＢＤｏｃがＯＬＴＰ−Ｒ／３システムに関連するか否かにつ
いて判定する。関連するのであれば、ＢＡＰＩ呼出部ＢＣはそのＢＤｏｃをマー
クする。これにより保証されるのは、同じキュー内にある別のＢＤｏｃも処理さ
れないようにすることである。ＯＬＴＰ−Ｒ／３システムに関連のないその種の
ＢＤｏｃも必ずキュー内に存在する。その理由は、キュー内のＢＤｏｃと先行の
ＢＤｏｃとの依存性が場合によっては存在するからである。ＢＤｏｃの構造は、
ＯＬＴＰ−Ｒ／３システムの対応するＢＡＰＩのパラメータ構造にマッピングさ
れる。ついでそのＢＡＰＩのコールフレームがＯＬＴＰ−Ｒ／３システムにおい
て呼び出される。
【０１００】
コールフレームの第１の役割は二重の処理を避けることである。ＢＡＰＩに従
って新たなオブジェクトを生成しようという場合にコールフレームは、そのオブ
ジェクトがすでに存在していてＭＳシステムの相応の要求に応じて生成されてい
るかのかについてチェックする。そうであればビジネスオブジェクトの新たな生
成の代わりにすでに処理されたデータが抽出され、ＭＳシステムへ伝送されて戻
される。コールフレームの第２の役割は、ＭＳシステムにおけるキーおよびオブ
ジェクトリファレンスとＯＬＴＰ−Ｒ／３システムのキーおよびオブジェクトリ
ファレンスとの間で必要とされるマッピングを保証することである。さらに第３
の役割はコミットサイクルのハンドリングである。これにより、ただ１つのコミ
ットサイクルでＢＡＰＩ処理が実行されるようになる。その結果、バックオフィ
スシステムＯＬＴＰ−Ｒ／３へのデータの格納ならびにフロントオフィスシステ
ムＭＳへのデータの伝送が、１つの共通の処理単位で行われるようになる。
って新たなオブジェクトを生成しようという場合にコールフレームは、そのオブ
ジェクトがすでに存在していてＭＳシステムの相応の要求に応じて生成されてい
るかのかについてチェックする。そうであればビジネスオブジェクトの新たな生
成の代わりにすでに処理されたデータが抽出され、ＭＳシステムへ伝送されて戻
される。コールフレームの第２の役割は、ＭＳシステムにおけるキーおよびオブ
ジェクトリファレンスとＯＬＴＰ−Ｒ／３システムのキーおよびオブジェクトリ
ファレンスとの間で必要とされるマッピングを保証することである。さらに第３
の役割はコミットサイクルのハンドリングである。これにより、ただ１つのコミ
ットサイクルでＢＡＰＩ処理が実行されるようになる。その結果、バックオフィ
スシステムＯＬＴＰ−Ｒ／３へのデータの格納ならびにフロントオフィスシステ
ムＭＳへのデータの伝送が、１つの共通の処理単位で行われるようになる。
【０１０１】
コールフレームＣＦのメイン機能は、スタンダードＢＡＰＩ ＳＢを呼び出す
ことである。このためコールフレームは、それが受け取ったＢＤｏｃの構造を汎
用的なＢＡＰＩの構造に置き換えるために必要とされるすべての情報を有してい
る。ＢＡＰＩはＢＤｏｃのデータを処理し、アップデートファンクションモジュ
ールＵＦＭに対する呼び出しを有している。このファンクションモジュールは、
コールフレームがコミット命令をスタンダードＢＡＰＩへ出したときに稼働し始
める。アップデートファンクションモジュールはデータベースにおけるデータの
変更を持続的なものにする。さらにこのモジュールはイベントを発し、そのイベ
ントはイベントディストリビュータＥＤのサブスクライバへ分配される。これら
のサブスクライバの１つは結果伝送部ＲＳである。これは変更されたデータを発
せられたイベントのパラメータとして受け取り、それを結果データＡＭＤと混合
してそれをＭＳシステムへ伝送する。
ことである。このためコールフレームは、それが受け取ったＢＤｏｃの構造を汎
用的なＢＡＰＩの構造に置き換えるために必要とされるすべての情報を有してい
る。ＢＡＰＩはＢＤｏｃのデータを処理し、アップデートファンクションモジュ
ールＵＦＭに対する呼び出しを有している。このファンクションモジュールは、
コールフレームがコミット命令をスタンダードＢＡＰＩへ出したときに稼働し始
める。アップデートファンクションモジュールはデータベースにおけるデータの
変更を持続的なものにする。さらにこのモジュールはイベントを発し、そのイベ
ントはイベントディストリビュータＥＤのサブスクライバへ分配される。これら
のサブスクライバの１つは結果伝送部ＲＳである。これは変更されたデータを発
せられたイベントのパラメータとして受け取り、それを結果データＡＭＤと混合
してそれをＭＳシステムへ伝送する。
【０１０２】
ＭＳシステムにおいて、結果セーブエージェントＲＳＡは受け取った結果をＢ
Ｄｏｃ構造へマッピングして戻す。マージエージェントＭＥＡは、ＯＬＴＰ−Ｒ
／３システムから到来した結果をＭＳシステムにおけるＢＤｏｃと混合する。そ
の後、結果セーブエージェントＲＳＡはＢＤｏｃのためのフローコントロールを
開始し、ＢＤｏｃのステータスを変えて "OLTP Complete" とする。
Ｄｏｃ構造へマッピングして戻す。マージエージェントＭＥＡは、ＯＬＴＰ−Ｒ
／３システムから到来した結果をＭＳシステムにおけるＢＤｏｃと混合する。そ
の後、結果セーブエージェントＲＳＡはＢＤｏｃのためのフローコントロールを
開始し、ＢＤｏｃのステータスを変えて "OLTP Complete" とする。
【０１０３】
ＢＤｏｃを処理するためのフローコントロールについては、図３に基づく前述
の説明を補足的に参照されたい。
の説明を補足的に参照されたい。
【０１０４】
デルタダウンロード（じかにＯＬＴＰ−Ｒ／３システムに入力されその後ＭＳ
システムへ転送されたデータの伝送）は、アップロードと非常に似ている。図６
には、デルタダウンロードに基づき生じたＢＤｏｃの処理における完全なフロー
コントロールが示されている。このアーキテクチャは図５に対応している。
システムへ転送されたデータの伝送）は、アップロードと非常に似ている。図６
には、デルタダウンロードに基づき生じたＢＤｏｃの処理における完全なフロー
コントロールが示されている。このアーキテクチャは図５に対応している。
【０１０５】
ダイアローグプログラムＤＰを介してＯＬＴＰ−Ｒ／３システムとオンライン
で通信する内勤従業員ＩＨＥによって、ビジネスオブジェクトが生成される。ダ
イアローグプログラムＤＰはアップデートファンクションモジュールＵＦＭを呼
び出し、稼働し始める。アップデートモジュールはイベントを発し、結果伝送部
ＲＳはＭＳシステムにおける結果セーブエージェントを呼び出す。アップロード
プロセスとは異なり、結果伝送部ＲＳがＭＳシステムへ伝送しなければならない
ような付加的なＭＳデータは存在しない。たとえば新たに生成されたオブジェク
トのためのＭＳキーなどのように欠けているＭＳデータはキージェネレータＫＧ
によって生成され、キージェネレータ自体は結果セーブエージェントＲＳＡによ
ってトリガされる。ＯＬＴＰ−Ｒ／３システムから受け取ったデータに対し新た
なＢＤｏｃが生成され、図６に示されているように相応のコントロールフローを
実行するためフローコントロールがスタートする。
で通信する内勤従業員ＩＨＥによって、ビジネスオブジェクトが生成される。ダ
イアローグプログラムＤＰはアップデートファンクションモジュールＵＦＭを呼
び出し、稼働し始める。アップデートモジュールはイベントを発し、結果伝送部
ＲＳはＭＳシステムにおける結果セーブエージェントを呼び出す。アップロード
プロセスとは異なり、結果伝送部ＲＳがＭＳシステムへ伝送しなければならない
ような付加的なＭＳデータは存在しない。たとえば新たに生成されたオブジェク
トのためのＭＳキーなどのように欠けているＭＳデータはキージェネレータＫＧ
によって生成され、キージェネレータ自体は結果セーブエージェントＲＳＡによ
ってトリガされる。ＯＬＴＰ−Ｒ／３システムから受け取ったデータに対し新た
なＢＤｏｃが生成され、図６に示されているように相応のコントロールフローを
実行するためフローコントロールがスタートする。
【０１０６】
生産的オペレーションの開始前にＭＳシステムのデータベースＣＤを満たすた
めに、初回のデータダウンロード（Initial Download）が必要とされる。ダウン
ロードすべきビジネスオブジェクトクラスは、カスタマ固有のシステム整合中に
決定される。しかもビジネスオブジェクトのインスタンスを、特定の属性値に依
存してフィルタリングすることができる。ついで、固有の出口（カスタマイクジ
ット Customer Exit）を利用することができる。
めに、初回のデータダウンロード（Initial Download）が必要とされる。ダウン
ロードすべきビジネスオブジェクトクラスは、カスタマ固有のシステム整合中に
決定される。しかもビジネスオブジェクトのインスタンスを、特定の属性値に依
存してフィルタリングすることができる。ついで、固有の出口（カスタマイクジ
ット Customer Exit）を利用することができる。
【０１０７】
図７には、初回データダウンロードのために用いられるコンポーネントが示さ
れている。初回データダウンロードドリガエージェント（Initial Download Tri
gger Agent）ＩＤＴＡはプロダクションフェーズ開始前、初回データダウンロー
ドを導入するためシステムアドミニストレータによって始められる。初回データ
ダウンロードトリガエージェントは、ＯＬＴＰダウンロードトリガエージェント
（OLTP Download Trigger Agent）ＯＤＴＡを呼び出す。トリガはｑＲＦＣによ
って引き起こされる。これにより、初回データダウンロードアクションが正確に
１度実行されるようになる。ＯＬＴＰダウンロードトリガエージェントＯＤＴＡ
は、選択されたビジネスオブジェクトクラスに対し抽出部マスタＥＭを呼び出し
、さらにこの抽出部マスタ自身はＲ／３抽出部ＥＸＴを呼び出す。抽出部マスタ
ＥＭと抽出部ＥＸＴの相違点は、抽出部マスタはＭＳシステムとの共働に固有に
適合されたコンポーネントであるのに対し、抽出部ＥＸＴはＯＬＴＰ−Ｒ／３シ
ステム内の他の関連においても使用される。
れている。初回データダウンロードドリガエージェント（Initial Download Tri
gger Agent）ＩＤＴＡはプロダクションフェーズ開始前、初回データダウンロー
ドを導入するためシステムアドミニストレータによって始められる。初回データ
ダウンロードトリガエージェントは、ＯＬＴＰダウンロードトリガエージェント
（OLTP Download Trigger Agent）ＯＤＴＡを呼び出す。トリガはｑＲＦＣによ
って引き起こされる。これにより、初回データダウンロードアクションが正確に
１度実行されるようになる。ＯＬＴＰダウンロードトリガエージェントＯＤＴＡ
は、選択されたビジネスオブジェクトクラスに対し抽出部マスタＥＭを呼び出し
、さらにこの抽出部マスタ自身はＲ／３抽出部ＥＸＴを呼び出す。抽出部マスタ
ＥＭと抽出部ＥＸＴの相違点は、抽出部マスタはＭＳシステムとの共働に固有に
適合されたコンポーネントであるのに対し、抽出部ＥＸＴはＯＬＴＰ−Ｒ／３シ
ステム内の他の関連においても使用される。
【０１０８】
抽出部マスタによって引き継がれたフィルタ基準に基づき、抽出部ＥＸＴはＯ
ＬＴＰデータベースＯＬＴＰ−ＤＢからオブジェクトデータを選び出す。さらに
抽出部マスタは処理すべきテーブルに関する情報も供給し、必ずしも完全なオブ
ジェクトを抽出しなくてもよいようにする。個々の抽出部マスタは選択されたオ
ブジェクトを結果伝送部ＲＳへ伝送する。既述のように、固有の出口を用いて結
果伝送部において付加的なフィルタリングを実行することができる。
ＬＴＰデータベースＯＬＴＰ−ＤＢからオブジェクトデータを選び出す。さらに
抽出部マスタは処理すべきテーブルに関する情報も供給し、必ずしも完全なオブ
ジェクトを抽出しなくてもよいようにする。個々の抽出部マスタは選択されたオ
ブジェクトを結果伝送部ＲＳへ伝送する。既述のように、固有の出口を用いて結
果伝送部において付加的なフィルタリングを実行することができる。
【０１０９】
結果伝送部ＲＳは、ビジネスオブジェクトデータをＢＡＰＩ結果セーブエージ
ェントＲＳＡへ伝送する。そしてこのエージェントはマッピング用エージェント
ＭＡ、キー生成用エージェントＫＧならびに統合データベース用バルクストレー
ジエージェント（Bulk CDB Agent）ＢＣＡを呼び出す。マッピングエージェント
は、ＯＬＴＰ−Ｒ／３システムの構造をＭＳシステムの構造に変換する。キージ
ェネレータは、ＯＬＴＰ−Ｒ／３キーだけをもつオブジェクトのためのＭＳキー
を生成する。バルクストレージエージェントＢＣＡは、ビジネスオブジェクトの
データを統合データベースＤＢへ書き込む。バルクストレージエージェントＢＣ
ＡとＭＳシステムのデータベースサービスＣＤＳとの相違点は、ＢＣＡは複数の
オブジェクトを同時に処理できるのに対し、ＣＤＳはそれぞれただ１つのビジネ
スオブジェクトのデータだけしか処理できないことである。
ェントＲＳＡへ伝送する。そしてこのエージェントはマッピング用エージェント
ＭＡ、キー生成用エージェントＫＧならびに統合データベース用バルクストレー
ジエージェント（Bulk CDB Agent）ＢＣＡを呼び出す。マッピングエージェント
は、ＯＬＴＰ−Ｒ／３システムの構造をＭＳシステムの構造に変換する。キージ
ェネレータは、ＯＬＴＰ−Ｒ／３キーだけをもつオブジェクトのためのＭＳキー
を生成する。バルクストレージエージェントＢＣＡは、ビジネスオブジェクトの
データを統合データベースＤＢへ書き込む。バルクストレージエージェントＢＣ
ＡとＭＳシステムのデータベースサービスＣＤＳとの相違点は、ＢＣＡは複数の
オブジェクトを同時に処理できるのに対し、ＣＤＳはそれぞれただ１つのビジネ
スオブジェクトのデータだけしか処理できないことである。
【０１１０】
良好なパフォーマンスを保証するため、複数のビジネスオブジェクトクラスが
同時にダウンロードされる。とはいえこれは、互いに無関係なオブジェクトクラ
スについてのみ行われる。あるオブジェクトが他のオブジェクトに依存している
かぎりは（たとえば「カスタマ｝の「オーダ」など）、それらは適切な順序で相
前後してダウンロードされる。この場合、望ましい順序におく目的で、各オブジ
ェクトはインスタンスのレベルではなくクラスのレベルでダウンロードされる。
同時にダウンロードされる。とはいえこれは、互いに無関係なオブジェクトクラ
スについてのみ行われる。あるオブジェクトが他のオブジェクトに依存している
かぎりは（たとえば「カスタマ｝の「オーダ」など）、それらは適切な順序で相
前後してダウンロードされる。この場合、望ましい順序におく目的で、各オブジ
ェクトはインスタンスのレベルではなくクラスのレベルでダウンロードされる。
【０１１１】
抽出部はＯＬＴＰ−Ｒ／３データベースからデータを抽出する。既述のように
、それらは他のアプリケーション領域（たとえば外部のアプリケーションＢＷ）
のためにも用いられる。
、それらは他のアプリケーション領域（たとえば外部のアプリケーションＢＷ）
のためにも用いられる。
【０１１２】
抽出部の利用は２つのステップを有している。第１のステップにおいてフィル
タ基準が抽出部へ渡される。これはフィルタ基準に対応するすべてのビジネスオ
ブジェクトのキーを決定する。さらに第２のステップにおいて、本来の情報を読
み出すためキーリストを用いて抽出部マスタＥＭが呼び出される。そして抽出部
マスタは抽出部を用いて、別の処理のためにＢＤｏｃとして必要とされる順序で
呼び出しに固有のデータをテーブルからフェッチする。
タ基準が抽出部へ渡される。これはフィルタ基準に対応するすべてのビジネスオ
ブジェクトのキーを決定する。さらに第２のステップにおいて、本来の情報を読
み出すためキーリストを用いて抽出部マスタＥＭが呼び出される。そして抽出部
マスタは抽出部を用いて、別の処理のためにＢＤｏｃとして必要とされる順序で
呼び出しに固有のデータをテーブルからフェッチする。
【０１１３】
ブロックサイズによって、１つのパスにおいて処理されるビジネスオブジェク
トの個数が決定される。抽出部はシリアルに動作可能であり、つまり１つのパス
を他のパスの次に処理することができる。パラレルの動作モードもオブジェクト
ごとのベースで可能である。
トの個数が決定される。抽出部はシリアルに動作可能であり、つまり１つのパス
を他のパスの次に処理することができる。パラレルの動作モードもオブジェクト
ごとのベースで可能である。
【０１１４】
ＯＬＴＰ−Ｒ／３システムの構造は、マッピングによりＭＳシステムの構造に
移される。マッピングはフィールドごとに実行される。この場合、複数のフィー
ルドを１つのフィールドに連結したり、あるいは１つのフィールドを複数の部分
に分けることができる。また、フィールドタイプがコンバートされる。さらにソ
ースフィールドから依存する情報が生成される。
移される。マッピングはフィールドごとに実行される。この場合、複数のフィー
ルドを１つのフィールドに連結したり、あるいは１つのフィールドを複数の部分
に分けることができる。また、フィールドタイプがコンバートされる。さらにソ
ースフィールドから依存する情報が生成される。
【０１１５】
キージェネレータＫＧは、ＯＬＴＰ−Ｒ／３キーに対しそれぞれＣＲＭ−ＭＳ
キーを見つけるために用いられる。この場合、それぞれ１つのキージェネレータ
はＢＤｏｃのタイプについて固有に、レポジトリ情報を利用して生成される。キ
ージェネレータエージェントを最新の状態に保持する目的で、キージェネレータ
を生成するためのジェネレータがレポジトリのジェネレータエージェントにおい
て１つのサブスクライバとして登録される。そしてこれは、対応するレポジトリ
の情報が変化したときに呼び出される。
キーを見つけるために用いられる。この場合、それぞれ１つのキージェネレータ
はＢＤｏｃのタイプについて固有に、レポジトリ情報を利用して生成される。キ
ージェネレータエージェントを最新の状態に保持する目的で、キージェネレータ
を生成するためのジェネレータがレポジトリのジェネレータエージェントにおい
て１つのサブスクライバとして登録される。そしてこれは、対応するレポジトリ
の情報が変化したときに呼び出される。
【０１１６】
キージェネレータはＢＤｏｃを受け取り、存在するすべてのＯＬＴＰ−Ｒ／３
キーに対しＣＲＭ−ＭＳキーをここではＧＵＩＤ（globally unique identifier
）のかたちで使用する。必要とされるＭＳキーは種々の場所で探され、つまりま
ずはじめにキージェネレータのローカルテーブルにおいて探され、ついでキーマ
ッピングテーブルによって、最後に統合データベースＣＤにおいて探される。Ｍ
Ｓキーがみつからなければ新たなキーが生成され、種々のマッピングテーブルに
挿入される。
キーに対しＣＲＭ−ＭＳキーをここではＧＵＩＤ（globally unique identifier
）のかたちで使用する。必要とされるＭＳキーは種々の場所で探され、つまりま
ずはじめにキージェネレータのローカルテーブルにおいて探され、ついでキーマ
ッピングテーブルによって、最後に統合データベースＣＤにおいて探される。Ｍ
Ｓキーがみつからなければ新たなキーが生成され、種々のマッピングテーブルに
挿入される。
【０１１７】
データがまだ統合データベースＣＤに格納されていない状況でキーが二重に生
成されるのを避けるため、付加的なキーマッピングテーブルが必要とされる。キ
ージェネレータのローカルテーブルはオプションであり、パフォーマンス向上の
ためキャッシュとして用いられるだけである。
成されるのを避けるため、付加的なキーマッピングテーブルが必要とされる。キ
ージェネレータのローカルテーブルはオプションであり、パフォーマンス向上の
ためキャッシュとして用いられるだけである。
【０１１８】
ＯＬＴＰ−Ｒ／３データベースＯＬＴＰ−ＤＢとＭＳシステムの統合データベ
ースＣＤとの同期合わせのために２つのコンポーネントが設けられており、すな
わち「リクエスト」と「コンペア」とが設けられている。リクエストコンポーネ
ントは、初回データダウンロード用のコンポーネントと非常に似ている。これに
よって、所期のように特定のビジネスオブジェクトをＯＬＴＰ−Ｒ／３データベ
ースＯＬＴＰ−ＤＢから統合データベースＣＤへダウンロードすることができ、
つまりはポータブルコンピュータＭＣのデータのレプリケーションを（フローコ
ントロールＦＣの制御のもとで）実行することができる。リクエストによって指
定されたフィルタ基準は初回データダウンロードの一般的なフィルタ基準と混合
され、その結果、初回データダウンロード中に処理されたデータの１つのサブセ
ットだけを選択できるようになる。このリクエストコンポーネントをインタラク
ティブにスタートさせることもできるし、バッチモードでスタートさせることも
できる。
ースＣＤとの同期合わせのために２つのコンポーネントが設けられており、すな
わち「リクエスト」と「コンペア」とが設けられている。リクエストコンポーネ
ントは、初回データダウンロード用のコンポーネントと非常に似ている。これに
よって、所期のように特定のビジネスオブジェクトをＯＬＴＰ−Ｒ／３データベ
ースＯＬＴＰ−ＤＢから統合データベースＣＤへダウンロードすることができ、
つまりはポータブルコンピュータＭＣのデータのレプリケーションを（フローコ
ントロールＦＣの制御のもとで）実行することができる。リクエストによって指
定されたフィルタ基準は初回データダウンロードの一般的なフィルタ基準と混合
され、その結果、初回データダウンロード中に処理されたデータの１つのサブセ
ットだけを選択できるようになる。このリクエストコンポーネントをインタラク
ティブにスタートさせることもできるし、バッチモードでスタートさせることも
できる。
【０１１９】
コンペアコンポーネントはＯＬＴＰ−Ｒ／３システムからビジネスデータをダ
ウンロードする。比較アクションの結果として得られる相違点によって、統合デ
ータベースＣＤにおいて行う必要のある変更が表され、これはその内容をＯＬＴ
Ｐ−Ｒ／３データベースＯＬＴＰ−ＤＢの内容と一致させることを目的としてい
る。その際、変更情報（「インサート」、「アップデート」、「デリート」）は
ＢＤｏｃ構造内に格納される。本来の比較アクション後に統合データベースＤＢ
に対しその変更が適用され、それによってその変更をＯＬＴＰ−ＤＢと一致させ
るようにする。そして変更情報からＢＤｏｃが生成され、ローカルデータベース
ＬＤのレプリケーションのため（フローコントロールにより制御されて）モバイ
ルクライントＭＣが用いられる。
ウンロードする。比較アクションの結果として得られる相違点によって、統合デ
ータベースＣＤにおいて行う必要のある変更が表され、これはその内容をＯＬＴ
Ｐ−Ｒ／３データベースＯＬＴＰ−ＤＢの内容と一致させることを目的としてい
る。その際、変更情報（「インサート」、「アップデート」、「デリート」）は
ＢＤｏｃ構造内に格納される。本来の比較アクション後に統合データベースＤＢ
に対しその変更が適用され、それによってその変更をＯＬＴＰ−ＤＢと一致させ
るようにする。そして変更情報からＢＤｏｃが生成され、ローカルデータベース
ＬＤのレプリケーションのため（フローコントロールにより制御されて）モバイ
ルクライントＭＣが用いられる。
【０１２０】
次に、本発明にとって重要な機能について補足的に説明する。
【０１２１】
１．クロスシステムプライマリキー（cross-system primary key）の供給
上述のように、オフライン分散されたデータベースシステムのセマンティクス
インテグレーションにとって重要であるのは、システムを超えてクロスシステム
もしくはシステムワイドでプライマリキーを供給することであり、これによって
データオブジェクトの一義的な識別を相互に融合するデータベースシステムの境
界を超えて実現することができる。
インテグレーションにとって重要であるのは、システムを超えてクロスシステム
もしくはシステムワイドでプライマリキーを供給することであり、これによって
データオブジェクトの一義的な識別を相互に融合するデータベースシステムの境
界を超えて実現することができる。
【０１２２】
図８には、（上述の説明を補足するかたちで）これに適した手順の基本原理が
描かれている。キージェネレータＫＧは、ここでは一般的にＡもしくはＢの付さ
れたデータベースシステム（ソースシステム）において捕捉されたデータを受け
取る。これにはシステム固有の個々のプライマリキーＫＡもしくはＫＢが属して
いる。（ターゲットとなるシステムにおける）それぞれ他のプライマリキーにつ
いては、データセットにおいて空のフィールドが設けられている。キージェネレ
ータはキーマッピングテーブル（Key Mapping Table）ＫＭＴの内容を読み出し
、システムＡまたはＢの一方から供給されるデータセットのキーフィールドと比
較する。ソースシステム（たとえばＫＡ）のプライマリキーがキーマッピングテ
ーブルＫＭＴ内にすでに存在しているならば、供給されたデータセットは既存の
エントリの変更（アップデート Update）に該当する。この場合、ターゲットと
なるシステム（たとえばＫＢ）における対応のプライマリキーがキーマッピング
テーブルＫＭＴから読み出され、データセットの空のフィールドにエントリされ
る。
描かれている。キージェネレータＫＧは、ここでは一般的にＡもしくはＢの付さ
れたデータベースシステム（ソースシステム）において捕捉されたデータを受け
取る。これにはシステム固有の個々のプライマリキーＫＡもしくはＫＢが属して
いる。（ターゲットとなるシステムにおける）それぞれ他のプライマリキーにつ
いては、データセットにおいて空のフィールドが設けられている。キージェネレ
ータはキーマッピングテーブル（Key Mapping Table）ＫＭＴの内容を読み出し
、システムＡまたはＢの一方から供給されるデータセットのキーフィールドと比
較する。ソースシステム（たとえばＫＡ）のプライマリキーがキーマッピングテ
ーブルＫＭＴ内にすでに存在しているならば、供給されたデータセットは既存の
エントリの変更（アップデート Update）に該当する。この場合、ターゲットと
なるシステム（たとえばＫＢ）における対応のプライマリキーがキーマッピング
テーブルＫＭＴから読み出され、データセットの空のフィールドにエントリされ
る。
【０１２３】
これに対し供給されたプライマリキーがキーマッピングテーブルＫＭＴ内にみ
つからなければ、それはデータセットの新たな生成（インサート Insert）であ
る。この場合、欠けているプライマリキー（たとえばＫＢ）がキー生成モジュー
ル（Key Generate Module）ＫＧＭによって生成されてキーマッピングテーブル
ＫＭＴに書き込まれ、さらにそのキーは空のデータフィールドにエントリされる
。その後、データセットはターゲットとなるシステムにおいても一義的に識別可
能であり、ソースシステムのキーとターゲットシステムのキーは互いに一義的に
対応づけられる。
つからなければ、それはデータセットの新たな生成（インサート Insert）であ
る。この場合、欠けているプライマリキー（たとえばＫＢ）がキー生成モジュー
ル（Key Generate Module）ＫＧＭによって生成されてキーマッピングテーブル
ＫＭＴに書き込まれ、さらにそのキーは空のデータフィールドにエントリされる
。その後、データセットはターゲットとなるシステムにおいても一義的に識別可
能であり、ソースシステムのキーとターゲットシステムのキーは互いに一義的に
対応づけられる。
【０１２４】
次に、上述のＢＤｏｃのように実際のインプリメントにおいて階層的に分けら
れたデータセグメントの複雑な構造をもつデータオブジェクトを有するデータベ
ースシステムにおいてこの原理を実施するための実際のやり方について説明する
。
れたデータセグメントの複雑な構造をもつデータオブジェクトを有するデータベ
ースシステムにおいてこの原理を実施するための実際のやり方について説明する
。
【０１２５】
図９には、２つのセグメントＳ１およびＳ２から成る非常に簡単な構造が描か
れている。セグメントＳ１は階層的にいえばセグメントＳ２の一段上に配置され
ており、したがって子セグメントＳ２に対する親セグメントと呼ばれる。親セグ
メントは図示の事例ではＢＤｏｃのルートセグメントである。
れている。セグメントＳ１は階層的にいえばセグメントＳ２の一段上に配置され
ており、したがって子セグメントＳ２に対する親セグメントと呼ばれる。親セグ
メントは図示の事例ではＢＤｏｃのルートセグメントである。
【０１２６】
親セグメントＳ１は、ＭＳシステムのプライマリキーＫＭＳとＯＬＴＰ−Ｒ／
３システムのプライマリキーＫＲ／３を有している。これらのキーの各々は、１
つまたは複数のセグメントフィールド内に格納されている。
３システムのプライマリキーＫＲ／３を有している。これらのキーの各々は、１
つまたは複数のセグメントフィールド内に格納されている。
【０１２７】
子セグメントも、（１つのフィールドに格納されている）ＭＳシステムのプラ
イマリキーＫＭＳと（３つのフィールドに格納されている）ＯＬＴＰ−Ｒ／３シ
ステムのキーＫＲ／３を有している。さらに子セグメントのフィールドには上位
の親セグメントのキーも含まれており、このことは両方のセグメント間の矢印に
よって表されている。とはいえそれらのフィールドはキーのファンクションをも
っているのではなく、セグメント構造に関する情報に対するいわゆる外部キー（
foreign key）として用いられる。つまりそれらは、Ｓ２はセグメントＳ１の子
であることを表している。
イマリキーＫＭＳと（３つのフィールドに格納されている）ＯＬＴＰ−Ｒ／３シ
ステムのキーＫＲ／３を有している。さらに子セグメントのフィールドには上位
の親セグメントのキーも含まれており、このことは両方のセグメント間の矢印に
よって表されている。とはいえそれらのフィールドはキーのファンクションをも
っているのではなく、セグメント構造に関する情報に対するいわゆる外部キー（
foreign key）として用いられる。つまりそれらは、Ｓ２はセグメントＳ１の子
であることを表している。
【０１２８】
図９の右側には対応するキーマッピングテーブルが描かれており、この場合、
矢印で表されている行にはセグメントＳ１とＳ２の各キーが書き込まれている。
矢印で表されている行にはセグメントＳ１とＳ２の各キーが書き込まれている。
【０１２９】
図１０にはいくらか複雑なフィールド構造が示されており、これには親セグメ
ントＳ１（ＢＤｏｃのルートセグメント）、階層的にいえば下位に位置する子ジ
ェネレーションの２つのセグメントＳ２ａおよびＳ２ｂ、さらにはセグメントＳ
２ａの子である孫ジェネレーションのセグメントＳ３が設けられている。たとえ
ばセグメントＳ１には「カスタマ」タイプのＢＤｏｃのためにカスタマの名前と
住所をもたせることができ、セグメントＳ２ａにはそのカスタマの担当員を、ま
た、フィールドＳ３にはその担当員の渉外情報（電話番号、サービス時間など）
を、さらにフィールドＳ２ｂにはそのカスタマの装備しているマシンに関する情
報を含めることができる。
ントＳ１（ＢＤｏｃのルートセグメント）、階層的にいえば下位に位置する子ジ
ェネレーションの２つのセグメントＳ２ａおよびＳ２ｂ、さらにはセグメントＳ
２ａの子である孫ジェネレーションのセグメントＳ３が設けられている。たとえ
ばセグメントＳ１には「カスタマ」タイプのＢＤｏｃのためにカスタマの名前と
住所をもたせることができ、セグメントＳ２ａにはそのカスタマの担当員を、ま
た、フィールドＳ３にはその担当員の渉外情報（電話番号、サービス時間など）
を、さらにフィールドＳ２ｂにはそのカスタマの装備しているマシンに関する情
報を含めることができる。
【０１３０】
この場合も各セグメントには（図示の実例ではみやすくするためそれぞれ１つ
のフィールドのみにおいて）両方のデータベースシステムのキーＫＭＳおよびＫ Ｒ／３ を有しており、この場合、依存するシステムはそれぞれ親ジェネレーショ
ンのキーを外部キーとして有している。図１０の右側に描かれているキーマッピ
ングテーブルは、やはり両方のシステムの対応を示している。
のフィールドのみにおいて）両方のデータベースシステムのキーＫＭＳおよびＫ Ｒ／３ を有しており、この場合、依存するシステムはそれぞれ親ジェネレーショ
ンのキーを外部キーとして有している。図１０の右側に描かれているキーマッピ
ングテーブルは、やはり両方のシステムの対応を示している。
【０１３１】
実際には大規模なデータベースシステムのデータオブジェクトは、互いにイン
タリーブされた多数の階層平面をもつ非常に複雑なデータ構造を有している可能
性があり、その際、セグメントはしばしばきわめて多くの個数のデータレコード
を有している。これに加えて、特別な要求を考慮するため特殊な構造エレメント
の必要とされることも多い。たとえば個々のデータレコードのデータに対し、そ
れらが下方の階層平面にあるにもかかわらず、迅速にアクセスできるようにする
ことの要求されることが多い。このような状況において好適であるのは、階層的
に深いセグメントにおいて必要とされるキーを比較的高い階層のセグメントにお
ける特別なフィールドに格納することである。たとえば図１０に描かれているよ
うに、第２のセグメントＳ２ａの第１のデータレコードのコードＣ１Ｍを有する
キーがセグメントＳ１の特別フィールドＳＦ内にエントリされており、その目的
はたとえばＳ１にコーディングされているカスタマの最も重要な担当員に対する
ダイレクトなアクセスを可能にすることである。このような構造上の特殊性によ
って、上述の方法の実施は実際にはとても困難になる。
タリーブされた多数の階層平面をもつ非常に複雑なデータ構造を有している可能
性があり、その際、セグメントはしばしばきわめて多くの個数のデータレコード
を有している。これに加えて、特別な要求を考慮するため特殊な構造エレメント
の必要とされることも多い。たとえば個々のデータレコードのデータに対し、そ
れらが下方の階層平面にあるにもかかわらず、迅速にアクセスできるようにする
ことの要求されることが多い。このような状況において好適であるのは、階層的
に深いセグメントにおいて必要とされるキーを比較的高い階層のセグメントにお
ける特別なフィールドに格納することである。たとえば図１０に描かれているよ
うに、第２のセグメントＳ２ａの第１のデータレコードのコードＣ１Ｍを有する
キーがセグメントＳ１の特別フィールドＳＦ内にエントリされており、その目的
はたとえばＳ１にコーディングされているカスタマの最も重要な担当員に対する
ダイレクトなアクセスを可能にすることである。このような構造上の特殊性によ
って、上述の方法の実施は実際にはとても困難になる。
【０１３２】
このような問題点を以下で説明するアルゴリズムによって解決することができ
る。このアルゴリズムは２つのプログラム部分から成り、それらをＰＡＳＳ−Ｉ
およびＰＳＳ−ＩＩと称する。
る。このアルゴリズムは２つのプログラム部分から成り、それらをＰＡＳＳ−Ｉ
およびＰＳＳ−ＩＩと称する。
【０１３３】
ＰＡＳＳ−Ｉ：
すべての（定義済み）セグメントに対し｛
すべてのデータセットに対し｛
／／ＫＭＳを満たす／／
（ＫＭＳ＝ＬＥＥＲ）であれば｛
ＫＭＴにおいて探索（ＫＲ／３）
エントリが存在しているならば｛
ＫＭＳをＫＭＴから取り出す
ＫＭＳをＢＤｏｃへ入力
｝そうでなければ｛
新たなＫＭＳを生成
ＫＲ／３，ＫＭＳをＫＭＴへエントリ
ＫＭＳをＢＤｏｃへエントリ
｝
｝
／／ＭＳ親キーを満たす／／
（ＭＳ親キー＝ＬＥＥＲ）であれば｛
ＢＤｏｃ親セグメントにポジショニング（Ｒ／３親キー）
ＭＳ親キーをＢＤｏｃ親セグメントから取り出す
ＭＳ親キーをＢＤｏｃへエントリ
｝
｝
｝
ＰＡＳＳ−Ｉにおいて、すべての定義済みセグメントに対し（つまりキー生成
の必要とされるすべてのセグメントに対し）、およびすべてのデータセットに対
し、コメント「ＫＭＳを満たす」の付けられたアルゴリズムセクションが実行さ
れる。このアルゴリズムセクションではまずはじめに、プライマリキーのフィー
ルドが空であるか否かの問い合わせが行われる。空であるならば、存在するキー
ＫＲ／３のもとでキーマッピングテーブルにおいて、エントリが存在するか否か
が探索される。場合によっては、対応するＭＳプライマリキーがキーマッピング
テーブルから取り出され、ＢＤｏｃへエントリされる。
の必要とされるすべてのセグメントに対し）、およびすべてのデータセットに対
し、コメント「ＫＭＳを満たす」の付けられたアルゴリズムセクションが実行さ
れる。このアルゴリズムセクションではまずはじめに、プライマリキーのフィー
ルドが空であるか否かの問い合わせが行われる。空であるならば、存在するキー
ＫＲ／３のもとでキーマッピングテーブルにおいて、エントリが存在するか否か
が探索される。場合によっては、対応するＭＳプライマリキーがキーマッピング
テーブルから取り出され、ＢＤｏｃへエントリされる。
【０１３４】
探索されたＫＭＳのエントリが存在しなければ、ＧＵＩＤが新たなＭＳプライ
マリキーとして生成され、ＫＲ／３もＫＭＳもキーマッピングテーブルにエント
リされる。さらにＢＤｏｃへのＫＭＳのエントリが行われる。
マリキーとして生成され、ＫＲ／３もＫＭＳもキーマッピングテーブルにエント
リされる。さらにＢＤｏｃへのＫＭＳのエントリが行われる。
【０１３５】
ついで、コメント「ＭＳ親キーを満たす」の付されたアルゴリズムセクション
が実行される。ＭＳ親キーのためのフィールドが空であれば、読み出しポジショ
ンがＢＤｏｃ内の親セグメントにおかれ、しかもこれは対応するＫＲ／３を含む
データレコードにおかれる。その後、対応するＫＭＳが親セグメントから取り出
され、子セグメントの外部キーフィールドにエントリされる。
が実行される。ＭＳ親キーのためのフィールドが空であれば、読み出しポジショ
ンがＢＤｏｃ内の親セグメントにおかれ、しかもこれは対応するＫＲ／３を含む
データレコードにおかれる。その後、対応するＫＭＳが親セグメントから取り出
され、子セグメントの外部キーフィールドにエントリされる。
【０１３６】
ＰＡＳＳ−Ｉは、階層によりまえもって定められた順序で（最も高い階層平面
から始めて）ＢＤｏｃのすべてのセグメントが処理されてしまうまで何度も実行
される。
から始めて）ＢＤｏｃのすべてのセグメントが処理されてしまうまで何度も実行
される。
【０１３７】
その後、ＰＡＳＳ−ＩＩがスタートする。これはＦＥＴＣＨテーブルと称する
レポジトリに格納されたテーブルによって制御される。このテーブルには、ＰＡ
ＳＳ−Ｉでは不可能である充填アクション（フィルアクション）が記述されてい
る。これには、（図１０に描かれているように）階層的に低い方のセグメントか
らの値の充填と、親平面よりも高い階層平面（つまりたとえば２つの平面だけ高
い平面すなわち親の親の平面）からのキーの充填が属している。
レポジトリに格納されたテーブルによって制御される。このテーブルには、ＰＡ
ＳＳ−Ｉでは不可能である充填アクション（フィルアクション）が記述されてい
る。これには、（図１０に描かれているように）階層的に低い方のセグメントか
らの値の充填と、親平面よりも高い階層平面（つまりたとえば２つの平面だけ高
い平面すなわち親の親の平面）からのキーの充填が属している。
【０１３８】
これらの機能を果たせるようにするため、ＦＥＴＣＨテーブルは以下の構造を
有している。
有している。
【０１３９】
・ＤｅｓｔＴｂｌ：ターゲットテーブル
・ＤｅｓｔＦｌｄ：ターゲットフィールド
・ＳｒｃＴｂｌ： ソーステーブル
・ＳｒｃＦｌｄ： ソースフィールド
・Ｃｏｎｄ： ＫＲ／３またはサンプルｘ＝ｙによる条件
ＦＥＴＣＨテーブルにおけるエントリにより、ソーステーブルのソースフィー
ルドからターゲットテーブルと称するＢＤｏｃのセグメントへの充填アクション
が発生する。
ルドからターゲットテーブルと称するＢＤｏｃのセグメントへの充填アクション
が発生する。
【０１４０】
ＰＡＳＳ−ＩＩのアルゴリズムは以下の通りである：
すべての定義済みセグメントについて｛
ＤｅｓｔＴｂｌ＝ＳｅｇｍｅｎｔであるＦＥＴＣＨテーブル内のすべてのテ
ーブルについて｛ ＦＥＴＣＨテーブルから値を読み込む （Ｃｏｎｄ＝Ｒ／３）であれば｛ ／／ＢＤｏｃ内の値 ＳｒｃＴｂｌにおけるＢＤｏｃにポジショニング（ＫＲ／３） ＳｒｃＴｂｌ−＞ＳｒｃＦｌｄをＤｅｓｔＴｂｌ−＞Ｄｅｓｔ
Ｆｌｄに書き込み ｝そうでなければ｛ ／／ＣＤからの値 フィルタ＝ＣｏｎｄでＳｒｃＴｂｌにおけるＣＤにポジショニング ＣＤＳｒｃＴｂｌ−＞ＳｒｃＦｌｄをＤｅｓｔＴｂｌ−＞Ｄｅｓｔ
Ｆｌｄに書き込み ｝ ｝ ｝ 処理されるＢＤｏｃのすべてのセグメントについて、およびセグメントがＤｅ
ｓｔＴｂｌとしてエントリされているＦＥＴＣＨテーブル内のすべてのエントリ
について、ＦＥＴＣＨテーブルから値が読み出される。その後、条件判定が行わ
れる。Ｃｏｎｄ＝Ｒ／３とセットされていれば、それはＢＤｏｃ内のキー値の伝
送のことであり、この場合、ソースセグメントにおけるソースフィールドの内容
がターゲットセグメント内のターゲットフィールドへ伝送される。条件Ｃｏｎｄ
が別の値を有しているならば、ＢＤｏｃ自体からまたは統合データベースＣＤか
ら値が引き継がれ、後者の場合、データベースＣＤ内のソーステーブルへのアク
セスが行われ、その内容がターゲットセグメントのターゲットフィールドへ伝送
される。
ーブルについて｛ ＦＥＴＣＨテーブルから値を読み込む （Ｃｏｎｄ＝Ｒ／３）であれば｛ ／／ＢＤｏｃ内の値 ＳｒｃＴｂｌにおけるＢＤｏｃにポジショニング（ＫＲ／３） ＳｒｃＴｂｌ−＞ＳｒｃＦｌｄをＤｅｓｔＴｂｌ−＞Ｄｅｓｔ
Ｆｌｄに書き込み ｝そうでなければ｛ ／／ＣＤからの値 フィルタ＝ＣｏｎｄでＳｒｃＴｂｌにおけるＣＤにポジショニング ＣＤＳｒｃＴｂｌ−＞ＳｒｃＦｌｄをＤｅｓｔＴｂｌ−＞Ｄｅｓｔ
Ｆｌｄに書き込み ｝ ｝ ｝ 処理されるＢＤｏｃのすべてのセグメントについて、およびセグメントがＤｅ
ｓｔＴｂｌとしてエントリされているＦＥＴＣＨテーブル内のすべてのエントリ
について、ＦＥＴＣＨテーブルから値が読み出される。その後、条件判定が行わ
れる。Ｃｏｎｄ＝Ｒ／３とセットされていれば、それはＢＤｏｃ内のキー値の伝
送のことであり、この場合、ソースセグメントにおけるソースフィールドの内容
がターゲットセグメント内のターゲットフィールドへ伝送される。条件Ｃｏｎｄ
が別の値を有しているならば、ＢＤｏｃ自体からまたは統合データベースＣＤか
ら値が引き継がれ、後者の場合、データベースＣＤ内のソーステーブルへのアク
セスが行われ、その内容がターゲットセグメントのターゲットフィールドへ伝送
される。
【０１４１】
２．データマージ
種々のデータベースシステムの融合におけるさらに別の基礎的な問題点は、２
つのシステムにおいて所定のタイプのデータオブジェクトに対して存在するデー
タがそれぞれ異なることである。たとえばＣＲＭシステムにおけるデータオブジ
ェクト「カスタマ」には、個々のカスタマ担当員または準備されている販売交渉
（opportunities）に関する情報の含まれている可能性があり、これをＥＲＰシ
ステムは必要としない。これに対し、ＥＲＰシステムにおけるデータオブジェク
ト「カスタマ」は、たとえば取引関係開始以来のカスタマのすべての勘定のよう
な情報を有しており、これをＣＲＭシステムは必要とせず、したがってそこで処
理されるデータオブジェクトについてセグメントは設けられていない。
つのシステムにおいて所定のタイプのデータオブジェクトに対して存在するデー
タがそれぞれ異なることである。たとえばＣＲＭシステムにおけるデータオブジ
ェクト「カスタマ」には、個々のカスタマ担当員または準備されている販売交渉
（opportunities）に関する情報の含まれている可能性があり、これをＥＲＰシ
ステムは必要としない。これに対し、ＥＲＰシステムにおけるデータオブジェク
ト「カスタマ」は、たとえば取引関係開始以来のカスタマのすべての勘定のよう
な情報を有しており、これをＣＲＭシステムは必要とせず、したがってそこで処
理されるデータオブジェクトについてセグメントは設けられていない。
【０１４２】
プライマリキーに関してはさきに説明したロジックが有利であり、それによれ
ばシステムの一方においてつまりフロントオフィスシステムＭＳにおいて、互い
に融合されるシステムの両方のキーＫＭＳおよびＫＲ／３がホールドされるのに
対し、バックオフィスシステムにはそのキーＫＲ／３だけがホールドされる。
ばシステムの一方においてつまりフロントオフィスシステムＭＳにおいて、互い
に融合されるシステムの両方のキーＫＭＳおよびＫＲ／３がホールドされるのに
対し、バックオフィスシステムにはそのキーＫＲ／３だけがホールドされる。
【０１４３】
このような状況においてできるかぎり完全なデータ交換を実現するために有利
であるのは「データマージ手順（data merge procedure）」を使用することであ
り、次にこれについて以下の取り決めを用いながら図５および図１１に基づき説
明する： ＤＭＳ： ＭＳシステム内にしか存在していないデータ ＤＲ／３： ＯＬＴＰ−Ｒ／３システム内にしか存在していないデータ ＤＭｉｘ： 両方のシステムに存在しているデータ 図１１に示されているように、ＭＳシステムからのデータがシステム固有のデ
ータオブジェクト（ＢＤｏｃ）としてＯＬＴＰ−Ｒ／３システムへ伝送するため
に用意される場合、それにはＤＭＳ，ＤＲ／３，ＤＭｉｘがキーとして含まれる
。ＯＬＴＰアダプタＯＬＴＰ−ＡＤにおいて、データＤＭＳがＢＡＰＩ呼出部Ｂ
Ｃから分配されてそこに保管される。その後、ＯＬＴＰアダプタは残りの情報Ｄ Ｍｉｘ およびＫＭＳをＯＬＴＰ−Ｒ／３システムへ伝送する。ソースシステムＫ ＭＳ のキーはターゲットシステムＯＬＴＰ−Ｒ／３システムにおいて分離され、
補助データＡＭＤというメモリ領域に保管される。
であるのは「データマージ手順（data merge procedure）」を使用することであ
り、次にこれについて以下の取り決めを用いながら図５および図１１に基づき説
明する： ＤＭＳ： ＭＳシステム内にしか存在していないデータ ＤＲ／３： ＯＬＴＰ−Ｒ／３システム内にしか存在していないデータ ＤＭｉｘ： 両方のシステムに存在しているデータ 図１１に示されているように、ＭＳシステムからのデータがシステム固有のデ
ータオブジェクト（ＢＤｏｃ）としてＯＬＴＰ−Ｒ／３システムへ伝送するため
に用意される場合、それにはＤＭＳ，ＤＲ／３，ＤＭｉｘがキーとして含まれる
。ＯＬＴＰアダプタＯＬＴＰ−ＡＤにおいて、データＤＭＳがＢＡＰＩ呼出部Ｂ
Ｃから分配されてそこに保管される。その後、ＯＬＴＰアダプタは残りの情報Ｄ Ｍｉｘ およびＫＭＳをＯＬＴＰ−Ｒ／３システムへ伝送する。ソースシステムＫ ＭＳ のキーはターゲットシステムＯＬＴＰ−Ｒ／３システムにおいて分離され、
補助データＡＭＤというメモリ領域に保管される。
【０１４４】
ついでＤＭｉｘデータは補助データＤＤによって補われる。これはターゲット
システム（ＯＬＴＰ−Ｒ／３システム）において生成されたデータオブジェクト
を処理するために必要とされる。それらの補助データは通例、対応するデータフ
ィールドのためのプリセット値（デフォルト値）である。
システム（ＯＬＴＰ−Ｒ／３システム）において生成されたデータオブジェクト
を処理するために必要とされる。それらの補助データは通例、対応するデータフ
ィールドのためのプリセット値（デフォルト値）である。
【０１４５】
その後、ＯＬＴＰ−Ｒ／３システムにおいて通常の処理が実行される。データ
はターゲットシステムにおいて一般に行われているロギングルーチンを用いるこ
とで非同期にチェックされ、データベースＯＬＴＰ−ＤＢに格納される。
はターゲットシステムにおいて一般に行われているロギングルーチンを用いるこ
とで非同期にチェックされ、データベースＯＬＴＰ−ＤＢに格納される。
【０１４６】
ロギングと関連して１つのイベントがトリガされ、このイベントはイベントデ
ィストリビュータＥＤによって殊に結果伝送部ＲＳへ伝達され、結果伝送部はこ
れに応じてデータをロギングから受け取る。得られたデータパケットはＤＲ／３ ，ＤＭｉｘおよびＫＲ／３から成る。結果伝送部ＲＳは保管されていたＭＳキー
ＫＭＳを挿入し、ＭＳシステムに関係しないデータＤＲ／３を取り除く。その後
、データパケットＤＭｉｘ，ＫＭＳおよびＫＲ／３としてＭＳシステムへの伝送
が行われる。ＭＳシステム内において、保管されていたデータＤＭＳが結果セー
ブエージェントＲＳＡにより再び付け加えられ、その結果、データＤＭＳ，ＤＭ ｉｘ ，ＫＭＳおよびＫＲ／３を有する完全なＢＤｏｃが後続処理（たとえばデー
タベースＣＤにおける統合化およびそれに続くモバイルクライントＭＣへのレプ
リケーション）のために得られる。
ィストリビュータＥＤによって殊に結果伝送部ＲＳへ伝達され、結果伝送部はこ
れに応じてデータをロギングから受け取る。得られたデータパケットはＤＲ／３ ，ＤＭｉｘおよびＫＲ／３から成る。結果伝送部ＲＳは保管されていたＭＳキー
ＫＭＳを挿入し、ＭＳシステムに関係しないデータＤＲ／３を取り除く。その後
、データパケットＤＭｉｘ，ＫＭＳおよびＫＲ／３としてＭＳシステムへの伝送
が行われる。ＭＳシステム内において、保管されていたデータＤＭＳが結果セー
ブエージェントＲＳＡにより再び付け加えられ、その結果、データＤＭＳ，ＤＭ ｉｘ ，ＫＭＳおよびＫＲ／３を有する完全なＢＤｏｃが後続処理（たとえばデー
タベースＣＤにおける統合化およびそれに続くモバイルクライントＭＣへのレプ
リケーション）のために得られる。
【０１４７】
このようなデータマージ手順は、ＭＳシステムからＯＬＴＰ−Ｒ／３システム
へのデータのアップデートごとに行われる。ＯＬＴＰ−Ｒ／３システムにおける
データ変更（デルタダウンロード）にあたりこの手順の一部分がロギングルーチ
ンからスタートして実行されるが、その際には当然ながらＭＳキーＫＭＳを加え
ることはできない。これはその場合には上述のようにしてキージェネレータＫＧ
によって生成される。
へのデータのアップデートごとに行われる。ＯＬＴＰ−Ｒ／３システムにおける
データ変更（デルタダウンロード）にあたりこの手順の一部分がロギングルーチ
ンからスタートして実行されるが、その際には当然ながらＭＳキーＫＭＳを加え
ることはできない。これはその場合には上述のようにしてキージェネレータＫＧ
によって生成される。
【０１４８】
３．ダウンロード
データベースシステムの融合における基本的な目標は、各システムにおいて共
通に利用されるデータを別個にメンテナンスしなくても済むようにし、互いに融
合されたデータベースシステム中に存在するデータを共通に利用できるようにす
ることである。たとえばＣＲＭフロントオフィスシステムは、企業のＥＲＰバッ
クオフィスシステム内に格納されているカスタマ情報および製品情報に関するデ
ータをアクセスすることができるようにしなければならない。
通に利用されるデータを別個にメンテナンスしなくても済むようにし、互いに融
合されたデータベースシステム中に存在するデータを共通に利用できるようにす
ることである。たとえばＣＲＭフロントオフィスシステムは、企業のＥＲＰバッ
クオフィスシステム内に格納されているカスタマ情報および製品情報に関するデ
ータをアクセスすることができるようにしなければならない。
【０１４９】
４．初回データダウンロード
このためまずはじめに以下の役割が課される。すなわち、既存の第１のデータ
ベース（ソースシステムＡここではＯＬＴＰ−Ｒ／３システム）におけるデータ
であって、インプリメントされている別のデータベースシステム（ターゲットシ
ステムＢここではＭＳシステム）によっても必要とされるデータが、初回データ
ダウンロード（Initial Download）にあたりシステムＡからシステムＢへ伝送す
る。この関連で本発明によれば以下のような問題解決手段が提案される。
ベース（ソースシステムＡここではＯＬＴＰ−Ｒ／３システム）におけるデータ
であって、インプリメントされている別のデータベースシステム（ターゲットシ
ステムＢここではＭＳシステム）によっても必要とされるデータが、初回データ
ダウンロード（Initial Download）にあたりシステムＡからシステムＢへ伝送す
る。この関連で本発明によれば以下のような問題解決手段が提案される。
【０１５０】
既存のバックオフィスシステム（以下ではこのことをＯＬＴＰ−Ｒ／３システ
ムと称するがこれによっても汎用性が制約されるものではない）におけるデータ
量は通例、非常に多い。したがって、他のシステムと交換すべきデータを詳しく
指定する手段を提供しなければならない。本発明においてはこのことは有利には
フィルタリングによって行われる。
ムと称するがこれによっても汎用性が制約されるものではない）におけるデータ
量は通例、非常に多い。したがって、他のシステムと交換すべきデータを詳しく
指定する手段を提供しなければならない。本発明においてはこのことは有利には
フィルタリングによって行われる。
【０１５１】
このようなフィルタリングのために図７を参照しながら説明した抽出部が用い
られ、これはＯＬＴＰ−Ｒ／３システムによって提供される。この場合の特殊性
は、抽出部マスタのかたちでＭＳシステムに対する標準化されたインタフェース
が適用され、このインタフェースを介してＭＳシステムにおけるすべての問い合
わせが行われることである。つまり、ターゲットデータシステムＭＳが標準化さ
れたインタフェースを介してそのシステムが必要とするデータに対する要求を、
ソースシステムＯＬＴＰ−Ｒ／３にインプリメントされている抽出部へ伝送する
ことによって、データがフィルタリングされる。
られ、これはＯＬＴＰ−Ｒ／３システムによって提供される。この場合の特殊性
は、抽出部マスタのかたちでＭＳシステムに対する標準化されたインタフェース
が適用され、このインタフェースを介してＭＳシステムにおけるすべての問い合
わせが行われることである。つまり、ターゲットデータシステムＭＳが標準化さ
れたインタフェースを介してそのシステムが必要とするデータに対する要求を、
ソースシステムＯＬＴＰ−Ｒ／３にインプリメントされている抽出部へ伝送する
ことによって、データがフィルタリングされる。
【０１５２】
さらに別の問題点は、初回データダウンロードをリーズナブルな時点で行える
ようにすることである。このことは、一般にバックオフィスシステムに設けられ
ている手段によって実現できない。なぜならばそのような手段は非常に大きいデ
ータ量を迅速に伝送するようには構成されていないからである。本発明によれば
この問題点は有利には、先に詳しく説明したバルク指向ＢＤｏｃと呼ばれる特別
なデータコンテナを提供することによって解決される。
ようにすることである。このことは、一般にバックオフィスシステムに設けられ
ている手段によって実現できない。なぜならばそのような手段は非常に大きいデ
ータ量を迅速に伝送するようには構成されていないからである。本発明によれば
この問題点は有利には、先に詳しく説明したバルク指向ＢＤｏｃと呼ばれる特別
なデータコンテナを提供することによって解決される。
【０１５３】
さらに初回データダウンロードにおける問題点は、ターゲットデータベースシ
ステムに伝送されるデータがソースデータベースシステムのきちんと定められた
状態と規定の時点（スナップショット snapshot）で一致するよう保証すること
である。従来ではこの問題点は、初回データダウンロード中はソースデータベー
スシステムを変更に対しブロックすることで解決されており、あるいは変更が許
可されているのであるならば、ソースデータベースの特別な手段を利用すること
で解決しているが、そのような手段によってデータベースに対し初回データダウ
ンロードの独立したオペレーションが妨げられる。
ステムに伝送されるデータがソースデータベースシステムのきちんと定められた
状態と規定の時点（スナップショット snapshot）で一致するよう保証すること
である。従来ではこの問題点は、初回データダウンロード中はソースデータベー
スシステムを変更に対しブロックすることで解決されており、あるいは変更が許
可されているのであるならば、ソースデータベースの特別な手段を利用すること
で解決しているが、そのような手段によってデータベースに対し初回データダウ
ンロードの独立したオペレーションが妨げられる。
【０１５４】
このような部分的な問題点を解決するため、本発明によれば以下でオンライン
同期手順（online sync procedure）と呼ぶ方法が提案され、これについて図１
２を参照して説明する。この場合、ソースシステムＯＬＴＰ−Ｒ／３にインプリ
メントされている抽出部は、ターゲットシステムＭＳ内に格納されているフィル
タ定義ＦＤにより制御され抽出部マスタインタフェースＥＭを介して呼び出され
るのであるが、この抽出部は通常はブロックで読み出され送出されるかたちで動
作し、その際にこれはソースデータベースのダイナミックなデータ変更を無視す
る。このため、ターゲットシステムにより必要とされるデータバルクは矢印ＩＬ
（Initial Load）の付された経路で伝送される。
同期手順（online sync procedure）と呼ぶ方法が提案され、これについて図１
２を参照して説明する。この場合、ソースシステムＯＬＴＰ−Ｒ／３にインプリ
メントされている抽出部は、ターゲットシステムＭＳ内に格納されているフィル
タ定義ＦＤにより制御され抽出部マスタインタフェースＥＭを介して呼び出され
るのであるが、この抽出部は通常はブロックで読み出され送出されるかたちで動
作し、その際にこれはソースデータベースのダイナミックなデータ変更を無視す
る。このため、ターゲットシステムにより必要とされるデータバルクは矢印ＩＬ
（Initial Load）の付された経路で伝送される。
【０１５５】
しかしこれと並行して、結果伝送部ＲＳによる既述のデルタハンドリングも実
行される。これにより、ソースシステム内で初回データダウンロード中に生じた
変更がキューに格納される。通常のデルタダウンロード動作とは異なりこのキュ
ーはアンロックされるのではなく、初回データダウンロード期間中はロックされ
る（Queue-Stop QS）。初回データダウンロード終了後に変更キューがアンロッ
クされ、初回データダウンロード中に実行された変更が矢印ＤＬ（Deltaload）
によってシンボリックに表されたデルタダウンロードチャネルを介してターゲッ
トシステムＭＳへ伝送される。このようにして、初回データダウンロード終了時
点に関して一致した「スナップショット」が生じる。
行される。これにより、ソースシステム内で初回データダウンロード中に生じた
変更がキューに格納される。通常のデルタダウンロード動作とは異なりこのキュ
ーはアンロックされるのではなく、初回データダウンロード期間中はロックされ
る（Queue-Stop QS）。初回データダウンロード終了後に変更キューがアンロッ
クされ、初回データダウンロード中に実行された変更が矢印ＤＬ（Deltaload）
によってシンボリックに表されたデルタダウンロードチャネルを介してターゲッ
トシステムＭＳへ伝送される。このようにして、初回データダウンロード終了時
点に関して一致した「スナップショット」が生じる。
【０１５６】
ｂ）デルタダウンロード
デルタダウンロードの機能についても、上述の（殊に図５に基づく）説明なら
びにデータマージ手順についてなされた説明が関連する。ここでの目的は、初回
データダウンロード後に動作実行中、ソースデータベースシステムＡとつながっ
ているすべてのシステムに対しそれぞれ変更を加えることである。
びにデータマージ手順についてなされた説明が関連する。ここでの目的は、初回
データダウンロード後に動作実行中、ソースデータベースシステムＡとつながっ
ているすべてのシステムに対しそれぞれ変更を加えることである。
【０１５７】
この機能は２つのサブステップで提供される：
ａ）実施された変更についてソースデータベースシステムに通知
ｂ）変更およびその処理ならびに後続処理のためそれに続いてターゲットデータ
ベースシステムへ転送 通例、実施された変更について通知するために変更ポインタが用いられるけれ
ども、これは著しい欠点をもっている。まず第１に、起こり得る変更ごとにソー
スデータベースシステムのアプリケーションに変更ポインタを設けなければなら
ない。これはたいていすべてのデータオブジェクトについて不可能なことである
が、少なくとも非常に手間がかかるしクリティカルなエラーの原因となる。他方
、変更の通知はまえもって定められたタイムインターバルでしか行われない。
ベースシステムへ転送 通例、実施された変更について通知するために変更ポインタが用いられるけれ
ども、これは著しい欠点をもっている。まず第１に、起こり得る変更ごとにソー
スデータベースシステムのアプリケーションに変更ポインタを設けなければなら
ない。これはたいていすべてのデータオブジェクトについて不可能なことである
が、少なくとも非常に手間がかかるしクリティカルなエラーの原因となる。他方
、変更の通知はまえもって定められたタイムインターバルでしか行われない。
【０１５８】
このような部分的な問題点を解決するため、本発明によれば有利にはイベント
技術が利用される。ソースデータベースシステムにおけるデータベースＯＬＴＰ
−ＤＢへ変更を加えるルーチンに、イベント発生が組み込まれる。イベントディ
ストリビュータＥＤを介して、イベントに対する予約を扱うファンクションモジ
ュールがイベント発生時に呼び出される。このファンクションモジュールには、
ターゲットデータベースシステムの相応のモジュール（図５では結果セーブエー
ジェントＲＳＡのコンポーネント）が属している。このようにしてＭＳシステム
におけるＯＬＴＰ−Ｒ／３アダプタ（つまり一般的にいえばターゲットシステム
のモジュール）は、ターゲットシステムに関連するソースデータベースシステム
内の変更に関する情報をほぼ同時に受け取る。
技術が利用される。ソースデータベースシステムにおけるデータベースＯＬＴＰ
−ＤＢへ変更を加えるルーチンに、イベント発生が組み込まれる。イベントディ
ストリビュータＥＤを介して、イベントに対する予約を扱うファンクションモジ
ュールがイベント発生時に呼び出される。このファンクションモジュールには、
ターゲットデータベースシステムの相応のモジュール（図５では結果セーブエー
ジェントＲＳＡのコンポーネント）が属している。このようにしてＭＳシステム
におけるＯＬＴＰ−Ｒ／３アダプタ（つまり一般的にいえばターゲットシステム
のモジュール）は、ターゲットシステムに関連するソースデータベースシステム
内の変更に関する情報をほぼ同時に受け取る。
【０１５９】
これに続いて行われるソースデータベースシステムからターゲットデータベー
スシステムへの変更の伝送は、ターゲットデータベースシステム内に格納されて
いる既述のフィルタ基準ＦＤ（図１２）に基づき実施される。その後、上述のデ
ータマージ手順を用いてデータが処理され、やはりすでに説明したやり方でシス
テムを超えたクロスシステムプライマリキー（cross-system primary key）が生
成される。
スシステムへの変更の伝送は、ターゲットデータベースシステム内に格納されて
いる既述のフィルタ基準ＦＤ（図１２）に基づき実施される。その後、上述のデ
ータマージ手順を用いてデータが処理され、やはりすでに説明したやり方でシス
テムを超えたクロスシステムプライマリキー（cross-system primary key）が生
成される。
【０１６０】
データ伝送のその他の特殊性として挙げられるのは、（殊にデルタダウンロー
ドにあたり）以下で説明するネットフィールド決定（net-field determination
）が用いられることである。
ドにあたり）以下で説明するネットフィールド決定（net-field determination
）が用いられることである。
【０１６１】
互いに無関係に同じデータセットにアクセスする多数のユーザによって実施さ
れる変更が相互に書き換えられるのを最小限に抑えるために有利であるのは、個
々のデータセットにおいて変更されたフィールドだけを伝送することである。こ
のことをネットフィールド伝送（net-field transmission）と称する。しかしな
がら、たとえばＯＬＴＰ−Ｒ／３システムなどのようなＥＲＰバックオフィスシ
ステムは一般に「すべて込みのフィールドないしはオールフィールド（all-fiel
d）」ベースでしか通信できず、つまりこのシステムはフィールド内容全体を伴
ってデータセット全体を一度に伝送するだけである。したがってデータはデータ
チャネルＤＬ（図１２）を介してオールフィールドベースでターゲットシステム
ＭＳに転送され、これはそのような転送が結果伝送部ＲＳによってトリがされた
ときに行われる。この欠点は本発明の有利な実施形態によれば次のようにして解
消される。すなわち、ターゲットシステムつまり統合データベースＣＤのデータ
ベースサービスＣＤＳにおいて、フィールド平面における有効な変更が統合デー
タベースＣＤの内容との比較により求められ、実際の変更だけがネットフィール
ドベースで後続処理に関与させるのである。
れる変更が相互に書き換えられるのを最小限に抑えるために有利であるのは、個
々のデータセットにおいて変更されたフィールドだけを伝送することである。こ
のことをネットフィールド伝送（net-field transmission）と称する。しかしな
がら、たとえばＯＬＴＰ−Ｒ／３システムなどのようなＥＲＰバックオフィスシ
ステムは一般に「すべて込みのフィールドないしはオールフィールド（all-fiel
d）」ベースでしか通信できず、つまりこのシステムはフィールド内容全体を伴
ってデータセット全体を一度に伝送するだけである。したがってデータはデータ
チャネルＤＬ（図１２）を介してオールフィールドベースでターゲットシステム
ＭＳに転送され、これはそのような転送が結果伝送部ＲＳによってトリがされた
ときに行われる。この欠点は本発明の有利な実施形態によれば次のようにして解
消される。すなわち、ターゲットシステムつまり統合データベースＣＤのデータ
ベースサービスＣＤＳにおいて、フィールド平面における有効な変更が統合デー
タベースＣＤの内容との比較により求められ、実際の変更だけがネットフィール
ドベースで後続処理に関与させるのである。
【０１６２】
詳しくはこれがどのように行われるかについて、次に図１３および図１４を参
照しながら説明する。
照しながら説明する。
【０１６３】
ネットフィールド伝送を支援するため、ＢＤｏｃ（すなわちターゲットデータ
ベースシステムのデータオブジェクト）のすべてのセグメント、変更されたフィ
ールドを反映するフィールドが挿入される。このフィールドを送信ビットフィー
ルド send-bit field SBF と称する。これはたとえばＲＡＷ（３２）タイプのも
のとすることができ、バイナリ表示で（好適にはＨＥＸで格納されるかたちで）
変更を受けたフィールドに対応する各ポジションにおいて「１」を有している。
図１３には、送信ビット情報ＳＢＦとフィールド情報ＦＩＮとの対応関係が描か
れている。この場合、消去も変更として表される。図示の事例ではたとえばフィ
ールド１およびフィールド４のフィールド内容が（「Ａ」と「Ｃ」に）変更され
ており、フィールド２およびフィールド８のフィールド内容が消去されている。
付加的なフィールドＳＢＦのフィールド内容は、フィールドの個数に対応するビ
ット数をもつ関連部分Ｒと無視される非関連部分Ｌによって構成されている。
ベースシステムのデータオブジェクト）のすべてのセグメント、変更されたフィ
ールドを反映するフィールドが挿入される。このフィールドを送信ビットフィー
ルド send-bit field SBF と称する。これはたとえばＲＡＷ（３２）タイプのも
のとすることができ、バイナリ表示で（好適にはＨＥＸで格納されるかたちで）
変更を受けたフィールドに対応する各ポジションにおいて「１」を有している。
図１３には、送信ビット情報ＳＢＦとフィールド情報ＦＩＮとの対応関係が描か
れている。この場合、消去も変更として表される。図示の事例ではたとえばフィ
ールド１およびフィールド４のフィールド内容が（「Ａ」と「Ｃ」に）変更され
ており、フィールド２およびフィールド８のフィールド内容が消去されている。
付加的なフィールドＳＢＦのフィールド内容は、フィールドの個数に対応するビ
ット数をもつ関連部分Ｒと無視される非関連部分Ｌによって構成されている。
【０１６４】
データセットがオールフィールドベースでターゲットデータベースシステムへ
転送される場合、ターゲットデータベースシステムＭＳのデータベースとの調整
が行われる。この調整はデータベースＣＤのデータベースサービスＣＤＳにおい
て実行され、これについては図１４に描かれている。この場合、データセットＤ
１は、変更されたフィールド内容「Ｘ」をもちオールフィールドベースで伝送さ
れるデータセットの実例である。データベースサービスＣＤＳはそのデータセッ
トを、データベースＣＤ内に格納されている対応するデータセットＤ１′と比較
し、内容「Ｘ」をもつフィールドだけが変更されていることを確認する。これに
従い、変更された情報だけをもつデータセットＤ２が生成される。対応する送信
ビットは「１」にセットされている。残りのフィールド内容は空にされている。
転送される場合、ターゲットデータベースシステムＭＳのデータベースとの調整
が行われる。この調整はデータベースＣＤのデータベースサービスＣＤＳにおい
て実行され、これについては図１４に描かれている。この場合、データセットＤ
１は、変更されたフィールド内容「Ｘ」をもちオールフィールドベースで伝送さ
れるデータセットの実例である。データベースサービスＣＤＳはそのデータセッ
トを、データベースＣＤ内に格納されている対応するデータセットＤ１′と比較
し、内容「Ｘ」をもつフィールドだけが変更されていることを確認する。これに
従い、変更された情報だけをもつデータセットＤ２が生成される。対応する送信
ビットは「１」にセットされている。残りのフィールド内容は空にされている。
【０１６５】
ｃ）同期合わせ
冒頭で説明したコンテキストにおけるセマンティックな統合とは、システム間
の単純なデータ交換以上のことを意味している。可能性に応じてアプリケーショ
ンの動作を、有効データの処理の基礎を成すロジック（ビジネスロジック "busi
ness logic"）に近づけるようにする。ビジネスロジックは、個々のデータベー
スシステムのレポジトリに格納されている制御データに高度に反映されており、
それらはたとえば値の範囲、フィールドやレコードやデータベースの妥当性など
のようなロジックをマッピングする。このためセマンティックな統合においては
、レポジトリ制御情報もクロスシステムでレプリケーションされるようにする。
ＯＬＴＰ−Ｒ／３システムの事例では、これはいわゆるカスタマイズテーブル（
Ｔテーブル）である。しかしながらカスタマイズテーブルにおける変更は、ＯＬ
ＴＰ−Ｒ／３システムでは変更ポインタによってもイベントによっても指示され
ない。このため適切な更新メカニズムを利用できなければ、ＭＳシステムなどの
ターゲットデータベースシステムにおいてこれらのデータのレプリカは急速に古
くなってしまう。
の単純なデータ交換以上のことを意味している。可能性に応じてアプリケーショ
ンの動作を、有効データの処理の基礎を成すロジック（ビジネスロジック "busi
ness logic"）に近づけるようにする。ビジネスロジックは、個々のデータベー
スシステムのレポジトリに格納されている制御データに高度に反映されており、
それらはたとえば値の範囲、フィールドやレコードやデータベースの妥当性など
のようなロジックをマッピングする。このためセマンティックな統合においては
、レポジトリ制御情報もクロスシステムでレプリケーションされるようにする。
ＯＬＴＰ−Ｒ／３システムの事例では、これはいわゆるカスタマイズテーブル（
Ｔテーブル）である。しかしながらカスタマイズテーブルにおける変更は、ＯＬ
ＴＰ−Ｒ／３システムでは変更ポインタによってもイベントによっても指示され
ない。このため適切な更新メカニズムを利用できなければ、ＭＳシステムなどの
ターゲットデータベースシステムにおいてこれらのデータのレプリカは急速に古
くなってしまう。
【０１６６】
このような事例においてもソースシステムとターゲットシステムとの間でデー
タ状態を絶えず同期合わせできるようにする目的で、すでに挙げたコンポーネン
ト「リクエスト」および「コンペア」が使われる。図１５および図１６には、こ
れによって実現される同期メカニズムが示されている。
タ状態を絶えず同期合わせできるようにする目的で、すでに挙げたコンポーネン
ト「リクエスト」および「コンペア」が使われる。図１５および図１６には、こ
れによって実現される同期メカニズムが示されている。
【０１６７】
リクエストコンポーネントは、すでに説明したように初回データダウンロード
と同じように動作する。任意のビジネスオブジェクトをＯＬＴＰ−Ｒ／３システ
ムからＭＳシステムへダウンロードするために、汎用抽出部 general extractor ＧＥと呼ばれるモジュールが用いられ、これはフィルタ定義ＦＤに従い抽出部
マスタＥＭによって呼び出される。
と同じように動作する。任意のビジネスオブジェクトをＯＬＴＰ−Ｒ／３システ
ムからＭＳシステムへダウンロードするために、汎用抽出部 general extractor ＧＥと呼ばれるモジュールが用いられ、これはフィルタ定義ＦＤに従い抽出部
マスタＥＭによって呼び出される。
【０１６８】
このようにしてダウンロードされたデータが統合データベースＣＤへ取り込ま
れる前に、図１５においてＣＯＭＰの付されたコンペアモジュールが呼び出され
る。このコンペアモジュールはダウンロードされたデータをすでにデータベース
ＣＤ内に存在しているデータと比較し、実際に変更されたデータだけを通過させ
る。さらにこのモジュールは、もはやオリジナル中には存在していないデータに
対する消去指示も発する。
れる前に、図１５においてＣＯＭＰの付されたコンペアモジュールが呼び出され
る。このコンペアモジュールはダウンロードされたデータをすでにデータベース
ＣＤ内に存在しているデータと比較し、実際に変更されたデータだけを通過させ
る。さらにこのモジュールは、もはやオリジナル中には存在していないデータに
対する消去指示も発する。
【０１６９】
図１６にはこのために使用されるアルゴリズムが示されている。準備過程にお
いてまずはじめにＯＬＴＰ−Ｒ／３システムから受け取ったデータおよびこれに
対してそれぞれ対応するデータベースＣＤからのテーブルが、それぞれメモリロ
ケーションＳ２もしくはＳ２に用意される。データベースＣＤから対応するテー
ブルを選択する際、ＭＳシステム内にしか含まれていないすべてのレコード（図
１６ではレコードレコードｍ１，ｍ２）は選択されないよう、データがフィルタ
リングされる。その他のレコードにもＭＳ固有のデータを有するフィールドが含
まれている。データ伝送時のさらに別の制限によって、メモリ領域Ｓ１にはＯＬ
ＴＰ−Ｒ／３システムにおいても利用可能なデータだけが供給されるようになる
。
いてまずはじめにＯＬＴＰ−Ｒ／３システムから受け取ったデータおよびこれに
対してそれぞれ対応するデータベースＣＤからのテーブルが、それぞれメモリロ
ケーションＳ２もしくはＳ２に用意される。データベースＣＤから対応するテー
ブルを選択する際、ＭＳシステム内にしか含まれていないすべてのレコード（図
１６ではレコードレコードｍ１，ｍ２）は選択されないよう、データがフィルタ
リングされる。その他のレコードにもＭＳ固有のデータを有するフィールドが含
まれている。データ伝送時のさらに別の制限によって、メモリ領域Ｓ１にはＯＬ
ＴＰ−Ｒ／３システムにおいても利用可能なデータだけが供給されるようになる
。
【０１７０】
ついでメモリ領域Ｓ１とＳ２の内容の比較が行われ、これによればテーブルの
一方が基準として選択され、そのテーブルにういて最初から最後まで段階的に進
められ、他方のテーブルにおいて対応するエントリが探索される。この場合、パ
フォーマンスの理由で有利であるのは、エントリの個数の僅かな方のメモリテー
ブル（図１６ではメモリ領域）を基準として選択することである。比較結果に依
存して以下のような相応のアクションが導入される： 新しいエントリの生成： ”Ｉ” ネットフィールドエントリの生成： ”Ｕ” 消去指示の生成： ”Ｄ” アルゴリズムは以下のように表すことができる： Ｓ１内のすべてのエントリについて｛ Ｓ２内で得られるならば｛ 該当しない先行のすべてのＳ２エントリについて新たなエントリ（”Ｉ
”）を生成 変更であれば ネットフィールドエントリ（”Ｕ”）を生成 ｝そうでなければ 消去指示（”Ｄ”）を生成 ｝ ４．アップロード 既述のように、データベースシステムのセマンティックな統合の基本的な要素
は、データのエントリや変更を１つのデータベース内だけでなく互いに結合され
た複数のデータベースまたはすべてのデータベースにおいて実行できるようにす
ることである。したがってたとえば、外勤従業員はカスタマにおいて新たなデー
タ（たとえば新たなオーダ）を自身のポータブルコンピュータに入力し、そのデ
ータセットにおけるそのような変更をデータベースＯＬＴＰ−ＤＢにおいて持続
的なものとすることができるようにすべきである。
一方が基準として選択され、そのテーブルにういて最初から最後まで段階的に進
められ、他方のテーブルにおいて対応するエントリが探索される。この場合、パ
フォーマンスの理由で有利であるのは、エントリの個数の僅かな方のメモリテー
ブル（図１６ではメモリ領域）を基準として選択することである。比較結果に依
存して以下のような相応のアクションが導入される： 新しいエントリの生成： ”Ｉ” ネットフィールドエントリの生成： ”Ｕ” 消去指示の生成： ”Ｄ” アルゴリズムは以下のように表すことができる： Ｓ１内のすべてのエントリについて｛ Ｓ２内で得られるならば｛ 該当しない先行のすべてのＳ２エントリについて新たなエントリ（”Ｉ
”）を生成 変更であれば ネットフィールドエントリ（”Ｕ”）を生成 ｝そうでなければ 消去指示（”Ｄ”）を生成 ｝ ４．アップロード 既述のように、データベースシステムのセマンティックな統合の基本的な要素
は、データのエントリや変更を１つのデータベース内だけでなく互いに結合され
た複数のデータベースまたはすべてのデータベースにおいて実行できるようにす
ることである。したがってたとえば、外勤従業員はカスタマにおいて新たなデー
タ（たとえば新たなオーダ）を自身のポータブルコンピュータに入力し、そのデ
ータセットにおけるそのような変更をデータベースＯＬＴＰ−ＤＢにおいて持続
的なものとすることができるようにすべきである。
【０１７１】
モバイルクライアントのレベルにおける変更は、図２を参照しながら説明した
トランザクション層によって登録され、その際、このトランザクション層を介し
てモバイルクライアントはＭＳシステムおよびその固有のローカルデータベース
ＬＤと通信する。ポータブルコンピュータがミドルウェアサーバＭＳと接続され
る場合、変更されたデータがＢＤｏｃとして伝達され、バックオフィスシステム
ＯＬＴＰ−Ｒ／３にも伝送される。このために用いられるコンポーネントは図５
を参照しながらすでに説明しており、その際に実行されるデータマージ手順につ
いては図１１を参照しながらすでに説明した。
トランザクション層によって登録され、その際、このトランザクション層を介し
てモバイルクライアントはＭＳシステムおよびその固有のローカルデータベース
ＬＤと通信する。ポータブルコンピュータがミドルウェアサーバＭＳと接続され
る場合、変更されたデータがＢＤｏｃとして伝達され、バックオフィスシステム
ＯＬＴＰ−Ｒ／３にも伝送される。このために用いられるコンポーネントは図５
を参照しながらすでに説明しており、その際に実行されるデータマージ手順につ
いては図１１を参照しながらすでに説明した。
【０１７２】
このようなデータアップロードにおける基本的な要求は適切なコンフリクト対
策の開発であり、その目的は様々な場所でエントリされたり変更されたりする各
データ間のコンフリクトを阻止することである。結合システムにおいてそのつど
１つの特定の個所においてのみデータの変更を許可するようにしたいわゆる「デ
ータメンテナンス優位（data maintenance ascendencies）」の定義であると、
十分な統合を提供することはできない。多くの適用事例において用いられている
ＬＯＷ（Last One Wins）方式も、ＥＲＰバックオフィスシステムのデータを含
むこのような結合システムには適していない。
策の開発であり、その目的は様々な場所でエントリされたり変更されたりする各
データ間のコンフリクトを阻止することである。結合システムにおいてそのつど
１つの特定の個所においてのみデータの変更を許可するようにしたいわゆる「デ
ータメンテナンス優位（data maintenance ascendencies）」の定義であると、
十分な統合を提供することはできない。多くの適用事例において用いられている
ＬＯＷ（Last One Wins）方式も、ＥＲＰバックオフィスシステムのデータを含
むこのような結合システムには適していない。
【０１７３】
したがって本発明においては、ＬＳＣ（Leading System Concept）と称する新
規のコンフリクト対策が用いられる。ＬＳＣ方式は、各データオブジェクトごと
に管理する側のシステム（ＦＳ）を定義する。結合システムにおける他のすべて
のシステムは管理される側のシステム（ＧＳ）である。ＧＳの各変更はまずはじ
め、ＦＳによって操作しなければならない。通常の操作機能に対する基本的な相
違点は、これはアプリケーションの境界を超えたファンクションであり、構造に
互換性のない各システム間のコンフリクトを解消するために用いられる。
規のコンフリクト対策が用いられる。ＬＳＣ方式は、各データオブジェクトごと
に管理する側のシステム（ＦＳ）を定義する。結合システムにおける他のすべて
のシステムは管理される側のシステム（ＧＳ）である。ＧＳの各変更はまずはじ
め、ＦＳによって操作しなければならない。通常の操作機能に対する基本的な相
違点は、これはアプリケーションの境界を超えたファンクションであり、構造に
互換性のない各システム間のコンフリクトを解消するために用いられる。
【０１７４】
ＬＳＣ方式のインプリメントのためには、あとで説明する特別な機能が必要と
される。
される。
【０１７５】
ここで説明している実施例の場合、ＭＳシステムはすべてのデータオブジェク
トついて管理される側のシステムである。管理される側のシステムは、以下の要
求を満たすことができなければならない。
トついて管理される側のシステムである。管理される側のシステムは、以下の要
求を満たすことができなければならない。
【０１７６】
−ユーザはデータの表示においていつでもその確認状態（承諾、拒否、未定）を
識別できなければならない。
識別できなければならない。
【０１７７】
−ユーザは自身の変更したデータを拒否するときに再びもとの値にアクセスでき
なければならない。
なければならない。
【０１７８】
−データオブジェクトは変更が確認されるまでロックされてはならない。つまり
同じデータオブジェクトにおいてチェックすべき複数の変更を先行のチェックの
終了を待たずとも相次いで続けることができなければならない。
同じデータオブジェクトにおいてチェックすべき複数の変更を先行のチェックの
終了を待たずとも相次いで続けることができなければならない。
【０１７９】
−結合されたシステム全体におけるデータの一致性を保証しなければならない。
【０１８０】
これらの要求はとりわけ２つのファンクションモジュールによって満たすこと
ができ、それらをペンディングカウンタ（ＰＣ）およびインボックス（ＩＢ）と
称する。
ができ、それらをペンディングカウンタ（ＰＣ）およびインボックス（ＩＢ）と
称する。
【０１８１】
ペンディングカウンタはＣｈａｒ（４）フィールドであり、これはデータ交換
に関与するテーブルごとに（つまりＢＤｏｃの各セグメントに）存在する。この
フィールドを介して、データの目下の確認状態が定義される。これによってコン
トロールフラグが形成され、これはデータの確認状態をたとえば画面上に視覚的
に表示するためにアプリケーションプログラムによって評価される。
に関与するテーブルごとに（つまりＢＤｏｃの各セグメントに）存在する。この
フィールドを介して、データの目下の確認状態が定義される。これによってコン
トロールフラグが形成され、これはデータの確認状態をたとえば画面上に視覚的
に表示するためにアプリケーションプログラムによって評価される。
【０１８２】
ペンディングカウンタは以下のかたちをとる：
”Ｏ”： ＯＫ
Ｐ＜ｎ＞： ペンディング（＝保留、まだ確認されていない）、ここで＜ｎ＞は
基準カウンタとして変更の回数をカウントアップする。
基準カウンタとして変更の回数をカウントアップする。
【０１８３】
Ｆ＜ｎ＞： データセットはエラー状態にある。
【０１８４】
ペンディングカウンタは変更のたびにカウントアップされ、管理する側のシス
テムによって確認されると再び”０”になるまで再びカウントダウンされる。拒
否の場合にもカウントダウンされるが、”Ｐ”ではなく”Ｆ”がセットされる。
テムによって確認されると再び”０”になるまで再びカウントダウンされる。拒
否の場合にもカウントダウンされるが、”Ｐ”ではなく”Ｆ”がセットされる。
【０１８５】
システム全体のけるデータの一致性を保証するために必要とされるのは、変更
が承認されないときにはもとのデータ状態が管理される側のシステムにおいて再
び形成（ロールバック）されるようにすることである。これは有利には、管理す
る側のシステム（この実例ではＯＬＴＰ−Ｒ／３システム）が拒否と同時に（上
述のように）データオブジェクトに含まれている「先行状態のイメージ（before image）」ＢＩを管理される側のシステムへ送り戻すことによって行われる。こ
のようにしてオリジナル状態を取り戻すことでロールバックを行うことができる
。
が承認されないときにはもとのデータ状態が管理される側のシステムにおいて再
び形成（ロールバック）されるようにすることである。これは有利には、管理す
る側のシステム（この実例ではＯＬＴＰ−Ｒ／３システム）が拒否と同時に（上
述のように）データオブジェクトに含まれている「先行状態のイメージ（before image）」ＢＩを管理される側のシステムへ送り戻すことによって行われる。こ
のようにしてオリジナル状態を取り戻すことでロールバックを行うことができる
。
【０１８６】
しかしながらこのようなやり方の欠点は、これにより個々のデータオブジェク
トにおけるユーザの変更すべてが上書きされることにある。たとえばこれが１０
０個以上の項目を含むオーダであって、それが場合によっては比較的僅かな不一
致ゆえに拒否された場合には、変更のもととなった誤りのあるデータオブジェク
トつまりはそれゆえに承認されなかったデータオブジェクトのデータを再びユー
ザが利用できるようにしなければならない。これはインボックスによって行われ
る。この場合、ユーザはエントリを便利なように整合させることができ、再び利
用可能にすることができる。
トにおけるユーザの変更すべてが上書きされることにある。たとえばこれが１０
０個以上の項目を含むオーダであって、それが場合によっては比較的僅かな不一
致ゆえに拒否された場合には、変更のもととなった誤りのあるデータオブジェク
トつまりはそれゆえに承認されなかったデータオブジェクトのデータを再びユー
ザが利用できるようにしなければならない。これはインボックスによって行われ
る。この場合、ユーザはエントリを便利なように整合させることができ、再び利
用可能にすることができる。
【０１８７】
図１７には１つの実施例に基づき、ペンディングカウンタおよびインボックス
のファンクションが描かれている。その際、ＬＤの付された行は、ペンディング
カウンタＰＣの状態を表すフィールドとプライマリキーフィールドＫと３つのデ
ータフィールドＤをそれぞれ有するローカルデータベースの内容をシンボリック
に表している。
のファンクションが描かれている。その際、ＬＤの付された行は、ペンディング
カウンタＰＣの状態を表すフィールドとプライマリキーフィールドＫと３つのデ
ータフィールドＤをそれぞれ有するローカルデータベースの内容をシンボリック
に表している。
【０１８８】
第１のステップにおいて、まん中のデータフィールドの内容が変更される。情
報をＯＬＴＰ−Ｒ／３システムへ伝達するＢＤｏｃには、変更された情報「２」
しか含まれていない。
報をＯＬＴＰ−Ｒ／３システムへ伝達するＢＤｏｃには、変更された情報「２」
しか含まれていない。
【０１８９】
次のステップにおいて２つのデータフィールドが変更される。変更された情報
「Ｂ」と「３」も同様にＢＤｏｃとして伝送される。さらに第４のステップにお
いて第１の変更の確認が行われ、第５のステップにおいて第２の変更の確認が行
われる。ペンディングカウンタＰＣはそれぞれ確認状態を表す。
「Ｂ」と「３」も同様にＢＤｏｃとして伝送される。さらに第４のステップにお
いて第１の変更の確認が行われ、第５のステップにおいて第２の変更の確認が行
われる。ペンディングカウンタＰＣはそれぞれ確認状態を表す。
【０１９０】
第６のステップにおいて管理する側のシステムにとって承認されない変更が行
われ、これには星型のシンボルが付されている。この変更はエラーメッセージ「
Ｅ」として拒否され、その結果、第８のステップにおいてその変更前の状態がリ
ストアされる。これと同時に、（拒絶された）変更された状態がインボックスに
配置され、これによりユーザはそれについて処理を続けることができる。その間
に第７のステップで行われた第１のフィールドにおける許可された変更が、第９
のステップにおいて確認される。
われ、これには星型のシンボルが付されている。この変更はエラーメッセージ「
Ｅ」として拒否され、その結果、第８のステップにおいてその変更前の状態がリ
ストアされる。これと同時に、（拒絶された）変更された状態がインボックスに
配置され、これによりユーザはそれについて処理を続けることができる。その間
に第７のステップで行われた第１のフィールドにおける許可された変更が、第９
のステップにおいて確認される。
【０１９１】
先行イメージ（before image）の生成は、リジェクトサービスを用いたＭＳシ
ステムのフローコントロールの制御のもとで行われる。これはＢＤｏｃのヘッダ
にセットされたフラグに基づき、ＢＤｏｃ全体が承認されたのか拒否されたのか
をチェックする。拒否の場合、リジェクトサービスはＢＤｏｃの全データを統合
データベースＣＤから抽出し、それをＢＤｏｃ内で先行イメージとして利用でき
るようにする。ＢＤｏｃ全体が承認されればリジェクトサービスはその部分セグ
メントをその状態についてチェックする。部分セグメントが拒否された場合には
その内容がやはり統合データベースＣＤから抽出され、先行イメージにおいて得
られるようにする。
ステムのフローコントロールの制御のもとで行われる。これはＢＤｏｃのヘッダ
にセットされたフラグに基づき、ＢＤｏｃ全体が承認されたのか拒否されたのか
をチェックする。拒否の場合、リジェクトサービスはＢＤｏｃの全データを統合
データベースＣＤから抽出し、それをＢＤｏｃ内で先行イメージとして利用でき
るようにする。ＢＤｏｃ全体が承認されればリジェクトサービスはその部分セグ
メントをその状態についてチェックする。部分セグメントが拒否された場合には
その内容がやはり統合データベースＣＤから抽出され、先行イメージにおいて得
られるようにする。
【０１９２】
管理する側のシステムはＬＳＣ手順において、到来するデータをチェックし必
要であれば拒否できるようでなくてはならない。このような機能はバックオフィ
スシステムにおいては一般に実装されている。この関連でやはり重要なその他の
機能についてはすでに説明した。これにはデータマージ手順との関連で説明した
受け入れの事例におけるデータ補足や、同じく説明済みの管理する側のシステム
のプライマリキーの伝送が含まれる。
要であれば拒否できるようでなくてはならない。このような機能はバックオフィ
スシステムにおいては一般に実装されている。この関連でやはり重要なその他の
機能についてはすでに説明した。これにはデータマージ手順との関連で説明した
受け入れの事例におけるデータ補足や、同じく説明済みの管理する側のシステム
のプライマリキーの伝送が含まれる。
【０１９３】
５．これまで説明してきた結合システムの拡充ならびに変形
これまで示してきた実施例では基本的に、ＣＲＭフロントオフィスシステムの
中央計算部を成すミドルウェアサーバＭＳとＥＲＰバックオフィスシステムの実
例としてのＯＬＴＰ−Ｒ／３システムとの間のデータ交換について説明してきた
。
中央計算部を成すミドルウェアサーバＭＳとＥＲＰバックオフィスシステムの実
例としてのＯＬＴＰ−Ｒ／３システムとの間のデータ交換について説明してきた
。
【０１９４】
とはえいえ既述の手順やアルゴリズムを他の事例にも適用することができる。
たとえばミドルウェアシステムＭＳは既述の手順を利用して様々な別のデータベ
ースシステムと利用することができる。それらのデータベースの論理構造は処理
されるオブジェクトのレベルで少なくともオーバラップ部分をもっている一方、
それらの構造はプログラミング技術的実装のレベルでは互換性のないものである
。したがってＭＳシステムを、既述の手順を利用して様々な外部のデータシステ
ム間の交換システムとして利用することができる。
たとえばミドルウェアシステムＭＳは既述の手順を利用して様々な別のデータベ
ースシステムと利用することができる。それらのデータベースの論理構造は処理
されるオブジェクトのレベルで少なくともオーバラップ部分をもっている一方、
それらの構造はプログラミング技術的実装のレベルでは互換性のないものである
。したがってＭＳシステムを、既述の手順を利用して様々な外部のデータシステ
ム間の交換システムとして利用することができる。
【図１】
オフライン分散型データベースにおける本発明による結合システムの環境の外
観を示す図である。
観を示す図である。
【図２】
本発明において適用されるフロントオフィスシステムのアーキテクチャに関す
る概観をＣＲＭシステムの実例で示す図である。
る概観をＣＲＭシステムの実例で示す図である。
【図３】
図２によるシステムのフローコントロールの典型的な流れをデータアップロー
ドプロセスの実例として示す図である。
ドプロセスの実例として示す図である。
【図４】
図２によるシステムで適用されるデータオブジェクト（”ＢＤｏｃ”）の構造
を示す図である。
を示す図である。
【図５】
本発明に従って互いに結合された２つのシステムにおいてデータのアップロー
ドおよびダウンロード時にはたらくコンポーネントのアーキテクチャを示す図で
ある。
ドおよびダウンロード時にはたらくコンポーネントのアーキテクチャを示す図で
ある。
【図６】
ダウンロードの事例に関する図３に応じたフローチャートを示す図である。
【図７】
関与するデータベースシステムに他のデータベースシステム内に含まれている
データを初回にダウンロードするためのコンポーネントのアーキテクチャを示す
図である。
データを初回にダウンロードするためのコンポーネントのアーキテクチャを示す
図である。
【図８】
必要とされるプライマリキーをシステムを超えて供給する方法を説明するため
の原理図である。
の原理図である。
【図９】
ＢＤｏｃおよび属するキーマッピングテーブルのセグメント構造に関する実例
を示す図である。
を示す図である。
【図１０】
いくらか複雑なセグメント構造を有する図９によるＢＤｏｃの構造に関する実
例である。
例である。
【図１１】
本発明に適したデータマージ手順の原理を説明する図である。
【図１２】
初回ダウンロードにおける基本コンポーネントの共働の様子を示す基本原理で
ある。
ある。
【図１３】
本発明に適したネットフィールド伝送手順を説明するための２つの図である。
【図１４】
本発明に適したネットフィールド伝送手順を説明するための２つの図である。
【図１５】
データを同期合わせする手順を説明するための基本コンポーネントの原理図で
ある。
ある。
【図１６】
本発明に適した「コンペア」モジュールの機能を説明するための基本原理図で
ある。
ある。
【図１７】
本発明に適したデータアップデート時のコンフリクトを解消する手順の原理図
である。
である。
─────────────────────────────────────────────────────
フロントページの続き
(81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，
ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ
Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ
，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，
ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ
Ｅ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ
，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，
ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，
ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，Ｃ
Ａ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ
，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，
ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，Ｋ
Ｅ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ
，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，
ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ
Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ
，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，
ＹＵ，ＺＡ，ＺＷ
Claims (16)
- 【請求項１】 ２つのデータベースシステムＡとＢとの間でデータを交換す
る方法であって、 データベースシステムの各々は、格納されているデータオブジェクトの一義的
な識別のため、各データオブジェクトごとにプライマリキー生成ロジックを用い
てシステム固有のプライマリキー（ＫＡないしはＫＢ）を生成し、両方のデータ
ベースシステムＡおよびＢのプライマリキー生成ロジックは互いに独立しており
、 ソースデータベースシステムＡ（ＯＬＴＰ−Ｒ／３）からターゲットデータベ
ースシステムＢ（ＭＳ）へ伝送されるデータオブジェクトについて、システムを
超えて共有される新しいエントリに必要とされる一義的な識別を可能にするため
、 ａ）ソースデータベースシステムＡからターゲットデータベースシステムＢへ
伝送すべきデータオブジェクトのプライマリキー（ＫＡ）をキーマッピングテー
ブル（ＫＭＴ）と比較するステップを実行し、該キーマッピングテーブルは、す
でに２つのプライマリキー（ＫＡおよびＫＢ）の生成されているすべてのデータ
オブジェクトのプライマリキー（ＫＡおよびＫＢ）を有しており、 ｂ）プライマリキー（ＫＡ）が前記キーマッピングテーブル（ＫＭＴ）内にま
だ存在していなければ、プライマリキージェネレータ（ＫＧ）によって自動的に
ターゲットデータベースシステムＢのプライマリキー（ＫＢ）を生成してデータ
オブジェクト内に格納し、ソースデータベースシステムＡのプライマリキー（Ｋ Ａ ）といっしょに前記キーマッピングテーブル（ＫＭＴ）に格納するステップと
、 ｃ）ソースデータベースシステムＡのプライマリキー（ＫＡ）が前記キーマッ
ピングテーブル（ＫＭＴ）内で見つけられたならば、ターゲットシステムＢの対
応するプライマリキー（ＫＢ）をデータオブジェクトに格納するステップを実行
することを特徴とする、 ２つのデータベースシステムＡとＢとの間でデータを交換する方法。 - 【請求項２】 前記プライマリキージェネレータ（ＫＧ）をターゲットデー
タベースシステムＢ内に統合する、請求項１記載の方法。 - 【請求項３】 ターゲットデータベースシステムＢ（ＭＳ）のプライマリキ
ー（ＫＢ，ＫＭＳ）は、ソースデータベースシステムＡ（ＯＬＴＰ−Ｒ／３）の
データベースに格納されているデータの一部分ではない、請求項１または２記載
の方法。 - 【請求項４】 ソースデータベースシステムＡ（ＯＬＴＰ−Ｒ／３）へデー
タオブジェクトを送り戻すとき、ソースデータベースシステムＢ（ＭＳ）のプラ
イマリキー（ＫＢ，ＫＭＳ）を該データオブジェクトから分離して保管する、請
求項３記載の方法。 - 【請求項５】 第１のデータベースシステムＡ（ＯＬＴＰ−Ｒ／３）内のデ
ータセットにおいて実行された変更に基づき第２のデータベースシステムＢ（Ｍ
Ｓ）内のデータセットを更新する方法であって、 第１のデータベースシステムＡ（ＯＬＴＰ−Ｒ／３）のデータセットは、第２
のデータベースシステムＢ（ＭＳ）には関連しないデータ（ＤＲ／３）も、第２
のデータベースシステムＢに関連するデータ（ＤＭＩＸ）も有しており、 各データベースシステムにおけるデータを、それぞれシステム固有のプライマ
リキー（ＫＭＳ，ＫＲ／３）を有するデータオブジェクトのかたちで処理し、 該データを第２のデータベースシステムＢ（ＭＳ）において両方のシステム固
有のプライマリキー（ＫＲ／３およびＫＭＳ）とともに格納し、 ａ）第２のデータベースシステムＢ（ＭＳ）には関連しないデータ（ＤＲ／３ ）をデータオブジェクトから分離するステップと、 ｂ）第１のデータベースシステムＡ（ＯＬＴＰ−Ｒ／３）から第２のデータベ
ースシステムＢ（ＭＳ）へデータオブジェクトを転送するステップと、 ｃ）データベースシステムＢ（ＭＳ）に固有のキー（ＫＭＳ）を生成し、生成
されたキー（ＫＭＳ）をデータオブジェクトに追加するステップと、 ｄ）生じたデータオブジェクト（ＢＤｏｃ）を第２のデータベースシステムＢ
（ＭＳ）の格納ルーチンに組み込み、該データオブジェクト中に含まれているデ
ータを第２のデータベースシステムＢ（ＭＳ）のデータベース（ＣＤ）に格納す
るステップの少なくとも一部を実行することを特徴とする、 第２のデータセットＢ内のデータセットを更新する方法。 - 【請求項６】 データオブジェクトのデータレコードを格納ルーチンに組み
込む前に補足値（ＤＭＳ）によって補い、該補足値は第２のデータベースシステ
ムＢ（ＭＳ）のデータセットに対応する、請求項５記載の方法。 - 【請求項７】 第２のデータベースシステムＢ（ＭＳ）内のデータセットに
おいて実行された変更に基づき第１のデータベースシステムＡ（ＯＬＴＰ−Ｒ／
３）内のデータセットを更新する方法であって、 第２のデータベースシステムＢ（ＭＳ）のデータセットは、第１のデータベー
スシステムＡ（ＯＬＴＰ−Ｒ／３）に関連しないデータ（ＤＭＳ）も第１のデー
タベースシステムＡに関連するデータ（ＤＭＩＸ）も有しており、 各データベースシステムにおけるデータをデータオブジェクトのかたちで処理
し、該データオブジェクトはそれぞれシステム固有のプライマリキー（ＫＭＳ，
ＫＲ／３）を有しており、 第１のデータベースシステムＡ（ＯＬＴＰ−Ｒ／３）内のデータをそのシステ
ム固有のプライマリキー（ＫＲ／３）とのみいっしょに格納する、 第１のデータベースシステムＡ内のデータセットを更新する方法において、 ａ）第１のデータベースシステムＡ（ＯＬＴＰ−Ｒ／３）に関連しないデータ
（ＤＭＳ）をデータオブジェクトから分離し、該データを第２のデータベースシ
ステムＢ（ＭＳ）内に保管するステップと、 ｂ）前記データオブジェクトを第２のデータベースシステムＢ（ＭＳ）から第
１のデータベースシステムＡ（ＯＬＴＰ−Ｒ／３）へ転送するステップと、 ｃ）第２のデータベースシステムＢ（ＭＳ）のためのシステム固有のキー（Ｋ ＭＳ ）を前記データオブジェクトから分離し、該キー（ＫＭＳ）を第１のデータ
ベースシステムＡ（ＯＬＴＰ−Ｒ／３）に保管するステップと、 ｄ）生じたデータオブジェクトを第１のデータベースシステムＡ（ＯＬＴＰ−
Ｒ／３）の格納ルーチンに取り込み、該データオブジェクトに含まれているデー
タを第１のデータベースシステムＡ（ＯＬＴＰ−Ｒ／３）のデータベースに格納
するステップの少なくとも一部を実行することを特徴とする、 第１のデータベースシステムＡ内のデータセットを更新する方法。 - 【請求項８】 前記データオブジェクトのデータレコードを格納ルーチンに
取り込む前に補足値（ＤＤ）で補い、該補足値は第１のデータベースシステムＡ
（ＯＬＴＰ−Ｒ／３）のデータセットに対応する、請求項７記載の方法。 - 【請求項９】 ｅ）第１のデータベースシステムＡ（ＯＬＴＰ−Ｒ／３）の
データベース（ＯＬＴＰ−ＤＢ）の格納の結果としてイベントをトリガするステ
ップと、 ｆ）第２のデータベースシステムＢ（ＭＳ）において前記イベントのために設
けられたコンポーネント（ＲＳＡ）によりイベントを受け取るステップと、 ｇ）データベースシステムＢ（ＭＳ）に固有の保管されたキー（ＫＭＳ）を追
加するステップと、 ｈ）第１のデータベースシステムＡ（ＯＬＴＰ−Ｒ／３）に固有のデータ（Ｄ Ｒ／３ ）を取り除くステップと、 ｉ）両方のデータベースシステムに関連するデータ（ＤＭＩＸ）、データベー
スシステムＢ（ＭＳ）に固有のキー（ＫＭＳ）およびデータベースシステムＡ（
ＯＬＴＰ−Ｒ／３）に固有のキー（ＫＲ／３）を有するデータオブジェクトとし
て、第２のデータベースシステムＢへデータを転送するステップと、 ｊ）第２のデータベースシステムＢ（ＭＳ）内に保管された第１のデータベー
スシステムに関連しないデータ（ＤＭＳ）を追加するステップの少なくとも一部
分を実行する、 請求項７または８記載の方法。 - 【請求項１０】 複数のデータベースシステム（ＯＬＴＰ−Ｒ／３，ＭＳ）
を有する統合システム内におけるデータの新たなエントリまたは変更のための方
法において、 前記統合システムにおけるデータベースシステムのうち任意の１つのデータベ
ース内で共有されるデータを新たにエントリする際にデータコンフリクトを避け
るため、各データベースシステム間で交換可能な各データオブジェクトごとに前
記データベースシステムの一方（ＯＬＴＰ−Ｒ／３）を管理する側のシステムＦ
Ｓとして定義し、 該管理する側のシステムＦＳ（ＯＬＴＰ−Ｒ／３）のデータセットにも属する
データオブジェクトのデータを、管理される側のシステムＧＳ（ＭＳ）において
新たにエントリまたは変更するたびに、システムを超えた確認アルゴリズムを実
行し、該アルゴリズムにおいて、 ａ）変更を含むデータオブジェクトを管理する側のシステムＦＳ（ＯＬＴＰ−
Ｒ／３）に伝送し、 ｂ）管理する側のシステムＦＳ内で、変更の承認または少なくとも部分的な拒
否として応答メッセージを生成し、 ｃ）応答メッセージを含むデータオブジェクトを管理される側のシステムＧＳ
（ＭＳ）へ送り戻すことを特徴とする、 複数のデータベースシステムを有する統合システム内におけるデータの新たな
エントリまたは変更のための方法。 - 【請求項１１】 管理される側のシステムＧＳ（ＭＳ）のデータベースＬＤ
は、変更されたデータオブジェクトの確認状態をカウンタフィールドを用いて記
録し、該カウンタフィールドの計数状態は該カウンタフィールドに割り当てられ
たデータセットにおいて変更が生じるたびにカウントアップし、応答メッセージ
のたびにカウントダウンして、管理される側のシステムＧＳ（ＭＳ）におけるカ
ウンタフィールドにより確認状態およびまだ応答のない変更の個数の表示を可能
にする、請求項１０記載の方法。 - 【請求項１２】 変更が少なくとも部分的に拒否された場合、データ変更前
の状態の先行イメージを利用して、管理される側のシステムＧＳ（ＭＳ）内でそ
の状態をリストアする、請求項１０または１１記載の方法。 - 【請求項１３】 エラーメッセージの場合、補正および後続処理のため管理
される側のシステムＧＳ（ＭＳ）において誤って変更された状態も利用可能にす
る、請求項１２記載の方法。 - 【請求項１４】 ディジタルコンピュータのメモリにそのままロード可能で
あり、コンピュータにおいて実行されるとき、請求項１から１３のいずれか１項
記載の方法のステップを実行するために用いられるソフトウェアセクションを有
していることを特徴とする、 コンピュータプログラム製品。 - 【請求項１５】 請求項１４記載のコンピュータプログラム製品を有するコ
ンピュータに適した記憶媒体。 - 【請求項１６】 請求項１５記載のコンピュータプログラム製品を有するデ
ータベースネットワークシステム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP99120009A EP1093061A1 (de) | 1999-10-14 | 1999-10-14 | Integriertes Datenbank-Verbundsystem |
| EP99120009.8 | 1999-10-14 | ||
| PCT/EP2000/009973 WO2001027806A1 (de) | 1999-10-14 | 2000-10-11 | Integriertes datenbank-verbundsystem |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006202842A Division JP4397385B2 (ja) | 1999-10-14 | 2006-07-26 | コンピュータに格納されたコンピュータプロセッサ命令として実装されている方法およびコンピュータにより読み取り可能な記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003511796A true JP2003511796A (ja) | 2003-03-25 |
| JP3887564B2 JP3887564B2 (ja) | 2007-02-28 |
Family
ID=8239147
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001530749A Expired - Lifetime JP3887564B2 (ja) | 1999-10-14 | 2000-10-11 | 統合型データベース結合システム |
| JP2006202842A Expired - Lifetime JP4397385B2 (ja) | 1999-10-14 | 2006-07-26 | コンピュータに格納されたコンピュータプロセッサ命令として実装されている方法およびコンピュータにより読み取り可能な記憶媒体 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006202842A Expired - Lifetime JP4397385B2 (ja) | 1999-10-14 | 2006-07-26 | コンピュータに格納されたコンピュータプロセッサ命令として実装されている方法およびコンピュータにより読み取り可能な記憶媒体 |
Country Status (10)
| Country | Link |
|---|---|
| US (2) | US6845378B1 (ja) |
| EP (3) | EP1093061A1 (ja) |
| JP (2) | JP3887564B2 (ja) |
| AT (2) | ATE231260T1 (ja) |
| AU (1) | AU765461B2 (ja) |
| CA (1) | CA2353845C (ja) |
| DE (2) | DE50004826D1 (ja) |
| DK (2) | DK1237098T3 (ja) |
| IL (2) | IL143509A0 (ja) |
| WO (1) | WO2001027806A1 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006099760A (ja) * | 2004-09-03 | 2006-04-13 | Microsoft Corp | スマートクライアントアドインアーキテクチャ |
| KR20210082921A (ko) * | 2019-12-26 | 2021-07-06 | 조상근 | 생산물류 erp 자동화 시스템의 협력사 및 고객사의 상호연결관계 파라미터의 설정방법 |
Families Citing this family (77)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030046017A1 (en) | 2001-06-06 | 2003-03-06 | Claudius Fischer | Deployment console for use with a computer system deploying software to remotely located devices |
| US7464097B2 (en) | 2002-08-16 | 2008-12-09 | Sap Ag | Managing data integrity using a filter condition |
| US7127475B2 (en) | 2002-08-15 | 2006-10-24 | Sap Aktiengesellschaft | Managing data integrity |
| US7257818B2 (en) | 2002-08-29 | 2007-08-14 | Sap Aktiengesellschaft | Rapid application integration using functional atoms |
| US7213227B2 (en) | 2002-08-29 | 2007-05-01 | Sap Aktiengesellschaft | Rapid application integration using an integrated development environment |
| US7225425B2 (en) | 2002-08-29 | 2007-05-29 | Sap Aktiengesellschaft | Rapid application integration |
| US7269665B2 (en) | 2002-08-29 | 2007-09-11 | Sap Ag | Isolated mapping point |
| US7171432B2 (en) | 2002-08-29 | 2007-01-30 | Sap Aktiengesellschaft | Phased upgrade of a computing environment |
| US7237225B2 (en) | 2002-08-29 | 2007-06-26 | Sap Aktiengesellschaft | Rapid application integration using reusable patterns |
| US7277940B2 (en) * | 2002-08-29 | 2007-10-02 | Sap Ag | Managing uneven authorizations in a computer data exchange |
| US7263698B2 (en) | 2002-08-29 | 2007-08-28 | Sap Aktiengesellschaft | Phased upgrade of a computing environment |
| US7206910B2 (en) * | 2002-12-17 | 2007-04-17 | Oracle International Corporation | Delta object replication system and method for clustered system |
| EP1611524A4 (en) * | 2003-03-19 | 2008-10-29 | Unisys Corp | SERVER CONSOLIDATION ANALYSIS |
| US8519158B2 (en) * | 2004-03-12 | 2013-08-27 | Ligand Pharmaceuticals Incorporated | Androgen receptor modulator compounds and methods |
| US7707432B2 (en) | 2004-08-13 | 2010-04-27 | Sap Ag | Enabling communication between an application program and services used by the application program |
| US7593916B2 (en) * | 2004-08-19 | 2009-09-22 | Sap Ag | Managing data administration |
| US7506006B2 (en) | 2004-09-03 | 2009-03-17 | Microsoft Corporation | Synchronization for smart clients |
| US7558783B2 (en) | 2004-09-03 | 2009-07-07 | Microsoft Corporation | Conversion between application objects and smart client objects |
| WO2006031921A2 (en) * | 2004-09-15 | 2006-03-23 | Adesso Systems, Inc. | System and method for managing data in a distributed computer system |
| US8140594B2 (en) * | 2004-09-17 | 2012-03-20 | Sap Ag | Advanced message mapping with sub-object key mapping |
| US7457794B2 (en) | 2004-10-14 | 2008-11-25 | Sap Ag | Searching for customized processing rules for a computer application |
| US7756809B2 (en) | 2004-10-14 | 2010-07-13 | Sap Ag | Apparatus and product of manufacture using execution points to select conditions and rules for business transaction processing |
| US7756808B2 (en) | 2004-10-14 | 2010-07-13 | Sap Ag | Apparatus and product of manufacture for using condition data structures separately from rule data structures in business transactions |
| US7761396B2 (en) | 2004-10-14 | 2010-07-20 | Sap Ag | Apparatus and product of manufacture for adaptive business transaction rule structures |
| US7457793B2 (en) | 2004-10-14 | 2008-11-25 | Sap Ag | Investigating execution of a customized transaction process in a computer application |
| US7457792B2 (en) | 2004-10-14 | 2008-11-25 | Sap Ag | Customizing transaction processing in a computer application by using pre-defined functions |
| US7386578B2 (en) | 2004-10-29 | 2008-06-10 | Sap Ag | Associations between duplicate master data objects |
| US7461091B2 (en) | 2005-06-09 | 2008-12-02 | Sap Aktiengesellschaft | Controlling data transition between business processes in a computer application |
| US20070143305A1 (en) * | 2005-11-02 | 2007-06-21 | Sourcecode Technology Holding, Inc. | Methods and apparatus for storing functions associated with an electronic form |
| US7996758B2 (en) * | 2005-11-02 | 2011-08-09 | Sourcecode Technologies Holding, Inc. | Methods and apparatus for storing data associated with an electronic form |
| US20070130138A1 (en) * | 2005-11-02 | 2007-06-07 | Sourcecode Technology Holding, Inc. | Methods and apparatus for storing a collaboratively designed workflow process |
| US20070208777A1 (en) * | 2005-11-02 | 2007-09-06 | Sourcecode Technology Holding, Inc. | Methods and apparatus for designing a workflow process using resource maps and process maps |
| US20070136367A1 (en) * | 2005-11-02 | 2007-06-14 | Sourcecode Technology Holding, Inc. | Methods and apparatus for dynamically modifying a business object definition |
| US8010940B2 (en) | 2005-11-02 | 2011-08-30 | Sourcecode Technologies Holdings, Inc. | Methods and apparatus for designing a workflow process using inheritance |
| US20070143711A1 (en) * | 2005-11-02 | 2007-06-21 | Sourcecode Technology Holding, Inc. | Methods and apparatus for displaying a setup sequence |
| US8224853B2 (en) * | 2005-11-02 | 2012-07-17 | Sourcecode Technologies Holdings, Inc. | Methods and apparatus for updating a plurality of data fields in an electronic form |
| US8239226B2 (en) * | 2005-11-02 | 2012-08-07 | Sourcecode Technologies Holdings, Inc. | Methods and apparatus for combining properties and methods from a plurality of different data sources |
| US9514163B2 (en) | 2005-11-17 | 2016-12-06 | International Business Machines Corporation | Database consolidation tool |
| US7778965B2 (en) * | 2006-05-23 | 2010-08-17 | Sap Ag | Systems and methods for common instance handling of providers in a plurality of frameworks |
| US7797322B2 (en) * | 2006-07-13 | 2010-09-14 | Sap Ag | Negative key mapping |
| US8495519B2 (en) * | 2006-11-27 | 2013-07-23 | Sourcecode Technologies Holdings, Inc. | Methods and apparatus for displaying interprocess communication thumbnails |
| US20080155518A1 (en) * | 2006-11-27 | 2008-06-26 | Sourcecode Technology Holding, Inc. | Methods and apparatus for tokenizing workflow process objects |
| US20080155330A1 (en) * | 2006-11-27 | 2008-06-26 | Sourcecode Technology Holding, Inc. | Methods and apparatus for debugging a workflow process |
| WO2008067312A2 (en) * | 2006-11-27 | 2008-06-05 | Sourcecode Technology Holding, Inc. | Methods and apparatus for modeling a workflow process in an offline environment |
| US8141128B2 (en) * | 2007-02-20 | 2012-03-20 | Source Code Technologies Holdings, Inc. | Methods and apparatus for building and executing natural language workflow functions |
| WO2008116218A1 (en) * | 2007-03-22 | 2008-09-25 | Sourcecode Technology Holding, Inc. | Providing context sensitive templates for a web based workflow design |
| US20080306806A1 (en) * | 2007-03-23 | 2008-12-11 | Sourcecode Technology Holding, Inc. | Methods and apparatus for dynamically allocating tasks |
| US20080270475A1 (en) * | 2007-04-27 | 2008-10-30 | Sap Ag | Data processing systems and methods for connecting business objects to data sources |
| US20090037397A1 (en) * | 2007-05-03 | 2009-02-05 | Sourcecode Technology Holding, Inc. | Methods and apparatus for providing context search results in process design |
| EP2145297A4 (en) * | 2007-05-08 | 2012-05-30 | Sourcecode Technology Holding Inc | METHODS AND APPARATUSES FOR EXPOSING DEFINITIONS OF WORKFLOW PROCESSES AS COMMERCIAL OBJECTS |
| EP2171581A4 (en) * | 2007-05-24 | 2012-05-02 | Sourcecode Technology Holding Inc | METHODS AND APPARATUSES FOR MODELING COLLABORATIVE PROCESSES |
| US20090024558A1 (en) * | 2007-07-16 | 2009-01-22 | Sap Ag | Methods and systems for storing and retrieving rejected data |
| US7899835B2 (en) * | 2008-02-28 | 2011-03-01 | Caterpillar, Inc. | Method and system for reviewing business activity of a business entity |
| US7996357B2 (en) | 2008-02-29 | 2011-08-09 | Plaxo, Inc. | Enabling synchronization with a difference unaware data source |
| US7991740B2 (en) * | 2008-03-04 | 2011-08-02 | Apple Inc. | Synchronization server process |
| US8655858B1 (en) * | 2008-11-13 | 2014-02-18 | Amazon Technologies, Inc. | Digital content reconstruction and distribution |
| US8738584B2 (en) * | 2009-02-17 | 2014-05-27 | Microsoft Corporation | Context-aware management of shared composite data |
| US8463743B2 (en) * | 2009-02-17 | 2013-06-11 | Microsoft Corporation | Shared composite data representations and interfaces |
| US8739124B2 (en) | 2012-06-27 | 2014-05-27 | Sap Ag | Configuring integration capabilities for system integration |
| US9015608B2 (en) * | 2012-07-16 | 2015-04-21 | Sap Se | Regenerating a user interface area |
| US8924848B2 (en) * | 2012-07-16 | 2014-12-30 | Sap Se | Synchronizing a user interface area |
| US8996565B2 (en) * | 2012-12-18 | 2015-03-31 | Sap Se | Systems and methods for in-memory database processing |
| US9811687B2 (en) | 2013-03-15 | 2017-11-07 | International Business Machines Corporation | Common location of user managed authorization |
| US10331765B2 (en) | 2013-05-24 | 2019-06-25 | Sourcecode Technology Holdings, Inc. | Methods and apparatus for translating forms to native mobile applications |
| CN104216914B (zh) | 2013-06-04 | 2017-09-15 | Sap欧洲公司 | 大容量数据传输 |
| US9231959B2 (en) | 2013-07-12 | 2016-01-05 | Sap Se | Multiple transaction interface framework |
| US20150039656A1 (en) * | 2013-08-01 | 2015-02-05 | Synchronoss Technologies, Inc. | Enterprise address management system and a method thereof |
| US9535933B2 (en) * | 2013-09-03 | 2017-01-03 | Acxiom Corporation | System and method for representing change values |
| CN104268234B (zh) * | 2014-09-26 | 2018-05-29 | 东软集团股份有限公司 | 一种基于sql语句的数据同步方法和装置 |
| JP6842071B2 (ja) * | 2016-05-31 | 2021-03-17 | 株式会社東新システム | データ交換システム、データ交換方法、及びデータ交換プログラム |
| CN108319451B (zh) * | 2017-01-16 | 2021-09-07 | 医渡云（北京）技术有限公司 | 医疗数据补充方法和装置 |
| US11120025B2 (en) * | 2018-06-16 | 2021-09-14 | Hexagon Technology Center Gmbh | System and method for comparing and selectively merging database records |
| US11562033B2 (en) * | 2018-08-30 | 2023-01-24 | Open Text Sa Ulc | Systems and methods for enhanced content management interoperability services interfaces and repository integration |
| CN110928867B (zh) * | 2018-08-31 | 2022-09-20 | 杭州海康威视数字技术股份有限公司 | 一种数据融合的方法及装置 |
| US11696528B2 (en) * | 2019-10-11 | 2023-07-11 | Deere & Company | Settings propagation and synchronization across mobile work machines |
| JP6886055B1 (ja) * | 2020-02-28 | 2021-06-16 | 株式会社ビズリーチ | 制御装置及び制御方法 |
| US20240281427A1 (en) * | 2023-02-22 | 2024-08-22 | Jpmorgan Chase Bank, N.A. | Method and system for utilizing a de-normalized master table structure for the processing of subscriptions |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4714995A (en) * | 1985-09-13 | 1987-12-22 | Trw Inc. | Computer integration system |
| US5333316A (en) * | 1991-08-16 | 1994-07-26 | International Business Machines Corporation | Locking and row by row modification of a database stored in a single master table and multiple virtual tables of a plurality of concurrent users |
| US5459860A (en) * | 1992-10-05 | 1995-10-17 | International Business Machines Corporation | Computerized system and process for managing a distributed database system |
| US5873096A (en) | 1997-10-08 | 1999-02-16 | Siebel Systems, Inc. | Method of maintaining a network of partially replicated database system |
| US5778373A (en) | 1996-07-15 | 1998-07-07 | At&T Corp | Integration of an information server database schema by generating a translation map from exemplary files |
| US5870765A (en) * | 1996-10-09 | 1999-02-09 | Oracle Corporation | Database synchronizer |
| US5937402A (en) * | 1997-06-19 | 1999-08-10 | Ontos, Inc. | System for enabling access to a relational database from an object oriented program |
| US6385618B1 (en) * | 1997-12-22 | 2002-05-07 | Sun Microsystems, Inc. | Integrating both modifications to an object model and modifications to a database into source code by an object-relational mapping tool |
| US6233585B1 (en) * | 1998-03-12 | 2001-05-15 | Crossworlds Software, Inc. | Isolation levels and compensating transactions in an information system |
| US6625621B2 (en) * | 2000-01-04 | 2003-09-23 | Starfish Software, Inc. | System and methods for a fast and scalable synchronization server |
-
1999
- 1999-10-14 EP EP99120009A patent/EP1093061A1/de not_active Withdrawn
-
2000
- 2000-10-11 CA CA002353845A patent/CA2353845C/en not_active Expired - Lifetime
- 2000-10-11 AT AT00974383T patent/ATE231260T1/de active
- 2000-10-11 EP EP02010023A patent/EP1237098B1/de not_active Expired - Lifetime
- 2000-10-11 DK DK02010023T patent/DK1237098T3/da active
- 2000-10-11 EP EP00974383A patent/EP1151399B1/de not_active Expired - Lifetime
- 2000-10-11 AT AT02010023T patent/ATE256889T1/de active
- 2000-10-11 AU AU12716/01A patent/AU765461B2/en not_active Expired
- 2000-10-11 DE DE50004826T patent/DE50004826D1/de not_active Expired - Lifetime
- 2000-10-11 DE DE50001091T patent/DE50001091D1/de not_active Expired - Lifetime
- 2000-10-11 JP JP2001530749A patent/JP3887564B2/ja not_active Expired - Lifetime
- 2000-10-11 IL IL14350900A patent/IL143509A0/xx active IP Right Grant
- 2000-10-11 US US09/857,864 patent/US6845378B1/en not_active Expired - Lifetime
- 2000-10-11 DK DK00974383T patent/DK1151399T3/da active
- 2000-10-11 WO PCT/EP2000/009973 patent/WO2001027806A1/de active IP Right Grant
-
2001
- 2001-05-31 IL IL143509A patent/IL143509A/en unknown
-
2004
- 2004-01-02 US US10/749,557 patent/US7143079B2/en not_active Expired - Lifetime
-
2006
- 2006-07-26 JP JP2006202842A patent/JP4397385B2/ja not_active Expired - Lifetime
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006099760A (ja) * | 2004-09-03 | 2006-04-13 | Microsoft Corp | スマートクライアントアドインアーキテクチャ |
| KR20210082921A (ko) * | 2019-12-26 | 2021-07-06 | 조상근 | 생산물류 erp 자동화 시스템의 협력사 및 고객사의 상호연결관계 파라미터의 설정방법 |
| KR102345148B1 (ko) | 2019-12-26 | 2021-12-29 | 조상근 | 생산물류 erp 자동화 시스템의 협력사 및 고객사의 상호연결관계 파라미터의 설정방법 |
Also Published As
| Publication number | Publication date |
|---|---|
| DE50001091D1 (de) | 2003-02-20 |
| EP1151399A1 (de) | 2001-11-07 |
| CA2353845C (en) | 2006-03-14 |
| DE50004826D1 (de) | 2004-01-29 |
| ATE256889T1 (de) | 2004-01-15 |
| EP1093061A1 (de) | 2001-04-18 |
| EP1237098B1 (de) | 2003-12-17 |
| IL143509A (en) | 2007-08-19 |
| US6845378B1 (en) | 2005-01-18 |
| AU765461B2 (en) | 2003-09-18 |
| ATE231260T1 (de) | 2003-02-15 |
| DK1151399T3 (da) | 2003-04-07 |
| JP4397385B2 (ja) | 2010-01-13 |
| IL143509A0 (en) | 2002-04-21 |
| US20040143606A1 (en) | 2004-07-22 |
| WO2001027806A1 (de) | 2001-04-19 |
| EP1151399B1 (de) | 2003-01-15 |
| CA2353845A1 (en) | 2001-04-19 |
| EP1237098A1 (de) | 2002-09-04 |
| AU1271601A (en) | 2001-04-23 |
| US7143079B2 (en) | 2006-11-28 |
| JP3887564B2 (ja) | 2007-02-28 |
| DK1237098T3 (da) | 2004-03-15 |
| JP2007012079A (ja) | 2007-01-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3887564B2 (ja) | 統合型データベース結合システム | |
| US7366460B2 (en) | System and method for mobile data update | |
| US6539381B1 (en) | System and method for synchronizing database information | |
| US6910053B1 (en) | Method for data maintenance in a network of partially replicated database systems | |
| CN100449548C (zh) | 数据库同步方法及系统 | |
| US9256655B2 (en) | Dynamic access of data | |
| US7269604B2 (en) | System of and method for transparent management of data objects in containers across distributed heterogenous resources | |
| US6256667B1 (en) | Intelligent messaging | |
| US20150046524A1 (en) | Data Management for Mobile Data System | |
| CN101185077A (zh) | 根据/利用第一数据库构建、同步和/或操作第二数据库的计算机网络及相应过程 | |
| US8805785B2 (en) | Shared storage of categorization, labeling or tagging of objects in a collaboration system | |
| US8626716B1 (en) | Service broker enhancements | |
| US7506000B2 (en) | Method and system for programming disconnected data | |
| US5615372A (en) | Network definition modifying system | |
| JPH06290098A (ja) | 分散データベース処理方法 | |
| US20070162492A1 (en) | Reconstruction of historic business object state | |
| WO2004025456A2 (en) | Interaction between a client process and software applications |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060127 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060424 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060501 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060726 |
|
| 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: 20061027 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061127 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3887564 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091201 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101201 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101201 Year of fee payment: 4 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D02 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111201 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121201 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131201 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |