Le strategie di una multinazionale nel mercato italiano: il caso Kraft

Tra i requisiti fondamentali del nuovo sistema informatico d’importanza cruciale è la sincronizzazione dei dati tra un agente di commercio e l’altro e tra gli agenti di commercio e le varie sedi dell’azienda.
Nel paragrafo “Che cosa offre il mercato?” sono stati analizzati un prodotto stand-alone (Sage ACT!) e diverse soluzioni client-server (vTiger, SugarCRM, ecc…). L’approccio utilizzato in questo progetto ha portato a unire i pregi di entrambe le tecnologie. Lo scopo è ottenere un database distribuito che permetta agli utenti di poterlo utilizzare sia quando collegati all’intranet aziendale sia quando la connessione non è disponibile.
Come descritto nel paragrafo “Lavorare offline…”, ogni commerciale avrà accesso a un’applicazione stand-alone che utilizza Oracle JavaDB come strumento di persistenza. I dati cui gli utenti dell’applicazione avranno accesso sono un sottoinsieme di quelli presenti anche sul DBMS aziendale PostgreSQL.

Ogni utente dell’applicazione lavorerà sempre sui dati locali, in modo da non preoccuparsi della disponibilità o meno del collegamento alla rete aziendale. La sincronizzazione di ogni database locale con il server aziendale avverrà automaticamente all’apertura e chiusura dell’applicazione, oppure manualmente su esplicita richiesta dell’utente. Ogni database locale deve avere la possibilità sia di ricevere gli aggiornamenti dal DBMS aziendale, sia d’inviare i dati inseriti e modificati localmente dagli utenti.
Lo scenario che si presenta prevede più database gemelli (i database locali JavaDB) e un database “centrale” (il DBMS PostgreSQL installato sul server di Trento). Ogni database locale sarà quindi una replica di parte del database aziendale.

Nel corso degli anni, in informatica, questa situazione è stata discussa e affrontata diverse volte sotto il nome di database replication. La maggior parte delle implementazioni di questa tecnologia usa un approccio master-slave, dove un server di database (il master) mantiene la copia principale dei dati e server di database aggiuntivi (gli slave) mantengono copie secondarie degli stessi. Questa semplice implementazione prevede che le repliche della base di dati principale (gli slave) siano accessibili esclusivamente in lettura, mentre i dati vengono inseriti e modificati esclusivamente all’interno del master.

Implementazioni più complesse utilizzano invece un approccio multi-master, dove ogni replica di database può modificare i contenuti. Questa tecnologia introduce un sostanziale incremento di complessità che la rende una scelta valida solamente in determinate situazioni.
La replicazione dei database può essere realizzata seguendo tre modelli:
- Snapshot replication
I dati di un server di database sono semplicemente copiati in altri server di database.
Un editore (publisher), che può trovarsi su un server di database slave, invia i dati al distributore (distributor) che solitamente si trova sul server di database master. Il distributore, spedisce copia dei dati a tutti i server di database che hanno un “abbonamento” con esso (subscriber) .
Questa tecnica di replicazione prevede, ogni volta, la duplicazione dell’interno database.
- Transactional replication
Inizialmente ogni subscriber contiene una copia iniziale del database principale. Queste copie saranno poi periodicamente aggiornate con i dati (nuovi o modificati) contenuti nel database master. Questa tecnica dinamica utilizza una propagazione incrementale, verso i subscriber, delle modifiche apportate dai publisher.
I publisher e i subscriber devono essere sempre mantenuti sincronizzati e dovrebbero quindi essere sempre connessi tra loro.
- Merging replication
Dati provenienti da più database (publisher/subscriber) vengono combinati in un unico database (distributor) che poi sincronizza nuovamente i database publisher/subscriber.