تعلم تصميم المخططات علاقة الكيان

مرحبا تم تخصيص هذه المقالة لأحد أكثر النماذج شهرة ، فضلاً عن العديد من عارضات التصميم المألوفة - ER ( Entity Relationship ) ، والتي اقترحها العلماء في مجال علوم الكمبيوتر - Peter Chen ، في عام 1976.


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

وجوه المنحى التصميم

بادئ ذي بدء ، أود أن أقول بضع كلمات حول OOP (برمجة / تصميم الكائنات الموجهة) بحيث لا توجد أي مشاكل مع فهم نموذج المخطط نفسه. هو أكثر ملاءمة بالنسبة لي لاستخلاص هذا النموذج مع مبدأ OOP ، حيث الجوهر هو الكائن ، والسمات هي خصائصه ، والاتصالات هي بعض الشيء وسيط (في بعض الحالات ، كطريقة).

بداية سريعة

الإضافة الرئيسية لنموذج تصميم علاقة الكيان هي أنه عالمي. يمكنك تصميم قاعدة بيانات (قواعد بيانات) ، وتشغيل البرنامج ، ومبادئ التفاعل ، إلخ.

ما تحتاج إلى معرفته في بداية الدراسة؟

- عليك أن تعرف في البداية أن العمل الرئيسي يتم على علاقة الجوهر والتواصل. لتسهيل الإدراك ، تجدر الإشارة إلى أن الجوهر عبارة عن اسم في مستطيل ، والاتصال فعل موجود في المعين. هنا مثال:



أعتقد أنك تفهم ما هو ما. لدينا مبرمج يعلم بايثون. يبدو أن كل شيء منطقي. ولكن هنا ، فقط ، ما هي هذه الوحدات في المثال؟

- هذا مؤشر على نوع الاتصال! في هذا المثال ، يكون نوع الاتصال واحدًا لواحد:

$$

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



PS آمل أن تكونوا مهتمين. يمكنك إنشاء مثل هذه المخططات في محرر المخطط - Dia.

سمات

لذلك ، لدينا مبرمج ، لكننا لا نعرف شيئًا عنه ... بدونه لا مبرمج له مبرمج؟
- بدون أي سمات!

لنكمل مثالنا:



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

السمات فارغة

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

تحديد السمات

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

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

أنواع الاتصالات

عظيم كنا قادرين على معرفة هذا. الآن النظر في أنواع الاتصالات المتبقية!

دعنا نواصل مع نوع الاتصال - واحد لكثير:

$$

$$1: N$$

دعني أريك مثالاً:



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

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

يبقى النوع الأخير من الاتصال - كثير للكثير:

$$

$$M: N$$

كالمعتاد ، سأريكم على سبيل المثال ، ولكن ليس مع المبرمج ، ولكن بمثال علاقة المشاهد مع الفيلم ، في أي خدمة لمشاهدة الأفلام:



هناك نوعان من القضايا المثيرة للجدل. لنبدأ.

أولاً:
- لماذا الاتصالات أشبه كيان؟

لتبسيط العلاقة بين النوع "كثير إلى كثير" ، يتم استخدام الكيانات الوسيطة .

"لماذا لا توجد فروع؟"

- يمكن للمشاهد الاشتراك في العديد من الأفلام.
- يمكن أن تحتوي الأفلام على العديد من المشاهدين الذين يشتركون فيها.

الآن ، دعنا نفكر في طريقة أخرى لتنفيذ العلاقة بين الكثير والكثير ، والتي سيكون من الصعب قليلاً كتابتها ، ولكن ربما تكون أكثر قابلية للفهم لأولئك الذين لا يعرفون عن الكيانات الوسيطة:



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

$$

$$M: N = 1: N + N: 1$$

ربما تكون مهتمًا بالسبب وراء وجود حواف لدينا بين الاتصال والكيان.
هذا أصعب قليلاً في التفسير. اقرأ بعناية.
الحقيقة هي أن هناك اتصالات اختيارية وإلزامية . تذكر الهوية:

تخلق الاتصالات الاختيارية مشاركة جزئية ، بينما تخلق الاتصالات الإلزامية مشاركة كاملة.

- ما هي المشاركة الجزئية والكاملة؟

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

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

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

كيانات ضعيفة

النظر في المفهوم النهائي.

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

جوهر ضعيف: لا يمكن أن يكون هناك تفاحة بدون شجرة تفاح

.

في هذا المثال ، الكيان "الطفل" هو كيان ضعيف.

الكيانات الضعيفة هي تلك الكيانات التي لا يمكن أن توجد بدون كيان آخر.

ننشئ الكيان "التابع" ، على أمل ألا يكون لدى الوالد / الوالدين أطفال يحمل نفس الاسم ، وإلا فإن كياننا ، الذي يمكن أن يكون جدولًا في قاعدة البيانات ، لا يمكن أن يسمى Normalized (جدول فيه قواعد أتمتة البيانات و هناك معرف مفتاح أساسي) ، لأنه لا يمكننا مبتذلة التمييز بين الأطفال.

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

سأقدم لك هذا كمثال:

الخاتمة

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

المصادر

- تأليف كتاب "دليل MySQL":
سيد م. "سعيد" Tahagghoghi ، هيو ويليامز
- en.wikipedia.org/wiki/Entity –relationship_model