How to model a Firebase Database in UML diagrams?

The Firebase databases, be it its realtime database or the cloud firestore, are document-oriented NoSQL databases. There are indeed no tables, just collections of documents, where each document is a JSON-like structure, and documents could contain other embedded collections or documents.

In theory, each document in a collection could be completely different from all the others. In this case, an UML class-diagram would make no sense since classes suppose common properties and behaviors.

db.collection("ouch"):          // Not recommended 
     [ {name: "Spiderman"}, 
       {size: "XXL", item: "T-Shirt}, 
       {date: "July 4 1776", event:"independence day"} ]

In practice, however, documents in a collection are in general a set of very similar objects, or at least related objects. May be one object of the set has a couple of properties more, or a couple of properties less. But they represent the same kind of things:

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 } ]

In this case, you may perfectly use UML class diagrams, because UML is not table based, but class based:

• A class represents a kind of things. In reverse engineering you'd usually start with the known collections.
• Small structural differences between documents of a same kind would be represented in the UML class diagram either with "optional" properties (i.e. multiplicity [0..1]) (see lastLogin in the users example).
• More substantial differences between documents having some common ground, would usually be modeeled with more specialized classes (see the shopItems example, where we can guess a class ShopItem and specializations thereof such as BookItem, RecordItem, TextileItem).
• The challenge in the modelling, is to understand the embedded documents and sub-collections. These are often sign other associated classes (or composed classes).

In principle, the UML class-diagram would not be used only for the database (data only), but it would be used to design the objet model of your application (data and behavior) independently of your database. The model could then help you to design the database based on the kind of objects needed to address you' user's needs.