LE BASI DI DATI DISTRIBUITE - LA DISTRIBUZIONE E LA FRAMMENTAZIONE DEI DATI - LA REPLICAZIONE DEI DATI

LA DISTRIBUZIONE E LA FRAMMENTAZIONE DEI DATI.

L'aspetto più difficile delle basi di dati distribuite è come deve avvenire la distribuzione dei dati. Per  risolvere questo problema si fa riferimento ad uno schema globale di tutta la base di dati come se fosse centralizzata, si può dire che può essere vista come integrazione degli schemi locali di ogni sito.

Questa relazione dello schema globale viene chiamata relazione globale.

Una base di dati locale, perciò, sarà costituita da un sottoinsieme delle relazioni globali o di loro frammenti.

I frammenti sono relazioni originate da ideali processi di frammentazione delle relazioni globali. In una relazione globale R si hanno tre tipi di frammentazione:

• frammentazione orizzontale:in questa frammentazione i singoli frammenti di R hanno tutti lo schema R e sono dei sottoinsiemi disgiunti delle tuple di R, l'unione di tutti i frammenti deve dare R
• frammentazione verticale: qui, ogni frammento è costituito da un sottoinsieme delle colonne di R, comprendente una chiave in modo tale che la relazione originale possa essere ottenuta mediante giunzione naturale dei singoli frammenti verticali.
• frammentazione mista: combina la frammentazione orizzontale e la frammentazione verticale.

Sei si frammenta una relazione bisogna ricordarsi di non dimenticare fuori della rete alcun frammento. Deve essere possibile ricostruire la relazione globale originale partendo dai frammenti.

Scegliere una o l'altra frammentazione dipende dalle funzionalità locali che si pensa di svolgere su quei siti.

Nelle basi di dati distribuite, quindi, si consente la duplicazione dei dati si permette cioè che una stessa relazione globale o un suo frammento possano comparire in più di un sito, dette repliche.

LA REPLICAZIONE DEI DATI.

Ci sono però molte situazioni in cui le modifiche dei dati di interesse generale vengono decise da persone di un unico nodo. Un esempio potrebbe essere le filiali delle aziende  nelle quali solo i vertici possono cambiare i prezzi di listino.

In generale, se le modifiche ad alcuni dati sono frequenti e sono comunque un privilegio di un nodo solo, è conveniente prendere in esame un sistema di distribuzione dei dati noto come replicazione, previsto anche da diversi DBMS non distribuiti.

Idealmente si vorrebbe che tutti i lettori venissero informati "contemporaneamente" delle modifiche o che nessuno incominci a leggere fino a quando tutti non sono stati aggiornati, consistenza della replicazione.

I sistemi di replicazione si differenziano rispetto al tipo di soluzione a questo problema dando luogo a diversi modelli di replicazione.

Ci sono due modelli di replicazione:

• modello a consistenza stretta in cui si garantisce che tutte le repliche siano sempre identiche  all'originale. In particolare ogni modifica all'originale deve provocare un blocco di tutti i "lettori" sino a quando la replicazione, che deve essere immediatamente attivata, non sia giunta a termine per tutti.
• modello a consistenza lasca in cui si permette che possa esserci un ritardo tra il momento in cui i dati originali sono modificati e, quello in cui un lettore riceve la copia. Non si garantisce che tutti i lettori abbiano sempre la stessa la copia dei dati.

In pratica il modello a consistenza stretta può essere realizzato con un certo successo sulle reti locali o comunque su reti con "notevoli" prestazioni sia riguardo ai tempi che all'affidabilità.

In molti casi pratici, specie se i nodi sono connessi in una rete lenta e inaffidabile (come certe reti geografiche), conviene accettare il rischio "calcolato" di incorrere in casi di inconsistenza usando un sistema a consistenza lasca. Tale rischio viene escluso se nella giornata esistono degli intervalli di inattività durante i quali lo scrittore può attivare e completare la replicazione a tutti i lettori.

Con riferimento ai casi citati all'inizio, la replicazione potrebbe avvenire nelle ore notturne o un'ora prima dell'orario di apertura delle filiali.

In ogni caso, la probabilità di un caso di inconsistenza può essere reso arbitrariamente piccola aumentando la frequenza con cui vengono fatte le replicazioni. La frequenza dipenderà, in ultima analisi, dalla "rapidità" dei fenomeni sui quali i dati replicati possono influire (ad es. un'ora, un giorno, una settimana, ecc.). Dato che le replicazioni hanno dei costi non indifferenti, in termini di tempo e di uso di una rete, sarà opportuno scegliere un valore di sicurezza, ma non più basso.

Un confronto fra le basi di dati distribuite e quelle centralizzate:

Vantaggi

Autonomia locale. Ogni sito è in grado di funzionare autonomamente e ha, in particolare, un propria capacità di controllo e manutenzione sui dati di quel nodo, affidata ad un amministratore locale delle base di dati (local DBA).

Maggiore affidabilità. Un guasto ad un nodo della rete non preclude agli altri la possibilità di continuare a lavorare. Si tratterà solo di rinunciare a lanciare quelle applicazioni che utilizzano i dati residenti solo in quel nodo. Un guasto ad un sistema centralizzato bloccherebbe invece tutte le attività.

Maggiore efficienza. Distribuendo il carico di lavoro sui vari nodi e compiendo elaborazioni locali si conferisce al sistema un elevato grado di parallelismo che potrebbe ridurre i tempi di certe interrogazioni. Inoltre il fatto che molte elaborazioni avvengano in modo locale riduce il traffico di rete.

Maggiore scalabilità. Il sistema può crescere gradualmente secondo le necessità. Non è necessario fare all'inizio un grosso investimento su un mainframe e scoprire poi comunque, ad un certo punto, che risulta insufficiente o inadatto per nuove esigenze. ,

Svantaggi

Costo del software. I costi del DBMS distribuito e ‑ soprattutto‑ quelli di sviluppo del software, sono certamente maggiori; perché maggiori sono le difficoltà da superare e i problemi di cui tener conto rispetto ad un sistema centralizzato. Tutto è più complesso: autorizzazioni, ottimizzazione, integrità, ecc.

Maggiori possibilità di malfunzionamenti. La maggiore complessità del sistema hardware e software ci espone di più al rischio di malfunzionamenti. Inoltre, nel caso si verifichi un malfunzionamento, non è semplice individuarne la causa e quindi capire come intervenire. Oltre alle cause tradizionale (disco e piattaforma) le reti ne introducono altre: crash di un nodo, interruzione di un collegamento, isolamento.

Difficoltà di gestione. Il numero delle persone e delle procedure coinvolte nella manutenzione del sistema è certamente maggiore di quello richiesto ad un sistema centralizzato. Anche se esiste di solito un DBA di rete, vi possono comunque essere difficoltà di coordinamento, gestione, ecc.

Maggiore sovraccarico di sistema (system overloading). La possibilità di effettuare transazioni globali e la presenza di repliche dei dati richiede dei protocolli di sincronizzazione particolarmente complessi anche dal punto di vista computazionale. Ad esempio, quando si accede ad un dato potrebbe essere necessario fare un bloccaggio su ogni copia del dato presente nei vari siti. I tempi spesi per questi protocolli sono spesso di gran lunga più onerosi di quelli richiesti per un sistema centralizzato.