Modello di dati delle entità per le PMI: modellazione chiara delle entità

Un modello di dati di entità rappresenta oggetti aziendali reali come record di dati univocamente identificabili, dotati di attributi, relazioni e una fonte definita. Per la vostra azienda, questo significa che organizzazione, marchio, persona, sede, servizio, prodotto, riferimento e metodo di contatto non vengono inseriti nuovamente in ogni sottopagina, ma vengono modellati una sola volta e poi utilizzati in modo coerente.

Soprattutto nelle PMI altoatesine, le informazioni contraddittorie raramente derivano da negligenza. Nel mio lavoro con le piccole e medie imprese, mi imbatto più frequentemente in un problema diverso: il sito web riporta orari di apertura diversi rispetto al profilo Google My Business, una brochure utilizza un marchio obsoleto e la versione in lingua italiana indica un referente che non è più responsabile. Il contenuto c'è, ma la fonte e la responsabilità non sono chiare.

Un modello di dati di entità pulito riduce la duplicazione degli sforzi. Crea un'unica fonte di verità per i dati aziendali chiave e fornisce una base affidabile per il tuo sito web, i motori di ricerca, le traduzioni, le interfacce e i sistemi di intelligenza artificiale.

Cosa può fare un modello di dati di entità per la tua azienda

Un'entità è un oggetto chiaramente definito su cui la tua azienda gestisce informazioni. Un'organizzazione è un'entità. Una sede è un'altra entità. Anche un servizio, un prodotto o un riferimento specifico possono essere considerati entità separate.

La differenza cruciale rispetto al testo di una pagina web ordinaria risiede nell'identità: un'entità mantiene il suo ID stabile anche se il nome, la descrizione, l'URL o la lingua cambiano. Ciò consente a sistemi diversi di fare riferimento in modo affidabile allo stesso oggetto.

Un ID stabile risponde alla domanda "A quale oggetto ci si riferisce?". Il nome canonico risponde alla domanda "Come chiamiamo attualmente questo oggetto?".

Un record di entità utilizzabile contiene almeno:

• ID stabile: un identificatore permanente e univoco che non dipende da un nome tradotto.
• Nome canonico: il nome principale ufficiale dell'ente.
• Nome alternativo: Nomi precedenti, forme abbreviate, nomi commerciali o varianti comuni.
• Caratteristiche: Ad esempio, indirizzo, descrizione, indirizzo email, orari di apertura o area di servizio.
• Relazione: un collegamento chiaro con altre entità, come ad esempio "la sede appartiene all'organizzazione".
• Sistema sorgente: la fonte principale in cui viene mantenuto il valore in questione.
• Lingua: l'etichettatura di valori dipendenti dalla lingua, ad esempio tedesco o italiano.
• Status: Bozza, approvato, obsoleto o archiviato.
• Responsabilità: La persona o il ruolo che esamina e approva le modifiche.
• Data dell'ispezione: la data dell'ultima ispezione professionale.

Questa struttura trasforma i dati sparsi delle entità presenti sul sito web in informazioni aziendali gestibili. Il software può automatizzare il processo. L'intelligenza artificiale può essere d'aiuto nella verifica, nella traduzione o nell'individuazione di discrepanze. Tuttavia, nessun software può sostituire la decisione aziendale in merito a quale fonte sia autorevole e chi sia responsabile della qualità dei dati.

Le otto entità principali nel modello dati delle entità

1. Organizzazione

L'organizzazione descrive l'entità giuridica o economica che sta alla base dell'attività. I ​​campi rilevanti includono la denominazione ufficiale, la forma giuridica, l'indirizzo, il codice fiscale o la partita IVA, le informazioni sulla fondazione, i principali recapiti e i responsabili della gestione.

Le relazioni tipiche includono:

• L'organizzazione guida il marchio.
• L'organizzazione ha una sede.
• Organizzazione che impiega o rappresenta una persona.
• L'organizzazione offre un servizio o un prodotto.
• L'organizzazione fornisce un metodo di contatto.

2. Marca

