1 / 171

Cos’è un database

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. Cos’è un database.

Download Presentation

Cos’è un database

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 concettuale. • La definizione del modello concettuale con tutti i meccanismi che il SGBD mette a disposizione è chiamato schema di database (nela caso di RSGBDe’ costituito da tabelle, chiavi primarie ed esterne, ecc...). 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 logico di database Modello concettuale 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. Schema concettuale 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 lo schema concettuale, traduciamo lo spazio del problema in termini di entità, attributi, domini e associazioni. Dario Colazzo

  14. Schema concettuale 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 concettuale dei dati e schema logico è 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

More Related