Das Schema der Reporting-Datenbank verstehen

BETA: Die Reporting-Datenbank befindet sich derzeit in der Beta-Phase 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 gespeichert sind

Die verwaltete Reporting-Datenbank speichert die berichtspflichtigen Daten Ihres Workspaces in einem Schema mit dem Namen company_<normalized-workspace-id>. Der Name verwendet Kleinbuchstaben und ersetzt andere Zeichen, außer Ziffern, durch Unterstriche. Eine kundenspezifische Datenbank kann einen anderen Schema-Namen verwenden. Verwenden Sie in den Beispielen unten Ihren konfigurierten Schema-Namen.

Die Haupttabellen

Das Aktivieren der Reporting-Datenbank synchronisiert alle unten aufgeführten Tabellen. Sie können keine einzelnen Tabellen auswählen.

Table	What it holds
workinstruction, workinstruction_version, workinstruction_tag	Arbeitsanweisungen, ihre Versionen und die zugewiesenen Tags. Versionen schließen nicht genehmigte Versionen ein. Verwenden Sie is_approved und is_effective, um Genehmigungs- und Wirksamkeitszustand zu prüfen.
instruction_step	Die einzelnen Schritte innerhalb einer Version einer Arbeitsanweisung.
instruction_visit, instruction_total_visit, instruction_partial_check	Jedes Mal, wenn ein Bediener einen Schritt durchführt, Per-Schritt-Summen und Teilprüfungs-Einreichungen.
recording, recording_status, recording_variant, recording_step	Aufzeichnungen mit einer Arbeitsanweisungs-Version und deren Statushistorie, ausgewählte Variantendaten und per Schritt aufgezeichnete Daten. Diese können geplante Audits enthalten, die noch nicht begonnen haben.
issue, board, issue_column	Issues, ihre Boards und Board-Spalten. Dazu gehören Continuous Improvement-, Genehmigungs-, Andon- und Trainings-Trajektory-Boards. Verwenden Sie issue.board_type, um einen Board-Typ auszuwählen.
issue_task, issue_comment, issue_attachment, issue_signature, issue_checklist	Die an ein Issue angehängten Elemente.
issue_transition	Die Historie der Bewegung eines Issues zwischen Board-Spalten.
product_order, product_order_workinstruction, product_order_workinstruction_spot	Produktionsaufträge und die mit ihnen verknüpften Arbeitsanweisungen.
article, article_category	Produktartikel und deren Kategorien, nicht Knowledge-Base-Artikel.
tree_node	Die Explore-Baumstruktur, die Module, Ordner und Inhalte organisiert.
user, user_group, user_group_member	Personen und Gruppen in Ihrem Workspace.

Audit-Aufzeichnungen in der Reporting-Datenbank

Die Tabelle recording enthält nur Aufzeichnungen mit einer numerischen Arbeitsanweisungs-Version. Eine Aufzeichnung ohne Version ist ausgeschlossen, selbst wenn ihr Status Finished (FINISHED) ist.

Die Aufzeichnung muss nicht In progress (IN_PROGRESS) oder Finished sein, um enthalten zu werden. Ein Offline-Download kann eine Arbeitsanweisungs-Version verknüpfen, während der Status Planned (IN_QUEUE) bleibt. Nach einer erfolgreichen Synchronisation der Reporting-Datenbank kann diese Aufzeichnung mit dem Status IN_QUEUE erscheinen.

Automatische Downloads hängen vom ausgewählten Geräteinhalt und dem Datumsbereich ab. Sie können erfolgen, bevor ein Bediener ein Audit öffnet. Siehe Device Settings: Offline.

Das Schließen eines nicht begonnenen Audits als N/A (NOT_APPLICABLE) verknüpft die Arbeitsanweisungs-Version nicht automatisch. Wenn die Aufzeichnung keine Version hat, schließt die Reporting-Datenbank sie weiterhin aus. Status allein erklärt daher nicht, ob ein Audit in der Datenbank erscheint.

Status und Ergebnis sind unterschiedlich

