Diseño de cubos de datos. Creación de un cubo OLAP con Microsoft Query

Arroz. 2. Rebanada de cubo OLAP

Rotación(Figura 3) - la operación de cambiar la ubicación de las medidas presentadas en el informe o en la página mostrada. Por ejemplo, una operación de rotación puede implicar el intercambio de filas y columnas de una tabla. Además, rotar un cubo de datos mueve dimensiones que no son de tabla a la ubicación de las dimensiones presentes en la página mostrada y viceversa.

Anotación: Esta lección cubre los conceptos básicos del diseño de cubos de datos para almacenes de datos OLAP. El ejemplo muestra cómo construir un cubo de datos usando la herramienta CASE.

El propósito de la conferencia

Después de estudiar el material de esta lección, sabrás:

• ¿Qué es un cubo de datos en Almacén de datos OLAP ;
• cómo diseñar un cubo de datos para Almacenes de datos OLAP ;
• qué es una dimensión de cubo de datos;
• cómo se relaciona el hecho con el cubo de datos;
• qué son los atributos de dimensión;
• qué es una jerarquía;
• qué es una métrica de cubo de datos;

y aprender:

• construir gráficos multidimensionales ;
• diseño sencillo gráficos multidimensionales.

Introducción

La tecnología OLAP no es independiente software, No lenguaje de programación. Si intenta cubrir OLAP en todas sus manifestaciones, entonces este es un conjunto de conceptos, principios y requisitos que subyacen a los productos de software que facilitan a los analistas el acceso a los datos.

Los analistas son los principales consumidores de información corporativa. La tarea de un analista es encontrar patrones en grandes conjuntos de datos. Por lo tanto, el analista no prestará atención al hecho único de que en un día determinado se vendió un lote de bolígrafos al comprador Ivanov; necesita información sobre cientos y miles de eventos similares. Los hechos únicos en el almacén de datos pueden ser de interés, por ejemplo, para un contador o jefe del departamento de ventas, cuya competencia es respaldar un contrato específico. Un registro no es suficiente para un analista; por ejemplo, puede necesitar información sobre todos los contratos de puntos de venta para un mes, un trimestre o un año. Es posible que a Analytics no le interese el TIN del comprador ni su número de teléfono: trabaja con datos numéricos específicos, que son la esencia de su actividad profesional.

La centralización y la estructuración conveniente están lejos de todo lo que necesita un analista. Necesita una herramienta para ver, visualizar información. Sin embargo, los informes tradicionales, incluso construidos sobre la base de un único almacén de datos, carecen de cierta flexibilidad. No se pueden "torcer", "expandir" o "contraer" para obtener la vista deseada de los datos. Cuantas más "rebanadas" y "rebanadas" de datos pueda explorar un analista, más ideas tendrá, las cuales, a su vez, requerirán cada vez más "rebanadas" para su verificación. Como tal herramienta para la exploración de datos, el analista es OLAP.

Aunque OLAP no es un atributo necesario de un almacén de datos, se utiliza cada vez más para analizar la información acumulada en este almacén de datos.

Los datos operativos se recopilan de varias fuentes, se limpian, integran y agregan al almacén de datos. Al mismo tiempo, ya están disponibles para su análisis utilizando varias herramientas de informes. Luego, los datos (en su totalidad o en parte) se preparan para el análisis OLAP. Pueden cargarse en una base de datos OLAP especial o dejarse en un almacén de datos relacional. El elemento más importante del uso de OLAP son los metadatos, es decir, información sobre la estructura, ubicación y transformación de datos. Gracias a ellos, se garantiza la interacción efectiva de varios componentes de almacenamiento.

De este modo, OLAP se puede definir como un conjunto de herramientas para el análisis multidimensional de datos acumulados en un almacén de datos. En teoría, las herramientas OLAP se pueden aplicar directamente a los datos operativos o copias exactas. Sin embargo, existe el riesgo de someter a análisis datos que no son adecuados para este análisis.

OLAP en cliente y servidor

En el corazón de OLAP se encuentra el análisis de datos multidimensionales. Se puede producir utilizando varias herramientas, que se pueden dividir condicionalmente en herramientas OLAP de cliente y servidor.

Las herramientas OLAP del lado del cliente son aplicaciones que calculan y muestran datos agregados (sumas, promedios, máximos o mínimos), y los propios datos agregados se almacenan en caché dentro del espacio de direcciones de la herramienta OLAP.

Si los datos de origen están contenidos en un DBMS de escritorio, la propia herramienta OLAP calcula los datos agregados. Si el origen de los datos de origen es un servidor DBMS, muchas de las herramientas OLAP del cliente envían consultas SQL que contienen la cláusula GROUP BY al servidor y, como resultado, reciben datos agregados calculados en el servidor.

Por regla general, la funcionalidad OLAP se implementa en herramientas de procesamiento de datos estadísticos (desde productos de esta clase hasta mercado ruso Los productos Stat Soft y SPSS son ampliamente utilizados) y en algunas hojas de cálculo. En particular, el Microsoft Excel 2000. Con este producto, puede crear y guardar como un archivo un pequeño cubo OLAP multidimensional local y mostrar sus secciones bidimensionales o tridimensionales.

Muchos herramientas de desarrollo contienen bibliotecas de clases o componentes que le permiten crear aplicaciones que implementan la funcionalidad OLAP más simple (como los componentes Decision Cube en Borland Delphi y Borland C++Builder). Además, muchas empresas ofrecen control S ActiveX y otras bibliotecas que implementan una funcionalidad similar.

Tenga en cuenta que las herramientas OLAP del cliente se utilizan, por regla general, con una pequeña cantidad de dimensiones (por lo general, no se recomiendan más de seis) y una pequeña variedad de valores para estos parámetros; después de todo, los datos agregados recibidos deben caber en el espacio de direcciones de dicha herramienta, y su número crece exponencialmente con un aumento en el número de mediciones. Por lo tanto, incluso las herramientas OLAP de cliente más primitivas, por regla general, le permiten realizar un cálculo preliminar de la cantidad de RAM requerida para crear un cubo multidimensional en él.

Muchas (pero no todas) las herramientas OLAP del lado del cliente le permiten almacenar el contenido de la caché de datos agregados como un archivo, lo que a su vez evita que se vuelvan a calcular. Tenga en cuenta que esta oportunidad se utiliza a menudo para enajenar datos agregados con el fin de transferirlos a otras organizaciones o para su publicación. Un ejemplo típico de tales datos agregados enajenados son las estadísticas de incidencia en diferentes regiones y en diferentes grupos de edad, que es información abierta publicado por los ministerios de salud varios países y la Organización Mundial de la Salud. Al mismo tiempo, los propios datos originales, que son información sobre casos concretos de enfermedades, son datos confidenciales de las instituciones médicas y en ningún caso deben caer en manos de las compañías de seguros y mucho menos hacerse públicos.

La idea de almacenar un caché de datos agregados en un archivo se ha desarrollado aún más en las herramientas OLAP del lado del servidor, en las que el almacenamiento y la modificación de los datos agregados, así como el mantenimiento del almacenamiento que los contiene, se llevan a cabo por una aplicación o proceso separado llamado servidor OLAP. Las aplicaciones cliente pueden solicitar este tipo de almacenamiento multidimensional y recibir algunos datos en respuesta. Algunas aplicaciones cliente también pueden crear dichos almacenes o actualizarlos de acuerdo con los datos de origen modificados.

Las ventajas de usar herramientas OLAP de servidor en comparación con las herramientas OLAP de cliente son similares a las ventajas de usar DBMS de servidor en comparación con las de escritorio: en el caso de usar herramientas de servidor, el cálculo y almacenamiento de datos agregados ocurre en el servidor y la aplicación cliente recibe solo los resultados de las consultas a ellos, lo que permite reducir el tráfico de red en general, tiempo de espera solicitudes y requisitos de recursos consumidos por la aplicación cliente. Tenga en cuenta que el análisis y el procesamiento de datos a escala empresarial, por regla general, se basan precisamente en herramientas OLAP de servidor, por ejemplo, como Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, productos de Crystal Decisions, Business Objects, Cognos , Instituto S.A.S. Dado que todos los principales fabricantes de DBMS de servidor producen (o tienen licencia de otras empresas) ciertas herramientas OLAP de servidor, su elección es bastante amplia y, en casi todos los casos, puede comprar un servidor OLAP del mismo fabricante que el servidor de base de datos.

Tenga en cuenta que muchas herramientas OLAP del cliente (en particular, Microsoft Excel 2003, Seagate Analysis, etc.) le permiten acceder a los almacenamientos OLAP del servidor, actuando en este caso como aplicaciones cliente que realizan dichas consultas. Además, hay muchos productos que son aplicaciones cliente para herramientas OLAP de varios fabricantes.

Aspectos técnicos del almacenamiento de datos multidimensionales

Los almacenes de datos multidimensionales contienen datos agregados con diversos grados de detalle, por ejemplo, volúmenes de ventas por día, mes, año, categoría de producto, etc. El propósito de almacenar datos agregados es reducir tiempo de espera solicitudes, ya que en la mayoría de los casos, para análisis y pronósticos, no son datos detallados, sino resumidos los que interesan. Por lo tanto, al crear una base de datos multidimensional, siempre se calculan y almacenan algunos datos agregados.

Tenga en cuenta que guardar todos los datos agregados no siempre está justificado. El caso es que al agregar nuevas dimensiones, la cantidad de datos que componen el cubo crece exponencialmente (a veces se dice del "crecimiento explosivo" de la cantidad de datos). Más específicamente, la cantidad de crecimiento de datos agregados depende de la cantidad de dimensiones en el cubo y los miembros de las dimensiones en diferentes niveles de las jerarquías de esas dimensiones. Para resolver el problema del "crecimiento explosivo", se utilizan varios esquemas que permiten, al calcular lejos de todos los datos agregados posibles, lograr una velocidad aceptable de ejecución de consultas.

Tanto los datos de origen como los agregados se pueden almacenar en estructuras relacionales o multidimensionales. Por lo tanto, actualmente hay tres formas de almacenar datos.

