Unit 2 — MongoDB Architecture, Data Modeling and Basics

Topics Covered

Syllabus topics: MongoDB architecture — database, collection, document concepts; BSON format; advantages of MongoDB over RDBMS; MongoDB datatypes (String, Number, Date, Boolean, Array, ObjectId, Embedded Documents, Null). Data modeling in MongoDB — schema design strategies, embedded vs referenced documents. Database and collection management — create and drop database, create and drop collection.

2.1 The hierarchy

mongod (the server process)
└── Database          collegeDB
    └── Collection    students          ← like a TABLE, but schema-free
        └── Document  { _id: 21, ... }  ← like a ROW, but nested
            └── Field  name: "Asha"     ← like a COLUMN, but per-document

Limits worth knowing

The 16 MB limit is examinable and it drives design. An "embed everything" model fails the day one document grows past it — a blog post with unbounded comments, a student with unbounded attendance records. §2.6 is largely about recognising that case in advance. For genuinely large content there is GridFS, which splits a file into 255 KB chunks across two collections.

JSON on your screen        { "_id": 21, "name": "Asha" }
BSON on disk               \x1d\x00\x00\x00        <- 29 bytes, total length
                           \x10 _id \x00 \x15...    <- \x10 = int32
                           \x02 name \x00 ...       <- \x02 = string
                           \x00                     <- end of document

2.2 Advantages of MongoDB over RDBMS

⚠️ State the disadvantages too

A ten-mark answer that lists only advantages is an incomplete answer.

2.3 MongoDB data types

⚠️ Three type traps

1. The shell stores whole numbers as Double.

db.c.insertOne({ n: 5 })                  // stored as a DOUBLE
db.c.insertOne({ n: NumberInt(5) })       // an int32
db.c.insertOne({ n: NumberLong(5) })      // an int64

Harmless until you need exact integer arithmetic or compact storage.

2. Never store money as a Double.

{ price: 19.99 }                     // a double -- cannot represent 19.99 exactly
{ price: NumberDecimal("19.99") }    // exact
{ priceInPaise: NumberInt(1999) }    // or work in the smallest unit

This is Problem Solving Using C's and Python for Data Analysis and Visualization's floating-point lesson again: binary floating point cannot represent most decimal fractions exactly, so sums of prices drift.

3. null, missing and undefined are three different things.

{ _id: 1, phone: "9876543210" }     // present, with a value
{ _id: 2, phone: null }             // present, explicitly empty
{ _id: 3 }                          // ABSENT

db.c.find({ phone: null })          // matches BOTH _id 2 AND _id 3
db.c.find({ phone: { $exists: false } })   // matches ONLY _id 3
db.c.find({ phone: { $type: "null" } })    // matches ONLY _id 2

{ field: null } matches missing fields as well as null ones, which is almost never what a beginner intends. This is a guaranteed exam question and a real source of wrong query results.

Dates

db.students.insertOne({ name: "Asha", dob: ISODate("2005-04-03") })
db.students.find({ dob: { $lt: ISODate("2006-01-01") } })      // works
db.students.insertOne({ name: "Ravi", dob: "2005-04-03" })     // a STRING

A date stored as a string cannot be compared or sorted reliably — string ordering only coincides with date ordering in ISO YYYY-MM-DD form, and breaks for any other format. Store dates as dates. MongoDB stores them as UTC; timezone handling is the application's job.

2.4 Database and collection management

// --- databases -------------------------------------------------------------
use collegeDB               // switch to it; CREATES NOTHING yet
db                          // the current database
show dbs                    // list -- an EMPTY database will not appear
db.dropDatabase()           // drop the CURRENT database

// --- collections -----------------------------------------------------------
db.createCollection("students")
db.createCollection("logs", { capped: true, size: 100000, max: 1000 })
db.createCollection("students", {                 // with schema validation
  validator: { $jsonSchema: { /* see 2.7 */ } }
})

show collections
db.getCollectionNames()
db.students.drop()                                // drop ONE collection
db.students.renameCollection("learners")
db.students.countDocuments()                      // an ACCURATE count
db.students.estimatedDocumentCount()              // fast, from metadata
db.students.stats()

