استعلام جداول بيانات جوجل: كيفية استخدام “NOT LIKE” في الاستعلام

تعد جداول بيانات جوجل (Google Sheets) واحدة من أكثر الأدوات السحابية انتشاراً وتطوراً في بيئات الأعمال والمؤسسات الأكاديمية والبحثية الحديثة، حيث تحولت من مجرد تطبيق جداول حسابية بسيط إلى بيئة معالجة بيانات متكاملة قادرة على محاكاة قواعد البيانات العلائقية المعقدة. وفي قلب هذه المنظومة التحليلية المتطورة تقبع دالة QUERY، التي تمثل جسراً برمجياً يربط بين مرونة واجهة المستخدم الرسومية وقوة لغة الاستعلام الهيكلية (SQL)، مما يتيح للمحللين والباحثين استخراج البيانات وتنقيحها وتلخيصها بكفاءة حسابية فائقة.

إن التعامل مع مجموعات البيانات الضخمة (Big Data) والمتشعبة يفرض تحديات تقنية جسيمة تتعلق بدقة تنقية النصوص واستبعاد المدخلات غير المرغوبة أو الشاذة. وفي حين تتيح معاملات المقارنة التقليدية تصفية القيم المتطابقة تماماً، تبرز الحاجة الماسة إلى تقنيات مطابقة الأنماط الجزئية (Pattern Matching) لمعالجة النصوص الديناميكية التي تتغير تراكيبها باستمرار. وهنا يتجلى الدور المحوري لمعامل النفي النصي NOT LIKE، الذي يعد أداة استبعاد نمطية بالغة الحساسية والدقة، تتيح استئصال السجلات التي تتبع نسقاً رمزياً أو نصياً محدداً مع الحفاظ على سلامة باقي البيانات.

يهدف هذا الدليل الأكاديمي الشامل إلى تفكيك البنية الهيكلية والمنطقية لمعامل NOT LIKE داخل دالة QUERY في جداول بيانات جوجل. وسنتناول بالتفصيل المعمق والتحليل الدقيق الأسس النظرية والمفاهيمية لمطابقة الأنماط، واستخدام الرموز البديلة (Wildcards)، وقوانين المنطق البولياني المنظمة للدمج الشرطي، ومعالجة تحديات حساسية حالة الأحرف، وخصوصية اللغة العربية، وصولاً إلى استراتيجيات تحسين الأداء وحل المشكلات التشغيلية المعقدة عبر سيناريوهات وحالات دراسية واقعية.

1. مقدمة تأصيلية لدالة QUERY في جداول بيانات جوجل وأهميتها التحليلية

1.1 المفهوم الهيكلي ولغة الاستعلام في جداول بيانات جوجل (Google Visualization API)

تستند دالة QUERY في جداول بيانات جوجل إلى واجهة برمجة تطبيقات التصور الخاصة بجوجل (Google Visualization API Query Language)، وهي لغة استعلامية مصممة خصيصاً لتنفيذ عمليات البحث، والفرز، والتجميع، والتصفية على مصفوفات البيانات ثنائية الأبعاد. تختلف هذه الدالة جوهرياً عن الدوال الرياضية والمنطقية المعتادة، إذ إنها لا تُجري عملية حسابية معزولة على خلية مفردة، بل تعمل كمحرك قواعد بيانات مصغر يقرأ النطاق المصدري كاملاً، ويُعيد هيكلته برمجياً وفقاً لجملة الاستعلام النصية الممررة إليها.

تتكون البنية الهيكلية القياسية للدالة من ثلاثة وسائط رئيسية: النطاق المصدري للبيانات (data)، وجملة الاستعلام النصية (query)، ووسيط اختياري يحدد عدد صفوف الترويسة (headers). تتم كتابة جملة الاستعلام كأمر نصي محاط بعلامات اقتباس مزدوجة، يتضمن كلمات مفتاحية قياسية تشبه إلى حد كبير لغة SQL التقليدية، مثل SELECT وWHERE وGROUP BY وORDER BY وLIMIT. هذا التصميم يمنح المحلل القدرة على كتابة استعلام واحد متعدد الأبعاد يغني عن تكديس عشرات الصيغ الحسابية المتداخلة.

تتفوق دالة QUERY بمراحل على الدوال التقليدية مثل FILTER وVLOOKUP وINDEX/MATCH، حيث توفر مرونة استثنائية في إعادة ترتيب الأعمدة، وتطبيق العمليات التجميعية الرياضية المباشرة (مثل SUM وAVG وCOUNT)، وإجراء التصفية الشرطية المتقدمة في خطوة واحدة دون الحاجة إلى إنشاء أعمدة مساعدة تستهلك الذاكرة الحسابية للملف وتزيد من احتمالية حدوث أخطاء بشرية أثناء الصيانة.

1.2 دور عبارة WHERE في تصفية السجلات وتنقية مخرجات البيانات

تمثل عبارة WHERE الركيزة المنطقية الأساسية لعمليات التصفية والاختيار داخل جملة الاستعلام؛ إذ تُملي على محرك الدالة المعايير الدقيقة التي يجب أن يستوفيها كل صف في جدول البيانات ليتم تضمينه في المخرجات النهائية. بدون عبارة WHERE، يقوم الاستعلام باسترجاع كافة السجلات المتواجدة في النطاق المحدد، مما يجعلها البوابة الحاكمة للتحكم في تدفق البيانات المسترجعة بناءً على تقييم منطقي صارم.

تخضع آلية عمل عبارة WHERE لقواعد المنطق البولياني (Boolean Logic)، حيث يقوم محرك الاستعلام بمسح كل صف بشكل تسلسلي وتقييم الشرط أو مجموعة الشروط المحددة. إذا كانت نتيجة التقييم لصف معين هي القيمة المنطقية الصائبة (TRUE)، يمرر الصف إلى مصفوفة النتائج، أما إذا كانت النتيجة خاطئة (FALSE) أو غير معرفة (Null)، يتم استبعاد الصف تماماً من النتيجة المعروضة، دون التأثير بأي شكل من الأشكال على البيانات الأصلية المخزنة في النطاق المصدري.

تتيح عبارة WHERE استخدام طيف واسع من المعاملات، بدءاً من معاملات المقارنة الرياضية البسيطة (مثل الأكبر من والأصغر من)، وصولاً إلى معاملات المطابقة المنطقية المركبة والمطابقة النصية. هذا التنوع يمنح محلل البيانات القدرة على بناء استعلامات ديناميكية تستجيب للتغيرات المستمرة في المدخلات، وتتعامل بكفاءة مع المعايير متعددة المستويات في البيئات التشغيلية المعقدة.

1.3 موضع المعامل المنطقي NOT LIKE ضمن منظومة تصفية الأنماط

في إطار معالجة البيانات النصية، ينقسم منطق التصفية إلى فئتين رئيسيتين: المطابقة التامة (Exact Matching) والمطابقة النمطية الجزئية (Pattern Matching). تُستخدم معاملات التساوي واللاتساوي (= و!=) للتعامل مع الحالات التي تكون فيها القيمة المستهدفة معروفة ومحددة بدقة تامة. ومع ذلك، تفشل هذه المعاملات في التعامل مع البيانات غير المتجانسة، أو الأوصاف النصية الطويلة، أو الأكواد المشفرة التي تحتوي على أجزاء متغيرة وأجزاء ثابتة.

