قاعده‌ی ارزیابی برای کنترل صحت داده‌های وارد‌شده به داخل یک فیلد از جدول، مورد استفاده قرار می‌گیرد. این قاعده با برقراری شرایط روی تعدادی از فیلد‌های یک جدول، همانند یک سد محافظ عمل می‌کند. این قاعده با عبارت CHECK تعریف می‌شود.
مثال:
CREATE TABLE T3(ID NUMBER, NAME VARCHAR2(20), PHONE VARCHAR2(20), CONSTRAINT HOOHOO CHECK(PHONE LIKE '0__________'));
در این جدول دیگر نمی‌توان در فیلد PHONE هر داده‌ای را وارد کرد و حتماً باید با فرمت صحیح داده را وارد کرد تا درج اطلاعات انجام بشه:
INSERT INTO T3 VALUES(1, 'MAHDI', '091212312');
*
ERROR at line 1:
ORA-02290: CHECK CONSTRAINT (MGHAFFARI.HOOHOO) violated'
INSERT INTO T3 VALUES(1, 'MAHDI', '09121231234');
نکته: قاعده CHECK بار پردازشی بسیار زیادی بر روی دیتابیس اعمال می‌کند.
نکته: VALIDATION در سطح اپلیکیشن حتماً باید انجام شود و نباید این بار فقط در سمت دیتابیس باشد (اگر VALIDATION سمت اپلیکیشن انجام نشود و منتظر EXEPTION از سمت دیتابیس باشیم باید بار TRANSACTION در سطح دیتابیس را بپذیریم، باید هزینه CONNACTION بر روی دیتابیس را بدیم، باید هزینه ROLLBACK TRANSACTION را نیز بدیم، ساختار CHECK هم که در اصل پشتش یک TRIGGER خوابیده و بار LISTENER روی دیتابیس میندازه پس این بار رو هم باید هزینه کنیم، در نهایت بار برگشت EXEPTION را هم باید به سطح اپلیکیشن هزینه کنیم که به کاربر آلارم بدیم اطلاعات وارد شده غلط است!!!)
نکته: تا جای ممکن از این قاعده استفاده نکنید، مگر زمانی که شما به ادمینتان یا یوزرهای کنسولیتان مطمئن نیستید. (برای اینکه یوزر مستقیم داره دیتا وارد میکنه و می‌خوایم از ورود اطلاعات UNVALID توسط یوزر جلوگیری کنیم) (زمانی که USER مستقیم با دیتابیس تعامل میکنه یعنی اپلیکیشن واسطی نداریم که اپلیکیشن خیلی از کارها رو به عهده بگیره و ممانعت کنه)
نکته: بدانید و آگاه باشید که هربار که شما INSERT ای انجام می‌دید چه ادمین انجام بده چه اپلیکیشن داره انجام میده یه بار ثانویه‌ای از بیرون داره رو دیتابیس می‌افته چون چه در بحث قاعده کلید خارجی چه در بحث قاعده CHECK در بحث قاعده خارجی خودش داره یه SELECT میزنه که ببینه داده وابسطه وجود داره یا نداره رو بحث قاعده CHECK هم هربار داره یه TRIGGERاجرا میشه و هر داده‌ای که INSERT میشه اونو چک میکنه بعد می‌خوابونه رو سطح دیتابیس
س: از کجا می‌توان به ساختار CONSTRAINT موجود پی‌برد؟
ج: با استفاده از DATA DICTONARY می‌توان به ساختار هر چیزی در اوراکل پی برد. DATA DICTONARY جداولی هستند که تمام ساختار دیتابیس را در خود نگهداری می‌کنند.
س: materialized view چیست؟
ج: materialized view به معنی آپدیت view در یک بازه زمانی مشخص مثلاً هر ۲۰ تراکنش یکبار است. به عنوان مثال: در سیستم‌های wearhouse می‌خواهیم هر ۲۴ ساعت یکبار ساعت ۱۲ شب view ما آپدیت بشه چون دیتایی که سمت wearhouseاست دیتای run time نیست و آرشیو داده مهمه و تو گزارش‌گیری‌ها و data miningها (data miningفقط روی داده‌های آفلاین انجام می‌شود نه روی داده‌های online چون روی داده‌های آنلاین صحت داده‌ای نداریم و تا بخوایم relationها را دربیاریم داده آپدیت شده) که از روی view انجام می‌شوند اطلاعات ۲۴ گذشته چندان مهم و تاثیر پذیر نیست.