Non-Relational Database Concepts

Introduction to Non-Relational Databases

A non-relational database, often grouped under the term NoSQL, stores and retrieves data using structures other than—or more flexible than—the traditional fixed relational table model.

Core idea

The data model is selected around the shape of the data and how an application needs to read, write, connect, and scale it. Different NoSQL families solve different kinds of problems.

Flexible Structure

Records do not always need an identical set of fields.

Scale-Out Design

Many systems are designed to distribute data and workload across multiple nodes.

Access-Pattern Focus

Data is often organized around common application queries.

Multiple Models

Key-value, document, column-family, and graph are major families.

Major Non-Relational Models

The four models below organize information differently. The correct model depends on what the application needs to retrieve and how the data is connected.

Key-Value

Key → Value. Direct lookup using a unique key.

Fast lookup

Document

Stores self-contained JSON-like documents with fields, arrays, and nested objects.

Flexible schema

Column-Family

Organizes data around rows/keys and related groups of columns.

Wide / sparse data

Graph

Represents entities as nodes and their connections as relationships or edges.

Connected data

Lookup by ID
Key-Value

→

Rich object
Document

→

Grouped columns
Column-Family

→

Relationships
Graph

Key-Value Databases — JSON Values

A key-value database associates a unique key with a value. Here the value is represented as JSON so one lookup can return a structured student object.

Key

"student:1002"

The key acts like the lookup address.

JSON Value

{
  "studentId": 1002,
  "name": "Hafiz Iskandar",
  "program": "Data Analytics",
  "courses": ["C101","C205"]
}

Visual — Key → JSON Value

Typical idea

When the application already knows the key, it can retrieve the associated value directly. This pattern is useful for cache entries, sessions, preferences, and other identifier-based access.

Document Databases

A document database stores a complete logical object as a document. JSON-style documents can contain scalar fields, arrays, and nested objects.

Student Document

{
  "_id": "student-1002",
  "studentId": 1002,
  "name": "Hafiz Iskandar",
  "program": {
    "code": "DA",
    "name": "Data Analytics"
  },
  "courses": [
    {"courseId":"C101","name":"Database Fundamentals"},
    {"courseId":"C205","name":"Data Management"}
  ]
}

Embedded Data

Program and course details can be placed inside the student document when that structure matches the application's access pattern.

Flexible Fields

Another student document can contain an additional field without requiring every document to have that field.

Document Identity

Each document normally has an identifier used to locate or update it.

Column-Family Databases

Column-family systems organize data around keys and groups of related columns. The JSON below is a simplified teaching illustration that groups student attribute values by column.

Students — Column-Oriented JSON Illustration

{
  "studentid": [1001, 1002, 1003, 1004, 1005, 1006],
  "studentname": [
    "Alya Rahman", "Hafiz Iskandar", "Siti Amira",
    "Kumar Naidu", "Nur Iman", "Daniel Lee"
  ],
  "program": [
    "Computer Science", "Data Analytics", "Business",
    "Engineering", "Data Analytics", "Computer Science"
  ],
  "year": [1, 2, 2, 3, 1, 3],
  "cgpa": [3.72, 3.85, 3.54, 3.68, 3.91, 3.60],
  "advisor": [
    "Dr. Lim", "Dr. Farah", "Dr. Wong",
    "Dr. Kumar", "Dr. Farah", "Dr. Lim"
  ]
}

Column	Example grouped values
studentid	[1001, 1002, 1003, 1004, 1005, 1006]
program	["Computer Science", "Data Analytics", "Business", …]
cgpa	[3.72, 3.85, 3.54, 3.68, 3.91, 3.60]

Read Position 1

studentid   → 1002
studentname → "Hafiz Iskandar"
program     → "Data Analytics"
year        → 2
cgpa        → 3.85
advisor     → "Dr. Farah"

Teaching Note

The parallel arrays are a visual teaching device for grouping values by attribute. Real column-family products use their own row-key, column-family, partition, and storage structures rather than this literal JSON layout.

Graph Databases

A graph database emphasizes connections. Nodes represent entities such as students and courses; edges represent relationships such as ENROLLED_IN.

Interactive Student–Course Graph

Select a student to highlight that student's relationships.

All student-course relationships are visible.

Scaling, Partitioning & Replication

Many non-relational systems are designed for distributed operation. Three important ideas are horizontal scaling, partitioning, and replication.

Horizontal Scaling

Add more machines or nodes so workload can be distributed instead of relying only on a larger single server.

Partitioning / Sharding

Divide a dataset into partitions and place different partitions on different nodes.

Replication

Maintain copies of data on multiple nodes to improve availability, resilience, or read capacity.

Distributed Data Illustration

Denormalization & Consistency

Non-relational designs often make deliberate trade-offs. Related data may be duplicated to make common reads simpler, while distributed systems may offer different consistency choices.

Denormalization

Store related information together—even when some values repeat—when doing so supports important access patterns and reduces multi-record lookups.

Strong Consistency

Applications expect reads to reflect the required latest committed state according to the system's consistency guarantees.

Eventual Consistency

Replicas may temporarily contain different versions, but updates are expected to propagate so replicas converge.

Design trade-off

There is no single NoSQL structure that is best for every application. Data shape, query patterns, relationship depth, write volume, scale, availability requirements, and consistency needs all influence the design.

Non-Relational Database Summary

Connect each model to the problem it is designed to make easier.

Key-Value

Key → value. Best understood as direct lookup by a known identifier.

Document

ID → structured document. Useful for rich objects with flexible or nested fields.

Column-Family

Row key → grouped columns. Useful for large, distributed, sparse, or wide datasets.

Graph

Nodes → edges → nodes. Useful when relationships and traversals are central.

Concept chain

Data shape → access pattern → model choice → partition strategy → replication strategy → consistency choice. The database design should follow the application's actual requirements.