Nei due esempi pubblicati da AWS il 20 ottobre 2026, Denodo federa fonti distribuite al momento della query, mentre AtScale esegue le query analitiche su un solo motore di data warehouse e descrive una replica a monte dei dati operativi. Se le risposte dell’agente devono combinare dati aggiornati che risiedono su sistemi diversi, il modello Denodo illustrato è quello più vicino a questa topologia; se i dati analitici sono già consolidati in un warehouse e la replica è parte dell’architettura, l’esempio AtScale è più pertinente.
Entrambi i tutorial collegano un agente Strands ospitato su Amazon Bedrock AgentCore a un layer semantico tramite Model Context Protocol (MCP). La differenza decisiva è dove vengono combinati i dati e come sono rappresentati i concetti aziendali.
| Dimensione | Esempio Denodo | Esempio AtScale |
| Dati interrogati | Amazon Aurora, Amazon Redshift e PostgreSQL on-premises, federati al momento della query tramite Virtual DataPort | Dati analitici in Amazon Redshift Serverless; i dati operativi di Aurora vengono replicati a monte |
| Confine della query | Virtual DataPort pianifica le query federate e combina i risultati delle fonti | Ogni query dimensionale viene risolta da un solo motore di warehouse |
| Modello semantico | Viste di base, una vista derivata e una vista separata per le metriche riutilizzabili; interrogazioni in VQL | Oggetti SML in YAML per dataset, dimensioni, fatti, misure, calcoli, prospettive e sicurezza a livello di riga; versionati in Git |
| Collegamento dell’agente | Il server MCP di Denodo collega l’agente a Virtual DataPort; AgentCore Gateway e Identity trasmettono l’identità tramite uno scambio di token On-Behalf-Of | Il server MCP di AtScale collega l’agente al modello; Gateway e Identity gestiscono le credenziali, mentre il motore AtScale risolve il ruolo del chiamante |
| Controlli illustrati | Una Global Security Policy maschera i campi sensibili contrassegnati per marketing_user; hr_user li vede senza mascheramento | Controllo degli accessi basato sui ruoli, sicurezza a livello di riga e prospettive; la prospettiva marketing esclude i campi SSN e numero di carta dell’esempio |
Il confine dei dati determina il modello di query
Il walkthrough Denodo descrive tre fonti: Amazon Aurora, Amazon Redshift e un database PostgreSQL on-premises. Virtual DataPort pianifica il lavoro tra i sistemi, invia le operazioni alle fonti e riunisce i risultati. Nell’esempio, quindi, il layer semantico non dipende da una tabella analitica unica che contenga già tutti i dati combinati.
L’esempio AtScale parte da una disposizione diversa: i dati analitici Customer 360 risiedono in Amazon Redshift Serverless e ciascuna query viene eseguita da un solo motore di warehouse. Il tutorial descrive la replica a monte dei dati operativi provenienti da Aurora. Per scegliere tra i due schemi, la domanda concreta è se le query dell’agente debbano unire fonti distribuite in tempo reale oppure possano lavorare sui dati analitici già raccolti nel warehouse.
Come vengono modellati metriche e concetti aziendali
Denodo usa viste di base per mappare le fonti, una vista derivata a livello di cliente e una vista distinta per le metriche riutilizzabili. Il tutorial descrive sei viste di base. Le query usano VQL, il linguaggio di Denodo Virtual DataPort.
AtScale rappresenta il modello dimensionale con oggetti YAML della Semantic Modeling Language (SML). Dataset, dimensioni, gerarchie, fatti, misure, calcoli, prospettive e regole di sicurezza a livello di riga fanno parte del modello, che viene versionato in Git. In entrambi gli esempi, definizioni aziendali e regole di accesso sono collocate nel layer semantico, invece di affidarsi soltanto alle istruzioni date al modello linguistico.
Identità, governance e audit
I due tutorial descrivono percorsi diversi per portare l’identità dell’utente fino al livello dei dati. Nell’esempio Denodo, AgentCore Gateway e Identity trasmettono l’identità con uno scambio di token On-Behalf-Of. In quello AtScale gestiscono il percorso delle credenziali e il motore AtScale applica il ruolo del chiamante.
I controlli di accesso illustrati non sono identici. Denodo maschera i campi sensibili etichettati ssn e card_num per marketing_user, mentre l’esempio hr_user li mostra senza mascheramento. AtScale combina accessi basati sui ruoli, sicurezza a livello di riga e prospettive; la prospettiva marketing esclude dal modello i campi SSN e numero di carta dell’esempio.
Il record di audit illustrativo di AtScale comprende sia il SQL dimensionale generato dal modello linguistico sia il SQL tradotto per Amazon Redshift. Include anche l’identità, le policy applicate, l’eventuale uso di aggregati e il numero di righe restituite. Nel walkthrough Denodo, l’audit descritto mette in evidenza la richiesta VQL, il ruolo associato, il piano federato e gli esiti delle policy.
I tutorial AWS riferiscono inoltre tre categorie di query e una nuova esecuzione con controlli di governance per ciascun esempio. Questi passaggi fanno parte delle dimostrazioni descritte nei rispettivi walkthrough.
Quale schema si adatta alla tua architettura?
Se l’agente deve interrogare insieme fonti cloud e sistemi on-premises senza spostare prima tutti i dati in un warehouse, la federazione illustrata da Denodo corrisponde a quel requisito. Se invece l’organizzazione mantiene già un warehouse analitico e un processo di replica verso di esso, l’esempio AtScale offre un modello dimensionale che risolve ogni query in un unico motore.
La scelta dipende quindi dalla collocazione dei dati e dal percorso con cui vengono aggiornati. I due walkthrough descrivono architetture e controlli specifici, non una misura comparativa delle prestazioni o della sicurezza in produzione.
