نموذج ERD لقاعدة بيانات موقع عقارات

 one to many هي عندما يكون لعنصر من الجدور الاول ارتباط مع عنصر واحد او اكثر من الجدول الثاني،

بينما many to many عندما يكون لعنصر واحد او اكثر من الجدول الاول ارتباط مع عنصر واحد او اكثر من الجدول الثاني.

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

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

يحتوي المخطط على ثلاثة جداول:

جدول العقارات (Properties)

ويحتوي على معلومات عن العقارات مثل العنوان والمساحة والسعر والصور والتفاصيل الأخرى.

جدول المستخدمين (Users)

ويحتوي على معلومات المستخدمين مثل الاسم والبريد الإلكتروني وكلمة المرور.

جدول المفضلة (Favorites)

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

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

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

وتحديدًا، يتم استخدام جدول وسيط (pivot table) لربط جدول المستخدمين بجدول العقارات. هذا الجدول يحتوي على مفتاح خارجي (foreign key) لكلا جدول المستخدمين والعقارات، ما يسهل على قاعدة البيانات إضافة أو حذف علاقات many to many بسهولة. 

وبشكل عام، تُستخدَم علاقة one to many في حالات ربط جانب واحد بجانب آخر، في حين تُستخْدَم علاقة many to many في حالات ربط جانب متعدِّد بجانب آخر متعدِّد.

الاجابة تكون بناءا على لوائح العمل لديك. 

بتاريخ 17 ساعة قال Mohammed Fahmy3:

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

وتحديدًا، يتم استخدام جدول وسيط (pivot table) لربط جدول المستخدمين بجدول العقارات. هذا الجدول يحتوي على مفتاح خارجي (foreign key) لكلا جدول المستخدمين والعقارات، ما يسهل على قاعدة البيانات إضافة أو حذف علاقات many to many بسهولة. 

وبشكل عام، تُستخدَم علاقة one to many في حالات ربط جانب واحد بجانب آخر، في حين تُستخْدَم علاقة many to many في حالات ربط جانب متعدِّد بجانب آخر متعدِّد

شكرًا، لدي سؤال آخر، هل من الأفضل تحويل صفة نوع هل العقار شقة أو أرض أو محل إلى كينونة أخرى؟

بتاريخ 8 ساعة قال محمد عنيبة:

شكرًا، لدي سؤال آخر، هل من الأفضل تحويل صفة نوع هل العقار شقة أو أرض أو محل إلى كينونة أخرى؟

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

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

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

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

بتاريخ 9 ساعة قال Mustafa Suleiman:

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

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

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

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

شكرا، أعتقد أني سأتركه هكذا لا داعي لإضافة كينونات جديدة وتعقيده أكثر.