JP3848085B2 - トランザクションデータの高速記憶常駐処理方法および処理システム - Google Patents

Description

【０００１】
技術分野
本発明は一般的に、トランザクションシステムにおけるデータの記憶、呼び出し、および処理方法に関する。とりわけ本発明は、記憶されたデータでの機能をリアルタイムベースで実行するためのリレーショナルかつオブジェクト指向の機能性を統合する方法に関する。
【０００２】
従来の技術
コンピュータ技術分野では、データを商用データベースシステムに記憶し、このデータをデータベースマネージャシステムにより呼び出すことが普通である。２つの一般的形式のデータベースマネージャシステムがある。すなわちリレーショナルとオブジェクト指向である。リレーショナルなデータベースシステムは、大容量のデータを管理するのに適し、一方オブジェクト指向のデータベースはオブジェクト間の複雑な関係を表現するのに適する。リレーショナルなデータベースシステムは、データを呼び出すのには適するが、データ操作はわずかしか和ポートしないか、まったくサポートしない。一方、オブジェクト指向のシステムはデータ操作に非常に適するが、データの問い合わせおよび呼び出しをわずかしかサポートしないか、またはまったくサポートしない。所与のタスクに応じて、所定のタスクに適する種々のシステムを使用することができる。単純なデータを問い合わせなしで管理するためには、伝統的なデータベースシステムさえも必要ない。単純なファイルシステムで十分である。単純なデータを問い合わせにより管理するためには、リレーショナルなデータベースシステムが理想的であろう。該当するデータが複雑であり、しかも問い合わせが必要でなければ、オブジェクト指向のデータベースシステムが使用されるであろう。さらに該当するデータが複雑で、かつ問い合わせ能力が要求される場合には、オブジェクト・リレーショナルなデータベースマネージメントシステムの使用が所望されるであろう。
【０００３】
内部の機能性を結合することが試みられた。しかし２つのモデルは基本的に異なっているので、両者の統合は非常に困難である。リレーショナルなデータベースシステムは２次元テーブルに基づくものであり、このテーブルでは各アイテムが各行に現れる。データ間の関係は、このテーブルに記憶された値の比較により表現される。オブジェクトモデルは、コードおよびデータの密な統合、フレキシブルなデータ形式、および引用に基づく。オブジェクト指向のデータベースはその起源をオブジェクト指向プログラミングパラダイムに有する。このパラダイムでは、ユーザはオブジェクトと、このオブジェクトでの演算に関心を持つ。「ＤＥＰＴ組」＋相応の「ＥＭＰ組」の集合（これは「ＤＥＰＴ組」で「一次キー値」を参照する「外部キー値」を含む）を考えなければならない代わりに、ユーザはエンプロイーオブジェクトの相応の集合に相当するデパートメントオブジェクトを直接考えなければならない。
【０００４】
００アプローチの基本原理は、全てが１つのオブジェクトであることである。いくつかのオブジェクトはプリミティブであり、不変である（整数、ストリングス等）。他のオブジェクトは−典型的にはユーザが形成したオブジェクト−はより複雑であり、可変である。これらより複雑なオブジェクトは任意の内部複雑性の変数に相応する。各オブジェクトはタイプを有する（００表現はクラスである）。個々のオブジェクトはしばしばオブジェクトインスタンスと称される。各所与のタイプの内部アスペクトは、オペレータまたは機能の集合からなり（００表現は「方法」である）、この集合はこのタイプのオブジェクトに適用することができる。さらに全てのオブジェクトがカプセル化される。これは、所定のオブジェクトの表現または内部構造が、このオブジェクトのユーザには見えないことを意味する。その代わりにユーザは、オブジェクトが所定の機能を実行可能であることを知るだけである。カプセル化の利点は、オブジェクトの内部表現を変更できることであり、その際にこれらオブジェクトを書き換えて使用しなければならないアプリケーションが必要ないことである。言い替えればこのカプセル化によりデータ独立性が得られる。各オブジェクトは、ＯＩＤ（オブジェクトＩＤ）と称される一義的な識別子を有し、この識別子はデータベースの他の部分からのポインタに対するアドレスとして使用することができる。
【０００５】
リレーショナルなデータベースシステムは小さく、固定されたデータタイプ（例えば整数、データ、およびストリングス）の集合をサポートする。これらは伝統的な適用領域、例えば管理データ処理に適することが証明されている。しかし多くの適用領域でより複雑な形式のデータを取り扱わなければならない。通常のこの複雑なデータはＤＢＭＳではなく、オペレーティングシステムのファイルシステムまたは専用のデータ構造に記憶される。複雑なデータを有する領域は例えばコンピュータ支援開発およびモデリング（ＣＡＤ／ＣＡＭ）、マルチメディアソース、および文書管理である。データ量が増大すると共に、データ管理のためにＤＢＭＳにより提供される多数のフューチャ、例えばアプリケーション開発時間の短縮、同時制御およびリカバリー、インデクスサポートおよび問い合わせ能力がますます所望されるようになり、必要になる。このようなアプリケーションを支援するために、ＤＢＭＳは複雑なデータタイプをサポートしなければならない。オブジェクト指向の概念は、複雑なデータに対するデータベース支援を改善する努力に大きな影響を与えた。すでに述べたように、従来技術に属するリレーショナルなデータベースマネージメントシステムは、この機能を単純なデータに基づいてサポートする。リレーショナルなＤＢＭＳが複雑なデータ形式を記憶できるとも考えられよう。例えば画像、ビデオ等はｂｌｏｂｓ（basic large objects、単純で大きなオブジェクト）として現在のリレーショナルなシステムに記憶することができるであろう。ｂｌｏｂは単に長いバイト流であり、ＤＢＭＳのサポートは、ｂｌｏｂを記憶し、呼び出すことである。この記憶および呼び出しは、ユーザがｂｌｏの大きさを意識する必要なしに、１つのｂｌｏｂが複数のページに伸張できるよう行われる。以降のｂｌｏｂの全ての処理は、ユーザのアプリケーションプログラムによりホスト言語で行わなければならない。このホスト言語にはＳＱＬ言語が埋め込まれている。この解決手段は効率的でない。なぜなら、全てのｂｌｏｂを集合から呼び出さなければならず、これらの多くをＤＢＭＳ内でユーザ定義された機能を適用することにより応答からふるい落とすことができるにしても、全てを呼び出さなければならない。従来技術におけるオブジェクト指向のデータベースも複雑なデータの記憶をサポートするが、これらはこのような複雑なデータを管理するための問い合わせ機能およびインデクシング機能を提供しない。
【０００６】
伝統的なリレーショナルなデータベースマネージメントシステムのフューチャおよび機能性を提供することのでき、しかも複雑なデータ形式により使用できるデータベースマネージメントシステムが必要である。この必要性の結果、オブジェクト−リレーショナルなデータベースマネージメントシステムを開発する機運が高まった。
【０００７】
オブジェクト−リレーショナルなデータベースは、リレーショナルなデータベースシステムを、アプリケーションの広範囲なクラスをサポートするために必要な機能性により拡張する試みと見なすことができ、多くの点でリレーショナルな領域とオブジェクト指向の領域との橋渡しをする。現在市場には複数のオブジェクト−リレーショナルなデータベースマネージメントシステム（ＯＲＤＢＭＳ）が存在する。これには、Informix Universal Server, UniSQLおよびＯ２が属する。現在の開発で行われた、オブジェクト−リレーショナル技術でのアプローチは、既存のＤＢＭＳの機能性を新たなデータ形式を追加することにより拡張することである。伝統的システムは使用可能なデータタイプにおいて制限されたフレキシビリティしか提供しない。データはテーブルに記憶され、各フィールド値のタイプは単純なアトミックタイプに制限される。この制限されたタイプシステムは３つの３つのタイプに拡張された：ユーザ定義されたアブストラクトタイプ、構造化タイプ、および参照タイプである。これらはまとめてコンプレクスタイプと称される。例としてＪＰＥＧ画像を挙げておく。このタイプは、典型的なＤＢＭＳのビルトインタイプの１つではないが、ユーザによりＯＲＤＢＭＳに定義することができ、ＪＰＥＧ規格により圧縮された画像データを記憶することができる。ＯＲＤＢＭＳのキーフューチャは、ユーザが任意に新たなデータタイプを定義できることである。ＯＲＤＢＭＳによりユーザは、タイプjpeg＿imageのオブジェクト、並びに整数のような任意の別のタイプを記憶し、呼び出すことができる。新しいデータタイプでは通常、タイプ固有の演算を、これを形成したユーザにより定義しなければならない。例えば画像データタイプでの演算を、圧縮、回転、収縮、およびクロップと定義できるであろう。データタイプとそれに配属された方法の組合せはアブストラクトデータタイプ（ＡＤＴ）と称される。ラベル「アブストラクト」はこのデータタイプに適用される。なぜなら、データベースシステムは、ＡＤＴのデータがどのように記憶されるか、またはＡＤＴの方法がどのように動作するかを知る必要がないからである。使用可能な方法、およびこの方法に対する入力および出力タイプを知ればよいだけである。内部ＡＤＴ構成部分の秘匿はカプセル化と称される。オブジェクトがとりわけ大きい場合、オブジェクト識別子が有利である。大きな値のコピーを構造化タイプの多重オブジェクトに記憶することは、この値を一度記憶し、基準タイプのオブジェクトによりこれを他の個所で参照する場合よりも格段に多くの空間を必要とする。この付加的なメモリ要求は、ディスク使用およびバッファ管理に大きな影響を与える。
【０００８】
大きなＡＤＴオブジェクトはディスク状でのデータのレイアウトを複雑化する。この問題は良く理解され、実質的に全てのＯＲＤＢＭＳおよびＯＯＤＢＭＳで解決されている。ユーザ定義されたＡＤＴは非常に大きくても良い。とりわけこのＡＤＴは個々のディスクページよりも大きくて良い。大きなＡＤＴはｂｌｏｂのように特別の記憶を必要とし、通常はこのＡＤＴを含む組とは別のディスク個所に記憶される。ディスクベースのポインタは組から、これを含むオブジェクトに維持される。
【０００９】
従来技術のＯＲＤＢＭでの別の問題は効率である。複雑なオブジェクトが純粋にリレーショナルなデータベースマネージメントシステムにｂｌｏｂとして記憶される場合、オブジェクト全体をメモリから呼び出し、クライアントに伝送しなければならない。オブジェクトの各処理および全ての処理はクライアント自身により実行しなければならない。しかしＯＲＤＢＭではこの能力が改善されている。なぜなら方法がクライアントによってではなく、サーバによって実行されるからである。ありきたりな例として、問い合わせ「２０章以上ある全ての本を検索せよ」を考えてみる。伝統的なリレーショナルＤＢＭＳでは本をｂｌｏｂとして表すことができ、クライアントは各本を呼び出し、走査し、それが基準を満たしているか否かを決定しなければならない。これに対してサーバは、適切な００サポートにより方法「章の数」を呼び出し、それらの本だけがクライアントに伝送される。
【００１０】
これが、必要なデータだけが呼び出され、クライアントに伝送されるという意味で能力の一側面である。効率の別の側面はアドレス空間に係るものである。記憶システムがユーザプログラムとは別のアドレス空間で実行されるなら、この命令を処理するためにアドレス空間を切り替えなければならない。このアドレス空間切り替えのために、命令は２から３のオーダーで非持続的な場合よりも緩慢になる。このような性能の低下はユーザには受け入れられないものである。この理由から持続的メモリシステムは、これがユーザプログラムと同じアドレス空間で実行されるように構成された。アドレス空間切り替えを回避することにより、格段に高い性能が提供される。持続的言語を使用することの利点は、持続的言語の世界ではアップデートが非常に「軽い」ことである。すなわち、アップデートはわずかな時間しか必要としない。結果として、例えばＣ＋＋のようなローレベル言語でのアップデート作成は例えばＳＱＬのような高級プログラミング言語でのアップデート作成とは基本的に異なる。Ｃ＋＋または第３世代属する他の任意のプログラミング言語では、アップデートが格段に軽い。すなわちこれらの言語はただ１つの記憶個所を変形するだけである。
【００１１】
性能の最後の側面は、ＤＢＭＳと、機能が実行されるアドレス空間との間のデータ伝送である。従来技術では、ハードディスクまたは所定の類似の装置に記憶されたＤＢＭＳからデータがアプリケーションに伝送される。この形式ので０多伝送はネットワークリソースを極端に負荷し、許容できない遅延の原因となる。ディスクの入出力は従来技術では、処理スピードにおける遅延の主要な原因である。大容量のトランザクションデータが伝統的リレーショナルＤＢＭＳに存在するような状況では、複雑な計算をこのデータにおいて実行することが所望される。このようなデータ操作の制限要因は速度と性能である。従来技術では、大容量のデータがＤＢＭＳにより呼び出され、入力として機能に供給され、この機能がデータにより実行され、出力値がフィードバックされる。しかし、データをディスクからメモリに伝送しなければならないときに、Ｉ／Ｏボトルネックが発生する。例えば大容量のトランザクションデータを、リアルタイムのデータ分析またはほぼリアルタイムのデータ分析のために処理しなければならない場合、実際のトランザクションデータをＤＢＭＳから伝送し、計算処理の実行されるクライアントに送出しなければならない。このことは伝統的に重大な遅延の原因となる。
【００１２】
本発明はこの欠陥を修正し、データベースからリアルタイムベースで呼び出されるデータの効率的で高速の処理を可能としようとするものである。
【００１３】
上記の議論は有利に、企業リソースプランニングシステム（ＥＲＰシステム）の関連で適用することができる。このトランザクションシステムは企業により使用され、企業の商業的プロセスを日ごとに自動的に管理する。このオンライントランザクション処理システムは、全ての商業的ルーチンとトランザクションを統合的に処理するよう構成されている。これには、企業ワイド、統合的ソリューション、並びに個別の部門機能に対する専用アプリケーションが含まれる。これらは企業の商業的に重要な全ての処理、すなわち金融、製造、販売および人事を反映する。
【００１４】
このようなシステムにより形成されたトランザクションを分析できると有利である。従来技術では、企業がコンピュータを使用して、商業プロセスデータを分析し、判断データを得ている。伝統的にはトランザクションシステムからのデータはデータ倉庫にバッチ処理でアップロードされた。分析は、データ倉庫からのデータで実行された。この分析はリアルタイムベースでは実行されない。本発明は、この欠陥を修正しようとするものである。
【００１５】
本発明の課題は、大容量のトランザクションデータでの複雑な操作をリアルタイムで実行できるシステムおよび方法を提供することである。
【００１６】
本発明の別の課題は、Ｉ／Ｏボトルネックを除去することである。このボトルネックは伝統的には、大容量のトランザクションデータを処理のためにクライアントに伝送するときに発生する。
【００１７】
本発明の別の課題は、トランザクションデータの記憶が最適化されたデータ構造で可能であるようなシステムおよび方法を提供することである。ここでは複雑なデータ構造、例えばネットワーク構造またはツリー構造をオブジェクト参照に基づいて適切に表現できるようにする。
【００１８】
本発明の別の課題は、トランザクションシステムで更新されるトランザクションデータと関連して、最適のデータ構造に記憶されたトランザクションデータを維持することである。
【００１９】
本発明の別の課題は、複雑なオブジェクトをオブジェクト指向環境で記憶することのできるシステムおよび方法を提供することである。
【００２０】
本発明の別の課題は、前記の複雑なオブジェクトを、伝統的なリレーショナルデータベース技術およびＳＱＬ言語を使用して問い合わせることのできるシステムを提供することである。
【００２１】
本発明の別の課題は、複雑なオブジェクトが、リレーショナルな環境と同じように高度に複雑化されたトランザクションマネージメントシステムに支配されるシステムを提供することである。
【００２２】
本発明の要約
本発明は、複雑なデータ処理をリアルタイムベースで実行するためのシステムおよび方法を提供する。有利な実施形態でこのシステムは、１つまたは複数のクライアント（例えば端末機またはＰＣ）を有し、クライアントはネットワークを介してアプリケーションサーバと接続されている。アプリケーションサーバは非常に大きなメインメモリを含み、このメモリでハイブリッド・オブジェクト−リレーショナル・データベースシステムが実行される。データベースシステムは伝統的なリレーショナル・データベースマネージメントシステムを含み、その機能性は複雑なデータタイプ、すなわち持続的Ｃ＋＋クラスおよび記憶された手続きの導入を可能にすることによって拡張されている。この複雑なデータタイプへは、ＳＱＬを用い、ユーザ定義されたタイプおよびユーザ定義された機能によってアクセスすることができる。トランザクションデータは最適化されたデータ構造に、複雑なオブジェクトとして同じ大きさのメインメモリに記憶される。この複雑なオブジェクトを記憶するために、別個のメモリコンテナが設けられる。各複雑なオブジェクト自体は、持続的Ｃ＋＋クラスの例である。オブジェクトが形成されるときに、このオブジェクトに対して一義的なオブジェクト識別子（ＯＩＤ）が形成される。このＯＩＤは、別個のメモリコンテナに記憶された複雑なオブジェクトへのポインタとして用いられる。本発明はさらに、持続的Ｃ＋＋オブジェクトを、オブジェクトマネージメントのＣ＋＋方法と伝統的リレーショナル・データベーストランザクションマネージメントを使用して、定義、操作、および呼び出すためのオブジェクトマネージメントシステム（ＯＭＳ）を含む。
【００２３】
各持続的Ｃ＋＋クラス毎に、記憶された関連の手続きが存在する。記憶された手続きは、Ｃ＋＋に実現されたＣＯＭオブジェクトの方法として実行される。この方法はライブラリーに登録され、データベース処理が実行されるアドレス空間にダイナミックにリンクされる。この方法はＣ＋＋で記述されており、持続的Ｃ＋＋クラスの例である複雑なオブジェクトとして記憶されたデータで動作するよう構成されている。
【００２４】
一般的動作では、１つまたは複数のクライアントが、データ処理演算を複雑なオブジェクトとして記憶されたデータセットで実行するよう要求する。ＯＲＤＢＭＳとデータ自体は、全て大きなメインメモリに記憶されている。このようにしてＩ／Ｏボトルネックが除去される。なぜなら重たいデータ伝送が必要ないからであり、性能のアドバンテージが達成される。記憶された手続きはさらに同じメインメモリアドレスで使用可能とされる。記憶された手続きはこの複雑なオブジェクトへオブジェクト識別子によって、介在するＧＥＴ方法を介してアクセスすることができる。オブジェクト識別子は、前記のオブジェクトが記憶されているメインメモリアドレスに変換される。こうして持続的オブジェクト、例えばＣ＋＋オブジェクトのコピーが、記憶された手続きと同じメインメモリアドレス空間で使用可能とされる。その結果、記憶させた手続きは、ＤＢＭＳが実行されるのと同じアドレス空間で実行される。このことにより、大容量のデータメモリの複雑な分析が行われる演算に対して付加的な性能アドバンテージが得られる。本発明以前では、複雑な問い合わせは多量のリソースを消費し、そのためトランザクションマネージメントシステムからの実際の演算データを格段の遅延なしに使用するのは非効率的であった。本発明によれば、トランザクションデータが提案されたＯＲＤＢＭＳに収集され、登録された機能がＯＲＤＢＭＳプロセスが実行されるのと同じアドレス空間で実行され、複雑な分析が実行される。これにより従来技術に対して改善された性能が得られる。
【００２５】
図面の簡単な説明
図１は、本発明を提供するのに適した環境の概略図である。
【００２６】
図２は、従来技術の概略図である。
【００２７】
図３は、本発明を実現することのできるコンピュータシステムの概略図である。
【００２８】
図４は、図３のコンピュータシステムの動作を制御するためのソフトウエアサブシステムを示すブロック回路図である。
【００２９】
図５は、本発明が有利に実現されるクライアント／サーバシステムのブロック回路図である。
【００３０】
図６は、本発明の有利な実現例を概略図である。
【００３１】
図７は、本発明の有利な実施例で開始される例としてのトランザクションの概略図である。
【００３２】
図８は、本発明の有利な実施例の構造概略図である。
【００３３】
図９は、本発明でＵＤＴと定義することのできる例として最適データ構造の構造概略図である。
【００３４】
図１０は、オブジェクト指向モデルへの関係からデータをマッピングする概略図である。
【００３５】
図１１は、図９の再提起データ構造により構成されたプラニングモデルの例を示す概略図である。
【００３６】
図１２は、オブジェクト指向のデータモデル化に適する分散ネットワークの概略図である。
【００３７】
図１３は、オブジェクトマネージメントシステムの構造の概略図である。
【００３８】
図１４は、ＯＭＳバンクでのオブジェクトデータ記憶の構造の概略図である。
【００３９】
図１５は、データオブジェクトが記憶されたページメモリレイアウトの概略図である。
【００４０】
図１６は、有利な実施例でのオブジェクト識別子の構造の概略図である。
【００４１】
図１７は、本発明によるメインメモリのページメモリレイアウトのオブジェクト記憶を示す概略図である。
【００４２】
図１８は、本発明によるページメモリレイアウトでのページシーケンスを示す概略図である。
【００４３】
図１９は、本発明で使用するのに適する最適データモデルのＯＩＤを示す概略図である。
【００４４】
図２０は、アプリケーションオブジェクトとライブキャッシュサーバとの間のインターフェースを示す概略図である。
【００４５】
図２１は、機能およびオブジェクトデータを呼び出すためのライブキャッシュサーバでのＳＱＬ問い合わせの発行方法を示す。
【００４６】
図２２は、本発明のトランザクションマネージメントシステムの概略図である。
【００４７】
図２３は、本発明のトランザクションマネージメントシステムに対するログを示す。
【００４８】
図２４は、本発明のデータ同期手段のステップ１を示す。
【００４９】
図２５は、本発明のデータ同期手段のステップ２を示す。
【００５０】
図２６は、本発明のデータ同期手段のステップ３を示す。
【００５１】
有利な実施例の詳細な説明
以下の説明は、本発明の現在の有利な実施例を中心にするものであり、この実施例はクライアント／サーバアプリケーションを実行するネットワーク環境で動作する。しかし本発明は、所定のアプリケーションまたは環境に制限されるものではない。本発明は有利には、大容量のトランザクションデータをリアルタイムで処理することが所望されるいずれのアプリケーションまたは環境でも使用することができる。有利な実施例の以下の説明は説明のためのものであり、限定ではない。
【００５２】
図１は、本発明の提供に適する供給チェーン環境を示す。供給者１００から消費者１０８への商品の流れは、製造者１０２，ディストリビュータ１０４および販売操作１０６の中間ノードを有し、この流れを最適の販売コストソリューションを達成するため最大にすべきである。本発明はこの最適計算をリアルタイムで達成する。図２は従来技術の処理方法を示す。伝統的にトランザクションデータは、ハードディスク２００またはデータベース・サーババッファからアプリケーションサーバ２０４に伝送される。図からわかるように、このような伝送２０６に対する時間が非常に重要である。本発明は、この伝送時間を格段に低減する。
【００５３】
本発明は、例えば図３のシステムのようなコンピュータシステムで実現することができる。このシステムは、中央プロセッサ、メインメモリ３０４，入／出力制御ユニット３０６，キーボード３０８，ポインティングデバイス３１０，スクリーンディスプレイ３１２および大容量メモリ（例えばハードディスク、リムーバルディスク、光学的ディスク、磁気光学的ディスク、またはフラッシュメモリ）を有する。
【００５４】
図４に示すように、コンピュータソフトウエアシステムがコンピュータシステムの演算を制御するために設けられている。システムメモリ４００と、大容量メモリ、例えばハードディスクに記憶されたソフトウエアシステムはカーネル、ないしオペレーティングシステム４０２を有し、これらは特別な実施例ではWindows NTおよびシェル４０４である。１つまたは複数のアプリケーションプログラム、例えばアプリケーションソフトウエアが（ディスクからメインメモリに）ロードされ、システムによって実行される。システムはまたユーザインタフェース４０６を、ユーザ命令およびデータを入力として受信するために有し、結果データを出力として表示する。本実施例では、下に説明するように、本発明によるライブキャッシュアプリケーションソフトウエアがハイブリッドオブジェクト−リレーショナルデータベースシステム４０８を有する。
【００５５】
クライアントは、任意の数のデータベースフロントエンドであって良い。これには、パワービルダー、ｄベース、パラドックス、マイクロソフトアクセス等が含まれる。例としての実施例では、フロントエンドがＳＱＬアクセスドライバを、ＳＱＬデータベースサーバテーブルをクライアント／サーバ環境でアクセスするために有する。
【００５６】
本発明はただ１つのコンピュータで機能することができるが（図３の例のように）、本発明は有利には、例えばクライアント／サーバシステムのようなマルチユーザコンピュータシステムで実現することができる。図５は、有利な実施例のクライアント／サーバシステム５００の一般的構造を示す。図示のようにシステム５００は、１つまたは複数のクライアント５０２を有し、これらはライブキャッシュサーバ５０４にネットワーク５０６を介して接続されている。とりわけクライアント５０２は１つまたは複数のスタンドアローン端末機５０８を有し、この端末機は従来のネットワーク５００を使用して、サーバに存在するシステムに接続される。
【００５７】
ライブキャッシュサーバ５０４は一般的に独立のプロセスとして動作し、このプロセスは、サーバ上のサーバオペレーティングシステム、例えばマイクロソフトＮＴ（Microsoft Corp.）下で実行される。ネットワーク５０６は、任意の数の従来のネットワークシステム、例えばローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）、並びに他の公知技術（例えばイーサネット、ＩＢＭトークンリング等を使用する）であって良い。ネットワーク５０６は、クライアントコールを公知の言語ＳＱＬ（構造化問い合わせ言語）でいずれかのパラメータ情報と共にパッケージ化し、ケーブルまたはデータ線路を介した伝送に適したフォーマットでライブキャッシュサーバ５０４に伝送する機能性を有している。
【００５８】
図６は、ライブキャッシュサーバが有利な実施形態で実現されるフレームのブロック回路図である。ＥＲＰシステム６００がデータリンク６０４を介してメインＥＲＰデータベースサーバ６０２と接続されている。ＥＲＰシステム６００は、企業の毎日のオペレーションに対してトランザクションマネージメントを提供する。前記のトランザクションはメインＥＲＰデータベースサーバ６０２に書き込まれる。ＥＲＰシステム６００はまたアプリケーションサーバ６０６と接続されている。ＥＲＰシステム６０２とアプリケーションサーバ６０６との間にはデータリンク６０７が存在する。ライブキャッシュサーバ６０８上には大容量のメインメモリ６１０があり、このメモリにはライブキャッシュアプリケーション６１２およびこれに含まれるデータベースシステム６１４が常駐する。演算データはＥＲＰデータベース６０２の従来のリレーショナル構造に記憶される。
【００５９】
図７は例として情報の流れのシーケンスを示す。ユーザは注文をＥＲＰシステム７００に入力し、この注文はライブキャッシュサーバ７０４に伝送され７０２る。ここでルールベースのＡＴＰ機能７０６（格納されている可能な手続きの例）が、その製品が搬送可能であるか否かをチェックする。可能でなければ７０８、製品プランニング機能部７１０（格納されていて可能な手続きの別の例）がプランニング注文７１２を作成し、これをＥＲＰシステム７００に戻し送信し、ここでそれが実行される。
【００６０】
図８は、本発明によるライブキャッシュアプリケーションの詳細な図である。メインメモリ８００はライブキャッシュアプリケーションを含む。ライブキャッシュアプリケーションはＯＭＳ８０２，ＳＱＬクラス８０４，ＯＭＳベース８０６，ＳＱＬベース、そしてデータログ８１０からなる。ここでＳＱＬベースはＢ＊ツリー８０８を含み、データログはＯＭＳ並びにＳＱＬベースのトランザクションマネージメント機能を記録する。メモリはまたリレーショナルデータ記憶機構８１２並びにオブジェクトデータ記憶機構８１４を含む。ＣＯＭオブジェクトはレジスタ８１６に登録され、ＣＯＭメモリコンテナ８１８に記憶される。タイプ・ライブラリー８２０は、ＣＯＭオブジェクトが入力パラメータに対して提供したインタフェースについての情報を維持する。インタフェース８２２は、記憶された手続きを呼び出し、入力パラメータを供給する手段である。
【００６１】
記憶された手続きは、ＣＯＭメモリコンテナ８１８に記憶されたＣＯＭオブジェクトの方法として実現される。本発明によりユーザは、プログラミング言語の持続的クラス、例えばＣ＋＋クラスを形成することができる。このクラスはオブジェクトクラスであり、ＯＭＳ８０２に記憶することができる。オブジェクトクラスは、リレーショナルデータを記憶するため、オブジェクト指向の最適化されたデータ構造であり、このリレーショナルデータはメインＥＲＰデータベースからインポートされる。最適化されたデータ構造は言い替えれば、メインＥＲＰデータベースからインポートされたデータである。このデータ構造に従いオブジェクトとして記憶されたデータは、オブジェクトクラスの例である。図９は、最適化されたデータ構造の例を示す。有利な実施例では、最適化されたデータ構造は、３／３／９８出願のＵＳ特許願０９／３３８４０に参照されており、本発明と共に使用するのに適する。図９は、製品注文９００を示し、これはオブジェクトとしてオブジェクトデータメモリ８１４に記憶され、アクティビティのネットワークからなる。このネットワークは第１のアクティビティ９０２と、中間のアクティビティ９０６を備える最後のアクティビティ９０４を有する。第１＿入力インタフェース＿ノード９０８があり、このノードで入力パラメータが作成される。さらに第１＿出力インターフェース＿ノード９１０があり、このノードは製品注文９００の結果を送出する。それらの間のアクティビティおよびリンクはＥＲＰデータベースサーバ６０２に、伝統的なリレーショナルフォーマットでテーブルに記憶される。この伝統的リレーショナルデータ１０００はライブキャッシュサーバに伝送され、最適化されたデータ構造１００２にマッピングされる。それらの例が図１０に示されている。ここの個々の製品注文は相互にリンクされており、図１１で説明する注文ネットを形成する。図１２は、図９，１０に示されたモデルにマッピングすることのできるシナリオの例を示す。ネットワーク１２００は３つの層からなる。すなわち、マシーン１２０２，分配センタ１２０４および顧客要求１２０６である。これらオブジェクト指向のデータモデルはメインメモリ８００（図８参照）のオブジェクトメモリコンテナ８１４に記憶される。これらのデータモデルは、データアクセスを促進し、これらのおける機能の高速実行を可能にする。複数のクラスがこのネットワーク内に存在することができる。１つのクラスのオブジェクトから別のクラスのオブジェクトへの参照も存在することができる。各記憶された手続きは所定のオブジェクトクラスに配属され、これらオブジェクトクラスの例でだけ動作する。しかし各オブジェクトクラスは２つ以上の記憶された手続きを有することができる。記憶された手続きは例えばＣ＋＋で記述され、下に説明するようにＣＯＭオブジェクト上の方法として実現される。
【００６２】
ライブキャッシュを実現するために選択された方法は、既存のＯＲＤＢＭＳで使用されるアプローチとは異なる。これら従来の方法では、扁平なデータ構造（テーブル）が複雑なデータタイプによって改善されていた。このシステムでのデータへのアクセスは専らＳＱＬによって行われるから、ローカルＳＱＬ実現が、複雑なデータへのアクセスを可能にする言語構造によって拡張された。したがって、ネット状の構造１２００を図１２に示すように、リレーショナルなパターン（テーブル）にシフトしなければならない。本発明では、リレーショナル環境とオブジェクト指向環境のデータモデル化は別個のままである。ＳＱＬをモデル化と、リレーショナル環境での動作に使用することができる。一方、ライブキャッシュクラス（例えばＣ＋＋クラスのフォーマット）がモデル化と、オブジェクト指向環境での動作のために存在する。複雑なオブジェクトは別個のメモリコンテナ８１４に記憶され、これはリレーショナルなデータベース記憶構造８１６とは区別される。
【００６３】
ユーザは前記のオブジェクトクラスを、上に持続的Ｃ＋＋クラスとして説明したように定義する。このような定義は、ＯＭＳ８０２のＣ＋＋でのオブジェクトマネージメント機能により行われる。これは例えば、機能ＣＲＥＡＴＥまたはＳＴＯＲＥである。ＯＭＳ８０２によりサポートされたオペレーションには以下のものがある：記憶されたオブジェクトの呼び出し、記憶されたオブジェクトの置換、記憶されたオブジェクトの追加、記憶されたオブジェクトの除去、新たなタイプの形成、そして存在するタイプおよびそのタイプの全ての例の破壊である。オブジェクト指向データの形成および操作に使用される全ての機能を含むＯＭＳクラスがある。オブジェクトクラスが定義された後、このオブジェクトクラスを基礎としてモデル化された全てのリレーショナルデータが、永続的Ｃ＋＋クラスの例としてオブジェクトメモリコンテナ８１４に記憶される。ＯＭＳベース８１６はこれらオブジェクトの記憶を管理する。
【００６４】
図１３は、ＯＭＳアーキテクチュアの概略図である。ＯＭＳ１３００はＯＭＳベース１３０２と接続されており、このＯＭＳベースはデータキャッシュ１３０４と接続されている。これは８０２として示されたＯＭＳと同じである。プライベートなＯＭＳキャッシュ１３０６は、処理が実行されるメモリアドレスである。各プライベートＯＭＳキャッシュ１３０６には固定的に所定のユーザセッションに割り当てられる。複数のユーザがライブキャッシュシステムにアクセスするとき、彼らには固有のプライベートＯＭＳキャッシュ１３０６が割り当てられ、その要求を処理することができる。さらに複数のユーザは、各ユーザセッションに対して実行される記憶された手続きのうち固有の別個の例を有する。記憶された手続きには、ＯＭＳのオブジェクトマネージメント方法に対する呼び出しが含まれる。Ｃ＋＋方法１３０８は、ＯＭＳ１３０ともプライベートＯＭＳキャッシュ１３０６とも接続されている。オブジェクトマネージメント方法は、オブジェクトデータをプライベートＯＭＳキャッシュへ呼び出す。データがすでにプライベートＯＭＳキャッシュに存在する場合にはこのステップはバイパスされる。
【００６５】
ＯＭＳベース１３０２の機能性を以下に説明する。このＯＭＳベースは公知の記憶技術を使用し、これを以下簡単に説明する。図１４に示すように、ＯＭＳベース８０６は各オブジェクトクラスに対するページチェーンからなる。これは、データキャッシュ１３０４とプライベートＯＭＳキャッシュ１３０２との間の全ての入／出力オペレーションを行うコンポーネントであり、その物理的メモリアドレスを管理する。オブジェクトデータはオブジェクトメモリコンテナ８１４のページに記憶される。例えばＯＭＳ１３００が所定の特別データオブジェクトを所定のページｐで呼び出すよう要求すると（図１５参照）、ＯＭＳベースはこのページｐがメインメモリのどこにあるかを正確に知らなければならない。しかしＯＭＳベース１３０２のユーザ、ＯＭＳ１３００はこの情報を知る必要はない。その代わりにＯＭＳはメモリを単に、それぞれが固定の大きさのページ集合からなるページセットの論理的集合であるとみなす。各ページチェーンは、オブジェクトクラスにしたがって記憶されたオブジェクトの所定のセットに相応する。図１４は、ＯＭＳベースの記憶アーキテクチュアを示す。クラスａ１４００は、オブジェクトクラスにより定義される所定の最適データ構造に相応する。クラスａ１４００はさらにコンテナａ１、１４０２とａ２、１４０４とに分割され、これらはさらに個々のページチェーンａ１．１、１４０６，ａ１．２、１４０８，ａ１．３、１４１０およびａ１．４、１４１２、並びにａ２．１、１４１４，ａ２．２、１４１６，ａ２．３、１４１８およびａ２．４、１４２０からそれぞれなる。各ページはさらに、メモリ内で一義的なページ番号により識別される。種々のページセットは結合されてない（すなわち共通のページはない）。ページ番号と物理的メモリアドレスとのマッピングはＯＭＳベース１３０２により理解され、維持される。
【００６６】
ＯＭＳはＯＭＳベース１３０２を次のように使用する。すなわち、ユーザがメモリを記憶されたオブジェクトの集合と見なすように使用する。各ページは、記憶されたオブジェクト１５０４の１つまたは複数を含む。各記憶されたオブジェクト１５０４はオブジェクト識別子（ＯＩＤ）により識別される。ＯＩＤはページ番号１５０２およびこのページに対して一義的な所定値からなり、これはこの実施例ではページオフセット１５０４である。持続的オブジェクト、例えばＣ＋＋オブジェクトのＯＩＤは、相応するデータエレメント（全体長８バイト：ページ番号４バイト:スロット番号２バイト：クラスＩＤ１バイト：そしてバージョン１バイト）に対するページアドレスを含む。内部ページオフセットは、スロット位置および固定のデータエレメント長から計算することができる。ＯＩＤは物理的オブジェクトアドレスを含まず、論理的オブジェクトアドレスを含む。有利な実施例のＯＩＤ１６００が図１６に示されている。このＯＩＤは、データページ番号１６０２，データページオフセット１６０４，クラスＩＤ１６０６，およびバージョン１６０８からなる。データページ番号１６０２は、ハッシュ法でデータキャッシュアドレスに参照されるオブジェクトのデータページに関連する。データページオフセット１６０４は、データページでのオブジェクトのオフセットである。クラスＩＤは、どの所定のクラスにオブジェクトが所属するかを識別する。アプリケーションは常に、ＯＩＤをオブジェクトへの有効なアクセスを得るために使用する。
【００６７】
以下、図１７に示されたライブキャッシュ記憶機構の簡単な実施例を説明する。まず、データベースにはデータが何もないと仮定する。１つのページセット、すなわち４ページ１７０２〜１７０８を全てディスク上に含む空き空間ページセットが存在するだけである。これらのページには１つずつシーケンシャルに通し番号が付され、５つのオブジェクトが１つのページに適合するとする。有利な実施例では、各ページが複数のオブジェクトを導く。例えば１０の供給者オブジェクト１７１０〜１７３０を記憶したいとする。ＯＭＳはクラスを登録し、これによりオブジェクトコンテナ１７１６を形成する。まず最初に、ＯＭＳは「供給者オブジェクトページ番号」１７１４を供給者オブジェクトに対して形成することを要求する。これはハッシュキーを備えたクラスを登録する。クラスの新たな例が相応のＯＩＤと共に形成される。ＯＭＳベースは、最初の２ページ１７０２，１７０４を空き空間ページセットから除去し、これらを「供給者オブジェクトページセット」としてラベリングする。１０の供給者オブジェクト１７１０〜１７３０が２つのページに記憶される。この状況でＯＭＳが新たな供給者オブジェクトを挿入すると、ＯＭＳベースは第１の空きページを空き空間ページセットから見出し、これを「供給者オブジェクトページセット」に追加する。ＯＭＳが記憶されたオブジェクトを消去すれば、ＯＭＳベースはこの空間を使用可としてマークする（ページのフラグ消去）。そしてこの空間は使用可能な空間のチェーンで使用可能と記録される。ページ上の全てのオブジェクトが消去されたなら、このページをページマネージメントにさらに供給することができる。
【００６８】
挿入は第１の空きオブジェクトフレームで行われる。空きのオブジェクトフレームを含むページのチェーンが存在する。空きオブジェクトフレームを有するページはいずれもがこのチェーンの一部である。アップデートは付加的なメモリを必要とせず、したがってメモリ内部からの過負荷を引き起こさない。新たな挿入はまず、消去されたデータエレメントの位置を使用し、次にコンテナ端部の空間を要求し、そして最後に新たなページを要求する。オプションとしてタイプに対し、新たな登録は端部にだけ挿入できると定義することができる。この場合、消去された登録からの空間は再使用されない。完全に空きのページはチェーンから除去され、空き空間ページ集合に戻される。
【００６９】
所定のページ集合におけるページの論理的シーケンスは、物理的隣接性によってではなく、図１８に示すポインタにより指示しなければならない。この図にはページのシーケンスが示されている。各ページはページヘッダ１８００、すなわち制御情報の集合を含む。これら制御情報には、論理シーケンスでこのページに直接続くページのメモリアドレスが含まれる。ページヘッダ１８００を備えるページは、ページヘッダ１８０２を備える論理的に次のページに物理的に隣接してはならない。ページヘッダはＯＭＳベースにより管理され、これによりＯＭＳ自体にとっては不可視である。オブジェクトだけがＯＭＳにとって可視である。
【００７０】
要約すると、ＯＭＳベースはページマネージメントを永続的オブジェクトコンテナに対して提供する。これは固定サイズのデータページのダブルリンクチェーンからなる。シングルクラスも複数のコンテナからなることもできる。このシングルクラスはクラス属性によってパーティションすることができる。クラス１６０６はまたコンテナｉｄを含み、これはＯＭＳにどのコンテナにオブジェクトが存在するかを通知する。オブジェクトは固定長のオブジェクトフレーム（データエレメント）に記憶される。なぜならクラスの全ての例、例えばＣ＋＋クラスの例は全て同じ大きさを有するからである。これは一定のオブジェクト状態へのアクセスをログを介して提供する。オブジェクトフレームは再使用される。空きのオブジェクトフレームは別個の空きチェーンに保持される。最大のオブジェクト長はデータページの大きさにより制限される。
【００７１】
上に述べた最適データ構造を使用する有利な実施例では、各オブジェクト例に対するＯＩＤが伝統的なリレーショナルフォーマットで記憶される。図１９は、ＯＩＤを記憶するためのリレーショナルテーブル構造を示す。注文番号１９００からなるキー値列がある。別の列１９０４〜１９１０にはオブジェクト属性を記憶することができる。ＯＩＤ１９０２は注文オブジェクト１９０４を指示し、この注文オブジェクトはオブジェクトメモリコンテナ８１４（図８参照）に記憶されている。ユーザが注文オブジェクト１９１２内のアクティビティにアクセスしたい場合、付加的テーブル９１４を設けることができる。この付加的テーブルは、ＯＩＤを備える第１の列１９１６，オペレーション番号を備える第２の列１９１８，別の注文番号を備える第３の列１９２０，そしてアクティビティ１９２２へのポインタからなる。いったんリレーショナルデータが最適データ構造にマッピングされ、オブジェクトとしてＯＭＳ８０２を介してオブジェクトメモリコンテナ８０４に記憶され、そして記憶された手続きをＣＯＭオブジェクトコンテナに記憶し、レジスタデータベースに登録したなら、ユーザはライブキャッシュシステムをデータ処理のために問い合わせることができる。データの問い合わせは記憶された手続きにより行われ、これによりオブジェクトマネージメント方法を呼び出すことができる。
【００７２】
図２０は本発明の別の概観を示す。アプリケーション２０００，２００２，２００４がライブキャッシュを、その相応のプライベートセッション２００６，２００８，２０１０により記憶された手続きを通して問い合わせる。この問い合わせは、ＳＱＬ層２０１２で解釈され、ＣＯＭオブジェクト２０１４の相応する方法、並びにデータ２０１６をデータ層２０１８からＯＭＳ層２０２０を介して呼び出す。記憶された手続きは、プライベートＯＭＳキャッシュの一部であるデータにアクセスし、したがってＯＭＳではデータをデータキャシュからプライベートＯＭＳキャッシュに呼び出す。アプリケーションは、ライブキャッシュ機能性をＳＱＬにより、記憶された手続きの呼び出しによって呼び出す。例えばプログラミング言語Ｃ＋＋で記述されたＣＯＭオブジェクトはＯＭＳ層により相応のプライベートＯＭＳキャッシュへ次のようにリンクされる。すなわちデータ伝送がアドレス空間間で行われないようにリンクされる。図２１に示すように、アプリケーションプログラム２１０２がアプリケーションサーバ２１００内でＳＱＬ問い合わせ２１０４を発行し、このＳＱＬ問い合わせは機能をＣＯＭオブジェクトメモリから呼び出す。このＣＯＭオブジェクトメモリで機能は、この所定のアプリケーションプログラム２１０２に割り当てられたプライベートＯＭＳキャッシュにダイナミックにリンクされている。このＳＱＬ問い合わせは記憶された手続きに対する呼び出しを含む。この記憶された手続きはＣＯＭオブジェクトの方法として記憶されている。オブジェクトデータは記憶された手続きから呼び出される。ＳＱＬ問い合わせは、有利な実施例では２つの部分からなる。記憶された手続きは呼び出され、ダイナミックにライブキャッシュカーネルにリンクされる。ダイナミックリンクにより、データでのオペレーションがコストの掛かるアドレス空間切り換えなしで可能である。プライベートＯＭＳキャッシュは、ＣＯＭオブジェクトの例の一部である。ＣＯＭオブジェクトは、プライベートＯＭＳキャッシュが存在する環境である。問い合わせは、処理に必要なオブジェクトの所定セットを含む。問い合わせはデータオブジェクトを所定の参照、例えば製品注文番号９００により呼び出す。この番号が発見され、相応のＯＩＤがテーブル２１０４に見出される。ＯＩＤは次に物理的メモリアドレスにマッピングされる。この時点で、オブジェクトのコピーは、その所属の記憶された手続きが使用可能であるのと同じアドレス空間で使用可能となる。機能に入力すべきパラメータデータタイプは例えばスカラーＣ＋＋データタイプ（int, float, char, arrays 等）フラット構造または内部ＡＢＡＰテーブルである。
【００７３】
ライブキャシュサーバが所定のオブジェクトを記憶、呼び出し、または表示する速度を上昇させるため、サーバは１つまたは複数のデータベースインデクスをテーブルに保存する。通常はＢツリー構造として保存されるデータベースインデクスにより、データエレメントを多種多様に、とりわけユーザの必要性に依存して編成することができる。インデクスは、インデクスキー値を一義的なデータエレメント番号と共に記憶するファイルとして構成することができる。後者は、データエレメントの１つまたは複数のフィールドからなるデータ量である。この値は、データバンクファイル−データエレメントを所定の所望の順序（インデクス表現）により（論理的に）配列するため使用される。後者は、データベースファイルにおける各データエレメントの実際の記憶場所に対する一義的なポインタまたは識別子である。両者を参照することにより、内部システムによってデータベースファイルにあるデータエレメントが見出され、表示される。これらのツリーは、図８に示されたＳＱＬベース８０８に記憶される。別の手段では、持続的クラス、例えばＣ＋＋クラスにハッシュキーを割り当てる。このようにしてＯＭＳは、キーの変換に対するハッシュインデクスをＯＩＤに提供することができる。このようにしてキーまたはＯＩＤを介して自分のオブジェクトを参照することができる。
【００７４】
ＯＭＳキャッシュは、プライベートキャッシュをセッション固有の持続的オブジェクトに対して提供する。ＯＩＤは、オブジェクトの存在するキャッシュアドレスにマッピングされる。オブジェクトへの第１のアクセスはＯＭＳベースを介して行われる。この時点でオブジェクトコピーがプライベートキャッシュに配置される。後続のアクセスはプライベートキャッシュ内のオブジェクトコピーを使用する。この使用は、プライベートキャッシュにあるメモリアドレスへのＯＩＤをハッシュ法により参照することにより行われる。
【００７５】
オブジェクトデータをメモリからＯＭＳおよびＯＭＳベースにより上に説明した機構を介して呼び出す場合、有利な実施例はさらにトランザクションマネージメントを提供する。このトランザクションマネージメントは、例えばリレーショナルモデルでオブジェクトマネージメントシステム（ＯＭＳ）により使用されたものと同じである。このようなマネージメントは従来技術から公知であるが、以下に有利な実施例で簡単に説明する。
【００７６】
トランザクションとは論理的処理ユニットである。トランザクションが２つのアップデートからなる場合、一方のアップデートを実行し、他方を実行しないことは許されない。なぜならこのことは、データベースに不一致状態を引き起こすからである。この最小単位を提供するシステムコンポーネントはオブジェクトマネージメントシステムであり、伝統的システムにおけるトランザクションマネージャと同価である。ＯＭＳは２つの整数演算、ＣＯＭＭＩＴとＲＯＬＬＢＡＣＫを有する。
【００７７】
トランザクションＣＯＭＭＩＴは成功したトランザクション終了を通知する。このＣＯＭＭＩＴはＯＭＳに、論理的処理ユニットが成功裏に終了し、データベースに再び一致状態が存在し、この処理ユニットにより実行された全てのアップデートを引き渡すことができるか、または永続的なものにできることを通知する。トランザクションＲＯＬＬＢＡＣＫは失敗したトランザクション終了を通知する。このＲＯＬＬＢＡＣＫはトランザクションマネージャに、エラーが発生し、データベースに不一致状態の存在する可能性があり、論理処理ユニットによりこれまで実行された全てのアップデートをロールバックしなければならないか、または取り消さなければならないことを通知する。両者のアップデートの一方にエラーが発生すれば、ＲＯＬＬＢＡＣＫが出力され、これまでの変更全てが取り消される。ＯＭＳは、上に図８で示したようにログ８１０を記憶媒体、例えばメモリディスクに保存する。メモリディスクには、全てのアップデートオペレーションの詳細、とりわけ更新されたオブジェクトの前の値と後の値が記録される。したがって所定のアップデートを取り消すことが必要な場合には、ＯＭＳは相応のログエントリーを用いて、更新されたオブジェクトをその前の値に戻すことができる。
【００７８】
トランザクションは、指示「トランザクション開始」の実行により開始され、ＣＯＭＭＩＴ指示またはＲＯＬＬＢＡＣＫ指示の実行により終了する。ＣＯＭＭＩＴは引き渡しを確定する。引き渡し時点は論理的処理ユニットの終了時に相当する。これに対してＲＯＬＬＢＡＣＫはデータベースを、ＢＥＧＩＮの時点の状態に戻す。引き渡し時点が確定したなら、先行の引き渡し時点からの全ての変更が永続的なものにされる。トランザクションが成功したなら、ＯＭＳはアップデートをやはり永続的なものとしてデータベースに格納することを、システムが直ちにクラッシュした場合であっても保証する。ＯＭＳシステムの再スタート手続きはこのアップデートをデータベースにインストールする。再スタート手続きは、書き込むべき値をログでの該当する登録の検査により発見することができる。
【００７９】
有利な実施例のＯＭＳは複数のアクセス法を有する。“Deref Object”はオブジェクトをＯＭＳキャッシュ点に参照する。“Deref Object by key”はオブジェクトをハッシュインデクスについての参照と共にＯＭＳキャッシュにコピーする。“Scan object”は次のオブジェクトをオブジェクトコンテナから戻す。“Lock object”はオブジェクトを施錠する。“Refresh object”は場合によりオブジェクトの最新の状態をＯＭＳキャッシュにコピーする。“Release object”はオブジェクトをＯＭＳキャッシュから消去する。
【００８０】
セッションマネージメントのオペレーションは例えばＣ＋＋クラスの方法として実現される。有利な実施例ではトランザクションモードに３つの形式がある。暗黙動作モードでは、施錠が暗黙的に要求され、ＯＭＳはプライベートキャッシュへのオブジェクトコピーをロックする。楽観的動作モードでは、“Deref object”は一定の見解を使用する。さらにオペレーション、ロックと格納がプライベートキャッシュレベルで制限され、ライブキャッシュデータの変更が行われない。悲観的動作モードでは、“Deref Object”は相変わらず一定の見解を使用する。しかしオペレーション、ロックと格納は共通に使用されるオブジェクトに直接作用しない。一定の見解では、完全なオブジェクトデータが“仮想的に”トランザクションの開始時に凍結される（primsh、１７）。
【００８１】
図２２は上に説明したトランザクションマネージメントの例である。トランザクションＴ１，２２００がオブジェクトＡ２２０２を要求すると、これがロックされる２２０４。処理の終了後にオブジェクトＡ２２０２は再び記憶される２２０６。記憶機能が終了すると、トランザクションは引き渡される２２０８。トランザクションＴ２，２２１０はオブジェクトＢ２２１２とオブジェクトＣ２２１４の処理を要求する。両者は処理中、ロックされる２２１６，２２１８。前記の処理後に両者は記憶される２２２０，２２２２。そしてトランザクションが引き渡される２２２４。
【００８２】
トランザクションＴ３，２２２６はオブジェクトＡ２２０２、オブジェクトＢ２２１２およびオブジェクトＣ２２１４の処理を要求する。しかしこれはトランザクションＴ２が引き渡される前に開始するから、この処理はＢとＣの古いイメージにより行わなければならない２２２８。この処理はＡ２２３０の最後のイメージにより実行することができる。ログ８１０が図２３に示されている。従来技術で公知であるトランザクションマネージメントテーブル２３００が示されている。ログファイル２３０３は、古いオブジェクトイメージ２３０４も、新しいオブジェクトイメージ２２０６もトランザクションが引き渡されるまで記憶する。
【００８３】
システムはさらに、ライブキャッシュシステムの初期母集団にしたがってデータ同期することができる。データをメインＥＲＰデータベース７０２からライブキャッシュサーバ７０６へ、ライブキャッシュのアクティブ化に基づき初期伝送した後、データはライブキャッシュに更新されて保持される。これはメインＥＲＰデータベースのデータを反映するためである。トランザクションがＥＲＰシステム７００に発生する間、このトランザクションはＥＲＰデータベース７０２に書き込まれ、在庫レベルの変更およびリソース使用可能性の変更を各トランザクション後に反映するようにする。これらのデータ変更は同時にライブキャッシュサーバのメインメモリに保存されたデータでも例えばＯＭＳのＣ＋＋機能を介して行われる。
【００８４】
最初に、図２４のステップ１，２４００に示すようにデータがＤＢサーバ２４０２からＥＲＰソフトウエア２４０４によりユーザサーバ２４０６を通ってライブキャッシュサーバ２４０８に伝送され、そこで最適データ構造２４１１へ伝送される。図２５に示されたステップ２，２５００は、ライブキャッシュサーバ２５０２からＥＲＰソフトウエア２５０４への、そしてＤＢサーバ２５０６への２つのデータ流を示す。このデータ流は、ライブキャッシュシステムがアプリケーションサーバの要求の応じて実行すべきプランを形成するときに発生する。最後に図２６に示されたステップ３，２６００はどのようにデータをライブキャッシュサーバ２６０２で、トランザクションがＥＲＰソフトウエア２６０４により処理される間に更新し続けるかを示す。上に述べたように、ライブキャッシュのデータは上書きされ、これにより必要メモリが最小になる。
【図面の簡単な説明】
【図１】 図１は、本発明を提供するのに適した環境の概略図である。
【図２】 図２は、従来技術の概略図である。
【図３】 図３は、本発明を実現することのできるコンピュータシステムの概略図である。
【図４】 図４は、図３のコンピュータシステムの動作を制御するためのソフトウエアサブシステムを示すブロック回路図である。
【図５】 図５は、本発明が有利に実現されるクライアント／サーバシステムのブロック回路図である。
【図６】 図６は、本発明の有利な実現例を概略図である。
【図７】 図７は、本発明の有利な実施例で開始される例としてのトランザクションの概略図である。
【図８】 図８は、本発明の有利な実施例の構造概略図である。
【図９】 図９は、本発明でＵＤＴと定義することのできる例として最適データ構造の構造概略図である。
【図１０】 図１０は、オブジェクト指向モデルへの関係からデータをマッピングする概略図である。
【図１１】 図１１は、図９の再提起データ構造により構成されたプラニングモデルの例を示す概略図である。
【図１２】 図１２は、オブジェクト指向のデータモデル化に適する分散ネットワークの概略図である。
【図１３】 図１３は、オブジェクトマネージメントシステムの構造の概略図である。
【図１４】 図１４は、ＯＭＳバンクでのオブジェクトデータ記憶の構造の概略図である。
【図１５】 図１５は、データオブジェクトが記憶されたページメモリレイアウトの概略図である。
【図１６】 図１６は、有利な実施例でのオブジェクト識別子の構造の概略図である。
【図１７】 図１７は、本発明によるメインメモリのページメモリレイアウトのオブジェクト記憶を示す概略図である。
【図１８】 図１８は、本発明によるページメモリレイアウトでのページシーケンスを示す概略図である。
【図１９】 図１９は、本発明で使用するのに適する最適データモデルのＯＩＤを示す概略図である。
【図２０】 図２０は、アプリケーションオブジェクトとライブキャッシュサーバとの間のインターフェースを示す概略図である。
【図２１】 図２１は、機能およびオブジェクトデータを呼び出すためのライブキャッシュサーバでのＳＱＬ問い合わせの発行方法を示す。
【図２２】 図２２は、本発明のトランザクションマネージメントシステムの概略図である。
【図２３】 図２３は、本発明のトランザクションマネージメントシステムに対するログを示す。
【図２４】 図２４は、本発明のデータ同期手段のステップ１を示す。
【図２５】 図２５は、本発明のデータ同期手段のステップ２を示す。
【図２６】 図２６は、本発明のデータ同期手段のステップ３を示す。
【符号の説明】
２００ ハードディスク
２０２ ＤＢサーババッファ
２０４ アプリケーションサーババッファを有するアプリケーションサーバ、データベースサーバ
３０２ 中央プロセッサ
３０４ メインメモリ
３０６ 入／出力制御部
３０８ キーボード
３１０ ポインティングデバイス
３１２ スクリーンディスプレイ
３１４ 大容量記憶装置
４０２ オペレーティングシステム
４０４ シェル
４０６ ユーザインタフェース、ユーザ
４０８ ＲＤＢＭＳクライアント、アプリケーションプログラム
５０２ クライアント
５０４ ライブキャッシュサーバ
５０６ ネットワーク
５０８ ＰＣまたは端末機
６００，６０６ アプリケーションサーバ
６０２ ＤＢサーバ
７０２ ＡＴＰ要求
７０４ ライブキャッシュサーバ
７１２ 計画された注文
８００ 命令分析器
８０４ ＳＱＬクラス、方法埋め込みのためのフレーム
８０６ ＯＭＳベース、ページチェーン
８０８ ＳＱＬベース
８１０ ログ
８１２ ＳＱＬデータ
８１４ オブジェクトデータ
８１６ レジストリ
８１８ ＣＯＭオブジェクト（ＤＬＬ）
８２０ タイプライブラリ
８２２ Ｒ／３コアのライブキャッシュインタフェース
９００ 製品注文、レジェンド、アクティビティ製品材料、アクティビティ消費材料、アクティビティ消費および製品材料、アクティビティ消費または製造されない材料
９０２ 第１のアクティビティ
９０８ 第１の入力、インタフェースノード
１０００ ＢＯＭ、ルーティング、リレーショナルモデル、調整可能
１００２ オブジェクトモデル
１２０２ マシーン、搬送注文、製品注文
１２０４ 分配センタ
１２０６ 顧客要求
１３０２ ＯＭＳベース（ページチェーン）
１３０４ データキャッシュ
１３０６ プライベートＯＭＳキャッシュ
１４００ クラスａ
１４０２ クラスａ１
１４０４ クラスａ２
１５００ ページｐ
１５０２ ページ番号
１５０４ ページ終了部からのオフセット
１５０４ オブジェクト
１６０２ データページ番号（データキャシュアドレスへのハッシュ参照によるオブジェクトのデータページへの参照）
１６０４ データページオフセット（データページ上でのオブジェクトのオフセットと共に）
１６０６ クラスＩＤ（オブジェクトが所属するクラス）
１６０８ バージョン（オブジェクトフレームの再使用を可能にする）
１７０２ ５つのオブジェクト
１９１２ 注文
２０００ アプリケーション１（プログラミング言語ＡＢＡＰ／４）
２００２ アプリケーション２（プログラミング言語：Ｃ）
２００４ アプリケーション３（プログラミング言語：Ｃ＋＋）
２００６ セッション１
２００８ セッション２，セッション３
２０１０ セッション４
２０１４ ＣＯＭオブジェクト
２０１８ データ
２０２０ ライブキャッシュマネージメントシステム
２１００ アプリケーションサーバ
２１０２ ＡＢＡＰアプリケーションプログラム
２１０４ 最適化された方法コーディングにより実行される手続き“Schedule＿order”、Schedule＿order
２２０２ オブジェクトＡ
２２０４ Ａのロック
２２０６ Ａの格納
２２０８ Ａの引き渡し
２２１２ オブジェクトＢ、トランザクション実行
２２１４ オブジェクトＣ
２２１６ Ｂのロック
２２１８ Ｃのロック
２２２０ Ｂ、Ｃの格納
２２２２ Ｃの格納
２２２４ トランザクション実行
２２２８ Ｂの古いイメージ、Ｃの古いイメージ
２２３０ Ａの新しいイメージ
２３００ トランザクションマネージメント
２３０４ 古いオブジェクトイメージ
２３０６ 新しいオブジェクトイメージ、Ｔ１−一定の読み出し、ｓ ロックされた、オブジェクト本体
２４００ ＡＰＯ母集団
２４０２ ＤＢサーバ
２４０４ アプリケーションサーバ
２４０６ アプリケーションサーバ
２４１０ データ構成、最適化された
２５０４，２５０８ アプリケーションサーバ
２５０６ ＤＢサーバ
２６００ オペレーション変更
２６０４ アプリケーションサーバ
２５０６ ＤＢサーバ

