نمذجة بيانات Power BI: تصميم مخطط النجوم لذكاء الأعمال

يعد نموذج البيانات أساس كل تقرير Power BI. النموذج المصمم جيدًا يجعل قياسات DAX بسيطة، وأداء الاستعلام سريعًا، وتطوير التقارير أمر بديهي. النموذج السيئ التصميم يجعل كل شيء صعبًا --- تتطلب التدابير حلولاً معقدة، وتعمل الاستعلامات ببطء، ويقضي المطورون وقتًا أطول في محاربة النموذج بدلاً من بناء الرؤى.

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

يغطي هذا الدليل مبادئ تصميم المخطط النجمي خصيصًا لـ Power BI، بما في ذلك كيفية إنشاء جداول الحقائق والأبعاد، وتكوين العلاقات، وكتابة مقاييس DAX الفعالة، والاستفادة من مجموعات الحساب، وتنفيذ ذكاء الوقت، واستخدام النماذج المركبة للاتصال بمصادر بيانات متعددة.

الوجبات الرئيسية

• يقوم المخطط النجمي بفصل البيانات إلى جداول حقائق (مقاييس رقمية، مفاتيح خارجية) وجداول أبعاد (سمات وصفية) --- تم تحسين هذه البنية لمحرك VertiPaq الخاص بـ Power BI
• يجب أن تتدفق كل علاقة في نموذج Power BI من البعد إلى الحقيقة (واحد إلى متعدد)، مع التصفية التبادلية في اتجاه واحد فقط
• تعمل مقاييس DAX بشكل أفضل بشكل كبير في المخططات النجمية لأن VertiPaq يمكنه ضغط أعمدة الأبعاد بكفاءة وتصفية الحقائق من خلال العلاقات
• تستبدل مجموعات الحساب العشرات من المقاييس الزائدة (حتى تاريخه، QTD، MTD، السنة السابقة) بنمط واحد مطبق عبر جميع المقاييس الأساسية
• يتطلب الذكاء الزمني جدولًا مخصصًا لأبعاد التاريخ --- لا تستخدم التاريخ/الوقت التلقائي أبدًا أو تعتمد على أعمدة التاريخ في جداول البيانات الفعلية
• تتيح لك النماذج المركبة دمج البيانات المستوردة مع اتصالات DirectQuery، مما يمنحك أداء الذاكرة الداخلية مع حداثة الاستعلامات المباشرة
• تتطلب أبعاد لعب الأدوار (جدول واحد يستخدم في أدوار علاقات متعددة) وظيفة USERELATIONSHIP الخاصة بـ DAX

---

أساسيات مخطط النجوم

لماذا مخطط النجوم لـ Power BI

يستخدم محرك الذاكرة Power BI، VertiPaq، الضغط العمودي لتخزين البيانات. إنه يضغط كل عمود بشكل مستقل، والأعمدة ذات العلاقة الأساسية المنخفضة (عدد قليل من القيم الفريدة) تضغط بشكل كبير --- يتم ضغط عمود "البلد" الذي يحتوي على 40 قيمة فريدة عبر 10 ملايين صف إلى لا شيء تقريبًا. الأعمدة ذات العلاقة الأساسية العالية (العديد من القيم الفريدة) مثل معرفات المعاملات أو الطوابع الزمنية يتم ضغطها بشكل سيئ.

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

النظر في الفرق. قد يحتوي الجدول المسطح غير الطبيعي لأعمال البيع بالتجزئة على 50 عمودًا: OrderDate، وCustomerName، وCustomerEmail، وCustomerCity، وCustomerCountry، وCustomerSegment، وProductName، وProductCategory، وProductSubcategory، والعلامة التجارية، والمورد، ومورد البلد، والكمية، وUnitPrice، والخصم، وTotalAmount، وما إلى ذلك. يكرر كل صف كلمة "الولايات المتحدة" آلاف المرات، وكلمة "إلكترونيات" مئات المرات، واسم العميل الكامل لكل طلب قدمه العميل على الإطلاق.

