Data modeling for NoSQL document database

Question

Below are the common phases applied, for a real world requirement(data) map to DBMS specific schema.

Conceptual models ER/EER/CODASYL/Hierarchical bridge the gap, in mapping the real world data(requirement) to DBMS specific schema.

In RDBMS world, object-relational impedance mismatch is the cause for applying these phases in database design.

Using RDBMS, reduces the agility of the application, because once the database is designed, it takes a lot to modify the DB schema again, based on new requirement.

But using, Document database(say MongoDB), factor of object mapping is intuitive, that minimizes impedance mismatch issue.

So, embedding & referencing of entities in JSON, would suffice for modeling real world data(requirement) to a document database.

Conceptual models(ER/EER/..) would not look like a necessity, for modeling document database.

---

Modeling data for document database(say MongoDB), are these phases still valid?

Answer 1

Modeling data for document database(say MongoDB), are these phases still valid?

Yes, they are. And it is much more important to do them right before the first release.

The reason is that in a document database you never change the structur of old documents. That means that every client accessing the database must be able to work with all versions of the document structure present in your database. This is why changes in the document structure should be well thought.

---

Changes in the document should be well thought, but for that, do we need phase of creating conceptual schema and then move to DB specific schema? – overexchange

The point is that you don't know if a document based database meets your requirements before the conceptual schema is finished.