حقيقة الجدول مع حقائق متعددة

Question

لدي البعد (siteitem) لديه حقائق مهمة:

perUserClicks 
perBrowserClicks

ومع ذلك، ضمن هذا البعد، لدي مجموعات من القيم بناء على عمود سمة (دعونا نسمي المجموعات المذكورة أعلاه، والأيسرNAVITEMS، ONTHEFFYITEMS، وما إلى ذلك) لكل منها حقائق أخرى خاصة بهذه المجموعة:

AboveFoldItems: eyeTime, loadTime
LeftNavItems: mouseOverTime
OnTheFlyItems: doesn't have any extra, but may in the future

هل الحقائق التالية جدول مخطط موافق؟

DateKey   
SessionKey
SiteItemKey
perUserClicks 
perBrowserClicks
eyeTime
loadTime
mouseOverTime

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

Answer 1

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

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

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

لاحظ أنه عند الانضمام إلى النجومين، يجب عليك استخدام الانضمام الأيسر، وفي هذه الحالة، ستنتج غير خاملين والتي ستتضطر على ربما يجب أن تأخذ في الاعتبار - لذلك أنت فعلا عدت إلى النموذج الأصلي الذي كان لديك خيال! ؛-)

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

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

أود أيضا أن أتطلع إلى معرفة ما إذا كنت في حالة كيمبال من "الأبعاد قليلة جدا". يبدو أنك يجب أن يكون لديك سمات جيدة الأبعاد المقطوعة في Sessence and Sideitemkey - ولكن دون رؤية النموذج والمتطلبات بأكملها، من الصعب القول، لكنني أعتقد أن لديك بعض التركيبة السكانية للمستخدم في البعد المنخفض أو حتى ندفة الثلج دون الجلسة الكاملة أو البعد الموقع.

Answer 2

لا يوجد حل أنيق حقا، إما أن يكون لديك أعمدة غير قابلة للغة أو تستخدم محلول إيف. لقد نشرت حول إياف من قبل (وأولدت الكثير من التعليقات التي قد تكون جديرة بالاهتمام):

• ما هو سيء جدا حول إيف، على أي حال؟

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

Answer 3

هل يمكن أن يكون لديك أكثر من جدول الحقائق: FactPeruserclicks، FactPerbrowserclicks، Facteyetime، إلخ ...

كل من هذه سيكون لها deatkey، sessionkey، siteitemkey. بهذه الطريقة فقط مفاتيح البعد التي "منطقي" تظهر مع كل حقيقة.

من الناحية المثالية، يجب ألا يكون هناك أي خاملين في DW - إذا احتفظ بها في نفس جدول الحقائق، فقد يكون استخدام الأصفار أكثر ملاءمة.

بقدر ما يوفر مساحة القرص، لا أرى حلا مثاليا - ولكن في A DW، من المفترض أن يتداول المساحة للسرعة و (استعلام) البساطة على أي حال.