البحث في الموقع

لقد صُمم نموذج البيانات العلائقية Relational Data Model في العام 1970 بواسطة C.F. Codd، وهو النموذج الأكثر استخدامًا في يومنا هذا، كما يُعَدّ الأساس لكل من: البحث العلمي في نظرية البيانات، والعلاقات، والقيود. العديد من منهجيات تصميم قواعد البيانات. لغة الوصول القياسية إلى قاعدة البيانات، حيث تسمى لغة الاستعلام المهيكلة structured query language - أي SQL اختصارًا-. جميع أنظمة إدارة قواعد البيانات التجارية الحديثة. يصف نموذج البيانات العلائقية العالم على أنه تجميعة من العلاقات والجداول المترابطة. المفاهيم الأساسية في نماذج البيانات العلائقية سنتعرف على المفاهيم الأساسية في نموذج البيانات العلائقية التي ترتكز ارتكازًا كبيرًا على العلاقة والجدول وكل الخصائص المتعلقة بهما. العلاقة العلاقة relation- أو ما تعرف أيضًا باسم الجدول table أو الملف file -، وهي مجموعة فرعية من الناتج الديكارتي لقائمة من المجالات التي تتميز بالاسم، حيث يمثِّل كل صف row ضمن الجدول الواحد مجموعةً من قيم البيانات ذات الصلة، ويُعرَف الصف أو السجل record باسم صف tuple أيضًا، كما يُعَدّ العمود في الجدول حقلًا، ويشار إليه باسم السِمة attribute أيضًا، كما يمكنك النظر إلى الأمر بالطريقة التالية: تُستخدَم السمات لتعريف السجلات، ويحتوي السجل على مجموعة من السمات. توضِّح الخطوات التالية المنطق بين العلاقة ومجالاتها: يُشار إلى عدد n من المجالات بالصورة: D1, D2, … Dn تُعَدّ r علاقةً محدَّدة على هذه المجالات. ثم r ⊆ D1 × D2 ×… × Dn الجدول Table تتكون قاعدة البيانات من عدة جداول، كما يحتوي كل جدول على بيانات، ويوضِّح الشكل التالي قاعدة بيانات تحتوي على ثلاثة جداول. الشكل 1: قاعدة بيانات بثلاثة جداول العمود Column تُخزِّن قاعدة البيانات أجزاء المعلومات أوالحقائق بطريقة منظَّمة، حيث يتطلب الفهم الجيد لكيفية استخدام قواعد البيانات والاستفادة منها إلى أقصى حد فهم طريقة التنظيم هذه. تسمى وحدات التخزين الرئيسية أعمدة columns، أو حقول fields، أو سمات attributes، وتضم هذه الوحدات المكونات الأساسية للبيانات التي يمكن تقسيم محتواها. تحتاج عند تحديد الحقول المراد إنشاؤها إلى التفكير في البيانات التي لديك عمومًا، فمثلًا، استخلاص المكونات المشتركة للمعلومات التي ستخزِّنها في قاعدة البيانات، وتجنُّب التفاصيل التي تميز عنصرًا عن الآخر. table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } Field Name Data First Name Isabelle Family Name Whelan Nationality British Salary 109,900 Date of Birth 15 September 1983 Marital Status Single Shift Mon, Wed Place of issue Addis Ababa Valid until 17 December 2003 مثال على معلومات حول بطاقة هوية المجال Domain يُمثِّل المجال المجموعات الأصلية للقيم الذَرية المستخدَمة لنمذجة البيانات، وتعني القيمة الذَرية atomic value أنّ كل قيمة في المجال غير قابلة للتجزئة بقدر ما يتعلق الأمر بالنموذج العلائقي، فمثلًا: يملك مجال الحالة الاجتماعية مجموعةً من الاحتمالات، وهي: متزوج، وأعزب، ومطلِّق. يملك مجال أيام العمل مجموعةً من جميع الأيام الممكنة، وهي: الأحد، الاثنين، …إلخ. مجال الراتب الشهري هو مجموعة جميع الأعداد الأكبر من 0 وأقل من 200000. مجال الاسم الأول هو مجموعة سلاسل الأحرف التي تمثل أسماء الأشخاص. باختصار، المجال هو مجموعة من القيم المقبولة التي يُسمح للعمود باحتوائها، كما يعتمد على الخصائص المختلفة ونوع بيانات العمود، وسنناقش أنواع البيانات في مقال آخر. السجلات Records مثلما يحتاج محتوى أي مستند أو عنصر إلى تقسيمه إلى أجزاء صغيرة من البيانات للتخزين في الحقول، فيجب أيضًا أن تكون مترابطةً بحيث يمكن إعادتها إلى شكلها الكامل، ويتم ذلك عن طريق استخدام السجلات، إذ تحتوي السجلات على حقول مرتبطة، مثل: حقل العميل customer، أو الموظف employee، كما يُستخدَم المصطلح صف أو سطر tuple أحيانًا على أساس مرادف للسجل. تشكل السجلات والحقول أساس جميع قواعد البيانات،و يمنحنا الجدول البسيط أوضح صورة عن كيفية عمل السجلات والحقول معًا في مشروع تخزين قاعدة بيانات. الشكل 2: مثال على جدول بسيط يوضِّح الجدول البسيط في الشكل السابق كيف يمكن للحقول الاحتفاظ بمجال واسع من مختلف أنواع البيانات، حيث يحتوي على: حقل ID (مُعرِّف السجل): هو عدد صحيح، ويُستخدَم لترتيب البيانات في الجدول. حقل PubDate (تاريخ النشر): ويحتوي على تاريخ النشر ويكون في الصورة (يوم/شهر/سنة). حقل Author (المؤلِّف): يحتوي على اسم المؤلِّف، وهو حقل يحتوي على بيانات نصية. نص Title (حقل العنوان): يحتوي على أيّ نص يُمثِّل عنوان المؤلِّف. من الممكن توجيه قاعدة البيانات للبحث في البيانات وتنظيمها بطريقة معينة، فمثلًا، يمكنك طلب مجموعة مختارة من السجلات محدودة حسب التاريخ بطرق عديدة، وهي: كل البيانات المسجَّلة قبل تاريخ معين، أو كل البيانات المسجَّلة بعد تاريخ معين، أو كل البيانات المسجَّلة بين تاريخين، ويمكنك بالمثل أيضًا ترتيب السجلات حسب التاريخ. نظرًا لإعداد الحقل أو السجل الذي يحتوي على البيانات على أساس حقل تاريخ، فلن تقرأ قاعدة البيانات المعلومات الموجودة في حقل التاريخ على أساس أعداد مفصولة بشرطة مائلة، وإنما على أساس تواريخ، بحيث يجب ترتيبها وفقًا لنظام التقويم. الدرجة Degree الدرجة هي عدد السمات في الجدول، فدرجة الجدول في المثال السابق الموضح في الشكل هي 4. خصائص الجدول لكل جدول في قاعدة البيانات اسم خاص به، ولا يتكرر الاسم الواحد في عدة جداول. يحتوي كل صف في الجدول على بيانات فريدة، ولا يتكرر الصف نفسه أكثر من مرة في الجدول. تكون المدخلات في الأعمدة ذَريةً بحيث لا يحتوي الجدول على مجموعات مكررة أو سمات متعددة القيم. تكون المدخلات في الأعمدة من المجال نفسه بناءً على نوع بياناتها، فإمّا أن تكون أعداد - أي عدد صحيح، كسري، …إلخ-، أو سلسلة محارف، أو تاريخ، أو قيم منطقية -أي صح أو خطأ-. غير مسموح بالعمليات التي تجمع بين أنواع البيانات المختلفة. كل سِمة لها اسم فريد. ترتيب الأعمدة غير مهم. ترتيب الصفوف غير مهم. المفاهيم الأساسية القيمة الذَرية atomic value: تعني أنّ كل قيمة في المجال غير قابلة للتجزئة بقدر ما يتعلق الأمر بالنموذج العلائقي. السِمة attribute: وحدة التخزين الأساسية في قواعد البيانات. العمود column: هو نفسه السمة attribute التي ذكرتها للتو. الدرجة degree: عدد السِمات في الجدول. المجال domain: هو المجموعات الأصلية للقيم الذَرية المستخدَمة لنمذجة البيانات، وهو مجموعة من القيم المقبولة التي يُسمح للعمود باحتوائها. الحقل field: يكافئ السمة attribute. الملف file: يكافئ العلاقة relation. السجل record: يحتوي على عدة حقول ذات صلة ببعضها البعض، ويكافئ السطر tuple. العلاقة relation: مجموعة فرعية من الناتج الديكارتي لقائمة من المجالات التي تتميز بالاسم، وهي المصطلح التقني لكل من الجدول table ، أو الملف file. الصف row: يكافئ السطر tuple. لغة الاستعلام المهيكلة structured query language -أي SQL اختصارًا-: هي لغة الوصول القياسية إلى قاعدة البيانات. الجدول table: يكافئ العلاقة relation. السطر tuple: مصطلح تقني مرادف للصف أو السجل. المصطلحات الأساسية table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } المصطلح الرسمي -أي حسب العالِم Codd- البديل الأول البديل الثاني العلاقة Relation الجدول Table الملف File السطر Tuple الصف Row السجل Record السمة Attribute العمود Column الحقل Field تمارين استخدم الجدول الموجود في الشكل الموضَّح أدناه للإجابة على الأسئلة الأربعة الأولى: حدِّد وصِف جميع المكونات في الجدول باستخدام المصطلحات الصحيحة. ما هو المجال المحتمل للحقل EmpJobCode؟ كم عدد السجلات المعروضة؟ كم عدد السمات المعروضة؟ اذكر خصائص الجدول. معرف سجل الموظف اسم الموظف تهيئة الموظف كنية الموظف رمز مهنة الموظف 123455 فريد .A عبد الله 12 123456 علا .D عادل 18 123457 فاتن .G علي 15 123458 كريم .X اسماعيل 18 جدول أسئلة التمرين ترجمة وبتصرف للفصل Chapter 7 The Relational Data Model من كتاب Database Design لصاحبته Adrienne Watt. اقرأ أيضًا دورة علوم الحاسوب المقال التالي: نموذج الكيان والعلاقة ER لتمثيل البيانات وتخزينها في قاعدة البيانات المقال السابق: نمذجة البيانات وأنواعها في عملية تصميم قواعد البيانات النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

سنتعرف في هذا المقال على أهم المصطلحات والمفاهيم الأساسية في قواعد البيانات بدءًا من التعرف على مفهوم قاعد البيانات بحد ذاته ثم التعرف إلى الصفات التي تتصف فيها قواعد البيانات وأخيرًا التعرف على مفهوم أنظمة إدارة قواعد البيانات وتصنيفاتها المندرجة ضمنها. ما هي قاعدة البيانات؟ تُعَدّ قاعدة البيانات database تجميعةً مشترَكةً من البيانات ذات الصلة، وتُستخدَم لدعم أنشطة منظَمة معينة، كما يمكن النظر إلى قاعدة البيانات على أساس مستودع للبيانات التي تُعرَّف مرةً واحدةً، ومن ثم يمكن الوصول إليها من مستخدِمين مختلفِين كما هو موضح في الشكل التالي. الشكل 1: قاعدة البيانات هي مستودع للبيانات خصائص قاعدة البيانات تملك قاعدة البيانات الخصائص التالية: تُمثِّل بعض جوانب العالم الحقيقي، أو تجميعةً من عناصر البيانات data elements -أو الحقائق facts- التي تُمثِّل معلومات مستقاة من الواقع. تُعَدّ قاعدة البيانات منطقيةً، ومتماسكةً، ومُتسقةً داخليًا. صُممَت قاعدة البيانات وبُنيت ومُلِئت بالبيانات لخدمة غرض معيّن. يُخزَّن كل عنصر بيانات في حقل field. تُكوِّن مجموعة الحقول جدولًا table، فمثلًا، يحتوي كل حقل في جدول الموظف على بيانات حول موظف فردي. يمكن أن تحتوي قاعدة البيانات على العديد من الجداول، فمثلًا، قد يحتوي نظام العضوية membership system على جدول عنوان، وجدول عضو فردي كما هو موضح في الشكل التالي. الشكل 2: نظام العضوية في Science World تتكون منظمة عالم العلوم مثلًا من عدة أعضاء، وهم: أفراد individuals، ومنازل جماعية group homes، وأعمال تجارية businesses، وشركات corporations، حيث يملكون عضوية نشطة في هذه المنظمة، كما يمكن شراء العضوية لمدة سنة أو سنتين، وبعد ذلك يمكن تجديدها لمدة سنة أو سنتين أيضًا. نلاحظ في الشكل السابق أنّ ميني ماوس Minnie Mouse قد جددت عضوية العائلة في منظمة عالم العلوم Science World، كما نلاحظ أنّ كل شخص يملك المعرِّف رقم 100755 يعيش في العنوان التالي: 8932 Rodent Lane. والأعضاء الأفراد كما يظهر في الشكل هم: Mickey Mouse وMinnie Mouse وحتى Moose Mouse كما هو ظاهر. أنواع مستخدمي قاعدة البيانات يندرج مستخدمو قواعد قواعد البيانات ضمن أحد التصنيفات التالية: المستخدمون النهائيون المستخدمون النهائيون End Users هم الأشخاص الذين تتطلب وظائفهم الوصول إلى قاعدة بيانات للاستعلام عن التقارير وتحديثها وإنشائها. مستخدم التطبيق مستخدم التطبيق Application user هو الشخص الذي يصل إلى برنامج تطبيقي موجود لأداء المهام اليومية. المستخدم الخبير المستخدمون الخبراء Sophisticated users هم المستخدمون الذين لديهم طريقتهم الخاصة في الوصول إلى قاعدة البيانات. هذا يعني أنهم لا يستخدمون البرنامج التطبيقي المتوفّر في النظام، فقد يحدّدون التطبيق الخاص بهم أو يصفِون حاجتهم مباشرةً باستخدام لغات استعلام. يحتفظ هؤلاء المستخدمون المتخصصون بقواعد بياناتهم الشخصية باستخدام حزم البرامج الجاهزة التي توفر أوامرًا قائمةً على القوائم menu driven commands وسهلة الاستخدام مثل برنامج MS Access. مبرمجو التطبيقات يطبّق هؤلاء المستخدمون - مبرمجو التطبيقات Application Programmers- برامجًا تطبيقية محددة للوصول إلى البيانات المخزَّنة، حيث يجب أن يكونوا على دراية بنظم إدارة قواعد البيانات لإنجاز مهاههم. مسؤولو قاعدة البيانات قد يكون مسؤول قاعدة البيانات Database Administrator -أو DBA اختصارًا- شخصًا أو مجموعة من الأشخاص في مؤسسةٍ، المسؤولين عن إعطاء التصريح بالوصول إلى قاعدة البيانات ومراقبة استخدامها وإدارة جميع الموارد لدعم استخدام نظام قاعدة البيانات بأكمله. نظام إدارة قواعد البيانات وتصنيفاتها يُعَدّ نظام إدارة قواعد البيانات database management system - أو DBMS اختصارًا- تجميعةً من البرامج التي تُمكِّن المستخدِمين من إنشاء قواعد البيانات databases، والحفاظ عليها، والتحكم في جميع عمليات الوصول إليها، كما يُعَدّ الهدف الأساسي لنظام إدارة قواعد البيانات هو توفير بيئة ملائمة وفعالة للمستخدِمين لاسترجاع المعلومات وتخزينها. يمكننا باستخدام نظام قواعد البيانات DBMS تمثيل النظام المصرفي التقليدي كما هو موضح في الشكل التالي، حيث يُستخدَم في هذا المثال المصرفي نظام إدارة قواعد البيانات من قِبَل قسم شؤون الموظفين، وقسم الحسابات، وقسم إدارة القروض، للوصول إلى قاعدة البيانات المشتركة للشركة. الشكل 3: نظام إدارة قواعد البيانات المصرفية يمكن تصنيف أنظمة إدارة قواعد البيانات بناءً على عدة معايير، مثل: نموذج البيانات data model، وأعداد المستخدمين user numbers، وتوزيع قاعدة البيانات database distribution؛ وفيما يلي بيان تفصيلي لكل من هذه المعايير. التصنيف على أساس نموذج البيانات نموذج البيانات الأكثر انتشارًا والمستخدم اليوم هو نموذج البيانات العلائقية relational data model، وذلك لأن جميع نظم إدارة قواعد البيانات، مثل: Oracle، وMS SQL Server، وDB2، وMySQL، تدعمه. لا تزال النماذج التقليدية traditional models الأخرى مثل نماذج البيانات الهرمية hierarchical data models، ونماذج بيانات الشبكة network data models مستخدَمةً في الصناعة بصورة أساسية على منصات الحواسيب المركزية، ولكن نجدها محصورةً في استخدامات بسيطة بسبب تعقيدها، ويشار إليها على أنها نماذج تقليدية traditional models لأنها سبقت النموذج العلائقي relational model. ظهرت في السنوات الأخيرة نماذج البيانات كائنية التوجه object-oriented data models، وهي نظام لإدارة قاعدة بيانات، حيث تُمثَّل فيه المعلومات في شكل كائنات كما هو مستخدم في البرمجة كائنية التوجه. تختلف قواعد البيانات كائنية التوجه عن قواعد البيانات العلائقية relational databases، والتي تعتمد على الجدول أي تُعَدّ جدولية التوجه table-oriented، كما تجمع أنظمة إدارة قواعد البيانات كائنية التوجه Object-oriented database management systems -وتختصر إلى OODBMS- بين إمكانيات قاعدة البيانات وإمكانيات لغات البرمجة كائنية التوجه. ما زال انتشار قواعد البيانات كائنية التوجه ضعيف موازنة بقواعد البيانات العلائقية وذلك يرجع إلى عدم تعرُّف المستخدِمِين عليها بعد، ويوجد بعض الأمثلة على نظم إدارة قواعد البيانات كائنية التوجه، وهي: O2. ObjectStore. Jasmine. التصنيف على أساس أعداد المستخدمين يمكن تصنيف نظم إدارة قواعد البيانات بناءً على عدد المستخدِمين القادر على دعمهم، حيث من الممكن دعم مستخدِم وحيد ويسمى نظام قواعد بيانات أحادي المستخدِم ingle-user database system، أو دعم العديد من المستخدِمين بصورة متزامنة ويسمى نظام قواعد بيانات متعدد المستخدِمين multiuser database system. التصنيف على أساس توزيع قاعدة البيانات توجد أربعة أنظمة توزيع رئيسية لأنظمة قواعد البيانات، ويمكن استخدامها لتصنيف قواعد البيانات حسب ماهو موضح أدناه. الأنظمة المركزية Centralized systems يُخزَّن نظام إدارة قواعد البيانات DBMS وقاعدة البيانات database عند استخدام الأنظمة المركزية لقواعد البيانات centralized database system في موقع واحد تستخدمه أنظمةً أخرى عديدةً كما هو موضَّح في الشكل التالي الشكل 4: مثال على نظام قاعدة بيانات مركزية. استخدَمت العديد من المكتبات الكندية في أوائل الثمانينيات نظام GEAC 8000 لتحويل دليل أو فهرس البطاقات اليدوية إلى أنظمة فهرس مركزية يمكن قراءتها آليًا، حيث يحتوي كل فهرس على حقل باركود مشابه لذلك الموجود في منتجات المتاجر. نظام قاعدة البيانات الموزعة يوزَّع نظام إدارة قواعد البيانات DBMS وقاعدة البيانات database في نظام قاعدة البيانات الموزعة distributed database system من مواقع مختلفة متصلة بشبكة حاسوب، كما هو موضَّح في الشكل التالي. الشكل 5: مثال على نظام قاعدة بيانات موزعة. أنظمة قواعد البيانات الموزعة المتجانسة تستخدِم أنظمة قواعد البيانات الموزعة المتجانسة Homogeneous distributed database systems برنامج إدارة قواعد البيانات نفسه من مواقع متعددة، كما يمكن تبادل البيانات بين هذه المواقع المختلفة بسهولة، فمثلًا، تستخدِم أنظمة معلومات المكتبات library information systems من البائع نفسه مثل نظام Geac Computer Corporation لإدارة قواعد البيانات نفسه، والذي يسمح بتبادل البيانات بسهولة بين مواقع مكتبة Geac المختلفة. أنظمة قواعد البيانات الموزعة غير المتجانسة تستخدِم مواقع مختلفة برنامج إدارة قواعد بيانات مختلف في نظام قاعدة البيانات الموزعة غير المتجانسة heterogeneous distributed database system، ولكن هناك برامج مشتركة إضافية تدعم تبادل البيانات بين هذه المواقع، فمثلًا، تستخدِم أنظمة قاعدة بيانات المكتبات المختلفة تنسيق الفهرسة المقروءة آليًا machine-readable cataloguing -أي MARC اختصارًا- نفسه لدعم تبادل بيانات تسجيلات المكتبة. مصطلحات أساسية عناصر البيانات data elements: حقائق تُمثِّل معلومات مستقاة من الواقع. قاعدة البيانات database: تجميعة مشتركة من البيانات ذات الصلة، وتُستخدَم لدعم أنشطة منظمة معيَّنة. نظام إدارة قواعد البيانات database management system - أو DBMS اختصارًا-: تجميعة من البرامج التي تُمكِّن المستخدِمين من إنشاء قواعد البيانات، والحفاظ عليها، والتحكم في جميع عمليات الوصول إليها. الجدول table: مجموعة من الحقول fields. نظام قاعدة البيانات المركزي centralized database system: يُخزَّن نظام إدارة قواعد البيانات DBMS وقاعدة البيانات database عند استخدام الأنظمة المركزية لقواعد البيانات centralized database system في موقع واحد تستخدمه أنظمةً أخرى عديدةً نظام قاعدة البيانات الموزعة distributed database system: يوزَّع نظام إدارة قواعد البيانات DBMS وقاعدة البيانات database في نظام قاعدة البيانات الموزعة distributed database system من مواقع مختلفة متصلة بشبكة حاسوب. نظام قاعدة البيانات الموزعة غير المتجانسة heterogeneous distributed database system: تستخدِم مواقع مختلفة برنامج إدارة قواعد بيانات مختلف، ولكن هناك برامج مشتركة إضافية تدعم تبادل البيانات بين هذه المواقع. نظام قاعدة البيانات الموزعة المتجانسة homogeneous distributed database systems: تستخدِم برنامج إدارة قواعد البيانات نفسه في مواقع متعددة. نظام قاعدة بيانات متعدد المستخدِمين multiuser database system: هو نظام إدارة قاعدة بيانات يدعم عدة مستخدِمين بصورة متزامنة. نموذج البيانات كائنية التوجه object-oriented data model: نظام لإدارة قواعد البيانات، حيث تُمثَّل المعلومات فيه على صورة كائنات كما هو مستخدم في البرمجة كائنية التوجه. نظام قاعدة بيانات أحادي المستخِدم single-user database system: نظام إدارة قاعدة بيانات يدعم مستخدم واحد فقط في كل مرة. النماذج التقليدية traditional models: هي نماذج البيانات التي سبقت النموذج العلائقي relational model. مبرمج التطبيق application programmer: هو المستخدم الذي يطبّق برامجًا تطبيقية محددة للوصول إلى البيانات المخزَّنة. مستخدم التطبيق application user: يمكنه الوصول إلى برنامجٍ تطبيقي موجود لأداء المهام اليومية. مسؤول قاعدة البيانات database administrator أو اختصارًا DBA: هو الشخص المسؤول عن إعطاء التصريح بالوصول إلى قاعدة البيانات ومراقبة استخدامها وإدارة جميع الموارد لدعم استخدام نظام قاعدة البيانات بأكمله. المستخدم النهائي end user: هو الشخص الذي تتطلب وظيفته الوصول إلى قاعدة بيانات للاستعلام عن التقارير وتحديثها وإنشائها. المستخدم الخبير sophisticated user: هو الشخص الذي يستخدم طرقًا أخرى مختلفة عن البرنامج التطبيقي للوصول إلى قاعدة البيانات. تمارين ما هو نظام إدارة قواعد البيانات؟ ما هي خصائص نظام إدارة قواعد البيانات؟ اذكر ثلاثة أمثلة لقواعد بيانات مستقاة من الواقع مثل تحتوي المكتبة على قاعدة بيانات للكتب. اذكر ثلاثة أمثلة لقواعد البيانات العلائقية المستخدَمة والأكثر شيوعًا. ما الفرق بين أنظمة قواعد البيانات المركزية والموزعة؟ ما الفرق بين أنظمة قواعد البيانات الموزعة المتجانسة وأنظمة قواعد البيانات الموزعة غير المتجانسة؟ ترجمة وبتصرف للفصل Chapter 2 Fundamental Concepts، والفصل Chapter 6 Classification of Database Management Systems، والفصل Database Users من كتاب Database Design لصاحبته Adrienne Watt. اقرأ أيضًا المقال السابق: تحليل نظام الملفات لإدارة البيانات وتخزينها واختلافه عن نظام قاعدة البيانات المقال التالي: خصائص قواعد البيانات والمزايا التي تقدمها النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

تعني إدارة المعلومات معالجة المعلومات وتنظيمها لتوظيفها بما يخدمنا بطريقة نستفيد منها في تنفيذ مهامنا، كما منع نظام إدارة قواعد البيانات DBMS وجود الفوضى العرضية التي كانت تحدث للبيانات التي نجمعها ونضيفها إلى قواعد البيانات، حيث أصبح الوصول إليها أكثر سهولةً وتكاملًا مع بقية عملنا، كما تسمح لنا إدارة المعلومات باستخدام قاعدة بيانات أن نصبح مستخدِمين استراتيجيين للبيانات التي نملكها. غالبًا ما نحتاج إلى الوصول إلى البيانات وإعادة فرزها لأغراض مختلفة تشمل ما يلي: إنشاء القوائم البريدية. كتابة التقارير الإدارية. توليد قوائم بالقصص الإخبارية المختارة. تحديد احتياجات العملاء المختلفة. تملك قواعد البيانات قدرةً كبيرةً على معالجة البيانات، مما يسمح لها بإجراء العمليات التالية: الفرز Sort. المطابقة Match. ربط البيانات Link. تجميع البيانات Aggregate. تخطي الحقول Skip fields. إجراء العمليات الحسابية Calculate. ترتيب Arrange البيانات. تتعدد استخدامات قواعد البيانات وترتبط بمجالات كثيرة، لذلك نجد من الممكن ربط قاعدة البيانات بكل من الأنظمة التالية: موقع إلكتروني لتسجيل المستخدِمين. تطبيقات الهواتف مثل تطبيق لتخزين بيانات عملاء منظَمة تقدم خدمات اجتماعية. نظام السجلات الطبية لمنشأة رعاية صحية. دفتر العناوين address book الشخصية في عميل البريد الإلكتروني. تجميعة من الملفات النصية. نظام حجوزات الطيران. خصائص قواعد البيانات يملك نظام قواعد البيانات عددًا من الخصائص والفوائد التي تميزه عن النظام القائم على الملفات file-based system، حيث سنذكر منها ما يلي: طبيعة الوصف الذاتي لنظام قاعدة البيانات يُشار إلى نظام قاعدة البيانات على أنه ذاتي الوصف، وذلك بسبب احتوائه على قاعدة البيانات تفسها، وعلى بيانات وصفية metadata بحيث تُحدِّد البيانات وتصفها، والعلاقات بين الجداول في قاعدة البيانات، حيث تُستخدَم هذه المعلومات بواسطة برامج أنظمة إدارة قواعد البيانات DBMS، أو مستخدمي قاعدة البيانات، ويُعَدّ هذا الفصل بين البيانات ومعلوماتها أحد الفروقات الرئيسية التي تميز نظام قواعد البيانات عن النظام اتقليدي القائم على الملفات، والذي يكون فيه تعريف البيانات جزءًا من برامج التطبيقات. العزل بين البرنامج والبيانات تُحدَّد هيكلة ملفات البيانات في النظام القائم على الملفات داخل برامج التطبيق، لذلك إذا أراد المستخدم تعديل هيكلة ملف معيَّن، فعليه تعديل جميع البرامج التي تتصل بهذا الملف. من الناحية الأخرى، تُخزِّن قواعد البيانات هيكلة البيانات في دليل catalogue النظام وليس في البرامج، لذلك كل ما هو مطلوب لتعديل هيكل ملف معيَّن هو تعديل واحد فقط، ويسمى هذا بالعزل بين البرامج والبيانات أو الاستقلالية بين البرامج والبيانات program-data independence أيضًا. دعم عدة واجهات عرض للبيانات تدعم قاعدة البيانات استخدام عدة واجهات لعرض البيانات، حيث تُعَدّ واجهة العرض view مجموعةً فرعيةً من قاعدة البيانات database، والتي تُعرَّف وتُخصَّص لخدمة أغراض فئة محددَّة من مستخدِمي النظام، وقد يملك مستخدِمين متعددين واجهات مختلفةً في النظام، حيث تحتوي كل منها على البيانات التي تهم مستخدِم أو مجموعة من المستخدِمين دون غيرهم. مشاركة البيانات والنظام متعدد المستخدمين صمِّمت أنظمة قواعد البيانات لعدة مستخدِمين، حيث تتيح لعدد من المستخدِمين الوصول إلى قاعدة البيانات نفسها في الوقت نفسه، وذلك عن طريق استخدام استراتيجيات معيَّنة تُسمى استراتيجيات التحكم المتزامنة concurrency control strategies، حيث تضمن هذه الاستراتيجيات صِحة البيانات التي يتم الوصول إليها، كما تُحافظ على سلامة البيانات أيضًا. يُعَدّ تصميم أنظمة قواعد البيانات الحديثة المتعددة المستخدِمين تحسنًا كبيرًا مقارنةً بتلك التي كانت في الماضي، والتي تقتصر على شخص واحد في كل مرة. التحكم في تكرار البيانات تُخزَّن البيانات في نظام قواعد البيانات - وفي الحالة المثالية - دون أي تكرار redundancy، أي أنّ كل عنصر بيانات موجود في مكان واحد فقط في قاعدة البيانات. ولكن يحدث في بعض الحالات تكرار للبيانات بغرض تحسين أداء النظام في أجزاء معينة، كما يُتحكَّم في هذا التكرار عن طريق برمجة التطبيقات، وذلك بالمحافظة على الحد الأدنى منه عند تصميم قاعدة البيانات. تشارك البيانات يملك تكامل جميع بيانات المؤسسة داخل نظام قاعدة البيانات العديد من المزايا، حيث يسمح بمشاركة البيانات بين الموظفين وغيرهم من الذين يمكنهم الوصول إلى النظام، وكذلك يسمح للمستخدمين بتوليد المزيد من المعلومات من كمية معيَّنة من البيانات أكثر مما سيكون ممكنًا بدون التكامل. تطبيق قيود صارمة لضمان سلامة البيانات وصحتها توفر أنظمة إدارة قواعد البيانات القدرة على تحديد وفرض قيود معينة على البيانات لضمان إدخال معلومات صحيحة من قِبَل المستخدِمين، والمحافظة على سلامة البيانات، إذ تُعَدّ قيود قاعدة البيانات database constraint قواعدًا لفرض ما يمكن إدخاله أو تعديله في جدول معيَّن، مثل: الرمز البريدي باستخدام تنسيق معيَّن، أو إضافة مدينة حقيقية في حقل المدينة. هناك أنواع عديدة من القيود في قواعد البيانات، مثل: نوع البيانات Data type مثل تحدد نوع البيانات المسموح بها في الحقل مثل الأعداد فقط، أو تفرد البيانات Data uniqueness مثل المفتاح الأساسي والذي يضمن عدم إدخال أي تكرارات، كما يمكن أن تكون القيود بسيطةً -بحيث تفرض على الحقل مباشرةً-، أو معقدةً -أي برمجية-. تقييد الوصول الغير مصرح به لا يحظى جميع مستخدمي نظام قاعدة البيانات بصلاحيات الوصول نفسها، فمثلًا، قد يكون لدى أحد المستخدِمين صلاحيات القراءة فقط -أي القدرة على قراءة الملفات دون إجراء أيّ تعديلات عليها-، بينما يكون لدى مستخدِم آخر صلاحيات القراءة والكتابة - أي القدرة على قراءة الملفات والتعديل عليها-، ولهذا السبب يجب على نظام إدارة قاعدة البيانات توفير نظام أمان فرعي لإنشاء أنواع مختلفة من حسابات المستخدِمين، والتحكم فيها، وتقييد الوصول الغير مصرح به. استقلالية البيانات يوجد ميزة أخرى لنظام إدارة قواعد البيانات، وهي الطريقة التي يسمح بها باستقلالية البيانات، بمعنى آخر، يتم فصل أوصاف بيانات النظام أو البيانات التي تصف البيانات -أي البيانات الوصفية metadata- عن برامج التطبيق، وهذا ممكن لأن نظام إدارة قاعدة البيانات يعالج التغييرات في هيكل البيانات، ولا تُضمَّن هذه التغيرات في البرنامج نفسه. معالجة المعاملات يجب أن يتضمن نظام إدارة قواعد البيانات أنظمةً فرعيةً للتحكم في التزامن، حيث تضمن هذه الخاصية بقاء البيانات متسقةً وصالحةً أثناء معالجة المعامَلات حتى وإن قام العديد من المستخدِمين بتحديث المعلومات نفسها. تقديم عدة واجهات عرض للبيانات يسمح نظام إدارة قواعد البيانات DBMS للعديد من المستخدمين بالوصول إلى قواعد البيانات بصورة فردية أو بصورة متزامنة، كما ليس من المهم أن يعرف المستخدِمون كيف وأين تُخزَّن البيانات التي يصلون إليها. النسخ الاحتياطي واسترجاع البيانات التالفة أو المفقودة يُعَدّ النسخ الاحتياطي والاسترجاع طريقتَين لحماية البيانات من الضياع، حيث يوفر نظام قواعد البيانات عمليةً منفصلةً عن عملية النسخ الاحتياطي للشبكة لنسخ البيانات احتياطيًا واستعادتها، ويُعَدّ النسخ الاحتياطي لقاعدة البيانات الطريقة الوحيدة لاستعادتها في حال فشل محرك الأقراص الثابتة وتعذَّر الوصول إلى قاعدة البيانات المخزنة عليه. إذا فشل نظام الحاسوب في منتصف عملية تحديث البيانات، فيكون النظام الفرعي للاسترجاع هو المسؤول عن التأكد من استعادة قاعدة البيانات إلى حالتها الأصلية، ويكون ما سبق فائدتَين إضافيتَين لنظام إدارة البيانات. مصطلحات أساسية استراتيجيات التحكم المتزامنة concurrency control strategies: تسمح للعديد من المستخدِمين بالوصول إلى عنصر البيانات نفسه في الوقت نفسه. نوع البيانات data type: يُحدِّد نوع البيانات المسموح بها في حقل معيَّن مثل يمكن أن يقبل الحقل أعدادًا فقط. تفرد البيانات data uniqueness: يضمن عدم إدخال بيانات مكرَّرة. قيود قاعدة البيانات database constraint: يُحدِّد القيد ما يُسمح بإدخاله أو تعديله في جدول معيَّن. البيانات الوصفية metadata: تُحدِّد وتصف البيانات والعلاقات بين الجداول في قاعدة البيانات. صلاحيات القراءة والكتابة read and write privileges: القدرة على قراءة الملفات وتعديلها. صلاحيات القراءة فقط read-only access: القدرة على قراءة الملفات فقط دون تعديلها. الوصف الذاتي self-describing: يُشار إلى نظام قاعدة البيانات على أنه ذاتي الوصف، لأنه يحتوي على قاعدة البيانات نفسها، بالإضافة إلى البيانات الوصفية التي تُحدِّد وتصف البيانات والعلاقات بين الجداول في قاعدة البيانات. واجهة العرض: مجموعة فرعية من قاعدة البيانات. تمارين ماذا يُميِّز نظام إدارة قاعدة البيانات DBMSعن النظام القائم على الملفات file-based system؟ ما هي استقلالية البيانات؟ وما أهميتها؟ ما هو الغرض من إدارة المعلومات؟ ناقش استخدام قواعد البيانات في بيئة العمل. ما هي البيانات الوصفية؟ ترجمة وبتصرف للفصل Chapter 3 Characteristics and Benefits of a Database من كتاب Database Design لصاحبته Adrienne Watt. اقرأ أيضًا المقال التالي: نمذجة البيانات وأنواعها في عملية تصميم قواعد البيانات المقال السابق: المفاهيم الأساسية في قواعد البيانات وتصميمها تحليل نظام الملفات لإدارة البيانات وتخزينها واختلافه عن نظام قاعدة البيانات النسخة العربية الكاملة لكتاب تصميم قواعد البيانات دليلك الشامل إلى أنواع البيانات

