One object, one document: the document model and how to design it

One order, four tables: why a document store

"Why document-based?" The slide (p. 291) gives three reasons — "Handles Schema Changes Well (easy development)", "Solves Impedance Mismatch problem", "Rise of JSON" — and draws the second one.

The impedance mismatch is the gap between the two shapes of Fig. 1: the program thinks in objects that contain lists and other objects, the relational database in flat rows linked by keys, so every read joins and every write takes the object apart (lesson 4 met it as the ORM problem). A document has the shape of the object, and it is read and written as one unit.

The first reason is change. A relational table fixes its columns; a document carries its own field names, so new documents can have one more field while the old ones keep working — "Dynamic schemas", says the overview slide (p. 293), with the data "stored in JSON-like documents". JSON, the third reason, is what web applications already exchange, so a document travels from the browser to the database almost unchanged.

Why is one document also fast? "MongoDB is fast and scalable" (p. 295) answers with a picture, "Better data locality". Its other two panels, in-memory caching and the distributed architecture, belong to lesson 16.

MongoDB belongs to the first of the four NoSQL families the deck opens with — "Document", "Graph", "Key-value", "Wide-column" (p. 286), compared in lesson 5. Of the nine tiles of its own pitch (p. 294), this lesson is about one: the "Rich data model".

A document stores an object the way the application uses it: one unit, one read, no join to rebuild it.

Database, collection, document, field — and the _id

The exercise session defines the containers in four sentences (p. 1416): "MongoDB is a document-oriented database that stores data within Collections of Documents. Documents consist of a set of key-value pairs, which are the basic unit of data in MongoDB. Collections contain sets of documents. Databases are made by one or more collections." Fig. 3 puts the next two slides together.

The lecture's own table (p. 297) has eight rows. Six only translate words. Two do more, and they are the subject of this lesson and of lesson 15:

Read the sixth row twice: the join is not replaced by a faster join but by a design decision — embed the related data or link to it (section 4).

A collection is a bag of documents (p. 302): the slide's three cards share their fields, but nothing forces them to. A field holds "Native data types", "Arrays" or "Other documents" (p. 303) — the last item, documents inside documents, is what makes embedding possible. Under the list, one rule: "Rule: Every document must have an _id."

The _id identifies the document in its collection. If you supply none, MongoDB creates an ObjectId (p. 1420): "The 12-byte ObjectId value consists of three different elements" — "A 4-byte timestamp value, representing the value creation, measured in seconds since the Unix epoch", "A 5-byte random value generated once per process", "A 3-byte incrementing counter, initialized to a random value". In the session's ObjectId("5ea64532a7678a3b27d34e00"), 24 hexadecimal digits for 12 bytes, 5ea64532 is the time, a7678a3b27 the random value, d34e00 the counter. The random part and the counter let two programs create ids at the same moment without asking anybody; the time in front keeps ids roughly in creation order. Other values work too: "First Post" on p. 309, integers on p. 312, the key "12345" on p. 1443.

The session's sample document (p. 1419) labels the kinds of value you will write in every design answer:

Keep the session's words: a sub-document is one embedded object, a sub-collection an array of sub-documents — what the papers mean by "Perform the query starting from the Chef Collection or Sub-Collection" (exam of 6 Sep 2024). The {"$date": …} is how tools display a BSON date; in an answer write ISODate("1986-03-01"). Dot notation reaches inside both (p. 1423): "address.city" names one value, "mobile_phone_numbers.service_provider" one value per element of the array — the main trap of lesson 14.

A document enters a collection with insertOne (p. 1421), and the _id is added for you:

// p. 1421: adds one document; MongoDB generates its _id
db.people_collection.insertOne({
   "name": {"first": "Mike", "last": "Ruby"},
   "age": 63
})

It comes back with find (every match), findOne (the first) or, as a number, countDocuments (p. 1424). The filter is itself a document, here with two dotted fields:

// p. 1424: returns every document whose name is Mark Jonhson
db.people_collection.find(
   {"name.first": "Mark", "name.last": "Jonhson"}
)

The same slides create an index (p. 1422) — fields with 1 for ascending or -1 for descending — and print its price: "Faster Queries and Improved Read Performance but Slower Writes and Increased Storage". Filters and indexes are lesson 14's.

// p. 1422: a compound index on three fields
db.people_collection.createIndex(
   {"name.last": -1, "name.first": 1, "age": 1}
)

