如何基于Firebase Firestore制作MCD、MLD及类图？

1. 概念数据模型（CDM）设计 #

这一步完全不需要考虑Firestore的文档型数据库特性，和传统关系型数据库的CDM设计逻辑完全一致，核心是梳理业务核心实体、实体属性、实体间的关联关系，不需要引入任何存储层的技术概念：

• 先罗列所有业务核心实体，比如博客类应用的核心实体为：用户、文章、评论、分类
• 标注每个实体的核心基础属性，比如用户实体包含ID、昵称、邮箱、注册时间
• 明确实体间的关联基数：1对1（1个用户对应1份实名认证信息）、1对多（1个用户发布多篇文章）、多对多（1篇文章关联多个分类，1个分类对应多篇文章）

2. 逻辑数据模型（LDM）设计 #

这一步需要结合Firestore的存储特性完成实体到存储结构的映射，核心是平衡查询性能和存储成本，优先以你的业务查询场景为导向设计：

• 首先把CDM中的核心实体映射为Firestore的顶层集合，实体的非关联属性映射为集合下的文档字段，字段类型和CDM定义保持一致
• 按照关联类型处理实体关系：
  • 1对1关联：直接嵌套为父文档的对象字段，不需要单独创建集合，比如用户的实名认证信息直接嵌套到用户文档的auth_info字段中
  • 1对多关联：如果子实体的查询全部依附于父实体（比如只有打开文章详情页才会查询评论），则将子实体设计为父文档下的子集合；如果子实体需要全局独立查询（比如需要单独统计所有用户的订单总金额），则将子实体设计为顶层集合，新增关联字段（比如user_id）绑定父实体ID
  • 多对多关联：使用数组字段存储关联的实体ID，比如文章文档中新增category_ids数组存储关联的分类ID，避免做跨集合关联查询（Firestore不支持原生join操作）
• 高频查询场景可以做适度反范式设计：比如展示评论时需要固定显示发布者昵称，可直接在评论文档中冗余存储author_nickname字段，减少跨集合查询的次数

示例博客场景的LDM结构：

// 顶层集合：用户
users
  ├─ 文档字段：id(string)、nickname(string)、email(string)、created_at(timestamp)
// 顶层集合：文章
articles
  ├─ 文档字段：id(string)、author_id(string)、title(string)、content(string)、category_ids(array)、view_count(number)、created_at(timestamp)
  └─ 子集合：评论 comments
      └─ 文档字段：id(string)、author_id(string)、author_nickname(string)、content(string)、created_at(timestamp)
// 顶层集合：分类
categories
  └─ 文档字段：id(string)、name(string)、sort(number)、created_at(timestamp)

3. 类图设计 #

类图设计和你项目使用的编程语言的实体类定义对应即可，不需要和Firestore的存储结构完全绑定，核心是体现业务层的类依赖关系：

• 每个顶层集合对应一个独立的实体类，子集合对应父类的列表属性
• 嵌套的对象字段可以单独定义为类，作为父类的属性关联
• 类间的关联关系直接和CDM中的实体关系保持一致，不需要体现Firestore的子集合、冗余字段等存储层细节

示例TypeScript实体类定义（可直接映射为类图）：

class Address {
  province: string;
  city: string;
  detail: string;
}

class User {
  id: string;
  nickname: string;
  email: string;
  address?: Address;
  createdAt: Date;
}

class Comment {
  id: string;
  authorId: string;
  authorNickname: string;
  content: string;
  createdAt: Date;
}

class Article {
  id: string;
  authorId: string;
  title: string;
  content: string;
  categoryIds: string[];
  comments?: Comment[];
  createdAt: Date;
}

答辩报告注意事项 #

可以单独补充1段Firestore建模和关系型数据库建模的差异说明，重点突出你是结合文档型NoSQL的特性做的适配设计，比如没有强外键约束、支持嵌套结构、优先以查询性能为建模导向，避免生搬关系型数据库的三范式设计逻辑。

内容的提问来源于stack exchange，提问作者Gersain Ipandi