معمارية بيانات Salesforce

🌐 متاح أيضًا بـ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 من دورة Data Architect. اقرأ الوحدات العشر أولًا؛ هذه الصفحة تساعدك على التحقق مما رسخ في ذهنك.

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

هذا هو الفصل الذي يلتقي فيه النموذج بالمنصة، وهو يحمل جزءًا كبيرًا من الاختبار. فهو يغذّي أكبر قسمين، Data Modeling and Database Design وSalesforce Data Management، ولكل منهما ربع الاختبار. أرقام المنصة تتغير: تذكر قائمة التحقق الأرقام التي تستشهد بها الوحدات، مع تاريخ التحقق منها. تعلّم الغرض من كل حدّ، وتحقق من الرقم الحالي قبل أن تعتمد عليه.

من أجل الاختبار

ضع علامة على كل بند وأنت تتقدم. كل بند يحيلك إلى المكان الذي يُشرح فيه.

DM-1: تصميم نموذج البيانات على المنصة

• أعرف أن Salesforce منصة تقودها البيانات الوصفية ومتعددة المستأجرين: الكائن بيانات وصفية، لا جدول جديد، وكل كائن يحصل على واجهات API الخاصة به لحظة وجوده. (البيانات الوصفية هي المخطط، واجهة API جاءت مع الكائن)
• أعرف أن governor limits (حدود المنصة) موجودة حتى لا يستطيع مستأجر واحد الاستيلاء على الموارد المشتركة. (لا يمكنك الاستيلاء على المصعد)
• أستطيع قراءة نماذج البيانات القياسية: تحويل العميل المحتمل (Lead) إلى حساب وجهة اتصال وفرصة؛ ومنتج الفرصة (Opportunity Product) يشير إلى Price Book Entry، الذي يشير إلى Product2؛ والحالة (Case) والأصل (Asset) والاستحقاق (Entitlement) على جانب الخدمة. (نموذج المبيعات، نموذج الخدمة)
• أعرف ما الذي تقرره شاشة New Custom Object: اسم سجل من نوع Text أو Auto Number؛ وObject Classification (مع تفعيل المشاركة وBulk API وStreaming API يكون كائن Enterprise Application، ومع إيقافها كائن Light Application)؛ وAllow Search، وهو متوقف افتراضيًا. (شاشة New Custom Object)
• أستطيع قراءة اسم API: الكائنات والحقول القياسية بلا بادئة ولا لاحقة؛ والكائنات والحقول المخصصة تنتهي بـ __c؛ والحزمة المُدارة تضيف بادئة نطاق الأسماء الخاصة بها (abc__)؛ والحقل الذي تضيفه إلى كائن حزمة يحصل على __c لكن لا يحصل أبدًا على بادئة المورّد. (البادئات واللواحق)
• أستطيع تطبيق اختبار التوافق النظيف على كائن قياسي، وأعرف متى يشير المعنى أو الثقل إلى كائن مخصص. (اختبار التوافق النظيف)
• أعرف الغرض من الأصل (Asset) والحسابات الشخصية، وأن الحساب الشخصي يستهلك نحو ضعف تخزين حساب الأعمال، وأن الحسابات الشخصية بمجرد تفعيلها لا يمكن تعطيلها. (الأصل مثال جيد، الحسابات الشخصية، متى يكون الشخص هو الحساب؟)
• أختار نوع الحقل وفق السلوك الذي أحتاج إليه (رقم الأسطول ليس Number)، وأعرف أن التاريخ/الوقت يُخزَّن بتوقيت GMT ويُعرض بالمنطقة الزمنية لكل قارئ، لذا يُقارَن بالنطاقات، لا بالتساوي. (الرقم ليس دائمًا رقمًا، Date وDate/Time وTime)
• أعرف أن النص يأتي بنوعين: حتى 255 حرفًا على السجل (قابل للفهرسة، ويمكن استخدامه كقيمة فريدة أو External ID)، وLong أو Rich text فوق ذلك، بلا فهرس، وبلا تصفية WHERE، وبلا صيغ. (عائلة النصوص)
• أعرف متى أستخدم حقل Name من نوع auto number، وأنه ليس معرّف السجل. (هل يحتاج إنسان إلى التعرّف عليه؟)
• أعرف كيف يتيح External ID للتكامل إجراء upsert، وتحميل السجلات الأبناء بواسطة External ID الخاص بأبيها. (معرّفات External ID)
• أعرف متى ينبغي أن تكون القيمة مشتقة بصيغة، ومتى تكون حقيقة تاريخية يجب تخزينها. (مخزَّنة أم مشتقة؟)
• أعرف الفرق بين كائن الربط المنطقي (فكرة النمذجة: كائن يربط بين كائنين آخرين في علاقة متعدد-لمتعدد، وله سماته الخاصة) وكائن الربط في Salesforce (Salesforce Junction Object) (كائن مخصص بعلاقتي رئيسي-تفصيلي)، وأن Salesforce تقصد الثاني. (أبوان عرضًا)
• أعرف العلاقة الهرمية: علاقة بحث خاصة على كائن User فقط، مثل حقل Manager القياسي، لا يمكن أن تعود إلى المستخدم نفسه مباشرةً أو بشكل غير مباشر، وليست التسلسل الهرمي للأدوار. (الهرمية)
• أعرف الفرق بين علاقة البحث (lookup) وعلاقة رئيسي-تفصيلي (master-detail): الملكية، والمشاركة، والأب الإلزامي، والحذف المتتالي، والملخصات التجميعية. (علاقة البحث، رئيسي-تفصيلي)
• أعرف أن علاقة رئيسي-تفصيلي لا يمكن إنشاؤها على كائن يحتوي بيانات بالفعل (أنشئ علاقة بحث، واملأها، ثم حوّلها)، ولا يمكن إعادتها إلى علاقة بحث إلا إذا لم تكن على الرئيسي ملخصات تجميعية، وتحتاج إلى Allow reparenting لنقل الابن. (هل يمكن للابن تغيير أبيه؟)
• أعرف شكل المنصة لعلاقة رئيسي-تفصيلي: حتى ثلاثة مستويات تفصيلية مخصصة عمقًا (ويمكن لعلاقة بحث أن تكسر السلسلة في أي مكان)، وأبوان رئيسيان عرضًا. في كائن الربط في Salesforce تكون علاقة رئيسي-تفصيلي المُنشأة أولًا هي الأساسية (المالك، والمظهر، والقسم)، والثانية هي الثانوية، والوصول يحتاج إلى الأبوين كليهما: الأكثر تقييدًا هو الذي يسود. (ثلاثة مستويات عمقًا، أبوان عرضًا)
• أعرف خيارات علاقة البحث الثلاثة عند حذف الأب: مسح الحقل (الافتراضي)، أو منع الحذف، أو الحذف المتتالي، وهو متوقف حتى تفعّله Salesforce ويتجاوز المشاركة. (علاقة البحث)
• أعرف أن العلاقة الذاتية يجب أن تكون علاقة بحث، وأعرف العلاقتين المدمجتين: Parent Account في الحساب وParent Case في الحالة. (العلاقات الذاتية)
• أعرف أن إعادة حساب الملخص التجميعي قد تستغرق وقتًا، وأن الملخص التجميعي لا يمكنه استخدام صيغة فيها NOW() أو TODAY() أو مرجع عبر الكائنات، وألّا أختار رئيسي-تفصيلي لمجرد الحصول على ملخص تجميعي: البديل حقل مخزَّن يبقيه flow أو trigger محدَّثًا. (الملخصات التجميعية مفيدة، لكنها ليست مجانية)
• أعرف حدود العلاقات التي تستشهد بها الوحدة: علاقتا رئيسي-تفصيلي لكل كائن؛ و40 حقل علاقة افتراضيًا (50 كحد أقصى)؛ و25 ملخصًا تجميعيًا افتراضيًا (40 كحد أقصى). (للعلاقات حدود أيضًا)

