|
مباديء في تصميم قواعد البيانات نقاط وأفكار مهمه لغير المختصين
من الصعب إعداة تنسيق المقاله بشكلها الأصلي ...
لقراءة المقالة بتنسيق جيد أنقر هنا :
http://www.orwah.net....php?storyid=82
مباديء في تصميم قواعد البيانات
مقدمة:
معظم المبرمجين ليسوا مؤهلين لإدارة قواعد البيانات أو لتصميم نماذج ضخمه منها . ولكنهم مضطرون دائما للتعامل معها من خلال مشاريعهم البرمجية المختلفة والتي كثيرا ماتكون ذات صلة كبيرة بقواعد البيانات نظرا لحاجات السوق .
- ستغطي هذه المقاله بعض المباديء الأساسية لتصميم وتشكيل فواعد البيانات , وستحوي إجراءات وقائية وآداب التعامل مع قواعد البيانات لغير المختصين أمثالنا والذين لايودون قضاء السنين اللاحقة من حياتهم في مناهج إدارة وتصميم قواعد البيانات ..
وهي موجهة للمبرمجين المتآلفين مع برمجة قواعد البيانات المبنية على المزود , وبالتأكيد عبارات 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 .
[COLOR=blue]المزيد في تصميم قواعد البيانات
قاعدة المستخدم السعيد
ببساطة مستخدموك هم زبائنك , عليك أن تجعلهم سعداء , وبذلك تضمن أن تبقى مرتاح البال وأن يصبح عملك أقل وفاعل أكثر , فإذا استمعت لحاجاتهم وعرفت مالذي يسبب لهم المشاكل والتعب , وتجاوبت مع ذلك ببراعة في برنامجك , فإن اعتمادهم عليك سيقل في الدعم الفني والأسئلة المزعجة وسيصبحون مصدر للدعاية والسمعة الحسنة كما أنهم سيدفعون أكثر ويشترون أكثر , المستخدم السعيد .... لم لا .
التوقف والمراجعة
من السهل قول ذلك ولكن من الصعب تطبيقه دائما , لذلك عليك كلما انتهيت من تصميم جدول مثلا أن تتوقف بعض الوقت لمراجعة الجدول وتتأكد من تطبيقة للقوانين الأساسية السابقة , ومن خلوة من النواقص والأخطاء .. خاصة أن العمل بالجداول المقبلة سيعتمد على مالدينا الآن في الجداول الموجوده , لذلك مراجعة العمل الآن ستعني أخطاء أقل بالمستقبل وستسمح لك بتصميم نموذج متين بسرعة أكبر.
التكامل المرجعي 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
الرابط الأصلي : http://www.orwah.net....php?storyid=82
|