Il marchio non è automaticamente identico all'organizzazione legale. Un'azienda può gestire più marchi; viceversa, un marchio può essere utilizzato da diverse aziende. Gli elementi chiave includono il nome canonico, le grafie alternative, il posizionamento, il logo, il tono di voce, il proprietario del marchio e le versioni linguistiche approvate.

Questa separazione è particolarmente importante durante un'operazione di rebranding. Se il nome del marchio cambia, l'organizzazione può rimanere invariata. Una solida strategia di branding e un'architettura del marchio ben definita forniscono le basi professionali necessarie a questo scopo.

3. Persona

Una persona può essere fondatore, amministratore delegato, referente, autore, responsabile di progetto o esperto in materia. La scheda dati deve includere nome, ruolo, responsabilità, foto del profilo, breve biografia, lingue parlate, organizzazione di appartenenza e metodi di contatto approvati.

I dati personali richiedono autorizzazioni chiare. Non tutte le informazioni interne devono essere presenti sul sito web o incluse nei dati strutturati. Il modello dati dell'entità dovrebbe pertanto distinguere tra proprietà interne, protette e accessibili al pubblico.

4. Posizione

Una sede necessita di una propria identità se il suo indirizzo, gli orari di apertura, il numero di telefono, i servizi offerti o le responsabilità differiscono da quelli della sede centrale. I campi rilevanti includono il nome della sede, l'indirizzo, le coordinate geografiche, il fuso orario, gli orari di apertura, le lingue offerte e l'organizzazione di appartenenza.

La relazione deve essere inequivocabile: "La sede di Bolzano appartiene all'Organizzazione A" e "I servizi di consulenza sono disponibili presso la sede di Bolzano". Questo modello di dati per le entità impedisce che gli orari di apertura o i numeri di telefono vengano accidentalmente applicati a tutte le filiali.

5. potere

Un servizio descrive un'attività o un'offerta chiaramente definita, come ad esempio la strategia di branding, lo sviluppo web o la consulenza. I campi rilevanti includono nome, descrizione del servizio, gruppo target, fornitore, area di servizio, lingua disponibile, persona responsabile e riferimenti pertinenti.

Un servizio è molto più di una semplice intestazione di pagina. Lo stesso record di dati può comparire nella pagina di un servizio, nel profilo di una sede, in un riferimento e in dati leggibili automaticamente. Nell'articolo su Service Schema e JSON-LD , approfondirò il collegamento tra le pagine dei servizi e le informazioni strutturate appropriate.

6. Prodotto

Un prodotto è un'offerta concreta e riconoscibile, dotata di una propria identità. Può trattarsi, ad esempio, di una linea di prodotti, di una soluzione software o di un oggetto fisico. I campi rilevanti possono includere il nome del prodotto, il produttore, il marchio, la descrizione, la variante, il codice articolo, la disponibilità, il prezzo e il canale di vendita.

Servizio e prodotto dovrebbero rimanere distinti, anche se venduti insieme. La consulenza è un servizio. Una piattaforma software standardizzata è un prodotto. La relazione potrebbe essere descritta, ad esempio, come: "L'implementazione del servizio supporta il prodotto X".

7. Riferimento

Un documento di riferimento registra il lavoro effettivamente svolto. La registrazione dei dati dovrebbe includere il nome del progetto, l'approvazione del cliente, il periodo di tempo, i servizi forniti, le persone responsabili, la situazione iniziale, il risultato e i supporti utilizzabili.

Il riferimento acquista significato attraverso le relazioni. Il sito web può quindi non solo mostrare l'immagine di un progetto, ma anche spiegare quale organizzazione è stata supportata, quali servizi sono stati forniti, quale luogo è stato coinvolto e quale persona ne è stata professionalmente responsabile.

8. Metodo di contatto

Un canale di contatto è una modalità specifica per entrare in contatto con la tua azienda: numero di telefono, indirizzo email, modulo, messaggistica istantanea, canale di supporto o persona di riferimento. Ogni canale di contatto deve avere uno scopo, un pubblico di riferimento, le lingue disponibili, gli orari di disponibilità, la sede geografica associata e una persona o un'organizzazione responsabile.

