الإقليم ٤ — النموذج العلائقيّ و SQL من الجذور

النبذة

في منهج بنية الويب تتبّعتَ الطلب حتى باب قاعدة البيانات، وقلنا "تحفظ الحالة"، وأقفلنا الصندوق. الآن نفتحه — لا من واجهة أداةٍ، بل من جذره الرياضيّ. قاعدةُ البيانات العلائقيّة ليست "مكاناً نرمي فيه البيانات"؛ إنها بناءٌ هندسيٌّ وُلد من نظرية المجموعات ليحلّ مشكلةً محدّدةً في حفظ الحقائق. من يفهم لماذا جداولٌ ومفاتيحُ وقيود، يصمّم بياناتٍ لا تفسد؛ ومن يحفظ أوامرَ SQL بلا هذا الجذر، يبني على رمل. وحين تأتي Prisma في الإقليم التالي، ستكون مجرّد راحةٍ فوق ما تتقنه، لا صندوقاً ثالثاً.

اللغز المستفزّ

ليش: لماذا "علائقيّ"؟ الجذر الرياضيّ

سنة ١٩٧٠، لاحظ إدغار كود أن خلطَ "ما البيانات" بـ"كيف تُخزَّن في الملفّات" يولّد هشاشةً (كلُّ ما رأيتَه أعلاه). فاقترح فصلاً جذرياً: نمذِج البياناتِ كـعلاقاتٍ رياضية (relations)، واترك "كيف تُخزَّن" للمحرّك. العلاقة = مجموعةٌ من الصفوف (tuples)، وكلُّ صفٍّ مجموعةٌ مرتّبةٌ من القيم، كلُّ قيمةٍ من مجالٍ (نوع). وهذا بالضبط ما يصير جدولاً:

code
جدول = علاقة = مجموعةُ صفوفٍ متجانسة
صفّ  = tuple = حقيقةٌ واحدة
عمود = attribute بمجالٍ (نوع: text, integer, uuid, timestamp, boolean, enum)

الفصلُ بلا فقدانٍ يتحقّق بثلاث لبنات: المفاتيح تُعرّف الحقائق، والمفاتيح الأجنبية تربطها، والقيود تحرس سلامتها. نبنيها لبنةً لبنة.

كيف: لبنات النموذج

المفتاح الأساسيّ (primary key) — هويّةُ الصفّ

كلُّ صفٍّ يحتاج هويّةً وحيدةً ثابتةً تميّزه عن كل غيره. خياران:

• متسلسل (serial/bigserial): 1, 2, 3... — صغيرٌ، مرتّب، لكن متوقَّع (يكشف العدد، ويسهل تخمين /users/2)، ويصعب توليدُه عبر خوادمَ موزّعة بلا تنسيق.
• UUID: معرّفٌ عشوائيٌّ من ١٢٨ بت (a3f1...) — غير متوقَّع، ويُولَّد في أي مكانٍ بلا تصادمٍ بلا تنسيق (مهمٌّ للتوسّع الأفقيّ الذي تعرفه من بنية الويب). ثمنه: أكبر، وغير مرتّبٍ زمنياً.

مشروعك اختار UUID (id String @id @default(uuid()) @db.Uuid) — قرارٌ واعٍ: معرّفاتٌ لا تُخمَّن ولا تكشف حجمَ النظام، تصلح لمنصّةٍ موزّعة. (هذا أحدُ القرارات التي صرتَ تفهم لماذا اتُّخذت، لا تحفظها.)

قيدُ التفرّد (unique) — يحلّ بذرة الإقليم ٠

تذكّر سؤال idempotency: كيف تمنع POST /register المكرّر من خلق مستخدمين مزدوجين؟ الجواب ليس في كود الخادم وحده (سباقُ نقرتين متزامنتين يتجاوز أيَّ فحصٍ في التطبيق) — بل في قيدٍ تفرّضه قاعدة البيانات نفسها:

sql
username TEXT NOT NULL UNIQUE,
email    TEXT NOT NULL UNIQUE

الآن مهما تسابقت نقرتان، قاعدةُ البيانات ترفض الثانية بخطأٍ ذرّيّ. هذا هو خطّ الدفاع الأخير والوحيد المضمون. درسٌ ستبنيه في الإقليم ٦: التطبيقُ يتحقّق للطفِ التجربة، لكن قاعدةَ البيانات تتحقّق للصحّة الحتميّة. (في schema.prisma: @unique على username وemail؛ وفي الـ migration: CREATE UNIQUE INDEX.)

NOT NULL، الافتراضيّات، والقيود — الجدولُ حارسٌ

