مذكرات حول تصمبم قواعد البيانات وتطبيقاتها

أخى نبيل .... مرحباً بعودتك ...

أما الكلام التالى لـــ Slave

يابنى هخطفك

الأخ العزيز slave ..

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

ووالله أنت عامل جو جامد فى المشاركات ..

وبالراحة عليا يا سيدى ..

وعلى فكرة انا حاولت أبعت راسى فى المرفقات بس لقيت الحجم الأقصى 3 ميجا .. وأنا راسى 5 ميجا بعد الضغط كمان...

ممكن أرفعهالك على لينك أوك؟؟

قشطة

رقم الحلقة (27)

(الجزء الأول، وقبل الأخير بإذن الله)

نقطتان بين يدي هذه الحلقة:

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

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

2. من مجمل مشاركات الإخوة الأخيرة، ربما كنا نحتاج إلى بعض التوقف، وانتظار ردود الفعل، وبعدها استئناف الحلقات على ضوء النتيجة، لكنني سأستمر بإذن الله في تداول بعض الأفكار، لبعض الأسباب:

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

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

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

الآن، لنعد إلى موضوع نظام المخازن والمبيعات. توقفنا في الحلقة السابقة عند جدول الأصناف، وكخلاصة، وصلنا إلى أن بعض التفاصيل قد تختلف من تصميم إلى آخر حسب الاحتياجات التفصيلية للنظام، وحسب اختيار المصمم / المبرمج لمعالجة بعض القضايا. لكن من الممكن أن نختار تصميماً عاماً مناسباً في الغالب:

رمز الصنف

اسم الصنف

مجموعة الصنف

وصف الصنف

المصنع

رقم الرف

الحد الأدنى

الكمية الافتتاحية

الكمية المتوفرة

الوحدة الأساسية

السعر الافتراضي

ملحوظات

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

رمز الصنف (مفتاح أجنبي لربط الوحدة الفرعية بصنف من جدول الأصناف)

الوحدة الفرعية

معامل التحويل

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

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

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

هل كان ذلك واضحاً؟ جيد، إذاً دعنا الآن نكسر بعض افتراضاتنا السابقة! التحليل قد يخبرك بمتطلب دقيق لصاحب المحل، ولا بد من مراعاته في التصميم. قد يشترط صاحب النظام أن يرتبط كل مردود بفاتورة أصلية محددة من حيث الأصناف والكميات. معنى ذلك أنه في حالة رد بضاعة مباعة (مردود بيع) يجب أن يتم رد البضاعة على أساس فاتورة البيع التي تم فيها بيع هذه البضاعة بعينها. لا يمكن رد بضاعة لم يتم شراؤها في هذه فاتورة البيع هذه نفسها، ولا رد كميات أكبر من الكميات المباعة في نفس الفاتورة. في هذه الحالة، ستحتاج إلى تضمين حقل آخر اسمه مثلاً (الفاتورة المصدر)، يربط كل فاتورة مردود بفاتورة أصلية. هنا بضع ملحوظات:

1. ينبغي عليك كمبرمج أن تتأكد من أن فاتورة المردود تلتزم بأصناف وكميات الفاتورة المصدر.

2. هذا الحقل (الفاتورة المصدر) يحوي أرقام فواتير، وهي المفتاح الأساسي لجدول الفواتير، وعلى هذا فإن هذا الحقل هو مفتاح أجنبي (غريب وسط أهله!)، يربط جدول الفواتير بنفسه، ويسمى هذا self-relationship، علاقة ذاتية.

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

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

(في قيد الكتابة... يتبع بعد سويعات بإذن الله)...

ايوا ما معلم ابتداء الكلام الي افهمه هههههههههههه

بانتظار التكملة

ملاحظه هامة

الاول دايما ههههههههههههههه

(الجزء الثاني والأخير للحلقة رقم 27)

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

