تُعَدّ القيود 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 وعندها ستحتاج إلى اختيار أنواع بيانات قابلة للموازنة.

1. اشرح قواعد العلاقة relationship rules لكل علاقة مثل العلاقة بين الجدولين tblEnrollment وtblStudents التي تمثِّل إمكانية تسجيل الطالب في صفوف سباحة متعددة.
2. حدّد عددية cardinality كل علاقة بافتراض القواعد التالية:

• قد يكون أو لا يكون للمسبح pool صفًا class للسباحة.
• يجب ارتباط جدول المستويات levels table دائمًا بصف سباحة واحد على الأقل.
• قد لا يدرِّس جدول فريق التدريب staff table أيَّ صف سباحة.
• يجب تسجيل جميع الطلاب في صف سباحة واحد على الأقل.
• يجب احتواء صف السباحة على طلاب مسجلين فيه.
• يجب امتلاك صف السباحة على مسبح صالح.
• قد لا يُعيَّن مدرب لصف السباحة.
• يجب ارتباط صف السباحة دائمًا بمستوى موجود.

3. حدّد الجداول الضعيفة، والجداول القوية التي شرحناها في مقالٍ سابق.
4. حدّد الجداول المُعرَّفة 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 بمفتاحين خارجيين على الأقل.
• قد تحتوي على سمات أخرى.
• يحدِّد كل مفتاح خارجي جدولًا مرتبطًا بالكيان نفسه.
• هناك ثلاثة خيارات للمفتاح الرئيسي:

1. استخدِم مزيجًا من المفاتيح الخارجية للجداول المرتبطة إذا كانت فريدة.
2. استخدِم مزيجًا من المفاتيح الخارجية وعمودًا مؤهِلًا.
3. أنشِئ مفتاح رئيسي بسيط جديد.

الكيانات المتميزة

توفر الكيانات المميَّزة Characteristic entities مزيدًا من المعلومات حول جدول آخر، ولهذه الكيانات الخصائص التالية:

• تمثِّل سمات متعددة القيم.
• تصِف كيانات أخرى.
• عادة ما يكون لديها علاقة علاقة واحد إلى متعدِّد one to many relationship.
• يُستخدَم المفتاح الخارجي foreign key لتحديد الجدول المميز characterized table.
• خيارات المفتاح الرئيسي هي:

1. استخدِم مزيجًا من المفاتيح الخارجية وعمودًا مؤهِلًا.
2. أنشِئ مفتاحًا رئيسيًا بسيطًا جديدًا في قاعدة بيانات الشركة 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 عندما يكون أحد الحدود قيمةً فارغةً null، كما تكون النتيجة قيمةً فارغةً null في العمليات الحسابية إذا كان أحد الحدود قيمةً فارغةً null باستثناء الدوال التي تتجاهل هذه القيمة.

مثال لكيفية استخدام القيمة الفارغة null

استخدم جدول الرواتب Salary_tbl الموجود في الشكل التالي لمعرفة كيفية استخدام القيمة الفارغة 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 تكافئ many أي N = many.

• لكل علاقة (n-ary) حيث n > 2، أنشئ جدولًا جديدًا لتمثيل تلك العلاقة.
• المفتاح الرئيسي للجدول الجديد هو مزيج من المفاتيح الرئيسية للكيانات المشاركة التي تمثل الجانب المتعدِّد N.
• تملك جميع الكيانات المشاركة في معظم حالات علاقة n-ary الطرف المتعدِّد من جانبها.

الشكل 9: العلاقة الثلاثية

تمارين

1. ما المفهومان اللذان يعتمد عليهما نموذج الكيان والعلاقة ER؟
2. تتكون قاعدة البيانات في الشكل التالي من جدولين، لذلك أجب على الأسئلة التالية مستخدمًا هذا الشكل.

جدول DIRECTOR:

جدول PLAY:

جداول التمرين

1. حدِّد المفتاح الرئيسي لكل جدول.
2. حدِّد المفتاح الخارجي في الجدول PLAY.
3. حدِّد المفاتيح المرشَّحة في كلا الجدولين.
4. ارسم نموذج الكيان والعلاقة ER.
5. هل يحقق الجدول PLAY سلامةً مرجعيةً؟ ولمَ؟ أو لمَ لا؟

3. عرف المصطلحات التالية، حيث قد تحتاج إلى البحث في الانترنت

• المخطط schema.
• لغة المضيف host language.
• اللغات الفرعية للبيانات data sublanguage.
• لغة تعريف البيانات data definition language.
• العلاقة الأُحادية unary relation.
• المفتاح الخارجي foreign key.
• العلاقة الافتراضية virtual relation.
• الربط connectivity.
• المفتاح المركَّب composite key.
• جداول الربط linking table.

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

الجدول TRUCK

الجدول BASE

الجدول TYPE

• حدِّد المفتاح الرئيسي والمفتاح الخارجي في كل جدول.
• هل يحقق الجدول TRUCK سلامةً مرجعيةً؟ اشرح إجابتك.
• ما نوع العلاقة بين الجدولين TRUCK، و BASE.
• كم عدد الكيانات في الجدول TRUCK.
• حدِّد المفاتيح المرشَّحة في الجدول TRUCK.

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

الجدول Customer

جدول BookOrders

• حدِّد المفتاح الرئيسي في كل جدول.
• حدِّد المفتاح الخارجي في الجدول BookOrders.
• هل هناك أي مفاتيح مرشَّحة في أي من الجدولين؟
• ارسم نموذج الكيان والعلاقة ER.
• هل يحقق الجدول BookOrders السلامة المرجعية؟
• هل تحتوي الجداول على بيانات مكررة؟ ما هي؟

دورة علوم الحاسوب

دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب

اشترك الآن

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

الشكل 14: السؤال السادس

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

الشكل 15: السؤال السابع

7. حدِّد جميع الأنوية والكيانات المعتمِدة والمميزة في مخطط الكيان والعلاقة ERD.
8. أي من الجداول لها علاقات ضعيفة، وأيها لديها علاقات قوية؟
9. بالنظر إلى كل جدول من جداول قاعدة بيانات المدرسة، ما هي السمات التي يمكنها أن تأخذ القيمة الفارغة Null، ولماذا؟
10. ما هي الجداول التي أُنشِئت على أساس نتيجة لعلاقات متعدِّد إلى متعدِّد؟

ترجمة وبتصرف للفصل Chapter 8 The Entity Relationship Data Model من كتاب Database Design لصاحبته Adrienne Watt.

اقرأ أيضًا

