IBM Lotus DominoおよびIBM DB2統合機能を使用してLotus Dominoアプリケーションの機能とパフォーマンスを強化する

ページオプション JavaScript を要するドキュメントオプションは表示されません ダウンロード 原文はこちら

レベル: 中級

Karen Brent (Karen_Brent@uk.ibm.com), Lotus Early Program Manager, BetaWorks, IBM

2008年 6月 17日
更新 2009年 11月 13日

IBM® DB2® を IBM Lotus® Domino®のデータ・ストア先として使用する方法を解説しましょう。この記事では、サンプル・アプリケーションを使用して、従来の Lotus Domino アプリケーションでの Lotus Domino および DB2 統合機能（以下DB2NSF機能と記述）の使い方を示す 4 つのシナリオについて説明します。

DB2NSF機能は、最初は Lotus Notes®/Domino 7 で非サポートの試用形式としてリリースされましたが、現在 Lotus Notes/Domino 8 では完全にサポートされています。

この機能により、ネイティブ DB2 データ (または、DB2 からアクセス可能なリポジトリーに保存されているデータ) を Lotus Domino のデータと動的に統合するアプリケーションを容易に作成できるようになります。さらに、Lotus Domino ビューまたは DB2 ビュー (あるいは、その両方) を介することで、アプリケーションの要求に応じて統合されたデータにアクセスできます。これらの機能は、すでに DB2 または DB2 からアクセスできる他のリレーショナル・データベース (たとえば、SAP または PeopleSoft など) を使用している組織にとって、興味深いさまざまな可能性をもたらします。この統合されたデータへの Web ベースのアクセスは、Lotus Domino アプリケーションへの HTTP アクセスまたは DB2 ビューへの JDBC アクセスを通じて行われます。

また、Lotus Notes/Domino 8 には DB2 を Lotus Dominoのデータ・ストア先として使用するライセンスが含まれています。このライセンスにより、ソフトウェアの追加コストを支払うことなく、従来のLotus Domino データ・ストア先（NSF）に保存されているアプリケーションを強化する機能を利用できます。この記事では、既存の外部 DB2 データを統合する必要がない従来の Lotus Domino アプリケーションに対し、DB2NSF機能がどのような利点を有しているのかについて説明します。

DB2NSF機能は、必ずしもすべての Lotus Domino アプリケーションに適するわけではないので、この点を理解することが重要です。おおよそ次の特徴を持つ Lotus Domino アプリケーションがこの統合機能に適しています。

• Lotus Notes クライアントへの複製を必要としない。
• データベース全体を 1 つのビューに表示する必要がない、またはその必要性が制限されている。
• 同じ情報を異なる方法でカテゴリー化する似たようなビューが多数ある。
• ユーザーは、80% から 90% の作業で一度に少数の文書しか参照しない。
• 複数の Lotus Notes データベースからデータを結合できることが利点になる。
• SQL のレポート機能を使用できることが利点になる。

しかし、重要なことは、これらの特徴を持つ既存の Lotus Domino アプリケーションを選択し、DB2 データ・ストアを使用するように変換するだけでは、アプリケーションには何の利点ももたらさないことです。アプリケーションを再設計し、DB2 対応アプリケーションで利用可能な新機能を活用することによってのみ、利点を得られます。実際に多くのケースでは、既存の設計を DB2 へ移行するのでなく、役に立つ DB2 対応アプリケーションを設計および開発し、必要なデータを生成することが最良の方法となるでしょう。

この記事では、サンプル・アプリケーションを使用して、従来の Lotus Domino アプリケーションで DB2NSF機能を使用する 4 つのシナリオを示すことにより、この機能がいつ、どのような方法でパフォーマンスの改善や機能強化などの利点をもたらすのかを説明します。この記事を読む際に Lotus Notes アプリケーション・デザインの知識が役立つこともありますが、サンプル・アプリケーションの設計およびコーディングはできるだけ簡潔にしているため、十分なアプリケーション開発の経験がなくても、その原理を容易に理解できます。

以下のシナリオで説明する機能は、アプリケーションが DB2 対応の Lotus Domino サーバー上でホストされている場合にのみ利用可能であることに注意してください。アプリケーションが DB2 非対応の Lotus Domino サーバーまたは Lotus Notes クライアントに複製される場合、ここで説明する機能は利用できません。

シナリオ1: データの独立性を Lotus Notes アプリケーションに実装する

Lotus Notes/Domino は、リレーショナル・データベースのアプリケーション・プラットフォームではありません。しかし、アプリケーション内でデータのソートおよびカテゴリー化の柔軟性を高めるために、何らかのリレーショナル・データベース機能を Lotus Notes アプリケーションに追加することが非常に有効なケースもあります。

たとえば、会社が主催するイベントの詳細を記録するアプリケーションについて考えてみましょう。私たちは、イベントに関する情報 (タイトル、主催した地域、日付、コスト)、発表されたトピック、およびイベントに出席した参加者の記録を保持する必要があります。各イベントではいくつかのトピックが扱われ、複数の出席者がいます。1 つのトピックは複数のイベントの議題で扱われることがあり、1 人の参加者は複数のイベントに出席できます。また、各参加者は、それぞれが属する地域に対応しています。これらの関係を図で示すと図 1 のようになります。

トピックと参加者のエントリーに複数値フィールドを使用し、これに応じて参加者の地域を検索する機能を付けると、このシナリオを 1 つのフォームに記録できます (図 2 参照)。

1 つのイベントに関するすべてのデータは単一の文書に格納されているため、同じイベントの異なるデータ項目間で特定の関係を定義および管理することはより困難です。たとえば、図 2 に示した文書では、イベントで扱われた各トピックに Jasmine を対応させることができますが、Jasmine が属する参加者の地域は 1 つだけです。

