Unità didattica 2: Basi di dati MODULO DIDATTICO: I DATABASE SCUOLA INTERUNIVERSITARIA SICILIANA DI SPECIALIZZAZIONE PER L’INSEGNAMENTO SECONDARIO Classe di Concorso: 42A Angelo Carpenzano Unità didattica 2: Basi di dati MODULO DIDATTICO: I DATABASE Docente: Prof. Cantone

Gli studenti devono conoscere: Prerequisiti Gli studenti devono conoscere: 1. Nozioni di entità, attributo, chiave, associazione 2. Il modello E/R e le regole di derivazione del modello logico 3. Le principali tecniche per la documentazione efficace dell’analisi di un problema

Competenze 1. Rilevare i limiti dell’organizzazione non integrata degli archivi 2. Comprendere i concetti e le tecniche per la progettazione di basi di dati 3. Applicare correttamente le tecniche di derivazione delle tabelle del modello relazionale a partire dal modello E/R 4. Conoscere i concetti fondamentali del modello relazionale 5. Saper applicare le principali operazioni sulle tabelle

Contenuti 1. Modelli per database 2. Differenze tra i modelli 3. Modello relazionale 4. Operazioni relazionali

Metodologie Lezione frontale Lezione dialogata “Brainstorming”

Spazi Aula Laboratorio

Strumenti Libro di testo Dispense e appunti Computer Proiettore

Verifiche Periodiche e costanti, tese sia alla valutazione globale del percorso formativo che ad una sua parte. Vengono usate diverse tipologie: Colloqui individuali Interventi di vario genere Questionari e Test Prove in laboratorio

Valutazione La valutazione sarà di due tipi: Di tipo formativo (in relazione all’applicazione, all’impegno, all’attenzione, al metodo di lavoro dimostrato da ogni studente durante l’attività didattica) Di tipo sommativo (ricavata dalla misurazione delle varie prove), in cui gli studenti dovranno dimostrare di: avere acquisito conoscenze e informazioni circa i contenuti avere maturato abilità e competenze specifiche alla disciplina

Recupero e/o Potenziamento Tempi Lezione Laboratorio Verifica Recupero e/o Potenziamento 20 ore 0 ore 4 ore 6 ore

Cominciamo…

Le basi di dati Basi di dati (database): archivi di dati, organizzati in modo integrato attraverso tecniche di modellazione dei dati e gestiti sulle memorie di massa dei computer attraverso appositi software (DBMS), con l’obiettivo di raggiungere una grande efficienza nel trattamento e nel ritrovamento dei dati. Il database è una collezione di archivi di dati ben organizzati e ben strutturati, in modo che possano costituire una base di lavoro per utenti diversi con programmi diversi. Es: i dati relativi agli articoli del magazzino di un’azienda possono essere utilizzati dal programma che stampa le fatture e dal programma che stampa i listini di magazzino. ARTICOLI FATTURE LISTINI

Caratteristiche delle basi di dati Efficienza e produttività di un’organizzazione di archivi: possibilità di ritrovare facilmente le informazioni desiderate (anche attraverso criteri di ricerca diversi) in termini di velocità nell’elaborazione, di sicurezza dei dati e integrità delle registrazioni. Devono essere garantite: Consistenza degli archivi: i dati in essi contenuti devono essere significativi ed essere effettivamente utilizzabili nelle applicazioni dell’azienda. Sicurezza: impedire che il database venga danneggiato da interventi accidentali o non autorizzati. Integrità: le operazioni effettuate sul database da utenti autorizzati non devono provocare perdita di consistenza ai dati.

DBMS DBMS (DataBase Management System): prodotti software per la gestione di database. Gli archivi che costituiscono la base di dati possono risiedere: su un unico computer; su computer diversi, facenti parte di una rete, i cui nodi possono anche essere fisicamente lontani (database distribuiti). Gli utenti della base di dati distribuita: elaborano localmente gli archivi che hanno a disposizione nel proprio sistema; nello stesso tempo accedono in maniera remota a sistemi centrali attraverso le linee di comunicazione.

Esempio di applicazione pratica Limiti degli archivi convenzionali Le tecniche di gestione delle basi di dati nascono per superare i problemi e i limiti insiti nelle tradizionali organizzazioni degli archivi in modo non integrato. Esempio di applicazione pratica Si vogliono gestire i conti correnti di un’azienda bancaria appartenenti alle diverse filiali e i movimenti contabili che vengono effettuati sui conti. Nella sede centrale della banca si vogliono organizzare le informazioni riguardanti i conti delle filiali. Per ciascun conto occorre registrare il numero di conto, il nome dell’intestatario, l’indirizzo, il codice della filiale e la descrizione della filiale. I/V

