رحـــــلة فـــــــــــــــــي كتـــــــــــــــــــــاب

الفصل الأول : مفاهيم قاعدة البيانات

في البداية يأخذنا الكاتب الي الحديث عن مفهوم قواعد البيانات بطرح سؤال من النوع المشوق حيث يقول

ما هو هذا الكائن الأسطوري الذي يدعي قاعدة البيانات ؟ ثم يجيب عن السؤال بطريقة أكثر تشويقا حيث يقول

في الماضي كان يعرف بقاعدة البيانات بأنها أداة تخزين ومعالجة المعلومات بكفاءة وفعالية. "بكفاءة وفعالية" يعني أن تتم حماية البيانات من الضياع أو التلف، كما تغني عن إستخدام المزيد من الموارد (البشرية أو الكمبيوتر) اكثر من اللزوم، والتي يمكن استرجاع المعلومات المخزنة فيها بطرق معقولة في ظل قيود أداء مقبولة . وحتي تكون قاعدة البيانات مؤهلة لوصفها قاعدة بيانات علائقية فإنها يجب ان تتطابق مع نموذج البيانات Data Model وما هو نموذج البيانات ... يجيبنا الكاتب بأن هذه القاعدة يجب ان تتفق مع القوانين التي وضعها العالم E.F Codd في عام 1969 .

ولكن ماذا كان شكل قواعد البيانات قبل عام 1969 يجيبنا في هذا الأخ Internet Master في موضوعه – الأسس العلمية لقواعد البيانات – بأنها كانت من النوع المسطح Flat DataBase وقد سرد لنا مثالا توضيحيا نستعيره منه بعد موافقته التي لا أظن أنه سيبخل بها علينا حيث قال .

إن ما قمت بتنفيذه هو قاعدة بيانات صحيحة مكتملة الجوانب وطريقة التصميم هذه تسمىFlat Databases أو قواعد البيانات المسطحة وهي نفس الطريقة المتبعة في لغة COBOL ولا أعلم إن كانت COBOL مازالت تتبع نفس الأسلوب حيث تركت هذه اللغة منذ أكثر من 10 أعوام.

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

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

نحفظ سوياً: قواعد البيانات من النوع المسطح Flat هي عبارة عن جدول واحد فقط فيه كافة الحقول المطلوبة وتتميز بسرعة تنفيذ وتصميم قاعدة البيانات.

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

سؤال: بماذا تتميز قواعد البيانات من النوع Flat؟

سؤال: ما هي قواعد البيانات من النوع Flat؟

نعود إلى المستوصف، نحن الآن في قاعة إستقبال المرضى في المستوصف.

يدخل المستوصف مريض:

العمر: 42 عاما

الإسم: محمد عبد الله

الجنسية: سعودي

الجنس: ذكر

المرض: إنفلوانزا

نطلب منه كافة المعلومات ثم نقوم بتحويله إلى:

الطبيب: سميرة عبد الخالق

الجنس: أنثى

العمر: 52

الجنسية: مصرى

ونقوم بتوجيه المريض إلى الطابق الثاني حيث تقع عيادة الأنف والأذن والحنجرة.

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

ما الذي حدث؟

تم إضافة سجل جديد في قاعدة البيانات المسطحة التي قمنا بإنشائها.

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

دخل محمد عبد الله مرة أخرى إلى المستوصف وتم توجيهه إلى طبيب العظام لإجراء تجبير للكسر في ساقه.

ما الذي حدث؟ --- قمنا بإضافة سجل جديد في قاعدة البيانات الخاصة بالمستوصف

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

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

ما الذي حدث؟ قمنا بإضافة سجل جديد إلى قاعدة بيانات المستوصف.

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

في هذه الليلة قام مدخل البيانات بإدخال ثلاثة سجلات، بماذ تميزت هذه السجلات؟

تميزت بأن أحد عناصر قاعدة البيانات وهو (المريض) قد تكرر تسجيل بياناته ثلاث مرات

ماذا يعني هذا؟

يعني:

أنه عند تكرار دخول المريض للمستوصف أكثر من مرة يتطلب الأمر في كل مرة إدخال كافة بياناته كاملة.

أنه عند تكرار إستخدام الطبيب (مثل أن يدخل خمسة مرضى على طبيب العظام) يتطلب الأمر إعادة إدخال بيانات الطبيب مرة أخرى.

أنه عند تكرار إستخدام أي عيادة (مثلا عشرة مرضى تم علاجهم من قبل ثلاثة أطباء كلهم في العيادة الباطنية) يتطلب الأمر إعادة إدخال كافة بيانات العيادة.

الخلاصة:

في قواعد البيانات المسطحة يتم إعادة إدخال بيانات أي عنصر يتكرر أكثر من مرة.

الآن سأذهب لشرب فنجان من القهوة وأتمتع بقليلا من التمر... وعندما أعود بعد بضعة دقائق أتمنى من الجميع أن يكونوا قد فكروا في إجابة السؤال التالي.

ما هي المشكلة من تكرار إدخال البيانات؟

توقفنا عند السؤال التالي:

ما هي المشكلة من تكرار إدخال البيانات؟

الجواب: مشاكل جمة لا عد ولا حصر لها !!!!

أهم هذه المشاكل:

تكرار بيانات موجودة أصلاً

إستنزاف شديد للسعات التخزينية مثل الأقراص الصلبة

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

أما المشكلة الأكبر هي عند إضافة حقل جديد لقاعدة البيانات، مثلا إضافة تاريخ الميلاد للمريض !!! يتطلب الأمر الآن إدخال نفس التاريخ في كافة السجلات فإذا كان لدينا 500 زيارة منها 42 زيارة للأخ محمد عبد الله يتطلب الأمر إعادة إدخال تاريخ الميلاد 45 مرة !!!

تكرار إدخال البيانات هو أحد مصائب وليس مشاكل قواعد البيانات المسطحة وكانت مرتعا خصبا للأبحاث في قبل عام 1970 ميلادية.

العالم الخطير السيد CODD والذي يعمل في شركة IBM قام في عام 1969 ميلادية بطرح أول نظرية تقوم بعلاج مشاكل قواعد البيانات المسطحة Flat وتم تسميتها قواعد البيانات العلاقية Relational Databases

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

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

إن القوانين التي وضعها هذا العالم (الذكي جدا طبعا) تم تبنيها من قبل الشركات العالمية وبدأت تنتج برامج تعتمد على هذه القوانين وتتيح هذه البرامج لمستخدميها بتصميم قواعد بيانات علاقية Relational ولصعوبة هذه القوانين يكفي أن تعلم عزيزي القارىء أن أفضل قاعدة بيانات تم تصميمها في العالم إلتزمت ب 8 قوانين فقط من 12 الأصلية !!!

أي أن التطوير في برامج قواعد البيانات مثل أوراكل وآكسس وSQL وغيرها مازال قاصرا عن الوفاء بكل قوانين السيد CODD.

قبل الخوض في قواعد البيانات من النوع العلاقي Relational نقول التالي:

أن قواعد البيانات من النوع Relational تقول بحل كافة مشاكل قواعد البيانات المسطحة بل تؤدي إلى Integrity (مين يذكر هذا المصطلح؟) أفضل بكثير وتسهل عمليات تحديث وتطوير قاعدة البيانات.

ولكن الثمن المقابل لهذا الميزات غير رخيص !!!!

فقواعد البيانات من النوع العلاقي:

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

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

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

لا يوجد نوع آخر لقواعد البيانات في العالم غير هذين النوعين:

مسطح Flat ذي تكلفة منخفضة في التصميم وتكلفة مرتفعة في الصيانة والتطوير ويعاب عليه تكرار البيانات التي تؤدي إلى رفع تكلفة التخزين وبطىء البحث والإسترجاع والإستعلام وغيره.

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

تحياتي،،،

نعود الي الكتاب حيث يقول :-

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

وفي تصور الكاتب لا يوجد حتي ألآن نظام إستطاع ان يتوافق مع كل القوانين

سوف نستخدم في هذا الكتاب نظامان لإدارة قواعد البيانات وهما Microsoft Jet و MS Sql Server وقاعدة بيانات Northwend

النص الأصلي : -

So, what is this mythical creature called a relational database? Briefly, a database is a tool for storing and manipulating information efficiently and effectively. "Efficiently and effectively" means that the data is protected from accidental loss or corruption, that it doesn't use more resources (human or computer) than necessary, and that it can be retrieved in sensible ways within acceptable performance constraints. To qualify as relational, the database must implement the relational model, which is a way of describing some aspect of the real world according to a set of rules first proposed by Dr. E. F. Codd in the late 1960s.

In theory, a relational database could be coded from scratch, but in reality you'll normally use the services of a database management system (DBMS). A DBMS is sometimes called a relational database management system (RDBMS), but technically a DBMS must meet some 300 rules to qualify as relational, and, to the best of my knowledge, no commercially available system fully qualifies. The two database management systems we'll be examining in this book are Microsoft Jet and Microsoft SQL Server.

I've said that a relational database is the physical implementation of the relational model (the data model), and it's important to keep these two concepts distinct. As we'll see in Part II, the dimensional model can also be implemented on a relational DBMS, and if you muddy the conceptual and physical, you'll get yourself hopelessly confused. (And yes, that is the voice of experience!)

اخي الفاضل : خالد

بارك الله بك وجزاك الله كل خير

استمر على هذا المنوال

واتمنى في نهاية الشرح لهذه المقاله ان تضع الكتاب بصيغة PDF سواء الإنجليزي او المترجم لتعم الفائده لجميع اعضاء المنتدى

ولك مني +1

بالتوفيق

السلام عليكم ورحمة الله وبركاته

كلنا معك أخي الكريم وبدون تردد +1 من عندي

السلام عليكم

جزاك الله خير اخي

فللاستاذ ماستر انترنت له فضل علينا كبير

والله يحميه من كل مكروه اينما حل

ومحيا ذكراه لها شوق علينا.

لك مني +1

أختتنا العزيزة زهرة الأكسيس ... أرجو لك توفيقا من الله في رحلتك العلمية ... وأن تحتلي أرفع المناصب العلمية ...فنجاحك هو نجاحنا جميعا ... وفقك الله لما يحب ويرضي

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

أشكركم ... ونتمني جميعا من الله أن نساهم في تعليم غيرنا وأنفسنا ولة حرف واحد وصدق رسول الله (ص) حينما قال " خيركم من تعلم العلم وعلمه

- يجيبنا الكاتب بقوله : إن مصطلح قواعد البيانات كجزء من البيئة المنسوب إليها " البرمجة الشيئية أو برمجة تحديد الأشكال " object oriented programmingهو مصطلح يتصف بالمرواغة وعدم التحديد والشمول الواسع ولنتوقف برهة هنا و حتي نفهم ما يقال يجب أن نأخذ لمحة عن هذا المفهوم فما هي object oriented programming

خلال بحثي في المواقع المختلفة وجدت شرحا بسيطا لهذا المفهوم حيث قال الكاتب في منتدي دردشة السعوي

