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

أخوك : سامي الفتني

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

درس رقم : 4

تابع - الفصل الثاني
العلاقات وأنواعها

الاستعلامات مع علاقة رأس برأس Quering One-to-one Relationship

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

SELECT EmpName, DeptName, EmpSalary
FROM Emp
WHERE EmpNo IN(SELECT BossNo FROM Dept)


********************************************************** انتهى الدرس

درس رقم : 5

علاقة رأس بأطرف One-to-Meny Relationship

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


شكل 2_4


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

شكل 2_5

لاحظ أن هناك العمود NatCode موجود في كلا الجدولين وبالمقارنة بينهما نستطيع تحديد الدولة الخاصة بأي شركة من الشركات ، وكما ترى عزيزي القارئ فإننا لم نكتب اسم الدولة ومعامل الضرب الخاص بها سوى مرة واحدة بدلاً من تكرارها عدة مرات في المثال السابق.
الآن نتعرف إلى مصطلحين في غاية الأهمية وإن كنا ذكرناه سابقاً إلا أننا سوف نعيد ذكرهما هنا معتمدين على مثالنا هذا، فنقول عن العمود NatCode في جدول البلدان أن اسمه المفتاح الأساسي Primary Key ونقول عن العمود NatCode في جدول الأسهم أن اسمه المفتاح المرتبط به Foreign Key.
أخيراً بقي علينا الآن أن نمثل ما قلناه في الفقرة السابقة تمثيلاً رسومياً يوضح الفكرة ويوسع المدارك في التفكير نحو إدارة جيدة لقواعد البيانات، حيث أننا تعلمنا أننا نمثل الجدول بشكل مستطيل يحتوي على اسم الجدول وحقوله فإننا هنا سوف نرسم الجدولين ونربطهما بطريقة (رجل الغراب) أو (Crow Foot) كما يلي :

شكل 2_6

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

شكل 2_7

نقول الآن إن العلاقة متكاملة فليس هناك طالب بدون فصل ولا وجود لفصل بدون طلاب.

*/*******************************************************************************انتهى الدرس


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

ترقبوا الدرس القادم :
الاستعلام من قاعدة بيانات ذات جدولين

مع تحيات أخوكم : سامي الفتني
[email protected]

04_Share.zip

Fig_2b.zip

بارك الله فيك يا اخى
مشكور
مشكور
مشكور
على هذا المجهود الرائع
في انتظار المزيد بإذن الله تعالى

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

 

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

درس رقم : 4

تابع - الفصل الثالث
علاقة أطراف بأطراف M:M
*************

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


شكل 3_1

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


شكل 3_2

شكل 3_3

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

شكل 3_4

بالنسبة لجدول الأفراد فسوف تقوم الآن بمسح عمود اللغة أما جدول اللغات فسيبقى كما هو، والجدول الجديد سيكون على النحو التالي :

شكل 3_5

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

شكل 3_6

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

شكل 3_7

*/*******************************************************************************انتهى الدرس

**** كلمة ثقيلة لجلب الصداع

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

ترقبوا الدرس القادم :

الاستعلامات مع علاقة أطراف بأطراف


مع تحيات أخوكم : سامي الفتني
[email protected]

DB.zip

images.zip

بسم الله الرحمن الرحيم

اخواني الاعزاء ارجو قبولي صديق لكم جميعا
واخص اخي سامي بالشكر والامتنان على هذه الدورة الرائعة وجزاك الله خير الجزاء وجعلها في ميزان حسناتك
عند سؤال وارجو ان تردوا علي يااصدقائي : ماهي الا شياء الواجب على dba عرفتها وهل عليه ان يعرف ال pl/sql بالذات ويتقنها ام يعرفها بشكل بسيط
افيدوني وجزاكم الله خير الجزاء

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

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

je crois que le sujet est très important pour un débutant comme moi et comme un nombre trèes importants des utilisateurs des bases de données je félicite notre cher frere sami pour sa façon très instructive pour transmetre l'information.
cher sami on est deriere toi continues la formation est voila un nouveau membre de votre communauté espérant d'être un grand suporteur de
vos intervenssion
votre frère abdelilah de france

