El CRM cambia el código de un cliente durante una migración. Los pedidos antiguos conservan el código anterior y los nuevos utilizan el nuevo. Si el almacén de datos trata ambos códigos como entidades independientes, el informe divide la historia del cliente. Si los une sin una correspondencia fiable, puede mezclar personas o empresas diferentes.
Elegir claves exige separar tres preguntas: qué identifica el sistema de origen, qué entidad representa el negocio y qué fila concreta necesita referenciar un hecho.
Qué aporta cada tipo de clave
Una clave natural o de negocio procede del contexto que identifica el registro en el origen. Puede ser una referencia simple o una combinación, y su estabilidad depende de las reglas de ese sistema.
Una clave sustituta es un identificador asignado dentro del modelo. Permite que las relaciones del almacén no dependan directamente del formato del código externo y puede identificar versiones distintas de una dimensión.
La guía de dimensiones de Microsoft Fabric describe ambas claves y su papel en la integración de fuentes y el seguimiento histórico. Generar una clave sustituta no resuelve por sí solo qué registros representan la misma entidad. Esa correspondencia requiere una regla y evidencia propias.
| Concepto | Pregunta que responde | Ejemplo ilustrativo |
|---|---|---|
| Identificador del origen | ¿Qué registro reconoce este sistema? | CRM-A / C-17 |
| Identidad de entidad | ¿De qué cliente hablamos entre sistemas? | Cliente interno E-42 |
| Clave de fila de dimensión | ¿Qué versión describe el hecho? | Fila 901 o fila 902 |
No todos los modelos necesitan materializar esas tres identidades como columnas separadas. Sí necesitan explicar sus relaciones sin confiar en coincidencias accidentales.
Un cambio de código con correspondencia validada
Supón que el responsable del CRM confirma que C-17 pasa a N-804 durante una migración. Conserva esa correspondencia y su procedencia. No la deduzcas únicamente de que los nombres se parecen.
El cliente también cambia de segmento comercial. Si el informe necesita mostrar el segmento que tenía cada pedido cuando ocurrió, el modelo puede conservar versiones de dimensión:
| Clave de dimensión | Entidad | Segmento | Inicio de vigencia | Fin de vigencia exclusivo |
|---|---|---|---|---|
| 901 | E-42 | Local | 1 de enero | 1 de febrero |
| 902 | E-42 | Regional | 1 de febrero | Sin fin conocido |
Un pedido del 20 de enero debe relacionarse con la fila 901 si la regla usa la fecha del pedido para determinar el segmento histórico. Un pedido del 10 de febrero se relaciona con 902. El cambio de código externo se resuelve mediante la correspondencia; el cambio de segmento se resuelve mediante la vigencia. Son problemas relacionados, pero diferentes.
Elige el tratamiento histórico según la pregunta
Si el usuario quiere reclasificar toda la historia según el segmento actual, conservar versiones no basta para elegir la vista adecuada. El informe debe indicar si aplica contexto histórico o actual.
Evita actualizar todas las relaciones al miembro más reciente por comodidad. Esa operación puede hacer que una comparación de periodos atribuya al pasado una clasificación que todavía no existía.
A la inversa, conservar cada corrección tipográfica como una nueva versión puede añadir complejidad sin responder a una necesidad analítica. Define qué atributos se historifican y qué cambios sustituyen el valor anterior.
Protege la carga de hechos
Para cada hecho, resuelve el origen, la identidad y la vigencia necesaria. Comprueba que existe una sola fila de dimensión aplicable. Los intervalos que se solapan pueden duplicar el hecho al unirlo; un hueco puede dejarlo sin contexto.
Si el hecho llega antes que la dimensión, no lo descartes silenciosamente. Define un tratamiento de pendiente, miembro inferido o valor desconocido según el diseño, y una reconciliación posterior.
Un evento tardío necesita resolver la versión que corresponde a su fecha de negocio, no necesariamente la versión vigente el día en que se carga. Relaciona esa decisión con la política de datos tardíos.
Mantén estables las referencias al reprocesar
Si regeneras una dimensión y asignas claves nuevas sin actualizar de forma coherente los hechos, las relaciones existentes pueden quedar inválidas. Conserva la correspondencia o publica un conjunto reconstruido con integridad comprobada.
La idempotencia de la carga debe cubrir también la creación de miembros: repetir un lote no debería crear otra fila equivalente por cada intento.
Prueba códigos iguales en dos fuentes, cambio de código, solapamiento de vigencias y llegada de un hecho antiguo. El resultado esperado debe identificar la entidad y la fila de dimensión, además del total del informe.
Si estás construyendo un almacén de datos empresarial, lleva a Nexeus Big Data ejemplos de cambios de identificador y las preguntas históricas del negocio. Permiten definir claves y correspondencias que conserven el significado de los hechos durante las migraciones y los reprocesamientos.