Il modello dati dell'entità può quindi distinguere se un numero di telefono è destinato a richieste generiche, vendite, assistenza o a una località specifica. Un metodo di contatto non solo deve essere corretto, ma anche chiaramente assegnato a uno scopo.

Modellazione delle entità aziendali in sette fasi

Fase 1: Dati di inventario

Innanzitutto, raccogli tutte le fonti in cui compaiono i dati aziendali: sito web, profilo Google My Business, CRM, ERP, firme email, listini prezzi, PDF, profili sui social media e documenti interni. Evidenzia le discrepanze invece di selezionare immediatamente la versione che si presume corretta.

La valutazione iniziale spesso rivela che non vi è una carenza di informazioni. Di solito, esistono diverse varianti senza una gerarchia discernibile.

Passaggio 2: Separare le entità l'una dall'altra

Per ogni record di dati, verifica quale oggetto del mondo reale descrive. Un test utile è: questo oggetto può cambiare indipendentemente dagli altri?

• È possibile che la sede si trasferisca senza che l'organizzazione cambi nome? In tal caso, la sede costituisce un'entità giuridica separata.
• Una persona può lasciare l'azienda mantenendo il proprio profilo di rendimento? In tal caso, la persona e il suo profilo di rendimento non devono essere uniti in un unico record di dati.
• È possibile rinominare un marchio mantenendo la stessa personalità giuridica? In tal caso, il marchio e l'organizzazione devono essere entità separate.

Passaggio 3: Assegnare ID stabili

Nel modello dati delle entità, utilizzare ID indipendenti da nomi, lingue o URL correnti. Un formato interno potrebbe essere simile a questo, ad esempio:

• org-0001 per l'organizzazione
• marca-0001 per il marchio
• posto-0001 per la prima posizione
• person-0001 per una persona
• servizio-0001 per un servizio

L'ID "service-0001" rimane invariato anche se "Digitalberatung" viene successivamente rinominato "Digitale Prozessberatung". L'URL descrittivo può cambiare; l'identità interna deve rimanere stabile.

Passaggio 4: Modellare esplicitamente le relazioni

Non limitarti a memorizzare le relazioni come semplici descrizioni. "Maria Huber gestisce la sede di Merano" dovrebbe esistere come una relazione strutturata tra persona-0001 e luogo-0002. I tipi di relazione rilevanti includono, ad esempio:

• appartiene a
• è gestito da
• è offerto da
• è disponibile presso
• è responsabile di
• marca usata
• prestazioni dimostrate
• è un percorso di contatto per

Fase 5: Identificare le fonti principali

Non tutti i campi devono necessariamente provenire dallo stesso sistema. I dati legali dell'azienda possono provenire dal sistema amministrativo, i prezzi dei prodotti dal sistema ERP e i testi brevi approvati dal sistema del sito web. Il punto cruciale è che ogni campo importante abbia esattamente un sistema di origine principale.

Il sito web può visualizzare dei dati, ma non dovrebbe essere automaticamente la fonte di tutte le informazioni. È preferibile un sistema di fonti centralizzato in cui le modifiche vengono decise e controllate da esperti.

Passaggio 6: Definire la logica del linguaggio

Un sito web multilingue non necessita di una copia completa di tutti i record di dati. È preferibile suddividere le proprietà del modello dati dell'entità in due gruppi:

• Valori indipendenti dalla lingua: ID stabile, numero di telefono, coordinate geografiche, indirizzo e-mail, rapporto organizzativo e numero di articolo interno.
• Valori dipendenti dalla lingua: Nome, breve descrizione, descrizione del servizio, qualifica professionale, URL, invito all'azione e, se applicabile, informazioni sugli orari di apertura.

Una traduzione non dovrebbe diventare un'entità separata. "Brand consulting" e "consulenza di marca" sono due valori linguistici per lo stesso servizio. Tuttavia, l'architettura dell'informazione e l'intento di ricerca devono essere pianificati separatamente per ogni lingua, come spiego nella guida alla SEO multilingue per siti web.

Fase 7: Regolare la manutenzione e il rilascio

