نموذج البيانات المفاهيمي

قبل كل شيء، التحضير هو مفتاح النجاح. —ألكسندر غراهام بيل

في هذا الفصل، نستكشف المكوّنات المختلفة لنموذج البيانات المفاهيمي (conceptual data model) والعملية التي تُصمَّم بها. وتحقيقًا لذلك، سنشرح بعض المفاهيم المهمة، وسنخطو أيضًا الخطوات الأولى نحو تصميم نماذج مفاهيمية بسيطة. وننظر في الأسئلة التالية:

• ما هي المكوّنات الأساسية للمخطط المفاهيمي؟ وما دور الكيانات (entities) والعلاقات (relationships) والخواص (attributes) بوصفها مكوّنات أساسية لنموذج البيانات المفاهيمي؟
• ما الخطوات الواجب اتخاذها لترجمة نص مسألة إلى مخطط مفاهيمي؟

بعد إكمال هذا الفصل، ينبغي أن تكون قادرًا على شرح:

• نموذج البيانات المفاهيمي؛
• مخطط الكيانات والعلاقات (ERD)؛
• الكيان ونوع الكيان (أنواع الكيانات الضعيفة، وأنواع الكيانات القوية (أو العادية))؛
• الخاصية (الخاصية المفتاحية، والخاصية المشتقة، والخاصية المركّبة، والخاصية أحادية القيمة، والخاصية متعددة القيم، وخاصية العلاقة)؛
• العلاقة (درجة العلاقة، التعددية، علاقة 1-1، علاقة 1-N، علاقة N-M)؛
• التكرار (redundancy)؛
• الأنواع الفرعية والأنواع الفائقة والتعميم والتخصيص.

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

كما ينبغي أن تكون قادرًا على إنشاء مخطط كيانات وعلاقات لنص مسألة معطى.

مخطط الكيانات والعلاقات (Entity Relationship Diagram)

يجيب نموذج البيانات المفاهيمي عن السؤال: "ما المعلومات ذات الصلة بتطبيق تكنولوجيا المعلومات المقصود؟" ويقدّم نموذج البيانات هذا رؤية لواقع المستخدمين والمعلومات الواردة فيه، دون الأخذ في الاعتبار التفاصيل التقنية.

نموذج البيانات المفاهيمي هو تمثيل مخطط للمعلومات ذات الصلة. ونحن نسعى إلى تمثيل يسهل إعداده ويستطيع جمهور واسع قراءته. ولتحقيق ذلك، نستخدم تدوينًا موحّدًا، ألا وهو نمذجة الكيانات والعلاقات (Entity Relationship Modelling). وتُسمّى المخططات التي تستخدم هذا التدوين مخططات الكيانات والعلاقات (ويُختصر إلى ERD).

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

طُوّر تدوين مخطط الكيانات والعلاقات في عام 1976 على يد بيتر تشن (Peter Chen)، لذا فقد مضى على وجوده سنوات عديدة. وفي الوقت نفسه كان هذا الحاسوب قد طُوّر للتو على يد شركة صغيرة تُسمّى "Apple Computer":

طُوِّر مخطط الكيانات والعلاقات أيضًا ببعض المفاهيم الإضافية للوصول إلى ما يُسمّى نموذج الكيانات والعلاقات الموسّع (Extended Entity Relationship Model، ويُختصر إلى EERD). والمفاهيم المضافة هي التخصيص والتعميم، والأنواع الفرعية والأنواع الفائقة. وسنشرح هذه المفاهيم بإيجاز أيضًا.

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

الكيانات وأنواع الكيانات

ما هي الكيانات وأنواع الكيانات؟

أول مفهومين مهمين داخل مخطط الكيانات والعلاقات هما الكيانات وأنواع الكيانات. يقابل الكيان شيئًا موجودًا في العالم الحقيقي.

وقد يكون شيئًا ماديًا أو شيئًا مجرّدًا، لذا يمكننا الحديث عن أشياء وأشخاص... فالشخص المسمّى "Emma"، والمدينة المسماة "Leuven"، والسيارة ذات لوحة الأرقام "1-AAA-001"، ... كلها أمثلة على كيانات. ومنذ اللحظة التي يوجد فيها ويكون ذا صلة، يمكننا اعتباره كيانًا.

وإلى جانب الكيانات، لدينا أيضًا أنواع الكيانات. نُعرّف أنواع الكيانات بأنها مجموعة من الكيانات المتشابهة. ثم نعطي هذه المجموعة اسمًا يصف الكيانات داخلها بوضوح. ومن أمثلة أنواع الكيانات "Person" و"City" و"Car"... وستلاحظ أننا نسمّي أنواع الكيانات هذه باسم في المفرد وبـحرف كبير في البداية. لا يوجد قانون أو قاعدة تفرض ذلك؛ وإنما نفعل ذلك من أجل الوضوح والاتساق.

