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

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

اقتباس

أتمنى أكون قربة من الحل مع انه العلاقات مو واضحة عندي بشكل كامل

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

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

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

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

طبعاً انا أقصد الأخ slave في بداية الرد، لكن أضفت المشاركة بعد تعليق الأخ سامح...

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

الآن بعض التعليق على إجابة أخينا slave الذي عرفنا على الأقل أنه يرتدي نظارة...

اقتباس

أدد (يمكن يقصد أول دكان دندرمة )

add عادة يستخدم كاختصار للعنوان (address)، ويعني هنا تفاصيل العنوان غير المدينة والرمز البريدي.. إلخ...

اقتباس

كائن المتر: (يمكن يقصد شريحة محاسبة العميل)

هذا هو العداد meter ومن خصائصه الرقم والنوع (وربما المصنّع)، وكذلك الفيز phase الذي أؤكد أنه لا علاقة له بأي كائن أرضي يشبه العم سيد...

اقتباس

الشكل العام للجدول يقول انه علاقة بين كائنات مختلفة

ويساعد على ترسيخ هذا الرأى أن الكائنات كلها لها نفس الشكل المستطيل

ملاحظة جيدة، وهي بالفعل علاقة هاهنا...

اقتباس

والتاريخ واخد نفس الشكل المستطيل وله خصائص وله مفتاح أساسى فى خصائصه.

أي تاريخ؟ هذا هو الشهر... وهو كائن كما تفضلت...

اقتباس

كائن أعلى الفنجان:

-- القراءة

(-- الشهر و -- العميل ) لو غلط انا حاططهم بين قوسين

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

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

إذا أردتم المزيد من التوضيح عن فكرة المثال فمن الممكن أن أوضح قليلاً شيئاً من تحليل النظام...

أسأل الله التوفيق والسداد...

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

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

اقتباس

وإن كنت غاضباً فحقك علينا

والله يا جماعة لا اقصد ان أظهر غضب أو تذمر

دا انا بس حبيت أنكش الرجالة

اقتباس

ربما كان يجدر التجاوب أولاً بأول

ولم أقصد ذلك أيضا يا أستاذنا وكان الله فى عونك

كفاية ان انت مستحملنا - او مستحملنى على الأقل-

سأقوم بقراءة المشاركات الآن ولكن أحببت أن ألقى البيان السابق قبل ذلك :)

جزاك الله عنا خير الجزاء

أخوك ابو نظارة

slave

الأساتذة الكرام والأخوة الأحباب

قرأت الحلقة .. وقرأت ما تلاها من تعقيبات وتعليقات ..

اقتباس

(مثلاً، محمد ندا على ما عرف عنه من متابعة، لم تتسن له الفرصة بعد لطرح رأيه)

لديك كل الحق .. ولكن والله لا أملك الوقت للتعقيب أو عمل (الواجب) .. :thumb_down: أرجوك لا تقيلنى.

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

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

فأسألكم المعذرة ... :rose:

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

وخاصة أخونا المشاكس أبو نظارة والسؤال التالى له .. مين القمر اللى منور على يمين مشاركاتك؟ طبعاً تملك حق الرد بأى طريقة تحب من أول الصمت الرهيب إلى "وانت مالك يا حشرى".

محمد ندا

:resentful:

:P

:D :D :D

طبعا المشاركة اللى فاتت دى للمدير بتاعنا

وده تمرين على المخطط الهيكلى للكائنات الطفولية

child

طبعا ماحدش فاهم حاجة

ماانتو لو بتذاكروا ...

اقروا آخر تعليق للمدير

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

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

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

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

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

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

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

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

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

هنا ملحوظتان:

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

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

على ذكر العلاقات، دعوننا نرى الآن العلاقة بين الفواتير والأصناف في مخطط ERD، وهو مثال مألوف لنا جميعاً على ما أظن...

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

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

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

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

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

اقتباس

Strong and weak entity set

Total and partial participation

Roles

Cardinality limits

Non-binary relationship sets

Extended features (specialization, generalization, aggregation)

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

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

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

أستاذنا الكريم أحمد مبارك الحيقى

مرحباً بك مرة أخرى .. وثم ... بالحلقة (24) ..

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

تحياتى

وأراكم قريباً بإذن الله.

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

أخوكم

محمد ندا

ايه يا رجالة

