المطابقة والدمج وقواعد البقاء
متاح أيضًا بـ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)
الوحدة 3 من 6 في فصل البيانات الرئيسية والهوية، الفصل 6 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: الطرق الأربع لإدارة البيانات الرئيسية · التالي: الخريطة ليست قرارًا
السؤال الذي تجيب عنه هذه الوحدة: كيف تعثر على التكرارات، وتقرر أيّ القيم تبقى؟
في Salesforce جهتا اتصال: Daniel Reyes، دالاس، d.reyes@example.com، وDan Reyes، دالاس، d.reyes@example.com. الشخص نفسه؟ على الأرجح. هل ينبغي أن ندمجهما؟ هذا سؤال مختلف. وإن فعلنا، فأيّ رقم هاتف وعنوان ومسمّى وظيفي يبقى؟ سؤال مختلف مرة أخرى. على المعماريين أن يفصلوا بين ثلاثة قرارات:
- المطابقة: هل تمثل هذه السجلات الشيء نفسه؟
- الدمج: هل ينبغي أن تصبح سجلًا واحدًا؟
- قواعد البقاء: إن جمعنا البيانات، فأيّ القيم تفوز؟
المطابقة أولًا
Section titled “المطابقة أولًا ”غطّى الفصل 3 قواعد التكرار وقواعد المطابقة في Salesforce، فلن أعيد شرح الآلية. السؤال المعماري هو ما الدليل القوي بما يكفي لنقول إن هذه قد تكون الشيء نفسه؟ للشخص: البريد الإلكتروني، أو الهاتف، أو الاسم مع العنوان، أو رقم عميل، أو مزيج منها. وللشركة: الاسم القانوني، أو الرقم الضريبي، أو معرّف العميل في ERP، أو العنوان، أو نطاق الموقع. ليس السؤال «هل يستطيع Salesforce مقارنة هذه الحقول؟» بل «أيّ مزيج يعطينا ثقة كافية لنتصرف؟»
والتطابق التام ليس يقينًا. البريد الإلكتروني المشترك إشارة قوية، لا برهان: العائلات تتشارك العناوين، والشركات تستخدم purchasing@company.com، وأرقام الهواتف تخص أسرًا كاملة، والأسماء والعناوين ليست فريدة، وحتى المعرّفات القوية يُعاد استخدامها أو تُكتب خطأً أو تُدوَّر. المطابقة ليست مقارنة نصوص. إنها تصريح عن الهوية.
كلفة الخطأ
Section titled “كلفة الخطأ ”حين أدرّس هذا، أغيّر المجال. في بيانات تسويق السيارات، نقرر خطأً أن شخصين باسم Daniel Reyes هما الشخص نفسه، فيتلقى الشخص الخطأ عرضًا لسيارة SUV. ليس جيدًا، لكنه منخفض المخاطر. والآن ارتكب المطابقة الخاطئة نفسها في بيانات طبية: يُدمج التاريخ الطبي لشخصين مختلفين. خطأ المطابقة نفسه، وعاقبة مختلفة تمامًا. لهذا لا توجد عتبة مطابقة «جيدة» عالمية. أحيانًا يكون الخطر الأكبر أن تفوتك مطابقة؛ وأحيانًا أن تجمع بين شخصين ليسا الشخص نفسه. حيث تكون المطابقات الخاطئة مكلفة، أطابِق بأقل من اللازم عن قصد.
وحّد الصيغ، ثم طابِق، ثم اجمع
Section titled “وحّد الصيغ، ثم طابِق، ثم اجمع ”المطابقة تعتمد أيضًا على شكل البيانات. AZ، وArizona، وAriz.؛ و6025550198، و(602) 555-0198، و+1 602 555 0198. التوحيد (harmonization) يجعل القيم قابلة للمقارنة: صيغ قياسية، واختصارات موحّدة، ورموز مربوطة. ثم تطابِق. ولا تجمع (consolidate) معلوماتها في تمثيل واحد إلا بعد أن يُعرف أن السجلات تنتمي معًا. التوحيد ليس مطابقة، والمطابقة ليست دمجًا، والجمع ليس بالضرورة إدارةً للبيانات الرئيسية.
قرارات الهوية تحدث على مراحل.
المطابقة لا تستلزم الدمج
Section titled “المطابقة لا تستلزم الدمج ”هذا من أهم الفروق في الفصل. نحن واثقون بأن سجلَّي عميل من نظامين قديمين يمثلان الشركة نفسها. هل يجب أن ندمجهما؟ لا. فقد يحمل كلٌّ منهما هوية نظامه المصدر؛ وقد تشير معاملات تاريخية إلى كلٍّ منهما؛ وقد يحتاج المدققون إلى الأثر؛ وقد نكون لا نزال في منتصف الترحيل؛ وقد نحتاج إلى معرفة ما قاله النظام القديم بالضبط. معرفة أن سجلين يمثلان الشيء نفسه لا تجبرنا على طيّهما في سجل واحد. يمكننا أن نربطهما، وهذه في الغالب المعمارية الأكثر أمانًا.
قاعدتي في الدمج: فائز واضح
Section titled “قاعدتي في الدمج: فائز واضح ”موقفي: لا تدمج إلا حين يكون هناك فائز واضح، والسجل المكرر لا يضيف شيئًا تحتاج إلى الاحتفاظ به. أنشأ مندوب حسابًا مكررًا أمس؛ والأصلي هو بوضوح السجل الراسخ. مرشح جيد للدمج. والآن غيّر المثال: استوردنا عملاء من نظام قديم، بمعرّفاته الخاصة، وقيم أقدم، وربما معاملات أو متطلبات تدقيق مرتبطة بها. هنا أكون أكثر حذرًا بكثير. احتفظ بالتكرارات القادمة من التحميلات الخارجية حين قد تحتاج إلى تتبّع القيم الأقدم، لأن الدمج يمحو ذلك التاريخ.
ما الذي يفعله الدمج في Salesforce فعلًا
Section titled “ما الذي يفعله الدمج في Salesforce فعلًا ”الربط يقول «هذه تنتمي معًا». والدمج يقول «هذه صارت واحدًا»، وهو في Salesforce تغيير حقيقي. للحسابات، تختار حتى ثلاثة سجلات وتجعل أحدها الرئيسي (principal)؛ وتختار أيّ قيم الحقول من السجلات الأخرى تحتفظ بها، بينما تأتي الحقول المخفية وحقول القراءة فقط من السجل الرئيسي. ويحتفظ السجل المدموج بـ Created By وCreated Date الخاصين بأقدم سجل، أيًّا كان الرئيسي. السجلات غير الرئيسية تذهب إلى سلة المحذوفات (Recycle Bin). والسجلات المرتبطة كالأنشطة تنتقل إلى السجل المدموج، مع استثناءات. وفي Lightning، يعمل الدمج على التكرارات التي تكتشفها قواعد التكرار لديك. وبالنسبة للحسابات الشخصية، كائنات نقاط الاتصال (contact point objects) لا تدعم الدمج: فتضيع علاقاتها (Considerations for Merging Duplicate Accounts (opens in a new tab)؛ Merge Duplicate Accounts in Lightning Experience (opens in a new tab)).
معلومة للاختبار. اعرف ما يفعله دمج الحسابات في Salesforce: حتى ثلاثة سجلات؛ وسجل رئيسي واحد تُحفظ حقوله المخفية وحقول القراءة فقط فيه؛ وCreated By وCreated Date الخاصان بأقدم سجل، أيًّا كان الرئيسي؛ والسجلات الأخرى تذهب إلى سلة المحذوفات (Recycle Bin)؛ وبالنسبة للحسابات الشخصية، كائنات نقاط الاتصال لا تُدمج.
لا تحتاج إلى كل حالة طرفية لتتخذ القرار. تحتاج إلى العاقبة: بعد الدمج، تختفي السجلات المستقلة التي بدأت بها. وهنا ينطبق اختبار قابلية التراجع من الفصل 1: الربط سهل التراجع عنه؛ والدمج ليس كذلك. ونادرًا ما يقف العميل وحده: جهات الاتصال، والحالات، والفرص، والملفات، وسجلات الموافقة، والسجلات الفرعية المخصصة، والمعرّفات الخارجية، ومراجع التكامل. قبل دمج السجل الأب، افهم ما يحدث لكل ما هو مرتبط به. حين تأتي التكرارات مع عملية تحميل، أعطي الفرق ثلاثة خيارات للسجلات الفرعية: انقلها إلى السجل الباقي؛ أو لا تحمّلها أصلًا، إن لم يكن أحد بحاجة إليها؛ أو أبقها على السجل الآخر، مع وسمه بأنه غير نشط، كي تظل تظهر في البحث. الخيار الأول هو ما يفعله الدمج لك. والخياران الآخران يحفظان الأثر، وهذا في الغالب هو المقصود.
قواعد البقاء: أيّ قيمة تفوز؟
Section titled “قواعد البقاء: أيّ قيمة تفوز؟ ”السجلات تنتمي معًا، لكنها تختلف: يقول Salesforce والفوترة 602-555-0100، ويقول ERP 602-555-0188. قواعد البقاء (survivorship) تختار الفائز. أشيعها: الأحدث (آخر تحديث)، والأكثر تكرارًا (القيمة التي تتفق عليها معظم المصادر)، وأولوية المصدر (ثق بهذا المصدر أكثر من ذاك)، إلى جانب التركيبات والعتبات والأوزان والقواعد الخاصة بكل عمل. ولا واحدة منها صحيحة في ذاتها.
«الأحدث» ليس إعدادًا تقنيًا. إنه تصريح عن الثقة: حين تختلف الأنظمة، فالقيمة الأحدث هي الأرجح صحةً. معقول لرقم هاتف محمول. وكارثي لاسم قانوني: إن كان ERP يملكه، فلا يهمني أن أحدهم غيّر نسخة Salesforce قبل خمس دقائق. و«الأكثر تكرارًا» يفترض أن الاتفاق دليل، لكن ثلاث نسخ قديمة في أنظمة لاحقة لا تتغلب بالأصوات على نظام السجل. و«أولوية المصدر» تقولها صراحة: نثق بهذا المصدر أكثر. لذلك تنتمي قواعد البقاء إلى المعمارية والحوكمة، وكل قاعدة تحتاج إلى مالك. من قرر أن أحدث عنوان يفوز، أو أن ERP يتقدم على Salesforce؟
إن كانت خريطة المرجعية في الوحدة 1 تقول أصلًا إن ERP يملك حد الائتمان، فقواعد البقاء سهلة: ERP يفوز، ولا حاجة إلى تسجيل نقاط ذكي. الحالات الصعبة هي السمات التي تكون مرجعيتها مشتركة، أو غير واضحة، أو مبنية على الأدلة بدلًا من مصدر رئيسي واحد. وهناك تثبت قواعد البقاء قيمتها.
قواعد البقاء تصريحات عن الثقة.
العتبات والمراجعة والإثراء
Section titled “العتبات والمراجعة والإثراء ”بعض المطابقة يزن الأدلة: تطابق معرّف العميل قوي جدًا، والبريد الإلكتروني قوي، والهاتف متوسط، والاسم المتشابه ضعيف، والعنوان المتشابه داعم. فوق درجة معينة، تطابق؛ وتحت درجة أخرى، اختلاف؛ وبينهما، يراجعه إنسان. الخوارزمية ليست الدرس. العتبة هي مدى تحمّلك للخطأ، وينبغي أن تتبع مخاطر العمل. وحين تطرح الأدلة السؤال دون أن تحسمه، لا تتظاهر بأن النظام يعرف. أرسله للمراجعة. أبطأ، ولا بأس بذلك: الأتمتة لا قيمة لها حين تدمج بثقة عميلين مختلفين.
والإثراء يضيف سؤالًا آخر عن مصدر البيانات. بيانات العناوين البريدية المرجعية، ورموز القطاعات، وبيانات الشركات، ودرجات المخاطر الخارجية تحسّن البيانات الرئيسية، لكن من أين جاءت كل قيمة، وما مدى موثوقيتها وحداثتها، وهل يجوز لنا استخدامها لهذا الغرض، وهل تحمل بيانات شخصية؟ «القطاع = النقل» من مزوّد بيانات ليس كأن يخبرك العميل بذلك. حافظ على هذا التمييز.
Steve Trucking: التشابه ليس تطابقًا
Section titled “Steve Trucking: التشابه ليس تطابقًا ”يرسل شريكا تجزئة توصيلات إلى John Smith، 123 Main Street، كولومبس، برقم الهاتف نفسه. الشخص نفسه؟ على الأرجح. هل ينبغي أن توحّدهما Steve Trucking؟ تذكّر لمن هما: أولئك المستلمون عملاء الشركاء، ويجب ألا يرى شريك أبدًا عملاء شريك آخر. المطابقة الخاطئة ستخلط البيانات عبر ذلك الحد. وفجأة لم يعد السؤال عن جودة البيانات بل عن الخصوصية والعزل، وهذا بالضبط سبب اعتماد العتبات على العواقب. نقطة التحقق تحسم القرار. أما الآن: لا تدع سهولة المطابقة تتخذ قرار العمل.
أحيانًا يخبرك الإبقاء على الفوضى بشيء. هذا السجل جاء من النظام القديم، وذاك من Salesforce، وهذا من الشركة المستحوَذ عليها؛ وقد تكون معرّفاتها وتاريخها وحقيقة أنها اختلفت كلها مهمة. البيانات النظيفة قيّمة. وكذلك إمكانية التتبّع. والمعماري يقرر أيهما أهم للاستخدام المقصود.
ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. كانت المطابقة السيئة تعني رسالتين بالبريد الإلكتروني أو تاريخ خدمة مجزّأً. أما الآن فيعثر الوكيل على ما يظنه العميل ويسحب طلباته وحالاته وعناوينه وملاحظاته. فإن طوبق شخصان خطأً، فقد يتصرف بناءً على معلومات شخص لصالح شخص آخر. لقد أصبح قرار المطابقة جزءًا من الحد الأمني، وحيث يكون الخلط مكلفًا، فالمطابقة الأكثر صرامة هي التصميم الأكثر أمانًا.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”- ما الدليل الكافي للإشارة إلى تكرار محتمل في كل مجال بيانات.
- هل تصبح المطابقة المؤكدة دمجًا، أم ربطًا، أم مراجعة بشرية.
- أيّ القيم تبقى عند الاختلاف، ومن يملك كل قاعدة من قواعد البقاء.
- كم من مخاطر المطابقة الخاطئة يستطيع العمل تحمّله، مقابل مخاطر المطابقة الفائتة.
- أيّ هويات المصادر وتاريخها وسجلاتها المرتبطة يجب حفظها قبل أي دمج.
طابِق بعناية، وادمج عن قصد، واختر قواعد البقاء عن وعي. سجل العميل النظيف لا يساوي الكثير إن وصلت إليه بدمج العملاء الخطأ.
للاستزادة
Section titled “للاستزادة ”- Salesforce Help، Considerations for Merging Duplicate Accounts (opens in a new tab) وMerge Duplicate Accounts in Lightning Experience (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).
- Salesforce Help، Things to Know About Duplicate Rules (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).