DM-2: نموذج يحترم المشاركة ويتوسع

• أعرف أن الابن في علاقة رئيسي-تفصيلي ليس له مالك ولا جدول مشاركة خاص به: الوصول يتبع الرئيسي. (الملكية تأتي معها)
• أعرف انحراف الأب والأبناء (parent-child skew): توجيه Salesforce ألّا يزيد عدد الأبناء على أب واحد على نحو 10,000. (سؤال الـ 10,000 ابن)
• أعرف انحراف الملكية (ownership skew) (مستخدم واحد يملك أكثر من 10,000 سجل من كائن واحد) والتوجيه: وزّع الملكية، أو أبقِ ذلك المستخدم خارج التسلسل الهرمي للأدوار أو وحده في القمة، وخارج المجموعات العامة التي تستخدمها قواعد المشاركة. (الملكية قد تصبح مشكلة حجم)
• أعرف جدول المشاركة: كائن المشاركة لكائن مخصص هو Object__Share؛ والكائن التفصيلي ليس له جدول، فوصوله يأتي من الرئيسي؛ وتغيير المالك يزيل المشاركات اليدوية لكنه يُبقي مشاركة Apex التي لها سببها الخاص. (جدول المشاركة)
• أستطيع أن أقرر من يملك السجلات التي تُنشئها التكاملات والوكلاء، بناءً على ما إذا كانت الملكية تقود المشاركة. (من يملك السجلات التي تُنشئها الأنظمة؟)

