Chi ha creato il modello relazionale del DBMS?
doc-4155
Il modello relazionale, proposto per la prima volta nel 1970 da Edgar F. Codd, si discostava da questa tradizione insistendo sul fatto che le applicazioni dovevano cercare i dati per contenuto, piuttosto che seguire link. Il modello relazionale utilizza serie di tabelle in stile libro mastro, ognuna utilizzata per un diverso tipo di entità. Solo verso la metà degli anni' 80 l' hardware informatico è diventato abbastanza potente da consentire l' ampia diffusione di sistemi relazionali (DBMS e applicazioni). All' inizio degli anni Novanta, tuttavia, i sistemi relazionali dominati in tutte le applicazioni di elaborazione dati su larga scala, e dal 2015[aggiornamento] rimangono dominanti: IBM DB2, Oracle, MySQL e Microsoft SQL Server sono i DBMS top. Il linguaggio dominante del database, SQL standardizzato per il modello relazionale, ha influenzato i linguaggi del database per altri modelli di dati.
None
doc-4172
La visione concettuale fornisce un livello di indirezione tra interno ed esterno. Da un lato fornisce una visione comune del database, indipendente dalle diverse strutture di visualizzazione esterne, e dall' altro estrae dettagli su come i dati sono memorizzati o gestiti (livello interno). In linea di principio ogni livello, e anche ogni vista esterna, può essere presentata da un modello di dati diverso. In pratica, di solito un dato DBMS utilizza lo stesso modello di dati sia per i livelli esterni che concettuali (ad esempio, modello relazionale). Il livello interno, che è nascosto all' interno del DBMS e dipende dalla sua implementazione, richiede un diverso livello di dettaglio e utilizza i propri tipi di struttura dati.
None
doc-4158
In questo articolo, ha descritto un nuovo sistema per l' archiviazione e il lavoro con database di grandi dimensioni. Invece di memorizzare i record in una sorta di lista collegata di record liberi come in CODASYL, l' idea di Codd era quella di usare una "tabella" di record a lunghezza fissa, con ogni tabella usata per un diverso tipo di entità. Un sistema basato su liste collegate risulterebbe molto inefficace quando si conservano banche dati "sparse", in cui alcuni dei dati per ogni singolo record potrebbero essere lasciati vuoti. Il modello relazionale ha risolto questo problema suddividendo i dati in una serie di tabelle (o relazioni) normalizzate, con elementi opzionali spostati fuori dalla tabella principale dove avrebbero occupato spazio solo se necessario. I dati possono essere liberamente inseriti, cancellati e modificati in queste tabelle, con il DBMS che fa qualsiasi manutenzione necessaria per presentare una vista della tabella all' applicativo/utente.
None
doc-4159
Il modello relazionale ha anche permesso l' evoluzione del contenuto del database senza riscrivere continuamente link e puntatori. La parte relazionale deriva da entità che fanno riferimento ad altre entità in quella che è nota come relazione one-to-many, come un modello gerarchico tradizionale, e multi-molti, come un modello di navigazione (rete). Così, un modello relazionale può esprimere sia modelli gerarchici che di navigazione, così come il suo modello nativo tabulare, permettendo la modellazione pura o combinata in termini di questi tre modelli, come richiede l' applicazione.
None
doc-4176
Un database costruito con un DBMS non è portatile in un altro DBMS (cioè, l' altro DBMS non può eseguirlo). Tuttavia, in alcune situazioni è auspicabile spostare una banca dati da un DBMS ad un altro. Le ragioni sono principalmente economiche (diversi DBMS possono avere costi totali di proprietà o costi di gestione diversi), funzionali e operativi (diversi DBMS possono avere capacità diverse). La migrazione comporta la trasformazione del database da un tipo di DBMS ad un altro. La trasformazione dovrebbe mantenere (se possibile) intatta l' applicazione relativa al database (cioè tutti i relativi programmi applicativi). Pertanto, i livelli architettonici concettuali ed esterni della banca dati dovrebbero essere mantenuti nella trasformazione. Si può desiderare che vengano mantenuti anche alcuni aspetti del livello interno dell' architettura. La migrazione di una banca dati complessa o di grandi dimensioni può essere di per sé un progetto (una tantum) complicato e costoso, che dovrebbe essere preso in considerazione nella decisione di migrare. Ciò nonostante il fatto che possano esistere strumenti per aiutare la migrazione tra specifici DBMS. Tipicamente un fornitore DBMS fornisce strumenti per aiutare l' importazione di database da altri DBMS popolari.
None
doc-4157
L' IBM aveva anche un proprio DBMS nel 1966, noto come Information Management System (IMS). IMS è stato uno sviluppo di software scritto per il programma Apollo su System/360. L' IMS era generalmente simile in termini concettuali a CODASYL, ma utilizzava una rigorosa gerarchia per il suo modello di navigazione dei dati al posto del modello di rete di CODASYL. Entrambi i concetti divennero in seguito noti come database di navigazione a causa del modo in cui i dati sono stati accessibili, e la presentazione del Premio Turing di Bachman del 1973 fu The Programmer come Navigator. L' IMS è classificato[da chi]? come banca dati gerarchica. Il database IDMS e il database TOTALE di Cincom Systems sono classificati come database di rete. L' IMS rimane in uso dal 2014[aggiornamento].
None
doc-4153
Un DBMS si è evoluto in un sistema software complesso e il suo sviluppo richiede migliaia di anni umani di sforzi di sviluppo. a] Alcuni DBMS generici come Adabas, Oracle e DB2 sono in fase di aggiornamento dagli anni Settanta. I DBMS generici mirano a soddisfare le esigenze del maggior numero possibile di applicazioni, il che aumenta la complessità. Tuttavia, il fatto che i loro costi di sviluppo possano essere ripartiti su un gran numero di utenti fa sì che essi siano spesso l' approccio più efficace sotto il profilo dei costi. Tuttavia, un DBMS generico non è sempre la soluzione ottimale: in alcuni casi un DBMS generico può introdurre inutili costi generali. Pertanto, ci sono molti esempi di sistemi che utilizzano database speciali.
None
doc-4154
Molte altre banche dati dispongono di software applicativo che accede al database per conto degli utenti finali, senza esporre direttamente l' interfaccia DBMS. I programmatori di applicazioni possono utilizzare un protocollo a filo direttamente, o più probabilmente attraverso un' interfaccia di programmazione dell' applicazione. I progettisti di database e gli amministratori di database interagiscono con il DBMS attraverso interfacce dedicate per costruire e mantenere i database delle applicazioni, e quindi hanno bisogno di una maggiore conoscenza e comprensione del funzionamento dei DBMS e delle interfacce esterne e dei parametri di sintonizzazione dei DBMS.
None
doc-4170
La fase finale della progettazione del database è quello di prendere le decisioni che influenzano le prestazioni, scalabilità, recupero, sicurezza, e simili. Questo è spesso chiamato design del database fisico. Un obiettivo chiave in questa fase è l' indipendenza dei dati, il che significa che le decisioni prese a fini di ottimizzazione delle prestazioni devono essere invisibili agli utenti finali e alle applicazioni. La progettazione fisica è guidata principalmente dai requisiti prestazionali, e richiede una buona conoscenza del carico di lavoro previsto e dei modelli di accesso e una profonda comprensione delle caratteristiche offerte dal DBMS scelto.
None
doc-4160
Per esempio, un uso comune di un sistema di database è quello di tenere traccia delle informazioni sugli utenti, il loro nome, le informazioni di login, vari indirizzi e numeri di telefono. Nell' approccio di navigazione tutti questi dati verrebbero inseriti in un unico record e gli elementi inutilizzati non verrebbero semplicemente inseriti nel database. Nell' approccio relazionale, i dati sarebbero normalizzati in una tabella utente, una tabella degli indirizzi e una tabella dei numeri di telefono (ad esempio). I record verrebbero creati in queste tabelle facoltative solo se l' indirizzo o i numeri di telefono fossero effettivamente forniti.
None
doc-4161
Il collegamento tra le informazioni è la chiave di questo sistema. Nel modello relazionale, un po' di informazioni è stato usato come "chiave", definendo in modo univoco un particolare record. Quando si raccolgono informazioni su un utente, le informazioni memorizzate nelle tabelle opzionali vengono trovate cercando questa chiave. Per esempio, se il nome di login di un utente è univoco, gli indirizzi e i numeri di telefono di quell' utente saranno registrati con il nome di login come sua chiave. Questo semplice "riallacciamento" dei dati correlati in un' unica raccolta è qualcosa per cui i linguaggi informatici tradizionali non sono concepiti.
None