Come utilizzare un modello di dati comune

Indicazioni per l'adesione a un Modello di dati comune ed esempi su come crearne uno.

Che cos'è un modello di dati comune?

Le applicazioni possono essere combinate per risolvere i casi d'uso, collegandosi tra i processi di produzione utilizzando le tabelle del Tulip Common Data Model for Discrete{target=_blank} o del Common Data Model for Pharma. A differenza dei modelli di dati tradizionali che si basano sulle dipendenze, il Common Data Model componibile di Tulip consente di aggiungere tabelle nel tempo, caso per caso.

Un modello di dati comune fornisce una raccolta di schemi di dati standardizzati ed espandibili. Questi schemi predefiniti coprono vari tipi di dati, tra cui artefatti operativi, artefatti fisici, materiali di riferimento e registri di eventi. Rappresentando concetti e attività ampiamente utilizzati, come gli ordini di lavoro e le unità, questi schemi facilitano la creazione, la compilazione e l'analisi dei dati. La standardizzazione aiuta a semplificare la gestione dei dati tra i diversi sistemi.

Modello di dati comune in Composability

Le tabelle Tulip svolgono un ruolo cruciale nella gestione dei flussi di dati e nel mantenimento della connessione tra le applicazioni. Esse contengono informazioni che vengono visualizzate nelle applicazioni e le applicazioni creano, aggiornano ed eliminano i record delle tabelle. Se più applicazioni utilizzano le stesse tabelle, possono comunicare tra loro attraverso le tabelle.

Ad esempio, un manager crea un ordine di lavoro in un'applicazione e un operatore lo esegue in un'altra applicazione o in un insieme di applicazioni.

Quando si progetta una soluzione per un determinato problema, la definizione delle tabelle da utilizzare è una delle fasi più importanti. La scelta logica delle tabelle può portare a un'applicazione più semplice, riutilizzabile e componibile. Se la giusta quantità di dati viene memorizzata nelle tabelle, il costruttore di applicazioni può ridurre il numero di variabili utilizzate, rendendo l'applicazione meno complessa e facile da personalizzare. Se le applicazioni all'interno di una soluzione utilizzano lo stesso set di tabelle, le applicazioni diventano intercambiabili o componibili, senza dover riprogettare l'una o l'altra applicazione.

Le migliori pratiche

:::(Info) (Nota) Per comprendere le tabelle che compongono un modello di dati comune, è importante conoscere le Best Practices for Storing Data in Tulip:::

Le tabelle di Tulip devono seguire principalmente il modello Digital Twin, ossia le tabelle devono riflettere il più rigorosamente possibile lo stabilimento fisico o l'officina. I dati storici delle applicazioni devono essere limitati ai record di completamento, assicurando che le tabelle non vengano utilizzate per memorizzare dati master o dati duplicati dai record di completamento o da record esterni.

Tipi di tabelle primarie

Idealmente, le tabelle dovrebbero rappresentare artefatti fisici e operativi.

Queste tabelle includeranno sempre un campo Stato che verrà regolarmente aggiornato dalle applicazioni.

Il diagramma seguente mostra le tabelle complete del Modello comune dei dati e quali tabelle utilizzare per i casi d'uso della produzione discreta e del settore farmaceutico.

Ecco una ripartizione di tutti i tipi di tabelle del Modello comune dei dati:

Artefatti fisici

Gliartefatti fisici sono oggetti tangibili presenti nello stabilimento o componenti che vengono utilizzati o prodotti durante le operazioni. Quando lo stato di un artefatto fisico cambia o si aggiorna, questa modifica si riflette nel record (ad esempio, cambiamento di stato).

Esistono due categorie di artefatti fisici:

1. AssetGli assetriguardano componenti che equipaggiano, contengono o eseguono un processo, come ad esempio: * Attrezzature * Bilance * Luoghi

2. MaterialiI materialiriguardano gli elementi utilizzati o creati in un processo, come ad esempio: * Articoli di inventario * Unità * Lotto

Artefatti operativi

Gliartefatti operativi sono elementi o componenti tangibili o intangibili che consentono o supportano le operazioni.