• MOLAP(OLAP multidimensional): los datos de origen y agregados se almacenan en una base de datos multidimensional. El almacenamiento de datos en estructuras multidimensionales le permite manipular los datos como una matriz multidimensional, de modo que la velocidad de cálculo de los valores agregados sea la misma para cualquiera de las dimensiones. Sin embargo, en este caso, la base de datos multidimensional es redundante, ya que los datos multidimensionales contienen completamente los datos relacionales originales.
• ROLAP(OLAP relacional): los datos originales permanecen en la misma base de datos relacional donde residía originalmente. Los datos agregados se colocan en tablas de servicio especialmente creadas para su almacenamiento en la misma base de datos.
• HOLAP(OLAP híbrido): los datos originales permanecen en la misma base de datos relacional donde residía originalmente, mientras que los datos agregados se almacenan en una base de datos multidimensional.

Algunas herramientas OLAP admiten el almacenamiento de datos solo en estructuras relacionales, algunas, solo en estructuras multidimensionales. Sin embargo, la mayoría de las herramientas de servidor OLAP modernas admiten los tres métodos de almacenamiento de datos. La elección del método de almacenamiento depende del volumen y la estructura de los datos de origen, los requisitos de velocidad de ejecución de consultas y la frecuencia de actualización de los cubos OLAP.

También notamos que la gran mayoría de las herramientas OLAP modernas no almacenan valores "vacíos" (un ejemplo de un valor "vacío" sería la ausencia de ventas de productos de temporada fuera de temporada).

Conceptos básicos de OLAP

prueba FAMSI

La tecnología de análisis de datos multidimensionales complejos se denomina OLAP (On-Line Analytical Processing). OLAP es un componente clave de una organización de almacenamiento de datos. El concepto de OLAP fue descrito en 1993 por Edgar Codd, un conocido investigador de bases de datos y autor del modelo de datos relacionales. En 1995, sobre la base de los requisitos establecidos por Codd, el llamado prueba FASMI(Análisis rápido de información multidimensional compartida): análisis rápido de información multidimensional compartida, incluidos los siguientes requisitos para aplicaciones de análisis multidimensional:

• Rápido(Rápido): proporcionar al usuario los resultados del análisis en un tiempo razonable (normalmente no más de 5 s), incluso a costa de un análisis menos detallado;
• análisis(Análisis) - la capacidad de realizar cualquier análisis lógico y estadístico específico para una aplicación determinada y guardarlo en una forma accesible para el usuario final;
• compartido(Compartido): acceso multiusuario a los datos con soporte para mecanismos de bloqueo apropiados y herramientas de acceso autorizadas;
• Multidimensional(Multidimensional) - Representación conceptual multidimensional de datos, incluido soporte total para jerarquías y múltiples jerarquías (este es un requisito clave de OLAP);
• información(Información): la aplicación debe poder acceder a cualquier información necesaria, independientemente de su volumen y ubicación de almacenamiento.

Cabe señalar que la funcionalidad OLAP se puede implementar diferentes caminos, comenzando con las herramientas de análisis de datos más simples en aplicaciones ofimáticas y terminando con sistemas analíticos distribuidos basados ​​en productos de servidor.

Representación multidimensional de la información

Cuba

OLAP proporciona un medio conveniente y de alta velocidad para acceder, ver y analizar información comercial. El usuario obtiene una visión natural e intuitiva. modelo de datos, organizándolos en forma de cubos multidimensionales (Cubes). Los ejes del sistema de coordenadas multidimensionales son los principales atributos del proceso de negocio analizado. Por ejemplo, para ventas puede ser un producto, región, tipo de comprador. El tiempo se utiliza como una de las medidas. En las intersecciones de los ejes de medidas (Dimensiones) hay datos que caracterizan cuantitativamente el proceso - medidas (Medidas). Estos pueden ser volúmenes de ventas en piezas o en términos monetarios, saldos de existencias, costos, etc. Un usuario que analiza la información puede "cortar" el cubo en diferentes direcciones, obtener un resumen (por ejemplo, por años) o, por el contrario, detallado (semanalmente) información y realizar otras manipulaciones que le vengan a la mente en el proceso de análisis.

Como medidas en el cubo tridimensional que se muestra en la Fig. 26.1, se usan los montos de las ventas y se usan como medidas el tiempo, el producto y la tienda. Las medidas se muestran en ciertos niveles agrupaciones: los productos se agrupan por categorías, tiendas, por países y datos sobre el momento de las transacciones, por meses. Un poco más adelante veremos los niveles de agrupación (jerarquías) con más detalle.

Arroz. 26.1.

"Cortando" el cubo

Incluso un cubo tridimensional es difícil de mostrar en una pantalla de computadora para que se puedan ver los valores de las medidas de interés. ¿Qué podemos decir de los cubos con más de tres dimensiones? Para visualizar los datos almacenados en un cubo, por regla general, se utilizan las representaciones bidimensionales habituales, es decir, tabulares, que tienen encabezados de fila y columna jerárquicos complejos.

Se puede obtener una representación bidimensional de un cubo "cortándolo" a lo largo de uno o más ejes (dimensiones): fijamos los valores de todas las dimensiones, excepto dos, y obtenemos un bidimensional regular mesa. El eje horizontal de la tabla (encabezados de columna) representa una dimensión, el eje vertical (encabezados de fila) representa otra dimensión y las celdas de la tabla representan valores de medida. En este caso, el conjunto de medidas se considera realmente como una de las dimensiones: seleccionamos una medida para mostrar (y luego podemos colocar dos dimensiones en los encabezados de filas y columnas), o mostramos varias medidas (y luego una de los ejes de la tabla estarán ocupados por los nombres de las medidas, y el otro - valores de una sola dimensión "sin cortar").

Arquitectura de aplicaciones OLAP

Todo lo dicho anteriormente sobre OLAP, de hecho, se refería a la presentación multidimensional de datos. En términos generales, ni el usuario final ni los desarrolladores de la herramienta que utiliza el cliente se preocupan por cómo se almacenan los datos.

La multidimensionalidad en las aplicaciones OLAP se puede dividir en tres niveles.

• Representación de datos multidimensionales: herramientas de usuario final que proporcionan visualización multidimensional y manipulación de datos; la capa de representación multidimensional se abstrae de la estructura física de los datos y los trata como multidimensionales.
• Procesamiento multidimensional: una herramienta (lenguaje) para formular consultas multidimensionales (el lenguaje SQL relacional tradicional no es adecuado aquí) y un procesador que puede procesar y ejecutar dicha consulta.
• Almacenamiento multidimensional: medio de organización física de datos que proporciona una ejecución eficiente de consultas multidimensionales.

Los dos primeros niveles son obligatorios en todas las herramientas OLAP. El tercer nivel, aunque se usa ampliamente, no es necesario, ya que los datos para la representación multidimensional también se pueden recuperar de estructuras relacionales ordinarias; el procesador de consultas multidimensionales en este caso traduce consultas multidimensionales en consultas SQL que son ejecutadas por un DBMS relacional.

Los productos OLAP específicos suelen ser una herramienta de presentación de datos multidimensionales (cliente OLAP, por ejemplo, tablas dinámicas en Excel 2000 de Microsoft o ProClarity de Knosys) o un DBMS back-end multidimensional (servidor OLAP, por ejemplo, Oracle Express Server o Microsoft OLAP Servicios).

La capa de procesamiento multidimensional generalmente está integrada en el cliente OLAP y/o el servidor OLAP, pero se puede aislar en su forma más pura, como el componente de servicio de tabla dinámica de Microsoft.

/ De manera cubista. El uso de cubos OLAP en la práctica gerencial de grandes empresas

En contacto con

compañeros de clase

Konstantin Tokmachev, sistema arquitecto

de forma cubista.
El uso de cubos OLAP en la práctica gerencial de grandes empresas

Quizás ya pasó el tiempo en que los recursos de cómputo de la corporación se dedicaban únicamente al registro de información y reportes contables. Al mismo tiempo, las decisiones gerenciales se tomaron "a ojo" en las oficinas, en las reuniones y reuniones. Tal vez sea hora de que Rusia devuelva a los sistemas informáticos corporativos su principal recurso: resolver problemas de control basados ​​​​en datos registrados en una computadora.

Sobre los beneficios de la inteligencia de negocios

En el ciclo de gestión corporativa, entre los datos "en bruto" y las "palancas" para influir en el objeto gestionado, hay "indicadores de rendimiento" - KPI. Forman, por así decirlo, un "tablero", que refleja el estado de varios subsistemas del objeto controlado. Dotar a la empresa de indicadores de rendimiento informativos y controlar su cálculo y los valores obtenidos es labor de un analista de negocio. Los servicios de análisis automatizados, como el MS servidor SQL Analysis Services (SSAS) y su principal dispositivo es un cubo OLAP.

Hay una nota más que hacer aquí. Por ejemplo, en la tradición americana, una especialidad enfocada a trabajar con cubos OLAP se llama BI (Business Intelligence). No debe hacerse ilusiones de que el BI estadounidense corresponde al "analista de negocios" ruso. Sin ofender, pero a menudo nuestro analista de negocios es un "subcontador" y un "subprogramador", un especialista con conocimientos borrosos y un salario pequeño, que realmente no tiene herramientas ni metodología propias.

Un especialista en BI es, de hecho, un matemático aplicado, un especialista de clase alta que pone al servicio de las empresas métodos matemáticos modernos (lo que se denominó Operations Research - métodos de investigación de operaciones). BI está más en línea con la especialidad "analista de sistemas" que solía estar en la URSS, que fue producida por la facultad de VMK de la Universidad Estatal de Moscú. MV Lomonosov. Los servicios de análisis y cubo OLAP pueden convertirse en una base prometedora para el lugar de trabajo de un analista de negocios ruso, quizás después de algunas mejoras en sus calificaciones hacia BI estadounidense.