• المقال التالي: قواعد السلامة وقيودها لضمان سلامة البيانات في قواعد البيانات
• المقال السابق: مفاهيم نموذج البيانات العلائقية RDM الأساسية المهمة في تصميم قواعد البيانات
• خصائص قواعد البيانات والمزايا التي تقدمها
• النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

لقد صُمم نموذج البيانات العلائقية 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، وتضم هذه الوحدات المكونات الأساسية للبيانات التي يمكن تقسيم محتواها.

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

مثال على معلومات حول بطاقة هوية

المجال 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: مصطلح تقني مرادف للصف أو السجل.

المصطلحات الأساسية

تمارين

استخدم الجدول الموجود في الشكل الموضَّح أدناه للإجابة على الأسئلة الأربعة الأولى:

1. حدِّد وصِف جميع المكونات في الجدول باستخدام المصطلحات الصحيحة.
2. ما هو المجال المحتمل للحقل EmpJobCode؟
3. كم عدد السجلات المعروضة؟
4. كم عدد السمات المعروضة؟
5. اذكر خصائص الجدول.

جدول أسئلة التمرين

ترجمة وبتصرف للفصل Chapter 7 The Relational Data Model من كتاب Database Design لصاحبته Adrienne Watt.

اقرأ أيضًا

• دورة علوم الحاسوب
• المقال التالي: نموذج الكيان والعلاقة ER لتمثيل البيانات وتخزينها في قاعدة البيانات
• المقال السابق: نمذجة البيانات وأنواعها في عملية تصميم قواعد البيانات
• النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

تُعَدّ نمذجة البيانات 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: هو وصف عام وشامل لقاعدة البيانات.

التمارين

1. ما هو نموذج البيانات؟
2. ما هو نموذج البيانات المفاهيمي عالي المستوى؟
3. عرف المصطلحات التالية:

• الكيان.
• السمة.
• العلاقة.

4. اذكر وصِف بإيجاز النماذج الشائعة لنماذج البيانات المنطقية القائمة على السجلات.
5. صِف الغرض من التصميم المفاهيمي.
6. ما هو الاختلاف بين التصميم المفاهيمي والتصميم المنطقي؟
7. عرف النماذج التالية:

• ما هو النموذج الخارجي؟
• ما هو النموذج المفاهيمي؟
• ما هو النموذج الداخلي؟
• ما هو النموذج المادي؟

8. ما هو النموذج الذي يتعامل معه مسؤول قاعدة البيانات؟
9. ما هو النموذج الذي يتعامل معه المستخدِم النهائي لقاعدة البيانات؟
10. ما هو الاستقلال البيانات ماديًا؟
11. ما هو استقلال البيانات منطقيًا؟

ترجمة وبتصرف للفصل Chapter 4 Types of Data Models والفصل Chapter 5 Data Modelling من كتاب Database Design لصاحبه Adrienne Watt.

اقرأ أيضًا

• المقال التالي: مفاهيم نموذج البيانات العلائقية RDM الأساسية المهمة في تصميم قواعد البيانات
• المقال السابق: خصائص قواعد البيانات والمزايا التي تقدمها
• تحليل نظام الملفات لإدارة البيانات وتخزينها واختلافه عن نظام قاعدة البيانات
• النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

تعني إدارة المعلومات معالجة المعلومات وتنظيمها لتوظيفها بما يخدمنا بطريقة نستفيد منها في تنفيذ مهامنا، كما منع نظام إدارة قواعد البيانات 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: يُشار إلى نظام قاعدة البيانات على أنه ذاتي الوصف، لأنه يحتوي على قاعدة البيانات نفسها، بالإضافة إلى البيانات الوصفية التي تُحدِّد وتصف البيانات والعلاقات بين الجداول في قاعدة البيانات.
• واجهة العرض: مجموعة فرعية من قاعدة البيانات.

تمارين

1. ماذا يُميِّز نظام إدارة قاعدة البيانات DBMSعن النظام القائم على الملفات file-based system؟
2. ما هي استقلالية البيانات؟ وما أهميتها؟
3. ما هو الغرض من إدارة المعلومات؟
4. ناقش استخدام قواعد البيانات في بيئة العمل.
5. ما هي البيانات الوصفية؟

ترجمة وبتصرف للفصل Chapter 3 Characteristics and Benefits of a Database من كتاب Database Design لصاحبته Adrienne Watt.

اقرأ أيضًا

• المقال التالي: نمذجة البيانات وأنواعها في عملية تصميم قواعد البيانات
• المقال السابق: المفاهيم الأساسية في قواعد البيانات وتصميمها
• تحليل نظام الملفات لإدارة البيانات وتخزينها واختلافه عن نظام قاعدة البيانات
• النسخة العربية الكاملة لكتاب تصميم قواعد البيانات
• دليلك الشامل إلى أنواع البيانات

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

ما هي قاعدة البيانات؟

تُعَدّ قاعدة البيانات 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: هو الشخص الذي يستخدم طرقًا أخرى مختلفة عن البرنامج التطبيقي للوصول إلى قاعدة البيانات.

تمارين

1. ما هو نظام إدارة قواعد البيانات؟
2. ما هي خصائص نظام إدارة قواعد البيانات؟
3. اذكر ثلاثة أمثلة لقواعد بيانات مستقاة من الواقع مثل تحتوي المكتبة على قاعدة بيانات للكتب.
4. اذكر ثلاثة أمثلة لقواعد البيانات العلائقية المستخدَمة والأكثر شيوعًا.
5. ما الفرق بين أنظمة قواعد البيانات المركزية والموزعة؟
6. ما الفرق بين أنظمة قواعد البيانات الموزعة المتجانسة وأنظمة قواعد البيانات الموزعة غير المتجانسة؟

ترجمة وبتصرف للفصل Chapter 2 Fundamental Concepts، والفصل Chapter 6 Classification of Database Management Systems، والفصل Database Users من كتاب Database Design لصاحبته Adrienne Watt.

اقرأ أيضًا

• المقال السابق: تحليل نظام الملفات لإدارة البيانات وتخزينها واختلافه عن نظام قاعدة البيانات
• المقال التالي: خصائص قواعد البيانات والمزايا التي تقدمها
• النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

قطعت الطريقة التي تدير بها أجهزة الحاسوب البيانات شوطًا طويلًا على مدار العقود القليلة الماضية، كما يأخذ مستخدمي الحاسوب اليوم المزايا العديدة الموجودة في نظام قواعد البيانات أمرًا مسلَّمًا به على الرغم من عدم مرور وقت طويل على اعتماد أجهزة الحاسوب النظام القائم على الملفات 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: برنامج تطبيق مصمَّم للتعامل مع ملفات البيانات.

