递归关系的基数？
Cardinality of recursive relationship?
我已经为学校计算 (CIS) 创建了一个数据库，我有一些额外的要求要从以下信息中添加。我创建了一个 ERD，但感觉我犯了一些错误，例如递归关系的基数？
任何其他反馈将不胜感激。
新要求
CiS 希望使用该数据库通过网站在线共享会议、参与者等的详细信息。任何相关人员——学生志愿者、学校工作人员、SHU 讲师——都可以使用用户名（或电子邮件地址）和密码登录。登录后，成员将以不同方式使用该网站（学校工作人员请求会议，SHU 讲师管理会议，学生志愿者查看他们可以参加的活动，确认他们是否有空，然后检查时间是否合适）。
CiS 希望能够通过站点共享资源。资源是在会话中有用或通常对 CiS 用途有用的文件。创建此类文件的成员上传它们，数据库保存 URL、文件标题、描述等详细信息，并跟踪文件作者。
会员可以上传文件，会员可以标记文件，给文件打星，评论。
• 标签 是用户分配给文件的关键字。一个文件可以有多个标签；一旦有人用关键字标记了一个文件，其他人就不需要再用相同的关键字标记同一个文件。
• 星级。任何站点成员都可以对任何文件进行评级，但不能 re-rate 他们已评级的文件。
• 评论没有这样的限制，因为它们最终形成了对每个文件的讨论，所以网站成员可以写很多关于文件的评论。了解每个文件评论的日期、作者和主题将很有帮助。
您的图表不是 ERD。特别是，使用线来表示关系将您限制为二元关系，并且失去了实体关系模型的大部分表达能力。
通过使用 Username 和 Password 的组合作为用户 table 中的主键，您允许不同的用户可以使用相同的 Username使用不同的密码。这是你想要的吗？但是，在 Upload file table 中，您只存储了 Author_username，所以也许您只想将 Username 作为键？你需要在这里保持一致。
你的Uploaded filetable需要分解成很多。目前，它仅支持每个 file/username 一个标签、一个评分和一个评论。目前尚不清楚 Author_username 是指上传文件的用户还是对文件进行标记、评级和评论的用户。顺便说一句，这些东西在你的 table 中链接在一起，防止用户发布比评级更多的标签或评论。 File title 和 File description 可能只依赖于 File URL，如果存储了多个标签、评分或评论，将会重复，从而导致不一致的风险。
编辑：
鉴于您在评论中要求推荐，我建议：
- 使用 Chen 的 ERD 表示法，或者至少是使用形状表示关系并支持三元和更高关系的变体。更好的方法是 Object-Role Modeling.
- 仅使用
Username 作为您的 4 个用户 table 的主键。
将Uploaded file拆分为以下table：
Uploaded file (File_URL PK, File_title, File_description, Username FK)File_tags (File_URL PK/FK, Tag PK)File_ratings (File_URL PK/FK, Username PK/FK, Rating)File_comments (Comment_ID PK, File_URL FK, Username FK, Comment, Created_at, Reply_to_comment_ID FK)
请注意，这只是为解决我提出的问题而进行的一组最小更改，用于教育目的，不一定是满足您要求的适当解决方案。
我已经为学校计算 (CIS) 创建了一个数据库，我有一些额外的要求要从以下信息中添加。我创建了一个 ERD，但感觉我犯了一些错误，例如递归关系的基数？
任何其他反馈将不胜感激。
新要求 CiS 希望使用该数据库通过网站在线共享会议、参与者等的详细信息。任何相关人员——学生志愿者、学校工作人员、SHU 讲师——都可以使用用户名（或电子邮件地址）和密码登录。登录后，成员将以不同方式使用该网站（学校工作人员请求会议，SHU 讲师管理会议，学生志愿者查看他们可以参加的活动，确认他们是否有空，然后检查时间是否合适）。 CiS 希望能够通过站点共享资源。资源是在会话中有用或通常对 CiS 用途有用的文件。创建此类文件的成员上传它们，数据库保存 URL、文件标题、描述等详细信息，并跟踪文件作者。 会员可以上传文件，会员可以标记文件，给文件打星，评论。
• 标签 是用户分配给文件的关键字。一个文件可以有多个标签；一旦有人用关键字标记了一个文件，其他人就不需要再用相同的关键字标记同一个文件。
• 星级。任何站点成员都可以对任何文件进行评级，但不能 re-rate 他们已评级的文件。
• 评论没有这样的限制，因为它们最终形成了对每个文件的讨论，所以网站成员可以写很多关于文件的评论。了解每个文件评论的日期、作者和主题将很有帮助。
您的图表不是 ERD。特别是，使用线来表示关系将您限制为二元关系，并且失去了实体关系模型的大部分表达能力。
通过使用 Username 和 Password 的组合作为用户 table 中的主键，您允许不同的用户可以使用相同的 Username使用不同的密码。这是你想要的吗？但是，在 Upload file table 中，您只存储了 Author_username，所以也许您只想将 Username 作为键？你需要在这里保持一致。
你的Uploaded filetable需要分解成很多。目前，它仅支持每个 file/username 一个标签、一个评分和一个评论。目前尚不清楚 Author_username 是指上传文件的用户还是对文件进行标记、评级和评论的用户。顺便说一句，这些东西在你的 table 中链接在一起，防止用户发布比评级更多的标签或评论。 File title 和 File description 可能只依赖于 File URL，如果存储了多个标签、评分或评论，将会重复，从而导致不一致的风险。
编辑：
鉴于您在评论中要求推荐，我建议：
- 使用 Chen 的 ERD 表示法，或者至少是使用形状表示关系并支持三元和更高关系的变体。更好的方法是 Object-Role Modeling.
- 仅使用
Username作为您的 4 个用户 table 的主键。 将
Uploaded file拆分为以下table：Uploaded file (File_URL PK, File_title, File_description, Username FK)File_tags (File_URL PK/FK, Tag PK)File_ratings (File_URL PK/FK, Username PK/FK, Rating)File_comments (Comment_ID PK, File_URL FK, Username FK, Comment, Created_at, Reply_to_comment_ID FK)
请注意，这只是为解决我提出的问题而进行的一组最小更改，用于教育目的，不一定是满足您要求的适当解决方案。