Che cos'è un "database"?

Ci sono state molte discussioni in questa domanda: quali tecnologie di database utilizzano i grandi motori di ricerca?

Tante discussioni che mi hanno fatto confondere. Quindi ... cos'è un database, comunque? I database relazionali sono solo "database"? I database orientati agli oggetti sono "database"? C'è un sistema che mi consente di archiviare e recuperare informazioni (come una mappa, un elenco, ecc.) Un database?

Oppure un database deve archiviare / recuperare informazioni e avere anche alcune funzionalità di amministrazione come Utenti e Privilegi? DBase III era più un database, dato che non era veramente relazionale?

Questa è un'ottima domanda e una serie di grandi risposte. Penso che una cosa che manca alla discussione sia una risposta che scava nella distinzione tra un database e un sistema di gestione del database (DBMS). Mi piace la definizione di database che Shark ha fornito da Dictionary.com. Penso che mostri davvero la necessità di distinguere tra database e DBMS. Il database è una "raccolta completa di dati correlati organizzata per un comodo accesso". La seconda parte di quella definizione, che dice "generalmente in un computer" è dove sta la distinzione. Se è memorizzato in un computer, può o meno essere archiviato in un DBMS. Può essere memorizzato in un file system del sistema operativo. Potrebbe essere memorizzato in un file system proprietario. Pertanto, sono d'accordo con FrustratedWithFormsDesigner che un catalogo di carte è un "database" (beh forse - è completo e correlato? Ne parleremo più avanti). Capita solo di essere memorizzato in un archivio. Nel mondo di oggi più "raccolte complete di dati correlati organizzate per un comodo accessosono memorizzati su un computer, quindi non sono d'accordo con Shark sul fatto che è un peccato che Dictionary.com abbia aggiunto quella parte. Penso che sia assolutamente corretto - come definizione di "database".

Quindi, come possiamo definire DBMS? Sono tornato su Dictionary.com e ho trovato questo :

"Una suite di programmi che in genere gestiscono grandi insiemi strutturati di dati persistenti, offrendo funzionalità di query ad hoc a molti utenti. Sono ampiamente utilizzati nelle applicazioni aziendali."

La definizione continua ed è piuttosto lunga. Descrive le funzionalità comuni fornite da un DBMS, come sicurezza, integrità dei dati, gestione delle transazioni, controllo della concorrenza e, soprattutto, indipendenza dei dati. Un DBMS fornisce una vista esterna dei dati estratti da come sono archiviati fisicamente.

Utilizzando questa definizione, penso che sia chiaro che un DBMS deve fornire un modello di dati , che è come i dati sono organizzati per la presentazione all'utente. I tre modelli comuni sono gerarchici (IMS), rete (IDMS) e relazionali (DB2, Oracle, SQL-Server, ecc.). Esiste anche il modello OO (OODBMS). Solo il modello relazionale oggi ha ampia applicabilità. Gli altri modelli sono ancora in uso ma solo in situazioni di nicchia. Il DBMS deve inoltre fornire le altre funzionalità menzionate. Vorrei fare riferimento a queste collettivamente come funzionalità o capacità di gestione dei dati.

Pertanto, i prodotti software che forniscono funzionalità di gestione dei dati sono DBMS, mentre i prodotti che non forniscono questi non sono DBMS '. I prodotti NoSQL non sono DBMS '. Questo non vuol dire che non siano utili e nonper dire che non memorizzano "database". Mi piace pensare che DBMS ', come dice la definizione, risolva una classe di problemi relativi ad applicazioni aziendali come contabilità, buste paga, fatturazione, gestione delle relazioni con i clienti, vendite, ecc. I prodotti NoSQL, sebbene non DBMS', sono eccellenti per risolvere un classe di problemi che non sono correlati alle applicazioni aziendali tradizionali ma ora esistono a causa dell'enorme quantità di tecnologia di archiviazione e larghezza di banda di cui è capace oggi. Queste sono applicazioni come la ricerca su Internet, come l'asta online, come Twitter e Facebook. Il DBMS non è adatto a risolvere questi problemi in quanto il DBMS contiene funzionalità di gestione dei dati che, sebbene una necessità assoluta per un'applicazione aziendale, non sono utili per risolvere l'archiviazione e il recupero di Craig ' s elenca annunci o feed di Twitter (bene di solito comunque - questa è un'altra discussione per un'altra volta :-)). Questi problemi richiedono un massiccio ridimensionamento e una risposta estremamente rapida e il DBMS, con le sue caratteristiche gonfie, non è adatto.

