La struttura dati di X-Cross sfrutta appieno le funzionalità avanzate dei moderni database:
- Transazioni
- Integrità referenziale
- Stored procedures
- Triggers
- Viste
per la massima velocità operativa e affidabilità della struttura dati.
- I moderni database offrono un insieme di funzionalità che, tutte insieme, fanno sì che la struttura dei dati rispetti i cosiddetti criteri “ACID“:
- Atomica
- Coerente
- Isolata
- Durevole
Per una spiegazione di ACID, vedere: https://it.wikipedia.org/wiki/ACID.
Per rispettare questi criteri non è sufficiente che nel database siano presenti le funzionalità necessarie, ma anche l‘ERP deve farne pieno uso. Ad esempio, se il database offre la funzionalità di integrità referenziale, ma il programma non la utilizza, i criteri ACID non vengono rispettati.
In X-Cross, invece, i requisiti ACID del database vengono pienamente soddisfatti sfruttando appieno le funzionalità offerte.
Transazioni in inserimento-modifica-cancellazione
In X-Cross, tutti gli inserimenti e gli aggiornamenti dei record sono inclusi in un’unica transazione ed in un’unico statament SQ.
Ad esempio, l’inserimento-modifica di una transazione contabile per il database è una singola transazione.
Questa struttura garantisce che tutti gli inserimenti aggiornati abbiano esito positivo (“COMMIT”), oppure l’intera transazione venga annullata (“ROLLBACK”), ed in questo caso i dati rimangono invariati.
Transazioni in oggetti complessi
La struttura dati di X-Cross è spesso basata su oggetti complessi:
Ad esempio una fattura è formata da tante tabelle (intestazione, righe, lotti, numeri di serie, provvigioni, spese, ecc.) che insieme formano l’oggetto “fattura”.
In X-Cross l’inserimento e l’aggiornamento di tutte le tabelle che costituiscono una fattura è contenuto in un’unica transazione, che comprende tutte le tabelle e sottotabelle, a qualsiasi livello, in un’unica transazione.
In questo modo la transazione non è limitata alla singola tabella (intestazione, righe, ecc.) ma a tutte le tabelle che insieme formano l’oggetto, che viene visto come un’entità “atomica”.
Questo vale non solo per una fattura, ma anche per tutti gli oggetti che sono formati da più tabelle.
Transazioni in una singola istruzione SQL
Una caratteristica molto importante di X-Cross è che l’inserimento o l’aggiornamento di oggetti complessi che includono più tabelle viene effettuato non solo in una singola transazione, ma anche in un singolo statement SQL.
In molti programmi, infatti, anche se i molteplici inserimenti-aggiornamenti sono compresi in un’unica transazione, le varie operazioni vengono eseguite con statements separati.
Se qualcosa va storto, il programma client deve prendere atto del problema ed eseguire l’azione appropriata (ROLLBACK), e non c’è una garanzia totale che ciò accada. Inoltre, queste azioni vengono eseguite in tempi diversi, quindi nel frattempo le transazioni sono “sospese”.
In X-Cross, invece, la transazione è sempre un singolo statement SQL
che viene automaticamente invertito (ROLLBACK) se qualcosa, a qualsiasi livello, va storto.
Questi livelli possono includere anche azioni indirette, come trigger attivati da azioni di inserimento e modifica.
Integrità referenziale
In X-Cross, tutte le connessioni tra le tabelle creano una foreign key nel database, con una completa integrità referenziale che garantisce la coerenza dei dati.
La foreign key impedisce all’utente di eliminare un record connesso a un altro: ad esempio, un cliente con fatture non può essere eliminato.
Cascade in foreign keys
In altri casi, le foreign keys possono cancellare i record figlio quando viene cancellato quello padre. Ad esempio, la cancellazione dell’intestazione di una fattura comporta l’automatica eliminazione anche di tutte le righe della fattura stessa.
Coerenza del database – nessun “orfano”
Nei database che non implementano l’integrità referenziale, è possibile avere record “orfani“, cioè record collegati a un padre che non esiste più, ad esempio fatture senza cliente, o righe fattura senza intestazione. Questo può accadere perché le cancellazioni delle singole tabelle non sono comprese in una singola transazione, quindi se qualcosa va storto i dati possono diventare incoerenti.
L’integrità referenziale, con o senza cascade, impedisce al database di creare record “orfani” e ne garantisce la consistenza.
- Senza cascade, il record padre non può essere cancellato se sono presenti record figli collegati
- Con cascade, i record figli vengono cancellati insieme al padre
- In entrambi i casi, l’integrità del database è assicurata.
Stored procedures
Tutte le operazioni di inserimento-modifica-cancella vengono eseguite tramite stored procedure, garantendo le massime prestazioni e, allo stesso tempo, assicurando la consistenza e l’isolamento del database.
Le stored procedure vengono utilizzate anche per leggere i dati in più oggetti (es. una transazione contabile, una fattura, ecc.) che includono più tabelle, aumentando notevolmente la velocità di lettura.
Questo è molto importante in X-Cross, i cui oggetti complessi possono includere molte tabelle o viste diverse (ognuna di esse può a sua volta includere molte tabelle diverse)
Un oggetto operazione contabile, ad esempio, ha 28 viste diverse da leggere (intestazione e 27 sottotabelle)
- L’intestazione della contabilità è una vista, composta da 42 diverse tabelle
- Ogni riga contabile (una delle 27 sottotabelle) è composta da 32 diverse tabelle.
Un oggetto ordine cliente ha 30 viste diverse da leggere (intestazione e 29 sottotabelle)
- L’intestazione dell’ordine è una vista, composta da 62 diverse tabelle
- Ogni riga d’ordine (una delle 29 sottotabelle) è composta da 70 diverse tabelle.
Leggere un oggetto come un ordine, con 29 sottotabelle, richiederebbe un tempo piuttosto lungo; se sono necessari 0,2 secondi per sottotabella, il tempo totale di lettura sarà di circa 6 secondi.
La tecnologia delle stored procedure di X-Cross può leggere un oggetto come questo in 0,2-0,3 secondi, ovvero circa 20 volte più velocemente.
Triggers
Molti aggiornamenti sono conseguenza di altri inserimenti-modifica (es. aggiornamento della giacenza inserendo o aggiornando un movimento di magazzino), e in questo caso vengono modificati con un trigger, ovvero una procedura che si attiva come conseguenza di un altro inserimento-aggiornamento -cancellazione.
In questo modo l’aggiornamento secondario non viene eseguito prima o dopo la transazione principale, ma esattamente durante la transazione stessa. Se la transazione è annullata, il database rimane totalmente invariato.
Viste
Il modellatore di dati CrossModel fa pieno uso delle viste, che vengono utilizzate per molti scopi diversi:
- Alias delle tabelle per connessioni a più record della stessa tabella
- Viste complesse con due o più tabelle nella stessa vista, che non possono comunque essere visualizzate e inserite-aggiornate come una singola tabella
- Viste (queries) che includono tutti i record collegati di una tabella principale (ad es. una fattura collegata al cliente, termine di pagamento, ecc.)