Sistemi di database relazionali


Download 98 Kb.
bet1/3
Sana07.02.2020
Hajmi98 Kb.
#96578
  1   2   3
Bog'liq
Sistemi di database relazionali
пречени, Sistemi di database relazionali, Yakuniy nazorat docx tasviriy san'at TS 1, Internet tarixi, reley chizigi nozik strukturasini olchash metodi , reley chizigi nozik strukturasini olchash metodi , reley chizigi nozik strukturasini olchash metodi , Тех.мех fan dasturi 2018, 445 Т Буйрук кучириш..2020 й, Ekspert tizimlar, 3-seminar (1), 5А140202-Физика (йўналишлар бўйича), yogochga ishlov berish dastgohlari va asboblari , 2-topshiriq

Sistemi di database relazionali


-Introduzione

Evoluzione dei sistemi di database

Il modello relazionale

Prospettiva storica

Concetti fondamentali

Elementi costitutivi

Progetto di database relazionali

Introduzione

Sviluppo concettuale

Il Modello ER

Implementazione del modello relazionale

Architetture Client/Server

Introduzione

Architetture C/S ad 3 strati

Proposta per un modello di sviluppo applicativo

Uso di convenzioni di denominazione

Lavorazione in cascata o prototipale ciclica

Bibliografia

 

Introduzione


Non è superfluo ricordare che i sistemi di database sono stati sviluppati per uno scopo che è essenzialmente quello di semplificare lo sviluppo di applicazioni che fanno uso intensivo di dati di tipo strutturato, cioè dati che hanno per natura una struttura in qualche modo ripetitiva. Infatti, nel caso migliore un sistema di database può eliminare intere fasi di sviluppo dato che fornisce una interfaccia semplice ed immediatamente funzionante per la visualizzazione e la modifica dei dati in esso contenuti. In genere maggiore è la parte di elaborazione che si riesce a demandare al database, minore sarà il codice che è necessario sviluppare. Esiste anche il rovescio della medaglia: funzionalità non richieste dal progetto iniziale possono ridurre le prestazioni del sistema senza ragione, e possono rendere il sistema più difficile da capire. Di conseguenza è necessario considerare attentamente quali funzionalità sono necessarie alle applicazioni di destinazione, e come realizzare al meglio le caratteristiche del sistema di database da proporre al programmatore.

Evoluzione dei sistemi di database


I sistemi per la gestione delle informazioni sono evoluti nel tempo attraverso tre grandi categorie.

 


data management

strutture dati semplici ed operazioni semplici (database relazionali)

object management

strutture dati astratte ed operazioni relative (database ad oggetti)

knowledge management

sistemi di memorizzazione di informazioni e di regole non strutturate (intelligenza artificiale)

 

In questo documento si porrà l’ attenzione soltanto sulla prima di esse, ed in particolare su un solo tipo di architettura che è quella relazionale. Come si vedrà in seguito tale architettura abbina le caratteristiche di facilità d’ uso e potenza. Non è un caso che tutti gli sviluppi futuri del data management, cioè l’ object management partono invariabilmente da qui. Inoltre le nuove tecnologie di database ad oggetti nascono per risolvere specifiche categorie di problemi per i quali l’ architettura tradizionale è insufficiente. Ciò non toglie perciò che la tradizionale architettura relazionale continui ad essere la migliore soluzione per tutti quei casi di gestione di informazioni semplici, ossia costituite essenzialmente, anche se non esclusivamente, da testo e numeri.

Di seguito si descrivono tre modelli relazionali fondamentali, ciascuno dei dei quali è costituito dalla coppia di dato e schema, ove lo schema è un metadato che descrive la struttura dei dati, mentre il dato è lo scopo stesso del sistema.

Modello relazionale - RDBMS


Il modello relazionale è il primo modello per importanza, a causa della sua diffusione. Inizialmente fu proposto da Codd nel 1970 e successivamente modificato da Date. Deve il suo successo alla semplicità, essendo costituito da una sola struttura dati, la tabella, che contiene tipi di dati semplici (numeri, lettere, ecc.). Il linguaggio di manipolazione del database è costituito da poche istruzioni, e non c’ è il bisogno che esso sia conosciuto dall’ utente del database (QBE).

