NoSQL Databases — Revision Notes
NoSQL Databases
Revision Notes — Tuto #6
1. The Relational Model — Quick Recap
1.1 Core Concepts
• Data is organized in tables (relations), rows (tuples), and columns (attributes).
• Each table has a primary key (PK) — a unique identifier for each row.
• Relationships between tables are represented using foreign keys (FK).
1.2 E/R Diagram Notation
An Entity-Relationship diagram captures entities, their attributes, and the relationships between
them. You need to know:
• Entity: Entities → become tables.
• Attribute: Attributes → become columns.
• Relationship: Relationships (1:1, 1:N, M:N) → may become join tables.
📝 In the tutorial, Author writes Book (1:N), Book appears in Sale (1:N). A sale concerns
one book; a book can appear in many sales.
1.3 Sample Schema (Books Database)
Three tables:
Table Columns PK FK
Author id_author, last_name, id_author —
first_name
Book isbn, title, id_author isbn id_author → Author
Sale id_sale, date, isbn id_sale isbn → Book
2. Why NoSQL? — Motivation & Context
• Relational databases require a fixed schema and rely on JOIN operations.
• NoSQL databases trade some consistency guarantees for flexibility, scalability, and
performance on specific access patterns.
• The choice of NoSQL model should be driven by the use case (how data is queried), not
just how it is stored.
There are four major NoSQL families:
Model Core Idea Best for
Key-Value Store/retrieve a value by a Fast lookups of full records
unique key
ENSIA — ISE Department | Semester 2 – 2025/2026 | Page 1
NoSQL Databases — Revision Notes
Model Core Idea Best for
Column-oriented Group columns by families; Queries filtering/aggregating
rows share row-key columns
Document Store semi-structured Flexible, nested, self-describing
documents (JSON/BSON) data
Graph Nodes and edges Highly connected data (social,
representing relationships routes)
3. Key-Value Model
3.1 Principle
• Every record = one (key, value) pair.
• The key uniquely identifies the record.
• The value is opaque — a blob, string, or serialized object.
• Retrieval is only possible by key. No querying on field values inside the value.
3.2 Structure
Key → Value
─────────────────────────────────────────────────────
isbn:2154889522 → {title:'Asterix et Cléopâtre', author_id:154, ...}
isbn:2154889589 → {title:'NoSQL', author_id:987, ...}
3.3 Use Case Fit
• Perfect when: you always know the key and need the full object.
• Poor when: you need to search by a value inside the record (e.g., find all books by an
author).
📝 Exercise 1 Q2: model books with isbn as the key — each key gives all book details.
4. Column-Oriented Model
4.1 Principle
Also called wide-column or column-family stores (e.g., Cassandra, HBase).
• Data is organized in column families.
• Each row is identified by a row key.
• Columns can vary per row — no strict schema.
• Efficient for reading/writing specific columns across many rows.
4.2 Structure
Row key (last_name) | cf:first_name | cf:isbn | cf:title
────────────────────────────────────────────────────────────────────────
Bruchez | Rudi | 2154889589 | NoSQL
ENSIA — ISE Department | Semester 2 – 2025/2026 | Page 2
NoSQL Databases — Revision Notes
Gosciny | René | 2154889522 | Asterix et
Cléopâtre
4.3 Use Case Fit
• Perfect when: searching by a specific attribute (e.g., last name) across all records.
• The row key should be chosen as the most common search criterion.
📝 Exercise 1 Q3: use last_name as the row key to find all books of a given author.
5. Document-Oriented Model
5.1 Principle
• Each record is a self-contained document (usually JSON or BSON).
• Documents can be nested and have variable structure.
• A collection groups related documents (like a table, but schema-free).
5.2 Embedding vs. Referencing
The key design decision is: should related data be embedded inside the document, or
referenced by ID?
Strategy Description Pro Con
Embedding Include sub-document(s) Single-read Data duplication;
directly inside parent doc access, no JOIN updates harder
Referencing Store only the ID of the Less duplication Requires multiple reads
related document (like a JOIN)
5.3 Modeling Perspectives — Same Data, Different Focus
The same data can be modeled from different angles. The choice affects which queries are
fast.
Sale-centered document
{
"_id": "sale:10",
"date": "02/06/2017",
"book": {
"isbn": "2154889522",
"title": "Asterix et Cléopâtre",
"author": { "id": 154, "last_name": "Gosciny", "first_name": "René" }
}
}
Book-centered document
{
"_id": "2154889522",
"title": "Asterix et Cléopâtre",
ENSIA — ISE Department | Semester 2 – 2025/2026 | Page 3
NoSQL Databases — Revision Notes
"author": { "id": 154, "last_name": "Gosciny", "first_name": "René" },
"sales": [
{ "id_sale": 10, "date": "02/06/2017" }
]
}
Author-centered document
{
"_id": 154,
"last_name": "Gosciny",
"first_name": "René",
"books": [
{ "isbn": "2154889522", "title": "Asterix et Cléopâtre" }
]
}
5.4 Impact on Queries
• Sale-centered: easy to get all details of a sale in one read. Hard to find all sales of a
given author (must scan all documents).
• Book-centered: easy to get book info + its sales. Hard to list all books by an author
without scanning.
• Author-centered: easy to list books by author. Hard to find sale history without
navigating to each book.
📝 Rule of thumb: organize documents around the entity that is most often the starting
point of queries.
6. From Document Back to Relational
6.1 Reverse-Engineering a Schema from JSON Documents
Given a set of JSON documents, reconstruct the relational schema by:
• Identifying top-level fields → candidate columns or related entities.
• Identifying arrays of sub-objects → likely a separate table with a FK back to the parent.
• Identifying repeated sub-objects across documents → likely a shared lookup table.
6.2 Example: Student Documents
{
"_id": 978,
"Name": "ADIMI Meriem",
"TU": [
{"id": "ue:11", "title": "Java", "grade": 12},
{"id": "ue:27", "title": "Bases de données", "grade": 17},
{"id": "ue:37", "title": "Réseaux", "grade": 14}
]
}
Reconstructed relational schema:
Table Columns
Student id_student (PK), name
ENSIA — ISE Department | Semester 2 – 2025/2026 | Page 4
NoSQL Databases — Revision Notes
Table Columns
TeachingUnit (TU) id_tu (PK), title
Enrollment id_student (FK), id_tu (FK), grade ← Junction table
Data extracted from the documents:
Student table id_student name
978 ADIMI Meriem
476 BELABDI Ahmed
TU table id_tu title
ue:11 Java
ue:27 Bases de données
ue:37 Réseaux
ue:13 Méthodologie
ue:76 Conduite projet
Enrollment id_student id_tu grade
978 ue:11 12
978 ue:27 17
978 ue:37 14
476 ue:13 17
476 ue:27 10
476 ue:76 11
6.3 TU-centered Representation
Instead of student-centered documents, we can pivot to TU-centered documents:
{
"_id": "ue:27",
"title": "Bases de données",
"enrollments": [
{ "student_id": 978, "name": "ADIMI Meriem", "grade": 17 },
{ "student_id": 476, "name": "BELABDI Ahmed", "grade": 10 }
]
}
7. Managing Many-to-Many Relationships
7.1 In the Relational Model
ENSIA — ISE Department | Semester 2 – 2025/2026 | Page 5
NoSQL Databases — Revision Notes
• A many-to-many (M:N) relationship requires a junction (association) table.
• Example — Multiple authors per book: add a Book_Author(isbn, id_author) table and
remove id_author from Book.
7.2 In a Document Model
• Embedding: add an 'authors' array inside the book document. Simple to read; duplicates
author details.
• Referencing: store only author IDs in the array; fetch author documents separately.
• Mixed: embed minimal info (id + name) and reference for full details.
// Multiple authors — embedding
{
"isbn": "...",
"title": "...",
"authors": [
{ "id": 154, "last_name": "Gosciny", "first_name": "René" },
{ "id": 201, "last_name": "Uderzo", "first_name": "Albert" }
]
}
8. Modeling Courses & Students (Exercise 3
Prerequisites)
8.1 Entities & Relationships
• Course: code, title, description, credits, prerequisites (other courses → self-referencing).
• Student: last_name, first_name, address (street_number, street_name, city,
postal_code).
• A student follows many courses; a course is followed by many students → M:N
relationship.
8.2 Address as Embedded Sub-document
Addresses are a natural candidate for embedding — they belong to exactly one student and are
always accessed together with the student record:
"address": {
"street_number": "12",
"street_name": "Rue Didouche Mourad",
"city": "Alger",
"postal_code": "16000"
}
8.3 Self-referencing — Prerequisites
A course can have other courses as prerequisites. In a document model this can be:
• An array of course codes (references): simple, but requires extra reads.
• An array of embedded course objects: fast to read but risks deep nesting.
8.4 Hybrid Modeling for the Use Case (Q3)
When the application shows a student list with course codes/titles and only fetches full details
on demand:
ENSIA — ISE Department | Semester 2 – 2025/2026 | Page 6
NoSQL Databases — Revision Notes
• Student document: embed minimal course info (code + title only).
• Course document: separate collection with full details.
• Fetching a student list → one read of student collection. Selecting a course → one read
of course collection by code.
// Student document (partial course info only)
{
"_id": "S001",
"last_name": "Adimi",
"first_name": "Meriem",
"address": { "city": "Alger", "postal_code": "16000", ... },
"courses": [
{ "code": "CS101", "title": "Java" },
{ "code": "CS205", "title": "Bases de données" }
]
}
// Course document (full details)
{
"_id": "CS205",
"title": "Bases de données",
"description": "Introduction to relational and NoSQL databases",
"credits": 3,
"prerequisites": ["CS101"]
}
9. Summary — Choosing the Right NoSQL Model
Question to ask Guidance
What is the main query? Choose the entity that is the starting point as your
document focus or row key.
Is the data always accessed Embed it. Otherwise, use references.
together?
Does data repeat across Consider referencing to avoid update anomalies.
documents?
Is the relationship M:N? Use an array of IDs (references) or a junction
collection.
Do you need to search by a field Key-value is not enough — use column or document
value? model.
Is the data highly Document model suits it well.
hierarchical/nested?
Good luck with the exercises!
ENSIA — ISE Department | Semester 2 – 2025/2026 | Page 7