أكثر من قاعدة بيانات

🌐 متاح أيضًا بـ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)

صورة مولّدة بالذكاء الاصطناعي

ترجمة بالذكاء الاصطناعي. لم يراجعها المجتمع بعد. اقرأ بالإنجليزية

الوحدة 1 من 10 في فصل معمارية بيانات Salesforce، الفصل 3 من دورة Data Architect. كل وحدة قائمة بذاتها. التالي: انظر إلى السفينة الأم: نماذج البيانات القياسية

السؤال الذي تجيب عنه هذه الوحدة: ما الذي يجعل Salesforce مختلفة عن قاعدة البيانات التقليدية؟

إذا كنت تعمل مسؤولًا عن Salesforce (admin) منذ فترة، فأنت تعرف بالفعل كيف تُنشئ كائنًا. Setup، ثم Object Manager، ثم New Custom Object. تعطيه اسمًا، وتضيف بضعة حقول، وتبني تخطيط صفحة، وبعد عشر دقائق يستطيع المستخدمون العمل عليه.

لكن ما الذي حدث فعلًا عندما نقرت على Save (حفظ)؟

إذا كانت خلفيتك في قواعد البيانات، فربما تتخيل أن Salesforce ذهبت وأنشأت جدولًا جديدًا. لم تفعل. وفهم السبب هو أحد المواضع التي تبدأ فيها بالانتقال من التفكير كمسؤول أو كمطوّر إلى التفكير كمعماري.

Salesforce تخزّن البيانات بالطبع؛ فهناك قواعد بيانات في الأسفل. لكن Salesforce ليست قاعدة بيانات فوقها شاشة جميلة. إنها منصة تطبيقات تقودها البيانات الوصفية (metadata)، وهذا الفرق يشكّل تقريبًا كل قرار في هذه الدورة.

للمنصة شكل

في الفصل 2 بنينا النموذج دون أن نشغل بالنا بـ Salesforce على الإطلاق. وكان ذلك مقصودًا: أصغينا إلى الأسماء، وبنينا النموذج المفاهيمي، وأضفنا السمات والمفاتيح والعلاقات، وبعد ذلك فقط سألنا كيف ينبغي أن تنفّذه Salesforce. والآن علينا أن نفهم الشيء الذي ننفّذه عليه.

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

البيانات الوصفية هي المخطط

فكّر في مبنى. هناك المبنى نفسه، وهناك المخطط الذي يصفه: أين الجدران، وأين الأبواب، وكيف تتصل الغرف. Salesforce تعمل بالطريقة نفسها. تعريف الكائن بيانات وصفية. تعريف الحقل بيانات وصفية. العلاقة بيانات وصفية. ومعظم ما نضبطه في Setup بيانات وصفية، تقرؤها المنصة أثناء التشغيل لتمنح مؤسستنا (org) بنيتها وسلوكها.

تصف Salesforce قلب المنصة بأنه متعدد المستأجرين (multitenant) وتقوده البيانات الوصفية (metadata-driven) في آن واحد: عندما نعرّف كائنًا أو حقلًا، يُخزَّن التعريف كبيانات وصفية، لا كجدول أو عمود مادي جديد لمؤسستنا (Platform Multitenant Architecture (opens in a new tab)).

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

وهذا يفسّر أيضًا أمرًا يتعثر فيه الناس. عندما تكتب SELECT Id, Name, Special__c FROM Account، يبدو الأمر كأنه جدول واحد. لكنك في الأسفل تقرأ الكائن القياسي وحقله المخصص من بُنى مختلفة، فالمنصة تُجري عملية ربط (join) لم تكتبها أنت قط. الفهارس موجودة، لكنها لا تعمل كما يعمل فهرس قاعدة البيانات التقليدية. لا تحتاج إلى معرفة التفاصيل الداخلية من أجل الاختبار. لكنك تحتاج إلى أن تعرف أن ما تراه في Object Manager ليس صورة مطابقة واحدًا لواحد للجداول المادية، وأن هذا التجريد هو مصدر قوة المنصة وسبب تصرفها على النحو الذي تتصرف به في آن واحد.

Click to enlarge

انظر إلى السفينة الأم

من الأشياء التي أقولها للناس في الصف: انظر إلى السفينة الأم. قبل أن تخترع طريقة معقدة لفعل شيء ما على Salesforce، انظر كيف تفعله Salesforce نفسها.

