Escribir consultas SQL

Escriba consultas PostgreSQL optimizadas para las visualizaciones de Dashboard Studio. Aprenda patrones de acceso a los datos, selección de capa y buenas prácticas de rendimiento

Dashboard Studio usa SQL para recuperar datos de los esquemas de IoT Query. Usted escribe SQL en dos contextos: los editores de panel, donde las instrucciones alimentan las visualizaciones, y el Editor de SQL independiente para la exploración de datos. Esta página explica cómo escribir SQL eficaz para ambos contextos, con énfasis en los requisitos de visualización, ya que tienen restricciones estructurales específicas.

Dónde se usa SQL

Dashboard Studio ofrece dos entornos de SQL para distintos propósitos. Entender cuándo usar cada uno le ayuda a trabajar con más eficiencia.

Consultas de visualización alimentan paneles individuales en los reportes. Usted escribe estas instrucciones en la pestaña de Consulta SQL del editor del panel. Consulta SQL pestaña. Cada panel ejecuta una instrucción que debe devolver datos con una estructura específica que coincida con el tipo de visualización. Estas instrucciones se ejecutan cuando los reportes cargan o se actualizan, por lo que el rendimiento importa para la experiencia del usuario. El SQL de visualización no puede modificar datos; todas las instrucciones se ejecutan como operaciones SELECT de solo lectura contra los esquemas de IoT Query.

Reportes Los reportes usan el mismo enfoque de SQL de visualización que los paneles del dashboard. Un reporte ejecuta una consulta que alimenta tres vistas al mismo tiempo: la tabla de datos, el gráfico y el mapa de ubicación. La instrucción debe devolver todas las columnas necesarias en los tres componentes, así que incluya juntas las columnas de coordenadas, tiempo y métricas en un solo SELECT.

Editor de SQL admite la exploración y exportación de datos. Acceda al Editor SQL desde la barra lateral izquierda, en Herramientas. Escriba cualquier instrucción SELECT para examinar la estructura de los datos, validar supuestos o exportar los resultados como CSV. El Editor SQL muestra tablas completas de resultados con ordenamiento de columnas y proporciona métricas de ejecución. Use esto para probar la lógica antes de agregar SQL a los paneles de visualización, o para extracción de datos ad hoc que no necesita visualización.

La diferencia clave: el SQL de visualización debe coincidir con estructuras exactas de columnas, mientras que las instrucciones del Editor SQL pueden devolver cualquier formato de resultado. Pruebe primero la lógica compleja en el Editor SQL y luego adáptela para visualizaciones.

Cómo escribir SQL para visualizaciones

El SQL de visualización debe devolver cantidades específicas de columnas y tipos de datos. Dashboard Studio no puede renderizar un gráfico de barras a partir de tres columnas ni una tarjeta de estadísticas a partir de datos de texto. Consulte la sección Requisitos del conjunto de datos en la pestaña Consulta SQL para ver exactamente qué espera la visualización que eligió antes de escribir la instrucción. La tabla siguiente contiene los tipos de visualización admitidos:

Visualización	Requisito de consulta	Ejemplo
Tarjeta de estadísticas	Un solo valor numérico	SELECT COUNT(*) FROM schema.table
Gráfico de barras	Dos columnas: categoría, valor	SELECT column1, COUNT(*) FROM schema.table Grupo BY column1
Gráfico circular	Dos columnas: etiqueta, valor	SELECT category, SUM(value) FROM schema.table GROUP BY category
Tabla	Cualquier columna	SELECT column1, column2, column3 FROM schema.table
Texto	No se requiere consulta	Markdown, HTML o texto sin formato
Mapas	Columnas de latitud y longitud	SELECT latitude, longitude FROM schema.table

Tarjetas de estadísticas

Las tarjetas de estadísticas muestran valores numéricos únicos. Las sentencias deben devolver exactamente una fila con una columna numérica:

Viajes totales en el mes actual

SELECT COUNT(*) as value
FROM processed_common_data.Viajes
WHERE trip_start_time >= DATE_TRUNC('month', CURRENT_DATE);

Distancia total recorrida (km)

SELECT ROUND(SUM(trip_distance_meters) / 1000.0, 1) as valor
FROM processed_common_data.Viajes
WHERE trip_start_time >= CURRENT_DATE - INTERVAL '7 days';

