ضع البيانات حيث تنتمي

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

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

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

الوحدة 4 من 6 في فصل نمذجة البيانات من أجل المعنى، الفصل 2 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: ابنِ النموذج المنطقي · التالي: صمّم حتى الشكل الطبيعي الثالث، ثم تراجع

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

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

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

ما التطبيع؟

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

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

نطبّع على خطوات تسمى الأشكال الطبيعية، وكل واحد منها يطرح سؤالًا واحدًا:

• الشكل الطبيعي الأول (1NF): قيمة واحدة في كل حقل، وشيء يحدد كل صف بشكل فريد.
• الشكل الطبيعي الثاني (2NF): كل حقيقة تصف كامل ما يحدد الصف، لا جزءًا منه فقط.
• الشكل الطبيعي الثالث (3NF): كل حقيقة تصف هذا الشيء، لا شيئًا آخر مرتبطًا به.

هناك أشكال أخرى بعد الثالث. سأقول عنها كلمة لاحقًا، وعن سبب توقفنا عادةً عند الثالث. لكن أولًا، لنشاهد الخطوات الثلاث وهي تحدث.

لماذا نطبّع؟

عندما أعلّم هذا مباشرة، لا أبدأ بالتوصيلات. بل أبدأ بالكلاب. الجميع يفهم الكلاب، فلا ينشغل أحد بتفاصيل العمل، ونستطيع أن نشاهد البيانات وهي تحاول أن تجد مكانها. ثم نأخذ الحركات نفسها إلى Steve Trucking.

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

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

الكلب	الميلاد	المالك	الرمز البريدي	المدينة	السلالة	المربّي	الحيل
Bella	2017	Marcus	80202	Denver	لابرادور	Maple Ridge	اجلس، ابقَ، صافح
Milo	2019	Marcus	80202	Denver	بودل	Golden Meadow	اجلس، تدحرج
Max	2022	Ana	64105	Kansas City	مختلط		اجلس، تظاهر بالموت
Luna	2020	Kenji	98101	Seattle	هاسكي	Cascade	اجلس، ابقَ، استدر
Rocky	2024	Priya	30301	Atlanta	بيغل	Maple Ridge	اجلس
Coco	2014	Ana	64105	Kansas City	شيواوا	Little Paws	صافح، استدر

إنها تعمل. كل جدول بيانات يعمل في يومه الأول. لكن انظر إلى ما هو خاطئ بالفعل. كيف أجد كل كلب يعرف «صافح»؟ الرمز البريدي لـ Ana موجود في صفين، وكذلك رمز Marcus: ماذا يحدث إذا حدّث أحدهم صفًا ونسي الآخر؟ Maple Ridge تظهر مرتين، وكذلك Kansas City. وMax جاء من مأوى الحيوانات، فلا مربّي له على الإطلاق.

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

الكلب (يُحدَّد بمعرّف الكلب)

معرّف الكلب	الاسم	الميلاد	المالك	الرمز البريدي	المدينة	السلالة	المربّي
D-001	Bella	2017	Marcus	80202	Denver	لابرادور	Maple Ridge
D-002	Milo	2019	Marcus	80202	Denver	بودل	Golden Meadow
D-003	Max	2022	Ana	64105	Kansas City	مختلط
D-004	Luna	2020	Kenji	98101	Seattle	هاسكي	Cascade
D-005	Rocky	2024	Priya	30301	Atlanta	بيغل	Maple Ridge
D-006	Coco	2014	Ana	64105	Kansas City	شيواوا	Little Paws

حيلة الكلب (تُحدَّد بمعرّف الكلب + الحيلة)

معرّف الكلب	الحيلة	الصعوبة	مستوى المهارة	تاريخ التعلّم
D-001	اجلس	سهلة	خبير	2017-11
D-001	ابقَ	سهلة	خبير	2018-01
D-001	صافح	متوسطة	جيد	2018-06
D-002	اجلس	سهلة	خبير	2020-02
D-002	تدحرج	صعبة	قيد التعلّم	2023-05
D-003	اجلس	سهلة	جيد	2022-06
D-003	تظاهر بالموت	صعبة	قيد التعلّم	2024-03
D-004	اجلس	سهلة	خبير	2020-11
D-004	ابقَ	سهلة	جيد	2021-01
D-004	استدر	متوسطة	خبير	2021-06
D-005	اجلس	سهلة	قيد التعلّم	2025-02
D-006	صافح	متوسطة	خبير	2015-06
D-006	استدر	متوسطة	قيد التعلّم	2025-04

الآن أصبح «كل كلب يعرف صافح» سؤالًا بسيطًا. لكن لاحظ ما الذي تُحدَّد به حيلة الكلب: ليس شيئًا واحدًا، بل شيئان معًا، الكلب والحيلة. احتفظ بهذه الملاحظة.

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

الحيلة

معرّف الحيلة	الحيلة	الصعوبة
T-01	اجلس	سهلة
T-02	ابقَ	سهلة
T-03	صافح	متوسطة
T-04	تدحرج	صعبة
T-05	تظاهر بالموت	صعبة
T-06	استدر	متوسطة

