Sei sulla pagina 1di 9

Database ECIPAR © Ghirardi Carmen

DATABASE

TEORIA

ELENCO QUERY

TEORIA

I PRINCIPI BASE PER LO SVILUPPO DELLA STRUTTURA DI UN ARCHIVIO DATI

LA STRUTTURA DI UN DATABASE RELAZIONALE

- TABELLA Una tabella identifica un’insieme di elementi che condividono le stesse proprietà. In un archivio dati le tabelle distinguono i diversi elementi chiave: in parole povere, le “cose” (dette ENTITA’) di cui è necessario registrare informazioni.

ES.:

In un database per una libreria, una tabella identificherà sicuramente i libri. In un database per un ospedale si potranno individuare le tabelle per i pazienti, i medici, le camere. Per un magazzino, i prodotti, i movimenti.

- CAMPO Un campo individua una proprietà comune all’elemento chiave individuato da una tabella. Una tabella possiede comunemente più di un solo campo, la totalità dei quali rappresenta le “proprietà” (o ATTRIBUTI) dell’elemento relativo alla tabella stessa.

ES.:

La tabella relativa ai libri conterrà sicuramente campi come titolo, descrizione, editore. La

tabella dei pazienti di un ospedale avrà nome, cognome, permanenza, data di nascita. I prodotti avranno un prezzo, una data di scadenza.

- RECORD Un record è un’intera riga di una tabella, le cui colonne sono individuate dai campi che possiede. Questo significa che un RECORD è un informazione completa su un singolo dato archiviato nel database.

ES.:

Per la tabella libro, contenente i campi titolo, descrizione, editore, un record è ‘Il Simbolo

Perduto Thriller sulla massoneria scritto da Daniel Brown Editore Non Mi Ricordo’. Per la tabella prodotti con i campi titolo, prezzo, data di scadenza avremo per esempio ‘Passata

di Pomodoro 3,00 euro – 03/03/2010’.

CONCETTO DI CHIAVE PRIMARIA Ogni singolo RECORD in una tabella deve essere univoco: significa che non deve esistere un record uguale ad un altro, come logicamente non esiste due volte lo stesso paziente o due volte lo stesso libro (NB: anche se di un libro vengono pubblicate milioni di copie, ogni copia ha il suo codice ISBN a identificarne la sua univocità). Per questo

Database ECIPAR © Ghirardi Carmen

Database ECIPAR © Ghirardi Carmen

motivo in un database avremo bisogno di un CODICE IDENTIFICATIVO tramite il quale distingueremo un certo record da tutti gli altri. Questo codice viene chiamato CHIAVE PRIMARIA, ed è assolutamente necessario per le relazioni fra tabelle.

- RELAZIONE La consultazione di un database necessita di un sistema efficiente per la ricerca di dati correlati a più di una sola tabella, perciò una RELAZIONE comporta il collegamento tra tabelle che sono logicamente legate fra loro.

ES.:

Se individuiamo in un database di una libreria una tabella che individua i libri, e un’altra che individua i clienti, è logicamente conseguente che i libri siano legati al cliente tramite l’acquisto. Se la libreria necessita di archiviare il numero di acquisti fatti da un certo cliente, o semplicemente sapere quali libri questo ha acquistato, le due tabelle dovranno essere in relazione. Se in un ospedale si vuole controllare il rapporto medico-paziente, queste tabelle dovranno essere in relazione.

TIPI DI RELAZIONE

- RELAZIONE 1 A 1 Quando abbiamo un legame univoco da entrambe le parti, avremo una relazione ti tipo 1:1. Questo tipo di relazione si crea grazie alla chiave primaria di ciascuna delle due tabelle, la quale sarà identica per il record della prima e per il suo gemello nella seconda.

ES.:

Prendendo in considerazione una mostra canina dove ogni partecipante umano avrà uno, e uno solo, relativo partecipante a quattro zampe, si individueranno le tabelle umani e cani, logicamente legate fra loro in modo univoco: un umano accompagna un cane e un cane viene accompagnato da un umano: relazione 1:1. Ipotizziamo che la tabella umani sia composta dai campi ID (la chiave primaria), nome, età. E la tabella cani da ID (chiave primaria), razza. Individuiamo dei record:

(UMANI) ‘… – Carmen – 20’ ‘… – Paolo – 30’ (CANI) ‘… – Border Collie’ ‘… – Pit Bull Terrier’ Notiamo che lo spazio per le chiavi primarie è vuoto: come le assegnamo se vogliamo mettere in relazione, per esempio, Carmen con il cane di razza Border Collie e Paolo con il Pit Bull? Procediamo con l’assegnare semplicemente la STESSA chiave primaria per i due record in relazione, avremo quindi:

(UMANI) ‘200 – Carmen – 20’ ‘201 – Paolo – 30’ (CANI) 200 – Border Collie’ ‘201 – Pit Bull Terrier’ In questo modo, dalla chiave primaria di un record potremo risalire al suo gemello.

Database ECIPAR © Ghirardi Carmen

Database ECIPAR © Ghirardi Carmen

- RELAZIONE 1 a MOLTI Quando il legame fra due parti è univoco da una parte ma molteplice dall’altra, avremo una relazione 1:n. Questa relazione si crea grazie alla chiave primaria della tabella che è in relazione univocamente e alla chiave esterna di quella che è in relazione molteplicemente.

CONCETTO DI CHIAVE ESTERNA Quando un singolo record fa riferimento a PIU’ record in un’altra tabella, in quest’ultima è necessario uno spazio per memorizzare il codice identificativo (la chiave primaria) del record esterno (cioè di un’altra tabella) che si relaziona a quelli interni. Questo spazio viene chiamato CHIAVE ESTERNA, e funziona come riferimento (essendone identico) alla chiave primaria di un’altra tabella, permettendo così la relazione dello stesso record esterno su più record interni (cioè della tabella che contiene la chiave esterna).

ES.:

Ipotizzando che in un ospedale un singolo medico visiterà diversi pazienti, ma un paziente riceverà visite da uno e un solo medico, avremo una relazione 1:n, dove la tabella che si relaziona univocamente è quella dei medici e molteplicemente quella dei pazienti. Graficamente risulta più chiaro:

MEDICO 1n PAZIENTE Un medico si relaziona con più pazienti. Un paziente si relaziona con un solo medico.

Individuiamo i campi per la tabella medici: id, nome, cognome. E i campi per i pazienti: id, nome, malattia. Manca la chiave esterna: abbiamo detto che la chiave esterna è contenuta dalla tabella che si relazione in modo molteplice, quindi la tabella pazienti. Ipotizzando dei record, avremo quindi:

(MEDICI) ‘110 – Mario – Rossi’ ‘111 – Michele – Bianchi’ (PAZIENTI) ‘200 – Francesco Cancro - …’ ‘201 – Antonio Ferita - …’ I puntini indicano lo spazio per la chiave esterna. Come lo riempiamo volendo relazionare entrambi i pazienti a Mario Rossi? Semplicemente copiando la chiave primaria di Mario Rossi in entrambi i pazienti Francesco e Antonio:

(MEDICI) ‘110 – Mario – Rossi’ ‘111 – Michele – Bianchi’ (PAZIENTI) ‘200 – Francesco Cancro - 110’ ‘201 – Antonio Ferita - 110’ In questo modo diversi record potranno fare riferimento allo stesso senza compromettere la loro unicità, perché possiedono chiavi primarie differenti (non come nella relazione 1:1).

Database ECIPAR © Ghirardi Carmen

Database ECIPAR © Ghirardi Carmen

- RELAZIONE MOLTI A MOLTI Spesso e volentieri capita di individuare una relazione logica molteplice da entrambe le parti, avremo quindi una relazione di tipo n:m. Questa relazione necessita di entrambe le chiavi primarie delle due tabelle, e di un’ulteriore tabella che conterrà due chiavi esterne, ciascuna relativa alla chiave primaria di una tabella.

ES.:

Consideriamo due tabelle negozi e fornitori: può capitare che un negozio faccia riferimento a diversi fornitori e sicuramente un fornitore rifornirà più di un negozio. In questo caso si presenta una chiara relazione molteplice da entrambe le parti.

NEGOZIO

nm

FORNITORE

Rappresentiamo ora l’inserimento della terza tabella che conterrà le due chiavi esterne.

NEGOZIO

1n

TABELLA-DI-RELAZIONE

n1

FORNITORE

Come vediamo, una relazione n:m equivale a due relazioni 1:n specchiate. Ciò significa che avremo una chiave primaria nelle tabelle che si relazionano univocamente e due chiavi esterne (una per ogni chiave primaria) nella tabella che si relazione molteplicemente. Individuando i campi id, titolo, settore per la tabella negozi e id, luogo per la tabella fornitori, potremmo inventare i record:

(NEGOZI) ‘100 - Bata – Scarpe’ ‘101 – Lush – Cosmetici’ ‘102 – Harnold’s – Gelateria’ (FORNITORI) ‘200 – Parma’ ‘201 – Sorbolo’ ‘202 – Collecchio’ Ora è necessario popolare la tabella di relazione che contiene le chiavi esterne. Come fare? Semplice, in base a qualche record vogliamo relazionare copiamo le loro chiavi primarie nella terza tabella. Volendo per esempio legare Bata con Sorbolo e Collecchio, Lush con Sorbolo, e Harnold’s con Parma e Collecchio:

(TABELLA DI RELAZIONE) ‘100 – 201’ [Bata-Sorbolo] ‘100 – 202’ [Bata-Collecchio] ‘101 – 201’ [Lush-Sorbolo] ‘102 – 200’ [H.-Parma] ‘102 – 202’ [H.-Collecchio] In questo modo avremo raccolto tutte le combinazioni volute nella tabella apposita.

Database ECIPAR © Ghirardi Carmen

Database ECIPAR © Ghirardi Carmen

ANALISI

- DAL PROBLEMA ALLA STRUTTURA Comunemente il programmatore si trova di fronte ai problemi del cliente, con lo scopo di risolverli con sistemi “all’avanguardia”. Il problema esposto dal cliente è il 100% delle volte confuso: spesso nemmeno lui sa veramente quel che vuole. Perciò sta al programmatore sviluppare la capacità fondamentale di raccogliere le giuste informazioni, fare in modo che siano esaurienti, saperle analizzare correttamente e suddividerle in uno schema che vada a formare una struttura di database relazionale. Sembra un procedimento impossibile! A volte comunque l’apparenza inganna, in questo caso basta seguire pochi punti fondamentali, almeno per iniziare:

1. IPOTIZZATE Fare ipotesi, in mancanza di un reale cliente (nel caso di un esercitazione, per esempio…) non è un male! All’opposto, è l’unico modo che abbiamo per cucire veramente ogni “toppa” nella stesura del problema. Avere domande senza risposta, quando si tratta di formare uno schema logico e rigido, è una situazione da evitare a qualsiasi costo! Ovviamente, se la vostra non è un’esercitazione, CHIEDETE al cliente. Le risposte devono essere esaurienti.

2. INDIVIDUATE GLI ELEMENTI CHIAVE Una volta che avete esaurito le domande da porvi (o porre), è il momento di “rileggersi” il problema e “sottolineare” (farlo letteralmente non è un male) quelle “parole” che hanno buone probabilità di diventare delle vere e proprie entità e quindi TABELLE della struttura. Ripetete lo stesso procedimento per le proprietà di ogni entità individuata, e avrete trovato i CAMPI delle tabelle.

3. RAPPRESENTATE GRAFICAMENTE Ora che avete la struttura base delle vostre tabelle manca solo di metterle in relazione. Trovato il tipo di ogni collegamento logico (1:1, 1:n, n:m) rappresentatelo graficamente disegnando ogni tabella e legandola con una freccia alla sua relativa. Questo tipo di grafico è fondamentale per la consultazione veloce della struttura da parte vostra, quando svilupperete ricerche al suo interno.

Il risultato è che avrete alla vostra portata TABELLE, CAMPI e RELAZIONI pronti da inserire in una struttura pratica su un reale database.

Database ECIPAR © Ghirardi Carmen

Database ECIPAR © Ghirardi Carmen

ELENCO QUERY

LAVORARE SUI DATI ARCHIVIATI

INTERROGARE IL DATABASE

- COS’E’ UNA QUERY Il termine “query” sta ad indicare l’interrogazione del database. In altre parole, “eseguire una query” significa fare una richiesta al database. Questa richiesta viene espressa in un linguaggio:

il più comune è il linguaggio SQL ed è della sua sintassi che ci occuperemo.

- LA CONSULTAZIONE La richiesta più basilare che possiamo fare a un database è la consultazione: ossia gli chiediamo di fornirci delle informazioni che contiene. Sfruttando i termini della struttura, gli chiediamo dei dati contenuti nei suoi record. Vediamo la sintassi SQL delle più comuni consultazioni:

SELECT [nomeCampo1],[nomeCampo2],… FROM [nome Tabella]

Questa query ci permette di visualizzare i campi richiesti di una tabella di tutti record presenti in quest’ultima.

ES.:

Abbiamo la tabella persone con i campi id, nome, cognome. (PERSONE) ‘200 – Mario – Rossi’ ‘201 – Franscesco – Inzaghi’ Eseguiamo la query ‘SELECT nome, cognome FROM persone’ Avremo in risposta ‘Mario – Rossi’ ‘Francesco – Inzaghi’ NB: al posto dei nomi dei campi, possiamo utilizzare il simbolo *, che significa TUTTI.

