تُعد التسوية في مجال تصميم قواعد البيانات العلائقية طريقة منهجية لضمان تناسب هيكل قاعدة البيانات مع الأغراض العامة، وخُلُوِّها من أي صفات غير مرغوب فيها—مثل الإدراج، والتحديث، والحذف الخطأ—التي قد تُؤدي إلى فقدان صحة البيانات.[1] وقدَّم إدجار كود، مخترع النموذج العلائقي، مفهوم التسوية وما يُعرف الآن باسم نموذج التسوية الأول (1NF) في عام 1970.[2] كما عرَّف كود نموذج التسوية الثاني (2NF)، ونموذج التسوية الثالث (3NF) في عام 1971.[3] كود ورايموند بويس، نموذج بويس-كود للتسوية (BCNF) في عام 1974.[4] ذلك بالإضافة إلى تعريف أشكال أخرى من التسوية من قبل باحثين آخرين في سنوات لاحقة. وكان آخرها نموذج التسوية السادس (6NF) الذي قدمه كريس ديت، وهيو داروين، ونيكوس لورينتوس في عام 2002.[5]
وكثيراً ما يُوصف جدول قاعدة البيانات العلائقية بأنه "تسوية" في حالة نموذج التسوية الثالث.[6] وتخلو معظم جداول الـ3NF من الإدراج، والتحديث، والحذف الخاطيء. أي أن جداول الـ3NF ترتبط في معظم الأحيان بالـBCNF، والـ4NF، والـ5NF (ولكنه لا يرتبط بالـ6NF).
وينبغي على المصمم إنشاء تصميم تم تسويته بالكامل؛ حيث يُمكن إلغاء التسوية لأسباب أدائية.[7] ومع ذلك، تتطلب بعض تخصصات النمذجة، مثل النمذجة ثلاثية الأبعاد في التعامل مع تصميم مستودع البيانات، وتصميمات لم يتم تسويتها[8]. وهي التصميمات التي لا ترتبط بالـ3NF.
أهداف تسوية قاعدة البيانات
يهدف نموذج التسوية الأول الذي عرَّفه كود في عام 1970 إلى الاستعلام عن البيانات والتعامل معها باستخدام "لغة فرعية عالمية للبيانات" تعتمد على منطق الرتبة الأولى.[9] (وتعتبر لغة الاستعلامات البنيوية إس كيو إل مثال على تلك اللغات البيانية).[10] وتعتبر عملية الاستعلام عن البيانات والتعامل معها في إطار هيكل بيانات غير مستوي عملية معقدة جداً. مثال: التمثيل التالي الذي لا يرتبط بالـ1NF الخاص بعمليات بطاقات الائتمان الخاصة بالعملاء:
| العميل | المعاملات
| |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| جونز |
| |||||||||
| ويلكنز |
| |||||||||
| ستيفنز |
|
تتكرر مجموعة من المعاملات لكل عميل. ويَشمل التقييم الآلي للاستعلام عن معاملات العملاء مرحلتين:
- تفريغ مجموعة أو أكثر من معاملات العملاء، مما يسمح بفحص المعاملات الفردية في كل مجموعة
- استخلاص نتيجة استعلام استناداً إلى نتائج المرحلة الأولى
فعلى سبيل المثال، يجب على النظام تفريغ مجموعة معاملات لكل عميل، ثم جمع مبالغ جميع المعاملات التي تمت قي شهر أكتوبر عام 2003، وذلك لمعرفة المبالغ النقدية لجميع المعاملات التي تمت في شهر أكتوبر 2003 لكل العملاء.
ومن أهم أراء كود أنه يمكن التخلص من هذا التعقيد الهيكلي، مما قد يُؤدي إلى حُدوث قدر أكبر من القوة والمرونة في كيفية صياغة وتقييم أسلوب الاستعلام (بواسطة المستخدمين والبرمجيات التطبيقية، ونظام إدارة قواعد البيانات). ويُمكن أن يظهر البديل الذي تم تسويته للهيكل أعلاه كالآتي:
| العميل | كود العملية | التاريخ | المبلغ |
|---|---|---|---|
| جونز | 12890 | 14 أكتوبر 2003 | -87 |
| جونز | 12904 | 15 أكتوبر 2003 | -50 |
| ويلكنز | 12898 | 14 أكتوبر 2003 | -21 |
| ستيفنز | 12907 | 15 أكتوبر 2003 | (18) |
| ستيفنز | 14920 | 20 نوفمبر 2003 | -70 |
| ستيفنز | 15003 | 27 نوفمبر 2003 | -60 |
يُمثل كل صف معملة فردية ببطاقة الائتمان، ويمكن لنظام إدارة قواعد البيانات الحصول على نتيجة الفائدة من خلال إيجاد جميع الصفوف التي ترتبط بالتاريخ الواقع في شهر أكتوبر، ثم جمع المبالغ الخاصة بهم. وتنطبق نفس الشروط على كافة قيم هيكل البيانات: حيثُ يتعرضون جميعاً إلى نظام إدارة قواعد البيانات مباشرةً، ويُمكنها المشاركة في الاستعلامات بشكل مباشر. في حين توضع بعض القيم في هياكل منخفضة المستوى في الحالة السابقة. وبالتالي، يصبح التصميم الذي تمت تسويته مناسباً لعملية الاستعلام ذات الغرض العام، بينما لا يقوم التصميم الآخر بذلك.
ذكر كود أهداف التسوية لنظام الـ1NF، وتمنح الفروع التالية تفاصيل عن كل هدف على حدى.
خلو قاعدة البيانات من التعديل الخاطيء
.
عند تعديل (تحديث، أو إضافة، أو حذف) أي جدول، يُمكن أن يُؤدي ذلك إلى حدوث آثار جانبية غير مرغوب فيها. ولا تتعرض كل الجداول إلى هذه الآثار الجانبية؛ تظهر هذه الآثار الجانبية في الجداول التي لم يتم تسويتها بشكل كافي. ويمكن أن يضم الجدول الذي لم يتم تسويته بشكل كاف واحدة أو أكثر من الخصائص التالية:
- يمكن تمثيل نفس المعلومات في صفوف متعددة؛ وبالتالي، قد تؤدي أي تحديثات تطرأ على الجدول إلى حدوث تناقضات منطقية. فعلى سبيل المثال، قد تضم كل حالة تسجيل داخل جدول "مهارات الموظفين" كود الموظف، وعنوانه، ومهارته؛ وبالتالي، فإن تغيير الموظف لعنوانه سيَحتاج إلى تطبيقه على تسجيلات متعددة. وإذا لم يتم التحديث بنجاح، سيظل الجدول في حالة غير متناسقة. حيث يمنح الجدول إجابات متضاربة عن عنوان الموظف. وتعرف هذه الظاهرة بتحديث الوضع الخاطيء
- في بعض الأحيان، لا يمكن تسجيل حقائق معينة. فعلى سبيل المثال، قد يضم جدول "الكلية ومقرراتها" كود الكلية، واسم الكلية، وتاريخ استئجار الكلية، وكود المنهج؛ وبالتالي، يمكن تسجيل تفاصيل أي عضو في هيئة التدريس يقوم بتدريس مادة واحدة على الأقل، ولكن لا يمكن تسجيل تفاصيل عضو جديد لم يتم تعيينه لتدريس أي مادة. وتُعرف هذه الظاهرة بالإدراج الخاطيء
- في بعض الحالات التي يُمثل فيها حذف البيانات معلومات معينة، يجب أن تمثل البيانات معلومات مختلفة تماماً. ويعاني جدول "الكلية والمقررات" الموضح في المثال السابق من هذه الأخطاء. حيث أنه في حالة توقف أحد أعضاء هيئة التدريس مؤقتاً عن تدريس أي دورات، يجب علينا حذف آخر تسجيل ظهر فيه هذا العضو. وتُعرف هذه الظاهرة باسم الحذف الخاطيء.
تقليل إعادة التصميم عند مد هيكل قاعدة البيانات
عندما يتم تسوية هيكل قاعدة البيانات بشكل تام، ومده لاستيعاب أنواع جديدة من البيانات، يمكن ألا تتغير جوانب هيكل قاعدة البيانات إلى حدٍ كبير. ونتيجة لذلك، ستتأثر التطبيقات المتفاعلة مع قاعدة البيانات بشكل بسيط.
كيفية جعل نموذج البيانات أكثر إفادةً للمستخدمين
تعكس الجداول المستوية والعلاقة بينها مفاهيم العالم الحقيقي والعلاقات المتبادلة بينهم.
تجنب التحيز تجاه أي نمط معين من الاستعلام
تعد الجداول المستوية مناسبة للاستعلامات ذات الغرض العام. وهذا يعني أنه يتم تدعيم أي استفسارات حول هذه الجداول، بما في ذلك الاستفسارات المستقبلية التي لا يمكن التنبؤ بتفاصيلها. وفي المقابل، تعتبر الجداول التي لم يتم تسويتها مفيدة لبعض أنواع الاستعلامات.
خلفية التسوية: التعاريف
- التبعية الوظيفية: يعتمد الخاصية B وظيفياً على الخاصية A (أي A → B)، وذلك في حالة وجود قيمة مماثلة من الخاصية B لكل قيمة من الخاصية A. وإذا تكررت قيمة A في صفوف، ستتكرر قيمة B أيضاً. وفي هذا المثال، يعتمد عنوان الموظف وظيفياً على مُعرِّف الموظف، وذلك لأن قيمة معرف الموظف يقابلها عنوان موظف واحد. (ملحوظة: ليس بالضرورة أن يكون العكس صحيحاً: فيمكن أن يعيش عدد من الموظفين في نفس العنوان، وبالتالي يمكن أن يقابل عنوان الموظف الواحد أكثر من معرف. ومن ثم لا يعتمد معرف الموظف وظيفياً على عنوان الموظف). وقد يعتمد الخاصية وظيفياً على خاصية واحد أو أكثر. وليس من الممكن تحديد مدى إمكانية تسوية تصميم من دون تفهم التبعيات الوظيفية التي تنطبق على الخاصيةات الموجودة في الجداول؛ وهذا يتطلب معرفة مجال المشكلة. فعلى سبيل المثال، يُمكن لصاحب العمل أن يطلب من بعض الموظفين تقسيم وقتهم بين موقعين، مثل مدينة نيويورك ولندن، ومن ثم يرغب في تحديد أكثر من عنوان لهؤلاء الموظفين. وفي هذه الحالة، لن يعتمد عنوان الموظف وظيفياً على معرف الموظف.
استعراض الوظائف الحسابية الأساسية:
نفترض أن الدالة Fx هي دالة رياضية ذات قيمة واحدة ومتغير مستقل واحد. ويشبه المتغير المستقل الخاصية A، المتغير التابع (أو الخاصية التابع). وبالتالي، فإن مصطلح التبعية الوظيفية هي قيمة الدالة FA؛ A هي خاصية مستقل. ومن ثم يمكن أن تشمل الوظائف ذات القيمة الواحدة على ناتج واحد فقط. ومن الشائع التعبير عن هذه العلاقة في الرياضيات كالآتي: F(A) = B أو F : A → B.
وهناك أيضاً وظائف ذات أكثر من متغير مستقل، وهي تسمى وظائف متعددة المتغيرات. وتمثل هذه الفكرة خاصية يعتمد وظيفياً على مزيج من الأتربيوتات. وبالتالي، تحتوى الدالة Fxyz على ثلاثة متغيرات مستقلة أو خاصيةات مستقلة، وخاصية واحد مستقل هو F:x,y,z.
- التبعية الوظيفية البسيطة
- التبعية الوظيفية البسيطة هي تبعية وظيفية لخاصية يعتمد على مجموعة شاملة. (معرف الموظف، عنوان الموظف) → (عنوان الموظف) بسيط، مثل (عنوان الموظف) → (عنوان الموظف).
- التبعية الوظيفية الكاملة
- يعتمد الخاصية وظيفياً بشكل تام على مجموعة من الخاصيةات X إذا
-
- كانت تعتمد وظيفياً على X
- لا تعتمد وظيفياً على أي مجموعة فرعية لـX. ويعتمد (عنوان الموظف) وظيفياً على (مُعرف الموظف، ومهارته)، ولكنه لا يعتمد عليهما بشكل تام، لأنه يعتمد أيضاً على (معرف الموظف).
- تبعية متعدية
- التبعية المتعدية هي تبعية وظيفية غير مباشرة حيث يكون: X→Z نتيجة X→Y، وY→Z.
- تبعية متعددة القيم
- تعد التبعية متعددة القيم أحد المعوقات، حيث أن وجود صفوف معينة في الجدول يعني وجود صفوف معينة أخرى.
- تبعية متصلة
- يتعرض الجدول تي إلى تبعية متصلة عندما يمكن إعادة صياغة تي من خلال توصيل جداول متعددة، ويشمل كل منها على مجموعة فرعية من الخاصية تي.
- المفتاح الشامل
- المفتاح الشامل هو خاصية أو مجموعة من الخاصيةات التي تحدد الصفوف داخل الجدول بشكل فريد؛ فأي صفين مميزين دائماً ما يكون لهما مفتاح شامل مميز. ويمكن أن يكون كل من معرف الموظف، وعنوان الموظف، والمهارة مفاتيح شاملة لجدول مهرات الموظفين؛ يمكن أن يكون (معرف الموظف، والمهارة) أيضاً مفتاح شامل.
- المفتاح المرشح
- المفتاح المرشح هو مفتاح شامل صغير، حيث أنه لا يشمل على مفاتيح شاملة فرعية أخرى. ويمكن أن يكون معرف الموظف والمهارة مفاتيح مرشحة في جدول "مهارات الموظف".
- الخاصية غير الرئيسي
- الخاصية غير الرئيسي هو خاصية لا يحدث في وجود أي مفتاح مرشح. ويمكن أن يكون عنوان الموظف خاصية غير رئيسي في جدول مهارات الموظفين".
- المفتاح الأساسي
- تحتاج معظم أنظمة إدارة قواعد البيانات إلى جدول ذو مفتاح واحد فريد، بدلاً من مفاتيح ممكنة متعددة. ومن ثم فإن المفتاح الأساسي هو المفتاح الذي قام مصمم قاعدة البيانات بتصميمه لهذا الغرض.
الأشكال العادية
توفر الأشكال العادية لنظرية قواعد البيانات العلائقية معايير لتحديد درجة ضعف الجدول وتناقضاته المنطقية وأخطائه. وكلما زادت قابلية تطبيق الشكل العادي على الجدول، قَلَّت درجة التناقضات والأخطاء. وهناك "أكثر النماذج العادية تطبيقاً"(HNF) لكل جدول: ووفقاً للتعريف، يفي الجدول دائماً بمتطلبات الـHNF الخاص به، وجميع الأشكال العادية الاقل من الـHNF الخاص به؛ كما يفشل الجدول في تلبية احتياجات أي شكل طبيعي يزيد عن الـHNF.
ويُمكن تطبيق أشكال عادية على الجداول الفردية؛ تصبح قاعدة البيانات في شكلها العادي n عندما تكون جميع الجداول في شكلها العادي n.
يفترض مصممو قاعدة البيانات أحياناً أن عملية التسوية تتم بشكل متكرر، أي أنه يتم تسوية تصميمات الـ1NF لتصبح 2NF، ثم إلى 3NF، وهكذا. لا يعد ذلك وصفاً دقيقاً لكيفية تسوية قواعد البيانات. ويمكن أن يقع الجدول الذي صمم بشكل معقول في نمط الـ3NF في أول محاولة؛ وإذا كان في نظام الـ3NF، فمن المحتمل أن يصل الـHNF إلى الـ5NF. ولا يتطلب تحقيق "أشكال عادية" فوق الـ3NF أن يبذل المصمم جهد إضافي، وذلك لأن جداول الـ3NF لا تحتاج عادةً إلى حدوث تعديلات لتلبية احتياجات تلك الأشكال العادية.
تتلخص الأشكال العادية الرئيسية كالآتي:
| النموذج العادي | عرفه | تعريف موجز |
|---|---|---|
| النموذج العادي الأول (1NF) | نسختين: إي كيف كود (1970)، سي جيه دات (2003) [11] | يمثل الجدول علاقة، ولا يحتوى على مجموعات متكررة |
| النموذج العادي الثاني (2NF) | إي إف كود (1971) [12] | لا يعتمد أي خاصية غير أساسي وظيفياً على جزء (فرع مناسب) من المفتاح المرشح. |
| النموذج العادي الثالث (3NF) | إي إف كود (1971) [13]؛ انظر أيضًا: معادلة كارلو زانيولو، تعريف مختلف (1982) [14] | لا يعتمد الخاصية غير الأساسي بشكل تعددي على كل مفتاح في الجدول. |
| نموذج بويس-كود العادي (BCNF) | ريمون بويس وكود (1974) [15] | تعتمد كل تبعية وظيفية بسيطة في الجدول على المفتاح الشامل |
| النموذج العادي الرابع (4NF) | رونالد فاجن (1977) [16] | تعتمد جميع التبعيات متعددة القيمة غير البسيطة في الجدول على المفتاح الشامل |
| النموذج العادي الخامس (5NF) | رونالد فاجن (1979) [17] | تشمل التبعية المتصلة غير البسيطة في الجدول علي المفاتيح الشاملة |
| مجال/النموذج العادي الأساسي (DKNF) | رونالد فاجن (1981) [18] | كل معوق في الجدول هو نتيجة منطقية لمجال الجدول. |
| النموذج العادي السادس (6NF) | سي جيه دات، وهيو داروين، ونيكوس لورينتسوس (2002) [5] | لا تشمل خصائص الجدول تبعيات متصلة غير بسيطة |
عدم التسوية
وعادةً ما تكون قواعد البيانات المخصصة لمعالجة المعاملات التجارية التي تتم عبر الإنترنت (OLTP) أكثر طبيعيةً من قواعد البيانات المخصصة للمعالجة التحليلية التي تتم عبر الإنترنت (OLAP). وتتميز تطبيقات الـOLTP بأنها تضم صفقات صغيرة ذات حجم كبير مثل تحديث تسجيلات المبيعات في السوبر ماركت. وبالتالي، يتوقع أن تترك كل معاملة قاعدة البيانات بشكل متناسق. وعلى الوجه الآخر، تعتبر قواعد البيانات المصممة لعمليات الـOLAP "للقراءة فقط" في معظم الحالات. وتميل تطبيقات الـOLAP إلى استخراج بيانات تاريخية تراكمت على مدار فترة طويلة من الزمن. وقد تُسهل البيانات غير المفيدة من عمل تطبيقات استخبارات الأعمال. كما تضم جداول الأبعاد في النموذج النجمي بيانات لم يتم تسويتها. ويجب التحكم في البيانات التي لم يتم تسويتها بعناية أثناء عملية استخراج ونقل وتحميل البيانات. ولا يجب السماح للمستخدمين برؤية هذه البيانات حتى تصبح في حالة متناسقة. ويعد البديل المستوى للنموذج النجمي هو المخطط الثلجي. وتقل الحاجة إلى عدم التسوية في كثير من الحالات لأن أجهزة الكمبيوتر وبرامج الـRDBMS أصبحت أكثر قوة. ومنذ أن زادت أحجام البيانات بوجه عام مع أداء الأجهزة والبرامج، تستخدم قواعد بيانات الـOLAP مخططات لم يتم تسويتها.
كما تستخدم عملية عدم التسوية أيضاً لتحسين أداء أجهزة الكمبيوتر الصغيرة وأجهزة المحمول. حيث يمكنها استخدام هذه البيانات للبحث فقط (البحث عن الأسعار مثلاً). كما تستخدم أيضاً في حالة عدم وجود RDBMS (مثل Palm)، أو في حالة عدم تغيير البيانات، مما يستوجب استجابة سريعة وحاسمة.
النموذج العادي غير الأول (NF² أو N1NF)
يمكن أن يكون عدم التسوية مفيداً، ومن ثم يُعرِّف النموذج العادى غير الأول تصميمات قاعدة البيانات التي لا تتفق مع النموذج العادي الأول من خلال "مجموعات مجالات الخاصية" (Schek 1982). ويجب أن تمتد اللغات المستخدمة في التعامل والاستعلام عن البيانات داخل النموذج، وذلك لدعم مثل هذه القيم.
يجب النظر إلى تلك القيم المهيكلة باعتبارها أنواع متخصصة من القيم (المجالات)، ولغاتهم المحددة. فالنماذج غير الـ1NF هي امتداد النموذج العلائقي واللغات المستخدمة في الاستعلام عنه من خلال آلية عامة خاصة بهذا الهيكل. فعلى سبيل المثال، يُدعم النموذج العلائقي المتداخل استخدام العلاقات باعتبارها قيم من خلال إضافة مشغلين (متداخل وغير متداخل) إلى الجبر العلائقي الذي يمكن أن يخلق علاقات متداخلة.
أنظر الجدول التالي:
| الشخص | اللون المفضل |
|---|---|
| بوب | أزرق |
| بوب | أحمر |
| جين | أخضر |
| جين | أَصْفَر |
| جين | أحمر |
لنفرض أن هناك شخص لديه أكثر من لون مفضل. تتكون الألوان المفضلة من مجموعة من الألوان وفقاً للجدول. ويحتاج تحويل جدول 1NF إلى جدول NF² "مشغل متداخل" لمد الجبر العلائقي الخاص بأعلى الأشكال العادية. وعند تطبيق "المشغل المتداخل" على جدول الـ1NF، ينتج جدول الـNF² التالى:
| الشخص | الألوان المفضلة | ||||
|---|---|---|---|---|---|
| بوب |
| ||||
| جين |
|
ولتحويل هذا الجدول إلى جدول 1NF مرة أخرى، يجب استخدام "مشغل غير متداخل" لمد الجبر العلائقي الخاص بأعلى الأشكال العادية.
على الرغم من أن "المشغل غير المتداخل" هو رياضياً عكس "المشغل المتداخل"، لا يصبح "المشغل المتداخل" دائماً عكس "المشغل غير المتداخل". كما يجب أن تكون المشغلات متقابلة، والتي يغطيها النموذج العادي المقسم (PNF).
قراءات أخرى
- نصائح ليت: تسوية
- سي جي دات(1999)، مقدمة لنظم قواعد البيانات (الطبعة الثامنة). أديسون ويسلي لونجمان. ردمك 0-321-47266-7
- دابليو كينت1983)، دليل بسيط حول خمسة أشكال عادية في نظرية قاعدة البيانات العلائقية، اتصالات إيه سي إم، المجلد 26، صـ. 120-125
- سي جيه دات، وإتش داروين. وإف باسكال، تفنيد قاعدة بيانات
- إتش جيه شيك، وبي بيستور، هياكل البيانات لإدارة قاعدة بيانات متكاملة ونظام استرجاع المعلومات
ملاحظات ومراجع
- إي إف كود، النموذج العلائقي لإدارة قواعد البيانات: الإصدار الثاني. أديسون ويسلي (1990)، صـ. 271
- Codd, E.F. (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM. 13 (6): 377–387. doi:10.1145/362384.362685. مؤرشف من الأصل في 14 يوليو 2007.
- إي إف كود، "تسوية نموذج قاعدة البيانات العلائقي". (جزء من السلسة السادسة من ندوات كورانت لعلوم الحاسب الآلي، "نظم قاعدة البيانات"، مدينة نيويورك، الرابع والعشرين والخامس والعشرين من شهر مايو عام 1971). تقرير أبحاث آي بي إم RJ909 (أغسطس 31، 1971). أُعيد نَشره في طبعة راندال روستين، نظم قاعدة البيانات: سلسلة ندوات كورانت لعلوم الحاسب الآلي، قاعة برنتيس، 2003.
- كود، "التحقيقات الأخيرة في نظم قاعدة البيانات العلائقية." تقرير أبحاث آي بي إم RJ1385 (أبريل، 23، 1947). أُعيد نشره في عام 1974، الكونغرس، (استوكهولم، والسويد عام 1974). نيويورك، الولايات المتحدة: شمال هولندا (1974).
- دات وهيو داروين، ونيكوس لورينتسوس. البيانات الزمنية والنموذج العلائقي. مورجان كوفمان (2002)، صـ. 176
- دات، مقدمة عن نظم قواعد البيانات. أديسون ويسلي (1999)، ص. 290
- كتب كريس دات: "أعتقد أن عدم تسوية أي تصميم يُعد باطلاً... فيجب أن يكون خيار "عدم التسوية" ملاذك الأخير. أي أنه يمكنك التخلي عن تسوية التصميم في حالة فشل جميع الاستراتيجيات الأخرى في تحسين الأداء". سي جيه دات، قاعدة البيانات في العمق: النظرية العلائقية للممارسين. أزريلي (2005)، ص. 152.
- كتب رالف كيمبل: "يلغي استخدام نماذج تسوية في مجال عرض تخزين البيانات الغرض من تخزين البيانات وهو استرجاع البيانات بسرعة". رالف كيمبال، أداة تخزين البيانات، الطبعة الثانية ويلي الكمبيوتر للنشر، (2002)، ص. 11.
- "يسمح اعتماد نموذج البيانات العلائقية... بتطوير لغة فرعية عالمية للبيانات، تستند إلى تطبيق الحساب الإسنادي. ويكفي الحساب الإسنادي الأول إذا كانت مجموعة العلاقات (قاعدة البيانات) في النموذج العادي الأول. وتوفر هذه اللغة مقياساً للقوة الغوية الخاصة بالبيانات المقترحة. وستكون أيضاً مرشحاً قوياً لاحتواء (مع بعض التعديلات التركيبية المناسبة) مجموعة متنوعة من اللغات المضيفة (البرمجة، أو الأوامر الموجهة نحو حل المشاكل)". كود، "نموذج البيانات العلائقي لمصارف البيانات المشتركة الكبيرة"، ص. 381 نسخة محفوظة 31 أغسطس 2006 على موقع واي باك مشين.
- كود، الفصل 23، "عيوب الـSQL الخطيرة"، النموذج العلائقي لإدارة قواعد البيانات: الإصدار الثاني أديسون ويسلي (1990)، ص. 371-389
- سي جيه دات "ماذا يعني النموذج العادي الأول"، دات وقاعدة البيانات: كتابات عام 2000-2006 (سبرينغر فيرلاج، 2006)، ص. 127-128.
- كود، "تسوية نموذج قاعدة البيانات العلائقية". (السلسة السادسة من ندوات كورانت لعلوم الحاسب الآلي، "نظم قاعدة البيانات"، مدينة نيويورك، 24-25 مايو 1971). تقرير أبحاث آي بي إم RJ909 (أغسطس،31 ،1971). أُعيد نشره في طبعة راندال روستين، نظم قاعدة البيانات: السلسة السادسة لندوات كورانت لعلوم الحاسب الآلي. قاعة برنتيس، 2003.
- كود، "تسوية نموذج قاعدة البيانات العلائقية". (السلسلة السادسة من ندوات كورانت لعلوم الحاسب الآلي، "نظم قاعدة البيانات"، مدينة نيويورك، 24-25 مايو 1971). تقرير أبحاث آي بي إم RJ909 (أغسطس،31 ،1971). أُعيد نشره في طبعة راندال روستين، نظم قاعدة البيانات: السلسة السادسة لندوات كورانت لعلوم الحاسب الآلي.ـ قاعة برنتيس، 2003.
- كارلو زانيولو. "نموذج عادي جديد لتصميم قاعدة بيانات علائقية". معاملات إيه سي إم ونظم قاعدة البيانات 7 سبتمبر 1982.
- كود، ""التحقيقات الأخيرة في نظم قاعدة البيانات العلائقية. " تقرير أبحاث آي بي إم RJ1385 (أبريل، 23، 1974). أُعيد نشره في عام 1974، الكونغرس، (استوكهولم، والسويد عام 1974). نيويورك، الولايات المتحدة: شمال هولندا (1974).
- Fagin, Ronald (1977). "Multivalued Dependencies and a New Normal Form for Relational Databases" ( كتاب إلكتروني PDF ). ACM Transactions on Database Systems. 2 (1): 267. doi:10.1145/320557.320571.
- رونالد فاجين، "مشغلات الأشكال العادية وقواعد البيانات العلائقية". مؤتمر إيه سي إم حول إدارة البيانات، 31 مايو - 1 يونيو 1979، بوسطن، ماساشوستس، تقرير أبحاث آي بي إم RJ2471، فبراير 1979.
- رونالد فاجن (1981)، نموذج عادي لقواعد البيانات العلائقية التي تعتمد على المجالات والمفاتيح، اتصالات إيه سي إم، المجلد 6، صـ 387-415
- بحث: "علاقات النموذج العادي غير الأول" بقلم جي جايشكي، وإتش شيك؛ مركز آي بي إم هايدلبرغ العلمي. --> بحث حول مشغلات التسوية وعدم التسوية المتداخلة وغير المتداخلة، وذلك كما هو موضح في نهاية هذه الصفحة. ويصف البحث تفاصيل العلاقة بين الـ1NF والـNF^2
وصلات خارجية
- أساسيات تسوية قاعدة البيانات بقلم مايك تشابل (About.com)
- مقدمة لتسوية قاعدة البيانات، الجزء الثاني
- مقدمة لتسوية قاعدة البيانات بقلم مايك هيلير.
- التسوية بقلم آي تي إس، جامعة تكساس.
- كيفية استخدام أول ثلاثة أشكال عادية بقلم فريد كولسون
- أمثلة حول تسوية الديسيبل
- وصف أساسيات تسوية قاعدة البيانات، شركة مايكروسوفت
- تقنيات تسوية قاعدة البيانات وتصاميمها بقلم باري وايز.