نمذجة البيانات ومخططات الكيانات والعلاقات

لماذا نُنشئ نماذج البيانات؟

18 دقيقة الدرس 1 من 10

لماذا نُنشئ نماذج البيانات؟

التطبيقات تأتي وتذهب. نظام حجز مواعيد العيادة الذي بُني عام 2010 أُعيد كتابته عام 2018 وسيُستبدل مرة أخرى. لكن البيانات الأساسية — سجلات المرضى، وتواريخ المواعيد، والتشخيصات — يجب أن تصمد عبر كل إعادة كتابة، وكل تغيير في المنصة، وكل تبديل للمورّد. البيانات هي الأصل الدائم. التطبيق ليس سوى نافذة مؤقتة على تلك البيانات.

هذه الرؤية هي السبب الأول والأهم لنمذجة البيانات قبل بناء أي شيء: النموذج المُصمَّم جيداً يدوم أطول من كل تطبيق يستخدمه. أما النموذج السيئ التصميم فيُقيّد كل تطبيق يُبنى فوقه، وأحياناً لعقود.

ما هو نموذج البيانات؟

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

  • ما الأشياء التي تحتاج المنظمة إلى تذكّرها؟ (الكيانات والسمات)
  • كيف ترتبط هذه الأشياء ببعضها؟ (العلاقات)
  • ما القواعد التي تُقيّد البيانات؟ (القيود وقواعد التكامل)

نموذج البيانات ليس مخطط قاعدة البيانات، وليس مخطط الأصناف، وليس جدول بيانات. إنه تجريد — تمثيل واضح للواقع يُجرّد تفاصيل التنفيذ ويكشف البنية الجوهرية للمعلومات. الهدف هو وضوح الفهم، لا مجموعة من جمل SQL.

المستويات الثلاثة لنماذج البيانات

النمذجة ليست عملاً واحداً — بل هي تكرير تدريجي عبر ثلاثة مستويات من التجريد. كل مستوى يخدم جمهوراً مختلفاً ويجيب على أسئلة مختلفة. فهم المستوى الذي تعمل فيه يمنع ارتباكاً هائلاً أثناء التحليل والتصميم.

المستويات الثلاثة هي: المفاهيمي، والمنطقي، والمادي.

The Three Levels of Data Models 1. Conceptual Model Audience: Business stakeholders, non-technical users Content: Key entities and major relationships only — no attributes, no keys, no types High Abstraction Add attributes & cardinality 2. Logical Model Audience: Analysts, data architects, senior developers Content: Entities, all attributes, primary keys, foreign keys, cardinality — database-independent Medium Abstraction Add platform-specific details 3. Physical Model Audience: Database administrators, developers Content: Tables, columns, data types, indexes, constraints, partitioning — specific to one DBMS Low Abstraction
المستويات الثلاثة لنمذجة البيانات — كل مستوى يُضيف مزيداً من التفاصيل ويقترب أكثر من التنفيذ.

النموذج المفاهيمي: ما الأشياء الموجودة؟

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

بالنسبة لـنظام مكتبة، قد يُحدد النموذج المفاهيمي: Member (عضو)، Book (كتاب)، Loan (استعارة)، Author (مؤلف) — ويُظهر أن الأعضاء يستعيرون كتباً، والكتب يكتبها مؤلفون، وكل عملية استعارة تُسجَّل كـ Loan. لا سمات، لا أنواع بيانات، لا مفاتيح. مجرد الصورة الكبيرة.

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

النموذج المنطقي: ما البيانات التي نحتاجها؟

النموذج المنطقي يُضيف المجموعة الكاملة من السمات، ويُحدد المفاتيح الرئيسية والأجنبية، ويُعرّف قيمة العلاقات (cardinality). لكنه لا يزال مستقلاً عن أي تقنية قاعدة بيانات محددة — لا يهم إن كنت ستستخدم MySQL أو PostgreSQL أو Oracle. يجيب النموذج المنطقي على السؤال: ما البيانات التي يجب على النظام تخزينها وما القواعد التي يجب أن يُطبّقها؟

بالنسبة لنظام المكتبة، سيُظهر النموذج المنطقي أن كيان Member يملك سمات member_id (PK) وfull_name وemail وdate_joined. وكيان Loan يملك loan_id (PK) وmember_id (FK) وbook_id (FK) وloan_date وdue_date وreturn_date. والعلاقة تقول أن عضواً واحداً يمكنه امتلاك استعارات متعددة، لكن كل استعارة تنتمي لعضو واحد بالضبط.

النموذج المنطقي هو المُخرَج الأساسي لنمذجة البيانات. وهو ما يُسلّمه المحللون لمصممي قواعد البيانات وما يرجع إليه المطورون عند كتابة الاستعلامات.