يفصل معادل مخطط النجمة هذا إلى:

FactSales (ضيقة، صف واحد لكل سطر طلب): OrderDateKey، CustomerKey، ProductKey، الكمية، UnitPrice، Discount، TotalAmount.

DimCustomer: مفتاح العميل، اسم العميل، البريد الإلكتروني، المدينة، البلد، القطاع.

DimProduct: مفتاح المنتج، اسم المنتج، الفئة، الفئة الفرعية، العلامة التجارية.

DimDate: مفتاح التاريخ، التاريخ، السنة، ربع السنة، الشهر، اسم الشهر، يوم الأسبوع.

يحتوي جدول الحقائق على 7 أعمدة فقط بدلاً من 50. يقوم كل جدول أبعاد بتخزين كل قيمة فريدة مرة واحدة بالضبط. يقوم VertiPaq بضغط هذه البنية بشكل أفضل بمقدار 3 إلى 5 مرات من الجدول المسطح، وتشغيل الاستعلامات بشكل أسرع بمقدار 2 إلى 10 مرات لأن المحرك يقوم بتصفية جداول الأبعاد الصغيرة ثم يقوم بحل الصفوف المتطابقة فقط في جدول الحقائق.

جداول الحقائق: مبادئ التصميم

تسجل جداول الحقائق الأحداث التجارية --- المبيعات، الطلبات، الشحنات، تذاكر الدعم، زيارات الويب، عمليات التصنيع. يمثل كل صف حدثًا واحدًا أو بندًا واحدًا من الحدث.

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

المفاتيح الخارجية فقط. يحتوي جدول الحقائق على مفاتيح خارجية لجداول الأبعاد، وليس سمات وصفية. يجب ألا يحتوي جدول البيانات الفعلية على "CustomerName" أو "ProductCategory" --- تلك التي تنتمي إلى جداول الأبعاد. يحتوي جدول الحقائق على مفتاح العميل ومفتاح المنتج، اللذين يرتبطان بالأبعاد التي توجد بها التفاصيل الوصفية.

المقاييس الإضافية. يجب أن تكون الأعمدة الرقمية في جدول البيانات الفعلية قيمًا إضافية يمكن جمعها بشكل مفيد عبر أي بُعد. تعتبر الإيرادات والكمية والتكلفة والخصم عوامل مضافة. النسب المئوية والنسب وأسعار الوحدات ليست إضافة (لا يمكنك جمع أسعار الوحدات عبر المنتجات). قم بتخزين المكونات (البسط والمقام) في جدول الحقائق واحسب النسبة في مقياس DAX.

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

جداول الأبعاد: مبادئ التصميم

تصف جداول الأبعاد "من وماذا وأين ومتى ولماذا" لأحداث الأعمال. وهي تحتوي على السمات التي يقوم المستخدمون بتصفيتها وتجميعها وتقسيمها حسبها.

المفاتيح البديلة. استخدم المفاتيح البديلة ذات الأعداد الصحيحة (مفتاح العميل، مفتاح المنتج) كمفتاح أساسي في جداول الأبعاد، وليس المفاتيح الطبيعية (البريد الإلكتروني للعميل، وSKU للمنتج). المفاتيح البديلة أصغر حجمًا، وتضغط بشكل أفضل، وتعزل النموذج عن التغييرات في مفاتيح النظام المصدر.

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

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

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

---

تكوين العلاقات

قواعد العلاقة لـ Power BI

تحدد علاقات Power BI كيفية اتصال الجداول وكيفية انتشار عوامل التصفية. إن تصحيح العلاقات أمر بالغ الأهمية --- فالعلاقات غير الصحيحة تنتج أرقامًا خاطئة بصمت، وهو أسوأ من إنتاج الأخطاء.

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

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

العلاقات النشطة مقابل العلاقات غير النشطة. يسمح Power BI بعلاقة نشطة واحدة فقط بين أي جدولين. إذا كان جدول البيانات الفعلية يحتوي على أعمدة تاريخ متعددة (OrderDate، ShipDate، DeliveryDate)، فقم بإنشاء علاقة نشطة واحدة (عادةً OrderDate إلى DimDate) وعلاقات غير نشطة للآخرين. استخدم الدالة USERELATIONSHIP في مقاييس DAX لتنشيط العلاقة غير النشطة عند الحاجة:

