O que é modelagem de dados?

A modelagem de dados é o processo de mapear entidades, atributos e relacionamentos antes de decidir como o banco de dados vai armazená-los. As entidades são a parte fácil — todo produto conhece seus usuários, pedidos e posts. O ofício está nos relacionamentos: quais registros apontam para quais, quantos, e onde essa aresta vive fisicamente. Acerte as arestas e as queries se escrevem sozinhas; erre e cada feature briga com o schema.

Principais pontos

Os mesmos relacionamentos, nos dois mundos

Relacional primeiro — a chave estrangeira carrega o um-para-muitos, e o muitos-para-muitos precisa se decompor por uma junção:

-- 1:N — a chave estrangeira vive no lado "muitos"
CREATE TABLE books (
  id        bigint PRIMARY KEY,
  title     text   NOT NULL,
  author_id bigint NOT NULL REFERENCES authors(id) ON DELETE CASCADE
);

-- M:N — nenhuma FK sozinha expressa isso; a tabela de junção guarda as duas chaves
CREATE TABLE book_genres (
  book_id  bigint REFERENCES books(id),
  genre_id bigint REFERENCES genres(id),
  added_at timestamptz DEFAULT now(),     -- junções podem carregar atributos
  PRIMARY KEY (book_id, genre_id)         -- chave composta: uma aresta, uma vez
);

Mundo dos documentos, mesmo modelo: a aresta um-para-muitos é um Pointer tipado, a muitos-para-muitos é uma Relation — nenhuma tabela de junção para inventar, e a aresta é declarada no código da aplicação:

// 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()

Conceitual vs. lógico vs. físico: os três níveis

A disciplina que os níveis impõem: não discuta índices enquanto o time ainda discorda sobre o que é um “pedido”.

Todo relacionamento, toda implementação

A tabela que a SERP nunca montou — cada tipo de aresta com sua implementação nos dois mundos:

Notação de cardinalidade, para ler diagramas: o pé-de-galinha desenha uma barra para “um” e um garfo de três pontas para “muitos”; a tradição ER escreve 1 e N nas linhas; a UML escreve multiplicidades como 1 e *. Três dialetos, uma gramática.

Normalizar, desnormalizar ou embutir?

A modelagem relacional parte da normalização — separar os dados para que cada fato viva uma vez só, protegendo as escritas de anomalias. A modelagem analítica e a de documentos a dobram de propósito: a denormalização duplica campos quentes de leitura para matar joins, e embutir é a prima nativa dos documentos da denormalização. O checklist embutir-vs-referenciar se comprime em três perguntas: lidos juntos? de um dono só? tamanho limitado? Três sins embutem; qualquer não referencia. E, acima de tudo isso, a regra moderna que os guias generalistas pulam: liste as queries primeiro. Um modelo está correto quando os padrões de acesso que ele precisa servir saem baratos — as entidades sozinhas não contam isso.

Casos de uso comuns

• Projetar um backend novo. O rito clássico: nomear entidades, desenhar arestas, escolher implementações pela tabela acima — antes da primeira linha de código.
• O padrão junção-com-atributos. Matrículas, assinaturas, itens de pedido — quando a própria aresta tem dados (data, quantidade, papel), a junção (ou uma classe de aresta com dois pointers) é entidade de primeira classe.
• Desembaraçar um schema que cresceu. Sintomas mapeiam para arestas: linhas duplicadas revelam um muitos-para-muitos mal modelado; documentos inchados revelam um embed sem limite.
• Migrar entre os mundos. Relacional→documentos significa re-decidir cada FK como embed vs. pointer; a tabela acima é o dicionário de tradução.
• Alimentar AI e analytics. Warehouses querem as arestas explícitas e estáveis — a dívida de modelagem aparece no dia em que você tenta exportar.

Como modelar cada aresta? Matriz de decisão

Limitações e trade-offs

• Modelos congelam premissas. Decisões de cardinalidade (“um usuário tem um endereço”) viram schema; baratas no papel, caras depois do lançamento — modele para a cardinalidade de amanhã.
• Os dois mundos punem a aresta sem índice. Colunas de FK e campos de pointer são caminhos de join; esquecer os índices deles é o bug silencioso de performance mais comum.
• Embutir troca integridade por localidade. Nenhum motor garante que uma cópia embutida continue consistente com a fonte — isso agora é a sua lógica de update.
• Junções multiplicam joins; Relations os escondem. Toda leitura muitos-para-muitos atravessa o armazém de arestas — orce o caminho da query, em qualquer um dos mundos.
• Modelar por padrão de acesso também tem custo. Otimizar para as queries de hoje pode casar o schema com o produto de hoje; mantenha o modelo conceitual por perto como o terreno neutro da verdade.

Modelagem de dados no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Seu vocabulário de modelagem é a coluna de documentos das tabelas acima, elevada a primeira classe: Pointers são arestas um-para-muitos tipadas, Relations carregam o muitos-para-muitos sem junção feita à mão, e arrays cobrem o “poucos e limitado”. Toda aresta que você declara é atravessável na hora — include() percorre pointers em uma requisição, o GraphQL aninha relações em uma query — e o schema segue visível e editável no dashboard, para que o modelo físico nunca saia do campo de visão do time que desenhou o conceitual.