إنشاء خافت والجداول الحقيقة لمستودع البيانات

Question

وأنا المكلفة بإنشاء مستودع البيانات للعميل. الجداول المعنية لا تتبع حقا الأمثلة التقليدية هناك (المنتج / أوامر)، لذلك انا بحاجة الى بعض المساعدة للبدء. العميل هو في الأساس مركز معالجة الحالات (على غرار قضية قانونية). كل يوم، يتم إدخال حالات جديدة في DB تحت الطاولة "الحالات". يحتوي كل عمود بعض الشيء من المعلومات المتعلقة بالقضية. كما يتم معالجة هذه القضية، يتم ملؤها إضافية جدول واحد لكثير مع الأحداث المتعلقة بالقضية. هناك عدد غير قليل من هذه الجداول الحدث، قد يكون المثال الجداول: (قضية مفتوحة، حالة dept1، حالة dept2، حالة dept3، وما إلى ذلك). كل من هذه الجداول لديها caseid التي تقوم بتعيين العودة إلى طاولة "الحالات". وهناك أيضا عدد قليل من جداول البحث تشارك أيضا.

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

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

Answer 1

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

في أي حال، عليك أن تقرر ما إذا كان نموذج الأبعاد، بل هو المناسب. فمن الممكن تماما لعلاج 3NF "مستودع بيانات المؤسسة" قاعدة البيانات مع مؤشرات أو ملخصات مختلفة، أو أيا كان.

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

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

Answer 2

والجدول حقيقة هو الحدث القضية وأنه 'factless "لأنه لا يوجد لديه القيمة العددية. أن تكون أبعاد الزمن، نوع الحدث القضية وربما البعض الآخر اعتمادا على ما هي البيانات الآخر هو في النظام.

وتحتاج إلى توحيد الجداول الحدث في جدول حقيقة واحدة، وصفت مع 'نوع الحدث "البعد. تقارير الإنتاجية / عنق الزجاجة واحتساب الفروق بين أوقات الحدث لمجموعات محددة من أنواع الأحداث في حالة معينة.

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

إذا كنت ترغب في مراحل معينة القياسي في تطور دورة الحياة عملتم على الجدول الذي يذهب نوع الحالة، type1 الحدث، حدث نوع 2، والوقت القياسي.

ومع قليل من تدليك، قد تكون قادرا على استخدام أدوات التنقيب في البيانات أو حتى تحليل الانحدار البسيط على الفور الارتباطات بين سمات حالة وأوقات الأحداث الحدث (YMMV).

Answer 3

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

Answer 4

وإليك ما خطرت لي أساسا. تشك NXC

وقائع الأحداث

وEventID TimeKey CaseID

الأحداث خافت

وEventID EventDesc

خافت الوقت

وTimeKey

المناطق خافت

وRegionID RegionDesc

حقائب

وCaseID RegionID

Answer 5

وهذا قد يكون حالة من اختيار حل قبل أن كنت قد يعتبر مشكلة. ليس كل datawarehouses تنسجم مع نموذج نجمة المخطط. أنا لا أرى أنك تجميع أي بيانات هنا. حتى الآن لدينا جدول حقيقة factless واحد على الأقل بعد تغيير بسرعة (الحالات).

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