JSON on the screen, BSON on the disk

"What is a document?" (p. 292) answers with a record from a business directory rather than with a definition:

// p. 292 (and p. 308): one business, one document
{
"business_id": "rncjoVoEFUJGCUoC1JgnUA",
"full_address": "8466 W Peoria Ave\nSte 6\nPeoria, AZ 85345",
"open": true,
"categories": ["Accountants", "Professional Services",
               "Tax Services"],
"city": "Peoria",
"review_count": 3,
"name": "Peoria Income Tax Service",
"neighborhoods": [],
"longitude": -112.241596,
"state": "AZ",
"stars": 5.0,
"latitude": 33.581867000000003,
"type": "business"
}

Read it as a list of types: strings, a boolean, an integer, floating-point numbers, an array of strings, an empty array ("neighborhoods": [] exists and holds nothing), newlines escaped inside a string. A document is typed, nested and self-describing: every value travels with its field name.

The JSON slide (p. 300) gives the syntax in five bullets: "Data is in name / value pairs", each pair "a field name followed by a colon, followed by a value", "Data is separated by commas", "Curly braces hold objects", "An array is stored in brackets []". Its last example, two Star Wars characters of which only R2-D2 has a race, is section 4's polymorphism in miniature.

MongoDB does not keep the text: "Data stored as BSON (Binary JSON)", "used for speed", "translation handled by language drivers" (p. 299). The BSON slide (p. 301) says what is inside: "Each entry consists of a field name, a data type, and a value", and "Files and large elements in a BSON document are prefixed with a length field to facilitate scanning". Fig. 4 encodes the first two fields of the document of p. 303, byte by byte.

The bytes explain the slide. A reader looking for age reads the type and name of the first field, finds the string's length, 4, and jumps over the value: that is "to facilitate scanning", and why BSON is "used for speed". The same slide says "Optimized for space and speed"; Fig. 4 shows that space is a goal, not a promise — speed is the sure gain. And every value has a type: "BSON types are a superset of JSON types (JSON does not have a date or a byte array type, for example), with one exception of not having a universal "number" type as JSON does." Where JSON has one number, BSON picks a 32-bit integer like the 26 above, a 64-bit integer or a double: the integer 1 and the double 1.0 are two BSON types, although a query compares them by value.

"Facts (1)" (p. 298) sets the ceiling: "Max docuement size of 16MB", "Larger documents handled with GridFS". The server counts 16 MB as 16,777,216 bytes and refuses a bigger insert ("object to insert too large"); GridFS stores files such as videos in chunks over several documents (background). For design, the cap warns against arrays that never stop growing.

The security slide (p. 296) adds "SSL" ("between client and server", "Intra-cluster communication") and "Authorization at the database level": "Read Only/Read+Write/Administrator". In January 2017 about 10,500 MongoDB databases open to the internet, with no administrator password, were wiped and held for ransom within days (BleepingComputer, 7 January 2017): authorization works only when it is switched on.

Embed or reference: the one design decision

The same user, two ways: on p. 304 one document with two "Embedded sub-document"s, contact and access; on p. 305 three documents — "Reference documents or linking documents" — where contact and access point back to the user through user_id, the user's _id.

An embedded document is read with its parent in one fetch and written with it in one operation. A reference is only a field holding another document's _id: MongoDB neither checks that the target exists, as a foreign key would, nor follows it in a find — the application sends a second query. It can sit on either side: on p. 305 each child holds its parent's id, on p. 1444 the parent holds an array of its children's ids, "orders": [ "order1", "order2" ]. The course notes warn that overusing references "would be just like recreating a relational database" (notes, 3.5.2).

"Designing NoSQL Data Structures" (p. 307) gives the method: "NoSQL data structures driven by application design", "Need to take into account necessary CRUD operations", "To embed or not to imbed. That is the question!", "Rule of thumb is to imbed whenever possible" — and, for whoever hoped for a recipe, "No modeling standards or CASE tools!" Design starts from what the application reads and writes. The deck shows three structures:

// p. 309: a post with its comments, one document
{
  "_id": "First Post",
  "comments": [
    {"author": "Bob", "text": "Nice Post!"},
    {"author": "Tom", "text": "Dislike!"}
  ],
  "comment_count": 2
}