DM-4: الـ big objects مقابل الكائنات القياسية والمخصصة

• أعرف المواطن الثلاثة للبيانات: على النواة (sObjects، يُعمل عليها كل يوم)، ومُشار إليها (نظام آخر هو مصدر الحقيقة: الكائنات الخارجية في Salesforce Connect، __x، أو استدعاءات مخصصة)، ومؤرشفة (على النواة في big objects، __b، أو خارج النواة في مستودع بيانات). (على النواة وخارج النواة)
• أعرف أن الكائنات الخارجية تُجري استدعاءً خارجيًا في كل مرة يُلمس فيها الكائن، لذا فإن زمن الاستجابة وتوافر النظام المصدر مهمان. (مُشار إليها)
• أعرف الـ big objects: أحجام ضخمة، يُستعلم عنها عبر فهرسها بالمطابقة التامة أو بالنطاق، بلا واجهة مستخدم قياسية ولا تقارير، وبأذونات الكائن والحقل فقط، وبلا أتمتة. (مؤرشفة)
• أعرف أن معظم السجلات تُحسب بنحو 2 KB من تخزين البيانات بغض النظر عن الحقول، وأن الملفات تُقاس على حدة في تخزين الملفات. (عمودان أم مئتا عمود، الملفات والمرفقات)

SDM-1: التراخيص والكائنات التي يستطيع الناس استخدامها

