De Google Sheet a esquema relacional: un plan de modelado paso a paso

Por qué las hojas de cálculo se vuelven un lío cuando las conviertes en base de datos

Una hoja de cálculo es genial para una lista pequeña. Puedes cambiar columnas sobre la marcha, añadir notas donde quieras y arreglar problemas a simple vista. Esa libertad empieza a fallar cuando el archivo se convierte en la fuente de verdad compartida.

A medida que los datos crecen, aparecen los mismos problemas una y otra vez. Ves duplicados porque no hay un lugar único para guardar un cliente o un producto. Aparecen valores contradictorios porque dos filas no coinciden en lo mismo, como un número de teléfono. Filtrar y reportar se vuelve frustrante porque algunas columnas ocultan listas ("Tags", "Products", "Attendees") o mezclan formatos ("$1,200", "1200", "1.2k").

Pasar de un Google Sheet a un esquema relacional es una cuestión de seguridad. Una base de datos impone una estructura más clara para que puedas consultar, validar y actualizar datos sin crear nuevas contradicciones.

Un modelo mental útil: una fila debería representar una cosa real. Si una fila representa un trato, un cliente y una lista de productos, actualizar cualquiera de esos más tarde será doloroso.

Una prueba rápida: ¿necesita alguna vez una sola fila dos valores para el mismo campo?

• Un pedido tiene múltiples productos
• Un proyecto tiene varios miembros del equipo
• Un cliente tiene varias direcciones

Si la respuesta es sí, no es un problema de “fila ancha”. Es un problema de “tabla separada”. Una vez que lo modelas bien, puedes construir formularios y validaciones encima en lugar de depender de ediciones manuales frágiles.

Empieza definiendo qué significa realmente la hoja

Una hoja de cálculo puede parecer organizada y aun así significar cosas diferentes para distintas personas. Antes de convertir un Google Sheet a un esquema relacional, pónganse de acuerdo sobre lo que la hoja está rastreando.

Comienza con los resultados, no con las columnas. ¿Qué decisiones debe soportar la información: un informe semanal de ingresos, una lista de tickets vencidos, un flujo de trabajo que asigna seguimientos o una consulta rápida durante una llamada con un cliente? Si no puedes nombrar una decisión, ese campo a menudo no pertenece en la base de datos.

Luego, extrae los sustantivos que se esconden en los encabezados y notas. Esos suelen convertirse en tus futuras tablas: customers, orders, products, invoices, tickets, agents, locations. Si una columna mezcla dos sustantivos (como “Customer + Company”), estás almacenando varias cosas en un solo lugar.

Acordad las definiciones desde el principio

Pequeñas diferencias en el significado se convierten en grandes limpiezas después. Aclara lo básico:

• ¿Qué cuenta como un “order” (una cotización, una compra pagada o ambos)?
• ¿Qué es un “customer” (persona, empresa o ambos)?
• ¿Puede un pedido tener múltiples productos?
• ¿Puede un email pertenecer a varios clientes?
• ¿Qué pretende mostrar “status” (estado actual o historial)?

Ejemplo: si tu hoja tiene una fila por “Order” pero la celda “Products” contiene una lista separada por comas, decide si esa fila representa un checkout, un envío o una factura. Cada elección conduce a un esquema distinto.

Congela una copia de la hoja original como solo lectura. La usarás para validar que las nuevas tablas siguen respondiendo las mismas preguntas.

Limpia la hoja para que la estructura sea visible

Antes de convertir un Google Sheet a esquema relacional, haz que la hoja parezca datos, no un informe. Las bases de datos necesitan filas y columnas consistentes. Los diseños decorativos ocultan patrones que necesitas modelar.

Elimina trucos de diseño como celdas combinadas, filas de encabezado múltiples y subtotales dentro del rango de datos. Mantén una fila de encabezado y luego solo filas de registros. Si necesitas totales, ponlos en una pestaña de resumen separada para que no se mezclen con los registros reales.

Luego, unifica los formatos en cada columna. Una base de datos no puede adivinar que “1/2/24”, “2024-02-01” y “Feb 1” son la misma fecha. Lo mismo aplica a números de teléfono, monedas y nombres. Elige un formato y úsalo en todas partes, aunque parezca estricto.

Un pase de limpieza corto que suele dar resultados:

• Asegúrate de que cada fila represente una sola cosa (un pedido, un cliente, un ticket).
• Elimina filas y columnas espaciadoras en blanco.
• Reemplaza “N/A”, “-” y cadenas vacías por una regla consistente que mantendrás.
• Marca qué columnas son calculadas vs. escritas por una persona.