Modello relazionale esteso - ERDBMS


Le limitazioni sul tipo di dato che il modello relazionale è in grado di trattare hanno reso necessario lo sviluppo di alcune estensioni, riunite sotto la definizione generica di modello esteso relazionale. Si tratta essenzialmente del modello relazionale ove si aggiunge la possibilità di memorizzare anche dati di tipo oggetto. E’ esclusa o molto ridotta la capacità di manipolare gli oggetti memorizzati, come la capacità di fare confronti, operazioni, ecc.

Modello ad oggetti - ODMS


Sono sistemi di database basati su un modello astratto dei dati, originato dal paradigma della programmazione ad oggetti nata con prodotti come Simula, SmallTalk e successivamente C++. Questi linguaggi di programmazione sono basati sul concetto di tipo di dati astratto, che è costituito da una interfaccia che definisce in modo esplicito una porzione pubblica ed una porzione privata all’ interno di una struttura dati, detta oggetto. Questo tipo di dati astratto, detto classe, può incapsulare alcune parti della struttura dati privata dell’ oggetto tramite procedure pubbliche dette metodi, ed espone la parte pubblica tramite delle variabili dette proprietà.

Il modello relazionale

Prospettiva storica


La tecnologia dei database si è evoluta fin dall’ inizio nello sviluppo di applicazioni di gesitione aziendale, probabilmente a causa del fatto che lo sviluppo di simili applicazioni ha alle spalle adeguati investimenti, ed ha la necessità di manipolare grandi quantità di dati.

La prima soluzione è stata quella dei file indicizzati. Questi file consentivano la memorizzazione su disco e la ricerca di records di vario tipo. Le caratteristiche avanzate dei file ad indici hanno nel tempo costituito le caratteristiche di base dei sistemi di database relazionali. Esse sono_



  1. 1.    record di lunghezza fissa con campi di tipo differente all’ interno

  2. 2.    capacità di memorizzare su disco le informazioni, e di manipolare quantità di dati più grandi della dimensione fisica della memoria disponibile

  3. 3.    indicizzazione di campi e gruppi di campi per la ricerca e selezione rapida di valori che soddisfano a condizioni fissate sul valore dei campi

  4. 4.    blocco di file e record, per la gestione dell’ accesso concorrente ai dati

Negli anni 70 fu sviluppato il primo sistema di database che usava un modello gerarchico e distribuito dei dati, che otteneva le caratteristiche dette prima insieme ad altre nuove:

  1. 5.    uso di identificatori di record e di campi di collegamento in grado di realizzare l’ associazione tra dati all’ interno di una rete di computer

  2. 6.    apertura simultanea di più file indicizzati e collegati da trattare come singolo database

  3. 7.    vincoli di protezione per consentire o no l’ accesso alle informazioni

  4. 8.    gestione delle transazioni al sicuro dai crash di sistema, controllo degli errori e della consistenza del database

Negli anno 80 fu sviluppato e messo in commercio il primo sistema di database relazionale, che agguingeva altre caratteristiche:

  1. 9.    linguaggio di alto livello interno con la possibilità di definire modificare e manipolare i dati, insieme a tool di alto livello per lo sviluppo di form, report ed altri elementi per il trattamento delle informazioni

  2. 10. indipendenza dai dati, ossia capacità del database di cambiare il modo di memorizzare i dati senza che si debba cambiare la logica delle applicazioni che li manipolano.

Il più grande contributo dato dal modello relazionale è stato quello di rendere più semplice da comprendere le strutture dei dati rispetto anche ai sistemi di potenza inferiore. Questa semplicità è dovuta essenzialmente all’ introduzione di pochi concetti come relazioni, query e transazioni, che hanno liberato il programmatore dal lavoro riguardante i dettagli fisici della memorizzazione della informazioni, inclusi i problemi riguardanti la gestione degli errori, la multiutenza, l’ organizzazione dei dati. Molto importante è risultato anche il discreto grado di standardizzazione introdotto dall’ SQL, sia nella manipolazione delle informazioni, che nei meccanismi di indipendenza dai dati delle applicazioni.