وكمثال على ذلك، إذا طوّرت نظامًا نتتبّع فيه معلومات العملاء، فسيكون "Sam Peters" عميلًا، ويكون "Customer" نوع الكيان الذي يصف مجموعة العملاء. ونقول إن Sam تفسير واقعي لنوع معين، وهو في هذه الحالة عميل. وفي سياق هذا القسم من الدورة، سنميّز تمييزًا صارمًا بين الكيان من جهة ونوع الكيان من جهة أخرى. غير أننا نعترف بأن هذا ليس هو الحال دائمًا في المؤلفات المتاحة. ضع ذلك في اعتبارك عند البحث عن مفاهيم معينة في الكتب أو على الإنترنت.

كيف تتعرّف على أنواع الكيانات؟

لإنشاء مخطط كيانات وعلاقات، نبحث عن أنواع الكيانات ذات الصلة. ويتم التعرّف على أنواع الكيانات عادةً باستخدام الأسماء التي تسمعها أثناء مقابلة أو عند قراءة مستندات أو التي تُستخدم في وصف الحل. وكلمات مثل "customer" و"reservation" و"product" و"shop" و"request" و"car"... نقطة بداية جيدة. وغالبًا ما ترغب بعد ذلك في الاحتفاظ بمعلومات عن هذه الأشياء (انظر الخواص)، مما يجعل هذه المفاهيم مرشحات جيدة.

لتقييم المرشحات، يمكننا طرح الأسئلة التالية:

• هل نوع الكيان ذو صلة بتطبيقنا؟ وبعبارة أخرى، هل من الضروري أن نحتفظ بمعلومات عن نوع الكيان؟ هل له دور في كيفية عمل التطبيق؟
• هل نوع الكيان شيء نريد وصفه ونستطيع وصفه؟ وكيف سنصفه؟ وما المعلومات التي يمكننا تخزينها عن نوع الكيان هذا؟
• هل يمكننا التفكير بسهولة في كيانات من نوع الكيان هذا؟ هل لدينا أمثلة على كيانات؟
• هل يمكننا تصوّر أكثر من كيان واحد؟ إذا لم نستطع تصوّر سوى كيان واحد على الأكثر، فهو على الأرجح زائد. ومن أمثلة نوع الكيان الزائد "College" في حالة نظام إداري لكلية UCLL. فبما أننا نتعامل مع كلية واحدة فقط، فإن ذلك سيجعل نموذج البيانات معقدًا بلا داعٍ. ويتغيّر الوضع بمجرد أن يُنشر تطبيقنا لعدة كليات، إذ يتعيّن علينا حينئذ الاحتفاظ بمعلومات عن كل من تلك الكليات.

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

التدوين في مخطط الكيانات والعلاقات

تُمثَّل أنواع الكيانات في مخطط الكيانات والعلاقات بمستطيل يحتوي على اسم نوع الكيان. ونختار كتابة الاسم في المفرد والبدء بحرف كبير. فمثلًا، تُمثَّل أنواع الكيانات "Customer" و"Product" و"Car" كما يلي:

كيف تبدأ؟

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

لتقييم المرشحات، يمكننا طرح الأسئلة التالية:

• هل يمثل نوع الكيان المرشّح مجموعة من الكيانات المختلفة؟ فمثلًا، هل يمثل نوع الكيان "Car" مجموعة من السيارات (سيارة بلوحة أرقام "1-DSY-558"، وسيارة بلوحة أرقام "2-AST-114"، ...)؟ إذا لم نستطع تصوّر سوى كيان واحد من نوع كيان معين، فهو على الأرجح زائد.
• هل نريد الاحتفاظ بـمعلومات عن الكيانات المختلفة لنوع الكيان المرشّح؟ فمثلًا، من نوع الكيان "Car" هل نريد تتبّع رقم اللوحة والصنع والطراز وسنة الصنع...؟ يمكننا وصف كيانات نوع الكيان "Car" باستخدام حقول البيانات هذه (وهو ما سنسميه لاحقًا الخواص).
• هل نوع الكيان المرشّح ذو صلة بحل تكنولوجيا المعلومات الذي نطوّره؟ فمثلًا، في سياق نظام إدارة أسطول لشركة، يُشار إلى أننا نريد الاحتفاظ بنظرة عامة على جميع السيارات المستخدمة. وعندئذ يكون نوع الكيان "Car" ذا صلة بحلّنا.

قد يكون تقييم الأسئلة أعلاه صعبًا أو مربكًا أحيانًا. ففي الأمثلة السابقة، استخدمنا نوع الكيان المرشّح "Car" لاختبار كل سؤال، ولكن ماذا عن نوع الكيان المرشّح "License plate" مثلًا؟ هناك لوحات أرقام متعددة، ويمكننا أيضًا وصف لوحات الأرقام (الرقم، وتاريخ الطلب، وتاريخ الإنشاء، ...)، ونستخدمها لتحديد السيارات، لذا فهي ذات صلة أيضًا.

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

أداة الرسم: Draw.io (diagrams.net)