• أعرف التراخيص الداخلية الثلاثة، Sales Cloud وService Cloud وPlatform، وما يستطيع كل منها استخدامه. (ثلاثة تراخيص داخلية)
• أعرف أن التراخيص جزء من نموذج البيانات: مستخدمو Salesforce Platform لا يحصلون على Leads أو Campaigns أو Opportunities أو Forecasts، ومستخدمو Customer Community لا يستطيعون استخدام الفرصة. (والآن دعني أعقّد كل شيء: التراخيص)
• أعرف مستويات التراخيص الخارجية: Customer Community، وCustomer Community Plus (التقارير، ولوحات المعلومات، والمشاركة القياسية)، وPartner Community (كائنات المبيعات)؛ وأن Partner Community لا يمكن استخدامه مع الحسابات الشخصية. (الملعب)
• أعرف الترخيص القائم على العضوية (member-based) مقابل القائم على تسجيل الدخول (login-based)، وأي فئة من المستخدمين يناسبها كل منهما. (طريقة الدفع تغيّر التصميم)
• أعرف أن بعض تراخيص المنصة تقصر المستخدمين على تطبيق واحد يضم حتى عشرة كائنات مخصصة، وأعرف نمط نوع السجل للعمل ضمن هذا القيد. (عندما يشكّل الترخيص النموذج)
• أعرف أن ترخيص Salesforce Integration مخصص لمستخدمي الاتصال بين الأنظمة عبر API فقط. (لم يعد الناس هم المستخدمين الوحيدين)
• أعرف أن تقارير اتفاقيات مستوى الخدمة (SLA) تحتاج إلى الاستحقاقات والمعالم (entitlements and milestones)، وهذه تحتاج إلى تراخيص Service. (والآن دعني أعقّد كل شيء: التراخيص)

SDM-2: الحفاظ على اتساق البيانات

• أستطيع وضع القاعدة على الدرجة الصحيحة من سُلّم الاتساق: نوع الحقل والمفردات، والإلزامي والفريد، وقواعد التحقق، وقواعد التكرار، والأتمتة. (الحفاظ على اتساق البيانات)
• أعرف أن قائمة الاختيار المقيّدة ترفض القيم غير الموجودة في القائمة، حتى عبر API، وأن مجموعة القيم العامة تشارك قائمة واحدة بين حقول عدة (حتى 1,000 قيمة). (الدرجة الأولى)
• أعرف أن جعل الحقل إلزاميًا في تخطيط الصفحة يحمي تلك الشاشة فقط، لا البيانات، وأن قواعد التحقق تعمل عند كل حفظ. (التحقق في الواجهة ليس تحققًا من البيانات، الدرجة الثالثة)
• أستطيع تحديد نطاق قاعدة التحقق بـ ISNEW() وISCHANGED()، أو بإذن مخصص، أو بتاريخ إطلاق، مع معرفة أي عمليات الحفظ لا يزال كل خيار يفحصها (بما فيها عمليات لا أتحكم فيها، مثل تغيير المالك على دفعات أو ملخص تجميعي). (مشكلة السجلات القديمة)
• أعرف قواعد المطابقة وقواعد التكرار، والحدود التي تستشهد بها الوحدة (خمس قواعد تكرار نشطة لكل كائن، وثلاث قواعد مطابقة لكل منها)، وأنها لا تحل مشكلة الهوية عبر الأنظمة. (الدرجة الرابعة: قواعد التكرار)
• أعرف أن قواعد التكرار لا تقارن السجلات المحفوظة في اللحظة نفسها، وأن عمليات الحفظ عبر API والاستيراد تُمنع دون تنبيه، وأن الحفظ وكل ما يطلقه يُتراجع عنه كمعاملة واحدة. (الدرجة الرابعة، الكل أو لا شيء)
• أعرف أن Workflow Rules وProcess Builder خارج الدعم؛ والأتمتة تعني Flow أو Apex. (الدرجة الخامسة: الأتمتة)

ما بعد الاختبار

الاختبار هو الحد الأدنى، لا السقف. هذه هي العادات من هذا الفصل التي يحتاجها المعماري، سواء سأل عنها سؤال يومًا أم لا.

