View Source

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

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

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

ビジネス・オブジェクトの型	AKey1	AKey2	AKey3	Visual ID1	Visual ID2
SECTIONS	ADM	01		ADM	01
EMPLOYEES	ADM	01	A1001	A1001	BEN JONES
EMPLOYEES	ADM	01	A1012	A1012	PATRICK PAUL
SECTIONS	ADM	02		ADM	02
EMPLOYEES	ADM	02	A0090	A0090	FRED BLOOGS
EMPLOYEES	ADM	02	A1014	A1014	JOHN MOORE
SECTIONS	LEG	01		LEG	01
EMPLOYEES	LEG	01	A1019	A1019	CHARLES DICKENS
など

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

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