DBMS distribuito - Ambienti database

In questa parte del tutorial, studieremo i diversi aspetti che aiutano nella progettazione di ambienti di database distribuiti. Questo capitolo inizia con i tipi di database distribuiti. I database distribuiti possono essere classificati in database omogenei ed eterogenei con ulteriori divisioni. La sezione successiva di questo capitolo discute le architetture distribuite, vale a dire client - server, peer - to - peer e multi - DBMS. Infine, vengono introdotte le diverse alternative di progettazione come la replica e la frammentazione.

Tipi di database distribuiti

I database distribuiti possono essere classificati ampiamente in ambienti di database distribuiti omogenei ed eterogenei, ciascuno con ulteriori suddivisioni, come mostrato nell'illustrazione seguente.

Database distribuiti omogenei

In un database distribuito omogeneo, tutti i siti utilizzano DBMS e sistemi operativi identici. Le sue proprietà sono:

I siti utilizzano software molto simili.
I siti utilizzano DBMS o DBMS identici dello stesso fornitore.
Ogni sito è a conoscenza di tutti gli altri siti e collabora con altri siti per elaborare le richieste degli utenti.
Si accede al database tramite un'unica interfaccia come se fosse un unico database.

Tipi di database distribuiti omogenei

Esistono due tipi di database distribuito omogeneo:

Autonomous- Ogni database è indipendente e funziona da solo. Sono integrati da un'applicazione di controllo e utilizzano il passaggio di messaggi per condividere gli aggiornamenti dei dati.
Non-autonomous - I dati vengono distribuiti tra i nodi omogenei e un DBMS centrale o master coordina gli aggiornamenti dei dati tra i siti.

Database distribuiti eterogenei

In un database distribuito eterogeneo, diversi siti hanno sistemi operativi, prodotti DBMS e modelli di dati diversi. Le sue proprietà sono:

Siti diversi utilizzano schemi e software diversi.
Il sistema può essere composto da una varietà di DBMS come relazionali, di rete, gerarchici o orientati agli oggetti.
L'elaborazione delle query è complessa a causa di schemi dissimili.
L'elaborazione delle transazioni è complessa a causa di software dissimili.
Un sito potrebbe non essere a conoscenza di altri siti e quindi la cooperazione nell'elaborazione delle richieste degli utenti è limitata.

Tipi di database distribuiti eterogenei

Federated - I sistemi di database eterogenei sono di natura indipendente e integrati insieme in modo da funzionare come un unico sistema di database.
Un-federated - I sistemi di database utilizzano un modulo di coordinamento centrale attraverso il quale si accede alle banche dati.

Architetture DBMS distribuite

Le architetture DDBMS sono generalmente sviluppate in base a tre parametri:

Distribution - Indica la distribuzione fisica dei dati tra i diversi siti.
Autonomy - Indica la distribuzione del controllo del sistema di database e il grado in cui ciascun DBMS costituente può operare in modo indipendente.
Heterogeneity - Si riferisce all'uniformità o alla diversità dei modelli di dati, componenti di sistema e database.

Modelli architettonici

Alcuni dei modelli architettonici comuni sono:

Client - Architettura server per DDBMS
Architettura peer-to-peer per DDBMS
Architettura multi-DBMS

Client - Architettura server per DDBMS

Questa è un'architettura a due livelli in cui la funzionalità è suddivisa in server e client. Le funzioni del server comprendono principalmente la gestione dei dati, l'elaborazione delle query, l'ottimizzazione e la gestione delle transazioni. Le funzioni client includono principalmente l'interfaccia utente. Tuttavia, hanno alcune funzioni come il controllo della coerenza e la gestione delle transazioni.

Le due diverse architetture client-server sono:

Single Server Multiple Client
Multiple Server Multiple Client (mostrato nel diagramma seguente)

Architettura peer-to-peer per DDBMS

In questi sistemi, ogni peer agisce sia come client che come server per impartire servizi di database. I pari condividono le loro risorse con altri colleghi e coordinano le loro attività.