Definisci un ruolo professionalmente responsabile per ogni tipo di entità. Ad esempio, il team di gestione potrebbe essere responsabile dei dati organizzativi, il responsabile marketing del marchio e il responsabile della sede degli orari di apertura e dei metodi di contatto locali.

Per molte PMI è sufficiente un processo di manutenzione ben definito:

• Si richiede una modifica.
• La persona responsabile verifica la correttezza tecnica.
• Vengono aggiunte o aggiornate le varianti linguistiche.
• Il record di dati verrà rilasciato.
• Il sito web e gli altri canali adotteranno la versione rilasciata.
• Le modifiche e le date dei test sono documentate.

Modello dati entità: esempio di un'azienda altoatesina

Il seguente modello semplificato di dati di entità descrive un'attività artigianale multilingue fittizia. Questo esempio non è un modello di produzione completo, ma piuttosto un punto di partenza per la modellazione individuale.

I set di dati centrali

• Organizzazione org-0001: Alpenwerk Holz GmbH ha sede legale a Bolzano.
• Marchio-0001: Alpenwerk, gestito da org-0001.
• Posizione place-0001: Workshop Bolzano, appartenente a org-0001.
• Posizione place-0002: Lo showroom Merano appartiene all'organizzazione org-0001.
• Persona persona-0001: Maria Huber, amministratrice delegata e responsabile della consulenza.
• Servizio servizio-0001: Progettazione d'interni su misura, offerta da org-0001.
• Prodotto prodotto-0001: Serie di mobili Larix, offerta con il marchio 0001.
• Riferimento riferimento-0001: Progettazione degli interni dell'Hotel Bergblick, servizio occupato-0001.
• Metodo di contatto contact-0001: Indirizzo email generico per la lingua tedesca e italiana.
• Metodo di contatto contact-0002: Numero di telefono dello showroom Merano durante gli orari di apertura locali.

Una voce di entità per il servizio

{
  "id": "service-0001",
  "canonicalName": {
    "de": "Innenausbau nach Maß",
    "it": "Arredamento su misura"
  },
  "provider": "org-0001",
  "availableAt": ["place-0001", "place-0002"],
  "responsiblePerson": "person-0001",
  "references": ["reference-0001"],
  "sourceSystem": "company-content",
  "status": "approved",
  "reviewedAt": "2026-02-15"
}

Il dataset separa identità, lingua e relazione. La correzione del nome italiano non modifica l'ID stabile né il collegamento all'organizzazione, alla persona o ai luoghi.

Quale entità necessita di una pagina dedicata?

Non tutte le entità del modello dati delle entità necessitano di un URL pubblico. La decisione dipende dai vantaggi per gli utenti, i motori di ricerca e i processi aziendali.

Pagina personale

Una pagina dedicata è utile se l'entità ha un proprio intento di ricerca distinto, contenuti sufficienti e un chiaro passo successivo. Esempi tipici sono:

• Profilo dell'organizzazione o dell'azienda
• marchio importante
• Locale con orari di apertura e servizi propri.
• prestazioni chiave
• Prodotto che richiede chiarimenti
• ampio riferimento
• esperto di rilevanza pubblica

Modulo di contenuto riutilizzabile

Un modulo di contenuto è adatto per le informazioni che devono essere presenti su più pagine. Ciò include persone di contatto, orari di apertura, recapiti, brevi descrizioni dei servizi, mappe e informazioni sul marchio.

Il componente base non contiene una copia gestita manualmente. Accede allo stesso record di entità condiviso.

Solo set di dati strutturati

Alcune entità rimangono in secondo piano. Un canale di contatto tecnico, una responsabilità interna o una variante di nome archiviata potrebbero non richiedere una pagina visibile. Il record di dati rimane rilevante perché documenta le relazioni, le approvazioni e l'origine delle informazioni.

Dal modello dati delle entità a JSON-LD e Schema.org

Il modello dati interno dell'entità e JSON-LD hanno scopi diversi. Il modello dati dell'entità organizza la conoscenza della tua azienda. JSON-LD è un formato di output che consente di rendere disponibili informazioni selezionate in un formato leggibile da una macchina su un sito web.

