مستودع بيانات مخطط Kimball Star النموذجي - طرق عرض النموذج ممكنة؟وكيفية ترميز الجنرال

Question

لدي مستودع بيانات يحتوي على مخططات نجمية نموذجية، ومجموعة كاملة من التعليمات البرمجية التي تفعل أشياء مثل هذه (من الواضح أنها أكبر بكثير، ولكن هذا توضيحي):

SELECT cdim.x
    ,SUM(fact.y) AS y
    ,dim.z
FROM fact
INNER JOIN conformed_dim AS cdim
    ON cdim.cdim_dim_id = fact.cdim_dim_id
INNER JOIN nonconformed_dim AS dim
    ON dim.ncdim_dim_id = fact.ncdim_dim_id
INNER JOIN date_dim AS ddim
    ON ddim.date_id = fact.date_id
WHERE fact.date_id = @date_id
GROUP BY cdim.x
    ,dim.z

أفكر في استبداله بطريقة عرض (MODEL_SYSTEM_1, ، مثلاً)، بحيث يصبح:

SELECT m.x
    ,SUM(m.y) AS y
    ,m.z
FROM MODEL_SYSTEM_1 AS m
WHERE m.date_id = @date_id
GROUP BY m.x
    ,m.z

لكن الرأي MODEL_SYSTEM_1 يجب أن تحتوي على أسماء أعمدة فريدة، كما أنني أشعر بالقلق بشأن الأداء مع المُحسِّن إذا واصلت القيام بذلك، لأنني أشعر بالقلق من أن جميع العناصر الموجودة في جملة WHERE عبر حقائق وأبعاد مختلفة قد تم تحسينها، نظرًا لأن سيكون العرض عبر نجم كامل، ولا يمكن تحديد حدود المشاهدات (يا فتى، أليس هذا رائعًا!)

لذلك أسئلتي هي -

1. هل هذا النهج مقبول، أم أنه سيكون مجرد تجريد يضر بالأداء ولا يمنحني أي شيء سوى صياغة أجمل بكثير؟

2. ما هي أفضل طريقة لترميز طرق العرض هذه، مع إزالة أسماء الأعمدة المكررة (حتى لو كان العرض بحاجة إلى تعديل يدويًا لاحقًا)، مع الأخذ في الاعتبار وجود جميع PK وFKs المناسبة في مكانها الصحيح؟هل يجب أن أكتب بعض SQL لإخراجها من ملف INFORMATION_SCHEMA أم أن هناك مثال جيد متاح بالفعل.

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

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

إذا كان أي شخص يريد الكود، ربما يمكنني نشره هنا.

Answer 1

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

2. لقد قمت بإنشاء طرق العرض باستخدام المصمم في استوديو إدارة SQL Server ولم أستخدم أي أسلوب تلقائي.لا أستطيع أن أتخيل أن المخطط يتغير كثيرًا بما يكفي لجعله آليًا مفيدًا على أي حال.قد تقضي وقتًا طويلاً في تعديل النتائج كما لو كان الأمر يتطلب سحب جميع الجداول إلى العرض في المقام الأول!

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

Answer 2

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

يمكنك استخدام قاموس البيانات أو طرق عرض مخطط المعلومات لإنشاء SQL لإنشاء الجداول إذا كان لديك عدد كبير من هذه الملخصات أو كنت ترغب في تغييرها بشكل متكرر.

ومع ذلك، أعتقد أنه من غير المحتمل أن تقوم بتغيير هذه العناصر في كثير من الأحيان، لذا فإن إنشاء تعريفات العرض تلقائيًا قد لا يستحق العناء.

Answer 3

إذا كنت تستخدم MS SQL Server، فيمكنك تجربة Inline UDF وهو أقرب ما يكون إلى ملف عرض المعلمات كما يحصل.