Firebase 数据库，无论是 realtime database 还是 cloud firestore，都是 document-oriented NoSQL 数据库。确实没有表格，只有文档集合，其中每个文档都是类似 JSON 的结构，文档可以包含其他嵌入的集合或文档。
理论上，集合中的每个文档都可能与其他文档完全不同。在这种情况下，UML 类图将毫无意义，因为类假定了共同的属性和行为。
db.collection("ouch"): // Not recommended
[ {name: "Spiderman"},
{size: "XXL", item: "T-Shirt},
{date: "July 4 1776", event:"independence day"} ]
实际上，然而，集合中的文档通常是一组非常相似的对象，或者至少是相关的对象。可能是集合中的一个对象有更多的属性，或者更少的属性。但它们代表的是同一种东西：
db.collection("users"): // example 1, small variations
[ { id: "AL", first: "Ada",last: "Lovelace"},
{ id: "JSMITH", last: "Smith", first: "Joe", lastLogin:"2021-07-10"} ]
db.collection("shopItems"): // example 2, more variations but common ground
[ { id: 123, type: "Book", title: "The definitive guide to Firebase", author:"L.Moroney", price: 34.23 },
{ id: 124, type: "Record", title: "Get lucky", artist: "Daft Punk", price: 16.20}
{ id: 125, type: "Shirt", brand: "Seidensticker", model:"Classic", size: "XL", color:"white", price: 65.00 } ]
在这种情况下，你可以完美地使用 UML 类图，因为 UML 不是基于表的，而是基于类的：
- 一个类代表一种事物。在逆向工程中，您通常会从已知集合开始。
- 同类文档之间的微小结构差异将在 UML 类图中表示为“可选”属性（即多重性 [0..1]）（参见
users 示例中的 lastLogin）。
- 具有某些共同点的文档之间存在更大的实质性差异，通常会使用更专业的类进行建模（参见
shopItems 示例，我们可以在其中猜测类ShopItem 及其专业化，例如BookItem、RecordItem , TextileItem)。
- 建模中的挑战是理解嵌入的文档和子集合。这些通常是其他关联类（或组合类）的符号。
原则上，UML 类图不会仅用于数据库（仅数据），而是用于独立设计应用程序的对象模型（数据和行为）您的数据库。然后，该模型可以根据满足您的用户需求所需的对象类型 help you to design 数据库。