صعوبة في تحديد العلاقة التعريفية أو غير المحددة

Question

قرأت هذا السؤال : ما الفرق بين العلاقات التعريفية وغير التعريفية؟

لكني مازلت غير متأكدة جداً...ما لدي هو ثلاث جداول.

1. المستخدمين
2. أشياء
3. الصور

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

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

Answer 1

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

• إذا تعرف الطفل على والديه، فهذه علاقة تعريف.في الرابط الذي قدمته، إذا كان لديك رقم هاتف، فأنت تعرف من ينتمي إليه (ينتمي إلى شخص واحد فقط).

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

يحرر:أمثلة أخرى من الحياة الواقعية:

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

Answer 2

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

Answer 3

قال نيك سي:علاقات رأس برأس هي علاقات تعريفية، وعلاقات أطراف بأطراف هي علاقات غير محددة

التفسير يبدو خاطئا تماما بالنسبة لي.بإمكانك أن تأخذ:

• العلاقات غير المحددة من Ono-to-One
• العلاقات غير المحددة من واحد إلى كثير
• تحديد العلاقات الفردية
• علاقات تحديد واحد إلى متعدد
• كثير إلى كثير تحديد العلاقات

تخيل أن لديك الجداول التالية: customer, products و feedback.وكلها مبنية على customer_id التي توجد على cutomer طاولة.لذا، بواسطة نيك سي التعريف لا ينبغي أن يكون هناك أي نوع من علاقات التعريف من كثير إلى كثير، ولكن في المثال الخاص بي، يمكنك أن ترى بوضوح ما يلي: لا يمكن أن توجد التعليقات إلا في حالة وجود المنتج ذي الصلة وتم شراؤه من قبل العميل، لذلك يجب تحديد العميل والمنتجات والتعليقات.

يمكنك إلقاء نظرة على دليل ماي اس كيو ال, مع شرح كيفية إضافة المفاتيح الخارجية إلى MySQL Workbench أيضًا.

Answer 4

مهدي، غرائزك صحيحة.هذا سؤال مكرر وهذه الإجابة التي تم التصويت عليها ليست صحيحة أو كاملة.انظر إلى أعلى إجابتين هنا:الفرق بين تحديد عدم تحديد الهوية

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

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

اسأل نفسك هذا السؤال

• هل يمكن أن يوجد السجل الفرعي بدون السجل الأصلي؟

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

علاقة تعريفية فردية

تتناسب أرقام الضمان الاجتماعي بشكل جيد مع هذه الفئة. لنتخيل على سبيل المثال أن أرقام الضمان الاجتماعي لا يمكن أن توجد بدون شخص (ربما يمكنها ذلك في الواقع، ولكن ليس في قاعدة بياناتنا). person_id سيكون PK لـ شخص الجدول، بما في ذلك الأعمدة مثل اسم و عنوان.(دعونا نبقي الأمر بسيطا).ال رقم الضمان الاجتماعي سيتضمن الجدول ssn العمود و person_id العمود كمفتاح خارجي.نظرًا لأنه يمكن استخدام FK هذا باعتباره PK لـ رقم الضمان الاجتماعي الجدول هو علاقة تعريف.

علاقة فردية غير محددة

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

علاقات واحد إلى متعدد

يمكن تصنيف علاقات رأس بأطراف بسهولة عن طريق طرح نفس السؤال.

علاقات متعدد إلى متعدد

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

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

في أغلب الأحيان لا يهم نوع العلاقة.

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

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