物理インスタンスリスト

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

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

• インスタンスリストの各エントリーには、英数字型の識別子、数値型の識別子をそれぞれ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のインスタンスリストは、物理的にはっきり分離して格納されているわけではなく、例えば次のように混在しています。
 

インスタンスリストを適切に処理し、Visual LANSAのツリー・コントロールに表示できるようにするためには、この SECTIONS と EMPLOYEES 間のキー構造リレーションは不可欠です。  「親子リレーションの計画 (VLF-WIN の場合)」も参照してください。

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

• インスタンスリストにエントリーを追加する順序は決まっていない
• オンデマンドでインスタンスリストに子を動的に追加
• インスタンスリストの子オブジェクトには親が必要
• ツリー表示を折りたたむことなく親子インスタンスリストの各エントリーを動的に更新
• ツリー表示を折りたたむことなく親子インスタンスリストの各エントリーを動的に削除
• ツリー表示を折りたたむことなく親子インスタンスリストの各エントリーを動的に追加