Basi dati 2

Formattazione del testo

SELECT NUM-CC, PROGR, AMMONTARE FROM CONTO-CORRENTE AS C JOIN TRANSAZIONE AS T ON C.NUM-CC = T.NUM-CC WHERE SALDO < 0

Trasparenza di allocazione (join distribuito)

SELECT NUM-CC, PROGR, AMMONTARE FROM CONTO1 JOIN TRANS1 ON…. WHERE SALDO < 0

UNION

SELECT NUM-CC, PROGR, AMMONTARE FROM CONTO2 JOIN TRANS2 ON…. WHERE SALDO < 0

UNION

SELECT NUM-CC, PROGR, AMMONTARE FROM CONTO3 JOIN TRANS3 ON…. WHERE SALDO < 0

Lezione 09 - Basi di Dati Distribuite ed Architetture Client-Server

Trasparenza di linguaggio

SELECT NUM-CC, PROGR, AMMONTARE FROM CONTO1@1 JOIN TRANS1@1 ON…. WHERE SALDO < 0

UNION

SELECT NUM-CC, PROGR, AMMONTARE FROM CONTO2@C JOIN TRANS2@C ON…. WHERE SALDO < 0

UNION

SELECT NUM-CC, PROGR, AMMONTARE FROM CONTO3@C JOIN TRANS3@C ON…. WHERE SALDO < 0

Trasparenza di frammentazione

UPDATE: Sposta il cliente 45 dalla Filiale 1 alla Filiale 2.

UPDATE CONTO-CORRENTE SET FILIALE = 2 WHERE NUM-CC = 45 AND FILIALE = 1

Trasparenza di allocazione

1. replicazione)
• INSERT INTO CONTO2
SELECT * FROM CONTO1 WHERE NUM-CC = 45
• INSERT INTO TRANS2
SELECT * FROM TRANS1 WHERE NUM-CC = 45
• DELETE FROM CONTO1 WHERE NUM-CC = 45
• DELETE FROM TRANS1 WHERE NUM-CC = 45
• (Bisogna settare anche la FILIALE a 2)
2. 130Lezione 09 - Basi di Dati Distribuite ed Architetture Client-Server
3. Trasparenza di linguaggio
• INSERT INTO CONTO2@2
SELECT * FROM CONTO1@1 WHERE NUM-CC = 45
• INSERT INTO CONTO2@C
SELECT * FROM CONTO1@C WHERE NUM-CC = 45
• INSERT INTO TRANS2@2
SELECT * FROM TRANS1@1 WHERE NUM-CC = 45
• INSERT INTO TRANS2@C
SELECT * FROM TRANS1@C WHERE NUM-CC = 45
• (In modo analogo: 2 coppie di DELETE)
• Bisogna settare anche la FILIALE a 2
4. Efficienza
• Ottimizzazione delle query. La modalità di esecuzione è seriale e parallela.
• Esecuzione seriale
• Esecuzione parallela
5. Transazioni distribuite
• BEGIN TRANSACTION
• UPDATE CONTO1@1
SET SALDO = SALDO + 500.000
WHERE NUM-CC = 45;
• UPDATE CONTO2@2
SET SALDO = SALDO – 500.000
WHERE NUM-CC = 35;
• COMMIT-WORK
• END TRANSACTION
6. 131Lezione 09 - Basi di

Dati Distribuite ed Architetture Client-Server

Tipi di DDB:

• Grado di omogeneità del software dei DDBMS, dove:
  • DDB omogenei: tutti i server e tutti gli utenti usano lo stesso software.
  • DDB eterogenei, altrimenti.
• Grado di autonomia locale, dove:
  • Se il sito locale non può funzionare come un DBMS stand-alone non ha nessuna autonomia locale, e all'utente il sistema "appare" come un DBMS centralizzato.
  • Se alle transazioni locali è permesso l'accesso diretto a un server, ha qualche grado di autonomia locale.

DDB omogenei

DDB eterogenei

Sistemi di database federati: ogni server è un DBMS centralizzato e autonomo con:

• I suoi propri utenti locali;
• Transazioni locali;
• DBA;
• E, quindi, un alto grado di autonomia locale.

È presente una vista globale o schema della federazione di database.

Un sistema multidatabase (DB federati o FDB) non ha uno schema globale e

interattivamente ne viene costruito uno (vista globale) in base alle necessità dell'applicazione. In un FDB eterogeneo, i DB coinvolti possono essere relazionali, reticolari, gerarchici, ecc... Si rende necessario introdurre dei traduttori di query.

Sistemi per la gestione dei DB Federati

Vi sono diversi tipi differenti di eterogeneità:

• Differenze nei modelli di dati.
• Differenze nei vincoli: le modalità per la specifica dei vincoli varia da sistema a sistema.
• Differenze nei linguaggi di query: anche con lo stesso modello di dati i linguaggi e le loro versioni possono variare.
• Eterogeneità semantica: differenze di significato, interpretazione, uso degli stessi dati o di dati correlati.

Essa costituisce la principale difficoltà nella progettazione degli schemi globali di basi di dati eterogenee.

Lezione 09 - Basi di Dati Distribuite ed Architetture Client-Server

Lo schema a cinque livelli (FDBS)

• Lo schema per un gruppo

di utenti o un'applicazione.

