Cos’è uno schema relazionale? Come si crea un database efficiente?
Non esiste una singola struttura di database che sia sempre più efficiente di qualsiasi altra. Questo perché il tipo e la quantità di dati immagazzinati cambiano la struttura ottimale del database.
Tuttavia, c’è una grande differenza tra costruire un database ottimizzato per le prestazioni e uno che è ottimizzato per il volume dei dati.
Utilizzando uno schema relazionale in MySQL, è possibile creare un database che è ottimizzato per il volume dei dati. Questo è l’ideale in situazioni in cui il costo di archiviazione, elaborazione e memoria è proibitivo.
Mentre questo non è più il caso dell’elettronica standard, ci sono ancora molte situazioni in cui i programmatori e gli sviluppatori vorrebbero usare lo schema relazionale. Anche se lo stoccaggio, la potenza di elaborazione e la memoria sono poco costosi per gli utenti dei computer convenzionali, queste cose sono massicciamente costose nel mondo dell’informatica quantistica.
Inoltre, uno schema relazionale è importante nei database MySQL che si basano sulle relazioni per generare significato. I record dei dipendenti e accademici, per esempio, possono essere facilmente pensati come reti di relazioni meglio descritte usando uno schema relazionale che, per esempio, i database a valore chiave o a grafo.
Lo schema relazionale è l’elemento primario del database relazionale. Questi database sono gestiti usando un linguaggio e una struttura che è coerente con la logica del primo ordine. Questo permette una gestione del database basata sulle relazioni tra entità, rendendole facili da organizzare in base al volume.
Lo schema relazionale si riferisce ai meta-dati che descrivono la struttura dei dati all’interno di un certo dominio. È lo schema di un database che delinea il modo in cui la sua struttura organizza i dati in tabelle.
Per esempio, se il vostro database contiene record di dipendenti per una grande impresa, allora potreste avere relazioni di entità che descrivono ogni dipendente come un’entità forte come questa:
- Nome del dipendente
- Numero ID
- Indirizzo
- Competenza del dipendente
- Data di assunzione
- Anni di servizio
In questo esempio, avresti due attributi di dati dello schema relazionale. In primo luogo, avreste l’attributo Employee, che è la chiave primaria della tabella (poiché tutto è legato all’impiegato) e un attributo Address, che è un attributo composito formato da diversi elementi.
L’attributo Address consisterebbe dei seguenti valori:
- City
- Street
- Address number
- Zip code
Sapendo questo, siete pronti per mappare un diagramma di relazione tra entità allo schema relazionale. Dovrebbe assomigliare a questo:
- Dipendente (Nome, Numero ID, Numero indirizzo, Via, Città, Codice postale, Data di assunzione)
- Skillset del dipendente (Numero ID, Skillset)
Si dovrebbe notare che gli anni di servizio sono esclusi da questa lista. Questo perché è un attributo derivato che può essere calcolato sottraendo la data di assunzione dalla data corrente. La ragione per cui Employee Skillset ha il suo proprio schema è perché è un attributo multi-valore.
Per gli schemi relazionali, ogni tipo di entità diventa la propria tabella, e ogni attributo a valore singolo è una colonna all’interno di quella tabella. Gli attributi derivati possono essere tranquillamente ignorati, mentre gli attributi multi-valore diventano tabelle separate.
Il metodo per convertire i tipi di entità deboli allo schema relazionale è simile al processo descritto sopra, eccetto che i tipi di entità deboli diventano tabelle proprie e la chiave primaria dell’entità forte agisce come chiave esterna nella tabella.
Questo significa che per l’entità forte Employee, si creerebbe una chiave primaria composta dalla chiave esterna Dependent e la chiave dell’entità debole stessa. Ciò renderebbe lo schema simile a questo:
- Impiegato (Nome, Numero ID, Numero indirizzo, Via, Città, Codice postale, Data di assunzione)
- Dipendente (Impiegato, ID dipendente, Nome, Indirizzo)
La correlazione qui è tra il Numero ID nella tabella Impiegato e l’elemento Dipendente della tabella Dipendente.
Con questo lavoro fatto, siete pronti per iniziare la conversione delle relazioni. Per farlo è necessario capire la cardinalità e il grado di ogni relazione.
- Ci sono tre cardinalità possibili – 1:1, 1:M, 1:N
- Ci sono tre gradi possibili – unario, binario e ternario.
Prendendo l’esempio precedente, Employee potrebbe essere combinato con una nuova tabella Department per formare una relazione binaria 1:1. Se l’impiegato gestisce un dipartimento specifico, allora lui o lei può essere descritto come un partecipante parziale, mentre il dipartimento sarebbe descritto come un partecipante totale.
Lo schema relazionale sarebbe come questo:
- Dipendente (Nome, Numero ID, Numero Indirizzo, Via, Città, CAP, Data di assunzione)
- Dipartimento (Numero ID del manager, ID del dipartimento, Nome, Indirizzo)
In questo caso, la chiave primaria del partecipante parziale diventa la chiave esterna del partecipante totale. Il numero ID del manager è correlato al numero ID del dipendente appropriato.
Questo mostra una parte importante della creazione dello schema relazionale. La chiave primaria di uno dei due partecipanti in una relazione binaria 1:1 può diventare una chiave esterna nell’altro. Un altro modo di descrivere la relazione di cui sopra sarebbe usare Manages come chiave esterna sotto Employee, correlata alla chiave primaria Department ID sotto Department.
Un esempio di relazione binaria 1:N sarebbe quella tra un insegnante che insegna una materia. In una particolare classe, gli insegnanti possono insegnare più di una materia ad una varietà di studenti, ma tutte le materie condividono la stessa relazione con l’insegnante.
Nella relazione binaria 1:1 di cui sopra, ogni dipartimento ha un manager unico. Con questa relazione binaria 1:N, un numero variabile di studenti può condividere lo stesso insegnante. La chiave primaria di Teacher sarebbe l’ID Teacher, che sarebbe correlato alla chiave esterna di Subject, sotto Teacher.
Per descrivere una relazione binaria M:N, immaginate uno studente che si iscrive a un corso. Create una nuova tabella che descriva Studente e un’altra che descriva Corso. Entrambe queste tabelle sono collegate attraverso l’atto dell’iscrizione, ed entrambe hanno chiavi esterne.
- La chiave esterna per Studente è l’ID Studente.
- La chiave esterna per Corso è l’ID Corso.
La chiave primaria della nuova tabella è la combinazione delle chiavi esterne di ogni entità. Si potrebbe descrivere come (ID studente, ID corso). Questo è uno schema relazionale binario unico M:N che collega i singoli studenti ai corsi.
Questo funziona perché gli ID sono, per loro natura, creati allo scopo di essere chiavi esterne nei database relazionali.
Si può usare uno schema relazionale per descrivere relazioni auto-referenziali. Per esempio, due impiegati che sono sposati l’uno con l’altro potrebbero avere la chiave esterna Spouse. Per entrambe le chiavi esterne di questi dipendenti, il riferimento sarà all’ID dipendente dell’altro dipendente, che è la chiave primaria della rispettiva tabella di ciascun dipendente.
Questo funziona anche in uno schema di relazione con cardinalità 1:N. Il campo chiave primaria stesso diventerebbe la chiave esterna della stessa tabella in questo caso. Questo è lo stesso di uno schema unario 1:1.
Per esempio, un Impiegato che è il manager di un Subordinato può avere manager come sua chiave esterna. In questo caso, l’ID del dipendente sarebbe la chiave primaria nella stessa tabella.
L’autoreferenziazione di una relazione M:N richiede due tabelle. Una deve rappresentare l’entità in questione e l’altra deve rappresentare la relazione M:N.
Immaginate un dipendente che è responsabile di garantire la qualità di un certo prodotto o servizio. Questa relazione dovrebbe includere sia il Garante che il Beneficiario come chiavi esterne che si combinano per correlarsi con l’ID del dipendente della tabella Employee. Sia il Garante che il Beneficiario agirebbero come chiavi primarie ed esterne all’interno della tabella dello schema relazionale appena creato.
Mentre le relazioni binarie e unarie sono semplici da descrivere usando lo schema relazionale con una o due tabelle. Le tabelle ternarie richiedono una terza, nuova tabella.
La chiave primaria di questa nuova tabella consiste nella chiave esterna di ogni entità partecipante, sommata. Questo significa che la nuova tabella deve contenere tre chiavi esterne a cui correlare.
Per esempio, la relazione tra un medico e il suo paziente consiste effettivamente di tre entità: Il medico, il paziente e la medicina. Per descrivere correttamente questa relazione come schema relazionale, dovete assegnare delle chiavi esterne a ciascuna di queste entità e correlarle a una nuova tabella intitolata Prescrizione.
Questo è un modo semplice di visualizzare il funzionamento di una tabella ternaria. La chiave primaria della tabella Prescription appena creata è (ID medico, ID paziente, ID farmaco). Qualsiasi schema che non includa questi tre importanti dati manca una parte importante del puzzle.
Questo approccio permetterebbe a un gestore di database di creare un archivio organizzato di prescrizioni che tiene conto di specifici tipi di farmaci, immediatamente correlati ai nomi dei pazienti che li stanno usando e offrono i nomi dei medici che li hanno prescritti.
Per completezza, potreste voler aggiungere la data di scadenza alla tabella Medicina in modo che questi dati siano disponibili nella matrice principale. Puoi aggiungere Next Appointment o Refill Date alla tabella Prescription. Vorresti logicamente aggiungere Data di nascita, Indirizzo, e altri dati relazionali importanti alla tabella Paziente.
Tutti questi strumenti si combinano per rendere possibile la creazione di database orientati alle relazioni in MySQL. Potete esercitarvi a creare i vostri database MySQL online con qualsiasi browser usando SQLDBM.
.