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

تُستخدَم قواعد البيانات العلاقيّة منذ وقت طويل. لقد اكتسبت قواعد البيانات من هذا النوع شُهرة بفضل أنظمة إدارتها التي تستخدم النموذج العلاقيّ بشكل جيّد للغاية، وهو النموذج الذي أثبت نفسه كطريقة رائعة للتعامل مع البيانات وخاصة في التطبيقات ذات المهام الحرجة. سنحاول في هذا المقال شرح الفروقات الرئيسيّة في بعض أكثر أنظمة إدارة قواعد البيانات العلاقيّة (RDBMS) شُهرة واستخدامًا. سنستكشف الفروقات الرئيسيّة بينها من حيث المزايا والأداء الوظيفيّ، وكيفية عملها، ومتى تتفوق إحداها على الأخرى، وذلك من أجل مساعدة المطورين على اختيار نظام إدارة قواعد بيانات علاقية (RDBMS). أنظمة إدارة قواعد البيانات قواعد البيانات هي مساحات تخزين مرتبة منطقيًّا لكل الأنواع المختلفة من المعلومات (البيانات). لكل نوع من قواعد البيانات –باستثناء عديمة المخطط– نموذج يقدم هيكلة للبيانات التي يتم التعامل معها. أنظمة إدارة قواعد البيانات هي تطبيقات (أو مكتبات) تدير قواعد البيانات بأشكالها وأحجامها وأنواعها المختلفة. أنظمة إدارة قواعد البيانات العلاقية تستخدم أنظمة قواعد البيانات العلاقيّة النموذج العلاقيّ للعمل على البيانات. يشكّل النموذج العلاقيّ المعلومات التي ستُخَزَّن مهما كان نوعها، وذلك بتعريفها ككيانات مترابطة ذات خصائص تتعدى الجداول (أي مخططات). تتطلب أنظمة إدارة قواعد البيانات من هذا النوع أن تكون البُنى (كالجداول مثلًا) معرّفة لتحوي بيانات وتتعامل معها. لكلّ عمود (مثل الخصائص) في الجداول نوعٌ مختلف من المعلومات (نوع البيانات). يُترجَم كلّ سجلّ في قاعدة البيانات –مُعرّف بمفتاح فريد– إلى صفّ ينتمي إلى جدول، وتكون مجموعة خصائص كل سجل معروضة كأعمدة للجدول. وتكون كلها مرتبطة ببعضها كما هو محدد في النموذج العلاقيّ. العلاقات وأنواع البيانات يمكن اعتبار العلاقات مجموعات حسابية تحوي مجموعة من الخصائص التي تشكّل معًا قاعدة البيانات والمعلومات المحفوظة فيها. تسمح هذه الطريقة في التعريف والتجميع لقواعد البيانات العلاقيّة بالعمل بالطريقة التي تعمل بها. عند تعريف جدول لإدخال سجلات، يجب أن يطابق كلّ عنصر يشكل سجلًّا (كالصفة attribute مثلًا) نوع البيانات المحدّد له (كأن يكون عددًا صحيحًا أو تاريخًا مثلًا). تستخدم أنظمة إدارة قواعد البيانات العلاقيّة أنواعًا مختلفة من البيانات ولا يمكن في العادة تبديل واحدة من هذه الأنواع مكان الأخرى. التعامل مع وعبر قيود –كالتي ذكرناها قبل قليل– شائع مع قواعد البيانات العلاقيّة. في الحقيقة، تشكّل القيودُ مركزَ العلاقات. ملاحظة: إذا كنت تحتاج للتعامل مع معلومات غير مترابطة إطلاقًا وممثلة عشوائيًّا (كالمستندات مثلًا)، فقد تكون مهتمًّا باستخدام NoSQL (قواعد البيانات عديمة المخططات schema-less). قواعد بيانات علاقية شائعة وهامة سنتعرف في هذا المقال على ثلاثة أنواع رئيسيّة وهامّة من أنظمة إدارة قواعد البيانات العلاقيّة مفتوحة المصدر التي ساهمت في تكوين عالم تطوير البرمجيات: SQLite: نظام إدارة قواعد بيانات علاقيّة مضمّن وقويّ جدًّا. MySQL: نظام إدارة قواعد البيانات العلاقيّة الأشهر والأكثر استخدامًا. PostgreSQL: نظام إدارة قواعد البيانات العلاقيّة الكيانيّ مفتوح المصدر المتوافق مع SQL الأكثر تقدّمًا. ملاحظة: تقريبًا دائمًا تتيح التطبيقات مفتوحة المصدر حريّة استخدام الطريقة التي تريدها. وفي غالب الأحيان تسمح لك أيضًا إنشاء تفرّع (fork) عن المشروع (وبالتالي استخدام نصوصه البرمجيّة) لإنشاء شيء جديد. إذا كنت مهتمًّا بأنظمة إدارة قواعد البيانات، فقد ترغب بالاطلاع على بعض المشاريع المتفرّعة المبنية على هذه المشاريع الشهيرة، مثل MariaDB. SQLite إنّ SQLite مكتبة رائعة تُضمَّن في التطبيقات التي تستخدمها. وكونها قاعدة بيانات قائمة بذاتها ومعتمدة على الملفات. تقدّم SQLite مجموعة رائعة من الأدوات للتعامل مع كل أنواع البيانات بقيود أقلّ بكثير وسهولة مقارنة بقواعد البيانات المستضافة المعتمدة على العمليات (خواديم قواعد البيانات). عندما يستخدم برنامج ما SQLite، يعمل هذا التكامل بنداءات (calls) مباشرة ومؤدية للغرض موجهة لملف يحوي البيانات (كقاعدة بيانات SQLite) بدلًا من التواصل عبر واجهة من نوع ما (كالمنافذ ports والمقابس sockets). هذا يجعل SQLite كفؤة وسريعة للغاية، وقويّة كذلك، وهذا بفضل التقنية التي بنيت عليها هذه المكتبة. أنواع البيانات التي تدعمها SQLite: NULL: قيمة فارغة NULL. INTEGER: عدد صحيح ذو إشارة (موجب أو سالب) محفوظ في بايت واحد، 2، 3، 4، 6، أو 8 بايت، وهذا يعتمد على حجم القيمة. REAL: قيمة النقطة العائمة (floating point)، مخزنة كرقم نقطة IEEE عائمة ذي 8-بايت. TEXT: سلسلة نصيّة مخزنة باستخدام ترميز قاعدة البيانات (UTF-8, UTF-16BE or UTF-16LE). BLOB: فقاعة من البيانات، تخزّن كما أدخِلَت تمامًا. ملاحظة: لمعرفة المزيد عن أنواع بيانات SQLite والعلاقات بين أنواع SQLite، ألقِ نظرة على التوثيق الرسميّ حول الموضوع. مزايا SQLite: معتمدة على الملفات: تتكون قاعدة البيانات بأكملها من ملف واحد على القرص، مما يجعلها محمولة تمامًا. مدركة للمعايير: رغم أنها قد تبدو كتطبيق قواعد بيانات "بسيط"، إلّا أن SQLite تستخدم SQL. ورغم أنّها أزالت بعض المزايا ( RIGHT OUTER JOIN أو FOR EACH STATEMENT) إلّا أنها تحوي بداخلها مزايا أخرى إضافيّة. ممتازة للتطوير، بل وحتى للاختبار: أثناء مرحلة تطوير التطبيقات، في الغالب يحتاج أغلب الناس لحلّ يمكن تطويعه للطلبات المتعدّدة. لدى SQLite قاعدة مزايا غنيّة، ويمكنها تقديم أكثر مما تحتاجه للتطوير، وبسهولة العمل مع ملف وحيد ومكتبة مرتبطة مبنية على C. عيوب SQLite: لا توفّر إدارة للمستخدمين: تأتي قواعد البيانات المتقدّمة بإدارة للمستخدمين –فمثلًا، فيها اتصالات مُدارة بصلاحيات الوصول إلى قواعد البيانات والجداول–. وبأخذ هدف وطبيعة SQLite بعين الاعتبار (عدم وجود مستوىً عالٍ من تعدّد المستخدمين في ذات الوقت)، لا وجود لهذه الميزة. عدم توفر إمكانية التلاعب بها للحصول على أداء أفضل: ونظرًا لطبيعة تصميمها أيضًا، لا يمكن التلاعب بـ SQLite للحصول على قدر كبير من الأداء. المكتبة سهلة الضبط والاستخدام. وبما أنها ليست معقّدة، فلا يمكن تقنيًّا جعلها أكثر أداءًا مما هي عليه، وبشكل يفوق أداءها الحاليّ الرائع. متى تستخدم SQLite: التطبيقات المضمّنة: كلّ التطبيقات التي تحتاج لقابليّة النقل، والتي لا تحتاج لتحجيم، كتطبيقات المستخدم المحلي والوحيد، وتطبيقات الهاتف النقّال أو الألعاب. كبديل عن الوصول إلى القرص: في العديد من الحالات، يمكن أن تستفيد التطبيقات التي تحتاج للقراءة من والكتابة إلى الملفات على القرص مباشرة من الانتقال إلى SQLite من أجل المزيد من الوظائف والسهولة اللتان تأتيان من استخدام لغة الاستعلام البنيويّة (Structured Query Language – SQL). الاختبار: من التبذير أن تستخدم نسبة كبيرة من التطبيقات عمليّة إضافيّة لاختبار منطقيّة العمل (أي الهدف الرئيسيّ للتطبيق: الوظيفيّة). متى لا تستخدم SQLite: في التطبيقات متعدّدة المستخدمين: إذا كنت تعمل على تطبيق يحتاج فيه العديد من المستخدمين الوصول إلى نفس قاعدة البيانات واستخدامها، فالغالب أنّ مدير قواعد بيانات علاقيّ كامل المزايا (مثل MySQL) خيار أفضل من SQLite. في التطبيقات التي تحتاج لقدر كبير من الكتابة: من محدوديّات SQLite عمليات الكتابة. يسمح نظام إدارة قواعد البيانات هذا عملية كتابة واحدة وحيدة أن تتم في وقت محدّد، مما يسمح بقدر محدود من الدفق. MySQL تعد MySQL أشهر خوادم قواعد البيانات الكبيرة. وهو منتج مفتوح المصدر غنيّ بالمزايا، ويشغّل الكثير من المواقع والتطبيقات على الإنترنت. من السهل البدء باستخدام MySQL، ولدى المطورين وصول إلى كمّ هائل من المعلومات المتعلقة بقواعد البيانات على الإنترنت. ملاحظة: يجب أن نذكر أنّه نتيجة لشيوع المُنتَج، فإنّ هناك الكثير من تطبيقات الشركات الأخرى وأدواتها ومكتباتها المضمّنة التي تساعد كثيرًا في الهديد من نواحي العمل مع نظام إدارة قواعد البيانات العلاقيّة هذا. ورغم عدم محاولتها تطبيق معيار SQL كامل، إلّا أنّ MySQL تقدّم الكثير من الوظائف للمستخدمين. وكخادم SQL قائم بذاته، تتصل التطبيقات بعملية مراقب MySQL (وهو تطبيق يعمل في الخلفية بعيدًا عن مرأى المستخدم، ويشار إليه أحيانًا بعبارة جنيّ أو عفريت) للوصول إلى قواعد البيانات ذاتها على خلاف SQLite. أنواع البيانات التي تدعمها MySQL: TINYINT: عدد صحيح متناهي الصغر. SMALLINT: عدد صحيح صغير. MEDIUMINT: عدد صحيح متوسّط الحجم. INT or INTEGER: عدد صحيح بحجم عاديّ. BIGINT: عدد صحيح كبير. FLOAT: عدد بفاصلة عائمة صغير أحاديّ الدقّة (single-precision floating-point). لا يمكن إلغاؤه. DOUBLE, DOUBLE PRECISION, REAL: عدد بفاصلة عائمة متوسط الحجم مزدوج الدقّة (normal-size/double-precision floating-point). لا يمكن إلغاؤه. DECIMAL, NUMERIC: عدد بفاصلة عائمة غير مُحتوىً. لا يمكن إلغاؤه. DATE: تاريخ. DATETIME: تجميعة من الوقت والتاريخ TIMESTAMP: ختم زمني (وقت وتاريخ حدوث حدث ما). TIME: وقت. YEAR: سنة بهيئة منزلتين أو أربعة منازل (المبدئيّ 4 منازل). CHAR: سلسلة نصّيّة ذات طول محدّد يتم دائمًا إكمالها من ناحية اليمين بفراغات إلى الطول المحدّد عند تخزينها. VARCHAR: سلسلة نصيّة ذات طول متغيّر. TINYBLOB, TINYTEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 255 (أي 2^8 – 1) محرفًا. BLOB, TEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 65535 (أي 2^16 – 1) محرفًا. MEDIUMBLOB, MEDIUMTEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 16777215 (أي 2^24 - 1) محرفًا. LONGBLOB, LONGTEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 4294967295 (أي 2^32 - 1) محرفًا. ENUM: تِعداد. SET: مجموعة. مزايا MySQL سهلة الاستخدام: يمكن تثبيت MySQL بسهولة شديدة. أدوات الأطراف الخارجية (third-party)، بما فيها المرئيّة (أي الواجهات الرسوميّة) تجعل البدء مع قواعد البيانات سهلًا للغاية. غنيّة بالمزايا: تدعم MySQL الكثير من وظائف SQL المتوقّع وجودها في أنظمة إدارة قواعد البيانات العلاقيّة، سواء بطريقة مباشرة أو غير مباشرة. آمنة: الكثير من مزايا الأمن وبعضها متقدّم مبنيّة في MySQL. قويّة وقابلة للتحجيم: يمكن لـMySQL التعامل مع الكثير من البيانات، ويمكنها أيضًا استخدامها على نطاق واسع إذا احتاج الأمر. سريعة: التخليّ عن بعض المعايير سمح لـ MySQL بالعمل بكفاءة عالية وبطريقة سلسة، مما أكسبها سرعة عالية. عيوب MySQL المحدوديّات المعروفة: من حيث التصميم، لا تنوي MySQL عمل كلّ شيء، وتأتي بمحدوديّات وظيفيّة قد تتطلبها بعض التطبيقات المتقدّمة جدًّا من الناحية الفنيّة. القضايا المتعلّقة بالمتانة: الطريقة التي يتم التعامل فيها مع بعض الوظائف في MySQL (كالمراجع، والتبادلات، والتدقيق، وغيرها) تجعلها أقل متانة بقليل من بعض أنظمة إدارة قواعد البيانات العلاقيّة الأخرى. بطء تطويرها: رغم أنّ MySQL ما زالت من الناحية الفنيّة منتجًا مفتوح المصدر، إلّا أنّ هناك انتقادات تتعلق بعمليّة تطويرها منذ الاستحواذ عليها. ولكن علينا التنويه إلى أنّ هناك قواعد بيانات مبنيّة على MySQL ومتكاملة معها تمامًا تضيف مزايا على تثبيت MySQL القياسيّ (مثل MariaDB). متى تستخدم MySQL العمليّات الموزّعة: عندما تحتاج لأكثر مما تتيحه SQLite، فإنّ تضمين MySQL في قائمة التطوير لديك – كذلك بالأمر بالنسبة لتضمين أيّ خادم قواعد بيانات مستقل – يقدّم لك الكثير من الحريّة في العمل إلى جانب بعض المزايا المتقدّمة. الأمان العالي: مزايا MySQL الأمنيّة تقدّم حماية يُعتمد عليها للوصول إلى البيانات (واستخدامها) بطريقة بسيطة. المواقع وتطبيقات الوِب: يمكن للأغلبية العُظمى من المواقع (وتطبيقات الوِب) العمل ببساطة مع MySQL رغم القيود. هذه الأداة المرنة والتي يمكن تحجيمها إلى حدّ ما سهلةُ الاستخدام والإدارة؛ وهذا مفيدٌ جدًّا على المدى البعيد. الحلول الخاصّة: إذا كنت تعمل على حلول محدّدة جدًّا ومخصّصة للغاية، يمكن لـMySQL العمل ضمن احتياجاتك بسهولة، وذلك بفضل إعدادات الضبط الغنيّة فيها وأوضاع العمل. متى لا تستخدم MySQL التوافقيّة مع SQL: بما أنّ MySQL لا تطبّق (ولا تسعى لتطبيق) معيار SQL بأكمله، فإنّ هذه الأداة ليست متوافقة بالكامل مع SQL. إذا كنت قد تحتاج التكامل مع أنظمة إدارة قواعد بيانات علاقيّة كهذه، فإنّ الانتقال من MySQL لن يكون سهلًا. التعدّدية Concurrency: رغم أنّ MySQL وبعض محرّكات الحفظ تعمل بأداء جيّد جدًّا في عمليات القراءة، إلا أنّ عمليات القراءة والكتابة متزامنتين قد تكون سيئة. نقص المزايا: مجدّدًا نقول، اعتمادًا على اختيار محرّك قواعد البيانات، يمكن أن لا تحوي MySQL على بعض المزايا، كالبحث في النصوص الكاملة. PostgreSQL إنّ PostgreSQL هي نظام إدارة قواعد البيانات العلاقيّة الكيانيّ مفتوح المصدر الأكثر تقدّمًا، والتي هدفها الرئيسيّ أن تكون موافقة للمعايير ويمكن الزيادة عليها. تسعى PostgreSQL (أو Postgres) إلى تبني معايير ANSI/ISO SQL مع مراجعاتها. تتميّز PostgreSQL عن أنظمة إدارة المحتوى الأخرى بدعمها للتوجه الكيانيّ (object-oriented) المتكامل والمطلوب بشدّة و/أو وظائف قواعد البيانات العلاقيّة، كدعمها الكامل للتبادلات (القيود transactions) التي يعتمد عليها، أي أن تكون مكونة من عناصر غير قابلة للتجزئة، وأن تكون متّسقة ومعزولة وذات قدرات تحمل عالية (Atomicity, Consistency, Isolation, Durability – ACID). وبسبب التقنية القوية التي تقف خلفها، لدى Postgres قدرات عالية جدًّا في التعامل مع العديد من المهام بكفاءة عالية. يتم الوصول إلى التعدّدية (concurrency) دون قفل قراءة، وذلك بفضل تطبيق تحكم التعدّديّة متعدد الإصدارات (Multiversion Concurrency Control – MVCC). يمكن برمجة الكثير في PostgreSQL، وبالتالي يمكن توسعتها، وذلك باستخدام إجراءات مخصّصة تُدعى "إجراءات التخزين" (store procesures). يُمكن إنشاء هذه الإجراءات لتسهيل تنفيذ عمليات قاعدة البيانات المكررة والمعقدة والتي تكثر الحاجة إليها. رغم أنّ نظام إدارة قواعد البيانات هذا لا يحظى بشعبيّة MySQL، إلّا أنّ هناك الكثير من أدوات الأطراف الأخرى ومكتباتهم مصمّمة لجعل العمل مع PostgreSQL سهلًا، رغم طبيعته القويّة. يمكن الحصول على PostgreSQL هذه الأيام كحزمة تطبيقات من خلال مدير الحزم المبدئيّ للعديد من أنظمة التشغيل بسهولة. أنواع البيانات التي تدعمها PostgreSQL bigint: عدد صحيح من 8-بايت ذو إشارة bigserial: عدد صحيح من 8-بايت يزداد تلقائيًّا [(bit [(n: سلسلة ثنائيّة ذات طول محدّد [(bit varying [(n: سلسلة ثنائيّة متغيرة الأطوال boolean: متغيّر منطقي (صواب/خطأ) box: صندوق مستطيل في سطح مستوٍ bytea: بيانات ثنائيّة ("مصفوفة بايت") [(character varying [(n: سلسلة محارف (character string) ذات طول متغير [(character [(n: سلسلة محارف ذات طول ثابت cidr: عنوان شبكة IPv4 أو IPv6 circle: دائرة في سطح مستوٍ date: تاريخ في تقويم (السنة، الشهر، اليوم) double precision: عدد فاصلة عائمة ذو دقّة مزدوجة (8 بايت) inet: عنوان مضيف IPv4 أو IPv6 integer: عدد صحيح من 4 بايت ذو إشارة [(interval [fields] [(p: مدة زمنية line: خط لا نهائيّ في مستوى lseg: جزء من خطّ مستقيم في مستوى macaddr: عنوان تحكم بالوصول إلى الوسيط (Media Access Control – MAC) money: مقدار من المال [(numeric [(p, s: دقّة رقميّة محدّدة أو يمكن اختيارها path: مسار هندسيّ على سطح point: نقطة هندسيّة على سطح polygon: شكل هندسيّ مغلق على سطح real: عدد فاصلة عائمة ذي دقّة أحاديّة (4 بايت) smallint: عدد صحيح من 2-بايت ذو إشارة serial: عدد صحيح من 4 بايت يزداد تلقائيًّا text: سلسلة محارف ذات طول متغيّر [time [(p)] [without time zone: وقت في اليوم (دون منطقة زمنية) time [(p)] with time zone: الوقت من اليوم (مع منطقة زمنية) [timestamp [(p)] [without time zone: تاريخ ووقت (دون منطقة زمنية) timestamp [(p)] with time zone: تاريخ ووقت يشمل المنطقة الزمنيّة tsquery: استعلام بحث نصّيّ tsvector: مستند بحث نصيّ txid_snapshot: لَقطَة (transaction) لهويّة التبادل على مستوى المستخدم uuid: معرّف فريد عالميًّا xml: بيانات XML مزايا PostgreSQL نظام إدارة قواعد بيانات مفتوح المصدر موافق لمعايير SQL: PostgreSQL مفتوح المصدر ومجانيّ، ولكنه نظام إدارة قواعد بيانات علاقيّة قويّ جدًّا. مجتمع قويّ: PostgreSQL مدعوم من مجتمع خبيرٍ ومخلص يمكن الوصول إليه عبر مواقع الأسئلة والإجابات والقاعدة المعرفيّة طوال الوقت ومجانًا. دعم قويّ من الأطراف الأخرى: بغض النظر عن المزايا المتقدّمة جدًّا، تُزيّن PostgreSQL العديدُ من الأدوات الجيّدة ومفتوحة المصدر من أطراف أخرى لتصميم وإدارة واستخدام نظام الإدارة هذا. إمكانية التوسعة: يمكن توسعة PostgreSQL برمجيًّا باستخدام إجراءات مخزّنة، كما يفترض أن يكون الوضع في نظام إدارة قواعد بيانات علاقيّة متقدّم. كيانيّ: ليس PostgreSQL مجرّد نظام إدارة قواعد بيانات علاقيّة، ولكنه كيانيّ (objective) أيضًا – ويدعم التضمين (nesting)، ومزايا أخرى. عيوب PostgreSQL الأداء: للعمليات البسيطة كثيفة القراءة، يمكن أن تكون PostgreSQL مبالغًا فيها، ويمكن أن تبدو أقلّ أداءً من منافساتها، مثل MySQL. الشعبيّة: نظرًا لطبيعة هذه الأداة، فإنها تقبع في الخلف فيما يتعلق بشعبيتها، رغم كثرة من استخدامها – مما قد يؤثر على سهولة الحصول على دعم. الاستضافة: نتيجة للعوامل المذكورة أعلاه، يصعب إيجاد مستضيفين أو مقدمي خدمة يعرضون خدمات PostgreSQL مُدارة. متى تستخدم PostgreSQL صحّة البيانات: عندما تكون صحّة البيانات وإمكانية التعويل عليها ضرورة حتميّة، ولا يكون هناك عذر إذا حدث خطب ما، فستكون PostgreSQL الخيار الأفضل. الإجراءات المخصّصة المعقّدة: إذا كنت تتطلّب من قاعدة بياناتك أداء إجراءات مخصّصة، فـPostgreSQL هي الخيار الأفضل، كونه يمكن توسعتها. التكامل: إذا كان يُحتمل في المستقبل أن تكون هناك حاجة لنقل نظام قاعدة البيانات بأكمله إلى حلّ مملوك (مثل أوراكل)، فستكون PostgreSQL الأكثر توافقًا والأسهل في التعامل معها عند الانتقال. التصاميم المعقّدة: مقارنة بتطبيقات أنظمة إدارة قواعد البيانات العلاقيّة المجانية ومفتوحة المصدر الأخرى، تقدّم PostgreSQL لتصاميم قواعد البيانات المعقّدة أكبر قدر من الوظائف والإمكانات دون التفريط بالأمور الأخرى. متى لا تستخدم PostgreSQL السرعة: إذا كان كلّ ما تطلبه عمليات قراءة سريعة، فليست PostgreSQL الأداة التي عليك استخدامها. سهولة الإعداد: إذا لم تكن تحتاج لصحّة مطلقة للبيانات، أو للتوافق مع ACID أو التصاميم المعقّدة، فقد تكون PostgreSQL مبالغًا فيها للإعدادات البسيطة. التكرار: إذا لم تكن مستعدًّا لقضاء الوقت، وبذل الجهد والموارد، فالحصول على التكرار (أو تعدّد النُسَخ) في MySQL قد يكون أسهل لمن ليست لديهم خبرة في إدارة الأنظمة وقواعد البيانات. ترجمة -وبتصرّف- للمقال: SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems لصاحبه O.S. Tezer.

سنتحدث في هذا المقال عن مفهوم العلاقات بين جداول قاعدة البيانات، وما أنواع هذه العلاقات وكيف تتمثل وما هو أثرها على العمل. ما هي العلاقات بين الجداول عند إنشاء جداول في قاعدة البيانات، فإن الظاهر لنا أننا نقوم ببناء جداول منفصلة وغير مترابطة، ولكننا في الواقع العملي نحتاج لربط هذه الكيانات المنفصلة بحيث تُبنَى علاقات تحكم البيانات الموجودة في هذه الجداول، وتحكم طريقة التعامل مع هذه البيانات. تنشَأ العلاقة بين جدوليْن عندما يُربط عمودان فيهما مع بعضهما عن طريق وجود قيود مطبقة على العمودين، بحيث يكون قيد المفتاح الرئيسي على عمود في الجدول “الأب” وقيد المفتاح الأجنبي على العمود في الجدول “الابن”، وعادة يكون اسم العمودين واحدًا في كلا الجدولين. مثلا، لحفظ عناوين الأشخاص نستطيع إنشاء جدول باسم Address ونربطه بجدول الأشخاص Persons بعلاقة تحكم البيانات الموجودة في الجدولين، بحيث يكون لكل شخص في الجدول Persons عنوان واحد مرتبط به في الجدول Address. يُربَط الجدولان عن طريق عمود باسم Person_Id في كلا الجدولين. مثال آخر، لو أردنا أن نتابع عملية استعارة الكتب في مكتبة، فإننا سننشئ جدولًا باسم Borrowed_Books (كُتُب مُعارة) ونربطها بالجدول Persons عن طريق العمود Person_Id. يستطيع الشخص الواحد - في هذا النوع من الربط - أن يستعير أكثر من كتاب. في هذا المثال، لو أننا حفظنا بيانات الأشخاص والكتب المستعارة في جدول واحد، ستظهر لنا مشكلة تكرار البيانات Data Redundancy لأننا سنكرّر بيانات الشخص لكل كتاب يستعيره. ماذا نستفيد من بناء العلاقات بين الجداول؟ التخلص من مشكلة تكرار البيانات عن طريق فصلها وحفظها في أكثر من جدول، فمشكلة تكرار البيانات هي عدو مستخدمي قواعد البيانات ومسؤوليها، لأنها تتسبب بزيادة حجم قاعدة البيانات بقدر كبير وبسرعة، وترفع السرعات المطلوبة لتنفيذ الاستعلامات، وتجعل من موضوع صيانة قاعدة البيانات كابوسا مقلقا. الحفاظ على دقة وسلامة البيانات في قاعدة البيانات، فمع وجود العلاقات بين الجداول، سوف تضمن مثلا عدم وجود كتاب مُعار ليس له شخص استعاره، أو عنوان وهمي ليس له صاحب، وقس على ذلك العديد من الأمثلة. استخراج البيانات من أكثر من جدول بكفاءة وسرعة عن طريق بناء جمل ربط استعلامية تطلب المعلومات من أعمدة مختلفة في جداول مختلفة، وإخراج النتيجة بطريقة مفيدة ومرتبة. أنواع العلاقات توجد أربعة أنواع من العلاقات بين الجداول كالتالي: علاقة واحد إلى واحد (One-to-One). علاقة واحد إلى كثير أو علاقة كثير إلى واحد (One-to-Many / Many-to-One). علاقة كثير إلى كثير (Many-to-Many). علاقة المرجعية الذاتية (Self Referencing). علاقة واحد إلى واحد لنفترض أن الجدول Persons لديه البنية والبيانات التالية: Person_ID First_Name Last_Name Age Address 101 Ibrahim Mohammed 31 12 Main St, Doha 102 Mohammed Khaled 25 Gaza, Middle Center نستطيع أن نضع بيانات العنوان في جدول منفصل ونسميه Address وتكون بنية الجدوليْن كالتالي. الجدول Persons: Person_ID First_Name Last_Name Age Address_Id 101 Ibrahim Mohammed 31 1 102 Mohammed Khaled 25 2 الجدول Address: Address_ID Address 1 12 Main St, Doha 2 Gaza, Middle Center لاحظ أنه أصبح لدينا عمود بنفس الاسم Address_Id في كلا الجدولين. لبناء العلاقة بين الجدولين، طبّقنا قيد المفتاح الأجنبي على العمود Address_Id في الجدول Persons بحيث يأخذ قيمه من العمود Address_Id في الجدول Address والمطبق عليه قيد المفتاح الرئيسي. أصبحت لدينا الآن علاقة بين الجدولين، وفي حال كان كل عنوان في الجدول Address يقترن فقط بشخص واحد في الجدول Persons فعندها نسمي هذه العلاقة واحدًا إلى واحد. يجب التنويه إلى أن هذا النوع من العلاقات غير مستخدم كثيرا، فالجدول الأول الذي يحتوي العنوان وبيانات الشخص يفي بالغرض في أغلب الأحيان. نستطيع تمثيل العلاقة بالشكل التالي: لاحظ أن وجود العلاقة اختياري، فمن الممكن أن يكون لدينا سجل في الجدول Persons دون عنوان له في الجدول Address وهذا مرتبط بعدم تطبيق قيد القيمة غير الفارغة على العمود Address_Id. في حال طُبِّق قيد غير القيمة غير الفارغة على العمود، فهنا تصبح العلاقة واجبة بين الجدولين، ولا يمكن أن نُنْشئ سجلًّا في الجدول Persons إلا بإدخال قيمة موجودة للعمود Address_Id وهو في مثالنا هذا غير منقطي نوعا ما. دورة علوم الحاسوب دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب اشترك الآن علاقة واحد إلى كثير أو علاقة كثير إلى واحد هذا النوع من العلاقات هو الشائع بين أنواع العلاقات بين الجداول في قاعدة البيانات، لوجود تطبيقات كثيرة عليه، فمثلا: الطالب (واحد) يستطيع أن يدرس أكثر من مساق (كثير). الطبيب يعالج ويتابع حالة مريض واحد أو أكثر. طلبية الشراء تحتوي على أكثر من عنصر. الشخص يستعير أكثر من كتاب. وقس على ذلك العديد من الأمثلة. لنفترض وجود جدول للزبناء Customers بالهيكلية التالية: Customer_ID Customer_Name 1 Ibrahim Mohammed 2 Mohammed Ahmed نستطيع ربط جدول الزبناء السابق بجدولٍ للطلبيات Orders بعلاقة واحد إلى كثير، لتعبر العلاقة عن الطلبيات التي قام بها العملاء وقيمة كل طلبية وتاريخها. يمكن أن تكون هيكلية الجدول Orders كالتالي: Order_ID Customer_ID Order_Date Order_Value 997 101 1/5/2017 100 998 102 21/4/2016 150 999 101 21/4/2015 1500 تسمح هذه العلاقة للعميل بأن يطلُب طلبيةً أو أكثر، ويمكن ألا تكون له أية طلبية. ولكنّ كل طلبية في الجدول Orders ستكون تابعة لعميل واحد. ونستطيع تمثيل هذه العلاقة بالشكل التالي: علاقة كثير إلى كثير في علاقة كثير إلى واحد، تكون العلاقة مبنية على أن يكون أحد أطرافها “واحدًا”، مثل طالب واحد، عميل واحد، طلبية واحدة، وفي الطرف الثاني “كثير”. نحتاج أحيانا أن يكون طرفا العلاقة كثيرين. فمثلا، قد تكون لدينا طلبية تحتوي أكثر من عنصر، ونفس العنصر يكون متواجدًا في أكثر من طلبية. في هذه الحالة نحتاج لوجود جدول إضافي لبناء العلاقة، فمثلا تكون هيكلية جدول Orders كالتالي: Order_ID Customer_ID Order_Date Order_Value 997 101 1/5/2017 100 998 102 21/4/2016 150 999 101 21/4/2015 1500 وهيكلية جدول Items كالتالي: Item_Id Item_Name Item_Description 201 Hard Disk 1 1 Tera SSD Hard 202 Mouse Microsoft Optical Mouse 203 LCD 42 42” LCD نستطيع بناء علاقة كثير إلى كثير بين الجدولين السابقين بإضافة جدول ثالث يحلّ مكان الرابط وغرضه الوحيد هو بناء هذا النوع من العلاقات. نطلق عليه مثلا الاسم Orders_Items، ويكون بالهيكلية التالية: Order_Id Item_Id 997 201 997 202 999 201 999 202 999 203 998 203 يمثّل الشكل التالي علاقة كثير إلى كثير كما تظهر في الجدول Orders_Items: علاقة المرجعية الذاتية يُبنى هذا النوع من العلاقات عندما نريد أن نبني علاقة بين جدول ونفس الجدول، وأوضح مثال على هذا النوع من العلاقات هو جدول الموظفين الذي يحتوي على عمود رقم الموظف المسؤول، حيث يمكن ربط كل موظف بموظف آخر (مدير أو مسؤول) من نفس الجدول. فمثلا، لو كان لدينا جدول باسم Employees خاص بحفظ بيانات الموظفين، ستكون هيكليته على النحو التالي لتطبيق علاقة مرجعية ذاتية عليه: Employee_ID Employee_Name Manager_Id 100 Ibrahim Elbouhissi 101 Khaled Saber 100 102 Yasmeen Hadi 100 103 Duaa Yousef 101 104 Sami Saber بعلاقة المرجعية الذاتية، من الممكن أن يكون للموظف مسؤولًا أو لا يكون، ومن الممكن أن يكون الموظف مسؤولا عن موظف أو أكثر، ويمكن تمثيل العلاقة بالشكل التالي.

يتناول هذا المقال، الأول من سلسلة دروس عن لغة الاستعلام البنائية Structured Query language التي تعرف بالاختصار المشهور SQL، مفهوم قواعد البيانات، وماذا نقصد بأنظمة إدارة قواعد البيانات، وما هو الجدول، وما هي خصائص قواعد البيانات العلاقية. ما هي قاعدة البيانات؟ بطريقة بسيطة مجرّدة من مفاهيم التقنية، قاعدة البيانات هي مكان لحفظ بيانات معينة على نحو مستمر بهدف الرجوع إليها وقت الحاجة، فدفتر أرقام الهواتف الذي كنا نستعمله في الماضي يُعدّ قاعدة بيانات؛ والكم الهائل من الفواتير المحاسبية الورقية المحفوظة في خزانات الأقسام المالية في الشركات قديماً، أيضاً هو قاعدة بيانات. وقِس على ذلك العديد من الأمثلة الواقعية والملموسة. نستنبطُ من هذا التعريف البسيط وجود خاصية هامة لقاعدة البيانات، ألا وهي “الاستمرارية” أو “الدوام” في حفظ البيانات. في الجانب التقني والبرمجي، فإن قاعدة البيانات Database هي عبارة عن مستودع تُحفظ البيانات فيه داخل جهاز الحاسوب أو الخادوم، ويتمتع هذا المستودع بخاصية الاستمرارية في حفظ البيانات. ونعني بخاصية الاستمرارية هنا أنه في حال إطفاء جهاز الحاسوب أو إعادة تشغيله أو انقطاع التواصل معه، فإن قاعدة البيانات وما تحتويه من بيانات تبقى موجودة ومحفوظة دون أي خلل. أنظمة إدارة قواعد البيانات العلاقية تُسمى البرمجيات التي تنشئ وتدير قواعد البيانات بأنظمة إدارة قواعد البيانات (Databases Management Systems) وتكتب بالاختصار DBMS. ما هي أنواع أنظمة إدارة قواعد البيانات؟ تختلف وتتعدد تسميات أنواع أنظمة إدارة البيانات، وهذا الاختلاف نابع بالدرجة الأولى من تقدم الزمن وما صاحبه من تقدم في العلوم والتقنيات، ومن ثم بالدرجة الثانية، ينبع الاختلاف من التقنيات والخصائص المتعددة لهذه الأنظمة وما تقدمه من خدمات. تنقسم أنواع أنظمة قواعد البيانات إلى ثلاثة أنواع رئيسية. نظام قاعدة البيانات الملف والواحد Flat File Database: يعدّ هذا النوع من الأنظمة قديما ومن النادر أن تجد أحدا يعمل عليه إلى الآن، وهو ببساطة قاعدة بيانات من ملف واحد كبير يحتوي على كل البيانات، وهو يشبه جدول واحد به كل البيانات. نظام إدارة قاعدة البيانات غير العلاقية Non-Relational DBMS :ظهر هذا النوع من أنظمة قواعد البيانات في ظل عصر تضخم البيانات وزيادة حجمها، وخاصة مع انتشار ما يسمى بالمواقع الاجتماعية وتطبيقات الجوال وصفحات الوب الحديثة، فهذا النوع من الأنظمة يسمح بحفظ بيانات غير مرتبة وفق بنية معينة Unstructured Data، وليس من الشرط أن تترابط هذه البيانات Not relational، كما يطلق عليها No-SQL Databases. نظام إدارة قاعدة البيانات العلاقية Relational DBMS: وهو النوع الأشهر والأكثر استخداما منذ بداية ظهوره والذي سنعتمده في هذه السلسلة لشرح SQL، حيث تُجمَّع في هذا النوع من الأنظمة البيانات التي لها علاقة ببعضها البعض في مكان واحد يسمى الجدول، مع وجود الإمكانية لربط الجداول مع بعضها البعض بعلاقات ترابط. دورة علوم الحاسوب دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب اشترك الآن ما هو الجدول؟ يُعدّ الجدول العنصر الأساسي في قواعد البيانات العلاقية، وعليه تعتمد أغلب مكونات قاعدة البيانات من مشاهد Views ودوال Functions وحِزم Packages وغيرها من العناصر الأخرى. يتكون الجدول من أعمدة Columns وصفوف Rows، حيث تمثل الأعمدة ما يسمى بالخصائص Features، والصفوف عبارة عن القيم التي تأخذها الأعمدة وتسمى بالسجلات Records. يوضح الشكل التالي مثالا لجدول يحتوي على بيانات تواريخ ميلاد وأسماء طلاب في مدرسة، وفي المثال نوضح مكونات الجدول في قاعدة البيانات. خصائص قواعد البيانات العلاقية ومميزاتها ظلت قواعد البيانات العلاقية مسيطرة منذ بدايات ظهور النموذج الأساسي لها عام 1970 على يد عالم الحاسوب Frank Codd أثناء عمله لصالح شركة IBM، ولم تكن هذه الأفضلية التي يتمتع بها نظام قواعد البيانات العلاقية تأتي من فراغ، بل من الخصائص التي تتمتع بها. البساطة تُرتَّب البيانات في أنظمة قواعد البيانات العلاقية وتُحفَظ بطريقة بعيدة عن التعقيد، حيث يعدّ الجدول الذي تُحفظ فيه البيانات مفهوما لأغلب المستخدمين وخاصة الذين مارسوا أعمالا في مجال البيانات المجدولة أو مراجعة السجلات. سهولة الاستعلام عن البيانات بعد عمليات الإضافة على قاعدة البيانات، وعند الحاجة للرجوع لها، فإن نظام قواعد البيانات العلائقية يوفر آلية سهلة للاستعلام عن هذه البيانات واستردادها، وذلك عن طريق لغة SQL، بالإضافة إلى وجود الإمكانية للمستخدم أن يستعلم عن البيانات من أكثر من جدول في نفس الوقت باستخدام جمل الربط Joins. كما أن خاصية ترشيح Filtering البيانات وتحديد شروط خاصة لظهور سجلات معينة هو أمر متاح بكل سهولة. سلامة البيانات تعدّ هذه الخاصية أساسية في أي نظام قواعد بيانات بغض النظر عن نوعه. ونعني بهذه الخاصية أن تتوفر جميع القدرات والإمكانات في نظام قواعد البيانات لضمان دقة وصحة المعلومات الموجودة فيه. ويندرج تحت هذه الخاصية ما يسمى بقيود التكامل Integrity constraints والتي هي عبارة عن مجموعة من القيود التي يجب الالتزام بها عند التعامل مع البيانات في الجدول، وسنتكلم عنها في مقال متقدم. المرونة تتمتع قواعد البيانات العلاقية بطبيعتها بالمرونة والقابلية للتطوير، مما يجعلها قابلة للتكيف مع طلبات التغيير والزيادة في كم البيانات. وهذا يعني مثلا أنك تستطيع التغيير على هيكلية جدول معين دون التأثير على البيانات الموجودة فيه أو على قاعدة البيانات ككل، كما أنك – مثلا - لن تحتاج إلى وقف قاعدة البيانات وإعادة تشغيلها مرة أخرى لتنفيذ بعض لتغييرات عليها. ما هي البرمجيات التي تقدم قواعد البيانات العلاقية؟ تَتَعدد الشركات والبرمجيات التي تُقدم أنظمة إدارة قواعد البيانات، وكل منها له سوقه ومجاله الذي يشتهر به. نُقدم لكم في الفقرات القادمة بعضًا من أشهر أنظمة إدارة قواعد البيانات العلاقية. قواعد بيانات MySQL أحد أشهر أنظمة قواعد البيانات العلاقية مفتوحة المصدر. تستطيع إنشاء العديد من قواعد البيانات بداخلها، وتستطيع الوصول لها عبر الوِب. تَعمل MySQL على هيئة خِدمة Service تُتيح لأكثر من مستخدم الوصول إلى أكثر من قاعدة بيانات، وتشتهر بين معشر مبرمجي تطبيقات الوِب لارتباطها الشائع مع لغة البرمجة PHP، ويمكن تنصيبها على أكثر من نظام تشغيل مثل وندوز أو لينكس أو ماك. تعدّ MySQL الخيار المفضل للشركات الناشئة أو المتوسطة وذلك لسهولة التعامل معها وانخفاض تكاليف تشغيلها مقارنة بخيارات أخرى. قواعد بيانات أوراكل Oracle تعدّ شركة أوراكل عملاق الشركات البرمجية التي تقدم أنظمة إدارة قواعد البيانات العلاقية، وتأتي قاعدة البيانات أوراكل بأكثر من إصدار (حسب البيئة والغرض) تبدأ من الإصدار الشخصي والخفيف، وتنتهي بالإصدار المتقدم Enterprise. تتميز قواعد بيانات أوراكل بكم كبير من الإمكانات التي تسهل عليك حل العديد من المشاكل والعقبات في التطبيقات التي تديرها وتنشئها، مع وجود دعم فني قوي عبر مجتمع أوراكل، لذلك فهي تعتبر الخيار الإستراتيجي (البعيد المدى) للعديد من الشركات الكبيرة والجامعات والحكومات. قواعد بيانات مايكروسوفت Microsoft SQL Server من قواعد البيانات الشهيرة، والذي تأتي أيضا بأكثر من إصدار، لتلبي احتياجات المستخدمين المختلفة وبيئات عملهم، ولكي تتعامل مع البيانات في هذا النوع تحتاج لاستخدام النسخة الخاصة من SQL والمسماة T-SQL اختصارا ل Transact SQL والتي هي عبارة عن نسخة SQL مضاف عليه ادوال خاصة وتعديلات على طريقة حذف وتعديل السجلات. قواعد بيانات PostgreSQL قواعد بينات PostgreSQL من قواعد البيانات العلاقية المفضلة لدى بعض مطوري تطبيقات الوِب وتطبيقات سطح المكتب، وهو نظام إدارة قواعد بيانات مفتوح المصدر. توجد الكثير من الشركات الكبيرة والعاملة في مجال نطاقات إنترنت تعتمد على هذا النوع من قواعد البيانات.

تعرّفنا في الدروس السابقة على إنشاء الجدول في قاعدة البيانات وإضافة البيانات إليه والتعامل معها من حيث التعديل والإضافة. سوف نبدأ في هذا المقال بالتعرف على أشهر جمل لغة الاستعلام البنائية، وهي جملة الاستعلام Select Statement، حيث سنتكلم عن كيفية كتابة جملة الاستعلام، وأشكالها، وكيفية ترشيح البيانات وتحديد الأعمدة التي نريدها وغيرها من المواضيع. جملة الاستعلام تجلب جملة الاستعلام SELECT بيانات جدول أو أكثر بعد الاستعلام عن وجود هذه الجداول في قاعدة البيانات، ونقصد بالاستعلام هنا ماذا نريد؟ ومن أين؟ ماذا نريد من أعمدة وسجلات، ومن أين، أي من أي الجداول نأتي بالمعلومات. البيانات الناتجة عن تنفيذ جملة الاستعلام تسمى مجموعة البيانات الناتجة Result Data-Set. الصيغة العامة لجملة الاستعلام SELECT column1, column2, ... FROM table_name [WHERE where_condition] [GROUP BY group_by_expression] [ORODER BY order_by_expression]; في بداية كل جملة استعلام نكتب كلمة SELECT (جمل SQL غير حساسة لحالة الأحرف) ومن ثم نُتبعها بأسماء الأعمدة التي نريد الاستعلام عنها، أو نستبدل أسماء الأعمدة برمز * والذي يعني كل الأعمدة، ثم نكتب كلمة From والتي يليها اسم الجدول أو أسماء الجداول التي تحتوي على البيانات التي نريدها. ما بين الأقواس المعكوفة هي جمل إضافية تقوم بمهام معينة في جملة الاستعلام وهي كالتالي: Where: هي جملة الشرط والتي ترشّح البيانات بناءً على الشرط الموجود بعدها. Group By: تجمّع البيانات الناتجة من تنفيذ جملة الاستعلام بناءً على جملة التجميع التي تليها. Order By: ترتّب البيانات تصاعديا أو تنازليا بناءً على جملة الترتيب التي تليها. سنتطرق لتفاصيل الجمل الإضافية في هذا المقال وفي مقالات قادمة. دورة علوم الحاسوب دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب اشترك الآن مثال على جملة الاستعلام لو أردنا الاستعلام عن كافة البيانات الموجودة في جدول Persons والذي تكلمنا عنه في المقال السابق، ننفذ الجملة التالية: SELECT * FROM Persons; كما ذكرتُ سابقا، فإن * تعني عرض جميع البيانات، حيث ستُظهر كافة الأعمدة الموجودة في الجدول والسجلات التي يحتويها. وسيكون ناتج الجملة البيانات التالية: Person_ID First_Name Last_Name Age 101 Ibrahim Mohammed 21 102 Mohammed Khaled 25 103 Saleem Yaser 25 104 Aly Mohammed 25 105 Reem 25 لو أردنا أن نستعلم عن اسم الشخص الأول وعمره، نقوم بتنفيذ الجملة التالية: SELECT First_Name, Age FROM Persons; لاحظ أننا فصلنا بين الأعمدة التي نريد إظهاراها بفاصلة عادية ,، والعمود الأخير لا نكتب بعده فاصلة، بل كلمة From مباشر. وسيكون ناتج الجملة البيانات التالية: First_Name Age Ibrahim 21 Mohammed 25 Saleem 25 Aly 25 Reem 25 الاستعلام عن السجلات الفريدة في بيانات الجدول، ستجد في كثير من الأحيان أن هناك تكراراً للقيم في عمود ما، وقد تحتاج إلى الاستعلام عن القيم دون تكرار، فمثلا، في جدول الأشخاص Persons السابق، ستلاحظ أن عمود العمر Age يحتوي على 5 قيم، ولكن توجد 4 سجلات من نفس القيمة وهي 25، وهنا يأتي دور جملة الاستعلام الفريد DISTINCT Select. تُرجع جملة الاستعلام عن السجلّات الفريدة سجلات دون تكرار في القيم وصيغتها العامة: SELECT DISTINCT column1, column2, ... FROM table_name; لو نفذنا الجملة التالية: SELECT Age FROM Persons; سيكون الناتج: Age 21 25 25 25 25 ولكن لو استخدمنا جملة الاستعلام عن السجلّات الفريدة SELECT DISTINCT Age FROM Persons; ستكون النتيجة كالتالي: Age 21 25 ترشيح السجلات لإجراء عملية ترشيح السجلات، سنضيف إلى جملة الاستعلام جملة شرطية تبدأ بالكلمة Where ويتبعها الشرط (أو مجموعة الشروط) الذي نريد والذي سيُرشِّح السجلات بحيث تبقى السجلات التي تحقق الشرط في مجموعة البيانات الراجعة، وتُستبعد السجلات التي لا تحقق الشرط. الصيغة العامة لجملة الاستعلام والتي تحتوي على شرط لترشيح السجلات: SELECT column1, column2, ... FROM table_name WHERE condition; أمثلة على ترشيح البيانات في جدول Persons الحصول على البيانات الكاملة للشخص الذي له Person_ID يساوي 101: SELECT * FROM Persons WHERE Person_ID = 101; الاستعلام عن أسماء الأشخاص الذين تساوي أعمارهم 25 سنة أو تزيد عليها: SELECT First_Name, Last_Name FROM Persons WHERE Age >= 25; الاستعلام عن الاسم الأول والعمر للأشخاص الذين ليس لديهم قيمة للعمود Last_Name وأعمارهم فوق 22: SELECT First_Name, Age FROM Persons WHERE Age > 22 AND Last_Name IS Null; عمليات المقارنة في جملة Where يلخص الجدول التالي العمليات التي من الممكن استخدامها في بناء شرط جملة Where: العمليّة الوصف مثال = يساوي Age = 20 <> لا يساوي (في بعض النظم تكتب != ) Age <> 20 > أكبر من Age > 20 < أصغر من Age < 20 >= أكبر من أو يساوي Age >= 20 <= أصغر من أو يساوي Age <= 20 BETWEEN … AND بين قيمتين أو يساويهما Age BETWEEN 20 AND 25 LIKE مطابقة نمط First_Name LIKE “%Ibr%” IN يوجد ضمن قيم معينة Age in (20,23,25) ملاحظة هامة: نستطيع الجمع بين أكثر من شرط في جملة Where وذلك باستخدام العمليات المنطقية NOT (للنفي)، AND (وجوب تحقّق جميع الشروط) أو OR (يكفي تحقّق شرط واحد من الشروط). ترتيب السجلات نستطيع الحصول على البيانات الراجعة مرتبة تصاعديا أو تنازليا بعد تنفيذ جملة الاستعلام، وذلك باستخدام جملة Order By. ترتّب الجملةُ السجلات تصاعديًّا وهو الخيار المبدئي، ولترتيبها تنازليًّا نستخدم الكلمة المحجوزة DESC، كما أنه يمكن الترتيب باستخدام عمود واحد أو أكثر. الصيغة العامة لجملة الاستعلام مع جملة الترتيب هي: SELECT column1, column2, ... FROM table_name ORDER BY column1, column2, ... ASC|DESC; فمثلا لو أردنا أن نستعلم عن كل البيانات من جدول Persons بحيث تكون البيانات مرتبة ترتيبا تصاعديا حسب عمود First_Name، نستخدم الجملة التالية: SELECT * FROM Persons ORDER BY First_Name; وستكون النتيجة: Person_ID First_Name Last_Name Age 104 Aly Mohammed 25 101 Ibrahim Mohammed 21 102 Mohammed Khaled 25 105 Reem 25 103 Saleem Yaser 25 في حال أردنا أن نرتب نفس البيانات بطريقة تنازلية نستخدم الجملة التالية: SELECT * FROM Persons ORDER BY First_Name DESC; وتكون نتيجة الاستعلام كالتالي: Person_ID First_Name Last_Name Age 103 Saleem Yaser 25 105 Reem 25 102 Mohammed Khaled 25 101 Ibrahim Mohammed 21 104 Aly Mohammed 25 تجميع البيانات باستخدام Group By: تُستخدم جملة تجميع البيانات غالبا مع دوال التجميع Aggregate Functions بهدف تجميع وترتيب البيانات الناتجة عن الاستعلام حسب عمود أو أكثر. سوف نتكلم عن جملة تجميع البيانات في مقال متقدم لعلاقته بموضوع الدوال الموجودة في SQL.

منذ زمن سحيق، كانت الذاكرةُ أكثر وظيفة نحتاجها ونعتمد عليها في الحاسوب. ورغم اختلاف التقنيات وأساليب التنفيذ الكامنة وراءها، إلّا أنّ معظم الحواسيب تأتي بالعتاد الضروريّ لمعالجة المعلومات وحفظها بأمان لاستخدامها في المستقبل متى احتجنا لها. لقد صار من المستحيل في عالمنا الحديث تخيل أيّ عمل لا يستفيد من هذه القدرة في الأجهزة، سواء كانت خواديم أو حواسيب شخصية أو كفّيّة. تُعالَج البيانات وتُسجَّل وتُسترجَع مع كل عملية، وفي كل مكان من الألعاب إلى الأدوات المتعلقة بالأعمال، بما فيها المواقع. أنظمة إدارة قواعد البيانات (DataBase Management Systems – DBMS) هي برمجيات عالية المستوى تعمل مع واجهات برمجة تطبيقات (APIs) أدنى منها في المستوى، وتلك الواجهات بدورها تهتم بهذه العمليات. لقد تم تطوير العديد من أنظمة إدارة قواعد البيانات (كقواعد البيانات العلائقيّة relational databases، وnoSQL، وغيرها) لعقود من الزمن للمساعدة على حلّ المشكلات المختلفة، إضافة إلى برامج لها (مثل MySQL ,PostgreSQL ,MongoDB ,Redis، إلخ). سنقوم في هذا المقال بالمرور على أساسيّات قواعد البيانات وأنظمة إدارة قواعد البيانات. وسنتعرف من خلالها على المنطق الذي تعمل به قواعد البيانات المختلفة، وكيفية التفرقة بينها. أنظمة إدارة قواعد البياناتإن مفهوم نظام إدارة قاعدة البيانات مظلّةٌ تندرج تحتها كلّ الأدوات المختلفة أنواعها (كبرامج الحاسوب والمكتبات المضمّنة)، والتي غالبًا تعمل بطرق مختلفة وفريدة جدًّا. تتعامل هذه التطبيقات مع مجموعات من المعلومات، أو تساعد بكثرة في التعامل معها. وحيث أن المعلومات (أو البيانات) يُمكِن إن تأتي بأشكال وأحجام مختلفة، فقد تم تطوير العشرات من أنظمة قواعد البيانات، ومعها أعداد هائلة من تطبيقات قواعد البيانات منذ بداية النصف الثاني من القرن الحادي والعشرين، وذلك من أجل تلبية الاحتياجات الحوسبيّة والبرمجية المختلفة. تُبنى أنظمة إدارة قواعد البيانات على نماذج لقواعد البيانات: وهي بُنى محدّدة للتعامل مع البيانات. وكل تطبيق ونظام إدارة محتوى جديد أنشئ لتطبيق أساليبها يعمل بطريقة مختلفة فيما يتعلق بالتعريفات وعمليات التخزين والاسترجاع للمعلومات المُعطاة. ورغم أنّ هناك عددًا كبيرًا من الحلول التي تُنشئ أنظمة إدارة قواعد بيانات مختلفة، إلّا أنّ كلّ مدة زمنية تضمّنت خيارات محدودة صارت شائعة جدًّا وبقيت قيد الاستخدام لمدة أطول، والغالب أنّ أكثرها هيمنة على هذه الساحة خلال العقدين الأخيرين (وربما أكثر من ذلك) هي أنظمة إدارة قواعد البيانات العلائقيّة (Relational Database Management Systems – RDBMS). أنواع قواعد البياناتيستخدم كلُّ نظام إدارة بياناتٍ نموذجًا لقواعد البيانات لترتيب البيانات التي يديرها منطقيًّا. هذه النماذج (أو الأنواع) هي الخطوة الأولى والمحدّد الأهم لكيفية عمل تطبيق قواعد البيانات وكيفية تعامله مع المعلومات وتصرفه بها. هناك بعض الأنواع المختلفة لنماذج لقواعد البيانات التي تعرض بوضوع ودقّة معنى هيكلة البيانات، والغالب أن أكثر هذه الأنواع شهرةً قواعدُ البيانات العلائقيّة. ورغم أنّ النموذج العلائقيّ وقواعد البيانات العلائقيّة (relational databases) مرنة وقويّة للغاية –عندما يعلم المبرمج كيف يستخدمها–، إلّا أنّ هناك بعض المشكلات التي واجهات عديدين، وبعض المزايا التي لم تقدمها هذه الحلول. لقد بدأت حديثًا مجموعة من التطبيقات والأنظمة المختلفة المدعوّة بقواعد بيانات NoSQL بالاشتهار بسرعة كبيرة، والتي قدمت وعودًا لحل هذه المشكلات وتقديم بعض الوظائف المثيرة للاهتمام بشدّة. بالتخلص من البيانات المهيكلة بطريقة متصلّبة (بإبقاء النمط المعرّف في النموذج العلائقيّ (relational model))، تعمل هذه الأنظمة بتقديم طريقة حرّة أكثر في التعامل مع المعلومات، وبهذا توفّر سهولة ومرونة عاليتين جدًّا؛ رغم أنّها تأتي بمشاكل خاصة بها –والتي تكون بعضها جدّيّة– فيما يتعلق بطبيعة البيانات الهامّة والتي لا غنى عنها. النموذج العلائقيّيقدّم النظام العلائقيّ الذي ظهر في تسعينات القرن الماضي طريقة مناسبة للرياضيات في هيكلة وحفظ واستخدام البيانات. توسّع هذه الطريقة من التصاميم القديمة، كالنموذج المسطّح (flat)، والشبكيّ، وغيرها، وذلك بتقديمها مفهوم "العلاقات". تقدّم العلاقات فوائد تتعلق بتجميع البيانات كمجموعات مقيّدة، تربط فيها جداول البيانات –المحتوية على معلومات بطريقة منظمة (كاسم شخص وعنوانه مثلاً)– كل المدخلات بإعطاء قيم للصفات (كرقم هوية الشخص مثلًا). وبفضل عقود من البحث والتطوير، تعمل أنظمة قواعد البيانات التي تستخدم النموذج العلائقيّ بكفاءة وموثوقيّة عاليتين جدًّا. أضف إلى ذلك الخبرة الطويلة للمبرمجين ومديري قواعد البيانات في التعامل مع هذه الأدوات؛ لقد أدّى هذا إلى أن يصبح استخدام تطبيقات قواعد البيانات العلائقيّة الخيار الأمثل للتطبيقات ذات المهام الحرجة، والتي لا يمكنها احتمال فقدان أيّة بيانات تحت أيّ ظرف، وخاصة كنتيجة لخلل ما أو لطبيعة التطبيق نفسه الذي قد يكون أكثر عرضة للأخطاء. ورغم طبيعتها الصارمة المتعلقة بتشكيل والتعامل مع البيانات، يمكن لقواعد البيانات العلائقيّة أن تكون مرنة للغاية وأن تقدم الكثير، وذلك بتقديم قدر ضئيل من المجهود. التوجّه عديم النموذج (Model-less) أو NoSQLتعتمد طريقة NoSQL في هيكلة البيانات على التخلص من هذه القيود، حيث تحرر أساليب حفظ، واستعلام، واستخدام المعلومات. تسعى قواعد بيانات NoSQL إلى التخلص من العلائقات المعقدة، وتقدم أنواع عديدة من الطرق للحفاظ على البيانات والعمل عليها لحالات استخدام معينة بكفاءة (كتخزين مستندات كاملة النصوص)، وذلك من خلال استخدامها توجّها غير منظم (أو الهيكلة على الطريق / أثناء العمل). أنظمة إدارة قواعد بيانات شائعةهدفنا في هذا المقال هو أن نقدم لك نماذج عن بعض أشهر حلول قواعد البيانات وأكثرها استخدامًا. ورغم صعوبة الوصول إلى نتيجة بخصوص نسبة الاستخدام، يمكننا بوضوح افتراض أنّه بالنسبة لغالب الناس، تقع الاختيارات بين محرّكات قواعد البيانات العلائقيّة، أو محرك NoSQL أحدث. لكن قبل البدء بشرح الفروقات بين التطبيقات المختلفة لكل منهما، دعنا نرى ما يجري خلف الستار. أنظمة إدارة قواعد البيانات العلائقيّةلقد حصلت أنظمة إدارة قواعد البيانات العلائقيّة على اسمها من النموذج الذي تعتمد عليه، وهو النموذج العلائقيّ الذي ناقشناه أعلاه. إنّ هذه الأنظمة –الآن، وستبقى لمدة من الزمن في المستقبل– الخيار المفضّل للحفاظ على البيانات موثوقة وآمنة؛ وهي كذلك كفؤة. تتطلب أنظمة إدارة قواعد البيانات العلائقيّة مخططات معرفة ومحددة جيدًا –ولا يجب أن يختلط الأمر مع تعريف PostgreSQL الخاص بهذه الأنظمة– لقبول هذه البيانات. تشكّل هذه الهيئات التي يحددها المستخدم كيفية حفظ واستخدام البيانات. إنّ هذه المخططات شبيهة جدًّا بالجداول، وفيها أعمدة تمثّل عدد ونوع المعلومات التي تنتمي لكل سجل، والصفوف التي تمثّل المدخلات. من أنظمة إدارة قواعد البيانات الشائعة نذكر: SQLite: نظام إدارة قواعد بيانات علائقيّة مضمّن قويّ جدًّا.MySQL: نظام إدارة قواعد بيانات علائقيّة الأكثر شهرة والشائع استخدامه.PostgreSQL: أكثر نظام إدارة قواعد بيانات علائقيّة كيانيّ (objective-RDBMS) متقدم وهو متوافق مع SQL ومفتوح المصدر.ملاحظة: لمعرفة المزيد عن أنظمة إدارة قواعد بيانات NoSQL، راجع المقالة التالية عن الموضوع: A Comparison Of NoSQL Database Management Systems. أنظمة قواعد بيانات NoSQL (أو NewSQL)لا تأتي أنظمة قواعد بيانات NoSQL بنموذج كالمستخدم في (أو الذي تحتاجه) الحلول العلائقيّة المهيكلة. هناك العديد من التطبيقات، وكلّ منها تعمل بطريقة مختلفة كليًّا، وتخدم احتياجات محدّدة. هذه الحلول عديمة المخططات (schema-less) إمّا تسمح تشكيلات غير محدودة للمدخلات، أو –على العكس– بسيطة جدًّا ولكنها كفؤة للغاية كمخازن قيم معتمد على المفاتيح (key based value stores) مفيدة. على خلاف قواعد البيانات العلائقيّة التقليديّة، يمكن تجميع مجموعات من البينات معًا باستخدام قواعد بيانات NoSQL، كـ MongoDB مثلًا. تُبقي مخازن المستندات هذه كل قطعة من البيانات مع بعضها كمجموعة واحدة (أي كملف) في قاعدة البيانات. يمكن تمثيل هذه المستندات ككيانات بيانات منفردة، مثلها في ذلك كمثل JSON، ومع ذلك تبقى كراسات، وذلك يعتمد على خصائصها. ليس لقواعد بيانات NoSQL طريقة موحدة للاستعلام عن البيانات (مثل SQL لقواعد البيانات العلائقيّة) ويقدم كلّ من الحلول طريقته الخاصّة للاستعلام. ملاحظة: لمعرفة المزيد عن أنظمة إدارة قواعد البيانات العلائقيّة، ألق نظرة على هذه المقالة المتعلقة بالموضوع: A Comparison Of Relational Database Management Systems. مقارنة بين أنظمة إدارة قواعد بيانات SQL و NoSQLمن أجل الوصول إلى نتيجة بسيطة ومفهومة، لنحلّل أولًا الاختلافات بين أنظمة إدارة قواعد البيانات: هيكلية ونوع البيانات المحتفظ بها:تتطلب قواعد البيانات العلائقيّة SQL هيكلة ذات خصائص محدّدة للحفاظ على البيانات، على خلاف قواعد بيانات NoSQL التي تسمح بعمليات انسياب حُرّ (free-flow operations). الاستعلام: وبغضّ النظر عن تراخيصها، تستخدم كلّ قواعد البيانات العلائقيّة معيار SQL إلى حدّ ما، ولهذا يمكن الاستعلام فيها بلغة SQL (أي Structured Query Language). أما قواعد بيانات NoSQL فلا تستخدم طريقة محدّدة للعمل على البيانات التي تديرها. التحجيم: يمكن تحجيم كلي الحلين عموديًّا (أي بزيادة موارد النظام). لكن لكون حلول NoSQL تطبيقات أحدث (وأبسط)، فهذا يجعلها تقدّم وسائل أسهل بكثير لتحجيمها أفقيًّا (أي بإنشاء شبكة عنقودية cluster من أجهزة متعدّدة). المتانة Reliability: عندما يتعلق الأمر بالمتانة والثقة الآمنة بالقَيد المنفّذ، تبقى قواعد بيانات SQL الخيار الأفضل. الدعم: لأنظمة إدارة قواعد البيانات العلائقيّة تاريخ طويل استمر لعقود من الزمن. إنها شائعة جدًّا، ومن السهل إيجاد دعم سواء مجانيّ أو مدفوع. إذا حدثت مشكلة، فمن الأسهل حلّها عليها من قواعد بيانات NoSQL التي شاعت حديثًا، وخاصة إذا كان الحلّ موضع السؤال ذا طبيعة معقّدة (مثل MongoDB). احتياجات حفظ واستعلام البيانات المعقدة: إنّ قواعد البيانات العلائقيّة بطبيعتها الخيار الأمثل لاحتياجات حفظ البيانات والاستعلامات المعقّدة. إنها أكثر كفاءة وتتفوق في هذا المجال. ترجمة -وبتصرّف- للمقال Understanding SQL And NoSQL Databases And Different Database Models لصاحبه O.S. Tezer.

بعد أن تكلمنا في المقال السابق عن موضوع جملة الاستعلام في SQL وكيفية الاستعلام عن البيانات في جدول معين وترشيحها وفق الشروط التي نرغب بها، سنتناول في هذا المقال موضوع الفهارس Indexes وما تمثله في قاعدة البيانات، وما هي الفائدة منها. فهرس الجدول لو افترضنا وجود 1000 ملف ورقيّ غير مميزة عن بعضها وتحتوي على بيانات خاصة بطلاب جامعة، وهذه الملفات محفوظة في خزانتين منفصلتين، وأردنا الحصول على بيانات الطلاب الذين يسكنون منطقة معينة، ففي هذه الحالة سنضطر إلى فتح كل الملفات الموجودة في الخزانتيْن والبحث عن فئة الطلاب المستهدفة، وفرزهم والحصول على البيانات المطلوبة. ماذا لو كان لدينا عدد ملفات أكبر؟ سيزداد الوقت والجهد للحصول على البيانات، لذلك، فإن فكرة فهرسة الملفات في هذه الحالة ستكون أمرا جيدا بالتأكيد. سنُفهرِس مثلا الملفات حسب المكان ثم نحفظها في الخزانتين، بحيث تحتوي كل خزانة على بيانات الطلاب لمنطقة أو مناطق معينة. ثم داخل كل خزانة، نستطيع فرز الملفات وحفظها حسب الاسم مثلا. بتطبيق مفهوم الفهرسة، سنوفر على أنفسنا عناء البحث في الخزانتين، وسنقلل الوقت والجهد اللازمين لذلك. الفكرة الرئيسة للفهارس في قاعدة البيانات تدور حول المثال السابق، ففي ظل عصر تضخم البيانات، فإنه أصبح من الملح والضّروريّ وجود تقنيات لتسهيل الوصول السريع للمعلومة. ما هو الفهرس؟ لو أردنا مثلا أن نبحث عن اسم شخص في جدول الأشخاص Persons عبر استخدام الجملة التالية: SELECT * FROM Persons WHERE First_Name = "Ibrahim"; فإن نظام إدارة قاعدة البيانات سيمرّ على كل السجلات الموجودة في الجدول لترشيح السجلات وإرجاع تلك التي توافق الشرط في جملة where. ستظهر لنا مشكلة الوقت اللازم لتنفيذ جملة الاستعلام – وتزداد -كلما زاد عدد السجلات في الجدول، فلو كان لدينا مثلا مليون سجل في الجدول Persons، ولنفترض جدلاً أن النظام باستطاعته المرور على 10 آلاف سجل في الثانية، فإننا بحاجة إلى 100 ثانية لتنفيذ جملة الاستعلام السابقة. لحل المشكلة السابقة، فإن نُظم إدارة قواعد البيانات تقدم خاصية الفَهْرَسة. الفَهْرَسة هي ببساطة عبارة عن مؤشر يحتوي على نسخة من جزء من البيانات في الجدول، بحيث تقوم هذه النسخة من البيانات بمهمة “الدليل” أو “المُؤَشّر” الذي يسرع الوصول إلى البيانات الأصلية الكاملة الموجودة في الجدول، بحيث لا تحتاج المرور الكامل على كل الجدول (No Full Table Scan) عند البحث عن البيانات. يعدّ الفهرس عمليا طريقةً من طُرُق تراكيب البيانات، وهو عنصر مرتبط بوجود جدول في قاعدة البيانات، ولكن نستطيع تعريفه وحذفه منفصلا عن تعريف الجدول، ولا يكون له أي تأثير على نفس البيانات، فعند حذف الفهرس، فإن البيانات الموجودة في الجدول لا تتأثر. يكون الفهرس في أغلب أنظمة إدارة قواعد البيانات من نوع “B-Tree” ويأتي هذا الاسم من بنية البيانات Data structure التي تحمل نفس الاسم، وهو المفضل لأن تُطبقه على العمود الذي يحتوي قيمًا متنوعة وكثيرة مثل الرقم القومي للشخص، وليس من المفضل أن تطبق فهرس “B-Tree” على العمود الذي يحتوي عددًا قليلًا من القيم. توجد أنواع أخرى من الفهارس تُقدمها أنظمة إدارة قواعد البيانات مثل “Bitmap Index” و “Denes Index” ولكننا لن نتكلم عنها هنا لأنها خارج إطار موضوع المقال ولأنها تحتاج إلى مقالة منفصلة لشرحها. كيف تُعرَّف الفهارس؟ يُعرَّف الفهرس بطريقتيْن: تعريفه ضمنيًّا: تُبنَى الفهارس ضمنيا على الأعمدة التي يُطَبَّق عليها القيد الفريد وقيد المفتاح الرئيسي، فعند تعريف أحد القيود السابقة، يُبنى فهرس تلقائيًّا على العمود أو الأعمدة المُقيَّدة. تعريفه صراحةً: يُبنَى الفهرس بطريقة مباشرة على العمود أو الأعمدة الذي نرغب وذلك باستخدام جملة Create Index. على الرغم من أنه لا يوجد تعريف للفهرس في معايير SQL، إلا أن أغلب أنظمة إدارة قواعد البيانات تقدم الإمكانية لتعريف الفهرس ويتفق أغلبها على الصيغة العامة لذلك. الصيغة العامة لتعريف الفهرس: CREATE INDEX index_name ON table_name (column1, column2, ...); عند تعريف الفهرس، لابد أن يكون اسمه متوافقا مع القيود الخاصة بنظام إدارة قاعدة البيانات المستخدم، كما أنه يجب ألا يكون مُكررا، فأسماء الفهارس في قواعد البيانات يجب أن تكون فريدة ولا تتكرر. لإضافة فهرس باسم First_Name_idx على عمود First_Name في الجدول Persons ننفذ الجملة التالية: CREATE INDEX First_Name_idx ON Persons (First_Name); نستطيع تعريف فهرس فريد UNIQUE Index على عمود ممّا يجعل نظام قواعد البيانات يفحص التكرار داخل هذا النوع من الفهارس، حيث يتأكد النظام - في حالة إضافة أو تعديل قيمة لعمود عليه فهرس فريد - من أن هذه القيمة فريدة وغير مكررة؛ وفي حال كانت مكررة، يُرفَض هذا التغيير ويُظهَر خطأ في العملية. مثلا، لو أردنا أن نضيف فهرسًا فريدًا على عمود Age في الجدول Persons ننفذ الجملة التالية: CREATE UNIQUE INDEX Age_idx ON Persons (Age); نستطيع أيضا تعريف الفهرس على أكثر من عمود، كما في المثال التالي: CREATE UNIQUE INDEX Multiple_Columns_idx ON Persons (First_Name ,Age); عرّفنا في المثال السابق فهرسًا على عمودين، وفي هذه الحالة، فإن الفهرس سيفيد في تنفيذ جملة الترتيب Order by التي تحتوي العمود First_Name ثم عمود Age بنفس الترتيب. لن نستفيد من الفهرس السابق في حالة تنفيذ جملة الترتيب بترتيب مختلف للعمودين، ولن نستفيد أيضا منه في حالة تنفيذ جملة الاستعلام المشروطة بالبحث في هذين العمودين، حيث نحتاج لتعريف فهارس أخرى لكل عمود على حدة لتسريع عملية الاستعلام مع جملة Where. حذف الفهارس الصيغة العامة لحذف الفهرس كالتالي: DROP INDEX Index_Name ; فلحذف فهرس باسم Age_idx ننفذ الأمر التالي: DROP INDEX Age_idx ; متى نستخدم الفهارس؟ يفضل أن يتم بناء الفهارس على الأعمدة التي: يُبحث عنها في جملة Where. تُكتَب في جملة الترتيب Order By. تُكتَب في جملة التجميع Group By. تُستخدَم في جمل الربط Joins. تُستخدَم في الدوال الإحصائية مثل min وmax وmedian. متى نتجنب استخدام الفهارس؟ لا تعدّ الفهارس مناسبة على الأعمدة التي: - تحتوي على قيم فريدة قليلة مثل عمود الجنس (قيمتان فقط)، أو الحالة الاجتماعية. - نادرة الاستخدام في جمل الاستعلام SELECT. - التي تكون جزءًا من جدول ذي سجلات قليلة. ملاحظات هامة: لأن الفهرس عنصر مستقل في قواعد البيانات، وبناؤه وتعريفه يعدّ إضافة عليها، فلابد أن يدير مسؤول قاعدة البيانات الصلاحيات اللازمة لهذا الأمر بحيث لا يؤثر سلبا على أداء قاعدة البيانات. لا يعدّ الفهرس أساسيا في بناء الجدول في قاعدة البيانات، وعليه قد لا يحتوي الجدول على فهرس، وقد يحتوي على فهرس أو أكثر. نستطيع أن نُعرّف الفهرس عند بناء الجدول (في نفس جملة بناء الجدول)، ولكن من ناحية عملية، فإن إدارة الفهارس والتعامل معها تعدّ عملية مستمرة ومتكررة. تُبنَى الفهارس وتُحذَف حسب الحاجة للوصول إلى الكفاءة المطلوبة في قاعدة البيانات، لذلك تُقدم نُظم قواعد البيانات الأدوات اللازمة لقياس كفاءة جمل الاستعلام وقياس الحاجة لبناء الفهارس من عدمه. لا تُعَرِّف فهارس أكثر من حاجتك وخاصة في الجداول التي تحتوي سجلات كثيرة، فكما أن الفهارس تُسرع من عملية الوصول للبيانات، فإنها تؤثر سلبا على عمليات الإضافة والتعديل، فعند كل إضافة أو تعديل لابد من تعديل الفهرس ليتلاءم مع التغييرات الجديدة. عند تعريف الفهرس، فإن نظام قاعدة البيانات هو الذي يحافظ على الفهرس ويستخدمه تلقائيا، وعليه لا يُطلب من مسؤول قاعدة البيانات أو المبرمج أو حتى المستخدم أي إجراء آخر بعد تعريف وبناء الفهرس. يُسمى الفهرس الذي يُعرَّف على عمود واحد “فهرسا بسيطا”، والفهرس الذي يُعرَّف على أكثر من عمود يسمى “فهرسا مركبا”.

يختار كثيرون من مطوري الويب الحديث اليوم استخدام قواعد بيانات NoSQL في مشاريعهم، وعادة ما تكون MongoDB اختيارهم الأول. إنّ إنشاء نسخ احتياطية بشكل دوري أمر مهم إن كنت تستخدم قواعد MongoDB في مشاريع في طور التشغيل وذلك بغرض الحفاظ على البيانات من التلف، ولحسن الحظ، توفّر MongoDB أمرًا بسيطًا ضمن أدواتها لإنشاء واستعادة النسخ الاحتياطية. لفهم كيفية عمل النسخ الاحتياطية دون المساس بقواعد بيانات عملك الخاص، سنبدأ المقال بإنشاء قاعدة بيانات جديدة وإضافة قدر بسيط من البيانات إليها، بعد ذلك سنقوم بإنشاء نسخة احتياطية لهذه القاعدة، ومن ثم حذفها واستعادتها من النسخة الاحتياطية التي قمنا بإنشائها. المتطلبات نظام تشغيل Ubuntu 14.04، مستخدم عادي بدون صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ أمر sudo. يمكن مراجعة مقال الإعداد الابتدائي لخادوم أوبنتو 14.04 لمزيد من المعلومات، تثبيت وإعداد MongoDB. الخطوة الأولى: إنشاء قاعدة بيانات تجريبية إنّ إنشاء نسخة احتياطية لقاعدة بيانات فارغة ليس أمرًا مفيدًا، لذا سنقوم في هذه الخطوة بإنشاء قاعدة بيانات تجريبية وإضافة بعض البيانات لها. إنّ أسهل طريقة للتعامل مع MongoDB هي عبر سطر أوامرها الذي يمكن فتحه بتنفيذ الأمر mongo في سطر الأوامر العادي. > mongo بعد ذلك سنقوم بإنشاء قاعدة بيانات جديدة سندعوها myDatabase وذلك باستخدام الأمر المساعد use: $ use myDatabasee سنحصل على الخرج التالي نتيجة لتنفيذ الأمر: switched to db myDatabase ينبغي على جميع البيانات في قاعدة MongoDB أن تتبع لمجموعة collection. وبالرغم من ذلك، فليس هناك حاجة لإنشاء مجموعة بشكل خاص، فعند استخدام التابع insert لإدخال بيانات لمجموعة غير موجودة، سيتم إنشاء المجموعة بشكل تلقائي قبل كتابة البيانات. بإمكانك استخدام الشفرة البرمجية التالية لإضافة 3 سندات documents لمجموعة تدعى myCollection باستخدام التابع insert: db.myCollection.insert([ {'name': 'Alice', 'age': 30}, {'name': 'Bill', 'age': 25}, {'name': 'Bob', 'age': 35} ]); وستظهر الرسالة التالية إن تم تنفيذ الشفرة بنجاح: BulkWriteResult({ "writeErrors" : [ ], "writeConcernErrors" : [ ], "nInserted" : 3, "nUpserted" : 0, "nMatched" : 0, "nModified" : 0, "nRemoved" : 0, "upserted" : [ ] }) الخطوة الثانية: التحقق من حجم قاعدة البيانات الآن وبعد أن حصلنا على قاعدة مع بعض البيانات فيها، سنقوم بأخذ نسخة احتياطية لها. ولكن حجم النسخ الاحتياطية قد يكون كبيرًا إن كانت لديك قاعدة بيانات كبيرة، وبالتالي حتى نتجنب المخاطرة باستهلاك مساحة التخزين المتبقية في القرص، وبالنتيجة إبطاء الخادوم أو منعه من العمل، فيجب أن نتحقق من حجم قاعدة البيانات قبل البدء بالنسخ الاحتياطي. للقيام بذلك بإمكاننا استخدام التابع stats والتحقق من القيمة التي يعيدها المفتاح dataSize لمعرفة حجم القاعدة مقدّرًا بالبايت. $ db.stats().dataSize; وبالنسبة لقاعدة بياناتنا التجريبية فإن الحجم سيكون رقمًا صغيرًا يبلغ 592 بايت. انتبه إلى أن القيمة التي يعطيها dataSize هي قيمة تقريبية لحجم النسخة الاحتياطية. الخطوة الثالثة: إنشاء النسخة الاحتياطية بإمكاننا استخدام الأمر mongodump والذي سيقوم باستدعاء أداة من الأدوات المرفقة مع MongoDb. سيقوم الأمر mongodump بشكل افتراضي بإنشاء نسخة احتياطية لجميع قواعد البيانات المستخدمة. ولإنشاء نسخة احتياطية لقاعدة بيانات معيّنة، يجب إضافة الخيار -d وتحديد اسم القاعدة. إضافة لذلك، يمكن إعلام mongodump بالمكان الذي نرغب بتخزين النسخة الاحتياطية فيه وذلك باستخدام الخيار -o وتحديد المسار. يتم تنفيذ mongodump من سطر الأوامر العادي لذا سنقوم الآن بإنهاء العمل بسطر أوامر mongo والعودة لسطر الأوامر العادي وذلك بالضغط على مفتاحي Ctrl+D. سنقوم بعد ذلك بتنفيذ الأمر mongodump لإنشاء نسخة احتياطية لقاعدتنا myDatabase وتخزين النسخة في المسار backups/first_backup/~: $ mongodump -d myDatabase -o ~/backups/first_backup إن تم تنفيذ الأمر بنجاح فيفترض أن تظهر الرسالة التالية: 2015-11-24T18:11:58.590-0500 writing myDatabase.myCollection to /home/me/backups/first_backup/myDatabase/myCollection.bson 2015-11-24T18:11:58.591-0500 writing myDatabase.myCollection metadata to /home/me/backups/first_backup/myDatabase/myCollection.metadata.json 2015-11-24T18:11:58.592-0500 done dumping myDatabase.myCollection (3 documents) 2015-11-24T18:11:58.592-0500 writing myDatabase.system.indexes to /home/me/backups/first_backup/myDatabase/system.indexes.bson لاحظ بأنّ النسخة الاحتياطية ليست ملفًّا واحدًا بل هو مجلد يملك الهيكل التالي: first_backup └── myDatabase ├── myCollection.bson ├── myCollection.metadata.json └── system.indexes.bson الخطوة الرابعة: حذف قاعدة البيانات لاختبار النسخة الاحتياطية التي قمنا بالحصول عليها، يمكن إما التوجّه لخادوم آخر يملك نسخة MongoDB أخرى أو حذف قاعدة البيانات التجريبية من الخادوم الحالي، وسنختار الخيار الثاني في المقال. لنقم الآن بفتح سطر أوامر mongo ومن ثم الاتصال بقاعدة البيانات: $ mongo myDatabase سنقوم بحذف قاعدة البيانات باستخدام التابع dropDatabase: $ db.dropDatabase(); إن تم حذف القاعدة بنجاح، ستشاهد الرسالة التالية: { "dropped" : "myDatabase", "ok" : 1 } وللتأكد يمكن استخدام التابع find على المجموعة myCollection وسنرى بأن جميع البيانات المدخلة سابقًا قد اختفت. $ db.myCollection.find(); وبطبيعة الحال فلن يكون هناك أي خرج نتيجة لتنفيذ الأمر لعدم وجود بيانات لإظهارها. الخطوة الخامسة: استعادة قاعدة البيانات من النسخة الاحتياطية لاستعادة قاعدة البيانات التي حصلنا على نسخة احتياطية منها باستخدام الأمر mongodump، سنقوم باستخدام أداة أخرى من أدوات Mongo يسمى mongorestore، ولكن قبل استخدامه قم بالعودة لسطر الأوامر العادي بالنقر على مفتاحي Ctrl+D إن كنت ما تزال في سطر أوامر mongo. إن من السهل استخدام أمر mongorestore حيث يكفي تمرير المسار الذي توجد به النسخة الاحتياطية كما في المثال: $ mongorestore ~/backups/first_backup/ وستظهر رسالة تشبه التالية دلالة على نجاح التنفيذ: 2015-11-24T18:27:04.250-0500 building a list of dbs and collections to restore from /home/me/backups/first_backup/ dir 2015-11-24T18:27:04.251-0500 reading metadata file from /home/me/backups/first_backup/myDatabase/myCollection.metadata.json 2015-11-24T18:27:04.252-0500 restoring myDatabase.myCollection from file /home/me/backups/first_backup/myDatabase/myCollection.bson 2015-11-24T18:27:04.309-0500 restoring indexes for collection myDatabase.myCollection from metadata 2015-11-24T18:27:04.310-0500 finished restoring myDatabase.myCollection (3 documents) 2015-11-24T18:27:04.310-0500 done ولاختبار البيانات التي قمنا باستعادتها، سنقوم بفتح سطر أوامر mongo مجددًا والاتصال بقاعدة myDatabase: $ mongo myDatabase ومن ثم نستخدم الأمر find على المجموعة: $ db.myCollection.find(); فإن سار كل شيء على ما يرام، ينبغي الآن أن تظهر لك البيانات المدخلة سابقًا: { "_id" : ObjectId("5654e76f21299039c2ba8720"), "name" : "Alice", "age" : 30 } { "_id" : ObjectId("5654e76f21299039c2ba8721"), "name" : "Bill", "age" : 25 } { "_id" : ObjectId("5654e76f21299039c2ba8722"), "name" : "Bob", "age" : 35 } الخلاصة تعلّمنا كيفية استخدام mongodump و mongorestore لإنشاء نسخة احتياطية واستعادة واحدة تخص قاعدة بيانات MongoDB. تذكر بأن إنشاء نسخة احتياطية هي عملية شرهة لموارد النظام ويمكن لها أن تخفض من أداء محرك MongoDB، لذا ينصح بأن تتم العملية فقط في الساعات التي تكون فيها الطلبات على القاعدة أقل ما يمكن. ترجمة -وبتصرّف- للمقال How to Create and Use MongoDB Backups on Ubuntu 14.04 لصاحبته Hazel Virdó.

يُعدّ محرك قواعد بيانات MongoDB أحد أشهر محرّكات قواعد بيانات NoSQL، ويشتهر بمرونته وقابليته للتوسعة وقوّته ومدى اعتماديّته وسهولة استخدامه. سنتحدث في المقال عن كيفية إجراء نسخ احتياطي واستعادة نسخة احتياطية ونقل قاعدة بيانات MongoDB. عند الحديث عن الاستيراد والتصدير في MongoDB فالمقصود التعامل مع البيانات بصيغة مقروءة من قبل البشر، ومتوافقة مع باقي المنتجات البرمجية. بالمقابل، فإن عمليات النسخ الاحتياطي واستعادة النسخ الاحتياطية تُنشئ أو تَستخدم نمط بيانات ثنائية binary خاصّة بـ MongoDB، وتحافظ بالتالي على تناسق وسلامة البيانات إضافة إلى سمات MongoDB الخاصة. بناء على ما سبق، فإنّه من المفضّل استخدام النسخ الاحتياطي عند الحاجة لتهجير migration قاعدة البيانات طالما أن هناك توافقية ما بين النظام المصدر والنظام الهدف. المتطلبات الأولية قبل أن نتابع، يرجى التأكّد من توفر المتطلبات التالية بشكل كامل: نظام تشغيل Ubuntu، مستخدم عادي بدون صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ أمر sudo. يمكن مراجعة مقال الإعداد الابتدائي لخادوم أوبنتو 14.04 لمزيد من المعلومات، تثبيت وإعداد MongoDB. وعدا عمّا قد يستثنى بوضوح، فإنّ جميع الأوامر التي تحتاج لصلاحيات مدير نظام root في المقال، يجب أن يتم تنفيذها من قبل مستخدم عادي يملك صلاحيات sudo. نسخة قاعدة بيانات MongoDB تجريبية، ويمكن الحصول على واحدة وتثبيتها وفق التعليمات المذكورة في مقال استيراد وتصدير قاعدة بيانات MongoDB في نظام أوبنتو 14.04. تنبيه: يجب تنفيذ جميع الأوامر المذكورة في المقال بصلاحيات المستخدم العادي من خلال أمر sudo ويستثنى من ذلك ما يذكر صراحة أن يتم تنفيذه وفق صلاحيات مدير النظام root. فهم الأساسيات سنحتاج لفهم بعض الأمور قبل أن نتابع أكثر في المقال، وإن كنت تملك بعض الخبرة مع قواعد البيانات العلائقية relational المشهورة مثل MySQL، فربّما تجد بعض التشابه عند العمل مع MongoDB. إنّ أول ما تحتاج معرفته حول MongoDB هو أنها تستخدم صيغتي json و bson (الصيغة الثنائية binary من json) بغرض تخزين المعلومات. إنّ Json هي صيغة مقروءة من قبل البشر وبالتالي مناسبة جدًا لتصدير واستيراد البيانات في نهاية الأمر، ومن الممكن أيضًا التعديل على البيانات المصدّرة باستخدام أيّ أداة تدعم json، بما في ذلك أي محرر نصوص بسيط. يبدو أحد الأمثلة عن مستند json على الشكل التالي: {"address":[ {"building":"1007", "street":"Park Ave"}, {"building":"1008", "street":"New Ave"}, ]} إنّ Json مناسبة جدًا للعمل معها، لكنها لا تدعم جميع أنماط البيانات المتاحة في bson، وهذا يعني بأنّه سيكون لدينا "فقدان في الدقّة" في البيانات عند استخدام json، ولهذا السبب فإنّه من الأفضل استخدام الصيغة الثنائية bson في حالة النسخ الاحتياطي والاستعادة لأنّها ستساعد في استعادة قاعدة بيانات MongoDB بشكل أدق. ثانيًا، ليس هناك داعٍ للقلق حول إنشاء قاعدة البيانات إن لم تكن موجودة أصلًا عند القيام باستعادة نسخة احتياطية، حيث سيتم إنشاؤها بشكل تلقائي. إضافة لذلك، فإنّ هيكل المجموعات collections (التي تُقابل الجداول) في القاعدة -بخلاف محركات قواعد البيانات الأخرى- سيتم إنشاؤها أيضًا بشكل تلقائي عند إدراج insert أول سطر. ثالثًا، إن قراءة وإدراج كمّية كبيرة من البيانات في MongoDB، قد يستهلك مصادر النظام كقدرة المعالج، الذاكرة ومساحة التخزين بشكل كبير جدًا وهذه نقطة حساسة على اعتبار أن MongoDB تُستخدم عادة مع قواعد البيانات الكبيرة والبيانات الضخمة، والحل الأسهل لهذه المشكلة هو تنفيذ عمليات التصدير والنسخ الاحتياطي ليلًا. رابعًا، فقد يكون هناك مشكلة في تناسق البيانات إن كنت تملك خادوم MongoDB معرّض لضغط العمل باستمرار وبالتالي قد تتغير البيانات أثناء عملية التصدير، حيث لا يوجد حل بسيط لهذه المشكلة ولكن في نهاية المقال سنتحدث حول استنساخ البيانات replication. وعلى الرغم من أنه من الممكن استخدام وظائف الاستيراد والتصدير للحصول على نسخة احتياطية أو استعادتها، تبقى هناك طرق أفضل لتضمن دقة البيانات في قاعدة MongoDB، ومن هذه الطرق استخدام الأمر mongodump للحصول على نسخة احتياطية للبيانات، والأمر mongorestore لاستعادة نسخة احتياطية سابقة. الحصول على نسخة احتياطية لقاعدة بيانات MongoDB لنتحدث أولًا عن الحصول على نسخة احتياطية لقاعدة البيانات. يقوم المُعامل db-- في الأمر mongodump بتحديد اسم قاعدة البيانات التي نرغب بالحصول على نسخة احتياطية لها، فإن لم يتم تحديد اسم قاعدة البيانات، سيقوم الأمر بإنشاء نسخة احتياطية لجميع قواعد البيانات التي يديرها محرّك MongoDB. أما لتحديد مسار المجلّد الذي سيتم تخزين النسخ الاحتياطية فيه فنستخدم المُعامل out--. لنرى المثال التالي للحصول على نسخة احتياطية من قاعدة بيانات اسمها newdb ولتخزين النسخة في مجلد var/backups/mongobackups/. نصيحة: من الأفضل أن يتم تخزين كل نسخة احتياطية في مجلد فرعي يُسمّى بتاريخ اليوم الذي تم إنشاء النسخة الاحتياطية فيه، مثل var/backups/mongobackups/01-20-16/ (العشرون من كانون الثاني 2016). لنقم أولًا بإنشاء المجلد الرئيسي الذي سنقوم فيه بتخزين النسخ الاحتياطية لقواعد MongoDB التي نملكها، ونستخدم لذلك الأمر: $ sudo mkdir /var/backups/mongobackups ثم نقوم بإنشاء نسخة احتياطية بالأمر التالي: $ sudo mongodump --db newdb --out /var/backups/mongobackups/`date +"%m-%d-%y"` فإن تم تنفيذ الأمر بنجاح، سيظهر ما يشبه النتيجة التالية على الشاشة: 2016-01-20T10:11:57.685-0500 writing newdb.restaurants to /var/backups/mongobackups/01-20-16/newdb/restaurants.bson 2016-01-20T10:11:57.907-0500 writing newdb.restaurants metadata to /var/backups/mongobackups/01-20-16/newdb/restaurants.metadata.json 2016-01-20T10:11:57.911-0500 done dumping newdb.restaurants (25359 documents) 2016-01-20T10:11:57.911-0500 writing newdb.system.indexes to /var/backups/mongobackups/01-20-16/newdb/system.indexes.bson لاحظ في الأمر الذي قمنا بتنفيذه أننا أدرجنا الجزء التالي "date +"%m-%d-%y الذي يقوم بالحصول على تاريخ اليوم بشكل تلقائي، وبالتالي نحصل على نسخة احتياطية داخل مجلد فرعي /var/backups/mongobackups/01-20-16/، وهذا مناسب جدًا إن قمنا بجدولة الأمر ليتم تنفيذه بصورة اوتوماتيكية. عند الوصول إلى هذه المرحلة نكون قد حصلنا على نسخة احتياطية لقاعدة البيانات المسمّاة newdb في المسار /var/backups/mongobackups/01-20-16/newdb/، وتملك هذه النسخة جميع المعلومات اللازمة لاستعادة حالة القاعدة newdb في حال حصول مشكلة فيها. وكقاعدة عامة، يجب أن يتم الحصول على نسخ احتياطية بشكل دوري، على أساس نسخة احتياطية يومية مثلًا، ويستحسن أن يتم تنفيذ العملية في الوقت الذي يكون نشاط الخادوم أقل ما يمكن، وللقيام بذلك يمكن جدولة تنفيذ الأمر mongodump باستخدام cron حتى يتم تنفيذه بصورة دورية، مثلاً، الساعة 3:03 صباحًا من كل يوم. لتنفيذ ذلك سنقوم بفتح محرّر cron المسمّى crontab على الشكل التالي: $ sudo crontab -e ملاحظة: عندما يتم تنفيذ الأمر sudo crontab فإننا نقوم بتحرير المهام المجدولة الخاصة بحساب المستخدم مدير النظام root. إن هذا مستحسن لأنه في حال جدولة الأمر mongodump ليتم تنفيذه بصلاحيات مستخدم آخر فقد لا يتم التنفيذ بشكل صحيح وخصوصًا إن كانت إعدادات sudo تتطلب تأكيد الأمر بإدخال كلمة المرور. سنقوم في crontab بإدخال السطر التالي: 3 3 * * * mongodump --out /var/backups/mongobackups/`date +"%m-%d-%y"` لاحظ أننا لم نستخدم المعامل db-- في الأمر السابق لأننا نرغب بالحصول على نسخة احتياطية دورية لجميع القواعد التي نملكها. إن تنفيذ النسخ الاحتياطي الدوري سيؤدي مع الوقت إلى استهلاك مساحة التخزين على القرص الصلب، لذا فمن الأفضل أن يتم حذف النسخ الاحتياطية القديمة بصورة دورية أو خفض المساحة التي تستهلكها عبر ضغطها. لحذف النسخ الاحتياطية التي تم الحصول عليها قبل 7 أيام يمكن أن نستخدم الأمر التالي: $ find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} \; وكما في الأمر المُجدول السابق فمن الممكن التخلص من النسخ الاحتياطية القديمة بصورة دورية عبر تنفيذ الأمر قبل أمر النسخ الاحتياطي، ولأجل هذا سنقوم بإدراج السطر التالي في cron، والذي سيتم تنفيذه الساعة 3:01 صباحًا من كل يوم: 3 1 * * * find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} \; وبإتمام الخطوات السابقة نكون قد ضمنّا حلًا مناسبًا للنسخ الاحتياطي لقواعد بيانات MongoDB. استعادة نسخة احتياطية لقاعدة بيانات MongoDB إن استعادة نسخة احتياطية سابقة لقاعدة بيانات MongoDB (كالتي حصلنا عليها من الخطوة السابقة) تتم باستخدام الأمر mongorestore والذي يمكّنك من الحصول على نسخة مطابقة تمامًا لبيانات القاعدة كما كانت في لحظة إنشاء النسخة الاحتياطية، متضمنًا ذلك جميع الفهارس وأنماط البيانات، وهذه مسألة مفيدة جدًا إن رغبت بنقل قاعدة البيانات. ومتابعة من المثال السابق، لنرى كيف من الممكن استعادة نسخة احتياطية سابقة. سنقوم باستخدام المُعامل db-- مع الأمر mongorestore لتحديد القاعدة التي نرغب باستعادة النسخة الاحتياطية إليها، كما سنستخدم المُعامل drop-- كي نضمن أن يتم حذف القاعدة القديمة حتى تتم استعادة النسخة الاحتياطية إلى نسخة جديدة من القاعدة لا تحتوي أي مشاكل، وأخيرًا سنقوم بتحديد مسار النسخة الاحتياطية التي نرغب باستعادتها; سيظهر الأمر كاملًا على النحو التالي (لا تنس استبدال المسار بمسار النسخة الموجودة لديك والتي ترغب باستعادتها): $ sudo mongorestore --db newdb --drop /var/backups/mongobackups/01-20-16/newdb/ وسيظهر ما يشبه الخرج التالي على الشاشة في حال تنفيذ الأمر بالشكل الصحيح: 2016-01-20T10:44:47.876-0500 building a list of collections to restore from /var/backups/mongobackups/01-20-16/newdb/ dir 2016-01-20T10:44:47.908-0500 reading metadata file from /var/backups/mongobackups/01-20-16/newdb/restaurants.metadata.json 2016-01-20T10:44:47.909-0500 restoring newdb.restaurants from file /var/backups/mongobackups/01-20-16/newdb/restaurants.bson 2016-01-20T10:44:48.591-0500 restoring indexes for collection newdb.restaurants from metadata 2016-01-20T10:44:48.592-0500 finished restoring newdb.restaurants (25359 documents) 2016-01-20T10:44:48.592-0500 done وفي هذه الحالة نكون قد أنجزنا استعادة نسخة احتياطية للقاعدة على الخادوم ذاته. أمّا لو رغبنا بنقل البيانات من خادوم لآخر باستخدام نفس الطريقة، فكُل ما نحتاجه هو نسخ مجلد النسخة الاحتياطية /var/backups/mongobackups/01-20-16/newdb/ إلى الخادوم الجديد قبل تنفيذ أمر استعادة النسخة الاحتياطية على الخادوم الجديد. الخلاصة تعرّفنا في المقال على أساسيات إدارة بيانات قاعدة MongoDB فيما يخص النسخ الاحتياطي والاستعادة من نسخة احتياطية سابقة، ونقل قاعدة البيانات من خادوم لآخر. إن آلية النسخ المُتماثل للبيانات ليست مهمّة بغرض قابلية التوسعة فحسب، وإنما مهمّة للموضوع الذي نتحدث عنه الآن، حيث تسمح الآلية باستمرارية تشغيل خدمة MongoDB دون توقّف أو انقطاع من خلال خادوم MongoDB ثانوي بينما يتم استعادة نسخة احتياطية على الخادوم الرئيسي في حال حدوث خلل ما فيه. وتعتبر سجلّات التشغيل (operations log (oplog جزءًا من آلية النسخة المُتماثل، حيث تقوم هذه السجلّات بتخزين جميع العمليات التي قامت بتغيير البيانات، ومن الممكن استخدام هذا السجل -كما يستخدم السجل الثنائي binary log في MySQL- بغرض استعادة البيانات بعد آخر نسخة احتياطية. تذكّر بأن النسخ الاحتياطي عادة يتم في فترة متأخرة من الليل، فإن قررت استعادة نسخة احتياطية ليلًا (قبل أن تبدأ عملية النسخ الاحتياطي) فستفقد جميع البيانات الجديدة التي لم يتم الحصول على نسخة احتياطية لها أولًا. ترجمة -وبتصرّف- للمقال How To Back Up, Restore, and Migrate a MongoDB Database on Ubuntu 14.04 لصاحبه Anatoliy Dimitrov.

يُعدّ MongoDB أحد أشهر محركات قواعد البيانات من نوع NoSQL، فهو شهير بمرونته، فعاليّته، موثوقيته وسهولة استخدامه، وسنستعرض في المقال كيفية استيراد وتصدير قواعد بيانات MongoDB. تجدر الإشارة إلى أنّه عند حديثنا عن الاستيراد والتصدير فالمقصود التعامل مع البيانات بصيغة مقروءة من قبل البشر، ومتوافقة مع باقي المنتجات البرمجية. بالمقابل، فإن عمليات النسخ الاحتياطي واستعادة النسخ الاحتياطية تُنشئ أو تَستخدم نمط بيانات ثنائية binary خاصّة بـ MongoDB، وتحافظ بالتالي على تناسق وسلامة البيانات إضافة إلى سمات MongoDB الخاصة. بناء على ما سبق، فإنّه من المفضّل استخدام النسخ الاحتياطي عند الحاجة لنقل/تهجير migration قاعدة البيانات طالما أن هناك توافقية ما بين النظام المصدر والنظام الهدف، وهذا الموضوع خارج إطار حديثنا. المتطلبات الأولية قبل أن نتابع، يرجى التأكّد من توفر المتطلبات التالية بشكل كامل: نظام تشغيل Ubuntu 14.04، مستخدم عادي بدون صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ أمر sudo. يمكن مراجعة الإعداد الابتدائي لخادوم أوبنتو 14.04 لمزيد من المعلومات، تثبيت وإعداد MongoDB. وعدا عمّا قد يستثنى بوضوح، فإنّ جميع الأوامر التي تحتاج لصلاحيات مدير نظام root في المقال، يجب أن يتم تنفيذها من قبل مستخدم عادي يملك صلاحيات sudo. فهم الأساسيات سنحتاج لفهم بعض الأمور قبل أن نتابع المقال، وإن كنت تملك بعض الخبرة مع قواعد البيانات العلائقية relational المشهورة مثل MySQL، فربّما تجد بعض التشابه عند العمل مع MongoDB. إنّ أول ما تحتاج معرفته حول MongoDB هو أنها تستخدم صيغتي json و bson (الصيغة الثنائية binary من json) بغرض تخزين المعلومات. إنّ Json هي صيغة مقروءة من قبل البشر وبالتالي مناسبة جدًا لتصدير واستيراد البيانات في نهاية الأمر، ومن الممكن أيضًا التعديل على البيانات المصدّرة باستخدام أيّ أداة تدعم json، بما في ذلك أي محرر نصوص بسيط. يبدو أحد الأمثلة عن مستند json على الشكل التالي: {"address":[ {"building":"1007", "street":"Park Ave"}, {"building":"1008", "street":"New Ave"}, ]} إنّ Json مناسبة جدًا للعمل معها، لكنها لا تدعم جميع أنماط البيانات المتاحة في bson، وهذا يعني بأنّه سيكون لدينا "فقدان في الدقّة" في البيانات عند استخدام json، ولهذا السبب فإنّه من الأفضل استخدام الصيغة الثنائية bson في حالة النسخ الاحتياطي والاستعادة لأنّها ستساعد في استعادة قاعدة بيانات MongoDB بشكل أدق. ثانيًا، ليس هناك داعٍ للقلق حول إنشاء قاعدة البيانات إن لم تكن موجودة أصلًا عند القيام باستعادة نسخة احتياطية، حيث سيتم إنشاؤها بشكل تلقائي. إضافة لذلك، فإنّ هيكل المجموعات collections (التي تُقابل الجداول) في القاعدة -بخلاف محركات قواعد البيانات الأخرى- سيتم إنشاؤها أيضًا بشكل تلقائي عند إدراج insert أول سطر. ثالثًا، إن قراءة وإدراج كمّية كبيرة من البيانات في MongoDB، قد يستهلك مصادر النظام كقدرة المعالج، الذاكرة ومساحة التخزين بشكل كبير جدًا وهذه نقطة حساسة على اعتبار أن MongoDB تُستخدم عادة مع قواعد البيانات الكبيرة والبيانات الضخمة، والحل الأسهل لهذه المشكلة هو تنفيذ عمليات التصدير والنسخ الاحتياطي ليلًا. رابعًا، فقد يكون هناك مشكلة في تناسق البيانات consistency إن كنت تملك خادوم MongoDB معرّض لضغط العمل باستمرار وبالتالي قد تتغير البيانات أثناء عملية التصدير، حيث لا يوجد حل بسيط لهذه المشكلة ولكن في نهاية المقال سنتحدث حول استنساخ البيانات replication. استيراد المعلومات إلى قاعدة بيانات MongoDB لنتعلّم كيفية استيراد المعلومات إلى قاعدة بيانات MongoDB، سنقوم باستخدام عيّنة قاعدة بيانات معروفة حول المطاعم. إنّ القاعدة بصيغة json ويمكن تحميلها باستخدام الأمر wget بالشكل التالي: $ wget https://raw.githubusercontent.com/mongodb/docs-assets/primer-dataset/primer-dataset.json وحالما ينتهي التحميل ستحصل على ملف حجمه 12 ميغابايت يُدعى primer-dataset.json في المجلّد الذي قمت بتنفيذ الأمر فيه. سنقوم باستيراد البيانات من هذا الملف إلى قاعدة بيانات جديدة سنسمّيها newdb وضمن جدول سنسمّيه restaurants. للقيام بعملية الاستيراد سنستخدم الأمر mongoimport على الشكل التالي: $ sudo mongoimport --db newdb --collection restaurants --file primer-dataset.json ويُفترض أن تكون نتيجة تنفيذ الأمر السابق على الشكل التالي: 2016-01-17T14:27:04.806-0500 connected to: localhost 2016-01-17T14:27:07.315-0500 imported 25359 documents وكما يظهر في الناتج السابق، فقد تم استيراد 25359 مستند، ولأننا لم نكن نملك قاعدة بيانات باسم newdb، فقد قام محرّك MongoDB بإنشائها بشكل تلقائي، وللتأكّد من نجاح عملية الاستيراد سنقوم بالاتصال بقاعدة البيانات newdb على الشكل التالي: $ sudo mongo newdb سنلاحظ عند تنفيذ الأمر بأن شكل مِحرف سطر الأوامر قد تغيّر، مما يشير إلى نجاح الاتصال بقاعدة البيانات، وللتحقق الآن من عدد المستندات التي تم استيرادها، سنقوم بتنفيذ الأمر التالي: > db.restaurants.count() ويفترض أن تكون النتيجة 25359، وهو مطابق تمامًا لعدد المستندات المستوردة. وللتحقق بشكل أفضل من نجاح الاستيراد، سنقوم باختيار المستند الأول من مجموعة المطاعم بتنفيذ الأمر التالي: > db.restaurants.findOne() وينبغي أن تكون النتيجة على الشكل التالي: { "_id" : ObjectId("569beb098106480d3ed99926"), "address" : { "building" : "1007", "coord" : [ -73.856077, 40.848447 ], "street" : "Morris Park Ave", "zipcode" : "10462" }, "borough" : "Bronx", "cuisine" : "Bakery", "grades" : [ { "date" : ISODate("2014-03-03T00:00:00Z"), "grade" : "A", "score" : 2 }, ... ], "name" : "Morris Park Bake Shop", "restaurant_id" : "30075445" } إنّ مثل هذا التحقق قد يظهر أيّ مشاكل في محتوى المستندات أو ترميزها أو ما شابه ذلك، فصيغة json تستخدم ترميز UTF-8 ويجب أن تكون البيانات المصدّرة والمستوردة بهذا الترميز. تذكّر هذا الأمر دومًا عند القيام بتحرير ملفات json بشكل يدوي، وفيما عدا ذلك فإنّ محرك MongoDB سيتولّى الأمر عنك بشكل تلقائي. أخيرًا، للخروج من سطر أوامر MongoDB نقوم بتنفيذ الأمر exit على الشكل: > exit وسيتم الخروج والعودة إلى سطر أوامر النظام كمستخدم عادي. تصدير المعلومات من قاعدة بيانات MongoDB كما ذكرنا سابقًا، فإنّه من الممكن الحصول على بيانات مقروءة ومفهومة عند القيام بتصدير المعلومات من قاعدة MongoDB، وتكون صيغة الملف المصدّر بشكل افتراضي هي json، ولكن من الممكن أيضًا الحصول على البيانات في ملف بصيغة (csv (comma separated value. نستخدم الأمر mongoexport لتصدير البيانات من قاعدة MongoDB، ويسمح أمر التصدير باختيار قاعدة بيانات، مجموعة من المجموعات collection، حقل من الحقول، وحتّى استخدام استعلام من أجل التصدير. وكمثال بسيط على أمر التصدير mongoexport، سنقوم بتصدير مجموعة المطاعم من قاعدة newdb التي قمنا باستيرادها سابقًا، ويبدو الأمر على النحو التالي: $ sudo mongoexport --db newdb -c restaurants --out newdbexport.json حيث قمنا في الأمر السابق باستخدام المُعامل db-- لتحديد القاعدة، والمُعامل c- لتحديد المجموعة، والمُعامل --out لتحديد اسم الملف الذي سيتم تصدير البيانات إليه، وستكون نتيجة تنفيذ الأمر السابق بشكل ناجح على النحو التالي: 2016-01-20T03:39:00.143-0500 connected to: localhost 2016-01-20T03:39:03.145-0500 exported 25359 records ويظهر الأمر السابق أنه قد تم تصدير 25359 مستند، وهو مماثل تمامًا لعدد المستندات التي قمنا باستيرادها سابقًا. قد نحتاج في بعض الأحيان إلى تصدير جزء من مجموعة، وبالأخذ بعين الاعتبار هيكل ومحتوى مستند المطاعم بصيغة json، سنقوم بتصدير معلومات جميع المطاعم التي تحقق الشرط الذي يقول بأنها موجودة في المنطقة الإدارية المسمّاة Bronx والتي تقدّم الطعام الصيني. للحصول على هذه المعلومات بشكل مباشر في حال كنّا متصلين بقاعدة MongoDB من خلال سطر أوامر MongoDB، فسنقوم بالاتصال بقاعدة البيانات مجددًا: $ sudo mongo newdb ومن ثم سنستخدم الاستعلام: > db.restaurants.find( { borough: "Bronx", cuisine: "Chinese" } ) وسيتم عرض النتيجة مباشرة، وللخروج من سطر أوامر MongoDB سننفّذ الأمر exit كما ذكرنا سابقًا. أمّا لتصدير البيانات من سطر أوامر النظام دون أن نكون متصلين بقاعدة البيانات مسبقًا، فسنقوم بتمرير الاستعلام السابق كمُعامل لأمر mongoexport باستخدام المُعامل q- على الشكل التالي: $ sudo mongoexport --db newdb -c restaurants -q "{ borough: 'Bronx', cuisine: 'Chinese' }" --out Bronx_Chinese_retaurants.json لاحظ في الأمر السابق بأنّا قمنا باستخدام علامات الاقتباس الفرديّة ' داخل علامات الاقتباس الزوجيّة " لأنّ هذا شرط من شروط كتابة الاستعلام في سطر الأوامر، ولو احتجنا لاستخدام علامات اقتباس زوجيّة أو إشارة $ فسنحتاج لتخطي المحارف الخاصة باستخدام \ بإدراجها قبل المحرف الخاص في الاستعلام. إن تمت عملية التصدير بنجاح فينبغي أن تكون النتيجة على الشكل التالي: 2016-01-20T04:16:28.381-0500 connected to: localhost 2016-01-20T04:16:28.461-0500 exported 323 records تُظهر النتيجة السابقة بأنّ هناك 323 سجل قد تم تصديره، ويمكن إيجادها ضمن ملف Bronx_Chinese_retaurants.json الذي قمنا بتحديده. الخلاصة تعرفّنا في المقال على أساسيات استيراد وتصدير المعلومات من وإلى قاعدة بيانات MongoDB. إنّ عملية الاستنساخ replication مفيدة في حالة التوسعة، ولكنّها مهمة أيضًا للنواحي التي تحدثنا عنها، حيث تسمح باستمرارية تشغيل خدمات MongoDB دون انقطاع عبر خادوم MongoDB ثانوي بينما نقوم باستعادة نسخة احتياطية إلى الخادوم الرئيسي عند حدوث فشل. إن جزءًا من عملية الاستنساخ هو سجل العمليات (oplog)، الذي يقوم بتسجيل جميع العمليات التي تقوم بتغيير البيانات، ويمكن استخدام هذا السجل كما في MySQL، لاستعادة البيانات بعد أن تكون آخر عملية نسخ احتياطي قد بدأت. تذكّر بأن عمليات النسخ الاحتياطي تحصل في الليل عندما يكون نشاط قاعدة البيانات في حدّه الأدنى، وإن قررت استعادة نسخة احتياطية لقاعدة البيانات في الفترة المسائية (أي قبل أن تبدأ عملية النسخ الاحتياطي الليلية) فإنّك ستفقد بذلك جميع التعديلات التي تمت على القاعدة منذ آخر عملية نسخ احتياطي. ترجمة -وبتصرّف- للمقال How To Import and Export a MongoDB Database on Ubuntu 14.04 لصاحبه Anatoliy Dimitrov.