データの保存に関する技術白書


Visual Basicのプログラムで情報を保存するにあたって、データベース、レジストリ、.INIファイル、または通常のファイルをいつどのように使いこなせばよいのか？ そしてOLE構造化ストレージとはいったい何なのか？ この2つの疑問に『The Visual Basic Programmer's Guide to the Win32 API』の著者が答える。

Daniel Appleman

Copyright (c) 1996 by Daniel Appleman. All Rights Reserved.
翻訳 文化オリエント株式会社

この記事は、完全な形で再録することを条件に、印刷物および電子メディアの両方において自由に再掲載、再配布することができます。実際、これは著者にとっても最初の電子出版の試みでもあり、条件が守られるかぎりどんどん再配布されることを著者は望んでいます。記事を再録する場合には、著作権の通知とStorageToolsの製品の情報のページを含む記事全体を必ず含めてください。この条件が満たされないもとでのこの記事の再録は、評論記事やレビュー記事における短い引用を除き、著者の事前の同意なしでは許可されません。なお、そのような引用にあたっては、出所を正しく明記することが条件となります。
著者へのコンタクトは、Compuserve：70303,2252またはインターネット：70303.2252@compuserve.comで可能です。

以下の技術白書は、筆者が1996年1月にSilicon Valley Visual Basic User's Groupで発表した内容に基礎を置いています。この白書の配布は、アプリケーションにデータストレージを実装するために利用可能なテクニックに関して、Visual Basicのプログラマーの皆さんを啓発するための努力の一環として行われています。この白書では、個々のアプリケーションでの必要性に応じて適切なデータストレージの技術を適合させることに焦点が置かれています。そして、それぞれのアプローチの利点および欠点も論じます。
この記事の終りには、Desaware社の製品を論じます。同社は筆者の勤務先でもありますが、読んでいただければ、この記事が（決して安易な広告文ではなく）ストレージ技術に関する客観的な、技術的な議論であることがわかります。そして同時に、ストレージ技術がすべてのVisual Basicプログラマーにとって価値あるものでることもご理解いただけるはずです。
この記事を読むことにより、次のような知識を得ることができます。

はじめに

「OLE構造化ストレージは近い将来に主流となるであろうもっともエキサイティングな技術の1つです。この技術はファイルを扱う方法を劇的に変えることになるでしょう。それは…。」
ちょっと待ってください。これはクールな技術を記述するときに使われる“決まり文句”ではありませんか？ そのような記事は、説明しているツールやテクニックの特長や機能に重きを置いた内容になっています。しかし、そのような情報はほとんどのプログラマが本当に必要とする情報でしょうか？
皆さんもおわかりのように、ほとんどのプログラマ（筆者も含みます）は技術と恋におちる傾向があります。私たちはクールな新しいツールやテクニックの噂を聞くと、それからしばらくは、それが、もっとも素晴らしいものだと思い、頭がいっぱいになります。筆者がコンピュータサイエンスを研究していたころには、ほとんど毎週のように新しい言語に出会っていました。そしてそのたびに、その新しい言語が、筆者の言語レパートリーの中の“最上”の言語になったことを記憶しています。判断基準は、ほかのどの言語よりも効果的に、そしてより迅速にすべてタスクを確実に実行することができるかどうかということでした。そして、次のものがやって来るまでの短い間のみ、それは“最上”の言語であり続けたのです。
このような経験というか性分は、多くのプログラマおよびエンジニアの中に共通して見られるものだと筆者は思います。私たちは技術について情熱的になります。私たちは自分の作業を愛する傾向があります。 言語、ツールおよびマシンに関する私たちの好みは、その強烈さにおいてほとんど宗教的ですらあります（実際、宗教よりプログラミングツールのほうに多くの情熱を注いでいるプログラマがいることは間違いありません）。
したがって、「OLE構造化ストレージ」という名前を付けられたこの“クールな新しいツール”を論じるにあたっては、その前に小休止を入れ、少し離れた場所から冷静に眺めてみることが大切であると考えます。
あらためて言うまでもありませんが、プログラマとしての私たちがやるべき仕事は、技術と恋におちることではありません。ソフトウェアを使って問題を解決することです。 そしてまたある意味では、目前の問題を解決するのにもっとも役立つであろうツールを正しく選択することも、私たちのプロとしての責任であるとも言えるでしょう。その時点でたまたま一世を風靡しているツールや、業界がやかましく売り込んでいるツールを安易に選ぶのではなくて……。
以上を踏まえたうえで、ここにOLE構造化ストレージについての真実を語りましょう――これは、ある種の問題を解決するために特化した非常に強力な技術であると同時に、それ以外の目的にはまったく適さない技術です。したがって、私たちが考えるべきは、「どのような問題がこの技術に適切であるのかをどのようにして判断すればよいのか？」ということです。 ここでは、身近で普遍的な問題について考えることから始めることにします。すなわち、データの保存の問題です。

データの保存

