Моделирование отношений сущностей: как реализовать «роли» сущностей?

Question

Недавно я немного прочитал о моделировании данных и у меня возник вопрос о ролях, которые может играть сущность.

Рассмотрим простой случай, когда у вас есть Компания, и Компания может быть Поставщиком, Клиентом, Дистрибьютором и т. Д. Или комбинацией этих ролей. Таким образом, компания X может быть как Поставщиком, так и Заказчиком.

На уровне данных у вас может быть таблица для CompanyS, а затем таблицы для SupplierS, CustomerS и т. Д., Которые ссылаются на таблицу Company. По крайней мере, я думаю, что так можно представить.

Хорошо, значит, где-то на земле приложений у вас есть классы для CustomerS и SupplierS и так далее. Каждый из них будет состоять из компании, и тогда все, что будет особенного в этом конкретном классе.

Это все нормально и имеет смысл для меня, пока мы работаем только с одним классом сущностей одновременно. Что если мы хотим начать с компании и посмотреть, какую роль она играет? Поэтому в приложении я мог бы открыть Компанию и увидеть, что это Поставщик и Дистрибьютор.

Теперь я могу придумать несколько разных способов сделать это, но я чувствую, что, поскольку эта проблемная область настолько стара, что должны существовать некоторые проверенные и истинные шаблоны для моделирования этих концепций.

Таким образом, я ищу здесь общие стратегии или шаблоны для моделирования ролей сущностей на уровне приложений. Будем весьма благодарны за конкретные справочные материалы по этой конкретной теме (будь то блоги, книги или что-то в этом роде).

Answer 1

Большинство СУБД не подходят для этой проблемы, поскольку им не хватает необходимой гибкости. Наверное, поэтому Чарльз Бахман предложил расширение сетевой модели данных CODASYL еще в 1977 году, добавив концепцию роли (см. Также Ролевая модель данных пересмотрена ( PDF )). Тем не менее, ИМХО Бахман был все еще слишком под влиянием Иерархической модели данных , думая в терминах наборов отношений владелец / член.

Концептуально рассматриваемая проблема соответствует графу / сети. Если вы моделируете объекты как узлы, ребра (отношения) будут иметь метки для обозначения ролей. Например, объект «Заказ» будет иметь отношение «заказано», связанное с каким-либо другим объектом, которым может быть Лицо, Компания или что-то еще. Когда вы придерживаетесь отношения «упорядочено по», вы знаете, что целевой узел представляет сущность, реализующую интерфейс Orderer.

В математическом жаргоне здесь нужен помеченный направленный мультиграф. Вы обнаружите, что как в родных графовых базах данных, например, Neo4j (проект с открытым исходным кодом, в котором я участвую), так и в RDF . Есть также реализации RDF поверх RDBMS s. Может быть, концепция графика также может дать вам несколько советов о том, как реализовать это с нуля. Я также кратко обсуждаю концепцию роли в своем блоге Гибкость в моделировании данных .

Answer 2

Я бы рекомендовал использовать наследование только в крайнем случае. Отношения, подобные этой, не являются прямыми и легко запутывают дизайн с помощью формы ранней оптимизации. Когда Компания может быть как Поставщиком, так и / или Дистрибьютором, вы не хотите создавать Компанию с атрибутами поставщика или дистрибьютора. Вместо этого думайте об этом, как если бы вы нормализовали базу данных. У вас есть набор понятий следующим образом

• Компании (CompanyID, имя, attrib1, attrib2)
• Поставщики , которые являются компаниями (SupplierID, CompanyID [внешний ключ], attrib1, attrib2)
• Дистрибьюторы (DistributorID, CompanyID, attrib1, attrib2), которые также являются компаниями
• VendorRelationship (RelationshipID, SupplierID, DistributorID, attrib1, attrib2), если вам необходимо отслеживать детали о связи между поставщиком и дистрибьютором

Это удерживает связь между Компанией, Поставщиком и Дистрибьютором на низком уровне.

Другой пример этого - когда у класса есть состояние. Много раз концептуальная модель использует наследование, чтобы показать, как класс является экземпляром класса, у которого есть полиморфные дочерние элементы для обработки различных возможных состояний. Это вызывает проблемы, когда вам нужно изменить состояние экземпляра, и вы понимаете, что ваши указатели будут признаны недействительными и / или затронутые экземпляры могут быть клонированы или иным образом внутри коллекций, что будет сложно или будет постоянно обновляться. потому что вам нужно создать новый экземпляр другого класса, а затем заменить указатель на целевую компанию, что может быть сложно, если имеется много копий или если экземпляры содержатся в контейнере или списке. Более простое и понятное решение состоит в том, чтобы класс содержал элемент типа BaseClass, который имеет возможные состояния в качестве дочерних классов. Таким образом, когда вы хотите изменить состояние объекта nobject, его можно обработать простой заменой атрибута состояния на обновленный конкретный тип.

Answer 3

Возможно, вы захотите проверить дизайн базы данных, используя Object Role Modeling . Он в основном использует выражения того типа, который вы используете в своем вопросе, утверждая роли, которые объекты (сущности) играют по отношению друг к другу. Помимо других возможностей, он может генерировать полный дизайн реляционной базы данных.

Вот другая ссылка .

Answer 4

Боюсь, я не могу дать «общий шаблон», как бороться с этой проблемой. Но я также думаю, что паттерна «один-единственный» вообще не существует.

Причина в том, что моделирование как-то "размыто". Я помню довольно похожую проблему моделирования в немецком компьютерном журнале. Это был своего рода конкурс, и они продемонстрировали различные решения, которые они получили. Решения были совершенно разными, но все они так или иначе действовали. Я думаю, что это также зависит от деталей проблемы. Иногда «бережливое» решение прекрасно, а в других случаях необходимо «большое, толстое, грандиозное» решение для удовлетворения потребностей проектов ...

Например, моделирование все еще является творческой задачей со многими свободными параметрами.

Конечно, есть некоторые "мета-паттерны", которые согласованы. Например в книге «Шаблоны дизайна» от знаменитой «Банды четырех», а также многие другие. Но все еще существует много проблем, где не существует согласованного «лучшего» решения.

В вашем случае можно было бы использовать подклассы (это эквивалентно специализации). Можно также сделать «Поставщика» и т. Д. Просто интерфейсом, который может / не может поддерживаться компанией (это можно рассматривать как необязательную специализацию абстрактной сущности). Но также возможно использовать композицию для той же проблемы. Роль может быть объектом (сущностью), который связан компанией (например, с помощью отношения «имеет роль»).