• للمنصة شكل. صمّم للمنصة التي تعمل عليها، لا لقاعدة بيانات عامة.
• انظر إلى السفينة الأم. انظر كيف تنمذج Salesforce مفهومًا ما قبل أن تخترع مفهومك.
• كل كائن التزام: التخزين، والحدود، ونموذج المشاركة، والتراخيص، والاعتماديات.
• اسأل أين تعيش البيانات قبل أن تختار كائنًا: على النواة، أو مُشار إليها، أو مؤرشفة.
• اقرأ أي اسم API وستعرف من صنعه، وما الذي تستطيع تغييره.
• إن لم تكن تؤرشف اليوم، فهل ستؤرشف يومًا؟
• جرّب الـ big objects بنموذج أولي قبل أن تقترحها.
• اختلاف أسماء الأعمال لا يعني تلقائيًا اختلاف الكائنات.
• اسأل أي الهويات تحتاج إلى البيانات: الناس، والعملاء، والشركاء، والتكاملات، والوكلاء.
• كل حقل يحصل على وصف، وعلى تصنيف حيث يهم ذلك.
• صِف سلوك العلاقة أولًا؛ والإعداد ينفّذه. لا تشوّه النموذج للحصول على ميزة.
• سؤال الحذف: ما الذي يجب أن يحدث للأبناء إذا حذف أحدهم الأب؟
• اختر أي رابط يكسر السلسلة: اجعل علاقة البحث حيث يكون للابن حياته الخاصة فعلًا.
• الملكية من الأساسي، والوصول من الاثنين: الأكثر تقييدًا هو الذي يسود.
• افصل غير النشط عن الزائل، واجعل الاحتفاظ قاعدة من قواعد الأعمال.
• ادفع القاعدة إلى أدنى مستوى تنتمي إليه بحق، وامنح التاريخ المشروع استثناءً بدلًا من إعادة كتابته.
• الرسم ليس المعمارية. كن قادرًا على تتبّع كل هيكل إلى سبب من أسباب الأعمال.

مصطلحات يجب معرفتها

المصطلح	في سطر واحد
تقوده البيانات الوصفية (metadata-driven)	الكائنات والحقول تعريفات تقرؤها المنصة أثناء التشغيل، لا جداول مادية جديدة
تعدد المستأجرين (multitenancy)	مؤسسات org كثيرة تتشارك البنية التحتية، كل منها معزولة، مثل الشقق في عمارة واحدة
governor limits (حدود المنصة)	حدود تمنع مستأجرًا واحدًا من الاستئثار بالموارد المشتركة
الكائن الخارجي	بيانات تُعرض في Salesforce عبر Salesforce Connect، وتُجلب من مصدرها عند كل لمسة
big object	تخزين لبيانات ضخمة جدًا نادرة الاستخدام، يُستعلم عنها عبر فهرسها
الحساب الشخصي	فرد ممثَّل كحساب، لنماذج البيع من الأعمال إلى المستهلك
التوافق النظيف	مفهوم أعمال يطابق الغرض المقصود من كائن قياسي
External ID	حقل يحمل معرّف نظام آخر، يُستخدم في عمليات upsert والمطابقة
upsert	حدّث السجل إن كان موجودًا، وأنشئه إن لم يكن
علاقة البحث (lookup)	علاقة يحتفظ فيها الابن بمالكه وحياته الخاصة
رئيسي-تفصيلي (master-detail)	علاقة ينتمي فيها الابن إلى الأب: مالك ومشاركة موروثان، وحذف متتالٍ، وملخصات تجميعية
كائن الربط المنطقي	فكرة النمذجة: كائن يربط بين كائنين آخرين في علاقة متعدد-لمتعدد ويحمل سماته الخاصة، أيًا كانت طريقة بنائه
كائن الربط في Salesforce (Salesforce Junction Object)	ما تقصده Salesforce بـ«كائن الربط»: كائن مخصص بعلاقتي رئيسي-تفصيلي
الرئيسي الأساسي والثانوي	علاقة رئيسي-تفصيلي المُنشأة أولًا في كائن الربط في Salesforce (المالك، والمظهر، والقسم)، والثانية (نطاق التقارير؛ وتصبح الأساسية إذا أُزيلت الأولى)
العلاقة الهرمية	علاقة بحث خاصة على كائن User فقط، مثل Manager، لا يمكن أن تعود إلى المستخدم نفسه
بادئة نطاق الأسماء (namespace prefix)	بادئة المورّد على كائنات الحزمة المُدارة وحقولها، مثل abc__Inspection__c
جدول المشاركة	كائن المشاركة (AccountShare، Truck__Share) الذي يحمل معظم مشاركات السجل، صفًا لكل مستخدم أو مجموعة، مع سببه
حقل ملخص تجميعي (roll-up summary)	حقل على الرئيسي يعدّ تفاصيله أو يجمعها أو يجد أصغر قيمة فيها أو أكبرها
data skew (انحراف البيانات)	سجلات كثيرة جدًا تحت أب واحد أو مالك واحد، تسبب الأقفال وإعادة حساب المشاركة لفترات طويلة
القائم على العضوية / القائم على تسجيل الدخول	الدفع لكل مستخدم خارجي، أو لكل تسجيل دخول شهريًا
سُلّم الاتساق	الطبقات التي تفرض قواعد البيانات، من نوع الحقل صعودًا إلى الأتمتة
قائمة الاختيار المقيّدة	قائمة اختيار ترفض أي قيمة ليست في قائمتها، من أي مصدر
تصنيف البيانات	بيانات وصفية للحقل تخص المالك، والاستخدام، والحساسية، وفئة الامتثال

