كيفية تصميم العديد من العلاقات إلى العديد من الأشياء في قاعدة بيانات الكائن؟

Question

اعتقدت أن الوقت قد حان لإلقاء نظرة على قواعد بيانات OO وقررت استخدام DB4O لمشروعي الصغير التالي - مكتبة صغيرة.

النظر في الكائنات التالية: كتاب ، فئة.

يمكن أن يكون الكتاب في فئات 0-N ويمكن تطبيق فئة على كتب 0 م.

فكرتي الأولى هي أن يكون لدي كائن انضمام مثل bookcatecory ، لكن بعد قليل من googling أرى أن هذا غير مناسب لـ "oo oo".

لذا فإن هناك نهجًا آخر (موصى به من قبل الكثيرين) هو الحصول على قائمة في كلا الكائنين: Book.Categories و Catevory.books. جانب واحد يتعامل مع العلاقة: Book.AddCategory يضيف فئة إلى Book.Categories و Book to Category.books. كيفية التعامل مع الالتزامات والتراجع عند تغيير كائنين ضمن استدعاء طريقة واحدة؟

ما رأيك؟ النهج الثاني له مزايا واضحة ، ولكن بالنسبة لي على الأقل ، فإن الأول "يشعر" بشكل صحيح (معيار أفضل).

Answer 1

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

n:n attribute, referencing from the parent
------------------------------------------------------------------
class Person{
List addresses;
}

class Address{
}


n:n attribute, referencing from the child
------------------------------------------------------------------
class Person{
}

class Address{
List persons
}

n:n attribute, bidirectional references
------------------------------------------------------------------
class Person{
List addresses;
}

class Address{
List persons
}

Answer 2

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

سوف تبدو كيانات OO:

BookCategory {
 Book book
 Category category
}
Book {
 Collection <BookCategory> categories
}
Category {
 Collection <BookCategory> categories
}

هنا عليك الحفاظ على كائن العلاقة والمجموعتين في التزامن ؛ ومع ذلك ، فإن المجموعات اختيارية في هذه الحالة. عادةً يمكنك الحصول على نفس المعلومات مع استعلام ORM ، شيء مثل: SELECT B.Book من BookCategory B حيث B.Category = MyCategory

البديل هو الحصول على إعداد مثل:

Book {
 Collection<Category> categories
}

Category {
 Collection<Books> books
}

إذا كانت أداة ORM/DB الخاصة بك تحافظ تلقائيًا على الارتباطات ، فهذا جيد ؛ خلاف ذلك ، أنت عالق في تحديث كلتا المجموعتين. (في السبات ، سيكون لدى أحد الجوانب الخاصية: عكسي = صحيح على التعيين ؛ لم يتم تحديث هذا الجانب ، لذلك لا يحتاج إلى الحفاظ عليه بصراحة. هذا يبدو لي مثل الممارسة السيئة ، على الرغم من ذلك)

إذا كنت عادةً تصل إلى العلاقة بطريقة واحدة فقط (على سبيل المثال ، الحصول على جميع الكتب في فئة) ، يمكنك القضاء على المجموعة على الجانب الآخر ؛ ثم أعتقد أنه سيتعين عليك العمل حول أداة ORM واستخدام استعلام أصلي من أجل الوصول إلى العلاقة من الاتجاه الآخر.

نستخدم Hibernate (أداة رسم خرائط للكائنات القائمة على Java) في مشروعنا ؛ تعتبر مستندات السبات مرجعًا جيدًا لمشاكل التصميم العليا/العلائقية ، على الرغم من أنك قد تضطر إلى قضاء القليل من الوقت في تعلم السبات لجعلها مفيدة:http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#collections-ofvalues

هول!

Answer 3

أعتقد أنك مجرد معلقة قليلاً على طريقة تفكير DB العلائقية. القوائم في كل كائن هو الشيء الصحيح الذي يجب القيام به. الالتزامات والتراجع ليست مشكلة ، فهي تحدث في معاملة ترتكب كل شيء أو تراجع كل شيء.

Answer 4

In a pure OO database such as GemStone the objects themselves have collections of references to other objects. When the object is referenced from the application the OODBMS generates a proxy that wraps the object. The schema for this is just the persisted object and its collection of references to the objects it refers to. The OODBMS does not necessarily need a link entity.

With an O/R mapping layer (assuming it is clever enough to do M:M relationships) the M:M relationship is manifested as a collection of subsidiary references on the object itself which the O/R mapper resolves to the link entity behind the scenes. Not all O/R mappers do this, so you may have a separate link object.

Answer 5

Do you have any particular reason you wanted to use an ODBMS? For simple data structures (such as categorizing books) you generally won't find any advantage in ODBMS over RDBMS, and in fact will have an easier time working in the much-more-standardized world of RDBMS. ODBMS has very tangible advantages when you are working with complex data types or literal persistence/storage of dynamic objects. ODBMS also is cited as being much faster and more scalable than RDBMS, though I can offer little insight into this myself. Here are a couple pages that discuss RDBMS vs. ODBMS, however:

Whatever Happened to Object-Oriented Databases

Object-Oriented Database vs. Object-Rleational Database (SO)

Answer 6

I would avoid data duplication because then you run into all kinds of problems with merging the differences.

the trick to this is references.

the result is that I would have each object contain a collection of references to the other object type as well as having an independent collection of the other objects.

The matching table is a relational concept, unless that intermediary connecting class may have properties that are not attributable to either of the objects. It is there as it enables queries to be written in a powerful manner as it reduces the relation to 2 one to many relations and greatly reduces data duplication. If you did this in a relation database without the matching table then things would get evil very quickly - how would an update operate? Personally i find the attraction of oo databases to be stepping away from this

the way that i would tie all the objects together is via events in code to some kind of transaction handler to allow the caching of objects states. so rather than objects manipulating each others properties they request a change through the handler and await the result in a callback.