قاموس البيانات
قاموس البيانات
مخطط ERD صورة. يُظهر البنية — أي كيانات موجودة، وكيف ترتبط، وأين تقع المفاتيح الأجنبية. لكن الصورة لا تستطيع أن تُخبرك أن status في جدول appointments يقبل فقط القيم pending وconfirmed وcompleted وcancelled. لا تستطيع أن تُخبرك أن email يجب أن يكون فريداً في كامل النظام، أو أن discount_rate عشري بين 0.00 و1.00، أو أن notes اختياري بينما patient_id إلزامي. تلك المعلومات تسكن في قاموس البيانات.
قاموس البيانات هو كتالوج منظَّم يوثّق كل كيان وكل سمة وكل قيد في نموذج البيانات. إنه الرفيق الكتابي لمخطط ERD — معاً يُشكّلان مواصفة كاملة لبيانات النظام. لا ينبغي لأي مطوّر أو مدير قاعدة بيانات أو محلل مستقبلي أن يضطر إلى التخمين في معنى أي حقل أو القيم التي يقبلها.
ما يحتويه قاموس البيانات
كحد أدنى، يتناول إدخال قاموس البيانات الاحترافي ما يلي لكل سمة:
- اسم السمة — الاسم الدقيق كما سيظهر في قاعدة البيانات (بالاصطلاح snake_case)
- الوصف — تفسير بلغة بسيطة لما تعنيه السمة بمصطلحات الأعمال
- نوع البيانات — النوع المنطقي: String، Integer، Decimal، Date، Boolean، Enum... (ليس نوعاً خاصاً بمنصة بعينها)
- الطول / الدقة — أقصى عدد محارف للنصوص؛ أرقام وخانات عشرية للأعداد
- إلزامي — هل السمة مطلوبة (NOT NULL) أم اختيارية (NULLable)
- فريد — هل تُحظر القيم المكررة
- القيمة الافتراضية — القيمة المُسنَدة عند عدم توفير قيمة
- القيم المسموح بها / النطاق — لحقول Enum والحقول المقيّدة: القائمة الاستنفادية للقيم الصالحة
- دور المفتاح — PK أو FK أو CK (مفتاح مرشّح) أو لا شيء
- مرجع المفتاح الأجنبي — للـ FKs: الكيان والسمة المُشار إليهما
- قاعدة الأعمال — أي قيد إضافي لا يمكن التعبير عنه بالنوع وحده (مثل: "يجب أن يكون تاريخاً مستقبلياً"، "يجب أن يكون أكبر من صفر")
- قيم مثالية — مثال أو مثالان توضيحيان يُجليان أي وصف غامض
مثال كامل: نظام حجز مواعيد عيادة
لنأخذ كيان appointments من نظام حجز مواعيد عيادة. مخطط ERD يُظهر الكيان وعلاقاته. أما قاموس البيانات فيُخبرك بالضبط ماذا تعني كل سمة، وما النوع الذي تحمله، وما القواعد التي تُقيّدها.
توثيق نطاقات Enum
تستحق سمات التعداد (Enum) اهتماماً خاصاً. كلما قبل حقل مجموعة ثابتة من القيم، يجب أن يُدرج قاموس البيانات كل قيمة مسموح بها ويُفسّر ما تعنيه. الإدخالات الغامضة مثل "status (Enum)" دون إدراج القيم تترك المطوّر يخمّن — والتخمين يُنتج بيانات غير متسقة.
لسمة status في كيان orders بمتجر إلكتروني، يبدو إدخال النطاق الصحيح هكذا:
لاحظ كيف تحمل كل قيمة تعريفاً تجارياً، لا مجرد تسمية. هذا هو الفارق بين قاموس البيانات الذي يوجّه التنفيذ وبين الذي يكتفي بإدراج الأسماء.
توثيق العلاقات في القاموس
لا يحل قاموس البيانات محل مخطط ERD في توثيق العلاقات، لكنه يجب أن يتضمن قسماً للعلاقات لكل كيان يُلخّص قواعد القيمة العددية بلغة بسيطة. هذا يجعل النموذج مقروءاً دون الحاجة إلى فك رموز تدوين crow-foot.
كيفية كتابة أوصاف مفيدة فعلاً
أكثر جزء مُهمَل في قاموس البيانات هو عمود الوصف. يملأه المحللون أحياناً بإعادة صياغة بديهية: "customer_id — معرّف العميل". هذا لا يُضيف قيمة. الوصف المفيد يجيب على أسئلة لا يمكن للاسم وحده الإجابة عنها:
- ماذا يعني من منظور الأعمال؟ — "المعرّف الفريد الذي يُسنده نظام CRM لحظة إنشاء حساب العميل. ليس هو نفسه رقم بطاقة الولاء."
- متى يُحدَّد؟ — "تُملأ هذه القيمة من قِبَل محرك الحجز لحظة التأكيد، لا لحظة الطلب."
- ما الحالات الحدية؟ — "قد يكون null في حالات الدفع كضيف. سيكون دائماً غير null للعملاء المسجلين."
- ما الوحدة؟ — "مُخزَّن بوحدة الدقائق الكاملة، لا الساعات ولا الثواني."
reason يستخدمه الأطباء أحياناً لإعداد المعدات مسبقاً، أو مدير المستودع الذي يعلم أن processing يعني أن قائمة الاختيار قد طُبعت. أجرِ مقابلاتك قبل أن توثّق.
توثيق الكيان على مستوى الرأس
قبل إدراج السمات، يجب أن يحتوي كل كيان في قاموس البيانات على رأس كيان موجز يتضمن:
- اسم الكيان واسم الجدول المقابل
- التعريف التجاري — جملة أو جملتان تشرحان ما يمثله هذا الكيان في العالم الحقيقي
- تقدير الحجم — العدد التقريبي للصفوف حالياً وبعد ثلاث سنوات (يساعد مدير قاعدة البيانات على تخطيط الفهارس والتجزئة)
- استراتيجية المفتاح الرئيسي — مفتاح بديل (عدد صحيح تلقائي الزيادة)، أو مفتاح طبيعي، أو مفتاح مركّب، ولماذا
- النظام المالك — في بيئات متعددة الأنظمة: أي نظام هو السجل الرئيسي لهذا الكيان
- سياسة الاحتفاظ — مدة الاحتفاظ بالسجلات قبل الأرشفة أو الحذف (مهم للامتثال لـ GDPR)
صيانة قاموس البيانات
قاموس البيانات الذي يُنشأ مرة واحدة ولا يُحدَّث أبداً يصبح مُضلِّلاً — أسوأ من عدم وجوده، لأنه يُنشئ ثقة زائفة. القاموس وثيقة حية. الممارسات التي تبقيه محدَّثاً:
- اعتبر تحديث القاموس جزءاً من تعريف "الانتهاء" لأي قصة مستخدم تُغيّر نموذج البيانات
- خزّنه في نظام إدارة النسخ إلى جانب مخطط ERD حتى تكون التغييرات قابلة للتتبع والتراجع
- اربطه بمواصفة المتطلبات — كل سمة يجب أن تعود إلى متطلب واحد على الأقل
- جدوِل مراجعة في نهاية كل مرحلة لاكتشاف الانجراف بين القاموس وقاعدة البيانات الفعلية
قاموس البيانات ومخطط ERD معاً
لا مخطط ERD وحده ولا قاموس البيانات وحده كافيان. مخطط ERD بدون القاموس هو هيكل عظمي — ترى البنية لكن ليس المحتوى. القاموس بدون مخطط ERD هو جدول وقائع بدون إحساس بكيفية اتصالها. معاً يُشكّلان مواصفة منطقية كاملة يستطيع المطوّر تنفيذها بدون غموض، ويستطيع المختبر استخدامها للتحقق من تطبيق القيود، ويستطيع المحلل المستقبلي الاستناد إليها لفهم النظام بعد سنوات من انتهاء الفريق الأصلي.
حين تُسلّم نموذج بيانات في نهاية مرحلة التحليل، تُسلّم كلا المُخرَجين. مخطط ERD يذهب على الجدار. قاموس البيانات يذهب في وثيقة المواصفات. كلاهما يُراجَع ويُوقَّع عليه من أصحاب المصلحة.
ملخص
- قاموس البيانات يوثّق كل كيان وسمة: الاسم والنوع والطول والإلزامية والتفرّد والقيمة الافتراضية والقيم المسموح بها ودور المفتاح ومرجع المفتاح الأجنبي وقواعد الأعمال والأمثلة.
- يجب أن يجيب وصف كل سمة على: ما معنى الحقل، ومتى يُحدَّد، وما الحالات الحدية، وما الوحدة.
- كل كيان يحتاج إلى رأس: التعريف التجاري، وتقدير الحجم، واستراتيجية المفتاح الرئيسي، والنظام المالك، وسياسة الاحتفاظ.
- سمات Enum يجب أن تُدرج كل قيمة مسموح بها مع تعريف بلغة بسيطة لكل منها.
- قسم العلاقات يوثّق القيمة العددية وموقع المفتاح الأجنبي وقواعد التكامل الاسترجاعي (Restrict / Cascade / Set Null) بلغة بسيطة.
- قاموس البيانات وثيقة حية: حدّثه مع كل تغيير في المخطط، وخزّنه في نظام إدارة النسخ، واربطه بالمتطلبات.
- مخطط ERD وقاموس البيانات متكاملان — لا يكفي أي منهما منفرداً. معاً يُشكّلان مواصفة بيانات منطقية كاملة وغير غامضة.