Shipped Revenue =
CALCULATE(
    [Total Revenue],
    USERELATIONSHIP(FactSales[ShipDateKey], DimDate[DateKey])
)

أبعاد لعب الأدوار

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

في Power BI، يمكنك التعامل مع أبعاد لعب الأدوار بطريقتين:

العلاقات غير النشطة + USERELATIONSHIP (مستحسن). احتفظ بجدول DimDate واحد يحتوي على علاقة نشطة واحدة (إلى OrderDate) وعلاقات غير نشطة مع أعمدة التاريخ الأخرى. قم بإنشاء مقاييس تستخدم USERELATIONSHIP لمنظورات التاريخ البديلة. وهذا يحافظ على ضغط النموذج ويتجنب تكرار البيانات.

جداول الأبعاد المكررة. قم بإنشاء نسخ منفصلة من DimDate (DimOrderDate، DimShipDate، DimDeliveryDate)، لكل منها علاقة نشطة بعمود الحقائق الخاص بها. يعد هذا الأسلوب أبسط من منظور DAX (لا حاجة إلى علاقة استخدام) ولكنه يزيد من حجم النموذج وعبء الصيانة.

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

علاقات متعدد إلى متعدد

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

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

BridgeCustomerSegment: مفتاح العميل، مفتاح القطاع

يتصل DimCustomer بـ BridgeCustomerSegment (واحد لأكثر على CustomerKey). يتصل DimSegment بـ BridgeCustomerSegment (واحد لأكثر على SegmentKey). يتيح الجدول الجسري تصفية FactSales حسب القطاع أثناء التعامل بشكل صحيح مع العملاء في قطاعات متعددة.

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

---

مقاييس DAX: الأنماط والأداء

التدابير الأساسية

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

Total Revenue = SUM(FactSales[TotalAmount])
Total Quantity = SUM(FactSales[Quantity])
Total Cost = SUM(FactSales[CostAmount])
Order Count = COUNTROWS(FactSales)
Average Order Value = DIVIDE([Total Revenue], [Order Count])
Gross Margin = DIVIDE([Total Revenue] - [Total Cost], [Total Revenue])

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

الحساب: جوهر DAX

CALCULATE هي دالة DAX الأكثر أهمية. يقوم بتقييم تعبير في سياق عامل التصفية المعدل. إن فهم CALCULATE يعني فهم DAX.

Revenue Last Year =
CALCULATE(
    [Total Revenue],
    SAMEPERIODLASTYEAR(DimDate[Date])
)

يأخذ هذا المقياس مقياس "إجمالي الإيرادات" ويقيمه في سياق عامل التصفية حيث يتم إرجاع نطاق التاريخ بمقدار سنة واحدة. إذا كان سياق عامل التصفية الحالي هو "يناير 2026"، فإن CALCULATE يعدله إلى "يناير 2025" ويقيم إجمالي الإيرادات في هذا السياق المعدل.

يقبل CALCULATE وسائط تصفية متعددة، وتتفاعل بشكل مختلف حسب نوعها:

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

** المرشحات المنطقية ** (مثل DimProduct[Category] = "Electronics") تضيف إلى السياق الحالي. إذا تمت تصفية العناصر المرئية حتى 2026، فستظهر نتيجة الحساب إيرادات الإلكترونيات لعام 2026.

** REMOVEFILTERS ** يمسح المرشحات الموجودة. CALCULATE([Total Revenue], REMOVEFILTERS(DimProduct[Category])) يُرجع إجمالي الإيرادات عبر جميع الفئات بغض النظر عن عوامل تصفية الفئات النشطة.

متغيرات لسهولة القراءة والأداء

تحسب المتغيرات (VAR) القيمة مرة واحدة وتشير إليها عدة مرات. إنها تجعل التدابير المعقدة قابلة للقراءة وتزيل الحسابات الزائدة عن الحاجة:

Revenue YoY Growth =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue = [Revenue Last Year]
VAR Growth = CurrentRevenue - PriorRevenue
VAR GrowthPct = DIVIDE(Growth, PriorRevenue)
RETURN
    GrowthPct

بدون متغيرات، سيحسب هذا المقياس [إجمالي الإيرادات] و[إيرادات العام الماضي] عدة مرات (مرة للطرح، ومرة ​​للقسمة)، مما يؤدي إلى مضاعفة تكلفة الحساب. تضمن المتغيرات حساب كل منها مرة واحدة بالضبط.

وظائف التكرار: متى يتم استخدامها

تقوم وظائف التكرار (SUMX وAVERAGEX وMAXX وMINX وCOUNTX وRANKX) بتقييم صف التعبير تلو الآخر عبر الجدول. إنها قوية ولكنها باهظة الثمن --- تقوم بمسح كل صف في الجدول المحدد.

استخدم التكرارات عندما تحتاج إلى حسابات على مستوى الصف قبل التجميع:

Weighted Average Price =
DIVIDE(
    SUMX(FactSales, FactSales[Quantity] * FactSales[UnitPrice]),
    SUM(FactSales[Quantity])
)

لا يمكن تحقيق ذلك باستخدام SUM بسيط لأنك تحتاج إلى ضرب الكمية في UnitPrice في كل صف قبل الجمع. يعالج المكرر SUMX هذا الضرب صفًا تلو الآخر.

تجنب التكرارات عندما يكون التجميع البسيط كافيًا. SUMX(FactSales, FactSales[TotalAmount]) يعادل وظيفيًا SUM(FactSales[TotalAmount]) ولكنه أبطأ لأن المكرِّر يقوم بمسح صف تلو الآخر بينما تعمل SUM على زيادة الضغط العمودي.

---

مجموعات الحساب

ما الذي تحله مجموعات الحساب

قبل مجموعات الحساب، كان نموذج البيانات الذي يحتوي على 10 مقاييس أساسية (الإيرادات، والكمية، والتكلفة، والهامش، وما إلى ذلك) و5 اختلافات في معلومات الوقت (منذ بداية العام، وQTD، وMTD، والسنة السابقة، والسنة السابقة منذ بداية العام) يتطلب 50 مقياسًا منفصلاً. إن إضافة مقياس أساسي جديد يعني إنشاء 5 متغيرات أخرى لذكاء الوقت. إن إضافة نمط ذكاء زمني جديد يعني إنشاء 10 قياسات أخرى. أدى هذا الانفجار التوافقي إلى صعوبة صيانة النماذج.

تحل مجموعات الحساب هذه المشكلة عن طريق تحديد أنماط الذكاء الزمني مرة واحدة وتطبيقها على أي مقياس ديناميكيًا.

بناء مجموعة حساب ذكاء الوقت

في Power BI Desktop، قم بإنشاء مجموعة حسابية عبر طريقة عرض النموذج أو باستخدام أدوات خارجية مثل Tabular Editor (الذي يوفر مزيدًا من التحكم).

تحديد عناصر الحساب لكل نمط ذكاء زمني:

الحالي: بدون تعديل --- يُرجع المقياس كما هو.

SELECTEDMEASURE()

حتى تاريخه (منذ بداية العام):

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(DimDate[Date])
)

السنة السابقة:

CALCULATE(
    SELECTEDMEASURE(),
    SAMEPERIODLASTYEAR(DimDate[Date])
)

العام السابق منذ بداية العام:

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(SAMEPERIODLASTYEAR(DimDate[Date]))
)

التغير السنوي:

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN CurrentValue - PriorValue

التغير السنوي %:

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN DIVIDE(CurrentValue - PriorValue, PriorValue)

بمجرد التحديد، يقوم المستخدمون بوضع مجموعة الحساب في عمود أو محور الصف المرئي، ويقوم Power BI بتطبيق كل عنصر حساب على أي مقياس موجود في القيم جيدًا. مجموعة حسابية واحدة تحتوي على 6 عناصر تحل محل 60 مقياسًا فرديًا (لمدة 10 قياسات أساسية).

