El Sayed El Tohamy

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

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

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

أهنئك على اجتهادك ومحاولاتك، وكلها صحيحة بفضل الله مع بعض الملاحظات البسيطة. الاستعلام الأول والثاني سليم تمامًا لا ملاحظات عليه الاستعلام الثالث بالفعل يعرض المنتجات على حسب أفضلية المبيعات، إلا إنه يعرض جميع المنتجات في حين نحن نريد عرض أول خمس منتجات فقط لذلك هناك إضافة بسيطة جدًا وهي limit 5 بآخر الاستعلام select product_name, quantity, price, (quantity*price) as total_price from master..Products, orders where Products.product_id = orders.product_id order by quantity desc limit 5 الاستعلام صحيح مائة بالمائة. أما بخصوص الاستعلام الرابع نحن نريد استخراج السنة والشهر من التاريخ، لأنه سيتم التجميع بناء عليهم وليس على التاريخ كله SELECT YEAR(order_date) AS SalesYear, MONTH(order_date) AS SalesMonth, SUM(Price) AS TotalSales FROM Sales GROUP BY YEAR(order_date), MONTH(order_date) ORDER BY YEAR(order_date), MONTH(order_date)

تسلسل الخطوات مضبوط، أحييك على تفكيرك المنطقي، ولكن يوجد خطأ بسيط وهو في الجملة الشرطية حيث يجب إزالة علامة = وذلك لأننا لا نريد استبعاد الصفر حيث أن مضروب الصفر يساوي 1 ليصير الأمر if (n < 0) وكذلك نقل أمر الطباعة خارج الحلقة التكرارية، لأننا نريد طباعة الناتج النهائي وليس الناتج بعد كل عملية ضرب، بالإضافة إلى أنه لن يتم الطباعة في حال n = 0 for (int i = 1; i <= n; i++) { sum = sum * i; } Console.WriteLine(sum);

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

هذا السؤال هام لأقصى درجة، فمن خلال التصميم يتم تحديد صلاحيات المستخدمين والتحكم بها، وفي الواقع إجابة هذا السؤال تحتاج إلى مجلدات حيث أن الموضوع لا يقتصر على تصميم قواعد البيانات فحسب، وإنما أيضًا معرفة تامة بالصلاحيات واختياراتها وما الاختيار الافتراضي وأشياء كثيرة تخص استيثاق المستخدمين Authentication وصلاحياتهم Authorization لتصميم صلاحيات المستخدمين يمكن اتباع عدة استراتيجيات منها ما هو بسيط الذي يغطي الاحتياجات الأساسية لإدارة المستخدمين وصلاحياتهم، ومنها ما هو معقد جدًا ولكنه يشمل على خصائص وخيارات كثيرة. سأشرح لك الأسلوب البسيط لأنه يطابق المخطط الموضح بالسؤال: عند تصميم التطبيقات متعددة المستخدمين، يجب تحديد صلاحيات كل مستخدم وبالمنطق ستكون العلاقة متعدد إلى متعدد Many-to-Many لأن كل مستخدم ربما يكون له أكثر من صلاحية، وكذلك الصلاحية ربما تُعطى لأكثر من مستخدم، لذلك يتوجب وجود جدول وسيط “Junction Table” أو “Intermediate Table”، وفيه يتم ذكر معرف المستخدم userID وأمامه معرف الخدمة المسموحة له serviceID ويمكن تكرار نفس المستخدم مع أكثر من خدمة. الآن نفترض أن جدول المستخدمين به 3 مستخدمين، وجدول الخدمات به 5 خدمات فيبدوان هكذا //Users table user_id user_name 1 user1 2 user2 3 user3 //Services Table service_id service_name 1 service1 2 service2 3 service3 4 service4 5 service5 الآن لإعطاء الصلاحيات للمستخدمين يتطلب إنشاء الجدول الوسيط وتحديد كل مستخدم والصلاحيات الممنوحة له، فإذا افترضنا أن المستخدم الأول له كل الصلاحيات فيتم تكرار معرف المستخدم userID مع الخمس صلاحيات، وإذا افترضنا أن المستخدم الثاني له ثلاث صلاحيات فيتم تكراره مع هذه الصلاحيات الثلاثة، وهكذا مع كل المستخدمين، فيبدو هكذا.. //Table Users_Services user_ID service_ID 1 1 1 2 1 3 1 4 1 5 2 1 2 3 2 4 هذا أبسط تصميم، ولكن به مشكلة كبيرة جدًا، تخيل لو أن لديك 200 صلاحية، فأنت تحتاج تكرار المستخدم الأول مع 200 صلاحية، وإذا يوجد مستخدم آخر له أيضًا كل الصلاحيات فسوف تضطر إلى تكرارها معه أيضًا، فتخيل مدى الجهد والوقت واحتمالية الأخطاء التي ممكن أن تحدث بسبب هذا النظام. لذلك تم تطوير هذا النظام ليكون أكثر تقدمًا، بحيث يتم إنشاء جدول ونسميه المجموعات أو القواعد User_Roles ويتم الربط بينه وبين جدول الخدمات Services ثم نربط كل مستخدم بالمجموعة التي تناسبه، وبذلك نحدد صلاحيات المجموعة (مرة واحدة) وبعدها يمكن ربط عشرات المستخدمين بهذه المجموعة (بخطوة واحدة) فيكتسبوا الصلاحيات منها، وهكذا وفرنا على المستخدم تكرار أعمال مرهقة جدًا وربما يتسبب في أخطاء وإعطاء بعض المستخدمين صلاحيات ليست من حقه. الخلاصة: جدول المجموعات User_Roles يرتبط مع جدول الخدمات Services عن طريق جدول وسيط، ثم جدول المستخدمين Users يرتبط بجدول بالمجموعات بعلاقة واحد إلى متعدد One-to-Many لأن كل مستخدم له مجموعة واحدة فقط. هناك تصميمات أعقد من ذلك، وفيها يمكن للمستخدم أن ينتمي لأكثر من مجموعة ولكنها تصميمات معقدة جدًا وتحتاج خبرة عالية لفك التداخلات أو التشابكات Conflicts بين المجموعات التي ينتمي إليها المستخدم. فيكون النموذج النهائي: Users (user_id, user_name, user_roleID) Services (service_id, service_name) User_Roles (role_id, role_name) Services_Roles(service_id, role_id) //Intermediate table