انا مستنى حد يخش يجاوب

هو مافيش غيرى فى الفصل (عشان كدة باطلع الأول) :)

انا باحذركم

لو مالقيتش اجابة هانزل بالحل

السلام عليكم جميعا

وأحب اشكرك اخي أحمد على حسن الطرح والإطراء لمثل هذه المواضيع المفيدة

وللاسف الشديد أني بدأت متأخر في قراءة هذه السلسة ولا زلت في الصفحة الـ 5 الحلقة الـ 15

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

ولا يسعني الآن إلا ان اكرر شكري لك والدعاء لك

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

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

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

اولا اشكر استاذي احمد على الدرس الجميل وابنتظار الدرس القادم بفارغ الصبر

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

ممممممممممممم لكن شكل الشباب ينتظرون اجابتي انزين

هذي المخطط شكل ما اعتقد انه صحيح والتصحيح على الاستاذ الله يعينه بس لا تنسى الدرجات ها اهم شي

ويا الله يا شباب همتكم اشفوكم تراخيتوا اشويه

علما انه فهمي في برنامج المخازن اشويه ما اشتغلت عليه انا مثل مديرنا محمد ندى مختص شؤون ادارية

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

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

1. ينبغي الدلالة على العلاقة بشكلها المحدد (ليس مجرد خط بين كائنين، هناك شكل المعين للعلاقة).

2. ينبغي الدلالة على نوع العلاقة (برؤوس الأسهم للواحد أو غيرها من الاصطلاحات).

3. إذا كان المهم من بطاقة الائتمان هو فقط الرقم، فإن هذه ليست خاصية مركبة بل مفردة، لذلك لا داعي لاستخدام طريقة الخاصية المركبة.

4. ينقص السندات، وإضافة الموظف إضافة ممتازة.

وها هو ذا المخطط كاملاً مع اختصار الخصائص من أجل المساحة...

أشكرك على التفاعل الجيد، ونعذر البقية لأننا كلنا نعاني من الانشغال الشديد أحياناً...

أيضاً لا أنسى الترحيب بالأخ sandm، جزاك الله خيراً على الدعاء وأثابك بمثله، وفي انتظار مشاركتك...

مشكور استاذي احمد على الملاحظات

بس عندي تسائل بخصوص العلاقة عن طريق المعين

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

ثانيا بخصوص الاسهم لاحظت الاسهم فقط بين كائن العملاء والعمال لكن لايوجد سهم بين كائن الفاتورة والصنف

واسف على التسائل بس علشان الفكرة توضح لي بشكل افضل

بخصوص كائن السندات ما المقصود بالسند هنا هل هو سند القبض للعميل او حساب العميل عند الشركة مثلا او ماذا واذا كان كذلك يعني العلاقة راح اتكون

واحد الى واحد يعني لا معنى لفصل السند عن العميل ليكون كائن منفرد لانه كل سند راح يكون له عميل واحد وكل عميل راح يكون عنده سند واحد

صح ولا انا فهمت موضوع السند هنا خطاء

واسف على الاطالة

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

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

اقتباس

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

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

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

اقتباس

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

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

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

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

اقتباس

ثانيا بخصوص الاسهم لاحظت الاسهم فقط بين كائن العملاء والعمال لكن لايوجد سهم بين كائن الفاتورة والصنف

أجيبك عن هذا من الحلقة السابقة:

اقتباس

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

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

اقتباس

بخصوص كائن السندات ما المقصود بالسند هنا هل هو سند القبض للعميل او حساب العميل عند الشركة مثلا او ماذا واذا كان كذلك يعني العلاقة راح اتكون

واحد الى واحد يعني لا معنى لفصل السند عن العميل ليكون كائن منفرد لانه كل سند راح يكون له عميل واحد وكل عميل راح يكون عنده سند واحد

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

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

وهكذا ترى أننا وصلنا في آخر مخطط إلى تمثيل كاف وعملي نظام مخازن ومبيعات، مع ملاحظة الخصائص التالية:

1. نوع العميل قد يكون زبون أو مورد أو كلاهما.

2. نوع الفاتورة قد يكون بيع أو شراء أو مرتجع (مردود) بيع أو مرتجع (مردود) شراء.

3. نوع السند قد يكون سند قبض أو سند دفع.

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