تنسيق تعبيرات السلسلة

يمكن أن يحتوي كل عنصر حساب على تعبير سلسلة تنسيق يقوم بتغيير تنسيق الأرقام ديناميكيًا بناءً على العملية الحسابية:

بالنسبة للمقاييس المطلقة (الحالية، منذ بداية العام، السنة السابقة): استخدم تنسيق المقياس الأساسي. بالنسبة لمقاييس النسبة المئوية (التغيير السنوي): قم بالتنسيق كنسبة مئوية.

// Format string for YoY % Change
"0.0%;-0.0%;0.0%"

وهذا يضمن أنه عندما يقوم المستخدم بالتبديل بين "الحالي" (يظهر 1,234,567 دولارًا أمريكيًا) و"التغيير السنوي%" (يظهر 12.5%)، يكون التنسيق صحيحًا دون تدخل يدوي.

---

ذكاء الوقت

جدول أبعاد التاريخ

تتطلب المعلومات المتعلقة بالوقت في Power BI جدولاً مخصصًا لأبعاد التاريخ. لا تعتمد على ميزة التاريخ/الوقت التلقائي (قم بتعطيلها في ملف → خيارات → تحميل البيانات) --- فهي تنشئ جداول تاريخ مخفية لكل عمود تاريخ، مما يؤدي إلى تضخيم النموذج الخاص بك والحد من التحكم الخاص بك.

أنشئ جدول أبعاد التاريخ الذي يغطي النطاق الكامل لبياناتك بالإضافة إلى سنة واحدة على الأقل في كل جانب. إذا كانت أول معاملة لك هي يناير 2020، فابدأ جدول التاريخ في يناير 2019. وإذا كان تحليلك سيتضمن توقعات 2027، فانتهى في ديسمبر 2027.

الأعمدة الأساسية لجدول أبعاد التاريخ:

قم بإنشاء جدول التاريخ في Power Query أو كجدول محسوب DAX:

DimDate =
VAR StartDate = DATE(2019, 1, 1)
VAR EndDate = DATE(2027, 12, 31)
RETURN
ADDCOLUMNS(
    CALENDAR(StartDate, EndDate),
    "DateKey", YEAR([Date]) * 10000 + MONTH([Date]) * 100 + DAY([Date]),
    "Year", YEAR([Date]),
    "Quarter", "Q" & QUARTER([Date]),
    "MonthNumber", MONTH([Date]),
    "Month", FORMAT([Date], "MMMM"),
    "DayOfWeek", FORMAT([Date], "dddd"),
    "IsWeekend", WEEKDAY([Date], 2) >= 6
)

قم بتمييز الجدول كجدول تاريخ في Power BI (أدوات الجدول → وضع علامة كجدول تاريخ → حدد عمود التاريخ). وهذا يتيح وظائف الاستخبارات الزمنية المضمنة.

أنماط استخبارات الوقت الشائعة

باستخدام بُعد التاريخ المناسب، تتعامل وظائف تحليل الوقت في Power BI مع الحسابات الزمنية الأكثر شيوعًا:

منذ بداية العام حتى تاريخه: DATESYTD(DimDate[Date]) ربع سنوي حتى تاريخه: DATESQTD(DimDate[Date]) من الشهر حتى الآن: DATESMTD(DimDate[Date]) نفس الفترة من العام الماضي: SAMEPERIODLASTYEAR(DimDate[Date]) مستمر لمدة 12 شهرًا: DATESINPERIOD(DimDate[Date], MAX(DimDate[Date]), -12, MONTH) الفترة الموازية: PARALLELPERIOD(DimDate[Date], -1, QUARTER) (تم نقل النافذة ذات الحجم نفسه إلى الخلف)

