Chapter_7_-_Mapping_ER_Model_to_Relational_Model_-_Par1
بسم الله والحمد لله والصلاة والسلام على رسول الله صلى الله عليه وسلم. إن شاء الله اليوم يا شباب هنتكلم عن Chapter 7 أو الفصل السابع من كتاب Fundamentals of Database Systems، والـ Chapter ده بالتحديد بيتكلم عن التحويل أو الـ Conversion between الـ ER model لـ Relational Data Model، أو من الـ ER Schema للـ Relational
الSchema.الحقيقة يا شباب عملية التحويل بسيطة خالص، وهي مجرد خطوات هتمشي فيها، إن شاء الله توصل في الآخر للتحويل اللي يكون بصورة صحيحة وسليمة وبدون أي مشاكل. فلو حبينا نبص على الخطوات، هتلاقي هما تقريباً 7 خطوات، طبعاً إحنا أثناء الشغل ممكن ندمج خطوتين أو تلاتة في بعض.
فأول خطوة تعال بقى نقرأ الخطوة ونحاول ننفذها على المثال اللي في الكتاب. فأول خطوة قالك Mapping of regular entity types.  Mapping of regular entity types معناها تحويل كل Entity كان موجود في الـ ER model لـ Relation في الـ Relational model.
واضح؟ يبقى أنا همسك كل Entity كان موجود عندي في الـ ER، وكمان خلي بالك مش أي Entity بقى الأول هو الراجل قال لك في الأول ابدأ بالـ Regular Entity. الـ Regular Entity هو مين؟ هو الـ Entity اللي هو ليه Key Attribute، إنت تذكر لما كنا بنتكلم على الـ ER Model قلنا إن في Weak Entity. الـ Weak Entity كان مين؟ كان الـ Entity اللي هو ملوش Key Attribute من نفسه صح؟ وكان وجوده مرتبط بوجود Entity آخر زي مثلاً الـ Dependent لما اتكلمنا عليه.
قلنا الـ Dependent ده الـ Attributes بتاعته مفيش فيها حاجة تعتبر Key Attribute، وفي نفس الوقت وجود الـ Dependent مرتبط بوجود الـ Entity الآخر اللي اسمه Employee. فأول خطوة هتعملها إنك أنت هتعمل Mapping للـ Regular Entities يبقى أنت هتبدأ الأول بـ Regular Entity.
طيب، خلينا نشوف الكلام ده أما نيجي نطبقه هيتم إزاي. أول حاجة همسك أول يعني أنا طبعاً هذكرك الأول بالـ ER Model لو نسيته، أدي الـ ER Model اللي كان عندنا، كان عندنا مثلاً الـ Entities اللي هو الـ Employee ده كان Regular، الـ Department ده Regular Entity، الـ Project Regular Entity
الوحيد اللي كان Weak Entity عندنا كان هو مين؟ الـ Dependent صح؟ وطبعاً أنت عارف الـ Weak Entity بيميز بهذا الشكل اللي أنا بعمل له Double Rectangle كده. طيب، خلينا نبدأ، أول حاجة هبدأ بتحويل الـ Employee لـ Relation فهاجي هنا، أدي الـ Employee. واحد يقول لي .
إيه ده؟ إيه الـ First Name والـ Middle Name والـ Last Name دي؟ برافو عليك إنك لاحظت الملحوظة دي. الـ Name هنا لو تذكر كان Composite Attribute صح؟يبقى أدي أول ملحوظة عاوزك تاخد بالك منها. الـ Composite Attribute أما بنيجي نحول الـ Entity لـ Relation مبنكتبش الـ Composite Attribute ده من ضمن الـ Relation، أومال بنعمل إيه؟ لأ، بنحط الـ Simple Attributes اللي مكوناه.
خدت بالك؟ يبقى بدل ما عندي Attribute واحد، لأ، أحط التفاصيل بتاعته كل واحد منها كـ Attribute. وده اللي حصل هنا، الـ Name شلناه وحطينا التفاصيل بتاعته الـ First Name والـ Middle Name والـ Last Name. صح كده؟ طيب، ثم بعد كده كان في الـ SSN والـ SSN ده كان Key Attribute نفس الكلام هنا هنخليه Key Attribute.
وكمل بقى الـ Birthdate والـ Address والـ Sex والـ Salary خلاص، مفيهوش مشكلة. خش بعد كده على مين؟ على الـ Department. الـ Department هنا إيه الـ Attributes الرئيسية اللي كانت فيه؟ فيه الـ Name والـ Number والـ Location. طيب يبقي فيه تلاته Attribute
أدي الـ Name والـ Number والـ Location. الله فين الـ Location؟ برافو عليك. أدي تاني ملاحظة. تاني ملاحظة لو أنا كان عندي Multi-valued Attribute، أما يكون عندي Multi-valued Attribute زي ده كده زي الـ Location، بعمل إيه؟ بخرجه في Relation جديدة. مع الـ Key.
بتاع الـ Entity الرئيسي ده. يعني هنعمل إيه؟ بالراحة كده، بص، أنت كان ده الوضع. يعني الوضع لو تذكر كان كده، أهو، كان كده الوضع صح؟ عملنا إحنا إيه؟ لأ، هنخرج الـ Multi-valued Attribute اللي اسمها Location دي بره
في Relation جديدة مع الـ Key Attribute بتاع الـ Entity الرئيسي. اللي هو كان عندنا الـ DNumber. أهو، هيبقى ده الوضع. خرجوا في Relation جديدة. وبدي الـ Relation الجديدة دي اسم. اسم عادة بنحاول نخليه اسم معبر، يقول يعني إن في ارتباط بين الـ Relation دي والـ Relation دي. فمثلاً هنا في الكتاب الراجل اقترح اللي إحنا نسميه Depart Location.
فأنا هشيل دول خلاص بقى، اللي إحنا عرفنا جم منين، وأحط أدي الـ Relation الجديدة اللي هي اسمها Depart Location، اللي هي عبارة عن مين؟ برافو عليك، الـ DLocation اللي كان أصلاً موجود في الـ Department بس هو عشان Multi-valued Attribute خرجناه بره، مع الـ Key Attribute بتاع الـ Department. واحد يقولي خلي بالك أنت هنا غلطت غلطة. إيه الغلطة؟
هنا الـ Department الـ DName والـ DNumber على الرسمة هنا هما الاتنين Key Attributes. لكن أنت هنا جيت خليت الـ DNumber فقط هو الـ Key Attribute. برافو عليك الملاحظة دي في مكانها بس هي مش غلطة ولا حاجة. هنا من خطوات التحويل، لو أنا عندي الـ Entity فيه أكتر من Key، فبختار منهم Key واحد
ويصبح أو يسمى الـ Primary Key Attribute. يبقى أنا لو عندي أكثر من Key Attributes بختار منهم Key واحد وبسميه هو الـ Primary Key Attribute بتاع الـ Relation. عشان كده هنا كان في DName وفي DNumber فإحنا اخترنا الـ DNumber. ودي برضه ملحوظة تالتة انك تخلي بالك من إيه؟ لو أنا عندي الاتنين Key Attribute.
واحد منهم Data Type بتاعه حروف أو Characters، وواحد Data Type Numerics أو Number أو أرقام. عادة بنفضل إحنا استخدام الـ Number Attribute أو الـ Numeric Attribute بنفضله إن إحنا نستخدمه بعد كده هو الـ Primary Key يبقى احنا عادة بنفضل استخدام الـ Attributes الـ  data type بتاعتها Number .
عن الحروف. ماشي؟ فعشان كده إحنا اخترنا هنا الـ DNumber. على فكرة الكلام ده هتلاقيه متكرر تاني أما نيجي نتكلم على الـ Project. بص الـ Project، الـ Project هنا أهو كان فيه كام Attribute؟ كان فيه الـ Name والـ Number صح؟ هتلاقي هنا اخترنا الـ Project Number فقط يكون هو ال Key Attribute صح كده ويطلق في الحالة دي عليه الـ Primary Key أو المفتاح الرئيسي بالعربي لو حبيت
ماشي الحال؟ ما تنساش بقى توصل الـ DNumber اللي هو في الـ Dept Locations بأصله، اللي هو جاي منين؟ اللي هو جاي من الـ Department Relation.زي ما اتفقنا أدي كده العلاقة دي بتقول إن الـ DNumber ده يا جماعة اللي في الـ Dept Locations أصله أو الـ Reference بتاعه هو الـ DNumber Attribute اللي موجود في الـ Depart.