A mi criterio, la dimensión de tipo 2 es la que puede darnos trazabilidad de manera más legible; dado que cada registro es una captura en el tiempo donde el id dicta la secuencia de los cambios; la desventaja que la dimensión puede llenarse rápido con muchos registros relacionados a los cambios de la misma persona/objeto.
Introducción a BI y Data Warehouse
¿Qué es BI y Data Warehousing?
Niveles de analítica y jerarquía del conocimiento
Conceptos de BI: Data Warehouse, Data Mart, Dimensiones y Hechos
Base de datos OLTP vs. OLAP
Metodologías de Data Warehouse
Quiz: Introducción a BI y Data Warehouse
Modelos dimensionales
Data Warehouse, Data Lake y Data Lakehouse: ¿Cuál utilizar?
Tipos de esquemas dimensionales
Dimensiones lentamente cambiantes
Dimensión tipo 1
Dimensión tipo 2
Dimensión tipo 3
Tabla de hechos (fact)
Configuración de herramientas para Data Warehouse y ETL
Modelado dimensional: identificación de dimensiones y métricas
Modelado dimensional: diseño de modelo
Quiz: Modelos dimensionales
ETL para inserción en Data Warehouse
Documento de mapeo
Creación del modelo físico
Extracción: querys en SQL
Extracción en Pentaho
Transformación: dimensión de cliente
Carga: dimensión de cliente
Soluciones ETL de las tablas de dimensiones y hechos
Parámetros en ETL
Orquestar ETL en Pentaho: job
Revisión de todo el ETL
Quiz: ETL para inserción en Data Warehouse
Cierre
Reflexiones y cierre
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Dimensión tipo 3
11/26Recursos
Aportes 4
Preguntas 1
Ordenar por:
La dimensión tipo 3 es aquella que trata los cambios en los atributos de las dimensiones lentamente cambiantes añadiendo una nueva columna con el valor nuevo y manteniendo el valor antiguo en la columna original. Se guarda un nivel de historial de cambios, pero se limita el número de cambios que se pueden almacenar.
Un ejemplo práctico de dimensión tipo 3 podría ser el siguiente:
Supongamos que tenemos una dimensión de productos con los atributos código, nombre, precio y categoría.
Si un producto cambia de categoría, añadimos una nueva columna con la categoría nueva y dejamos la categoría antigua en la columna original. De esta forma, podemos tener un solo registro por producto, con dos columnas de categoría: la actual y la anterior.
Esto nos permite comparar los datos según la categoría nueva o la antigua, pero solo podemos guardar un cambio por producto. Si el producto cambia de categoría más de una vez, tendremos que elegir qué valor guardar y cuál descartar.
Profe para mi según lo explicado y combinandos las dos tipologias me quedaria de la siguiente manera , agradeceria feedback
como conclusión entonces… al usar el SCD 3, conoceríamos los cambios a nivel de columna y si agregamos los campos start_date y end_date, tendríamos las fechas de cambios a nivel de fila
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?