ダイナミックトランザクションとは、物理テーブルと関連付けるのではなく、実行時にデータを照会する (GeneXus によってデータベースにビューが作成される) ために定義するトランザクションです。
この定義は極めて強力で、トランザクションフォームの実行だけではなく、For each コマンド、データプロバイダー、Web パネルや SD パネルのグリッドでベーストランザクションとして参照することで、クエリを自由に定義できる柔軟性を備えています。加えて、Work With for Web および Work With for Smart Devicesパターンをダイナミックトランザクションに適用することもできます。さらに、ダイナミックトランザクションに物理テーブルや物理フィールドが関連付けられているかどうかに関係なく、これらのトランザクションの項目属性を printblock や条件などで標準の項目属性として透過的に使用することもできます。
トランザクションをダイナミックに設定するには、オブジェクトプロパティを次のように設定します:
- Data Provider = True
- Used To = Retrieve Data
[ Data Provider ] プロパティを True に設定すると、TransactionName_DataProvider という名前のデータプロバイダーが自動的に作成され、そのソースがトランザクションの構造に初期化されます。ダイナミックトランザクションの項目属性にロードする必要があるデータを定義する際には、初期化されたソースにデータを入力するだけで済みます。
[ Used To ] を [ Retrieve Data ] に設定すると、トランザクションがダイナミックであることが GeneXus に認識されます。そのため、該当するトランザクションに関連付けられた物理テーブルが作成されることはありません。代わりに、データベースにビューが作成されます。
製品の販売とサービスの提供を行う会社について考えます。自動車会社など、さまざまな会社が考えられます。
次に示すように、2 つのトランザクションを定義します: この Product と Service はそれぞれ製品とサービスを記録するためのものです。
Product
{
ProductId*
ProductDescription
ProductStock
ProductExpirationDate
}
Service
{
ServiceId*
ServiceDescription
ServiceHoursDuration
}
1 つの会社が製品とサービスを販売するという状況は、さまざまな方法でモデル化できます。この例では、2 つの独立したトランザクションを定義して、2 つの異なる概念を扱うように設計しています。
目的は、どの情報が必要かにかかわらず、すべての製品とサービスのあらゆるデータを 1 つにまとめることです。たとえば、会社が提供しているすべてのもの (製品とサービスの両方) をアルファベット順にリストします。
ここでは、データを簡単に結合するためのアプローチとして、次のように SaleItem というダイナミックトランザクションを定義します:
SaleItem
{
SaleItemId*
SaleItemType*
SaleItemDescription
}
SaleItem トランザクションのキーは複合キーであることに注目してください。このように定義した理由は、すべての製品のデータとすべてのサービスのデータを項目属性にロードする必要があるためです。したがって、同じ識別子の値を持つ製品とサービスが共存できるように、各販売アイテムには複合キー (SaleItemId*、SaleItemType*) を使用しており、SaleItemType ではキーの一部として P (製品) および S (サービス) を割り当てることができます。
その後、SaleItem トランザクションのプロパティを次のように設定します:
- Data Provider = True
- Used To = Retrieve Data
これにより、トランザクションに関連付けられた物理テーブルを作成する必要がないことが GeneXus に認識されます。また、SaleItem_DataProvider という名前のデータプロバイダーが作成され、そのソースがトランザクションの構造に初期化されます:
次に、SaleItem トランザクションの項目属性にロードする必要があるデータをこのデータプロバイダーに入力します:
上のデータプロバイダーでは、既定で用意されているコードブロックをコピー アンド ペーストしています。1 つ目のコード構造では、すべての製品を取得し、販売アイテムとして割り当てています。2 つ目のコード構造では、すべてのサービスを取得し、販売アイテムとして割り当てています。SaleItem トランザクションをそれに関連付けられたデータプロバイダーを使用してモデル化すると、トランザクションに対する各種処理が可能になります。つまり、通常どおり、フォームを実行したり、すべての販売アイテムを表示したり、トランザクションを <base Transaction> として参照したり、その項目属性を他のオブジェクトで自然に使用したりできます。
次のプロシージャーは、自動車会社が提供するすべての販売アイテムをアルファベット順に出力するものです。SaleItem トランザクションがダイナミックであるにもかかわらず、すべての概念が通常どおり使用されています。
前述のとおり、ダイナミックトランザクションの項目属性を使用して Web パネルを定義したり、すべての GeneXus 機能を自然に適用したりすることができます。
次に、例として自動車会社が期待する要件を考えます: その要件とは、請求書の入力フォームのグリッドを 1 つだけにすることです。つまり、グリッドを 2 つに分けて、製品とサービスそれぞれにグリッドを使用する必要はありません。これについては、ダイナミックトランザクションの主キー (この例では SaleItemId*、SaleItemType*) は別のトランザクションの外部キー (この例では請求書の明細行) として使用できるため、問題なくモデル化できます:
Invoice
{
InvoiceId*
InvoiceDate
CustomerId
CustomerName
Line
{
SaleItemId*
SaleItemType*
SaleItemDescription
InvoiceLineQuantity
}
}
次の図は、Invoice トランザクションの実行時のフォームを示しています。グリッドには 4 つの販売アイテム (3 つのサービスと 1 つの製品) が含まれています。販売アイテムの選択リストを参照することもできます。
注: 製品とサービスの価格に関する課題については、ここでは解決しません。製品とサービスの価格は、それぞれ日付別に記録され、請求書に取り込まれるものと考えてください。
- ローカルソリューションを定義する代わりに、トランザクション/項目属性のパラダイムを利用できるという利点があります。たとえば、SDT、データプロバイダー、プロシージャーで扱ったり、複数のオブジェクトまたはデータセレクターで同じフィルタを定義したりできます。つまり、トランザクションは、ナレッジベース内でグローバルかつ強力な定義となります。したがって、概念が存在する場合は、ダイナミックトランザクションを定義して表すことができ (データベースに物理テーブルではなくビューが作成される)、それをいつもどおりに使用できます。
- 実際の状況や意図を柔軟に記述できます。
- プログラミングが容易になります。
- ダイナミックトランザクションが動的でなくなると、次のデータベース影響分析で再編成が行われます。空ではない物理テーブルが作成される一方で、ビューが実行され、その実行結果を使用して新しい物理テーブルが初期化されます(注: パラメーターを受け取るダイナミックトランザクションではこの処理は行われません)。
- ダイナミックトランザクションは、ナレッジベース内に並行トランザクションを持つことはできません。つまり、トランザクションをダイナミックとして定義するためには、そのトランザクションの主キーがほかのトランザクションと異なるものでなければならないという要件があります。
- すべてのトランザクションをダイナミックトランザクションとして定義できるわけではありません。いくつかの制約があります: データ プロバイダー クエリは、ビューで表すことができます。これに該当しない場合、仕様によりエラーが報告されます。
- ダイナミックトランザクションに関連付けられたデータプロバイダーでは、変数を使用できません。サーバーで評価できない関数についても同様です。
GeneXus は、これらのトランザクションで使用する SQL ビューを作成します。通常、DBMS はさまざまな最適化戦略を駆使して、良好なパフォーマンスを確保します。
|