Das Schema der Reporting-Datenbank verstehen

Aktualisiert

Beta-Funktion. Die Reporting-Datenbank befindet sich derzeit in Beta und kann sich noch weiterentwickeln. Sie ist nur per Opt-in verfügbar. Um der Beta beizutreten oder Fragen zu stellen, kontaktieren Sie support@azumuta.com.

Wo Ihre Daten gespeichert sind

Alle Daten Ihres Arbeitsbereichs liegen in einem einzelnen Schema mit dem Namen company_<your-workspace-id>. Jede Tabelle darin entspricht einem Konzept, das Sie bereits aus Azumuta kennen.

Die wichtigsten Tabellen

Die genaue Menge an Tabellen hängt davon ab, was Sie aktiviert haben. Die gebräuchlichsten sind:

Tabelle Inhalt
workinstruction, workinstruction_version Ihre Arbeitsanweisungen und deren veröffentlichte Versionen.
instruction_step Die einzelnen Schritte einer Arbeitsanweisungs-Version.
instruction_visit, instruction_total_visit Jedes Mal, wenn ein Bediener einen Schritt ausführt, plus Summen pro Schritt.
recording, recording_status Ausführungssitzungen (ein Bediener führt eine Anweisung aus) und deren Statushistorie.
issue Issues/Tickets zur kontinuierlichen Verbesserung, mit nützlichen vorkalkulierten Zählwerten.
issue_task, issue_comment, issue_attachment, issue_signature, issue_checklist Die an ein Issue angehängten Elemente.
issue_transition Die Historie eines Issues beim Wechsel zwischen Board-Spalten.
product_order, product_order_item, product_order_item_spot Produktionsaufträge und deren Positionen.
users, user_group, user_group_member Personen und Gruppen in Ihrem Arbeitsbereich.

Konventionen im Überblick

Sobald Sie diese wenigen Regeln kennen, wird das gesamte Schema vorhersehbar:

  • Primärschlüssel. Jede Tabelle hat einen Text-Primärschlüssel (z. B. recording_id, issue_id), der mit der ID des Datensatzes in Azumuta übereinstimmt. Sie können ihn verwenden, um verwandte Tabellen zu verknüpfen.
  • Soft Deletes. Zeilen werden nie stillschweigend entfernt. Wenn in Azumuta etwas gelöscht wird, erhält die Zeile stattdessen einen Zeitstempel deleted_at. Um nur mit aktuellen Daten zu arbeiten, fügen Sie where deleted_at is null zu Ihren Abfragen hinzu.
  • Zeitstempel. Jede Tabelle enthält created_at und modified_at (und deleted_at). Alle Zeitstempel werden in UTC gespeichert.
  • Dauern sind in Millisekunden. Felder wie actual_duration oder rework_time werden als ganze Millisekunden gespeichert. Teilen Sie durch 1000 für Sekunden.
  • Flexible Felder verwenden JSON. Daten mit variabler Struktur (wie parameters oder eine Antwort in einer Anweisung) werden als jsonb gespeichert, das Sie mit den JSON-Operatoren von PostgreSQL abfragen können.
  • Vorkalkulierte Werte. Um zusätzliche Joins zu sparen, enthalten einige Tabellen bereits fertige Zählwerte und Metriken — z. B. issue.comment_count, issue.open_task_count oder recording.rework_time.

Das integrierte Datenwörterbuch

Jede Tabelle und jede Spalte hat eine menschenlesbare Beschreibung. Die meisten SQL-Clients und BI-Tools zeigen diese automatisch an. Zum Beispiel in psql:

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

Sie können sie auch mit einer Abfrage lesen:

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;

Das bedeutet, dass Sie selten raten müssen, was eine Spalte bedeutet — das Schema dokumentiert sich selbst.

Bereit für Abfragen? Siehe Beispiel-Analytics-Abfragen.

Auf dieser Seite
© Azumuta 2026