الأشكال الرئيسية للبيانات في نمذجة البيانات
الفصل الرابع
"ابدأ والنهاية في ذهنك." – ستيفن كوفي.
على مستوى عالٍ، تهدف نمذجة البيانات (Data Modeling) إلى أن تكون مستقلة عن تفاصيل التنفيذ الفيزيائية. ومع ذلك، لا يمكنك تجاهل الخصائص الفيزيائية لمكان تخزين بياناتك، ولا أشكال البيانات التي تتعامل معها. فمعرفة أشكال البيانات يسمح لك بأن تُبقي الهدف النهائي في ذهنك أثناء تصميم النماذج. وعلى سبيل المثال، إذا كنت تنشئ نموذج تعلم آلي (ML) لتصنيف الصور، فإن مدخلاتك ستكون صوراً، ومخرجاتك ستكون نموذجاً يصنف هذه الصور.
ولعدة عقود، ركزت معظم مناقشات نمذجة البيانات على كيفية تمثيل البيانات في الجداول. وكان هذا مناسباً عندما كان نمذجة البيانات تتمحور حول قواعد البيانات. ولكن العالم قد تغير. فاليوم، يتم استخدام العديد من أنواع البيانات بطرق لا تحصى — بيانات مهيكلة Stuctured، شبه مهيكلة Semi-structured، غير مهيكلة Unstructured، بيانات عم البيانات أو بيانات وصفية (metadata)، ومخرجات من نماذج تعلم الآلة والذكاء الاصطناعي (ML/AI) — ولا تتناسب جميعها بسهولة مع الإطار التقليدي المعتمد على الجداول.
على سبيل المثال، محاولة تطبيق مخطط الكيانات والعلاقات (ERD) بشكل مباشر لتصنيف مجموعة من الصور هو مثال على استخدام تقنية تصميم نماذج خاطئة في غير محلها. فمصنف الصور (image classifier) هو أداة أفضل، نظراً لأن مخططات الكيان والعلاقة تم إنشاؤها أساساً لتنظيم البيانات المهيكلة. ومع ذلك، يمكنك (وبشيء من المبالغة) إسقاط مفاهيم ERD على الصور، كأنك تريد العثور على صور تُظهر أشخاصاً يقودون سيارات. في هذه الحالة، لديك كيانان: الأشخاص والمركبات، وعلاقتهما هي "القيادة". ومع ذلك، فأنت تدرك أن الصورة ليست مثل جدول بقاعدة بيانات، ويجب أن يكون هذا واضحاً بذاته. سنتناول في هذا الكتاب مخططات الكيانات والعلاقات ERD وكيفية التعامل مع بيانات غير مهيكلة عبر التعلم الآلي.
دعونا الآن نلقي نظرة على بعض الأشكال الأكثر شيوعاً للبيانات التي ستتعامل معها أثناء تصميم النماذج: البيانات المهيكلة، شبه المهيكلة، غير المهيكلة، بيانات التعلم الآلي والذكاء الاصطناعي، والبيانات الوصفية.
البيانات المهيكلة (Structured Data)
البيانات المهيكلة، والتي تُسمى أحياناً البيانات الجدولية، هي بيانات منظمة للغاية تناسب الجداول المكونة من أعمدة وصفوف بشكل دقيق. ولها مخطط (Schema) معرف بدقة وصارم، مما يعني أن لكل عمود معنى ونوع بيانات محدد، مثل الأعداد الصحيحة، السلاسل النصية، والتواريخ (رغم أن جداول البيانات "spreadsheets" قد تكون أقل صرامة في هذا الجانب). من المؤكد أنك تعاملت مع البيانات المهيكلة لأنها موجودة في كل مكان — قواعد البيانات، جداول البيانات، وأطر البيانات (DataFrames).
تاريخياً، كانت مناقشات نمذجة البيانات تركز على البيانات المهيكلة. إذا كنت قد أخذت دورة أو قرأت كتاباً عن نمذجة البيانات، فمن المحتمل أنك تعلمت كيفية نمذجة البيانات المهيكلة. ويمكننا تتبع هذا التقليد إلى بدايات الحوسبة، حيث كانت البيانات غالباً تُخزن في بُنى مهيكلة. وصعود قواعد البيانات العلائقية (Relational Databases) في السبعينيات والثمانينيات من القرن الماضي عزز من هيمنة البيانات المهيكلة كالشكل الافتراضي لمعظم حالات استخدام الأعمال. لا يزال النموذج العلاقاتي (Relational Data Model) هو المسيطر عند تصميم البيانات لقواعد البيانات المعاملاتية (Transactional Databases). هناك أيضًا نماذج أخرى مشتقة للبيانات المهيكلة في مجال التحليلات، مثل نموذج الأبعاد لرالف كيمبال (Ralph Kimball’s Dimensional Model) ونموذج Data Vault لدان ليندستيدت (Dan Lindstedt). ستتعلم المزيد عن هذه النماذج لاحقاً في هذا الكتاب.
البيانات المهيكلة واسعة الانتشار، فعالة، وسهلة القراءة من قبل البشر. لقد استفادت البيانات المهيكلة من عقود من الاعتماد والتطور عبر أنواع مختلفة من قواعد البيانات. كما أنّ اعتماد لغة الاستعلامات SQL على نطاق واسع وفّر لغة مشتركة للتفاعل مع معظم قواعد البيانات. كما أن البيانات المهيكلة فعالة جداً، إذ يمكنك إضافة أو حذف أعمدة أو صفوف بسهولة، ويمكنك، حسب نظامك، فرض سلامة البيانات من خلال أنواع البيانات والقيود. وأخيراً، فإن البنية الواضحة للصفوف والأعمدة تجعل من السهل جداً فهمها.
العيب الرئيسي للبيانات المهيكلة هو أن المخطط الثابت يجعل من الصعب التعامل مع بيانات بأشكال وتعقيدات مختلفة. على سبيل المثال، يمكنك من الناحية الفنية تخزين ملفات صوتية داخل عمود، ولكن هل هذا هو أفضل أسلوب لتخزين ملف صوتي؟ بالتأكيد لا. الأفضل أن تقوم بإنشاء رابط (Pointer) لمكان تخزين الملف الصوتي بدلاً من ذلك.
تحظى قواعد البيانات عادةً بأكبر قدر من الاهتمام عند الحديث عن البيانات المهيكلة. ولكن إذا نظرت حولك، ستجد أن جداول البيانات (spreadsheets) تسيطر بالفعل على عالم البيانات المهيكلة. جداول البيانات وأطر البيانات (DataFrames) تعتبر مهيكلة ولكن دون الالتزام الصارم بالمخططات مثل قواعد البيانات. فلا يوجد ما يمنعك من إدخال أي قيمة في أي صف أو عمود، ولا توجد قيود أو عواقب فورية لذلك.
البيانات شبه المهيكلة (Semi-structured Data)
البيانات شبه المهيكلة هي "ابن العم" للبيانات المهيكلة. فهي أقل تنظيماً من البيانات المهيكلة، ولا تمتلك مخططاً صارماً أو تنسيقاً محدداً مسبقاً. ومع ذلك، فهي تحتفظ بدرجة معينة من الهيكلية والتسلسل الهرمي، لكنها أقل رسمية مقارنة بالبيانات المهيكلة. هذا الانخفاض في الرسمية والجمود يجعل البيانات شبه المهيكلة أكثر مرونة وأسهل في التعامل معها. في معظم الحالات، يتم تفضيل استخدام البيانات شبه المهيكلة إذا لم تكن ملتزماً تماماً بهيكل محدد لنموذج بياناتك.
بعض الأمثلة الشائعة على البيانات شبه المهيكلة تشمل JSON وXML والطرق المختلفة التي يتم بها تخزين البيانات في قواعد بيانات NoSQL. وبما أن JSON هو الشكل الأكثر شيوعًا للبيانات شبه المهيكلة، دعونا نلقي نظرة سريعة عليه.
في هذا المثال، يرجى ملاحظة عدة أمور. أولاً، لا يوجد مخطط ثابت أو مُعرف مسبقاً. فيمكن إضافة أو إزالة حقول جديدة دون أن يؤدي ذلك إلى إفساد مجموعة البيانات بأكملها. وعلى سبيل المثال، الحقل orderItems هو مصفوفة (Array)، مما يسمح بوجود عناصر متعددة ضمن الطلب. في هذه الحالة، هناك عنصران في orderItems، لكن يمكنك أن تضع عنصراً واحداً أو أكثر من عنصرين. ثانياً، تحتوي مجموعة بيانات JSON على كائنات متداخلة، مثل الحقل shippingAddress، الذي يتضمن عدة خصائص مرتبطة بالعنوان. يتيح لك هذا التداخل تنظيم البيانات ذات الصلة معاً. ثالثاً، يتم تنظيم البيانات بشكل هرمي، مع وجود علاقات أب-ابن بين الكيانات. على سبيل المثال، معرّف الطلب (order ID) يقع في أعلى التسلسل الهرمي، مع المعلومات المرتبطة به أسفله. وأخيراً، بيانات JSON قابلة للقراءة من قبل البشر، مما يسهل على المطورين أو المحللين فهم البيانات بصرياً والعمل معها.
يُعتبر JSON هو "بيانات الويب" والطريقة الأساسية لنقل البيانات عبر واجهات برمجة التطبيقات (APIs) أو كتابتها ككائنات (Objects) في جافاسكريبت، لغة الويب الأساسية. ورغم انتشاره الواسع، أجد أن نمذجة JSON غالباً ما تتم بشكل سيء، حيث تكثر فيه التكرار والبيانات الزائدة. يرجع جزء كبير من المشكلة ببساطة إلى عدم الإلمام بكيفية نمذجة البيانات شبه المهيكلة بشكل صحيح. بشكل عام، عيوب البيانات شبه المهيكلة هي أيضاً من نقاط قوتها. فمرونتها تعني أن البيانات يمكن أن تتخذ أي شكل في أي وقت. ولكن إذا أُسيء استخدام هذه المرونة، فقد يؤدي ذلك إلى مخطط بيانات يتغير باستمرار، مما قد يؤدي إلى تعطل الأنظمة التي تعتمد على وجود مخطط ثابت. نمذجة البيانات شبه المهيكلة لا تحظى بالتوثيق والدراسة بنفس القدر الذي تحظى به النماذج التقليدية مثل النمذجة العلائقية (Relational) أو التحليلية (Analytical). في الفصل السابع، ستتعلم كيفية نمذجة البيانات شبه المهيكلة لقواعد البيانات وأنظمة البث (Streaming Systems).
البيانات غير المهيكلة (Unstructured Data)
البيانات غير المهيكلة لا تتناسب مخطط أو هيكل مُعرف مسبقاً. فهي لا تحتوي على صفوف وأعمدة منظمة مثل البيانات المهيكلة، ولا تملك المخطط المرن الخاص بالبيانات شبه المهيكلة. البيانات غير المهيكلة هي "البيانات الأخرى" التي تشكل الغالبية العظمى من البيانات في العالم. فمقابل كل جدول بيانات موجود داخل مؤسسة، تخيل كمية الرسائل الإلكترونية والمستندات النصية المنتشرة هنا وهناك.
بعض الأمثلة على البيانات غير المهيكلة التي قد تتعامل معها تشمل المستندات النصية، الصور، الملفات الصوتية، ومقاطع الفيديو. أدى صعود تقنيات تعلم الآلة (ML) في أوائل ومنتصف العقد الأول من القرن الحادي والعشرين إلى فتح الأبواب أمام التعامل مع مجموعات البيانات غير المهيكلة. على سبيل المثال، مكنت تقنيات معالجة اللغات الطبيعية (NLP) الناس من إجراء تحليلات مشاعر (Sentiment Analysis) على كميات ضخمة من النصوص، كما دفعت الشبكات العصبية الالتفافية (Convolutional Neural Networks) تصنيف الصور إلى مستويات تجاوزت القدرات البشرية. ومع صعود الذكاء الاصطناعي التوليدي المتعدد الوسائط (Multi-modal Generative AI)، سيتم دمج البيانات غير المهيكلة بشكل متزايد في نمذجة البيانات التقليدية. سنستكشف البيانات غير المهيكلة وكيفية نمذجتها في فصول قادمة من هذا الكتاب.
وكتفكير ختامي، أعتقد أن مصطلح "غير المهيكلة" ليس دقيقاً تماماً. فكل نوع من البيانات يمتلك بنية أو هيكلاً بطريقة ما. على سبيل المثال، الصورة قد تكون بصيغة HD بأبعاد 1980 × 1080 بكسل، وهذه بنية أيضاً، رغم أنها ليست بنية يمكنك الاستعلام عنها مباشرة كما هو الحال مع مجموعة بيانات مهيكلة. ورغم أن المصطلح "غير المهيكلة" قد يكون مضللاً بعض الشيء عند وصف البيانات، إلا أنه لا يزال المصطلح الشائع الاستخدام، ولذلك سأستمر في استخدامه.
مخرجات الذكاء الاصطناعي/تعلم الآلة (Machine Learning/AI Artifacts)
في تعلم الآلة، غالباً ما تقوم بأخذ المدخلات الخام من البيانات المهيكلة، شبه المهيكلة، غير المهيكلة، بل وحتى البيانات الوصفية (Metadata)، وتغذيتها في خوارزمية تعلم آلي. تقوم الخوارزمية بإنتاج مخرجات ونتائج متنوعة تُعرف باسم "المخرجات Artifacts"
مخرجات نماذج تعلم الآلة تشمل جميع النتائج والمنتجات الجانبية التي يتم إنشاؤها أثناء تطوير وتدريب النموذج. ويمكن أن تأخذ عدة أشكال، بما في ذلك النموذج المدرب نفسه، بالإضافة إلى مقاييس التقييم المختلفة (مثل الدقة Accuracy، الاسترجاع Recall، الدقة النوعية Precision، أو غيرها من مقاييس أداء النموذج). قد تشمل المخرجات أيضاً السجلات (Logs)، المتجهات التمثيلية (Embeddings)، وغيرها من المنتجات الجانبية المرتبطة بتعلم الآلة.
توجد العديد من أنواع المخرجات المختلفة الناتجة عن تعلم الآلة. ويمكن استخدام هذه المخرجات لاحقاً كمدخلات لنماذج تعلم آلة أخرى أو دمجها في التطبيقات، التحليلات، أو نماذج تعلم آلة أخرى.
البيانات الوصفية (Metadata)
البيانات الوصفية، والتي تُعرف عادةً باسم "بيانات عن البيانات"، هي بمثابة الغراء الذي يربط البيانات معاً. فهي توفر معنى وسياقاً قد لا يكون واضحاً دائماً في مجموعة البيانات الأساسية. وكما يكتب "أولي أوليسن-باجنيوكس" في كتابه القادم أساسيات إدارة البيانات الوصفية (Fundamentals of Metadata Management)، "البيانات الوصفية هي وصف يتم ربطه بما يتم وصفه، ويتم وضعه في مكان آخر، لجعل ما يتم وصفه قابلًا للاكتشاف والإدارة."
في نمذجة البيانات، غالباً ما يتم التعامل مع البيانات الوصفية كمجرد فكرة لاحقة. حيث يتم توجيه معظم الاهتمام إلى المستوى الأعلى لمجموعة البيانات، مثل الصفوف والأعمدة في مجموعة بيانات مهيكلة، أو مفاتيح/قيم ملف JSON، وما إلى ذلك. من فضلك، احرص على قضاء وقت في فهم ليس فقط الجوانب السطحية لبياناتك، بل وأيضًا بياناتها الوصفية. خصوصاً مع تطور نمذجة البيانات لتصبح أكثر تداخلاً بين التخصصات، مثل ربط سجلات قواعد البيانات المعاملاتية transactional مع مجموعات بيانات الصور أو الفيديو. ستصبح البيانات الوصفية عنصراً أساسياً في نمذجة البيانات.
هناك العديد من أنواع البيانات الوصفية، أكثر من أن تُحصى. فيما يلي بعض الأنواع الشائعة: البيانات الوصفية للأعمال (Business Metadata)، البيانات الوصفية التشغيلية (Operational Metadata)، والبيانات الوصفية التقنية (Technical Metadata). دعنا نلقي نظرة سريعة على كل نوع مع مثال:
البيانات الوصفية للأعمال (Business Metadata): تصف سياق الأعمال، والمعنى، وأهمية البيانات داخل المؤسسة، وكيفية استخدامها وتفسيرها ضمن نطاق الأعمال. قد تتضمن مصطلحات العمل (مثل "العميل")، ملكية مجموعة البيانات، وقواعد الأعمال المتعلقة بالاستخدام، والوصول إلى البيانات، والخصوصية.
البيانات الوصفية التشغيلية (Operational Metadata): تحتوي على مقاييس مرتبطة بكيفية استخدام البيانات، مثل تاريخ ووقت إنشاء مجموعة بيانات معينة، أو متى تم تعديلها آخر مرة، ومن قام بذلك: أي نظام أو أجراء، بالإضافة إلى إحصاءات الاستخدام الأخرى.
البيانات الوصفية التقنية (Technical Metadata): تلتقط الجوانب التقنية للبيانات، مما يتيح معالجتها وعرضها وتحويلها بشكل صحيح بين تنسيقات مختلفة. قد تشمل تنسيق الملف (مثل CSV، JPEG، MP4، Parquet، JSON)، حجم الملف، أبعاد الصورة أو الفيديو (العرض، الارتفاع، الدقة)، الضغط، الترميز (مثل UTF-8، ASCII)، وغير ذلك.
لطالما شعرت أن شرح البيانات الوصفية يكون جافاً وأكاديمياً أكثر من اللازم. لذلك، لتوضيح الأنواع السابقة بشكل عملي، دعونا نأخذ مثالاً حقيقياً:
تستخدم شركة تجارة إلكترونية نظام إدارة علاقات العملاء (CRM) لإدارة تفاعلات العملاء. يقوم هذا النظام بتخزين بيانات العملاء، بما في ذلك أسمائهم، تفاصيل الاتصال، تاريخ الشراء، وتفاعلات الدعم. تقوم البيانات الوصفية للأعمال بتعريف ماذا يعني مصطلح "عميل" ضمن سياق الشركة، وأي المصطلحات (التسويق، التنفيذ، إلخ) ادارة بيانات العملاء. تصف البيانات الوصفية التقنية مخطط جداول قاعدة بيانات CRM (مثل "العملاء"، "الطلبات"، "حالات الدعم Support Cases") مع الأعمدة المرتبطة بها (مثل "معرّف العميل"، "الاسم"، "البريد الإلكتروني"، "تاريخ الطلب"، "حالة الحالة"). وقد تتبع أيضاً انتقال البيانات بين نظام CRM وأنظمة السجلات الأخرى ذات الصلة. وأخيراً، قد تسجل البيانات الوصفية التشغيلية أحداثاً مثل وقت إضافة سجل عميل جديد إلى نظام CRM، أو من الذي يصل إلى سجلات معينة بشكل متكرر، وما إلى ذلك.
مرة أخرى، هناك العشرات من أنواع البيانات الوصفية المختلفة. من المفيد أن تتعلم الأنواع الرئيسية مثل المذكورة أعلاه، ثم تتوسع لاحقًا حسب الحاجة.
ملاحظة حول كيفية تمثيل الأشكال المختلفة للبيانات
تُـمثَّل أشكال البيانات بطريقتين: إما أن تستخدم نموذج البيانات الخاص بك لإنشاء أشكال جديدة من البيانات، أو أن تستخدم بيانات موجودة مسبقاً لنمذجة شيء ما. هناك فرق دقيق وأساسي بين هذين النهجين.
استخدام نموذج البيانات لإنشاء أشكال جديدة من البيانات:
معظم مناقشات نمذجة البيانات تفترض أنك تقوم ببناء نموذج البيانات الخاص بك من الصفر. ومن الطبيعي أن تتفرع أشكال جديدة من البيانات من هذا النموذج. على سبيل المثال، تقوم بنمذجة إجراء عمل business process حيث يقدّم العميل طلباً وكيفية تنفيذ هذا الطلب. في هذه الحالة، تقوم بتقسيم العملية إلى تمثيل مهيكل وتدفق، وإنشاء نموذج بيانات استناداً إلى هذا التدفق. ستحدد الكيانات (Entities)، والعلاقات بين الكيانات، وخصائض الكيانات. وهنا، يتشكل نموذج البيانات من خلال ملاحظة شيء موجود في العالم الواقعي أو من خيالك، ومن ثم تجريده.استخدام البيانات الموجودة مسبقاً لنمذجة شيء ما:
وهذا شائع جداً. على سبيل المثال، لديك ملايين من المستندات النصية، وتريد أن تتمكن من طرح أسئلة محددة على هذه المستندات وفهم كيفية ارتباط المستندات ببعضها البعض. في هذه الحالة، قد تقوم بتقطيع النصوص إلى رموز (Tokenization) وتدريب نموذج لغوي ضخم (LLM) على هذه المستندات. هنا، أنت ببساطة تقوم بنمذجة البيانات الموجودة مسبقاً، تأخذها كمدخلات، وتنتج منها شيئاً جديداً.
للقارئ الذي سبق له العمل في نمذجة البيانات، قد تتعرف على هذا الفرق باعتباره الهندسة الأمامية (Forward Engineering) أو الهندسة العكسية (Reverse Engineering)، وسنناقش هذين المفهومين بتفصيل أكبر في الفصل التالي.
الآن وبعد أن أصبحت لديك فكرة واضحة عن الأشكال المختلفة للبيانات التي ستتعامل معها، دعنا نوجه انتباهنا إلى اللبنات الأساسية لنماذج البيانات.