🏂🏿 🏷️ 🗽 دليل متواضع لمخططات قاعدة البيانات 🍳 👨🏼‍🔬 🔎

هندسة الزهور من قبل Mookiezoolook

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

ولكن كيف يمكن تقييم الدائرة الأفضل؟ وماذا تعني كلمة "أفضل" عندما نتحدث عن بنية قاعدة البيانات؟يدعوكفريق Mail.ru Cloud Solutions إلى اتباع توصيات Mike Alcha ، مستشار تطوير البرامج. يبدو لنا أنه لخص بإيجاز بعض مبادئ العمارة المختصة.

المدير: " أعتقد أننا يجب أن نبني قاعدة بيانات SQL . " المطور (هل يفهم حتى ما يتحدث عنه ، أم أنه رأى نوعًا من الإعلان في مجلة الأعمال؟ ..): " ما هو اللون الذي تريده لقاعدة البيانات؟ ". المخرج: " ربما يمتلك الليلك أكبر قدر من الذاكرة . "

بعض النصائح الأساسية

لذا ، من المهم أن تسعى من أجل شيئين رئيسيين :

عند تقسيم المعلومات إلى جداول ، يتم تخزين جميع المعلومات.
فائض التخزين هو الحد الأدنى.

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

فيما يلي بعض الإرشادات للاقتراب من البنية الجيدة :

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

- مالذي تعمل عليه؟

" تحسين استعلام SQL هذا." يتباطأ ، ويبدأ المستخدمون في الشكوى.

- واللغة الفاحشة في التعليقات مطلوبة للتحسين؟

- إذا رأيت الرمز الأصلي ، فلن تسأل.

دعونا ننظر في هذه التوصيات بمزيد من التفصيل.

1. استخدم النموذج العادي الثالث على الأقل

يمكن تقسيم بنية قاعدة البيانات إلى الفئات التالية:

الشكل العادي الأول.
الشكل العادي الثاني.
الشكل العادي الثالث.
الشكل الطبيعي لـ Boyce-Codd.

تمثل هذه الفئات تصنيفًا حسب الجودة. سنراجع بإيجاز جميع الفئات ونرى سبب الحاجة إلى نموذج عادي ثالث على الأقل.

الشكل العادي الأول

بالنسبة للنموذج العادي الأول ، يجب أن تكون كل قيمة لكل عمود في كل جدول في قاعدة البيانات ذرية. ماذا يعني الذري؟ باختصار ، القيمة الذرية هي "شيء واحد".

على سبيل المثال ، لدينا جدول مثل هذا:

الاسم الاول	الكنية	عمر	المناطق
جون	ظبية	27	{"تصميم مواقع الويب" ، "أبحاث العملاء"}
مريم	جين	33	{"التخطيط الاستراتيجي طويل المدى" ، "التوظيف"}
توم	حداد	35	{"تسويق"}

هنا ، يحتوي عمود المساحات على قيم غير ذرية. على سبيل المثال ، في خط John Doe ، يخزن الحقل كيانين: تصميم موقع الويب وبحوث العملاء.

لذلك هذا الجدول ليس في الشكل العادي الأول.

لإحضاره إلى هذا النموذج ، يجب تخزين قيمة واحدة فقط في كل حقل .

الشكل العادي الثاني

في النموذج العادي الثاني ، لا يمكن اشتقاق أي عمود ليس جزءًا من المفتاح الأساسي (أو يمكن أن يعمل كجزء من مفتاح أساسي آخر) من الجزء الأصغر من المفتاح الأساسي .

ماذا تعني؟

لنفترض أن لديك مثل هذه البنية الأساسية (أكدت على الحقول المقابلة للمفتاح الأساسي في هذا الجدول):

هوية الموظف	معرف المشروع	ساعات	اسم الموظف	اسم المشروع
1	1	10	يوحنا	"تصميم الموقع"
2	1	عشرون	مريم	"تصميم الموقع"

