In una frase
Questo documento mette in fila le osservazioni strutturali sul DB NewAge: come è organizzato il dato anagrafico, dove si producono ridondanze e potenziali conflitti, quali logiche CRUD governano oggi il ciclo di vita del dato, quali criticità conseguono per un sistema a valle come il CRM.
È un documento diagnostico con implicazioni per il DUC: fotografa le criticità della base dati attuale e alimenta le regole che il DUC dovrà formalizzare e far validare dal business nelle fasi successive.
Il DB NewAge non è "fatto male"
È coerente con tre logiche storiche legittime. Il problema non è la qualità intrinseca del DB: è che queste tre logiche non favoriscono una vista CRM centrata sul soggetto.
- Logica di polizza Il business è stato costruito attorno al contratto assicurativo.
- Logica di produttore / punto vendita La rete è il canale attraverso cui il cliente entra.
- Vincoli legali e di business la struttura attuale risponde ad anni di evoluzione organizzativa e normativa.
L'analisi dell'estrazione Estrazione_Anagrafica_trasposta.02.xlsx ha chiarito che il dato anagrafico in NewAge vive su due livelli sovrapposti, fisicamente distinti.
Una sola copia per soggetto, visibile a tutti
- persona_fisica
- persona_giuridica
- soggetto_anagrafica_* (contatti, consensi, professione, animali, mezzi, sport, convenzioni, dati economici…)
Una copia per ogni coppia (punto vendita, produttore)
- cliente (indirizzo, comune, provincia, telefono_portatile, e_mail, IBAN inline)
- conto_corrente (tabella normalizzata dei rapporti bancari)
(cod_punto_vendita, cod_produttore). Lo stesso codice fiscale, se gestito da più punti vendita o produttori, compare come più "clienti" diversi nella tabella cliente.
F · 01 · Chiavi multiple
Convivono tre identificatori del soggetto
codice_fiscale, id_soggetto_anagrafica e codice_cliente (UUID, N per soggetto) coesistono senza che nessuno sia designato come chiave canonica. Ogni parte del sistema usa quella più comoda per il proprio scopo.
▶ dettaglio
codice_fiscale, id_soggetto_anagrafica e codice_cliente (UUID, N per soggetto) coesistono senza che nessuno sia designato come chiave canonica. Ogni parte del sistema usa quella più comoda per il proprio scopo.Tre identificatori, nessuno canonico: codice_fiscale (chiave naturale del soggetto fisico), id_soggetto_anagrafica (chiave tecnica 1:1 per soggetto, usata dalle tabelle L1), codice_cliente UUID (chiave della coppia soggetto+produttore: N per soggetto). Ogni parte del sistema usa quella più comoda: le polizze usano codice_fiscale o codice_cliente a seconda del tipo, le tabelle anagrafica usano id_soggetto_anagrafica, il CRM si appoggia a codice_cliente che però moltiplica il soggetto per produttore.
Il DUC deve scegliere e formalizzare una chiave primaria del soggetto. La candidata naturale è id_soggetto_anagrafica: è già 1:1 con il soggetto reale e collega le tabelle L1. Il codice_fiscale ha eccezioni (soggetti esteri, omonimie tecniche). Il codice_cliente non va mai usato come chiave del soggetto perché moltiplica.
Senza una chiave canonica, ogni sistema a valle (CRM, app agenzia, Viki) costruisce la propria euristica di deduplicazione. Oggi accade già: si producono "attribuzioni euristiche" a monte delle estrazioni per evitare duplicati. Il DUC deve rendere quella logica esplicita e condivisa, non lasciarne una copia per ogni sistema a valle.
F · 02 · Centralità operativa di cliente
Il fulcro quotidiano del sistema, non una tabella anagrafica
La tabella cliente lega soggetto + punto vendita + produttore: una riga per coppia. Le scritture operative avvengono qui, ma non è la fonte autoritativa del dato del soggetto, ovvero quella della relazione commerciale specifica.
▶ dettaglio
clientecliente lega soggetto + punto vendita + produttore: una riga per coppia. Le scritture operative avvengono qui, ma non è la fonte autoritativa del dato del soggetto, ovvero quella della relazione commerciale specifica.Una riga per coppia (soggetto, punto vendita, produttore). Lo stesso soggetto gestito da tre produttori ha tre righe cliente, potenzialmente con valori diversi su ogni campo. È il punto di attacco principale per le scritture operative, ma non è la fonte autoritativa del dato anagrafico del soggetto: lo è della relazione commerciale specifica.
Il CRM ha bisogno di una vista per testa, ovvero una sola riga per soggetto. Ma cliente ha per design N righe per soggetto. Il DUC deve definire una regola di prevalenza esplicita: quale record cliente prevale per il CRM? Il produttore principale? Il più recente? Il produttore con la polizza attiva più rilevante? Oggi questa scelta non è documentata: viene fatta implicitamente nelle estrazioni.
Se il CRM si aggancia a cliente senza regola di prevalenza, può mostrare dati diversi per lo stesso soggetto a seconda di chi lo interroga, o aggregare valori sbagliati (es. comunicare su un'email che appartiene alla relazione con produttore X ma non è il contatto principale per quel soggetto).
F · 03 · Collegamento soggetto-polizza non omogeneo
Quattro tabelle, quattro modi di legare il cliente
polizza_persona_azienda ha una FK diretta su codice_cliente. Le altre tre passano obbligatoriamente da matrice_polizze_clienti. Senza questa tabella ponte, le polizze auto e patrimonio di un soggetto diventano invisibili.
▶ dettaglio
polizza_persona_azienda ha una FK diretta su codice_cliente. Le altre tre passano obbligatoriamente da matrice_polizze_clienti. Senza questa tabella ponte, le polizze auto e patrimonio di un soggetto diventano invisibili.polizza_persona_azienda ha FK diretta su cliente.codice_cliente. polizza_auto, polizza_patrimonio_bene e polizza_infortuni_malattia (per ruolo contraente/assicurato) non hanno FK esplicita: il collegamento passa obbligatoriamente da matrice_polizze_clienti. polizza_infortuni_malattia è ibrida: nessuna FK per contraente/assicurato, ma una FK dedicata per il beneficiario (codice_cliente_beneficiario). Da verificare con IT: polizza_persona_azienda.codice_cliente è tipizzato varchar(16) mentre cliente.codice_cliente è uuid: possibile artefatto dell'estrazione. dell'estrazione.
Per ricostruire "tutte le polizze di un soggetto" servono logiche diverse a seconda del tipo. Se il DUC non astrae questa eterogeneità in una vista unificata, ogni sistema a valle deve reimplementare la stessa logica, con il rischio che qualcuno salti il passaggio da matrice_polizze_clienti e perda polizze.
Vista incompleta del portafoglio del cliente: un sistema che si aggancia solo alle FK dirette non vede le polizze auto e patrimonio di quel soggetto. È già un rischio concreto nelle estrazioni ad hoc realizzate senza conoscere a fondo lo schema.
F · 04 · Asimmetria PF / PG
Persone fisiche e persone giuridiche non sono interscambiabili
persona_fisica e persona_giuridica non sono due istanze dello stesso pattern: portano strutture, logiche e livelli di ridondanza diversi. Un golden record unico non è applicabile a entrambe.
▶ dettaglio
persona_fisica e persona_giuridica non sono due istanze dello stesso pattern: portano strutture, logiche e livelli di ridondanza diversi. Un golden record unico non è applicabile a entrambe.persona_fisica ha molti campi inline snapshot, duplicati delle tabelle soggetto_anagrafica_* corrispondenti. persona_giuridica è più snella sui duplicati inline, ma porta logiche proprie: forma giuridica tramite ponte molti-a-molti con id distinti per varianti semanticamente simili (es. ATI e RTI); legami societari con capogruppo e percentuali di partecipazione in soggetto_anagrafica_persona_giuridica_legame, con date di effetto/uscita. Nessuna di queste strutture ha un equivalente nel mondo PF.
Non si può costruire un modello unico di golden record applicabile indifferentemente a PF e PG. Il DUC dovrà avere: golden record PF (principalmente da L1: persona_fisica + tabelle soggetto_anagrafica_*, con regole di prevalenza su contatti, professione e consensi) e golden record PG (struttura societaria, forma giuridica riconciliata risolvendo le varianti ATI/RTI e simili, legami con capogruppo).
Se il CRM tratta PF e PG con lo stesso template di profilo, o perde dati rilevanti per la PG (struttura societaria, legami), o mostra campi vuoti e irrilevanti per la PF (percentuali di partecipazione). È un problema di modellazione del golden record, non di qualità del dato.
F · 05 · Storico non sistemico
Lo storico è ricomponibile a tratti e non in modo uniforme
Il DB ha quattro regimi di storico: versionato per data di validità (professione, consenso, legami PG), tracciato con timestamp ma senza versioning del valore (la maggior parte delle soggetto_anagrafica_*), frozen per legge (polizze), nessun versioning (campi inline di persona_fisica e persona_giuridica).
▶ dettaglio
soggetto_anagrafica_*), frozen per legge (polizze), nessun versioning (campi inline di persona_fisica e persona_giuridica).Quattro regimi non uniformi, sedimentati per ragioni diverse:
- Versionato per data di validità:
soggetto_anagrafica_professione,soggetto_anagrafica_consenso,soggetto_anagrafica_persona_giuridica_legame: si conserva il valore cambiato e il periodo di validità. - Timestamp senza versioning del valore: la maggior parte delle
soggetto_anagrafica_*: si sa quando è cambiato qualcosa, non cosa era prima. - Frozen per vincolo legale: tutte le tabelle polizza: il valore alla firma è immutabile.
- Nessun versioning: campi inline di
persona_fisicaepersona_giuridica: sovrascrittura diretta, il passato non è recuperabile.
Il DUC non può promettere al CRM una customer journey storica se la materia prima non è versionata. Tre implicazioni pratiche: i trigger su variazioni (es. "cliente ha cambiato professione") funzionano solo sui campi versionati; le analisi temporali ("quanti clienti hanno cambiato indirizzo nell'ultimo anno?") sono impossibili dove persona_fisica sovrascrive; il DUC dovrà decidere esplicitamente per quali attributi introduce versioning da qui in avanti, perché non può versionare tutto retroattivamente.
Senza intervento, il CRM nasce già storicamente cieco su gran parte degli attributi del soggetto. Il lifecycle marketing (campagne basate su variazioni di stato) funziona solo sui pochi campi già versionati. È una limitazione che il DUC può mitigare per il futuro, ma non eliminare: il passato già scritto in sovrascrittura non è ricostruibile.
I dati anagrafici contenuti nelle polizze (professione, animali, mezzi, dati socio-demo del nucleo, indirizzo dell'immobile assicurato, beneficiari, ecc.) sono congelati al momento della firma, per vincolo legale e per ricostruibilità in sede di sinistro. Questo è corretto e necessario lato compagnia.
Le conseguenze rilevanti per il dato sono però significative:
Tre codifiche di professione coesistono e non sono mappabili tra loro
Evidenza da schema, confermata in SAL 21/05/2026. La tripletta anagrafica (cod_professione_anagrafica + cod_qualifica_professione + cod_settore_professione) serve al censimento. cod_professione_per_auto è la codifica ANIA usata in polizza_auto per la tariffazione. cod_professione_re è la codifica specifica del ramo RE / persona azienda. Scopi e contesti sono diversi e non c'è una tabella di corrispondenza diretta.
Nessun meccanismo di propagazione polizza → anagrafica
Se un cliente cambia professione e l'aggiornamento avviene solo all'interno di una nuova polizza, la tripletta in anagrafica resta quella vecchia. Lo stesso vale per indirizzo, dati socio-demo, animali, mezzi.
Esempi concreti di disallineamento
Un animale censito in una polizza pet potrebbe non risultare in soggetto_anagrafica_animale. Un immobile assicurato in polizza_patrimonio_bene ha un indirizzo che può differire dalla residenza in cliente.
Questa asimmetria rende complesso avere una fotografia aggiornata e completa della situazione di una persona.
Prima di mappare le ridondanze, conviene distinguere come sono fatte. Le tre forme che seguono richiedono trattamenti diversi nel DUC: la prima va validata o modificata, la seconda va riconciliata semanticamente, la terza va risolta con regole di prevalenza.
cliente: il sistema è progettato così, ogni produttore mantiene la propria copia. Non è un errore.
A
Interne al Livello 1 · anagrafico unico
Pattern: persona_fisica contiene un campo inline singolo ("fotografia del valore corrente"); la tabella soggetto_anagrafica_* corrispondente contiene la versione completa e/o storicizzata. Per il CRM la fonte autoritativa è quasi sempre la tabella dedicata.
fisiologica prevalente
conflitto op. su contatti
conflitto sem. su forma giuridica
▶ dettaglio
Interne al Livello 1 · anagrafico unico
persona_fisica contiene un campo inline singolo ("fotografia del valore corrente"); la tabella soggetto_anagrafica_* corrispondente contiene la versione completa e/o storicizzata. Per il CRM la fonte autoritativa è quasi sempre la tabella dedicata.| Categoria | Tabelle coinvolte | Quante copie esistono | Storico | Tipo | Regola di prevalenza nota |
|---|---|---|---|---|---|
| Contatti | persona_fisica ↔ soggetto_anagrafica_contatto | Un solo valore nel profilo base; fino a 18 voci nella scheda contatti dedicata | timestamp creazione/variazione; no validità | conflitto op. i contatti vivono su 4 livelli (NewAge per-relazione, AR ad anagrafica unica, consensi certificati, contrattuali SDD), con cardinalità reale ben oltre i 7 valori | "più recente per data" sulla dedicata (operativa, dal 2026); non è l'unica regola in gioco |
| Consensi | persona_fisica ↔ soggetto_anagrafica_consenso ↔ cliente_dettaglio (mktg) | Un flag nel profilo base; fino a 10 voci nella scheda consensi dedicata | sì (date inizio/fine validità) | conflitto op. + issue flag/documento | "più recente per data di aggiornamento" |
| Professione (tripletta) | persona_fisica ↔ soggetto_anagrafica_professione | Un solo valore corrente nel profilo; più voci con storico nella scheda professione | sì (date validità nella storica) | fisiologica snapshot + storico | scrittura su tripletta anagrafica via VCT |
| Composizione familiare | persona_fisica ↔ soggetto_anagrafica_dato_economico | Una sola copia, conservata in due posti distinti | parziale | fisiologica | non documentata |
| Dati economico-reddituali (MiFID) | persona_fisica ↔ soggetto_anagrafica_dato_economico | Una sola copia, conservata in due posti distinti | parziale | fisiologica | non documentata |
| Immobili anagrafici (numero, mutui, locazione) | persona_fisica ↔ soggetto_anagrafica_dato_economico | Una sola copia, conservata in due posti distinti | parziale | fisiologica | non documentata |
| Titolo di studio | persona_fisica ↔ soggetto_anagrafica_dato_economico | Una sola copia, conservata in due posti distinti | parziale | fisiologica | non documentata |
| Animali domestici | persona_fisica ↔ soggetto_anagrafica_animale | Un campo riassuntivo nel profilo; lista completa nella scheda animali | no versioning, solo timestamp | fisiologica | non documentata |
| Mezzi di trasporto anagrafici | persona_fisica ↔ soggetto_anagrafica_mezzo_trasporto | Un campo riassuntivo nel profilo; lista completa nella scheda mezzi | no versioning | fisiologica | non documentata |
| Saldo punti / fedeltà | persona_fisica ↔ soggetto_anagrafica_saldo_punti ↔ soggetto_anagrafica_movimento | Un saldo aggiornato nel profilo + lista storica di tutti i movimenti | sì (movimenti datati) | fisiologica | saldo riconciliabile con i movimenti; regola non documentata |
| Stato validazione contatto | persona_fisica ↔ soggetto_anagrafica_contatto | Un flag nel profilo; ogni contatto ha il proprio stato di validazione | no | conflitto op. a quale contatto si riferisce il dato in persona_fisica? | non documentata |
| Coperture altre compagnie | persona_fisica ↔ soggetto_anagrafica_altra_copertura | Un campo nel profilo; lista con note per ogni copertura esterna | no versioning | fisiologica | non documentata |
| Legami familiari | persona_fisica ↔ persona_fisica_legame | Un campo nel profilo; lista dei legami familiari nella scheda dedicata | no versioning | fisiologica tabella di legami | non documentata |
| Legami PG | persona_giuridica ↔ soggetto_anagrafica_persona_giuridica_legame | Un campo nel profilo; lista dei legami societari con date di entrata/uscita | sì (date effetto/uscita) | fisiologica | non documentata |
| Forma giuridica PG | persona_giuridica ↔ tipo_persona_forma_giuridica ↔ tipo_forma_giuridica | Un codice identificativo; può corrispondere a più etichette formali (es. ATI e RTI classificate separatamente) | no | conflitto sem. es. ATI e RTI con id distinti sotto stessa coppia | non documentata |
| Sport | soggetto_anagrafica_sport | Solo nella scheda dedicata; una voce per ogni sport | no versioning | vedi anche cat. C | non documentata |
| Convenzioni | soggetto_anagrafica_convenzione | Solo nella scheda dedicata; una voce per ogni convenzione | no versioning | multi-riga; nessun conflitto polizza dimostrato | non documentata |
B
Tra Livello 2 (pv_produttore) e Livello 1
Pattern: il Livello 2 mantiene una propria copia operativa di alcuni dati di contatto/identità, distinta per produttore. È ridondanza fisiologica per design.
fisiologica per produttore
conflitto op. sul "produttore autoritativo"
▶ dettaglio
Tra Livello 2 (pv_produttore) e Livello 1
| Categoria | Tabelle coinvolte | Quante copie esistono | Storico | Tipo | Regola di prevalenza nota |
|---|---|---|---|---|---|
| Indirizzo / residenza | cliente ↔ dati di residenza nelle polizze | Una copia per ogni agente/produttore che gestisce il cliente; più copie nelle polizze (cristallizzate alla firma) | no versioning in cliente; cristallizzato in polizza | fisiologica per produttore + conflitto op. quale produttore è la fonte? | non documentata |
| Contatti operativi | cliente.telefono_portatile, cliente.e_mail ↔ persona_fisica inline ↔ soggetto_anagrafica_contatto | Una copia per ogni agente/produttore; lista separata nella scheda contatti unica del soggetto | parziale | fisiologica (L2) + conflitto op. (L1) | "più recente per data" sulla dedicata |
| IBAN / dati bancari | cliente (campi inline IBAN per produttore) ↔ conto_corrente | Una copia per ogni agente/produttore; lista separata di conti correnti per il soggetto | no versioning | fisiologica un soggetto può avere IBAN diversi per produttori diversi | non documentata |
C
Tra anagrafica e polizze
Pattern: ogni polizza contiene campi anagrafici cristallizzati alla firma. Il dato esiste anche in anagrafica, ma può divergere senza che il sistema lo riconcili.
fisiologica per legge
conflitto sem. su codifiche e granularità
conflitto op. su animali e sport
▶ dettaglio
Tra anagrafica e polizze
| Categoria | Tabelle coinvolte | Quante copie esistono | Storico | Tipo | Regola di prevalenza nota |
|---|---|---|---|---|---|
| Identità base (nascita, sesso, età, luogo, beneficiario) | persona_fisica ↔ campi nelle polizze (data_nascita_intest_pra, sesso_intestatario_pra, ecc.) ↔ polizza_infortuni_malattia (cognome/nome/CF beneficiario) | Una nell'anagrafica; una copia cristallizzata alla firma in ogni polizza | cristallizzato alla firma | fisiologica per legge | nessuna propagazione |
| Professione | tripletta anagrafica ↔ cod_professione_per_auto (ANIA) in polizza_auto ↔ cod_professione_re in polizza_patrimonio_bene e polizza_persona_azienda | Una nell'anagrafica; una copia per ogni tipo di polizza (con codifiche diverse e non confrontabili) | cristallizzato | conflitto sem. 3 codifiche, scopi diversi, non mappabili | nessuna propagazione |
| Indirizzo | cliente (residenza) ↔ polizza_patrimonio_bene.indirizzo (immobile) ↔ polizza_auto (CAP, comune intestatario) ↔ polizza_persona_azienda (provincia) | Una per ogni agente/produttore; una per ogni polizza (es. residenza vs. immobile assicurato possono differire) | cristallizzato alla firma | fisiologica residenza ≠ immobile | (168.634 contraenti con immobile ≠ residenza) |
| Animali domestici | persona_fisica / soggetto_anagrafica_animale ↔ polizze pet | Più voci nell'anagrafica; una copia separata in ogni polizza pet (le due liste possono non coincidere) | cristallizzato | conflitto op. animale in polizza può non essere in anagrafica | nessuna propagazione |
| Veicoli | persona_fisica / soggetto_anagrafica_mezzo_trasporto ↔ polizza_auto (targa, telaio, marca, modello, cv, peso, anno…) | Più voci nell'anagrafica; una copia più dettagliata in ogni polizza auto | cristallizzato | conflitto sem. livello di dettaglio diverso | nessuna propagazione |
| Immobili | persona_fisica / soggetto_anagrafica_dato_economico (numero, mutui) ↔ polizza_patrimonio_bene (indirizzo, anno, piani, unità abitative) | Un dato riepilogativo nell'anagrafica; dettaglio completo per ogni polizza immobile | cristallizzato | conflitto sem. granularità diversa | nessuna propagazione |
| Beneficiari di polizza | solo polizza_infortuni_malattia (cognome, nome, CF, codice_cliente beneficiario) | Solo all'interno di ogni polizza; nessuna copia nell'anagrafica del soggetto | cristallizzato | conflitto sem. beneficiario è un soggetto, ma vive solo nella polizza | nessuna propagazione |
| Attività sportive / convenzioni | soggetto_anagrafica_sport, soggetto_anagrafica_convenzione ↔ campi sport in polizza_infortuni_malattia | Più voci nell'anagrafica; una copia separata in ogni polizza infortuni (le due liste possono non coincidere) | cristallizzato | conflitto op. sport in anagrafica vs sport in polizza | nessuna propagazione |
Osservazioni trasversali
persona_fisica sono un pattern ricorrente, non eccezioni. Sono snapshot del valore corrente, sovrascritti a ogni aggiornamento. La fonte autoritativa per il CRM è quasi sempre la tabella soggetto_anagrafica_* corrispondente.Da agenzia/agente via VCT o emissione polizza
Le scritture avvengono principalmente tramite gli strumenti operativi di compagnia (VCT, schede anagrafiche, fasi di emissione polizza). In alcuni touchpoint il cliente può inserire o modificare direttamente alcuni dati (es. area riservata, OTP).
Condizionata dai livelli di visibilità di rete
Lo stesso dato del Livello 2 è leggibile in modo diverso a seconda del produttore richiedente. La visibilità segue i livelli di rete (L1/L2 e oltre).
Tre regimi diversi, con eccezioni note sui contatti
L2 (cliente): write locale al produttore, senza propagazione cross-produttore. È design.
L1 inline (persona_fisica): prevale la sovrascrittura del valore corrente; le tabelle soggetto_anagrafica_* conservano la storia quando hanno date di validità.
Polizze: per definizione non si aggiornano dopo la firma, salvo appendici.
Eccezioni sui contatti (da documentazione contatti e comunicazioni):
Contatti AR ad anagrafica unica: se modificati da Area Riservata vengono salvati a livello di anagrafica unica e contro-aggiornati su tutti i cliente del soggetto. È un'eccezione alla regola L2.
Contatti consensi (OTP, grafometrica): aggiornabili solo da NewAge; da AR si può cambiare solo il cellulare OTP.
Contatti contrattuali (SDD): legati al singolo contratto, l'aggiornamento non impatta altri contatti.
Nel perimetro osservato prevale la cancellazione logica
Campo data_cancellazione sulle tabelle soggetto_anagrafica_*. Non è stato verificato se esistano flussi di cancellazione fisica e in quali condizioni.
Regole di prevalenza note
- Contatto del soggetto: "più recente per data". Regola operativa introdotta a inizio 2026 a livello di estrazione per marketing automation, dopo problemi noti di comunicazioni non consegnate.
- Stato di certificazione del contatto: esiste un processo (validazione lineare in onboarding, validazione incrociata su modifica singola di email o cellulare) con stati
VALIDATO/IN ATTESA DI VALIDAZIONE/NON VALIDATO, finestra di 20gg con reminder a 10gg. La regola "più recente per data" applicata oggi a fini marketing non considera lo stato di certificazione. Vincolo hard noto sull'OTP: 1 codice fiscale = 1 numero di telefono; 1 numero di telefono = max 2 codici fiscali. - Consenso: "più recente per data di aggiornamento". Stessa logica, dichiarata nei flussi di marketing automation.
- Professione anagrafica: scrittura su tripletta del Livello 1 via VCT; le codifiche di polizza non vengono toccate.
- Dati pv_produttore: nessuna regola di prevalenza globale. Ogni produttore mantiene la propria copia.
Storico
- Versionato per data di validità:
soggetto_anagrafica_professione,soggetto_anagrafica_consenso,soggetto_anagrafica_persona_giuridica_legame. - Tracciato con timestamp ma senza versioning del valore: la maggior parte delle tabelle
soggetto_anagrafica_*(creazione, variazione, cancellazione). - Cristallizzato per vincolo legale: tutte le tabelle polizza.
- Nessun versioning: campi inline in
persona_fisicaepersona_giuridica(sovrascrittura).
VALIDATO / IN ATTESA / NON VALIDATO che oggi il "più recente per data" non considera.✓ Sì · in scope DUC
- Golden record per il Livello 1: riconciliazione tra produttori.
- Golden rules: regole di coerenza del dato da far validare dal business (commerciale e agenzie), non solo IT.
- Vista per testa: aggregazione cross-polizza per soggetto.
- Regole di visibilità esplicite per il Livello 2 (L1-L4), da co-progettare.
- Versioning dove serve al CRM.
✗ No · fuori scope DUC
- Qualità del dato a monte in NewAge.
- Bonifica completa degli ambienti NewAge esistenti: piano pluriennale, fuori Fase 1.
- Processo di allineamento flag/documento per i consensi: tema di compliance e processo, non di dato.
- Dati fossilizzati nelle polizze già firmate.
- Statistiche e dato certificato ANIA: restano in NewAge.
02_Analisi/DUC_Criticita_Struttura_DB_v1.md · documento sorgente di questi findings (v1.1, 25 mag 2026)01_Estrazioni/Estrazione_Anagrafica_trasposta.02.xlsx · fonte della distinzione Livello 1 / Livello 202_Analisi/chartdb/ChartDB20260525.dbml · schema NewAge aggiornato al 25/05/202602_Analisi/DUC_Principi_Clustering_v0.2.md · proposta di clustering e principi fondativi