مشكور يا اخى الكريم
و فى انتظارك و معك ابدا الدورة بقى........

مقدمة مملة أخرى!!

 

لكأني أرى الشوق ينهمر في عيونكم .. ولكأني أرى لعاب المبرمجين يسيل من أفواههم رغبة منهم في التهام سطور هذه الدورة والنهم الشديد تجاه أكوادها وأفكارها ..

 

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

 

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

 

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

 

 

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

 

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

 

3. جميع الاستعلامات سوف تنفذ عن طريق حبيبة الملايين SQL ولذلك يفضل أن يكون لدى الملتحق بهذه الدورة معلومات أولوية على الأقل لفهم أساسيات هذه اللغة. ( يكفي الإلمام البسيط بـSelect و Where و Max وما حولها)

 

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

 

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

 

 

 

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

 

في إنتظار ردودكم ... وأبشركم بأن موعد بداية الدورة قد قاب قوسين أو أدنى!!!

 

أخوكم : سامي عبدالغني الفتني

 

[email protected]

[email protected]السلام عليكم ورحمة الله وبركاته

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

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

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

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

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

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

4.

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

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

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

61660[/snapback]

اخى الكريم
انت مشكور على هذه الدورة كل الشكر
وارجو ان تبدأ

لا تبقى الصداقة ... دون (وصال)
لا تنجلى الأمور ... دون (مثال)
لا تظهر الشخصية ... دون (مقال)

ولا يظهر الأثر ... دون (فعال)

ولا أرى أثرا إلى الآن ... أرجوك هلم بالـ (فعال)

ارجو تحديد موعد لبدء الدورة على ان يكون محددا بيوم معين دون تسويف

الدرس الأول

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

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

الأخ مش أشكرك على اهتمامك .. وها أنا أحقق رغبتك وغبة الجميع ...

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


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

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

الفصل الأول

قاعدة بيانات بكائن وحيد

مقدمة

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

النموذج العلائقي لقواعد البيانات Relational Module

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

فعلى سبيل المثال يحتوي جدول الطلاب على ( اسم الطالب، اسم الأب، العمر، رقم الفصل) لاحظ ملاحظتين في غاية الأهمية:

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

o قد يسجل الطالب مادة واحدة وبالتالي سوف يكون هناك 49 حقل يحمل قيمة فارغة وهذا يعني هدر كبير للذاكرة، وهذه المشكلة تسمى Wasted Data أي البيانات المهدرة.

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

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

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

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

في العادة لكي يتم التفرقة بين الصفوف يتم وضع عمود نوعه Primary Key أي المفتاح الأساسي، فعند تعيين هذه الخاصية للعمود فإن قاعدة البيانات سوف تتخذ إجراءً صارماً على هذا الحقل من ناحيتين :

1. لن تسمح بترك قيمة الحقل خالية ( أي لا يمكن أن تساوي NULL ).

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

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


المفتاح الأساسي والمفتاح المرتبط به Primary Key and Foreign Key

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

شاهد الملف المرفق........


الآن لاحظ في الجدول السابق أن الحقل Code لا يتكرر أبداً في أي صف من الصفوف فليس هناك شركتين تحمل نفس الرمز أما في جدول الرحلات فسوف تجد نفس الحقل ولكن بالطبع من الممكن جداً أن يتكرر فمن الوارد جداً وجود أكثر من رحلة على نفس شركة الطيران، فعلى ذلك نقول أن الحقل Code في جدول الشركات هو مفتاح أساسي أما في جدول الرحلات فنسميه مفتاح مرتبط Foreign Key وبهذه الطريقة نكون قد فهمنا العلاقة بين الجدولين.

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

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

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

هذا هو الملف

Tab01.zip

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

أخي الكريم (شاقوهاد)

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

النقطة المهمة ... هناك مشكلة في تحميل الأمثلة .. يعني الموقع ما بيرضى تحميل امتداد . rar وبالنسبة للمثال اللي نزلته الآن أعتقد إنه غير شغال .. والله ما أدري ...

أرجو من مشرف المنتدى إبلاغي بهذا الخصوص وشكراً...

الملف فعلا غير قابل للتنزيل و ارجو اعاده رفعه مرة اخرى حتى نستفيد و نتفاعل اكثر مع هذه الدورة الرائعة

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

هذا هو الملف للمرة الثانية إن شاء الله إنه شغال

Tab1.bmp

أخواني .. لدي ملاحظة في غاية الأهمية ::

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

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

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

الله يجزاك خير ونحن نتظر بفارغ الصبر

