Normalization vs denormalization default in MongoDB - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Default Data Organization in MongoDB

In MongoDB, when you design your data model without explicitly embedding related data, what is the default approach to organizing data?

A Data is normalized by storing references between documents

B Data is denormalized by embedding all related data in one document

C Data is stored in flat tables like in relational databases

D Data is automatically partitioned across multiple collections

💡 Hint

Think about how MongoDB stores documents by default when you don't embed related data.

MongoDB by default stores data in separate documents and collections, using references to relate data, which is a form of normalization. Embedding data (denormalization) is a design choice, not the default.

❓ query_result

intermediate

Query Result with Normalized Data References

Given two collections in MongoDB: users and orders. Each order document stores a userId referencing a user. What will be the output of this aggregation query that looks up user info for each order?

MongoDB

db.orders.aggregate([
  { $lookup: {
      from: 'users',
      localField: 'userId',
      foreignField: '_id',
      as: 'userInfo'
  }},
  { $unwind: '$userInfo' },
  { $project: { _id: 0, orderId: 1, 'userInfo.name': 1 } }
])

A [{ orderId: 101, userId: 'Alice' }, { orderId: 102, userId: 'Bob' }]

B [{ orderId: 101, userInfo: 'Alice' }, { orderId: 102, userInfo: 'Bob' }]

C [{ orderId: 101, userInfo: { name: 'Alice' } }, { orderId: 102, userInfo: { name: 'Bob' } }]

D []

💡 Hint

Look at how $lookup and $unwind work to join and flatten the user info.

The $lookup stage joins orders with users by matching userId to _id. The $unwind stage converts the userInfo array to a single object. The $project stage selects only orderId and userInfo.name fields.

📝 Syntax

advanced

Identify the Syntax Error in Denormalized Document Update

Which of the following MongoDB update commands correctly updates the embedded address city in a denormalized user document?

MongoDB

User document example: { _id: 1, name: 'John', address: { city: 'Oldtown', zip: '12345' } }

A db.users.updateOne({ _id: 1 }, { $set: { address.city: 'Newtown' } })

B db.users.updateOne({ _id: 1 }, { $set: { 'address.city': 'Newtown' } })

C db.users.updateOne({ _id: 1 }, { $set: { 'address->city': 'Newtown' } })

D db.users.updateOne({ _id: 1 }, { $set: { address['city']: 'Newtown' } })

💡 Hint

Check the correct way to specify nested fields in MongoDB update operators.

MongoDB uses dot notation in strings to update nested fields. Option B correctly uses 'address.city' as a string key. Options B, C, and D use invalid syntax.

❓ optimization

advanced

Optimizing Read Performance with Denormalization

You have a MongoDB collection where user profiles embed their recent activity logs. Which of the following is a key advantage of this denormalized design compared to normalized references?

A Faster reads because all related data is in one document, reducing the need for joins

B Smaller document size leading to less storage usage

C Easier to maintain consistency across multiple collections

D Automatic indexing of embedded documents without extra configuration

💡 Hint

Think about how embedding affects the number of queries needed to get related data.

Embedding related data reduces the need for multiple queries or joins, improving read performance. However, it can increase document size and complicate updates.

🔧 Debug

expert

Debugging Data Inconsistency in Mixed Normalization Design

A MongoDB application stores user data with some fields embedded (denormalized) and others referenced (normalized). After updating a user's email in the users collection, the embedded email in orders documents is not updated. What is the most likely cause?

A The orders collection is read-only and cannot be updated

B MongoDB automatically updates embedded fields but the update query is incorrect

C The email field cannot be embedded and referenced at the same time by design

D The application does not update embedded email fields in orders after changing the user email

💡 Hint

Consider how denormalized data requires manual synchronization.

When data is denormalized by embedding, updates to the original source do not automatically propagate. The application must explicitly update all embedded copies to keep data consistent.