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

مرحباً أخى Slave وأهلاً وسهلاً.

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

تحياتى

محمد ندا

....

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

خمسة أيام لم نسمع منك ... كيفك .. كنا قد تلقينا منك وعد بألا تغيب عنا كثيراً.

فى انتظار تحيتك لنا.

تحياتى

محمد ندا

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

أخى ووويييييييينك لعلك تكون بخير إن شاء الله

ما نريده هو الإطمئنان :unsure:

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

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

ملحوظة 1: لا أستطيع كتابة حلقة جديدة الليلة بسبب الانشغال، لكن أحببت توثيق الحضور...

ملحوظة 2: الأخ المدير محمد ندا... لست أستاذاً، وإنما أخ قد يفيد ويستفيد...

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

أشكركم جداً على السؤال وأطلب عفوكم...

أخوكم أحمد

....

مرحباً بك أستاذنا أحمد ...

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

والحمد لله أنك بخير .. ونحن فى الانتظار غير عاجلين ولا مستعجلين ,,

تحياتى لشخصكم الكريم والأخوة الكرام الحضور

محمد ندا

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

الحمد لله رب العالمين كونك بخير أخى :thumb_up: ( وقد تم مانريده منك وهو الإطمئنان .. جزاك لله خيرا ونفع الله بعلمك ومتعك الله بصحتك ووقتك إن شاء الله أخى )

فى إنتظارك أستاذنا الفاضل

ألف حمدا لله انك بخير يا استاذنا :rose:

الأخوة الكرام

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

وقد أردت أن أطمئنكم عليه لمن لا يتابع الموضوعات الأخرى بالمنتدى.

تحياتى

محمد ندا

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

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

كنت أقترح أن يتم تحديد موعد أسبوعى ثابت للحلقة (أو إذا سمح وقتك موعدين) .. نترك باقى الأسبوع للنقاش حول الحلقة ومشاركات الأخوة.

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

وهنا الترتيب يفيد فى التالى:

1. سيعرف الجميع أن يوم كذا هناك حلقة جديدة.

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

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

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

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

تحياتى

محمد ندا

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

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

...

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

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

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

1. تكامل كيان entity integrity

2. تكامل مجال domain integrity

3. تكامل مرجعي referential integrity

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

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

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

كما أشرت في فقرة سابقة، تسمى الشروط التي تفرضها من أجل الحفاظ على تكامل قاعدة البيانات (قيود التكامل integrity constraints)، لأنها تقيد الإدخال، وتمنع بعض التصرفات غير المرغوبة. هناك نوع آخر من القيود يسمى قواعد العمل business rules، لا تتعلق مباشرة بالمفاتيح الأساسية والأجنبية، وإن كان يمكن اعتبار قيود المجال جزءاً منها أحياناً. القيود السابقة قيود عامة تتفق في كل قواعد البيانات، لكن هناك متطلبات خاصة بكل قاعدة بيانات تفرضها حاجة العمل وسياسة المستخدم، ولذلك تسمى قواعد العمل. مثلاً، كم عدد المواد الممكن أن يحملها الطالب معه إلى المستوى الأعلى دون أن يفصل؟ ما هو الحد الأقصى لعدد التفاصيل في الفاتورة الواحدة؟ هل يمكن لموظف في إجازة أن يكلف بمهمة؟ وهكذا. من الواضح طبعاً أن قواعد العمل من اختصاص التطبيق، وتبرمج خارج قاعدة البيانات، وإن كان يمكن حسب نوع المنتج المستخدم دمج منطق قواعد العمل في قاعدة البيانات من خلال كائنات خاصة (مثلاً، قادحات الجداول table triggers في أوراكل). منطق قواعد العمل هو جزء التطبيق الذي يتناول فرض هذه القيود، وفي الأنظمة متعددة الطبقات (لو تذكر نقاشنا عن multi-layer architecture في أوائل الحلقات) ربما توضع في الطبقة الثانية مثلاً.

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

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

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

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

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

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