// p. 310: two collections, post and comments
// db.post
{
  "_id": "First Post",
  "author": "Rick",
  "text": "This is my first post."
}
// db.comments
{
  "_id": ObjectId("..."),
  "post_id": "First Post",
  "author": "Bob",
  "text": "Nice Post!"
}

// p. 312: two kinds of document in one collection, nodes
// Page document
{
  _id: 1,
  title: "Welcome",
  url: "/",
  type: "page",
  text: "Welcome to my wonderful wiki."
}
// Photo document
{
  _id: 3,
  title: "Cool Photo",
  url: "/photo.jpg",
  type: "photo",
  content: Binary(...)
}

As a default the rule of thumb is right. Four situations — call them the four stop signs — make it a mistake:

1. Size and growth. An array that grows forever — sensor readings, a customer's orders — drifts towards the 16 MB of p. 298, and each new element rewrites a bigger document.
2. Duplication. Data embedded in many parents is copied into each; a change must find every copy.
3. Many-to-many. The shared side of an M:N relationship is such data: one product in thousands of orders.
4. Independent access. An entity read or updated on its own — a product page — needs its own collection.

The exercise session says it in two lines (p. 1444): "If related data is often queried together, embed it directly in the document"; "If related data is large or accessed independently, store references instead of embedding". The widget tests the four signs on the invoice of lesson 9.

Embed what is read together, stays bounded and belongs to one parent; reference what grows, is shared or is read on its own.

From ER diagram to documents: the session's recipe

The exercise session turns these principles into rules for the diagram every exam starts from (pp. 1443–1450). Entities first: "Entities become collections", "Each collection stores documents representing instances of the entity", and "Attributes of an entity are represented as fields within a document" (p. 1443):

// p. 1443: one entity, one collection
db.createCollection('user');
{
   "_id": "12345",
   "name": "John Doe",
   "email": "john.doe@example.com",
   "age": 30
}

Relationships change that. For a one-to-many, p. 1449: "Nest the entity on the N side inside the entity on the 1 side." and "You don't need to create a reverse link by nesting the 1-side entity inside each N-side document."

// p. 1449: the books (N side) inside their author (1 side)
{
   "_id": ObjectId("..."),
   "name": "J.K. Rowling",
   "books": [
      { "title": "Harry Potter and the Sorcerer's Stone",
        "year": 1997 },
      { "title": "Harry Potter and the Chamber of Secrets",
        "year": 1998 }
   ]
}

Which side is N? Read the pairs as lesson 6 taught (read it from the right side): the pair next to an entity counts the partners of one of its instances. Author (1,N) — Writes — (1,1) Book: an author writes one to many books, a book has exactly one author, so Book is the N side and the books go inside the author. For the papers: nest the entity next to (1,1) inside the entity next to (1,N).

For a many-to-many, p. 1450: "Modeled using reference IDs" — arrays of ids, on both sides in the slide's example — "Or separate linking collections":

// p. 1450: Student (M:N) Course with reference ids
db.createCollection('student');
{
   "_id": ObjectId("..."),
   "name": "Alice",
   "enrolledCourses": [ ObjectId("course1"), ObjectId("course2") ]
}
db.createCollection('course');
{
   "_id": ObjectId("course1"),
   "title": "Database Systems",
   "students": [ ObjectId("student1"), ObjectId("student2") ]
}

// p. 1450: the same relationship as a linking collection
db.createCollection('enrollment');
{
    "studentId": ObjectId("student1"),
    "courseId": ObjectId("course1"),
    "enrolledOn": "2025-09-01"
}

The linking document is the natural home of a relationship's own attribute: enrolledOn belongs to the pair (student, course), not to either side. The exam diagrams are full of them — Role on Works For, Since on Play, Production Date on Produce — and wherever the pair ends up, the attribute goes with it.

ISA hierarchies get one slide for each letter of the pair you met in lesson 6 (pp. 1445–1448). Total, "must be": "Only the child entities are converted into documents. Each child includes its own attributes plus inherited ones from the parent." Partial, "may be": "Both parent and child entities are transformed into documents." Exclusive, "not both": "Each child entity becomes a separate document." Overlapping, "also both": "A document may contain attributes from multiple child entities involved in the hierarchy." In all four the documents go into one collection, person — the polymorphic structure of p. 311. The other group's summary (p. 1469) adds, under partial, the case of a hierarchy nested inside another document: "These can be managed either with a single or multiple sub-collections when nested".