データが文書に格納されている場合、Lotus Domino の標準的なアプリケーション手法では、複数の文書からのデータをビュー内の 1 つの行に結合することは容易ではありません。

DB2NSF機能を使用すると、適切な場合にデータを異なる文書に格納してデータの独立性を実装できますが、必要に応じてデータをビュー内の 1 つの行に結合できる機能も維持されています。

たとえば、個別の Agenda Item フォームを使用して、各イベントに特有のトピック関連データを作成したり、個別の Attendee フォームを使用して、各イベントに特有の出席者関連データを作成したりすることができます。トピックおよび参加者の情報をリンクしてイベントに戻せるようにするには、各イベント固有のキーを使用し、このデータを Agenda Item と Attendee の各文書に格納します。

これらの関係を図示すると、今度は図 3 のようになります。

イベント・フォームは、トピックおよび出席者を表示するために入力することも可能ですが、今回は、各議題項目および各出席者の情報は個別の文書に格納されていて、埋め込みビューを使用して Events フォームに表示します。図 4 に示す例には、Event Key フィールドがあることに注目してください。ユーザーが議題項目を追加するボタンを使用すると、このイベント・キーが継承された新規文書が作成されます。埋め込みビューには、イベント・キーによってカテゴリー化されたすべての議題項目レコードが含まれますが、1 つのカテゴリー、つまり現在の文書のイベント・キーに一致するカテゴリーだけを表示するように設定されています。

複数の文書からのデータをビュー内の同じ行に結合するビューを作成するために、DB2 アクセス・ビュー (DB2 内のデータを公開する) とクエリー・ビュー (SQL ステートメントを使用してデータを Lotus Notes ビューに取得する) の組み合わせを使用できます。DB2 アクセス・ビューおよび SQL クエリー・ビューの作成についての詳細は、「Lotus Domino 8 Designer ヘルプ」(US)を参照してください。

最初の例では、DB2 アクセス・ビューは、Event、AgendaItem、および Attendee という 3 つのフォームのそれぞれに作成されます。図 5 の特定のフィールドの横にチェック・マークが付いていることに注目してください。これらは、クエリー・ビューの選択条件で使用する可能性があるフィールドです。チェック・マークはこれらのフィールドが DB2 で索引作成されていることを示し、この索引によってデータの取得効率が高まります。

この選択により、DB2 コントロール・センターを通じて表示できる 3 つのビューが得られます (図 6 参照)。

DB2 表 (表名に _T および _X という接尾辞があるもの) および DB2 ビューのどちらも DB2 アクセス・ビューに対応しています。セキュリティー・トリガーを含む DB2 ビューは Lotus Domino サーバーによってアクセスが検証されるため、DB2 アクセス・ビューを通じて公開されたデータへのアクセスは、DB2 表ではなく常に DB2 ビューを介して行われます。

そして、リスト 1 のコードで示す SQL SELECT ステートメントによって SQL クエリー・ビューが作成されます。

 
MySchema := @DB2Schema(@DbName);

"SELECT ATTENDEES.ATTENDEENAME, ATTENDEES.REGION, AGENDA.TOPICNAME, EVENTS.EVENTDATE, 
EVENTS.EVENTNAME,  EVENTS.#NOTEID FROM "

+ MySchema + ".ATTENDEES AS ATTENDEES, "
+ MySchema + ".EVENTS AS EVENTS, "
+ MySchema + ".AGENDAITEMS AS AGENDA "

+ "WHERE ATTENDEES.EVENTKEY = AGENDA.EVENTKEY AND AGENDA.EVENTKEY = 
EVENTS.EVENTKEY"

クエリー内にスキーマ名をハードコーディングしなくてもよいように、ビューに用いられるスキーマ名は @DB2Schema を使用して計算している点に注意してください。スキーマは各 Lotus Notes データベースに固有であり、異なるデータベースからの DB2 アクセス・ビューがたとえ同じ名前であっても、このスキーマによってそれぞれを識別できます。

3 つの異なる文書タイプからフィールド (Attendee 文書からの Attendee Name、Agenda Item 文書からの Topic Name、および Events 文書からの Event Date と Event Name) がどのように選択されるのかに注目してください。

クエリー・ビューから文書を開けるようにする場合は、SELECT ステートメントに #NOTEID を含める必要があります。リスト 1 の SELECT ステートメントには、Events 文書からの #NOTEID フィールドが含まれています。これが含まれることにより、ビュー内で行がダブルクリックされたときに、デフォルトのオプションとして、出席者とトピックをリンクするイベント文書が開かれます。

前述のように、スキーマ名は正しい DB2 ビューを識別するために重要です。SQL ステートメントを読みやすくするために、AS を使用して、選択されたビューに別名を割り当てることができます。このため、該当フィールドを参照するたびに <MySchema>.ATTENDEES.ATTENDEENAME を使用する代わりに、<MySchema>.ATTENDEES を別名の ATTENDEES で置き換えられます。

最後に、この SQL ステートメントは、一致する EventKey フィールドに基づいて WHERE を使用して 3 つの表を結合します。このコーディングは、複数の文書からのフィールドを持つ単一の行をビュー内に作成する方法を示しています。EventKey は、DB2 索引を追加したフィールドの 1 つでした。この追加により、DB2 は一致する EventKey フィールドを持つレコードを非常に効率よく検索し、返すことができます。