تقوم هذه الوظائف بتعديل سياق عامل تصفية التاريخ عند استخدامها داخل CALCULATE. وهي تعمل بشكل صحيح فقط عندما يأتي عمود التاريخ من جدول تم وضع علامة عليه كجدول تاريخ بنطاق تاريخ كامل ومتجاور.

دعم التقويم المالي

إذا كانت السنة المالية لمؤسستك لا تتماشى مع السنة التقويمية، فقم بتعديل حسابات معلومات الوقت لاستخدام التقويم المالي:

Fiscal YTD Revenue =
CALCULATE(
    [Total Revenue],
    DATESYTD(DimDate[Date], "6/30")  -- Fiscal year ends June 30
)

تحدد الوسيطة الثانية لـ DATESYTD تاريخ نهاية السنة المالية. تستخدم كافة الحسابات منذ بداية العام حد السنة المالية بدلاً من 31 ديسمبر.

---

النماذج المركبة

متى يجب استخدام النماذج المركبة

تجمع النماذج المركبة بين البيانات المستوردة (المخزنة في VertiPaq) وبيانات DirectQuery (التي يتم الاستعلام عنها مباشرة من المصدر) في نموذج واحد. يُعد هذا النهج المختلط ذا قيمة عندما تحتاج إلى أداء البيانات المستوردة للتحليل التاريخي وحداثة البيانات المباشرة للمقاييس التشغيلية.

السيناريوهات الشائعة:

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

** النموذج المركزي + الإثراء المحلي. ** اتصل بمجموعة بيانات مُدارة مركزيًا عبر DirectQuery (تأكد من استخدام التعريفات المحكومة للمؤسسة). أضف الجداول المحلية المستوردة للبيانات الخاصة بالقسم (أهداف الميزانية، التصنيفات المخصصة) غير الموجودة في النموذج المركزي.

أنظمة متعددة المصادر. استيراد البيانات من مستودع البيانات السحابية (Snowflake وAzure Synapse) والاتصال عبر DirectQuery بقاعدة بيانات تشغيلية (PostgreSQL وSQL Server) في تقرير واحد، دون إنشاء مسار ETL منفصل لدمجها.

العمارة النموذجية المركبة

في النموذج المركب، يحتوي كل جدول على وضع تخزين:

استيراد: يتم تحميل البيانات في ذاكرة VertiPaq. أسرع أداء للاستعلام ولكنه يتطلب تحديثًا مجدولًا للتحديث.

DirectQuery: يتم الاستعلام عن البيانات مباشرة من المصدر. محدث دائمًا ولكنه يعتمد على أداء قاعدة البيانات المصدر.

Dual: الجدول مستورد ومتاح لـ DirectQuery. يُستخدم لجداول الأبعاد التي تحتاج إلى الارتباط بكل من جداول حقائق الاستيراد وDirectQuery.

قم بتعيين جداول الأبعاد التي تربط حقائق الاستيراد والاستعلام المباشر بالوضع "ثنائي". يسمح هذا لمحرك VertiPaq باستخدام النسخة الموجودة في الذاكرة عند تصفية استيراد الحقائق وإنشاء استعلامات SQL عند تصفية حقائق DirectQuery.

اعتبارات الأداء

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

قم بتقليل الروابط عبر المصادر عن طريق تنظيم النموذج الخاص بك بحيث تصل معظم الاستعلامات التحليلية إلى جداول الاستيراد. استخدم DirectQuery فقط للجداول المحددة التي تتطلب التحديث في الوقت الفعلي. قم بفهرسة جداول مصدر DirectQuery في الأعمدة المستخدمة في العلاقات وعوامل التصفية.

بالنسبة للمؤسسات التي تقوم ببناء نماذج بيانات Power BI معقدة، توفر خدمات نمذجة البيانات من ECOSIRE إرشادات الخبراء حول تصميم المخطط النجمي، وتحسين DAX، وبنية النموذج المركب المصممة خصيصًا لتناسب مشهد البيانات ومتطلبات الأداء المحددة لديك.

---

تحسين النموذج

تقليل حجم النموذج

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

