الموارد

تعد صفحة الموارد نقطة الدخول لأي شخص يريد فهم نموذج المعلومات السحابية (CIM) أو تبنيه أو المساهمة فيه. CIM هو نموذج بيانات مفتوح المصدر وغير مرتبط بتطبيقات معينة - يتم إدارته تحت مظلة مؤسسة لينكس (The Linux Foundation) - يحدد مفردات مشتركة لكيانات الأعمال بحيث تتمكن الأنظمة السحابية والمحلية (on-premises) من تبادل البيانات دون أن يضطر كل فريق تكامل إلى إعادة ابتكار المخطط (schema) الخاص به. تجمع هذه الصفحة العناصر التي تحتاجها لتقييم CIM، والتنسيقات التي يدعمها، والمستودعات التي توجد فيها النماذج، وقنوات المشاركة.

النقاط الرئيسية

• CIM هو نموذج بيانات مشترك ومحايد تجاه الموردين، وليس منتجًا أو قاعدة بيانات؛ فهو يصف الكيانات والسمات والعلاقات التي يمكن لتطبيقات متعددة الربط بها.
• توجد الأصول التقنية الأساسية في مؤسسة CIM على GitHub، حيث يتم إصدار تعريفات النماذج والأدوات وترخيصها بشكل مفتوح.
• يتم التعبير عن CIM بتنسيقات قياسية متعددة بحيث يمكن استهلاكها بواسطة سلاسل أدوات مختلفة بدلاً من تقييدك بتسلسل (serialization) واحد.
• تعد صفحات العرض التقديمي والأسئلة الشائعة والأخبار أسرع طريقة لبناء دراسة جدوى اقتصادية والإجابة على أسئلة أصحاب المصلحة قبل التعمق التقني.
• تتم المساهمة من خلال مستودعات GitHub ونموذج الويب الخاص بالمساهمين؛ ويتطور النموذج من خلال مراجعة المجتمع بدلاً من خريطة طريق خاصة بمورد واحد.

ما هو نموذج المعلومات السحابية في الواقع؟

من الأفضل فهم CIM باعتباره نموذجًا أساسيًا (canonical model): تمثيل محايد ومتفق عليه لمفاهيم الأعمال - العملاء، والحسابات، والطلبات، والمنتجات، وجهات الاتصال، والعلاقات فيما بينهم - يتوسط الأنظمة التي تقوم بتشغيلها بالفعل. وبدلاً من إجبار كل تطبيق على التحدث بـ “لهجة” كل تطبيق آخر، يمكنك ربط كل نظام بـ CIM مرة واحدة، ويصبح CIM هو نقطة التبادل.

هذا هو نفس النمط المعماري الذي ظهر بشكل متكرر في تكامل المؤسسات: مخطط أساسي بنظام “المحور والأطراف” (hub-and-spoke) بدلاً من شبكة من الربط المباشر (point-to-point). ويرتبط مفاهيميًا بجهود مثل لغة الأعمال العالمية (UBL) من OASIS للمستندات، ومواصفات تكامل مجموعة التطبيقات المفتوحة (OAGIS) لرسائل الأعمال، وschema.org للمفردات على نطاق الويب. ويكمن التميز في CIM في أنه غير مرتبط بتطبيقات معينة ومصمم لواقع “السحابة بالإضافة إلى الأنظمة المحلية” الذي تعمل فيه معظم المؤسسات فعليًا.

المردود العملي هو تقليل تشتت عمليات الربط (mapping sprawl). فإذا كان لديك عدد n من الأنظمة ويجب على كل منها التحدث مع كل نظام آخر، فستواجه ما يقرب من n² من عمليات الربط. وبإدخال نموذج أساسي، ينخفض العمل إلى نحو n من عمليات الربط - عملية واحدة لكل نظام مع النموذج المشترك. وهذا التقليص هو الحجة الاقتصادية الجوهرية لتبني CIM.

العرض التقديمي لـ CIM

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

استخدمه على النحو التالي:

ذات صلة: Boomi AtomSphere — Enterprise iPaaS للتكامل المختلط بين السحابة المحلية.

• للمديرين التنفيذيين والرعاة: ابدأ بمشكلة تشتت عمليات الربط وحجة حيادية المورد. يطرح العرض التقديمي CIM كوسيلة لتقليل المخاطر، وليس كعملية إزالة واستبدال شاملة.
• للمهندسين المعماريين والمهندسين: استخدمه لتحديد السياق، ثم انتقل فورًا إلى مستودعات GitHub للاطلاع على تعريفات النماذج الفعلية.
• لأصحاب المصلحة في الحوكمة والامتثال: استخدمه لفتح نقاش حول الملكية، وإدارة الإصدارات، وكيفية مراجعة تغييرات النموذج.

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

