Dimensión (almacén de datos)


De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda
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 comúnmente 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 a 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 triples: proporcionar filtrado, agrupación y etiquetado.

Estas funciones se describen a menudo como "cortar y cortar". 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 divididos en cuadritos agrupando 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:

  • "Días (se agrupan en) Meses (que se agrupan en) Años",
  • "Días (se agrupan en) Semanas (que se agrupan en) Años"
  • "Días (se agrupan en) Meses (que se agrupan en) Trimestres (que se agrupan en) Años"
  • etc.

Tipos

Dimensión conformada

Una dimensión conformada es un conjunto de atributos de datos que se han referenciado físicamente en varias tablas de bases de datos utilizando el mismo valor clave para referirse 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. Más importante aún, 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 conforman 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 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. [3]

Dimensión basura

Una dimensión basura es una agrupación conveniente de banderas e indicadores de cardinalidad baja. 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. [4] 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 varios indicadores, por ejemplo, comentarios no genéricos o simplemente indicadores de sí / no o verdadero / falso. Este tipo de atributos normalmente permanecen 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 que resulten en 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 ponerlos 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 de 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 para que termine manteniendo todos los indicadores que ocurren con todos los demás indicadores para que se cubran todas las combinaciones. Esto establece un tamaño fijo para la tabla en sí, que sería 2 x filas, donde xes 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, múltiples 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 una clave sustituta que se utilizará en la tabla de hechos para cada fila devuelta con un campo de comentario en blanco. [5]

Dimensión degenerada

Una dimensión degenerada es una clave, como un número de transacción, número de factura, número de boleto o 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 artículo de transacción o artículo de línea porque la dimensión degenerada representa el identificador único del padre. Las dimensiones degeneradas a menudo juegan un papel integral en la clave principal de la tabla de hechos. [6]

Dimensión de juego de roles

Las dimensiones a menudo se reciclan para múltiples aplicaciones dentro de la misma base de datos. Por ejemplo, una dimensión "Fecha" se puede utilizar para "Fecha de venta", así como "Fecha de entrega" o "Fecha de contratación". Esto a menudo se denomina "dimensión de 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 referenciada se denomina dimensión estabilizadora . Las dimensiones de los estabilizadores deben considerarse un antipatrón de almacenamiento de datos: se considera una mejor práctica utilizar algunas tablas de hechos que relacionen las dos dimensiones.[7]

Dimensión encogida

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.[8]

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. Se haría referencia a las fechas 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 banderas que representan días laborables, festivos, 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 los próximos 10 años de fechas, o más si es necesario, o fechas pasadas si se manejan eventos en el pasado.

En cambio, el tiempo se suele representar mejor como una marca de tiempo en la tabla de hechos .[9]

Uso de términos de representación ISO

Cuando se hace referencia a datos de un registro de metadatos como ISO / IEC 11179 , términos de representación como "Indicador" (un valor booleano verdadero / falso), "Código" (un conjunto de valores enumerados que no se superponen) se utilizan normalmente como dimensiones. 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 a una tabla de hechos .

