فتح الله عليك يا استاذنا ورحم الله والديك أسأل المولى عزوجل ان يعتق رقبتك من النار انت ووالديك واهلك ومن تحب وجميع اخواننا في منتدانا العزيز و ذلك كما اعتقتنا من قراءة الكتب الكثيرة التي تستنزف جيوبنا والفائدة محدودة ووالله وبدون مجاملة لم تتضح لي الرؤيا بخصوص الروابط والمفتاح الاساسي الا الآن مع انني قرأت العديد من الكتب وبالمناسبة لماذا لا تفكر في تأليف كتاب عن الاكسس مثلآ. انا متأكد باذن الله انه سيحقق شهرة واسعة فاسلوبك جميل ويخاطب جميع الفئات .
الأسس العلمية لقواعد البيانات
الأخ العزيز internet master جزاك الله كل خير في هذا الشهر المبارك, ووفاك بأجر عظيم عن كل حرف كتبته في هذا المنتدى.
هل أذنت لي بالاتصال بك عن طريق بريدك الخاص للتحدث معك عن ما أريد الوصول اليه؟

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

السلام عليكم ورحمة الله وبركاته
تم وضع رابط للموضوع في منتدى Oracle و منتدى SQL وتثبيته في أعلى المنتدى .
http://www.arabteam2000.com/ib/index.php?s...showtopic=35369
http://www.arabteam2000.com/ib/index.php?s...showtopic=35370
أخي الخبير الكبير أسأل الله تعالى لي ولك التوفيق وأن يجمعنا في الفردوس الأعلى في الجنان مع نبيه وأصحابه الكرام
آمين
مرحبا،،،
مازلت في مرحلة إنشاء أسئلة المسابقة -- وآمل أن أستطيع إنهائها الليلة بمشيئة الله.
نعود إلى العم CODD والعلاقات، ونكرر أن ما نقوله هنا ليس له علاقة بأي برنامج بل ينطبق على Oracle و Microsoft SQL وغيرهم أيضا.
ما زال هدفنا هو تماسك وتكامل قاعدة البيانات كذلك تسهيل عملية إدخال البيانات لصديقنا المسكين (مدخل البيانات).
ووصلنا أن قاعدة البيانات لدينا ما زالت هشة وقابلة للكسر لسبب أن طريقة تصميمها تتيح للحقل الغريب أن يحتوى بيانات غير موجودة وكذلك يتيح بيانات فارغة.
لنزيد من حجم المشكلة قليلا للتفاعل مع صديقنا (أحمد الحربي)، إذهب إلى صفحة العلاقات من أدوات ثم علاقات.
نقر مزدوج على الخط الواصل بين الجدولين وضع علامة صح على إختيار (فرض التكامل المرجعي) سيظهر لك مربعان إضافيان اتركهما الآن بدون علامة صح. إضغط موافق، ماذا حدث؟؟؟؟
انت الآن تطلب من الآكسس او من MS SQL أن يساعدك في إلقضاء على إحتمالية تولد أيتام في قاعدة البيانات !!! ولهذا يقول لك الأكسس او أي برنامج آخر (آسف لا أستطيع مساعدتك) من يقول لماذا؟؟؟
صح -- لأن قاعدة البيانات أصلا فيها أيتام.
ما هي المشاكل التي نحاول حلها والتي واجهتنا في الحلقة السابقة:
نستطيع ترك الحقل الغريب فارغا
نستطيع ادخال اي قيمة في الحقل الغريب دون شرط وجودها في الحقل المرتبط فيه
نستطيع حذف أب وترك أبنائه بدون أب --- أيتام Orphans
نستطيع تعديل رقم الأب في جدول الآباء من 4000 إلى 4500 وبهذا يفقد الأب أولاده المرتبطين فيه على رقم 4000 وليس 4500
كل ما سبق مشاكل تؤدي إلى عدم تكامل وتماسك قاعدة البيانات -- لا بد من حل المشاكل الأربعة السابقة واحدة تلو الأخرى.
اترك العلاقات بدون فرض التكامل المرجعي (ترجمة ثقيلة على القلب)
اذهب إلى جدول الأبناء وقم بوضع أب للطفلين 180 و 190 وليكن ابوهما رقم 6000
أي ادخل 6000 في الحقل الغريب.
لنتأكد من السجلات.
في جدول الآباء
3000 محمد سعيد أحمد 42
4000 خالد عبد الله الصيعري 61
5000 سعيد محمد المالكي 32
6000 طلال عبد العزيز المسبحي 29
7000 سمير خالد الجار الله 46
9000 أحمد مبارك الحربي 42
في جدول الأبناء
100 خالد 7 3000
110 محمد 4 3000
120 سعيد 9 4000
130 طارق 12 4000
140 أحمد 5 5000
150 سمير 17 5000
160 فهد 1 5000
170 مشاري 3 9000
180 صالح 9 6000
190 ناصر 11 6000
اذهب مرة أخرى الى العلاقات وضع صح على مربع فرض التكامل واترك المربعين الآخرين فارغين.
افتح جدول الأبناء وأضف الطفل التالي:
200 سلطان 12
وحاول أن تضع أي قيمة غير القيم التالية (3000, 4000, 5000, 6000, 7000, 9000) وكذلك لا تتركه فارغا.
ماهي المشكلة التي تم حلها من الأربعة مشاكل بعاليه؟
تم حل المشكلة الثانية حسب الترتيب السابق، الآن إما أن تضع قيمة موجودة في جدول الآباء أو ن تتركه فارغا... لن يستطيع مدخل البيانات الآن إختراع قيمة من عنده.
إذهب إلى جدول الآباء -- حاول حذف أي أب له أبناء مثل الأب رقم 3000، مممممم لا تستطيع مهما حاولت لأن ذبح الأب سيترك ... ماذا؟ نعم أيتام ولهذا فهو ممنوع.
حاول تعديل رقم أي أب له أبناء مثل الأب رقم 4000 حاول أن تجعله 4500!!! مممممممم لا تستطيع مهما حاولت لأن تغيير رقم الأب سيترك كل الأطفال الذين أبوهم رقمه 4000 بدون أب.
كم مشكلة بقيت --- صح مشكلة واحدة وهي ترك الحقل الغريب في جدول الأبناء فارغا، ومن التجربة العملية في السوق أقترح ترك هذه الثغرة دائما في بداية التصميم مع أخذ ملاحظات عن هذه الحقول ومن ثم حلها فيما بعد. لماذا؟
نعود لصديقنا (أحمد الحربي) وتوجيهه لنا، السبب هو أننا في مرحلة التفكير والتصميم سنحتاج إلى بيانات غير صحيحة لتجريب التماسك والتكامل لقاعدة البيانات ولا نريد كل دقيقة أن ينط لنا الآكسس او إس كيو إل ويظهر لنا خطأ ما.
أما كيف نحل المشكلة الرابعة فهي من خصائص الحقول، إفتح جدول الأبناء في التصميم ونشط الحقل الغريب وأنظر في الأسفل سترى خاصية (مطلوب) أو Required عند تعديلها من (لا) إلى (نعم) لا نستطيع ترك الحقل الغريب فارغا.
لدينا الآن قاعدة بيانات Intergated أي متكاملة ومتماسكة --- ولكن لحظة .... توقف...
يوجد مصيبة في هذا التصميم !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
يوجد الآن مشاكل حقيقية في تصميم قاعدة البيانات حتى مع تماسكها وتكاملها.
من يقول لي لماذا؟
فكرووووووووووووووووووووووووووا
ولا تنسوا أن القراءة لا تفيد ---- إكتبوا كل الملاحظات.
تحياتي،،،
اعتقد ان المشكلة الآن اننا لا نستطيع حذف اي سجل من جدول الآباء
اقصد انه لا نستطيع حذف اي اب الا بعد حذف ابناءه اولا ً ..... مع انها من قواعد السيد CODD الا انني اراها مشكلة المفروض اذا حذفت اب يتم حذف ابناؤه معه
كذلك المشلكة الاخطر .....لايمكن اضافة سجلات جديدة لجدول الاباء
اسف تراجعت عن المشكلة الثانية فبالامكان اضافة سجلات
كذلك اي اب ليس له ابناء نستطيع تغيير حقل المفتاح الاساسي له
واصل واصل أيها المبدع الرائع الجميل .. والله جعلت المنتدى شعلة وفقك الله
سؤال متقدم للمحترفين والأذكياء --- متى نحتاج إلى علاقة على شكل واحد إلى واحد؟ ما أهميتها؟
ج/لناحية أمنية حين لا نريد من مدخل بيانات الموظفين من رؤية رواتبهم وكذلك العكس فنجعل بيانات الموظفين في جدول ورواتبهم في جدول آخر ونربط بينهم بعلاقة واحد لواحد
تم تعديل هذه المشاركة بواسطة أحمد الحربي في 8 نوفمبر 2003 في 03:37
ربما المشكلة في خصائص الحقول حيث بإمكان مدخل البيانات إدخال رقم في حقل الإسم وبالتالي بيانات خاطئة .. أقول ربما
واصل يامبدع ..
جعل الله ذلك في ميزان حسناتك ..وزادك علماً وفهماً ..
بشر المشّائين في الظُلم بالنور التام يوم القيامة..
السلام عليكم
بارك الله فيك ونفعك بالعلم النافع والعمل الصالح وزادك الله علما
والله يوفقك
تم تعديل هذه المشاركة بواسطة اا الفاروق اا في 8 نوفمبر 2003 في 17:04
" وما توفيقى إلا بالله عليه توكلت وإليه أنيب "
-------------------------------------------------
قل : " لا حول ولا قوة إلا بالله "
-------------------------------------------------
مرحبا،،،
أولاً... للأخ (أحمد الحربي) الله ما أجمل وأروع إجابتك وبالذات الإجابة على سؤال متى نستخدم العلاقة واحد إلى واحد.
بالظبط -- في حالة واحدة فقط -- عندما نحتاج إلى زيادة النواحي الأمنية في قاعدة البيانات (طبعا ليس حماية قواعد البيانات بل حماية البيانات نفسها من الإطلاع عليها) ويتم هذا بفص حقول الجدول الواحد إلى جدولين أو أكثر ويربط بينهما بنفس المفتاح الرئيسي --- العلاقة واحد إلى واحد تعني أن الربط يتم بين مفتاحيين رئيسيين. اما كيف نفصل بين الجدولين وكيف نوزع الحقول فهذا جزئية قد نتحدث عنها إذا أسعفنا الوقت وتسمى Normalization
يا سلام يا أخ (احمد الحربي) اكثر من رائع.
لدينا الآن قاعدة بيانات تنطبق فيها كل قوانين CODD ومتكاملة ومتماسكة. ولكن فيها مشكلتين أساسيتين تطرق بعض الأخوة لهما:
المشكلة الأولى: ماذا نفعل إذا أردنا فعلا أن نحذف أي أب؟
المشكلة الثانية: ماذا نفعل إذا أردنا فعلا أن نغير رقم أي أب؟
في التصميم الحالي لا نستطيع؟؟؟
لحظة.... ركز معي
إذا كان الأب بدون أطفال، فلا مشكلة لدينا -- نستطيع حذفة وهذا لا ينتج عنه أيتام، وكذلك نستطيع أن نغير رقمه وأيضا لا ينتج عن هذا أيتام. بالإستنتاج نستطيع أن نحذف أب بعد أن نقوم أولا بحذف كل أولاده. ولكن هذا فيه إجهاد كبير لماذا؟
لأننا نتخيل أن قاعدة البيانات فيها 5000 جدول وكل جدول فيه آلاف الحقول وكل جدول فيه ملايين السجلات، هل من المنطقي والعملي أن نذهب كل مرة إلى جدول (المتعدد) ونحذف السجلات كلها ثم نذهب إلى جدول الواحد وحذف سجل واحد من هناك، طبعا العملية مجهدة وقابلة للأخطاء... لا بد من وجود حل عملي ومنطقي.
أعد قراءة المشكلتين أعلاه بتمعن،،، ماذا تلاحظ -- المشكلة الأولى (حذف) والمشكلة الثانية (تحديث) او (تعديل).
افتح صفحة العلاقات من أدوات ثم علاقات من القائمة.
نقر مزدوج على الخط الواصل بين الجدولين.
إقراء المربعين الذين يوجدان تحت خاصية (فرض التكامل) ... توقف --- ركز -- إقرأ مرة أخرى
واحدة فيها كلمة (تحديث) Update والأخرى فيها (حذف) Delete وهو ما نبحث عنه فعلياً، صح؟
إقرأ مرة أخرى بتمعن وتركيز أكبر، ستجد ان الحذف يتعلق بالسجلات ....مممم
وأن التحديث يتعلق بالحقول .... ممممممممم
كالعادة، لماااااااااااااااااااااذا؟
ماذا يعني كل ما سبق،، عن ماذا نبحث؟ ماذا نفعل؟
نريد حلاً للمشكلتين أعلاه...
نريد عن تعديل أو تحديث رقم الأب في جدول الآباء ----- ماذا؟ أين يتم تلقائيا تحديث رقم هذا الأب في جدول الأبناء.
ضع علامة صح على الإختيار الأول (تحديث الحقول المرتبطة) --- اقفل النافذة
إذهب إلى جدول الآباء وغير (عدل) (حدث) رقم الأب 4000 إلى 4500
ماذا حدث؟؟
ممممممممممممم ---- لم يظهر خطأ.
أقفل جدول الأباء وإفتح جدول الأبناء --- الآن يجب أن تجيب ماذا حدث؟ ماذا تغير؟
آليا قام الآكسس أو Oracle أو MS SQL بتحديث -- بتغيير -- بتعديل --- سمها ما شئت، قام بماذا؟ بتحديث الحقل الغريب (المرتبط) ولا يوجد الآن أب برقم 4000 كل أب يحمل الرقم القديم أصبح الآن يحمل الرقم 4500
هل تلاحظ التماسك والتكامل --- لا يمكن صناعة أيتام -- أقفل الجدول
بالإستنتاج وبالقياس نذهب إلى العلاقات مرة أخرى من أدوات ثم علاقات
الآن ضع علامة صح على الخاصية الثانية (حذف السجلات) -- أعتقد أنها واضحة الآن
إضغط موافق وأقفل صفحة العلاقات ثم إفتح جدول الآباء.
قم بحذف الأب صاحب الرقم 4500 -- ماذا تقول الرسالة؟ لاحظ في السابق كان الحذف ممنوعاً ولكنه الآن يقول لك في الرسالة (لا بأس) سأحذف لك هذا الأب ولكن بشرط واحد هو أنني سأحذف كل أولاده أولاً -- هل توافق؟ إضغط نعم.
تم حذف الأب --- ليس هذا فقط --- اقفل جدول الآباء وإفتح جدول الأبناء، ماذا تلاحظ؟
نعم لا وجود لأي إبن بأب ذو رقم 4500
قاعدة بيانات متكاملة ومتماسكة من الدرجة الأولى.
الرجاء ممن لم يشتغلوا معي خطوة بخطوة عدم الإستمرار حيث سنأخذ منحى صعبا الآن وسنعقد العملية أكثر وأكثر... إذا أردت أن تفهم إقرأ وطبق يدويا من الأول.
تعالو بنا الآن نزيد قليلا من التعقيد ولا تنسوا أن الهدف خلال رحلتنا بكاملها هو المحافظة على التماسك والتكامل.
تحياتي،،،
تقبل الله صيامك أيها الأخ internetmaster , أبهرتني بأسلوبك الشيق,وفقك الله فيكل ما نويته من خير في هذا المنتدىو عوضك الله بأجر عظيم عن عطلتك التي تضحي بها من أجل انارة اخوانك.
مرحبا،،،
في حوالي 90% من الحالات العلاقة بين الجداول هي واحد إلى متعدد وفي حوالي 1% هي واحد إلى واحد.
واحد إلى متعدد هي العلاقة التي يجب أن تبحث عنها دائماً لأنها الأسهل والأفضل والأوضح والأكثر منطقية في عمليات الربط.
ولكن عالم قواعد البيانات ليس سهلاً دائما وممتعا، تعال نحاول حل هذه المشكلة، في ترقيم السيارات عندنا في المملكة العربية السعودة مثلاً لوحات السيارات تأخذ 6 خانات ثلاثة أحرف وثلاثة أرقام، عندنا نريد إنشاء قاعدة بيانات لكافة سيارات المملكة لدينا مشكلة أساسية.
تعالو بنا سويا نحاول حل هذه المشكلة.
الحل الأول هو إنشاء مفتاح رئيسي يتكون من 6 خانات وهذا قد يكون حلا سريعا للمشكلة ولكنه يتطلب حلولا برمجية للمساعدة مثلا لعمل Mapping أو ترسيم بين الحروف العربية والحروف اللاتينية مثلا.
لنسهل الموضوع ونفترض أن الإدارة العامة للمرور منعتنا من إستخدام حقل واحد.
ما هو الحل... إنشاء حقلين كل واحد منهما 3 خانات، وبهذا يصبح لدينا حقل من ثلاثة أرقام وحقل آخر من ثلاثة حروف. ولتسهيل العملية سأفترض أن الحروف باللغة الإنجليزية مثلا للهروب من التشبيك في اللغة العربية (ليس الهدف ترقيم السيارات الآن الهدف هو أن نفهم سويا الموضوع).
وبهذا لترقيم سيارة ما KLT 376 بحيث نضع KLT في حقل ونضع الرقم 376 في حقل آخر
هذا حل جيد (حتى وإن كنت لا أحبذه إطلاقا من الخبرة) ولكن الهدف هو شرح الموضوع.
الآن ما هو المفتاح الرئيسي لهذا الجدول.
إنشأ جدولا في قاعدة البيانات Family وفيه الحقلان التاليان:
PlateLet نص 3 -- للكناية عن الأحرف الثلاثة لرقم لوحة السيارة
PlateNum نص 3 -- للكناية عن الأرقام الثلاثة لرقم لوحة السيارة
لا تنس قاعدة مستر CODD والتي تنص على أن لكل جدول مفتاح أساسي، لاحظ كلمة (مفتاح) وليس (مفاتيح) !!!! واضح؟
مرة أخرى للتأكد من طرح الموضوع بشكل جيد --- مفتاح واحد فقط وليس مجموعة من المفاتيح.
نعود إلى لوحة السيارة --- ما هو المفتاح الرئيسي في هذا الجدول علما بأنه يوجد لدينا الآن أربع سيارت لوحاتها كالتالي:
رقم لوحة السيارة الأولى --- KLT 376
رقم لوحة السيارة الثانية --- KLT 950
رقم لوحة السيارة الثالثة --- RMD 376
رقم لوحة السيارة الرابعة --- RMD 950
فلنعبث قليلا...
لنفترض أن الحقل PlateLet الخاص بالحروف هو المفتاح الرئيسي --- ما هي المشكلة؟
صح، لن نستطيع تكرار البيانات في هذا الحقل وبالتالي لن نستطيع إدخال KLT وكذلك RMD أكثر من مرة واحدة ---- مشكلة --- هذا الحقل لا يصلح أن يكون مفتاحا رئيسيا.
لنفترض أن الحقل PlateNum الخاص بالأرقام هو المفتاح الرئيسي --- ما هي المشكلة؟
صح، لن نستطيع تكرار البيانات في هذا الحقل وبالتالي لن نستطيع إدخال 376 وكذلك 950 أكثر من مرة واحدة ---- مشكلة --- هذا الحقل لا يصلح أن يكون مفتاحا رئيسيا.
لدينا حقلين فقط وكلاهما لايصلح أن يكون مفتاحا أساسيا وفي نفس الوقت لا بد من وجود مفتاح أساسي؟؟؟ معضلة !! وطبعا لم تسمح لنا إدارة المرور بإضافة حقل جديد ندعيه أساسيا.
ما هو الحل؟
يقول لنا CODD إذا كنت مضطرا لجعل المفتاح الرئيسي يتكون من أكثر من حقل فلا بأس -- ولكن لا تنس أن هذا الحل فقط عندما تكون مضطرا...
واضح أن كلمة (مضطرا) هذه تعني إستثناء وليس قاعدة وهي تعني أيضا أن نحاول الهرب من هذا الحل قدر الاستطاعة. ولكن هل لدينا حل هنا --- طبعا لدينا ولكننا قمنا بإلغاء هذه الحلول لتوصيل فكرة في غاية الأهمية لن تفيدنا مع السيارات ولكن ستفيدنا مع الآباء وكذلك في المستوصف.
قم بتنشيط الحقلين PlateLet و PlateNum مع بعضهما البعض من خلال الضغط والسحب من أقصى اليسار أو أقصى اليمين حسب الآكسس لديك ومن ثم إضغط المفتاح في شريط الأدوات.
ماذا حصل؟ قام الآكسس بوضع مفتاح بجانب كل حقل من الحقلين....
الآن ركز بشدة معي--- لا يوجد أكثر من مفتاح أساسي في الجدول -- متفقين؟
إذا ماذا نسمي الذي أمامنا؟
الذي أمامك الآن هو مفتاح أساسي واحد فقط ولكن يتكون من حقلين إثنين!!!
ماذا يعني هذا؟
يعني أن المفتاح الأساسي هو ناتج جمع الحقلين مع بعضهما البعض وليس كل حقل على حدة !!!!
وطالما أنه يمنع تكرار البيانات في المفتاح الأساسي -- فالتكرار هنا ممنوع لمجموع الحقلين وليس لكل حقل على حدة!!!
تعالو بنا نفهم بشكل أفضل
خزن الجدول بإسم Plates بعد أن تطمئن انه يوجد رسمة مفتاح بجانب كل حقل من الحقلن.
تعالوا بنا ندخل بيانات في هذا الجدول...
أدخل الحروف KLT في حقل PlateLet ثم حاول الإنتقال إلى السجل التالي--- ماذا حدث؟ خطأ طبعا،،، لماذا؟ لأن حقل المفتاح الأساسي لا يمكن أن يكون فارغا -- ولكننا وضعنا قيمة في هذا الحقل --- صح وضعنا قيمة في حقل PlateLet ولكنه ليس هو المفتاح الأساسي -- مرة أخرى ماهو المفتاح الأساسي في هذا الجدول --- المفتاح الأساسي هنا هو ناتج جمع قيمة الحقلين سويا مع بعضهما البعض وليس PlateLet لوحدها وكذلك ليس PlateNum لوحدها.
امسح القيمة KLT وحاول إدخال 950 في حقل PlateNum لن تسطيع.
إذا كان المفتاح الأساسي يتكون من حاصل جمع أكثر من حقل فإن ترك أي حقل منهم فارغا يؤدي إلى أن المفتاح الأساسي فارغا وهذا ممنوع.
لن تستطيع الإنتقال من هذا السجل إلا في حالة واحدة فقط وهي إدخال KLT في PlateLet وكذلك إدخال 950 في PlateNum وهذا منطقي حسب ما فهمناه.
قم بإدخال السجل السابق وتعال ندخل سويا سجلا آخر وهو KLT 376 لاحظ أن الآكسس وكذلك الأوراكل وغيرهما سيسمحون لك بإدخال هذه اللوحة ... من يجيب لماذا؟
لماذا سمح لنا الآكسس بتكرار KLT في حقل PlateLet؟ من يجيب؟
الإجابة لأن PlateLet ليس مفتاحا رئيسيا
الإجابة لأن PlateNum ليس مفتاحا رئيسيا
المفتاح الرئيسي هو ناتج جمع قيمة الحقلين
ما هو السجل الذي سيمنعا الآكسس من إدخاله --- من يجيب؟
تحياتي،،،
أحاول:
السجل الذي يمنعنا الأكسس من اضافته هو سجل RMD 376
او محاولة ادخال جزء من السجل كأن نحاول اضافة سجل ناقص مثلا RMD دون الثلاثة أرقام.
عذرا عن المحاولة.
ما هو السجل الذي سيمنعا الآكسس من إدخاله --- من يجيب؟
هو ادخال نفس القيمه السابقة في سجل جديد يتكون من الحقلين المفروض انهما
يشكلان مفتاح رئيسي بجمعهما
مثلا نعيد تكرار ادخال هذه القيمه KLT 376
وبهذا خالفنا المفتاح الاساسي وهو ناتج جمع الحقلين
سيمنعنا الأكسس من إضافة أي سجل تكون بيانات كلا الحقلين PlateLet و
PlateNum فيه مماثلة لبيانات نفس الحقلين لسجل سابق لأن المفتاح الأساسي في هذه الحالة بيانات كلا الحقلين يعني سيمنعنا الاكسس من ادخال البيانات التالية
KLT 376 و KLT 950
وبصراحة ياعزيزي حباك الله بموهبة في توصيل المعلومة وفي قدرتك على التشويق
ياليت إذا مافي مانع تعطينا أيميلك على اساس نتعرف عليك أكثر
وهذه دعوة من لك:
أسأل الله العلي القدير أن يوفقك لكل مافيه خير وصلاح وأن يرزقك خير الدنيا والآخرة وان
وأن يجنبك شر الدنيا والآخرة بحق هذا الشهر المبارك
تحياتي لك
تم تعديل هذه المشاركة بواسطة ha98 في 8 نوفمبر 2003 في 21:24
حياك الله أخي
أقترح عليك اقتراح بسيط
انه بعد الانتهاء من هذه السلسلة الرائعة أن يتم تجميعها في ملف وورد ثم يرفق في آخر الموضوع تماماً ليستفيد منه الأعضاء بصفة مجملة
مع خالص تحياتي
السلام عليكم
جزاك الله خيرا و جعله فى ميزان حسناتك
و نتمني زيادة عدد المستفيدين من هذه السلسلة الرائعة
لقد ثبتت الوصلة الي هذا الموضوع فى قسم االاكسس العام بمنتدي أوفيسنا و أدعو كل من يشارك فى أي منتدي له علاقة بقواعد البيانات أن يضع وصلة لهذا الموضوع فيه مثلما دلنا عليه الأخ صاحب الموضوع المثبت - ليزيد معدل الفائدة من جهد أخونا الكريم ، و فى نفس الوقت يزيد نسبة من سيدعون له بإذن الله تعالي
أخونا الكريم
هل نطمع بالاضافة الي شرحك الرائع أن ترفق لنا القواعد الكاملة للمستر CODDأو أي مستندات متاحة لها علاقة بالموضوع عربية كانت أو انجليزية طمعاً فى الاستزادة
مع جزيل الشكر و التحية (( و الدعاء )))
تم تعديل هذه المشاركة بواسطة محمد طاهر في 8 نوفمبر 2003 في 23:03
جزاك الله خيرا َ وغفر لك وزادك من خيري الدنيا والآخرة
حقاَ أنت معلم ومدرب بارع
رغم أن المعلومات قد درستها من سنين طويلة إلا أن طريقة عرضك لها توحي لي أني أقرأها لأول مرة
وفقك الله
لأخي محمد طاهر عسى أن تجد فيها فائدة بالنيابة عن أخي انترنت ماستر لعله يأذن لي في ذلك
وستجد تأصيلاَ جيداَ في كتاب
An introduction to database systems
ل
C. J. Date
من نشر دار
Addison Wesley
Dr. E.F. Codd, an IBM researcher, first developed the relational data model in 1970. In 1985, Dr. Codd published a list of 12 rules that concisely define an ideal relational database, which have provided a guideline for the design of all relational database systems ever since. I use the term "guideline" because, to date, no commercial relational database system fully conforms to all 12 rules. They do represent the relational ideal, though. For a few years, scorecards were kept that rated each commercial product's conformity to Codd's rules. Today, the rules are not talked about as much but remain a goal for relational database design. Following is a list of Codd's 12 rules, including his original name for each rule and a simplified description. I also have included a note where certain rules are problematic to implement. Don't worry if some of these items are confusing to you, as we move further through this newsletter series we will fill in the details. Rule 1: The Information Rule All data should be presented to the user in table form. Last week's newsletter already discussed the basics of this rule. Rule 2: Guaranteed Access Rule All data should be accessible without ambiguity. This can be accomplished through a combination of the table name, primary key, and column name. Rule 3: Systematic Treatment of Null Values A field should be allowed to remain empty. This involves the support of a null value, which is distinct from an empty string or a number with a value of zero. Of course, this can't apply to primary keys. In addition, most database implementations support the concept of a nun- null field constraint that prevents null values in a specific table column. Rule 4: Dynamic On-Line Catalog Based on the Relational Model A relational database must provide access to its structure through the same tools that are used to access the data. This is usually accomplished by storing the structure definition within special system tables. Rule 5: Comprehensive Data Sublanguage Rule The database must support at least one clearly defined language that includes functionality for data definition, data manipulation, data integrity, and database transaction control. All commercial relational databases use forms of the standard SQL (Structured Query Language) as their supported comprehensive language. Rule 6: View Updating Rule Data can be presented to the user in different logical combinations, called views. Each view should support the same full range of data manipulation that direct-access to a table has available. In practice, providing update and delete access to logical views is difficult and is not fully supported by any current database. Rule 7: High-level Insert, Update, and Delete Data can be retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. This rule states that insert, update, and delete operations should be supported for any retrievable set rather than just for a single row in a single table. Rule 8: Physical Data Independence The user is isolated from the physical method of storing and retrieving information from the database. Changes can be made to the underlying architecture ( hardware, disk storage methods ) without affecting how the user accesses it. Rule 9: Logical Data Independence How a user views data should not change when the logical structure (tables structure) of the database changes. This rule is particularly difficult to satisfy. Most databases rely on strong ties between the user view of the data and the actual structure of the underlying tables. Rule 10: Integrity Independence The database language (like SQL) should support constraints on user input that maintain database integrity. This rule is not fully implemented by most major vendors. At a minimum, all databases do preserve two constraints through SQL. No component of a primary key can have a null value. (see rule 3) If a foreign key is defined in one table, any value in it must exist as a primary key in another table. Rule 11: Distribution Independence A user should be totally unaware of whether or not the database is distributed (whether parts of the database exist in multiple locations). A variety of reasons make this rule difficult to implement; I will spend time addressing these reasons when we discuss distributed databases. Rule 12: Nonsubversion Rule There should be no way to modify the database structure other than through the multiple row database language (like SQL). Most databases today support administrative tools that allow some direct manipulation of the datastructure. Over the life of this newsletter, I will be expanding on the concepts covered by each of Codd's rules. I will use the relational query language of choice, SQL, to illustrate these concepts and explain relational database structure in detail. http://www.itworld.com/nl/db_mgr/05072001/ http://www.nap.edu/readingroom/books/far/ch6.html http://www.acm.org/classics/nov95/toc.html
مرحبا،،،
بالنسبة للأخوة والأخوات الذين يسألون عن بريدي الإلكتروني فهو Info@arabserver.net راجيا من الجميع ملاحظة أنني بعد 20 رمضان سأكون في غاية الإنشغال لإرتباطي بعدة مواضيع ومشاريع وتنقلات ويمكنهم مراستلي (عذرا) للأمور الطارئة جدا. الرجاء ملاحظة أن موردا أساسيا من رزقي (بفضل الله) هو من البرمجة وقواعد البيانات. وبإذن الله سأشرح لكم في آخر هذه الدروس كيف تقومون بتحويل علمكم إلى ما يعود عليكم بنقود.
أما بالنسبة للأخ الذي وضع القوانين الخاصة بالسيد CODD فأتقدم له بجزيل الشكر راجيا من الجميع:
عدم ترجمتها إلى اللغة العربية ونشرها -- حتى لا تؤدي إلى بلبلة فكرية نحن جميعا في غنى عنها.
ملاحظة أن القوانين من القانون التاسع إلى القانون الثاني عشر لم تطبق حتى الآن في أي لغة قواعد بيانات لا الآكسس ولا الأوراكل ولا MS SQL ولا غيرها، وبالتالي لم يتم إنشاء أي قاعدة بيانات علاقية في العالم تتبنى القوانين من 9 إلى 12.
أما إقتراح الأخ بتجميع كل المشاركة في ملف وورد فآمل منه أن يقوم بهذه نيابة عني شاكرا ومقدرا له هذا الجهد.
نعود...
كم أنا سعيد أن وأنا أقرأ الإجابات على السؤال الذي تركناه في الحلقة السابقة وقد كانت كل الإجابات صحيحة وتشرح الصدر. فعلاً أصبح المفتح الأساسي هو ناتج مجموع قيمتي الحقلين وبهذا لن تستطيع تكرار رقم اللوحة الذي يتكرر في كلا الحقلين.
لننسى جدول Plates الخاص بأرقام لوحات السيارات ونتكفي منه بهذا القدر.
قم بإنشاء الجدول التالي سواء في الآكسس أو الأوراكل أو MS SQL وهو جدول الأصناف إطلق عليه الإسم Items وضع فيه الحقول التالية:
ItemNum نص 2 -- مفتاح أساسي
ItemName نص
ItemCost رقم
إحفظ الجدول بإسم Items
أضف السجلات التالية في جدول الأصناف Items :
90 محاية 2
91 مسطرة 4
92 قلم رصاص 1
93 منقلة 2
94 قلم حبر 15
95 سبورة 45
96 آلة حاسبة 20
97 براية 1
98 شنطة 70
99 دفتر 3
قرر بعض الآباء شراء بعض الأصناف المدرسية لأطفالهم (بغض النظر عن المنطق) أي آمل ألا يقول أحد أن طفلا عمره سنة واحدة قد إشترى منقلة !!!
أين نحن؟؟
نريد أن نسمح لكل أب (عندما يشاء الأب) أن يشتري أية مجموعة من الأصناف السابقة لأطفاله ثم نريد إنشاء إستعلام يقول لنا إجمالي ما دفعه كل أب مقابل الأصناف التي قام بشرائها لأطفاله.
بعد حفظ الجدول Items وإدخال البيانات السابقة، إفتح صفحة العلاقات، ثم إضغط بالزر اليمين للماوس في إي مكان فارغ وقم بإختيار (إظهار جدول) وأضف جدول Items إلى صفحة العلاقات.
في MS SQL إذهب إلى Diagrams وإضغط بالزر الأيمين في مكان فارغ وإختر Add Table ثم أضف Items إلى صفحة العلاقات.
أريد من يقرأ معي أن يحضر فنجانا من القهوة أو الشاي، ويسن قلما من الرصاص ويفتح صفحة بيضاء جديدة في الدفتر ويعصر فكره ويقول لي:
كيـــــــــــــــــــــــــــــــــــف نربط جدول الأصناف Items ؟؟؟؟؟؟؟؟؟؟؟؟؟؟!!!
تعذبوااااااا ،،،،،،،،،،،،،،،،،،،،
تحياتي،،،
بسم الله الرحمن الرحيم
اولاً اسأل الله العلي القدير ان يجعل ذلك في ميزان حسناتك وأن ينفعنا بك انه على ذلك قدير .
ثانياً : مع الاسف انني كل موجود في المنتدى وانتم الان في الصفحه الخامسه ولست ادري اين كانت عيناي لأتخلف عن متابعة هذه الدروس منذ البدايه . ويعلم الله تعالى انه لشيء يؤسف له .
ثالثاً : اقدم اعتذاري الشديد لك اخي العزيز nternetMaster على ماجاء في موضوع الصادر والوارد مع يقيني انني لم اقصد به الاساءه أو التجريح . ولن اسرد اي تبرير لما كان حتى لا اخذ حيز هو ليس لي في الدروس .
مع بالغ شكري لأخي العزيز جدا جدا biskra لتنبيهي الى الدرس .
والسلام عليكم .
ملاحظه
كل املي من الاستاذ nternetMaster ان ترشدني الى الاخطاء في مثال الصادر والوارد حيث انه قد تم العمل عليه منذ مايقارب الشهر واكثر في العمل لدي . ومن الصعب ان اقوم بسحبه الأن لكثرة البيانات التي ادخلت به . ارجو منك عزيزي ان تقدر وضعي هذا ولك مني جزيل الدعاء بالتوفيق .
تم تعديل هذه المشاركة بواسطة alali100 في 9 نوفمبر 2003 في 02:27

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


