حوّل النموذج إلى 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)
الوحدة 6 من 6 في فصل نمذجة البيانات من أجل المعنى، الفصل 2 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: صمّم حتى الشكل الطبيعي الثالث، ثم تراجع · التالي: دليل دراسة الفصل، ثم الفصل التالي: معمارية بيانات Salesforce
السؤال الذي تجيب عنه هذه الوحدة: كيف يصبح نموذج البيانات المنطقي نموذج بيانات ماديًا في Salesforce؟
أخيرًا سنتحدث عن Salesforce. إذا كنت تقاوم الرغبة في تحويل كل مربع إلى كائن، فالآن تستطيع. لكن لاحظ الترتيب الذي جئنا به: فهمنا العمل، ووصفنا البيانات، ووضعنا كل حقيقة حيث تنتمي، وقررنا أين سنحيد عن ذلك عن قصد. الآن فقط أسأل كيف ينبغي أن ينفّذه Salesforce. هذا هو التدرّج الذي أريدك أن تتذكره: مفاهيمي ← منطقي ← مادي. النموذج المفاهيمي يصف العمل. والنموذج المنطقي يصف البيانات. والنموذج المادي يصف كيف سنبنيه فعلًا.
اجلس، ابقَ، نمذِج
Section titled “اجلس، ابقَ، نمذِج ”الخطوة المادية أسهل رؤيةً على شيء صغير، لذلك تأتي الحيوانات الأليفة أولًا.
من هم الشركات والأشخاص؟ المربّي شركة، لذلك يصبح حسابًا (Account) بنوع سجل Breeder (مربٍّ). والمالك حساب أيضًا، أو حساب شخصي، بنوع سجل Owner (مالك). نوعان من الكائن القياسي نفسه، جنبًا إلى جنب في أعلى المخطط، حيث كانا تمامًا منذ الوحدة 1.
ما الذي ليس له مكان قياسي؟ الحيوان الأليف، والسلالة، والحيلة، وحيلة الحيوان الأليف، وتقييم الحيلة تصبح كائنات مخصصة. وهل تتذكر النوع الذي نسخناه إلى الحيوان الأليف في الوحدة 5؟ هنا يحصل على وظيفته: يصبح نوع السجل للحيوان الأليف، Dog (كلب) أو Cat (قط). كائن واحد بنوعَي سجل، لكلٍّ منهما تخطيط صفحته وقيم قوائم اختياره، بدلًا من كائن للكلب وكائن للقط.
أي العلاقات رئيسي-تفصيلي؟ أستخدم علاقة رئيسي-تفصيلي فقط حيث لن يُنقل الابن أبدًا إلى أب آخر. حيلة الحيوان الأليف تنتمي إلى حيوانها الأليف مدى الحياة، وكل تقييم حيلة ينتمي إلى حيلة الحيوان الأليف الخاصة به، لذلك كلتاهما علاقة رئيسي-تفصيلي. وهذا يؤتي ثماره فورًا: علاقة رئيسي-تفصيلي هي ما يتيح للحيوان الأليف أن يحتفظ بـحقل ملخص تجميعي (roll-up summary) لحيل الحيوان الأليف، فيبقى عدد الحيل المتقنة من الوحدة 5 متوافقًا من تلقاء نفسه. لكن الحيوانات الأليفة تنتقل من بيت إلى آخر، لذلك المالك علاقة بحث.
أيها علاقات بحث؟ لا يوصي Salesforce بأكثر من 10,000 ابن لأب واحد. حيلة شائعة مثل «اجلس»، أو سلالة منتشرة، أو مربٍّ كبير، قد تتجاوز ذلك بسهولة، لذلك تشير حيلة الحيوان الأليف إلى حيلتها بعلاقة بحث، ويشير الحيوان الأليف إلى سلالته ومربّيه بالطريقة نفسها. وتجنّب العلاقات متعددة الأشكال (polymorphic) حيثما استطعت، أي النوع الذي يمكن فيه لحقل واحد أن يشير إلى عدة أنواع من الكائنات. إنها مريحة في اليوم الأول وأصعب على كل ما يجب أن يقرأها لاحقًا: التقارير، وعمليات التكامل، والآن الوكلاء.
ما الذي يبقى خارج المنصة؟ إذا كان الحيوان الأليف يرتدي طوق GPS يُبلغ عن مكانه، فذلك الموقع لا يحتاج إلى أن يُنسخ إلى الداخل على الإطلاق. يمكن أن يكون كائنًا خارجيًا، يُقرأ مباشرة من نظام التتبع الخاص بالطوق.
كل قرار في ذلك المخطط يعود إلى شيء قررناه سابقًا، وهذا هو المقصود. والآن الخطوة نفسها لـ Steve Trucking.
ابدأ بالنموذج المنطقي
Section titled “ابدأ بالنموذج المنطقي ”يضم نموذج Steve Trucking المنطقي الآن شريك التجزئة، ومركز التوزيع، وبيان الشحنة، والتوصيلة، وبند التوصيلة، والمستلم، والمسار، والمحطة، والطاقم، والشاحنة، وتكليف الطاقم. هذه مفاهيم عمل، والآن أستطيع أن أبدأ في ربطها بـ Salesforce.
شريك التجزئة قد يكون حسابًا (Account). والتوصيلة قد تُربط بشيء يملكه Salesforce بالفعل للعمل المجدول في الميدان، أو قد تصبح كائنًا مخصصًا. وبيان الشحنة ليس له ما يناسبه من الكائنات القياسية، لذلك سيصبح على الأرجح مخصصًا. أما المستلم فسؤال صعب حقًا: حساب شخصي (Person Account)، أم جهة اتصال (Contact)، أم مجرد معلومات على التوصيلة؟ سنجيب عن ذلك كما ينبغي في الفصل التالي.
الكلمة المهمة ما زالت قد. لا تفترض التنفيذ لمجرد أن مفهوم عمل يبدو مثل كائن في Salesforce. لهذا بنينا النموذج المنطقي أولًا: إنه يمنحنا شيئًا نختبر تصميم Salesforce في ضوئه.
كيان العمل لا يعني تلقائيًا كائنًا مخصصًا
Section titled “كيان العمل لا يعني تلقائيًا كائنًا مخصصًا ”هذا فخ أريد أن يتجنبه مسؤولو الأنظمة: «حدّدنا أحد عشر كيانًا، إذن نحتاج إلى أحد عشر كائنًا مخصصًا.» لا. الكيان المنطقي يخبرنا بأن مفهوم العمل مهم. لكنه لا يملي كيف يجب أن يخزّنه Salesforce. قد يصبح المفهوم كائنًا قياسيًا، أو كائنًا مخصصًا، أو علاقة بين كائنات، أو حقلًا أو بضعة حقول، أو قيمة تُدار في الإعدادات، أو بيانات تعيش خارج Salesforce تمامًا (صور التوصيل في Steve Trucking مرشّح جيد لذلك). النموذج المادي هو حيث تُتخذ تلك الخيارات، ولهذا بالضبط لم نتخذها في المكالمة الأولى.
السمات تصبح حقولًا مادية
Section titled “السمات تصبح حقولًا مادية ”الانتقال نفسه يحدث مع السمات. للشاحنة المنطقية لدينا رقم وحدة، ورقم هيكل (VIN)، وشركة مصنّعة، وطراز، وسنة طراز، ولوحة ترخيص، وحالة. والآن نقرر كيف توجد ماديًا: أي كائن يملكها، وأي أنواع الحقول تستخدم، وأيها إلزامي، وأيها يجب أن يكون فريدًا، وأيها معرّفات خارجية، وأيها يحتاج إلى تحقق، وأيها يُشتق بدلًا من أن يُخزَّن، وأيها حساس. على المستوى المنطقي سألنا ماذا تعني الشاحنة. وعلى المستوى المادي نسأل كيف سيمثّل Salesforce الشاحنة. سؤالان مختلفان.
العلاقات تصبح قرارات على مستوى المنصة
Section titled “العلاقات تصبح قرارات على مستوى المنصة ”كل الوقت الذي قضيناه على العلاقات يؤتي ثماره هنا. نعرف بالفعل هل كل علاقة واحد-إلى-واحد أم واحد-إلى-كثير أم كثير-إلى-كثير، إلزامية أم اختيارية، وهل يهم تاريخها. والآن نقرر كيف ينفّذها Salesforce: علاقة بحث، أو رئيسي-تفصيلي، أو كائن الربط في Salesforce (Salesforce Junction Object)، وربما كائن ربط بسمات خاصة به، لأنه، كما وجدنا، يمكن أن يكون للعلاقة نفسها معنى في العمل.
تذكّر تكليف الطاقم. كان يمكن أن نبدأ هذا الفصل بقول: «لننشئ كائن ربط في Salesforce بين الطاقم والشاحنة.» انظر إلى ما كنا سنتخطاه: لماذا توجد العلاقة، وهل تحتاج إلى تاريخ ومسار، وهل لها حالة، وهل تحتاج مطالبة بتعويض عن ضرر بعد أسابيع إلى تاريخها. أسئلة العمل هذه تخبرنا بما هو تكليف الطاقم. وعندها فقط ينبغي أن نقرر كيف يبنيه Salesforce، وهل لدى Salesforce بالفعل شيء يؤدي هذه الوظيفة.
والآن ارسم النموذج المادي
Section titled “والآن ارسم النموذج المادي ”يتغيّر المخطط مرة أخرى. أظهر النموذج المفاهيمي مفاهيم العمل وخطوطًا بسيطة. وأضاف النموذج المنطقي السمات والمفاتيح والتعددية والكيانات المختبئة في العلاقات. والآن يبدأ النموذج المادي في أن يشبه Salesforce: كائنات قياسية، وكائنات مخصصة، وحقول، وأنواع علاقات، وما يعيش خارج المنصة.
أريدك أن تستطيع وضع تلك المخططات الثلاثة جنبًا إلى جنب وترى التدرّج: لا ثلاثة مخططات لا علاقة بينها، بل العمل نفسه على ثلاثة مستويات.
كلمة عن طريقتي في رسم هذه المخططات، لأن التخطيط جزء من الرسالة. أضع الكائن الأساسي في المنتصف، أسفل قليلًا. وإذا كانت له كائنات أب، أضعها أعلى قليلًا، فتقرأ النموذج من الأعلى إلى الأسفل، ومن اليسار إلى اليمين، بالطريقة التي يفكر بها العمل. والبيانات المرجعية تذهب إلى الجانب. وللون معنى أيضًا: أجعل Salesforce أزرق دائمًا، وأختار لونًا لأنظمة الشركة نفسها، عادةً الأخضر، لأن الأخضر لون لطيف وودود. لا أستخدم الأحمر، والأصفر قاسٍ بعض الشيء. عندما يُرتَّب النموذج هكذا، فإنه يغنّي لي. كثير من المخططات التي ستجدها هي في الحقيقة إدارة مساحات: كيف أركن كل سياراتي في مرآبي المزدحم؟ أفضّل أن أرسم صورة منطقية يستطيع العقل استيعابها.
النموذج المادي يجب أن يحترم المنصة
Section titled “النموذج المادي يجب أن يحترم المنصة ”Salesforce ليس قاعدة بيانات علائقية عامة. لديه آراء في العلاقات والملكية والأمان والتقارير. لديه حدود، وسلوك استعلامات، وأتمتة، ومعمارية تؤثر في سلوك النموذج على نطاق واسع. لذلك قد يحتاج نموذج منطقي يبدو مثاليًا على السبورة إلى التغيير عندما يصبح ماديًا. هذا ليس Salesforce يعترض الطريق. بل يعني أن للمنصة شكلًا، والمعماريون الجيدون يفهمون ذلك الشكل. والفصل التالي يدور حول ذلك بالضبط.
وأحيانًا أيضًا سيختلف النموذج المادي عن قصد عن النموذج المنطقي النظيف بسبب قرارات إلغاء التطبيع التي اتخذناها في الوحدة 5. لا بأس بذلك، ما دمنا نستطيع أن نشرح السبب.
لا تصمّم من Setup
Section titled “لا تصمّم من Setup ”هناك عادة أريدك أن تتخلص منها إن كانت لديك: أن تبدأ معمارية بياناتك من Setup → Object Manager → New Custom Object وتكتشف النموذج وأنت تمضي. يجعل Salesforce إنشاء الأشياء سهلًا بشكل لا يُصدَّق؛ وهذه إحدى نقاط قوته، وأحد أسباب ظهور نماذج البيانات الضعيفة بهذه السرعة. بضع نقرات ولديك كائن، وبضع نقرات أخرى ولديك حقول وعلاقة. ثم تصل البيانات، وتُبنى عمليات Flow، وتُنشأ التقارير، وتعتمد عليه عمليات التكامل، ويصبح الكائن الذي أنشأته في خمس دقائق مكلفًا جدًا في تغييره. إنه اختبار قابلية التراجع من الفصل 1. لذلك قبل أن تنقر New Custom Object، ارسم النموذج.
المادي لا يعني الدائم
Section titled “المادي لا يعني الدائم ”هناك سبب آخر لإبقائي النماذج الثلاثة منفصلة: التقنية تتغيّر. اليوم تعيش بعض بيانات Steve Trucking على نواة Salesforce. وغدًا قد يعيش جزء منها في Data 360، أو في مستودع بيانات، أو في نظام لم نختره بعد، ويحتاج مساعد الذكاء الاصطناعي إلى تمثيله الخاص. يمكن أن تتغيّر المعمارية المادية، بينما تبقى مفاهيم العمل مستقرة بشكل لافت: شركاء التجزئة والتوصيلات والمستلمون ما زالوا موجودين. وهذا ما يجعل النموذج المنطقي قيّمًا. إنه وصف متين للعمل غير مرتبط بتنفيذ اليوم.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”عندما أحوّل نموذجًا منطقيًا إلى نموذج Salesforce مادي، فأنا أقرر:
- أي كيانات العمل تُربط بقدرات Salesforce القياسية، وأيها يحتاج إلى كائنات مخصصة أو تمثيل آخر.
- كيف تصبح السمات المنطقية حقولًا مادية، وكيف تُنفَّذ العلاقات على المنصة.
- أين ينتمي إلغاء التطبيع المقصود في التصميم المادي.
- أي البيانات تنتمي إلى Salesforce، وأيها ينتمي إلى مكان آخر.
- أي خصائص المنصة تتطلب أن يختلف النموذج المادي عن المنطقي.
والأهم من ذلك، أريد أن أستطيع تتبّع كل قرار إلى الوراء. إذا أشرت إلى شيء في نموذجي المادي وسألت: «لماذا هذا هنا؟»، فينبغي أن أستطيع أن أعود بك عبر النموذج المنطقي والنموذج المفاهيمي إلى شيء يحتاجه العمل فعلًا: العمل ← المفاهيمي ← المنطقي ← المادي.
ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. يستطيع الذكاء الاصطناعي الآن أن يأخذ وثيقة متطلبات حتى كائنات Salesforce وحقوله في قفزة واحدة. وهذا يجعل التسلسل أكثر أهمية، لا أقل: إذا قفز من المتطلبات إلى الإعدادات، فاطلب منه أن يُظهر ما حدث بينهما: ما الذي قرر أنه كيان، وأي المفاتيح اختار، وأي العلاقات افترض، وأين ألغى التطبيع. هذه قرارات معمارية، والمعماري ما زال بحاجة إلى رؤيتها.
بدأنا هذا الفصل في مكالمة أولى، ننصت إلى الأسماء، وننهيه بنموذج مادي نستطيع تتبّعه إلى العمل. والآن بعد أن اخترنا البناء على Salesforce، يذهب السؤال التالي أعمق: على أي نوع من منصات البيانات نبني فعلًا؟
للاستزادة
Section titled “للاستزادة ”- Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab)، Salesforce Developers، Winter ‘27 (بالإنجليزية، تم التحقق في 2026-10-02): «اضبط علاقات الأب-الابن بحيث لا يزيد عدد الأبناء على 10,000 لسجل أب واحد.» إرشاد بشأن data skew (انحراف البيانات)، لا حدّ صارم؛ والفصل 7 يتعمق أكثر.
- Roll-Up Summary Field (opens in a new tab)، Salesforce Help (بالإنجليزية، تم التحقق في 2026-10-12): حقل الملخص التجميعي يعدّ سجلات التفاصيل أو يجمعها عبر علاقة رئيسي-تفصيلي.