Le 10 caratteristiche elencate di sopra costituiscono le caratteristiche di massima di qualsiasi sistema di database. Naturalmente ciascun prodotto di questa categoria può singolarmante disporre di ulteriori funzionalità. Essi spaziano infatti attraverso il vasto settore delle applicazioni gestionali, dalla semplice rubrica degli indirizzi fino al sistema di transazioni su larga scala.


Concetti fondamentali

L’ architettura a tre livelli del modello relazionale


Un sistema di database è tipicamente costituito dai seguenti livelli costitutivi distinti:

 


Interno

tutto quello che riguarda l’ organizzazione interna dei campi, record, indici, sistemi di accesso, codifica, lettura e scrittura dei dati sul corrispondente media di destinazione.

Concettuale

tutto ciò che riguarda il tipo dei campi e record, o le relazioni tra di essi.

Esterno

l’ interpretazione dei dati fornita dal’ applicazione che li utilizza - che può presentare ulteriori vincoli per i dati i tipi.

 

Questo schema è noto come architettura a tre livelli di un sistema di database. In alcuni casi qui o altrove è possibile trovare riferimenti ad una struttura semplificata che include solo due livelli disitinti tra:



  1. 1.    Fisico (interno)

  2. 2.    Logico (concettuale ed esterno)

L’ architettura a tre strati di un sistema di databaase ha profonde ripercussioni sul successivo argomento delle Architetture Client/Server.

Indipendenza dai dati


Una caratteristica molto importante dei sistemi di database è l’ indipendenza dai dati, che consente di modificare l’ organizzazione di questi senza che tali modifiche disturbino il funzionamento dei programmi di manipolazione. In una architettura a tre livelli questa indipendenza esiste sia al livello interno che concettuale.

Indipendenza fisica-è l’ abilità di cambiare l’ organizzazione interna dei dati (ad es. indici, formati) senza influire sui programmi di manipolazione. Corrisponde all’ indipendenza sia sul piano fisico che concettuale.

Indipendenza logica-è l’abilità di modificare lo schema strutturale dei dati (ad es. aggiungere campi, relazioni), senza modificare le applicazioni. Corrisponde ai livelli concettuale ed esterno.

Sistema di sicurezza


Si presenta spesso il problema di amministrare i livelli interno e concettuale di un sistema di database, e qualche volta anche quello esterno. Questo perché bisogna coordinare le modifiche effettuate dalle varie persone coinvolte nello sviluppo del sistema sia al livello fisico che logico. In genere questo problema si risolve creando la figura di un amministratore di database, essenzialmente responsabile del mantenimento delle strutture sia interne che esterne del sistema di database. Per estensione ci si rende conto che esistono essenzialmente tre figure di utenti del sistema di database:

  1. 1.    Amministratore: responsabile del livello fisico del sistema e coordinatore delle azioni di modifica in quell’ ambito

  2. 2.    Programmatore: responsabile del livello esterno

  3. 3.    Utente finale: tutti coloro che fanno qualcosa di utile tramite gli strumenti creati dalle due figure precedenti

Elementi costitutivi

Tabelle


La tabella è l’ ingrediente di base di qualsiasi sistema di database. Essa è costituita da righe (dette anche record o n-ple) e da colonne (dette anche campi o attributi). E’ quindi una struttura dati rettangolare di tipo NxM senza particolari vincoli posti per le dimensioni di M o N, a parte quelli imposti dalla potenza del sistema hardware che ospita i dati. La differenza fondamentale tra M ed N esiste, però, ed è quella che la modifica del numero di colonne avviene piuttosto raramente ed è compito dell’ Amministratore del sistema di database, mentre il numero di righe viene continuamente variato dagli utenti del sistema. E’ evidente come la variazione del numero di colonne ha luogo nello strato fisico e concettuale, mentre la variazione del numero di righe ha luogo nello strato esterno.

Chiavi primarie e chiavi straniere


