Overslaan en naar hoofdcontent gaan

Het Reporting Database Schema begrijpen

Beta feature. De reporting database is momenteel in beta en kan nog verder evolueren. Deze is alleen beschikbaar via opt-in. Om deel te nemen aan de beta of vragen te stellen, neem contact op met support@azumuta.com.

Waar uw gegevens zich bevinden

Alle gegevens van uw workspace bevinden zich in een enkel schema met de naam company_<your-workspace-id>. Elke tabel erin komt overeen met een concept dat u al kent van Azumuta.

De belangrijkste tabellen

De exacte set tabellen hangt af van wat u hebt ingeschakeld. De meest voorkomende zijn:

Tabel Wat het bevat
workinstruction, workinstruction_version Uw werkinstructies en hun gepubliceerde versies.
instruction_step De afzonderlijke stappen binnen een werkinstructie versie.
instruction_visit, instruction_total_visit Elke keer dat een operator een stap doorloopt, plus totalen per stap.
recording, recording_status Recordings met een werkinstructie versie en hun statusgeschiedenis. Deze kunnen geplande audits bevatten die nog niet zijn gestart.
issue Doorlopende verbeteringsissues / tickets, met handige vooraf berekende aantallen.
issue_task, issue_comment, issue_attachment, issue_signature, issue_checklist De items die aan een issue zijn gekoppeld.
issue_transition De geschiedenis van een issue dat tussen kolommen op het bord beweegt.
product_order, product_order_item, product_order_item_spot Productieorders en hun items.
users, user_group, user_group_member Personen en groepen in uw workspace.

Audit recordings in de reporting database

De recording tabel bevat alleen recordings met een numerieke werkinstructie versie. Een recording zonder versie wordt uitgesloten, zelfs wanneer de status Afgewerkt (FINISHED) is.

De recording hoeft niet Bezig (IN_PROGRESS) of Afgewerkt te zijn om te worden opgenomen. Een offline download kan een werkinstructie versie koppelen terwijl de status Gepland (IN_QUEUE) blijft. Na een geslaagde reporting database synchronisatie kan die recording verschijnen met status IN_QUEUE.

Automatische downloads zijn afhankelijk van de geselecteerde inhoud en het datumbereik van het device. Ze kunnen plaatsvinden voordat een operator een audit opent. Zie Device Instellingen: Offline.

Het sluiten van een niet-gestarte audit als N/A (NOT_APPLICABLE) koppelt op zichzelf geen werkinstructie versie. Als de recording geen versie heeft, blijft de reporting database deze uitsluiten. Status alleen verklaart niet of een audit in de database verschijnt.

Status en resultaat zijn verschillend

De status kolom bevat de opgeslagen waarde, zoals IN_QUEUE, niet het weergavelabel Gepland. Zie Status, resultaat en notities voor alle Engelse labels en opgeslagen waarden.

De recording_status tabel bevat statuswijzigingen. Deze bevat geen resultaatwijzigingen.

De recording tabel heeft geen kolom voor het geselecteerde resultaat, zoals Succes (SUCCESS), Mislukt (FAILED), of N/A (NOT_APPLICABLE).

De is_failure kolom wordt berekend op basis van checks, events en rework. Deze kan true zijn vanwege:

  • Een mislukte check of dubbelcheck.
  • Een koppelresultaat van NOK.
  • Een getal buiten de toegestane limieten.
  • Een Andon event, dat een probleem tijdens uitvoering aangeeft.
  • Een huidige of vorige Rework (REWORK) status.

De berekening gebruikt het geselecteerde resultaat niet. Gebruik niet is_failure = false om N/A of Succes te identificeren. Deze waarde kan ook voorkomen wanneer een audit geen resultaat heeft.

Recording notities

Notities die met een resultaat zijn ingevoerd, worden opgeslagen op de recording in Azumuta. De reporting database bevat deze recording notities niet. Een notitie zoals "auto cleanup" kan audits in een reporting database query niet onderscheiden.

Conventies die overal worden gebruikt

Zodra u deze enkele regels kent, wordt het hele schema voorspelbaar:

  • Primaire sleutels. Elke tabel heeft een tekstprimaire sleutel (bijvoorbeeld recording_id, issue_id) die overeenkomt met de id van de record in Azumuta. U kunt deze gebruiken om gerelateerde tabellen samen te voegen.
  • Soft deletes. Rijen worden nooit stilzwijgend verwijderd. Wanneer iets in Azumuta wordt verwijderd, krijgt de rij in plaats daarvan een deleted_at timestamp. Om alleen met huidige gegevens te werken, voegt u where deleted_at is null toe aan uw query's.
  • Timestamps. Elke tabel bevat created_at en modified_at (en deleted_at). Alle timestamps worden opgeslagen in UTC.
  • Duraties zijn in milliseconden. Velden zoals actual_duration of rework_time worden opgeslagen als hele milliseconden. Deel door 1000 voor seconden.
  • Flexibele velden gebruiken JSON. Gegevens die in vorm variëren (zoals parameters of een instructie answer) worden opgeslagen als jsonb, die u kunt opvragen met PostgreSQL's JSON-operators.
  • Vooraf berekende waarden. Om u extra joins te besparen, bevatten sommige tabellen kant-en-klare aantallen en metriek — bijvoorbeeld issue.comment_count, issue.open_task_count, of recording.rework_time.

Het ingebouwde gegevenswoordenboek

Elke tabel en elke kolom heeft een voor mensen leesbare beschrijving eraan gekoppeld. De meeste SQL-clients en BI-tools tonen deze automatisch. Bijvoorbeeld in psql:

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

U kunt ze ook lezen met een query:

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;

Dit betekent dat u zelden hoeft te raden wat een kolom betekent — het schema documenteert zichzelf.

Klaar om query's uit te voeren? Zie Voorbeeld Analytics Queries.

Verwante artikelen