Claims (28)

1. データベースマネージメントシステムのデータオブジェクトで少なくとも１つの、記憶された手続きを記憶および実行するための方法において、
   ａ）オブジェクト指向で最適化された少なくとも１つのデータ構造を、オブジェクト指向のプログラミング言語の永続的クラスとして前記のデータベースマネージメントシステムで定義し、
   ｂ）リレーショナルなデータを前記のオブジェクト指向で最適化された少なくとも１つのデータ構造にマッピングし、
   ｃ）前記のリレーショナルなデータを、前記永続的クラスに所属する前記データオブジェクトとして記憶し、
   ｄ）前記データオブジェクトを物理的メモリに記憶し、
   ｅ）前記データオブジェクトに対して一義的であるオブジェクト識別子を形成し、
   ｆ）前記オブジェクト識別子をＳＱＬテーブルに記憶し、
   ｇ）前記少なくとも１つの記憶された手続きを、ＣＯＭオブジェクトコンテナに記憶されたＣＯＭオブジェクトに定義し、
   ｈ）前記少なくとも１つの記憶された手続きを、アプリケーションプログラムにより提供されるＳＱＬ問い合わせにより呼び出し、
   ｉ）複数の入力パラメータを前記少なくとも１つの記憶された手続きに対して提供し、
   ｊ）前記データベースマネージメントシステムをアドレス空間で実行し、
   ｋ）前記少なくとも１つの記憶された手続きを、前記データベースマネージメントシステムが実行されるアドレス空間にダイナミックにリンクし、
   ｌ）前記データオブジェクトのコピーを前記アドレス空間で作成し、
   ｍ）前記少なくとも１つの記憶された手続きを前記データオブジェクトで実行する、
   ことを特徴とする方法。