يتمثل أحد الجوانب الأساسية لهندسة البرمجيات في تقسيم عملية التطوير إلى سلسلة من المراحل أو الخطوات، حيث تركِّز كل مرحلة منها على جانب واحد من جوانب التطوير. يشار أحيانًا إلى مجموعة هذه الخطوات بدورة حياة تطوير البرمجيات software development life cycle -أو SDLC اختصارًا-، حيث ينتقل المنتج البرمجي عبر مراحل دورة الحياة هذه -في بعض الأحيان بصورة متكررة أثناء ضبطه أو إعادة تطويره- حتى يتوقف استخدامه في النهاية، كما يمكن التحقق من كل مرحلة في دورة الحياة للتأكد من صحتها قبل الانتقال إلى المرحلة التالية في الحالة المثالية. دورة حياة تطوير البرمجيات: نموذج الشلال Waterfall لنبدأ بإلقاء نظرة عامة على نموذج الشلال waterfall model الذي هو أحد نماذج تمثيل دورة حياة عملية تطوير البرمجيات Software Development Life Cycle كما ستجده في معظم كتب هندسة البرمجيات. يوضح هذا الشكل الشلالي الموجود في الشكل الآتي نموذج شلال عام يمكن تطبيقه على أية عملية تطوير لنظام حاسوبي، حيث يُظهِر هذا النموذج العملية على أساس تسلسل صارم من الخطوات بأن يكون خرج خطوة واحدة دخلًا للخطوة التالية، كما يجب إكمال كل خطوة قبل الانتقال إلى الخطوة التالية. يمكننا استخدام عملية نموذج الشلال على أساس وسيلة لتحديد المهام المطلوبة مع دخل وخرج كل نشاط activity. المهم هنا هو مجالات الأنشطة التي يمكن تلخيصها على النحو التالي: تتضمن مرحلة إنشاء المتطلبات Establishing requirements التشاور والاتفاق مع أصحاب المصلحة حول ما يريدونه من النظام، ويُعبَّر عنها بما يسمَّى وثيقة المتطلبات statement of requirements. تبدأ مرحلة التحليل Analysis بالنظر في وثيقة المتطلبات وتنتهي من خلال إنتاج مواصفات النظام system specification، حيث تُعَدّ المواصفات تمثيلًا رسميًا لما يجب على النظام فعله، ويُعبَّر عنها بعبارات مستقلة عن كيفية تطبيقها. تبدأ مرحلة التصميم Design بمواصفات النظام وينتج عنها وثائق التصميم، كما تقدِّم هذه المرحلة وصفًا تفصيليًا لكيفية بناء النظام. مرحلة التطبيق Implementation هي بناء نظام حاسوبي وفقًا لوثيقة تصميم معينة مع مراعاة البيئة التي سيعمل فيها النظام، مثل العتاد، والبرمجيات المتاحة للتطوير؛ كما قد تُنفَّذ مرحلة التطبيق على مراحل باستخدام نظام أولي يمكن التحقق من صحته واختباره قبل إصدار النظام النهائي للاستخدام. توازن مرحلة الاختبار Testing النظام المُطبَّق مع وثائق التصميم ومواصفات المتطلبات، وتنتج هذه المرحلة تقرير قبول، أو قائمةً بالأخطاء والزلات البرمجية bugs التي تتطلب مراجعة عمليات التحليل، والتصميم، والتطبيق لتصحيحها، أي تُعَدّ مرحلة الاختبار عادةً المَهمة التي تؤدي إلى تكرار نموذج الشلال خلال دورة الحياة. تتضمن مرحلة الصيانة Maintenance التعامل مع تغيرات المتطلبات، أو بيئة التطبيق، أو إصلاح الزلات البرمجية، أو نقل النظام إلى بيئات جديدة مثل ترحيل نظام من حاسوب مستقل إلى محطة عمل يونكس أو بيئة متصلة بالشبكة، كما سيعاد النظر في دورة حياة الشلال بصورة متكررة بسبب احتواء مرحلة الصيانة على تحليل التغيرات المطلوبة، وتصميم حل، وتطبيقه، واختباره على مدى حياة نظام برمجي جرت صيانته. دورة حياة قاعدة البيانات Database Life Cycle يمكننا استخدام دورة الشلال مثل أساس لنموذج تطوير قاعدة البيانات الذي يتضمن ثلاثة افتراضات، هي: يمكننا فصل تطوير قاعدة البيانات عن عمليات المستخدم التي تستخدم قاعدة البيانات، أي تحديد وإنشاء تخطيط schema لتعريف البيانات في قاعدة البيانات. يمكننا استخدام معمارية التخطيطات الثلاثة three-schema architecture مثل أساس لتمييز الأنشطة المرتبطة بالتخطيط. يمكننا تمثيل القيود constraints لفرض دلالات semantics البيانات مرةً واحدةً في قاعدة البيانات عوضًا عن فرضها على كل عملية مستخدِم تستخدِم البيانات. يمكننا باستخدام هذه الافتراضات والشكل السابق رؤية أنّ هذا المخطط يمثِّل نموذجًا للأنشطة وخرجها لتطوير قاعدة البيانات، فهذا المخطط ليس قابلًا للتطبيق على النهج العلائقي فقط وإنما يُطبَّق على أية صنف class من نظم إدارة قواعد البيانات DBMS أيضًا. يُعَدّ تطوير تطبيقات قواعد البيانات عمليةً للحصول على متطلبات العالم الحقيقي real-world، وتحليل المتطلبات، وتصميم البيانات ووظائف النظام، ثم تطبيق العمليات في النظام. جمع المتطلبات Requirements Gathering تُعَدّ مرحلة جمع المتطلبات requirements gathering الخطوة الأولى في نموذج الشلال، ويجب على مصممي قاعدة البيانات خلال هذه الخطوة إجراء مقابلات مع العملاء -أي مستخدمي قاعدة البيانات- لفهم النظام المقترح والحصول على البيانات والمتطلبات الوظيفية، وتوثيقها، كما تكون نتيجة هذه الخطوة وثيقةً تتضمن المتطلبات التفصيلية التي قدمها المستخدِمون. تتضمن مرحلة إنشاء المتطلبات Establishing requirements التشاور والاتفاق بين جميع المستخدِمين بشأن البيانات الثابتة persistent data التي يرغبون في تخزينها مع الاتفاق على معنى عناصر البيانات وتفسيرها، كما يلعب مسؤول البيانات دورًا رئيسيًا في هذه العملية لأنه يستعرِض القضايا التجارية، والقانونية، والأخلاقية داخل المؤسسة التي تؤثِّر على متطلبات البيانات. تُستخدَم وثيقة متطلبات البيانات data requirements document لتأكيد فهم المتطلبات مع المستخدِمين، فلا ينبغي أن تكون رسميةً أو مشفرةً بمستوى عالٍ لضمان سهولة فهمها. يجب أن تقدِّم هذه الوثيقة ملخصًا موجزًا لمتطلبات جميع المستخدِمين -أي ليس مجرد مجموعة من الأفراد فقط-، وذلك لأنّ الهدف هو تطوير قاعدة بيانات مشتركة واحدة. يجب ألا تصِف المتطلبات كيفية معالجة البيانات، بل تصف عناصر البيانات، والسِمات attributes التي تمتلكها، والقيود المطبَّقة، والعلاقات التي تربط بين عناصر البيانات. التحليل Analysis تبدأ مرحلة تحليل البيانات Data analysis بوثيقة متطلبات البيانات، ثم ينتج عنها نموذج بيانات مفاهيمي conceptual data model. الهدف من التحليل هو الحصول على وصف تفصيلي للبيانات التي ستناسب متطلبات المستخدِم، بحيث يجري التعامل مع خصائص البيانات ذات المستوى العالي والمنخفض واستخدامها. تتضمن هذه الخصائص المجال المحتمل من القيم التي يمكن السماح بها للسمات، مثل: رمز مقررات الطالب student course code، وعنوان المقرر course title، ونقاط الائتمان credit points في قاعدة بيانات المدرسة على سبيل المثال. يوفِّر نموذج البيانات المفاهيمي تمثيلًا رسميًا مشتركًا لما يجري توصيله بين العملاء والمطورين أثناء تطوير قاعدة البيانات، فهذا النموذج يركز على البيانات في قاعدة البيانات، بغض النظر عن الاستخدام النهائي لتلك البيانات في عمليات المستخدِم، أو تطبيق البيانات في بيئات حاسوبية محدَّدة، لذلك يهتم نموذج البيانات المفاهيمي بمعنى البيانات وبنيتها، وليس بالتفاصيل التي تؤثر على كيفية تطبيقها. إذًا يُعَدّ نموذج البيانات المفاهيمي تمثيلًا رسميًا للبيانات التي يجب أن تحتويها قاعدة البيانات، والقيود التي يجب على البيانات تلبيتها، كما يجب التعبير عن ذلك بمصطلحات مستقلة عن كيفية تنفيذ النموذج، لذلك يركِّز التحليل على الأسئلة التي تحتوي عبارات مثل عبارة "ما هو المطلوب؟" وليس على الأسئلة التي تحتوي عبارات مثل عبارة "كيف يتحقق ذلك؟". التصميم المنطقي Logical Design تبدأ مرحلة تصميم قاعدة البيانات بنموذج بيانات مفاهيمي وينتج عنها مواصفات التخطيط المنطقي logical schema الذي سيحدِّد نوع نظام قاعدة البيانات المطلوب -أي نوع شبكي، أو علائقي، أو كائني التوجه-. لا يزال التمثيل العلائقي relational representation مستقلًا عن أي نظام إدارة قواعد البيانات DBMS، فهو نموذج بيانات مفاهيمي آخر. يمكننا استخدام التمثيل العلائقي لنموذج البيانات المفاهيمي على أساس دخلٍ لعملية التصميم المنطقي، وخرج هذه المرحلة هو مواصفات علائقية مفصَّلة أي تخطيط منطقي لجميع الجداول والقيود اللازمة لتلبية وصف البيانات في نموذج البيانات المفاهيمي. تُختار الجداول الأكثر ملاءمة أثناء نشاط التصميم لتمثيل البيانات في قاعدة بيانات، ولكن يجب أخذ هذه الاختيارات في الحسبان معايير التصميم المختلفة بما في ذلك على سبيل المثال مرونة التغيير، والتحكم في التضاعف أو الاستنساخ duplication، وأفضل طريقة لتمثيل القيود. تحدِّد الجداول المحدَّدة بالتخطيط المنطقي البيانات المخزَّنة وكيفية معالجتها في قاعدة البيانات. يتجه مصممو قواعد البيانات الملمّون بقواعد البيانات العلائقية ولغة الاستعلامات الهيكلية SQL للذهاب مباشرةً إلى مرحلة التطبيق بعد إنتاج نموذج البيانات المفاهيمي، لكن لا يؤدي مثل هذا التحول المباشر للتمثيل العلائقي إلى جداول SQL بالضرورة إلى قاعدة بيانات تحتوي على جميع الخصائص المرغوبة، مثل: الكمال completeness، والسلامة integrity، والمرونة flexibility، والكفاءة efficiency، وقابلية الاستخدام usability. يُعَدّ نموذج البيانات المفاهيمي الجيد خطوةً أولى أساسية نحو قاعدة بيانات لها هذه الخصائص، لكن لا يعني هذا أنّ التحول المباشر إلى جداول SQL ينتج قاعدة بيانات جيدة تلقائيًا. ستمثل هذه الخطوة الأولى بدقة الجداول والقيود اللازمة لتلبية وصف نموذج البيانات المفاهيمي، وبالتالي ستلبي متطلبات الكمال والسلامة، ولكنها قد تكون غير مرنة، أو قد تقدِّم قابلية استخدام ضعيفة، يُثنَى flexed التصميم الأول بعد ذلك لتحسين جودة تصميم قاعدة البيانات، ويهدف مصطلح الثني Flexing إلى أخذ الأفكار المتزامنة من شيء مثني لغرض مختلف وتشذيب جوانب من هذا الشيء- أي الوصول إلى الغاية نفسها بطريقة وفكرة أخرى تحقق المقصود-. يلخص الشكل الآتي الخطوات التكرارية الموجودة في تصميم قاعدة البيانات بناءً على النظرة العامة المقدَّمة، كما يكون الغرض الرئيسي من هذا الشكل هو التمييز بين الهدف العام للجداول التي يجب استخدامها عن التعريف المفصَّل للأجزاء المكوِّنة لكل جدول، حيث تُدرَس هذه الجداول واحدًا تلو الآخر رغم أنها ليست مستقِلةً عن بعضها البعض، كما سيؤدي كل تكرار يتضمّن مراجعةً للجداول إلى تصميم جديد، ويشار إلى هذه التصاميم الجديدة معًا باسم تصاميم القطع الثاني second-cut designs حتى لو تكررت العملية لأكثر من حلقةٍ واحدة. أولًا، ليس من الضروري تلبية جميع متطلبات المستخدم التي يمثلها نموذج بيانات مفاهيمي معين بواسطة قاعدة بيانات واحدة، كما يوجد أسباب مختلفة لتطوير أكثر من قاعدة بيانات، مثل: الحاجة إلى عملية مستقِلة في مواقع مختلفة، أو التحكم الإداري ببيانات قواعد البيانات، لكن إذا احتوت مجموعة قواعد البيانات على بيانات مضاعَفة وكان المستخدِمون بحاجة للوصول إلى البيانات في أكثر من قاعدة بيانات، فهناك أسباب محتملة لتلبِّي قاعدة بيانات واحدة متطلبات متعددة، وإلا فيجب فحص المشاكل المتعلقة بمضاعَفة البيانات وتوزيعها. ثانيًا، أحد الافتراضات حول تطوير قاعدة البيانات هو أنه يمكننا فصل تطوير قاعدة البيانات عن تطوير عمليات المستخدم التي تستفيد منها، ويستند ذلك إلى توقّع تحديد جميع البيانات المطلوبة بواسطة عمليات المستخدِم المحدَّدة حاليًا، وإمكانية الوصول إليها بمجرد تطبيق قاعدة البيانات، لكننا نطلب أيضًا المرونة للسماح بتلبية تغيرات المتطلبات المستقبلية، كما يمكن التنبؤ بالطلبات الشائعة التي ستُقدَّم إلى قاعدة البيانات عند تطوير قاعدة بيانات لبعض التطبيقات، وبالتالي يمكننا تحسين تصميمنا للطلبات الأكثر شيوعًا. ثالثًا، تعتمد العديد من جوانب تصميم قاعدة البيانات وتطبيقها في المستوى التفصيلي على نظام إدارة قاعدة البيانات DBMS المستخدَم، فإذا كان اختيار نظام إدارة قواعد البيانات ثابتًا أو أُجرِي قبل مهمة التصميم، فيمكن استخدام هذا الاختيار لتحديد معايير التصميم بدلًا من الانتظار حتى مرحلة التطبيق، أي يمكن دمج قرارات التصميم لنظام إدارة قاعدة البيانات DBMS معين عوضًا عن إنتاج تصميم عام، ثم تكييفه مع نظام إدارة قاعدة البيانات DBMS أثناء التطبيق. ليس غريبًا العثور على تصميم مفرد لا يمكنه تلبية جميع خصائص قاعدة البيانات الجيدة في الوقت نفسه، لذلك من المهم أن يعطي المصمم الأولوية لهذه الخصائص، ويكون ذلك عادةً باستخدام معلومات من مواصفات المتطلبات، مثل: تحديد ما إذا كانت السلامة أهم من الكفاءة، وما إذا كانت قابلية الاستخدام أهم من المرونة في تطوير معيَّن. ستحدِّد تعليمات لغة تعريف البيانات data definition language -أو DDL اختصارًا- الخاصة بلغة SQL التخطيط المنطقي في نهاية مرحلة التصميم، حيث تصف لغة DDL قاعدة البيانات التي يجب تطبيقها لتلبية متطلبات المستخدِم. التطبيق Implementation تتضمن مرحلة التنفيذ أو التطبيق Implementation بناء قاعدة بيانات وفقًا لمواصفات التخطيط المنطقي، والذي سيتضمّن مواصفات تخطيط التخزين storage schema المناسب، وفرض الأمان، والتخطيط الخارجي، وما إلى ذلك، كما يتأثر التطبيق بشدة باختيار نظم إدارة قواعد البيانات المتاحة، وأدوات قواعد البيانات، وبيئة التشغيل. هناك مهام إضافية تتجاوز مجرد إنشاء تخطيط قاعدة بيانات database schema وتطبيق القيود، إذ يجب إدخال البيانات في الجداول، ومعالجة القضايا المتعلقة بالمستخدِمين وعمليات المستخدِم، كما يجب دعم الأنشطة الإدارية المرتبطة بالجوانب الأوسع لإدارة بيانات الشركة. نريد معالجة أكبر عدد ممكن من هذه القضايا الموضَّحة أدناه داخل نظام إدارة قواعد البيانات تماشيًا مع نهج نظم إدارة قواعد البيانات. يتطلب تطبيق التخطيط المنطقي عمليًا في نظام إدارة قواعد البيانات DBMS معرفةً مفصلةً للغاية بالميزات والفوائد المحددة التي يجب تقديمها من قِبَل نظام إدارة قواعد البيانات. ستشمل المرحلة الأولى من التطبيق انسجامَ متطلبات التصميم مع أفضل أدوات التطبيق المتاحة ثم استخدام تلك الأدوات للتطبيق، وذلك مثاليًا وتماشيًا مع الممارسة الجيدة لهندسة البرمجيات، كما قد يتضمن ذلك في قواعد البيانات على اختيار منتجات البائعِين ذات متغيرات من نظام إدارة قواعد البيانات DBMS ولغة SQL الأكثر ملاءمة لقاعدة البيانات التي نحتاج إلى تطبيقها، لكننا لا نعيش في عالم مثالي، كما ستُتخَذ في كثير من الأحيان قرارات اختيار العتاد والقرارات المتعلقة بنظام إدارة قواعد البيانات DBMS قبل النظر في تصميم قاعدة البيانات بوقت طويل، وبالتالي، يمكن أن يتضمن التطبيق ثنيًا إضافيًا للتصميم للتغلب على محدوديات البرمجيات أو العتاد. تحقيق التصميم Realizing the Design نحتاج إلى إنشاء قاعدة بياناتنا بعد إنشاء التصميم المنطقي وفقًا للتعريفات التي أنتجناها، كما يُحتمَل أن يتضمن التطبيق مع نظام إدارة قواعد البيانات DBMS العلائقي استخدام لغة SQL لإنشاء جداول وقيود تلبي وصف التخطيط المنطقي واختيار تخطيط التخزين المناسب -إذا كان نظام إدارة قواعد البيانات DBMS يسمح بهذا المستوى من التحكم-. تتمثل إحدى طرق تحقيق ذلك في كتابة تعليمات لغة SQL DDL المناسبة في ملف يمكن لنظام إدارة قواعد البيانات DBMS تنفيذه، بحيث يكون هناك سجل مستقل أو ملف نصي من تعليمات لغة SQL التي تعرِّف قاعدة البيانات؛ أما الطريقة الأخرى فهي العمل تفاعليًا باستخدام أداة قاعدة بيانات مثل الأداتين SQL Server Management Studio أو Microsoft Access. مهما كانت الآلية المستخدَمة لتطبيق التخطيط المنطقي، فالنتيجة هي أن قاعدة البيانات -مع الجداول والقيود- معرَّفة ولكنها لن تحتوي على بيانات لعمليات المستخدِم. ملء قاعدة البيانات Populating the Database يوجد طريقتان لملء الجداول بعد إنشاء قاعدة البيانات؛ إما من بيانات موجودة أو من خلال استخدام تطبيقات المستخدِم المطوَّرة لقاعدة البيانات. قد تكون هناك بيانات موجودة من قاعدة بيانات أخرى أو من ملفات بيانات وذلك بالنسبة لبعض الجداول، فمثلًا، نتوقع عند إنشاء قاعدة بيانات لمستشفى وجود بعض السجلات بالفعل لجميع الموظفين الذين يجب تضمينهم في قاعدة البيانات، كما يمكن أيضًا إحضار البيانات من وكالة خارجية مثل قوائم العناوين التي تُجلَب بصورة متكررة من شركات خارجية، أو يمكن إنتاجها أثناء مهمة إدخال بيانات كبيرة -أي يمكن إجراء تحويل السجلات اليدوية المطبوعة إلى ملفات حاسوبية بواسطة وكالة إدخال بيانات-، ويُعَدّ استخدام وسائل الاستيراد والتصدير الموجودة في نظام إدارة قواعد البيانات DBMS أبسط طريقة لملء قاعدة البيانات في مثل هذه الحالات. تتوفر عادةً وسائل لاستيراد وتصدير البيانات بتنسيقات قياسية مختلفة، وتُعرَف هذه الوظائف أيضًا في بعض الأنظمة باسم تحميل loading البيانات وتفريغها unloading، كما يتيح الاستيراد إمكانية نسخ ملف البيانات مباشرةً إلى جدول. إذا جرى الاحتفاظ بالبيانات بتنسيق ملف غير مناسب لاستخدام عملية الاستيراد، فيجب إعداد برنامج تطبيقي يقرأ البيانات القديمة، ويحوّلها حسب الضرورة، ثم يدخلها في قاعدة البيانات باستخدام شيفرة لغة SQL الذي أُنتجِت خصيصًا من أجل هذا الهدف. يُسمّى نقل كميات كبيرة من البيانات الموجودة إلى قاعدة بيانات بالتحميل المجمَّع bulk load، وقد يتضمن التحميل المجمَّع للبيانات كميات كبيرةً جدًا من البيانات المُحمَّلة أي تحميل جدول في نفس الوقت، لذلك قد تجد وسائل في نظام إدارة قواعد البيانات DBMS لتأجيل فحص قيد حتى نهاية التحميل المجمَّع. إرشادات لتطوير مخطط ER ملاحظة: ستساعد هذه الإرشادات العامة في تطوير أساس قوي لتصميم قاعدة البيانات الفعلية أي النموذج المنطقي: وثّق جميع الكيانات المكتشَفة خلال مرحلة جمع المعلومات. وثّق جميع السمات التي تنتمي إلى كل كيان، وحدّد المفاتيح المرشَّحة candidate keys، والمفاتيح الرئيسية primary keys، كما تأكد من اعتمادية جميع السمات التي ليست مفاتيحًا non-key attributes لكل كيان بصورة كاملة على المفتاح الرئيسي. طوِّر مخطط ER الأولي وراجعه مع الأشخاص المناسبين، وتذكَّر أن هذه عملية تكرارية. أنشِئ كيانات -أي جداول- جديدة للسمات متعددة القيم والمجموعات المكرَّرة، ثم ضمِّن هذه الكيانات- أي الجداول- الجديدة في مخطط ER، وراجع ذلك مع الأشخاص المناسبين. تحقَّق من نمذجة الكيان العلائقي ER عن طريق تطبيق عملية التوحيد normalizing على الجداول. ترجمة -وبتصرّف- للمقال Database Development Process لصاحبته Adrienne Watt. اقرأ أيضًا المقال التالي: نظرة سريعة على لغة الاستعلامات الهيكلية SQL المقال السابق: فهم عملية التوحيد Normalization المستخدمة عند تصميم قاعدة البيانات الاعتماديات الوظيفية المستخدمة في تصميم قواعد البيانات قواعد السلامة وقيودها لضمان سلامة البيانات في قواعد البيانات الاستعلامات الفرعية والإجراءات في SQL النسحة الكاملة من كتاب الدليل العملي إلى قواعد بيانات PostgreSQL

