البيانات الرئيسية والهوية
متاح أيضًا بـ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؛ هذه الصفحة تساعدك على التحقق مما رسخ في ذهنك.
عن دليل الدراسة هذا. بُني فقط من محتوى هذه الدورة نفسها ومن قائمة الأهداف في دليل الاختبار الذي نشرته Salesforce. لا يستند أبدًا إلى أسئلة اختبار حقيقية، ولا يدّعي معرفة ما في الاختبار. إن كنت قد أدّيت الاختبار، فأرجو ألا ترسل إليّ أسئلة منه: اتفاقية الشهادة تمنع مشاركتها، وحفظ الإجابات طريقة خاطئة لتصبح معماريًا على أي حال.
يحمل هذا الفصل قسم Master Data Management (إدارة البيانات الرئيسية) في الاختبار (5%) والرؤية الواحدة للعميل من Salesforce Data Management. إنه قسم صغير من حيث الوزن، لكن أفكاره (المرجعية، والمطابقة، وقواعد البقاء) تظهر داخل سيناريوهات كثيرة أخرى. أرقام المنصة تتغير، فتحقق من الأرقام الحالية قبل أن تعتمد عليها.
من أجل الاختبار
Section titled “من أجل الاختبار ”ضع علامة على كل بند وأنت تتقدم. كل بند يحيلك إلى المكان الذي يُشرح فيه.
MDM-2: السجل الذهبي ونظام الحقيقة
- أعرف أن المرجعية تُحدَّد لكل سمة، لا لكل سجل: يمكن أن يكون لحساب واحد حقول تُدار في ERP وحقول تُدار في Salesforce. (الحقيقة تنتمي إلى السمة)
- أسأل أين تُنشأ كل سمة، وأين تُحرَّر، وأين يُرجَع إليها، وما زمن تغيّرها. (أين تُنشأ، وأين تُحرَّر، وأين يُرجَع إليها، وبأي سرعة؟)
- أستطيع بناء خريطة مرجعية، وأعرف أن مالك العمل والنظام المرجعي المعتمد ليسا الشيء نفسه. (ابنِ خريطة المرجعية)
- أعرف أن المرجعية يمكن أن تتغير عبر دورة الحياة (عميل محتمل في Salesforce يصبح عميلًا يحكمه ERP)، وأن النسخة ليست مرجعية. (المرجعية تتغير عبر دورة الحياة، النسخة ليست مرجعية)
MDM-1: تقنيات MDM
- معلومة للاختبار: أعرف أساليب تنفيذ MDM الأربعة، السجل المركزي والدمج والتعايش والمركزي: ما الذي يركّزه كلٌّ منها، وهل يعيد القيم. (الأربعة جنبًا إلى جنب)
- أستطيع التمييز بين أساليب MDM الأربعة: السجل المركزي، والدمج، والتعايش، والمركزي، واختيار أخفها الذي يحل المشكلة. (الأربعة جنبًا إلى جنب)
- أعرف أن نموذج البيانات القانوني يوحّد البنية، لكنه لا يحسم المرجعية. (النموذج المشترك ليس حقيقةً مشتركة)
- أعرف الترتيب: وحّد الصيغ، ثم طابِق، ثم اجمع. (وحّد الصيغ، ثم طابِق، ثم اجمع)
- أعرف أن العتبات تعكس مدى تحمّل الخطأ، وأن الإثراء يحتاج إلى معرفة مصدر البيانات. (العتبات والمراجعة والإثراء)
- معلومة للاختبار: أعرف إدارة التسلسلات الهرمية: Parent Account يبني التسلسل الهرمي (عرض Lightning يعرض حتى 2,000 حساب، دون الحسابات الشخصية)، والتسلسلات الهرمية غالبًا موزّعة المرجعية، ويمكن أن يكون للشركة عدة تسلسلات هرمية صحيحة. (التسلسلات الهرمية بيانات رئيسية أيضًا، تسلسل هرمي واحد، ومصادر رئيسية عدة)
MDM-3: اختيار السمات الفائزة
- أفصل بين المطابقة والدمج وقواعد البقاء. (المطابقة والدمج وقواعد البقاء)
- أعرف قواعد البقاء: الأحدث، والأكثر تكرارًا، وأولوية المصدر، وأن كل قاعدة تحتاج إلى مالك. (قواعد البقاء: أيّ قيمة تفوز؟)
- أعرف أن المطابقة لا تستلزم الدمج، ولا أدمج إلا حين يكون هناك فائز واضح، بعد أن أقرر أولًا ما يحدث للسجلات الفرعية. (المطابقة لا تستلزم الدمج، قاعدتي في الدمج: فائز واضح)
- معلومة للاختبار: أعرف ما يفعله دمج الحسابات في Salesforce: حتى ثلاثة سجلات، وسجل رئيسي واحد، والاحتفاظ بـ Created By وCreated Date الأقدم، وذهاب البقية إلى سلة المحذوفات (Recycle Bin)، وعدم دمج كائنات نقاط الاتصال في الحسابات الشخصية. (ما الذي يفعله الدمج في Salesforce فعلًا)
SDM-3: الرؤية الواحدة للعميل
- أعرف أن حل الهوية في Data 360 يربط الملفات المصدرية في ملف موحّد ويحتفظ بالروابط إليها: وهذا أقرب ما يكون إلى السجل المركزي. (حل الهوية يجيب عن «مَن؟»)
- معلومة للاختبار: أعرف قواعد المطابقة في Data 360: يجب أن تتطابق كل المعايير في القاعدة، ويمكن لأي قاعدة أن تُحدث التطابق؛ معايير أكثر من أجل الدقة، وأقل من أجل الدمج. (قواعد المطابقة)
- أعرف أساليب المطابقة (Exact وExact Normalized وFuzzy بثلاث درجات دقة): الأسلوب الأقل دقة يرفع معدل الدمج، ويرفع معه خطر المطابقات الخاطئة. (قواعد المطابقة)
- معلومة للاختبار: أعرف أن قواعد التسوية (Last Updated وMost Frequent وSource Priority) تقرر ما يعرضه الملف الموحّد، لكنها لا تغيّر المصادر؛ ونقاط الاتصال لا تخضع للتسوية. (التسوية ليست إدارةً للبيانات الرئيسية أيضًا)
- أستطيع الاختيار بين إدارة التكرارات وحل الهوية ومنصة MDM مخصصة بحسب المهمة. (ثلاث أدوات لثلاث مهام)
MDM-4 والبيانات ثنائية الاتجاه
- أعرف أن البيانات ثنائية الاتجاه لا تعني مرجعيتين: تعديل Salesforce لحقل يملكه ERP هو طلب، لذا أصمّم طلب ← تحقق ← قبول ← نشر، مع حالة «قيد الانتظار». (البيانات ثنائية الاتجاه لا تعني مرجعيتين، حين يقول المصدر الرئيسي لا)
- أعرف كيف أتجنب الحلقات والتصادمات: أميّز التغيير الأصلي من صداه، وأقرر أيّ الحقول تنتقل معًا كـ معاملة واحدة. (الحلقات والتصادمات)
- للعميل الواحد في نظامَي ERP، أستطيع الاختيار بين تسلسل هرمي، أو حسابات نظيرة، أو حساب واحد مع سجل فرعي لكل ERP، بحسب مدى إحكام العميل لمزامنة أنظمة ERP لديه. (العميل الواحد في نظامَي ERP، اسأل كيف يبقون أنظمة ERP متزامنة)
نقطة التحقق 1: جمع الجزء 1 معًا
- معلومة للاختبار: أعرف أيّ التراخيص الخارجية تحمل المشاركة القياسية: Customer Community Plus وPartner Community، وتحتاجان إلى أدوار للمستخدمين الخارجيين؛ أما Customer Community فيستخدم مجموعات المشاركة (sharing sets). (من يرى ماذا، ومن يحتاج إلى ترخيص)
ما بعد الاختبار
Section titled “ما بعد الاختبار ”الاختبار هو الحد الأدنى، لا السقف. هذه هي العادات التي يحتاج إليها المعماري من هذا الفصل، سواء سأل عنها سؤال يومًا أم لا.
- «مصدر واحد للحقيقة»: أيّ حقيقة؟ إنها معمارية للحقيقة، لا سجل واحد.
- اجعل المرجعية مرئية في المخطط: بادئة للحقول التي يملكها نظام آخر.
- الثقة تحتاج إلى أكثر من قيمة: المصدر، وآخر تأكيد، ومن غيّرها.
- ابدأ بالمشكلة، لا بمنتج MDM. MDM قرار عمل بشأن المرجعية.
- الربط ليس إدارةً للبيانات الرئيسية.
- حيث تكون المطابقات الخاطئة مكلفة، طابِق بأقل من اللازم عن قصد.
- احتفظ بالتكرارات القادمة من التحميلات الخارجية حين قد تحتاج إلى تتبّعها إلى أصلها.
- الملف الموحّد خريطة. والسجل الذهبي قرار.
- العرض ليس مرجعية.
- توحيد الهوية لا يمحو الحدود الأمنية.
- أصعب شيء هو التكاملات ثنائية الاتجاه. المرجعية المشتركة ليست المشكلة؛ المرجعية الملتبسة هي المشكلة.
- لا تدع أبدًا طلبًا مرفوضًا يتحول إلى حقيقة منافسة.
- الحقل الذي يقول إن هذه بيانات رئيسية هو ما يحدد قابلية التحرير، لا نوع السجل.
- نحن لا نتحكم في أنظمة ERP. بل نتحكم في طريقة تمثيلها في Salesforce.
مصطلحات يجب معرفتها
Section titled “مصطلحات يجب معرفتها ”| المصطلح | في سطر واحد |
|---|---|
| إدارة البيانات الرئيسية (MDM) | تحديد الهوية والقيم المعتمدة للبيانات الأساسية عبر الأنظمة، وحوكمتها |
| خريطة المرجعية (authority map) | لكل سمة: من يُنشئها، ومن يملك القرار، وأيّ نظام هو المرجعي المعتمد، ومن يحق له تغييرها |
| السجل الذهبي | قرار محكوم بشأن أيّ القيم هي المعتمدة |
| السجل الذهبي الهجين | سجل بعض سماته تُدار في مكان آخر وتُنسخ إليه، وبعضها مملوك محليًا |
| السجل المركزي (registry) | أسلوب MDM يربط السجلات بوصفها الكيان نفسه دون تغيير المصادر |
| الدمج (consolidation) | أسلوب MDM يجمع البيانات مركزيًا، للتحليلات في الغالب، دون إعادتها |
| التعايش (coexistence) | أسلوب MDM يقرر القيمة المُدارة وينشرها عائدة إلى المصادر |
| MDM المركزي | أسلوب MDM تُنشأ فيه البيانات المحكومة في المصدر الرئيسي وتُوزَّع |
| نموذج البيانات القانوني (canonical data model) | شكل مؤسسي متفق عليه لمفهوم ما، يُستخدم لربط الأنظمة بعضها ببعض |
| التوحيد (harmonization) | جعل القيم قابلة للمقارنة: صيغ ورموز واختصارات قياسية |
| المطابقة | تقرير ما إذا كانت السجلات تمثل الشيء نفسه |
| قواعد البقاء (survivorship) | قواعد تحدد أيّ قيمة تفوز حين تختلف المصادر |
| السجل الرئيسي (principal record) | في الدمج في Salesforce، السجل الذي يبقى ويحتفظ بحقوله المخفية وحقول القراءة فقط |
| أسلوب المطابقة (match method) | طريقة مقارنة معيار المطابقة في Data 360 للقيم: مطابقة تامة، أو تامة بعد التطبيع، أو تقريبية |
| حل الهوية (identity resolution) | مطابقة Data 360 للملفات المصدرية في ملفات موحّدة |
| الملف الموحّد | مجموعة من المفاتيح تربط سجلات مصدرية تمثل شخصًا واحدًا أو شركة واحدة |
| قواعد التسوية (reconciliation rules) | قواعد Data 360 التي تحدد أيّ قيمة يعرضها الملف الموحّد |
| التسلسل الهرمي موزّع المرجعية | تسلسل هرمي تملك فروعَه أنظمةٌ مختلفة |
اختبر نفسك
Section titled “اختبر نفسك ”سيناريوهات قصيرة على نمط الدورة. حدّد إجابتك قبل أن تفتحها.
1. «Salesforce هو مصدرنا الوحيد للحقيقة عن العميل.» ماذا تسأل؟
أيّ حقيقة؟ المرجعية لكل سمة: قد يملك ERP الاسم القانوني وعنوان الفوترة وحد الائتمان بينما يملك Salesforce مسؤول الحساب ومستوى النجاح. ابنِ خريطة مرجعية. أعد قراءة الحقيقة تنتمي إلى السمة.
2. يحتاج وكلاء الخدمة إلى أن يروا أن جهة اتصال في Salesforce هي الشخص نفسه الذي اشترى عبر الإنترنت. ولا أحد يحتاج إلى تغيير الأنظمة. أيّ أسلوب MDM؟
السجل المركزي: اربط السجلات كهوية واحدة دون تغيير المصادر، وهذا ما يفعله حل الهوية في Data 360. اختر أخف نمط يحل المشكلة. أعد قراءة السجل المركزي: أخبرني من هو من.
3. ضُبطت قواعد البقاء على «الأحدث يفوز» لكل حقل. يغيّر أحدهم نسخة Salesforce من الاسم القانوني الذي يملكه ERP. ماذا يحدث، وما الخطأ؟
القيمة الأحدث تفوز، فتتغلب النسخة على المرجعية. «الأحدث» تصريح عن الثقة يناسب بعض السمات (رقم الهاتف المحمول) ولا يناسب أخرى. وحيث تقول خريطة المرجعية إن ERP يملك الحقل، يفوز ERP. أعد قراءة قواعد البقاء: أيّ قيمة تفوز؟.
4. تُستورد سجلات عملاء من نظام قديم وتتطابق مع حسابات موجودة. هل ندمجها؟
كن حذرًا. المطابقة لا تستلزم الدمج، والدمج يمحو المعرّفات القديمة والقيم الأقدم التي قد تحتاج إلى تتبّعها. اربطها، ما لم يكن هناك فائز واضح والسجل المكرر لا يضيف شيئًا تحتاج إليه. أعد قراءة قاعدتي في الدمج: فائز واضح.
5. الملف الموحّد في Data 360 يعرض دالاس. يقول الفريق إن دالاس صارت الآن القيمة الذهبية لكل نظام. هل هي كذلك؟
لا. التسوية تقرر ما يعرضه الملف الموحّد؛ لكنها لا تغيّر المصادر ولا تتخذ قرار إدارة بيانات رئيسية. إن كان على كل نظام أن يستخدم قيمة محكومة واحدة، فهذا MDM بأسلوب التعايش أو المركزي، مع مالك. أعد قراءة التسوية ليست إدارةً للبيانات الرئيسية أيضًا.
6. مطابقة السجلات الطبية مقابل سجلات التسويق: القواعد نفسها؟
لا. المطابقة الخاطئة في التسويق ترسل العرض الخطأ؛ وفي البيانات الطبية تدمج تاريخ شخصين. حدّد الصرامة بحسب كلفة الخطأ، وطابِق بأقل من اللازم حيث يكون الخلط مكلفًا. أعد قراءة كلفة الخطأ.
7. يريد المندوبون تحديث عنوان فوترة يملكه ERP من داخل Salesforce. كيف تصمّم ذلك؟
كطلب، لا كتعديل: يرسل Salesforce القيمة المقترحة، فيتحقق منها ERP ويقبلها، وينشر القيمة المعتمدة عائدة. احتفظ بحالة «قيد الانتظار» حتى ذلك الحين، وتعامل مع الرفض والتصادمات والأصداء. أعد قراءة البيانات ثنائية الاتجاه لا تعني مرجعيتين.
8. في Steve Trucking، يظهر John Smith نفسه في بيانات شحنة شريكَي تجزئة. هل نوحّده؟
لا، وعن قصد. يجب ألا يرى أي شريك أبدًا مستلمي شريك آخر، والهوية الموحّدة هي الجسر الذي يتسرب منه ذلك. طابِق بأقل من اللازم حيث يكون الخلط مكلفًا؛ وإن أراد شريك التعرف على المستلمين المتكررين، فاحصر ذلك في ذلك الشريك وحده. أعد قراءة هل كنت سأوحّد المستلمين عبر الشركاء؟.
9. يرسل مندوب شارعًا جديدًا لعنوان يملكه ERP، بينما يغيّر أحدهم في ERP المدينة في الدقيقة نفسها. ماذا تقرر؟
هل ينتقل العنوان كمعاملة واحدة. إن كان كذلك، فالحقول تنتقل كلها معًا أو لا ينتقل أيٌّ منها، ويُرفض الطلب لأن العنوان تغيّر في الأثناء. قرّر ذلك قبل أول تصادم، وتذكّر أن الطلب يطلب تغيير قيمة ERP، لا يغيّرها. أعد قراءة الحلقات والتصادمات.
10. لدى عميل زبون واحد في نظامَي ERP، ولا أحد يبقي السجلين متزامنين. وتريد المبيعات حسابًا واحدًا. بماذا توصي؟
ليس حسابًا واحدًا. إن لم يستطيعوا إبقاء السجلات متزامنة في أنظمة ERP الخاصة بهم، فلن يستطيع Salesforce فعل ذلك عنهم: مثّلها كحسابات نظيرة أو كتسلسل هرمي، وأظهِر البنية التي تعرفها المبيعات أصلًا. الحساب الواحد مع سجل فرعي لكل ERP يحتاج إلى عميل يبقي القيم المشتركة متزامنة. أعد قراءة اسأل كيف يبقون أنظمة ERP متزامنة.
للاستزادة
Section titled “للاستزادة ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)، Salesforce Help (بالإنجليزية، تم التحقق في 2026-09-25): القائمة الرسمية للأهداف وأوزانها. تحقق دائمًا من النسخة الحالية قبل أن تحجز موعد الاختبار.
- يسرد قسم «للاستزادة» في كل وحدة وثائق Salesforce التي تستند إليها حقائقها، مع تاريخ التحقق.