أخواني ... السلام عليكم ... ورحمة الله

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

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

مثلاً أنا قلت ودنا نحدد يوم معين نجتمع فيه على البالتوك لتبادل الآراء والمصطلحات ... ولكن ما حدش رد.

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

على العموم راح أضع اليوم الدرس الثاني ... ونشوف ايش اللي حيحصل..

قاعدة بيانات بجدول واحد Modeling a Single-entity Database

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

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

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

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

مراجعة سريعة إلى لغة الاستعلام SQL

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

SELECT * FROM Share;

إظهار عمودين فقط لجميع الصفوف في الجدول :

SELECT ShrCode, ShrName FROM Share;

إظهار جميع الأعمدة لعشرة صفوف في الجدول (لا يمكن تحديد أي عشرة بالضبط):

SELECT TOP 10 * FROM Share;

إظهار جميع الأعمدة لربع عدد الصفوف ( 25 % ) :

SELECT TOP 25 PERCENT * FROM Share;

يمكن أيضاً إجراء العمليات الحسابية على الأعمدة، فمثلاً يمكننا إظهار الصف بالإضافة إلى إظهار نسبة الربح في كل صف.

SELECT s.*, ShrDIV/ShrPrice*100 AS Yield FROM Share AS s


لاحظ أنه يمكنك استخدام أحد المعاملات التالية مرتبة حسب أسبقية التنفيذ:
الأقواس ( )
الضرب والقسمة * | /
الجمع والطرح + | -

لاحظ أن المعامل AS يستخدم لإعادة التسمية سواء للحقل أو الجدول. بالنسبة لـ MS Access عند استخدام AS يجب وضع الاسم الجديد بين قوسين مربعين[ ].
إظهار الصفوف التي لها عدد من الأسهم يقل عن 12.000 سهم :

SELECT * FROM Share WHERE ShrQTY <= 12000;

لاحظ أنه يمكنك استخدام أحد المعاملات التالية :

يساوي =
أصغر من <
أصغر من أو يساوي <=
أكبر من >
أكبر من أو يساوي >=
لا يساوي <>

كما أنه يمكنك استخدام المعاملات AND و OR وذلك للربط بين أكثر من شرط، ففي المثال التالي سوف نعرض جميع الصفوف التي لها عدد من الأسهم ما بين 12.000 و 13.000 سهم :

SELECT * FROM Share
WHERE ShrQTY <= 12000 AND ShrQTY >= 13000;

باستخدام المعامل BETWEEN يمكنك تطبيق نفس العبارة السابقة على سبيل الاختصار كما في الشكل التالي:

SELECT * FROM Share
WHERE ShrQTY BETWEEN 12000 AND 13000;

السؤال الآن : عند استخدامك للعبارة السابقة ستلاحظ أن حدود المجال المسموح به غير واضحة، فهل ستظهر الحقول التي تحتوي على القيمة 12.000 أو 13.000 بالضبط أم أنها سوف تستبعد؟ الجواب هو أنه لا يوجد قانون يحكم هذا المعامل فبعض قواعد البيانات تعتبر الحدين ضمن المجال والبعض الآخر يضع الحد الابتدائي ضمن المجال والنهائي خارجه فلذلك نقول إن التجربة خير برهان. قبل استخدامك لهذه العبارة تأكد أولاً كيف تتعامل قاعدة البيانات مع هذا المعامل.
بالنسبة لقاعدة بيانات Microsoft Access فإن تعاملها مع حدود المعامل BETWEEN بإدخال كلا الحدين ضمن المجال سواءً في الأرقام أو التواريخ.
المعاملات السابقة كانت للمقارنة بين الأعداد أما الآن سوف نتعلم كيفية المقارنة بين القيم النصية وذلك بمساعدة المعامل LIKE. فمثلاً لإظهار أسماء الشركات التي يكون فيها الحرف الثالث n والحرف الأخير r فنكتب:
SELECT * FROM Share
WHERE ShrName LIKE '__n%r';

