07 NoSQL theory

NoSQL theory

← Index · Solutions

Priority key · Priorities guide emphasis; they do not remove taught scope.

Exam recall

Requirement → database feature → benefit → tradeoff. Choose using structure, relationships and workload; avoid universal claims about speed or transactions.

Why consider NoSQL? priority/high

A relational database organises data into tables with defined columns and relationships. That is useful when the structure is stable and records must be linked consistently. It can become less convenient when different records need different attributes, or a workload must be spread across many machines. NoSQL offers alternative data models and distribution designs for those needs.

The two controlling theory outcomes are 3.3.6: how NoSQL addresses SQL shortcomings and 3.3.7: applications of SQL and NoSQL. This chapter’s main task is therefore to explain a choice, not memorise a catalogue of products. NoSQL coding is outside your stated promo scope.

Exam-ready distinction

Choose the database from the structure of the data, the operations required and the consistency needs. “SQL is old; NoSQL is new” is not a justification.

Relational difficulty → NoSQL response priority/high

Requirement or difficulty	Relevant NoSQL feature	Why it helps	Tradeoff to recognise
Products have different, changing attributes	Flexible document structure	A shoe can have sizes while a book has an author; a new product field need not be added to every existing record.	The application must still check which fields exist and what they mean.
Data arrives in nested groups usually read together	Embedded documents/arrays	Related details can be retrieved with their parent document, reducing separate lookups for that access pattern.	Embedding the same fact in many documents makes updates harder to keep consistent.
Storage or request volume exceeds a convenient single-machine setup	Systems designed to partition data across machines	Distributing records/work can increase capacity and throughput as machines are added.	Choosing partition keys and coordinating cross-partition work introduces complexity.
Service should continue despite a machine failure	Replication in an appropriately configured distributed system	Another copy can serve data when a machine is unavailable.	Copies must be synchronised; the chosen system determines the consistency/availability behaviour.

These are reasons to consider a suitable NoSQL design. They do not mean relational databases cannot store varied data, replicate or scale across machines.

Applications: make the scenario do the work priority/high

Scenario	Reasoned choice
Bank transfers between accounts	A relational system is a natural fit for structured account records and transactions maintaining debit/credit integrity. Explain ACID rather than saying “banks use SQL”.
School enrolment and reports	SQL tables with keys and joins represent students, courses and enrolments, supporting consistent links and varied reports.
Rapidly changing product catalogue	A document database can represent different attribute sets and nested product details without forcing every product into an identical shape.
Very large stream of device records	A suitably distributed NoSQL system may partition high-volume writes; justify it with scale/access needs rather than claiming all NoSQL is faster.

A strong answer: identify a concrete requirement → name a relevant feature → explain the benefit for that requirement. Add a tradeoff when comparing or evaluating. One application can reasonably use different databases for different components.

Supporting vocabulary: data models priority/medium

NoSQL databases commonly use non-relational models and can suit flexible structures or distributed workloads. “Not only SQL” is a useful expansion, but the important point is the data model and access pattern. It does not mean no structure, no constraints, no querying or no transactions.

Model	Representation	Typical fit
Key–value	Unique key maps to a value	Retrieving session settings by session ID.
Document	Documents contain named fields, possibly nested objects/arrays	Product records with differing attributes.
Wide-column / column-family	Rows can hold varying columns organised in families	Large distributed datasets with appropriate key-based access patterns.
Graph	Nodes and edges represent entities and relationships	Traversing social connections or routes.

MongoDB is a document database. A collection holds documents; a document contains field–value pairs and an _id identifier. Documents in a collection can have different fields, though applications can impose a consistent structure and validation rules. Nested data can keep information used together in one document. MongoDB explicitly supports schema validation and multi-document transactions, counterexamples to the absolute claims in some older summaries.

{
  "_id": "P17",
  "name": "Trail shoes",
  "sizes": [38, 39, 40],
  "details": {"waterproof": true, "colour": "blue"}
}

This is a JSON-style illustration of a document, not MongoDB code to memorise. Your scope is theory.

Scaling and integrity: enough precision to avoid mistakes priority/medium

Relational tables provide explicit schemas, relationships and joins, with integrity constraints and transaction support. They suit strongly related records such as customers, orders and order lines. Document models can reduce the mismatch between an application’s nested objects and storage, and allow different record shapes. Embedding repeated facts can create update-consistency work.

Vertical scaling increases one machine’s resources. Horizontal scaling adds machines and distributes work/data. School comparisons often associate relational systems with vertical scaling and NoSQL with horizontal scaling. Treat these as common design tendencies: either family can have other scaling arrangements.

Schema flexibility is helpful when optional product attributes evolve; it also means validation and consistent interpretation must be managed. Distributed storage can improve capacity and availability but introduces coordination and consistency trade-offs. “NoSQL is faster” is incomplete: faster for which queries, data layout and workload?

Worked example — analyse a catalogue choice priority/high