DB2 コントロール・センターで SQL 支援ツールを使用すると、必要な SQL ステートメントを構成し、望ましい結果を返しているかチェックする作業を補助できます。図 7 に示すように、このクエリーでは、1 つのイベントに関連する文書 (1 つのイベント文書、4 つの出席者文書、3 つのトピック文書) を取り上げ、可能なすべての文書の組み合わせを個別の行として提供しています。

図 7 に示した DB2 クエリーの結果は、これらの名前を使用して列を追加することにより、Lotus Notes ビューで再生成できます。また、Lotus Notes ビューは、Lotus Notes のビューおよび列の標準プロパティーを使用してソート、カテゴリー化、および書式設定することが可能です (図 8 参照)。

データの独立性は、ソートおよびカテゴリー化により大きな柔軟性をもたらします。たとえば、ある地域でイベントを主催するときに、その地域の参加者に招待状を送ることができると便利です。Participant という DB2 アクセス・ビューをコレクションに追加できます (図 9 参照)。

次に、リスト 2 に示すように、イベントと出席予定者を結合する SQL クエリーを書くことができます。

 
MySchema := @DB2Schema(@DbName);

"SELECT  "

+ "EVENTS.EVENTNAME || ' - ' || CHAR(EVENTS.EVENTDATE) AS EVENT, "

+ "PARTICIPANT.#NOTEID, PARTICIPANT.EMPLOYEE FROM "

+ MySchema + ".EVENTS AS EVENTS, "
+ MySchema + ".PARTICIPANT AS PARTICIPANT "

+ "WHERE EVENTS.REGION = PARTICIPANT.DEPARTMENT"

繰り返されているイベントのそれぞれを識別したいので、このクエリーは連結関数を使用して EventName および EventDate フィールドを結合しています。EventDate は日付フィールドであるため、連結する前にこれをテキスト・フィールドに変換しなければなりません。連結した値をビューに表示するために、これに EVENT という別名を割り当てる必要があります。この別名は、出席予定者をグループ化するためにビューの列式で使用される別名です。

今回は、Participant DB2 アクセス・ビューから #NOTEID を含めたため、ビュー内の行をダブルクリックすることで、参加者のレコードを開けます。

結果は図 10 のようになります。

EventName と EventDate をクエリー内で別々に選択し、「EventName + “-” + EventDate」のような Lotus Notes の列式を使用することも可能でした。しかし、DB2 で連結を行い、その結果を単に Lotus Notes ビューに表示する方がより効率的です。

たとえば、参加者が関心を持つトピックなど、参加者に関するよりプロファイル・ベースの情報を保管している場合は、より複雑な WHERE 節を使用することで、参加者の関心と予定の議題を比較し、これらが一致する招待済みの参加者だけをリストすることが可能です。

上に戻る

シナリオ2: 動的なクエリー・ビューを使用してアプリケーションの効率を改善する

アプリケーションにデータを追加するにつれ、埋め込みビューを持つイベント・フォームの表示が徐々に遅くなることがあります。埋め込みビューで単一のカテゴリーを表示するとき、Lotus Notes クライアントは必要なカテゴリーを表示する前に、カテゴリー化されたビュー全体を最初に取得します。必要なカテゴリーに一致するレコードだけを取得すれば、効率は大きく向上します。

このアプリケーションは DB2 に対応しているため、標準の Lotus Notes ビューを使用する代わりに、動的に作成される SQL クエリーを持つクエリー・ビューを使用するように埋め込みビューを構成できます。

標準の Lotus Notes ビューには、ビューを取得する際にビューの選択式にパラメーターを渡す方法がありません。しかし、クエリー・ビューには、ビューの取得時に SQL クエリーを変更可能な、主に3 つの方法があります。

まず、SQL クエリーは、他の Lotus Notes 文書またはビュー (たとえば、プロファイル文書) の情報を検索することや、環境変数から値を読み取ることができます。以下の例では、コードはイベント・フォームの PostOpen イベントに入力されているため、各文書が開かれるときに、埋め込みビューはイベント・キーを使用して、取得するトピックと出席者レコードを決定します。

リスト 3 の LotusScript® コードでは、EventKey フィールドの値を環境変数 EventkeyENV に設定しています。

 
Sub Postopen(Source As Notesuidocument)
Dim session As New NotesSession
Call session.SetEnvironmentVar _
("EventKeyENV",source.FieldGetText("EventKey"))
End Sub

リスト 4 に示した SQL クエリーは、環境変数 EventKeyENV の値を取得し、SQL ステートメントの WHERE 節でこの値を使用し、イベント・キーが一致するレコードだけを取得します。

 
MySchema := @DB2Schema(@DbName);
Keyword := @Environment("EventKeyENV");

"SELECT * FROM " + MySchema + ".ATTENDEES AS ATTENDEES WHERE ATTENDEES.EVENTKEY =
'" + Keyword + "'"

現在、この埋め込みビューには必要なデータだけが含まれているため、埋め込みビュー・オブジェクトのプロパティーで「単一カテゴリーの表示」オプションを使用しなくても、同じ結果が得られます。

埋め込みビューは、それ自体が表示されている文書の内容を表示する機能を持たないため、SQL クエリー内でイベント・キー・フィールドの値を直接文書に使用できません。

動的なクエリー・ビューを構成する 2 番目の方法は、ビューが開かれるときに、ユーザーに何らかの情報を入力または選択するように促す方法です。そして、ユーザーから提供された情報を使用して、ユーザーが関心を持つ行だけが返されるよう行を制限することができます。

たとえば、トピック別に出席者をカテゴリー化するクエリー・ビューを作成できます (図 11 参照)。