في هذا المشروع ، يمكن الاستدلال على اسم الموظف مباشرة من "الموظف" ، لأن الفكرة هي أن اسم الموظف يتم تحديده بشكل فريد من خلال معرفه.

وبالمثل ، يتم تحديد اسم المشروع بشكل فريد بواسطة معرف معرّف المشروع.

وبالتالي ، لدينا عمودين يمكن استنتاجهما من الجزء الرئيسي الأساسي.

سيكون كل من هذه الأمثلة كافياً لإخراج هذا الجدول من النموذج العادي الثاني.

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

الشكل العادي الثالث

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

ماذا تعني؟

لنفترض أن لديك البنية التالية (وهي بعيدة عن المثالية):

اسم الموظف	هوية الموظف	عمر	رقم القسم	اسم القسم
يوحنا	1	27	123	"تسويق"
مريم	2	33	456	"التشغيل"
توم	3	35	123	"تسويق"

في هذا الجدول ، يمكن الاستدلال على رقم_الرقم من رقم_الموظف ، ويمكن استنتاج اسم_العنوان من رقم_الرقم. إذن ، يعتمد اسم_القسم بشكل انتقائي على معرف_الموظف

إذا كان هناك مثل هذا التبعية متعدية: الموظف_المعروف → department_number → department_name ، فإن هذا الجدول ليس في النموذج العادي الثالث.

ما المشاكل التي تنشأ بسبب هذا ؟

إذا كان يمكن اشتقاق اسم القسم من رقمه ، فإن تخزين هذا الحقل لكل موظف يؤدي إلى تكرار زائد.

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

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

يمكن تجنب جميع هذه المشاكل تمامًا في شكل عادي ثالث.

مآثر أمي . اسم ابنتها هو مساعدة! أجبر على تزييف جوازات السفر

2. إنشاء خط الدفاع الأخير في شكل قيود

قاعدة البيانات التي تعمل معها هي أكثر من مجرد مجموعة من الجداول. وظائف معينة مدمجة فيه. تساعد العديد من هذه الميزات في ضمان جودة البيانات ودقتها.

تحدد القيود القواعد ، وما هي القيم التي يمكن إدخالها في حقول قاعدة البيانات.

عند تحديد العلاقات في قاعدة بيانات ، تأكد من تعيين قيود المفتاح الخارجي.

تأكد من تحديد ما يجب أن يحدث عند حذف وتحديث الصف المرتبط بالصفوف الأخرى في الجداول الأخرى (ON DELETE و ON UPDATE).

تأكد من استخدام NOT NULL لجميع الحقول التي لا يجب إبطالها. قد يكون من المنطقي تعيين تحقق على الواجهة الخلفية ، ولكن تذكر أن الأعطال تحدث دائمًا ، لذا فإن إضافة هذا النوع من التقييد لن يضر.

قم بتعيين حدود التحقق من الاختيار للتأكد من أن قيم الجدول في النطاق المقبول ، على سبيل المثال ، سعر المنتج له قيمة موجبة دائمًا.

حقيقة مثيرة للاهتمام : في أبريل 2020 ، على وجه التحديد ، منع مثل هذا التقييد في البرمجيات التداول في موسكو MICEX لأن سعر العقود الآجلة للنفط WTI انخفض إلى ما دون الصفر. على عكس بورصة موسكو ، قامت بورصة نيويورك التجارية NYMEX بتحديث البرنامج قبل أسبوع من الحادثة ، لذلك كانت قادرة على إجراء المعاملات بنجاح بسعر سلبي ، أي مقابل رسوم إضافية للمشتري من البائع - تقريبًا. عبر.

يمكن العثور على جميع قيود PostgreSQL هنا .

3. لا تخزن عناوين كاملة في حقل واحد

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

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

سيكون من الصعب جدا!

نظرًا لأنه يتم تخزين العنوان الكامل كسلسلة في حقل قاعدة البيانات ، سيتعين عليك أولاً معرفة مقدار هذه السلسلة من المدينة! وهذه مهمة مستحيلة تقريبًا ، نظرًا لجميع تنسيقات العناوين الممكنة في هذا المجال.

