How do you document the logical data model of a document-oriented database like MongoDB?
For relational databases, Entity-Relationship diagrams or UML class diagrams are used.
What is the practice for NoSQL document databases?
In particular, how do you describe the existence of nested entities versus referenced entities?
Also, how do you highlight the data redundancy that was introduced by design?
Nesting data is an artifact of how data is stored in a document database — the physical data model. Translating that to a logical data model requires you to reorient how you think about the data in terms of relationships rather than "nesting." However you choose to document your logical data model, remember that you are describing relationships between data, and nesting is a kind of relationship. To me, nesting implies ownership. Given that nested data structures are "owned" by their parent structure, I would recommend a UML class diagram showing the aggregate associations.
UML aggregate associations come in two main flavors. One implies "ownership" and the other doesn't. The diamond shape is used to denote which entity has the relationship. A diamond with a solid fill color would probably be most useful in your case, because this shape claims that one entity "owns" another. This is the closest I can think of to a "nested" relationship.
For example, say your "Customer" document is in this structure:
{
"FirstName": "...",
"LastName": "...",
"Email": "...",
"Purchases": [
{ ... },
{ ... },
{ ... }
]
}
The relationship between the parent entity "Customer" and the nested collection "Purchases" could look like this in a UML diagram:
The 1..* notation under the line between the two entities can indicate the multiplicity of that relationship. In this case, 1 customer can have zero or more purchases. The diamond shape is resting against the "Customer" entity, because that is the entity that contains the nested purchases.
For other cases where your data structure only has one object being nested, e.g.
{
"Person": {
"Name": "...",
...
},
...
}
You would still use the solid fill diamond, but change the multiplicity to indicate that only one "Person" is nested: 1..1. This sort of notation might make the nesting less obvious, but it would translate easier to an object oriented model.
To help clarify the meanings, consider adding a Key to your diagram to describe what this notation means for a document database.
Document databases store collections of data objects that have a dynamic, self-describing structure. MongoDB and many other such databases use JSON or its binary equivalent BSON for data objects.
There is no modeling technique dedicated to document databases. Moreover, traditional ERD techniques, including extended ERD, are not well suited for dynamic data formats.
UML on the other hand is ideally suited for documenting object oriented models, including data object models: it can model specific object instances as well as general classes of objects. It's not well known, but the UML classifier semantic correspond very closely to what you do when trying to group sets of JSON objects that match some specific expectations.
You will find an explanation about mapping document databases to UML classes here on StackOverflow. In addition, some more practical details about referential links and nested objects:
If you think this might be confusing, you could consider creating a profile in your UML model with some explicit stereotypes for associations, e.g. <<nested>> and <<reference>>.
UML is method neutral. There is no distinction between a conceptual, a logical and a physical model: it's the same UML notation and semantic.
It's up to you to decide if you want one model or three distinct ones, and what level of details you want to include. For example in a logical data model you would represent the classes and the associations. But you would not yet care about implementation details, such as repeating some keys to implement a relation.