Un sistema di database relazionale è quindi composto da un insieme di tabelle. All’ interno di queste vengono definiti i campi (o attributi, n-ple), i quali sono destinati ad ospitare campi di natura omogenea. All’ interno di un certo campo può essere contenuto un solo tipo di dato. Per ottenere il risultato che ci poniamo, è quasi sempre necessario fare uso di più campi di tipo differente. Ma la differenza fondamentale tra i vari campi non è nel tipo, che pure rappresenta già una grande differenza, ma nel ruolo del campo. D’ altra parte è chiaro già dall’ espressione che è stata usata: tipo, cioè attributo-ed un campo è di per sé un attributo del record, almeno secondo la terminologia usata sopra-e ruolo, cioè compito svolto all’ interno non del record ma dell’insieme di tabelle che costituisce il sistema di database relazionale. Esistono tre ruoli possibili per un campo che passiamo subito a precisare:

  1. 1.    ruolo banale, notabilmente quello di attributo

  2. 2.    chiave primaria, è un campo o un gruppo di campi il cui valore deve essere unico tra le righe di una tabella

  3. 3.    chiave straniera, è un campo o un gruppo di campi che assume un valore scelto tra quelli contenuti in una tabella scelta in un particolare gruppo di tabelle dette tabelle entità.

Riassumendo il ruolo della chiave primaria sarà quello di identificare univocamente tutte le righe di una tabella, stabilendo una corrispondenza biunivoca tra i valori assunti dalla chiave primaria e le righe della tabella, mentre il ruolo della chiave straniera è quello di ospitare valori ricevuti dalla chiave primaria di una qualche tabella. Va notato quindi che il modello relazionale non consente righe duplicate all’ interno di una relazione, ossia due record non possono essere identici in tutti i loro attributi. Inoltre ogni relazione ha una chiave primaria nel senso stretto, costituita da tutti i campi della relazione. Questa forma degenerata di chiave primaria non ha nessun tipo di utilità, per cui di seguito fisseremo l’ attenzione solo su chiavi primarie semplici, cioè costituite da uno, al massimo due campi di una data tabella.

Tabelle entità e tabelle associazione


A seguito della distinsione tra chiavi primarie e straniere, le tabelle si dividono tra tabelle entità e tabelle associazione. Le tabelle entità rappresentano oggetti del mondo reale che vogliamo caratterizzare con dei campi o attributi. Ogni record della tabella entità rappresenta dunque uno ed uno solo di questi oggetti del mondo reale. Le tabelle associazione servono invece per rappresentare le relazioni che intercorrono tra oggetti di tipo diverso contenuti nel sistema di database relazionale. Per quanto detto sopra essi sono contenuti in differenti tabelle entità. Per estensione, dunque, le tabelle associazione servono in qualche modo a memorizzare la relazione esistente tra due oggetti diversi, contenuti nel nostro sistema.

Bisogna dire però che non tutte le relazioni richiedono tabelle associazione. Infatti è possibile e anzi capita molto di frequente di realizzare relazioni aggiungendo una o più chiavi straniere in una tabella entità. Tali relazioni uno ad uno ed uno a molti sono dette relazione dirette, per distinguerle da quelle indirette molti a molti che necessitano di una o più tabelle associazione, come vedremo più oltre.


Dominio dei valori ed Integrità referenziale


Se dal punto di vista teorico il concetto di relazione è un concetto chiave per la teoria dei sistemi di database relazionale, dal punto di vista pratico quello di integrità referenziale ha lo stesso tipo di importanza.

Il motore del database, negli strati interno e concettuale, effettua dei controlli sui dati immessi all’ interno dei campi. Come abbiamo detto precedentemente lo spostamento di compiti dallo strato esterno verso strati via via più interni dell’ architettura a tre livelli, semplifica il lavoro di sviluppo dei programmi, ossia lo scopo ultimo della nostra attività. Maggiore è la quantità dei controlli sui dati che spostiamo dall’ esterno all’interno, maggiore sarà la semplificazione che otteniamo. Due compiti essenziali del nostro motore sono dunque i seguenti:



  1. 1.    verificare la correttezza delle chiavi straniere, e gestire le corrispondenti eccezzioni-controllo di integrità referenziale

  2. 2.    verificare l’ appartenenza degli attributi ai corrispondenti insieme di valori-controllo di validità