• Schema globale risultante dall'integrazione di più schemi.
• Sottoinsieme dello schema componente.
• Modello dati comune.
• Schema concettuale.

Controllo della concorrenza e Recovery

I database distribuiti incontrano un numero di controlli di concorrenza e problemi di recovery che non sono presenti nei database centralizzati. Ne vengono elencati alcuni di seguito:

• Trattamento di copie multiple di dati. Il controllo della consistenza deve mantenere una consistenza globale. Allo stesso modo il meccanismo di recovery deve recuperare tutte le copie e conservare la consistenza dopo il recovery.
• Fallimenti di singoli siti. La disponibilità del database non deve essere influenzata dai guasti di uno o due siti e lo schema di recovery li deve recuperare prima che siano resi disponibili.
• Guasto dei collegamenti di comunicazione. Tale guasto può portare ad una partizione della rete che può influenzare
primario. Un singolo sito è designato come sito primario il quale fa da coordinatore per la gestione delle transazioni.

Nell'ottica della gestione delle transazioni il controllo della concorrenza ed il commit sono gestiti da questo sito. La tecnica del lock a due fasi (2PL) è usata per bloccare e rilasciare i data item. Se tutte le transazioni in tutti i siti seguono la politica delle due fasi allora viene garantita la serializzabilità.

Vantaggi: i data item sono bloccati (locked) solamente in un sito ma possono essere usati da qualsiasi altro sito.

Svantaggi: tutta la gestione delle transazioni passa per il sito primario che potrebbe essere sovraccaricato. Nel caso in cui il sito primario fallisce, l'intero sistema è inaccessibile.

Per assistere il recovery, un sito di backup viene designato come copia di backup del sito primario. Nel caso di fallimento del sito primario, il sito di backup funziona da sito principale.

Tecnica della copia primaria: In questo approccio, invece di un sito, una partizione dei data item è designata come copia primaria. Per bloccare un

data item soltanto sulla copia primaria di quel data item viene eseguito il lock.

Vantaggi: le copie primarie sono distribuite su vari siti, e un singolo sito non viene sovraccaricato da un numero elevato di richieste di lock ed unlock.

Svantaggi: l'identificazione della copia primaria è complesso. Una directory distribuita deve essere gestita possibilmente in tutti i siti.

Recovery dal fallimento di un coordinatore

In entrambi gli approcci un sito coordinatore o un sito copia possono essere indisponibili. Questo richiede la selezione di un nuovo coordinatore.

• Approccio del sito primario senza sito di backup. Abortire e far ripartire tutte le transazioni attive in tutti i siti. Si elegge un nuovo coordinatore che inizia il processing delle transazioni.

• Sito primario con copia di backup. Sospende tutte le transazioni attive, designa il sito di backup come sito primario e identifica un nuovo sito di backup. Il nuovo sito primario riceve il compito di gestire tutte le

transazioni per riprendere il processo. Se il sito primario e quello di backup falliscono si utilizza un processo di elezione per selezionare un nuovo sito coordinatore.

Controllo della concorrenza basata sul Voting

In questo caso non esiste la copia primaria del coordinatore. Quindi:

1. Spedire una richiesta di lock ai siti che hanno i data item.
2. Se la maggioranza dei siti concedono il lock allora la transazione richiedente ottiene il data item.
3. Le informazioni di lock (concesse o negate) sono spedite a tutti questi siti.
4. Per evitare un tempo di attesa inaccettabile, viene definito un periodo di time-out. Se la transazione richiedente non riceve alcuna informazione di voto allora la transazione viene abortita.

Lezione 09 - Basi di Dati Distribuite ed Architetture Client-Server

Architettura Client-Server

Viene discussa l'architettura Client-Server in generale e poi verrà applicata ai DBMS.

In un ambiente con un grande numero di PC, stampanti, ecc... Si definiscono

dei server specializzati con funzionalità specifiche. Ad esempio:
• Il file server mantiene i file delle macchine client.
• Il printer server gestisce la stampa su diverse stampanti.
• L'email server gestisce la posta elettronica.
Le risorse fornite da server specializzati possono essere messe a disposizione di diversi client. Una macchina client fornisce all'utente l'appropriata interfaccia per utilizzare questi server impiegando la potenza di calcolo locale per eseguire applicazioni locali. Lezione 09 - Basi di Dati Distribuite ed Architetture Client-Server Architettura Client-Server per DBMS Differenti approcci sono stati proposti su come suddividere le funzionalità tra client e server. Una possibilità è di includere le funzionalità in un DBMS centralizzato a livello server. Un server SQL è fornito al client (ogni client):
• Formula la query.
• Fornisce l'interfaccia utente.
• Fornisce funzioni di
nterfaccia dei linguaggi di programmazione.
SQL è uno standard e i server SQL di diversi produttori possono accettare query SQL.
I client possono collegarsi al dizionario dei dati che include la distribuzione dei dati fra i vari server SQL.
Interazione fra Client e Server
Elaborazione di una query:
1. Il client parsa una query e la decompone in un certo numero di query ai siti indipendenti.
2. Ogni server processa la query locale e manda il risultato al sito client.
3. Il client combina il risultato delle sottoquery per produrre il risultato della query sottomessa in origine.
In questo approccio, il server SQL è detto anche transaction server o back-end machine. Il c