العلاقات في قواعد البيانات وأثرها على أداء النظام

العلاقات في قواعد البيانات: فهمها من الجذر إلى التطبيق العملي

العلاقات ليست مجرد جزء من تصميم قاعدة البيانات، بل هي النقطة التي تحدد هل النظام سيتوسع بشكل طبيعي أم سيتحول لاحقًا إلى كود مليء بالترقيع والاستعلامات المعقدة.

كثير من المطورين يتعامل مع العلاقات على أنها:

• foreign key هنا
• join هناك
• ORM relation داخل الإطار

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

• تكرار البيانات
• استعلامات ثقيلة
• منطق تطبيق معقد
• صعوبة التعديل عند تغير المتطلبات

---

ما المقصود بالعلاقة أصلًا؟

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

• واحد إلى واحد
• واحد إلى متعدد
• متعدد إلى متعدد
• علاقة ذاتية داخل الجدول نفسه

والفكرة الأساسية دائمًا هي:

هل هذا الكيان يملك الكيان الآخر؟ هل يشير إليه فقط؟ هل يمكن أن يرتبط بأكثر من سجل؟ وهل هذا الارتباط إجباري أم اختياري؟

---

المفاهيم التي يجب فهمها قبل أي علاقة

1) Primary Key

المفتاح الأساسي هو العمود الذي يميز كل سجل بشكل فريد.

id INTEGER PRIMARY KEY

2) Foreign Key

المفتاح الخارجي هو العمود الذي يشير إلى سجل في جدول آخر.

user_id INTEGER REFERENCES users(id)

3) Referential Integrity

سلامة المرجعية تعني أن قاعدة البيانات تمنع وجود قيمة تشير إلى سجل غير موجود.

مثال: إذا كان هناك post.user_id = 5 فلا يجب أن تسمح القاعدة بذلك إلا إذا كان المستخدم رقم 5 موجودًا فعلًا.

---

أولًا: علاقة One-to-One

هذه العلاقة تعني أن كل سجل في الجدول الأول يقابله سجل واحد فقط في الجدول الثاني.

مثال واقعي:

• مستخدم
• ملف شخصي للمستخدم

كل مستخدم لديه Profile واحد فقط، وكل Profile يعود لمستخدم واحد فقط.

تصميم الجداول

CREATE TABLE users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    email TEXT NOT NULL UNIQUE
);

CREATE TABLE profiles (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    user_id INTEGER NOT NULL UNIQUE,
    bio TEXT,
    avatar TEXT,
    FOREIGN KEY (user_id) REFERENCES users(id)
);

لاحظ وجود UNIQUE على user_id. هذا هو الذي يجعل العلاقة واحد إلى واحد فعلًا. بدونه ستتحول عمليًا إلى واحد إلى متعدد.

مثال إدخال

INSERT INTO users (name, email)
VALUES ('Rayan', '[email protected]');

INSERT INTO profiles (user_id, bio, avatar)
VALUES (1, 'Backend Developer', 'avatar.png');

استعلام JOIN

SELECT users.name, profiles.bio, profiles.avatar
FROM users
JOIN profiles ON profiles.user_id = users.id;

متى تستخدم هذا النوع؟

• عندما تريد فصل بيانات إضافية غير موجودة دائمًا
• عندما تريد تقليل حجم الجدول الأساسي
• عندما توجد بيانات حساسة أو نادرة الاستخدام

---

ثانيًا: علاقة One-to-Many

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

مثال:

• مستخدم واحد
• عدة مقالات

تصميم الجداول

CREATE TABLE users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL
);

CREATE TABLE posts (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    user_id INTEGER NOT NULL,
    title TEXT NOT NULL,
    body TEXT NOT NULL,
    FOREIGN KEY (user_id) REFERENCES users(id)
);

مثال إدخال

INSERT INTO users (name)
VALUES ('Rayan');

INSERT INTO posts (user_id, title, body)
VALUES
(1, 'First Post', 'Content 1'),
(1, 'Second Post', 'Content 2');

استعلام يجلب المستخدم مع مقالاته

SELECT users.name, posts.title
FROM users
JOIN posts ON posts.user_id = users.id
WHERE users.id = 1;

لماذا هذه العلاقة مهمة جدًا؟

لأنها تمثل فكرة الملكية. المقال هنا “يتبع” للمستخدم. وغالبًا تبنى عليها قرارات مثل:

• الصلاحيات
• الحذف
• الفهارس

فهرسة العلاقة

في هذا النوع من العلاقات، من المهم جدًا فهرسة المفتاح الخارجي:

CREATE INDEX idx_posts_user_id ON posts(user_id);

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

---

ثالثًا: علاقة Many-to-Many

هنا كل سجل من الجدول الأول يمكن أن يرتبط بعدة سجلات من الجدول الثاني، والعكس صحيح.

مثال:

• المقال يمكن أن يحمل عدة Tags
• والـ Tag يمكن أن يكون موجودًا في عدة مقالات

هذا النوع لا يُبنى مباشرة بين جدولين، بل يحتاج إلى Pivot Table أو Junction Table.

تصميم الجداول

CREATE TABLE posts (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    title TEXT NOT NULL
);

CREATE TABLE tags (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL UNIQUE
);

CREATE TABLE post_tag (
    post_id INTEGER NOT NULL,
    tag_id INTEGER NOT NULL,
    PRIMARY KEY (post_id, tag_id),
    FOREIGN KEY (post_id) REFERENCES posts(id),
    FOREIGN KEY (tag_id) REFERENCES tags(id)
);

هنا استخدمنا مفتاحًا مركبًا:

PRIMARY KEY (post_id, tag_id)

حتى نمنع تكرار نفس العلاقة أكثر من مرة.

مثال إدخال

INSERT INTO posts (title)
VALUES ('Understanding Queues');

INSERT INTO tags (name)
VALUES ('Laravel'), ('Backend'), ('Architecture');

INSERT INTO post_tag (post_id, tag_id)
VALUES
(1, 1),
(1, 2),
(1, 3);

استعلام لجلب المقال مع الـ Tags

SELECT posts.title, tags.name
FROM posts
JOIN post_tag ON post_tag.post_id = posts.id
JOIN tags ON tags.id = post_tag.tag_id
WHERE posts.id = 1;

متى تكون هذه العلاقة ضرورية؟

• عندما لا يمكن وضع foreign key في أحد الجدولين فقط
• عندما العلاقة من الطرفين متعددة بطبيعتها
• عندما تحتاج تخزين بيانات إضافية على العلاقة نفسها

Pivot Table مع بيانات إضافية

أحيانًا العلاقة نفسها تحمل معلومات. مثال:

• طالب يسجل في كورس
• العلاقة نفسها تحتوي على تاريخ التسجيل والدرجة

CREATE TABLE course_student (
    course_id INTEGER NOT NULL,
    student_id INTEGER NOT NULL,
    enrolled_at DATETIME NOT NULL,
    grade REAL,
    PRIMARY KEY (course_id, student_id),
    FOREIGN KEY (course_id) REFERENCES courses(id),
    FOREIGN KEY (student_id) REFERENCES students(id)
);

---

رابعًا: Self-Referencing Relationship

هنا الجدول يرتبط بنفسه.

مثال:

• كل موظف له مدير
• وكل مدير هو أصلًا موظف

تصميم الجدول

CREATE TABLE employees (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    manager_id INTEGER,
    FOREIGN KEY (manager_id) REFERENCES employees(id)
);

مثال إدخال

INSERT INTO employees (name, manager_id)
VALUES
('CEO', NULL),
('Team Lead', 1),
('Developer', 2);

استعلام Self Join

SELECT e.name AS employee, m.name AS manager
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.id;

هذا النوع مفيد جدًا في:

• الهياكل الإدارية
• التعليقات المتداخلة
• الفئات الهرمية

---

خامسًا: Polymorphic Relationships من منظور التصميم

هذا النوع يظهر غالبًا في الـ ORM أكثر من SQL الخام، لكن يمكن فهم فكرته على مستوى التصميم.

مثال:

• الصورة يمكن أن تنتمي إلى مستخدم
• أو إلى مقال
• أو إلى منتج

بدل إنشاء جدول صور لكل نوع، يمكن عمل جدول واحد:

CREATE TABLE images (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    imageable_id INTEGER NOT NULL,
    imageable_type TEXT NOT NULL,
    path TEXT NOT NULL
);

مثال بيانات:

INSERT INTO images (imageable_id, imageable_type, path)
VALUES
(1, 'users', 'user1.png'),
(3, 'posts', 'post3.png');