El nombre de la columna no importa; solo que el resultado sea un único valor numérico. Dashboard Studio muestra este valor con el formato que configure en Configuración de visualización.

Gráficos de barras

Los gráficos de barras requieren exactamente dos columnas: categoría (texto o fecha) y valor (numérico). La primera columna se convierte en el eje X, la segunda en la altura de las barras:

Viajes por objeto

CON device_owner AS (
  SELECT DISTINCT ON (o.device_id) o.device_id, o.object_label
  FROM raw_business_data.objects o
  WHERE o.is_deleted IS NOT TRUE
  ORDENAR POR o.device_id, o.object_id
)
SELECT 
  d.object_label como categoría,
  COUNT(*) as value
DESDE processed_common_data.Viajes t
LEFT JOIN device_owner d ON d.device_id = t.device_id
DONDE t.trip_start_time >= DATE_TRUNC('month', CURRENT_DATE)
Grupo por d.object_label
ORDER BY value DESC;

Agrupe por una columna de texto. datos_crudos_de_negocio.Gestión de vehículos.tipo_de_vehículo contiene un código entero en lugar de un nombre, por lo que agrupar por él etiqueta las barras 1, 2, 3.

El propietario_del_dispositivo el bloque de la parte superior no es opcional cada vez que una etiquetas de Objeto con Viajes o eventos. Véase Cómo unir etiquetas de Objeto.

Conteos diarios de Recorrido

SELECT 
  DATE_TRUNC('day', trip_start_time)::date as category,
  COUNT(*) as value
FROM processed_common_data.Viajes
WHERE Recorrido_start_time >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY DATE_TRUNC('day', trip_start_time)
ORDER BY category;

Usar ORDER BY para controlar la secuencia de barras. Ordene por valor para comparaciones jerarquizadas o por categoría para progresiones de series temporales.

Gráficos de pastel

Los gráficos de pastel requieren exactamente dos columnas: etiqueta (texto) y valor (numérico). La primera columna se convierte en etiquetas de las porciones, la segunda determina el tamaño de las porciones:

Viajes por zona de inicio

SELECT 
  start_zone como etiqueta,
  COUNT(*) as value
FROM processed_common_data.Viajes
WHERE trip_start_time >= DATE_TRUNC('month', CURRENT_DATE)
  AND start_zone IS NOT NULL
Grupo por start_zone
ORDER BY value DESC
LIMIT 10;

Agregue cláusulas LIMIT para categorías con muchos valores. Los gráficos circulares con 20 o más segmentos se vuelven ilegibles; lítelos a las 10-15 categorías principales.

Tablas

Las tablas admiten cualquier cantidad de columnas con cualquier tipo de datos. Seleccione las columnas que desea mostrar:

Detalles recientes del recorrido

SELECT 
  device_id,
  hora de inicio del recorrido,
  Recorrido_end_time,
  REDONDEAR(recorrido_distance_meters / 1000.0, 1) como distance_km,
  ROUND(trip_duration_seconds / 60.0) as duration_minutes,
  max_speed
FROM processed_common_data.Viajes
WHERE trip_start_time >= CURRENT_DATE - INTERVAL '7 días'
ORDER BY trip_start_time DESC
LIMIT 100;

Los nombres de columna se convierten en encabezados de tabla. Use alias con espacios para encabezados legibles: ROUND(trip_distance_meters / 1000.0, 1) as "Distancia (km)".

Paneles de texto

Los paneles de texto muestran contenido de Markdown, HTML o texto sin formato. No ejecutan una consulta SQL.

En el Contenido pestaña, seleccione una opción debajo de Modo de contenido:

• Markdown (predeterminado) admite formato como encabezados y enlaces.

• HTML representa el marcado sin procesar.

• Texto sin formato muestra el contenido exactamente como lo ingresó y no interpreta ningún marcado.

Utilice paneles de texto para los encabezados de sección, las instrucciones o el contexto junto con sus visualizaciones de datos.

Mapas

Los paneles de mapa trazan un marcador por fila. Las sentencias deben devolver una columna de latitud y una columna de longitud:

Últimas posiciones de los vehículos

CON device_owner AS (
  SELECT DISTINCT ON (o.device_id) o.device_id, o.object_label
  FROM raw_business_data.objects o
  WHERE o.is_deleted IS NOT TRUE
  ORDENAR POR o.device_id, o.object_id
)
SELECT DISTINCT ON (t.device_id)
  d.etiqueta_de_Objeto,
  t.latitude / 1e7 AS latitude,
  t.longitude / 1e7 AS longitude