次のセッションで使用するために現在のセッションの情報を保存することができないワードプロセッサを想像してください。そのようなプログラムでは、印刷物が必要になるたびに、最初からドキュメントを作成しなければなりません――これでは、この数十年間にオフィスで行われてきたタイプライタを使った方法と何ら変わりがありません。コンピュータの価値の多くは元をただせば、情報を蓄積できるというアプリケーションの能力から生じています。つまり、データの保存です。データの保存には利用可能な多くの技術がありますが、その一方で、すべての技術がすべての状況に適切なわけではないのも事実です。
アプリケーションでデータを保存する場合には、主に以下に示すような3つの理由があり、そのうちの1つ以上またはすべてが任意のプログラムに対して適合します。

  1. アプリケーションの構成情報：多くのアプリケーションは次のセッションのために現在のセッションの状態に関する情報を保存します。こうしたアプリケーションは、最後に閉じられた直前と同じ状態に自分自身を戻すことができるように、それぞれのファイルのためにバックアップを作成するべきかどうかなどのユーザ設定、あるいはウィンドウの位置をなどを記憶することができます。アプリケーションによっては、一般的な構成情報に加えて特定ユーザーのための構成情報を保存するものもあります（複数のユーザーをサポートするアプリケーションの場合）。
  2. ドキュメント：多くのアプリケーションはドキュメントという単位で作業します。これは、セッションの初めには開かれ、セッションの終わりには保存されるか閉じられます。典型的なドキュメントには文書処理のドキュメント、スプレッドシート、画像などがあります。ドキュメントには多くのタイプのオブジェクトを含めることができます。ここで重要なのは、ドキュメントが一般的には1つのディスクファイルと一致するということです。このことにより、各ドキュメントをそれぞれ独立したユニットとして操作することが容易になっています。たとえば、ドキュメントをフロッピーディスクにコピーしたり、電子メールに添付して送ることができます。
  3. 記録：互いに共通項の多い複数のレコードについての記録を残す必要があるようなアプリケーションは、ある種のデータベースストレージのメカニズムを使用する典型的な例です。データベースであれば、検索操作やフィルタ操作をサポートするばかりか、複数のアプリケーションからこれを共有することも簡単に実現できます。

データを保存するにあたっての上記のそれぞれの理由は、ストレージに関する個別の問題についてどの技術が最良の選択であるのかを判断する材料となります。しかし、どの技術を選択すべきかは必ずしも明白ではありません。
この白書のこれ以降では、Windowsのもとで使われている主要なストレージ技術を概観し、上にリストアップされた問題に対しておのおのがどのくらい適切な解決策を提供するのかを見ていくことにしましょう。

専用の初期化ファイル（.INI）

初期化ファイル（.INI）はWindows 2.0にまで遡る古い技術です（Windows 1.0では唯一win.iniだけが使われ、アプリケーション専用の初期化ファイルはサポートされていませんでした）。最新のWindows関連の文書の中には、常に初期化ファイルの代わりにレジストリを使うことことを勧めているものもあるようですが、これは必ずしもすべての場合に当てはまる方策ではありません。アプリケーションによっては、初期化ファイルを使用したほうがレジストリを上回る多数の利点が得られます。たとえば、「メモ帳」のようなテキストエディタを使って簡単に編集することができることも利点の1つです。コピーされるか、簡単なファイルのコマンドを使って、簡単にコピーしたり保存することができます。また、少数の単純なAPIの機能やVisual Basicのコマンドを使って、とても簡単に扱うことができます。
初期化ファイルは、アプリケーションの構成情報を保存するのに適しているのでしょうか？ はい、もちろんです。多くの場合、プログラムの状態は比較的少数の短い文字列または数値のとして保管することができます。そして、このような種類の情報は、初期化ファイルがもっとも得意とするものです。ユーザーごとの構成情報を扱う場合には、それぞれのユーザーが初期化ファイルの中に各自のセクションを持つことになるため、骨の折れる作業になりますが、それでも十分実行可能な方法であることにはまちがいありません。
初期化ファイルはドキュメントを保存するのに適しているでようか？ いいえ、たぶん適していません。初期化ファイルの性能は、ほとんどのドキュメントに対して十分なものとは言えません。それぞれのエントリのサイズや、ファイル全体のサイズには制限があります（実際の制限は、オペレーティングシステムによって異なります）。 また、テキストのデータしか扱うことができないため、一般的な用途に使うには柔軟性に欠けています。
初期化ファイルはレコード情報を保存するのに適しているでしょうか？ 言うまでもなく、非常に限られた機能のアプリケーションの場合を除けば、適していません。

システムレジストリ