このビューを開いているユーザーは、どの出席者が特定のトピックについて学習したかを知ることにのみ関心を持つでしょう。現在のビューでは、すべてのレコードが返されてカテゴリー化されるので、ユーザーは自分が関心を持ったトピック・カテゴリーに移動し、参照する必要があります。レコードが選択される前に、ユーザーが関心のあるカテゴリーを選択または入力できると、効率が大幅に向上します。

これを行うには、@Prompt 関数を SQL クエリーに追加してユーザーに関心のあるトピックの入力を求め、これを SQL ステートメントの WHERE 節に追加します (リスト 5 の SQL クエリーを参照)。

 

MySchema := @DB2Schema(@DbName);

TopicChoice := @Prompt([OkCancelEdit]; "Topic Name"; "Enter topic name";"");

"SELECT AGENDA.TOPICNAME, ATTENDEES.ATTENDEENAME, EVENTS.EVENTDATE, EVENTS.EVENTNAME, 
EVENTS.#NOTEID FROM " + MySchema + ".ATTENDEES AS ATTENDEES, " + MySchema + 
".EVENTS AS EVENTS, " + MySchema + ".AGENDAITEMS AS AGENDA WHERE ATTENDEES.EVENTKEY =
AGENDA.EVENTKEY AND AGENDA.EVENTKEY = EVENTS.EVENTKEY  AND "

+ "AGENDA.TOPICNAME = '" + TopicChoice + "'"

ユーザーがこのビューを選択すると、関心を持っているトピック名の入力を求められます (図 12 参照)。この場合、ユーザーはトピック・フィールドに「Notes 8 Client」と入力します。

このトピック (Notes 8 Client) に対応するレコードだけが返されます (図 13 参照)。

@Prompt 関数では、検索関数を使用することで、正しいデータだけが入力されるように、選択用の適切なトピックのリストをユーザーに提供できます。別のトピック名を選択するには、ユーザーは F5 (または F9) キーを押してビューを更新します。入力を求めるダイアログ・ボックスが再び表示されます。

この例ではコードを簡潔にするために行っていませんが、フリー・フォームのユーザー入力を許可する SQL オペレーションでは、ベスト・プラクティスとして、クエリーを実行する前に、DB2 の特殊文字 (たとえば、引用符やセミコロンなど) が入力に含まれないようにします。この手法により、ユーザーがクエリーをハッキングしてデータを不正に削除または変更することを防止できます。このような動作を停止する DB2 のパーミッション設定がありますが、最初の段階で問題を防止しておくとよいでしょう。

SQL クエリーを動的に変更する 3 番目の方法として、URL 値の置換を用いる方法があります。

@URLQueryString 関数を使用すると、現在の URL から情報を抽出し、クエリー・ビューを変更できます。

たとえば、対応するレコードを表示する前に、ユーザーに出席者名の入力を求める Web バージョンのビューについて考えましょう。リスト 6 に示す SQL クエリーを使用すると、URL の Attendee パラメーターに渡された値を取り出し、これをレコードの選択に使用することができます。

 

MySchema := @DB2Schema(@DbName);

AttendeeChoice := @UrlQueryString("Attendee");

"SELECT ATTENDEES.ATTENDEENAME, AGENDA.TOPICNAME, EVENTS.EVENTDATE, EVENTS.EVENTNAME, 
EVENTS.#NOTEID FROM " + MySchema + ".ATTENDEES AS ATTENDEES, " + MySchema + 
".EVENTS AS EVENTS, " + MySchema + ".AGENDAITEMS AS AGENDA WHERE ATTENDEES.EVENTKEY = 
AGENDA.EVENTKEY AND AGENDA.EVENTKEY = EVENTS.EVENTKEY AND ATTENDEES.ATTENDEENAME = 
'" + AttendeeChoice + "'"

次の URL を入力 (または、この URL を生成するリンクをクリック) したユーザーには、図 14 に示すレコードが表示されます。

 
  http://domino.betaworks.ibm.com/db2example/events.nsf/WebTopics?
  OpenView&Attendee=Frank%20Adams

前述の例に加え、他の領域においても、標準の Lotus Notes ビューよりも SQL クエリー・ビューを使用することにより、一層パフォーマンスが向上する可能性があります。

まず、Lotus Domino データベース内の標準の Lotus Notes ビューは、Lotus Domino サーバーによって維持および更新されます。データベースが DB2 対応であれば、これらのビューの索引は物理的に DB2 サーバーに格納されますが、索引はまだ Lotus Domino サーバーによって維持および更新されています。ビュー索引が大きく、アプリケーション内でのデータの変更頻度が高い場合、Lotus Domino サーバーはこれらのビュー索引を最新状態に保つために、かなりのリソースを費やすでしょう。

Lotus Domino サーバーは、クエリー・ビューで索引を維持する役割を持っていません。これらの索引は、すべて DB2 サーバーによって処理されます。このため、Lotus Domino サーバーと DB2 サーバーが異なるハードウェア・デバイス上でホストされている環境では、標準の Lotus Notes ビューの代わりにクエリー・ビューを使用することで、Lotus Domino サーバーでのロードを大幅に削減できます。また、ユーザーが標準の Lotus Notes ビューを開くとき、Lotus Domino サーバーはビューを表示する前にビュー索引を更新する必要があります。DB2 では、文書が追加、更新、または削除されるたびに索引が更新されるため、SQL ステートメントを実行する前に索引の更新を実行する必要はありません。これにより、データをより迅速に取得できます。

次に、従来の Lotus Notes アプリケーションでは、ユーザーが同じデータのセットをさまざまな方法でソートおよびカテゴリー化できるようにするために、多数のビューを含めることができます。たとえば、10 のビューと 5,000 文書でスタートしたアプリケーションが、数年後には 500 のビューと 500,000 文書を持つようになるのは、非常に一般的です。そして、Lotus Domino サーバー上の UPDATE/UPDALL タスクは、すべてのビューの索引を最新の状態に保とうとするため、Lotus Domino サーバーのパフォーマンスに深刻な影響を及ぼす可能性があります。

