Basi di Dati Relazionali Dario Colazzo Università di Pisa Dipartimento di Informatica Corso Italia, 40 Pisa, 56125 email: colazzo@di.unipi.it telefono: +39 050 887265

hh hhh Cos’è un database Un databse (relazionale) e’ l’insieme degli strumenti per memorizzare e manipolare dati in modo “efficiente ed efficacie” allo scopo do ottenere informazioni utili in un preciso contesto. Il concetto di dato e’ diverso dal concetto di informazione Fino a 30 anni fa, i database venivano creati dal nulla (sistemi di archiviazione) Oggi abbiamo i sistemi di gestione di basi di dati o DBMS (data base management system). Basi di dati Dario Colazzo hh

hh hhh Database relazionali In questo corso ci occuperemo dei database piu’ comunemente utilizzati: i database relazionali. I sistemi di gestione di basi di dati relazionali vengono chiamati RSGBD. dire essenzialmente cosa è, altri modelli per basi di dati Basi di dati Dario Colazzo hh

Terminologia dei database relazionali hh hhh Terminologia dei database relazionali Un database relazionale modella alcuni aspetti del mondo reale. La parte del mondo reale modellata e’ detta spazio del problema La definizione piu’ precisa e rigorosa dello spazio del problema, é detto modello dei dati La definizione del modello dei dati con tutti i meccanismi che il SGBD mette a disposizione è chiamato schema di database. spazio del problema: è soprattutto usato dai progettisti di basi di dati) Basi di dati Dario Colazzo hh

Motore di database Quando realizziamo un database, ci fermiamo all schema del database. L’effettiva implementazione è poi affidata al motore di database Si occupa della effettiva memorizzazione dei dati, dei loro legami, di strutture per aumentare l’efficienza del recupero dei dati. Importante: non include l’applicazione Basi di dati Dario Colazzo

hh hhh Sistema di database Applicazioni: maschere e report utilizzati dalgi utenti Motore di database: non fa parte del database Database: implementazione fisica dello schema e dei dati Schema di database database: strutture + dati motore: insieme di moduli schema di database Modello dei dati Spazio del problema Basi di dati Dario Colazzo hh

Il modello relazionale (E. F. Codd, IBM) Si basa su un insieme di principi matematici, introdotti per la memorizzazione e manipolazione di dati. Importante: il modello indica solo come i dati devono essere concettualmente rappresentati e quali siano le operazioni. Come abbiamo gia visto, l’effettiva realizzazione fisica è a carico del motore di database. Basi di dati Dario Colazzo

hh hhh Aspetti principali Ogni sistema di database relazionale presenta le seguenti caratteristiche: I dati sono concettualmente rappresentati attraverso relazioni; spesso una relazione è chiamata tabella. Ogni valore in corrispondenza di una riga/colonna di una relazione è uno scalare; in particolare una relazione non può contenere altre relazioni. Ogni operazione ha come input relazioni e restituisce sempre una relazione (chiusura). disegni per chiarire dichiaratività delle operazioni Basi di dati Dario Colazzo hh

Terminologia relazionale: i componenti di una relazione. attributi intestazione corpo tupla Basi di dati Dario Colazzo

hh hhh Osservazioni E’ possibile avere relazioni che non corrispondono a nessuna realizzazione fisica effettiva, ma sono definite estraendo dati da altre relazioni (viste o views). Il principio della chiusura è molto importante. Grazie ad esso si possono comporre le operazioni: i risultati di una operazione possono essere utilizzati come input per un’altra operazione. views per limitare l’accesso chiarire chiusura, paragone con routine.... ecc Basi di dati Dario Colazzo hh

Valori scalari Un valore è scalare se non è composto da altri valori. Attenzione, il fatto che un valore sia scalare o meno è soggettivo, in effetti dipende dal significato e dal ruolo che deve assumere nello spazio del problema. Esempio: ci possono essere realtà modellate da database in cui il valore “Nome” di una persona può essere rappresentato con una sola stringa (“Mario Rossi”) In altre invece può essere necessario scomporlo in due valori, “Nome” e “Cognome” (in questo caso avremo “Mario” e “Rossi”). Torneremo su questo aspetto quando parleremo di attributi. Basi di dati Dario Colazzo

Relazioni: cardinalità, grado,…. La cardinalità di una relazione è data dal numero delle tuple che la compongono. Il numero di attributi di ogni tupla determina il grado della relazione. Ogni relazione, contiene un insieme non ordinato di tuple; in altre parole, due relazioni che differiscono solo per l’ordine delle tuple, sono la stessa relazione. In particolare, non si possono fare interrogazioni del tipo: “visualizza il prima tupla il cui campo “FirstName” è diverso dal valore ‘Russel’. Basi di dati Dario Colazzo

hh hhh Modello dei dati 1/2 Abbiamo visto che i database modellano una porzione della realtà detta spazio del problema. Sarebbe improponibile partire dallo spazio del problema e arrivare direttamente all definizione dello schema di database. Esiste un passo intermedio, la costruzione del modello dei dati. Attraverso il modello dei dati, traduciamo lo spazio del problema in termini di entità, attributi, domini e associazioni. importante:necessità del modello dei dati Basi di dati Dario Colazzo hh

Modello dei dati 2/2 La visione del mondo reale di interesse in termini di entità, attributi, domini e associazioni, permette di dare una prima impostazione logica e precisa della realtà da trattare, senza preoccuparsi della definizione dello schema. La corrispondenza tra modello dei dati e schema è abbastanza naturale. Basi di dati Dario Colazzo

Entità In prima istanza, possiamo dire che un’entità è qualunque fenomeno, concreto o astratto, presente nello spazio del problema di cui ci interessa memorizzare i relativi dati. Esempi: ‘Clienti’, ‘Impiegati’, ‘Libri’,… (concrete) Ma anche: ‘Acquisto’, ‘Accredito’,…. (astratte) Basi di dati Dario Colazzo

