ابنِ النموذج المنطقي

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

السؤال الذي تجيب عنه هذه الوحدة: كيف أحوّل نموذجًا مفاهيميًا إلى نموذج بيانات منطقي؟

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

اجلس، ابقَ، نمذِج

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

ما الذي يصفه؟ للكلب اسم وتاريخ ميلاد. وللمالك اسم ورقم هاتف وعنوان. وللحيلة اسم ودرجة صعوبة. كل حقيقة توضع على المربع الذي تصفه.

ثم كائن الربط. مدى إتقان Bella لحيلة «اجلس»، ومتى تعلّمتها: هل يصف ذلك Bella؟ ليس تمامًا؛ فهي أفضل في بعض الحيل من غيرها. هل يصف «اجلس»؟ لا؛ فكل كلب يؤدي «اجلس» بطريقة مختلفة. إنه يصف Bella و«اجلس» معًا، لذلك ينتمي إلى حيلة الكلب: مستوى المهارة وتاريخ التعلّم. ولهذا يوجد كائن الربط: بعض الحقائق لا تنتمي إلا إلى الزوج.

أي كلب هو أي كلب؟ جرّب الاسم أولًا. هناك كلاب كثيرة اسمها Max، فالاسم ليس فريدًا. رقم هاتف المالك؟ لدى Marcus كلبان على الهاتف نفسه، والناس يغيّرون أرقامهم، وهو بيانات شخصية لأحدهم، ستُنسخ إلى كل نظام يشير يومًا إلى كلب. رقم الشريحة الإلكترونية (microchip) يبدو أفضل: إنه فريد، ولا يتغيّر. لكن الجرو الجديد قد لا يكون مزوّدًا بشريحة بعد، والمفتاح لا يمكن أن يكون فارغًا. لذلك تبقى الشريحة، بوصفها شيئًا يُعرف به الكلب أيضًا، ويحصل الكلب على معرّف الكلب (Dog ID) الخاص به: رقم يؤدي وظيفة واحدة مملّة، هي تمييز كلب من آخر.

Click to enlarge

هذه هي الأسئلة نفسها التي سنطرحها الآن على Steve Trucking، والأسباب التي يقصر بها الاسم والهاتف والشريحة كلٌّ بطريقته تتحول إلى قاعدة أتمسك بها منذ سنوات.

المفاهيمي يخبرني بما يوجد؛ والمنطقي يخبرني بما يعنيه كبيانات

خذ الشاحنة. ما الذي أحتاج إلى معرفته عن الشاحنة؟ ربما رقم الوحدة، ورقم الهيكل (VIN)، والشركة المصنّعة، والطراز، وسنة الطراز، ولوحة الترخيص، والمسافة المقطوعة الحالية، والحالة. هذه سمات الشاحنة.

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

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

Click to enlarge

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

ينبغي أن تصف السمات الكيان

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

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

ثم علينا أن نتحدث عن المعرّفات الفريدة

السمات تصف الأشياء. لكن هناك مشكلة أخرى يجب حلها: كيف أعرف أي شيء هو أي شيء؟

مستلمان اسم كل منهما John Smith. هل هما الشخص نفسه؟ ربما؛ وربما لا. الاسم لا يكفي. العنوان؟ الناس ينتقلون. أرقام الهواتف تتغيّر. عناوين البريد الإلكتروني تتغيّر. حتى اسم شريك التجزئة يمكن أن يتغيّر.

هذا يقودنا إلى المفاتيح: ما يتيح لنا تحديد شيء ما بشكل فريد في نموذجنا. وهو مجال كوّنت فيه رأيًا قويًا إلى حد ما على مر السنين. أريد في المعرّف أربعة أشياء:

فريد. ثابت لا يتغيّر. بلا معنى. ليس PII أبدًا.

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

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

بلا معنى. يبدو هذا غريبًا أول مرة تسمعه. لماذا أريد أن يكون المعرّف بلا معنى؟ لأن المعنى يتغيّر. تخيّل أن أحدهم بنى معرّف توصيلة يرمّز فيه مركز التوزيع، وشريك التجزئة، وتاريخ التوصيل، ورقمًا تسلسليًا: PHX-KEY-20261002-0042. يبدو ذكيًا. ثم يعيد المستلم جدولة الموعد إلى الجمعة. هل نغيّر المعرّف؟ إن لم نفعل، فهو يكذب علينا. وإن فعلنا، فقد غيّرنا المعرّف الفريد للتوصيلة لأن إحدى سماتها تغيّرت، وكل نظام خزّن المعرّف القديم فقد أثرها للتو. كان المعرّف يحاول أداء وظيفتين: تحديد التوصيلة ووصفها. أفضّل أن أترك السمات تصفها، وأن أترك المعرّف يؤدي وظيفة واحدة مملّة: أن يحددها. المعرّفات المملّة معرّفات جيدة.

