الرئيسية      أرشيف المقالات       المنتدى        المكتبة       إتصل بنا
  القائمة الرئيسية
  Language
  تسجيل الدخول
اسم المستخدم :

كلمة المرور :

تذكرني



هل نسيت كلمة المرور ؟

اشترك الآن !
  بحث
  أقسام المقالات
  آخر المشاركات
  كتب جديدة
 
  زوار هذه الصفحة
اليوم 79
أمس 169
الإجمالي 26517
  الموقع

تقنية -  مباديء في تصميم قواعد البيانات
بواسطة عروة عيسى في 2005/7/25 (12546 قراءة)
تقنية

مباديء في تصميم قواعد البيانات

مقدمة:

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



وهي موجهة للمبرمجين المتآلفين مع برمجة قواعد البيانات المبنية على المزود , وبالتأكيد عبارات Sql كذلك .



من أهم الأمور التي يمكننا التفكير بها عند تصميم قاعدة بيانات هي المرونه , الاستقرارية , قابلية التوسع , الأمن ..

 

سأحاول الجمع بين هذه الأهداف في مجموعة من النقاط المفيده , وأعلم أنها ليست بالكثير , ولكن ربما يستفيد منها آخرون مهتمون بتطبيقات قواعد البيانات , ويعانون مشاكل مع تطبيقاتهم بمجرد أن تكبر قاعدة بيانهم قليلا فوق الحد الذي اعتادوا عليه ..




- أشياء من المهم تجنبها

كلمات قد تكون محجوزة :
عندما تعطي الحقول والجداول أسماء فعليك الحذر من استخدام أسماء قد تكون محجوزة (reserved words) , ومن المهم ان تلاحظ أن عدم كون بعض الكلمات المشهورة محجوزة في قاعدة بياناتك الحالية لايعني أنها لن تكون كذلك في المستقبل أو في قاعدة بيانات أخرى , مما يصّعب موضوع ترقية قاعدة البيانات المستخدمه أو تغييرها .

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

مثال على بعض الكلمات:

Name, Order, By, Sort, Number, Currency, Text, Desc, Date, Time, Username, Password, Group, Data, Min and Max.

لفترة طويلة كنت أستخدم البعض منها مثل Name و Desc , ولكني الآن أعرف تماما مدى خطأ ذلك , فالكلمة Desc هي أحد معرفات "modifier" العبارة Order By في Sql . ولاتعرف متى تظهر لك المشاكل عند حدوث تشابه كهذا , بامكانك مثلا استخدام اكلمة Descr بدلا منها .

للأسف استخدام بعض هذه الأسماء لايزال شائعا مثل Name و Text رغم وجود الكثير من التحذيرات بالابتعاد عنه .

وكحل جذري أنصح باستخدام بادئه لكل حقول الجدول , ربما تمثل الحروف الأولى من الجدول , مثل dept_name بدلا من name حيث dept اختصار Departmint أي جدول الفروع .




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

ولو كان برنامج إدارة قواعد البيانات DBMS يدعم التسمية باللغة العربية فمن الخطورة البالغة القيام به , ستواجهك مشاكل مع لغة البرمجة , كما أنك قد تقرر في أي لحظة نقل القاعدة إلى نظام إدارة قواعد بيانات جديد قد لايدعم على الغالب الأسماء العربية , وغيرها من المشاكل التي قد تقضي على المشروع فقط بسبب عدم مراعاته للقياسية .




لاتكرر الأسماء على مستوى قاعدة البيانات
الجميع يعرف أنه لايجب تكرار أسماء الحقول في جدول واحد . ولكن النصيحة الآن أن لاتكرر أسماء الحقول أو الجداول على صعيد قاعدة البيانات كلها وليس فقط ضمن الجدول نفسه أو الSchema نفسها , أي لاتضع الحقل name في جدولين مختلفين , برأيي طريقة وضع بادءة للحقول تعتبر مناسبه لحل هذه المشكلة أيضا







قواعد أساسية وأفكار مفيدة


اجعل أسماء الجداول والكيانات بالمفرد singular
تكررت معي هذه القاعدة كثيرا , سواء بالOOP أو بمفاهيم هندسة لبرمجيات أو UML أو قواعد البيانات أو غيرها , .. لايوجد سبب أساسي , ولكن هذا يعتبر عرف تقني يسير عليه الاخصائيون منذ زمن .

