Il modello relazionale di database è un metodo per strutturare i dati utilizzando le relazioni, utilizzando strutture a griglia, costituite da colonne e righe. È il principio concettuale dei database relazionali. È stato proposto da Edgar F. Codd nel 1969.
Da allora è diventato il modello di database dominante per le applicazioni aziendali, rispetto ad altri modelli di database, come gerarchico, di rete e a oggetti..
Codd non aveva idea di quanto sarebbe stato estremamente vitale e influente il suo lavoro come piattaforma per database relazionali. La maggior parte delle persone ha molta familiarità con l'espressione fisica di una relazione in un database: la tabella.
Il modello relazionale è definito come il database che permette di raggruppare i suoi elementi di dati in una o più tabelle indipendenti, che possono essere correlate tra loro tramite l'utilizzo di campi comuni a ciascuna tabella correlata..
Indice articolo
Una tabella di database è simile a un foglio di calcolo. Tuttavia, le relazioni che possono essere create tra le tabelle consentono a un database relazionale di archiviare in modo efficiente una grande quantità di dati, che possono essere recuperati in modo efficace..
Lo scopo del modello relazionale è fornire un metodo dichiarativo per specificare dati e query: gli utenti dichiarano direttamente quali informazioni contiene il database e quali informazioni vogliono da esso.
D'altra parte, lasciano che il software del sistema di gestione del database sia incaricato di descrivere le strutture dei dati per l'archiviazione e la procedura di recupero per rispondere alle domande..
La maggior parte dei database relazionali utilizza il linguaggio SQL per l'interrogazione e la definizione dei dati. Attualmente esistono molti sistemi di gestione di database relazionali o RDBMS (Relational Data Base Management System), come Oracle, IBM DB2 e Microsoft SQL Server.
- Tutti i dati sono concettualmente rappresentati come una disposizione ordinata di dati in righe e colonne, chiamata relazione o tabella.
- Ogni tabella deve avere un'intestazione e un corpo. L'intestazione è semplicemente l'elenco delle colonne. Il corpo è l'insieme di dati che riempie la tabella, organizzato in righe.
- Tutti i valori sono scalari. Vale a dire, in una determinata posizione di riga / colonna nella tabella, c'è solo un singolo valore.
La figura seguente mostra una tabella con i nomi dei suoi elementi di base, che compongono una struttura completa.
Ogni riga di dati è una tupla, nota anche come record. Ogni riga è una n-tupla, ma la "n-" viene generalmente scartata.
Ogni colonna in una tupla è chiamata attributo o campo. La colonna rappresenta l'insieme di valori che può avere un attributo specifico.
Ogni riga ha una o più colonne chiamate chiave di tabella. Questo valore combinato è univoco per tutte le righe di una tabella. Per mezzo di questa chiave, ogni tupla sarà identificata in modo univoco. Cioè, la chiave non può essere duplicata. Si chiama chiave primaria.
D'altra parte, una chiave esterna o secondaria è il campo in una tabella che fa riferimento alla chiave primaria di un'altra tabella. Utilizzato per fare riferimento alla tabella primaria.
Quando si progetta il modello relazionale, si definiscono alcune condizioni che devono essere soddisfatte nel database, chiamate regole di integrità.
La chiave primaria deve essere univoca per tutte le tuple e non può essere nulla. In caso contrario, non sarai in grado di identificare in modo univoco la riga.
Per una chiave a più colonne, nessuna di queste colonne può contenere NULL.
Ogni valore di una chiave esterna deve corrispondere a un valore della chiave primaria della tabella di riferimento o primaria.
Una riga con una chiave esterna può essere inserita nella tabella secondaria solo se tale valore esiste in una tabella primaria.
Se il valore della chiave cambia nella tabella genitore, aggiornando o eliminando la riga, allora tutte le righe nelle tabelle figlie con questa chiave esterna dovrebbero essere aggiornate o eliminate di conseguenza.
I dati necessari devono essere raccolti per essere archiviati nel database. Questi dati sono suddivisi in diverse tabelle.
È necessario scegliere un tipo di dati appropriato per ciascuna colonna. Ad esempio: numeri interi, numeri in virgola mobile, testo, data, ecc..
Per ogni tabella, è necessario scegliere una colonna (o poche colonne) come chiave primaria, che identificherà in modo univoco ogni riga della tabella. La chiave primaria viene utilizzata anche per fare riferimento ad altre tabelle.
Un database costituito da tabelle indipendenti e non correlate ha poco scopo.
L'aspetto più cruciale nella progettazione di un database relazionale è identificare le relazioni tra le tabelle. I tipi di relazione sono:
In un database "Class Listing", un insegnante può insegnare a zero o più classi, mentre una classe è tenuta da un singolo insegnante. Questo tipo di relazione è noto come uno-a-molti..
Questa relazione non può essere rappresentata in una singola tabella. Nel database "Elenco delle classi" puoi avere una tabella chiamata Insegnanti, che memorizza le informazioni sugli insegnanti.
Per memorizzare le lezioni insegnate da ogni insegnante, potresti creare colonne aggiuntive, ma dovresti affrontare un problema: quante colonne creare.
D'altra parte, se hai una tabella chiamata Classi, che memorizza le informazioni su una classe, potresti creare colonne aggiuntive per memorizzare le informazioni sull'insegnante..
Tuttavia, poiché un insegnante può insegnare in molte classi, i suoi dati sarebbero duplicati in molte righe della tabella Classi.
Pertanto, è necessario progettare due tabelle: una tabella Classes per memorizzare le informazioni sulle classi, con Class_Id come chiave primaria e una tabella Teachers per memorizzare le informazioni sugli insegnanti, con Teacher_Id come chiave primaria..
Quindi la relazione uno-a-molti può essere creata memorizzando la chiave primaria della tabella Master (Master_Id) nella tabella Classi, come illustrato di seguito.
La colonna Master_Id nella tabella Classes è nota come chiave esterna o chiave secondaria.
Per ogni valore Master_Id nella tabella Master, possono esserci zero o più righe nella tabella Classes. Per ogni valore Class_Id nella tabella Classi, c'è solo una riga nella tabella Insegnanti.
In un database "Vendita di prodotti", l'ordine di un cliente può contenere più prodotti e un prodotto può essere visualizzato in più ordini. Questo tipo di relazione è noto come molti a molti.
È possibile avviare il database "Vendite di prodotti" con due tabelle: Prodotti e Ordini. La tabella Products contiene informazioni sui prodotti, con productID come chiave primaria.
D'altra parte, la tabella Orders contiene gli ordini del cliente, con orderID come chiave primaria.
Non è possibile memorizzare i prodotti ordinati all'interno della tabella Ordini, poiché non si sa quante colonne riservare per i prodotti. Né gli ordini possono essere memorizzati nella tabella Prodotti per lo stesso motivo.
Per supportare una relazione molti-a-molti, è necessario creare una terza tabella, nota come tabella di join (OrderDetails), in cui ogni riga rappresenta un elemento in un ordine particolare.
Per la tabella OrderDetails, la chiave primaria è composta da due colonne: orderID e productID, che identificano in modo univoco ogni riga.
Le colonne orderID e productID nella tabella OrderDetails vengono utilizzate per fare riferimento alle tabelle Orders e Products. Pertanto, sono anche chiavi esterne nella tabella OrderDetails..
Nel database "Vendita di prodotti", un prodotto può avere informazioni opzionali, come una descrizione aggiuntiva e la sua immagine. Mantenerlo all'interno della tabella Prodotti genererebbe molti spazi vuoti.
Pertanto, è possibile creare un'altra tabella (ProductExtras) per memorizzare i dati facoltativi. Verrà creato un solo record per i prodotti con dati opzionali.
Le due tabelle, Products e ProductExtras, hanno una relazione uno a uno. Per ogni riga nella tabella Products c'è un massimo di una riga nella tabella ProductExtras. Lo stesso ID prodotto deve essere utilizzato come chiave primaria per entrambe le tabelle.
Nel modello di database relazionale, le modifiche alla struttura del database non influiscono sull'accesso ai dati.
Quando è possibile apportare modifiche alla struttura del database senza influire sulla capacità del DBMS di accedere ai dati, si può affermare che è stata raggiunta l'indipendenza strutturale.
Il modello di database relazionale è ancora più semplice concettualmente del modello di database gerarchico o di rete.
Poiché il modello di database relazionale libera il progettista dai dettagli dell'archiviazione fisica dei dati, i progettisti possono concentrarsi sulla vista logica del database.
Il modello di database relazionale raggiunge sia l'indipendenza dai dati che l'indipendenza dalla struttura, il che rende la progettazione, la manutenzione, l'amministrazione e l'uso del database molto più semplici rispetto agli altri modelli..
La presenza di una capacità di query molto potente, flessibile e di facile utilizzo è uno dei motivi principali dell'immensa popolarità del modello di database relazionale.
Il linguaggio di query del modello di database relazionale, denominato Structured Query Language o SQL, rende le query ad-hoc una realtà. SQL è un linguaggio di quarta generazione (4GL).
Un 4GL consente all'utente di specificare cosa dovrebbe essere fatto, senza specificare come dovrebbe essere fatto. Pertanto, con SQL, gli utenti possono specificare quali informazioni desiderano e lasciare i dettagli su come ottenere le informazioni nel database.
Il modello di database relazionale nasconde le complessità della sua implementazione ei dettagli della memorizzazione fisica dei dati degli utenti.
Per fare ciò, i sistemi di database relazionali necessitano di computer con hardware più potenti e dispositivi di archiviazione dati..
Pertanto, l'RDBMS necessita di macchine potenti per funzionare senza problemi. Tuttavia, poiché la potenza di elaborazione dei computer moderni sta aumentando a un ritmo esponenziale, la necessità di una maggiore potenza di elaborazione nello scenario odierno non è più un grosso problema..
Il database relazionale è facile da progettare e utilizzare. Gli utenti non hanno bisogno di conoscere i dettagli complessi dell'archiviazione fisica dei dati. Non hanno bisogno di sapere come vengono effettivamente archiviati i dati per accedervi.
Questa facilità di progettazione e utilizzo può portare allo sviluppo e all'implementazione di sistemi di gestione di database mal progettati. Poiché il database è efficiente, queste inefficienze di progettazione non verranno alla luce quando il database viene progettato e quando c'è solo una piccola quantità di dati.
Man mano che il database cresce, database mal progettati rallenteranno il sistema e porteranno a un degrado delle prestazioni e al danneggiamento dei dati..
Come accennato in precedenza, i sistemi di database relazionali sono facili da implementare e utilizzare. Ciò creerà una situazione in cui troppe persone o reparti creeranno i propri database e applicazioni..
Queste isole di informazioni impediranno l'integrazione delle informazioni, che è essenziale per il funzionamento regolare ed efficiente dell'organizzazione..
Questi database individuali creeranno anche problemi come incoerenza dei dati, duplicazione dei dati, ridondanza dei dati, ecc..
Supponiamo che un database sia costituito dalle tabelle Fornitori, Parti e Spedizioni. La struttura delle tabelle e alcuni record di esempio sono i seguenti:
Ogni riga nella tabella Fornitori è identificata da un numero di fornitore univoco (SNo), identificando in modo univoco ogni riga nella tabella. Allo stesso modo, ogni parte ha un numero di parte univoco (PNo).
Inoltre, non può esserci più di una spedizione per una data combinazione Fornitore / Parte nella tabella Spedizioni, poiché questa combinazione è la chiave primaria delle Spedizioni, che funge da tabella di unione, poiché è una relazione molti a molti..
La relazione tra le tabelle Parti e Spedizioni è data dall'avere in comune il campo PNo (numero parte) e la relazione tra Fornitori e Spedizioni nasce dall'avere in comune il campo SNo (numero fornitore).
Analizzando la tabella Spedizioni si può ottenere come informazione che un totale di 500 noci vengono inviate dai fornitori di Suneet e Ankit, 250 ciascuno.
Allo stesso modo, 1.100 bulloni in totale sono stati spediti da tre diversi fornitori. 500 viti blu sono state spedite dal fornitore Suneet. Nessuna spedizione di viti rosse.
Nessun utente ha ancora commentato questo articolo.