How to draw a NoSQL database (document oriented) with UML?

You can use UML class diagrams to model entities and aggregates of an application domain, regardless of the implementation technology. You can also model a more concrete implementation that uses a NoSQL database, and in particular document stores such as CouchDB. Objects are stored in the database are kind-of dehydrated (i.e. object data without their behavior) into a document.

There are challenge that you will face:

1. mapping between the document world and the object world: a document may contain several related objects (no joins needed), as well as links to other objects (see also embedded/nested document vs. document references).

2. potentially unstructured (or loosely structured) documents: document databases are extremely flexible about the content of documents, and it is perfectly allowed to mix objects of completely unrelated classes into the same document collection. Moreover, the fields/properties/members of a document may be dynamic and evolve. In practice however, collections often contain similar objects that will vary mainly regarding the fields (for example to acknowledge existence of implicit classes). Documents may even be validated according to a schema to ensure consistency if needed.

3. UML classes are based on strong typing, whereas types in documents are as flexible as the rest of their content (e.g. a field from could be a date 2000-04-02 in one document or a string "a long time ago" in another one).

So before you start, you need to think of the mapping strategy. My advice would be to focus in UML on the design of your object model, and think of documents as a convenient grouping of related ones (DDD aggregates may help in this regard). The following rule of thumb may help for the modeling:

• joins (e.g. links between independent documents) will be represented by associations.
• systematic grouping of objects with other, may suggest existence of some kind of stronger relation such as UML composition.
• fields that vary from document to document would be represented either with optional properties (multiplicity 0..1 or 0..*) or generalisation/specialization of the enclosing object, depending on the logic that explains the variation.