مشغل قاعدة البيانات

بالإضافة إلى مُشغّلات لغة معالجة البيانات (DML) القياسية التي تُنفّذ شيفرة PL/SQL عند تعديل البيانات، يدعم أوراكل مُشغّلات تُفعّل عند حدوث تغييرات على مستوى المخطط وأحداث قاعدة البيانات على مستوى النظام. وقد تم تقديم كل من مُشغّلات لغة تعريف البيانات (DDL) على مستوى المخطط ومُشغّلات أحداث النظام معًا في أوراكل 8i . ^{[ 2 ] [ 3 ]}

يدعم Microsoft SQL Server المشغلات لعبارات DML و DDL، بالإضافة إلى مشغل "تسجيل الدخول" الخاص.

يمكن أن يكون نطاق مُشغّل DDL قاعدة بيانات واحدة CREATE TRIGGER...ON DATABASEأو مثيل SQL Server بأكمله CREATE TRIGGER...ON ALL SERVER. عند تكوينه للمثيل بأكمله، يلتقط المُشغّل الأحداث التي تُنفّذ على مستوى الخادم وقاعدة البيانات داخل ذلك المثيل.

تتوفر قائمة كاملة بأحداث تشغيل مشغلات DDL المتاحة في وثائق Microsoft الرسمية . ^{[ 5 ]}

يمكن أن تمتد مشغلات DDL في SQL Server على قاعدة بيانات واحدة أو على مثيل كامل. أما بالنسبة لعمليات DML، insertedفتُستخدم deletedالجداول الوهمية، وبينما تعمل المشغلات على مستوى العبارة، يمكن تحقيق منطق مستوى الصف عبر المؤشر.

أضافت PostgreSQL دعمًا للمشغلات في عام 1997، ثم أضافت مشغلات خاصة بالأعمدة في الإصدار 9.0 بما يتوافق تمامًا مع معيار SQL:2003 . ^{[ 6 ]} بينما تُربط مشغلات DML القياسية بجداول محددة، CREATE TABLEيتم رصد تعديلات المخطط غير المتعلقة بـ DML - مثل - على مستوى قاعدة البيانات بواسطة مشغلات الأحداث، وهي ميزة أُضيفت في PostgreSQL 9.3. ^{[ 7 ]}

يتبع بناء جملة SQL الأساسي لتعريف المشغل في PostgreSQL هذا الهيكل:

إنشاء مُشغّل باسم { قبل | بعد } { حدث [ أو ... ] } على اسم الجدول [ لكل [ صف | عبارة } ] تنفيذ الإجراء funcname ( الوسائط )​​

يدعم Firebird عدة مُشغّلات على مستوى الصفوف لكل جدول لعمليات INSERTالتحديث UPDATEوالتعديل DELETEوالتغيير، بالإضافة إلى أي توليفة من هذه العمليات. تُنفَّذ هذه المُشغّلات إما قبل أو بعد تعديلات البيانات، وتعمل بالإضافة إلى تغييرات الجدول الافتراضية. يمكن للمستخدمين تحديد ترتيب تنفيذ المُشغّلات المتعددة بالنسبة لبعضها البعض باستخدام POSITIONعبارة `-----`. كما يمكن تعريف المُشغّلات على طرق العرض INSTEAD OFكمُشغّلات، والتي تحل محل منطق طريقة العرض القابلة للتحديث الافتراضي. قبل الإصدار 2.1، كانت المُشغّلات على طرق العرض القابلة للتحديث تُنفَّذ بالإضافة إلى منطق المحرك الافتراضي بدلاً من استبداله. ^{[ 8 ]}

يُتيح مُحرك قاعدة البيانات إمكانية تداخل المُشغّلات وتكرارها افتراضيًا، ولا يُثير استثناءات تغيير الجداول. يستخدم Firebird متغيرات NEWالسياق OLDللوصول إلى حالات الصفوف أثناء تعديل البيانات. كما يُوفر علامات السياق المنطقية INSERTINGلتحديد UPDATINGحدث DELETINGDML المُحدد الذي بدأ تنفيذ المُشغّل برمجيًا.

