一个解决方案是存储一个拥有者文档，其中一个字段包含一个引用PC文档的对象ID列表，同样，PC文档也包含一个引用Parts文档的对象ID列表。
这就是MongoDB模拟关系的方式，想象一个SQL外键，它驻留在子节点中并引用父节点，然后反转引用的方向：MongoDB在父文档中存储其子文档的objectid列表。
但这不是规范化--这是 denormalization，就像在RDBMS中存储一个用逗号分隔的id列表，这将是一个打破第一范式的重复组。
您可能会合理地想知道，如果引用存储在PC文档中，您将如何找出哪些PC包含给定的部件。为此，您必须在部件文档中存储一个冗余的PC引用列表，然后担心如何保持双向引用同步，冒着PC认为它使用部件的异常风险。但该部并没有提述刑事诉讼法（反之亦然）。
您可以创建一个MongoDB文档来模拟SQL多对多交叉表，其中一个文档包含一个对PC的objectid引用和一个对Part的引用。然后创建许多这样的文档，就像您在SQL交叉表中创建许多行一样。但是因为这些是文档，而不是行。没有模式来强制所有文档只存储对每个实体的一个引用，也没有JOIN这样的东西来有效地进行查找。
这些都是非规范化和面向文档的数据库的结果，也是关系数据库仍然提供一些优势的原因。