 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
OnDemand: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
はじめに 「もう、ユーザー・フレンドリーでパフォーマンスに優れたOnDemandソリューションを設計できるようになったかね？」という上司の問いに対して、皆さんはどのように答えることができるでしょうか。 この記事は、こうした問いに対して皆さんが前向きに、しかも自信を持って答えられるよう、お手伝いするものです。ここでは、OnDemandソリューションを正しく設計するためのすべての方法を述べることはできませんが、ソリューションの作成におけるポイントをいくつか挙げることにしましょう。 OnDemandに初めて接する人のほとんどは、OnDemandによって、文書の保管、および、PCやWebブラウザーによるそれらの文書の検索ができるようになるということは理解しています。また、そのような人たちの多くは、個々のコンポーネントの基本機能について理解し、また、文書を保管するアプリケーションを作成することができます。しかし、OnDemandにあまり慣れていない人々も多く、OnDemandをしばらく使用していても、そのユーザー・フレンドリーな点や優れたパフォーマンスを十分に発揮できるような使い方をしていない場合もあります。そのような場合、エンド・ユーザーもそのような状況に慣れてしまい、ソリューションの向上/改善を提案しなくなってしまっています。
OnDemandとは? OnDemandによって、エンド・ユーザーは最小の時間、最小のやりとりによって、特定の文書を記憶域から検索することができるようになります。パフォーマンスに優れたユーザー・フレンドリーなソリューションを作るためには、まず、データがどのように使われるのか、それを少し見てみることが必要でしょう。 きわめて簡単に言えば、OnDemandとは、手で記入するカード・カタログ（引出しに入った）を使っていた頃の「図書館」の「電子版」といえるでしょう。図書館とOnDemandを対比させると次のようになります。
図書館では、「特定の書籍」の「特定の章」を調べたい場合、カード・カタログ・キャビネットで特定のカード・カタログの引出しを開け、特定のカード（書籍の場所を示している）を見つけ、書籍を取りに行き、それから調べたいページを開きます。 OnDemandのPCまたはWebビューアーでは、特定のデータベース表に接続されているフォルダーを選択し、次に検索基準を入力します。それからEnterキーを押すと、文書のヒット・リスト（データベース表の特定の行のコピー）が表示されます。このリストで1つの行を選択すると、その文書を取り出すことができます。 最大限のパフォーマンスと最大限の使いやすさ 同様のことがOnDemandの場合にもいえます。検索基準が複数のアプリケーション・グループ表にまたがっていれば、照会にはより長い時間を要します。これは、1つの照会に対してシステムがより多くの作業を行い、エンド・ユーザーがより長い時間待たなければならないということです。 OnDemandソリューションの設計者が行うべきことは、複数のアプリケーション・グループ表にまたがる検索を行わないようにアプリケーションを設計するための最もよい方法を見つけ出すことです。複数のアプリケーション・グループ表は、同じアプリケーション・グループから発生することも、また複数のアプリケーション・グループから発生することもあります。 アプリケーションの設計にあたっては、設計上最も重要な意味を持つ「OnDemandアプリケーションの4つの要素」を理解しておくことが必要です。
OnDemandソリューションに関する要素には、さらに多くのものがありますが、OnDemandソリューションの設計の成功に最も大きく影響するのは、この4つです。 1つのレポート・タイプに対してのみOnDemandが使用される場合には、優れた設計も容易に可能です。しかし、ほとんどの場合、OnDemandソリューションは常に数千のユーザー、数百のデータ・タイプの検索を対象としているため、パフォーマンスと使いやすさに優れた設計のためには、3段階のアプローチが必要となります。
ステップ1：データの検索方法を判断する ユーザーがフォルダーを開いた時点で、データベースの照会はすでに開始されています。フォルダーを選択することによって、検索対象とするアプリケーション・グループ表の数が制限されます。この点については、ステップ3で説明します。 フォルダーは、エンド・ユーザーがデータベース表を照会する際のインターフェースを提供します。フォルダーのフィールドはアプリケーション・グループのフィールドに対応し、これがデータベースの索引とフィルター・フィールドに対応しています。セグメント・フィールドによって、検索対象の表を絞り込むことができます。フォルダーにサーバーベースのテキスト検索フィールドを置くこともできますが、他の照会フィールドを突き合わせた後に一致する文書において一致する単語/句を検索するため、データ検索に最も時間のかかる方法です。OnDemandのユーザーには、照会フィールドによる検索で十分な効率が提供されるため、テキスト検索フィールドの使用はあえて避けるべきでしょう。 照会の要求の後に行われること（ハイレベル・ビュー）は、以下のようなことです。 1. セグメント・フィールドの照会であれば、これを使用してその基準を満たす表のみを選択する。 2. 索引フィールドの照会であれば、セグメント検索により選択された表の索引を検索して、一致する表の行を選択する。 3. フィルター・フィールドが選択された場合は、選択されている行を、一致するフィルター・フィールドを持つ行のみに絞り込む。 4. 一致する行をヒット・リストとしてエンド・ユーザーに返す。 すべてのフィールドを索引フィールドにしたくもなりますが、それに伴うトレードオフの関係を理解しておく必要があります。索引を作成する場合、データベース表に保管されている情報を取り出し、その情報を再び別の表に追加するためにデータベース・スペースを使い、しかも索引の作成にかかわる余分なスペースも使うことになります。表フィールドがすべて索引であれば、何のメリットも得られないままデータベースはただ巨大化することになります。 あまりにたくさんのフィールド、索引、フィルターを作ることも、よい方法とはいえません。アプリケーション・グループに作成される表ごとのそれぞれのデータベース列には、データベース内の追加スペースが必要です。必要となるのは、検索対象に対するフィールド（データベース列）の作成のみであり、最低1つの索引フィールドが必要です。このフィールドは、通常、エンド・ユーザーが検索を行うフィールドであり、Customer Number（顧客番号）、Social Security Number（社会保障番号）、Phone Number（電話番号）など、一意の値であることが必要です。 これこそが、ユーザーがどのような文書検索を行うかを知ることが不可欠である理由です。ユーザーが1つのフィールドで検索を行う場合、必要なのはそのフィールドのみです。また、ユーザーの80%が3つのフィールドを使い、残りの20%がその3つのフィールドとその他のフィールドを使って照会を行う場合、索引を3つ作り、他のフィールドは単にフィルター・フィールドのままにしておくのがよいでしょう。 アプリケーション・グループ表は、使用できる行数によって制限を受けます。使用できる行数は、アプリケーション・グループのプロパティーに設定しますが、デフォルトでは1,000万行に設定してあります。1,000万行を保管すると、最初の表が閉じられて次の表が開かれます。この場合、両方の表に対して照会が行われる際には、パフォーマンスがわずかに低下します。1つの表に対する照会と2つの表に対する照会では、パフォーマンスの差は極めて微小なものであり、ほとんど気づかれないほどですが、それが100の表に対する検索となると状況は異なります。また逆に、行の制限を高く設定してしまうと、表との照会に時間がかかるようになり、その場合にもパフォーマンスは低下します。 そこで、セグメント・フィールドが必要となります。通常、「レポートの日付」や「ステートメントの日付」といったセグメント値を常に指定することによって、パフォーマンスを高めることができます。レポートにそのような値がない場合には、「ロードの日付」をアプリケーションで指定することによって、それを行うことができます。この値は、日時順にすることによって、有効なセグメント化が可能となります。セグメント・フィールドによって、検索する表の数を制限できるようになります。セグメントに「ロードの日付」を使い、年に4回、表が更新される場合には、検索の際に「月」および「年」を追加することによって、その検索をひとつの表に制限することができます。悪くても、月が2番目の表に繰り越される程度ですみます。このように、検索する表を絞り込むだけでも、検索の幅をうまく狭めることができます。
企業によっては、利用できるキャッシュの量に何らかの制限を加えている場合もあります。しかし、多くの場合、データをできる限り長期間の間、キャッシュに保持しておくことが重要です。長期記憶域からデータを取り出す時間の間エンド・ユーザーを待たせておくということは、できる限り避けたいものです。
ステップ3：優れたパフォーマンスと使いやすさを目指したフォルダーの設計 以下のような、役に立つOnDemandの基本的原則があります
これはつまり、索引付けされた情報が同じである限り、AFP™、JPG、LINE、PDF、TIFFのデータを同じアプリケーション・グループ内に置くことができる、ということです。 以下のようになることが必要です。
ここまで基本を述べましたので、これから、簡単なシナリオを実際に検討し、OnDemandソリューションの設計をすることにしましょう。 あなたの会社では、以下の6つのレポートをOnDemandで保管したいと考えているとします。
よくないソリューションの例： 以下は、上記の情報のみに基づいた、きわめて簡単かつ未熟な設計です。
よいソリューションの例： データの使用方法について少し詳しく調べることによって、以下のことが確認できる。 顧客番号、日付にメジャー照会を用いる 顧客説明にマイナー照会を用いる （役員と会計士が使用） 顧客番号、日付にメジャー照会を用いる 顧客説明にマイナー照会を用いる （役員、会計士、販売担当者が使用） 製品番号、日付にメジャー照会を用いる 製品説明、取引タイプにマイナー照会を用いる （役員、会計士、在庫管理、販売担当者が使用） 顧客番号、日付にメジャー照会を用いる 顧客説明、取引タイプにマイナー照会を用いる （会計士が使用） 顧客番号、日付にメジャー照会を用いる 顧客説明にマイナー照会を用いる （役員、会計士が使用） 従業員番号、姓、日付、社会保障番号にメジャー照会を用いる 姓、部門にマイナー照会を用いる （会計士、人事が使用） これらのレポートから得られた情報を使用する、優れたOnDemand設計は、以下のようなものになります。 「給与計算元帳」は、人事部門が使用する唯一のレポートです。したがって、以下のものを作成します。 1. フォルダー「Payroll Ledger」2. アプリケーション・グループ「payledge」
3. アプリケーション「payledge」
次の「取引明細報告書」は、他と必要項目が類似しています。ただし、他の会計報告書では必要とされない「取引タイプ」が必要です。
最後に、「バランスシート」「セールス明細報告書」「損益計算書」の3つのレポートがありますが、これらはすべてデータ・タイプが異なります。照会に必要な項目はすべて同じです。1つ注意しなければならないのは、セールス明細報告書だけが唯一販売部門によって使用されるものだということです。しかし、これらのレポートは、単一のアプリケーション・グループにも適しています。 1. フォルダー：
2. アプリケーション・グループ：「execreport」
3. アプリケーション「balsheet」「salesrpt」「incomestmnt」 このソリューションでは、「6つのアプリケーション」、「4つのアプリケーション・グループ」、「5つのグループによるアクセスが管理される5つのフォルダー」が必要となります。各照会では、1つの表の最小限の部分に対して検索が行われ、検索のほとんどは、表スキャン（フィルター・フィールド）ではなく、索引スキャン（索引フィールド）によって行われます。日付フィールドをセグメント日付としてリストしてあるため、データを日付順にロードし、ユーザーが日付を入力する場合、最小限度の表で照会を行うことができるようになります。 優れたOnDemand設計は、以上の例には限られるものではありません。照会の制限、ユーザー・グループの制限、アプリケーション・グループの許可など、他の方法もいつくかあります。他の設計方法に関しては、OnDemand Support Webサイトを参照してください。 OnDemandソリューションの設計者として、皆さんはこれから、さまざまな種類のレポートのアーカイブを手がけることになるでしょう。行データやAFPデータ以外のものもあり、また、さまざまな照会のニーズがあります。最高の設計を実現するには、「誰がレポートを使用するのか」、「レポートの照会はどのように行われるのか」を理解することが必須です。ソリューションの構築の前に綿密な計画を立てることが、その後長年にわたって効率を維持することのできる設計を可能にするのです。
Eric Hannは、1998年からContent ManagerのOnDemand Supportに加わり、現在、コロラド州ボールダーを拠点とするContent Managerの OnDemand Supportで Team Leadを務めています。彼はこれまで、Content Manager製品のWebベース・サポートの初期設計と実 施において重要な役割を果たしてきました。 Benjamin Boltzは、同じく、コロラド州ボールダーに拠点を置くContent ManagerのOnDemand Developerです。Content Manager OnDemand（最終的にそういう名称の製品となった）のインストーラーとして1996年にIBMに入社しました。メールアドレスはそれぞれ、ehann@us.ibm.comとboltz@us.ibm.comです。  原文はこちら
(英文）
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