Die Spalte status enthält den gespeicherten Wert, z. B. IN_QUEUE, nicht das Anzeige-Label Planned. Siehe Status, result, and notes für alle englischen Labels und gespeicherten Werte.

Die Tabelle recording_status enthält Statusänderungen. Sie enthält keine Ergebnisänderungen.

Die Spalte recording.result speichert das gewählte Ergebnis, etwa Success (SUCCESS), Failed (FAILED), N/A (NOT_APPLICABLE) oder Cancelled (CANCELLED). Neue Aufzeichnungen starten mit PLANNED. Dieser Wert kann bestehen bleiben, wenn kein Ergebnis gewählt wird. Wenn die Quell-Aufzeichnung keinen Ergebniswert hat, ist die Spalte NULL. Verwenden Sie status, nicht result, um den Ausführungszustand zu identifizieren.

Die Spalte is_failure wird aus Prüfungen, Ereignissen und Nacharbeit berechnet. Sie kann true sein aufgrund von:

• Einer fehlgeschlagenen Prüfung oder einer Doppelprüfung.
• Einem Drehmoment-Ergebnis von NOK.
• Einer Zahl außerhalb der zulässigen Grenzen.
• Einem Andon-Ereignis, das während der Ausführung auf ein Problem hinweist.
• Einem aktuellen oder vorherigen Rework (REWORK) Status.

Die Spalte is_defect verwendet dieselben Prüfungen, schließt jedoch reine Nacharbeit aus. Beispielsweise ergibt Nacharbeit ohne eine fehlgeschlagene Prüfung oder Andon-Ereignis is_failure = true und is_defect = false. Vorherige Nacharbeit kann is_failure = true beibehalten, nachdem die Aufzeichnung beendet wurde. Siehe Rework für den Workflow.

Keine der Berechnungen verwendet das ausgewählte Ergebnis. Um N/A oder Success zu identifizieren, verwenden Sie result, nicht is_failure = false. Eine Aufzeichnung kann is_failure = false haben, ohne dass ein Ergebnis gewählt wurde.

Aufzeichnungsnotizen

Die Spalte recording.notes enthält die Notizen zur Aufzeichnung, einschließlich Notizen, die zusammen mit einem Ergebnis eingegeben wurden. Sie können mit notes = 'auto cleanup' filtern, um Aufzeichnungen mit genau dieser Notiz zu identifizieren. Fehlende oder leere Notizen erscheinen als NULL.

Vor result und notes synchronisierte Zeilen können in diesen Spalten weiterhin NULL haben. Eine normale Synchronisation aktualisiert nur geänderte Aufzeichnungen. Eine vollständige Resynchronisation ist erforderlich, um diese Spalten für unveränderte historische Aufzeichnungen zu füllen.

Abgeschlossene Arbeit und geschlossene Aufträge

Aufzeichnungsstatus und Produktauftragsstatus beschreiben unterschiedliche Arbeitsebenen:

Field and value	Meaning
recording.status = 'FINISHED'	Die Aufzeichnung ist beendet. Prüfen Sie result separat.
product_order.enhanced_status = 'all-complete' (All complete)	Der aktive Auftrag erfüllt die berechneten Abschlussbedingungen. Diese berücksichtigen seine Arbeitsanweisungen, Mengen und nicht archivierte Kinderaufträge.
product_order.enhanced_status = 'finished' (Finished)	Der Auftrag wurde geschlossen.

Ein Auftrag kann In progress bleiben, wenn seine Aufzeichnungen beendet sind, die abgeschlossene Menge jedoch nicht der erforderlichen Menge entspricht. Ein aktiver Auftrag ohne Arbeitsanweisungen oder Kinderaufträge ist All complete. Siehe Product-order status.

Das Erzwingen des Abschlusses eines Auftrags bricht seine unvollendeten Aufzeichnungen ab. Diese Aufzeichnungen erhalten den Status FINISHED und das Ergebnis CANCELLED. Schließen ist also kein Beweis für erfolgreiche Ausführung. product_order.finished_at dokumentiert den Zeitpunkt der Auftragsschließung, nicht notwendigerweise die Zeit, zu der alle Arbeiten abgeschlossen wurden.