هنا تبرز أهمية معامل المطابقة الجزئية LIKE، ونظيره الاستبعادي NOT LIKE. يمثل معامل NOT LIKE الجمع المنطقي بين أداة النفي (NOT) ومعامل مطابقة الأنماط (LIKE)، مما يتيح استبعاد أي سجل يحتوي على تسلسل محدد من المحارف، حتى لو كان هذا التسلسل مدمجاً داخل نص أطول أو محاطاً بمحارف أخرى مجهولة.

يعد هذا النفي النمطي عنصراً جوهرياً في تنقية البيانات وتطهيرها (Data Cleaning)، حيث يتيح للباحثين والمحللين عزل القيم الشاذة، واستبعاد المعاملات الاختبارية أو السجلات الملغاة، وتنقية التقارير المالية والإدارية من الضوضاء النصية التي قد تشوه نتائج التحليل الإحصائي أو تؤدي إلى استنتاجات خاطئة إذا تم تضمينها في الحسابات التجميعية.

2. البنية التركيبية الأساسية لمعامل المطابقة النصية LIKE والمعامل العكسي NOT LIKE

2.1 الصيغة القواعدية الصحيحة لكتابة شرط NOT LIKE داخل الدالة

تتطلب لغة استعلام جداول بيانات جوجل الالتزام الصارم بقواعد بناء الجملة (Syntax) لضمان تفسير الشروط بشكل صحيح من قبل المحرك التحليلي. عند صياغة شرط الاستبعاد النمطي، يجب اتباع الترتيب القواعدي القياسي: كتابة عبارة التصفية WHERE، متبوعة بأداة النفي المنطقي NOT، ثم اسم العمود المستهدف، يليه معامل المطابقة LIKE، وأخيراً النمط النصي المراد استبعاده محاطاً بعلامات اقتباس مفردة.

الصيغة العامة القياسية تُكتب على النحو التالي:
WHERE NOT [Column] LIKE ‘pattern’
حيث يمثل [Column] المعرف الحرفي للعمود (مثل A أو B أو C) إذا كان الاستعلام يشير إلى نطاق خلايا مباشر، أو Col1 وCol2 إذا كان الاستعلام يعتمد على مصفوفة مجمعة بين أقواس معقوفة. من الضروري الانتباه إلى أن جملة الاستعلام ككل تُحاط بعلامات اقتباس مزدوجة، في حين تُحاط الأنماط النصية الداخلية بعلامات اقتباس مفردة لتجنب تداخل علامات التنصيص وانهيار بنية الصيغة البرمجية.

من الأخطاء القواعدية الشائعة التي يقع فيها الممارسون كتابة أداة النفي بعد العمود (مثل: WHERE B NOT LIKE ‘pattern’)، وهو نمط متبع في بعض لهجات SQL ولكنه قد يؤدي إلى أخطاء في واجهة Google Visualization API إذا لم يُكتب بالهيكل الدقيق الذي يتوقعه المحرك، حيث يفضل المحرك دائماً وضع NOT قبل العمود المستهدف لضمان التفسير المنطقي السليم.

2.2 آلية عمل محرك المطابقة الداخلي عند تقييم النصوص المنفية

عند تنفيذ دالة الاستعلام، يقوم المحرك الداخلي بتطبيق خوارزمية مسح متسلسلة تمر على كل سجل من سجلات العمود المحدد في جملة WHERE. تقوم الخوارزمية بمقارنة السلسلة النصية الموجودة في الخلية مع النمط المحدد بعد معامل LIKE حرفاً بحرف، مع الأخذ في الاعتبار مواقع الرموز البديلة إن وجدت.

خلال هذه العملية، يقوم محرك المطابقة أولاً بتقييم تعبير LIKE الداخلي؛ فإذا تطابق النص مع النمط المحدد، يُنتج التعبير قيمة منطقية إيجابية (TRUE). وعند تطبيق المعامل العكسي NOT، تنعكس هذه القيمة المنطقية لتصبح سلبية (FALSE)، مما يدفع المحرك إلى استبعاد الصف فوراً من المصفوفة المخرجة. وعلى العكس من ذلك، إذا لم يتطابق النص مع النمط، ينتج عن تقييم LIKE قيمة خاطئة (FALSE)، والتي تنقلب بفعل NOT إلى قيمة صائبة (TRUE)، فيتم الاحتفاظ بالصف وعرضه للمستخدم.

هذا الفصل المنطقي بين عملية المطابقة وعملية النفي يضمن معالجة متسقة عبر مجموعات البيانات المعقدة، ويمنع حدوث تداخلات غير مقصودة في نتائج التصفية، مما يوفر بيئة استعلام موثوقة ومطابقة للمعايير القياسية لعلم المنطق الحاسوبي.

3. الرموز البديلة (Wildcards) ودورها في بناء أنماط البحث مع NOT LIKE

3.1 رمز النسبة المئوية (%) واستخدامه لتمثيل السلاسل النصية غير محددة الطول

يعد رمز النسبة المئوية % الأداة الأكثر مرونة واستخداماً في بناء أنماط المطابقة النصية، حيث يعمل كرمز بديل يمثل صفراً أو واحداً أو أي عدد لا نهائي من المحارف المتتالية في السلسلة النصية. يتيح هذا الرمز للمحلل تحديد موضع النص المراد استبعاده بدقة متناهية، سواء كان في بداية الخلية، أو في نهايتها، أو مغموراً في أي موضع داخلها.

تتحدد سلوكيات الاستبعاد النصي بناءً على تموضع رمز النسبة المئوية داخل النمط كما يلي:

• النمط ‘%text%’: يؤدي إلى استبعاد أي صف يحتوي على المقطع ‘text’ في أي موضع من مواضع الخلية، سواء كان في أول الكلمة، أو وسطها، أو آخرها، أو حتى إذا كانت الخلية لا تحتوي إلا على هذا المقطع فقط.
• النمط ‘text%’: يركز الاستبعاد حصراً على الخلايا التي تبدأ بالمقطع ‘text’ كبادئة (Prefix)، متجاهلاً ما يليها من محارف، بينما يحتفظ بالخلايا التي تحتوي على نفس المقطع إذا ظهر في الوسط أو النهاية.
• النمط ‘%text’: يوجه محرك الاستعلام لاستبعاد الخلايا التي تنتهي بالمقطع ‘text’ كلاحقة (Suffix)، مع الحفاظ على كافة السجلات الأخرى التي لا ينتهي نصها بهذه السلسلة الرمزية المحددة.

3.2 رمز الشرطة السفلية (_) لتمثيل خانة حرفية فردية متغيرة

