ظهور خطأ في نتائج تقرير بطاقة درجات

اخي الفاضل : ابو منتظر

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

تفضل ملفك بعد التعديل

لاحظ الفرز والتجميع على مستوى الأسم في التقرير

بطاقة الدرجات-UP.rar

هناك ملاحظة بارك الله بك

لماذا قمت بوضع كل هذه الحقول في الجدول

لا أعلم لماذا قمت بهذا العمل !!!!!!!!

والسبب انه اذا كثرت البيانات في جدول كهذا فستحتاج الى اسبوع لكي يفتح معك

فتخيل انك وضعت درجات كل الصفوف من الصف الأول ابتدائي الى الصف الثالث ثانوي كل حسب درجاته

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

كان من المفترض انك قمت بتقسيم الجدول الى جداول اصغر مثل :

1. بيانات الطلاب ( تضع هنا كافة بيانات الطالب من اسم ورقم وخلافه

2. جدول الصفوف ( الأول - الثاني - الثالث - الرابع ............................. ) وتربطه مع جدول الطلاب

3. جدول المواد الدراسية وتربطه مع جدول الطلاب والصفوف

فكلما صغرت الكائنات كانت اسهل في فتحها واستخراج ما تريده منها بسهوله

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

عموما احببت ان ارشدك للطريق الصحيح في بناء قواعد البيانات .

بالتوفيق

اشكر استاذتنا الفاضلة على الرد

وفقك الله , وأعطى مرادك في الدنيا و الآخرة

شكرا ً على توجيهاتك القيمة فيما يتعلق بأصول كيفية تصميم قواعد البيانات , فهي عين الصواب

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

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

مشكورة مرة أخرى

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

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

وضعت الكود التالي :

If Isnull (Me.islam1) then
Exit Sub
End if

ابو منتظر

أخي الكريم: أبا منتظر...

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

Dim ctl As Control
    For Each ctl In Me.Controls
        If ctl.Tag = "unbound" Then ctl.Value = Null
    Next ctl

وتجد النتيجة في الملف المرفق.

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

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

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

الخلاصة، أن هذا التصميم لا يوافق المبادئ السليمة، لكن ليس لاعتبارات الأداء أو خوفاً من الانهيار، والله أعلم.

اقتباس

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

عفوا وما هو المفهوم الأولي الذي تكسر نتيجة وضع الاخت زهرة لسبب البطء....؟؟؟

الا تلاحظ انك تبالغ؟؟

اقتباس

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

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

اقتباس

نظرياً، فإن عدد الحقول المسموحة في جدول واحد في الأكسس هو 255 حقلاً، وأنت لم تتجاوز حتى نصف هذا العدد

وعمليا...100..50...30..كم..طب علميا.. منطقيا.. هل هذا عدد حقول جدول مبني بشكل سليم.. حتى لو كانت كلها مفاتيح اجنبية وقيمها ارقاما..

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

اقتباس

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

ارجو ان تدقق في هذا الكلام جيدا.. لدي برنامج لفندق..به العشرات من الجداول المرتبطة من خلال واجهة تطبيق وشاشات منفصلة عن القاعدة.. ولم اواجه ولو لجزء من الثانية بطء والبرنامج يعمل منذ 3 سنوات الان!

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

التقسيم "تجزئة الجداول وتصغيرها" من المفاهيم الاساسية التي قام عليها علم قواعد البيانات.. فكيف بعد كل هذه السنوات ناتي ونقول انها من اسباب البطء..؟

اقتباس

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

بعض المصممين.. !!

تاكد ان المبرمج الذي سيكتب كودا لهكذا مصممين يستحق جائزة نووية!!

يعني ذلك ان جدولا به مثلا50 حقل نبني عليه استعلام ونصمم الجدول عليه سيكون افضل من ربط 3 جداول لتكوين استعلام ويكون اسرع؟؟

فماذا عن دوال التجميع.. الفرز..الاستعلام والبحث والفلترة.. ؟

كل هذه مفاهيم اساسية تحتاج عزيزي الى مراجعتها وليس العكس.

أخي الكريم همام،

في البدء، يسرني ويشرفني أن تشترك معي في نقاش علمي هادف، فشكراً لك جزيلاً على اهتمامك ووقتك.

اقتباس من كلام الأخ همام:

اقتباس

عفوا وما هو المفهوم الأولي الذي تكسر نتيجة وضع الاخت زهرة لسبب البطء....؟؟؟

الا تلاحظ انك تبالغ؟؟

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

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

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

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

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

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

Microsoft TechNet

http://technet.microsoft.com/en-us/library/cc505841.aspx

Databasedev.co.uk

http://www.databasedev.co.uk/normalizing_data.html

اقتباس من كلام الأخ همام

اقتباس

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

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

اقتباس من كلام الأخ همام

اقتباس

وعمليا...100..50...30..كم..طب علميا.. منطقيا.. هل هذا عدد حقول جدول مبني بشكل سليم.. حتى لو كانت كلها مفاتيح اجنبية وقيمها ارقاما..

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

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

اقتباس من كلام الأخ همام:

اقتباس

كل هذه مفاهيم اساسية تحتاج عزيزي الى مراجعتها وليس العكس.

أرجو أخي الكريم أن تكون قد غيرت رأيك الآن. وفي كل الأحوال، فقد سرني مرورك ومشاركتك، أسأل الله أن يفتح علينا جميعاً.

اقتباس

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

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

اقتباس

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

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

اقتباس

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

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

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

هنا اقتبس..

اقتباس

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

Microsoft TechNet

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

الدرس الثالث يقول : Optimizing the Database Design by Denormalizing

You implement normalization with a specific purpose: to maintain data integrity. However, in a real-life project, you typically have to bring back some data redundancy either for performance reasons or to maintain a history.

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

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

هنا كلام مهم جدا.. لا يختلف ابدا عما قلته بخصوص الاداء ودوال التجميع والبحث وغيرها..

اقتباس

When you denormalize a database, you can encounter problems with data consistency, especially with aggregated data, which must be updated for any single event.

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

اذا المسالة واضحة..

اخي العزيز..

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

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

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

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

مرة اخرى

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

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

وتاكد ان ذلك مصلحة للجميع

أحمد مبارك الحيقي كتب:

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

اخي الفاضل احمد

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

بارك الله بك على هذا الطرح الهادف

و كلام جميل وجيد وهذا هو مفهوم التسويه Normalization ويجب ان يلتزم به مصمم قاعدة البيانات .

أحمد مبارك الحيقي كتب:

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

نعم اخي احمد يتم ازالة التسويه Non-normalized في حالة اننا نريد الحصول على زيادة الأداء في السرعه

ولكن هذا الكسر او ازالة التسويه له شروط ومعايير :

1. ان تكون قاعدة البيانات للقراءة فقط .

2. ان يتم منع المستخدمين للدخول عليها والسبب ( انه لو تم حذف صف واحد من هذه البيانات فستصبح مشكله )

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

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

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

أحمد مبارك الحيقي كتب:

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

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

س : لو طلب منك مثلا مدير مدرسه ما او دعنا نقرب الأشخاص وهو طلب احد أعضاء المنتدى منك ان تقوم مشكورا بعمل قاعدة بيانات لمدرسه وهذه المدرسه بها :

1. طلاب ..... عددهم حوالي 1000 طالب ( كل طالب له بياناته الخاصه )

2. صفوف ...... من أول ابتدائي الى ثالث ثانوي

3. فصول تابعة للصفوف ..... أ - ب - ج - د - ح - .... الخ

4. مواد دراسية مختلفه لكل مرحله من المراحل

فأي الطريقتين تستخدم مع قاعدة البيانات أكسيس ؟ :

* . طريقة الجداول المترابطه ( طلاب - صفوف - فصول - مواد دراسية )

*. طريقة وضع كل هذه الحقول في جدول واحد حتى لو وصل عدد الحقول في هذا الجدول الى 255 حقل .

مع خالص الشكر والتقدير

اقتباس

*. طريقة وضع كل هذه الحقول في جدول واحد حتى لو وصل عدد الحقول في هذا الجدول الى 255 حقل .

حسب كلامك السابق اخي احمد قاعدة بيانات بالطريقة الثانية ستصمد اكثر من 7 سنوات! فهل هذا معقول؟.. وبما انك قلت انك تخجل من تصميمها

اقتباس

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

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

تحياتي