ここにあるのは、行間のテーブル制約です。つまり、単一のOracle CONSTRAINTを配置することはできません。 列上では、一度に1行内のデータしか表示できないためです。
Oracleは、一意性（主キーと一意性制約など）と参照整合性（外部キー）の2つの行間制約タイプのみをサポートしています。
あなたの場合、制約を自分で手動でコーディングする必要があります-それに伴い、他の同時セッションによって挿入/更新されたデータをそれぞれが見ることができない複数のセッションが存在する場合に制約に違反しないようにする責任があります（少なくとも、彼らがコミットするまで）。
単純なアプローチは、新しいレコードと競合するレコードの数をカウントするクエリを発行するトリガーを追加することです。ただし、他のセッションによって挿入/更新されたがまだコミットされていない行をトリガーが認識できないため、これは機能しません。そのため、（たとえば）2人のレジ係が別々の端末にデータを入力できる限り、トリガーによってメンバーが6本のビデオをレンタルできる場合があります。
片道 この問題を回避するには、シリアル化の要素をいくつか入れます。トリガーは、レンタルの確認を許可する前に、最初にメンバーレコードのロックを要求します（たとえば、SELECT FOR UPDATEを使用）。そうすれば、2番目のセッションがレンタルを挿入しようとすると、最初のセッションがコミットまたはロールバックを実行するまで待機します。
別の方法 この問題の回避策は、テストに失敗した行を見つけるように設計されたクエリに基づく集計マテリアライズドビューを使用することです。 MVが空になることが予想され、MVにテーブル制約を設定して、行がMVに表示された場合に、制約に違反するようにします。これにより、制約に違反する行を挿入しようとするステートメントは、MVが更新されたときに制約違反を引き起こします。
あなたのデザインに基づいてこれに対するクエリを書くことは、読者のための練習として残されています:)