EN Últimamente Ha surgido otra tendencia dañina. Gracias a la especialización, se ha perdido el entendimiento mutuo entre las diferentes categorías de empleados de la corporación. Un contador, gerente y programador, como un "cisne, cáncer y lucio" en la fábula de I.A. Krylov, tirando de la corporación en diferentes direcciones.

El contador está ocupado informando, sus montos, tanto en significado como en dinámica, no están directamente relacionados con el proceso comercial de la empresa.

El gerente está ocupado con su segmento del proceso comercial, pero no puede evaluar globalmente, a nivel de la empresa como un todo, los resultados y perspectivas de sus acciones.

Finalmente, el programador, que alguna vez fue (gracias a la educación) el conductor de ideas técnicas avanzadas desde la esfera de la ciencia a la esfera de los negocios, se ha convertido en un ejecutor pasivo de las fantasías de un contador y gerente, por lo que ya no es poco común cuando los contadores y, en general, todos los que no son perezosos. El programador 1C no iniciado, analfabeto, pero relativamente bien pagado, es un verdadero flagelo para las corporaciones rusas. (Casi como un jugador de fútbol doméstico.) No hablo de los llamados "economistas y abogados", todo se ha dicho sobre ellos durante mucho tiempo.

Entonces, la posición de un analista de negocios, equipado con un aparato SSAS de alta tecnología, que conoce los conceptos básicos de programación y contabilidad, puede consolidar el trabajo de la empresa en relación con el análisis y pronóstico del proceso de negocios.

Beneficios de los cubos OLAP

El cubo OLAP es instalación moderna análisis de la base de datos del sistema informático corporativo, que permite dotar a los empleados de todos los niveles jerárquicos del conjunto de indicadores necesarios que caracterizan el proceso productivo de la empresa. El punto no es solo que la interfaz fácil de usar y el lenguaje de consulta flexible para el cubo MDX (MultiDimensional eXpressions) le permiten formular y calcular los indicadores analíticos necesarios, sino también en la notable velocidad y facilidad con la que lo hace este cubo OLAP. Además, estas velocidades y facilidades, dentro de ciertos límites, no dependen de la complejidad de los cálculos y del volumen de la base de datos.

Algo de comprensión de OLAP
cubo puede dar una "tabla dinámica" MS Excel. Estos objetos tienen una lógica similar e interfaces similares. Pero, como se verá en el artículo, la funcionalidad de OLAP es incomparablemente más rica y el rendimiento es incomparablemente más alto, por lo que la "tabla dinámica" sigue siendo un producto de escritorio local, mientras que OLAP es un producto de nivel empresarial.

¿Por qué un cubo OLAP es tan adecuado para resolver problemas analíticos? El cubo OLAP está diseñado de tal manera que todos los indicadores en todas las secciones posibles están precalculados (en su totalidad o en parte), y el usuario solo tiene que "sacar" los indicadores requeridos (medidas medidas) y secciones (dimensiones dimensiones ) con el ratón, y el programa vuelve a dibujar las placas.

Todos los análisis posibles en todas las secciones forman un campo enorme, o mejor dicho, no un campo, sino solo un cubo OLAP multidimensional. Cualquiera que sea la solicitud que un usuario (gerente, analista comercial, gerente) haga al servicio de análisis, la velocidad de respuesta se debe a dos cosas: en primer lugar, los análisis requeridos se pueden formular fácilmente (seleccionados de la lista por su nombre o dados por una fórmula en el lenguaje MDX), y en segundo lugar, por regla general, ya se ha calculado.

La formulación de análisis es posible en tres versiones: es un campo de base de datos (más precisamente, un campo de almacén), o un campo de cálculo definido en el nivel de diseño del cubo, o una expresión de lenguaje MDX cuando se trabaja con el cubo de forma interactiva.

Esto significa varias características atractivas de los cubos OLAP a la vez. De hecho, la barrera entre el usuario y los datos desaparece. Una barrera en forma de un programador de aplicaciones, que, en primer lugar, necesita explicar el problema (establecer una tarea). En segundo lugar, tendrá que esperar hasta que el programador de la aplicación cree el algoritmo, escriba y depure el programa, luego se podrá modificar. Si hay muchos empleados y sus requisitos son variados y cambiantes, se necesita todo un equipo de programadores aplicados. En este sentido, un cubo OLAP (y un analista comercial calificado) en términos de trabajo analítico reemplaza a todo un equipo de programadores de aplicaciones, ¡al igual que una excavadora poderosa con un conductor de retroexcavadora cuando cava una zanja reemplaza a toda una brigada de trabajadores invitados con palas!

En este caso se consigue otra cualidad muy importante de los datos analíticos obtenidos. Dado que el cubo OLAP es uno para toda la empresa, es decir Dado que este es el mismo campo con analistas para todos, se excluye una molesta inconsistencia en los datos. Cuando un gerente tiene que asignar la misma tarea a varios empleados independientes para eliminar el factor de subjetividad, pero aún traen respuestas diferentes, que cada uno se compromete a explicar de alguna manera, etc. El cubo OLAP asegura la uniformidad de los datos analíticos en diferentes niveles de la jerarquía corporativa, es decir. si el gerente quiere detallar un determinado indicador de interés para él, seguramente llegará a los datos de nivel inferior con los que trabaja su subordinado, y estos serán solo los datos sobre la base de los cuales se calcula el indicador de nivel superior , y no algunos otros datos, recibidos de alguna otra manera, en algún otro momento, etc. Es decir, toda la empresa ve el mismo análisis, pero en diferentes niveles de consolidación.

Tomemos un ejemplo. Suponga que un gerente controla las cuentas por cobrar. Mientras el KPI de las cuentas por cobrar vencidas esté en verde, entonces todo es normal, no se requieren acciones de administración. Si el color ha cambiado a amarillo o rojo, algo anda mal: cortamos el KPI por departamento de ventas e inmediatamente vemos las divisiones “en rojo”. Se define la siguiente sección sobre los gerentes y el vendedor, cuyos clientes se atrasan en los pagos. (Más adelante, el monto de la demora se puede desglosar por compradores, por términos, etc.) El jefe de la corporación puede dirigirse directamente a los infractores en cualquier nivel. Pero, en general, tanto los jefes de departamento como los gerentes de ventas ven el mismo KPI (en sus niveles de jerarquía). Por lo tanto, para corregir la situación, ni siquiera necesitan esperar una "llamada en la alfombra" ... Por supuesto, el KPI en sí no tiene que ser necesariamente la cantidad de morosidad, puede ser un promedio ponderado. período de morosidad o, en general, la tasa de rotación de las cuentas por cobrar.

Tenga en cuenta que la complejidad y flexibilidad del lenguaje MDX, junto con resultados rápidos (a veces instantáneos), hace posible resolver (teniendo en cuenta las etapas de desarrollo y depuración) tareas de control complejas que, en otras condiciones, podrían no haberse planteado. en absoluto debido a la complejidad para los programadores aplicados y la incertidumbre inicial en la formulación. (Largos plazos para que los programadores de aplicaciones resuelvan problemas analíticos debido a una formulación mal entendida y a menudo se encuentran en la práctica largas modificaciones del programa cuando las condiciones cambian).

Prestemos atención también al hecho de que cada empleado de la empresa puede recoger del campo general del analista OLAP exactamente la cosecha que necesita para trabajar, y no contentarse con la "franja" que ha cortado en los "informes estándar" comunales. ”.

Una interfaz multiusuario para trabajar con un cubo OLAP en modo cliente-servidor permite que cada empleado, independientemente de los demás, tenga sus propios bloques (informes) de análisis (incluso de producción propia con alguna habilidad), que, una vez definidos, se actualizado - en otras palabras, siempre están actualizados.

Es decir, el cubo OLAP te permite hacer más selectivo el trabajo analítico (que en realidad no solo lo hacen los analistas de billetes, sino, de hecho, casi todos los empleados de la empresa, incluso los logísticos y los gerentes que controlan los saldos y los envíos), “ de la cara no en una expresión general”, lo que crea condiciones para mejorar el trabajo y aumentar la productividad.

Resumiendo nuestra introducción, notamos que el uso de cubos OLAP puede elevar la gestión de una empresa en más nivel alto. Uniformidad de los datos analíticos en todos los niveles de la jerarquía, su confiabilidad, complejidad, facilidad para crear y modificar indicadores, configuraciones individuales, alta velocidad de procesamiento de datos y, finalmente, ahorro de dinero y tiempo invertido en respaldar rutas analíticas alternativas (programadores de aplicaciones, independientes). cálculos de un empleado), abren perspectivas para el uso de cubos OLAP en la práctica de las grandes empresas rusas.

OLTP + OLAP: un circuito de retroalimentación en la cadena de gestión empresarial

Ahora considere la idea general de los cubos OLAP y su punto de aplicación en la cadena de gestión corporativa. El término OLAP (Procesamiento analítico en línea) fue introducido por el matemático británico Edgar Codd además de su término anterior OLTP (Procesamiento de transacciones en línea). Esto se discutirá más adelante, pero E. Codd, por supuesto, no solo propuso los términos, sino también las teorías matemáticas de OLTP y OLAP. Sin entrar en detalles, en la interpretación moderna de OLTP es una base de datos relacional, considerada como un mecanismo de registro, almacenamiento y recuperación de información.

Metodología de solución

Dichos sistemas ERP (Enterprice Resource Planning), como 1C7, 1C8, MS Dynamics AX, tienen interfaces de software orientadas al usuario (ingreso y corrección de documentos, etc.) y una base de datos relacional (DB) para almacenar y recuperar información presentada hoy. productos de software escriba MS SQL Server (SS).

Tenga en cuenta que la información registrada en la base de datos del sistema ERP es de hecho un recurso muy valioso. No se trata solo de que la información registrada proporcione el flujo de trabajo actual de la corporación (emisión de documentos, corrección de los mismos, posibilidad de impresión y conciliación, etc.) y no solo la posibilidad de calcular Estados financieros(impuestos, auditoría, etc.). Desde el punto de vista de la gestión, es mucho más importante que un sistema OLTP (base de datos relacional) sea, de hecho, un modelo digital real de las actividades de una corporación en tamaño completo.