{ إنشاء | إعادة إنشاء | إنشاء أو تعديل } اسم المُشغّل لـ { اسم الجدول | اسم العرض } [ نشط | غير نشط ] { قبل | بعد } { إدراج [ أو تحديث ] [ أو حذف ] | تحديث [ أو إدراج ] [ أو حذف ] | حذف [ أو تحديث ] [ أو إدراج ] } [ الموضع ن ] كبداية .... نهاية

ابتداءً من الإصدار 2.1، أضافت فايربيرد دعمًا للمُشغّلات على مستوى قاعدة البيانات، والتي تُنفّذ خلال أحداث جلسات ومعاملات مُحدّدة. تشمل هذه الأحداث أحداث الاتصال، عبر مُشغّلات `connection` CONNECTو` DISCONNECTconnection`، وأحداث المعاملات، عبر مُشغّلات TRANSACTION START`connection` و`connection` TRANSACTION COMMITو` TRANSACTION ROLLBACKconnection`. في حال حدوث استثناء أثناء CONNECTتشغيل مُشغّل، يتم إيقاف تسلسل الاتصال. وبالمثل، فإن الاستثناءات التي تحدث داخل TRANSACTION COMMITمُشغّل تُعيق إتمام المعاملة، بما في ذلك مرحلة الإعداد أثناء عملية الالتزام على مرحلتين.

يمكن استخدام المشغلات على مستوى قاعدة البيانات لفرض قيود متعددة الجداول أو لمحاكاة طرق العرض المادية . عند حدوث استثناء داخل TRANSACTION COMMITالمشغل، يتم التراجع عن التعديلات التي أجراها المشغل قبل الخطأ، ويتم إخطار تطبيق العميل. ومع ذلك، تظل المعاملة نفسها نشطة كما لو COMMITلم تبدأ العملية أبدًا، مما يسمح للتطبيق بإجراء المزيد من تعديلات البيانات وطلب تسلسل الالتزام. ^{[ 9 ]}

يستخدم بناء الجملة العام لإنشاء أو تعديل المشغلات على مستوى قاعدة البيانات في Firebird البنية التالية:

{ إنشاء | إعادة إنشاء | إنشاء أو تعديل } اسم المُشغّل [ نشط | غير نشط ] عند { اتصال | قطع الاتصال | بدء المعاملة | تأكيد المعاملة | التراجع عن المعاملة } [ الموضع ن ] كبداية ..... نهاية

تدعم مُشغّلات MySQL/MariaDB، التي طُرحت عام 2005 (الإصدار 5.0)، أحداث DML، حيث يُتيح MySQL 8.0 تشغيل مُشغّلات متعددة من النوع نفسه، مع العلم أن مُشغّلات DDL غير مدعومة. ^{[ 10 ]} يستخدم بناء الجملة، المتوافق مع كلا النظامين، CREATE TRIGGERو DROP TRIGGERو FOR EACH ROWلإجراءات على مستوى الصف، مع بدء نصوص الأوامر بـ SETأو BEGIN. ^{[ 11 ]}

يدعم IBM Db2 لأنظمة Linux و Unix و Windows (Db2 لأنظمة LUW) ثلاثة أنواع رئيسية من المشغلات، مصنفة حسب وقت التنشيط: BEFOREو AFTERو و INSTEAD OF. يدعم المحرك مستوى تفصيل على مستوى الصف ومستوى العبارة. في حال تعريف عدة مشغلات لنفس العملية على جدول واحد، يتم تحديد ترتيب تنفيذها تسلسليًا بناءً على طابعها الزمني عند الإنشاء. بدءًا من الإصدار 9.7، يدعم Db2 أيضًا المعاملات المستقلة، مما يسمح للمشغل بتنفيذ عمليات معاملات مستقلة يمكن تثبيتها أو التراجع عنها دون التأثير على عبارة التشغيل. ^{[ 12 ]}