⚠️ Lazy creation, again

use brandNewDB
show dbs                     // brandNewDB is ABSENT
db.things.insertOne({ x: 1 })
show dbs                     // now it exists

A database or collection springs into existence on the first write. So does a collection: db.anything.insertOne({}) creates anything. createCollection is only needed when you want options — validation, capping, a custom collation.

⚠️ count() versus countDocuments()

db.c.count() is deprecated and could be inaccurate on a sharded cluster or after an unclean shutdown, because it read cached metadata. countDocuments() actually counts and is correct; estimatedDocumentCount() is the fast, approximate one, and its name says so honestly.

Capped collections

A fixed-size collection that overwrites its oldest documents when full, preserving insertion order. Useful for logs and caches. You cannot delete from one, and you cannot grow a document beyond its original size.

2.5 Schema design strategies

The steps

1. List the queries the application will run, and how often.
2. Identify the entities and their relationships.
3. For each relationship, decide embed or reference (§2.6).

4. Consider read/write ratio — reads favour embedding, frequent independent writes favour referencing.

5. Watch the 16 MB limit and unbounded growth.

6. Add indexes for the query patterns (Unit 5).
7. Add validation where consistency matters (§2.7).

Step 1 is the one people skip, and it is the one that determines the answer. You cannot design a MongoDB schema without knowing the queries; there is no "neutral" normalised form to fall back on.

2.6 Embedded versus referenced

{
  _id: 21,
  name: "Asha Kumari",
  address: { city: "Vijayawada", state: "AP", pin: "520010" },
  enrollments: [
    { course: "Data Science", grade: "A", credits: 4 },
    { course: "Statistics",   grade: "B", credits: 3 }
  ]
}

// students
{ _id: 21, name: "Asha Kumari", course_ids: [101, 102] }

// courses
{ _id: 101, title: "Data Science", credits: 4, instructor: "Dr. Rao" }
{ _id: 102, title: "Statistics",   credits: 3, instructor: "Dr. Devi" }

⚠️ The unbounded-array trap

This is the classic MongoDB design failure and it is worth a mark to name.

// WRONG -- comments grow without limit
{ _id: 1, title: "Post", comments: [ /* ...50,000 of them... */ ] }

Three things go wrong, and only the first is obvious:

1. The document eventually exceeds 16 MB and writes start failing.

2. Every read of the post drags all the comments over the network, even when you wanted the title.

3. Every write rewrites the whole document, and once it outgrows its allocated space it must be moved on disk, invalidating index entries.

The fix is the extended reference or subset pattern: embed the few you show, reference the rest.

{ _id: 1, title: "Post",
  commentCount: 50000,
  recentComments: [ /* the newest 5, for the preview */ ] }

// comments collection, one document each
{ _id: ..., post_id: 1, text: "...", author: "..." }

{ _id: 21, name: "Asha",
  address: { city: "Vijayawada", pin: "520010" } }

// one-to-few: embed
{ _id: 21, name: "Asha", phones: ["98765...", "98764..."] }

// one-to-squillions: the CHILD points at the parent
{ _id: 1, name: "Sensor A" }                        // devices
{ _id: ..., device_id: 1, at: ISODate(), value: 22.5 }   // readings

// Option A: array of ids on the student (query "which courses does X take?")
{ _id: 21, name: "Asha", course_ids: [101, 102] }

// Option B: both sides (fast both ways, TWO places to update)
{ _id: 101, title: "Data Science", student_ids: [21, 22, 23] }

// Option C: a separate enrolment collection -- Course 5's JUNCTION TABLE
{ _id: ..., student_id: 21, course_id: 101, grade: "A", enrolled: ISODate() }

2.7 Schema validation

Flexible does not have to mean unconstrained.

