أنواع بيانات المؤسسة

🌐 متاح أيضًا بـ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 من 6 في فصل فهم بيانات المؤسسة، الفصل 4 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: Salesforce نظام واحد بين أنظمة كثيرة · التالي: الأنظمة المحيطة بـ Salesforce

السؤال الذي تجيب عنه هذه الوحدة: ما أنواع البيانات التي تحتفظ بها المؤسسة، ولماذا تنتمي إلى أماكن مختلفة؟

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

ابدأ بالنوع، لا بالكائن

بصفتنا أهل Salesforce، نترجم المتطلبات إلى هياكل على الفور تقريبًا: العميل، حساب؛ الصورة، File؛ الحالة، قائمة اختيار. هذا مفيد في النهاية. أما على مستوى المؤسسة، فأريد أولًا أن أعرف نوع المعلومات التي أتعامل معها. هناك طرق كثيرة لتصنيفها (ومرجع المعرفة DAMA هو المرجع المعياري)، وأجد ستة أنواع مفيدة: البيانات الرئيسية، والمرجعية، وبيانات المعاملات، والبيانات الوصفية، والتحليلية، وغير المهيكلة. الفئات ليست المعمارية. إنها وسيلة لطرح أسئلة أفضل.

البيانات الرئيسية: الأشياء التي تعرفها الأعمال

تصف البيانات الرئيسية الأشياء الدائمة التي تدور حولها الأعمال: العملاء، والمنتجات، والتسعير، والموظفون، والموردون، والمواقع، والأصول. في مؤسسة Salesforce (org) للمبيعات، هذه هي الحسابات وجهات الاتصال، ومنتجاتك ودفاتر الأسعار. في Steve Trucking، شريك التجزئة (Retail Partner) بيانات رئيسية. Keystone ليس حدثًا؛ إنه مؤسسة تربطها بـ Steve Trucking علاقة مستمرة. ومراكز التوزيع التسعة بيانات رئيسية أيضًا.

البيانات الرئيسية تعيش أطول من المعاملات التي تستخدمها: شريك تجزئة واحد قد تكون له ملايين التوصيلات. لذا فالسؤال الأول عنها دائمًا من يملكها؟ قد لا يكون Salesforce. قد يملك ERP المنتجات. قد يملك Salesforce العملاء المحتملين بينما يصبح ERP هو المرجع المعتمد بمجرد أن يصبحوا عملاء. وقد تملك منصة MDM الهوية المؤسسية للعميل المجمَّعة من عدة أنظمة. الفصل 6، البيانات الرئيسية والهوية، يتعمق في ذلك. أما الآن، فتعرّف على الشكل.

البيانات المرجعية: المفردات التي تتشاركها الأعمال

البيانات المرجعية هي المفردات المضبوطة المستخدمة لتصنيف بيانات أخرى: رموز الدول، والعملات، وفئات المنتجات، ورموز الأسباب، والحالات. حالات التوصيل في Steve Trucking (مجدولة، محمّلة، خرجت للتوصيل، على وشك الوصول، تم التوصيل، تم التركيب، استثناء، مُرتجعة) بيانات مرجعية. إنها ليست توصيلات؛ إنها الكلمات المستخدمة لوصف التوصيلات.

تبدو صغيرة وغير مؤذية، وغالبًا ما تكون قائمة اختيار من ثماني قيم. لا تخلط بين الصغير وغير المهم. إذا قال Salesforce Delivered، وقال ERP Complete، وأرسل شريك تجزئة D، فعلى أحدهم أن يحدد ما يعنيه كل منها وكيف تُطابَق. البيانات المرجعية هي المكان الذي تختبئ فيه افتراضات التكامل.

بيانات المعاملات: ما الذي حدث

تسجّل بيانات المعاملات النشاط: طلب قُدِّم، ودفعة سُدّدت، وتوصيلة اكتملت، وحالة فُتحت. في org المبيعات نفسه، هذه هي عروض الأسعار وبنودها، والطلبات وبنودها، والمدفوعات: كل منها يشير إلى عميل ومنتج. ومليون توصيلة سنويًا في Steve Trucking بيانات معاملات، وكذلك تحديثات حالتها: نحو ثمانية لكل توصيلة، أي ثمانية ملايين تغيير حالة في السنة، في عمل ينمو 30% سنويًا.

هذا منحنى نمو مختلف تمامًا عن البيانات الرئيسية. ثلاثة شركاء تجزئة في الأعلى؛ وملايين الصفوف في الأسفل. وهنا يصبح «عدد الأصفار» عند Steve (Steve’s Number of Zeros) مهمًا: لا يمكنك أن تنظر إلى شريك التجزئة ← التوصيلة ← الحالة وتعطي كل صندوق الوزن نفسه. مع بيانات المعاملات أفكر فورًا في الحجم، والسرعة، والاحتفاظ، والتاريخ، والأرشفة، والتكامل، وكيف يحتاج الناس فعلًا إلى العثور عليها. ويقضي الجزء 2 وقتًا طويلًا هناك.