نقطتان إضافيتان عن الفواتير. أولاً، لماذا نجد أن البعض يصر على تضمين تفاصيل العميل من اسم وعنوان وهاتف في الفاتورة؟ هل هذا صحيح؟ في الغالب هذا ليس صحيحاً، لأنه تكرار لبيانات العميل الموجودة أصلاً في جدول العملاء، وقد سبق أن أفضنا في ذلك عند حديثنا عن التسوية. أقول (في الغالب) لأن هناك حالة خاصة قد يتوجب علينا فيها تضمين بعض تفاصيل العميل في الفاتورة، وبالذات ما يتعلق بالعنوان والهاتف، وربما أن البعض قد اطلع على هذا التصميم، وظن أنه التصميم العام الصحيح. هذه الحالة هي حالة الطلبيات التي سيتم توصيلها (شحنها) إلى أماكن مختلفة كل مرة، وليس إلى عنوان ثابت للعميل. تحتاج هنا إلى إضافة عنوان التوصيل لهذه الفاتورة في الفاتورة نفسها. مثلاً، تجد في قاعدة بيانات Northwind المرفقة مع الأكسس أن من بيانات الفاتورة (الطلبية order) بعض الحقول المتعلقة بمكان الشحن shipping.

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

رقم السند (راجع النقاش حول رقم الفاتورة من فضلك)

تاريخ السند

نوع السند (قبض/دفع)

العميل

المبلغ

البيان (وصف لتفاصيل الحركة)

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

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

1. من هنا سوف تقوم بتحديث رصيد الصنف عند كل الحركات، في حالة اخترت تضمين حقل الكمية المتوفرة في جدول الأصناف.

2. من هنا سوف تقوم بتحديث رصيد العملاء عند كل حركة بالآجل، في حالة اخترت تضمين حقل رصيد العميل في جدول العملاء.

3. ينبغي الانتباه عند تحديث رصيد الصنف إلى حقل وحدة القياس من أجل احتساب الكمية السليمة بالوحدة الأساسية. لاحظ أن ذلك قد يستلزم التحويل بين الوحدات حسب معامل التحويل في جدول الوحدات الفرعية.

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

ما سبق يقود إلى التصميم التالي لجدول الفواتير:

رقم الفاتورة (ربما اثنان حسب النقاش أعلاه في الجزء الأول)

تاريخ الفاتورة

طريقة الدفع (نقد/آجل)

رقم العميل

رقم العامل

نوع الفاتورة

الخصم الكلي

إجمالي الفاتورة

ملحوظة

لاحظ أن لدينا حقلين من جدولين لم نذكرهما حتى الآن، وهما جدولا العملاء والعاملون... أما جدول تفاصيل الفاتورة فيمكن أن يحوي التالي:

رقم الفاتورة

رقم الصنف

الكمية

سعر الوحدة

وحدة القياس

الخصم

تاريخ الصلاحية

جدول العملاء واضح جداً، ويحوي بيانات كل عميل. نحن نحتفظ ببيانات العميل الذي نتعامل معه بالآجل، أما عملاء التفرقة فمن الصعب، وغير المجدي، الاحتفاظ ببياناتهم. الحقول هنا من الممكن أن تكون:

رقم العميل

اسم العميل

نوع العميل

بلد

مدينة

عنوان

هاتف

جوال

رصيد

ملحوظة

الحقول التي قد تحتاج إلى تعليق هي:

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

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

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

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

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

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

(يتبع إن شاء الله)...

الأستاذ/أحمد .. مرحباً بك من جديد .. وعلى طول إن شاء الله.

وطبعاً مرحباً أيضاً بتوقيعك الجديد.

الأخ Slave ... طبعاً إنت قاعد تقرأ الآن .. وهترد كالعادة بشوية كلام جامد قوى .. أنا شايفك أهه

منتظرك.

الأخ السباق دائماً محمد المسيفرى

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

أروح أقرا وأرجع لكوا تانى.

تحياتى

محمد ندا

السلام عليكم ورحمة الله وبركاته

