ixWEB
مايو
1
2013

أساسيات تصميم تطبيقات قواعد البيانات

عملية تصميم وتطوير تطبيقات قواعد بيانات أوراكل او كما يطلق عليها المطورون (تصميم النظام) عملية معقده وليست بالبساطه التى يمكن حصرها فى انشاء الجداول وتشغيل معالج انشاء الفورمات والتقارير بل يمتد لابعد من ذلك كثيرا فيجب للمطور الإلمام بكل التفاصيل التى يحتاجها تطبيقه بداً من فهم وتحليل المطلوب واختيار افضل الطرق لتنفيذه , الموضوع لايركز على اساسيات تحليل النظم بل على الناحية البرمجية للتطبيقات, اى على المستوى المعرفى بأدوات أوراكل التى يجب على مطور التطبيقات معرفتها لاختيار , فقاعدة بيانات أوراكل تتيح العديد من الأدوات التى يمكن ان تؤدى عدة اغراض افضل من الاخرى , فمثلا بدون معرفة الفرق بين الجدول العادى Table وال View و ال Materialized View  سيكون التطبيق حتما غير مكتمل الجوانب وربما سيعانى من مشكلات حقيقية فى التصميم تؤدى لمشكلات اكبر فى عمله من ناحية availability  وربما يؤثر على قاعدة البيانات ككل , فالمطور يجب ان ياخذ فى الاعتبار متى يحفظ البيانات فى جدول عادى او جدول عشوائى ومتى يستخدم external tables كما يجب عليه كيف يتوجب عليه القراءة من وحدة ال DUAL والتى يستخدمها المطورون بكثرة دون مراعاة لسرعة التطبيق ودون محاولة استخدام شغرات ال pause والتى تتيح ازالة الضغط على قاعدة البيانات وزيادة لسرعة التطبيق وغيرها , ساتحدث بايجاز عن بعض النقاط التى يجب لمطورى تطبيقات قواعد البيانات مراعاتها بشده وقبل كل شيى يجب على كطور التطبيقات الإلمام بكل الادوات التى تساعده فى عمله متوفرة داخل الاوراكل امثال Tables وال indexes و Views وال synonym و snapshot وغيرها , دعونا ندخل للموضوع :

فورم 11جى

نقطه اولى :  حسب احصائيا اوراكل فأن 50% من مشاكل سرعة واستقرار التطبيقات تعتمد أساساُ على اخطاء فى تصميم التطبيق واستخدام ادوات بدلا عن ادوات بعينها مثلا كأستخدام جدول بدلا عن View او جعل التقرير يقوم بعمليات تجكيع مجهدة لقاعدة البيانات كل مره بدلا من تجهيز البيانات التى يحتاجها التقرير فى جدول واحد بقدر الإمكان على ان تتم ذلك فى كرحلة تصميم التطبيق.

بعض أساسيات تصميم تطبيقات قواعد البيانات :

 1- مستخدمى ومدخلى بيانات تطبيقات قواعد البيانات لايهمهم مالذى تحتويه التفاصيل الداخلية للبرنامج مقارنة بسرعة استجابة التطبيق وسهولة استخدامه مع الوضع فى العتيار بتغطية التطبيق لأحتياجات العمل , فلايجب عند البدء فى تصميم البرنامج وضع كل الاهتمام على النظريات البرمجية واغفال الجانب الذى يخص سهولة تعامل المستخدم مع التطبيق من كافة النواحى فيجب تبسيط التصميم لأقصى مايمكن , فمثلا فى الانظمة المالية يمكننا اخذ ادخال تفاصيل عنصر لفاتوره فالعملية ربما تقوم بعملية بحث عن بيانات اوتفاصيل بجدول اخر كما يمكن ان تقوم باكثر من عملية ادخال فى عدة مواقع , هذا على نطاق المستخدم الواحد ربما يكون ليس ذى شأن فى بال مطور التطبيق , لكن يجب عليه اعطاءه اشد الانتباه فى حالة ان الادخال يتم باكثر من مستخدم واحد فسيسبب هذا مشكلات ضخمة للتطبيق وسيدخله فى حلفة مغلقة من عمليات ال Locks وايقاف المستخدمين والتطبيق احيانا , هنا وجب تغيير التصميم واستخدام ادوات ال Materialize views وغيرها لدورها الفعال فى حل هذه المشكلات .

2- الغاء وتقليل مناداة البيانات من اوراكل , المعروف انه عند عمل اى اجراء على جهاز الكمبيوتر فان المعالج يقوم بعمل معين لتنفيذ الاجراء والوصول للبيانات على القرص هذه العملية نطلق عليها Physical reads وعى عملية مجهدة جدا ويجب تجنبها متى ماسنح ذلك , دعنا ننظر للمثال التالى : سافترض ان مصمم نطبيقات قاعدة بيانات يقوم بالقراءة من جدول dual مثلا قيمة الوقت عدة مرات دون الوضع الاعتبار ان هذا الجدول بالذات ليس جدولا عاديا بل oracle internal table , فاذا قمت مثلا بقراءة الزمن من هذا الجدول فاعلم ان بيانات هذا الجدول يتغير 86,400 مره فى اليوم وهذا المصمم قام باستدعاء بيانات عدة مرات داحل تطبيقه من داخل هذا الجدول وتطبيقه هذا يستخدمه  50 مستخدم فتخيل عدد مرات ال physical read التى ستتم وكما سبق وذكرت ان هذا الجدول ليس جدول قواعد بيانات لنقول انها Logical reads بل physical reads  ففى هذه الحالات يمكن لمطور التطبيق استعمال sleep على مستوى نظام التشغيل باستخدامه لحزمة DBMS_LOCK.SLEEP() عن طريق plsql حتى يجنب قاعدة البيانات اى اعمال لاتحتاج اليها فعلاً هذا بعض تحسين عملية الوصول لهذه البيانات.

