Data Models — Hierarchical, Network, Relational, Object & NoSQL
ডেটা মডেল — Hierarchical থেকে NoSQL পর্যন্ত
1. What Is a Data Model?
A data model is a way of thinking about data: what shape does it have, how do pieces relate to each other, and what operations make sense on it? Choosing a data model is the most consequential decision in any system design — much more than choosing a programming language. Five big families of models exist, each born from a real engineering pain.
In this module we walk through them in roughly the order history invented them: hierarchical, network, relational, object/object-relational, and the NoSQL family (document, key-value, wide-column, graph). We will end with a practical guide on how to choose for a Bangladeshi project.
2. Hierarchical Model — Data as a Tree
The first commercial DBMS, IBM's IMS, used a tree. There is one root, every other record has exactly one parent, and you navigate by following parent-to-child links. It is exactly how a Unix filesystem looks today, or how XML and JSON nest.
Pros: very fast lookups along the tree. Cons: a student who attends two departments cannot be expressed cleanly — he would need to be duplicated. Modern descendants are JSON documents in MongoDB and XML in legacy systems.
3. Network Model — Records Connected by Pointers
Charles Bachman's IDS generalised the tree to a graph: any record can be linked to any other through manually-maintained "sets" (essentially pointers). The CODASYL committee standardised this into a model that ran most banks in the 1970s.
Pros: many-to-many natural; richer than a tree. Cons: programs become tangled — a query is a navigation through pointers, and changing the schema means rewriting every navigation. Modern descendants are graph databases like Neo4j, which keep the idea but add a query language (Cypher) so you do not have to chase pointers by hand.
4. Relational Model — The One We Will Master
Codd's relational model says: forget pointers, forget trees. Everything is a table (a relation), every row is a tuple, every column is an attribute. Relationships are expressed by matching values, not by physical pointers. This indirection is the entire reason SQL is so flexible.
-- Same university, relational style: TWO flat tables, joined by value
SELECT s.name, s.cgpa, d.name AS dept
FROM student s
JOIN department d ON d.did = s.did
ORDER BY s.cgpa DESC;
Notice: there is no pointer from a student to a department. Instead, both tables share a value
(did). Adding a new department is one INSERT, dropping one is one DELETE — the rest of the
schema is unaffected. This is the magic.
JOIN)। কোনো pointer নেই, তাই schema পাল্টানো সহজ।
Pros: declarative SQL, mathematically grounded, mature, ACID. Cons: not natural for deeply-nested data
(every JOIN is paid for at query time), schema is rigid by default. Modern relational systems
we will use throughout this course: SQLite, PostgreSQL, MySQL, Oracle, SQL Server.
5. Object-Oriented & Object-Relational Models
In the late 1980s, as Java and C++ took over application development, programmers complained: "My code has objects, my database has rows. Mapping between them is a pain." Two answers appeared:
- Object-Oriented DBMS (OODBMS) — store entire program objects directly. Examples: ObjectStore, db4o. Niche today.
- Object-Relational DBMS (ORDBMS) — keep tables, but allow rich types: arrays, JSON, custom user-defined types, even inheritance. PostgreSQL is the gold standard here.
Below is an object-relational flavour: storing an array directly inside a column. SQLite supports JSON arrays natively — almost every modern relational DBMS does too.
-- Each product carries a JSON array of tags — an object-style column
SELECT name,
json_array_length(tags) AS tag_count,
tags
FROM product;6. The NoSQL Family — Four Different Animals
"NoSQL" is a marketing label, not a single technology. It actually covers four very different families, each invented to solve a problem the relational model handles awkwardly at scale.
| Family | Shape of data | Example DB | Best for | বাংলায় |
|---|---|---|---|---|
| Document | JSON-like documents grouped into collections. | MongoDB, Couchbase | Variable schemas; nested data; product catalogs. | JSON document — schema নমনীয়। |
| Key-Value | Hash map: a key → an opaque value. | Redis, DynamoDB | Sessions, caches, leaderboards. | Key থেকে value — দ্রুত cache। |
| Wide-Column | Sparse table: rows can have different columns. | Cassandra, HBase, ScyllaDB | Time-series, telemetry, write-heavy at scale. | প্রতিটি row-এর কলাম আলাদা — বড় scale-এর জন্য। |
| Graph | Nodes & edges with properties. | Neo4j, JanusGraph | Social networks, fraud rings, recommendation. | Node-edge — সম্পর্ক-প্রধান data। |
In 2026, the world's biggest fintechs (Stripe, bKash, Visa) all run on relational databases. NoSQL is excellent for specific workloads — caching, social graphs, write-heavy logs — but for transactions where money cannot be lost, ACID-compliant SQL still wins. Most production stacks use both.
NoSQL SQL-কে সরিয়ে দেয়নি। আজ Stripe, bKash, Visa — সবই relational। NoSQL ভালো কাজ করে cache, log, social graph-এ। বেশিরভাগ production stack-এই দুটোই ব্যবহার হয়।
Even SQLite can simulate a key-value store with two columns. Run this to feel how a "document" lives in a relational table — the same idea as MongoDB, just SQL syntax:
-- Look up just like Redis: GET key
SELECT v FROM kv WHERE k = 'user:101';
-- Or scan a "namespace" prefix, like Redis SCAN
SELECT k, json_extract(v, '$.city') AS city
FROM kv
WHERE k LIKE 'user:%';7. How to Choose — A Practical Guide
Here is a decision tree we actually use in industry. For 90% of Bangladeshi projects — startup, government, e-commerce, fintech — the answer ends at "Postgres or MySQL."
✅ Default to relational when
- You need ACID — money, orders, NID, healthcare.
- The schema will live for years.
- Reports and analytics matter (SQL is unbeatable here).
- Your team already knows SQL — almost everyone does.
⚠️ Reach for NoSQL only when
- You have a specific scale problem relational cannot meet.
- The data is genuinely schemaless (logs, telemetry, raw events).
- You need a cache or queue (Redis) — most apps do.
- Your problem is graph-shaped (recommendations, fraud rings).
8. Glossary (শব্দকোষ)
| Term | Meaning | বাংলায় |
|---|---|---|
| Data model | A way of describing the shape and meaning of data. | Data-র আকার ও অর্থ ব্যাখ্যার একটি পদ্ধতি। |
| Hierarchical | Tree-shaped; one parent per record. | গাছ আকার; প্রতি record-এর এক parent। |
| Network (CODASYL) | Graph of records connected by pointers. | Pointer-জোড়া graph। |
| Relational | Flat tables joined by matching values. | Flat টেবিল; value-মিলিয়ে JOIN। |
| Object-relational | Tables enriched with rich types and JSON. | Table + JSON/array/custom type। |
| Document DB | Stores schema-less JSON documents. | Schema-less JSON document store। |
| Key-value DB | Hash map persisted to disk. | Disk-এ persisted hash map। |
| Wide-column DB | Sparse, write-optimised table. | Sparse, write-অপ্টিমাইজড টেবিল। |
| Graph DB | Nodes-and-edges-first storage. | Node-edge ভিত্তিক storage। |
9. Practice Problems
Try, then click Show Answer. Several answers contain runnable SQL.
-
For each scenario pick a model: (a) hospital prescription history, (b) Facebook friend graph, (c) IoT sensor data from 50,000 farms, (d) Daraz product catalog with variable attributes.প্রতিটির জন্য মডেল বাছুন: (ক) hospital prescription, (খ) Facebook friend graph, (গ) ৫০,০০০ farm-এর IoT sensor data, (ঘ) variable attribute সহ Daraz catalog।
✨ Show Answer
Answer: (a) Relational — ACID and reporting matter. (b) Graph — friends-of-friends queries. (c) Wide-column / time-series — Cassandra or TimescaleDB. (d) Document — MongoDB or a relational DB with a JSON column.
(ক) Relational; (খ) Graph (Neo4j); (গ) Wide-column / time-series; (ঘ) Document বা relational + JSON column।
-
Build a relational mini-schema for "library books and borrowers" and find every overdue book."Library book ও borrower"-এর জন্য relational schema বানান এবং প্রতিটি overdue book বের করুন।
✨ Show Answer
ans2.sqlSELECT b.title, u.name, b.due FROM book b JOIN borrower u ON u.uid = b.uid WHERE b.due < '2025-05-10' ORDER BY b.due; -
Why is the network model considered hard to maintain compared to relational?Relational-এর তুলনায় network model maintain করা কেন কঠিন?
✨ Show Answer
Answer: Network queries navigate pointer chains. Any schema change (adding a record type, splitting one) breaks every program that hand-walks those pointers. Relational JOINs are based on values, so changing one table rarely breaks queries on others.
Network query মানে pointer ধরে hand-navigation। কোনো record-type যোগ করলে সব program আবার লিখতে হয়। Relational JOIN value-ভিত্তিক — একটি table পাল্টালেও অন্যেরা প্রায়ই অক্ষত থাকে।
-
Use a JSON column to store a list of ingredients for restaurant dishes, then count ingredients per dish.JSON কলামে restaurant dish-এর ingredient list রাখুন এবং প্রতিটির ingredient সংখ্যা গুনুন।
✨ Show Answer
ans4.sqlSELECT name, json_array_length(ingredients) AS n_ing FROM dish ORDER BY n_ing DESC; -
In one sentence each, when would you use Redis, MongoDB, Cassandra, and Neo4j?এক বাক্যে: Redis, MongoDB, Cassandra, Neo4j — প্রতিটি কখন?
✨ Show Answer
Answer: Redis — ultra-fast cache or session store. MongoDB — JSON-shaped data with variable schema. Cassandra — write-heavy, time-series at huge scale across data centres. Neo4j — relationship-heavy data like social networks or fraud rings.
Redis — দ্রুত cache/session। MongoDB — schema-less JSON ডেটা। Cassandra — অনেক write, time-series, multi-datacenter। Neo4j — সম্পর্ক-প্রধান (social/fraud) graph।
-
Implement a simple key-value store in plain SQL: insert three sessions, then "get" one by key.প্লেইন SQL-এ একটি key-value store বানান — তিনটি session রাখুন, তারপর একটি key দিয়ে "get" করুন।
✨ Show Answer
ans6.sqlINSERT INTO session VALUES ('sess:abc', '{"uid":101}', '2025-05-11'), ('sess:def', '{"uid":102}', '2025-05-11'), ('sess:ghi', '{"uid":103}', '2025-05-11'); SELECT v FROM session WHERE k = 'sess:def'; -
Why is "NoSQL replaced SQL" a myth?"NoSQL SQL-কে replace করেছে" — এই ধারণা কেন ভুল?
✨ Show Answer
Answer: Most production systems use both. Relational DBs handle the source-of-truth, transactional, money-bearing tables; NoSQL handles caches, search indexes, telemetry, and graph features. They are complements, not competitors.
প্রায় প্রতিটি production system দুটোই ব্যবহার করে। Relational ধরে রাখে money/source-of-truth; NoSQL ব্যবহৃত হয় cache, search, telemetry, graph-এ। তারা প্রতিদ্বন্দ্বী নয়, পরিপূরক।
-
List three things the relational model gives you that the hierarchical model does not.Relational মডেল hierarchical মডেলের তুলনায় কোন তিনটি জিনিস বাড়তি দেয়?
✨ Show Answer
Answer: (1) Many-to-many relationships natively (a student in two departments). (2) A declarative query language (SQL) that the optimizer plans for you. (3) Schema changes that do not break code, thanks to data independence.
(১) Many-to-many সম্পর্ক স্বাভাবিকভাবে প্রকাশ। (২) Declarative SQL — optimizer plan ঠিক করে। (৩) Data independence-এর কারণে schema পাল্টানো নিরাপদ।
Summary — Module 04
Five families of data models have shaped the industry. Hierarchical sees data as a tree (IMS, JSON). Network sees it as a graph of pointers (CODASYL, Neo4j today). Relational sees it as flat tables joined by values — and is still the workhorse for transactional, money-bearing systems in 2026. Object-relational enriches relational with JSON, arrays and custom types (Postgres). NoSQL is a label for four very different animals (document, key-value, wide-column, graph), each born to solve a specific scale problem. Choose deliberately: for most Bangladeshi projects, "Postgres + Redis" is the right boring answer.