Zonen-Zuordnungen und Zuweisung

product_order_workinstruction_spot verknüpft jedes Auftrags-Item mit seinen Zonen. Der zone_type identifiziert die Herkunft:

• assigned: eine dem Auftrags-Item zugewiesene Zone.
• accessed: eine während der Bedieneraktivität erfasste Zone, sofern dieselbe Zone nicht bereits assigned ist.
• associated: eine Zone aus der Platzierung der Arbeitsanweisung, verwendet nur wenn das Item keine zugewiesenen oder erfassten Zonen hat.

Die Tabelle kombiniert zugewiesene und erfasste Zonen. Sie führt eine Zeile pro Item und Zone, wobei assigned Vorrang hat. Eine gesperrte Zuweisung ist kein eigener SQL-Zonentyp.

Beispiel: Ein Item ist A zugewiesen, wurde bei A und B erfasst und hat die Standardplatzierung C. Die Zeilen sind assigned A und accessed B, ohne C. Ein Filter auf zone_type = 'accessed' übersieht daher den Zugriff bei A.

Die Fallback-Platzierung verwendet den direkten übergeordneten Tree-Node der Arbeitsanweisung, wenn dieser Node eine Zone ist. Es werden nicht beliebige Ahnen durchsucht.

Zuweisungen können sich ändern. Die Felder assigned_spot_id beschreiben die Zuweisung, nicht einen unveränderlichen Ausführungsort. Die Assoziationstabelle ist keine Zuweisungshistorie. Ihre Regeln stimmen außerdem nicht mit jedem integrierten Widget überein. Siehe Zone filtering for product-order widgets für die Widget-Konfiguration.

Join auf der Auftragsposten-Ebene

Um geplante Arbeit zu zählen, starten Sie bei product_order_workinstruction. Wenn Sie Aufzeichnungsdetails benötigen, verwenden Sie einen Left Join von dessen recording_id zu recording.id. So behalten Sie Items ohne Reporting-Zeile für eine Aufzeichnung bei.

Verbinden Sie Zonen über product_order_workinstruction_spot.product_order_workinstruction_id = product_order_workinstruction.id. Verbinden Sie nicht nur über workinstruction_id: Mehrere Auftragsposten können dieselbe Arbeitsanweisung verwenden.

Mehrere Zonen oder Besuche können die Menge eines Items oder die Dauer einer Aufzeichnung in einem Ergebnis mit Join vervielfachen. Verwenden Sie EXISTS für einen Assoziationsfilter oder aggregieren Sie jede Quelle vor dem Join. Siehe Count order items associated with a zone.

Geplante Benutzer und tatsächliche Bediener

recording.planned_user_id und planned_group_id beschreiben die Zuweisung. Sie identifizieren nicht alle Personen, die die Arbeit ausgeführt haben. instruction_visit.user_id identifiziert den Bediener für diesen Besuch.

Mehrere Bediener können zu einer Aufzeichnung beitragen. Zählen Sie für jeden Bediener eindeutige Recording-IDs, nicht Besuchszeilen. Eine geteilte Aufzeichnung zählt dann für jeden beitragenden Bediener. Siehe Recordings für den Reporting-Workflow und the operator query für diese Berechnung.

Besuche, Versuche und anwendbare Schritte

• instruction_visit hat eine Zeile, wenn ein Bediener einen Schritt verlässt. Ein Besuch, der noch offen ist, kann noch keine Zeile haben.
• type = 'normal' und type = 'double-check' sind getrennte Besuchsgruppen. is_last_visit markiert den letzten Besuch innerhalb seiner Gruppe, nicht unbedingt den letzten Besuch mit einer Antwort. Siehe Double-checks.
• Eine blockierte oder ungültige Prüfung zählt als Versuch, liefert jedoch keine angenommene Antwort. instruction_total_visit.answer_attempts zählt Besuche mit einem Versuch, nachdem der Bediener den Schritt verlassen hat, nicht einzelne Tastendrücke.
• instruction_total_visit enthält Summen und die final aufgezeichnete Antwort für jede Aufzeichnung, jeden Schritt und jeden Besuchstyp. Eine aufgezeichnete Antwort ist nicht notwendigerweise eine erfolgreiche Antwort.
• recording_step.active = false bedeutet, dass Varianten den Schritt ausschließen. Kein Besuch ist erwartet. Bei älteren Aufzeichnungen ohne gespeicherte Variantenauswahl werden alle Schritte als aktiv behandelt. Siehe Variants und variant configuration.