Entità Osservazione: individuare le entità di interesse non è sempre immediato. Ad esempio, l’acquisto di un prodotto non costituisce necessariamente una entità a se. Potrebbe rappresentare due eventi distinti: l`acquisto da parte di un cliente e la vendita da parte di un venditore Basi di dati Dario Colazzo

hh hhh Sottotipi Supponiamo che tra le entità rilevate abbiamo Persona, rappresentata da tutte le informazioni sulle generalità di una persona. Inoltre abbiamo anche Impiegato e Dirigente (generalità + dati specifici) In effetti abbiamo che ogni Impiegato o Dirigente è anche una Persona. In questo caso si dice che sia Impiegato che Dirigenti sono entità sottotipo di Persona. E’ necessario tenere conto delle relazioni di sottotipo tra entità per definire uno schema più semplice, coerente con la realtà ed efficiente. dire che la nozione di sottotipo non è proprio del modello relazionale, ma può essere modellato Basi di dati Dario Colazzo hh

Attributi Ogni dato di una entita che ci interessa rappresentare nel database e un attributo dell’entità. Se nel database abbiamo l’entità Cliente, sicuramente ci interesserà memorizzare il nome e indirizzo: questi sono due attributi dell’entità cliente. Stabilire ciò che può essere considerato un attributo di un’entità è un processo semantico: gli attributi vanno determinati in base al significato dei dati e del loro uso. Basi di dati Dario Colazzo

Determinare gli attributi 1/6 Principio generale: ridurre gli attributi a valori non ulteriormente scomponibili. Esempio, l’ attributo Indirizzo andrebbe suddiviso in Via, Città, Codice, Stato. L’idea che è alla base di questo principio è che i dati strutturati sono più semplici da manipolare. Ad esempio, in questo modo posso fare interrogazioni in base al valore dell’attributo Stato. Se considerassi un unico attributo Indirizzo, questo richiederebbe la scrittura di codice appropriato per l’estrazione della componente Stato. Basi di dati Dario Colazzo

Determinare gli attributi 2/6 2/6 hh hhh Determinare gli attributi 2/6 2/6 Non sempre la cosa milgiore e’ seguire il criterio generale. Esempio di un caso: società di vendita per corrispondenza via Internet. Per motivi fiscali, questa società deve far riferimento allo stato nei quali risiedono i clienti. Si potrebbe allora pensare ad una suddivisione Via, Città, Codice, Stato. Cosa accade quando la società ha a che fare con clienti il cui indirizzo non rispetta questa suddivisione? più struttura, più rigidità Basi di dati Dario Colazzo hh

Determinare gli attributi 3/6 hh hhh Determinare gli attributi 3/6 Si pensi ad esempio ad un indirizzo di un cliente del tipo: 4/32 Grifen Avenue, Bondi Beach, Australia. Molto probabilmente vi saranno utenti del database che non sanno che 4/32 significa Appartamento 4, Numero civico 32. Dal momento che l’unica esigenza dell’azienda segnalata è conoscere lo stato, un buon compromesso è dividere Indirizzo in Stato+(parte restante: Via,…ecc) Ricordare che i costi di cambiamento di schema sono proibitivi. perchè cambiare lo schema è hard Basi di dati Dario Colazzo hh

Determinare gli attributi 4/6 Come gia detto, la scelta dipende dal significato dei dati e dall’uso che se ne farà. E’ importante: tenere presente il risultato finale e non rendere il progetto più complesso del necessario. Se ad esempio l’unico utilizzo che si farà degli indirizzi e quello di indirizzo di spedizione, allora la cosa migliore è un unico attributo Indirizzo. Ricordare: rendere il modello meno complesso possibile, allegerisce molto le applicazioni (poche eccezioni) e il lavoro degli utenti (che non si trovano di fronte maschere di immissione dati con molti campi separati da riempire). Basi di dati Dario Colazzo

Determinare gli attributi 5/6 hh hhh Determinare gli attributi 5/6 Un altro aspetto da considerare è quello di fare uno studio su possibili future esigenze. Ad esempio, potrebbe essere molto probabile che una società voglia ordinare gli indirizzi per codice postale per poter gestire sconti sulle tariffe postali. In questo caso, anche se l’esigenza non è rilevata nel momento dell’analisi dello spazio del problema, è bene prevedere un attributo a parte CodicePostale. Le vere esigenze a cui il database deve risponde-re non sono solo quelle che l’organizzazione vi chiede. Un buon modello dipende anche dalla vostra accuratezza e creatività. Ce ne sono sempre altre che sarebbero state chieste se solo chi necessita della base di dati sapesse che si può realizzare. Basi di dati Dario Colazzo hh

Determinare gli attributi 6/6 Un altro aspetto importante è quello della distinzione tra attributo o entità. Ad esempio, nulla vieta di vedere gli indirizzi come entita a sé, e raggruppare tutti gli indirizzi di un sistema in una unica relazione. Questo potrebbe essere accettabile solo quando l’uso di tutti gli indirizzi e pressoché il medesimo. E’ difficile, ad esempio, che in una società gli indirizzi dei clienti abbiano lo stesso utilizzo e formattazione degli indirizzi degli impiegati. Basi di dati Dario Colazzo

hh hhh Domini Il dominio di un attributo specifica l`insieme dei valori che l`attributo può validamente contenere. I domini non vanno confusi con i tipi di dato, in genere messi a disposizione dai linguaggi di programmazione (VB, Java, C++,…) I tipi definiscono insiemi di valori come ad esempio l’insieme di tutte le stringe, degli interi…ecc. sottolineare tipo diverso da dominio Basi di dati Dario Colazzo hh

hh hhh Tipi e domini 1/2 I tipi sono al livello della realtà fisica di un database. I domini invece sono al livello del modello dei dati, e quindi ad un livello concettuale. Se consideriamo ad esempio il dominio di NomeProvincia, i possibili valori del dominio non è dato dal tipo text{20}, ma dall`insieme {Aosta, Aquila,…Milano,….., Venezia}, tutte le possibile provincie. in ogni caso vanno realizzati esempio del set di valori...finestra a tendina Basi di dati Dario Colazzo hh

hh hhh Tipi e domini 2/2 Si può pensare ai domini come ad una combinazione di un tipo di dato e regole di convalida. E’ bene ricordare che la convalida è un problema riguardante l’integrità dei dati e non il modello dei dati. Come vedremo la validità del valore di un attributo (dominio) può dipendere dal valore di altri attributi. sesso:maschio  celibe Basi di dati Dario Colazzo hh

Compatibiltà tra due domini hh hhh Compatibiltà tra due domini Due domini sono compatibili se ha senso confrontare valori del primo con valori del secondo. Esempio: su di un db di un supermarket si potrebbe avere NomeImpiegato=NomeCliente per ottenere i nomi dei clienti che sono anche impiegati nell’organizzazione. Quindi i domini dei due attributi sono compatibili. Sicuramente non avrebbe senso confrontare NomeImpiegato con DataUltimoAcquisto. = parlared delle interrogazioni Basi di dati Dario Colazzo hh

Perchè occuparsi dei domini hh hhh Perchè occuparsi dei domini Oltre ad individuare gli attributi è importante capire quali sono i valori che possono assumere. Domande come questi due attributi sono interscambiabili? ci sono regole che si applicano ad uno ma non all’altro? sono importanti ai fini della progettazione per le applicazioni, integrità Basi di dati Dario Colazzo hh

Associazioni (introduzione) 1/2 hh hhh Associazioni (introduzione) 1/2 Le entità rilevate nello spazio del problema sono in genere in associazione tra di loro. Esempio, gli Impiegati sono in relazione con i Reparti: ogni impiegato corrisponde ad uno (o più) Reparti, e viceversa. In questo caso abbiamo che esiste una associazione tra Impiegati e Reparti. perchè è importante modellare le associazioni: ricordare dati e informazioni Basi di dati Dario Colazzo hh

Associazioni (introduzione) 2/2 hh hhh Associazioni (introduzione) 2/2 Modellare le associazioni è di fondamentale importanza. Da come questo viene fatto dipende la capacità del db di rispondere a interrogazioni, di eliminare ridondanze, e di mantenere informazioni aggiuntive tra i legami oltre al fatto che questi esistano nello spazio del problema. Le associazioni sono importanti per modellare inclusioni di sottotipo tra entità: Impiegati è sottotipo di Persone. dire qualcosa in più per l’ultimo punto, accennare a che tipo di associazione Basi di dati Dario Colazzo hh

