Comprender el esquema de la base de datos de informes

Actualizado

Función beta. La base de datos de informes está actualmente en beta y puede seguir evolucionando. Esta función está disponible solo mediante incorporación voluntaria. Póngase en contacto con su persona de contacto en Azumuta para unirse a la beta y probarla.

Dónde residen sus datos

Todos los datos de su espacio de trabajo residen en un único esquema llamado company_<your-workspace-id>. Cada tabla en él corresponde a un concepto que ya conoce de Azumuta.

Las tablas principales

El conjunto exacto de tablas depende de lo que haya habilitado. Las más comunes son:

Table What it holds
workinstruction, workinstruction_version Sus instrucciones de trabajo y sus versiones publicadas.
instruction_step Los pasos individuales de una versión de la instrucción de trabajo.
instruction_visit, instruction_total_visit Cada vez que un operario realiza un paso, más totales por paso.
recording, recording_status Sesiones de ejecución (un operario ejecutando una instrucción) y su historial de estado.
issue Incidencias / tickets de mejora continua, con recuentos precomputados útiles.
issue_task, issue_comment, issue_attachment, issue_signature, issue_checklist Los elementos asociados a una incidencia.
issue_transition El historial de una incidencia al moverse entre columnas del tablero.
product_order, product_order_item, product_order_item_spot Órdenes de producción y sus elementos.
users, user_group, user_group_member Personas y grupos en su espacio de trabajo.

Convenciones utilizadas en todo el esquema

Una vez que conozca estas pocas reglas, todo el esquema se vuelve predecible:

  • Claves primarias. Cada tabla tiene una clave primaria de tipo texto (por ejemplo recording_id, issue_id) que coincide con el id del registro en Azumuta. Puede usarla para unir tablas relacionadas.
  • Eliminaciones lógicas. Las filas nunca se eliminan silenciosamente. Cuando algo se borra en Azumuta, su fila recibe en su lugar una marca temporal deleted_at. Para trabajar solo con datos actuales, añada where deleted_at is null a sus consultas.
  • Marcas temporales. Cada tabla incluye created_at y modified_at (y deleted_at). Todas las marcas temporales se almacenan en UTC.
  • Duraciones en milisegundos. Campos como actual_duration o rework_time se almacenan como milisegundos enteros. Divida entre 1000 para obtener segundos.
  • Campos flexibles usan JSON. Los datos que varían en estructura (como parameters o una answer de la instrucción) se almacenan como jsonb, que puede consultar con los operadores JSON de PostgreSQL.
  • Valores precomputados. Para evitar joins adicionales, algunas tablas incluyen recuentos y métricas ya preparados — por ejemplo issue.comment_count, issue.open_task_count o recording.rework_time.

El diccionario de datos integrado

A cada tabla y columna se le adjunta una descripción legible por humanos. La mayoría de clientes SQL y herramientas BI las muestran automáticamente. Por ejemplo, en psql:

\d+ "company_<your-workspace-id>".issue

También puede leerlas con una consulta:

select column_name, col_description(
    ('company_<your-workspace-id>.issue')::regclass,
    ordinal_position
) as description
from information_schema.columns
where table_schema = 'company_<your-workspace-id>'
  and table_name = 'issue'
order by ordinal_position;

Esto significa que rara vez tendrá que adivinar qué significa una columna: el esquema se documenta a sí mismo.

¿Listo para consultar? Vea Ejemplos de consultas analíticas.

En esta página
© Azumuta 2026