2. 前記データベースマネージメントシステムも前記データオブジェクトも共にコンピュータシステムのメインメモリに記憶する、請求項１記載の方法。
3. データベースマネージメントシステムのデータオブジェクトで、少なくとも１つの記憶された手続きを記憶および実行するためのシステムにおいて、
   ａ）オブジェクト指向で最適化されたデータ構造を、オブジェクト指向のプログラムイング言語の永続的クラスとして前記データベースマネージメントシステムに定義するための手段と、
   ｂ）リレーショナルなデータを前記オブジェクト指向で最適化された少なくとも１つのデータ構造にマッピングするための手段と、
   ｃ）前記のリレーショナルなデータを、前記永続的クラスに所属する前記データオブジェクトとして記憶するための手段と、
   ｄ）前記データオブジェクトを物理的メモリに記憶するための手段と、
   ｅ）前記データオブジェクトに対して一義的であるオブジェクト識別子を形成するための手段と、
   ｆ）前記オブジェクト識別子をＳＱＬテーブルに記憶するための手段と、
   ｇ）前記少なくとも１つの記憶された手続きを、ＣＯＭオブジェクトコンテナに記憶されたＣＯＭオブジェクトに定義するための手段と、
   ｈ）前記少なくとも１つの記憶された手続きを、アプリケーションプログラムにより提供されるＳＱＬ問い合わせにより呼び出すための手段と、
   ｉ）複数の入力パラメータを前記少なくとも１つの記憶された手続きに対して提供するための手段と、
   ｊ）前記データベースマネージメントシステムをアドレス空間で実行するための手段と、
   ｋ）前記少なくとも１つの記憶された手続きを、前記データベースマネージメントシステムが実行されるアドレス空間にダイナミックにリンクするための手段と、
   ｌ）前記データオブジェクトのコピーを前記アドレス空間で作成するための手段と、
   ｍ）前記少なくとも１つの記憶された手続きを前記データオブジェクトで実行するための手段と
   を有することを特徴とするシステム。