Associazioni: terminologia hh hhh Associazioni: terminologia Le entità coinvolte in una associazione sono dette partecipanti. Nel precedente esempio, i partecipanti sono Impiegati e Reparti. Il grado di una associazione è dato dal numero delle entità che vi partecipano: Grado 1: associazione unaria Grado 2: associazione binaria Grado 3: associazione ternaria esempi, esempi, esempi.... Basi di dati Dario Colazzo hh

hh hhh Associazioni binarie L’associazione Impiegati-Reparti è binaria, tra le più comuni. Le associazioni binarie si classificano in uno-a-uno uno-a-molti molti-a-uno molti-a-molti. esempi, esempi, esempi Basi di dati Dario Colazzo hh

Direazione delle Associazioni In genere le associazioni vengono distinte con un nome; nel nostro esempio possiamo utilizzare “è situato in” L’associazione va da Impiegati a Reparti (verso o direzione) L’associazione inversa, lega ogni reparto ad un certo numero di impiegati (uno-a-molti) è può essere chiamata “ospita” Vedremo che non è necessario dare un nome alla associazione (dipende dal verso) Basi di dati Dario Colazzo

hh hhh Associazioni totali Una associazione e’ totale se le entità di partenza non possono esistere senza essere associate. L’esistenza di un impiegato è subordinata al collegamento di un reparto dove questo svolge la sua attività. Anche il viceversa è vero, in genere ogni reparto ha degli impiegati. In seguito vedremo che nel caso di associazioni totali, particolare attenzione deve essere dedicata alla modifica della base di dati. esempi, esempi, Basi di dati Dario Colazzo hh

Associazioni parziali Consideriamo le due entità Impiegati e MansioniSpeciali, con l’associazione “svolge” Un impiegato non svolge necessariamente mansioni speciali, quindi può esistere pur non essendo necessariamente associato ad una mansione speciale. In questo caso si dice che l’associazione è parziale Basi di dati Dario Colazzo

Associazione ternarie hh hhh Associazione ternarie Consideriamo le associazioni binarie “i clienti vendono prodotti” e “clienti acquistano prodotti” L’associazione ternaria “i venditori vendono prodotti ai clienti” stabilisce quali venditori vendono certi prodotti a quali clienti. Questa informazione non è esplicitamente disponibile se consideriamo solo le due associazioni binarie (vedremo che può essere ottenuta con opportune interrogazioni). Basi di dati Dario Colazzo hh

Diagrammi E/R (P. P. Shan Chen, 1976) Essenzialmente, una rappresentazione E/R schematizza informazioni riguardanti quali entità vi sono nel modello e quali associazioni, specificando per queste ultime anche la loro tipologia (uno-a-uno, uno-a-molti,...). In particolare, nella rappresentazione non vengono considerati i domini degli attributi, e spesso conviene specificare a parte questi ultimi. Basi di dati Dario Colazzo

Esempio di diagramma E/R hh hhh Esempio di diagramma E/R attributi entità associazione Basi di dati Dario Colazzo hh

Simbologia diagrammi E/R hh hhh Simbologia diagrammi E/R Per le associazioni useremo la seguente simbologia esercizio Basi di dati Dario Colazzo hh

hh hhh Prossimo argomento Il prossimo argomento di cui ci occuperemo tratta della struttura delle relazioni Una volta definito il modello dei dati, il passo successivo è quello di definire le relazioni che conterranno le entità Inoltre, le relazione devono essere opportunamente strutturate Questo al fine di garantire che le relazioni permettano di rispondere a tutte le interrogazioni che possono essere poste e, allo stesso tempo, minimizzare la ridondanza dei dati. problemi della ridondanza Basi di dati Dario Colazzo hh

Ridondanza La ridondanza dei dati si ha quando gli stessi dati vengono ripetute più volte ina una data relazione o tra più relazioni I problemi sono due: Sprego di risorse Complica la vita Basi di dati Dario Colazzo

Relazione con ridondanza Immaginiamo che questo recordset contenente le fatture emesse dagli impiegati, sia presente come relazione nel databse (non è il risultato di una query) Basi di dati Dario Colazzo

hh hhh Ridondanza, problemi I valori HireDate TelephoneExtension sono elencati diverse volte per ciascun impiegato Primo problema: ogni volta che immettete una nuova fattura dovete immettere nuovamente i valori per questi due campi, con possibilità di commettere errori. Secondo, non potete immettere la data di assunzione o il numero di telefono per un nuovo impiegato fino a quando questo non emette una fattura. Terzo, se le fatture di un anno vengono archiviate e tolte dal database, perdete le informazioni relative alla data di assunzione e al numero di telefono. cattivo modello Basi di dati Dario Colazzo hh

Ridaondanza tra + relazioni hh hhh Ridaondanza tra + relazioni Questi problemi, normalmente chiamati anomalie di aggiornamento, sono anche peggiori se la ridondanza è distribuita in più relazioni aggiornamento su più relazioni invoice, ordine, fattura Basi di dati Dario Colazzo hh

Ridaondanza tra + relazioni Se il numero di telefono di “Around the Horn” cambia, le modifiche devono essere apportate ad entrambe le relazioni. Nulla vieta di fare questo, ma i problemi sono ancora la possibilità di commettere errori, e di dimenticarsi un aggiornamento. Basi di dati Dario Colazzo

False ridondanze Consideriamo le due relazioni hh hhh False ridondanze Consideriamo le due relazioni In questo caso la rodondanza dei valori relativi ai prezzi unitari è apparente Nella prima tabella si tratta dei prezzi di vendita corrente Nella seconda, dei prezzi all’atto dell’emissione della fattura. I due attributi sono definiti sullo stesso dominio, ma sono logicamente distinti Basi di dati Dario Colazzo hh

Ridondanza di attributi 1/3 Osserviamo la seguente tabella Per rispondere all’interrogazione:”quali studenti frequentano il corso di biologia?” è necessario far riferimento a tutti e 5 i periodi Basi di dati Dario Colazzo

Ridondanza di attributi 2/3 hh hhh Ridondanza di attributi 2/3 L’interrogazione corrisponde alla seguente query in SQL SELECT StudentID  FROM Enrollments  WHERE  Period1 = "Biology"  OR  Period2 = "Biology" OR Period3 = "Biology"  OR Period4 = "Biology"  OR Period5 = "Biology"  OR Period6 = "Biology";  Stesso attributo con nome diverso ( errore di modellazione) cosa accade inoltre se si aggiunge un nuovo periodo? parlare delle query Basi di dati Dario Colazzo hh

Ridondanza di attributi 3/3 Con la seguente tabella la query ha una più semplice formulazione. Inoltre il modello è più flessibile: se i periodi saranno sei basterà cambiare un vincolo di integrità e non aggiungere un attributo. La query diventa: SELECT StudentID FROM Enrollments WHERE Class = "Biology"; Basi di dati Dario Colazzo

