Guida al Visual Basic .NET
Capitolo 71° - Introduzione ai database relazionali
Il modello relazionale non è stato il primo in assoluto ad essere usato per la gestione dei database, ma è stato introdotto più tardi, negli anni '70, grazie alle idee di E. F. Codd. Ad oggi, è il modello più diffuso e utilizzato per la sua semplicità. Tale modello si basa su un unico concetto, la relazione, una tabella costituita da righe (o record o tuple) e colonne (o attributi). Per definire una relazione, basta specificarne il nome e gli attributi. Ad esempio: Person (FirstName, LastName, BirthDay)indica una relazione di nome Person, che presenta tre colonne, denominate rispettivamente FirstName, LastName e BirthDay. Una volta data la definizione, però, è necessario anche fornire dei dati che ne rispettino le regole: dobbiamo aggiungere delle righe a questa tabella per rappresentare i dati che ci interessano, ad esempio:
L'insieme di tutte le righe della relazione si dice estensione della relazione, mentre ogni singola tupla viene anche chiamata istanza di relazione. Facendo un parallelismo con la programmazione ad oggetti, quindi, avremo queste "somiglianze" (che si riveleranno di vitale importanza nella tipizzazione forte, come vedremo in seguito): DatabaseProgrammazione ad oggetti Relazione-> Classe Tupla -> Oggetto Estensione della relazione -> Lista di oggetti Attributo-> Propriet? dell'oggetto Istanza di relazione -> Istanza di classe (= Oggetto)Avendo ora chiarito questi parallelismi, vi sarà più facile entrare nella mentalità del modello relazionale, dato che, se siete arrivati fino a qui, si assume che sappiate già benissimo tutti gli aspetti e i concetti della programmazione ad oggetti. Uno sguardo attento, tuttavia, farà notare che, tra i caratteri fondamentali che si possono rintracciare in questi parallelismi, manca il concetto di "tipo" di un attributo. Infatti, per come abbiamo prima definito la relazione, sarebbe del tutto lecito immettere un numero intero nel campo FirstName o una stringa in BirthDay. Per fortuna, il modello prevede anche che ogni colonna possegga un dominio, ossia uno specifico range di valori che essa può assumere: ciò che noi abbiamo sempre chiamato tipo. Il tipo di un attributo può essere scelto tra una gamma molto limitata: interi, valori a virgola mobile, stringhe (a lunghezza limitata e non), date, caratteri, boolean e dati binari (array di bytes). In sostanza, questi sono i tipi primitivi o atomici di ogni linguaggio e proprio per questo motivo, si dice che il dominio di un attributo può essere solo di tipo atomico, ossia non è possibile costruire tipi di dato complessi come le strutture o le classi. Questa peculiarità sembrerebbe molto limitativa, ma in realtà non è così, poiché possiamo instaurare dei collegamenti (o vincoli) tra una relazione e l'altra, grazie all'uso di elementi detti chiavi. La chiave più importante è la chiave primaria (primary key), che serve ad identificare univocamente una tupla all'interno della relazione. Facendo un paragone con la programmazione, se una tupla è assimilabile ad un oggetto ed esistono due tuple con attributi identici, esse non rappresentano comunque la stessa entità, proprio come due oggetti con proprietà uguali non sono lo stesso oggetto. E se per gli oggetti esiste un codice "segreto" per distinguerli (guid), a cui solo il programma ha accesso, così esiste un particolare valore che serve per indicare senza ombra di dubbio se due record sono differenti: questo valore è la chiave primaria. Essa è solitamente un numero intero positivo ed è anche la prima colonna definita dalla relazione. Modificando la definizione di Person data precedente, ed introducendo anche il dominio degli attributi, si otterrebbe: 'Questa sintassi è del tutto inventata! 'Serve solo per esemplificare i concetti: Person (ID As Integer, FirstName As String, LastName As String, BirthDay As Date)
Per distinguere le singole righe esiste, poi, un'altra tipologia di chiave, detta chiave candidata, costituita dal più piccolo insieme di attributi per cui non esistono due tuple in cui quegli attributi hanno lo stesso valore. In generale, tutte le chiavi primarie sono chiavi canditate, a causa della stessa definizione data poco fa; mentre esistono chiavi candidate che non sono chiavi primarie. Ad esempio, in questo caso, l'insieme degli attributi FirstName, LastName e BirthDay costituisce una chiave candidata, poichè è praticamente impossibile trovare due persone con lo stesso nome nate nello stesso giorno alla stessa ora (almeno, è impossibile nella nostra relazione formata da due elementi XD e questo ci basta): quindi, questi tre attributi soddisfano le condizioni della definizione e identificano univocamente un record. In genere, si sceglie una fra tutte le chiavi candidate possibili che viene assunta come chiave primaria: a rigor di logica, essa dovrà essere la più semplice di tutte. In questo caso, il singolo numero ID è molto più maneggevole che non l'insieme di due stringhe e una data. Ora, ammettiamo di avere una relazione così definita: Program (ProgramID As Integer, Path As String, Description As String)che indica un qualsiasi programma installato su un computer; e quest'altra relazione: User (UserID As Integer, Name As String, MainFolder As String)che indica un qualsiasi utente di quel computer. Ammettiamo anche che la macchina sulla quale sono installati i programmi presenti nell'estensione della relazione sia condivisa da più utenti: vogliamo stabilire, tramite relazioni, quale utente possa accedere a quale programma. In questa circostanza, abbiamo diverse soluzioni possibili, ma una sola è la migliore:
C#, TypeScript, java, php, EcmaScript (JavaScript), Spring, Hibernate, React, SASS/LESS, jade, python, scikit, node.js, redux, postgres, keras, kubernetes, docker, hexo, etc...
|