Soluzione del problema con l’approccio tradizionale Limiti degli archivi convenzionali Soluzione del problema con l’approccio tradizionale Le informazioni vengono organizzate in un archivio i cui record hanno il seguente tracciato: NUMCONTO NOME INDIRIZZO CODFILIALE DESCRIZ 9 40 30 5 20 NUMCODICE DESCRIZ CITTA DATA IMPORTO CAUSALE 9 40 20 8 10 3 Al contempo, nelle filiali bisogna registrare le informazioni sui movimenti effettuati sui conti: numero del conto, nome del correntista, città, data del movimento, importo e causale. Il record del file corrispondente possiede il seguente tracciato: II/V

Limiti degli archivi convenzionali Quando si vogliono associare tra loro i dati contenuti nei due archivi possono nascere problemi di questo tipo: i sono due campi con nomi diversi che rappresentano lo stesso dato (NumConto e NumCodice); lo stesso dato viene rappresentato in formati diversi (Indirizzo nel primo tracciato e Città nel secondo); ci sono due campi con lo stesso nome che rappresentano dati diversi (Descriz nel primo archivio rappresenta la filiale e nel secondo l’intestatario del conto); NUMCONTO NOME INDIRIZZO CODFILIALE DESCRIZ 9 40 30 5 20 NUMCODICE DESCRIZ CITTA DATA IMPORTO CAUSALE 9 40 20 8 10 3 III/V

Limiti degli archivi convenzionali Quando si vogliono associare tra loro i dati contenuti nei due archivi possono nascere problemi di questo tipo: c’è ridondanza di dati (la descrizione della filiale è ripetuta per ogni conto nel primo tracciato, il nome e la città del correntista vengono ripetuti per ogni movimento); il fatto che gli stessi dati compaiano in due archivi diversi può causare anomalie in fase di aggiornamento e quindi problemi di inconsistenza (se il dato viene modificato in un archivio e non nell’altro). NUMCONTO NOME INDIRIZZO CODFILIALE DESCRIZ 9 40 30 5 20 NUMCODICE DESCRIZ CITTA DATA IMPORTO CAUSALE 9 40 20 8 10 3 III/V

Limiti degli archivi convenzionali Quali sono le cause? RIDONDANZA DEI DATI (Gli stessi dati compaiono in maniera duplicata) INCONGRUENZA (se il dato viene aggiornato in un archivio e non in un altro, oppure se sono presenti valori diversi per lo stesso dato) INCONSISTENZA DEI DATI (i dati a disposizione non sono più affidabili, perché non si sa in modo certo quale dei diversi valori sia quello corretto) Tutto ciò deriva dal fatto che i dati sono organizzati in archivi diversi, in maniera non integrata. IV/V

Limiti degli archivi convenzionali Soluzione Individuare con precisione quali sono gli elementi che caratterizzano l’applicazione. Associamo a ciascuno di essi un archivio, il cui tracciato contiene i campi che individuano l’elemento e una chiave (tipicamente un codice). La chiave identifica univocamente il record all’interno dell’archivio e consente di stabilire legami con gli altri archivi. archivio delle filiali, con codice filiale e descrizione filiale; archivio dei conti, con codice conto, nome del correntista, indirizzo, città, codice filiale di appartenenza; archivio dei movimenti, con numero del movimento, data, importo, causale, codice del conto sul quale è stato effettuato il movimento. V/V

Limiti degli archivi convenzionali NUMCONTO NOME INDIRIZZO CITTA FILIALE 9 40 30 20 5 NUMMOV DATA IMPORTO CAUSALE CODICE 6 8 10 3 CODFILIALE DESCRIZ archivio delle filiali, con codice filiale e descrizione filiale; archivio dei conti, con codice conto, nome del correntista, indirizzo, città, codice filiale di appartenenza; archivio dei movimenti, con numero del movimento, data, importo, causale, codice del conto sul quale è stato effettuato il movimento. V/V

Caratteristiche fondamentali: Archivi integrati La teoria dei database introduce una nuova metodologia di organizzazione degli archivi di dati, con l’obiettivo di superare i limiti visti. Caratteristiche fondamentali: indipendenza dalla struttura fisica dei dati: i programmi applicativi sono indipendenti dai dati fisici; indipendenza dalla struttura logica dei dati: i programmi applicativi sono indipendenti dalla struttura logica con cui i dati sono organizzati negli archivi; utilizzo da parte di più utenti: i dati organizzati in un unico database possono essere utilizzati da più utenti con i loro programmi, consentendo anche una visione solo parziale del database da parte del singolo utente; eliminazione della ridondanza: gli stessi dati non compaiono più volte in archivi diversi; I/II

