الأخ العزيز صايل، لم أقصد امتحانك، وإنما الأمر أشبه بأني لم أرد أن أقاطع كلامك، فأحببت أن أنتظر حتى تنتهي من سرد ملحوظاتك. وعلى كل حال، أشكر لك ثقتك الكبيرة، وأسأل الله أن يزيدنا جميعاً من علمه وفضله، وبعد...
أولاً: أتفق بشكل عام مع تصميم الأخ صايل، عدا تفاصيل يسيرة جداً أوضحها إن شاء الله فيما يلي، كل ذلك في رأيي، والله أعلم.
ثانياً: كلمة مهمة عن أهمية التحليل مرة أخرى. من المهم غاية الأهمية ملاحظة أن التصميم يتبع دائماً التحليل، لأن متطلبات النظام هي التي تحدد تصميمه. حتى الأنظمة المتشابهة في التصنيف العام، مثلاً، أنظمة المخازن والمبيعات والخدمات، قد تختلف في بعض التفاصيل، مما يؤدي إلى اختلاف يسير أو كبير في تصميم الجداول. أقول هذا لأن بعض الاختلافات في التصميم ليست صحيحة أو خاطئة إلا بعد أن يقول التحليل كلمته. مثال على ذلك: هل يوكل كل نادل بطاولة أو أكثر؟ الذي يحدد هذا هو متطلبات النظام، والذي يحدد متطلبات النظام هو صاحب النظام أو من يمثله في مرحلة التحليل. الإجابة عن هذا السؤال تحدد وجود حقل للنادل في جدول الطاولات من عدمه. كذلك بالنسبة للزبائن: كيف هي طبيعة تدفق الإجراءات في النظام؟ هل يدخل الزبون طلبيته بنفسه؟ يعني هل يحدد نفسه بنفسه؟ بالطبع لا يمكن حفظ كل من يدخل المطعم كزبون، لكن إذا افترضنا أن صاحب المطعم سيقوم بإدخال بيانات الزبائن المميزين بنفسه بين حين وآخر، هل يعامل الزبائن بالدين، أم فقط بحسن الخدمة؟ ما سبق قد يقتضي زيادة بعض الحقول في قاعدة البيانات، وبعد ذلك التأكد من صلاحيات الإدخال في البرنامج. مثلاً، إذا كان هناك حقل سيحدد نوع الفاتورة (نقد أم آجل) من أجل الزبائن المميزين، فيجب التأكد من أن هذا الاختيار يتم بواسطة الزبون المناسب فقط، وليس من قبل أي زبون غير مميز (لاحظ أن الزبون يدخل تفاصيل طلبيته بنفسه). سنفترض هنا أن صاحب المطعم يريد أن يميز بعض الزبائن، وأن هذا التمييز يتجلى فقط في نوع الخدمة، ولهذا يمكن أن نعد تصميم الأخ صايل لجدول الزبائن كافياً، بمعنى أنه يكفينا حقل لتحديد مدى امتياز هذا الزبون بوساطة مدى تردده على المطعم. مثال آخر، في كل المطاعم تقريباً، يمكن أن تكون الطلبية لطبق يؤخذ خارج المطعم (takeaway)، نسميه عندنا (سفري)، على خلاف الطبق الذي يتم تناوله داخل المطعم (نسميه عادة بالمحلي). إذا كان صاحب المطعم سيستخدم النظام في توصيل الطلبية إلى المطبخ، ومن ثم إلى الزبون، فإن هذه المعلومة مهمة، وترتبط بكل فاتورة. الخلاصة هنا: لا بد من معلومات من صاحب النظام من أجل تصميم مناسب للنظام.
الآن أريد أن أنبه على نقطة: في كل برامج المبيعات التي تتاجر بأصناف (المطعم يبيع أطباقاً)، هناك فواتير بيع. تشكل الفواتير مركز برامج المبيعات، وتتعلق الفواتير بكائنات أخرى لا بد منها من أجل أداء مهمة النظام. لذا، يشكل تصميم الجزء الخاص بالفواتير وما يتعلق بها لب تصميم قاعدة بيانات برنامج مبيعات. لحسن الحظ، كما أوضحت في سلسلة المذكرات، هناك تصميم نستطيع أن نقول إنه شبه قياسي (standard) بالنسبة لهذا الجزء، تشترك فيه جل أو كل برامج المبيعات (تستطيع أن تجد مثالاً لهذا التصميم في قاعدة بيانات Northwind المثال التي تأتي مع نسخة الأكسس). دوماً هناك فاتورة. المطاعم عادة تصدر هذه الفاتورة للزبون بعد الوجبة من أجل الدفع. في حالتنا هذه، يمكن أن نسمي هذه الفاتورة (طلبية)، وتصدر نسخة منها للزبون مباشرة عند اختياره للطلبية. لكل فاتورة أو طلبية رقم وتاريخ، ثم يمكن أن نضيف حقلاً لنوع الفاتورة (سفري، محلي). هذا كائن. هناك كائن آخر هو الطبق، ولكل طبق اسم وسعر على الأقل. نعم، قد نختار إضافة رقم الطبق كخاصية تلعب دور المفتاح الأساسي عوضاً عن اسم الطبق.
بالمناسبة، وعلى ذكر المفتاح الأساسي، السر في أن تصميم جدول الطلبات للأخت الجمان غير مناسب بتاتاً هو أنه يكسر أول شرط لجداول قواعد البيانات العلائقية، حتى قبل أي تسوية، وهو أن يكون لكل جدول مفتاح أساسي. من أجل هذا لا نستطيع تمييز طلبية بعينها؛ لا يوجد رقم للطلبية، ولا أي خليط من الحقول يكون مفتاحاً لا يتكرر، كل الحقول من الممكن
أن تتكرر قيمها: الطاولة والكمية والصنف والنادل. وهذا هو السر في ملحوظة الأخ صايل بارك الله فيه.
نعود إلى كائن الطبق. سعر الطبق ثابت تقريباً، على الأقل لفترات طويلة، ولهذا هو من خصائص كائن الطبق. الآن، الذي يربط كائني الطلبية والطبق هو أن طبقاً أو أكثر قد يظهر في طلبية، كما أن أكثر من طلبية قد تحوي نفس الطبق. هذا يعني علاقة من نوع متعدد إلى متعدد. علاوة على ذلك، هذه العلاقة عندما تحدث بين طلبية وطبق، تحمل معها خصائص خاصة بها، مثل الكمية المطلوبة. لاحظ هنا أن الزبون قد يطلب كمية لشخص أو أكثر من نفس الطبق في طلبية واحدة.
ثم، هناك كائن الطاولة. لماذا كانت الطاولة كائناً مستقلاً، ولم تك مجرد خاصية من خصائص الطلبية؟ هذا، كما ناقشنا في المذكرات، من أجل أن الطاولة هنا تعامل معاملة خاصة، وعلامة هذه المعاملة الخاصة أننا نخصص نادلاً لكل طاولة. هذا يقودنا أيضاً إلى كائن النادل، لكنني لن أضمه إلى تصميم قاعدة البيانات هنا من أجل الاختصار فقط. إذاً، يمكن الآن أن نرسم مخطط الكائنات والعلاقات التالي:
لم أضم أصناف الأطباق الأساسية عمداً، كتطبيق على (إزالة التسوية)، لأن قيم الأصناف ثابتة لا تتغير (طبق أساسي، مقبلات، حلويات ومشروبات) حسب النقاش في إحدى حلقات المذكرات.
وكذلك حسب إحدى حلقات المذكرات، التي تتكلم عن قواعد التحويل بين المخطط والجداول بالتحديد، هذا التصميم يقودنا إلى مجموعة الجداول التالية، مع بعض الاختلافات الطفيفة، وبدون جدول الطاولات:
هنا ملحوظة، هي أنني قد قمت بتكرار حقل سعر الطبق في جدول تفاصيل الطلبية، على الرغم من وجوده في جدول الأطباق. السبب في ذلك ليس هو احتمالية اختلاف سعر الطبق الواحد من طلبية إلى أخرى، وإنما من أجل الاحتفاظ بسجل تاريخي لأسعار الأطباق، لأن الأسعار القديمة سوف تختفي إلى الأبد عندما نغير سعر الطبق في جدول الأطباق بين فترة وأخرى. أرفقت ملفاً يحوي هذه الجداول المقترحة. من الملاحظ طبعاً أن هذا التصميم المقترح شبيه جداً بتصميم الأخ صايل عزام حفظه الله تعالى.
هذا والله أعلم.
تم تعديل هذه المشاركة بواسطة أحمد مبارك الحيقي في 22 ديسمبر 2009 في 15:33