حيلة الكلب (معرّف الكلب + معرّف الحيلة)

معرّف الكلب	معرّف الحيلة	مستوى المهارة	تاريخ التعلّم
D-001	T-01	خبير	2017-11
D-001	T-02	خبير	2018-01
D-001	T-03	جيد	2018-06
D-002	T-01	خبير	2020-02
D-002	T-04	قيد التعلّم	2023-05
D-003	T-01	جيد	2022-06
D-003	T-05	قيد التعلّم	2024-03
D-004	T-01	خبير	2020-11
D-004	T-02	جيد	2021-01
D-004	T-06	خبير	2021-06
D-005	T-01	قيد التعلّم	2025-02
D-006	T-03	خبير	2015-06
D-006	T-06	قيد التعلّم	2025-04

جدول حيلة الكلب هذا هو الذي وجدناه في الوحدة 2، وله اسم في نمذجة البيانات: جدول ربط (junction)، أو كما أسمّيه، كائن ربط منطقي. الكلب يعرف حيلًا كثيرة؛ والحيلة تعرفها كلاب كثيرة. يقع كائن الربط بينهما، وهو ليس أنابيب فارغة: إنه يحمل الحقائق التي تنتمي إلى العلاقة نفسها، مستوى المهارة والتاريخ. سنلتقي به مجددًا في الوحدة 6، وفي الفصل 3 سنرى أن Salesforce يستخدم «junction object» بمعنى أضيق: كائن الربط في Salesforce (Salesforce Junction Object) هو كائن مخصص له علاقتا رئيسي-تفصيلي (الفصل 3، الوحدة 7).

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

• الكلب: معرّف الكلب، الاسم، الميلاد، معرّف المالك، معرّف السلالة، معرّف المربّي
• المالك: معرّف المالك، الاسم، الرمز البريدي، المدينة
• السلالة: معرّف السلالة، السلالة، الحجم
• المربّي: معرّف المربّي، الاسم، المدينة
• الحيلة وحيلة الكلب، من الخطوة 2

أصبحت Ana مخزّنة مرة واحدة الآن، وكلبا Ana يشيران إليها. وMaple Ridge مخزّنة مرة واحدة، وجدول السلالة يمنحنا مكانًا للحقائق عن كل سلالة، مثل حجمها، لم يكن لجدول البيانات مكان يضعها فيه. يمكن أن يكون المفتاح الخارجي فارغًا: ليس لـ Max معرّف مربٍّ، وهذه إجابة صادقة، لا ثغرة. ثم أرمي على الحاضرين سؤالًا مخادعًا: متى حصل المالك على الكلب، أين يذهب ذلك التاريخ؟ على الكلب. للكلب مالك واحد في كل مرة في هذا النموذج، لذلك يصف ذلك التاريخ علاقة الكلب بمالكه.

يمكنك أن تذهب خطوة أبعد وتفصل المدينة عن الرمز البريدي؛ والكتب الدراسية تفعل ذلك. لكن في الواقع يبقى العنوان معًا، وKansas City تقع في ولايتين على أي حال، وهذا تذكير لطيف بأن العالم الحقيقي لا يقرأ كتبنا الدراسية.

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

Click to enlarge

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

والآن لنطبّقه على Steve Trucking

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

التوصيلة	شريك التجزئة	مركز التوزيع	مدينة المركز	الطاقم	الشاحنة
1001	Keystone	Keystone Phoenix DC	Phoenix	Crew 12	117
1002	Keystone	Keystone Phoenix DC	Phoenix	Crew 8	122
1003	Keystone	Keystone Phoenix DC	Phoenix	Crew 12	117

للوهلة الأولى لا شيء معقّد هنا. لكن انظر إلى مركز التوزيع. نكرر «Keystone Phoenix DC، Phoenix» على كل توصيلة تنطلق منه: تُجري Steve Trucking نحو 3,300 توصيلة يوميًا عبر تسعة مراكز توزيع، أي بضع مئات يوميًا من كل مركز. ماذا يحدث إذا انتقل ذلك المركز؟ كم سجلًا نغيّر، وماذا يحدث إذا فاتنا واحد؟ عندها تقول البيانات إن المركز في مدينتين في آن واحد. هذا شذوذ تحديث. ماذا لو أردنا إعداد مركز توزيع جديد قبل أول توصيلة منه؟ ماذا لو حذفنا آخر توصيلة من مركز: هل حذفنا للتو المكان الوحيد الذي خزّنا فيه أي شيء عنه؟

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

الشكل الطبيعي الأول: لا تُخفِ البنية المتكررة

لنبدأ بـالشكل الطبيعي الأول، أو 1NF، حيث يجعل الناس التطبيع أحيانًا أصعب مما ينبغي.

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

Click to enlarge

الدرس العملي من 1NF: لا تُخفِ البنية المتكررة داخل الحقول. إذا أخبرك العمل أن شيئًا ما يمكن أن يحدث مرات كثيرة، فأنصت. ربما يكون هناك كيان آخر يحاول الخروج.