Un professionista dei dati deve comprendere tutti questi strumenti per l'archiviazione dei dati e quale classe di problemi sono adatti a risolvere al fine di scegliere lo strumento giusto per il lavoro, proprio come un appaltatore generale deve sapere quale dei suoi strumenti di costruzione è lo strumento giusto per il lavoro. Nessuno strumento è buono o cattivo in sé e per sé. È utile se è adatto per risolvere un problema importante.

Concluderò rilevando altre due distinzioni chiave nella definizione di database e DBMS che potrebbero essere finora trascurate nella discussione. La definizione di database include " raccolta completa di dati correlati ". La definizione di DBMS include "gestire grandi strutturesarebbe meglio usare MS Access o altri DBMS relazionali. Quindi forse un catalogo di schede non è un database dopo tutto come completo (ha una registrazione di tutti i libri nella biblioteca) non è correlato in quanto contiene solo informazioni sui libri, non complete informazioni correlate su autori, editori, eccetera.

In secondo luogo, un DBMS eccelle nella memorizzazione di dati "strutturati". È interamente basato su uno schema definito di elementi di dati discreti con tipi strutturati. Un prodotto NoSQL, ad esempio un archivio di valori chiave privo di uno schema, eccelle nella memorizzazione di dati non strutturati. Tale prodotto NoSQL pertanto non soddisfa la definizione di DBMS. Ma se il problema che stai cercando di risolvere è l'archiviazione di dati non strutturati (cosa che non abbiamo nemmeno tentato di fare quando i DBMS sono stati sviluppati per la prima volta), e non hai bisogno di funzionalità di gestione dei dati indipendenti dall'applicazione su cui scriverai elabora i dati non strutturati, il prodotto NoSQL si adatta perfettamente allo strumento.

Spero che questa risposta aggiunga valore alle altre grandi risposte pubblicate qui. Attendo con ansia eventuali commenti e punti di discussione che chiunque altro possa avere che ci aiuterà tutti ad ampliare la nostra comprensione dei database e delle classi di tecnologia che risolvono i problemi relativi ai dati.

Citerò Dictionary.com , poiché prendo questo come significato del database:

una raccolta completa di dati correlati organizzata per un comodo accesso, generalmente in un computer.

In base a questa definizione, è possibile considerare qualsiasi database da un RDBMS completo (SQL Server, Oracle, ecc.) A un file flat di base. Se memorizza i dati, tecnicamente può essere considerato un database.

Ora, come la maggior parte delle cose nel nostro mondo moderno, c'è il significato accettato di un nome. E nel caso del database , questo varierà da persona a persona. Molte persone pensano a un database esclusivamente come un'entità gestita da un sistema di dati.

Vale la pena notare il commento di @ FrustratedWithFormsDesigner:

i cataloghi di carte contano anche se si rimuove il "... generalmente in un computer".

Sono d'accordo con questa affermazione e non penso necessariamente che un database debba vivere in un "computer" o in qualsiasi dispositivo elettronico. Un catalogo di schede è un perfetto esempio di database non computerizzato.