استخدم draw.io كأداة رسم لمخططات الكيانات والعلاقات. لقد خصصنا صفحة منفصلة عن هذا التطبيق. اطّلع على:

• شرح عام لـ draw.io
• نموذج البيانات المفاهيمي باستخدام draw.io

تمرين نادي الشباب: أنواع الكيانات

أنشئ التمرين 1: نادي الشباب: أنواع الكيانات. وتابع نتيجة التمرين لأننا سنبني النتيجة على عدد من الخطوات.

الخواص

ما هي الخواص؟

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

ومن أمثلة هذه الخواص للكيان "Sam Peters": "Sam" و"Peters" و"04/09/2001" و"21" و"Vilvoorde" و"Board games, rugby, travel"، وهي على التوالي قيم للخواص "First name" و"Name" و"Date of birth" و"Age" و"Place of residence" و"Hobbies".

تُعطى الخاصية اسمًا عامًا يصف صفتها. وتُسمّى القيم الممكنة التي يمكن أن تأخذها الخاصية مجال الخاصية (domain). فمثلًا، يمكن للخاصية المسماة "Residence" أن تأخذ ضمن مجالها "Vilvoorde" و"Leuven" و"Tienen" و"Landen" و"Heverlee"...

لا تُشارَك الخاصية بين عدة أنواع كيانات. فإذا أردت مثلًا تتبّع محل إقامة كل من العميل والموظف، فيتعيّن عليك إضافة الخاصية "City of residence" إلى نوع الكيان "Customer" وإلى نوع الكيان "Employee" معًا.

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

كيف تتعرّف على خاصية؟

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

أحيانًا، بشأن عناصر معينة، عليك الاختيار بين أن تكون نوع كيان أو خاصية لنوع كيان. وبعض النصائح التي يمكننا تقديمها هنا:

• نوع كيان بلا خواص هو صندوق فارغ. لدينا مفهوم لكننا لا نحتفظ بأي معلومات عنه. فما جدوى نوع الكيان هذا؟
• نوع كيان بخاصية واحدة فقط قد يكون خاصية لنوع كيان آخر. ويوجد استثناء لذلك إذا كان لنوع الكيان هذا عدة علاقات مع أنواع كيانات أخرى، وهو ما يُغطّى في القسم التالي.

التدوين في مخطط الكيانات والعلاقات

في سياق مخطط الكيانات والعلاقات، تُمثَّل الخاصية بشكل بيضاوي (ellipse) يحتوي على اسم الخاصية. ثم يُوصل هذا البيضاوي بخط إلى نوع الكيان. ولا يمكن مشاركة الخاصية بين أنواع كيانات مختلفة!

مجال الخاصية (= القيم الممكنة التي يمكن أن تأخذها الخاصية) لا يُعرض في مخطط الكيانات والعلاقات.

تمرين نادي الشباب: الخواص

أنشئ التمرين 2: نادي الشباب، الخواص. وتابع نتيجة التمرين لأننا نواصل بناء النموذج في تمرين لاحق.

العلاقات

ما هي العلاقات؟

يصف نوع الكيان ذو الخواص مفاهيم نجدها ذات صلة والبيانات التي نريد تخزينها عنها. * وتُنشأ المعلومات عندما تُدمج البيانات وتُنشأ العلاقات. * ولوصف هذه الروابط القائمة بين مفاهيم مختلفة، نستخدم العلاقات.

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

مثال على علاقة ينشأ عندما يدخل Sam Peters إلى سوبرماركت ليشتري زجاجة ماء. ففي نهاية المطاف، سيشتري عملاؤنا منتجاتنا. لدينا هنا نوعا كيان: "Customer" (وكيانُه "Sam Peters") و"Product" (وكيانُه "Bottle of water"). وبين نوعي الكيان ننشئ علاقة "Buys". ويتيح لنا نموذج البيانات الآن استخلاص معلومات عن أي العملاء يشترون أي المنتجات.

كيف تتعرّف على علاقة؟

تتعلق العلاقات بالتعرّف على الروابط وتسميتها. وغالبًا ما تُوصف تلك العلاقات بصيغة "هو الـ... الخاص بـ" أو فعل معين. ويمكنك تقييم كل تركيبة لمعرفة ما إذا كان هناك رابط في مكان ما، لكن احذر من إنشاء التكرار. وسنناقش التكرار لاحقًا.

نوع الكيان غير المتصل بأي نوع كيان آخر يدل عادةً على وجود علاقة مفقودة، أو على أن نوع الكيان المعزول غير ذي صلة.

التدوين في مخطط الكيانات والعلاقات

تُرسم العلاقة في مخطط الكيانات والعلاقات على شكل معيّن (diamond) نضع فيه اسمًا للعلاقة. ويُوصل المعيّن بأنواع الكيانات ذات الصلة.

التكرار

الغرض من مخطط الكيانات والعلاقات هو الحصول على أبسط تمثيل ممكن للمعلومات الضرورية. غير أنه من الممكن أن نضيف المعلومات نفسها عدة مرات في نموذج البيانات. ويُسمّى ذلك التكرار (redundancy).

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

