Page History

標準を定める目的は、アプリケーション・データベースの一貫性を保証し、開発したリポジトリが長期間にわたって活用されるようにすることです。社内開発の場合、テーブル名は次のように標準化するとよいでしょう(一般販売用のパッケージ開発の場合は別)。

テーブル名は「xxxxxxnn」という形式で、次の規則に従うものとします。

• 物理テーブル名は6字以内で、「#」や「@」を含まない。

• 「xxxxxx」の部分は、1 から 6 文字以内という制限の中で、できるだけ意味をよく表す文字列とする。例えば、次のようになります。CUSTMR - 顧客マスター、SALEHS - 販売履歴。

• テーブル名は全体で8文字以内とする。

• インデックス名は、ベースとなるテーブル名「xxxxxx」の部分に順序番号「nn」を追加したものとする。例：CUSTMR01、CUSTMR02、CUSTMR03。

• インデックス名を決める際、番号「nn」の順序には意味を持たせない (テーブル数がある程度以上になると、一貫した番号づけはほとんど不可能になるため)。

『LANSA テクニカル リファレンスガイド』の「LANSA オブジェクト名」を参照をしてください。

[ Image Removed |../../index.htm#lansa/l4wdev01_0065.htm]
現在地:

...

LANSA Client はエンド・ユーザー用のクエリー/レポート作成ツールです。これを使用する場合、LANSA リポジトリのテーブル定義を開発して、LANSA クライアント・ユーザーをサポートすることが焦点となります。
最初にアプリケーション・データベースの作成を行いますが、これは通常、既存のテーブルをLANSAリポジトリにインポートすることで完了します。
特に重要な作業としては、アクセス経路の作成があります。さらに、仮想列の作成や、場合によっては事前結合列の作成を、リポジトリ側で行う必要があります。
リポジトリの開発が終われば、LANSA Client を使って、実際にクエリー処理やレポート作成ができるようになります。
次のトピックも参照してください。
LANSA Client ユーザーガイド
LANSA Client 管理者ガイド
[ Image Removed |../../index.htm#lansa/l4wdev01_0065.htm]