La tabla de hechos contiene hechos comerciales (o medidas ) y claves externas que se refieren 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 de texto (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 de conjuntos de resultados de consultas.

Los atributos de dimensión deben ser:

  • Verboso (etiquetas que constan de palabras completas)
  • Descriptivo
  • Completo (sin valores perdidos)
  • Valorado discretamente (con solo un valor por fila de la tabla de dimensiones)
  • Calidad asegurada (sin errores ortográficos ni valores imposibles)

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 número 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 trae varias ventajas, que incluyen:

  • Rendimiento. El procesamiento de combinaciones se hace mucho más eficiente al usar un solo campo (la clave sustituta )
  • Protección de las prácticas operativas de gestión de claves. Esto evita situaciones en las que las filas de datos eliminadas pueden reaparecer cuando sus claves naturales se reutilizan o reasignan después de un largo período de inactividad.
  • Mapeo para integrar fuentes dispares
  • Manejo de conexiones desconocidas o no aplicables
  • Seguimiento de cambios en los valores de los atributos de dimensión

Aunque el uso de la clave sustituta supone una carga para el sistema ETL , el procesamiento de la canalización se puede mejorar y las herramientas ETL incorporan un procesamiento mejorado de la clave sustituta.

El objetivo de una tabla de dimensiones es crear dimensiones estandarizadas y adaptadas que se puedan compartir en el entorno de almacenamiento de datos de la empresa y permitir la unión 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:

  • Consistencia. Cada tabla de hechos se filtra de forma coherente, por lo que las respuestas a las consultas se etiquetan de forma coherente.
  • Integración. Las consultas pueden profundizar en diferentes tablas de hechos de procesos por separado y luego unir los resultados en atributos de dimensión comunes.
  • Reducción del tiempo de desarrollo hasta el mercado. Las dimensiones comunes están disponibles sin volver a crearlas.

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 hacer frente a este tipo de cambio se dividen en tres categorías:

  • Escriba uno: simplemente sobrescriba los valores antiguos.
  • Tipo dos: agregue una nueva fila que contenga los nuevos valores y distinga entre las filas utilizando técnicas de control de versiones de Tuple .
  • Tipo tres: agregue un nuevo atributo a la fila existente.

Patrones comunes

Fecha y hora [10]

Dado que muchas tablas de hechos en un almacén de datos son series de tiempo 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 fecha / marca de tiempo SQL simple es útil para proporcionar información precisa sobre la hora en que se registró un hecho, no puede proporcionar información sobre días festivos, períodos fiscales, etc. Una fecha / marca de tiempo SQL puede ser útil para almacenar en la tabla de hechos. ya que permite cálculos precisos.

Tener la fecha y 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, generalmente es una buena idea dividir la fecha y la hora en dos o más dimensiones separadas. Una dimensión de tiempo con un grano de 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 en función de las necesidades. Por ejemplo, las dimensiones de la fecha pueden ser precisas en términos de año, trimestre, mes o día, y las dimensiones de hora pueden ser precisas en 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, "punta de la tarde" o "primer turno").

Si las filas de una tabla de hechos proceden 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 teniendo dos dimensiones para cada dimensión de fecha / hora necesaria: una para la hora local y otra para la hora estándar. El almacenamiento de la fecha / hora tanto en la hora local como en la hora estándar permitirá analizar 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 o cualquier otra zona horaria que tenga sentido utilizar.

Ver también

  • Variable categórica
  • Almacén de datos
  • Dimensión degenerada
  • Dimensión que cambia lentamente
  • Tabla de hechos
  • ISO / IEC 11179
  • Medir (almacén de datos)
  • Metadatos

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. ^ Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Second Edition, Wiley Computer Publishing, 2002. ISBN  0471-20024-7 , páginas 82-87, 394
  4. ^ Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Second Edition, Wiley Computer Publishing, 2002. ISBN 0471-20024-7 , páginas 202, 405 
  5. ^ 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
  6. ^ Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Second Edition, Wiley Computer Publishing, 2002. ISBN 0471-20024-7 , páginas 50, 398 
  7. ^ Ralph Kimball; Margy Ross (2013). The Data Wharehouse Toolkit 3ª edición . Wiley. pag. 50. ISBN 978-1-118-53080-1.
  8. ^ Ralph Kimball; Margy Ross (2013). The Data Wharehouse Toolkit 3ª edición . Wiley. pag. 51. ISBN 978-1-118-53080-1.
  9. ^ Ralph Kimball; Margy Ross (2013). The Data Wharehouse Toolkit 3ª edición . Wiley. pag. 48. ISBN 978-1-118-53080-1.
  10. ^ Ralph Kimball, Kit de herramientas de almacenamiento de datos, segunda edición, Wiley Publishing, Inc., 2008. ISBN 978-0-470-14977-5 , páginas 253-256 

Obtenido de " https://en.wikipedia.org/w/index.php?title=Dimension_(data_warehouse)&oldid=1027931018 "