• Use Case: Il caso bancario

In un sistema distribuito abbiamo diversi basi dati locali, diverse applicazioni su ogni nodo di elaborazione (dove ogni nodo condivide varie informazioni) con gli utenti che accedono alle varie applicazioni. Questo tipo di architettura prende il nome di architettura shared nothing. In quanto i DBMS di ogni singola macchina sono autonomi (anche di vendor diversi) ma che lavorano insieme.

Non abbiamo solo dati “distribuiti” tra vari nodi ma possiamo anche “duplicarne” alcuni per diversi scopi, coi nodi collegati in rete (anche soluzioni interamente distribuite nel cloud).

Confrontando un db distribuito con un multi-database (ovvero vari database completi da “unificare”) notiamo come entrambi abbiano un’alta distribuzione, il primo una bassa eterogeneità (a differenza del secondo, dove nei vari db potrei avere forte differenza di tipologia dei dati contenuti). Si ha anche bassa autonomia nel caso di db distribuiti a differenza del multi-db (dove ogni db è singolarmente autonomo).

Bisogna capire cosa distribuire. Si hanno diverse condizioni (che possono essere presenti simultaneamente):

• le applicazioni, fra loro cooperanti, risiedono su più nodi elaborativi (elaborazione distribuita);
• l’archivio informativo è distribuito su più nodi (base di dati distribuita)

Ad esempio, il client e un server possono ripartirsi le funzionalità di elaborazione, oppure su una schiera di sistemi server possono essere ripartiti diversi sottoprogrammi che implementano diverse funzionalità.

La distribuzione si dice essere ortogonale e trasparente agli altri.

Capire cosa distribuire è una parte consistente dello studio di come costruire un’architettura distribuita (magari frutto di situazioni particolari come la “fusione” di due sistemi a causa di un’acquisizione aziendale, ec… dove diverse logiche applicative e diverse strutture dati possono creare situazioni molto pericolose).

• Use Case: Azienda di progettazione e vendita

Possiamo classificare i db distribuiti.

Definizione: Un DBMS Distribuito Eterogeneo Autonomo (DEA) è in generale una federazione di DBMS che collaborano nel fornire servizi di accesso ai dati con livelli di trasparenza definiti (infatti le diversità tra db nei nodi vengono “nascosti” a vari livelli di trasparenza per distribuzione, eterogeneità e autonomia).

Come abbiamo visto esiste l’esigenza di integrare a posteriori vari db preesistenti (anche a causa di integrazione di nuovi applicativi o nuove cooperazioni di processi) e questa situazione è spinta dallo sviluppo della rete.

Possiamo quindi dividere i livelli di federazione su tre categorie tra loro ortogonali (indipendenti):

• Autonomia: fa riferimento al grado di indipendenza tra i nodi e si hanno diverse forme:

  • di progetto (ogni nodo ha un proprio modello dei dati e di gestione delle transazioni)
  • di condivisione (ogni nodo sceglie cosa condividere, condividendo con gli altri nodi lo schema comune)
  • di esecuzione (ogni nodo sceglie in che modo eseguire le transazioni che gli vengono sottoposte)

  Si hanno quindi:

  • DBMS Strettamente integrati (nessuna autonomia),
    • dati logicamente centralizzati,
    • unico data manager responsabile delle transazioni applicative
    • data manager locali che non operano in modo autonomo ma eseguono le direttive centrali
  • DBMS semi-autonomi
    • ogni data manager è autonomo ma partecipa a transazioni globali,
    • una parte dei dati è condivisa
    • sono richieste modifiche architetturali per poter far parte della federazione;
  • DBMS totalmente autonomi (o P2P)
    • ogni DBMS lavora in autonomia ed è inconsapevole dell’esistenza degli altri

• Distribuzione

  Fa riferimento alla distribuzione dei dati.

  Si possono distinguere tre possibili distribuzioni:

  • client / server, la gestione dei dati è concentrata nel server, mentre i client forniscono l’ambiente applicativo e la presentazione
  • distribuzione P2P, in cui non c’è distinzione tra client e server, e tutti i nodi hanno identiche funzionalità DBMS
  • nessuna distribuzione

  Le prime due possono anche non essere distinte.

• Eterogeneità

  può riguardare vari aspetti:

  • modello dei dati (relazionale, XML, OO, json)

  • linguaggio di query

    (dialetti SQL, Query by Example, Linguaggi OO o XML)

  • gestione delle transazioni

    (diversi protocolli per il concurrency control e per il recovery)

  • schema concettuale e logico

    (un concetto rappresentato in uno schema come attributo e in un altro come entità)