لكن هذه العلاقة زائدة. فيمكننا دائمًا اشتقاق هذه المعلومة من الجمع بين العلاقات الأخرى. ولا ينبغي إدراج العلاقة "Buys car in" في مخطط الكيانات والعلاقات.

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

فلنفترض مثلًا أننا نريد تتبّع أن عميلًا يزور كراجًا معينًا، فيمكننا تعريف علاقة "Visits" بين نوعي الكيان "Customer" و"Garage". وقد لا تؤدي الزيارة إلى شراء، لذا نريد فعلًا تتبّع ذلك بشكل منفصل.

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

الدرجة

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

في حالة نوع كيان واحد، نسميها علاقة أحادية (unary relationship) أو علاقة من الدرجة الأولى. وفي حالة نوعي كيان، نتحدث عن علاقة ثنائية (binary relationship) أو علاقة من الدرجة الثانية. وفي حالة ثلاثة أنواع كيانات، نتحدث عن علاقة ثلاثية (ternary relationship) أو علاقة من الدرجة الثالثة. وهكذا. وستكون معظم العلاقات ثنائية، لكن العلاقات الأحادية والثلاثية... تحدث بالتأكيد.

مثال على علاقة أحادية هو "Is married to" حيث يكون كيان من نوع الكيان "Person" متزوجًا من كيان من النوع نفسه.

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

مثال على علاقة ثنائية هو "Is pilot" حيث يُسنَد كيان من نوع الكيان "Pilot" إلى كيان من نوع الكيان "Scheduled flight". وكما يوضح المثال أدناه أيضًا، من الممكن أن توجد علاقات متعددة بين نوعي كيان، إذ عرّفنا أيضًا علاقة ثنائية "Is co-pilot". فبالنسبة لرحلة مجدولة، سيُسنَد طيار واحد كطيار (رئيسي) وطيار آخر كطيار مساعد. وبناءً على النموذج، نحتفظ بمعلومات الدورين.

مثال على علاقة ثلاثية هو "Prescribes" حيث ترتبط كيانات من أنواع الكيانات "Patient" و"Doctor" و"Medication" ببعضها.

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

وبدلًا من ذلك، يمكن نمذجة العلاقة الثلاثية أعلاه كنوع كيان "Prescription". وهنا سنستبدل العلاقة "Prescribes" التي تربط أنواع الكيانات "Patient" و"Doctor" و"Medication" بنوع كيان "Prescription" يُوصل في كل مرة بعلاقة ثنائية بأنواع الكيانات "Patient" و"Doctor" و"Medication". ولكل وصفة، نعرف حينئذ أي مريض يتلقى الوصفة، وأي طبيب يكتب الوصفة، وأي دواء يُوصف.

وميزة هذا النهج أننا نستطيع إرفاق خواص إضافية بنوع الكيان هذا. فمثلًا، يمكننا إضافة الخاصية "Date". وبهذه الطريقة، نعرف أيضًا التاريخ الذي كُتبت فيه الوصفة.

ويمكنك الآن أن تسأل: أي الحلين أفضل، الحل ذو العلاقة الثلاثية "Prescribes" أم الحل ذو نوع الكيان "Prescription"؟ والجواب أن كلا الحلين صحيح. وفي المحصلة النهائية، سيؤديان إلى النتيجة نفسها.

التعددية في العلاقة

كما ذُكر سابقًا، تربط العلاقة نوع كيان واحدًا أو أكثر. وتتيح لنا نمذجة الكيانات والعلاقات زيادة دقة طبيعة تلك العلاقة بإدراج معلومات إضافية. فمثلًا، يمكننا تحديد بعدد كيانات نوع كيان معين التي ينبغي وأن يستطيع كيان من نوع كيان آخر الارتباط بها. ونفعل ذلك بتحديد التعددية (cardinality) للعلاقة. وتتكوّن كل تعددية من جزأين: تعددية دنيا وتعددية عليا. ويُحدَّد ذلك لكل نوع كيان داخل العلاقة على حدة.

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