Archivi integrati II/II facilità di accesso: il ritrovamento dei dati è facilitato e svolto con velocemente; integrità dei dati: vengono previsti controlli per evitare anomalie ai dati causate dai programmi e dalle applicazioni degli utenti; sicurezza dei dati: sono previste procedure di controllo per impedire accessi non autorizzati ai dati contenuti nel database e di protezione da guasti accidentali; uso di linguaggi per la gestione del database: il database viene gestito attraverso comandi per la manipolazione dei dati in esso contenuti e comandi per effettuare interrogazioni alla base di dati, al fine di ottenere le informazioni desiderate. II/II

I modelli per il database Il database è un modello della realtà considerata. I contenuti della base di dati rappresentano gli stati in cui si trova la realtà da modellare. I cambiamenti che vengono apportati alla base di dati rappresentano gli eventi che avvengono nell’ambiente in cui opera l’azienda. CONTENUTI DEL DB STATI DELLA REALTA’ CAMBIAMENTI NEL DB EVENTI NELLA REALTA’ L’uso dei dati organizzati in un database presuppone un attento lavoro di progettazione iniziale, che viene fatto con riferimento ai dati che si vogliono memorizzare e successivamente elaborare. I/II

I modelli per il database Novità rispetto all’organizzazione convenzionale degli archivi: Il progetto è indipendente: dal computer, dai supporti fisici destinati a contenere le informazioni dalle caratteristiche del DBMS. Ciò consente alla base di dati di evolvere nel tempo insieme alla realtà aziendale per la quale è stata progettata, con il crescere delle esigenze degli utenti e della necessità di informazioni. A partire dallo schema concettuale entità/associazioni, un database può essere progettato e realizzato passando al modello logico, cioè alle strutture che consentono di organizzare i dati per consentire le operazioni di manipolazione e di interrogazione. II/II

Flat file La soluzione più semplice consiste nel costruire un database con una struttura di dati formata da un unico file. Questa struttura, detta flat file, è adatta solo per basi di dati estremamente semplici. Una struttura flat file non è efficiente per la maggior parte delle applicazioni gestionali. Nello sviluppo della teoria dei database sono emersi principalmente tre tipi diversi di modelli per le basi di dati: 1. Modello gerarchico 2. Modello reticolare 3. Modello relazionale

Modello gerarchico E’ particolarmente adatto per rappresentare situazioni nelle quali è possibile fornire ai dati una struttura nella quale ci sono entità che stanno in alto ed entità che stanno in basso, secondo uno schema ad albero, nel quale i nodi rappresentano le entità e gli archi rappresentano le associazioni. Struttura di dati gerarchica: insieme ordinato di alberi. Un tipo di albero nel database gerarchico è formato da un unico record radice e da un insieme ordinato di sottoalberi di livello inferiore. Un sottoalbero a sua volta consiste in un singolo record (radice del sottoalbero) e da un insieme di sottoalberi e così via.

Modello gerarchico: esempio Modello che rappresenta le aree di interesse per un’azienda che vende tramite agenti, i quali hanno i clienti e gli ordini ricevuti. Ogni ordine è composto da una o più righe che fanno riferimento ai prodotti venduti. L’albero ha come radice il record Agente, il quale a sua volta ha due sottoalberi con la radice in Cliente e Ordine. Entrambi hanno sottoalberi di livello più basso con le righe dell’ordine e gli articoli delle righe. AGENTE CLIENTE ORDINE RIGA ARTICOLO

Modello gerarchico Il modello gerarchico è particolarmente adatto a rappresentare le associazioni 1:N (uno a molti). Presenta dei limiti, soprattutto nella rigidità della struttura di dati creata (talvolta non riesce ad evitare la ridondanza dei dati).

Modello reticolare Nel modello reticolare le entità rappresentano i nodi e le associazioni rappresentano gli archi di uno schema a grafo orientato: si tratta di una estensione del modello di albero gerarchico (sono consentite anche associazioni tra entità che stanno in basso, e non solo dall’alto verso il basso). Un database reticolare consiste di due insiemi di dati: un insieme di record un insieme di legami I tipi record sono fatti di campi tra i quali ci deve essere anche un campo chiave, mentre i legami sono realizzati memorizzando le coppie di chiavi delle entità associate.

