推測されたスキーマ - Parallel Transporter

例1

次の例を考えてみましょう。

   STEP LOAD_2
   (
     APPLY  <DML statement(s)>

     TO OPERATOR( $INSERTER() )

     SELECT * FROM OPERATOR( $EXPORT() )

     UNION ALL

     SELECT * FROM OPERATOR( EXPORT_OPER2() );
   );

スクリプト定義のProducerオペレータEXPORT_OPER_2は、スクリプト定義スキーマ名のスキーマ指定を使用して、ジョブ スクリプトで先に定義しておく必要があります。 EXPORT_OPER_2によって抽出されるソース データは、プロデューサ テンプレート オペレータ$EXPORTによって抽出されるソース データとともに単一の入力データ ストリームにマージされます。このため、Teradata PTは両方のProducerオペレータのスキーマが同じであると推測し、ジョブ スクリプトにインポートする$EXPORTテンプレートのコピーでEXPORT_OPER_2のスキーマの名前を使用することができます。

例2

この例では、$EXPORTプロデューサ テンプレートのスキーマを生成するための基準としてSQL SELECT文が推測されます。

   STEP INSERT_DAILY_TRANS
   (
     APPLY  <DML statement(s)>

     TO OPERATOR( $INSERTER() )

     SELECT *

     FROM OPERATOR
     (
       $EXPORT()
       ATTR
       (
         PrivateLogName = 'daily_trans.log',
         SelectStmt     = 'Select * from Daily_Trans;'
       )
     );
   );

上記のジョブ ステップでは、$EXPORTテンプレートのSelectStmt属性には、値Select * from Daily_Trans (属性の定義に基づきSQL SELECT文でなければならない)が割り当てられています。SELECT文の結果テーブルの列には、テンプレート$EXPORTを介して呼び出したExportオペレータによって生成されるソース データが正確に記述されているため、Teradata PTは、Teradata Databaseを問合わせることによって、SELECT文の結果テーブルの列に基づいてスキーマを生成できます。

SelectStmtの値で生成されたスキーマを基準として、属性はプロデューサ テンプレート$EXPORTと$SELECTORで有効になります。これは、これらの基本オペレータの両方がこの属性を必要とするためです。

例3

この例では、Teradata PTはジョブ ステップに含まれるConsumerオペレータのターゲット テーブルのIDを確認し、このテーブルを基準としているスキーマはジョブ ステップ内のプロデューサ テンプレートのスキーマを生成するための基準となると推測します。

   STEP INSERT_MONTHLY_SHIPMENTS
   (
     APPLY  <DML statement(s)>

     TO OPERATOR
     (
       $LOAD()
       ATTRIBUTES
       (
         PrivateLogName = 'monthly_ship.log',
         TargetTable    = 'Monthly_Shipments'
       )
     )

     SELECT * FROM OPERATOR( $FILE_READER() );
   );   

上記の例では、Teradata PTは$LOADオペレータ テンプレートのTargetTable属性から、このジョブ ステップでロードされるデータのターゲットがTeradata DatabaseテーブルMonthly_Shipmentsであることを判断できます。

プロデューサ テンプレートにスキーマのスクリプト指定がなく、このソース スキーマを生成するための基準となりえるスクリプト標識も存在しないため、Teradata PTはソース データが変更されずにターゲット テーブルにロードされると想定し、そのため、ターゲットのTeradata DatabaseテーブルがProducerオペレータ$FILE_READERのソース スキーマを生成する基準であると推測できます。

この想定は、ターゲット テーブルが単にTeradata PTに認識されているすべての場合で正しいとは限らないため、推測された一部のスキーマは、プロデューサ テンプレートのソース データを正確に表わさないことがあります。その結果、スキーマの不一致がTeradata PTによって検出され、ジョブが失敗します。これが推測されたスキーマの機能の限界です。プロデューサ テンプレートのスキーマがTeradata Databaseターゲット テーブルから正しく推測される場合、ソース データはTeradata PTからターゲットに変更されずに移動される必要があります。具体的には、 ターゲット列はソース列の射影ではなく、派生列も含まない場合があります。Teradata PTがそのプロデューサ テンプレートのスキーマを正しく推測できるようにプロデューサ テンプレート オペレータからの行を表わすことができるのは、SELECT *命令だけです。

ジョブ ステップに複数のターゲット テーブルが含まれる場合(複数のAPPLY機能を使用する構文など)と、ステップ ConsumerオペレータがUpdateオペレータ(または$UPDATEテンプレート)で、このオペレータによって複数のターゲット テーブルが更新される場合には、Teradata PTはターゲット テーブルのプロデューサ テンプレートのスキーマを推測しません。

Teradata PTがプロデューサ テンプレートのスキーマを推測するための基準がないジョブ ステップと、Teradata PTが不正なテンプレートのスキーマを推測する場合にスキーマ不一致エラーを生成するジョブ ステップは、次のセクションで説明しているように、特別なジョブ変数を使用して常に修正できます。