db.createCollection("students", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["roll", "name", "dept"],
      properties: {
        roll: { bsonType: "int", minimum: 1,
                description: "required integer roll number" },
        name: { bsonType: "string", minLength: 3, maxLength: 80 },
        dept: { enum: ["DS", "Stats", "CS"],
                description: "must be one of the three departments" },
        marks: {
          bsonType: "object",
          properties: {
            maths: { bsonType: "int", minimum: 0, maximum: 100 },
            stats: { bsonType: "int", minimum: 0, maximum: 100 }
          }
        },
        email: { bsonType: "string", pattern: "^[^@]+@[^@]+\\.[^@]{2,}$" }
      }
    }
  },
  validationLevel: "strict",       // "strict" | "moderate" | "off"
  validationAction: "error"        // "error" | "warn"
})

db.runCommand({ collMod: "students", validator: { /* ... */ } })   // add later

moderate plus warn is how you add validation to a live collection: start by logging violations, fix the existing data, then tighten to strict and error. Turning on strict validation over dirty data simply breaks the application.

Practice problems

// students
{ _id: 21,
  name: "Asha Kumari",
  dept: "DS",
  address: { city: "Vijayawada", state: "AP", pin: "520010" }   // EMBEDDED
}

// courses
{ _id: "DSC301",
  title: "Data Science with R",
  credits: 4,
  instructor: "Dr. Rao"
}

// enrollments -- the junction collection
{ _id: ObjectId(),
  student_id: 21,
  course_id: "DSC301",
  grade: "A",
  enrolled_on: ISODate("2026-07-01"),
  student_name: "Asha Kumari",     // DENORMALISED, for query 2
  course_title: "Data Science with R"
}

{ _id: 21, name: "Asha", enrollments: [ { course_id: "DSC301", grade: "A" } ] }

{ _id: 1, title: "Post", commentCount: 50000,
  recentComments: [ /* newest 5 */ ] }

db.createCollection("students", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["roll", "name", "dept"],
      additionalProperties: true,
      properties: {
        roll: { bsonType: "int", minimum: 1,
                description: "required int, >= 1" },
        name: { bsonType: "string", minLength: 3, maxLength: 80 },
        dept: { enum: ["DS", "Stats", "CS"],
                description: "must be DS, Stats or CS" },
        marks: {
          bsonType: "object",
          properties: {
            maths: { bsonType: "int", minimum: 0, maximum: 100 },
            stats: { bsonType: "int", minimum: 0, maximum: 100 }
          }
        },
        email: { bsonType: "string",
                 pattern: "^[^\\s@]+@[^\\s@]+\\.[^\\s@]{2,}$" }
      }
    }
  },
  validationLevel: "strict",
  validationAction: "error"
})

// 1. Attach the validator in the SAFEST mode: log, do not block.
db.runCommand({ collMod: "students",
                validator: { $jsonSchema: { /* as above */ } },
                validationLevel: "moderate",
                validationAction: "warn" })

// 2. FIND the offenders -- $nor + $jsonSchema inverts the match
db.students.find({ $nor: [ { $jsonSchema: { /* as above */ } } ] })

// 3. Fix them, then confirm the count is zero.

// 4. Tighten.
db.runCommand({ collMod: "students",
                validationLevel: "strict",
                validationAction: "error" })

Exam questions from this unit

Two marks

1. Give the MongoDB terms for database, table, row and column.
2. What is the maximum document size?
3. Distinguish embedded from referenced documents.
4. Why should money not be stored as a Double?
5. Distinguish null, a missing field and undefined.
6. Why does { field: null } match documents where the field is absent?
7. What is a capped collection?
8. Distinguish countDocuments() from estimatedDocumentCount().
9. What is the unbounded-array problem?
10. Distinguish validationLevel: "strict" from "moderate".

Five marks

1. Explain the MongoDB architecture with a diagram.
2. Explain MongoDB's data types with examples.
3. Explain the advantages and disadvantages of MongoDB over an RDBMS.
4. Explain database and collection management commands.
5. Explain schema design strategies in MongoDB.
6. Explain embedded and referenced models with the decision criteria.
7. Explain schema validation with JSON Schema.

Ten marks

1. Design a complete schema for a given application, justifying every embed and reference decision, and stating what you would watch.

2. Explain data modelling in MongoDB exhaustively — the three relationship types, embedding versus referencing, and the design patterns.

3. Compare relational and document data modelling with worked examples of the same system in both.

Mistakes that cost marks