قم بإزالة الأعمدة غير المستخدمة. إذا لم يتم استخدام عمود في أي قاعدة مرئية أو قياس أو علاقة أو قاعدة RLS، فقم بإزالته. يستهلك كل عمود الذاكرة حتى لو لم يكن هناك أي مرجع مرئي له. تتضمن الجرائم الشائعة الأعمدة التي يتم إنشاؤها تلقائيًا، وأعمدة التدقيق (CreatedBy، وModifiedDate)، والمعرفات الفنية التي لا تخدم أي غرض تحليلي.

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

استخدم أنواع البيانات المناسبة. يقوم Power BI بتخزين "الرقم الصحيح" بكفاءة أكبر من "الرقم العشري". إذا كان العمود يحتوي على أعداد صحيحة فقط (الكميات والأعداد)، فاضبط نوعه على "رقم صحيح". تستهلك الأعمدة النصية ذاكرة أكبر من الأعمدة الرقمية التي لها نفس العلاقة الأساسية --- حيثما أمكن، قم بتشفير فئات النص كأعداد صحيحة ذات بُعد بحث.

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

تشخيص أداء الاستعلام

استخدم DAX Studio لتحليل أداء الاستعلام بما يتجاوز ما يعرضه محلل الأداء المدمج في Power BI. يكشف استوديو DAX:

** استعلامات محرك التخزين. ** كم عدد الاستعلامات التي يتم إرسالها إلى محرك VertiPaq وكم البيانات التي يقومون بمسحها. عدد أقل من الاستعلامات التي تفحص بيانات أقل يعني أداء أفضل.

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

خطة الاستعلام. خطة التنفيذ المنطقية والمادية لاستعلام DAX، توضح كيفية تحليل Power BI للمقياس إلى استعلامات محرك التخزين وعمليات محرك الصيغة.

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

---

الأسئلة الشائعة

هل يجب علي استخدام مخطط النجمة أو مخطط ندفة الثلج في Power BI؟

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

ما هو الحد الأقصى لحجم مجموعة البيانات في Power BI؟

يدعم Power BI Pro مجموعات البيانات المضغوطة التي يصل حجمها إلى 1 جيجابايت. يدعم Premium لكل مستخدم ما يصل إلى 100 جيجابايت. تدعم السعة المميزة (P1 وما فوق) ما يصل إلى 400 جيجابايت مع تمكين تخزين مجموعة بيانات كبيرة. تشير هذه الحدود إلى حجم الذاكرة المضغوطة، وليس حجم البيانات المصدر. يقوم VertiPaq عادةً بضغط البيانات بنسبة 10:1، لذا فإن مجموعة البيانات المضغوطة التي يبلغ حجمها 1 جيجابايت قد تمثل 10 جيجابايت من البيانات المصدر. بالنسبة لمجموعات البيانات التي تقترب من هذه الحدود، فكر في التجميعات أو التحديث التزايدي أو النماذج المركبة باستخدام DirectQuery للبيانات على مستوى التفاصيل.

كيف أتعامل مع علاقات متعدد إلى متعدد في مخطط النجمة؟

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

هل يجب علي إنشاء أعمدة محسوبة أو مقاييس DAX؟

تفضيل المقاييس على الأعمدة المحسوبة في جميع الحالات تقريبًا. يتم حساب المقاييس في وقت الاستعلام ولا تستهلك مساحة تخزين. يتم حساب الأعمدة المحسوبة أثناء التحديث وتخزينها في الذاكرة، مما يؤدي إلى زيادة حجم النموذج. استخدم الأعمدة المحسوبة فقط عندما تحتاج إلى القيمة المتوفرة للتصفية أو الفرز أو العلاقات (لا يمكنك التصفية حسب مقياس في مقسم طريقة العرض، ولكن يمكنك التصفية حسب عمود محسوب). الاستثناء الشائع هو العمود المتسلسل للتسميات على مستوى الصف (FullName = FirstName + " " + LastName) الذي يحتاجه المستخدمون في مقسمات طرق العرض أو مرئيات الجدول.

كيف تتفاعل مجموعات الحساب مع المقاييس الموجودة؟

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