شرکت طراحي سايت بهپردازان

كليه حقوق اين سايت مربوط به شرکت نرم افزاري بهپردازان - شركت طراحي سايت بهپردازان مي باشد

                  

 

 

 

دانشگاه

 

دانشکده

 

گروه

 

 

مدیریت پایگاه داده

 

پروژه ی درس

 

رشته ی

 

توسط:

 

 

استاد مربوطه:

 

 

 

 

 

 

 

 

 

 

 

 

آبان 1391
فهرست

مقدمه :.. 4

داده، پايگاه داده و امنيت آن.. 5

امنيت پايگاه داده:.. 6

ANSI/SPARC.. 11

سطح خارجی.. 12

سطح ادراکی.. 12

سطح داخلی.. 13

تبديلات بين سطوح.. 14

استقلال داده.. 14

زبان ميزبان و زبان فرعي داده.. 15

زبان دستکاری داده.. 16

زبان کنترل داده.. 16

کاربران پایگاه داده.. 16

ديکشنری داده.. 18

Data modeling. 18

عناصر مدل داده.. 19

ساختمان های داده.. 19

جامعیت.. 19

عملیات.. 19

انواع مدل های داده.. 20

مدل سلسله مراتبی.. 20

مدل شبکه ای.. 22

پايگاه داده XML. 23

معماري امن شبکه با نگاه به پايگاه داده.. 24

قرار ندادن پايگاه داده در DMZ:.. 24

رمز نگاري اطلاعات مابين سرور وب و سرور پايگاه داده:.. 27

اوراکل نرم‌افزار بانک اطلاعاتي.. 29

راهكارهايي براي‌ افزايش سرعت در بانك‌هاي اطلاعاتي SQL Server 30

بانك‌هاي اطلاعاتي بسيار بزرگ، دي‌بي2 يا آداباس.. 39

Oracle آسيب پذير تر از SQL Server 42

مروری بر ویژگی های نسخه 5.0.1 بانک اطلاعاتی MySQL.. 43

مراجع و منابع.. 47

 

 

 

 

 


مقدمه :

داده هاي موجود در يك شبكه، سازمان و يا هر ارگان، ثروت اصلي آن مجموعه به حساب مي آيند و اساساً كليه منابع انساني و تجهيزات و منابع مادي بطور زنجيروار سعي در نگهداري، حفظ، انتقال امن، سطح دسترسي مطلوب و درنهايت كاربري مفيد آن دارند.

به طور كلي گستره وسيعي از اطلاعات شامل داده هاي آموزشي، مديريتي، پژوهشي، مالي، اداري و پرسنلي در شبكه علمي كشور در مجموعه كلي داده ها جاي دارند. از طرفي رشد روزافزون داده ها باعث مي شود حجم و نوع داده هاي اندوخته شده و حساسيت آنها تغيير نمايد و كليه موارد فوق سبب مي شود تا صاحبان و مديران شبكه درخصوص تهاجم و استفاده غيرمجاز بعضي كاربران (خرابكاران) چاره انديشي نمايند.

باتوجه به گسترش شبكه ها، خصوصاً شبكه علمي كشور و توزيع داده ها در سطح اين شبكه، مسائل مربوط به حفظ امنيت و تأمين حفاظت داده ها از اهميت خاصي برخوردار خواهد بود و به عبارتي مي توان گفت كليه منابع دست اندركار حفظ و تأمين داده هاي موجود خواهند شد.

با گسترش استفاده از تکنولوژي وب و توسعه برنامه هايي که براي کارکرد درين بستر توليد ميشوند مباحث مربوط به امنيت پايگاههاي داده اي بعد جديدتري پيدا کرده اند. هر چند از آغاز پيداش پايگاههاي داده همواره امنيت و تامين آن يک دغدغه مهم و پياده سازي مناسب  و کاراي آن يک خصوصيت بنيادي در پايگاههاي داده بوده است اما بهر روي بحث امنيت (Security)همواره در سايه مقولاتي همچون عملکرد مناسب (Functionality) ، کارايي (Performance) و قابليت اطمينان (Reliability) قرار ميگرفت. به عبارتي هنوز هم چندان عجيب نيست اگر ببينيم يک برنامه رده سازماني (Enterprise Level) با تعداد زيادي Client بدون هيچگونه ملاحظه امنيتي توليد شده و مورد استفاده باشد. حتي ميتوان درين زمينه مثالهاي جالبتري يافت. اغلب برنامه هاي Client-Server با نام کاربري  sa(System Administrator) به پايگاههاي داده متصل ميشوند. از ديد امنيتي اين مطلب يک فاجعه محسوب ميشود. هيچ تغيير و يا خرابکاري اي قابل رديابي نيست، همه کاربران به همه اطلاعات دسترسي دارند و الي آخر.

آنچه ذکر شد ، در واقع تصويري از وضعيت جاري بود، که بايد از دو منظر نگريسته شود: عدم وجود مکانيزمهاي امنيتي مناسب و نيز در صورت وجود چنين مکانيزمهايي عدم بهره گيري صحيح ازانها يا نداشتن سياست امنيتي مطلوب.

 

 

اين وضعيت شايد در دنياي برنامه هاي مبتني بر تکنولوژي هاي Mainframe يا Client-Server قابل تحمل بود اما در شرايط فعلي که برنامه ها با سرعت زيادي به سمت بهره گيري از بستر وب ميروند ادامه اين روند فاجعه بار است. در حال حاضر ديگر کاربران يک برنامه به صورت بالقوه تنها کارمندان يک سازمان نيستند. هر فردي ميتواند به سادگي باز کردن يک مرورگر وب به پايگاه داده شما متصل شود و مطمئن باشيد اگر مکانيزمهاي امنيتي را رعايت نکرده باشيد ، حذف تمامي داده هاي شما حتس از عهده يک نفوذگر عادي هم بر مي آيد.

اجازه دهيد يک فرض اساسي را مطرح کنيم. مديران IT يک سازمان بر دو دسته اند: مديران نوگرايي که به صورت داوطلبانه سازمان را به سمت ارائه خدمات عمومي و گسترده هدايت ميکنند و به همين دليل تکنولوژي وب را به عنوان تنها بستر موجود براي ارائه اين خدمات ميپذيرند و مديران سنتي محافظه کاري که قابليت اطمينان و کارايي سيستم جاري را تحت هيچ شرايطي حاضر نيستند در معرض خطر قرار دهند. وب از نظر اين گروه دوم کماکان يک تکنولوژي مشکوک غير قابل اطمينان است. در واقع دلايل فني اين گروه دوم هنوز هم چشمگير و قابل اعتناست، به خصوص گروهي که از mainframe ها صحبت ميکنند. قابليت اطمينان 0.99999 هنوز هم در دنياي غير Mainframe  يک روياست. 

 

زماني که بحث امنيت در بستر وب مطرح ميشود به صورت عمده سه جزء زير مد نظر است:

در ادامه نگاهي به جزئيات هريک از اجزاي اين دسته بندي خواهيم داشت.

شايد بخش عمده امنيت سرور مربوط به مدير شبکه و نيز کارشناس امنيت اطلاعات باشد. ازين نظر DBA مسئوليت چنداني ندارد ، البته اين به شرطي ست که قبلا متخصص امنيت شبکه مکانيزمهاي امنيتي مناسب را جهت سرور پيش بيني کرده باشد. اين مکانيزمها محدوده وسيعي از ابزارها و راه حلهاي امنيتي را در بر ميگيرد: فايروالها ، تشخيصگرهاي نفوذ (Intrusion Detectors) ، ضد ويروسها ، ... از جمله ابزارها هستند . معماري امن شبکه و لحاظ کردن مسائل امنيتي درين معماري نيز ميتواند حائز اهميت باشد.

داده، پايگاه داده و امنيت آن

 

كليه اطلاعاتي كه از حالت خام خارج شده و حاوي مطالب مهم و پخته شده به منظور استفاده از انواع مختلف مي باشد را داده نامند و اين داده ها حاصل برنامه هاي مختلف است كه در سطح شبكه علمي كشور به كار گرفته مي شوند تا كليه كاربران به فراخور حال و موقعيت خاص از آنها بهره برداري نمايند.

 

در ادامه مطالب در بخشهاي بعدي مباحث مطروحه درخصوص امنيت داده خواهد بود لذا در اين بخش مسائل مربوط به پايگاه داده به طور خلاصه بررسي خواهد شد و در ادامه اين بخش صرفاً به مسائل امنيت داده مي پردازيم.

 

 امنيت پايگاه داده:

 

امنيت پايگاه داده، به مجموعه سياستها و مكانيزمهايي گفته مي شود كه سه بعد مهم امنيت يعني : محرمانگي، جامعيت و دسترس پذيري را براي داده ها بوجود آورده و آنها را در برابر حملات عناصر داخلي و خارجي حفاظت نمايند.

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

«چگونگي روشهاي برقراري امنيت (مستقل از پياده سازي) و يك خط مشي قابل اجرا، حاصل اعمال سياست خواهد بود».

 

از طرفي :

«مكانيزم، عبارت است از مؤلفه هاي سخت افزاري و نرم افزاري لازم براي پياده سازي يك سياست»

 

كليدي ترين بحث در امنيت پايگاه داده، نحوه كنترل دسترسي به داده ها و ارائه محل مناسب براي آن مي باشد و در اين رابطه مي بايست مدل امنيتي كه درحقيقت مدل كنترل دسترسي است ارائه گردد لذا اين موضوع حائز اهميت است كه هدف از كنترل دسترسي، محدود نمودن اعمال و فعاليتهاي يك كاربر معتبر سيستم هاي كامپيوتري و يا برنامه هاي اجرايي وي مي باشد.

 

نكته مهم آن است كه كنترل دسترسي فقط يكي از ابعاد مهم امنيتي است لذا راه حل كاملي براي برقراري امنيت در يك سيستم نمي باشد.

 

 

 

شكل فوق ارتباط كنترل دسترسي را با سرويسهاي امنيتي ديگر نشان مي دهد.

 

اجزاي يك مدل كنترل دسترسي به طور خلاصه تحت عناوين ذيل مي باشند :

 

-         عاملها (Subjects)

-         اشياء (Objects)

-         حالتهاي دسترسي (access modes)

-         سياستها (Policies)

-         مجازشناسي ها (authorizations)

-         مجوزهاي مديريتي (administrative rights)

-         اصول (axioms)

 

حال طبق شكل زير ارتباط اجزاي يك مدل كنترل دسترسي نشان داده مي شود.

 

 

امكانات امنيتي كه يك DBMS خوب بايد فراهم كند:

در اينجا هدف عنوان نمودن بعضي امكانات خوب امنيتي است كه يك DBMS بايد قادر به ارائه آن باشد :

 

-         حالتهاي دسترسي مختلف

-         انواع مختلف كنترلهاي دسترسي

-         مجازشناسي (authorization)

-         حفاظت چند سطحي

-         جلوگيري از ايجاد كانال مخفي (روش ارتباط غيرمستقيم براي دسترسي غيرمجاز به اطلاعات)

-         امكان ايجاد محيطي كه دادة يكسان از نظر كاربران مختلف به صورت متفاوت نشان داده شود.

-         يكپارچه بودن روشهاي كنترل محرمانگي و كنترل جامعيت

-         كارايي معقول در برابر سربار حاصل از هزينه هاي امنيتي

-         كنترل جريان براي بررسي مقصد اطلاعات

 

طراحان پايگاه داده مي بايست موارد اشاره شده را مدنظر قرار داده و در اين خصوص قادر به اعمال انواع سياستهاي كنترل دسترسي باشيم.

 

 

لذا سياستهاي قابل اعمال بايد به نحوي باشد كه :

 

الف) دسترسي كاربران به اطلاعات براساس هويت كاربر و قوانين مالكيتي از پيش تعريف شده (توسط مدير امنيت سيستم) باشد.

 

ب) دسترسي كاربران به اطلاعات براساس رده بندي امنيتي كاربران و داده هاي موجود در سيستم، مديريت شود.

 

ج) رده امنيتي كاربر، ميزان اطمينان سيستم به وي و رده امنيتي داده، ميزان حساسيت آن و ضررهاي ناشي از فاش شدن داده نشان داده شود.

 

د) هر وظيفه شغلي يا مسئوليت در سيستم به عنوان يك نقش تعريف شده و مجوزهاي لازم براي ايفاي نقش، به آن تخصيص مي يابد.

 

هـ) كاربران با عضويت در نقش مي توانند به منابع سيستم دسترسي پيدا كند كه اين نقش رابط كاربر و مجوزها مي باشد.

 

نتيجه اينكه طراحان پايگاههاي داده در شبكه علمي كشور ضمن نگرش به نوع داده ها و پايگاههاي داده موردنياز در سطح شبكه علمي لازم است با ديد امنيتي و لحاظ نمودن پارامترهايي كه به طور مختصر به آنها اشاره شد، طراحي و پياده سازيهاي لازم را انجام داده و درصورت امكان با مشاوره گروه امنيت شبكه علمي اقدام به مورد مذكور نمايند.

تهاجمات و ضعف هاي امنيتي:

موارد مربوط به تهاجمات و ضعف هاي امنيتي از دو ديدگاه موردنظر مي باشد :

 

 

انواع تهاجمات به داده ها :

 

-         تهاجماتي كه باعث افشا شدن اطلاعات حساس مي شود.

-         تهاجماتي كه باعث تغييرات ناخواسته در اطلاعات ذخيره شده مي گردد.

-         تهاجماتي كه باعث جلوگيري از دسترسي افراد مجاز به اطلاعات مي شود.

-         تهاجماتي كه باعث تغييرات عمدي درا طلاعات مي شود.

-         تهاجماتي كه باعث ايجاد دسترسي افراد غيرمجاز به اطلاعات مي گردد.

 

انواع داده هاي مورد تهاجم :

 

-  حملات به اطلاعات پيكربندي سيستم ها و هويت شناسي

اين حملات شامل تغيير غيرمجاز داده ها، تغيير اطلاعات در هنگام انتقال و يا استفاده از اطلاعات هويت شناسي براي نفوذ به سيستم و ... مي باشد.

 

-  حملات به داده هاي ذخيره شده بر روي سيستم هاي ذخيره سازي

اين نوع حملات شامل خطاهاي غيرعمدي خرابي سيستم هاي مذكور مي شوند و حتي مي تواند شامل خرابيهاي عمدي و دسترسي غيرمجاز افراد به سيستم هاي ذخيره سازي باشد.

 

-   وجود اشكالات نرم افزاري و سخت افزاري در سيستم هاي ذخيره سازي اطلاعات و خطاهاي غيرعمدي كاربران به هنگام دسترسي بر روي داده ذخيره شده

 

-   حملات و ضعف هاي نرم افزاري واسط بين سيستم هاي ذخيره سازي اطلاعات و كاربران

 

موارد مذكور شامل :

 -  ضعف هاي امنيتي و خطاهاي سيستم عامل

-  خطاها و ضعف هاي امنيتي مدير پايگاه داده DBMS

-  خطاها و ضعف هاي امنيتي برنامه اي Client

 

روشهاي مقابله:

در اين بخش بعضي روشهاي كلي با درنظر گرفتن سه هدف كشف، ترميم و جلوگيري از حمله بيان مي شوند. به لحاظ كلي امنيت داده ها در نگهداري و انتقال مي باشد و لذا راههاي ذيل به طور مشخص ارائه مي گردند.

 

