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

المنطق سيوصلك من A إلى B. أما الخيال فسيأخذك إلى كل مكان. —ألبرت أينشتاين

في هذا الفصل، نقدّم مفهوم "نموذج قاعدة البيانات" مقدمةً لبناء نموذج البيانات المنطقي. ثم نستطيع إجراء التحويل من النموذج المفاهيمي إلى النموذج المنطقي. وسننظر في ما يلي:

• ما هو نموذج قاعدة البيانات؟
• ما دور نموذج قاعدة البيانات؟
• ما هو نموذج قاعدة البيانات العلائقية؟
• كيف نحوّل نموذج بيانات مفاهيميًا إلى نموذج بيانات منطقي وفق نموذج قاعدة البيانات العلائقية؟

ينبغي أن تكون قادرًا على تعريف المصطلحات التالية، وكيفية تصوّر ذلك (حيثما كان ذا صلة)، وشرحه بمثال:

• نموذج البيانات المنطقي؛
• نموذج قاعدة البيانات؛
• نموذج قاعدة البيانات العلائقية؛
• الجدول؛
• المفتاح (بما في ذلك المفتاح المرشّح، والمفتاح الأساسي، والمفتاح الأجنبي، والمفتاح المركّب، والمفتاح الطبيعي، والمفتاح التقني أو البديل)
• التطبيع.

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

وينبغي أيضًا أن تكون قادرًا على تحويل نموذج بيانات مفاهيمي إلى نموذج بيانات منطقي (لنموذج قاعدة بيانات علائقية).

مقدمة

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

وفي الخطوة التالية، سننظر في بنية هذه المجموعة من البيانات. فكيف ننظّم البيانات؟ ففي نهاية المطاف، هناك عدة طرق لفعل ذلك.

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

وبالنسبة للبيانات، يمنح ذلك فائدة إضافية هي أن البنية نفسها تحتوي على معلومات إضافية (نسميها بيانات وصفية - بيانات عن البيانات) يمكن استخدامها بعد ذلك لتحديد الإجراءات. وهكذا يمكننا إدارة الوصول إلى البيانات وتحسين التخزين وتطوير إجراءات قياسية...

ويمكنك هيكلة المفهوم نفسه بطرق كثيرة مختلفة، فكّر فقط في مكتبة. يمكنك ترتيب جميع الكتب حسب الموضوع أو المؤلف أو العنوان... وهذا لا يختلف بالنسبة للبيانات. ثم تطرح الأسئلة التالية:

• ما نوع البيانات التي نتحدث عنها؟
• ماذا تريد أن تفعل بهذه البيانات؟

ولأن أهل تكنولوجيا المعلومات مغرمون إلى حد بعيد بـالمعايير (وأنتم يا من ستشتغلون بتكنولوجيا المعلومات ينبغي أن تتحمسوا الآن لأن معيارًا آتيًا بوضوح)، فلا عجب أن يكون الأمر كذلك أيضًا بالنسبة للبيانات. وقد وُضعت على مر الزمن معايير كثيرة لنماذج البيانات ولهيكلة البيانات. ونسمي هذه المعايير نماذج قواعد البيانات (database models).

نماذج قواعد البيانات

يحدد نموذج قاعدة البيانات بنية قاعدة البيانات وكيفية تنظيم البيانات داخل قاعدة البيانات ومعالجتها. ولننظر في ذلك بمزيد من التفصيل.

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

وتوفّر المعايير المحيطة بنماذج قواعد البيانات (وغيرها من المجالات) بعض المزايا المهمة التي ينبغي ألا نغفل عنها:

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

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

ومن بين كل نماذج قواعد البيانات هذه، صمد نموذج واحد بعينه مدة طويلة. فـنموذج قاعدة البيانات العلائقية (relational database model)، الذي طوّره Codd في سبعينيات القرن العشرين، لا يزال يُعتبر معيارًا داخل صناعة تكنولوجيا المعلومات. ولهذا سيكون هذا النموذج هو محور تركيزنا في هذه الدورة. وتُغطّى نماذج أخرى في دورات أخرى.

نموذج قاعدة البيانات العلائقية

الجدول

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

ويمثل الصف سجلًا (أو كيانًا) من الجدول. ويمكن أن يحتوي الجدول نظريًا على عدد لا نهائي من الصفوف. وعندما ننشئ جدولًا بسجلات الطلاب، فقد يمثل كل صف طالبًا.

ويمثل العمود خاصية (أو حقلًا) من الجدول، وستصف كل منها جزءًا من الصف (أو الكيان). ويحتوي الجدول على عدد ثابت من الأعمدة. وإذا أردنا إضافة عمود، وهو أمر ممكن، فعلينا أن نفكر في ما يعنيه ذلك للصفوف الموجودة في الجدول. فمثلًا، من الممكن أن نحتاج إلى إدخال قيمة لهذا العمود لكل صف من الصفوف المدرجة بالفعل في الجدول.