لذلك ، تأكد من تقسيم حقل "العنوان" العالمي إلى حقول محددة: الشارع ، رقم المنزل ، المدينة ، المنطقة ، الرمز البريدي ، وما إلى ذلك.

مشكلة أخرى في العنوان - الحقول المجهولة

في ما يلي توضيح من كتاب Michaels Blach ، The Copper Bullet لتحسين جودة البرامج:

ما هي المشاكل المحتملة المرئية هنا؟ هل يمكنك بسهولة تمييز مدينة شيكاغو عن شوارع شيكاغو؟ على الاغلب لا.

لذلك ، تذكر دائمًا إعطاء أسماء أعمدة واضحة لكل وحدة من وحدات المعلومات.

كيفية كتابة السيرة الذاتية

- هل لديك خبرة في SQL؟

- لا (لا).

- لذا اكتب: خبير NoSQL.

4. لا تخزن أبداً الاسم الأول والأخير في حقل واحد

على غرار الوضع مع العناوين: عدد الاختلافات في الاسم واللقب أكبر من أن يميز بينهما بوضوح.

بالطبع ، يمكنك فصل الاسم عن الاسم الأخير ، إذا كانت هناك مسافة بينهما.

على سبيل المثال ، "مايك ألتشي" ← اسم "مايك" واللقب "ألتشي".

ولكن ماذا لو أدخل المستخدم الاسم الأوسط؟ أم لديه لقب مزدوج؟ ولكن ماذا لو كان هناك اسم وسط ولقب مزدوج؟

كيفية تحديد أين هو الاسم وأين هو الاسم الأخير لتقسيم السلسلة؟ الأخطاء حتمية.

هناك طريقة لتجنب العديد من المشاكل وهي إنشاء حقول منفصلة (في النماذج) لاسم المستخدم first_name و last_name. بهذه الطريقة ، تسمح للمستخدمين بمشاركة أسمائهم الخاصة ويمكنهم تخزين البيانات بطريقة متسقة.

ملحوظة: أنا لا أقول أن المساحات ممنوعة في مجالات قاعدة البيانات. على سبيل المثال ، بالنسبة لأسماء مثل Juan Martin Del Potro ، فإن الجزء الأول من Juan Martin موجود في حقل الاسم_الأول ، و Del Potro موجود في حقل الاسم_الأخير. بالطبع ، هذا ليس مثاليًا . يمكن أن يكون لديك بشكل اختياري الأعمدة middle_name و second_last_name. انظر بمزيد من التفاصيل حول الاختلافات المحتملة في الأسماء والألقاب في قائمة " المفاهيم الخاطئة للمبرمجين حول الأسماء " والمقالة " المفاهيم الخاطئة للمبرمجين حول الأسماء - مع الأمثلة ". يجب أن توافق على نوع من الحل الوسط بين الدقة والعملية.

5. تعيين اصطلاحات أسماء الجداول والحقول والالتزام بها

من المزعج جدًا العمل مع البيانات التي تبدو مثل user.firstName و user.lst_name و user.birthDate وما إلى ذلك.

أنصحك بإنشاء قواعد تسطير أسفل السطر ، لأنه ليس كل محركات SQL تتعامل مع الأحرف الكبيرة بنفس الطريقة ، وإرفاق كل شيء في علامات الاقتباس أمر ممل للغاية.

اختر نفس استدعاء الجداول - بصيغة الجمع أو المفرد (على سبيل المثال ، المستخدمون في صيغة الجمع أو المستخدم بصيغة المفرد). أنا أحب المفرد أكثر ، ولكن يبدو أن جميع إطارات الخلفية تعددية بشكل افتراضي. عليك اتباع النمط واستخدام الجمع.

ماذا تقرأ :

دليل متواضع لمخططات قاعدة البيانات