Fehlende Daten allein sind kein Beweis für ein Fehlverhalten. Prüfen Sie Anwendbarkeit, Aufzeichnungsstatus und ob der Schritt eine Antwort verlangt. Siehe Compare applicable steps with recorded answers.

Versions- und Parameterkontext

Verbinden Sie recording.workinstruction_version_id mit workinstruction_version.id, um die mit der Aufzeichnung verknüpfte Version zu lesen. Verwenden Sie nicht die aktuelle Version der Arbeitsanweisung, um historische Schritte zu interpretieren. Genehmigung ist eine separate Eigenschaft; siehe Revision History.

Bei Produktauftrags-Aufzeichnungen lesen Sie Parameter aus product_order.parameters über recording.product_order_id. Andere Aufzeichnungsparameter können in recording.parameters liegen. Siehe Product-order parameters und Introduction to parameters für die Bedeutung eines Parameters.

JSON-Felder können Listen oder verschachtelte Objekte enthalten, nicht nur Zahlen oder Text. Prüfen Sie den Typ jedes Werts, bevor Sie ihn konvertieren. Ein SQL-NULL zeigt fehlende Daten an, nicht Null oder eine fehlgeschlagene Antwort.

Konventionen, die durchgehend verwendet werden

• Primärschlüssel. Jede Tabelle hat einen Text-Primärschlüssel namens id. Dieser identifiziert einen Quell-Datensatz oder eine generierte Zeile. Verwandte Spalten verwenden Namen wie recording_id und workinstruction_id. Beispielsweise verbinden Sie recording.workinstruction_id mit workinstruction.id.
• Löschungen. Wenn ein Sync einen gelöschten Quell-Datensatz erkennt, entfernt er die entsprechenden Reporting-Zeilen. Aktuelle Tabellendefinitionen enthalten kein deleted_at. Ältere Datenbanken können diese Spalte beibehalten, da Schema-Updates alte Spalten nicht entfernen. Der aktuelle Sync pflegt sie nicht; verwenden Sie sie nicht als aktuellen Löschindikator. Archivierte Datensätze unterscheiden sich von gelöschten Datensätzen. Beispielsweise identifiziert issue.archived_at archivierte Issues.
• Sync-Zeitstempel. Jede Tabelle hat first_synced_at und last_synced_at. Diese zeichnen die erste und die zuletzt schreibende Synchronisation für die Zeile auf, nicht die Erstellung oder Änderung des Quell-Datensatzes.
• Quell-Zeitstempel. Spalten wie created_at, updated_at und started_at hängen von der Tabelle ab. PostgreSQL speichert diese Zeitstempel als Zeitpunkte in UTC und zeigt sie in der Session-Zeitzone an.
• Aufzeichnungsdauern. recording.actual_duration und recording.rework_time sind in Sekunden und können Bruchteile enthalten. Teilen Sie sie nicht durch 1000. Prüfen Sie die Spaltenbeschreibung für die Einheit anderer Felder.
• Flexible Felder verwenden JSON. Daten, die in der Form variieren (z. B. parameters oder eine Instruktions-answer), werden als jsonb gespeichert, das Sie mit PostgreSQLs JSON-Operatoren abfragen können.
• Vorkalkulierte Werte. Um zusätzliche Joins zu sparen, enthalten einige Tabellen fertige Zählungen und Metriken, z. B. issue.comment_count, issue.open_task_count oder recording.rework_time.

Das eingebaute Datenwörterbuch

Jede Tabelle und jede Spalte hat 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;

Bereit zum Abfragen? Siehe Example Analytics Queries.