L’ integrità referenziale è un insieme di vincoli che vengono fissati sulle chiavi straniere: una chiave straniera contenuta in una tabella deve ospitare solo i valori contenuti nella corrispondente tabella entità. Tolgliendo questo vincolo il database non è più relazionale, anche se resta un sistema di database. La validità dei dati corrisponde in ultima analisi alla validità del tipo, più la validità del valore assunto. Tanto per fare un esempio nel campo ‘data_nascita’ di un ufficio anagrafico non deve essere possibile inserire il valore ‘Giuseppe Aielli’, e, una volta che ci si decide di inserire una data, non deve essere possibile inserire ‘300 a.C.’, ma solo una data successiva ad es. a ‘01-01-1850’. E’ da notare come, se noi togliamo questo secondo tipo di controllo dal nostro sistema di database, esso non è più un sistema di database, essendo degenerato in un archivio puro e semplice, cioè un insieme di file ed indici.

Normalizzazione


Buona parte del lavoro di ricerca svolto negli anni 80 a proposito dei sistemi di database relazionale fu svolto sul concetto di normalizzazione relazionale. Come abbiamo visto nel caso precedente un sistema di database relazionale può degenerare fino al ruolo di sistema di file ed indici, semplicemente per nostra scelta o ignoranza. Questo significa che un sistema di database relazionale non è in grado da solo di svolgere il compito di ottimizzare il suo funzionamento più esterno. Un passo di importanza fondamentale da compiere verso la creazione di un database relazionale è quindi quello di normalizzare il suo schema, cioè quello di ottenere la migliore rappresentazione concettuale possibile dei dati, sotto forma di tabelle entità, associazioni e relazioni. L’ essenza della normalizzazione, che si vedrà in dettaglio più avanti, è quella di dividere i dati contenuti in tabelle con tante colonne, in più tabelle ciascuna con un numero di colonne inferiore. Questo diventa necessario quando troppe informazioni sono rappresentate in una sola tabella, quando la rappresentazione dei dati può portare confusione, quando la stessa informazione è presente in più posti differenti, oppure quando le informazioni sono male associate tra loro. Si noti come ad esempio la duplicazione di una stessa informazione all’ interno di un sistema di database conduce come conseguenza più immediata ad un potenziale conflitto tra le due fonti, ed ad uno spreco di spazio e di risorse. Per fortuna sono state definite una serie di regole formali dette forme normali, col lo scopo di eliminare problemi ed errori nella definizione dello schema. Tali forme normali, per la loro estrema importanza, saranno oggetto di trattazione successiva.

Proprietà delle tabelle


Il modello relazionale deriva molta della sua semplicità da tre proprietà delle tabelle:

  1. 1.    le tabelle sono insiemi nel senso matematico: le righe sono uniche e non sono ordinate

  2. 2.    gli attributi non sono ordinati: si indicano col nome, ed il nome deve essere unico all’ interno di una tabella

  3. 3.    i valori assunti dai campi sono atomici: un campo non può contenere al suo interno un insieme (I forma normale).

Proprio a causa della matemeticità del modello relazionale è stata possibile la realizzazione di motori di database relazionali in grado di assolvere in modo efficiente al compito di memorizzare ed elaborare le informazioni. Questo ultimo compito viene poi svolto in modo elegante dalla formulazione di un semplice linguaggio di interrogazione, l’ SQL.
Accesso concorrente e recupero
Introduzione

Controllo dell’ accesso concorrente e recupero sono due caratteristiche molto importanti per un sistema di database relazionale. Esse contribuiscono a mantenere l’ integrità logica e fisica di un database, rispettivamente. Il recupero di un sistema di database relazionale consiste nella capacità di ripristinare il funzionamento dopo un errore grave del sistema. Molte sono le ragioni che possono condurre ad un crash di sistema, e non è il caso di analizzarle in questa sede. Preso atto di questa eventualità e del fatto che i sistemi di database relazionale sono particolarmente delicati a causa della loro natura estremamente precisa, è necessario attuare essenzialmente due politiche:

  1. 1.    backup dei dati sistematico ed affidabile

  2. 2.    uso delle transazioni, se supportate dal sistema.