Schema.org fornisce tipi e proprietà per questo scopo. Ad esempio, un'organizzazione interna può essere rappresentata come ` Organization` , una persona come ` Person` , una posizione come ` Place` , un servizio come ` Service` , un prodotto come ` Product` e un metodo di contatto come ` ContactPoint` . La scelta dei tipi e delle proprietà più appropriati in un caso specifico deve essere determinata esaminando l'intero set di dati.

L'ID interno "org-0001" può essere convertito in un ID web univoco. Il seguente codice JSON-LD abbreviato mostra la logica di base:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.alpenwerk.example/#organization",
      "name": "Alpenwerk Holz GmbH",
      "brand": {
        "@type": "Brand",
        "@id": "https://www.alpenwerk.example/#brand",
        "name": "Alpenwerk"
      },
      "location": [
        {
          "@id": "https://www.alpenwerk.example/standorte/bozen/#place"
        },
        {
          "@id": "https://www.alpenwerk.example/standorte/meran/#place"
        }
      ],
      "contactPoint": {
        "@type": "ContactPoint",
        "@id": "https://www.alpenwerk.example/#contact-general",
        "contactType": "customer service",
        "availableLanguage": ["de", "it"]
      }
    },
    {
      "@type": "Service",
      "@id": "https://www.alpenwerk.example/leistungen/innenausbau/#service",
      "name": "Innenausbau nach Maß",
      "provider": {
        "@id": "https://www.alpenwerk.example/#organization"
      }
    }
  ]
}

Il valore @id collega oggetti correlati senza ripetere tutte le informazioni in ogni punto. Google descrive il collegamento di elementi correlati contrassegnati separatamente sulla stessa pagina tramite @id . Ciò non implica un requisito generale per ID univoci su più pagine. Fonte: Google Search Central.

Per la tua architettura, gli ID web utilizzati in modo permanente rimangono utili se più pagine o sistemi fanno riferimento alla stessa entità. Questa decisione deriva dal tuo modello dati delle entità e non da un tentativo di replicare il formato di un motore di ricerca.

Prima e dopo: cosa cambia con il modello dati delle entità

In precedenza: le informazioni venivano gestite per pagina

• Il nome dell'azienda compare sul sito web con diverse grafie.
• Gli orari di apertura vengono modificati separatamente nel piè di pagina, nella pagina dei contatti e nella pagina della posizione.
• Le versioni tedesca e italiana esistono come copie sostanzialmente indipendenti del contenuto.
• Una persona che se ne va rimane visibile come persona di contatto nei vecchi riferimenti.
• JSON-LD contiene valori diversi rispetto al contenuto visibile della pagina.
• Non è specificato quale versione sia vincolante.

In seguito: le entità forniscono i valori di collegamento.

• Sia l'organizzazione che il marchio possiedono un'identità stabile e un nome canonico.
• Ogni sede gestisce autonomamente il proprio indirizzo, gli orari di apertura e i metodi di contatto.
• I valori neutri rispetto alla lingua vengono mantenuti una sola volta; i testi ricevono varianti linguistiche controllate.
• I servizi sono associati a fornitori, persone, luoghi e referenze.
• I componenti della pagina e JSON-LD accedono ai dati delle entità condivise.
• Il sistema di origine e la responsabilità sono documentati per ogni tipo di entità.

Nella mia esperienza, il vantaggio più importante non risiede nella struttura tecnica, bensì nella chiarezza dei processi: una modifica viene decisa una volta, verificata una volta e poi implementata in modo coerente.

Modello di dati delle entità: lista di controllo per le PMI

• L'organizzazione e il marchio dispongono di set di dati separati se non sono identici?
• Ogni entità importante possiede un ID stabile?
• Esiste un nome canonico definito per ogni entità?
• I nomi alternativi e precedenti sono documentati?
• Persone, luoghi, servizi, prodotti e riferimenti sono collegati tra loro?
• Per ogni campo centrale è definito un sistema di riferimento principale?
• I valori indipendenti dalla lingua e quelli dipendenti dalla lingua sono distinti?
• Ogni sede ha orari di apertura e modalità di contatto diversi?
• La responsabilità per l'installazione, il collaudo e l'omologazione è regolamentata?
• Esiste uno stato aggiornato e una data dell'ultima ispezione?
• Il contenuto visibile e l'output leggibile dalla macchina corrispondono?
• Le entità archiviate verranno conservate anziché riutilizzare i loro ID per nuovi oggetti?