Pero para gestionar el proceso no basta con registrar información al respecto. El proceso debe presentarse como un sistema de indicadores numéricos (KPI) que caracterizan su curso. Además, se deben definir rangos de valores permisibles para los indicadores. Y solo si el valor del indicador va más allá del intervalo permitido, debe seguir una acción de control.

En torno a tal lógica (o mitología) de la gestión (“gestión por desviación”) convergen y filósofo griego antiguo Platón, que creó la imagen de un timonel (nariz cibernética), que se apoya en el remo cuando el barco se desvía del rumbo, y el matemático estadounidense Norbert Wiener, que creó la ciencia de la cibernética en vísperas de la era de las computadoras.

Además del sistema habitual para registrar información utilizando el método OLTP, se necesita un sistema más: un sistema para analizar la información recopilada. Este complemento, que en el lazo de control cumple la función de retroalimentación entre la gestión y el objeto de control, es un sistema OLAP o, en definitiva, un cubo OLAP.

Como implementación de software de OLAP, consideraremos la utilidad MS Analysis Services, que forma parte de la entrega estándar de MS SQL Server, abreviado como SSAS. Tenga en cuenta que, según la idea de E. Codd, el cubo OLAP en análisis debe dar la misma libertad de acción exhaustiva que el sistema OLTP y la base de datos relacional (SQL Server) dan para almacenar y recuperar información.

Logística OLAP

Ahora consideremos la configuración específica de dispositivos externos, aplicaciones y operaciones tecnológicas en las que se basa la operación automatizada del cubo OLAP.

Supondremos que la corporación utiliza un sistema ERP, por ejemplo, 1C7 o 1C8, dentro del cual se registra la información de la forma habitual. La base de datos de este sistema ERP se encuentra en un servidor determinado y es mantenida por MS SQL Server.

También supondremos que el software está instalado en otro servidor, incluido MS SQL Server con la utilidad MS Analysis Services (SSAS), así como los programas MS SQL Server Management Studio, MS C#, MS Excel y MS Visual Studio. Estos programas juntos forman el contexto requerido: las herramientas y las interfaces necesarias para el desarrollador de cubos OLAP.

El servidor SSAS tiene instalado el software gratuito blat, llamado (con parámetros) desde línea de comando y prestación de servicios postales.

En los puestos de trabajo de los empleados, dentro red local, entre otras cosas, se instalan programas MS Excel (versión 2003 o superior), así como, posiblemente, un controlador especial para permitir que MS Excel funcione con MS Analysis Services (a menos que el controlador correspondiente ya esté incluido en MS Excel).

Para mayor precisión, supondremos que las estaciones de trabajo de los empleados tienen instalado el sistema operativo Windows XP y los servidores tienen instalado Windows Server 2008. Además, use MS SQL Server 2005 como SQL Server y Enterprise Edition (EE) o Edición para desarrolladores (DE). En estas ediciones, es posible utilizar los llamados. "medidas semiaditivas", es decir, funciones agregadas adicionales (estadísticas) distintas de las sumas regulares (por ejemplo, valor extremo o medio).

Diseño de cubo OLAP (cubismo OLAP)

Digamos algunas palabras sobre el diseño del propio cubo OLAP. En el lenguaje de las estadísticas, un cubo OLAP es un conjunto de indicadores de rendimiento calculados en todas las secciones necesarias, por ejemplo, un indicador de envío en secciones por compradores, por mercancías, por fechas, etc. Debido a la traducción directa del inglés en la literatura rusa sobre cubos OLAP, los indicadores se denominan "medidas" y los cortes se denominan "dimensiones". Esta es una traducción matemáticamente correcta, pero sintáctica y semánticamente no muy exitosa. Las palabras rusas "medida", "medida", "dimensión" casi no difieren en significado y ortografía, mientras que "medida" y "dimensión" en inglés son diferentes tanto en ortografía como en significado. Por lo tanto, preferimos los términos estadísticos rusos tradicionales de significado similar a "indicador" y "corte".

Hay varias opciones para la implementación del software del cubo OLAP en relación con el sistema OLTP donde se registran los datos. Consideraremos solo un esquema, el más simple, el más confiable y el más rápido.

En este esquema, OLAP y OLTP no tienen tablas comunes, y los análisis de OLAP se calculan con el mayor detalle posible en la etapa de actualización del cubo (proceso) antes de la etapa de uso. Este esquema se llama MOLAP (Multidimensional OLAP). Sus desventajas son la asincronía con ERP y los altos costos de memoria.

Aunque formalmente se puede construir un cubo OLAP usando todas las (miles) tablas de una base de datos relacional del sistema ERP como fuente de datos y todos (cientos) de sus campos como indicadores o secciones, en realidad esto no debería hacerse. Viceversa. Para cargar en un cubo, es más correcto preparar una base de datos separada llamada "escaparate" o "almacén" (almacén).

Hay varias razones por las que este es el caso.

• En primer lugar, vincular un cubo OLAP a tablas bases reales los datos sin duda crearán problemas técnicos. El cambio de datos en una tabla puede desencadenar una actualización del cubo, y actualizar un cubo no es necesariamente un proceso rápido, por lo que el cubo estará en un estado de reconstrucción permanente; al mismo tiempo, el procedimiento de actualización del cubo puede bloquear (durante la lectura) los datos de las tablas de la base de datos, ralentizando el trabajo de los usuarios en el registro de datos en el sistema ERP.
• En segundo lugar, la presencia de demasiados indicadores y cortes aumentará drásticamente el área de almacenamiento del cubo en el servidor. No olvidemos que el cubo OLAP almacena no solo los datos iniciales, como en el sistema OLTP, sino también todos los indicadores resumidos sobre todas las secciones posibles (e incluso sobre todas las combinaciones de todas las secciones). Además, la velocidad de actualización del cubo y, finalmente, la velocidad de creación y actualización de análisis e informes de usuario basados ​​en ellos se ralentizarán en consecuencia.
• Tercero, demasiados campos (medidas y aspectos) crearán problemas en la interfaz de desarrollador OLAP, porque las listas de elementos se volverán interminables.
• Cuatro, Un cubo OLAP es muy sensible a las violaciones de integridad de datos. No se puede crear un cubo si los datos clave no se encuentran mediante un enlace especificado en la estructura de enlace de los campos del cubo. Violación temporal o permanente de la integridad, los campos en blanco son comunes en la base de datos de un sistema ERP, pero esto categóricamente no es adecuado para OLAP.

También puede agregar que el sistema ERP y el cubo OLAP deben estar ubicados en servidores diferentes para compartir la carga. Pero entonces, si existen tablas comunes para OLAP y OLTP, también existe el problema del tráfico de red. En este caso aparecen problemas prácticamente irresolubles si es necesario consolidar varios sistemas ERP heterogéneos (1C7, 1C8, MS Dynamics AX) en un cubo OLAP.

Probablemente, es posible acumular más problemas técnicos. Pero lo más importante, recuerde que, a diferencia de OLTP, OLAP no es un medio para registrar y almacenar datos, sino una herramienta de análisis. Esto significa que no hay necesidad de cargar y cargar datos "sucios" de ERP a OLAP "por si acaso". Por el contrario, primero debe desarrollar un concepto para administrar una empresa, al menos a nivel del sistema KPI, y luego diseñar un almacén de datos de aplicaciones (almacén) ubicado en el mismo servidor que el cubo OLAP y que contiene una pequeña cantidad refinada de ERP datos necesarios para la gestión.

no promocionar malos hábitos, el cubo OLAP en relación con OLTP se puede comparar con el conocido "cubo de alambique", mediante el cual se extrae un "producto limpio" de la "masa fermentada" de un registro real.

Entonces, obtuvimos que la fuente de datos para OLAP es una base de datos especial (almacén) ubicada en el mismo servidor que OLAP. Básicamente, esto significa dos cosas. Primero, debe haber procedimientos especiales que crearán un almacén a partir de las bases de datos de ERP. En segundo lugar, el cubo OLAP es asíncrono con sus sistemas ERP.

Teniendo en cuenta lo anterior, proponemos la siguiente versión de la arquitectura del proceso computacional.

Arquitectura de soluciones

Supongamos que hay muchos sistemas ERP de una determinada corporación (explotación) en diferentes servidores, para los cuales nos gustaría ver los datos analíticos consolidados dentro de un cubo OLAP. Destacamos que en la tecnología descrita combinamos datos de sistemas ERP a nivel de almacén, dejando sin cambios el diseño del cubo OLAP.

En el servidor OLAP creamos imágenes (copias en blanco) de las bases de datos de todos estos sistemas ERP. A estas copias vacías, periódicamente (todas las noches) realizamos una replicación parcial de las bases de datos de los ERP correspondientes que se ejecutan activamente.

A continuación, se inicia el SP (procedimiento almacenado), que en el mismo servidor OLAP sin tráfico de red, sobre la base de réplicas parciales de las bases de datos de los sistemas ERP, crea (o repone) el almacenamiento (almacén), la fuente de datos del OLAP. cubo.

Luego se inicia el procedimiento estándar para actualizar/construir un cubo de acuerdo con los datos del almacén (la operación Proceso en la interfaz SSAS).

Comentemos algunos aspectos de la tecnología. ¿Qué tipo de trabajo hacen los SP?

Como resultado de la replicación parcial, los datos reales aparecen en la imagen de algún sistema ERP en el servidor OLAP. Por cierto, la replicación parcial se puede realizar de dos formas.

Primero, de todas las tablas en la base de datos del sistema ERP, durante la replicación parcial, solo se copian aquellas que son necesarias para construir el almacén. Esto está controlado por una lista fija de nombres de tablas.

En segundo lugar, la replicación parcial también puede significar que no se copian todos los campos de la tabla, sino solo aquellos que están involucrados en la construcción del almacén. La lista de campos a copiar se especifica o se crea dinámicamente en el SP a partir de la imagen de la copia (si la copia de la tabla no contiene inicialmente todos los campos).

