Los problemas analíticos se acaban remontando a los datos subyacentes. La duplicación de registros de clientes, las cifras de ingresos que no coinciden en los informes y los Dashboards que se contradicen entre sí no son problemas de visualización ni de consulta; son problemas de esquema y la normalización de datos es la forma en que los equipos los solucionan en origen.

A continuación, explicaremos cómo funciona la normalización de datos, qué aspecto tiene un esquema normalizado en la práctica y dónde aparecen las verdaderas ventajas y desventajas para los equipos de análisis y almacenes.

Aspectos destacados

• La normalización de datos estructura una base de datos relacional de modo que cada dato resida en un solo lugar. Esto elimina los valores duplicados y contradictorios.

• Los equipos de análisis pueden aplicar la normalización en un pipeline si crean primero tablas de entidades de la capa central normalizada y luego añaden una capa de informes desnormalizada.

• Un proveedor de servicios de pago moderno puede sincronizar los datos de los pagos directamente en el almacén de una empresa. Esto les proporciona a los esquemas normalizados un origen completo y reciente sobre el que basarse sin necesidad de enrutar datos financieros sensibles a través de conectores de terceros.

¿Qué es la normalización de datos?

La normalización de datos es el proceso de organizar una base de datos relacional de modo que cada dato resida en un solo lugar. Para ello, se dividen los datos en tablas relacionadas y se vinculan mediante claves en lugar de repetir los mismos valores en las filas.

El objetivo es la coherencia. A medida que crece el volumen de datos, esa disciplina estructural es lo que separa un almacén en el que puedes confiar de uno que estás auditando constantemente.

¿Por qué es importante la normalización de datos para la precisión y la gobernanza de los análisis?

Los datos no normalizados pueden crear categorías de problemas que se agravan a medida que los datos crecen.

Cada una de las siguientes es una falla estructural en el esquema en sí:

• Anomalías de actualización: ocurren cuando el mismo hecho aparece en varias filas. Si el nombre de un plan de suscripción está almacenado directamente en cada fila de la factura, cambiar el nombre del plan significa actualizar miles de registros, y el hecho de omitir solo uno genera una discrepancia. En un esquema normalizado, el nombre del plan se encuentra en una tabla de planes; la factura solo contiene un plan_id.

• Anomalías de inserción: ocurren cuando no se puede registrar algo sin registrar algo más no relacionado. En una tabla plana que almacena juntos los datos de clientes y pedidos, no puedes agregar un cliente nuevo hasta que haga un pedido, lo que significa que la tabla se rompe en el momento en que tu equipo de ventas comienza a cargar prospectos en el almacén.

• Anomalías de eliminación: ocurren cuando la eliminación de un registro específico elimina sin querer datos importantes y no relacionados. Si eliminas el último pedido de un cliente en una tabla plana, habrás perdido también su información de contacto, porque no tenía un lugar propio.

¿Cuáles son las principales formas normales?

Las formas normales son una secuencia de reglas cada vez más estrictas sobre cómo deben estructurarse los datos.

Los equipos que utilizan la normalización de datos deben comprender las formas hasta la tercera forma normal (3NF) incluida para tomar buenas decisiones sobre los esquemas. A menudo se describe una base de datos como «normalizada» si cumple la 3NF.

• Primera forma normal (1NF): requiere que cada columna contenga valores atómicos: sin listas, cadenas separadas por comas ni matrices empaquetadas en un solo campo. Una columna de productos que contenga «camisa, pantalones, chaqueta» no cumple la 1NF. Tres filas con un product_id y un product_name cada una la cumplen.

• Segunda forma normal (2NF): se basa en la 1NF y requiere que cada columna que no sea clave dependa de la clave principal completa, no solo de una parte de ella. Si una tabla de partidas de pedido usa «(order_id, product_id)» como clave pero también almacena la ciudad del cliente, que depende solo de order_id, se trata de una dependencia parcial y de una infracción de la 2NF. La ciudad del cliente pertenece a la tabla de pedidos.

• Tercera forma normal (3NF): elimina las dependencias transitivas, lo que significa columnas que no son clave y que dependen de otras columnas que no son clave en lugar de la propia clave. Si una tabla de pedidos almacena tanto zip_code como city, y la ciudad está determinada por el código postal y no por el pedido, esos campos pertenecen a una tabla de geografía separada.

• Forma normal de Boyce-Codd (BCNF): esta es una versión más estricta de la 3NF que maneja casos extremos relacionados con claves candidatas superpuestas. Para los esquemas de análisis, llegar a la 3NF es suficiente.

¿Cómo funciona la normalización de datos en la práctica?

La forma más clara de ver lo que realmente hace la normalización es comenzar con una tabla defectuosa y arreglarla. Este es un ejemplo de una tabla de pedidos no normalizada y una explicación de lo que le sucede después de la normalización.

Tabla de pedidos no normalizada