تنسيقات CIM

يدعم CIM عمدًا معايير وتنسيقات متعددة بدلاً من تسلسل ملكية واحد. وهذا أمر مهم لأن سلاسل أدوات المؤسسات غير متجانسة: فقد تفضل أداة النمذجة، ومنصة ETL، وبوابة API، ومولد الوثائق الخاصة بك تمثيلات مختلفة.

تشمل عائلات التنسيقات ذات الصلة الشائعة في هذا المجال ما يلي:

اختيارنا: Workato — iPaaS الذي يقوده التشغيل الآلي والذي يمكن لفرق العمل البناء عليه فعليًا.

• تدوينات علاقة الكيان (ER) والتدوينات المفاهيمية للمراجعة البشرية وورش عمل التصميم.
• تمثيلات المخططات المستندة إلى JSON لاستهلاك واجهات برمجة التطبيقات (API) والتطبيقات.
• تمثيلات RDF والأنطولوجيا (ontology) لحالات استخدام الرسوم البيانية المعرفية والدلالية.
• الربط العلائقي والجدولي لمستودعات البيانات وخطوط أنابيب ETL.

مبدأ التصميم هو قابلية النقل: فالنموذج المعبر عنه بتنسيق مفتوح يمكن تحويله، ومقارنة فروقاته (diffed)، والتحكم في إصداره، والتحقق من صحته باستخدام أدوات قياسية. عندما تقيم CIM لمؤسستك، فإن السؤال الذي يجب طرحه ليس “ما التنسيق الذي يستخدمه؟” بل “هل يمكنني نقل نموذجي ذهابًا وإيابًا عبر التنسيقات التي تتطلبها أدواتي دون فقدان بيانات؟”. إذا أدى تحويل التنسيق إلى إسقاط صامت لتعددية العلاقات (cardinality) أو قيود السمات، فإن ذلك يمثل خطر تكامل حقيقي يجب اختباره مبكرًا.

كيفية تحديد التنسيق الذي سيتم اعتماده

استخدم هذا كدليل سريع لاتخاذ القرار:

إذا كان المستهلك الأساسي هو…	فضل التمثيل الذي…	احذر من…
مطورو التطبيقات/API	مخططات نمط JSON	فقدان دلالات العلاقات في JSON المسطح
فرق مستودعات البيانات / ETL	الربط العلائقي أو الجدولي	العلاقات متعدد إلى متعدد التي تتطلب جداول وسيطة
فرق الرسوم البيانية المعرفية / الدلالية	تمثيلات RDF/الأنطولوجيا	نضج الأدوات وأداء الاستعلام
ورش عمل التصميم والحوكمة	تدوين مفاهيمي/ER	الانحراف بين الرسم التخطيطي والنموذج المقروء آليًا

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

CIM في الأخبار

يقوم قسم “CIM في الأخبار” بتجميع التغطية الخارجية - الإعلانات، وتعليقات المحللين، ومقالات المجتمع - حتى تتمكن من رؤية كيفية استقبال CIM خارج المشروع نفسه. وهذا مفيد لسببين.

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

اقرأ التغطية الإخبارية بنظرة نقدية؛ فغالباً ما تصف الإعلانات النوايا والشراكات بدلاً من الاستخدام الفعلي في بيئات الإنتاج. ميز بين “انضمت المنظمة X إلى الجهد” وبين “تدير المنظمة X نموذج CIM في بيئة الإنتاج للنظام Y”. فالأولى شائعة، أما الثانية فهي الدليل الذي يهم عند اتخاذ قرار بين البناء أو التبني.

ذات صلة: Matillion — تم تصميم ELT للأسفل لمستودعات البيانات السحابية.

منظمة CIM على GitHub

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

• تعريفات النموذج — الكيانات، والسمات، والعلاقات، والقيود التي تشكل CIM.
• الأدوات — البرامج النصية والأدوات المساعدة للتحقق من صحة العناصر المستخرجة من النموذج وتحويلها وإنشائها.
• الإصدارات والسجل — سجل الالتزامات (commit history) الذي يوضح كيف تطور النموذج ولماذا.
• المشكلات والمناقشات — السجل العملي للمقترحات والأسئلة والقرارات.

هناك بعض العادات العملية التي تجعل المستودعات أكثر فائدة بكثير:

• التثبيت على إصدار (release) أو علامة (tag) بدلاً من تتبع الفرع الافتراضي، حتى لا تتغير التعيينات (mappings) الخاصة بك في منتصف المشروع.
• قراءة سجل الالتزامات للكيانات التي تهمك قبل اعتمادها؛ فالحقل الذي تغير ثلاث مرات في عام واحد يشير إلى منطقة غير مستقرة.
• التحقق من الترخيص في كل مستودع. فالمشاريع مفتوحة المصدر تخلط أحياناً بين التراخيص المستخدمة في الأدوات وتلك المستخدمة في محتوى النموذج.
• فتح مشكلات (issues) عند وجود غموض. إذا كانت تعددية العلاقة (cardinality) غير واضحة، فإن هذا الغموض سيؤثر على كل فريق في المراحل اللاحقة؛ لذا فإن إثارته مبكراً يحسن النموذج للجميع.

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

حيث سنبدأ: Fivetran — خط أنابيب ELT المُدار بالكامل والذي يستمر في العمل.

الأسئلة المتداولة

هل نموذج المعلومات السحابية (CIM) منتج يمكنني شراؤه؟

لا. CIM هو نموذج بيانات مفتوح المصدر — مجموعة من التعريفات والعناصر الداعمة — تدار تحت مظلة مؤسسة لينكس (The Linux Foundation). يمكنك اعتماده عن طريق تعيين أنظمتك إليه واستخدام تعريفات النموذج المنشورة؛ ولا توجد رسوم ترخيص للنموذج نفسه. قد يبني الموردون منتجات تدعم أو تدمج CIM، لكن النموذج في حد ذاته ليس عرضاً تجارياً.

هل يجب علي استبدال أنظمتي الحالية لاستخدام CIM؟

لا، وهذا هو الهدف الأساسي. لقد صُمم CIM ليكون وسيطاً بين الأنظمة كنموذج تبادل معياري (canonical interchange model). يمكنك الاحتفاظ بتطبيقاتك وقواعد بياناتك ومستودعات بياناتك، وبناء تعيينات من كل نظام إلى CIM. هذه العملية تدريجية: يمكنك البدء بتكامل واحد عالي القيمة وتوسيع التغطية بمرور الوقت.

ما هو التنسيق الذي يجب أن أستخدمه لاستهلاك CIM؟

يعتمد ذلك على الجهة المستهلكة. تفضل فرق واجهات برمجة التطبيقات (API) والتطبيقات بشكل عام تمثيلات المخططات بنمط JSON؛ بينما تفضل فرق مستودعات البيانات وعمليات ETL التعيينات العلائقية أو الجدولية؛ وتفضل فرق النمذجة الدلالية ورسوم المعرفة تمثيلات RDF/الأنطولوجيا (ontology). الاختبار الرئيسي هو “التحويل الدائري دون فقدان بيانات” (lossless round-tripping) — تحقق من أن التحويل بين التنسيقات يحافظ على العلاقات والقيود قبل الاعتماد النهائي.

كيف يرتبط CIM بمعايير أخرى مثل UBL أو OAGIS؟

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

كيف يمكنني المساهمة في CIM؟

تتم المساهمة بشكل أساسي من خلال منظمة CIM على GitHub — عبر المشكلات، وطلبات السحب (pull requests)، والمناقشات — بالإضافة إلى نموذج الويب للمساهمين المرتبط بهذا الموقع. ونظراً لأن النموذج يخضع لحوكمة مجتمعية، تتم مراجعة المقترحات علناً. ابدأ بخطوات صغيرة: وضح تعريفاً غامضاً أو أضف سمة مفقودة مع تقديم مبرر واضح، وتواصل مع المشرفين قبل اقتراح تغييرات هيكلية كبيرة.

من أين يبدأ صاحب المصلحة غير التقني؟

ابدأ بالعرض التقديمي لـ CIM والأسئلة الشائعة، ثم تصفح قسم “CIM في الأخبار” للحصول على سياق من طرف ثالث. ستمنحك هذه المواد الحافز والمفردات اللازمة دون الحاجة إلى قراءة تعريفات النموذج. استعن بالفريق التقني بمجرد حصولك على نموذج تكامل مرشح للتجربة، واترك لهم مهمة العمل من مستودعات GitHub.

المشاركة ومواصلة القراءة

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

للحصول على خلفية عن سياق الإشراف والحوكمة المفتوحة، راجع صفحة Linux Foundation على ويكيبيديا. وبالنسبة للأعمال المتعلقة بالمعايير، تعد OASIS Universal Business Language وschema.org نقاط مرجعية مفيدة عند مقارنة مناهج النماذج المعيارية. وللتعمق أكثر في النمذجة الدلالية، ينشر اتحاد شبكة الويب العالمية (W3C) مواصفات RDF وOWL التي تدعم تمثيلات نمط الأنطولوجيا.

استخدم أدوات التنقل في هذا الموقع للوصول إلى العرض التقديمي، والأسئلة الشائعة، ووثائق التنسيقات، وملخص الأخبار، ومستودعات GitHub — واستخدم نموذج الويب للمساهمين عندما تكون مستعداً للمشاركة في تشكيل النموذج.