DB2NSF機能を使用すると、標準ビューのグループを単一の動的クエリー・ビューに置き換えて、アプリケーションに関連するビューの数を大幅に削減できます。前述の例では、値の置換について説明しました。つまり、ビューの内容は一致するトピック名によって決定されます。リスト 7 に示すように、SQL クエリーのすべての部分を置換することができます。

 

MySchema := @DB2Schema(@DbName);

CategoryChoice := @Prompt([OkCancelList]; "Category"; "Select category";""; 
"Topic":"Attendee");

CategoryCol := @If(CategoryChoice = "Topic"; "AGENDA.TOPICNAME"; 
"ATTENDEES.ATTENDEENAME");

SecondCol := @If(CategoryChoice = "Topic"; "ATTENDEES.ATTENDEENAME"; 
"AGENDA.TOPICNAME");

"SELECT " + CategoryCol + " AS CATEGORY, "

+ SecondCol + " AS SECOND "

+ ", EVENTS.EVENTDATE, EVENTS.EVENTNAME, EVENTS.#NOTEID FROM " + MySchema + 
".ATTENDEES AS ATTENDEES, " + MySchema + ".EVENTS AS EVENTS, " + MySchema + 
".AGENDAITEMS AS AGENDA WHERE ATTENDEES.EVENTKEY = AGENDA.EVENTKEY AND 
AGENDA.EVENTKEY = EVENTS.EVENTKEY"

このクエリーでは、トピック別または参加者別のどちらでカテゴリー化されたデータのセットを表示するのか、ユーザーに選択を求めます。

次に、選択されたフィールドに CATEGORY という別名が割り当てられ、他のフィールド (この場合は、さらにビューに表示したいフィールド) に SECOND という別名が割り当てられます。ビュー内の最初と 2 番目の列で、CATEGORY および SECOND をフィールド名として使用した場合 (さらに、2 番目の列名をブランクのままにする)、ユーザーがカテゴリーとして「Topic」を選択すると、図 15 と同じビューが表示されます。

ユーザーがカテゴリーとして「Attendee」を選択すると、図 16 と同じビューが表示されます。

上に戻る

シナリオ3: アプリケーションを複数のデータベースに広げる

多くの組織では、業務上重要で長年にわたって使用され、多くのデータが蓄積され続ける Lotus Domino アプリケーションを開発しています。アプリケーションのサイズが増加するのにともない、アプリケーションのパフォーマンスが低下し、アプリケーションを維持するのが難しくなることがあります。前のセクションで説明したように、標準の Lotus Notes ビューの代わりにクエリー・ビューを使用することが、パフォーマンスを改善し、アプリケーションに関連するビュー索引のサイズを削減する 1 つの方法となるでしょう。最近、あるお客様から、標準の Lotus Notes ビューをクエリー・ビューで置き換えることにより、40% もアプリケーションのサイズを削減できたという報告が寄せられました。しかし、大量のデータを持つアプリケーションでは、この削減ではまだ不十分です。

Lotus Domino アプリケーションを DB2 データ・ストアに格納しても、単一の Lotus Domino データベースのサイズが、現在の NSF の上限 (64 GB) を超えられるようにはできません。DB2NSF機能を使用して、大規模なアプリケーションをより効率的に管理し、アプリケーションに関連するデータの合計がこの上限を超えられるようにする方法があります。

たとえば、イベント・アプリケーションの拡大にともなってアプリケーションを個別のデータベースに分割すると (たとえば、1 年ごとに 1 つのデータベース)、より効率が高くなります。しかし、ユーザーはレポートを作成する目的で、現在は異なるデータベースに格納されているレコードを結合して表示するビューを求めているかもしれません。

アプリケーション内のすべてのデータベースが DB2 に対応していると、単一の SQL クエリー・ビューを使用して、個別の各データベースに対応する DB2 アクセス・ビューからレコードを取得できます。

たとえば、2007 年のイベント・レコードを保持するアーカイブ・データベース (現在、取り上げているデータベースと同じ設計) について考えてみましょう。このデータベース設計には、ユーザーに出席者名の入力を求め、その出席者が受講したトピックを表示する動的なクエリー・ビューがあります。

現在のデータベースでは、ビューは図 17 のようになります。

2007 年のアーカイブ・データベースでは、ビューは図 18 のようになります。

SQL クエリーを使用して、両方のデータベースからのレコードを結合するクエリー・ビューを現在のデータベース内に作成できます (リスト 8 参照)。

 

MySchema := @DB2Schema(@DbName);
ArchSchema := @DB2Schema("":"DB2Example\\events2007.nsf");
AttendeeChoice := @Prompt([OkCancelEdit]; "AttendeeName"; "Enter attendee name";"");

"SELECT ATTENDEES.ATTENDEENAME, AGENDA.TOPICNAME, EVENTS.EVENTDATE, 
EVENTS.EVENTNAME, EVENTS.#NOTEID FROM " + MySchema + ".ATTENDEES AS ATTENDEES, " + 
MySchema + ".EVENTS AS EVENTS, " + MySchema + ".AGENDAITEMS AS AGENDA WHERE 
ATTENDEES.EVENTKEY = AGENDA.EVENTKEY AND AGENDA.EVENTKEY = EVENTS.EVENTKEY 
AND ATTENDEES.ATTENDEENAME = '" + AttendeeChoice + "'" +