Por supuesto, es posible no copiar filas completas de la tabla, sino solo agregar nuevos registros. Sin embargo, esto crea un serio inconveniente al contabilizar las revisiones de ERP "retroactivas", que a menudo se encuentran en los sistemas de la vida real. Entonces es más fácil, sin más preámbulos, copiar todos los registros (o actualizar la "cola" a partir de alguna fecha).

Además, la tarea principal de SP es convertir los datos de los sistemas ERP al formato de almacén. Si solo hay un sistema ERP, entonces la tarea de transformación se reduce principalmente a copiar y posiblemente reformatear los datos necesarios. Pero si necesita consolidar varios sistemas ERP en un mismo cubo OLAP estructura diferente, entonces las transformaciones se vuelven más complicadas.

Particularmente difícil es la tarea de consolidar varios sistemas ERP diferentes en un cubo, si los conjuntos de sus objetos (directorios de bienes, contratistas, almacenes, etc.) se cruzan parcialmente, los objetos tienen el mismo significado, pero naturalmente se describen de manera diferente en los directorios diferentes sistemas(en el sentido de códigos, identificadores, nombres, etc.).

En realidad, tal imagen surge en una gran sociedad de cartera, cuando varias empresas autónomas del mismo tipo que la componen realizan aproximadamente los mismos tipos de actividades en aproximadamente el mismo territorio, pero utilizan sus propios sistemas de registro no coordinados. En este caso, al consolidar datos a nivel de almacén, no puede prescindir de las tablas de mapeo auxiliares.

Prestemos atención a la arquitectura de almacenamiento del almacén. Normalmente, un esquema de cubo OLAP se representa como una "estrella", es decir, como una tabla de datos rodeada de "rayos" de directorios - tablas de valores clave secundarios. La tabla es un bloque de "indicadores", los libros de referencia son sus cortes. Al mismo tiempo, el directorio, a su vez, puede ser un árbol desequilibrado arbitrario o una jerarquía equilibrada, por ejemplo, una clasificación de bienes o contrapartes de varios niveles. En un cubo OLAP, los campos numéricos de la tabla de datos del almacén se convierten automáticamente en "indicadores" (o medidas de medidas), y las secciones (o dimensiones) se pueden definir a través de tablas de claves secundarias.

Esta es una descripción "pedagógica" visual. De hecho, la arquitectura de un cubo OLAP puede ser mucho más compleja.

En primer lugar, un almacén puede constar de varios "asteriscos", posiblemente vinculados a través de directorios comunes. En este caso, el cubo OLAP será una unión de varios cubos (múltiples bloques de datos).

En segundo lugar, el "rayo" del asterisco puede no ser un directorio, sino un sistema de archivos completo (jerárquico).

En tercer lugar, sobre la base de los cortes de dimensión existentes, se pueden definir nuevos cortes jerárquicos utilizando la interfaz de desarrollador OLAP (por ejemplo, con menos niveles, con un orden de niveles diferente, etc.)

En cuarto lugar, se pueden definir nuevos indicadores (cálculos) sobre la base de indicadores y secciones existentes utilizando la expresión del lenguaje MDX. Es importante tener en cuenta que los nuevos cubos, los nuevos indicadores, las nuevas secciones se integran automáticamente por completo con los elementos originales. También se debe tener en cuenta que los cálculos mal formulados y los cortes jerárquicos pueden ralentizar notablemente el trabajo de un cubo OLAP.

MS Excel como interfaz con OLAP

De particular interés es la interfaz de usuario con cubos OLAP. Naturalmente, la propia utilidad SSAS proporciona la interfaz más completa. Este es un kit de herramientas para desarrolladores de cubos OLAP, un diseñador de informes interactivos y una ventana para el trabajo interactivo con un cubo OLAP mediante consultas en el lenguaje MDX.

Además del propio SSAS, existen muchos programas que proporcionan una interfaz a OLAP, cubriendo su funcionalidad en mayor o menor medida. Pero entre ellos hay uno que, en nuestra opinión, tiene ventajas innegables. Esto es MS Excel.

La interfaz con MS Excel la proporciona un controlador especial, que puede descargarse por separado o incluirse con Excel. No cubre toda la funcionalidad de OLAP, pero con el crecimiento de los números de versión de MS Excel, esta cobertura es cada vez más amplia (por ejemplo, en MS Excel 2007 aparece un gráfico de KPI, que no estaba en MS Excel 2003, etc.).

Por supuesto, además de una funcionalidad bastante completa, la principal ventaja de MS Excel es la distribución ubicua de este programa y el conocimiento cercano de la gran mayoría de los usuarios de la oficina. En este sentido, a diferencia de otros programas de interfaz, la empresa no necesita adquirir nada adicional y no necesita capacitar a nadie adicionalmente.

La gran ventaja de MS Excel como interfaz con OLAP es la posibilidad de seguir procesando de forma independiente los datos obtenidos en un informe OLAP (es decir, la continuación del estudio de los datos obtenidos de OLAP en otras hojas del mismo Excel, ya no utilizando herramientas OLAP, pero utilizando herramientas ordinarias de Excel).

Ciclo de tratamiento facubi nocturno

Ahora describamos el ciclo informático diario (nocturno) de la operación OLAP. El cálculo se realiza bajo el control del programa facubi, escrito en C# 2005 y lanzado mediante Task Scheduler en un servidor con warehouse y SSAS. Al principio, facubi accede a Internet y lee los tipos de cambio actuales (utilizados para representar una serie de indicadores en una moneda). A continuación, se realizan los siguientes pasos.

Primero, facubi lanza SP que realizan una replicación parcial de la base de datos de varios sistemas ERP (elementos de retención) disponibles en la red local. La replicación se realiza, como dijimos, en "patios" preparados previamente: imágenes de sistemas ERP remotos ubicados en el servidor SSAS.

En segundo lugar, a través de SP, se realiza un mapeo desde las réplicas de ERP hasta el almacenamiento del almacén, una base de datos especial que es la fuente de los datos del cubo OLAP y se encuentra en el servidor SSAS. Esto logra tres tareas principales:

• datos ERP se traen bajo los formatos de cubo requeridos; estamos hablando de tablas y campos de tablas. (A veces, la tabla requerida debe "moldearse", por ejemplo, a partir de varias hojas de MS Excel). Los datos similares pueden tener un formato diferente en diferentes ERP, por ejemplo, los campos de ID clave en los directorios 1C7 tienen un código de 36 caracteres de longitud 8 , y _idrref campos en directorios 1C8 - números hexadecimales con una longitud de 32;
• durante el procesamiento se lleva a cabo el control lógico de los datos (incluida la prescripción de valores predeterminados "predeterminados" en lugar de los datos que faltan, cuando sea posible) y el control de integridad, es decir, verificar la presencia de claves primarias y secundarias en los clasificadores correspondientes;
• consolidación de código objetos que tienen el mismo significado en diferentes ERP. Por ejemplo, los elementos correspondientes de directorios de diferentes ERP pueden tener el mismo significado, digamos, esta es la misma contraparte. La tarea de consolidación de códigos se resuelve construyendo tablas de mapeo, donde diferentes códigos de los mismos objetos se unen.

En tercer lugar, facubi lanza el procedimiento estándar de actualización de datos del cubo de proceso (de los procedimientos de la utilidad SSAS).

De acuerdo con las listas de verificación, facubi envía mensajes de correo electrónico sobre el progreso de los pasos de procesamiento.

Después de ejecutar facubi, el Programador de tareas lanza varios archivos de Excel, en los que se crean informes basados ​​en los indicadores del cubo OLAP. Como dijimos, MS Excel tiene una interfaz de programación especial (controlador incorporado o descargable por separado) para trabajar con cubos OLAP (con SSAS). Cuando inicia MS Excel, se incluyen programas en MS VBA (como macros), que brindan actualización de datos en informes; los informes se modifican si es necesario y se envían por correo (programa blat) a los usuarios de acuerdo con las listas de verificación.

Los usuarios de la red local con acceso al servidor SSAS recibirán informes "en vivo" configurados para el cubo OLAP. (En principio, ellos mismos, sin ningún correo, pueden actualizar los informes OLAP en MS Excel, ubicados en sus computadoras locales). Los usuarios fuera de la red local recibirán informes originales, pero con funcionalidad limitada, o para ellos (después de actualizar los informes OLAP en MS Excel) se calcularán informes especiales "muertos" que no contactan con el servidor SSAS.

Evaluación de resultados

Hablamos anteriormente sobre la asincronía de OLTP y OLAP. En la versión considerada de la tecnología, el ciclo de actualización del cubo OLAP se realiza por la noche (digamos, comienza a la 1 am). Esto significa que en el día hábil actual, los usuarios trabajan con los datos de ayer. Debido a que OLAP no es una herramienta de registro (ver la última versión del documento), sino una herramienta de gestión (comprender la tendencia del proceso), esta acumulación generalmente no es crítica. Sin embargo, si es necesario, incluso en la versión descrita de la arquitectura del cubo (MOLAP), es posible actualizar varias veces al día.

El tiempo de ejecución de los procedimientos de actualización depende de las características de diseño del cubo OLAP (más o menos complejidad, definiciones de indicadores y secciones más o menos acertadas) y del volumen de bases de datos de sistemas OLTP externos. Según la experiencia, los trámites para construir un almacén toman de varios minutos a dos horas, el procedimiento de actualización de un cubo (Proceso) toma de 1 a 20 minutos. Estamos hablando de cubos OLAP complejos que combinan docenas de estructuras estelares, de docenas de "rayos" (cortes de referencia) comunes para ellos, de cientos de indicadores. Estimando el volumen de bases de datos de sistemas ERP externos por documentos de envío, estamos hablando de cientos de miles de documentos y, en consecuencia, millones de líneas de productos por año. La profundidad histórica de procesamiento de interés para el usuario fue de tres a cinco años.