يُستخدم المُشغِّل BEFOREللتحقق من صحة البيانات الواردة وتحديد ما إذا كان ينبغي السماح بتعديل البيانات. في حال حدوث استثناء داخل BEFOREالمُشغِّل، يتم إيقاف العملية واستعادة التغييرات التي أُجريت على قاعدة البيانات. مع أن BEFOREالمُشغِّلات لا تستطيع تنفيذ عبارات لغة معالجة البيانات (DML) لتعديل جداول قاعدة البيانات مباشرةً، إلا أنها ليست للقراءة فقط؛ إذ يُمكنها تعديل حالات البيانات الواردة برمجيًا عن طريق تغيير القيم المستهدفة ضمن متغيرات انتقال الصف قبل كتابتها على القرص. ^{[ 13 ]}

على النقيض من ذلك، AFTERتُنفَّذ المُشغِّلات بعد اكتمال تعديل البيانات المطلوب. وعلى عكس BEFOREالمُشغِّلات الأخرى، AFTERفإن المُشغِّلات الأخرى قادرة تمامًا على تنفيذ عمليات كتابة DML اللاحقة عبر أي جدول قاعدة بيانات، بما في ذلك الجدول النشط الذي بدأ تنفيذ المُشغِّل. INSTEAD OFتُستخدم المُشغِّلات الأخرى حصريًا على طرق العرض لتجاوز منطق المعالجة الافتراضي وجعل طرق العرض غير القابلة للتحديث قابلة للكتابة. عادةً ما يُكتب المنطق الإجرائي داخل مُشغِّلات Db2 باستخدام امتداد لغة SQL PL الإجرائية.

إنشاء مُشغّل مؤقت [ إذا لم يكن موجودًا ] [ اسم_قاعدة_البيانات . ] اسم_المُشغّل [ قبل | بعد | بدلًا من ] { حذف | إدراج | تحديث [ من اسم_العمود [ , اسم_العمود ] ... ] } على { اسم_الجدول | اسم_العرض } [ لكل صف ] [ عند تحقق الشرط ] ابدأ ... انتهى

يدعم SQLite فقط المشغلات على مستوى الصف ولا يوفر دعمًا أصليًا للمشغلات على مستوى العبارة.

يمكن محاكاة طرق العرض القابلة للتحديث، والتي لا يدعمها المحرك افتراضيًا، عن طريق تنفيذ INSTEAD OFالمشغلات على هياكل العرض المستهدفة.

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

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

إنشاء مُشغّل "trigger3" قبل الحذف على المستند "auction" / الموقع // الشخص لكل عقدة DO { إذا ( كان موجودًا ( $ WHERE // open_auction / bidder / personref / @person = $ OLD / @id )) ثم ( ) وإلا $ OLD ; }

في MongoDB Atlas، تُنفَّذ المُشغِّلات كجزء من بنية لا خادمية تعتمد على الأحداث، وذلك لتنفيذ منطق الخادم المؤتمت عند حدوث تغييرات في البيانات. على عكس مُشغِّلات قواعد البيانات التقليدية، التي تعمل مباشرةً على خادم قاعدة البيانات، تعمل مُشغِّلات قاعدة بيانات MongoDB Atlas على طبقة حوسبة قابلة للتوسع بشكل مستقل. وهي تراقب تعديلات البيانات في الوقت الفعلي (مثل `<input>` INSERT, UPDATE` REPLACE<input>`, ` <input> DELETE`, `<input>`) باستخدام ^{[ 14 ]}Change Streams . عند اكتشاف حدث ما، يُنفِّذ المُشغِّل تلقائيًا دالة Atlas مخصصة (مكتوبة بلغة JavaScript) أو يُرسل الحدث إلى خدمة خارجية. تُستخدم هذه الوظيفة بشكل أساسي لضمان اتساق البيانات وسلامتها، ولتنفيذ عمليات التدقيق تلقائيًا عبر منظومة البيانات.

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

{ _id : معرف الكائن ( "59cf1860a95168b8f685e378" ) , معرف العميل : معرف الكائن ( " 59cf17e1a95168b8f685e377 " ) , تاريخ الطلب : ISODate ( " 2018-06-26T16 : 20 : 42.313Z " ) , تاريخ الشحن : ISODate ( " 2018-06-27T08:20:23.311Z " ) , محتويات الطلب : [ { الكمية : 1 , الاسم : " أكياس شاي إيرل جراي - 100 كيس " , السعر : NumberDecimal ( " 10.99 " ) } ] , موقع الشحن : [ { الموقع : "Memphis" ، الوقت : ISODate ( " 2018-06-27T18:22:33.243Z" ) } , ] }

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

