En la Parte 1 de esta serie, presentamos las relaciones entre conjuntos de datos múltiples de Amazon Quick Sight y cubrimos los conceptos fundamentales del modelado dimensional, las mejores prácticas para diseñar modelos de datos limpios y un marco de decisión sobre cuándo usar uniones en tiempo de ejecución versus conjuntos de datos preunidos. Si aún no ha leído la Parte 1, le recomendamos comenzar por ahí.
En esta publicación, pasamos de conceptos a patrones. Para cada esquema, encontrará una estructura de tabla, casos de uso, pasos de implementación y consultas SQL de muestra. También cubrimos soluciones alternativas para escenarios avanzados que requieren pasos de modelado adicionales y cerramos con un resumen de las limitaciones actuales.
Nota: Todas las relaciones de conjuntos de datos múltiples en la versión actual utilizan combinación interna. En los resultados de la consulta solo aparecen filas con claves coincidentes en ambos conjuntos de datos. Diseñe su modelo de datos en consecuencia.
Patrones admitidos
Los siguientes siete escenarios son compatibles de forma nativa con Quick Sight Multi-Dataset Relationships. Cada escenario se corresponde con un patrón de modelado de datos común, con orientación de implementación concreta y SQL de muestra.
Escenario 1: esquema de estrella simple
El patrón más común y recomendado. Un conjunto de datos de hechos centrales está relacionado con conjuntos de datos de múltiples dimensiones.
Tipo de tabla Cardinalidad Columnas clave Atributos/Medidas SALES_FACT Hecho alto: Millones a miles de millones de filas sale_id (PK) customer_id (FK) product_id (FK) time_id (FK) store_id (FK) cantidad costo de ingresos CUSTOMER_DIM Dimensión Media: Miles a millones de filas customer_id (PK) nombre, correo electrónico, ciudad, estado, país, segmento Dimensión PRODUCT_DIM Baja: Cientos a miles de filas product_id (PK) nombre_producto, categoría, marca, precio unitario TIME_DIM Dimensión Bajo time_id (PK) fecha, mes, trimestre, año, día_de_semana STORE_DIM Dimensión Bajo a Medio store_id (PK) nombre_tienda, región, administrador, pies cuadrados
Casos de uso
Ventas totales por segmento de clientes y región. Tendencia de ingresos mensuales por categoría de producto. Las 10 tiendas principales por valor promedio de pedido.
Implementación
Cree conjuntos de datos separados para cada tabla de hechos y dimensiones. Defina relaciones mediante claves coincidentes:
Todas las uniones son de un solo salto (hecho a dimensión), sin necesidad de encadenamiento. Las dimensiones desnormalizadas admiten operaciones rápidas GROUP BY sin uniones adicionales.
Consultas de muestra
Ventas totales por segmento de clientes y región:
Escenario 2: esquema de copo de nieve
Un esquema de copo de nieve extiende la estrella normalizando las tablas de dimensiones en cadenas. Por ejemplo, una dimensión de Cliente podría vincularse a una tabla Geografía, que a su vez se vincula a una tabla Región. Cada mesa se mantiene a su manera.
Las tablas de dimensiones están normalizadas en cadenas de varios niveles.
Tipo de tabla Columnas clave Atributos/Medidas SALES_FACT Hecho sale_id (PK) customer_id (FK) product_id (FK) time_id (FK) store_id (FK) cantidad ingresos CUSTOMER_DIM Dimensión customer_id (PK) geo_id (FK) segment_id (FK) nombre, correo electrónico GEOGRAFÍA Subdimensión geo_id (PK) ciudad, estado país SEGMENTO Subdimensión segment_id (PK) nombre_segmento PRODUCT_DIM Dimensión id_producto (PK) id_categoría (FK) id_marca (FK) nombre_producto precio_unidad CATEGORÍA Subdimensión id_categoría (PK) nombre_categoría MARCA Subdimensión id_marca (PK) nombre_marca TIME_DIM Dimensión id_tiempo (PK) id_trimestre (FK) fecha día_de_semana TRIMESTRE Subdimensión id_trimestre (PK) trimestre, año
Casos de uso
Desglose de ventas por jerarquía geográfica (país → estado → ciudad). Rendimiento del producto por marca y categoría de forma independiente.
Consideración clave
La unión de múltiples saltos (hecho → cliente → geografía) aumenta ligeramente la complejidad de la consulta. Una previamente las cadenas de copos de nieve en un conjunto de datos de una sola dimensión plana, a menos que la dimensión sea muy grande (>1 millón de filas) y la reducción del almacenamiento justifique el salto de unión agregado.
Consulta de muestra
Ventas por jerarquía geográfica:
Escenario 3: Esquema de galaxia/constelación (multihecho con dimensiones compartidas/conformadas)
Varias tablas de hechos comparten tablas de dimensiones comunes (conformadas). Esto admite análisis entre procesos. Por ejemplo, puede comparar ventas y devoluciones utilizando dimensiones compartidas de productos y clientes.
Varias tablas de hechos comparten dimensiones conformadas comunes.
Tipo de tabla Columnas clave Atributos/Medidas SALES_FACT Hecho sale_id (PK) producto_id (FK) cliente_id (FK) promo_id (FK) canal_id (FK) cantidad, ingresos, costo RETURNS_FACT Hecho return_id (PK) producto_id (FK) cliente_id (FK) motivo_id (FK) estado_id (FK) monto_reembolso PRODUCT_DIM Compartido Dim product_id (PK) nombre_producto, categoría marca, precio unitario CUSTOMER_DIM Shared Dim customer_id (PK) nombre, correo electrónico ciudad, estado PROMOTION_DIM Promo_id (PK) solo ventas promo_name, descuento_pct CHANNEL_DIM Channel_id (PK) solo ventas nombre_canal, tipo de canal REASON_DIM Solo devoluciones Reason_id (PK) Reason_desc, Reason_category STATUS_DIM Solo devuelve status_id (PK) status_name, is_final
Casos de uso
Tasa de devolución por producto (Devoluciones totales / Ventas totales). Comparación período tras período de rentabilidad versus ventas. Análisis entre procesos: ¿qué promociones generan más retornos?
Consideración clave
Las dimensiones conformes deben utilizar grano y claves idénticas en ambas tablas de hechos. La consulta entre hechos utiliza dimensiones compartidas como "puente" para la unión.
Consulta de muestra
¿Qué promociones generan más retornos?
Escenario 4: Dimensiones del juego de roles
La misma tabla de hechos hace referencia a una tabla de una sola dimensión (por ejemplo, Fecha) varias veces, cada vez en una función analítica diferente. En Quick Sight, cree tres conjuntos de datos separados, todos basados en la misma tabla de origen DATE_DIM subyacente.
Una única dimensión de fecha cumple múltiples funciones analíticas.
Tipo de tabla Columnas clave Atributos ORDERS_FACT Hecho order_id (PK) order_date_id (FK) ship_date_id (FK) delivery_date_id (FK) customer_id (FK) product_id (FK) cantidad ingresos DATE_DIM Juego de roles Dim (1 tabla física) date_id (PK) fecha mes, trimestre, año día_de_semana is_weekend, is_holiday CUSTOMER_DIM Dimensión customer_id (PK) nombre, correo electrónico ciudad, estado, segmento PRODUCT_DIM Dimensión product_id (PK) product_name categoría, marca
Casos de uso
Demanda estacional: pedidos realizados en diciembre frente a artículos entregados en enero. Días promedio entre pedido y envío (análisis de retraso del envío). Rendimiento de entrega por mes: ¿cuántos pedidos se entregaron a tiempo?
Implementación
Cree una tabla física: DATE_DIM con todos los atributos de fecha. En la tabla de hechos, agregue un FK por rol:
En Quick Sight, cree tres conjuntos de datos separados para las funciones de la dimensión de fecha, todos basados en la misma tabla de origen subyacente Date_Dim. Nota: En SQL, el motor utiliza alias de tabla en JOIN para diferenciar cada función. No duplique la tabla física en la fuente de datos subyacente.
La asignación de roles se define en la siguiente tabla.
FK en la tabla de hechos Rol/Alias Pregunta comercial order_date_id OrderDate ¿Cuándo se realizó el pedido? ship_date_id Fecha de envío ¿Cuándo se envió? delivery_date_id Fecha de entrega ¿Cuándo se entregó?
Consulta de muestra
Retraso promedio del barco por categoría de producto:
Escenario 5: Multihecho con diferente grano
Dos o más tablas de hechos con diferentes niveles de detalle (grano) comparten tablas de dimensiones comunes. Las uniones en tiempo de ejecución de Quick Sight Multi-Dataset agregan automáticamente los datos más finos hasta los más gruesos antes de unirse. Esto elimina la necesidad de realizar una agregación previa manual en canalizaciones de extracción, transformación y carga (ETL).
Las ventas diarias y los pronósticos mensuales comparten dimensiones en diferentes niveles de grano.
Tipo de tabla/grano Columnas clave Atributos/Medidas DAILY_SALES_FACT Grano de hecho: 1 fila por tienda/producto/día ID de venta (PK) ID de tienda (FK) ID de producto (FK) fecha_venta cantidad ingresos MONTHLY_FORECAST_FACT Grano de hecho: 1 fila por tienda/producto/mes ID_pronóstico (PK) ID_tienda (FK) ID_producto (FK) mes_pronóstico Forecast_revenue Forecast_quantity STORE_DIM Shared Dim store_id (PK) nombre_tienda, administrador de región, pies cuadrados PRODUCT_DIM Shared Dim product_id (PK) nombre_producto categoría, marca precio unitario
Consulta de muestra
Real versus pronóstico por tienda (mensual):
Escenario 6: programas de actualización independientes
Los escenarios anteriores demuestran cómo se asignan diferentes patrones de esquema a relaciones de conjuntos de datos múltiples. Los siguientes dos escenarios cambian el enfoque de la estructura de modelado de datos a las capacidades operativas de la arquitectura de múltiples conjuntos de datos: programas de actualización independientes y seguridad a nivel de fila en tiempo de ejecución.
Debido a que cada conjunto de datos en un tema de conjuntos de datos múltiples es una entidad independiente, los conjuntos de datos se pueden actualizar en cronogramas separados adaptados a la volatilidad de sus datos. Las tablas de hechos de alta velocidad pueden actualizarse cada hora y las dimensiones que cambian lentamente pueden actualizarse diariamente o semanalmente.
Tipo de conjunto de datos Cadencia sugerida Ejemplo Datos de transacción (pedidos, clics) Cada hora ORDERS_FACT, PAGEVIEWS_FACT Datos agregados/resumidos Diario DAILY_SALES_SUMMARY Tablas de dimensiones Semanal o en cambios CUSTOMER_DIM, PRODUCT_DIM Tablas de referencia/búsqueda Mensual o ad-hoc REGION_DIM, CATEGORY_DIM Configure cada conjunto de datos con su propio programa de actualización SPICE de forma independiente. Utilice la actualización incremental en las tablas de hechos cuando sea compatible para minimizar los costos de SPICE. Monitoree la capacidad de SPICE por separado por conjunto de datos. Cada actualización es un trabajo de ingesta independiente.
Escenario 7: seguridad a nivel de fila en tiempo de ejecución
Las relaciones de conjuntos de datos múltiples aplican reglas de seguridad a nivel de fila (RLS) durante las uniones en tiempo de ejecución. Las políticas RLS de cada conjunto de datos se respetan de forma independiente, por lo que los usuarios solo ven los datos a los que están autorizados a acceder, incluso cuando las consultas abarcan varios conjuntos de datos. Esta es una ventaja clave sobre los conjuntos de datos compuestos, que no pueden imponer el RLS del conjunto de datos principal.
Casos de uso
Los gerentes de ventas regionales solo ven los datos de su región cuando realizan consultas sobre hechos y dimensiones. Control de acceso a nivel de departamento en tablas de dimensiones compartidas (por ejemplo, datos de RR.HH. visibles solo para RR.HH.). Análisis multiinquilino donde cada cliente ve solo sus propios registros en todos los conjuntos de datos. Escenarios de cumplimiento que requieren un estricto aislamiento de datos entre unidades de negocio.
Implementación
Defina reglas RLS en cada conjunto de datos de forma independiente (por ejemplo, filtrar SALES_FACT por región, filtrar CUSTOMER_DIM por segmento). En el momento de la consulta, el motor de unión en tiempo de ejecución aplica el RLS de cada conjunto de datos antes de realizar la unión. Los usuarios que realizan consultas en conjuntos de datos reciben solo la intersección de filas que pueden ver en cada tabla. No se necesita configuración adicional a nivel de tema. RLS se propaga automáticamente desde cada conjunto de datos.
RLS se aplica antes de la unión, no después. Esto significa que los usuarios ven la intersección de sus filas permitidas de cada conjunto de datos, que es un modelo más estricto y seguro que el filtrado posterior a la unión.
Compatible con soluciones alternativas
Los siguientes patrones no son compatibles de forma nativa, pero se pueden abordar con soluciones alternativas de modelado de datos aplicadas en la capa de preparación del conjunto de datos.
Uniones circulares/bucle → romper el ciclo
Existe una relación circular cuando dos caminos conducen desde el mismo hecho a la misma dimensión (por ejemplo, Pedido → Sucursal Y Pedido → Personal de ventas → Sucursal). No se admiten relaciones circulares. La solución es quitar una pierna y desnormalizar el camino redundante.
Un ciclo de unión triangular que debe romperse para evitar ambigüedades.
Problema (no compatible de fábrica)
Pedido → Sucursal (FK directo) Y Pedido → Personal de ventas → Sucursal (ruta indirecta a través del Personal). Esto crea un bucle triangular. Si su modelo crea un ciclo (A → B → C → A), debe romperlo antes de definir relaciones en el Tema. Quick Sight rechazará las definiciones de relaciones que formen un bucle.
Solución
Retire una pierna del círculo. Determine la ruta analítica principal y preserve esa relación. Elimine la relación Personal de ventas → Sucursal de la definición del tema. Opcionalmente, desnormalice los atributos clave de la dimensión eliminada en el conjunto de datos de hechos. Relaciones restantes (sin ciclo): ORDER_FACT.branch_id → BRANCH_DIM y ORDER_FACT.staff_id → SALES_STAFF_DIM.
Se aplica la nueva estructura de tabla después de aplicar la solución.
Tipo de tabla Columnas clave Atributos/Medidas ORDER_FACT Hecho order_id (PK) Branch_id (FK) staff_id (FK)
nombre_rama (desnormalizado)
cantidad
BRANCH_DIM Dimensión Branch_id (PK)
nombre_sucursal
región
SALES_STAFF_DIM Dimensión (¡sin sucursal_id!) staff_id (PK)
nombre_del_personal
fecha_contratación
Desempeño del personal por sucursal (después del arreglo)
Jerarquías recursivas → aplanar
Una tabla de empleados con una columna MANAGER_ID que hace referencia a la misma tabla (organigrama). Las autouniones no se admiten en todos los conjuntos de datos.
Solución 1: dimensión de administrador independiente
Cree una copia de la tabla de empleados como un conjunto de datos de dimensión "Administrador". Bueno para jerarquía de un solo nivel (empleado → gerente directo solamente).
Solución 2: tabla de jerarquía aplanada (recomendada)
Calcule previamente una vista de jerarquía aplanada con columnas de nivel explícitas (Nivel1_VP, Nivel2_Director, Nivel3_Manager, Empleado). Importe como un único conjunto de datos Quick Sight.
Jerarquías irregulares → rellenar/repetir valores principales
Jerarquía geográfica donde algunos países tienen estados y ciudades, pero otros van directamente de país a ciudad. Los niveles faltantes provocan lagunas en los desgloses.
Solución
En la capa ETL/conjunto de datos, rellene los niveles faltantes repitiendo el valor principal para que cada ruta tenga una profundidad uniforme:
País Estado Ciudad Nota EE.UU. California San Francisco Profundidad normal Singapur Singapur Singapur Estado = Ciudad = País (relleno) Reino Unido Inglaterra Londres Profundidad normal
Jerarquías divididas/paralelas → dimensiones múltiples
Cuando una entidad pertenece a dos o más jerarquías independientes simultáneamente (por ejemplo, un Producto tiene una jerarquía de Marca y una jerarquía de Categoría), modele cada una como una dimensión separada conectada a la tabla de hechos de forma independiente.
La marca y la categoría existen como jerarquías de dimensiones independientes.
Problema
Un producto pertenece tanto a una jerarquía de Marca (Nike Inc. > Nike > Air Max) como a una jerarquía de Categoría (Calzado > Running > Carretera). Estas jerarquías son independientes. Combinarlos en una dimensión crea una falsa dependencia.
Solución
Cree tablas de dimensiones independientes para cada ruta de jerarquía. Relacione ambas dimensiones con el hecho de forma independiente:
Los usuarios pueden dividir por marca o categoría de forma independiente y sin interferencias.
Consulta de muestra
Análisis cruzado: matriz Marca x Categoría
Limitaciones actuales
Aunque las soluciones anteriores abordan muchas necesidades de modelado avanzado, existen limitaciones en la versión actual que no se pueden resolver únicamente mediante el modelado de datos.
Limitación Descripción Impacto Solo unión interna Solo se admite unión interna. Se excluyen las filas sin claves coincidentes. No se pueden analizar registros no coincidentes. No hay uniones circulares. El gráfico de relaciones debe ser acíclico (DAG). Debe romper los ciclos mediante la desnormalización. No hay uniones externas. Las uniones externas izquierda, derecha y completa no están disponibles. Limita las consultas "todas las X, incluidas aquellas sin Y". Sin relaciones consigo mismo. Un conjunto de datos no puede relacionarse consigo mismo. Las jerarquías recursivas deben aplanarse. Sin combinación SPICE + DQ. Todos los conjuntos de datos de un tema deben utilizar el mismo modo de consulta (SPICE o consulta directa). Elija un modo por tema Límite de conjunto de datos de 12 El tema no puede exceder los 12 conjuntos de datos. Es posible que los copos de nieve grandes necesiten consolidación. Fuentes de DQ limitadas. Direct Query solo admite Amazon Redshift, Amazon Athena, Amazon S3 Tables, Snowflake y Databricks. Otras fuentes deben utilizar relaciones SPICE JSON únicamente. Las claves compuestas requieren carga JSON (no UI). Paso adicional para claves de varias columnas
Conclusión
Las uniones en tiempo de ejecución de múltiples conjuntos de datos mueven Quick Sight de "aplanar todo primero" a "modelar una vez, combinar en el momento de la consulta". Mantenga cada tabla como un conjunto de datos, declare relaciones en un tema y permita que Quick Sight ensamble uniones internas a pedido en elementos visuales, cálculos, filtros y chat.
Se admiten directamente esquemas de estrella y copo de nieve, análisis de múltiples hechos de una sola dimensión y dimensiones de juego de roles. Se puede acceder a bucles, jerarquías profundas de muchos a muchos y retención de uniones externas a través de tablas puente, aplanamiento, adaptación a una columna vertebral y uniones prediseñadas. Un pequeño número de casos permanecen fuera del alcance por ahora: ciclos verdaderos y semántica de unión externa completa.
Comience modelando un hecho y sus dimensiones, enriquezca los metadatos del tema, valide con Chat y haga crecer el modelo hacia afuera. El mismo conjunto de conjuntos de datos relacionados responderá muchas más preguntas que cualquier conjunto de datos aplanado.
Sobre los autores
Ying Wang
Ying es un arquitecto senior de soluciones especializado a nivel mundial en la organización de IA generativa de AWS. Aporta 17 años de experiencia en análisis y ciencia de datos, con una sólida formación como arquitecta de datos y gerente de ingeniería de desarrollo de software.
Emily Zhu
Emily es gerente senior de productos en Amazon Quick, responsable de toda la pila de datos estructurados, que abarca la arquitectura de datos gobernados y de escala empresarial, motores de consulta analíticos y conversacionales de alto rendimiento, y la capa semántica y ontológica que brinda a los datos un significado real a escala. Le apasiona cómo una estrategia de datos sólida desbloquea la estrategia de IA y tiene la misión de hacer que la pila de datos estructurados sea la base para experiencias conversacionales y analíticas en Quick Suite.
Salim Khan
Salim es arquitecto de soluciones especializado para Amazon Quick Sight. Salim tiene más de 16 años de experiencia en la implementación de soluciones de inteligencia empresarial (BI) empresarial. Antes de AWS, Salim trabajó como consultor de BI para sectores verticales como automoción, atención sanitaria, entretenimiento, consumo, publicaciones y servicios financieros. Ha brindado soluciones de inteligencia empresarial, almacenamiento de datos, integración de datos y gestión de datos maestros en todas las empresas.
Neeraj Kumar
Neeraj es arquitecto sénior de soluciones mundiales en AWS, donde diseña soluciones de inteligencia empresarial a escala empresarial que transforman la forma en que las organizaciones aprovechan sus datos. Con más de dos décadas de experiencia en datos y análisis, Neeraj ha impulsado la transformación digital en los sectores de la automoción, la fabricación y las telecomunicaciones. En la actualidad, guía a organizaciones globales para desbloquear conocimientos innovadores utilizando Amazon Quick Sight y se centra en ampliar los límites de los análisis basados en IA con Amazon Q en QuickSight, ayudando apasionadamente a los clientes a modernizar su panorama de BI y acelerar su viaje para convertirse en empresas verdaderamente basadas en datos.
Srikanth Baheti
Srikanth es gerente sénior de Amazon Quick Sight. Comenzó su carrera como consultor y trabajó para múltiples organizaciones privadas y gubernamentales. Posteriormente trabajó para PerkinElmer Health and Sciences & eResearch Technology Inc, donde fue responsable del diseño y desarrollo de aplicaciones web de alto tráfico y canales de datos altamente escalables y mantenibles para plataformas de informes que utilizan servicios de AWS y computación sin servidor.