Surrogate keys y SCD Tipo 2

Objetivo

Conservar historia de atributos cambiantes.

Explicación

Una surrogate key identifica una versión de dimensión. En SCD2, cuando cambia un atributo relevante, cierras la versión anterior y abres otra con effective_from/effective_to/current_flag. Un modelo analítico mal definido puede producir métricas correctas en apariencia pero equivocadas por duplicación o grain. Aquí practicarás cómo convertir reglas de negocio en estructuras y tests que puedan verificarse automáticamente. Para trabajar Surrogate keys y SCD Tipo 2 de forma profesional, no te quedes con el ejemplo: identifica la entrada, ejecuta el caso base, provoca al menos un caso incorrecto y compara el resultado con un control independiente. En este laboratorio el criterio de salida es concreto: Cada fecha de pedido encuentra exactamente una versión vigente. La verificación principal será: No debe haber intervalos solapados para el mismo customer_id. Si no puedes explicar por qué pasa esa comprobación, vuelve al paso anterior antes de continuar.

Contexto profesional

Un modelo analítico mal definido puede producir métricas correctas en apariencia pero equivocadas por duplicación o grain. Aquí practicarás cómo convertir reglas de negocio en estructuras y tests que puedan verificarse automáticamente.

Ejemplo real

customer_sk | customer_id | country | effective_from | effective_to | is_current

Archivos o datos de entrada

• data/customer_history.csv

Práctica guiada

Identifica qué filas corresponden al mismo customer_id.

Laboratorio paso a paso

• Prepara el entorno y localiza los datos/archivos de entrada: data/customer_history.csv. Antes de modificar nada, anota el número de filas, columnas u objetos que esperas usar.
• Reproduce el ejemplo real de la lección y guarda la salida. No avances hasta poder explicar qué hace cada bloque relacionado con «Surrogate keys y SCD Tipo 2».
• Ejecuta la práctica guiada: Identifica qué filas corresponden al mismo customer_id. Documenta el comando, consulta o acción exacta y el resultado obtenido.
• Resuelve el reto sin mirar la solución: Determina qué versión debe relacionarse con un pedido histórico según order_date. Si falla, registra el mensaje de error y formula una hipótesis antes de cambiar código.
• Compara tu resultado con el criterio esperado: Cada fecha de pedido encuentra exactamente una versión vigente. Después ejecuta la comprobación: No debe haber intervalos solapados para el mismo customer_id.
• Provoca deliberadamente un caso problemático relacionado con este error frecuente: Relacionar siempre con la versión current reescribe el pasado.. Comprueba que sabes detectarlo y corregirlo.

Reto sin ayuda

Determina qué versión debe relacionarse con un pedido histórico según order_date.

Resultado esperado

Cada fecha de pedido encuentra exactamente una versión vigente.

Cómo verificarlo

No debe haber intervalos solapados para el mismo customer_id.

Checklist de validación

• El resultado cumple: Cada fecha de pedido encuentra exactamente una versión vigente.
• Has ejecutado esta verificación y puedes explicar el resultado: No debe haber intervalos solapados para el mismo customer_id.
• Has probado al menos un caso límite o dato inválido y el comportamiento es explícito, no silencioso.
• Puedes repetir la práctica desde cero sin copiar la solución y dejar evidencia (consulta, commit, captura o salida de consola).

Errores frecuentes

• Relacionar siempre con la versión current reescribe el pasado.

Qué debes recordar

SCD2 preserva cambios históricos mediante versiones de dimensión.

Preguntas de entrevista

• ¿Cuál es el grain y cómo lo demostrarías? Aplícalo concretamente a «Surrogate keys y SCD Tipo 2».
• ¿Qué test detectaría el error más probable de este modelo? Explica qué evidencia enseñarías al revisor.

Siguiente paso

Aplicarás tests de calidad.

Recursos de esta lección