Un database attivo è un’interfaccia automatizzata che esegue determinate funzioni che dipendono da input specifici di informazioni. I programmatori e gli amministratori possono manipolare i sistemi di database attivi per eseguire transazioni in base a relazioni predefinite. Simile all’idea di causa ed effetto, alcune di queste relazioni o domande sono indicate come “accoppiamento”. All’interno del design del database, ci sono parametri che specificano quali informazioni verranno condivise e con chi verranno condivise.
La principale differenza tra un database convenzionale e uno attivo è che qualcosa si verifica come risultato di qualcos’altro. I pagamenti automatici delle bollette sono un esempio di database attivo. Un cliente bancario può incaricare il suo istituto di pagare a un beneficiario un importo specifico in una determinata data ogni mese. Al raggiungimento della data indicata, i pagamenti elettronici vengono inviati automaticamente ai beneficiari indicati dalle informazioni nel database.
A volte indicato come architettura basata su eventi, un database attivo è progettato per eseguire azioni in base a determinati trigger. Di solito c’è una relazione tra gli eventi. Ad esempio, i sistemi di database del punto vendita (POS) possono riordinare automaticamente il prodotto per un negozio al dettaglio una volta ricevuto l’informazione che l’inventario corrente è sceso a un importo predefinito. A seconda del modo in cui sono impostati i parametri del database, il riordino effettivo può avvenire immediatamente, come transazione separata, o essere posticipato.
Le transazioni immediate si verificano insieme agli eventi scatenanti. Ad esempio, un sistema POS può riordinare il prodotto in base al codice prodotto universale (UPC) o all’unità di conservazione delle scorte (SKU). Può elaborare i livelli di inventario e le transazioni di ordinazione allo stesso tempo. Molti rivenditori di massa operano con questo tipo di database attivo che riceve input continui da diverse fonti, incluso il personale di vendita e ricevimento.
Le transazioni separate sono impostate per verificarsi in momenti diversi. In genere, il database è progettato per esaminare l’evento di attivazione e potrebbe essere necessario confrontarlo con regole aggiuntive per eseguire un’azione. Ad esempio, il sistema POS di un rivenditore può essere attivato da un basso livello di inventario, ma l’azione intrapresa può dipendere dal fatto che il prodotto venga interrotto o se un articolo viene fornito tramite un fornitore. Il database potrebbe non elaborare un ordine se le regole sono impostate per rifiutare l’azione se il prodotto non supera la valutazione.
Le transazioni differite sono simili all’idea delle transazioni separate, tranne per il fatto che la prima deve terminare prima che venga elaborata la seconda. Nell’esempio POS, il database può registrare che l’inventario di un determinato prodotto è sceso al di sotto dei livelli accettabili all’inizio della giornata. Con una transazione differita, il processo di riordino non verrebbe eseguito fino alla chiusura dell’attività, quando vengono registrati i livelli finali di inventario.