Comprender el esquema de la base de datos de informes

Actualizado

Funcionalidad beta. La base de datos de reporting está actualmente en beta y aún puede evolucionar. Está disponible solo mediante inscripción. Para unirse a la beta o formular preguntas, contacte con support@azumuta.com.

Dónde se almacenan sus datos

Todos los datos de su espacio de trabajo residen en un único esquema llamado company_<your-workspace-id>. Cada tabla dentro de é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 habituales son:

Table What it holds
workinstruction, workinstruction_version Sus work instructions y sus versiones publicadas.
instruction_step Los pasos individuales dentro de una versión de work instruction.
instruction_visit, instruction_total_visit Cada vez que un operario recorre 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 de mejora continua / tickets, con recuentos precomputados útiles.
issue_task, issue_comment, issue_attachment, issue_signature, issue_checklist Los elementos adjuntos 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 artículos.
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 resulta 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.
  • Borrados lógicos. Las filas nunca se eliminan silenciosamente. Cuando algo se borra en Azumuta, su fila recibe un sello de tiempo deleted_at. Para trabajar solo con los 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.
  • Las duraciones están en milisegundos. Campos como actual_duration o rework_time se almacenan como milisegundos enteros. Divida entre 1000 para obtener segundos.
  • Campos flexibles en JSON. Los datos que varían en estructura (como parameters o una answer de una 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 calculados — 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 por humanos asociada. La mayoría de clientes SQL y herramientas de BI las muestran automáticamente. Por ejemplo, en psql:

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

También puede consultarlas 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 Consultas analíticas de ejemplo.

En esta página
© Azumuta 2026