システムレジストリ（「レジストリデータベース」とも呼ぶ）は、システムの中心的役割を果たす階層的なストレージを提供します。レジストリは、Windows 3.xのもとではかなり限られた機能しかありませんでした。使用できるデータ型は制限されており、階層内のそれぞれノードにはたった1つ値しか格納できませんでした。これに対し、Windows 95およびWindows NTのもとでは、レジストリ内のそれぞれのキーにはいくつでも名前付きの値を関連づけることができ、さらにそれらの値には、生のバイナリのデータを含む幅広いデータ型の中から1つを選んで使用することもできます。それぞれの値の長さは、通常、最大2KBまで可能です。
レジストリはアプリケーションの構成情報の保存に適していますか？ はい、もちろん。レジストリは、構成情報を保存するために使用できる非常に洗練された構造を提供します。また、それぞれのユーザー専用のノードを追加するだけでユーザーごとの情報の保存も簡単に行うことができます。その一方で、レジストリは、エンドユーザーにとっては編集するのが難しいという特徴もあります（これは、アプリケーション次第で、長所にも短所にもなり得ます）。レジストリを編集する作業には、「ユーザーがシステムの正確な動作を妨げるような変更を誤って行いかねない」という危険が常につきまといます。なぜなら、レジストリには、アプリケーション専用の初期化ファイルとは異なり、システム自身のための構成情報も含まれているからです。レジストリへアクセスするにはより洗練されたAPIのコマンドを使用する必要があるため、専用の初期化ファイルの場合に比べてプログラムが複雑になります（Visual Basicには、基本的なレジストリの作業に対して利用可能な単純なコマンドセットが用意されてはいますが）。
レジストリはドキュメントの保存に適していますか? 言うまでもなく、適していません。レジストリのそれぞれ独立した部分を管理するためのスマートなメカニズムは用意されていません――いったい、どのようにしてレジストリの一部をディスクのファイルにコピーしたり、電子メールに添付して送るというのでしょうか？ レジストリは、その本来の性質上、ドキュメント指向ではありません。また、レジストリ内の各値はなるべく小さくすることが強く推奨されています。
レジストリはレコード情報を保存するのに適していますか？ いいえ、まったく適していません。ドキュメントについて述べたすべての理由がここでも当てはまります。

独立したドキュメント

アプリケーションがデータの保存を行う際に使われるもっとも一般的な方法は、ディスクの上のドキュメントファイルに必要な情報を保管することです。ディスク上のファイルには多数の標準的な形式があります。たとえば、BMPファイル（Windowsビットマップ形式）はビットマップイメージのための標準的なファイルの形式です。RTF（リッチテキスト形式）は書式付きのテキストのための標準的なドキュメント形式です。多くの場合、アプリケーションは独自のファイル形式を定義します。実際、現在標準となっている形式の多くも、元をたどればあるアプリケーションの独自のファイル形式です。独自のまたは標準的なファイル形式が任意のアプリケーションのために適切であるかどうかは、設計時に開発者が決定しなければならない選択の1つです。
ドキュメントファイルの場合、ファイルの内容にはアプリケーションが全責任を持たなければなりません。また、すべてのファイル操作についても同様にアプリケーションが行う必要があります。アプリケーションにファイル操作を実装するには、APIコマンドを使うか、行、レコード、またはバイナリデータを扱うことを可能にするVisual Basicの多種多様なコマンドを使います。
ドキュメントファイルはアプリケーションの構成情報を保存するにのに適していますか？ はい。結論から言うと、専用の初期化ファイルも、ディスクの上のドキュメントそのものですから。しかし、ドキュメントファイルがこの目的に使われることはめったにありません。構成情報が単純なものなら、初期化ファイルを使うほうが簡単です。構成情報が複雑な場合や、テキストでは簡単に表すことができないデータを保存する必要がある場合には、システムレジストリを使うほうが簡単です。
ドキュメントファイルはディスク上で簡単に管理することができます。コピーや移動をしたり、電子メールに添付して送ったり、標準的なファイル管理ソフトウェアを使って操作することができます。ドキュメントを読み書きするタスクは、ごく単純なものから極端に複雑なものまで、ドキュメントのタイプによってさまざまです。簡単なテキストのドキュメントファイルなら、テキストの各行をCR、LFの組み合わせによって区切りながら単に“print”することによって作成できます。しかし、行をファイルの中間に挿入したり、ファイルから削除したい場合には、一般にはファイル全体を書き込み直す必要があります。ディスクファイルの情報の一部を後方にシフトするための簡単な方法はありません。
ドキュメントに多くの異なる種類の情報を保存したい場合の方策は？ たとえば、テキストと画像の両方を含むようなワープロのドキュメントファイルはどのようにして作成すればよいのでしょうか？ このような場合には、ディスクファイル内で個々のオブジェクトがどこに位置しているのかを追跡するために、より複雑なファイル形式を定義する必要が必要があります。つまり、ファイルを構成するさまざまな部品をリストアップし、それらの位置を追跡するために、ディスクのファイルの内部にディレクトリ構造を定義しなければなりません。実際問題として、場合によっては、データベースシステムによって使われるファイル構造に見られるような複雑さが必要になることもあります（データベースシステムとは、サイズが不定の多数のオブジェクトをディスクファイル内に追跡可能な状態で保存したものと言えます）。
ここから私たちはレコードの話題へと移っていくことになります。ドキュメントは、互いに共通項の多いデータの複数のレコードを保管するのに適していますか？ この時点での答は「イエス」でもあり「ノー」でもあります。いま、内部的にデータを保管するためにユーザー定義型のデータ型を使うアプリケーションがあり、これらの構造体の配列を保存する必要があるとします。この場合には、ドキュメントファイルが、この情報を保管するための非常に効果的な方法になりえます。 Visual Basicには、高速でオーバーヘッドの少ない、レコードのI/Oファイル操作が含まれています。
しかしながら、レコードの保管にドキュメントを使う方法には、多くの問題が潜在しています。たとえば、個々のレコードの挿入と削除の操作が複雑になる可能性があります。次に、構造の形式が変わってしまう可能性があれば、結局はアプリケーション側にドキュメントのバージョンの記録を残したり、あるバージョンから次のバージョンへとドキュメントを更新するための方法を実装する必要が生じます。また、可変長のレコードを使用する場合には、それぞれのレコードの開始と終了の位置を検索するための何らかのメカニズムを含む、より複雑なストレージ技術が必要となります。さらに、検索操作やフィルタ操作の手法はすべてアプリケーション側で独自に実装する必要があります。