انا لما دخلت النهاردة الصبح مالقيتش الحلقة بتاعة الأسبوع نزلت ، قلت بس الرجالة كلها هتدعى عليا :)

ما شاء الله عليك يا أستاذنا الخـطير (بلاش الخبير عشان مابتعجبكش)

انا قرأت الجزأين قراءة الطائر (إيه رأيك .. أنا لسة فاكر)

بس ليا ملاحظة عامة وحضرتك كررتها كثير فى المناقشة

وهو موضوع توفير عدد الجداول

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

يعنى مثلا:

لماذا لا نقوم بعمل جدولين مختلفين للفواتير

أحدهما لفواتير الشراء (لما يستتبعه من مسائل الموردين كالشحن والاعتمادات و...)

والآخر لفواتير البيع

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

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

جزاكم الله خيرا

وأعود للقراءة (طائر برضه بس طائر البطريق) ( مش مشكلة المهم طائر وخلاص )

أخوكم

slave

وعليكم السلام ورحمة الله وبركاته...

ممتاز أخي slave، نحن نريد مشاركات من هذا النوع...

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

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

هناك من ضمن مفاهيم مخطط الكائنات والعلاقات التي تمت إضافتها إلى النموذج الأصلي extended features ما يسمى بالتخصيص (ومثله التعميم) specialization و generalization ، ويعني أن نجد كائناً واحداً يمكن فصله إلى عدة كائنات عبر عملية تخصيص specialization أو يمكن أن تفكر بالعكس، وهو أن تجد عدة كائنات يمكن جمعها عبر عملية تعميم بالاستفادة من الخصائص المشتركة... بغض النظر عن أي طريقة تتبع، الناتج عند التحويل إلى جداول هو أكثر من جدول، بحيث يحوي جدول الخصائص المشتركة، وتنفرد الجداول الأخرى بالخصائص المختلفة، أو يمكن أن يحوي كل جدول الخصائص المشتركة بالإضافة إلى الخصائص التي ينفرد بها...

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

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

لكن لماذا كان دمج الجداول في الحالة الأولى أفضل؟ هذا يقودنا إلى

اقتباس

القاعدة بصفة عامة توفير عدد الجداول

ربما أطيل قليلاً، فأرجو المعذرة، لكن الأمر يستحق...

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

لكن السؤال هاهنا: هل هذا اللجوء هو هدف بحد ذاته أم طريقة نضطر إليها لسبب ما؟ ما لاينبغي أن ننساه هو أن هناك دوماً ثمناً ندفعه لـ(فرّق) هذه. هذا الثمن له تسمية عامة overhead. المثال المناسب هنا هو تقسيم المشكلة الواحدة إلى عدة أجزاء، وبناء برنامج يحل كل جزء، ثم استخدام هذه البرامج معاً، وذلك باستدعاء هذه البرامج من برنامج واحد لحل المشكلة الكبيرة. هذه هي فكرة structured programming، ومن هنا نجد مفهوم ال subroutine أو subprogram أو البرنامج الفرعي أو الدالة والإجراء. لكن لا تنس أنه بالرغم من الفوائد الجليلة لهذه الفكرة (ليس هنا موضع عدها)، إلا أن تنفيذ برنامج واحد أسرع وأقل استهلاكاً للذاكرة من تنفيذ عدد من البرامج الصغيرة. السبب هو أن هناك وقتاً يضيع عند كل استدعاء لبرنامج فرعي، وعملية الـ context switch والمتغيرات المحلية. لا أريد أن أضخم الموضوع، لكن القصد أنه لو لم تكن هناك حاجة حقيقية لهذا الأسلوب، فإن الأفضل تركه (لكن هناك حاجة حقيقية لذلك).

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

تعقيد العبارات

بطء التنفيذ

العرضة للأخطاء

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

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

هذا رأيي في الموضوع، وأرجو عدم التردد في الاعتراض في حالة عدم الاقتناع، كما أن أي آراء أخرى هي موضع الترحيب...

أشكرك مرة أخرى على الملحوظة الجيدة... أخوك أحمد

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

