قيمة فارغة (إس كيو إل)
القيمة الفارغة أو لا شيء؛ قيمة خالية ؛ غير معروف (أو NULL)[1] وهي علامة خاصة تستخدم في لغة الاستعلام البنيوية (SQL) للإشارة إلى عدم وجود قيمة بيانات في قاعدة البيانات. قدمها منشئ نماذج قواعد البيانات العلائقية إدجار كود، SQL Null والتي تعمل على تلبية متطلبات جميع أنظمة إدارة قواعد البيانات العلائقية الحقيقية (RDBMS) لتدعم تمثيل «المعلومات المفقودة والمعلومات غير القابلة للتطبيق». أيضًا استخدام رمز أوميغا اليوناني الصغير (ω) لتمثيل Null في نظرية قاعدة البيانات. في لغة SQL فإن قيمةNULL هي كلمة محجوزة تُستخدم لتحديد هذه العلامة.
يجب عدم الخلط بين قيمة فارغة وقيمة 0. تشير القيمة الفارغة إلى نقص في القيمة - فالافتقار إلى قيمة ليست نفس قيمة الصفر بنفس الطريقة التي لا يكون بها نقص الإجابة نفس الشيء مثل إجابة «لا». على سبيل المثال، ضع في اعتبارك السؤال «كم عدد الكتب التي يملكها خالد؟» قد يكون الجواب «صفر» (نعلم أنه لا يملك شيئًا) أو «فارغ» (هنا لا نعلم كم يملك). في جدول قاعدة البيانات، يبدأ العمود الذي يبلغ عن هذه الإجابة بدون قيمة (مميزة بعلامة Null)، ولن يتم تحديثه بقيمة «صفر» حتى نتأكد من أن خالد لا يملك كتبًا.
تعتبر القيمة الفارغة null في لغة أس كيو إل هي حالة وليست قيمة. فهي تختلف في الاستخدام تمامًا عن معظم لغات البرمجة، حيث تعني في لغات البرمجة بالقيمة الخالية للمؤشر أي أنه لا يشير إلى أي كائن.[2]
التاريخ
عدلذكر إدجار كود القيم الخالية كطريقة لتمثيل البيانات المفقودة في النموذج العلائقي في ورقة عام 1975 في نشرة الخاصة بـ جمعية آلات الحوسبة (ACM) -SIGMOD. ورقة كود التي تم الاستشهاد بها بشكل شائع فيما يتعلق بدلالات Null (كما تم اعتمادها في SQL) هي ورقه بحثية لعام 1979 في معاملات ACM على أنظمة قواعد البيانات، والتي قدم فيها أيضًا نموذج العلائقية / تسمانيا، على الرغم من أن الكثير من المقترحات الأخرى من الورقة الأخيرة ظلت غامضة. يوضح القسم 2.3 من ورقته البحثية عام 1979 دلالات انتشار Null في العمليات الحسابية بالإضافة إلى المقارنات التي تستخدم منطقًا ثلاثيًا (ثلاثي القيم) عند مقارنته بالأصفار؛ كما يفصل معالجة Nulls في عمليات محددة أخرى (لا تزال المسألة الأخيرة مثيرة للجدل حتى اليوم). في دوائر نظرية قواعد البيانات، يُشار الآن إلى الاقتراح الأصلي لـ كود (1975، 1979) باسم «جداول كود».[3] عزز كود لاحقًا مطلبه بأن تدعم جميع أنظمة RDBMS الـ Null للإشارة إلى البيانات المفقودة في مقالة من جزأين عام 1985 نُشرت في مجلة ComputerWorld.[4][5]
اعتمد معيار SQL لعام 1986 أساسًا اقتراح كود بعد نموذج أولي للتنفيذ في IBM System R. على الرغم من أن دونالد شامبرلن اعترف بالقيم الخالية (جنبًا إلى جنب مع الصفوف المكررة) كواحدة من أكثر السمات المثيرة للجدل في SQL ، فقد دافع عن تصميم Nulls في SQL مستحضرًا الحجج البراغماتية التي كان هذا هو الشكل الأقل تكلفة لدعم النظام للمعلومات المفقودة، مما يوفر للمبرمج من العديد من عمليات التحقق من مستوى التطبيق المكرر (انظر semipredicate problem) بينما يوفر في نفس الوقت لمصمم قاعدة البيانات خيار عدم استخدام Nulls إذا رغبوا في ذلك؛ على سبيل المثال، من أجل تجنب الحالات الشاذة المعروفة (anomalies). جادل تشامبرلين أيضًا أنه إلى جانب توفير بعض وظائف القيمة المفقودة، أدت الخبرة العملية مع Null أيضًا إلى ميزات لغة أخرى تعتمد على Null ، مثل بعض التركيبات التجميعية والوصلات الخارجية. أخيرًا، جادل بأنه من الناحية العملية، ينتهي الأمر باستخدام Null أيضًا كطريقة سريعة لتصحيح مخطط موجود عندما يحتاج إلى التطور إلى ما بعد هدفه الأصلي، والترميز ليس من أجل المعلومات المفقودة ولكن بالأحرى للمعلومات غير القابلة للتطبيق؛ على سبيل المثال، قاعدة بيانات تحتاج بسرعة إلى دعم السيارات الكهربائية مع وجود عمود ميل لكل جالون.[6]
أشار كود في كتابه الصادر عام 1990، النموذج العلائقي لإدارة قواعد البيانات، الإصدار 2، إلى أن Null الفردي الذي يفرضه معيار SQL لم يكن كافياً، ويجب استبداله بعلامتين منفصلتين من النوع Null للإشارة إلى سبب فقدان البيانات. في كتاب كود، تتم الإشارة إلى هاتين المحددين من النوع Null باسم "A-Values" و "I-Values"، والتي تمثل «مفقود لكن قابل للتطبيق» و «مفقود لكن غير قابل للتطبيق»، على التوالي.[7] كانت توصية كود تتطلب توسيع نظام منطق SQL لاستيعاب نظام منطق رباعي القيم. بسبب هذا التعقيد الإضافي، فإن فكرة الأعداد الفارغة المتعددة ذات التعريفات المختلفة لم تحظ بقبول واسع النطاق في مجال ممارسي قواعد البيانات. لا يزال مجالًا نشطًا للبحث، مع استمرار نشر العديد من الأوراق.
التحديات
عدلكانت Null محور الجدل ومصدرًا للنقاش بسبب المنطق المرتبط به ثلاثي القيم (3VL)، والمتطلبات الخاصة لاستخدامه في Join (SQL)، والمعالجة الخاصة التي تتطلبها الوظائف التجميعية ومشغلي تجميع SQL. لخص أستاذ علوم الكمبيوتر رون فان دير ميدن القضايا المختلفة على النحو التالي: «التناقضات في معيار SQL تعني أنه لا يمكن إسناد أي دلالات منطقية بديهية إلى معالجة القيم الخالية في SQL.»[3] على الرغم من تقديم العديد من المقترحات لحل هذه القضايا، إلا أن تعقيد البدائل حال دون اعتمادها على نطاق واسع.
شيوع Null
عدلالعمليات الحسابية
عدللأن القيمة الفارغة Null ليس قيمة بيانات، بل علامة لقيمة غائبة، فإن استخدام معاملات الحسابية على Null يعطي نتيجة غير معروفة، والتي يتم تمثيلها بواسطة Null.[8] في المثال التالي، ينتج عن ضرب 10 في Null قيمة Null ؛
10 * NULL -- Result is NULL
هذا يمكن أن يؤدي إلى نتائج غير متوقعة. على سبيل المثال، عند إجراء محاولة تقسيم Null على صفر، قد تُرجع الأنظمة الأساسية Null بدلاً من طرح «بيانات متوقع - قسمة على صفر».[8] على الرغم من عدم تحديد هذا السلوك بواسطة معيار ISO SQL ، فإن العديد من بائعي DBMS يعاملون هذه العملية بشكل مشابه. على سبيل المثال، تقوم الأنظمة الأساسية Oracle و PostgreSQL و MySQL Server و Microsoft SQL Server بإرجاع نتيجة خالية لما يلي:
NULL / 0
سلسلة الحروف
عدل
تؤدي عمليات دمج الحروف String، الشائعة في SQL ، أيضًا إلى قيمة فارغة Null عندما يكون أحد المعاملات Null.[9] يوضح المثال التالي نتيجة لا شيء تم إسترجاعها باستخدام Null في لغة SQL || بمعامل دمج سلسلة الحروف.
'Fish ' || NULL || 'Chips' -- Result is NULL
هذا ليس صحيحا لجميع تطبيقات قاعدة البيانات. في Oracle RDBMS على سبيل المثال NULL وسلسلة الفارغة (empty string) تُعتبران نفس الشيء، وبالتالي 'Fish ' || NULL || 'Chips' النتيجة ستكون 'Fish Chips'.
الجدل
عدلالأخطاء الشائعة
عدلإن سوء فهم كيفية عمل Null هو سبب عدد كبير من الأخطاء في تعليمات SQL البرمجية، سواء في عبارات SQL القياسية ISO أو في لهجات SQL المحددة التي تدعمها أنظمة إدارة قواعد البيانات في العالم الحقيقي. عادة ما تكون هذه الأخطاء نتيجة الخلط بين Null و 0 (صفر) أو سلسلة الحروف الفارغة (empty string). يتم تعريف Null بواسطة معيار SQL على أنه يختلف عن كل من السلسلة الفارغة والقيمة العددية 0. بينما يشير Null إلى عدم وجود أي قيمة، فإن كلا من السلسلة الفارغة والصفر العددي يمثلان القيم الفعلية.
الخطأ التقليدي هو محاولة استخدام عامل التشغيل يساوي = بالاقتران مع الكلمة الأساسية NULL للعثور على صفوف بها Nulls. وفقًا لمعيار SQL ، يعد هذا تركيبًا غير صالح وسيؤدي إلى رسالة خطأ أو استثناء. لكن معظم عمليات التنفيذ تقبل بناء الجملة وتقيم مثل هذه التعبيرات إلى UNKNOWN. والنتيجة هي أنه لم يتم العثور على صفوف - بغض النظر عما إذا كانت الصفوف ذات القيم الخالية موجودة أم لا. الطريقة المقترحة لاسترداد الصفوف ذات القيم الخالية هي استخدام المسند IS NULL بدلاً من = NULL.
SELECT *
FROM sometable
WHERE num = NULL; -- Should be "WHERE num IS NULL"
في مثال مرتبط ولكن أكثر دقة، قد تقارن جملة WHERE أو العبارة الشرطية بقيمة العمود ثابتة. غالبًا ما يُفترض بشكل غير صحيح أن القيمة المفقودة ستكون «أقل من» أو «لا تساوي» القيمة الثابتة إذا كان الحقل يحتوي على Null، ولكن في الواقع، تُرجع هذه التعبيرات غير معروف. مثال أدناه:
SELECT *
FROM sometable
WHERE num <> 1; -- Rows where num is NULL will not be returned,
-- contrary to many users' expectations.
تنشأ هذه الالتباسات لأن قانون الهوية مقيد في منطق SQL. عند التعامل مع مقارنات المساواة باستخدام القيمة الحرفية NULL أو قيمة الحقيقة غير المعروفة، سترجع SQL دائمًا «غير معروف» كنتيجة للتعبير. هذه علاقة تكافؤ جزئية وتجعل SQL مثالاً على المنطق غير انعكاسي.[10] وبالمثل، غالبًا ما يتم الخلط بين القيم الفارغة والسلاسل الفارغة. ضع في اعتبارك الدالة LENGTH ، التي تُرجع عدد الأحرف في السلسلة. عندما يتم تمرير Null إلى هذه الدالة، ترجع الدالة Null. يمكن أن يؤدي هذا إلى نتائج غير متوقعة، إذا لم يكن المستخدمون على دراية بمنطق 3 قيم. مثال أدناه:
SELECT *
FROM sometable
WHERE LENGTH(string) < 20; -- Rows where string is NULL will not be returned.
هذا معقد بسبب حقيقة أنه في بعض برامج واجهة قواعد البيانات (أو حتى تطبيقات قواعد البيانات مثل Oracle)، يتم الإبلاغ عن NULL كسلسلة فارغة، وقد يتم تخزين السلاسل الفارغة بشكل غير صحيح على أنها NULL.
انتقادات
عدلتطبيق ISO SQL لـ Null هو موضوع نقد ومناقشة ودعوات للتغيير. في النموذج العلائقي لإدارة قواعد البيانات: الإصدار 2، اقترح كود أن تطبيق SQL لـ Null كان معيبًا ويجب استبداله بعلامتين مختلفتين من النوع Null. كانت العلامات التي اقترحها ترمز إلى «مفقود لكن قابل للتطبيق» و «مفقود ولكن غير قابل للتطبيق»، والمعروفين باسم قيم A وقيم I ، على التوالي. توصية Codd ، في حالة قبولها، كانت ستتطلب تنفيذ منطق رباعي القيم في SQL.[7] اقترح آخرون إضافة علامات إضافية من النوع Null إلى توصية كودللإشارة إلى المزيد من الأسباب التي تجعل قيمة البيانات «مفقودة»، مما يزيد من تعقيد نظام منطق SQL. في أوقات مختلفة، تم أيضًا تقديم مقترحات لتنفيذ علامات Null متعددة المعرفة من قبل المستخدم في SQL. نظرًا لتعقيد أنظمة المعالجة الفارغة والمنطقية المطلوبة لدعم علامات Null المتعددة، لم يحظ أي من هذه المقترحات بقبول واسع النطاق.
اقترح كريس ديت وهيو داروين، مؤلفا The Third Manifesto، أن تطبيق SQL Null معيب بطبيعته ويجب إزالته تمامًا،[11] مشيرين إلى التناقضات والعيوب في تنفيذ معالجة SQL Null (خاصة في الوظائف الإجمالية) كدليل على ذلك مفهوم Null بالكامل معيب ويجب إزالته من النموذج العلائقي.[12] صرح آخرون، مثل المؤلف فابيان باسكال، بالاعتقاد بأن «كيفية معالجة حساب الوظيفة للقيم المفقودة لا يحكمها النموذج العلائقي».[بحاجة لمصدر]
افتراض العالم المغلق
عدلنقطة أخرى للصراع بشأن Nulls هي أنها تنتهك نموذج افتراض العالم المغلق (Closed-world assumption) لقواعد البيانات العلائقية من خلال إدخال افتراض العالم المفتوح فيه.[13] ينص افتراض العالم المغلق، من حيث صلته بقواعد البيانات، على أن "كل ما تنص عليه قاعدة البيانات، سواء بشكل صريح أو ضمني، فهو صحيح؛ وكل شيء آخر خاطئ.[14]" تفترض طريقة العرض هذه اكتمال معرفة العالم المُخزّن في قاعدة بيانات. ومع ذلك، تعمل القيم الفارغة في ظل افتراض العالم المفتوح، حيث تعتبر بعض العناصر المُخزنة في قاعدة البيانات غير معروفة، مما يجعل المعرفة المخزنة في قاعدة البيانات عن العالم غير مكتملة.
انظر أيضًا
عدلالمراجع
عدل- ^ "null - JavaScript | MDN". developer.mozilla.org (بالإنجليزية الأمريكية). 21 Feb 2023. Archived from the original on 2023-06-29. Retrieved 2023-09-09.
- ^ "A quick and thorough guide to 'null': what it is, and how you should use it". freeCodeCamp.org (بالإنجليزية). 12 Jun 2018. Archived from the original on 2023-05-30. Retrieved 2023-09-09.
- ^ ا ب Ron van der Meyden, "Logical approaches to incomplete information: a survey" in Chomicki, Jan; Saake, Gunter (Eds.) Logics for Databases and Information Systems, Kluwer Academic Publishers (ردمك 978-0-7923-8129-7), p. 344; PS preprint (note: page numbering differs in preprint from the published version) نسخة محفوظة 2021-04-14 على موقع واي باك مشين.
- ^ Codd، E.F. (14 أكتوبر 1985). "Is Your Database Really Relational?". ComputerWorld.
- ^ Codd، E.F. (21 أكتوبر 1985). "Does Your DBMS Run By The Rules?". ComputerWorld.
- ^ Don Chamberlin (1998). A Complete Guide to DB2 Universal Database. Morgan Kaufmann. ص. 28–32. ISBN:978-1-55860-482-7. مؤرشف من الأصل في 2015-04-03.
- ^ ا ب Codd، E.F. (1990). The Relational Model for Database Management (ط. Version 2). بيرسون. ISBN:978-0-201-14192-4.
- ^ ا ب ISO/IEC (2003). ISO/IEC 9075-2:2003, "SQL/Foundation". ISO/IEC. Section 6.2.6: numeric value expressions..
- ^ ISO/IEC (2003). ISO/IEC 9075-2:2003, "SQL/Foundation". ISO/IEC. Section 6.2.8: string value expression.
- ^ Arenhart, Krause (2012)، "Classical Logic or Non-Reflexive Logic? A case of Semantic Underdetermination"، Revista Portuguesa de Filosofia، ج. 68، ص. 73–86، DOI:10.17990/RPF/2012_68_1_0073، JSTOR:41955624.
- ^ Darwen، Hugh؛ Chris Date. "The Third Manifesto". مؤرشف من الأصل في 2021-03-03. اطلع عليه بتاريخ 2007-05-29.
- ^ Darwen، Hugh. "The Askew Wall" (PDF). مؤرشف من الأصل (PDF) في 2021-12-02. اطلع عليه بتاريخ 2007-05-29.
- ^ Date، Chris (مايو 2005). Database in Depth: Relational Theory for Practitioners. O'Reilly Media, Inc. ص. 73. ISBN:978-0-596-10012-4.
- ^ Date، Chris. "Abstract: The Closed World Assumption". Data Management Association, San Francisco Bay Area Chapter. مؤرشف من الأصل في 2007-05-19. اطلع عليه بتاريخ 2007-05-29.
