Un certo numero di caratteristiche distinguono l’approccio con basi di dati dall’approccio tradizionale della programmazione con file. Nella tradizionale gestione file ciascun utente definisce ed implementa i file necessari per una specifica applicazione, come parte della programmazione dell’applicazione.
Natura autodescrittiva di un sistema di basi di dati. Una caratteristica fondamentale è che il sistema di basi di dati contiene non solo la base di dati ma anche un definizione o descrizione completa della sua struttura e dei suoi vincoli. Questa definizione è memorizzata nel catalogo del sistema, che contiene informazioni come la struttura di ciascun file, il tipo e il formato di memorizzazione di ciascun datoo e vari vincoli sui dati. Le informazioni memorizzate nel catalogo sono dette metadati e descrivono la struttura della base di dati principale.
Il catalogo è usato dal software DBMS e anche dagli utenti della base di dati che hanno bisogno di informazioni sulla struttura della stessa – il valore attuale di un certo tipo di gas, che potrebbe far scattare una regola reattiva (trigger) se una certa soglia è stata imposta in fase di configurazione iniziale, etc.
Nella tradizionale gestione file, la definizione dei dati è tipicamente parte dei programmi applicativi. Di conseguenza questi programmi sono costretti a lavorare solo con una base di dati specifica, la cui struttura è dichiarata nei programmi applicativi.
Al contrario, i programmi di accesso DBMS nella maggioranza dei casi non richiedono cambiamenti di tutti i programmi che accedono ad una determinata struttura. La struttura dei file di dati è memorizzata nel DBMS separatamente dai programmi di accesso. Tale proprietà è chiamata indipendenza tra programmi e dati.
Nelle basi di dati orientate ad oggetti ed in quelle relazionali e ad oggetti gli utenti possono definire le operazioni sui dati come parte delle definizioni della base di dati. Un’operazione è specificata in due parti. L’interfaccia di un’operazione comprende il nome dell’operazione e i tipi di dati dei suoi argomenti (o parametri). L’implementazione (o metodo) dell’operazione è specificata separatamente e può essere cambiata senza interessare l’interfaccia. I programmi applicativi dell’utente possono operare sui dati invocando queste operazioni attraverso i loro nomi e argomenti, indipendentemente da come le operazioni stesse siano implementate. Questo fatto può essere definito indipendenza tra programmi e operazioni.
Questa caratteristica risulterà essenziale per le caratteristiche di qualità di estendibilità, modularità, scalabilità, etc. dell’interazione tra utente e stazione remota. Una separazione dei contesti opportuna consente, una volta definite le corrette interfacce, lo sviluppo indipendente (o quasi) delle due parti.
La caratteristica che consente l’indipendenza tra programmi e dati e l’indipendenza tra programmi e operazioni è detta astrazione dei dati. Un DBMS fornisce agli utenti una rappresentazione concettuale dei dati che non comprende inizialmente molti dettagli su come i dati sono memorizzati e su come le operazioni sono implementate. Nella fase iniziale, è stata posta una forte attenzione a quest’aspetto che si è mostrato estremamente dinamico ed evolvibile. Informalmente, un modello di dati è un tipo di astrazione dei dati usato per fornire questa rappresentazione concettuale.
Supporto di viste multiple dei dati. Il sistema di gestione SMoG avrà, con ogni probabilità, molti utenti, ciascuno dei quali può richiederne una diversa prospettiva o vista. Una vista può essere un sottoinsieme della base di dati o può contenere dati virtuali che sono derivati dai file della base di dati ma che non sono esplicitamente memorizzati. Talvolta può non essere necessario rendere consapevoli gli utenti del fatto che i dati a cui si riferiscono sono memorizzati piuttosto che derivati da altri. Il DBMS multiutente i cui utenti hanno una molteplicità di applicazioni deve fornire funzioni per definire viste multiple. Un utente, ad esempio, può essere interessato (oppure è condizionato da una politica di permessi specifica) a visualizzare solo le informazioni rigurdanti certi gas potenzialmente nocivi, un secondo utente alle informazioni ambientali, un terzo ancora alle immagini provenienti dalle telecamere termiche, e così via.
Condivisione dei dati ed elaborazione delle transazioni con utenti multipli. Il DBMS multiutente, come suggerisce il nome stesso, deve consentire a più utenti di accedere contemporaneamente alle basi di dati. La cosa è essenziale se dati per applicazioni multiple devono essere integrati e mantenuti in una singola base di dati. Il DBMS deve contenere un software per il controllo della concorrenza che garantisca che più utenti che cerchino di aggiornare gli stessi dati lo possano fare in maniera controllata, cosicchè il risultato degli aggiornamenti sia corretto. L’ applicazione in esame appartiene, sommariamente, alla categoria di applicazioni dette di elaborazione delle transazioni in linea (OLTP: on-line transaction processing). Una funzione fondamentale del software di un DBMS multiutente è quella di assicurare che le transazioni concorrenti operino correttamente.
Elenchiamo alcune delle funzionalità implementate per il sistema in questione:
Natura autodescrittiva di un sistema di basi di dati. Una caratteristica fondamentale è che il sistema di basi di dati contiene non solo la base di dati ma anche un definizione o descrizione completa della sua struttura e dei suoi vincoli. Questa definizione è memorizzata nel catalogo del sistema, che contiene informazioni come la struttura di ciascun file, il tipo e il formato di memorizzazione di ciascun datoo e vari vincoli sui dati. Le informazioni memorizzate nel catalogo sono dette metadati e descrivono la struttura della base di dati principale.
Il catalogo è usato dal software DBMS e anche dagli utenti della base di dati che hanno bisogno di informazioni sulla struttura della stessa – il valore attuale di un certo tipo di gas, che potrebbe far scattare una regola reattiva (trigger) se una certa soglia è stata imposta in fase di configurazione iniziale, etc.
Nella tradizionale gestione file, la definizione dei dati è tipicamente parte dei programmi applicativi. Di conseguenza questi programmi sono costretti a lavorare solo con una base di dati specifica, la cui struttura è dichiarata nei programmi applicativi.
Al contrario, i programmi di accesso DBMS nella maggioranza dei casi non richiedono cambiamenti di tutti i programmi che accedono ad una determinata struttura. La struttura dei file di dati è memorizzata nel DBMS separatamente dai programmi di accesso. Tale proprietà è chiamata indipendenza tra programmi e dati.
Nelle basi di dati orientate ad oggetti ed in quelle relazionali e ad oggetti gli utenti possono definire le operazioni sui dati come parte delle definizioni della base di dati. Un’operazione è specificata in due parti. L’interfaccia di un’operazione comprende il nome dell’operazione e i tipi di dati dei suoi argomenti (o parametri). L’implementazione (o metodo) dell’operazione è specificata separatamente e può essere cambiata senza interessare l’interfaccia. I programmi applicativi dell’utente possono operare sui dati invocando queste operazioni attraverso i loro nomi e argomenti, indipendentemente da come le operazioni stesse siano implementate. Questo fatto può essere definito indipendenza tra programmi e operazioni.
Questa caratteristica risulterà essenziale per le caratteristiche di qualità di estendibilità, modularità, scalabilità, etc. dell’interazione tra utente e stazione remota. Una separazione dei contesti opportuna consente, una volta definite le corrette interfacce, lo sviluppo indipendente (o quasi) delle due parti.
La caratteristica che consente l’indipendenza tra programmi e dati e l’indipendenza tra programmi e operazioni è detta astrazione dei dati. Un DBMS fornisce agli utenti una rappresentazione concettuale dei dati che non comprende inizialmente molti dettagli su come i dati sono memorizzati e su come le operazioni sono implementate. Nella fase iniziale, è stata posta una forte attenzione a quest’aspetto che si è mostrato estremamente dinamico ed evolvibile. Informalmente, un modello di dati è un tipo di astrazione dei dati usato per fornire questa rappresentazione concettuale.
Supporto di viste multiple dei dati. Il sistema di gestione SMoG avrà, con ogni probabilità, molti utenti, ciascuno dei quali può richiederne una diversa prospettiva o vista. Una vista può essere un sottoinsieme della base di dati o può contenere dati virtuali che sono derivati dai file della base di dati ma che non sono esplicitamente memorizzati. Talvolta può non essere necessario rendere consapevoli gli utenti del fatto che i dati a cui si riferiscono sono memorizzati piuttosto che derivati da altri. Il DBMS multiutente i cui utenti hanno una molteplicità di applicazioni deve fornire funzioni per definire viste multiple. Un utente, ad esempio, può essere interessato (oppure è condizionato da una politica di permessi specifica) a visualizzare solo le informazioni rigurdanti certi gas potenzialmente nocivi, un secondo utente alle informazioni ambientali, un terzo ancora alle immagini provenienti dalle telecamere termiche, e così via.
Condivisione dei dati ed elaborazione delle transazioni con utenti multipli. Il DBMS multiutente, come suggerisce il nome stesso, deve consentire a più utenti di accedere contemporaneamente alle basi di dati. La cosa è essenziale se dati per applicazioni multiple devono essere integrati e mantenuti in una singola base di dati. Il DBMS deve contenere un software per il controllo della concorrenza che garantisca che più utenti che cerchino di aggiornare gli stessi dati lo possano fare in maniera controllata, cosicchè il risultato degli aggiornamenti sia corretto. L’ applicazione in esame appartiene, sommariamente, alla categoria di applicazioni dette di elaborazione delle transazioni in linea (OLTP: on-line transaction processing). Una funzione fondamentale del software di un DBMS multiutente è quella di assicurare che le transazioni concorrenti operino correttamente.
Elenchiamo alcune delle funzionalità implementate per il sistema in questione:
- Controllo della ridondanza: memorizzare più volte gli stessi dati porta a numerosi problemi. Primo, c’è la necessità di eseguire un singolo aggiornamento logico molte volte: n-plicazione degli sforzi. Secondo, si spreca spazio di memoria quando gli stessi dati sono memorizzati ripetutamente, e questo problema può essere serio per basi di dati di grandi dimensioni. Terzo, file che rappresentano gli stessi dati possono diventare inconsistenti. Questo può accadere perché un aggiornamento è applicato ad alcuni file ma non ad altri. E’ tuttavia necessario notare che, in alcuni casi, una ridondanza controllata può essere utile per migliorare le prestazioni delle interrogazioni;
- Divieto all’accesso non autorizzato: quando più utenti condividono una base di dati, è verosimile che ad alcuni non sarà permesso di accedere a tutte le informazioni in essa contenute. Ad alcuni utenti può essere permesso solo di recuperare dati, mentre ad altri sarà permesso sia di recuperarli sia di aggiornarli. Il DBMS è stato quindi progettato per fornire un sottosistema per la sicurezza e l’autorizzazione;
- Memorizzazione persistente di oggetti e strutture dati: la memorizzazione persistente di oggetti di programmi e strutture di dati è una funzione importante del sistema.
- Definizione di regole di inferenza e regole che usano azioni: la progettazione prevede la fruizione di servizi che definiscono regole di deduzione in modo da inferire nuove informazioni dai fatti memorizzati nella base di dati. Un sistema di questo tipo è detto sistema di basi di dati deduttive. Ad esempio, potranno esserci regole complesse nell’applicazione del mini-mondo per determinare quando un determinato gas supera il livello di soglia. Tali regole possono essere specificate con dichiarazioni esplicite come regole, che una volta compilate e mantenute nel DBMS sono in grado di determinare tutti i gas che superano la relativa soglia. A questo punto di vista procedurale, si è deciso anche di affiancare un paradigma più dinamico, che tenga conto del fatto che le regole possono cambiare e cambieranno. Una funzionalità più potente è fornita dai sistemi di basi di dati attive, che forniscono regole attive che possono automaticamente dar inizio ad azioni;
- Disponibilità di numerose interfacce utente: poiché il sistema è utilizzato da più utenti, con svariati livelli di conoscenza tecnica, un DBMS dovrebbe fornire una molteplicità di interfacce utente. Queste includono linguaggi di interrogazione per utenti casuali, interfacce a linguaggi di programmazione per programmatori di applicazioni, moduli (forms) e codici di comando per utenti parametrici, etc.
- Rappresentazione di associazioni complesse fra dati: il sistema comprende numerose varietà di dati associati in molti modi e dovrà pertanto essere in grado di rappresentare una varietà di associazioni complesse tra dati, così come di recuperare e aggiornare i dati correlati facilmente ed efficientemente;
- Imposizioni di vincoli di integrità: il sistema presenta vincoli di integrità che devono valere per i dati. Il DBMS fornisce i servizi per definire ed imporre questi vincoli. Il tipo più semplice di vincolo di integrità comporta la specificazione di un tipo di dati per ciascun dato. Un tipo più complesso di vincolo, che si presenta frequentemente, comporta la specificazione che un record in un file deve essere correlato a record in altri file;
- Fornitura di backup e recovery: Il sistema fornisce funzioni di ripristino da guasti hardware e software. Il sottosistema di backup (salvataggio) e recovery (ripristino) del DBMS è responsabile del ripristino.