4. 前記データベースマネージメントシステムも前記データオブジェクトも共にコンピュータシステムのメインメモリに記憶されている、請求項３記載のシステム。
5. 前記オブジェクト指向のプログラミング言語はＣ＋＋である、請求項２記載の方法。
6. ａ）前記リレーショナルなデータをデータキャッシュに記憶し、
   ｂ）オブジェクトマネージメントシステムを、Ｃ＋＋機能の実行のために提供し、
   ｃ）前記データオブジェクトの記憶を、オブジェクトマネージメントシステムベースにより管理し、
   ｄ）プライベートオブジェクトマネージメントキャッシュを、前記少なくとも１つの記憶された手続きを実行するために提供する、請求項５記載の方法。
7. ａ）前記プライベートオブジェクトマネージメントキャッシュを、複数のユーザのそれぞれに割り当て、
   ｂ）前記少なくとも１つの記憶された手続きの別の例を、前記プライベートオブジェクトマネージメントキャッシュにおいて前記複数のユーザのそれぞれに対して提供し、
   ｃ）前記データオブジェクトの別の例を、前記複数のユーザのそれぞれに対して前記プライベートオブジェクトマネージメントキャッシュに提供し、
   ｄ）前記少なくとも１つの記憶された手続きの前記別の例を、前記データオブジェクトの前記別の例で実行する、請求項６記載の方法。