Hay tres problemas inmediatos con esta tabla. El correo electrónico de Ana aparece dos veces: si lo actualizas en una fila, habrás creado un conflicto. El nombre y la categoría del producto se repiten en cada fila de pedido, por lo que cambiar una categoría significa modificar todos los pedidos históricos que la incluían. Y no hay forma de agregar un nuevo cliente o producto sin asociarle un pedido.

Después de la normalización, tendrías tres tablas:

• Clientes: customer_id, name, email
  
• Productos: product_id, name, category
  
• Pedidos: order_id, customer_id, product_id, qty, unit_price
  

El correo electrónico de Ana figura una vez. La categoría de los auriculares figura una vez. Los pedidos hacen referencia a ambos mediante un ID. Una sentencia de SELECT de dos uniones de lenguaje de consulta estructurado (SQL, por sus siglas en inglés) puede combinar datos de varias tablas en función de condiciones comunes: un costo pequeño y permanente para un esquema que no acumula errores a medida que escala.

¿Cuáles son las desventajas comunes de la normalización de datos?

Si bien tiene beneficios importantes, la normalización también puede introducir costos reales para los equipos.

Las desventajas se dividen en tres áreas:

• Complejidad de la consulta: cada relación que normalices en su propia tabla es una unión que escribirás más adelante. Un informe que podías leer desde una sola tabla plana ahora requiere tres uniones, y la sobrecarga cognitiva se acumula en un equipo de analistas que trabajan directamente en SQL.

• Esfuerzo de modelado inicial: diseñar un esquema normalizado requiere comprender el dominio lo suficientemente bien como para identificar entidades, sus atributos y las relaciones entre ellos. Los equipos que están bajo presión de enviar suelen omitir esto para crear estructuras planas que parecen más fáciles en el momento pero que se vuelven costosas más adelante.

• Rendimiento de lectura: en tablas muy grandes, las uniones son más lentas que los escaneos. Los almacenes de datos modernos (p. ej., BigQuery, Snowflake, Redshift) tienen optimizadores de consultas que manejan las uniones razonablemente bien, pero las estructuras desnormalizadas a menudo ganan en velocidad bruta de consulta para cargas de trabajo analíticas contra miles de millones de filas.

¿Cómo aplican los equipos de análisis y almacenes la normalización de datos en los flujos de trabajo?

En la práctica, los equipos de análisis dividen en capas la normalización en un pipeline. Los diferentes niveles de estructura tienen finalidades y preocupaciones distintas: la integridad de los datos se maneja en la capa central normalizada, y el rendimiento de las consultas y la ergonomía de los analistas se manejan en la capa de informes.

A continuación, encontrarás la explicación:

• Capa de staging: aquí llegan los datos sin procesar, casi tal cual proceden del origen. En esta fase hay poca o ninguna transformación. El objetivo es que los datos lleguen intactos al almacén y se puedan consultar, no que se modelen.

• Capa central normalizada: las herramientas de transformación producen tablas de entidades normalizadas a partir de la capa de staging: una para clientes, una para suscripciones y una para transacciones. Estas se asientan aproximadamente en la 3NF y sirven como fuente de la verdad para cualquier modelo posterior.

• Capa de informes: por encima de la capa central normalizada, los equipos crean tablas amplias y desnormalizadas diseñadas para la velocidad y la facilidad de uso en una herramienta de inteligencia empresarial (BI) como Tableau o Looker. El modelo de un Dashboard de ingresos puede unir cinco tablas normalizadas en una tabla de hechos amplia que la herramienta de BI lee directamente.

Cómo Stripe respalda datos más limpios y confiables para la normalización en etapas posteriores

La calidad de cualquier esquema normalizado depende por completo de la calidad y la integridad de los datos que lo alimentan. Los registros de transacciones obsoletos o incompletos pueden crear brechas de conciliación que ninguna cantidad de diseño cuidadoso de esquemas puede solucionar.

Esto es lo que un proveedor de servicios de pago puede ofrecer:

• Sincronización: Stripe Data Pipeline mueve los datos de Stripe (p. ej., cargos, clientes, suscripciones, reembolsos, disputas, transferencias) directamente a un almacén de datos o destino de almacenamiento en la nube, sin conectores de terceros en el medio ni límites de tasa de la interfaz de programación de aplicaciones (API).

• Integridad: Stripe garantiza la integridad de los datos al sincronizar todos los datos de Stripe, los informes financieros prediseñados y los conjuntos de datos seleccionados.

• Seguridad: Cuando los equipos enrutan los datos de Stripe a través de conectores de extracción, transformación y carga (ETL) de terceros, envían datos financieros confidenciales a la infraestructura de un proveedor adicional. Data Pipeline maneja el transporte directamente, lo que elimina ese intermediario y a un proveedor de la lista al revisar la seguridad de los datos.

Data Pipeline no reemplaza una plataforma ETL completa. Si combinas los datos de Stripe con datos de una decena de otras fuentes, aún necesitas herramientas de transformación. Pero esta solución está diseñada específicamente para sincronizar tus datos de Stripe mejor que un conector de terceros a fin de garantizar que tus datos financieros se sincronicen de manera confiable, segura y precisa.