OceanBaseデータベースがいつ制約チェック（Checking of Constraint）を実行するかを理解することは、さまざまな制約が存在する場合に許可される操作タイプを明確にするのに役立ちます。
以下の図に示すように、emp テーブルを定義します。emp テーブルに自己参照制約（Self-Referential Constraint）を定義し、mgr 列の値は empno 列の値に依存します。例を簡略化するため、以下では emp テーブルの empno (employee_id) 列と mgr (manager_id) 列のみについて説明します。
次に、emp テーブルに最初のデータを挿入します。この時点でテーブル内にデータがないため、mgr 列は empno 列の既存の値を参照できません。以下のシナリオに従ってデータ挿入を実行できます：
mgr列にNOT NULL制約が定義されていない場合、最初の行のmgr列にNULL値を入力できます。外部キー制約はNULL値を許容するため、この行はテーブルに正常に挿入されます。最初の行の
empno列とmgr列に同じ値を入力できます。この場合、制約チェック（Constraint Checking）はステートメントの実行後に実行されます。最初の行の親キー（Parent Key）と外部キー（Foreign Key）に同じ値を挿入する場合、まずステートメント（データ行の挿入）を実行し、その後、この行のデータのmgr列の値がテーブル内のどのempno列の値とも一致するかをチェックする必要があります。複数行の
INSERTステートメントを実行する場合、例えばSELECTステートメントと組み合わせたINSERTステートメントでは、相互参照関係にある複数行のデータが挿入されます。例えば、最初の行のempno列の値は200、mgr列の値は300、2行目のempno列の値は300、mgr列の値は200になります。
この場合も、データベースは制約チェックをステートメントの実行終了まで遅延させます。すべてのデータ行が先に挿入され、その後、各行ごとに制約違反がないかチェックされます。
上記の自己参照制約を使って、もう一つ例を挙げます。会社が買収され、すべての従業員番号を現在の値に5000を加算して更新する必要があるとします。これは新しい会社の従業員番号と一致させるためです。マネージャー番号も従業員番号であるため、この値も5000加算する必要があります。下の図は更新前の emp テーブルで、empno と mgr の2列が含まれています。empno 列には3つの値：210、211、212があります。mgr 列には2つの値：210、211があります。
emp テーブルに以下のSQLを実行します：
UPDATE EMP
SET empno = empno + 5000,
mgr = mgr + 5000;
emp テーブルに定義された制約では、各 mgr 値が empno 値と一致する必要がありますが、このステートメントは実行可能です。なぜなら、制約チェックはステートメントの実行後に行われるからです。下の図は、SQLステートメントのすべての操作が完了した後に制約チェックが行われることを示しています。
まず各従業員番号に5000を加算し、次に各マネージャー番号に5000を加算します。最初のステップでは、empno 列の値210が5210に更新されます。2番目のステップでは、empno 列の値211が5211に更新され、mgr 列の値210が5210に更新されます。3番目のステップでは、empno 列の値212が5212に更新され、mgr 列の値211が5211に更新されます。最後に制約チェックが実行されます。
上記の例は、INSERT および UPDATE ステートメントの制約チェックメカニズムを示しています。実際、UPDATE、INSERT、DELETE などの各種DMLステートメントの制約チェックメカニズムは同じです。