8. 前記データオブジェクトの記憶を管理する際にさらに：
   ａ）前記永続的なクラスに相応する複数のページを含むページチェーンを作成し、
   ｂ）前記データオブジェクトを前記複数のページに記憶し、
   ｃ）ページ番号と、該ページ番号に対して一義的な値とを有するテーブルを作成し、ここで前記ページ番号は前記データオブジェクトに対して一義的である前記オブジェクト識別子に相当し、
   ｄ）前記データオブジェクトの要求をユーザインタフェースから受信し、
   ｅ）前記オブジェクト識別子を、前記データオブジェクトが記憶されている前記物理的メモリにマッピングし、
   ｆ）前記データオブジェクトを呼び出す、請求項６記載の方法。
9. 前記データオブジェクトの前記呼び出しを容易にするため、データベースインデクスを作成する、請求項８記載の方法。
10. データベースインデクスはＢツリーデータ構造である、請求項９記載の方法。
11. ａ）前記少なくとも１つの記憶された手続きの実行を管理し、
    ｂ）前記少なくとも１つの記憶された手続きの実行が終了した後、トランザクションの引き渡しを実行し、
    ｃ）前記少なくとも１つの記憶された手続きの実行が終了しないままである場合、ロールバック・トランザクションを実行し、
    ｄ）前記トランザクションの引き渡しと、ロールバック・トランザクションとを前記データベースマネージメントシステムのログに記録し、
    ｅ）前記データオブジェクトの状態を、前記少なくとも１つの記憶された手続きの実行前に記録し、
    ｆ）前記データオブジェクトの前記状態を、前記少なくとも１つの記憶された手続きの実行前であって、前記ロールバック・トランザクションの記録後に呼び出す、請求項５記載の方法。
