أداة فحص أفضل الممارسات هي قائمة قواعد: ضع تنسيقًا لكل مقياس، واجعل العلاقات تفلتر في اتجاه واحد، وانقل الأعمدة المحسوبة إلى Power Query. وغالبًا تكون كل قاعدة صحيحة. لكن توثيق Microsoft نفسه يذكر استثناءات لعدد منها، والأداة التي تتجاهل الاستثناءات تعطيك نصيحة لا يمكنك تنفيذها، أو لا ينبغي لك.
اكتشفنا ذلك في أداتنا نفسها، فحص صحة النموذج. شغّلناها على 23 نموذجًا وصنّفنا كل نتيجة صحيحة أو خاطئة مقابل توثيق Microsoft. قبل الإصلاح كانت 206 من 5,656 نتيجة أمكن الحكم عليها خاطئة (96.4% صحيحة)، وكل واحدة منها كانت قاعدة طُبّقت حيث لا تنطبق، وأوضحها تذكره صفحات Microsoft نفسها. بعد الإصلاح: نتيجة واحدة خاطئة من 5,464 (99.98% صحيحة). هذه هي الاستثناءات الخمسة، لتطبّق القواعد كما تقصدها Microsoft، بأي أداة.
1. المقياس النصي لا يحتاج تنسيقًا رقميًا
تطلب أداة Best Practice Analyzer من Microsoft تنسيقًا لكل مقياس ظاهر. التنسيق يخبر Power BI كيف يعرض الرقم: علامة النسبة والمنازل العشرية وفاصل الآلاف. أما المقياس الذي يُرجع نصًا، كعنوان متغير أو نص زر أو سطر "البيانات حتى تاريخ"، فلا رقم فيه ليُنسَّق.
كان هذا أكبر أخطائنا: 148 من 338 نتيجة "بلا تنسيق" كانت مقاييس نصية. ومن السهل ألا ننتبه للأنماط التي تُرجع نصًا: SELECTEDVALUE لعمود نصي، وCALCULATE حول مقياس نصي، وIF كل فروعها نصوص. إذا أظهرت أداة الفحص مقياسًا كهذا فاتركه. أما مع الأرقام فالقاعدة مهمة: هامش قيمته 33.8% بلا تنسيق يظهر في البطاقة 0.34.
2. علاقة one-to-one تفلتر في الاتجاهين، ويجب ذلك
تنصح إرشادات Microsoft للعلاقات ثنائية الاتجاه بتقليل العلاقات التي تفلتر في الاتجاهين، لأنها قد تبطئ الاستعلامات وتربك مستخدمي التقرير. والصفحة نفسها تذكر الاستثناءات. عن one-to-one تقول: "All one-to-one relationships must be bi-directional—it isn't possible to configure otherwise." أي يجب أن تكون كل علاقات one-to-one في الاتجاهين ولا يمكن غير ذلك. وبين بُعدين يربطهما جدول bridge: "A bi-directional filter is required to ensure filters propagate across the bridging table."
11 من 57 نتيجة لدينا طلبت ضبط علاقة one-to-one على اتجاه واحد، وهو ما لا يسمح به Power BI. والثانية عشرة نبّهت إلى علاقة غير نشطة: اتجاهها لا يكلّف شيئًا، لأنها لا تفلتر شيئًا حتى يفعّلها USERELATIONSHIP. الآن يترك الفحص علاقات one-to-one، ومع جدول bridge يطلب منك التأكد أنه bridge بدل أن يطلب تغييره. ولأي علاقة أخرى في الاتجاهين تقترح Microsoft الدالة CROSSFILTER داخل المقياس الوحيد الذي يحتاجها.
3. بعض الأعمدة المحسوبة مكانها DAX
تفضّل إرشادات Microsoft لتقليل حجم البيانات الأعمدة المضافة في Power Query أو في المصدر: فالأعمدة المحسوبة عادة تنضغط أقل ولا تُبنى إلا بعد تحميل كل الجداول. ثم تضيف: "However, in some instances, model calculated columns might be the better choice. That's true when the formula involves evaluating measures, or it requires specific modeling functionality only supported in DAX functions." أي قد يكون العمود المحسوب الخيار الأفضل عندما تحتاج المعادلة مقاييس أو وظائف لا توجد إلا في DAX.
10 من 44 نتيجة لدينا كانت أعمدة من هذا النوع: مجموع تراكمي بـ EARLIER، وترتيب بـ RANKX، ومسار parent-child بـ PATH، وقيمة تجمع جدولًا آخر. أما IF بسيطة أو دمج نصوص أو بحث بـ RELATED فمكانها Power Query، حيث يؤدي الدمج (merge) المهمة نفسها.
4. FILTER صحيحة عندما يكون الشرط مقياسًا
تقول إرشادات Microsoft في DAX: تجنّب FILTER كوسيط فلترة، اكتب KEEPFILTERS('Product'[Color] = "Red") لا FILTER('Product', ...). لكن فلتر Boolean "Cannot reference a measure" أي لا يمكنه الإشارة إلى مقياس، لذلك تكتب Microsoft نفسها لحساب "المبيعات في الأشهر الرابحة":
Sales for Profitable Months =
CALCULATE(
[Sales],
FILTER(
VALUES('Date'[Month]),
[Profit] > 0
)
)
كان فحصنا يقول هنا أيضًا "فلتر العمود بدلًا من ذلك"، وهذا لا يعمل. الآن يميّز بين الحالتين. شرط على عمود: استخدم فلتر Boolean. شرط على مقياس: أبقِ FILTER، لكن على VALUES لعمود واحد كما في المثال، لا على الجدول كله. لم تحتوِ نماذجنا الـ 23 هذه الحالة، فقد وجدناها عند قراءة صفحة Microsoft، ولها الآن اختبار خاص.
5. المقياس المخفي لا يحتاج وصفًا
تطلب Best Practice Analyzer وصفًا للعناصر الظاهرة، لأن Power BI Desktop يعرض الوصف عند المرور على الحقل في قائمة الحقول. والمقياس المخفي ليس في قائمة الحقول، فلا أحد يرى وصفه. 26 من 1,132 نتيجة "بلا وصف" كانت مقاييس مساعدة مخفية، ومثلها 5 نتائج "بلا مجلد عرض" ونتيجة "بلا تنسيق" واحدة: فالمجلدات أيضًا لا ترتّب إلا قائمة الحقول، والتنسيق لا يظهر إلا في عنصر مرئي. صِف ونظّم ما يستخدمه معدّو التقارير، والمقاييس المساعدة يمكنها الانتظار.
الباقي، وما لا يستطيع الملف إخبارنا به
الأخطاء الأربعة الأخيرة كانت أصغر، وأُصلحت أيضًا. نتيجتان "جدول التاريخ غير مُعلَّم" كانتا لجدولي اختيار تاريخ (عمود تاريخ واحد بلا علاقة) لا تقويمين. ونتيجة "مسار ثابت" كانت عنصرًا نائبًا {{...}} يُملأ عند النشر. ونتيجة "مقياس مكرر" كانت لمقياسين بالنص نفسه، SUM([SalesAmount])، في جدولين: كل منهما يجمع جدوله، فهما مختلفان. وأداة Best Practice Analyzer من Microsoft تقارن النص أيضًا، فتقع في الخطأ نفسه.
47 نتيجة لم نستطع تصنيفها، والأداة تقول ذلك بدل التخمين. فحاجة النموذج إلى أمان على مستوى الصفوف تعتمد على من سيستخدمه (21 نموذجًا بلا أدوار أمان). وبعض الإشارات المكسورة في التقرير لا يؤكدها إلا فتح التقرير في Power BI Desktop (19). وخمس أخرى تحتاج تقديرًا لا يحسمه الملف: جدول تاريخ بـ CALENDARAUTO وخطوات Power Query طويلة. أما النتيجة الخاطئة الوحيدة الباقية فهي عمود نصي مبني بـ SELECTCOLUMNS وINDEX لا يقرؤه فحص التنسيق كنص بعد، وهي على قائمتنا.
كيف قسنا
النماذج الـ 23: ثمانية عشر نشرتها Microsoft على GitHub بترخيص MIT (من fabric-toolbox وAnalysis-Services وfabric-samples وfabric-cicd وpowerbi-desktop-samples)، بإصدارات مثبتة، وخمسة نماذج اختبار خاصة بنا. شغّلنا الفحص في Node على كل ملف، وصنّفنا كل نتيجة من الـ 5,703 صحيحة أو خاطئة مقابل توثيق Microsoft، أو غير مؤكدة حين لا يكفي الملف وحده للحكم، وبعد الإصلاح استخدمنا التصنيفات نفسها. الدقة هي النتائج الصحيحة مقسومة على كل النتائج التي أمكن الحكم عليها. وأثر يمكنك رؤيته على موقعنا: نموذج COVID-19 من Microsoft أصبحت نتيجته 85 بدل 84.
ماذا نستفيد من هذا
- اقرأ السبب لا القاعدة وحدها. كل نتيجة في فحص صحة النموذج تذكر الآن مصدرها: صفحة Microsoft، أو قاعدة Best Practice Analyzer، أو "قاعدة من DataArcus" مع السبب.
- قبل أن تغيّر نموذجًا لأن أداة فحص طلبت ذلك، راجع الحالات الخمس أعلاه. إنها الحالات الشائعة التي لا تنطبق فيها القاعدة.
- شغّله على نموذجك: File > Export > Power BI template، ثم أسقط ملف .pbit على فحص صحة النموذج. يعمل داخل متصفحك ولا يُرفع أي ملف. ولخطوات تجهيز النموذج لـ Copilot، راجع فحصنا من 7 نقاط.