Моделирование базы данных

Question

Мой вопрос касается моделирования конкретной ситуации: В моей модели есть таблицы: Пользователь, Офисы и Партнеры. Система имеет разные профили пользователей: пользователи Office (консультанты, директора, помощники), пользователи для партнеров (учреждения, ...), пользователи-администраторы Как лучше всего моделировать отношения между офисными пользователями и партнерами-партнерами, если: - Пользователи уникальны (два пользователя должны иметь одинаковый логин - должно быть только в 1 таблице) - Пользователь офиса связан только с одним офисом - Пользователь-партнер связан только с партнером.

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

Answer 1

Вы не предоставили достаточно определения партнеров и офисов, поэтому эти части модели еще не завершены, но я думаю, что основной вопрос, на который вы задаете вопрос, дан в этой ▶ модели данных ◀ .Насколько я понимаю:

• Пользователь (логин, имя пользователя уникален, и вы не хотите, чтобы это было неясно)
• Пользователи являются исключительно (то есть Х в половинекружок) Офис / Партнер / Администратор
  • , для которого требуется структура Supertype-Subtype.Количество элементов составляет 1 :: 0-1
• Пользователи принадлежат (?) Исключительно к Office или Партнеру.
  
  • Это может быть OfficeType или OfficeTitle.

Если вы определите этот последний элемент немного больше, я смогу завершить модель.

Читатели, не знакомые со Стандартом моделирования реляционных баз данных, могутнайти ▶ IDEF1X примечание ◀ полезно.

Answer 2

Я думаю, что лучшим способом было бы пойти со структурой группы счетов, где вы используете таблицу ассоциации, чтобы определить, кто в какой группе ...

группа

id | Имя

group_assoc

group_id | account_id

Answer 3

Предполагая, что эта модель никогда не изменится, я бы добавил поле пользователям, чтобы определить, где они принадлежат.Вы можете поместить enum с именем user_type с возможными значениями 'office', 'partner' или 'admin'. А затем вы можете поместить в столбцы office_id и partner_id, чтобы при необходимости можно было объединять таблицы.