レコード

複数のレコードを保存することが必要な場合、それぞれのレコードの構造はお互いに似通っていることがほとんどです。このような場合には、すべてのレコードが同一のフィールドを含む表形式がしばしば使われます。また、同一のファイルの中で異なる種類のレコードを扱う必要があることもありますが、その場合には複数の表を用いることになります。多くの場合に必要となるのは、複数のユーザーまたは複数のアプリケーションから同時にアクセスすることが可能な情報でしょう。これは、明らかに、データベースのシステムを使うときしばしば保管される種類の情報です。これは、この目的に特化したデータベースのコマンドセットやデータベースのコントロール、およびVisual Basicに組み込まれているコマンドを使うことで実現できます。
皆さんは、以上の議論をデータベースについて話すにはいくぶん手が込みすぎている方法であるとお考えになるかもしれません。「“レコードの保存”と“データベースの構築”をこのように差別化するために、なぜこれほどの手間をかける必要があるのか?」と。それは、ゴール（最終目的）とソリューション（解決方法）を区別することが重要だからです。ゴールはある型のデータ、つまり、共通項を持つ複数のレコードを保存することです。そして、そのための1つのソリューションがデータベースなのです。しかし、ソリューションは1つとはかぎりません。
すでに、ドキュメントファイルの中にレコードを保管することが可能だということは説明しました。しかしながら、データベースがレコードストレージとして設計されていることが明確であるなら、いったいドキュメントファイルにレコードを保管する必要はあるのでしょうか？ 答えは「イエス」です。実際、データベースの検索機能やフィルタ機能を必要としない場合や、ファイルを共有する必要がまったく（または、ほとんど）ない場合、あるいは、レコードが単純で長さが固定されているような場合には、そのほうが簡単なのです。このような場合には、ドキュメントを使う方法のほうがプログラムが簡単になるということのほかにも、ほとんどの場合アプリケーションの動作が高速になったり、データベースエンジンを実装することによるオーバーヘッドを避けることができるという利点があります。
アプリケーションの構成情報について考えれば、このことは容易に理解できます。データベースの機能は、この種のデータを保存するために使うには、あまりに強力すぎます。ユーザーごとのアプリケーションの構成情報のためのストレージとして使う場合でさえ、ほかのテクニックを使ったほうが、簡単に目的を達成できます。
ドキュメントについてはどうでしょう？ たとえば、ワープロのドキュメントの情報を保管するためにデータベースを使うのは適切なことでしょうか？ もちろん、それは可能なことです。私たちは、ある表にはドキュメントの文字列（およびフォーマット情報）が格納され、またある別の表には、異なる種類のオブジェクト――おそらく、イメージ、ビデオ、サウンドなど――が格納されているような複雑なデータベース構造を、容易に想像することができます。これらの表は、データベースのリレーショナル機能を介して連結することも可能です。
このアプローチはたしかに機能はします。しかし、複雑になりすぎます。適切な形式のドキュメントを実装し、自分でディスク操作を行うのと同じぐらい複雑です。データベースを使うと、アプリケーションのパフォーマンスに大きな影響を与え、重大なオーバーヘッドを引き起こします。

技術のすき間

すべてのプログラマはデータの保存の問題を取り扱わなければなりませんが、一般に、個々のソフトウェアプロジェクトが要請する特有の問題について十分な検討を加えることなく、ソリューションへとまっすぐに突き進む傾向があります。すでに見たように、通常、アプリケーションの構成情報は専用の初期化ファイルまたはシステムレジストリのどちらかを使うのがもっとも良い方法であることはまちがいありません。レコードストレージはデータベースで取り扱うのが最良です。簡単なドキュメントなら、直接にディスクのファイルを読み書きするのが最良です。しかしこれと同時に、これらの保存に関するどのタスクについても上記の4つの技術を適用できるということ、そして、自明と思われる選択が必ずしも最良ではないということもすでに説明したとおりです。
そして、これらの技術のどれ1つとしてふさわしくない保存の問題が1つ残されている、ということもこれまでの議論から明かです――異なるタイプの情報を含んでいる複雑なドキュメントを保存するには、いったいどのような方法をとるのが最良なのでしょうか？ 複雑なファイル形式をアプリケーションに実装するのは非常に手間のかかる作業です。また、データベースはお互いに共通項を持つレコードの記録のために設計されたものです。これを使って、長さや種類が不定の情報を保存することができる例も少なくありませんが、さらに膨大な作業が必要になることが予想されます。
ごく最近まで、この問題に対してVisual Basicのプログラマが利用できる明確なソリューションはありませんでした。
さて、このような観点からOLE構造化ストレージを見るまえに、少し休憩がてら、複雑なドキュメントのファイルを処理することができる理想的なストレージシステムとはどのような特性を持つべきかという点について考えてみましょう。なお、ここから少しの間は、「オブジェクト」という言葉は、実際には個々に定義しなければならないあらゆるデータのブロックのことを指すものとします。