" UNION SELECT ATTENDEES.ATTENDEENAME, AGENDA.TOPICNAME, EVENTS.EVENTDATE, 
EVENTS.EVENTNAME, EVENTS.#NOTEID FROM " + ArchSchema + ".ATTENDEES AS ATTENDEES, " + 
ArchSchema + ".EVENTS AS EVENTS, " + ArchSchema + ".AGENDAITEMS AS AGENDA WHERE 
ATTENDEES.EVENTKEY = AGENDA.EVENTKEY AND AGENDA.EVENTKEY = EVENTS.EVENTKEY 
AND ATTENDEES.ATTENDEENAME = '" + AttendeeChoice + "'"

今回は、アーカイブ・データベースのスキーマ名を計算しなければならない点に注意してください。前の例では、スキーマ名はハードコーディングされたデータベース名から計算されていました。この名前をデータベースのレプリカ ID にして、それをアプリケーション設定の別の場所に格納することにより、データベース名のハードコーディングを不要になります。

また、SQL ステートメントが UNION を使用して 2 つのレコードを結合している点にも注目してください。

出席者名でソートされたこのビューは図 19 のように表示され、現在のデータベースからのレコードと、アーカイブ・データベースからのレコードが混在しています。

この設定では、現在のデータベースに格納されていないレコードをユーザーがダブルクリックすると、レコードの #NOTEID 値が現在のデータベース内でのみ使用して文書を検索するため、正しいレコードが開かれません。現在のデータベース以外のデータベース内で文書を検索し、開けるようにするには、もう少し作業が必要です。

DB2 アクセス・ビューを使用すると、文書のソース・ロケーションを識別するために役立ついくつかの特殊フィールドを保管できます。この例では、以下の特殊フィールドを使用します。

• #DBPATH - DB2 アクセス・ビューが置かれているデータベースのファイル・パスとディレクトリーを提供します。
• #SERVER - データベースが保存されているサーバーの名前を提供します。
• #UNID - DB2 アクセス・ビューの各レコードに対応する文書の固有 ID を提供します。

図 20 を参照してください。

これらの特殊フィールドを DB2 アクセス・ビューに追加すると、DB2 で特別な情報を見られるようになります (図 21 参照)。

この情報を使用してQueryOpenDocument イベントを設定することで正しい文書を検索して開くようにできます。

これらの新しいフィールドを SQL クエリーで取得するために、リスト 9 に示すような SQL を使用できます。

 
MySchema := @DB2Schema(@DbName);
ArchSchema := @DB2Schema("":"DB2Example\\events2007.nsf");
AttendeeChoice := @Prompt([OkCancelEdit]; "AttendeeName"; "Enter attendee name";"");

"SELECT ATTENDEES.ATTENDEENAME, AGENDA.TOPICNAME, EVENTS.EVENTDATE, 
EVENTS.EVENTNAME, EVENTS.#NOTEID," +

" EVENTS.#SERVER || '~' || EVENTS.#DBPATH || '~' || EVENTS.#UNID AS DOCID " +

"FROM " + MySchema + ".ATTENDEES AS ATTENDEES, " + MySchema + ".EVENTS AS EVENTS, " + 
MySchema + ".AGENDAITEMS AS AGENDA WHERE ATTENDEES.EVENTKEY = AGENDA.EVENTKEY 
AND AGENDA.EVENTKEY = EVENTS.EVENTKEY AND ATTENDEES.ATTENDEENAME = '" + 
AttendeeChoice + "'" +

" UNION SELECT ATTENDEES.ATTENDEENAME, AGENDA.TOPICNAME, EVENTS.EVENTDATE, 
EVENTS.EVENTNAME, EVENTS.#NOTEID, EVENTS.#SERVER || '~' || EVENTS.#DBPATH || '~' || 
EVENTS.#UNID AS DOCID FROM " + ArchSchema + ".ATTENDEES AS ATTENDEES, " + ArchSchema + 
".EVENTS AS EVENTS, " + ArchSchema + ".AGENDAITEMS AS AGENDA WHERE 
ATTENDEES.EVENTKEY = AGENDA.EVENTKEY AND AGENDA.EVENTKEY = EVENTS.EVENTKEY 
AND ATTENDEES.ATTENDEENAME = '" + AttendeeChoice + "'"

新しいフィールドを連結して 1 つの文書識別フィールドを作成している点に注目してください。これには、DOCID という別名を割り当てています。

他のデータベース内の文書を参照するエントリーに対応するローカルのバックエンド文書は存在しないため、ビュー内に表示される値を操作する能力には制限があります。使用できる唯一の LotusScript プロパティーは、NotesUIView クラスの CaretCategory プロパティーです。このプロパティーは、選択された文書の現在のカテゴリーを返します。

CaretCategory プロパティーに情報を渡すには、文書識別子情報をビューの最初の列に入れ、この列のソートを有効にする必要があります。この列はカテゴリー化する必要はなく、非表示にすることができます。しかし、このテクニックは、異なる列でのカテゴリー化を必要とするビューには機能しません。

DOCID の列式を設定すると、ビューの最初の列は図 22 のようになります。

このビューの Queryopendocument イベントにリスト 10 のコードを記述して、ビュー内の行がダブルクリックされたときに、正しい文書が検索されて開かれるようにできます。

 
Sub Queryopendocument(Source As Notesuiview, Continue As Variant)
continue = False
Dim ws As New NotesUIWorkspace	
Dim db As New NotesDatabase("","")	
Dim target As String
Dim server As String
Dim path As String
Dim unid As String

target = Source.CaretCategory

server = Strleft(target, "~")
path = Strleft(Strright(target, "~"), "~")	
unid = Strrightback(target, "~")

