الخريطة ليست قرارًا
متاح أيضًا بـ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)
الوحدة 4 من 6 في فصل البيانات الرئيسية والهوية، الفصل 6 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: المطابقة والدمج وقواعد البقاء · التالي: عندما تكون المرجعية مشتركة
السؤال الذي تجيب عنه هذه الوحدة: هل الملف الموحّد هو الشيء نفسه الذي نسميه السجل الذهبي؟
العميل نفسه موجود في ثلاثة أنظمة. يعرف Salesforce الاسم Daniel Reyes، وd.reyes@example.com، ودالاس. وتعرف التجارة الإلكترونية Dan Reyes، بالبريد نفسه، ودالاس، تكساس. ويعرف الدعم Daniel Reyes، و214-555-0100، ودالاس. يقرر Data 360 أن الثلاثة هم الشخص نفسه ويبني ملفًا موحّدًا. ممتاز. هل لدينا سجل ذهبي؟ ليس بالضرورة. نحن نعرف أن السجلات تنتمي معًا؛ لكننا لم نقرر أيّ مصدر يملك الحقيقة. قد يربك هذا الناس: حل الهوية يُنشئ فردًا موحّدًا، لكنه لا يُنشئ سجلًا ذهبيًا. لذلك أدرّس الفرق مباشرة:
الملف الموحّد خريطة. والسجل الذهبي قرار.
حل الهوية يجيب عن «مَن؟»
Section titled “حل الهوية يجيب عن «مَن؟» ”بدون حل الهوية (identity resolution)، يظهر الشخص الواحد كملفات غير متصلة: يرى التسويق ملفًا، والمبيعات ملفًا آخر، والخدمة ثالثًا. يستوعبها Data 360 ويستخدم قواعد حل الهوية ليقرر أيّها ينتمي معًا. عندها نستطيع أن نقول هذه السجلات تبدو للشخص نفسه. هذا يحل مسألة الهوية. لكنه لا يحل مسألة إدارة البيانات الرئيسية.
والملف الموحّد يحتفظ بالخريطة إلى مصادره. وبحسب وصف Salesforce نفسها، الملف الموحّد ليس سجلًا ذهبيًا: إنه مجموعة من المفاتيح، مع كائنات روابط الهوية (identity link objects) التي تربط معرّف كل سجل مصدري بمعرّف الملف الموحّد (Data 360 Architecture (opens in a new tab)). الشخص الموحّد 10042 يُربط بجهة الاتصال 003… في Salesforce، وبعميل التجارة الإلكترونية EC-48372، وبعميل الدعم SUP-9128. والأصول لا تختفي. وهذا قريب جدًا من السجل المركزي في الوحدة 2.
الملف الموحّد خريطة تعود إلى هويات المصادر.
قواعد المطابقة: الصرامة قرار مخاطر
Section titled “قواعد المطابقة: الصرامة قرار مخاطر ”كيف يقرر Data 360 من يُوحَّد؟ قواعد المطابقة. تتطابق الملفات حين تتحقق كل المعايير في قاعدة، وإن كانت لديك عدة قواعد، فالتطابق في أيٍّ منها يُنشئ الملف الموحّد. وإرشاد Salesforce نفسها: استخدم معايير أكثر من أجل الدقة (ملفات متمايزة أكثر)، وأقل من أجل الدمج (Identity Resolution Match Rules (opens in a new tab)). إذن إضافة معايير إلى قاعدة تجعلها أكثر صرامة؛ وإضافة قواعد بديلة توسّع الطرق التي يمكن أن تتطابق بها الملفات. ضبط حل الهوية ليس «تشغيل المطابقة». إنه تحديد الدليل الكافي لنقول إن هذه الملفات شخص واحد.
المطابقة الأكثر ليست أفضل تلقائيًا. عشرة ملايين ملف مصدري تصبح ثمانية ملايين ملف موحّد. خفّف القواعد، فتصبح ستة ملايين. أفضل؟ ربما عثرت على تكرارات أكثر. أو ربما بدأت تجمع بين أشخاص مختلفين. العدد الأصغر ليس دليلًا على بيانات أفضل. الهدف ليس أقل عدد من الملفات؛ بل الهويات الأكثر قابلية للدفاع عنها في ضوء الغرض. ولكل معيار أسلوب مطابقة: Exact (مطابقة تامة)، أو Exact Normalized (مطابقة تامة بعد التطبيع)، أو Fuzzy (مطابقة تقريبية) بدقة عالية أو متوسطة أو منخفضة. وتحذير Salesforce نفسها هو بيت القصيد: الأسلوب الأقل دقة يرفع معدل الدمج، «لكنه قد يؤدي إلى مطابقات غير مرغوب فيها». (المطابقة التقريبية غير متاحة لحقول الحساب، والقيم المطبَّعة تُستخدم للمقارنة فقط؛ ولا تُخزَّن في الملف الموحّد، وهذه خطوة التوحيد من الوحدة 3 وهي تعمل: Identity Resolution Match Methods (opens in a new tab).) كلما كان الأسلوب أكثر تساهلًا، صارت الهوية نفسها حكمًا تقديريًا أكثر. فإن كانت خاطئة، فهل نكتفي بتخصيص صفحة بشكل سيئ، أم نعرض تاريخ دعم شخص لشخص آخر، أم ندع وكيلًا يتصرف في بيانات شخصين؟
هذا موقفي: صرامة المطابقة قرار مخاطر. إنها تعتمد على مدى تفرّد الحقول المطابَقة في تعريف الشخص، وعلى كلفة المطابقة الخاطئة. حيث يكون الخلط مكلفًا، طابِق بأقل من اللازم عن قصد. ملفان لشخص واحد أمر مزعج. أما ملف واحد يحمل شخصين فقد يكون خطيرًا.
التسوية ليست إدارةً للبيانات الرئيسية أيضًا
Section titled “التسوية ليست إدارةً للبيانات الرئيسية أيضًا ”بعد توحيد الملفات، تظل المصادر مختلفة: يقول Salesforce دالاس، والتجارة الإلكترونية بلانو، والدعم دالاس. ماذا يعرض الملف الموحّد؟ قواعد التسوية (reconciliation rules) هي التي تقرر: Last Updated (آخر تحديث)، أو Most Frequent (الأكثر تكرارًا)، أو Source Priority (أولوية المصدر)، وتُضبط لكل كائن ويمكن تجاوزها لكل حقل (Identity Resolution Reconciliation Rules (opens in a new tab)). وينبغي أن يذكّرك هذا بقواعد البقاء في الوحدة 3.
وهنا تقع الفرق في المتاعب. يعرض الملف الموحّد دالاس، فيقول أحدهم: «رائع، دالاس هي قيمتنا الذهبية.» تمهّل. التجارة الإلكترونية لا تزال تقول بلانو. وSalesforce صريحة في أن التسوية لا تحذف بيانات المصدر ولا تغيّرها ولا تحدّث الأنظمة المصدرية، وأنها ليست مصمَّمة لاختيار قيمة «فُضلى» لكل تطبيق. إنها تقرر فقط ما يعرضه الملف الموحّد (المصدر نفسه). العرض ليس مرجعية.
معلومة للاختبار. اعرف كيف يقرر حل الهوية في Data 360 وكيف يعرض: في قاعدة المطابقة، يجب أن تتطابق كل المعايير، وتطابق أيّ قاعدة واحدة يوحّد الملفات (معايير أكثر من أجل الدقة، وأقل من أجل الدمج)؛ وقواعد التسوية الثلاث هي Last Updated وMost Frequent وSource Priority، وتُضبط لكل كائن ويمكن تجاوزها لكل حقل؛ والتسوية لا تغيّر بيانات المصدر، ونقاط الاتصال لا تخضع للتسوية.
ونقاط الاتصال تجعل الفكرة أوضح. قد يكون للشخص بريد شخصي وبريد للعمل، وهاتف محمول وهاتف منزلي، وكلها مشروعة. ولا يُجري Data 360 أي تسوية على نقاط الاتصال: كل بريد وكل هاتف يبقى على الملف الموحّد (المصدر نفسه). أحيانًا تكون القيم المتعددة هي الحقيقة ببساطة. «موحّد» لا يعني قيمة واحدة لكل شيء.
السجل الذهبي قرار
Section titled “السجل الذهبي قرار ”قارن ذلك بمتطلب حقيقي لإدارة البيانات الرئيسية. تقول الجهة المعنية إن ERP هو المرجع المعتمد للاسم القانوني، والقيمة المُدارة هي «Oakline Logistics LLC». يجب أن يستخدمها Salesforce والفوترة والخدمة جميعًا، وإن خالفها أحدها، تعيد عملية الإدارة القيمة المحكومة إليه. هذه معمارية مختلفة. نحن لا نختار ما تعرضه رؤية واحدة؛ بل نقرر أن هذه هي القيمة التي تستخدمها المؤسسة، وكل نظام مشارك يتقارب نحوها.
إذن: الملف الموحّد يجمع الهويات والمعلومات معًا. والسجل الذهبي قرار محكوم بشأن أيّ القيم هي المعتمدة. يمكن للملف الموحّد أن يصنع رؤية واحدة ممتازة للعميل، مجمّعة من مصادر معتمدة. لكن هذا لا يجعله النظام الذي يدير العميل كبيانات رئيسية.
الملف الموحّد خريطة. والسجل الذهبي قرار.
إمكانية التتبّع
Section titled “إمكانية التتبّع ”إن قال الملف الموحّد دالاس، فمن أين جاءت: من Salesforce، أم ERP، أم التجارة الإلكترونية؟ هل اختيرت لأنها آخر تحديث، أم الأكثر تكرارًا، أم بأولوية المصدر؟ هذا الأصل مهم للتدقيق، والخصوصية، واستكشاف الأخطاء، وإصلاح جودة البيانات، وقرارات الوكلاء، وفوق كل ذلك لمعرفة أين ينبغي أن يحدث التصحيح. إن كانت دالاس خاطئة، فتحرير الرؤية المجمّعة لا يصلح المصدر. تحتاج إلى المعرّفات الخارجية، وروابط الهوية، وحقول سلسلة النَّسَب لتعود إلى السجل الذي ينبغي أن يتغير.
ثلاث أدوات لثلاث مهام
Section titled “ثلاث أدوات لثلاث مهام ”هكذا أفصل بينها:
- إدارة التكرارات والدمج، داخل org واحد في Salesforce، حين يكون هناك فائز واضح ولم تعد بحاجة إلى التكرارات (الوحدة 3).
- حل الهوية في Data 360، لهوية واحدة ورؤية واحدة عبر المصادر دون تغييرها: سجل مركزي.
- منصة MDM مخصصة، حين يجب أن تُحسَم القيم مرة واحدة وتُعاد إلى كل نظام مشارك: التعايش أو المركزي.
ثلاث أدوات لثلاث مهام: ادمج، اربط، أدِر.
لا تشترِ MDM حين تحتاج إلى خريطة. «نريد أن يرى وكيل الخدمة أن عميل Salesforce هذا هو الشخص نفسه الذي اشترى عبر الإنترنت» قد يحتاج إلى حل الهوية وسياق مجمّع، لا إلى MDM مركزي. أما «يجب أن يستخدم ERP وSalesforce والتجارة الإلكترونية والفوترة جميعًا الاسم القانوني المحكوم نفسه، ويجب أن تتدفق التغييرات عائدة إليها كلها» فشيء مختلف: هذه إدارة بيانات رئيسية. لا تحل الثاني حين يكون لديك الأول، ولا تتظاهر بأن الأول حلّ الثاني.
الهوية الواحدة ليست إذنًا واحدًا
Section titled “الهوية الواحدة ليست إذنًا واحدًا ”حل الهوية يقول إن هذه السجلات شخص واحد. وهذا لا يعني أن كل من يستطيع رؤية سجل مصدري واحد يحق له رؤية كل ما يرتبط بالهوية الموحّدة. قد يرى شريك التجزئة التوصيلات التي أرسلها؛ أما توصيلات شريك آخر إلى المستلم نفسه فليست من شأنه، حتى لو كانت طبقة الهوية تعرف أنها مرتبطة. يمكن أن يكون مخطط الهوية صحيحًا بينما تصميم الوصول خاطئ. توحيد الهوية لا يمحو الحدود الأمنية. لهذا تصبح المطابقة الزائدة مشكلة خصوصية، ولهذا تتعامل نقطة التحقق الخاصة بـ Steve Trucking مع توحيد المستلمين بحذر شديد: خريطة من هو من لا تمنح ملكية، ولا وصولًا.
ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. الوكلاء يحتاجون إلى هوية واحدة يعملون عليها، والملف الموحّد يعطيهم إياها. وهذا يرفع المخاطر في الاتجاهين. فالمطابقة الزائدة صارت حادثة خصوصية: وكيل يعمل لصالح شخص على بيانات شخص آخر. والوكيل الذي «يحدّث العميل» يجب أن يكتب في نظام السجل الخاص بالسمة، مستخدمًا خريطة المرجعية من الوحدة 1، لا في الملف الموحّد. الخريطة تخبر الوكيل من هو الشخص؛ ونموذج المرجعية يخبره أين ينتمي التغيير.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”- ما الدليل الكافي لتوحيد الملفات، وكيف تحدد كلفة المطابقة الخاطئة مستوى الصرامة.
- أيّ قواعد التسوية تقرر ما يعرضه الملف الموحّد.
- هل الحاجة تنظيف تكرارات داخل org واحد، أم هوية عبر المصادر، أم إدارة حقيقية للبيانات الرئيسية على مستوى المؤسسة.
- أيّ مصدر يبقى المرجع المعتمد لكل سمة، حتى حين يعرض Data 360 قيمة مُسوّاة.
- كيف تتفاعل الهوية الموحّدة مع الأمن والخصوصية ومصدر البيانات وأفعال الوكلاء.
يستطيع Data 360 أن يخبرنا بأن هذه الملفات تنتمي معًا، وأن يعطينا هوية موحّدة، وأن يسوّي ما يعرضه، وأن يحتفظ بالروابط إلى كل مصدر. هذا قيّم للغاية. لكن إن قال Salesforce شيئًا وقال ERP شيئًا آخر، فلا يزال على أحد أن يقرر أيّ نظام يحق له تغيير حقيقة المؤسسة. لذلك حين يقول أحدهم «لدينا ملف موحّد، إذن لدينا سجلنا الذهبي»، اسأل: هل وحّدنا البيانات، أم أدرناها كبيانات رئيسية؟
للاستزادة
Section titled “للاستزادة ”- Salesforce Architects، Data 360 Architecture (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).
- Salesforce Help، Data 360: Identity Resolution Match Rules (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).