#sql #many-to-many #entity-relationship
Вопрос:
Я работаю над университетским проектом для библиотеки, и у меня есть таблица ПОЛЬЗОВАТЕЛЕЙ с РОЛЯМИ столбцов ( возможные значения: участник, библиотекарь, администратор).
Я всегда слышал, что мне не следует использовать отношения «много ко многим». Причина, по которой здесь существует такая взаимосвязь, заключается в том, что у КРЕДИТА есть идентификатор пользователя для заемщика и идентификатор библиотекаря, который работал в то время. (Табличный ЗАЕМ связан с настольной КНИГОЙ другими отношениями, такими как авторы, жанр и т.д. не требуется для этого вопроса)
вопрос
Я не вижу способа или смысла разделять эти отношения на «многие к одному» и «один ко многим». Является ли то, что я делаю, неправильным по какой-то причине?
Редактировать*: Забыл добавить FK в мою диаграмму для Librarian_borrowed, Librarian_returned, но они являются FK. Кроме того, библиотекарь также может взять книгу напрокат.
Спасибо, что уделили мне время.
P.S. Я думал о разделении пользователей таблиц или использовании обобщения, но я не вижу никаких реальных преимуществ, и мне это очень нравится, это облегчает мой проект. Это не мой вопрос, но я уверен, что кто-нибудь может его прокомментировать.
Комментарии:
1. Это хороший вопрос. Это не соотношение «многие ко многим», поскольку один кредит относится только к одному заемщику и одному библиотекарю. Это означает, что вы не должны рисовать здесь линию m:n. Я полагаю, что это будет смоделировано с помощью двух строк, по одной для каждой связи в ERM.
2. Спасибо, это хорошее наблюдение. Я должен сделать это, чтобы прояснить ситуацию.
Ответ №1:
Нет необходимости в отношениях m2m. Вам нужно добавить несколько FK в таблицу ЗАИМСТВОВАНИЯ, по одному для каждой связи с пользовательской таблицей, например, loan_id, librarian_id и т. Д.
Каждый из них будет ссылаться на другую запись пользователя (если, конечно, библиотекарь также не одолжит книгу).
Комментарии:
1. Да, библиотекарь также может одолжить книгу. Как вы думаете, эта конструкция неисправна?
2. Если количество объектов, связанных с кредитом, не является конечным (настраиваемым/динамическим), вы можете использовать таблицу внешних ссылок, такую как LoanUserRelationshipXref, с таблицей отношений. [Пользователь] <== [LoanUserRelationshipXref (идентификатор пользователя, идентификатор кредита, идентификатор отношений)] ==> [Кредит]
3. @GregOgle Итак, у вас есть таблица для определения взаимосвязи со столбцом с, например, возможными значениями («заемщик, librarian_that_loaned, librarian_that_received)? Звучит красиво и чище. Какая от этого будет польза? Я только думаю, что это замедлит чтение и запись.
4. Я думаю, что дизайн в порядке. Один пользователь одалживает книгу, другой одалживает книгу. То, что пользователь заимствования может быть библиотекарем, не имеет значения. Единственная проблема заключается в том, что может быть немного сложно убедиться, что пользователь, предоставляющий кредит, является библиотекарем. Вы могли бы сделать это с помощью дополнительной таблицы библиотекарей, в которой проживают только пользователи, являющиеся библиотекарями. Это сделало бы отношения более ясными. Это дизайнерский выбор, и, на мой взгляд, оба варианта являются правильными подходами.
5. Если вы хотите записать роли, которые может играть пользователь (и, возможно, использовать эту информацию для ограничения возможностей пользователей), то это относится к таблице M:M, но между ПОЛЬЗОВАТЕЛЯМИ и новой ТАБЛИЦЕЙ РОЛЕЙ