علاقة المرجعية الذاتية

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

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

يتضمن إنشاء علاقة مرجعية ذاتية في نظام إدارة قواعد البيانات العلائقية (RDBMS) مثل PostgreSQL تحديد المفتاح الأساسي وأعمدة المفاتيح الخارجية داخل مخطط الجدول ووضع القيود والقواعد المناسبة للحفاظ على التكامل المرجعي. في مثال جدول الموظف، يمكن استخدام عبارات SQL التالية لإنشاء مخطط الجدول وتأسيس علاقة المرجع الذاتي:

إنشاء موظف الجدول (
    معرف الموظف INT المفتاح الأساسي،
    الاسم الأول فارتشار (50)،
    اسم العائلة فارتشار (50)،
    قسم فارتشار(50)،
    Manager_ID إنت،
    CONSTRAINT fk_Manager
        المفتاح الخارجي (Manager_ID)
        المراجع الموظف (Employee_ID)
);

يعد فهم أهمية الحفاظ على التكامل المرجعي أمرًا بالغ الأهمية عند العمل مع العلاقات المرجعية الذاتية. يتضمن ذلك إعداد قواعد CASCADE أو SET NULL أو SET DEFAULT المناسبة لعبارات ON DELETE وON UPDATE. تحدد هذه القواعد الإجراءات التي سيتم اتخاذها عند تحديث قيمة مفتاح أساسي أو حذفها.

على سبيل المثال، ضع في اعتبارك سيناريو يتم فيه تغيير معرف_الموظف الخاص بالمدير أو إزالة المدير من جدول الموظفين. للحفاظ على التكامل المرجعي، يمكن استخدام قواعد SET NULL أو SET DEFAULT لعبارة ON DELETE، مع التأكد من تعيين قيم Manager_ID الجديدة بشكل مناسب للمرؤوسين المتأثرين. وبالمثل، يمكن استخدام قاعدة CASCADE لعبارة ON UPDATE لتحديث قيمة Manager_ID تلقائيًا لجميع المرؤوسين ذوي الصلة عندما يتغير معرف الموظف الخاص بالمدير.

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

من خلال دمج العلاقات المرجعية الذاتية داخل تطبيقات الواجهة الخلفية المستندة إلى Go، يضمن AppMaster قابلية التوسع والأداء في معالجة حالات الاستخدام الخاصة بالمؤسسات والحمولات العالية. علاوة على ذلك، تعمل المنصة على تجديد التطبيقات بسلاسة من الصفر عندما تتغير المتطلبات، مما يؤدي إلى التخلص من الديون التقنية وتبسيط عملية التطوير.

باعتبارها بيئة تطوير متكاملة وشاملة (IDE)، تتيح AppMaster للمستخدمين تصميم وبناء ونشر تطبيقات الويب والجوال والواجهة الخلفية القوية والقابلة للتطوير والتي تتضمن هياكل وعلاقات بيانات معقدة مثل العلاقات المرجعية الذاتية. من خلال الاستفادة من إمكانات AppMaster الواسعة، يمكن للمستخدمين تطوير ونشر التطبيقات التي تلبي احتياجات الأعمال المتنوعة بسرعة، مما يجعل العملية أسرع بـ 10 مرات وأكثر فعالية من حيث التكلفة بثلاث مرات.