النموذج المادي: كيف ستُخزَّن البيانات؟

النموذج المادي يُترجم النموذج المنطقي إلى صياغة محرك قاعدة بيانات محدد. السمة المنطقية email : String تصبح عموداً في MySQL هكذا: email VARCHAR(255) NOT NULL UNIQUE. تُضاف الفهارس للأعمدة التي ستُبحث كثيراً. وتُجزَّأ الجداول للبيانات الضخمة. وتُضبط معامِلات التخزين.

النموذج المادي من اختصاص مدراء قواعد البيانات وكبار المطورين. نادراً ما يبني المحللون نماذج مادية، لكنهم يحتاجون لفهم ماهيتها كي يخوضوا نقاشات مُستنيرة حول الأداء وقابلية التوسع وقيود المنصة.

Three Levels Applied to a Library System Library System — Same Domain, Three Models Conceptual Member Loan Book borrows covers Logical Member PK member_id full_name email Loan PK loan_id FK member_id loan_date, due_date Book PK book_id, title, isbn Physical (MySQL) TABLE members member_id INT PK AI full_name VARCHAR(120) email VARCHAR(255) UQ INDEX (email) TABLE loans loan_id INT PK AI member_id INT FK loan_date DATE NN due_date DATE NN return_date DATE NULL TABLE books book_id INT PK AI title VARCHAR(300) NN isbn CHAR(13) UQ
نفس مجال المكتبة مُعبَّر عنه في المستويات الثلاثة — من أشكال بيضاوية بسيطة، إلى صناديق كيانات منظمة بمفاتيح، وصولاً إلى تعريفات جداول SQL فعلية.

لماذا تدوم البيانات أطول من التطبيقات

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

قارن هذا بمخزن بيانات مُصمَّم جيداً: الكيانات واضحة، والعلاقات صريحة، وقيود التكامل تمنع حفظ أي بيانات فاسدة. تُرحَّل نفس البيانات بنظافة في أيام قليلة لأن أي شخص يستطيع قراءة النموذج وفهم ما يُخزِّنه كل جدول وسبب ذلك.

هذا ليس افتراضياً. تعمل المنظمات بصفة اعتيادية على نفس البيانات الأساسية لمدة 20-30 عاماً عبر أربعة أو خمسة أجيال مختلفة من التطبيقات. مستشفى افتُتح عام 1995 لا يزال بحاجة إلى سجل المريض الذي أُنشئ في أول يوم. التطبيقات تغيرت تغيراً جذرياً. البيانات لم تتغير.

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

ما ليس نموذج البيانات

توضيح المفاهيم الخاطئة الشائعة يوفّر الوقت في نقاشات الفريق:

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

دور المحلل في نمذجة البيانات

المحللون ليسوا مدراء قواعد بيانات، لكنهم الجسر بين الأعمال وتصميم قاعدة البيانات. مهمتك في نمذجة البيانات هي:

  1. الاكتشاف — تحديد ما تحتاج المنظمة إلى تذكّره من خلال مقابلة أصحاب المصلحة وفحص المستندات والجداول والنماذج القائمة.
  2. النمذجة — تمثيل تلك البيانات على المستويين المفاهيمي والمنطقي — برسم الكيانات والسمات والعلاقات بشكل صحيح قبل اتخاذ أي قرارات تنفيذ.
  3. التواصل — شرح النموذج للمطورين ومعماريي البيانات وأصحاب المصلحة التجاريين، باستخدام مستوى التجريد المناسب لكل جمهور.
  4. التحقق — مقارنة النموذج بقواعد الأعمال؛ كل قاعدة أعمال تتعلق ببيانات مُخزَّنة يجب أن تُتتبَّع إلى قيد أو علاقة في نموذج البيانات.

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

ملخص

  • البيانات تدوم أطول من التطبيقات — السبب الأول والأهم لنمذجة البيانات بعناية ودقة قبل كتابة أي كود.
  • نموذج البيانات يصف ما توجد من بيانات، وكيف ترتبط، وما القواعد التي تحكمها — بمعزل عن التنفيذ.
  • النموذج المفاهيمي مُوجَّه لأصحاب المصلحة التجاريين: الكيانات والعلاقات الرئيسية فقط، بلا تفاصيل تنفيذ.
  • النموذج المنطقي مُوجَّه للمحللين والمعماريين: السمات الكاملة والمفاتيح وقيمة العلاقات، مع الاستقلالية عن قاعدة البيانات.
  • النموذج المادي مُوجَّه لمدراء قواعد البيانات والمطورين: الجداول والأعمدة والأنواع والفهارس الخاصة بمنصة محددة.
  • المحلل يملك المستويين المفاهيمي والمنطقي؛ ومدير قاعدة البيانات يملك المستوى المادي.