خذ الحساب (Account). لم تُنشئه أنت؛ أنشأته Salesforce. لكنك تستطيع أن تضيف إليه حقولًا، وتبني حوله الأتمتة، وتغيّر تخطيطاته، وتكشفه عبر واجهات API، وتربط به كائنات أخرى. الكائنات المخصصة تعمل على الآلية نفسها، ولهذا تبدو الكائنات القياسية والمخصصة متشابهة جدًا حين نبني عليها. بل إنها في Apex تشترك في فئة أساسية واحدة، هي sObject.

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

نحن لا نبني بجانب Salesforce. نحن نوسّعها.

واجهة API جاءت مع الكائن

أنشئ جدولًا في قاعدة بيانات تقليدية، فيكون لديك جدول. وإذا احتاج تطبيق آخر إلى العمل عليه، فأمام أحدهم عمل إضافي. أنشئ كائنًا على Salesforce، فتفهمه المنصة فورًا عبر طبقات التطبيق والتكامل فيها: فهي تستخدم البيانات الوصفية نفسها لتوفير واجهات REST وSOAP، بحيث يمكن إنشاء سجلات الكائن وقراءتها وتحديثها وحذفها عبرها بمجرد أن يوجد الكائن (Platform Multitenant Architecture (opens in a new tab)).

لم أصمّم واجهة API لأنني أنشأت كائنًا. المنصة تعرف الكائن وحقوله وأنواعها وعلاقاته وأمانه. هذا أحد أسباب سرعة التطوير على Salesforce. وهو أيضًا سبب كون إنشاء كائن قرارًا أكبر مما يبدو: أنت تصل بنية بمنصة تطبيقات كاملة. والأمر يعمل في الاتجاه الآخر أيضًا. يسألني أحيانًا قادمون من SQL Server أو Oracle كيف يحمّلون البيانات مباشرة في قاعدة البيانات. لا يمكنك ذلك. كل شيء يمر عبر واجهات API.

العمارة السكنية

والآن الكلمة التي تسمعها طوال الوقت: تعدد المستأجرين (multitenancy). أنا أتخيلها عمارة سكنية.

لديك شقتك. أثاثك ملكك، ومفتاحك لا ينبغي أن يفتح بابي. لكننا نتشارك المبنى: الكهرباء، والماء، والمصاعد، والردهة. تبدو مؤسستك كأنها بيئتك الخاصة، ببياناتك وكائناتك وأتمتتك. وفي الأسفل، تصف Salesforce كل مؤسسة بأنها مستأجر، وتعزل بيانات كل مستأجر وبياناته الوصفية ومنطقه، بينما تكون البنية التحتية والخدمات مشتركة (Platform Multitenant Architecture (opens in a new tab)). وهكذا تستطيع أن تمنح كل عميل منصة قابلة للتخصيص إلى هذا الحد دون أن تشغّل حزمة منفصلة لكل واحد.

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

لا يمكنك الاستيلاء على المصعد

ابقَ في المبنى دقيقة أخرى. تخيّل أن أحد السكان أعلن: «أحتاج إلى المصعد من الثامنة حتى الظهر. لا أحد غيري يستخدمه». هذا لا ينجح في مبنى مشترك، ولا ينجح على Salesforce أيضًا. لا يمكن السماح لمستأجر واحد باستهلاك الموارد المشتركة بلا حدود وإضعاف المنصة على الجميع.

من هنا تأتي governor limits (حدود المنصة). إذا كنت قد طوّرت على Salesforce، فربما قابلتها كقائمة أرقام تحفظها. لا أريدك أن تفكر فيها بهذه الطريقة. تطبّق Salesforce الحدود على مستوى المعاملة والمؤسسة حتى لا يحتكر عبء عمل مستأجر واحد قدرة المعالجة المشتركة (Architecture Basics (opens in a new tab)). هذه هي المعمارية؛ وكل حد بعينه ليس إلا تطبيقًا لها. لاحقًا في الدورة سنهتم بحدود معينة لأنها تغيّر التصميم. أما الآن فتذكّر المبنى: لديك حرية هائلة في إعادة تجهيز شقتك. لكنك لا تستولي على المصعد.

معرّفات Salesforce جزء من التجريد

لكل سجل في Salesforce معرّف تفهمه المنصة، هو معرّف السجل (record ID)، وهو يعمل عبر كل القدرات: واجهة المستخدم، وواجهات API، والتقارير، والأتمتة.

