سؤال

في مقدمة هذا، لست على دراية بـ OLAP على الإطلاق، لذا إذا كانت المصطلحات معطلة، فلا تتردد في تقديم التصحيحات.

أنا أقرأ عن OLAP ويبدو أن الأمر كله يتعلق باستبدال المساحة بالسرعة، حيث تقوم بالحساب المسبق (أو الحساب عند الطلب) وتخزين التجميعات حول بياناتك، مقفلة بأبعاد معينة.أفهم كيفية عمل ذلك مع الأبعاد التي تحتوي على مجموعة منفصلة من القيم، مثل { ذكر، أنثى } أو { يناير، فبراير، ...ديسمبر } أو { @US_STATES }.ولكن ماذا عن الأبعاد التي لها قيم عشوائية تمامًا مثل (0، 1.25، 3.14156، 70000.23، ...)؟

هل يمنع استخدام OLAP استخدام التجميعات في الاستعلامات التي تصل إلى جداول الحقائق، أم أنه يستخدم فقط لتجاوز الأشياء التي يمكن حسابها مسبقًا؟مثل، هل لا يزال يتعين القيام بالتجميعات التعسفية على القيم التعسفية بسرعة؟

أي مساعدة أخرى فيما يتعلق بمعرفة المزيد عن OLAP ستكون موضع تقدير كبير.للوهلة الأولى، يبدو كل من Google وSO جافين بعض الشيء (مقارنة بالموضوعات الأخرى الأكثر شيوعًا).

يحرر:تم سؤالك عن البعد الذي توجد عليه قيم عشوائية.

  • سرعة التجارب:1.256 م/ث، -2.234 م/ث، 33.78 م/ث
  • قيمة المعاملات:120.56 دولارًا، 22.47 دولارًا، 9.47 دولارًا
هل كانت مفيدة؟

المحلول

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

ومع ذلك، قلت عادة.في مخطط OLAP الخاص بنا، لدينا مثال جيد لعمود تفكر فيه:event_time (حقل التاريخ والوقت، مع دقة الثانية).في بياناتنا، سيكون الأمر فريدًا تقريبًا - لن يقع حدثان خلال نفس الثانية، ولكن بما أن لدينا سنوات من البيانات في جدولنا، فإن هذا لا يزال يعني أن هناك مئات الملايين من القيم المنفصلة المحتملة، وعندما نجري استعلامات OLAP، نريد دائمًا تقييدها بناءً على النطاقات الزمنية.

الحل هو أن تفعل ما قاله ديفيد رازنيك - أن تقوم بإنشاء نسخة "مجمعة" من القيمة.لذلك، في جدولنا، بالإضافة إلى عمود "event_time"، لدينا عمود "event_time_bucketed" - وهو مجرد تاريخ الحدث، مع كون الجزء الزمني هو 00:00:00.وهذا يقلل من عدد القيم المميزة من مئات الملايين إلى بضعة آلاف.بعد ذلك، في جميع الاستعلامات التي تقيد التاريخ، فإننا نقيد كلاً من العمود المعبأ والعمود الحقيقي (نظرًا لأن العمود المعبأ لن يكون دقيقًا بما يكفي لتزويدنا بالقيمة الحقيقية)، على سبيل المثال:

   WHERE event_time BETWEEN '2009.02.03 18:32:41' AND '2009.03.01 18:32:41'
     AND event_time_bucketed BETWEEN '2009.02.03' AND '2009.03.01'

في هذه الحالات، لن يتمكن المستخدم النهائي من رؤية عمود events_time_bucketed أبدًا - فهو موجود فقط لتحسين الاستعلام.

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

نصائح أخرى

لقد وجدت هذا الرابط ليكون في متناول يدي http://www.ssas-info.com/

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

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

تحتوي خدمات تحليل SQL Server على معالج التحسين المستند إلى الاستخدام والذي يساعد في تصميم التجميع من خلال تحليل الاستعلامات التي تم إرسالها من قبل العملاء (عملاء التقارير مثل SQL Server Reporting Services أو Excel أو أي شيء آخر) وتحسين تصميم التجميع وفقًا لذلك.

آمل أن يساعد هذا.

هتافات

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top