تمارين

1. ناقش كل من المصطلحات التالية:

• البيانات
• الحقل
• السجل
• الملف

2. ما هو تكرار البيانات؟
3. ناقش عيوب النظام القائم على الملفات.
4. اشرح الفرق بين البيانات والمعلومات.
5. استخدم الشكل أدناه للإجابة على الأسئلة التالية:

• كم عدد السجلات التي يحتوي عليها الملف؟
• كم عدد الحقول في كل سجل؟
• ما المشكلة التي قد تواجهها إذا أردت إنشاء قائمة مرتبة حسب المدينة؟
• كيف يمكنك حل هذه المشكلة عن طريق تعديل هيكلة الملف؟

جدول التمرين رقم 5

ترجمة وبتصرف للفصل Chapter 1 Before the Advent of Database Systems من كتاب Database Design لصاحبه Adrienne Watt.

اقرأ أيضًا

• المقال التالي: المفاهيم الأساسية في قواعد البيانات وتصميمها
• شرح الفروقات بين قواعد بيانات SQL ونظيراتها NoSQL
• مقارنة بين أنظمة إدارة قواعد البيانات العلاقية: SQLite مع MySQL مع PostgreSQL
• النسخة العربية الكاملة لكتاب تصميم قواعد البيانات

من المُستبعد احتمال أنّك ستعمل مع بيانات من جدول واحد فقط، لذا ستحتاج إلى الحصول على البيانات من جداول مُتعدّدة. استعمال الروابط (Joins) أحد الخيارات للقيام بالأمر، وفي قواعد البيانات العلائقيّة (Relational databases)، فالروابط هي التي تجعل قواعد البيانات علائقيّة. يوفّر هذا الدّرس تذكيرا سريعا بالأنواع الأربعة الأساسيّة لروابط SQL وثلاثة من فروعها.

ما هو الرابط؟

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

لماذا تعد الروابط مهمة؟

تُمكّن الروابط من الحصول على البيانات من عدّة جداول باستعلام (query) واحد. من المُستبعد بأنّك ستعمل مع جدول واحد فقط. استعمال جدول واحد فقط يعني بأنّك إمّا تحدّ نفسك في كميّة البيانات التي تحصل عليها أو أنّك تمتلك الكثير من البيانات التي قد تجعل من الجدول صعب المراس. تُنشئ الروابط علاقة بين جدول وآخر (ومنه جاء مُصطلح “قواعد البيانات العلائقيّة”).

ما هي أنواع روابط SQL الموجودة؟

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

الرابط الدّاخلي Inner Join

رُبما يعتبر الرّابط الدّاخلي من أكثر أنواع روابط SQL استعمالا. ويُرجِع الرابط الداخلي جميع الصفوف التي تُحقّق شرط الرّبط (join condition) من جدولين أو أكثر.

عينة SQL

SELECT columns
FROM TableA
INNER JOIN TableB
ON A.columnName = B.columnName;

الربط اليساري (الخارجي)

يُرجع الرّبط اليساري الخارجي (أحيانا يُختصر إلى الرّبط اليساري) جميع الصفوف من الجدول المُحدّد يسار الشّرط ON والصفوف التي تًحقّق شرط الرّبط فقط من الجدول في اليمين.

عينة SQL

SELECT columns
FROM TableA
LEFT OUTER JOIN TableB
ON A.columnName = B.columnName

الربط اليساري (الخارجي) دون تقاطع

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

عينة SQL

SELECT columns
FROM TableA
LEFT OUTER JOIN TableB
ON A.columnName = B.columnName
WHERE B.columnName IS NULL

الربط اليميني (الخارجي)

يُرجع الرّبط اليميني الخارجي (أحيانا يُختصر إلى الرّبط اليميني) جميع الصّفوف من يمين شرط ON والصفوف التي تحقّق شرط الرّبط فقط من الجدول على اليسار.

عيّنة SQL

SELECT columns
FROM TableA
RIGHT OUTER JOIN TableB
ON A.columnName = B.columnName

الربط اليميني (الخارجي) دون تقاطع

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

عيّنة SQL

SELECT columns
FROM TableA
RIGHT OUTER JOIN TableB
ON A.columnName = B.columnName
WHERE A.columnName IS NULL

الربط التام (الخارجي)

يُرجع الرّبط التّام الخارجي (يُختصر أحيانا إلى الرّبط التّام) جميع الصفوف من كلا الجدولين المُحددين في الشّرط ON في حالة لم يتحقق شرط الرّبط (ما يشمل القيم الفارغة NULL).

عيّنة SQL

SELECT columns
FROM TableA
FULL JOIN TableB
ON A.columnName = B.columnName

الربط التام (الخارجي) دون تقاطع

هذا فرع من الرّوابط التّامة الخارجية يُرجع جميع الصفوف من كلا الجدولين المُحدّدين في الشّرط ON في حالة لم يتحقّق شرط الرّبط (باستثناء القيم الفارغة NULL).

عيّنة SQL

SELECT columns
FROM TableA
FULL JOIN TableB
ON A.columnName = B.columnName
WHERE A.columnName IS NULL
OR B.columnName IS NULL

ختاما

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

ترجمة -بتصرّف- للمقال The Seven Types of SQL Joins لصاحبه Eren Baydemir.

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

المتطلبات المسبقة

للمتابعة مع هذا الدرس يجب أن يكون عندك:
- خادوم CentOS 7 مع حساب مستخدم ليس جذرًا لكنه يمتلك امتيازات الجذر باستعمال الأمر sudo، وفيه خادوم MariaDB مثبت مسبقًا، يمكنك معرفة المزيد من المعلومات حول ضبط CentOS 7 بقراءة درس الضبط المبدئي لخادوم CentOS 7، وإذا لم تثبت MariaDB من قبل، فسيساعدك درس تثبيت وإعداد نظامي إدارة قواعد البيانات MySQL وPostgreSQL على ذلك.
سننقل البيانات من جهاز تخزينٍ موصولٍ (mounted) في نقطة الوصل ‎/mnt/volume-nyc1-01. يمكنك معرفة المزيد من المعلومات عن أجهزة التخزين والأقسام وكيفية استخدامها في درس «كيفية إجراء مهام إدارة أجهزة التخزين البسيطة في لينكس».
سيعلّمك هذا الدرس طريقة نقل مجلد تخزين بيانات MySQL إلى مكانٍ جديد بغض النظر عن وسيط التخزين الذي تستخدمه (قرص صلب، أو مصفوفة RAID، أو تخزين شبكي).

