استعلام جداول بيانات جوجل: كيفية استخدام WHERE IN في قائمة

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

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

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

1. مقدمة تأصيلية لدالة QUERY في جداول بيانات جوجل (Google Sheets)

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

تستند دالة QUERY في جداول بيانات جوجل إلى بروتوكول Google Visualization API Query Language، وهي لغة برمجية مبسطة مخصصة لاستخراج البيانات المنظمة ومعالجتها مباشرة في الذاكرة الحسابية السحابية. تختلف هذه اللغة عن معايير SQL الكلاسيكية مثل ANSI SQL في عدة جوانب معمارية؛ حيث تتعامل مع النطاقات الجغرافية للخلايا داخل ورقة العمل بدلاً من الجداول وقواعد البيانات الفعلية. يتم تمرير النطاق كمعامل أول في الدالة، مثل A1:Z100، في حين يكون المعامل الثاني عبارة عن سلسلة نصية تمثل جملة الاستعلام البرمجية المحاطة بعلامات اقتباس مزدوجة.

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

تكمن الأهمية الجوهرية لدالة QUERY في قدرتها على دمج عمليات استرجاع البيانات، والتصفية الصفية، والتجميع الرياضي، والفرز الهيكلي، وإعادة تسمية الترويسات وتنسيق القيم الرقمية في عملية حسابية واحدة. بدلاً من الاعتماد على دوال متتالية مثل FILTER و SORT و UNIQUE و SUMIFS، يقوم محرك دالة QUERY بمعالجة البيانات دفعة واحدة، مما يقلل العبء الحوسبي على خوادم جداول بيانات جوجل ويسرع زمن استجابة الملفات التحليلية الضخمة.

1.2 موقع شرط التصفية (WHERE) ضمن التسلسل المنطقي للاستعلام

يحتل شرط التصفية WHERE موقعاً محورياً واستراتيجياً داخل التسلسل الهرمي لجملة الاستعلام. في قواعد لغة Google Visualization API، يجب أن تتبع العبارات البرمجية ترتيباً نحوياً صارماً وغير قابل للتغيير، حيث تبدأ الجملة بعبارة SELECT لتحديد الأعمدة المطلوبة، تليها مباشرة عبارة WHERE لتصفية الصفوف، ثم عبارات التجميع والتنسيق الإضافية مثل GROUP BY و PIVOT و ORDER BY و LIMIT و OFFSET و LABEL وأخيراً FORMAT. إن الإخلال بهذا الترتيب يؤدي فوراً إلى توقف المحرك وإرجاع خطأ تركيبي في معالجة السلسلة النصية.

تعمل عبارة WHERE كبوابة ترشيح أولية للسجلات على مستوى الصفوف الفردية قبل تنفيذ أي عمليات تجميعية أو إعادة هيكلة للبيانات. يقوم المحرك بفحص كل صف في النطاق المحدد ومطابقته مع المعايير المنطقية المحددة في شرط التصفية. إذا كانت النتيجة المنطقية مطابقة (True)، يتم تمرير الصف إلى المراحل اللاحقة من خط أنابيب المعالجة (Processing Pipeline)؛ أما إذا كانت النتيجة خاطئة (False)، فيتم استبعاد الصف تماماً من الذاكرة اللحظية للاستعلام.

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

1.3 إشكالية غياب المعامل المباشر IN ومفهوم المحاكاة التعبيرية

في بيئات قواعد البيانات التقليدية مثل MySQL أو PostgreSQL أو Microsoft SQL Server، يمثل المعامل IN أداة بديهية لا غنى عنها للمطورين لتصفية السجلات بناءً على قائمة محددة من القيم، مثل صياغة الاستعلام كالتالي: WHERE Department IN (‘Sales’, ‘Marketing’, ‘Finance’). إلا أن مهندسي جوجل، عند تصميم واجهة Google Visualization API، لم يضمنوا هذا المعامل كجزء من الكلمات المحجوزة في لغة الاستعلام، مما يخلق عائقاً تقنياً ظاهرياً للمستخدمين الذين يحتاجون إلى مطابقة قيم أعمدتهم مع قوائم متعددة العناصر.

في غياب هذا المشغل المباشر، يضطر بعض المستخدمين المبتدئين إلى كتابة سلاسل مطولة وغير عملية من الشروط المنطقية باستخدام المعامل OR، مثل صياغة: WHERE Department = ‘Sales’ OR Department = ‘Marketing’ OR Department = ‘Finance’. ومع اتساع القائمة لتشمل عشرات أو مئات القيم، يصبح هذا الأسلوب شديد التعقيد، وعرضة للأخطاء النحوية، وغير قابل للصيانة أو الأتمتة الديناميكية داخل المؤسسات.

يكمن الحل الجذري والمنهجي لهذه الإشكالية في توظيف مشغل التعبيرات النمطية MATCHES المتاح داخل لغة الاستعلام. يتيح هذا المشغل المتطور مقارنة محتويات الخلايا مع تعبيرات نمطية منتظمة (Regular Expressions). من خلال استغلال الرمز الرياضي البديل (|) داخل النمط، يمكن محاكاة عمل المعامل IN بدقة تامة وبصيغة مضغوطة للغاية، مما يحقق مرونة غير محدودة في التعامل مع القوائم الثابتة والديناميكية على حد سواء.

2. المفهوم النظري لمحاكاة جملة WHERE IN باستخدام المعامل MATCHES