وفي مثالنا لجدول بيانات الطلاب، سيحتوي كل عمود على خاصية معينة للطالب، مثل الاسم وتاريخ الميلاد...

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

المفاتيح

يتكوّن المفتاح من عمود واحد أو أكثر (خواص) في جدول يحقق الشروط الثلاثة التالية:

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

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

ويُختار المفتاح الأساسي من عدد من المفاتيح المرشّحة. والمفتاح المرشّح (candidate key) مفتاح محتمل لجدول، وهو يحقق بالتالي الشروط الثلاثة للمفتاح.

ويوضح الشكل أدناه مثالًا لجدول "Lecturers". لدينا أربعة أعمدة قد تكون مفتاحًا. وبعد التفكير لا يبقى لدينا سوى "Lecturer ID" مفتاحًا مرشّحًا. * وبما أن هناك مفتاحًا مرشّحًا واحدًا فقط، فمن المنطقي اختياره مفتاحًا أساسيًا. *

إذن يمكن أن يكون للجدول عدة مفاتيح. ومن قائمة المفاتيح المرشّحة نختار مفتاحًا أساسيًا واحدًا. ولاختيار مفتاح جيد من قائمة المفاتيح الممكنة يمكنك النظر في المعايير التالية:

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

وإذا لم يكن لدينا أي مفاتيح مرشّحة، أو لم تكن المفاتيح المرشّحة المتاحة خيارًا مناسبًا، فلدينا دائمًا خيار تعريف مفتاح بأنفسنا. ونسمي هذه المفاتيح تقنية أو بديلة (surrogate keys). والمفتاح التقني يُستخدم داخل قاعدة البيانات فقط، وليس له قيمة خارجها. ويترتب عليه إضافة عمود إضافي يحتوي المفتاح. وفي النهاية، يجب أن يكون لكل جدول مفتاح أساسي.

كنا قد أشرنا بالفعل إلى أن المفاتيح الأساسية تتيح إنشاء روابط بين الجداول. ويتم ذلك بتبادل المفاتيح الأساسية. وتُشرح آلية التبادل في قسم "من النموذج المفاهيمي إلى النموذج المنطقي". وفي جوهره، يُضاف المفتاح الأساسي لجدول إلى جدول آخر. وبمجرد أن نضيف مفتاحًا أساسيًا إلى جدول آخر، وبالتالي نضيف عمودًا إلى ذلك الجدول، نسمي هذا المفتاح مفتاحًا أجنبيًا (foreign key).

• يُعدّ استخدام المفاتيح الأساسية والمفاتيح الأجنبية محوريًا في النموذج العلائقي. فهو الأساس لتعريف العلاقات. *

نماذج قواعد البيانات الأخرى

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

• نموذج قاعدة البيانات الهرمي (Hierarchical): يستخدم هيكلة شجرية لتمثيل البيانات
• نموذج قاعدة البيانات الشبكي (Network): يستخدم هيكلة شبكية لتمثيل البيانات
• نموذج قاعدة البيانات الأبعادي (Dimensional): يُستخدم في سياق مخازن البيانات
• نموذج قاعدة البيانات الكائني التوجه (Object-oriented): يجمع قدرات قاعدة بيانات علائقية مع البرمجة كائنية التوجه
• نموذج قاعدة البيانات الرسم البياني (Graph): يستخدم هيكلة رسوم بيانية لتمثيل البيانات

من النموذج المفاهيمي إلى النموذج المنطقي

يمكن العثور على كيفية رسم نموذج بيانات منطقي في draw.io في فصل منفصل عبر فيديوين:

1. رسم نموذج بيانات منطقي باستخدام draw.io
2. من المفاهيمي إلى المنطقي

ويجيب نموذج البيانات المنطقي عن السؤال: "كيف ينبغي أن نهيكل البيانات وفق نموذج قاعدة البيانات الذي اخترناه؟" فقد طوّرنا نموذج بيانات مفاهيميًا، واتخذنا قرار اختيار نموذج قاعدة بيانات علائقية. ويجري تحويل هذا النموذج المفاهيمي بعد ذلك على عدد من الخطوات.

الخطوة 1: أنواع الكيانات تصبح جداول

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

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

الخطوة 2: يُسنَد مفتاح أساسي لكل جدول

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

ونمثل المفتاح الأساسي بصريًا بوضع أعمدة المفتاح في أعلى القائمة مع خط أسفلها للتمييز بوضوح بين المفتاح الأساسي والأعمدة المتبقية. وعند فعل ذلك نضع أيضًا لأعمدة المفتاح الأساسي المختلفة الرمز "PK" (من primary key)، ولكي نكون متأكدين تمامًا من أن لا أحد يمكنه ارتكاب خطأ، نضع خطًّا تحت أسماء الأعمدة أيضًا.

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

الخطوة 3: لكل علاقات 1-1 و1-N، ننقل المفتاح الأساسي مفتاحًا أجنبيًا

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