الرمز(_) يرمز إلى مكان حرف واحد لا نهتم بأمره.
الرمز(%) يرمز إلى عدد لانهائي من الأحرف لا نهتم بأمرها.
في MS Access استخدم (*) و(?) بدلاً من (%) و(_) على التوالي.
إظهار أي صف بحيث يكون اسمه الكودي ShrCode يساوي لأي من القيمة FC أو AR أو SLG . فبدلاً من كتابة عبارة OR مكررة في الاستعلام يمكن الاستفادة من المعامل IN كما في الشكل التالي:
SELECT * FROM Share
WHERE ShrCode IN ('FC','AR','SLG');
يمكن استخدام المعامل IN في مهمة أخرى غاية في الأهمية ولكن سنذكرها فيما بعض وذلك ضمن دروس الاستعلامات الفرعية.
نأتي الآن لكيفية استخدام الدوال التجميعية Aggregate Functions وهي دوال يتم تطبيقها على عمود واحد لتعطي قيمة واحدة بناءً على جميع قيم ذلك العمود. فمثلاً لإظهار قيمة أعلى سهم نستخدم الاستعلام التالي:
SELECT MAX(ShrPrice) AS [Maximim] FROM Share

أو الصيغة التالية:
SELECT ShrName,ShrPrice FROM Share
WHERE ShrPrice = (SELECT MAX(ShrPrice) FROM Share)

طبعاً يمكنك أيضاً استخدام الدوال الموجودة في الشكل Fig1_6

إذا ذكرت اسم العمود في الدالة Count فسوف يتم تجاهل الصفوف التي تحمل القيمة NULL لذلك العمود أما استخدام النجمة فإنها تحسب جميع صفوف الجدول ،ولذلك يفضل استخدام النجمة بدلاً من اسم العمود وإن كنا سوف نضطر لكتابة اسم أي عمود من الجدول للتمييز فيما إذا كنا نستخدم استعلام لأكثر من جدول كما سيأتي لاحقاً.
نأتي الآن إلى معامل هام جداً وهو DISTINCT وهو يعرض قيم عمود معين من دون تكرار، فإذا أردت مثلاً معرفة جميع نكهات العصيرات المتوفرة لديك في المحل فسوف تكتب شيئاً مشابها لما يلي:
SELECT DISTINCT Taste FROM Items
WHERE ItemName = 'Juice';
فلو كان هناك عصيران من شركتان مختلفتان من نكهة التفاح فلن تظهر كلمة التفاح سوى مرة واحدة في الاستعلام.
يمكن استخدام أكثر من عمود كما يلي :
SELECT DISTINCT Taste,Size FROM Items
WHERE ItemName = 'Juice';
فلو كان هناك عصيران من شركتان مختلفتان من نكهة التفاح ولكن المنتج الأول 200 مل أما الثاني 250مل، فسيظهر السطرين معاً في الاستعلام. أما الصف الذي سوف يختفي هو الصف الذي تطابق فيه قيمتي الحقلين معاً في صف آخر.
كذلك يمكن معرفة عدد النكهات لجميع العصيرات كما يلي:
SELECT Count(DISTINCT Taste) FROM Items
WHERE ItemName = 'Juice';
آخر شرط سوف نتحدث عنه وهو معامل الترتيب ORDER BY ويستخدم لترتيب البيانات المستخدمة تصاعدياً أو تنازلياً كما يلي :
SELECT * FROM Share
ORDER BY ShrPrice,ShrDIV DESC
تستخدم كل من ASC و DESC للتعبير عن الترتيب التصاعدي والتنازلي، وفي المثال السابق سوف يتم الترتيب تنازلياً حسب قيمة السهم وفيما إذا توافق صفين بنفس القيمة فإن ترتيباهما يكون حسب قيمة الربح.

Fig1_3.bmp

Fig1_4.bmp

Fig1_5.bmp

03_AirLines.zip

Fig1_6.zip

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

تحياتي وبالتوفيق

السلام عليكم ورحمة الله وبركاته
اخى الحبيب سامى اسلوبك فعلا ممتع وانا على اتم استعداد للمساعدة فى تحضير المادة العلمية التى تريدها - فمجال عملى كمبرمج بلغة ال RPG على AS400 اكسبنى الكثير من الخبرات فى مجال قواعد البيانات - فقد تعاملت مع عدد كبير من قواعد البيانات - ولكنى لا اعرف كيف اقدم العون
للتواصل :
[email protected]
[email protected]
ارجوا من العلى القدير أن يجعل أعمالنا خالصة لوجهه الكريم وأن يتقبل منا ومنكم
وجزاكم الله خيرا وجعلها الله فى ميزان حسناتك

اخوك :- عاصم عوض شعبان

تم تعديل 1 أبريل 200620 سنة بواسطة ASSIMAWAD

أخي العزيز ASSIMAWAD :

 

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

 

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

 

 

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

 

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

مشكور جداَ اخوي على هذا الشرح الوافي

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

ام لو تبغى تفاعل وتشجيع انا مستعد كل يوم اعطيك جرعات حماس و تشجيع بس انت أمر .

