En el modelado de almacenes de datos, una comprensión general del modelo estrella es que la tabla de hechos corresponde a muchas tablas de dimensiones; no entiendo muy bien el modelo de copo de nieve.
El modelado de datos multidimensionales de esquema en estrella versus esquema de copo de nieve organiza los datos de una manera intuitiva y admite el acceso a datos de alto rendimiento. Cada modelo de datos multidimensional está representado por múltiples esquemas de datos multidimensionales, y cada esquema de datos multidimensional consta de una tabla de hechos y un conjunto de tablas de dimensiones. El modelo multidimensional más común es el esquema en estrella. En el esquema en estrella, la tabla de hechos está en el centro y las tablas de múltiples dimensiones están distribuidas radialmente a su alrededor y conectadas a la tabla de hechos. A partir de la forma de la estrella se desarrolla un patrón de copo de nieve. Comparemos las características de los dos. La entidad con un patrón de estrella en el centro de la estrella es una entidad indicadora, que es la entidad básica que más preocupa a los usuarios. Es el centro de las actividades de consulta y proporciona datos cuantitativos para las actividades de consulta en el almacén de datos. Cada entidad indicadora representa una serie de hechos relacionados y realiza una función específica. Las entidades ubicadas en las esquinas de las estrellas del gráfico estelar son entidades de dimensión. Su función es limitar los resultados de la consulta del usuario y filtrar los datos para que la consulta de la entidad de índice devuelva menos filas, reduciendo así el alcance del acceso. Cada tabla de dimensiones tiene sus propios atributos, y la tabla de dimensiones y la tabla de hechos están relacionadas mediante palabras clave. Aunque el esquema en estrella es un modelo relacional, no es un modelo estandarizado. En el esquema en estrella, las tablas de dimensiones se desnormalizan deliberadamente, que es la diferencia básica entre el esquema en estrella y el esquema relacional en los sistemas OLTP. Hay dos razones principales para utilizar el esquema en estrella: mejorar la eficiencia de las consultas. La ventaja de un almacén de datos diseñado con un esquema en estrella es que la organización de los datos ha sido preprocesada y los datos principales están en una tabla de hechos enorme, por lo que puede realizar consultas escaneando la tabla de hechos sin conectar varias tablas enormes, y la eficiencia del acceso a las consultas es alto. Al mismo tiempo, debido a que las tablas de dimensiones son generalmente pequeñas, incluso se pueden colocar en el caché, lo que hace que la conexión con la tabla de hechos sea más rápida y fácil de entender para los usuarios. Para los usuarios no profesionales de la informática, el esquema en estrella es relativamente intuitivo y es fácil combinar varias consultas analizando el esquema en estrella. Resumen: No normalización; cada dimensión del cubo está conectada a la tabla de hechos (a través de claves primarias y externas no hay dimensiones de gradiente; la eficiencia de la consulta puede ser mayor; no se presta mucha atención a los factores de normalización); El diseño y el mantenimiento son relativamente simples.
En aplicaciones prácticas, con el aumento y cambio de las tablas de hechos y de dimensiones, el modelo de estrella producirá muchos modelos derivados, incluidos modelos de galaxias, modelos de constelaciones, tablas de dimensiones bidimensionales, modelos de copos de nieve, etc. El esquema de copo de nieve es una capa adicional de la tabla de dimensiones del esquema en estrella. Extiende algunas tablas de dimensiones a tablas de hechos. Esto no solo puede manejar las consultas de los usuarios en diferentes niveles, sino que también integra los datos de origen a través de enlaces entre niveles para minimizar la capacidad de almacenamiento de datos. , mejorando así las capacidades de consulta. La tabla de dimensiones del patrón de copo de nieve se basa en la teoría del paradigma, por lo que es un patrón de diseño entre el tercer paradigma y el patrón de estrella. Por lo general, algunas organizaciones de datos adoptan la estructura estándar de la tercera forma normal, y algunas organizaciones de datos adoptan la tabla de hechos del esquema en estrella y la estructura de la tabla de dimensiones. En algunos casos, la formación del esquema de copo de nieve se debe a la estandarización de las tablas de datos para reducir la estructura jerárquica de las tablas de dimensiones y manejar relaciones de muchos a muchos al organizar los datos en el esquema de estrella. Las ventajas del modo copo de nieve son: reduce en cierta medida el espacio de almacenamiento; la estructura estandarizada es más fácil de actualizar y mantener. De manera similar, el esquema de copo de nieve también tiene muchas deficiencias: el esquema de copo de nieve es complejo y difícil de entender para los usuarios; es relativamente difícil navegar por el contenido y reducirá el rendimiento de la consulta; En los almacenes de datos, generalmente no se recomienda el uso de "copos de nieve". Debido a que el rendimiento de las consultas es más importante que los sistemas OLTP en los almacenes de datos, el modo copo de nieve reducirá el rendimiento de los sistemas de almacenamiento de datos. Resumen: normalización; menos redundancia de datos; algunos datos requieren conexión para obtenerse, lo que puede no ser eficiente; las operaciones de estandarización son complejas, lo que resulta en un diseño complejo y un mantenimiento posterior, se puede usar una combinación de los dos modelos anteriores: como capa intermedia La estructura de copo de nieve se utiliza para reducir la redundancia de datos y la parte del centro de datos adopta una forma de estrella para facilitar la extracción y el análisis de datos.
A veces estandarización y eficiencia son contradictorias. Generalmente, sacrificaremos espacio (normalización) para lograr un buen rendimiento. Lo más rápido es almacenar tanta información dimensional como sea posible en una "mesa grande". Generalmente se adopta una estrategia de compromiso dependiendo de la situación.
Las estrellas a veces causan mucha redundancia de datos y es muy probable que la tabla de hechos se vuelva extremadamente inflada (millones de datos × cientos de dimensiones).
Cada vez que es necesario actualizar un miembro de dimensión, también se debe actualizar la tabla de hechos.
Los tipos de copos de nieve a veces requieren actualizar solo una capa en una dimensión de copo de nieve sin cambiar la enorme tabla de hechos.
El análisis concreto de cuestiones específicas, como dimensiones temporales, años y estaciones, no requiere copos de nieve, sino que implica productos y clasificación de productos. Si la información clasificada también es la información que necesitamos analizar, entonces definitivamente crearé una tabla de búsqueda sobre clasificación, es decir, usaré el patrón de copo de nieve.
La estructura de copo de nieve es una estructura estandarizada que elimina datos redundantes del almacén de datos. Por ejemplo, hay una tabla de hechos de ventas, luego hay una tabla de dimensiones de producto unida a ella y luego hay una tabla de dimensiones de categoría de producto unida a la tabla de dimensiones de producto. Esta estructura es la estructura del copo de nieve. Además de la redundancia de datos, la estructura del copo de nieve también necesita estar conectada para generar algunas estadísticas, por lo que la eficiencia no es necesariamente tan alta como la de la estructura en estrella. La estandarización también es un proceso complejo, y el diseño de la estructura de la base de datos correspondiente, el ETL de datos y el mantenimiento posterior son relativamente complejos.
El esquema estrella es una estructura informal. Cada dimensión del cubo está conectada a la tabla de hechos y no hay dimensiones de gradiente, por lo que los datos son redundantes. Debido a la redundancia de datos, muchas consultas estadísticas no requieren conexiones externas, por lo que la eficiencia es generalmente mayor que la de Snowflake. La estructura en estrella no necesita considerar muchos factores de normalización y el diseño y la implementación son relativamente simples.
Aunque existen algunas diferencias entre ambas estructuras, personalmente creo que no hay ninguna mejor ni peor. Lo más importante es observar los requisitos del proyecto y la lógica empresarial.