في مجال تكنولوجيا المعلومات، هناك مجالان متكاملان:

تركز التقنيات على معالجة البيانات التشغيلية (المعاملات). وتشكل هذه التقنيات أساس أنظمة المعلومات الاقتصادية المصممة للمعالجة السريعة للبيانات. تسمى هذه الأنظمة - OLTP(معالجة المعاملات عبر الإنترنت) أنظمة;

تركز التقنيات على تحليل البيانات واتخاذ القرار. تكمن هذه التقنيات في أنظمة المعلومات الاقتصادية المصممة للتحليل

البيانات المتراكمة. تسمى هذه الأنظمة - OLAP

(المعالجة التحليلية عبر الإنترنت) أنظمة.

الغرض الرئيسي من أنظمة OLAP- ديناميكية متعددة الأبعاد

تحليل البيانات التاريخية والحالية، مستقرة مع مرور الوقت، والتحليل

الاتجاهات والنمذجة والتنبؤ بالمستقبل. هذه

تركز الأنظمة، كقاعدة عامة، على المعالجة التعسفية،

طلبات غير منظمة مقدما. الرئيسية

ويمكن ملاحظة خصائص هذه الأنظمة على النحو التالي:

دعم تمثيل البيانات متعددة الأبعاد، والمساواة في جميع الأبعاد، واستقلال الأداء عن عدد الأبعاد؛

الشفافية للمستخدم فيما يتعلق بالهيكل وطرق تخزين ومعالجة البيانات؛

التعيين التلقائي لبنية البيانات المنطقية للأنظمة الخارجية؛

معالجة المصفوفات المتفرقة ديناميكيًا بطريقة فعالة.