الخطوة الأولى: نقل مجلد بيانات MariaDB

لكي نحضِّر لنقل مجلد بيانات MariaDB فلنحاول معرفة مساره الحالي عبر بدء جلسة تفاعلية بتسجيل الدخول بحساب المستخدم root:

mysql -u root -p

أدخِل كلمة المرور عند طلبها، ثم نفِّذ التعليمة التالية من سطر أوامر mysql:

select @@datadir;

الناتج:

+-----------------+
| @@datadir       |
+-----------------+
| /var/lib/mysql/ |
+-----------------+
1 row in set (0.00 sec)

الناتج السابق يُظهِر أنَّ قواعد MariaDB مضبوطة لاستخدام مجلد تخزين البيانات المبدئي ‎/var/lib/mysql/‎، وهذا هو مسار المجلد الذي علينا نقله؛ نفِّذ الأمر exit للخروج:

exit

لكي نضمن سلامة البيانات، علينا أولًا إغلاق خادوم MariaDB قبل تعديل مجلد البيانات:

sudo systemctl stop mariadb

الأمر systemctl لا يُظهِر نتيجة تنفيذ أوامر إدارة الخدمات، لذا إذا أردتَ التحقق أنَّ الخادوم قد أُغلِق بنجاح، فنفِّذ الأمر الآتي:

sudo systemctl status mariadb

انظر إلى آخر سطر من ناتج الأمر السابق الذي يجب أن يخبرك أنَّ الخادوم قد توقف عن العمل:

. . .
Dec 16 18:29:26 mysql systemd[1]: Stopped MariaDB database server.

سننسخ مجلد قواعد البيانات الموجود حاليًا إلى المكان الجديد باستخدام rsync وذلك بعد إغلاق الخادوم.
سنستخدم الخيار ‎-a للحفاظ على الأذونات وخصائص المجلد الأخرى، وسيزودنا الخيار ‎-v بمخرجات توضِّح سير عملية النسخ.
ملاحظة: احرص على عدم وجود خط مائل (/) في نهاية مسار المجلد الذي ستُنسَخ البيانات منه، والذي قد يُضاف تلقائيًا إذا كنتَ تُكمِل المسار باستعمال زر tab، فإذا كان الخط المائل موجودًا فسينسخ الأمر rsync المجلد نفسه وليس محتوياته.

sudo rsync -av /var/lib/mysql /mnt/volume-nyc1-01

بعد إكمال تنفيذ أمر rsync السابق، فأعد تسمية المجلد الحالية وأضف إليه اللاحقة ‎.bak (لتعرف أنه نسخة احتياطية وليس المجلد الأصل) وأبقِه موجودًا حتى تتأكد من نجاح عملية النقل؛ أعدنا تسميته لتفادي الخلط بين الملفات الموجودة في المكان القديم والجديد:

sudo mv /var/lib/mysql /var/lib/mysql.bak

سنشرع الآن بتعديل ضبط قواعد البيانات.

الخطوة الثانية: الإشارة إلى مكان تخزين البيانات الجديد

هنالك طرائق عدِّة لتجاوز القيم المضبوطة في MySQL، إذ تُضبَط التعليمة datadir مبدئيًا إلى ‎/var/lib/mysql في ملف ‎/etc/my.cnf، لذا لنعدِّل هذا الملف لتغيير المسار إلى المجلد الجديد:

sudo vi /etc/my.cnf

ابحث عن السطر الذي يبدأ بالكلمة datadir=‎ وغيّر المسار الذي يُشير إليه إلى المسار الجديد. ولوجود ملف المقبس (socket file) في مجلد البيانات القديم، فعلينا تحديثه ليشير إلى المكان الجديد أيضًا:

[mysqld]
. . .
datadir=/mnt/volume-nyc1-01/mysql
socket=/mnt/volume-nyc1-01/mysql/mysql.sock
. . .

بعد تحديث الأسطر السابقة الموجودة في الملف، فلنضف ضبطًا خاصًا بعميل mysql وذلك بإضافة الضبط الآتي إلى نهاية الملف (لكي لا نُقسِّم تعليمات الضبط الخاصة بخادوم MySQL إلى قسمين) لكن قبل السطر الذي يحتوي على الكلمة include:

[client]
port=3306
socket=/mnt/volume-nyc1-01/mysql/mysql.sock

!includedir /etc/my.cnf.d

بعد أن تنتهي من تعديل الملف، فاضغط على زر Escape ثم اكتب ‎:wq!‎ لحفظ الملف والخروج من المحرر.

الخطوة الثالثة: إعادة تشغيل خادوم MariaDB

بعد أن حدثنا الضبط ليشير إلى مسار المجلد الجديد، فيمكننا الآن تشغيل خادوم MariaDB والتأكد من عمله بشكل سليم:

sudo systemctl start mariadb
sudo systemctl status mariadb

للتأكد أننا نستعمل المجلد الموجود في المسار الجديد لتخزين البيانات، فسنتصل عبر عميل mysql:

mysql -u root -p

وننظر إلى قيمة datadir مجددًا:

select @@datadir;

الناتج:

+----------------------------+
| @@datadir                  |
+----------------------------+
| /mnt/volume-nyc1-01/mysql/ |
+----------------------------+
1 row in set (0.01 sec)

نفِّذ exit للخروج من العميل.
بعد أن أعدت تشغيل خادوم MariaDB وتأكدت أنَّه يستعمل المكان الجديد، فخذ وقتك للتحقق من سلامة بياناتك وأنَّ قواعد بياناتك تعمل دون مشاكل، وبعدئذٍ تستطيع حذف المجلد الاحتياطي بالأمر sudo rm -rf /var/lib/mysql.bak.

الخلاصة

تعلمنا في هذا الدرس طريقة نقل مجلد بيانات MariaDB إلى مسارٍ جديد، وهذه الطريقة ستعمل مهما كانت تقنية التخزين التي يعتمدها وسيط التخزين الذي ستستعمله.
ولمّا كانت قواعد بيانات MariaDB مشتقةً من MySQL، فيمكنك معرفة المزيد من المعلومات حول إدارة مجلدات البيانات في القسمين الآتيين من توثيق MySQL الرسمي: The MySQL Data Directory و Setting Up Multiple Data Directories.
ترجمة –وبتصرّف– للمقال How To Change a MariaDB Data Directory to a New Location on CentOS 7 لصاحبته Melissa Anderson

توفر أوبنتو خادومَيّ قواعد بيانات شهيرَين هما:

• قواعد بيانات MySQL.
• قواعد بيانات PostgreSQL.

