Ir al contenido
Documentación

Manual de prueba — NoSqlStudio Data Modeling

Una guía paso a paso para hacer ingeniería inversa de un schema real, editar el diagrama ER, auditarlo, transformar los datos de forma segura y aplicar los cambios a MongoDB.

Tiempo estimado: ~25 minutos
En este manual

Introducción

Una guía paso a paso para llevar una base de datos desde su schema real hasta el dato corregido: haz ingeniería inversa de las colecciones, trabaja el diagrama ER editable, ejecuta la auditoría con un health score, transforma los datos mediante una escalera de seguridad y, al final, genera el DDL o aplica los cambios de vuelta a MongoDB.

Cómo leer este manual

Cada paso tiene:

  • Haz — la acción exacta (hacer clic, escribir, ejecutar tal comando).
  • Mira — qué debe ocurrir en pantalla. Este es tu “pasa / falla”.
  • Por qué — contexto adicional, solo cuando ayuda (sáltalo si vas con prisa).

Antes de empezar

Concepto

Qué es Data Modeling

Data Modeling hace ingeniería inversa de tus colecciones en vivo en un diagrama ER editable, lo audita en busca de anti-patrones con un health score, y te deja corregir tanto el modelo como los datos — para luego generar el DDL o aplicar los cambios de vuelta a la base.

Atención

Cuándo se necesita una conexión

Se requiere una conexión activa para Generate el modelo y para escribir en la base (correcciones de la auditoría, transformaciones, Apply to DB). Todo lo demás — editar el canvas, auditar, generar DDL, importar/exportar — funciona offline.

Vas a necesitar:

  1. 1Un deployment MongoDB conectado con al menos una base que tenga datos para muestrear.
  2. 2Abrir la pantalla desde la tarjeta Home → Data Modeling, o desde el menú Tools ▸ Schema & Data ▸ Data Modeling.
  3. 3Idealmente una base de prueba — la Etapa 4 puede escribir en tus datos, así que practica donde un error sea inofensivo.

Tiempo estimado para el recorrido completo: ~25 minutos.

Etapa 1

Generar el modelo

Haz ingeniería inversa de una base en vivo a un diagrama ER y congélalo como la baseline “Observado”.

Paso 1

Abre Data Modeling

Haz

Con una conexión activa, abre la pantalla desde la tarjeta Home → Data Modeling, o desde el menú Tools ▸ Schema & Data ▸ Data Modeling.

Mira

El canvas de Data Modeling se abre, con un selector de database en la barra y un botón Generate.

Paso 2

Elige la(s) base(s) de datos

Haz

En el selector de la barra, elige la base de datos a modelar — o elige varias para construir un modelo cross-DB.

Mira

La(s) base(s) elegida(s) quedan seleccionadas, listas para generar.

Por qué

Seleccionar varias bases permite que la inferencia encuentre relaciones que cruzan los límites de base, no solo dentro de una DB.

Paso 3

Haz clic en Generate

Haz

Haz clic en Generate para hacer la ingeniería inversa del modelo desde la conexión.

Mira

Una barra de progreso recorre las etapas LISTING → SAMPLING → ANALYZING → INFERRING → DONE. Puedes Cancelar en cualquier momento.

Por qué

Muestrea cada colección, infiere campos y tipos, lee índices y validadores existentes, e infiere relaciones a partir de los datos muestreados.

Paso 4

Lee las relaciones inferidas

Mira

Las relaciones se infieren de dos maneras: por FK — campos como *_id / *Id / *Ref que coinciden con el _id de otra colección y se confirman contra los datos — y por campo compartido — el mismo nombre de identificador apareciendo entre colecciones.

Concepto

Inferencia, no magia. La herramienta solo propone una relación cuando el patrón del nombre del campo y los valores muestreados encajan con un _id de destino. Puedes editar o borrar cualquier relación después.

Paso 5

Inspecciona el diagrama ER

Mira

El diagrama ER aparece: colecciones como tarjetas, campos con badges (PK/FK/UK/NN/ENUM/CK), y relaciones como líneas — azul = FK, ámbar = campo compartido, discontinua = inferida.

Paso 6

Anota la baseline Observado

Mira

Este estado generado se vuelve la baseline congelada “Observado” con la que el Diff de la Etapa 5 compara.

Por qué

Todo lo que edites de aquí en adelante se mide como un delta contra este snapshot — así es como los renames y las adiciones se rastrean con precisión.

Etapa 2

Editar el canvas

Organiza, inspecciona y da forma al modelo — colecciones, campos, validación y relaciones — todo offline y con deshacer.

Paso 7

Mover, organizar, zoom y pan

Haz

Arrastra las tarjetas para moverlas (Ctrl/Cmd-clic para multi-selección); haz clic en ✦ Arrange para reempacar el layout; usa −/+/%/Fit para el zoom; mantén Alt+arrastre o usa el botón central para hacer pan.

Mira

