المقدمة
كما هو الحال غالبًا ، يحتاج مهندس قاعدة البيانات إلى تطوير قاعدة بيانات لحل معين.
في إحدى ليالي الجمعة ، في القطار إلى المنزل من العمل ، فكرت في كيفية إنشاء خدمة لتعيين موظفين لشركات مختلفة. بعد كل شيء ، لا تسمح لك أي من الخدمات الحالية بفهم مدى ملاءمة المرشح لك بسرعة. لا يمكن إنشاء عوامل تصفية معقدة تتضمن أو تستبعد مجموعة من المهارات أو المشاريع أو المناصب المحددة. الحد الأقصى الذي تقدمه الخدمات عادةً هو الفلاتر حسب الشركة وجزئيًا حسب المهارة.
في هذه المقالة ، سأسمح لنفسي بتخفيف العرض الصارم للمادة قليلاً عن طريق مزج المعلومات الفنية بأمثلة غير تقنية من الحياة.
بادئ ذي بدء ، دعنا نحلل إنشاء قاعدة بيانات في MS SQL Server لخدمة البحث عن وظيفة.
يمكن نقل هذه المواد إلى نظام DBMS آخر مثل MySQL أو PostgreSQL.
أساسيات قواعد التصميم
لتصميم مخطط قاعدة بيانات ، عليك أن تتذكر 7 قواعد رسمية ومفهوم التطبيع وعدم التطابق. هم أساس جميع قواعد التصميم.
دعنا نصف بمزيد من التفصيل 7 قواعد رسمية:
- علاقة واحد لواحد:
1.1) مع اتصال إلزامي:
مثال يمكن أن يكون مواطنًا وجواز سفره: يجب أن يكون لدى أي مواطن جواز سفر ؛ جواز سفر واحد لكل مواطن
يمكن تنفيذ هذه العلاقة بطريقتين:
1.1.1) في كيان واحد (جدول): الشكل 1. كيان المواطن هنا ، جدول Citizen هو كيان مواطن ، وتحتوي سمة PassportData (حقل) على جميع بيانات جواز السفر للمواطن ولا يمكن أن تكون فارغة (NOT NULL). 2) في كيانين مختلفين (جداول): الشكل 2. العلاقة بين كيانات Citizen و PassportData
هنا جدول Citizen هو كيان المواطن وجدول PassportData هو كيان بيانات جواز سفر المواطن (جواز السفر نفسه). يحتوي كيان المواطن على سمة PassportID (حقل) تشير إلى المفتاح الأساسي لجدول PassportData. بدوره ، يحتوي كيان بيانات جواز السفر على سمة (حقل) CitizenID ، والتي تشير إلى المفتاح الأساسي CitizenID لجدول Citizen. لا يمكن ترك حقل معرف جواز السفر لجدول المواطنين فارغًا (ليس فارغًا). من المهم أيضًا الحفاظ على تكامل حقل CitizenID في جدول PassportData لضمان وجود علاقة رأس برأس. بمعنى آخر ، يجب أن يشير حقل PassportID في جدول Citizen وحقل CitizenID في جدول PassportData إلى نفس السجلات كما لو كانت كيانًا واحدًا (جدول) معروضًا في الفقرة 1.1.1.
1.2) برابط اختياري:
مثال على ذلك هو شخص لديه جواز سفر أو بدون جواز سفر لبلد معين. في الحالة الأولى ، سيكون من مواطني الدولة المعنية ، وفي الحالة الثانية ، لن يكون.
يمكن تنفيذ هذه العلاقة بطريقتين:
1.2.1) في كيان واحد (جدول): الشكل 3. كيان الشخص جدول الشخص هو كيان شخص ، وتحتوي سمة PassportData (حقل) على جميع بيانات جواز سفره ويمكن أن تكون فارغة (NULL). 2) في كيانين (جداول): الشكل 4. العلاقة بين كيانات Person و PassportData
جدول الشخص هو كيان الشخص ، وجدول PassportData هو كيان بيانات جواز سفر الشخص (جواز السفر نفسه). يحتوي الكيان البشري على سمة PassportID (حقل) تشير إلى المفتاح الأساسي لجدول PassportData. في المقابل ، تحتوي هوية بيانات جواز السفر على السمة (الحقل) PersonID ، والتي تشير إلى المفتاح الأساسي PersonID لجدول الشخص. يمكن أن يكون حقل PassportID الخاص بجدول الأشخاص NULL. من المهم أيضًا الحفاظ على تكامل حقل PersonID لجدول PassportData. هذا ضروري لضمان التواصل الفردي. يجب أن يشير حقل PassportID في جدول الشخص وحقل PersonID في جدول PassportData إلى نفس السجلات كما لو كانت هي نفس الكيان (الجدول) الموضح في الفقرة 1.2.1. أو يجب أن تكون هذه الحقول فارغة ، أي أن تحتوي على NULL.
- :
2.1) :
. .
:
2.1.1) ():
.5. Parent
Parent , () ChildList . (NOT NULL). ChildList (NoSQL) XML, JSON .
2.1.2) ():
.6. Parent Child
Parent , Child — . Child ParentID, ParentID Parent. ParentID Child (NOT NULL).
2.2) :
, .
:
2.2.1) ():
.7. Person
Parent , () ChildList . (NULL). ChildList (NoSQL) XML, JSON .
2.2.2) ():
.8. Person Child
Parent , Child — . Child ParentID, ParentID Parent. ParentID Child (NULL).
2.2.3) , () () :
.9. Person
() Person () ParentID, PersonID Person (NULL).
« » .
- :
. , «» «», , . , , .
- :
: , . , .
, NoSQL, , . , 3 ():
.10. Person RealEstate
Person RealEstate . () () PersonRealEstate. () PersonID RealEstateID PersonID Person RealEstateID RealEstate . , PersonRealEstate (PersonID; RealEstateID) PersonRealEstate.
. , . , 1.1.2 1.2.2.
واحد لكثير و كثير إلى واحد العلاقات يمكن تنفيذها من خلال أكثر من كيانين. لهذا ، تتم إضافة السمات الضرورية ، والتي تشير إلى المفاتيح الأساسية للكيانات المقابلة الضرورية. هذا التنفيذ مشابه للأمثلة الموصوفة أعلاه في الفقرتين 1.1.2 و 1.2.2.
أين القواعد الرسمية السبع؟
ها هم:
- البند 1 (البند 1.1 والفقرة 1.2) - القواعد الرسمية الأولى والثانية
- البند 2 (البند 2.1 والفقرة 2.2) - القواعد الرسمية الثالثة والرابعة
- البند 3 (على غرار البند 2) - القواعد الرسمية الخامسة والسادسة
- البند 4 - القاعدة الرسمية السابعة
في النص أعلاه ، تم دمج هذه القواعد الرسمية السبع في أربع كتل وظيفية.
عندما نتحدث عن التطبيع ، عليك أن تفهم جوهره. يؤدي التطبيع إلى انخفاض في تكرار تخزين المعلومات ، وبالتالي إلى انخفاض في إمكانية حدوث حالات شاذة في البيانات. ومع ذلك ، فإن التسوية عند تقسيم الكيانات تؤدي إلى إنشاءات استعلام أكثر تعقيدًا لمعالجة البيانات (عمليات الإدراج والتعديلات والاختيار والحذف).
تسمى عملية التطبيع العكسي عدم التطابق . هذا تبسيط لبناء استعلامات الوصول إلى البيانات بسبب تجميع وتداخل الكيانات (على سبيل المثال ، كما هو موضح أعلاه في الفقرتين 2.1.1 و 2.2.1 باستخدام بيانات منظمة بشكل غير كامل (NoSQL)).
هذا هو بيت القصيد من قواعد تصميم قاعدة البيانات.
هل أنت متأكد أنك تفهم العلاقة في سبع قواعد رسمية؟ هل فهمت ولم تعترف؟ بعد كل شيء ، المعرفة والفهم مفهومان مختلفان تمامًا.
سأشرح بمزيد من التفصيل. اسأل نفسك ، هل يمكنك رسم نموذج قاعدة بيانات ، وإن تم تكبيره بواسطة الكيانات ، لأي مجال موضوع ولأي نظام معلومات في غضون ساعتين؟ (يمكن إكمال التفاصيل الدقيقة عن طريق السؤال عن المحللين وممثلي العملاء). إذا فاجئك السؤال ، وتعتقد أن هذا مستحيل ، فأنت تعرف القواعد الرسمية السبع ، لكنك لا تفهمها.
لسبب ما ، تتجاهل العديد من المصادر حقيقة أن هذه العلاقات لم يتم اختراعها ، بل تم الكشف عنها. توجد في البداية في العالم الحقيقي بين الموضوعات وبين الموضوعات والأشياء.
أيضا ، يمكن أن تتغير هذه العلاقة ، والانتقال من 00:59 ل واحدة إلى العديد، كثير إلى واحد أو كثير إلى كثير . يمكن أن يتغير التزام الاتصال أو يظل دون تغيير.
اسمحوا لي أن أخبركم عن حالة واحدة عندما توصلت إلى فهم هذه العلاقات من خلال معرفة القواعد الرسمية السبع.
في وقت ما ، شعرت بالحرج من حقيقة أنني كنت أعرف هذه القواعد الرسمية السبعة في الجامعة ، ولكن في الممارسة الصناعية (ترسل الجامعة الطلاب إلى شركات مختلفة لاكتساب الخبرة المهنية) لفترة طويلة جدًا ، قمت ببناء نماذج من القواعد لمختلف المجالات. فكرت في الأمر وأدركت أنني لم أفهم هذه العلاقة.
ساعدتني مراقبة الناس ، وتم الكشف عن جوهر العلاقة في المنام. سأعيد سرد هذا الحلم في شكل مبسط: فقط ما يسمح لك بفهم هذه القواعد الرسمية السبع بشكل أفضل - دون تفصيل كل شيء آخر.
كان الحلم حول عائلة لها أب وأم وأطفال. يموت الأب في حادث سيارة ، وتبدأ الأم في الشرب ، وينتقل الأطفال في النهاية إلى دار الأيتام. هؤلاء الأطفال تركوا بدون آباء لفترة طويلة. ثم يكون لبعض الأطفال أوصياء ، وهناك أيضًا العديد منهم.
هل تتبعت نوع العلاقات بين الأشخاص وكيف تغيرت هذه العلاقات؟
دعونا نلقي نظرة فاحصة.
- عندما اكتملت الأسرة ، مع وجود العديد من الأطفال ، كانت العلاقة بين الآباء والأطفال متعددة .
- , . , , , , .
- .
- — .
- , : , ().
العلاقة بين الزوج والزوجة هي علاقة فردية مع رباط إلزامي في الزواج الرسمي ، أو علاقة فردية مع رباط اختياري قبل التسجيل. يمكن أن تكون هناك زوجة واحدة فقط ، كما لا يمكن أن يكون هناك سوى زوج واحد. على الأقل في روسيا. لكن في بلد آخر ، يكون تعدد الزوجات ممكنًا ، ومن ثم ستكون العلاقة بين الزوج والزوجة علاقة واحدة بالعديد ، وبين الزوجات والزوج - كثير إلى واحد .
نأمل أن تكون الآن أقرب إلى فهم هذه القواعد الرسمية السبع.
يجدر التمرين باستمرار: مراقبة الأشخاص وتحديد العلاقات القائمة بين الموضوعات وبين الموضوعات والأشياء. ما سبق وصف المواطن وجواز سفره بالموقف رأس برأس ارتباط إلزامي... في نفس الوقت ، مثال على الشخص وجواز سفره هو علاقة واحد لواحد مع ارتباط اختياري .
بعد فهم القواعد الرسمية السبع ، يمكنك بسهولة تصميم نموذج قاعدة بيانات لأي تعقيد لأي نظام معلومات.
سترى أيضًا أن هناك طرقًا عديدة لتنفيذ علاقة ، ويمكن أن تتغير العلاقة نفسها. نموذج قاعدة البيانات (المخطط) هو لقطة من العلاقات بين الكيانات في نقطة زمنية معينة. هذا هو السبب في أنه من المهم تحديد الكيانات نفسها - صور الكائنات من العالم الحقيقي أو مجال الموضوع ، وعلاقتها مع بعضها البعض ، مع مراعاة التغييرات في المستقبل.
لن يحتاج نموذج قاعدة البيانات المصمم جيدًا ، مع مراعاة العلاقات المتغيرة في الواقع أو في المجال ، إلى التغيير لسنوات أو حتى عقود. هذا مهم بشكل خاص لمخازن البيانات ، حيث تتطلب التغييرات إعادة حفظ كميات كبيرة من البيانات (من عدة غيغابايت إلى العديد من التيرابايت).
من المهم أن تتذكر أن الجداول في النموذج العلائقي هي علاقات كيان ، والصفوف (المجموعات) هي أمثلة على هذه العلاقات. ولكن لتسهيل الأمر ، غالبًا ما تُفهم الجداول على أنها كيانات ، وصفوف الجدول هي مثيلات كيان. يتم التعبير عن علاقتهم من خلال العلاقات في شكل مفاتيح خارجية.
تصميم مخطط قاعدة بيانات للعثور على المتقدمين للوظيفة
بعد أن قمنا بتغطية أساسيات قواعد تصميم قواعد البيانات في الجزء الأول ، فلنقم بإنشاء مخطط قاعدة بيانات للعثور على الباحثين عن عمل.
بادئ ذي بدء ، دعنا نحدد ما هو مهم لموظفي الشركة الذين يبحثون عن مرشحين:
- بالنسبة للموارد البشرية:
1.1) الشركة التي عمل فيها مقدم الطلب
1.2) الوظائف التي شغلها مقدم الطلب سابقًا في هذه الشركات
1.3) المهارات والقدرات التي استخدمها مقدم الطلب في عمله ؛
وكذلك مدة عمل المتقدم في كل شركة في كل وظيفة ومدة استخدام كل مهارة وقدرة
- لأخصائي تقني:
2.1) الوظائف التي يشغلها مقدم الطلب في هذه الشركات ؛
2.2) المهارات والقدرات التي استخدمها مقدم الطلب في عمله ؛
2.3) المشاريع التي شارك فيها مقدم الطلب ؛
وكذلك مدة عمل المتقدم في كل منصب وفي كل مشروع ، ومدة استخدام كل مهارة وقدرة
أولاً ، دعنا نحدد الكيانات الضرورية:
- موظف
- شركة
- المنصب (المنصب)
- مشروع
- مهارة
- تتشابه الشركات والموظفون مع كثيرين ، حيث يمكن للموظف العمل في العديد من الشركات ، ويعمل العديد من الأشخاص في الشركة.
- ترتبط المناصب والموظفون بطريقة مماثلة: يمكن للعديد من الموظفين شغل منصب واحد داخل شركة واحدة أو عدة شركات.
- , , . , — .
- : .
- , .
- .
نظرًا لأنه من المهم جدًا تسجيل المدة التي عمل فيها الموظف في منصب معين في شركة معينة ، وكذلك في كل مشروع ، فقد يكون الرسم التخطيطي لقاعدة البيانات الخاصة بنا على النحو التالي: الشكل 11. مخطط قاعدة البيانات للعثور على المتقدمين للوظيفة هنا ، يعمل جدول JobHistory ككيان لتاريخ الوظيفة لكل باحث عن عمل. بمعنى ، إنها سيرة ذاتية تقدم علاقات متعدد إلى متعدد بين موظف الكيانات والشركة والمنصب والمشروع. ترتبط المشاريع والمهارات ببعضها البعض بقدر ما ترتبط بالعديد من الأشخاص ، وبالتالي تتواصل مع بعضها البعض من خلال كيان ProjectSkill (الجدول).
عندما تفهم العلاقة بين الموضوعات وبين الموضوعات والأشياء - القواعد الرسمية السبعة التي سبق ذكرها - يمكن تنفيذ هذا المخطط أو مخطط مشابه "على الركبة": على قطعة من الورق ، في أقل من ساعة. ويراعى هذا أيضًا التعب بعد يوم عمل مثمر.
هنا كان من الممكن تبسيط مخطط إضافة البيانات إذا تم تضمين "المهارات" في "مشاريع" الكيان من خلال بيانات منظمة بشكل غير كامل (NoSQL) في شكل XML أو JSON ، أو ببساطة سرد أسماء المهارات مفصولة بفواصل منقوطة. لكن هذا سيجعل من الصعب أخذ العينات حسب المهارة والتصفية حسب المهارة.
يوجد نموذج مشابه في قلب قاعدة بيانات مشروع Geecko .
كما ترى ، لا يوجد شيء معقد في تصميم أنظمة المعلومات من حيث تصميم قاعدة البيانات. هذا مجرد انعكاس للكائنات والموضوعات من الواقع ، تم نقلها إلى "كيانات" مخطط قاعدة البيانات. يتم إصلاح العلاقة بين هذه الكيانات في وقت معين ، مع مراعاة التغييرات المستقبلية.
ما نأخذه بالضبط من الواقع ونضعه في جوهر المخطط ، وما هي العلاقات التي نبنيها في النموذج ، سيعتمد على ما نريده من نظام المعلومات بشكل عام ، هنا وفي المستقبل. بمعنى آخر ، ما هي البيانات التي نريد تلقيها في الوقت الحالي وبعد وقت معين في المستقبل.
قليلا من كلمات
بعد تشغيل النموذج ، توقف للحظة وفكر: لقد تم للتو إنشاء عالم صغير جديد. لها كياناتها الخاصة من العالم الحقيقي وعلاقاتها الخاصة. نعم ، هذا عالم رقمي ، لكنه سيطور الآن طريقته الخاصة. سيتواصل (يتكامل) مع أنظمة (عوالم) أخرى ، تم إنشاؤها أيضًا وفقًا لقواعدها الخاصة. سوف تتدفق البيانات في هذه الأنظمة مثل الدم في الكائن الحي.
وقبل الذهاب إلى الفراش ، فكر في حقيقة أن القواعد الرسمية السبعة كانت دائمًا ، وأنها تحيط بنا في كل مكان. لا أكثر ولا أقل ، دائمًا سبعة. يمكن تقسيم جميع العلاقات في الحياة الواقعية إلى هذه القواعد الرسمية السبعة. وعندما تفكر أو تحلم ، كيف ترتبط الكيانات ببعضها البعض - وليس وفقًا لنفس القواعد الرسمية السبع؟
بشكل عام ، أنا متأكد من أن هذه العلاقة (سبع قواعد رسمية) تم الكشف عنها من قبل معالج نفسي جيد جدًا ، ربما امرأة. لقد مر وقت طويل جدًا ، قبل وقت طويل من ظهور مفهوم تكنولوجيا المعلومات. والشيء الأكثر إثارة للاهتمام هو أن هذه العلاقات تعيش خارج قاعدة البيانات وتكنولوجيا المعلومات - يستخدمها الأخير فقط لنمذجة أنظمة المعلومات.
لكننا خرجنا عن الموضوع قليلاً. أنا فقط أحثك على التعامل مع هذه العملية بروحك في لحظة إنشاء نظام جديد. ثم صدقوني ، ستحدث لحظة الخلق. سيكون النظام المصمم بهذه الطريقة هو الأكثر حيوية بين جميع الكائنات الحية في العالم الرقمي.
خاتمة
تم تنفيذ المخططات الخاصة بالأمثلة باستخدام أداة مخطط قاعدة البيانات لـ SQL Server . ومع ذلك ، فإن DBeaver لديه وظائف مماثلة .