الربط ليس إدارةً للبيانات الرئيسية

🌐 متاح أيضًا بـ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)

ترجمة بالذكاء الاصطناعي. لم يراجعها المجتمع بعد. اقرأ بالإنجليزية

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

«نحتاج إلى مصدر واحد للحقيقة.» إنها من أكثر العبارات تكرارًا في المعمارية، ومن أقلها تمحيصًا. للحقيقة في ماذا؟ خذ حسابًا واحدًا. قد يملك نظام ERP اسمه القانوني وعنوان الفوترة وحد الائتمان؛ ويملك Salesforce مسؤول الحساب ومستوى الدعم؛ وتملك منصة الموافقة تفضيلاته التسويقية. ثلاث مرجعيات على سجل واحد، وهذا أمر طبيعي. لذلك حين يقول أحدهم «Salesforce هو مصدرنا الوحيد للحقيقة عن العميل»، يكون سؤالي التالي دائمًا: أيّ حقيقة؟

هذا الفصل عن الإجابة عن هذا السؤال عن قصد. المرجعية تُحدَّد سمةً سمة. وربط السجلات ليس إدارةً لها كبيانات رئيسية. ويمنحك Salesforce أدوات مختلفة لمهام مختلفة: إدارة التكرارات والدمج داخل الـ org الواحد؛ وحل الهوية (identity resolution) في Data 360 لرؤية واحدة عبر المصادر؛ ومنصة MDM مخصصة حين يجب أن تُحسَم القيم مرة واحدة ثم تُعاد إلى كل مكان. وينتهي الفصل بـ نقطة التحقق 1، حيث يجتمع الجزء 1 كله على Steve Trucking.

صورة مُنشأة بالذكاء الاصطناعي.

المواقف في هذا الفصل

• الحقيقة لكل سمة. اسأل أين تُنشأ كل قطعة من البيانات، وأين تُحرَّر، وأين يُرجَع إليها، وبأي سرعة تتغير. وأظهِر المرجعية الخارجية في المخطط ببادئة تدل على النظام، مثل sap_ أو erp_.
• العملاء المحتملون حالة مختلفة. فهم يعيشون في Salesforce قبل أن يعرفهم نظام ERP؛ ومرجعية ERP تسري بعد التحويل.
• السجل المركزي (registry) هو القاعدة في مشاريع Salesforce، يليه الدمج (consolidation) والتعايش (coexistence)؛ أما MDM المركزي الخالص فنادر.
• لا تدمج إلا حين يكون هناك فائز واضح. احتفظ بالتكرارات القادمة من التحميلات الخارجية إن كنت قد تحتاج إلى تتبّعها إلى أصلها؛ فالدمج يمحو ذلك التاريخ. وقرّر ما يحدث للسجلات الفرعية: انقلها، أو لا تحمّلها، أو أبقها على سجل غير نشط.
• الملف الموحّد خريطة؛ والسجل الذهبي قرار. قد يربك هذا الناس: حل الهوية يُنشئ فردًا موحّدًا، لكنه لا يُنشئ سجلًا ذهبيًا.
• صرامة المطابقة قرار مخاطر. حيث يكون خلط الأشخاص مكلفًا، طابِق بأقل من اللازم عن قصد.
• ثلاث أدوات لثلاث مهام: الدمج، وحل الهوية، وMDM.
• التسلسلات الهرمية موزّعة المرجعية. قرّر المرجعية فرعًا فرعًا.
• «أصعب شيء هو التكاملات ثنائية الاتجاه.» التكامل ثنائي الاتجاه لا يصنع مرجعيتين. قرّر أي الحقول تنتقل معًا كمعاملة واحدة قبل أول تصادم.
• اجعل البيانات الرئيسية مرئية. الحقل الذي يقول إن هذه بيانات رئيسية (مفتاح ERP أو علامة) هو ما يحدد قابلية التحرير، لا نوع السجل.
• نحن لا نتحكم في أنظمة ERP. بل نتحكم في طريقة تمثيلها في Salesforce: العميل الواحد في نظامَي ERP إما تسلسل هرمي، أو نظيران، أو حساب واحد له سجل فرعي لكل ERP، ويحسم ذلك مدى إحكام العميل لمزامنة أنظمة ERP لديه.

ثلاث أدوات لثلاث مهام

المهمة	الأداة	ما تفعله بالمصادر
تكرارات داخل org واحد، مع فائز واضح	إدارة التكرارات والدمج	تدمج حتى ثلاثة سجلات؛ ويذهب الباقي إلى سلة المحذوفات (Recycle Bin)
هوية واحدة ورؤية واحدة عبر المصادر	حل الهوية في Data 360	تربطها؛ ولا تغيّر أيًّا منها (سجل مركزي)
قيمة واحدة محكومة، تُعاد إلى كل نظام	منصة MDM مخصصة	تحسم القيمة وتوزّعها (التعايش أو المركزي)

المسار عبر هذا الفصل

ست وحدات وتحدٍّ، كلٌّ منها قائم بذاته.

1. مصدر واحد للحقيقة لكل سمة. خريطة المرجعية، والسجل الذهبي الهجين، وإشارات الثقة.
2. الطرق الأربع لإدارة البيانات الرئيسية. السجل المركزي والدمج والتعايش والمركزي، ولماذا لا يعني النموذج المشترك حقيقةً مشتركة.
3. المطابقة والدمج وقواعد البقاء. كلفة المطابقة الخاطئة، وما يفعله الدمج في Salesforce فعلًا (وما يحدث للسجلات الفرعية)، وقواعد البقاء بوصفها تصريحًا عن الثقة.
4. الخريطة ليست قرارًا. قواعد المطابقة وأساليبها، وقواعد التسوية (reconciliation)، ولماذا لا يكون الملف الموحّد سجلًا ذهبيًا.
5. عندما تكون المرجعية مشتركة. الطلبات مقابل التحديثات، والحلقات والتصادمات، والتسلسلات الهرمية موزّعة المرجعية، والعميل الواحد في نظامَي ERP.
6. تحدي نقطة التحقق 1، ثم نقطة التحقق 1: Steve Trucking، كيف كنت سأصمّمها. جرّب التحدي أولًا: ارسم تصميم الجزء 1 ودافع عنه، ثم قارنه بتصميمي، وانظر ما الذي يتغير عن خريطة الأنظمة في الفصل 4.

حين تنتهي، اختبر نفسك بـ دليل دراسة الفصل: قائمة تحقق للاختبار، والعادات التي تتجاوزه، والمصطلحات التي يجب معرفتها، وبضعة أسئلة. وهو يختم الجزء 1؛ أما دليل دراسة الجزء 1 فيجمع الفصول الستة معًا.

ما الذي يقرره المعماري هنا

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

ما بعد الاختبار: الوكلاء يحتاجون إلى هوية واحدة يعملون عليها، وهذا يرفع المخاطر في الاتجاهين. فالمطابقة الزائدة تصبح حادثة خصوصية، والوكيل الذي «يحدّث العميل» عليه أن يكتب في نظام السجل (system of record) الخاص بكل سمة، لا في الملف الموحّد. وتنتهي كل وحدة بما يغيّره الذكاء الاصطناعي.

للاستزادة

• Salesforce Architects، Data 360 Architecture (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).
• Salesforce Help، Considerations for Merging Duplicate Accounts (opens in a new tab) وIdentity Resolution Match Methods (opens in a new tab) وIdentity Resolution Reconciliation Rules (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).

التالي: يبدأ الجزء 2 بـ التصميم للنطاق الواسع (coming soon).