Cuando comenzamos un proyecto de almacenamiento de datos, lo primero que hacemos es definir las tablas dimensionales. Las tablas dimensionales son las partes interesantes, el marco alrededor del cual construimos nuestras medidas. Vienen en muchas formas y tamaños. En este artículo, vamos a echar un vistazo más de cerca a cada tipo de tabla dimensional.
Las tablas dimensionales brindan contexto a los procesos comerciales que deseamos medir. Nos dicen todo lo que necesitamos saber sobre un evento. Dado que dan sustancia a las mediciones (es decir, tablas de hechos) del sistema de almacenamiento de datos (DWH), dedicamos más tiempo a su definición e identificación que a cualquier otro aspecto del proyecto. Tablas de hechos define las medidas; las tablas dimensionales dan contexto. (Para leer más sobre tablas de hechos, consulte estas publicaciones sobre almacenamiento de datos, el esquema de estrella, el esquema de copo de nieve y datos sobre tablas de hechos).
La principal característica de las tablas de dimensiones es su multitud de atributos . Los atributos son las columnas que resumimos, filtramos o agregamos. Tienen baja cardinalidad y suelen ser textuales y temporales. Las tablas dimensionales tienen una clave principal basada en la clave comercial subyacente o una clave sustituta . Esta clave principal es la base para unir la tabla de dimensiones a una o más tablas de hechos.
En comparación con las tablas de hechos, las tablas de dimensiones son de tamaño pequeño, fáciles de almacenar y tienen poco impacto en el rendimiento.
Ahora echemos un vistazo a algunas de las tablas de dimensiones con las que se encontrará en un entorno de almacenamiento de datos.
Una tabla dimensional común:la dimensión conformada
Comenzaremos con un tipo básico:la dimensión conformada. Estos contienen múltiples atributos, que se pueden abordar en varias tablas de origen pero que se refieren al mismo dominio (cliente, contrato, trato, etc.) Las dimensiones conformadas se usan con muchos hechos y deben ser únicas para el valor de grano/dominio en el almacén de datos.
Ejemplo:
Veamos una tabla dimensional típica, DIM_CUSTOMER .
Definimos:
id– La clave principal de la tabla de dimensiones.cust_natural_key– La clave natural para el cliente.first_name– El nombre del cliente.last_name– El apellido del cliente.address_residence– La dirección residencial del cliente.date_of_birth– La fecha de nacimiento del cliente.marital_status– ¿El cliente está casado? Definido como Y (sí) o N (no).gender– El género del cliente, M (masculino) o F (femenino).
Los atributos de la tabla de dimensiones dependen de la necesidad empresarial. Podemos expandir este tipo de tabla para contener información específica de la industria (fecha de incumplimiento, actividad, etc.)
Tablas dimensionales que cambian lentamente
A medida que pasa el tiempo, las dimensiones pueden cambiar sus valores. En los siguientes párrafos, examinaremos las dimensiones clasificadas por cómo almacenan (o no almacenan) datos históricos.
Digamos que tienes una dimensión de cliente. Es probable que algunos atributos cambien durante la vida del cliente, p. número de teléfono, dirección, estado civil, etc. Este tipo de tabla es lo que Ralph Kimball llama una dimensión que cambia lentamente, o SCD.
El SCD viene en muchos tipos; ocho de ellos son bastante comunes. De estos, verá los tipos 0 a 4 en su mayoría; los tipos 5, 6 y 7 son híbridos de los primeros cinco. (Nota:el esquema de numeración de estos SCD comienza con un 0 en lugar de un 1).
Los SCD híbridos brindan más flexibilidad y mejor rendimiento, pero a costa de la simplicidad. Usamos estos tipos de tablas cuando necesitamos hacer análisis analíticos de actual datos con algo de histórico consideraciones.
SCD tipo 0:llenado una vez
Este es el tipo más básico de la tabla de dimensiones:se llena una vez y nunca llenarlo de nuevo. Considere esto como datos referenciales. Un ejemplo típico de esto es la dimensión de fecha. No necesitamos llenar esta dimensión con cada carga de DWH. La tabla dimensional no cambia con el tiempo. No se pueden obtener más fechas ni modificar fechas.
La tabla de hechos se conecta a los atributos originales de la dimensión.
Ejemplo
Veamos la dimensión del tiempo:
La estructura es bastante sencilla:
id– Clave sustitutatime_date– Fecha realtime_day– Día del mestime_week– Semana del añotime_month– Mes en un añotime_year– Representación numérica de un año
SCD tipo 1:reescritura de datos
Como sugiere el nombre, reescribimos este tipo de tabla dimensional con cada carga de DWH. No necesitamos mantener un historial de ellos, pero esperamos que haya algunos cambios.
La diferencia entre un SCD Tipo 0 y un Tipo 1 no está en la estructura de la tabla. Tiene que ver con la actualización de los datos. Nunca actualiza los datos en un Tipo 0, pero a veces lo hace en un Tipo 1.
Una tabla reescribible es la forma más sencilla de manejar los cambios (eliminar/insertar), pero agrega poco valor comercial. Una vez que define una tabla de dimensiones como esta, es difícil instalar el seguimiento histórico.
La tabla de hechos se conecta a los atributos actuales de la dimensión.
Ejemplo
Veamos la dimensión de la cuenta:
Su estructura es la siguiente:
id– La clave sustituta de la tablaaccount_name– El nombre de la cuentaaccount_type– La categoría de la cuentaaccount_activity– Marca diferentes tipos de actividad
Si miramos los datos antes del cambio, veríamos esto:
Si el tipo de cuenta ha cambiado, los datos simplemente se sobrescribirán:
SCD tipo 2:seguimiento de atributos históricos por fila
Esta es la forma más común de seguimiento histórico en un sistema DWH. Las tablas SCD Tipo 2 agregan nuevas filas para cada cambio histórico de atributos dimensionales entre Cargas DWH . En este tipo, definimos la clave principal como una clave sustituta porque la clave comercial tendrá múltiples representaciones a lo largo del tiempo. Cuando se modifican las filas que contienen el cambio de datos, definimos un nuevo valor para la clave sustituta que corresponde al valor en la tabla de hechos. Necesitamos agregar al menos dos columnas, valid_from y valid_to , para almacenar el historial de esta manera.
La tabla de hechos se conecta a los atributos históricos de la dimensión a través de la clave sustituta. La agregación se realiza sobre la clave natural .
Ejemplo
Veamos la tabla de dimensiones del cliente anterior, ahora ampliada con dos columnas de fecha:
Veamos los datos:
Puntos a considerar:
- ¿Cómo podemos marcar la fila actual,
valid_to? ? (Por lo general, con 31.12.9999 o NULL .) - ¿Cómo podemos marcar la primera fila,
valid_from? ? (Generalmente con 01.01.1900, o la fecha de la primera inserción). - ¿Define una fila inclusiva o exclusiva? (Arriba, usamos un
valid_frominclusivo y un exclusivovalid_to).
SCD tipo 3:seguimiento de atributos históricos por columna
Al igual que con el SCD Tipo 2, este tipo agrega algo para representar valores históricos. En este caso, sin embargo, estamos agregando nuevas columnas. Estos representan el valor de un atributo de fila dimensional antes de que cambie. Por lo general, solo conservamos la versión anterior del atributo.
Nota:este SCD rara vez se usa.
La tabla de hechos se conecta a los atributos actuales y anteriores de la dimensión.
Ejemplo
Veamos la dimensión del cliente, esta vez con una dirección residencial anterior:
En este ejemplo, agregamos una nueva columna, previous_address_residence , para representar la antigua dirección del cliente. Si observamos nuestro ejemplo inicial, los datos de esta tabla se verían así:
Se pierde toda la información histórica, excepto la dirección anterior del cliente.
SCD tipo 4:agregar una minidimensión
Este tipo de dimensión no se basa en cambios estructurales (Tipo 3) o de valor (Tipo 2). Más bien, se basa en cambios de diseño en el modelo. Si nuestra tabla dimensional contiene datos altamente volátiles, es decir, datos que cambian con frecuencia, el tamaño de la tabla dimensional crecería significativamente.
Para mitigar esto, extraemos los atributos volátiles en una mini-dimensión . Estas minidimensiones luego podrían agregarse al nivel relevante para el negocio. Sin embargo, esta agregación no confundirse con agregación de hechos . El ejemplo aclarará esto.
La tabla de hechos se conecta a los atributos históricos de la dimensión.
Ejemplo
Veamos un ejemplo de un simple data mart financiero. Suponga que necesita realizar un seguimiento del retraso de ciertos clientes en sus pagos. Llamemos a este atributo días vencidos o DPD. Si tuviéramos que rastrear DPD todos los días en una dimensión de Tipo 2, el tamaño de la tabla pronto explotaría más allá de los límites manejables. Así que extraemos el atributo y encontramos períodos de DPD relevantes para el negocio, digamos en incrementos de 30 días (0-30 DPD, 30-60 DPD, 60-90 DPD, etc.)
Podemos tomar otros atributos de alta volatilidad, como la edad, y construir períodos relevantes para el negocio también para ellos (por ejemplo, 20-30 años, 30-40 años, etc.)
Si observamos los datos en la minidimensión del cliente, tendríamos algo como esto:
Los atributos son:
id– Clave principal sustitutaDPD_period– Días de atraso en el períodoDEM_period– Período demográfico
El esquema de estrella simple se vería así:
Tenga en cuenta que para realizar cualquier análisis sobre los atributos de ambas tablas, tendríamos que unirlos a través de la tabla de hechos.
SCD tipo 5:creación de una minidimensión con una extensión regrabable
Esta es la primera de nuestras construcciones de tablas dimensionales híbridas. En un SCD Tipo 5, agregamos la versión actual de datos minidimensionales a la tabla dimensional. Debemos tener en cuenta que solo agregaremos el actual representación de la mini-dimensión a la dimensión principal.
Rellenamos esta extensión de minidimensión con cada carga (el SCD "regrabable" de Tipo 1).
Si bien la historización de esta extensión podría generar problemas de tamaño, ya los hemos mitigado con la tabla de minidimensiones.
Usamos esta técnica cuando queremos hacer análisis directamente en las tablas de dimensiones.
Ejemplo
Expandiendo el ejemplo anterior con la minidimensión actual, obtenemos:
El dim_mini_customer_current la tabla contiene los valores de atributo más recientes que corresponden al dim_customer mesa. Ahora podemos realizar análisis específicos del cliente sin pasar por la tabla de hechos (que es muy lenta).
La tabla de hechos se conecta a los atributos históricos de la dimensión.
Tipo 6:dimensión de tipo 2 (fila histórica) con un atributo reescribible
Esta es una construcción dimensional muy común. Agregamos un atributo que almacena una cosa, generalmente el último valor conocido, que reescribimos con cada carga. Esto nos permite agrupar todos los hechos por su valor actual, mientras que el atributo histórico muestra los datos tal como estaban cuando ocurrieron los eventos.
La tabla de hechos se conecta a los valores dimensionales en el momento del evento con valores dimensionales adicionales actuales.
Ejemplo
Expandamos la tabla de clientes anterior con un current_address_residence columna.
Ahora tenemos un atributo que actualizaremos al valor actual, usando la clave natural (cust_natural_key ).
Tipo 7:dimensiones de tipo 2 (fila histórica) con un espejo actual
Podemos usar este tipo solo si hay una clave natural en la dimensión de la tabla. La clave no debe cambiar durante la vida de la entidad.
La idea es simple:agregamos una representación actual de la tabla dimensional al esquema del copo de nieve. Luego insertamos la clave natural de la nueva dimensión en la tabla de hechos. (La clave sustituta de la dimensión histórica todavía está presente).
La tabla de hechos se conecta a los valores dimensionales en el momento del evento y a los valores dimensionales actuales.
Ejemplo
Veamos nuestro esquema de estrella de cuenta de cliente. Agregamos la nueva dimensión, dim_current_customer , a la tabla de hechos. Esta tabla está conectada a la tabla de hechos a través de una clave natural, cust_natural_key .
Esta construcción nos permite realizar consultas analíticas en el esquema en estrella con los valores actuales e históricos de los atributos del cliente.
Dimensiones del dominio
Una dimensión de dominio es una forma simple de tabla dimensional. Contiene información sobre el dominio de la medida subyacente de un atributo dimensional. Estas tablas almacenan varios códigos y valores explicativos.
Ejemplo
Un ejemplo simple sería una tabla de monedas.
En esta tabla, almacenamos información descriptiva sobre varias unidades monetarias.
En mi opinión personal, el mejor uso de la dimensión del dominio está en la documentación de los valores de datos que encontramos en el sistema DWH.
Dimensiones basura
Los sistemas fuente transaccionales generan muchos indicadores y banderas. Estos atributos pueden considerarse datos categóricos, pero no son relevantes para el negocio ni se explican por sí mismos. Podemos archivar todos estos indicadores y banderas en una tabla unidimensional llamada dimensión basura . La dimensión basura es la alternativa al uso de dimensiones degeneradas. Si no queremos sobrecargar la tabla de hechos con muchas dimensiones degeneradas, creamos una dimensión basura.
Debemos tener en cuenta que no llenamos todas las combinaciones posibles de indicadores y banderas. Solo rellenamos los que existen en el sistema de origen.
Ejemplo
Las tablas de dimensiones son el esqueleto del mundo del almacenamiento de datos:todo se construye alrededor de ellas. No son tan grandes como las tablas de hechos, pero su estructura puede ser más compleja.
Puede armar muchos tipos de tablas de dimensiones, incluso más allá de las que acabamos de discutir. ¿Qué pasa con su negocio e industria? Si ha combinado tipos de tablas dimensionales en algo nuevo, ¡cuéntenoslo!