Modello reticolare: esempio Non esiste una gerarchia predefinita tra le entità. Un record figlio può avere un numero qualsiasi di padri: in questo modo vengono evitate situazioni di ripetizione di dati uguali. AGENTE CLIENTE ORDINE RIGA ARTICOLO CA CC CO CR La gestione delle informazioni è più complessa (in quanto deve essere utilizzata una struttura a grafo). Un database costruito secondo il modello reticolare può produrre prestazioni più elevate.

Modello relazionale Rappresenta il database come un insieme di tabelle. E’ considerato attualmente il modello più semplice ed efficace, perché: è più vicino al modo consueto di pensare i dati; si adatta in modo naturale alla classificazione e alla strutturazione dei dati. AGENTE CLIENTE ORDINI RIGHE ARTICOLI

Confronto tra i modelli 1. I modelli gerarchico e reticolare sono diventati obsoleti per il mercato e per la ricerca, che sono orientati verso il modello relazionale negli anni più recenti. 2. I primi due modelli furono definiti attraverso un processo di astrazione da sistemi già implementati, mentre il modello relazionale è stato definito a livello teorico prima di qualsiasi implementazione sul computer. 3. Le operazioni sui database gerarchici e reticolari sono complesse, agiscono su singoli record e non su gruppi di record.

I database orientati agli oggetti Database orientati agli oggetti (OODB, Object Oriented DataBase): gestiscono oggetti e classi. utilizzano concetti tipici della programmazione ad oggetti (es. metodo, ereditarietà); accettano sottoclassi di oggetti; ogni oggetto ha una propria identità. Favoriscono l’avvicinamento tra programmi applicativi e DB, perché permettono di usare tipi di dati definiti dall’utente e di associare ai dati routine di codice che rappresentano le modalità di accesso ai dati: viene applicato il concetto di oggetto al DB. Consente di utilizzare tecnologie più avanzate insieme alle prestazioni tipiche dei linguaggi utilizzati nella programmazione ad oggetti, come il C++.

Definizione matematica Modello relazionale: concetti di base Il modello relazionale si basa sul concetto matematico di relazione tra insiemi di oggetti. Cos’è una relazione? Dati n insiemi A1, A2,…, An, si dice relazione un sottoinsieme dell’insieme di tutte le n-uple a1, a2, …, an che si possono costruire prendendo nell’ordine un elemento a1 dal primo insieme A1, a2 dal secondo insieme A2, e così via. Definizione matematica n = grado della relazione Ai = dominio i-esimo della relazione a1, … an = tupla L’insieme delle tuple si chiama cardinalità della relazione. I/III

Modello relazionale: concetti di base La relazione è rappresentata con una tabella, avente tante colonne quanti sono i domini (grado) e tante righe quante sono le n-uple (cardinalità). A1 A2 AN Domini ……… a1 a2 ……… an cardinalità I nomi dei domini sono i nomi delle colonne, i valori che compaiono in una colonna sono omogenei tra loro (appartengono allo stesso dominio). tupla grado La relazione (collezione di tuple) è un’entità, ogni tupla è un’istanza dell’entità, le colonne sono gli attributi dell’entità, il dominio è l’insieme dei possibili valori di un attributo. II/III

Modello relazionale: concetti di base La chiave della relazione è un attributo o una combinazione di attributi che identificano univocamente le tuple: ogni riga della tabella possiede valori diversi per l’attributo (o gli attributi) chiave. CLIENTI FATTURE PAGAMENTI RIGHE FATTURE Il modello relazionale di un database è un insieme di tabelle, sulle quali si possono effettuare operazioni e tra le quali possono essere stabilite delle associazioni. III/III

Modello relazionale: requisiti a. tutte le righe della tabella contengono lo stesso numero di colonne; b. gli attributi rappresentano informazioni elementari (atomiche), ovvero non scomponibili ulteriormente; c. i valori assunti da un campo appartengono al dominio dei valori possibili per quel campo, ovvero sono omogenei tra loro; d. in una relazione, ogni riga è diversa da tutte le altre, ovvero esiste un attributo o una combinazione di attributi che identificano univocamente la n-upla; e. le n-uple compaiono nella tabella secondo un ordine non prefissato, ovvero non è rilevante il criterio con il quale le righe sono sistemate nella tabella.

Integrità sull’entità Ogni dato elementare contenuto nel modello relazionale deve essere accessibile attraverso la combinazione di: nome della tabella, nome e valore della chiave, nome della colonna contenente il dato. Nessuna componente della chiave primaria di una tabella può avere valore nullo.

