连接用户、项目和数据集表的 ERD 图和 SQL 关系

发布于 2024-09-29 13:19:38 字数 625 浏览 3 评论 0原文

我的 ERD 中有几个表,我想以关系方式将它们组合起来。

我有几个用例,但我完全不知道表之间要使用什么样的关系。

  • 每个用户都可以处理多个项目。
  • 每个用户在每个项目中都有一个特定的角色(经理、贡献者、用户)
  • 每个项目都有多个数据集(“项目”中的 currDataXXX 列),需要链接到表数据。
  • 该应用程序将跟踪用户添加的数据集。因此我假设我也需要表“用户”和“数据”之间的关系?

我在表“角色”中使用了带有 2 个 PK 的桥接模型,将用户和项目链接在一起,并同时为该用户和项目定义角色(这是正确的方法吗?)。

有人可以帮我帮助表之间的正确关系吗?并可能建议表(或当然是整个表)的列(缺少)。

有点忽视了这一点。

谨致问候,

B.

修订后的 ERD: 替代文本 (原图:http://i55.tinypic.com/2mq2ejs.jpg

I have several tables in my ERD which which I would like to combine in a relational manner.

I have several use cases, but I completely lost track of what kind of relations to use between the tables.

  • Every user can work on multiple projects.
  • Every user has one specific role per project (Manager, Contributor, User)
  • Every project has multiple datasets (currDataXXX columns in 'projects') which need to be linked to the table data.
  • The application will keep track of datasets that have been added by users. Thus I assume I need a relation between tables 'users' and 'data' too?

I used a bridge model in table 'roles' with 2 PK's to link the users and projects together and defining a role for that user and project at the same time (is this the correct way?).

Could somebody please help me assist the correct relations between the tables? and maybe suggest columns (which are missing) for tables (or tables as a whole of course).

Kind of lost sight of this.

With kind regards,

B.

REVISED ERD:
alt text
(Original image: http://i55.tinypic.com/2mq2ejs.jpg)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

追风人 2024-10-06 13:19:38

每个项目都有多个数据集(“projects”中的 currDataXXX 列)

这意味着项目与数据集之间存在一对多关系。因此,项目 ID 应是数据集表上的外键,而 currDataXX 列应从项目表中删除。 (当前的设计代表了一种非规范化。)

完成此操作后,项目和用户之间现在有两种多对多关系 - 一种具有角色的链接实体,另一种具有数据集的链接实体。这种关系通常是多余的 - 在这种情况下,我假设 a) 只有在项目中具有角色的用户才能添加数据集,b) 单个用户可以为单个项目添加多个数据集。

如果这两个假设都是正确的,那么从角色到数据集实际上存在一对多关系,因此角色 ID 应该是数据集表上的外键,而用户和项目 ID 在数据集表上变得冗余,并且可以删除。像这样:

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

[如果假设 b) 不正确,则角色和数据集可以组合成一个表,而如果假设 a) 不正确,则角色和数据集仍然是两个不同的链接实体,彼此无关。]

编辑 - 更新提议结构,遵循 Rhizosis 的编辑:

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

Every project has multiple datasets (currDataXXX columns in 'projects')

This means that there is a one-to-many relationship from project to dataset. As such, the project ID should be a foreign key on the dataset table, while the currDataXX columns should be removed from the project table. (The current design represents a denormalisation.)

Having done this, you now have two many-to-many relationships between project and user - one with a link entity of roles, and one with a link entity of dataset. Such relationships are normally redundant - in this case, I would assume that a) only users with a role on a project can add datasets, and b) that a single user can add many datasets for a single project.

If both of these assumptions are correct, then there is actually a one to many relationship from role to dataset, and therefore the role ID should be a foreign key on the dataset table, while the user and project IDs become redundant on the dataset table and can be removed. Like this:

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

[If assumption b) is incorrect, then role and dataset can be combined into a single table, while if assumption a) is incorrect then role and dataset remain two distinct linking entities, unrelated to each other.]

EDIT - updated proposed structure, following Rhizosis' edits:

                +----------+
                |   Role   |
                +----+-----+
                     |
                    /|\
+----------+    +----------+    +----------+
|   User   +---<|  Users/  |>---+  Project |
|          |    | Projects |    |          |
+----------+    +----+-----+    +----------+
                     |
                    /|\
                +----------+
                |  Dataset |
                +----------+
陌伤ぢ 2024-10-06 13:19:38

每个用户都可以处理多个项目。

这是一种多对多关系,因此必须使用中间表,就像使用用户 ID 和项目一样。

每个用户在每个项目中都有一个特定角色(经理、贡献者、用户)

您应该在上述表中添加第三个字段,并将其命名为“RoleID”,并创建另一个名为“Roles”的表,其中包含两个字段“ RoleID”和“角色”

Every user can work on multiple projects.

This is a many-to-many relationship, so it has to be with a middle table as you've done with the ID of the user and the project.

Every user has one specific role per project (Manager, Contributor, User)

You should add third field in this table mentioned above and call it "RoleID" and have another table called "Roles" containing two fields "RoleID" and "Role"

潇烟暮雨 2024-10-06 13:19:38

您不需要设计表格然后计算出关系 - 它们应该同时发展。

特别是当您使用不需要外键声明的数据库时,我建议使用严格的命名约定。尽管您似乎正在对已显示关系的表执行此操作,但其余字段名称似乎有些偶然。

但是,如果没有看到所有分析(并且知道它是正确的),任何人都不可能真正告诉您应该如何连接表,也不可能告诉您可能缺少什么

You don't design your tables then work out the relationships - they should both evolve at the same time.

Particularly when you're using a database that does not require foreign-key declarations, I'd recommend using a strict naming convention. Although you seem to be doing that for the tables you've shown relationships for, the remainder of the field names seem somewhat hap-hazard.

But without seeing all the analysis (and knowing it is correct) its not really possible for anyone to tell you how the tables should be joined, nor what may be missing

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文