Scarica Appunti informatica su Database e più Appunti in PDF di Elementi di Informatica solo su Docsity!
APPUNTI INFORMATICA DATABASE
INTRODUZIONE (lez. 9 24/10/2024) Le basi di dati sono utili a gestire i dati, che negli ultimi anni hanno avuto una crescita esponenziale nel loro utilizzo. I dati nel mondo reale vengono prodotti da: 1 Sistemi informativi aziendali 2 Social media 3 Sorgenti di big data Perché i dati sono importanti? I dati sono una risorsa importantissima per qualsiasi azienda, al pari di risorse come il capitale, gli impianti di produzione, le persone, e dei beni prodotti dall’azienda. I dati inoltre sono un bene prodotto dall’azienda e fonte di profitto. Inoltre essi sono importanti in quanto generano conoscenza, che supporta nelle decisioni aziendali. BUSINESS INTELLIGENCE (BI) (def.) Insieme di processi aziendali, metodologie tool per raccogliere i dati di un’azienda, ed estrarre informazioni di supporto alla decisioni strategiche. Per quanto riguarda i dati, analizzeremo modelli, linguaggi, e strumenti software al fine di progettare, implementare ed analizzare collezioni (Basi) di Dati (DB) che siano: Persistenti (memorizzate su un supporto fisico, e quindi persistenti nel tempo) Potenzialmente grandi Potenzialmente condivise (tra utenti/applicazioni) Forniremo un’introduzione al mondo delle basi di dati (DB) da due punti di vista: Utente che interagisce con un DB (aggiungere/modificare informazioni, recuperare informazioni, etc). Progettista, che si occupa di come progettare un DB. Esistono appositi strumenti software, sviluppati fin dagli anni ‘60, per la gestione delle basi di dati. Questi strumenti software si chiamano Database Management System (DBMS)ovvero dei sistemi software che sono in grado di gestire BD grandi, condivise e
persistenti, in maniera efficiente e sicura. Da qui in avanti, per noi una base di dati è una collezione di dati gestita da un DBMS SISTEMA INFORMATIVO E SISTEMA INFORMATICO Un Sistema Informativo (SI) è una componente di un’organizzazione il cui scopo è quello di gestire le informazioni utili ai fini dell’organizzazione stessa. ES. Organizzazione: • Azienda, Ufficio, Ente, Università, etc. L’esistenza di un Sistema Informativo è indipendente dalla sua automatizzazione. Ad esempio sono esistiti sistemi informativi anche in tempi antichi, come ad esempio la biblioteca reale di Alessandria D’Egitto oppure i censimenti e il registro anagrafe al tempo dell’impero romano. La porzione automatizzata di un sistema informativo prende il nome di Sistema Informatico. All’interno di un sistema informatico, le informazioni sono rappresentate da dati. Gran parte dei sistemi informatici ha la necessità di gestire dati in maniera persistente (dove persistente vuol dire dati memorizzati su una memoria secondaria e pertanto persistenti nel tempo) Abbiamo due approcci di gestione ai dati: Approccio convenzionale (basato su files) Approccio strutturato (basato su software di gestione dei dati) APPROCCIO CONVENZIONALE (basato su files) L’approccio convenzionale, basato su files, sfrutta la presenza di file per memorizzare i dati in memoria secondaria: in questo tipo di approccio i dati vengono scritti su un file che poi viene salvato nella memoria secondaria del computer. Inoltre, nell’approccio basato su file: non vi è nessuna chiara distinzione tra dati ed applicazioni.
Perché utilizziamo un livello intermedio (DBMS) per memorizzare i files anziché utilizzare direttamente l’applicazione? Ovvero perché bisogna utilizzare l’approccio dbms based (strutturato) al posto di quello convenzionale? Risposta: perché vi e la necessità di disaccoppiare (cioè separare) dati e applicazioni inserendo il dbms come livello intermedio, in maniera analoga a quanto avviene nella struttura interna di un computer dove bisogna separare il software applicativo dall’hardware introducendo un livello intermedio che è il software di base. QUALI SONO LE CARATTERISTICHE DI UN DBMS?
- Efficienza : Un DBMS è efficiente se è in grado di gestire le operazioni sui dati utilizzando le risorse di sistema (tempo e spazio) in modo ottimale, garantendo prestazioni rapide e scalabili. Questo avviene fornendo adeguate strutture dati per organizzare I dati all’interno dei file, e per supportare le operazioni di
ricerca/aggiornamento. In genere, parliamo di strutture dati ad albero o tabelle hash. Uno strumento attraverso cui il dbms può garantire efficienza è l’indice, che contiene informazioni sulla posizione di memorizzazione delle tuple sulla base del valore del campo chiave.
- Concorrenza : In molti sistemi è fondamentale gestire operazioni concorrenti (nello stesso momento) di accesso ai dati. Al tempo stesso, un DBMS deve garantire il fatto che accessi da parte di applicazioni diverse non interferiscano tra loro, lasciando il sistema in uno stato inconsistente. Per prevenire tali situazioni, i DBMS implementano algoritmi di controllo della concorrenza affinché operazioni sui dati (transazioni) eseguite in concorrenza producano lo stesso risultato di un’esecuzione seriale.
- Affidabilità: Alcune operazioni sui dati sono particolarmente delicate e devono essere gestite in maniera opportuna, secondo la regola del tutto o niente. Es. Trasferimento di denaro (100$) dal conto X al conto Y. Supponiamo che nel mezzo di questa operazione il sistema subisca un malfunzionamento. Per evitare che vengano salvate operazioni non corrette (dovute al malfunzionamento), i DBMS devono fornire appositi strumenti per annullare operazioni non completate e fare roll back dello stato del sistema, riportandolo allo stato iniziale. In molti casi i DBMS mettono a disposizione appositi strumenti ed algoritmi per garantire la persistenza dei dati anche in presenza di malfunzionamenti hardware/software
- Sicurezza: La maggior parte dei DBMS implementa politiche di controllo degli accessi ai dati mediante sistemi di permessi: ci sono alcuni dati che sono riservati e non devono essere accessibili a tutti ma solo agli utenti autorizzati Quindi I DBMS implementano rigorosi meccanismi di autenticazione e autorizzazione per tutelare la riservatezza dei dati. Solo gli utenti autorizzati possono accedere alle informazioni in base a specifici privilegi. DATABASE: MODELLO LOGICO (LEZ 10 28/10/2024) Un DBMS può essere visto come un’architettura software strutturata su 3 livello: Schema esterno: descrive come si presenta il database, cioè come i dati appaiono per un utente o per un gruppo di utenti Schema logico: descrive cosa rappresenta il database (descrive l’organizzazione logica dei dati) Schema fisico: descrive come e dove sono memorizzati i dati Facendo riferimento all’approccio strutturato basato su dbms descritto in precedenza, abbiamo. 5
SOFTWARE
APPLICATIVO
SCHEMA ESTERNO
SCHEMA LOGICO
DBMS
Proprietà (auspicabili) dei livelli in un DBMS: 1)Indipendenza fisica: interagire con il modello logico in modo indipendente dallo schema fisico. 2)Indipendenza logica: interagire
Come possono utenti ed applicazioni interagire con un DBMS? Quasi tutti i DBMS mettono a disposizione dei linguaggi: Linguaggio DDL: Definizione dello schema logico Linguaggio DML: Manipolazione delle istanze Questi sono Linguaggi orientati ai dati, che sono molto diversi da linguaggi di programmazione “tradizionali” (es. C/C++/Java/etc) Noi prenderemo in considerazione il linguaggio SQL che contiene sia il linguaggio DDL che il linguaggio DML. Per quanto riguarda le applicazioni che vogliono interagire con il DBMS, esse integrano codice SQL all’interno del loro codice e inoltre utilizzano opportune librerie (fornite dal DBMS) per gestire la connessione al DBMS. Un esempio molto in voga di modello integrato DBMS/App è web information system (WIS). VANTAGGI E SVANTAGGI NELL’UTILIZZO DI UN DBMS VANTAGGI: (quando usare un DBMS in un profetto software?) Necessità di gestire grandi volumi di dati Necessità di costruire sistemi data-centric con molte operazioni di accesso ai dati Necessità di condividere dati, fornendo l’accesso a diversi sistemi SW/applicazioni Necessità di garantire la persistenza dei dati anche a fronte di possibili guasti e malfunzionamenti HW/SW
Necessità di implementare meccanismi di sicurezza per l’accesso ai dati in un ambiente multi-utente SVANTAGGI: (quando NON utilizzare un DBMS in un progetto software?) Prestazioni In alcuni sistemi con richieste di efficienza sull’elaborazione, l’overhead computazionale (risorse utilizzate) introdotto dal DBMS può essere eccessivo Costo Spese per l’acquisto di DBMS, formazione del personale, amministrazione del DB, etc che possono risultare troppo eccessive Complessità quando bisogna gestire sistemi di dimensioni ridotte, single-user o con pochi dati da gestire non è necessario utilizzare un sistema complesso come un DBMS. Dopo aver capito quando bisogna utilizzare un DBMS, dobbiamo chiederci quale DBMS utilizzare? Finora abbiamo parlato in generale delle caratteristiche dei DBMS, supponendo che questi siano tutti uguali ma in realtà non è così. Tra due DBMS possono esistere ad esempio delle differenze sostanziali in termini di: Modello logico supportato (relazionale? RDBMS) Linguaggio DDL/DML (SQL-2? SQL-3? varianti?) Algoritmi di indicizzazione (es. R+ tree?) Supporto alla transazioni (es. proprietà ACID?) Gestione della concorrenza etc DBMS: UN PO’ DI STORIA Il primo DBMS mai creato fu Information Management System (IMS), un software sviluppato da IBM nel 1968 che venne Utilizzato come supporto alle missioni Apollo per la gestione dei dati tecnici/amministrativi e delle forniture di materiali. Questo IMS è basato su un Modello gerarchico di gestione dei dati, motore transazionale per la concorrenza Nel 1970, un ricercatore della IBM (Edgar Codd) pubblica la sua visione di modello “relazionale” dei dati, basato sul concetto matematico di relazione tra insiemi. Negli anni 1970, IBM lavora allo sviluppo di un linguaggio basato sul modello relazionale (SQL), ed all’implementazione di un RDBMS sperimentale, ma continua anche lo sviluppo del sistema IMS. Nel 1979, una piccola startup (Relational Software Inc) produce un primo esempio di RDBMS commerciale. Nel 1982, Relational Software cambia il proprio nome in Oracle Corporation. Negli anni ‘80, compaiono i primi DBMS basati sul modello ad oggetti (ORDBMS), Viene sviluppata OQL – omologo di SQL per il paradigma ad oggetti. Nonostante ciò ORDBMS restano poco diffusi. Oggi, il mercato globale dei DBMS è in continua espansione ed è dominato da quattro grandi aziende, che da sole hanno il 75% dei ricavi totali: Oracle, IBM, Microsoft, SAP. IN COSA CONSISTE IN PRATICA IL MODELLO LOGICO? Si tratta di:
- un Insieme di concetti per strutturare/organizzare i dati relativi ad un certo dominio d’interesse.
- Insieme di regole per modellare eventuali vincoli e restrizioni sui dati (Esempio di vincolo sui dati: Il voto d’esame è un numero intero compreso tra 18 e 30)
Ogni attributo (colonna) dispone di un DOMINIO che definisce l’insieme di valori validi per quell’attributo. Es. dom(Nome) = string. E’ possibile avere domini ripetuti nella stessa relazione. Il dominio di un attributo può essere atomico (singoli dati omogenei) oppure complesso (più dati eterogenei). Una relazione si dice in Prima Forma Normale (PFN) se tutti gli attributi sono definiti su domini atomici e non su domini complessi.
Una base di dati può essere costituita da molte tabelle. Spesso, le informazioni contenute in relazioni diverse sono correlate tra loro Nel modello relazionale, i riferimenti tra dati in relazioni differenti sono espressi mediante valori. Nel modello relazionale, le tabelle (relazioni) sono collegate tra loro mediante i valori all’interno dei dati, ovvero attraverso la replica dei valori contenuti negli attributi. Nella pratica, quando si inizia a progettare una base di dati di un certo dominio d’interesse, le informazioni NON sono già tradotte in dati del modello relazionale. Es. Realizzazione di un sistema informativo per gestire i dati di una società immobiliare. • Quali dati devono essere gestiti? Quali/quante tabelle usare? Rispondere a tali quesiti è compito del progettista. Anziché creare tante tabelle, potremmo inserire i dati in un’unica grande tabella? NO, perché inserendo tutti i dati in un’unica tabella si avrebbero diversi problemi: grandi dimensioni della tabella, duplicazione e ridondanza dei dati, si avrebbe una limitazione nella correzione di un eventuale errore o nell’aggiornamento di un dato, in quanto si dovrebbe correggere l’errore o aggiornare il dato operando in ogni riga in cui esso è presente. LA
Una ennupla su un insieme di attributi X è una funzione che associa a ciascun attributo A in X un valore del dominio di A. t[A] denota il valore della ennupla t sull'attributo A. Istanza di relazione su uno schema R(X): insieme r di ennuple su X Generalizzando, nel caso di basi di dati composte da più relazioni: Schema di base di dati: insieme di schemi di relazione: R = {R1(X1), ..., Rk(Xk)} Istanza di base di dati su uno schema R = {R1(X1), ..., Rk(Xk)}: insieme di istanze di relazioni r = {r1,..., rn} (con ri relazione sullo schema Ri) BASI DI DATI: MODELLO LOGICO (lez. 11 31/10/2024) Una ennupla è un insieme di elementi che costituiscono una riga della tabella. Altre componenti del modello relazionale: Informazioni incomplete Vincoli di integrità, i quali comprendono Vincoli intra-relazionali e Vincoli inter- relazionali INFORMAZIONI INCOMPLETE In una relazione, le ennuple di dati devono essere omogenee (ossia avere tutte la stessa struttura). In caso contrario potrebbero sorgere diversi problemi: Cosa accade se il valore di un attributo per una certa ennupla non è noto (esiste ma non è noto al momento della creazione della ennupla)? Cosa accade se il valore di un attributo per una certa ennupla è inesistente (non esiste)?
Cosa accade se il valore di un attributo per una certa ennupla è senza informazione? Una possibile soluzione per tutti e tre i casi potrebbe essere quella di colmare le informazioni mancanti usando “valori speciali”. Tuttavia l’utilizzo di valori speciali non è adatto in quanto si richiedono valori speciali per ogni attributo e inoltre Si richiede di conoscere la semantica dei valori “speciali” da parte delle applicazioni. In alternativa: le informazioni mancanti sono etichettate con il valore NULL. Quindi t[A], per ogni attributo A, è un valore del dominio dom(A) oppure il valore NULL (se ricadiamo in valori non noti, inesistenti o senza informazione). Tramite valori NULL, è possibile gestire i 3 casi visti in precedenza (valori non noti, inesistenti o senza informazione), senza necessità di operare distinzione tra gli stessi. E’ fondamentale limitare il numero di valori NULL in una relazione. Questo perché se in una tabella ci sono tanti valori NULL significa che il DB non è stato ben progettato e la tabella dovrà essere suddivisa in più tabelle. Per definizione, NULL diverso da NULL. In tal modo non creeremo due ennuple (righe) uguali anche utilizzando il valore NULL, (in quanto ogni null è diverso da un altro null). VINCOLI DI INTEGRITA’
DEFINIZIONE DI SUPERCHIAVE: Un sottoinsieme K di attributi di una relazione è una superchiave se NON esistono due ennuple distinte tx e ty con tx[K]= ty[K]. una superchiave è un sottoinsieme K di attributi tali che non esistono ennuple distinte con lo stesso valore. Una chiave di una relazione r è una superchiave minimale di r (ossia non esiste un’altra superchiave K’ che sia contenuta in K). (Matricola, nome) è una superchiave (perché non si ripete lo stesso valore). È anche una chiave? Per capirlo dobbiamo ricordare che una chiave è una superchiave minimale, dove per superchiave minimale si intende che non esiste un’altra superchiave K’ che sia contenuta in K. Prendiamo gli attributi singolarmente: matricola è una superchiave, nome è una superchiave quindi sicuramente matricola, nome non è una chiave. L’attributo matricola costituisce una chiave della relazione studenti, perché consente di identificare in maniera univoca le ennuple della
Altro esempio: consideriamo gli attributi cognome, data nascita. Cognome, data nascita è una superchiave, perché non si ripete lo stesso valore. Ma è anche una chiave? Per capirlo prendiamo gli attributi singolarmente: se almeno uno di essi è una superchiave, allora cognome data nascita non è una chiave altrimenti lo è. Cognome non è una superchiave; data nascita non è una superchiave quindi cognome data nascita è una chiave minimale e quindi una chiave.
Esiste sempre almeno una superchiave per ogni relazione? SI Possono esistere più superchiavi per la stessa relazione? SI Esiste sempre almeno una chiave per ogni relazione? SI Possono esistere più chiavi per la stessa relazione? SI In fase di progettazione, le chiavi dovrebbero essere definite a livello di schema, e non di istanza. Se ragionassimo a livello di istanza, un attributo (fortuitamente) potrebbe essere una chiave, ma in seguito all’inserimento di altri dati nel DB potrebbe non esserlo più. Dunque bisogna ragionare a livello di schema. A COSA SERVONO LE CHIAVI? Per accedere a ciascuna ennupla della base di dati, in maniera univoca. Per correlare dati tra relazioni differenti. Cosa accade se una chiave ha valori NULL? In questo caso, potrebbero NON essere garantiti l’indirizzamento univoco delle ennuple e le correlazioni tra tabelle diverse.
In molti scenari d’uso, risulta utile imporre un vincolo sulle dipendenze tra relazioni. Il vincolo è questo CHIAVE ESTERNA: Un vincolo di integrità referenziale (“foreign key”, chiave esterna) fra gli attributi X di una relazione R1 e un’altra relazione R2 impone ai valori (diversi da NULL) su X in R1 di comparire come valori della chiave primaria di R2. In pratica: consente di collegare le informazioni tra tabelle diverse attraverso valori comuni. Chiave esterna : attributo in una relazione (referente) che fa da chiave primaria in un'altra relazione, che si chiamerà relazione riferita (e quindi è esterno rispetto alla prima, formando una chiave esterna) Pilota: attributo della relazione voli che compare come chiave primaria nella relazione piloti e quindi è chiave
Il vincolo di integrità referenziale è definito tra gli attributi di una tabella (interna) ed il nome della tabella referenziata. Es. Attributo Partenza della relazione VOLI e la relazione AEROPORTI Nel modello relazionale (teorico) non è necessario definire l’attributo della relazione AEROPORTI, in quanto si suppone che la chiave primaria esista e sia unica. Partenza: attributo della relazione voli che compare come chiave primaria nella relazione aereoporti, e quindi è una chiave esterna
