Hoy en día, los informes y análisis son casi tan importantes como el negocio principal. Los informes se pueden construir a partir de sus datos en vivo; a menudo, este enfoque funcionará para las pequeñas y medianas empresas sin una gran cantidad de datos. Pero cuando las cosas se hacen más grandes, o la cantidad de datos comienza a aumentar drásticamente, es hora de pensar en separar sus sistemas operativos y de informes.
Antes de abordar el modelado básico de datos, necesitamos algunos antecedentes sobre los sistemas involucrados. Aproximadamente podemos dividir los sistemas en dos categorías:sistemas operativos y de informes. Los sistemas operativos a menudo se denominan procesamiento de transacciones en línea (OLTP). Los sistemas analíticos y de generación de informes se denominan Procesamiento analítico en línea (OLAP). Los sistemas OLTP dan soporte a los procesos de negocio. Trabajan con datos operativos "en vivo", están altamente normalizados y reaccionan muy rápidamente a las acciones del usuario. Por otro lado, el propósito principal de los sistemas OLAP es el análisis. Estos sistemas utilizan datos resumidos, que normalmente se colocan en una estructura de almacenamiento de datos no normalizada como el esquema en estrella. (¿Qué es la desnormalización? En pocas palabras, es tener registros de datos redundantes en aras de un mejor rendimiento. Lea más).
Ahora que sabemos un poco sobre los sistemas, comencemos a examinar el almacén de datos y sus piezas y procesos.
Almacenes de datos frente a mercados de datos
Un almacén de datos (DWH) es un sistema utilizado para almacenar información para su uso en análisis de datos y elaboración de informes. Markets de datos son áreas de un almacén de datos que se utilizan para almacenar la información que necesita un solo departamento o incluso un usuario individual. (Piense en el DWH como un edificio y en los data marts como oficinas dentro del edificio).
¿Por qué son necesarios los data marts? Todos los datos relevantes se almacenan dentro de la empresa DWH. Sin embargo, la mayoría de los usuarios solo necesitan acceder a ciertos subconjuntos de datos, como los relacionados con ventas, producción, logística o marketing. Los data marts son importantes tanto desde el punto de vista de la seguridad (que limitan el acceso innecesario) como desde el punto de vista del usuario (no queremos confundirlos ni obligarlos a navegar a través de datos extraños).
Hay dos enfoques diferentes para la relación almacén de datos-mart de datos:
- Descendente :Los data marts se crean a partir del almacén de datos. (Esto es algo con lo que Bill Inmon, el "padre del almacén de datos", estaría de acuerdo, junto con la idea de que los almacenes deberían estar en 3NF).
- De abajo hacia arriba :Los data marts se crean primero y luego se combinan en un almacén de datos. (Este enfoque está más cerca de lo que defiende Ralph Kimball, experto en almacenamiento de datos y modelado dimensional).
El proceso ETL se utiliza para agregar datos "nuevos" al sistema OLAP de forma regular. ETL es la abreviatura de Extraer, Transformar y Cargar. Como sugiere el nombre, extraeremos datos de una o más bases de datos operativas, los transformaremos para que se ajusten a nuestra estructura de almacén y cargaremos los datos en el DWH.
Modelado dimensional , que forma parte del diseño del almacén de datos, da como resultado la creación del modelo dimensional. Hay dos tipos de tablas involucradas:
-
Tablas de dimensiones se utilizan para describir los datos que queremos almacenar. Por ejemplo:un minorista puede querer almacenar la fecha, la tienda y el empleado involucrado en una compra específica. Cada tabla de dimensiones es su propia categoría (fecha, empleado, tienda) y puede tener uno o más atributos . Para cada tienda, podemos guardar su ubicación a nivel de ciudad, región, estado y país. Para cada fecha podemos almacenar el año, mes, día del mes, día de la semana, etc. Esto está relacionado con la jerarquía de atributos en la tabla de dimensiones.
En el esquema de estrella, generalmente encontraremos que algunos atributos son un subconjunto de otros atributos en el mismo registro. Esta redundancia es deliberada y se hace en nombre de un mejor desempeño. Podríamos usar las dimensiones de fecha, ubicación y agente de ventas para agregar (la parte de transformación del proceso ETL) y almacenar datos dentro de DWH. En el modelado dimensional, es muy importante definir las dimensiones correctas y elegir la granulación adecuada.
- Tablas de hechos contienen los datos que queremos incluir en los informes, agregados en función de los valores dentro de las tablas de dimensiones relacionadas. Una tabla de hechos solo tiene columnas que almacenan valores y claves externas que hacen referencia a las tablas de dimensiones. La combinación de todas las claves foráneas forma la clave principal de la tabla de hechos. Por ejemplo, una tabla de hechos podría almacenar una cantidad de contactos y la cantidad de ventas resultantes de estos contactos.
Con esta información en su lugar, ahora podemos profundizar en el modelo de datos de esquema en estrella.
El esquema de estrella
El esquema de estrella es el modelo más simple utilizado en DWH. Debido a que la tabla de hechos está en el centro del esquema con tablas de dimensiones a su alrededor, se ve más o menos como una estrella. Esto es especialmente evidente cuando la tabla de hechos está rodeada por tablas de cinco dimensiones. Una variante del esquema de estrella, el esquema de ciempiés , donde la tabla de hechos está rodeada por un gran número de tablas de dimensiones pequeñas.
Los esquemas en estrella se utilizan con mucha frecuencia en los data marts. Podemos relacionarlos con el enfoque del modelo de datos de arriba hacia abajo. Analizaremos dos esquemas en estrella (data marts) y luego los combinaremos para crear un solo modelo.
Ejemplo de esquema en estrella:Ventas
El informe de ventas es uno de los informes más comunes de la actualidad. Como mencionamos antes, en la mayoría de los casos podríamos generar informes de ventas desde el sistema en vivo. Pero cuando los datos o el tamaño de la empresa hacen que esto sea demasiado engorroso, tendremos que construir un almacén de datos o un data mart para agilizar el proceso. Después de diseñar nuestro esquema en estrella, un ETL El proceso obtendrá los datos de las bases de datos operativas, los transformará al formato adecuado para el DWH y los cargará en el almacén.
El modelo presentado arriba contiene una tabla de hechos (de color rojo claro) y cinco tablas de dimensiones (de color azul claro). Las tablas del modelo son:
fact_sales– Esta tabla contiene referencias a las tablas de dimensiones más dos hechos (precio y cantidad vendida). Tenga en cuenta que las cinco claves foráneas juntas forman la clave principal de la tabla.dim_sales_type– Esta es una tabla de dimensión de tipo de venta con un solo atributo, “type_name”.dim_employee– Esta es una tabla de dimensiones de empleados que almacena los atributos básicos de los empleados:nombre completo y año de nacimiento.dim_product– Esta es una tabla de dimensiones del producto con solo dos atributos (además de la clave principal):nombre del producto y tipo de producto.dim_time– Esta tabla maneja la dimensión del tiempo. Contiene cinco atributos además de la clave principal. Los datos de nivel más bajo son las ventas por fecha (action_date). Laaction_weekEl atributo es el número de la semana de ese año (es decir, la primera semana de enero recibiría el número 1; la última semana de diciembre recibiría el número 52, etc.) Elactual_monthyactual_yearLos atributos almacenan el mes y el año del calendario en que se produjo la venta. Estos se pueden extraer de laaction_dateatributo. Elaction_weekdayEl atributo almacena el nombre del día en que se realizó la venta.dim_store– Esta es una dimensión de la tienda. Para cada tienda guardaremos la ciudad, región, estado y país donde se encuentra. Aquí podemos notar claramente que el esquema de estrella está desnormalizado.
Ejemplo de esquema en estrella:pedidos de suministros
Hay muchas similitudes entre este modelo, que se muestra a continuación, y el modelo de ventas.
Este modelo está destinado a almacenar el historial de pedidos realizados. Tenemos una tabla de hechos y cuatro tablas de dimensiones. Las tablas de dimensiones dim_employee , dim_product y dim_time son exactamente los mismos que en el modelo de ventas. Sin embargo, las siguientes tablas son diferentes:
fact_supply_order– contiene datos agregados sobre los pedidos realizados.dim_supplier– es una tabla de dimensiones que almacena datos de proveedores de la misma manera quedim_storemantuvo los datos de la tienda en el modelo de ventas.
Ventajas y desventajas del esquema en estrella
El uso del esquema en estrella tiene muchas ventajas. La tabla de hechos está relacionada con cada tabla de dimensiones por exactamente una relación, y no necesitamos ningún diccionario adicional para describir las tablas de dimensiones. Eso simplifica las consultas y disminuye el tiempo de ejecución de las consultas. Podríamos generar el mismo informe directamente desde nuestro sistema OLTP, pero la consulta sería mucho más compleja y podría afectar el rendimiento general del sistema. La siguiente consulta de ejemplo para el modelo de ventas devolverá la cantidad de todos los productos de tipo teléfono vendidos en las tiendas de Berlín en 2016:
SELECT dim_store.store_address, SUM(fact_sales.quantity) AS quantity_sold FROM fact_sales INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id WHERE dim_time.action_year = 2016 AND dim_store.city = 'Berlin' AND dim_product.product_type = 'phone' GROUP BY dim_store.store_id, dim_store.store_address
La mayor desventaja del esquema en estrella es la redundancia. Cada dimensión se almacena en una tabla de dimensiones separada y esto provoca la desnormalización. En nuestro ejemplo, ciudad pertenece a una región o estado, que pertenece a un país; no almacenamos esa relación como regla en nuestra base de datos, sino que la repetimos continuamente. Esto significa que gastaremos más espacio en disco y tendremos un riesgo de integridad de datos.
El esquema de la galaxia
Podemos ver los dos modelos anteriores como dos data marts, uno para el departamento de ventas y otro para el departamento de abastecimiento. Cada uno de ellos consta de una sola tabla de hechos y algunas tablas dimensionales. Si quisiéramos, podríamos combinar estos dos data marts en un solo modelo. Este tipo de esquema, que contiene varias tablas de hechos y comparte algunas tablas de dimensiones, se denomina esquema de galaxia. . Compartir tablas de dimensiones puede reducir el tamaño de la base de datos, especialmente cuando las dimensiones compartidas tienen muchos valores posibles. Idealmente, en ambos data marts las dimensiones se definen de la misma manera. Si ese no es el caso, tendremos que ajustar las dimensiones para que se ajusten a ambas necesidades.
A continuación se muestra un esquema de galaxia, construido a partir de nuestros dos data marts de ejemplo:
El esquema en estrella es un enfoque para organizar un almacén de datos. Es muy sencillo y se usa con mayor frecuencia en data marts. Si no tenemos que preocuparnos por el espacio en disco y cuidamos bien la integridad de los datos, entonces el esquema en estrella es la primera y mejor opción viable. Si no, deberíamos pensar en otro enfoque. Uno es el esquema de copo de nieve, del que hablaremos en un próximo artículo.