自力でこのようなシステムを実装する複雑さは、想像を絶します。それゆえ、専用のファイル形式を作成するのではなく、何か代わりとなる方法を探したくなります。ところで、このような議論はどこかで聞いたことがあると思いませんか――そうです。これらの条件に適合するストレージシステムは、すべてのWindowsおよびDOSベースのシステムにすでに具現化されています。
それは「ファイルシステム」です。
オブジェクトとしてのファイルについて少し考えてみましょう。ファイルシステムは何千ものオブジェクトを扱うことができます。それぞれのファイルのサイズは0バイトからギガバイトまであらゆる大きさがカバーされます。言うまでもなく、1つのファイルが別のファイルに干渉することを心配せずに、作成したり除去することができます。そして、あるファイルへの書き込みが、ほかのファイルを破損することもありません。ファイルには名前を付け、ディレクトリの階層構造に体系化することができます。
実際、ファイルシステムを使い、ドキュメントを複数のディスクのファイルに分けることによって複雑なドキュメントのストレージ問題を解決するいくつかのアプリケーションが市場には出回っています。たとえば、筆者が最近試したCorel Ventura Publisherでは、異なる種類のドキュメントへのリンクを包む複数の章から1つの出版物を構成することができます。通常、1つの出版物は数百のファイルによって構成され、それらは1つ以上のディレクトリに体系化されます。
このアプローチの欠点は、別のディレクトリまたはフロッピディスクに対してドキュメントをコピーしようとしたとき、あるいは、電子メールに添付して送信しようとしたときに明らかになります。 出版物をコピーするには、すべてのリンクされたファイルを捜しだし、それらを正確な場所にコピーすることができる特別なユーティリティが必要となります。たった1つのファイルでも欠落してしまうと、最悪の場合は出版物全体がロードできなくなったり、良くても不完全な情報しか揃わないことになります。
ここに、OLE構造化ストレージの存在意義があります。

OLE構造化ストレージ

Windowsの開発者（Visual Basicまたはほかの言語を使うかどうかに関わらず）であり続けるために必要な努力の大部分は、Redmondから絶えず送り出されるおびただしい数の新しい約定と頭文字に対処し続けることであるように思われます。OLE構造化ストレージも、そのようなものの1つです。
幸運にも、ここでは、これまでお読みいただいた少々長めの前置きに述べられている内容が役に立ちます。その内容を読んだ皆さんは、OLE構造化ストレージとはいったい何であるのか、なぜ存在するのか、そして、各自の開発計画にどのように適合するのか、などについて正確に理解しているはずです。
ここで少しの間、ファイルシステムについてもう一度考えてみましょう。その利点および欠点の両方について、そして、複雑なドキュメントを作成するという問題をどのように解決する可能性があったかについて。それから、ファイルシステムはハードディスクドライブに存在する――つまり、情報を保管するために非常に大きな領域を利用することができる――という点についても。そしてさらに考えてみてください。本当のファイルシステムの代わりに、1つのディスクファイル内にファイルシステム全体を作成できるとしたら、いったい何が起こるでしょうか。
突然にあなたは、何の不利益もともなわずに、ファイルシステムのすべての利点を手にすることができます。ファイルシステム全体が1つのディスクファイルの中に収められているので、そのファイルをコピー、移動、送信するだけで、中に含まれるすべてのオブジェクトをコピー、移動、送信することができるのです。
OLE構造化ストレージは、1つのディスクファイル内にファイルシステム全体を作成する技術です。それ以下でも、それ以上のものでもありません。そしてこれこそがOLE構造化ストレージであると理解するとき、皆さんはどんな専門家にも劣らず、OLE構造化ストレージについて知っていることになります。

用語について

ファイルシステムには、ディレクトリおよびファイルが含まれます。 それぞれのディレクトリは、最上位のルートディレクトリに含まれています。 また、それぞれのディレクトリは、複数のサブディレクトリおよび任意の数のファイルを含むことができます。
OLE構造化ストレージにおいては、「ストレージ」という語を「ディレクトリ」という語の代わりに、「ストリーム」を「ファイル」の代わりにそれぞれ用います。OLE構造化ストレージのファイルで作業するときには、最上位のストレージ（ルートのストレージ）から始めます。このストレージには、サブストレージおよびストリームを含めることができます。ストリームはファイルとまったく同じように、作成、オープン、クローズすることができます。ほかのストリームへのいかなる影響も心配することなく、任意のストリームに書き込むことができます。OLE構造化ストレージは、ストリームおよびストレージへのスペースの割り当てを行い、ディスクファイル内でのスペースの割り当てを管理します。
OLE構造化ストレージでは、この技術で管理されるディスクファイルに対しても特別な名前を定義します。このようなファイルのことを「複合ドキュメント」と呼びます。