داخل مخطط الكيانات والعلاقات، توجد عدة صيغ تدوين للتعددية. وفي سياق هذه الدورة، نستخدم تدوين (min, max) لنماذج البيانات المفاهيمية. وإلى جانب تدوين (min, max)، سنستخدم تدوين قدم الغراب (crow's foot notation) في نماذج البيانات المنطقية، حتى تعرف كلا التدوينين.

التعددية الدنيا (أو قيد المشاركة)

تشير التعددية الدنيا إلى ما إذا كانت العلاقة اختيارية أو إلزامية

لجميع كيانات نوع كيان محدد. وهناك قيمتان محتملتان: "0" و"1":

• القيمة "0" تشير إلى أن العلاقة بالنسبة لنوع الكيان المحدد اختيارية. والاختيارية تعني أن الكيان يمكن أن يوجد دون أن تكون له علاقة بكيانات أنواع الكيانات الأخرى في العلاقة.
• القيمة "1" تشير إلى القيد القائل بأن الكيان لا يمكن أن يوجد إلا إذا كانت له علاقة. وبعبارة أخرى، لا يمكن أن يوجد كيان من نوع الكيان هذا إلا إذا كانت له علاقة واحدة على الأقل بكيانات أنواع الكيانات الأخرى داخل العلاقة.

قد يبدو هذا مجرّدًا بعض الشيء، لذا لنوضّحه قليلًا بمساعدة أمثلة. المثال الأول هو العلاقة "Buys" بين نوعي الكيان "Customer" و"Product". والآن اطرح السؤال التالي: هل يمكن أن يوجد منتج دون أن يشتريه عميل؟ الجواب "نعم"، لأن المنتجات الجديدة التي لم نبعها بعد قد تكون موجودة فعلًا في النظام. لذا فإن التعددية الدنيا لنوع الكيان "Product" في العلاقة "Buys" هي "0".

والسؤال التالي الذي نطرحه: هل يمكن أن يوجد عميل دون أن يشتري منتجًا؟ الإجابة عن هذا أصعب بالفعل، لأنها ستعتمد كثيرًا على كيفية تشغيل المتجر. فإذا كان بإمكان العميل التسجيل المسبق دون إجراء عملية شراء، فيمكن أن يوجد عميل دون أن يشتري منتجًا، وتكون التعددية الدنيا "0". أما إذا كان العميل لا يُنشأ إلا بمجرد أن يشتري منتجًا، فتكون قيمة التعددية الدنيا "1".

لنفترض للحظة أن العميل لا يصبح عميلًا إلا بمجرد أن يشتري شيئًا، أي بتعددية دنيا "1".

داخل مخطط الكيانات والعلاقات، سنضع التعددية الدنيا حيث يلامس الخط القادم من المعيّن الذي يمثل العلاقة المربعَ الذي يمثل نوع الكيان. ونكتب (0, ...) أو (1, ...).

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

التعددية العليا (أو قيد التعددية)

تحدد التعددية العليا ما إذا كان يمكن أن يكون لكيان من نوع كيان علاقات متعددة من النوع نفسه. ولدينا قيمتان محتملتان: 1 أو N.

• القيمة 1 تشير إلى أن كيانًا من نوع كيان يمكن أن تكون له علاقة واحدة على الأكثر من نوع معين.
• القيمة N تشير إلى أن كيانًا من نوع كيان يمكن أن تكون له علاقات متعددة من نوع معين.

لنوضّح ذلك مرة أخرى بمثالنا السابق حيث يشتري العملاء منتجات. ونسأل أنفسنا السؤال التالي: هل يمكن للعميل أن يشتري أكثر من منتج واحد؟ الجواب "نعم"، ما يعني أن لدينا تعددية عليا "N". وإذا جمعنا ذلك مع التعددية الدنيا، يمكننا القول إن العميل يمكن أن يشتري "1" على الأقل و"N" على الأكثر من المنتجات، ويُلخَّص ذلك بـ (1, N).

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

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

داخل مخطط الكيانات والعلاقات، سنضيف التعددية العليا بعد التعددية الدنيا. ونكتب (<التعددية الدنيا>, 1) أو (<التعددية الدنيا>, N). وعندما تظهر تعددية عليا N عدة مرات داخل النوع نفسه من العلاقة، نميّز بينها باستخدام M أو O أو P... بدلًا من تكرار N. وبذلك نريد التأكيد على أن هذه تمثل قيمًا مختلفة في كل مرة، لكنها أكبر من "1" في كل مرة.

كيف ينبغي أن تقرأ الشكل أعلاه؟ "Product" في العلاقة "Buys" لها تعددية دنيا "0"، أي أن المنتج يمكن أن يوجد دون أن يُباع. والتعددية العليا لـ "Product" في العلاقة "Buys" هي "1"، أي أن المنتج لا يمكن أن يشتريه إلا عميل واحد.

"Customer" في العلاقة "Buys" لها تعددية دنيا "1"، ما يعني أن العميل لا يمكن أن يوجد دون أن يشتري منتجًا. فلا بد أن توجد له علاقة بمنتج واحد على الأقل. والتعددية العليا لـ "Customer" في علاقة "Buys" هي "N"، ما يعني أن العميل يمكن أن يشتري منتجات متعددة، وبالتالي يمكن أن يرتبط بمنتجات متعددة.

التعددية: مثال مدرسة الكلاب

لعل ما سبق كان نصًا كثيرًا. ويحاول الفيديو التالي شرح التعددية بمثال جديد:

أنواع العلاقات

من العلاقات الثنائية، نميّز ثلاثة أنواع مختلفة.

علاقة 1-1

النوع الأول علاقة 1-1 (علاقة واحد إلى واحد) حيث التعددية العليا لنوعي الكيان كليهما داخل العلاقة هي "1". وبذلك يمكن لكل كيان من أحد نوعي الكيان أن تكون له علاقة واحدة على الأكثر بكيان من نوع الكيان الآخر. وهذا ينطبق في الاتجاهين.

مثال على علاقة 1-1 علاقة "Has" حيث يمكن أن يرتبط كيان (مثل "Sam Peters") من نوع الكيان "Person" بكيان واحد على الأكثر من نوع الكيان "Identity card"، ويمكن أن يرتبط كل كيان من نوع الكيان "Identity card" بكيان واحد على الأكثر من نوع الكيان "Person". فلكل شخص بطاقة هوية واحدة على الأكثر، وكل بطاقة هوية تنتمي إلى شخص واحد بالضبط.

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

التعددية الدنيا لا دور لها في هذا التصنيف. فنحن نعتبر التعددية العليا فقط.

علاقة 1-N

النوع الثاني علاقة 1-N (علاقة واحد إلى متعدد) حيث تكون التعددية العليا لأحد نوعي الكيان "N" وللآخر "1". ويمكن لكل كيان من نوع الكيان ذي التعددية العليا "N" أن يرتبط بعدة كيانات من نوع الكيان ذي التعددية العليا "1". وبالعكس، يمكن لكل كيان من نوع الكيان ذي التعددية العليا "1" أن يرتبط بكيان واحد على الأكثر من نوع الكيان ذي التعددية العليا "N".

مثال على علاقة 1-N علاقة "Buys" حيث يمكن لكيان (مثل "Sam Peters") من نوع الكيان "Customer" أن يشتري عدة كيانات من نوع الكيان "Car"، لكن كل كيان من نوع الكيان "Car" يمكن أن يُباع لكيان واحد على الأكثر من نوع الكيان "Customer". فيمكن للعميل أن يشتري عدة سيارات، لكن كل سيارة يمكن بيعها مرة واحدة على الأكثر (لن نأخذ البيع المستعمل في الاعتبار في الوقت الحالي). والمهم في هذا المثال أن كل سيارة قابلة للتحديد بشكل فردي وأن معرفة أي عميل اشترى أي سيارة أمر ذو صلة.

كذلك التعددية الدنيا لا دور لها في هذا التصنيف.

علاقة N-M

النوع الثالث علاقة N-M (علاقة متعدد إلى متعدد) حيث تكون التعددية العليا لنوعي الكيان كليهما "N" (أو "M" أو "P"...). ويمكن لأي كيان من أحد نوعي الكيان أن تكون له علاقات متعددة بكيان من نوع الكيان الآخر. وهذا ينطبق في الاتجاهين.

مثال على علاقة N-M علاقة "Buys" حيث يمكن لكيان (مثل "Sam Peters") من نوع الكيان "Customer" أن يشتري عدة كيانات من نوع الكيان "Product"، ويمكن لكل كيان من نوع الكيان "Product" أن يشتريه عدة كيانات من نوع الكيان "Customer". فيمكن للعميل أن يشتري منتجات متعددة، ويمكن لكل منتج أن يشتريه عدة عملاء. والمهم في هذا المثال أنه ليس ذا صلة تحديد كل قطعة مباعة بشكل فردي. فنحن نريد تتبّع أن العميل "Sam Peters" اشترى زجاجة ماء، لكن ليس أي زجاجة بعينها، بخلاف مثال السيارة حيث نريد تتبّع ذلك.

تمرين جمعية الشباب: العلاقات

أنشئ التمرين 3: نادي الشباب: العلاقات. واحتفظ بنتيجة التمرين لأننا سنوسّعها في وقت لاحق.

أنواع الخواص

الخواص المفتاحية

لتحديد الكيانات تحديدًا فريدًا، نستخدم الخواص المفتاحية. والخواص المفتاحية لنوع كيان هي الخواص التي تتيح تحديد كل كيان من نوع الكيان تحديدًا فريدًا.

مثال على خاصية مفتاحية لنوع الكيان "Student" خاصية "Student number". فكل طالب قابل للتحديد بشكل فريد برقمه الجامعي. وبالنسبة للسيارة، لديك اختيار: يمكنك استخدام رقم الهيكل (Vehicle Identification Number أو VIN) أو لوحة الأرقام. وستعلّمك بعض البحث أن رقم الهيكل خيار أفضل، لذا تستخدمه كخاصية مفتاحية.

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

المفاتيح مكوّنات مهمة في نموذج قاعدة البيانات العلائقية، لذا سنعود إليها بالتفصيل في سياق نموذج البيانات المنطقي.

الخواص المشتقة

يمكن، في بعض الحالات، اشتقاق الخواص من خواص أخرى. ونشير إلى هذه الحالات بالخواص المشتقة.

مثال على خاصية مشتقة خاصية "Age" عندما تكون لدينا أيضًا الخاصية "Date of birth". وباستخدام حساب قائم على هذا التاريخ، يمكننا تحديد العمر أيضًا.

وتُشار إلى الخاصية المشتقة في مخطط الكيانات والعلاقات ببيضاوي مرسوم بخط منقّط يُوضع فيه اسم الخاصية.

والخاصية التي تُستخدم لاشتقاق القيمة يلزم أيضًا أن تكون موجودة في نموذج البيانات. ففي حالة "Age" يجب أن تكون "Date of birth" موجودة أيضًا. ولا يمكن الإشارة في مخطط الكيانات والعلاقات إلى أن "Age" مشتقة تحديدًا من "Date of Birth"؛ عليك بيان ذلك في التوثيق أو في ملاحظة على النموذج.

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

وبالمناسبة، يمكن أيضًا اشتقاق خاصية مشتقة بناءً على خواص أنواع كيانات أخرى. فالخاصية "Number of credits" لكيان من نوع الكيان "Enrolment" يمكنك اشتقاقها من الخاصية "Number of credits" لكيانات من نوع الكيان "Course unit" المضمّنة داخل التسجيل.

الخواص المركّبة والبسيطة

يمكن أن تكون الخاصية مركّبة أو بسيطة. فالخواص المركّبة يمكن تقسيمها إلى خواص أخرى (مركّبة أو بسيطة). أما الخواص البسيطة فلا يمكن تقسيمها أكثر من ذلك.

مثال على خاصية مركّبة لنوع الكيان "Person" خاصية "Address". فالعنوان يتكوّن من الشارع ورقم المنزل... وبعبارة أخرى، يمكننا أيضًا استبدال الخاصية "Address" بالخواص "Street" و"House number"...

في مخطط الكيانات والعلاقات، لن نميّز بين المركّبة والبسيطة. فلا يوجد فرق في التدوين.

الاختيار بين الخواص المركّبة والبسيطة هو توازن بين البساطة وقابلية القراءة من جهة والصحة والاكتمال من جهة أخرى. وغالبًا ما نفضّل الصحة والاكتمال.

الخواص أحادية القيمة ومتعددة القيم

تحتوي الخاصية عادةً على قيمة واحدة على الأكثر لكيان معين. فمثلًا، لنوع الكيان "Student"، وللكيان "Sam Peters"، ستحتوي الخاصية "First name" على القيمة "Sam". وهكذا، لدينا لكل كيان قيمة واحدة على الأكثر لخاصية معينة. ونتحدث في هذه الحالة عن خاصية أحادية القيمة.

ومن الممكن أيضًا تعريف خواص متعددة بحيث يمكن أن تكون لخاصية كيان معين قيم متعددة. فمثلًا، من الممكن أن يكون لطالب عدة عناوين بريد إلكتروني. ولنوع الكيان "Student"، وللكيان "Sam Peters"، يمكن أن تحتوي الخاصية "Email address" على القيمتين "sam.peters@gmail.com" و"huppeldepup@gmail.com". و"Email address" في هذه الحالة خاصية متعددة القيم.

وتُشار إلى الخاصية متعددة القيم في مخطط الكيانات والعلاقات ببيضاوي مزدوج الحدود يُوضع فيه اسم الخاصية.

خاصية العلاقة

في بعض علاقات N-M، تلاحظ أنك لا تستطيع وضع خواص معينة مع أي من نوعي الكيان.

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

ويريد عميلنا أيضًا معرفة اليوم والوقت المحددين لتجربة القيادة، لذا نريد إضافة الخاصيتين "Day" و"Time of day". وإذا أضفنا هاتين الخاصيتين إلى نوع الكيان "Car"، فذلك يعني أننا نستطيع تعيين يوم واحد ووقت واحد لكل كيان من "Car". ولكن بما أن أكثر من شخص يمكن أن يطلب تجربة قيادة، فقد تُسجَّل أوقات مختلفة لسيارة واحدة. ويمكننا تحويل "Day" و"Time of day" إلى خاصيتين متعددتي القيم لنوع الكيان "Car". لكن حتى ذلك ليس خيارًا؛ فسيكون لدينا عدة أيام لكل كيان من "Car" وأوقات متعددة، لكننا لن نعرف حينئذ أي عميل تنتمي إليه هذه.

وإذا أضفنا الخاصيتين إلى نوع الكيان "Customer"، فواجهنا مشكلة مشابهة. فيمكن للعميل أن يجرّب عدة سيارات، وقد يكون ذلك في يوم ووقت مختلفين. فإذا أضفنا ذلك كخاصية إلى نوع الكيان "Customer"، فستكون لجميع تجارب القيادة التاريخ والوقت نفسهما. ويمكننا أن نستنتج أن إضافة الخاصيتين "Day" و"Time of day" إلى نوع الكيان "Customer" ليست خيارًا أيضًا.

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

تنبيه * يمكن أن توجد خاصية العلاقة في حالة علاقة N-M. * أما بالنسبة لجميع أنواع العلاقات الأخرى، فذلك غير ممكن، لأننا نستطيع دائمًا إرفاق الخاصية بأحد نوعي الكيان.

تمرين نادي الشباب: أنواع الخواص

أنشئ التمرين 4: نادي الشباب، أنواع الخواص.

تمرين شركة تأجير السيارات

أنشئ التمرين 5: شركة تأجير السيارات.

الكيانات الضعيفة والقوية

داخل أنواع الكيانات، يمكننا إجراء تمييز آخر بين أنواع الكيانات الضعيفة وأنواع الكيانات القوية (وتُسمّى أيضًا أنواع الكيانات العادية). يصف نوع الكيان الضعيف مجموعة من الكيانات لا يمكن أن توجد بمفردها. فالكيانات تعتمد على وجود كيانات أخرى.

مثال على نوع كيان ضعيف "Enrolment" في كلية UCLL. فلا يمكن أن يوجد تسجيل إذا لم يوجد طالب. وبعبارة أخرى، لا بد أن يكون كيان "Sam Peters" من نوع الكيان "Student" قد أُنشئ بالفعل قبل أن نسجّل Sam. وسيحتوي كيان نوع الكيان "Enrolment" على إشارة إلى كيان نوع الكيان "Student". لذا تلزم في مخطط الكيانات والعلاقات علاقة بين نوعي الكيان.

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

ويُحدَّد نوع الكيان الضعيف في مخطط الكيانات والعلاقات بمربع مزدوج الحدود يحتوي على اسم نوع الكيان. وتُعرض العلاقة بين نوع الكيان الضعيف والقوي على شكل معيّن مزدوج الحدود.

لاحظ أننا في مخطط الكيانات والعلاقات لا نأخذ الخاصية المحدِّدة لنوع الكيان "Student" بوصفها الخاصية المحدِّدة لـ "Enrolment". غير أننا نستطيع استنتاج ذلك من التدوين بالمستطيلات والمعينات مزدوجة الحدود.

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

تمرين إدارة الطلاب

أنشئ التمرين 6: إدارة الطلاب.

مخطط الكيانات والعلاقات الموسّع (EERD)

وُسِّع مخطط الكيانات والعلاقات ليشمل عددًا من المفاهيم من أجل نمذجة نسخ أكثر تعقيدًا من الواقع.

الأنواع الفرعية والأنواع الفائقة

يكون نوع الكيان نوعًا فرعيًا من نوع كيان آخر إذا ورث نوع الكيان الأول جميع خواص وعلاقات نوع الكيان الثاني ووسّعه بخواصه وعلاقاته الخاصة. ونوع الكيان الثاني هو نوع كيان أكثر عمومية له بعض الخواص والعلاقات العامة، ونسميه النوع الفائق.

فمثلًا، من أمثلة الأنواع الفرعية والأنواع الفائقة نوع فائق "Employee" ونوعان فرعيان "Temporary employee" و"Permanent employee". ومن نوع الكيان "Employee" نحتفظ بالخصائص النموذجية: الاسم، والاسم الأول، وتاريخ الميلاد، ورقم الموظف... وإضافة إلى ذلك، لدينا نوع الكيان "Temporary employee" الذي يرث جميع الخواص والعلاقات من نوع الكيان "Employee"، لكنه يوسّعه بالخاصيتين "Contract start date" و"Contract end date". ويوسّع نوع الكيان "Permanent employee" نوعَ الكيان "Employee" بالخاصيتين "Employee start date" و"Number of years service".

ويمكن أن تكون الأنواع الفرعية متداخلة (overlapping) أو منفصلة (disjoint):

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

المثال أعلاه منفصل، لأن الموظف إما عامل مؤقت وإما عامل دائم، ولكن ليس كليهما أبدًا.

ويمكن أن تكون الوراثة كلية أو اختيارية:

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

المثال أعلاه كلي، إذ يجب أن يكون كل موظف إما موظفًا مؤقتًا وإما موظفًا دائمًا.

وكل كيان من نوع فرعي هو أيضًا كيان من النوع الفائق. والعلاقة بين نوع فرعي ونوع فائق هي علاقة 1-1. والخاصية المفتاحية للنوع الفائق تصبح أيضًا الخاصية المفتاحية للأنواع الفرعية. وهذا أمر مفروض بالوراثة، لذا لا ينبغي إضافته.

التدوين في مخطط الكيانات والعلاقات

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

التعميم والتخصيص

وتُعرف عملية تعريف الأنواع الفرعية والأنواع الفائقة أيضًا بالتعميم والتخصيص:

• يشير التعميم (generalisation) إلى العملية التي نُنشئ بها، لعدد من أنواع الكيانات المتشابهة، نوعًا فائقًا نجمع فيه الخواص والعلاقات المشتركة، ومنه ترث أنواع الكيانات الأولية.
• يبدأ التخصيص (specialisation) من نوع كيان تُنشأ له عدة أنواع فرعية، لكل منها مجموعة خواصها أو علاقاتها الخاصة المختلفة عن الأنواع الفرعية الأخرى.

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

متى تُطبَّق؟

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

تمرين المكتبة

أنشئ التمرين 7: المكتبة.