Диаграмма ERD и отношения SQL, связывающие таблицы пользователя, проекта и набора данных

Question

В моем ERD есть несколько таблиц, которые я хотел бы объединить реляционным образом.

У меня есть несколько вариантов использования, но я полностью потерял счет того, какие отношения использовать между таблицами.

• Каждый пользователь может работать над несколькими проектами.
• Каждый пользователь имеет одну конкретную роль для проекта (руководитель, участник, пользователь)
• Каждый проект имеет несколько наборов данных (столбцы currDataXXX в «проектах»), которые необходимо связать с данными таблицы.
• Приложение будет отслеживать наборы данных, которые были добавлены пользователями. Таким образом, я предполагаю, что мне нужна связь между таблицами 'users' и 'data' тоже?

Я использовал модель моста в «ролях» таблицы с двумя PK, чтобы связать пользователей и проекты вместе и одновременно определить роль для этого пользователя и проекта (это правильный путь?).

Может ли кто-нибудь помочь мне помочь в правильных отношениях между таблицами? и, возможно, предложить столбцы (которые отсутствуют) для таблиц (или таблиц в целом, конечно).

Вид упущенного из виду.

С уважением,

B.

ПЕРЕСМОТРЕННЫЙ ERD: (Исходное изображение: http://i55.tinypic.com/2mq2ejs.jpg)

Answer 1

Вы не разрабатываете свои таблицы, а затем вырабатываете отношения - они должны развиваться одновременно.

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

Но, не видя весь анализ (и зная, что он правильный), никто не сможет сказать вам, как должны быть объединены таблицы, и что может отсутствовать

Answer 2

Каждый проект имеет несколько наборов данных (столбцы currDataXXX в «проектах»)

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

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

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

+----------+    +----------+    +----------+
|   User   +---<|   Role   |>---+  Project |
+----------+    +----+-----+    +----------+
                     |
                    /|\
                +----------+
                |  Dataset |
                +----------+

[Если предположение b) неверно, то роль и набор данных могут быть объединены в одну таблицу, в то время как если предположение а) неверно, то роль и набор данных остаются двумя различными связующими объектами, не связаннымидруг другу.]

РЕДАКТИРОВАТЬ - обновлена ​​предлагаемая структура, после правок Ризоза:

                +----------+
                |   Role   |
                +----+-----+
                     |
                    /|\
+----------+    +----------+    +----------+
|   User   +---<|  Users/  |>---+  Project |
|          |    | Projects |    |          |
+----------+    +----+-----+    +----------+
                     |
                    /|\
                +----------+
                |  Dataset |
                +----------+

Answer 3

Каждый пользователь может работать над несколькими проектами.

Это отношение «многие ко многим», поэтому оно должно быть со средней таблицей, как вы сделали с IDпользователя и проекта.

Каждый пользователь имеет одну определенную роль для проекта (руководитель, участник, пользователь)

В этой таблице следует добавить третье поле и назвать его «RoleID» ииметь другую таблицу с именем «Roles», содержащую два поля «RoleID» и «Role»