sql
password_hash TEXT NOT NULL,                 -- لا يُسمح بـ NULL
role          "Role" NOT NULL DEFAULT 'USER',-- قيمةٌ افتراضية
created_at    TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
CHECK (memory_limit_mb > 0)                  -- قيدُ منطقٍ (مثالٌ من الـ sandbox)

كلُّ قيدٍ منها قاعدةُ سلامةٍ يفرضها المحرّك مهما كان مصدرُ الكتابة (تطبيقك، سكربت، يدويّ في psql). قاعدةُ البيانات هي الحارسُ الأخير للحقيقة — أبعدُ من المترجم (الذي يُمحى) وأبعدُ من Zod (الذي يحرس حافةَ HTTP فقط). ثلاثُ طبقاتِ حراسةٍ ستراها مكتملةً في الإقليم ٦.

الأنواع المُعدَّدة (enum)

sql
CREATE TYPE "Role" AS ENUM ('USER', 'ADMIN');

مجالٌ مقيَّدٌ بقيمٍ محدّدة — مطابقٌ تماماً لاتّحاد القيم الحرفية في TS ("USER" | "ADMIN" من الإقليم ١). لاحظ في تاريخ مشروعك: الـ migration الأولى جعلت role نصّاً بافتراضِ 'trainee'، ثم الثانية حوّلته إلى enum('USER','ADMIN') — وهذا بالضبط نوعُ تطوّر السكيمة الذي يديره نظامُ الـ migrations (الإقليم ٥). (وفيه تعارضٌ مع وثائق المشروع التي تقول trainee/curriculum_designer/admin — قرارٌ تملكه الآن.)

المفتاح الأجنبيّ (foreign key) — هنا تُربَط الحقائق المفصولة

هذه اللبنةُ التي تحلّ "الفصل بلا فقدان". بدل تكرار عنوان المنهج في كل مهمّة، نفصل المنهجَ في جدوله، ونضع في المهمّة إشارةً لمفتاحه:

sql
CREATE TABLE curricula (
  id    UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  title TEXT NOT NULL                      -- الحقيقةُ هنا، مرّةً واحدة
);

CREATE TABLE sprints (
  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name          TEXT NOT NULL,
  curriculum_id UUID NOT NULL REFERENCES curricula(id) ON DELETE CASCADE
  --            ↑ مفتاحٌ أجنبيّ: يشير لصفٍّ في curricula
);

curriculum_id يخزّن هويّةَ المنهج لا نسخةً من بياناته. هذا يحقّق علاقة واحد-لكثير (CURRICULUM ─< SPRINT): منهجٌ واحدٌ له سبرنتاتٌ كثيرة، كلٌّ تشير إليه. وعنوانُ المنهج يعيش في مكانٍ واحدٍ بالضبط — لا شذوذَ تحديثٍ ولا حذف.

السلامةُ المرجعيّة (referential integrity): المحرّك يرفض curriculum_id يشير لمنهجٍ غيرِ موجود، ويرفض حذفَ منهجٍ له سبرنتات (أو يحذفها معه حسب ON DELETE). لا يمكن أن توجد سبرنتٌ يتيمة. الرابطُ مضمونٌ رياضياً، لا بأملٍ من كود التطبيق.

هكذا تنبني سلسلةُ مشروعك كلّها بمفاتيحَ أجنبية: USER ─< CURRICULUM ─< SPRINT ─< PROJECT ─< TASK ─< TEST_CASE.

كثير-لكثير: جدولُ الوصل (junction)

USER ─< ENROLLMENT >─ CURRICULUM: مستخدمٌ يسجّل في مناهجَ كثيرة، ومنهجٌ فيه مستخدمون كثيرون. لا يمكن تمثيلُ هذا بمفتاحٍ أجنبيٍّ في أيٍّ من الطرفين (أين تضع "قائمةً"؟ العلائقيّ لا يحفظ قوائم في خلية). الحلُّ الوحيد: جدولٌ ثالثٌ للوصل، كلُّ صفٍّ فيه = رابطٌ واحد:

sql
CREATE TABLE enrollments (
  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id       UUID NOT NULL REFERENCES users(id)      ON DELETE CASCADE,
  curriculum_id UUID NOT NULL REFERENCES curricula(id)  ON DELETE CASCADE,
  enrolled_at   TIMESTAMP NOT NULL DEFAULT now(),
  UNIQUE (user_id, curriculum_id)          -- لا تسجيلَ مزدوجٌ لنفس الزوج
);

وبالمثل TASK_PROGRESS يصل ENROLLMENT بـ TASK (تقدّمُ تسجيلٍ معيّنٍ في مهمّةٍ معيّنة) — وهو حيث يكتب نظامُ التصحيح نتيجتَه في الإقليم ١٠.

