¿Qué es el modelado de datos?

El modelado de datos es un proceso que mapea entidades, atributos y relaciones antes de decidir cómo la base de datos los almacenará. Las entidades son la parte fácil — todo producto conoce sus usuarios, pedidos y posts. El oficio está en las relaciones: qué registros apuntan a cuáles, cuántos, y dónde vive físicamente esa arista. Acierta las aristas y las queries se escriben solas; equivócate y cada feature pelea contra el esquema.

Puntos clave

Las mismas relaciones, en ambos mundos

Primero el mundo relacional — la clave foránea carga el uno-a-muchos, y el muchos-a-muchos debe descomponerse a través de una tabla de unión:

-- 1:N — la clave foránea vive en el lado de "muchos"
CREATE TABLE books (
  id        bigint PRIMARY KEY,
  title     text   NOT NULL,
  author_id bigint NOT NULL REFERENCES authors(id) ON DELETE CASCADE
);

-- M:N — ninguna FK sola puede expresarlo; la tabla de unión guarda ambas claves
CREATE TABLE book_genres (
  book_id  bigint REFERENCES books(id),
  genre_id bigint REFERENCES genres(id),
  added_at timestamptz DEFAULT now(),     -- las uniones pueden llevar atributos
  PRIMARY KEY (book_id, genre_id)         -- clave compuesta: una arista, una vez
);

Mundo de documentos, el mismo modelo: la arista uno-a-muchos es un Pointer tipado, la muchos-a-muchos es una Relation — sin tabla de unión que inventar, y la arista se declara en el código de la aplicación:

// 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. lógico vs. físico: los tres niveles

La disciplina que los niveles imponen: no discutas sobre índices mientras el equipo todavía no se pone de acuerdo en qué es un “pedido”.

Cada relación, cada implementación

La tabla que la SERP nunca construyó — cada tipo de arista con su implementación en ambos mundos:

Notación de cardinalidad, para leer diagramas: la pata de gallo dibuja una barra para “uno” y un tridente de tres puntas para “muchos”; la tradición ER escribe 1 y N sobre las líneas; UML escribe multiplicidades como 1 y *. Tres dialectos, una sola gramática.

¿Normalizar, desnormalizar o embeber?

El modelado relacional parte de la normalización — separa los datos para que cada hecho viva una sola vez, protegiendo las escrituras de anomalías. El modelado analítico y el de documentos la doblan a propósito: la desnormalización duplica campos calientes de lectura para matar joins, y embeber es el primo nativo de documentos de la desnormalización. El checklist de embeber vs. referenciar se comprime en tres preguntas: ¿se leen juntos? ¿pertenecen a un solo padre? ¿tienen tamaño acotado? Tres síes embeben; cualquier no, referencia. Y por encima de todo, la regla moderna que las guías generalistas se saltan: lista primero las queries. Un modelo es correcto cuando los patrones de acceso que debe servir son baratos — las entidades por sí solas no pueden decírtelo.

Casos de uso comunes

• Diseñar un backend nuevo. La pasada clásica: nombra las entidades, dibuja las aristas, elige implementaciones según la tabla de arriba — antes de la primera línea de código.
• El patrón de unión con atributos. Inscripciones, membresías, líneas de pedido — cuando la arista misma tiene datos (fecha, cantidad, rol), la unión (o una clase-arista con dos pointers) es una entidad de primera clase.
• Desenredar un esquema que creció. Los síntomas mapean a aristas: filas duplicadas revelan un muchos-a-muchos mal modelado; documentos inflados revelan un embed sin límite.
• Migrar entre mundos. Relacional→documentos significa volver a decidir cada FK como embeber vs. pointer; la tabla de arriba es el diccionario de traducción.
• Feeds de AI y analítica. Los warehouses quieren las aristas explícitas y estables — la deuda de modelado sale a la luz el día que intentas exportar.

¿Cómo deberías modelar cada arista? Matriz de decisión

Limitaciones y trade-offs

• Los modelos congelan supuestos. Las decisiones de cardinalidad (“un usuario tiene una dirección”) se vuelven esquema; baratas de cambiar en papel, caras después del lanzamiento — modela para la cardinalidad de mañana.
• Ambos mundos castigan la arista sin índice. Las columnas FK y los campos pointer son rutas de join; olvidar sus índices es el bug de performance silencioso más común.
• Embeber cambia integridad por localidad. Ningún motor garantiza que una copia embebida se mantenga consistente con su fuente — esa ahora es tu lógica de updates.
• Las uniones multiplican joins; las relations los esconden. Cada lectura muchos-a-muchos cruza el almacén de aristas — presupuesta la ruta de la consulta, estés en el mundo que estés.
• Modelar por patrones de acceso también cuesta. Optimizar para las queries de hoy puede casar el esquema con el producto de hoy; conserva el modelo conceptual como la verdad neutral de fondo.

El modelado de datos en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Su vocabulario de modelado es la columna de documentos de las tablas de arriba, elevada a primera clase: los Pointers son aristas uno-a-muchos tipadas, las Relations llevan el muchos-a-muchos sin una tabla de unión hecha a mano, y los arrays cubren los pocos-acotados. Cada arista que declaras es inmediatamente recorrible — include() camina los pointers en una sola solicitud, GraphQL anida relations en una sola query — y el esquema se mantiene visible y editable en el dashboard, así el modelo físico nunca se pierde de vista del equipo que diseñó el conceptual.