Normalizzazione In seguito formuleremo delle proprietà strutturali delle relazioni che danno una buona probabilità di assenza di anomalie di aggiornamento Queste proprietà sono chiamate forme normali, ne esamineremo 4 Il processo che porta ad una struttura che soddisfa le forme normali è detto normalizzazione. Basi di dati Dario Colazzo

Assenza di perdite Essenzialmente la normalizzazione si basa sulla suddivisione di relazioni È importante garantire l`assenza di perdita di informazioni durante la suddivisione. In altre parole, la suddivisione deve portare a relazioni che possono essere ricombinate senza perdere informazioni. Basi di dati Dario Colazzo

Esempio di divisione relazione non normalizzata Basi di dati hh hhh Esempio di divisione relazione non normalizzata dire che il collegamento è data dalla chiave Basi di dati Dario Colazzo hh

hh hhh Chiavi candidate In precedenza, abbiamo definito una relazione come un insieme non ordinato di zero o più tuple Ogni membro di un insieme è unico Per ciascuna relazione, quindi, deve esistere una combinazione di attributi che identifica univocamente una tupla Questo insieme di uno o più attributi è detta chiave candidata Spiegare cosa significa identificare univocamente perchè le chiavi sono necessarie, per le associazioni Basi di dati Dario Colazzo hh

Proprietà delle chiavi hh hhh Proprietà delle chiavi Ogni relazione può avere più chiavi candidate Ogni chiave candidata deve identificare univocamente ciascuna tupla Questo non vale per una specifica istanza di una relazione, ma per tutte le possibili tuple Le chiavi candidate dipendono dalla semantica del modello dei dati esempio con tabella (punto 3) lucido successivo, spiegare il concetto di istanza Basi di dati Dario Colazzo hh

Chiavi candidate, esempio Consideriamo la relazione CustomerId è univoco nell’esempio, ma non può essere una chiave candidata: sicuramente ci saranno più ordini relativi allo stesso cliente Basi di dati Dario Colazzo

Classificazione delle chiavi hh hhh Classificazione delle chiavi Per la caratterizzazione insiemistica delle relazioni, ognuna di esse possiede almeno una chiave candidata: l’insieme di tutti gli attributi. Chiavi semplici, un solo attributo Chiavi composte, più attributi esempi Basi di dati Dario Colazzo hh

hh ++++++++++++++++++++++++Chiavi candidate hhh Irriducibilità Ogni chiave deve essere tale che se eliminiamo uno o più attributi, gli attributi restanti non formano una chiave. Esempio CategoryId è una chiave, mentre {CategoryId, CategoryName} non lo è: può essere ridotto ad un solo attributo. domande su esempi di relazioni, persone, macchine, abitazioni chiedere anche degli attributi Basi di dati Dario Colazzo hh

Classificazione delle chiavi hh hhh Classificazione delle chiavi Per la caratterizzazione insiemistica delle relazioni, ognuna di esse possiede almeno una chiave candidata: l’insieme di tutti gli attributi. Chiavi semplici, un solo attributo Chiavi composte, più attributi esempi Basi di dati Dario Colazzo hh

hh ++++++++++++++++++++++++Chiavi candidate hhh Irriducibilità Ogni chiave deve essere tale che se eliminiamo uno o più attributi, gli attributi restanti non formano una chiave. Esempio CategoryId è una chiave, mentre {CategoryId, CategoryName} non lo è: può essere ridotto ad un solo attributo. domande su esempi di relazioni, persone, macchine, abitazioni chiedere anche degli attributi Basi di dati Dario Colazzo hh

Generatore automatico di identificatori hh hhh Generatore automatico di identificatori Quando tutte le chiavi hanno troppi attributi è possibile delegare al motore la generazione di valori univoci (marche) per le tuple. L`attributo contenete questi valori sarà la chiave. I valori, in genere, sono generati casualmente; è conveniente attribuirgli nessun significato ulteriore. Ad esempio, un errore potrebbe essere quello di vedere ogni valore di OrderID come il numero dell’ordine, e magari fare anche delle computazioni in base a tale significato. esempi Basi di dati Dario Colazzo hh

Chiave primaria Nel caso di esistenza di più chiavi candidate, una di esse viene scelta come chiave primaria. Le restanti sono dette chiavi alternative Questa distinzione non riguarda il livello logico (modello concettuale dei dati). A tale livello interessano solo le chiavi candidate. Basi di dati Dario Colazzo

Scelta delle chiavi candidate hh hhh Scelta delle chiavi candidate La scelta delle chiavi è un processo semantico, la scelta dipende dal significato del modello Non sempre è immediata In una relazione che contiene le generalità dei dipendenti di una azienda, potrebbe essere naturale scegliere {Nome, Cognome} come chiave Questa scelta è errata. Andrebbe bene CodiceFiscale, qualora tale attributo fosse previsto nella relazione oppure IdPersona Basi di dati Dario Colazzo hh

Dipendenze funzionali hh hhh Dipendenze funzionali Data una tupla T, con due insiemi di attributi A={X1,…Xn} e B={Y1,…Ym}, allora B è funzionalmente dipendente da X se: per qualunque valore valido di A esiste un solo valore valido per B esempi Basi di dati Dario Colazzo hh

Simbologia A ? B “A determina funzionalmente B” Graficamente, per A={CategoryID} e B={CategoryName, Description} Basi di dati Dario Colazzo

Dipendenze funzionali, interpretazione pratica Da un punto di vista pratico, una dipendenza funzionale esprime un concetto importante: esiste un insieme di attributi che è univoco per ciascuna tupla, e conoscendolo è possibile determinare quegli attributi che non sono univoci Basi di dati Dario Colazzo

Dipendenze e normalizzazione Se A è una chiave candidata allora tutti gli attributi B, devono necessariamente dipendere da A. In generale, se A?B, e A non è una chiave ne B contiene A, allora la relazione è necessariamente ridondante. In un certo senso, normalizzare significa avere relazioni dove tutte le dipendenze funzionali partono dalle chiavi candidate. Basi di dati Dario Colazzo

hh hhh Prima forma normale Una relazione è in prima forma normale se tutti i domini, sui quali i suoi attributi sono definiti, sono scalari L`attributo Items non è scalare Un caso classico è la data: se è necessario lavorare singolarmente sui giorni, mese, anno, allora può essere conveniente memorizzare i dati separatamente. In genere non conviene memorizzare più informazioni in uno stesso attributo (ref0010398, 10001100..); quando questo accade nella relatà modellata è conveniente scomporre i dati in fase di immissione. Abbiamo già visto che questo concetto, seppur semplice, non è di immediata implementazione Basi di dati Dario Colazzo hh

Prima forma normale: gruppi a ripetizione hh hhh Prima forma normale: gruppi a ripetizione Esaminate la relazione C’è un gruppo di attributi che si ripete; abbiamo già visto un caso simile e quali sono gli inconvenienti. Query: quali prodotti hanno superato il10 per cento delle vendite in qualsiasi periodo stessa soluzione del caso precedente Basi di dati Dario Colazzo hh

Seconda forma normale Una relazione è in seconda forma normale se è nella prima forma normale e se, inoltre, tutti i suoi attributi sono dipendenti dalla sua chiave candidata Questa relazione non è nella seconda forma normale Chiave: {ProductName, SupplierName}, ma PhoneNumber dipende solo da SupplierName, questo provoca ridondanza. Basi di dati Dario Colazzo

Seconda forma normale, divisione Al livello logico il problema nella relazione precedente, è che due entità distinte (prodotti e fornitori) sono rappresentati da una sola relazione La seguente divisione risolve il problema (scomposizione senza perdita) Basi di dati Dario Colazzo

Esempio di scomposizione hh hhh Esempio di scomposizione Attenzione: per non avere perdita di informazioni, è necessario introurre un campo SupplierId nella relazione Products dire che così mantreniamo l`associazione Basi di dati Dario Colazzo hh