السلام عليكم
لك جزيل الشكر يا اخ سام ونرجو الاستمرار

ألف شكر ليك أخي

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

أعزائي الكرام .... مرتادي المنتدى

يسرني أن أقدم بي أيديكم دورة في إدارة وتنظيم قواعد البيانات .. طبعاً ليس بالضرورة أن تكون قاعدة بيانات أوراكل، ولكنها دورة شاملة تغطي جميع أو معظم أفكار قواعد البيانات،،

ولكني في الحقيقة أريد التواصل من أصدقاء المنتدى حتى يكون هناك تفاعل مع الدورة وتعم الفائدة للجميع .. فأنا في الحقيقة لا أدعي الكمال ولا حتى نصفه في دورتي المتوضعة هذه وإنما كل ما أريده هو وضع مفاهيم أساسية قد يجهلها البعض ...[/size]
أهداف الدورة ::

1. التعرف على النماذج العلائقية Relational Model

2. التعرف على العديد من قواعد SQL المتعمقة.

3. تصميم قواعد البيانات باستخدام ER-Diagram ن.

4.

5.
:
:
في انتظار ردودكم ولكن في الحقيقة إذا لم أجد تواصل كبير فإني أعتذر عن تقديم هذه الدورة

ولكم من تحياتي وتقديري
أخوكم سامي الفتني

ملاحظة : أرجو من مشرف هذا المنتدى إبلاغي بخصوص تثبيت هذه الدورة في المنتدى.

61660[/snapback]

we support ya Sami abeerallam

الشكر لله ثم لجميع الزملاء والاخ سامى خاصة وجعلها الله فى ميزان حسناته

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

كلنا معك سماسيمو وجعلها الله في ميزان حسناتك

سبحان الله وبحمدة سبحان الله العظيم

درس رقم : 4

الفصل الرابع
الاستعلامات مع علاقة أطراف بأطراف Querying an m:m Relationship
*************
نعيد ونكرر وللمرة الألف إن الفكرة الأساسية من تكوين العلاقات هي تقسيم قاعدة البيانات ذات الجدول الواحد إلى جداول أصغر تفادياً لتكرار المعلومات من غير طائل، أما في الاستعلام فإننا نعيد الجداول المقسمة إلى وضعها الأساسي حتى نتمكن من استخلاص أي معلومة من هذه الجداول المتصلة، ومن هنا فإن أول عبارة SQL سنأخذها في هذه الفقرة هي عبارة تجميع الجداول الثلاث كما فعلنا في الفصل السابق :

SELECT *
FROM Bills, items, bilitm
WHERE Bills.BilNum = bilitm.BilNum
And items.ItmNum = bilitm.ItmNum;

شكل 4_1

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

SELECT ItmName,ItmPrice,QTY, ItmPrice*QTY AS Total
FROM Bills, items, bilitm
WHERE Bills.BilNum = bilitm.BilNum
And items.ItmNum = bilitm.ItmNum
And BilDate = #10/02/2005#;

شكل 4_2

المعامل Exists

هذا المعامل هو في الحقيقة أشبه بدالة تقوم بمعالجة عبارة استعلام وتعيد قيمة منطقية (True , False) حيث أنها تكتب بعد كلمة WHERE وكأنها أحد الشروط المطلوبة في الاستعلام، وبكل بساطة اكتب كلمة Exisits بعد وأتبعها بقوسين بينهما أي عبارة SQL فإذا كان عدد الأسطر الناتج من العبارة سطر واحد أو أكثر فإن هذا الدالة سوف تعيد القيمة True أما إذا لم ينتج أي سطر من العبارة فإنها تعيد False.
ومن أوضح الأمثلة على استخدام هذا المعامل هو استعلامنا مثلاً على أسماء وأسعار المواد ذوات الأرقام (15 و 16 و 17) إذا تم بيع المادة رقم 16 مرة واحدة على الأقل، ففي هذه الحالة يجب أن تكون المادة 16 مسجلة في جدول BilItem مرة واحدة على الأقل وإلا فلن يتم عرض أي من تلك المواد.

SELECT *
FROM Items
WHERE Items.ItmName IN(15,16,17)
AND EXISTS
(SELECT *
FROM bilItm
WHERE bilItm.ItmNum = 16);

في الكود السابق سوف يتم تنفيذ أولاً الاستعلام الفرعي فإذا نتج الاستعلام بسطر أو أكثر فإن فسوف تعرض المواد (15 و 16 و 17) أما إذا لم ينتج الاستعلام بأي سطر فلن تعرض أي مادة.
الكود التالي يعرض لك جميع المواد التي تبدأ بكلمة Red والتي تم بيعها :

SELECT *
FROM Items
WHERE ItmName LIKE 'Red*'
AND EXISTS
(SELECT *
FROM BilItm
WHERE BilItm.ItmNum = Items.itmNum);

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

SELECT Items.ItmNum, Itmname, ItmPrice
FROM bilitm, Items
WHERE bilitm.ItmNum=Items.ItmNum
And ItmName Like 'Red*';

الكود التالي يعرض جميع المواد التي تبدأ بكلمة Red والتي لم يتم بيعها :

SELECT *
FROM Items
WHERE ItmName LIKE 'Red*'
AND NOT EXISTS
(SELECT *
FROM BilItm
WHERE BilItm.ItmNum = Items.itmNum);

ويمكن تطبيقه بدون استخدام هذا المعامل كما يلي :

SELECT Items.itmNum, ItmName, ItmPrice
FROM Items
WHERE Itmname Like 'red*'
And Items.Itmnum NOT IN(
SELECT Items.ItmNum
FROM bilItm, Items
WHERE bilItm.ItmNum=Items.ItmNum
And Itmname Like 'red*');

الاستعلام الفرعي سوف يحدد جميع أرقام المواد التي تبدأ بـ Red والتي تم بيعها ، أما الاستعلام الخارجي فسوف يحدد جميع المواد التي تبدأ بـ Red من جدول المواد ما عدا التي تم بيعها.



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

شكل 4_3

ويمكن أيضاً مشاهدة شكل العلاقة كما يلي :

شكل 4_4

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


*/*******************************************************************************انتهى الدرس


ترقبوا الدرس القادم :

علاقات الجدول مع نفسه


مع تحيات أخوكم : سامي الفتني
[email protected]

وهذه الملفات المرفقة :

DB_Images.zip

السلام عليكم ورحمة الله وبركاته
كمل ياباشا
مشكور على الشرح الجميل
في انتظار المزيد
جزاك الله خير

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

يا جماعه انا درست اوراكل sql وحابب اني اكمل dba فهل من الضروري اني ادرس pl/sql ولا ادرس ووركشوب ون و ووركشوب توو ياريت حد يبلغنا الرد ياجماعه وياريت حد يدلني علي مركز كويس اتعلم فيه في مصر في القاهره ويقولي اسعاره ايه ويقولي ايه ظروف شغل dba في مصر وشكرا لكم جميعا

أشكر الجميع على ردودهم ...

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

يعني .. أنا شايف العدد قليل حتى الآن .. (عدد القراآت حوالي 190 في 4 أيام .. )

لكن إنشاء الله مع البداية ... يمكن العدد يزيد...

عموماً هناك نقطة مهمة جداً أريد التنويه عليها ... وهي حقيقة موضوع مقالتي اليوم :

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

ممكن يكون الاجتماع .. على غرفة بالتوك مثلاً أو ماسنجر .. الخ .....،،،،،،،،

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

شكراً لكم تعاونكم وترقبوا بداية الدورة قريباًً
أخوكم : سامي الفتني
[email protected]

62191[/snapback]

يا ريت اكون اكون من المستفيدين والاعضاء في هذه الدورة

موضوعك فعال وروعة

الى الامام

موضوع يستحق المتابعة

واسلوب مميز للشرح

لكن هناك سوال هل تعتقد من الصواب اذا كانت العلاقة ONE-TO -MANy أن يكون بينهم جدول صغير او ما يسمى بــ WEAK-ENTITY
او من الأفضل أن يكون ONE مفتاح غريب FORIGENKEY في جدول MANY ؟؟؟؟

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