Unit 3: Schema Design and Data Modeling - Subjective Questions

MongoDB is described as schema-less because documents in the same collection are not required to contain exactly the same fields or use an identical structure.

• A document can contain fields that are absent from other documents in the same collection.
• Fields and nested structures can be added as application requirements evolve.
• Related information can be represented using embedded documents and arrays.
• MongoDB still has an implicit schema determined by application code, indexes, validation rules, and data-access patterns.

In a relational database, a table generally has a predefined schema consisting of fixed columns, data types, keys, and constraints. Altering that structure usually requires a schema migration. MongoDB provides greater structural flexibility, but developers must still maintain consistency through careful modeling and validation.

Advantages:

• Rapid development: Fields can be introduced without immediately changing every existing document.
• Natural object representation: Nested objects and arrays map well to application data structures.
• Support for heterogeneous data: A collection can store documents with variations in attributes.
• Simpler evolution: New application versions can gradually adopt new fields.

Disadvantages:

• Inconsistent documents: Different names or data types may accidentally be used for the same concept.
• Complex application logic: Code may need to handle multiple document versions.
• Difficult analytics: Irregular structures can complicate aggregation and reporting.
• Weak integrity without validation: Invalid data may be stored if application checks and database validators are absent.

Therefore, schema flexibility should be controlled using conventions, validation rules, tests, and migration strategies.

Embedding stores related data inside a parent document. For example, an order may embed its delivery address and line items. It is suitable when related data is usually read together, has the same lifecycle, and remains bounded in size.

{
  _id: 101,
  customer: "Asha",
  address: { city: "Pune", pin: "411001" }
}

Referencing stores related entities in separate collections and connects them through identifiers. For example, an order may store a customerId that refers to a customer document.

{
  _id: 101,
  customerId: ObjectId("64ab...")
}

Key differences:

• Embedding provides faster single-document reads and atomic updates.
• Referencing reduces duplication and supports independently changing entities.
• Embedding may create large or unbounded documents.
• Referencing may require additional queries or a $lookup aggregation.

The choice should be based primarily on access patterns, update frequency, relationship cardinality, and expected data growth.

The choice between embedding and referencing should consider the following factors:

• Read pattern: Embed data that is usually retrieved with its parent.
• Update pattern: Reference data that changes frequently and must remain consistent in many places.
• Cardinality: Embedding works well for one-to-one and bounded one-to-few relationships.
• Data growth: Use references when an embedded array could grow without a practical limit.
• Atomicity: Operations on one MongoDB document are atomic, so embedding helps when related values must be updated together.
• Duplication: Embedding may duplicate shared data, while referencing centralizes it.
• Document size: A BSON document must remain within MongoDB's document-size limit.
• Entity lifecycle: Data owned by and deleted with the parent is a strong candidate for embedding.

A good model balances query efficiency, storage costs, consistency requirements, and future growth.

A one-to-one relationship exists when one entity is associated with at most one instance of another entity, such as a user and a profile.

Embedding approach:

{
  _id: 1,
  username: "nina",
  profile: {
    fullName: "Nina Shah",
    language: "English"
  }
}

Embedding is appropriate when the profile is owned by the user, is usually read with the user, and does not grow significantly.

Referencing approach:

// users
{ _id: 1, username: "nina" }

// profiles
{ _id: 20, userId: 1, fullName: "Nina Shah" }

Referencing is useful when the profile is large, accessed separately, protected by different permissions, or updated independently. A unique index on profiles.userId can enforce that only one profile exists for each user.

A one-to-many relationship can be modeled according to the number of related items and the application's query patterns.

1. Embed books inside the author:

{
  _id: 1,
  name: "Author A",
  books: [
    { title: "Book One", year: 2022 },
    { title: "Book Two", year: 2024 }
  ]
}

This is efficient when the number of books is small and bounded and books are usually retrieved with the author.

2. Store an array of book references in the author:

{ _id: 1, name: "Author A", bookIds: [101, 102] }

This is useful for a manageable reference list, but the array may become difficult to maintain if it grows considerably.

3. Store the parent reference in each book:

{ _id: 101, title: "Book One", authorId: 1 }

This is generally preferable for a large or unbounded number of books. An index on authorId supports efficient retrieval of all books by an author.

An ever-growing embedded array creates several risks:

• The parent document may eventually approach MongoDB's maximum BSON document size.
• Reading the parent may unnecessarily transfer the entire array.
• Large array updates can increase storage and write costs.
• Frequently updating one parent document can create write contention.
• Pagination and independent indexing of child records become more difficult.
• The parent document's size becomes unpredictable.

For an unbounded relationship, child records should usually be stored in a separate collection with a reference to the parent. For example, each comment can contain a postId. An index on postId, possibly combined with a date field, allows efficient filtering, sorting, and pagination.