Per me, un database è una cosa esistente per archiviare e recuperare i dati. Chiamiamo Access un database, anche se in realtà è solo un bel front-end per una raccolta di file. Outlook (almeno su Mac) chiama il suo archivio di messaggi un database. Alcune persone chiamano addirittura Excel un database (ma questo tipo di mi fa sbuffare - quindi c'è una linea da qualche parte).

Penso che la definizione si sia evoluta nel tempo, e confrontando il dizionario.com, il wiki, con i documenti di vari professionisti del database nel corso degli ultimi 30 anni, produrrà una varietà di definizioni. E anche la definizione continuerà ad evolversi.

Se stai parlando di un tipo di origine dati che tu o le tue applicazioni utilizzate per archiviare o recuperare i dati, siano essi relazionali o meno, non ho problemi a chiamarlo database. Se si tratta di un file di testo, potresti avere delle sopracciglia alzate, ma non sono sicuro di capire la necessità di individuare la definizione in modo così limitato che la gente si arrabbia.

Alcune persone diventano piuttosto arroganti, a quanto pare, se si arriva anche marginalmente a suggerire che BigTable (o NoSQL o hadoop) sia un "database", e sostengono che chiamarlo come tale darà - in particolare ai neofiti - una grande promessa di prestazioni infinite, immortalità e unicorni. Considerando che di solito intendi solo che è un luogo in cui i dati vengono archiviati e recuperati, senza alcuna garanzia su ciò che fa l'implementazione effettiva, sia essa relazionale o meno, o se potresti produrre una cosa del genere quando ti annoi la domenica pomeriggio.

Devo ammettere che mi arrabbio quando le persone parlano di un database relazionale e chiamano le righe "record" o colonne "campi". Ma mentre mi irrita un po ', non mi arrabbio o faccio di tutto per correggerli - qual è il punto? Ho capito cosa significano, anche se non sono accurati al 100%.

Può essere molto generale, solo una raccolta di dati e strutture. Il sistema per la gestione di un database può essere semplice come un file system o complesso come un sistema federato come il DNS.

Generalmente nell'uso moderno, quando si dice database, si implicano sia l'archiviazione dei dati che le strutture e un sistema di gestione del database di accompagnamento, e poiché è stato svolto così tanto lavoro teorico sulle basi dei database relazionali, questi sono ancora i più popolari che spesso quando si dice un database, si implica spesso un database relazionale.

Con l'ascesa di NoSQL / database non relazionali, il termine database è tornato ad essere più generale e potenzialmente più ambiguo, dal momento che un modello condiviso per la comprensione dei dati non può essere assunto.

Prima della fondazione della teoria relazionale, la modellizzazione dei dati in altri sistemi variava da sistema a sistema e non aveva principi guida condivisi come il modello relazionale - sono stati utilizzati altri tipi di database come database gerarchici e database di rete.

Ho lavorato per Ashton-Tate durante lo sviluppo di dBASE Direct / 36 e dBASE IV, usando la mia conoscenza di dBASE III Plus per codificare un piccolo programma per facilitare il test di dBASE Direct / 36 (interfaccia con un IBM System / 36 Mini Computer). Abbiamo dovuto effettuare il caricamento binario e chiamare le istruzioni per le tabelle SQL System / 36, che richiedevano la ripetizione della digitazione delle stesse istruzioni "load" e "call" durante la modifica dei nomi delle tabelle e dei nomi dei campi al momento dell'invio per ottenere i dati da ciascun record o gruppo di più record a seconda dell'ambito della query. dBASE III Plus, un linguaggio di programmazione del database, mi ha permesso di creare "dbldot.prg" che ha cambiato il prompt a punto singolo in doppio punto mentre progettavo di essere un indicatore del fatto che il sistema era in modalità di recupero SQL, così come il testo sotto la riga di comando che diceva "

All'epoca dBASE era un linguaggio di programmazione del database, o più precisamente, un linguaggio di programma che consentiva la manipolazione dei record di dati. Un record era un gruppo di campi che contenevano dati per un singolo elemento, come persone LAST_NAME, FIRST_NAME, ADDRESS, CITY, ST, ZIP, PLUS_FOUR, SSN, ecc. Queste strutture sono state successivamente rappresentate in tabelle e organizzate in righe e colonne, una riga è un singolo record e una colonna rappresenta i dati di una serie di record per ciascun nome di campo. In questo modo, un utente potrebbe facilmente ordinare in base al nome del campo per ordinare e raggruppare i record in base a campi comuni specifici, come CITY, ST, ZIP, ecc.

Il linguaggio dBASE ha consentito all'utente o al programmatore di manipolare i dati, eseguire ordinamenti, visualizzare tabelle, record ed eseguire calcoli (Y2K era molto lontano ma le date dovevano essere convertite in AAAAMMGG per ordinare i dati MM-GG-AAAA immessi, che potrebbe essere fatto con DtoC e CtoD (Date to Character, Character to Date)). Senza il linguaggio dBASE, i file di dati sarebbero semplicemente una serie di record (righe) con campi comuni (colonne).

Database relazionale: era il termine utilizzato per fare riferimento incrociato a più di un database (tabella) con un altro che conteneva informazioni diverse ma conteneva uno o più campi comuni. Ad esempio, un database intitolato "Indirizzi" contiene "LNAME", "FNAME", "ADDRESS", "CITY", "ST", "ZIP", "SSN". Un altro database intitolato "CHECKING" contiene "ACCOUNT_NO", "ROUTING_NO", "CUSTLAST", "CUSTFIRST", "DOB", "SSNO", "CUST_NO". Sebbene i nomi dei campi siano diversi, molti di essi contengono le stesse informazioni che possono essere collegate tra loro per legare i dati di un database a quelli dell'altro, per esempio, per inviare dichiarazioni ai clienti della banca, utilizzando i campi nome e cognome e numeri SS per mettere in relazione i dati, estraendo l'indirizzo del cliente da un database e le informazioni sull'account da inserire nell'estratto conto dall'altro. Quindi, su una scala più ampia, può avere luogo una funzione di stampa unione per eseguire queste azioni su ogni singolo cliente nel database ADDRESS, estraendo le informazioni relative all'account di ciascun cliente, personalizzando la dichiarazione, stampando e indirizzando ciascuno prima di passare al successivo record o cliente nel database.

Quindi, qualcosa come MS ACCESS potrebbe essere più di un DBMS, ma a livello base dBASE era un linguaggio per creare interfacce utente front-end e condurre tutta la manipolazione dei dati tra database per creare una relazione tra loro e restituire i dati risultanti per siamo semplici umani da usare.

Da allora sono cambiate molte cose, ma le fondamenta rimangono le stesse. I dati sono ancora contenuti in record contenenti una serie di campi di vari tipi di dati e devono essere referenziati e uniti a quelli di altri database tramite uno o più punti dati comuni, permettendoci di utilizzare carte di credito, impostare account sul Web utilizzando i nostri ID di Google, Facebook, Twitter, tenere traccia della cronologia degli acquisti e così via. Le nostre vite sono solo una serie di molti database relazionali sovrapposti, che attraversiamo ogni giorno senza pensare a tutti i bit e byte che interagiscono per portarci i piaceri e la continua evoluzione della facilità nella nostra vita di oggi.

In affitto è così che l'ho sempre capito in tanti anni di test di software e hardware che sono iniziati con dBASE II nel 1984.

Il documento fondamentale di Codd era intitolato Un modello relazionale di dati per grandi banche dati condivise . Ciò che chiamava "banca dati" chiameremmo un database.

Mi piacciono le sue immagini, comunque. Implica un luogo in cui i dati possono essere inseriti, sapendo che saranno tenuti al sicuro, debitamente contabilizzati e restituiti solo a coloro che possono dimostrare di avere l'autorità per accedervi. Se la nostra filiale viene derubata, abbiamo la certezza che la società bancaria ha un backup adeguato per garantire che le nostre preziose risorse non vengano perse irrevocabilmente.

Dai fondamenti di Database Design 7th Ed. (pag. 5),

Un database è una raccolta di dati correlati.

Continuano a dire che l'uso comune è più limitato,

Un database ha le seguenti proprietà implicite:

• Un database rappresenta alcuni aspetti del mondo reale, a volte chiamato mini-mondo o universo del discorso (UdD). Le modifiche al mini-mondo si riflettono nel database.
• Un database è una raccolta di dati logicamente coerente con un significato intrinseco. Un assortimento casuale di dati non può essere correttamente definito come un database.
• Un database è progettato, costruito e popolato con dati per uno scopo specifico. Ha un gruppo di utenti previsto e alcune applicazioni preconcette a cui questi utenti sono interessati.

In nessuna definizione un database è esplicitamente "relazionale" in alcun senso, tuttavia spesso si presume che il settore sia saturo di DBA di un tipo specifico e probabilmente il software DBMS più avanzato è tutto relazionale. Dal dizionario del database relazionale

In senso stretto, un valore di database, qv; più comunemente usato, in questo dizionario in particolare, per riferirsi a quella che sarebbe più precisamente definita una variabile di database, qv Assumiamo in questo dizionario che i database siano sempre relazionali, escludendo affermazioni esplicite al contrario. Nota: il termine database viene utilizzato anche in contesti non relazionali per indicare una varietà di altre cose: ad esempio una raccolta di dati archiviati fisicamente. Viene anche usato, troppo spesso, per indicare un DBMS, ma questo particolare utilizzo è fortemente deprecato. (Se chiamiamo DBMS un database, come chiamiamo il database?)

Quest'ultimo punto è in qualche modo importante e mi piace anche la distinzione tra DBMS / RDBMS e il database stesso.