STAR-SCHEMA: أبعاد منفصلة للعملاء وغير المشتركين أو البعد المشترك للحاضرين؟
https://stackoverflow.com/questions/2396378
-
25-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أنا جديد في مخططات النجوم النمذجة ، جديدة من قراءة مجموعة أدوات مستودع البيانات.
لديّ عملية تجارية تضم عملاء وغيرهم من المكالمات الجماعية مع بعض موظفينا.
سيحتوي طاولة الحقائق ، التي تسميها "جمهور" ، على مقياس لمدة اتصال الشخص المعالج بالمكالمة ، وتكلفة اتصال هذا الشخص بالمكالمة. الحبوب هي "اتصال فردي بالمكالمة الجماعية".
هل يجب أن أستخدم بُعد العميل المطابق وإنشاء بُعد غير صريح (بالنسبة للمتصلين الذين ليسوا عملاء بعد) بهذه الطريقة (حذف الأبعاد التي ليست جزءًا من هذه الأسئلة):
أم أنه من الأفضل/من الأفضل أن يكون لديك بُعد غير متطابق يتعلق ببعد العميل المطابق بهذه الطريقة:
أم أن هناك آلية أفضل/قياسية لنمذجة العمليات التجارية مثل هذه؟
تعديل:
ماذا عن استخدام النموذج 2 أعلاه ، ولكن إنشاء طريقة عرض أعلى جدول أبعاد العميل وبعد الحضور لجعله يبدو أنه بعد واحد فقط؟
هل هذا بديل مقبول عن إجابة دامير أدناه؟
المحلول
ليست هناك حاجة لتقسيم العملاء إلى جدولين (الأبعاد). ما عليك سوى وضع جميع العملاء ، النشطين والآفاق في نفس جدول الأبعاد. يمكنك بعد ذلك تقديم سمة (عمود) للتمييز بين العملاء والآفاق. عاجلاً أم آجلاً ، ستستخدم أداة تعدين البيانات لمعرفة المزيد عن العملاء وما يميز الأشخاص الذين يرغبون في دفع ثمن خدمتك عن أولئك الذين ليسوا كذلك. لكي تعمل الخوارزمية ، يجب عليك توفير بيانات لكلتا مجموعتين من الأشخاص - أولئك الذين يدفعون وأولئك الذين لا يدفعون. لتلخيص ، تنتمي الآفاق إلى نفس الجدول مثل دفع العملاء.
مع هذا ، يمكنك استخدام النموذج الخاص بك رقم 1. تأكد من أن التدابير في جدول الحقائق منطقية. على سبيل المثال ، إذا كان call_id = 123 كان لديه 10 أشخاص يشاركون ، إذن
sum(cost_of_connection)
from factAudience
where call_id = 123;
يجب إرجاع التكلفة الإجمالية للمكالمة ، وليس شيئًا لا معنى له - مثل 10x التكلفة الحقيقية.
تعديل
يعد "عميل الدفع" و "عميل Prospect" نوعًا من العميل ، وبالتالي ينتمي إلى جدول الأبعاد نفسه - DimClient. في مكان ما في DW هناك حقائق (أو ما شابه) مع FK إلى Dimsale. حتى إذا لم يكن لديك عمود في DimClient للتمييز بين الدفع والآفاق - لا يزال بإمكانك دفع العملاء من خلال الانضمام إلى FactSale و DimClient.
"من هو العميل؟" هو نقاش شائع عند تقديم DW في المنظمة. من أجل أن تكون قادرًا على تحليل اكتساب العميل والاحتفاظ به والتحويل وما إلى ذلك ، فإن التوقعات لها نفس علاج دفع العملاء - على الأقل في DW. ضع في اعتبارك أن الحصول على وإنشاء عملاء جدد هو على رأس القائمة (تقريبًا) أي مدير تنفيذي.
نصائح أخرى
أود أن أذهب للثاني: إنه نماذج من الحاضرين في البعد المخصص ، مع السماح لك بفضح عميلهم (أو غير ذلك) عن طريق سمة في هذا البعد ، والتي ربما تكون الطريقة التي تريد أن تتنقل فيها لأسفل الحياة الحقيقية ("أرني جميع الحاضرين" تليهم "والآن أي من هؤلاء العملاء").
في بُعد العميل الخاص بك ، كنت أقوم بتعبئة Client_ID لجميع الحاضرين ، مطابقة لعنصر "غير معروف" حيث لا يكون الحاضر عميلًا.
هناك مناقشة لطيفة حول هذا هنا:
إنه يجعل فرقًا كبيرًا. قد يكون الإصدار الثاني أكثر صحة ، ولكن هل يدعم نظام OLAP هذا؟
الثاني يشبه "مخطط ندفة الثلج" بالنسبة لي. انظر إلى مخطط ندفة الثلج ، بدءًا من مقال ويكيبيديا. سترى عدة مقارنات بين ندفة النجوم والثلوج.