هذه الفكرة عملية جدًا لكنها تأتي على حساب:

• ضعف القيود المرجعية على مستوى SQL
• الاعتماد الأكبر على منطق التطبيق

ولهذا يجب استخدامها بحذر.

---

ON DELETE و ON UPDATE: الجزء الذي ينساه كثيرون

العلاقة لا تتوقف عند الربط فقط. السؤال المهم: ماذا يحدث إذا حُذف السجل الأب؟

1) CASCADE

إذا حذف الأب، يحذف الأبناء معه.

FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE

2) SET NULL

إذا حذف الأب، يصبح المفتاح الخارجي NULL.

FOREIGN KEY (manager_id) REFERENCES employees(id) ON DELETE SET NULL

3) RESTRICT

يمنع حذف السجل الأب إذا كانت هناك سجلات مرتبطة به.

FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE RESTRICT

اختيار واحد من هذه الخيارات ليس قرارًا عشوائيًا. هو قرار Business Logic.

---

العلاقات في SQLite

SQLite يدعم العلاقات والمفاتيح الخارجية، لكن هناك نقطة مهمة:

في بعض البيئات يجب تفعيلها صراحة:

PRAGMA foreign_keys = ON;

بدون هذا، قد تنشئ foreign keys لكن لا يتم فرضها فعليًا.

مثال كامل في SQLite

PRAGMA foreign_keys = ON;

CREATE TABLE users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL
);

CREATE TABLE posts (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    user_id INTEGER NOT NULL,
    title TEXT NOT NULL,
    FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);

---

العلاقات في MySQL / MariaDB

في MySQL يجب التأكد من استخدام محرك يدعم العلاقات مثل:

ENGINE=InnoDB

مثال

CREATE TABLE users (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255) NOT NULL
) ENGINE=InnoDB;

CREATE TABLE posts (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    user_id BIGINT UNSIGNED NOT NULL,
    title VARCHAR(255) NOT NULL,
    CONSTRAINT fk_posts_user
        FOREIGN KEY (user_id)
        REFERENCES users(id)
        ON DELETE CASCADE
) ENGINE=InnoDB;

وهنا الفهارس غالبًا تُنشأ تلقائيًا للمفاتيح الخارجية، لكن فهمها ما زال مهمًا.

---

العلاقات في PostgreSQL

PostgreSQL من أقوى الأنظمة في موضوع العلاقات والقيود.

مثال

CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    name TEXT NOT NULL
);

CREATE TABLE posts (
    id BIGSERIAL PRIMARY KEY,
    user_id BIGINT NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    title TEXT NOT NULL
);

PostgreSQL قوي جدًا في:

• القيود المرجعية
• الفهارس المركبة
• الاستعلامات المعقدة

---

المشاكل الشائعة في تصميم العلاقات

1) العلاقة موجودة في التطبيق وليست في قاعدة البيانات

كثير من المشاريع تعتمد على:

• user_id موجود
• لكن بدون foreign key

هذا يفتح الباب لبيانات معطوبة بسهولة.

2) استخدام many-to-many بدون حاجة

أحيانًا تكون العلاقة في الحقيقة one-to-many، لكن يتم تعقيدها بلا داعٍ.

3) نسيان الفهارس

العلاقة بدون index تتحول بسرعة إلى bottleneck في الأداء.

4) سوء استخدام cascade

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

5) العلاقة التقنية لا تعكس الواقع

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

---

كيف تفكر بالعلاقة قبل ما تكتبها؟

قبل إنشاء أي علاقة، اسأل:

• من يملك من؟
• هل يمكن أن يوجد الابن بدون الأب؟
• هل العلاقة واحدة أم متعددة؟
• هل أحتاج بيانات إضافية على العلاقة نفسها؟
• ماذا يحدث عند الحذف؟

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

---

الخلاصة

العلاقات ليست مجرد foreign keys. هي تمثيل مباشر لبنية النظام نفسه.

One-to-One، One-to-Many، Many-to-Many، Self-Reference، وحتى العلاقات متعددة الأشكال… كلها أدوات. لكن اختيار الأداة الصحيحة يعتمد على فهم طبيعة البيانات، لا على ما يسهل كتابته داخل ORM.

التصميم الجيد للعلاقات يجعل:

• الاستعلامات أوضح
• الأداء أفضل
• الصلاحيات أسهل
• التوسع أقل ألمًا

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