مصطلح OLAP جديد نسبيًا ويتم تفسيره أحيانًا بشكل مختلف في مصادر الأدب المختلفة. غالبًا ما يتم تعريف هذا المصطلح بأنظمة دعم القرار (DSS (Decision Support Systems) - أنظمة دعم القرار. وكمرادف للمصطلح الأخير يستخدمون Data Warehouses - مستودعات البيانات، ويعني مجموعة من الحلول التنظيمية والبرمجيات والأجهزة لتزويد المحللين بمعلومات مبنية على بيانات من أنظمة معالجة المعاملات ذات المستوى الأدنى ومصادر أخرى

تسمح لك "مستودعات البيانات" بمعالجة البيانات المتراكمة على مدى فترات زمنية طويلة. هذه البيانات غير متجانسة (وليست منظمة بالضرورة). تتميز مستودعات البيانات بالطبيعة المتعددة الأبعاد للاستعلامات. تتطلب الكميات الضخمة من البيانات وتعقيد بنية كل من البيانات والاستعلامات استخدام طرق خاصة للوصول إلى المعلومات.

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

يتضمن OLAP دائمًا معالجة الاستعلام التفاعلية والتحليل اللاحق للمعلومات متعدد التمريرات، مما يسمح لنا بتحديد الاتجاهات المختلفة، غير الواضحة دائمًا، التي تمت ملاحظتها في مجال الموضوع.

في بعض الأحيان يتم التمييز بين "OLAP بالمعنى الضيق" - وهي أنظمة توفر فقط مجموعة مختارة من البيانات في أقسام مختلفة، و"OLAP بالمعنى الواسع"، أو ببساطة OLAP، والتي تتضمن:

دعم لعدة مستخدمين لتحرير قاعدة البيانات.

وظائف النمذجة، بما في ذلك الآليات الحسابية للحصول على النتائج المشتقة، فضلا عن تجميع البيانات والجمع بينها؛

التنبؤ والاتجاهات والتحليل الإحصائي.

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

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

يمكن تقسيم أنظمة OLAP إلى ثلاث فئات.

تعتمد أكثرها تعقيدًا وتكلفة على تقنيات حاصلة على براءة اختراع خوادم قواعد البيانات متعددة الأبعاد. هذه الأنظمة توفير دورة كاملة من معالجة OLAPوإما أن تشمل، بالإضافة إلى مكون الخادم، واجهة العميل المتكاملة الخاصة بهم، أو تستخدم برامج جداول البيانات الخارجية لتحليل البيانات. تعتبر منتجات هذه الفئة مناسبة للاستخدام في مستودعات المعلومات الكبيرة. تتطلب صيانتها طاقمًا كاملاً من الموظفين المشاركين في تثبيت النظام وصيانته وإنشاء طرق عرض البيانات للمستخدمين النهائيين. عادة ما تكون هذه الحزم باهظة الثمن. تتضمن أمثلة المنتجات في هذه الفئة نظام Essbase من Arbor Software، وExpress من IRI (الآن جزء من Oracle)، وLightship من Pilot Software، وغيرها.

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

مع الأخذ في الاعتبار كل ما سبق، لا يمكن إجراء المقارنات بين منتجات MDD المختلفة إلا في الفئات الأكثر عمومية. في القطاع الأرخص من السوق، لا يوجد سوى عارض بيانات لمستخدم واحد ومتعدد الأبعاد مصمم للشبكات المحلية الصغيرة. على الرغم من أنها توفر مستوى عالٍ إلى حد ما من الوظائف وسهلة الاستخدام، إلا أن هذه الأنظمة محدودة النطاق. ويفتقرون إلى الأدوات اللازمة لتنفيذ معالجة OLAP بالمعنى الواسع. وتشمل المنتجات التي تندرج ضمن هذه الفئة PowerPlay من Cognos، وAndyne's PaBlo، وMercury من Business Objects. يتم تمثيل القطاع الباهظ الثمن في السوق بأنظمة Acumate ES من شركة Kenan Technologies، وExpress من شركة Oracle Corporation، وGentium من Planning Sciences وHolos من Holistic Systems. إنهم يختلفون كثيرًا في قدراتهم بحيث يمكن فصل أي منهم بأمان إلى فئة منفصلة. وأخيرًا، أنظمة MDD في شكلها النقي: Essbase من Arbor Software، وLightShip Server من Pilot Software، وTM/1 من Sinper [N. رادين (سوق البرمجيات)].

الفئة الثانية من أدوات OLAP - أنظمة OLAP العلائقية(رولاب). هنا، يتم استخدام أنظمة إدارة قواعد البيانات العلائقية القديمة لتخزين البيانات، ويتم تنظيم طبقة البيانات التعريفية التي يحددها مسؤول النظام بين قاعدة البيانات وواجهة العميل. من خلال هذه البرامج الوسيطة، يمكن لمكون العميل التفاعل مع قاعدة البيانات العلائقية كما لو كانت قاعدة بيانات متعددة الأبعاد. مثل الأدوات من الدرجة الأولى، تعد أنظمة ROLAP مناسبة تمامًا للعمل مع مستودعات المعلومات الكبيرة، وتتطلب تكاليف صيانة كبيرة من قبل متخصصين من أقسام المعلومات وتوفر العمل في وضع متعدد المستخدمين. تشتمل المنتجات من هذا النوع على IQ/Vision من IQ Software، وDSS/Server وDSS/Agent من MicroStrategy، وDecisionSuite من Information Advantage.

ROLAP - تقوم الأدوات بتنفيذ وظائف دعم القرار في وظيفة إضافية عبر معالج قاعدة البيانات العلائقية.

يجب أن تستوفي هذه المنتجات البرمجية عددًا من المتطلبات، على وجه الخصوص:

احصل على منشئ تعبيرات SQL قوي محسّن لـ OLAP، مما يسمح لك باستخدام عبارات SQL SELECT متعددة التمرير و/أو الاستعلامات الفرعية المرتبطة؛

أن يكون لديه وسائل متطورة بما فيه الكفاية لتنفيذ المعالجة غير التافهة، وتوفير التصنيف والتحليل المقارن وحساب النسب المئوية داخل الفصل؛

إنشاء تعبيرات SQL محسنة لنظام إدارة قواعد البيانات الارتباطي المستهدف، بما في ذلك دعم امتدادات اللغة المتوفرة فيه؛

توفير آليات لوصف نموذج البيانات باستخدام البيانات الوصفية وإتاحة استخدام هذه البيانات الوصفية لبناء الاستعلامات في الوقت الفعلي؛

تضمين آلية تسمح لك بتقييم جودة بناء الجداول المحورية من حيث سرعة الحساب، ويفضل أن يكون ذلك مع تراكم الإحصائيات حول استخدامها.

النوع الثالث الجديد نسبيًا من أدوات OLAP - أدوات الاستعلام وإعداد التقارير على سطح المكتبأو مكملة بوظائف OLAP أو مدمجة مع أدوات خارجية تؤدي مثل هذه الوظائف. تقوم هذه الأنظمة المتقدمة للغاية باسترداد البيانات من المصادر الأولية وتحويلها ووضعها في قاعدة بيانات ديناميكية متعددة الأبعاد تعمل على جهاز الكمبيوتر الخاص بالمستخدم النهائي. هذا النهج، الذي يجعل من الممكن الاستغناء عن خادم قاعدة بيانات باهظ الثمن ومتعدد الأبعاد وطبقة بيانات تعريف وسيطة معقدة مطلوبة لأدوات ROLAP، يضمن في الوقت نفسه كفاءة تحليل كافية. تعتبر أدوات سطح المكتب هذه مناسبة بشكل أفضل للعمل مع قواعد البيانات الصغيرة والبسيطة. إن الحاجة إلى الصيانة الماهرة أقل بالنسبة لهم مقارنة بأنظمة OLAP الأخرى، وهي تساوي تقريبًا مستوى بيئات معالجة الاستعلام التقليدية. ومن بين اللاعبين الرئيسيين في قطاع السوق هذا شركة Brio Technology مع نظامها Brio Query Enterprise، وBusiness Objects مع منتجها الذي يحمل نفس الاسم، وCognos مع PowerPlay.

حاليًا، يتزايد عدد منتجات OLAP المتوافقة مع الويب.

هناك مشكلة مهمة وهي تكييف OLAP مع البرامج الأخرى. على الرغم من أن بائعي OLAP بدأوا في تقديم بعض الطرق للتفاعل مع أنظمة إدارة قواعد بيانات SQL وأدوات أخرى، إلا أن المستخدمين والمحللين يحذرون من أن مستوى التكامل سيختلف ومن المرجح أن يتطلب قدرًا كبيرًا من الترميز، بما في ذلك كتابة الاستعلامات في SQL. علاوة على ذلك، لا يوجد معيار صناعي لدمج OLAP مع بقية برامج المؤسسة.

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

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

1. باستخدام أنظمة OLTP التقليدية، يمكنك إنشاء تقرير تحليلي وحتى تنبؤ بأي تعقيد، ولكن يتم تنظيمه مسبقًا. أي خطوة جانبا، أي متطلبات غير منظمة للمستخدم النهائي، كقاعدة عامة، تتطلب معرفة بنية البيانات ومؤهلات عالية إلى حد ما للمبرمج؛

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

3. على عكس أنظمة المعاملات، لا تتطلب الأنظمة التحليلية، وبالتالي، لا توفر وسائل متطورة لضمان سلامة البيانات والنسخ الاحتياطي والاسترداد. ولا يسمح هذا بتبسيط أدوات التنفيذ نفسها فحسب، بل يسمح أيضًا بتقليل الحمل الداخلي، وبالتالي تحسين الأداء عند استرداد البيانات.

سنحدد نطاق المهام التي تم حلها بشكل فعال بواسطة كل نظام بناءً على الخصائص المقارنة لأنظمة OLTP وOLAP (الجدول 8).

من الممكن تحديد فئات معينة من الأنظمة التي تكون نماذج البيانات المقيسة بقوة أو ضعيفة أكثر ملاءمة لها.

تعد نماذج البيانات عالية التطبيع مناسبة تمامًا لما يسمى تطبيقات OLTP(معالجة المعاملات عبر الإنترنت (OLTP)-معالجة المعاملات السريعة ). الأمثلة النموذجية لتطبيقات OLTP هي أنظمة محاسبة المستودعات، وأنظمة طلب التذاكر، والأنظمة المصرفية التي تقوم بعمليات تحويل الأموال، وما إلى ذلك.

وتتمثل المهمة الرئيسية لهذه الأنظمة في تنفيذ عدد كبير من المعاملات القصيرة. تبدو المعاملات نفسها بسيطة نسبيًا، على سبيل المثال، "سحب مبلغ من المال من الحساب أ، وإضافة هذا المبلغ إلى الحساب ب".

تكمن المشكلة في أنه أولاً، هناك الكثير من المعاملات، وثانيًا، يتم تنفيذها في وقت واحد (يمكن توصيل عدة آلاف من المستخدمين المتزامنين بالنظام)، وثالثًا، في حالة حدوث خطأ، يجب التراجع عن المعاملة بالكامل وإرجاع النظام إلى الحالة التي كانت قبل بدء المعاملة (لا ينبغي أن يكون هناك موقف يتم فيه سحب الأموال من الحساب أ، ولكن لم تصل إلى الحساب ب). تتكون جميع استعلامات قاعدة البيانات تقريبًا في تطبيقات OLTP من أوامر الإدراج والتحديث والحذف. لذلك، تعد سرعة وموثوقية عمليات تحديث البيانات القصيرة أمرًا بالغ الأهمية لتطبيقات OLTP. كلما ارتفع مستوى تسوية البيانات في تطبيق OLTP، أصبح أسرع وأكثر موثوقية.

نوع آخر من التطبيقات هو ما يسمى تطبيقات أولاب(المعالجة التحليلية عبر الإنترنت(OLAP) -معالجة البيانات التحليلية التشغيلية ). هذا مصطلح عام يميز مبادئ البناء أنظمة دعم القرار (نظام دعم القرار-مفاجآت صيف دبي),مستودعات البيانات(مستودع البيانات),أنظمة استخراج البيانات (بيانات التعدين). تم تصميم هذه الأنظمة للعثور على التبعيات بين البيانات (على سبيل المثال، يمكنك محاولة تحديد مدى ارتباط حجم مبيعات البضائع بخصائص المشترين المحتملين)، لإجراء تحليل "ماذا لو ...".

تعمل تطبيقات OLAP على كميات كبيرة من البيانات المتراكمة بالفعل في تطبيقات OLTP، المأخوذة من جداول البيانات أو مصادر البيانات الأخرى. وتتميز هذه الأنظمة بالميزات التالية:

نادرًا ما تتم إضافة بيانات جديدة إلى النظام في كتل كبيرة (على سبيل المثال، بمجرد تنزيل بيانات ربع سنوية بناءً على نتائج المبيعات ربع السنوية من تطبيق OLTP).

عادةً لا يتم حذف البيانات المضافة إلى النظام أبدًا.

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

الاستعلامات الموجهة إلى النظام غير منظمة، وعادة ما تكون معقدة للغاية.

تعد سرعة تنفيذ الاستعلام أمرًا مهمًا، ولكنها ليست حاسمة.

عادةً ما يتم تمثيل البيانات من تطبيقات OLAP كمكعب واحد أو أكثر، تكون أبعادها بيانات مرجعية، وتقوم خلايا المكعب الفائق نفسه بتخزين البيانات الفعلية. على سبيل المثال، يمكنك إنشاء مكعب فائق، أبعاده هي: الوقت (بالأرباع، السنوات)، نوع المنتج وفروع الشركة، وحجم مبيعات متجر الخلايا. سيحتوي هذا المكعب الفائق على بيانات عن مبيعات أنواع مختلفة من البضائع حسب الربع والقسمة. بناءً على هذه البيانات، يمكنك الإجابة على أسئلة مثل "ما هو القسم الذي حقق أفضل حجم مبيعات هذا العام؟"، أو "كيف هي اتجاهات مبيعات أقسام المنطقة الجنوبية الغربية هذا العام مقارنة بالعام السابق؟"

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

• < Назад
• إلى الأمام >

تعد معالجة المعاملات عبر الإنترنت (OnLine Transaction Processing - OLTP) من أهم وسائل التفاعل مع المعلومات الموجودة داخل الأجهزة الذكية. وفي الوقت نفسه، فإن بناء أنظمة OLTP معقدة وعالية الأداء ليس بالمهمة السهلة. غالبًا ما يؤدي تنوع التقنيات واتجاهات الموضة إلى إرباك المطور عند اختيار حل معين أو إجباره على "توسيع" التقنيات المعروفة للمهمة المطروحة، مما يؤدي أحيانًا إلى نتائج غير متوقعة. عندما تظهر عدة منصات في مشروع واحد، تصبح المهمة أكثر صعوبة.

من وجهة نظر المهام التطبيقية، فإن أي نظام تفاعلي له ثلاثة مستويات رئيسية: تخزين البيانات؛ المنطق المطبق العرض التقديمي (واجهة المستخدم النهائية). وفقًا لذلك، من وجهة نظر التنفيذ، قد يشتمل النظام على خادم بيانات، وخادم منطق التطبيق (خادم التطبيقات)، ومجموعة من الواجهات لتقديم المعلومات إلى المستخدم النهائي. كقاعدة عامة، يتم استخدام نظام إدارة قواعد البيانات من نوع SQL أو هياكل الملفات أو مصادر البيانات الخاصة كأساس لخادم البيانات. مع نماذج الواجهة، كل شيء واضح أيضًا: يمكنك تنفيذ واجهات رسومية، و"شاشات خضراء" نصية، وواجهات ويب، وما إلى ذلك. لكن مسألة تنفيذ خادم التطبيقات ليست بسيطة كما قد تبدو للوهلة الأولى. إذا نظرت إلى التطبيقات المحلية الحالية للأنظمة، فيمكن تحديد اتجاهين:

• ويتم وضع المنطق مع الواجهات (العميل "السميك")؛
• يتم وضع المنطق على جانب خادم البيانات (أكثر شيوعًا).

في الحالة الأخيرة، كقاعدة عامة، يتم استخدام أنظمة إدارة قواعد البيانات من نوع SQL، والتي تتمتع ببعض وظائف دعم خادم التطبيق في شكل آلية الإجراء المخزن. عند تنفيذه، يتم تحويل المخطط ثلاثي الطبقات إلى بنية خادم العميل ذات المستويين. بالنسبة للأنظمة الصغيرة، يعد هذا حلاً مقبولاً تمامًا، ولكن هذه البنية لها عدد من العيوب، بما في ذلك قابلية التوسع المحدودة. ويسمح تنفيذه، حتى على الأنظمة الأساسية القوية من فئة S/390، بتحقيق أعلى أداء بما لا يزيد عن 200 معاملة في الثانية.

في بعض التطبيقات، يقوم المطورون بفصل خادم التطبيق إلى مكون منفصل. لكن هذه التطبيقات، كقاعدة عامة، لا تمثل سوى مجموعة من البرامج التطبيقية التي لا تعتمد على أي خدمات خاصة، ولكنها تستخدم آليات نظام التشغيل القياسية، والتي، بشكل عام، لا تصل بالنظام إلى مستوى جودة مختلف مقارنة بوحدتين -الهندسة المعمارية الطبقة. وينطبق هذا على أي نظام أساسي تقريبًا، باستثناء AS/400 وVM/ESA، حيث تكون أنظمة التشغيل نفسها هي خادم المعاملات. وفي الأنظمة الأساسية الأخرى، لا يمكن تحقيق وظائف مماثلة إلا باستخدام منتجات خاصة إضافية، والتي سيتم مناقشتها، من بين أشياء أخرى، في هذه المقالة.

فسيفساء التقنيات

بدءًا من منصة الكمبيوتر الشخصي، باستخدام تقنيات Borland وMicrosoft في المراحل الأولية، نفذت شركتنا العديد من المشاريع في بنية ثنائية المستويين. مع نمو حجم المشاريع وشمولها للعديد من المنصات، ظهر السؤال حول إيجاد وتحسين التقنيات المستخدمة لبناء الأنظمة ذات الخصائص الاستهلاكية الضرورية.

بعد اختبار التقنيات والأدوات المختلفة، اخترنا تقنيات IBM، التي توفر نطاقًا واسعًا من حلول الأجهزة والبرامج المفتوحة. وبالنظر إلى أننا نقوم بتنفيذ مشاريع OLTP للعملاء الذين غالبًا ما يستخدمون بالفعل تقنيات من Microsoft وOracle وشركات أخرى، فإن القدرة على مشاركة الحلول من IBM والموردين البديلين كانت مفيدة جدًا (الشكل 1).

ولتنفيذ مشكلات النظام الدقيقة بشكل خاص، نلجأ أيضًا إلى البرمجة بلغة C++ أو Cobol، لكن هذا لا يستغرق أكثر من 1-2% من إجمالي حجم العمل.

مراقبة معاملات IBM CICS

أصبحت مراقبة المعاملات CICS (نظام التحكم في المعلومات المخصصة)، التي تتمتع بتاريخ غني، رائدة في مجالها لأكثر من 30 عامًا من وجودها. إنها البرمجيات الوسيطة التي تمثل العمود الفقري الموثوق لبناء أنظمة OLTP.

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

يتم تطبيق CICS على جميع المنصات الرئيسية تقريبًا، وهو يسمح لك ببناء بيئة معاملات معقدة وموزعة وغير متجانسة. يستخدم CICS واجهة X/Open XA للتفاعل مع مديري الموارد المختلفين والتفاعل مع المنتجات من كبار موردي DBMS. إن استخدام مراقب المعاملات يجعل النظام أكثر قابلية للتطوير مقارنة بالحلول التي تضع نظام إدارة قواعد البيانات في المركز. وبالتالي، استنادًا إلى الإصدارات القياسية من CICS، من الممكن بناء أنظمة ذات أداء ذروة يصل إلى 500 معاملة في الثانية، وبمساعدة الإصدارات الخاصة (على سبيل المثال، برنامج Transaction Processing Facility، المستخدم في أنظمة حجز تذاكر الطيران عبر الإنترنت) و مع أحمال ذروة أعلى.

لاحظ أن TPC، اختبارات الصناعة لأقصى أداء لنظام إدارة قواعد البيانات ( www.tpc.org)، يتم تنفيذها باستخدام مراقبي المعاملات، مما يسمح لك بالحصول على أفضل المؤشرات. لماذا؟ تلعب مراقبة المعاملات دور "الشاحن التوربيني" لنظام إدارة قواعد البيانات، من بين أمور أخرى، حيث تعمل على تسريع تنفيذ استعلامات SQL بسبب ميزات التصميم لكل من جوهرها والواجهة مع نظام إدارة قواعد البيانات (الواجهة في عميل من مستويين- بنية الخادم محدودة للغاية في الأداء). يتيح لك ذلك تقليل الوقت اللازم لإرسال الطلب قبل معالجته بواسطة DBMS kernel. بالإضافة إلى ذلك، تحل مراقبات المعاملات مشكلة موازنة التحميل بشكل أفضل من أنظمة إدارة قواعد البيانات.

يدعم CICS خمسة أنواع من التفاعل عالي المستوى بين الخوادم، والتي يمكن تنظيمها عبر أي بروتوكولات شبكة (TCP/IP، وSNA، وNetBIOS، وما إلى ذلك).

• وظيفة الشحن (FS).تعديل مصادر البيانات (الملفات) البعيدة عن خادم CICS المحلي. عندما تصل معاملة على خادم CICS محلي إلى هذا المصدر، فإنها تعيد توجيه الطلب تلقائيًا إلى الخادم الذي يملك مصدر البيانات هذا. يتم ضمان سلامة البيانات في حالة حدوث أي فشل.
• توجيه المعاملات (TR).إعادة توجيه مكالمات المعاملات بين خوادم CICS. يمكنك "نقل" معاملة من خادم إلى خادم وتحتاج فقط إلى إعادة تعريف المرجع على خادم CICS دون تغيير رمز البرنامج.
• المعالجة غير المتزامنة (AP).قم بتشغيل المعاملة بشكل غير متزامن على خادم CICS آخر. تبدأ المعاملة الجديدة في "العيش" من تلقاء نفسها، ويعود التحكم فورًا إلى المعاملة المستدعية.
• رابط البرنامج الموزع (DPL).استدعاء معاملة عن بعد وإعادة التحكم بعد انتهاء المعاملة المطلوبة. يتم استخدام هذا النوع من التفاعل في أنظمة التطبيقات في أغلب الأحيان.
• معالجة المعاملات الموزعة (DTP).حوار عبر الإنترنت بين معاملتين يتم تشغيلهما على خوادم CICS مختلفة. من وجهة نظر التطوير والتصحيح، هذا هو النوع الأكثر غرابة وتعقيدًا من التفاعل.

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

خادم قائمة انتظار المعاملات MQSeries

المفهوم الكامن وراء البرامج الوسيطة MOM، وتحديدًا MQSeries، بسيط للغاية. يقوم التطبيق بوضع بعض بنية البيانات (الرسالة) في قائمة انتظار على خادم MQSeries المحلي ثم يخرج. يتم إرسال الرسالة المخزنة من قائمة الانتظار المحلية بواسطة وكيل قناة MQSeries إلى خادم MQSeries البعيد ويتم تخزينها هناك في قائمة انتظار الإدخال. في هذه الحالة، تتم إزالة الرسالة من قائمة الانتظار المحلية. تضمن MQSeries نقل المعاملات - لن يتم فقدان الرسالة أو إرسالها مرتين (هذه هي الميزة الرئيسية على أنظمة البريد، والتي تستخدم غالبًا لتنفيذ وظائف المعالجة الموزعة). بعد تلقي رسالة على خادم بعيد، يمكن لبرنامج التطبيق قراءتها في أي وقت مناسب وتنفيذ الإجراءات اللازمة؛ حتى يقرأ التطبيق هذه الرسالة، سيتم تخزينها في MQSeries.

يمكن توصيل MQSeries بمراقبة المعاملات CICS مع نظام إدارة قواعد البيانات (DBMS). في هذه الحالة، يعمل CICS كمنسق خارجي للمعاملات (منسق المعاملات الخارجية - ETC)، مما يلغي المواقف التي يتم فيها تغيير البيانات الموجودة في نظام إدارة قواعد البيانات (DBMS) ولم يتم إرسال الرسالة، أو العكس - تم تغيير البيانات بسبب بعض الفشل. لم يتغير، ولكن تم إرسال رسالة التغيير. يؤدي هذا في النهاية إلى حالة عدم تطابق البيانات على العقد الموزعة لنظام OLTP. يتيح لك استخدام مراقب المعاملات تجنب مثل هذه المواقف.

تتصدر MQSeries سوق MOM (أكثر من 70%)، وتكمل CICS بالقدرة على بناء بيئة معاملات موزعة غير متجانسة معقدة مع نوع غير متزامن من التفاعل.

قاعدة البيانات العالمية DB2

DB2 هو نظام إدارة قواعد البيانات الرائد لشركة IBM. استخدامه كأساس لخادم البيانات لأنظمة OLTP يجعل من الممكن تنفيذ معالجة البيانات المعقدة وتخزين المصفوفات الكبيرة. يتم نقل هذه الوظائف إلى خادم البيانات، مما يخفف من عبء خادم التطبيقات. ولكن إذا كنت بحاجة إلى إنشاء نظام لا يكون فيه تخزين البيانات ومعالجتها معقدًا للغاية، وتظهر متطلبات الأداء وتقليل الموارد في المقدمة (يتطلب كود kernel DBMS موارد كبيرة)، فيمكنك استخدام هياكل الملفات المتصلة بـ CICS خادم المعاملات. على سبيل المثال، تم بناء العديد من أنظمة OLTP الغربية الكبيرة المعروفة للحاسبات المركزية S/390 على أساس CICS وVSAM.

خادم تطبيقات ويب سفير

تشتمل مجموعة منتجات البرامج WebSphere Application Server على ثلاثة إصدارات - Standard وAdvanced وEnterprise. إذا تحدثنا عن دعم المعاملات، فإن الإصدار القياسي لا يحتوي على هذه الخدمة، ويدعم الإصدار المتقدم خدمة Java Transaction Service (JTS)، بالإضافة إلى مواصفات Enterprise JavaBeans، ويحتوي الإصدار Enterprise على موصلات خاصة للتفاعل مع "All-wheel" "قيادة" أنظمة المعاملات مثل CICS.

عند الحديث عن WebSphere، فإنهم غالبًا ما يقصدون فقط مكون الإنترنت لهذا المنتج - خادم التطبيقات، وهو خادم تطبيقات قوي عبر الأنظمة الأساسية يدعم جميع المواصفات والبروتوكولات المعروفة تقريبًا.

في المشاريع الحقيقية، نتجنب برمجة منطق الأعمال باستخدام لغة جافا، حيث أن تنفيذ خادم التطبيقات، على سبيل المثال، بتنسيق Enterprise JavaBeans، يؤدي إلى انخفاض كبير في أداء التطبيق ويجبر على التطوير بلغة الجيل الثالث، وهي أقل فعالة مقارنة بمجموعة أدوات VisualAge Generator. ومع ذلك، فإن استخدام متصفحات الويب في مكان العمل يوفر مزايا معينة للأنظمة التفاعلية: ليست هناك حاجة للدفع مقابل تراخيص إضافية لأجهزة العميل؛ من الممكن عرض المعلومات الرسومية. ليست هناك حاجة لنسخ التطبيق عبر مواقع العملاء.

يتطلب توصيل المتصفحات بأنظمة خلفية قوية استخدام خوادم الإنترنت. يمكن اعتبار WebSphere Application Server بمثابة نوع من المحول الذي يسمح للتعليمات البرمجية من المتصفح، من خلال استدعاء servlet، بالوصول إلى معاملة في CICS وإرجاع النتيجة إلى المتصفح، مما يؤدي إلى إنشاء صفحة HTML أمامية بسرعة.

لاحظ أن OS/390 يدعم واجهة دعم ويب CICS، والتي من خلالها يمكن للمتصفح الاتصال مباشرة بخادم CICS. ولكن لتوحيد البنية عبر الأنظمة الأساسية، وبالنظر إلى أن أداة تطوير تطبيق VisualAge Generator تقوم ببناء أنظمة باستخدام WebSphere Application Server، فإننا نستخدم هذا المنتج على S/390 أيضًا. يساعد هذا في حل مشكلات نقل كود هذه التطبيقات بين الأنظمة الأساسية.

التطوير على مولد VisualAge

يعد VisualAge Generator أداة سريعة لتطوير التطبيقات. هذا المنتج هو "الغراء" الذي يسمح لك ببساطة بدمج جميع التقنيات المذكورة أعلاه في صورة واحدة.

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

تبدو دورة تطوير التطبيق باستخدام VisualAge Generator مختلفة قليلاً (الشكل 3). تعتمد بيئة التطوير هذه على Universal Virtual Machine (UVM)، وهو الأساس لبيئات التطوير مثل VisualAge for Smalltalk وVisualAge for Java، والتي تم تثبيت VisualAge Generator عليها.

لتشغيل التطبيق وتصحيح أخطائه، ليست هناك حاجة إلى ترجمة التطبيق وإنشائه. لتصحيح أخطاء تشغيل نماذج المنطق والواجهة، يستخدمون دورة "صغيرة" (العمليتين 1 و2)، مما يقلل من وقت التطوير ولا يتطلب منصة مستهدفة. في هذه الدورة، يتم إنجاز 80-90% من العمل ويمكنك إنجازه باستخدام جهاز كمبيوتر يعمل بنظام التشغيل Windows NT أو OS/2، والذي يمكن تثبيت VisualAge Generator Developer عليه.

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

يتم دعم أكثر من 20 نظامًا أساسيًا كنظام أساسي مستهدف لخادم التطبيقات، بما في ذلك CICS وMQSeries. بمجرد إنشاء رمز وقت تشغيل الخادم، يمكن تصحيحه من داخل بيئة VisualAge Generator، أي. تحقق من وظيفة الكود النهائي (حلقة كبيرة من العمليات 3، 4، 5، 6).

لا يتضمن VisualAge Generator أدوات لتطوير وبرمجة خوادم البيانات، على سبيل المثال، نظام إدارة قواعد البيانات (DBMS). ولكن، مع وجود بنية قاعدة بيانات جاهزة، يمكنك إنشاء بنية التطبيق بالكامل تلقائيًا، بما في ذلك مكونات الخادم والعميل، باستخدام أداة قوالب مولد VisualAge (VAGT)، والتي يتم تضمينها في التسليم. من خلال تحديد بعض الشروط مسبقًا، يمكنك تلقائيًا إنشاء البنية التحتية للتطبيق بالكامل تقريبًا، والتي تمثل ما يصل إلى 80% من أعمال البرمجة. وهذا يحفظ المطور من إنشاء عناصر يدويًا مثل برامج الخادم والعمليات وكائنات الأعمال وعناصر النموذج ومعالجات الاستثناءات وما إلى ذلك. وبالنظر إلى وجود المئات والآلاف من هذه العناصر في المشاريع الحقيقية، فإن VAGT يقلل بشكل كبير من الوقت الذي يستغرقه إنشاء رمز التطبيق. بعد ذلك، تحتاج فقط إلى ملء الطلبات بمنطق الأعمال المناسب، والمكتوب بلغة 4GL.

"التعميم الشامل"

في التين. يوضح الشكل 4 البنية العامة لنظام OLTP الموزع، والذي يعتمد على التقنيات الموصوفة.

أساس النظام هو CICS (CICS A، على سبيل المثال، على النظام الأساسي Windows NT، CICS B على النظام الأساسي S/390). يمكن لخادمي المعاملات هذين التفاعل بشكل متزامن (TR وAC وFS وDPL وDTP) وبشكل غير متزامن من خلال MQSeries (مديري MQ1 وMQ2 للمنصات المقابلة). يتصل مديرو قائمة الانتظار بخوادم CICS الخاصة بهم عبر واجهة XA. أيضًا، يتم توصيل مصادر البيانات المختلفة بخوادم CICS (في Windows NT - DB2 و/أو Oracle DBMS وMicrosoft SQL Server، على S/390 - DB2 وVSAM، والتي تم تعريفها في CICS من خلال تعريف الموارد عبر الإنترنت).

يعمل WebSphere Application Server (WSAS) كمحول للمكالمات من عملاء الويب إلى نظام الواجهة الخلفية (المعاملات P1، P2، P3)، المكتوبة في VisualAge Generator.

يعد VisualAge Generator Server (VAGen Srv) منتجًا يعتمد على النظام الأساسي مطلوبًا لتشغيل البرامج التي تم تطويرها على VisualAge Generator.

الاتصالات المباشرة بـ CICS ممكنة للعملاء الذين لديهم واجهة مستخدم رسومية أو نصية. في هذه الحالة، يمكن تعريف البرامج P1 وP2 في CICS A على أنها برامج بعيدة، ثم سيتم إعادة توجيه مكالماتها في CICS A تلقائيًا بواسطة طريقة TR إلى CICS B وتشغيلها هناك. P3 عبارة عن معاملة محلية في CICS A يمكنها إرسال رسائل إلى CICS B عبر MQSeries.

يجب أن يقال أن مثيلات CICS مثل CICS A وCICS B (في CICS يتم تحديدها بمصطلح "المنطقة") يمكن أن تكون موجودة ليس فقط على أجهزة مختلفة، ولكن أيضًا على نفس الخادم أو في مجموعة. عمل المناطق معزول و"سقوط" إحداها لا يؤثر على عمل المناطق الأخرى. وهذا يوفر أيضًا مزايا في قابلية التوسع، مما يسمح بتقسيم المهام عبر المناطق من حيث التخصص. يتم ممارسة هذا الأسلوب في أغلب الأحيان على أنظمة S/390، خاصة في مجموعات Sysplex. تحتوي الأنظمة الحقيقية على عدة مئات من المناطق وعشرات الآلاف من المعاملات.

ومع ذلك، فإن التكنولوجيا نفسها دون الأدوات المناسبة لا توفر "العادم" المتوقع. لنفترض أن CICS جيد جدًا، ولكن إذا حاولت تنفيذ نظام في C++ أو Cobol، فسوف يتطلب الأمر أن يكون لدى مطور منطق الأعمال معرفة جيدة بكل من لغة البرمجة وواجهات برمجة تطبيقات CICS، التي تشبه واجهات برمجة تطبيقات نظام التشغيل. سيتم قضاء الكثير من الوقت في إنشاء عناصر البنية التحتية (وصف الوظائف والمتغيرات وما إلى ذلك) وتصحيح مثل هذا المشروع. ولكن إذا كنت تأخذ VisualAge Generator، فسوف يخفف مطور منطق الأعمال من الحاجة إلى معرفة CICS، مما يسمح له بالتركيز على مهامه المباشرة. بالطبع، لتنفيذ مشاريع معقدة، هناك حاجة إلى معرفة CICS، ولكن هذا المطلب لم يعد ينطبق على جميع المطورين، ولكن على اثنين أو ثلاثة متخصصين مسؤولين عن بيئة تشغيل التطبيق.

إن "دمج" التقنيات والأدوات يعطي النتيجة المثالية؛ إن النظر إلى المنتجات الفردية خارج سياق تطبيق النظام لمطوري الحلول المعقدة غير المعبأة ليس له معنى كبير. وبنفس الطريقة، ليس من المفيد الحكم على نظام إدارة قواعد البيانات خارج إطار مشكلة التطبيق. لنفترض أنك من كبار المعجبين بشركة Oracle. ولكن ماذا لو كان العميل يحتاج إلى تطبيق لمنصة AS/400 المستهدفة؟ أو لديك حب كبير لـ DB2، ولكن نظام تطبيق العميل في S/390 يستخدم VSAM ويكون العميل راضيًا تمامًا، والأمر يتعلق فقط باستبدال الشاشة "الخضراء" بمتصفح ويب، بحيث، على سبيل المثال، فهو لا يظهر البيانات الأبجدية الرقمية فقط.

تنفيذ نظام OLTP لبنك Vneshtorgbank

لم يكن تعقيد هذا المشروع في حجم التعليمات البرمجية المكتوبة (تم توفير رمز منطق التطبيق من قبل العميل)، ولكن في معرفة العمق الفني لتشغيل الآليات المختلفة لأنظمة المعاملات. يتميز هذا المشروع بمجموعة واسعة من المنصات والتقنيات والمعرفة اللازمة لتشغيل الآليات المحددة اللازمة للتكامل مع بعض حزم التطبيقات الجاهزة.

يتم استخدام S/390 كعقدة مركزية لنظام OLTP؛ من الممكن استخدام مجموعة Sysplex. باعتبارها "آلة مصرفية"، يتم استخدام حزمة من Altel، يتم تنفيذها على أساس CICS TS، VSAM ولها واجهة "خضراء" بتنسيق 3270. بالإضافة إلى العقدة المركزية، يحتوي البنك على عشرات العقد الطرفية التي استخدم خوادم AS/400 وWindows NT (الشكل 5).

يتم تنفيذ تفاعل الخادم عبر MQSeries. من أجل عزل مطوري منطق التطبيق عن آليات استدعاء المعاملات من عمليات الخادم المكتوبة بلغة 4GL في VisualAge Generator، تم استخدام منهجية ومجموعة من البرامج (معاملات "التغليف")، والتي يمكنهم من خلالها الوصول إلى وظائف من 4GL. في محاولة لتوحيد واجهات الوصول إلى البيانات وتقليل تكاليف مكان العمل، طرح العميل متطلبًا لاستخدام واجهات الويب. في الوقت نفسه، لا ينبغي تنفيذ العمل من خلال متصفح الويب على أساس واحد لواحد، كما هو الحال من خلال 3270 محطة، ولكن من خلال صفحة HTML تم إنشاؤها بواسطة عدة شاشات 3270. وفي الوقت نفسه، كان من الضروري التأكد من ذلك التوافق مع نظام الأمان. كل هذا أدى إلى ظهور عدد من المشاكل التي كان لا بد من حلها ككل.

المشكلة رقم 1.لاستدعاء معاملة CICS التي تعمل على شاشة خضراء، يعمل بروتوكول واجهة العرض الخارجية (EPI) على مؤشر الترابط 3270. عند استدعاء مثل هذه المعاملة، يستخدم CICS جهازًا طرفيًا، وهو هيكل يحدد الاتصال وهو السمة الأساسية لـ الصفقة. وبالتالي، تحتوي هذه البنية على حقل TERMID (معرف المحطة الطرفية) المكون من أربعة أحرف، والذي تستخدمه المعاملات لنظام الأمان الخاص بها. يُسمى هذا النوع من الاتصال بالاتصال الطرفي في CICS.

ومع ذلك، فإن الاتصال الذي تم إنشاؤه لتشغيل متصفح الويب ليس طرفيًا، أي أنه لا يوجد مثل هذا الهيكل لهذا الاتصال (في فهم المعاملة 3270)، مما سيؤدي على الفور إلى فشل المعاملة.

لاستدعاء المعاملات 3270 من الاتصالات غير الطرفية أو من معاملات CICS الأخرى التي تم استدعاؤها عبر بروتوكول واجهة الاتصال الخارجية (ECI)، قام مراقب CICS لـ OS/390 بتطبيق آلية تسمى 3270 Bridge. تمت إضافة أمر EXEC CICS START BREXIT جديد وعندما يتم تنشيط المعاملة 3270 من خلال هذا الأمر، تقوم CICS بإنشاء بنية خاصة تسمى Bridge Facility، وهي ما يسمى بالمحطة البديلة، والتي يتم "تقديمها" للمعاملة 3270 في وقتها. التهيئة. ولكن عند إنشاء محطة بديلة، تقوم CICS بشكل مستقل بإنشاء معرف لحقل TERMID وفقًا لمنطقها الداخلي. لا علاقة لـ TERMID الذي تم إنشاؤه بمعرف اتصال المستخدم الفعلي. وهذا يؤدي إلى المشكلة رقم 2.

الأمر EXEC CICS START BREXIT غير مدعوم أيضًا بواسطة VisualAge Generator - لا يمكنك تعيين مثل هذه المعلمات بحيث تقوم بإنشاء أمر الاستدعاء، لأنه ظهر فقط في أحدث إصدارات CICS (بدءًا من الإصدار 1.3). لحل هذه المشكلة، تمت كتابة برنامج في Cobol يأخذ المعلمات اللازمة وينشط المعاملة من خلال هذا الأمر الجديد. هذا مثال على استخدام Cobol كلغة جيل ثالث لتنفيذ وظائف النظام الدقيقة. يمكن استدعاء برنامج Cobol من معاملات التطبيق المكتوبة بلغة 4GL في VisualAge Generator.

المشكلة رقم 2.لاستدعاء المعاملة 3270، يتم استخدام آلية Bridge 3270، والتي تقوم بإنشاء محطة بديلة. ولكن تتم تهيئة بعض الحقول، بما في ذلك TERMID، بواسطة CICS نفسها، دون ربطها بأي شكل من الأشكال باتصال العميل الذي يتم استدعاء هذه المعاملة منه. يقوم CICS، لكل مكالمة من هذا القبيل، بتعيين TERMID على قيمة من؟ (AAA؟ إلى؟ (999؟)، مما يزيده بالتسلسل. يستخدم استراتيجية أمان تعود إلى عصر ما قبل SQL - يتم تعيين كل عميل لتسجيل الدخول عبر VTAM (طريقة الوصول إلى الاتصالات الافتراضية) معرف مكون من ثمانية أحرف يسمى LU (الوحدة المنطقية)، والذي يتحقق من VTAM يتم أخذ الأحرف الأربعة الأخيرة من LU لإنشاء TERMID. تأخذ المعاملة المسؤولة عن تحديد المستخدم اسم المستخدم وكلمة المرور من لوحة المفاتيح، يأخذ TERMID ويبحث في ملفه الداخلي، حيث يبحث عن تطابق بين اسم المستخدم وTERMID، مما يضمن أن مستخدمًا معينًا يمكنه الوصول إلى النظام فقط من جهاز كمبيوتر معين، وذلك عند تكوين اتصال SNA ، يتم أيضًا تسجيل عنوان MAC الخاص ببطاقة شبكة الكمبيوتر العميل على جانب الخادم، لكن اتصالات الويب تعمل على تجاوز VTAM ولا تحتوي على جهاز طرفي أو شيء يحل محله لتقليل إعادة صياغة المعاملات.

تم حل هذه المشكلة من خلال الاستفادة من منطقة مستخدم جدول التحكم الطرفي (TCTUA)، ومعاملة مصادقة المستخدم الأساسية 3270 الخاصة بنا، وتهيئة TCTUA المكتوبة في VisualAge Generator. أدى هذا إلى التقليل من إعادة العمل في الصفقة، والتي تتلخص في استبدال كلمة "TERMID"؟ على ؟ TCTUA ؟ في النصوص "kobolny".

بالإضافة إلى ذلك، كانت هناك مشاكل في تنفيذ استدعاء لتسلسل من 3270 معاملة ضمن معاملة 4GL واحدة مع معالجة وسيطة للنتائج: كان من الضروري معالجة وتمرير المعلمات ("الشاشات") لكل مكالمة 3270.

نظام OLTP الموزع مع تكامل البرامج القديمة

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

تستخدم باناسونيك برنامج PSI لـ AS/400 وWindows NT. في الوقت نفسه، استخدم البرنامج في AS/400 جداوله الخاصة وجداوله من نظام J.D.ERP كهياكل بيانات. إدواردز يعمل على هذا الخادم. يقع خادم AS/400 في هلسنكي، بينما يقع خادم NT في موسكو وكييف، ولا يتم توصيلهما بخطوط موثوقة للغاية. وفي الوقت نفسه، يجب أن يضمن منطق برنامج PSI تسليم المعلومات إلى العقد من خلال خادم AS/400. يستخدم الإصدار الحالي آلية النسخ المتماثل لقاعدة البيانات، وهو أمر غير مقبول في ظروف خطوط الاتصال الضعيفة.

لحل هذه المشكلة، تم اقتراح نموذج لنظام النقل بين الخوادم على أساس MQSeries. ولم يتطلب ذلك تغيير كود تطبيق PSI الحالي، والذي كان مسؤولاً عن التفاعل مع المستخدم النهائي، ولكنه اقترح استخدام آليات تشغيل قاعدة البيانات. أي أنه تم "إرفاق" المشغلات بالجداول الضرورية، والتي لكل عملية (إدراج، حذف، تحرير) ترسل الرسائل المقابلة إلى نظام MQSeries. تم إرسال هذه الرسائل، مرة واحدة على AS/400، إلى كافة العقد الأخرى في النظام.

يدعم هذا الحل استخدام قواعد بيانات متعددة (في بيئة NT) والمكتبات (في بيئة AS/400) لتصحيح الأخطاء أو لأغراض أخرى. في الوقت نفسه، باستخدام أدوات مساعدة خاصة، يمكنك تحديد مكان ومكان نقل البيانات الخاصة بجدول معين. يتم تحديد مجموعة وبنية الجداول في قاعدة البيانات بشكل صارم. لتنفيذ هذا المشروع، تم إشراك كل من MQSeries وVisualAge Generator، بالإضافة إلى برمجة C++. على NT، تم تنفيذ مشغلات MQSeries كخدمات NT، وعلى AS/400، تم تنفيذ مشغلات DB2.

في هذا المشروع، في المرحلة الأولى، قامت كل عملية في قاعدة البيانات بإنشاء رسالة واحدة مع رمز العملية المقابل (I - إدراج، D - حذف، U - تحديث)، والذي تم فك تشفيره في العقد البعيدة. ولكن في الواقع اتضح أن برنامج PSI يغير المجالات الرئيسية، وهو أمر غير مستحسن بشكل عام. وهذا يجعل من المستحيل إجراء عملية U ("التغيير") على العقدة البعيدة، نظرًا لأن السجل الذي يحتوي على حقل المفتاح الذي تم تغييره لا يوجد بعد هناك ولا يمكن لنظام إدارة قواعد البيانات العثور عليه. لم يكن من الممكن إدراج حقول المفاتيح الخاصة بك في بنية الجدول، حيث تم استخدام جداول تطبيق J.D. إدواردز، الذي لا يمكن تغيير هيكله. بعد تحليل الموقف، من أجل حل المشكلة بأقل قدر من إعادة العمل، تم اقتراح أنه بدلاً من رسالة واحدة تحتوي على الرمز U، بدأ المشغل المقابل في إرسال زوج من الرسائل: الأولى - مع الرمز D ("حذف") و قيمة المفتاح القديم؛ الثاني - بالرمز I ("إدراج") وقيمة مفتاح جديدة.

يقوم هذا النظام بتمرير حوالي 60 ألف رسالة يومياً بمتوسط ​​طول يبلغ حوالي 2 كيلو بايت. تم الانتهاء من المشروع في 8 أسابيع بواسطة 4 مهندسين.

الأدب

ماساهارو موروزومي، تحدي لحجم المعاملات الكبير لنظام OLTP المشترك لبيانات العميل/الخادم DB2. آي بي إم، 2000

G. Ladyzhensky، تكنولوجيا خادم العميل ومراقبة المعاملات. "الأنظمة المفتوحة"، 1994، العدد 3

M. Ruzinkevich, A. Tsikocki، تعريف وتنفيذ تدفقات المعاملات. "نظام إدارة قواعد البيانات"، 1995، العدد 2

E. كوب، ج. هاميلتون، ج. شارمان، هل أحتاج إلى مراقبة معالجة المعاملات وقاعدة بيانات؟ آي بي إم، 1996

نيكولاي إجناتوفيتش، IBM MQSeries: بنية نظام قائمة انتظار الرسائل. "الأنظمة المفتوحة"، 1999، العدد 9-10

نيكولاي إجناتوفيتش، تكامل تقنيات إدارة البيانات في DB2. "الأنظمة المفتوحة"، 2001، العدد 7-8

P. Wakelin، S. Day، S. Read، F. McKenna، CICS Transaction Gateway V3.1. موصل WebSphere لـ CICS. SG24-6133-00، آي بي إم، 2001

ايليا أفاناسييف ( [البريد الإلكتروني محمي]) - المدير العام لشركة الإمبراطورية الرقمية (موسكو).

الأنواع الرئيسية للوسيطة

• مراقبة معالجة المعاملات الموزعةمراقبة تنفيذ تدفق المعاملات المكثف في أنظمة معالجة المعاملات عبر الإنترنت في بيئة متعددة المنصات.
• استدعاء الإجراء عن بعد (RPC).مزامنة العلاقة بين العمليات عن طريق الاتصال بها عن بعد. المعاملات غير مدعومة.
• الاتصال بقاعدة البيانات.يمكن معالجة استعلام SQL المرسل عبر هذا البرنامج بواسطة العديد من أنظمة إدارة قواعد البيانات (DBMS) من شركات مصنعة مختلفة.
• وسيط طلب الكائنات (ORB).تبادل كائنات البرامج بين منصات مختلفة وعبر بروتوكولات مختلفة.

جميع أنواع البرامج الوسيطة المذكورة أعلاه تدعم فقط الاتصالات المتزامنة؛ في حالة فقدان الاتصال، تتوقف العملية ولا يتم استئنافها تلقائيًا.

البرمجيات الوسيطة التي تعتمد على تمرير الرسائل (البرمجيات الوسيطة الموجهة للرسائل - MOM). مراسلة غير متزامنة بين التطبيقات التي يمكن تشغيلها على منصات مختلفة. تتم عمليات الاستبدال مع ضمان التسليم؛ في حالة فقدان الاتصال، سيتم استئناف العملية تلقائيًا بعد الاسترداد.

مقارنة النماذج المقيسة وغير المقيسة

تحليل معايير نماذج البيانات المقيسة وغير المقيسة

دعونا نجمع نتائج تحليل المعايير التي أردنا من خلالها تقييم تأثير نمذجة البيانات المنطقية على جودة نماذج البيانات المادية وأداء قاعدة البيانات:

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

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

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

من الممكن تحديد فئات معينة من الأنظمة التي تكون نماذج البيانات المقيسة بقوة أو ضعيفة أكثر ملاءمة لها.

تعد نماذج البيانات عالية التطبيع مناسبة تمامًا لما يسمى تطبيقات OLTP (معالجة المعاملات عبر الإنترنت (OLTP )- معالجة المعاملات السريعة ). الأمثلة النموذجية لتطبيقات OLTP هي أنظمة محاسبة المستودعات، وأنظمة طلب التذاكر، والأنظمة المصرفية التي تقوم بعمليات تحويل الأموال، وما إلى ذلك. وتتمثل المهمة الرئيسية لهذه الأنظمة في تنفيذ عدد كبير من المعاملات القصيرة. تبدو المعاملات نفسها بسيطة نسبيًا، على سبيل المثال، "سحب مبلغ من المال من الحساب أ، وإضافة هذا المبلغ إلى الحساب ب". تكمن المشكلة في أنه أولاً، هناك الكثير من المعاملات، وثانيًا، يتم تنفيذها في وقت واحد (يمكن توصيل عدة آلاف من المستخدمين المتزامنين بالنظام)، وثالثًا، في حالة حدوث خطأ، يجب التراجع عن المعاملة بالكامل وإرجاع النظام إلى الحالة التي كانت قبل بدء المعاملة (لا ينبغي أن يكون هناك موقف يتم فيه سحب الأموال من الحساب أ، ولكن لم تصل إلى الحساب ب). تتكون جميع استعلامات قاعدة البيانات تقريبًا في تطبيقات OLTP من أوامر الإدراج والتحديث والحذف. تم تصميم استعلامات التحديد في المقام الأول للسماح للمستخدمين بالاختيار من الدلائل المختلفة. وبالتالي فإن معظم الطلبات تكون معروفة مسبقًا في مرحلة تصميم النظام. لذلك، تعد سرعة وموثوقية عمليات تحديث البيانات القصيرة أمرًا بالغ الأهمية لتطبيقات OLTP. كلما ارتفع مستوى تسوية البيانات في تطبيق OLTP، أصبح أسرع وأكثر موثوقية. يمكن أن تحدث الانحرافات عن هذه القاعدة عندما تكون بعض الاستعلامات التي تحدث بشكل متكرر معروفة، في مرحلة التطوير بالفعل، والتي تتطلب علاقات متصلة وتؤثر سرعة تنفيذها بشكل كبير على تشغيل التطبيقات. في هذه الحالة، يمكنك التضحية بالتطبيع لتسريع تنفيذ مثل هذه الاستعلامات.

نوع آخر من التطبيقات هو ما يسمى تطبيقات أولاب (المعالجة التحليلية عبر الإنترنت (OLAP ) - معالجة البيانات التحليلية التشغيلية ). هذا مصطلح عام يميز مبادئ البناء أنظمة دعم القرار (نظام دعم القرار - مفاجآت صيف دبي ), مستودعات البيانات (مستودع البيانات ), أنظمة استخراج البيانات (بيانات التعدين ). تم تصميم هذه الأنظمة للعثور على التبعيات بين البيانات (على سبيل المثال، يمكنك محاولة تحديد مدى ارتباط حجم مبيعات البضائع بخصائص المشترين المحتملين)، لإجراء تحليل "ماذا لو ...". تعمل تطبيقات OLAP على كميات كبيرة من البيانات المتراكمة بالفعل في تطبيقات OLTP، المأخوذة من جداول البيانات أو مصادر البيانات الأخرى. وتتميز هذه الأنظمة بالميزات التالية:

• نادرًا ما تتم إضافة بيانات جديدة إلى النظام في كتل كبيرة (على سبيل المثال، بمجرد تنزيل بيانات ربع سنوية بناءً على نتائج المبيعات ربع السنوية من تطبيق OLTP).
• عادةً لا يتم حذف البيانات المضافة إلى النظام أبدًا.
• قبل التحميل، تخضع البيانات لإجراءات "تنظيف" مختلفة، وذلك نظرًا لحقيقة أن نظامًا واحدًا يمكنه تلقي البيانات من العديد من المصادر التي لها تنسيقات عرض مختلفة لنفس المفاهيم، وقد تكون البيانات غير صحيحة أو خاطئة.
• الاستعلامات الموجهة إلى النظام غير منظمة، وعادة ما تكون معقدة للغاية. في كثير من الأحيان، يقوم المحلل بصياغة استعلام جديد لتوضيح النتيجة التي تم الحصول عليها من استعلام سابق.
• تعد سرعة تنفيذ الاستعلام أمرًا مهمًا، ولكنها ليست حاسمة.

عادةً ما يتم تمثيل البيانات من تطبيقات OLAP كمكعب واحد أو أكثر، تكون أبعادها بيانات مرجعية، وتقوم خلايا المكعب الفائق نفسه بتخزين البيانات الفعلية. على سبيل المثال، يمكنك إنشاء مكعب فائق، أبعاده هي: الوقت (بالأرباع، السنوات)، نوع المنتج وفروع الشركة، وحجم مبيعات متجر الخلايا. سيحتوي هذا المكعب الفائق على بيانات عن مبيعات أنواع مختلفة من البضائع حسب الربع والقسمة. بناءً على هذه البيانات، يمكنك الإجابة على أسئلة مثل "ما هو القسم الذي حقق أفضل حجم مبيعات هذا العام؟"، أو "كيف هي اتجاهات مبيعات أقسام المنطقة الجنوبية الغربية هذا العام مقارنة بالعام السابق؟"

ماديًا، يمكن بناء المكعب الفائق بناءً على خاص نموذج بيانات متعدد الأبعاد (مولاب - OLAP متعدد الأبعاد ) أو تم إنشاؤها باستخدام نموذج البيانات العلائقية ( رولاب - OLAP العلائقية ).

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

معالجة المعاملات عبر الإنترنت تم تصميم OLTP لخدمة الطلبات البسيطة نسبيًا من عدد كبير من المستخدمين بسرعة. تتطلب هذه الأنظمة الحماية من الوصول غير المصرح به، وسلامة البيانات، وفشل الأجهزة والبرمجة.

وتتميز بأوقات انتظار منخفضة لاستكمال الطلبات.

نطاق التطبيق: المدفوعات والمحاسبة والحجوزات والبنوك وعمليات البورصة

عملية- هذا هو بعض الإجراءات المكتملة على قاعدة البيانات من وجهة نظر المستخدم.

أنظمة معالجة البيانات التحليلية (معالجة التحليل عبر الإنترنت) OLAP هي أنظمة دعم القرار التي تركز على تنفيذ استعلامات أكثر تعقيدًا تتطلب معالجة إحصائية للبيانات التاريخية المتراكمة خلال فترة زمنية معينة. تشمل الأنظمة التحليلية ما يلي:

1. أدوات معالجة المعلومات المعتمدة على أساليب الذكاء الاصطناعي

2. وسائل العرض الرسومي للبيانات.

ويتم تحديد هذه الأنظمة من خلال حجم كبير من البيانات التاريخية، مما يسمح باستخلاص معلومات ذات معنى منها، أي: اكتساب المعرفة من البيانات.

أدت متطلبات سرعة وجودة التحليل إلى ظهور أنظمة المعالجة التحليلية (OLAP). يتم تحقيق كفاءة المعالجة من خلال استخدام تقنية المعالجات المتعددة القوية وطرق التحليل المعقدة ومستودعات البيانات المتخصصة.

تعتمد فئات الأنظمة المحددة (OLAP وOLTP) على استخدام نظام إدارة قواعد البيانات (DBMS)، لكن أنواع الاستعلامات مختلفة تمامًا.

معالجة المعاملات في أنظمة OLTP

عملية -تسلسل غير قابل للتجزئة لعمليات معالجة البيانات من منظور التأثير على قاعدة البيانات. يمكن أن تكون هذه عملية قراءة أو حذف أو إدراج أو ما إلى ذلك.

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

يجب أن تحتوي المعاملة على 4 خصائص أساسية:

1. الذرية،يجب تنفيذ المعاملة كعملية وصول واحدة لقاعدة البيانات، ويجب إكمالها بالكامل أو عدم تنفيذها على الإطلاق.

2. الاتساق، يضمن سلامة البيانات المتبادلة.

3. العزلةسيتم تنفيذ المعاملات بشكل منفصل على نظام المستخدم.

4. المتانة، إذا اكتملت المعاملة بنجاح، فلن يتم فقدان التغييرات التي تجريها على البيانات تحت أي ظرف من الظروف.

نتيجة الصفقة يمكن أن تكون لها تثبيتو التراجع

تثبيت - وهذا الإجراء يضمن تسجيل كافة التغييرات في قاعدة البيانات.

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

عند التراجع عن المعاملة وتنفيذها، استخدم سجل المعاملات,حيث يتم حفظ كافة التغييرات.

عند إجراء أي عملية تؤدي إلى تغيير قاعدة البيانات، يقوم نظام إدارة قواعد البيانات تلقائيًا بحفظ حالات الصفوف المعدلة قبل العملية وبعدها في سجل المعاملات. فقط بعد ذلك يتم إجراء التغييرات على قاعدة البيانات.

عند التراجع، يستخدم نظام إدارة قواعد البيانات سجل المعاملات لاستعادة تلك الصفوف التي تم تعديلها.

حدود المعاملات- هذه هي العملية الأولى والأخيرة المضمنة فيه. من المفترض أن تبدأ المعاملة ببيان SQL الأول، وتشكل العبارات التالية نص المعاملة ويمكن أن يتفرع النص:

1. بيان SQL يلتزم بالعمل

عامل التراجع SQL

2. ببساطة عن طريق استكمال البيان الذي دعا إلى المعاملة.

حفظ النقاط- تستخدم في المعاملات الطويلة، أي. يمكن لنص المعاملة تحديد النقاط التي يتم حفظ حالة قاعدة البيانات فيها.

يعد استخدام المعاملة آلية فعالة لتنظيم وصول المستخدمين المتعددين إلى قاعدة البيانات.

مشاكل:

1. كيفية تجنب فقدان التغييرات في قاعدة البيانات في حالة قيام عدة برامج بقراءة نفس البيانات وتغييرها وكتابتها في نفس المكان. يمكن حفظ التغييرات من برنامج واحد في قاعدة البيانات، وسيتم فقدان نتائج جميع البرامج الأخرى.

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

للتخلص من ذلك، استخدم التسلسل (المعالجة المشتركة):

1. لا يمكن للمعاملة الوصول إلى البيانات غير الملتزم بها

2. يجب أن تكون نتيجة التنفيذ المشترك للمعاملات معادلة لنتيجة تسلسل تنفيذها.

في نظام إدارة قواعد البيانات الحديث، يتم تنفيذ تسلسل المعاملات من خلال آلية تأمين:أثناء تنفيذ المعاملة 1، يقوم نظام إدارة قواعد البيانات (DBMS) بحظر جزء قاعدة البيانات الذي تصل إليه المعاملة 1. يتم الحفاظ على القفل حتى يتم تنفيذ المعاملة 1؛ إذا وصلت معاملة أخرى 2 في هذه اللحظة إلى البيانات المقفلة، فسيتم تعليق المعاملة 2 حتى اكتمال المعاملة 1.

الجمود الصفقة

السماح للمعاملة t1 بتحديث العلاقة - o1. بعد ذلك، تحاول هذه المعاملة t1 تعديل العلاقة o2، والتي تم حظرها مسبقًا بواسطة المعاملة t2. يتم نقل المعاملة t1 إلى حالة الانتظار حتى يتم تحرير القفل الموجود على العلاقة o2؛ وفي نفس اللحظة، تحاول المعاملة t2 تغيير بيانات العلاقة o1، والتي تم حظرها مسبقًا بواسطة المعاملة t1. يضطر نظام إدارة قواعد البيانات (DBMS) إلى وضع المعاملة T2 في حالة انتظار، وبالتالي تنشأ حالة توقف تام للمعاملة.

يقوم نظام إدارة قواعد البيانات (DBMS) بفحص القفل بشكل دوري وإذا كان هناك حالة توقف تام، فسيتم إحباط إحدى المعاملات بالقوة.

أدوات التعافي من الكوارث

أحد المتطلبات الرئيسية لأنظمة المعلومات الحديثة هو موثوقية تخزين البيانات. يجب أن يكون نظام إدارة قواعد البيانات (DBMS) قادرًا على استعادة قاعدة البيانات بعد أي فشل في الأجهزة أو البرامج. هناك سجل المعاملات لهذا الغرض. مبدأ الاسترداد - يجب استعادة نتائج المعاملة قبل الفشل، ويجب حذف النتائج التي لم تلتزم بها المعاملة.

إذا تم إتلاف محتويات الذاكرة الخارجية فعليًا، فسيتم تنفيذ تخزين البيانات المكررة للتخلص من ذلك.