La Logica di Business nei Database Aziendali

Molte applicazioni aziendali sono costruite sul cosiddetto 3-tier o più comunemente a tre livelli: i dati nel database, la logica di business e l’interfaccia utente. Il secondo livello, secondo alcuni produttori, deve stare in oggetti che fungono da filtro tra il primo ed il secondo, ma, come vedremo in questo articolo, è possibile inserire una buona parte della logica di business all’interno dell’archivio stesso.
Con il termine “logica di business” si intende l’insieme dei vincoli che regolano la gestione delle informazioni mantenute in un database. Prendiamo ad esempio il modulo di gestione degli ordini clienti di un’azienda:

• ogni cliente deve avere un codice univoco
• ad ogni cliente deve essere applicata un’aliquota iva del 20% di default
• lo sconto applicato alla merce non può superare il 30% del costo
• ogni volta che viene evaso un ordine occorre decrementare la quantità disponibile in magazzino
• ogni volta che si elimina un ordine occorre eliminare tutte le sue righe e aumetare la quantità disponibile in magazzino

Nei database moderni (DBMS) ci sono già gli strumenti per implementare la logica di business, alcuni in maniera molto semplice, altri utilizzando dei linguaggi di scripting e quindi la programmazione. Ecco i casi più semplici:

• Le chiavi primarie possono garantire l’univocità dei codici.
• Il controllo sui campi con la clausola NOT NULL permette di far inserire obbligatoriamente un valore.
• Le viste o query permettono di creare campi fittizi il cui valore viene dinamicamente calcolato.
• L’integrità referenziale consente di indicare che ad ogni chiave straniera equivale sempre una chiave primaria ed è possibile imporre la cancellazione di ogni dato riferito a quella chiave.

Questi controlli, oltre ad essere molto semplici da implementare, sono di solito portabili da un DBMS ad un altro. Altri strumenti più complicati ed anche meno portabili sono invece i trigger e le stored procedure. Un trigger è un’azione che deve essere svolta ogni volta in cui si verifica una determinata modifica al database. Ad esempio quando viene evaso un ordine occorre diminuire la quantità di merce disponibile in magazzino e questo è possibile farlo con un trigger, in SQL Server il codice da scrivere sarà simile a questo:

CREATE TRIGGER trord FOR INSERT AS UPDATE Articoli SET Articoli.Giacenza = Articoli.Giacenza – SottoOrdine.Qt FROM SottoOrdine WHERE Articoli.IDArticolo = SottoOrdine.IDArticolo

Dopo ogni inserimento ( FOR INSERT ) nella tabella SottoOrdini viene avviato il comando UPDATE diminuendo il valore della giacenza. Una stored procedure è invece un vero e proprio programma che viene memorizzato all’interno del database, compilato ed infine eseguito su esplicita richiesta da parte del client. Una stored procedure come una funzione in un linguaggio di programmazione, può accettare dei parametri in ingresso e rilasciarne altri in uscita. Vediamo ad esempio il codice per avere la quantità di un articolo di magazzino ordinato da un cliente:

CREATE PROCEDUE pcord #idCliente int AS SELECT Articolo, SUM(Qt) FROM Articoli A, Ordini O, Clienti C WHERE C.IDCliente = @idCliente AND C.IDOrdine = O.IDordine AND O.IDArticolo = A.IDArticolo GROUP BY Articolo

Rispetto alla scrittura di una simile funzione all’interno del programma client, l’utilizzo delle stored procedure offre dei vantaggi molto importanti:

1. La velocità di esecuzione della stored procedure direttamente sul server è notevolmente più elevata ed inoltre viene generato meno traffico di rete, essendoci meno interazioni tra client e server.
2. La sicurezza nell’eseguire dei comandi sui dati, perché un utente avrà la possibilità di effettuare soltanto una procedura invece che avere a disposizione tutto il database.

Come abbiamo visto, quindi, la logica di business è uno strato intermedio dell’architettura applicativa e l’utilizzo di trigger e stored procedure rappresenta solo una delle possibili scelte. I vantaggi della centralizzazione delle regole di utilizzo dei dati all’interno del database risiedono anche nella possibilità di far utilizzare dette regole da tutte le applicazioni client, diminuendo i tempi di sviluppo di queste ultime, inoltre garantiscono una performance maggiore ed una minore interazione tra client e server dati. Tra gli svantaggi abbiamo il maggior carico di lavoro per il server dati e la scarsa portabilità di questo tipo di soluzione, infatti trigger e stored procedure utilizzano un linguaggio diverso tra i vari produttori di DBMS.