// after p. 1445 (total): only children, distinct _ids
db.createCollection('person');
// Instance of a student
{ "_id": "p1", "name": "John Doe", "fee": 1000 }
// Instance of a professor
{ "_id": "p2", "name": "Jane Roe", "salary": 1400 }

The exam's design question, solved

Every past paper opens its MongoDB exercise with a design question on a few entities of the ER diagram. Most papers of 2025 ask: "How many collections would you define within a documental database (clearly state it)? How would you implement the relations between the concepts? Provide a simple documental representation. (1 PT)" The exam of 11 Feb 2025 adds "specifying all attributes and their types or an example" and "Do not include any attributes besides the ones in the ER model", and leaves a blank: "NUMBER OF COLLECTIONS: ______ ← HERE!". The paper of 30 January 2026 rewords it and gives it 2 points: "How would you implement the nesting of the entities and the relationships between them? Provide a simple documental representation. Define ALL attributes and their types, and provide additional comments when needed. You must design the relationships without using the MongoDB $lookup operation."

$lookup is the aggregation stage that joins two collections. The practical lectures never teach it, and the ban spells out the consequence: every query runs on one collection, so each document must contain everything the queries read. Here is that paper, exercise 3, step by step.

The scenario: "a hospital heating management system". The entities asked are Hospital (Hospital_ID, Name), Building (Building_ID, Name, Year), Department (Department_ID, Specialty, N_Beds, Head_Physician_ID) and Person (P_ID, Email), related as in Fig. 6. The queries printed below the design ask, "for each hospital with more than 10 buildings, the number of departments with more than 25 people", and "the total number of departments each person with the role 'maintenance' works for".

1. Keep only the entities asked. Hospital, Building, Department, Person. Floor and the heating systems are on the diagram but not in the question: they stay out.

2. List their relationships with the pairs. Has Building and Has Dept. have 1:N next to Hospital and 1:1 next to Building and Department: one-to-many. Works For has 1:N on both sides: many-to-many, with Role.

3. Nest the N sides (p. 1449). Building and Department become the sub-collections buildings and departments of the hospital document, with no reverse link.

4. Place the many-to-many by the queries. The slide offers reference ids or a linking collection (p. 1450), but without $lookup a query on departments cannot reach people stored elsewhere. So each department carries its people, and Role goes inside each person entry, because it belongs to the pair.

5. Count and type. One collection, hospital. The ER key becomes _id; every attribute appears once, with its type.

6. Check against the queries. Buildings per hospital, people per department, the Role of each person entry: all inside one document, no join needed. (The pipelines are lesson 15's.)

// NUMBER OF COLLECTIONS: 1 (hospital)
db.createCollection('hospital');
{
  "_id": "H01",                    // Hospital_ID: String
  "Name": "Ospedale Nord",         // String
  "buildings": [                   // Has Building (1:N)
    { "Building_ID": "B01",        // String
      "Name": "Pavilion A",        // String
      "Year": 1968 }               // Integer
  ],
  "departments": [                 // Has Dept. (1:N)
    { "Department_ID": "D07",      // String
      "Specialty": "cardiology",   // String
      "N_Beds": 40,                // Integer
      "Head_Physician_ID": "P042", // String
      "people": [                  // Works For (M:N)
        { "P_ID": "P042",          // String
          "Email": "p042@nord.it", // String
          "Role": "head physician" // String, of Works For
        }
      ] }
  ]
}

The comments the paper asks for: Building and Department are nested because each belongs to one hospital; a person working for three departments appears three times, Email included — accepted, so that both queries run on one collection. A second collection person (P_ID, Email), with only P_ID and Role in the departments, would also work and store each Email once: say which you chose, and why. Both queries of the paper were run on this design on a real MongoDB server, without $lookup.

What a complete answer shows — our reading, since no solutions are published: the number of collections, stated; every ER attribute with its type, none invented; each relationship placed and named in a comment; the duplication acknowledged; documents on which the paper's queries run without $lookup.

Back to the hook. Storing the card is right when the pieces are read together, stay bounded and belong to this one order — true of the line items and the payment details, not of Ann, who orders for years, nor of the products, each in thousands of orders. That is why the slide's rule stops at "whenever possible": "to embed or not to imbed" is answered per relationship, by the four stop signs. With $lookup banned it becomes the exam's question: no query may join, so you nest along the queries and copy, with a comment, what a many-to-many shares.