السلام عليكم جميعًا
عدنا لنلقاكم في تكملة دروسنا , عساكم بخير يارب
تكلمنا المرة الأخيرة عن إيجاد Entitiesو cardinality والعلاقة الموجودة وأخذنا هذا المثال:
وقلنا أنه يوجد علاقة بين الزبون والفاتورة وهي علاقة امتلاك, ولإيجاد الـ cardinality(min-max) علينا أن نطرح السؤال التالي :
هل عند تسجيل الزبون يجب أن تكون له فاتورة؟ كانت الإجابة لا يجب أن يكون مسجلًا قبل إنشاء الفاتورة وبهذا وجدنا (cardinality (0-max
ثم تساءلنا هل يمكن للزبون أن يقوم بالشراء عدة مرات واستلام عدة فواتير؟ فكان من البديهي الجواب بنعم فوجدنا العلاقة (min=0,max=n)
ماذا لو غيرنا cardinality وأخذناها بالشكل التالي (1-0) ؟
تفسيرها أن كل زبون له الحق في الشراء والحصول على الفاتورة مرة واحدة فقط حرفيا قاعدين نقول ' اشتري مرة وحدة ومترجعش فضلًا '
طيب ماذا لو غيرناها (min=1,max=n)؟هنا يمكن للزبون الشراء عدة مرات لكن إذا كان زبون أول مرة يشتري من عند المحل بتقوله ' هات الفاتورة الأول'
طيب هو لسا مشتراش بيقولك بجيب الفاتورة من وين؟ بتقولوا لا جيبها
وفي النهاية لن يستطيع لا التسجيل ولا الشراء .بالنسبة للفاتورة دعونا نغير العلاقة ل (1-0)
هنا نحن نسمح بتواجد فاتورة لكن لا نعرف لمن هذه الفاتورة وهذا غير منطقي البتة, لأن الفاتورة يجب أن يكون وجودها غير مستقل بل يتعلق بالزبون .
أضفت توضيح وشرح الجدوال فقط لكي يكون لكم فكرة وتصور أن كل Entity ستتحول فيما بعد إلى جدول في مرحلة IDM ولكن سنكمل بالتعامل مع entities فقط .
والآن ماذا يمكن أن تحتوي الفاتورة معلومات الشراء صحيح؟ شراء ماذا؟ المنتجات, إذًا يمكن إيجاد علاقة بين المنتجات والفاتورة هي الاحتواء الفاتورة تحتوي على مواد وتعودنا على طرح السؤال:
بالنسبة للمنتج:
حقيقة لم أقتنع ما دام يوجد علاقة بين client و product لماذا لم نجعل بينها علاقة شراء بهذا الشكل:
ــ بحيث أن الزبون يمكنه شراء العديد من المنتجات
ــ والمنتج يمكن أن يشتريه العديد من الأشخاص
سؤال جيد
طيب في كل علاقة يجب أن أسأل ماذا استفدت من هذه العلاقة وماذا يمكن الاستنتاج منها؟
إذا كنا نستنتج من هذه العلاقة شيء جديد يجب إضافتها عدا ذلك يجب التخلي عنها
علاقة 'يشتري 'يمكن الاستنتاج منها المنتجات التي اشتراها كل شخص صحيح؟ نعم أظن أن هذا ما أراد السائل معرفته
طيب هل يمكننا أن نستنتجها من المعلومات السابقة, إذا كنا نعرف رقم الفاتورة ماذا يمكننا أن نستنتج منها؟
بطبيعة الحال المنتجات وماذا كذلك يمكننا أن نعرف لمن تنتمي, فبالتالي يمكننا معرفة الزبون من خلالها لأن الفاتورة علاقتها بالزبون (1-1), فإذا كانت الفاتورة y و الزبون x علاقتهما y —> x, إذًا علينا التخلص من العلاقة يشتري
-قارورة المياة 2
-شيبس 5
-شكولاطة 2
هذه الكمية تعتبر attribute صحيح لكن أين يمكننا وضعها؟ هل هي تخص المنتج؟ أم تخص الفاتورة؟
إذا طرحنا السؤال كم يوجد من قطعة شكولاطة ماركة x في المحل هنا نحن نتكلم عن stock الموجود داخل product , لكن نحن بحاجة معرفة عدد المنتجات داخل الفاتورة , إذًا هذه المعلومة مرتبطة بالفاتورة والمنتج معًا إذًا يجب وضعها داخل العلاقة
السعر الموجود داخل product يعبر عن سعر الشراء هو سعر ثابت أما سعر البيع فهو يتغير مهلًا أين معلومة سعر البيع؟ يجب أن نقوم بإضافتها لكن أين؟
هي تخص البيع والمنتج معًا, إذًا يجب وضعها داخل العلاقة.
1. أريد معرفة الربح الناتج عن بيع كل منتج أين يمكن أن أضع هذه المعلومة؟
الجواب : أي معلومة يمكن حسابها ( استنتاجها ) لا نقوم بتسجيلها فالربح يمكن أن يحسب بـ (سعر الشراء - سعر البيع)
2. أي معلومة تتغير كثير عبر الزمن كالعمر لا نقوم بتسجيله بل نقوم بالاحتفاظ بتاريخ الميلاد ومجرد عملية حساب بسيطة يمكننا استنتاج العمر.
3. يُمنع منعًا باتًا تكرار attributes بين Entities أو تكرار Entities
دُمتم بخير
التعديل الأخير بواسطة المشرف:
