Gli schema graph sono il punto centrale della meta-conoscenza legata alle history delle versioni. Come mostrato nella figura 5.8, la loro composizione è abbastanza complessa ma perfettamente riconducibile alla definizione data in precedenza. Ogni schemaGraph è formato da un solo fact node (factNode) e da una sequenza potenzialmente infinita di misure, proprietà e dipendenze funzionali.
All'interno di una history il fatto d'interesse non può cambiare, ciò nonostante si è deciso di salvare il fact node in ogni schema graph ed ogni schema aumentato. Questa scelta è dovuta all'utilizzo delle query XPath all'interno dell'applicativo per la gestione delle dipendenze funzionali. Questa ridondanza viene controllata a livello implementativo nel codice di DWers, e non crea problemi dal momento che non viene mai permessa nessun modifica al nodo del fatto.
E' importante notare come vengono gestiti gli attributi all'interno degli schema graph, perché non è stato definito nessun elemento generico che li rappresenta.
Il rapporto con lo schema logico dello schema graph dipende dalle scelte implementative fatte sul database relazionale, i cui dati per la connessione andranno inseriti in un file a parte oppure attraverso una estensione del XML Schema qui presentato. In ogni caso, se è possibile scegliere il nome delle relazioni in maniera autonoma, sia che si lavori su un repository single-pool sia che si scelga un multi-pool sarà possibile determinare in maniera univoca le tabelle coinvolte. In caso contrario, sarà necessario inserire altri dati che permettano di far corrispondere i nodi degli attributi al loro repository.