مشكور استاذي على التوضيح وفعلا ما اخذت بالي بخصوص نوع الخط الان واضح

وانه العلاقة ممكن تتحول الى جدول ان كان متعدد الى متعدد الان واضح

بخصوص السندات فهمت عليك بس ان شاء الله في التطبيق راح يتضح اشلون عمل ذلك لانه كل نظم المخازن الي شفتها لم اجد فيها نضام سندات علشان

جذيه كان غريب علي الاسم

وبخصوص الزبون ان يكون زبون وفي نفس الوقت مورد هذي المشكله طرحت من قبل وان شاء الله اشوف حل لها في متابعتنا للدروس معاك

وبخصوص المرتجع لم اجد في النظم الي شفتها بعد نظام استرجاع او كان فيه وانا ما اخذت بالي منه

بخصوص العمل على نظام المخازن شكله راح يكون شي مشوق بسبب هذي الاضافات الي ما مرت علي من قبل

1- نظام الاسترجاع او التبديل

2- نظام السندات

3- الزبون والمورد في نفس الوقت

شكلنا راح نطلع على بناء نظام مخازن بشكل كامل دون توفويت شي ان شاء الله

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

بنتظار الدرس القادم بفارغ الصبر

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

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

ان شاء الله يرجع بالسلامة

الغايب عذره معه وان شاء الله ما نبتدي الدرس القادم الى ويكون موجود ان شاء الله

ومعاه اخوه المشاغب او SLAVE

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

واسعد الله يومكم واوقاتكم

الحمد لله اني انتهيت من قراءة الحلقات السابقة

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

لأن الغير مرسوخ اكثر من الراسخ ( المفهوم )

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

ولا يخفى عليك الأمر

ان هذه السلسلة والحلقات سوف تظل مرجع لي ولي غيري من رواد هذا الصرح الشامخ وان شاء الله تدوم ويدوم لتعم الفائدة

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

وسوف اقوم بتنسيقة مع مرور والوقت ليكون مرجع مع حفظ الحقوق للمرجع وللكاتب(أحمد مبارك الحيقي)

ولكي لا ننسى الشكر لك والدعاء في الأجل وبظهر الغيب والقائمين على هذا المنتدى

وكما قال اخي الفاضل مشارف

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

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

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

إخوانى الكرام .. أساتذتى الكرام

لا تسعنى كلمات الشكر لشكركم على سؤالكم عنى .. لعلى أستحق سؤالكم .. ولكن وكرمكم هذا يزيد عما استحق.

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

والله افتقدكم كثيراً ..

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

وأخى محمد المسيفرى (مشارف) على سؤاله وعلى رسالته الطيبة.

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

تحياتى لكم جميعاً ...

أخوكم

محمد ندا

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

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

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

إنشاء مخطط الكائنات والعلاقات يختبر فهمك الحقيقي للنظام. نقطة.

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

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

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

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

O الكائنات تصبح جداول.

O الخصائص المفردة تصبح حقولاً.

O كل جزء من الخصائص المركبة يتحول إلى حقل مستقل.

O الخصائص المشتقة يمكن الاستغناء عنها (راجع النقاش في الحلقة السابقة).

O الخاصية متعددة القيم تتحول إلى جدول مستقل مع إضافة حقل المفتاح الأساسي في الجدول الأصلي كمفتاح أجنبي.

O العلاقات تحتاج إلى تفصيل:

= العلاقات متعدد إلى متعدد تتحول إلى جدول مفتاحه هو مجموع مفتاحي الكائنين الذين تربط بينهما.

= العلاقات واحد إلى واحد تختفي ويتم دمج الكائنين الذين تربط بينهما في جدول واحد.

= إذا لم يتم دمج الجدولين تمثل العلاقة بتضمين المفتاح الأساسي لجدول في الجدول الآخر كمفتاح أجنبي.

= العلاقات واحد إلى متعدد غالباً ما تختفي وتمثل بتضمين مفتاح جهة الواحد في جدول جهة المتعدد كمفتاح أجنبي.

دعونا الآن نطبق هذا الكلام على المثال المألوف:

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

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

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

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

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

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

ملحوظة:

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

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

الموضوع بدا يوضح اكثر ولو انه دخلت في مسائلة الاجمالي المحسوب في الفاتورة

بس ان شاء الله عند التطبيق راح يوضح هذي الشي

