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 clasifica hechos y medidas para permitir a los usuarios responder preguntas comerciales. Las dimensiones que se utilizan habitualmente 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 a medidas numéricas que de otro modo no estarían ordenadas. 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, agrupamiento y etiquetado.

Estas funciones suelen describirse como "segmentar y dividir". 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 de cambio lento es un conjunto de atributos de datos que cambian lentamente durante un período de tiempo en lugar de cambiar regularmente, por ejemplo, la dirección o el nombre. Estos atributos pueden cambiar durante un período de tiempo y se combinarán como una dimensión de cambio lento. 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ísicamente 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 abarca muchos hechos.

Las dimensiones se consideran conformes 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 a partir de las mismas dimensiones conformes 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 están conformadas si los atributos están etiquetados de forma diferente o contienen valores diferentes. Las dimensiones conformadas se presentan en diferentes formas. En el nivel más básico, las dimensiones conformadas significan exactamente lo mismo con cada tabla de hechos posible a la que se unen. La tabla de dimensión de fecha conectada a los hechos de ventas es idéntica a la dimensión de fecha conectada a los hechos de inventario. [5]

Dimensión basura

Una dimensión basura es una agrupación conveniente de indicadores y banderas que normalmente tienen una cardinalidad baja. Al crear una dimensión abstracta, estos indicadores y banderas 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 simples de sí/no o verdadero/falso. Este tipo de atributos suelen permanecer cuando se han identificado todas las dimensiones obvias en el proceso empresarial 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 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 de 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 "llegó" 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 con todos los demás indicadores de modo que se cubran todas las combinaciones. 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 adecuada en situaciones en las que 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 en la que la cantidad de indicadores es grande y, por lo tanto, se crea una tabla muy grande o en la que 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 podrían 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 una clave sustituta que se utilizará en la tabla de hechos para cada fila que se devuelva 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 ticket 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 grano de una tabla de hechos representa un solo elemento de transacción o línea de artículo porque la dimensión degenerada representa el identificador único del elemento principal. Las dimensiones degeneradas a menudo desempeñan un papel integral en la clave principal de la tabla de hechos. [8]

Dimensión del juego de roles

Las dimensiones suelen reciclarse para varias aplicaciones dentro de la misma base de datos. Por ejemplo, una dimensión "Fecha" se puede utilizar para la "Fecha de venta", así como para la "Fecha de entrega" o la "Fecha de contratación". Esto suele denominarse "dimensión de juego de roles". Esto se puede implementar utilizando 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 referencia. Las dimensiones de referencia 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 las filas y/o columnas de la dimensión original. [10]

Dimensión de la fecha del calendario

Se puede utilizar un tipo especial de dimensión para representar fechas con una granularidad de un día. Las fechas se referenciarían en una tabla de hechos como claves externas a 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 indicadores que representen días laborables, feriados, etc. También puede incluir filas especiales que representen fechas desconocidas o fechas que aún no se han definido. La dimensión de fecha debe inicializarse con todas las fechas requeridas, por ejemplo, los próximos 10 años de fechas o más si es necesario, o fechas pasadas si se manejan eventos del pasado.

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

Uso de términos de representación ISO

Al hacer referencia a datos de un registro de metadatos como ISO/IEC 11179 , se suelen utilizar como dimensiones términos de representación como "Indicador" (un valor booleano verdadero/falso) o "Código" (un conjunto de valores enumerados que no se superponen). Por ejemplo, si se utiliza 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 una de las tablas complementarias de una tabla de hechos .

La tabla de hechos contiene hechos comerciales (o medidas) 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 descriptivos (o campos) 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 fundamentales: restringir o filtrar consultas y etiquetar el conjunto de resultados de las 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, ya que un valor clave no tiene sentido y se utiliza únicamente para unir campos entre las tablas de hechos y dimensiones. Las tablas de dimensiones suelen utilizar claves principales que también son claves sustitutas. Las claves sustitutas suelen generarse automáticamente (por ejemplo, una "columna de identidad" de Sybase o SQL Server, un número de serie de PostgreSQL o Informix, una SEQUENCE de Oracle o una columna definida con AUTO_INCREMENT en MySQL).

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

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

El objetivo de una tabla de dimensiones es crear dimensiones estandarizadas y conformadas que puedan compartirse en todo el entorno de almacén de datos de la empresa y permitir la unión a múltiples tablas de hechos que representan diversos 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 dimensión de cambio lento . Las estrategias para abordar este tipo de cambio se dividen en tres categorías:

Patrones comunes

Fecha y hora

Fuente: [12]

Dado que muchas tablas de hechos de 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 de 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 de SQL puede seguir siendo útil para almacenar en la tabla de hechos, ya que permite realizar cálculos precisos.

Si se tienen en la misma dimensión la fecha y la hora del día, se puede obtener fácilmente 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 independientes. Una dimensión de tiempo con un grano de segundos en un día solo tendrá 86 400 filas. Se puede elegir un grano más o menos detallado para las dimensiones de fecha/hora según las necesidades. Por 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 la 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, “hora pico 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 la hora local como en la hora estándar. Esto se puede hacer con dos dimensiones para cada dimensión de fecha y hora necesaria: una para la hora local y otra para la hora estándar. El almacenamiento de la fecha y la hora tanto en la hora local como en la hora estándar permitirá realizar un análisis sobre 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 (p. ej., UTC ), puede ser la hora local de la sede de la empresa (p. ej., CET ) o cualquier otra zona horaria que tenga sentido utilizar.

Véase también

Referencias

  1. ^ "Oracle Data Warehousing Guide", Oracle Corporation, consultado el 9 de junio de 2014
  2. ^ Definición: Gestión de datos de búsqueda de dimensión, TechTarget, consultado el 9 de junio de 2014
  3. ^ Dice Kalyn (9 de octubre de 2014). "Tipos de tablas de dimensiones | Formació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: Cambio lento de los tipos de dimensión 0, 4, 5, 6 y 7". Kimball Group . 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, et al. (2008): The Data Warehouse Lifecycle Toolkit, 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). The Data Wharehouse Toolkit 3.ª edición . Wiley. pág. 50. ISBN 978-1-118-53080-1.
  10. ^ Ralph Kimball; Margy Ross (2013). The Data Wharehouse Toolkit 3.ª edición . Wiley. pág. 51. ISBN 978-1-118-53080-1.
  11. ^ Ralph Kimball; Margy Ross (2013). The Data Wharehouse Toolkit 3.ª edición . Wiley. pág. 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