Le regole di derivazione del modello logico Le tabelle vengono ricavate dal modello E/R applicando le regole di derivazione: ogni entità diventa una relazione; ogni attributo di un’entità diventa un attributo della relazione; ogni attributo della relazione eredita le caratteristiche dell’attributo dell’entità da cui deriva; l’identificatore univoco di un’entità diventa la chiave primaria della relazione derivata; l’associazione uno a uno diventa un’unica relazione, che contiene gli attributi della prima e della seconda entità; nell’associazione uno a molti, l’identificatore univoco dell’entità di partenza diventa chiave esterna (foreign key) dell’entità di arrivo associata; l’associazione con grado molti a molti diventa una nuova relazione, composta dagli identificatori univoci delle due entità e dagli eventuali attributi dell’associazione.

Operazioni relazionali Agiscono su una relazione per ottenere una nuova relazione. Effettuano le interrogazioni alle basi di dati per ottenere le informazioni desiderate, estraendo da una tabella una sottotabella o combinando tra loro due o più tabelle. AGENTE CLIENTE Relativo a Abbinato a AGENTI CLIENTI Codice Agente Nome Agente Indirizzo Agente Codice Zona Codice Cliente Ragione Sociale Codice Attività Partita IVA Indirizzo Cliente Codice Agente

Selezione La selezione genera una nuova relazione costituita solo dalle n-uple della relazione di partenza che soddisfano una determinata condizione: vengono selezionate le righe con i valori degli attributi corrispondenti alla condizione prefissata. La relazione ottenuta possiede tutte le colonne della relazione di partenza e quindi ha lo stesso grado; la cardinalità della nuova relazione può essere minore o uguale alla tabella di partenza (solitamente è minore).

Selezione: esempio Se si vuole l'elenco dei clienti della provincia di Milano, si effettua sulla relazione Clienti una selezione per Provincia =“MI” estraendo dalla tabella tutte le righe che hanno quel valore per l'attributo provincia, ottenendo così una nuova tabella.

Proiezione La proiezione genera una nuova relazione estraendo dalla tabella iniziale due o più colonne corrispondenti agli attributi prefissati. La tabella ottenuta potrebbe avere più righe uguali: in questo caso occorre richiedere che ne venga conservata solo una. La relazione risultante ha grado minore o uguale al grado della relazione di partenza; la cardinalità è uguale a quella di partenza.

Proiezione: esempio Se si vuole l'elenco dei codici di attività dei clienti con i relativi codici degli agenti, occorre applicare alla relazione Clienti l’operazione di proiezione secondo gli attributi CodiceAttività e CodiceAgente.

Congiunzione La congiunzione (join) serve a combinare due relazioni aventi uno o più attributi in comune, generando una nuova relazione contenente le righe della prima e della seconda tabella, che possono essere combinate secondo i valori uguali dell’attributo comune. a1 b1 a2 b2 a3 b3 b1 c1 b2 c2 b3 c3 a1 b1 c1 a2 b2 c2 a3 b3 c3 Il grado della relazione generata è uguale a N1+N2–1, dove N1 e N2 sono i gradi delle relazioni di partenza; la cardinalità non è prevedibile a priori. I/III

Congiunzione: esempio L’elenco dei clienti e dei relativi agenti si ottiene applicando l’operazione di congiunzione tra la relazione Clienti e la relazione Agenti secondo l’attributo comune CodiceAgente.

Combinazioni di operazioni Gli operatori possono essere applicati alle tabelle anche in successione, combinandoli tra loro in vario modo. Vengono così effettuate interrogazioni sulle relazioni ottenute come risultato di un’interrogazione precedente. Quesito Ottenere l’elenco delle ragioni sociali e degli agenti per i clienti che hanno il codice di attività pari a 3109. Occorre applicare la seguente sequenza di operazioni: Selezione di Clienti per CodiceAttività = 3109 Congiunzione della relazione ottenuta su CodiceAgente e di Agenti su CodiceAgente Proiezione della relazione ottenuta su RagioneSociale, NomeAgente

Operazioni tra tabelle con struttura omogenea Due tabelle hanno struttura omogenea se hanno colonne con lo stesso numero di attributi, dello stesso tipo e nello stesso ordine. In questo caso si possono applicare le usuali operazioni sugli insiemi. Unione Genera una nuova tabella che contiene le righe della prima e della seconda tabella con riduzione a una di quelle ripetute.

Operazioni tra tabelle con struttura omogenea Intersezione Genera, a partire da due tabelle omogenee, una nuova tabella che contiene soltanto le righe comuni. Differenza Genera una nuova tabella che contiene soltanto le righe della prima tabella che non sono contenute nella seconda.

Fine