11 نصيحة في تصميم قاعدة البيانات

 

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

رابط المقالة المترجمه
قبل ما تبدأ بقراءة المقالة التالية اؤكد لك بأني لست خبير في تصميم قواعد البيانات , لكن من عدة مشاريع عملتها وخبراتي البسيطة بهذا المجال ومطالعة عدة مقالات وكتب , سحاول أن أعطيك 11 نصيحة أو قاعدة ( سمها ما شئت ) تفيدك كثيرا بتصميم أي قاعدة بيانات .
دعنا بالبداية نفهم ماهية ( Normalization ) هي عملية نستخدمها لتنظيم البيانات بكفائة عالية , لها هدفين الاول التقليل من البيانات المكررة ( على سبيل المثال لو أردت حفظ نفس البيانات في أكثر من جدول ) والتأكد من أن تبعية هذه البياناتصحيحة ( يعني خزن البيانات المترابطة فقط في الجدول ) وهذا مما قلل من المساحة المستهلكة بقاعدة البيانات والحفظ بصورة منطقية (صحيحة ) – من مقالة ماهي التبعية في SQL ؟ – أبهيجت ديساي
الكثير من المطورين عند تصميمهم لقواعد البيانات يميلون الى الأشكال الثلاثة للتبعية بالتصميم كما في الفيديو (https://www.youtube.com/watch?v=wp0N1tYjEWc&feature=youtu.be&hd=1 ) مما يقود أحيانآ الى طرق مسدودة !
قلت وأعود لأقول بأن قواعد التبعية الثلاث( Normalization ) مهمة جدآ لكنها قد تسبب مشاكل جمّه , أقرا النصائح التالية ثم بعدها قرر بما ترغب :

النصيحة الأولى: يجب علينا أولآ أن نعرف طبيعة التطبيق الذي نريد تصميم قاعدة بيانات له , هل هو OLAP أو OLTP ؟
( هل سمعت سابقآ ب OLAP و OLTP ؟ المقالة التالية ستكون عن هذا الموضوع فلا تصعبها على نفسك :
الأجرائية ( Transactional ) : في هذا النوع يجب ان يكون المستخدم النهائي أكثر أهتماما ب (CRUD- انشاء , قراءة , تحديث , حذف السجلات) والأسم الرسمي لمثل هذا النوع من قواعد البيانات ( OLTP) .
التحليلية (Analytical ) في هذا النوع يجب ان يكون المستخدم النهائي أكثر أهتماما بالتحليل و اعداد التقارير و التنبؤات …. الخ . هذا النوقع من قواعد البيانات لديه أقل عدد من ( الادخال والتحديث ) . حيث الهدف الاسلاسي هنا هو جلب وتحليل البيانات بالسرعة الممكنة .
الاسم الرسمي لها هو ( OLAP).

1

من جانب آخر , يُفضل أستخدام ( Normalization ) إذا كنت تحتاج لأستخدام الأضافة والحذف والتعديل , وإلا أستخدم ( De-Normalization ) .
الصورة أدناه فيها مخطط بسيط يُظهر جدول ( Names ) وجدول ( Address ) على يسارك ويمثل هذا ( Normalization ) أما الجدول الذي على يمينك يمثل ( De-Normalization ) .
2

النصيحة الثانية: قسّم بياناتك الى أقسام بصورة منطقية , البعض يتجاوز هذه النصيحة حين يحتاج الى أستخدام بعض الدوال مثل دوال النصوص وفهارس الأحرف .
كما تلاحظ في الجدول أدناه الخاص بأسماء الطلاب فلو أردت البحث عن طالب أسمه ( Koirala ) تخيل كيف سيكون أستعلامك ؟
لذلك في مثل هذه الحالات يُفضل تقسيم البيانات الى حقول جديدة كما تلاحظ أدناه .
3

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

النصيحة الرابعة: عندما تتكرر البيانات في جدول ما ستكون مقلقة جدا لسببين الاول أنها ستُزيد من حجم القاعدة مما تسبب بأستهلاك مساحة خزنية والسبب الثاني في بعض الاحيان تُسبب ألتباس وخاصة في أستعلامات البحث أو الشروط .
أنظر للجدول أدناه سترى بأن ( 5th Standard ) و ( Fifth Standard ) متشابهات اليس كذلك ؟ مثل هذه البيانات تكون مربكة ومزعجة وبالأخص في التقارير .
5
لحل هكذا مشكلة ننقل البيانات الى جدول مختلف وربطناه بعلاقة مع الجدول الاساسي لاحظ الصورة أدناه وستفهم هذه النصيحة أكثر .
6

النصيحة الخامسة: كانت النصيحة الثانية تقول حاول أن تقسم البيانات الى أصغر ما يمكن , اليس كذلك ؟ طيب , أنظر للجدول أدناه وبالأخص للحقل (Syllabus ) ترى بياناته مكررة وهذه مشكلة لأنها تحتاج الى أستعلام معقد وتقلل من أداء هذا الاستعلام .
7
هكذا أعمدة ذات بيانات مكررة تحتاج الى نظرة خاصة وطريقة جيدة لنقل بياناتها الى جدول جديد وربطها بعلاقة مع الجدول الأم , كما في الصورة أدناه .
8
لذلك دعنا نضع قاعدة ثانية من الشكل الطبيعي الأول وتقول : تجنب المجاميع المكررة . كما تلاحظ بالشكل أعلاه أنا قد أنشأت جدول (Syllabus ) مفصول ومن ثم ربطته بعلاقة ( Many-to Many ) مع جدول ( Subject ) .

النصيحة السادسة: راقب التبعيات الجزئية :
9
شاهد الحقول التي تعتمد جزئيا على ال(PK ) ففي الصورة أعلاه جدول ترى فيه (PK ) انشئ على ( roll No ) و ( Standard ) الان شاهد حقل ( syllabus ) الذي يرتبط مع الحقل (Standard ) وليس مع (Student ) مباشرة يعني ليس مع (roll No ) .
حقل (syllabus ) مرتبط مع (Standard ) وليس مباشر مع (Student ) . لذا لو أردنا في ما بعد ان نحدث حقل (syllabus ) فسوف نحدثه لكل (Student ) وهذا مظني وغير صحيح , فالأكثر منطقية ان ننقل كل الحقول خارجا وربطها مع جدول (Standard ) .
يمكنك أن ترى كيف نقلنا حقل (syllabus ) وربطناه مع الجدول (standard ) , هذه القاعدة لا شي لكنها الثانية من قواعد التبعية (Normalization ) التي تقول : جميع المفاتيح (Keys ) يجب ان تعتمد كليا على (PK ) وليس جزئيا .

النصيحة السابعة: أختر الأعمدة المشتقة بعناية :
10
فلو عملت على تطبيقات ( OLTP) حاول التخلص من الأعمدة المشتقة إذا لم يكن هناك داعي بالاداء , اما في حالة ( OLAP ) فأننا سوف نحتاج الى عمليات رياضية او تجيميعة لذلك هذا النوع من الحقول يُزيد من الأداء .
ففي الصورة أعلاه لدينا حقل ( Average ) الذي يساوي = الدرجة الكلية / المادة وهذا أحد أشكال ( Redundancy ) , أي أن هذا الحقل مشتق من حقول أخرى , فهل هذا ضروري ؟
أحدى قواعد (Normalization ) تقول : يجب أن لا يعتمد عمود ما على غير ( PK ) !!!
برأيي الشخصي لا تبالغ بتطبيق هذه القاعدة كثيرا , فليس دائما البيانات المكررة سيئة , خاصة إذا كانت البيانات المكررة بيانات حسابية , لاحظ الوضع وقرر فيما بعد ان كنت تريد تطبيق هذه القاعدة أو لا .

النصيحة الثامنة: ليس من الصعب تجنب التكرار إذا كان الاداء هو المهم .
11
لا تجعلها قاعدة صارمة بأنك تتجنب التكرار , فإذا كان هناك حاجة ملحة للأداء حاول التفكير ب ( De-Normalization ) , وتحتاج الى جعل الربط مع عدة جادول وفي ( De-normalization ) الربط يقلل من تحسين الاداء .

النصيحة التاسعة:مشاريع (OLAP) غالبا تستخدم البيانات ذات الابعاد المتعددة , كما تلاحظ بالشكل إدناه , فأنت تستطيع الحصول على ( Sales ) ب ( Country , Customer , Date ) , وبصورة أبسط لو لاحظت شكل بيانات ( Sales ) ستجدها متكون من بيانات متعددة الابعاد .
12
في مثل هذا الوضع تستطيع أنشاء جدول جديد ( Sales ) ويتصل مع جميع أبعاد الجدول بأستعمال ( FK ) .
13

النصيحة العاشرة: في كثير من الاحيان يحصل لدينا تقاطع بأسماء الجداول , اسم الجدول وقيمته , وهذه تعني لديه مفتاح وبعض البيانات المرتبطة مع هذا المفتاح , لاحظ الشكل أدناه لدينا جدول بأسم ( Currency ) و جدول ( Country ) , إذا رأيت البيانات المغلقة هي بالحقيقة فقط مفتاح وقيمة .
14
لمثل هذا النوع من الجداول , ننشأ جدول مركزي ونفرق البيانات بأستعمال حقول معينة تجعله أكثر منطقية .

النصيحة الحادية عشر: لبيانات هرمية غير محددة نستعلم ( PK ) و ( FK ) :
في كثير من الاحيان تتقاطع البيانات في هرمية الاباء والابناء بصورة غير محدودة , حيث في السيناريو متعدد المستويات حيث يكون الشخص ( Sales ) لديه عدة أشخاص ( Sales ) كما في أدناه , لمثل هكذا سيناريوهات نستعمل الموادر الذاتية للمفتاح الاساسي ( Primary Key ) و (Foreign Key ) .التي تساعدنا بتحقيق نفسها .
15
هذه المقالة لا تعني ان لا نتبع الشكل العادي بالتصميم , ولكن بدل ذلك لا نتبعها بشكل أعمى , أنظر الى طبيعة مشروعك ونوع بياناته بالبداية .
16
(( المقالة لم تتُرجم نصيا وأنما أضيفت وحذفت منها بعض الامور حسب ضروريتها )) . المترجم

  • Joseph Adam

    شكرا على المقالة الجميلة

  • شكراً جزيلا بش مهندس

  • Engr. ZADI

    نصائح رائعه .