التطبيع (normalization) — تسميةُ ما فعلناه

ما فعلناه للتوّ اسمه التطبيع: تفكيكُ البيانات حتى تعيش كلُّ حقيقةٍ مرّةً واحدة. القواعدُ الثلاثُ الأولى، مشتقّةً من الشذوذ لا محفوظة:

• 1NF: لا قوائمَ/تكراراتٍ في خليّة — قيمةٌ ذرّيّةٌ واحدةٌ لكل خلية. (لهذا جدولُ الوصل، لا "قائمةُ مناهجَ" في خليّة.)
• 2NF/3NF حدساً: كلُّ عمودٍ غيرِ مفتاحيٍّ يعتمد على المفتاح، كلِّ المفتاح، لا شيءَ غيرِ المفتاح. عنوانُ المنهج يعتمد على المنهج لا على المهمّة، فينتقل لجدول المناهج. هذا يقتل شذوذَ التحديث/الإدراج/الحذف من جذره.

التطبيعُ ليس طقساً؛ هو العلاج المشتقُّ من الداء الذي رأيته في اللغز. (ويوجد إلغاءُ تطبيعٍ مقصودٌ أحياناً للأداء — مقايضةٌ واعية، بذرة.)

كيف: SQL — لغةُ الاستجواب التصريحيّة

SQL تختلف عن C جوهرياً: تصف النتيجة المطلوبة، لا خطواتِ الحصول عليها. تقول "أعطني صفوفَ المستخدمين حيث الدور admin مرتّبةً بالاسم"، ويقرّر مخطِّطُ الاستعلام (query planner) كيف (أيُّ فهرسٍ يمسح، أيُّ ترتيبِ ضمّ). هذا تجريدٌ قويّ — وأحياناً فخّ، حين لا تفهم ما يفعله المخطِّط (الفهارس أدناه).

DDL — تعريفُ البنية (رأيتَه أعلاه: CREATE TYPE/TABLE)

DML — التعامل مع البيانات

sql
-- إدراج
INSERT INTO users (first_name, last_name, username, email, password_hash)
VALUES ('Yazeed', 'A', 'yazeed', 'y@x.com', '$2b$...')
RETURNING id, created_at;                 -- يرجّع ما ولّدته القاعدة

-- استعلام: إسقاطٌ (أعمدة) + ترشيحٌ (WHERE) + ترتيبٌ + حدّ
SELECT id, username, role FROM users
WHERE role = 'ADMIN' AND created_at > now() - interval '7 days'
ORDER BY created_at DESC
LIMIT 20;

-- تحديثٌ وحذفٌ مرشَّحان (انتبه: WHERE وإلّا طالت كلَّ الصفوف!)
UPDATE users SET role = 'ADMIN' WHERE id = '...';
DELETE FROM users WHERE id = '...';

JOIN — قلبُ النموذج: نلملم ما فصلناه

التطبيعُ فصلَ الحقائقَ في جداول. الـ JOIN يعيد تركيبها عند السؤال — يضمّ صفوفاً من جدولين حيث يتطابق مفتاحٌ أجنبيٌّ مع مفتاحٍ أساسيّ. تذكّر تداخلَ الإقليم ٠ (/curricula/:id/sprints)؟ هو حرفياً هذا الضمّ:

sql
-- كل سبرنتات منهجٍ معيّن (الواحد-لكثير، معكوساً)
SELECT s.id, s.name
FROM sprints s
JOIN curricula c ON s.curriculum_id = c.id
WHERE c.id = '...';

-- كل المناهج التي سجّل فيها مستخدمٌ (عبور جدول الوصل — كثير لكثير)
SELECT c.title, e.enrolled_at
FROM enrollments e
JOIN curricula c ON e.curriculum_id = c.id
WHERE e.user_id = '...';

• INNER JOIN: فقط الصفوفُ التي لها مطابِقٌ في الطرفين.
• LEFT JOIN: كلُّ صفوفِ اليسار، ومع غيرِ المطابَقِ تأتي NULL يميناً (مثلاً: كلُّ المناهج، حتى ما لا سبرنتَ له — يجيب شذوذَ الإدراج الذي عانيناه!).

التجميع (aggregation)

sql
-- عدد المهامّ في كل مشروع
SELECT project_id, COUNT(*) AS task_count
FROM tasks
GROUP BY project_id;

-- عدد المسجّلين في كل منهج
SELECT c.title, COUNT(e.id) AS learners
FROM curricula c
LEFT JOIN enrollments e ON e.curriculum_id = c.id
GROUP BY c.id, c.title;