Finalmente, etiqueta cualquier celda que contenga múltiples valores, como “red, blue, green” en una columna. No arregles el esquema todavía. Solo marca esas columnas para recordar que más tarde se convertirán en filas separadas.

Identifica grupos repetidos y campos que ocultan listas

La señal de alarma más grande en el modelado de datos de hojas de cálculo es la repetición. Las hojas suelen apretar “más de una cosa” en una sola fila repitiendo columnas o empaquetando múltiples valores en una celda. Eso funciona para seguimiento rápido y luego se rompe cuando necesitas filtros, reportes o actualizaciones consistentes.

Patrones que usualmente significan “esto debería ser otra tabla”

Escanea en busca de estas formas:

• Columnas numeradas como Item 1, Item 2, Item 3 o Phone 1, Phone 2.
• Bloques repetidos como campos de dirección duplicados para “Home” y “Work”.
• Celdas con comas, saltos de línea o “y” que combinan valores (por ejemplo, “Mouse, Keyboard, Monitor”).
• Una columna que mezcla dos conceptos, como “Approved 2025-01-10” o “Alex (Manager)”.
• Una fila que representa dos niveles a la vez, como una fila de Order que también intenta almacenar todos los Order Items.

Ejemplo: si tu tracker de ventas usa Order ID, Customer, Product 1, Qty 1, Product 2, Qty 2, te toparás con un muro. Algunos pedidos tienen 1 ítem, otros 8. La hoja o crece hacia los lados para siempre o empieza a perder datos. En un modelo relacional, “Orders” se convierte en una tabla y “Order Items” en otra tabla con una fila por producto del pedido.

Para “listas en una celda”, trata cada valor como su propio registro. Una celda que dice “Email, SMS” normalmente significa que necesitas una tabla separada (o una tabla de unión) para rastrear canales limpiamente.

Las columnas mixtas son más silenciosas pero igual de arriesgadas. Sepáralas temprano para que cada campo guarde un hecho claro.

Crea tablas a partir de las entidades que encontraste

Una vez que puedas nombrar las cosas del mundo real en la hoja, convierte cada una en su propia tabla. Tu hoja deja de ser una gran rejilla y se vuelve un conjunto de listas más pequeñas y con propósito.

Si una fila mezcla detalles de dos cosas diferentes, probablemente necesita dos tablas. Una fila de tracker de ventas puede incluir info del cliente (nombre, teléfono), info del pedido (fecha, estado) e info del producto (SKU, precio). Los clientes no cambian cada vez que cambia un pedido, y los productos no dependen de un solo pedido. Separarlos evita ediciones duplicadas y valores inconsistentes.

Antes de finalizar, escribe una frase que describa el propósito de cada tabla. Si no puedes describir lo que representa una tabla sin decir “y además”, suele ser demasiado amplia.

Algunas reglas prácticas:

• Mantén atributos que describen la misma cosa y comparten el mismo ciclo de vida juntos (nombre del cliente y email del cliente).
• Mueve a su propia tabla cualquier cosa que pueda aparecer varias veces (múltiples items de un pedido, múltiples direcciones).
• Si una celda contiene una lista (valores separados por comas, columnas repetidas), eso es una tabla separada.
• Si dos conjuntos de campos cambian por razones distintas, sepáralos (estado del pedido vs info de contacto del cliente).

Luego nombra columnas de forma clara y consistente. Prefiere sustantivos simples y evita etiquetas vagas como “Info” o “Details”.

Elige claves que se mantengan estables en el tiempo

Elige una clave primaria para cada tabla desde temprano. Una buena clave es aburrida: nunca cambia, siempre está presente e identifica una fila y solo una fila.

Las claves naturales (valores del mundo real) pueden funcionar, pero solo si son realmente estables. Un SKU suele ser una buena clave natural porque está pensado para ser permanente. Los emails suenan estables, pero la gente cambia de email, comparte bandejas y crea duplicados como “john@” y “john.work@”. Nombres, teléfonos y direcciones cambian y no son garantía de unicidad.

Un valor seguro por defecto es un ID autogenerado (como customer_id, order_id). Mantén el identificador natural como un campo normal y añade una regla de unicidad cuando encaje con tus reglas de negocio. Si un email cambia, el customer_id se mantiene y los pedidos relacionados siguen apuntando al cliente correcto.

Reglas simples de claves:

• Usa un ID auto cuando el identificador del mundo real pueda cambiar, faltar o reutilizarse.
• Usa una clave natural solo cuando la controles y esté diseñada para ser permanente (por ejemplo, SKU).
• Marca campos como únicos solo cuando los duplicados serían un error.
• Permite NULL solo cuando “desconocido” sea un estado válido; si no, exige un valor.
• Escribe qué significa “único” (único por tabla, por compañía o por periodo de tiempo).

Ejemplo: en una tabla Contacts, usa contact_id como clave primaria. Mantén email como único solo si tu regla es un contacto = un email. Permite que phone esté vacío porque no todo el mundo lo comparte.

Mapea relaciones sin adivinar

La mayoría de errores vienen de adivinar cómo se relacionan las cosas. Usa una regla simple: si una fila “posee” muchas de algo, eso es uno-a-muchos. Coloca la clave foránea en el lado “muchos”.

Ejemplo: un Customer puede tener muchos Orders. La tabla Orders debe almacenar customer_id. Si guardas una lista de números de pedido separada por comas dentro de Customers, pronto aparecerán duplicados y datos faltantes.

Muchos-a-muchos es la trampa común de las hojas. Si un Order puede incluir muchos Products y un Product puede aparecer en muchos Orders, necesitas una tabla de unión (a menudo llamada line items). Normalmente incluye order_id, product_id, además de campos como quantity y el price en el momento de la compra.

Las relaciones uno-a-uno son raras. Tienen sentido cuando los datos extra son opcionales o se mantienen separados por privacidad o rendimiento (por ejemplo, User y UserProfile). Son una señal de advertencia cuando separas una tabla solo porque la hoja tenía dos pestañas.

El historial necesita su propia estructura. Si los valores pueden cambiar con el tiempo (estado, precio, dirección), evita sobrescribir una sola columna. Almacena los cambios como filas en una tabla de historial para poder responder “¿qué era cierto en esa fecha?”.

Normaliza lo suficiente para evitar contradicciones

Una regla simple: guarda un hecho en un solo lugar. Si el teléfono de un cliente aparece en cinco filas, alguien actualizará cuatro y fallará en la quinta.

Normalizar en términos prácticos:

1NF, 2NF, 3NF en términos prácticos

Primera forma normal (1NF) significa que cada celda contiene un valor. Si una columna contiene “red, blue, green” o “SKU1|SKU2|SKU3”, eso es una lista oculta. Divídela en filas en una tabla relacionada.

Segunda forma normal (2NF) aparece sobre todo en los line items. Si tienes OrderItems y la clave es (OrderID, ProductID), entonces campos como CustomerName no pertenecen allí. Dependen del pedido, no del producto.

Tercera forma normal (3NF) significa que los campos no claves no deberían depender de otros campos no claves. Ejemplo: si guardas ZipCode y City, y City se determina por ZipCode, corres el riesgo de inconsistencias.

Un auto-chequeo rápido:

• ¿Podría editarse el mismo valor en más de un lugar?
• ¿Un cambio forzaría a actualizar muchas filas?
• ¿Estás almacenando etiquetas que se pueden derivar de un ID?
• ¿Se guardan totales junto a las filas crudas que los generan?

Cuándo está bien desnormalizar

Desnormaliza principalmente para reportes de lectura intensiva y hazlo de forma segura: trata la tabla de reporte como una copia que puedes reconstruir. Mantén las tablas normalizadas como la fuente de verdad.

Para valores derivados como totales, saldos y estados, no los dupliques a menos que tengas una regla clara para recalculados. Un enfoque práctico: guarda transacciones crudas, calcula totales en consultas y solo cachea totales cuando el rendimiento lo exija.

Trampas comunes de modelado que generan limpiezas futuras

La mayoría de problemas de “funcionó en la hoja” vienen del significado, no de las herramientas. El objetivo es que cada fila diga una cosa clara, de la misma manera, cada vez.

Trampas comunes:

• Usar nombres como IDs. “John Smith” no es un identificador único y los nombres cambian. Usa un ID generado (o un email verificado o teléfono) y trata los nombres para mostrar como etiquetas.
• Empaquetar listas en una celda. Parece simple, pero rompe búsquedas, validación y reportes. Las listas pertenecen a una tabla relacionada.
• Mezclar estado actual con historial. Una columna Status no puede decirte a la vez el último estado y cómo cambió. Si el tiempo importa, guarda cambios de estado como eventos con timestamp.
• Sobrecargar una tabla para significar varias cosas. Una hoja de Contacts que incluye clientes, proveedores y empleados suele acabar con campos que solo aplican a algunas filas. Separa por rol, o mantén una tabla Person compartida y añade tablas por rol.
• Ignorar campos obligatorios vs opcionales. Si campos clave pueden quedar en blanco, obtendrás filas que no pueden unirse limpiamente. Decide qué es obligatorio y hazlo cumplir temprano.