اضافه كردن داده:

 

با روش اضافه كردن داده، بسته اضافي طولاني تر يا با تكرار ارسال مي گردد و از اين روش براي كشف حمله و يا ترميم استفاده مي شود و در اين خصوص از روشهاي كُدگذاري، CRC (Cyclic Redundancy Check)، تكرار پيغام به هنگام ارسال و تكرار در ذخيره سازي استفاده مي شود.

 

ايجاد حصار در اطراف داده :

 

با ايجاد حصار فيزيكي در اطراف محل نگهداري داده و يا خطوط انتقال مي توان از شنود و سرقت اطلاعات جلوگيري نمود و با ايجاد حصارهاي سيستم برنامه مي توان ضوابط خاصي را براي استفاده از داده تعريف نمود.

 

رمزنگاري :

 

با استفاده از رمزنگاري در دو روش كلي رمزنگاري متقارن و غيرمتقارن مي توان براي نگهداري و يا انتقال داده ها، آنها را تغيير شكل داد و درنتيجه استفاده از داده ها براي افراد غيرمجاز ممكن نخواهد بود و به كارگيري رمز از ابزاري است كه حتي اگر خطوط انتقال و محل ذخيره سازي در اختيار مهاجم قرار گيرد مي توان تا حد زيادي از امنيت آن اطمينان حاصل كرد.

 

روشهاي تأييد :

 

با استفاده از اين روش قبل از اينكه انتقال ديتا انجام شود طرفين مبدأ و مقصد از هويت يكديگر اطمينان حاصل نموده و پس از آن انتقال داده انجام خواهد شد.

 

 

  ثبت اتفاقات :

يكي از روشهاي بسيار مفيد ايجاد مجموعه اي است كه در آن وضعيت و رفتار كاربران در ارتباط با انتقال داده ثبت شود و با مراجعه به آن بتوان فرد خرابكار را شناسايي نمود.

مسئله مهم و قابل توجه اين است كه روشهاي ديگري هم وجود دارد و لذا مي بايست طبقه بندي و حساسيت اطلاعات مشخص شود و راههاي ديگر و يا راههاي تركيبي مورد استفاده قرار گيرند لذا ابزارآلاتي كه در اين خصوص موردنياز هستند در فازهاي بعدي پروژه معرفي و طريقه كار آنها ارائه خواهد شد.

 

ANSI/SPARC

سيستم های مديريت پايگاه داده دارای معماری های يکسانی نيستند. معماری سه سطحی ANSI/SPARC يکی از استانداردهایی است که امروزه اساس اکثر سيستم های مديريت پايگاه داده را شکل می دهد. اين استاندارد توسط گروه مطالعاتی ANSI/SPARC اولين بار در سال 1975 برای طراحی سیستم های مدیریت پایگاه داده پیشنهاد شد.

ANSI/SPARC مخفف American National Standards Institute, Standards Planning And Requirements Committee است.

معماری ANSI/SPARC سه سطح مجزا را برای توصيف داده در يک پايگاه داده تعيين می کند:

سطح داخلی(internal level)

      سطح خارجی(external level)

      سطح ادراکی (conceptual level)

هدف معماری سه سطحی اين است که امکاناتی را فراهم کند تا کاربران بتوانند با ديدگاه های شخصی خود به داده موردنياز دسترسی پيدا کنند. يعنی هر کاربری بتواند به داده مشترک دسترسی پيدا کند اما ديد خاص خود را داشته باشد.

از طرف ديگر فاصله بین سطح داخلی از سطح خارجی دلالت بر این دارد که کاربر نیازی به دانستن جزئیات فیزکی داده ذخیره شده در پایگاه داده ندارد. این تفکیک سطح اجازه تغییر ساختار ذخیره سازی پایگاه داده را بدون تاثیر روی دیدهای کاربران می دهد. لازمه اين استقلال سطوح از همديگر است به نحوی که تغييرات روی يک سطح روی بقيه تاثير نگذارد.

ANSI-SPARC Architecture


سطح خارجی

سطح خارجی دید کاربر از داده های ذخیره شده در پايگاه داده است. منظور از دید کاربر (user view) قسمتی از پایگاه داده است که کاربر با آن سروکار دارد. يعنی مجموعه ای از صفات خاصه موجوديت هائی است که در اختيار کاربر قرار داده می شود. هر کاربر دیدگاه های خاص خود را از پايگاه داده می تواند داشته باشد.

دید هر کاربر باید تعریف شود. به تعریف و شرح دید کاربر شمای خارجی (external schema) می گویند. برای تعريف شمای خارجی از یک مدل داده استفاده می شود که معمولا همان است که در سطح ادراکی بکار رفته است.


سطح ادراکی

سطح ادراکی کل داده های که در پایگاه داده ذخیره می شوند و ارتباط مابين آنها را شرح می دهد. یعنی داده هائی درباره انواع موجودیت ها و ارتباط آنها در محیط عملیاتی را توصيف می کند.

سطح ادراکی دید طراح پایگاه داده از داده های ذخیره شده در پايگاه داده است. داده های دنيای واقعی آنطور که واقعا هستند توسط طراح پايگاده داده مدل می شوندد.

برای تعریف سطح ادراکی از یک ساختار یا مدل داده استفاده می شود که شمای ادراکی (conceptual schema) ناميده می شود. شمای ادراکی کلیه داده ها و ارتباط بین آنها را توصیف می کند. علاوه بر اين رويه های شناسائی و قیدهای جامعیت را نيز دربر می گيرد.

برای کسب استقلال داده، شمای ادراکی تنها درگير معنی داده است و جنبه های نمایش داده، سازماندهی فیزیکی و استراتژی های دستيابی نديده گرفته می شود.

شمای خارجی از شمای ادراکی مشتق می شود و اگر مدل داده در هر دو سطح یکسان نباشد سیستم پایگاه داده را دوساختاری می نامند.


سطح داخلی

سطح داخلی درگیر چگونگی نمایش فیزیکی پایگاه داده روی سیستم کامپیوتری است و شرح می دهد چگونه داده واقعا در پایگاه داده و سخت افزار ذخیره می شود.

سطح داخلی دید طراح پايگاه داده از محیط فیزیکی ذخیره سازی و درواقع فایل های محیط فیزیکی است که توسط شمای داخلی (internal schema) توصيف می شود. شمای داخلی نحوه نمايش فيزيکی داده هایی را که در شمای ادراکی شرح داده شده را مشخص می کند. انواع مختلف رکوردها، فيلدهای داده، فایل ها، نحوه نمایش رکوردها در فایل، استراتژی دستیابی، شاخص ها و چگونگی ترتیب رکوردها در فایل توسط شمای داخلی تشریح می شوند.

جزئيات تبديل به منبع ذخيره سازی در معماری سه سطحی بيان نمی شود و از این سطح به پائین در اختیار DBMS نیست و به عهده سیستم عامل و درایورهای دستگاه ذخیره سازی است.


مثال. در يک سازمان موجوديت کارمند را درنظر بگيريد. دوکاربرUser1 و User2 با دو ديد مختلف با اين موجوديت کار می کنند. تعريف ديدهای خارجی، ادراکی و داخلی می توانند چنين باشند:

خارجی.

Example External View

 

ادراکی.

Employee 
   Employee_Number Character(6)
   Department_Number Character(4)
   Salary Numeric (5)

Example Conceptual Schema

داخلی.

Stored_Emp
   Prefix Type=Byte(6), Offset = 0
   Emp# Type = Byte (6), Offset = 6, Index = Empx
   Dept# Type = Byte (4), Offset = 12
   Pay Type = FullWord, Offset = 16


تبديلات بين سطوح

در معماری سه سطحی روش هائی برای تبديل سطوح به يکديگر وجود دارد. دو سطح از تبديل موجود است:

تبديل ادراکی/داخلی ارتباط ديد داخلی و ادراکی را تعريف می کند. تعيين می کند رکوردها و فيلدهای سطح ادراکی چگونه در سطح داخلی نمايش داده شوند. تغييرات در سطح داخلی باعث عوض شدن تبديل ادراکی/داخلی می شود. بنابراين شِمای ادراکی ممکن است ثابت بماند تا استقلال فيزيکی حاصل شود.
تبديل خارجی/ادراکی ارتباط ديد ادراکی و يک ديد خاص خارجی را برقرار می کند. مثلا يک صفت خاصه از ديد کاربری ممکن است ترکيبی از چندين فيلد در سطح ادراکی باشد. تغيير در تعاريف ادراکی باعث تغيير نگاشت ادراکی/خارجی می شود. از اين رو شِمای خارجی ممکن است ثابت بماند تا استقلال داده منطقی بدست بيايد.


استقلال داده

سيستم های قديمی وابسته به داده بودند به اين معنی که روش سازماندهی داده در دستگاه جانبی و روش دسترسی به آن توسط برنامه و در منطق آن ساخته می شدند. در چنين سيستمی تغيير در ساختار دخيره سازی يا استراتژی دستيابی بدون تاثير روی برنامه غيرممکن است.

يکی از مزايای سيستم پايگاه داده استقلال داده است. استقلال داده به معنی مصونيت برنامه ها از تغييرات ساختار ذخيره سازی و استراتژی دستيابی است. ساختار ذخيره سازی بدون تاثير روی ديدهای کاربران است می تواند تغيير کند. پايگاه داده و برنامه های کاربری هم می توانند مستقل از يکديگر تغيير کنند.

 

دو نوع استقلال داده وجود دارد:

1.   • استقلال فیزیکی داده نشان می دهد تا چه اندازه شمای داخلی می تواند بدون تاثیر روی برنامه های کاربردی تغییرکند.
2.
استقلال منطقی داده نشان می دهد تا چه اندازه شمای ادراکی می تواند بدون تاثیر روی برنامه کاربردی تغییر کند.


زبان ميزبان و زبان فرعي داده

برنامه نويسان، برنامه های کاربردی را با استفاده از يک زبان های سطح بالا نظير Visual basic، Java و Visial C پياده سازی می کنند. زبان سطح بالائی که علاوه بر داشتن امکانات گوناگون دارای دستوراتی برای تعريف و کار با داده هستند زبان ميزبان (host language) ناميده می شوند.

زيرمجموعه ای از زبان ميزبان که مختص عمليات ذخيره و بازيابی اطلاعات از پايگاه داده است زبان فرعی داده (Data Sub Language) نام دارد.

هر DSL ترکيبی از سه زبان ديگر است:

      احکام تعريف داده (DDL)

      احکام کارکردن با داده (DML)

احکام کنترلی (DCL)

3.  احکام کنترلی (DCL)زبان تعریف داده

DDL مخفف Data Definition Language امکان تعريف يا توصيف اشيای پايگاه داده را می دهد. ساختار ركوردها، تعریف فیلدها، محل فایل ها و شیوه ذخیره سازی داده ها در بانك به وسیله احكام DDL انجام می پذیرد.

مثال. نوع رکور زير را درنظر بگيريد.

create table account (
    account-number  char(10),
    balance    integer)


زبان دستکاری داده

DML مخفف Data Manipulation Language عمليات پردازشی و دستکاری اشيای پايگاه داده مانند insert، select، update را پشتيبانی می کند.

DML به عنوان زبان پرس و جو هم شناخته می شود واغلب دارای قابلیت انجام محاسبات ریاضی و آماری است كه عملیات گزارش گیری از پايگاه داده را آسان تر می کند.

زبان کنترل داده

DCL مخفف Data Control Language امکان تعيين نوع استراتژی های دستيابی، تعريف شاخص ها و مرتب سازی داده های پايگاه داده را می دهد.


دو دسته زبان DSL وجود دارد:

رویه ای (Procedural). کاربر داده ای که نياز دارد و نحوه دريافت آن را تعيين می کند. 
غیررویه ای (nonprocedural) يا (Declarative). کاربر تعیین می کند چه داده ای مورد نیاز است ولی نحوه حصول آن را بيان نمی کند.

هر سیستم پایگاه داده DSL خاص خود را دارد به عبارت دیگر هر مدل داده زبان فرعی خاص دارد. يک DSL خاص که توسط اغلب سيستم های فعلی پستيبانی می شود SQL است. SQL يک زبان غير رويه ای است.

سطوح داخلی، ادراکی و خارجی هريک DSL خاص خود را دارند. شِمای هر سطح توسط DSL مربوطه نوشته می شود.


XML مخفف Extensible Markup Language که توسط کنسرسیم W3C معرفی شده است زبان نشانه گذاری مستندات است تا زبان پایگاه داده. اما توانائی آن در تعیین تگ های جدید و تولید ساختارهای تودرتو باعث شد روش مهمی برای تبادل داده بشود و اکنون XML اساس کلیه فرمت های تبادل داده نسل جدید شده است. ابزارهای گوناگونی برای تجزیه، مرور و پرس و جو داده/مستندات XML موجود است.


کاربران پایگاه داده

کاربران يک سيستم پايگاه داده توسط روش هائی که با سيستم تعامل می کنند از هم تفکيک می شوند.

تحلیل گران سیستم

تحليل گران سيستم (system analysts) با گروه کاربران پایگاه داده به منظور درک نیازهای اطلاعاتی و پردازشی آنها ارتباط دارند. نیاز های اطلاعاتی و پردازشی هر گروه را مجتمع می کنند و مستندسازی می کنند.

طراحان پایگاه داده

طراحان پايگاه داده (database designers) ساختار مناسبی را برای نمایش اطلاعات مشخص شده توسط تحلیل گر سیستم به طریق نرمالسازی شده به منظور تضمین جامعیت و سازگاری داده انتخاب می کنند و با استفاده از DDL داده های پايگاه داده را تعريف می کنند.

پیاده سازان برنامه های کاربردی

برنامه نويسان برنامه های کاربردی (Application Developers) برای برآوردن نيازهای کاربران و کار با پايگاه داده برنامه هایی را آماده می کنند. تست، اشکالزدائی و مستندسازی برنامه و پايگاه داده از وظايف برنامه نويسان است. برنامه نويسان با سيستم توسط احکام DML ارتباط برقرار می کنند.

مدیر پایگاه داده

مدير پايگاه داده (database administrator) يا بطور خلاصه DBA فردی است که مسئول کنترل عمليات کل سيستم پايگاه داده است. DBA کلیه فعالیت های سیستم پایگاه داده را هماهنگ می کنند. اين فرد بايد درک خوبی از منابع و نیازهای اطلاعاتی کل سازمان داشته باشد و برای حصول اطمينان از اينکه داده موردنياز قابل دسترس کاربران قرار می گيرد با آنها در ارتباط باشد.

بعضی از وظایف DBA شامل:

    تعريف شِماها توسط DDL

    تعريف ساختار ذخيره سازی و متدهای دسترسی توسط DDL

    اصلاح شِما و سازماندهی فيزيکی

    اعطای مجوز دسترسی پايگاه داده به کاربران

    تعيين قيدهای جامعيت

    عامل ارتباطی کاربران

    نظارت اجرا و واکنش برای تغییر درصورت نیاز

    برقراری ديکشنری دادهکاربران نهائی

کاربران نهائی (End Users) شامل:

کاربران پارامتری : که توسط برنامه های کاربردی نوشته شده با سيستم سروکار دارند. مانند تحويلدار بانک و کارکنان دفتری.
کاربران ماهر : که نیاز های پیچیده تری دارند و با قابلیت های
DBMS آشنائی کامل دارند. درخواست های خود از پایگاه داده را توسط یک زبان پرس و جو می سازند.

کاربران نهائی اتفاقی : کسانی که دسترسی گاه و بیگاه به پایگاه داده دارند اما ممکن است هر بار نیازهای متفاوتی داشته باشند. از زبان های پرس و جوی و مرورگرهای حرفه ای تر استفاده می کنند.


ديکشنری داده

دیكشنری داده ها (Data Catalog) یكی از امكاناتی است كه در سيستم پايگاه داده در اختيار DBA قرار می گیرد. دیكشنری داده ها كه به آن راهنمای سیستم نیز می گویند يک متا داده است يعنی اطلاعاتی درباره خود پايگاه داده و داده های ذخیره شده در آن را نگهداری می کند.

دیکشنری داده تعيين می کند چه داده ای موجود است و چه معنی دارد، داده چگونه ذخیره می شود و در کجا قرار دارد، مالک آن چه کسی است و چه کسانی اجازه دسترسی به داده را دارند، تاریخچه و آمار استفاده از داده را دربردارد.

مدل کردن داده روشی برای توصيف داده ها و عمليات روی آنها در سطوح مختلف معماری پايگاه داده است. مدل های سلسله مراتبی و شبکه از قديمی ترين ساختارها برای مدل کردن داده بوده اند.

Data modeling

مدل کردن داده (data modeling) تحلیل و توصيف داده های محیط عملیاتی و ارتباط بین آنها و شرح معنی و قیدهای داده است.

یک مدل داده قالب قراردادی برای ساخت و کارکردن با داده دراختیار می گذارد.

يک مدل داده پديده های دنيای واقعی را توصيف می کند و ساختار داده مورد نیاز برای حل مسئله خاص و ارتباط درونی بین ساختارها را تعریف می کند. دیاگرام ER مثالی از این نوع است که بیشتر توسط طراحان و تحلیل گران سیستم به کار می رود.

علاوه براين مدل داده تعیین می کند یک DBMS چگونه داده را درون خود، به کاربران و برنامه های کاربردی نمایش دهد. مدل رابطه ای مثالی برای این نوع از مدل داده است.


عناصر مدل داده

هر مدل داده باید جنبه های زیر را دارا باشد و نمادهائی برای بیان آنها داشته باشد:

ساختمان های داده. که راهی برای سازماندهی داده های محيط عملياتی است و به DBMS می گوید چگونه داده نمایش داده می شود.
جامعیت. برای تضمین سازگاری و اعتبار داده در پايگاه داده است و به DBMS می گوید چگونه مانع ورود داده نامعتبر به پايگاه داده بشود.
عملیات. مجموعه روش هایی که امکان کار با داده را می دهند مانند عمليات اضافه، حذف، اصلاح و بازیابی داده.

ساختمان های داده

لازمه هر مدل داده ای وجود یك ساختار داده ای است. ساختار های داده نحوه سازماندهی داده های محيط عملياتی و نمايش داده در DBMS را تعيين می کند.

هر مدل داده بايد شامل نمادهائی برای تعريف انواع موجوديت، انواع صفات خاصه و انواع ارتباط بين موجوديت ها باشد.

جامعیت

در هر مدل داده بايد امکان تعريف قيدهای جامعيت وجود داشته باشد. قيدها قوانينی را برای تضمین سازگاری و اعتبار داده در پايگاه داده است وضع می کنند و به DBMS می گویند چگونه مانع ورود داده نامعتبر به پايگاه داده بشود.

عملیات

یک مدل داده علاوه بر ساختمان داده، مجموعه عملیاتی را تعریف می کند که می تواند روی داده انجام شود.

عمليات امکان کار با داده را می دهند مانند اضافه، حذف، اصلاح و بازیابی داده.

البته این عملیات ممکن است صریحا در زبان پرس و جو خاصی نباشند. بلکه اساسی را فراهم کنند که بر پایه آن زبان پرس و جو ساخته می شود.

 

 

 

انواع مدل های داده

عناصر مدل داده

انواع مدل های داده

مدل سلسله مراتبی

مدل شبکه ای

پايگاه داده XML


مدل سلسله مراتبی

قديمی ترين مدل برای طراحی پايگاه داده مدل سلسله مراتبی ( hierarchical model) است، که در اوایل دهه 60 توسط IBM برای سازماندهی دنیای تجارت به شکل سلسله مراتبی پيشنهاد شد.

در مدل سلسله مراتبی داده ها و ارتباط بین آنها به كمك یك درختواره نمایش داده می شوند.

درختواره گرافی است دارای یك ریشه و تعدادی گره که بین هر دو گره پیوندی وجود دارد. پيوند یك مسیر منطقی را از يک گره در سطح بالا به يک گره دیگر در سطح پايين برقرار می كند. مسیری از گره سطح پایین تر به گره سطح بالاتر وجود ندارد.

مدل اجازه تکرار اطلاعات را توسط ارتباطات والد/فرزند می دهد؛ یعنی هر گره در هر سطح می تواند تعدادی گره وابسته یا فرزند داشته باشد که بعنوان والد آنها محسوب می شود. هر گره فرزند تنها دارای يک گره والد است.


مثال. شرکتی چند شعبه دارد. هر شعبه احتیاج به چندین قطعه برای ساخت محصولاتش دارد. هر قطعه از چند تهیه کننده تهيه می شود.

در ساختار سلسله مراتبی دو نوع رکورد قطعه و موجوديت به صورت زير تعريف می شوند:

Product ( P#, Pname, Color, Weight, City)
Supplier (S#, Sname, Status, City, QTY)

Hierarchical model Example

 

 

 

خواص مدل

 

      هر گره درختواره حاوی کليه صفات خاصه يک نوع رکورد تحت يک نوع موجوديت است

      درختواره مجموعه ای از رکوردها با انواع مختلف می تواند باشد.

      مجموعه ای از پیوندها را دارد که کلیه انواع رکورد را در ساختار بهم متصل می کند

      حداکثر یک پیوند بین دو نوع رکورد وجود دارد بنابراین پیوندها نامگذاری نمی شوند

      هر رکورد تنها والد در سطح بالاتر در درخت وجود دارد

      اتصالی بین رکوردهای هم نوع وجود ندارد. بین رکوردهای هم سطح نمی توان حرکت کرد مگر اینکه والدشان یکی باشد

      نقطه ورود به ساختار هميشه ريشه است و مسير منطقی هميشه از بالا به پايين است

      دو عملگر جداگانه برای يافتن داده ای در ريشه و پرس و جو در فرزندان مورد نياز است

 

مزایا و معایب

      چون داده به صورت يک درختواره سازماندهی می شود برای داده هایی که ماهيت سلسله مراتبی دارند مناسب است

      ساختار سلسله مراتبی برای مدل کردن ارتباطات یک به چند مناسب است

      ساختار درختی انعطاف پذیر نبوده و برقراری پیوندهای جدید بین رکوردها بعد از ايجاد درخت امکان ندارد. علاوه براين پيوندهای عمودی هستند و نمی توان پیوند افقی و مورب در درخت تعریف کرد

      ارتباط تنها می تواند به صورت "تعلق دارد" یا "شامل می شود" کد شوند

      در عمليات ذخیره سازی يعنی درج، حذف و بهنگام سازی دارای آنومالی است (درمثال امکان ذخيره تهيه کننده S4 تا زمانيکه ندانيم چه قطعه ای توليد می کند وجود ندارد)

      رويه های پاسخ به پرس و جوهای قرينه متقارن نيستند( برای مثال رويه جستجو برای "شماره تهيه کنندگانی که P2 را تهيه می کنند" متفاوت از رويه جستجوی "شماره قطعاتی که توسط S1 تهيه شده است")

در نمايش افزونگی داده ناتوان است (در مثال اگر بخواهيم شهر S1 را تغيير دهيم در همه نمونه رکوردهایی که S1 ظاهر شده باید انجام شود دغير اينصورت ناسازگاری رخ می دهد)

 

مدل شبکه ای

درمقايسه با مدل سلسله مراتبی که ساختمان های داده ای به صورت درختی از رکوردها سازماندهی می شود و هر رکورد آن يک والد و چند فرزند دارد، مدل شبکه اجازه رکوردهائی با چند والد و چند فرزند را می دهد که در نتيجه يک ساختار مشبک را می سازد.

به مدل شبکه ساختار Plex هم گفته می شد.

درمقايسه با مدل سلسله مراتبی که درختی از رکوردها سازماندهی می شود و هر رکورد آن يک والد و چند فرزند دارد، مدل شبکه اجازه رکوردهائی با چند والد و چند فرزند را می دهد که در نتيجه يک ساختار مشبک را می سازد.

عمليات در مدل شبکه به صورت پيمايشی است از يک رکورد به ديگری با دنبال کردن ارتباطاتی که رکورد درآنها سهيم است دنبال می شود.

 

مثال. ارتباط دو سويه قطعه و تهيه کننده را دنظر بگيريد. هر قطعه توسط چند تهيه کننده تهيه می شود و هر تهيه کننده چند قطعه را عرضه می کند.

Network model Example

 

خواص مدل

 

        در این ساختار موجودیت ها به كمك انواع ركوردها، و ارتباطات به كمك پیوندهای بین ركوردها نمایش داده می شوند.

        هر گره فرزند می تواند بیش از یك گره والد داشته باشد.

        برای نمايش ارتباطات یك به چند دو سويه مناسب است.

        عملیات ذخیره و بازیابی پیچیده تر از مدل سلسله مراتبی است.

        برای پرس و جوهای قرینه رویه پاسخگوئی قرینه دارد ولی پیچیده است.

        متدهائی را برای ساخت و تعریف دوباره پیوندها دارد.

        ساختارهای فیزیکی مناسب برای ارتباطات شبکه ای ساختار چندحلقه است.

مزایا و معایب

 

        اجازه مدل کردن طبيعی تر ارتباطات مابين موجوديت ها را می دهد.

        مدل شبکه انعطاف پذیری بیشتری نسبت به سلسله مراتبی دارد.

        در عملیات ذخیره سازی آنومالی ندارد.

        مدل شبکه می تواند افزونگی داده را بهتر از سلسله مراتبی نشان بدهد.

        از دید کاربر وضوح کامل ندارد

        عمليات پيچيده تری دارد

        پیوند بین رکوردهای یک نوع ممکن نیست.

        اصل وحدت عملگر در یک عمل رعایت نمی شود.

پايگاه داده XML

يک پايگاه داده XML سيستم نرم افزاری است که اجازه می دهد داده در فرمت XML وارد، پردازش و ارسال شود.

دو دسته اصلی پايگاه داده XML وجود دارد:

1.  XML-enabled . پايگاه داده ای که مستند XML را به عنوان ورودی گرفته به يک پايگاه داده ديگر نظير رابطه ای تبديل می کند و پس از انجام عمليات آنرا مجددا به XML بر می گردند.

2.  Native XML (NXD). مدل داخلی چنين پايگاه داده ای بر پايه XML است و مستندات XML را به عنوان منبع ذخيره سازی مستقيما استفاده می کند.

دليل استفاده XML در پايگاه داده شفافيت داده است. داده از پايگاه داده استخراج می شود و در مستندات XML قرار می گيرد و برعکس. به اين صورت هزينه ذخيره داده در فرمت XML هم کمتر می شود.

 

 

 

 

معماري امن شبکه با نگاه به پايگاه داده

 

1-3  در نظر گرفتن سخت افزار جداگانه جهت سرور وب و سرور پايگاه داده:

بسياري از سرويسهاي کنوني وب و حتي  شبکه هاي داخلي (Intranet) به گونه اي طراحي شده اند که سرور اصلي پايگاه داده (Back End Server) را روي همان سروري در نظر ميگيرند که سرويس وب روي آن راه اندازي شده است. البته براي اين کار چندين توجيه وجود دارد :

 

توجيه اقتصادي: در نظر گرفتن هر دو سرويس بر روي يک ماشين از جهت هزينه کل سازمان يک صرفه جويي محسوب ميشود. بايد توجه داشت که براي ارايه هر دوي اين خدمات ماشينهاي با قدرت پردازش بالا بايد در نظر گرفته شوند.

 

توجيه فني: عده اي برين عقيده اند که ارائه اين دو خدمت بر روي يک ماشين سبب بهبود کلي کارايي ميشود. استدلال اصلي محدوديت سرعت بر روي شبکه است. اين استدلال نيز توجيه چنداني ندارد زيرا حداقل سرعت شبکه هاي محلي فعلي ۱۰۰Mb/s است که بسيار بالاتر از حداکثر سرعت شبکه هاي WAN در حال حاضر است.

 

بنابراين از دو توجيه بالا تنها استدلال مبتني بر صرفه جويي اقتصادي کماکان ميتواتند مطرح باشد. اما خطرات اجراي اين دو سرويس بر روي يک مکاشين به حدي ست که بهتر است سازمان به جاي پذيرش اين ريسکها، هزينه اضافي مربوطه را متحمل شود. تا کنون روشهاي متعددي براي نفوذ به سرورهاي وب طراحي و اجرا شده است.

 

بسياري از ويروسهاي کامپيوتري و نيز کرمهاي اينترنتي (Code Redو Nimda) نيز اساسا بر پايه همين ضعفها عمل ميکنند. صرف نظر از نوع سرور وبي که در نظر ميگيريد (Apache،IIS يا هر سرور ديگر) هميشه بايد اين احتمال را بدهيد که در صورت وجود يک شکاف امنيتي در سرور مربوطه، شما در مجموع کمترين ضرر را متحمل شويد.

 

جدا کردن فيزيکي دو سرور وب و پايگاه داده اين امر را تا حدي (دقت کنيد که فقط تا حدي و نه به طور کامل) براي شما تضمين ميکند که حتي اگر نفوذگري توانست اختيارات مدير سيستم مربوط به سرور وب را به دست بياورد نتواند به سادگي به اطلاعات موجود روي پايگاه داده نيز دست يابد.

 

قرار ندادن پايگاه داده در DMZ:

در صورتي که از يک معماري امن براي پياده سازي شبکه خود استفاده کرده باشيد به احتمال زياد شبکه شما داراي يک بخش DMZ(Don’t Militarized Zone) خواهد بود. معمولا ارائه دهندگان خدمات عمومي را درين بخش از شبکه قرار ميدهند.

 

بعنوان مثال سرورهاي وب، سرورهاي ميل ... که همگي جهت خدمات عمومي بکار ميروند درين بخش از شبکه قرار دارند.

 

ايده عمومي داشتن يک بخش DMZ ساده ست:

سرورهايي که خدمات عمومي بيرون سازماني ارايه ميدهند نيازمند سطح کمتري از امنيت هستند. در واقع همه ميتوانند به آنها دسترسي  داشته باشند. اين دسترسي همگاني به هيچ وجه لازم نيست در مورد تمامي منابع شبکه اعمال شود. بنابرين منابع عمومي شبکه را در بخشي از شبکه قرار ميدهند که حساسيت امنيتي کمتري نسبت به آن وجود دارد. اين همان بخش DMZ است. با توجه به مطالب بالا بسيار بديهي به نظر ميرسد سرور پايگاه داده را بايد در همان بخش DMZ قرار دهيم زيرا که عموما اين سرور نيز مسئوليت ارائه خدمات همگاني را بعهده دارد. اما قضيه در باره سرور پايگاه داده تا حدي متفاوت است. اين سرور گرچه خدمات همگاني نيز عرضه ميکند اما تنها بخشي از داده هاي آن ممکن است جنبه همگاني داشته باشد در حالي که عمده آن در اغلب اوقات سري ست. بعنوان مثال سروري که اطلاعات مربوط به کارت اعتباري افراد را نگهداري ميکند از اهميت فوق العاده اي برخوردار است و هرگونه دسترسي به کل داده هاي آن ميتواند فاجعه بار باشد.

 

بنابراين بر خلاف ديد اوليه به اين نتيجه ميرسيم که پايگاه داده نميتواند و نبايد که در بخش DMZ قرار گيرد. اما راهکار جداسازي آن ازين بخش چيست؟

شکل ۱: پايگاه داده و DMZ

 

 

 راه حل ايده آل براي اين جداسازي به شرح زير است: به صورت عام از يک فايروال اصلي براي ايمني کل شبکه و جداسازي آن از دنياي بيرون استفاده ميشود. اين فايروال در قسمت بيروني DMZ قرار دارد و داراي قواعد خاص خود است.

 

بدلايلي که در بخش پيش ذکر شد که کلا عبارت بود از نياز به ارائه خدمات عمومي ،اين فايروال نميتواند کل ترافيک ورودي را محدود کند و ناچار است يک سياست (Policy) حداکثري را اعمال کند.

 

اما در داخل خود شبکه ، مابيت LAN داخلي و DMZ از فايروال دومي استفاده ميشود. اين فايروال دوم در حالت ايده آل تمامي ترافيک ورودي را سد ميکند بجز ترافيک ورودي از وب سرور به پايگاه داده. با اين تمهيد خاص هم پچايگاه داده خدمات عمومي خود را ارائه ميدهد و هم دستيابي عموم را به آن سد کرده ايم. درين صورت يک نفوذ گر حتي پس ازينکه کنترل کامل سرور وب را در اختيار گرفت ناچار است از قواعد سختگيرانه فايروال

دوم نيز عبور کند و تازه پس ازان بايد بتواند به سرور پايگاه داده نيز نفوذ کند که انجام اين هر دو کار بسيار دشوار ميباشد و ريسک چنين شبکه اي عملا پايين مي باشد.

 

اما شايد در مقابل روش ما استدلالي اينچنين ارائه شود:

ميتوان تنها با استفاده از يک فايروال امنيت را تامين کرد. روش آنهم اينست که براي سرورهاي پايگاه داده از IP مجازي استفاده کنيم. در واقع اين سرورها پشت يک NAT قرار داشته باشند. درين صورت نفوذگر اساسا از وجود پايگاه داده خبر ندارد تا بخواهد به آن نفوذ کند. اين استدلال يک ابراد عمده دارد و آنهم اينست که اگر نفوذ گر بتواند کنترل سرور وب را در اختيار بگيرد عملا در همان شبکه اي قرار گرفته است که سرور پايگاه داده دران قرار دارد و داراي همان رنج IP ميشود. بنابراين پس ازينکار در واقع تمهيد قبلي ما بلااثر ميشود و نفوذ گر ميتواند بسادگي مانند يک کاربر داخلي شبکه ما عمل کند.

 

حال که استدلالات فوق را پذيرفته ايم ميتوانيم کمي ايده آل تر باشيم و شبکه را ايمن تر کنيم. فرض کنيد که يک نفوذگر بتواند از لايه اول امنيتي شما عبور کرده وارد DMZ شود. اگر اين نفوذ به دليل نقص قواعد امنيتي فايروال شماره يک باشد احتمال نفوذ همين شخص به لايه دوم بسيار پايين است. اما اگر اين نفوذ به دليل وجود شکاف امنيتي خاصي بر روي فايروال باشد چطور؟ فرض کنيد به عنوان مثال هردو فايروال شما Check Point است. آنوقت نفوذگر بهمان سادگي که از لايه اول عبور کرده از لايه دوم امنيتي شما نيز خواهد گذشت چون هر دو فايروال ما از يک نوع است و طبيعتا شکاف امنيتي هردو يکسان است. بنابراين ميتوان پيشنهاد داد که فرضا اگر فايروال لاه اول شما Check Point است در لايه دوم بهتر است از PIX استفاده کنيد. اين مطلب باعث امنيت بالاتر شبکه شما خواهد شد.

 

اين روش گرچه موثر است اما از عهده هرسازماني بر نمي آيد. نگهداري، بروزسازي و پيکربندي فايروال عموما خودش يک تخصص خاص و بالنسبه گرانقيمت است. بنابراين وقتي از دو نوع فايروال استفاده ميکنيد دو تخصص جداگانه را در سازمان خود نياز خواهيد داشت که اين مطلب باعث دو برابر شدن هزينه نيروي انساني شما خواهد شد. علاوه برينکه اصولا خود سخت افزار فايروال هم گرانقيمت است و اصولا مشخص نيست که سازمان شما حاضر باشد چنين هزينه اي را متقبل شود (حتي با فرض دانستن ريسک امنيتي بالاي آن)

راه حل ديگري که ميتوان براي جداسازي بخش امن شبکه ارائه داد استفاده از بيش از يک کارت شبکه در فايروال است (شکل ۲)

شکل ۲: استفاده از دو کارت شبکه براي جداسازي DMZ

 

 همانطور که مشخص است درين روش توسط يک فايروال، DMZ از بخش امن شبکه جداسازي ميشود. تنها ترافيکي که حق عبور از اينترفيس اول (eth1) به اينترفيس امن (eth2) را دارد ترافيک ورودي از وب سرور به سرور پايگاه داده ميباشد. اين روش بسيار ارزان تر از روش قبلي ست اما مشخصا امنيت آن در حد امنيت روش قبل نيست و علاوه برآن ممکن است فايروال موجود ما عملا از چندين کارت شبکه پشتيباني نکند.

 

علاوه بر دو راهي که در فوق براي جداسازي پايگاه داده از مابقي شبکه ارائه داديم راه حل سومي هم وجود دارد:

اينکه اساسا پايگاه داده را از مابقي شبکه جدانکنيم! دقت کنيد که با توجه به هزينه و نيز اندازه سازمان ممکن است جداسازي امکان پذير نباشد و حتي مجبور شويم که اين دو سرور را برروي يک ماشين اجرا کنيم. حتي درين صورت نيز بهتر است حداقل کارهايي که جهت ايمني مضاعف پايگاه داده از دستمان بر مي آيد انجام دهيم. بعنوان مثال ميتوانيم از يک فايروال نرم افزاري ارزان قيمت جهت ايمني بيشتر استفاده کنيم. بهر حال اين راه حل توصيه نميشود مگر در شرايط اجبار.

 

 

رمز نگاري اطلاعات مابين سرور وب و سرور پايگاه داده:

براي جلوگيري از سرقت اطلاعات در بين راه(Sniffing) عموما از روشهاي رمز نگاري استفاده ميشود. متداول ترين روش تحت وب براي انجام اين منظور استفاده از پروتکل SSL است. عموم اطلاعات امن که بر روي اينترنت منتقل ميشوند از همين پروتکل استفاده ميکنند . بعنوان مثال انتقال اطلاعات شناسايي با سرورهاي معروف ايميل، انتقال اطلاعات مربوط به کارت اعتباري و غيره.

 

تا بدينجا اين پروتکل که اغلب سرورهاي وب و نيز مرورگرها ازان پشتيباني ميکنند سطحي از امنيت را تامين ميکند. اما آيا همين کافي ست؟

 

اغلب اين اشتباه پيش مي آيد که همين سطح از رمز نگاري را در مقابل حمله Sniffing کافي ميدانند. بايد دقت کرد که SSL به صورت عام تنها براي رمزنگاري اطلاعات مابين Client و سرور وب به کار ميرود و به صورت عادي اطلاعات مابين وب سرور و سرور پايگاه داده به صورت عادي و بدون رمزنگاري (Plain Text) منتقل ميشوند. بنابراين حتي اگر همه جوانب را در شبکه بيروني رعايت کرده باشيم، يک نفوذگر داخلي به سادگي ميتواند اطلاعات در حال انتقال مابين اين دو سرور را شنود کند. اين مطلب زماني بسيار جدي ميشود که بدانيم بر اساس داده هاي موجود، بالاتر از ۶۰٪ حملات موجود حملات درون سازماني مي باشد.

 

چاره کار استفاده از يک روش رمز نگاري مابين سرور وب و سرور پايگاه داده است. اغلب سرور هاي پايگاه داده امروزه از SSL حمايت ميکنند. MS SQL Server2000 ، Oracle،Sybase ازين جمله اند. البته استفاده از SSL براي ارتباط مابين اين دو سرور لازمه اش اينست که برنامه اصلي شما (Web Application) با همين ملاحظه طراحي و پياده سازي شده باشد.

اما در صورتي که برنامه شما از قبل موجود باشد يا از SSL پشتيباني نکند يا به هر صورت شما مايل به ايجاد هزينه اضافي نباشيد چه؟ آيا راه حل ديگري براي رمزنگاري مابين دو سرور وجود دارد؟ خوشبختانه چنين راه حلي وجود دارد: استفاده از SSH يا يک برنامه مشابه.

 

اصولا SSH برنامه اي شبيه Telnet است اما نسخه امن آن. يکي از قابليتهاي SSH ايجاد يک تونل امن است. به اين صورت که ميتوان برنامه SSH را به گونه اي اجرا کرد که بر روي يک پورت شنود کند کل اطلاعات آن را رمز کرده به کامپيوتر مقصد ارسال کند و آنجا پس از تبديل به حالت عادي به پورت مقصد تحويل دهد. با استفاده از اين روش (SSH Port Forwarding) يک تونل امن به صورت شفاف مابين دو سرور ايجاد شده است(شکل ۳).

 

شکل ۳: استفاده از SSH براي برقراري تونل امن

 

 

مزيت استفاده ازين روش اينست که نياز به هيچگونه تغييري در سرورها و يا برنامه ها ندارد و تنها توسط چند خط دستور قابل اجراست.

 

 

 

اوراکل نرم‌افزار بانک اطلاعاتي

شرکت اوراکل در اقدامي قافلگيرانه يک نسخه مجاني از نرم‌افزار بانک اطلاعاتي ORACLE 10g با نام Express Edition منتشر کرد.

 

روز سه‌شنبه شرکت اوراکل صنعت نرم‌افزار جهان را غافلگير کرد و با صدور اطلاعيه‌اي انتشار مجاني نسخه Express از نرم‌افزار مشهور و محبوب ORACLE 10g را اعلام و طلسم گران قيمت بودن اين نرم‌افزار را شکست.

 

نسخه Express از نرم‌افزار ORACLE 10g داراي محدوديت‌هايي است. از جمله تنها روي سرورهايي کار مي‌کند که يک پردازنده دارند و فقط از 4 گيگابايت فضاي ذخيره‌سازي روي هاردديسک و يک گيگابايت حافظه رم پشتيباني مي‌کند.

 

گرچه محدوديت‌هاي نسخه Express مانع از به‌کارگيري آن در محيط‌ها و سايت‌هاي بزرگ مي‌شود اما اين مشخصات براي راه‌اندازي سايت‌هاي کوچک و متوسط و نيز مصرف برنامه‌نويسان شرکت‌هاي نرم‌افزاري کافي به نظر مي‌رسد.

نسخه بتاي Express Edition از اين نشاني قابل دريافت است.

نرم‌افزار بانک اطلاعاتي اوراکل قدرتمند‌ترين سيستم در نوع خود به شمار مي‌رود و زيرساخت نرم‌افزاري بسيار از سازمان‌ها و شرکت‌هاي بزرگ دنيا همچون ساختار دولت الکترونيک برخي از کشورهاي جهان بر مبناي آن بنا شده است. اما معماري و اينترفيس دشوار اين نرم‌افزار تاکنون مانع از رويکرد عمده برنامه‌نويسان رده متوسط به سمت آن شده است.

 

به نظر مي‌رسد اوراکل قصد دارد با اين اقدام چهره مهربان‌تر و کاربرپسندتري از خود ارائه دهد و جايگاه خود را در بازارهايي که نرم افزار SQL Server مايکروسافت و برنامه اپن سورس MySQL حرف اول را مي‌زنند تقويت کند.

 

اقدام اوراکل از سوي بسياري از محافل اپن سورسي جهان حرکتي در جهت تضعيف جنبش اپن سورس در بازار نرم‌افزارهاي بانک اطلاعاتي ارزيابي شده است. محافل اپن سورسي معتقدند که اوراکل قصد دارد با اين کار نرم‌افزار MySQL ، محبوب‌ترين بانک اطلاعاتي در صنعت اپن سورس را به زمين بزند.

 

 

نرم‌افزار MySQL‌ يکي از ارکان پلاتفرم نرم‌افزاري ترکيبي موسوم به LAMP است که از اين بانک اطلاعاتي به همراه سيستم‌عامل لينوکس، آپاچي و PHP تشکيل شده است.

برخي صاحب‌نظران مي‌گويند شرکت اوراکل با اين فرض که بخش عمده‌اي از رويکرد کاربران سراسر دنيا به نرم‌افزارهاي اپن سورس ناشي از توجه آنان به مقوله قيمت پايين اين نرم‌افزارهاست و مساله باز بودن کد منبع آنها برايشان اهيمت کمتري دارد، نرم‌افزار ORACLE 10g Express Edition را رايگان کرده است ولي از بازکردن سورس کد آن اجتناب کرده است تا کسب‌وکار غير اپن سورسي خود را کماکان پررونق نگه دارد.

سخنگوي MySQL در واکنش به اين خبر گفت: بيشتر کاربران از نرم‌افزارها و نسخه‌هايي که داراي محدوديت هستند خوششان نمي‌آيد و دنبال نرم‌افزارهاي Full Edition مانند نسخه پنجم بانک اطلاعاتي MySQL هستند.

 

همچنين پاول بيچ، يک مدير پروژه اپن سورسي Firebird در اين زمينه گفت: نسخه Express اوراکل قابل رقابت با نرم‌افزارهاي بانک اطلاعاتي اپن سورسي همچون Firebird و PostgreSQL نيست.

 

يک برنامه‌نويس علاقه‌مند به PostgreSQL در گفتگو با رسانه ZDNet به کاربران صنعت اپن سورس هشدار داد که گول اوراکل را نخورند زيرا نسخه 8.1 برنامه PostgreSQL که تا چند روز ديگر به بازار مي‌آيد قادر است چندين گيگا بايت و حداکثر 8 پردازنده را پشتيباني کند.

 

گروهي از ناظران با يادآوري وجود شبکه عظيم بين‌المللي فروش نرم‌افزار اوراکل، نسبت به دست‌کم گرفتن قدرت بخش بازاريابي شرکت اوراکل از سوي کاربران اپن سورس هشدار دادند و خواستار تقويت بازار نرم‌افزارهاي اپن سورس در عرصه بانک‌هاي اطلاعاتي شدند.

 

راهكارهايي براي‌ افزايش سرعت در بانك‌هاي اطلاعاتي SQL Server

 

شايد بعضي از شما تاكنون دست‌اندركار يكي دو پروژه مبتني بر بانك‌هاي اطلاعاتي بوده‌ايد و يا اكنون با چنين پروژه‌هايي سروكار داريد. اگر تجربه كار در محيط‌هاي متوسط (مثلاً با يكصد كاربر) يا بزرگ‌ را نيز داشته باشيد، قطعاً با مسائل و مشكلات مربوط به كاهش سرعت ناشي از افزايش تعداد كاربران يا حجم پردازشي آن‌ها مواجه شده‌ايد. اين مقاله با استناد به منابع مايكروسافتي، راهكارهايي را براي بهبود سرعت و كارايي سيستم در بانك‌هاي اطلاعاتي با تعداد كاربر و حجم پردازش زياد مورد بررسي قرار مي‌دهد. شايان ذكر است كه در تمامي نمونه‌هاي مورد اشاره، بانك‌هاي اطلاعاتي مبتني بر محصول مايكروسافت يعني SQL Server2000 مدنظر قرار گرفته است. طبق بررسي‌هايي كه كارشناسان مايكروسافت انجام داده‌اند، كارايي يك سيستم بانك اطلاعاتي به پنج عامل مختلف بستگي دارد كه به ترتيب اهميت عبارتند از: برنامه نوشته شده، پايگاه داده موردنظر، سخت‌افزار سرور يا كلاينت، تنظيمات و نسخه مورد استفاده SQL Server و سيستم‌عامل ويندوز. همان‌طور كه حتماً مي‌بينيد، ساختار پايگاه داده، براي كارايي سيستم، در رتبه دوم اهميت قرار‌دارد. بنابراين ايجاب مي‌كند كه در زمان تحليل و طراحي سيستم، به‌صورت ويژه‌ به بانك اطلاعاتي در‌حال ساخت توجه شود و رابطه بين اين بانك و برنامه‌هاي كاربردي و همچنين رابطه بين اجزاي مختلف درون بانك، به بهترين شكل ممكن طراحي و پياده‌سازي شود.

توسعه  :
به‌طور كلي براي افزايش سرعت يك بانك اطلاعاتي مي‌توان به دو روش اقدام كرد. در واقع پنج عامل مورد اشاره در بالا‌، به دو دسته طولي و عرضي تقسيم‌بندي مي‌شوند. در توسعه طولي كه در اصطلاح انگليسي به Scalp up نيز شناخته مي‌شود، مدير سيستم با صرف هزينه‌، به ارتقاي سخت‌افزار (مثل پردازنده‌ها يا هاردديسك‌ها) يا به‌طوركلي ايجاد شبكه‌اي سريع‌تر اقدام مي‌نمايد يا مثلاً سيستم‌عامل خود را به نسخه‌اي جديدتر و پايدارتر ارتقا مي‌دهد. اما در روش عرضي (Scale out) تقريباً با حفظ همان سخت‌افزار و ساختار شبكه، به بهينه‌سازي روابط موجود ميان عناصر دخيل در سرعت مثل برنامه‌هاي كاربردي، بانك اطلاعاتي و سرور اقدام مي‌كند.

توسعه طولي (Scale up)  :
هدف اين مقاله پرداختن به توسعه عرضي براي بهره‌برداري بهينه از امكانات موجود است. اما قبل از آن، جادارد به‌صورت خلا‌صه و فهرست‌وار به توسعه طولي و راه‌حل‌هاي آن نيز پرداخته شود تا زمينه براي بررسي‌هاي بيشتر در آينده فراهم گردد.

راه‌حل يكم: افزايش حافظه مورد استفاده
SQL Server از يك به سه گيگابايت. اين كار را بايد با دستكاري در فايلBoot.ini سرور 2000 يا 2003 كه SQL Server در آنجا قرار دارد، انجام دهيد. براي اطلاع از چگونگي انجام‌دادن اين كار، به سايت پشتيباني مايكروسافت رجوع كنيد نشاني(http://support.microsoft.com) و در آنجا عبارت AWE SQLServer را جستجو كنيد تا مقالاتي كه در اين زمينه وجود دارد، در دسترس شما قرار گيرد.

راه‌حل دوم: ارتقاي سيستم‌عامل ويندوز 2000 به 2003 كه در فرايند
caching، سيستم‌عاملي پايدارتر و هوشمندتر قلمداد مي‌شود.

راه‌حل سوم: استفاده از پردازنده‌هاي
Xeon به جاي پنتيوم 4 در سرور. اين پردازنده‌ها به دليل ويژگيhyper threading، مي‌توانند سرعت پردازش اطلاعات در سمت سرور را به دو برابر افزايش دهند.

راه‌حل چهارم: هاردديسك‌هاي اسكازي با 15‌هزار دور در دقيقه و سرعت سه مگابيت در ثانيه و يا
Sata با 10‌هزار دور در دقيقه و دو مگابيت در ثانيه نسبت به هاردديسك‌هاي IDE با 7500 دور در دقيقه و يك مگابيت در ثانيه از عملكرد بهتري برخوردارند.پس درصورت امكان، از اين ادوات ذخيره‌سازي در سرور بانك اطلا‌عاتي استفاده كنيد.

 راه‌حل پنجم: جداسازي محل ذخيره فايل‌هاي داده‌اي بانك اطلاعاتي (mdf) و فايل‌هاي لاگ (ldf) برروي دو هاردديسك مختلف يا دو ديسك مختلف از يك RAID. معمولاً براي نگهداري mdf استفاده از RAID1 و براي ldf  استفاده از RAID5 توصيه مي‌شود.

با جداسازي اين فايل‌ها از يكديگر، عمل ايجاد لاگ، وقفه‌اي در خواندن و نوشتن اطلاعات بر روي هاردديسكي كه حاوي فايل‌هاي داده‌اي
mdf است، ايجاد نمي‌كند.

راه‌حل ششم: راه‌حل آخر و در واقع مشكل‌ترين راه، تقسيم بانك اطلاعاتي (در صورت لزوم) به دو بانك جدا از هم و بر روي دو سرور مختلف است. به عنوان مثال، فرض كنيد كه عمليات روزانه سيستم شما به دو دسته تقسيم مي‌شود: دسته يكم عملياتي است كه طي آن بايد از آخرين اطلاعات موجود بر روي سيستم استفاده شود و هرگونه تغيير نيز بايد فوراً
  در همان لحظه بر روي بانك سيستم‌ها (جداول مربوط به آن‌ها كه به
online transactional Processing) OLTP) مشهورند،) اعمال شود.

دسته دوم نيز شامل عملياتي است كه طي آن مي‌توان از اطلاعات چند ساعت يا چند روز پيش نيز استفاده كرد و لزومي به داشتن آخرين اطلاعات به صورت لحظه‌اي نيست. به عنوان نمونه فرض كنيد تعدادي از گزارش‌هاي سيستم مربوط به تحليل آماري فرايندهاي مختلف ماه پيش است. بنابراين بايد تمهيداتي انديشيده شود تا تهيه اين گزارش‌ها -كه البته ارزش آني ندارند، اما به دليل بازه زماني و نوع تحليل آن‌ها، منابع زيادي از سيستم براي خواندن اطلاعات انبوه و تجزيه و تحليل صرف مي‌شود، بايد بر روي سرور دومي در شبكه كه به
سيستم‌هاي
online Analytical Processing) OLAP) مشهورند قرار گيرند تا در كار كساني كه مشغول  كار با OLTP  هستند، خللي ايجاد نشود.