Seconda forma normale, vantaggi Vantaggio: possiamo reperire informazioni sui fornitori prima di ottenere informazioni sui prodotti Nella forma precedente ciò non era possibile: era necessario avere un valore per il campo ProductName Il valore di un campo chiave non può essere vuoto. Basi di dati Dario Colazzo

Seconda forma normale, svantaggio Questa relazione è in sfn, ma si basa sul presupposto che ogni fornitore abbia un solo indirizzo Questo potrebbe non verificarsi in futuro Basi di dati Dario Colazzo

Terza forma normale Una relazione è in terza forma normale se è in sfn, e se inoltre tutti gli attributi che non sono chiave sono mutuamente indipendenti. Nella relazione del successivo slide, vi è una dipendenza tra Region e Salesperson Entrambi non possono essere chiavi candidate Basi di dati Dario Colazzo

Relazione non in tfn Basi di dati Dario Colazzo

Esempio scomposizione per tfn Questa relazione non è strettamente in tfn In effetti, PostalCode è basato sui valori City e Region; Basi di dati Dario Colazzo

Tfn, possibile divisione hh hhh Tfn, possibile divisione In fase di immissione dati, il codice postale può essere ricavato automaticamente, risparmiando digitazioni e possibilità di errori conviene separare i dati quando: i dati cambiano di frequente, oppure quando si è sicuri di vantaggi implementativi Esempi con verifica di forme normali Basi di dati Dario Colazzo hh

Relazione non in tfn Basi di dati Dario Colazzo

Esempio scomposizione per tfn Questa relazione non è strettamente in tfn In effetti, PostalCode è basato sui valori City e Region; Basi di dati Dario Colazzo

Tfn, possibile divisione hh hhh Tfn, possibile divisione In fase di immissione dati, il codice postale può essere ricavato automaticamente, risparmiando digitazioni e possibilità di errori conviene separare i dati quando: i dati cambiano di frequente, oppure quando si è sicuri di vantaggi implementativi Esempi con verifica di forme normali Basi di dati Dario Colazzo hh

Boyce-Codd La forma normale di Boyce/Codd, è cosiderata una variante della tfn Presupposti: Due o più chiavi candidate Almeno due devono essere composte Le chiavi candidate devono avere attributi sovrapponibili Essenzialmente, la fn di Boyce/Codd afferma che non devono esistere dipendenze funzionali tra le chiavi candidate. Basi di dati Dario Colazzo

Boyce-Codd, esempio 1/2 Consideriamo la seguente relazione Le due chiavi candidate in questo caso sono {SupplierId, ProductId} e {SupplierName, ProductId} Basi di dati Dario Colazzo

Boyce-Codd, esempio 2/2 Diagramma delle dipendenze: Abbiamo {SupplierID}{SupplierName}, quindi la relazione non è in forma normale di BC Da un punto di vista logico, l`anomalia è rappresentata dal fatto che le informazioni sui fornitori non dovrebbero essere presenti nella relazione Basi di dati Dario Colazzo

Boyce-Codd, normalizzazione esempio Le due tabelle danno una versione completamente normalizzata del precedente esempio Basi di dati Dario Colazzo

Quarta forma normale Consideriamo la relazione Non è in prima forma normale, l’attributo Packsize non è scalare Basi di dati Dario Colazzo

Esempio precedente in pfn Prima forma normale Esistono ridondanze, il mantenimento dell’integrità dei dati potrebbe essere difficoltoso. È in forma normale di Boyce-Codd? Basi di dati Dario Colazzo

Qfn, dipendenze multivalore La ridondanza presente nella relazione precedente è dovuta ad una particolare dipendenza: dipendenza multivalore. Una dipendenza multivalore è costituita da due insiemi di attributi A e B mutuamente indipendenti. A multidetermina B, se per ogni valore valido di A esistono uno o più valori validi di B. Notazione: A?>B Basi di dati Dario Colazzo

Qfn, normalizzazione Nell`esempio in questione la dipendenza è Si legge: Product multidetermina PackSize e SupplierName Informalmente, la qfn richiede che le dipendenze multivalore devono essere divise in più tabelle {ProductName}?>{PackSize}|{SupplierName} Basi di dati Dario Colazzo

Esempio in qfn È importante osservare che la qfn entra in gioco solo se gli attributi possiedono più valori Nel caso esaminato, se ogni prodotto possedesse solo una singola confezione o un singolo fornitore, non si applicherebbe la qfn. Basi di dati Dario Colazzo

Associazioni

Associazioni Dopo le relazioni, le associazioni costituiscono un’altra parte fondamentale del modello dei dati Come per le relazioni, per determinare le associazioni è fondamentale comprendere la semantica dello spazio del problema. Basi di dati Dario Colazzo

Associazioni, terminologia (richiamo) Prtecipanti: entità tra le quali esiste una associazione Grado: unarie, binarie, ternarie,… Totali: le entità non possono esistere a meno di partecipare all`associazione Parziali: altrimenti Basi di dati Dario Colazzo

Entità deboli e normali Una entità debole può esistere solo in associazione con altre entità Una entità normale può esistere anche senza essere associato ad altre. Esempio e simbologia Clienti Ordini Basi di dati Dario Colazzo

“is a” e “has a” Talvolta è utile classificare le associazioni in is a e has a Un Impiegato è un (is a) membro di una SquadraDiCalcio Un Impiegato ha un (has a) ordine di vendita Basi di dati Dario Colazzo

Cradinalità La cardinalità di una associazione è il numero massimo di entità che possono essere associate ad una entità Tre tipi: uno-a-uno, uno-a-molti, molti-a-molti Basi di dati Dario Colazzo

Cardinalità, simbologia nei diagrammi E/R Le associazioni sono rappresentate come linee tra rettangoli Le entità sono indicate all`interno dei rettangoli Basi di dati Dario Colazzo

Modellare le associazioni Nella rappresentazione E/R si indicano le entità e le associazioni tra queste individuate Il passo successivo è quello di modellare le associazioni Questo viene fatto rappresentando le entità coinvolte nelle asociazioni, elencando anche gli attributi di queste Basi di dati Dario Colazzo

