物理インスタンス・リスト

物理インスタンス・リスト

開発者にとっては、インスタンス・リストのデータ実体がどのように格納、処理されるか、理解しておくと役立つかも知れません。

そこで、インスタンス・リストの物理的実装について、基本的な事項をいくつか説明しておきましょう(既述の「プログラム的識別子」も参照)。

·         インスタンス・リストの各エントリーには、英数字型の識別子、数値型の識別子をそれぞれ5つまで使って定義、アクセスするようになっています。通常はこれを、AKey1〜AKey5、NKey1〜NKey5と表します。

·         インスタンス・エントリーを一意に識別する複合キーは、「AKey1-NKey1-AKey2-NKey2-AKey3-NKey3-AKey4-NKey5-AKey5-NKey5」という形になります。

·         インスタンス・リストの各エントリーには、このような10の部分から成るキーがあります。すべての部分を指定しない場合でも同じです。例に使っているインスタンス・リストにSECTIONSを追加する場合、通常はAKey1(#DEPTMENT)とAKey2(#SECTION)のみを指定します。この場合、AKey3(' ')〜AKey5(' ')、NKey1(0)〜NKey5(0)をデフォルト値として仮定し、10の部分から成るキーが指定されたものとして扱います。

·         AKeyN()の実際の値として空白(' ')、NKeyN()の実際の値として0を与えると、デフォルト値が使われた場合と区別がつかず、問題が生じる可能性があります。したがって、空白や0を実際には空白や0ではないキー値として論理的に表すには、「AKey4('<BLANK>')」や「NKey2(-9999)」を使用するなど、何らかの工夫をしなければなりません。

·         AKeyn()やNKeyn()に与える値について、特にこうしなければならないというようなことはなく、組み合わせ方は自由に決めて構いません。識別のために英数字キーが6つ以上必要であれば、いくつかを連結した文字列を1つのキーとして扱うとよいでしょう。例えばSECTIONS-EMPLOYEESインスタンス・リストを、AKey1は「(#DEPTMENT + "." + #SECTION)」という形の連結文字列、AKey2は「(#EMPNO)」であるとして構成しても構わない、ということです。

付属のSECTIONSビジネス・オブジェクトでは、AKey1 = 部門コード(Department Code)、AKey2 = 部課コード(Section Code)という規約になっています。

また、EMPLOYEESビジネス・オブジェクトでは、AKey1 = 部門コード(Department Code), AKey2 = 部課コード(Section Code)、AKey3 = 従業員番号(Employee Number)と定義されています。

したがって、SECTIONとEMPLOYEEの間には、キーの構成に基づく親子関係があることになります。

SECTIONSとEMPLOYEESのインスタンス・リストは、物理的にはっきり分離して格納されているわけではなく、例えば次のように混在しています。

親子関係にあるSECTIONSとEMPLOYEESのインスタンス・リストを適切に処理し、Visual LANSAのツリー・コントロールに表示できるようにするためには、このように関連を持ったキー構成が不可欠です。「親子関係を表すキー構成」も参照してください。

物理インスタンス・リストについては、次のような事項も頭に入れておくとよいでしょう。

·         インスタンス・リストにエントリーを追加する順序は決まっていない

·         「必要になった時点で」動的にインスタンス・リストに子を追加していっても構わない

·         インスタンス・リスト上の子オブジェクトには親がなければならない

·         親子関係があるインスタンス・リストの各エントリーを、ツリー表示を折りたたむことなく、動的に更新できる

·         親子関係があるインスタンス・リストの各エントリーを、ツリー表示を折りたたむことなく、動的に削除できる

·         親子関係があるインスタンス・リストの各エントリーを、ツリー表示を折りたたむことなく、動的に追加できる