الطرق الأربع لإدارة البيانات الرئيسية
متاح أيضًا بـ28 لغة
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
الوحدة 2 من 6 في فصل البيانات الرئيسية والهوية، الفصل 6 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: مصدر واحد للحقيقة لكل سمة · التالي: المطابقة والدمج وقواعد البقاء
السؤال الذي تجيب عنه هذه الوحدة: كيف تدير المؤسسات بياناتها الرئيسية، وأيّ أسلوب يناسب؟
قالت الوحدة 1 إن المرجعية تُحدَّد سمةً سمة. والآن: ماذا نفعل حين تعيش تلك السمات في عدة أنظمة في آن واحد؟ معلومات العميل في Salesforce، وفي ERP، وفي الفوترة، وفي الدعم، وربما في Data 360، وربما في مستودع بيانات، ولكلٍّ نسخته. هذه هي المشكلة التي تحاول إدارة البيانات الرئيسية (MDM) حلها، وMDM ليست معمارية واحدة. ستسمع عن أربعة أنماط: السجل المركزي (registry)، والدمج (consolidation)، والتعايش (coexistence)، والمركزي (centralized). إنها ليست إعدادات في منتج. إنها أربع إجابات عن سؤال واحد: كم من المرجعية تملك طبقة إدارة البيانات الرئيسية؟
ابدأ بالمشكلة، لا بالمنتج
Section titled “ابدأ بالمشكلة، لا بالمنتج ”يسمع الناس كلمة MDM فيبدؤون التسوّق بحثًا عن منتج MDM. أما أنا فأبدأ بالمشكلة. هل نحتاج فقط إلى معرفة أن عدة سجلات تمثل العميل نفسه؟ هل نحتاج إلى رؤية مجمّعة واحدة للتحليلات؟ هل نحتاج إلى أن نقرر أيّ القيم معتمدة ونعيدها إلى الأنظمة الأخرى؟ أم نريد نظامًا مركزيًا واحدًا يُنشئ البيانات الرئيسية للجميع؟ متطلبات مختلفة جدًا، ومعماريات مختلفة جدًا.
السجل المركزي: أخبرني من هو من
Section titled “السجل المركزي: أخبرني من هو من ”أخف الأنماط. السجل المركزي (registry) لا يحل محل المصادر. يحتفظ ERP بعميله، وSalesforce بحسابه، والفوترة بعميلها، ويستنتج السجل المركزي أن هذه السجلات تمثل الكيان نفسه: الحساب 001… في Salesforce، والعميل SAP-43821 في ERP، وعميل الفوترة BILL-9127 تعود كلها إلى عميل واحد. تبقى المصادر حيث هي ولا يُكتب فوقها. والآن صار لسؤال «أرني كل ما نعرفه عن هذا العميل» جواب.
لكن لاحظ ما لا يجيب عنه السجل المركزي. يقول Salesforce إن العنوان 123 Main Street، ويقول ERP إنه 125، وتقول الفوترة «123 Main St., Suite 200». السجل المركزي يعرف أنها تنتمي معًا. لكنه لا يقرر أيّها يجب أن يتغير. الربط ليس إدارةً للبيانات الرئيسية.
من خبرتي، السجل المركزي هو القاعدة في مشاريع Salesforce، يليه الدمج والتعايش؛ أما MDM المركزي الخالص فنادر. السجل المركزي شائع لأنه غير جراحي. لا تعيد تصميم كل نظام تشغيلي قبل أن تحصل على قيمة. يواصل Salesforce عمله، ويواصل ERP عمله، وتضيف أنت طبقة هوية. وهذا تغيير أصغر بكثير من أن تقول لكل نظام «لم تعد تتحكم في بيانات العملاء؛ هذا النظام المركزي الجديد هو من يتحكم».
السجل المركزي يجيب: أيّ السجلات تنتمي إلى الكيان نفسه؟
الدمج: اجمع البيانات معًا
Section titled “الدمج: اجمع البيانات معًا ”الدمج (consolidation) يأخذ البيانات من عدة مصادر ويجمعها في تمثيل مركزي، لأغراض التقارير والتحليلات والتجزئة وفهم العملاء. مستودع البيانات هو المثال المألوف: يرسل Salesforce العميل، ويرسل ERP البيانات المالية، وترسل الفوترة المدفوعات، فتستطيع الجهة أخيرًا أن تحلل العميل عبر الأنظمة. وتبقى المصادر موجودة وقد تبقى هي المرجع المعتمد. والاتجاه مهم: البيانات تتدفق إلى النظام المدمج، الذي لا يعيد في العادة التغييرات المُدارة إلى المصادر. صورة أفضل للعميل، دون أن يصبح المرجع التشغيلي له.
من السهل الخلط بين السجل المركزي والدمج. الفرق في ما يُركَّز: السجل المركزي يركّز الهوية («هذه تنتمي معًا»)؛ والدمج يركّز قدرًا أكبر من البيانات («اجمع السمات معًا كي نستخدمها»). ولا أحد منهما يقول «هذا النظام المركزي هو الآن المصدر الرئيسي وعلى كل تطبيق أن يقبل قيمه».
الدمج يجمع البيانات معًا دون أن ينتزع الملكية من المصادر.
التعايش: قرّر، ثم أعِد القيمة
Section titled “التعايش: قرّر، ثم أعِد القيمة ”في التعايش (coexistence)، تنال طبقة إدارة البيانات الرئيسية مرجعية حقيقية. لا تزال البيانات تعيش في عدة أنظمة تشغيلية، لكن عملية MDM تقرر القيمة المُدارة وتنشرها عائدة إليها. لدى Salesforce وERP والفوترة اسم قانوني مختلف لكلٍّ منها؛ فتحدد عملية MDM الاسم المحكوم وتوزّعه على الثلاثة. الأنظمة تتعايش، لكنها تتقارب نحو القيمة المُدارة.
هذا شكل أقوى بكثير من MDM. إنه لا يقول «هذه تنتمي معًا»؛ بل يقول «لهذه السمة، هذه هي القيمة التي تستخدمها المؤسسة». وهذا يتطلب أكثر من المطابقة: قواعد عمل، وملكية، وقواعد بقاء، وتكاملًا ثنائي الاتجاه، ومعالجة للأخطاء، وحوكمة، لأن أحدًا ما يجب أن يقرر لماذا تفوز قيمة دون أخرى.
التعايش لا يكتفي بربط السجلات. بل يقرر القيم المُدارة ويعيدها.
المركزي: المصدر الرئيسي يصنع الحقيقة
Section titled “المركزي: المصدر الرئيسي يصنع الحقيقة ”أقوى الأنماط. في MDM المركزي، تُنشأ البيانات الرئيسية المحكومة وتُصان في المصدر الرئيسي المركزي وتُوزَّع على الجميع. فبدلًا من أن يُنشئ كل نظام عميله الخاص ثم تسوّي MDM بينها لاحقًا، تُنشئ العميل المحكوم في المصدر الرئيسي، ثم ترسله إلى Salesforce وERP والفوترة. حوكمة قوية جدًا، وتغيير كبير جدًا: العمليات القائمة تُنشئ عملاءها، وللمستخدمين سير عملهم، والتكاملات تفترض الإنشاء المحلي، وقد لا تتفق وحدات العمل أصلًا على معنى العميل. لهذا هو نادر في بيئات Salesforce التي أراها. قد يكون هو الصواب. لكنه قرار أكبر بكثير من تثبيت أداة.
MDM المركزي ينقل الإنشاء والمرجعية إلى المصدر الرئيسي.
الأربعة جنبًا إلى جنب
Section titled “الأربعة جنبًا إلى جنب ”| الأسلوب | ما الذي يُركَّز | هل تبقى المصادر؟ | هل يعيد القيم المحكومة؟ |
|---|---|---|---|
| السجل المركزي | الهوية والروابط | نعم | في العادة لا |
| الدمج | الهوية والبيانات المجمّعة | نعم | في العادة لا |
| التعايش | الهوية والبيانات والقرارات المُدارة | نعم | نعم |
| المركزي | الإنشاء والمرجعية | نعم، كمستهلكين | نعم |
كلما نزلت في الجدول، نالت طبقة الإدارة مرجعية أكبر، واضطرت المؤسسة في العادة إلى تغيير أكبر.
معلومة للاختبار. اعرف أساليب تنفيذ MDM الأربعة: السجل المركزي (يربط الهويات؛ وتحتفظ المصادر ببياناتها)، والدمج (يجمع البيانات معًا، للتحليل في الغالب)، والتعايش (يقرر القيم المُدارة وينشرها عائدة إلى المصادر)، والمركزي (المصدر الرئيسي يُنشئ البيانات؛ والمصادر تستهلكها).
إذن لا يوجد شيء اسمه «المركزي هو الأنضج، فيجب أن يصل إليه الجميع». اختر أخف نمط يحل المشكلة. تحتاج إلى معرفة أن السجلات تنتمي معًا؟ فكّر في السجل المركزي. رؤية مجمّعة للتحليلات؟ الدمج. قيم محكومة تُزامَن عائدة إلى عدة أنظمة تشغيلية؟ التعايش. عملية واحدة تُنشئ البيانات الرئيسية وتتحكم فيها للجميع؟ المركزي.
أين يقع Data 360؟
Section titled “أين يقع Data 360؟ ”يبني Data 360 ملفات موحّدة عبر مصادر كثيرة، وهذا يشبه MDM كثيرًا، وهو بالفعل يحل جزءًا من المشكلة. فحل الهوية فيه يطابق الملفات المصدرية في هوية موحّدة ويحتفظ بالروابط إلى السجلات المصدرية (Data 360 Architecture (opens in a new tab)). وهذا يجعله أقرب ما يكون إلى السجل المركزي. ويمكنه أيضًا أن يعرض قيمًا مُسوّاة على الملف الموحّد. لكن ذلك لا يجعله نظام سجلات ذهبية مركزيًا يعيد كتابة المصادر. الرؤية الموحّدة ليست تلقائيًا سجلًا مؤسسيًا مُدارًا. والوحدة 4 كلها عن هذا الفرق.
النموذج المشترك ليس حقيقةً مشتركة
Section titled “النموذج المشترك ليس حقيقةً مشتركة ”ستسمع أيضًا عن نموذج البيانات القانوني (canonical data model). الحساب (Account) في Salesforce، وشريك الأعمال في ERP، والعميل في الفوترة، كلها تُربط بمفهوم مؤسسي واحد متفق عليه، العميل، بمعرّفات وسمات متفق عليها، كي لا يضطر كل تكامل إلى فهم شكل كل نظام آخر. ونموذج بيانات Data 360 مثال على توحيد المصادر في مفاهيم مشتركة. لكن النموذج القانوني يجيب عن كيف نمثّل هذا بشكل متسق؟ أما MDM فتجيب عن كيف نعرّفه ونحكمه وندير بياناته الرئيسية عبر الأنظمة؟ اربط الأنظمة الثلاثة ربطًا مثاليًا بشكل واحد للعميل، وسيظل Salesforce يقول 123 Main Street بينما يقول ERP إنه 125. لقد حللت البنية، لا المرجعية. التوحيد (harmonization) وإدارة البيانات الرئيسية ليسا قابلين للتبادل.
عمل واحد، وأنماط عدة
Section titled “عمل واحد، وأنماط عدة ”إذن «Steve Trucking تحتاج إلى MDM» ليست متطلبًا. لأي شيء؟ شركاء التجزئة، ومراكز التوزيع، والطواقم، والشاحنات، والمستلمون مجالات مختلفة بمرجعيات مختلفة: شركاء التجزئة يُحكَمون في Salesforce وفي ERP المالي، وهوية الشاحنة تأتي من FleetLink، وكل مستلم يزوّد به شريكٌ لكل توصيلة. يمكن للمجالات المختلفة أن تأخذ أنماطًا مختلفة، وداخل المجال الواحد يمكن أن تكون للسمات مرجعيات مختلفة. لذلك لا ترسم مربعًا موسومًا MDM في وسط المخطط وتعلن أن المشكلة حُلّت. اسأل ماذا يفعل المربع.
والأسلوب يغيّر التكامل أيضًا. السجل المركزي يحتاج إلى روابط هوية؛ والدمج إلى تدفقات واردة موثوقة؛ والتعايش إلى بيانات في الاتجاهين؛ والمركزي إلى توزيع من المصدر الرئيسي، مع ضوابط تمنع الأنظمة الأخرى من إنشاء حقيقة منافسة. وكلما زادت المرجعية زاد التنسيق، وزادت معه معالجة الفشل: ماذا لو غيّرت MDM الاسم القانوني ورفضه ERP؟ لهذا ليس التعايش والمركزي «سجلًا مركزيًا بميزات أكثر». إنهما يحملان مسؤوليات تشغيلية مختلفة.
MDM قرار عمل
Section titled “MDM قرار عمل ”النقطة الأهم: MDM ليست في جوهرها قرارًا تقنيًا. إنها قرار بشأن المرجعية. من يُنشئ العميل، ومن يحق له تغييره، ومن يقرر أيّ قيمة تفوز، وأيّ الأنظمة يجب أن تقبلها، وماذا يحدث حين تختلف. يمكن لأداة أن تنفّذ هذه القرارات؛ لكنها لا تستطيع أن تجعل المؤسسة تتفق عليها. لهذا يمكن أن يملك مشروع MDM تقنية ممتازة ثم يفشل: الفريق التقني حلّ المطابقة، والجهة المعنية لم تحل الملكية قط.
الدرس العام الذي تعلّمته بالطريقة الصعبة: حين تدير عدة أنظمة البيانات نفسها، لا يستطيع Salesforce أن يسوّي ما لا تتفق عليه هي. حين تشغّل شركة نظامَي ERP، أسأل كيف تبقيهما متزامنين. إن لم تستطع، فلن يستطيع Salesforce أيضًا. والوحدة 5 تروي تلك القصة (العميل الواحد في نظامَي ERP).
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”- هل تحتاج المشكلة إلى روابط هوية، أم إلى بيانات مجمّعة، أم إلى قيم مُدارة تُعاد، أم إلى إنشاء مركزي.
- أيّ نمط يناسب كل مجال بيانات، بدلًا من نمط واحد للمؤسسة كلها.
- كم من المرجعية تنالها طبقة الإدارة، وأيّ الأنظمة يجب أن تقبل قراراتها.
- هل يلزم نموذج قانوني، دون الخلط بين التوحيد والمرجعية.
- كيف يغيّر النمط المختار اتجاه التكامل والملكية ومعالجة الفشل.
حين يضع أحدهم مربع MDM على مخطط، اسأل ماذا يفعل. هل يعرف أيّ السجلات تنتمي معًا؟ هل يجمع بياناتها؟ هل يقرر أيّ القيم تفوز؟ هل يعيد تلك القرارات؟ هل يُنشئ البيانات أصلًا؟ الإجابات تخبرك بأي معمارية لديك فعلًا، وأين تعيش المرجعية.
للاستزادة
Section titled “للاستزادة ”- Salesforce Architects، Data 360 Architecture (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).