في الفصل 2 قلنا إن المفتاح الجيد يكون فريدًا، وثابتًا، وبلا معنى، وليس بيانات شخصية (PII) أبدًا. معرّف Salesforce يحقق ذلك داخل Salesforce. لكنه ليس الشيء نفسه الذي يمثله مفتاح العمل. فقد يظل لدى شركتك رقم عميل في نظام ERP، أو رقم موظف، أو رقم طلب لدى شريك، له معنى عبر الأنظمة. لا تخلط بين «Salesforce تعرف أي سجل هذا» و«المؤسسة تعرف أي شيء تجاري هذا». إنهما مشكلتا تعريف مختلفتان، والثانية تعود إلينا في التكامل والبيانات الرئيسية.

الكائنات أكثر من مجرد تخزين

هذا هو التحول الذي أريدك أن تُحدثه قبل بقية هذا الفصل. الكائن ليس مجرد مكان لتخزين البيانات. والحقل ليس مجرد عمود، والعلاقة ليست مجرد مفتاح خارجي. أستخدم المقارنات بقواعد البيانات حين أُدرّس، لأنها تتصل بما يعرفه الناس مسبقًا. لكن إذا توقفنا عندها، تفوتنا المعمارية.

الكائن الذي نختاره يحدد القدرات التي تأتي معه. ونوع الحقل يؤثر في التحقق والتكامل والبحث والتقارير وطريقة قراءة الأنظمة الأخرى للبيانات. والعلاقة تحدد دورة الحياة والملكية والمشاركة والحذف. والمكان الذي نضع فيه البيانات يؤثر في التخزين والأداء وقابلية التوسع. ولأن كل هذا يعمل على منصة مشتركة، فإن خيارًا لا ضرر منه مع مئة سجل قد يتصرف بشكل مختلف تمامًا مع مئة مليون. وسنتناول هذه القرارات واحدًا تلو الآخر.

ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. لسنوات، ساعدت الأسماء والأوصاف الجيدة المسؤول أو المطوّر التالي على فهم ما بنيناه. والآن تقرأ الآلات هذا السياق أيضًا. نظام ذكاء اصطناعي يعمل مع حقل اسمه Flag2__c يواجه المشكلة نفسها التي يواجهها مطوّر جديد: ماذا يعني هذا الشيء؟ البيانات الوصفية لم تعد زينة؛ إنها جزء من الطريقة التي تفهم بها الآلات التطبيق.

ما الذي يقرره المعماري هنا

• هل أصمّم للمنصة التي أعمل عليها فعلًا، أم أعامل Salesforce كقاعدة بيانات عامة؟
• أي أجزاء تصميمي مفاهيم عمل، وأيها خيارات تنفيذ في Salesforce؟
• ما سلوك المنصة الذي يأتي مع البنية التي أوشك على إنشائها؟
• أي الحدود تعبير عن المعمارية المشتركة، وأيها سيشكّل هذا التصميم؟
• إذا كان تغيير هذه البنية سيصعب لاحقًا، فهل أعاملها كقرار معماري؟

في الفصل 2 قلنا: لا تصمّم من Setup. والآن تعرف سببًا آخر. النقر على New Custom Object لا يعطيك جدولًا فحسب؛ بل يصل قطعة أخرى من معماريتك بمنصة متعددة المستأجرين تقودها البيانات الوصفية. لكن قبل أن تقرر أي كائن تُنشئ، هناك سؤال أكثر أساسية: هل ينبغي أن تعيش هذه البيانات هنا أصلًا؟ هذا هو التالي.

للاستزادة

• Salesforce Architects، Platform Multitenant Architecture (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-02، وأُعيد التحقق في 2026-10-12): تُخزَّن تعريفات الكائنات والحقول كبيانات وصفية، لا كجداول جديدة؛ جداول مشتركة (MT_Objects، MT_Fields، MT_Data، MT_Indexes) مفهرسة بـ OrgID؛ والبيانات الوصفية نفسها توفّر واجهات REST وSOAP.
• Salesforce Architects، Architecture Basics (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-02، وأُعيد التحقق في 2026-10-12): حدود governor وحدود التنفيذ حتى لا تحتكر الشيفرة والمعاملات «موارد المعالجة المشتركة» (don’t monopolize shared compute resources).