Das Reporting-Datenbankschema verstehen

Aktualisiert

Beta feature. Die Reporting-Datenbank befindet sich derzeit in Beta und kann sich noch weiterentwickeln. Dieses Feature ist derzeit nur per Opt-in verfügbar. Wenden Sie sich an Ihren Azumuta-Ansprechpartner, um der Beta beizutreten und sie auszuprobieren.

Wo Ihre Daten liegen

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

Die wichtigsten Tabellen

Die genaue Auswahl der Tabellen hängt davon ab, was Sie aktiviert. Die gebräuchlichsten sind:

Table What it holds
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 durchläuft, sowie Summen pro Schritt.
recording, recording_status Ausführungssitzungen (ein Bediener führt eine Anweisung aus) und deren Statushistorie.
issue Kontinuierliche Verbesserungs-Issues/Tickets mit praktischen, vorab berechneten Zählwerten.
issue_task, issue_comment, issue_attachment, issue_signature, issue_checklist Die an ein Issue angehängten Elemente.
issue_transition Die Historie eines Issue-Wechsels 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, die überall gelten

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 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, die in ihrer Struktur variieren (wie parameters oder eine Anweisungs-answer), werden als jsonb gespeichert, das Sie mit PostgreSQLs JSON-Operatoren abfragen können.
  • Vorab berechnete Werte. Um zusätzliche Joins zu vermeiden, enthalten einige Tabellen fertige Zählwerte und Metriken — zum Beispiel issue.comment_count, issue.open_task_count oder recording.rework_time.

Das eingebaute Datenwörterbuch

Jeder Tabelle und jede Spalte ist eine menschenlesbare Beschreibung zugeordnet. 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 auslesen:

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