多次元データ・モデル

表現豊かな多次元データ構造

Caché の超高速データベースは多次元データ・モデルを採用しています。この多次元データ・モデルは、複雑なデータ構造のデータをコンパクトに管理することができます。通常リレーショナル・データベースに必要な結合は、複雑で処理時間を浪費しますが、Caché では結合を実行しないでデータにアクセスし、更新することができます。

Caché のストレージ・モデルは “ハイパー・キューブ” あるいは “多次元空間モデル” と言われ、“グローバル” と呼ばれる非連続的な多次元配列構造を持つデータ構造体でデータが管理されます。データは、任意の添え字と共に、グローバルに保存できます。添え字には文字、数値、浮動小数などのデータ型という考え方はありません。つまり、同じ添え字レベルでも、1 つの 添え字が数値の 34 で、もう 1 つが “LineItems” などのような名称を取ることができます。

例えば在庫管理アプリケーションでは、商品名、サイズ、色、柄といった情報をもっていますが、それらは以下のような構造を持つことができます。

^Stock(item,size,color,pattern) = quantity

以下は、データのサンプルです。

^Stock(“slip dress”,4,”blue”,”floral”)=3

このようなデータ構造の場合、"サイズ 4 の花柄の青いスリップ・ドレス" の在庫の有無は、そのデータ・ノードにアクセスすることにより、簡単に確認できます。もし、顧客が "サイズ 4 のスリップ・ドレス (色と柄は未定)" を探している場合には、^Stock(“slip dress”,4) よりも詳細なデータ・ノードと通信し、該当する商品のリストを表示する事ができます。

この例では、すべてのデータ・ノードは同様の性質 (在庫数を格納) を持ち、同様の添え字 (3 番目の添え字が、常に商品の色を表すテキストである) を持つ同じ添え字レベル (4 つの添え字) で保存されます。しかし、必ずしもこの形をとる必要はありません。データ・ノードは、同じ数や同じタイプの添え字を持つ必要はなく、異なるタイプのデータを保存することも可能です。

下記は、送り状データを取り扱う複雑なデータの例です。これらのデータは、異なる添え字タイプで、異なる添え字レベル (階層) に保存されています。

^Invoice(invoice #,”Customer”) = Customer information
^Invoice(invoice #,”Date”) = Invoice date
^Invoice(invoice #,”Items”) = # of Items in the invoice
^Invoice(invoice #,”Items”,1,”PartNum”) = part number of 1st Item
^Invoice(invoice #,”Items”,1,”Quantity”) = quantity of 1st Item
^Invoice(invoice #,”Items”,1,”Price”) = price of 1st Item
^Invoice(invoice #,”Items”,2,”PartNum”) = part number of 2nd Item 

各ノードに対する複数のデータ要素

日付や数量といった項目の値は、それだけでデータ・ノードに格納されることがありますが、多くの場合データ・ノードには複数のデータ要素の値を取りまとめて格納すると便利です。特に、関連する一連のデータにまとめて、一緒にアクセスする場合に有用です。データ・アクセス回数を削減することにより、アプリケーションのパフォーマンスを向上させることができます。

例えば､上記の送り状データの例では、それぞれのデータ・ノードに区分情報、数量情報、価格情報を別々に格納していますが、下記のように 1 つのデータ・ノードに統合できます。

^Invoice(invoice #,”LineItems”,item #) = $LB(PartNum,Quantity,Price)

これを簡単に処理するために、Caché は list 関数をサポートしています。list 関数は、複数のデータを長さで区切られたバイト文字列にまとめます。このデータを取り出すときには、データ型に従ってデータを翻訳します。

多数の利用者がいる場合のトランザクション処理

トランザクション処理に最適な多次元データ・モデルを利用して、効率的にデータにアクセスすることができます。Caché プロセスは複数テーブルの結合に時間を浪費することなく、高速な処理を実現します。

論理ロックによる同時使用の強化

数千のユーザをサポートするシステムでは、競合するプロセス間の衝突の削減は、パフォーマンスの向上に不可欠です。大きな競合として、同じデータにアクセスしようとするトランザクション間で発生するものがあります。

Caché プロセスは、更新中にデータのページ全体をロックしません。トランザクションは、少量のデータに頻繁にアクセスして変更を加えるので、Caché はデータベースの更新処理において対象データの含まれるページ全体をロックするのではなく、必要最小限のデータに対して論理レベルのロックを実行します。データベースに対して小さな単位で更新、削除処理を実行することにより、ロックを実行しないで競合をさらに削減することができます。(このような制御は、カウンタで 1 ずつインクリメントしながら ID 番号を割り当てる処理や統計カウンタの変更などに特に有効です。ID 番号や統計カウンタは、データベース内で共通の “ホット・スポット” であり、この方法を採用しない場合、競合するトランザクション処理間で頻繁に衝突が発生します。)

Caché では各トランザクションは高速に処理されるため、一定時間内により多くのトランザクション処理を実行できます。

多次元データモデルは実用的なデータ定義を可能とする

多次元データ・モデルは、複雑なデータの保存や記述にも最適です。開発者は実際に取り扱うデータを忠実に表すデータ構造を作成できるため、迅速にアプリケーションを開発し、容易に管理できるようになりました。

スパース配列の可変長データ

Caché は完全可変長データをスパース配列の形で格納するので、必要な格納領域は一般的なリレーショナル・データベースの場合の半分程度にすぎません。ディスク容量が少なくて済むばかりでなく、コンパクトなデータ保存によって、一度の I/O 処理でより多くのデータの読み書きが可能となり、データがより効率良くキャッシュされるため、パフォーマンスが向上します。

宣言や定義は必要ありません

データベースにダイレクト・アクセスを行う場合やデータを保存する場合に、ストレージの宣言や定義、あるいは格納領域を割り当てる必要はありません。また、添え字の数やタイプ、データのタイプやサイズを指定する必要もありません。通常、多次元配列はデータや添え字によって、タイプを指定しません。グローバル・データは、単純に SET コマンドで、データとして挿入されます。

しかしデータベースのオブジェクト・アクセスや SQL アクセスを利用する場合には、データのディクショナリ情報が必要になります。オブジェクトや SQL に対するデータのディクショナリ情報を指定するには、専用のウィザードを利用して、そのデータに適した多次元データ構造を構築できます。独自の構造を定義することもできます。

ネームスペース

Caché では、データと ObjectScript コードは、CACHE.DAT という名前でディスク・ファイルに保存されています (1 つのディレクトリにつき 1 つのみ)。その各ファイルには、多数の “グローバル” (多次元配列) が含まれます。ファイル内では、各グローバル名は一意である必要がありますが、異なるファイルでは同じグローバル名を使用可能です。これらのファイルは、広い意味でデータベースと考えることができます。

データにアクセスするために、Caché の各プロセスは、使用する CACHE.DAT ファイルを指定するのではなく、"ネームスペース" を指定します。ネームスペースは、多次元グローバル配列やルーチン・コードがどの CACHE.DAT に格納されているかを指定するもので、データ・サーバの名称や格納されているディレクトリを指定します。もし CACHE.DAT が異なるドライブ、あるいは異なるコンピュータに移動された場合、ネームスペース・マップは変更されます。

通常ネームスペースは、特定のシステム情報を他のネームスペースと共有します。そして、CACHE.DAT に含まれるその他のデータは、そのネームスペース内でのみ使用します。しかし、これは柔軟性のある構造なので任意のマッピングが可能であり、ネームスペースを複数の CACHE.DAT のコンテンツにマップすることも珍しくありません。