هل لا يزال مخطط DB طبيعته؟ قاعدة البيانات

Question

لديّ DB-SCHEMA التالية.

ملف, مجموعة و الكتلة تمثل بنية كائن ملف XML.ملف هو الجذر.مجموعة لديه fk ل ملف. الكتلة لديه واحد fk مجموعة والآخر fk ل وحدة.

وحدة مجموعات "مماثلة" كتل من مختلف مجموعات في سياق ملف.

قاعدة البيانات حاليا في 3NF. ومع ذلك أود أن أعرف أي الوحدات تنتمي إلى ملف.id = 1. للقيام بذلك حتى الآن ، لا بد لي من إجراء استعلام ينضم إلى جميع الطاولات الأربعة. لتحسين هذا المخطط ، يمكنني إنشاء علاقة جديدة وحدة n-fk-> 1 ملف. ومع ذلك ، فإن استعلامي ينضم إلى طاولتين فقط على DB-SCHEMA المحسّن. وهنا السؤال: هل هذا DB (مع هذا FK الجديد) لا يزال في 3 NF؟ ماذا تقول النظرية؟

BLOCK  n--FK-->1  GROUP  n--FK-->1  FILE
 n 
 |
 FK    
 |    
 1  
Unit

أو

            +--------+
      +-----|  File  |.....+
      |     +--------+     .
      |                    .
     /|\                  /.\
 +--------+           +--------+
 | Group  |--+     +--|  Unit  |
 +--------+  |     |  +--------+
             |     |
            /|\   /|\
           +---------+
           |  Block  |
           +---------+

Answer 1

من المعلومات المقدمة ، يبدو أن هذا تسلسل هرمي متوازي حقيقي. على هذا الأساس ، أعتقد أن المخطط المعدل المقترح سيظل تطبيع إلى 3NF.

Answer 2

ليس من الواضح كيف يتناسب جدول الوحدة مع المخطط قبل إجراء تغييرات.

من الواضح ، بعد إجراء تغييرات ، كل ما عليك فعله لمعرفة الوحدات التي تنتمي إلى ملف هو الانضمام إلى جداول الملف والوحدة.

نظرًا لأن الجداول موجودة في 3NF عندما يتم تحديد جميع التبعيات الوظيفية بواسطة المفاتيح ، والمفاتيح بأكملها ، ولا شيء سوى المفاتيح (لذا ساعدني CODD) ، عليك أن تنظر إلى مخططك في هذا الضوء.

بالنظر إلى المعلومات المتاحة ، فمن المرجح أن تكون الجداول كلها في 3NF (و BCNF ، و AFAICT في 4NF و 5NF أيضًا).

Answer 3

لا أعتقد أن مخططك "Crows Foot" يدعم التبعيات الأخرى الموضحة في سؤالك. كيف توصلت إلى 1: العديد من العلاقة بين الملف والوحدة؟

هذه هي التبعيات الوظيفية التي تصفها ...

• مجموعة -> ملف
• الكتلة -> مجموعة
• الكتلة -> وحدة

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

• ملف -> ملف آخر-أطراف
• مجموعة -> مجموعة أخرى من مجموعة
• الكتلة -> آخر كتلة attributes
• وحدة -> آخر الوحدة

بناء مجموعة من علاقات 3NF من التبعيات الوظيفية أعلاه يعطي:

• الإلغاء: ((ملف, ، ملف آخر-attributes)
• Grouprelation: (مجموعة, ملف, ، مجموعة أخرى-attributes)
• Unitrelation: (وحدة, ، الوحدة الأخرى-attributes)
• التعاون: ((الكتلة, مجموعة, وحدة, ، attributes كتلة أخرى)

هذا يتوافق إلى حد كبير مع ما وصفته.

تحديد أي وحدة تتعلق الحالات بـ A ملفيتطلب الانضمام إلى الإلغاء إلى Grouprelation على ملف ثم grouprelation إلى حظر الارتباط مجموعة ثم حظر الارتباط على Unitrelation وحدة.

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

• وحدة -> ملف

هذا يبدو أن الشيء الذي أضفته إلى مخطط "Crows Foot". إضافة هذا يقدم تناقض منطقي. يدعم المخطط الأصلي وجود معين وحدة فيما يتعلق بالمتعددة ملف حالات. كما في:

• الإلغاء (F1 ، ...)
• الإلغاء (F2 ، ...)
• Grouprelation (G1 ، F1 ، ...)
• Grouprelation (G2 ، F2 ، ...)
• blockrelation (B1 ، G1 ، U1 ، ...)
• blockrelation (B2 ، G2 ، U1 ، ...)
• Unitrelation (U1 ، ...)

مثيل UNIT U1 يتعلق بملف الحالات F1 و F2. بالنظر إلى هذا الموقف إما وحدة -> ملف لا يمكن دعم التبعية الوظيفية أو أن المجموعة الأصلية من التبعيات الوظيفية غير مكتملة والمخطط ليس في 3NF.

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

• ملف, وحدة -> ولا شيء

والعلاقة المقابلة:

• FileUnit: (ملف, وحدة)

هو إلغاء التمييز بين الطور لأن محتواه قد يتم اشتقاقه من خلال الجداول الحالية التبعية الوظيفية.

=================================================================================

تعديل

بناءً على عدد من التعليقات التي تم إجراؤها على هذا الإجابات وغيرها ، يبدو أن:

• وحدة -> ملف

هو التبعية الوظيفية الحقيقية ، التبعية الوظيفية:

• الكتلة -> وحدة

على الرغم من أنها غير صحيحة ، يجب أن تكون زائدة عن الحاجة. أعتقد أن مجموعة العلاقات 3NF الصحيحة لهذا النموذج الآن هي:

• الإلغاء: ((ملف, ، ملف آخر-attributes)
• Grouprelation: (مجموعة, ملف, ، مجموعة أخرى-attributes)
• Unitrelation: (وحدة, ملف, ، الوحدة الأخرى-attributes)
• التعاون: ((الكتلة, مجموعة, ، attributes كتلة أخرى)

لاحظ أن وحدة لقد انخفض المفتاح الخارجي من الحظر. هذا لأن ال وحدة -> ملف جعلها FD زائدة عن الحاجة. ال (الكتلة, وحدة) يتم تشكيل العلاقة الآن من خلال الانضمام إلى Unitrelation إلى الإلغاء على ملفثم الإلغاء إلى grouprelation على ملف ثم grouprelation إلى حظر الارتباط مجموعة.

لم يكن المخطط الأصلي في 3NF بسبب التبعية الوظيفية غير المعلنة: وحدة -> ملف. مجموعة العلاقات المقترحة أعلاه في 3NF.

ملاحظة: عند تطبيع المخطط ، يجب ذكر كل التبعية الوظيفية في المقدمة. في عداد المفقودين يمكن للمرء تغيير الصورة كاملة!