Modelli di architettura di database: modelli gerarchici, di rete e relazionali

Alcuni dei modelli di architettura di database sono i seguenti:

Il processo di definizione della progettazione concettuale degli elementi di dati e delle loro interrelazioni è chiamato modellazione dei dati. L'approccio tradizionale delle applicazioni all'organizzazione dei dati ha creato modelli diversi per ciascun file di dati.

Cortesia dell'immagine: ysma.gr/static/images/6_4_DBinput.jpg

Questa varietà di modi in cui diversi elementi di dati sono collegati e memorizzati in file di dati rendono questi file adatti solo per le applicazioni per cui sono stati originariamente creati. In effetti, i dettagli riguardanti il ​​posizionamento esatto di diversi elementi di dati in un file devono essere documentati con molta attenzione.

Qualsiasi modifica nell'ordine in cui sono posizionati i vari elementi di dati comporta modifiche nei programmi applicativi utilizzando il file di dati. L'approccio al database utilizza un modello di dati comune per l'intero database e il programma utente non riguarda il posizionamento di un particolare elemento di dati. Il sistema di gestione del database (DBMS) funge da interfaccia tra il database e i programmi utente.

Il DBMS recupera i dati dal database e li rende disponibili per il programma utente. Questa funzionalità offre il vantaggio dell'indipendenza dei dati nell'approccio al database.

Concettualmente, ci sono tre ampie opzioni per quanto riguarda i modelli di database. Questi sono:

un. Modello gerarchico

b. Modello di rete

c. Modello relazionale

(a) Modello gerarchico:

Questo modello presenta i dati agli utenti in una gerarchia di elementi di dati che possono essere rappresentati in una sorta di albero invertito. In un sistema di elaborazione degli ordini di vendita, un cliente può ricevere numerose fatture e ogni fattura può avere diversi elementi di dati. Pertanto, il livello principale dei dati è il cliente, il secondo livello è la fattura e l'ultimo livello è costituito da elementi pubblicitari come numero di fattura, data, prodotto, quantità, ecc.

Questa struttura è abbastanza naturale se vista dal punto di vista dell'evento. Tuttavia, i livelli inferiori sono di proprietà di elementi di livello superiore e gli elementi allo stesso livello non hanno alcun collegamento. Di conseguenza, la query come ad esempio quali prodotti sono acquistati da quale cliente, nell'esempio sopra, sarà difficile da eseguire nella struttura gerarchica.

La domanda su quale cliente ha acquistato quale prodotto sarebbe conveniente. Quindi, dove ci sono relazioni molti-a-molti tra due entità, questo modello non sarebbe appropriato. La Figura 9.4 mostra il modello gerarchico di dati per un'applicazione di elaborazione degli ordini di vendita.

(b) Modello di rete:

Nel modello di rete del database, non ci sono livelli e un record può avere un numero qualsiasi di proprietari e può anche avere la proprietà di più record. Pertanto, il problema sopra riportato nell'elaborazione dell'ordine di vendita non si presenterà nel modello di rete.

Poiché non esiste un percorso definito definito per il recupero dei dati, il numero di collegamenti è molto grande e quindi i database di rete sono complessi, lenti e difficili da implementare. In vista della difficoltà di implementazione, il modello di rete viene utilizzato solo quando tutte le altre opzioni sono chiuse.

L'esempio tipico di un database di rete può essere il dipendente e il reparto con cui ha lavorato o in cui può lavorare in futuro. La Figura 9.5 mostra il modello di rete dei dati per un sistema informativo dei dipendenti.

(c) Modello relazionale:

Il modello più recente e popolare di progettazione di database è il modello di database relazionale. Questo modello è stato sviluppato per superare i problemi di complessità e inflessibilità dei primi due modelli nella gestione di database con relazioni molti-a-molti tra entità.

Questi modelli non sono solo semplici ma anche potenti. Nel database relazionale, ogni file viene percepito come un file flat (una tabella bidimensionale) costituito da molte righe (record), ciascun record con elementi dati chiave e non chiave. L'elemento chiave (s) è l'elemento (i) di dati che identifica il record. La Figura 9.6 mostra i file e i campi che ogni record deve avere in un sistema di fatturazione del cliente.

In questi file, gli elementi dei dati chiave sono ID cliente, numero fattura e codice prodotto. Ciascuno dei file può essere utilizzato separatamente per generare report. Tuttavia, i dati possono anche essere ottenuti da qualsiasi combinazione di file poiché tutti questi file sono correlati tra loro con l'aiuto di elementi chiave specificati sopra.

Questo è il vantaggio fondamentale del modello relazionale del database insieme alla sua semplicità e alla sua robustezza.

Il modello relazionale attinge molto al lavoro di EF Codd che identifica le caratteristiche di un buon database relazionale come segue:

a) Tutte le informazioni sono rappresentate logicamente come tabelle e l'accesso ai dati è possibile tramite i nomi dei campi. Pertanto, l'ordine, la posizione o il collegamento di file non è motivo di preoccupazione per gli utenti.

b) Il dizionario dei dati contiene informazioni sulla struttura del database, incluso il tipo di dati; dimensioni, ecc., definizioni, relazioni e permessi di accesso. Gli utenti autorizzati possono conoscere l'ambiente del database e modificare l'ambiente utilizzando il linguaggio di descrizione dei dati (DDL).

c) Un linguaggio di manipolazione dei dati (DML) è disponibile per gli utenti, inclusi i programmatori per la creazione, l'inserimento, la modifica, il recupero, l'organizzazione e l'eliminazione di qualsiasi parte del database. Queste manipolazioni sono possibili a livello di record e per l'intero file, dando la flessibilità nella definizione delle autorizzazioni di accesso per varie categorie di utenti.

d) Qualsiasi modifica nella struttura del database in termini di suddivisione orizzontale o verticale della tabella non dovrebbe avere alcun impatto sulla logica del programma che utilizza il database. Questa indipendenza dei dati è il vantaggio principale del modello relazionale del database.

e) L'indipendenza distribuita dei dati è un'altra caratteristica di un buon database relazionale. I programmi utente non richiedono alcuna modifica quando i dati vengono prima distribuiti o ridistribuiti. L'effettiva ubicazione fisica dei dati non è rilevante per l'utente a condizione che tale campo appaia nel dizionario dei dati come locale.

Come si può notare dalla Fig. 9.6, nessuno dei campi è comune in due file tranne l'elemento chiave. Quindi, la ridondanza dei dati può essere evitata in questo modello. A tale scopo, viene intrapreso un processo di normalizzazione dei dati durante la progettazione della struttura di un database.