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 an der Beta teilzunehmen oder Fragen zu stellen, kontaktieren Sie support@azumuta.com.

Wo Ihre Daten liegen

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

Die Haupttabellen

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

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

Im Schema verwendete Konventionen

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

  • Primärschlüssel. Jede Tabelle hat einen Text-Primärschlüssel (zum Beispiel 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 deleted_at-Zeitstempel. 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, um Sekunden zu erhalten.
  • Flexible Felder verwenden JSON. Daten mit variabler Struktur (wie parameters oder eine Anweisungs-answer) werden als jsonb gespeichert, die Sie mit den JSON-Operatoren von PostgreSQL abfragen können.
  • Vordefinierte Werte. Um zusätzliche Joins zu vermeiden, enthalten einige Tabellen fertige Zählwerte und Kennzahlen — zum Beispiel issue.comment_count, issue.open_task_count oder recording.rework_time.

Das integrierte Datenwörterbuch

Jeder Tabelle und jeder Spalte ist eine menschenlesbare Beschreibung angehängt. 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 kaum raten müssen, was eine Spalte bedeutet — das Schema dokumentiert sich selbst.

Bereit zum Abfragen? Sehen Sie Beispiel-Analytics-Abfragen.

Auf dieser Seite
© Azumuta 2026