Las tarjetas se reposicionan, el layout se reempaca con Arrange, y el viewport hace zoom y pan suavemente.

Paso 8

Inspecciona una colección

Haz

Doble clic en una tarjeta de colección para abrir el inspector.

Mira

El inspector se abre mostrando los campos e índices de esa colección.

Paso 9

Edita los campos

Haz

Usa + Add field, renombra (Enter), cambia el tipo o elimina (×). Por campo, define la Validación (required / enum / checks).

Mira

Aparecen nuevos campos; la validación produce los badges NN (required), ENUM y CK (check) en el campo.

Paso 10

Agrega una colección

Haz

Haz clic en + Add collection e informa el namespace como db.colección. Renombra colecciones de la misma forma.

Mira

Una nueva tarjeta de colección aparece en el canvas con el namespace que escribiste (por ejemplo db.orders).

Paso 11

Crea y edita relaciones

Haz

Arrastra desde el dot (○) de un campo hasta otra colección para crear una relación. Doble clic en la línea edita lados/cardinalidad/nota; doble clic en la flecha invierte la dirección; arrastra un waypoint para curvar la línea; presiona ×/Delete para eliminar.

Mira

Se dibuja una línea de relación entre los campos, y la edición se refleja en sus lados, cardinalidad y forma.

Paso 12

Deshaz y rehaz

Haz

Usa Undo/Redo (↶ ↷) para avanzar y retroceder por tus ediciones.

Mira

El canvas revierte o reaplica cada edición en orden.

Concepto

Todo offline. Editar el canvas nunca toca la base — solo cambia el modelo en memoria hasta que apliques explícitamente una corrección, transformación o DDL.

Etapa 3

Auditar + corrección de 1 clic

Puntúa el modelo, lee los verdicts por severidad, y aplica correcciones no destructivas en el modelo, la base o ambos.

Paso 13

Ejecuta la auditoría

Haz

Haz clic en ✓ Audit para abrir el panel de auditoría.

Mira

Aparece un health score (A–E), más los verdicts por severidad: 🔴 err / 🟡 warn / ℹ️ info. Los filtros permiten mostrar todos / errores / avisos / info.

Paso 14

Lee los anti-patrones

Mira

Los anti-patrones detectados incluyen: array sin límite, documento inflado (demasiados campos), campo de tipo mixto, fecha como string, FK sin índice, colección sin validación, y sin `_id`. Cada verdict dice qué se detectó, por qué importa, y la buena práctica.

Paso 15

Aplica una corrección de 1 clic

Haz

En un verdict corregible, usa la corrección de 1 clic — por ejemplo crear índice (para una FK sin índice) o aplicar validación ($jsonSchema). Elige el destino Modelo / Base / Ambos y haz clic en Aplicar.

Mira

La corrección se aplica de forma no destructiva. Si el destino incluye Base o Ambos, la escritura entra en el changeset.

Por qué

Estas correcciones son aditivas — crean un índice o adjuntan un validador $jsonSchema; nunca borran datos ni reescriben documentos.

Paso 16

Envía un verdict a Transformar

Haz

Los verdicts con la etiqueta → Transform (por ejemplo fecha-como-string o tipo-mixto) abren la escalera de transformación cubierta en la Etapa 4.

Mira

Hacer clic en la etiqueta lleva el verdict al flujo de transformación, ya apuntado al campo o colección problemático.

Etapa 4

Transformar datos (escalera de seguridad)

Esta etapa corrige los datos, no solo el modelo. Cada escritura sube una escalera de seguridad de cuatro peldaños antes de tocar un solo documento.

Paso 17

Haz el Preview del cambio

Haz

Abre la escalera desde un verdict de auditoría, un diff del modelo, un pipeline personalizado o un inline de referencia. Empieza por el Preview.

Mira

El Preview muestra antes / después de los primeros documentos afectados — y no escribe nada.

Paso 18

Dry-run para los conteos

Haz

Ejecuta el Dry-run para medir el impacto.

Mira

El Dry-run reporta afectados / total / bytes, y marca el job como “grande” cuando supera 250k docs o 1 GB.

Atención

El Dry-run no escribe

Tanto el Preview como el Dry-run son de solo lectura. Calculan conteos y muestras sin modificar ningún documento — no se escribe nada hasta que llegues al Apply.

Paso 19

Haz un Backup

Haz

Haz un Backup (opcional, pero forzado si el job es grande) — una copia con timestamp vía $out.

Mira

Se crea una colección de backup con timestamp para que puedas restaurar si la transformación sale mal.

Paso 20

Aplica la transformación

Haz

Escribe el nombre de la colección para desbloquear el Apply. Luego Aplicar pipeline in-place (idempotente, vía $merge) — o ejecutar en segundo plano como Tarea para colecciones grandes.

Mira

Los documentos se transforman. Cada escritura se vuelve un AppliedChange registrado con su comando mongosh equivalente.

Por qué

La escritura vía $merge es idempotente — volver a ejecutar la misma transformación converge al mismo resultado en lugar de aplicarla por duplicado.