بنابراين سرور دومي را در شبكه در نظر بگيريد و كپي بانك اطلاعاتي موجود در سرور اول را به سرور دوم انتقال دهيد. سپس با استفاده از روش
Replication سيستم را طوري تنظيم كنيد تا در مواقع خلوت‌بودن ترافيك سيستم (مثلاً نيمه شب) اطلاعات Upgrade شده آن روز را از سرور اول به سرور دوم كپي كند. كليه برنامه‌هايي كه با OLAP  كار مي‌كنند را به بانك مشابه، اما با آدرس سرور دوم ارجاع دهيد.
 
براي كسب اطلاعات بيشتر در زمينه نحوه انجام‌دادن
Replication، عبارت مذكور را در سايت ماهنامه شبكه جستجو كنيد. تا به مقالا‌تي در اين زمينه دست پيدا كنيد.

2-1-6 توسعه عرضي (Scale out)  :

نام خانوادگي

نام

شماره تامين اجتماعي بيمه شده

شماره سريال بيمه شده

ب

الف

ايندكس خوشه‌اي يا خاصيت منحصر به فرد

كليد اوليه ايندكس غيرخوشه‌اي

راه‌هاي موجود در توسعه عرضي در واقع سريع‌ترين راه‌حل‌هاي افزايش سرعت در بانك‌هاي اطلاعاتي را تشكيل مي‌دهند. برخي از اين راه‌ها فقط با يك بار استفاده، اثر دايمي خود را روي سيستم به جا مي‌گذارند. اما برخي ديگر بايد به عنوان يك الگوي دوره‌اي در مراحل زماني مناسب ازسوي مدير سيستم اجرا شود. اين راه‌ها در واقع جزئي از دستورالعمل‌هاي نگهداري و پشتيباني سيستم محسوب مي‌شوند. در ادامه  به بررسي آن‌ها مي‌پردازيم:
1 - از ساخت جداولي كه فاقد كليد اوليه (
Primary key) باشند، خودداري كنيد. كليد اوليه علاوه بر جلوگيري از  ورود اشتباه اطلاعات از سوي كاربر، به دليل داشتن خاصيت منحصر به‌فرد بودن (Unique) به سريع‌تر پيدا‌شدن ركورد موردنظر از همان جدول كمك شاياني مي‌كند. تا آنجا كه براي سيستم امكان دارد براي كليد اوليه از فيلدهاي عددي استفاده كنيد.
استفاده از فيلدهاي رشته‌اي (
string) مثلchar ياvarchar به‌عنوان كليد اوليه، كمي كندتر از فيلدهاي عددي است. از انتخاب فيلدهاي رشته‌اي با طول زياد و يا فيلدهايي مثل Memo ،Text و Picture به عنوان كليد اوليه نيز اجتناب كنيد.

2 - تمام كليدهاي خارجي (
Foreign key) قابل تعريف در بانك را تعريف كنيد. وجود كليدهاي خارجي نيز علاوه بر جلوگيري از اشتباه كاربر در واردكردن يا حذف اطلاعات، موجب مي‌شود هنگام لينك شدن (join) جداول مادر و فرزند از طريق كليدهاي خارجي، سيستم سرعت بيشتري را در انجام دستورات Select شما از خود نشان دهند.

3 - همان‌طور كه مي‌دانيد ايندكس‌ها در دو نوع خوشه‌اي (
cluster) و غيرخوشه‌اي (Non cluster) قابل ساخت هستند. ايندكس‌ها باعث افزايش سرعت خواندن اطلاعات به‌وسيله دستور Select مي‌شوند.
ما تعريف بي‌رويه آن‌ها در سيستم نيز باعث كاهش سرعت اجراي دستورات فرايندي مثل
Insert ،Update و Delete  مي‌شود. بنابراين سعي كنيد ايندكس‌هاي ضروري را در سيستم تعريف كنيد. اما در اين راه دست و دلبازي بي‌مورد از خود نشان ندهيد. به عنوان مثال، فرض كنيد در يك شعبه اداره تأمين اجتماعي، جدولي ويژه تعريف بيمه‌شدگان به شكل زير وجود دارد.  

 

مبلغ

تاريخ

شماره سريال

1

جزء دوم كليد اوليه

جزء اول كليد اوليه

1

 

كليد خارجي از جدول قبل

1

جزئي از ايندكس خوشه اي

جزئي از ايندكس خوشه اي

جدولي نيز براي نگهداري وجه حق بيمه از بيمه‌شدگان نيز تعريف شده است.

همان‌طور كه مشاهده مي‌كنيد، ايندكس نوع خوشه‌اي به فيلدي داده شده كه نسبت به بقيه فيلدها در يك جدول كاربرد بيشتري دارد. چرا كه اين نوع ايندكس نسبت به نوع غيرخوشه‌اي سرعت بيشتري دارد. در ضمن در هر جدول از بانك اطلاعاتي شما فقط قادر به تعريف يك ايندكس خوشه‌اي هستيد كه انتخاب فيلد آن اهميت زيادي دارد. بنابراين لزومي ندارد فيلدي كه كليد اوليه است، حتماً به عنوان ايندكس خوشه‌اي انتخاب شود.

نكته مهم ديگر اين است كه لا‌زم است تمام كليدهاي اوليه جداول ايندكس داراي باشند (خوشه‌اي يا غيرخوشه‌اي) نكته ديگر در زمان ساخت ايندكس‌ها فاكتور پرشدن (
Fill Factor) آن‌ها است. اين فاكتور در واقع بيانگر ميزان فضاي مياني است كه بايد براي ركوردهايي كه در آينده درج يا حذف مي‌شوند، خالي نگه داشته شود. بنابراين اگر احساس مي‌كنيد جدول شما به‌طور مداوم مورد عمليات حذف و درج (Insert،‌Delete) قرار مي‌گيرد، اين فاكتور را پايين (مثلاً 30 درصد) انتخاب كنيد. اما اگر صرفاً عمليات درج بر روي يك جدول انجام مي‌گيرد و ميزان حذف اطلاعات از آن بسيار كم است، مي‌توانيد اين ميزان را به ارقام بالاتر مثلاً 90 درصد افزايش دهيد. زيرا اين نوع جداول نيازي به داشتن فضاي خالي مياني براي ركوردهايي كه در آينده جانشين ركوردهاي حذف شده مي‌شوند، ندارد.

اين مسئله براي ايندكس‌هايي كه برروي ديدها (
Indexed Views) ساخته مي‌شوند نيز صادق است. به‌طوركلي گذاشتن ايندكس برروي ديدها به افزايش سرعت آن‌ها كمك مي‌كند. در اين حالت، كليه مطالب مذكور از جمله سياست استفاده از ايندكس‌هاي خوشه‌اي و غيرخوشه‌اي و همچنينFill Factor در جداول، در مورد ديدها نيز عيناً بايد رعايت گردد.

4 - در هنگام نوشتن دستورات
Select يا در هنگام ساختن ديدها، از استفاده بي‌مورد از پارامترهاي پردازش مثلDistinct و LIKE order by و لينك‌هاي خارجي (Outer join) اجتناب كنيد. در صورت استفاده از اين پارامترها، مطمئن باشيد كه گذاشتن آن‌ها كاملاً ضروري است و چاره ديگري نداريد.

5 - از واگذاري پردازش‌هاي رياضي يا آماري سنگين و مداوم به سرور بانك اطلاعاتي بپرهيزيد. مثلا‌ً به دستور زير نگاهي بيندازيد.

SELECT( a*( b+c )) +( d* E+F))  %G/H From ... WHERE ...


به‌جاي اين‌كار، مي‌توانيد ابتدا با استفاده از يك
Select معمولي مثل Select a ,b ,c ,d ,E ,F ,G ,h  فيلدهاي موردنظر را در حافظه كلاينت لود كنيد و سپس عمليات رياضي مذكور را در همان جا انجام دهيد. با اين كار پردازشي كه سرور بايد مثلاً براي 50 كلاينت در عرض چند دقيقه انجام دهد، بين آن 50 كلاينت تقسيم مي‌شود و در واقع هر كلاينت فقط سهم پردازشي مربوط به خود را انجام مي‌دهد.

