Cos’è un database

1. Basi di Dati Relazionali Dario ColazzoUniversità di PisaDipartimento di InformaticaCorso Italia, 40Pisa, 56125email: colazzo@di.unipi.ittelefono: +39 050 887265

2. 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). Dario Colazzo

3. 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. Dario Colazzo

4. 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. Dario Colazzo

5. 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 Dario Colazzo

6. 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 Modello dei dati Spazio del problema Dario Colazzo

7. 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. Dario Colazzo

8. 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). Dario Colazzo

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

10. 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. Dario Colazzo

11. 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. Dario Colazzo

12. 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’. Dario Colazzo

13. 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. Dario Colazzo

14. 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. Dario Colazzo

15. 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) Dario Colazzo

16. 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 Dario Colazzo

17. 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. Dario Colazzo

18. 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. Dario Colazzo

19. 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. Dario Colazzo

20. Determinare gli attributi 2/62/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? Dario Colazzo

21. 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. Dario Colazzo

22. 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). Dario Colazzo

23. 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. Dario Colazzo

24. Determinaregli 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 indirizzidegli impiegati. Dario Colazzo

25. 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. Dario Colazzo

26. 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. Dario Colazzo

27. 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. Dario Colazzo

28. 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. Dario Colazzo

29. 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 Dario Colazzo

30. 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. Dario Colazzo

31. 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. Dario Colazzo

32. 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 Dario Colazzo

33. 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. Dario Colazzo

34. 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) Dario Colazzo

35. 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. Dario Colazzo

36. 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 Dario Colazzo

37. 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 Dario Colazzo

38. 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. Dario Colazzo

39. Esempio di diagramma E/R attributi entità associazione Dario Colazzo

40. Simbologia diagrammi E/R • Per le associazioni useremo la seguente simbologia Dario Colazzo

41. 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. Dario Colazzo

42. 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 Dario Colazzo

43. 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) Dario Colazzo

44. 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. Dario Colazzo

45. Ridaondanza tra + relazioni • Questi problemi, normalmente chiamati anomalie di aggiornamento, sono anche peggiori se la ridondanza è distribuita in più relazioni Dario Colazzo

46. 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. Dario Colazzo

47. 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. Dario Colazzo

48. 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 Dario Colazzo

49. Ridondanza di attributi 2/3 • L’interrogazione corrisponde alla seguente query in SQL SELECT StudentID  FROM Enrollments  WHEREPeriod1 = "Biology"  OR Period2 = "Biology" OR Period3 = "Biology"  OR Period4 = "Biology" OR Period5 = "Biology"  OR Period6 = "Biology"; Dario Colazzo

50. 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"; Dario Colazzo