البيانات الوصفية: بيانات عن البيانات

لقد كنت تعمل مع البيانات الوصفية طوال الدورة: تعريف الكائن، ونوع الحقل، ووصفه، وعلاقاته. والمؤسسة كلها لديها ذلك: مخططات مستودع البيانات، وتعيينات التكامل، وكتالوجات البيانات، وعقود API، ولكل حقل مالك، ومستوى حساسية، وتعريف، وسلسلة نَسَب، وقاعدة احتفاظ. القيم بيانات؛ ووصف ما تعنيه بيانات وصفية. وكما قال الفصل 3، Flag2__c لا يخبر أحدًا بشيء، وهذا يهم أكثر الآن بعد أن صار الذكاء الاصطناعي يقرأ البيانات الوصفية ليفهم معنى البيانات.

البيانات التحليلية: بيانات صنعناها من بيانات أخرى

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

البيانات غير المهيكلة: ما لا يتسع في الصفوف

المستندات، وملفات PDF، والصور، والصوت، والفيديو، ورسائل البريد الإلكتروني، والنصوص المفرَّغة، ومقالات المعرفة. في Steve Trucking، صور التوصيل: نحو أربع لكل توصيلة، وأكثر مع التركيب، أي أربعة إلى خمسة ملايين في السنة. الصورة ليست مجرد حقل آخر. إنها كبيرة، وقد تُظهر داخل منزل شخص ما، ولها قواعد احتفاظ خاصة بها، ويُبحث فيها بطريقة مختلفة، إن بُحث فيها أصلًا.

هذا النوع يزداد أهمية كل عام، لأن الذكاء الاصطناعي صار قادرًا على فعل أشياء مفيدة بمعلومات كانت تقبع خارج النموذج المهيكل. النص المفرَّغ بيانات. ودليل PDF بيانات. وصورة التركيب بيانات. هذا لا يعني أنها تنتمي إلى نواة Salesforce. بل يعني أنها تنتمي إلى خريطة الأنظمة.

Click to enlarge

ستة أنواع، وأربعة أسئلة لكل منها. الإجابات تتغيّر من نوع إلى نوع، وهذا هو المقصود.

النوع نصف السؤال فقط: حِمل العمل

معرفة نوع البيانات التي لدينا لا تكفي. أريد أن أعرف أيضًا ما الذي نفعله بها. ثلاثة أحمال عمل مهمة هنا، والخلط بينها يصنع معمارية سيئة.

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

التحليلي: فهم الأعمال. كل توصيلة على مدى خمس سنوات، مجمَّعة حسب الشريك ومركز التوزيع، ومقارنة سنة بسنة، ومربوطة ببيانات المالية. الآن نحن نمسح ونجمّع. هذا هو OLAP، أي المعالجة التحليلية عبر الإنترنت، وهو ما بُنيت من أجله مستودعات البيانات والـ Lakehouses ومنصات التحليلات. ببساطة: الـ org يدير الأعمال؛ ومستودعات البيانات والبحيرات تحلّلها. ومن الأخطاء الكلاسيكية وضع ذلك الحِمل على المنصة التشغيلية ثم التفاجؤ مع نمو الأصفار. إذا أراد أحدهم مسح كميات هائلة من التاريخ مرارًا، فلا تعامل ذلك على أنه «مجرد تقرير آخر». اسأل هل هذه هي المنصة الصحيحة. يعود الجزء 2 إلى ذلك في التصميم للنطاق الواسع (coming soon) (لا تجعل النواة مستودع بياناتك)، ويُظهر الجزء 3 كيف تُبنى الهياكل التحليلية في ما وراء العلائقية (coming soon).

التدفقي: بيانات في حركة. الأحداث، والقياس عن بُعد، وتغييرات الحالة، وقراءات المستشعرات. شاحنات Steve Trucking ترسل نحو 200,000 قراءة GPS في اليوم. يهتم المرسِل بمكان الشاحنة 217 الآن. هل يحتاج Salesforce إلى الاحتفاظ بكل قراءة دقيقة بدقيقة من كل شاحنة؟ ربما لا. «أين هي الآن؟» و«ما اتجاهات كفاءة المسارات في الربع الماضي؟» يأتيان من المصدر نفسه ويقودان إلى قرارات تخزين مختلفة تمامًا.

ما السرعة التي يجب أن تنتقل بها؟

ثم زمن الاستجابة. في الصف أصوغها هكذا: الوقت الفعلي (real time) هو أن تنتظر عند الباب حتى يعود أحدهم. ترسله وتقف هناك، لأنك لا تستطيع المتابعة حتى يعود. هذا هو المتزامن. وشبه الوقت الفعلي (near real time) هو أن تراه يغادر ثم تنشغل بشيء آخر؛ وعندما يعود بعد قليل، تتعامل مع الأمر. هذا هو غير المتزامن. ثم هناك الدفعات (batch): لا أحد يخرج من الباب واحدًا تلو الآخر. البيانات تنتظر وتنتقل كمجموعة وفق جدول: كل ساعة، أو كل بضع ساعات، أو يوميًا. هناك مواقف كثيرة تكفي فيها الدفعات، وبعضها لا تكفي فيه. ومعرفة أيها أيّها هي المهمة. هذه الثلاثة ليست مجرد مصطلحات تكامل؛ إنها خيارات معمارية.