La tecnología descrita se utiliza en varias grandes corporaciones: desde 2008 en Russian Fish Company (RRK) y Russian Sea Company (RM), desde 2012 en Santa Bremor Company (SB). Algunas de las corporaciones son predominantemente empresas de compras comerciales (RRK), otras son empresas de producción (plantas de procesamiento de pescado y mariscos en la República de Moldova y el Consejo de Seguridad). Todas las corporaciones son grandes participaciones que unen varias empresas con varios sistemas informáticos de contabilidad independientes, que van desde sistemas ERP estándar como 1C7 y 1C8 hasta sistemas de contabilidad "reliquia" basados ​​en DBF y Excel. Agregaré que la tecnología descrita para operar cubos OLAP (sin tener en cuenta la etapa de desarrollo) no requiere empleados especiales o está incluida en las responsabilidades de un analista comercial de tiempo completo. La tarea ha estado girando durante años en modo automático, proporcionando diariamente informes actualizados a varias categorías de empleados corporativos.

Pros y contras de la solución.

Como muestra la experiencia, la variante de la solución propuesta es bastante confiable y fácil de operar. Se modifica fácilmente (conectar/desconectar nuevos ERP, crear nuevos indicadores y secciones, crear y modificar informes de Excel y sus listas de correo) con la invariancia del programa de control facubi.

MS Excel como interfaz con OLAP proporciona suficiente expresividad y permite que varias categorías de trabajadores de oficina se unan rápidamente a la tecnología OLAP. El usuario recibe informes OLAP "estándar" diarios; utilizando la interfaz de MS Excel con OLAP, puede crear informes OLAP de forma independiente en MS Excel. Además, el usuario puede continuar explorando de forma independiente la información de los informes OLAP utilizando las capacidades habituales de su MS Excel.

Una base de datos de almacén “refinada”, en la que se consolidan varios sistemas ERP heterogéneos (durante la construcción del cubo), incluso sin ningún OLAP, permite resolver (en el servidor SSAS, utilizando el método de consulta Transact SQL o el método SP, etc.) gran cantidad de tareas de gestión aplicadas. Recuerde que la estructura de la base de datos del almacén es unificada y mucho más simple (en términos de número de tablas y número de campos de tabla) que las estructuras de base de datos del ERP original.

Destacamos especialmente que en nuestra solución propuesta existe la posibilidad de consolidar varios sistemas ERP en un cubo OLAP. Esto le permite obtener análisis para todo el holding y mantener la continuidad a largo plazo en los análisis cuando una corporación se traslada a otro sistema de contabilidad ERP, por ejemplo, al pasar de 1C7 a 1C8.

Utilizamos el modelo de cubo MOLAP. Las ventajas de este modelo son la confiabilidad en la operación y la alta velocidad de procesamiento de las solicitudes de los usuarios. Contras: OLAP y OLTP asíncronos, así como grandes cantidades de memoria para almacenar OLAP.

En conclusión, demos un argumento más a favor de OLAP, que, quizás, hubiera sido más apropiado en la Edad Media. Porque su poder probatorio descansa en la autoridad. El modesto y claramente subestimado matemático británico E. Codd desarrolló la teoría de las bases de datos relacionales a finales de los años 60. La fuerza de esta teoría era tal que ahora, después de 50 años, ya es difícil encontrar una base de datos no relacional y un lenguaje de consulta de base de datos que no sea SQL.

La tecnología OLTP, basada en la teoría de las bases de datos relacionales, fue la primera idea de E. Codd. De hecho, el concepto de cubos OLAP es su segunda idea, expresada por él a principios de los 90. Incluso si no eres matemático, puedes esperar que la segunda idea sea tan efectiva como la primera. Es decir, en términos de análisis informático, las ideas OLAP pronto dominarán el mundo y suplantarán a todas las demás. Sencillamente porque el tema de la analítica encuentra su solución matemática exhaustiva en OLAP, y esta solución es “adecuada” (término de B. Spinoza) a la tarea práctica de la analítica. "Adecuadamente" significa en Spinoza que ni siquiera el mismo Dios podría haber tenido una idea mejor...

1. Larson B. Desarrollo de inteligencia empresarial en Microsoft SQL Server 2005. - San Petersburgo: "Piter", 2008.
2. Codd E. Completitud relacional de los sublenguajes de bases de datos, Sistemas de bases de datos, Courant Computer Science Sumposia Series 1972, v. 6, acantilados de Englwood, Nueva York, Prentice–Hall.

En contacto con

Lo que es OLAP hoy, en general, todo especialista lo sabe. Al menos los conceptos de "OLAP" y "datos multidimensionales" están firmemente conectados en nuestras mentes. Sin embargo, el hecho de que este tema se plantee nuevamente, espero, sea aprobado por la mayoría de los lectores, porque para que la idea no se vuelva obsoleta con el tiempo, debe comunicarse periódicamente con gente inteligente o leer artículos en una buena publicación...

Almacenes de datos (el lugar de OLAP en la estructura de información de la empresa)

El término "OLAP" está indisolublemente ligado al término "almacén de datos" (Data Warehouse).

Aquí hay una definición formulada por el "padre fundador" de los almacenes de datos, Bill Inmon: "Un almacén de datos es una colección de datos inmutable, específica de un dominio y limitada en el tiempo para respaldar el proceso de toma de decisiones gerenciales".

Los datos en el almacenamiento provienen de sistemas operativos (sistemas OLTP), que están diseñados para automatizar procesos comerciales. Además, el repositorio se puede reponer desde fuentes externas, como informes estadísticos.

¿Por qué construir almacenes de datos? Después de todo, contienen información obviamente redundante que ya "vive" en las bases de datos o archivos de los sistemas operativos. La respuesta puede ser breve: es imposible o muy difícil analizar los datos de los sistemas operativos directamente. Esto se debe a varias razones, incluida la fragmentación de datos, su almacenamiento en los formatos de varios DBMS y en diferentes "rincones" de la red corporativa. Pero incluso si todos los datos de la empresa se almacenan en un servidor de base de datos central (lo cual es extremadamente raro), el analista seguramente no comprenderá sus estructuras complejas, a veces confusas. El autor tiene una experiencia bastante triste al tratar de "alimentar" a los analistas hambrientos con datos "en bruto" de los sistemas operativos; resultó ser demasiado difícil para ellos.

Por lo tanto, la tarea del repositorio es proporcionar "materias primas" para el análisis en un solo lugar y en una estructura simple y comprensible. Ralph Kimball, en el prefacio de su libro "The Data Warehouse Toolkit", escribe que si, después de leer todo el libro, el lector entiende solo una cosa, a saber, que la estructura del almacén debe ser simple, el autor considerará su tarea terminado.

Hay otra razón que justifica la aparición de un almacenamiento separado: las consultas analíticas complejas de información operativa ralentizan el trabajo actual de la empresa, bloquean las tablas durante mucho tiempo y aprovechan los recursos del servidor.

En mi opinión, el almacenamiento no es necesariamente una acumulación gigante de datos; lo principal es que es conveniente para el análisis. En términos generales, un término separado está destinado a pequeños almacenamientos: Data Marts (quioscos de datos), pero en nuestra práctica rusa no lo escuchará a menudo.

OLAP es una herramienta de análisis útil

La centralización y la estructuración conveniente están lejos de todo lo que necesita un analista. Después de todo, todavía necesita una herramienta para ver, visualizar información. Los informes tradicionales, incluso creados sobre la base de un único repositorio, carecen de una cosa: flexibilidad. No se pueden "torcer", "expandir" o "contraer" para obtener la vista deseada de los datos. Por supuesto, puede llamar a un programador (si él quiere venir), y él (si no está ocupado) hará un nuevo informe con bastante rapidez, digamos, dentro de una hora (escribo y no lo creo yo mismo) no pasa tan rápido en la vida, démosle tres horas). Resulta que un analista no puede verificar más de dos ideas por día. Y él (si es un buen analista) puede generar varias ideas de este tipo por hora. Y cuantos más "rebanadas" y "rebanadas" de datos ve el analista, más ideas tiene, las cuales, a su vez, requieren más y más nuevas "rebanadas" para su verificación. ¡Ojalá tuviera una herramienta que le permitiera expandir y contraer datos de manera simple y conveniente! OLAP es una de esas herramientas.

Aunque OLAP no es un atributo necesario de un almacén de datos, se utiliza cada vez más para analizar la información acumulada en este almacén de datos.

Los componentes incluidos en un almacenamiento típico se muestran en la fig. 1.

Arroz. 1. Estructura del almacén de datos

Los datos operativos se recopilan de varias fuentes, se limpian, se integran y se colocan en un almacén relacional. Al mismo tiempo, ya están disponibles para su análisis utilizando varias herramientas de informes. Luego, los datos (en su totalidad o en parte) se preparan para el análisis OLAP. Pueden cargarse en una base de datos OLAP especial o dejarse en un almacén relacional. Su elemento más importante son los metadatos, es decir, información sobre la estructura, ubicación y transformación de los datos. Gracias a ellos, se garantiza la interacción efectiva de varios componentes de almacenamiento.

Resumiendo, podemos definir OLAP como un conjunto de herramientas para el análisis multidimensional de los datos acumulados en un almacén. Teóricamente, las herramientas OLAP se pueden aplicar directamente a los datos operativos o sus copias exactas (para no interferir con los usuarios operativos). Pero al hacerlo, corremos el riesgo de pisar el rastrillo ya descrito anteriormente, es decir, comenzar a analizar datos operativos que no son directamente aptos para el análisis.

Definición y conceptos básicos de OLAP

Para empezar, descifremos: OLAP es Procesamiento Analítico en Línea, es decir, análisis de datos en línea. Los 12 principios definitorios de OLAP fueron formulados en 1993 por E. F. Codd, el "inventor" de las bases de datos relacionales. Más tarde, su definición se reformuló en la llamada prueba FASMI, que requiere una aplicación OLAP para brindar la capacidad de analizar rápidamente información multidimensional compartida ().

prueba FASMI

Rápido(Rápido): el análisis debe realizarse con la misma rapidez en todos los aspectos de la información. El tiempo de respuesta aceptable es de 5 segundos o menos.

análisis(Análisis) - Debería ser posible realizar tipos básicos de análisis numérico y estadístico, predefinidos por el desarrollador de la aplicación o definidos arbitrariamente por el usuario.