FROM raw_telematics_data.tracking_data_core t
LEFT JOIN device_owner d ON d.device_id = t.device_id
WHERE t.device_time >= NOW() - INTERVAL '24 hours'
  AND t.latitude <> 0 AND t.longitude <> 0
ORDER BY t.device_id, t.device_time DESC;

DISTINCT ON con el correspondiente ORDER BY mantiene una fila por dispositivo, la más reciente. Sin él, la consulta traza todos los puntos históricos que el dispositivo haya enviado alguna vez.

Dashboard Studio detecta automáticamente las columnas de coordenadas cuando usan nombres comunes como latitud, latitud, o gps_lat para latitud y longitud, lon, o lng para longitud. Si sus columnas usan nombres diferentes, selecciónelas manualmente en Configuración de visualización.

Las coordenadas deben estar en grados decimales. Cuando una tabla las almacena como enteros escalados, divida por 1e7 como se muestra arriba. Cualquier otra columna que devuelva la instrucción aparecerá en la ventana emergente del marcador.

Las consultas de reportes siguen las mismas reglas estructurales que las consultas de visualización en los paneles del dashboard. Debido a que una sola instrucción impulsa juntos la tabla de datos, el gráfico y el mapa de ubicación, es posible que necesite combinar columnas que en un dashboard se escribirían como consultas separadas de panel. Por ejemplo, una consulta de panel de gráfico de barras que devuelve dos columnas no es suficiente para un reporte que además necesita coordenadas GPS para el mapa de ubicación. Incluya todas las columnas requeridas para cada componente en una sola instrucción. La lógica central de filtrado y JOIN sigue siendo la misma que en las consultas de panel; solo la cláusula SELECT debe ser más amplia.

Cómo escribir SQL para reportes

Un reporte ejecuta una consulta SQL que impulsa tres componentes simultáneamente: la tabla de datos, el gráfico y el mapa de ubicación. A diferencia de los paneles del dashboard, donde cada panel tiene su propia consulta enfocada, una consulta de reporte debe devolver todas las columnas necesarias para cada componente en una sola instrucción SELECT.

Requisitos de columnas por componente

Cada componente del reporte tiene requisitos de columnas específicos. Su consulta debe satisfacer todos los componentes que haya activado.

Componente	Columnas requeridas	Notas
Tabla de datos	Cualquier columna	Todas las columnas devueltas aparecen como columnas de la tabla
Gráfico	Al menos una columna de tiempo o de categoría, al menos una columna numérica	Las columnas de los ejes se seleccionan en la configuración del gráfico
Mapa de ubicación	Latitud y longitud en grados decimales	Dashboard Studio detecta automáticamente las columnas de coordenadas

Como la tabla de datos acepta cualquier columna, no impone restricciones adicionales. El gráfico y el mapa de ubicación determinan la mayoría de las decisiones estructurales.

Combinar componentes en una sola consulta

Una consulta que devuelve solo las columnas necesarias para un gráfico (dos columnas: categoría y valor) no puede alimentar también un mapa de ubicación. Debe incluir todas las columnas requeridas juntas.

El siguiente ejemplo devuelve columnas para los tres componentes: una columna de tiempo y una columna numérica para el gráfico, columnas de coordenadas para el mapa de ubicación y atributos adicionales que aparecen en la tabla de datos.

CON device_owner AS (
  SELECT DISTINCT ON (o.device_id) o.device_id, o.object_label
  FROM raw_business_data.objects o
  WHERE o.is_deleted IS NOT TRUE
  ORDENAR POR o.device_id, o.object_id
)
SELECT
    t.device_id,
    d.etiqueta_de_Objeto,
    t.device_time,
    t.latitude::float / 10000000 AS latitude,
    t.longitude::float / 10000000 AS longitude,
    t.speed::float / 100 AS speed
FROM raw_telematics_data.tracking_data_core t
LEFT JOIN device_owner d ON d.device_id = t.device_id
WHERE t.device_time >= NOW() - INTERVAL '24 hours'
ORDER BY t.device_time DESC
LIMIT 1000