ليس PII أبدًا. هذا الشرط مهم بما يكفي لأفرده وحده. لا تستخدم معلومات التعريف الشخصية (PII) معرّفًا لمجرد أنها تبدو فريدة. في Steve Trucking من المغري التعرّف على المستلم برقم هاتفه. لكن المفتاح يُنسخ إلى كل مكان تحتاج فيه الأنظمة إلى ربط السجلات: عمليات التكامل، والتصديرات، والسجلات (logs)، وملفات الحالة المرسلة إلى شركاء التجزئة، ومستودع البيانات، وبيانات الاختبار. اجعل رقم الهاتف هو المفتاح، وستكون قد نشرت البيانات الشخصية للمستلم في المعمارية كلها.

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

لذلك قاعدتي هي: فريد، ثابت لا يتغيّر، بلا معنى، ليس PII أبدًا.

المفاتيح الطبيعية والمفاتيح البديلة

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

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

الشيء الواحد يمكن أن تكون له عدة معرّفات مفيدة

معرّف السجل الداخلي ليس بالضرورة المعرّف الذي تستخدمه كل الأنظمة الأخرى. قد تعرّف Steve Trucking التوصيلة داخليًا بمعرّف مُولَّد. وكل شريك تجزئة يعرف التوصيلة نفسها برقم طلبه الخاص: Keystone في بيان الشحنة بصيغة CSV، وRedrock في واجهة API الخاصة به، وBrightwave في رسائل EDI. وسنوات التاريخ الثماني في RouteDesk، أداة الإرسال القديمة، تستخدم معرّفات التوصيل الخاصة بـ RouteDesk.

هذه المعرّفات مهمة. علينا أن نحتفظ بها ونربطها بشكل صحيح، لأن تحديث الحالة يجب أن يعود إلى كل شريك برقمه هو. لكن ليس عليها كلها أن تصبح المعرّف الفريد للتوصيلة. «ما معرّفه؟» يمكن أن يكون له أكثر من إجابة، وعلى المعماري أن يعرف أي معرّف هو المرجع المعتمد في أي سياق. وسنعود إلى هذا مع البيانات الرئيسية والتكامل.

العلاقات تعتمد على المعرّفات الفريدة

والآن عد إلى الخطوط التي رسمناها. بيان الشحنة يسرد التوصيلات. المستلم يتلقى التوصيلات. الطاقم لديه تكليفات طاقم. هذه العلاقات لا تعمل إلا لأننا نستطيع تحديد الأشياء على طرفيها بشكل موثوق.

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

Click to enlarge

في هذه المرحلة ربما تفكر: «Salesforce يعطي كل سجل معرّفًا.» صحيح، وسنصل إلى ذلك. إذا كانت البيانات تعيش في Salesforce، يحصل كل سجل على معرّف يُنشئه Salesforce. إنه مبهم وصعب القراءة، لذلك نعرض عادةً أيضًا حقل معرّف يستطيع الناس استخدامه، مثل رقم توصيلة D-000184227، وهو حقل Auto Number. كثيرًا ما يظن الناس أن ذلك الرقم هو معرّف السجل، لكنه ليس كذلك: معرّف Salesforce ما زال موجودًا تحته. والنظام الخارجي أو قاعدة البيانات، Oracle أو SQL Server، لها معرّفاتها الفريدة أيضًا. لكن المعمارية قد تضم في النهاية Salesforce، ونظام ERP المالي، وSnowflake، وData 360، وأنظمة الشركاء، وأنظمة لم توجد بعد. النموذج المنطقي يصف بيانات العمل دون أن يجعل كل قرار معتمدًا على تقنية واحدة. أما كيف ينفّذه Salesforce ماديًا فخطوة لاحقة.

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

وأنا أحوّل نموذجًا مفاهيميًا إلى نموذج منطقي، فأنا أقرر:

• أي السمات تصف كل كيان فعلًا.
• كيف يُحدَّد كل كيان بشكل فريد، وهل ذلك المعرّف مستقر بما يكفي ليكون معرّفه الفريد.
• أي معرّفات العمل (أرقام طلبات الشركاء، والمعرّفات القديمة) يجب الاحتفاظ بها وربطها.
• هل تُستخدم معلومات حساسة مفتاحًا.
• هل تربط العلاقات الكيانات عبر معرّفات فريدة موثوقة.

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

للاستزادة

• Custom Field Types (opens in a new tab)، Salesforce Help (بالإنجليزية، تم التحقق في 2026-10-09): يمنح Auto Number كل سجل رقمًا فريدًا بتنسيق عرض مثل بادئة وأصفار في البداية؛ وهو ليس معرّف Salesforce للسجل. انظر أيضًا Auto-Number Fields Are Not Always Sequential (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-09).