close

Sistema di gestione delle banche dati

Vai alla navigazione Vai alla ricerca

Un sistema di gestione di database o DBMS ( dall'inglese : Data Base Management System o DBMS) è un software che consente di gestire un database . Ciò significa che attraverso questo programma è possibile utilizzare, configurare ed estrarre le informazioni memorizzate [ 1 ] . Gli utenti possono accedere alle informazioni utilizzando specifici strumenti di generazione di query e report o tramite applicazioni a tale scopo.

Questi sistemi forniscono anche metodi per mantenere l'integrità dei dati, per gestire l'accesso degli utenti ai dati e per recuperare le informazioni in caso di danneggiamento del sistema. Consentono di presentare le informazioni del database in vari formati. La maggior parte include un generatore di rapporti. Possono anche includere un modulo grafico che permette di presentare le informazioni con grafici e tabelle.

L'accesso ai dati avviene generalmente attraverso linguaggi di query, linguaggi di alto livello che semplificano il compito di creare applicazioni. Semplificano inoltre le interrogazioni e la presentazione delle informazioni. Un DBMS consente di controllare l'accesso ai dati, garantirne l'integrità, gestire l'accesso simultaneo, recuperare i dati dopo un errore del sistema ed eseguire copie di backup. I database e i loro sistemi di gestione sono essenziali per qualsiasi area di business e devono essere gestiti con attenzione.

Introduzione

I database generalmente funzionano su computer dedicati esclusivamente a questo campo. A causa delle funzionalità richieste, generalmente funzionano su computer multiprocessore con molta memoria .

Per l'archiviazione dei dati è possibile disporre dei propri sistemi su disco o dell'archiviazione diretta collegata ( DAS ), è possibile connettersi a una rete di archiviazione ( SAN ) o connettersi a un sistema di archiviazione di rete ( NAS ).

Esistono acceleratori hardware , utilizzati nei grandi sistemi di elaborazione delle transazioni. I DBMS sono al centro di qualsiasi applicazione che gestisce i dati. I DBMS si basano su sistemi operativi standard per svolgere queste funzioni.

Storia

I database sono stati utilizzati sin dai primi giorni dei computer elettronici. A differenza dei sistemi moderni, che possono essere applicati a dati ed esigenze molto diversi, la maggior parte dei sistemi originali erano focalizzati su database specifici e progettati per guadagnare velocità a costo di perdere flessibilità. Il DBMS originale era disponibile solo per le grandi organizzazioni che potevano permettersi i computer complessi necessari.

Sistemi di navigazione (1960)

Man mano che i computer guadagnavano velocità e capacità, apparvero sistemi di database generici; a metà degli anni '60 alcuni sistemi erano già in uso. Sorse l' interesse per uno standard e Charles Bachman, autore di uno dei primi prodotti, l' Integrated Data Store (IDS), fondò il Database Task Group all'interno di CODASYL , il gruppo responsabile della creazione e della standardizzazione di COBOL. Nel 1971 pubblicarono il loro standard, che divenne noto come "approccio CODASYL", e presto apparvero alcuni prodotti basati su questa linea.

La strategia di CODASYL si basava sulla navigazione manuale attraverso un set di dati in rete. Quando il database è stato avviato, il programma ha restituito un collegamento al primo record nel database, che a sua volta conteneva puntatori ad altri dati. Per trovare un record specifico, il programmatore doveva seguire i puntatori fino a raggiungere il record cercato.

Per rispondere a semplici domande come "trova tutte le persone in Giappone", il programma ha dovuto esaminare tutti i dati per selezionare i record giusti. Non esistevano "cerca" o "trova", qualcosa che oggi sarebbe inaccettabile, ma ai tempi in cui i dati erano archiviati su nastro non era possibile metterli in pratica.

Sono state trovate soluzioni a molti di questi problemi. Il produttore Prime ha creato un DBMS adattato a CODASYL basato su alberi binari che hanno abbreviato la navigazione da un record all'altro fornendo percorsi di accesso alternativi. Ha anche fornito un linguaggio di query molto chiaro. In effetti, non c'è motivo per cui i concetti di normalizzazione non possano essere applicati ai database CODASYL, ma CODASYL alla fine era molto complesso e richiedeva molti sforzi e pratica per produrre un'applicazione utile.

IBM aveva anche il proprio DBMS nel 1968, noto come IMS . Era un software sviluppato per il programma Apollo su System/360. IMS aveva concetti simili a CODASYL, ma utilizzava una rigida gerarchia di ordinamento dei dati, in contrasto con la struttura di rete di CODASYL. Entrambi i concetti furono successivamente inclusi nel concetto di database di navigazione per via della modalità di accesso ai dati, infatti Bachman ricevette il premio Turing nel 1973 per il suo articolo Il programmatore come browser . [ 2 ]

Sistemi relazionali (1970)

Image
Esempio di tabella nel modello relazionale .

Edgar Codd ha lavorato in IBM, in una di quelle sedi periferiche che si dedicava principalmente allo sviluppo di dischi rigidi. Non ero soddisfatto del modello di navigazione CODASYL, principalmente per la mancanza di un'operazione di ricerca. Nel 1970 scrive alcuni articoli che delineano un nuovo approccio culminato nel documento "Un modello relazionale di dati per grandi banche dati condivise". [ 3 ]

In questo articolo, hai scoperto un nuovo sistema per l'archiviazione e l'utilizzo di database di grandi dimensioni. Invece di memorizzare record di tipo arbitrario in un elenco concatenato come in CODASYL, l'idea di Codd era quella di utilizzare una "tabella" di record di dimensioni fisse. Un elenco concatenato ha un'efficienza molto scarsa quando si archiviano dati sparsi in cui alcuni dei dati in un record potrebbero essere lasciati vuoti. Il modello relazionale risolve questo problema dividendo i dati in una serie di tabelle normalizzate, o relazioni, in cui gli elementi opzionali sono stati estratti dalla tabella principale in modo che occupino spazio solo se necessario. In questo modello relazionale, i record correlati sono collegati con una "chiave".

Un uso comune dei database può essere quello di mantenere un elenco di utenti, il loro nome, informazioni di accesso, indirizzo e numero di telefono. Nella soluzione di navigazione tutti i dati sarebbero ubicati in un unico record e le funzioni non utilizzate semplicemente non sarebbero nel database. Nella soluzione relazionale, i dati verrebbero normalizzati in una tabella utenti, un telefono e una tabella indirizzi, in cui verrebbero aggiunti record se dovessimo incorporare telefono e indirizzo.

Riconciliare tutte le informazioni è la chiave di questo sistema. Nel modello relazionale, una parte delle informazioni viene utilizzata come chiave, identificando biunivocabilmente uno specifico record. Quando vengono raccolte informazioni su un utente, sarà possibile accedere alle informazioni nelle tabelle opzionali effettuando la ricerca utilizzando quella chiave. Ad esempio, se il nome utente è univoco, l'indirizzo e il numero di telefono dell'utente verranno memorizzati con il nome utente come password. La compilazione di queste informazioni in un unico record è qualcosa a cui le lingue tradizionali non sono destinate.

Proprio come l'approccio di navigazione richiede programmi che raccolgono record in loop, anche l'approccio relazionale li richiederà. La soluzione di Codd per i cicli necessari si basa su un linguaggio orientato agli insiemi, un suggerimento che si sarebbe poi cristallizzato nell'onnipresente SQL. Propose l'uso di un ramo dell'algebra chiamato tuple calculus, e mostrò che con esso si potevano eseguire tutte le operazioni tipiche su un database, oltre ad estrarre insiemi di dati in modo semplice.

L'articolo di Codd è caduto nelle mani di due persone a Berkeley, Eugene Wong e Michael Stonebraker. Hanno avviato un progetto chiamato INGRES con fondi assegnati a un progetto di database geografico programmato dagli studenti. A partire dal 1973, INGRES ha prodotto le sue prime versioni di test che erano pronte per l'uso generale nel 1979. INGRES era molto simile a System R di IBM sotto diversi aspetti, incluso un linguaggio di accesso ai dati noto come QUEL. Nel tempo, INGRES ha adottato lo standard SQL.

IBM ha realizzato un'implementazione di prova del modello relazionale —PRTV— e uno di produzione —Business System 12— entrambi sospesi. Honeywell ha scritto MRDS per Multics e stanno comparendo anche due nuove implementazioni: Alphora Dataphor e Rel . La maggior parte delle altre cosiddette implementazioni DBMS relazionali sono in realtà DBMS SQL.

Negli anni '70 , l' Università del Michigan iniziò lo sviluppo del MICRO Information Management System basato sul modello di dati teorici di DL Childs. Micro è stato utilizzato per gestire grandi quantità di dati nel Dipartimento del lavoro del governo degli Stati Uniti. Funzionava sul mainframe utilizzando il Michigan Terminal System . È stato in produzione fino al 1998 .

Sistemi SQL (fine anni '70)

IBM iniziò a lavorare all'inizio degli anni '70 su un prototipo vagamente basato sui concetti di Codd, chiamandolo System R. La prima versione era pronta nel 1974 o 1975, e quindi iniziò a lavorare su sistemi multi-tabella, in cui i dati potevano essere disaggregati in modo casuale in modo che tutte le informazioni in un record (alcune delle quali sono facoltative) non devono essere archiviate in un unico blocco di grandi dimensioni. Le seguenti versioni multiutente sono state testate dagli utenti nel 1978 e nel 1979, quando un linguaggio SQL era stato standardizzato. Le idee di Codd si sono rivelate operative e superiori a quelle di CODASYL, lanciando IBM nello sviluppo di una vera versione di produzione di System R, nota come SQL/DS, e successivamente come Database 2 (DB2).

Molti dei tecnici INGRES erano sicuri del successo commerciale del sistema e formarono le proprie società per commercializzare lo sviluppo, ma con un'interfaccia SQL. Sybase , Informix , NonStop SQL e INGRES stesso venivano venduti come derivati ​​dell'INGRES originale negli anni 80. Anche SQL Server di Microsoft è basato su Sybase, e quindi INGRES. Solo Larry Ellison , il fondatore di Oracle , ha iniziato un nuovo percorso basato sull'articolo di IBM su System R e ha superato IBM introducendo sul mercato la sua prima versione nel 1978.

Stonebraker ha applicato le lezioni di INGRES allo sviluppo di un nuovo database, Postgres, ora noto come PostgreSQL. PostgreSQL è utilizzato per molte applicazioni critiche (viene utilizzato dai registri di dominio .org e .info per la loro archiviazione primaria, nonché da grandi aziende e istituzioni finanziarie).

In Svezia, l'articolo di Codd ha generato il database Mimer SQL [ 4 ] presso l'Università di Uppsala . Nel 1984 questo progetto è stato consolidato in una società indipendente. All'inizio degli anni '80, Mimer ha introdotto la gestione delle transazioni per rendere robuste le applicazioni, un'idea che è stata ripresa in molti altri DBMS.

Sistemi orientati agli oggetti (1980)

Durante gli anni '80, l'ascesa della programmazione orientata agli oggetti ha influenzato il modo in cui le informazioni venivano gestite nei database. Programmatori e designer hanno iniziato a trattare i dati nei database come oggetti. Ciò significa che se i dati di una persona sono nel database, gli attributi della persona come indirizzo, telefono ed età sono considerati appartenenti alla persona, non sono dati estranei. Ciò consente di stabilire relazioni tra oggetti e attributi, anziché tra singoli campi.

Un altro grande centro di attenzione durante il decennio è stato l'aumento della velocità e dell'affidabilità dell'accesso. Nel 1989, due professori dell'Università del Wisconsin hanno pubblicato un articolo in una conferenza ACM in cui illustravano i loro metodi per migliorare le prestazioni del database. L'idea era di replicare le informazioni importanti e più richieste in un piccolo database temporaneo con collegamenti al database principale. Ciò significava che la ricerca nel database piccolo poteva essere molto più veloce rispetto a quello grande. Le sue prestazioni migliorate hanno portato all'introduzione dell'indicizzazione, incorporata in tutti i DBMS.

Sistemi NoSQL (2000)

Il 21° secolo ha portato una nuova tendenza nei database: NoSQL. Questa tendenza ha introdotto una linea non relazionale significativamente diversa da quelle classiche. In genere non richiedono schemi fissi, evitano operazioni di join archiviando dati denormalizzati e sono progettati per essere ridimensionati orizzontalmente. La maggior parte di essi può essere classificata come archivi di valori-chiave o database orientati ai documenti .

Di recente, c'è stata una grande richiesta di database distribuiti tolleranti alle partizioni, ma secondo il teorema CAP non è possibile ottenere un sistema distribuito che fornisca contemporaneamente coerenza, disponibilità e tolleranza della partizione. Un sistema distribuito può soddisfare solo due dei tre vincoli alla volta. Per questo motivo, molti database NoSQL utilizzano la cosiddetta consistenza eventuale per fornire disponibilità e tolleranza di partizionamento, con un livello massimo di coerenza dei dati.

Le applicazioni popolari includono MongoDB , MemcacheDB , Redis , CouchDB , Hazelcast , Apache Cassandra e HBase , tutte open source.

Sistemi XML (2010)

I database XML formano un sottoinsieme di database NoSQL. Tutti utilizzano il formato di archiviazione XML, che è aperto, leggibile da persone e macchine e ampiamente utilizzato per l'interoperabilità.

In questa categoria troviamo: BaseX, eXist, MarkLogic Server, MonetDB/XQuery, Sedna.

Componenti

  • Il motore di database accetta richieste logiche dagli altri sottosistemi DBMS, le converte nel loro equivalente fisico e accede al database e al dizionario dei dati sul dispositivo di archiviazione.
  • Il sottosistema di definizione dei dati aiuta a creare e mantenere il dizionario di dati e definisce la struttura dei file che supporta il database.
  • Il sottosistema di manipolazione dei dati aiuta l'utente ad aggiungere, modificare ed eliminare informazioni dal database e dalla query per estrarre informazioni. Il sottosistema di manipolazione dei dati è in genere l'interfaccia principale dell'utente al database. Consente all'utente di specificare i propri requisiti di informazione da un punto di vista logico.
  • Il sottosistema di compilazione dell'applicazione contiene utilità per assistere gli utenti nello sviluppo dell'applicazione. Di solito fornisce schermate di immissione dati, linguaggi di programmazione e interfacce.
  • Il sottosistema di amministrazione aiuta a gestire il database fornendo funzionalità quali archiviazione e recupero, gestione della sicurezza, ottimizzazione delle query, controllo della concorrenza e gestione delle modifiche.

Linguaggi di modellazione

Ogni database supportato da un DBMS deve avere schemi modellati correttamente. In concomitanza con l'evoluzione storica dei database, hanno utilizzato diversi modelli. Il DBMS prevede che un determinato modello sia in grado di accedere al database in modo semplice. Questi modelli sono:

  • Gerarchico
  • In rete
  • relazionale
  • multidimensionale
  • di oggetti

Sono state utilizzate anche liste invertite.

Struttura gerarchica

Image
Esempio di un modello di database gerarchico

La struttura gerarchica è stata utilizzata nei DBMS dei primi mainframe . Le relazioni tra i record formano una struttura ad albero. Questa struttura è semplice ma inflessibile poiché le relazioni sono confinate al tipo 1:n. Il sistema IMS di IBM e RDM Mobile di Raima [ 5 ] sono esempi di database con più gerarchie sullo stesso set di dati. RDM Mobile è un nuovo design di database incorporato per una rete di computer mobili. La struttura gerarchica è utilizzata oggi principalmente per memorizzare informazioni geografiche.

Il modello di database gerarchico ha uno schema in cui i dati sono organizzati in una struttura ad albero. Questa struttura permette di rappresentare le relazioni genitore/figlio: ogni genitore può avere più figli, ma ogni figlio deve provenire da un solo genitore (note come relazioni 1:N). Tutti gli attributi di un record specifico sono associati a un tipo di entità. Questo modello è stato creato da IBM nel 1960.

In un database, un tipo di entità è il termine generico per una tabella. Ogni singolo record è rappresentato come una riga e ogni attributo come una colonna. Le entità di tipo sono correlate tra loro utilizzando corrispondenze 1:N.

Attualmente i database gerarchici più utilizzati sono l'IMS di IBM e il registro di Windows di Microsoft .

Struttura della rete

Image
Modello di database di rete

Questa struttura contiene relazioni più complesse di quelle gerarchiche. Ammette relazioni di ogni record con diversi che possono essere seguiti da percorsi diversi. In altre parole, il modello consente N:N relazioni.

Il modello di rete è concepito come un modo flessibile di rappresentare gli oggetti e le loro relazioni. La sua qualità distintiva è che lo schema, visto come un insieme di nodi collegati da archi, non ha restrizioni.

L'inventore di questo modello fu Charles Bachman e lo standard fu pubblicato nel 1969 da CODASYL.

Struttura relazionale

Image
Esempio di tabelle e relazioni.

La struttura relazionale è oggi la più diffusa. Viene utilizzato nei mainframe , nei computer medi e nei microcomputer. Archivia i dati in righe (tuple) e colonne (attributi). Queste tabelle possono essere collegate tra loro tramite chiavi comuni. Mentre lavorava in IBM nel 1972, EF Codd concepì questa struttura. Il modello non è di facile consultazione per l'utente poiché potrebbe richiedere una complessa combinazione di tabelle.

Struttura multidimensionale

Image
Cubi che rappresentano 4 dimensioni in un database multidimensionale

La struttura multidimensionale ha somiglianze con il modello relazionale, ma invece delle due dimensioni riga-colonna, ha N dimensioni. Questa struttura offre l'aspetto di un foglio di calcolo. È facile da gestire e comprendere poiché i registri vengono archiviati nello stesso modo in cui vengono visualizzati. Le sue elevate prestazioni lo hanno reso il database più popolare per l'elaborazione analitica delle transazioni online (OLAP).

Struttura orientata agli oggetti

Image
Esempio di database contenente oggetti ed eredità

La struttura orientata agli oggetti è progettata seguendo il paradigma dei linguaggi orientati agli oggetti. In questo modo supporta in modo naturale tipi di dati grafici, immagine, voce e testo. Questa struttura è ampiamente utilizzata nelle applicazioni web per applicazioni multimediali.

Prima dell'implementazione del DBMS con una struttura orientata agli oggetti, la memorizzazione dei dati multimediali era basata sul file system per organizzare, archiviare ed elaborare i dati. L'elaborazione dei file è ingombrante, costosa e poco flessibile. La ridondanza dei dati è uno svantaggio dell'elaborazione dei file poiché i file indipendenti producono file duplicati con la loro implicazione nello spazio necessario. Un altro inconveniente è la mancanza di integrazione e la difficoltà di manutenzione. Ciò è stato risolto applicando l'orientamento agli oggetti ai dati.

Linguaggi di ricerca

I linguaggi di query e reportistica del database consentono di interrogare il database, analizzare i dati e aggiornarlo in base ai privilegi di ciascun utente. Controlla inoltre la sicurezza del database per impedire l'accesso non autorizzato alla visualizzazione, all'eliminazione o alla modifica dei dati. Attraverso l'utilizzo delle chiavi è consentito l'accesso all'intero database oa parte di esso. Ad esempio, un database dei dipendenti può contenere tutti i dati dei dipendenti, ma solo un gruppo di utenti può essere autorizzato a visualizzare le buste paga mentre altri possono essere autorizzati a visualizzare solo storie lavorative e dati medici o richieste.

Se il DBMS fornisce una modalità per accedere e aggiornare il database, oltre che per consultarlo, consentirà di creare database personali. Tuttavia, mancherebbe la capacità di tracciare le azioni oi controlli necessari richiesti dal database di una grande organizzazione. Questi controlli sono disponibili solo quando un insieme di programmi di supporto monitora gli accessi e gli aggiornamenti ai dati.

Architettura

L'architettura di un DBMS specifica i suoi componenti (compresa la loro descrizione funzionale) e le loro interfacce. Si occupa di concetti diversi rispetto all'architettura del database. I componenti principali di un DBMS sono:

  • Interfacce esterne : significa comunicare con l'SGDB in entrambe le direzioni (I/O) e sfruttarne tutte le funzioni. Possono influenzare il database o il funzionamento del DBMS, ad esempio:
    • operazioni dirette con il database: definizione delle tipologie, assegnazione dei livelli di sicurezza, aggiornamento dei dati, interrogazione del database...
    • operazioni legate al funzionamento del DBMS: backup e ripristino, ripristino dopo un crash, monitoraggio della sicurezza, gestione dello storage, prenotazione dello spazio, monitoraggio della configurazione, monitoraggio delle prestazioni, tuning...
    • le interfacce esterne possono essere utilizzate dagli utenti (es. amministratori) o da programmi che comunicano tramite un'API.
  • Interprete o processore di lingua : la maggior parte delle operazioni viene eseguita utilizzando una lingua di database. Esistono linguaggi per la definizione dei dati, la manipolazione dei dati (es. SQL), per specificare gli aspetti di sicurezza e altro ancora. Le istruzioni in quella lingua vengono immesse nel DBMS tramite l'apposita interfaccia. Le espressioni in detto linguaggio (compilate o interpretate) vengono elaborate per estrarre le operazioni in modo che possano essere eseguite dal DBMS.
  • Query Optimizer: esegue l'ottimizzazione di ogni domanda e sceglie il piano d'azione più efficiente per eseguirla.
  • Motore di database : esegue le operazioni richieste sul database, in genere rappresentandolo a un livello elevato.
  • Meccanismo di archiviazione : traduce le operazioni in un linguaggio di basso livello per accedere ai dati. In alcune architetture il meccanismo di archiviazione è integrato nel motore di database.
  • Motore di transazione : per ottenere correttezza e affidabilità, la maggior parte delle operazioni interne del DBMS vengono eseguite incapsulate all'interno delle transazioni. È possibile specificare transazioni esterne al DBMS per incapsulare un gruppo di operazioni. Il motore delle transazioni segue l'esecuzione delle transazioni e ne gestisce l'esecuzione secondo le regole che ha stabilito (es. controllo della concorrenza e loro esecuzione o cancellazione).
  • Gestione e funzionamento del DBMS : include molte altre componenti che si occupano degli aspetti gestionali e operativi del DBMS come il monitoraggio delle prestazioni, la gestione dello storage, le mappe di archiviazione.

Vedi anche

Riferimenti

  1. "Introduzione al sistema di gestione dei database (SGBD)" . IONOS Guida digitale . Estratto 27-04-2022 . 
  2. ^ Bachman, Charles W. " Il programmatore come navigatore " (in inglese) . Estratto il 17 febbraio 2013 . 
  3. ^ Codd, EF (1970). "Un modello relazionale di dati per grandi banche dati condivise" . In: Comunicazioni dell'ACM 13 (6): 377-387.
  4. ^ " Mimer SQL " (in inglese) . Estratto il 18 febbraio 2013 . 
  5. « Sistema di gestione delle banche dati; Panoramica del prodotto » (in inglese) . Estratto il 19 febbraio 2013 .