識別列を使用すると、重複に関する2種類の問題が発生します。
- 重複識別列値
- 故意でない重複行
GENERATED ALWAYS ... NO CYCLEを使用して列が指定されるときにのみ、その他の制約がなければ識別列の値の固有性が保証されます。
重複識別列値は、以下のいずれかの状況で発生する可能性があります。
- 列がGENERATED ALWAYSに指定されるが、CYCLEオプションが指定される場合。
この場合、列は最大値または最小値に到達したとき、以前に生成された値の再利用が始まります。
- 列がGENERATED BY DEFAULTに指定され、アプリケーションがその列に重複値を指定する場合。
重複行は、以下のいずれかの状況で発生する可能性があります。
- 以前に完了したロード タスクが誤って再実行される場合。
識別列を持たないものの、SETテーブルとして指定されているか1つ以上の固有インデックスを持つテーブルでは、重複行の挿入は許可されません。
- Teradata Parallel Data Pumpが、ROBUSTオプションを使用可能にしないで実行され、再始動される場合。
- セッションがアボートしますが、アボートが発生する前に挿入された行が、セッションが手動で再始動されるまで削除されない場合。
多くの場合、そのような行は、リレーショナル モデルで定義されている意味での重複行ではありません。例えば、ロード タスクを誤って複数回実行した場合でも、新しく生成される行は厳密なリレーショナルの定義では重複行とは見なされません。たとえその行が同じクライアントの行であっても(サーバー上で固有性確保のために定義されている識別列値を指定していなければ)、その行は、サーバー上で異なる識別列値を持つことになり、したがって、それぞれは重複ではないことになるからです。
例えば、Reiko Kawabataという従業員名を従業員テーブルemployeeに間違って2度ロードしたとします。従業員番号列employee_numberが識別列です。この場合、employee_numberの値が異なる以外はまったく同一の2つの従業員行が存在することになります。これは企業の観点からすればエラーですが、この2つの行ではemployee_numberの値が異なっているため、これは重複ない。これは、機能の問題ではありません。これは設計どおりの動作だからです。
したがって、この種のあいまいな重複によってデータベースが破壊されないようにするためには、それぞれのシステムで識別列テーブルを処理するための厳格なガイドラインを施行する必要があります。