يمكن تنفيذ قواعد البيانات باستخدام Excel أو GSheet أو باستخدام أنظمة ORM الكبيرة. في ممارستي لتحليل الأعمال ، صادفت حلولًا مختلفة. وبما أنني أتيت لتحليل الأعمال من المالية والتدقيق ، في كل مرة التقيت فيها بنظام جديد ، سألت نفسي أسئلة - كيف يختلف كل منهم عن الآخر وما هي المهام التي يحلونها؟ وجدت بعض الإجابات. تغطي هذه المقالة غرضين رئيسيين من قواعد البيانات:
1 - محاسبة العمليات ،
2 - تحليل البيانات
يتم حل النوع الأول من المهام بواسطة أنظمة OLTP: من O n L ine T ransaction P rocessing. يتم حل النوع الثاني بواسطة أنظمة OLAP: من O n L ine A معالجة تحليلية
OLTP
يمكن مقارنة طراز تخزين OLTP بإدخالات دفتر الهاتف. يتم تقديم الصف في الجدول كفهرس وفهرس البيانات المطابق: (indexN ، بيانات). لذلك ، لا يمكن أن يسمى جدول مثل جدول. بل هو كتاب عادي ، مع خطوط مرقمة. إذا كنت بحاجة إلى كتابة عملية جديدة إلى الكتاب ، فأضف سطرًا ، وقم بتعيين فهرس وإغلاق الكتاب. التسميات المنبثقة من الكتاب والتي تسمح لك بسرعة (تسجيل ن) ، والعثور على السطر المطلوب والقيام CRUD.
لأغراض المحاسبة العمليات هذا هو عرض ودية. لكنها ليست معادية لتحليل البيانات ، حيث لا تعتبر الخطوط نفسها هي التي تهمنا ، بل الحسابات القائمة على محتويات هذه الخطوط. وإذا قمت بإجراء استعلام تحليلي بناءً على محتويات الصفوف ، أي للحقول غير المفهرسة ، ستعمل مثل هذه الاستعلامات ببطء أكثر.
فهرسة جميع السجلات ، كما تعلمون ، ليس خيارًا. على الرغم من أن الكتاب يصبح كجدول ، مع إتاحة السمات للبحث السريع ، إلا أنه يؤدي أيضًا إلى إبطاء إنشاء صفوف جديدة وتحديث. لأن هذه العمليات سوف تتطلب إعادة فرز المجموعة بأكملها.
المفاضلة بين OLAP و OLTP
في حلول 1C ، يتم تنفيذ حل وسط على النحو التالي. تتم كتابة الأحداث عند الكتابة إلى قاعدة البيانات إلى عدة أماكن في وقت واحد. في مكان واحد ، تحتوي السجلات على عدد قليل من المؤشرات ويتم تحسينها من أجل تحميلات OLTP ؛ في مكان آخر ، يتم فهرسة السجلات حسب جميع الحقول وتكييفها مع تحميلات OLAP. تسمى هذه الجداول سجلات التراكم وسجلات المعلومات. بما أن الكتابة إلى عدة أماكن تزيد من المساحة المشغولة عدة مرات ، لحفظ لا تندرج كل سمات المعاملة في السجلات ، ولكن فقط تلك التي تعتبر مهمة لهذا القسم من المحاسبة التحليلية. يسمى هذا الحل الوسط بنموذج ROLAP ، أي رسم الخرائط التحليلية العلائقية.
OLAP
في SAP ، ذهب النظير الألماني 1C إلى أبعد من ذلك. يمكن نسخ نموذج OLTP العلائقي في هذا البرنامج إلى نموذج OLAP. تطبق SAP HANA بنية عمود التخزين. هذا يعني أن "الجداول" يتم تخزينها هناك ليس كمجموعة من الصفوف ، ولكن كمجموعة من الأعمدة.
يتم تطبيق نظام تخزين مماثل في حلول مثل Google Bigquery و Microsoft SSAS Tabular و Amazon Redshift و Yandex ClickHouse.
الفرق بين تخزين العمود وتخزين الصف
إذا كان يتم تخزين البيانات في بنية حكيمة في شكل tuples "الأفقي" ، كل منها عبارة عن معاملة:
period, product, department (Q1, SKU1, 1) (Q1, SKU2, 1) (Q1, SKU1, 1) ... (Q2, SKU1, 1) (Q2, SKU1, 1) (Q3, SKU1, 1) (Q3, SKU1, 1) ...
ثم في العمود يتم تخزين هذه البيانات "رأسيا":
(Q1, Q1, Q1, ... Q2, Q2, Q3, Q3, ...) (SKU1, SKU2, SKU1, ... SKU1, SKU1, SKU1, SKU1, ...) (1,1,1, ... 1,1,1,1, ...)
يمكن تحسين التكرار بشكل مشروط كما يلي:
period = (Q1, {start: 0, count: n}, Q2, {start: n+1; count: m}, ...) product = (SKU1, {start: 0, count: 1}, SKU2, {start: 1; count: 1}, SKU1, {start: 2; count: m}, ...) department = (1,{start:0, count:m}...)
إذا كان هناك عمود لن يؤدي هذا التحسين إلى تقليل حجمه الأولي ، فسيتم تخزين البيانات في شكلها الأصلي.
يقوم محرك جدول الأعمدة نفسه باختيار تسلسل فرز الأعمدة ، ولكن إذا كنت تعرف بياناتك وتصنفها يدويًا ، فغالبًا ما يؤدي ذلك إلى زيادة الضغط وتخفيف الحمل التحليلي. تجاوز ضغط الجداول الفردية 300 مرة. في الممارسة العملية ، مثل هيكل تخزين البيانات:
- يسمح لك بضغط البيانات إلى المستوى عند وضعها في ذاكرة الوصول العشوائي ، أي إتاحة حسابات في الذاكرة غير قابلة للمقارنة بسرعة مع الاستعلامات لقواعد البيانات العلائقية
- يضع قواعده الخاصة لبناء نموذج بيانات ، لم يعد يتطلب التطبيع كما في OLTP
- يعرف دلالاته لبناء التعبيرات التحليلية.
يتم وصف تفاصيل التعبيرات بالتفصيل:
هنا هو لجوجل BigQuery.
هنا هو لمايكروسوفت داكس.
استقصاء المعلومات كأعمدة البنية الأساسية
BI هو الحل الذي يخدم الحمل التحليلي. وهي تجعل الحياة أسهل كثيرًا إذا كانت مبنية على قواعد بيانات الأعمدة. يمكن أن يكون هذا مجموعة ClickHouse-Grafana-Python محلية الصنع أو حزمة مكدسة من Google: Bigquery-Data Studio-Dataprep-Dataflow أو Power BI.
تعد مكعبات متعددة الأبعاد بديلاً آخر لـ OLAP لتخزين الأعمدة. لكن بالنسبة لي ، فإن تعبيرات MDX ، بالمقارنة مع SQL في BQ أو DAX ، تعتبر زائدة عن الحاجة ومعقدة.