Si tu tabla Orders tiene columnas como Item 1, Item 2, Item 3, estás ante un grupo repetido. Planea una tabla Orders y otra OrderItems.

Lista rápida antes de confirmar el esquema

Antes de bloquear el esquema, haz una pasada final por claridad. La mayoría del dolor en bases de datos viene de atajos pequeños que parecían inofensivos al principio.

Pregúntate si cada tabla responde a una pregunta simple. “Customers” debería significar clientes, no clientes más su último pedido más notas de llamada. Si no puedes describir una tabla en una frase corta, está mezclando cosas.

Comprobaciones finales:

• ¿Puedes apuntar a la columna (o conjunto de columnas) que identifica de forma única cada fila, aun cuando los nombres cambien?
• ¿Alguna celda contiene más de un valor (etiquetas separadas por comas, múltiples emails, columnas Item1/Item2)? Si es así, sepáralo en una tabla hija.
• Para cada relación, ¿está almacenada como una clave foránea intencional? Para muchos-a-muchos, ¿tienes una tabla de unión?
• ¿Los campos importantes tienen reglas (obligatorios donde la falta rompe el proceso, únicos donde duplicados serían dañinos)?
• ¿Puedes actualizar un hecho (dirección del cliente, precio del producto, rol del empleado) en exactamente un lugar?

Prueba de realidad: imagina que alguien ingresa el mismo cliente dos veces con una ortografía ligeramente diferente. Si tu esquema facilita eso, añade una clave mejor o una regla de unicidad.

Ejemplo: convertir una hoja de tracker de ventas en tablas limpias

Imagina un tracker de ventas donde cada fila es un deal. Tiene columnas como Customer Name, Customer Email, Deal Amount, Stage, Close Date, Products (lista separada por comas) y Notes (a veces varias notas en una celda).

Esa única fila oculta dos grupos repetidos: products (un deal puede incluir muchos productos) y notes (un deal puede tener muchas notas). Aquí es donde las conversiones suelen fallar, porque las listas en celdas son difíciles de consultar y fáciles de contradecir.

Un modelo “después” limpio que refleja cómo se comporta el trabajo:

• Customers (CustomerId, Name, Email)
• Deals (DealId, CustomerId, Amount, Stage, CloseDate)
• Products (ProductId, Name, SKU)
• DealProducts (DealId, ProductId, Quantity, UnitPrice)
• DealNotes (NoteId, DealId, NoteText, CreatedAt)

CustomerId, DealId y ProductId son identificadores estables. DealProducts resuelve la relación muchos-a-muchos: un deal puede incluir muchos productos y un producto puede aparecer en muchos deals. DealNotes mantiene las notas separadas, para que no termines con columnas “Note 1, Note 2, Note 3”.

Antes de modelar, un reporte como “ingresos por producto” significa dividir cadenas y esperar que la gente escriba nombres consistentemente. Después de modelar, se convierte en una consulta sencilla sobre DealProducts unida a Deals y Products.

Siguientes pasos: pasa del esquema a una app funcional

Una vez que tu esquema se ve bien en papel, pásalo a una base de datos real y pruébalo con datos reales. No importes todo a la vez. Carga un pequeño lote primero, arregla lo que rompa y repite.

Un orden práctico que mantiene el riesgo bajo:

• Crea las tablas y relaciones.
• Importa de 50 a 200 filas, verifica totales y revisa registros.
• Arregla problemas de mapeo (columnas equivocadas, IDs faltantes, duplicados), luego re-importa.
• Cuando sea estable, carga el resto.

Añade reglas de validación temprano para que los hábitos desordenados de hojas no vuelvan. Haz campos obligatorios verdaderamente obligatorios, limita valores permitidos (como status), valida formatos (fechas y emails) y usa claves foráneas para que no puedas crear un pedido para un cliente que no existe.

Después, deja de usar la hoja para actualizaciones. Proteger tus datos es mucho más fácil cuando la gente tiene formularios simples y flujos claros.

Si quieres convertir el esquema en una herramienta interna sin escribir código, AppMaster (appmaster.io) puede ayudar: modelas tablas y relaciones visualmente y luego generas un backend listo para producción, una web app y apps móviles nativas desde el mismo modelo.