No se trata de especificaciones técnicas. Se trata de pensar como un negocio. Considérelo el modelo para toda su casa de análisis. Si el plano es caótico, tu casa se desmorona. Si está estructurado y organizado, su equipo encontrará información rápidamente.
Estás mirando una hoja de cálculo llena de pedidos de clientes, precios de productos y fechas de venta. Es un desastre. Su “tablero” es lento. Ha intentado responder una pregunta simple como: ¿Cuántos ingresos generó la pizza el último trimestre? y terminé con números que no cuadran. ¿Por qué? Porque su modelo de datos es un puro desastre.
En esta publicación de blog, lo guiaré a través de los conceptos básicos de modelado de datos que todo ingeniero analítico debería conocer. Olvídese de Power BI y Microsoft Fabric por un segundo. Se trata de principios básicos: el por qué detrás de los modelos. Estas ideas funcionan independientemente de la herramienta.
Comencemos presentando el desafío. Imagina que diriges una pequeña pizzería. Su “base de datos” es una única hoja de Excel: ID del pedido, nombre del cliente, dirección, tipo de pizza, cantidad, precio. Parece bastante simple, ¿verdad? ¿El problema? El discurso de John Smith se repite en cada orden. Si se muda, tendrás que editar 37.000 filas de pedidos sólo para actualizar su dirección. No parece inteligente, ¿verdad?
Su modelo de datos es la solución. Literalmente dice: Los clientes viven en su propia mesa. Los pedidos se vinculan a los Clientes sin copiar direcciones. No se trata de cómo vas a visualizar los datos. Se trata de organizarlos para que los datos tengan sentido cuando hagas preguntas.
Sin embargo, el modelado de datos comienza mucho antes de que sus datos se almacenen en una hoja de cálculo o en una base de datos real. En las siguientes secciones, presentaremos conceptos básicos de modelado de datos, aquellos que deben implementarse en cada escenario de modelado de datos, independientemente del enfoque de modelado que planee adoptar o la herramienta que vaya a utilizar para la implementación física.
Así como un arquitecto no pasa directamente de una idea a un edificio terminado, un modelador de datos no crea un esquema de base de datos en un solo paso. El proceso avanza a través de tres niveles de detalle creciente, cada uno de los cuales tiene un propósito y una audiencia distintos. Piense en ello como un progreso desde un boceto conceptual hasta un plano arquitectónico detallado y un plan de construcción final utilizado por los constructores.
Modelo conceptual: el boceto de la servilleta.
Todo gran modelo de datos comienza no con código o tablas, sino con una conversación. El modelo conceptual es la primera vista de nivel más alto de sus datos. No es completamente técnico y se centra únicamente en comprender y definir los conceptos comerciales y las reglas que los gobiernan.
El modelo conceptual identifica las principales cosas o entidades que le interesan a una empresa y cómo se relacionan entre sí. Crea un vocabulario para hablar con las partes interesadas de la empresa y garantizar que hablan el mismo idioma.
Imagine un arquitecto reunido con un cliente en una cafetería. El cliente podría decir algo como: Quiero una casa familiar que se sienta abierta y conectada. El arquitecto toma una servilleta y dibuja algunas burbujas: cocina, sala de estar, dormitorios, y dibuja líneas entre ellas con la etiqueta "se conecta a" o "está separado de". No hay dimensiones, ni materiales, ni detalles técnicos. Se trata simplemente de capturar la idea central y garantizar que todos estén de acuerdo con los conceptos fundamentales. Ese boceto en servilleta es el modelo de datos conceptual.
Veamos un ejemplo real: eventos en un estadio. En un modelo conceptual para este escenario, identificaría varias entidades: estadio, evento, cliente, asistente y entrada. También notarás cómo estas entidades están interconectadas. Esta descripción general de alto nivel proporciona una imagen simplificada del flujo de trabajo empresarial dentro de la organización.
Un Estadio tiene un nombre y está ubicado en un país y ciudad específicos, lo que lo identifica de manera única. Este estadio puede albergar muchos eventos y puede haber muchos asistentes a estos eventos. Un Evento no puede existir fuera del Estadio donde está programado. A un evento puede asistir un asistente y puede haber muchos asistentes para un evento. Un Asistente es la entidad que asiste al evento. También pueden ser Clientes de la entidad Estadio (por ejemplo, visitando el museo del estadio o comprando en una tienda para fanáticos), pero eso no los convierte en asistentes de un evento específico. Finalmente, un Ticket representa la confirmación de que el asistente asistirá a un evento específico. Cada Entrada tiene un identificador único y un Asistente puede comprar varias Entradas.
Ahora quizás te preguntes: ¿por qué es esto importante? ¿Por qué alguien debería dedicar tiempo y esfuerzo a describir todas las entidades y las relaciones entre ellas?
Recuerde, el modelo de datos conceptual tiene que ver con generar confianza entre la empresa y las personas de datos, garantizando que las partes interesadas de la empresa obtengan lo que necesitan, explicado en un lenguaje común, para que puedan comprender fácilmente todo el flujo de trabajo. La configuración de un modelo de datos conceptual también proporciona a las partes interesadas del negocio una forma de identificar una amplia gama de preguntas comerciales que deben responderse antes de construir algo físico. Preguntas como: ¿El cliente y el asistente son la misma entidad (y por qué no lo son)? ¿Un asistente puede comprar varias entradas? ¿Qué identifica de forma única un evento específico?
Además, el modelo de datos conceptual representa procesos comerciales muy complejos de una manera más fácil de consumir. En lugar de revisar páginas y páginas de documentación escrita, puede echar un vistazo a la ilustración de entidades y relaciones, todas explicadas de forma fácil de usar, y comprender rápidamente los elementos centrales del proceso empresarial.
Modelo lógico: el modelo
Una vez que los equipos de datos y de negocios se alinean en el modelo de datos conceptual, el siguiente paso es diseñar un modelo de datos lógico. En esta etapa, nos basamos en el paso anterior identificando la estructura exacta de las entidades y proporcionando más detalles sobre las relaciones entre ellas. Debe identificar todos los atributos de interés para cada entidad, así como la cardinalidad de la relación.
Tenga en cuenta que, al igual que durante la fase de modelado de datos conceptuales, todavía no estamos hablando de ninguna plataforma o solución específica. La atención se centra todavía en comprender los requisitos comerciales y cómo estos requisitos se pueden traducir de manera eficiente en un modelo de datos.
Hay varios pasos para garantizar que el modelo conceptual evolucione exitosamente hacia un modelo lógico. Debe identificar los atributos de la entidad: los puntos de datos específicos que debe contener cada entidad. Luego identifique las claves candidatas: qué atributo, o conjunto de atributos, identifica de forma única una entidad específica. A partir de ahí, elija las claves principales según los hallazgos del paso anterior. También aplicará la normalización o desnormalización según corresponda (más sobre esto más adelante). A continuación, establezca relaciones entre entidades, valide cómo se interconectan y, si es necesario, divida entidades complejas en varias más simples. Luego identifique la cardinalidad de la relación, es decir, defina cuántas instancias de una entidad se relacionan con instancias de otra. Hay tres tipos principales: uno a uno (1:1), uno a muchos (1:M) y muchos a muchos (M:M). Finalmente, y de manera crítica, iterar y ajustar. En la vida real, es casi imposible encontrar un modelo de datos que se adapte inmediatamente a las necesidades de todos. Solicite comentarios a las partes interesadas del negocio y ajuste el modelo de datos lógico antes de materializarlo en forma física.
Los beneficios potenciales del modelo lógico son significativos. En primer lugar, sirve como la mejor prueba de control de calidad, identificando brechas y problemas en la comprensión del flujo de trabajo empresarial, lo que le permite ahorrar una cantidad significativa de tiempo y esfuerzo a largo plazo. Es mucho más fácil y menos costoso solucionar los problemas en esta etapa, antes de limitarse a una plataforma específica. La creación de un modelo de datos lógico puede considerarse parte del ciclo de modelado de datos ágil, que garantiza modelos más sólidos, escalables y preparados para el futuro. Y, en última instancia, sirve como modelo para la implementación física final.
Modelo físico: el plano de construcción.
Un modelo de datos físico representa el toque final: cómo se implementará realmente el modelo de datos en una base de datos específica. A diferencia de los modelos de datos conceptuales y lógicos, que son independientes de la plataforma y la solución, la implementación física requiere definir detalles de bajo nivel que pueden ser específicos de un determinado proveedor de bases de datos.
Existe una lista completa de pasos necesarios para que la implementación de su modelo de datos físicos sea exitosa. Debe elegir la plataforma; esta decisión da forma a sus futuros principios de diseño. Luego, traduzca las entidades lógicas en tablas físicas; dado que una base de datos real no admite el nivel abstracto de una entidad lógica, debe definir el tipo de datos de cada atributo: número entero, número decimal o texto sin formato. Además, cada tabla física debe depender de claves (primaria, externa, única) para garantizar la integridad de los datos.
También debe establecer relaciones basadas en las columnas clave. Aplique la normalización o desnormalización según corresponda; recuerde, en los sistemas OLTP, las tablas deben normalizarse (normalmente a 3NF) para reducir la redundancia y admitir operaciones de escritura de manera eficiente, mientras que en los sistemas OLAP, los datos pueden desnormalizarse para eliminar uniones y hacer que las operaciones de lectura tengan más rendimiento.
Defina restricciones de tabla para garantizar la integridad de los datos, no solo claves, sino también comprobaciones lógicas. Por ejemplo, si su tabla almacena calificaciones de estudiantes en el rango de 5 a 10, ¿por qué no definir esa restricción en la columna, evitando la inserción de valores sin sentido?
Cree índices y/o particiones: estas son estructuras de datos físicas especiales que aumentan la eficiencia del modelo de datos. La partición de tablas, por ejemplo, divide una tabla grande en varias subtablas más pequeñas, lo que reduce el tiempo de escaneo durante la ejecución de la consulta. Un enfoque clásico es la partición por año calendario. Y, por último, amplíe con objetos programáticos (procedimientos almacenados, funciones, activadores) que son estándar de facto en casi todas las soluciones de plataforma de datos.
El principal beneficio del modelo de datos físicos es garantizar la eficiencia, el rendimiento óptimo y la escalabilidad. Cuando hablamos de eficiencia, tenemos en mente los dos activos empresariales más preciados: el tiempo y el dinero. A menos que piense que tiempo = dinero, entonces sólo tiene un activo a considerar. Cuanto más eficiente sea su modelo de datos, más usuarios podrá atender, más rápido podrá atenderlos y eso, al final, generará más dinero para el negocio.
¿Por qué molestarse con los tres? Porque arreglar una brecha en el modelo conceptual cuesta una conversación. Arreglarlo en el modelo físico cuesta un sprint. Cuanto antes detectes los problemas, más barato será resolverlos.
OLTP frente a OLAP: escritura frente a lectura
Sistemas de procesamiento de transacciones en línea (OLTP)
Para ser un ingeniero analítico exitoso, primero debe comprender de dónde provienen sus datos. La gran mayoría de los datos empresariales no se crean para análisis. Se crea mediante aplicaciones que ejecutan las operaciones diarias de la empresa: un sistema de punto de venta, una herramienta de gestión de relaciones con el cliente (CRM), la base de datos backend de un sitio web de comercio electrónico y muchas más.
Estos sistemas fuente se denominan sistemas de procesamiento de transacciones en línea (OLTP). Están diseñados y optimizados para un objetivo principal: procesar un gran volumen de transacciones de forma rápida y confiable. Los sistemas OLTP necesitan confirmar instantáneamente el pedido de un cliente o actualizar su dirección de envío. La velocidad y la integridad de los datos para escribir datos son primordiales.
Para lograr esto, los sistemas OLTP utilizan un modelo de datos relacional altamente normalizado. Profundicemos en lo que eso realmente significa.
Normalización: el catálogo de fichas de la biblioteca
La normalización es el proceso de organizar datos en una base de datos para minimizar la redundancia de datos y mejorar la integridad de los datos. En términos simples, significa que no repites información si no es necesario.
Imagine una biblioteca en la era anterior a la informática. Todos y cada uno de los libros tienen una ficha. Si el nombre completo, la nacionalidad y la fecha de nacimiento del autor tuvieran que escribirse en cada tarjeta de cada libro que un autor escribió, sería tedioso. Estarías escribiendo “William Shakespeare, inglés, 1564-1616” en las tarjetas de Hamlet, Macbeth y Romeo y Julieta. Y si descubrieras un error en el año de nacimiento de Shakespeare, tendrías que encontrar y corregir cada tarjeta de cada libro que escribió. Es casi seguro que te perderás uno.
Un bibliotecario inteligente utilizaría la normalización. Crearían un catálogo de tarjetas de Autores separado. La tarjeta de Hamlet simplemente diría "ID de autor: 302". Luego, iría al catálogo de Autores, buscaría el ID 302 y encontraría todos los detalles de William Shakespeare en un solo lugar. Si necesitas hacer una corrección, sólo tienes que hacerlo una vez.
Formas normales
Ésta es la esencia de la normalización: dividir los datos en muchas tablas pequeñas y discretas para evitar repetirnos. Las reglas para hacer esto se llaman formas normales (1NF, 2NF, 3NF…). Hay siete formas normales en total, aunque en la mayoría de los escenarios de la vida real, normalizar los datos a la tercera forma normal (3NF) se considera óptimo.
Analicemos brevemente los principios clave detrás de las tres primeras formas normales. La primera forma normal (1NF) elimina los grupos repetidos. Cada celda debe contener un valor único y cada registro debe ser único. La segunda forma normal (2NF) se basa en 1NF y garantiza que todos los atributos dependan de la clave primaria completa; esto es principalmente relevante para tablas con claves compuestas. La tercera forma normal (3NF) se basa en 2NF y garantiza que ningún atributo dependa de otro atributo que no sea clave. Este es el ejemplo de la biblioteca: AuthorNationality no depende del libro; depende del autor. Entonces, mueve AuthorNationality a la tabla de Autores.
Veamos un ejemplo de antes y después. Imagine una hoja de cálculo no normalizada para rastrear pedidos: ID de pedido, Fecha de pedido, ID de cliente, Nombre de cliente, Ciudad de cliente, ID de producto, Nombre de producto, Cantidad, Precio unitario, todo en una tabla plana. ¿Notas toda la repetición? Se repiten el nombre y la ciudad de John Smith. El nombre y el precio del widget A se repiten. Para actualizar el precio del widget A, debe cambiarlo en dos lugares, y eso es sólo una pequeña muestra.
Para normalizar estos datos a 3NF, los dividimos en cuatro tablas separadas: una tabla de Cliente (ID de cliente, Nombre de cliente, Ciudad de cliente), una tabla de Producto (ID de producto, Nombre de producto, Precio unitario), una tabla de Pedidos (ID de pedido, Fecha de pedido, ID de cliente) y una tabla Detalles de pedido (ID de pedido, ID de producto, Cantidad). Ahora, si John Smith se muda a Los Ángeles, actualizamos su ciudad exactamente en un lugar. Si el precio del Widget A cambia, lo actualizamos exactamente en un lugar. Esto es perfecto para el sistema OLTP.
Sin embargo, la vida no es un cuento de hadas. Y aquí está el giro. Si bien esta estructura normalizada es excelente para escribir datos, es ineficiente para analizarlos. Para responder una pregunta simple como "¿Cuál es el monto total de ventas de productos en la categoría 'Widgets' a clientes en Nueva York?" Tendrías que realizar múltiples operaciones JOIN complejas en todas estas pequeñas tablas. Con docenas o incluso cientos de tablas, estas consultas se vuelven increíblemente lentas y una pesadilla para los usuarios empresariales.
Esto nos lleva al trabajo principal de un ingeniero analítico: transformar datos de un modelo optimizado para escritura (OLTP) a uno optimizado para lectura (OLAP).
Sistemas de procesamiento analítico en línea (OLAP)
Si los sistemas OLTP sirven para gestionar el negocio, los sistemas de procesamiento analítico en línea (OLAP) sirven para comprender el negocio. Nuestro principal objetivo como ingenieros analíticos es construir sistemas OLAP. Estos sistemas están diseñados para responder preguntas comerciales complejas sobre grandes volúmenes de datos lo más rápido posible.
Desnormalización: la reversión estratégica
Comencemos explicando la desnormalización. Como se puede suponer correctamente, con la desnormalización estamos invirtiendo estratégicamente el proceso de normalización que examinamos anteriormente. Recombinamos intencionalmente muchas tablas pequeñas en algunas tablas más grandes y anchas, incluso si eso significa repetir algunos datos y crear redundancia.
La desnormalización es esencialmente una compensación: estamos sacrificando un poco de espacio de almacenamiento y actualizando la eficiencia de la operación para obtener ganancias potencialmente masivas en el rendimiento de las consultas y la facilidad de uso. La desnormalización es uno de los conceptos centrales para implementar técnicas de modelado de datos dimensionales, que se tratan a continuación.
Modelado dimensional: el esquema estrella y más allá
Un modelo dimensional representa el paradigma estándar de oro al diseñar sistemas OLAP. Antes de explicar el aspecto dimensional, tengamos una breve lección de historia. El libro de Ralph Kimball The Data Warehouse Toolkit (Wiley, 1996) todavía se considera una biblia del modelado dimensional. En él, Kimball introdujo un enfoque completamente nuevo para modelar datos para cargas de trabajo analíticas: el llamado enfoque ascendente. La atención se centra en identificar procesos de negocio clave dentro de la organización y modelarlos primero, antes de introducir procesos de negocio adicionales.
El enfoque de Kimball es elegante por su simplicidad. Consta de cuatro pasos, cada uno de ellos basado en una decisión:
Paso 1: seleccione el proceso de negocio. Usemos un ejemplo: imaginemos que vender una entrada para un evento es el proceso de negocio que nos interesa. Los datos capturados durante este proceso pueden incluir Evento, Lugar, Cliente, Cantidad, Monto, Empleado, Tipo de entrada, País y Fecha.
Paso 2: Declarar el grano. Grano significa el nivel más bajo de detalle capturado por el proceso de negocio. En nuestro ejemplo, el nivel más bajo de detalle es la venta de entradas individuales. Elegir el grano correcto es de suma importancia en el modelado dimensional: define lo que representa cada fila en su tabla de hechos.
Paso 3: Identificar las dimensiones. Una dimensión es un tipo especial de tabla que nos gusta considerar como una tabla de búsqueda. Es donde buscas información más descriptiva sobre un determinado objeto. Piensa en una persona: ¿cómo la describirías? Por nombre, sexo, edad, atributos físicos, dirección de correo electrónico, número de teléfono. Un producto es similar: nombre, categoría, color, tamaño. Las tablas de dimensiones suelen responder a las preguntas que empiezan por W: ¿Cuándo vendimos el billete? ¿Dónde vendimos el billete? ¿Qué tipo de billete vendimos? ¿Quién era el cliente?
Paso 4: Identificar los hechos. Si pensamos en una dimensión como una tabla de búsqueda, una tabla de hechos almacena datos sobre eventos, algo que sucedió como resultado del proceso de negocio. En la mayoría de los casos, estos eventos se representan con valores numéricos: ¿Cuántas entradas vendimos? ¿Cuántos ingresos obtuvimos?
Piense en las dimensiones como tablas de búsqueda: describen el contexto. ¿Cuándo vendimos el boleto? ¿Dónde? ¿Qué tipo? ¿Quién era el cliente? Y piense en los hechos como en los eventos: cuántas entradas, cuántos ingresos.
Beneficios del modelado dimensional
Antes de pasar a las implementaciones físicas, reiteremos los beneficios clave. En primer lugar, la navegación de datos fácil de usar: como usuarios, nos resulta más fácil pensar en los procesos de negocio en términos de los sujetos que forman parte de ellos. ¿Qué evento vendió más entradas el último trimestre? ¿Cuántas entradas compraron las clientas para la final de la Liga de Campeones? ¿Qué empleado de EE. UU. vendió más entradas VIP para el Super Bowl?
En segundo lugar, el rendimiento: los sistemas OLAP están diseñados para lecturas de datos rápidas y eficientes, lo que significa menos uniones entre tablas. Eso es exactamente lo que proporciona el modelado dimensional a través del diseño de esquemas en estrella. En tercer lugar, flexibilidad: ¿su cliente cambió su dirección? ¿Su empleado cambió de puesto? Estos cambios se pueden manejar utilizando dimensiones que cambian lentamente; hablaremos de eso en breve.
El modelado dimensional, aunque solo es un subconjunto del modelado de datos, es uno de los conceptos más importantes en la implementación de soluciones de ingeniería analítica eficientes y escalables en la vida real.
La mayor ventaja de los modelos dimensionales es su flexibilidad y adaptabilidad. Puede agregar nuevos hechos a una tabla de hechos existente creando una nueva columna (suponiendo que los nuevos hechos coincidan con el grano existente). Puede agregar nuevos atributos de búsqueda agregando una clave externa a una nueva dimensión. Puede ampliar las dimensiones existentes con nuevos atributos simplemente agregando columnas. Ninguno de estos cambios viola ninguna consulta o aplicación de inteligencia empresarial existente.
Esquema de estrella y copo de nieve
Si se encuentra rodeado de modeladores de datos experimentados, probablemente los oirá hablar de estrellas y copos de nieve. Estos son probablemente los conceptos más influyentes en el mundo del modelado dimensional.
Esquema estelar: sigue siendo el rey
Según Ralph Kimball, cada dato debe clasificarse como qué, cuándo, dónde, quién, por qué, o cuánto o cuántos. En un modelo dimensional bien diseñado, debe tener una tabla central que contenga todas las medidas y eventos (la tabla de hechos) rodeada de tablas de dimensiones o de búsqueda. Las tablas de hechos y dimensiones están conectadas mediante relaciones establecidas entre la clave primaria de la tabla de dimensiones y la clave externa de la tabla de hechos. Este arreglo parece una estrella, de ahí el nombre.
Aunque hay muchos debates en curso que cuestionan la relevancia del esquema en estrella para las soluciones de plataformas de datos modernas debido a su antigüedad, es justo decir que este concepto sigue siendo absolutamente relevante y definitivamente el más ampliamente adoptado cuando se trata de diseñar sistemas de inteligencia empresarial eficientes y escalables.
Esquema de copo de nieve
El esquema de copo de nieve es muy similar al esquema de estrella. Conceptualmente, no hay diferencia entre los dos: en ambos casos, colocará quién, qué, cuándo, dónde y por qué en tablas de dimensiones, mientras mantendrá cuánto y cuántos en la tabla de hechos. La única diferencia es que en el esquema del copo de nieve, las dimensiones están normalizadas y divididas en subdimensiones, razón por la cual se parece a un copo de nieve.
La principal motivación para normalizar las dimensiones es eliminar la redundancia de datos de las tablas de dimensiones. Aunque esto puede parecer un enfoque deseable, la normalización de dimensiones conlleva algunas consideraciones serias: la estructura general del modelo de datos se vuelve más compleja y el rendimiento puede verse afectado debido a las uniones entre las tablas de dimensiones normalizadas.
Por supuesto, existen casos de uso específicos en los que la normalización de dimensiones puede ser una opción más viable, especialmente cuando se trata de reducir el tamaño del modelo de datos. Sin embargo, tenga en cuenta que el esquema de copo de nieve debería ser una excepción y no una regla al modelar sus datos para cargas de trabajo de ingeniería analítica.
Dimensiones que cambian lentamente: gestionar lo inevitable
¿Conoce el viejo dicho "La única constante en la vida es el cambio"? Bueno, eso es tan cierto para tus datos como para toda la vida. En el mundo real, las cosas no se quedan quietas. Su cliente se muda a un nuevo estado. Su producto clave recibe un nuevo nombre y categoría. Su empleado estrella recibe un ascenso y una nueva asignación regional.
Si simplemente actualizamos ciegamente estos registros en nuestro almacén de datos (por ejemplo, sobrescribiendo la antigua dirección del cliente con la nueva), podemos encontrarnos con un gran problema: perdemos el historial. Ya no podemos responder preguntas históricas súper importantes como "¿Cuántos ingresos generamos con este cliente mientras vivía en Nueva York?" o "¿Cómo funcionó este producto antes de cambiarle el nombre?"
Aquí es donde entra en juego el concepto de dimensiones que cambian lentamente (SCD). Un SCD es simplemente una estrategia formal para gestionar los cambios en sus tablas de dimensiones (las tablas que describen quién, qué, dónde y cómo) para que pueda realizar un seguimiento preciso del historial y garantizar que sus informes históricos se mantengan fieles.
Aunque hay siete tipos de dimensiones que cambian lentamente, nos centraremos en dos que se utilizan con mayor frecuencia en escenarios de modelado de datos: SCD Tipo 1 y SCD Tipo 2.
SCD Tipo 1: La sobrescritura olvidadiza
Piense en SCD Tipo 1 como una sobrescritura olvidadiza. Este es el más fácil de implementar y también el más implacable con la historia. Cuando un atributo de dimensión cambia (como una dirección de correo electrónico), simplemente sobrescribe el valor anterior con el nuevo. Hecho. El cambio es instantáneo e irreversible.
Piense en ello como corregir un error tipográfico en una entrada de Wikipedia. Editas la página, presionas Guardar y la antigua versión incorrecta desaparece para siempre. Nadie recuerda el antiguo error tipográfico a menos que revisen el historial de revisiones, ¡que es lo que no quieres que tus analistas tengan que hacer!
Si a su empresa no le importa el historial de un atributo (como el número de teléfono principal de un cliente), el Tipo 1 es una solución sencilla y limpia.
SCD tipo 2: el estándar de oro: viajes en el tiempo
El tipo 2 es el estándar de oro para la ingeniería analítica y es el enfoque más común para cualquier cosa que su empresa necesite para dividir datos históricos. Cuando un atributo cambia (como la ciudad de un cliente), nunca actualiza el registro anterior. En su lugar, crea un registro completamente nuevo para contener la nueva versión de la dimensión. Así consigues "viajar en el tiempo" en tus informes.
Cada vez que cambia un atributo clave, nace una nueva fila. Esto mantiene intactas todas las versiones anteriores del registro, cada una válida por un período de tiempo específico. Pero, ¿cómo puede un solo cliente terminar teniendo tres filas diferentes en la tabla de dimensiones sin causar un desorden en sus sistemas de informes? Nos basamos en tres campos de limpieza especiales para gestionar el cronograma:
La clave sustituta (una identificación generada por computadora) es el campo más importante. Es posible que su cliente original tenga un ID de CUST123, pero su primera versión de dirección obtiene una clave única como DIM_CUST_ID_1. Cuando se mueven, la nueva versión obtiene DIM_CUST_ID_2. Esta clave sustituta es a la que se unirán sus tablas de hechos, lo que garantiza que se una a la versión exacta del cliente que existía cuando se produjo la transacción.
Las ventanas de tiempo (Fecha de inicio y Fecha de finalización) definen el período durante el cual ese registro específico fue válido. Y el indicador actual es un indicador simple S/N: solo un registro para un cliente determinado tendrá este indicador establecido en VERDADERO, lo que proporciona un gran atajo para los analistas que solo desean la versión actual.
Permítanme repasar un ejemplo concreto. Imagine a la empleada Sarah Jones, ID de empleada 123. Comenzó como gerente de ventas en la región Oeste. Cuando fue ascendida a Directora Regional en octubre de 2023, no sobrescribimos su antiguo historial. En su lugar, creamos una nueva fila (clave sustituta 2) con su nuevo título, actualizamos la fecha de finalización en la fila anterior y configuramos el indicador actual en FALSO. Luego, cuando se mudó de la región Oeste a la Región Norte en mayo de 2024, repetimos el proceso: otra fila nueva (clave sustituta 3), otra actualización de la fecha de finalización, otro cambio de bandera. Ahora tenemos tres filas que capturan la historia profesional completa de Sarah y podemos analizar su desempeño en cualquier función, en cualquier región y en cualquier momento.
SCD Tipo 2 es el estándar de facto para la ingeniería analítica moderna porque otorga a los analistas el poder de una precisión histórica perfecta. Permite viajar en el tiempo en sus informes. Si bien es un poco más complejo de construir y mantener que la simple sobrescritura del Tipo 1, el valor que proporciona en inteligencia empresarial confiable, auditable y precisa no es negociable. Si necesita saber cómo eran las cosas ayer, el mes pasado o hace cinco años, la ECF tipo 2 es la salsa secreta que lo hace posible.
Diferentes tipos de tablas de hechos
Ya has aprendido que las tablas de hechos almacenan información medible y responden preguntas como ¿Cuánto? o ¿Cuantos? Sin embargo, no todas las medidas son iguales. No usarías el mismo cuaderno para escribir una lista de compras que para realizar un seguimiento de un proyecto de construcción de un año de duración. Es por eso que tenemos cuatro tipos principales de tablas de hechos, cada una diseñada para un tipo específico de medición empresarial.
Tabla de hechos transaccionales
Este es el tipo de tabla de hechos más simple, más común y quizás más fácil de entender. Una tabla de hechos transaccionales registra un evento único e instantáneo. Cada fila es como una fotografía con flash de algo que sucedió en ese momento.
Las características clave son que cada fila es un momento único y atómico (un clic, una línea de pedido, un intento de inicio de sesión, una transferencia de fondos) y que las medidas son totalmente aditivas, lo que significa que puede resumirlas de forma segura en cualquiera de sus dimensiones.
El ejemplo perfecto es el detalle de la partida individual de un recibo de caja registradora. Cuando compra alimentos, cada artículo escaneado es una línea (una fila) en la tabla de hechos. Esa única línea conecta la ID del producto específico, la ID del cliente, la ID de la tienda, la fecha y hora de la transacción y el monto de las ventas. Las tablas de hechos transaccionales son el pan de cada día de su almacén de datos.
Tabla de hechos de instantáneas periódicas
En algunos escenarios, no te importan todos los eventos; te preocupas por el estado de las cosas en un momento regular. Ése es un trabajo para la tabla de hechos de instantáneas periódicas. En lugar de registrar eventos, esta tabla captura las métricas de su negocio en un cronograma fijo y recurrente, por ejemplo, el último día del mes o el final de cada semana.
Las características clave son que una fila se crea solo en el momento predeterminado, capturando el estado de muchas cosas a la vez, y que las medidas son semiaditivas. Aquí es donde la cosa se vuelve complicada: generalmente puedes sumar las medidas en la mayoría de las dimensiones (como sumar el inventario total en todas las tiendas), pero no puedes sumarlas en el tiempo. Si tiene niveles de inventario para el lunes (100 unidades) y el martes (100 unidades), el inventario total para los dos días no es 200, sigue siendo 100.
Piense en su extracto bancario mensual. No registra cada taza de café que compraste durante el mes (esos son los datos transaccionales). Simplemente le indica el saldo de la cuenta el primer día del mes y el último día del mes. Las medidas que a menudo se capturan en tablas instantáneas periódicas incluyen el inventario disponible, el recuento de personal actual, el recuento de pedidos abiertos o el saldo de cuenta mensual.
Tabla de hechos de instantáneas acumuladas
Si necesita realizar un seguimiento del progreso de un proceso definido de varios pasos de principio a fin, necesita la tabla de hechos instantáneos acumulados. Esta tabla es única porque los registros no son estáticos. Se crea una fila cuando comienza el proceso y esa misma fila se actualiza a medida que el proceso avanza a través de hitos clave.
Cada fila representa una instancia de proceso completa: un solo pedido de un cliente o un reclamo de seguro. A diferencia de los otros tipos, estas filas se modifican deliberadamente con el tiempo para capturar fechas clave. Los principales conocimientos provienen del cálculo de las medidas de duración: el tiempo transcurrido entre los hitos.
El mejor ejemplo podría ser un servicio de mensajería como UPS o FedEx con un sistema de seguimiento de paquetes. Cuando realiza un pedido, se crea una fila. Luego, esa fila se actualiza con Fecha de pedido, Fecha de envío, Fecha de entrega y Fecha de entrega. Está todo en el mismo número de seguimiento. Esto le permite hacer preguntas como: "¿Cuál es el tiempo promedio entre la fecha del pedido realizado y la fecha de envío para todos los pedidos abiertos?"
Tabla de hechos sin hechos
Espera, ¿una tabla de hechos sin hechos? Sí, exactamente. La tabla de hechos sin hechos no tiene medidas numéricas. Todo su trabajo es capturar una relación entre dimensiones. Su única medida es un simple recuento de las filas: te dice qué pasó o qué se suponía que iba a pasar.
Piense en una tabla que muestra a todos los estudiantes que asistieron a todas las clases requeridas en un día determinado. Si un estudiante falta en la tabla para una clase requerida, puede inferir una ausencia. Lo usas para contar eventos (o eventos faltantes) donde lo importante es la existencia de la relación.
Elegir el tipo de tabla de hechos correcto
A continuación se ofrecen algunos consejos rápidos sobre cuándo utilizar qué tipo de tabla de hechos. Utilice una tabla de hechos transaccionales cuando necesite registrar cada pequeño detalle de un evento inmediato (por ejemplo, cada venta). Utilice una tabla de hechos instantánea periódica cuando necesite verificar el estado de muchas cosas en un calendario recurrente, por ejemplo, recuentos de inventario o estado de cuentas bancarias. Utilice una tabla de datos instantánea acumulativa cuando necesite realizar un seguimiento del ciclo de vida de un proceso complejo de principio a fin (por ejemplo, el cumplimiento de un pedido). Y utilice una tabla de hechos sin hechos cuando necesite capturar que algo sucedió (o no sucedió), y la mera existencia de la relación es la medida.
La conclusión clave
Cubrimos mucho en este artículo. Primero analizamos cómo debería comenzar el flujo de trabajo de modelado de datos dibujando el plano utilizando un modelo conceptual. Este es el puente entre los usuarios técnicos y comerciales, sirve como plantilla para etapas posteriores del proceso y explica términos técnicos básicos en un lenguaje que los usuarios comerciales puedan entender. Un modelo de datos lógico proporciona la mejor prueba de control de calidad, lo que le permite identificar rápidamente posibles lagunas en la comprensión de todo el flujo de trabajo empresarial. Finalmente, un modelo físico garantiza eficiencia, rendimiento óptimo y escalabilidad.
Luego trazamos la línea entre los sistemas OLTP y OLAP. En los sistemas OLTP, el énfasis está en la velocidad de escritura de datos, mientras que en los sistemas OLAP nos preocupa principalmente la velocidad de lectura de datos. En los escenarios de modelado de datos OLAP, el modelado dimensional se considera un estándar de facto, siendo el esquema en estrella el método de implementación dominante en muchas soluciones analíticas.
Exploramos dimensiones que cambian lentamente, desde la simple sobrescritura de Tipo 1 hasta la de Tipo 2 que preserva el historial y que le brinda poderes de “viaje en el tiempo” en sus informes. Y nos sumergimos en los cuatro tipos de tablas de hechos, cada una diseñada para un tipo específico de medición empresarial, desde la tabla de hechos transaccional básica hasta la enigmática tabla de hechos sin hechos.
Nos propusimos una tarea ambiciosa para este artículo: desmitificar y explicar conceptos y técnicas que por sí solos podrían llenar libros enteros. Por lo tanto, considere esto como una introducción o una introducción suave a los principios básicos del modelado de datos que necesita en su trabajo diario como ingeniero analítico. Definitivamente, este no es el final de la historia del modelado de datos; al contrario, apenas hemos arañado la superficie. Por lo tanto, le recomiendo encarecidamente que continúe su viaje de aprendizaje en modelado de datos, ya que esta es una habilidad indiscutible para todo ingeniero analítico.
¡Gracias por leer!