Call db.Open(server, path)
Set originalDoc = db.GetDocumentByUNID ( unid )

Set uidoc = ws.EditDocument(False, originalDoc, False, "", False, True)

End Sub

Attendee 列のカテゴリー化を解除し、新しい最初の列を非表示にすると、ビューは図 23 のようになります。ユーザーがこのビューで任意の行をクリックすると、文書がどのデータベースに保存されているかにかかわらず、正しい文書が開かれます。

上に戻る

シナリオ4: Lotus Notes データについてレポートする

デフォルトでは、Lotus Notes には、データに関する要約レポートを生成するきわめて限定された機能しかありません。1 つのデータベース内で一定レベルのレポートを得るために、カテゴリー化されたビューに合計および平均を追加できます。前のセクションで説明したように、アプリケーションを DB2 対応にすると、クエリー・ビューを使用してデータベース間の情報を示すビューを作成できるようになります。合計および平均をこれらのクエリー・ビューに追加して、異なるデータベースにわたる基本レポート機能を提供できます。

しかし、この方法を使用するレポートでは、要約を実行する前に、すべてのソース・レコードを取得し、ビュー内に表示しなければなりません。要約行だけを取得すれば、要約レポートの生成は効率が高まります。DB2 には強力で幅広い関数ライブラリーがあり、その関数の多くは SQL クエリーで使用可能であり、元になるすべてのデータを取得および表示せずに要約レポート情報を提供できます。

たとえば、図 24 に示す標準の Lotus Notes ビューでは、すべてのイベント文書を参加者と地域別にカテゴリー化し、合計を Cost 列に追加することにより、出席者が参加したイベントの各地域のコストをまとめています。

各ユーザーのイベント・コストの合計をレポートすることだけに関心がある場合は、ユーザーが出席したすべてのイベントを取得する代わりに、リスト 11 に示す SQL クエリーを使用できます。

 

MySchema := @DB2Schema(@DbName);

"SELECT ATTENDEES.ATTENDEENAME, ATTENDEES.REGION, "

+ "SUM(EVENTS.COST) AS SUM "

+ "FROM " + MySchema + ".ATTENDEES AS ATTENDEES, " + MySchema + ".EVENTS AS EVENTS 
WHERE ATTENDEES.EVENTKEY =  EVENTS.EVENTKEY "

+ "GROUP BY ATTENDEES.REGION, ATTENDEES.ATTENDEENAME"

単に EVENTS.COST フィールドを選択するだけでなく、このコードには SUM 関数が追加されていることに注目してください。SUM 関数に関連して、EVENTS.COST 値のどのグループを追加する必要があるのかを SQL クエリーに指示する GROUP BY 節を追加しなければなりません。

次に、SUM(EVENTS.COST) に割り当てた別名の SUM を、Cost 列のフィールド値として使用します。地域別の要約合計を同じビューに表示したい場合、標準のビューの合計機能を使用することもできますが、ここでは、あらかじめ集計した出席者の合計コストから総計を計算します。

結果は標準の NSF ビューと同じ要約情報を表示するビュー (図 25 参照) になりますが、数千ものイベント・レコードがあるアプリケーションでは、より迅速に結果を得られます。

もう 1 つの例として、各地域でのスキルの範囲を表示したり、1 つの地域から少なくとも 1 人の参加者があるイベントのビューを作成したりするケースを取り上げます。このようなビューを作成するために、すべてのイベント出席者を地域別にカテゴリー化できますが、この方法では必要以上のレコードを取得することになります。必要なデータをより効率よく取得するには、リスト 12 に示すようなクエリーを使用できます。

 
MySchema := @DB2Schema(@DbName);

"SELECT DISTINCT EVENTS.EVENTNAME,  ATTENDEES.REGION FROM "

+ MySchema + ".ATTENDEES AS ATTENDEES, "
+ MySchema + ".EVENTS AS EVENTS "

+ "WHERE ATTENDEES.EVENTKEY = EVENTS.EVENTKEY"

SELECT パラメーターに続く DISTINCT パラメーターに注目してください。このパラメーターにより、1 つの地域から少なくとも 1 人の参加者がいるイベントごとに 1 つの行を返せます (図 26 参照)。

前の 2 つの例では、DB2 関数を使用して、標準の Lotus Notes ビューと同じ結果をより効率的に再現する方法を示しました。DB2 関数ライブラリーには、標準の Lotus Notes ビューの機能では不可能な方法で Lotus Notes データに関するレポートを生成できる多数の関数が含まれています。たとえば、図 13 に示すクエリーは、集約関数を使用して、地域ごとに出席者がいたイベントに関するいくつかの統計情報を提供します。

 
MySchema := @DB2Schema(@DbName);

"SELECT COUNT(EVENTS.COST) AS COUNT, SUM(EVENTS.COST) AS SUM, AVG(EVENTS.COST) 
AS AVG, MAX(EVENTS.COST) AS MAX, MIN(EVENTS.COST) AS MIN, ATTENDEES.REGION FROM "

+ MySchema + ".ATTENDEES AS ATTENDEES, "
+ MySchema + ".EVENTS AS EVENTS "

+ "WHERE ATTENDEES.EVENTKEY = EVENTS.EVENTKEY"

+ " GROUP BY ATTENDEES.REGION"

この SQL クエリーの結果を、列フィールドとして定義された別名 (COUNT、SUM、AVG、MAX、MIN) を使用してビュー内に表示できます (図 27 参照)。

前のシナリオでは、文書用の単一の文書識別子を作成するストリング連結関数 “||” の使い方を説明しました。

そのケースでは、関数を使用して同じ文書のフィールドを連結しました。しかし、異なる文書のフィールドを連結し、1 つないしは2つ以上のデータベースにわたって集約したレポートを生成するために、この方法を使用できない理由はありません。

