MERISE - كيف أمثل العلاقة بين "Services" و "Users" في هذا المثال

مرحبا @مصطفى اوريك

يمكنك عمل علاقه بين users وال service ونسميه مثلا user_service
 
ويحتوى ال user_service على المفتاحين الأساسيين لكل منهما( users_id و services_id )

وبهذا سيكون لدنيا
علاقة بين users و user_service
علاقة بين services و user_service

وهذه العلاقه تسمى Many-to-Many
اي انه يمكن ان يكون لكل مستخدم يمكن اي يكون لدية اكثر من خدمه او اضافه اكثر من خدمة

شكرا لك

عليك إنشاء جدول وسيط Intermediary Table يسمى مثلاً Service_Providers يشير إلى العلاقة بين المستخدمين (العارضين) والخدمات.

و يحتوي الجدول على مفتاحين خارجيين، مفتاح المستخدم (user_id) ومفتاح الخدمة (service_id).

ويجب أن يكون المستخدم المشار إليه في الجدول هو من نوع "عارضي الخدمات" عبر استخدام الدور المحدد في جدول User_Role.

لذا، النموذج النهائي يبدو كالتالي:

• Users: يحتوي على بيانات المستخدمين.
• Services: يحتوي على بيانات الخدمات.
• User_Role: يحتوي على أدوار المستخدمين.
• Service_Providers: يحتوي على العلاقات بين المستخدمين (عارضي الخدمات) والخدمات.

بالنسبة لتمثيل العلاقات:

• العلاقة بين Users و Service_Providers: علاقة واحد إلى عدة (1:N).
• العلاقة بين Services و Service_Providers: علاقة واحد إلى عدة (1:N).
• العلاقة بين Users و User_Role: علاقة واحد إلى عدة (1:N).

مخطط النموذج (MCD):

Users (user_id, user_name, user_email)
Services (service_id, service_name, service_description)
User_Role (role_id, role_name)
Service_Providers (service_provider_id, user_id, service_id)

Users -1:N-> Service_Providers (user_id)
Services -1:N-> Service_Providers (service_id)
User_Role -1:N-> Users (role_id)

هذا السؤال هام لأقصى درجة، فمن خلال التصميم يتم تحديد صلاحيات المستخدمين والتحكم بها، وفي الواقع إجابة هذا السؤال تحتاج إلى مجلدات حيث أن الموضوع لا يقتصر على تصميم قواعد البيانات فحسب، وإنما أيضًا معرفة تامة بالصلاحيات واختياراتها وما الاختيار الافتراضي وأشياء كثيرة تخص استيثاق المستخدمين 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