أننى أحاول ألا أنهى نقطة دون فهمها ووضع التساؤلات التى تأتى على بالى حتى لا تضيع من رأسى بسبب عدم خبرتى بالمخازن (ليست فنية ولكن منطقية) فحدث معى أن كتبت السؤال التالى:

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

وجاءت الإجابة فى الفقرة التالية مباشرةً لتلك الفقرة

اقتباس

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

.. ولذلك سأحاول ألا أسأل إلا فى النهاية .. بس يارب أفضل فاكر.

مش قادر أصبر على السؤال ده:

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

ووجدت الإجابة على التساؤل فى فقرة تالية أيضاً.

أما السؤال التالى .. فلم يثيرة حتى الآن آخر .. الحمد لله علشان ألاقى حاجة أعملها بدلاً من أن أيقى مدير عطلان كدة.

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

تحياتى

محمد ندا

بالطبع مديرنا الفاضل، لا بد من حقلي الفاكس والبريد الإلكتروني (هذه الأيام، مع موقع الوب أيضاً)... لكنهما سقطا سهواً :)... ألم أقل أنني (كلاسيكي دقّة قديمة؟ :))...

بالمناسبة، أنت تبقى مديراً، حتى لو كان الشيء الوحيد الذي تفعله هو طلب الكابتشينو...:)..

لو كانت كل الدقة القديمة هكذا روعة .. مثلك .. فنحن من أنصار الدقة القديمة إلى النهاية.

بس أنا شايف Slave الآن يطالع السلسلة معى .. يارب ما يفهمش الدقة غلط .. ما أنا عارف ألاعيبه.

تحياتى

انا موجود معاك واحاول استوعب الافكار هذي ما يهمكم انتوا كملوا وانا معاكم هههههههههههههههه

السلام عليكــم ورحمـة الله وبركاتــه ،،

طبتم وطاب مسعاكم وممشاكم وتبوأتم من الجنة مقعداً

ما شاء الله لقد فوجئت بروعة الطرح ودسامة المحتوى واعذروني على عدم متابعتي منذ البداية

اسمحوا لي أن ألتقط طرف الخيط واتحدث عن مسألة "توفير عدد الجداول"

أنا أؤيد هذا الإتجاه شريطة عدم تباين أو اختلاف البيانات لما في ذلك من :

1 - حفاظ على مساحة قاعدة البيانات (المحدودة أصلاً)

2 - سهولة استخراج النتائج والحسابات دون اللجوء الى تعقيدات أو انشاء علاقات لا داعي لها (مما يضخم بدوره مساحة القاعدة)

وببساطة شديدة بدلاً من جدول فواتير شراء واخر لفواتير البيع ليكن جدول واحد مع وجود حقل لنوع الفاتورة

فقط أكرر شرط عدم التباين في نوعية البيانات في الحالتين

هل سيتحقق هذا الشرط في حالة فواتير البيع/فواتير الشراء ؟؟؟

وعليكم السلام ورحمة الله وبركاته...

اسمح لي أستاذ إيهاب أن أكون أول من يرحب بك، وإننا لنتشرف بمشاركاتك التي -كما ربما لاحظت من تفاعل الإخوان- نفتقدها بشدة... وجود رجل من وزن الأستاذ إيهاب مكسب حقيقي للسلسلة...

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

شكراً جزيلاً على المشاركة، وأرجو (باسم جميع الإخوة هنا) أن تستمر إطلالاتك علينا...

بارك الله فيك استاذنا الكريم "أحمد" وأرجو ألا أكون ضيفاً ثقيلاً :D

مرحباً بك أخ سامح وبارك الله فيك..

بداية لنتفق أن الاجابات لا تتصف في الغالب ب (صحيح / خطأ) فمن الممكن الوصول للحل بأكثر من طريقة غير أننا نبحث عن الأدق ..

بالنسبة لسؤالك..

فلا داعي أبداً للفصل بين النوعين وذلك لعدة أسباب :