compartido(Compartido): varios usuarios deben tener acceso a los datos, mientras que el acceso a la información confidencial debe estar controlado.

Multidimensional(Multidimensional) es la característica principal y más esencial de OLAP.

información(Información): la aplicación debe poder acceder a cualquier información necesaria, independientemente de su volumen y ubicación de almacenamiento.

OLAP = Vista Multidimensional = Cubo

OLAP proporciona un medio conveniente y de alta velocidad para acceder, ver y analizar información comercial. El usuario obtiene un modelo de datos natural e intuitivo, organizándolos en forma de cubos multidimensionales (Cubes). Los ejes del sistema de coordenadas multidimensionales son los principales atributos del proceso de negocio analizado. Por ejemplo, para ventas puede ser un producto, región, tipo de comprador. El tiempo se utiliza como una de las medidas. En las intersecciones de los ejes - medidas (Dimensiones) - hay datos que caracterizan cuantitativamente el proceso - medidas (Medidas). Estos pueden ser volúmenes de ventas en piezas o en términos monetarios, saldos de existencias, costos, etc. Un usuario que analiza la información puede "cortar" el cubo en diferentes direcciones, obtener un resumen (por ejemplo, por años) o, por el contrario, detallado (semanalmente) información y realizar otras manipulaciones que le vengan a la mente en el proceso de análisis.

Como medidas en el cubo tridimensional que se muestra en la Fig. 2, se usan cantidades de ventas y tiempo, producto y tienda se usan como medidas. Las mediciones se presentan en niveles de agrupación específicos: los productos se agrupan por categoría, las tiendas se agrupan por país y los tiempos de transacción se agrupan por mes. Un poco más adelante consideraremos los niveles de agrupación (jerarquía) con más detalle.

Arroz. 2. Ejemplo de cubo

"Cortando" el cubo

Incluso un cubo tridimensional es difícil de mostrar en una pantalla de computadora para que se puedan ver los valores de las medidas de interés. ¿Qué podemos decir de los cubos con más de tres dimensiones? Para visualizar los datos almacenados en el cubo, por regla general, se utilizan las vistas bidimensionales habituales, es decir, tabulares, que tienen encabezados de columna y fila jerárquicos complejos.

Se puede obtener una representación bidimensional de un cubo "cortándolo" en uno o más ejes (dimensiones): fijamos los valores de todas las dimensiones, excepto dos, y obtenemos una tabla bidimensional regular . El eje horizontal de la tabla (encabezados de columna) representa una dimensión, el eje vertical (encabezados de fila) representa otra dimensión y las celdas de la tabla representan valores de medida. En este caso, el conjunto de medidas se considera realmente como una de las dimensiones: seleccionamos una medida para mostrar (y luego podemos colocar dos dimensiones en los encabezados de filas y columnas), o mostramos varias medidas (y luego una de los ejes de la tabla estarán ocupados por los nombres de las medidas, y el otro - el valor de una sola dimensión "sin cortar").

Echa un vistazo a la fig. 3: aquí hay una porción bidimensional del cubo para una medida: Ventas unitarias (piezas vendidas) y dos dimensiones "sin cortar": Tienda (Tienda) y Tiempo (Tiempo).

Arroz. 3. Rebanada de cubo bidimensional para una medida

En la fig. 4 muestra solo una dimensión "sin cortar" - Tienda, pero muestra los valores de varias medidas - Ventas unitarias (piezas vendidas), Ventas en tienda (cantidad de ventas) y Costo de tienda (gastos de tienda).

Arroz. 4. Corte de cubos 2D para múltiples medidas

Una representación bidimensional de un cubo también es posible cuando más de dos dimensiones permanecen "sin cortar". En este caso, se colocarán dos o más dimensiones del cubo "cortado" en los ejes de división (filas y columnas); consulte la fig. 5.

Arroz. 5. Corte bidimensional de un cubo con varias dimensiones en el mismo eje

Etiquetas

Los valores "reservados" a lo largo de las dimensiones se denominan miembros o etiquetas (members). Las etiquetas se utilizan tanto para "cortar" el cubo como para restringir (filtrar) los datos seleccionados - cuando en una dimensión que permanece "sin cortar" no estamos interesados ​​en todos los valores, sino en su subconjunto, por ejemplo, tres ciudades de varias docena. Los valores de etiqueta aparecen en la vista de cubo 2D como encabezados de fila y columna.

Jerarquías y niveles

Las etiquetas se pueden combinar en jerarquías que constan de uno o más niveles. Por ejemplo, las etiquetas de la dimensión "Tienda" (Tienda) se combinan naturalmente en una jerarquía con niveles:

País (País)

Estado (Estado)

Ciudad (Ciudad)

Tienda).

Según los niveles de la jerarquía, se calculan valores agregados, como las ventas para EE. UU. (nivel "País") o para California (nivel "Estado"). Se puede implementar más de una jerarquía en una dimensión, por ejemplo, para el tiempo: (Año, Trimestre, Mes, Día) y (Año, Semana, Día).

Arquitectura de aplicaciones OLAP

Todo lo dicho anteriormente sobre OLAP, de hecho, se refería a la presentación multidimensional de datos. En términos generales, ni el usuario final ni los desarrolladores de la herramienta que utiliza el cliente se preocupan por cómo se almacenan los datos.

La multidimensionalidad en las aplicaciones OLAP se puede dividir en tres niveles:

• Representación de datos multidimensionales: herramientas de usuario final que proporcionan visualización multidimensional y manipulación de datos; la capa de representación multidimensional se abstrae de la estructura física de los datos y los trata como multidimensionales.
• Procesamiento multidimensional: una herramienta (lenguaje) para formular consultas multidimensionales (el lenguaje SQL relacional tradicional no es adecuado aquí) y un procesador que puede procesar y ejecutar dicha consulta.
• Almacenamiento multidimensional: medio de organización física de datos que proporciona una ejecución eficiente de consultas multidimensionales.

Los dos primeros niveles son obligatorios en todas las herramientas OLAP. El tercer nivel, aunque se usa ampliamente, no es necesario, ya que los datos para la representación multidimensional también se pueden recuperar de estructuras relacionales ordinarias; el procesador de consultas multidimensionales en este caso traduce consultas multidimensionales en consultas SQL que son ejecutadas por un DBMS relacional.

Los productos OLAP específicos suelen ser una herramienta de presentación de datos multidimensionales, un cliente OLAP (por ejemplo, tablas dinámicas en Excel 2000 de Microsoft o ProClarity de Knosys) o un DBMS back-end multidimensional, un servidor OLAP (por ejemplo, Oracle Express Server o Servicios OLAP de Microsoft).

La capa de procesamiento multidimensional generalmente está integrada en el cliente OLAP y/o el servidor OLAP, pero se puede aislar en su forma más pura, como el componente de servicio de tabla dinámica de Microsoft.

Aspectos técnicos del almacenamiento de datos multidimensionales

Como se mencionó anteriormente, las herramientas de análisis OLAP también pueden extraer datos directamente de los sistemas relacionales. Este enfoque resultó más atractivo en un momento en que los servidores OLAP no figuraban en las listas de precios de los principales proveedores de bases de datos. Pero hoy, Oracle, Informix y Microsoft ofrecen servidores OLAP completos, e incluso aquellos administradores de TI a los que no les gusta plantar un "zoológico" de software de diferentes fabricantes en sus redes pueden comprar (más precisamente, aplicar con una solicitud correspondiente a la gestión de la empresa) Servidor OLAP de la misma marca que el servidor de base de datos principal.

Los servidores OLAP, o servidores de bases de datos multidimensionales, pueden almacenar sus datos multidimensionales de diferentes formas. Antes de considerar estos métodos, debemos hablar de un aspecto tan importante como el almacenamiento de áridos. El hecho es que en cualquier almacén de datos, tanto en uno regular como multidimensional, junto con los datos detallados recuperados de los sistemas operativos, también se almacenan indicadores de resumen (indicadores agregados, agregados), como las sumas de los volúmenes de ventas por meses, por categorías bienes, etc. Los agregados se almacenan explícitamente con el único propósito de acelerar la ejecución de consultas. Después de todo, por un lado, por regla general, se acumula una gran cantidad de datos en el almacenamiento y, por otro lado, los analistas en la mayoría de los casos no están interesados ​​​​en indicadores detallados, sino generalizados. Y si se tuvieran que sumar millones de ventas individuales cada vez para calcular la cantidad de ventas del año, lo más probable es que la velocidad sea inaceptable. Por lo tanto, al cargar datos en una base de datos multidimensional, se calculan y guardan todos los indicadores totales o parte de ellos.

Pero, como sabes, tienes que pagar por todo. Y tiene que pagar por la velocidad de procesamiento de consultas para resumir datos al aumentar la cantidad de datos y el tiempo que lleva cargarlos. Además, el aumento de volumen puede volverse literalmente catastrófico: en una de las pruebas estándar publicadas, el recuento completo de agregados para 10 MB de datos iniciales requirió 2,4 GB, es decir, ¡los datos crecieron 240 veces! El grado de "hinchazón" de los datos al calcular los agregados depende del número de dimensiones del cubo y la estructura de estas dimensiones, es decir, la proporción del número de "padres" e "hijos" en diferentes niveles de la dimensión. Para solucionar el problema del almacenamiento de áridos a veces se utilizan esquemas complejos, que permiten, al calcular lejos de todos los agregados posibles, lograr un aumento significativo en el rendimiento de ejecución de consultas.

Ahora sobre las diversas opciones para almacenar información. Tanto los datos detallados como los agregados se pueden almacenar en estructuras relacionales o multidimensionales. El almacenamiento multidimensional le permite tratar los datos como una matriz multidimensional, lo que proporciona el mismo cálculo rápido de totales y varias transformaciones multidimensionales en cualquiera de las dimensiones. Hace algún tiempo, los productos OLAP admitían almacenamiento relacional o multidimensional. Hoy, como regla general, el mismo producto proporciona ambos tipos de almacenamiento, así como un tercer tipo: mixto. Se aplican los siguientes términos:

• MOLAP(OLAP multidimensional): tanto los datos detallados como los agregados se almacenan en una base de datos multidimensional. En este caso se obtiene la mayor redundancia, ya que los datos multidimensionales contienen completamente datos relacionales.
• ROLAP(OLAP relacional) - los datos detallados permanecen donde "vivieron" originalmente - en una base de datos relacional; los agregados se almacenan en la misma base de datos en tablas de servicio especialmente creadas.
• HOLAP(OLAP híbrido): los datos detallados permanecen en su lugar (en una base de datos relacional), mientras que los agregados se almacenan en una base de datos multidimensional.

Cada uno de estos métodos tiene sus ventajas y desventajas y debe usarse según las condiciones: la cantidad de datos, el poder del DBMS relacional, etc.

Al almacenar datos en estructuras multidimensionales, existe un problema potencial de "hinchazón" debido al almacenamiento de valores vacíos. Después de todo, si se reserva un lugar en una matriz multidimensional para todas las combinaciones posibles de etiquetas de medición, y solo se llena una pequeña parte (por ejemplo, una cantidad de productos se vende solo en una pequeña cantidad de regiones), entonces la mayoría de el cubo estará vacío, aunque el lugar estará ocupado. Los productos OLAP modernos pueden hacer frente a este problema.

Continuará. En el futuro, hablaremos sobre productos OLAP específicos producidos por fabricantes líderes.

OLAP no es un único producto de software, ni un lenguaje de programación, ni siquiera una tecnología específica. Si intenta cubrir OLAP en todas sus manifestaciones, entonces este es un conjunto de conceptos, principios y requisitos que subyacen a los productos de software que facilitan a los analistas el acceso a los datos. Vamos a averiguar Para qué los analistas necesitan algo especial facilitar acceso a los datos.

El hecho es que los analistas son consumidores especiales de información corporativa. La tarea de un analista es encontrar patrones en grandes arreglos de datos.. Por lo tanto, el analista no prestará atención al hecho único de que el jueves, el cuarto día, se vendió un lote de tinta negra a la contraparte Chernov: necesita información sobre cientos y miles eventos similares. Los hechos únicos en la base de datos pueden ser de interés, por ejemplo, para un contador o el jefe del departamento de ventas, en cuya competencia se encuentra la transacción. Un registro no es suficiente para un analista; por ejemplo, puede necesitar todas las transacciones de una sucursal u oficina de representación determinada durante un mes o un año. al mismo tiempo analista descartes detalles innecesarios como el TIN del comprador, su dirección exacta y número de teléfono, índice de contrato y similares. Al mismo tiempo, los datos que un analista necesita para trabajar contienen necesariamente valores numéricos, esto se debe a la esencia misma de su actividad.

Entonces, un analista necesita muchos datos, estos datos son selectivos y también tienen una naturaleza ". conjunto de atributos - número". Esto último significa que el analista trabaja con tablas del siguiente tipo:

Aquí " Un país", "Producto", "Año son atributos o mediciones, A " Volumen de ventas" - por lo tanto, un valor numérico o medida. La tarea del analista, repetimos, es identificar relaciones persistentes entre atributos y parámetros numéricos.. Mirando la tabla, puede ver que se puede traducir fácilmente en tres dimensiones: en uno de los ejes ponemos países, en el otro, bienes, en el tercero, años. Y los valores en esta matriz tridimensional serán los volúmenes de ventas correspondientes.

Representación 3D de la mesa. El segmento gris muestra que no hay datos para Argentina en 1988

Es precisamente una matriz tridimensional de este tipo en términos de OLAP la que se denomina cubo. De hecho, desde el punto de vista de las matemáticas estrictas, dicha matriz no siempre será un cubo: para un cubo real, el número de elementos en todas las dimensiones debe ser el mismo, mientras que los cubos OLAP no tienen esa limitación. Sin embargo, a pesar de estos detalles, el término "cubos OLAP", debido a su brevedad e imaginería, se ha vuelto generalmente aceptado. Un cubo OLAP no tiene que ser 3D en absoluto. Puede ser tanto bidimensional como multidimensional, dependiendo del problema a resolver. Los analistas especialmente experimentados pueden necesitar alrededor de 20 mediciones, y los productos OLAP serios están diseñados para ese número. Las aplicaciones de escritorio más simples admiten alrededor de 6 dimensiones.

mediciones Los cubos OLAP se componen de los llamados marcas o miembros. Por ejemplo, la dimensión "País" consta de las etiquetas "Argentina", "Brasil", "Venezuela", etc.

No se deben llenar todos los elementos del cubo: si no hay información sobre las ventas de productos de caucho en Argentina en 1988, simplemente no se determinará el valor en la celda correspondiente. Tampoco es necesario que una aplicación OLAP almacene datos necesariamente en una estructura multidimensional; lo principal es que para el usuario estos datos se ven exactamente así. Por cierto, es precisamente en formas especiales de almacenamiento compacto de datos multidimensionales que el "vacío" (elementos sin llenar) en cubos no conduce a una pérdida de memoria.

Sin embargo, el cubo en sí no es adecuado para el análisis. Si todavía es posible representar o representar adecuadamente un cubo tridimensional, entonces con seis o diecinueve dimensiones la situación es mucho peor. Es por eso antes de usar los cubos ordinarios se extraen de un cubo multidimensional tablas bidimensionales. Esta operación se llama "cortar" el cubo. De nuevo, este término es figurativo. El analista, por así decirlo, toma y "corta" las dimensiones del cubo de acuerdo con las marcas que le interesan. De esta forma, el analista recibe una rebanada bidimensional del cubo y trabaja con ella. Más o menos de la misma manera, los leñadores cuentan los anillos anuales en un corte de sierra.

En consecuencia, por regla general, solo quedan dos dimensiones "sin cortar", según el número de dimensiones de la mesa. Sucede que solo la dimensión permanece "sin cortar": si el cubo contiene varios tipos de valores numéricos, se pueden trazar de acuerdo con una de las dimensiones de la tabla.

Si observa más de cerca la tabla que mostramos primero, puede ver que los datos que contiene, muy probablemente, no son primarios, sino que se obtienen como resultado de suma para artículos más pequeños. Por ejemplo, un año se divide en trimestres, los trimestres en meses, los meses en semanas, las semanas en días. Un país se compone de regiones, y las regiones se componen de localidades. Finalmente, en las propias ciudades se pueden distinguir distritos y puntos de venta específicos. Los productos se pueden combinar en grupos de productos y así sucesivamente. En términos de OLAP, estas uniones multinivel se denominan lógicamente jerarquías. Las herramientas OLAP permiten en cualquier momento pasar al nivel deseado de la jerarquía. Además, por regla general, se admiten varios tipos de jerarquías para los mismos elementos: por ejemplo, día-semana-mes o día-década-trimestre. Los datos de origen se toman de los niveles inferiores de las jerarquías y luego se resumen para obtener los valores de los niveles superiores. Para acelerar el proceso de transición, los valores sumados para diferentes niveles se almacenan en un cubo. Por lo tanto, lo que parece un cubo desde el lado del usuario, en términos generales, consta de muchos más cubos primitivos.

Ejemplo de jerarquía

Este es uno de los puntos esenciales que llevaron al surgimiento de OLAP: productividad y eficiencia. Imaginemos lo que sucede cuando un analista necesita obtener información y las herramientas OLAP no están disponibles en la empresa. El analista de forma independiente (lo que es poco probable) o con la ayuda de un programador realiza una consulta SQL adecuada y recibe los datos de interés en forma de informe o los exporta a una hoja de cálculo. Hay muchos problemas con esto. En primer lugar, el analista se ve obligado a hacer algo diferente a su trabajo (programación SQL) o esperar a que los programadores hagan la tarea por él; todo esto afecta negativamente la productividad laboral, el asalto, el aumento del nivel de ataque cardíaco y accidente cerebrovascular, etc. . En segundo lugar, un solo informe o tabla, por regla general, no salva a los gigantes del pensamiento y a los padres del análisis ruso, y todo el procedimiento deberá repetirse una y otra vez. En tercer lugar, como ya hemos descubierto, los analistas no piden bagatelas, necesitan todo a la vez. Esto significa (aunque la tecnología avanza a pasos agigantados) que el servidor de base de datos relacional empresarial al que accede el analista puede pensar profundamente y durante mucho tiempo, bloqueando el resto de transacciones.

El concepto de OLAP apareció precisamente para resolver tales problemas. Los cubos OLAP son esencialmente metainformes. Al cortar los metainformes (es decir, cubos) por dimensiones, el analista en realidad recibe los informes bidimensionales "normales" que le interesan (estos no son necesariamente informes en el sentido habitual del término: estamos hablando de estructuras de datos con las mismas funciones). Las ventajas de los cubos son obvias: los datos deben solicitarse de un DBMS relacional solo una vez, al construir un cubo. Dado que los analistas, por regla general, no trabajan con información que se complementa y cambia sobre la marcha, el cubo generado es relevante durante bastante tiempo. Gracias a esto, no solo se eliminan las interrupciones en el funcionamiento del servidor DBMS relacional (no hay consultas con miles y millones de líneas de respuesta), sino que se aumenta drásticamente la velocidad de acceso a los datos para el propio analista. Además, como ya se señaló, el rendimiento también se mejora al calcular subsumas de jerarquías y otros valores agregados en el momento de la construcción del cubo. Es decir, si inicialmente nuestros datos contenían información sobre el ingreso diario de un producto específico en una sola tienda, luego al formar el cubo, la aplicación OLAP calcula los totales para diferentes niveles de jerarquías (semanas y meses, ciudades y países).

Por supuesto, tiene que pagar para aumentar la productividad de esta manera. A veces se dice que una estructura de datos simplemente "explota" - cubo OLAP puede ocupar decenas e incluso cientos de veces más espacio que los datos originales.

Responde a las preguntas:

Qué ha pasado cubo ¿OLAP?

Qué ha pasado etiquetas dimensión específica? Dar ejemplos.

Pueden ellos medidas en un cubo OLAP, contienen valores no numéricos.