تُعَدّ نمذجة البيانات Data Modelling الخطوة الأولى والأساسية عند تصميم أي قاعدة بيانات، كما تُعَدّ هذه الخطوة مرحلة تصميم مجردة وعالية المستوى، ويشار إليها باسم التصميم المفاهيمي conceptual design أيضًا. الهدف من هذه المرحلة هو إعطاء وصف واضح لكل من: البيانات الواردة في قاعدة البيانات، مثل الكيانات: طلاب، ومحاضرون، ودورات، ومواد. العلاقات بين عناصر البيانات data items، مثل: يشرف محاضرون على طلاب، ويدرِّس محاضرون دورات. القيود المفروضة على البيانات، مثل: يتكون رقم الطالب من ثمانية خانات بالضبط، وتحتوي المادة الدراسية على أربع أو ست درجات فقط. يُعبَّر في الخطوة الثانية عن عناصر البيانات، والعلاقات، والقيود، باستخدام المفاهيم التي يوفرها نموذج البيانات عالي المستوى، ونظرًا لعدم وجود تفاصيل التنفيذ implementation details في هذه المفاهيم، فتكون نتيجة عملية نمذجة البيانات تمثيلُا شبه رسمي لهيكل قاعدة البيانات، وهذه النتيجة سهلة الفهم، لذلك تُستخدَم على أساس مرجع للتأكد من تلبية جميع متطلبات المستخدم. الخطوة الثالثة هي تصميم قاعدة البيانات، حيث يكون لدينا خلال هذه الخطوة خطوتَين فرعيتَين، وهما: التصميم المنطقي لقاعدة البيانات database logical design، والتي تحدِّد قاعدة البيانات في نموذج بيانات لنظام إدارة قواعد بيانات DBMS معيَّن، والأخرى هي التصميم المادي لقاعدة البيانات database physical design، والتي تحدِّد بنية تخزين قاعدة البيانات الداخلية، أو طريقة تنظيم الملفات، أو تقنيات الفهرسة، وتتمثّّل هاتان الخطوتان الفرعيتان في التنفيذ الفعلي لقاعدة البيانات database implementation، وخطوات أساسية لبناء العمليات وواجهات المستخدم. تُمثَّل البيانات في مراحل تصميم قاعدة البيانات باستخدام نموذج بيانات معيَّن، حيث يكون نموذج البيانات data model تجميعةً من المفاهيم، أو الصيغ التي تصف البيانات، والعلاقات بينها، ودلالاتها semantics، والقيود المفروضة عليها، كما تتضمن معظم نماذج البيانات أيضًا مجموعةً من العمليات الأساسية لمعالجة البيانات في قاعدة البيانات database. دورة علوم الحاسوب دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب اشترك الآن أنواع نماذج البيانات تُعَدّ نماذج البيانات وسيلةً لتوصيف كيفية عرض البيانات وتخزينها، وسنناقش أنواعها بالتفصيل في هذا القسم. نماذج البيانات المفاهيمية عالية المستوى توفر نماذج البيانات المفاهيمية عالية المستوى High-level Conceptual Data Models مفهومًا لعرض البيانات بأساليب قريبة من الأسلوب الذي يدرك به الإنسان البيانات، والمثال النموذجي هو نموذج الكيان والعلاقة Entity Relationship الذي يستخدِم المفاهيم الرئيسية، مثل: الكيانات، والسمات، والعلاقات، حيث يمثل الكيان كائنًا واقعيًا، مثل: موظف، أو مشروع، كما يحتوي على سمات تمثل خصائص، مثل: اسم الموظف، وعنوانه، وتاريخ ميلاده، وتُمثِّل العلاقات كيفية ارتباط الكيانات مع بعضها البعض، فمثلًا، توجد علاقة بين الموظف وكل مشروع عندما يعمل الموظف في العديد من المشاريع. نماذج البيانات المنطقية القائمة على السجلات توفر نماذج البيانات المنطقية القائمة على السجلات Record-based Logical Data Models مفاهيمًا يمكن للمستخدِمين فهمها واستيعابها كما أنها ليست بعيدةً جدًا عن الطريقة التي تُخزَّن بها البيانات في الحاسوب. هناك ثلاثة نماذج معروفة من هذا النوع، وهي: نماذج البيانات العلائقية relational data models، ونماذج البيانات الشبكية network data models، ونماذج البيانات الهرمية hierarchical data models. يُمثِّل النموذج العلائقي relational model البيانات على أساس علاقات أو جداول، فمثلًا، تضم العضوية في منظَمة عالم العلوم Science World العديد من الأعضاء كما في الشكل 2 في مقال المفاهيم الأساسية في قواعد البيانات وقواعد تصميمها، ويُعَدّ كل من مُعرِّف العضوية، وتاريخ انتهاء الصلاحية، ومعلومات العنوان، حقولًا في العضوية، ويكون الأعضاء أفرادًا، مثل: Mickey، وMinnie، وMighty، وDoor، وTom، وKing، وMan، وMoose، كما يكون كل سجل بمثابة نسخة عن جدول العضوية. يُمثِّل النموذج الشبكي network model البيانات على أساس أنواع سجلات، كما يُمثِّل أيضًا هذا النموذج نوعًا محددًا من علاقة واحد إلى متعدد one to many يسمى نوع المجموعة set type، كما هو موضح في الشكل التالي. مخطط النموذج الشبكي يُمثِّل النموذج الهرمي hierarchical model البيانات على أساس هيكل شجرة هرمية، حيث يُمثِّل كل فرع من فروع التسلسل الهرمي عددًا من السجلات ذات الصلة، ويوضح الشكل التالي هذا المخطط في صيغة النموذج الهرمي. مخطط النموذج الهرمي مدى تجريد البيانات سنلقي في هذا القسم نظرةً على عملية تصميم قاعدة البيانات من حيث تخصيصها لأداء وظائف معينة، فكما يبدأ أيّ تصميم بمستوى عالٍ من التجريد ثم يتنقل تدريجيًا إلى التفاصيل الصغيرة، كذلك هو الحال عند تصميم قاعدة البيانات، فمثلًا، تبدأ عند بناء منزل بعدد غرف النوم والحمامات فيه، سواءً كان على مستوى واحد أو مستويات عدة، وتكون الخطوة التالية بتعيين مهندس معماري لتصميم المنزل تصميمًا أكثر تنظيمًا ودقةً، حيث يصبح هذا المستوى أكثر تفصيلًا فيما يتعلق بأحجام الغرف، وكيف سيتم توصيل المنزل بالأسلاك، وأين ستُوضع تركيبات السباكة، وما إلى ذلك، والخطوة الأخيرة هي تعيين مقاول لبناء المنزل. يتبع تصميم قاعدة البيانات يتبع طريقةً شبيهةً بهذه، حيث يبدأ بتحديد المستخدِمين لقواعد العمل، ثم ينشئ مصممو ومحللو قاعدة البيانات تصميم قاعدة البيانات، وبعدها ينفّذ مسؤول قاعدة البيانات التصميم باستخدام نظام إدارة قواعد البيانات DBMS. تلخِّص الأقسام الفرعية التالية النماذج بترتيب تنازلي لمستوى التجريد. النماذج الخارجية تمثل واجهة عرض قاعدة البيانات للمستخدم. تحتوي على عدد من واجهات عرض خارجية مختلفة. ترتبط ارتباطًا وثيقًا بالعالم الحقيقي الذي يراه المستخدم. النماذج المفاهيمية Conceptual models توفِّر إمكانيات مرنة لهيكلة البيانات data-structuring. تقدِّم واجهة عرض مشتركة community view، وهي الهيكل المنطقي لقاعدة البيانات بأكملها. تحتوي على البيانات المخزنة في قاعدة البيانات. تظهر العلاقات بين البيانات بما في ذلك: القيود. المعلومات الدلالية مثل قواعد العمل. معلومات الأمان والسلامة. تُعَدّ قاعدة البيانات مجموعةً من الكيانات -أي الكائنات objects- من أنواع مختلفة. تمثِّل الأساس لتحديد وإعطاء وصف عالي المستوى لكائنات البيانات الرئيسية، كما أنها تتجاهل التفاصيل. تحدِّد هل قاعدة البيانات مستقلة بغض النظر عن قاعدة البيانات التي تستخدمها. النماذج الداخلية Internal models النماذج الثلاثة الأكثر شهرة من هذا النوع، هي: نموذج البيانات العلائقية relational data model، ونموذج البيانات الشبكية network data model، ونموذج البيانات الهرمي hierarchical data model، ومن السمات الرئيسية لنماذج البيانات الداخلية: تُعَدّ قاعدة البيانات مثل تجميعة من السجلات ذات الحجم الثابت. تُعَدّ أقرب إلى المستوى المادي أو بنية الملف. تُمثِّل قاعدة البيانات كما يراها نظام إدارة قواعد البيانات DBMS. تطالب المصمم بمطابقة خصائص وقيود النموذج المفاهيمي مع تلك الخاصة بنموذج التنفيذ المختار. يتضمن مقابلة الكيانات في النموذج المفاهيمي مع الجداول في النموذج العلائقي. النماذج المادية Physical models هي التمثيل المادي أو الفيزيائي لقاعدة البيانات. تملك أدنى مستوى من التجريد. تحدِّد كيفية تخزين البيانات في قاعدة البيانات، وترتبط مباشرةً بكل من: أداء قاعدة البيانات في وقت التشغيل Run-time performance. تحسين التخزين وضغط الملفات. تنظيم الملفات وطرق الوصول إليها. تشفير البيانات. تُحدِّد ما إذا كان نظام التشغيل operating system -أو OS اختصارًا- يدير المستوى المادي. تُقدِّم مفاهيم تصف تفاصيل كيفية تخزين البيانات في ذاكرة الحاسوب. طبقات تجريد البيانات يمكنك أن ترى في العرض التصويري كيف تعمل النماذج المختلفة معًا، لذلك دعنا نلقي نظرةً على هذا من أعلى مستوى، وهو النموذج الخارجي. النموذج الخارجي external model هو كيفية عرض المستخدِم النهائي للبيانات، فعادةً ما تكون قاعدة البيانات نظام مؤسسي يخدم احتياجات أقسام متعددة، كما لا يهتم أي قسم برؤية بيانات الأقسام الأخرى، فمثلًا، لا يهتم قسم الموارد البشرية human resources - أو HR اختصارًا- بعرض بيانات قسم المبيعات sales. وعليه تختلف طريقة عرض البيانات من مستخدم لآخر. يتطلب النموذج الخارجي أن يقسِّم المصمم مجموعة المتطلبات والقيود إلى وحدات وظيفية يمكن فحصها في إطار نماذجها الخارجية مثل تقسيم المؤسسة إلى قسم الموارد البشرية وقسم المبيعات. تحتاج بوصفك مصمم بيانات إلى فهم جميع البيانات حتى تتمكن من إنشاء قاعدة بيانات على مستوى المؤسسة بناءً على احتياجات الأقسام المختلفة، لذلك يكون إنشاء النموذج المفاهيمي conceptual model هو الخطوة الأولى. يكون النموذج المفاهيمي في هذه المرحلة مستقلًا عن كل من البرامج software والعتاد hardware، ولا يعتمد على برنامج نظام إدارة قواعد البيانات المُستخدم في تنفيذ النموذج، ولا على العتاد المستخدَم في ذلك، كما لا تؤثر التغييرات في العتاد أو برنامج نظام إدارة قواعد البيانات على تصميم قاعدة البيانات على المستوى المفاهيمي. بمجرد تحديد برنامج نظام إدارة البيانات المُراد استخدامه، يمكنك بعد ذلك تنفيذه، وهو ما يُسمى بالنموذج الداخلي internal model، حيث تقوم هنا بإنشاء جميع الجداول، والقيود، والمفاتيح، والقواعد، وما إلى ذلك، وغالبًا ما يشار إلى هذا باسم التصميم المنطقي logical design. النموذج المادي ببساطة هو الطريقة التي تُخزَّن فيها البيانات على القرص، وتختلف طريقة تخزين البيانات باختلاف نوع قاعدة البيانات المستخدَمة. مستويات تجريد البيانات تخطيطات قاعدة البيانات Schemas التخطيط schema هو وصف عام وشامل لقاعدة البيانات، وعادةً ما يتم تمثيله بواسطة مخطط الكيان والعلاقة entity relationship diagram، وتختصر إلى ERD. غالبًا ما تكون هناك العديد من التخطيطات الفرعية subschemas التي تمثل النماذج الخارجية المختلفة وبالتالي تعرض الواجهات الخارجية للبيانات. فيما يلي قائمة بالعناصر التي يجب مراعاتها أثناء عملية تصميم قواعد البيانات: تخطيطات خارجية External schemas: من الممكن أن توجد عدة تخطيطات خارجية في قاعدة البيانات الواحدة. تخطيطات فرعية متعددة Multiple subschemas: تعرض واجهات خارجية متعددة للبيانات. تخطيط مفاهيمي Conceptual schema: يوجد تخطيط مفاهيمي واحد فقط لقاعدة البيانات الواحدة، يتضمن هذا التخطيط عناصر البيانات، والعلاقات، والقيود، وتمثَّل بواسطة مخطط علاقة الكيان والعلاقة ERD. تخطيط مادي Physical schema: يوجد تخطيط مادي واحد فقط لقاعدة بيانات واحدة. استقلالية البيانات المنطقية والمادية يشير مفهوم استقلالية البيانات Data independence إلى حصانة تطبيقات المستخدِم من التغييرات التي تطرأ على تعريفات البيانات وتنظيمها. تكشف عمليات تجريد البيانات عن العناصر المهمة أو العناصر ذات الصلة بالمستخدِم، وتكون التعقيد مخفيًا عن مستخدم قاعدة البيانات. تشكل استقلالية البيانات واستقلالية التشغيل معًا ميزة تجريد البيانات، وهناك نوعان من استقلالية البيانات، هما: استقلالية البيانات منطقيًا، واستقلالية البيانات ماديًا. استقلالية البيانات منطقيًا يُعَدّ التخطيط المنطقي logical schema تصميمًا مفاهيميًا conceptual design لقاعدة البيانات، والذي يتم على الورق أو على لوح أبيض مثل الرسومات المعمارية للبيوت. تسمى القدرة على تغيير التخطيط المنطقي دون تغيير التخطيط الخارجي external schema، أو واجهة المستخدم باستقلالية البيانات منطقيًا logical data independence، فمثلًا، يجب أن تكون إضافة أو إزالة كيانات جديدة، أو سمات، أو علاقات، إلى التخطيط المفاهيمي conceptual schema ممكنةً دون الحاجة إلى تغيير التخطيطات الخارجية الحالية، أو إعادة كتابة برامج التطبيق؛ بمعنى آخر يجب ألَّا تؤثر التغييرات على التخطيط المنطقي على وظيفة التطبيق -أي طرق العرض الخارجية- مثل التعديلات على بنية قاعدة البيانات مثل إضافة عمود أو جداول جديد. استقلالية البيانات ماديا تشير استقلالية البيانات ماديًا Physical data independence إلى حصانة النموذج الداخلي ضد التغييرات في النموذج المادي، إذ يبقى التخطيط المنطقي دون تغيير على الرغم من إجراء تغييرات على تنظيم الملفات، أو هياكل التخزين، أو أجهزة التخزين، أو استراتيجية الفهرسة. تعمل مرحلة استقلالية البيانات ماديًا على إخفاء تفاصيل بنية التخزين من تطبيقات المستخدم، حيث لا ينبغي أن تتعامل التطبيقات مع هذه القضايا لعدم وجود فرق في العمليات الجارية على البيانات. مصطلحات أساسية النموذج الهرمي hierarchical model: يُمثِّل البيانات في هيكل الشجرة الهرمية. النسخة instance: سجل داخل جدول معين في قاعدة البيانات. النموذج الشبكي network model: يمثل البيانات على أساس أنواع سجلات. العلاقة relation: مصطلح آخر لوصف الجداول. النموذج العلائقي relational model: يُمثِّل البيانات على أساس علاقات أو جداول. نوع المجموعة set type: نوع محدَّد من علاقة واحد إلى متعدد one to many. النموذج المفاهيمي conceptual model: هو الهيكل المنطقي لقاعدة البيانات. التخطيط المفاهيمي conceptual schema: مصطلح مرادف للتخطيط المنطقي logical schema. استقلالية البيانات data independence: هي حصانة تطبيقات المستخدِم من التغييرات التي تطرأ على تعريفات البيانات وتنظيمها. نموذج البيانات data model: تجميعة من المفاهيم أو الصيغ المستخدمة لوصف البيانات، والعلاقات بينها، ودلالاتها، والقيود المفروضة عليها. نمذجة البيانات data modelling: هي الخطوة الأولى في عملية تصميم قاعدة البيانات. التصميم المنطقي لقاعدة البيانات database logical design: يُحدِّد قاعدة بيانات في نموذج البيانات الخاص بنظام إدارة قاعدة بيانات محدَّد. التصميم المادي لقاعدة البيانات database physical design: يُحدِّد بنية تخزين قاعدة البيانات الداخلية، أو تنظيم الملفات، أو تقنيات الفهرسة. مخطط الكيان والعلاقة entity relationship diagram -أو ERD اختصارًا-: يُعَدّ نموذج بيانات، حيث يصف قاعدة البيانات، ويعرض الجداول، والسمات، والعلاقات. النموذج الخارجي external model: يمثِّل واجهة عرض المستخدِم لقاعدة البيانات. التخطيط الخارجي external schema: يمثِّل واجهة المستخدِم. النموذج الداخلي internal model: هو تمثيل قاعدة البيانات في الصورة التي يراها أو يتعامل معها نظام إدارة قواعد البيانات. استقلالية البيانات منطقيًا logical data independence: هو القدرة على تغيير التخطيط المنطقي للبيانات دون تغيير التخطيط الخارجي. التصميم المنطقي logical design: هو الخطوة التي تُنشأ فيها الجداول، والقيود، والمفاتيح، والقواعد، …إلخ. التخطيط المنطقي logical schema: هو تصميم مفاهيمي لقاعدة البيانات، حيث يتم على الورق، أو الألواح البيضاء مثل الرسومات المعمارية لمنزل. نظام التشغيل operating system - أو OS اختصارًا-: هو المسؤول عن إدارة المستوى المادي للنموذج المادي. استقلالية البيانات ماديًا physical data independence: هو حصانة النموذج الداخلي ضد التغييرات في النموذج المادي. النموذج المادي physical model: هو التمثيل المادي لقاعدة البيانات. التخطيط schema: هو وصف عام وشامل لقاعدة البيانات. التمارين ما هو نموذج البيانات؟ ما هو نموذج البيانات المفاهيمي عالي المستوى؟ عرف المصطلحات التالية: الكيان. السمة. العلاقة. اذكر وصِف بإيجاز النماذج الشائعة لنماذج البيانات المنطقية القائمة على السجلات. صِف الغرض من التصميم المفاهيمي. ما هو الاختلاف بين التصميم المفاهيمي والتصميم المنطقي؟ عرف النماذج التالية: ما هو النموذج الخارجي؟ ما هو النموذج المفاهيمي؟ ما هو النموذج الداخلي؟ ما هو النموذج المادي؟ ما هو النموذج الذي يتعامل معه مسؤول قاعدة البيانات؟ ما هو النموذج الذي يتعامل معه المستخدِم النهائي لقاعدة البيانات؟ ما هو الاستقلال البيانات ماديًا؟ ما هو استقلال البيانات منطقيًا؟ ترجمة وبتصرف للفصل Chapter 4 Types of Data Models والفصل Chapter 5 Data Modelling من كتاب Database Design لصاحبه Adrienne Watt. اقرأ أيضًا المقال التالي: مفاهيم نموذج البيانات العلائقية RDM الأساسية المهمة في تصميم قواعد البيانات المقال السابق: خصائص قواعد البيانات والمزايا التي تقدمها تحليل نظام الملفات لإدارة البيانات وتخزينها واختلافه عن نظام قاعدة البيانات النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