En esta consulta, device_time y velocidad sirva para el gráfico, latitud y longitud sirva para el mapa de ubicación, y todas las columnas aparezcan en la tabla de datos.

Las tablas telemáticas en bruto almacenan coordenadas y velocidad como enteros escalados. Las coordenadas se dividen entre 10,000,000 (10⁷) para convertirlas a grados decimales, y la velocidad se divide entre 100 (10²) para convertirla a km/h. Aplique estas conversiones en cualquier consulta que lea de raw_telematics_data tablas.

Adaptar consultas de panel de dashboard para Reportes

Cualquier consulta de panel de un dashboard es un punto de partida válido para un reporte. El ajuste necesario depende de qué componentes quiera activar.

Si la consulta del panel ya es una visualización de tabla que devuelve varias columnas, es posible que ya incluya todo lo necesario. Agregue columnas de coordenadas si se requiere el mapa de ubicación.

Si la consulta del panel es un gráfico de barras o una consulta de tarjeta de estadísticas que devuelve resultados agregados, probablemente carece del detalle a nivel de fila necesario para la tabla de datos y el mapa de ubicación. En ese caso, elimine la agregación y trabaje en su lugar con las tablas subyacentes de la capa de Datos brutos o de la capa de transformación.

Libro de recetas SQL contiene ejemplos de consultas listos para usar para análisis comunes de la flota. Las recetas del libro se pueden adaptar para reportes agregando columnas de coordenadas donde se necesite el mapa de ubicación. La lógica principal de WHERE y JOIN se transfiere directamente; ajuste solo la cláusula SELECT para cubrir todos los componentes requeridos.

Cómo usar variables globales

Las variables globales proporcionan valores reutilizables en múltiples instrucciones SQL. Defina las variables en Ajustes > Configuración > Variables globales, luego haga referencia a ellas usando ${variable_name} la sintaxis.

Defina variables para valores que cambian periódicamente pero permanecen consistentes en varios paneles: rangos de fechas de análisis, filtros por tipo de vehículo o valores umbral. Cuando esos valores cambien, actualice la definición de la variable una sola vez en lugar de editar instrucciones SQL individuales.

Uso de variables de rango de fechas

SELECT 
  DATE_TRUNC('day', trip_start_time)::date as category,
  COUNT(*) as value
FROM processed_common_data.Viajes
WHERE recorrido_start_time >= '${analysis_start_date}'::date
  AND trip_start_time < '${analysis_end_date}'::date
GROUP BY DATE_TRUNC('day', trip_start_time)
ORDER BY category;

Las variables almacenan valores de texto. Conviértalas a los tipos apropiados en SQL: '${variable_name}'::date para fechas, '${variable_name}'::integer para números.

Para parámetros específicos de la instrucción que cambian con frecuencia, puede usar bloques de parámetros CTE al inicio:

WITH params AS (
  SELECT 
    300 como min_idle_seconds,
    10 como max_idle_speed_kmh,
    '${analysis_start_date}'::date as date_from,
    '${analysis_end_date}'::date as date_to
)

SELECT 
  e.device_id,
  COUNT(*) as idle_count,
  ROUND(SUM(e.duration_sec) / 60.0) as total_idle_minutes
FROM processed_common_data.rule_based_Conductor_events e
CROSS JOIN params p
WHERE e.event_type = 'idling_soft'
  AND e.device_time >= p.date_from
  AND e.device_time < p.date_to
  AND e.speed_kmh <= p.max_idle_speed_kmh
  AND e.duration_sec >= p.min_idle_seconds
AGRUPAR POR e.device_id
ORDER BY total_idle_minutes DESC;

Este patrón combina variables globales (rangos de fechas) con parámetros específicos de la sentencia (umbrales), manteniendo todos los valores ajustables en la parte superior para facilitar el Mantenimiento.

Cómo unir etiquetas de Objeto

raw_business_data.objects.device_id No es único. Un dispositivo puede llevar varios registros de Objeto, porque un dispositivo reasignado entre objetos deja atrás las filas anteriores. Tablas de hechos como processed_common_data.viajes encender device_id por sí sola, así que una unión simple a objetos multiplica cada fila de hechos por el número de registros de objeto coincidentes. Luego, los conteos y las sumas resultan demasiado altos, sin ningún error que se lo indique.

Filtrado en is_deleted no es suficiente por sí solo, porque más de un registro puede pasar ese filtro. Primero elija una fila por dispositivo y luego haga la unión con ella:

La unión de la etiqueta de objeto

CON device_owner AS (
  SELECT DISTINCT ON (o.device_id) o.device_id, o.object_id, o.object_label
  FROM raw_business_data.objects o
  WHERE o.is_deleted IS NOT TRUE
  ORDENAR POR o.device_id, o.object_id
)
SELECT d.object_label, COUNT(*) AS Viajes
DESDE processed_common_data.Viajes t
LEFT JOIN device_owner d ON d.device_id = t.device_id
DONDE t.trip_start_time >= CURRENT_DATE - INTERVAL '30 days'
AGRUPAR POR d.object_label;

Usar LEFT JOIN en lugar de una unión interna, para que un dispositivo sin un registro de Objeto que sobreviva siga apareciendo en lugar de quedar excluido del resultado.

processed_common_data.rule_based_Conductor_events es la excepción. Ya contiene object_id y etiqueta de Objeto, y sus coordenadas están en grados, así que no necesita ni esta unión ni la /1e7 conversión.

Cómo acceder a los esquemas de IoT Query

IoT Query organiza los datos en las Capas de Datos brutos, Transformación y análisis. Las Capas de Datos brutos y Transformación contienen dos esquemas de PostgreSQL cada una, y usted referencia una tabla por el nombre de su esquema en lugar de por la capa. Elegir la capa correcta ahorra tiempo y mantiene SQL claro. Para obtener detalles completos de los esquemas, consulte el Visión general del esquema de IoT Query.

Capa de Datos brutos contiene lo que los dispositivos y la plataforma Navixy registraron, en dos esquemas. raw_telematics_data contiene datos de Seguimiento, entrada y estado: raw_telematics_data.Seguimiento_data_core almacena cada posición de GPS con marcas de tiempo, coordenadas y lecturas de sensores. datos_brutos_de_negocio contiene entidades de negocio como raw_business_data.objects, raw_business_data.Gestión de vehículos, y raw_business_data.zones. Utilice la capa de Datos brutos para análisis a nivel de punto, para valores brutos de sensores y para las etiquetas y atributos que vincule a los datos procesados.

Capa de transformación almacena entidades procesadas en dos esquemas. datos_comunes_procesados contiene las transformaciones que Navixy mantiene, que están disponibles sin configuración: Viajes, datos_de_sensores_por_hora, eventos del conductor basados en reglas, y input_change_events. datos_personalizados_procesados contiene las transformaciones que usted crea por su cuenta en Transformation Builder. Utilice la capa de transformación para la mayoría de las necesidades de visualización, porque proporciona estructuras listas para el análisis. Vea Transformaciones comunes para cada una de las columnas de la tabla.

Capa de insights ofrece métricas preagregadas y modelos dimensionales para analíticas complejas. Úselo para estadísticas de toda la flota o análisis multidimensional que de otro modo requerirían uniones complejas con las tablas de la capa de transformación.

Los nombres de las capas Bronze, Silver y Gold describen la arquitectura de medallón que siguen las capas. No son nombres de esquema, y silver.viajes no es una tabla que usted pueda consultar. Use los nombres de esquema anteriores.

Tablas de referencia que usan schema.table formato: processed_common_data.viajes, no solo Viajes. Incluya filtros de rango de fechas en las cláusulas WHERE para limitar los datos escaneados:

Filtre siempre por rangos de tiempo

SELECT device_id, COUNT(*) as trip_count
FROM processed_common_data.Viajes
WHERE Recorrido_start_time >= CURRENT_DATE - INTERVAL '30 days'
AGRUPAR POR device_id;

La mayoría de las sentencias SQL filtran por dispositivo, rango de tiempo o ambos. Agregue estos filtros al inicio de las cláusulas WHERE para reducir el volumen de datos procesados.

Unidades de medición en los resultados de la consulta

IoT Query almacena cada medición en una unidad fija, y Dashboard Studio muestra lo que devuelva la consulta. No convierte los valores al sistema de medición configurado en las Preferencias de la cuenta Navixy, como sí lo hace la app predefinida de Dashboards. Dos personas con Preferencias diferentes ven los mismos números en el mismo panel.

