تحقق من القيد

قيد التحقق هو نوع من قيود التكامل في لغة SQL، يحدد شرطًا يجب أن يستوفيه كل صف في جدول قاعدة البيانات . يجب أن يكون القيد شرطًا منطقيًا (predicate) . يمكن أن يشير إلى عمود واحد أو عدة أعمدة في الجدول. يمكن أن تكون نتيجة الشرط المنطقي إما فارغة TRUE(null FALSE) أو غير فارغة (null) أو غير قابلة للتغيير (true)، UNKNOWNوذلك حسب وجود قيم فارغة (null) . إذا كانت نتيجة الشرط المنطقي فارغة UNKNOWN، فلن يتم انتهاك القيد، ويمكن إدراج الصف أو تحديثه في الجدول. هذا يختلف عن الشروط المنطقية في WHEREعبارات SQL SELECTأو UPDATEعبارات SQL.

على سبيل المثال، في جدول يحتوي على منتجات، يمكن إضافة قيد تحقق بحيث يكون سعر المنتج وكمية المنتج قيمة غير سالبة:

السعر ≥ 0

الكمية >= 0

إذا لم تكن هذه القيود موجودة، فسيكون من الممكن الحصول على سعر سلبي (-30 دولارًا) أو كمية سلبية (-3 عناصر).

تُستخدم قيود التحقق لضمان صحة البيانات في قاعدة البيانات وتوفير سلامتها . عند استخدامها على مستوى قاعدة البيانات، لن تتمكن التطبيقات التي تستخدم قاعدة البيانات من إضافة بيانات غير صالحة أو تعديل البيانات الصالحة بحيث تصبح غير صالحة، حتى لو كان التطبيق نفسه يقبل البيانات غير الصالحة.

يجب تعريف كل قيد تحقق في عبارة " CREATE TABLEأو" ALTER TABLEباستخدام الصيغة التالية:

إنشاء جدول باسم_الجدول ( ..., CONSTRAINT constraint_name CHECK ( predicate ), ... )

ALTER TABLE table_name ADD CONSTRAINT constraint_name CHECK ( predicate )

إذا كان قيد التحقق يشير إلى عمود واحد فقط، فمن الممكن تحديد القيد كجزء من تعريف العمود.

إنشاء جدول باسم_الجدول ( ... اسم_العمود نوع التحقق ( المسند )، ... )

القيد مكافئ وظيفيًا لقيد التحقق التالي مع شرط:NOT NULLIS NOT NULL

تحقق ( العمود ليس فارغًا)

تستطيع بعض أنظمة إدارة قواعد البيانات العلائقيةNOT NULL تحسين الأداء عند استخدام صيغة القيود بدلاً من CHECKصيغة القيود المذكورة أعلاه. ^{[ 1 ]}

معظم أنظمة إدارة قواعد البيانات تقيد قيود التحقق بصف واحد، مع إمكانية الوصول إلى الثوابت والوظائف الحتمية، ولكن ليس إلى البيانات الموجودة في الجداول الأخرى، أو إلى البيانات غير المرئية للمعاملة الحالية بسبب عزل المعاملات .

لا تُعدّ هذه القيود قيودًا للتحقق من الجداول، بل قيودًا للتحقق من الصفوف . ولأن هذه القيود لا تُتحقق عادةً إلا عند تحديث صفٍّ ما مباشرةً (لأسباب تتعلق بالأداء)، وغالبًا ما تُنفَّذ ضمنيًا INSERTأو UPDATEعبر مُشغِّلات، فقد تُنتهك قيود التكامل بفعل إجراءات غير مباشرة لولا هذه القيود. علاوة على ذلك، فإن هذه القيود تمنع التعديلات الصحيحة على هذه السجلات CHECK. ومن أمثلة القيود الخطيرة ما يلي:

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

يمكن استخدام المحفزات المُعرَّفة من قِبل المستخدم لتجاوز هذه القيود. ورغم تشابه التنفيذ، فمن الواضح دلاليًا أن المحفزات لن تُفعَّل إلا عند تعديل الجدول مباشرةً، وأن مسؤولية معالجة التغييرات غير المباشرة والهامة في الجداول الأخرى تقع على عاتق المصمم؛ أما القيود، من جهة أخرى، فهي مصممة لتكون "صحيحة دائمًا" بغض النظر عن إجراءات المستخدم أو عدم استباق المصمم للأمر.