حيث تتوفران في المستودع الرئيسي (main)؛ ويشرح هذا الدرس كيفية تثبيت وضبط خادومَي قواعد البيانات آنفَيّ الذكر.

MySQL

إن MySQL هو خادوم قواعد بيانات سريع ومتعدد الخيوط (multi-threaded) ومتعدد المستخدمين ومرن جدًا؛ مُطوَّر للأنظمة الإنتاجية المحورية والتي تتحمل حِملًا ثقيلًا، ويمكن أيضًا تضمينه في البرمجيات سريعة النشر (mass-deployed).

التثبيت

نفذِّ الأمر الآتي في الطرفية لتثبيت MySQL:

sudo apt-get install mysql-server

سيُطلب منك إدخال كلمة مرور للمستخدم الجذر لخادوم MySQL أثناء التثبيت.

بعد أن ينتهي التثبيت، فيجب أن يبدأ خادوم MySQL تلقائيًا؛ تستطيع تنفيذ الأمر الآتي في الطرفية للتحقق إذا كان خادوم MySQL يعمل أم لا:

sudo netstat -tap | grep mysql

يجب أن تشاهد شيئًا شبيهًا بما يلي بعد تنفيذ الأمر السابق:

tcp 0 0 localhost:mysql *:* LISTEN 2556/mysqld

إذا لم يكن يعمل الخادوم، فتستطيع تشغيله بالأمر:

sudo service mysql restart

الضبط

تستطيع تعديل الملف ‎/etc/mysql/my.cnf لضبط الإعدادات الأساسية، مثل ملف السجل، ورقم المنفذ ...إلخ. فمثلًا لضبط MySQL ليستمع إلى الاتصالات من مضيفي الشبكة، عليك تعديل قيمة التعليمة bind-address إلى عنوان IP للخادوم:

bind-address = 192.168.0.5

ملاحظة: عدِّل 192.168.0.5 إلى العنوان الملائم.

بعد إجراء التعديلات على ملف ‎/etc/mysql/my.cnf؛ فيجب إعادة تشغيل عفريت MySQL:

sudo service mysql restart

أدخل الأمر الآتي في الطرفية إذا رغبت بتغيير كلمة مرور المستخدم الجذر (root) في MySQL:

sudo dpkg-reconfigure mysql-server-5.5

سيُوقَف عمل عفريت MySQL، وستُسأل عن كلمة المرور الجديدة.

محركات قاعدة البيانات

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

صُمِّمَت قواعد بيانات MySQL للسماح بتخزين البيانات بطرقٍ مختلفة؛ يُشار لهذه الطرق إما بمحركات قواعد البيانات أو محركات التخزين (Storage engine)؛ هنالك محركان رئيسيان ستكون مهتمًا بهما: InnoDB و MyISAM؛ لا تتغير طريقة التعامل مع محركات التخزين المختلفة بالنسبة للمستخدم النهائي؛ حيث تتعامل MySQL مع الأمور بطريقة مختلفة وراء الستار، أي أنه بغض النظر عن محرك التخزين الذي تستخدمه، فإنك ستتعامل مع قواعد البيانات بنفس الطريقة تمامًا.

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

• المحرك MyISAM هو الأقدم بين المحركين المذكورين؛ يمكن أن يكون أسرع من InnoDB في حالات معيّنة ويفضل الأعمال التي تتطلب القراءة فقط؛ تتمحور بعض تطبيقات الويب حول MyISAM (على الرغم أنها لن تُبطَئ إذا استخدمت InnoDB)؛ يدعم MyISAM أيضًا نوع البيانات FULLTEXT؛ الذي يسمح بالبحث بسرعة كبيرة في كمياتٍ كبيرةٍ من النص؛ لكن MyISAM قادر على قفل الجدول بأكمله فقط عند الكتابة، هذا يعني أن عمليةً واحدةً فقط تستطيع تحديث الجدول في لحظة زمنية معينّة؛ قد يكون هذا إعاقةً لتوسع تطبيق يعتمد على هذا الجدول؛ ولا يحتوي MyISAM على ميزة «journaling»، وهذا يعني أنه من الصعب استرجاع البيانات بعد حدوث انهيار.
• المحرك InnoDB هو محرك قواعد بيانات أكثر حداثةً، صُمِّم ليكون متوافقًا مع ACID الذي يضمن إجراء العمليات على قواعد البيانات بطريقة عملية؛ قفل الكتابة يحدث على مستوى السجل (row) ضمن الجدول؛ هذا يعني أنه من الممكن إجراء عدِّة تحديثات لسجلات جدولٍ ما في نفس الوقت؛ التخزين الموقت للبيانات يحدث في الذاكرة ضمن محرك قواعد البيانات، مما يسمح بالتخزين على أساس السجل وليس على أساس كتلة الملف (file block)؛ ولكي يتوافق مع ACID، فإن كل العمليات تحدث بطريقة «journaled» مستقلةً عن الجداول الرئيسية؛ وهذا يؤدي إلى استرجاع البيانات استرجاعًا عمليًا.

إن InnoDB هو المحرك الافتراضي في MySQL 5.5 ومن المستحسن بشدة استخدامه بدلًا من MyISAM ما لم تكن تريد استخدام مزايا خاصة بذاك المحرك.

الضبط المتقدم: إنشاء ملف ضبط my.cnf

هنالك عدد من المعاملات التي يمكن تعديلها في ملف ضبط MySQL مما يسمح لك بتحسين أداء الخادوم مع مرور الوقت؛ ربما تجد الأداة «Percona's my.cnf generating tool» مفيدةً للإعداد الابتدائي؛ ستولد هذه الأداة ملف my.cnf ليكون أكثر ملائمةً لإمكانيات ومتطلبات خادومك.

لا تستبدل ملف my.cnf المولد من Percona إذا وضعت بيانات في قاعدة بيانات، بعض التغييرات في الملف لن تسبب مشاكل لأنها تُعدِّل طريقة تخزين البيانات على القرص الصلب ولن تتمكن من تشغيل MySQL؛ إذا أردت استخدامه وكانت لديك بيانات موجودة مسبقًا، فعليك أن تجري mysqldump ثم تعيد التحميل:

mysqldump --all-databases --all-routines -u root -p > ~/fulldump.sql

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

أغلق خادوم MySQL بعد إكمال عملية التفريغ (dump):

sudo service mysql stop

خذ الآن نسخةً احتياطيةً من my.cnf واستبدله بالملف الجديد:

sudo cp /etc/my.cnf /etc/my.cnf.backup
sudo cp /path/to/new/my.cnf /etc/my.cnf

