stringtranslate.com

Dimensión (almacén de datos)

Una tabla de dimensiones en un cubo OLAP con un esquema en estrella

Una dimensión es una estructura que categoriza hechos y medidas para permitir a los usuarios responder preguntas comerciales. Las dimensiones más utilizadas son personas, productos, lugar y tiempo. [1] [2] (Nota: las personas y el tiempo a veces no se modelan como dimensiones).

En un almacén de datos , las dimensiones proporcionan información de etiquetado estructurada para medidas numéricas que de otro modo estarían desordenadas. La dimensión es un conjunto de datos compuesto por elementos de datos individuales que no se superponen . Las funciones principales de las dimensiones son tres: proporcionar filtrado, agrupación y etiquetado.

Estas funciones a menudo se describen como "rebanar y cortar en dados". Un ejemplo común de almacén de datos implica las ventas como medida, con el cliente y el producto como dimensiones. En cada venta un cliente compra un producto. Los datos se pueden dividir eliminando todos los clientes excepto un grupo en estudio, y luego dividirlos agrupándolos por producto.

Un elemento de datos dimensional es similar a una variable categórica en estadística.

Normalmente, las dimensiones de un almacén de datos se organizan internamente en una o más jerarquías. "Fecha" es una dimensión común, con varias jerarquías posibles:

Tipos

Dimensiones que cambian lentamente

Una dimensión que cambia lentamente es un conjunto de atributos de datos que cambian lentamente durante un período de tiempo en lugar de cambiar regularmente, por ejemplo, dirección o nombre. Estos atributos pueden cambiar durante un período de tiempo y se combinarán como una dimensión que cambia lentamente. Estas dimensiones se pueden clasificar en tipos: [3]

Dimensión conformada

Una dimensión conformada es un conjunto de atributos de datos a los que se ha hecho referencia física en varias tablas de bases de datos utilizando el mismo valor clave para hacer referencia a la misma estructura, atributos, valores de dominio, definiciones y conceptos. Una dimensión conformada atraviesa muchos hechos.

Las dimensiones se conforman cuando son exactamente iguales (incluidas las claves) o una es un subconjunto adecuado de la otra. Lo más importante es que los encabezados de fila producidos en dos conjuntos de respuestas diferentes de las mismas dimensiones conformadas deben poder coincidir perfectamente.'

Las dimensiones conformadas son subconjuntos matemáticos idénticos o estrictos de la dimensión más granular y detallada. Las tablas de dimensiones no se ajustan si los atributos están etiquetados de manera diferente o contienen valores diferentes. Las dimensiones conformadas vienen en varios sabores diferentes. En el nivel más básico, las dimensiones conformadas significan exactamente lo mismo con todas las tablas de hechos posibles a las que se unen. La tabla de dimensiones de fecha conectada a los datos de ventas es idéntica a la dimensión de fecha conectada a los datos de inventario. [5]

dimensión basura

Una dimensión basura es una agrupación conveniente de indicadores y banderas típicamente de baja cardinalidad. Al crear una dimensión abstracta, estas banderas e indicadores se eliminan de la tabla de hechos y se colocan en un marco dimensional útil. [6] Una dimensión basura es una tabla de dimensiones que consta de atributos que no pertenecen a la tabla de hechos ni a ninguna de las tablas de dimensiones existentes. La naturaleza de estos atributos suele ser texto o varias banderas, por ejemplo, comentarios no genéricos o simplemente indicadores de sí/no o verdadero/falso. Este tipo de atributos generalmente permanecen cuando se han identificado todas las dimensiones obvias del proceso de negocio y, por lo tanto, el diseñador se enfrenta al desafío de dónde colocar estos atributos que no pertenecen a las otras dimensiones.