Domande e risposte sul modello dati delle entità

Quale formato di documento d'identità è più adatto a una PMI?

Spesso è sufficiente un formato semplice e permanente come org-0001 , place-0001 o un UUID controllato. Il punto cruciale è che l'ID rimanga univoco, non venga tradotto e persista anche dopo un cambio di nome.

Ogni lingua ha bisogno di una propria entità?

No. "Brand consulting" e "Consulenza di marca" sono generalmente termini che dipendono dalla lingua per indicare lo stesso servizio. Entrambi i valori linguistici si riferiscono quindi allo stesso ID stabile, mentre testi, URL e metadati vengono gestiti separatamente per ciascuna lingua.

Cosa succede quando si cambia nome?

Il nuovo nome canonico sostituisce il nome primario precedente, mentre l'ID stabile rimane invariato. È necessario documentare il vecchio nome come designazione alternativa o precedente e reindirizzare gli URL interessati in modo controllato.

Ogni località richiede un proprio set di dati?

Sì, non appena l'indirizzo, gli orari di apertura, le modalità di contatto, i servizi offerti o l'area di competenza differiscono. Una registrazione separata della sede impedisce che le informazioni locali vengano accidentalmente trasferite a tutte le filiali.

Chi dovrebbe essere responsabile dei dati relativi alle entità?

La responsabilità ricade sul ruolo tecnicamente competente, non automaticamente sulla persona che gestisce il sistema del sito web. La direzione può divulgare i dati aziendali, mentre i gestori del sito sono responsabili degli orari di apertura e delle informazioni di contatto locali.

Con quale frequenza le aziende dovrebbero essere sottoposte a revisione contabile?

I dati soggetti a modifiche, come persone di contatto, orari di apertura e modalità di contatto, devono essere verificati dopo ogni modifica rilevante e, inoltre, a intervalli prestabiliti. Per i dati anagrafici stabili, una verifica annuale documentata rappresenta una linea guida pratica che deve essere adattata alle specifiche esigenze aziendali.

Un modello di dati a entità è la stessa cosa di un modello di dati strutturato?

No. Il modello dati delle entità (Entity Data Model, LD) rappresenta l'organizzazione interna delle conoscenze aziendali, mentre i dati strutturati sono un output selezionato e leggibile automaticamente per il sito web. Un markup JSON-LD tecnicamente corretto non può compensare in modo permanente un modello dati interno inadeguato.

Una piccola azienda ha davvero bisogno di un software complesso per questo?

No. Una piccola o media impresa (PMI) può iniziare con una struttura dati controllata, ID univoci e responsabilità chiaramente definite. Il software viene selezionato solo dopo che entità, fonti, linguaggi e processi di manutenzione sono stati definiti in modo professionale.

Prima il modello dati dell'entità, poi l'automazione

Un modello di dati di entità non è fine a se stesso. Il modello dovrebbe far risparmiare tempo alla tua azienda, ridurre gli errori e fornire informazioni affidabili sia per le persone che per le macchine.

Pertanto, non partite da JSON-LD, plugin o automazione basata sull'IA. Partite dagli elementi concreti della vostra attività: qual è l'organizzazione legale che si cela dietro l'attività? Quale marchio utilizzate? Chi è responsabile di quale servizio? Cosa offre ogni sede? Quale canale di contatto è destinato a quale scopo?

Una volta ottenute risposte definitive a queste domande, potremo utilizzarle, nell'ambito della nostra strategia per il sito web e dello sviluppo tecnico , per costruire un sistema in grado di gestire e riutilizzare i contenuti in modo affidabile. Il risultato per l'azienda sarà una minore duplicazione dei contenuti, responsabilità più chiare e informazioni coerenti per clienti, motori di ricerca e sistemi di intelligenza artificiale.