Paso 21

Usa las variaciones

Haz

Prueba las variaciones: un pipeline personalizado (pega tu propio aggregation más un destino — in-place o nueva colección) y el inline (colapsa una colección referenciada en el padre vía $lookup, con opción de eliminar el campo FK).

Mira

Ambas variaciones corren por la misma escalera de cuatro peldaños — Preview → Dry-run → Backup → Apply.

Etapa 5

Diff Observado × Objetivo

Compara el modelo editado contra la baseline Observado congelada y convierte un delta en una transformación.

Paso 22

Abre el diff

Haz

Haz clic en ⇆ Diff (se habilita en cuanto hay cambios) para listar el delta desde el “Observado”.

Mira

El diff lista colecciones, campos, índices y validación agregados / eliminados / cambiados como +N −M ~L.

Paso 23

Confirma los renames reconocidos

Mira

Los renames se reconocen por el log de edición — así un campo renombrado aparece como rename (no como eliminación + adición), y los datos se preservan en la transformación.

Paso 24

Genera una transformación desde un delta

Haz

Desde un elemento del delta, genera una transformación personalizada y aplícala a la base por la escalera.

Mira

El constructor de transformación se abre prellenado desde el delta, listo para ejecutarse vía Preview → Dry-run → Backup → Apply.

Etapa 6

DDL y aplicar a la base

Genera un script mongosh para recrear el modelo, o crea las colecciones que faltan directamente — sin sobrescribir lo que ya existe.

Paso 25

Genera el script de DDL

Haz

Elige File ▸ DDL (mongosh) para generar un script que recrea el modelo.

Mira

El script contiene createCollection con $jsonSchema, los índices, e índices de FK para cada relación (con una opción “incluir FK inferidas”), generado por base de datos.

Paso 26

Copia o descarga el script

Haz

Usa Copiar o Descargar para guardar el DDL generado.

Mira

El script mongosh completo queda en tu portapapeles o en tu carpeta de Descargas, listo para ejecutar.

Paso 27

Apply to DB

Haz

Haz clic en Apply to DB para crear las colecciones (con validator + índices) que aún no existen.

Mira

Las colecciones que faltan se crean; las existentes no se sobrescriben. Cada creación entra en el changeset.

Atención

El Apply to DB es solo aditivo. Nunca sobrescribe ni altera una colección que ya existe — solo rellena lo que falta.

Etapa 7

Importar/Exportar e historial

Guarda y carga el modelo, exporta un informe legible, y revisa cada escritura hecha en la base en esta sesión.

Paso 28

Abre y guarda el modelo

Haz

Usa File ▸ Open / Save para cargar o guardar el modelo como JSON.

Mira

El modelo se escribe en / se lee de un archivo JSON, así puedes versionarlo o compartirlo.

Paso 29

Exporta un informe

Haz

Usa Export HTML/PDF para producir un informe legible del modelo.

Mira

Se genera un documento HTML o PDF para compartir o archivar.

Paso 30

Revisa el historial de cambios

Haz

Abre File ▸ Changes para revisar el log de sesión de cada escritura en la base.

Mira

Cada entrada registra timestamp · tipo · namespace · comando mongosh — el rastro de auditoría de todo lo que esta sesión escribió en la base.

Concepto

Este es tu comprobante. Cada corrección de auditoría, transformación y creación vía Apply to DB aparece aquí con el comando mongosh exacto que ejecutó.

Limpieza (cuando termines)

Sé honesto sobre qué tocó la base. Editar, auditar, generar DDL e importar/exportar son todos offline y seguros — nunca escriben. Las únicas escrituras en la base son las correcciones de la auditoría, transformaciones y creaciones vía Apply to DB que ejecutaste explícitamente.

Haz

Abre File ▸ Changes para ver la lista completa de escrituras hechas en esta sesión.

Mira

Cada escritura registrada corresponde a una corrección, transformación o apply de DDL que disparaste a propósito.

Atención

Si aplicaste una transformación sobre datos de prueba, elimina o restaura las colecciones afectadas según sea necesario — los backups tomados en la Etapa 4 son copias con timestamp desde las que puedes restaurar.

Resumen de lo que validaste

EtapaFuncionalidad
1Generar el modelo ER de una base en vivo y congelar la baseline Observado
2Editar el canvas — organizar, campos, badges de validación, colecciones y relaciones
3Auditar con un health score y aplicar correcciones de 1 clic no destructivas
4Transformar datos por la escalera de seguridad Preview → Dry-run → Backup → Apply
5Diff Observado × Objetivo y generar una transformación desde un delta
6Generar DDL (mongosh) y Apply to DB sin sobrescribir colecciones existentes
7Importar/Exportar el modelo y revisar el historial completo de cambios
Si cada paso dio el “Mira” esperado, tu flujo de Data Modeling está 100% validado — del schema observado al dato corregido. Anota el número del paso de cualquier discrepancia para que podamos corregirlo.