02 - Database Design Concepts

لنوسع الحديث عن مثالنا السابق . شركة لديها مجموعة أسواق تجارية لبيع المواد التموينية . لديها زبائنها و مورديها . سننظر في تصميم قاعدة بيانات مناسبة.

لدينا بدايةً جدول الزبائن:

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

لنتأمل الفاتورة قليلاً . هناك رأس لكل فاتورة ، فيه رقهما ، و تاريخها ، و زبونها . و هناك تفاصيل لها ، في كل تفصيل لدينا المادة ، و واحدتها ، و الكمية و السعر الإفرادي و الإجمالي . ثم هناك إجمالي قيمة الفاتورة . لنبدأ بوضع تصميم أولي للجدول (أو للقاعدة):

هذه هي الحقول (و البيانات) التي تعبر عن رأس الفاتورة:

كيف سنضع التفاصيل ؟ هل نضعها هكذا:

أم هكذا:

في الحالة الأولى ، من الصعب جداً استثمار البيانات . كيف سيتم احتساب النتائج في حقل الإجماليات ، و كيف سيتم إسناد الواحدة للمادة ، السعر الإفرادي ...

في الحالة الثانية ، هناك نقص في البيانات . لا بد من تعبئة قيم حقول رأس الفاتورة أمام كل تفصيل . هكذا:

لماذا ؟ لأنه لابد من أن نقول أن مادة السكر هذه ، قد بيعت في الفاتورة رقم 156 بتاريخ 06/02/2013 لحامد ، و السمنة بيعت في الفاتورة رقم 156 بتاريخ 06/02/2013 لحامد ، و الرز كذلك ... تكرار إجباري للبيانات.

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

فلننظر في هذا التصميم . لنصنع جدولاً أولياً نسميه "رؤوس الفواتير" مثلاً ، نضع فيه المعلومات الرئيسية في الفاتورة ، كما ذكر قبل قليل ، هكذا:

ثم لنضع جدولاً ثانياً يختص بـ "تفاصيل الفواتير" . هكذا:

ولكن ، كيف سنربط التفصيل بفاتورته ؟

جدول رؤوس الفواتير ، كل سطر فيه يعبر عن فاتورة ، و هو مليئ بالفواتير (الأسطر) . و جدول تفاصيل الفواتير ، كل سطر فيه يعبر عن تفصيلة واحدة (قلم) تتبع لفاتورة واحدة . كيف سيتم هذا التتبيع ؟

هكذا:

أضفنا حقل "رقم الفاتورة" ، حتى نوثق أن الأقلام الثلاثة المذكورة تتبع للفاتورة التي رقمها 159.

ألا يسمى هذا تكراراً ؟ ألم يتم تكرار رقم الفاتورة لكل الأقلام ؟ نعم ، و لكنه مقبول جداً ، ليس فقط لأنه ضروري ، بل لأنه أقل ما يمكن . نسميه "تكرار حدي".

لننظر مرة أخرى في بيانات الجدولين:

لدينا الآن ثلاثة فواتير ، و سبعة أقلام تتبع لها . المهم هو مراقبة العلاقة التي تربطهما معاً ، و التثب منها.

لنتأمل هذا:

هذه هي القواعد الثلاثة ، الجدوال ، التي بدأنا الحديث عنها ، إلا أننا نراها الآن بطريقة مختلفة ، من وجهة نظر تصميمية بحتة . لا يوجد بينات هنا لأن البيانات ليست مهمة في هذا المعرض.

لننظر مرة أخرى:

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

لماذا رقم الزبون في جدول الفواتير بدلاً من اسمه؟

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

إلا أنه من وجهة نظر تصميمية ، هذه السيئة هي عين الميزة.

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

و لكن ، لننظر إلى البيانات التالية:

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

و كذلك الأمر المادة رقم 99 ، "حليب" ، لم تبع و لا مرة ، و لا مشكلة تصميمية في ذلك.

أما الفاتورة رقم 915 ، فهي تشير إلى زبون رقمه 999 ، و أما تفاصيل الفواتير الملونة بالأحمر ، فهي تشير إلى تبعيتها لفاتورة رقمها 160 غير موجودة أصلا في جدول الفواتير ، أما السطر الأخير الظاهر في تفاصيل الفواتير فهى يحوي المادة رقم 26 ... و التي على ما يبدو محذوفة من جدول المواد !

هناك خلل في البيانات . نقول: خلل في تكامل البيانات ، Data Integration Error ، لماذا كلمة تكامل؟ لأن معلومات الفاتورة لا تكتمل إلا بالعودة للجداول الأخرى ، و كذلك معلومات تفاصيل الفواتير ، و كل الجدوال الأخرى . العلاقة بين هذه الجداول هي في الحقيقة علاقة تكامل.

كيف حدثت هذه المشاكل؟

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

2.      حذف البيانات
كان هناك زبون رقمه 915 في جدول الزبائن ، إلا أن صاحبنا المسؤول عن هذا الدرج قام بحذف الزبون دون الرجوع إلى جدول الفواتير ، و التحقق فيما إذا كان مستخدماً ...

3.      تعديل البيانات
قام أحدهما بتعديل رقم الزبون بعد أن كان صحيحاً . هذا التعديل تم دون مراقبة.

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

علم قواعد البيانات ، يضع قاعدةً ، شرطاً ، يكفل "استحالة" حدوث هذه المشكلة . اسم هذا الشرط هو "شرط التكامل المرجعي" ، أو ما يعرف بالـ Referential Integrity.