ข้อจำกัดการตรวจสอบ (Check constraint)เป็นข้อจำกัดด้านความสมบูรณ์ของ ข้อมูล ประเภทหนึ่งในSQLซึ่งระบุข้อกำหนดที่แต่ละแถวในตาราง ฐานข้อมูลต้องปฏิบัติตาม ข้อจำกัดนั้นต้องเป็นเงื่อนไข (predicate ) โดยอาจอ้างอิงถึงคอลัมน์เดียวหรือหลายคอลัมน์ของตารางก็ได้ ผลลัพธ์ของเงื่อนไขอาจเป็น null TRUE, FALSEtrue หรือUNKNOWNfalse ขึ้นอยู่กับการมีค่าNULLหากเงื่อนไขประเมินค่าเป็น true UNKNOWNแสดงว่าไม่มีการละเมิดข้อจำกัด และสามารถแทรกหรืออัปเดตแถวในตารางได้ ซึ่งแตกต่างจากเงื่อนไขในWHEREคำสั่ง SQL SELECTทั่วไปUPDATE

ตัวอย่างเช่น ในตารางที่ประกอบด้วยผลิตภัณฑ์ เราสามารถเพิ่มเงื่อนไขตรวจสอบเพื่อให้ราคาและปริมาณของผลิตภัณฑ์ต้องเป็นค่าที่ไม่ติดลบได้:

ราคา >= 0 

ปริมาณ >= 0 

หากไม่มีข้อจำกัดเหล่านี้ ราคาสินค้าอาจติดลบได้ (−30 ดอลลาร์) หรือปริมาณสินค้าอาจติดลบได้ (−3 ชิ้น)

ข้อจำกัดการตรวจสอบ (Check constraints) ใช้เพื่อตรวจสอบความถูกต้องของข้อมูลในฐานข้อมูลและเพื่อให้เกิดความสมบูรณ์ของข้อมูลหากใช้ข้อจำกัดเหล่านี้ในระดับฐานข้อมูล แอปพลิเคชันที่ใช้ฐานข้อมูลจะไม่สามารถเพิ่มข้อมูลที่ไม่ถูกต้องหรือแก้ไขข้อมูลที่ถูกต้องจนทำให้ข้อมูลนั้นไม่ถูกต้องได้ แม้ว่าตัวแอปพลิเคชันเองจะยอมรับข้อมูลที่ไม่ถูกต้องก็ตาม

ข้อจำกัดการตรวจสอบแต่ละข้อจะต้องถูกกำหนดไว้ใน คำสั่ง CREATE TABLEOR ALTER TABLEโดยใช้ไวยากรณ์ดังนี้:

สร้างตารางชื่อ table_name ( ... ข้อจำกัดconstraint_name CHECK ( predicate ), ... ) 

ALTER TABLE table_name ADD CONSTRAINT constraint_name CHECK ( predicate ) 

หากข้อจำกัดการตรวจสอบอ้างอิงถึงคอลัมน์เดียวเท่านั้น ก็สามารถระบุข้อจำกัดนั้นเป็นส่วนหนึ่งของคำจำกัดความของคอลัมน์ได้

สร้างตารางชื่อ table_name ( ... ชื่อคอลัมน์ประเภท CHECK ( เงื่อนไข ) ... ) 

ข้อจำกัดดังกล่าวมีฟังก์ชันการทำงานเทียบเท่ากับข้อจำกัดการตรวจสอบต่อไปนี้ที่มีภาคแสดง: NOT NULLIS NOT NULL

ตรวจสอบ ( คอลัมน์ต้องไม่เป็นค่าว่าง) 

ระบบจัดการฐานข้อมูลเชิงสัมพันธ์บางระบบสามารถเพิ่มประสิทธิภาพได้เมื่อNOT NULLใช้ไวยากรณ์ข้อจำกัดแทนCHECKไวยากรณ์ข้อจำกัดที่ระบุไว้ข้างต้น^{[ 1 ]}

ระบบจัดการฐานข้อมูลส่วนใหญ่จำกัดข้อจำกัดการตรวจสอบไว้ที่แถวเดียว โดยอนุญาตให้เข้าถึงค่าคงที่และฟังก์ชันที่กำหนดได้ แต่ไม่ สามารถ เข้าถึงข้อมูลในตารางอื่น หรือข้อมูลที่มองไม่เห็นในธุรกรรมปัจจุบันเนื่องจากการแยกธุรกรรม

ข้อจำกัดดังกล่าวไม่ใช่ข้อจำกัดการตรวจสอบตาราง อย่างแท้จริง แต่เป็นข้อจำกัดการตรวจสอบแถวเนื่องจากโดยทั่วไปแล้วข้อจำกัดเหล่านี้จะได้รับการตรวจสอบก็ต่อเมื่อมีการอัปเดตแถวโดยตรงเท่านั้น (ด้วยเหตุผลด้านประสิทธิภาพ) และมักถูกนำไปใช้ในลักษณะโดยนัยINSERTหรือUPDATEเป็นตัวกระตุ้น ดังนั้นข้อจำกัดด้านความสมบูรณ์อาจถูกละเมิดได้จากการกระทำทางอ้อมหากไม่มีข้อจำกัดเหล่านี้ นอกจากนี้ การแก้ไขข้อมูลที่ถูกต้องตามปกติก็จะถูกป้องกันโดยCHECKข้อจำกัดดังกล่าว ตัวอย่างของข้อจำกัดที่เป็นอันตราย ได้แก่:

• CHECK((selectcount(*)frominvoiceswhereinvoices.customerId=customerId)<1000)
• CHECK(dateInserted=CURRENT_DATE)
• CHECK(countItems=RAND())

สามารถใช้ ทริกเกอร์ที่ผู้ใช้กำหนดเองเพื่อหลีกเลี่ยงข้อจำกัดเหล่านี้ได้ แม้ว่าการใช้งานจะคล้ายคลึงกัน แต่ในเชิงความหมายแล้ว ทริกเกอร์จะทำงานก็ต่อเมื่อมีการแก้ไขตารางโดยตรงเท่านั้น และเป็นความรับผิดชอบของผู้ออกแบบที่จะจัดการกับการเปลี่ยนแปลงทางอ้อมที่สำคัญในตารางอื่น ๆ ในทางกลับกัน ข้อจำกัดนั้นมีจุดประสงค์เพื่อให้ "เป็นจริงตลอดเวลา" โดยไม่คำนึงถึงการกระทำของผู้ใช้หรือการขาดวิสัยทัศน์ของผู้ออกแบบ