2.1 التحليل الدلالي للتعبير النمطي MATCHES وخصائصه

يعمل مشغل MATCHES داخل بيئة استعلام جداول بيانات جوجل كأداة مطابقة أنماط متقدمة تستند إلى قواعد التعبيرات النمطية المعتمدة في لغة جافا (Java Regex Engine). يختلف مشغل MATCHES جوهرياً عن مشغلات التصفية النصية الأخرى المتوفرة في الدالة، مثل CONTAINS و LIKE، في طبيعة وشمولية التحقق من السلسلة النصية المستهدفة داخل الخلية.

بينما يبحث المشغل CONTAINS عن وجود مقطع نصي جزئي في أي موقع داخل الخلية دون النظر إلى بداية السلسلة أو نهايتها، ويعتمد المشغل LIKE على محارف البدل التقليدية مثل علامة النسبة المئوية (%) والشرطة السفلية (_) لمطابقة الأنماط، يتطلب المشغل MATCHES مطابقة تامة وشاملة لكامل محتوى الخلية من أول محرف إلى آخره. هذا يعني أن التعبير النمطي الممرر يجب أن يصف بنية الخلية بالكامل لكي يتم تقييم النتيجة على أنها إيجابية وصحيحة.

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

2.2 دور المعامل المنطقي البديل (|) في محاكاة دالة الاختيار (OR)

في علم اللغات الشكلية والتعبيرات النمطية، يمثل رمز الخط العمودي الرأسي | (Pipe Operator) المعامل المنطقي للتناوب أو البديل (Alternation)، وهو المكافئ الدقيق للبوابة المنطقية OR في الجبر البولياني. عند وضع الرمز | بين قيمتين نصيتين داخل التعبير النمطي، مثل (Apple|Banana)، يقوم المحرك باختبار السلسلة النصية لمعرفة ما إذا كانت تطابق القيمة الأولى “Apple” أو القيمة الثانية “Banana”.

لضمان التحكم الدقيق في نطاق سريان هذا المعامل البديل ومنع تداخله مع أي محددات أخرى داخل الاستعلام، يتم تجميع عناصر القائمة المستهدفة إجبارياً داخل أقواس تنظيمية دائرية. صياغة النمط بالشكل ‘(Sales|Marketing|Human Resources)’ تخلق مجموعة التقاط نمطية (Regex Group) تفيد بأن السلسلة النصية المقبولة يجب أن تكون واحدة حصراً من هذه الخيارات الثلاثة المحددة داخل القوسين.

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

2.3 آلية المعالجة المنطقية داخل محرك جداول بيانات جوجل

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

ثانياً، يتم تمرير القيمة النصية المستخرجة إلى آلة الحالات المنتهية المحددة (Deterministic Finite Automaton – DFA) المسؤولة عن معالجة التعبير النمطي. تختبر الآلة ما إذا كانت السلسلة النصية للخلية تتطابق بالكامل مع أي من المسارات المحددة بين رموز الفصل الرأسية (|). إذا وجد المحرك مساراً مطابقاً بنسبة مئة بالمئة لأحد عناصر القائمة، تتوقف عملية الفحص للخلية الحالية وتُرجع الدالة القيمة المنطقية TRUE فوراً.

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

3. الصياغة النحوية (Syntax) القياسية لتطبيق WHERE IN مع البيانات النصية

3.1 الهيكل القياسي للصيغة البرمجية الثابتة

تتطلب الصياغة النحوية لتطبيق شرط محاكاة WHERE IN باستخدام المعامل MATCHES التزاماً دقيقاً بقواعد تضمين السلاسل النصية والاقتباس في لغة استعلام تصور جوجل. الهيكل الرياضي العام للمعادلة يتبع النمط المعياري التالي:

=QUERY(A1:D100, “SELECT * WHERE A MATCHES ‘(قيمة1|قيمة2|قيمة3)'”, 1)

في هذا التركيب الهيكلي، يُحاط الاستعلام البرمجي بالكامل بعلامات اقتباس مزدوجة (” “)، بينما يُحاط التعبير النمطي الخاص بالمعامل MATCHES بعلامات اقتباس مفردة (‘ ‘) لتمييزه كسلسلة نصية فرعية داخل نص الاستعلام الرئيسي. غياب أي من هذه العلامات أو وضعها في غير موضعها الصحيح يفسده المحرك ويعتبره خطأ نحوياً يمنع تنفيذ الدالة.

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

3.2 حساسية حالة الأحرف (Case Sensitivity) في النصوص

من الخصائص الجوهرية لمشغل MATCHES في دالة QUERY أنه حساس لحالة الأحرف (Case-Sensitive) بصورة افتراضية عند التعامل مع النصوص المكتوبة باللغات اللاتينية (مثل الإنجليزية والفرنسية). هذا يعني أن القيمة “Sales” تختلف تماماً في المنطق الحسابي للمحرك عن “sales” أو “SALES”. إذا كانت بيانات المصدر تحتوي على تباين في إدخال الأحرف الكبيرة والصغيرة، فإن المطابقة النمطية المباشرة قد تتجاهل سجلات هامة.

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

=QUERY(A1:D100, “SELECT * WHERE lower(A) MATCHES ‘(sales|marketing|finance)'”, 1)

أما الطريقة الثانية، فتعتمد على استغلال محددات التعبيرات النمطية المتطورة من خلال إضافة بادئة تعطيل حساسية الأحرف (?i) في بداية التعبير النمطي داخل علامات الاقتباس المفردة، كالتالي:

=QUERY(A1:D100, “SELECT * WHERE A MATCHES ‘(?i)(Sales|Marketing|Finance)'”, 1)

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

3.3 التعامل مع النصوص متعددة الكلمات والفراغات

غالباً ما تحتوي قواعد البيانات الواقعية على مسميات تتألف من كلمات متعددة مفصولة بمسافات بيضاء، مثل أسماء الإدارات المركبة (“Human Resources”, “Research and Development”) أو أسماء المدن والمنتجات. في هذه الحالات، يجب التعامل مع الفراغات بدقة متناهية داخل التعبير النمطي للمعامل MATCHES.

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

=QUERY(A1:D100, “SELECT * WHERE A MATCHES ‘(Human Resources|Research & Development)'”, 1)

يجب الحذر الشديد من إدراج مسافات إضافية قبل أو بعد رمز الفصل الرأسي (|). فكتابة ‘(Human Resources | Research & Development)’ تعني أن المحرك سيبحث عن نص ينتهي بمسافة بعد كلمة Resources أو يبدأ بمسافة قبل كلمة Research، وهو ما سيؤدي حتماً إلى عدم مطابقة الخلايا النظيفة التي لا تحتوي على تلك الفراغات الزائدة. يُعد الانضباط في ضبط المسافات البيضاء أحد أهم معايير سلامة استعلامات التصفية المتقدمة في بيئات العمل الاحترافية.

4. التطبيق العملي لتصفية النصوص: دراسة حالة تطبيقية

4.1 إعداد مجموعة البيانات النموذجية وتحديد المتغيرات

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

تتوزع السجلات في هذا الجدول على فرق متعددة تشمل: “Mavs”، “Magic”، “Kings”، “Lakers”، “Warriors”، “Celtics”، و “Bulls”. الهدف التحليلي هو استخراج كافة السجلات والصفوف التي تنتمي حصراً إلى أربعة فرق مستهدفة محددة في القائمة التالية: (Mavs, Magic, Kings, Lakers)، مع استبعاد أي فرق أخرى من التقرير النهائي.

يمثل العمود A في هذه الحالة متغير التصفية الأساسي (Filter Target Column)، بينما تمثل عناصر القائمة الأربعة معايير التحقق المشروطة. إن استخراج هذه البيانات بدقة يتطلب بناء استعلام محكم يستبعد تلقائياً فرق “Warriors” و”Celtics” و”Bulls” دون التأثير على الترويسات أو سلامة الأرقام الإحصائية المرافقة في العمودين B و C.

4.2 كتابة وتنفيذ استعلام التصفية على البيانات الفعلية

لتطبيق معايير التصفية المحددة في دراسة الحالة، نقوم بكتابة الصيغة التنفيذية لدالة QUERY في خلية منفصلة مخصصة لعرض التقرير (ولتكن الخلية E1) بالشكل البرمجي التالي:

=QUERY(A1:C11, “SELECT * WHERE A MATCHES ‘(Mavs|Magic|Kings|Lakers)'”, 1)

عند إدخال هذه الصيغة وضغط مفتاح الإدخال، يبدأ محرك جداول بيانات جوجل بفحص الصفوف العشرة للبيانات تباعاً. يطابق المحرك قيمة العمود A في كل صف مع التعبير النمطي الجماعي. في الصفوف التي يظهر فيها اسم “Mavs” أو “Magic” أو “Kings” أو “Lakers”، يتم التحقق من الشرط بنجاح، ويتم جلب الصف بالكامل بما يحتويه من بيانات في الأعمدة A و B و C.

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

4.3 تحليل المخرجات وضمان سلامة البيانات المسترجعة

عند تدقيق مصفوفة البيانات المسترجعة من الاستعلام، يتبين أن المعامل الثالث في الدالة، وهو الرقم 1، لعب دوراً حاسماً في الحفاظ على الصف الأول من النطاق (A1:C1) كصف ترويسة رئيسي للأعمدة (Headers)، مما يضمن بقاء أسماء الحقول “Team” و “Position” و “Points” واضحة في أعلى التقرير المولد دون تكرار أو حذف.

في الحالات التي لا تسفر فيها عملية التصفية عن أي تطابق—كأن نقوم بالبحث عن فرق غير موجودة إطلاقاً في الجدول الأصلي—فإن دالة QUERY ترجع خطأ من نوع #N/A يفيد بعدم العثور على صفوف مطابقة (Query completed with an empty output). لضمان المظهر الاحترافي للتقارير المؤسسية وتجنب ظهور رسائل الأخطاء للمستخدمين النهائيين، يوصى دائماً بتغليف دالة الاستعلام داخل دالة IFERROR كالتالي:

=IFERROR(QUERY(A1:C11, “SELECT * WHERE A MATCHES ‘(Mavs|Magic|Kings|Lakers)'”, 1), “لا توجد بيانات مطابقة لمعايير البحث”)

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

5. تطبيق شرط القائمة على القيم والبيانات الرقمية (Numeric Values)

5.1 الفروق الجوهرية بين معالجة النصوص والأرقام داخل MATCHES

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

تتمثل القاعدة الأساسية عند تصفية الأرقام باستخدام MATCHES في عدم إحاطة الأرقام الفردية داخل النمط بعلامات اقتباس مفردة مستقلة، بل يتم وضع القائمة الرقمية بالكامل كنمط نصي موحد داخل علامات الاقتباس المفردة المخصصة لمشغل MATCHES نفسه. على سبيل المثال، لتصفية عمود النقاط (العمود C) لاستخراج السجلات التي تحتوي حصراً على القيم 10 أو 20 أو 30، تتم كتابة الصيغة على النحو التالي:

=QUERY(A1:C100, “SELECT * WHERE C MATCHES ‘(10|20|30)'”, 1)

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

5.2 مطابقة الأرقام الدقيقة مقابل الأرقام العشرية

تستوجب التصفية الرقمية عبر التعبيرات النمطية دقة شديدة لتفادي التداخل بين الأرقام المتشابهة. نظراً لأن المشغل MATCHES يتطلب مطابقة كاملة للخلية، فإن التعبير ‘(10|20)’ لن يطابق بالخطأ الأرقام 100 أو 200 أو 105؛ لأن المحرك يتحقق من أن الخلية تبدأ وتنتهي بالرقم المحدد دون أي زيادات محرفية.

ومع ذلك، تظهر التعقيدات عند التعامل مع الأرقام العشرية (Floating-point Numbers). في لغة التعبيرات النمطية، تمثل النقطة . محرفاً خاصاً يعني “مطابقة أي محرف مفرد”. فإذا كتبنا النمط ‘(10.5|20.5)’، فإن النقطة هنا ستطابق النقطة العشرية، ولكنها قد تطابق أيضاً أي رمز آخر يقع بين الرقمين، مثل “10-5” أو “10a5”.

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

5.3 تجنب تضارب الأنواع البيانية (Data Type Conflicts)

من أهم القواعد المعمارية الصارمة في دالة QUERY هي قاعدة “النوع البياني الغالب” (Majority Data Type Rule). يحدد محرك الدالة نوع البيانات المسموح به في كل عمود بناءً على النوع الذي يشغل النسبة الأكبر من خلايا ذلك العمود (سواء كان نصاً، أو رقماً، أو تاريخاً). إذا احتوى عمود رقمي على بعض الخلايا النصية، فإن الدالة قد تتجاهل تلك الخلايا وتعتبرها قيماً فارغة (Nulls).

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

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

6. التصفية الديناميكية المتقدمة: الربط التفاعلي مع نطاق خلايا خارجي

6.1 الحاجة المنهجية للقوائم الديناميكية في تحليل البيانات

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

تقتضي المنهجية المتقدمة فصل منطق الحساب عن معايير الإدخال، وذلك من خلال السماح للمستخدم باختيار عناصر القائمة المستهدفة من خلال نطاق خلايا خارجي مستقل (مثل إدخال أسماء الفرق أو المنتجات في العمود E)، أو عبر أدوات واجهة المستخدم مثل القوائم المنسدلة للتحقق من صحة البيانات (Data Validation Dropdowns).

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

6.2 استخدام دالة TEXTJOIN لبناء التعبير النمطي تلقائيًا

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

إذا كانت معايير التصفية المطلوبة مدخلة في الخلايا من E1 إلى E4، يمكن بناء السلسلة النمطية باستخدام الصيغة التالية:

TEXTJOIN(“|”, TRUE, E1:E4)

تقوم هذه الصيغة بدمج محتويات الخلايا وتضع الرمز الرأسي (|) بين كل قيمة وأخرى، لتنتج سلسلة نصية متكاملة بالشكل: “Mavs|Magic|Kings|Lakers”. إذا كانت إحدى الخلايا في النطاق فارغة، تتجاهلها الدالة بفضل المعامل المنطقي TRUE، وتنتج نمطاً نظيفاً وخالياً من الفواصل الزائدة المزدوجة.

لدمج هذه السلسلة الديناميكية داخل استعلام دالة QUERY، نستخدم معامل الربط النصي & لدمج أجزاء الاستعلام الثابتة مع المخرجات المتغيرة للدالة، كما يتضح في الهيكل التالي:

=QUERY(A1:C11, “SELECT * WHERE A MATCHES ‘(” & TEXTJOIN(“|”, TRUE, E1:E4) & “)'”, 1)

تجمع هذه الصيغة بين القوة الهيكلية لدالة QUERY والمرونة المطلقة لدالة TEXTJOIN، مما ينتج استعلاماً تفاعلياً فائق التطور يلبي أعلى معايير هندسة جداول البيانات المؤسسية.

6.3 استخدام دالة JOIN كبديل وإدارة النطاقات المتغيرة

قبل ظهور دالة TEXTJOIN، كانت دالة JOIN هي الوسيلة التقليدية المتاحة لدمج النصوص في جداول بيانات جوجل. على الرغم من أن دالة JOIN تؤدي نفس الغرض الأساسي، إلا أنها تعاني من عيب هيكلي يتمثل في عدم قدرتها الذاتية على تخطي الخلايا الفارغة؛ حيث تقوم بدمج الفواصل حتى لو كانت الخلية خالية، مما ينتج تعبيراً نمطياً مشوهاً مثل “Mavs||Kings”.

إذا اضطر المحلل لاستخدام دالة JOIN مع نطاق خلايا مفتوح ومتغير الأبعاد (مثل E1:E)، يجب دمجها مسبقاً مع دالة FILTER لتنقية النطاق واستبعاد الخلايا الفارغة قبل تمريرها لعملية الدمج، كالتالي:

JOIN(“|”, FILTER(E1:E, E1:E “”))

ومع ذلك، تظل الصيغة الشاملة المعتمدة على TEXTJOIN مع النطاقات المفتوحة هي المعيار الذهبي الأحدث والأكثر أماناً، حيث يمكن كتابتها بالصيغة المتكاملة التالية:

=QUERY(A1:C11, “SELECT * WHERE A MATCHES ‘(” & TEXTJOIN(“|”, TRUE, E1:E) & “)'”, 1)

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

7. الربط الشرطي المعقد: دمج MATCHES مع الشروط المنطقية المتعددة

7.1 الجمع بين شروط قائمة متعددة على أعمدة مختلفة

تتعاظم القوة التحليلية لدالة QUERY عند دمج محاكاة WHERE IN عبر أعمدة متعددة في نفس الوقت لتلبية استفسارات إحصائية مركبة. تتيح لغة الاستعلام الجمع بين مشغلات MATCHES متعددة باستخدام المعاملات المنطقية القياسية AND و OR.

لنفترض أننا نريد استخراج السجلات التي ينتمي فيها اللاعب إلى قائمة فرق محددة (العمود A) وفي نفس الوقت يشغل أحد مراكز محددة في قائمة أخرى كأن يكون حارساً أو مهاجماً (العمود B). يتم بناء الاستعلام المركب بالصيغة التالية:

=QUERY(A1:D100, “SELECT * WHERE A MATCHES ‘(Mavs|Lakers)’ AND B MATCHES ‘(Guard|Forward)'”, 1)

يقوم محرك الاستعلام في هذه الحالة بفحص جدول الحقيقة المنطقي (Truth Table) لكل صف؛ حيث يجب أن تُرجع مقارنة العمود A القيمة TRUE بالتزامن مع إرجاع مقارنة العمود B للقيمة TRUE لكي يتم قبول الصف وإدراجه في التقرير. يتيح هذا الدمج المتعدد بناء تقارير تصفية شديدة التعقيد والتخصيص بدقة إجرائية بالغة.

7.2 المزج بين شروط القوائم والمقارنات الكمية الرياضية

لا تقتصر تصفية البيانات على مطابقة القوائم النصية فحسب، بل تمتد لتشمل المزج بين القوائم النمطية والشروط الرياضية المقارنة مثل معاملات الأكبر من (>)، والأصغر من (=)، وأصغر من أو يساوي (<=)، ولا يساوي (!=).

في سياق دراسة الحالة الرياضية، إذا أردنا استخراج لاعبي الفرق المحددة (Mavs, Magic, Kings, Lakers) بشرط أن يكون إجمالي نقاط اللاعب المسجلة في العمود C يتجاوز 20 نقطة، يتم دمج الشروط في الاستعلام التالي:

=QUERY(A1:C11, “SELECT * WHERE A MATCHES ‘(Mavs|Magic|Kings|Lakers)’ AND C > 20”, 1)

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

7.3 أسبقية العمليات المنطقية وضبط الأقواس الإنشائية

عند بناء استعلامات تشتمل على خليط معقد من معاملات AND و OR المتعددة، تبرز مسألة أسبقية العمليات المنطقية (Operator Precedence). في القواعد المنطقية للغة الاستعلام، يمتلك المعامل AND أسبقية تقييم أعلى من المعامل OR، مما يعني أن المحرك سينفذ عمليات العطف المنطقي قبل عمليات التخيير ما لم يتم توجيهه بخلاف ذلك.

لتفادي استرجاع بيانات خاطئة أو غير مقصودة نتيجة الأسبقية التلقائية، يجب استخدام الأقواس الإنشائية الدائرية داخل نص الاستعلام لتحديد الأولويات بوضوح لا يقبل اللبس. تأمل الاستعلام التالي الذي يستهدف استخراج بيانات فريقي Mavs أو Lakers بشرط تجاوز النقاط 20، أو استخراج أي لاعب من فريق Warriors بغض النظر عن نقاطه:

=QUERY(A1:C11, “SELECT * WHERE (A MATCHES ‘(Mavs|Lakers)’ AND C > 20) OR A = ‘Warriors'”, 1)

تضمن الأقواس هنا تقييم الشرط المركب الأول كوحدة منطقية متكاملة قبل تطبيق شرط التخيير الخارجي، مما يعكس بدقة متناهية الرؤية التحليلية المطلوبة ويمنع تداخل السجلات وتشويه دقة التقارير المؤسسية.

8. الاستبعاد والنفي: محاكاة شرط WHERE NOT IN

8.1 صياغة النفي باستخدام المشغل المنطقي NOT

كما تمثل تصفية السجلات بناءً على وجودها في قائمة ضرورة تحليلية، فإن استبعاد السجلات بناءً على قائمة محظورة يمثل العملية العكسية المكافئة لشرط WHERE NOT IN في لغة SQL المعيارية. توفر دالة QUERY في جداول بيانات جوجل المشغل المنطقي NOT لتنفيذ عمليات النفي البرمجي بدقة وكفاءة عالية.

لمحاكاة جملة WHERE NOT IN واستبعاد قائمة محددة من الفرق من مخرجات التقرير، يتم وضع المشغل NOT مباشرة قبل اسم العمود المتبوع بمشغل MATCHES، وفق البنية الهيكلية التالية:

=QUERY(A1:C11, “SELECT * WHERE NOT A MATCHES ‘(Mavs|Magic|Kings|Lakers)'”, 1)

عند تنفيذ هذا الاستعلام، يقوم المحرك بعكس القيمة المنطقية الناتجة عن المطابقة؛ فإذا كان الفريق موجوداً داخل القائمة النمطية، تصبح النتيجة النهائية FALSE ويتم إسقاطه، أما إذا كان الفريق غير موجود في القائمة (مثل Warriors و Celtics)، فتصبح النتيجة TRUE ويتم إدراجه فوراً في التقرير المستخرج. يتيح هذا الأسلوب تنظيف البيانات واستبعاد الفئات غير المرغوبة بسهولة بالغة.

8.2 التعامل مع القيم الفارغة (Null/Blank) عند تطبيق النفي

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

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

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

=QUERY(A1:C11, “SELECT * WHERE (NOT A MATCHES ‘(Mavs|Magic)’) OR A IS NULL”, 1)

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

8.3 استخدام التعبيرات النمطية العكسية (Negative Lookahead)

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

تتم صياغة الاستبصار السلبي باستخدام الرمز (?!pattern) داخل التعبير النمطي، كما يتضح في الصيغة المتقدمة التالية:

=QUERY(A1:C11, “SELECT * WHERE A MATCHES ‘^(?!(Mavs|Magic)$).*$‘”, 1)

على الرغم من أن هذه الصيغة تحقق نفس النتيجة العملية لمشغل NOT اللغوي، إلا أنها أكثر تعقيداً في التركيب وتتطلب فهماً عميقاً لرموز البداية (^) والنهاية ($) في التعبيرات النمطية. من الناحية العملية وأداء المعالجة، يُفضل دائماً استخدام المشغل اللغوي الصريح NOT A MATCHES ‘…’ لوضوحه وسهولة قراءته وصيانته من قبل فرق العمل، بينما يُحتفظ بالاستبصار السلبي للحالات الاستثنائية التي تتطلب مطابقة أنماط متداخلة شديدة التعقيد داخل نفس الخلية.

9. معالجة المحارف الخاصة والتنظيف المسبق للنصوص في القوائم

9.1 الهروب من المحارف الخاصة (Escaping Special Regex Characters)

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

إذا حاولنا تصفية قائمة تحتوي على منتج يحمل اسماً مثل “Item (A)”، وكتبنا النمط بالشكل ‘(Item (A)|Item (B))’، سيفشل محرك الاستعلام في قراءة التعبير وسيرجع خطأ نحوياً حاداً؛ لأن المحرك سيعتبر الأقواس المحيطة بالحرف A مجموعات التقاط فرعية غير مكتملة بدلاً من معاملتها كنصوص عادية.

لحل هذه المشكلة، يجب “الهروب” من هذه المحارف الخاصة عن طريق وضع خطين مائلين عكسيين قبل كل رمز خاص. يتم كتابة الشرط الصحيح بالشكل التالي:

=QUERY(A1:D100, “SELECT * WHERE A MATCHES ‘(Item (A)|Item (B))'”, 1)

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

9.2 تنظيف الفراغات والمسافات المخفية

تعد المسافات البيضاء الزائدة—سواء كانت مسافات بادئة في بداية النص، أو لاحقة في نهايته، أو مسافات متعددة بين الكلمات—من أكثر الأسباب شيوعاً لفشل مطابقة التعبيرات النمطية في جداول بيانات جوجل. نظراً لأن المشغل MATCHES يشترط التطابق التام، فإن وجود مسافة غير مرئية في نهاية الخلية (مثل “Mavs “) سيجعلها غير مطابقة للنمط “Mavs”، مما يؤدي إلى استبعاد السجل خطأً من النتائج.

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

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

9.3 أتمتة تهيئة نصوص البحث لتفادي الأخطاء البرمجية

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

يمكن تحقيق ذلك عبر استخدام دالة REGEXREPLACE المتقدمة لاستبدال وتحييد كافة الرموز المحجوزة في نطاق المعايير تلقائياً وإضافة خطوط الهروب العكسية قبل تمريرها للاستعلام. الصيغة المتقدمة التالية توضح كيفية تطهير المعايير ديناميكياً:

=ARRAYFORMULA(REGEXREPLACE(TRIM(E1:E4), “([.+*?[](){}|^$])”, “\$1″))

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

10. تحليل الأداء والكفاءة الحوسبية في مجموعات البيانات الضخمة

10.1 المقارنة الأدائية بين MATCHES وسلاسل OR الطويلة

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

عند كتابة استعلام يحتوي على شروط متتالية مثل WHERE A = ‘Val1’ OR A = ‘Val2’ OR A = ‘Val3’…، يضطر المحلل النحوي لمحرك الاستعلام إلى بناء شجرة تعبيرات منطقية متعددة العقد (Syntax Tree Nodes). في كل صف يتم فحصه، يجب تقييم كل شرط ومقارنته على حدة حتى الوصول إلى نتيجة إيجابية أو استنفاد الشروط، مما يزيد من التعقيد الزمني الحوسبي بصورة طردية مع كل شرط مضاف.

في المقابل، عند استخدام MATCHES مع نمط التناوب ‘(Val1|Val2|Val3)’، يقوم المحرك بترجمة النمط لمرة واحدة فقط إلى آلة حالات نمطية موحدة (Compiled Regex Pattern)، ويتم تمرير قيم الخلايا عبر هذه الآلة في مسار تدقيق مفرد ومحسن حوسبياً. أظهرت الاختبارات الإحصائية والأداء العملي أن استخدام MATCHES يقلل زمن معالجة الاستعلامات بنسبة تتراوح بين 25% إلى 40% في الجداول الضخمة، فضلاً عن حماية ورقة العمل من الوصول إلى الحد الأقصى لطول نص المعادلات البرمجية المسموح به في جداول جوجل.

10.2 مقارنة دالة QUERY مع دوال التصفية البديلة (FILTER و REGEXMATCH)

توفر بيئة جداول بيانات جوجل أدوات مصفوفية بديلة يمكنها تحقيق تصفية مشابهة لمحاكاة WHERE IN، وأبرز هذه البدائل هو الدمج بين دالتي FILTER و REGEXMATCH وفق الصيغة المعيارية التالية:

=FILTER(A1:C11, REGEXMATCH(A1:A11, “^(” & TEXTJOIN(“|”, TRUE, E1:E4) & “)$”))

تمتاز صيغة FILTER بالبساطة والسرعة المباشرة في العمليات الحسابية البسيطة التي لا تتطلب سوى استخراج البيانات كما هي دون أي تحويلات إضافية. ومع ذلك، تتفوق دالة QUERY تفوقاً كاسحاً في المشاريع التحليلية المتكاملة بفضل قدرتها الشاملة على تنفيذ التصفية، واختيار أعمدة معينة وإعادة ترتيبها (SELECT)، والفرز المتقدم (ORDER BY)، والتجميع الرياضي (GROUP BY)، وتحديد أعداد الصفوف (LIMIT)، وإعادة تسمية الترويسات (LABEL) في خطوة برمجية واحدة متسقة.

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

10.3 أفضل الممارسات لتحسين سرعة معالجة جداول البيانات

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

• ضبط حدود النطاقات الجغرافية بدقة: تجنب استخدام النطاقات اللانهائية المفتوحة بالكامل مثل A:Z ما لم تكن هناك حاجة ماسة؛ إذ يجبر هذا النمط المحرك على فحص ملايين الخلايا الفارغة في قاع الورقة. يُفضل دائماً تحديد النطاقات بدقة مثل A1:Z5000، أو استخدام النطاقات الديناميكية المرنة.
• تقليل عدد الاستعلامات المكررة والمتداخلة: بدلاً من كتابة عشرات الدوال الصغيرة المتفرقة في خلايا متعددة لجلب بيانات متشابهة، يُنصح بتصميم استعلام مركزي واحد يسترجع مصفوفة البيانات بالكامل دفعة واحدة، مما يقلل عدد استدعاءات المحرك الحوسبي.
• الاستعانة بأوراق المعالجة الوسيطة (Staging Sheets): في المشاريع المؤسسية الضخمة، يُفضل عزل عمليات الاستيراد والتنظيف الأولي للبيانات في أوراق عمل وسيطة مخصصة، ثم توجيه استعلامات التصفية النهائية QUERY إلى تلك البيانات المعالجة والنظيفة لضمان استجابة لحظية للتقارير ولوحات التحكم.

11. تشخيص الأخطاء الشائعة واستراتيجيات استكشافها وإصلاحها

11.1 معالجة أخطاء الصياغة النحوية (#VALUE! و #ERROR!)

تعد الأخطاء التركيبية والنحوية من أكثر العقبات التي تواجه المحللين عند كتابة استعلامات QUERY المتقدمة، وغالباً ما تظهر في صورة أخطاء برمجية حادة مثل #VALUE! مرفقة برسالة تحذيرية شهيرة: “Unable to parse query string for Function QUERY”. يشير هذا الخطأ حصراً إلى وجود خلل في بنية السلسلة النصية الممررة للاستعلام يمنع المحرك من ترجمتها وفهمها.

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

لاستكشاف هذه الأخطاء وإصلاحها بمنهجية احترافية، يُنصح بتطبيق استراتيجية “عزل السلسلة” (String Isolation Technique). تتلخص هذه الطريقة في نسخ نص الاستعلام الداخلي المولد ولصقه في خلية مستقلة كمعادلة نصية مجردة (تسبقها علامة =)، وفحص السلسلة الناتجة بالعين المجردة للتأكد من توازن الأقواس وصحة تموضع علامات الاقتباس والفواصل قبل تمريرها مجدداً داخل دالة QUERY.

11.2 حل مشكلة القوائم الفارغة التي تؤدي لانهيار الاستعلام

عند بناء استعلامات ديناميكية تعتمد على دالة TEXTJOIN لقراءة المعايير من نطاق خلايا خارجي، يظهر خطأ تشغيلي حرج عندما يقوم المستخدم بمسح كافة معايير التصفية من النطاق الخارجي (كأن يصبح النطاق E1:E4 فارغاً بالكامل). في هذه الحالة، ترجع دالة TEXTJOIN سلسلة نصية فارغة، مما يحول نص الاستعلام إلى الصيغة المشوهة التالية: MATCHES ‘()’ أو MATCHES ”.

يعتبر محرك الاستعلام وجود أقواس فارغة في التعبير النمطي خطأ نحوياً فادحاً يترتب عليه انهيار المعادلة وظهور رسالة الخطأ #VALUE! بدلاً من عرض كافة البيانات أو إرجاع جدول فارغ. يمثل هذا السلوك ثغرة خطيرة في استقرار لوحات التحكم التفاعلية.

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

=IF(COUNTA(E1:E4)=0, QUERY(A1:C11, “SELECT *”, 1), QUERY(A1:C11, “SELECT * WHERE A MATCHES ‘(” & TEXTJOIN(“|”, TRUE, E1:E4) & “)'”, 1))

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

11.3 تصحيح مشكلات حساسية واسترجاع البيانات المفقودة

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

أولاً، عدم تطابق حالة الأحرف النصية (Case Sensitivity) بين المصدر ومعايير البحث، وهو ما تمت مناقشته سابقاً ويتم حله بإضافة البادئة (?i) داخل التعبير النمطي. ثانياً، وجود مسافات بيضاء غير مرئية في نهاية النصوص داخل جدول المصدر الأصلي، مما يمنع التطابق التام لمشغل MATCHES ويستوجب تنظيف البيانات بدالة TRIM.

ثالثاً، التأثير الخفي لإعدادات المنطقة واللغة (Locale Settings) الخاصة بملف جدول البيانات. في بعض البلدان الأوروبية وتطبيقات اللغات اللاتينية، تُستخدم الفاصلة المنقوطة (;) كفاصل معتمد بين معاملات الدوال بدلاً من الفاصلة العادية (,)، كما تُستخدم الفاصلة العشرية بدلاً من النقطة. يجب على المحلل التأكد من توافق الصياغة النحوية للمعادلة مع الإعدادات الإقليمية لورقة العمل لضمان التفسير الرياضي الدقيق لكافة القيم الممررة.

12. دراسات تطبيقية متقدمة وأفضل الممارسات في بيئات العمل الحقيقية

12.1 بناء لوحة تحكم (Dashboard) تفاعلية متعددة المعايير

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

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

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

12.2 الربط مع مصادر بيانات خارجية عبر دالة IMPORTRANGE

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

عند تطبيق تصفية WHERE IN على بيانات مستوردة عبر IMPORTRANGE، تتغير قواعد الصياغة النحوية للاستعلام؛ حيث لا يتعرف المحرك على أسماء الأعمدة الحرفية (مثل A و B)، بل يجب استخدام معرفات الأعمدة الرقمية بصيغة (Col1, Col2, Col3…) بدقة، وفق النموذج المتقدم التالي:

=QUERY(IMPORTRANGE(“https://docs.google.com/spreadsheets/d/SpreadsheetID…”, “Data!A1:Z”), “SELECT Col1, Col2, Col5 WHERE Col1 MATCHES ‘(” & TEXTJOIN(“|”, TRUE, E1:E) & “)'”, 1)

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

12.3 الدليل الإرشادي لأفضل الممارسات وتوثيق الصيغ البرمجية

لضمان استدامة واستقرار المشاريع التحليلية المبنية على جداول بيانات جوجل على المدى الطويل، وسهولة صيانتها وتطويرها من قبل فرق العمل المتعاقبة، يجب الالتزام بالدليل الإرشادي الصارم لأفضل الممارسات البرمجية التالية:

• استخدام النطاقات المسماة (Named Ranges): يُنصح بتسمية نطاقات المعايير وجداول البيانات بأسماء دلالية واضحة (مثل CriteriaList و MasterData) واستخدامها داخل الدوال؛ مما يحول المعادلات الطويلة إلى نصوص برمجية مقروءة وذات معنى مفهوم يسهل صيانته.
• التوثيق الداخلي للمعادلات المعقدة: الاستفادة من ميزة إدراج التعليقات التوضيحية داخل جداول البيانات لشرح المنطق المتبع في التعبيرات النمطية وتركيبات الاستعلام، لا سيما عند استخدام محارف الهروب الخاصة أو استراتيجيات النفي المتقدمة.
• فصل طبقات التطبيق (Architecture Layering): تقسيم المصنف دائماً إلى ثلاث طبقات وظيفية واضحة ومستقلة: طبقة إدخال وتخزين البيانات الخام (Data Layer)، وطبقة المعالجة والحسابات الوسيطة (Processing Layer)، وأخيراً طبقة العرض والتقارير التفاعلية (Presentation Layer).

الخاتمة

في الختام، يمثل إتقان محاكاة جملة WHERE IN باستخدام مشغل التعبيرات النمطية MATCHES داخل دالة QUERY قفزة نوعية في المهارات التقنية لأي محلل بيانات يعمل ضمن بيئة جداول بيانات جوجل. على الرغم من الغياب الظاهري للمعامل المباشر IN من لغة الاستعلام المدمجة، إلا أن المرونة الاستثنائية التي يوفرها المشغل MATCHES، مدعوماً برمز البديل المنطقي (|) والدوال المساعدة مثل TEXTJOIN، تمنح المستخدمين حلولاً هندسية فائقة القوة والأناقة تتفوق في كثير من الأحيان على الأساليب التقليدية.

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

References

• Benlloch, J. (2020). Google Sheets for Data Analysis: The Comprehensive Guide to Query and Automation. Data Analytics Press.
• Friedl, J. E. (2006). Mastering Regular Expressions (3rd ed.). O’Reilly Media. https://www.oreilly.com/library/view/mastering-regular-expressions/0596528124/
• Google Developers. (2023). Google Visualization API Query Language Reference. Google Cloud Documentation. https://developers.google.com/chart/interactive/docs/querylanguage
• Google Support. (2023). QUERY Function in Google Sheets. Google Workspace Learning Center. https://support.google.com/docs/answer/3093343
• Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill Education.
• Walkenbach, J. (2015). Spreadsheet Modeling and Advanced Formulas Masterclass. Wiley Publishing.