وصف التطبيع
تطبيع قاعدة البيانات هي عملية التصميم المستخدمة لتنظيم مجموعة معينة من البيانات في جداول وأعمدة في قاعدة البيانات. يجب أن يحتوي كل جدول على بيانات تتعلق بـ "شيء" محدد ويحتوي فقط على بيانات تدعم نفس "الشيء" المدرج في الجدول. يتمثل الهدف من هذه العملية في تقليل البيانات المكررة الموجودة في قاعدة بياناتك، لتقليل انخفاض الأداء لإدخالات قاعدة البيانات والتحديثات. على سبيل المثال، يكون تغيير عنوان العميل أسهل بكثير في التنفيذ إذا كان المكان الوحيد الذي يتم تخزين عنوان العميل فيه في جدول العملاء. النماذج الأكثر شيوعًا من التطبيع هي النموذج العادي الأول والثاني والثالث والنماذج الموصوفة أدناه.
النموذج العادي الأول
يتمتع النموذج العادي الأول بالمواصفات التالية:
- إنشاء جدول منفصل لكل مجموعة من البيانات ذات الصلة
- إزالة المجموعات المتكررة في جداول فردية
- تحديد كل مجموعة من البيانات ذات الصلة باستخدام مفتاح أساسي
في هذا النموذج، يجب عدم استخدام أعمدة متعددة في جدول واحد لتخزين بيانات متشابهة. على سبيل المثال، إذا كان يمكن إصدار المنتج بألوان متعددة، يجب ألا تكون لديك أعمدة متعددة في سجل واحد تحتوي على قيم ألوان مختلفة. لا يعد الجدول الأول أدنى (ProductColors) بتنسيق النموذج العادي الأول، حيث إن هناك قيماً متكررة للون. بالنسبة إلى المنتجات ذات اللون الواحد فقط، توجد مساحة مهدرة. وماذا لو جاء منتج في أكثر من ثلاثة ألوان؟ بدلاً من الاضطرار إلى ضبط الحد الأقصى لعدد الألوان، يمكننا إعادة إنشاء الجدول كما هو موضح في الجدول الثاني، لون المنتج. لدينا أيضاً متطلبات النموذج العادي الأول حيث يوجد مفتاح فريد للجدول، وهو العمود (أو الأعمدة) التي تحدد قيمة الصف بشكل فريد. لا يعتبر أي من الأعمدة في الجدول الثاني فريدًا، ولكن تركيبة معرف المنتج واللون فريدة. عند الحاجة إلى أعمدة متعددة، نطلق عليها مفتاحًا مركبًا.
| معرّف المنتج | اللون 1 | اللون 2 | اللون 3 |
|---|---|---|---|
| 1 | أحمر | أخضر | أصفر |
| 2 | أصفر | ||
| 3 | أزرق | أحمر | |
| 4 | أزرق | ||
| 5 | أحمر |
| معرّف المنتج | اللون |
|---|---|
| 1 | أحمر |
| 1 | أخضر |
| 1 | أصفر |
| 2 | أصفر |
| 3 | أزرق |
| 3 | أحمر |
| 4 | أزرق |
| 5 | أحمر |
يوجد الجدول الثالث، معلومات المنتج، في النموذج العادي الأول لأن كل سجل يشير إلى منتج معين، وليست هناك مجموعات مكررة، ولدينا عمود معرّف المنتج لاستخدامه كمفتاح أساسي.
| معرّف المنتج | اسم المنتج | Price | دولة الإنتاج | الموقع المختصر |
|---|---|---|---|---|
| 1 | عنصر واجهة المستخدم | 15.95 | الولايات المتحدة | US |
| 2 | فوب | 41.95 | المملكة المتحدة | المملكة المتحدة |
| 3 | جلومبيت | 49.95 | المملكة المتحدة | المملكة المتحدة |
| 4 | سورفين | 99.99 | جمهورية الفلبين | جمهورية الفلبين |
| 5 | برغى الكبح | 29.95 | الولايات المتحدة | US |
النموذج العادي الثاني
يتمتع النموذج العادي الثاني بالمواصفات التالية، بالإضافة إلى تلك المطلوبة من خلال النموذج العادي الأول:
- إذا كان الجدول يحتوي على مفتاح مركب، يجب أن تعتمد كافة السمات على المفتاح الكامل وليس فقط جزء منه.
النموذج العادي الثاني هو فقط النموذج ذات الصلة بالجداول مع باستخدام المفاتيح المركبة، كما هو الحال في الجدول لون المنتج وهو الجدول الثاني أعلاه. ولنتأمل هنا الحالة التي يتضمن فيها جدول لون المنتج أيضًا سعر المنتج. يحتوي هذا الجدول على مفتاح مركب على معرّف المنتج واللون أنه باستخدام قيمتي العمود فقط يمكننا تحديد السجل بشكل فريد. إذا لم يتغير سعر المنتج مع اللون، فقد نرى البيانات كما هو موضح في هذا الجدول:
| معرّف المنتج | اللون | Price |
|---|---|---|
| 1 | أحمر | 15.95 |
| 1 | أخضر | 15.95 |
| 1 | أصفر | 15.95 |
| 2 | أصفر | 41.95 |
| 3 | أزرق | 49.95 |
| 3 | أحمر | 49.95 |
| 4 | أزرق | 99.95 |
| 5 | أحمر | 29.95 |
الجدول أعلاه ليس في النموذج العادي الثاني. تعتمد قيمة السعر على ProductID ولكن ليس على اللون. هناك ثلاثة سجلات لمعرّف المنتج 1، لذلك يتكرر سعر هذا المنتج ثلاث مرات. تكمن مشكلة مع مخالفة النموذج العادي الثاني في أنه إذا كان يجب علينا تحديث السعر، فعلينا أن نتأكد من تحديثه في كل مكان. إذا قمنا بتحديث السعر في السجل الأول ولكن ليس السجل الثاني أو الثالث، فسوف يكون لدينا ما نطلق عليه شيئًا يسمى "شذوذ التحديث". بعد التحديث، لن نتمكن من معرفة السعر الفعلي لمعرّف المنتج 1. الحل هو نقل عمود السعر إلى جدول يحتوي على معرّف المنتج كمفتاح عمود فردي، لأن هذا هو العمود الوحيد الذي يعتمد عليه السعر. على سبيل المثال، يمكننا استخدام الجدول 3 لتخزين السعر.
إذا كان سعر المنتج مختلفاً استناداً إلى لونه، فسيكون الجدول الرابع بتنسيق النموذج العادي الثاني، لأن السعر يعتمد على كلا الجزأين من المفتاح: ProductId وColor.
النموذج العادي الثالث
يعتبر النموذج العادي الثالث هو الهدف لمعظم قواعد بيانات OLTP. يتمتع النموذج العادي الثالث بالمواصفات التالية، بالإضافة إلى المواصفات المطلوبة من قبل النموذج العادي الثاني:
- تعتبر كافة الأعمدة غير الأساسية غير عابرة بناءً على المفتاح الأساسي.
تُعنى العلاقة العابرة أن هناك عمودًا واحدًا في جدول يرتبط بالأعمدة الأخرى، من خلال عمود ثانٍ. تعني التبعية أنه يمكن للعمود اشتقاق قيمته من عمود آخر، نتيجة للتبعية. على سبيل المثال، يمكن تحديد عمرك من تاريخ ميلادك، ما يجعل عمرك يعتمد على تاريخ ميلادك. الرجوع إلى الجدول الثالث، معلومات المنتج. يوجد هذا الجدول في النموذج العادي الثاني، ولكن ليس في العمود الثالث. يتبع عمود ShortLocation عمود ProductionCountry الذي لا يعد مفتاحاً. مثل النموذج العادي الثاني، يمكن أن تؤدي مخالفة النموذج العادي الثالث إلي شذوذ التحديث. إذا قمنا بتحديث ShortLocation في صف واحد، دون تحديثه في جميع الصفوف حيث يظهر الموقع، ينتهي بنا الأمر حينها إلى بيانات غير متناسقة. لمنع ذلك، يمكننا إنشاء جدول منفصل لتخزين أسماء البلدان/المناطق ونماذجها المختصرة.
نشر التكرار
بينما يعد النموذج العادي الثالث مرغوباً فيه نظرياً، فإنه ليس أمراً ممكناً دائماً لكافة البيانات. بالإضافة إلى ذلك، لن تمنحك دوماً قاعدة البيانات التي تم تقليل تكراراتها أفضل أداء. تتطلب البيانات التي عادت لطبيعتها بشكل متكرر عمليات ربط متعددة للحصول على كافة البيانات الضرورية التي يتم إرجاعها في الاستعلام الفردي. توجد مفاضلة بين تقليل البيانات المكررة عندما يكون عدد الروابط المطلوبة لإعادة نتائج الاستعلام ذات استخدام مرتفع للمعالج وبيانات نشر التكرار التي تحتوي على عدد أقل من الروابط ذات استخدام منخفض للمعالج، ولكن يتيح ذلك إمكانية وقوع أحداث للتحديث خارجة عن المألوف.
إشعار
بيانات نشر التكرار ليست هي البيانات غير الطبيعية. بالنسبة إلى نشر التكرار، نبدأ بتصميم الجداول التي يتم تطبيعها. ثم يمكننا إضافة أعمدة إضافية إلى بعض الجداول لتقليل عدد الروابط المطلوبة، ولكن كما نقوم بذلك، ونحن على علم بشذوذ التحديث المحتمل. ثم نتأكد من أن لدينا مشغلات أو أنواعًا أخرى من المعالجة التي سوف تتأكد من أنه عند القيام بتحديث، يتم تحديث كافة البيانات المكررة أيضًا.
يمكن أن تكون بيانات نشر التكرار أكثر كفاءة في الاستعلام، خاصةً بالنسبة إلى أحمال العمل الثقيلة للقراءة مثل مستودع البيانات. في هذه الحالات، قد يوفر وجود أعمدة إضافية أنماط استعلام أفضل و/أو استعلامات أكثر تبسيطاً.
مخطط نجمي
في حين أن معظم التطبيع يستهدف أعباء عمل OLTP، تتمتع مستودعات البيانات ببنية نموذج خاص بهم، والتي عادة ما تكون نموذجًا لنشر التكرار. يستخدم هذا التصميم جداول الحقائق، التي تسجل القياسات أو المقاييس لأحداث معينة مثل البيع، ويربطهم بجداول الأبعاد، والتي تكون أصغر من حيث عدد السجلات ولكن قد تتضمن عددًا كبيرًا من الأعمدة لوصف بيانات الحقيقة. ومن الأمثلة على ذلك، تشمل الأبعاد المخزون و/ أو الوقت و/أو الجغرافيا. يتم استخدام نمط التصميم لتصبح قاعدة البيانات أسهل في الاستعلام وعرض مكاسب الأداء من أجل تحقيق أحمال العمل للقراءة.
تعرض الصورة أعلاه مثالاً للمخطط النجمي، بما في ذلك جدول حقائق مبيعات الموزعين وأبعاد التاريخ والعملة والمنتجات. يحتوي جدول الحقائق على البيانات المتعلقة بمعاملات المبيعات، كما تحتوي الأبعاد فقط على بيانات تتعلق بعنصر محدد من بيانات المبيعات فقط. على سبيل المثال، يحتوي الجدول حقيقة مبيعات الموزعين فقط على مفتاح المنتج للإشارة إلى المنتج الذي تم بيعه. يتم تخزين كافة التفاصيل حول كل منتج في جدول DimProduct وترتبط مرة أخرى بجدول الحقائق مع العمود ProductKey.
وفيما يتعلق بتصميم المخطط النجمي فهو مخطط بلورة ثلجية، والذي يستخدم مجموعة من الجداول المطبعة لكيان عمل واحد. تعرض الصورة التالية مثالاً لبعد واحد من آجل مخطط بلورة ثلجية. يتم تطبيع وتخزين بعد المنتج في ثلاثة جداول تسمى فئة أبعاد المنتج، وفئة أبعاد المنتج الفرعية، وأبعاد المنتج.
الفرق الرئيسي بين المخططات النجمية ومخططات البلورة الثلجية هو أن الأبعاد في مخطط البلورة الثلجية يتم تطبيعها للحد من التكرار، ما يوفر مساحة التخزين. المبادلة هي أنه تتطلب استعلاماتك المزيد من الروابط، والتي يمكن أن تزيد من تعقيدك وتقلل من الأداء.