なぜ構造化ストレージがOLEの一部なのか？

「構造化ストレージ」という用語は、これだけで正確にこの複合ドキュメント技術が提供するものを表現しています。それではなぜ、これがMicrosoftの規格であるOLE――オブジェクトのリンクと埋め込み――の一部である必要があるのでしょうか？
これは部分的には、「OLEが実際には、技術のコレクション――Windowsにおける新しい開発の多くがつめ込まれている福袋――である」という事実に由来します。しかしこれと同時に、構造ストレージ技術は、OLEの主要な目的――ユーザーがアプリケーション中心ではなくドキュメント中心で作業できる環境を実現すること――と関係しているということも、その理由の1つです。
WordのドキュメントにExcelのスプレッドシートを埋め込んだときのことを思い浮かべてみてください。ドキュメントに表示されているスプレッドシートの部分をクリックすると、ExcelのユーザのインターフェースがWord内に現れます。いわゆる「インプレース編集」と呼ばれるこの機能では、ドキュメントそのものは、あくまでWordのドキュメントであるのに、どういうわけかWordはWordのファイルに埋め込まれているExcelのスプレッドシートのオブジェクトを保存したり操作したりする能力を得ます。いったい何が起こっているのでしょう？
実際にはWordは、Excelのスプレッドシートにどんなデータが含まれているのか、あるいは、どのようにそれを扱えばよいのかについて何も知りません。実際に起きているのは、Wordのファイルが複合ドキュメント化されているということです。Wordのドキュメント内のストレージの1つが、Wordにとっての外部オブジェクト――いまの例ではExcelのスプレッドシート――を格納する場所として機能しているのです。それぞれのオブジェクトはそれ専用のストリームに格納されます。Wordドキュメントを保存するとき、Wordはどのようにしてスプレッドシートのオブジェクトを保管するのかを知りませんが、その必要はありません。ストリームへのハンドルをExcelに渡すだけでよいからです。Excelはそのストリームにスプレッドシートのデータを保存します。
ドキュメントを再びロードするときには、Wordはオブジェクトプールの中のオブジェクトを参照します。それぞれのストリームは、ユニバーサル識別子の「GUID」で始まっています。Wordはその識別子を参照し、OLEのライブラリを呼び出して、ストリーム情報に基づいたオブジェクトを作成します。OLEはシステムレジストリ内を参照して、それがExcelのスプレッドシートオブジェクトであることを理解します。そして、オブジェクトを表示し、ユーザーがそれを編集するために必要なExcelの部品をロードします。
おわかりのように、OLE構造化ストレージは、「アプリケーションがオブジェクトの内部形式を知らなくても、そのオブジェクトを保管することができる」という重要な要請に応えます。OLE構造化ストレージの側では単に、そのオブジェクトをどのように扱えばよいのか知っているサーバーにストリームのハンドルを渡すだけでよいのです。そしてVisual Basicでも、OLEのコンテナのコントロールを用いれば、これと同一のテクニックを使って、プログラマが独自に作成した複合ドキュメントのファイル内に外部オブジェクトを保管することができるうになります。
複合ドキュメントブラウザで少し覗いてみれば、Microsoft Officeに含まれるの大部分のアプリケーションを含む多くのMicrosoft社のアプリケーションで、OLE構造化ストレージが使われていることがわかります。

複合ドキュメントを使うべきか、それともデータベースを使うべきか？

筆者は、これまで何度となくこの質問を受けてきました。そして実際、この記事を書いた大きな目的は、この疑問を「追い払う」ことです。ここで筆者が疑問に「答える」のではなく、「追い払う」と述べたことに注目してください。これは、個々のアプリケーションのデザインに密接に結びついている問題であるため、ひと言で「答える」ことはでません。
作成しようとするアプリケーションが、互いに似たレコードを保持するグループ（=表）を複数保管する予定であり、洗練された検索機能とフィルタ機能を使用したり、異なるグループ（=表）間でレコードのリレーションを定義する必要がある場合には、おそらくデータベースが必要になるでしょう。
一方、サイズや形式が不定のデータや、ほかのアプリケーションのオブジェクトを含むような独自のドキュメント形式を作成したいなら、構造化ストレージがよりよい選択でありえます。
いずれにしても、問題はまず作成しようとする個々のアプリケーションに必要な機能を明らかにすることです。。必要な仕様さえ定義してしまえば、どの技術を使えばよいかの答えは、ほとんどの場合、明白です。

独自の情報 vs 公共の情報