كما وضح أستاذنا حمزة عباد: إذا كنت تتابع إحدى الدورات يرجى طرح السؤال أسفل الدرس. ولكن يبدو من لقطات الشاشة أنك استخدمت الأمر let x = new sqlite3.Database("workx1"); لاحظ أنك لم تضع امتدادًا في اسم قواعد البيانات وبالتالي فإن قواعد البيانات ستأخذ الامتداد .sqlite لذلك ابحث في المجلد عن قواعد البيانات بالاسم workx1.sqlite أو ضع امتدادًا للملف فيصير let x = new sqlite3.Database("workx1.db");

يجب ملاحظة شيء هام، وهو ليس الهدف من أكاديمية حسوب حل التمارين والاختبارات للطلاب فهذا ضد قواعد الأكاديمية. إنما الهدف هو تعليم المتدربين والطلاب واكتسابهم المهارات التي من خلالها يستطيعون حل المشاكل بأنفسهم. لذلك، أعطيكي بعض الملاحظات على الشيفرات المكتوبة، وعليك اكتشاف الخطأ وتصحيحه. أولاً: عند تعليق سطر (أي تهميشه) فإن السطر لا يتم تنفيذه ويتم اعتباره كأنه ملاحظة مكتوبة وليس شيفرت مطلوب تنفيذها، وبناء عليه يجب عليك البحث عن السطور المعلقة (التي قبلها //) وتفعيلها. ثانيًا: في الحلقة التكرارية for نحن نحدد البداية مثل i = 0 ونحدد الشرط الذي يضمن استمرار الحلقة التكرارية مثل i <= count ونحدد قيمة الزيادة عن طريق ++i، فإذا كتبنا الشرط بشكل خاطيء سيحدث خطأ إما الحلقة لن يتم تنفيذها، أو سيبدأ تنفيذها ولكنها لن تنتهي أبدًا، لذلك يجب عليكِ النظر في الشرط المكتوب وتصحيحه.

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

في الحقيقة هذا السؤال هام جدًا جدًا، وهو من الأسئلة المتقدمة التي ستظهر مع ذوي الخبرة، لأن هذه المشكلة ستظهر عندما يقوم المبرمج بتطوير تطبيق وتوزيعه أو تثبيته عند العميل ثم بعد ذلك يقوم بعمل إضافات على هذا التطبيق، فتظهر هذه المشكلة. دعنا نصف المشكلة: عند تطوير أي تطبيق وإخراج الإصدار الأول منه، تكون إمكانيات هذا التطبيق محدودة إلى حد ما، ولكن مع انتشار التطبيق وأخذ الإفادات من المستخدمين سوف تظهر طلبات وإمكانيات جديدة مطلوب إضافتها إلى التطبيق (وهذا شأن أي تطبيق في العالم). إذًا ما المشكلة؟ المشكلة تكمن عندما يتعامل التطبيق مع ملفات أخرى مثل قواعد البيانات، فسنجد أن الإصدار الأول من التطبيق يتعامل مع قواعد بيانات تحتوي على عدد محدود من الجداول (وليكن 5 جداول)، ولكن مع الإضافات الجديدة سنحتاج إلى إضافة جداول أخرى (وليكن 3 جداول جديدة فيصبح الإجمالي 8 جداول). هنا تكمن المشكلة، لأن المستخدمين الحاليين قد أضافوا بيانات على قواعد البيانات (ذات الخمس جداول) وبالتالي لا يمكن حذف هذه القواعد وتنزيل القاعدة الجديدة (ذات الثمان جداول). فما الحل؟ سأذكر لك الخطوات العامة لأي تطبيق مهما كان نوعه سواء تطبيق أندرويد أو تطبيق ويندوز أو ماك، هذه الخطوات يجب اتباعها أولًا: بالنسبة للتطبيقات التي لا تقوم بحذف قواعد البيانات: هنا سنحتاج فقط تنفيذ بعض الاستعلامات التي تقوم بإنشاء الجداول الجديدة على قاعدة البيانات الموجودة حاليًا، وهكذا تظل الخمس جداول القديمة كما هي ببياناتها، ويضاف إليهم ثلاث جداول أخرى) ويتم تحديث التطبيق فيعمل بدون مشاكل. ثانيًا: بالنسبة للتطبيقات التي تحذف قواعد البيانات مع كل تحديث: إذا استطعنا تعطيل خاصية حذف الملفات مع التحديث عن طريق التحكم في خصائص التطبيق بملف الخصائص مثل gradle.properties كأن نضيف السطر التالي: android.builder.sdkDownload=false أو بأي طريقة تراها مناسبة على حسب التطبيق الذي تقوم به. فإذا فعلت هذا، اتبع التعليمات المذكورة سابقًا (بالنقطة أولاً). أما إذا لم تتمكن من تعطيل هذه الخاصية فيتوجب عليك قبل تحديث التطبيق أن تأخذ نسخة احتياطية من قواعد البيانات، وبعد التحديث، تحذف قواعد البيانات الجديدة التي نزلت حالًا مع التحديث، ثم تقوم باستعادة النسخة الاحتياطية ثم تقوم بإضافة التغييرات الجديدة عليها بعد الاسترجاع (أي إضافة الثلاث جداول الجديدة). بالتأكيد الموضوع متقدم، ويحتاج بحثًا وجهدًا، ولكن هذه الخطوط العامة التي يجب وضعها بالحسبان، والتي اكتسبناها على مدار سنوات خبرتنا بالبرمجيات وكنا نعاني كثيرًا من هذه النقطة، ولم تكن البرمجيات تقدمت بعد (أتحدث عن بدايات الألفينات).

