العلاقات والتجميع ومسارات الترشيح ومنع العد المزدوج

العلاقة الصحيحة لا تكفي إذا كان التجميع خاطئًا

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

COUNT ليس دائمًا عدد الكيانات

في الجدول نفسه يوجد ثلاثة صفوف ولكن طلبان مميزان. إذا كان السؤال «كم بند قطعة؟» فعدد الصفوف 3 مناسب. إذا كان السؤال «كم طلب صيانة؟» نحتاج عدد RequestID المميز = 2. وإذا كان السؤال «متوسط تكلفة القطع لكل طلب؟» نحسب 100 ÷ 2 = 50، لا 100 ÷ 3. يجب أن يطابق المقام وحدة العمل التي يسأل عنها المقياس. هذه العادة البسيطة تمنع نسبة كبيرة من أخطاء اللوحات.

التجميع لا يقتصر على SUM وCOUNT. نستخدم المتوسط أو الوسيط أو الحد الأدنى أو الأقصى بحسب السؤال وتوزيع البيانات. متوسط زمن المعالجة قد يتأثر بطلبات شديدة الطول، بينما الوسيط يصف القيمة الوسطى. لا توجد دالة «أفضل» بلا سؤال. قبل اختيار التجميع، سمِّ الكيان والحبيبة ووحدة القياس، ثم اختبر مثالًا صغيرًا يمكن حسابه يدويًا.

سياق المرشح يغيّر ما يدخل الحساب

سياق المرشح هو مجموعة القيود التي تحدد أي جزء من البيانات يُقيَّم فيه المقياس. إذا كانت البطاقة تعرض تكلفة القطع 100 لكل الطلبات، ثم اختر المستخدم الفريق «North»، يصبح الحساب مقيدًا بصفوف الطلبات التي تنتمي إلى ذلك الفريق. قد تنخفض التكلفة إلى 50 أو أي قيمة أخرى بحسب البيانات. هذا التغير ليس خللًا؛ هو معنى التفاعل. الخلل يظهر عندما لا يعرف المستخدم أن مرشحًا ما يعمل، أو عندما يصل المرشح إلى جداول غير مقصودة عبر مسار علاقة غامض.