سترى هذا في الـ orgs الحقيقية طوال الوقت. يحتاج أحدهم إلى وصف بعدة لغات، فينشئ حقلًا اسمه Description_English، ثم Description_French، ثم Description_German. أو تحتاج موافقة إلى عدة أشخاص، فنحصل على Approver 1 وApprover 2 وApprover 3. عندما أجد ذلك في مراجعة، فهي ضربة خفيفة على اليد: أصلح نموذج بياناتك. واحد أو اثنان، ربما، إذا كان العمل فعلًا لا يملك إلا واحدًا أو اثنين. وكل ما يزيد على ذلك ينبغي أن يكون كائنًا ابنًا: ترجمة (Translation) بلغة، وخطوة موافقة (Approval Step) بموافِق. اللغة التالية، أو الموافِق الرابع، يصبح سجلًا جديدًا، لا حقلًا جديدًا ونشرًا جديدًا.

الشكل الطبيعي الثاني: صِف الشيء كله

الشكل الطبيعي الثاني، أو 2NF، يهم عندما يُحدَّد السجل بتركيبة من الأشياء. خذ بند التوصيلة. له معرّف سجل خاص به، لكن كل بند فريد بـالتوصيلة + المنتج. لنفترض أننا نخزّن التوصيلة، والمنتج، والكمية، ووصف المنتج.

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

إذن سؤال 2NF هو: هل تصف هذه السمة الشيء كله الذي أحدده، أم جزءًا منه فقط؟ إذا كانت تصف المنتج وحده، فمكانها مع المنتج. وإذا كانت تصف موقع المنتج على هذه التوصيلة بعينها (الكمية، وهل سيُركَّب)، فهي تنتمي إلى بند التوصيلة. كثير من مسؤولي الأنظمة لن يقولوا عن وعي أبدًا: «أنا أطبّق الشكل الطبيعي الثاني الآن.» لا بأس. يهمني أكثر بكثير أن تتعلم أن تسأل: ما الذي تصفه هذه الحقيقة فعلًا؟

الشكل الطبيعي الثالث: لا تخزّن حقائق عن حقائق أخرى

والآن الشكل الذي يهمني أكثر من غيره في النمذجة اليومية: الشكل الطبيعي الثالث، أو 3NF.

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

النسخة الكلاسيكية في الكتب الدراسية هي العنوان: الرمز البريدي والمدينة والولاية مخزّنة معًا على كل سجل، مع أن المدينة والولاية تُستنتجان عادةً من الرمز البريدي. الشكل نفسه، والسؤال نفسه.

Click to enlarge

سؤال 3NF العملي هو: هل تصف هذه الحقيقة هذا الشيء، أم شيئًا آخر يرتبط به هذا الشيء؟ أريدك أن تطرحه باستمرار.

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

Click to enlarge

الأسئلة الثلاثة نفسها، والنتيجة نفسها: كل حقيقة في مكان واحد.

طريقة بسيطة للتفكير في 1NF و2NF و3NF

يمكنك أن تقضي دورة كاملة في قواعد البيانات عن التطبيع. لن نفعل ذلك. في هذه الدورة، أريد أن يكون لديك فهم المعماري العملي:

• 1NF: هل أُخفي قيمًا متعددة أو بنى متكررة داخل حقل أو سجل؟
• 2NF: هل تصف هذه الحقيقة الشيء كله الذي أحدده؟
• 3NF: هل تصف هذه الحقيقة هذا الكيان فعلًا، أم شيئًا مرتبطًا به؟

هذه ليست تعريفات لكتاب دراسي في قواعد البيانات. إنها أسئلة أستطيع استخدامها فعلًا وأنا أصمّم.

نعم، يذهب التطبيع أبعد من ذلك: شكل Boyce-Codd الطبيعي (BCNF) يشدّد القواعد حول 3NF للنماذج ذات المفاتيح الأكثر تعقيدًا، وهناك الأشكال الطبيعية الرابع والخامس بل والسادس. إنها تتعامل مع أنواع أندر من التكرار، النوع الذي يأتي من بنى مفاتيح غير مألوفة أكثر مما يأتي من سجلات العمل اليومية. نظرية كثيرة، ولا تستحق في تجربتي الصداع لنوع الأنظمة التي نبنيها على Salesforce. في أنظمة العمل، يسير الضغط عادةً في الاتجاه المعاكس: من المرجح أكثر بكثير أن نتراجع عن الشكل الطبيعي الثالث، من أجل المستخدمين والتقارير والأداء، من أن نتجاوزه. وهذا موضوع الوحدة التالية. اعرف أن الأشكال الأبعد موجودة، لكن لمعظم ما نفعله، تمنحنا الأشكال من 1NF إلى 3NF أدوات التفكير التي نحتاج إليها.

صمّم وفق الشكل الطبيعي الثالث

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

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

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

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

عندما أطبّع نموذجًا منطقيًا، أبحث عن:

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

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