يقدم لنا الأمر desc أساسيًا معلومات عن الأعمدة الموجودة بالجدول مثل نوع بيانات العمود data type، المقيدات constraints والخصائص الأخرى. لكن لاستعراض المفاتيح التابعة (الأجنبية) Foreign Keys الخاصة بجدول معين وليكن bonuses نستخدم الاستعلام التالي SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_SCHEMA = (SELECT DATABASE()) AND REFERENCED_TABLE_NAME = 'bonuses';

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

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

وعليكم السلام ورحمة الله وبركاته، المفترض ان العلاقة بين جدول الإدارات أو الأقسام Sub_sections وجدول الموظفين Employees هي علاقة واحد إلى متعدد one-to-many أي كل سجل في جدول الإدارات يمكنه أن يرتبط بالعديد من السجلات بجدول الموظفين، وهذا منطقي لأن كل إدارة أو قسم يمكن أن يحتوي على موظف (واحد على الأقل) أو أكثر من موظف. ويتضح أيضًا من الصورة أن هناك علاقة ذاتية واحد إلى متعدد بين جدول الإدارات (الأقسام) ونفسه، بحيث كل قسم له قسم رئيسي، فهذه علاقة ذاتية تتم بين الجدول ونفسه في جملة الاستعلام، بحيث كل قسم يمكن أن يحتوي على عدة أقسام فرعية. ولكن ألاحظ وجود خطأ في العلاقة بين جدول الموظفين وجدول الإدارات، حيث يتم الربط بينهما بعلاقتين. ما السبب في هذا؟ المبرمج الذي وضع العلاقتين يقصد أن كل موظف له قسم رئيسي section_id وله قسم فرعي sub_section_id أيضًا لذلك قام بوضع علاقتين بين هذين الجدولين، في الحقيقة لا داعي لهذا لأنه يمكن معرفة القسم الرئيسي للموظف بمجرد أن عرفنا القسم الفرعي له (وذلك لأن القسم الفرعي يستطيع أن يصل إلى القسم الرئيسي الخاص به)، وبذلك يكفي الموظف معرفة القسم الفرعي ومنه يعرف القسم الرئيسي، فيتم الربط أولاً بين جدول الموظفين Employees وجدول الإدارات أو الأقسام Sub_sections ثم يتم الربط ثانيًا مع جدول الإدارات لمعرفة القسم الرئيسي. لذلك وجود علاقتين بين الجدولين بهذا الشكل خطأ كبير وكارثي يجب تجنبه إلا في حالات معينة نادرة (كأن ينتمي الموظف لقسمين في نفس الوقت).