12. 前記オブジェクト指向のプログラミング言語はＣ＋＋である請求項４記載のシステム。
13. ａ）Ｃ＋＋機能を実行するための手段と、
    ｂ）前記データオブジェクトの記憶を管理するための手段と、
    ｃ）プライベートオブジェクトマネージメントキャッシュを、前記少なくとも１つの記憶された手続きを実行するために提供する手段と
    を有する請求項１２記載のシステム。
14. ａ）前記プライベートなオブジェクトマネージメントキャッシュを複数のユーザのそれぞれに割り当てるための手段と、
    ｂ）前記少なくとも１つの記憶された手続きの別の例を、前記プライベートオブジェクトマネージメントキャッシュにおいて前記複数のユーザのそれぞれに対して提供するための手段と、
    ｃ）前記データオブジェクトの別の例を、前記プライベートオブジェクトマネージメントキャッシュにおいて前記複数のユーザのそれぞれに対して提供するための手段と、
    ｄ）前記少なくとも１つの記憶された手続きの前記別の例を、前記データオブジェクトの前記別の例で実行するための手段と
    を有する請求項１３記載のシステム。
15. 前記データオブジェクトの記憶を管理するための前記手段はさらに、
    ａ）前記永続的なクラスに相応する複数のページを含むページチェーンを作成するための手段と、
    ｂ）前記データオブジェクトを前記複数のページに記憶するための手段と、
    ｃ）ページ番号と、該ページ番号に対して一義的な値とを有するテーブルを作成するための手段と、ここで前記ページ番号は前記データオブジェクトに対して一義的である前記オブジェクト識別子に相当し、
    ｄ）前記データオブジェクトの要求をユーザインタフェースから受信するための手段と、
    ｅ）前記オブジェクト識別子を、前記データオブジェクトが記憶されている前記物理的メモリにマッピングするための手段と、
    ｆ）前記データオブジェクトを呼び出すための手段と
    を有する請求項１３記載のシステム。
