قواعد البيانات العلائقية مقابل الأبعاد ، ما الفرق؟

Question

أحاول أن أتعرف على OLAP وتخزين البيانات ، وأنا مرتبك بشأن الفرق بين النمذجة العلائقية والأبعاد. هل النمذجة الأبعاد نمذجة علائقية بشكل أساسي ، ولكن السماح ببيانات زائدة/غير طبيعية؟

على سبيل المثال ، لنفترض أن لدي بيانات مبيعات تاريخية على (المنتج ، المدينة ، # المبيعات). أفهم أن ما يلي سيكون وجهة نظر علائقية:

Product | City | # Sales
Apples, San Francisco, 400
Apples, Boston, 700
Apples, Seattle, 600
Oranges, San Francisco, 550
Oranges, Boston, 500
Oranges, Seattle, 600

في حين أن ما يلي هو وجهة نظر أكثر أبعادًا:

Product | San Francisco | Boston | Seattle
Apples, 400, 700, 600
Oranges, 550, 500, 600

ولكن يبدو أن كلا وجهات النظر سيتم تنفيذها في مخطط نجم متطابق:

Fact table: Product ID, Region ID, # Sales
Product dimension: Product ID, Product Name
City dimension: City ID, City Name

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

City dimension: City ID, City Name, Region ID
Region dimension: Region ID, Region Name, Region Manager, # Regional Stores

في حين أن قاعدة بيانات الأبعاد ستسمح بإعادة تخصيصها للحفاظ على بيانات المنطقة داخل بعد المدينة ، من أجل تسهيل تقطيع البيانات:

City dimension: City ID, City Name, Region Name, Region Manager, # Regional Stores

هل هذا صحيح؟

Answer 1

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

أقول يشبه إلى حد ما لأن العديد من منهجيات التصميم العلائقية تؤدي إلى تصميم طبيعي ، أو على الأقل تصميم طبيعي تقريبًا. سيكون لمخطط النجوم مغادرة كبيرة من التطبيع الكامل.

كل خروج من التطبيع الكامل يحمل معه شذوذ تحديث البيانات. (أنا بما في ذلك Anomlaies على إدراج العمليات وتحديثها وحذفها تحت مظلة واحدة). هذه الحالات الشاذة لا علاقة لها بنموذج البيانات الذي بدأت به.

التعليق على OLTP مقابل OLAP مناسب هنا. سيكون لدى تحديث الحالات الشاذة تأثيرات مختلفة على الأداء و/أو صعوبة البرمجة في هاتين حالتين.

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

مثلما كإجراء استطهاد من سؤالك ، قمت ببناء مخطط النجوم ذات مرة كخطوة وسيطة بين قاعدة بيانات OLTP التي دعمت تطبيقًا قائمًا على المعاملة ودانكوبول داخل Cognos PowerPlay. باستخدام تقنيات ETL القياسية ، فإن النقل المشترك من قاعدة بيانات OLTP إلى مخطط النجوم ومن ثم من مخطط النجوم إلى مكعب البيانات تفوق بالفعل على النقل المباشر من قاعدة بيانات OLTP إلى DataCube. كانت هذه نتيجة غير متوقعة.

أتمنى أن يساعدك هذا.

Answer 2

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

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

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

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

• جميع المفاتيح الأجنبية حقيقة واحدة -لا يوجد بعد للبعد (أي Master to Master Table Join) .. Snowflake تمثل نفس البعد
  • الحقائق المصممة بشكل مثالي تحمل أرقامًا فقط .. التدابير أو المفاتيح الأجنبية
  • يتم استخدام البعد لحمل الوصف والمعلومات غير القابلة للتجميع
  • يتم تجاهل التكرار من البيانات ... ولكن في حالات نادرة إذا كانت الأبعاد نفسها تنمو أكثر من اللازم ، يُنظر

للحصول على التفاصيل ، يرجى مرور كتب مفصلة حول هذا الموضوع.

Answer 3

لقد قرأت مؤخرًا الفرق بين نمذجة البيانات الأبعاد والعلائقية نظرًا لأننا نستخدم النماذج العلائقية بشكل أساسي في عملي حيث نقوم بتخزين مستودع بيانات المؤسسة (EDW).

وفقًا لستيف هوبرمان في كتابه ، فإن "نمذجة البيانات جعلت بسيطة" التمييز بين النوعين من النماذج هو:

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

يمكن القول أنه يمكن أيضًا استخدام نموذج علائقي كأساس للإجابة على أسئلة العمل ، ولكن على المستوى التكتيكي. "كم عدد الطلبات الموجودة في حالة غير محققة للعميل X بسبب تعليق الائتمان؟" لكن التمييز هو المكان الذي يحتاج فيه سؤال الإبلاغ إلى "الحبوب الأصلية" للجدول وعندما يمكن الإجابة على سؤال الإبلاغ بالبيانات الملخصة.

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

Answer 4

لقد وجدت الوصف الذي وجدته http://www.orafaq.com/node/2286 أن تكون مفيدًا للغاية عند القدوم إلى Scar Schema من منظور علائقي.

النظر في نموذج البيانات الطبيعية بالكامل. فكر الآن في العكس تمامًا ، حيث تقوم بتشغيل نموذج البيانات العلائقية تمامًا بحيث يكون لديك سجل مسطح واحد فقط مثل جدول بيانات Big'ol مع صف واسع جدًا. الآن احتياطيًا من هذا السجل المسطح قليلاً حتى يكون لديك نموذج بيانات لا يتجزأ سوى مستويين ؛ طاولة كبيرة واحدة ، والعديد من الجداول الصغيرة التي يشير إليها الجدول الكبير. هذا مخطط نجمة. وبالتالي فإن نموذج بيانات النجوم الحقيقي له سمتان ، إنه دائمًا مستويان عميقان ، ويحتوي نموذج النجمة الحقيقي دائمًا على جدول كبير واحد فقط هو محور النموذج.