Una solución es crear una nueva dimensión para cada uno de los atributos restantes, pero debido a su naturaleza, podría ser necesario crear una gran cantidad de nuevas dimensiones, lo que daría como resultado una tabla de hechos con una gran cantidad de claves externas. El diseñador también podría decidir dejar los atributos restantes en la tabla de hechos, pero esto podría hacer que la longitud de la fila de la tabla sea innecesariamente grande si, por ejemplo, el atributo es una cadena de texto larga.

La solución a este desafío es identificar todos los atributos y luego colocarlos en una o varias dimensiones basura. Una dimensión basura puede contener varios indicadores verdadero/falso o sí/no que no tienen correlación entre sí, por lo que sería conveniente convertir los indicadores en un atributo más descriptivo. Un ejemplo sería un indicador sobre si un paquete ha llegado: en lugar de indicarlo como “sí” o “no”, se convertiría en “llegado” o “pendiente” en la dimensión basura. El diseñador puede optar por construir la tabla de dimensiones de modo que termine conteniendo todos los indicadores que ocurren entre sí para que todas las combinaciones estén cubiertas. Esto establece un tamaño fijo para la tabla en sí, que sería 2 x filas, donde x es el número de indicadores. Esta solución es apropiada en situaciones donde el diseñador esperaría encontrar muchas combinaciones diferentes y donde las combinaciones posibles están limitadas a un nivel aceptable. En una situación donde el número de indicadores es grande, creando así una tabla muy grande o donde el diseñador solo espera encontrar algunas de las combinaciones posibles, sería más apropiado construir cada fila en la dimensión basura a medida que se encuentren nuevas combinaciones. . Para limitar el tamaño de las tablas, varias dimensiones basura pueden ser apropiadas en otras situaciones dependiendo de la correlación entre varios indicadores.

Las dimensiones basura también son apropiadas para colocar atributos como comentarios no genéricos de la tabla de hechos. Dichos atributos pueden consistir en datos de un campo de comentario opcional cuando un cliente realiza un pedido y, como resultado, probablemente estarán en blanco en muchos casos. Por lo tanto, la dimensión basura debe contener una sola fila que represente los espacios en blanco como clave sustituta que se utilizará en la tabla de hechos para cada fila devuelta con un campo de comentario en blanco. [7]

Dimensión degenerada

Una dimensión degenerada es una clave, como un número de transacción, un número de factura, un número de boleto o un número de conocimiento de embarque, que no tiene atributos y, por lo tanto, no se une a una tabla de dimensiones real. Las dimensiones degeneradas son muy comunes cuando el detalle de una tabla de hechos representa un único elemento de transacción o línea de pedido porque la dimensión degenerada representa el identificador único del padre. Las dimensiones degeneradas suelen desempeñar un papel integral en la clave principal de la tabla de hechos. [8]

Dimensión del juego de roles

Las dimensiones suelen reciclarse para múltiples aplicaciones dentro de la misma base de datos. Por ejemplo, se puede utilizar una dimensión "Fecha" para "Fecha de venta", así como "Fecha de entrega" o "Fecha de contratación". A esto se le suele denominar "dimensión del juego de roles". Esto se puede implementar usando una vista sobre la misma tabla de dimensiones.

Dimensión del estabilizador

Por lo general, las tablas de dimensiones no hacen referencia a otras dimensiones mediante claves externas. Cuando esto sucede, la dimensión a la que se hace referencia se denomina dimensión de estabilizador. Las dimensiones de los estabilizadores deben considerarse un antipatrón del almacén de datos: se considera una mejor práctica utilizar algunas tablas de hechos que relacionen las dos dimensiones. [9]

Dimensión reducida

Se dice que una dimensión conformada es una dimensión reducida cuando incluye un subconjunto de filas y/o columnas de la dimensión original. [10]

Dimensión de fecha del calendario

Se puede utilizar un tipo especial de dimensión para representar fechas con una granularidad de un día. Se haría referencia a las fechas en una tabla de hechos como claves externas para una dimensión de fecha. La clave principal de la dimensión de fecha podría ser una clave sustituta o un número con el formato AAAAMMDD.