Esistono tre categorie di artefatti operativi:

1. CompitiI compiticomportano un processo attivabile, come ad esempio: * Risultati delle ispezioni * Schede Kanban

2. EventiGli eventiriguardano qualcosa che è accaduto, come ad esempio: * Difetti * Correzioni

3. OrdiniGli ordiniriguardano informazioni su beni o impegni, come ad esempio: * Ordini di lavoro * Ordini di processo

Tipi di tabella secondari (avanzati)

Ci sono casi in cui è necessario prendere in considerazione la possibilità di infrangere le best practice. Per le circostanze più avanzate, e con la massima parsimonia possibile, potrebbe essere necessario utilizzare i seguenti due tipi di tabella secondaria:

• Registro
• Riferimento

I dati in queste tabelle saranno probabilmente statici e non verranno aggiornati (per questo motivo è preferibile mantenere questi tipi di dati nei record di completamento o nel sistema esterno originale).

:::(Error)Secondary table types do not fit within a Digital Twin model and should only be considered by advanced users. Questi tipi di tabella devono essere inclusi solo dopo aver completato il processo di progettazione della soluzione e aver esaurito tutte le altre opzioni. I tipi di tabella secondari non devono MAI costituire la base di una soluzione applicativa:

Registri

Iregistri degli eventi sono informazioni che possono essere consultate e definiscono qualcosa in produzione. Spesso si trovano in sistemi esterni come un ERP. Poiché i dati storici sono tradizionalmente tracciati tramite il completamento dell'app e memorizzati nei record di completamento, è necessario utilizzare una tabella Log SOLO se:* È necessario separare dati specifici dai record di completamento a scopo di visualizzazione* È necessario utilizzare questi dati in calcoli, in particolare query e aggregazioni.

Esempi:

• Note e commenti
• Registri di genealogia
• Cronologia delle attività della stazione
• Risultati delle ispezioni

Non si dovrebbe ricorrere alle tabelle di registro per:* Registrazioni storiche* Rintracciabilità

Riferimenti

Iriferimenti sono registri condivisi tra le applicazioni. È simile al concetto di record di completamento, tranne per il fatto che è condiviso tra le applicazioni e rende accessibili le query di tabella, le {{glossario.Aggregazioni}} e la mutabilità delle tabelle Tulip.

Ove possibile, i dati dovrebbero essere recuperati in tempo reale direttamente dalla fonte originale, ad esempio un ERP, tramite un connettore HTTP. Potrebbe essere necessario utilizzare una tabella di riferimento in casi marginali come:* Temporaneamente, mentre si stabilisce la connessione a un ERP.* Se il sistema esterno contiene dati di riferimento limitati che devono essere aumentati con Tulip.

Il vostro approccio si evolverà nel tempo, man mano che le soluzioni matureranno e i sistemi diventeranno più integrati e strettamente accoppiati.

Esempi:

• Definizioni dei materiali
• Distinta dei materiali

Costruire il proprio modello di dati comuni

L'esempio di Modello comune di dati di Tulip è stato concepito come punto di partenza per costruire il vostro modello di dati. Tuttavia, tutti i processi e le soluzioni sono diversi e, come le applicazioni, il modello di dati può essere personalizzato secondo le necessità.

Le modifiche più piccole comprendono l'aggiunta e la rimozione di campi dalle tabelle. In alcuni casi (processi speciali, più tabelle necessarie per lo stesso caso d'uso) sono necessarie modifiche sostanziali. Questo può essere fatto sostituendo una o più tabelle dal modello di dati scaricato o inserendo tabelle aggiuntive.

Pianificare un modello di dati comune

1. Definire gli artefatti fisici e operativi del vostro processo.
2. Trovare le rispettive tabelle per ogni artefatto
3. Esplorare i tipi di dati che devono essere raccolti dalle applicazioni e i riferimenti che devono essere utilizzati.

Ulteriori letture

• Memorizzazione dei dati
• Tabelle Tulip comuni
• Migliori pratiche per l'archiviazione dei dati in Tulip