ISYS1055 Chap.13 NoSQL Document Modelling with MongoDB: Schema-Free Design
NoSQL Document Modelling with MongoDB: Schema-Free Design
Week 11 is the advanced topic, and its outcomes are to learn the limitations of the relational database model, explore the document database model and the structure of a database record, learn how to use MongoDB, and write simple queries to extract data from it. The motivating case is deliberately small: a table whose schema was fixed before a new requirement existed, and one row that now needs a field the schema has no room for - a relational schema must be defined before data can be added, whereas a document database allows insertion with no predefined schema and delegates validation to the application. Because MongoDB is not available on the School's servers, all lab and assignment activity for this week runs on the MongoDB Atlas free tier, browsed with MongoDB Compass. Week 11 also carries the final quiz, which the course states is cumulative over the previous ten weeks.
What this chapter covers
- 01Why the relational model is under pressure: fixed schemas, costly joins, limited data structures and difficulty scaling - against the advantages of normalised data and comprehensive querying
- 02Three relational workarounds and their costs: denormalisation (faster reads, data anomalies), sharding (better read and write throughput, more complex to manage), replication (faster reads, risk of inconsistency between copies)
- 03NoSQL defined - storage and retrieval of data modelled by means other than tables, read as "not only SQL" - with the document store as the one family this course explores
- 04The three levels of the document model - a database of collections, a collection of JSON documents, a document as a set of key-value pairs - and the vocabulary bridge from table to collection, row to document, column to field and primary key to the _id field
- 05The four properties that separate it from the relational model: no schema required, arrays allowed as values, composite objects allowed, and nesting to any depth
- 06Embedding versus referencing: nesting related data inside a document (a denormalised model) versus storing document IDs as the equivalent of foreign keys
- 07The find() signature - a query document and a projection document - with the comparison operators $gt, $gte, $lt, $lte, $ne, $in, $all, $or and $regex, dotted paths for nested fields, .sort() and .count()
- 08Tooling: a cluster on the Atlas free tier plus MongoDB Compass, whose FILTER, PROJECT and SORT boxes map directly onto the shell arguments
Translate one SQL query into a MongoDB find, then decide what to embed and what to reference
- +1(a) Map the vocabulary first: the table becomes the collection, each row a document, each column a field. The find() call takes two documents - the query, which plays the role of the WHERE clause, and the projection, which plays the role of the SELECT list. Several conditions in one query document are combined with AND by default, so no operator is needed for that.
- +1(a) continued: write it out. db.venues.find( { "address.suburb": "Brunswick", capacity: { $gt: 200, $lte: 800 } }, { venue_name: 1, capacity: 1, _id: 0 } ) - the nested field is reached by a dotted path in double quotes, the range uses $gt and $lte in one operator object on the same field, and _id: 0 suppresses the identifier that would otherwise be returned automatically.
- +1(b) Sorting and counting are chained onto the cursor rather than written inside the query document: .sort({ capacity: -1 }) orders descending, where 1 would be ascending, and .count() returns how many documents matched. So the full call is db.venues.find(
, ).sort({ capacity: -1 }), and the count is db.venues.find( ).count(). - +1(c) Reviews should be referenced, not embedded. Embedding suits child data that is read together with its parent, is bounded in size and does not change on its own; referencing suits child data that is large, unbounded, shared, or updated independently. Thousands of reviews per venue is unbounded growth inside a single document, and reviews arrive independently of any change to the venue, so store them as their own documents and keep their identifiers - the document model's equivalent of foreign keys - on the venue. By contrast the address belongs inside the venue document: it is one small object, always read with the venue, and never shared.
Key terms
- NoSQL
- A database providing storage and retrieval of data modelled by means other than tables - originally "non SQL", now usually read as "not only SQL". The course notes that "non-relational" would have been the more accurate collective name, and explores exactly one family: the document store.
- Document and collection
- The three levels of the document model: a document database holds one or more collections, a collection holds one or more JSON documents, and a document is a set of key-value pairs. The vocabulary maps onto the relational one as table to collection, row to document, column to field, primary key to the _id field.
- Schema-free (dynamic schema)
- The property that a document may be inserted without a schema having been defined first, so each document may carry its own structure. Validation moves out of the database and into the application, which suits agile development and relaxes the guarantees the relational model enforces.
- Embedding
- Nesting related data inside a single document - a host object inside a listing, or an array of review objects. These are denormalised models, and they suit child data that is read with its parent, bounded in size and not updated independently.
- Referencing
- Relating documents by storing document identifiers, the document model's equivalent of foreign keys. It corresponds to normalised relations and suits child data that is large, unbounded, shared between parents or updated on its own.
- find(query, projection)
- The read operation. The first document holds the conditions and plays the role of the WHERE clause; the second selects the fields to return and plays the role of the SELECT list. Leave the query empty to match everything, and use the comparison operators $gt, $gte, $lt, $lte, $ne, $in, $all, $or and $regex inside it.
NoSQL Document Modelling with MongoDB: Schema-Free Design FAQ
When is a document database the right choice, and when is it not?
It suits data whose shape genuinely varies between records, data that is read as a whole rather than joined together, and applications whose schema is still moving - which is why the course frames it around agile development. It is a poor choice where the value of the data lies in guaranteed consistency across many related records, because the model relaxes ACID guarantees and delegates validation to the application. This is the Week 11 reflection question, and the honest answer names one application of each kind.
How does MongoDB relate to what I learned about normalisation?
It inverts the default. Normalisation removes redundancy so that each fact is stored once; the document model embeds related data on purpose, which is a denormalised design, and accepts the anomalies that come with it in exchange for reading a whole record in one operation. The trade-off is the same one the course raises when discussing denormalisation in a relational setting - integrity is then maintained somewhere else, in the application layer or through validation rules.
Do I need to install MongoDB on my own machine?
No. MongoDB is not available on the School's servers, and the course runs all lab and assignment activity on the MongoDB Atlas free tier instead, with MongoDB Compass as the desktop client. Register with your student email address; Atlas is a third-party service and does not use RMIT single sign-on, so do not reuse your RMIT password. Load the sample dataset into your cluster before the practical, since every example query needs data to run against.
What is the difference between embedding and referencing?
Embedding puts the related data inside the parent document, so one read returns everything and there is no join to write; referencing stores the related document's identifier instead, exactly as a foreign key does. Embed when the child is small, bounded, read with the parent and not shared; reference when it is large, unbounded, shared between parents, or updated independently of the parent.
Assessment move
Set up the environment before the practical rather than during it: create an Atlas account with your student email, deploy a free-tier cluster, install Compass and load the sample dataset. Then work the translation table in both directions - given a SQL query write the find, and given a find write the SQL - because that pairing is how the lecture teaches the material and how it can be asked. Use Compass's FILTER, PROJECT and SORT boxes deliberately, noticing that each one is simply an argument you could have typed in the shell. Finally, take one relational design you already built this semester and redesign it as documents, writing down for each relationship whether you would embed or reference and why; that is the Week 11 reflection task and the best possible revision for the cumulative quiz, which the course states covers the previous ten weeks.
Working through NoSQL Document Modelling with MongoDB: Schema-Free Design in ISYS1055? Sia is AskSia’s AI Information Technology tutor — ask any ISYS1055 NoSQL Document Modelling with MongoDB: Schema-Free Design question and get a clear, step-by-step explanation grounded in how ISYS1055 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