أشكر لك جداً كلماتك الرقيقة ...

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

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

إسمح لى الآن أن أعود وأتم قراءة الحلقة.

تحياتى

محمد ندا

أستاذنا أحمد

مرحباً بك ثم بالحلقة رقم (22)

وبعد الشكر على الحلقة

اقتباس

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

هذا فعلاً ما كنت أنوى السؤال عنه قبل قراءاته وبمجرد أن وجدت التكامل هو الموضوع الرئيسى للحلقة .. ولكنك أجبت السؤال قبل أن يُسأل .. ففى قاعدة بيانات الموظفين مثلاً .. لا يعقل أن يتم حذف عدد من الموظفين من قاعدة البيانات لمجرد أن القسم الذى يعملون به تم إلغاؤه .. فما الحل فى هذه الحالة ..

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

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

نشكر لك مرة أخرى الحلقة الرائعة

تحياتى

محمد ندا

الأخ العزيز والمدير القدير محمد ندا...

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

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

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

مرحباً بك، وشكراً للتفاعل المستمر...

أخوك أحمد

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

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

أخجل أونا عربى أن أضع التعليق التالى .. وخاصة النقطة رقم 2 منه:

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

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

2. بعض قرائك وأنا منهم للأسف أفهم كل ما يتعلق بالحاسوب (وعلى فكرة أول مرة أكتب كلمة حاسوب أو ربما ثانى مرة فى حياتى) .. أفهم ما يتعلق بالكمبيوتر أكثر باللغة الإنجليزية عدا البعض القليل جداً من ملفات المساعدة.

3. تضم إلى حسناتك المتعددة حسنة جديدة وهى أن يكتسب من يتعامل باللغة العربية مصطلحات جديدة بالإنجليزية مما يثرى (أكثر وأكثر) المعلومات لدينا.

ثم أما بعد،،،

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

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

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

تحياتى

محمد ندا

.....

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

تحياتى

محمد ندا

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

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

وفي كل مره اقراء الحلقات احس اني توني اتعلم الاكسيس

ثانيا مديرنا محمد ندى اقتراحاتك جميلة ورائعة وفي محلها

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

وهذي ايميلي

thedark_2010@hotmail.com

بارك الله فيك أستاذنا مشارف

وأتمنى أن يعيننى الله لأكون عند حسن ظنكم.

تمت الإضافة

تحياتى

محمد ندا

الإخوة الكرام... تمهيداً للحلقة القادمة عن مخططات الكائنات والعلاقات Entity-Relationship Diagram أو اختصاراُ ERD، أرجو المشاركة بالرد على هذا السؤال:

هل تعرف ERD؟

إن كان كذلك، ما هو مفهومك عنه؟

في انتظار المشاركة لمن تيسر له... أسأل الله أن يفتح علينا جميعاً...

مرحباً الأستاذ/أحمد وعوداً جديداً بشكل جديد

ماشى يا عم أحمد .. إنت كده عايز تكشفنا بدرى بدرى

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

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

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

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

تحياتى

محمد ندا

اقتباس

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

أخى الكريم Same7

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

بالإضافة إلى مشاركاته الأخرى فى المنتديات .. وأنا أتابع معظمها إن لم يكن كلها.

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

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

تحياتى

محمد ندا

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

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

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

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

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

1- الجداول لخزن البيانات

2- الاستعلامات لعمل العمليات الحسابية والفرز والاحصائيات بنائا على الجداول

3- النماذج لادخال البيانات في الجداول

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

اي برنامج يعتمد على المخرجات والمدخلات ومنها ما يهم العميل واهوا كيف سوف تخرج له البيانات وسهولة الاخراج

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

وان شاء الله اكون ما اثقلت عليكم هههههههههههه هذي اذا صح الي قلته

ثانيا بخصوص اخوي Same7 فانا معه في اقتراحه

ومقدر انشغال استاذنا احمد

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

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

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

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

وهذي فايدة الموضوع اصلا انه تتعلم من اخطائنا

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