Modellare le associazioni, un esempio Le associazioni non vengono etichettate, in genere le etichette dipendono dalla direzione in cui si legge l’associazione Basi di dati Dario Colazzo

Implementazione nel modello relazionale Come vedremo, le associazioni vengono effettivamente modellate attraverso particolari attributi delle entità coinvolte. Dal momento che le chiavi candidate individuano univocamente le istanze di entità, il collegamento viene fatto attraverso le chiavi candidate Il fatto di rappresentare le associazioni mostrando gli attributi è utile per evidenziare quali delle chiavi candidate sono utilizzate dall’associazione. Basi di dati Dario Colazzo

Chiavi interne ed esterne chiave esterna, (nota: copia della chiave di Orders) chiave interna relazione primaria relazione esterna Nella coppia chiave candidata/chiave esterna che modella l`associazione non vi deve essere necessariamente la chiave primaria della relazione primaria; dovrebbe essere usata la chiave candidata più significativa dal punto di vista semantico Basi di dati Dario Colazzo

Determinare la relazione primaria Se l’associazione è uno-a-molti, la relazione primaria è quella sul lato uno (la sua chiave candidata è aggiunta alla relazione esterna) Nel caso esistano dubbi (es. uno-a uno) la scelta dipende dalla semantica dei dati e dall’uso dell’associazione Basi di dati Dario Colazzo

Proprietà dell’associazione È possibile modellare attributi di una associazione, esempio: Una alternativa potrebbe essere quella di includere gli attributi in una delle relazioni partecipanti (non molto pulita e pesante con molti attributi) relazione astratta Basi di dati Dario Colazzo

Transizione di stato Ad esempio, se ci interessa sapere che hh hhh Transizione di stato Ad esempio, se ci interessa sapere che John e Mary Smith nel 1953 erano sposati e hanno divorziato nel 1972, e che Mary si è risposata nel 1975 è vanataggioso introdurre una relazione astratta tra entità per mantenere traccia delle transizioni Caso di più relazioni, Altro esempio: Automobili / Persone Basi di dati Dario Colazzo hh

Associazioni uno-a-uno hh hhh Associazioni uno-a-uno Ogni istanza dell`entità X può essere associata con una sola istanza dell’entità Y Associazione uno-a-uno tra Office e Employee Osservazione: il modello potrebbe non essere adatto nel caso in cui gli impiegati cambiano reparto: Se state modellando un sistema per recapitare la posta, volete sapere quale sia il suo ufficio attuale, e non quello di tre mesi fa Potrebbe interessare una statistica sulla frequenza di cambiamento dei reparti da parte degli impiegati Come soddisfare queste esigenze ? Basi di dati Dario Colazzo hh

Associazioni uno-a-uno per modellare attributi specifici hh hhh Associazioni uno-a-uno per modellare attributi specifici Supponiamo di avere delle entità Orders, potremo avere il seguente modello per catturare gli attributi specifici di ogni categoria di prodotto Problema del modello: se vogliamo ricercare il codice di un prodotto, dobbiamo verificare se esiste nella relazione x, o nella relazione y,…. (le categorie possono essere molte) Inoltre, cosa accade se la categoria di un prodotto cambia? Condimenti, Caseari (dairy products) , carni/pollame Basi di dati Dario Colazzo hh

Sottoclassi Per ovviare ai problemi prima evidenziati, risulta conveniente adottare il seguente modello Si possono trattare le informazioni specifiche per le diverse categorie senza perdere la capacità di trattare i prodotti come tipo generico. Basi di dati Dario Colazzo

