8

I have a project in android so I decided to make a Quiz app, and I used Firebase in it. But I also need to design UML diagrams for this project and I was wondering if I can do it since Firebase is a Table-less database.

Christophe
  • 68,716
  • 7
  • 72
  • 138
Monica Khoury
  • 109
  • 1
  • 6
  • What exactly is your concern? Do you wonder if you can represent a Firebase DB in UML? – qwerty_so Jan 13 '19 at 01:05
  • @Thomas Kilian yes because I have a university project and they need our android app to be represented in UML diagrams and I used Firebase till now so I was wodering if I can do it – Monica Khoury Jan 13 '19 at 02:04
  • 3
    A conceptual model is definitely possible, for example in a class diagram. A more concrete model may be possible, depending on your exact data model. For an introduction and some samples, see https://www.ripublication.com/ijaer17/ijaerv12n5_12.pdf. Also see https://stackoverflow.com/questions/11323841/mongodb-how-to-represent-a-schema-diagram-in-a-thesis – Frank van Puffelen Jan 13 '19 at 02:37
  • Please refer to the links @FrankvanPuffelen gave to you. Next time please be more concrete in your question. I had voted this as unclear. I will not retract my close vote since as such it is too broad. – qwerty_so Jan 13 '19 at 09:01
  • @FrankvanPuffelen okay Thank you! – Monica Khoury Jan 13 '19 at 22:20

1 Answers1

1

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.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • "In theory, each document in a collection can be completely different from all the others." ... that's the worst practice ever. no one would never recommend that. Data persistence = 0 ... And you should always do a conceptual model of your data (yes with uml), imho. – BorisD Jul 10 '21 at 22:46
  • 1
    @BorisDetry Exactly! I think we fully agree. This is why I started the sentence with “In theory” and followed with a paragraph “In practice” for the real world. And my last paragraph says exactly what you say about the conceptual model, except that O stringly believe that the conceptual model is not just for data, but for classes (data+behavior) ;-) – Christophe Jul 11 '21 at 07:51