هل يمكن التعليق على مخطط ERD الخاص بي؟

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

مبدئيا لا مشكلة بالتصميم. اذ يتم اعتبار:

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

رغم هذا، إلا أنه يوجد بعض الملاحظات التي تخص التصميم:

• لا يظهر أن هنالك داع من خاصية movies_ids في انموذج بيانات قائمة المشاهدة watch_list، اذ تربط هذا الأخير مع انموذج الفيلم movie علاقة many to many، ولذلك فإنه سيكون من السهل الاستعلام عن الأفلام الخاصة بالقائمة دون الحاجة إلى حقل يميز ذلك في انموذج القائمة.
• لا يتضح الفرق بين انموذج قائمة المشاهدة watch_list وانموذج القائمة list، قد يمكن التخلي عنها في حال لم تكن تختلفان عن بعض.

بخصوص التوسع في التصميم، ما عليك إلا إضافة المزيد من النماذج واعتبار علاقات فعالة ما بين نماذج البيانات.

بتاريخ 3 ساعة قال Adnane Kadri:

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

مبدئيا لا مشكلة بالتصميم. اذ يتم اعتبار:

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

رغم هذا، إلا أنه يوجد بعض الملاحظات التي تخص التصميم:

• لا يظهر أن هنالك داع من خاصية movies_ids في انموذج بيانات قائمة المشاهدة watch_list، اذ تربط هذا الأخير مع انموذج الفيلم movie علاقة many to many، ولذلك فإنه سيكون من السهل الاستعلام عن الأفلام الخاصة بالقائمة دون الحاجة إلى حقل يميز ذلك في انموذج القائمة.
• لا يتضح الفرق بين انموذج قائمة المشاهدة watch_list وانموذج القائمة list، قد يمكن التخلي عنها في حال لم تكن تختلفان عن بعض.

بخصوص التوسع في التصميم، ما عليك إلا إضافة المزيد من النماذج واعتبار علاقات فعالة ما بين نماذج البيانات.

watch_list هي خاصة بالأفلام يلي شافها اوا بدو يشوفها المستخدم 

اما الlist هي قائمة فيها افلام متل الأفلام الجديدة او الأكثر مشاهد ...

• هناك عدد كبير جدًا من الكيانات والعلاقات، مما يجعل من الصعب فهم وصيانة مخطط ERD معقد مثل هذا.
• بعض أسماء الكيانات غير واضحة أو وصفية، مثل ما الفرق بين "قائمة" و"_id"؟
• بعض العلاقات غير محددة جيدًا،  ما معنى علاقة "تعيين أفلام القائمة"؟
• لا يستخدم مخطط ERD اصطلاح تسمية ثابتًا، حيث أن بعض أسماء الكيانات متعددة، بينما البعض الآخر مفرد.

حاول القيام بالتالي:

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

أي:

تقسيم المخطط إلى ثلاثة مخططات منفصلة، أحدهما لمستخدمي النظام، والثاني لأفلام النظام، والثالث لقوائم مشاهدة المستخدمين.

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

إليك مثال على مخطط ERD مبسط لنفس المجال:

مستخدم
- معرف (مفتاح أساسي)
- اسم المستخدم
- البريد الإلكتروني
- كلمة المرور

فيلم
- معرف (مفتاح أساسي)
- العنوان
- الوصف
- تاريخ الإصدار

قائمة مشاهدة
- معرف (مفتاح أساسي)
- معرف المستخدم (مفتاح خارجي إلى جدول المستخدم)
- معرف الفيلم (مفتاح خارجي إلى جدول الفيلم)