ولكل علاقة 1-N، سننقل المفتاح الأساسي من جهة 1 إلى جهة N. وعلى جهة N يصبح هذا المفتاح الأساسي مفتاحًا أجنبيًا. وهكذا سيحصل كل صف من الجدول على جهة N على عمود إضافي يحتوي إشارة (بواسطة المفتاح الأجنبي) إلى صف في جدول جهة 1.

فمثلًا، لدينا نوعا كيان: "Team" و"Staff Member". وكل موظف في فريق واحد بالضبط. ويمكن أن يضم كل فريق عدة موظفين. ننشئ جدولين: جدول "Team" وجدول "Staff member". ويُمنح جدول "Team" المفتاح الأساسي "Team Code"، الذي يحصل به كل فريق في الجدول على رمز فريق فريد. ويُمنح جدول "Staff member" المفتاح الأساسي "Member number"، الذي يُسنَد به لكل موظف في الجدول رقم عضوية فريد. ولنمذجة العلاقة بين نوعي الكيان في نموذج البيانات المنطقي، نضيف رمز الفريق من جدول "Team" (جهة 1) إلى كل موظف في جدول "Staff Member" (جهة N).

والعكس (أي إضافة المفتاح الأساسي من "Staff Member" إلى "Team") ليس خيارًا. فلا يمكننا إضافة سوى قيمة واحدة إلى فريق. ومن ثم، لو أنشأنا إشارة من الفريق إلى موظف واحد، لفقدنا الارتباط ببقية أعضاء الفريق.

وفي نموذج البيانات نضيف المفتاح الأجنبي إلى قائمة الأعمدة. ونرمز إلى المفتاح الأجنبي بالاختصار "FK" (من foreign key) متبوعًا برقم تسلسلي، مثل FK1 وFK2... وينبغي أن يتيح الرقم التسلسلي التمييز بين المفاتيح الأجنبية المختلفة. وإذا كان لدينا مفتاح أجنبي يتكوّن من عدة أعمدة، ننقل كل عمود منها. ثم نمنحها جميعًا الرقم التسلسلي نفسه للإشارة إلى أنها تنتمي معًا.