複合ドキュメントにどのようなストリームを含めるのかは、アプリケーションまたはドキュメントに保管するオブジェクトによって完全に定義されますが、ドキュメント内のストリームおよびストレージの管理はOLEが受け持ちます。これは、複合ドキュメントの構造や内容は、いかなるアプリケーションからも参照することができるということを意味します。ちょうど、ディスクファイルの場合もあらゆるアプリケーションからオープンしたり、読み込むことができるのと同じことです。
複合ドキュメントのファイルのこのような特長がもたらす恩恵の1つは、1つのファイルの中に独自のデータと公共のデータを混在させることができるという点です。たとえば、あるストリームにすべてのアプリケーションから読むことができる任意の名前を付けたり、説明的なテキストを含めることができます。
実際、Microsoft社は、標準的なプロパティのための形式として「Summary Information」フィールドという名前のストリームを定義しています。このストリームは、ドキュメント名（Title）、作成者名（Author）、コメント（Comments）などのような標準的なサマリー情報を含みます。すべてのアプリケーションがこのサマリー情報を読むことができます。独自に作成するドキュメントにこのストリームを含めることもできますし、ほかのドキュメントについての情報を得るためにこの情報を使うこともできます。

自己保存（Self Persisting）クラス

これまでの説明で、OLE構造化ストレージを使った場合に、それぞれのアプリケーションがどのようにして1つのドキュメント内で独自のオブジェクトを管理できるのかおわかりいただけたと思います。さらに、自己保存クラスを作成することによって、独自に作成するアプリケーション内でも同一のテクニックを使うことができます。
いま、多数の異なるクラスを含むアプリケーションを作成し、それぞれのクラスのオブジェクトのコレクションを保存したいとします。ここで利用可能な1つのテクニックは、すべてのオブジェクトを保存し、ロードするためにハイレベルなルーチンを作成することです。このアプローチの欠点は、クラスに変更を加えるたびにハイレベルのルーチンもあわせて変更する必要があるということです。この作業には、新しいクラスを作成する作業や、データを保存するときにクラスが使う形式を変えてやる作業が含まれます。この種の中央集中管理のアプローチが必要になるのは、独自のファイル形式を作成し、自分で管理する場合がほとんどです。
OLE構造化ストレージを用いると、もっと扱いやすいアプローチが可能になります。このアプローチでは、ストリームとデータをやりとりする方法をそれぞれのクラス単位で管理します。この場合、すべてのハイレベルのルーチンは、それぞれのクラスのそれぞれのインスタンスについて、「Save」や「Load」のメソッドを読み出すだけで実行できます。クラスがそのデータ形式を変える必要があるときも、（古い形式をロードすることができさえすれば）自由に変更することができます。 ハイレベルの保存ルーチンを変更する必要はまったくありません。
自己保存クラスを使うことにより、長期的な意味でのアプリケーションの信頼性を向上することができます。つまり、1つのクラスの保存操作が、アプリケーションのほかのクラスによって利用される保存操作に干渉する可能性がより低くなります。それぞれのクラスのコードやデータ形式が変更された場合でも、この利点は失われません。

OLE構造化ストレージのその他の機能

複合ドキュメントはファイルの共有機能をサポートします。それぞれのストレージでは、ディスクファイルが共有をサポートするのとまったく同じ方法で、排他アクセスまたは共有アクセスによりファイルをオープンすることができます。
OLE構造化ストレージはまたトランザクション機能をサポートします。ストレージをトランザクションモードで開くことができます。ストレージの内容を変更したあとで、それらの変化をコミットするかオリジナルの内容に戻すかを選択することができます。これは作業結果を元に戻すための「アンドゥ操作」のような機能を実装するのに理想的な機能です。

OLE構造化ストレージとVisual Basic

Visual BasicからOLE構造化ストレージの技術を使うにあたっては、難題が1つ存在します。それはVisual Basicがこの技術をサポートしていないということです。OLE構造化ストレージはAPIの呼び出しではなく、OLEのインターフェイスを使うように実装されていますが、このシステムをVBはサポートしないのです。
しかし、幸運にも、Desaware社の「StorageTools」というパッケージを使うことで、Visual BasicからOLE構造化ストレージのすべての機能にアクセスすることができるようになります。このパッケージには、構造化ストレージのサポートに加え、システムレジストリへの簡単なアクセスをサポートする16および32ビットのOLEコントロールが含まれています。
「StorageTools」とその機能についてのより詳しい説明が次のページにあります。

詳しい情報の問合わせ先：
Desaware Incorporated
I 100 East Hamilton Ave, Suite 4
Campbell, CA 95008
Tel：（408） 377-4770
Fax：(408) 371-3530.
Compuserve：74431,3534またはInternet：74431.3534@compuserve.com

Desaware社 製品紹介

100 East Hamilton、Suite 4、Campbell、CA、95008
Tel（408）377-4770 FAX：（408）371-3530

StorageToolS TM Version 1.0

究極のデータストレージおよびファイル操作を実現するツールキット！

ファイルとデータのプログラミングが変わる！

