What is Data Modeling?

Data modeling is a process of mapping entities, attributes, and relationships before deciding how a database will store them. The entities are the easy part — every product knows its users, orders, and posts. The craft is in the relationships: which records point at which, how many, and where that edge physically lives. Get the edges right and queries write themselves; get them wrong and every feature fights the schema.

Key takeaways

The same relationships, both worlds

Relational first — the foreign key carries one-to-many, and many-to-many must decompose through a junction:

-- 1:N — the foreign key lives on the "many" side
CREATE TABLE books (
  id        bigint PRIMARY KEY,
  title     text   NOT NULL,
  author_id bigint NOT NULL REFERENCES authors(id) ON DELETE CASCADE
);

-- M:N — no single FK can express it; a junction table holds both keys
CREATE TABLE book_genres (
  book_id  bigint REFERENCES books(id),
  genre_id bigint REFERENCES genres(id),
  added_at timestamptz DEFAULT now(),     -- junctions can carry attributes
  PRIMARY KEY (book_id, genre_id)         -- composite key: one edge, once
);

Document world, same model: the one-to-many edge is a typed Pointer, the many-to-many edge is a Relation — no junction table to invent, and the edge is declared in application code:

// JavaScript / Node.js — Back4app JS SDK
// One-to-many: a Pointer. Many-to-many: a Relation.
const author = await new Parse.Query('Author').get(authorId);

const book = new Parse.Object('Book');
book.set('title', 'Dune');
book.set('author', author);              // Pointer — typed one-to-many edge
await book.save();

const genres = book.relation('genres');  // Relation — many-to-many, unbounded
genres.add([sciFi, classics]);
await book.save();

// Flutter / Dart — Back4app Flutter SDK
// One-to-many: a Pointer. Many-to-many: a Relation.
final book = ParseObject('Book')
  ..set('title', 'Dune')
  ..set('author', author.toPointer()); // Pointer — typed one-to-many edge
await book.save();

book.addRelation('genres', [sciFi, classics]); // Relation — many-to-many
await book.save();

// iOS / Swift — Back4app Swift SDK
// One-to-many: a Pointer. Many-to-many: a Relation.
var book = Book()
book.title = "Dune"
book.author = try author.toPointer()   // Pointer — typed one-to-many edge
let saved = try await book.save()

let relation = try saved.relation("genres")
try await relation.add([sciFi, classics]).save() // Relation — many-to-many

// Android / Kotlin — Back4app Android SDK
// One-to-many: a Pointer. Many-to-many: a Relation.
val book = ParseObject("Book").apply {
  put("title", "Dune")
  put("author", author)                 // Pointer — typed one-to-many edge
}
book.save()

val genres = book.getRelation<ParseObject>("genres") // Relation — many-to-many
genres.add(sciFi)
genres.add(classics)
book.save()

Conceptual vs. logical vs. physical: the three levels

The discipline the levels enforce: don’t argue about indexes while the team still disagrees about what an “order” is.

Every relationship, every implementation

The table the SERP never built — each edge type with its implementation in both worlds:

Cardinality notation, for reading diagrams: crow’s-foot draws a bar for “one” and a three-pronged fork for “many”; the ER tradition writes 1 and N on the lines; UML writes multiplicities like 1 and *. Three dialects, one grammar.

Normalize, denormalize, or embed?

Relational modeling starts from normalization — split data so every fact lives once, protecting writes from anomalies. Analytical and document modeling deliberately bend it: denormalization duplicates read-hot fields to kill joins, and embedding is denormalization’s document-native cousin. The embed-vs-reference checklist compresses to three questions: read together? owned by one parent? bounded in size? Three yeses embed; any no references. And over all of it, the modern rule that generalist guides skip: list the queries first. A model is correct when the access patterns it must serve are cheap — entities alone can’t tell you that.

Common use cases

• Designing a new backend. The classic pass: name entities, draw edges, choose implementations per the table above — before the first line of code.
• The junction-with-attributes pattern. Enrollments, memberships, line items — when the edge itself has data (date, quantity, role), the junction (or an edge class with two pointers) is a first-class entity.
• Untangling a grown schema. Symptoms map to edges: duplicated rows reveal a mis-modeled many-to-many; document bloat reveals an unbounded embed.
• Migrating between worlds. Relational→document means re-deciding every FK as embed vs. pointer; the table above is the translation dictionary.
• AI and analytics feeds. Warehouses want the edges explicit and stable — modeling debt surfaces the day you try to export.

How should you model each edge? A decision matrix

Limitations and trade-offs

• Models freeze assumptions. Cardinality decisions (“a user has one address”) become schema; cheap to change on paper, expensive after launch — model for tomorrow’s cardinality.
• Both worlds punish the unindexed edge. FK columns and pointer fields are join paths; forgetting their indexes is the most common silent performance bug.
• Embedding trades integrity for locality. No engine enforces that an embedded copy stays consistent with its source — that’s your update logic now.
• Junctions multiply joins; relations hide them. Every many-to-many read crosses the edge store — budget the query path, whichever world you’re in.
• Access-pattern modeling has a cost too. Optimizing for today’s queries can wed the schema to today’s product; keep the conceptual model around as the neutral ground truth.

Data modeling on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Its modeling vocabulary is the document column of the tables above, made first-class: Pointers are typed one-to-many edges, Relations carry many-to-many without a hand-built junction, and arrays cover the bounded-few. Every edge you declare is immediately traversable — include() walks pointers in one request, GraphQL nests relations in one query — and the schema stays visible and editable in the dashboard, so the physical model never drifts out of sight of the team that designed the conceptual one.