Het schema van de rapportagedatabase begrijpen

Bijgewerkt

Bètafunctie. De rapportagedatabase verkeert momenteel in bèta en kan nog veranderen. Deze is alleen beschikbaar op basis van opt-in. Om u aan te melden voor de bèta of vragen te stellen, neem contact op met support@azumuta.com.

Waar uw gegevens zich bevinden

Alle gegevens van uw werkruimte bevinden zich in één schema genaamd company_<your-workspace-id>. Elke tabel daarin correspondeert met een begrip dat u al kent uit Azumuta.

De belangrijkste tabellen

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

Table What it holds
workinstruction, workinstruction_version Uw werkvoorschriften en hun gepubliceerde versies.
instruction_step De afzonderlijke stappen binnen een versie van een werkvoorschrift.
instruction_visit, instruction_total_visit Elke keer dat een operator een stap doorloopt, plus totalen per stap.
recording, recording_status Uitvoersessies (een operator die een instructie uitvoert) en hun statusgeschiedenis.
issue Issues voor continue verbetering / 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 wordt verplaatst.
product_order, product_order_item, product_order_item_spot Productieorders en hun items.
users, user_group, user_group_member Personen en groepen in uw werkruimte.

Conventies die overal gelden

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

  • Primaire sleutels. Elke tabel heeft een tekstuele primaire sleutel (bijvoorbeeld recording_id, issue_id) die overeenkomt met de id van het record in Azumuta. U kunt deze gebruiken om gerelateerde tabellen te koppelen.
  • Zachte verwijderingen. Rijen worden nooit stilzwijgend verwijderd. Wanneer iets in Azumuta wordt verwijderd, krijgt de rij een deleted_at-timestamp. Als u alleen met huidige gegevens wilt werken, voeg dan where deleted_at is null aan uw queries toe.
  • Tijdstempels. Elke tabel bevat created_at en modified_at (en deleted_at). Alle tijdstempels worden opgeslagen in UTC.
  • Duur in milliseconden. Velden zoals actual_duration of rework_time worden bewaard als gehele milliseconden. Deel door 1000 voor seconden.
  • Flexibele velden gebruiken JSON. Data met variabele structuur (zoals parameters of een instructie answer) wordt opgeslagen als jsonb, die u kunt bevragen met de JSON-operatoren van PostgreSQL.
  • Vooraf berekende waarden. Om u extra joins te besparen, bevatten sommige tabellen kant-en-klare aantallen en metrics — bijvoorbeeld issue.comment_count, issue.open_task_count of recording.rework_time.

Het ingebouwde gegevenswoordenboek

Aan elke tabel en elke kolom is een leesbare beschrijving gekoppeld. De meeste SQL-clients en BI-tools tonen deze automatisch. Bijvoorbeeld in psql:

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

U kunt ze ook uitlezen 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;

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

Klaar om queries uit te voeren? Zie Voorbeeld-analyticsqueries.