و انا على فكرة ما اشارك عادةً في المنتديات و مشاركاتي قليلة جداَ .

لكن قدام ما بدات فهذا اقل شيْ يقدم لك .

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

والله يوفقك و يكسب بعلمك جميع المسلمين

واعتذر ان مشاركتي جت متاخرة

... ودمتم

 

 

 

تحياتي

درس رقم : 3

 

الفصل الثاني

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

 

رأينا فيما سبق قاعدة بيانات تتكون من جدول واحد وفي الحقيقة إن أي قاعدة

 

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

 

إلى تكرار العديد من القيم على غير فائدة إضافة إلى زيادة كبيرة في احتمالية

 

وقوع أخطاء الإدخال من قبل المستخدم مثل الخطأ الإملائي وخلافه، إن الهدف الأساسي

 

من إنشاء العلاقات هو عدم الاضطرار لكتابة نفس القيمة أو القيم في أكثر من

 

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

 

ووضعه في جدول منفصل يحمل جميع القيم المحتملة له ومن ثم الإشارة إلى كل قيمة من

 

الجدول الأساسي.

طبعاً قد يبدو الكلام غامضاً ولكنه سيتضح في الفقرات القادمة حينما نتحدث عن

 

الموضوع بشكل عملي :

 

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

 

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

 

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

 

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

 

نظيره لكي تكتمل بياناته كما في الشكل التالي :

 

شكل 2_1

 

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

 

واحد يحمل جميع صفات الشخص ولكن أحياناً تجد في بعض الحالات أن التقسيم يوفر عليك

 

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

 

خاصة من الصفات، ولكن قد لا يكون بالضروري أن نملأ جميع البيانات لكل شخص،

 

فإذا علمت سلفاً أن معظم الأفراد لا تهمنا من بياناتهم سوى العمر والجنس أما

 

بقية البيانات فلا نسجلها إلا قليلاً جداً، في هذه الحالة لو كانت جميع البيانات في

 

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

 

أما بطريقة التقسيم فإننا نضع البيانات المطلوبة دائماً في الجدول الأساسي أما

 

البيانات الأخرى فنضعها في جدول آخر وفي حالة الرغبة في تسجيلها فإننا نضيف

 

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

 

 

شكل 2_2

 

قد يبدو المثال السابق غير ذا أهمية كبيرة ولكن لتعلم عزيزي القارئ إن أهمية

 

العلاقات التي من هذا النوع تظهر في قواعد البيانات الكبيرة كأن يكون للجدول

 

الواحد أكثر من مائة عمود ومعظمها لا يسجل إلا نادراً من بين ملايين السجلات التي

 

تسجل، أعتقد في هذه الحالة أنت بحاجة إلى تروٍ كبير حتى تبني قاعدة بياناتك على

 

أساس قوي يتحمل دهس عربات الزمن.

وعلى وجه السرعة سوف نضع لك مثالاً آخر عن نفس العلاقة الذي ربما يكون أوضح من

 

السابق، لنفترض أن لدينا قاعدة بيانات لشركة ما مكونة من جدولين، الأول يحمل

 

بيانات الموظفين أما الآخر فيحمل بيانات أقسام الشركة (اسم القسم ، موقعه ،

 

تخصصه ، اسم المدير)، ولكن لحظة!! أليس المدير هو أحد موظفي الشركة!! إذا من

 

الخطأ تماما أن نضع بيانات المدير في نفس جدول الأقسام، والحل الأمثل هو أن نضع في

 

جدول الأقسام رقم الموظف الذي هو مدير القسم، أما بيانات المدير فتكون ضمن

 

جدول الموظفين لأنه يحمل جميع بياناتهم.

 

 

شكل 2_3

 

وحيث أن كل قسم لابد له من مدير واحد وأن الموظف لايمكن أن يكون مدير لأكثر من

 

قسم إذا نقول إن العلاقة هي علاقة رأس برأس، وتمثل هذه العلاقة بيانياً بخط

 

مستقيم كما هو موضح في الشكل السابق.

 

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

 

**** كلمة مملة كالعادة

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

 

الآخر لا يدري كنهه أو وظيفته .. لقد خصصته بدرس منفصل حتى تظهر أهميته أكثر

 

.. فعلاقة رأس برأس لها العديد من الفوائد .. أرجوا طرح الآراء ووجهات النظر

 

حول الموضوع .. لإثارة حلقات النقاش وشكراً للجميع.

 

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

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

 

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

[email protected]

Fig.zip

ممكن توضح انواع العلاقات اكثر