16. 前記データオブジェクトの呼び出しを容易にするため、データベースにインデクス作成するための手段を有する、請求項１５記載のシステム。
17. 前記データベースにインデクス作成するための手段は、Ｂツリーデータ構造である、請求項１６記載のシステム。
18. ａ）前記少なくとも１つの記憶された手続きの実行を管理するための手段と、
    ｂ）前記少なくとも１つの記憶された手続きの実行が終了した後、トランザクションの引き渡しを実行するための手段と、
    ｃ）前記少なくとも１つの記憶された手続きの実行が終了しないままである場合、ロールバック・トランザクションを実行するための手段と、
    ｄ）前記トランザクションの引き渡しと、ロールバック・トランザクションとを前記データベースマネージメントシステムのログに記録するための手段と、
    ｅ）前記データオブジェクトの状態を、前記少なくとも１つの記憶された手続きの実行前に記録するための手段と、
    ｆ）前記データオブジェクトの前記状態を、前記少なくとも１つの記憶された手続きの実行前であって、前記ロールバック・トランザクションの記録後に呼び出すための手段と
    を有する請求項１２記載のシステム。
19. 少なくとも１つの記憶された手続きを、Ｒ／３システムのデータオブジェクトで記憶および実行するための方法において、
    ａ）オブジェクト指向で最適化された少なくとも１つのデータ構造を、オブジェクト指向のプログラミング言語のクラスとして前記Ｒ／３システムに定義し、
    ｂ）前記Ｒ／３システムからのトランザクションデータを、オブジェクト指向で最適化された前記少なくとも１つのデータ構造にマッピングし、
    ｃ）前記Ｒ／３システムからのトランザクションデータを、前記永続的クラスに所属するデータオブジェクトとして記憶し、
    ｄ）前記データオブジェクトを物理的メモリに記憶し、
    ｅ）前記データオブジェクトに対して一義的であるオブジェクト識別子を形成し、
    ｆ）前記オブジェクト識別子をＳＱＬテーブルに記憶し、
    ｇ）前記少なくとも１つの記憶された手続きを、ＣＯＭオブジェクトコンテナに記憶されているＣＯＭオブジェクトに定義し、
    ｈ）前記少なくとも１つの記憶された手続きを、Ｒ／３システムにユーザインタフェースにより提供されるＳＱＬ問い合わせによって呼び出し、
    ｉ）複数の入力パラメータを前記少なくとも１つの記憶された手続きに対して提供し、
    ｊ）前記データベースマネージメントシステムをアドレス空間で実行し、
    ｋ）前記少なくとも１つの記憶された手続きを、前記Ｒ／３システムのデータベースマネージメントシステムモジュールが実行されるアドレス空間へダイナミックにリンクし、
    ｌ）前記データオブジェクトのコピーを前記アドレス空間に作成し、
    ｍ）前記少なくとも１つの記憶された手続きを前記データオブジェクトで実行する、
    ことを特徴とするシステム。