الآن احذف وأعد تهيئة مجال قواعد البيانات وتأكد أن الملكية صحيحة قبل إعادة تشغيلMySQL:

sudo rm -rf /var/lib/mysql/*
sudo mysql_install_db
sudo chown -R mysql: /var/lib/mysql
sudo service start mysql

كل ما تبقى الآن هو إعادة استيراد بياناتك؛ وللحصول على فكرة عن مدى إتمام عملية الاستيراد، فربما تجد الأداة pv‏ (Pipe Viewer) مفيدةً؛ الأمر الآتي يظهر كيفية تثبيت واستخدام pv لهذه الحالة، ربما لا تريد أن تستخدمها وكل ما عليك فعله هو استبدال pv بالأمر cat؛ تجاهل أية أوقات متوقعة للانتهاء (ETA) مولدة من pv؛ لأنها مبنية على الوقت المستغرق لكي يُعالَج كل سجل من الملف، لكن سرعة إدراج البيانات قد تختلف اختلافًا كبيرًا من سجل إلى سجل:

sudo apt-get install pv
pv ~/fulldump.sql | mysql

ملاحظة: هذا ليس ضروريًا لكل تعديلات my.cnf؛ أغلبية المتغيرات التي قد ترغب في تعديلها لتحسين الأداء يمكن أن تُغيَّر حتى وإن كان يعمل الخادوم؛ تأكد من الحصول على نسخة احتياطية من ملفات الضبط والبيانات قبل إجراء التعديلات.

MySQL Tuner

الأداة «MySQL Tuner» هي أداة مفيدة تستطيع الاتصال إلى خدمة MySQL التي تعمل وتوفر اقتراحات عن كيفية ضبطها بأفضل ضبط لحالتك؛ وكما كان يعمل الخادوم لوقتٍ أطول، كلما كانت «النصيحة» التي سيوفرها mysqltuner أفضل؛ خذ بعين الاعتبار الانتظار لمدة 24 ساعة في بيئة إنتاجية قبل تشغيل هذه الأداة؛ تستطيع تثبيت mysqltuner من مستودعات أوبنتو:

sudo apt-get install mysqltuner

ثم تشغيلها بعد تثبيتها بالأمر:

mysqltuner

وانتظر التقرير النهائي، سيوفر القسم العلوي معلوماتٍ عن خادوم قاعدة البيانات، ويوفر القسم السفلي اقتراحاتٍ لكي تعدلها في ملف my.cnf؛ يمكن تعديل أغلبية الاقتراحات على الخادوم مباشرةً دون إعادة تشغيله، انظر إلى توثيق MySQL الرسمي للمتغيرات المناسبة لتعديلها في البيئات الإنتاجية؛ ما يلي هو جزء من تقرير من قاعدة بيانات إنتاجية الذي يُظهِر أن هنالك بعض الفائدة من زيادة مقدار ذاكرة تخزين الطلبية:

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    key_buffer_size (> 1.4G)
    query_cache_size (> 32M)
    table_cache (> 64)
    innodb_buffer_pool_size (>= 22G)

تعليق أخير عن ضبط قواعد البيانات: بينما نستطيع أن نقول أن بعض الإعدادات هي الأفضل، لكن قد يختلف الأداء من تطبيق لآخر؛ على سبيل المثال، ما يعمل عملًا ممتازًا لووردبريس (Wordpress) قد لا يكون الأفضل لدروبال (Drupal) أو جوملا (Joomla) أو التطبيقات التجارية؛ الأداء متعلقٌ بأنواع الطلبيات واستخدام الفهارس، وإذا ما كان تصميم قاعدة البيانات جيدًا، وهكذا... ربما من الجيد إنفاق بعض الوقت في البحث عن إعدادات ملائمة لقواعد البيانات بناءً على التطبيقات التي تستخدمها؛ لكن بعد أن تتجاوز التعديلات حدًا معيّنًا، فإن أيّة تغييرات تجريها لا تتسبب إلا بتحسين بسيط جدًا في أداء التطبيق، ومن الأفضل لك تحسين التطبيق نفسه، أو التفكير في توسيع خادوم MySQL إما باستخدام عتاد أفضل أو بإضافة خواديم تابعة (slave).

مصادر

• راجع الموقع الرئيسي لقواعد MySQL لمزيدٍ من المعلومات.
• التوثيق الكامل متوفر بصيغ online و offline من «MySQL Developers portal».
• لمعلومات عامة حول SQL، انظر إلى كتاب «Using SQL Special Edition».
• صفحة ويكي أوبنتو «Apache MySQL PHP» فيها بعض المعلومات المفيدة.

PostgreSQL

PostgreSQL هي قاعدة بيانات علائقية تعتمد على الكائنات وتملك ميزات أنظمة قواعد البيانات التجارية التقليدية مع تحسينات موجودة في الجيل الجديد من أنظمة DBMS.

التثبيت

أدخل الأمر الآتي في الطرفية لتثبيت PostgreSQL:

sudo apt-get install postgresql

بعد انتهاء التثبيت، عليك ضبط خادوم PostgreSQL بناءً على متطلباتك، على الرغم من أن الضبط الافتراضي قابل للاستخدام.

الضبط

الاتصال عبر TCP/IP معطَّل افتراضيًا؛ تدعم PostgreSQL عدّة طرق للاستيثاق من العميل؛ طريقة الاستيثاق IDENT تُستعمَل للمستخدمين المحليين ولمستخدم postgres ما لم يُضبَط غير ذلك؛ رجاءً راجع «PostgreSQL Administrator's Guide» إذا أردت ضبط بدائل مثل Kerberos.

سنفترض في ما يلي أنك ستُفعِّل اتصالات TCP/IP وتستخدم طريقة MD5 للاستيثاق من العميل؛ تُخزَّن ملفات ضبط PostgreSQL في المجلد ‎/etc/postgresql/<version>/main؛ على سبيل المثال، إذا ثبتت خادوم PostgreSQL 9.1، فإن ملفات الضبط ستُخزَّن في المجلد ‎/etc/postgresql/9.1/main.

تنويه: لضبط الاستيثاق بطريقة ident، فأضف مدخلات إلى ‎/etc/postgresql/9.1/‎ main/pg_ident.conf؛ هنالك تعليقات تفصيلية في الملف لتساعدك.

لتفعيل اتصالات TCP/IP، عليك تعديل الملف ‎/etc/postgresql/9.1/main/postgresql.conf ومن ثم تحديد السطر:

 ‎‎#listen_addresses = 'localhost‎‎'‎ 

ثم تغييره إلى:

listen_addresses = '*'

ملاحظة: للسماح باتصالات IPv4 و IPv6، استبدل «localhost» بالرمز «::».

ربما تريد تعديل بقية المعاملات، إذا كنت تعرف ماذا تفعل! للتفاصيل، ارجع إلى ملف الضبط أو إلى توثيق PostgreSQL.

الآن وبعد أن استطعنا الاتصال بخادوم PostgreSQL فإن الخطوة الآتية هي ضبط كلمة مرور للمستخدم postgres؛ نفذ الأمر الآتي في الطرفية للاتصال بقاعدة بيانات PostgreSQL الافتراضية:

sudo -u postgres psql template1

يتصل الأمر السابق بقاعدة بيانات PostgreSQL المسماة template1 كالمستخدم postgres؛ بعد أن تتصل إلى خادوم PostgreSQL وتحصل على مِحَث لإدخال تعليمات SQL، فيمكنك إدخال أمر SQL الآتي في مِحَث psql لضبط كلمة المرور للمستخدم postgres:

ALTER USER postgres with encrypted password 'your_password';

بعد ضبط كلمة المرور، عدِّل الملف ‎/etc/postgresql/9.1/main/pg_hba.conf لاستخدام استيثاق MD5 مع المستخدم postgres:

local all postgres md5

في النهاية، يجب أن تُعيد تشغيل خدمة PostgreSQL لتهيئة الضبط الجديد، وذلك بإدخال الأمر الآتي من الطرفية:

sudo service postgresql restart

تحذير: الضبط السابق ليس كاملًا بأي شكل من الأشكال، رجاءً راجع «PostgreSQL Administrator's Guide» لمعاملات ضبط إضافية.

يمكنك اختبار اتصالات الخادوم من الأجهزة الأخرى باستخدام عملاء PostgreSQL:

sudo apt-get install postgresql-client
psql -h postgres.example.com -U postgres -W

ملاحظة: استبدل اسم النطاق في المثال السابق باسم نطاقك الفعلي.

مصادر

• كما ذُكِر سابقًا، فإن «PostgreSQL Administrator's Guide» هو مصدر رائع، وهو متوفر أيضًا في حزمة postgresql-doc-9.1؛ نفذ ما يلي لتثبيت تلك الحزمة:

sudo apt-get install postgresql-doc-9.1

• أدخِل الوصلة file:///usr/share/doc/postgresql-doc-9.1/html/index.html في شريط العنوان في متصفحك لمشاهدة الدليل.
• راجع أيضًا صفحة ويكي أوبنتو «PostgreSQL» لمزيدٍ من المعلومات.

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Databases.

Sqlite هي عبارة عن محرك SQL مفتوح المصدر سريع وبسيط جدا، يشرح هذا الدرس متى يكون من الأمثل استخدام Sqlite كبديل لأنظمة إدارة قواعد البيانات الارتباطية RDBMS مثل MySQL أو Postgres، بالإضافة إلى كيفية تثبيتها وأمثلة عن استخداماتها الأساسية، تُغطي عمليات CRUD: الإنشاء Create، القراءة Read، التحديث Update، والحذف Delete.

مفاهيم خاطئة

لا يجب أن ننخدع بالاعتقاد أن Sqlite تستَخدم فقط للاختبار والتطوير، فعلى سبيل المثال تعمل Sqlite بشكل جيد لمواقع الإنترنت التي تتلقى 100,000 زائر يوميا، وهذا هو الحد المُحافظ. إن الحد الأقصى لحجم قاعدة بيانات Sqlite هو 140 تيرابايت (والذي من المفترض أن يكون كافيًا، أليس كذلك؟)، وبإمكانها أن تكون أسرع بكثير من RDBMS، يتم تخزين قاعدة البيانات كاملةمع كافة البيانات الضرورية في ملف عادي في نظام ملفات المضيف Host، ولذلك لا توجد حاجة لعملية خادوم Server منفصلة (الاستغناء عن الحاجة إلى الاتصالات البطيئة بين العمليّات).

الاستخدام الأمثل على VPS الخاص بنا

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

حيث تستطيع Sqlite أن تدعم كاتب writer واحد فقط في نفس الوقت، وقد يكون زمن الوصول latency لنظام الملفات المرتَفِع عادة غير مُلائِم إن كانت هناك حاجة لنفاذ access العديد من العملاء إلى قاعدة بيانات Sqlite في نفس الوقت. العيب الأخير المُحتَمل وجوده في Sqlite هو صياغتها syntax الفريدة، بالرغم من تشابهها مع أنظمة SQL الأخرى، ومن البديهي عند الانتقال إلى نظام آخر -إن قمنا باستخدام Sqlite والتي تتطوّر بسرعة- أن نجد بعض العقبات في المرحلة الانتقاليّة.

تثبيت Sqlite على VPS الخاص بنا

إن وحدة sqlite3 module هي جزء من مكتبة بايثون المعيارية، لذلك لا نحتاج لأي تثبيت آخر على توزيعة Ubuntu المعيارية أو على أي نظام آخر مُثبّت عليه بايثون، ولتثبيت واجهة سطر الأوامر لـ Sqlite على Ubuntu نستخدم هذه الأوامر:

sudo apt-get update

sudo apt-get install sqlite3 libsqlite3-dev

إن كُنّا نريد تصريفه Compile من المصدر Source يجب علينا الحصول على آخر إصدار من autoconf من الرّابط sqlite.org/download.html، وهو الإصدار المتوفّر وقت كتابة هذا الدّرس:

wget http://sqlite.org/2013/sqlite-autoconf-3080100.tar.gz
tar xvfz sqlite-autoconf-3080100.tar.gz

cd sqlite-autoconf-3080100

./configure

make

make install

ملاحظات من أجل البناء من المصدر:

1. لا يجب أن نقوم بفعل هذا على توزيعة Ubuntu معياريّة لأنّه من المُحتمل أن نتلقّى خطأ عن عدم التّوافق في إصدار التّرويسة Header والمصدر "header and source version mismatch" بسبب التّعارض بين الإصدار المُثبّت حاليًّا والإصدار الجّديد الذي نريد تثبيته.
2. إن كان يبدو أنّ الأمر make ينتظر المزيد من المُدخلات منك فكُن صبورًا فقط، حيث أنّ تصريف Compile المصدر قد يستغرق بعض الوقت.

الاستخدامات الأساسية لواجهة سطر الأوامر

لإنشاء قاعدة بيانات نقوم بتنفيذ الأمر التالي:

sqlite3 database.db

حيث يكون database هو اسم قاعدة البيانات لدينا، وإن كان الملف database.db موجودًا مُسبقًا ستقوم Sqlite بإنشاء اتصال معه، وإن لم يكن موجودًا سيتمّ إنشاؤه، يجب أن يكون الخرج Output مُشابهًا لما يلي:

SQLite version 3.8.1 2013-10-17 12:57:35

Enter ".help" for instructions

Enter SQL statements terminated with a ";"

sqlite>

فلنقم الآن بإنشاء جدول Table وإدخال بعض البيانات إليه، يملك هذا الجدول المُسمَّى الأندية clubs أربعة أعمدة columns، من أجل id، اسم النادي name، مدرّبه coach، وبلد النّادي country، سنقوم بإدخال بيانات ثلاثة أندية كرة قدم إلى قاعدة بياناتنا:

CREATE TABLE clubs (id integer, name varchar(30), coach varchar(20), country varchar(20));

INSERT INTO clubs VALUES (1, "Real Madrid", "Benitez", "Spain");

INSERT INTO clubs VALUES (2, "Barcelona", "Enrique", "Spain");

INSERT INTO clubs VALUES (3, "Chelsea", "Mourinho", "England");

لقد أنشأنا قاعدة بيانات، جدول، وبعض الإدخالات، نضغط الآن Ctrl+D للخروج من Sqlite ونكتب ما يلي (يجب هنا أيضًا أن نضع اسم قاعدة بياناتنا بدلًا من 'database') والذي سيقوم بإعادة الاتصال إلى قاعدة البيانات التي أنشأناها للتو:

sqlite3 database.db

الآن نكتب:

SELECT * FROM clubs;

يجب أن نرى هنا الإدخالات التي قُمنا بها:

1|Real Madrid|Benitez|Spain

2|Barcelona|Enrique|Spain

3|Chelsea|Mourinho|England

رائع، هذا هو كلّ شيء فيما يتعلّق بالإنشاء Creating والقراءة Reading، فلنقم الآن بالتّحديث Update والحذف Delete:

UPDATE clubs SET country="Spain" WHERE country="England";

سيقوم هذا الأمر بتحديث قاعدة البيانات بحيث يجعل الأندية المُدرَجة على أنّها من إنكلترا يتم إدراجها وكأنّها أندية من إسبانيا، فلنتأكّد من النتائج باستخدام الأمر:

SELECT * FROM clubs;

يجب أن نرى:

1|Real Madrid|Benitez|Spain

2|Barcelona|Enrique|Spain

3|Chelsea|Mourinho|Spain

أصبحت لدينا الآن كل الأندية من إسبانيا، فلنقم بحذف Chelsea من قاعدة بياناتنا كونه النادي الوحيد الذي في الحقيقة ليس من إسبانيا:

DELETE FROM clubs WHERE id=3;

SELECT * FROM clubs;

ينبغي أن نجد الآن عدد الأندية لدينا أقل بواحد من السّابق:

1|Real Madrid|Benitez|Spain

2|Barcelona|Enrique|Spain

يُغطِّي هذا جميع العمليّات الأساسيّة لقواعد البيانات، وقبل أن ننتهي دعونا نجرّب مثالًا آخر أقل بديهيّة بقليل، والذي يستخدم جدولين وانضمام join أساسي بينهما.

فلنخرج الآن من Sqlite باستخدام الأمر Ctrl+D ونعيد الاتصال إلى قاعدة بيانات جديدة باستخدام:

 sqlite3 database2.db

سنقوم بإنشاء جدول مشابه جدًّا لجدول الأندية clubs ولكنّنا سننشئ أيضًا جدول للدول countries، والذي يقوم بتخزين اسم الدّولة ورئيسها الحالي، فلنقم أولًا بإنشاء جدول الدّول countries وإدخال إسبانيا وفرنسا إليه باستخدام ما يلي (لاحظ أنّنا نستطيع نسخ ولصق عدّة أسطر من شيفرة sqlite دفعة واحدة):

CREATE TABLE countries (id integer, name varchar(30), president varchar(30));

INSERT INTO countries VALUES (1, "Spain", "Rajoy Brey");

INSERT INTO countries VALUES(2, "France", "Francois Hollande");

ونستطيع بعدها إعادة إنشاء الجدول clubs باستخدام ما يلي:

CREATE TABLE clubs (id integer, name varchar(30), country_id integer);

INSERT INTO clubs VALUES (1, "Real Madrid", 1);

INSERT INTO clubs VALUES (2, "Barcelona", 1);

INSERT INTO clubs VALUES (3, "Chelsea", 2);

دعونا الآن نرى ما هي الأندية الموجودة في إسبانيا باستخدام:

SELECT name FROM clubs JOIN countries ON country_id=countries.id WHERE countries.name="Spain";

ينبغي أن نشاهد ما يلي:

Real Madrid

Barcelona

يُغطّي هذا موضوع الانضمام الأساسي basic join، فلنلاحظ أنّ sqlite تفعل الكثير من أجلنا، ففي التّعبير السّابق يرمز الانضمام Join افتراضيًّا إلى INNER JOIN بالرغم من أنّنا استخدمنا فقط الكلمة المفتاحيّة JOIN، ولا يجب علينا أيضًا تحديد clubs.country_id لأنّها واضحة لا لبس فيها، من ناحية أخرى إن جرّبنا هذا الأمر:

SELECT name FROM clubs JOIN countries ON country_id=id WHERE country_id=1;

سنتلقّى رسالة خطأ:  "Error: ambiguous column name: id" وهو خطأ معقول بما فيه الكفاية لأنّ الجدولين لدينا كلاهما يملكان عمود id، ولكن بشكلٍ عام sqlite متسامحة مع الأخطاء إلى حد ما، فرسائل الأخطاء فيها تميل إلى أن تجعل تحديد مكان أيّ مشاكل وإصلاحها شيئًا بديهيا إلى حد ما، وهذا يُساعد على تسريع عمليّة التّطوير.

 للمزيد من المساعدة في موضوع الصّياغة Syntax فإنّ الوثائق الرّسميّة لها مليئة بالمخطّطات البيانيّة diagrams مثل هذا sqlite.org/langdelete.html، والتي من الممكن أن تكون مفيدة.

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

ترجمة -وبتصرّف- للمقال How and When to Use Sqlite لصاحبه Gareth Dwyer.

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

سنحاول في هذا المقال شرح الفروقات الرئيسيّة في بعض أكثر أنظمة إدارة قواعد البيانات العلاقيّة (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.

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

أنظمة إدارة قواعد البيانات (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.