3- تجنب تكرار تنفيذ العمليات التى قمت بتنفيذها مسبقاً بقدر الإمكان , على المصمم فهم اهمية استعمال ال procedures ومخرجاتها واهمية نخزين النتائج التى يحتاجها المستخدمون بكثره فى التطبيق بدلاء عن اجراء نفس عمليات ال sort و ال group كل مره , فاحيانا تجد ببعض التطبيقات غير ذات التصميم الجيد ان المطور يقوم بعمل اجراء اكثر من مره للحصول على نفس النتيجه على الرغم من امكانية الوصول للبيانات السابقة والتى لم يحدث تغيير بها بقاعدة البيانات , فمثلا عند بناء procedures استخدم القيم التى لاتتغير او الثابته كثوابت فى إجراء ولاتقم بتخزينها فى قاعدة البيانات , لانك بذلك تقوم بعدة عمليات للاشيء , مجموعة physical reads و waitings ربما تنفذ من قبل 30 مستخدم !!!! تخيل أنه يمكنك الاستغناء ببساطه عن كل هذا .

4- فى تصميم التقارير قم بتخزين البيانات التى تحتاجها التقارير فى جدول لتكون جاهزة مسبقاً, تعطى الاولوية دائما للسرعة مقارنة بالمساحة , فمثلا تخيل اننا نريد عمل تقرير يعتمد على براميتر, فعكس مايتخيله معظم مطورى التطبيقات يفضل تماما تجهيز هذه البيانات على الجدول مباشرة ومناداتها بدون باراميتر افضل من اجراء عملية الفلتر Select اثناء تشغيل التقرير والفارق سيكون ضخم جدا وسيلاخظه المستخدم العادى بسهولة جدا فى سرعة التطبيق وقلة الجراء الذى ستقوم قاعدة البيانات بعمله فهى فقط ستقوم بعمل تحديث refresh لل materialized View  او الجدول .

5- لاتقم بالاتصال يقاعدة البيانت باكثر من مره , عادة عملية الاتصال بقاعدة البيانات تاخذ وقت اكثر من مجرد ال Connect الذى يعلمها المطور فيجب على المطور معرفة كيفية عمل Reuse لل Connection وبالمقابل ترك الاتصال مفتوحا داخل التطبيق.

6- ضرورة استخدام ال indexes وعدم الاكثار فيها ,  معروف لتاثير المباشر لل indexes على سرعة تطبيقات قواعد البيانات فعملية الوصول لسجل على جدول يحتوى مليون سجل من دون index بمكن ان تاخذ 15 ثانية بالاضافة للتاثير السيىء جدا على التطبيق وقاعدة البيانات ككل لكن فى ظل وجود index يمكن لهذه العملية ان تاخذ فقط 3 ثوان !!!! ومااسهل من انشاء index , لكن بالمقابل يجب عدم الاكثار من اسنخدام ال Index او عدم استخدامه فى مكان غير مكانه الحقيقى , كمثال لايجب اسنخدام ال Bitmap Index  مع تطبيقات ال OLTP .

7- تجنب تجنب تجنب عمليات ال sort الغير ضرورية متمثلة فى Order by , مثلا تخيل جدول ضخم من غير index والمصمم يريد اجراء عملية Sort لحقل معين فسيتم اجراء عملية محده يتم فيها عمل scan لكل الجدول ومن ثم يقوم بعمل sort للناتج !!! وعملية ال sort تنفذ معها عملية select لكل البيانات الوجوده بالجدول ككل ونقلها الى خارج ال data file لاجاء العملية , وكامتداد لهذه العملية تجنب استعمال Union  واستعمل Union all نسبة لان union تقوم بعمل Sort ايضا وليس Union all .

8- استخدم ال Partitioning , كمطور تطبيقات يجب عليك استعمال   Partitioning  مع الجداول الكبيره لأثر ذلك فى تسريع التطبيق وتخفيف الضغط على قاعدة البيانات .

9- قم باستعمال ال Materialized View لتقسيم وتصنيف الاجراءات التى يحتاجها المستخدم من الجداول , فعند استخدام ال Materialized view يقوم الاوراكل بعمل نسختين من البيانات نسخة تتاح عند ادخال بيانات جديده ونسخة اخرى تخصص لعمليات ال Query وغيرها بالاضافة لأمكانية ضم الجداول وانشاء جداول حسب query معين مما يسهل ويقلل الوقت الذى سيحتاجه التطبيق لتوفير البيانات .

10- اختبر التطبيق مع كمية ضخمة من البيانات وعدد كبير من المستخدمين لان فى هذه الحالة فقط ستخرج بنتائج صحيحة , لان تجربة النظام مع مستخدم واحد لايعطى النتائج المرجوة والمتعلقة بجوانب السرعة واستقرار التطبيق .

11- الاستخدام الصحيح لل Data types , فلا يجب استخدام ال Varchar2 مع بيانات ثابته مثلا مفاتيح الدول ةالتى ستتكون فقط من حرفين يمكن استعمال النوع char بطول 2 , وكمثال اخر وظائف استعمال raw و BLOB واماكن استعمال كل واحده منهما .

يتبع الجزء الثانى ….

2 تعليقان »

خلاصة تعليقات التدوينة - رابط التعقيب


رد

mojtabanow.info : موقع متخصص فى تقنية المعلومات, أوراكل , لينكس , أمن المعلومات تستخدم Wordpress - القالب من تصميم TheBuckmaker.com - تعريب الإعصار الأحمر