اختبر نفسك

سيناريوهات قصيرة على نمط الدورة. حدّد إجابتك قبل أن تفتحها.

1. يحتاج المستخدمون إلى رؤية تفاصيل الطلبات التي يملكها ERP ويحدّثها طوال اليوم. ولا يعدّلونها في Salesforce. هل ننسخها أم لا؟

أشِر إليها: الكائنات الخارجية عبر Salesforce Connect تُبقي ERP مصدرًا للحقيقة دون نسخة تحتاج إلى مزامنة. تقبّل أن كل عرض يُجري استدعاءً خارجيًا، لذا فإن زمن الاستجابة وتوافر ERP مهمان، وأنها تناسب الوصول للقراءة أكثر من التعديل المكثّف أو التقارير. أعد قراءة مُشار إليها.

2. تريد الأعمال تتبّع الموزّعين والموردين وشركاء التجزئة. ثلاثة كائنات مخصصة؟

لا. كلهم شركات، لذا فالحساب توافق نظيف؛ والأسماء المختلفة أدوار، يحملها نوع، أو نوع سجل، أو علاقة. أعد قراءة اختبار التوافق النظيف.

3. تصميم يستخدم الفرصة (Opportunity)، لكن معظم من يحتاجون إلى البيانات لديهم تراخيص Salesforce Platform أو Customer Community. ماذا الآن؟

هذه التراخيص لا تستطيع استخدام الفرصة، لذا فالترخيص قيد معماري: اشترِ تراخيص مختلفة، أو انقل التجربة، أو أعد التصميم، وعادةً نحو كائن مخصص. أعد قراءة والآن دعني أعقّد كل شيء: التراخيص.

4. يرسل ERP تحديثات ليلية للحسابات. كيف ينبغي للتكامل أن يجد السجل الصحيح دون الاستعلام عن معرّفات Salesforce؟

خزّن رقم العميل في ERP في حقل External ID وأجرِ upsert عليه: حدّث إن وُجد، وأنشئ إن لم يوجد. ويمكن للسجلات الأبناء أيضًا أن تشير إلى أبيها بواسطة External ID الخاص به. أعد قراءة معرّفات External ID.

5. بند التوصيلة لا يمكن أن يوجد دون توصيلته، ولا ينتقل أبدًا، ولا يحتاج إلى مالك خاص به. والتوصيلة توجد قبل أن تُوجَّه إلى مسار ويمكن أن تنتقل إلى مسار آخر. أي علاقة لكل منهما؟

بند التوصيلة إلى التوصيلة: رئيسي-تفصيلي (ينتمي إلى الأب مدى الحياة، ويرث الوصول، ويُحذف معه حذفًا متتاليًا). التوصيلة إلى المسار: علاقة بحث (لها حياتها الخاصة، واختيارية في البداية، وقابلة للنقل، وحذف المسار يجب ألّا يحذف التوصيلات أبدًا). أعد قراءة ابدأ بالعلاقة التجارية.