A catalogue contains books with authors and page counts, shoes with sizes, and laptops with processor specifications. A document model can store each product’s relevant fields without forcing every product into the same set of columns. Product documents can embed small attributes usually read together. However, copying a supplier’s address into every product means a supplier change must update multiple documents or use a reference instead.

Analysis: the decisive fact is that books, shoes and laptops need different attributes. Nothing in the question establishes huge traffic, so “big data” would invent a reason. A document design addresses the stated variation. It should still validate essential fields such as product ID and price.

Exam-sized answer: a document database suits the catalogue because documents can hold different attributes for different product types. This accommodates evolving product details without requiring all products to share the same columns. Shared supplier facts should be referenced or updated consistently to avoid conflicting copies.

The four-model table is supporting recognition. Detailed product commands, deployment settings and shell syntax are lower-priority reference beyond this theory chapter. priority/low

Exam focus

The supplied syllabus and school NoSQL theory establish the topic even though no NoSQL question was identified in the four supplied HCI promos. Do not manufacture “commonly tested” evidence. The best preparation is to answer both stated outcomes directly.

Common mistakes

Saying SQL cannot store unstructured/varied information at all; saying NoSQL has no structure; choosing by dataset size alone; listing features without linking them to the scenario; and claiming no NoSQL product supports transactions.

Practice

07A — original, outcome 3.3.6. An online shop sells phones, books and clothing. Each category has different attributes and new categories are added regularly. Explain a difficulty of using one fixed table with a column for every possible attribute, and how a document database can address it. Give one remaining responsibility for the application.

07B — original, outcome 3.3.7. A school needs reliable student–course links and varied reports combining student, course and enrolment records. A separate service stores a growing stream of sensor readings and usually retrieves records for one sensor and time range. Recommend a suitable SQL/NoSQL approach for each, explaining a feature and its benefit. State why neither recommendation proves the alternative is impossible.

Hints

07A: identify the actual schema problem, then the feature that addresses it. 07B: use relationships/reporting for the first service and partitionable volume/access pattern for the second.

Revision checklist

• 07.1 Explain relational and non-relational data models without treating every NoSQL product as identical.
• 07.2 Recognise the NoSQL models covered by the school slides and associate each with suitable data.
• 07.3 Explain schema flexibility and its benefits and trade-offs.
• 07.4 Compare vertical and horizontal scaling as common approaches rather than universal restrictions.
• 07.5 Discuss integrity, transactions and querying with qualified, product-dependent statements.
• 07.6 Choose SQL or NoSQL for a scenario and justify using structure, relationships, consistency needs and workload.
• 07.7 Explain how NoSQL can address particular limitations of a relational design.
• 07.8 Recognise that NoSQL theory is required here; PyMongo implementation is outside the stated request for NoSQL theory.

Visual revision mindmap

Open this mindmap and its text version · All 21 mindmaps

Your mindmap framework

Centre: NoSQL theory. Build the six branches below. For each subbranch, add a short definition, a labelled sample and one exam trap from memory; then check the chapter.

flowchart LR
    C["07 • Revision map"]
    C --> B0["Start with the requirement"]
    C --> B1["Relational strengths"]
    C --> B2["NoSQL models"]
    C --> B3["Address a design difficulty"]
    C --> B4["Tradeoffs and vocabulary"]
    C --> B5["Visual checks and mistakes"]

• Start with the requirement

  • Shape of records and changing attributes.
  • Relationships and reporting needs.
  • Read/write patterns and volume.
  • Integrity, consistency and availability needs.

• Relational strengths

  • Tables and explicit schema.
  • Keys and relationships.
  • Joins for varied reports.
  • Transaction support for related updates.

• NoSQL models

  • Key–value: key lookup.
  • Document: fields, nested objects and arrays.
  • Wide-column: appropriate distributed keyed workloads.
  • Graph: nodes, edges and relationship traversal.

• Address a design difficulty

  • Varied product attributes → flexible documents.
  • Read nested details together → embedding.
  • Large workload → suitable partitioning.
  • Failure tolerance → suitably configured replication.

• Tradeoffs and vocabulary

  • Vertical: strengthen a machine; horizontal: add machines.
  • Flexible schema still needs validation.
  • Repeated embedded facts complicate updates.
  • Product-dependent transactions, querying and scaling.

• Visual checks and mistakes

  • Sketch book and shoe documents with different fields.
  • Map requirement → feature → benefit → remaining responsibility.
  • Compare enrolment, banking, catalogue and sensor workloads.
  • Avoid: NoSQL has no structure/transactions; always faster; SQL cannot scale.

Close the notes and test the map: explain one branch aloud, sketch its sample, then answer a linked practice question. Mark any missing link to revisit.

Source trail

9569 §§3.3.6–3.3.7; school Introduction to NoSQL slides; your NoSQL note.

No direct standalone NoSQL question found in the four HCI promotional question texts. Still explicitly in your current scope.

Source guide records provenance and original-paper locations.