In a many-to-many relationship, each student may enroll in many courses, and each course may contain many students.

Array-of-references approach:

// students
{ _id: 1, name: "Ravi", courseIds: [101, 102] }

// courses
{ _id: 101, title: "Databases", studentIds: [1, 2] }

This approach is simple for small, bounded relationships but duplicates links and makes consistency more difficult.

Association collection approach:

// enrollments
{
  studentId: 1,
  courseId: 101,
  enrolledAt: ISODate("2025-01-10"),
  grade: "A"
}

The association collection is better when relationships are numerous, unbounded, or have attributes such as enrollment date and grade. A compound unique index on { studentId: 1, courseId: 1 } prevents duplicate enrollment. Separate indexes can support queries by student or by course.

Arrays of references:

• Simple to understand and may provide direct access to related identifiers.
• Suitable when each array remains small and bounded.
• Can duplicate relationship information on both sides.
• Large arrays are expensive to update and may cause document growth.
• Relationship-specific attributes are awkward to store.

Association collection:

• Stores one document per relationship.
• Supports attributes such as role, status, quantity, date, or grade.
• Scales better for large and changing relationships.
• Allows compound indexes and uniqueness constraints on pairs of identifiers.
• Requires an additional query or $lookup to retrieve complete related records.

An association collection is generally the stronger design when the relationship is itself an important domain entity or can grow without a clear bound.

Access-pattern-based modeling starts by identifying how the application reads and writes data rather than first normalizing entities into separate collections.

Important questions include:

• Which data is commonly fetched together?
• Which queries are most frequent or latency-sensitive?
• Which fields are used for filtering, sorting, and joining?
• Which values must be updated atomically?
• How quickly will documents and arrays grow?
• Is the workload read-heavy or write-heavy?

Frequently co-accessed and bounded data may be embedded to reduce round trips. Independently accessed, frequently updated, shared, or unbounded data is often referenced. Indexes should then be designed for the important query shapes. The result may deliberately duplicate selected values when that improves common reads without creating unacceptable consistency costs.

Important MongoDB data modeling practices include:

• Model data around actual query and update patterns.
• Embed related data when it is bounded and commonly accessed with its parent.
• Reference independently changing, shared, or unbounded entities.
• Avoid documents and arrays whose growth cannot be predicted.
• Store fields with consistent names, meanings, and BSON data types.
• Add indexes that support important filters, sorts, and relationship lookups.
• Use schema validation to reject structurally invalid documents.
• Use controlled denormalization only when its read benefits justify synchronization costs.
• Include a schema-version field when documents may require gradual migrations.
• Monitor document size, query performance, index usage, and update frequency using realistic data volumes.

A successful design balances performance, consistency, simplicity, storage use, and future scalability.

Denormalization means intentionally duplicating or embedding data to make reads simpler or faster. For example, an order may store both customerId and a snapshot of the customer's name and delivery address.

Benefits:

• Reduces the number of queries and joins.
• Improves read latency for frequently requested views.
• Allows a document to preserve historical values, such as the address used for an order.
• Can make aggregation and distributed reads simpler.

Risks:

• The same fact may exist in several documents.
• Updates may need to be propagated to multiple locations.
• Partial failures can create inconsistent copies.
• Additional storage is required.

Denormalization is appropriate when reads are frequent, duplicated values change infrequently, or the copied value represents a historical snapshot. A synchronization strategy is required when copies must remain current.

A practical model uses separate customers, products, and orders collections.

An order document can be structured as follows:

{
  _id: ObjectId("..."),
  customerId: ObjectId("..."),
  placedAt: ISODate("2025-02-01"),
  status: "shipped",
  shippingAddress: {
    line1: "10 Market Road",
    city: "Mumbai",
    postalCode: "400001"
  },
  items: [
    {
      productId: ObjectId("..."),
      productName: "Keyboard",
      unitPrice: 2500,
      quantity: 2
    }
  ],
  total: 5000
}

Design justification:

• customerId is referenced because the customer exists independently and may place many orders.
• Products are referenced through productId because inventory and current product details change independently.
• The product name and price are copied into each item to preserve the historical transaction.
• The delivery address is embedded as a snapshot because later customer address changes must not alter an existing order.
• Order items are embedded because they belong to the order, are generally read with it, and are normally bounded.

Indexes may include customerId, placedAt, status, and compound indexes based on the application's order-search patterns.

A suitable design uses separate users, posts, comments, and tags collections.

A post may contain:

{
  _id: ObjectId("..."),
  authorId: ObjectId("..."),
  title: "MongoDB Modeling",
  body: "...",
  tagIds: [ObjectId("..."), ObjectId("...")],
  commentCount: 245,
  createdAt: ISODate("2025-01-01")
}

Each comment may contain:

{
  _id: ObjectId("..."),
  postId: ObjectId("..."),
  authorId: ObjectId("..."),
  text: "Useful explanation",
  createdAt: ISODate("2025-01-02")
}

Justification:

• Posts reference users because users exist independently and create many posts.
• Comments are separated because their number per post may be unbounded.
• An index such as { postId: 1, createdAt: -1 } supports comment pagination.
• Tag references are acceptable when each post has a small number of tags.
• commentCount may be denormalized into the post for fast display, with controlled updates.

Expected growth is critical: small bounded metadata can be embedded, while potentially unlimited content should be stored separately.

Schema validation rules allow MongoDB to check documents during insert and update operations. The $jsonSchema operator can specify required fields, BSON types, nested structures, allowed values, and numeric or length restrictions.

Example:

db.createCollection("students", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["name", "age", "status"],
      properties: {
        name: {
          bsonType: "string",
          minLength: 1
        },
        age: {
          bsonType: "int",
          minimum: 16
        },
        status: {
          enum: ["active", "inactive"]
        }
      }
    }
  }
})

This validator requires name, age, and status; checks their values and types; and restricts status to predefined values. Validation improves consistency while preserving MongoDB's ability to evolve schemas deliberately.

validationLevel determines which documents are checked, while validationAction determines what happens when validation fails.

validationLevel:

• strict: Validates all inserts and all updates. This is the default behavior.
• moderate: Validates inserts and updates to documents that already satisfy the validator; it provides more flexibility when legacy invalid documents exist.
• off: Disables validation.

validationAction:

• error: Rejects an insert or update that violates the validation rule. This is the default.
• warn: Allows the operation but records a warning in the server log.

For a legacy collection, a team may initially use moderate with warn, clean existing data, and later move to strict with error for stronger enforcement.

MongoDB indexes can enforce selected constraints and improve relationship queries.

• A unique index prevents duplicate values, such as duplicate email addresses.
• A compound unique index prevents duplicate combinations, such as repeated student-course enrollment.
• A partial unique index can enforce uniqueness only for documents matching a condition.
• Indexes on reference fields, such as authorId or postId, make relationship traversal efficient.

Example:

db.enrollments.createIndex(
  { studentId: 1, courseId: 1 },
  { unique: true }
)

However, a normal MongoDB reference does not automatically enforce referential integrity. A document may contain an identifier that points to no existing document, and deleting a parent does not automatically delete or reject its children. Such rules must be handled through application logic, transactions, background checks, or carefully designed workflows.

A controlled schema-evolution strategy can include the following steps:

• Add a field such as schemaVersion to identify the document format.
• Make application reads temporarily support both old and new formats.
• Ensure new writes use the latest format.
• Backfill existing documents in small batches to reduce operational impact.
• Make migration operations idempotent so they can be safely retried.
• Add or update validation rules only after incompatible legacy data has been migrated.
• Create required indexes with attention to production workload.
• Monitor failures, performance, and the number of remaining legacy documents.
• Remove compatibility code only after migration verification.

For example, if name is divided into firstName and lastName, the application can read either representation during migration while a background process updates old documents. This approach supports gradual deployment with limited downtime.

Embedding every follower identifier in a user's document is unsuitable because follower arrays can grow without bound. Large arrays make updates, pagination, and document growth difficult. Storing both followers and following arrays also duplicates every relationship and increases consistency work.

A scalable approach is a separate follows collection:

{
  followerId: ObjectId("..."),
  followedId: ObjectId("..."),
  createdAt: ISODate("2025-01-01")
}

Recommended indexes include:

• A unique compound index on { followerId: 1, followedId: 1 } to prevent duplicate follows.
• An index on { followedId: 1, createdAt: -1 } to list followers.
• An index on { followerId: 1, createdAt: -1 } to list followed accounts.

Follower counts may be denormalized into user documents for quick display, provided updates are managed reliably and occasional reconciliation is possible. This model supports unbounded growth, relationship pagination, and independent indexing.

Embedding complete loan history in each member document causes several problems:

• The loan array grows without a clear bound.
• Member documents become increasingly expensive to read and update.
• Pagination and searching by due date or book become difficult.
• Concurrent loan operations repeatedly modify the same member document.
• The model may eventually approach the BSON document-size limit.

A better design uses separate collections for members, books, and loans:

{
  _id: ObjectId("..."),
  memberId: ObjectId("..."),
  bookId: ObjectId("..."),
  borrowedAt: ISODate("2025-01-01"),
  dueAt: ISODate("2025-01-15"),
  returnedAt: null,
  status: "borrowed"
}

Indexes should support common operations, such as { memberId: 1, borrowedAt: -1 }, { bookId: 1, status: 1 }, and { status: 1, dueAt: 1 }. Small summary values, such as a member's current-loan count, may be denormalized when necessary. Validation should require identifiers and dates and restrict status to recognized values.