Comprender el esquema de la base de datos de informes

Actualizado

Beta. La base de datos de informes está actualmente en beta; el esquema y las convenciones descritos aquí aún pueden cambiar.

Dónde se almacenan sus datos

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

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 dentro de una versión de instrucción de trabajo.
instruction_visit, instruction_total_visit Cada vez que un operario realiza un paso, además de totales por paso.
recording, recording_status Sesiones de ejecución (un operario ejecutando una instrucción) y su historial de estados.
issue Incidencias / tickets de mejora continua, con recuentos precomputados útiles.
issue_task, issue_comment, issue_attachment, issue_signature, issue_checklist Los elementos adjuntos a una incidencia.
issue_transition El historial del movimiento de una incidencia entre columnas del tablero.
product_order, product_order_item, product_order_item_spot Órdenes de producción y sus partidas.
users, user_group, user_group_member Personas y grupos en su espacio de trabajo.

Convenciones utilizadas en todo el esquema

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

  • Claves primarias. Cada tabla tiene una clave primaria de 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 de forma silenciosa. Cuando algo se elimina en Azumuta, su fila recibe un timestamp deleted_at. Para trabajar solo con datos actuales, añada where deleted_at is null a sus consultas.
  • Marcas de tiempo. Cada tabla incluye created_at y modified_at (y deleted_at). Todas las marcas de tiempo se almacenan en UTC.
  • Las duraciones están en milisegundos. Campos como actual_duration o rework_time se almacenan en 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 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

Cada tabla y cada columna tiene una descripción legible asociada. 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 el significado de una columna — el esquema se documenta por sí mismo.

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

En esta página
© Azumuta 2026