Questa architettura ha generalmente quattro livelli di schemi:

Global Conceptual Schema - Raffigura la vista logica globale dei dati.
Local Conceptual Schema - Raffigura l'organizzazione logica dei dati in ogni sito.
Local Internal Schema - Raffigura l'organizzazione fisica dei dati in ogni sito.
External Schema - Raffigura la visualizzazione dei dati da parte dell'utente.

Architetture multi-DBMS

Si tratta di un sistema di database integrato formato da una raccolta di due o più sistemi di database autonomi.

Il multi-DBMS può essere espresso attraverso sei livelli di schemi:

Multi-database View Level - Raffigura più viste utente che comprendono sottoinsiemi del database distribuito integrato.
Multi-database Conceptual Level - Rappresenta il multi-database integrato che comprende definizioni di strutture logiche globali multi-database.
Multi-database Internal Level - Descrive la distribuzione dei dati tra diversi siti e la mappatura da più database a dati locali.
Local database View Level - Rappresenta la visualizzazione pubblica dei dati locali.
Local database Conceptual Level - Raffigura l'organizzazione locale dei dati in ogni sito.
Local database Internal Level - Raffigura l'organizzazione fisica dei dati in ogni sito.

Esistono due alternative di progettazione per multi-DBMS:

Modello con livello concettuale multi-database.
Modello senza livello concettuale multi-database.

Alternative di design

Le alternative di progettazione della distribuzione per le tabelle in un DDBMS sono le seguenti:

Non replicato e non frammentato
Completamente replicato
Parzialmente replicato
Fragmented
Mixed

Non replicato e non frammentato

In questa alternativa di progettazione, tabelle diverse vengono posizionate in siti diversi. I dati vengono posizionati in modo che siano molto vicini al sito in cui vengono utilizzati maggiormente. È più adatto per i sistemi di database in cui la percentuale di query necessarie per unire le informazioni nelle tabelle collocate in siti diversi è bassa. Se viene adottata una strategia di distribuzione appropriata, questa alternativa di progettazione aiuta a ridurre i costi di comunicazione durante l'elaborazione dei dati.

Completamente replicato

In questa alternativa di progettazione, in ogni sito viene archiviata una copia di tutte le tabelle del database. Poiché ogni sito ha la propria copia dell'intero database, le query sono molto veloci e richiedono costi di comunicazione trascurabili. Al contrario, l'enorme ridondanza dei dati richiede costi enormi durante le operazioni di aggiornamento. Quindi, questo è adatto per i sistemi in cui è necessario gestire un numero elevato di query mentre il numero di aggiornamenti del database è basso.

Parzialmente replicato

Copie di tabelle o porzioni di tabelle vengono archiviate in siti diversi. La distribuzione delle tabelle avviene in base alla frequenza di accesso. Ciò tiene in considerazione il fatto che la frequenza di accesso alle tabelle varia notevolmente da sito a sito. Il numero di copie delle tabelle (o porzioni) dipende dalla frequenza con cui vengono eseguite le query di accesso e dal sito che genera le query di accesso.

Frammentato

In questa struttura, una tabella è divisa in due o più parti denominate frammenti o partizioni e ogni frammento può essere archiviato in siti diversi. Ciò tiene conto del fatto che raramente accade che tutti i dati memorizzati in una tabella siano richiesti in un determinato sito. Inoltre, la frammentazione aumenta il parallelismo e fornisce un migliore ripristino di emergenza. Qui c'è solo una copia di ogni frammento nel sistema, cioè nessun dato ridondante.

Le tre tecniche di frammentazione sono:

Frammentazione verticale
Frammentazione orizzontale
Frammentazione ibrida

Distribuzione mista

Questa è una combinazione di frammentazione e repliche parziali. Qui, le tabelle sono inizialmente frammentate in qualsiasi forma (orizzontale o verticale), quindi questi frammenti vengono parzialmente replicati tra i diversi siti in base alla frequenza di accesso ai frammenti.