سنوضح في هذا المقال مثالًا عمليًا عن خطوات تصميم قاعدة بيانات لجامعة، كما سنضع أمثلةً عمليةً تشرح كيفية إنشاء مخططات ERD، إذ يشرح المثال الأول مثالًا عن مخطط ERD لشركة تصنيع، ويشرح المثال الثاني مثالًا عن مخطط ERD لوكيل سيارات، كما يقدم خطوات لحل تمرين باستخدام لغة SQL وعباراتها. مثال عملي عن تصميم قاعدة بيانات لجامعة فيما يلي متطلبات البيانات لمنتج من أجل دعم تسجيل وتقديم المساعدة لطلاب جامعة تعليم إلكتروني وهمية. تحتاج جامعة تعليم إلكتروني إلى الاحتفاظ بتفاصيل طلابها وموظفيها، والمقررات التي تقدمها وأداء الطلاب الذين يدرسون فيها. تدار الجامعة في أربع مناطق جغرافية (إنجلترا واسكتلندا وويلز وأيرلندا الشمالية). يجب تسجيل معلومات كل طالب في البداية عند التسجيل، ويتضمن ذلك رقم تعريف الطالب الصادر في الوقت والاسم وسنة التسجيل والمنطقة الموجود فيها الطالب. ليس الطالب ملزمًا بالتسجيل في أي مقرر عند التسجيل، فيمكنه التسجيل في مقررٍ ما في وقتٍ لاحق. يجب أن تتضمن المعلومات المسجلة لكل عضو في القسم التعليمي وقسم الإرشاد رقمَ الموظف والاسم والمنطقة التي يوجد بها. قد يعمل كل موظف كمرشد counselor لطالبٍ أو أكثر، وقد يعمل كمدرس tutor لطالبٍ أو أكثر في مقررٍ أو أكثر. قد لا يُخصَّص لأحد الموظفين أي طالب كمدرس أو كمرشد في أي وقتٍ معين. يملك كل طالب مرشدًا واحدًا يخصَّص له عند التسجيل، ويقدّم الدعم للطالب طوال حياته الجامعية. يُخصَّص للطالب مدرسٌ منفصلٌ لكل مقرر سجّل فيه الطالب. يُسمَح للموظف فقط العمل كمرشد أو كمدرّس لطالبٍ مقيم في نفس منطقته. يجب أن يكون لكل مقرر متوفر للدراسة رمز مقرر وعنوان وقيمة من حيث نقاط الائتمان، حيث يكون للمقرر إما 15 نقطة أو 30 نقطة. قد يكون للمقرر حصة quota لعدد الطلاب المسجلين فيه في أي عرض. لا يحتاج المقرر إلى أي طالب مسجل فيه (مثل المقرر الذي كُتِب للتو ثم عُرِض للدراسة). يُقيَّد الطلاب في عدد المقررات التي يمكنهم التسجيل فيها في نفس الوقت، فقد لا يأخذون المقررات في نفس الوقت إذا تجاوز مجموع النقاط المدمَجة للمقررات المسجلين فيها 180 نقطة. قد يكون للمقرر ذي الـ 15 نقطة ما يصل إلى ثلاث وظائف لكل عرض، ويكون للمقرر ذي الـ 30 نقطة ما يصل إلى خمس وظائف لكل عرض. تُسجَّل درجة الوظيفة في أي مقرر كعلامةٍ من 100. قاعدة بيانات الجامعة التالية نموذج بيانات محتمل يصِف مجموعة المتطلبات المذكورة أعلاه. يحتوي النموذج على عدة أجزاء، بدءًا من مخطط ERD ويليه وصفٌ لأنواع الكيانات والقيود والافتراضات. عملية التصميم الخطوة الأولى هي تحديد النوى والتي هي عادة أسماء: الموظفين Staff والمقرر Course والطالب Student والوظيفة Assignment. الخطوة التالية هي توثيق جميع السمات attributes لكل كيان entity. هذا هو المكان الذي تحتاج فيه إلى التأكد من توحيد normalized جميع الجداول توحيدًا صحيحًا. أنشئ مخطط ERD الأولي وراجعه مع المستخدمين. أجرِ تغييرات إن لزم الأمر بعد مراجعة مخطط ERD. تحقق من نموذج ER مع المستخدمين لوضع اللمسات الأخيرة على التصميم. يوضّح الشكل التالي مخطط ERD للجامعة الذي يمثّل نموذج بيانات لنظام سجلات الطلاب والموظفين الكيان Entity Student (StudentID, Name, Registered, Region, StaffNo). Staff (StaffNo, Name, Region): يحتوي هذا الجدول على مدرّسين وغيرهم من الموظفين. Course (CourseCode, Title, Credit, Quota, StaffNo). Enrollment (StudentlD, CourseCode, DateEnrolled, FinalGrade). Assignment (StudentID, CourseCode, AssignmentNo, Grade). القيود Constraints يجوز لأحد الموظفين أن يدرّس أو يرشد الطلاب المتواجدين في نفس منطقتهم فقط. قد لا يسجّل الطلاب في مقررات لا تزيد قيمتها عن أكثر من 180 نقطة في نفس الوقت. للسمة Credit (ضمن المقرر Course) قيمة هي 15 أو 30 نقطة. قد يكون للمقرر الذي له 30 نقطة ما يصل إلى خمس وظائف، بينما يكون للمقرر الذي له 15 نقطة ما يصل إلى ثلاث وظائف. للسمة Grade (ضمن الوظيفة Assignment) قيمة هي علامة من 100. الافتراضات Assumptions يستطيع الطالب أن يسجّل مرة واحدة للمقرر حيث تُسجَّل عمليات التسجيل الحالية فقط. تُقدَّم الوظيفة مرة واحدة فقط. العلاقات Relationships (تشمل عددية العلاقة cardinality) لاحظ في الشكل الآتي أن سجل الطالب مرتبط مع مقررات مُسجَّلة بحد أدنى مقرر واحد إلى مقررات متعددة كحد أقصى. يجب أن يكون لكل تسجيل enrollment طالب صالح. يوضح الشكل الآتي ارتباط سجل الموظفين (المدرّس هنا) بحد أدنى 0 طالب وبطلاب متعددين كحد أقصى. قد يكون لسجل الطالب مدرسٌ tutor أو قد يكون بدون مدرس. يرتبط سجل الموظفين Staff (المدرّس هنا) بعدد لا يقل عن 0 مقرّر كحد أدنى وبمقررات متعددة كحد أقصى. قد يكون المقرر course مرتبطًا بمدرّس instructor أو غير مرتبط بمدرس. يجب توفير المقرر (في عملية التسجيل enrollment) مرة واحدة على الأقل ومرات متعددة كحد أقصى، كما يجب أن يحتوي جدول التسجيل Enrollment على مقرر واحد صالح على الأقل إلى مقررات متعددة كحد أقصى. يمكن أن تحتوي عملية التسجيل على 0 مهمة كحد أدنى أو مهام متعددة كحد أقصى. يجب أن ترتبط الوظيفة assignment بتسجيل واحد على الأقل وبتسجيلٍ واحد كحد أقصى. أمثلة عملية عن إنشاء مخططات ERD سنعرض في هذه الجزئية مثالين عن عملية إنشاء مخططات ERD. التمرين الأول: شركة تصنيع Manufacturer تنتج شركة تصنيع منتجات، وتخزّن معلومات المنتج التالية: اسم المنتج product name ومعرّف المنتج product name والكمية المتوفرة quantity. تتكون هذه المنتجات من مكونات متعددة، ويوفّرموِّردٌ أو أكثر كلَّ مكون. تُحفَظ معلومات المكوّن التالية: معرّف المكون component ID واسمه name ووصف عنه description الموّردون suppliers الذين يوفرونه والمنتجات products التي تستخدم هذا المكوّن (استخدم الشكل الآتي لحل هذا التمرين). أنشِئ مخطط ERD لإظهار كيفية تتبع هذه المعلومات. اعرض أسماء الكيانات entity names والمفاتيح الرئيسية primary keys وسمات attributes كل كيان والعلاقات بين الكيانات وعددية العلاقة cardinality. الافتراضات Assumptions يمكن وجود الموّرد دون أن يوفّر مكونات. ليس واجبًا أن يرتبط مكونٌ بموّرد. ليس واجبًا أن يرتبط مكوّنٌ مع منتج، فليست جميع المكونات مستخدمَةً في المنتجات. لا يمكن أن يوجد منتج بدون مكونات. جواب مخطط ERD Component(CompID, CompName, Description) PK=CompID. Product(ProdID, ProdName, QtyOnHand) PK=ProdID. Supplier(SuppID, SuppName) PK = SuppID. CompSupp(CompID, SuppID) PK = CompID, SuppID. Build(CompID, ProdID, QtyOfComp) PK= CompID, ProdID. التمرين الثاني: وكيل سيارات Car Dealership أنشئ مخطط ERD لوكيل سيارات، حيث يبيع هذا الوكيل كلًا من السيارات الجديدة والمستعملة، ويشغّل قسمًا للخدمات. ابنِ تصميمك على قواعد الأعمال التالية: قد يبيع مندوب المبيعات salesperson سيارات متعددة، ولكن تُباع كل سيارة بواسطة مندوب مبيعات واحد فقط. يمكن أن يشتري العميل customer سيارات متعددة، ولكن تُشترى كل سيارة بواسطة عميل واحد فقط. يكتب مندوب المبيعات فاتورةً invoice واحدة لكل سيارة يبيعها. يحصل العميل على فاتورة لكل سيارة يشتريها. قد يأتي العميل من أجل الحصول على خدماتٍ لسيارته فقط، وهذا يعني أن العميل لا يحتاج إلى شراء سيارة لكي يُصنَّف كعميل. إذا جلب العميل سيارةً أو أكثر لإصلاحها أو للحصول على خدمة، فستُكتَب تذكرة خدمة service ticket لكل سيارة. يحتفظ وكيل السيارات بتاريخ خدمة لكل من السيارات المُخدَّمة، ويُشار إلى سجلات الخدمة عن طريق رقم السيارة التسلسلي. يمكن أن يعمل على السيارة التي تُجلَب للحصول على خدمة ميكانيكيون متعددون، وقد يعمل كل ميكانيكي على سيارات متعددة. قد تحتاج السيارة التي تحصل على خدمة إلى قِطع أو قد لا تحتاج إلى قطع (مثل عملية ضبط المفحّم carburetor أو تنظيف فوهة حاقن الوقود التي لا تتطلب توفير قِطعٍ جديدة). جواب مخطط ERD حل تمرين باستخدام لغة SQL نزّل السكريبت التالي: OrdersAndData.sql. الجزء الأول: استخدم لغة DDL استخدم السكريبت orderData.sql الذي ينشئ جداولًا ويضيف بيانات مخطط ERD للطلبات والبيانات في الشكل السابق. أنشئ قاعدة بيانات تسمّى Orders، وعدّل السكريبت لدمج المفتاح الرئيسي PK والسلامة المرجعية referential integrity. استخدم عبارات CREATE TABLE مع التعديلات بما في ذلك القيود الموجودة في الخطوة 3. أضف القيود التالية: tblCustomers table: Country (Canada قيمته الافتراضية هي) tblOrderDetails: Quantity – > 0 tblShippers: CompanyName (يجب أن يكون فريدًا) tblOrders: ShippedDate (order date يجب أن يكون أكبر تاريخ الطلب) CREATE DATABASE Orders Go Use Orders Go Use Orders Go CREATE TABLE [dbo].[tblCustomers] [CustomerID] nvarchar(5) NOT NULL, [CompanyName] nvarchar(40) NOT NULL, [ContactName] nvarchar(30) NULL, [ContactTitle] nvarchar(30) NULL, [Address] nvarchar(60) NULL, [City] nvarchar(15) NULL, [Region] nvarchar(15) NULL, [PostalCode] nvarchar(10) NULL, [Country] nvarchar(15) NULL Constraint df_country DEFAULT ‘Canada’, [Phone] nvarchar(24) NULL, [Fax] nvarchar(24) NULL, Primary Key (CustomerID) ); CREATE TABLE [dbo].[tblSupplier] ( [SupplierID] int NOT NULL, [Name] nvarchar(50) NULL, [Address] nvarchar(50) NULL, [City] nvarchar(50) NULL, [Province] nvarchar(50) NULL, Primary Key (SupplierID) ); CREATE TABLE [dbo].[tblShippers] ( [ShipperID] int NOT NULL, [CompanyName] nvarchar(40) NOT NULL, Primary Key (ShipperID),< CONSTRAINT uc_CompanyName UNIQUE (CompanyName) ); CREATE TABLE [dbo].[tblProducts] ( [ProductID] int NOT NULL, [SupplierID] int NULL, [CategoryID] int NULL, [ProductName] nvarchar(40) NOT NULL, [EnglishName] nvarchar(40) NULL, [QuantityPerUnit] nvarchar(20) NULL, [UnitPrice] money NULL, [UnitsInStock] smallint NULL, [UnitsOnOrder] smallint NULL, [ReorderLevel] smallint NULL, [Discontinued] bit NOT NULL, Primary Key (ProductID), Foreign Key (SupplierID) References tblSupplier ); CREATE TABLE [dbo].[tblOrders] ( [OrderID] int NOT NULL, [CustomerID] nvarchar(5) NOT NULL, [EmployeeID] int NULL, [ShipName] nvarchar(40) NULL, [ShipAddress] nvarchar(60) NULL, [ShipCity] nvarchar(15) NULL, [ShipRegion] nvarchar(15) NULL, [ShipPostalCode] nvarchar(10) NULL, [ShipCountry] nvarchar(15) NULL, [ShipVia] int NULL, [OrderDate] smalldatetime NULL, [RequiredDate] smalldatetime NULL, [ShippedDate] smalldatetime NULL, [Freight] money NULL Primary Key (OrderID), Foreign Key (CustomerID) References tblCustomers, Foreign Key (ShipVia) References tblShippers, Constraint valid_ShipDate CHECK (ShippedDate > OrderDate) ); CREATE TABLE [dbo].[tblOrderDetails] ( [OrderID] int NOT NULL, [ProductID] int NOT NULL, [UnitPrice] money NOT NULL, [Quantity] smallint NOT NULL, [Discount] real NOT NULL, Primary Key (OrderID, ProductID), Foreign Key (OrderID) References tblOrders, Foreign Key (ProductID) References tblProducts, Constraint Valid_Qty Check (Quantity > 0) ); Go الجزء الثاني: إنشاء عبارات لغة SQL اعرض قائمة العملاء customers والطلبات orders المُنشَأة خلال عام 2014. أظهر الحقول customer ID و order ID و order date و date ordered. Use Orders Go SELECT CompanyName, OrderID, RequiredDate as ‘order date’, OrderDate as ‘date ordered’ FROM tblcustomers JOIN tblOrders on tblOrders.CustomerID = tblCustomers.CustomerID WHERE Year(OrderDate) = 2014 أضف حقلًا جديدًا (نشطًا) في جدول tblCustomer باستخدام عبارة ALTER TABLE، حيث تكون قيمته الافتراضية True. ALTER TABLE tblCustomers ADD Active bit DEFAULT (‘True’) اعرض جميع الطلبات التي جرى شراؤها قبل 1 سبتمبر 2012 (اعرض الحقول company name و date ordered وكلفة الطلب الإجمالية (بما في ذلك تكلفة الشحن freight). SELECT tblOrders.OrderID, OrderDate as ‘Date Ordered’, sum(unitprice*quantity*(1-discount))+ freight as ‘Total Cost’ FROM tblOrderDetails join tblOrders on tblOrders.orderID = tblOrderDetails.OrderID WHERE OrderDate < ‘September 1, 2012’ GROUP BY tblOrders.OrderID, freight, OrderDate اعرض جميع الطلبات المشحونة عبر شركة Federal Shipping (اعرض الحقول OrderID و ShipName و ShipAddress و CustomerID). SELECT OrderID, ShipName, ShipAddress, CustomerID FROM tblOrders join tblShippers on tblOrders.ShipVia = tblShippers.ShipperID WHERE CompanyName= ‘Federal Shipping’ اعرض جميع العملاء الذين لم يشتروا في عام 2011. SELECT CompanyName FROM tblCustomers WHERE CustomerID not in ( SELECT CustomerID FROM tblOrders WHERE Year(OrderDate) = 2011 ) اعرض جميع المنتجات التي لم تُطلَب أبدًا. SELECT ProductID from tblProducts Except SELECT ProductID from tblOrderDetails أو يمكن حل ذلك بالشكل التالي: SELECT Products.ProductID,Products.ProductName FROM Products LEFT JOIN [Order Details] ON Products.ProductID = [Order Details].ProductID WHERE [Order Details].OrderID IS NULL اعرض معرّفات الطلبات OrderID للزبائن الذين يقيمون في لندن باستخدام استعلام فرعي (اعرض الحقول CustomerID و CustomerName و OrderID). SELECT Customers.CompanyName,Customers.CustomerID,OrderID FROM Orders LEFT JOIN Customers ON Orders.CustomerID = Customers.CustomerID WHERE Customers.CompanyName IN (SELECT CompanyName FROM Customers WHERE City = ‘London’) اعرض المنتجات التي يوفّرها الموّرد A والموّرد B (اعرض الحقول product name و supplier name). SELECT ProductName, Name FROM tblProducts JOIN tblSupplier on tblProducts.SupplierID = tblSupplier.SupplierID WHERE Name Like ‘Supplier A’ or Name Like ‘Supplier B’ اعرض جميع المنتجات التي تأتي ضمن صناديق (اعرض الحقول product name و QuantityPerUnit). SELECT EnglishName, ProductName, QuantityPerUnit FROM tblProducts WHERE QuantityPerUnit like ‘%box%’ ORDER BY EnglishName الجزء الثالث: الإدخال Insert والتعديل Update والحذف Delete والفهارس Indexes أنشئ جدول الموظفين Employee. يجب أن يكون المفتاح الرئيسي هو معرّف الموظف EmployeeID وهو حقل ترقيم تلقائي autonumber. أضف الحقول التالية: LastName و FirstName و Address و City و Province و Postalcode و Phone و Salary. استخدم عبارة إنشاء جدول CREATE TABLE وعبارات إدخال INSERT خمسة موظفين. ضم جدول الموظفين employee إلى الجدول Tblorders. اعرض السكريبت لإنشاء الجدول وإعداد القيود وإضافة الموظفين. Use Orders CREATE TABLE [dbo].[tblEmployee]( EmployeeID Int IDENTITY NOT NULL , FirstName varchar (20) NOT NULL, LastName varchar (20) NOT NULL, Address varchar (50), City varchar(20), Province varchar (50), PostalCode char(6), Phone char (10), Salary Money NOT NULL, Primary Key (EmployeeID) Go INSERT into tblEmployees Values (‘Jim’, ‘Smith’, ‘123 Fake’, ‘Terrace’, ‘BC’, ‘V8G5J6’, ‘2506155989’, ‘20.12’), (‘Jimmy’, ‘Smithy’, ‘124 Fake’, ‘Terrace’, ‘BC’, ‘V8G5J7’, ‘2506155984’, ‘21.12’), (‘John’, ‘Smore’, ’13 Fake’, ‘Terrace’, ‘BC’, ‘V4G5J6’, ‘2506115989’, ‘19.12’), (‘Jay’, ‘Sith’, ’12 Fake’, ‘Terrace’, ‘BC’, ‘V8G4J6’, ‘2506155939’, ‘25.12’), (‘Jig’, ‘Mith’, ’23 Fake’, ‘Terrace’, ‘BC’, ‘V8G5J5’, ‘2506455989’, ‘18.12’); Go أضف حقلًا يسمّى Totalsales إلى جدول Tblorders. استخدم تعليمات لغة DDL وعبارة ALTER TABLE. ALTER TABLE tblOrders ADD Foreign Key (EmployeeID) references tblEmployees (EmployeeID) استخدم عبارة UPDATE لإضافة مجموع مبيعات كل طلب بناءً على جدول تفاصيل الطلب order details. UPDATE tblOrders Set TotalSales = (select sum(unitprice*quantity*(1-discount)) FROM tblOrderDetails WHERE tblOrderDetails.OrderID= tblOrders.OrderID GROUP BY OrderID ترجمة -وبتصرف- للمقالات: Appendix A University Registration Data Model Example Appendix B Sample ERD Exercises Appendix C SQL Lab with Solution لـ Adrienne Watt و Nelson Eng اقرأ أيضًا: المقال السابق: لغة معالجة البيانات DML الخاصة بلغة SQL لغة معالجة البيانات DML الخاصة بلغة SQL نمذجة الكيان العلاقي ER عند تصميم قواعد البيانات نظرة سريعة على لغة الاستعلامات الهيكلية SQL النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

تُستخدَم لغة معالجة البيانات Data Manipulation Language -أو DML اختصارًا- الخاصة بلغة SQL للاستعلام عن البيانات في قاعدة البيانات وتعديلها، وسنشرح في هذا المقال كيفية استخدام تعليمات أوامر لغة SQL DML والتي هي SELECT وINSERT وUPDATE، وDELETE المُعرَّفة كما يلي: SELECT: للاستعلام عن بيانات في قاعدة البيانات. INSERT: لإدخال بيانات في جدول. UPDATE: لتحديث بيانات في جدول. DELETE: لحذف بيانات من جدول. في تعليمة SQL DML: يجب بدأ كل شرط في عبارة بسطر جديد. يجب انتظام بداية كل شرط مع بداية الشروط الأخرى. إذا تألّف شرط من عدة أجزاء، فيجب توضُّع هذه الأجزاء على سطور منفصلة، كما يجب إضافة مسافة بادئة لها تحت بداية الشرط لإظهار العلاقة. تُستخدَم الأحرف الكبيرة لتمثيل الكلمات المحجوزة. تُستخدَم الحروف الصغيرة لتمثيل الكلمات التي يُعرِّفها المستخدِم. تعليمة SELECT تسمح التعليمة أو الأمر SELECT للمستخدِم باستخراج البيانات من الجداول، بناءً على معايير محدَّدة، حيث تُعالَج وفقًا للتسلسل التالي: SELECT DISTINCT اختيار عنصر أو مجموعة عناصر. FROM من جدول أو مجموعة جداول. WHERE يليها تعبير شرطي. GROUP BY يليها حقل أو مجموعة حقول. ORDER BY يليها مجموعة حقول. يمكننا استخدام تعليمة SELECT لإنشاء قائمة بهواتف الموظفين من جدول الموظفين Employees كما يلي: SELECT FirstName, LastName, phone FROM Employees ORDER BY LastName سيعرض هذا الإجراء اسم عائلة last name الموظف، واسمه الأول first name، ورقم هاتفه phone number من جدول الموظفين Employees كما في الجدول التالي: table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } Last Name First Name Phone Number Hagans Jim 604-232-3232 Wong Bruce 604-244-2322 سنستخدم في المثال التالي جدول الناشرين Publishers table الذي يمثِّله الجدول الآتي، حيث ستلاحظ أنّ كندا Canada مكتوبة بطريقة خاطئة في حقل بلد الناشر Publisher Country المقابل لحقل اسم الناشر Example Publishing، ومدينة الناشر ABC Publishing. استخدم تعليمة UPDATE لتصحيح الأخطاء وتوحيد حقل البلد ليصبح Canada، -كما سنتكلم لاحقًا عن تعليمة UPDATE في هذا المقال. Publisher Name Publisher City Publisher Province Publisher Country Acme Publishing Vancouver BC Canada Example Publishing Edmonton AB Cnada ABC Publishing Toronto ON Canda إذا أضفتَ اسم الناشر Publisher Name، ومدينة الناشر Publisher City، فستستخدِم تعليمة SELECT، ويتبعها اسم الحقول التي يُفصَل بينها بفاصلة أجنبية comma، أي كما يلي: SELECT PubName, city FROM Publishers سيؤدي هذا الإجراء إلى عرض اسم الناشر ومدينته من جدول الناشرين. إذا أردت عرض حقل اسم الناشر باسم حقل المدينة -أي تبديل اسم الحقل PubName ليصبح city-، فاستخدِم تعليمة SELECT مع عدم وضع فاصلة أجنبية بين Pub_Name وcity، أي كما يلي: SELECT PubName city FROM Publishers سيعرض تنفيذ هذا الإجراء فقط الحقل PUB_NAME من جدول الناشرين، بحيث يكون له العنوان city. يفترض SQL Server أنك تريد وضع اسم عمود جديد للحقل PUB_NAME إذا لم تضمّن الفاصلة الأجنبية. تعليمة SELECT مع معيار WHERE قد ترغب أحيانًا في التركيز على جزء من جدول الناشرين، مثل الناشرين الموجودين في مدينة فانكوفر Vancouver فقط، إذ ستستخدم في هذه الحالة عبارة SELECT مع معيار WHERE، أي كما يلي: 'WHERE city = 'Vancouver. يوضِّح المثالان الأوليّان التاليان كيفية تحديد اختيار سجل مع المعيار WHERE باستخدام BETWEEN، إذ يعطي كل من هذين المثالَين نتائج تخزين العناصر نفسها التي عددها بين 20 و50 عنصر في المخزن. يستخدم المثال رقم 1 الكمية التي قيمتها بين 20 و50 عنصر مع تضمين العنصرين 20 و50 بالصورة التالية: qty BETWEEN 20 and 50. SELECT StorID, qty, TitleID FROM Sales WHERE qty BETWEEN 20 and 50 يستخدِم المثال رقم 2 الشرط qty >=20 and qty <=50. SELECT StorID, qty, TitleID FROM Sales WHERE qty >= 20 and qty <= 50 يوضِّح المثال رقم 3 كيفية تحديد اختيار سجل مع المعيار WHERE باستخدام NOT BETWEEN. SELECT StorID, qty, TitleID FROM Sales WHERE qty NOT BETWEEN 20 and 50 يظهر المثالان التاليان طريقتَين مختلفتَين لتحديد اختيار سجل مع المعيار WHERE باستخدام IN مع النتائج نفسها. يوضح المثال رقم 4 كيفية اختيار السجلات باستخدام حقل المقاطعة province من جدول Publishers -أي =province- على أساس جزء من تعليمة WHERE. SELECT * FROM Publishers WHERE province = 'BC' OR province = 'AB' OR province = 'ON' يوضِّح المثال رقم 5 كيفية اختيار السجلات باستخدام المقاطعة province مع IN على أساس جزء من تعليمة WHERE: SELECT * FROM Publishers WHERE province IN (‘BC’, ‘AB’, ‘ON’) يوضِّح المثالان الأخيران كيف يمكن استخدام NULL وNOT NULL لتحديد السجلات، ولكن سنستخدم في هذين المثالين جدول الكتب Books table الغير موضَّح هنا، والذي يحتوي على حقول، وهي: العنوان Title، والكمية Quantity، وسعر الكتاب Price، وكل ناشر لديه جدول كتب يعطي قائمةً بجميع كتب الناشر. يستخدِم المثال رقم 6 القيمة NULL: SELECT price, title FROM Books WHERE price IS NULL يستخدِم المثال رقم 7 القيمة NOT NULL: SELECT price, title FROM Books WHERE price IS NOT NULL استخدام محارف البدل wildcards في شرط LIKE يحدِّد الشرط LIKE الصفوف التي تحتوي على الحقول التي تطابق أجزاءً محددة من سلاسل محرفية، كما يُستخدَم LIKE مع البيانات التي من النوع char وvarchar وtext وdatetime وsmalldatetime. يسمح محرف البدل wildcard للمستخدِم بمطابقة الحقول التي تحتوي على محارف معينة، حيث سيعطي محرف البدل '%province = 'N جميع المقاطعات التي تبدأ بالمحرف N. يوضِّح الجدول التالي أربعة طرق لتحديد محارف البدل في تعليمة SELECT في صيغة التعبير المنتظم: محرف البدل wildcard نتيجة استخدامه % يمثل أيّ سلسلة تتألف من صفر أو أكثر من المحارف _ يمثل أيّ محرف واحد [ ] يمثل أيّ محرف واحد ضمن مجال محدد مثل المجال [a-f]، أو مجموعة محدَّدة مثل المجموعة [abcdef] [^] يمثل أي محرف واحد ليس ضمن مجال محدد مثل المجال [a - f^]، أو مجموعة محدَّدة مثل المجموعة [abcdef^] تبحث التعليمة '%LIKE 'Mc في المثال رقم 1 عن جميع أسماء العائلة last names التي تبدأ بالمحرفين Mc مثل McBadden: SELECT LastName FROM Employees WHERE LastName LIKE 'Mc%' تبحث التعليمة 'LIKE '%inger في المثال رقم 2 عن جميع أسماء العائلة التي تنتهي بالمحارف inger، مثل Ringer وStringer: SELECT LastName FROM Employees WHERE LastName LIKE '%inger' تبحث التعليمة '%LIKE '%en عن جميع أسماء العائلة التي تحتوي على المحرفين en، مثل Bennett وGreen وMcBadden: SELECT LastName FROM Employees WHERE LastName LIKE '%en%' تعليمة SELECT مع الشرط ORDER BY يُستخدَم الشرط ORDER BY لترتيب السجلات في القائمة الناتجة، ويمكنك استخدام ASC لترتيب النتائج تصاعديًا، وDESC لترتيب النتائج تنازليًا. يستخدِم المثال التالي ASC: SELECT * FROM Employees ORDER BY HireDate ASC يستخدم المثال التالي DESC: SELECT * FROM Books ORDER BY type, price DESC تعليمة SELECT مع الشرط GROUP BY يُستخدَم الشرط GROUP BY لإنشاء خرج هو عبارة عن صف واحد لكل مجموعة، وينتج قيمًا موجِزةً للأعمدة المحدَّدة، كما هو موضَّح أدناه: SELECT type FROM Books GROUP BY type يستخدم المثال التالي التعليمة السابقة: SELECT type AS 'Type', MIN(price) AS 'Minimum Price' FROM Books WHERE royalty > 10 GROUP BY type إذا تضمنت تعليمة SELECT معيار WHERE ليكون السعر price قيمةً غير فارغة not null كما يلي: SELECT type, price FROM Books WHERE price is not null فستكون التعليمة التي تحتوي على شرط GROUP BY كما يلي: SELECT type AS 'Type', MIN(price) AS 'Minimum Price' FROM Books WHERE price is not null GROUP BY type استخدام COUNT مع GROUP BY يمكننا استخدام COUNT لإحصاء عدد العناصر الموجودة في حاوية container، ولكن إذا أردت حساب عدد عناصر مختلفة في مجموعات منفصلة مثل رخام ذي ألوان مختلفة، فسنستخدِم دالة COUNT مع الأمر GROUP BY. توضح تعليمة SELECT أدناه كيفية حساب عدد مجموعات من البيانات باستخدام دالة COUNT مع الشرط أو الأمر GROUP BY: SELECT COUNT(*) FROM Books GROUP BY type استخدام AVG وSUM مع GROUP BY يمكننا استخدام دالة AVG لتعطينا متوسط أي مجموعة، وتُستخدَم الدالة SUM لإعطاء المجموع. يستخدِم المثال رقم 1 التالي دالة AVG مع الشرط GROUP BY type: SELECT AVG(qty) FROM Books GROUP BY type يستخدِم المثال رقم 2 التالي دالة SUM مع الشرط GROUP BY type: SELECT SUM(qty) FROM Books GROUP BY type يستخدِم المثال رقم 3 كلًا من الدالتين AVG، وSUM مع الشرط GROUP BY type في تعليمة SELECT: SELECT 'Total Sales' = SUM(qty), 'Average Sales' = AVG(qty), stor_id FROM Sales GROUP BY StorID ORDER BY 'Total Sales' تقييد الصفوف مع HAVING يمكن استخدام الشرط HAVING لتقييد الصفوف، فهو يشبه شرط WHERE باستثناء أنه يتضمّن دالة تجميع aggregate function؛ إذ لا يستطيع الشرط WHERE فعل ذلك، أي يتصرّف الشرط HAVING مثل الشرط WHERE، ولكنه قابل للتطبيق على المجموعات. نستخدم في هذا المثال الشرط HAVING لاستبعاد المجموعات التي مقاطعتها 'BC'. SELECT au_fname AS 'Author"s First Name', province as 'Province' FROM Authors GROUP BY au_fname, province HAVING province <> 'BC' تعليمة INSERT تضيف تعليمة INSERT صفوفًا إلى جدول، وأيضًا ما يلي: تحدِّد تعليمة INSERT الجدول أو العرض view التي ستُدخَل البيانات فيه. تعرض Column List قائمةً بالأعمدة التي ستتأثر بتعليمة INSERT. يجب توفير كل قيمة إذا حُذِف عمود. يمكن وضع الأعمدة في قائمة ضمن أي ترتيب إذا ضمّنتها. تحدِّد الكلمة VALUES البيانات التي تريد إدخالها في الجدول، وتكون VALUES إلزامية). يجب عدم إدراج الأعمدة ذات الخاصية IDENTITY بصورة صريحة في column_list أو value_sclause. صيغة تعليمة INSERT هي: INSERT [INTO] Table_name | view name [column_list] DEFAULT VALUES | values_list | select statement تُطبَّق القواعد التالية عند إدخال صفوف باستخدام تعليمة INSERT: يؤدي إدخال سلسلة فارغة (' ') في عمود من النوع varchar، أو text إلى إدخال مسافة واحدة. تُحشَى جميع الأعمدة ذات النوع char على اليمين right-padded حتى تصل إلى الطول المحدد. تُزال جميع المسافات الزائدة من البيانات المدرجة في أعمدة من النوع varchar، باستثناء السلاسل التي تحتوي على مسافات فقط، إذ تُختصَر هذه السلاسل إلى مسافة واحدة فقط. إذا أخلَّت تعليمة INSERT بالقيد، أو الافتراض، أو القاعدة، أو إذا كان نوع البيانات خاطئًا، فستفشل هذه التعليمة، وسيعرض خادم SQL Server رسالة خطأ. يمكن حدوث أحد الأشياء الثلاثة التالية للأعمدة التي لا تحتوي على قيم عند تحديد قيم بعض الأعمدة في column_list فقط: تُدخَل قيمة افتراضية إذا كان للعمود قيد DEFAULT، أو إذا كان الافتراض مرتبط بالعمود، أو إذا كان الافتراض مرتبط بنوع البيانات التي يعرِّفها المستخدم. تُدخَل القيمة الفارغة NULL إذا سمح العمود بالقيم الفارغة، ولا توجد قيمة افتراضية موجودة للعمود. تُعرَض رسالة خطأ ويُرفَض الصف إذا عُرَِف العمود بأنه غير فارغ NOT NULL، ولا توجد قيمة افتراضية. يستخدِم المثال التالي تعليمة INSERT لإضافة سجل إلى جدول الكتّاب Authors: INSERT INTO Authors VALUES('555-093-467', 'Martin', 'April', '281 555-5673', '816 Market St.,' , 'Vancouver', 'BC', 'V7G3P4', 0) يوضِّح المثال التالي كيفية إدخال صف جزئي partial row في جدول الناشرِين Publishers مع قائمة أعمدة. يملك عمود الدولة country قيمة افتراضية هي Canada، لذلك لا يلزمك تضمينه في قيمك. INSERT INTO Publishers (PubID, PubName, city, province) VALUES ('9900', 'Acme Publishing', 'Vancouver', 'BC') اتبع المثال التالي لإدخال صفوف في جدول مع عمود IDENTITY، ولا تعطي قيمةً للعمود IDENTITY، ولا قيمةً لاسم العمود ضمن قائمة الأعمدة. INSERT INTO jobs VALUES ('DBA', 100, 175) إدخال قيم محددة ضمن عمود IDENTITY لا يمكن إدخال البيانات مباشرة في عمود IDENTITY افتراضيًا، ولكن إذا حُذِف صف خطأً، أو إذا كانت هناك ثغرات في قيم عمود IDENTITY، فيمكنك إدخال صف وتحديد قيمة العمود IDENTITY. IDENTITY_INSERT option يمكن استخدام خيار IDENTITY_INSERT على النحو التالي للسماح بإدخال قيمة هوية identity محدَّدة: SET IDENTITY_INSERT jobs ON INSERT INTO jobs (job_id, job_desc, min_lvl, max_lvl) VALUES (19, 'DBA2', 100, 175) SET IDENTITY_INSERT jobs OFF إدخال صفوف باستخدام عبارة SELECT يمكننا أحيانًا إنشاء جدول مؤقت صغير من جدول كبير، لذلك يمكننا إدخال صفوف مع تعليمة SELECT. لا يوجد تحقق لصحة التفرد uniqueness عند استخدام هذا الأمر، وبالتالي، قد يكون هناك العديد من الصفوف بالمعرّف pub_id نفسه في المثال التالي. ينشِئ هذا المثال جدول ناشرِين Publishers مؤقت هو tmpPublishers أصغر باستخدام تعليمة إنشاء جدول CREATE TABLE، ثم تُستخدَم تعليمة INSERT مع تعليمة SELECT لإضافة سجلات إلى جدول الناشرِين المؤقت من جدول الناشرين Publishers. CREATE TABLE dbo.tmpPublishers ( PubID char (4) NOT NULL , PubName varchar (40) NULL , city varchar (20) NULL , province char (2) NULL , country varchar (30) NULL DEFAULT ('Canada') ) INSERT tmpPublishers SELECT * FROM Publishers ننسخ في هذا المثال مجموعةً فرعيةً من البيانات: INSERT tmpPublishers (pub_id, pub_name) SELECT PubID, PubName FROM Publishers تُنسَخ بيانات الناشرين في هذا المثال إلى جدول tmpPublishers ويُضبَط عمود الدولة country إلى القيمة Canada: INSERT tmpPublishers (PubID, PubName, city, province, country) SELECT PubID, PubName, city, province, ‘Canada’ FROM Publishers تعليمة UPDATE تغيّر تعليمة UPDATE البيانات في الصفوف الموجودة إما بإضافة بيانات جديدة أو بتعديل البيانات الموجودة. يستخدِم المثال التالي تعليمة UPDATE لتوحيد حقل الدولة country ليكون Canada لجميع السجلات في جدول Publishers: UPDATE Publishers SET country = 'Canada' يزيد المثال التالي مبالغ حقوق المؤلف royalty التي قيمتها بين 10 و20 بنسبة 10%: UPDATE roysched SET royalty = royalty + (royalty * .10) WHERE royalty BETWEEN 10 and 20 تضمين استعلامات فرعية subqueries ضمن عبارة UPDATE يُمنَح الموظفون في جدول الموظفين Employees الذين وظّفهم الناشر في عام 2010 ترقيةً إلى أعلى مستوى وظيفي حسب نوع عملهم كما يلي: UPDATE Employees SET job_lvl = (SELECT max_lvl FROM jobs WHERE employee.job_id = jobs.job_id) WHERE DATEPART(year, employee.hire_date) = 2010 تعليمة DELETE تزيل تعليمة DELETE صفوفًا من مجموعة سجلات، كما تحدِّد عبارة DELETE الجدول أو العرض view الذي يحوي الصفوف التي ستُحذَف، ويمكن إدراج جدول أو صف واحد فقط في الوقت نفسه. يُعَدّ الشرط WHERE المعيار الذي يحدِّد السجلات المراد حذفها، وتكون صيغة تعليمة DELETE كما يلي: DELETE [FROM] {table_name | view_name } [WHERE clause] قواعد تعليمة DELETE هي: إذا حُذِف شرط WHERE فستُزال جميع الصفوف الموجودة في الجدول باستثناء الفهارس indexes، والجدول، والقيود. لا يمكن استخدام عبارة DELETE بعرض view يحتوي على شرط FROM يسمّي أكثر من جدول واحد، فتعليمة DELETE يمكن أن تؤثر على جدول أساسي فقط في الوقت نفسه. فيما يلي ثلاث تعليمات DELETE مختلفة يمكن استخدامها: حذف جميع الصفوف من جدول: DELETE FROM Discounts حذف صفوف محدَّدة: DELETE FROM Sales WHERE stor_id = '6380' حذف صفوف بناءً على قيمة ضمن استعلام فرعي: DELETE FROM Sales WHERE title_id IN (SELECT title_id FROM Books WHERE type = 'mod_cook') الدوال المبنية مسبقا Built-in Functions يوجد العديد من الدوال المبنية مسبقًا في SQL Server، مثل: دوال التجميع Aggregate: ترجع قيمًا موجِزة summary values. دوال التحويل Conversion: تحوِّل نوع بيانات معين إلى نوع آخر. دوال التاريخ Date: تعرض معلومات عن التواريخ والأوقات. الدوال الرياضية Mathematical: تجري عمليات على البيانات العددية. الدوال المتعلِّقة بالسلاسل String: تجري عمليات على سلاسل المحارف، أو البيانات الثنائية، أو التعابير. الدوال المتعلِّقة بالنظام System: ترجع معلومات من قاعدة البيانات. الدوال المتعلِّقة بالنصوص Text، والصور image: تجري عمليات على بيانات نصية، أو على بيانات الصور. سنشرح أدناه الدوال الأربع الأولى شرحًا مفصَّلًا مع أمثلة عنها. دوال التجميع Aggregate functions تجري دوال التجميع حسابات على مجموعة من القيم، وترجع قيمةً واحدةً أو قيمةً موجِزةً. يعرض الجدول التالي هذه الدوال: الدالة FUNCTION وصفها AVG ترجع متوسط average جميع القيم، أو القيم المميزة DISTINCT فقط، ضمن التعبير COUNT ترجع عدد القيم غير الفارغة في التعبير، وإذا استخدِم التمايز DISTINCT فستجد الدالة COUNT عدد القيم غير الفارغة الفريدة (*)COUNT ترجع عدد الصفوف، ولا تأخذ الدالة (*)COUNT معاملات، كما لا يمكن استخدام التمايز DISTINCT معها MAX ترجع القيمة العليا في التعبير، ويمكن استخدام الدالة Max مع الأعمدة ذات النوع العددي، والمحرفي، والأعمدة ذات النوع datetime، ولكنها لا تُستخدَم مع الأعمدة ذات النوع bit، كما تعطي الدالة MAX مع الأعمدة المحرفية أعلى قيمة في تسلسل مرتَّب، وتتجاهل هذه الدالة القيم الفارغة MIN ترجع القيمة الدنيا في التعبير. يمكن استخدام الدالة MIN مع أعمدة عددية، ومحرفية، وذات النوع datetime، ولكنها لا تُستخدَم مع أعمدة لها النوع bit، كما تعطي الدالة MIN مع الأعمدة المحرفية أعلى قيمة في تسلسل مرتَّب، وتتجاهل هذه الدالة القيم الفارغة SUM ترجع مجموع كل القيم، أو فقط القيم المميزة DISTINCT في التعبير، ويمكن استخدام الدالة SUM مع الأعمدة العددية فقط سنعرض فيما يلي أمثلةً عن كل من دوال التجميع الموجودة في الجدول السابق. المثال الأول: الدالة AVG SELECT AVG (price) AS 'Average Title Price' FROM Books المثال الثاني: الدالة COUNT SELECT COUNT(PubID) AS 'Number of Publishers' FROM Publishers المثال الثالث: الدالة COUNT SELECT COUNT(province) AS 'Number of Publishers' FROM Publishers المثال الرابع: الدالة (*) COUNT SELECT COUNT(*) FROM Employees WHERE job_lvl = 35 المثال الخامس: الدالة MAX SELECT MAX (HireDate) FROM Employees المثال السادس: الدالة MIN SELECT MIN (price) FROM Books المثال السابع: الدالة SUM SELECT SUM(discount) AS 'Total Discounts' FROM Discounts دالة التحويل Conversion function تحوّل دالة التحويل نوع بيانات معين إلى نوع بيانات آخر. يُحوَّل السعر price الذي يحتوي ضمنه على تسعتين 99 إلى خمسة محارف في المثال الآتي، حيث تكون صيغة التعليمة بالصورة التالية: SELECT 'The date is ' + CONVERT(varchar(12), getdate()) إليك مثال: SELECT CONVERT(int, 10.6496) SELECT title_id, price FROM Books WHERE CONVERT(char(5), price) LIKE '%99%' مثال آخر عن تغيِّر دالة التحويل في المثال التالي البيانات إلى نوع بيانات بحجم مختلف: SELECT title_id, CONVERT(char(4), ytd_sales) as 'Sales' FROM Books WHERE type LIKE '%cook' دالة التاريخ Date function تُنتج دالة التاريخ تاريخًا عن طريق إضافة فاصل زمني إلى تاريخ محدَّد، والنتيجة هي قيمة لها نوع datetime، وتساوي التاريخ مضافًا إليه عدد أجزاء التاريخ date parts. إذا كان معامل دالة التاريخ قيمةً من النوع smalldatetime، فستكون النتيجة قيمةً من النوع smalldatetime أيضًا. تُستخدَم الدالة DATEADD لإضافة وزيادة قيم التاريخ، وصيغة هذه الدالة هي: (DATEADD(datepart, number, date. SELECT DATEADD(day, 3, hire_date) FROM Employees يستخدِم المثال الآتي الدالة (DATEDIFF(datepart, date1, date2، ويعيد هذا الأمر عدد أجزاء التاريخ أو الحدود boundaries المتقاطعة بين تاريخَين محددين. تجعل طريقة حساب الحدود المتقاطعة النتيجة التي أعطتها الدالة DATEDIFF متوافقة مع جميع أنواع البيانات، مثل الدقائق، والثواني، والميلي ثانية. SELECT DATEDIFF(day, HireDate, 'Nov 30 1995') FROM Employees يمكننا فحص أي جزء من تاريخ معيَّن من السنة إلى الميلي ثانية. يعرض الجدول التالي أجزاء التاريخ DATEPART، واختصاراتها، وقيمها المقبولة التي يعترف بها خادم SQL Server. جزء التاريخ DATE PART اختصاره ABBREVIATION قيمه VALUES Year yy 1753-9999 Quarter qq 1-4 Month mm 1-12 Day of year dy 1-366 Day dd 1-31 Week wk 1-53 Weekday dw 1-7‎ (Sun.-Sat.) Hour hh 0-23 Minute mi 0-59 Second ss 0-59 Millisecond ms 0-999 الدوال الرياضية Mathematical functions تجري الدوال الرياضية عمليات على البيانات العددية، ويعرض المثال التالي السعر الحالي لكل كتاب يبيعه الناشر، كما يعرض ما سيكون عليه الأمر إذا ارتفعت جميع الأسعار بنسبة 10%: SELECT Price, (price * 1.1) AS 'New Price', title FROM Books SELECT 'Square Root' = SQRT(81) SELECT 'Rounded' = ROUND(4567.9876,2) SELECT FLOOR (123.45) ربط الجداول Joining Tables يُعَدّ ربط جدولين أو أكثر مثل عملية موازنة بيانات ضمن أعمدة محدَّدة، واستخدام نتائج الموازنة لتشكيل جدول جديد من الصفوف المؤهلة لذلك. تقوم عبارة الربط join بما يلي: تحدِّد عمودًا من كل جدول. توازن القيم الموجودة في تلك الأعمدة صفًا صفًا. تدمج الصفوف ذات القيم المؤهلة ضمن صف جديد. تكون الموازنة عادةً مساواةً -أي القيم التي تتطابق مع بعضها البعض تمامًا-، ولكن يمكن تحديد أنواع ربط أخرى أيضًا. سنشرح جميع أنواع الربط المختلفة أدناه، مثل: الربط الداخلي inner، واليساري (الخارجي)، واليميني (الخارجي)، والربط المتقاطع cross join (التام). الربط الداخلي Inner join يربط جدولين في عمود له نفس نوع البيانات، وينتج الصفوف التي تتطابق فيها قيم العمود فقط، حيث يجري تجاهل الصفوف التي لا مثيل لها. المثال الأول: SELECT jobs.job_id, job_desc FROM jobs INNER JOIN Employees ON emp loyee.job_id = jobs.job_id WHERE jobs.job_id < 7 المثال الثاني: SELECT authors.au_fname, authors.au_lname, books.royalty, title FROM authorsINNER JOIN titleauthor ON authors.au_id=titleauthor.au_id INNER JOIN books ON titleauthor.title_id=books.title_id GROUP BY authors.au_lname, authors.au_fname, title, title.royalty ORDER BY authors.au_lname الربط اليساري الخارجي Left outer join ينتج عن الربط الخارجي اليساري كل الصفوف الخارجية اليسرى، إذ تُضمَّن جميع الصفوف من الجدول الأيسر التي لا تحقّق الشرط المحدّد في مجموعة النتائج، وتُضبَط أعمدة الخرج من الجدول الآخر على القيمة الفارغة NULL. يستخدِم المثال التالي الصيغة الجديدة للربط اليساري الخارجي: SELECT publishers.pub_name, books.title FROM Publishers LEFT OUTER JOIN Books On publishers.pub_id = books.pub_id بينما يستخدِم المثال التالي الصيغة القديمة للربط الخارجي اليساري: SELECT publishers.pub_name, books.title FROM Publishers, Books WHERE publishers.pub_id *= books.pub_id الربط الخارجي الأيمن Right outer join يتضّمن الربط الخارجي الأيمن في مجموعة النتائج الخاصة به كافة الصفوف من الجدول الأيمن التي لا تحقّق الشرط المحدّد، وتُضبَط أعمدة الخرج المقابلة من الجدول الآخر على القيمة الفارغة NULL. يستخدِم المثال التالي الصيغة الجديدة للربط الخارجي الأيمن: SELECT titleauthor.title_id, authors.au_lname, authors.au_fname FROM titleauthor RIGHT OUTER JOIN authors ON titleauthor.au_id = authors.au_id ORDERY BY au_lname بينما يوضِّح المثال التالي الصيغة القديمة المستخدَمة للربط الخارجي الأيمن: SELECT titleauthor.title_id, authors.au_lname, authors.au_fname FROM titleauthor, authors WHERE titleauthor.au_id =* authors.au_id ORDERY BY au_lname الربط الخارجي الكامل Full outer join يحدِّد الربط الخارجي الكامل أنه في حالة عدم تطابق صف من أي من الجدولين مع معايير التحديد، فسيُضمَّن الصف في مجموعة النتائج، وتُضبَط أعمدة الخرج الخاصة به التي تتوافق مع الجدول الآخر إلى القيمة الفارغة NULL. فيما يلي مثال عن ربط خارجي كامل: SELECT books.title, publishers.pub_name, publishers.province FROM Publishers FULL OUTER JOIN Books ON books.pub_id = publishers.pub_id WHERE (publishers.province <> "BC" and publishers.province <> "ON") ORDER BY books.title_id الربط المتقاطع Cross join الربط المتقاطع هو ناتج دمج جدولين، وينتج عن هذا الربط صفوف حالة عدم استخدام الشرط WHERE نفسها، أي كما يلي: SELECT au_lname, pub_name, FROM Authors CROSS JOIN Publishers للمزيد من المعلومات، انظر توثيق SQL في موسوعة حسوب. ترجمة -وبتصرّف- للمقال SQL Data Manipulation Language لصاحبَيه Adrienne Watt و Nelson Eng. اقرأ أيضًا المقال التالي: أمثلة عملية عن كيفية تصميم قواعد البيانات المقال السابق: نظرة سريعة على لغة الاستعلامات الهيكلية SQL الاعتماديات الوظيفية المستخدمة في تصميم قواعد البيانات قواعد السلامة وقيودها لضمان سلامة البيانات في قواعد البيانات الاستعلامات الفرعية والإجراءات في SQL البحث والتنقيب والترشيح في SQL معالجة الأخطاء والتعديل على قواعد البيانات في SQL النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

لغة الاستعلامات الهيكلية Structured Query Language -أو SQL اختصارًا- هي لغة قاعدة بيانات مصمَّمة لإدارة البيانات الموجودة في نظام إدارة قواعد البيانات العلائقية. طوّرت شركة IBM لغة SQL في أوائل السبعينات -عُرِفت بالإصدار 1986-، حيث صُمِّم الإصدار الأولي المسمَّى بلغة الاستعلامات الهيكلية الإنجليزية SEQUEL -اختصارًا للعبارة Structured English Query Language- لمعالجة واسترداد البيانات المخزَّنة في نظام خاص بشركة IBM وشبه علائقي لإدارة قواعد البيانات، ويُسمَّى نظام R. قدّمت بعد ذلك شركة Relational Software Inc -والتي أصبحت الآن شركة Oracle Corporation- أول تطبيق متاح تجاريًا للغة SQL والمسمَّى بـ Oracle V2 لحواسيب VAX في أواخر السبعينات. تُستخدَم العديد من أنظمة DBMS العلائقية المتاحة حاليًا، مثل: Oracle Database، وMicrosoft SQL Server -الموضَّح في الشكل التالي-، وMySQL، وIBM DB2، وIBM Informix، وMicrosoft Access، لغة SQL. تُستخدَم لغة قاعدة بيانات SQL في نظام DBMS من أجل: إنشاء بنى قواعد البيانات والجداول. إجراء الأعمال الأساسية لإدارة البيانات، مثل الإضافة والحذف والتعديل. إجراء استعلامات معقَّدة لتحويل البيانات الأولية إلى معلومات مفيدة. سوف نركز في هذا المقال على استخدام لغة SQL لإنشاء بنى قواعد البيانات والجداول، باستخدام لغة SQL على أساس لغة تعريف بيانات data definition language -أو DDL اختصارًا- بصورة أساسية. سنستخدم لغة SQL في مقال لاحق على أساس لغة معالجة بيانات data manipulation language -أو DML اختصارًا- لإدخال البيانات، وحذفها، واختيارها، وتحديثها في جداول قاعدة البيانات. إنشاء قاعدة بيانات Create Database تتكوّن عبارات لغة SQL DDL الرئيسية من: CREATE DATABASE وCREATE/DROP/ALTER TABLE، إذ تُستخدَم عبارة CREATE في لغة SQL لإنشاء بنى قواعد البيانات والجداول. إنشاء قاعدة بيانات تُنشَأ قاعدة بيانات جديدة تسمَّى SW باستخدام العبارة CREATE DATABASE SW بلغة SQL. الخطوة التالية بعد إنشاء قاعدة البيانات هي إنشاء جداول قاعدة البيانات. التنسيق العام للأمر CREATE TABLE هو: CREATE TABLE <tablename> ( ColumnName, Datatype, Optional Column Constraint, ColumnName, Datatype, Optional Column Constraint, Optional table Constraints ); يكون Tablename اسم جدول قاعدة البيانات مثل جدول الموظف Employee، كما يتكون كل حقل من الأمر CREATE TABLE من ثلاثة أجزا، هي: اسم العمود ColumnName. نوع البيانات Data type. قيد عمود اختياري Optional Column Constraint. يجب أن يكون اسم العمود ColumnName فريدًا في الجدول، وبعض الأمثلة على أسماء الأعمدة هي FirstName وLastName. أما نوع البيانات Data Type، فيجب أن يكون نوع بيانات نظام أو نوع بيانات يعرِّفه المستخدِم، كما تملك العديد من أنواع البيانات حجمًا، مثل (CHAR(35 أو (Numeric(8,2 وإليك قائمة بأشهر أنواع البيانات: النوع Bit: بيانات أعداد صحيحة Integer لها قيمة 1 أو 0. النوع Int: بيانات أعداد صحيحة Integer لها القيم من ‎-2^31 أي (‎-2,147,483,648) حتى ‎2^31 – 1، أي (‎2,147,483,647). النوع Smallint: بيانات أعداد صحيحة Integer لها القيم من ‎(-32,768) 2^15 أي حتى ‎ 2^15 – 1أي 32,767. النوع Tinyint: بيانات أعداد صحيحة Integer لها القيم من 0 حتى 255. النوع Decimal: بيانات ذات دقة ثابتة وقياس رقمي لها القيم من ‎-10^38 -1 إلى‎ 10^38. النوع Numeric: مرادف للنوع decimal. النوع Timestamp: رقم فريد على مستوى قاعدة البيانات. النوع Uniqueidentifier: معرَّف فريد عالميًا globally unique identifier -أو GUID اختصارًا-. النوع Money: تتراوح قيم البيانات النقدية من ‎-2^63 أي ‎-922,337,203,685,477.5808 حتى ‎2^63 – 1 أي ‎922,337,203,685,477.5807 بدقة تصل إلى واحد من عشرة آلاف من الوحدة النقدية. النوع Smallmoney: تتراوح قيم البيانات النقدية من ‎-214,748.3648إلى ‎+214,748.3647 بدقة تصل إلى واحد من عشرة آلاف من الوحدة النقدية. النوع Float: بيانات أرقام ذات دقة عشرية تتراوح قيمها بين ‎ -1.79E + 308و ‎1.79E + 308. النوع Real: بيانات أرقام ذات دقة عشرية قيمها تتراوح من ‎-3.40E + 38 حتى ‎3.40E + 38. النوع Datetime: بيانات التاريخ والوقت تتراوح قيمها من January 1, 1753 إلى December 31, 9999 بدقة تبلغ واحد إلى ثلاثة أجزاء من مئة من الثانية، أو 3.33 ميلي ثانية. النوع Smalldatetime: بيانات التاريخ والوقت تتراوح قيمها من January 1, 1900 حتى June 6, 2079 بدقة تبلغ دقيقة واحدة. النوع Char: بيانات محارف ثابتة الطول وليست يونيكود بطول أقصى 8000 محرف. النوع Varchar: بيانات متغيرة الطول وليست يونيكود بحد أقصى 8000 محرف. النوع Text: بيانات متغيرة الطول وليست يونيكود بطول أقصى يبلغ ‎2^31 – 1 أي ‎2,147,483,647 محرفًا. النوع Binary: بيانات ثنائية ذات طول ثابت بطول أقصى 8000 بايت. النوع Varbinary: بيانات ثنائية متغيرة الطول بطول أقصى يبلغ 8000 بايت. النوع Image: بيانات ثنائية متغيرة الطول بطول أقصى ‎2^31 – 1 أي‎ 2,147,483,647بايت. أخيرًا في ما يتعلق بقيود العمود الاختيارية Optional Column Constraints، فهي الآتي: NULL. NOT NULL. UNIQUE. PRIMARY KEY. DEFAULT. وتُستخدَم لتهيئة قيمة لسجل جديد. يشير قيد العمود NULL إلى أن القيمة الفارغة null مسموح بها، مما يعني أنه يمكن إنشاء صف بدون قيمة لهذا العمود؛ كما يشير قيد العمود NOT NULL إلى وجوب توفير قيمة عند إنشاء صف جديد. سنستخدم تعليمة لغة SQL للتوضيح والتي هي CREATE TABLE EMPLOYEES لإنشاء جدول موظفين يحتوي على 16 سمة attributes أو حقل fields. USE SW CREATE TABLE EMPLOYEES ( EmployeeNo CHAR(10) NOT NULL UNIQUE, DepartmentName CHAR(30) NOT NULL DEFAULT "Human Resources", FirstName CHAR(25) NOT NULL, LastName CHAR(25) NOT NULL, Category CHAR(20) NOT NULL, HourlyRate CURRENCY NOT NULL, TimeCard LOGICAL NOT NULL, HourlySalaried CHAR(1) NOT NULL, EmpType CHAR(1) NOT NULL, Terminated LOGICAL NOT NULL, ExemptCode CHAR(2) NOT NULL, Supervisor LOGICAL NOT NULL, SupervisorName CHAR(50) NOT NULL, BirthDate DATE NOT NULL, CollegeDegree CHAR(5) NOT NULL, CONSTRAINT Employee_PK PRIMARY KEY(EmployeeNo) ); الحقل الأول هو EmployeeNo من النوع CHAR، ويبلغ طول هذا الحقل 10 محارف، ولا يمكن للمستخدِم ترك هذا الحقل فارغًا NOT NULL، والحقل الثاني هو DepartmentName من النوع CHAR بطول 30. يُستخدَم قيد الجدول المعرَّف بواسطة الكلمة CONSTRAINT لإنشاء المفتاح الأساسي primary key، وذلك بعد تعريف جميع أعمدة الجدول، أي كما يلي: CONSTRAINT EmployeePK PRIMARY KEY(EmployeeNo) يمكننا إنشاء جدول أقسام Department، وجدول مشاريع Project، وجدول مهام Assignment باستخدام الأمر CREATE TABLE بلغة SQL DDL، كما هو موضَّح في المثال التالي: USE SW CREATE TABLE DEPARTMENT ( DepartmentName Char(35) NOT NULL, BudgetCode Char(30) NOT NULL, OfficeNumber Char(15) NOT NULL, Phone Char(15) NOT NULL, CONSTRAINT DEPARTMENT_PK PRIMARY KEY(DepartmentName) ); أُنشِئ جدول المشاريع project التالي بسبعة حقول هي: معرِّف المشروع ProjectID، واسم المشروع ProjectName، والقسم Department، والحد الأقصى للساعات MaxHours، وتاريخ البدء StartDate، وتاريخ الانتهاء EndDate. USE SW CREATE TABLE PROJECT ( ProjectID Int NOT NULL IDENTITY (1000,100), ProjectName Char(50) NOT NULL, Department Char(35) NOT NULL, MaxHours Numeric(8,2) NOT NULL DEFAULT 100, StartDate DateTime NULL, EndDate DateTime NULL, CONSTRAINT ASSIGNMENT_PK PRIMARY KEY(ProjectID) ); بينما أُنشِئ جدول المهام assignment بثلاثة حقول، هي: معرِّف المشروع ProjectID، ورقم الموظف EmployeeNumber، وساعات العمل HoursWorked. يُستخدَم جدول المهام لتسجيل الموظف باستخدام الحقل EmployeeNumber، ومقدار الوقت باستخدام الحقل HoursWorked الذي عمل فيه الموظف في مشروع معين باستخدام الحقل ProjectID، أي كما يلي: USE SW CREATE TABLE ASSIGNMENT ( ProjectID Int NOT NULL, EmployeeNumber Int NOT NULL, HoursWorked Numeric(6,2) NULL, ); قيود الجدول Table Constraints تُعرَّف قيود الجدول بواسطة الكلمة المفتاحية CONSTRAINT ويمكن استخدامها لتطبيق العديد من القيود الموضَّحة أدناه. القيد IDENTITY يمكننا استخدام قيد العمود الاختياري IDENTITY لتوفير قيمة فريدة تزايدية لهذا العمود، إذ تُستخدَم أعمدة الهوية Identity مع قيود المفتاح الرئيسي PRIMARY KEY لتكون بمثابة معرِّف صف فريد للجدول، كما يمكن إسناد الخاصية IDENTITY إلى عمود له نوع بيانات tinyint، أو smallint، أو int، أو decimal، أو numeric، وهذا القيد: يولِّد أرقامًا متسلسلةً. لا يفرض سلامة الكيان entity integrity. يمكن أن يحتوي عمود واحد فقط على الخاصية IDENTITY. يجب تعريفه على أساس نوع بيانات integer أو numeric أو decimal. لا يمكن تحديث عمود له الخاصية IDENTITY. لا يمكن أن يحتوي على قيم فارغة NULL. لا يمكنه ربط الافتراضات والقيود الافتراضية بالعمود. بالنسبة للقيد [(IDENTITY[(seed, increment: Seed: هي القيمة الأولية لعمود الهوية identity. Increment: هي القيمة المطلوب إضافتها إلى عمود الزيادة increment الأخير. سنستخدم مثال قاعدة بيانات آخر لتوضيح عبارات لغة SQL DDL بصورة أكبر من خلال إنشاء الجدول tblHotel في قاعدة بيانات الفندق HOTEL كما يلي: CREATE TABLE tblHotel ( HotelNo Int IDENTITY (1,1), Name Char(50) NOT NULL, Address Char(50) NULL, City Char(25) NULL, ) القيد UNIQUE يمنع القيد UNIQUE من إدخال قيم مكررة في عمود، حيث: يُستخدَم القيدان PK، و UNIQUE لفرض سلامة الكيان. يمكن تعريف قيود UNIQUE متعددة للجدول. يجري دائمًا التحقق من صحة البيانات الموجودة عند إضافة قيد UNIQUE إلى جدول موجود. يمكن وضع القيد UNIQUE على الأعمدة التي تقبل القيم الفارغة، حيث يمكن أن يكون صفٌ واحد فقط NULL. ينشِئ القيد UNIQUE دليلًا فريدًا للعمود المُختار تلقائيًا. الصيغة التالية هي الصيغة العامة للقيد UNIQUE: [CONSTRAINT constraint_name] UNIQUE [CLUSTERED | NONCLUSTERED] (col_name [, col_name2 […, col_name16]]) [ON segment_name] يستخدم المثال التالي القيد UNIQUE كما يلي: CREATE TABLE EMPLOYEES ( EmployeeNo CHAR(10) NOT NULL UNIQUE, ) القيد FOREIGN KEY المفتاح الخارجي يعرِّف القيد FOREIGN KEY -أو FK اختصارًا- عمودًا، أو مجموعة من الأعمدة التي تتطابق قيمها مع المفتاح الرئيسي PRIMARY KEY -أو PK اختصارًا- لجدول آخر، بحيث: تُحدَّث القيم في المفتاح الخارجي FK تلقائيًا عند تحديث أو تغيير قيم المفتاح الرئيسي PK في الجدول المرتبط. يجب أن تشير قيود المفتاح الخارجي FK إلى القيد المفتاح الرئيسي PK، أو القيد UNIQUE لجدول آخر. يجب أن يكون عدد أعمدة المفتاح الخارجي FK هو نفسه قيد المفتاح الرئيسي PK، أو قيد UNIQUE. إذا اُستخدِم الخيار WITH NOCHECK، فلن يتحقق قيد المفتاح الخارجي FK من صحة البيانات الموجودة في الجدول. لا يوجد دليل index للأعمدة التي تشارك في قيد المفتاح الخارجي FK. الصيغة التالية هي الصيغة العامة لقيد المفتاح الخارجي FOREIGN KEY: [CONSTRAINT constraint_name] [FOREIGN KEY (col_name [, col_name2 […, col_name16]])] REFERENCES [owner.]ref_table [(ref_col [, ref_col2 […, ref_col16]])] يكون الحقل HotelNo في المثال التالي في الجدول tblRoom مفتاحًا خارجيًا FK للحقل HotelNo في الجدول tblHotel الموضَّح سابقًا: USE HOTEL GO CREATE TABLE tblRoom ( HotelNo Int NOT NULL , RoomNo Int NOT NULL, Type Char(50) NULL, Price Money NULL, PRIMARY KEY (HotelNo, RoomNo), FOREIGN KEY (HotelNo) REFERENCES tblHotel ) القيد CHECK يقيِّد القيد CHECK القيم التي يمكن إدخالها في جدول، بحيث: يمكن أن يحتوي على شروط بحث مشابهة لعبارة WHERE. يمكنه الربط بين الأعمدة في نفس الجدول. يجب تقييم قاعدة التحقق من صحة البيانات للقيد CHECK من خلال تعبير بولياني boolean expression. يمكن تعريفه لعمود له قاعدة مرتبطة به. الصيغة التالية هي الصيغة العامة للقيد CHECK: [CONSTRAINT constraint_name] CHECK [NOT FOR REPLICATION] (expression) يقتصر حقل النوع Type في المثال التالي على الأنواع "Single"، أو "Double"، أو "Suite"، أو "Executive". USE HOTEL GO CREATE TABLE tblRoom ( HotelNo Int NOT NULL, RoomNo Int NOT NULL, Type Char(50) NULL, Price Money NULL, PRIMARY KEY (HotelNo, RoomNo), FOREIGN KEY (HotelNo) REFERENCES tblHotel CONSTRAINT Valid_Type CHECK (Type IN ('Single', 'Double', 'Suite', 'Executive')) ) يجب في المثال التالي أن يكون تاريخ تعيين الموظف قبل January 1, 2004، أو يجب أن يكون الحد الأقصى للراتب 300 ألف دولار: GO CREATE TABLE SALESREPS ( Empl_num Int Not Null CHECK (Empl_num BETWEEN 101 and 199), Name Char (15), Age Int CHECK (Age >= 21), Quota Money CHECK (Quota >= 0.0), HireDate DateTime, CONSTRAINT QuotaCap CHECK ((HireDate < "01-01-2004") OR (Quota <=300000)) ) القيد DEFAULT يُستخدَم القيد DEFAULT لتوفير قيمة تُضاف تلقائيًا لعمود ما إذا لم يوفّرها المستخدم، بحيث: يمكن احتواء العمود على قيد DEFAULT واحد فقط. لا يمكن استخدام القيد DEFAULT في الأعمدة التي لها نوع البيانات timestamp، أو الخاصية identity. ترتبط القيود DEFAULT تلقائيًا بعمود عند إنشائها. الصيغة العامة للقيد DEFAULT هي: [CONSTRAINT constraint_name] DEFAULT {constant_expression | niladic-function | NULL} [FOR col_name] يضبط المثال التالي القيمة الافتراضية default لحقل المدينة city field على القيمة "Vancouver": USE HOTEL ALTER TABLE tblHotel Add CONSTRAINT df_city DEFAULT ‘Vancouver’ FOR City الأنواع التي يعرفها المستخدم User Defined Types تعتمد الأنواع التي يعرِّفها المستخدِم دائمًا على نوع البيانات التي يوفرها النظام، فيمكن لهذه الأنواع فرض سلامة البيانات والسماح بالقيم الفارغة nulls. اختر الأنواع التي تكون تحت الكلمة "Programmability" في قاعدة البيانات الخاصة بك، لإنشاء نوع بيانات يعرِّفه المستخدِم في خادم SQL Server، ثم انقر بزر الماوس الأيمن واختر المسار New’ –>‘User-defined data type’، أو نفّذ إجراء النظام sp_addtype المخزّن system stored procedure، ثم اكتب ما يلي: sp_addtype ssn, 'varchar(11)', 'NOT NULL' سيؤدي هذا إلى إضافة نوع بيانات جديد عرّفه المستخدم يسمى SIN بتسعة محارف. يستخدم الحقل EmployeeSIN نوع البيانات SIN الذي عرّفه المستخدم في المثال التالي: CREATE TABLE SINTable ( EmployeeID INT Primary Key, EmployeeSIN SIN, CONSTRAINT CheckSIN CHECK (EmployeeSIN LIKE ' [0-9][0-9][0-9] – [0-9][0-9] [0-9] – [0-9][0-9][0-9] ') ) التعليمة ALTER TABLE يمكن استخدام تعليمات ALTER TABLE لإضافة وحذف القيود، بحيث: تسمح تعليمة ALTER TABLE بإزالة الأعمدة. يُتحقق من جميع البيانات الموجودة عند إضافة قيد للتأكد من عدم وجود انتهاكات. نستخدم في المثال التالي تعليمة ALTER TABLE للخاصية IDENTITY في الحقل ColumnName: USE HOTEL GO ALTER TABLE tblHotel ADD CONSTRAINT unqName UNIQUE (Name) استخدم تعليمة ALTER TABLE لإضافة عمود مع الخاصية IDENTITY مثل التعليمة ALTER TABLE TableName. ADD ColumnName int IDENTITY(seed, increment) التعليمة DROP TABLE تزيل التعليمة DROP TABLE جدولًا من قاعدة البيانات، لذلك تأكد من تحديد قاعدة البيانات الصحيحة. DROP TABLE tblHotel سيؤدي تنفيذ عبارة DROP TABLE السابقة بلغة SQL إلى إزالة الجدول tblHotel من قاعدة البيانات. تمارين باستخدام المعلومات الخاصة بالتمرين الموجود في المقال قواعد السلامة والقيود المُطبَّقة عند تصميم قواعد البيانات، طبّق التخطيط باستخدام لغة Transact SQL -أي اعرض تعليمات SQL لكل جدول-، وطبّق القيود أيضًا. أنشئ الجدول الموضَّح أدناه في خاوم SQL Server، واعرض التعليمات التي استخدمتها. الجدول: Employee table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } ATTRIBUTE (FIELD) NAME DATA DECLARATION EMP_NUM CHAR(3) EMP_LNAME VARCHAR(15) EMP_FNAME VARCHAR(15) EMP_INITIAL CHAR(1) EMP_HIREDATE DATE JOB_CODE CHAR(3) اكتب شيفرة لغة SQL لإدخال صفوف الجدول السابق، بعد إنشاء بنيته. استخدم الشكل السابق للإجابة على الأسئلة من 4 إلى 10. اكتب شيفرة لغة SQL لتغيير رمز الوظيفة job code إلى 501 للموظف الذي رقمه 107، وافحص النتائج بعد الانتهاء من المهمة، ثم أعد ضبط رمز الوظيفة إلى قيمته الأصلية. اكتب شيفرة لغة SQL لإعطاء قائمة بجميع السمات الخاصة برمز الوظيفة 502، بافتراض إدخال البيانات الموضَّحة في جدول الموظف Employee. اكتب شيفرة لغة SQL لحذف الصف الخاص بالشخص الذي اسمه "William Smithfield"، والذي وُظِّف في June 22, 2004، والذي تصنيف رمز وظيفته هو 500. أضف السمتين EMP_PCT، وPROJ_NUM إلى جدول الموظف، بحيث تكون السمة EMP_PCT هي نسبة المكافأة المدفوعة لكل موظف. اكتب شيفرة لغة SQL باستخدام أمر واحد لإدخال رقم المشروع PROJ_NUM = 18 لجميع الموظفين الذين تصنيف الوظيفة JOB_CODE الخاص بهم هو 500. اكتب شيفرة لغة SQL باستخدام أمر واحد لإدخال رقم المشروع PROJ_NUM = 25 لجميع الموظفين الذين تصنيف الوظيفة JOB_CODE الخاص بهم يساوي 502 أو أعلى. اكتب شيفرة لغة SQL لتغيير رقم المشروع PROJ_NUM إلى 14 للموظفين الذين تعيّنوا قبل January 1, 1994، ورمز الوظيفة الخاصة بهم يساوي 501 على الأقل. (قد تفترض أن الجدول سيعاد إلى حالته الأصلية التي سبقت هذا السؤال). ترجمة -وبتصرّف- للمقال SQL Structured Query Language لصاحبَيه Adrienne Watt وNelson Eng. اقرأ أيضًا المقال التالي: لغة معالجة البيانات DML الخاصة بلغة SQL المقال السابق: عملية تطوير قواعد البيانات Database Development النسحة الكاملة من كتاب ملاحظات للعاملين بلغة SQL الاستعلامات الفرعية والإجراءات في SQL قواعد السلامة وقيودها لضمان سلامة البيانات في قواعد البيانات الاعتماديات الوظيفية المستخدمة في تصميم قواعد البيانات

يجب أن يكون التوحيد Normalization جزءًا من عملية تصميم قاعدة البيانات، ولكن من الصعب فصل عملية التوحيد عن عملية نمذجة الكيان العلائقي ER modelling، لذلك يجب استخدام الطريقتين بصورةٍ متزامنة. يُستخدَم مخطط الكيان والعلاقة entity relation diagram -أو ERD اختصارًا- لتوفير الرؤية الكبيرة أو الشاملة لمتطلبات بيانات المؤسسة وعملياتها، إذ يَنشأ ذلك من خلال عملية تكرارية تتضمن تحديد الكيانات المرتبطة، وسماتها، وعلاقاتها؛ بينما يركِّز إجراء التوحيد على خصائص كيانات محددَّة، كما يمثِّل رؤيةً مُصغَّرةً للكيانات داخل مخطط ERD. ما هو التوحيد Normalization؟ التوحيد هو فرع من فروع النظرية العلائقية الذي يوفر رؤى التصميم، وهو عملية تحديد مقدار التكرار redundancy الموجود في الجدول. أهداف التوحيد هي: القدرة على وصف مستوى التكرار في مخطط علائقي. توفير آليات لتغيير المخططات بهدف إزالة التكرار. تعتمد نظرية التوحيد على نظرية الاعتماديات الوظيفية اعتمادًا كبيرًا، وتحدِّد هذه النظرية ستة نماذج موحَّدة normal forms -أو NF اختصارًا-، حيث يتضمن كل نموذج موحَّد مجموعةً من خصائص الاعتمادية التي يجب أن يفي المخطط بها، كما يعطي كل نموذج موحَّد ضمانات حول وجود / أو عدم وجود حالات تحديث شاذة update anomalies، وهذا يعني احتواء النماذج الموحدة الأعلى على عدد أقل من التكرار، وبالتالي، مشاكل تحديث أقل. النماذج الموحدة Normal Forms يمكن أن تكون جميع الجداول الموجودة في قواعد البيانات ضمن أحد النماذج الموحَّدة التي سنناقشها الآن. نريد الحد الأدنى من التكرار بين المفتاح الرئيسي PK، والمفتاح الخارجي FK من الناحية المثالية، كما يجب اشتقاق كل شيء آخر من جداول أخرى. هناك ستة نماذج موحَّدة، ولكننا سنلقي نظرة على النماذج الأربعة الأولى فقط، وهي: النموذج الموحَّد الأول First normal form، أو 1NF اختصارًا. النموذج الموحَّد الثاني Second normal form، أو 2NF اختصارًا. النموذج الموحَّد الثالث Third normal form، أو 3NF اختصارًا. نموذج بويس-كود الموحَّد Boyce-Codd normal form، أو BCNF اختصارًا، وهو نادر الاستخدام. النموذج الموحد الأول 1NF يُسمَح فقط بقيم غير مكرَّرة في النموذج الموحد الأول عند تقاطع كل صف وعمود، وهذا يؤدي إلى عدم وجود مجموعات مكرَّرة repeating group، حيث يجب إزالة المجموعة المكرَّرة، وتشكيل علاقتين جديدتين لتوحيد علاقة تحتوي على مجموعة مكرَّرة، ويكون المفتاح الرئيسي PK للعلاقة الجديدة هو تركيب من المفتاح الرئيسي PK للعلاقة الأصلية بالإضافة إلى سمة من العلاقة المنشَأة حديثًا للحصول على تعريف فريد. عملية نموذج 1NF سنستخدم جدول تقرير درجات الطالب Student_Grade_Report أدناه، من قاعدة بيانات المدرسة School على أساس مثال لشرح عملية نموذج 1NF. Student_Grade_Report (StudentNo, StudentName, Major, CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation, Grade) تكون المجموعة المكرَّرة في جدول تقرير درجات الطالب Student Grade Report هي معلومات المقرر الدراسي course، إذ يمكن للطالب أخذ مقررات متعددة. أزِل المجموعة المكررَّة، حيث تكون المجموعة المكرَّرة في هذه الحالة هي معلومات المقرر لكل طالب. حدِّد المفتاح الرئيسي PK لجدولك الجديد. يجب أن يحدِّد المفتاح الرئيسي PK قيمةَ السمة StudentNo وCourseNo تحديدًا فريدًا. يتبقى لك جدول مقررات الطلاب StudentCourse بعد إزالة جميع السمات المتعلِّقة بالمقرر والطالب. أصبح جدول الطالب Student الآن بصيغة النموذج الموحَّد الأول مع إزالة المجموعة المكرَّرة. الجدولان الجديدان موضَّحان كما يلي: Student (StudentNo, StudentName, Major) StudentCourse (StudentNo, CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation, Grade) تحديث حالات نموذج 1NF الشاذة بالنظر إلى الجدول السابق والذي يسبقه: نحتاج طالبًا لإضافة مقرَّر جديد. قد يكون لدينا تناقضات عندما تحتاج معلومات المقرَّر إلى تحديث. قد نحذف أيضًا معلومات هامة حول مقرر عند حذف طالب. النموذج الموحد الثاني 2NF يجب أن تكون العلاقة أولًا بصيغة نموذج 1NF للانتقال إلى النموذج الموحَّد الثاني 2NF، حيث تكون العلاقة تلقائيًا بصيغة نموذج 2NF إذا وفقط إذا اشتمل المفتاح الرئيسي PK على سمة واحدة. إذا احتوت العلاقة على مفتاح رئيسي مركّب composite PK، فيجب أن تعتمد كل سمةٍ ليست مفتاحًا على المفتاح الرئيسي PK بأكمله اعتمادًا كاملًا، ولا تعتمد على مجموعة فرعية من المفتاح الرئيسي PK، أي لا يجب وجود اعتمادية جزئية partial dependency، أو ما يُسمَّى بالزيادة augmentation. عملية نموذج 2NF يجب أولًا أن يكون الجدول بصيغة نموذج 1NF للانتقال إلى النموذج 2NF. جدول الطالب Student موجود بالفعل بصيغة نموذج 2NF لأنه يحتوي على عمود مفتاح رئيسي واحد. ليست كل السمات -وتحديدًا جميع معلومات المقرر course information- معتمدةً بالكامل على المفتاح الرئيسي عند فحص جدول مقررات الطلاب Student Course، إذ تكون السمة الوحيدة المعتمدة بالكامل على المفتاح الرئيسي هي الدرجة grade. عرِّف الجدول الجديد الذي يحتوي على معلومات المقرَّر. عرِّف المفتاح الرئيسي PK للجدول الجديد. الجداول الثلاثة الجديدة موضَّحة أدناه. Student (StudentNo, StudentName, Major) CourseGrade (StudentNo, CourseNo, Grade) CourseInstructor (CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation) تحديث حالات نموذج 2NF الشاذة بالنظر إلى الجداول السابقة: نحتاج إلى مقرَّر course عند إضافة مدرِّس جديد. قد يؤدي تحديث معلومات المقرر إلى وجود تناقضات في معلومات المدرِّس. قد يؤدي حذف المقرر أيضًا إلى حذف معلومات المدرِّس. النموذج الموحد الثالث 3NF يجب أن تكون العلاقة بصيغة النموذج الموحَّد الثاني 2NF للانتقال إلى النموذج الموحَّد الثالث 3NF، كما يجب إزالة جميع الاعتماديات المتعدية transitive dependencies أيضًا، فقد لا تعتمد السمة التي ليست مفتاحًا اعتمادًا وظيفيًا على سمة أخرى ليست مفتاحًا. عملية نموذج 3NF أزِل كافة السمات الاعتمادية dependent attributes في العلاقة، أو في العلاقات المتعدية من كل جدول من الجداول التي لها علاقة متعدية. أنشِئ جدولًا، أو جداولًا جديدةً مع إزالة الاعتمادية. تحقق من الجدول، أو الجداول الجديدة، كما تحقق من الجدول، أو الجداول المعدَّلة أيضًا، وذلك للتأكد من احتواء كل جدول على محدِّد determinant، ومن عدم وجود جدول يحتوي على اعتماديات غير مناسبة. الجداول الأربعة الجديدة موضَّحة أدناه. Student (StudentNo, StudentName, Major) CourseGrade (StudentNo, CourseNo, Grade) Course (CourseNo, CourseName, InstructorNo) Instructor (InstructorNo, InstructorName, InstructorLocation) يجب ألا تكون هناك حالات شاذة في النموذج الموحَّد الثالث في هذه المرحلة. لنلقِ نظرةً على مخطط الاعتمادية الموضَّح في الشكل الآتي لهذا المثال، حيث تتمثل الخطوة الأولى في إزالة المجموعات المكرَّرة. Student (StudentNo, StudentName, Major) StudentCourse (StudentNo, CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation, Grade) تلخِّص الاعتماديات الموضَّحة في الشكل التالي عملية توحيد normalization قاعدة بيانات المدرسة School database: الاختصارات المستخدمة في الشكل السابق هي كما يلي: PD: الاعتمادية الجزئية partial dependency. TD: الاعتمادية المتعدية transitive dependency. FD: الاعتمادية الكاملة full dependency، إذ يشير الاختصار FD إلى الاعتمادية الوظيفية functional dependency عادةً، ولكن استخدمنا الاختصار FD على أساس اختصار للاعتمادية الكاملة full dependency في الشكل السابق فقط. نموذج بويس-كود الموحد BCNF قد تنتج حالات شاذة عندما يحتوي الجدول على أكثر من مفتاح مرشَّح candidate key على الرغم من أن العلاقة بصيغة نموذج 3NF، حيث يُعَدّ نموذج بويس-كود الموحَّد حالةً خاصةً من النموذج 3NF، وتكون العلاقة ضمن نموذج BCNF إذا وفقط إذا كان كل محدّد determinant مفتاحًا مرشَحًا candidate key. المثال الأول عن نموذج BCNF ضع في بالك الجدول التالي St_Maj_Adv: table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } Student_id Major Advisor 111 Physics Smith 111 Music Chan 320 Math Dobbs 671 Physics White 803 Physics Smith تكون القواعد الدلالية semantic rules -أي قواعد العمل المطبَّقة على قاعدة البيانات- لهذا الجدول هي: يجوز لكل طالب Student التخصص في عدة مواد. يكون لكل طالب معين مدرِّسًا واحدًا فقط لكل تخصص Major. لكل تخصص عدة مدرِّسين. يدرِّس كل مدرِّس تخصصًا واحدًا فقط. يدرِّس كل مدرِّس عدة طلاب في تخصص واحد. الاعتماديات الوظيفية لهذا الجدول مذكورة أدناه، فالأولى هي مفتاح مرشَّح candidate key، والثانية ليست كذلك. Student_id, Major ——> Advisor Advisor ——> Major تشمل الحالات الشاذة لهذا الجدول ما يلي: الحذف Delete: مثل حالة حذف الطالب معلومات المدرِّس. الإدخال Insert: مثل حالة احتياج المدرِّس الجديد إلى وجود طالب. التحديث Update: مثل الحالات المتناقضة. ملاحظة: ليست السمة المُفرَدة single attribute مفتاحًا مرشَحًا. يمكن أن يكون المفتاح الرئيسي PK هو Student_id, Major، أو Student_id, Advisor. يمكنك إنشاء جدولين جديدين، لتقليل العلاقة St_Maj_Adv إلى النموذج BCNF كما يلي: St_Adv (Student_id, Advisor) Adv_Maj (Advisor, Major) جدول St_Adv: Student_id Advisor 111 Smith 111 Chan 320 Dobbs 671 White 803 Smith جدول Adv_Maj: Advisor Major Smith Physics Chan Music Dobbs Math White Physics المثال الثاني عن نموذج BCNF انظر الجدول التالي Client_Interview: ClientNo InterviewDate InterviewTime StaffNo RoomNo CR76 13-May-02 10.30 SG5 G101 CR56 13-May-02 12.00 SG5 G101 CR74 13-May-02 12.00 SG37 G102 CR56 1-July-02 10.30 SG5 G102 FD1 – ClientNo, InterviewDate –> InterviewTime, StaffNo, RoomNo (PK) FD2 – staffNo, interviewDate, interviewTime –> clientNO (candidate key: CK) FD3 – roomNo, interviewDate, interviewTime –> staffNo, clientNo (CK) FD4 – staffNo, interviewDate –> roomNo تكون العلاقة بصيغة نموذج BCNF إذا وفقط إذا كان كل محدّد determinant مفتاحًا مرشَّحًا. نحن بحاجة إلى إنشاء جدول يتضمن أول ثلاثة اعتماديات كاملة FD -أي جدول Client_Interview2-، وإنشاء جدول آخر -أي جدول StaffRoom- للاعتمادية الكاملة FD الرابعة. جدول Client_Interview2: ClientNo InterviewDate InterViewTime StaffNo CR76 13-May-02 10.30 SG5 CR56 13-May-02 12.00 SG5 CR74 13-May-02 12.00 SG37 CR56 1-July-02 10.30 SG5 جدول StaffRoom: StaffNo StaffNo RoomNo SG5 13-May-02 G101 SG37 13-May-02 G102 SG5 1-July-02 G102 التوحيد وتصميم قواعد البيانات تأكَّد أثناء عملية توحيد تصميم قاعدة البيانات من توافق الكيانات المقترحة للنموذج الموحَّد المطلوب قبل إنشاء بُنى الجدول. صُمِّمت العديد من قواعد البيانات واقعيًا بصورة غير سليمة، أو أُثقِل كاهلها بحالات شاذة عند تعديلها بصورة غير سليمة خلال فترة زمنية، وقد يُطلب منك إعادة تصميم قواعد البيانات الحالية، وتعديلها، كما يمكن أن يكون ذلك مهمةً كبيرةً إذا أجريت عملية التوحيد على الجداول بصورةٍ غير صحيحة. تمارين ما هو التوحيد normalization؟ متى يكون جدول ما في نموذج 1NF؟ 3.متى يكون جدول ما في نموذج 2NF؟ متى يكون جدول ما في نموذج 3NF؟ عرِّف وناقش كل من الاعتماديات المشار إليها في مخطط الاعتمادية الموضَّح في الشكل التالي: تستخدم كليّة جامعية college جديدة بنية الجدول الموضَّحة في الشكل التالي، وذلك لتتبع الطلاب والمقرَّرات، وبالتالي، ارسم مخطط الاعتمادية لهذا الجدول. table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } Attribute Name Sample Value Sample Value Sample Value StudentID 1 2 3 StudentName John Smith Sandy Law Sue Rogers CourselD 2 2 3 CourseName Programming Level 1 Programming Level 1 Business Grade 75% 61% 81% CourseDate Jan 5th, 2014 Jan 5th, 2014 Jan 7th, 2014 اعرض الجداول بصيغة النموذج الموحَّد الثالث التي ستنشئها لإصلاح المشكلات التي واجهتها باستخدام مخطط الاعتمادية الذي رسمته للتو، ثم ارسم مخطط الاعتمادية للجدول الثابت. توفر الوكالة التي تسمى Instant Cover موظفِين بدوام جزئي / مؤقت للفنادق في اسكتلندا، إذ يوضِّح الشكل الآتي الوقت الذي يقضيه موظفو الوكالة في العمل في فنادق مختلفة، حيث يكون رقم التأمين الوطني NIN -أي national insurance number- فريدًا لكل موظف. استخدم الشكل التالي للإجابة على السؤالين الآتيين: NIN ContractNo Hours eName hNo hLoc 1135 C1024 16 Smith J. H25 East Killbride 1057 C1024 24 Hocine D. H25 East Killbride 1068 C1025 28 White T. H4 Glasgow 1135 C1025 15 Smith J. H4 Glasgow هذا الجدول عرضة لحالات تحديث شاذة، لذلك قدّم أمثلةً على حالات شاذة للإدخال، والحذف، والتحديث. طَبّق عملية التوحيد على هذا الجدول ليصبح له صيغة النموذج الموحّد الثالث، مع ذكر أي افتراضات. إملأ الفراغات: ينتج عن __ نموذجًا موحّدًا أقل. تسمى السمة التي تحدِّد قيمتها قيمًا أخرى داخل صف __. السمة التي لا يمكن تقسيمها توصف بأنها ___. يشير __ إلى مستوى التفاصيل الذي تمثِّله القيم المخزَّنة في صف الجدول. يجب ألا يحتوي الجدول العلائقي على مجموعات ___. ترجمة -وبتصرف- للمقال Normalization لصاحبته Adrienne Watt. اقرأ أيضًا المقال التالي: عملية تطوير قواعد البيانات Database Development المقال السابق: الاعتماديات الوظيفية المستخدمة في تصميم قواعد البيانات نموذج الكيان والعلاقة ER لتمثيل البيانات وتخزينها في قاعدة البيانات المفاهيم الأساسية في قواعد البيانات وتصميمها نموذج الكيان والعلاقة ER لتمثيل البيانات وتخزينها في قاعدة البيانات النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

الاعتمادية الوظيفية functional dependency -أو FD اختصارًا- هي علاقة بين سمتَين attributes، حيث تكون عادةً بين المفتاح الرئيسي PK والسمات الأخرى التي ليست مفاتيحًا non-key attributes داخل الجدول، إذ تعتمد السمة Y وظيفيًا على السمة X -والتي تُعَد مفتاحًا رئيسيًا PK- في علاقة R إذا حدّدت قيمةُ السمة X قيمةَ السمة Y بصورةٍ فريدة لكل نسخةٍ صالحة من السمة X، ويشار إلى هذه العلاقة من خلال التمثيل التالي: X ———–> Y يسمى الجانب الأيسر من مخطط الاعتمادية الوظيفية FD السابق بالمحدِّد determinant، ويسمى الجانب الأيمن بالاعتمادي dependent، وفيما يلي بعض الأمثلة على ذلك. تحدِّد السمة SIN الاسم Name، والعنوان Address، وتاريخ الميلاد Birthdate في المثال الأول أدناه، حيث يمكننا تحديد أي من السمات الأخرى داخل الجدول باستخدام السمة SIN. SIN ———–> Name, Address, Birthdate تحدِّد السمتان SIN، وCourse تاريخ الانتهاء DateCompleted في المثال الثاني، حيث يجب أن يعمل هذا أيضًا مع مفتاح رئيسي مركّّب composite PK. SIN, Course ———–> DateCompleted يشير المثال الثالث إلى أن السمة ISBN تحدّد العنوان Title. ISBN ———–> Title قواعد الاعتماديات الوظيفية انظر إلى جدول البيانات (r(R لمخطط العلاقة (R(ABCDE الموضَّح في الشكل التالي: قد تسأل نفسك عند النظر إلى هذا الجدول: ما نوع الاعتماديات التي يمكننا ملاحظتها بين السمات في الجدول R؟ بما أنّ قيم السمة A فريدة (a1, a2, a3, etc)، فيمكن القول اعتمادًا على تعريف الاعتمادية الوظيفية FD أنّ: A → B, A → C, A → D, A → E ويترتب على ذلك أيضًا أن A → BC، أو أي مجموعة فرعية أخرى من المجموعة ABCDE. يمكن تلخيص ذلك على أساس A → BCDE. تُعَدّ السمة A مفتاحًا رئيسيًا. بما أن قيم السمة E هي نفسها دائمًا أي كلها لها القيمة e1، فهذا يعني أنّ: A → E, B → E, C → E, D → E ولكن لا يمكننا تلخيص ما سبق باستخدام ABCD → E، وذلك لأنّ: A → E, B → E, AB → E ملاحظات أخرى: تركيبات BC فريدة، لذلك BC → ADE. تركيبات BD فريدة، لذلك BD → ACE. إذا كانت قيم السمة C متطابقة، فإن قيم السمة D متطابقة كذلك. لذلك C → D. ولكن لا تحدِّد قيم السمة D قيم السمة C. لذلك لا تحدّد السمة C السمة D، ولا تحدِّد السمة D السمة C. يمكن مساعدة النظر إلى البيانات الفعلية في توضيح السمات التي هي سمات اعتمادية dependent، والسمات التي هي سمات محدِّدة determinant. قواعد الاستدلال Inference Rules تُعَدّ بديهيات أرمسترونغ Armstrong’s axioms مجموعةً من قواعد الاستدلال المستخدَمة لاستنتاج جميع الاعتماديات الوظيفية في قاعدة بيانات علائقية، حيث طوَّر ويليام أرمسترونغ William W. Armstrong هذه البديهيات. لنفترض أنّ (R(U هو مخطط علاقة لمجموعة سمات U، حيث سنستخدم الأحرف X، وY، وZ لتمثيل أي مجموعة فرعية، أو اتحاد union مجموعتين من السمات اختصارًا، بدلًا من استخدام X U Y. بديهية الانعكاس Axiom of reflexivity تنص هذه البديهية على أنه إذا كانت Y مجموعة فرعية subset من X، فإنّ X تحدِّد Y، كما في الشكل التالي: افترض الاعتمادية الوظيفية PartNo —> NT123 على سبيل المثال، حيث تتركّب (X (PartNo من معلومات متعددة، وهي: (Y (NT، و(partID (123. بديهية الزيادة Axiom of augmentation تنص بديهية الزيادة -والمعروفة باسم الاعتمادية الجزئية partial dependency أيضًا- على أنه إذا كانت X تحدِّد Y، فإنّ XZ تحدد YZ مهما كانت Z، أي كما في الشكل التالي: تنص بديهية الزيادة على أن يجب على كل سمة ليست مفتاحًا non-key attribute الاعتماد على المفتاح الرئيسي PK بصورة كاملة، فمثلًا، تعتمد السمات التالية: اسم الطالب StudentName، والعنوان Address، والمدينة City، وProv، وPC -أي الرمز البريدي postal code- على سمة رقم الطالب StudentNo فقط، ولا تعتمد على السمتين StudentNo، وGrade معًا. StudentNo, Course —> StudentName, Address, City, Prov, PC, Grade, DateCompleted هذا الوضع غير مرغوب به لأنه يجب على كل سمة ليست مفتاحًا الاعتماد على المفتاح PK بصورةٍ كاملة، ولكن تعتمد معلومات الطلاب في هذه الحالة جزئيًا فقط على المفتاح الرئيسي PK أي StudentNo. يجب إصلاح هذه المشكلة من خلال تقسيم الجدول الأصلي إلى جدولين على النحو التالي: الجدول الأول 1: يحوي الحقول التالية: StudentNo. Course. Grade. DateCompleted. الجدول الثاني 2: ويحوي الحقول التالية: StudentNo. StudentName. Address. City. Prov. PC. البديهية المتعدية Axiom of transitivity تنص البديهية المتعدِّية على أنه إذا كانت X تحدِّد Y، وY تحدِّد Z، فإنّ X تحدِّد Z أيضًا، أي كما في الشكل التالي: يحتوي الجدول أدناه على معلومات غير مرتبطة مباشرةً بالطالب، فيجب أن يكون لمعرِّف البرنامج ProgramID، واسم البرنامج ProgramName جدولًا خاصًا بهما، حيث لا يعتمد اسم البرنامج على رقم الطالب، وإنما يعتمد على معرِّف البرنامج. StudentNo —> StudentName, Address, City, Prov, PC, ProgramID, ProgramName هذه الحالة غير مرغوب بها بسبب اعتماد السمة التي ليست مفتاحًا -أي ProgramName- على سمة أخرى ليست مفتاحًا أيضًا -أي ProgramID-. نحل هذه المشكلة من خلال تقسيم هذا الجدول إلى جدولين: جدول لمعلومات الطالب، والآخر لمعلومات البرنامج، أي كما يلي: الجدول 1: StudentNo —> StudentName, Address, City, Prov, PC, ProgramID الجدول 2: ProgramID —> ProgramName لكن لا نزال بحاجة إلى مفتاح خارجي FK في جدول الطالب لنتمكن من تحديد البرنامج الذي سُجِّل الطالب به. الاتحاد Union تشير هذه القاعدة إلى أنه إذا كان جدولان منفصلان، والمفتاح الرئيسي PK هو نفسه، فقد ترغب في وضع الجدولين معًا، حيث تنص هذه القاعدة على أنه إذا كانت X تحدِّد Y، وX تحدِّد Z، فيجب على X أن تحدِّد Y وZ أيضًا، أي كما في الشكل التالي: افترض على سبيل المثال أنّ: SIN —> EmpName SIN —> SpouseName قد ترغب في ضم هذين الجدولين في جدول واحد على النحو التالي: SIN –> EmpName, SpouseName قد يختار بعض مسؤولي قاعدة البيانات database administrators -أو DBA اختصارًا- الاحتفاظ بهذه الجداول مفصولةً لسببين، هما: السبب الأول هو أنّ كل جدول يصِف كيانًا مختلفًا، لذلك يجب إبقاء الكيانات منفصلةً عن بعضها البعض، والسبب الثاني هو إذا تُرِك اسم الزوج/ـة SpouseName فارغًا NULL في معظم الأوقات، فلا حاجة إلى تضمينه في نفس جدول اسم الموظّف EmpName. التفكك Decomposition التفكُّك Decomposition هو عكس قاعدة الاتحاد Union، فإذا كان لديك جدولًا يبدو أنه يحتوي على كيانين يحدِّدهما المفتاح الرئيسي PK نفسه، فستفكِّر في تقسيمه إلى جدولين، حيث تنص هذه القاعدة على أنه إذا كانت X تحدِّد Y وZ، فستكون X تحدِّد Y، وX تحدِّد Z بصورةٍ منفصلة، أي كما في الشكل التالي: مخطط الاعتمادية Dependency Diagram يوضِّح مخطط الاعتمادية والمبيَّن في الشكل الآتي العديد من الاعتماديات المختلفة التي قد تكون موجودةً في جدول لم تطبَّقٍ عليه عملية التوحيد non-normalized table، أي الجدول الذي يحتوي على تكرار بيانات. تُحدَّد الاعتماديات التالية في هذا الجدول كما يلي: يتألف المفتاح الأساسي من مجموع ProjectNo وEmpNo. الاعتماديات الجزئية PDs: ProjName <— ProjectNo. EmpName, DeptNo <— EmpNo. HrsWork <— ProjectNo, EmpNo. الاعتمادية المتعددية Transitive Dependency: DeptName <—DeptNo. ترجمة -وبتصرف- للمقال Functional Dependencies لصاحبته Adrienne Watt. اقرأ أيضًا المقال التالي: فهم عملية التوحيد Normalization المستخدمة عند تصميم قاعدة البيانات المقال السابق: نمذجة الكيان العلاقي ER عند تصميم قواعد البيانات قواعد السلامة وقيودها لضمان سلامة البيانات في قواعد البيانات المفاهيم الأساسية في قواعد البيانات وتصميمها النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

تتضمن إحدى النظريات المهمة التي طُوِّرت لنموذج الكيان العلاقي entity relational -واختصارًا ER- فكرة الاعتمادية الوظيفية functional dependency -أو FD اختصارًا-، والهدف من دراستها هو تحسين فهمك للعلاقات بين البيانات، واكتساب المنهجية الكافية للمساعدة في التصميم العملي لقاعدة البيانات. تُستخلَص الاعتماديات الوظيفية FD من دلالات semantics نطاق التطبيق، أي مثل القيود constraints التي شرحناها في المقال السابق، وتصِف كيفية ارتباط السمات المنفصلة individual attributes ببعضها البعض، كما تُعَدّ الاعتماديات الوظيفية FD نوعًا من القيود بين السمات داخل علاقة، وتساهم في تصميم مخطط علاقي جيد، حيث سنلقي في هذا المقال نظرةً على: نظرية الاعتمادية الوظيفية الأساسية وتعريفها. منهجية تحسين تصميمات المخططات، وتسمى أيضًا التوحيد normalization. التصميم العلاقي Relational Design والتكرار Redundancy يجب احتواء التصميم الجيد لقاعدة البيانات العلاقية على جميع السمات والارتباطات الضرورية، حيث يجب أن يقوم التصميم بذلك بأقل قدرٍ ممكن من المعلومات المخزَّنة مع عدم وجود بيانات مكرَّرة redundant. يُعَدّ التكرار أمرًا غير مرغوب فيه في تصميم قاعدة البيانات، وذلك لأنه يسبب مشاكلًا في الحفاظ على التناسق بعد التحديثات، لكن يمكن أن يؤدي التكرار إلى تحسينات في الأداء في بعض الأحيان مثل إمكانية استخدام التكرار بدلًا من عملية الضم join لربط البيانات، حيث تُستخدَم عملية الضم join عند الحاجة إلى الحصول على معلومات تستند إلى جدولين مرتبطين. ضع في بالك الشكل الآتي الذي يوضِّح مثالًا عن التكرار المُستخدَم في الحسابات المصرفية Bank Accounts، وفروع المصرف Branches، حيث يَظهر العميل رقم 1313131 مرتين، أي مرةً للحساب ذو الرقم A-101، ومرةً أخرى للحساب رقم A-102؛ إذ لا يكون رقم العميل زائدًا في هذه الحالة على الرغم من وجود حالات حذفٍ شاذة deletion anomalies في الجدول، وسيحل هذه المشكلة وجود جدول منفصل للعملاء. إذا تغير عنوان الفرع branch address، فيجب تحديثه في أماكن متعددة، وإذا تُرِك رقم العميل في الجدول كما هو، فلن تحتاج إلى جدول للفرع branch، ولن تكون هناك حاجة إلى عملية ضم، وبالتالي، سيتحسّن الأداء. table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } accountNo blance customer branch address assets A-101 500 1313131 Downtown Brooklyn 9000000 A-102 400 1313131 Perryridge Horseneck 1700000 A-113 600 9876543 Round Hill Horseneck 8000000 A-201 900 9676543 brighton Brooklyn 7100000 A-215 700 1111111 Manus Horseneck 400000 A-222 700 1111111 Redwood Palo Alto 2100000 A-305 350 1234567 Round Hill Horseneck 8000000 التعديلات الشاذة على جداول قاعدة البيانات سنعرض أشهر الحالات الشاذة التي تحدث نتيجة إجراء تعديلات من إدخل أو تعديل أو حذف على قاعدة البيانات كما سنضرب مثالًا لذلك. حالة الإدخال الشاذة Insertion Anomaly تحدث هذه الحالة عند إدخال معلومات متضاربة في جدول، حيث نحتاج إلى التحقق من أن بيانات الفرع branch متوافقة مع الصفوف الموجودة عندما ندخل سجلًا جديدًا مثل رقم الحساب A-306، كما في الشكل التالي: accountNo blance customer branch address assets A-101 500 1313131 Downtown Brooklyn 9000000 A-102 400 1313131 Perryridge Horseneck 1700000 A-113 600 9876543 Round Hill Horseneck 8000000 A-201 900 9676543 brighton Brooklyn 7100000 A-215 700 1111111 Manus Horseneck 400000 A-222 700 1111111 Redwood Palo Alto 2100000 A-305 350 1234567 Round Hill Horseneck 8000000 حالة التحديث الشاذة Update Anomaly إذا غيّر أحد فروع المصرف عنوانه مثل الفرع راوند هيل Round Hill في الشكل الآتي، فنحن بحاجة إلى تحديث جميع الصفوف التي تشير إلى هذا الفرع، حيث يسمّى تغيير المعلومات الموجودة بصورة غير صحيحة بحالة تحديث شاذة. accountNo blance customer branch address assets A-101 500 1313131 Downtown Brooklyn 9000000 A-102 400 1313131 Perryridge Horseneck 1700000 A-113 600 9876543 Round Hill Horseneck 8000000 A-201 900 9676543 brighton Brooklyn 7100000 A-215 700 1111111 Manus Horseneck 400000 A-222 700 1111111 Redwood Palo Alto 2100000 A-305 350 1234567 Round Hill Horseneck 8000000 A-306 800 1111111 Round Hill Horseneck 8000800 حالة الحذف الشاذة Deletion Anomaly تحدث هذه الحالة عند حذف سجل قد يحتوي على سمات لا ينبغي حذفها، إذا أزلنا معلومات حول الحساب الأخير في أحد الفروع، مثل الحساب رقم A-101 في الفرع داون تاون Downtown في الشكل التالي على سبيل المثال، فستختفي جميع معلومات ذلك الفرع. accountNo blance customer branch address assets A-101 500 1313131 Downtown Brooklyn 9000000 A-102 400 1313131 Perryridge Horseneck 1700000 A-113 600 9876543 Round Hill Horseneck 8000000 A-201 900 9676543 brighton Brooklyn 7100000 A-215 700 1111111 Manus Horseneck 400000 A-222 700 1111111 Redwood Palo Alto 2100000 A-305 350 1234567 Round Hill Horseneck 8000000 مشكلة حذف الصف A-101 هي عدم معرفتنا مكان الفرع Downtown، وأننا سنفقد جميع المعلومات المتعلقة بالعميل 1313131. نحتاج إلى تفكيك الجدول الأصلي إلى جداول أصغر متعددة بحيث يكون لكل جدول حدًا أدنى من التداخل مع الجداول الأخرى، وذلك لتجنب هذه الأنواع من مشاكل التحديث أو الحذف. يجب احتواء كل جدول حساب مصرفي على معلومات حول كيان entity واحد فقط، مثل: الفرع Branch، أو العميل Customer، كما هو موضح في الشكل التالي: سيضمن اتباع هذه العملية أن إضافة معلومات الفرع أو تحديثها سيؤثر على سجل واحد فقط، لذلك لن تعدَّل معلومات الفرع عن طريق الخطأ، ولن تُسجَّل بصورة غير صحيحة، عند إضافة معلومات العميل أو حذفها. مثال تطبيقي عن جدول مشروع-موظف والحالات الشاذة يوضِّح الشكل الآتي مثالًا لجدول مشروع-موظف employee project table، كما يمكننا الافتراض من هذا الجدول أن: معرِّف الموظف EmpID، ومعرِّف المشروع ProjectID هما مفتاح رئيسي مركَّب composite PK. يحدد معرِّف المشروع الميزانية Budget، أي أنّ للمشروع P1 ميزانيةً لفترة 32 ساعة. EmpID Budget ProjectID Hours S75 32 P1 7 S75 40 P2 3 S79 32 P1 4 S79 27 P3 1 S80 40 P2 5 17 P4 فيما يلي بعض الحالات الشاذة anomalies المحتملة التي قد تحدث مع هذا الجدول خلال الخطوات التالية: الإجراء: إضافة الصف Add row الذي هو {S85,35,P1,9}. المشكلة: هناك صفان tuples بميزانيات متضاربة. الإجراء: حذف الصف Delete tuple الذي هو {S79, 27, P3, 1}. المشكلة: الخطوة رقم 3 تحذف ميزانية المشروع P3. الإجراء: تحديث الصف Update tuple من {S75, 32, P1, 7} إلى {S75, 35, P1, 7}. المشكلة: تُنشِئ الخطوة رقم 5 صفَّين بقيم مختلفة لميزانية المشروع P1. الحل: إنشاء جدول منفصل separate table لكل من المشاريع Projects والموظفين Employees، أي كما هو موضَّح في الشكل التالي: كيفية تجنب الحالات الشاذة أفضل طريقة لإنشاء جداول بدون حالات شاذة هي التأكد من توحيد الجداول، ويتحقق ذلك من خلال فهم الاعتماديات الوظيفية، حيث تضمن الاعتمادية الوظيفية FD في جدول انتماء جميع السمات attributes إلى هذا الجدول، أي ستزيل التكرار والحالات الشاذة. مثال تطبيقي: جدولا المشاريع والموظفين المنفصلان ProjectID Budeget P1 32 P2 40 P3 27 P4 17 جدول المشروع Project Emp ID Project ID Hours S75 P1 7 S75 P2 3 S79 P1 4 S79 P3 1 S80 P2 5 جدول الموظف Employee يكون من خلال الاحتفاظ بالبيانات منفصلة باستخدام جدول مشاريع وجدول موظفين ما يلي: لن تُنشَأ حالات شاذة إذا تغيرت الميزانية. ليست هناك حاجة إلى قيم وهمية للمشاريع التي لم يُعيَّن لها موظفون. إذا حُذِفت مساهمة موظف ما، فلن تُفقَد بيانات مهمة. لن تُنشَأ حالات شاذة إذا أُضيفت مساهمة موظف. تمارين أولًا، طبِّق التوحيد normalization على الشكل التالي: Attribute Name Sample Value Sample Value Sample Value StudentID 1 2 3 StudentName John Smith Sandy Law Sue Rogers CourselD 2 2 3 CourseName Programming Level 1 Programming Level 1 Business Grade 75% 61% 81% CourseDate Jan 5th, 2014 Jan 5th, 2014 Jan 7th, 2014 ثانيًا، أنشِئ مخطط ERD منطقي لخدمة تأجير الأفلام عبر الإنترنت، حيث لا توجد علاقات من النوع متعدد إلى متعدد many to many، واستخدم الوصف التالي للعمليات التي يجب أن تستند عليها قواعد عملك: تُصنِّف خدمة تأجير الأفلام عبر الإنترنت عناوين الأفلام وفقًا لنوعها إلى: الأفلام الكوميدية comedy، وأفلام الغرب الأمريكي western، والأفلام الكلاسيكية classical، وأفلام الخيال العلمي science fiction، وأفلام الرسوم المتحركة cartoon، وأفلام الحركة action، والأفلام الموسيقية musical، والأفلام المصدرة حديثًا new release. يحتوي كل نوع على العديد من العناوين المحتملة، وتتوفر نسخ copies متعددة لمعظم العناوين داخل النوع، فمثلًا، لاحظ الملخَّص التالي: TYPE TITLE Musical My Fair Lady (Copy 1) My Fair Lady (Copy 2) Oklahoma (Copy 1) Oklahoma (Copy 2) Oklahoma (Copy 3) ثالثًا، ما هي الحالات الشاذة الثلاثة للبيانات التي من المحتمل تَشكّلها نتيجةً لتكرار البيانات؟ وكيف يمكن القضاء على مثل هذه الحالات الشاذة؟ وسنتطرق في مقال لاحق لمثال عملي حول تصميم قاعدة بيانات كاملة من الصفر مثل تدريب عملي. ترجمة -وبتصرف- للمقال ER Modelling لصاحبته Adrienne Watt من كتاب Database Design. اقرأ أيضًا المقال التالي: الاعتماديات الوظيفية المستخدمة في تصميم قواعد البيانات المقال السابق: قواعد السلامة وقيودها لضمان سلامة البيانات في قواعد البيانات نموذج الكيان والعلاقة ER لتمثيل البيانات وتخزينها في قاعدة البيانات المفاهيم الأساسية في قواعد البيانات وتصميمها النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

تُعَدّ القيود Constraints ميزةً مهمةً جدًا في النموذج العلائقي relational model الذي يدعم نظريةً محددةً للقيود المُطبَّقة على السِمات attributes أو الجداول tables، كما تُعَدّ هذه القيود مفيدةً بسبب سماحها لمصمم قواعد البيانات بتحديد دلالات semantics البيانات، فهذه القيود هي القواعد التي تجبر نظم إدارة قواعد البيانات Database management systems -أو DBMSs اختصارًا- على التحقق من توافق البيانات مع هذه الدلالات. سلامة النطاق Domain Integrity يُعَدّ النطاق قيدًا من قيود النموذج العلائقي، حيث يُقيّد قيم السمات في العلاقة، لكن هناك دلالات واقعية للبيانات التي لا يمكن تحديدها إذا اُستخدِمت مع قيود النطاق فقط، لذلك نحتاج إلى طرقٍ أكثر تحديدًا لبيان قيم البيانات المسموح بها أو غير المسموح بها والتنسيق المناسب لكل سمة، فمثلًا، يجب أن يكون معرّف الموظف Employee ID -أو EID اختصارًا- في قاعدة البيانات فريدًا، أو يجب أن يكون تاريخ ميلاد الموظف Birthdate ضمن المجال [Jan 1, 1950, Jan 1, 2000]، حيث توفَّر هذه المعلومات ضمن تعليمات منطقية تسمى قيود السلامة integrity constraints، ويوجد عدة أنواع من قيود السلامة كما هو موضَّح أدناه. سلامة الكيان Entity integrity يجب احتواء كل جدول على مفتاح رئيسي primary key لضمان سلامة الكيان، ولا يمكن احتواء المفتاح الرئيسي PK أو أي جزء منه على قيم فارغة null، حيث لا يمكننا تحديد بعض الصفوف rows عندما تكون قيم المفتاح الرئيسي فارغة، فمثلًا، لا يمكن أن يكون الهاتف Phone في جدول الموظف EMPLOYEE مفتاحًا رئيسيًا نظرًا لعدم امتلاك بعض الأشخاص أيّ هاتف. السلامة المرجعية Referential integrity تتطلب السلامة المرجعية وجود مفتاح رئيسي مقابل للمفتاح الخارجي foreign key، وإلا فيجب أن يكون فارغًا. يُحدَّد هذا القيد بين جدولين أي الجدول الأب والجدول الابن؛ حيث يحافِظ على المطابقة بين الصفوف في هذين الجدولَين، وهذا يعني أن المرجع من صفٍ في جدول إلى جدول آخر يجب أن يكون صالحًا، وفيما يلي مثال على قيود السلامة المرجعية في قاعدة بيانات العملاء/الطلبات Customer/Order الخاصة بالشركة Company: جدول العميل Customer يحوي الحقلين التاليين: CustID رقم العميل. CustName اسم العميل. جدول الطلب Order يحوي الحقول التالية: OrderID رقم الطلب. CustID رقم العميل. Date تاريخ الطلب. يجب فرض السلامة المرجعية لضمان عدم وجود سجلات معزولة أو يتيمة orphan records، فالسجل المعزول هو السجل الذي تكون قيمة مفتاحه الخارجي FK غير موجودة في الكيان المقابل -أي الكيان الذي يحوي المفتاح الرئيسي PK، وتذكّر أنّ عملية الضم join تكون بين المفتاحَين الرئيسي PK والخارجي FK. ينص قيد السلامة المرجعية في المثال السابق على وجوب تطابق CustID في جدول الطلبات Order مع CustID صالح في جدول العملاء Customer. تملك معظم قواعد البيانات العلائقية سلامة مرجعية تصريحية declarative referential integrity، أي يجري إعداد قيود السلامة المرجعية عند إنشاء الجداول. وفيما يلي مثال آخر على قاعدة بيانات صفوف دراسية/مقرَّرات Course/Class: جدول الدورة التدريبية Course يحوي الحقول التالي: CrsCode رمز الدورة. DeptCode رمز القسم. Description وصف الدورة. جدول الصف Class يحوي الحقول التالية: CrsCode رمز الدورة. Section القسم. ClassTime وقت الصف. ينص قيد السلامة المرجعية هنا على وجوب تطابق المفتاح الخارجي CrsCode في جدول Class مع مفتاح رئيسي CrsCode صالح في جدول Course، حيث لا يكفي في هذه الحالة أن تشكِّل السمتان CrsCode و Section في جدول Class المفتاح الرئيسي PK، إذ يجب علينا فرض السلامة المرجعية أيضًا. يجب امتلاك المفتاح الرئيسي PK والمفتاح الخارجي FK أنواع البيانات نفسها، كما يجب أن يأتيا من نفس النطاق عند إعداد السلامة المرجعية، وإلا فلن يسمح نظام إدارة قاعدة البيانات العلائقية RDBMS بعملية الضم join. يُعَدّ نظام RDBMS نظام قاعدة بيانات شائع، حيث يعتمد على النموذج العلائقي الذي قدمه إدجار كود E.F. Codd من مختبر أبحاث سان خوسيه San Jose التابع لشركة IBM، كما تُعَدّ أنظمة قواعد البيانات العلائقية أسهل في الاستخدام والفهم من أنظمة قواعد البيانات الأخرى. السلامة المرجعية في نظام مايكروسوفت أكسس Microsoft Access يجري إعداد السلامة المرجعية في نظام مايكروسوفت أكسس MS Acces من خلال ضم المفتاح الرئيسي PK الذي هو معرّف العميل CustID في جدول العملاء إلى معرّف العميل CustID في جدول الطلبات Order، ويوضِّح الشكل التالي طريقة عمل ذلك على شاشة تحرير العلاقات Edit Relationships في نظام مايكروسوفت أكسس: السلامة المرجعية باستخدام الإصدار Transact-SQL من لغة SQL تُضبَط السلامة المرجعية في الإصدار Transact-SQL (اختصارها T-SQL) المستخدمة في خادم MS SQL Server عند إنشاء جدول الطلبات Order باستخدام المفتاح الخارجي FK، حيث تُظهِر التعليمات المدرجة أدناه المفتاح الخارجي FK في جدول الطلبات Order الذي يكون مرجعًا إلى المفتاح الرئيسي PK في جدول العملاء Customer: CREATE TABLE Customer ( CustID INTEGER PRIMARY KEY, CustName CHAR(35) ) CREATE TABLE Orders ( OrderID INTEGER PRIMARY KEY, CustID INTEGER REFERENCES Customer(CustID), OrderDate DATETIME ) قواعد المفاتيح الخارجية يمكن إضافة قواعد مفاتيح خارجية إضافية عند ضبط السلامة المرجعية مثل ما نفعله بالصفوف الأبناء -في جدول Orders- عندما يُحذَف أو يُغيَّر -أي يُحدَّث- السجل وهو جزء من الجدول الأب -Customer- والذي يملك مفتاحًا رئيسيًا PK، فمثلًا، تَعرض نافذة تحرير العلاقات في MS Access في الشكل السابق خيارين إضافيين لقواعد المفتاح الخارجي FK، هما: التحديث المتسلسل أو التعاقبي Cascade Update، والحذف المتسلسل Cascade Delete، فإذا لم يُحدَّد هذان الخياران، فسيمنع النظام حذف أو تحديث قيم المفتاح الرئيسي PK في جدول الأب -أي جدول العملاء Customer- في حالة وجود سجل ابن، فالسجل الابن هو أي سجل مع مفتاح رئيسي PK مطابق. يوجد خيار إضافي في بعض قواعد البيانات عند تحديد خيار الحذف ويسمى Set to Null، حيث يُحذَف صف المفتاح الرئيسي PK في هذا الاختيار، ولكن يُضبَط المفتاح الخارجي FK في الجدول الابن على القيمة الفارغة NULL، فعلى الرغم من أنّ هذا يؤدي إلى إنشاء صف يتيم، إلا أنه أمر مقبول. قيود المؤسسة Enterprise Constraints يشار إلى قيود المؤسسة أحيانًا بالقيود الدلالية semantic constraints، وهي قواعد إضافية يحددها المستخدمون أو مسؤولو قاعدة البيانات، كما يمكنها الاستناد إلى جداول متعددة، وفيما يلي بعض الأمثلة عنها: يمكن للصف الدراسي class ضم ثلاثين طالبًا على أساس حد أقصى. يمكن للمدرّس teacher تدريس أربعة صفوف في الفصل الواحد على أساس حد أقصى. لا يمكن للموظف employee المشاركة في أكثر من خمسة مشاريع. لا يمكن لراتب الموظف تجاوز راتب مديره. قواعد العمل Business Rules نحصل على قواعد العمل من المستخدِمين عند جمع المتطلبات gathering requirements، كما تُعَدّ عملية جمع المتطلبات عمليةً مهمةً للغاية، ويجب على المستخدِم أن يتحقق من نتائجها قبل بناء تصميم قاعدة البيانات، فإذا كانت قواعد العمل غير صحيحة، فسيكون التصميم غير صحيح، وفي النهاية لن يعمل التطبيق على النحو الذي توقّعه المستخدِمون، وفيما يلي بعض الأمثلة عن قواعد العمل، وهي: يمكن للمدرّس تدريس طلاب متعددين. يمكن للصف الدراسي امتلاك 35 طالبًا على أساس حد أقصى. يمكن تدريس المُقرَّر course عدة مرات، ولكن يدرِّسه مدرِّس واحد فقط. لا يدرّس جميع المدرِّسين صفوفًا دراسية. تعددية العلاقة Cardinality والارتباط connectivity تُستخدَم قواعد العمل لتحديد عددية العلاقة والارتباط، حيث تصف نعددية العلاقة Cardinality العلاقة بين جدولي بيانات من خلال التعبير عن الحد الأدنى والحد الأقصى لعدد مرات حدوث الكيان المرتبط بحدوث كيانٍ آخر ذي صلة، ويمكّنك الشكل التالي من رؤية أن عددية العلاقة ممثَّلة من خلال العلامات الداخلية على رمز العلاقة، حيث تكون درجة العلاقة Cardinality هي 0 على اليمين و1 على اليسار. يمثل الرمز الخارجي لرمز العلاقة الارتباط Connectivity بين الجدولين، فالارتباط هو العلاقة بين جدولين مثل علاقة واحد إلى واحد one to one، أو واحد إلى متعدد one to many؛ والمرة الوحيدة التي يكون فيها الارتباط صفرًا هي عندما يكون للمفتاح الخارجي FK قيمة فارغة null. يوجد ثلاثة خيارات للعلاقة بين هذه الكيانات عندما يتعلق الأمر بالمشاركة، وهي: 0، أو 1، أو متعدد many، فمثلًا، قيمة الارتباط Connectivity هي 1 في الشكل السابق على الجانب الخارجي الأيسر من هذا الخط، ومتعدد على الجانب الخارجي الأيمن. يظهر الشكل التالي الرمز الذي يمثل علاقة واحد إلى متعدد one to many: يعرض الشكل الآتي كلًا من العلامات الداخلية -التي تمثل عددية العلاقة Cardinality -والعلامات الخارجية -التي تمثل الارتباط Connectivity-، حيث يُقرأ الجانب الأيسر من هذا الرمز على أن الحد الأدنى 1 والحد الأقصى 1، بينما يُقرأ الجانب الأيمن على النحو التالي: الحد الأدنى 1 والحد الأقصى متعدد. أنواع العلاقات يشير السطر الذي يربط جدولين في مخطط الكيان والعلاقة entity relationship diagram -أو ERD اختصارًا- إلى نوع العلاقة بين الجدولين؛ فهي إما وثيقة أو معرَّفة identifying أو غير وثيقة non-identifying. العلاقة الوثيقة هي خط متصل بحيث يحتوي المفتاح الرئيسي PK على المفتاح الخارجي FK، كما يشار إلى العلاقة الغير وثيقة بخط متقطع مع عدم وجود المفتاح الخارجي FK ضمن المفتاح الرئيسي PK. العلاقات الاختيارية يمكن أن يكون للمفتاح الخارجي FK قيمةً فارغةً في العلاقة الاختيارية أو لا يحتاج الجدول الأب إلى وجود جدول ابن مطابق. يوضح الرمز المبيَّن في الشكل نوعًا مكوَّنًا من صفر وثلاث بروزات -تشير إلى متعدد- والذي يُفسَّر على أنه علاقة صفر أو متعدد zero OR many، وإذا نظرت إلى جدول الطلبات Order table على الجانب الأيمن من الشكل الآتي على سبيل المثال، فستلاحظ عدم حاجة العميل customer إلى تقديم طلب ليكون عميلًا، أي أن الجانب المتعدد اختياري، ويوضِّح الشكل التالي المثال السابق عن كيفية استخدام رمز العلاقة الاختيارية صفر إلى متعدد zero to many: يمكن أيضًا قراءة رمز العلاقة في الشكل السابق على النحو التالي: الجانب الأيسر: يجب احتواء كيان الطلب order entity على كيان واحد مرتبط على أساس حد أدنى في جدول العميل Customer table، وكيان واحد مرتبط على أساس حد أقصى. الجانب الأيمن: يمكن للعميل عدم تقديم طلبات (أي صفر طلب) على أساس حد أدنى، أو تقديم طلبات متعددة على أساس حد أقصى. يوضِّح الشكل نوعًا آخرًا من رموز العلاقة الاختيارية بصفر وواحد، أي علاقة صفر أو واحد zero OR one، حيث جانب الواحد اختياري، ويوضِّح الشكل التالي مثالًا عن كيفية استخدام رمز العلاقة الاختيارية صفر إلى واحد zero to one: العلاقات الإلزامية Mandatory relationships يتطلب حدوث كيان واحد حدوث كيان مقابل في العلاقة الإلزامية. يُظهِر رمز هذه العلاقة علاقة واحد فقط one and only one كما هو موضح في الشكل ، أي أن الجانب واحد one side إلزامي، ويوضِّح الشكل التالي مثالًا عن كيفية استخدام رمز العلاقة الإلزامية واحد فقط one and only one: يوضِّح الشكل رمز علاقة واحد إلى متعدد one to many حيث يكون الجانب المتعدد many side إلزاميًا. ويوضِّح الشكل التالي مثالًا عن كيفية استخدام رمز العلاقة الإلزامية واحد إلى متعدد: رأينا حتى الآن أن الجانب الداخلي من رمز العلاقة الموضَّح على الجانب الأيسر من الرمز في الشكل الآتي يمكن أن يكون له تعددية العلاقة cardinality قيمتها 0 وارتباط connectivity متعدد كما هو موضَّح على الجانب الأيمن من الرمز في الشكل ، أو ارتباط قيمته واحد وهو غير موضَّح في الشكل. لا يمكن أن يكون لديه ارتباط قيمته 0، كما هو موضَّح في الشكل ، حيث يمكن أن يكون الارتباط 1 فقط. تُظهِر رموز الارتباط الحدود القصوى، فإذا أظهر رمز الارتباط على الجانب الأيسر القيمة 0، فلن يكون هناك ارتباط بين الجداول، وفيما يلي طريقة قراءة رمز العلاقة مثل الرمز الموجود في الشكل الآتي: يجب العثور على معرِّف العميل CustID في جدول الطلبات Order table وفي جدول العملاء Customer table أيضًا بحد أدنى 0 وبحد أقصى 1 مرة. تعني القيمة 0 أن معرِّف العميل CustID في جدول الطلبات Order table قد تكون قيمته فارغة null. تشير القيمة 1 الموجودة أقصى اليسار -أي قبل القيمة 0 مباشرةً التي تمثل الارتباط- إلى أنه إذا كان هناك معرِّف عميل CustID في جدول الطلبات Order table، فيمكن وجود هذا المعرِّف في جدول العملاء Customer table مرةً واحدةً فقط. يمكنك افتراض شيئين عندما ترى الرمز 0 لتعددية العلاقة cardinality: يسمح المفتاح الخارجي FK في جدول الطلبات Order table بوجود القيم الفارغة. ليس المفتاح الخارجي FK جزءًا من المفتاح الرئيسي PK، لأنه يجب ألا تحتوي المفاتيح الرئيسية على قيم فارغة null. تمارين اقرأ الوصف التالي ثم أجب عن الأسئلة: صُمِّمت قاعدة بيانات نادي السباحة في الشكل الآتي لتحتوي على معلومات حول الطلاب students المسجَلين enrolled في صفوف السباحة، حيث خُزِّنت المعلومات التالية: الطلاب students، والتسجيل enrollment، وصفوف السباحة swim classes، والمسابح pools التي تقام فيها الصفوف، ومدربو instructors صفوف السباحة، والمستويات levels المختلفة من صفوف السباحة. استخدم الشكل التالي للإجابة على الأسئلة: حُدِّدت المفاتيح الرئيسية primary keys أدناه، وعُرِّفت أنواع البيانات التالية في خادم SQL Server. **tblLevels** Level – Identity PK ClassName – text 20 – nulls are not allowed **tblPool** Pool – Identity PK PoolName – text 20 – nulls are not allowed Location – text 30 **tblStaff** StaffID – Identity PK FirstName – text 20 MiddleInitial – text 3 LastName – text 30 Suffix – text 3 Salaried – Bit PayAmount – money **tblClasses** LessonIndex – Identity PK Level – Integer FK SectionID – Integer Semester – TinyInt Days – text 20 Time – datetime (formatted for time) Pool – Integer FK Instructor – Integer FK Limit – TinyInt Enrolled – TinyInt Price – money **tblEnrollment** LessonIndex – Integer FK SID – Integer FK (LessonIndex and SID) Primary Key Status – text 30 Charged – bit AmountPaid – money DateEnrolled – datetime **tblStudents** SID – Identity PK FirstName – text 20 MiddleInitial – text 3 LastName – text 30 Suffix – text 3 Birthday – datetime LocalStreet – text 30 LocalCity – text 20 LocalPostalCode – text 6 LocalPhone – text 10 طبّق هذا المخطط في خادم SQL Server، أو باستخدام نظام access وعندها ستحتاج إلى اختيار أنواع بيانات قابلة للموازنة. اشرح قواعد العلاقة relationship rules لكل علاقة مثل العلاقة بين الجدولين tblEnrollment وtblStudents التي تمثِّل إمكانية تسجيل الطالب في صفوف سباحة متعددة. حدّد عددية cardinality كل علاقة بافتراض القواعد التالية: قد يكون أو لا يكون للمسبح pool صفًا class للسباحة. يجب ارتباط جدول المستويات levels table دائمًا بصف سباحة واحد على الأقل. قد لا يدرِّس جدول فريق التدريب staff table أيَّ صف سباحة. يجب تسجيل جميع الطلاب في صف سباحة واحد على الأقل. يجب احتواء صف السباحة على طلاب مسجلين فيه. يجب امتلاك صف السباحة على مسبح صالح. قد لا يُعيَّن مدرب لصف السباحة. يجب ارتباط صف السباحة دائمًا بمستوى موجود. حدّد الجداول الضعيفة، والجداول القوية التي شرحناها في مقالٍ سابق. حدّد الجداول المُعرَّفة identifying، والجداول غير المُعرَّفة non-identifying. ترجمة -وبتصرف- للفصل Integrity Rules and Constraints لصاحبَيه Adrienne Watt و Nelson Eng من كتاب Database Design. اقرأ أيضًا المقال التالي: نمذجة الكيان العلاقي ER عند تصميم قواعد البيانات المقال السابق: نموذج الكيان والعلاقة ER لتمثيل البيانات وتخزينها في قاعدة البيانات النسخة العربية الكاملة لكتاب تصميم قواعد البيانات خصائص قواعد البيانات والمزايا التي تقدمها

ظهر نموذج الكيان والعلاقة entity relationship - أو ER اختصارًا- لتمثيل البيانات منذ أكثر من 35 عام، وهو مناسب تمامًا لنمذجة البيانات للاستخدام مع قواعد البيانات، وذلك لأنه ذو طبيعة مجردة إلى حد ما، وسهل المناقشة والشرح. تترجم نماذج الكيان والعلاقة للبيانات إلى علاقات بسهولة، كما تسمى تخطيط الكيان والعلاقة ER schema، حيث تُمثَّل بواسطة مخططات الكيان والعلاقة ER diagrams. تعتمد عملية إنشاء نماذج الكيان والعلاقة للبيانات ER modelling على مفهومين هما: الكيانات Entities: وتُعرَّف على أنها الجداول التي تحتوي على معلومات خاصّة -أي بيانات-. العلاقات Relationships: وتُعرَّف على أنها الارتباطات أو التفاعلات بين الكيانات. فيما يلي مثال على كيفية دمج هذين المفهومين في نموذج الكيان والعلاقة: يكون في قولنا "يدرِّس البروفيسور دورة أنظمة قواعد البيانات" الكيان هو كل من البروفيسور، ودورة أنظمة قواعد البيانات؛ أما العلاقة فهي كلمة يدرِّس. سنستخدم في هذا المقال قاعدة بيانات تسمى الشركة COMPANY لتوضيح مفاهيم نموذج الكيان والعلاقة، حيث تحتوي على معلومات حول الموظفين employees، والأقسام departments، والمشاريع projects، كما يجب ملاحظة النقاط التالية: هناك عدة أقسام في الشركة، ولكل منها قسم مُعرِّف فريد، واسم، وموقع المكتب، وموظف معين يدير القسم. يتحكم القسم في عدد من المشاريع، ولكل منها اسم فريد، ورقم فريد، وميزانية. كل موظف له اسم، ورقم تعريف، وعنوان، وراتب، وتاريخ ميلاد، كما يُعيَّن الموظف في قسم واحد، ويمكنه الانضمام لعدة مشاريع، كما نحتاج إلى تسجيل تاريخ بدء الموظف في كل مشروع، ومعرفة المشرف المباشر لكل موظف. نريد تتبّع المُعالِين لكل موظف، حيث يملك كل مُعال اسم، وتاريخ ميلاد، وعلاقته بالموظف. دورة علوم الحاسوب دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب اشترك الآن الكيان ومجموعة الكيان ونوع الكيان الكيان entity هو كائن في العالم الحقيقي له وجود مستقل، كما يمكن تمييزه عن الكائنات الأخرى، وقد يكون هذا الكيان: كائن له وجود مادي physical existence، مثل: محاضر، وطالب، وسيارة. كائن له وجود مفاهيمي conceptual existence، مثل دورة، ووظيفة، ومنصب. يمكن تصنيف الكيانات بناءً على قوتها، حيث يُعَدّ الكيان ضعيفًا في الحالات التالية: وجوده غير ممكن بدون علاقة مع كيان آخر. مفتاحه الرئيسي مشتق من المفتاح الرئيسي للكيان الأب. يُعَدّ جدول الزوج Spouse في قاعدة بيانات الشركة كيانًا ضعيفًا لأن مفتاحه الرئيسي يعتمد على جدول الموظف، أي لن يكون سجل الزوج موجودًا إذا لم يتواجد سجل الموظف المقابل. يُعَدّ الكيان قويًا إذا كان يمكن أن يوجد مستقلًا عن جميع الكيانات المرتبطة به. الأنوية Kernels هي كيانات قوية. يُعَدّ الجدول كيانًا قويًا إذا لم يحتوي على مفتاح خارجي foreign key، أو إذا احتوى على مفتاح خارجي يقبل القيم الفارغة null. يجب معرفة مصطلح آخر، وهو نوع الكيان entity type الذي يحدِّد تجميعةً من الكيانات المتشابهة، كما تُعَدّ مجموعة الكيان entity set تجميعةً من نوع الكيان entity type في وقت معيَّن. يُمثَّل نوع الكيان في مخطط الكيان والعلاقة entity relationship diagram -أي ERD اختصارًا- في صندوق، فمثلًا، نوع الكيان في الشكل التالي هو موظف EMPLOYEE. الشكل 1: نوع الكيان هو الموظف ارتباط الوجود يعتمد وجود الكيان على وجود الكيانات ذات الصلة به، ويُعَدّ الكيان ارتباطي الوجود Existence dependency إذا كان يحتوي على مفتاح خارجي إلزامي -أي سمة مفتاح خارجي لا يمكن أن تكون فارغة null-، فمثلًا، يكون في قاعدة بيانات الشركة COMPANY كيان الزوج Spouse معتمدًا على وجود كيان الموظف. أنواع الكيانات يجب أيضًا أن تكون على دراية بأنواع الكيانات المختلفة بما في ذلك الكيانات المستقلة independent entities، والكيانات المعتمِدة dependent entities، والكيانات المميَّزة characteristic entities. الكيانات المستقلة تُعَدّ الكيانات المستقلة Independent entities -والتي يشار إليها أيضًا باسم الأنوية kernels- العمود الفقري لقاعدة البيانات، إذ تستند عليه الجداول الأخرى، ولها الخصائص التالية: هم اللبنات الأساسية لقاعدة البيانات. قد يكون المفتاح الرئيسي primary key بسيطًا، أو مركبًا. لا يمكن أن يكون المفتاح الرئيسي مفتاحًا خارجيًا. لا تعتمد على أي كيان آخر في وجودها. إذا عدنا إلى قاعدة بيانات الشركة COMPANY الخاصة بنا، فتتضمن أمثلة الكيانات المستقلة جدول العميل Customer table، أو جدول الموظف Employee table، أو جدول المنتَج Product table. الكيانات المعتمِدة تستند الكيانات المعتمِدة Dependent entities - والتي يشار إليها باسم الكيانات المشتقة derived entities أيضًا- على جداول أخرى حتى يكون لها معنى، ولها الخصائص التالية: تُستخدَم الكيانات المعتمِدة لربط نواتين معًا. يَعتمد وجودها على وجود جدولين أو أكثر في قاعدة البيانات، حيث لا يمكن وجود كيانات معتمِدة في قاعدة بيانات تحتوي على جدول واحد فقط. تُنشِئ علاقات (متعدد إلى متعدد) جداول ترابطية associative tables بمفتاحين خارجيين على الأقل. قد تحتوي على سمات أخرى. يحدِّد كل مفتاح خارجي جدولًا مرتبطًا بالكيان نفسه. هناك ثلاثة خيارات للمفتاح الرئيسي: استخدِم مزيجًا من المفاتيح الخارجية للجداول المرتبطة إذا كانت فريدة. استخدِم مزيجًا من المفاتيح الخارجية وعمودًا مؤهِلًا. أنشِئ مفتاح رئيسي بسيط جديد. الكيانات المتميزة توفر الكيانات المميَّزة Characteristic entities مزيدًا من المعلومات حول جدول آخر، ولهذه الكيانات الخصائص التالية: تمثِّل سمات متعددة القيم. تصِف كيانات أخرى. عادة ما يكون لديها علاقة علاقة واحد إلى متعدِّد one to many relationship. يُستخدَم المفتاح الخارجي foreign key لتحديد الجدول المميز characterized table. خيارات المفتاح الرئيسي هي: استخدِم مزيجًا من المفاتيح الخارجية وعمودًا مؤهِلًا. أنشِئ مفتاحًا رئيسيًا بسيطًا جديدًا في قاعدة بيانات الشركة COMPANY، والتي قد تشمل: جدول الموظف Employee (المعرف EID، الاسم، العنوان، العمر، الراتب) - EID هو المفتاح الرئيسي البسيط. جدول هاتف الموظف EmployeePhone (معرف الموظف EID، رقم الهاتف)، EID هنا هو جزء من مفتاح رئيسي مركب، وهو مفتاح خارجي مرتبط بجدول الموظف السابق. السمات يوصَف كل كيان بمجموعة من السمات attributes، فمثلًا، يمكن وصف كيان الموظف بالسمات التالية: الاسم، أو العنوان، أو تاريخ الميلاد، أو الراتب. تملك كل سمة اسمًا محدَّدًا، وترتبط بكيان معيَّن، وبمجال من القيم المسموحة التي يمكن أخذها، ولكن لا تُعرَض المعلومات حول مجال السمة في مخطط الكيان والعلاقة ERD. تمثَّل كل سمة في مخطط الكيان والعلاقة الموضح في الشكل التالي تمثيلًا بيضويًا مع اسم بداخله. الشكل 2: تمثيل السِمات في نموذج العلاقات الكائني للبيانات أنواع السمات هناك أنواع قليلة من السمات التي يجب أن تكون على دراية بها، ويجب ترك بعضها كما هي، لكن يحتاج بعضها الآخر إلى تعديل ليسهل تمثيلها في النموذج العلائقي relational model، وسيناقش هذا القسم أنواع السمات؛ أما لاحقًا فسنناقش تعديل السمات لتلائم النموذج العلائقي بصورة صحيحة. السمات البسيطة السمات البسيطة Simple attributes هي السمات المستمدة من مجالات القيمة الذَرية، ويطلق عليها أيضًا اسم السمات وحيدة القيمة single-valued، فمثلًا، تجد في قاعدة بيانات الشركة COMPANY أن الاسم والعمر هما نموذجان للسمات البسيطة. السمات المركبة السمات المركَّبة Composite attributes هي التي تتكون من مجموعة متسلسلة هرميًا من السمات، فمثلًا، قد يتكون العنوان باستخدام مثال قاعدة البيانات الشركة COMPANY والموضَّح في الشكل التالي، من رقم الشارع، واسم الشارع، واسم الحي، حيث يُمثَّل بالطريقة التالية: العنوان = {59 + "شارع خالد بن الوليد" + "حي القنوات"}. الشكل 3: مثال للسمات المركبة السمات متعددة القيم السمات متعددة القيم Multivalued attributes هي التي تحمل مجموعةً من القيم لكل كيان، فمثلًا، يمكن أن تحمل سمة الدرجات العلمية degrees لموظف معيَّن في قاعدة بيانات الشركة COMPANY العديد من القيم، مثل: دكتوراه PhD، الجامعة العربية للعلوم، إجازة في العلوم BSc كما هو موضَّح في الشكل التالي: الشكل 4: مثال على السمات متعددة القيم السمات المشتقة السمات المشتقة Derived attributes هي سمات تحتوي على قيم محسوبة من سمات أخرى، فمثلًا، يمكن اشتقاق العمر في الشكل التالي من تاريخ الميلاد، يسمى تاريخ الميلاد في هذه الحالة سمة مخزنة stored attribute، وهي التي تُحفظ ماديًا لقاعدة البيانات. الشكل 5: مثال على السِمات المشتقة المفاتيح يُعَدّ المفتاح key أحد القيود المهمة التي يجب وجودها في جميع الكيانات، وهو عبارة عن سمة أو مجموعة من السمات التي تُستخدم قيمها لتعريف كيان منفصل individual entity تعريفًا فريدًا في مجموعة الكيانات. أنواع المفاتيح هناك عدة أنواع من المفاتيح، نذكر منها: المفتاح المرشح يُعَدّ المفتاح المرشَّح candidate key مفتاحًا بسيطًا أو مركَّبًا، كما يكون فريدًا وبسيطًا، وهو فريد لأنه لا يمكن أن يكون لصفين المفتاح المرشَّح نفسه في الجدول في أيّ وقت، فمثلًا، تكون المفاتيح المرشَّحة الممكنة في كيان الموظف الموجود في قاعدة البيانات COMPANY، والذي يتكون من السمات التالية: معرِّف الموظف، الاسم الأول، اسم العائلة، رقم التأمين الاجتماعي SIN، العنوان، الهاتف، تاريخ الميلاد، الراتب، معرِّف القسم، هي ما يلي: رقم التأمين الاجتماعي SIN، أو معرف الموظف EID. الاسم الأول واسم العائلة، بافتراض عدم وجود شخصين في الشركة لهما الاسم نفسه. اسم العائلة ومعرِّف القسم، بافتراض عدم عمل شخصين لهما اسم العائلة نفسه في القسم نفسه. المفتاح المركب يتكون المفتاح المركَّب composite key من سمتين أو أكثر، ويستحسن الإبقاء على الحد الأدنى من السِمات فيه. باستخدام المثال السابق نفسه، تكون المفاتيح المركَّبة الممكنة هي: الاسم الأول واسم العائلة، بافتراض عدم وجود شخصين في الشركة لهما الاسم نفسه. اسم العائلة ومعرِّف القسم، بافتراض عدم عمل شخصين لهما اسم العائلة نفسه في القسم نفسه. المفتاح الرئيسي المفتاح الرئيسي primary key هو مفتاح مرشَّح candidate key يُحدَّد بواسطة مصمم قاعدة البيانات لاستخدامه على أساس آلية تعريف لمجموعة الكيانات بأكملها، كما يجب أن يُحدِّد أسطر الجدول تحديدًا فريدًا، ولا يمكن تركه فارغًا. يُشار إلى المفتاح الرئيسي في نموذج الكيان والعلاقة ER model عن طريق وضع خط تحت السمة التي تُمثِّله. يُحدَّد مفتاح مرشِّح بواسطة مصمم قاعدة البيانات لتحديد أسطر الجدول تحديدًا فريدًا، ولا يمكن تركه فارغًا. يُختار مفتاح معيِّن من قِبَل مصمم قاعدة البيانات لاستخدامه على أساس آلية تعريف لمجموعة الكيانات بأكملها، ويُشار إلى هذا المفتاح بالمفتاح الرئيسي primary key، كما يُشار إليه عن طريق وضع خط تحت السمة الممثِّلة له في نموذج الكيان والعلاقة ER model. إذا أخذنا المثال التالي، يتكون كل صف في جدول الموظف من (EID، الاسم الأول، اسم العائلة، SIN، العنوان، الهاتف، تاريخ الميلاد، الراتب، معرف القسم)، فإن المفتاح الرئيسي هو EID. المفتاح الثانوي المفتاح الثانوي secondary key هو سمة تُستخدَم استخدامًا صارمًا لأغراض الاسترجاع، ويمكن أن يكون هذا المفتاح مركبًا من عدة سمات مثل أن يتكون من الهاتف واسم العائلة معًا. المفتاح البديل المفاتيح البديلة Alternate keys هي جميع المفاتيح المرشَّحة التي لم تُستخدَم على أساس مفتاح رئيسي. المفتاح الخارجي يُعَدّ المفتاح الخارجي foreign key -أو FK اختصارًا- سمةً موجودةً في جدول معيَّن بحيث تشير إلى المفتاح الرئيسي في جدول آخر، أو يمكن تركه فارغًا، ويجب أن تكون كل من المفاتيح الخارجية والرئيسية من نوع البيانات نفسه، فمثلًا يُمثِّل مُعرِّف القسم DepartmentID المفتاح الخارجي ضمن قاعدة بيانات الشركة COMPANY، أي كما يلي: جدول الموظف Employee (معرف الموظف EID ، الاسم الأول، اسم العائلة، رقم التأمين الاجتماعي SIN، العنوان، الهاتف، تاريخ الميلاد، الراتب، معرف القسم) القيم الفارغة Nulls تُعَدّ القيمة الفارغة Null رمزًا خاصًا ليس له علاقة بنوع بيانات محدَّد، مما يعني أنه إما غير معروف unknown أو غير قابل للتطبيق inapplicable، ولا يعني صفرًا أو فراغًا، ومن صفات هذه القيمة: لا توجد بيانات محددة لإدخالها. لا يمكن تواجدها في المفتاح الرئيسي. يجب تجنبها في جميع السمات الأخرى. يمكنها تمثيل ما يلي: قيمة سمة غير معروفة. قيمة سمة معروفة، ولكنها مفقودة. شرط "غير قابل للتطبيق". يمكنها تسبيب العديد من المشاكل عند استخدام بعض الدوال، مثل: COUNT، وAVERAGE، وSUM. يمكنها تسبيب مشاكل منطقية عند ربط الجداول العلائقية ببعضها البعض. مثال لكيفية استخدام القيمة الفارغة null استخدم جدول الرواتب Salary_tbl الموجود في الشكل التالي لمعرفة كيفية استخدام القيمة الفارغة null. table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } emp# JopName Salary Commission E10 Sales 12500 32090 E11 Null 25000 8000 E12 Sales 44000 0 E13 Sales 44000 Null جدول الرواتب فيه أحد أعمدته قيمة فارغة null على أساس خطة أولى، إبدأ بإيجاد جميع الموظفين في عمود الموظف emp#‎ في قسم المبيعات Sales تحت عمود اسم الوظيفة jobName، والذين تزيد رواتبهم salary بالإضافة إلى عمولتهم commission عن 30000. SELECT emp# FROM Salary_tbl WHERE jobName = Sales AND (commission + salary) > 30,000 يكون ناتج العملية أعلاه الموظفَين E10، وE12، إذ لا تتضمن هذه النتيجة الموظف E13 بسبب القيمة الفارغة null في عمود العمولة commission، حيث ستكون النتيجة القيمة الفارغة null عند جمع الراتب مع العمولة، لذا سنحتاج إلى إلقاء نظرة على الحقول بصورة منفصلة للتأكد من تضمين الصف الذي يحتوي على القيمة الفارغة null، كما هو مبين في الحل أدناه. SELECT emp# FROM Salary_tbl WHERE jobName = Sales AND (commission > 30000 OR salary > 30000 OR (commission + salary) > 30,000 سيكون ناتج العملية أعلاه هو الموظفِين E10، وE12، وE13. العلاقات العلاقات Relationships هي الرابط الذي يربط الجداول ببعضها البعض في قاعدة البيانات، وتُستخدَم لربط المعلومات ذات الصلة بين الجداول. تعتمد قوة العلاقة Relationship strength على كيفية تعريف المفتاح الرئيسي للكيانات المترابطة، إذ تُعَدّ العلاقة ضعيفة weak، أو غير محددة non-identifying إذا كان المفتاح الرئيسي للكيان المرتبط لا يحتوي على المفتاح الرئيسي للكيان الأب parent entity. وتتضمن قاعدة بيانات الشركة Company بعض الأمثلة التالية: جدول العميل Customer يحوي الحقلين التاليين: CustID رقم العميل. CustName اسم العميل. جدول الطلب Order يحوي الحقول التالية: OrderID رقم الطلب. CustID رقم العميل. Date تاريخ الطلب. يحتوي المفتاح الرئيسي للكيان المرتبط في العلاقة القوية أو المحددة على المفتاح الرئيسي للكيان الأب، مثل: جدول الدورة التدريبية Course يحوي الحقول التالي: CrsCode رمز الدورة. DeptCode رمز القسم. Description وصف الدورة. جدول الصف Class يحوي الحقول التالية: CrsCode رمز الدورة. Section القسم. ClassTime وقت الصف. أنواع العلاقات هناك عدة أنواع من العلاقات منها: علاقة واحد إلى متعدد تُعَدّ علاقة واحد إلى متعدِّد one to many -أو ‎1:M اختصارًا- الأساس في أي تصميم لقاعدة البيانات العلائقية، وتوجد في جميع بيئات قواعد البيانات العلائقية، فمثلًا، يحتوي القسم الواحد على العديد من الموظفين، ويوضِّح الشكل التالي علاقة أحد هؤلاء الموظفين بالقسم. الشكل 6: علاقة واحد إلى متعدد علاقة واحد إلى واحد تُعَدّ علاقة واحد لواحد one to one -أو 1:1 اختصارًا- علاقة كيان واحد بكيان واحد آخر فقط، والعكس صحيح. يُعَدّ هذا النوع من العلاقات نوعًا نادرًا جدًا في تصميم قواعد البيانات العلائقية، ومن الممكن أن يشير وجود هذه العلاقة إلى انتماء كيانَين بالفعل إلى الجدول نفسه، فمثلًا، يكون الموظف في قاعدة بيانات الشركة COMPANY مرتبطًا بزوجة واحدة، وتكون الزوجة الواحدة مرتبطةً بموظف واحد. علاقة متعدد إلى متعدد ضع في بالك النقاط التالية عند التعامل مع علاقة متعدَِد إلى متعدَِد many to many -أو M:N اختصارًا-: لا يمكن تمثيلها بهذه الصورة -أي متعدَِد إلى متعدَِد- في النموذج العلائقي relational model. يمكن تحويلها إلى علاقتين من النوع واحد إلى متعدِّد. يمكن تنفيذها عن طريق كسرها لمجموعة علاقات من نوع واحد إلى متعدِّد. تنطوي على تنفيذ كيانات مركَّبة. تُنشِئ علاقتين أو أكثر من النوع واحد إلى متعدِّد. يجب أن يحتوي جدول الكيان المركَّب على المفاتيح الرئيسية للجداول الأصلية على الأقل. يحتوي جدول الربط على تكرارات متعددة لقيم المفتاح الخارجي. قد تُسنَد سمات إضافية حسب الحاجة. يمكنك تجنب المشاكل الموجودة في علاقة متعدِّد إلى متعدِّد عن طريق إنشاء كيان مركَّب composite entity، أو كيان جسري bridge entity، فمثلًا، يمكن للموظف العمل في العديد من المشاريع، أو يمكن أن يعمل في المشروع الواحد العديد من الموظفين، اعتمادًا على قواعد العمل؛ أو يمكن للطالب أخذ العديد من الدروس، كما يمكن للدرس الواحد أن يؤخذ بواسطة العديد من الطلاب. يوضِّح الشكل التالي جانبًا آخرًا من علاقة M:N، حيث يكون للموظف العديد من تواريخ البداية المتعلِّقة بمشاريع مختلفة، لذلك نحتاج إلى جدول ربط JOIN بحيث يحتوي على معرِّف الموظف EID، والرمز Code، وتاريخ البداية StartDate. الشكل 7: للموظف العديد من تواريخ البدء المتعلقة بمشاريع مختلفة إليك مثال على تعيين علاقة ثنائية من نوع متعدِّد إلى متعدِّد M:N: حدِّد علاقتين لكل علاقة ثنائية من نوع متعدِّد إلى متعدِّد، حدِّد علاقتين. تمثل A، وB نوعَين من الكيانات المشاركة في R. أنشئ علاقة جديدة S لتمثيل R. تحتاج S أن تتضمن المفاتيح الرئيسية الخاصة بـ A، وB، حيث يمكن أن تكون هذه معًا المفتاح الرئيسي في الجدول S، أو يمكن أن تضاف لها سمة بسيطة أخرى في الجدول الجديد R لتكوين المفتاح الرئيسي. تكون مجموعة المفاتيح الرئيسية لـ A، وB المفتاح الرئيسي لـ S. العلاقة الأحادية -أو التكرارية- العلاقة الأحادية Unary relationship -والتي تسمى العلاقة التكرارية recursive أيضًا- هي العلاقة التي توجد فيها علاقة بين تكرارات مجموعة الكيانات نفسها، ويكون في هذه العلاقة المفتاحان الرئيسي والخارجي متماثلَين لكنهما يمثلان كيانين لهما أدوار مختلفة. تُعَدّ مجموعة الكيان مجموعةً من نوع مماثل من الكيانات. الشكل 8: العلاقات الأحادية (التكرارية) يمكن إنشاء عمود منفصل بحيث يشير إلى المفتاح الرئيسي لمجموعة الكيان نفسها في بعض كيانات العلاقة الأحادية. العلاقة الثلاثية n-ary العلاقة الثلاثية ternary relationship هي نوع من العلاقات يضمن إنشاء علاقة متعدِّد إلى متعدِّد بين ثلاثة جداول، والشكل التالي هو مثال عن هذه العلاقة. لكل علاقة (n-ary) حيث n > 2، أنشئ جدولًا جديدًا لتمثيل تلك العلاقة. المفتاح الرئيسي للجدول الجديد هو مزيج من المفاتيح الرئيسية للكيانات المشاركة التي تمثل الجانب المتعدِّد N. تملك جميع الكيانات المشاركة في معظم حالات علاقة n-ary الطرف المتعدِّد من جانبها. الشكل 9: العلاقة الثلاثية تمارين ما المفهومان اللذان يعتمد عليهما نموذج الكيان والعلاقة ER؟ تتكون قاعدة البيانات في الشكل التالي من جدولين، لذلك أجب على الأسئلة التالية مستخدمًا هذا الشكل. جدول DIRECTOR: table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } DIRNUM DIRNAME DIRDOB 100 J_.Broadway 01/08/39 101 J.Namath 11/12/48 102 W.Blake 06/15/44 جدول PLAY: PLAYNO PLAYNAME DIRNUM 1001 Cat on a cold bare roof 102 1002 Hold the mayo, pass the bread 101 1003 I never promised you coffee 102 1004 Silly putty goes to Texas 100 1005 See no sound, hear no sight 101 1006 Starstruck in Biloxi 102 1007 Stranger in parrot ice 101 جداول التمرين 1. حدِّد المفتاح الرئيسي لكل جدول. 2. حدِّد المفتاح الخارجي في الجدول PLAY. 3. حدِّد المفاتيح المرشَّحة في كلا الجدولين. 4. ارسم نموذج الكيان والعلاقة ER. 5. هل يحقق الجدول PLAY سلامةً مرجعيةً؟ ولمَ؟ أو لمَ لا؟ عرف المصطلحات التالية، حيث قد تحتاج إلى البحث في الانترنت المخطط schema. لغة المضيف host language. اللغات الفرعية للبيانات data sublanguage. لغة تعريف البيانات data definition language. العلاقة الأُحادية unary relation. المفتاح الخارجي foreign key. العلاقة الافتراضية virtual relation. الربط connectivity. المفتاح المركَّب composite key. جداول الربط linking table. تضمن قاعدة بيانات شركة PRE الجداول الثلاثة الموضحة في الشكل أدناه، لذلك أجب عن الأسئلة التالية مستخدمًا هذه الجداول: TNUM BASENUM TYPENUM TMILES TBOUGHT TSERIAL 1001 501 1 5900.2 11/08/90 as-125 1002 502 2 64523.9 11/08/90 ac-213 1003 501 2 32116.0 09/29/91 ac-215 1004 2 3256.9 01/14/92 ac-315 الجدول TRUCK BASENUM BASECITY BASESTATE BASEPHON BASE MGR 501 Dallas TX 893-9870 J. Jones 502 New York NY 234-7689 K. Lee الجدول BASE TYPENUM TYPEDESC 1 single box, double axle 2 tandem trailer, single axle الجدول TYPE حدِّد المفتاح الرئيسي والمفتاح الخارجي في كل جدول. هل يحقق الجدول TRUCK سلامةً مرجعيةً؟ اشرح إجابتك. ما نوع العلاقة بين الجدولين TRUCK، و BASE. كم عدد الكيانات في الجدول TRUCK. حدِّد المفاتيح المرشَّحة في الجدول TRUCK. لنفترض أنك تستخدم قاعدة البيانات الموضحة في الشكل أدناه والمكونة من جدولين، أجب عن الأسئلة التالية. CustID CustName AccntNo. 100 Joe Smith 010839 101 Andy Blake 111248 102 Sue Brown 061544 الجدول Customer OrderlD Title CustID Price 1001 The Dark Tower 102 12.00 1002 Incubus Dreams 101 19.99 1003 Song of Susannah 102 23.00 1004 The Time Traveler's Wife 100 21.00 1005 The Dark Tower 101 12.00 1006 Tanequil 102 15.00 1007 Song of Susannah 101 23.00 جدول BookOrders حدِّد المفتاح الرئيسي في كل جدول. حدِّد المفتاح الخارجي في الجدول BookOrders. هل هناك أي مفاتيح مرشَّحة في أي من الجدولين؟ ارسم نموذج الكيان والعلاقة ER. هل يحقق الجدول BookOrders السلامة المرجعية؟ هل تحتوي الجداول على بيانات مكررة؟ ما هي؟ دورة علوم الحاسوب دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب اشترك الآن بالنظر إلى جدول الطالب الموضح في الشكل أدناه، اكتب قائمة بجميع المفاتيح المرشَّحة الممكنة، واذكر سبب اختيارك لكل واحد من المفاتيح. الشكل 14: السؤال السادس أجب عن الأسئلة التالية مستخدمًا مخطط الكيان والعلاقة ERD لقاعدة بيانات المدرسة الموضحة في الشكل أدناه. الشكل 15: السؤال السابع حدِّد جميع الأنوية والكيانات المعتمِدة والمميزة في مخطط الكيان والعلاقة ERD. أي من الجداول لها علاقات ضعيفة، وأيها لديها علاقات قوية؟ بالنظر إلى كل جدول من جداول قاعدة بيانات المدرسة، ما هي السمات التي يمكنها أن تأخذ القيمة الفارغة Null، ولماذا؟ ما هي الجداول التي أُنشِئت على أساس نتيجة لعلاقات متعدِّد إلى متعدِّد؟ ترجمة وبتصرف للفصل Chapter 8 The Entity Relationship Data Model من كتاب Database Design لصاحبته Adrienne Watt. اقرأ أيضًا المقال التالي: قواعد السلامة وقيودها لضمان سلامة البيانات في قواعد البيانات المقال السابق: مفاهيم نموذج البيانات العلائقية RDM الأساسية المهمة في تصميم قواعد البيانات خصائص قواعد البيانات والمزايا التي تقدمها النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

قطعت الطريقة التي تدير بها أجهزة الحاسوب البيانات شوطًا طويلًا على مدار العقود القليلة الماضية، كما يأخذ مستخدمي الحاسوب اليوم المزايا العديدة الموجودة في نظام قواعد البيانات أمرًا مسلَّمًا به على الرغم من عدم مرور وقت طويل على اعتماد أجهزة الحاسوب النظام القائم على الملفات File-based System والذي يُعَدّ النهج الأقل في الأناقة والتكلفة لإدارة البيانات. النظام القائم على الملفات يُعَدّ تخزين المعلومات في ملفات دائمة في الحاسوب إحدى طرق الحفاظ عليها، فمثلًا، يملك نظام الشركة عددًا من البرامج التطبيقية والمصمَّمة لمعالجة ملفات البيانات تلك، ثم توليد المخرجات والنتائج في ملفات أخرى، حيث تُصمَّم هذه البرامج بناءً على طلب المستخدِمين في المؤسسة، كما تضاف برامج جديدة إلى النظام عند الحاجة إليها، ويسمى هذا النظام بالنظام القائم على الملفات File-based System، فمثلًا، يمكن استخدام النظام القائم على الملفات لإدارة بيانات نظام مصرِفي تقليدي كما هو موضح في الشكل أدناه، حيث يوجد أقسام مختلفة في المصرِف، ولكل منها برامج خاصة لإدارة ومعالجة ملفات البيانات المختلفة، كما يمكن استخدام برامج لأداء عمليات عديدة في الأنظمة المصرفية، مثل: الخصم من الحساب أو ائتمانه، وإنشاء كشف برصيد الحساب، وإضافة قروض عقارية جديدة، وإنشاء كشوف حسابات شهرية. الشكل 1: مثال على نظام قائم على الملفات لبنك يستعمله لإدارة البيانات عيوب النظام القائم على الملفات يملك النظام القائم على الملفات والمستخدَم لحفظ المعلومات التنظيمية العديد من العيوب، والتي دفعت فيما بعد لتطوير أنظمة جديدة أكثر كفاءة، نذكر منها التالي: تكرار البيانات غالبًا ما تُنشأ ملفات البيانات الخاصة بالمؤسسة من طرف العديد من المبرمجين من أقسام مختلفة على مدى فترات طويلة من الزمن، مما يؤدي إلى تكرار البيانات عند تحديث أحد الحقول في أكثر من موضع واحد، حيث تسبب هذه العملية العديد من المشاكل، منها: عدم توحيد تنسيق البيانات. الاحتفاظ بالمعلومة نفسها في عدة أماكن مختلفة، أي ضمن ملفات مختلفة. عدم تناسق البيانات، وهو الموقف الذي تتعارض فيه النسخ المختلفة من البيانات نفسها، مما يُهدر مساحة التخزين ويضاعف الجهد. عزل البيانات عزل البيانات هو الخاصية التي تحدد متى وكيف تصبح التغييرات التي يتم إجراؤها بواسطة عملية معينة مرئيةً للمستخدِمين المتزامنين، والأنظمة المتزامنة الأخرى؛ ويؤدي حدوث أي مشكلة في مزامنة البيانات إلى صعوبة استرجاع البيانات المناسِبة من قِبل التطبيقات الأخرى التي تصل لنفس البيانات والتي ربما تكون مخزَّنة في عدة ملفات مختلفة. مشاكل السلامة تُعَدّ مشاكل سلامة البيانات عيبًا آخرًا لاستخدام النظام القائم على الملفات، حيث تشير سلامة البيانات data integrity إلى صيانة البيانات، والتأكد من صحة وتناسق البيانات الموجودة في قاعدة البيانات، حيث يجب مراعاة العوامل التالية أثناء معالجة هذه المشكلة: يجب على قيم البيانات استيفاء قيود تناسق معينة ومحدَّدة في برامج التطبيق. من الصعب إجراء تغييرات على برامج التطبيق من أجل فرض قيود جديدة. مشاكل الأمان يُعَدّ الأمان مشكلةً في النظام القائم على الملفات للأسباب التالية: وجود قيود تتعلق بالحصول على الصلاحيات. تُضاف متطلبات التطبيق إلى النظام بطرق مخصصة، لذلك من الصعب فرض القيود. الوصول المتزامن التزامن هو قدرة قاعدة البيانات على السماح لعدة مستخدِمين بالوصول للسجل نفسه دون التأثير سلبًا على معالجة المعامَلات. يجب على النظام القائم على الملفات إدارة التزامن وضبطه باستخدام برامج تطبيقية، حيث يُقفَل الملف ويُمنَع الوصول إليه عندما يفتحه تطبيق ما، مما يعني أنه لا يمكن لأي شخص آخر الوصول إلى ذاك الملف في الوقت نفسه آنذاك. تُدير أنظمة قواعد البيانات عملية التزامن من خلال السماح لعدة مستخدِمين من الوصول إلى السجل نفسه، ويُعَدّ هذا فرق مهم بين قواعد البيانات والأنظمة القائمة على الملفات. نظام قواعد البيانات دفعت الصعوبات الناشئة عن استخدام النظام القائم على الملفات إلى تطوير نظام جديد لإدارة الكميات الكبيرة من المعلومات التنظيمية، والذي يُسمى بنظام قاعدة البيانات. تلعب قواعد البيانات وتقنيتها دورًا مهمًا في معظم المجالات التي تُستخدَم فيها أجهزة الحاسوب، بما في ذلك الأعمال التجارية، والتعليم، والطب، وغيرها، وسنبدأ في هذا المقال بتقديم بعض المفاهيم الأساسية المتعلقة بهذا المجال لفهم أساسيات أنظمة قواعد البيانات. دور قواعد البيانات في إدارة الأعمال يستخدِم الجميع قواعد البيانات بطريقة أو بأخرى، حتى ولو كانت استخدامات بسيطة مثل تخزين معلومات عن أصدقائهم وعائلاتهم فقط، كما يمكن تدوين هذه البيانات أو تخزينها على جهاز حاسوب باستخدام برنامج معالجة النصوص، أو يمكن حفظها على صورة جداول، ومع ذلك فإنّ أفضل طريقة لتخزين البيانات هي استخدام برامج إدارة قواعد البيانات، وهي أدوات برمجية قوية تسمح لك بتخزين البيانات، ومعالجتها، واسترجاعها بعدة طرق مختلفة. تتتبّع معظم الشركات معلومات العملاء من خلال تخزينها في قاعدة بيانات، وقد تشمل هذه البيانات العملاء، أو الموظفين، أو المنتجات، أو الطلبات، أو أي شيء آخر يساعد الشركة في تنفيذ مهامها. معنى البيانات تُعَدّ البيانات Data معلومات واقعيةً، مثل: القياسات، أو الإحصائيات حول الأشياء والمفاهيم، كما تُستخدَم للمناقشات، أو على أساس جزء من العمليات الحسابية، و يمكن أن تكون هذه البيانات شخصًا، أو مكانًا، أو حدَثًا، أو إجراءً، أو أي شيء آخر، حيث تُمثِّل كل معلومة أو حقيقة معينة عنصرًا من عناصر البيانات أي data element. إذا كانت البيانات معلومات، وكانت المعلومات هي ما نعتمد عليه في العمل، فيمكنك البدء في معرفة المكان الذي قد تخزِّن هذه البيانات فيه، فمثلًا، يُمكن تخزين البيانات في: ملفات تخزين مخصصة جداول البيانات المجلدات الدفاتر القوائم الأوراق تخزِّن كل هذه المواد المعلومات وكذلك قاعدة البيانات. بسبب الطبيعة الميكانيكية لقواعد البيانات، نجد أنَّ لها مقدرة كبيرة على إدارة ومعالجة المعلومات المُخزَّنة فيها، مما يجعل هذه المعلومات أكثر فائدة لعملك. يمكننا البدء من خلال هذا الفهم للبيانات في رؤية كيف يمكن لقاعدة البيانات تخزين مجموعة من البيانات، وتنظيمها، وإجراء بحث سريع عليها، واسترجاعها، ومعالجتها. ويتضمن هذا الكتاب والفصول التالية الكثير من التفاصيل عن أنظمة إدارة قواعد البيانات وكيفية التعامل معها. مصطلحات أساسية التزامن Concurrency: هو قدرة قاعدة البيانات على السماح لعدة مستخدمين من الوصول إلى السجل نفسه دون التأثير سلبًا على معالجة المعاملات. عنصر البيانات Data element: حقيقة أو معلومة واحدة. عدم تناسق البيانات Data inconsistency: الحالة التي تتعارض فيها النسخ المختلفة للبيانات نفسها. عزل البيانات Data isolation: الخاصية التي تحدد متى وكيف تصبح التغييرات التي تجري بواسطة عملية معينة مرئيةً للمستخدِمين المتزامنين والأنظمة المتزامنة الأخرى. سلامة البيانات Data integrity: يشير إلى الصيانة والتأكد من أن البيانات في قاعدة البيانات صحيحة ومتّسقة. تكرار البيانات Data redundancy: حالة تحدث في قاعدة بيانات عندما يحتاج أحد الحقول إلى التحديث في أكثر من جدول. نظام قاعدة البيانات Database approach: يسمح بإدارة كميات كبيرة من المعلومات التنظيمية. برامج إدارة قواعد البيانات Database management software: أداة برمجية قوية تتيح لك تخزين البيانات، ومعالجتها، واسترجاعها بطرق مختلفة. النظام القائم على الملفات File-based system: برنامج تطبيق مصمَّم للتعامل مع ملفات البيانات. تمارين ناقش كل من المصطلحات التالية: البيانات الحقل السجل الملف ما هو تكرار البيانات؟ ناقش عيوب النظام القائم على الملفات. اشرح الفرق بين البيانات والمعلومات. استخدم الشكل أدناه للإجابة على الأسئلة التالية: كم عدد السجلات التي يحتوي عليها الملف؟ كم عدد الحقول في كل سجل؟ ما المشكلة التي قد تواجهها إذا أردت إنشاء قائمة مرتبة حسب المدينة؟ كيف يمكنك حل هذه المشكلة عن طريق تعديل هيكلة الملف؟ table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } PROJECT_CODE PROJECT_MANAGER MANAGER_PHONE MANAGER_ADDRESS PROJECT_BID_PRICE 21-5Z Holly B. Parker 904-338-3416 3334 Lee Rd., Gainesville, FL 37123 $16٬833٬460٫00 25-2D Jane D. Grant 615-898-9909 218 Clark Blvd., Nashville, TN 36362 $12,500٬000٫00 25-5A George F. Dorts 615-227-1245 124 River Dr., Franklin, TN 29185 $32٬512٬420٫00 25-9T Holly B. Parker 904-338-3416 3334 Lee Rd., Gainesville, FL 37123 $21٬563٬234٫00 27-4Q George F. Dorts 615-227-1245 124 River Dr., Franklin, TN 29185 $10٬314٬545٫00 29-2D Holly B. Parker 904-338-3416 3334 Lee Rd., Gainesville, FL 37123 $25٬559٬999٫00 31-7P 0/11liam K. Moor 904-445-2719 216 Morton Rd., Stetson, FL 30155 $56٬850٬000٫00 جدول التمرين رقم 5 ترجمة وبتصرف للفصل Chapter 1 Before the Advent of Database Systems من كتاب Database Design لصاحبه Adrienne Watt. اقرأ أيضًا المقال التالي: المفاهيم الأساسية في قواعد البيانات وتصميمها شرح الفروقات بين قواعد بيانات SQL ونظيراتها NoSQL مقارنة بين أنظمة إدارة قواعد البيانات العلاقية: SQLite مع MySQL مع PostgreSQL النسخة العربية الكاملة لكتاب تصميم قواعد البيانات