ارسم العلاقات
متاح أيضًا بـ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 في فصل نمذجة البيانات من أجل المعنى، الفصل 2 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: أنصت إلى الأسماء · التالي: ابنِ النموذج المنطقي
السؤال الذي تجيب عنه هذه الوحدة: كيف أحوّل الكيانات المرشّحة إلى نموذج بيانات مفاهيمي؟
لدينا أسماء على السبورة. والآن أريد أن أعرف عن الخطوط بين المربعات، لأن مجموعة من الكيانات ليست نموذج بيانات حقًا بعد. العلاقات هي حيث يعيش جزء كبير من المعنى. شريك التجزئة يُشغّل مراكز توزيع. بيان الشحنة يسرد التوصيلات. التوصيلة تذهب إلى مستلم. الطاقم يُشغّل شاحنة. كل عبارة من هذه تخبرني بشيء عن العمل، وكل واحدة تمنحني سؤالًا آخر أطرحه.
ابدأ بلغة العمل
Section titled “ابدأ بلغة العمل ”ما زلت لا أريد الحديث عن Salesforce. لست أسأل هل ينبغي أن تكون هذه علاقة بحث (lookup) أم علاقة رئيسي-تفصيلي (master-detail)، ولا أفكر في كائنات الربط في Salesforce (Salesforce Junction Objects)، ولا أقرر ما يحدث عند حذف سجل أب. أحاول أن أفهم علاقة العمل.
خذ عبارة «شريك التجزئة يُشغّل مراكز توزيع.» تبدو بسيطة. لكن هل لشريك التجزئة مركز توزيع (DC) واحد أم مراكز كثيرة؟ في Steve Trucking، يُشغّل كل شريك تجزئة مركز توزيع إقليميًا في كل منطقة تخدمها Steve Trucking، إذن مراكز كثيرة. هل يمكن أن ينتمي مركز التوزيع إلى أكثر من شريك تجزئة؟ هل لمركز التوزيع أهمية بذاته، بموظفيه وتاريخه، أم هو مجرد عنوان؟ إذا غادر شريك التجزئة، هل ما زالت تهمنا مراكز توزيعه؟
هذه ليست أسئلة عن Salesforce. إنها أسئلة عن العمل، وإجاباتها قد تغيّر النموذج تمامًا.
اقرأ الخطوط
Section titled “اقرأ الخطوط ”قبل أن نتعمق أكثر، أريد أن أعطيك اللغة التي سنستخدمها في كل مخطط من الآن فصاعدًا. إنها لغة صغيرة. الخط بين مربعين يقول إن الشيئين مرتبطان، والعلامات على طرفيه تقول كم.
ابدأ بخط بسيط، بلا أي علامات. من هنا أبدأ على السبورة: أعرف أن هذين الاسمين مرتبطان، لكنني لم أسأل كيف بعد. ثم تحصل الأطراف على علامات. الشَّرطة الواحدة العرضية على الخط تعني واحدًا. وقدم الغراب (crow’s foot)، الطرف الذي ينقسم إلى ثلاثة مثل قدم الطائر، تعني كثيرًا. لاحقًا في هذه الوحدة سترى علامة ثانية تظهر بجوار الأولى، شَرطة أو دائرة، وتلك تجيب عن سؤال مختلف: هل يمكن ألّا يوجد شيء؟
القاعدة الوحيدة التي عليك تذكّرها: تقرأ كل علامة عند المربع الذي تلامسه. العلامة الأقرب إلى المربع هي الحد الأقصى؛ والعلامة التالية بعدها هي الحد الأدنى.
اجلس، ابقَ، نمذِج
Section titled “اجلس، ابقَ، نمذِج ”قبل Steve Trucking، لنعد إلى الكلاب من الوحدة 1. كان لدينا خمسة مربعات: المالك، والمربّي، والكلب، والسلالة، والحيلة. والآن أسأل عن الخطوط بينها.
واحد أم كثير؟ يمكن أن يملك المالك أكثر من كلب؛ لدى Ana كلبان. وللكلب مالك واحد، في نموذجنا على الأقل. هذه علاقة واحد-إلى-كثير: شَرطة عند المالك، وقدم غراب عند الكلب. والمربّي بالشكل نفسه: مربٍّ واحد يربّي كلابًا كثيرة.
هل يمكن ألّا يوجد شيء؟ جاء Max من مأوى الحيوانات، فليس له مربٍّ على الإطلاق. يحصل طرف المربّي على دائرة: للكلب صفر أو مربٍّ واحد. لكن لكل كلب مالكًا، لذلك يحصل ذلك الطرف على شَرطة ثانية: واحد بالضبط.
كثير إلى كثير؟ الكلب يعرف حيلًا كثيرة، والحيلة، «اجلس» مثلًا، تعرفها كلاب كثيرة. هذه علاقة كثير-إلى-كثير، وهنا بالضبط أبحث عن مفهوم مخفي. هل هناك شيء يخص معرفة هذا الكلب لهذه الحيلة؟ مدى إتقانها لها، ومتى تعلّمتها. للعلاقة حقائقها الخاصة، فتصبح شيئًا قائمًا بذاته: حيلة الكلب (Dog Trick)، واسم الكلب أولًا في الاسم الإنجليزي، لأن الكلب هو الذي يقودها.
ماذا يعني كل خط؟ المالك يملك الكلب. المربّي يربّيه. الكلب يعرف حيله. سمِّ الخطوط، وسيستطيع أي أحد أن يقرأ لك النموذج.
الآن، أم عبر الزمن؟ هل يهتم أحد بمدى إتقان Bella لحيلة «اجلس» اليوم، أم بكيف وصلت إلى ذلك؟ إذا كان مدرّب يختبرها كل بضعة أشهر، فكل اختبار سجل قائم بذاته: تقييم الحيلة (Trick Assessment)، بالتاريخ ومستوى المهارة ومن أجرى الاختبار، تحت حيلة الكلب التي ينتمي إليها. حتى العلاقة التي أصبحت شيئًا يمكن أن يكون لها تاريخها الخاص.
السلالة أتركها غير مربوطة الآن. ما زالت سؤال الوحدة 1: مربع قائم بذاته أم كلمة مكتوبة على الكلب؟ والوحدة 4 تحسمه.
كل سؤال من هذه الأسئلة يعمل بالطريقة نفسها على عمل حقيقي. والآن لنطرحها على Steve Trucking.
اسأل: «واحد أم كثير؟»
Section titled “اسأل: «واحد أم كثير؟» ”من أول الأشياء التي أريد فهمها عن العلاقة هو التعددية (cardinality). هذا هو المصطلح في عالم قواعد البيانات؛ أما السؤال فأبسط بكثير: كم من هذه يمكن أن يرتبط بكم من تلك؟ على المستوى المفاهيمي هناك ثلاثة أنماط أساسية.
هذه خطوة مهمة في العملية: خذ اسمين مختلفين وافهم العلاقة بينهما. في معظم الحالات تكون واحد-إلى-كثير، أو كثير-إلى-واحد. ولن تصادف علاقة واحد-إلى-واحد إلا في ظروف نادرة.
علاقة واحد-إلى-كثير موجودة في كل مكان. شريك تجزئة واحد لديه مراكز توزيع كثيرة. بيان شحنة واحد يسرد توصيلات كثيرة. مسار واحد فيه نحو عشر محطات. عندما أسمع لغة كهذه، أبدأ في رسم الخط.
والآن يحصل الخط على علاماته. كل طرف يخبرك بعدد ما في المربع الذي يلامسه: الشَّرطة تعني واحدًا، وقدم الغراب تعني كثيرًا. اقرأه من كل مربع: شريك تجزئة واحد لديه مراكز توزيع كثيرة.
علاقات واحد-إلى-واحد موجودة، لكنها نادرة، وعندما أجد واحدة أطرح بعض الأسئلة. هل هذان حقًا اسمان مختلفان، أم الاسم نفسه؟ إذا كانا مختلفين، فما علاقة الواحد-إلى-واحد بينهما؟ وهل ستبقى دائمًا واحد-إلى-واحد، أم هي كذلك الآن فقط؟ هذه أسئلة أساسية في تصميم نموذج البيانات. الطاقم والشاحنة يبدوان واحد-إلى-واحد في أي صباح: شخصان، شاحنة واحدة، مسار واحد. لكن على مدى شهر ليسا كذلك، وهناك تختبئ أكثر العلاقات إثارة للاهتمام في هذا النموذج.
علاقات كثير-إلى-كثير مثيرة للاهتمام بشكل خاص، لأنها كثيرًا ما تخبرنا بوجود مفهوم آخر في العمل. هل يمكن لطاقم أن يقود أكثر من شاحنة عبر الزمن؟ نعم. هل يمكن أن يقود الشاحنةَ أكثرُ من طاقم؟ على مدى عمرها، بالتأكيد. إذن بين الطواقم والشاحنات علاقة كثير-إلى-كثير. لكنني الآن أريد أن أعرف أكثر. هل يهتم العمل متى كانت لدى طاقم شاحنة ما؟ لأي مسار، وفي أي يوم؟ من أجرى التكليف؟ إذا كانت العلاقة نفسها تحمل معلومات تهمنا، فقد اكتشفنا مفهوم عمل آخر: تكليف الطاقم (Crew Assignment).
هذه عادة مهمة في النمذجة. أحيانًا لا يكون الشيء الأكثر إثارة للاهتمام أحد الأسماء التي سمعناها في البداية. بل يختبئ في العلاقة بين اسمين.
العلاقات يمكن أن تصبح أشياء
Section titled “العلاقات يمكن أن تصبح أشياء ”هذا أحد المواضع التي أريد فيها أن يبدأ مسؤولو الأنظمة (admins) في التفكير بشكل مختلف. في Salesforce اعتدنا الحديث عن الكائنات والحقول، فمن السهل أن نعامل المربعات على أنها الجزء المهم، والخطوط على أنها مجرد أنابيب توصيل. لكن العلاقة نفسها يمكن أن يكون لها معنى في العمل.
فكّر في التوصيلة والمنتجات التي عليها. يمكن أن تحمل التوصيلة عدة منتجات، غسالة ومجففًا مثلًا. والمنتج، طراز الثلاجة نفسه، يظهر في آلاف التوصيلات. هذا سهل بما يكفي. لكن ماذا لو احتجت إلى معرفة كم قطعة من ذلك المنتج على هذه التوصيلة، أو هل سيُركَّب، أو هل سيُنقل القديم بعيدًا؟ لم أعد مهتمًا فقط بعلاقة بين التوصيلة والمنتج. بل أنا مهتم بـبند التوصيلة (Delivery Item)، وهذا المفهوم يستحق كيانًا خاصًا به.
إذا كنت قادمًا من عالم Salesforce، فربما تفكر بالفعل: «هذا كائن ربط (junction object).» لست مخطئًا. لكنني لا أريد أن أبدأ من هناك. بند التوصيلة مفهوم عمل قبل أن يكون كائن الربط في Salesforce (Salesforce Junction Object). العمل أولًا، والتنفيذ ثانيًا.
بعض عاداتي مع كيانات العلاقات هذه، أينما انتهى بها الأمر عند البناء.
سمِّه. إذا كان لدى العمل كلمة له بالفعل، فاستخدم كلمتهم. وإن لم تكن، فخذ اسمَي الأبوين واجمعهما. فكّر في طلب ومنتج. الشيء الذي بينهما هو بند الطلب (Order Item): الطلب، والبند الذي في الطلب. إنه ابن لكلا الأبوين، وفي Salesforce قد ينتهي به الأمر كائنَ ربط في Salesforce (Salesforce Junction Object). لكن أي اسم يأتي أولًا: Item Order أم Order Item؟ انظر إلى نوع البيانات في كل أب. المنتج بيانات مرجعية؛ والطلب بيانات معاملات، والطلب هو الذي يقوده. لذلك هو Order Item، أو Order Product، كما أن لدى Salesforce منتج الفرصة (Opportunity Product). في Steve Trucking هو بند التوصيلة (Delivery Item). الاسم القائد يأتي أولًا، فيُرتَّب السجل بجوار مالكه في كل قائمة ستنظر إليها.
امنحه مفتاحه الخاص. من المغري أن تقول إن بند التوصيلة يُعرَّف بالتوصيلة زائد المنتج وتتوقف عند ذلك. هذا مفتاح مركّب، والمفاتيح المركّبة أصعب بكثير في التعامل معها: كل نظام يشير إلى السجل عليه أن يحمل النصفين كليهما. امنح كيان العلاقة معرّفه الخاص، واجعل التوصيلة زائد المنتج قاعدةً عن التفرّد، لا معرّفَ السجل.
لاحظ ما ليس فيه: الرقم التسلسلي. الكمية والرقم التسلسلي لا ينتميان إلى السجل نفسه. الكمية تعدّ عدة قطع من شيء؛ والرقم التسلسلي يحدد شيئًا واحدًا بعينه. إذا احتاج العمل إلى أرقام تسلسلية، تصبح كل وحدة سجلًا قائمًا بذاته، وتصبح خمس ثلاجات خمسة سجلات. لا أرى حالة تستدعي بند توصيلة تحته تفاصيل بند التوصيلة. إما هذا وإما ذاك: مجموع بكمية، أو سجل لكل وحدة. وهنا، هي الكمية.
راقب السمات التي تريد تاريخًا. بعض كيانات العلاقات تستقر بمجرد إنشائها: الغسالة على هذه التوصيلة تبقى الغسالة على هذه التوصيلة. وبعضها يظل يتغيّر. لدى طاقمٍ الشاحنةُ 117 هذا الأسبوع، وفي الأسبوع المقبل تذهب الشاحنة إلى طاقم آخر. عندما تتغيّر العلاقة ويهتم العمل بما كانت عليه، يحتاج كيان العلاقة إلى تواريخ، وتكليف الطاقم هو الذي يجب مراقبته. اسأل مبكرًا هل يهتم العمل بـالآن أم عبر الزمن؛ وسنعود إلى ذلك بعد قليل.
للعلاقات معنى يتجاوز التعددية
Section titled “للعلاقات معنى يتجاوز التعددية ”«واحد-إلى-كثير» لا تكفي لفهم علاقة. أريد أيضًا أن أعرف ماذا تعني العلاقة.
للتوصيلة موقع. أي موقع؟ مركز التوزيع الذي تنطلق منه؟ أم منزل المستلم الذي تذهب إليه؟ هذان ليسا قابلين للتبادل. يمكن أن يكون لنموذجين المربعات نفسها والتعددية نفسها تمامًا، وتعني الخطوط فيهما أشياء مختلفة كليًا. لهذا ليس النموذج الجيد مجرد مربعات تربطها خطوط. الخطوط تحتاج إلى أسماء. إذا سلّمت مخططي إلى معماري آخر، فلا ينبغي أن يضطر إلى تخمين معنى العلاقة، وإذا كنت أعرضه على أهل العمل، فينبغي أن يستخدم لغة يعرفونها.
الاختيارية مهمة أيضًا
Section titled “الاختيارية مهمة أيضًا ”هناك سؤال آخر يختبئ داخل «كم؟»: هل العلاقة إلزامية؟ هل يمكن أن توجد التوصيلة قبل أن توضع على مسار؟ لا بد من ذلك: بيان الشحنة يصل قبل التوصيل بيوم أو يومين، والمسارات تُعتمد في المساء السابق. هل يمكن أن توجد التوصيلة دون شريك تجزئة؟ لا؛ كل توصيلة تأتي من بيان شحنة لشريك. هذه هي الاختيارية (optionality).
مرة أخرى، لا تقفز مباشرة إلى خانة Required (إلزامي) في Salesforce. هناك فرق بين أن تقول «يجب أن يكون لكل توصيلة شريك تجزئة» وأن تقول «ينبغي أن يجعل Salesforce حقل شريك التجزئة إلزاميًا عند إنشاء السجل». قد ينتهيان إلى التنفيذ نفسه، لكنهما ليسا العبارة نفسها. الأولى قاعدة عمل؛ والثانية طريقة واحدة لفرضها. وبوصفنا معماريين، نريد أن نفهم الأولى قبل أن نقرر الثانية.
في المخطط، الاختيارية هي العلامة الثانية على كل طرف. العلامة الأقرب إلى المربع هي الحد الأقصى: الشَّرطة للواحد، وقدم الغراب للكثير. والعلامة التالية بعدها هي الحد الأدنى: شَرطة أخرى تعني واحدًا على الأقل، والدائرة تعني أنه يمكن أن يكون صفرًا. إذن كل توصيلة على بيان شحنة واحد بالضبط، وبيان الشحنة يسرد توصيلة واحدة أو أكثر. والتوصيلة عند صفر أو محطة واحدة، لا شيء حتى تُوضع على مسار، والمحطة تُنزل صفرًا أو توصيلات كثيرة.
الزمن يغيّر العلاقات
Section titled “الزمن يغيّر العلاقات ”هذا سؤال أطرحه كثيرًا: هل تقصد الآن، أم تقصد عبر الزمن؟
الطاقم يُشغّل شاحنة. الآن؟ لمسار اليوم؟ طوال المدة التي يعمل فيها هذان الشخصان معًا؟ هذه تُنتج نماذج مختلفة. إذا كان العمل يهتم فقط بأي شاحنة لدى الطاقم اليوم، يمكن أن يبقى النموذج بسيطًا. وإذا احتاج إلى كل شاحنة قادها الطاقم، ومتى، وعلى أي مسار، فنحن بحاجة إلى التاريخ، ويصبح تكليف الطاقم الذي اكتشفناه مهمًا جدًا فجأة.
هذا مصدر شائع لأخطاء النمذجة. ننمذج الحالة الحالية لأنها ما نراه على الشاشة. ثم، بعد أسابيع، يقدّم شريك تجزئة مطالبة بتعويض عن ضرر، ويسأل أحدهم: «أي طاقم كانت لديه الشاحنة 117 في 17 مارس؟» فنكتشف أننا كنا نكتب فوق الإجابة في كل مرة تغيّر فيها التكليف.
إحدى طرق الاحتفاظ بذلك التاريخ أن نجعل التكليف سجلًا قائمًا بذاته. عندما يُكلَّف طاقم، ننشئ تكليف طاقم بتاريخ بداية. وعندما يتغيّر التكليف، نضع تاريخ نهاية على السجل القديم وننشئ سجلًا جديدًا بتاريخ بدايته الخاص. الآن يصبح سؤال «من كان لديه ذلك التكليف قبل ستة أشهر؟» سؤالًا سهل الإجابة، بدلًا من التنقيب في سجل تاريخ الحقول أو في سجل لتغييرات البيانات. وبمجرد أن يكون للطاقم تكليفات كثيرة، سيسأل أحدهم أيها التكليف الحالي، لذلك سأضيف علامة Active (نشط) أيضًا.
لذلك عندما يخبرني أحدهم عن علاقة، لا أسأل فقط كيف ترتبط الأشياء. بل أسأل: هل تتغيّر تلك العلاقة، وهل يهمنا تاريخها؟
ارسم قبل أن تُعِدّ
Section titled “ارسم قبل أن تُعِدّ ”نموذج Steve Trucking لدينا يصبح مفيدًا. نعرف أي العلاقات واحد-إلى-كثير، وأين تخفي علاقة كثير-إلى-كثير مفهومًا آخر، وأي العلاقات اختيارية، وأيها يتغيّر عبر الزمن. وما زلنا لم ننشئ كائنًا واحدًا في Salesforce. هذا مقصود.
ينبغي أن يكون هذا المخطط شيئًا أستطيع وضعه أمام أهل العمل، ولا ينبغي أن يحتاجوا إلى معرفة Salesforce ليخبروني هل هو صحيح. إذا لم يستطيعوا التحقق منه لأنه مليء بمصطلحات Salesforce، فقد انتقلت إلى التصميم المادي بسرعة زائدة.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”عندما أعمل على العلاقات في نموذج مفاهيمي، فأنا أقرر:
- كيف ترتبط كيانات العمل الرئيسية ببعضها.
- هل كل علاقة واحد-إلى-واحد أم واحد-إلى-كثير أم كثير-إلى-كثير، الآن وعبر الزمن.
- هل كل علاقة إلزامية أم اختيارية.
- هل تخفي علاقة كثير-إلى-كثير مفهوم عمل ذا معنى.
- هل تتغيّر العلاقة عبر الزمن، وهل نحتاج إلى تاريخها.
علاقة البحث أم رئيسي-تفصيلي، وإعداد كائن الربط، وسلوك الحذف المتتالي، والمشاركة: كلها قرارات مادية؛ وسنصل إليها. أما الآن فما زلنا نجيب عن السؤال الأهم: كيف يسير هذا العمل فعلًا؟ وبمجرد أن نفهم الكيانات والعلاقات بينها، يمكننا أن نبدأ في إضافة التفاصيل التي تصفها. عندها يبدأ نموذجنا المفاهيمي في أن يصبح نموذج بيانات منطقيًا.