6 - گاهي عمل اجتماع بين دو
Select  توسط دستور Union به شدت بر عملكرد و سرعت سيستم اثر منفي مي‌گذارد. بنابراين در صورت امكان به جاي استفاده از روش مذكور، از روش‌هاي ديگري كه هدفتان را برآورده نمايد، استفاده كنيد.

7 - سعي نماييد فيلدهايي كه از نظر مقدار و ارزش با يكديگر مقايسه مي‌شوند، از يك جنس (
type) باشند. در غير اين‌صورت سيستم‌مجبور مي‌شود به طور ضمني، عمل تبديل داده را انجام دهد كه كمي برايش وقت‌گير است. به مثال زير توجه كنيد و فرض بگيريد فيلد customer ID در جدول customers از جنس nchar تعريف شده است. 

Declare@custID char (5)
Set @ CustID =' FDLKO'
Select * From Customers where customerID=@custID


8 - تاحد ممكن از به كار بردن توابع (چه پيش ساخته توسط
SQL Server و چه ساخته شده توسط كاربر) در قسمت WHERE يا order by اجتناب كنيد. مثال زير نمونه‌اي از اين مورد است:

Select * Form orders Where DateAdd (Day, 15, orderdata) = '2005/23/07'


9 - در زمان نوشتن تريگر (
trigger) بر روي جداول يك بانك اطلاعاتي، از نوشتن تعداد زيادي دستورالعمل در آن‌ها خودداري كنيد. به عبارت ديگر تريگرها را تا حد امكان كوتاه كنيد و دستورالعمل‌ پياد‌ه‌سازي آن‌ها را كم نماييد.
10 - در زمان ساخت كرسر (
cursor) درون توابع، روال‌ها و تريگرها از پارامترهاي Forward only يا read only و همچنين local استفاده كنيد تا SQL Server با دانستن اين نكته كه شما قصد تغيير داده‌ها در كرسر موردنظر را نداريد، تغيير يافتني بودن آن‌ها را درنظر نگيرد و آن را براي شما سريع‌تر بسازد.

11 - در صورتي كه تكه‌اي از برنامه شما به ساخت يك جدول موقت (
temporary table) نياز دارد، اين كار بايد با ظرافت خاصي صورت بگيرد. اصولا SQL Server براي اجتناب برنامه‌نويسان از ساخت جداول موقت، از يك نوع داده(Data type) خاص به نام Table پشتيباني مي‌كند كه مزيت استفاده از آن اين است كه به‌جاي هاردديسك، در حافظه رم قرارگرفته است و در نتيجه نسبت به جداول موقت سرعت بيشتري دارد.

اما به ياد داشته باشيد كه استفاده بي‌رويه از اين نوع داده، حافظه زيادي را صرف مي‌كند كه مي‌تواند باعث كاهش كارايي سيستم شود. بنابراين اگر احساس مي‌كنيد تعداد جداول موقت، ركوردهاي آن‌ها و زمان استفاده از آن‌ها كم است، از اين نوع داده استفاده كنيد. در غير اين‌صورت، راه‌حل جدول موقت را انتخاب كنيد.
 
12-
  قفل‌گذاري بر روي ركوردهايي كه در حال خواندن، درج شدن، حذف شدن يا تغيير كردن هستند، هميشه از مباحث مهم بانك‌هاي اطلاعاتي بوده‌است. همان‌طور‌كه مي‌دانيد يك فرايند (Transaction) شامل يك يا چند دستورالعمل SQL است كه يا بايد همگي به صورت موفقيت‌آميز اجرا شوند (committed) يا در صورت ايجاد خطا در زمان اجراشدن يكي، اجراي بقيه نيز منتفي شود (Rollbacked).

فرايند به دو صورت قابل پياده‌سازي است. اين كار يا با استفاده از دستورات Begin trans و Committrans انجام مي‌شود كه به آن حالت صريح (Explicit) مي‌گويند يا به صورت ضمني (Implicit) صورت مي‌گيرد كه در آن اثري از دو دستور مذكور ديده نمي‌شود و هر دستور SQL يك فرايند مجزا به حساب مي‌آيد. در هر دو روش ركوردهايي كه تحت‌تأثير دامنه فرايند قرار مي‌گيرند، توسط سيستم قفل مي‌گردند و براي ديگر كاربران نيز غيرقابل استفاده مي‌شوند و در نتيجه باعث كاهش سرعت كار آن‌ها به دليل ايجاد انتظار براي آزاد شدن ركوردها مي‌شود.
 
