الرئيسية
أحدث الصور
بسم الله الرحمن الرحيم
أوراكل : هي قواعد بيانات غرضية علائقية object-relational إن قواعد البيانات العلائقية هي طريقة سهلة جداً للتفكير بالبيانات المستخدمة في عمل ما و إدارتها .وهي ليست أكثر من جداول بيانات .
مثال على هذه الجداول تقارير الطقس و مخططات المخزون و نتائج المباريات الرياضية
هي كلها جداول لها أسماء أعمدة ولها أسطر من المعلومات معروضة بشكل بسيط و مع هذا ممكن أن تكون غنية وفعالة من أجل الأعمال الأكثر تعقيداً وهي تدعم كافة خصائص قواعد البيانات العلائقية مع دعم مفاهيم وخصائص التوجه الغرضي.
الهدف من أوراكل :
أولاً إحداث تعاون بين مطور البرنامج والمستثمر
ثانياً طريقة بسيطة لتفهيم المستخدم أو المستثمر كيفية التعامل مع الجداول
هناك بعض العادات التصميمية الصعبة أو حتى غير الضرورية التي تساعدك أوراكل على التخلص منها
اوراكل تفيد في إعفاء المبرمجين من أعباء العمل الذي قليلاً ما يجدونه مجدياً وهو كتابة التقارير الجديدة ففي المؤسسات الضخمة يكون 95% من الأعمال التي لم يتم القيام بها هي كتابة التقارير و هذا ما مكن أن تقوم بالأمر خلال دقائق باستخدام إمكانيات أوراكل
تصميم قاعدة المعطيات:
لتصميم قاعدة عن مؤسسة يجب أن يتوفر لدي معلومات عنها و بالتالي أحتاج إلى أفراد مختصين بالمجال والذين يشكلون اتصال بين المصمم والمؤسسة.
و لدي ثلاث مراحل لتصميم قاعدة المعطيات
تكون كما في الشكل
أولاً التحليل الوظيفي :
نأخذ المعلومات من المؤسسة وننمذجها على شكل وظائف أي نحلل المعطيات تحليل وظيفي بحيث أحدد ما هي الوظائف وما هي المعطيات التي ستتم عليها الوظائف و خرج هذه المرحلة هو عبارة عن كامل المعطيات وقواعد العمل .
المعطيات وقواعد العمل هي دخل الdata analysis والتي لها عدة مستويات و هنا ما زلنا بمستوى مجرد ليس له علاقة بالتنفيذ أو التنجيز.
إذا التحليل الوظيفي تفحص المسألة التي ستنمذج و تصنف مكوناتها بحسب كيانات خارجية وعمليات و معطيات تمثل هذه المكونات بواسطة مخطط تدفق المعطيات .
الكيان الخارجي : هو يزود دخلاً أو يستقبل معلومة في العملية وتمثل بمستطيل .
تخزين المعطيات : وهي المكان الذي يخزن فيه المعطيات و تمثل بمستطيل.
العمليات : تقوم بمعالجة المعطيات وتمثل بشكل بيضوي .
تدفق المعطيات: تمثل المعطيات التي تذهب أو تأتي من كيان خارجي أو مخزن معطيات وهي التي تحدد مسار المعطيات .
سنحصل على مخطط تدفق المعطيات و الذي منه ننطلق إلى عملية التصميم و خرج هذا المخطط هو قائمة معطيات و قواعد عمل اللذين هما دخل الdata analysis ومنها أجري عملية التصميم.
الشكل التالي هو مخطط تدفق معطيات لشركة سياحية
لاحظ أنه ربما يحجز المسافر في أكثر من رحلة بنفس الوقت و أنه ربما يدفع ثمن التذاكر بالتقسيط وربما تتضمن الرحلة الواحدة أكثر من مدينه
نستطيع أن نحصل من هذا المخطط على قواعد العمل وعلى معطيات على هذا الشكل
تحليل المعطيات دخلها هو data وقواعد العمل و خرجها هو data model أي نموذج المعطيات
تحليل المعطيات يتضمن:
المستوى المفاهيمي أنجز فيه المسألة بشكل منفصل تماماً عن تفاصيل التنجيز والأداء فقط أتعامل مع المعطيات و استخدم أحد طرق النمذجة.
E.A.R Entity Attribute Relationship
Entity تعني كيان أو جدول
Attribute تعني صفة أو اسم عمود
Relationship العلاقات التي تربط بين الجداول
نمثل الجدول أوEntity بمستطيل
نمثل مسألة المسافر بالنموذج التالي
لاحظ أنني لا أستخدم القيم بالنموذج يعني لا أدخل قيمة الصفة أوقيمة اسم العمود وذلك لأنها متغيرة مثلاً الاسم ###### لا أدخلهم ولكن أدخل الصفة والتي هي هنا الاسم
الآن لنشرح تمثيل العلاقات بين الجداول لاحظ السهم والدائرة والخط
1-لاحظ أن المسافر ربما يحمل جواز سفر وربما لا لذلك أضع دائرة صغيرة على طرف جدول جواز السفر وهي تعني قد يملك أو لا يملك
و إن جواز السفر هو لمسافر واحد فقط لذلك أضع خط عمودي صغير
والشكل يوضح علاقة واحد لصفر
2- المسافر بلحظة معينة يخرج برحلة واحدة أي بنفس الوقت لا يحجز أكثر من خط سير لذلك نضع خط صغير عمودي من جهة المسافر و أيضاً فإن المسافر قد لا يخرج لرحلة
أو قد يخرج لرحلة واحدة أو أكثر لذلك وضعنا إشارة سهم صغير تدل علىواحد أو أكثر وبجانبه دائرة تدل على أنه أيضا ربما لا يخرج في أي رحلة أسميها علاقة
ONE TO MANY وتكون كما في الشكل
3- خط سير الرحلة قد يملك مدينة واحدة أو أكثر لذلك نضع سهم صغير بجانبه خط
أما المدينة الواحدة قد تكون على خط سير رحلة واحدة أو أكثر أو قد لا تكون على خط الرحلة والعلاقة بين الجدولين CITY , ITINERARY هو علاقة
MANY TO MANY
إذاً هنا مثلت المعطيات بكيانات ووضعت العلاقات بينها وهي دخل للتصميم المنطقي
LOGICAL DESIGN:
الدخل هوCONCEPTUAL DATA MODEL وتطرأ عليه التعديلات وتطبق عليه قواعد والناتج هو LOGICAL DATA MODEL.
يتضمن هذا التصميم مرحلتين
المرحلة الأولى تشذيب الصفات :
ونعني بها أنه ضمن الجدول قد يكون هناك صفات أو أسماء أعمدة مختلفة ولكن لها نفس المعنى عندها يتم الاحتفاظ بواحدة منها وتلغى البقية
في الجدول CLIENT لدي الصفتين PAYMENT A/C و
A/C-CODE لهما نفس المعنى عندها أشطب وا حدة و أترك الأخرى
لذلك ما رأيكم أن نشطب PAYMENT A/C
وقد يكون لدي صفات لها نفس الاسم ولكن ليس لها نفس المضمون عند ذلك أغير
اسم أحدهما بحيث لا يحدث تشابه أسماء.
المرحلة الثانية تتضمن 1- تحويل النموذج EAR إلى شكل جداول :
2- وتحويل الصفات إلى أسماء أعمدة في الجداول
ووضع خط تحت كل عمود هو مفتاح أساسي (المفتاح الأساسي أو PK هو العمود الذي يحوي قيم غير مكررة وقيم ليست null كرقم جواز السفر ورقم الهوية وهكذا
إذ لا يتواجد شخصان لهما نفس رقم جواز السفر) وربما يكون المفتاح عمود أو أكثر
يصبح الشكل المفاهيمي بعد تشذيب الصفات وتحويله إلى شكل جداول كما في الشكل
3- وهي حل العلاقات:
عند تحويل العلاقات عندها أحذف الخط الدال على العلاقة ولكن علي أن أترك أثر وذلك عن طريق المفتاح الثانوي FK ويجب ان أحدد أين علي أن أضع الFORIGN KEY
أو المفتاح الثانوي و يجب أن أحدد أين مكان الFK وذلك يتعلق بنوعية العلاقة والأهم أن أحصل على أقل تكرار.
لعلك تسأل و ما هو المفتاح الثانوي الإجابة المفتاح الثانوي لجدول ما هو المفتاح الأساسي للجدول الآخر الذي يرتبط معه أضعه في نهاية هذا الجدول .
كمثال على ذلك
أولاً في حالة الجدولين client و passport أقوم بوضع المفتاح client_no كمفتاح ثانوي في الجدول passport فيصبح الجدول passport كالتالي
لاحظ أن المفتاح الثانوي أضع تحته خط منقط وبذلك أكون قد حللت العلاقة
one to zero بين الجدولين client و passport بوضع المفتاح الرئيسي للجدول client كمفتاح ثانوي للجدول الذي يوجد على طرفه الصفر و لعلك تتساءل لماذا على الطرف الذي فيه الدائرة الجواب
إذا وضعنا المفتاح الأساسي للجدول passport كمفتاح ثانوي في الجدول client
ربما لا يملك المسافر passport عندها هذا الحقل سيصبح null قيمة فارغة ولكن لا يوجد قيمة مكررة وهذا صحيح ولكن إذا وضعت المفتاح client_nu في الجدول passport كمفتاح ثانوي لاحظ أنه لايوجد تكرار ولا يوجد قيم null وهذا هو الحل الصحيح
ثانياً لحل العلاقة ما بين الجدول itinerary و الجدول client وهي علاقة
one to many
أنقل المفتاح الى طرف الmany .
فيصبح الجدول كالتاليitinerary
و يبقى الجدول client على حاله
ولعلك تتساءل لماذا لم أنقل المفتاح itin_nu( رقم الرحلة) إلى نهاية الجدول client السبب هو
أنه في حال نقله سيفقد العمود client_nu خاصية المفتاح لأنه ربما يحجز الشخص نفسه لأكثر من رحلة فهذا يؤدي إلى تكرار رقم المسافر فيفقد خاصية عدم التكرار بالإضافة إلى وجود تكرار في العمود itin_nu لذلك لا ينبغي القيام بهذا النقل
ولكن في حالة نقل العمود client_nu إلى itinerary ليصبح مفتاح ثانوي
ربما يكون نفس المشارك مشترك في عدة رحلات فيحدث عندي تكرار ولكن بنسبة أقل
مما سبق حيث أن الحالة السابقة سيتكرر فيها كل معلومات المسافر وهذا يحجز مساحة أكبر أما هنا يتكرر فقط عمود
ثالثاً:لحل العلاقة many to many بين الجدولين city و itinerary
الحالة أولى:
إذا وضعنا iten_num (رقم الرحلة) في الجدول city وهو fk قد تظهر المدينة في عدة رحلات وبالتالي فإن معلومات المدينة سوف تتكرر وبالتالي city_name لم تعد مفتاح أساسي بالإضافة إلى وجود تكرار بالمعطيات لذا لنجرب الحالة الثانية.
الحالة الثانية:
هي أن أضع city_name في الجدول itinerary (الرحلة) بالتالي الرحلة قد تظهر في بعدة مدن وبالتالي نحصل على نفس المشكلة السابقة أي يفقد العمود iten_nu خاصية المفتاح .
الحل في حالة many to many هو:
أوجد جدول جديد مفتاحه الرئيسي هو المفتاح الرئيسي في كلا الجدولين
ولأسميه itin_cityوممكن أن أضع ضمن هذا الجدول أعمدة لها علاقة بالمفتاحين
أي أن علاقة many to many تكسر وتصبح علاقتين one to many أي تمثل كالتالي
ممكن أن أضع صفات جديدة في الجدول ITIN_CITY تتعلق بالمفتاح الأساس أي ممكن يصبح كالتالي
إذا المدينة لن تتكرر معي ولكن سوف يحدث تكرار في CONTACT_NAME و CONTACT_ADDRESS ولكن هذا الحل يبقى أفضل من السابق
سأعطيك الخلاصة
أولاً: علاقة ONE TO ONE لا فرق في مكان المفتاح الثانوي
ثانياًً: علاقة ONE TO ZERO نضع المفتاح الثانوي الFK لطرف الZERO
ثالثاًً: علاقة ONE TO MANY نضع المفتاح الثانوي الFK لطرف الMANY
رابعاًً: علاقة MANY TO MANY نجري جدول جديد (كيان جديد)ونضع العلاقتين و إذا لم نجد صفات ترتبط بالمفتاحين عندها نكتفي بوضع المفتاحين فقط ضمن الكيان الجديد .
المرحلة التالية من التصميم المنطقي
APPLING THE RULES OF NORMALIZATION
أصبحت الكيانات كالتالي
دعنا نطبق عليها النوع الأول من التوحيد أي يجب أن تملك الصفة قيمة واحدة فقط وعندما يملك حقل ما مجموعة من القيم هذا الجدول لا يملك توحيد .
لا حظ أن الرحلة ممكن أن أدفع ثمنها على عدة مراحل في حقل مبلغ الدفع التي تخص مسافر واحد سوف يحوي عدة قيم إذاً عمود واحد أو عدة أعمدة في سطر واحد تأخذ مجموعة من القيم و أيضاً ربما يملك الشخص الواحد أكثر من حساب لذلك نطبق عليه أول توحيد
لاحظ هنا أن , payment _date, raiment amt, a/c_code , a/c name تأخذ قيم غير وحيدة
لذلك سوف نعزل هذه الصفات كلها بطرف واحد و أضع علاقة بينها وبين الجدول الأساسي هي one to many
نحل علاقة one to many وذلك كما علمنا بوضع المفتاح الثانوي في طرف الmany
فيصبح الجدول كالشكل
لاحظ أن المفتاح الأساسي السابق مع المفتاح للأعمدة المعزولة نشكل مفتاح أساسي للجدول الجديد.
و بذلك نكون حققنا أول شكل توحيد.
النوع الثاني للتوحيد: 1- أول شكل للتوحيد محقق أي لا يوجد قيم مركبة
2- كل الصفات التي ليست مفتاح ترتبط بكامل المفتاح الأساسي وليس بجزء منه
ننظر إلى الجداول السابقة نجد أن الجدول client و الجدول payment والجدول passport يحقق ثاني شكل من أشكال التوحيد.
أما الجدول itin_city ففيه آخر عمودين يتعلقان بcity_name فقط .أي بجزء من المفتاح الرئيسي وبالتالي الجدول الأخير itin_city) ) لا يحقق second normal form
وبالتالي هذا الجدول يجزأ إلى جدولين
الأول هو الجدول التالي
و الجدول الثاني هو
النوع الثالث للتوحيد:
شرطه أن يكون الشرط الثاني محقق و أن الصفات الغير مفتاحية لا ترتبط ببعضها البعض .
لا حظ أن الجداول كلها تحقق الشرط الثالث إلا الجدول payment لا يحقق الشرط الثالث وذلك لأن
لاحظ أن A/C_CODE و A/C_NAME أي رمز الحساب واسم الحساب يرتبطان مع بعضهما البعض فأجزأ الجدول إلى الجدولين التاليين
وبالتالي تصبح الجداول كلها مع بعضها كالتالي
... ..