1 - لقد ارتضينا الدمج بين فواتير العملاء والموردين (البيع والشراء) فليس من المنطقي الفصل بين نوعين من فواتير العملاء

2 - الاختلاف في حالتنا هنا لا يتعلق بذات الفواتير انما هو أمر متعلق بفئة العميل وطريقة التعامل معه

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

(فواتير شراء - فواتير بيع للفئة أ - فواتير بيع للفئة ب)

أو الاستعلام عن الفواتير ذات الخصم والضريبة صفر أو ذات الخصم والضريبة > صفر على اعتبار أن الخصم والضريبة حقلان في جدول الفواتير

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

======

طبتم واهتديتم

أخي الكريم...

اقتراحي بتقسيم العملاء الى فئات ومن ثم تفعيل/تعطيل مربعي النص المرتبطين بحقلي الضريبة والخصم كان ذلك من باب

اقتباس

مزيد من التسهيل في عملية الإدخال وتقليل احتمالات الخطأ

أما ان كان الواقع هو خضوع نفس العميل لأحد النظامين فالأمر سهل املأ أو اترك حقلي الضريبة والخصم بحسب الحالة

وبخصوص التكرار فهو ممكن ويمكن التمييز بين النوعين برمز معين

وان كنت لا أرى أبداً صحة هذه العملية (تكرار المسلسل) من جميع الجهات

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

ليسمح لى أستاذنا أحمد مبارك أن أخصص هذه المشاركة للترحيب برجل يستحق الترحاب:

(1) قالها الأستاذ وصاحب السلسلة

اقتباس

اسمح لي أستاذ إيهاب أن أكون أول من يرحب بك، وإننا لنتشرف بمشاركاتك

(2) من أخينا سامح

اقتباس

إسمح لى أستاذنا أحمد أن أرحب بمشرفنا الغالى إيهاب ...مرحبا بك...ونأمل ألا نفتقدك هنا معنا

(3)

اقتباس

بارك الله فيك استاذنا الكريم "أحمد" وأرجو ألا أكون ضيفاً ثقيلا

(4)

اقتباس

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

(5) دورى الآن:

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

كما أنك أكيد لاحظت ما أثار تواجدك من زيادة التفاعل داخل السلسلة.

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

تحية متواضعة

محمد ندا

إسمح لى أستاذنا أحمد أن أرحب بمشرفنا الغالى إيهاب ...مرحبا بك...ونأمل ألا نفتقدك هنا معنا

الله يعطيك العافية على هذه الحقلة الجديدة

وما تحتويه من حلول وافكار ومقترحات لبعض الجداول والمشاكل

واعتذر منك بإستطراء نقطة ربما ليست من محور النقاش في الوقت الحالي

ولا كن وأنا اقراء هذه الحلقة هي ما دعتني اطرحها

إلا وهي الاكواد

والعنوان يقول نوفر الجداول ونستخدام الأكود

إن لم اكن مخطئ في ما تقصد

إلا تجزم معي انه ربما يكون هناك برنامجين متشابهين في الأداء ولأكن مختلفان في الحجم على القرص الصلب !!!

اليس هذا يعود إلى بنيت الأكواد و أوامر الإجراءات المخزنة .

ووفقكم الله إلى ما يحب ويرضى

ودمت بخير وصحة وسلام

السلام عليكــم ورحمـة الله وبركاتــه ،،

مرحباً اخوتي الكرام واشكركم جميعا على هذا الترحيب وان كنتم مبالغين في منحي صفات لا استحقها..

بارك الله فيكم..

=======

أخي sandm

توفير الجداول / الاستعلامات من البديهي أن يكون مع مراعاة الاداء وعدم الاقلال من المستوى

هذه واحدة

كذلك يجب عدم اللجوء للأكواد المعقدة والحلول الملتفة فهذا أيضاً مما يؤدي الى تضخيم القاعدة كما أن الاسراف في عدد الجداول والاستعلامات يؤدي الى نفس المأساة

وأخيراً..

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