経験則として、必要な場合以外はサブタイプを使用しないでください。

GeneXus では、Universal Relation Assumption (URA) を採用しています。URA では、1 つの項目属性の名前は、どの場所においても同じであると仮定します。たとえば、お客様の番号は、Customer トランザクションでも Invoice トランザクションでも CustomerId です。ただし、次の場合、URA は使用できません。

• 同じトランザクションに複数のリレーションシップ

• 自己参照

• 不要な整合性制約

• 継承

したがって、上記の場合には、Subtype Group オブジェクトを使用することが必須となります。

同じトランザクションに複数のリレーションシップ

標準的な例としては、Airport (空港) トランザクションと Flight (フライト) トランザクション間のリレーションシップが考えられます。Flight トランザクションには、Airport トランザクションとの間に、出発空港 (Departure Airport) および到着空港 (Arrival Airport) を定義する 2 種類のリレーションシップがあります。この場合のモデルは以下のようになります:

Airport
{
  AirportId*
  AirportName
}

Flight
{
  FlightId*
  DepartureAirportId
  DepartureAirportName
  ArrivalAirportId
  ArrivalAirportName
}

Departure Subtype Group
  DepartureAirportId   subtype of AirportId
  DepartureAirportName subtype of AirportName

Arrival Subtype Group
  ArrivalAirportId     subtype of AirportId
  ArrivalAirportName   subtype of AirportName

サブタイプを使用しなくても済む、以下のような代案のデザインも考えられます:

Airport
{
  AirportId*
  AirportName
}

Flight
{
  FlightId*
  {
      FlightAirportType* (Arrival or Departure)
      AirportId
      AirportName
  }
}

このデザインは、一般的にはあまり使用されません。おそらく、両方の空港を同時に検索するという点で難易度が上がることが原因と考えられます。

自己参照

社員 1 人につき、上司は 1 人だけという旧来型の体制の企業を考えてみましょう。この場合のモデルは以下のようになります:

Employee
{
  EmployeeId*
  EmployeeName
  ManagerId
  ManagerName
}

Subtype Group: Manager 
  ManagerId      subtype of   EmployeeId
  ManagerName    subtype of   EmployeeName

不要な整合性制約

株式情報追跡用の以下のオンライン ブローカー モデルを考えてみましょう:

Account
{
  AccountId*
  AccountName
}

Stock
{
  StockId*
  StockName
}

Trade
{
  TradeId*
  TradeTime
  AccountId
  AccountName
  StockId
  StockName
  TradeType  (buy or sell)
  TradeQuantity
  TradePrice
}

この Trade トランザクションは、あるアカウントで売買した株式銘柄をすべて記録します。ここで、アカウントで定期的にチェックしておきたい株式銘柄を登録する 'Watch List (注目銘柄一覧)' 機能を追加することにしましょう。一見すると、この機能は次のトランザクションで実装できるように思えます:

BadWatchList 
{
  AccountId*
  AccountName
  StockId*
  StockName
}

このトランザクションの問題点は、Trade ベーステーブルと BadWatchList との間に整合性制約がある点です。つまり、該当アカウントでは、Watch List に登録されている銘柄しか取引できないことになります。この事態は望ましくないため、訂正して以下のような Watch List トランザクションを使用します:

WatchList
{
  AccountId*
  AccountName
  WatchListStockId*
  WatchListStockName
}

Subtype Group: WatchListStock 
  WatchListStockId      subtype of   StockId
  WatchListStockName    subtype of   StockName

おそらく、このケースは次のように考えると、もっと直観的で分かりやすいでしょう。あるアカウントについて、売買したことのある銘柄と、常に注目している銘柄の 2 種類の株式銘柄を追跡する必要があるとします。この 2 種類の銘柄情報には関係がないため (Watch List に未登録の銘柄を売買することも、取引履歴のない銘柄に注目することも可能)、これらの銘柄情報にはそれぞれ別々の名前 (サブタイプ) が必要になります。

継承

人物 (People)、学生 (Student)、社員 (Employee) に関する情報を保存する必要があるとします。ポイントは、学生は全員人物でもあるし、社員も全員人物であるという点です。この状況をモデル化する一番の方法は、学生 (Student) と社員 (Employee) のサブタイプを定義することです:

Person
{
  PersonId*
  PersonName
}

Student
{
  StudentId*
  StudentName
  StudentUniversity
}

Subtype Group: Student 
  StudentId      subtype of   PersonId
  StudentName    subtype of   PersonName

Employee
{
  EmployeeId*
  EmployeeName
  EmployeeDateOfHire
}

Subtype Group: Employee 
  EmployeeId      subtype of   PersonId
  EmployeeName    subtype of   PersonName

「People And Organizations Knowledge Base」では、このケースの好例を紹介しています。

詳細については、「Types of Inheritance」を参照してください。
ファイルのダウンロード