خذ تكامل ERP الشائع. يُنشأ منتج جديد في ERP الساعة 11 صباحًا. هل يحتاج فريق المبيعات فعلًا إلى بيعه بحلول الظهر؟ رأيت الإجابتين. بعض العملاء يريدونه في أسرع وقت ممكن؛ وآخرون يقولون: إذا لم نكن قد شحنّا ذلك الـ SKU إليك، فلا يمكننا أن نتوقع منك بيعه بعد. لذا تكون المنتجات عادةً يومية، وأحيانًا أسرع. والعملاء، يوميًا على الأقل؛ رأيت كل ساعة، وفي الحالات القصوى شبه الوقت الفعلي. أما الطلبات فمختلفة: يجب أن يبدأ التنفيذ، لذا شبه الوقت الفعلي. يُغلق مندوب المبيعات الصفقة ويمضي، ويصل الطلب إلى ERP في ثوانٍ إلى دقيقة أو دقيقتين. لا يوجد زمن استجابة صحيح واحد لـ«بيانات المؤسسة». اسأل عمّا تحتاج إليه الأعمال فعلًا، ولا تجعل كل شيء في الوقت الفعلي لأنه يبدو مثيرًا للإعجاب. للوقت الفعلي ثمن.

الأسئلة الأربعة وراء الفئات

لست بحاجة إلى التجول معلنًا «هذه بيانات معاملات!». التصنيف موجود ليطلق أربعة أسئلة عن كل مجموعة بيانات مهمة:

• من يملكها؟ أي نظام هو المرجع المعتمد؟ أقسّمه إلى ثلاثة: أين تُنشأ، وأين تُعدَّل، وأين يُشار إليها؟ يتعمق الفصل 6 في ذلك (أين تُنشأ، وأين تُحرَّر، وأين يُرجَع إليها، وبأي سرعة؟).
• ما سرعة تغيّرها؟ مرة في السنة، يوميًا، عشرات إلى مئات المرات في الثانية؟
• ما حجمها؟ عشرة سجلات، عشرة آلاف، عشرة ملايين، عشرة مليارات؟
• ما دورة حياتها؟ هل تعيش إلى الأبد، أم تُؤرشف، أم يجب حذفها، أم تفقد قيمتها مع الوقت؟

هذه الأربعة تخبرني أكثر بكثير من «هل يستطيع Salesforce تخزين هذا؟». وهي تجمع ما تعلمناه بالفعل: الملكية، ودورة الحياة، و«عدد الأصفار»، وأين تعيش البيانات.

عمل واحد ينتج كل الأنواع

في Steve Trucking، شريك التجزئة بيانات رئيسية؛ ومفردات الحالة بيانات مرجعية؛ وكل توصيلة بيانات معاملات؛ وتعريفات حقولها بيانات وصفية؛ وبطاقة أداء الالتزام بالمواعيد لخمس سنوات بيانات تحليلية؛ وصورة التركيب بيانات غير مهيكلة؛ وتغذية GPS بيانات تدفقية. كلها «بيانات Steve Trucking». ولا شيء من ذلك يعني أنها تنتمي إلى قاعدة البيانات نفسها. هذا هو التحول.

ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. للإجابة عن سؤال واحد، قد يحتاج وكيل إلى سجل عميل مهيكل، ومعاملة حديثة، ودليل PDF، ونص مفرَّغ لمكالمة خدمة، وبيانات قياس عن بُعد حية. تصبح البيانات غير المهيكلة والتدفقية أجزاءً أساسية من المعمارية حتى عندما لا تنتمي إلى قاعدة بيانات CRM، ولا يزال على المعماري أن يعرف من يملك كل مصدر، ومدى حداثته، وهل ينبغي للوكيل أن يثق به.

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

• ما نوع كل مجموعة بيانات مهمة، ومن يملكها.
• هل حِمل عملها تشغيلي، أم تحليلي، أم تدفقي، أم مزيج.
• ما سرعة تغيّرها، وما السرعة التي تحتاج بها الأنظمة الأخرى فعلًا إلى رؤية التغيير.
• كيف يشكّل الحجم ودورة الحياة مكان عيشها ومدته.
• هل ينبغي لـ Salesforce أن يملكها، أو يحتفظ بنسخة منها، أو يشير إليها، أو يتركها في مكان أنسب لحِمل العمل.

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

للاستزادة

• DAMA International، DAMA-DMBOK: Data Management Body of Knowledge، الطبعة الثانية (2017): المرجع المعياري لفئات البيانات وإدارة البيانات (بالإنجليزية).
• موجز Steve Trucking، القسم 4 (الأحجام).