6. تكامل يُنشئ 3,300 توصيلة في اليوم، يملكها كلها مستخدم التكامل، الذي له دور في منتصف التسلسل الهرمي. ما الخطر، وما الحل؟

انحراف الملكية: بعد 10,000 سجل، يؤدي نقل ذلك المستخدم أو تغيير مجموعاته إلى إعادة حساب المشاركة لفترات طويلة. وزّع الملكية إن كانت مهمة للوصول؛ وإلا فأبقِ مستخدم التكامل خارج التسلسل الهرمي للأدوار، أو وحده في دور في القمة، وخارج المجموعات التي تستخدمها قواعد المشاركة. أعد قراءة الملكية قد تصبح مشكلة حجم.

7. تضيف قاعدة تحقق، فتخالفها 20,000 سجل قديم. يعدّل مستخدم رقم هاتف في أحدها فيفشل الحفظ. ما الذي كان يجب أن تفعله القاعدة؟

أن تقول متى تُفرض، لا ما يجب أن يكون صحيحًا فقط: حدّد نطاقها بـ ISNEW() أو ISCHANGED() على الحقول المعنية، وامنح السجلات الأقدم من القاعدة استثناءً مقصودًا بدلًا من إعادة كتابة تاريخها. أعد قراءة مشكلة السجلات القديمة.

8. تريد الأعمال كل صورة توصيل «في Salesforce»: أربعة إلى خمسة ملايين في السنة، بنمو 30 في المئة. ماذا تقترح؟

افصل الوصول عن التخزين. أبقِ الملفات في تخزين مبني لهذا الحجم، خارج مؤسسة Salesforce (org) الأساسية، واحتفظ بمرجع أو عدد أو سجل فهرسة في Salesforce حتى يستطيع المستخدمون العثور عليها ورؤيتها. أعد قراءة الصور.

9. لتكليف الطاقم (Crew Assignment) علاقتا رئيسي-تفصيلي بالطاقم (أُنشئت أولًا) وبالشاحنة. يستطيع المرسِل رؤية الطاقم لكن لا يستطيع رؤية الشاحنة. هل يستطيع رؤية تكليف الطاقم؟

لا. الطاقم هو الأساسي، لذا فهو يمنح التكليف مالكه ومظهره، لكن الوصول يحتاج إلى الأبوين كليهما: يحتاج المرسِل إلى الوصول إلى الطاقم والشاحنة، بالمستوى الذي يطلبه Sharing Setting لكل حقل رئيسي-تفصيلي. الأكثر تقييدًا هو الذي يسود. أعد قراءة أبوان عرضًا.

10. يعيد شريك إرسال ملف بيان شحنة، ويظهر العميل نفسه فيه مرتين. لديك قاعدة تكرار على الحساب مضبوطة على المنع. هل أنت في أمان؟

ليس بقاعدة التكرار وحدها. السجلات المحفوظة في اللحظة نفسها لا تُقارَن ببعضها، بل بالسجلات الموجودة في Salesforce فقط، لذا قد يمرّ الصفّان كلاهما. ادفع التفرّد إلى مستوى الحقل: External ID فريد، تفحصه المنصة عند كل حفظ، فلا يفوز إلا واحد. أعد قراءة الدرجة الرابعة: قواعد التكرار والكل أو لا شيء.

للاستزادة

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)، Salesforce Help (بالإنجليزية، تم التحقق في 2026-09-25): القائمة الرسمية للأهداف وأوزانها. تحقق دائمًا من النسخة الحالية قبل أن تحجز موعد الاختبار.
• يسرد قسم «للاستزادة» في كل وحدة وثائق Salesforce التي تستند إليها حقائق المنصة فيها، مع تاريخ التحقق منها.