20. 複数の指示が記憶されたコンピュータ読み出し可能媒体であって、
    前記複数の指示は、プロセッサによる実行の際にプロセッサが以下のステップを実行するような指示を含む：
    ａ）オブジェクト指向で最適化されたデータ構造を、オブジェクト指向のプログラミング言語の永続的クラスとして前記データベースマネージメントシステムに定義するステップ；
    ｂ）リレーショナルなデータを前記オブジェクト指向で最適化された少なくとも１つのデータ構造にマッピングするステップ；
    ｃ）前記のリレーショナルなデータを、前記永続的クラスに所属する前記データオブジェクトとして記憶するステップ；
    ｄ）前記データオブジェクトを物理的メモリに記憶するステップ；、
    ｅ）前記データオブジェクトに対して一義的であるオブジェクト識別子を形成するステップ；
    ｆ）前記オブジェクト識別子をＳＱＬテーブルに記憶するステップ；
    ｇ）前記少なくとも１つの記憶された手続きを、ＣＯＭオブジェクトコンテナに記憶されたＣＯＭオブジェクトに定義するステップ；
    ｈ）前記少なくとも１つの記憶された手続きを、アプリケーションプログラムにより提供されるＳＱＬ問い合わせにより呼び出すステップ；
    ｉ）複数の入力パラメータを前記少なくとも１つの記憶された手続きに対して提供するステップ；
    ｊ）前記データベースマネージメントシステムをアドレス空間で実行するステップ；
    ｋ）前記少なくとも１つの記憶された手続きを、前記データベースマネージメントシステムが実行されるアドレス空間にダイナミックにリンクするステップ；
    ｌ）前記データオブジェクトのコピーを前記アドレス空間で作成するステップ；
    ｍ）前記少なくとも１つの記憶された手続きを前記データオブジェクトで実行するステップ；
    ことを特徴とするコンピュータ読み出し可能媒体。
21. 前記複数の指示は、プロセッサによる実行の際に、プロセッサが前記データベースマネージメントシステムと前記データオブジェクトの記憶をコンピュータシステムのメインメモリで実行するような指示を含む、請求項２０記載のコンピュータ読み出し可能媒体。
22. 前記複数の指示は、プロセッサによる実行の際、プロセッサがＣ＋＋を前記オブジェクト指向のプログラミング言語として提供するステップを実行するような指示を含む、請求項２１記載のコンピュータ読み出し可能媒体。
23. 前記複数の指示はさらに、プロセッサによる実行の際にプロセッサが以下のステップを実行するような指示を含む：
    ａ）前記リレーショナルなデータをデータキャッシュに記憶するステップ；
    ｂ）オブジェクトマネージメントシステムをＣ＋＋機能の実行のために提供するステップ；
    ｃ）前記データオブジェクトの記憶をオブジェクトマネージメントシステムベースにより管理するステップ；
    ｄ）プライベートオブジェクトマネージメントキャッシュを前記少なくとも１つの記憶された手続きの実行のために提供するステップ；
    請求項２２記載のコンピュータ読み出し可能媒体。
24. 前記複数の指示は、コンピュータによる実行の際に、プロセッサが以下のステップを実行するような指示を含む：
    ａ）前記プライベートオブジェクトマネージメントキャッシュを複数のユーザのそれぞれに割り当てるステップ；
    ｂ）前記少なくとも１つの記憶された手続きの別の例を、前記プライベートオブジェクトマネージメントキャッシュにおいて前記複数のユーザのそれぞれに対して提供するステップ；
    ｃ）前記データオブジェクトの別の例を、前記プライベートオブジェクトマネージメントキャッシュにおいて前記複数のユーザのそれぞれに対して提供するステップ；
    ｄ）前記少なくとも１つの記憶された手続きの前記別の例を、前記データオブジェクトの前記別の例で実行するステップ；
    請求項２３記載のコンピュータ読み出し可能媒体。
25. 前記複数の指示は、コンピュータによる実行の際に、プロセッサが以下のステップを実行するような指示を含む：
    ａ）前記永続的なクラスに相応する複数のページを含むページチェーンを作成するステップ；
    ｂ）前記データオブジェクトを前記複数のページに記憶するステップ；
    ｃ）ページ番号と、該ページ番号に対して一義的な値とを有するテーブルを作成するステップ；
    ここで前記ページ番号は前記データオブジェクトに対して一義的である前記オブジェクト識別子に相当し、
    ｄ）前記データオブジェクトの要求をユーザインタフェースから受信するステップ；
    ｅ）前記オブジェクト識別子を、前記データオブジェクトが記憶されている前記物理的メモリにマッピングするステップ；
    ｆ）前記データオブジェクトを呼び出すステップ；
    請求項２３記載のコンピュータ読み出し可能媒体。
26. 前記複数の指示は、コンピュータによる実行の際に、プロセッサが、前記データオブジェクトの呼び出しを容易にするため、データベースインデクスの作成を実行するような指示を含む、請求項２３記載のコンピュータ読み出し可能媒体。
27. 前記複数の指示は、コンピュータによる実行の際に、プロセッサが、前記データベースインデクスをＢツリーデータ構造の形態で作成するステップを実行するような指示を含む、請求項２６記載のコンピュータ読み出し可能媒体。
28. 前記複数の指示は、コンピュータによる実行の際に、プロセッサが以下のステップを実行するような指示を含む：
    ａ）前記少なくとも１つの記憶された手続きの実行を管理するステップ；
    ｂ）前記少なくとも１つの記憶された手続きの実行が終了した後、トランザクションの引き渡しを実行するステップ；
    ｃ）前記少なくとも１つの記憶された手続きの実行が終了しないままである場合、ロールバック・トランザクションを実行するステップ；
    ｄ）前記トランザクションの引き渡しと、ロールバック・トランザクションとを前記データベースマネージメントシステムのログに記録するステップ；
    ｅ）前記データオブジェクトの状態を、前記少なくとも１つの記憶された手続きの実行前に記録するステップ；
    ｆ）前記データオブジェクトの前記状態を、前記少なくとも１つの記憶された手続きの実行前であって、前記ロールバック・トランザクションの記録後に呼び出すステップ；
    請求項２３記載のコンピュータ読み出し可能媒体。

Images