相当于 MongoDB 的 ERD？
对于 MongoDB 等 NoSQL 数据库，ERD 相当于什么？
What would be the equivalent of ERD for a NoSQL database such as MongoDB?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
对于 MongoDB 等 NoSQL 数据库，ERD 相当于什么？
What would be the equivalent of ERD for a NoSQL database such as MongoDB?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（6）
看来您在 Quora 上提出了类似问题。
正如那里提到的，ERD 只是您要存储的数据以及该数据之间的关系的映射。
您仍然可以使用 MongoDB 制作 ERD，因为您仍然想要跟踪数据和关系。最大的区别是 MongoDB 没有连接，因此当您将 ERD 转换为实际模式时，您必须做出一些关于实现关系的具体决策。
特别是，在决定如何存储这些数据时，您需要做出“嵌入与引用”决策实际上会被存储。关系仍然是允许的，只是不强制。 MongoDB 的许多包装器实际上提供了跨集合的查找来抽象出一些复杂性。
尽管 MongoDB 不强制执行模式，但也不建议完全随机地进行。对您期望在系统中拥有的数据进行建模仍然是一个非常好的主意，这就是 ERD 为您提供的。
所以我猜 ERD 的等价物是 ERD？
It looks like you asked a similar question on Quora.
As mentioned there, the ERD is simply a mapping of the data you intend to store and the relations amongst that data.
You can still make an ERD with MongoDB as you still want to track the data and the relations. The big difference is that MongoDB has no joins, so when you translate the ERD into an actual schema you'll have to make some specific decisions about implement the relationships.
In particular, you'll need to make the "embed vs. reference" decision when deciding how this data will actually be stored. Relations are still allowed, just not enforced. Many of the wrappers for MongoDB actually provide lookups across collections to abstract some of this complexity.
Even though MongoDB does not enforce a schema, it's not recommended to proceed completely at random. Modeling the data you expect to have in the system is still a really good idea and that's what the ERD provides you.
So I guess the equivalent to the ERD is the ERD?
您也可以只使用 UML 类图。
You could just use a UML class diagram instead too.
我已经思考同样的问题很长一段时间了。
我得出以下结论：
如果 NoSQL 数据库通常是无模式的，那么您实际上没有“模式”可以在图表中进行说明。
因此，我认为你应该采取“举例”的方法。
您可以绘制一些思维导图来举例说明数据存储在 NoSQL DB（例如 MongoDB）中时的样子。
由于这些数据库非常动态，您还可以创建一些派生思维导图来显示今天的数据如何及时演变。
也看看这个话题。
NoSQL 设计的困惑
I have been thinking about the same issue for quite some time.
And I came to the following conclusion:
If NoSQL databases are generally schemaless, you don't actually have a 'schema' to illustrate in a diagram.
Thus, I think you should take a "by example" approach.
You could draw some mindmaps exemplifying how your data would look like when stored in a NoSQL DB such as MongoDB.
And since these databases are very dynamic you could also create some derived mindmaps to show how the data from today could evolve in time.
Take a look at this topic too.
Confusion about NoSQL Design
Moon Modeler 支持 MongoDB 的架构设计。它允许用户定义具有嵌套结构的图表。
Moon Modeler supports schema design for MongoDB. It allows users to define diagrams with nested structures.
我知道没有标准的方法来绘制面向文档的“模式”。
我确信您可以使用 ERD 来映射您的模式，但由于文档数据库并不真正支持（或更重要的是强制执行）数据之间的关系，因此只有当您的代码被严格要求在内部强制执行此类关系时，它才会有用。 。
I know of no standard means of diagramming document-oriented "schema".
I'm sure you could use an ERD to map out your schemata but since document databases do not truly support--or more importantly enforce--relationships between data, it would only be as useful as your code was disciplined to internally enforce such relationships.
MongoDB 确实支持“连接”，只是不支持 SQL 意义上的 INNER JOIN（默认 SQL 连接）。虽然“连接”的概念通常与 SQL 相关，但 MongoDB 确实具有聚合框架及其数据处理管道阶段。 $lookup 管道阶段用于创建 SQL 中 LEFT JOIN 的等效项。也就是说，关系左侧的所有文档以及关系右侧的任何相关文档都将通过管道传递。文档经过修改以将关系包含在新文档中。
因此，我假设实体关系图确实在 MongoDB 中发挥着作用。文档在数据库中肯定是相互关联的，我们应该对这些关系进行可视化，包括基数关系，例如完全参与、部分参与、弱/强实体等。
当然，MongoDB还引入了嵌入式的概念文档和参考文档，因此我认为它为 ERD 模型增添了额外的风味。我当然希望看到在可视化图表中映射的嵌入和引用关系。
剩下的问题是那里有什么？ NodeJS 的 Mongoose 有什么？ Ruby 的 Mongoid？如果您检查相应的存储库中相应的 ORM（对象关系映射器），那么您将看到它们有 ERD。但就其完整性而言，也许还有很多不足之处，欢迎开源社区做出贡献。
MongoDB does support 'joins', just not in the SQL sense of INNER JOIN (the default SQL join). While the concept of 'join' is typically associated with SQL, MongoDB does have the aggregation framework with its data processing pipeline stages. The $lookup pipeline stage is used to create the equivalent of a LEFT JOIN in SQL. That is, all documents on the left of a relationship will be pass through the pipeline, as well as any relating documents on the right side of the relationship. The documents are modified to include the relationship as part of the new documents.
Consequently, I postulate that Entity Relationship Diagrams do have a role in MongoDB. Documents are certainly related to each other in the db, and we should have a visualization of these relationships, including the cardinality relationship, e.g. full participation, partial participation, weak/strong entities, etc.
Of course, MongoDB also introduces the concept of embedded documents and referenced documents, and so I argue it adds additional flavor to the model of the ERD. And I certainly would want to see embedded and referenced relationships mapped out in a visual diagram.
The remaining question is so what is out there? What is out there for Mongoose for NodeJS? Mongoid for Ruby? etc. If you check the respective repositories for their corresponding ORMs (Object Relational Mappers), then you will see there are ERDs for them. But in terms of their completeness, perhaps there is a lot to be desired and the open source community is welcome to make contributions.