فقط تذكر معي كم مره واجهت نفسك أثناء كتابة عبارة Sql إذا كان الجدول customer أم customers ؟ لابأس قد تقول إني متأكد أن الجدول يكون بالعادة customer , لكن ماذا عن حالات أخرى مثل order_line بدلا من order_lines مع أن العلاقة علاقة رأس بإطراف ؟ . إذا راجعت الأمثلة الشهيرة والشفرات المفتوحة ستجد هذه القاعدة تطبق في 100% من الحالات , ولابأس بتطبيقها من قبلك كي تبقى داخل السياق . وتتأكد من عدم خروجك عن المألوف الذي يضمن لك السلامه




تجنب الإختصارات Abbreviations
مالم يكن الاختصار واضحا تماما , أو ضروريا , فلا تكثر من استخدام الاختصارات في قاعدة بياناتك , وأضعف الإيمان أحرص على أن تكون واضحه ولاريب فيها .

دعني مثلا أجرب أن أقدم بعض الأمثلة التي قد تدل على أكثر من معنى :

Name

Possible Meanings

Inv_ID

Inventory? Invoice? Investment?

Disc_Code

Discontinued? Discount? Discovery?

Item_Ct

Count? Connector?

Prod_Count

Product? Produced? Production?

Proj_Amt

Project? Projected?

Ext_Rate

Extension? External? Extra?

Org

Organization? Originator? Origin? Orangutang? (Just seeing if you are paying attention)

Req_ID

Requisition? Request?

Rec_ID

Received? Recipient? Receipt? Recovered?

Cat

Catalog? Category?

Grp_Code

Group? Grouping?

Comp_ID

Company? Compensation? Compreshensive?

وبالمقابل إذا استخدمت اختصارات حاول أن تقترب من الاختصارات الشائعة والمتكرره وهذه مجموعة من الأمثله عنها :

Name

Meaning

Pkg

Package

No

Number

Qty

Quantity

Hdr

Header

Attn

Attention

Addr

Address

Alt

Alternate

Dept

Department

Exp

Expiration

Seq

Sequence

Mgr

Manager

Amt

Amount

Min

Minimum

Max

Maximum

Doc

Document

ونصيحة أن تتأكد دائما من أن تحافظ على وحدة الاختصار في كل مكان من قاعدة بياناتك , مثلا إذا كان a_doc وثائق الجدول a , فلتكن b_doc هي وثائق الجدول b .

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





استخدم الشخطة السفلية Underscore وحاذر من الفراغات
بما أن استخدام الفراغات في التسمية هو انتحار مباشر , وبما أن بعض برامج إدارة قواعد البيانات تسمح بالتمييز بين الحروف الكبيرة والصغيرة والبعض الآخر لا , والبعض الآخر يجبرك بحروف كبيره , فعندها بدلا من كتابة . Alt Product ID (فراغات) , وبدلا من . AltProductID (حروف كبيرة وصغيرة) , وبدلا من ALTPRODUCTID (غير واضحه وصعبة القراءة) , فيفضل عندها استخدام أكثر الحلول أمانا وهو : أسماء بالحروف الكبيرة يفصل بينها شخطة سفلية بدل الفراغات أي : ALT_PRODUCT_ID . (الحروف الكبيرة ليست قانونا)

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





لاتستخدم أسماء حقول تطابق اسم الجدول
لاداعي لوضع اسم الحقل locations عندما يكون اسم الجدول locations
لإن ذلك سيخلق لك مشاكل سواء في DBMS ألمستخدم أو في البرمجة لاحقا .

حيث أصبح من المعروف أن ذلك سيسبب مشاكل في الـ alias , كما أنه سيربك ويتعقد عند القيام بتعليمات ضم الجداول باستخدام table joins .








المزيد في تصميم قواعد البيانات


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


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



التكامل المرجعي RI
كثيرا ما يشار للـتكامل ذو الصله أو Referential integrity بالتقييد أو الإكراه " constraints" . مفاد الإكراه هو حماية المستخدم , وحماية نفسك كمطور , وحماية البيانات في مراحل مختلفة من التطوير أو التشغيل ..