بنابراين براي رسيدن به حداكثر كارايي سيستم، بايد از ايجاد قفل‌هاي بي‌مورد بر روي ركوردهاي جداول بانك اطلاعاتي جلوگيري كرد. اين كار با استفاده از دستور
SET Transaction Isolation Level Read Uncommitted براي فرايندهاي صريح (قبل از شروع فرايند، يعني قبل از دستور (begin Trans  و يا استفاده از دستور WITH NOLOCK  براي فرايندهاي ضمني (پس از قسمت From هر دستور SQL) قابل انجام است. در مورد مسئله فرايندها و انواع قفل‌گذاري مطالب خواندني زيادي در سايت مايكروسافت وجود دارد كه درصورت تمايل مي‌توانيد به آن‌ها نيز مراجعه كنيد.

13 - روال‌هاي ذخيره شده (
stored Procedures) پس از هر اجرا، به ازاي هر دستورالعملي كه اجرا مي‌كنند،  جهت اطلاع برنامه فراخوان (كلاينت) از موفقيت‌آميز بودن اجراي آن دستور SQL، پيغامي را به سمت آن برنامه مي‌فرستند. اين مسئله باعث افزايش ترافيك شبكه در اثر فرستادن مداوم پيغام ازSP به سمت كاربر مي‌شود. با تايپ دستور زير در ابتداي يكSP، مي‌توانيد آن را از انجام اين كار منع كنيد:
SET NOCOUNT ON



نتيجه‌گيري‌:


مطالب فوق تنها قسمتي از راهكارهاي قابل انجام براي رسيدن به‌سرعت و بازدهي مناسب در بانك‌هاي اطلا‌عاتي مبتني بر
SQL Server است. در ضمن‌ بايد اين نكته را هم درنظر داشت كه اصولا‌ً در سيستم‌هاي بزرگ اطلا‌عاتي تحت شبكه، توپولوژي و نوع اجزاي موجود در شبكه از اهميت بسيار زيادي در تعيين سطح كارايي يك بانك اطلا‌عاتي برخورداراست. گاهي حتي در حالي‌كه بهترين طراحي و پيكربندي SQL Server براي يك بانك اطلا‌عاتي انجام شده، يك اشتباه كوچك در سطح شبكه مي‌تواند تمام زحمات را بر ‌باد دهد يا مثلا‌ً يك سهل‌انگاري در نوشتن روال‌هاي ذخيره شده يا تريگرها مي‌تواند سيستم را به‌يك لوپ (Loop) پردازشي بي‌نهايت ببرد و باعث افت شديد سرعت اجراي برنامه‌ها شود. بنابراين در اين‌گونه سيستم‌ها، استفاده بجا و مناسب از منابع سيستم و شبكه و دقت در طراحي و پياده‌سازي جداول، ديدها، روال‌هاي ذخيره‌شده و تريگرها بسيار مهم  و حياتي است.

ده اشتباهي كه نبايد در نوشتن پرس‌وجوي بانك اطلاعاتي مرتكب شد

برنامه‌نويسان پايگاه داده، عموما در نوشتن پرس‌و‌جو‌ها دچار اشتباهات ساده‌اي مي‌شوند كه اجتناب از آنها مي‌تواند كارآيي كلي برنامه و سرعت پاسخ‌گويي را افزايش دهد.
با دقت اين نكات را بخوانيد تا مطمئن شويد كه قرباني اين اشتباهات نشده‌ايد و نخواهيد شد.

 

با توجه به رشد سریع و روزافزون حجم داده‌ها در پایگاه داده‌های SQL Server و انتظار كاربران براي سرعت پاسخ‌دهي دهم‌ثانيه‌اي سيستم‌ها، این مساله مهم پیش رو قرار مي‌گيرد كه باید از نوشتن پرس‌وجوهای[1] ضعیف دوري كرد. در مقاله حاضر ده خطاي متداول مربوط به نوشتن پرس‌وجو را مطرح می‌كنیم تا با به‌كارگیری آنها از خطري كه در كمين پرس‌وجوهاست اجتناب كنيد. با دقت مطالب زیر را بررسی كنید تا مطمئن شوید كه قربانی این اشتباهات نشده‌اید و برای اصلاح پرس‌وجوی خود نیز این توصیه‌ها را به كار ببندید.

 

 

1- مدل داده‌ها و پرس‌وجوهای بعدی

اگر زمانی كه مشغول ساخت مدل داده‌ها[2] هستید درباره چگونگی دسترسی به داده‌ها فكر نكنید، ممكن است نتيجه كار پرس‌وجویی بدفرم و سنگين شود. این مساله ممكن است باعث به وجود آمدن JOINهاي غیرضروری شود كه كد را بیش از اندازه پیچیده می‌كند و به اجرای برنامه صدمه می‌زند.

برای اصلاح این مساله به پرس‌وجوهایی فكر كنید كه برای دسترسی به داده‌ها مورد نیاز می‌باشند. اگر نحوه دسترسي در این مرحله از فرآیند پرس‌وجو واضح نباشد، اين مساله باعث سخت‌تر شدن كد و در نتيجه، پیچیده‌تر شدن طراحی پايگاه داده خواهد شد. در اين صورت بايد به اصلاح و ساده‌سازي پرس‌وجو پرداخت.

در ارتباط با این نكته، اگر فردی هستید كه با ديدن بهتر مي‌توانيد مسايل را درك كنيد، حتما مدل داده‌ها را چاپ كنید یا مدل خود را در ابزار مدل‌سازی داده‌هاي مورد استفاده خود مرور كنید.

 

2- بهترین تكنیك‌ها كدام‌اند؟

بحث بر سر استفاده از cursor يا منطق مبتني بر set[3] است. عقل سلیم حكم مي‌كند كه برای دسترسی به تمام داده‌ها از منطق مبتني بر set استفاده شود. من نیز این مساله را عنوان يك قانون كلي مي‌پذيرم. استفاده از cursor وقتي كه منطق مبتني بر set انتخاب درستی می‌باشد، كارآيي پرس‌وجوها را نيز قرباني مي‌كند. SQL Server برای منطق مبتني بر set طراحی شده است و باید در بیشتر مراحل پردازش داده‌ها از اين روش استفاده شود.

البته، نمونه‌هاي خوبي مربوط به cursor را در اين پيوند مي‌توانيد ببينيد. در این وضعیت منطق مربوط به cursor نسبت به منطق مبتني بر set بهتر كار می‌كند. نتيجه اين كه ، از این اطلاعات برای تعیین نوع پردازشی كه در حال اجرا است و برای انتخاب بهترین تكنیك مورد نیاز استفاده كنيد.

 

3- هنوز به روش قدیمی كار مي‌كنيد؟

SQL Server 2005 مجموعه‌ای كامل و جدید از فرصت‌ها را برای پرس‌وجو فراهم می‌كند. البته، هنوز مي‌توان شیوه‌هاي قدیمی را به كار بست، اما زمان آن فرارسیده تا از آخرین امكانات بهره ببريم. روش مديريت خطا با TRY…CATCH یكی از اولین تكنیك‌هايي است كه باید در كد خود به كار ببندید. موارد دیگری كه باید در نظر بگیرید common table expressions است كه با سلسله مراتب به كار گرفته می‌شود. مورد آخر این است كه باید قابلیت‌های موتور پایگاه داده را با استفاده از CLR توسعه دهید. این سه تكنیك به طرز چشم‌گيري روش كار شما با Server SQL را تغيير مي‌دهند و این خود نكته‌ای است كه بحث مفصل‌تری را می‌طلبد.

 

4- آیا به اینجا نگاهی انداخته‌اید؟

قبل از به‌كارگیری كد حتما از فرد ديگري بخواهيد آن را به‌دقت مرور كند. مرور كد و به‌خصوص نقشه پرس‌وجو[4] برای اطمینان از به‌كارگیری شاخص‌های صحیح ضروری می‌باشد. چنین پرس‌وجوی مرورشده‌اي، معمولا، همان طور كه انتظار می‌رود اجرا خواهد شد.

 

نكته این جاست كه یكی از ساده‌ترین ابزارها برای اطمینان از صحت كد لزوم بازبینی آن توسط شخص دیگری است. این روش می‌تواند هم برای برنامه‌نویس و هم برای همكار او تجربه‌ای باشد تا با چگونگی مواجهه با چنين مسايلي توسط برنامه‌نویسان دیگر و مدير پايگاه داده[5] آشنا شوند. این روش را می‌توان به عنوان ابزاری برای مبادله ایده‌ها و اصلاح مهارت‌های یكدیگر به كار بست.

 

5- يك اشتباه كلاسيك

نوشتن يك عبارت SELECT * با این گمان كه تغییری در جدول ایجاد نخواهد شد، اشتباهی قدیمی است. حتی در ساده‌ترین شرایط نیز جدول ممكن است بناچار تغییر كند و این مساله مرور كد را برای اطمینان از نبود ستون‌های اضافی ایجاب می‌نمايد. وضعيت بدتر این است كه منتظر وقفه یا اشكالی در برنامه شوید و بعد به تصحيح آن بپردازید. بهترین كاری كه می‌توان انجام داد گنجاندن ستون‌هایی است كه در پرس‌وجو مورد نیاز هستند و تنها تغییر همان ستون‌ها در صورت  بوجود آمدن تغيير.

روز خود را با جستجو در كد، همانند فردي بي‌خانمان كه در خرابه‌هاي يك ساختان جستجو مي‌كند خراب نكنيد.

 

6- هیچ توضیحی  نمي‌نويسم!

متاسفانه اكثر كدهایی كه نوشته می‌شود، یا توضیح كمی دارند و یا اصلا در آنها از توضيح استفاده نشده است با اين شرايط اعمال تغییرات حتی براي برنامه‌نویس يا مدير پايگاه داده‌اي كه برنامه را نوشته‌اند كاري بسيار سخت(ترسناك) خواهد بود[6]. نوشتن توضیح برای كد حقیقتا فرآیندی است سریع و بی‌زحمت كه برای درك و تغییر كد به شیوه‌ای امن و مناسب برای برنامه‌نویساني كه در آینده با كد سروكار خواهند داشت، امری ضروری می‌باشد. (ر.ك. مقاله چطور توضيحات و كد پاكيزه بنويسيم)

 

7- حتما، آن را تست خواهم كرد!

برنامه‌نویسان و مديران پايگاه داده غالبا طرف‌دار آزمون‌هاي ساده هستند و آزمون‌هاي سخت را قبل از انتشار كد برای محیط تولید به كار نمی‌برند. علاوه بر اين، در زمان توليد نرم‌افزار داده‌هايي كه بوجود مي‌آيند به هيج‌عنوان به پای محیط‌های استفاده و كاربري نمی‌رسند. می‌توان گفت كه پرس‌وجوهای ساده با صدها یا حتی هزاران ركورد نیز به خوبی كار می‌كنند اما در مرحله كاربري به اين صورت نخواهد بود. هیچ راهي بهتر از این كه كد خود را در محیط آزمایش در برابر ميلیون‌ها ركورد در جداول پراكنده شده[7] آزمایش كنید، وجود ندارد. این كار باعث حصول اطمینان از عملكرد مورد انتظار از پرس‌وجو می‌شود.

 

8- آن را به من بده، جدي مي‌گويم!

نوشتن يك عبارات SELECT بدون شرط WHERE و انتظار از لايه مياني يا انتهايي برنامه كاربردي[8] برای پردازش داده به شیوه‌ای كارآمدتر از SQL Server اشتباه محض می‌باشد. SQL Server برای فرآیند جستجو طراحی شده است و این كار را به شیوه‌ای بسیار كارآمد انجام می‌دهد. انتقال مجموعه‌ای بزرگ از داده‌ها تنها باعث جلوگیری از عملكرد كارآمد سیستم و شبكه می‌شود و حتي آن را تا مرحله اشباع می‌كشاند. از فیلتر شدن مجموعه داده‌هاي‌تان، تا جایی كه ممكن است، اطمینان حاصل نمایید. این كار باعث جلوگیری از تبعات اجرایی می‌شود.

 

9- از view استفاده كنيد!

دیدها نیاز به ساده كردن كد را برای پرس‌وجوهای پیچیده برآورده می‌كنند. دیدها اغلب برای كمك به كاربران حرفه‌ای برای پرس‌وجوی پایگاه داده‌ها به كار می‌روند. متاسفانه استفاده بیش از حد از یك چیز خوب می‌تواند منجر به تاثیرات مخرب شود. دید فقط یك عبارت SELECT است و عبارت SELECTمربوط به آن زماني كه ديد را اجرا مي‌كنيد، اجرا مي‌شود. استفاده از دیدها را محدود و از ايجاد ديد‌هاي تودرتو خودداري كنید. بسياري از مواقع مي‌توانيد با يك رویه ذخيره‌شده[9] كه به آن  پارامترهای مورد نیاز را ارسال كرده‌ايد به نتيجه دلخواه دست يابيد.

 

10- نه! ، من اين كد را ننوشته‌ام.

ما همه مسلما اشتباه می‌كنیم. اين موضوع بسيار بديهيست كه  آخرین سیستمی كه روی آن كار كرده‌ايم از اندوخته‌های پروژه‌‌ جاري‌مان بهره‌مند شده است. بنابراین آموخته‌هاي‌تان را يادداشت كنید تا با دیگر اعضای تیم به اشتراك بگذارید. هر زمان كه مجالی به دست آوردید به سیستم‌های قبلی بازگردید و با دانش‌هاي جديد كه كسب كرده‌ايد آنان را بهبود بخشيد.

 

 

نتیجه:

 

اگر در مورد پرس‌وجوهاي‌تان مرتكب يكي از این اشتباهات شدید، آن را تشخیص دهید و برای رفع آن تلاش كنید. البته، حرف زدن از عمل كردن ساده‌تر است، اما تصحیح اشتباه سازمان را منتفع و اعتبار برنامه را بيشتر می‌كند. به عنوان نتيجه‌گيري عملي از اين مقاله، شروع به ساخت راهنمای شخصی براي برنامه‌نويسي كنید تا از آن برای پروژه‌های جاری و آینده‌تان استفاده نماييد.

 

 

بانك‌هاي اطلاعاتي بسيار بزرگ، دي‌بي2 يا آداباس

 

 

مقدمه فصل :

وقتي كه تعداد سطرها يا ركوردهاي يك جدول يا فايل از چند صد ميليون يا چندين ميليارد تجاوز كند، يا وقتي كه تعداد مراجعه به يك بانك اطلاعاتي از چند صد مورد در ثانيه تجاوز كند، در ايران، ما احتياج به يك مين‌فريم (MainFreame) معمولي آي‌بي‌ام با سيستم عامل او-اس-390 و بانك اطلاعات دي‌بي2 (DB2) داريم. رقيب قبلي دي‌بي2 عبارت از بانك اطلاعات آداباس(ADABAS) از شركت سافت‌وير اي‌جي (Software AG) بود كه با توجه قيمت زياد، عدم پشتيباني مناسب و اجبار به داشتن ليسانس نرم افزاري، در حال حاضر تا حد زيادي متروك مانده است. اگر چه به صورت موردي و خاص بانك اطلاعات اراكل و سوپرا براي مين‌فريم نيز در سازماني يافت مي‌شود، اما از دور رقابت خارج شده و طالب چنداني ندارند. اين مقاله به نقاط ضعف و قوت اين دو محصول، براي آنهايي كه هنوز شكي در دل دارند مي‌پردازد. اگر تصميم خود را گرفته‌ايد، از همين جا مقاله را رها كرده و ادامه ندهيد.


پس ادامه مي‌دهيم. محصول دي‌بي2 را در حال حاضر 3 شركت مبنا، خدمات انفورماتيك و شركت داده‌پردازي ايران، ارايه و پشتيباني مي‌نمايند. به نظر ما شركت داده‌پردازي ايران از هر نظر و با فاصله بسيار زياد، بهتر از ديگران است. دي‌بي2 به ده‌ها شركت، وزارت‌خانه و بانك فروخته شده است. بانك اطلاعات آداباس، به شركت واحد اتوبوس‌راني، فولاد مباركه، وزارت دارايي و بانك مركزي ايران از طرق مختلفي فروخته شده و اگر چه هنوز كار مي‌كند و پشتيباني مي‌شود، ولي در غير از فولاد مباركه كه داراي ليسانس مي‌باشد، ازآينده نامعلومي برخوردار است. اينك به مقايسه مختصر آنها مي‌پردازيم:



1-9 مقايسه اجمالي:

پشتيباني و نگهداري دي‌بي2 در ايران چندين سال است كه بصورت مستمر انجام مي‌گيرد و افراد زيادي نگهداري و تعمير آنرا بعهده دارند كه در كلاس‌هاي آموزشي لازم در كشور انگليس يا شركت داده پردازي ايران حضور يافته‌اند. تعداد افرادي كه با اين محصول نرافزارهاي كاربردي نوشته‌اند زياد مي‌باشد. اكثر توليد كنندگان نرم افزار بصورت كلاينت‌سرور و از طريق
ODBC كاربردهايشان را مي‌نويسند. با توجه با محصول استراتژيك آي‌بي‌ام بنام Websphere Application server، مناسب است كه كاربردها را بر روي Internet منتقل نمود تا دسترسي كاربر از طريق Internet بصورت راحت و بدون ترس از ويروس و نقاط ضعف رايانه‌هاي رايج انجام پذيرد.


پشتيباني و نگهداري
ADABAS در ايران از بدو ورود آن بصورت خيلي ضعيف ارائه شد و در حال حاضر پشتيباني مناسبي براي آن وجود ندارد. تعداد نفرات براي پشتيباني آن كم است و كاربردهايي كه از قبل با اين محصول نوشته شده است، بدون ارتقا و بهبود در حال اجرا مي‌باشند.


2-9 حق امتياز يا ليسانس نرم‌افزار:

بانك اطلاعاتي دي‌بي2 بدون ليسانس بوده و با قيمت خيلي كم در دسترس سازمانها قرار مي‌گيرد. ولي بانك اطلاعاتي آداباس با ليسانس بوده و با قيمت خيلي زياد در دسترس قرار مي‌گيرد . حدوداً يك نسخه آن بر روي محيط‌هاي او-اس-390  يا زد-او-اس (Z/OS) بيش از يك ميليون دلار قيمت دارد. محصول بدون ليسانس با پشتيباني خوب، قيمت پائين و بدون اشكال، بهتر از محصولي با ليسانس گمراه كننده، قيمت گزاف و بدون پشتيباني مي‌باشد كه با خود اشكالات عديده‌اي را به همراه مي‌آورد.


3-9 نقاط ضعف و قوت :
 
يكي از اشكالات عمده بانك اطلاعاتي ADABAS رابطه‌اي نبودن آن مي‌باشد. اين بانك اطلاعاتي از Inverted List براي دسترسي به داده‌ها استفاده مي‌نمايد و براي سازگار شدن با محيط‌هاي رابطه‌ايي مشكل عمده و جدي وجود دارد كه بايستي Data Conversion صورت پذيرد. يكي از قوت‌هاي بانك اطلاعاتي DB2 رابطه‌اي بودن آن است كه با دشواري كم مي‌تواند با بانك‌هاي اطلاعاتي رابطه‌اي روي Mainframe يا PC ارتباط برقرار نموده و براحتي به داده هاي آنها دسترسي داشته باشد.


 با توجه به نيازهاي امروزي كاربران دنيا كه نيازمند استفاده از كاربردهاي كلاينت‌سرور و تحت وب بسيار محسوس مي‌باشند. توليد اين نوع كاربردها با توجه به ذرايورهاي نوشته شده توسط آي‌بي‌ام و شركت‌هايي كه با آن همكاري مي‌نمايند، بسيار آسان و سريع مي‌باشد كه آداباس و محصولات جانبي آن داراي اين قابليت و راحتي نمي‌باشند.


به جهت اينكه
DB2 از سخت افزارهاي خود IBM همچنين از سيستم هاي عامل خود شركت IBM استفاده مي‌نمايد، داراي سرعت بسيار زياد در اجرا است و خيلي مناسب براي پردازش تعداد ركوردهاي عظيم مي‌باشد. در عوض ADABAS براي وفق دادن خود با سخت افزارها و سيتم عامل‌هاي IBM مجبور مي‌باشد كه از رابط‌هايي استفاده نمايد كه در مقام مقايسه، كندتر از مورد DB2 مي‌باشد.


نيز با توجه به امكانات سيستم عامل او-اس-390 يا زد-او-اس براي تنظيم بار و انجام عمليات موازي، مي‌توان مجموعه او-اس-390 و دي‌بي2 را تبديل به يك
Transaction Monitor قوي نموده و هزاران كاربر را به صورت همزمان به آن وصل نمود. محيط DB2 براي توليد سيستم‌هاي كاربردي، محيطي امن، آسان، قابل انعطاف و سريع است.
نتيجه گيري:
يك مين‌فريم (MainFreame) معمولي آي‌بي‌ام با سيستم عامل او-اس-390 و بانك اطلاعات دي‌بي2 (DB2) مي‌تواند بستري مناسب براي سامانه‌هاي بسيار بزرگ و عظيم سازمان‌ها، بانك‌ها، وزارت‌خانه‌ها و شركت‌هاي بزرگ ايراني باشد. اين راه حل مي‌تواند هزاران كاربر همزمان، چند صد تراكنش موازي و همزمان و چندين ميليارد قلم اطلاعاتي را پشتيباني نمايد. چون داراي ليسانس نيست، قيمت آن ارزان بوده و از پشتيباني مناسب ايراني برخوردار است. از تمام استانداردهاي روز دنيا براي توليد نرم‌افزارهاي كلاينت سرور و تحت وب، پشتيباني مي‌نمايد.

 

 

 

 

 

 

Oracle آسيب پذير تر از SQL Server

 

 

در يك مقايسه كه بين آسيب پذيري ها در پايگاه داده SQL Server مايكروسافت و اراكل انجام شد نتايج نشان مي دهد كه پايگاه داده اراكل آسيب پذير تر از همتاي مايكروسافتي خود است. اين مقايسه كه توسط گروه NGSS صورت گرفته است نشان دهنده آن است كه از دسامبر 2000 تا نوامبر 2006 ، محققين امنيتي تعداد 233 آسيب پذيري در اراكل يافته اند كه در مقابل 59 آسيب پذيري در پايگاه داده SQL Server چشمگير است. اين مقايسه در بين پايگاه داده مايكروسافت نسخه هاي 7 ، 2000 و 2005 در مقايسه با پايگاه داده اراكل نسخه هاي 8، 9 و 10g صورت گرفته است.

 

به گزارش آژانس خبری پرشین هک از Litchfield ، مؤسس NGSS ، « نتايج نشان مي دهد كه پايگاه داده SQL Server از سال 2002 اعتبار خود را بيشتر كرده است و آسيب پذيري جدي در آن ايجاد نشده است. او ادامه مي دهد : هر چند هيچكدام از اين موارد نشان دهنده اين نمي باشد كه مايكروسافت يك ره آورد امنيتي را در پيش گرفته است.»

 

Litchfield ادامه مي دهد : « من فكر مي كنم كه زمان آن شده است كه مردم به گذشته مراجعه كنند. ما بايد حتي به كاربران Outlook هم امنيت را بياموزيم و اما در بازه بزرگتر ما جنگ امنيتي با مايكروسافت را برده ايم زيرا كه مي بينيم چرخه حياط نرم افزار مايكروسافت هنوز زنده است.»

 

« در مقابل ما جنگ هاي ديگري هم داريم كه بايد در آنها موفق شويم، يكي از آنها همين اراكل است.»

 

در توضيحي كه شركت اراكل از طريق سخنگوي خود ارسال كرده ، مدعي شده است كه ميزان گزارش هاي آسيب پذيري ها در يك برنامه نشانگر امنيت پايين تر آن نيست.

او مي گويد : « هر محصولي با توجه به انواع نسخه ها، تنوع محصولي و نوع كاري كه انجام مي دهد متفاوت هستند. ميزان درجه بندي امنيتي يك محصول پيچيده تر از چند آسيب پذيري مي باشند كه در آن به چشم مي خورند. تمامي اينها مواردي هستند كه يك مشتري در نظر مي گيرد. شايد چند آسيب پذيري و عدم توجه به آنها ، ميزان سنجش خوبي براي امنيت يك محصول نباشد.»

 

لازم به ذكر است كه در اين هفته يك محقق امنيتي به نام Cesar Cerrudo به دليل بي توجهي شركت اراكل به هشدارهاي امنيتي اش، اقدام به منتشر كردن هر روز يك آسيب پذيري براي اين پايگاه داده غول پيكر كرده است. اين اقدام تا يك هفته ادامه خواهد داشت.

 

 

مروری بر ویژگی های نسخه 5.0.1 بانک اطلاعاتی MySQL

 

بانک اطلاعاتی معروف MySQL که اپن‌سورس است، طرفداران زیادی در بین برنامه‌نویسان دارد. MySQL علاوه بر آن‌که یکی از نمونه‌های بسیار موفق نرم‌افزارهای منبع باز محسوب می‌شود، مثالی از نرم‌افزاری است که در اروپا (سوئد) پا به عرصه گذاشته است. نخستین نسخه این بانک اطلاعاتی توسط دو نفر از برنامه‌نویسان سوئدی نوشته شد و از آن پس بر اساس مدل نرم‌افزارهای منبع باز توسعه یافت. البته در میانه راه (یعنی در زمان عرضه نسخه سوم این نرم‌افزار) بر اساس توافقی میان شرکت MySQL AB از یک سو و شرکت معظم SAP (که دارای خط تحقیق و توسعه بانک اطلاعاتی اختصاصی خود بود) از طرف دیگر، نسخه ویژه‌ای موسوم به MaxDB از تلفیق تکنولوژی‌های این دو شرکت در فهرست محصولات MySQL قرار گرفت. اما شرکت MySQL همچنان کار توسعه نسخه قبلی و منبع باز نرم‌افزار MySQL را تا این لحظه به موازات MaxDB ادامه داده است.


طرف‌داران فلسفه نرم‌افزار‌های منبع باز همواره از
MySQL به عنوان نمونه‌ای یاد می‌کنند که توانسته است به‌خوبی با نمونه‌های بانک‌های اطلاعاتی اختصاصی همانندSQL server که سرمایه‌گذاری‌های سنگینی برای توسعه آن انجام می‌شود، رقابت کند (هر چند که مایکروسافت بر اساس یک سیاست کلی تنها رقیب خود را در زمینه بانک‌های اطلاعاتی، محصولا‌ت اوراکل می‌داند و اصولاً توجهی به نرم‌افزارهای منبع باز نمی‌کند). اما واقعیت آن است که در دنیای برنامه‌نویسی این دو نرم‌افزار در رقابت تنگاتنگ قرار دارند.


آخرین نسخه
MySQL همراه مجموعه‌ای از قابلیت‌ها و امکانات عرضه شده است که آنرا بیش از پیش به‌سمت کاربردهای <بزرگ مقیاس> سوق می‌دهد. برخی از ناظران معتقدند هدف اولیه تغییرات و پیشرفت‌های ارائه شده در نسخه 5 این نرم‌افزار، بیش از هر چیز دیگری معطوف برنامه‌نویسی پیشرفته در کاربردهای گسترده و بزرگ است. یکی از منابع مورداستفاده در تهیه این مقاله در این زمینه چنین بیان می‌کند: <آیا زمان آن فرا رسیده است که اوراکل باز گردد و به پشت‌سر خود نگاه کند؟> جالب است که نویسنده در نوشته خود اصلاً اسمی از مایکروسافت و SQL server نیاورده است!

 

بانک‌اطلاعاتی سرور از نوع Embedded  :
اگرچه قابلیت استفاده از این بانک اطلاعاتی به صورت سرور
Embedded موضوع جدیدی محسوب ن-م-ی‌ش-ود و از نسخه 4 MySQL به بعد همواره وجودداشته است، اما این ویژگی از سوی کاربران همچنان نسبتاً ناشناخته باقی‌مانده است. استفاده از موتور نرم‌افزاری این بانک اطلاعاتی به صورت Embedded با توجه به آن‌که این نرم‌افزار از نظر توابع API به‌طور کامل با مدل Client/Server سازگاری دارد، بسیار ساده است. در واقع برای به‌کارگیری این نرم‌افزار به صورت Embedded تنها کافی است تا یک تغییر کوچک در سورس کد (نسبت به روش معمول) اعمال شود. نمونه‌ای از یک قطعه کد به زبان C (که در گوشه و کنار اینترنت به فراوانی یافت می‌شود) این مطلب را به‌خوبی نمایش می‌دهد. (به تصویر قطعه کد شماره یک مراجعه نمایید.)

 

Unionها:
یونیون‌ها موجوداتی هستند که امکان ترکیب دو یا چند
Query را در یک DataSet فراهم می‌کنند (البته با فرض این که اسامی ستون، نوع داده و ترتیب فیلد مطابقت داشته باشند). یونیون‌ها مکانیسم بسیار قدرتمندی برای انواع گوناگون جستجو‌های پیشرفته محسوب می‌شوند. به‌طور معمول زمانی یونیون‌ها به‌کار برنامه‌نویسان می‌آیند که در کاربردهای مورد نظر آن‌ها، دو جدول شامل اطلاعات نسبتاً مرتبط وجود داشته باشند. به عنوان مثال، در صورتی‌که در ساختار یک بانک اطلاعاتی، یک جدول شامل اطلاعات فروشندگان باشد و جدول دیگری برای ثبت داده‌های شرکت‌های فروشنده لوازم ساختمانی به‌کار رفته باشد، می‌توان از یونیون برای جستجوی همزمان در دو جدول و به‌دست آوردن یک مجموعه پاسخ یا result set بهره گرفت.

 

SubQueryها:
از
SubQuery‌ها و جداول مشتق شده برای قرار دادن عبارات انتخابی در یک SQL Statement دیگر استفاده می‌شود. مثلاً اگر در بخش FROM عبارت جستجوی خود از یک عبارت SELECT دیگر استفاده کنید، در این صورت، عبارت SELECT خارجی از نتایج به‌دست آمده از عبارت SELECT به‌کار رفته در بخش FROM کلی جستجو، استفاده خواهد کرد. این ویژگی هم یکی از ابزارهای قدرتمندی است که در کاربردهای پیشرفته به کمک برنامه‌نویسان می‌آید.

 

عبارات از قبل آماده
برنامه‌نویسان آشنا با گرامر عبارات
ODBC  ازپیش آماده (ODBC Prepared statement) از این پس می‌توانند این ویژگی را در مجموعه API  بانک اطلاعاتی MySQL  که به زبان C  نوشته است، نیز بیابند. مثلاً:
  SELECT * FROM  customer WHERE annual_sales > ? AND 
  ?= region
اصطلاح عبارت جستجوی فوق آماده یا‌
prepare شد، برنامه‌نویس می‌تواند توسط توابع API نرم‌افزار MySQL  مقادیر گوناگونی را به علامت‌های سؤال‌های به‌کار رفته در عبارت، متصل یا Bind کنند. مزیت عمده پشتیبانی از چنین قابلیتی در آن نهفته است که دیگر برای هر عبارت جستجویی که به ازای هر یک از مقادیر متغیر علامت سؤال ایجاد می‌شود، نیازی به تولید مجدد query نخواهد بود. اهمیت این موضوع زمانی بیشتر آشکار می‌گردد که قرار باشد یک عبارت جستجوی از پیش آماده مکرراً اجرا شود. در این وضعیت‌ به‌دلیل آن‌که query‌ها فقط یک‌بار ساخته و بهینه‌سازی می‌شوند، سرعت اجرای نرم‌افزار به طرز محسوسی بالا خواهد بود (در واقع سرعت اجرای نرم‌افزار در قیاس با حالت معمول، دچار افت قابل توجهی نخواهد شد).

 

چندین DataSet در یک فراخوانی :
از زمان عرضه نسخه 4.1 نرم‌افزار
MySQL، برنامه‌نویسان می‌توانسته‌اند توسط یک فراخوانی، چندینquery را بر روی سرور به اجرا بگذارند. این مطلب به معنی آن است که نرم‌افزار Client قادر به دریافت چندین resultSet خواهد بود. این قابلیت در مواقعی که برنامه‌نویس از پیش می‌داند که چندین جستجو مستقل و ناوابسته به یکدیگر باید در کاربرد مشخصی به اجرا گذاشته شوند، عامل صرفه‌جویی بسیار مفیدی محسوب می‌شود. علاوه بر مواردی که در بالا مورد بررسی قرار دادیم، این قابلیت زمانی که آن‌را در کنار ویژگی جدید نسخه 5 این نرم‌افزار یعنی پشتیبانی ازStored Procedure‌ها مورد بررسی قرار دهیم، اهمیت دوچندان خواهد یافت. زیرا می‌دانیم که هر Stored Procedure ممکن است منجر به تولید  و بازگشت دادن چندین resultSet شود.

 

Viewها :
Viewها برای نخستین بار در نسخه جدید MySQL مورد پشتیبانی قرار گرفته‌اند. Viewها این امکان را برای کاربر فراهم می‌آورند که بتواند داده‌های مجموعه‌ای از جداول را همانند اطلاعات یک جدول ببیند. واقعیت آن است که Viewها از دید برنامه‌نویسان از اهمیت چندانی برخوردار نیستند. اما برای مدیران بانک‌های اطلاعاتی، view یک ابزار کارآمد محسوب می‌شود. در آخرین نسخه بانک‌اطلاعاتی MySQL ،view‌ها دارای قابلیت Update شدن هستند.


Stored procedureها و توابع :
طرفداران
MySQL تا همین اواخر از این‌که نرم‌افزار بانک‌اطلاعاتی محبوبشان ازStored procedure‌ها پشتیبانی نمی‌کند، دلخور می‌شدند. اما از زمان عرضه نسخه 4، شرکت MySQL AB وعده داده بود که از این قابلیت در نسخه 5 پشتیبانی خواهد کرد. بدین ترتیب برای نخستین بارStored procedureها در نسخه‌های 5 و 5.0.10 به کار گرفته شدند.


یک
stored procedure ‌همان‌طور که از نام آن مشخص می‌شود، دستور فرایند یا تابعی است که در محل خودِ بانک اطلاعاتی ذخیره‌سازی می‌شود. stored procedure از چندین منظر دارای اهمیت فراوان است. اصولاً یک stored procedure تابعی است که برنامه‌نویس از آن برای انجام عملیات منطقی پیچیده بر روی داده‌های بانک اطلاعاتی استفاده می‌کند. البته باید توجه داشته باشید که چنین تابعی در خود بانک اطلاعاتی ذخیره می‌شود. بدین ترتیب خواص متعددی که به آن اشاره کردیم،‌ در این شرایط تحقق می‌یابند. نخست آن‌که در یک مدل برنامه‌های کاربردی از نوع Client/server، انجام چنین عملیات پیچیده‌ای به هیچ وجه به سکویی که بخش Client بر روی آن در حال اجرا خواهد بود، وابسته نیست. نکته دیگر آن‌که در سیستم‌های شبکه، انجام عملیات پیچیده و سنگین تحت هیچ شرایطی منجر به ایجاد ترافیک در سطح شبکه و در نتیجه ایجاد تأخیر نخواهد شد. زبان مورد استفاده برای نوشتن توابع ذخیره شده در بانک Stored procedure، زبان استانداردی است که 2003 SQL نام دارد. این زبان همان زبانی است که بسیاری از بانک‌های اطلاعاتی از آن برای چنین منظور‌هایی استفاده می‌کنند. به عنوان مثال بانک اطلاعاتی معتبر و معروف IBM به نام  DB2 هم از همین زبان برای بیان روتین‌های توابع خود بهره می‌گیرد.

 

مطلب دیگری که نباید آن‌را فراموش کرد آن است  که در نسخه آخر MySQL قابلیت مهمی گنجانده شده است که امکان بازگرداندن نتایج یک عبارت جستجویSELECT را به‌سمت کلاینت، فراهم می‌کند. در صورتی‌که نرم‌افزارMySQL از چنین قابلیتی پشتیبانی نمی‌کرد و برنامه‌نویسان ناگزیر می‌شدند تا یک cursor بر روی query باز کنند و نهایتاً یک resultSet بسازند. هرچند که انجام چنین عملیاتی برای برنامه‌نویسان بانک‌های اطلاعاتی کار دشواری محسوب نمی‌شود، اما با این حال کاری است که نیاز به توجه کامل برنامه‌نویس برای برگرداندن نتیجه یک query  به کاربر دارد. از آنجایی‌که در کاربردهای مشخصی، امکان بازگشت چندین resultSet به کاربر متصور است، اهمیت ویژگی مورد بحث در چنین شرایط خاصی بیشتر نمایان خواهد شد. بر همین اساس توصیه می‌شود در چنین شرایطی، حد‌المقدور از نسخه‌های بالاتر از نسخه 4.1 MySQL استفاده شود.


در پروژه‌های بزرگ و پیچیده‌تر،
stored procedureها نقش دیگری نیز می‌یابند. معمولاً مرسوم است که در پروژه‌های بزرگ، یک یا دو نفر از برنامه‌نویسان خبره بانک‌های اطلاعاتی وظیفه می‌یابند تا به حل مسائل پیچیده‌تر بپردازند و حاصل کار خود را به‌صورت یک عبارت SQL و در قالب یک Stored procedure تحویل دهند. بدین ترتیب مابقی برنامه‌نویسان می‌توانند به پیاده‌سازی بخش‌های دیگر پروژه بپردازند.

 

Replication :
اگرچه این ویژگی از دیرباز در نرم‌افزار
MySQL  مورد توجه بوده است، در نسخه جدید MySQL پیشرفت‌های قابل توجهی در ارتباط با این موضوع از جهات سرعت اجرا و قابلیت اطمینان صورت گرفته است. ویژگی replication از چندین جهت مهم  تلقی می‌شود.
نخست آن‌که استفاده از
replication تقریباً در اکثر نرم‌افزارهای کاربردی بزرگ مقیاس (که کاربران متعددی در حال قرائت اطلاعات از جداول هستند)، روش متداولی به‌شمار می‌رود. در چنین شرایطی به‌طور معمول کاهش سرعت اجرای نرم‌افزار کاربردی، هیچ چاره‌ای به‌جز بهره جستن از منابع سخت‌افزاری سریع‌تر نخواهد داشت. اما یک راه‌حل هوشمندانه دیگر نیز برای جبران مسأله سرعت اجرا وجود دارد. در این روش می‌توان یک بانک اطلاعاتی را فقط برای خواندن از اطلاعات به‌کار گرفت و از چندین بانک‌های اطلاعاتی دیگر برای نوشتن و ذخیره اطلاعات استفاده کرد.


کاربرد متداول دیگر
replication، ایجاد یک پشتیبان زنده یا Hot Backup از بانک‌های اطلاعاتی به اصطلاح mission critical است. (اصطلاح mission critical به وضعیت‌هایی گفته می‌شود که در آن‌ها حتی توقف‌های لحظه‌ای نرم‌افزار، منجر به بروز  خسارت خواهد شد. به عنوان مثال، نرم‌افزارهای کنترلی دمای راکتور یک نیروگاه هسته‌ای، تشکیل چنین حالتی دارند. زیرا توقف لحظه‌ای فرایند کنترل دما در چنین کاربردهایی مسلماً بسیار خطرآفرین محسوب می‌شود) سناریوی استفاده ازreplication در تهیه نسخه‌های <پشتیبان زنده> در کاربردهای حساس چنان است که به محض از کارافتادگی بانک اطلاعاتی اصلی، نسخه‌های پشتیبان، قابلیت در مدار قرار دادن اطلاعات و جایگزین بانک اطلاعاتی اصلی شدن را دارا باشند. در یک طراحی مناسب، استفاده از replication  می‌تواند زمان‌های توقف یا Downtime را به حداقل برساند.

 

 

نتیجه‌گیری‌ :
مسیر تغییر و تحولات و توسعه‌ای که نرم‌افزار
MySQL از نسخه 3 به بعد تا این لحظه طی کرده است، مسیری دشوار و طولانی محسوب می‌شود. اما تنها از طریق طی کردن چنین مسیرهایی یک نرم‌افزار، خصوصاً از نوع بانک‌های اطلاعاتی می‌تواند خود را برای کاربرد در سطوح سازمانی بزرگ (Enterprise)  آماده سازد.


 

 

 

مراجع و منابع

1محمد عادلی نیا، مهدی سلیمانی، مرجع کامل پایگاه داده ها ،انتشارات دیباگران،تهران ،1385

2. آبراهام سیلبرشاتس، هنری کورت، اس سودارشان، اصول طراحی پایگاه داده ها،ترجمه جعفرنژادقمی،انتشارات دیباگران ،بابل،1389

3. رمضان عباس نژادورزی، علیرضا عظیمی، باقر رحیم پورکامی ، اصول طراحی پایگاه داده ، انتاشرات فن آوری نوین ، تهران ، 1390

4.تقی روحانی رانکوهی ، سیستم مدیریت پایگاه داده ها ،انتشارات جلوه ، تهران ، 1390