ولا نزال نرمز إلى العلاقة بخط نستخدم فيه تدوين قدم الغراب (crow's foot notation). ويختلف تدوين قدم الغراب عن تدوين (min,max) الذي استخدمته حتى الآن.

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

والإرشاد في علاقة 1-1 هو النظر إلى التعددية الدنيا. فإذا تعذّر وجود نوع كيان معين دون العلاقة (أي أن التعددية الدنيا "1")، فمن الأفضل أن يأخذ هذا الجدول المفتاح الأساسي للجدول الآخر مفتاحًا أجنبيًا. وبما أن الكيان لا يوجد إلا إذا كانت له علاقة، فيجب أن يكون هذا العمود ممتلئًا دائمًا في الصف الذي يصف الكيان. لأنه بدون هذه القيمة لا توجد العلاقة.

وإذا تعذّر وجود نوعي الكيان دون بعضهما (أي أن التعددية الدنيا "1" في كليهما)، أو أمكن وجودهما معًا دون بعضهما (أي أن التعددية الدنيا "0" في كليهما)، فلك أن تختار. وعادةً تختار الجدول ذا العدد الأصغر من الصفوف ليضم المفتاح الأساسي للجدول الآخر مفتاحًا أجنبيًا.

الخواص متعددة القيم

الخواص متعددة القيم نوع من علاقات 1-N حيث يرتبط كيان بعدة قيم خاصية. ومن ثم، تحتاج إلى اتباع نهج مشابه لهذه كما في تحويل علاقات 1-N. ولكل خاصية متعددة القيم، أنشئ جدولًا جديدًا باسم الخاصية متعددة القيم. وإلى هذا الجدول تضيف قيمة الخاصية ثم المفتاح الأساسي لجدول نوع الكيان مفتاحًا أجنبيًا. ولا تنسَ الإشارة إلى المفتاح الأساسي وإضافة خط بتدوين قدم الغراب.

فمثلًا، ينتج عن الخاصية متعددة القيم "Email" لنوع الكيان "Employee" جدول "Email" يحتوي عمود "Email". ولربط كل عنوان بريد إلكتروني بموظف، نضيف المفتاح الأساسي لجدول "Staff member" مفتاحًا أجنبيًا إلى جدول "Email". ولاحظ في هذا المثال أن المفتاح الأساسي لجدول "Email" مفتاح مركّب: فـتركيب العمودين "Staff Member" و"Email" وحده هو الفريد.

الخطوة 4: لكل علاقة N-M، ننشئ جدولًا وسيطًا

الآن تصبح الأمور أكثر تعقيدًا قليلًا.

في الفقرات أعلاه، قدّمنا بالفعل إجراءً لأنواع الكيانات المختلفة وخواصها ولعلاقات 1-1 و1-N. وفي هذه الخطوة نركّز على علاقات N-M. ولتمكين علاقات N-M، نحتاج إلى تجاوز التبادل البسيط للمفاتيح الأساسية لأن ذلك لا يوفر حلًا جيدًا لعلاقات N-M.

لنبدأ من مثال. لدينا نوع الكيان "Student" ونوع الكيان "Course". وبين نوعي الكيان علاقة تعبّر عن أن طالبًا يمكن أن يسجّل في عدة مقررات، وبالعكس أن عدة طلاب يمكن أن يسجّلوا في مقرر واحد. فهذه علاقة متعدد إلى متعدد.

وفي البداية، ننشئ جدولين من نوعي الكيان: جدول "Student" وجدول "Course". ويُمنح الجدول الأول المفتاح الأساسي "Student Number"، ويُمنح الجدول الثاني المفتاح الأساسي "Course Code". ولو أضفنا عمود "Course Code" إلى جدول "Student"، لأمكن للطالب الإشارة إلى مقرر واحد فقط، وبالتالي دراسة مقرر واحد فقط، وهذا غير صحيح. وبالعكس، لو أضفنا "Student Number" إلى جدول "Course"، لما أمكن دراسة المقرر إلا من طالب واحد، وهذا غير صحيح أيضًا.

ونحل ذلك بإنشاء جدول وسيط نضيف إليه صفًا لكل تركيبة من كيان "Student" يدرس كيان "Course". ويحتوي كل صف حينئذ على المفتاح الأساسي لجدول "Student" والمفتاح الأساسي لجدول "Course". وبذلك سيحتوي الجدول على مفتاحين أجنبيين. ثم يصبح تركيب المفتاحين الأجنبيين هو المفتاح الأساسي الجديد للجدول الوسيط الجديد.

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

وبعبارة أخرى، ينتج عن المثال أعلاه جدول (وسيط) "StudentFollowsCourse" (أو "Student_Course"، وكن متسقًا في تسميتك) نجد فيه عمود "Student Number" وعمود "Course Code". وكلاهما مفتاح أجنبي، لذا نرمز إليهما بالاختصار "FK" (Foreign Key) متبوعًا برقم تسلسلي. وتركيب المفتاحين هو أيضًا المفتاح الأساسي للجدول الجديد، لذا نرمز إلى كل عمود أيضًا بالاختصار "PK" (Primary key). وادرس الشكل أدناه بتمعّن!

وعلاقة N-M هي النوع الوحيد من العلاقات الذي يمكن أن تكون له خواص. وفي نموذج البيانات المنطقي، سننشئ أعمدة إضافية لهذه الخواص في الجدول الوسيط.

فمثلًا، في المثال أعلاه، إذا أردنا الاحتفاظ بعلامة لكل تركيبة بين طالب ومقرر، فإننا ننشئ عمودًا إضافيًا "Score" في جدول "StudentFollowsCourse" (انظر الشكل أدناه).

الخطوة 5: الحالات الخاصة

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

علاقات من الدرجة 1

علاقة من الدرجة 1 في نموذج بيانات مفاهيمي، وتُسمّى أيضًا علاقة أحادية، هي حالة يكون فيها لنوع كيان علاقة بنفسه.

فمثلًا، تخيّل حالة يدرّب فيها موظف موظفًا آخر. نريد تضمين هذه المعلومة في قاعدة بياناتنا (وبالتالي في نموذج بياناتنا). لدينا نوع الكيان "Employee" الذي يشير إلى نفسه عبر علاقة "Coaches". وتحدد العلاقة أن كل موظف يدرّب ربما عدة موظفين آخرين أو لا يدرّب أحدًا. وإضافة إلى ذلك، لكل موظف مدرب واحد على الأكثر، لكن ذلك ليس إلزاميًا أيضًا.

ولتحويل ذلك بعد ذلك إلى نموذج بيانات منطقي، نعامل هذه العلاقة الأحادية كما لو كانت علاقة ثنائية تقابل علاقة 1-N.

فكيف نقارب ذلك عمليًا؟ أولًا، ننشئ جدول "Employee" ونحدد مفتاحًا أساسيًا، وهو في هذه الحالة "Staff Number". وفي حالة علاقة 1-N، ننقل المفتاح الأساسي من جهة 1 (الموظف المدرِّب) مفتاحًا أجنبيًا إلى جهة N (الموظف المتدرِّب). ونضيف المفتاح الأساسي "Staff Number" عمودًا إضافيًا إلى جدول "Employee" حيث نعيد تسميته "CoachedByStaffNumber" للوضوح، ونحدده مفتاحًا أجنبيًا بالاختصار "FK"، اختياريًا متبوعًا برقم تسلسلي. ويتيح لنا ذلك، لكل موظف، الارتباط بمدربه لأن كل صف من الموظف سيحتوي إشارة.

وبالنسبة إلى الأنواع الأخرى من العلاقات، يجري الاستدلال بالمثل. فإذا كانت العلاقة الأحادية علاقة N-M، نستخدم جدولًا وسيطًا كما وُصف سابقًا.

علاقات من الدرجة 3 أو أعلى

علاقة من الدرجة 3 أو أعلى في نموذج بيانات مفاهيمي هي حالة تربط فيها علاقة ثلاثة أنواع كيانات أو أكثر.

فمثلًا، تخيّل حالة يصف فيها طبيب دواءً لمريض. وإذا نمذجنا ذلك في نموذج بيانات مفاهيمي، سيكون لدينا ثلاثة أنواع كيانات "Doctor" و"Patient" و"Medication" تربطها علاقة "Prescribes". وقد استخدمنا هذا المثال سابقًا في فصل نموذج البيانات المفاهيمي، لذا نعرف أنه لا يمكن اختزاله إلى علاقات ثنائية.

ولتحويل ذلك بعد ذلك إلى نموذج بيانات منطقي، ننشئ جدولًا لكل من أنواع الكيانات الثلاثة: "Doctor" و"Patient" و"Medication". ولكل من هذه الجداول الثلاثة مفتاح أساسي هو على التوالي "Doctor Number" و"Patient Number" و"Medication Code". ونستبدل العلاقة بـجدول وسيط "Prescription" نضيف إليه الأعمدة الثلاثة التي يشير كل منها إلى المفاتيح الأساسية لجداول "Doctor" و"Patient" و"Medication". وكل مفتاح مفتاح أجنبي في جدول "Prescription"، لذا نرمز إليه بالاختصار "FK" متبوعًا برقم تسلسلي. وتشكّل الأعمدة الثلاثة معًا المفتاح الأساسي لجدول "Prescription"، ولذلك نرمز إليها أيضًا بالاختصار "PK". ولكل علاقة توجد بين الكيانات المختلفة من أنواع الكيانات "Doctor" و"Patient" و"Medication"، سيُضاف صف إلى جدول "Prescription".

وكل خاصية للعلاقة، مثل الخاصية "Date" للإشارة إلى وقت وصف الدواء، تُضاف إلى الجدول الوسيط "Prescription" كعمود إضافي.

ويمكننا توسيع المبدأ نفسه لعلاقات من الدرجة 4 و5... وفي كل حالة، ننشئ جدولًا وسيطًا يحتوي المفاتيح الأساسية لجميع الجداول المشاركة.

تمرين تأجير السيارات

أنشئ التمرين 1: تأجير السيارات.

تمرين جمعية الشباب

أنشئ التمرين 2: جمعية الشباب.

تمرين جمعية ألعاب الطاولة

أنشئ التمرين 3: جمعية ألعاب الطاولة.

تمرين الصيانة والإصلاح التقنيان

أنشئ التمرين 4: الصيانة والإصلاح التقنيان.

الأنواع الفرعية والأنواع الفائقة

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

والمثال الذي استخدمناه سابقًا نوع فائق "Employee" ونوعان فرعيان "Temporary employee" و"Permanent employee". ومن نوع الكيان "Employee" نحتفظ بالخصائص النموذجية: الاسم والاسم الأول وتاريخ الميلاد ورقم الموظف... وإضافة إلى ذلك، لدينا نوع الكيان "Temporary employee" الذي يرث جميع الخواص والعلاقات من نوع الكيان "Employee"، لكنه يوسّعه بالخاصيتين "Contract start date" و"Contract end date". ويوسّع نوع الكيان "Permanent employee" نوعَ الكيان "Employee" بالخاصيتين "Employee start date" و"Number of years of service".

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

وسنستعرض الاستراتيجيتين:

1. الاستراتيجية الأولى هي إنشاء جدول واحد "Employee"، نضيف فيه عمودًا لكل خاصية من خواص نوع الكيان "Employee"، باستثناء الخواص متعددة القيم والخواص المشتقة. ونمنح هذا الجدول مفتاحًا أساسيًا، مثل "Staff Number". ثم نضيف أيضًا أعمدة لكل من خواص الأنواع الفرعية لنوع الكيان "Employee" (وبعبارة أخرى نوعي الكيان "Temporary Employee" و"Permanent Employee"). وينتج عن ذلك جدول كبير واحد يضم جميع خواص الأنواع الفائقة والأنواع الفرعية معًا. وإذا كانت للأنواع الفرعية علاقات أيضًا، فيجب بالطبع إضافة كل من هذه العلاقات إلى الجدول بشكل صحيح كما وصفنا سابقًا. ويحتوي الجدول الناتج على صف واحد لكل موظف، وتُملأ الأعمدة المختلفة وفقًا لما إذا كان الموظف مؤقتًا أم دائمًا. تعمل هذه الاستراتيجية بشكل جيد جدًا إذا كان النوع الفائق يحتوي على النسبة الأكبر من الخواص والعلاقات، وكان لكل نوع فرعي عدد قليل فقط من الخواص أو العلاقات الإضافية. وهكذا نختار عن قصد عدم إضافة تعقيد بإضافة جداول إضافية. وإضافة إلى ذلك تعمل هذه الاستراتيجية بشكل جيد مع الوراثة المتداخلة و/أو الكلية. فمع الوراثة المتداخلة و/أو الكلية، سيكون لدينا عدد أكبر من الأعمدة الممتلئة لكيان معين، أو بعبارة أخرى، عند ترجمتها إلى النموذج المنطقي، سيكون عدد أقل من الأعمدة فارغًا لصف معين.
2. أما الاستراتيجية الثانية فهي إنشاء جدول واحد "Employee" نضيف فيه عمودًا لكل خاصية من خواص نوع الكيان "Employee"، باستثناء الخواص متعددة القيم والخواص المشتقة. ونمنح هذا الجدول مفتاحًا أساسيًا، مثل "Staff Number". ثم ننشئ جداول إضافية لكل من الأنواع الفرعية، مما ينتج في مثالنا الجدولين "Temporary Employee" و"Permanent Employee". وإلى هذين الجدولين نضيف عمودًا لكل خاصية من خواص الأنواع الفرعية، باستثناء الخواص متعددة القيم والخواص المشتقة مرة أخرى. وإلى كل من جدولي النوعين الفرعيين نضيف المفتاح الأساسي لجدول النوع الفائق. وفي مثالنا، نضيف العمود "Employee Number" إلى جدولي "Temporary Employee" و"Permanent Employee". وبما أن هذا مفتاح أساسي لجدول آخر، نرمز إليه مفتاحًا أجنبيًا بالاختصار "FK" متبوعًا برقم تسلسلي. وفي الوقت نفسه، يتولى هذا المفتاح أيضًا دور المفتاح الأساسي لجدولي النوعين الفرعيين، لذا نرمز إليه أيضًا بالاختصار "PK". وينتج عن ذلك عدة جداول، جدول للنوع الفائق وجدول لكل من الأنواع الفرعية. وبالطبع يجب هنا أيضًا معالجة العلاقات المختلفة بشكل صحيح كما وصفنا سابقًا. ويحتوي جدول النوع الفائق الناتج على صف واحد لكل موظف. وإضافة إلى ذلك، سيُضاف صف لكل موظف مؤقت إلى جدول "Temporary Employee"، وسيُضاف صف لكل موظف دائم إلى جدول "Permanent Employee" مع ملء كل عمود وفقًا لذلك. تعمل هذه الاستراتيجية بشكل جيد جدًا إذا كان النوع الفائق يضم عددًا صغيرًا من الخواص والعلاقات، وكان للأنواع الفرعية نفسها كثير من الخواص أو العلاقات. ولتجنّب تعقيد كل تلك الأعمدة الإضافية التي ستكون عادةً فارغة في جدول واحد، نقسّم الأمر كله. وإضافة إلى ذلك، تعمل هذه الاستراتيجية بشكل جيد إذا كان الأمر يتعلق بوراثة منفصلة و/أو اختيارية. فمع الوراثة المنفصلة و/أو الاختيارية، يكون لدينا خطر كبير من كثرة الأعمدة الفارغة لصف معين، وهو ما يستهلك بدوره مساحة غير ضرورية.

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

تمرين المكتبة

أنشئ التمرين 5: المكتبة.

التكرار في نموذج قاعدة البيانات العلائقية

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

وفي سياق نموذج قاعدة البيانات العلائقية، يعني التكرار أننا نعرّف جداول وأعمدة لا نحتاجها فعليًا. ولكن كيف يبدو ذلك؟

لنبدأ من المثال الذي استخدمناه سابقًا. يشتري عميل سيارة من إحدى الكراجات. ونحن نعرف أي عميل يشتري أي سيارة. ونعرف أيضًا في أي كراج تُباع السيارة. وإذا أردنا معرفة في أي كراج يشتري العميل سيارة، يمكننا إنشاء العلاقة "Buys car in" بين نوعي الكيان "Customer" و"Garage". وقد ذكرنا سابقًا أن هذه العلاقة زائدة، لأن المعلومة التي يمكننا اشتقاقها من هذه العلاقة موجودة بالفعل في العلاقة "Buys" بين نوعي الكيان "Customer" و"Car" والعلاقة "Is in" بين نوعي الكيان "Car" و"Garage". فماذا يعني الآن إضافة العلاقة على أي حال بالنسبة إلى نموذج بياناتنا المنطقي؟

وبناءً على ما سبق، قد نصل إلى نموذج البيانات المفاهيمي التالي. وقد أضفنا تعدديات وخواص إضافية.

وإذا ترجمنا نموذج البيانات هذا إلى نموذج بيانات منطقي، نحصل على النتيجة أدناه.

الآن أصبح هناك تكرار. لأنه إذا أردنا معرفة أي عميل اشترى سيارة في كراج معين، يمكننا النظر في جدول "Buys_car_in". ويمكننا أيضًا النظر في جدول "Car"، لأنه لكل سيارة مباعة توجد إشارة في هذا الجدول إلى العميل وإلى الكراج معًا. ولكن لماذا يُعدّ ذلك مشكلة؟

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

• شذوذات الإدراج (Insert anomalies)
• شذوذات الحذف (Delete anomalies)
• شذوذات التحديث (Update anomalies)

وبإيجاز، في جدول "Car" قد نضيف بيانات (إدراج) أو نحذف بيانات (حذف) أو نعدّل بيانات (تحديث) دون تعديل البيانات نفسها في جدول "Buys_car_in"، والعكس صحيح. وهذه مشكلة لأننا بذلك نُخلّ بسلامة قاعدة بياناتنا.

ونعني بـسلامة قاعدة البيانات أن البيانات في قاعدة البيانات ينبغي أن تعكس الواقع بشكل صحيح. فمثلًا، إذا لم تتم عملية بيع، سنحذف الإشارة إلى العميل في جدول "Car". وإذا نسيَنا حذف الإشارة إلى هذه العملية في جدول "Buys_car_in"، فلن تكون البيانات في قاعدة البيانات صحيحة بعد الآن. فقد سجّلنا عملية بيع في جدول "Buys_car_in"، لكننا لم نسجّلها في جدول "Car". وهذا مثال على شذوذ التحديث.

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

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

التطبيع

لتجنّب التكرار في نموذج بيانات، سنقوم بـتطبيع (normalize) نموذج البيانات. والتطبيع هو العملية التي نصوغ بها نموذج البيانات (وقاعدة البيانات النهائية) في وحدات منطقية. ولإرشادنا في ذلك، نستخدم الصيغ الطبيعية (normal forms)، حيث تفرض كل صيغة طبيعية شروطًا معينة على الجداول في نموذج البيانات. وتهدف الشروط الواردة في هذه الصيغ الطبيعية إلى تقليل التكرار وضمان السلامة.

وتستند الخلفية النظرية للصيغ الطبيعية إلى منطق الرتبة الأولى حيث تُزال الاعتماديات القائمة بين الأعمدة المختلفة لإزالة تكرار البيانات. فمثلًا، يحدد العمود "Zip Code" العمود "Municipality"، لذا يمكن إزالة أحدهما.

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

الصيغة الطبيعية الأولى

تنص الصيغة الطبيعية الأولى، 1NF ("first normal form")، على أن الجدول يكون في الصيغة الطبيعية الأولى إذا لم تكن أي قيمة في الجدول جدولًا في حد ذاتها. وبعبارة أخرى، إذا كان لنوع كيان خاصية متعددة القيم، فيجب أن نفصل هذه الخاصية عند تحويل نموذج البيانات المفاهيمي إلى نموذج بيانات منطقي، فننشئ جدولًا منفصلًا، تمامًا كما وصفنا أعلاه. ويمكننا القول عن أي جدول يحقق هذا الشرط إنه في الصيغة الطبيعية الأولى.

الصيغة الطبيعية الثانية

تنص الصيغة الطبيعية الثانية، 2NF ("second normal form")، على أن الجدول يجب أن يحقق ما يلي:

• الصيغة الطبيعية الأولى،
• وأن يعتمد كل عمود في الجدول (وهو ليس جزءًا من مفتاح مرشّح للجدول) دائمًا على كامل الأعمدة التي تشكّل مفتاحًا مرشّحًا.

والشرط الثاني معقد بعض الشيء. أولًا، لدينا مفهوم "الاعتماد"، وهو يعني أساسًا أن قيمة عمود تحدد قيمة عمود آخر. فمثلًا، لدينا جدول "Address" يحتوي عناوين. ويحتوي الجدول الأعمدة "Street" و"House no." و"Postal code" و"City". والمفتاح المرشّح الوحيد هو تركيب "Street" و"House no" و"Postal Code". فإذا عرفنا قيمة كل من هذه الأعمدة الثلاثة، أمكننا تحديد الصف المناسب.

ويعتمد العمود "Municipality" على العمود "Zip Code"، لأنه إذا عرفنا قيمة "Zip Code" أمكننا تحديد قيمة "Municipality". فمثلًا، الرمز البريدي 3053 هو رمز Oud-Heverlee. وبالعكس، لا يعتمد العمود "Postal Code" على العمود "Municipality"، لأنه إذا عرفنا قيمة "Municipality" لم نستطع تحديد قيمة "Zip Code" بشكل قاطع. فمثلًا، لبلدية Oud-Heverlee الرموز البريدية 3053 (Oud-Heverlee) و3051 (Sint-Joris-Weert) و3052 (Blanden) و3053 (Haasrode) و3053 (Vaalbeek). وكل هذه أحياء من Oud-Heverlee. فالرمز البريدي يحدد البلدية تحديدًا فريدًا، لكن البلدية لا تحدد الرمز البريدي تحديدًا فريدًا. وبذلك يعتمد العمود "Municipality" على العمود "Postal code"، لكن العمود "Postal code" لا يعتمد على العمود "Municipality".

و"Zip code" جزء من مفتاح مرشّح، لكنه ليس في حد ذاته مفتاحًا مرشّحًا. ولا يعتمد العمود "Municipality" على كامل الأعمدة التي تشكّل مفتاحًا مرشّحًا، بل على عمود واحد من مفتاح مرشّح فقط. وعليه، لا يتحقق الشرط الثاني.

Street	House number	Postal code	Municipality
Stationlei	12	1800	Vilvoorde
Bondgenotenlaan	16	3000	Leuven
Maurice Dequeeckerplein	1	2100	Deurne
Maurice Dequeeckerplein	26	2100	Deurne
Turnhoutsebaan	20	2100	Deurne
Molenberg	14	3290	Deurne

لتحقيق الشرط الثاني، نحتاج إلى تقسيم هذا الجدول إلى جدولين منفصلين. الجدول الأول "Address" يتكوّن من الأعمدة "Street" و"House no" و"Postal code".

Street	House no	Postal code
Station Valley	12	1800
Bondgenotenlaan	16	3000
Maurice Dequeeckerplein	1	2100
Maurice Dequeeckerplein	26	2100
Turnhoutsebaan	20	2100
Molenberg	14	3290

وبعد ذلك، ننشئ جدولًا ثانيًا "Municipality" يحتوي العمودين "Zip Code" و"Municipality".

Postal code	Municipality
1800	Vilvoorde
3000	Leuven
2100	Deurne
3290	Deurne

وبذلك يحقق جدولانا الآن الشرط الثاني للصيغة 2NF.

الصيغة الطبيعية الثالثة

تنص الصيغة الطبيعية الثالثة، 3NF ("third normal form")، على أن الجدول يجب أن يحقق ما يلي:

• الصيغة الطبيعية الثانية،
• وأن يعتمد كل عمود في الجدول على أحد المفاتيح المرشّحة وحدها.

وتنص الصيغة الطبيعية الثانية على أن جميع الأعمدة التي لا تنتمي إلى مفتاح مرشّح يجب أن تعتمد على المفتاح المرشّح كاملًا، وبالتالي ينبغي ألا تعتمد على جزء من مفتاح مرشّح فقط.

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

فمثلًا، لدينا جدول "Staff member" يحتوي بيانات الموظفين. ويحتوي الجدول الأعمدة "Staff number" و"Name" و"Street" و"House number" و"Zip code" و"City". والمفتاح المرشّح الوحيد هو "Staff number". وكل قيمة مفردة، لذا نحقق الصيغة الطبيعية الأولى. وكل قيمة من قيم الأعمدة الأخرى يحددها المفتاح "Staff Number"، لذا نحقق الصيغة الطبيعية الثانية. ومرة أخرى يحدد العمود "Zip Code" العمود "Municipality". و"Postal code" ليس جزءًا من مفتاح مرشّح هنا. وبذلك يوجد عمود لا يعتمد على المفتاح المرشّح وحده، لذا لا نحقق الشرط الثاني للصيغة 3NF.

Staff no	Name	Street	House no	Postal code	Municipality
0000001	Jan	Station Valley	12	1800	Vilvoorde
0000002	Kaat	Bondgenotenlaan	16	3000	Leuven
0000003	Hans	Maurice Dequeeckerplein	1	2100	Deurne
0000004	Petra	Maurice Dequeeckerplein	26	2100	Deurne
0000005	Kaat	Turnhoutsebaan	20	2100	Deurne
0000006	Pieter	Molenberg	14	3290	Deurne

لتحقيق الشرط الثاني، نحتاج إلى تقسيم هذا الجدول إلى جدولين منفصلين. الجدول الأول "Address" يتكوّن من الأعمدة: "Street" و"House no" و"Postal code". وبعد ذلك، ننشئ جدولًا ثانيًا "Municipality" يحتوي العمودين "Zip Code" و"Town".

Staff number	Name	Street	House no	Postal code
0000001	Jan	Station Valley	12	1800
0000002	Kaat	Bondgenotenlaan	16	3000
0000003	Hans	Maurice Dequeeckerplein	1	2100
0000004	Petra	Maurice Dequeeckerplein	26	2100
0000005	Kaat	Turnhoutsebaan	20	2100
0000006	Pieter	Molenberg	14	3290

Postal code	Municipality
1800	Vilvoorde
3000	Leuven
2100	Deurne
3290	Deurne

وبذلك يحقق جدولانا الآن الشرط الثاني للصيغة 3NF.

الاستنتاجات

للتطبيع أثر على نموذج بياناتك المنطقي. وبمجرد أن تقرر تقسيم جدول، يلزمك أيضًا تعديل ذلك في نموذجك المنطقي.

ولا نتوقع أن تكون قادرًا على تحويل نموذج إلى صيغة طبيعية معينة. لكن ما نتوقعه أن تكون قادرًا على شرح مفهوم التطبيع، وأن تكون متعمدًا في تعاملك مع التكرار.