الفرق الرئيسي بين هذين النوعين من المشغلات هو عدد مرات تشغيلهما عند تعديل البيانات:

• تُنفَّذ مُشغِّلات مستوى الصف مرة واحدة لكل صف يتأثر بأمر قاعدة البيانات، مثل عبارة INSERT`if` UPDATEأو `if` أو DELETE`if`. على سبيل المثال، إذا UPDATEغيّر أمرٌ ما 50 صفًا في جدول، فسيتم تشغيل مُشغِّل مستوى الصف 50 مرة منفصلة. أما إذا لم يُطابق الأمر أي صفوف ولم يُغيّر أي شيء، فلن يتم تشغيل مُشغِّل مستوى الصف على الإطلاق.
• تُنفَّذ المُشغِّلات على مستوى العبارة مرة واحدة فقط لعبارة SQL بأكملها، بغض النظر عن عدد الصفوف التي تم تغييرها. حتى لو لم يؤثر أمر قاعدة البيانات على أي صفوف، فسيتم تشغيل رمز المُشغِّل على مستوى العبارة مرة واحدة.

تختلف دقة تنفيذ المُشغّلات باختلاف المُحرك، حيث تستخدم أنظمة مثل PostgreSQL FOR EACH ROWمُشغّلات على مستوى الصف، بينما يعتمد خادم Microsoft SQL افتراضيًا على التنفيذ على مستوى العبارة ويتطلب معالجة الصفوف عبر جداول وهمية. يجب على المطورين تجنب تكرار المُشغّلات ، حيث يقوم المُشغّل بتحديث جدول يُشغّل نفسه، مما يُسبب حلقات لا نهائية واحتمالية تعطل قاعدة البيانات.

تحدد خيارات التوقيت، التي يتم تحديدها باستخدام الكلمات BEFOREالمفتاحية AFTER، متى يتم تشغيل المشغل بالنسبة لتعديل البيانات:

• BEFOREتُنفّذ المُشغّلات تعليماتها البرمجية قبل حفظ تغييرات البيانات بشكل دائم في الجدول. ومن الاستخدامات الشائعة للمُشغّلات BEFOREالتحقق من صحة بيانات الإدخال أو إجراء فحوصات أمنية. على سبيل المثال، BEFOREيمكن للمُشغّل التحقق من سجل وارد، إما بتصحيح القيم غير الصحيحة أو إيقاف العملية تمامًا قبل كتابة أي بيانات على القرص.
• AFTERتُنفّذ المُشغّلات شفرتها البرمجية بعد كتابة تغييرات البيانات بأمان في الجدول. تُستخدم هذه المُشغّلات عادةً لمهام ما بعد المعالجة، مثل تسجيل المعلومات التاريخية أو إنشاء سجلات التدقيق. في حين أن BEFOREالمُشغّلات هي الأنسب لفحص البيانات الواردة وتنظيفها، إلا AFTERأنها مثالية لنسخ التغييرات المؤكدة إلى جداول سجلات أو جداول تاريخية منفصلة. ^{[ 15 ]}

يوضح المثال التالي مُشغِّل Oracle PL/SQL على مستوى الصف، مُهيأ للتشغيل بعد UPDATEإجراء عملية على جدول مُسمى phone_book. يسجل هذا المُشغِّل التغييرات السابقة تلقائيًا عن طريق كتابة سجل في جدول تتبع منفصل يُسمى phone_book_audit. كما يستخدم تسلسل قاعدة بيانات يُسمى audit_id_sequenceلإنشاء رقم تعريف فريد لكل سجل جديد.