(خلال الأسطر القليلة التالية، سنلقي الضوء على مفهوم البرمجة الكائنية أو الشيئة Object Oriented Programming وهي ما يطلق عليه اختصاراً OOP، ماهيتها ومميزاتها.

فكّر بالكائنات Think about Objects:

ستتعرف في هذا الجزء على أهم المصطلحات المستخدمة في الـOOP كما ستفهم فكرة الـOOP إن شاء الله!

لو نظرنا حولنا في عالمنا الحقيقي لوجدنا جميع ما يحيط بنا عبارة عن "كائنات Objects": الناس، الحيوانات، النباتات، السيارات، الطائرات، البنايات، وحتى الكمبيوترات وغيرها. هذا هو معنى كلمة "كائن Object"، ومن الممكن أن نطلق نفس المصطلح على أي ممثل لأي فئة، فنطلقه على الفراولة لأنها تمثل أحد الفواكة، أو نطلقه مثلاً على الطاووس لأنه يمثل أحد الطيور... وهكذا.

ويمكننا تصنيف الكائنات إلى صنفين:

كائنات نشطة (حية) Animate Objects: وهي التي نحس فيها فنجد لها حركة ونشاط.

كائنات غير نشطة (غير حية) Inanimate Objects: هي التي لا نلاحظ لها نشاط أو حركة أو وقع أينما وجدت. وجميع الكائنات بصنفيها لها:

خصائص Attribute مثل: الحجم، اللون، الوزن، الشكل...ألخ.

سلوك Behavior فمثلاً: الطفل (كائن) يبكي، وينام، ويمشي، ويأكل (سلوكيات).

الإنسان وخصوصاً المبرمج يتعلم عن الكائنات بمعرفة خصائصها، وملاحظة (تجربة) سلوكها، فمن الممكن أن يكون لكائنات مختلفة نفس الخصائص وسلوك متقارب.

البرمجة الشيئية Object Oriented Programming تقوم بنمذجة Modeling كائنات العالم الحقيقي في برنامج نظير software counterpart. هذا البرنامج يحمل إيجابيات العلاقات بين الفئات classes relationships حيث أن أي كائن من أي فئة يحمل جيمع مميزات وصفات characteristics هذه الفئة أو بالأحرى يرثها لأنه ممثل لفئته. كما أن الفئات الجديدة -تسمى فئة فرعية subclass- ترث صفات الفئات التي أُنتجت وتكونت منها -تسمى الفئة الأم superclass- كما يرث الطفل جينات أبويه. وهذه الفئة الجديدة والتي تعتبر subclass، من الممكن أن تكون superclass لفئات جديدة أخرى ينشئها المبرمج.

الـOOP كذلك تقوم باحتواء البيانات (Data (attributes والطرق (Methods (behavior في حزمة package هي ما نطلق عليه "كائنات Objects"؛ حيث أن بيانات وطرق أي كائن ترتبط ببعضها ارتباط وثيق. هذا الكائن يتميّز بخاصية التخفي Information Hiding نعني بالتخفي هنا أنه بإمكان الكائنات الاتصال والتعامل مع بعضها البعض مع عدم معرفة أحدها كيف تكوّن الآخر! أي أن تفاصيل التكوين هي المخفيّة حتى عن الكائنات نفسها؛ فمن المؤكد أننا نعرف كيف نقود السيارة بكفاءة عالية دون معرفة تفاصيل هندستها. تسمى هذه الخاصية في البرمجة بـAbstraction أي تجريد البيانات.

برامج الجافا جميعها قائمة على برمجة المبرمج لمجموعة فئات خاصة به تسمى user-defined classes باستخدام الفئات والمميزات التي توفرها اللغة ومن ثم استخدام هذه الفئات جميعها أو بعضها في برامجه :)

حيث أن كل فئة تحتوي على بيانات data ومجموعة دوال functions تقوم بتشكيل هذه البيانات، تسمى البيانات في فئات الجافا بـ: instance variable أو data member. ويطلق على الدوال اسم الطرق methods. فأي طلب لأي فئة معرّفة في اللغة كأنواع البيانات مثل int يسمى "متغير variable"، بينما طلب أي فئة من الفئات التي عرّفها المبرمج user-defined يسمى "كائن object".

البرمجة الشيئية أو الكائنية Object Oriented Programming:

عند حديثنا عن البرمجة الشيئية، نجمل الحديث في كلمتين: الوراثة وتعدد الأشكال Inheritance & Polymorphism، وهما من التقنيات الفعّالة للتعامل مع البرمجيات المعقدّة:

فالوراثة inheritance هي شكل للبرامج software المعدّة للاستعمال مع الفئات classes الحديثة والتي أنشئت من فئات موجودة مسبقاً وأخذت عنها خصائصها وسلوكها وأضافت إليها القدرات التي نحتاج إليها في هذه الفئة الجديدة. الوراثة ماذا تعني عملياً؟! تعني بالضبط ما الذي تم وراثته و كيف يمكن التعديل عليه وما الذي لا يمكن وراثته -يتضح ذلك بالأمثلة-. هذه الخاصية توفر الكثير من الوقت للمبرمج وتقطع عنه أشواطاً في تطوير برنامجه.

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

وكما ذكرنا في الأعلى أن الفئات الجديدة -تسمى فئة فرعية subclass- ترث صفات الفئات التي أُنتجت وتكونت منها -تسمى الفئة الأم superclass- كما يرث الطفل جينات أبويه. وهذه الفئة الجديدة والتي تعتبر subclass، من الممكن أن تكون superclass لفئات جديدة أخرى ينشئها المبرمج. وهكذا تمتد لدينا سلسلة من الوراثة بين الفئات extends، يحكمها قانون "الوراثة المفردة Single Inheritance" حيث ينص هذا القانون على:

تنشأ أي فئة فرعية من فئة أم واحدة، فالجافا لا تدعم التوارث المتعدد multiple inheritance كالسي++ ولكنها تدعم مفهوم الواجهات Interfaces، فنظام الواجهات يساعد الجافا على تحقيق فائدة التوارث المتعدد مع عدم وجود الأخطاء المترابطة الناتجة عن هذا التوارث المتعدد!

تذكر أن أي كائن ينتمي إلى فئة فرعية فهو ينتمي إلى الفئة الأم لهذه الفئة الفرعية ويحمل خصائصهما وسلوكهما.

وبعد هذه المقدمة وهذا التوصيف لعالم الـOOP نلاحظ أن جُلّ التركيز في هذا النوع من البرمجة يقع على الـفئات Classes، فالمبرمج يستخدم الفئات المبنية مسبقاً في اللغة مع الفئات التي يبنيها هو كي ينتج برنامجاً بالجافا، ربما يفسر هذا الاسم OOP :)

بهذا يكون درسنا قد انتهى، أرجو أن يكون واضحاً .... إنتهي

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

البرمجة كائنية المنحى Object-oriented programming - OOP (ويطلق عليها أحيانا اسم: برمجة غرضية المنحى، أو برمجة شيئية مع أن هذه الأخيرة لا تعتبر ترجمة محبذة) أو برمجة موجهة نحو الكائنات (أو العناصر) وهي عبارة عن نمط برمجة متقدم، وفيه يقسم البرنامج إلى وحدات تسمى الكائنات (Objects)، كل كائن عبارة عن حزمة (تعليب) من البيانات (المتغيرات والثوابت) والدوال ووحدات التنظيم وواجهات الاستخدام. ويتم بناء البرنامج بواسطة استخدام الكائنات وربطها مع بعض وواجهة البرنامج الخارجية باستخدام هيكلية البرنامج وواجهات الاستخدام الخاصة بكل كائن.

أسماء عربية أخرى:

برمجة كينونية

برمجة شيئية المنحى.

برمجة موجهة

برمجة كائنية

برمجة كائنية التوجه

برمجة غرضية التوجه

برمجة كائنية المنحى (أو المنحى)

برمجة بالعناصر

برمجة موجهة نحو الكائنات (أو العناصر)

البرمجة بالكائنات -

البرمجة الكائنية عبارة عن نمط برمجة متخصص في المفاهيم التالية:

الفئة Class وهو نموذج الوحدة الرئيسية لبناء الـكائن (Object) بمعنى أنه يتم تكوين أكثر من كائن على أساس نموذج البناء الأساسي وهو (Class), ويمكن تشبيه الكلاس بالقالب الذي يقوم بتشكيل الكائن ويمكن بعد ذلك استخدام هذا الكائن لأي غرض مطلوب.

الكائنات Objects - حزم وتعليب البيانات والدوال الوظيفية معاً في وحدات تعمل ضمن برنامج نشط. الكائنات هي أساس هيكلية برمجة الحاسوب الكائنيّة.

المثال Instance وهو شكل الكلاس أو كائن محدد والذي ينشأ في وضع التشغيل، وبشكل آخر يمكن أن نسمي الكلاس في وضع التشغيل (نموذج).

التجريد Abstraction - قدرة البرنامج على تجاهل بعض واجهات المعلومات المتلاعبة، أي التركيز على المفهوم الأساسي للكائن وهيكليته النظرية وتجريدة من طريقة العمل النهائية والتوجهات الخارجية.

التغليف Encapsulation - التأكد أن المستخدم لا يستطيع أن يغير البيانات الداخلية لكائن بطريقة مفاجئة، فقط دوال الكائن الداخلية يسمح لها بتعديل حالة الكائن وبياناته. أي أن لايمكن التلاعب بالكائن وتغير معلوماته بأي طريقة بل أن هناك واجهة استخدام خاصة يضعها المبرمج ومن خلالها يمكن تغيير بيانات الكائن الداخلية وحالته.

تعدد الأوجه Polymorphism - بدلاً من استدعاء الإجراءات الفرعية مباشرة، تستطيع البرمجة الشيئية إرسال رسائل، الإجراء المعين الذي يتم نداؤه نتيجة الرسالة يعتمد على نوع الكائن الذي أُرسل له. أي أنه باستخدام نفس اسم الاستدعاء يمكن استدعاء إجراءات ودوال مختلفة اعتماداً على نوع الكائن.

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

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

من أحدث أساليب هندسة البرامج ما يعرف ب object oriented approach تعد الطريقة الموجهة للكينونات من الأساليب الجديدة في تطوير النظم وهو أسلوب التحليل والتصميم الكينوني object oriented design and analysis حيث يقوم هذا الأسلوب بدمج البيانات والعمليات في بيئة واحدة تسمى كينونة object وتمثل الكينونة عادة الاشياء الواقعية التي يعالجها نظام المعلومات مثل الزبائن والمزودين والعقود واتفاقيات الإيجار.

نعود إلي الكتاب ...

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

شكل 1-1 مفهوم قاعدة البيانات بالمرفقات

- Data Model

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

يقول الكاتب : بالرغم من أن قاعدة البيانات لا تمثل شكل مادي ملموس يمكننا أن نشبه بشئ مادي في الحياة التي حولنا إلا أننا يجب أن نفكر فيها كشيء مادي محسوس حتي ندرك أبعادها .. أي يجب أن نعتبرها شيئ موجود فعلا وسبب وجوده هو حل لمشكلة موجودة فعلا في العالم الحقيقي أي يجب عليك أن تري المشكلة أمامك أن تعرف أبعادها أن تحددها بدقة .أن تفكر في تفاعلاتها مع غيرها . أن تفكر في القرارات السليمة لحل هذه المشكلة .. وأكرر .. يجب ان تعرف حدود المشكلة بدقة حتي لا تدخل في حالة فوضوية وهذا ما يسمي علميا بتحديد مجال قاعدة البيانات DataBase Scoap

يقول الكاتب : ان الجزء الأول في بناء قاعدة البيانات هو الوصف النظري للمشكلة يعني إيه ؟

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

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

- يستخدم الكاتب مفهوم Data Model أيضا لوصف العلاقات بين الكيانات وأي قيود علي تلك العلاقات فمثلا يمكن أن نقول أن فئة المديرين غير مصرح لهم برؤية أكثر من خمس تقارير محددة كما أنهم ممنوعين من تعديل أي شيئ في ثوابت النظام .

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

- Database Schema

ماذا يقصد الكاتب بهذا المصطلح ؟

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

الكاتب قال ... يا جماعة أنا أقصد بهذا المصطلح Database Schema التصميم المادي للجداول في قاعدة البيانات ..يعني ترجمة للوصف التصوري Data Model الي جداول في قاعدة بيانات يعني أعمل مخطط تصوري لقاعدة البيانات أو بالأدق مخطط تصوري للجداول .

يعني بالبلدي كدة أحول الوصف التصوري للمشكلة إلي شئ مادي أقدر أديره بواسطة أحد أنظمة إدارة البيانات DBMS

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

الكاتب بيقولك لأ

الـ Database Schema مش أكثر من أنها شكل تصوري موضوع في شكل توصيف قاعدة بيانات يعني ممكن تقول أنه شكل تصوري لقاعدة بيانات ولكن مش هوة قاعدة البيانات النهائية .

DataBase

خلاص يا كبير .. هانبدأ نشتغل علي الكمبيوتر ونعمل الجداول .

خلاص يا عم هاتشتغل ... بس إنت عارف إيه اللي بيحصل في الكمبيوتر لما تيجي تنشئ قاعدة بيانات بإستخدام أحد محركات قواعد البيانات زي MS Access أو SQl Server الكاتب اللي بيقول

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

application

يقول الكاتب : أن قواعد البيانات لا تشتمل إلا علي البيانات فقط ... لا يوجد بها نماذج .. لا توجد تقارير ..لا توجد بها أي واجهات تعامل مع المستخدم .. الموجود بها بيانات فقط ... ركز جدا

هاييجي حد يقول – الكلام دة ما يمشيش – طب ما هو الأكسيس فيه نماذج وتقارير والإمتداد بتاعه .mdb ودة امتداد قواعد بيانات الخاص بـ Microsoft jet إزاي بقة .

الكاتب بيقولك أديك جاوبت علي نفسك محرك قواعد البيانات في الأكسيس هوة الـ ميكروسوفت جيت مش الأكسيس والأكسيس عبارة عن نظام قواعد بيانات ومش محرك قواعد بيانات ... خد بالك من الفرق

ويقصد بنظام قواعد البيانات هوة مزيج من تطبيقات قواعد البيانات + محركات قواعد البيانات + قواعد البيانات .

وهة ما سنناقشه في الفقرة المقبلة إن شاء الله

النص الأصلي للفقرة السابقة

What Is a Database?

Database terminology is almost as slippery as the term "object-oriented programming." The word "database" is used to describe everything from a single set of data, such as a telephone list, to a complex set of tools, such as SQL Server, and a whole lot in between. This lack of precision isn't a bad thing, necessarilyit's just the nature of languagebut it's not particularly useful for our purposes, so I'll try to be a bit more precise here. Figure 1-1 shows the relationships between the terms discussed here. We'll define these terms in this chapter, and examine them in detail in the rest of the book.

Figure 1-1. Relational Database Terminology

Although relational databases don't have real-world analogies, most are intended to model some aspect of the real world. I'll call that bit of the real world the problem space. The problem space, by its nature, is messy and complexif it weren't, we wouldn't need to build a model of it. But it is critical to the success of your project that you limit the database system you're designing to a specific, well-defined set of objects and interactions; only by doing so can you make sensible decisions about the scope of your system.

I'll use the term data model to mean the conceptual description of the problem space. When you're working with the relational model, this includes the definition of entities, their attributes (a Customer, for example, is an entity, and it might have the attributes Name and Address), and the entity constraints (such as, for example, that the CustomerName field cannot be empty). When you're working with the dimensional model, this definition consists of facts and dimensions, but we'll discuss those in Part II.

The data model also includes a description of the relationships between entities and any constraints on those relationships. For example, managers are not allowed to have more than five individuals reporting to them. It does not include any reference to the physical layout of the system.

The definition of the physical layoutthe tables and views that will be implementedis called the database schema or just the schema. It's the translation of the conceptual model into a physical representation that can be implemented using a DBMS. Note that the schema is still conceptual, not physical. The schema is nothing more than the data model expressed in the terms that you will use to describe it to the database enginetables and triggers and such creatures. One of the benefits of using a database engine is that you don't ever have to deal with the physical implementation; you can largely ignore B-trees and leaf nodes and other low-level physical concepts.

Once you've explained to the database engine what you want the data to look like, using either code or an interactive environment such as Microsoft Access or the SQL Server Enterprise Manager, the engine will create some physical objects (usually, but not always, on a hard disk someplace) and you'll store data in them. The combination of structure and data is what I'll refer to as a database. This database includes the physical tables that store the data; the defined views, queries, and stored procedures used to retrieve the data in various ways; and the rules the engine will enforce to protect the data.

The term "database" does not include the application, which consists of the forms and reports with which your users will interact, nor does it include any of the bits and piecesthings such as middleware or Internet Information Serverused to stick the front and back ends together. The term "database" also excludes the database engine. Thus, an Access .mdb file is a database, while Microsoft Jet is a database engine. Actually, an .mdb file can contain application objects as wellforms and reports, for examplebut that's a topic we'll discuss later.

To describe all these componentsthe application, the database, the database engine, and the middlewareI'll use the term database system. All of the software and data that goes into making a production system is part of the database system.

بارك الله فيك أخى الكريم

و بعد اذنك

هذا هو الكتاب لمن يريده

Designing Effective Database SystemsAddison Wesley(200501).pdf

أعزك الله أخي أبو يوسف .. وأشكرك علي مرورك ...

المؤلفة : صباح الخير أيها المترجم

المترجم : سيدتي هل لك أن تعرفينا بنفسك ؟

المؤلفة : أسمي ريبيكا م ريوردان

وظيفتي - كبير مهندسي الدعم الفني لقواعد البيانات بشركة ميكروسوفت استراليا

الخبرة حوالي عشرون عاما في تصميم قواعد البيانات

المؤلفة : نعم .. أنظر أيها المترجم أولا يجب أن ألفت نظرك لشئ هام ...

أن هذا الكتاب يركز على التصميم وليس التنفيذ فلا معني أن تعرف نظرية معينة ولا تعرف كيفية تطبيقها

المترجم : تفضلي سيدتي

.

النص الأصلي للفقرة السابقة

عدنا ....

المترجم : لقد أشرت سيدتي ... ضمن المفاهيم الأساسية التي يجب معرفتها كأساس علمي عند بناء قاعدة البيانات علي مفهوم ( النموذج الترابطي The relational model) كأساس لتحليل المعطيات ...

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

وفقا لموسوعة ويكيبيديا فإنه ...

في القرن التاسع عشر، قام عالم الرياضيات الألماني جورج كانتور بتقديم نظريته التي عرفت باسم نظرية المجموعات. عند أختراع الحاسوب، تم توظيف هذه النظرية في أبتكار أشكال للبيانات يمكن تمثلها والتعامل معها من خلال الحواسيب، وقد تحقق هذا الهدف في الصيغة التي طرحها عالم الرياضيات الأمريكي د. ل. شيلدز en:D. L. Childs عام 1969 في ورقة علمية بعنوان "وصف تنظيري لبنى البيانات الفئوية" "Description of Set-Theoretic Data Structure"، وقد أعتمد عالم الرياضيات والحاسوب البيرطاني إدجار كود على هذه الورقة في أعداد ورقته العلمية التي اسمها "نموذج مترابط لبيانات بنوك البيانات الكبيرة المشتركة A Relational Model of Data for Large Shared Data Banks" التي قدم فيها لأول مرة نموذج قاعدة البيانات المترابطة. يعتبر إدجار كود المبتكر الأصلي لنموذج قاعدة البيانات المترابطة، لكن هذا النموذج خضغ للتطوير على يد عدد من الباحثين، ويعتبر جزء كبير من تطوير نموذج قاعدة البيانات المترابطة عائد إلى أبحاث كريس دات en:Chris Date وهيو داروين en:Hugh Darwen. في كتابهما المنشور عام 1995 والمسمى "البيان الثالث"en:The Third Manifesto بين كريس دات وهيو داروين كيف يمكن تكييف نموذج قاعدة البيانات المترابطة ليكون متوائماً نموذج للكائنات Object Oriented دون تغيير في المبادئ التي بني عليها.

- وقد عرفت ويكيبيديا النموذج الترابطي علي أنه ( نموذج تصميمي لقاعدة البيانات يعتمد على المنطق الضمني. ظهر هذا النموذج ضمن ورقة علمية نشرها العالم إدجار كود عام 1970.)

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

- فما هو النموذج الترابطي من وجهة نظرك في هذا الكتاب ؟

المؤلفة :

نعم ... فالنموذج الترابطي يعني كيف تشكل البيانات وفقا لمجموعة من المبادئ الرياضية والمنطقية الضمنية ( وقد إبتكر هذا النموذج العالم إدجار كودد في أواخر السبعينيات من القرن الماضي ) وهذه المبادئ مترجمة في مجموعة من القوانين التي تهتم بالطريقة الصحيحة لـ 1 – كيفية هيكلة البيانات وتخزينها بالطريقة السليمة data structure 2- طريقة حماية البيانات وتكاملها data integrity 3- وطريقة التعامل مع البيانات لإسترجاع المعلومات منها data manipulation

- سوف نناقش أيضا النموذج ثلاثي الأبعاد وهو نموذج علائقي خاص مصمم لمراقبة البيانات التاريخية .

- وعلي العموم فإن أنظمة قواعد البيانات العلائقية يجب أن تتصف بثلاث صفات فريدة وهي

1- جميع البيانات ترتب و تخزن في أعمدة وصفوف وهذا يدعي طبقا للنموذج العلائقي " علاقة " أي بناء منطقي ينظم البيانات في شكل منطقي في أعمدة وصفوف .

2- كل تقاطع صف مع عمود في هذه العلاقة يحمل فقط قيمة واحدة مما يطلق عليه مصطلح Scalar

3- جميع العمليات التشغيلية تتم من خلال العلاقات وجميع النتائج تستخرج من خلال العلاقات مما أصطلح عليه مصطلح Closer

إذا نظرنا الي Microsoft Access نجد انه يعرف العلاقة علي انها مجموعة السجلات ( الجدول ) كما يعرفها SQL Server علي أنها مجموعة النتائج لكن عندما أراد دكتور Codd أن يضع تسمية لهذه التركيبة من البيانات فقد أسماها " علاقة " ولم يسمها جدول مثلما يحدث في Access .. إنه خطأ شائع أن يظن البعض أن مقصود العلاقة هنا هي علاقة للربط بين جدولين بل الصواب هو ان العلاقة توصف هنا لتحديد العلاقات بين القيم داخل الجدول الواحد

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

أن المبدأ الثالث Closer يعني أن النموذج العلائقي الذي يحتم أن تكون طريقة إنشاء العلاقة والنتائج المستخلصة يكونا ناتجان عن العلاقة ذاتها كما أن النتائج يمكن أن تكون مدخلا لعمليات تشغيل أخري يعطي قاعدة البيانات ونظام إدارتها فعالية كبيرة ونحن نري هذا جليا في Jet و SQL Sever حيث يمكن أن يكون الإستعلام مدخلا لعملية تشغيلية أخري .

النص الأصلي للفقرة السابقة

The relational model is based on a collection of mathematical principles drawn primarily from set theory and predicate logic. These principles were first applied to the field of data modeling in the late 1960s by Dr. E. F. Codd, then a researcher at IBM, and first published in 1970.[1] The rules of the relational model define the way data can be represented (data structure), the way data can be protected (data integrity), and the operations that can be performed on data (data manipulation).

[1] Codd, E. F. "A Relational Model of Data for Large Shared Data Banks," Communications of the ACM, Vol. 13, No. 6 (June 1970).

The relational model is not the only method available for storing and manipulating data. Alternatives include the hierarchical, network, and Object/Data models. Each of these models has its advocates, and each has its advantages for certain tasks. But because of its efficiency and flexibility, the relational model is by far the most popular database technique and is the one discussed in this book. Both the Microsoft Jet database engine and Microsoft SQL Server implement the relational model.

We'll also be discussing the dimensional model, a special kind of relational schema used for tracking historical data. We'll look at the dimensional model and its relationship to the relational model in detail in Part III.

In general terms, relational database systems have the following characteristics:

All data is conceptually represented as an orderly arrangement of data into rows and columns, called a relation.

All values are scalar. That is, at any given row/column position in the relation there is one and only one value.

All operations are performed on an entire relation and result in an entire relation, a concept known as closure.

If you've worked with Microsoft Access databases at all, you'll recognize a "relation" as a "recordset" or, in SQL Server terms, as a "result set." Dr. Codd, when formulating the relational model, chose the term "relation" because it was comparatively free of connotations, unlike, for example, the word "table." It's a common misconception that the relational model is so called because relationships are established between tables. In fact, the name is derived from the relations on which it's based.

Notice that the model requires only that data be conceptually represented as a relation; it doesn't specify how the data should be physically stored. This separation of the conceptual and physical representations, although it seems obvious now, was a major innovation 30 years ago when database programming generally meant writing machine code to physically manipulate the data storage devices.

In fact, relations need not have a physical representation at all. A given relation might map to an actual physical table someplace on a disk, but it can just as well be based on columns drawn from half a dozen different tables, with a few calculated columnswhich aren't physically stored anywherethrown in for good measure. A relation is a relation provided that it's arranged in row and column format and its values are scalar. Its existence is completely independent of any physical representation.

The requirement that all values in a relation be scalar can be somewhat treacherous. The concept of "one value" is necessarily subjective, based as it is on the semantics of the data model. To give a common example, a "Name" might be a single value in one model, but another environment might require that the value be split into "Title", "Given Name", and "Surname", and another might require the addition of "Middle Name" or "Title of Courtesy". None of these is more or less correct in absolute terms; it depends on the use to which the data will be put.

The principle of closurethat both base tables and the results of operations are represented conceptually as relationsenables the results of one operation to be used as the input to another operation. Thus, with both the Jet database engine and SQL Server we can use the results of one query as the basis for another. This provides database designers with functionality similar to a subroutine in procedural development: the ability to encapsulate complex or commonly performed operations and reuse them whenever and wherever necessary.

For example, you might have created a query called FullNameQuery that concatenates the various attributes representing an individual's name into a single calculated field called FullName. You can create a second query using FullNameQuery as a source that uses the calculated FullName field just like any field that's actually present in the base table. There is no need to recalculate the name.

This is, of course, a simple example, and it's probably not immediately obvious that calling FullNameQuery provides any significant advantages over simply recalculating the full name. But as we'll see, the SQL language allows for the generation of extremely complex queries, and as the complexity increases, so do the benefits of using existing queries as input for new ones.

بارك الله فيك أستاذ خالد الغول ... زادك الله علماً .

الحلقة القادمة

مفهوم العلاقات..... أنتظرونا

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

وأنت عندما وضعت أخر مشاركة لك في هذه المقالة وقلت فيها " مفهوم العلاقات ... إنتظرونا " فأنا متأكدة أن أكثر من 95% ممن قرأ هذه المشاركة قد ظن أنني سوف أقوم بشرح العلاقات بين الجداول ... ولكن سوف يفاجأ الجميع بأن الحديث سوف يكون مختلفا .

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

وألآن نتعلم من جديد

لكي نفهم معني مصطلح Relation يجب أن نذكر مفهومين

1- Relation

2- Relationship

- كلمة Relation تعني حقيقة (Fact) ....

هذه الحقيقة تمثل إما كيان أو علاقة مشتركة .... فلنوضح أكثر .. مثلا

في برنامج معد لشئون التوظيف

الموظف يمثل كيان أي Relation

وتكون خصائص العلاقة كالتالي ( رقم الموظف .. اسم الموظف.. العنوان ... وما الي ذلك)

أي معني العلاقة هنا (جدول )

ولأان قواعد البيانات العلائقية تنتمي الي ذلك النوع من البرمجة الذي يسمي بالبرمجة الكائنية oop فإنه يسمي كيان (entity )

هذا الكيان يدخل في علاقة مشتركة ((((Relationship)))) مع كيان آخر

فالموظف السالف الذكر يعمل في إدارة الحسابات ....

كلمة" يعمل في " هي برمجيا Relationship

أي أن Relation هي الجدول بتحول المفاهيم التالية

Attribute خاصية في مفهوم العلاقة تحولت الي عمود رأسي Column Headers في الجدول

Tuple عنصر في مفهوم العلاقة تحول الي صف Row في الجدول

المجال Domain في مفهوم العلاقة تحول الي Data Tayp في الجدول

Relationship هي طبيعة علاقة هذا الجدول أو الكيان أو العلاقة بجدول آخر أو كيان آخر أو علاقة أخري .. فهمت ؟

سيدتي : ما المقصود بالعلاقات في النموذج العلائقي عند العالم E F CODD ؟

أنظر الي هذا الشكل ( مرفقات )وتابع معي .

إذا نظرنا الي هذا الرسم طبقا للنموذج العلائقي نجد التالي ....

هذا البناء الذي أمامنا طبقا للنموذج العلائقي يسمي علاقة Relation لماذا ؟ لأنه بناء منطقي من البيانات منظم في شكل أعمدة وصفوف

كل صف في هذا البناء هو عنصر tuple ... (ومن الناحية الفزيائية فإن كل عنصر له رقم تسلسلي ولكن يتم تجاهل هذا الرقم في العادة ) وعدد العناصر يحدد جوهرية العلاقة - cardinality of a relation - أي أن هذه العلاقة جوهرها 18 ويتغير هذا الجوهر مع عمليات الحذف والإضافة لذلك فإن جوهر العلاقة متغير مع الزمن عادة

كل تقاطع عمود column مع العنصر tuple يسمي خاصية attribute للعنصر ( وعدد الخصائص – الحقول – في العلاقة يسمي بدرجة العلاقة degree of a relation) وفي مثالنا هنا فإن درجة العلاقة هي (3)

- من ناحية أخري فإننا يمكننا أن نقسم العلاقة ( الجدول ) إلي قسمين

:(Heading) (1) رأس العلاقة : يتكون من مجموعة من الحقول بحيث أن كل حقل يتبع مجال معين ( سنعرف لاحقا ما هو المجال )

(2) BODY : جسم العلاقة : يتكون من مجموعة متغيرة مع الزمن من العناصرTuples أو الصفوف Rows حيث أن كل صف يتكون من مجموعة من الخصائص

خصائص العلاقة ( أو الجدول للتقريب ) حسب مفهوم EF Codd

كما قلنا سابقا " أن العلاقة ( الجدول )عبارة عن بيانات منظمة علي أساس رياضي ومنطقي " ولذلك فإن هناك بعض الخصائص التي تختص بها هذه العلاقة وتعتبر هذه الخصائص متوارثة من تلك المبادئ الرياضية وكما عرفنا العلاقة بأنها (set) أي مجموعة ... فلها خصائص هذه المجموعة المتمثلة فيما يلي

1- لا يشترط في المجموعة ترتيب العناصر

2- لا يشترط ترتيب الحقل داخل العنصر

3- لا يجوز تكرار العنصر

4- كل حقل داخل العنصر يحمل قيمة واحدة ولا يجوز تعددية القيمة داخل الحقل .

أنظر الي هذا الشكل ( مرفقات )وتابع معي .

إذا نظرنا الي هذا الرسم طبقا للنموذج العلائقي نجد التالي ....

هذا البناء الذي أمامنا طبقا للنموذج العلائقي يسمي علاقة Relation لماذا ؟ لأنه بناء منطقي من البيانات منظم في شكل أعمدة وصفوف

كل صف في هذا البناء هو عنصر tuple ... (ومن الناحية الفزيائية فإن كل عنصر له رقم تسلسلي ولكن يتم تجاهل هذا الرقم في العادة ) وعدد العناصر يحدد جوهرية العلاقة - cardinality of a relation - أي أن هذه العلاقة جوهرها 18 ويتغير هذا الجوهر مع عمليات الحذف والإضافة لذلك فإن جوهر العلاقة متغير مع الزمن عادة

كل تقاطع عمود column مع العنصر tuple يسمي خاصية attribute للعنصر ( وعدد الخصائص – الحقول – في العلاقة يسمي بدرجة العلاقة degree of a relation) وفي مثالنا هنا فإن درجة العلاقة هي (3)

- من ناحية أخري فإننا يمكننا أن نقسم العلاقة ( الجدول ) إلي قسمين

:(Heading) (1) رأس العلاقة : يتكون من مجموعة من الحقول بحيث أن كل حقل يتبع مجال معين ( سنعرف لاحقا ما هو المجال )

(2) BODY : جسم العلاقة : يتكون من مجموعة متغيرة مع الزمن من العناصرTuples أو الصفوف Rows حيث أن كل صف يتكون من مجموعة من الخصائص

خصائص العلاقة ( أو الجدول للتقريب ) حسب مفهوم EF Codd

كما قلنا سابقا " أن العلاقة ( الجدول )عبارة عن بيانات منظمة علي أساس رياضي ومنطقي " ولذلك فإن هناك بعض الخصائص التي تختص بها هذه العلاقة وتعتبر هذه الخصائص متوارثة من تلك المبادئ الرياضية وكما عرفنا العلاقة بأنها (set) أي مجموعة ... فلها خصائص هذه المجموعة المتمثلة فيما يلي

1- لا يشترط في المجموعة ترتيب العناصر

2- لا يشترط ترتيب الحقل داخل العنصر

3- لا يجوز تكرار العنصر

4- كل حقل داخل العنصر يحمل قيمة واحدة ولا يجوز تعددية القيمة داخل الحقل .

shows a relation with the formal names of the basic components marked. Those of you who know something about relational design will recognize that the relation is not in normal form. That's okay; it still qualifies as a relation because it's arranged in row and column format and its values are scalar.

The entire structure is, as we've said, a relation. Each row of data is a tuple (rhymes with "couple"). Technically, each row is an n-tuple, but the "n-" is usually dropped. The number of tuples in a relation determines its cardinality. In this case, the relation has a cardinality of 18. Each column in the tuple is called an attribute. The number of attributes in a relation determines its degree. The example relation has a degree of 3.

The relation is divided into two sections, the heading and the body. The tuples make up the body, while the heading is composed of, well, the heading. Note that in its relational representation the label for each attribute is composed of two terms separated by a colonfor example, UnitPrice:Currency. The first part of the label is the name of the attribute, while the second part is its domain. The domain of an attribute is the "kind" of data it representsin this case, currency. A domain is not the same as a data type. We'll be discussing this issue in detail in the next section. The specification of domain is often dropped from the heading.

The body of the relation consists of an unordered set of zero or more tuples. There are some important concepts here. First, the relation is unordered. Think of a relation as a brown paper bag (or perhaps a Ming bowl if you're feeling poetic) containing all the tuples in no particular order. Record numbers, a common mechanism to access records in non-relational databases, do not apply to relations. Second, a relation with no tuples (an empty relation) still qualifies as a relation. Third, a relation is a set. The items in a set are, by definition, uniquely identifiable. Therefore, for a table to qualify as a relation, each record must be uniquely identifiable and the table must contain no duplicate records.

If you've read the Access or SQL Server documentation, you might be wondering why you've never seen any of these words before. They're the formal terminology used in the technical literature, not the terms used by Microsoft. I've included them just so you won't be embarrassed at cocktail parties (at least not about n-tuples of third degree, anyway).

Unfortunately, not only do Microsoft products not conform to formal terminology, they're not consistent. The terms used by the two products are shown in Table 1-1. I'll use the formal terminology in this book.

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

شفاك الله وعافاك أستاذ خالد .. بارك الله فيك .

شكرا لك أخي عمر ... وأهدي اليك المشاركة التالية

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

هذه الأقسام الأربع الرئيسية هي

1- تحديد الكيانات

2- تحديد خصائص كل كيان

3- تحديد المجالات

4- تحديد العلاقات بين الكيانات

1-

( Entities).

في الحقيقة لا يمكننا أن نضع تعريف محدد وواضح للكيان ... لكننا نستطيع أن نقول أن الكيان هو ...

" أي شئ داخل النظام يحتاج النظام إلي تخزين بيانات بشأنه "

المترجم : عفوا سيدتي قد يبدو سؤالي ساذجا بعض الشئ ولكني أريد أن أوضح المعلومة بشكل دقيق حتي يفهمها القارئ المبتدأ ... وسؤالي هذه المرة " ما معني البيانات ؟ "

المؤلفة : نعم سؤال جيد

لقد عرف كتاب Business Information Systems، الطبعة الثانية 2003 البيانات وقال " يمكن تعريف البيانات أو المعطيات على أنها سلسلة غير مترابطة من الحقائق الموضوعية التي يمكن الحصول عليها عن طريق الملاحظة أو عن طريق البحث والتسجيل[1].

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

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

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

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

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

والآن نعود الي الحديث عن الكيانات ... قلنا أن الكيانات هي

" أي شئ داخل النظام يحتاج النظام إلي تخزين بيانات بشأنه "

المترجم : عفوا سيدتي ... لكن التعريف فضفاض جدا ... هل يمكن تحديده أكثر من ذلك ؟

المؤلفة : نعم ...عندما تبدأ قي تصميم النموذج الوصفي فسوف تجد أنه ليس من الصعب أن تحدد القائمة الأولية من الكيانات حيث أن هناك كيانات صريحة ... فحينما تحاول الحديث مع عملائك عن حدود المشكلة التي تحاولون تصميم برنامج لها تجد ان الحديث بينكم يرد فيه (أسماء) و(أفعال) هذه الأسماء والأفعال التي ترد في الحديث هي التي ترشح الكيانات . "العملاء يشترون المنتجات ".. "موظفي المبيعات يبيعون المنتجات "..." المودون يوردون المنتجات الي الشركة "

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

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

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

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

وقد يعني العميل ان هناك فعلا فعلين لعملية واحدة وهو يقصدها ولكن لا تعيها انت مثال : اذا كان عميلك خياط وتسير العملية البيعية كالتالي :-

- الخياط يأخذ المقاسات في المرحلة الأولي من البيع

- العميل يترك مقدم تحت الحساب

- الخياط يعطي موعد تسليم

- العميل يستلم في الموعد المحدد

هذه العملية في المجموع ... عملية بيع ... ولكنها في الحقيقة ليست كذلك ... بل هي عمليتين مستقلتين ... الأولي توصية بيع ... والثانية عملية بيع ويجب أن توصف بهذا الشكل ... لان كلا من العمليتين يجب أن توصف بشكل مختلف .

والحل دائما وأبدا عزيزي ... إفهم المشكلة بالتفصيل

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

معظم الكيانات في نظامك تجسد أشياء موجود في المشكلة الحقيقة ( العالم الحقيقي ... للتبسيط – الشركة التي تصنع لها النظام) العملاء – الأصناف – المكالمات

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

وبما أن علم الرياضيات يقول أن الكل = مجموع أجزائه فإننا يمكننا أن نقول أن الكائن هو مجموع خصائصه .

Domains

ذكرت في بداية هذا الفصل أن " رأس العلاقة – اسم الحقل في أكسيس – يقترن معه اسم المجال " هل تذكر ذلك وقلت أنني سأشرحه بعد ذلك ... لقد وصلنا هنا الي ضرورة شرح المجال Domain .

فالمجال يمكن أن نعرفه بأنه

كل القيم الممكنة (فقط )التي تحتاجها الخاصية

فلنشرح أكثر .. هناك خلط شائع بين المجال Domain و نوع بيانات الخاصية Data tayps .. الصحيح أنهما ليسا شيئا واحدا .. فنوع البيانات هو مفهوم فييزيائي أما المجال فهو مفهوم منطقي ..

فالرقم هو نوع بيانات الحقل أما العمر فهو المجال ... كمثال آخر فإن اسم الشارع و لقب الأسرة يمكن ان يوصفان كحقول من نوع نصي ولكنهما يتبعان مجالين مختلفين ..

من ناحية أخري فإن ال Domain أضيق من Data Tayp حيث أن له معايير تحد من القيم الخاصة به ...لأعطيك مثالا .. عندما نحدد نوع الموظف فإنه يحمل قيمتين فقط ( ذكر – أنثي ) ... وبالطبع يمكن للـ Domain أن يكون أوسع من ذلك .. فعندما نضع دومين للعمر فإنه يكون مائة سنة أو أكثر قليلا عندما نستخدمه للأشخاص العاديين .. وقد يكون الاف السنوات إذا إستخدمناه لتحديد عمر الآثار.

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

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

ذكرت في بداية هذا الفصل أن " رأس العلاقة – اسم الحقل في أكسيس – يقترن معه اسم المجال " هل تذكر ذلك وقلت أنني سأشرحه بعد ذلك ... لقد وصلنا هنا الي ضرورة شرح المجال Domain .

فالمجال يمكن أن نعرفه بأنه

فلنشرح أكثر .. هناك خلط شائع بين المجال Domain و نوع بيانات الخاصية Data tayps .. الصحيح أنهما ليسا شيئا واحدا .. فنوع البيانات هو مفهوم فييزيائي أما المجال فهو مفهوم منطقي ..

فالرقم هو نوع بيانات الحقل أما العمر فهو المجال ... كمثال آخر فإن اسم الشارع و لقب الأسرة يمكن ان يوصفان كحقول من نوع نصي ولكنهما يتبعان مجالين مختلفين ..

من ناحية أخري فإن ال Domain أضيق من Data Tayp حيث أن له معايير تحد من القيم الخاصة به ...لأعطيك مثالا .. عندما نحدد نوع الموظف فإنه يحمل قيمتين فقط ( ذكر – أنثي ) ... وبالطبع يمكن للـ Domain أن يكون أوسع من ذلك .. فعندما نضع دومين للعمر فإنه يكون مائة سنة أو أكثر قليلا عندما نستخدمه للأشخاص العاديين .. وقد يكون الاف السنوات إذا إستخدمناه لتحديد عمر الآثار.

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

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

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

الكيان الذي تشتمله هذه العلاقة يسمي كيان مشارك participant أي أن هذا الكيان شارك كيان غيره في علاقة ... عدد مشاركات هذا الكيان مع كيان غيره يسمي درجة العلاقة degree of a relationship ... وهي تشبه ولكنها ليست هي درجة العلاقة degree of a relation .. حيث أن الثانية هي عدد الخصائص في العلاقة ( الجدول ).

إذا درجة العلاقة المشتركة = عدد الكيانات المشتركة في العلاقة

• درجة العلاقة الثنائية هي الغالبية العظمي من درجات العلاقة وتكون هذه المشاركة هي عبارة عن أن الكيان يشارك كيان آخر في علاقة ثنائية مثل ان نقول ( العملاء يشترون المنتجات ) ولكن هذه العلاقة غير مطلوبة أو غير مجدية لأنها لا تأتي بنتائج كافية وحيث يوجد هنا علاقة ضمنية ومستترة أخري وهي أن ( مندوبي البيع يبيعون المنتجات للعملاء ) وحيث أن درجة العلاقة الثنائية لا تسمح لنا بالتعرف علي المندوب الذي قام بعملية البيع ... فقط العلاقة الثلاثية هي التي تسمح لنا بالتعرف علي ذلك .

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

العلاقة بين أي كيانين من الممكن أن تكون (واحد الي واحد )(واحد الي متعدد)(متعدد الي متعدد) .

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

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

(علاقة متعدد الي متعدد) هي أيضا علاقة شائعة وليست نادرة ... فمثلا العميل يشتري العديد من المنتجات والمنتج يشتريه العديد من العملاء .

الإرتباط : Participation : ويقصد به هل الكيان يرتبط في وجوده علي كيان آخر...

وهل هذا الإرتباط كلي ... أم جزئي

- الإرتباط الكلي هو ... إذا كا عندنا كيانان 1 و 2

فإن كل حالة تغير في الكيان 1 يجب أن يواكبها تغير في الكيان 2

- الإرتباط الجزئي ... ليس شرطا أن تكون كل حالة تغير في الكيان 1 يتبعها تغير في الكيان 2

أي أنه إذا كان هناك كيانان في علاقة وكان وجود الكيان الأول يعتمد وجوده إعتمادا كليا علي وجود الكيان الثاني فإن نوع المشاركة هنا ( مشاركة كلية) مثال – مبيعات المندوب (كيان) و بيانات المندوب ( كيان )

الإرتباط الجزئي : ويقصد به أنه يمكننا أن نذكر بيانات المندوب دون أهمية ذكر مبيعاته ... وضحت ؟