OLE2.0について多くの方がご存じなのは、アプリケーションを制御し、1つのアプリケーションからほかのアプリケーションへとオブジェクトを埋め込むという機能でしょう。しかし、OLE 2.0にはVisual Basicのプログラマが以前には利用できなかったもう1つの機能が組み込まれていることはあまり知られていません。それは「構造化ストレージ」と呼ばれる機能であり、StorageToolsはこの強力な技術への扉を開く鍵となるツールです。
「構造化ストレージ」とは、情報をより簡単に体系化できるようなファイルを作成するための技術です。データブロックを、ファイルがディレクトリに置かれるのとまったく同じような階層的な形式で配置することができます。それはちょうど、それぞれのファイルの中にファイルシステム全体が含まれているようなものです。これにより、複合ドキュメント――ドキュメントのストレージに関しての新しい標準――を作成して、活用することが可能になります。
ファイル内でのスペースの割り当てや解放といった処理はOLE 2.0が行うので、プログラマはディスクの上のファイルの物理的な配置にかかわる必要がありません。ファイルの中のデータの現実の位置にとらわれることなくプログラムすることができます。さらに、トランザクション機能もサポートされているため、アプリケーションにアンドゥ操作や作業状態をインクリメンタルに保存する機能を容易に実装できます。
StorageToolsでは、Microsoft社のアプリケーションで使われているのと同一のファイルストレージシステムを利用することができます。OLE 2.0ベースのあらゆるファイルの構造をテストするサンプルプログラム（ソース付き）が含まれているので、それがどのように機能するのかを正確に知ることができます。

StorageToolsのStorageコントロール：

Storageコントロールでは、ストレージおよびストリームを表現するのにVisual Basic OLEオブジェクトが使われています。おなじみのインターフェイスを作成し、GetやPutのようなおなじみのコマンドを使ってそれらの要素を操作することができます。また、構造化ストレージの規格には、ファイルを操作するプロシージャを簡単にアップグレードすることができる多くの機能が用意されています。たとえば、ファイルが構造化ストレージ形式であるかどうかを調べたり、普通のファイルを構造化ストレージのファイルとして読み込むことができます。StorageコントロールはまたVisual Basicのプログラマのための特別な機能を数多く備えています。「シーケンシャル」、「バイナリ」、「ランダム」など、Visual Basicで使用される情報スタイルのすべてを読み書きすることができます。配列にも対応しています。

StorageToolsは、以下に示すような構造化ストレージのさまざま機能を利用するための鍵となるツールです。

StorageToolSのRegistryコントロール

Registryコントロールは、レジストリおよびレジストリデータベースへのアクセスを容易にします。Windows APIの呼び出しはもとより、それ以上の操作を可能にする機能が用意されています。レジストリの「キー」に対してディレクトリのようにアクセスすることができます。「値」は、Visual Basicと互換性があるデータ型にコンバートされます。強力な検索機能も用意されているので、キーおよび値の名前に対する検索はもちろん、値のデータに対する検索も可能です。また本製品のマニュアルには、レジストリの各領域に関する役立つ情報や、それらへのアクセス方法の解説などが含まれています。
StorageToolsを使えば、レジストリは独自に作成したVisual Basicのプログラムを真にプロフェッショナルなアプリケーションに変えるための鍵となります。StorageToolsを使うと、次のようなことができます。

StorageToolsのパッケージには16および32ビットのOLEコントロール、マニュアル、そしてサンプルコードが含まれています。これで、たった$129です。
Desaware社は、プログラミングの世界の現実の問題を解消する製品を提供することに誇りを持っています。Desaware社はソフトウェア開発の限界を世に知らしめるとともに、それを打破する高度なツール群を開発し続けています。Desaware社がこれまで開発した製品には、『SpyWorks』、『VersionStamper』、『StorageTools』、『Custom Control Factory』、『CCF Cursors』、『The Common Dialog Toolkit』などがあります。 以上の製品は、32ビットのOLEコントロールおよび新しいオペレーティングシステムへの移行に際して、この新しい技術に真っ向から取り組むわが社の姿勢を反映するものです。

さらに詳しい情報のお問い合わせは…
Desaware Incorporated
1100 East Hamilton Ave, Suite 4
Campbell, CA 95008
Tel (408) 377-4770
Fax：(408) 371-3530
Compuserve：74431,3534またはInternet：74431.3534@compuserve.com

最後に…

この記事はおよそ5000語の長さです（製品紹介のページを除く英語原文）。通常なら筆者はこのような記事を主要な雑誌に有償で提供しています。今回は、この記事を使って、直販のための機能紹介記事を書くことが有益となるレベルにまで電子メディアが十分に普及したのかどうかを調べるための実験を行っています。筆者が期待しているのは、それなりの人数の方々がこの記事を読み、それなりの方が興味を抱き、続く製品紹介を読んでくださることです。さらにその結果として、伝統的なチャンネルを介して記事を売らないことにより被る損失を相殺するに十分な販売実績が上がることです。

このアプローチに関してご意見がありましたら何なりとお聞かせください。

Daniel Appleman

Strage Tools の日本語版(文化オリエント株式会社発売)は PCDNの 優待販売でお買い求めいただけます。


オンラインマガジン
int21 ホームページ | PCDN ホームページ


For questions or comments, please send mail to: pcdn@int21.co.jp