Spostare dati commerciali in Square non significa copiare campi da un sistema all’altro. Square rappresenta catalogo, scorte, Customers e transazioni attraverso oggetti collegati che svolgono funzioni operative differenti. Un Product di origine può diventare un articolo di catalogo con una o più varianti. Un valore selezionabile può definire un’opzione dell’articolo, una variante vendibile, un modificatore oppure un’informazione fornita dall’acquirente. L’inventario appartiene al contesto di una specifica variante e di una specifica sede. Un Order storico conserva ciò che è accaduto, ma non diventa la configurazione che governa pagamenti, evasione degli ordini, imposte o presentazione online futuri.
La domanda centrale non è quindi se Square disponga di un campo dal nome familiare. Bisogna capire se il record di destinazione appartiene all’oggetto Square corretto e rimane collegato ai record che gli attribuiscono significato commerciale. Quando queste relazioni vengono preservate, il personale può vendere la variante giusta, interpretare le scorte per sede, trovare Customers e Orders, riconciliare identificativi esterni e pubblicare contenuti coerenti in Square Online. Quando le relazioni vengono appiattite, i dati possono sembrare completi pur comportandosi in modo errato.
Il significato dei dati in Square nasce da oggetti commerciali collegati
Il catalogo Square è composto da oggetti tipizzati, non da un unico record Product universale. Gli articoli di catalogo descrivono Products o servizi. Le varianti rappresentano versioni acquistabili. Le opzioni degli articoli possono standardizzare i valori che definiscono le varianti. Gli elenchi di modificatori descrivono cambiamenti o aggiunte selezionati al momento della vendita. Le Categories organizzano gli articoli. Imposte, sconti, regole di prezzo, immagini, unità di misura e attributi personalizzati possono partecipare alla relazione più ampia del catalogo.
Una piattaforma di origine può conservare più significati in una singola tabella Product, in un Product configurabile o in una struttura posseduta da un’applicazione. La traduzione del modello richiede di separare il record di origine negli oggetti di destinazione che possiedono davvero ciascun comportamento.
| Assunzione del negozio di origine | Significato della relazione in Square | Conseguenza per la traduzione |
|---|---|---|
| Una riga Product rappresenta l’intera unità vendibile | L’articolo e la sua variante possono essere oggetti distinti ma collegati | Conservare l’articolo padre e assegnare SKU, prezzo, stock e altra identità vendibile alla variante corretta. |
| Ogni opzione è una variante | Alcune scelte definiscono varianti; altre sono modificatori o input dell’acquirente | Classificare l’effetto commerciale della scelta prima di creare i record di destinazione. |
| Una sola quantità di stock appartiene al Product | L’inventario è legato alla variante dell’articolo e al contesto della sede | Una quantità è incompleta senza la variante vendibile e la sede operativa corrette. |
| Le Categories ricreano l’intero negozio online | Le Categories del catalogo e la struttura del sito Square Online sono collegate ma non equivalenti | Conservare la classificazione del catalogo separatamente da pagine, navigazione e presentazione degli URL. |
| Lo storico Customer ricrea il comportamento dell’account | I profili Customer conservano identità e relazioni commerciali, non ogni modello di accesso o membership dell’origine | Separare i dati Customer durevoli dal comportamento di accesso o delle applicazioni specifico dell’origine. |
| Gli Orders importati configurano le vendite future | Gli Orders registrano transazioni storiche o correnti; la configurazione resta di proprietà delle impostazioni Square per pagamenti, evasione, imposte e altre funzioni | Conservare l’istantanea della transazione senza trattarla come configurazione operativa. |
Questa visione per oggetti spiega anche perché gli identificativi esterni sono importanti. Un ID Product di origine, una chiave di magazzino, un ID Customer CRM o un riferimento contabile devono essere collegati all’oggetto Square riconosciuto dal sistema connesso. Una nota generica sull’articolo padre non sostituisce adeguatamente un identificativo di magazzino a livello di variante quando il magazzino tratta ogni variante come un articolo di stock distinto.
Articoli, varianti, opzioni e modificatori hanno significati di vendita differenti
La distinzione più importante del catalogo riguarda l’articolo e la variante dell’articolo. L’articolo descrive la famiglia di Product o servizi. La variante identifica una versione acquistabile e può possedere SKU, prezzo, unità di misura, relazione con l’immagine e significato di inventario propri. Anche un Product di origine senza opzioni visibili può diventare un articolo Square con una sola variante predefinita, perché la variante è l’oggetto vendibile usato dalle altre relazioni Square.
Le opzioni degli articoli forniscono un modo standardizzato per descrivere attributi delle varianti come taglia, colore o stile. Una variante può fare riferimento ai valori selezionati delle opzioni, consentendo a Square di comprendere la combinazione anziché dipendere soltanto da un nome visualizzato incoerente. Le varianti dell’origine devono quindi essere interpretate sia attraverso il Product padre sia attraverso i valori che rendono distinta la combinazione vendibile.
I modificatori sono diversi. Rappresentano una modifica o un’aggiunta scelta durante la vendita e non definiscono automaticamente un’identità separata soggetta a stock. Formaggio extra, confezione regalo, preferenza di preparazione o servizio opzionale possono essere assimilabili a modificatori. Una taglia con SKU e inventario propri è invece normalmente assimilabile a una variante. Trattare un modificatore come variante crea falsi record di stock; trattare una vera variante come modificatore elimina l’identità vendibile richiesta da inventario e sistemi esterni.
| Modello di origine | Probabile proprietario in Square | Significato da mantenere |
|---|---|---|
| Product semplice con un solo SKU | Articolo più una variante | Descrizione Product a livello articolo; SKU vendibile, prezzo e identità di stock a livello variante. |
| Combinazioni di taglia e colore | Opzioni dell’articolo, valori delle opzioni e varianti | Ogni combinazione acquistabile resta distinguibile e collegata al corretto articolo padre. |
| Topping opzionale o servizio aggiuntivo | Elenco modificatori e modificatore | Scelta al momento della vendita ed effetto sul prezzo senza inventare uno SKU separato soggetto a inventario. |
| Incisione o istruzione dell’acquirente | Modificatore, input personalizzato, nota sulla riga Order o record di applicazione collegata in base al comportamento supportato | Il valore fornito dal Customer resta collegato alla riga acquistata e visibile a chi evade l’ordine. |
| Kit, bundle o pacchetto | Articolo, relazione tra componenti, regola di prezzo, applicazione collegata o struttura di sistema esterno | Identità dei componenti, formazione del prezzo, proprietà dello stock e scopo di reportistica sono assegnati esplicitamente. |
| Servizio, appuntamento, abbonamento o diritto digitale | Articolo di catalogo più l’area prodotto Square o il sistema collegato che gestisce pianificazione, ricorrenza o accesso | Il record di catalogo resta separato dal sistema che governa tempo, fatturazione o diritto di accesso. |
Immagini, imposte, sconti, unità di misura e attributi personalizzati devono essere assegnati con la stessa disciplina. Un’immagine può appartenere a un articolo, a una variante o a una relazione con una Category. Un’imposta o uno sconto può essere un oggetto riutilizzabile del catalogo referenziato da articoli e Orders. Un attributo personalizzato deve avere un utilizzatore noto, per esempio personale, reportistica, un’integrazione o un altro processo Square. Valori senza un proprietario nella destinazione creano rumore invece di conservare significato aziendale.
Relazioni tra Categories, menu, immagini e merchandising
Le Categories di origine spesso svolgono più funzioni contemporaneamente: gerarchia, navigazione, merchandising, reportistica, controllo degli accessi, landing page SEO e presentazione delle campagne. Le Categories del catalogo Square conservano la classificazione del catalogo, mentre pagine, navigazione e presentazione merchandising di Square Online possono introdurre relazioni separate a livello di sito. Una migrazione deve preservare la funzione durevole di classificazione senza presumere che l’albero del vecchio negozio possa essere ricreato soltanto con record Category.
Una gerarchia di origine profonda può diventare una classificazione di catalogo più piatta combinata con navigazione o struttura di pagina in Square Online. Una collezione di origine può essere un reparto permanente, una campagna temporanea, il risultato di un filtro o una landing page editoriale. Questi significati non vanno fusi soltanto perché nel vecchio negozio comparivano tutti come link.
| Struttura di origine | Domanda sulla proprietà nella destinazione |
|---|---|
| Gerarchia permanente di reparti | Quali Categories Square preservano la classificazione durevole dei Products? |
| Collezione di campagna temporanea | La relazione appartiene a una Category, a una pagina Square Online, a una presentazione merchandising o a una regola di prezzo/sconto? |
| Raggruppamento per brand o produttore | Appartiene alla classificazione del catalogo, a un attributo personalizzato, a contenuto ricercabile o a un sistema esterno di informazioni Product? |
| Filtro tecnico | Il valore serve per confronto, ricerca, reportistica o selezione Product e quale oggetto Square o sistema collegato ne possiede l’uso? |
| Galleria Product e immagine della variante | Quale immagine appartiene alla famiglia dell’articolo e quale identifica una specifica variante vendibile? |
| Etichetta di menu e landing page | Il record punta a una Category, un articolo, una pagina Square Online, un URL esterno o una destinazione di campagna? |
Questa separazione protegge sia il commercio sia i contenuti. Una Category può restare autorevole per la classificazione Product mentre una pagina Square Online controlla come il gruppo viene presentato. Un link di menu può puntare alla destinazione corretta senza diventare il proprietario della relazione di catalogo. Le immagini possono restare collegate all’articolo o alla variante corretti anche quando cambia il layout online.
Sedi e inventario formano una relazione operativa
L’inventario Square non è una singola quantità copiata su un articolo. È collegato alla variante dell’articolo e alla sede in cui si applica lo stato di stock. Square registra inoltre l’inventario tramite conteggi fisici e transizioni di stato, per cui una quantità corrente è il risultato di una storia inventariale, non un campo Product isolato.
Un negozio, magazzino, filiale, pool di stock o canale dell’origine può non corrispondere uno a uno a una sede Square. La traduzione deve identificare quale quantità di origine appartiene a quale sede di destinazione e a quale variante vendibile. Sommare più magazzini dell’origine in un unico totale è appropriato soltanto se la destinazione usa intenzionalmente un solo pool di stock. Dividere un totale di origine tra più sedi richiede invece un’allocazione autorevole, non una supposizione.
| Segnale di inventario | Relazione nella destinazione |
|---|---|
| Stock a livello Product senza varianti | La quantità appartiene alla sola variante dell’articolo nella sede Square prevista. |
| Stock a livello variante | Ogni combinazione vendibile dell’origine viene collegata alla propria variante Square prima di assegnare lo stock. |
| Quantità specifica per magazzino | Il magazzino o la filiale di origine viene riconciliato con la sede Square che possiede la quantità. |
| Stock riservato, danneggiato, reso o in transito | Il significato dello stato viene mantenuto soltanto quando la destinazione o il sistema di inventario collegato riconosce lo stesso ciclo di vita. |
| Autorità inventariale esterna | ID della variante e chiave di stock esterna diventano più durevoli di una quantità importata una sola volta. |
| Rettifica inventariale storica | Il record resta separato dal conteggio fisico corrente salvo che sia richiesto da un’integrazione di inventario o da un sistema di audit. |
Il confine del sistema autorevole è fondamentale. Se Square gestirà l’inventario dopo il lancio, quantità e relazioni delle varianti devono essere coerenti all’interno di Square. Se ERP, sistema di magazzino o hub marketplace resteranno autorevoli, Square necessita di identificativi stabili di variante e sede che consentano all’integrazione di mantenere lo stock. La quantità importata è quindi soltanto uno stato iniziale, non la fonte permanente di verità.
Relazioni tra Customers, gruppi, segmenti e identità
I profili Customer di Square possono contenere nomi, informazioni aziendali, indirizzi email, numeri di telefono, indirizzi, note, ID di riferimento, appartenenza a gruppi, relazioni con segmenti, dati sulle preferenze marketing e attributi personalizzati. Gli ID Customer collegano inoltre Customers a Orders e ad altri record Square. Queste capacità non rendono un profilo Customer Square equivalente a ogni modello di account dell’origine.
Un account di origine può includere anche password, ruoli acquirente, gerarchie organizzative, esenzioni fiscali, saldi fedeltà, membership, abbonamenti, strumenti di pagamento salvati, accesso a portali o preferenze possedute da applicazioni. Alcuni di questi valori possono appartenere ai dati Customer Square, altri a un’area prodotto Square, a un’applicazione collegata o a un sistema esterno.
La corrispondenza delle identità deve evitare sia fusioni errate sia duplicati inutili. Email, telefono, ID Customer di origine, ID CRM esterno, relazione con gli Orders e contesto aziendale possono contribuire alla decisione. Un indirizzo email familiare condiviso non significa automaticamente che due acquirenti siano la stessa persona. Un’email modificata non significa necessariamente che il Customer sia nuovo. Gli Orders effettuati come ospite devono conservare il contesto dell’acquirente senza inventare una relazione di account permanente che non esisteva.
| Modello di identità nell’origine | Significato in Square |
|---|---|
| Customer retail registrato | Profilo Customer collegato a contatti supportati, indirizzi, gruppi, segmenti, attributi e Orders. |
| Acquirente ospite | Contesto Customer a livello Order, con profilo permanente soltanto quando le regole di identità della destinazione lo supportano. |
| Contatto aziendale | Profilo Customer più dati aziendali/di riferimento o proprietario B2B/CRM collegato; non automaticamente una gerarchia organizzativa completa. |
| Membro di un programma fedeltà | Identità Customer collegata al record Square o esterno che possiede saldo e attività del programma. |
| Iscritto marketing | Preferenza Customer o record del sistema marketing con il significato del consenso preservato indipendentemente dallo storico acquisti. |
| Account di origine duplicati | Consolidati soltanto quando evidenze di identità, consenso, proprietà degli Orders e riferimenti esterni supportano la fusione. |
L’obiettivo durevole è una relazione Customer che personale e sistemi collegati possano comprendere. Una nota importata generica è insufficiente quando lo stesso valore dovrebbe essere ricercabile come ID di riferimento, strutturato come attributo personalizzato o posseduto da un CRM.
Gli Orders conservano le relazioni della transazione, non la configurazione futura
Gli Orders Square possono contenere righe, riferimenti alle varianti degli articoli, modificatori, quantità, imposte, sconti, costi di servizio, mance, dettagli di evasione, sede, origine dell’Order, collegamenti Customer, totali e contesto di pagamenti o rimborsi. Queste relazioni rendono gli Orders storici utili per assistenza clienti, riconciliazione e reportistica, ma non configurano le transazioni future.
La riga deve conservare il Product o la variante acquistata al momento della transazione, anche se il catalogo corrente cambia in seguito. Le selezioni di modificatori e le istruzioni dell’acquirente appartengono alla riga acquistata. Imposte, sconti, costi di servizio e mance spiegano come è stato formato il totale storico. I dati di evasione spiegano se l’Order è stato ritirato, spedito, consegnato, annullato o gestito in altro modo. Origine e sede identificano dove è avvenuta la transazione.
| Valore storico | Significato nell’Order Square |
|---|---|
| Numero Order di origine | Riferimento durevole per assistenza, finanza e tracciamento tra sistemi. |
| Riga Product o variante | Identità vendibile acquistata, quantità, prezzo e istantanea descrittiva. |
| Modificatore o personalizzazione | Scelta al momento della vendita collegata alla riga corretta. |
| Imposta, sconto, costo di servizio o mancia | Componente del totale storico, non regola di prezzo attiva. |
| Riferimento di pagamento o metodo | Evidenza della transazione completata o tentata, non configurazione riutilizzabile dei pagamenti. |
| Evasione e tracciamento | Contesto storico di consegna o ritiro, non definizione dei metodi di evasione correnti. |
| Rimborso o rettifica | Storico finanziario collegato all’Order e alla transazione originali. |
| Sede e origine | Origine operativa dell’Order e relazione con Square o con il canale esterno. |
Anche le righe storiche ad hoc richiedono attenzione. Un Order di origine può fare riferimento a un Product che non esiste più o a un addebito generato da un’applicazione senza equivalente nel catalogo corrente. L’Order può comunque conservare descrizione e importo storici, ma il record non dovrebbe creare artificialmente un articolo di catalogo corrente salvo che l’azienda intenda venderlo nuovamente.
Contenuti Square Online, URL e proprietà del sito
Square Online aggiunge un livello sito attorno ai dati commerciali Square. Articoli del catalogo e Categories possono partecipare alla vendita online, ma pagine, navigazione, domini, percorsi URL, redirect, campi SEO, contenuti legali, Blog Posts, posizionamento dei media e presentazione personalizzata hanno un proprio significato a livello di sito.
Un URL Product di origine può cambiare quando il Product diventa una pagina articolo in Square Online. Una landing page Category di origine può richiedere una destinazione Square Online anziché soltanto una Category di catalogo. Una CMS Page può diventare una pagina del sito, essere consolidata in un’altra pagina o restare fuori dal sito commerciale. Blog Posts, raccolte editoriali, risorse scaricabili e pagine di campagna devono conservare relazioni di contenuto e destinazione prevista anche quando il design visivo viene ricostruito.
| Risorsa web di origine | Proprietario nella destinazione |
|---|---|
| Titolo, descrizione e media Product | Articolo di catalogo e relativa relazione di presentazione online. |
| URL Product o Category | Percorso Square Online più ogni relazione di redirect necessaria dall’origine alla destinazione. |
| Pagina informativa o legale | Pagina Square Online o altra destinazione di contenuto definita. |
| Blog Post o archivio editoriale | Destinazione di pubblicazione supportata o sistema di contenuti posseduto separatamente. |
| Voce di menu | Relazione di navigazione del sito che punta a un articolo, Category, pagina o URL esterno. |
| Blocco del tema, script personalizzato o widget applicativo | Configurazione di presentazione o integrazione del sito, non normale contenuto di catalogo. |
| Dominio e redirect | Configurazione del sito e dell’instradamento collegata alla destinazione di contenuto preservata. |
Il modello dei contenuti deve quindi mantenere separati i dati commerciali autorevoli dai componenti del sito che li presentano. Un Product resta un articolo di catalogo anche quando diverse pagine Square Online lo collegano. Una pagina resta contenuto anche quando contiene riferimenti Product. Un redirect resta una relazione di instradamento, non un sostituto del record di destinazione.
Attributi personalizzati, applicazioni e identificativi esterni
Square supporta attributi personalizzati su diversi tipi di oggetto, mentre molte aziende usano anche applicazioni per contabilità, CRM, fidelizzazione, consegna, ristorazione, retail, pianificazione, reportistica, marketplace e inventario. Il fatto che entrambi i sistemi contengano un campo personalizzato non dimostra che i campi abbiano lo stesso proprietario o ciclo di vita.
I dati personalizzati devono essere classificati in base a oggetto padre, scopo aziendale, sistema autorevole e utilizzatore futuro. Una chiave di magazzino a livello variante appartiene alla relazione tra variante e magazzino. Un ID CRM Customer appartiene alla relazione tra Customer e CRM. Un ID marketplace Order appartiene alla relazione tra Order e canale. Un’impostazione di uno script del sito appartiene alla configurazione del sito, non a un record Customer o Product.
| Segnale personalizzato o esterno | Definizione corretta della proprietà |
|---|---|
| Chiave Product ERP | Articolo o variante riconosciuti dall’ERP in base alla granularità Product adottata dall’ERP. |
| SKU di magazzino | Variante soggetta a inventario più relazione con sede o magazzino. |
| ID Customer CRM | Profilo Customer più CRM esterno che considera l’ID autorevole. |
| ID inserzione marketplace | Relazione articolo/variante/canale, non nota generica sul Product. |
| Saldo fedeltà o ID membership | Customer più sistema fedeltà che possiede registro e stato. |
| Attributo Order personalizzato | Order o riga più applicazione che crea e utilizza il valore. |
| Dati widget Square Online | Configurazione del sito o dell’applicazione più riferimenti ai record commerciali sottostanti. |
| Tabella di origine non supportata | Entità padre, chiave, ciclo di vita e proprietario di destinazione espliciti prima di conservare qualsiasi valore. |
Questo modello di proprietà evita due errori: forzare ogni valore di origine nel campo Square più vicino e conservare dati personalizzati senza sapere a cosa appartengono. Un valore è utile soltanto quando il team sa quale record lo possiede, quale sistema lo riconosce e se descrive un’entità corrente, una transazione storica o un comportamento di presentazione.
Decisioni di traduzione per modelli comuni dell’origine
Il modello finale della destinazione Square dovrebbe essere espresso come relazioni anziché come elenco di campi. Alcuni modelli rappresentativi rendono visibili tali relazioni prima di definire la mappatura su larga scala.
| Modello di origine | Relazione di destinazione Square |
|---|---|
| Product di abbigliamento configurabile | Articolo → opzioni articolo → valori opzione → varianti articolo → immagini/SKU variante → inventario per sede. |
| Voce menu ristorante con extra | Articolo/variante → elenco modificatori → modificatori → selezioni sulla riga Order → contesto di evasione. |
| Catalogo multi-magazzino | Variante articolo → sede Square o magazzino esterno → stato inventario → chiave stock esterna. |
| Customer retail con fidelizzazione | Customer → dati di contatto/riferimento → Orders → record fedeltà posseduto da Square o sistema collegato. |
| Order marketplace | Order → riferimento origine/canale → variante sulla riga o istantanea ad hoc → storico pagamento/evasione → ID marketplace esterno. |
| Pagina Category sensibile alla SEO | Category catalogo → destinazione Square Online → link di navigazione → redirect URL di origine → articoli referenziati. |
| Configuratore Product personalizzato | Articolo/variante catalogo → configurazione posseduta dall’applicazione → output sulla riga Order → identificativi esterni per l’evasione. |
Queste catene relazionali rendono esplicito l’ambito della migrazione identificando il proprietario nella destinazione, i record dipendenti e il comportamento esterno che continua fuori dal catalogo principale. Evidenziano inoltre i casi in cui un record di origine deve diventare più oggetti Square collegati. Una catena è completa soltanto quando personale e sistemi collegati possono seguire articolo, Customer, Order, contenuto o identificativo esterno nella destinazione senza dipendere dalla piattaforma di origine per comprenderlo.
Conclusione
La traduzione del modello dati verso Square dipende dall’assegnazione di ogni valore dell’origine all’oggetto Square che ne possiede il significato commerciale. Articoli, varianti, opzioni, modificatori, Categories, sedi, inventario, Customers, Orders, contenuti Square Online, attributi personalizzati e identificativi esterni sono collegati ma non intercambiabili.
Un modello di destinazione solido preserva le relazioni padre-figlio e tra sistemi che danno senso ai dati. Mantiene l’identità della variante collegata a stock e sedi, l’identità Customer collegata a Orders e riferimenti esterni, le transazioni storiche separate dalla configurazione futura e la presentazione Square Online separata dai record autorevoli del catalogo. Questa struttura rende i dati migrati comprensibili e utilizzabili, non semplicemente presenti.
Domande frequenti
Qual è la differenza tra una variante articolo Square e un modificatore?
Una variante è una versione acquistabile di un articolo e può portare SKU, prezzo, immagine, unità di misura e significato di inventario. Un modificatore è normalmente un’aggiunta, una rimozione o una preferenza scelta al momento della vendita. La destinazione corretta dipende dal fatto che la scelta crei o meno un’identità vendibile distinta e controllata a inventario.
Ogni opzione Product dell’origine deve diventare un’opzione articolo Square?
No. Le opzioni articolo sono appropriate quando i relativi valori definiscono scelte standardizzate delle varianti. Personalizzazioni, extra opzionali, istruzioni dell’acquirente o scelte guidate da applicazioni possono appartenere a modificatori, dati della riga Order, attributi personalizzati o un altro sistema proprietario.
Perché la sede Square è importante nella migrazione dell’inventario?
L’inventario Square ha significato per una specifica variante e una specifica sede. Una quantità priva della corretta relazione variante-sede può essere numericamente esatta ma assegnare lo stock al contesto operativo sbagliato.
I profili Customer Square possono riprodurre ogni funzione dell’account di origine?
No. I profili Customer possono conservare identità, contatti, gruppi, segmenti, preferenze, attributi personalizzati e relazioni con Orders supportati. Password, gerarchie B2B, membership, registri fedeltà, abbonamenti e permessi posseduti da applicazioni possono avere proprietari diversi nella destinazione.
Gli Orders migrati in Square configurano pagamenti ed evasione degli ordini?
No. Gli Orders conservano righe, rettifiche, sede, origine, contesto dei pagamenti, storico dell’evasione e altre evidenze della transazione. Comportamento corrente di pagamenti, imposte, evasione, notifiche e applicazioni resta configurazione separata.
Come vanno rappresentati campi personalizzati e ID esterni in Square?
Ogni valore va collegato all’articolo, variante, Customer, Order, riga, record del sito, applicazione o sistema esterno che lo possiede. Il campo deve inoltre conservare la chiave necessaria al sistema che lo utilizza; inserire ogni valore personalizzato in una nota generica fa perdere il significato relazionale.