على النقيض من رمز النسبة المئوية الذي يتعامل مع سلاسل مجهولة الطول، يمثل رمز الشرطة السفلية _ محرفاً فردياً واحداً بالضبط، أياً كانت طبيعته (حرف، رقم، مسافة، أو رمز خاص). يمنح هذا الرمز المحلل تحكماً دقيقاً في الأطوال الهيكلية للمقاطع النصية المستهدفة بالاستبعاد.

يمكن تكرار الشرطة السفلية لتمثيل عدد محدد بدقة من الخانات؛ فعلى سبيل المثال، النمط ‘__’ (شرطتان سفليتان) يطابق أي نص يتكون من محرفين اثنين فقط. وإذا قمنا بكتابة النمط ‘A_C’، فإن الاستعلام سيطابق نصوصاً مثل ‘ABC’ و’A1C’ و’A-C’ ويستبعدها جميعاً، لكنه لن يطابق ‘ABBC’ لأن عدد الخانات الفاصلة بين الحرفين يتجاوز المحرف الواحد.

تكتسب الشرطة السفلية أهمية بالغة في تنقية السجلات ذات البنية المقيسة الصارمة، مثل أرقام الحسابات البنكية، أو أكواد المنتجات الدولية (SKUs)، أو لوحات المركبات، حيث يتطلب التحليل استبعاد فئات معينة محددة بخانة تشفيرية محددة الموضع ضمن الكود العام دون المساس بالأكواد الأخرى.

3.3 التعامل مع الرموز الخاصة واستراتيجيات إلغاء تفعيل المعنى الخاص (Escaping)

تنشأ تحديات تقنية معقدة عندما تحتوي البيانات النصية الفعلية المراد معالجتها على الرموز الخاصة ذاتها، أي عندما يحتاج المحلل إلى استبعاد النصوص التي تحتوي على رمز النسبة المئوية الحرفي (مثل ‘10%’) أو الشرطة السفلية الحرفية (مثل ‘user_id’). في مثل هذه السيناريوهات، يؤدي استخدام الرموز بشكل مباشر إلى قيام محرك الدالة بتفسيرها كرموز بديلة، مما يؤدي إلى تشويه نتائج الاستعلام واستبعاد صفوف غير مقصودة.

لحل هذه المعضلة في لغة استعلام جداول بيانات جوجل، تتطلب الممارسة المنهجية استخدام تقنيات إلغاء التفعيل (Escaping) أو اللجوء إلى معالجات بديلة. في محركات الاستعلام القياسية، يتم استخدام الشرطة المائلة العكسية () قبل الرمز الخاص لتعطيل وظيفته البديلة وتأكيد معاملته كمحرف نصي مجرد (مثل: ‘%’ أو ‘_’).

في بيئة Google Visualization API، إذا واجهت الدالة صعوبة في تفسير محرف الهروب بشكل مباشر داخل جملة LIKE، يُنصح بالانتقال إلى معاملات أكثر مرونة مثل MATCHES واستخدام التعبيرات النمطية (RegEx)، أو تنظيف وتعديل الرموز الخاصة مؤقتاً عبر دوال الاستبدال النصية مثل SUBSTITUTE قبل تمرير البيانات إلى محرك الاستعلام، لضمان استقرار التحليل وعدم حدوث التباس في المعالجة البرمجية.

4. التطبيق العملي الأساسي: استبعاد الأنماط الجزئية داخل النصوص باستخدام NOT LIKE

4.1 إعداد نموذج البيانات الأكاديمي والافتراضات المنهجية

لترسيخ المفاهيم النظرية، سنفترض وجود مجموعة بيانات تمثل سجلاً تنظيمياً لموظفي إحدى المؤسسات الكبرى، حيث تتوزع السجلات عبر ثلاثة أعمدة رئيسية: معرف الموظف (العمود A)، والمسمى الوظيفي (العمود B)، والقسم التشغيلي (العمود C). يوضح الجدول التالي عينة من هذه البيانات المرجعية الممتدة من الخلية A1 إلى C11:

• الصف 1 (الترويسة): ID | Job Title | Department
• الصف 2: 101 | Senior Guard | Security
• الصف 3: 102 | Chief Architect | Engineering
• الصف 4: 103 | Night Guard | Security
• الصف 5: 104 | Financial Analyst | Finance
• الصف 6: 105 | Software Engineer | Engineering
• الصف 7: 106 | Security Guard | Operations
• الصف 8: 107 | Data Scientist | Analytics
• الصف 9: 108 | Bodyguard | Executive Support
• الصف 10: 109 | Network Administrator | IT
• الصف 11: 110 | Guardian Officer | Legal

الفرضية التحليلية المستهدفة هنا هي استخراج تقرير شامل لكافة الموظفين مع استبعاد أي وظيفة ترتبط بمهام الحراسة أو الحماية الأمنية التي تتضمن التسلسل الحرفي ‘uar’ ضمن مسماها الوظيفي، بغض النظر عن موقع هذا المقطع في الكلمة أو تركيب المسمى الإداري.

4.2 تنفيذ الصيغة القياسية خطوة بخطوة لتحقيق التصفية المطلوبة

لتحقيق الهدف التحليلي المفترض، نقوم بصياغة دالة QUERY بالاعتماد على معامل النفي النمطي NOT LIKE والرموز البديلة لتغطية كافة الاحتمالات الموضعية للمقطع المستهدف. تُكتب المعادلة في خلية مستقلة (ولتكن E1) بالشكل التالي:

=QUERY(A1:C11, “SELECT * WHERE NOT B LIKE ‘%uar%'”, 1)

تتفكك هذه الصيغة برمجياً إلى العناصر التالية:

• A1:C11: يمثل النطاق المصدري الكامل الذي يحتوي على البيانات مع صف الترويسة.
• “SELECT *”: يوجه الاستعلام لاسترجاع كافة الأعمدة المتواجدة في النطاق دون إسقاط أي حقل بياني.
• WHERE NOT B LIKE ‘%uar%’: يمثل الشرط الحاكم؛ حيث يتم فحص قيم العمود B، واستبعاد كل صف يحتوي على المقطع ‘uar’ محاطاً بأي محارف سابقة أو لاحقة.
• 1: يشير إلى أن الصف الأول في النطاق هو صف الترويسة، مما يضمن تثبيته في رأس التقرير المفرز وعدم إخضاعه لشروط التصفية المنطقية.

4.3 قراءة وتفسير النتائج المسترجعة والتحقق من دقة الاستبعاد

عند تنفيذ المعادلة السابقة، يُعيد محرك جداول بيانات جوجل مصفوفة نظيفة تماماً تم استئصال كافة السجلات غير المرغوبة منها بنجاح. بمراجعة دقيقة للمخرجات، نجد أن السجلات ذات المعرفات 101 و103 و106 (التي تحتوي على كلمة Guard)، والسجل 108 (Bodyguard)، والسجل 110 (Guardian Officer) قد تم استبعادها بالكامل من التقرير النهائي.

في المقابل، احتفظ الاستعلام بكافة السجلات المهنية الأخرى مثل: Chief Architect، وFinancial Analyst، وSoftware Engineer، وData Scientist، وNetwork Administrator، دون المساس بأي من بياناتها الإضافية مثل القسم أو المعرف الرقمي.

يؤكد هذا التطبيق العملي قدرة معامل NOT LIKE على أداء عمليات تصفية نصية مجهرية بالغة الدقة؛ حيث نجح مقطع نصي واحد مكون من ثلاثة أحرف (‘uar’) في تنقية قاعدة البيانات من مسميات وظيفية متعددة الأشكال والتراكيب، وهو ما كان سيتطلب شروط تصفية متعددة ومعقدة للغاية في حال استخدام معاملات التطابق التام التقليدية.

5. استراتيجيات متقدمة: دمج شروط NOT LIKE المتعددة باستخدام المعاملات المنطقية

5.1 الربط المنطقي الاستبعادي التراكمي باستخدام المعامل AND

في السيناريوهات التحليلية المعقدة، نادراً ما يقتصر الاستبعاد على نمط نصي وحيد؛ إذ تتطلب متطلبات الأعمال غالباً استبعاد عدة أنماط متباينة في آن واحد لضمان نقاء البيانات المستخرجة. في هذه الحالة، يتم الاعتماد على المعامل المنطقي AND لربط شروط النفي التراكمية.

عند ربط شروط النفي باستخدام AND، تشترط الدالة أن تكون كافة شروط الاستبعاد محققة معاً لكي يتم الإبقاء على السجل. بمعنى آخر، إذا تطابق الصف مع أي من الأنماط المنفية، يتم استبعاده فوراً. الصيغة القياسية لهذا الربط تُكتب على النحو التالي:
WHERE NOT A LIKE ‘%pattern1%’ AND NOT A LIKE ‘%pattern2%’

يستند هذا السلوك إلى قوانين دي مورغان (De Morgan’s Laws) في علم المنطق الرياضي، حيث إن نفي الاتحاد يكافئ تقاطع النفيين. يقع العديد من المبتدئين في خطأ استخدام المعامل OR بدلاً من AND عند الرغبة في استبعاد نمطين معاً، مما يؤدي إلى فشل التصفية تماماً وظهور كافة السجلات؛ لأن الصف الذي يحتوي على النمط الأول سينجح في تحقيق شرط عدم احتوائه على النمط الثاني، مما يجعل العبارة الإجمالية صائبة دائماً.

5.2 الاستبعاد المشروط المتفرع عبر المعامل المنطقي OR

يُستخدم المعامل المنطقي OR عند بناء استعلامات تصفية متفرعة ومعقدة تتضمن مفاضلات شرطية عبر أعمدة متعددة، أو عند دمج شروط الاستبعاد النمطي مع شروط الإثبات النصي أو الرقمي. في هذا السياق، تبرز الأهمية القصوى لاستخدام الأقواس الهيكلية لتنظيم أولويات التقييم المنطقي داخل محرك الاستعلام.

لنفترض أننا نريد استخراج تقرير للموظفين، بحيث يتم استبعاد الموظفين التابعين لقسم الأمن الذين يحتوي مسماهم على ‘Guard’، ولكننا نريد في الوقت ذاته الاحتفاظ بأي موظف في قسم آخر حتى لو تطابق مسماه مع نمط معين، أو العكس. يتم التعبير عن هذا التعقيد بصيغة مثل:
WHERE (NOT B LIKE ‘%Guard%’) OR (C = ‘Executive Support’)

يقوم المحرك بتقييم التعبيرات المحاطة بالأقواس بشكل مستقل أولاً، ثم يطبق منطق OR النهائي. إذا تساوت الأولويات دون أقواس، قد يفسر المحرك الشروط بتسلسل يختلف عن الغرض التحليلي للباحث، مما يسفر عن تسرب سجلات غير مرغوبة أو استبعاد بيانات حرجة دون قصد.

5.3 بناء سلاسل شروط ديناميكية متعددة المستويات لتنقية قواعد البيانات المعقدة

في بيئات معالجة البيانات الضخمة (Enterprise Datasets)، تتطلب التحليلات المتقدمة بناء سلاسل استبعاد نصية تمتد عبر ثلاثة أعمدة أو أكثر بالتزامن مع محددات كمية وزمنية. يتطلب هذا المستوى من التعقيد هندسة دقيقة لعبارة WHERE لضمان التوازن بين دقة التصفية وسرعة المعالجة البرمجية.

يمكن بناء استعلام مركب متعدد المستويات كالتالي:
WHERE NOT A LIKE ‘TMP%’ AND NOT B LIKE ‘%Test%’ AND (NOT C LIKE ‘%Vendor%’ OR D > 5000)
في هذا النموذج، يقوم الاستعلام بتصفية المعاملات المؤقتة في العمود A، واستبعاد العمليات الاختبارية في العمود B، ثم تطبيق تصفية مركبة على العمودين C وD تستبعد الموردين غير المعتمدين إلا إذا تجاوزت قيمة معاملاتهم الحد المالي المقرر.

إن صياغة هذه السلاسل المنطقية بأسلوب تركيبي واضح واستخدام التنسيق المنظم يسهل مراجعة الأكواد البرمجية من قبل فرق العمل التحليلية، ويقلل من الوقت المستغرق في تصحيح الأخطاء المنطقية وتتبع مسار البيانات داخل المؤسسة.

6. حساسية حالة الأحرف (Case Sensitivity) والتعامل مع اللغات المتعددة

6.1 سلوك المعامل LIKE و NOT LIKE تجاه الأحرف الإنجليزية الكبيرة والصغيرة

من الخصائص الجوهرية التي يجب الإحاطة بها عند استخدام دالة QUERY في جداول بيانات جوجل هي أن لغة الاستعلام التابعة لـ Google Visualization API تُعد لغة حساسة لحالة الأحرف (Case-sensitive) بشكل افتراضي عند تقييم النصوص عبر المعاملين LIKE وNOT LIKE.

يترتب على هذه الخاصية أن النمط ‘%guard%’ لن يطابق النص الذي يحتوي على ‘Guard’ أو ‘GUARD’. وبالتالي، إذا تم كتابة الاستعلام لاستبعاد ‘%guard%’ بأحرف صغيرة فقط، فإن كافة السجلات التي تبدأ بأحرف كبيرة ستفلت من شرط الاستبعاد وستظهر في المخرجات، مما يؤدي إلى تشوه التقرير وتسلل البيانات غير المرغوبة إلى التحليل الإحصائي النهائي نتيجة اختلاف أسلوب إدخال البيانات النصية بين المستخدمين.

6.2 استخدام الدوال المساعدة LOWER و UPPER لمعالجة حساسية الأحرف

للتغلب على عائق حساسية حالة الأحرف وضمان شمولية التصفية الاستبعادية لكافة التكرارات النصية بغض النظر عن طريقة كتابتها، توفر لغة استعلام جداول بيانات جوجل دوال تحويل النصوص القياسية lower() وupper() التي يمكن تضمينها مباشرة داخل عبارة الاستعلام.

يتم تطبيق هذه المنهجية بتحويل قيم العمود المستهدف بالكامل إلى حالة موحدة برمجياً أثناء لحظة التقييم، مع كتابة النمط الاستبعادي بنفس الحالة المختارة. تُكتب المعادلة النموذجية كالتالي:
=QUERY(A1:C11, “SELECT * WHERE NOT lower(B) LIKE ‘%uar%'”, 1)

في هذا الاستعلام، تقوم الدالة lower(B) بتحويل كافة النصوص في العمود B إلى أحرف صغيرة افتراضياً داخل محرك الذاكرة قبل إجراء المطابقة، مما يضمن أن النمط ‘%uar%’ سيصطاد نصوص مثل ‘Guard’ و’GUARD’ و’gUaRd’ دون استثناء، محققاً تنقية تامة ومحكمة للبيانات دون الحاجة إلى إنشاء أعمدة مساعدة لتحويل النصوص في الورقة الأصلية.

6.3 خصوصية التعامل مع النصوص العربية والهمزات والتطابق الصوتي

يفرض التعامل مع النصوص باللغة العربية داخل استعلامات جداول بيانات جوجل تحديات خاصة ناجمة عن التباين الإملائي الشائع في إدخال الحروف المتشابهة؛ وأبرزها التباين بين أشكال الهمزات المختلفة (أ، إ، آ، ا)، والخلط بين الياء المقصورة والياء المنقوطة (ى، ي)، والتاء المربوطة والهاء (ة، هـ).

بما أن محرك الاستعلام يعامل هذه الحروف كمحارف برمجية مستقلة تماماً ذات ترميز يونيكود (Unicode) مختلف، فإن استبعاد نمط مثل ‘%إدارة%’ لن يستبعد السجلات المكتوبة بصيغة ‘ادارة’ أو ‘أدارة’. لتجاوز هذه العقبة وتأمين استبعاد شامل للأنماط العربية غير المتجانسة، يوصى بالاعتماد الاستراتيجي على الرمز البديل للخانة الفردية (_) محل الحرف الإشكالي.

فعلى سبيل المثال، عند كتابة النمط الاستبعادي كالتالي:
WHERE NOT B LIKE ‘%_دارة%’
يتم استبدال حرف الهمزة برمز الشرطة السفلية، مما يمكن الدالة من اصطياد واستبعاد كافة المتغيرات الإملائية للكلمة (‘إدارة’، ‘أدارة’، ‘ادارة’) دفعة واحدة وبأعلى كفاءة ممكنة. كما يمكن اللجوء إلى التعبيرات النمطية المعقدة عبر معاملات أخرى إذا تطلب الأمر مطابقة صوتية أكثر عمقاً.

7. الجمع بين NOT LIKE وشروط المقارنة الرقمية والزمنية في استعلام واحد

7.1 دمج استبعاد الأنماط النصية مع الشروط الحسابية والرقمية

تتطلب التطبيقات الواقعية لتحليل الأعمال مزج المعايير النصية مع القيود الرقمية الكمية لإنتاج تقارير إدارية ومالية عالية الدقة. تتيح دالة QUERY إمكانية دمج معاملات NOT LIKE النصية مع معاملات المقارنة الرياضية المعتادة (مثل >، =، <=، !=) داخل نفس عبارة WHERE بسلاسة تامة.

لنفترض وجود قاعدة بيانات للمعاملات المالية، حيث يحتوي العمود B على نوع العملية النصي، ويحتوي العمود C على القيمة المالية الصافية. لصياغة استعلام يستبعد العمليات الترويجية أو الاختبارية مع حصر المخرجات في المعاملات التي تتجاوز قيمتها 10,000 دولار، تُبنى الصيغة على النحو التالي:
=QUERY(A1:D100, “SELECT * WHERE NOT lower(B) LIKE ‘%promo%’ AND C > 10000”, 1)

من الضروري هنا الانتباه إلى التمييز الصارم بين أنواع البيانات؛ فالقيم الرقمية تُكتب داخل جملة الاستعلام كأرقام مجردة دون علامات اقتباس، بينما تظل الأنماط النصية محاطة بعلامات الاقتباس المفردة، لتفادي وقوع خطأ التعارض في نوع البيانات (Type Mismatch).

7.2 تضمين شروط التواريخ والأوقات بالتزامن مع معايير NOT LIKE

يعد التعامل مع التواريخ والأوقات داخل استعلامات جداول بيانات جوجل من العمليات الحساسة برمجياً، حيث يتطلب محرك Google Visualization API صياغة محددات التاريخ بنسق قياسي صارم مسبوقاً بالكلمة المفتاحية date، وبالتنسيق الدولي الموحد: ‘yyyy-MM-dd’.

عند الرغبة في تصفية سجلات نشاط زمني معين مع استبعاد أنشطة تصنيفية محددة عبر NOT LIKE، يتم بناء جملة الاستعلام بدمج المحدد الزمني مع المعامل النصي كما في النموذج التالي:
=QUERY(A1:E500, “SELECT * WHERE NOT B LIKE ‘%Maintenance%’ AND C >= date ‘2024-01-01′”, 1)

يقوم هذا الاستعلام باسترجاع كافة السجلات التشغيلية المسجلة ابتداءً من الأول من يناير لعام 2024 فصاعداً، مع استبعاد أي نشاط يحتوي على وصف ‘Maintenance’ في العمود B. هذا التكامل المتناغم بين الأنظمة الزمنية والتصفية النصية يتيح للشركات أتمتة إعداد تقارير الأداء الدورية واستخراج بيانات الإغلاق المالي الشهرية والسنوية بدقة متناهية ودون تدخل يدوي مستمر.

8. معالجة القيم الفارغة (Null/Blank Values) والأخطاء الشائعة عند استخدام NOT LIKE

8.1 سلوك دالة QUERY تجاه الخلايا الفارغة عند تطبيق شروط النفي

من أكثر المفاهيم المنطقية التباساً لدى مستخدمي دالة QUERY هو كيفية تعامل محرك الاستعلام مع الخلايا الفارغة (Null Values) عند تطبيق معاملات النفي مثل NOT LIKE. في المنطق الرياضي ثلاثي القيم (Three-Valued Logic) الذي تستند إليه لغات الاستعلام، فإن تقييم أي مقارنة نمطية مقابل خلية فارغة لا يُنتج TRUE ولا FALSE، بل يُنتج قيمة غير معرفة (UNKNOWN / NULL).

نتيجة لذلك، عند كتابة شرط مثل WHERE NOT B LIKE ‘%test%’، يقوم المحرك باستبعاد الصفوف التي تحتوي على نصوص لا تطابق النمط المطلوب، ولكنه في الوقت ذاته يُسقط تلقائياً كافة الصفوف التي يكون فيها العمود B فارغاً تماماً، لأن المحرك لا يستطيع إثبات نفي النمط على قيمة منعدمة.

إذا كان الغرض التحليلي يقتضي الاحتفاظ بالسجلات التي تحتوي على خلايا فارغة في عمود التصفية بجانب السجلات التي لا تطابق النمط، يجب التدخل منطقياً واستدعاء المعامل IS NULL بشكل صريح ودمجه عبر رابط OR، كالتالي:
WHERE (NOT B LIKE ‘%test%’) OR (B IS NULL)
تضمن هذه الإضافة البرمجية استعادة السجلات ذات الحقول الفارغة ومنع فقدانها من مصفوفة النتائج المستخرجة.

8.2 الأخطاء الشائعة (Syntax & Parsing Errors) وكيفية تشخيصها وتصحيحها

يواجه المحللون أثناء كتابة استعلامات NOT LIKE مجموعة من الأخطاء التشغيلية التي توقف عمل الدالة وتُرجع رسائل خطأ مثل #VALUE! أو #ERROR!. يتطلب التشخيص المنهجي لهذه المشكلات فهم الأسباب الجذرية وراء كل خطأ:

• أخطاء علامات الاقتباس والتنصيص (Quote Mismatches): تحدث عند نسيان إغلاق علامة الاقتباس المفردة المحيطة بالنمط النصي أو المزدوجة المحيطة بالاستعلام كاملاً، مما يؤدي إلى فشل المحلل اللغوي (Parser Error) في قراءة نهاية الأمر البرمجي.
• أخطاء تجانس البيانات (Data Type Inconsistency): تتطلب دالة QUERY أن يكون العمود المصدري متجانساً في نوع بياناته (نصوص فقط أو أرقام فقط). إذا كان العمود يحتوي على خليط من الأرقام والنصوص، يحدد المحرك نوع الأغلبية ويتعامل مع الأقلية كقيم فارغة (Nulls)، مما يؤدي إلى فشل مطابقة الأنماط النصية على الأرقام واختفائها من النتائج.
• أخطاء تسمية الأعمدة: استخدام معرفات الحروف (A, B) عند استعلام مصفوفات مجمعة تتطلب استخدام (Col1, Col2)، أو العكس، مما يؤدي إلى رسالة خطأ صريحة تفيد بعدم العثور على العمود المستهدف.

8.3 التعامل مع السلاسل النصية المحتوية على مسافات زائدة وفراغات مخفية

تعد المسافات البادئة (Leading Whitespaces) والمسافات اللاحقة (Trailing Whitespaces) والفراغات غير المرئية من أبرز العوامل الخفية التي تؤدي إلى إخفاق غير مبرر في مطابقة واستبعاد النصوص. على سبيل المثال، قد يفشل نمط يستهدف بادئة الكلمة مثل ‘text%’ إذا كانت الخلية تبدأ بمسافة فارغة مخفية (‘ text’).

لتفادي هذا الفشل التشغيلي وتأمين نقاء المدخلات قبل معالجتها بالاستعلام، يمكن تنظيف نطاق البيانات مسبقاً باستخدام دالة TRIM بالاقتران مع مصفوفة ديناميكية (ARRAYFORMULA)، أو تمرير النطاق المنظف مباشرة داخل مصفوفة دالة QUERY كالتالي:
=QUERY(ARRAYFORMULA(TRIM(A1:C11)), “SELECT * WHERE NOT Col2 LIKE ‘text%'”, 1)
يضمن هذا الأسلوب استئصال كافة الفراغات العشوائية وتوحيد المسافات البينية، مما يجعل مطابقة الأنماط النصية دقيقة وموثوقة بنسبة مئة بالمئة.

9. بدائل معالجة النصوص في جداول بيانات جوجل: مقارنة NOT LIKE مع NOT CONTAINS و MATCHES

9.1 المقارنة التفصيلية بين NOT LIKE و NOT CONTAINS

توفر لغة استعلام جداول بيانات جوجل معاملين متميزين للتعامل مع النصوص الجزئية: المعامل القياسي LIKE والمعامل المبسط CONTAINS. على الرغم من تشابه الغرض الوظيفي العام بينهما في التصفية، إلا أن هناك فروقاً هيكلية وعملية جوهرية تحدد متى يجب استخدام كل منهما.

يعتمد معامل LIKE بصورة أساسية على الرموز البديلة (% و _) للتحكم في موضع وطول النص المستهدف، مما يمنحه مرونة فائقة في التمييز بين البادئات واللاحقات والمقاطع الداخلية. في المقابل، يعمل المعامل NOT CONTAINS بشكل مباشر على استبعاد أي نص يحتوي على السلسلة الفرعية في أي موضع، دون الحاجة أو القابلية لاستخدام الرموز البديلة (مثل: WHERE NOT B CONTAINS ‘test’).

يتميز NOT CONTAINS بالبساطة وسرعة الكتابة في حالات البحث الجزئي العام غير المقيد بموضع محدد، ولكنه يفتقر تماماً إلى القدرة على تقييد الاستبعاد ببداية الكلمة أو نهايتها فقط أو حساب عدد خانات محدد، وهي المساحة الاحترافية التي ينفرد بها NOT LIKE بجدارة.

9.2 المقارنة المتقدمة مع التعبيرات النمطية (Regular Expressions) عبر NOT MATCHES

عندما تصل متطلبات التصفية إلى مستويات فائقة من التعقيد تتجاوز إمكانيات الرموز البديلة البسيطة، يبرز المعامل MATCHES ونظيره المنفي NOT MATCHES كأقوى أداة لمعالجة النصوص داخل دالة QUERY. يعتمد هذا المعامل كلياً على محرك التعبيرات النمطية (Regex).

يتيح NOT MATCHES استبعاد أنماط هيكلية بالغة التجريد؛ مثل استبعاد النصوص التي تحتوي على أرقام هواتف بصيغ محددة، أو عناوين بريد إلكتروني تنتمي لنطاقات معينة، أو نصوص تحتوي على تركيبات محرفية معقدة عبر استخدام محددات الكم والمجموعات الحرفية (مثل: [0-9], [A-Z], d+).

ومع ذلك، فإن القوة التعبيرية الهائلة لـ NOT MATCHES تأتي على حساب استهلاك الذاكرة وسرعة المعالجة البرمجية، بالإضافة إلى صعوبة قراءة وصيانة الشيفرة البرمجية مقارنة ببساطة ووضوح NOT LIKE. لذلك، تقتضي أفضل الممارسات الهندسية استخدام NOT LIKE للمهام النمطية القياسية، والاحتفاظ بـ NOT MATCHES للسيناريوهات الاستثنائية شديدة التعقيد.

9.3 جدول معياري لاختيار الأداة الأنسب بحسب طبيعة المهمة التحليلية

لتسهيل المفاضلة المنهجية واختيار المعامل الأمثل للمهمة التحليلية، يوضح الجدول الوصفي التالي المقارنة بين الأدوات الثلاث عبر المعايير التشغيلية الحاكمة:

• المعامل NOT LIKE:
  • المرونة الهيكلية: عالية جداً (تدعم التحكم في البدايات والنهايات وعدد الخانات عبر % و _).
  • حساسية حالة الأحرف: حساس افتراضياً (يتطلب دمج lower/upper).
  • كفاءة استهلاك الموارد: سريعة وخفيفة على الذاكرة في مجموعات البيانات الكبيرة.
  • مستوى التعقيد البرمجي: متوسط وسهل التعلم والصيانة.
• المعامل NOT CONTAINS:
  • المرونة الهيكلية: محدودة (مطابقة جزئية عامة دون تخصيص موضعي).
  • حساسية حالة الأحرف: حساس افتراضياً.
  • كفاءة استهلاك الموارد: فائقة السرعة للأبحاث النصية البسيطة.
  • مستوى التعقيد البرمجي: بسيط جداً ومباشر.
• المعامل NOT MATCHES:
  • المرونة الهيكلية: مطلقة (تدعم كافة قواعد التعبيرات النمطية RegEx).
  • حساسية حالة الأحرف: يمكن التحكم بها مباشرة عبر بادئات النمط مثل (?i).
  • كفاءة استهلاك الموارد: تستهلك طاقة معالجة أعلى، وقد تبطئ الملفات الضخمة.
  • مستوى التعقيد البرمجي: متقدم ويتطلب إتقان صياغة التعبيرات النمطية.

10. تحسين أداء الاستعلامات وتطبيق NOT LIKE على مجموعات البيانات الضخمة

10.1 إدارة استهلاك الذاكرة وسرعة الحساب في الملفات كثيفة البيانات

مع نمو حجم البيانات داخل جداول بيانات جوجل ووصولها إلى عشرات الآلاف من الصفوف، تصبح كفاءة المعالجة الحسابية وسرعة تحديث الشيت عاملاً حاسماً في استقرار النظام وتجربة المستخدم. تتطلب الإدارة الاحترافية لاستعلامات NOT LIKE اتباع استراتيجيات صارمة لترشيد استهلاك الذاكرة البرمجية.

أولى هذه الممارسات هي تجنب استخدام النطاقات المفتوحة غير المحددة مثل A:Z، حيث يجبر هذا النطاق محرك الدالة على مسح وتحليل ملايين الخلايا الفارغة في قاع الورقة وتطبيق شروط المطابقة النصية عليها دون طائل. بدلاً من ذلك، يجب حصر النطاق بدقة في حدود البيانات الفعلية (مثل A1:Z5000) أو استخدام نطاقات ديناميكية تستند إلى دوال الحساب التلقائي.

بالإضافة إلى ذلك، يلعب الترتيب المنطقي للشروط داخل عبارة WHERE دوراً جوهرياً في تسريع الاستجابة؛ حيث يُنصح بوضع الشروط الرقمية أو الفلاتر المنطقية الأكثر حسماً وسرعة في التقييم في بداية العبارة، وتأخير شروط NOT LIKE النصية المكلفة حسابياً إلى المراحل اللاحقة، مما يقلص حجم السجلات التي يتعين على محرك النصوص مسحها حرفاً بحرف.

10.2 استخدام المصفوفات الديناميكية والمراجع غير المباشرة لتوليد استعلامات مرنة

لبناء نماذج تحليلية ولوحات تحكم (Dashboards) احترافية وتفاعلية، يجب فصل منطق الاستعلام البرمجي عن الثوابت النصية؛ بحيث لا يضطر المستخدم النهائي لتعديل معادلة QUERY كلما رغب في استبعاد نمط نصي جديد. يتحقق ذلك بربط نص الاستعلام ديناميكياً بخلايا إدخال خارجية باستخدام معامل الدمج النصي (&).

إذا كانت الخلية F1 تحتوي على النمط المراد استبعاده من قبل المستخدم، يمكن صياغة المعادلة الديناميكية بالشكل التالي:
=QUERY(A1:C100, “SELECT * WHERE NOT lower(B) LIKE ‘%” & LOWER(F1) & “%'”, 1)

عند كتابة هذه الصيغة، يقوم المعامل & بدمج القيمة المدخلة في الخلية F1 مع بقية نص الاستعلام بسلاسة، مع تطبيق دالة LOWER لضمان التوافق اللغوي. يتيح هذا التصميم للمحللين والمديرين تغيير معايير التصفية والاستبعاد لحظياً بنقرة زر واحدة دون المساس بالبنية التحتية للمعادلات، مما يحمي جداول البيانات من أخطاء التعديل البشري غير المقصودة.

11. حالات دراسية واقعية وتطبيقات عملية في تحليل البيانات وإدارة الأعمال

11.1 الحالة الأولى: تصفية بيانات التجارة الإلكترونية واستبعاد الطلبات الملغاة والتجريبية

في منصات التجارة الإلكترونية وسجلات المبيعات الرقمية، غالباً ما تتداخل المعاملات الشرائية الحقيقية مع معاملات تجريبية يُجريها فريق التطوير لاختبار بوابات الدفع (تحتوي على بادئات مثل ‘TEST-‘ أو ‘DEV-‘)، بالإضافة إلى طلبات تم إلغاؤها أو استرجاعها وتوسيمها بلاحقة مثل ‘-CANC’ أو ‘-VOID’.

إذا تم احتساب هذه المعاملات في التقارير الإجمالية، ستؤدي إلى تضخيم زائف لأرقام المبيعات وتشوه مقاييس الأداء المالي الرئيسية (KPIs). لمعالجة هذه المعضلة واستخراج صافي الإيرادات الحقيقية بدقة تامة، يتم تطبيق استعلام استبعادي مركب كالتالي:

=QUERY(SalesData!A1:G10000, “SELECT Col1, Col3, Col5, Col7 WHERE NOT lower(Col2) LIKE ‘test%’ AND NOT lower(Col2) LIKE ‘dev%’ AND NOT lower(Col4) LIKE ‘%canc%'”, 1)

يحقق هذا الاستعلام عزلاً فورياً وتلقائياً لكافة المعاملات الوهمية والتجريبية والملغاة، مما يضمن تدفق بيانات مالية نقية وموثوقة بنسبة مئة بالمئة إلى لوحات الإدارة العليا والتقارير المحاسبية المعتمدة.

11.2 الحالة الثانية: تنقية سجلات الموارد البشرية وتصنيف الكوادر الوظيفية

تواجه إدارات الموارد البشرية (HR) في الشركات متعددة الجنسيات تحديات دورية عند إعداد تقارير كفاءة الأداء، وتوزيع المكافآت السنوية، وحساب معدلات دوران العمالة الخاصة بالموظفين الدائمين؛ حيث تتضمن قواعد البيانات المركزية كوادر مؤقتة، ومتدربين صيفيين، ومستشارين خارجيين بعقود محددة المدة.

تتضمن هذه السجلات توصيفات نصية داخل مسمى الوظيفة أو طبيعة العقد مثل ‘(Intern)’ أو ‘[Contractor]’ أو ‘Temp Staff’. لإنشاء تقرير استراتيجي يقتصر على الكوادر الدائمة المستقرة، يتم توظيف NOT LIKE بالشكل التالي:

=QUERY(HR_Master!A1:E2500, “SELECT A, B, C, E WHERE NOT B LIKE ‘%(Intern)%’ AND NOT B LIKE ‘%[Contractor]%’ AND NOT D LIKE ‘Temp%'”, 1)

يضمن هذا الاستعلام عزل الكوادر غير المستهدفة بالتقييم السنوي التلقائي، ويوفر للقيادة التنفيذية رؤية واقعية ودقيقة حول القوة العاملة الأساسية المؤثرة في الإنتاجية طويلة الأجل.

11.3 الحالة الثالثة: تنظيف بيانات العملاء والبريد الإلكتروني من الحسابات الوهمية

في عمليات التسويق الرقمي وإدارة علاقات العملاء (CRM)، تعاني قواعد بيانات المشتركين باستمرار من تسجيل عناوين بريد إلكتروني وهمية أو مؤقتة تُنشأ عبر خدمات النطاقات المتاح استخدامها لمرة واحدة (مثل ‘mailinator.com’ أو ‘tempmail.com’ أو ’10minutemail.com’).

يؤدي إرسال الحملات الإعلانية إلى هذه العناوين الوهمية إلى ارتفاع معدل الارتداد (Bounce Rate)، مما يضر بالسمعة الرقمية لنطاق الشركة (Domain Reputation) لدى مزودي خدمات البريد ويخفض معدلات الوصول إلى صناديق الوارد للعملاء الحقيقيين. يمكن أتمتة عملية تنظيف جهات الاتصال بصورة لحظية باستخدام الصيغة التالية:

=QUERY(Subscribers!A1:D50000, “SELECT A, B, C WHERE NOT lower(C) LIKE ‘%@mailinator.com’ AND NOT lower(C) LIKE ‘%@tempmail.com’ AND NOT lower(C) LIKE ‘%@10minutemail.com'”, 1)

تؤمن هذه العملية البرمجية حماية فورية للحملات التسويقية، وترفع من معدلات التسليم المباشر والتحويل التجاري، وتخفض التكاليف التشغيلية الناتجة عن تخزين ومراسلة جهات اتصال عديمة القيمة التسويقية.

12. أفضل الممارسات المنهجية وإرشادات استكشاف الأخطاء وإصلاحها في استعلامات NOT LIKE

12.1 قواعد التوثيق والتنظيم البرمجي لمعادلات QUERY المعقدة

تتطلب الاستعلامات المتقدمة وطويلة الأسطر تنظيماً برمجياً صارماً لمنع تحولها إلى صيغ غامضة وغير قابلة للصيانة من قبل المحللين الآخرين داخل المنظمة. من أفضل الممارسات المتبعة في هذا الشأن استخدام فواصل الأسطر (الضغط على Ctrl + Enter أو Cmd + Enter داخل شريط الصيغة) لتقسيم جملة الاستعلام إلى فقرات وظيفية واضحة ومقروءة.

كما يوصى بشدة بالاعتماد على النطاقات المسماة (Named Ranges) بدلاً من مراجع الخلايا الجامدة؛ فاستخدام اسم معبر مثل Transactions_2024 بدلاً من ‘Sheet1’!A1:M5000 يجعل قراءة المعادلة بديهية ويقلل من فرص الخطأ عند تعديل النطاقات لاحقاً.

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

12.2 قائمة التحقق المنهجية لمراجعة الصيغ وحل المشكلات التشغيلية (Troubleshooting Checklist)

عند مواجهة سلوك غير متوقع أو فشل في تنفيذ استعلام NOT LIKE، يُنصح باتباع قائمة التحقق المنهجية التالية لعزل الخلل وإصلاحه خطوة بخطوة:

• التحقق من مواضع الرموز البديلة: تأكد من أن رمز % موضوع في مكانه الصحيح لعزل النمط (في البداية، النهاية، أو كلاهما) وأنك لم تستخدم رمزاً غير متوافق.
• مطابقة علامات الاقتباس: تأكد من أن الاستعلام ككل محاط بعلامات اقتباس مزدوجة (“”)، وأن كافة الأنماط النصية الداخلية محاطة بعلامات اقتباس مفردة (”) دون زيادة أو نقصان.
• توحيد حالة الأحرف: تأكد من إدراج دالة lower() أو upper() على العمود المصدري إذا كنت ترغب في استبعاد النصوص دون تأثر بحالة الأحرف الإنجليزية.
• معالجة القيم الفارغة (Nulls): إذا اختفت صفوف تحتوي على خلايا فارغة ترغب في الاحتفاظ بها، أضف شرط OR [Col] IS NULL إلى عبارة WHERE.
• فحص تجانس البيانات: تأكد من أن العمود الموجه إليه الاستعلام لا يحتوي على مزيج عشوائي من النصوص والأرقام، وقم بتوحيد تنسيق العمود من قائمة التنسيق المسبق للبيانات.
• الاختبار على عينة مصغرة: قم باختبار المعادلة على نطاق بيانات مصغر يحتوي على 5 إلى 10 صفوف تمثل كافة الحالات الحدية للتحقق من استجابة الاستعلام قبل تعميمه على مصفوفة البيانات الكبرى.

12.3 الخلاصة والتوصيات المستقبلية لاستخدام لغة الاستعلام باحترافية

يمثل معامل النفي النمطي NOT LIKE أداة تحليلية محورية في ترسانة أي باحث أو محلل بيانات يعتمد على منظومة جداول بيانات جوجل. إن القدرة على استبعاد الأنماط النصية الجزئية بدقة فائقة لا تسهم فقط في تنقية وتطهير قواعد البيانات الضخمة، بل تمثل حجر الزاوية لبناء تقارير ذكية، ديناميكية، وموثوقة تعكس الأداء الحقيقي للأعمال دون تشويش إحصائي.

يتطلب الاستخدام الاحترافي لهذه الأداة فهماً عميقاً للتفاعل بين المنطق البولياني، ورموز المطابقة البديلة، وحساسية اللغات المتعددة، وإدارة الذاكرة الحسابية. ومع التطور المتسارع في منصات التحليل السحابية، يظل إتقان لغة استعلام Google Visualization API مدخلاً أساسياً للانتقال بسلاسة نحو نظم قواعد البيانات العلائقية الأكثر تقدماً مثل BigQuery وPostgreSQL.

ختاماً، نوصي بمواصلة تطبيق أفضل الممارسات البرمجية، والمراجعة الدورية للاستعلامات المركبة، والجمع المنهجي بين دوال التنظيف المسبق واستعلامات QUERY المتقدمة، لضمان أعلى درجات الدقة والنزاهة للبيانات عبر كافة الأنشطة التحليلية والبحثية.

المراجع (References)

• Google. (2024). QUERY function reference in Google Sheets. Google Docs Editors Help. https://support.google.com/docs/answer/3093343
• Google Developers. (2023). Google Visualization API Query Language Reference. Google Developers Documentation. https://developers.google.com/chart/interactive/docs/querylanguage
• Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill Education.
• Date, C. J. (2019). An Introduction to Database Systems (8th ed.). Pearson Education.
• W3Schools. (2024). SQL LIKE and Wildcards Operators. W3Schools Online Web Tutorials. https://www.w3schools.com/sql/sql_like.asp
• Friedl, J. E. (2006). Mastering Regular Expressions (3rd ed.). O’Reilly Media.
• Google. (2024). TRIM function in Google Docs. Google Support. https://support.google.com/docs/answer/3094140