前の例では Lotus Notes アプリケーション内で要約レポートを生成する方法を示しましたが、導入部で説明したように、スプレッドシート・アプリケーションや Crystal Reports などのサード・パーティーのレポート製品 (DB2 に保持されているデータへの直接の JDBC 接続を使用) で、同じデータを動的に利用できます。このアプローチにより、Lotus Notes アプリケーションに保存されているデータに関するレポートを作成する際に、これらのプログラムで利用可能な組み込みのグラフ機能およびレポート機能を使用できます。

上に戻る

まとめ

DB2NSF機能を使用して、Lotus Notes/Domino に保持されているデータと、DB2 に保持されている (または DB2 からアクセス可能な) データを統合するさまざまな方法に加え、外部のデータ統合を必要とせずに Lotus Domino アプリケーションのために利点を引き出す方法もあります。

この記事では、DB2NSF機能を使用して、アプリケーションの機能や、従来の Lotus Domino アプリケーションのパフォーマンスを強化する 4 つの簡単なシナリオについてまとめました。ここで使用したテクニックを組み合わせて拡張することにより、さらに複雑なアプリケーションを構築できます。

この記事で説明した機能は、DB2 対応サーバー上に存在するアプリケーションでのみ利用可能あり、これを理解することが重要です。これらの機能が含まれるアプリケーションを DB2 非対応のサーバーまたは Lotus Notes クライアントに複製すると、設計は複製されますが、いずれかの機能 (たとえば、クエリー・ビューを開く) を実行したときに、エラーが発生し、データは表示されません。

付録: サンプル・アプリケーション

変更をまったくせずにサンプル・アプリケーションを実行するには、以下の手順に従います。

1. ここの説明を参照し、Lotus Domino 8、DB2 9.1 FP2 サーバー、および DB2 Access Server をセットアップ(US) します。Lotus Domino アプリケーションで使われる DB2 アクセス・ビューおよび SQL クエリー・ビューの使い方に関するすべての手順を必ず実行してください。
2. データベース (EVENTS.NSF および EVENTS2007.NSF) を Lotus Domino サーバー上の DB2Example ディレクトリーにコピーします。デフォルトのデータベース形式が DB2 ではなく NSF の場合は、サーバー・コンソールで以下のコマンドを入力します。

   load compact -p DB2Example\events.nsf load compact -p DB2Example\events2007.nsf

   
   
   これらのコマンドは、DB2 データ・ストアを使用するようにデータベースを変換します。
3. Lotus Domino Designer で各データベースを開き、「共有リソース」->「DB2 アクセス・ビュー」に移動します。各 DB2 アクセス・ビューを順番に選択し、以下のアクションを順に選択します。
   • 「DB2 で作成/更新」アクション
   • 「DB2 に作成」
   • 「更新状況」

すべての DB2 アクセス・ビューが処理されると、各ビューに緑色のアイコンが表示されます (図 A1 参照)。

これで、アプリケーションを使用する準備が整いました。

上記に示した DB2Example ディレクトリーでデータベースが見つからない場合は、EVENTS2007 データベースの実際のデータベース・パスを反映するためにビュー「03-All Topics by Attendee-with prompt」で SQL クエリーを修正する必要があります。

ビューの説明

メインのアプリケーション EVENTS.NSF には、図 A2 に示すビューが含まれています。ビューには、ここで説明したシナリオに対応する番号が付けられています。

EVENTS2007.NSF には、これらのビューのサブセットが含まれています。

追記

• 00 のビューは、レコードの検索を容易にする標準 NSF ビューです。
• 02a のビューは Events フォームで埋め込みビューとして使用されます。メイン・ナビゲーターから選択されたとき、最初はこれらのビューは空ですが、ユーザーがイベント文書を開いた後は、イベントに関連する参加者とトピックが表示されます。通常、これらのビューは明らかに非表示にされますが、判別しやすくするために表示されています。
• 02b のビューおよび 02c のビューは、それぞれトピック名と出席者名の入力を求めます。クエリーをできるだけシンプルにするために、これらは大文字と小文字が区別される検索となっています。
• 02d のビューは、Lotus Notes クライアントでは空で表示されます。しかし、HTTP を介してアプリケーションにアクセスし、シナリオで示したような URL を使用すると、Web ブラウザーにビューが生成されます。

補足（2009年11月）

上に戻る

ダウンロード

	ダウンロード形式について

参考文献

• developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
  
  
• developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです
  
  
• Participate in the discussion forum(US)
  
  
• Read the developerWorks® Lotus article, “Exploiting IBM DB2 in your Lotus Domino 7 application(US).” The information included in this article is still valid for Lotus Domino 8.
  
  
• Read the developerWorks Lotus article, “IBM Lotus Domino with IBM DB2 storage for Lotus Notes mail users(US).” 日本語版: 「IBM DB2対応IBM Lotus Dominoを使ったLotus Notesメールのパフォーマンス」
  
  
• Read the IBM white paper, “IBM — Improving Domino and DB2 performance(US).”
  
  
• Refer to the IBM Lotus Notes and Domino Information Center(US).
  
  
• Refer to the IBM DB2 Information Center.

著者について

		Karen Brent has worked for IBM in the United Kingdom for nine years, initially in the Lotus services organization, where she assisted customers in designing, deploying, and managing Lotus Notes and Domino architectures. Curently, she is a Lotus Early Program Manager on the BetaWorks team, where she supports beta customers in deploying beta and early software, provides the development teams with feedback, and contributes to early enablement activities for the technical sales and services teams.

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る