والحين التفكير في مسائلة المخزون في الرصيد الافتتاحي هل يكون الرصيد المفروض توافره او الرصيد المقترح عند انشاء الجداول لانه راح تترتب عليه

اشياء كثيرة او هية الكمية المتوفرة حال فتح استخدام النظام وعندها ممكن انغير عليها فيما بعد

قد تستغرب السؤال بس لانه ما عندي خلفية عن نظام المخازن هل كل سنه يكون له رصيد خاص فيه

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

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

وموضوع انتهاء الصلاحية

وموضوع المسترجع او التبديل نفس القيمة هذي موضوع

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

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

ههههههههههه اسائله وايد اسمحلي بس هذي اسائلة ادور في بالي ويكن راح تطرح اسائلة ثانية كل ما استجد شي

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

يعني نوع العميل ممكن مورد او عميل بس اشلون الاثنين معا

سؤال اخير هل نبداء بانشاء الجدوال الان

الله يعينك علي هههههههههههههه

الله يعطيك العافية يا استاذنا الغالي على الحلقة الجميلة والدسمة

اقتباس

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

بالنسبة للخصم أو اختلاف الاسعار

ممكن تكون هذه عن طريق إضافة حقل جديد في جدول الاصناف ويأخذ اسم ( الخصم Discount )

وانا قلت كذا علشان ما يكون الخصم كامل على الفاتورة فقط يكون على الاصناف أو الأنواع المراد الخصم عليها .

والباقي على المبرمج في العمليات الحسابية(الأكواد) :rolleyes:

أما الشق الثاني

اقتباس

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

هذه تدخل في شقين

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

أو الإغتناء عن الحقل بوضع شرط اثناء البرمجة لأختيار نوع البيع قبل إدخال بيانات الفاتورة

ثانيا إضافة حقل جديد في جدول الاصناف ويكون لأسعار الجملة فقط

عند اختيار مفرد في تفاصيل الفاتورة يجلب لنا الاسعار من جدول الاصناف فقط للمفرد

والعكس كذلك للجملة

وتصبح حقول جدول الأصناف

(رقم الصنف + اسم الصنف + رقم الرف + السعر فردي + السعر جملة + الخصم )

اتمنى تكون إجابتي على سؤالك صحيحة او فيها شي من الصحة وتكون ضمن شروط التسوية

وبإنتظار التعقيب من اخونا واستاذنا الغالي احمد

وانا اسئل لو اردنا إضافة حقول على تفاصيل الفاتورة وهي

المدفوع

الباقي

اليست هذه حقول محسوبة و هل يلزم تخزينها

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

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

ما رأيكم...؟

اقتباس

ولست أدري عن ضيفنا الجديد sandm جزاه الله خيراً...

واياك ان شاء الله واخواننا الغالين

اما عني انا احب الإطلاع والقراءة قبل التطبيق

سواء كان نظام مخازن او اي نظام آخر لأنه لا يخفى عليكم ما سوف نتعلمه ونستفيده من هذا النظام

سوف يخدمنا في غيره من الانظمة والمشاريع

وايضا لأنه من هواياتي تعلم البرمجة

وهذا سوف يزيدنا علما وخبرة بتباع طريقة الممارسة

فإلى الأمام يا ستاذنا الغالي احمد

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

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

على بركة الله استاذي احمد احنا كلنا اذن صاغية

والله يعينك على الموضوع طلع مو شي بصيط كانك اتالف لكتاب

وبخصوص السلسلة لاستاذنا محمد فؤاد تركي ما عندي خلفية عنه هل لا اطلعتنا على الرابط حتى اتابع هذي الدروس انا احب ادور كل درس عن مواضيع

البرمجة وقواعد البيانات بشكل خاص

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

الجاهزة لانها ما اتلبي متطلبات كل عميل بس اعتقد انه مثل هذي البرامج فيها من الامكانيات الي اتخلي هذي المحلات تشتريها

وكنت اتمنى انه اشوف طريقة عمل برامج مثلها بالطريقة الاحترافية

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

واتمنى تعلم برامج بالحجم الكبير وان شاء الله مثل هذي الدروس راح اتقودنا واتخلينا في اول الطريق الصحيح لتصميم البرامج لانه الاساس واحد في كل

البرامج شكل ما اعتقد والله المستعان