Una base de datos de productos puede parecer correcta y aun así contener ambigüedades que impiden comparar, integrar o analizar la información. El problema suele aparecer cuando varios conceptos se concentran en un solo campo: nombre comercial, fabricante, ingrediente, presentación, tamaño y descripción terminan mezclados en una cadena de texto imposible de normalizar con fiabilidad.
En proyectos de Business Intelligence, la calidad analítica comienza antes del tablero. Empieza en el modelo de datos y en la decisión de qué representa exactamente cada atributo.
Product master data: una ficha que separa identidades
Los datos maestros de producto deben permitir responder preguntas básicas sin interpretar manualmente una descripción. ¿Cuál es el producto? ¿Quién lo fabrica? ¿Qué variante es? ¿Qué presentación se está registrando? ¿Qué fuente respalda el dato? Si la respuesta depende de leer un texto libre, la estructura puede mejorarse.
Nombre del producto
El nombre es el identificador que se presenta al usuario o al catálogo, pero no debería absorber todos los demás atributos. Una convención estable evita variantes innecesarias de mayúsculas, abreviaturas, signos y orden de palabras.
Fabricante
El fabricante o entidad responsable debe tratarse como un campo propio. Eso permite consolidar productos por origen, detectar cambios de proveedor y evitar que una diferencia tipográfica genere entidades duplicadas.
Ingrediente activo o nombre común
En algunas categorías, el producto contiene un componente que tiene identidad propia y que no coincide con la marca. Los medicamentos ofrecen un ejemplo de alto impacto: la FDA explica que un medicamento genérico aprobado debe compartir el ingrediente activo con su producto de referencia y distingue además concentración, forma farmacéutica y vía de administración.
Por eso, al estructurar datos sanitarios, conviene separar el principio activo, marca y fabricante de un medicamento. “Sildenafilo”, por ejemplo, es el nombre de una sustancia; MedlinePlus muestra que puede aparecer asociado a diferentes marcas y presentaciones. La relación entre esos campos no convierte ninguno de ellos en sinónimo del otro.
Concentración
La concentración o potencia debe almacenarse de forma estructurada, con una unidad normalizada. Mezclar “10”, “10 mg”, “10MG” y “0.01 g” como textos diferentes dificulta agrupaciones y controles. La normalización no significa cambiar el dato original sin trazabilidad: lo correcto es conservar el valor de origen cuando sea necesario y mantener un valor normalizado para análisis.
Forma o presentación
Tableta, solución, cápsula, envase, botella o cualquier otra forma relevante debe representarse de manera consistente. En datos médicos, la forma farmacéutica no es un detalle decorativo: la FDA la trata como uno de los atributos que se comparan en la aprobación de medicamentos genéricos.
Identificadores
SKU, códigos internos, códigos de barras, identificadores regulatorios y claves de proveedor pueden coexistir. El error común es asumir que uno de ellos sirve universalmente como clave primaria. Una arquitectura robusta distingue el identificador interno de los identificadores externos y mantiene reglas claras de unicidad.
Fuente del dato
Un campo “source” o una tabla de procedencia permite saber si el dato llegó de un proveedor, de un catálogo interno, de una autoridad pública o de una carga manual. La procedencia es esencial cuando dos fuentes entran en conflicto.
Normalización
Normalizar no es solo corregir ortografía. Implica definir catálogos controlados, unidades, reglas de capitalización, relaciones entre entidades y criterios para resolver equivalencias. Cuando el dominio es sensible, los cambios automáticos deben poder auditarse.
Este trabajo forma parte del análisis e integración de información: antes de combinar fuentes, hay que decidir qué campos pueden compararse y cuáles solo parecen similares.
Duplicados y entradas en conflicto
Dos registros con nombres parecidos pueden ser el mismo producto, pero también variantes distintas. La deduplicación debería apoyarse en varios atributos: fabricante, identificador, presentación, ingrediente, concentración y fuente. Un algoritmo que solo compare nombres puede fusionar entidades que deberían permanecer separadas.
Los conflictos también deben registrarse. Si una fuente indica un fabricante y otra uno diferente, sobrescribir silenciosamente uno de los valores elimina información útil para investigar el problema.
Por qué los datos malos producen decisiones malas
Una métrica agregada es tan confiable como la clasificación que la alimenta. Si marcas y fabricantes se mezclan, los reportes por proveedor serán incorrectos. Si las unidades no se normalizan, las comparaciones serán engañosas. Si no hay trazabilidad, será difícil explicar por qué cambió un indicador.
En sectores de alto impacto, como salud, el problema deja de ser únicamente analítico. La identidad de un producto puede tener consecuencias operativas y de seguridad. Por eso el modelo debe ser suficientemente preciso para evitar inferencias basadas en campos ambiguos.
Linaje del dato y cambios en el tiempo
Un dato de producto no es estático. Puede cambiar el fabricante registrado, la presentación, un identificador o la fuente de referencia. Por eso es útil conservar linaje: de qué sistema llegó el valor, cuándo se importó, qué transformación se aplicó y qué versión sustituyó a la anterior. Sin historial, una corrección parece un dato nuevo y se pierde la posibilidad de explicar por qué cambió un reporte.
Catálogos controlados y reglas de validación
Los campos más repetitivos funcionan mejor cuando utilizan catálogos controlados. Fabricantes, formas, unidades y tipos de identificador deberían tener reglas de escritura y validación. Esto reduce variantes como abreviaturas distintas para la misma entidad y permite detectar valores que no pertenecen al conjunto esperado.
Las reglas automáticas, sin embargo, necesitan excepciones documentadas. Un sistema no debería “corregir” silenciosamente un valor solo porque se parece a otro. En dominios de alto impacto, una coincidencia aproximada debe generar una revisión cuando existe riesgo de fusionar productos diferentes.
Gobernanza: quién puede corregir un dato
La calidad también depende de responsabilidades. Conviene definir quién puede crear productos, quién aprueba cambios, qué evidencia se necesita para modificar atributos críticos y cómo se resuelven conflictos entre fuentes. Este flujo evita que cada equipo mantenga su propia versión de la misma entidad.
Cuando la organización sabe qué campo es autoridad para cada atributo y conserva el dato de origen, el análisis deja de depender de correcciones manuales hechas al final del proceso.
Definir estas reglas desde el origen reduce retrabajo.
Checklist para un modelo de producto
- Nombre de producto separado de fabricante.
- Ingrediente o componente principal en campo propio cuando corresponda.
- Concentración y unidad estructuradas.
- Forma y presentación normalizadas.
- Identificadores internos y externos diferenciados.
- Fuente y fecha de actualización disponibles.
- Reglas documentadas para duplicados.
- Conflictos conservados hasta poder resolverlos.
Un buen modelo de datos no intenta meter toda la identidad del producto en un nombre largo. La separa en atributos que pueden validarse, relacionarse y actualizarse. Esa estructura mejora la calidad de los reportes y permite detectar errores antes de que se conviertan en decisiones.
Fuentes utilizadas para el ejemplo farmacéutico: FDA — Generic Drug Facts y MedlinePlus — Sildenafil.
Comentarios recientes