La dimensión de fecha puede incluir otros atributos como la semana del año o banderas que representan días laborables, feriados, etc. También podría incluir filas especiales que representen: fechas desconocidas o fechas aún por definir. La dimensión de fecha debe inicializarse con todas las fechas requeridas, digamos las fechas de los próximos 10 años, o más si es necesario, o fechas pasadas si se manejan eventos del pasado.

En cambio, el tiempo suele representarse mejor como una marca de tiempo en la tabla de hechos . [11]

Uso de términos de representación ISO

Cuando se hace referencia a datos de un registro de metadatos como ISO/IEC 11179 , normalmente se utilizan como dimensiones términos de representación como "Indicador" (un valor booleano verdadero/falso), "Código" (un conjunto de valores enumerados que no se superponen). Por ejemplo, utilizando el Modelo Nacional de Intercambio de Información (NIEM), el nombre del elemento de datos sería "PersonGenderCode" y los valores enumerados podrían ser "masculino", "femenino" y "desconocido".

tabla de dimensiones

En el almacenamiento de datos , una tabla de dimensiones es uno del conjunto de tablas complementarias de una tabla de hechos .

La tabla de hechos contiene datos (o medidas) comerciales y claves externas que hacen referencia a claves candidatas (normalmente claves primarias ) en las tablas de dimensiones.

A diferencia de las tablas de hechos, las tablas de dimensiones contienen atributos (o campos) descriptivos que suelen ser campos textuales (o números discretos que se comportan como texto). Estos atributos están diseñados para cumplir dos propósitos críticos: restricción y/o filtrado de consultas y etiquetado del conjunto de resultados de consultas.

Los atributos de dimensión deben ser:

Las filas de la tabla de dimensiones se identifican de forma única mediante un único campo clave. Se recomienda que el campo clave sea un entero simple porque un valor clave no tiene sentido y se usa solo para unir campos entre las tablas de hechos y dimensiones. Las tablas de dimensiones suelen utilizar claves primarias que también son claves sustitutas. Las claves sustitutas a menudo se generan automáticamente (por ejemplo, una "columna de identidad" de Sybase o SQL Server, una serie de PostgreSQL o Informix, una SECUENCIA de Oracle o una columna definida con AUTO_INCREMENT en MySQL).

El uso de claves de dimensión sustitutas aporta varias ventajas, entre ellas:

Aunque el uso de claves sustitutas supone una carga para el sistema ETL , el procesamiento de la canalización se puede mejorar y las herramientas ETL tienen un procesamiento de claves sustitutas mejorado incorporado.

El objetivo de una tabla de dimensiones es crear dimensiones estandarizadas y conformadas que se puedan compartir en todo el entorno de almacenamiento de datos de la empresa y permitir unirse a múltiples tablas de hechos que representan varios procesos comerciales.

Las dimensiones conformadas son importantes para la naturaleza empresarial de los sistemas DW/BI porque promueven:

Con el tiempo, los atributos de una fila determinada en una tabla de dimensiones pueden cambiar. Por ejemplo, la dirección de envío de una empresa puede cambiar. Kimball se refiere a este fenómeno como una dimensión que cambia lentamente . Las estrategias para afrontar este tipo de cambio se dividen en tres categorías:

Patrones comunes

Fecha y hora

Fuente: [12]

Dado que muchas tablas de hechos en un almacén de datos son series temporales de observaciones, a menudo se necesitan una o más dimensiones de fecha. Una de las razones para tener dimensiones de fecha es colocar el conocimiento del calendario en el almacén de datos en lugar de codificarlo en una aplicación. Si bien una simple marca de fecha y hora SQL es útil para proporcionar información precisa sobre la hora en que se registró un hecho, no puede brindar información sobre días festivos, períodos fiscales, etc. Una marca de fecha y hora SQL aún puede ser útil para almacenar en la tabla de hechos. ya que permite realizar cálculos precisos.

