نموذج البيانات هو الهيكل العظمي
متاح أيضًا بـ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)
الوحدة 2 من 7 في فصل التفكير كمعماري بيانات، الفصل الأول من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: التفكير كمعماري · التالي: اختبار قابلية التراجع
السؤال الذي تجيب عنه هذه الوحدة: لماذا يهم نموذج البيانات أكثر من أي شيء يُبنى عليه، وكيف تحكم عليه؟
عندما أعلّم معمارية البيانات، هناك عبارة أعود إليها مرة بعد مرة: نموذج البيانات هو الهيكل العظمي.
نموذج البيانات هو الهيكل العظمي للنظام. كل شيء آخر يُبنى حوله، وهو ما يمسك بقية الجسد معًا. لا ترى العظام عندما تنظر إلى شخص ما، لكنها تحدد طول قامته، وكيف يتحرك، وما الذي يستطيع حمله.
فكّر في كل ما نبنيه في تنفيذ Salesforce. نبني الأتمتة حول نموذج البيانات. نكتب شيفرة Apex تعمل عليه، وعمليات Flow تقرؤه وتحدّثه. نبني عمليات تكامل ترسل البيانات إليه وتسحبها منه. ننشئ التقارير والتحليلات عليه، ونصمم الأمان حوله. وبشكل متزايد، نبني وكلاء ذكاء اصطناعي يحتاجون إلى فهم تلك البيانات والتصرف بناءً عليها. وكل ذلك يعتمد على البنية التي تحته.
لهذا السبب من المهم جدًا أن تُحكم نموذج البيانات مبكرًا. يمكنك أن تغيّر الهيكل العظمي لاحقًا. لكن الأرجح أن ذلك سيؤلم.
ابدأ بالأعمال
Section titled “ابدأ بالأعمال ”يبدأ نموذج البيانات الجيد بسؤال بسيط: ما الذي يحتاج العمل فعلًا إلى تمثيله؟ ليس «ما كائنات Salesforce المتوفرة لدينا؟» وبالتأكيد ليس «ما الذي أستطيع بناءه بسرعة؟»
نحاول أن نفهم العمل أولًا. ما الأشياء المهمة في هذا العمل؟ كيف ترتبط ببعضها؟ من يملكها؟ كيف تتغير مع الوقت؟ ما الذي يجب تذكّره، وما الذي يُشارَك عبر عمليات العمل؟ ولا نبدأ في ترجمتها إلى كائنات وحقول وعلاقات إلا بعد أن نفهم تلك الأشياء.
يبدو هذا بديهيًا. لكن من السهل جدًا في الواقع أن نعكس الترتيب. يرى أحدهم شيئًا يشبه الفرصة (Opportunity) أو الحالة (Case) أو الأصل (Asset)، فيبدأ فورًا في التصميم حوله. أحيانًا يكون هذا صحيحًا تمامًا. وأحيانًا نحاول إدخال وتد مربع في ثقب دائري، وبمجرد أن يُبنى ما يكفي حول ذلك القرار، يصبح إخراج الوتد مكلفًا جدًا.
إليك سؤالًا أسمعه طوال الوقت. قد يكون لنشاط العميل مواقع توصيل كثيرة. هل ينبغي أن يكون كل موقع حسابًا (Account)، أم كائنًا مخصصًا؟ قبل أن تجيب، لاحظ ما ستحتاج إلى معرفته أولًا: ماذا يعني الموقع لهذا العمل، وماذا يحدث له. هذه هي نمذجة العمل قبل الكائنات. (سأعطيك إجابتي في الفصل 3.)
الدعم. النمو. الأداء.
Section titled “الدعم. النمو. الأداء. ”عندما أنظر إلى نموذج بيانات، أريده أن يجتاز ثلاثة اختبارات: أن يدعم العمل، وأن ينمو مع العمل، وأن يحقق الأداء.
الدعم. يجب أن يدعم النموذج ما يحاول العمل تحقيقه فعلًا. هناك فرق كبير بين نموذج يستطيع تقنيًا تخزين البيانات ونموذج يمثّل العمل تمثيلًا جيدًا فعلًا. إذا وجدت نفسي أضيف باستمرار حقولًا غريبة، وعلامات خاصة، وأتمتة معقدة، واستثناءات، لأن النموذج لا يناسب تمامًا، أبدأ في التساؤل عمّا إذا كانت المشكلة حقًا في الأتمتة. ربما النموذج هو الخطأ. النموذج الجيد ينبغي أن يجعل فهم العمل أسهل، لا أصعب.
النمو. عندما أقول النمو، لا أعني مجرد مزيد من السجلات. الحجم مهم: عشرة آلاف سجل ومئة مليون سجل يخلقان مشكلات مختلفة جدًا. لكن الأعمال تنمو أيضًا في التعقيد. فهي تضيف منتجات، وتدخل أسواقًا جديدة، وتستحوذ على شركات، وتغيّر عملياتها، وتضيف قنوات، وتربط أنظمة جديدة. وتكتشف أن شيئًا ظنّته شيئًا واحدًا هو في الحقيقة خمسة أشياء مختلفة. النموذج الذي يعمل بشكل رائع اليوم قد يصبح فخًا إذا لم يترك مساحة للغد. لهذا أفضّل التصاميم التي تنمو عن طريق الإضافة على التصاميم التي تظل تغيّر ما هو موجود. إضافة شيء جديد عادةً أسهل من إعادة تعريف شيء تعتمد عليه عشرات الأشياء الأخرى.
الأداء. البيانات لا تبقى ساكنة. نكتبها، ونبحث عنها، ونستعلم عنها، ونشاركها، ونبني عليها التقارير، وندمجها، وبشكل متزايد تسترجعها أنظمة الذكاء الاصطناعي سياقًا قبل أن تتصرف. قد يبدو النموذج جميلًا على المخطط ومع ذلك يكون تشغيله مريعًا. لذلك نصمم لكلا الأمرين: كيف تُخزَّن البيانات وكيف ستُستخدم.
ويجب أن يظل يحقق الأداء. يجب أن يحقق الأداء على نطاق واسع: عندما يرتفع عدد المستخدمين، وعندما يرتفع حجم البيانات، في ظروف العالم الحقيقي وفي أوقات الذروة، في أكثر أيام السنة ازدحامًا لا في اليوم المتوسط. ويجب أن يظل يحقق الأداء عندما يحدث شيء غير متوقع.
الدعم. النمو. الأداء. سنظل نعود إلى هذه الاختبارات الثلاثة طوال هذه الدورة.
مسطّح جدًا، أو معقّد جدًا، أو خاطئ ببساطة
Section titled “مسطّح جدًا، أو معقّد جدًا، أو خاطئ ببساطة ”رأيت نماذج البيانات تنحرف بثلاث طرق.
الأولى هي اختيار الشيء الخطأ من البداية. نستخدم كائنًا قياسيًا لأنه يبدو قريبًا بما يكفي، ثم نقضي سنوات في إضافة الاستثناءات لأنه لم يكن مناسبًا قط. هذا هو الوتد المربع.
والثانية هي جعل النموذج مسطّحًا جدًا. كل شيء يذهب إلى كائن واحد، ويبدو ذلك في البداية بسيطًا على نحو رائع. ثم ينمو العمل، فنكتشف أن بعض تلك الأشياء لها دورة حياتها الخاصة، أو يمكن أن تكون لها نسخ متعددة، أو تحتاج إلى أمانها الخاص، أو لها علاقاتها الخاصة. وفجأة نجد أنفسنا نمثّل علاقة واحد-إلى-متعدد بـField 1 وField 2 وField 3، أو بعلامات وأتمتة تزداد تعقيدًا. لم يترك لنا النموذج أي مكان للنمو.
والثالثة هي الخطأ المعاكس: نُفرط في التطبيع. ننشئ مخططًا أنيقًا فيه كائن بعد كائن، وكل مفهوم مفصول تمامًا. جميل تقنيًا، بائس عمليًا. يجد المستخدمون صعوبة في فهمه، وقد تبدأ تخطيطات الصفحات وصفحات Lightning، بقائمة مرتبطة تلو أخرى، في أن تبدو عميقة بلا نهاية. تصبح الاستعلامات أعقد، وتعبر الأتمتة علاقات أكثر، ويصعب إعداد التقارير، وتبذل المنصة جهدًا أكبر للإجابة عن أسئلة عمل عادية.
إذن أيهما الصحيح، المسطّح أم المطبَّع؟ ليست هناك معادلة. تحتفظ في ذهنك بصورة النموذج الأمثل وتفهم المفاضلات كلما ابتعدت عنه. هذا هو فن المعمارية، وسنعود إليه في الوحدة 4 وفي الفصل التالي، حيث نتعلم كيف ننمذج. أما الآن، فأدرك أن البنية نفسها قرار معماري.
احذر من تغيير الهيكل العظمي
Section titled “احذر من تغيير الهيكل العظمي ”بمجرد أن يبدأ النظام في العمل، أصبح شديد الحذر من التغييرات الجوهرية في نموذج البيانات.
لنفترض أن حقلًا نصيًا موجود منذ سنوات، ثم يقول أحدهم: «لم نعد نستخدمه بهذه الطريقة حقًا. فلنحوّله إلى رقم.» يبدو الأمر تغييرًا في حقل. لكن ما الذي يعتمد على ذلك الحقل؟ عمليات Flow، وApex، والتقارير، وعمليات التكامل، وخطوط نقل البيانات، والتطبيقات الخارجية، ووكلاء الذكاء الاصطناعي. وماذا يحدث للبيانات التاريخية؟ المنصة نفسها لن تسمح لك بتغيير نوع الحقل ما دامت شيفرة أو عمليات Flow تشير إليه، وهذا يخبرك إلى أي مدى يمتد التغيير.
أحيانًا لا تكون الإجابة الصحيحة هي تحوير ما هو موجود. بحسب مدى جسامة التغيير، أفضّل أن أنشئ شيئًا جديدًا، وأُجري الترحيل عن قصد، وأُهمل البنية القديمة تدريجيًا:
أضِف بدلًا من أن تحوّر. أعلِن الإهمال بدلًا من أن تفاجئ.
بل إن Salesforce تمنحك طريقة لقول ذلك في البيانات الوصفية: يمكن ضبط Field Usage (استخدام الحقل) لحقل ما على DeprecateCandidate، أي «مخطط لإهماله ولم يعد مستخدمًا». هذا يُعلِّم الحقل لكل من يقرأ الكائن؛ لكنه لا يُخفي الحقل، فإيقافه يظل قرارًا عليك تنفيذه.
لأنه بمجرد أن تعتمد أجزاء أخرى من المعمارية على شيء ما، قد يكون تغيير معناه أخطر بكثير من تغيير اسمه. وأسوأ صورة لذلك هي الحقل الذي يبقى اسمه كما هو بينما يتغير محتواه: كل ما يأتي بعده لا يزال يثق بالاسم.
حتى شيء بسيط مثل تحديد مربع Required (إلزامي) على حقل قد يتحول إلى قنبلة موقوتة. إذا كنت قد جمعت بيانات بالفعل، فبعض السجلات لن يكون فيها ذلك الحقل مملوءًا. ثم بعد أيام أو أسابيع أو شهور، يحدّث أحدهم أحد تلك السجلات، فيفشل الحفظ بسبب الحقل الإلزامي، ولا أحد لديه تلك القيمة. تغيير بسيط مثل جعل حقل إلزاميًا قد تكون له عواقب غير مقصودة ومؤجلة. سنعود إلى Required، وإلى متى تكون القيمة معروفة فعلًا، في الفصل 3.
ما بعد الاختبار: الذكاء الاصطناعي يبني على الهيكل العظمي أيضًا. اطلب من أداة ذكاء اصطناعي أن تبني تطبيقًا، وستُنشئ الكائنات والحقول وعمليات Flow وApex والمكوّنات والاختبارات في دقائق. إذا كان نموذج البيانات الأصلي خاطئًا، فنحن لم نتجنب عواقب القرار السيئ؛ بل سرّعناها، لأن كل طبقة مُنشأة هي شيء آخر يعتمد على تلك البنية. لهذا أريد معماريًا بشريًا يراجع نموذج البيانات الذي أنشأه الذكاء الاصطناعي، ويفهمه، ويكون مسؤولًا عنه. والوحدة 7 تأخذ هذا إلى أبعد.
الهيكل العظمي أولًا
Section titled “الهيكل العظمي أولًا ”خلال هذه الدورة، سنتحدث عن كثير من التقنيات: الكائنات والعلاقات، وأحجام البيانات الكبيرة، والاستعلامات، والتكامل، والترحيل، والمعاملات، والأمان، وData 360، والذكاء الاصطناعي. وتحت كل ذلك يقبع نموذج البيانات.
إذا كان النموذج يدعم العمل، ويستطيع النمو معه، ويحقق الأداء للطرق التي سنستخدم بها البيانات، فقد بنينا أساسًا متينًا. وإذا أخطأنا في الأساس، يصبح كل ما يأتي بعده أصعب.
نموذج البيانات هو الهيكل العظمي. على المعماريين أن يكونوا حذرين جدًا عندما يصممون الهيكل العظمي. فإجراء تغييرات على البنى القائمة قد تكون له عواقب متتالية.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”- هل يدعم النموذج العمل، ويستطيع النمو معه، ويحقق الأداء للطرق التي ستُستخدم بها البيانات.
- هل يناسب المفهومُ كائنًا قياسيًا أم أنه وتد مربع.
- إلى أي حد يُجعل النموذج مسطّحًا أو مطبَّعًا، ولماذا.
- هل ينبغي أن يكون تغيير الهيكل العظمي إضافةً أو ترحيلًا أو إهمالًا، بدلًا من تغيير في المكان نفسه.
للاستزادة
Section titled “للاستزادة ”- Considerations for Converting the Field Type of a Custom Field (opens in a new tab)، Salesforce Help (بالإنجليزية، تم التحقق في 2026-10-02؛ وأُعيد التحقق في 2026-10-12): أي تغييرات النوع قد تُفقد البيانات، ولماذا لا يمكنك تغيير نوع حقل تشير إليه Apex أو عمليات Flow أو العمليات (processes).
- Data Classification Metadata Fields (opens in a new tab)، Salesforce Help (بالإنجليزية، تم التحقق في 2026-10-02؛ وأُعيد التحقق في 2026-10-12): قيم Field Usage (Active، DeprecateCandidate، Hidden)، وحقول التصنيف الأخرى.