الصرامة تعني فرض حدود , وعدم تخطي هذه الحدود , وهذا يعزز الأمن , كما أنه يقلل من أمكانية التسبب بخطأ من قبل المستخدم (لاتسمح للمستخدم بالخطأ)

للتكامل نوعين تعريفي وإجرائي (procedural and declarative)
الإجرائي هو الذي تقدمه في تطبيقك نفسه
التعريفي يقدم عادة من قاعدة البيانات (عادة باستخدام Foreign Keys) أو القوادح triggers في قاعدة البيانات ..

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






توصيات ونصائح


استخدم مفاتيح أساسية حتى لو لم تحتاجها
لاتترك جدول من دون مفتاح أساسي , لإن المفاتيح الأساسيه بالإضافة لأهميتها في التصميم والبرمجة لها دور في عملية البحث , والبحث في جدول يحوي مفتاح أساسي أسرع من البحث في جدول لايحوي مفتاح أساسي ,

كما أن حاجات تطوير قاعدة البيانات في المستقبل تفرض عليك وجود مفتاح أساسي لكي لاتضطر لإعادة العمل بقاعدة البيانات القديمة من أجل تطويرها



الإسم أولا ثم التفصيل ثانيا
الكثيرون يظنون أنها قاعدة غير صحيحه , ولكن الزمن سيثبتها لك ببساطة , كما أنها تسهل في البرمجة لاحقا .

إذا كان لدينا حقل مثل first_name فنحن نكسر القاعدة إذا .
والصحيح هو أن نكتب name_first .. وقد يأتي بعده name_middle و name_last .

وكما تلاحظ هذا شبيه بسلوك لغات البرمجة حيث في لغات oop نكتب object.property وليس العكس , أي الأساسي أولا ثم التفصيل ثانيا , بحيث يسهل سرد كل التفاصيل حسب الاسم لاحقا.

ومن السهل بمجرد كتابة name أن نعرف أن لديه عدة انواع first و middle و last ولكن عند كتابة first سنجد أمور أخرى تبدأ بحرف f لاتفيدك بشيء ولن تستطيع توقع ماذا ستكون الحقول والنتائج .



حقول بوليانية جوابها سؤال
كثير من الأحيان يلزمنا حقول جوابها نعم أو لا (بوليانية أو منطقيه) , عند تسميه هذا النوع من الحقول عليك توضيح ماذا تخزن حالة true أو حالة false لذلك من المفيد أن تسبق اسماء متحولاتك بمعامل يحوله إلى سؤال مثل: Is, Does, Want, Has, Needs

فبدلا من active استخدم is_active , لإنك لو وضعت في active قيمة true فلن تعرف إذا كان مفعلا الآن أم أنه سيصبح مفعلا بعض تغيير القيمه ؟؟

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

أمثله :

Update

Need_update

Phone

has_phone

Modified

Was_modified or is_modified



استخدم المشاهد Views في قاعدة بياناتك
Views هي عبارة عن جداول منطقية , تحوي فعليا استعلامات sql تساعدك في تحديد الحقول التي تريدها من جدول محدد أو من أكثر من جدول وتساعد في تحديد سماحيات كل مستخدم ..

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

وخاصة عندما تكبر قاعدة البيانات وتتعقد , ويصبح من الصعب على مستخدم عادي أن يكتب تعبير Sql فاعل لاسترجاع معلومات مهمة , ولكن بتقسم العمل إلى Views تحوي ضمنها عبارات Joins بين الجداول ومقسمة بطريقة منطقية وصحيحه حسب المعلومات المرجعه من كل منها , فإن كتابة عبارات sql من قبل مستخدم أقل خبرة أصبح أمرا بسيطا وواضحا ..

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