La unidad de cada columna se documenta en la Visión general del esquema de IoT Query, y muchas columnas lo nombran directamente. distancia del Recorrido en metros contiene metros, avg_speed y max_speed mantenga km/h y altitude_start y altitud_final Mantenga los metros sobre el nivel del mar. Verifique la columna antes de etiquetar un panel.

Convierta en la consulta cuando sus lectores trabajen con otras unidades, y nombre la unidad en el alias de la columna para que el panel se etiquete correctamente:

Devolver la distancia en millas en lugar de metros

SELECT device_id,
       ROUND(SUM(trip_distance_meters) / 1609.344, 1) as "Distancia (mi)"
FROM processed_common_data.Viajes
WHERE trip_start_time >= CURRENT_DATE - INTERVAL '7 días'
AGRUPAR POR device_id;

Divida los metros entre 1,609.344 para obtener millas, km/h entre 1.609344 para obtener mph y los metros entre 0.3048 para obtener pies.

Cómo usar el editor SQL

Acceda al Editor de SQL desde la barra lateral izquierda, en Herramientas. Úselo para tres propósitos principales: probar la lógica antes de agregarla a los paneles, explorar los esquemas de datos para entender las columnas disponibles y exportar datos que no necesitan visualización.

El editor SQL admite varias pestañas para diferentes sentencias. Escriba SQL en las pestañas, ejecútelo con el botón "Execute Query" y vea los resultados en la tabla de abajo. Los resultados muestran métricas de ejecución (tiempo de ejecución, filas devueltas) y admiten la ordenación de columnas para examinar rápidamente los datos.

Exporte los resultados como CSV usando el botón «Export CSV». Esto funciona para reportes ad hoc o para extracciones de datos para análisis externo. El editor de SQL no tiene límite de filas de resultados, a diferencia del SQL de visualización, que debería devolver conjuntos de datos específicos.

Pruebe el SQL de visualización en el SQL Editor antes de agregarlo a los paneles. Escriba la instrucción, verifique que devuelva las columnas y los tipos de datos esperados, luego cópiela a la pestaña SQL Query del editor del panel. Este flujo de trabajo detecta problemas estructurales antes de que configure los ajustes de visualización.

Patrón de exploración para datos nuevos:

-- 1. Examinar la estructura de la tabla
SELECT * FROM processed_common_data.trips LIMIT 10;

-- 2. Verifique la cobertura del rango de fechas
SELECT 
  MIN(trip_start_time) como el más temprano,
  MAX(hora_inicio_del_recorrido) como más_reciente,
  COUNT(*) como total_recorridos
DESDE processed_common_data.Viajes;

-- 3. Prueba de la lógica de filtrado
SELECT 
  device_id,
  hora de inicio del recorrido,
  distancia del Recorrido en metros
FROM processed_common_data.Viajes
WHERE trip_start_time >= '2024-01-01'
  AND device_id = 12345
ORDENAR POR trip_start_time;

-- 4. Adaptar para visualización (2 columnas para gráfico de barras)
SELECT 
  DATE_TRUNC('day', trip_start_time)::date as day,
  COUNT(*) as viajes
FROM processed_common_data.Viajes
WHERE trip_start_time >= '2024-01-01'
  AND device_id = 12345
GROUP BY DATE_TRUNC('day', trip_start_time)
ORDER BY day;

Patrones SQL comunes

La mayor parte del SQL de visualización sigue patrones similares. Copie estas estructuras y ajuste los filtros, las columnas y las agregaciones según sus necesidades específicas.

Conteos de series temporales para el seguimiento de tendencias

SELECT 
  DATE_TRUNC('hour', recorrido_start_time) as time_bucket,
  COUNT(*) as event_count
FROM processed_common_data.Viajes
WHERE trip_start_time >= CURRENT_DATE - INTERVAL '24 hours'
Grupo BY DATE_TRUNC('hour', trip_start_time)
ORDER BY time_bucket;

Clasificaciones de categorías para comparar grupos

SELECT 
  columna de categoría,
  COUNT(*) as count
FROM schema.table
WHERE filter_conditions
AGRUPAR POR category_column
ORDER BY count DESC
LIMIT 15;

Cálculos de métricas para estadísticas agregadas

SELECT 
  ROUND(SUM(recorrido_distance_meters) / 1000.0, 1) as total_distance_km,
  ROUND(AVG(trip_duration_seconds) / 60.0) as avg_duration_minutes,
  COUNT(*) as recorrido_count