GROUP BY يطوي صفوفاً في مجموعاتٍ، ودوالُّ التجميع (COUNT/SUM/AVG/MAX) تلخّص كلَّ مجموعة. هذا كيف تحسب تقدّمَ متدرّبٍ أو إحصاءاتِ منهج.

المعاملات و ACID — لا غنى عنها للتصحيح (الإقليم ١٠)

تخيّل تسجيلَ نتيجةِ تصحيح: تكتب صفَّ نتيجةٍ، وتحدّث task_progress، وربما نقاطَ المتدرّب — ثلاثُ كتاباتٍ يجب أن تنجح كلُّها أو لا شيء. لو انهار الخادمُ بين الثانية والثالثة، تبقى البياناتُ نصفَ مكتوبةٍ متناقضة. الحلّ: المعاملة (transaction):

sql
BEGIN;
  INSERT INTO submissions (...) VALUES (...);
  UPDATE task_progress SET score = 80, status = 'passed' WHERE ...;
COMMIT;        -- إمّا الكلُّ يثبت ذرّياً...
-- ROLLBACK;   -- ...أو يُلغى الكلُّ كأنه لم يكن

ضماناتُ ACID:

• Atomicity (الذرّيّة): الكلُّ أو لا شيء. لا حالةَ نصفٍ أبداً.
• Consistency (الاتّساق): المعاملةُ تنقل القاعدةَ من حالةٍ صحيحةٍ (محترِمةٍ كلَّ القيود) لأخرى صحيحة.
• Isolation (العزل): معاملاتٌ متزامنةٌ لا يرى بعضُها نصفَ بعضٍ (مستوياتُ عزلٍ تضبط الصرامة — بذرة).
• Durability (الديمومة): ما ثبت (COMMIT) يبقى حتى لو انقطع التيّار بعده مباشرة.

هذه الضماناتُ هي لماذا نضع الحالةَ في قاعدةٍ علائقيّةٍ لا في ملفّ. وستبنيها بيدك في لغز التصحيح.

الفهارس (indexes) — لماذا يبطئ استعلامٌ ويسرع آخر

بلا فهرس، البحثُ عن WHERE email = '...' يمسح كلَّ الصفوف (sequential scan) — بطيءٌ مع الملايين. الفهرسُ بنيةُ بياناتٍ مساعدة (B-tree غالباً — تعرفها) تسمح بقفزٍ لوغاريتميٍّ للصفّ المطلوب:

sql
CREATE INDEX idx_sprints_curriculum ON sprints(curriculum_id);  -- سرّع ضمّ المفاتيح الأجنبية
EXPLAIN ANALYZE SELECT * FROM sprints WHERE curriculum_id = '...';  -- شاهد الخطّة

ملاحظتان: (١) قيودُ PRIMARY KEY وUNIQUE تُنشئ فهارسَها تلقائياً (لهذا رأيتَ CREATE UNIQUE INDEX users_email_key في migration مشروعك). (٢) المقايضة: الفهرسُ يسرّع القراءةَ لكن يبطئ الكتابةَ (يجب تحديثُه) ويأكل مساحة — ففهرِس أعمدةَ البحث والمفاتيحَ الأجنبية، لا كلَّ شيء. (EXPLAIN نافذتُك على قرارات المخطِّط — استعملها حين يبطئ استعلام.)

اللغز / البناء من الصفر

الخلاصة — أين تتّصل هذه العقدة بالشجرة

الوصلة للواقع (نمط SelfLab)

افتح schema.prisma و migration مشروعك الآن — ستقرؤهما كترجمةٍ لِما صمّمتَه:

prisma
model User {
  id       String @id @default(uuid()) @db.Uuid   // مفتاحٌ أساسيٌّ UUID
  username String @unique @map("user_name")        // قيدُ تفرّد
  email    String @unique
  password String @map("password_hash")            // NOT NULL ضمناً
  role     Role   @default(USER)                    // enum بقيمةٍ افتراضية
  ...
  @@map("users")                                    // اسمُ الجدول الفعليّ
}

و migration الـ SQL الذي ولّده يطابق ما كتبتَه بيدك: CREATE TABLE "users" (...), CREATE UNIQUE INDEX "users_email_key", CREATE TYPE "Role" AS ENUM (...). لم يعد شيءٌ منه غامضاً: تعرف لماذا UUID، لماذا unique، لماذا enum، ومن أين تأتي الفهارس. وتعرف ما ينقص سكيمةَ مشروعك (بقيّةُ الكيانات: curricula → sprints → ... → test_cases، وenrollments، وtask_progress) — وصرتَ قادراً على إضافتها.