MODELLO DI DATABASE RELAZIONALE: ELEMENTI, COME FARLO, ESEMPIO - TECNOLOGIA - 2024

Il modello di database relazionale è 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.

Fonte: pixabay.com

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.

Gestione del database

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 desiderano da esso.

D'altra parte, lasciano che sia il software del sistema di gestione del database a 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.

Caratteristiche ed elementi

- 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. Cioè, in qualsiasi posizione di riga / colonna data nella tabella, c'è solo un singolo valore.

-Elementi

La figura seguente mostra una tabella con i nomi dei suoi elementi di base, che compongono una struttura completa.

tuple

Ogni riga di dati è una tupla, nota anche come record. Ogni riga è una n-tupla, ma la "n-" viene generalmente scartata.

Colonna

Ogni colonna in una tupla è chiamata attributo o campo. La colonna rappresenta l'insieme di valori che può avere un attributo specifico.

Chiave

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 qualche altra tabella. Viene utilizzato per fare riferimento alla tabella primaria.

-Regole di integrità

Quando si progetta il modello relazionale, si definiscono alcune condizioni che devono essere soddisfatte nel database, chiamate regole di integrità.

Integrità chiave

La chiave primaria deve essere univoca per tutte le tuple e non può essere nulla (NULL). 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.

Integrità referenziale

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 primaria, a causa dell'aggiornamento o dell'eliminazione della riga, tutte le righe nelle tabelle secondarie con questa chiave esterna devono essere aggiornate o eliminate di conseguenza.

Come realizzare un modello relazionale?

-Raccogliere dati

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.

-Definire le chiavi primarie

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.

-Crea relazioni tra le tabelle

Un database costituito da tabelle indipendenti e non correlate serve a poco.

L'aspetto più cruciale nella progettazione di un database relazionale è identificare le relazioni tra le tabelle. I tipi di relazione sono:

Uno a molti

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 a molte classi, i suoi dati sarebbero duplicati su molte righe nella tabella Classi.

Progetta due tavoli

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 informazioni sugli insegnanti, con Teacher_Id come chiave primaria.

La relazione uno-a-molti può quindi essere creata memorizzando la chiave primaria dalla 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 Classes, c'è solo una riga nella tabella Insegnanti.

Molti a molti

In un database "Vendita di prodotti", un ordine 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 puoi memorizzare i prodotti ordinati all'interno della tabella Ordini, poiché non sai 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 è costituita 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.

Uno per uno

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.

Vantaggio

Indipendenza strutturale

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.

Semplicità concettuale

Il modello di database relazionale è ancora più concettualmente semplice 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 visualizzazione logica del database.

Facilità di progettazione, implementazione, manutenzione e utilizzo

Il modello di database relazionale raggiunge sia l'indipendenza dai dati che l'indipendenza dalla struttura, il che rende la progettazione, la manutenzione, la gestione e l'utilizzo del database molto più semplici rispetto agli altri modelli.

Capacità di query ad hoc

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, chiamato linguaggio di query strutturato 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.

svantaggi

Spese hardware

Il modello di database relazionale nasconde le complessità della sua implementazione ei dettagli dell'archiviazione fisica dei dati dell'utente.

Per fare ciò, i sistemi di database relazionali necessitano di computer con hardware più potente 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.

La facilità di progettazione può portare a una progettazione scadente

Il database relazionale è facile da progettare e utilizzare. Gli utenti non hanno bisogno di conoscere i dettagli complessi della memorizzazione 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 è presente 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.

Fenomeno delle «isole dell'informazione»

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 singoli database creeranno anche problemi come incoerenza dei dati, duplicazione dei dati, ridondanza dei dati, ecc.

Esempio

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), che identifica 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 di 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, è possibile ottenere informazioni 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. Non ci sono spedizioni di viti rosse.

Riferimenti

1. Wikipedia, l'enciclopedia libera (2019). Modello relazionale. Tratto da: en.wikipedia.org.
2. Techopedia (2019). Modello relazionale. Tratto da: ceilingpedia.com.
3. Dinesh Thakur (2019). Modello relazionale. Note sull'ecomputer. Tratto da: ecomputernotes.com.
4. Geeks for Geeks (2019). Modello relazionale. Tratto da: geeksforgeeks.org.
5. Nanyang Technological University (2019). Un tutorial di avvio rapido sulla progettazione di database relazionali. Tratto da: ntu.edu.sg.
6. Adrienne Watt (2019). Capitolo 7 Il modello di dati relazionale. BC Open Textbooks. Tratto da: opentextbc.ca.
7. Toppr (2019). Database e schemi relazionali. Tratto da: toppr.com.