Database ECIPAR © Ghirardi Carmen

Database ECIPAR © Ghirardi Carmen

SELECT * FROM [nome Tabella] WHERE [condizioneSuUnCampo]

Il comando WHERE ci permette di limitare la richiesta con un vincolo, che può essere espresso in termini di > (maggiore), < (minore), = (uguale) su uno più campi.

ES.:

Consideriamo la stessa tabella persone, con gli stessi record. Eseguiamo la query ‘SELECT * FROM persone WHERE nome=”Mario”’ Avremo in risposta ‘200 – Mario – Rossi’ Da notare che viene visualizzato anche l’id, in quanto abbiamo usato il simbolo * per richiedere tutti i campi, e che il record 201 viene escluso, in quanto il suo campo nome NON è uguale a “Mario”. NB: La condizione si può esprimere su più campi, unendo la condizione su un campo con la condizione del secondo campo. Si possono usare operatori come AND e OR. Rispettivamente, AND richiede che entrambe le condizioni siano vere perché il record venga visualizzato mentre OR necessita che O una O l’altra (o entrambe) sia vera.

SELECT [nomeCampo1],[nomeCampo2],… FROM [nome Tabella] INNER JOIN [nomeTabella2] ON [chiave P]=[chiave E] WHERE [condizioneSuUnCampo]

Quando abbiamo bisogno di risalire a record contenuti in una certa tabella, ma filtrandoli secondo delle condizioni sui campi di un’altra tabella, ci serve l’INNER JOIN. Ovviamente è implicito che le due tabelle debbano essere in relazione. Ciò che compie il comando INNER JOIN è l’intersezione fra tutti i record di tutte le tabelle, allineandoli secondo la corrispondenza delle chiavi primarie/esterne.

Database ECIPAR © Ghirardi Carmen

Database ECIPAR © Ghirardi Carmen

ES.:

Consideriamo la solita tabella persone, e ipotizziamo una seconda tabella cani. Individuiamo il tipo di relazioni persone 1n cani. Avremo perciò la tabella cani con chiave esterna e campi nome, razza. (CANI) ‘300 – Jack Pastore - 200’ ‘301 – Pippi Barboncino - 200’ ‘302 – Trilli Snautser - 201’ Ricordiamoci che questa rappresentazione sta a significare che Jack e Pippi sono di Mario, mentre Trilli è di Francesco. Se volessi quindi sapere dal mio database tramite una query, i nomi dei cani di Mario (id=200)? Eseguo la query ‘SELECT nome FROM persone INNER JOIN cani ON id,idPersone WHERE id=200Avremo in risposta ‘Jack’ ‘Pippi’ NB: idPersone è il nome del campo adibito alla chiave esterna nella tabella cani.

SELECT [nomeCampo1],[nomeCampo2],… FROM [nome Tabella] ORDER BY [nome Campo]

Grazie a questa SELECT la tabella che ci verrà restituita ordinerà tutte le colonne in base a un campo scelto.

SELECT COUNT([nomeCampo1]) FROM [nome Tabella]

Anche quest’ultimo SELECT è piuttosto utilizzato: ci restituirà il numero totale di record trovati sotto il campo specificato. NB: Questo comando è chiamato “funzione di aggregazione” in SQL, e dello stesso tipo troviamo anche SUM() che somma il valore dei record sotto il campo richiesto, SUB() che sottrae e AVG() che ottiene la media matematica.

Database ECIPAR © Ghirardi Carmen

Database ECIPAR © Ghirardi Carmen

- INSERIMENTO, AGGIORNAMENTO E ELIMINAZIONE Dopo le query di consultazione, sono fondamentali le query che ci consentono di andare a scrivere sul database. In altre parole, in questo modo possiamo lavorare sui record, inserendone di nuovi, modificandoli, eliminandoli.

INSERT INTO [nome Tabella] VALUES ([valoreCampo1],[valoreCampo2]…)

In questo modo inseriamo un’intera riga (un nuovo record completo) alla nostra tabella.

UPDATE [nome Tabella] SET

[nomeCampo1]=[valoreCampo1],

[nomeCampo2]=[valoreCampo2],

WHERE [condizione SuUnCampo]

Dato il nome della tabella dove vogliamo aggiornare, specifichiamo i nuovi valori del record campo per campo e tramite la condizione WHERE specifichiamo su quale record andare ad operare.

DELETE FROM [nome Tabella] WHERE [condizioneSuUnCampo]

Infine possiamo andare a eliminare un’intera riga (un record completo) data la condizione per cui è quello il record da eliminare.

Database ECIPAR © Ghirardi Carmen