Page History
事前結合列(PJC: Predetermined Join Column)は、LANSAリポジトリならではの機能です。これは仮想列の一種です(「仮想列の考え方」を参照」を参照)。リポジトリ内の他のタイプの仮想テーブルと異なり、事前結合列は、ある値または別テーブルの値をもとにして求められる仮想列です。（その他の仮想列は常に自身のテーブル定義内の列から派生します。）派生元である他のテーブルとの関係は、アクセス経路の形で表します。
...
派生元列の値に対して適用できる演算は、アクセス経路として設定された関係が1対1か1対多かによって異なります。
1対多の関係 (アクセス経路の「アクセス経路の「最大レコード」を参照」を参照) であれば、TOTAL、MAXIMUM、MINIMUM、AVERAGE、COUNTの演算が適用できます(『LANSA テクニカル リファレンスガイド』の「結合タイプ」も参照リファレンスガイド』の「結合タイプ」も参照)。
一方、1対1の関係であれば、事前結合列の値を「LOOKUP」とすることにより、対応する値を検索して値を求める旨を指定したことになります。例えば、注文明細テーブルから製品テーブルに対するアクセス経路が定義されていれば、製品コードをキーとして製品の詳細説明を検索できます。ここで 保管数 を指定しておけば、最新の検索結果がキャッシュされるため、入出力の負荷を軽減できます。
1対多の関係であれば、アクセス経路に定義されたキーにより検索した複数のレコードに対し、所定の演算を施した結果が事前結合列に入ります。例えば、注文の明細行テーブルから金額を検索し、その合計値を求めて頭書きの「合計」欄に表示する、といった使い方ができます。
事前結合列に対して定義したアクセス経路には、保管数 、結合列設定 という属性を設定できます。どちらもアクセス経路上の事前結合列すべてに適用されます。
...
- コード・テーブルから説明記述を検索するような状況で、テーブルの実体が高速テーブルである場合、事前結合列は効率的に使えます。しかし使用頻度が過大になると、逆効果になる場合があります。特に、テーブルの実体が高速テーブルでない場合の、DBOPTIMISEDファンクションではそうなります。
- おおよその指針として、事前結合列の結合元テーブルは、多くても10～15程度にとどめてください。
次のトピックも参照してください。