Sul primo rimedio niente da dire. Il secondo consiste nella capacità del sistema di database relazionale di effettuare le operazioni a blocchi. Per cui se non si riesce ad effettuare tutto il blocco di operazioni, allora le operazioni saranno annullate per tutto il blocco corrente, ripristinando la situazione esistente prima di effettuare la transazione.

Il controllo di concorrenza, invece, si occupa della gestione degli aggiornamenti e modifiche dei dati da parte di molti utenti contemporaneamente, tramite il meccanismo del blocco dei dati. Nel caso più semplice si tratta di porre un blocco esclusivo per il numero di record coinvolti da una certa operazione, da parte di un certo utente: tutti gli altri utenti non saranno in grado di modificare i record bloccati fino al termine di quella operazione. Esistono due tipi di blocco:



  •        Fisico: avviene in modo esplicito a livello di record, di pagina o di tabella

  •        Logico: è definito da una espressione in una query che definisce un set di record da bloccare

Il tipo di blocco utile per una certa operazione dipende da questa nel seguente modo:

  1. 1.    il blocco di una intera tabella è quello più efficiente dal punto di vista computazionale, ma comporta la minore flessibilità possibile, perchè solo un utente alla volta può modificare i dati contenuti nella tabella

  2. 2.    il blocco di un singolo record è il meno efficace dal punto di vista computazionale, ma il più flessibile per l’ uso

  3. 3.    il blocco di una pagina rappresenta una scelta vantaggiosa dal punto di vista computazionale, senza sacrificare quasi nulla della flessibilità del sistema, dal momento che i record sono registrati sul disco sotto forma di pagine fisiche costituite da più record alla volta.

Il blocco dei record può condurre a situazioni di errore, laddove due o più utenti richiedano sistematicamente il blocco di un certo record o di una certa pagina: l’ utente A potrebbe attendere che B rilasci una certa pagina e viceversa. Questa è detta situazione di deadlock.
Transazioni

Molti sistemi di database relazionale implementano meccanismi di transazione, che provvedono contemporaneamente al recupero ed al blocco delle informazioni. Il nome di transazione proviene probabilmente dall’ esempio classico in letteratura che viene di seguito riproposto: bisogna trasferire una somma da un conto di un certo cliente a quello di un certo fornitore-si tratta di una transazione anche nel linguaggio bancario commerciale.

In che modo il sistema di database realizza tale tipo di operazione? Il sistema è in uno stato consistente all’ inizio ed alla fine della operazione, il che vuol dire che i due stati iniziali e finali sono coerenti con la realtà dei fatti, anche se può esserci inconsistenza per brevi (ed invisibili) istanti durante l’operazione, per esempio quando il conto del cliente è stato già addebitato e quello del fornitore non è stato ancora accreditato. Per chi pensa che la soluzione sia di eseguire contemporaneamente le due operazioni bisogna tenere conto che in primo luogo non è possibile eseguire due operazioni contemporaneamente sulla stessa macchina a causa della natura essenzialmente seriale di questa, ed in secondo luogo, se anche fosse, non si avrebbe la garanzia che le operazioni vengano entrambe eseguite correttamente. La soluzione consiste quindi nel rendere le due operazioni una sola operazione logica, detta transazione. La transazione sarà completata solo quando entrambe le operazioni sono entrambe completate correttamente. In caso contrario sarà annullata l’ intera operazione. Le transazioni sono la migliore soluzione possibile al problema del controllo di accesso e della coerenza dei dati, perché l’ utente finale non deve avere a che fare con blocco, sblocco, backup ed altro. Nel campo dei sistemi di database relazionale l’ uso delle transazioni porta solo dei benefici e non è soggetta a nessuna limitazione, senza contare che i meccanismi interni al motore che implementano le transazioni possono anche rendere più efficienti molte elaborazioni a causa della bufferizzazione delle operazioni che viene effettuata durante un ciclo di transazioni.


Database distribuiti