Soluzione alternativa hh hhh Soluzione alternativa Se tutto ciò che interessa riguardo ai prodotti è quello di produrre report con raggruppamento per categoria, è sufficiente il seguente modello: Products cattura gli attributi per tutti i prodotti, gli attributi relativi alle bevande sono intrinsicamente diversi da quelli per condimenti. (questo problema viene risolto con le sottoclassi, che però possono complicare la stesura di applicazioni, come report (elaborazione condizionale per visualizzare solo I campi appropriati) Basi di dati Dario Colazzo hh

Associazioni uno-a-uno, relazione primaria e secondaria Nel caso di sottoclassi, l’entità generica diventa la relazazione primaria, e ciascuna sottoclasse diventa la una relazione esterna Importante: quasi sempre, la chiave che le sottoclassi acquisiscono è anche la loro chiave candidata. Raramente hanno una chiave propria. Negli altri casi la scelta è arbitraria; se esiste un lato facoltativo (raramente entrambi i lati lo sono), allora questa può essere la relazione esterna (entità debole). Basi di dati Dario Colazzo

hh hhh uno-a-molti È la più comune, inoltre la maggioranza delle tecniche di normalizzazione viste si risolvono cone questo tipo di associazione In genere, si ritiene che solo il lato molti possa essere facolativo; non vero, esempio: L’AgenteServizioClienti può avere zero o più clienti, un AgenteServizioClienti di un cliente, se ne è stato assegnato uno, deve essere presente nella relazione AgenteServizioClienti. la facoltatività sul lato uno Basi di dati Dario Colazzo hh

uno-a-molti, relazione primaria e secondaria L’entità sul lato uno è sempre la relazione primaria La chiave candidata della relazione sul lato uno viene copiata nulla relazione sul lato molti, che diventa la relazione esterna La chiave candidata della relazione primaria spesso costituisce parte della chiave candidata della relazione sul lato molti Basi di dati Dario Colazzo

molti-a-molti Esempio: Non possono essere implementate direttamente in un database relazionale gli studenti frequentano molti corsi, i corsi sono frequentati da molti studenti Basi di dati Dario Colazzo

molti-a-molti, implementazione Si untroduce una relazione intermediaria che possiede una associazione uno-a-molti con ognuno dei partecipanti La relazione intermediaria è normalmente chiamata tabella unione, anche al livello del modello dei dati quando si parla di relazioni (entità) e non di tabelle. Basi di dati Dario Colazzo

molti-a-molti, esempio L’associazione molti-a-molti ...diventa Quali attributi contiene la tabella unione? tabella unione relazioni primarie Basi di dati Dario Colazzo

Associazioni unarie Una relazione è associata con se stessa Sono modellate come le relazioni binarie, con la differenza che relazione primaria e esterna coincidono. Possono avere qualunque cardinalità, quelle molti-a-molti richiedono ugualmente una tabella unione. Basi di dati Dario Colazzo

Associazioni unaria uno a molti Sono utilizzate per modellare le gerarchie gerarchia Impiegati-Manager oss: parziale sul lato uno, i direttori generali non hanno un dirigente Basi di dati Dario Colazzo

SQL :Structured Query Language

Relazioni di base e derivate Le relazioni definite nello schema di database sono dette relazioni di base, sono effettivamente memorizzate (e ottimizzate) Una relazione derivata è definita in termini di altre relazioni attraverso interrogazioni al motore di database, espresse in uno specifico linguaggio Nelle basi di dati relazionali, il linguaggio è SQL Basi di dati Dario Colazzo

Sintassi query SQL SELECT <lista campi> FROM  <lista recordset>        <tipo di join> JOIN <condizione di join> WHERE  <condizioni di selezione tuple> GROUP BY  <lista di attributi di raggruppamento> HAVING  <criterio di selezione> ORDER BY  <lista di attributi su cui ordinare> Basi di dati Dario Colazzo

SELECT-FROM SELECT <lista campi> FROM <lista recordset> L’unica parte obbligatoria è In altre parole, è obbligatorio indicare almeno le tabelle da cui si intende estrarre dati (FROM) e quali campi di queste selezionare (SELECT) SELECT <lista campi>  FROM  <lista recordset>        Basi di dati Dario Colazzo

Operatori relazionali Sono restrizione, proiezione, join, (divisione) Più alcuni operatori insiemistici: unione, intersezione, differenza, prodotto cartesiano Queste sono le operazioni definite per manipolare le relazioni Sono tutte implementate attraverso una appropriata SELECT di SQL Basi di dati Dario Colazzo

Valori Null e logica a tre valori Nell’implementare gli operatori relazionali con SQL vedremo che sarà necessario confrontare valori memorizzate nelle tabelle. È possibile che alcuni di questi siano del valore speciale Null, che molti motori mettono a disposizione Basi di dati Dario Colazzo

Informazioni sconosciute o inesistenti Il valore Null è stato introdotto per modellare la possibilità di avere informazioni “mancanti” o “assenti”. Non risolve il problema: quando un valore di un campo non è inserito (è di valore Null) non sappiamo se il dato era inesistente o mancante. Questo problema può essere risolto per alcuni domini basati su tipi come stringhe o testo: posso modellare l’inesistenza con valori di lunghezza zero, e con Null il fatto che non si conosce il valore. Attenzione: non conviene introdurre valori convenzionali. Basi di dati Dario Colazzo

Confronti con valori Null Cosa accade se ad esempio voglio testare l’uguaglianza di due dati (es: ora/data) di cui uno è Null? Per i valori booleani abbiamo le seguenti tabelle: In genere Null op Valore restituisce Null Basi di dati Dario Colazzo

Logica a tre valori Possiamo avere condizioni dove alcune sottoespressioni possono assumere Null, come regolarci? Logica a tre valori: Basi di dati Dario Colazzo

Restrizione SELECT * FROM Employees WHERE LastName = "Davolio" Restrizione: restringere un insieme di record ai soli record che soddisfano una condizione (WHERE) La clausola WHERE può contenere espessioni logiche complesse costruite con altri operatori di confronto (<, >, ...) e connettivi (AND, OR,...) SELECT *  FROM Employees  WHERE LastName = "Davolio" Basi di dati Dario Colazzo

Proiezione La proiezione seleziona una porzione verticale di un recordset, esempio ORDER BY specifica il criterio di ordinamento del recordset che la query restituisce SELECT LastName, FirstName, Extension FROM Employees ORDER BY LastName, FirstName; Basi di dati Dario Colazzo

Join L’operazione di join è fondamentale: permette di ricombinare più relazioni in una sola. Senza tale operatore non sarebbe possibile scomporre le relazioni per poi ricomporle Il join ricombina le relazioni in base al confronto di uno più campi comuni In base al tipo di confronto e al modo in cui sono trattati i risultati di confronto, si distinguono tre tipi di join, implementati per mezzo di una combinazione di SELECT e JOIN. Basi di dati Dario Colazzo

Equi-join Si ha quando il join è effettuato in base ad un confronto di uguaglianza Se consideriamo la seguente porzione di schema, possiamo ricombinare le relazioni in accordo all’associazione uno-a-molti Basi di dati Dario Colazzo

INNER JOIN Esempio Può essere vista come una operazioni di denormalizzazione SELECT Orders.OrderID, Orders.CustomerID, [Order Details].ProductID FROM Orders  INNER JOIN [Order Details]  ON Orders.OrderID = [Order Details].OrderID WHERE (Orders.OrderID)=10248; Basi di dati Dario Colazzo

Theta-Join È una Join (INNER) basata su un operatore di confronto diverso dall’uguaglianza: <>, >, >=, <, <=. Non sono applicate frequentemente, ma possono essere utilizzate per interrogazioni che individuano record con un valore maggiore di una media o di un totale, oppure compresi in un intervallo. Basi di dati Dario Colazzo

Theta-Join, esempio Consideriamo le tabelle possono essere riunite per visualizzare i prodotti che hanno venduto di più all’interno di una categoria Basi di dati Dario Colazzo

Theta-Join, query SELECT DISTINCTROW ProductCategoryAverages.CategoryName, ProductTotals.ProductName FROM ProductCategoryAverages  INNER JOIN ProductTotals  ON ProductCategoryAverages.CategoryID =  ProductTotals.CategoryID AND ProductTotals.TotalSold >  ProductCategoryAverages.AverageSold; Basi di dati Dario Colazzo

..risultato theta-join Basi di dati Dario Colazzo

Riscrittura di query La precedente query è equivalente a SELECT DISTINCTROW  ProductCategoryAverages.CategoryName, ProductTotals.ProductName FROM ProductCategoryAverages  INNER JOIN ProductTotals  ON ProductCategoryAverages.CategoryID =  ProductTotals.CategoryID WHERE ProductTotals.TotalSold >  ProductCategoryAverages.AverageSold; Basi di dati Dario Colazzo

SQL :Structured Query Language

Relazioni di base e derivate Le relazioni definite nello schema di database sono dette relazioni di base, sono effettivamente memorizzate (e ottimizzate) Una relazione derivata è definita in termini di altre relazioni attraverso interrogazioni al motore di database, espresse in uno specifico linguaggio Nelle basi di dati relazionali, il linguaggio è SQL Basi di dati Dario Colazzo

Sintassi query SQL SELECT <lista campi> FROM  <lista recordset>        <tipo di join> JOIN <condizione di join> WHERE  <condizioni di selezione tuple> GROUP BY  <lista di attributi di raggruppamento> HAVING  <criterio di selezione> ORDER BY  <lista di attributi su cui ordinare> Basi di dati Dario Colazzo

SELECT-FROM SELECT <lista campi> FROM <lista recordset> L’unica parte obbligatoria è In altre parole, è obbligatorio indicare almeno le tabelle da cui si intende estrarre dati (FROM) e quali campi di queste selezionare (SELECT) SELECT <lista campi>  FROM  <lista recordset>        Basi di dati Dario Colazzo

Operatori relazionali Sono restrizione, proiezione, join, (divisione) Più alcuni operatori insiemistici: unione, intersezione, differenza, prodotto cartesiano Queste sono le operazioni definite per manipolare le relazioni Sono tutte implementate attraverso una appropriata SELECT di SQL Basi di dati Dario Colazzo

Valori Null e logica a tre valori Nell’implementare gli operatori relazionali con SQL vedremo che sarà necessario confrontare valori memorizzate nelle tabelle. È possibile che alcuni di questi siano del valore speciale Null, che molti motori mettono a disposizione Basi di dati Dario Colazzo

Informazioni sconosciute o inesistenti Il valore Null è stato introdotto per modellare la possibilità di avere informazioni “mancanti” o “assenti”. Non risolve il problema: quando un valore di un campo non è inserito (è di valore Null) non sappiamo se il dato era inesistente o mancante. Questo problema può essere risolto per alcuni domini basati su tipi come stringhe o testo: posso modellare l’inesistenza con valori di lunghezza zero, e con Null il fatto che non si conosce il valore. Attenzione: non conviene introdurre valori convenzionali. Basi di dati Dario Colazzo

Confronti con valori Null Cosa accade se ad esempio voglio testare l’uguaglianza di due dati (es: ora/data) di cui uno è Null? Per i valori booleani abbiamo le seguenti tabelle: In genere Null op Valore restituisce Null Basi di dati Dario Colazzo

Logica a tre valori Possiamo avere condizioni dove alcune sottoespressioni possono assumere Null, come regolarci? Logica a tre valori: Basi di dati Dario Colazzo

Restrizione SELECT * FROM Employees WHERE LastName = "Davolio" Restrizione: restringere un insieme di record ai soli record che soddisfano una condizione (WHERE) La clausola WHERE può contenere espessioni logiche complesse costruite con altri operatori di confronto (<, >, ...) e connettivi (AND, OR,...) SELECT *  FROM Employees  WHERE LastName = "Davolio" Basi di dati Dario Colazzo

Proiezione La proiezione seleziona una porzione verticale di un recordset, esempio ORDER BY specifica il criterio di ordinamento del recordset che la query restituisce SELECT LastName, FirstName, Extension FROM Employees ORDER BY LastName, FirstName; Basi di dati Dario Colazzo

Join L’operazione di join è fondamentale: permette di ricombinare più relazioni in una sola. Senza tale operatore non sarebbe possibile scomporre le relazioni per poi ricomporle Il join ricombina le relazioni in base al confronto di uno più campi comuni In base al tipo di confronto e al modo in cui sono trattati i risultati di confronto, si distinguono tre tipi di join, implementati per mezzo di una combinazione di SELECT e JOIN. Basi di dati Dario Colazzo

Equi-join Si ha quando il join è effettuato in base ad un confronto di uguaglianza Se consideriamo la seguente porzione di schema, possiamo ricombinare le relazioni in accordo all’associazione uno-a-molti Basi di dati Dario Colazzo

INNER JOIN Esempio Può essere vista come una operazioni di denormalizzazione SELECT Orders.OrderID, Orders.CustomerID, [Order Details].ProductID FROM Orders  INNER JOIN [Order Details]  ON Orders.OrderID = [Order Details].OrderID WHERE (Orders.OrderID)=10248; Basi di dati Dario Colazzo

Theta-Join È una Join (INNER) basata su un operatore di confronto diverso dall’uguaglianza: <>, >, >=, <, <=. Non sono applicate frequentemente, ma possono essere utilizzate per interrogazioni che individuano record con un valore maggiore di una media o di un totale, oppure compresi in un intervallo. Basi di dati Dario Colazzo

Theta-Join, esempio Consideriamo le tabelle possono essere riunite per visualizzare i prodotti che hanno venduto di più all’interno di una categoria Basi di dati Dario Colazzo

Theta-Join, query SELECT DISTINCTROW ProductCategoryAverages.CategoryName, ProductTotals.ProductName FROM ProductCategoryAverages  INNER JOIN ProductTotals  ON ProductCategoryAverages.CategoryID =  ProductTotals.CategoryID AND ProductTotals.TotalSold >  ProductCategoryAverages.AverageSold; Basi di dati Dario Colazzo

..risultato theta-join Basi di dati Dario Colazzo

Riscrittura di query La precedente query è equivalente a SELECT DISTINCTROW  ProductCategoryAverages.CategoryName, ProductTotals.ProductName FROM ProductCategoryAverages  INNER JOIN ProductTotals  ON ProductCategoryAverages.CategoryID =  ProductTotals.CategoryID WHERE ProductTotals.TotalSold >  ProductCategoryAverages.AverageSold; Basi di dati Dario Colazzo

Join-esterna Restituisce tutti i record che soddisfano le condizioni di join (join interna) + i record di uno o entrambi i recordset I valori non corrispondenti saranno Null Tre tipi: join esterna sinistra, join esterna destra, join esterna piena Basi di dati Dario Colazzo

Esempi join esterne d/s SELECT *  FROM X LEFT OUTER JOIN Y  ON <condition> FROM Y RIGHT OUTER JOIN X  Entrambe restituiscono i record di X e tutti i record di Y per cui <condition> è valutata a True. Basi di dati Dario Colazzo

Join esterna completa SELECT * FROM X FULL OUTER JOIN Y ON <condition> Restituisce i record provenienti da entrambi i recordset, combinando quelli per i quali la condizione è True. Basi di dati Dario Colazzo

Unione L’unione relazionale è la concatenazione di due recordset Esempio: SELECT CompanyName AS Name, Address, City, PostalCode  FROM Customers UNION SELECT [FirstName] & " " & [LastName] AS Name,  Address, City, PostalCode  FROM Employees ORDER BY Name; Basi di dati Dario Colazzo

risultato unione Basi di dati Dario Colazzo

Intersezione Restituisce i record comuni a due recordset; è implementata attraverso join esterne Supponiamo di avere due elenchi di clienti e di volere i clienti che occorrono in entrambi Basi di dati Dario Colazzo

Intersezione, esempio Basi di dati Dario Colazzo

Intersezione, query SELECT DuplicateCustomers1.* FROM DuplicateCustomers1  LEFT JOIN DuplicateCustomers2  ON  (DuplicateCustomers1.CustomerID =  DuplicateCustomers2.CustomerID)  AND  (DuplicateCustomers1.CompanyName =  DuplicateCustomers2.CompanyName) WHERE  DuplicateCustomers2.CustomerID IS NOT NULL; Basi di dati Dario Colazzo

....risultato Basi di dati Dario Colazzo

Differenza Restituisce i record che appartengono ad un recordset ma non all’altro Può essere ottenuta con due passaggi Basi di dati Dario Colazzo

Primo passo Basi di dati Dario Colazzo

Secondo passo Basi di dati Dario Colazzo

Prodotto cartesiano Il prodotto cartesiano combina ogni record di un recordset con i record di un secondo recordset SELECT CustomerName, CSRName  FROM Customer, CSRs; Sono utilizzati allo scopo di analisi o come risultati intermedi Basi di dati Dario Colazzo

Riepilogo, esempio di query Basi di dati Dario Colazzo

..risultato Basi di dati Dario Colazzo

Estensione Permette di introdurre campi virtuali che sono calcolati Offre la possibilità di non introdurre campi calcolati nelle tabelle, esempio SELECT [UnitPrice]*[Qty] AS ExtendedPrice FROM [Order Details]; Basi di dati Dario Colazzo

Rinomina Già introdotta Utile per definire auto-join SELECT Manager.Name, Employee.Name  FROM Employees AS Employee  INNER JOIN Employees AS Manager  ON Employee.EmployeeID = Manager.EmployeeID; Basi di dati Dario Colazzo