إنشاء أو استبدال مُشغّل phone_book_audit بعد التحديث في جدول phone_book لكل صف : ابدأ بإدراج البيانات التالية في جدول phone_book_audit : ( audit_id , audit_change , audit_l_name , audit_f_name , audit_old_phone_number , audit_new_phone_number , audit_date ) VALUES ( audit_id_sequence.nextVal , ' Update ' , : OLD.last_name , : OLD.first_name , : OLD.phone_number , : NEW.phone_number , SYSDATE ) ; انتهى .​​

يقوم أمر UPDATEيتم تنفيذه على phone_bookالجدول بتعديل السجلات التي يكون فيها اسم العائلة "جونز":

تحديث جدول phone_book ، تعيين رقم الهاتف = '111-111-1111' حيث اسم العائلة = 'Jones' ؛

يحتوي الجدول الناتج phone_book_auditعلى مدخلين مختلفين لأن قاعدة البيانات المصدرية تحتوي على سجلين يحملان اسم العائلة "جونز". ولأن مُشغِّل مستوى الصف يُنفَّذ مرة واحدة لكل صف مُعدَّل، فإن المحرك يستدعي منطق المُشغِّل مرتين أثناء تنفيذ عبارة تحديث واحدة. ^{[ 16 ]}

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

إنشاء أو استبدال مُشغّل phone_book_history بعد التحديث على phone_book ابدأ بإدراج البيانات في جدول phone_book_edit_history ( audit_history_id , username , modification , edit_date ) VALUES ( audit_history_id_sequence . nextVal , USER , 'Update' , SYSDATE ); انتهى ؛

يؤدي تنفيذ العبارة المتطابقة UPDATEإلى عزل التباين السلوكي لمحفز على مستوى العبارة:

تحديث جدول phone_book ، تعيين رقم الهاتف = '111-111-1111' حيث اسم العائلة = 'Jones' ؛

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

يقوم مُشغّل على مستوى الصف BEFOREبتقييم قيم البيانات الواردة وتعديلها قبل اكتمال عملية الكتابة الفعلية على القرص. يوضح هذا المثال استخدام مُشغّل WHENيعتمد على قيد شرطي لاعتراض INSERTإجراء ما. عندما يحتوي سجل على سلسلة اسم عائلة يتجاوز طولها 10 أحرف، يستدعي المحرك SUBSTRالدالة ^{[ 17 ]} لاقتطاع قيمة الإدخال إلى الحرف الأول منها: ^{[ 18 ]}

إنشاء أو استبدال المشغل phone_book_insert قبل الإدراج في جدول phone_book لكل صف عندما يكون طول ( اسم العائلة الجديد ) أكبر من 10 ، ابدأ : اسم العائلة الجديد : = SUBSTR ( : اسم العائلة الجديد ، 0 ، 1 )؛ انتهى ؛

تُلاحظ هذه الآلية عند محاولة إدخال سجل يستوفي معايير التصفية:

INSERT INTO phone_book VALUES ( 6 , 'VeryVeryLongLastName' , 'Erin' , 'Minneapolis' , 'MN' , '989 University Drive' , '123-222-4456' , 55408 , TO_DATE ( '11/21/1991' , 'MM/DD/YYYY' ));

يقوم المحرك بتثبيت بيانات الصف مع متغير اللقب المختصر، مما يؤكد أن التعديل قد حدث قبل كتابة السجل في الجدول.

يُعدّ تطبيق BEFOREمُشغّل على مستوى العبارة نمط تصميم قياسي لفرض معايير الأمان أو قيود قواعد العمل على مستوى موارد قاعدة البيانات. ^{[ 19 ]} يُقيّد التعريف التالي الوصول إلى قاعدة البيانات على جدول مُستهدف ضمن مخطط مُحدد:

إنشاء أو استبدال المشغل hauschbc قبل الإدراج في جدول SOMEUSER.phone_book ابدأ برفع خطأ التطبيق ( الرقم = > -20050 ، الرسالة = > 'رسالة الخطأ هنا.' )؛ انتهى ؛

تؤدي محاولة إدخال بيانات تستهدف المورد المحمي إلى قيام محرك قاعدة البيانات بإلغاء تسلسل المعاملة وإرجاع رسالة خطأ إلى واجهة تطبيق العميل المُستدعي:

خطأ في SQL: ORA-20050: رسالة الخطأ هنا.

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