{"id":1,"date":"2023-04-11T16:18:58","date_gmt":"2023-04-11T16:18:58","guid":{"rendered":"https:\/\/www.suffritti.it\/?p=1"},"modified":"2023-04-11T17:19:57","modified_gmt":"2023-04-11T17:19:57","slug":"hello-world","status":"publish","type":"post","link":"https:\/\/www.suffritti.it\/?p=1","title":{"rendered":"Appunti sui database relazionali e sul linguaggio SQL"},"content":{"rendered":"\n\n

Appunti sui DataBase Relazionali e sul linguaggio \nSQL<\/FONT><\/H1>Autore Pietro \nSuffritti <\/FONT><\/TT><\/B> \nVersione 1.1, pubblicata il 27\/01\/2004 sulla base della 1.0 del 15\/02\/2002<\/FONT><\/TT><\/B><\/P>\n basato in origine sul documento “Introduction to \nStructured Query Language ver. 4.71” di James Hoffmann, poi pesantemente rielaborato e riscritto, reperibile all’ URL HTTP:\/\/w3.one.net\/~jhoffman\/sqltut.htm<\/A> <\/FONT><\/TT><\/B><\/P>\n Queste pagine nascono a causa della richiesta rivoltami dai membri dell’ \nERLUG di Modena di tenere un corso introduttivo sull’ SQL ANSI (un grazie \nparticolare a quel rompiscatole di Andrea “Andy” Papotti che con le sue battute \ne richieste mi ha spinto a fare questa robaccia). \n Non avendo io la minima esperienza n\u00e9 di SQL ANSI (normalmente ammetto di \nlavorare con il transact-sql di SQLServer 7.0) n\u00e9 tantomeno di corsi ho \nricercato su internet una guida introduttiva all’ SQL ANSI su cui basarmi ed ho \ntrovato l’ottima “Introduction to Structured Query Language” di James Hoffmann a \ncui ho attinto a piene mani per sviluppare questi appunti, ampliandoli con una \ndisgressione su cos’\u00e8 un database e traducendoli in italiano. Spero di non avere \nintrodotto troppi errori, ma tengo a precisare che il medesimo James Hoffmann mi \nha autorizzato via mail a fare tutto ci\u00f2. Presto vedr\u00f2 di tradurre anche \npedissequamente il suo documento e metterlo sempre qui, distaccando quindi in \nseguito questo documento sempre di pi\u00f9 dal suo originale, ed aggiungendovi nuove \nsezioni. In ogni caso riconosco al suddetto quanto di buono pu\u00f2 esserci in \nquesto documento mentre mi assumo la colpa di qualsiasi boiata io possa avervi \nintrodotto,e come nel documento originale vi segnalo l’ esistenza di un SQL Club \nnell’ area forum di Yahoo rintracciabile a questo link: SQL Club on \nYahoo!<\/A> . \n Voglio comunque chiarire che era mia intenzione creare un documento in \ncui la semplicit\u00e0 di comprensione fosse INCREDIBILMENTE pi\u00f9 importante della \nprecisione (di manuali di SQL e’ pieno il mondo, se dovete usarlo davvero fate \nriferimento a quelli), per cui invoco la clemenza della corte per le incredibili \nsemplificazioni che ho qui utilizzato nel tentativo (orrore!) di uscire dal \nlinguaggio tecnico per avvicinarmi a qualcosa che anche mia madre, insegnante di \nscuola materna dotata di un ottimo cervello ma di preparazione informatica quasi \nnulla, potesse comprendere. Spero che i tecnici mi perdoneranno e che i non \ntecnici possano trarne un qualche vantaggio.<\/P>\n Ringrazio Decio Biavati per avermi aiutato traducendo l’ ultimo pezzettino \nresiduo del documento di Hoffmann ancora presente in inglese. Colgo l’ occasione \nper dirgli per\u00f2 che se invece che in formato doc l’ avesse fatto in html avrei \napprezzato ancora di pi\u00f9 \ud83d\ude42<\/P>\n \nIndice<\/FONT><\/B> \n\n Introduzione \n sui database<\/A> Cos’e’ un \n database? <\/A>Piccola \n storia dei database assolutamente incompleta<\/A><\/P>\n I \n DataBase Relazionali <\/A>SQL \n questo sconosciuto <\/A>Commit \n e Rollback, ovvero come limitare i danni <\/A>I \n Semafori , ovvero la gestione della multiutenza<\/A><\/P>\n Il \n Linguaggio SQL<\/A><\/P><\/BLOCKQUOTE>\n Basi del \ncomando SELECT <\/A> Selezione \nCondizionata<\/A> Operatori \nRelazionali<\/A> Condizioni \npi\u00f9 complesse: Condizioni multiple e Operatori Logici<\/A> \n IN, BETWEEN e \nNOT <\/A> <\/A>Utilizzare \nla clausola LIKE ed il carattere jolly %<\/A> I \nJoin <\/A> Le \nChiavi <\/A> Creare un \nJoin <\/A> <\/B><\/I>Clausola \nDISTINCT e l’Eliminazione dei Duplicati<\/A> Alias, \nIn e l’utilizzo delle Subquery<\/A> \nFunzioni \ndi Aggregazione <\/A>Viste<\/A> Creare Nuove \nTabelle<\/A> Modificare \nla struttura delle tabelle <\/A>Inserire \ndati in una tabella<\/A> Cancellare \ndati da una tabella<\/A> Modifica dei \ndati<\/A> \n Gli \nIndici<\/A> GROUP BY ed \nHAVING<\/A> Altre Subquery<\/A> \n EXISTS ed \nALL<\/A> UNION ed \nOuter Joins<\/A> Sommario \ndella Sintassi – Solo per veri masochisti <\/A>Sommario \ndei Link relativi all’ SQL<\/A> <\/P><\/DIR>\n \n\nINTRODUZIONE SUI \nDATABASE<\/A><\/FONT><\/B><\/P>\n cos’\u00e8 un \ndatabase<\/A><\/FONT><\/B><\/P>\n In tutti i corsi che io ho frequentato la definizione di cosa sia un database \n\u00e8 stata o allegramente saltata (dando per scontato che tutti sapessero di cosa \nsi stava parlando) o definita con un criptico linguaggio pseudomatematico per me \ndi difficile comprensione, pertanto tento di esporre qui quello che io ho capito \nessere un database (con buona pace di professori e puristi dell’ \ninformatica)<\/P>\n Al di l\u00e0 dei termini complessi e da iniziati un database (del tipo “un \ninsieme strutturato di dati che in un momento n fornisce una rappresentazione \nsemplificata di una realt\u00e0 in evoluzione”) un database non \u00e8 altro che una \nspecie di “contenitore” che ci permette di gestire grossi quantitativi di \ninformazioni simili in maniera ordinata e (si spera) pi\u00f9 semplice e veloce che \ncon grossi libroni cartacei o documenti di tipo foglio di calcolo o \ntesto. <\/P>\n Piccola storia dei \ndatabase assolutamente incompleta<\/A><\/FONT><\/B><\/P>\n Probabilmente il pi\u00f9 glorioso (ed a tutt’ oggi utilizzato) antenato dei \ndatabase relazionali odierni pu\u00f2 essere identificato con la sana e vecchia \nagenda telefonica. in effetti penso che se guardiamo come \u00e8 fatta la \nnostra agenda scopriremo una notevole affinit\u00e0 con i sui parenti pi\u00f9 tecnologici \nattuali. Infatti \u00e8 organizzata tramite un indice (la serie di linguette sul \nfianco che ci permette di accedere pi\u00f9 rapidamente a tutti i nominativi che \niniziano con una certa lettera) che gestisce una tabella composta da colonne che \nidentificano il tipo di dato sotto riportato (nome, numero di telefono, a volte \nindirizzo) all’ interno delle registrazioni (vogliamo chiamarle con il termine \ninglese “record”?) che , pur differendo l’ una dall’ altra per i dati riportati \nal loro interno “hanno tutti la stessa struttura”, cio\u00e8 riportano le stesse \ninformazioni nella medesima maniera.<\/P>\n Il primo tentativo di cui io sono a conoscenza compiuto dagli informatici per \nriversare questo tipo di oggetti in un “coso” trattabile dalle loro grosse \ncalcolatrici corrisponde al nome di CSV (Comma Separated Value), cio\u00e8 un \nbanalissimo file di testo dove ogni informazione (numero di telefono di pino, \nnome di gino, indirizzo di tino) \u00e8 separata dalle altre tramite un carattere \nparticolare (normalmente una virgola) ed ogni record (vedi definizione spora \nriportata, cio\u00e8 la riga della nostra agenda) \u00e8 separato dagli altri tramite un’ \naltro carattere (normalmente il carattere di “a capo”). Ovviamente questo \nsistema era decisamente embrionale, in quanto comunque per trovare all’ interno \ndi un file del genere una informazione specifica era spesso necessario \nscorrerselo quasi tutto ed in modo poco pratico per trovare quanto si \nricercava.<\/P>\n la logica evoluzione del CSV fu l’ISAM (Indexed Sequential Access Method), \nche differiva dal CSV solo per il fatto che i record non erano “buttati dentro a \ncasaccio” (cio\u00e8 in ordine di inserimento), bens\u00ec veniva definito un ordinamento \n(tipicamente nel caso della nostra agenda l’ ordine alfabetico sui cognomi) che \nveniva sfruttato sia in scrittura (“dove devo mettere il record del telefono di \nAnna?” “sotto la lettera A tra Anita ed Antonio”) sia in lettura (“dove hai \ninfilato il numero di telefono di Pietro?” ” lettera P, tra Paolo e Pinocchio”) \npermettendo in questo modo di abbreviare incredibilmente i tempi di ricerca di \nuna data informazione. Per riuscire poi a gestire ancora meglio il tutto si \ncrearono anche delle specie di “archivi sussidiari”, detti indici, in cui \nveniva registrato solo l’ ordine dei vari record senza tutte le altre \ninformazioni, il che permetteva di andare a svolgere le proprie ricerche in \nquesto “riassunto” in modo molto pi\u00f9 veloce (meno roba da leggere=ci metto di \nmeno a leggerla) e poi “puntare diritti” sul database completo per leggere tutto \nil record una volta che si sapeva dov’era<\/P>\n A questo punto parecchi matematici di notevole ingegno si misero a cercare \nmetodi per rendere ancora pi\u00f9 veloce l’ accesso alle informazioni che ci \nservivano sfornando sistemi di ricerca dai nomi fantasiosi come “ricerca \ndicotomica” o ” a farfalla” (che non \u00e8 nostro interesse qui approfondire) , \nsviluppando cos\u00ec tutti quei sistemi oggi definiti “Database non relazionali” (in \ncontrapposizione ai database relazionali che vedremo dopo) di cui forse i pi\u00f9 \nfamosi sono stati i database B-Trieve e DBIII-like (clipper, DBIII, DBIV \necc)<\/P>\n con l’evoluzione di questi ultimi i database ebbero una notevole diffusione e \nquindi iniziarono a nascere richieste di affidabilit\u00e0 e di prestazioni sempre \nmaggiori, con uno sviluppo teorico notevole dietro ad essi, che permetteva a \nquesto punto di affrontare diversi problemi, di cui di seguito elenco quelli pi\u00f9 \nconosciuti (forse da me: sicuramente un teorico dei database potr\u00e0 aggiungerne \naltri milioni). sia chiaro, alcuni di questi problemi venivano egregiamente \naffrontati dai database non relazionali, ma raramente tutti insieme ed in \nmaniera affidabile<\/P>\n \n La ridondanza dei dati: ergo “ma non esiste proprio un modo per evitare \n di rimettere nel mio database della contabilit\u00e0 duemila volte l’ indirizzo del \n mio cliente principale?” \n L’ uniformit\u00e0 dei dati “oddio, come ho chiamato la Johns Coopers and \n Lybrand Incorporated l’ ultima volta? JCL? J.C.L. ? J.C.L Inc.? J.C.& L. \n Inc?” \n L’indipendenza dalla piattaforma “scusa Aristide, ti ricordi sul tuo \n sistema come devo fare per vedere il contenuto di una tabella? perch\u00e9 su \n quello di Asdrubale devo fare cos\u00ec, su quello di Antonio cos\u00e0 e sul mio in un \n modo completamente diverso” \n La sicurezza delle transazioni “ARGH! stavo mettendo dentro al database \n tutte le fatture dell’ ultimo semestre quando \u00e8 andata via la corrente ed \n adesso non so se l’ ultima me l’ ha presa o no! cosa faccio, devo ricostruire \n l’ intera tabella delle fatture per essere certo che non ci siano valori doppi \n o inseriti a met\u00e0??” \n La possibilit\u00e0 di gestire correttamente un ambiente multiutente “Mi \n spieghi perch\u00e9 io sono certo di avere inserito l’ ordine per le ultime dieci \n scatole di pirulazio a nome del mio miglior cliente e quelle sono finite \n invece al peggior cliente di un’ altro commerciale? eppure SO di averle \n fermate al magazzino io per primo..” <\/LI><\/OL>\nPer risolvere tutti questi problemi in maniera soddisfacente si \u00e8 dovuto \ncambiare il modo di “pensare” i database, portando cos\u00ec alla nascita dei \ndatabase relazionali<\/P>\n <\/P>\nI Database \nRelazionali<\/A><\/FONT><\/B><\/P>\n allora cosa sono questi famigerati Database relazionali? il concetto che sta \nalla base \u00e8 , come spesso succede nell’ informatica, molto meno “strampalato” di \nquello che si pensa: invece di fare un’ enorme tabella in cui \u00e8 contenuto TUTTO \nil database si divide lo stesso in tante tabelle che contengono dati logicamente \ncorrelati e per metterle insieme si usano delle relazioni tra l’ una e l’ altra \ntabella. vediamo di fare un qualche esempio per capirci meglio.<\/P>\n Per il nostro esempio prenderemo in esame il database di una piccola gestione \ndi una videoteca di famiglia.Vogliamo tenere registrati tutti i film che abbiamo \nin modo da sapere su di essi le seguenti informazioni:<\/P>\n \n il titolo \n il regista \n l’ attore protagonista \n l’ attrice protagonista \n l’ anno di uscita nelle sale del film \n il tipo di supporto \n se l’ ho in casa o se l’ ho prestato a qualcuno \n a chi l’ ho eventualmente prestato: nome, cognome e numero di telefono \n il genere del film \n se nostra figlia di 5 anni pu\u00f2 vederlo o non \u00e8 proprio il caso \n un breve riassunto della trama <\/LI><\/OL>\nnel modo “classico” avremmo realizzato un’ unica “tabellona” pi\u00f9 o meno di \nquesto tipo:<\/P>\n\n \n \n \n \n \n \n Videoteca<\/P><\/TD><\/TR>\n cod<\/TD>\n titolo<\/TD>\n regista<\/TD>\n attore<\/TD>\n attrice<\/TD>\n anno<\/TD>\n supporto<\/TD>\n PrestNome<\/TD>\n PrestCogn<\/TD>\n PrestTel<\/TD>\n Genere<\/TD>\n VM18<\/TD>\n trama<\/TD><\/TR>\n 1<\/TD>\n l\u00e0 dove scorre il fiume<\/TD>\n Redford<\/TD>\n DeNiro<\/TD>\n Stone<\/TD>\n 85<\/TD>\n DVD<\/TD>\n <\/TD>\n <\/TD>\n <\/TD>\n Dramma<\/TD>\n no<\/TD>\n xxx<\/TD><\/TR>\n 2<\/TD>\n Proposta indecente<\/TD>\n Spielberg<\/TD>\n Redford<\/TD>\n Pfeiffer<\/TD>\n 91<\/TD>\n VHS<\/TD>\n Gigi<\/TD>\n Salvioli<\/TD>\n 05808086<\/TD>\n sexy<\/TD>\n si<\/TD>\n yyy<\/TD><\/TR><\/TBODY><\/TABLE>\nin questo modo abbiamo registrato poche informazioni e di difficile uso. \nproviamo allora a ragionarci sopra e vediamo che vogliamo in realt\u00e0 registrare 3 \ndiversi tipi di dati, nella fattispecie:<\/P>\n \n i dati della cassetta vera e propria: codice, titolo, supporto, genere, \n vietata si\/no , trama \n i dati di persone che lavorano nei film: regista, attore, attrice \n i dati dei nostri amici a cui potremmo voler prestare la cassetta <\/LI><\/UL>\na questo punto prendiamo in mano un database relazionale e creiamo non una ma \ntre tabelle:<\/P>\n\n \n \n \n \n \n \n Cassette<\/P><\/TD><\/TR>\n CodCass<\/TD>\n Titolo<\/TD>\n CodReg<\/TD>\n CodAtt1<\/TD>\n CodAtt2<\/TD>\n Anno<\/TD>\n Supporto<\/TD>\n CodPrest<\/TD>\n Genere<\/TD>\n VM18<\/TD>\n trama<\/TD><\/TR>\n 1<\/TD>\n l\u00e0 dove scorre il fiume<\/TD>\n 1<\/TD>\n 2<\/TD>\n 3<\/TD>\n 85<\/TD>\n DVD<\/TD>\n 0<\/TD>\n dramma<\/TD>\n no<\/TD>\n xxx<\/TD><\/TR>\n 2<\/TD>\n Proposta indecente<\/TD>\n 4<\/TD>\n 1<\/TD>\n 5<\/TD>\n 85<\/TD>\n VHS<\/TD>\n 1<\/TD>\n Sexy<\/TD>\n SI<\/TD>\n yyy<\/TD><\/TR><\/TBODY><\/TABLE>\n <\/P>\n\n \n \n \n \n \n \n \n \n \n Personaggi del cinema<\/P><\/TD><\/TR>\n CodPers<\/TD>\n Cognome<\/TD>\n Nome<\/TD>\n VintoOscar<\/TD><\/TR>\n 1<\/TD>\n Redford<\/TD>\n Robert<\/TD>\n si<\/TD><\/TR>\n 2<\/TD>\n DeNiro<\/TD>\n Robert<\/TD>\n si<\/TD><\/TR>\n 3<\/TD>\n Stone<\/TD>\n Sharon<\/TD>\n no<\/TD><\/TR>\n 4<\/TD>\n Spielberg<\/TD>\n Stephen<\/TD>\n si<\/TD><\/TR>\n 5<\/TD>\n Pfeiffer<\/TD>\n Michelle<\/TD>\n no<\/TD><\/TR><\/TBODY><\/TABLE>\n <\/P>\n\n \n \n \n \n \n \n \n Amici<\/P><\/TD><\/TR>\n CodAmico<\/TD>\n Cognome<\/TD>\n Nome<\/TD>\n Telefono<\/TD>\n Indirizzo<\/TD><\/TR>\n 0<\/TD>\n non prestata<\/TD>\n <\/TD>\n <\/TD>\n <\/TD><\/TR>\n 1<\/TD>\n Salvioli<\/TD>\n Gigi<\/TD>\n 0547778899<\/TD>\n via Garibaldi 5<\/TD><\/TR>\n 2<\/TD>\n Persiceto<\/TD>\n Gennaro<\/TD>\n 0547558877<\/TD>\n via Mazzini 6<\/TD><\/TR><\/TBODY><\/TABLE>\nin questo modo, oltre ad inserire molti pi\u00f9 dati abbiamo gi\u00e0 risolto due dei \nproblemi citati sopra: inseriremo una sola volta Robert de Niro per tutte le \nvolte che vorremo usarlo in punti differenti del nostro database ed avremo \nsempre la certezza di chiamarlo Redford, Robert e non r.redford,robertredford, \nRobert Redford ecc…<\/P>\n in compenso abbiamo un problema : come faccio a capire che la cassetta di \nproposta indecente l’ ho prestata a Gigi Salvioli e non ad un fantomatico signor \n1 ? risposta: tramite delle relazioni<\/P>\n una delle cose che dovrebbe saltare immediatamente all’ occhio guardando le \ntabelle dell’ esempio \u00e8 il fatto che ogni record ha un suo codice univoco \n(spesso chiamato “chiave primaria” ) che identifica lui e solo lui (non ci sono \nn\u00e9 possono essere due personaggi del cinema con CodPers=1) e che tali codici \nvengono richiamati all’ interno della tabella delle cassette: si pu\u00f2 quindi dire \nche ho stabilito una relazione tra i campi della tabella cassette CodReg, \nCodAtt1 e CodAtt2 e il campo CodPers della tabella personaggi del cinema, cos\u00ec \ncome ho stabilito una relazione tra CodAmico della tabella Amici e CodPrest \n(risolvendo peraltro il fastidio di avere caselle vuote per indicare che la \ncassetta \u00e8 in mio possesso). in questo modo tramite un apposito sistema di \ndefinizione delle relazioni si possono creare database estremamente complessi ma \ndi consultazione abbastanza semplice. con una appropriata gestione degli indici \nsulle tabelle inoltre si pu\u00f2 ottenere un tempo di accesso ai dati decisamente \nsoddisfacente<\/P>\n SQL questo \nsconosciuto<\/A><\/FONT><\/B><\/P>\n Abbiamo appena finito di dire che uno dei requisiti fondamentali per poter \nutilizzare un database relazionale e’ avere un “linguaggio” che ci permetta di \ninterrogarlo in maniera opportuna, cosa che gli informatici (che complottano tra \ndi loro usando sigle strane per non farsi capire dai non iniziati) chiamano \nRDBMS, cio\u00e8 Relational DataBase Management System. come spesso succede nel mondo \ndell’ informatica anche in questo caso e’ nato uno “standard” che avrebbe \npermesso a tutti di parlare la stessa lingua, ed appena e’ nato sono nati cos\u00ec \ntanti dialetti che non parlano l’ uno con l’altro da potercisi affogare. Questo \nstandard si chiama ANSI SQL (Structured Query Language della American National \nStandard Institute), e ovviamente sebbene TUTTI dicano che il loro linguaggio e’ \nANSI Compliant (compatibile con l’ ansi SQL) in realt\u00e0 tutti hanno differenze \nsostanziali l’ uno con l’altra. i pi\u00f9 diffusi linguaggi SQL oggi sono \n(ovviamente) quelle dei pi\u00f9 diffusi database, cio\u00e8<\/P>\n \n Oracle SQL \n Transact – SQL \n PostgreSQL \n MySQL \n SQLInformix \n DBII SQL \n ecc… <\/LI><\/UL>\nnon potendo fare un corso su ognuno di essi (in primis perch\u00e9 molti non li \nconosco) noi faremo invece riferimento all’ ANSI SQL. ma prima di partire con il \nlinguaggio soffermiamoci un’ attimo sugli altri punti mancanti delle richieste \nche abbiamo fatto ai nostri database relazionali: la possibilit\u00e0 di riuscire a \nrecuperare la situazione in caso di guasto e di lavorare in un sistema \nmultiutente<\/P>\nCommit e Rollback, ovvero \ncome limitare i danni<\/A><\/FONT><\/B><\/P>\n In tutti i database relazionali minimamente decenti esistono due comandi \nfondamentali che rispondono per l’ appunto al nome di commit e rollback. questi \ndue comandi provvedono a fare in modo che una determinata operazione venga \neffettuata come un tutto unico o che non venga effettuata per niente. vediamo di \ncapire cosa significa.<\/P>\n Mettiamo che voi stiate gestendo il database di una banca e che dobbiate \neffettuare un bonifico bancario; questa operazione in realt\u00e0 si divide in almeno \ndue distinte operazioni:<\/P>\n \n aumentare il saldo del conto corrente del destinatario della cifra in \n esame \n diminuire il saldo del conto corrente del mittente della stessa cifra pi\u00f9 \n quella dovuta per le commissioni <\/LI><\/OL>\nora, cosa succederebbe se a met\u00e0 dell’ operazione il sistema avesse dei \nproblemi (stile corrente che salta, un errore logico come la mancanza del record \ndel destinatario, un processore fuso per il troppo calore,un impiegato impazzito \ncon grosso martellone che picchia sul server)? a seconda dell’ ordine in cui le \neffettuate potete avere i seguenti risultati:<\/P>\n\n i soldi vengono tolti dal cc del mittente e non arrivano in quello del \n destinatario: risultato il destinatario del bonifico vuole il vostro sangue \n i soldi NON vengono tolti dal cc del mittente, arrivano in quelli del \n destinatario e la banca ce li rimette: risultato dovete cercarvi in fretta \n un’altro lavoro DOPO averli sborsati voi <\/LI><\/OL>\nentrambi i risultati non brillano per piacevolezza, ma per fortuna vi vengono \nincontro i due comandi suddetti. come funzionano?<\/P>\n Quando si fa qualcosa che deve venire gestito come un tutt’ uno si inizia la \nprocedura con una istruzione BEGIN TRANSACTION, che indica il punto di inizio \ndel nostro codice “a rischio” . a questo punto il nostro database non esegue pi\u00f9 \nle variazioni direttamente sul disco ma in una particolare area temporanea \n(normalmente in memoria) e se la tiene parcheggiata l\u00ec finch\u00e9 non sente un \ncomando COMMIT. a quel punto in un’ unica soluzione fa TUTTE le variazioni che \nha precalcolato in contemporanea. nel caso qualcosa andasse storto l’ intera \ntransazione andrebbe persa e quindi il bonifico non verrebbe fatto, sicuramente \nuna situazione meno spiacevole di quella citata prima (anche perch\u00e9 pu\u00f2 venire \nrifatto). E’ inoltre possibile forzare questo avvenimento tramite l’ istruzione \nROLLBACK nel caso che il problema sia di tipo software (esempio ho gli estremi \ndel mittente ma in tabella non esiste il destinatario, quindi sebbene sia gi\u00e0 \npartito a togliere i soldi dal primo non posso metterli sul secondo) . un tipico \nesempio di gestione commit-rollback pu\u00f2 essere la seguente:<\/P>\n BEGIN \nTRANSACTION; \n\/\/ inizio della transazione <\/CODE><\/P>\n USE \nbanca1; \n\/\/ utilizza il database di nome BANCA1<\/CODE><\/P>\n UPDATE \nconticorrenti \n\/\/ aggiorna la tabella dei conti correnti<\/CODE><\/P>\n SET saldo = saldo + 1000000 \/\/ \naggiungendo un milione al saldo<\/CODE><\/P>\n WHERE ccn = \n181818 \n\/\/ del conto corrente numero 181818<\/CODE><\/P>\n ON ERROR \nROLLBACK; \n\/\/ in caso di un qualunque errore effettua un rollback ed annulla \ntutto<\/CODE><\/P>\n USE \nbanca2; \n\/\/ utilizza il database di nome BANCA2<\/CODE><\/P>\n UPDATE \nconticorrenti \n\/\/ aggiorna la tabella dei conti correnti<\/CODE><\/P>\n SET saldo = saldo – 1000000 \/\/ \nsottraendo un milione al saldo<\/CODE><\/P>\n WHERE ccn = \n161616; \n\/\/ del conto corrente numero 161616<\/CODE><\/P>\n ON ERROR \nROLLBACK; \n\/\/ in caso di un qualunque errore effettua un rollback ed annulla \ntutto<\/CODE><\/P>\n COMMIT; \n\/\/ effettua tutta la transizione in una volta<\/CODE><\/P>\n attenzione, l’ esempio fatto sopra e’ un classico esempio di pi\u00f9 ISTRUZIONI \ninserite in un’ unica transazione , ma in genere se non specifichiamo nulla ogni \nsingola istruzione viene gestita come una transazione a se stante, pertanto se \ndurante l’ esecuzione della nostra update su due milioni di campi crolla il \nsistema, le procedure di ripristino provvederanno a fare si che NESSUNA modifica \ndella due milioni che stavamo facendo compaia, il che e’ incredibilmente \npreferibile al non sapere su quali record la modifica e’ gi\u00e0 stata apportata e \nsu quali no<\/P>\nI Semafori , ovvero la \ngestione della multiutenza<\/A><\/FONT><\/B><\/P>\n Chiariamo subito una cosa: gi\u00e0 linguaggi come Clipper avevano strumenti per \ngestire la multiutenza sui database, ma in quel caso ancora era \ncompletamente demandato al programmatore il fatto di inserire apposite \nistruzioni per gestire tale eventualit\u00e0, mentre nei moderni motori database chi \ngestisce la multiutenza e’ il motore stesso (a meno che il programmatore o il \nDataBase Administrator non vogliano fare giochini strani ed in quel caso se ne \nprendono la responsabilit\u00e0). ma come viene gestita questa multiutenza? nella \nmaniera pi\u00f9 semplice del mondo: chi primo arriva meglio alloggia. per spiegarsi \nun po’ meglio la cosa funziona in questo modo:<\/P>\n Tutte le volte che noi accediamo ad un determinato record possiamo accedervi \nin tre diverse modalit\u00e0: in lettura, in scrittura o in lettura E scrittura. la \nprocedura di accesso ai record SA in che modo noi vogliamo accedere (o perch\u00e9 ha \nuna impostazione di default o perch\u00e9 noi stessi glielo abbiamo detto) e provvede \nquindi ad imporre un “limite” sul set di record su cui stiamo lavorando che po’ \nessere normalmente uno dei seguenti:<\/P>\n \n record libero in lettura e scrittura \n record in sola lettura (divieto di modifica) \n record bloccato sia in lettura che in scrittura <\/LI><\/UL>\nquesto tipo di gestione (normalmente definito “a semafori” ) permette di \nevitare che due persone tentino contemporaneamente di modificare lo stesso \nrecord, permettendo cos\u00ec di evitare i problemi che nascono con la \nmultiutenza<\/P>\n \n\nIl Linguaggio \nSQL<\/A><\/FONT><\/B><\/P>\n Ora che abbiamo visto rapidamente cosa sta alla base di un database \nrelazionale entriamo nel dettaglio del linguaggio SQL, analizzandone i \ncomandi<\/P>\n Basi del comando \nSELECT<\/A><\/FONT><\/B> <\/P>\n Come abbiamo detto prima nell’ introduzione, nei database relazionali le \ninformazioni sono contenute in tabelle. Un esempio di tabella puo’ essere \nrappresentato dalla tabella dei dati degli impiegati riportata qui sotto \n\n \n \n \n \n \n \n \n \n TabellaImpiegati<\/B><\/P><\/TD><\/TR>\n CFisc<\/B><\/TD>\n Nome<\/B><\/TD>\n Cognome<\/B><\/TD>\n Indirizzo<\/B><\/TD>\n Citta<\/B><\/TD>\n Provincia<\/B><\/TD><\/TR>\n ALSNTN60R18F115Z<\/TD>\n Alessandro<\/TD>\n Antoni<\/TD>\n Vicolo Fastidio 23<\/TD>\n Sesso<\/TD>\n Bologna<\/TD><\/TR>\n FRCBNC58A55F254W<\/TD>\n Franca<\/TD>\n Bianchi<\/TD>\n Via Rua Pioppa 15<\/TD>\n Modena<\/TD>\n Modena<\/TD><\/TR>\n OSCGRG75F23K242Z<\/TD>\n Oscar<\/TD>\n Gorgo<\/TD>\n Piazza Ugo Bassi 23<\/TD>\n Forl\u00ec<\/TD>\n Forl\u00ec Cesena<\/TD><\/TR>\n SMNZNT71D12F251K<\/TD>\n Simone<\/TD>\n Zanti <\/TD>\n Via Radici in piano 115<\/TD>\n Sassuolo<\/TD>\n Modena<\/TD><\/TR><\/TBODY><\/TABLE>\nadesso tentiamo di leggere gli indirizzi dei nostri impiegati.Utilizziamo l’ \nistruzione SELECT cos\u00ec: \n SELECT Nome, Cognome, Indirizzo, Citta, Provincia<\/TT> FROM \nTabellaImpiegati;<\/TT> \n Il risultato della vostra prima QUERY (interrogazione) del database sar\u00e0 \nquesto: \n\n \n \n \n \n \n \n Nome<\/B><\/TD>\n Cognome<\/B><\/TD>\n Indirizzo<\/B><\/TD>\n Citta<\/B><\/TD>\n Provincia<\/B><\/TD><\/TR>\n Alessandro<\/TD>\n Antoni<\/TD>\n Vicolo Fastidio 23<\/TD>\n Sesso<\/TD>\n Bologna<\/TD><\/TR>\n Franca<\/TD>\n Bianchi<\/TD>\n Via Rua Pioppa 15<\/TD>\n Modena<\/TD>\n Modena<\/TD><\/TR>\n Oscar<\/TD>\n Gorgo<\/TD>\n Piazza Ugo Bassi 23<\/TD>\n Forl\u00ec<\/TD>\n Forl\u00ec Cesena<\/TD><\/TR>\n Simone<\/TD>\n Zanti <\/TD>\n Via Radici in piano 115<\/TD>\n Sassuolo<\/TD>\n Modena<\/TD><\/TR><\/TBODY><\/TABLE>\nSpieghiamo cosa avete appena fatto. Avete appena chiesto al vostro database \ndi farvi vedere tutti i dati contenuti nella tabella TabellaImpiegati, ed in \nparticolare di mostrarvi solo il contenuto delle colonne Nome, Cognome, \nindirizzo, citt\u00e0 e provincia. E’ il caso di notare che nei nomi delle colonne e \nnel nome della tabella non sono presenti spazi, che sono un tipo di carattere \nnon ammesso per specificare i nomi di tali elementi. La sintassi generalizzata \ndi questo comando, per ricevere sulle colonne specificate tutte le righe di una \ntabella, e’ la seguente:\n SELECT NomeColonna, NomeColonna, …<\/TT> FROM \n<\/TT>NomeTabella<\/TT>;<\/TT> \n Per ricevere invece tutte le colonne, senza specificarle una ad una, potete \nusare: \n SELECT * FROM NomeTabella;<\/TT>\n Notiamo due cose in particolare da questa prima istruzione:\n Ogni comando SQL viene concluso (terminato) da un carattere particolare che \ne’ normalmente il carattere “;”. finch\u00e9 SQL non incontra tale carattere continua \nad interpretare i caratteri che legge come facenti parti della stesa istruzione. \ncorollario fondamentale di questo fatto e’ che possiamo spezzare il comando \nstesso su pi\u00f9 righe allo scopo di ottenere una migliore leggibilit\u00e0 senza \nparticolari problemi (ATTENZIONE: questo carattere VARIA da DBMS a DBMS, \nCONTROLLATE QUAL’E’ il carattere di separazione nel particolare DBMS che state \nusando). \n \nSelezione \nCondizionata<\/A><\/FONT><\/B> \nPer continuare la discussione sulla selezione, facciamo riferimento a questa \nnuova tabella di esempio<\/P>\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n TabellaStatisticheImpiegati<\/B><\/P><\/TD><\/TR>\n CodiceImpiegato<\/B><\/TD>\n StipendioAnnuo<\/B><\/TD>\n Benefici<\/B><\/TD>\n Posizione<\/B><\/TD><\/TR>\n 010<\/TD>\n 75000000<\/TD>\n 15000000 <\/TD>\n Dirigente<\/TD><\/TR>\n 105<\/TD>\n 65000000<\/TD>\n 15000000 <\/TD>\n Dirigente<\/TD><\/TR>\n 152<\/TD>\n 60000000<\/TD>\n 15000000 <\/TD>\n Dirigente<\/TD><\/TR>\n 215<\/TD>\n 60000000<\/TD>\n 12500000 <\/TD>\n Dirigente<\/TD><\/TR>\n 244<\/TD>\n 50000000<\/TD>\n 12000000 <\/TD>\n Impiegato<\/TD><\/TR>\n 300<\/TD>\n 45000000<\/TD>\n 10000000 <\/TD>\n Impiegato<\/TD><\/TR>\n 335<\/TD>\n 40000000<\/TD>\n 10000000 <\/TD>\n Impiegato<\/TD><\/TR>\n 400<\/TD>\n 32000000<\/TD>\n 7500000 <\/TD>\n Apprendista<\/TD><\/TR>\n 441<\/TD>\n 28000000<\/TD>\n 7500000 <\/TD>\n Apprendista<\/TD><\/TR><\/TBODY><\/TABLE>\nOperatori Relazionali<\/A><\/H4>Ci sono sei \noperatori relazionali in SQL, e dopo averli specificati vedremo come si usano. \ngli operatori sono: \n\n \n \n \n \n \n \n \n =<\/TD>\n Uguale<\/TD><\/TR>\n <> oppure != (vedere manuali)<\/TD>\n Non Uguale <\/TD><\/TR>\n <<\/TD>\n Minore di<\/TD><\/TR>\n ><\/TD>\n Maggiore di<\/TD><\/TR>\n <=<\/TD>\n Minore o uguale di<\/TD><\/TR>\n >=<\/TD>\n Maggiore o uguale di<\/TD><\/TR><\/TBODY><\/TABLE>\nLa clausola WHERE <\/I>viene utilizzata per specificare che si desidera \nvedere solo certe righe della tabella, basandosi per la scelta sul criterio \nstabilito nella clausola stessa. Penso che un paio di esempi possano rendere pi\u00f9 \nchiaro il funzionamento della stessa.\n Se si vuole vedere il Codice Impiegato di quegli impiegati che hanno uno \nstipendio annuo maggiore di 50 milioni possiamo farlo cos\u00ec: \n SELECT CodiceImpiegato<\/TT> FROM TabellaStatisticeImpiegati<\/TT> \n WHERE StipendioAnnuo >= 50000000;<\/TT> \n Notate che abbiamo utilizzato il simbolo >= (Maggiore o uguale di), in \nquanto vogliamo vedere sia coloro che hanno uno stipendio di 50 milioni che \nquelli che hanno uno stipendio maggiore di 50 milioni. il risultato sar\u00e0 il \nseguente: \n CodiceImpiegato<\/TT> ————<\/TT> 010<\/TT> \n 105<\/TT> 152<\/TT> 215<\/TT> 244<\/TT> \n la parte del comando WHERE<\/I> che contiene la regola discriminante, \nin questo caso StipendioAnnuo >= 50000000, e’ conosciuta come una \ncondizione<\/I> (un’ operazione il cui risultato pu\u00f2 essere Vero o \nFalso).<\/I> La stessa cosa pu\u00f2 essere fatta anche con colonne che contengono \ntesto invece che numeri: \n SELECT CodiceImpiegato<\/TT> FROM TabellaStatisticheImpiegati<\/TT> \n WHERE POSIZIONE = ‘Dirigente’;<\/TT> \n Questo comando mostrer\u00e0 come risultato il codice impiegato di tutti i \ndirigenti. Generalmente quando si utilizzano colonne di testo ci si limita agli \noperatori = e != , e bisogna assicurarsi che tutti i testi utilizzati compaiano \nnel comando racchiusi tra singoli apici (‘). N.B. il singolo apice e’ l’ \nidentificatore di testo nell’ SQL ANSI, ma alcuni DBMS usano altri qualificatori \ncome i doppi apici. \n Condizioni pi\u00f9 complesse: Condizioni multiple e Operatori \nLogici <\/FONT><\/A>\n L’ operatore AND<\/I> congiunge due o pi\u00f9 condizioni, e ritorna tutte e \nsolo le righe che soddisfano TUTTE le condizioni. Per esempio, per mostrare i \ncodici di tutti gli impiegati con uno stipendio superiore ai 40 milioni si \nutilizza il comando seguente: \n SELECT CodiceImpiegato<\/TT> FROM TabellaStatisticheImpiegati<\/TT> \n WHERE StipendioAnnuo > 40000000 AND Posizione = \n‘Impiegato’;<\/TT> \n L’ operatore OR<\/I> collega anch’esso due o pi\u00f9 condizioni, ma ritorna una \nriga se UNA QUALSIASI delle condizioni inserite risulta vera. ad esempio per \nvedere tutti coloro che hanno uno stipendio annuo inferiore a 40 milioni o \nricevono meno di 10 milioni in benefici accessori si utilizza la seguente query: \n\n SELECT CodiceImpiegato<\/TT> FROM TabellaStatisticheImpiegati<\/TT> \n WHERE StipendioAnnuo < 40000000 OR Benefici < 10000000;<\/TT> \n\n AND ed OR possono venire combinati, come nell’ esempio seguente: \n SELECT CodiceImpiegato<\/TT> FROM TabellaStatisticheImpiegati<\/TT> \n WHERE Posizione = ‘Dirigente’ AND StipendioAnnuo > 60000000 OR \nBenefici > 12000000;<\/TT> \n Per prima cosa, SQL trova le righe in cui lo stipendio annuo e’ maggiore di \n60 milioni e che contengono nella colonna Posizione la parola ‘Dirigente’, \nquindi si tiene in memoria questa lista e controlla che soddisfino la condizione \nOR relativa ad avere benefici per pi\u00f9 di 12 milioni. Notate che la condizione \nAND viene risolta per prima, cosa che modifica nettamente i risultati. spendiamo \nun paio di parole in pi\u00f9 su questo fatto, in quanto se non ben compreso pu\u00f2 \nportare a differenze sostanziali nei risultati delle query ed alla difficile \ncomprensione del perch\u00e9 ci\u00f2 \u00e8 avvenuto.\n Per generalizzare quello che avviene, SQL calcola i risultati delle \noperazioni AND per determinare quali sono le righe che soddisfano la condizione \n(ricordate: TUTTE le condizioni devono essere vere), quindi questi risultati \nvengono utilizzati per essere confrontati con la condizione OR, e vengono \nmostrate solo le righe rimanenti dove una qualsiasi delle operazioni collegate \ndall’ operatore OR risulta vera (True). Matematicamente , SQL valuta tutte le \ncondizioni realizzate tramite operatori relazionali, quindi valuta le “coppie” \ndi AND e quindi gli OR (dove entrambi gli operatori sono valutati da sinistra a \ndestra).\n Per fare un esempio, guardiamo cosa succede quando il nostro DBMS valuta una \ndeterminata condizione, ricordando che i valori booleani “vero” e “falso” in SQL \nvengono espressi come True e False . il primo passo che il DBMS fa e’ di \nvalutare i risultati delle operazioni svolte tramite gli operatori relazionali, \nquindi si prepara a valutare gli operatori logici sui risultati. mettiamo che \ndalla valutazione di una condizione complessa al nostro DBMS sia risultato \nquanto segue: \n True AND False OR True AND True OR False AND False<\/TT> \n La prima cosa che fa sar\u00e0 valutare le coppie di AND, ottenendo quanto segue: \n True AND False<\/U> OR True AND True<\/U> OR False AND False<\/U> = \nFalse OR True OR False 1\u00b0 \ncoppia 2\u00b0 \nCoppia 3\u00b0Coppia<\/TT> \n Quindi parte a valutare gli OR, da sinistra a destra, ottenendo al primo \npassaggio quanto segue: \n False OR True<\/U> OR False = True OR False 1\u00b0 coppia<\/TT> \n ed alla fine, valutando l’ ultima espressione , arriva al risultato \ndefinitivo \n True OR False<\/U> = True<\/TT>\n Il risultato finale e’ True (vero) e quindi la riga che ha generato questa \nsequenza di valori verr\u00e0 inserita all’ interno di quelle passate dalla query. \nAssicuratevi di leggere attentamente anche la prossima sezione sull’ operatore \nNOT e di avere ben compreso l’ ordine di valutazione degli operatori, in quanto \ne’ un argomento difficile da spiegare in poche righe, pertanto posso solo \nsperare di essere stato sufficientemente chiaro.\n Per variare l’ ordine di esecuzione , ad esempio se volete una lista di \ndipendenti che percepiscono uno stipendio maggiore di 50 milioni o con benefici \nmaggiori di 10 milioni e che siano dei dirigenti, si usano le parentesi, come in \nquesto esempio: \n SELECT CodiceImpiegato<\/TT> FROM TabellaStatisticheImpiegati<\/TT> \n WHERE Posizione = ‘Dirigente’ AND (StipendioAnnuo > 50000000 OR \nBenefici > 10000000); \n \n<\/TT>IN , BETWEEN e NOT<\/A><\/I><\/B> \nUn metodo semplice per usare delle condizioni multiple e’ quello di impiegare \nle due clausole IN<\/I> e BETWEEN.<\/I> Per esempio, se volete vedere \ntutti i dipendenti che siano dirigenti o impiegati potete fare cos\u00ec:\n SELECT CodiceImpiegato<\/TT> FROM TabellaStatisticheImpiegati<\/TT> \n WHERE Posizione IN (‘Dirigente’, ‘Impiegato’);<\/TT> \n Oppure per avere la lista di coloro che hanno uno stipendio maggiore o uguale \ndi 30 milioni e minore o uguale a 50 milioni potete impiegare il seguente \ncomando\n SELECT CodiceImpiegato<\/TT> FROM TabellaStatisticheImpiegati<\/TT> \n WHERE StipendioAnnuo BETWEEN 30000000 AND 50000000;<\/TT> \n Invece, per mostrare tutti quelli che non sono compresi nell’ intervallo, \npotete usare:\n SELECT CodiceImpiegato<\/TT> FROM TabellaStatisticheImpiegati<\/TT> \n WHERE StipendioAnnuo NOT BETWEEN 30000000 AND 50000000;<\/TT> \n Similarmente, la clausola NOT IN restituisce tutte le righe escluse \ndalla lista generata dalla relativa IN<\/I>, quindi se voleste vedere tutti \ncoloro che non sono ne’ dirigenti ne’ impiegati potete farlo con il comando\n SELECT CodiceImpiegato<\/TT> FROM TabellaStatisticheImpiegati<\/TT> \n WHERE Posizione NOT IN (‘Dirigente’, ‘Impiegato’);<\/TT> \n Inoltre, l’ operatore NOT pu\u00f2 venire utilizzato in congiunzione con AND \ned OR per invertirne il risultato, ma va tenuto conto che mentre i due operatori \nAND ed OR sono binari (usano 2 condizioni) il NOT e’ unario, cio\u00e8 si riferisce \nad una sola condizione; inoltre il NOT viene calcolato PRIMA dell’ AND e dell’ \nOR . \n Ordine in SQL degli operatori logici (tutti funzionano da \nsinistra a destra)<\/I><\/B> \n\n NOT<\/FONT><\/TT> \n AND<\/FONT><\/TT> \n OR<\/FONT><\/TT> <\/LI><\/OL>Utilizzare la clausola \nLIKE ed il carattere jolly %<\/I><\/A><\/B> \nMettiamo di voler estrarre dalla nostra tabella TabellaImpiegati i codici \nfiscali di tutti gli impiegati il cui nome inizia per “S”; possiamo \nprocedere cos\u00ec:\n SELECT CFisc<\/TT> FROM TabellaImpiegati<\/TT> WHERE NOME \nLIKE ‘A%’;<\/TT> \n Il carattere percento (%) viene utilizzato pre rappresentare ogni possibile \ncarattere (numeri, lettere o segni di interpunzione) o blocchi di caratteri che \npossono venire trovati dopo il carattere “A”. similmente, se volessimo trovare \ncoloro il cui nome termina in “A” potremmo farlo con “%A”, o se volessimo \ntrovare quelli il cui nome contiene una A potremmo farlo con “%A%”. Visto che il \nfunzionamento dell’ operatore Like varia tantissimo da DBMS a DBMS consiglio di \nverificare la sintassi esatta nel vostro sistema prima di impiegarlo e per \nvedere quali altre possibilit\u00e0 vi pu\u00f2 offrire \n \nI Join<\/A><\/FONT><\/B> \nIn questa sezione discuteremo solo degli inner<\/I> joins<\/I>, e \ndegli equijoin<\/I>s<\/I>, che , in genere, sono estremamente utili. \nPer informazioni pi\u00f9 dettagliate in merito vi rimando ai link che ho inserito in \nfondo a questa pagina e che credo possano esservi di un qualche aiuto\n Le norme generali sulla buona progettazione dei database suggeriscono che \nogni tabella contenga dati relativi solo ad una singola “entit\u00e0” e che i dati \naggiuntivi rispetto ad essa possano venire recuperati tramite relazioni con \naltre tabelle create tramite i Join. per prima cosa partiamo da un esempio, \nrappresentato dalle tabelle seguenti: \n \n\n \n \n \n \n \n \n \n \n \n Antiquari<\/P><\/TD><\/TR>\n IDAntiquario<\/B><\/TD>\n CognomeAntiquario<\/B><\/TD>\n NomeAntiquario<\/B><\/TD><\/TR>\n 01<\/TD>\n Jones<\/TD>\n Bill<\/TD><\/TR>\n 02<\/TD>\n Smith<\/TD>\n Bob<\/TD><\/TR>\n 15<\/TD>\n Lawson<\/TD>\n Patricia<\/TD><\/TR>\n 21<\/TD>\n Akins<\/TD>\n Jane<\/TD><\/TR>\n 50<\/TD>\n Fowler<\/TD>\n Sam<\/TD><\/TR><\/TBODY><\/TABLE> \n\n \n \n \n \n \n \n \n \n Ordini<\/B> <\/P><\/TD><\/TR>\n IDAntiquario<\/B><\/TD>\n OggettoRicercato<\/B><\/TD><\/TR>\n 02<\/TD>\n Tavolo<\/TD><\/TR>\n 02<\/TD>\n Scrivania<\/TD><\/TR>\n 21<\/TD>\n Sedia<\/TD><\/TR>\n 15<\/TD>\n Specchio<\/TD><\/TR><\/TBODY><\/TABLE> \n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n Antichita<\/B><\/P><\/TD><\/TR>\n IDVenditore<\/B><\/TD>\n IDAcquirente<\/B><\/TD>\n Oggetto<\/B><\/TD><\/TR>\n 01<\/TD>\n 50<\/TD>\n Letto<\/TD><\/TR>\n 02<\/TD>\n 15<\/TD>\n Tavolo<\/TD><\/TR>\n 15<\/TD>\n 02<\/TD>\n Sedia<\/TD><\/TR>\n 21<\/TD>\n 50<\/TD>\n Specchio<\/TD><\/TR>\n 50<\/TD>\n 01<\/TD>\n Scrivania<\/TD><\/TR>\n 01<\/TD>\n 21<\/TD>\n Cassettiera<\/TD><\/TR>\n 02<\/TD>\n 21<\/TD>\n Tavolinetto da Caff\u00e8<\/TD><\/TR>\n 15<\/TD>\n 50<\/TD>\n Sedia<\/TD><\/TR>\n 01<\/TD>\n 15<\/TD>\n Portagioielli<\/TD><\/TR>\n 02<\/TD>\n 21<\/TD>\n Terracotta<\/TD><\/TR>\n 21<\/TD>\n 02<\/TD>\n Libreria<\/TD><\/TR>\n 50<\/TD>\n 01<\/TD>\n Piantana<\/TD><\/TR><\/TBODY><\/TABLE>\n\n Le Chiavi<\/A><\/B>\n Per prima cosa vediamo il concetto di Chiave<\/I>. Una Chiave \nPrimaria<\/I> ( o primary key) <\/I>e’ una colonna o un gruppo di colonne che \nidentificano in maniera univoca (singola) ogni data riga rispetto alle altre. \nTradotto in un linguaggio un po’ pi\u00f9 semplice, e’ quell’ insieme di informazioni \nche mi permettere di distinguere ogni singolo record da ogni altro record. Per \nesempio, nella tabella Antiquari il campo IDAntiquario distingue in maniera \nprecisa ogni singolo record (non ci sono due record con lo stesso numero nel \ncampo IDAntiquario ne’ ci possono logicamente essere). questo significa che non \npossono esistere due righe della tabella con lo stesso codice in IDAntiquario e \nche se anche due antiquari avessero lo stesso nome e lo stesso cognome sarebbero \ncomunque differenziato da un codice diverso, permettendoci cos\u00ec di non \nconfonderli tra di loro, e che quindi ci verr\u00e0 molto pi\u00f9 comodo usare il codice \nrispetto al nome + cognome per collegarci alle altre tabelle del database.\n Una Chiave Esterna<\/I> (o foreign key<\/I> ) e’ invece una colonna \npresente in una tabella nella quale si registrano dati che sono la chiave \nprimaria di un’ altra tabella. per fare un’ esempio con il nostro database le \ncolonne IDVenditore e IDAcquirente della tabella antichit\u00e0 sono chiavi esterne \nin quanto fanno riferimento ai valori contenuti nella chiave primaria della \ntabella Antiquari, cio\u00e8 IDAntiquario. In “Informatichese” questa corrispondenza \nviene chiamata Integrit\u00e0 Referenziale<\/I> (o referential integrity <\/I>per \ngli inglesofoni), ed impongono il limite che all’ interno dei campi della \ncolonna della chiave esterna non possono comparire valori che non siano stati \nprecedentemente inseriti nella colonna della chiave primaria relativa, \naltrimenti ci si troverebbe di fronte ad un errore chiamato “Violazione dell’ \nintegrit\u00e0 referenziale<\/I>” che renderebbe il database inconsistente<\/I>, \ncio\u00e8 in pratica inutilizzabile. In pratica, come risulta chiaro dall’ esempio, \nviene utilizzata la chiave primaria di una certa tabella per fare riferimento ai \ndati contenuti nel record relativo senza dovere riportarli nella seconda \ntabella. nel nostro esempio infatti viene utilizzato il campo “IDAntiquario” per \nsapere chi ha comprato e chi ha venduto un determinato oggetto nella tabella \nAntichita, senza dovere riportare il nome ed il cognome sia dell’ acquirente che \ndel venditore. \n Creare un Join<\/A><\/B> \n Lo scopo delle Chiavi appena discusse e’ quella di correlare i dati \nattraverso le tabelle, senza dover in questo modo ripetere su tutte le tabelle i \ndati pi\u00f9 frequenti, il che e’ il vero scopo e la sostanziale differenza tra i \ndatabase relazionali ed altri tipi di database. per esempio possiamo trovare i \nnomi di coloro che hanno comprato una sedia senza dover mettere il nome ed il \ncognome dell’ acquirente nella tabella antichit\u00e0. possiamo infatti ottenerne il \nnome mettendo in relazione coloro che hanno comprato una sedia con la lista di \ntutti i nomi degli antiquari della tabella Antiquari attraverso l’ utilizzo \ndell’ IDAcquirente, che mette in relazione i dati nelle due tabelle. per trovare \ni nomi di chi ha comprato una sedia possiamo , in pratica, utilizzare la \nseguente query: \n SELECT CognomeAntiquario, NomeAntiquario<\/TT> FROM Antiquari, \nAntichita<\/TT> WHERE IdAcquirente = IDAntiquario AND Oggetto = \n‘Sedia’;<\/TT> \n Iniziamo ad analizzare le particolarit\u00e0 di questa query. la prima che balza \nall’ occhio subito e’ che ENTRAMBE le tabelle sono coinvolte nella query e \ncitate di fianco alla clausola FROM. la seconda cosa e’ che nella clausola WHERE \nle due chiavi delle due tabelle sono messe in relazione tramite l’ uso della \ncondizione IdAcquirente = IDAntiquario <\/TT>e quindi ristretto tramite la \ncondizione Oggetto = ‘Sedia’ <\/TT>a coloro che hanno acquistato una sedia. \nLa condizione che mette in collegamento le due tabelle \n(IDAcquirente=IDAntiquario) e’ il nostro Join<\/I> (in italiano connessione). \nVisto che la condizione che crea il join e’ un uguale, questo tipo di join e’ \nchiamato un equijoin<\/I>. Il risultato di questa query saranno due \nnomi: Smith, Bob e Fowler, Sam.\n La notazione a punti <\/I>(Dot notation<\/I>) permette di specificare il \nnome della tabella a cui si riferisce il campo , evitando cos\u00ec possibili \nambiguit\u00e0. pur essendo pi\u00f9 “faticosa” e’ nettamente preferibile visto che \nmigliora notevolmente la leggibilit\u00e0 della query e riduce la possibilit\u00e0 di \nerrori. la nostra query precedente in dot notation sarebbe cos\u00ec: \n SELECT Antiquari.CognomeAntiquario, Antiquari.NomeAntiquario<\/TT> \n FROM Antiquari, Antichita<\/TT> WHERE Antichita.IdAcquirente = \nAntiquari.IDAntiquario AND Antichita.Oggetto = ‘Sedia’;<\/TT> \n Questa notazione non sarebbe (e non e’) necessaria se i nomi di tutti i campi \ndi ogni tabella differissero l’ uno dall’ altro, ma e’ comunque un’ ottima \nabitudine da prendere e diventa fondamentale appena la struttura del database \ncresce a sufficienza da non essere pi\u00f9 verificabile a colpo d’occhio<\/P>Clausola \nDISTINCT<\/A><\/I> e \nl’Eliminazione dei Duplicati<\/A><\/B> \n Prendiamo in esame la necessit\u00e0, nel nostro database di esempio, di avere una \nlista dei codici e dei nomi esclusivamente degli antiquari che hanno venduto un \noggetto. Ovviamente si vorr\u00e0 che nella lista risultante ogni venditore sia \nelencato una sola volta, indipendentemente dal numero di oggetti che ha venduto \n– non vogliamo sapere quanti oggetti ha venduto un antiquario, ma solo che abbia \nvenduto qualcosa (per poterli conteggiare invece fare riferimento alla \nsuccessiva sezione sulle funzioni di aggregazione). Questo significa che \ndobbiamo dire ad SQL di eliminare le righe duplicate delle vendite dello stesso \nantiquario, e quindi elencare ognuno di questi una volta sola. Per ottenere \nquesto scopo utilizzeremo la clausola DISTINCT<\/I>.\n Per prima cosa ci serve un equijoin (come e’ stato spiegato subito sopra) \nalla tabella degli Antiquari per potere ottenere i dati particolareggiati di \nogni antiquario, cio\u00e8 cognome e nome. Ovviamente in merito va mantenuta ben in \nmente quella che prima e’ stata definita l’ Integrit\u00e0 referenziale, cio\u00e8 nel \ncaso in cui non esistesse un record relativo al codice presente nel campo \nIDVenditore all’ interno del campo IDAntiquario nella tabella Antiquari il \nminimo che pu\u00f2 accadere \u00e8 che il record non venga mostrato, mentre addirittura \nsu alcuni DBMS si verificherebbe un errore di integrit\u00e0 referenziale violata \nbloccando l’ esecuzione della query. come abbiamo detto inoltre vogliamo \neliminare le occorrenze multiple dei record nella nostra lista, quindi \nimpieghiamo la clausola Distinct sulle colonne in cui potrebbe verificarsi l’ \noccorrenza multipla stessa\n Per aggiungere un’ ulteriore livello di complessit\u00e0 della query , vogliamo i \nrisultati in ordine alfabetico prima per cognome e poi per nome. per fare questo \npossiamo utilizzare la clausola ORDER BY<\/I> . La nostra query finale sar\u00e0 la \nseguente: \n SELECT DISTINCT IDVenditore, CognomeAntiquario, NomeAntiquario<\/TT> \n FROM Antichita, Antiquari<\/TT> WHERE IDVenditore = \nIDAntiquario<\/TT> ORDER BY CognomeAntiquario, NomeAntiquario;<\/TT> \n In questo esempio particolare, visto che tutti hanno venduto almeno un \noggetto, avremo una lista completa di tutti gli antiquari, in ordine alfabetico \nper cognome e nome. Per uso futuro (cio\u00e8 se un qualche sadico ve lo viene a \nchiedere) tenete presente che questo tipo di Join \u00e8 da considerarsi nella \ncategoria degli inner joins. \n \n<\/I>Alias, In \ne l’ utilizzo delle Subquery<\/A><\/FONT><\/B> \nIn questa sezione parleremo dell’ utilizzo degli Alias<\/I>, dell’ \nIn<\/I> , dell’ utilizzo delle subquery, e come queste possono venire \nutilizzate nel nostro esempio di 3 tabelle. Per prima cosa diamo un’ occhiata \nalla query riportata qui sotto, che ritorna i cognomi di quegli antiquari che \nhanno fatto un’ ordine e che tipo di oggetto hanno ordinato, mostrando solo gli \nordini in essere (se notate infatti esiste un’ antiquario che ha ordinato un’ \noggetto di cui e’ gi\u00e0 in possesso):\n SELECT PERS.CognomeAntiquario Cognome, ORD.OggettoRicercato Oggetto \nOrdinato FROM Ordini ORD, Antiquari PERS<\/TT> WHERE ORD.IDAntiquario \n= PERS.IDAntiquario<\/TT> AND ORD.OggettoRicercato IN<\/TT> \n(SELECT Oggetto<\/TT> FROM Antichita);<\/TT><\/DIR>Questa query \nritorna questo risultato:\nCognome Oggetto Ordinato<\/TT> ——- —————-<\/TT> \n Smith Tavolo<\/TT> Smith Scrivania<\/TT> \n Akins Sedia<\/TT> Lawson Specchio<\/TT> \n C’e’ veramente un mucchio di cose da vedere in questa query. analizziamola \nnello specifico : \n\n Per prima cosa, nella linea della clausola SELECT compaiono le parole \n “Cognome” e “Oggetto Ordinato” che forniscono l’ intestazione delle colonne \n del report ritornato dalla query \n Le parole PERS ed ORD sono alias<\/I>; gli alias sono dei nomi \n alternativi per le due tabelle che compaiono nella clausola FROM e che vengono \n utilizzati come prefissi in tutta la dot notation delle colonne utilizzate \n nella query, in modo da eliminare le ambiguit\u00e0 , in particolar modo nella \n clausola WHERE dell’ equijoin , dove entrambi le colonne si chiamano \n IDAntiquario e quindi la dot notation si renda indispensabile per evitare \n confusione tra i due \n Notate che la tabella Ordini e’ quella che compare per prima nella \n clausola FROM; questo ci permette di essere sicuri che il report verr\u00e0 tratto \n dai dati presenti in questa tabella e che la tabella Antiquari viene \n utilizzata solo per recuperare le informazioni dettagliate (i cognomi) \n La cosa pi\u00f9 importante; l’ AND nella clausola WHERE forza a richiamare la \n subquery contenuta nella clausola IN (“= ANY” o “= SOME” sono due utilizzi \n equivalenti ad IN). Questo e’ quello che fa: la subquery contenuta tra le \n parentesi viene eseguita, ritornando l’ elenco di tutti gli oggetti contenuti \n nella tabella Antichita non essendoci nessuna clausola WHERE nella subquery; \n dopodich\u00e9, perch\u00e9 una riga nella tabella degli ordini possa venire \n inserita nel report finale, il valore del campo OggettoRicercato deve essere \n all’ interno della lista degli oggetti restituita dalla subquery. Per \n chiarire meglio la cosa si pu\u00f2 vederla in questo modo: la subquery ritorna un \n set di oggetti con i quali vengono confrontati gli oggetti presenti nella \n colonna OggettoRicercato e la condizione di inclusione diventa vera solo se il \n valore del campo OggettoRicercato \u00e8 presente nella lista ritornata dalla \n subquery \n Inoltre tenete ben presente che quando usate le clausole IN, “= ANY”, o “= \n SOME” NON potete fare riferimento a pi\u00f9 colonne diverse. sono i valori che \n vengono restituiti a potere essere differenti , e il confronto pu\u00f2 venire \n fatto tra valori differenti contenuti in ogni RIGA ma NON in colonne \n differenti. il viceversa non e’ possibile. <\/LI><\/OL>Ok, penso che abbiamo \ndiscusso in maniera ampia e dettagliata del comando SELECT e penso che dovreste \nessere a questo punto in grado di arrivare a fare query di selezione decisamente \ncomplesse, per cui passiamo agli altri comandi di SQL \n \nComandi SQL Vari<\/FONT><\/B>\nFunzioni di Aggregazione<\/A><\/B>\n In questa sezione introdurr\u00f2 le cinque pi\u00f9 importanti Funzioni di \nAggregazione<\/I>: SUM, AVG, MAX, MIN, e COUNT. Queste funzioni vengono chiamate \nDi Aggregazione perch\u00e9 servono a calcolare valori dai risultati delle query \ninvece che a ottenerne un listato di tutte le righe. Vediamo il significato di \nogni funzione: \n \n SUM () restituisce il totale di tutte le righe, che soddisfano ogni \n condizione, della colonna data, quando tale colonna contiene valori numerici \n AVG () restituisce la media della colonna data \n MAX () restituisce il valore pi\u00f9 elevato della colonna data \n MIN () restituisce il valore pi\u00f9 piccolo della colonna data \n COUNT() restituisce il numero di righe che soddisfano le condizioni \n<\/LI><\/UL>proviamo a fare un po’ di esempi con le tabelle degli impiegati \nutilizzate all’ inizio di questo documento. guardiamo questi tre esempi: \nSELECT SUM(StipendioAnnuo), AVG(StipendioAnnuo)<\/TT> FROM \nTabellaStatisticheImpiegati;<\/TT> \n Questa query ritorna la somma totale di tutti gli stipendi annui presenti \nnella tabella e la media degli stessi \n SELECT MIN(Benefici)<\/TT> FROM TabellaStatisticheImpiegati<\/TT> \n WHERE Posizione = ‘Dirigente’;<\/TT> \n Questa query ritorna il valore del piu’ basso importo annuo preso da un \ndirigente come beneficio accessorio (12 milioni). \n SELECT COUNT()<\/TT> FROM TabellaStatisticheImpiegati<\/TT> \n WHERE POSITION = ‘Impiegato’;<\/TT> \n Questa query risponde dandoci il numero di persone con la qualifica di \nimpiegato (3). \n \nViste<\/A><\/B> \nIn SQL si pu\u00f2 normalmente avere la possibilit\u00e0 di crearsi delle proprie \nviste, cio\u00e8 creare delle query “perenni” che possono venire utilizzate come \ndelle vere e proprie tabelle. normalmente questa funzione pu\u00f2 venire usata da \nogni singolo utente, che sar\u00e0 colui che vedr\u00e0 la vista se non specificato \ndiversamente dal DBA (controllate il vostro DBMS e sentite dal vostro DB \nAdministrator se gli utenti hanno questo diritto). per essere pi\u00f9 precisi quello \nche fa una vista e’ permettervi di assegnare i risultati di una query ad una \nnuova tabella “personale” (cio\u00e8 legata al vostro utente), che potete usare all’ \ninterno di altre query , ed il cui nome potete tranquillamente specificare nella \nclausola FROM come se fosse una qualunque tabella. Generalmente le viste sono \ndinamiche, cio\u00e8 i valori nella tabella vengono rigenerati tutte le volte che \naccedete alla vista stessa. un esempio di creazione di una vista pu\u00f2 essere il \nseguente: \n CREATE VIEW VistaAnt AS SELECT OggettoRichiesto FROM Ordini;<\/TT> \n A questo punto possiamo scrivere una query che usa questa vista come una \ntabella; tabella che in realt\u00e0 sar\u00e0 solo un’ elenco di tutti gli oggetti \nrichiesti proveniente dalla tabella Ordini: \n SELECT IDVenditore<\/TT> FROM Antichita, VistaAnt<\/TT> \n WHERE OggettoRichiesto = Oggetto;<\/TT> \n Questa query mostra il codice del venditore estratto dalla tabella antichit\u00e0 \nquando il campo OggettoRichiesto in quella tabella compare nella vista VistaAnt, \nche e’ semplicemente la lista di tutti gli oggetti richiesti nella tabella degli \nordini, eseguita al momento del lancio della query.Le viste possono essere \nutilizzate sia allo scopo di restringere la visibilit\u00e0 dei dati a determinati \nutenti che per semplificare delle query complesse. \n \nCreare Nuove Tabelle<\/A><\/B>\nTutte le tabelle all’ interno di un database devono venire create prima o \npoi. vediamo come possiamo fare. a titolo di esempio prendiamo in esame la \ncreazione della tabella Ordini: \n CREATE TABLE Ordini<\/TT> (IDAntiquario \nINTEGER NOT NULL,<\/TT> OggettoRicercato CHAR(40) NOT NULL);<\/TT>\n Questo comando dice al DBMS di creare una tabella, gli assegna un nome e \ndefinisce ogni colonna nella stessa. ATTENZIONE: notate che questo comando \nutilizza dei tipi di dato generici, e che i tipi di dato possono variare da DBMS \na DBMS, quindi verificate i tipi di dato disponibili sul vostro. Alcuni tipi di \ndato generalmente disponibili su quasi tutti i DBMS sono: \n\n Char(x) – una serie di caratteri alfanumerici (generalmente la tabella \n ASCII o EBCDIC) , in cui x specifica il numero massimo di caratteri permessi \n nella colonna (spesso conosciuta anche come stringa di caratteri di lunghezza \n x). \n Integer – una colonna di numeri interi, positivi o negativi, i cui massimi \n dipendono da DBMS a DBMS. \n Decimal(x, y) – Una colonna di numeri decimali, in cui x esprime il numero \n massimo di cifre permesso e y il numero di cifre dopo la virgola. per esempio \n il numero pi\u00f9 alto esprimibile in un campo definito Decimal(4,2) e’ 99,99. \n Date – Una colonna contenente delle date nel formato tipico specifico del \n proprio DBMS. \n Logical – Una colonna che pu\u00f2 contenere solo uno dei due seguenti valori: \n TRUE (vero) o FALSE (falso). <\/LI><\/UL>Altra cosa da notare e’ l’ impiego della \nclausola NOT NULL. Questa clausola impone che il relativo campo non possa mai \nvenire lasciato vuoto (deve sempre essere presente un valore per questo campo). \nNel caso si voglia invece permettere l’ inserimento di record con quel \ndeterminato campo vuoto si usa la clausola NULL o, in molti DBMS, se non viene \nspecificato nulla viene associata per default la clausola NULL. \n \nModificare la struttura delle \ntabelle<\/A><\/B>\nSempre con la logica di vedere i comandi all’ interno di esempi pratici, \nvediamo come si puo’ aggiungere una nuova colonna “Prezzo” alla tabella \nantichita per permettere l’ inserimento del prezzo di ogni articolo. vista la \nprossima introduzione dell’ euro inseriamo invece che un valore Integer un \nvalore Decimal di dimensioni tali da poterci permettere di esprimere il prezzo \nsia in lire che in euro: \n ALTER TABLE Antichita ADD (Prezzo DECIMAL(12,2) NULL);<\/TT> \n l’ ovvio complemento della clausola ADD qui utilizzata per aggiungere una \ncolonna e’ la clausola REMOVE che permette di eliminare una colonna specificata. \ni dati in questa nuova colonna possono essere modificati o inseriti come \nspecificato poco oltre. \n \n\nInserire dati in una \ntabella<\/A><\/B><\/P>\n Per inserire record (righe) in una tabella si usa il seguente comando \n(esempio riferito alla tabella Antichita a cui e’ appena stato aggiunto il \nprezzo) : \n INSERT INTO Antichita VALUES (21, 01, ‘Ottomana’, 2000000.00);<\/TT> \n Questo comando inserisce una nuova riga nella tabella, nell’ ordine dei campi \npredefinito e riempiendo tutti i campi. per poter variare l’ ordine di \ninserimento dei campi e lasciare in bianco il campo Prezzo (che abbiamo \nprecedentemente definito NULL e che quindi accetta valori nulli) si pu\u00f2 fare \ncos\u00ec: \n INSERT INTO Antichita (IDAcquirente, IDVenditore, Oggetto)<\/TT> \n VALUES (01, 21, ‘Ottomana’); \n \n<\/TT>Cancellare dati da una \ntabella<\/A><\/B>\nAdesso proviamo a cancellare la riga di dati che abbiamo appena inserito \ndalla tabella: \n DELETE FROM Antichita<\/TT> WHERE Oggetto = ‘Ottomana’;<\/TT> \n Ma, in questo caso, se c’e’ un’ altra riga che contiene nel campo Oggetto la \nparla “Ottomana” verr\u00e0 cancellata anch’essa. per cui siamo un po’ pi\u00f9 specifici \ne cancelliamo la riga specificando tutti i dati che abbiamo appena inserito: \n DELETE FROM Antichita<\/TT> WHERE Oggetto = ‘Ottomana’ AND \nIDAcquirente = 01 AND IDVenditore = 21;<\/TT> \n \n<\/TT>Modifica dei dati<\/A> <\/B>\nProviamo ad aggiornare il valore di un prezzo in un record dove questo non e’ \nstato inserito. ricordiamoci che in questo caso non si tratta di un inserimento \nma di una modifica del valore NULL precedentemente impostato in quel campo, in \nquanto il record e’ gi\u00e0 presente nella tabella: \n UPDATE Antichita SET Prezzo = 500000.00 WHERE Oggetto = ‘Sedia’;<\/TT> \n Questo comando imposta il prezzo di tutte le sedie a 500.000\u00a3 . anche in \nquesto caso possiamo fare riferimento alla sintassi della clausola WHERE del \ncomando SELECT per essere pi\u00f9 o meno specifici nella scelta dei record da \nmodificare. inoltre, esattamente come nel comando SELECT, si possono modificare \npi\u00f9 colonne con la stessa sintassi usata in questo comando per indicare pi\u00f9 \ncolonne (elenco diviso da virgole dopo la clausola SET) . \n \n\nGli Indici<\/A><\/FONT><\/I><\/B> \n Gli indici permettono ad un DBMS di accedere ai dati pi\u00f9 \nrapidamente (nota bene: questa funzionalit\u00e0 \u00e8 non-standard\/non disponibile su \ntutti i sistemi).Il sistema crea della strutture dati interne (gli indici) per \nla selezione pi\u00f9 veloce di determinate righe quando la selezione \u00e8 basata su \ncolonne indicizzate. La struttura indica al DBMS dove si trova una certa riga su \nuna tabella con colonne indicizzate, pi\u00f9 o meno come il glossario di un libro \nindica la pagina in cui appare una determinata parola. Creiamo un indice per \nIDAntiquario nella tabella ANTIQUARI<\/P>\n CREATE INDEX OID_IDX ON ANTIQUARI (IDAntiquari);<\/TT> \n Ora un indice sui nomi:<\/P>\n CREATE INDEX NAME_IDX ON ANTIQUARI (CognomeAntiquario, \nNomeAntiquario);<\/TT> \n Per eliminare un indice si usa l\u2019istruzione DROP:<\/P>\n DROP INDEX OID_IDX;<\/TT> \n In pi\u00f9, si pu\u00f2 usare l\u2019istruzione DROP TABLE per eliminare \nuna tabella (attenzione! Questo significa che la tua tabella viene cancellata). \nNel secondo esempio, l\u2019indice \u00e8 relativo a due colonne, aggregate insieme; in \nquesto caso, possono accadere strani comportamenti\u2026 consultare il manuale prima \ndi eseguire questa operazione.<\/P>Alcuni DBMS non richiedono l\u2019unicit\u00e0 della \nchiave primaria. In altre parole, se cercassi di inserire un\u2019altra riga nella \ntabella ANTIQUARI con un IDAntiquario = 2, alcuni sistemi mi lascerebbero fare \nquest\u2019operazione, anche se non \u00e8 consigliabile, in quanto si suppone che il \nvalore di questa colonna sia unico per ciascuna riga. Un modo per ovviare a \npossibili inconvenienti di questo genere \u00e8 di creare un indice unico sulla \ncolonna che noi vogliamo sia una chiave primaria, per forzare il sistema ad \nimpedire la duplicazione di valori in quella colonna: \n CREATE UNIQUE INDEX OID_IDX ON ANTIQUARI (IDAntiquario); \n \n<\/TT>GROUP BY ed \nHAVING<\/A><\/FONT><\/I><\/B> \nUn uso speciale dell\u2019istruzione GROUP BY \u00e8 di associare una funzione di \naggregazione (nella fattispecie COUNT; conta il numero di righe in ciascun \ngruppo) con dei gruppi di righe. Si assuma che la tabella ANTICHITA abbia la \ncolonna PREZZO e che ciascuna riga abbia un valore inserito in questa colonna. \nQuello che ci interessa \u00e8 di vedere il prezzo dell\u2019oggetto pi\u00f9 costoso comprato \nda ciascun acquirente. Si deve impartire via SQL l\u2019ordine di raggruppare<\/I> gli acquisti di ciascun \nacquirente, e di stampare il prezzo dell\u2019acquisto pi\u00f9 costoso:\n SELECT IDAcquirente, MAX(Prezzo)<\/TT> FROM ANTICHITA<\/TT> \n GROUP BY IDAcquirente;<\/TT> \n Ora, aggiungiamo l\u2019istruzione di stampare il prezzo massimo di acquisto se \nsupera i 100 dollari; in questo caso si usa l\u2019istruzione HAVING:<\/P>\n SELECT IDAcquirente, MAX(Prezzo)<\/TT> FROM ANTICHITA<\/TT> \n GROUP BY IDAcquirente<\/TT> HAVING Prezzo > 100; \n \n<\/TT>Altre \nSubquery<\/A><\/FONT><\/I><\/B> \nUn altro uso comune delle Queries coinvolge l\u2019uso di operatori per permettere \nad una condizione di WHERE di includere l\u2019output di una SELECT di una Query \nannidata. Dapprima, si mostri la lista degli acquirenti che hanno comprato un \noggetto dispendioso (ovvero con il prezzo dell\u2019articolo che superi di 100 \ndollari il prezzo medio di tutti gli oggetti comprati): \n SELECT IDAcquirente FROM ANTICHITA WHERE Prezzo \n><\/TT><\/P>\n (SELECT AVG(Prezzo) + \n100 FROM ANTICHITA);<\/TT><\/P>\n La query annidata fra parentesi calcola il prezzo medio, \nsomma 100, ed usando il risultato, si stampa un IDAcquirente per ciascun oggetto \nvenduto di prezzo superiore. Si pu\u00f2 usare DISTINCT IDAcquirente per visualizzare \nuna sola riga per ciascun IDAcquirente selezionato. <\/O:P><\/P>\n Stampa i Cognomi della tabella ANTIQUARI, solo se hanno \ncomprato un oggetto:<\/P>\n SELECT COGNOMEANTIQUARIO FROM ANTIQUARI WHERE \nIDAntiquario IN<\/TT><\/P>\n (SELECT \nDISTINCT IDAcquirente FROM \nANTICHITA);<\/TT><\/P>\n La query annidata (o sottoquery) seleziona una lista di \nacquirenti, e stampa il cognome di un Antiquario se e solo se il suo \nIDAntiquario appare nella lista selezionata dalla sottoquery (talvolta chiamata \nlista dei candidati<\/I>). Nota:<\/I> alcuni DBMS permettono di usare il \nsegno uguale (\u2018=\u2019) al posto di IN; per chiarezza, per\u00f2, si preferisce l\u2019uso di \nIN, in quanto la sottoquery non ritorna un valore singolo, bens\u00ec una lista.<\/P>\n Per un esempio relativo all’ UPDATE, sappiamo che il \ngentiluomo che ha acquistato la libreria ha il Nome sbagliato nel database, e \nche il nome corretto \u00e8 Giovanni:<\/P>\n UPDATE ANTIQUARI SET NOMEANTIQUARIO = \n‘Giovanni’ WHERE IDAntiquario =<\/TT><\/P>\n (SELECT \nIDAcquirente FROM \nANTICHITA WHERE OGGETTO = \n‘Libreria’);<\/TT><\/P>\n In primis<\/I>, \nla sottoquery cerca l\u2019IDAcquirente per la persona o le persone che hanno \nacquistato la libreria, in secundis<\/I> \nla query esterna aggiorna il Nome.<\/P>\n Regola delle \nsottoquery: <\/B>quando si ha una sottoquery come parte di una condizione di \nWHERE, l\u2019istruzione di SELECT deve avere un numero di colonne pari in numero e \ntipo a quelle contenute nella condizione di WHERE della query esterna. In altre \nparole, se si ha \u201cWHERE NomeColonna = \n(SELECT\u2026.);\u201d <\/SPAN>l\u2019istruzione di Select deve avere solo una colonna, per \ntrovare una corrispondenza con il NomeColonna della condizione di Where esterna; \nin pi\u00f9, il tipo<\/I> deve essere il \nmedesimo (due interi, due stringhe di caratteri, etc..).<\/P>\n \nEXISTS ed ALL<\/A><\/FONT><\/I><\/B> \nEXISTS usa una sottoquery come condizione: la condizione \u00e8 \nVera se la sottoquery ritorna almeno una riga, ed \u00e8 Falsa se la sottoquery non \nritorna nessuna riga. Questa \u00e8 una funzionalit\u00e0 non intuitiva con quest\u2019uso \nspecifico. Comunque, se si vuole stampare un riassuntivo clienti solo se il \nnegozio ha venduto Sedie, si pu\u00f2 scrivere: <\/O:P><\/SPAN><\/P>\n SELECT NomeAcquirente, CognomeAcquirente FROM ANTIQUARI WHERE \nEXISTS<\/TT><\/P>\n (SELECT \n* FROM \nANTICHITA WHERE Oggetto = \n‘Sedia’);<\/TT><\/P>\n Se nella colonna della tabella ANTICHITA c\u2019\u00e8 almeno una riga \ncontenente l\u2019articolo sedia, la sottoquery ritorna una o pi\u00f9 righe, rendendo \nVera la condizione EXISTS; di conseguenza la query stampa gli Antiquari. Se non \nci sono righe con l\u2019oggetto Sedia, la query esterna non <\/SPAN>stamper\u00e0 alcuna riga.<\/P>\n ALL \u00e8 un\u2019altra funzionalit\u00e0 inusuale, in quanto la \nquery che contengono l\u2019istruzione ALL possono essere eseguite in altri modi, a \nvolte anche pi\u00f9 semplici; diamo un\u2019occhiata alla query di esempio:<\/P>\n SELECT IDAcquirente, Oggetto FROM ANTICHITA WHERE Prezzo >= \nALL<\/TT><\/P>\n (SELECT \nPrezzo FROM ANTICHITA);<\/TT><\/P>\n <\/TT>Questa query ritorna l\u2019oggetto con il prezzo pi\u00f9 alto (o pi\u00f9 \ndi un oggetto se hanno un prezzo uguale e massimo), e l\u2019Acquirente. La \nsottoquery ritorna una lista di tutti i prezzi nella tabella ANTICHITA, mentre \nla query esterna passa tutte le righe della tabella ANTICHITA, e se il prezzo \u00e8 \nmaggiore o uguale di qualunque altro oggetto (ALL = tutti), viene stampato, \nrisultando cos\u00ec l\u2019oggetto con il prezzo pi\u00f9 alto. La ragione per cui viene usato \nil segno di \u201cmaggiore o uguale\u201d \u00e8 che il prezzo dell\u2019oggetto pi\u00f9 costoso sar\u00e0 \nuguale al prezzo pi\u00f9 alto della tabella.<\/P>\n \nUNION ed Outer Joins<\/A> \n(rapida spiegazione non esaustiva)<\/FONT><\/I><\/B> \nSi possono presentare casi in cui si voglia vedere il \nrisultato di diverse query insieme, combinando il loro output; in questi casi si \nusa l\u2019espressione UNION. Per unire l\u2019output delle due query seguenti, stampando \ntutti gli IDAcquirente, insieme con tutti quelli che hanno mandato un ordine, si \nesegua:<\/P>\n SELECT IDAcquirente FROM ANTICHITA UNION SELECT \nIDAntiquario FROM ORDINI; <\/TT><\/O:P><\/SPAN><\/P>\n <\/SPAN>Si noti che SQL richiede che la \nlista di colonne di entrambe le Select siano uguali per tipo, colonna per \ncolonna. In questo caso IDAcquirente ed IDAntiquario sono dello stesso tipo \n(Interi [integer]). Si noti inoltre che SQL elimina automaticamente le righe \nduplicate usando UNION (come fossero due set di dati); per le query singole si \ndeve usare DISTINCT.<\/P>\n L\u2019outer join<\/I>, \n(join esterno) si usa quando una join fra tabelle viene \u201cunita\u201d con le righe non \nincluse nella condizione di join; questo risulta particolarmente utile se nella \nquery sono contenute delle costanti di tipo testo. Per esempio:<\/P>\n SELECT IDAntiquario, ‘presente in Ordini ed \nAntichita’ FROM ORDINI, ANTICHITA WHERE IDAntiquario = \nIDAcquirente UNION SELECT IDAcquirente, ‘presente solo in \nAntichita’ FROM ANTICHITA WHERE IDAcquirente NOT \nIN <\/TT> (SELECT \nIDAntiquario FROM ORDINI); \n<\/TT><\/O:P><\/SPAN><\/P>\n <\/SPAN>La prima query fa una join per \nstampare tutti gli Antiquari in entrambe le tabelle, e per aggiungere un breve \ncommento dopo ciascun ID. La UNION combina questa lista con la successiva, che \nviene generata anzi tutto richiamando gli ID non presenti nella tabella ORDINI, \ninfine stampando gli ID esclusi dalla condizione di join. Quindi, ciascuna riga \nnella tabella ANTICHITA viene esaminata, e se l\u2019IDAcquirente non \u00e8 nella lista \ndi esclusione, viene stampato con il commento fra apici. Ci possono essere modi \npi\u00f9 semplici per generare la stessa lista di ID, ma attaccare a ciascuna riga un \ncommento fisso appropriato \u00e8 ben pi\u00f9 complesso se fatto in altri modi.<\/P>\n Questo concetto \u00e8 utile in situazioni in cui una chiave \nprimaria viene messa in condizione di join con una chiave secondaria, ma la \nchiave secondaria pu\u00f2 essere NULL per alcune chiavi primarie. Ad esempio, in una \ntabella la chiave primaria \u00e8 il venditore e in un\u2019altra \u00e8 il cliente, con il \nvenditore riportato nella stessa riga. Se un venditore non ha clienti, il suo \nnome non appare nella tabella dei clienti. L\u2019outer join<\/B> si usa allora per ottenere \nla lista di tutti<\/B> i venditori, \ninsieme con i loro clienti, sia nel caso in cui il venditore abbia clienti sia \nnel caso in cui non ne abbia, cio\u00e8 non venga stampato il nome del cliente (un \nvalore di NULL logico) se il venditore non ha clienti, ma \u00e8 nella tabella dei \nvenditori. In caso contrario, il venditore sar\u00e0 stampato insieme con ognuno dei \nsuoi clienti.<\/P>\n Un altro punto importante riguardo ai NULL nelle condizioni \ndi join: l\u2019ordine delle tabelle nella lista successiva all\u2019istruzione FROM \u00e8 \nmolto importante. La regola \u00e8 che SQL aggiunge la seconda tabella alla prima; se \nla prima tabella presenta solo righe contenenti NULL nella colonna di join, e la \nseconda tabella ha una riga con NULL nella colonna di join, tale riga non \nrisulta nella condizione di join, e pertanto deve venire inclusa con i dati di \nriga della prima tabella. Questa \u00e8 un altro esempio in cui comunemente viene \nimpiegato un outer join. Il concetto di NULL \u00e8 importante, e pu\u00f2 essere proficuo \ninvestigarlo in maniera pi\u00f9 approfondita.<\/P>BASTA QUERY!!! O non ne avete \nancora avuto abbastanza? \u2026 adesso si passa a qualcosa del tutto differente\u2026 \n \nSommario della \nSintassi – Solo per veri masochisti<\/A><\/FONT><\/B>\nQui potete trovare le forme generalizzate dei comandi discussi in questi \nappunti, pi\u00f9 alcuni aggiuntivi che possono risultare comodi e la cui spiegazione \ne’ data a latere. ATTENZIONE!!!<\/U><\/B> non e’ detto che tutti questi \ncomandi siano esattamente in questa forma, controllate sul vostro sistema per \navere la certezza del loro funzionamento e della loro disponibilit\u00e0:\n ALTER TABLE<\/B> <Nome Tabella> ADD|DROP|MODIFY (Specifiche \nColonna[e]…vedere Create Table);<\/TT> <\/B>–vi permette di aggiungere o \ncancellare una o pi\u00f9 colonne da una tabella, o di cambiare i parametri di una \ncolonna esistente (tipi di dato ecc..); questo comando e’ utilizzato spesso \nanche per cambiare le specifiche fisiche di una tabella (dove e come viene \nsalvata ecc.), ma in questo caso dipende direttamente dal DBMS che state usando, \nquindi vi rimando ai manuali del vostro database. Oltre che con questo comando \nle specifiche fisiche della tabella possono venire generalmente date all’ \ninterno del comando Create Table quando una tabella viene creata per la prima \nvolta.\n Begin Transaction; <\/TT><\/B>inizia a considerare i comandi seguenti \ncome facenti parte di un’ unico blocco (transazione) che vanno eseguiti in un \nblocco unico al raggiungimento di una istruzione di commit o scartati tutti \ninsieme al raggiungimento di una istruzione rollback\n COMMIT<\/TT>;<\/B> effettua i cambiamenti fatti sul database dall’ \nultima istruzione Begin Transaction (in alcuni DBMS dall’ ultima commit) e li \nrende permanenti — questo blocco di istruzioni viene definito una Transazione \n CREATE [UNIQUE] INDEX<\/TT> <\/B><Nome Indice><\/TT> ON \n<Nome Tabella> (<Lista Colonne>); <\/TT>— UNIQUE e’ opzionale e va \nusato senza parentesi quadre.\n CREATE TABLE<\/TT> <\/B><Nome Tabella><\/TT> (<Nome \nColonna> <Tipo di Dato> [(<Dimensione>)] <Limitazioni sulle \ncolonne>,<\/TT> …altre colonne[PRIMARY KEY (colonna, colonna,…)]); \n(<\/TT>sintassi valida anche per ALTER TABLE) –dove Dimensione viene usato \nsolo su alcuni tipi di dato, e le limitazioni includono quelle qui sotto \nriportate (controllate automaticamente dal dbms. una tentata violazione causa la \ngenerazione di un errore): \n\n NULL o NOT NULL (vedi sotto) \n UNIQUE obbliga a non avere due valori uguali all’ interno della colonna \n PRIMARY KEY dice al database che questa colonna e’ la chiave primaria \n della tabella (utilizzato solo se la chiave primaria e’ composta da una sola \n colonna, altrimenti una clausola PRIMARY KEY (colonna, colonna, …) \n comparir\u00e0 dopo l’ultima definizione di colonna. \n CHECK permette ad una condizione di essere testata quando i dati vengono \n inseriti o aggiornati in una determinata colonna; per esempio, CHECK (Prezzo \n >= 0) impone al sistema di controllare che il prezzo sia maggiore o uguale \n a zero prima di accettare il valore; a volte viene implementato con \n l\u2019istruzione CONSTRAINT. \n DEFAULT inserisce il valore nel database per una determinata colonna se \n una riga viene inserita senza un valore per la colonna stessa; per \n esempio, \n <\/SPAN>BENEFITS \n INTEGER DEFAULT = 10000<\/SPAN> \n FOREIGN KEY funziona esattamente come l\u2019istruzione Primary Key, ma \u00e8 \n seguita da: REFERENCES <Nome Tabella> (<Nome Colonna>)<\/TT>, \n che riferisce la chiave riferita ad una chiave primaria. <\/LI><\/OL>CREATE \nVIEW<\/TT> <\/B><Nome Tabella> AS <Query>;<\/TT> \nDELETE<\/TT> <\/B>FROM <Nome Tabella> WHERE \n<Condizione>;<\/TT> \n INSERT<\/TT> <\/B>INTO <Nome Tabella> [(<Lista \nColonne>)]<\/TT> VALUES (<Lista Valori>);<\/TT> \n ROLLBACK<\/TT>; <\/B>— Annulla le modifiche effettuare al database che \nsono state effettuate dopo l’ ultimo comando COMMIT. ATTENZIONE! vedere il \nfunzionamento delle istruzioni COMMIT, ROLLBACK e BEGIN TRANSACTION sui propri \nRDBMS particolari in quanto il funzionamento di tali comandi varia moltissimo da \nun sistema all’ altro\n SELECT<\/B> [DISTINCT|ALL] <Lista Colonne, Funzioni, Costanti, \necc.><\/TT> FROM <Lista di tabelle o di viste><\/TT> [WHERE \n<Condizione\/i>]<\/TT> [GROUP BY <raggruppamento \ncolonna\/e>]<\/TT> [HAVING <condizione>]<\/TT> [ORDER BY \n<colonna\/e di ordinamento> [ASC|DESC]]; <\/TT>–dove ASC|DESC permettono di \nfare in modo che l’ ordinamento venga effettuato in ordine ascendente (ASC) o \ndiscendente (DESC)\n UPDATE<\/TT> <\/B><Nome Tabella><\/TT> SET <Nome \nColonna> = <Valore><\/TT> [WHERE <Condizione>]; <\/TT>— se \nla clausola Where non e’ specificata vengono aggiornate tutte le righe come \nspecificate nella clausola SET \n \n\nSommario dei \nLink relativi all’ SQL <\/A><\/FONT><\/B><\/H1>\nSQL Reference \nPage<\/A> Programmer’s \nSource<\/A> DevX<\/A> DB Ingredients<\/A> SQL Trainer S\/W<\/A> Web Authoring<\/A> DBMS Lab\/Links<\/A> SQL \nFAQ<\/A> Query List<\/A> SQL Practice Site<\/A> SQL Course II<\/A> Database Jump Site<\/A> Programming Tutorials on the \nWeb<\/A> PostgreSQL<\/A> Adobe \nAcrobat<\/A> A Good DB \nCourse<\/A> Tutorial \nPage<\/A> Intelligent \nEnterprise Magazine<\/A> miniSQL<\/A> SQL for DB2 Book<\/A> SQL Server \n7<\/A> SQL \nReference\/Examples<\/A> SQL \nTopics<\/A> Lee’s SQL Tutorial<\/A> Data Warehousing Homepage<\/A> MIT SQL for Web \nNerds<\/A> RDBMS \nServer Feature Comparison Matrix<\/A> Oracle FAQ<\/A> Oracle Developer \n(2000)<\/A> Intro to Relational \nDatabase Design<\/A> SQL Sam, the SQL Server \nDetective<\/A> ZDNet’s \nSQL Introduction<\/A> Baycon \nGroup’s SQL Tutorial<\/A> Dragonlee’s SQL Tutorial<\/A> A good, but anonymous SQL \nTutorial<\/A> UC \nDavis’ Oracle PDF’s<\/A> About.com’s \nDatabase Advisor<\/A> Manas \nTungare’s SQL Tutorial at FindTutorials.com<\/A> A Gentle Introduction to \nSQL<\/A> SQL (News) Wire<\/A> \n vi consiglio vivamente di andare a visitare i link qui sopra riportati , \nspecialmente se volete approfondire gli argomenti qui trattati ed in particolare \ncose come lo standard SQL-92. ricordatevi comunque che se state utilizzando un \ndatabase commerciale ben conosciuto (come Oracle, SQLServer ecc) normalmente il \nposto migliore dove trovare informazioni e’ normalmente il sito web del \nproduttore del vostro DBMS \n \n<\/BODY>\n","protected":false},"excerpt":{"rendered":"una serie di note da me utilizzate per tenere un corso all’ ERLUG su SQL e sui database relazionali, con un focus sull’ANSI SQL<\/p>\n","protected":false},"author":1,"featured_media":44,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[12,9,11],"class_list":["post-1","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-informatica","tag-ansi-sql","tag-database","tag-database-relazionali"],"yoast_head":"\nAppunti sui database relazionali e sul linguaggio SQL - Suffritti.it<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.suffritti.it\/?p=1\" \/>\n<meta property=\"og:locale\" content=\"it_IT\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Appunti sui database relazionali e sul linguaggio SQL - Suffritti.it\" \/>\n<meta property=\"og:description\" content=\"una serie di note da me utilizzate per tenere un corso all' ERLUG su SQL e sui database relazionali, con un focus sull'ANSI SQL\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.suffritti.it\/?p=1\" \/>\n<meta property=\"og:site_name\" content=\"Suffritti.it\" \/>\n<meta property=\"article:published_time\" content=\"2023-04-11T16:18:58+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-04-11T17:19:57+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.suffritti.it\/wp-content\/uploads\/2023\/04\/database-schema-1895779_960_720.png\" \/>\n\t<meta property=\"og:image:width\" content=\"824\" \/>\n\t<meta property=\"og:image:height\" content=\"720\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Pietro Suffritti\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Scritto da\" \/>\n\t<meta name=\"twitter:data1\" content=\"Pietro Suffritti\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tempo di lettura stimato\" \/>\n\t<meta name=\"twitter:data2\" content=\"56 minuti\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/?p=1#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/?p=1\"},\"author\":{\"name\":\"Pietro Suffritti\",\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/#\\\/schema\\\/person\\\/7d2b80cf72d9701c47de6ad671953fce\"},\"headline\":\"Appunti sui database relazionali e sul linguaggio SQL\",\"datePublished\":\"2023-04-11T16:18:58+00:00\",\"dateModified\":\"2023-04-11T17:19:57+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/?p=1\"},\"wordCount\":10419,\"publisher\":{\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/#\\\/schema\\\/person\\\/7d2b80cf72d9701c47de6ad671953fce\"},\"image\":{\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/?p=1#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.suffritti.it\\\/wp-content\\\/uploads\\\/2023\\\/04\\\/database-schema-1895779_960_720.png\",\"keywords\":[\"ansi sql\",\"database\",\"database relazionali\"],\"articleSection\":[\"Informatica\"],\"inLanguage\":\"it-IT\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/?p=1\",\"url\":\"https:\\\/\\\/www.suffritti.it\\\/?p=1\",\"name\":\"Appunti sui database relazionali e sul linguaggio SQL - Suffritti.it\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/?p=1#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/?p=1#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.suffritti.it\\\/wp-content\\\/uploads\\\/2023\\\/04\\\/database-schema-1895779_960_720.png\",\"datePublished\":\"2023-04-11T16:18:58+00:00\",\"dateModified\":\"2023-04-11T17:19:57+00:00\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/?p=1#breadcrumb\"},\"inLanguage\":\"it-IT\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.suffritti.it\\\/?p=1\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"it-IT\",\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/?p=1#primaryimage\",\"url\":\"https:\\\/\\\/www.suffritti.it\\\/wp-content\\\/uploads\\\/2023\\\/04\\\/database-schema-1895779_960_720.png\",\"contentUrl\":\"https:\\\/\\\/www.suffritti.it\\\/wp-content\\\/uploads\\\/2023\\\/04\\\/database-schema-1895779_960_720.png\",\"width\":824,\"height\":720},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/?p=1#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.suffritti.it\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Appunti sui database relazionali e sul linguaggio SQL\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/#website\",\"url\":\"https:\\\/\\\/www.suffritti.it\\\/\",\"name\":\"Suffritti.it\",\"description\":\"la nostra web-casa\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/#\\\/schema\\\/person\\\/7d2b80cf72d9701c47de6ad671953fce\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.suffritti.it\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"it-IT\"},{\"@type\":[\"Person\",\"Organization\"],\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/#\\\/schema\\\/person\\\/7d2b80cf72d9701c47de6ad671953fce\",\"name\":\"Pietro Suffritti\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"it-IT\",\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/wp-content\\\/uploads\\\/2023\\\/04\\\/PietroSamuraiSmall.png\",\"url\":\"https:\\\/\\\/www.suffritti.it\\\/wp-content\\\/uploads\\\/2023\\\/04\\\/PietroSamuraiSmall.png\",\"contentUrl\":\"https:\\\/\\\/www.suffritti.it\\\/wp-content\\\/uploads\\\/2023\\\/04\\\/PietroSamuraiSmall.png\",\"width\":500,\"height\":500,\"caption\":\"Pietro Suffritti\"},\"logo\":{\"@id\":\"https:\\\/\\\/www.suffritti.it\\\/wp-content\\\/uploads\\\/2023\\\/04\\\/PietroSamuraiSmall.png\"},\"sameAs\":[\"https:\\\/\\\/www.suffritti.it\"],\"url\":\"https:\\\/\\\/www.suffritti.it\\\/?author=1\"}]}<\/script>\n","yoast_head_json":{"title":"Appunti sui database relazionali e sul linguaggio SQL - Suffritti.it","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.suffritti.it\/?p=1","og_locale":"it_IT","og_type":"article","og_title":"Appunti sui database relazionali e sul linguaggio SQL - Suffritti.it","og_description":"una serie di note da me utilizzate per tenere un corso all' ERLUG su SQL e sui database relazionali, con un focus sull'ANSI SQL","og_url":"https:\/\/www.suffritti.it\/?p=1","og_site_name":"Suffritti.it","article_published_time":"2023-04-11T16:18:58+00:00","article_modified_time":"2023-04-11T17:19:57+00:00","og_image":[{"width":824,"height":720,"url":"https:\/\/www.suffritti.it\/wp-content\/uploads\/2023\/04\/database-schema-1895779_960_720.png","type":"image\/png"}],"author":"Pietro Suffritti","twitter_card":"summary_large_image","twitter_misc":{"Scritto da":"Pietro Suffritti","Tempo di lettura stimato":"56 minuti"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.suffritti.it\/?p=1#article","isPartOf":{"@id":"https:\/\/www.suffritti.it\/?p=1"},"author":{"name":"Pietro Suffritti","@id":"https:\/\/www.suffritti.it\/#\/schema\/person\/7d2b80cf72d9701c47de6ad671953fce"},"headline":"Appunti sui database relazionali e sul linguaggio SQL","datePublished":"2023-04-11T16:18:58+00:00","dateModified":"2023-04-11T17:19:57+00:00","mainEntityOfPage":{"@id":"https:\/\/www.suffritti.it\/?p=1"},"wordCount":10419,"publisher":{"@id":"https:\/\/www.suffritti.it\/#\/schema\/person\/7d2b80cf72d9701c47de6ad671953fce"},"image":{"@id":"https:\/\/www.suffritti.it\/?p=1#primaryimage"},"thumbnailUrl":"https:\/\/www.suffritti.it\/wp-content\/uploads\/2023\/04\/database-schema-1895779_960_720.png","keywords":["ansi sql","database","database relazionali"],"articleSection":["Informatica"],"inLanguage":"it-IT"},{"@type":"WebPage","@id":"https:\/\/www.suffritti.it\/?p=1","url":"https:\/\/www.suffritti.it\/?p=1","name":"Appunti sui database relazionali e sul linguaggio SQL - Suffritti.it","isPartOf":{"@id":"https:\/\/www.suffritti.it\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.suffritti.it\/?p=1#primaryimage"},"image":{"@id":"https:\/\/www.suffritti.it\/?p=1#primaryimage"},"thumbnailUrl":"https:\/\/www.suffritti.it\/wp-content\/uploads\/2023\/04\/database-schema-1895779_960_720.png","datePublished":"2023-04-11T16:18:58+00:00","dateModified":"2023-04-11T17:19:57+00:00","breadcrumb":{"@id":"https:\/\/www.suffritti.it\/?p=1#breadcrumb"},"inLanguage":"it-IT","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.suffritti.it\/?p=1"]}]},{"@type":"ImageObject","inLanguage":"it-IT","@id":"https:\/\/www.suffritti.it\/?p=1#primaryimage","url":"https:\/\/www.suffritti.it\/wp-content\/uploads\/2023\/04\/database-schema-1895779_960_720.png","contentUrl":"https:\/\/www.suffritti.it\/wp-content\/uploads\/2023\/04\/database-schema-1895779_960_720.png","width":824,"height":720},{"@type":"BreadcrumbList","@id":"https:\/\/www.suffritti.it\/?p=1#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.suffritti.it\/"},{"@type":"ListItem","position":2,"name":"Appunti sui database relazionali e sul linguaggio SQL"}]},{"@type":"WebSite","@id":"https:\/\/www.suffritti.it\/#website","url":"https:\/\/www.suffritti.it\/","name":"Suffritti.it","description":"la nostra web-casa","publisher":{"@id":"https:\/\/www.suffritti.it\/#\/schema\/person\/7d2b80cf72d9701c47de6ad671953fce"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.suffritti.it\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"it-IT"},{"@type":["Person","Organization"],"@id":"https:\/\/www.suffritti.it\/#\/schema\/person\/7d2b80cf72d9701c47de6ad671953fce","name":"Pietro Suffritti","image":{"@type":"ImageObject","inLanguage":"it-IT","@id":"https:\/\/www.suffritti.it\/wp-content\/uploads\/2023\/04\/PietroSamuraiSmall.png","url":"https:\/\/www.suffritti.it\/wp-content\/uploads\/2023\/04\/PietroSamuraiSmall.png","contentUrl":"https:\/\/www.suffritti.it\/wp-content\/uploads\/2023\/04\/PietroSamuraiSmall.png","width":500,"height":500,"caption":"Pietro Suffritti"},"logo":{"@id":"https:\/\/www.suffritti.it\/wp-content\/uploads\/2023\/04\/PietroSamuraiSmall.png"},"sameAs":["https:\/\/www.suffritti.it"],"url":"https:\/\/www.suffritti.it\/?author=1"}]}},"_links":{"self":[{"href":"https:\/\/www.suffritti.it\/index.php?rest_route=\/wp\/v2\/posts\/1","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.suffritti.it\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.suffritti.it\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.suffritti.it\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.suffritti.it\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1"}],"version-history":[{"count":2,"href":"https:\/\/www.suffritti.it\/index.php?rest_route=\/wp\/v2\/posts\/1\/revisions"}],"predecessor-version":[{"id":16,"href":"https:\/\/www.suffritti.it\/index.php?rest_route=\/wp\/v2\/posts\/1\/revisions\/16"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.suffritti.it\/index.php?rest_route=\/wp\/v2\/media\/44"}],"wp:attachment":[{"href":"https:\/\/www.suffritti.it\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.suffritti.it\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.suffritti.it\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}