Tener tanto la fecha como la hora del día en la misma dimensión puede resultar fácilmente en una dimensión enorme con millones de filas. Si se necesita una gran cantidad de detalles, suele ser una buena idea dividir la fecha y la hora en dos o más dimensiones separadas. Una dimensión de tiempo con unos pocos segundos en un día solo tendrá 86400 filas. Se puede elegir un grano más o menos detallado para las dimensiones de fecha/hora dependiendo de las necesidades. Como ejemplo, las dimensiones de fecha pueden tener una precisión de año, trimestre, mes o día y las dimensiones de tiempo pueden tener una precisión de horas, minutos o segundos.

Como regla general, la dimensión de hora del día solo debe crearse si se necesitan agrupaciones jerárquicas o si hay descripciones textuales significativas para períodos de tiempo dentro del día (por ejemplo, “punta de la tarde” o “primer turno”).

Si las filas de una tabla de hechos provienen de varias zonas horarias, puede resultar útil almacenar la fecha y la hora tanto en hora local como en hora estándar. Esto se puede hacer teniendo dos dimensiones para cada dimensión de fecha/hora necesaria: una para la hora local y otra para la hora estándar. Almacenar la fecha/hora tanto en hora local como estándar permitirá el análisis de cuándo se crean los hechos en un entorno local y también en un entorno global. La hora estándar elegida puede ser una hora estándar global (por ejemplo, UTC ), puede ser la hora local de la sede de la empresa (por ejemplo, CET ) o cualquier otra zona horaria que tenga sentido utilizar.

Ver también

Referencias

  1. ^ "Guía de almacenamiento de datos de Oracle", Oracle Corporation, consultado el 9 de junio de 2014
  2. ^ Definición: Dimensión "Gestión de datos de búsqueda", TechTarget, consultado el 9 de junio de 2014
  3. ^ Dice Kalyn (9 de octubre de 2014). "Tipos de tabla de dimensiones | Capacitación en almacenamiento de datos". Edureka . Consultado el 12 de enero de 2022 .
  4. ^ Ross, Margy (5 de febrero de 2013). "Consejo de diseño n.º 152 Tipos de cotas que cambian lentamente 0, 4, 5, 6 y 7". Grupo Kimball . Consultado el 12 de enero de 2022 .
  5. ^ Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: la guía completa para el modelado dimensional, segunda edición, Wiley Computer Publishing, 2002. ISBN 0471-20024-7 , páginas 82-87, 394 
  6. ^ Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: la guía completa para el modelado dimensional, segunda edición, Wiley Computer Publishing, 2002. ISBN 0471-20024-7 , páginas 202, 405 
  7. ^ Kimball, Ralph y col. (2008): Kit de herramientas del ciclo de vida del almacén de datos, segunda edición, Wiley Publishing Inc., Indianápolis, IN. Páginas 263-265
  8. ^ Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: la guía completa para el modelado dimensional, segunda edición, Wiley Computer Publishing, 2002. ISBN 0471-20024-7 , páginas 50, 398 
  9. ^ Ralph Kimball; Margy Ross (2013). El kit de herramientas del almacén de datos, tercera edición . Wiley. pag. 50.ISBN 978-1-118-53080-1.
  10. ^ Ralph Kimball; Margy Ross (2013). El kit de herramientas del almacén de datos, tercera edición . Wiley. pag. 51.ISBN 978-1-118-53080-1.
  11. ^ Ralph Kimball; Margy Ross (2013). El kit de herramientas del almacén de datos, tercera edición . Wiley. pag. 48.ISBN 978-1-118-53080-1.
  12. ^ Ralph Kimball, The Data Warehouse Toolkit, segunda edición, Wiley Publishing, Inc., 2008. ISBN 978-0-470-14977-5 , páginas 253-256