الأمــن :
برأيي الشخصي , الخبير الجيد لايسمح للمستخدم أبدا بالدخول إلى جدول ... الدخول مسموح فقط للمشاهد Views أو بالأحرى لعدد محدد من المشاهد تناسب كل مستخدم , عند مراقبتي لنظام قاعدة بيانات كبير وجدت أن المصمم ألغى سماخيات الوصول العامة للجداول , وسمح بوصول مقيد للمشاهد حسب الحاجة , كما أن الجداول كلها تبدأ بالبادئة tbl_ في حين أن المشاهد من دون بادئة , وهذا دليل على اعتبار المشاهد هي الواجهة الأساسية للمستخدم الذي لن يعرف إذا كانت مشاهد أم جداول , ولن يختلف معه شيء بالأستخدام , سوى سهولة أكثر في الحصول على نتائج أكثر.

نظام آمن بهذه الطريقة سيسمح لك مستقبلا بتعديل قاعدة البيانات دون أن يشعر المستخدمون لها بأي شيء , وهذا يسمى الفصل بين طبقة المصمم وطبقة المستخدم بطريقه مرنه .


أحذر من حقول الزيادة الآليه Auto Generation
أعرف أن استخدام هذه الحقول أمر شائع (أنا كذلك أستخدمها) , ولكن المشاكل المتكرره مع هذه الحقول جعلتني أفكر بالتنويه إلى مشاكل هذه الحقول ..

.. مشكلة هذه الحقول في الكثير من أنواع قواعد البيانات أنك لاتعرف قيمة الحقل المولد تلقائيا حتى بعد الإدخال , وكثيرا ماتحتاج استخدام مباشر لقيمة هذا الحقل  .. (أي أن القاعدة تولد قية في الحقل , ولكن أمكانية قراءة هذه القيمة ستتأخر قليلا بعد الإدخال)

فإذا كنت ترى أنك ستسخدم الحقل المولد تلقائيا أثناء الإدخال فأنصحك بأن تقوم بتوليده تقائيا أو الاستفاده من مزايا RDBMS التي تستخدمها sequence (Oracle) or generator (Interbase) .. وهذا موضوع سهل باستعلام يتم تنفيذه قبل الإدخال يحسب أكبر رقم في قاعدة البيانات ويزيد عليه واحد ((مثلا))  ..



شكرا لاستمرارك بالقراءة حتى هنا ,, سأعتبر ذلك إطراء
 عروة عيسى 25/7/2005
www.orwah.net


شكرا لـ Chad Z الذي استفدت منه في الكثير من السطور السابقة

التقييم: 0.00 (0 أصوات)
**** تحضير للطباعة أرسل هذه المقالة
أضف هذه المقالة إلى المواقع التالية
إضافة إلى Blinklist إضافة إلى del.icio.us إضافة إلى Digg إضافة إلى Fark إضافة إلى Furl إضافة إلى Newsvine إضافة إلى Reddit إضافة إلى Simpy إضافة إلى Spurl إضافة إلى Yahoo مرجع إلى Balatarin مرجع إلى Faceboom مرجع إلى Twitter مرجع إلى Scripstyle مرجع إلى Stumble مرجع إلى Technorati مرجع إلى Mixx مرجع إلى Myspace مرجع إلى Designfloat _NW_BOOKMARK_TO_GOOGLEPLUS _NW_BOOKMARK_TO_GOOGLEREADER _NW_BOOKMARK_TO_GOOGLEBOOKMARKS
التعليقات تخص صاحبها ولا تخص ادارة الموقع
الكاتب الموضوع
orwah
بتاريخ: 2005/09/05 15:25  
مدير الموقع
الانضمام: 2016/10/10
من: سوريا
ردود: 1086
 Re: مباديء في تصميم قواعد البيانات
شكرا سامي
Eng.Ahmad
بتاريخ: 2007/12/26 13:11   تحديث:2016/10/15 23:59
مشترك
الانضمام: 2007/12/26
من:
ردود: 2
 Re: مباديء في تصميم قواعد البيانات
السلام عليكم ورحمة الله وبركاته

جزاك الله خيراً اخي الفاضل عرة

لقد استفدت كثيراً من المقال .
Eng.Ahmad
بتاريخ: 2007/12/26 13:14   تحديث:2016/10/15 23:59
مشترك
الانضمام: 2007/12/26
من:
ردود: 2
 رد: مباديء في تصميم قواعد البيانات
السلام عليكم ورحمة الله وبركاته

جزاك الله خيراً أخي عرة

أنا استفد مثيراً من المقالة




عروة نت 2003-2016 . بالاعتماد على زوبس