نموذج معلومات السحابة

يعد نموذج المعلومات السحابية (CIM) مخططًا مفتوحًا ومستقلاً عن التطبيق لوصف الكيانات التي تتحرك عبر المؤسسة الحديثة: الأطراف، والمنتجات، والطلبات، والمدفوعات، والعلاقات التي تربطهم معًا. وبدلاً من ابتكار نموذج بيانات مخصص لكل عملية تكامل، يقدم CIM مفردات مشتركة بحيث يمكن لنظام إدارة علاقات العملاء (CRM)، ونظام تخطيط موارد المؤسسات (ERP)، ومنصة تجارة إلكترونية، ومستودع تحليلات الاتفاق على المعنى الفعلي لـ “طلب مبيعات” (Sales Order) أو “نوع علاقة منتج” (Product Relationship Type). تتناول هذه المقالة مجموعات الكيانات التي تشكل النموذج، ثم تتعمق في كيان تمثيلي واحد — ProductRelationshipType — لإظهار كيفية تعبير CIM عن العلاقات والأدوار والمفاتيح في الممارسة العملية.

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

• ينظم CIM بيانات المؤسسة في مجموعات كيانات (الطرف، والمنتج، وطلب المبيعات، والدفع، وغيرها) يمكن اعتمادها بشكل تدريجي بدلاً من اعتمادها دفعة واحدة.
• يتم تعريف كل كيان باستخدام URI للمصطلح (Term URI)، ووصف، وخصائص قياسية (scalar properties)، وخصائص ربط (link properties) — وهي بنية تتوافق بسلاسة مع مخازن JSON-LD وRDF ومخططات الرسوم البيانية للخصائص (property-graph stores).
• تقوم كيانات العلاقة مثل ProductRelationshipType بتشفير الأدوار (أصل/فرع) بحيث يمكن نمذجة الحزم والخيارات والتغطيات دون الحاجة إلى كتابة منطق أعمال برمجي ثابت (hard-coding).
• النموذج مستقل عن التطبيق عن عمد: فهو يصف معنى البيانات، وليس كيفية تخزين بائع معين لها.
• يعد اعتماد CIM تمرينًا في رسم الخرائط (mapping)، وليس عملية استبدال شاملة — حيث تقوم بمواءمة الأنظمة الحالية مع المصطلحات المشتركة ومعالجة الفجوات.

لماذا يهم وجود نموذج مشترك

يتسم التكامل المؤسسي بنمط فشل مألوف: كل نظام يتحدث لهجته الخاصة. تطلق عليه Salesforce اسم Account (حساب)، وتطلق عليه SAP اسم Business Partner (شريك أعمال)، وتطلق عليه خدمة فوترة محلية اسم Customer (عميل). عندما تقوم بإنشاء تعيينات من نقطة إلى نقطة بين كل زوج، ينمو عدد الترجمات بمربع عدد الأنظمة المعنية، ويضاعف كل نظام جديد عبء الصيانة.

يكسر النموذج المعياري (canonical model) هذه المشكلة التربيعية؛ حيث تقوم بتعيين كل نظام مرة واحدة إلى النموذج المشترك، ويصبح النموذج المشترك هو المحور. هذه هي نفس الغريزة المعمارية وراء معايير مثل OAGIS (مواصفات تكامل مجموعة التطبيقات المفتوحة)، ونموذج Common Warehouse Metamodel الخاص بـ OMG، ومفردات schema.org للتجارة. يندرج CIM ضمن هذا التقليد ولكنه مخصص لقابلية التشغيل البيني في عصر السحابة، ويُنشر كمصطلحات مفتوحة مع عناوين URI قابلة للفك (dereferenceable).

والفائدة العملية هي أن مهندس البيانات يمكنه الإجابة على أسئلة مثل “ما هي الأنظمة التي تحمل السجل المعتمد لطرف ما؟” أو “كيف نمثل حزمة منتجات بشكل متسق عبر الكتالوج والطلب؟” باستخدام نقطة مرجعية واحدة.