Il termine database distribuito viene usato di solito con vari significati differenti. Noi intendiamo per database distribuito un database che abbia almeno le due seguenti caratteristiche: possibilità di accesso da remoto e capacità di gestire un unico database suddiviso su più di una macchina.
Accesso remoto

La maggior parte dei sistemi di database supportano l’ accesso remoto. Ciò significa che l’ utente di un certo programma attinge o manipola dei dati che non risiedono sulla macchina che stà usando, ma su una macchina lontana che può trovarsi sulla sua stessa rete locale o anche su una rete differente. Il tutto senza che l’ utente possa percepire questo fatto, cioè come si dice in gergo, ‘in modo trasparente’. In altre parole egli ‘vede’ dati locali o remoti esattamente nello stesso modo, perché il software rende ‘invisibile’ il processo di comunicazione che avviene con la macchina lotana.

Il meccanismo attraverso il quale un database riesce ad implementare questa funzionalità è molto semplice: solo una piccola parte del sistema di database relazionale risiede con il programma applicativo nella macchina dell’ utente, detta client. Questa porzione di applicazione è responsabile essenzialmente della visualizzazione dei dati e della codifica di query da inviare alla macchina remota, detta server, che gli restituisce poi i risultati sotto forma di record, sempre tramite la rete (locale o no) attraverso la quale aveva ricevuto le ‘richieste’. Esistono poi delle complicazioni addizionali dovute alla natura eterogenea di alcune reti, in particolar modo per quello che riguarda le reti basate su Internet. Attualmente una soluzione che ha preso molto piede consiste nell’ usare i meccanismi di comunicazione intrinseci di Internet per effettuare il dialogo detto prima: il client invia le richieste tramite meccanismi interni come il metodo POST o la posta elettronica (e-mail) e riceve le risposte direttamente in HTML dal server.


Partizionamento

Si definisce ‘database distribuito’ un insieme di database che appaiono all’ utente come un unico database. Nel caso più semplice i database possono essere su di una unica macchina e possono anche essere ridotti al numero di uno. In questo caso si parla di replicazione di database. Più in generale però si verifica il caso che i database risiedano su macchine differenti in quanto la caratteristica principale del partizionamento consiste nel voler distribuire il carico di lavoro tra differenti macchine server, con l’ evidente scopo di ottimizzare il processo complessivo. L’ evidente condizione per realizzare efficientemente il partizionamento di un database è:

  1. 1.    che vi sia un partizionamento logico dei dati, cioè che la suddivisione abbia senso dal punto di vista organizzativo prima ancora che tecnico

  2. 2.    che la necessità di comunicazione esistente tra le parti da separare sia piccola o nulla

Mancare la prima condizione è un errore che porta confusione dello schema del database. A questo punto se anche vi fossero dei benefici dal punto di vista computazionale-comunicativo sicuramente si avranno svantaggi nello sviluppo dei programmi. Invece mancare la seconda condizione significa che se anche miglioriamo il processo dal punto di vista computazionale, sicuramente lo peggioriamo da quello della comunicazione, e quindi nel complesso non apportiamo miglioramenti molto significativi.

Dentro le condizioni dette prima il partizionamento di un database:



  1. 1.    consente a ciascun reparto di organizzare in modo autonomo le strutture dei dati ed i meccanismi relativi al loro impiego

  2. 2.    consente ancora di effettuare query ed analisi su tutto il complesso dei dati ed in modo trasparente, con la gli stessi meccanismi e con la stessa semplicità di un sistema di database non partizionato.

I database possono essere partizionati in una varietà di modi. Ricordiamo brevemente i principali:

  1. 1.    tabelle differenti in database differenti-partizionamento semplice

  2. 2.    la stessa tabella separata in due o più database con alcune righe da una parte e le altre da un’ altra-partizionamento orizzontale

  3. 3.    la stessa tabella separata in due o più database con alcune colonne da una parte e le altre dall’ altra-partizionamento verticale

  4. 4.    la stessa tabella in più copie sincronizzate su macchine differenti-replica.

Download 98 Kb.

Do'stlaringiz bilan baham:
  1   2   3




Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©fayllar.org 2022
ma'muriyatiga murojaat qiling