التعامل مع "hypernormalized" البيانات

Question

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

الجديد المورد البيانات هو أفضل بكثير من القديم ، ولكن البيانات الخاصة بهم هو ما يمكن أن أسميه hypernormalized.ومنها على سبيل المثال فئة المنتج هيكل لديه 5 مستويات:ماجستير إدارة, إدارة الصف, فرعية, كتلة المنتج.وبالإضافة إلى ذلك المنتج كتلة المحتوى وصف طويل, مصطلحات البحث و صورة أسماء المنتجات (الفكرة هي أن المنتج يحتوي على كتلة منتج و كل الاختلافات - على سبيل المثال ، معين القلم قد يأتي باللون الأسود أو الأزرق أو الأحمر الحبر.كل هذه العناصر هي أساسا نفس الشيء ، بحيث تنطبق على منتج واحد كتلة).في البيانات لقد أعطيت هذا هو التعبير عن المنتجات الجدول (أقول "الجدول" لكنه شقة الملف مع البيانات) وجود إشارة إلى كتلة المنتج معرف فريد.

أنا أحاول أن تأتي قوية مخطط لاستيعاب البيانات أنا قدمت مع, منذ أن كنت سوف تحتاج إلى تحميل ذلك في وقت قريب نسبيا ، البيانات التي أعطيت لي لا يبدو أن تطابق نوع البيانات التي توفر مظاهرة على عينة موقع (http://www.iteminfo.com).في أي حال, أنا لا أبحث عن لإعادة عرض هيكل لذا فهو نقطة خلافية, ولكن كنت تصفح الموقع للحصول على بعض الأفكار حول كيفية بنية الأشياء.

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

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

كيف يمكنك معالجة مثل هذا الوضع ؟ نضع في اعتبارنا أن لدي البيانات التي يتم تحميلها بالفعل في شقة الملفات التي تحاكي بنية الجدول (لدي وثائق تقول أي الأعمدة التي وماذا المراجع يتم إعداد);أنا أحاول أن تقرر إذا كان يجب الاستمرار عليها كما تطبيع كما أنها حاليا ، أو إذا كان ينبغي أن ننظر إلى توطيد;أنا بحاجة إلى أن يكون على بينة من كيفية استخدام كل طريقة سوف يؤثر على طريقة برمجة الموقع باستخدام القضبان منذ اذا فعلت توحيد سيكون هناك أساسا 4 "مستويات" من الفئات في جدول واحد ، ولكن هذا بالتأكيد يبدو أكثر سهولة من جداول منفصلة لكل مستوى منذ وبصرف النظر عن الفئة الفرعية (الذي يربط مباشرة إلى المنتج كتل) لا هل أي شيء ما عدا تظهر المستوى التالي من الفئة تحت لهم.أنا دائما خسارة "أفضل" طريقة للتعامل مع البيانات مثل هذا - أعلم قائلا "تطبيع حتى انه لامر مؤلم ، ثم denormalize حتى يعمل" ولكن لم يسبق لي أن تنفذ ذلك حتى الآن.

Answer 1

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

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

Answer 2

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

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

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

Answer 3

إذا فهمت بشكل صحيح, أنت تريد أن تأخذ جداول منفصلة وتحويلها إلى التسلسل الهرمي الذي احتفظ في جدول واحد مع الذات الرجوع FK.

هذا هو عموما أكثر مرونة النهج (على سبيل المثال ، إذا كنت ترغب في إضافة المستوى الخامس) ، ولكن SQL وقواعد البيانات العلائقية نماذج لا تميل إلى العمل مع القوائم المرتبطة مثل هذا ، حتى مع جملة جديدة مثل MS SQL Servers CTEs.باعتراف الجميع ، CTEs جعله أفضل بكثير على الرغم من.

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

إذا قررت أن تفعل ذلك بهذه الطريقة, ثم بالتأكيد تحقق من جو Celko هو SQL على Smarties, الذي أعتقد أنه قسم أو اثنين على النمذجة والعمل مع التسلسلات الهرمية في SQL أو أفضل بعد الحصول على الكتاب الذي خصص هذا الموضوع (جو Celko أشجار الهرمية في SQL على Smarties).

Answer 4

Normalization يعني سلامة البيانات ، وهذا هو:كل شكل طبيعي يقلل من عدد من الحالات التي تكون فيها البيانات غير متناسقة.

وكقاعدة عامة ، denormalization لديه هدف من أسرع querying, ولكن يؤدي إلى زيادة مساحة زيادة DML الوقت, و, أخيرا وليس آخرا, زيادة الجهود الرامية إلى جعل البيانات متسقة.

واحد يكتب عادة رمز أسرع (يكتب أسرع ، وليس رمز أسرع) و الكود هو أقل عرضة للأخطاء إذا كانت البيانات normalized.

Answer 5

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

Answer 6

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

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

Answer 7

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

في الوضع الخاص بك, كنت ترغب في معرفة ما تطبيع مخطط ترغب.يمكنك القاعدة إلى حد كبير على مصدر المخطط ، ولكن عليك أن تعلم ما الاعتمادية الوظيفية (FD) في البيانات.لا مصدر مخطط ولا بالارض الملفات مضمونة تكشف كل FDs لك.

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

قلت السابقة المخططات في الشركة تكلف الملايين بسبب التناقض و عدم الدقة.المزيد من تطبيع المخطط ، أكثر حماية من التناقض الداخلي.هذا يترك لك الحرية في أن تكون أكثر يقظة حول دقة.يتفق البيانات باستمرار الخطأ يمكن أن تكون مضللة بيانات غير متناسقة.

Answer 8

هو الواجهة الخاصة بك (أو أيا كان ما لم يكن واضحا تماما على ذلك) دائما ما يكون باستخدام بيانات من هذا المورد ؟ قد كنت من أي وقت مضى تغيير الموردين أو إضافة مزيد من مختلف الموردين ؟

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

Answer 9

بالنسبة لي فإن السؤال الحقيقي هو: ما يناسب نموذج أفضل ؟

مثل مقارنة Tuple قائمة.

1. الصفوف هي حجم ثابت و غير متجانسة-فهي "hypernormalized".
2. القوائم هي arbitrarty الحجم متجانسة.

يمكنني استخدام Tuple عندما كنت في حاجة Tuple وقائمة عندما أحتاج إلى القائمة ؛ أنها في الأساس خادم أغراض مختلفة.

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

يمكنني استخدام كلا النهجين في بعض من قاعدة البيانات حسب الحاجة. ومع ذلك ، هناك أيضا "التكاليف الخفية" من نمط تكراري وهو أنه ليس كل ORMs (غير متأكد حول ع) دعما جيدا.العديد من حديث DBs لديها دعم "الانضمام إلى الاقدام" (Oracle), التسلسل الهرمي معرفات (SQL Server) أو غيرها من أنماط متكررة.وثمة نهج آخر هو استخدام مجموعة القائم على التسلسل الهرمي (الذي يعتمد عموما على المشغلات/الصيانة).في أي حال, إذا اسندت المستخدمة لا يدعم الاستعلامات العودية جيدا ، ثم قد يكون هناك الإضافية "التكلفة" من استخدام إلى DB الميزات مباشرة-سواء من حيث دليل الاستعلام/عرض الجيل أو إدارة مثل المشغلات.إذا كنت لا تستخدم غير تقليدي ORM ، أو ببساطة استخدام المنطق فاصل مثل iBatis ، ثم هذه المسألة قد لا تنطبق.

بقدر الأداء على Oracle أو SQL Server (وعلى الأرجح الآخرين) RDBMS ، فإنه ينبغي أن تكون مشابهة جدا بحيث تكون أقل من المخاوف:ولكن تحقق من الحلول المتاحة RDBMS وقابلية المخاوف.

Answer 10

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

Set1 = (Node1 Node2 Node3...)

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

Node1=(Node2 Node3=(Node4 Node5=(Node6) Node7))

والآن كيف يمكننا أن نموذج هذا ؟ دعونا الحصول على كل عقدة أن يكون اثنين من السمات التي تحدد حدود العقد أنه يحتوي على:

عقدة = { Id:الباحث مين:الباحث ماكس:الباحث }

إلى نموذج التسلسل الهرمي لدينا نحن فقط تعيين هذه القيم مين/ماكس وفقا لذلك:

Node1 = { Id = 1, الحد الأدنى = 1, الحد الأقصى = 10 }
Node2 = { Id = 2, الحد الأدنى = 2, Max = 2 }
Node3 = { Id = 3, دقيقة = 3, Max = 9 }
Node4 = { Id = 4, دقيقة = 4, Max = 4 }
Node5 = { Id = 5, دقيقة = 5, الحد الأقصى = 7 }
Node6 = { Id = 6, دقيقة = 6, Max = 6 }
Node7 = { Id = 7, دقيقة = 8, Max = 8 }

الان الاستعلام عن كافة العقد في إطار المجموعة/Node5:

حدد n.* من العقد كما n, العقد s
حيث s.Id = 5 s.مين < ن.مين n.ماكس < s.ماكس

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