نظرة سريعة على مجموعات الكيانات

CIM ليس مخططًا واحدًا متجانسًا، بل هو مجموعة من المجموعات المترابطة بشكل فضفاض. تشمل المجموعات المذكورة في النموذج ما يلي:

• الحساب (Account) — سياق العلاقة التجارية لطرف ما.
• نقطة الاتصال (Contact Point) — أرقام الهواتف، وعناوين البريد الإلكتروني، وقنوات التواصل المماثلة.
• العميل المحتمل (Lead) — طرف مرتقب لم يتم تأهيله بعد.
• الطرف (Party) ودور الطرف (Party Role) — المفهوم العام للفاعل والأدوار التي يؤديها (عميل، مورد، موظف).
• الدفع (Payment) وطريقة الدفع (Payment Method) — كيفية انتقال الأموال والأدوات المستخدمة.
• سمة المنتج (Product Attribute)، وكتالوج المنتج (Product Catalog)، والمنتج (Product) — السلع والخدمات القابلة للبيع والوصف.
• طلب المبيعات (Sales Order) وعائلته الكبيرة من الكيانات الفرعية — القلب العملياتي للنموذج.
• الشحنة (Shipment) — التنفيذ والخدمات اللوجستية.

تعتبر مجموعة طلبات المبيعات هي الأكثر تفصيلاً على الإطلاق، ومن الجدير فهم السبب. فالطلب هو المكان الذي تتركز فيه قواعد العمل: التسعير، والضرائب، والتسويات، ومجموعات التسليم، والملاحظات لكل سطر، كلها ترتبط به. يقوم CIM بتفكيك الطلب إلى العديد من الكيانات الصغيرة — Sales Order Product وSales Order Price Adjustment وSales Order Tax وSales Order Delivery Group وSales Order Payment Summary وSales Order Change Log وغيرها — بدلاً من جدول واحد عريض. هذا التفكيك هو خيار تصميم متعمد: فهو يتيح لكل جانب أن يتطور بشكل مستقل ويسمح للأنظمة بالاشتراك فقط في الأجزاء التي تهمها.

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

تشريح كيان CIM

يتبع كل كيان في CIM نفس الشكل، مما يجعل استهلاك النموذج برمجياً أمراً متوقعاً. لننظر في ProductRelationshipType وهو الكيان الذي يصف سبب ارتباط منتجين.

• URI للمصطلح (Term URI) — http://cloudinformationmodel.org/model/ProductRelationshipType. هذا هو المعرف الفريد عالميًا لهذا المفهوم. وبما أنه URI، يمكن فكه واستخدامه مباشرة في رسوم RDF/JSON-LD البيانية.
• الوصف (Description) — “أسباب ارتباط المنتجات مثل الحزمة أو الخيار أو التغطية”. يخبرك هذا أن الكيان هو نوع أو تصنيف، وليس مثيل العلاقة نفسه.
• الخصائص القياسية (Scalar Properties) — الحقول البدائية التي تحمل البيانات.
• خصائص الربط (Link Properties) — مراجع لكيانات أخرى. لا يحتوي ProductRelationshipType على أي منها، وهو أمر مفيد في حد ذاته: فهو كيان ورقي (leaf entity)، أي مفردات خاضعة للتحكم وليس محوراً.

الخصائص القياسية هي:

الخاصية	URI للمصطلح	النطاق	إلزامية	الوصف
id	.../model/id	guid	نعم	المفتاح الأساسي
parentProductRole	.../model/parentProductRole	string	نعم	الدور الأول في العلاقة، مثل “يتكون من”
childProductRole	.../model/childProductRole	string	نعم	الدور الثاني في العلاقة، مثل “مكون من”

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

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

نمذجة العلاقات باستخدام الأدوار

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

فكر في حزمة. تتكون “مجموعة أدوات التشغيل” (Starter Kit) من “جهاز توجيه” (Router) و”كابل” (Cable). في مصطلحات CIM:

• يلعب المنتج الأصل (parent product) الدور الموضح بواسطة parentProductRole — على سبيل المثال، “يتكون من”.
• يلعب المنتج الفرعي (child product) الدور الموضح بواسطة childProductRole — على سبيل المثال، “مكون من”.

من خلال تخزين كلا الدورين كسلاسل نصية على النوع (type)، تحصل على تعريف قابل لإعادة الاستخدام. يمكن لأي عدد من الروابط الفعلية من منتج إلى منتج أن يشير إلى نفس صف ProductRelationshipType؛ وبذلك تظل المفردات صغيرة ومتسقة بينما تظل مثيلات العلاقة عديدة. هذا نمط تطبيع (normalization) كلاسيكي: افصل نوع العلاقة عن مثيلاتها.

يذكر الوصف بوضوح ثلاثة أنواع — الحزمة (bundle)، والخيار (option)، والتغطية (covering) — مما يلمح إلى نطاق الدلالات التجارية التي ينوي النموذج تغطيتها:

• الحزمة — منتجات تُباع معًا كوحدة واحدة (الأصل “يتكون من” المنتجات الفرعية).
• الخيار — خيار أو إضافة مرتبطة بمنتج أساسي.
• التغطية — منتج يغلف منتجًا آخر أو يحميه، وهو أمر شائع في سياقات التأمين والضمان.

كيف تحدد مفردات الأدوار الخاصة بك

نظرًا لأن parentProductRole وchildProductRole عبارة عن سلاسل نصية حرة، فإن النموذج لا يملي عليك الصياغة الدقيقة. هذه المرونة ميزة وخطر في آن واحد. إليك بعض القواعد العملية:

1. اختر مفردات محكومة وقم بتثبيتها. اتفق على مجموعة صغيرة من عبارات الأدوار (“يتكون من” / “مكون من”، “إضافة اختيارية لـ” / “لديه خيار”) وقم بتوثيقها. النصوص الحرة تؤدي إلى تشتت المصطلحات.
2. حافظ على تناسق الأدوار وقابليتها للقراءة في كلا الاتجاهين. اختبار جيد: هل يمكنك قراءة العلاقة بصوت عالٍ من أي من الطرفين وتكون منطقية؟
3. لا تفرط في تحميل الأدوار بمنطق الأعمال. إذا كان الدور يتطلب سلوكًا شرطيًا، فإن هذا المنطق مكانه في التطبيق المستهلك، وليس في السلسلة النصية.
4. قم بإصدار مفرداتك. عند إضافة دور، تعامل معه على أنه تغيير في المخطط (schema change) مع مسار ترحيل، وليس مجرد إدراج عشوائي.

اعتماد CIM عمليًا

إن اعتماد نموذج معياري (canonical model) هو عملية انضباط في رسم الخرائط (mapping)، وليس عملية هجرة بيانات. إليك تسلسل عملي:

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

• جرد أنظمة التسجيل (systems of record) لديك. بالنسبة لكل مجموعة كيانات، حدد النظام المعتمد. قد يكون “الطرف” (Party) في نظام CRM؛ و”المنتج” (Product) في نظام PIM؛ و”أمر المبيعات” (Sales Order) في نظام ERP.
• قم بتعيين كل مصدر إلى مصطلحات CIM. أنشئ جدولاً يربط (حقل المصدر $\rightarrow$ خاصية CIM). عندما لا يكون للمصدر ما يعادله، دوّن الفجوة؛ وعندما لا يكون لـ CIM ما يعادله، دوّن الامتداد.
• التوفيق بين المعرفات. يعني اصطلاح GUID الخاص بـ CIM أنك ستحافظ عادةً على جدول مطابقة (crosswalk) بين المفاتيح الأصلية وقيم id الخاصة بـ CIM.
• اختر طريقة التسلسل (serialization). المصطلحات المستندة إلى URI في CIM تتوافق طبيعيًا مع JSON-LD وRDF؛ كما أنها تترجم بوضوح إلى جداول علائقية أو رسم بياني للخصائص (property graph). النموذج لا يفرض تقنية تخزين معينة.
• إدارة المفردات. إن سلاسل الأدوار والتعدادات والامتدادات التي تضيفها هي الأجزاء الأكثر عرضة للتشتت، لذا ضعها تحت نظام التحكم في التغيير.

النموذج العقلي المفيد هو التعامل مع CIM باعتباره مخطط التبادل (interchange) ومخازنك التشغيلية باعتبارها نظام التسجيل. أنت لا تطلب من كل تطبيق التخلي عن نموذجه الأصلي؛ بل تطلب منهم نشر واستهلاك نموذج مشترك عند الحدود الفاصلة.

المحاذير والمقايضات

لا يوجد نموذج معياري بلا تكلفة، وCIM ليس استثناءً.

• للتجريد ثمن. النموذج العام بما يكفي ليشمل صناعات متعددة لن يناسب أيًا منها بشكل مثالي. توقع إضافة امتدادات.
• مجموعة “أمر المبيعات” ثقيلة. تحليلها الدقيق قوي ولكنه يعني المزيد من عمليات الربط (joins) والمزيد من الكيانات التي يجب تعيينها. قد تتبنى الفرق ذات تدفقات الطلبات البسيطة مجموعة فرعية فقط.
• سلاسل الأدوار الحرة تحتاج إلى إدارة. كما ذكرنا، فإن المرونة في parentProductRole وchildProductRole تعتمد جودتها على مدى الانضباط في استخدامها.
• النماذج المفتوحة تتطور. نظرًا لأن CIM موجه نحو المجتمع، يمكن إضافة المصطلحات أو تحسينها بمرور الوقت. قم بالتثبيت على إصدار معين وراجع التغييرات بعناية.

المقايضة هي في الأساس المقايضة الكلاسيكية بين الدقة في نظام معين وقابلية النقل عبر الأنظمة. يحسن CIM من قابلية النقل، وهو القرار الصحيح عندما يكون الهدف هو التشغيل البيني.

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

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

ما هو نموذج المعلومات السحابية (Cloud Information Model)؟

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

في ماذا يُستخدم ProductRelationshipType؟

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

لماذا يستخدم CIM معرفات GUID للمفاتيح الأساسية؟

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

هل CIM مخطط قاعدة بيانات أم تنسيق لتبادل البيانات؟

من الأفضل فهمه على أنه نموذج مفاهيمي وتبادلي وليس مخطط قاعدة بيانات مادي. مصطلحاته المستندة إلى URI تتوافق طبيعيًا مع JSON-LD أو RDF أو الجداول العلائقية أو الرسوم البيانية للخصائص، لذا يمكنك تنفيذه باستخدام أي تقنية تخزين تستخدمها بنيتك بالفعل.

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

تشترك CIM في هدف تلك الجهود — وهو إيجاد مفردات مشتركة لقابلية التشغيل البيني — ولكن نطاقها مخصص لتكامل المؤسسات في عصر السحابة، وتُنشر كمصطلحات مفتوحة وقابلة للإسناد (dereferenceable). ومن الناحية العملية، يمكنك ربط CIM بمعايير أخرى عند النقاط الطرفية التي يتطلبها الشركاء.

هل يجب عليّ اعتماد النموذج بأكمله مرة واحدة؟

لا. يتم تنظيم CIM في مجموعات كيانات مفككة الارتباط (loosely coupled)، لذا يمكنك اعتماد المجموعات التي تحتاجها — مثل “الطرف” (Party) و”المنتج” (Product) — والتوسع لاحقًا. تبدأ معظم الفرق بالكيانات التي تسبب أكبر قدر من الصعوبات في التكامل وتتوسع من هناك.

مزيد من القراءة

• أمر المبيعات — ويكيبيديا
• إطار وصف الموارد (RDF) — ويكيبيديا
• JSON-LD — ويكيبيديا
• schema.org — مفردات مشتركة للبيانات المنظمة على الويب