FROM processed_common_data.Viajes
WHERE trip_start_time >= DATE_TRUNC('week', CURRENT_DATE);

Resúmenes filtrados con múltiples condiciones

SELECT 
  device_id,
  COUNT(*) as recorridos,
  ROUND(SUM(trip_distance_meters) / 1000.0, 1) as total_km
FROM processed_common_data.Viajes
WHERE trip_start_time >= '${period_start}'::date
  Y trip_start_time < '${period_end}'::date
  Y trip_distance_meters >= 5000
  Y trip_duration_seconds >= 600
Grupo POR device_id
HAVING COUNT(*) >= 5
ORDER BY total_km DESC;

Qué hacer cuando SQL falla

Las fallas de ejecución se dividen en tres categorías: discrepancias estructurales con los requisitos de visualización, errores de sintaxis SQL o filtros que no devuelven datos.

Desajustes en la estructura de las columnas

Ocurren cuando los resultados no coinciden con las expectativas de visualización. Si seleccionó un gráfico de barras pero su SQL devuelve tres columnas, Dashboard Studio no puede renderizarlo. Revise Requisitos del conjunto de datos en la pestaña SQL Query. El gráfico de barras necesita exactamente dos columnas (categoría, valor), así que ajuste su cláusula SELECT:

-- Incorrecto: tres columnas
SELECT device_id, trip_start_time, COUNT(*) FROM processed_common_data.trips GROUP BY device_id, trip_start_time;

-- Correcto: dos columnas
SELECT device_id, COUNT(*) as trips FROM processed_common_data.trips GROUP BY device_id;

Errores de sintaxis de SQL

Muestre mensajes de error específicos. Los problemas comunes incluyen prefijos de esquema faltantes (Viajes en lugar de processed_common_data.viajes), errores tipográficos en los nombres de columna o conversión incorrecta de fechas. Pruebe las sentencias en el Editor SQL para ver mensajes de error detallados con números de línea.

Resultados vacíos

A pesar de una ejecución exitosa, indique que los filtros excluyen todos los datos. Pruebe el SQL sin cláusulas WHERE en el editor de SQL para verificar que la tabla contiene datos; luego agregue filtros de manera incremental para identificar qué condición excluye los resultados esperados.

Problemas de rendimiento

Si las sentencias se ejecutan lentamente o agotan el tiempo, agregue filtros de rango de fechas a las cláusulas WHERE. Las operaciones que analizan tablas completas procesan millones de filas innecesariamente:

-- Lento: sin filtro de fecha
SELECT device_id, COUNT(*) FROM processed_common_data.trips GROUP BY device_id;

-- Rápido: filtro de rango de fechas
SELECT device_id, COUNT(*) 
FROM processed_common_data.Viajes 
WHERE Recorrido_start_time >= CURRENT_DATE - INTERVAL '30 days'
AGRUPAR POR device_id;

Para obtener orientación adicional sobre el rendimiento, consulte Cómo acceder a los esquemas de IoT Query para conocer las mejores prácticas sobre el filtrado y la selección de esquemas.

Dónde encontrar ejemplos de SQL

El Libro de recetas SQL proporciona ejemplos completos para análisis telemáticos comunes. Estas recetas demuestran patrones para el análisis de Recorrido, cálculos de visitas a zonas, detección de ralentí y métricas de Flota. Cada receta incluye la instrucción SQL completa, la explicación de la lógica y resultados de ejemplo.

Adapte ejemplos del libro de recetas para visualizaciones ajustando la cláusula SELECT para que coincida con los requisitos de la visualización. Una receta que devuelve registros de recorrido detallados puede convertirse en un gráfico de barras agregando GROUP BY y la agregación COUNT. Una sentencia que calcula métricas por vehículo puede convertirse en un mosaico de estadísticas agregando SUM en todos los vehículos.

Solo necesita:

1. Copie ejemplos de Libro de recetas al Editor de Dashboard Studio.

2. Pruebe con sus datos reales.

3. Verifique los resultados y luego modifique la cláusula SELECT para su visualización de destino.

La lógica principal de WHERE y JOIN permanece igual; usted ajusta solo la estructura de salida.

Para conocer los detalles del esquema, consulte el Visión general del esquema de IoT Query. Esta referencia explica las tablas disponibles, las definiciones de columnas y las relaciones entre las Capas de Datos brutos, Transformación e Insight.