Los problemas de análisis acaban por rastrear los datos subyacentes. Los registros de cliente duplicados, las cifras de ingresos que no coinciden en todos 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 el modo en que los equipos los resuelven de origen.

A continuación, analizaremos cómo funciona la normalización de datos, cómo es un esquema normalizado en la práctica y dónde aparecen las compensaciones reales para los equipos de análisis y almacén de datos.

Destacados

• La normalización de datos estructura una base de datos relacional para que cada fragmento de información resida en un único lugar. Esto elimina los valores duplicados y contradictorios.

• Los equipos de análisis pueden aplicar la normalización en todo el proceso si crean en primer lugar tablas de entidades principales normalizadas y añaden posteriormente capas de informes desnormalizadas por encima.

• Un proveedor de servicios de pago moderno puede sincronizar los datos del pago directamente en el almacén de una empresa. Esto ofrece a los esquemas normalizados un origen completo y reciente desde el que trabajar sin crear una ruta de datos financieros confidenciales 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 para que cada fragmento de información resida en un único lugar. Para ello, tienes que dividir los datos en tablas relacionadas y vincularlas mediante claves en lugar de repetir los mismos valores en distintas filas.

El objetivo es la coherencia. A medida que aumenta el volumen de datos, esa disciplina estructural es lo que diferencia un almacén en el que puedes confiar de uno que auditas constantemente.

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

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

Cada uno de los siguientes ejemplos es un defecto estructural del propio esquema:

• Anomalías de actualización: se producen cuando el mismo dato aparece en varias filas. Si la información del nombre de un plan de suscripción está almacenada directamente en cada fila de la factura, cambiar el nombre del plan significa actualizar miles de registros, y omitir tan solo uno crea una discrepancia. En un esquema normalizado, el nombre del plan reside en una tabla de planes; la factura solo incluye un plan_id.

• Anomalías de inserción: ocurren cuando no puedes registrar algo sin registrar otra cosa no relacionada. En una tabla plana que almacena los datos de cliente y pedido juntos, no puedes añadir un nuevo cliente hasta que realice un pedido, lo que significa que la tabla se rompe en el momento en que tu equipo de ventas empieza a cargar clientes potenciales en el almacén.

• Anomalías de eliminación: ocurren cuando, al eliminar un registro específico, se eliminan accidentalmente datos importantes no relacionados. Si eliminas el último pedido de un cliente de una tabla plana, también pierdes su información de contacto porque no tenía una ubicación independiente.

¿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: nada de listas, ni cadenas separadas por comas, ni matrices empaquetadas en un único 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 sí la cumplen.

• Segunda forma normal (2NF): se basa en la 1NF al requerir que cada columna que no es clave dependa de toda la clave principal, no solo de una parte. Si una tabla de líneas de factura utiliza «(order_id, product_id)» como clave pero también almacena la ciudad del cliente, que solo depende 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, es decir, las 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 se determina por el código postal en lugar del pedido, esos campos pertenecen a una tabla de geografía independiente.

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

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

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

Tabla de pedidos no normalizada

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

Tras 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 se guarda una vez. La categoría de los auriculares se guarda una vez. Los pedidos hacen referencia a ambos mediante un ID. Una declaración SELECT de dos combinaciones de Structured Query Language (SQL) puede combinar datos de las distintas tablas establecido en condiciones comunes: un coste pequeño y permanente para un esquema que no acumula errores a medida que crece.

¿Cuáles son las compensaciones habituales de la normalización de datos?

Aunque tiene ventajas importantes, la normalización también puede suponer costes reales para los equipos.

Las compensaciones se dividen en tres áreas:

• Complejidad de la consulta: cada relación que normalizas en su propia tabla es una combinación que escribirás más adelante. Una consulta que podías leer en una tabla plana ahora requiere tres combinaciones, y la sobrecarga cognitiva se acumula en un equipo de analistas que trabaja directamente en SQL.

• Esfuerzo de modelado inicial: diseñar un esquema normalizado requiere comprender el dominio lo bastante bien como para identificar las entidades, sus atributos y las relaciones entre ellas. Los equipos bajo presión para entregar resultados a menudo omiten este paso y construyen estructuras planas que parecen más fáciles en el momento, pero que resultan caras más adelante.

• Rendimiento de lectura: en tablas muy grandes, las combinaciones son más lentas que los análisis. Los almacenes de datos modernos (p. ej., BigQuery, Snowflake, Redshift) tienen optimizadores de consulta que gestionan las combinaciones bastante bien, pero las estructuras desnormalizadas suelen ganar en velocidad de consulta sin procesar para cargas de trabajo analíticas con miles de millones de filas.

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

En la práctica, los equipos de análisis aplican niveles de normalización en todo el proceso. Los diferentes niveles de estructura tienen fines y problemas distintos: la integridad de los datos se gestiona en la capa central normalizada, y el rendimiento de la consulta y la ergonomía para los analistas se gestionan en la capa de informes.

Veamos cómo se hace:

• Capa de almacenamiento provisional: los datos sin procesar llegan aquí casi tal cual desde el origen. En esta fase apenas se realizan transformaciones. El objetivo es introducir los datos en el almacén intactos y listos para su consulta, no modelarlos.

• Capa central normalizada: las herramientas de transformación crean tablas de entidades normalizadas a partir de la capa de almacenamiento provisional: una para clientes, otra para suscripciones y otra para transacciones. Estas se sitúan aproximadamente en la 3NF y sirven de única fuente de información para cualquier modelo de nivel inferior.

• Capa de informes: por encima del núcleo normalizado, los equipos crean tablas amplias y desnormalizadas diseñadas para ser rápidas y fáciles de usar en una herramienta de inteligencia empresarial (BI) como Tableau o Looker. Un modelo de Dashboard de ingresos podría combinar cinco tablas normalizadas en una tabla de hechos más amplia que la herramienta de BI lee directamente.

Cómo ayuda Stripe a obtener datos más limpios y fiables para su posterior normalización

La calidad de cualquier esquema normalizado depende totalmente de la calidad y de lo completos que sean los datos que lo alimentan. Los registros de transacciones incompletos u obsoletos pueden crear lagunas en la conciliación que ningún diseño de esquema minucioso podrá solucionar.

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

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

• Exhaustividad: Stripe garantiza que los datos estén completos mediante la sincronización de todos los datos de Stripe, los informes financieros preintegrados y los conjuntos de datos depurados.

• Seguridad: Cuando los equipos dirigen los datos de Stripe a través de conectores de terceros de extracción, transformación y carga (ETL), están enviando datos financieros confidenciales a la infraestructura de un proveedor adicional. Data Pipeline gestiona el transporte directamente, lo cual elimina a ese intermediario y, por tanto, a un proveedor de tu lista para revisar la seguridad de los datos.

Data Pipeline no sustituye a una plataforma ETL completa. Si vas a combinar datos de Stripe con datos procedentes de otras muchas fuentes, seguirás necesitando herramientas de transformación. Sin embargo, esta solución se ha diseñado específicamente para sincronizar tus datos de Stripe mejor que con un conector de terceros, a fin de garantizar que tus datos financieros se sincronicen de forma fiable, segura y precisa.