Prof. Lorenzo Vita , Ing. Luigi Testa Dati e Base di Dati Prof. Lorenzo Vita , Ing. Luigi Testa

Data Base e DBMS Un data base (DB) è un insieme di informazioni correlate tra di loro, che formano un unico insieme e sono disponibili per più utenti o applicazioni. Le informazioni contenute nel data base sono memorizzate in un supporto di memoria di massa Il data base non presenta le informazioni all’utente. Un’applicazione, il Data Base Managment System (DBMS), si occupa della presentazione dei dati. In un data base ben progettato i dati sono ben organizzati, senza duplicati, con informazioni correlate memorizzate in un’unica struttura e con la possibilità di stabilire associazioni tra le varie strutture.

Architettura di un Data Base I data base possono essere realizzati secondo diverse architetture sia hardware sia software. Tra le architetture ricordiamo: File based. Un’applicazione che accede direttamente ai file e ai dati memorizzati nel suo disco locale o in un disco di rete. Architettura usata normalmente nei personal computer. L’applicazione sul PC riveste i ruoli di client e di server. Host based. Tutte le funzionalità del data base ed il controllo dei dati è effettuato da un mainframe centrale a cui gli utenti si collegano attraverso terminali stupidi. L’applicazione sul mainframe riveste i ruoli di client e di server. Client server. I servizi di data base sono implementati su un computer (il server) che offre una gestione centralizzata e garantisce la sicurezza e la condivisione di risorse. Il server in questo caso coincide con il data base ed i suoi servizi. I clients sono terminali intelligenti che si occupano della gestione dell’interazione con il server.

Oggi esistono varie architetture software che consentono di dividere un’applicazione in diversi livelli assegnando ad ogni livello un compito: Presentation service: Presentare le informazioni all’utente in un formato a lui congeniale Business service: in questo livello vengono controllate tutte le regole restrittive sui dati, proprie dell’applicazione (limiti sui valori dei dati, controllo dei loro valori etc…) Data service: Fornisce il servizio di immagazzinamento, sicurezza ed integrità dei dati.

Si parla di architetture software: a 2 strati (2 – Tier) proprie dei sistemi host based (mainframe e terminali stupidi) in cui il terminale si occupa solo della presentazione e il mainframe del livello di business e dei dati a 2 strati (2 – Tier) proprie dei sistemi client server in cui il terminale si occupa sia della presentazione sia del livello di business, e il server del livello dei dati A 3 strati (3 – Tier o N –Tier). Ogni livello si occupa di una funzionalità

I DBMS dati conformi alle specifiche imposte dal committente Un Data Base Managment System e un software che consente la gestione di grosse quantità di dati e le operazioni per la loro gestione (inserimento, cancellazione, modifica, ricerca) Un DBMS garantisce: la consistenza dei dati ovvero: dati conformi alle specifiche imposte dal committente Se esistono varie copie degli stessi dati, queste devono contenere in ogni momento lo stesso valore. Ciò si ottiene riducendo in fase di progettazione al minimo la ridondanza (ridurre al minimo copie diverse dello stesso dato) e usando specifici meccanismi per garantire la consistenza dei dati la congruenza dei dati: dati tra loro correlati (associati) devono contenere informazioni non discordanti l’integrità dei dati ovvero il rispetto dell’insieme di regole che definiscono i valori che possono assumere i dati. Il DBMS consente di definire vincoli sui dati (di dominio, di entità, referenziali e definiti dall’utente)

I DBMS Un Data Base Managment System garantisce inoltre: l’affidabilità dei dati ovvero la capacità del sistema di conservare intatti tutti i dati contenuti nel data base, anche in caso di malfunzionamento hardware e software: (backup) e (recovery) transazioni e log delle transazioni la privatezza dei dati: i dati non vengono persi o modificati da altri utenti senza autorizzazione. Il DBMS consente la definizione di utenti e gruppi di utenti, specificando per ogni utente o gruppo di utenti su quali dati del Data Base può agire e quali operazioni può fare su di essi (lettura, inserimento, cancellazione, modifica)

I DBMS Un Data Base Managment System garantisce: la condivisione delle informazioni. Utenti diversi devono poter accedere contemporaneamente e coerentemente a dati comuni. Il DBMS offre dei sistemi per il controllo di concorrenza (esempio evitare che due utenti accedano contemporaneamente agli stessi dati uno per leggere e l’altro per scrivere). La condivisione dei dati viene garantita per mezzo di lock sui dati e di protocolli per la richiesta, l’ottenimento ed il rilascio dei lock sulle singole risorse del data base l’efficienza ovvero la capacità di svolgere le operazioni, soprattutto quelle di ricerca, in tempi rapidi e occupando il minor spazio di memoria possibile. L’efficienza in termini di tempo è garantita dalla creazione di indici che facilitano l’esecuzione di ricerche complesse

I DBMS Un Data Base ben progettato inoltre deve garantire: L’indipendenza dei dati dalle applicazioni. Questo è realizzato attraverso: un’indipendenza fisica dei dati, ovvero una progettazione del data base completamente svincolata dal DDMS che lo realizza fisicamente e dalle applicazioni che utilizzano il data base Un’indipendenza logica dei dati, ovvero una progettazione dei dati tale da potersi adattare dinamicamente alle diverse richieste di dati e ricerche da parte dell’utente. In questo caso il DBMS offre la possibilità di creare viste (view o maschere) che consentono visualizzazioni particolari dei dati, non necessariamente coincidenti con la loro struttura logica.

I DBMS in Commercio Access: è un DBMS desktop o file based e non client / server. Consente di gestire un numero limitato di utenti (non più di trenta) e ha limitazioni sulla quantità di dati che può gestire. SQL Server: è un data base client / server e consente il collegamento di migliaia di utenti e la gestione di volumi di dati molto maggiori. È un sistema più affidabile e scalabile (capace di adattarsi ad un numero di utenti crescente) di Access. Oracle Server: è anch’esso un DBMS client server ed è uno dei sistemi più diffusi per realizzare Data Base di grosse dimensioni in termini di dati e di utenti MySql: un DBMS gratuito molto usato con il sistema operativo LINUX oggi disponibile anche per sistemi operativi della famiglia Microsoft.

Ciclo di vita del software

Ciclo di vita del software Studio di fattibilità Raccolta requisiti Analisi e progettazione Implemen tazione Validazione e collaudo Funzionamento

Modelli di dati A partire dall’osservazione della realtà e dall’intervista (contratto) con il committente si realizzano diversi modelli dei dati a livelli di astrazione via via decrescenti, per un maggior spazio ai dettagli realizzativi: Modello concettuale Modello logico Modello fisico

Modelli di dati Modello concettuale: rappresenta i dati e le relazioni tra essi attraverso uno schema. Lo schema finale deve essere indipendente: dal valore dei dati, dall’uso dei dati e quindi dalle procedure, funzioni e programmi che elaborano questi dati, da ciò che deve essere mostrato all’utente di questi dati (viste parziali per gli utenti). Il modello più usato in questa fase è il modello entità associazioni o Entity relationship.

Modelli di dati Modello logico: descrive la struttura dei dati negli archivi elettronici. Oltre ai dati vengono descritte le strutture di supporto per facilitare le operazioni che si devono effettuare con i dati Risultato di questa fase è una definizione delle strutture dati e della loro organizzazione. In questa fase si determina l’organizzazione del data base (flat file, data base gerarchico, reticolare, relazionale ad oggetti od altro), ed in funzione dell’organizzazione scelta si determina la struttura logica di ogni elemento.

Modelli di dati Modello fisico: in questo modello i dati vengono descritti relativamente alla loro memorizzazione fisica sul disco. Per ogni gruppo di dati vengono specificati: la struttura nel disco il disco o la partizione (porzione) di disco dove vengono memorizzati come gli indici scelti nella fase precedente vengono realizzati (la loro struttura: esempio indici clustered o non clustered) etc…

Dal contratto al modello concettuale Il modello concettuale deve essere una rappresentazione schematica dei dati da memorizzare e gestire nel nostro sistema informativo Per realizzare il modello è quindi necessario, prima di tutto, individuare da una lettura attenta del contratto: i soggetti che devono essere memorizzati nel sistema informativo (soggetti di interesse) Le azioni compiute dai soggetti presi in considerazione I risultati di queste azioni (complementi oggetto o altri complementi) Più in generale, dalla lettura del contratto vanno individuati i sostantivi e i verbi

Il modello concettuale Uno dei modelli concettuali più adoperato è il modello entità associazioni (entity relationship) Questo modello si basa su: Entità e loro attributi Associazioni tra entità ed attributi di queste associazioni Individuate le entità e le associazioni, queste vengono rappresentate in maniera grafica per fornire una rappresentazione complessiva del sistema informativo

Entità Rappresentano modelli o prototipi di oggetti (classi) L’entità serve a caratterizzare le proprietà comuni che hanno tutti gli elementi (oggetti) della stessa classe. Di un’entità abbiamo diverse istanze o occorrenze (oggetti di quella classe) Gli oggetti sono elementi concreti, mentre le entità sono modelli astratti Gli oggetti della classe hanno proprietà comuni Un’occorrenza (istanza) dell’entità è un oggetto concreto del modello, prototipo, entità Esempio: data l’entità professore, il Prof. Albert Einstain rappresenta un’istanza dell’entità professore.

Entità: esempi Nella gestione di un magazzino, le entità possono essere cliente, fornitore, articolo etc.... Per la gestione di un albergo le entità potrebbero essere: cliente, camera Per un’agenzia turistica le entità potrebbero essere: cliente, viaggio Per individuare le entità nel contratto con il committente i soggetti (o in qualche caso i sostantivi) sono buoni candidati per le entità.

Associazioni Rappresentano legami logici tra due o più entità Anche in questo caso il legame logico è astratto e si concretizza in una coppia (o terna a secondo della cardinalità della associazione, ovvero dal numero di entità coinvolte nell’associazione) di occorrenze di entità: un’occorrenza per ogni entità coinvolta nell’associazione

Associazioni Se si usa la prima rappresentazione delle associazioni, in cui esse hanno un verso, nel contratto con il committente, i verbi rappresentano in generale le associazioni. Se si usa il simbolo del rombo per rappresentare le associazioni, queste non sono caratterizzate da un verso. In questo caso conviene sostituire il verbo con un sostantivo per meglio rappresentare l’associazione. Persona Città Risiede in E’ residenza per Sede di abitazione Persona Città

Associazioni: esempi Un cliente compra un articolo (i) (un articolo è comprato da più clienti) Un cliente prenota una stanza d’albergo (una stanza è prenotata da più clienti) Un turista acquista un pacchetto turistico (un pacchetto turistico è acquistato da più turista). Un fornitore fornisce un dipartimento di un determinato prodotto (relazione ternaria e non binaria, dal momento che coinvolge tre entità)

Associazioni Ogni associazione ha una cardinalità. La cardinalità viene specificata per ciascuna relazione che partecipa all’associazione. La cardinalità descrive, per ogni entità, il numero minimo e massimo di volte con cui un’istanza di un’entità può essere legata a istanze di altre entità coinvolte Esempio: un articolo può essere oggetto di zero o più vendite (cardinalità minima zero, massima N). Una vendita riguarda uno o più articoli (cardinalità minima 1, massima N). Se la cardinalità minima è zero si dice che la partecipazione dell’entità all’associazione è opzionale Se la cardinalità minima è uno si dice che la partecipazione dell’entità all’associazione è obbligatoria

Associazioni Le cardinalità massime consentono di classificare le associazioni binarie in base al tipo di corrispondenza: Associazione 1 : 1 o biunivoca (uno a uno). In questo caso la cardinalità massima per entrambe le entità coinvolte è pari ad uno Associazione 1 : N (uno a N o uno a molti). In questo caso un’entità dell’associazione ha cardinalità massima pari ad uno, l’altra pari ad N Associazioni N : M (N ad M o molti a molti). In questo caso entrambe le entità coinvolte nell’associazione hanno cardinalità massima pari a N

Associazioni: esempi Una persona deve essere residente in una sola città. In una città possono essere residenti o zero persone o molte persone Un cliente può effettuare più ordini (potrebbe anche non comprare niente). Un ordine deve essere effettuato da un solo cliente Un turista può prenotare zero o più viaggi. Un viaggio può essere prenotata da zero o più viaggiatori Persona Città Risiede in E’ residenza per

Attributi Gli attributi servono a descrivere le proprietà elementari di entità o associazioni. Dal contratto con l’utente scaturiscono le proprietà di interesse ai fini dell’applicazione. Una regola di costruzione degli schemi entità associazione, consiste nell’ individuare solo gli attributi elementari e non gli attributi che si possono ottenere con calcoli a partire dagli attributi elementari (esempio: il saldo di un conto corrente è un attributo derivato dalla somma algebrica dei movimenti (entrate ed uscite) sul conto) Ogni attributo associa ad ogni istanza di entità o relazione, un valore. Questo valore deve appartenere all’insieme specificato dall’attributo. Questo insieme si chiama dominio Al dominio di un attributo possono essere imposte dal committente restrizioni particolari. Il dominio non viene in genere rappresentato nello schema

Attributi Si definisce identificatore primario un attributo o un insieme di attributi tali che, dato un qualunque valore a questo attributo o insieme di attributi, si individua al più una ed una sola istanza dell’entità. Gli identificatori primari delle entità, vengono evidenziati graficamente sottolineando il loro nome o colorando il cerchio che li rappresenta. Cognome Nome Cliente Codice fiscale

Attributi Esempio di attributi di un’associazione Prenota zione Turista Viaggio Codice prenotazione Data

Modello E/R

Primo esempio Realizzare un’agenda elettronica. Si vuole memorizzare: un elenco di amici con un’indicazione del cognome, del nome e del telefono tutti gli appuntamenti del proprietario. Per ogni appuntamento si vuole memorizzare la data, l’ora ed il luogo dell’appuntamento nonchè la persona con cui si ha l’appuntamento. Realizzare l’agenda nelle seguenti ipotesi: ogni appuntamento è con un solo amico ogni appuntamento è con uno o più amici

Primo esempio Cognome Nome Amico Telefono Amico Va a Va a Codice È con Appuntamento È con Va a Amico Telefono Va a Codice È con Data Appuntamento Ora Luogo Codice

Secondo esempio Una società di formazione vuole memorizzare i dati anagrafici dei suoi corsisti e dei corsi che tiene. Per ogni corsista vuole memorizzare il suo numero di matricola, il suo cognome ed il suo nome, i voti presi negli esami sostenuti e le date in cui è assente. I corsi sono caratterizzati dal loro nome.

Secondo esempio Cognome Nome Corsista Matricola Fa Può sostenere Corso NomeCorso Codice È valutato con Relativo a Voto Esame Data Esame È fatta È sostenuto da CodiceEsame Assenza Data Codice

Terzo esempio Un commerciante vuole informatizzare la gestione delle sue attività. Egli desidera memorizzare: I clienti ed in particolare il cognome, il nome, la data di nascita, l’indirizzo e il codice fiscale. i fornitori ed in particolare il nome, l’indirizzo, il numero di telefono e la partita IVA della ditta del fornitore. gli articoli specificando una descrizione dell’articolo, la quantità presente in magazzino, la scorta minima, la quantità di riordino, il prezzo di acquisto, ed il prezzo di vendita e i fornitori dell’articolo. Un articolo può essere fornito da uno o più fornitori. Ogni fornitore può fornire più articoli. Il commerciante vuole anche archiviare l’elenco delle vendite ai clienti e degli acquisti dal fornitore. Ogni vendita è fatta ad un cliente in una determinata data e contiene l’elenco degli articoli venduti a quel cliente in quella data, con un articolo per riga. Il prezzo di vendita normalmente è pari al prezzo di acquisto dell’articolo più il 20 %, ma può essere modificato dall’utente purchè non scenda al di sotto del 10% del prezzo di acquisto. Gli acquisti sono effettuati da un fornitore in una determinata data e contengono l’elenco degli articoli acquistati in quella data, con un’indicazione, per ogni articolo, del prezzo di acquisto.

Terzo esempio Nome ditta Telefono Commerciante Codice fiscale Via Ind. La prima entità che si rileva dall’analisi dei requisiti è l’entità commerciante. Del commerciante devono essere quanto meno memorizzati: Il nome della ditta, l’ indirizzo, il telefono, la Partita Iva, l’indirizzo Web Nome ditta Commerciante Telefono Codice fiscale Via Ind. Numero IndWeb Partita Iva Interno Cliente Cognome Nome Codice fiscale Ind. Via Numero Interno Codice

Terzo esempio Descrizione Acquisto DataEvasione DataEmissione Codice Codice Riga Quantità RigaAcquisto PrezzoAcq.

Terzo esempio Associazioni tra entità: Un articolo è fornito da 1 o più fornitori ed un fornitore fornisce zero o più articoli (associazione 1 a M opzionale) Un acquisto è effettuato presso un fornitore che è destinatario di zero o più ordini di acquisto Un acquisto è composto da 1 o più rigaAcquisto che a sua volta é il dettaglio di un solo acquisto Una rigaAcquisto è compilata con un articolo. Un articolo può essere oggetto di zero o più righe acquisto Una vendita è effettuata ad un cliente. Un cliente riceve zero o più vendite Una vendita è composta da 1 o più rigaVendita che a sua volta é il dettaglio di una sola vendita Una rigaVendita è compilata con un articolo. Un articolo può essere oggetto di zero o più righe vendite Dalle entità e associazioni sopra descritte scaturisce il modello entità associazioni seguente

Effettuato presso Fornitore Commerciante Acquisto Destinatario di Composta da Fornitore di Dettaglio di RigaAcquisto Compilata con RigaVendita Compilata con Dettaglio di Fornito da Oggetto di Articolo Oggetto di Composta da Rivolta a Vendita Clienti Destinatario di

Modello concettuale: Descrizione operazioni Il modello entità associazioni é un modello concettuale usato per descrivere i dati. Nel progetto di un sistema informativo vanno anche descritte le operazioni da eseguire sui dati con particolare riferimento a come i dati vengono modificati, quando e con quale frequenza vengono modificati e da chi vengono modificati. Esistono vari modelli concettuali per rappresentare le operazioni da effettuare sui dati. Ogni insieme di modelli assieme al modello concettuale per la descrizione dei dati caratterizzano un sistema per la progettazione concettuale dei data base Ogni sistema di progettazione è caratterizzato dal suo insieme di modelli per rappresentare i dati e le operazioni su di essi. Un modello abbastanza completo per la progettazione dei sistemi informativi è il modello SSADM In questo modello le operazioni sui dati sono descritti con: data flow diagrams, entity function matrix, entity life histories

Modello logico Il modello concettuale rappresenta la prima fase di progettazione del data base. A partire dal modello concettuale dei dati è necessario passare ad un modello logico in cui si definisce come memorizzare i dati e con quale struttura. La scelta della struttura dati influenza sia l’organizzazione del data base (eliminare ridondanza dei dati e garantire la loro consistenza) sia la sua gestione (velocità delle operazioni di gestione: inserimento, modifica, cancellazione e ricerca di dati) La definizione del modello logico porta inevitabilmente ad una ristrutturazione del modello concettuale

Modelli logici: flat file Il modello logico più semplice di un data base è il modello che prevede un unico file (flat file): tutti i dati del nostro data base sono memorizzati in un unico file. Il modello flat file va bene solo per data base estremamente semplici (con una sola entità) I fogli elettronici sono ottimi strumenti per gestire data base con modello logico dei dati flat file. Excel ad esempio contiene numerose funzioni per gestire e manipolare i dati di un data base con struttura flat file: Elenchi, filtri e ordinamenti di elenchi Uso di data base esterni e Microsoft Query Analisi dei dati con tabelle pivot L’analisi dei dati what – if Analisi dei dati con ricerca obiettivo e risolutore L’analisi dei dati con strumenti di analisi statistica

Modelli logici: gerarchico Agente Cliente Ordine Ordine RigaOrdine RigaOrdine Articolo Articolo

Modelli logici: reticolare Figura di un modello reticolare Agente Cliente Ordine RigaOrdine Articolo

Modelli logici: relazionale Nel modello logico relazionale le informazioni sono logicamente memorizzate in tabelle. Una tabella è un insieme di righe e colonne. Ogni colonna della tabella ha un nome detto attributo. Ogni riga della tabella è detta ennupla e costituisce un’informazione di base. La tabella corrisponde alla relazione (relazione matematica). Le righe della tabella corrispondono agli elementi della relazione. I nomi delle colonne corrispondono ai nomi delle componenti della ennupla La chiave primaria della relazione è un attributo o un insieme di attributi che identifica univocamente una riga: non esistono due righe con lo stesso valore della chiave. Il modello relazionale impone il vincolo di integrità sulle entità per cui nessuna componente della chiave primaria può avere valore nullo

Modelli logici: relazionale Un modello relazionale gode delle seguenti proprietà: Ogni colonna contiene valori dello stesso attributo, sono quindi valori omogenei ovvero valori presi dallo stesso insieme o dominio. Ogni casella della tabella può contenere un solo valore (non un array di valori) Ogni colonna ha un nome univoco e l’ordine delle colonne è irrilevante Ogni riga è unica, ovvero non esistono righe con gli stessi valori per determinati attributi (che formano la chiave) Tute le righe della tabella contengono lo stesso numero di attributi. La sequenza delle righe è irrilevante Si definisce dominio l’insieme di possibili valori di un attributo In una tabella sono importanti due aspetti: L’insieme dei nomi delle colonne che formano lo schema della tabella Le righe che contengono le informazioni vere e proprie Il data base consiste in un insieme di tabelle corrispondenti alle entità. L’insieme degli schemi delle tabelle contenute nel data base si chiama schema del data base.

Dal modello concettuale al modello logico Per passare dal modello concettuale entità associazione al modello logico relazionale si applicano le seguenti regole: Ogni entità diventa una relazione Ogni attributo di un’entità diventa un attributo della relazione, ovvero il nome della colonna della relazione L’identificatore univoco di un’entità diventa la chiave primaria della relazione

Associazione 1 : 1 Impiegato Dipartimento Dirige E’ diretto Codice Le associazioni 1: 1 vengono rappresentate in una qualunque delle entità coinvolte, aggiungendo ad una delle entità coinvolte gli attributi delle associazioni. In generale non è conveniente rappresentare tutti i concetti delle entità e dell’associazione 1 : 1 in un’unica relazione in quanto il modello E/R è costruito effettuando delle scelte precise sugli eventuali accorpamenti di entità Impiegato Dipartimento Dirige E’ diretto Codice Cognome Nome Sede Direzione Data Inizio (0,1) (1,1) Impiegati (Codice, Cognome) Dipartimenti (Nome, Sede, Codice direttore, DataInizioDirezione) Impiegati (Codice, Cognome, DipartimentoDiretto, DataInizioDirezione) Dipartimenti (Nome, Sede)

Associazioni 1: 1 (0,1) (1,1) Impiegato Dipartimento Direzione Dirige Nel caso di associazione 1: 1 con partecipazione opzionale per una sola entità, conviene includere gli attributi dell’associazione nell’entità con partecipazione obbligatoria. Se gli attributi dell’associazione sono inclusi nell’entità con partecipazione facoltativa, si introduce la possibilità di valori nulli Viene introdotto il vincolo di integrità referenziale tra l’attributo CodiceDirettore della relazione Dipartimenti e l’attributo Codice della relazione Impiegati. (0,1) (1,1) Impiegato Dipartimento Direzione Dirige E’ diretto Codice Cognome Data Inizio Nome Sede Impiegati (Codice, Cognome) Dipartimenti (Nome, Sede, CodiceDirettore, DataInizioDirezione)

Associazioni 1: N (1,1) (0,N) Giocatore Squadra Contratto Gioca Nel caso di associazione 1: N l’entità che partecipa all’associazione con cardinalità massima pari a 1 viene tradotta in una relazione che contiene: Gli attributi dell’entità Gli identificatori delle entità che partecipano all’associazione Gli attributi dell’associazione L’associazione di partenza non viene rappresentata esplicitamente (1,1) (0,N) Giocatore Squadra Contratto Gioca E’ composta Ruolo Cognome Data nascita Data Inizio Nome Città Giocatori (Cognome, DataNascita, Ruolo, NomeSquadra, Data) Squadre (Nome, Città)

Associazioni 1: N (0,1) (0,N) Giocatore Squadra Contratto Gioca Nel caso in cui la cardinalità minima dell’entità dell’associazione lato uno è pari a zero (giocatori che non hanno contratti con una squadra) la traduzione dello schema può essere fatta secondo le regole delle associazioni N : M introducendo una relazione per l’associazione (0,1) (0,N) Giocatore Squadra Contratto Gioca E’ composta Ruolo Cognome Data nascita Data Inizio Nome Città Giocatori (Cognome, DataNascita, Ruolo) Squadre (Nome, Città) Contratto (CognomeGiocatore, DataNascitaGiocatore, NomeSquadra, DataInizioContratto) In questa traduzione abbiamo un numero superiore di relazione, ma non è possibile avere valori nulli nella relazione Giocatori. In generale la prima soluzione è la più usata poiché é più efficiente in termine di velocità di ricerche, ma occupa più spazio di memoria

Associazioni N: M (0,N) (0,N) Impiegato Partecipazione Progetto Nel caso di associazione N: M si ottiene: Una relazione per ogni entità partecipante alla relazione. Ogni relazione ha gli stessi attributi dell’entità di partenza, e per chiave l’identificatore dell’entità. Una relazione per rappresentare l’associazione. Questa relazione contiene come attributi: Gli identificatori delle entità coinvolte, che formano la chiave della nuova relazione Gli attributi della relazione (0,N) (0,N) Impiegato Partecipazione Progetto Partecipa E’ composto Matricola Cognome Data nascita DataInizio Codice Nome Impiegati (Matricola, Cognome, DataNascita) Progetti (Codice, Nome) Partecipazioni (MatricolaImpiegato, CodiceProgetto, DataInizio)

PROGETTO LOGICO DI UN DATA BASE Il progetto di un data base include la scelta delle tabelle necessarie per contenere i dati per consentire un efficiente e sicuro immagazzinamento dei dati ed una loro ricerca Il progetto deve definire: Le tabelle ed i loro nomi I nomi delle colonne (attributi) Le caratteristiche delle colonne (Valori unici o nulli, il tipo di dati) La chiave primaria di ogni tabella (un valore o un insieme di valori che identificano univocamente una riga) Le associazioni tra tabelle. Per definire un’associazione un attributo (o un insieme di attributi) in una tabella chiamato chiave esterna, è uguale (fa riferimento) a un attributo (o insieme di attributi) chiave primaria in un’altra tabella I vincoli di dominio, di entità, referenziale ed imposti dall’utente Gli indici per velocizzare le operazioni di ricerca dei dati I permessi e le autorizzazioni dei vari utenti o gruppi sulle singole tabelle

Primo esempio: Dal modello E/R al modello logico Entità amico genera la tabella Amici (CodiceAmico, Cognome, Nome, telefono) Entità appuntamento genera la tabella Appuntamenti (CodiceAppuntamento,Data, Ora, Luogo, CodiceAmico) Dove il CodiceAmico è stato aggiunto per realizzare l’associazione tra l’appuntamento e l’amico con cui si ha l’appuntamento. Nel caso in cui ad un appuntamento possono essere presenti più amici (un amico può essere presente a più appuntamenti) l’associa M: N tra l’entità amico e l’entità appuntamento si realizza introducendo una terza tabella Appuntamenti (CodiceAppuntamento, Data, Ora, Luogo) AmiciAdAppuntamenti (CodiceAppuntamento, CodiceAmico)

Secondo esempio: Dal modello E/R al modello logico Entità corsista genera la tabella Corsisti (Matricola, Cognome, Nome) Entità corso genera la tabella Corsi (CodiceCorso, NomeCorso) Entità assenza genera la tabella Assenze (CodiceAssenza, Data, Matricola) -Dove la Matricola è stata aggiunta per realizzare l’associazione tra l’assenza e il corsista che effettua l’assenza. Entità esame genera la tabella Esami (CodiceEsame, DataEsame, Matricola, CodiceCorso, Voto) -Dove la matricola è stata aggiunta per realizzare l’associazione tra l’esame e il corsista che sostiene l’esame. -Dove il CodiceCorso è stato aggiunto per realizzare l’associazione tra l’esame ed il corso a cui si riferisce.

Terzo esempio: Dal modello E/R al modello logico Entità commerciante genera la tabella Commercianti (PartitaIva, nomeDitta, telefono, codiceFiscale, Via, Numero, Interno, indWeb) Entità cliente genera la tabella Clienti (Codice, Cognome, Nome, CodiceFiscale, Via, Numero, Interno, Telefono) Entità fornitore genera la tabella Fornitori (Codice, Nome, Telefono, PartitaIva, Via, Numero, Interno) Entità articolo genera la tabella Articoli (Codice, Descrizione, Giacenza, ScortaMin, ScortaMax) Entità acquisto genera la tabella Acquisti (Codice, Descrizione, DataEvasione, DataEmissione, CodiceFornitore) -Dove il codice fornitore è stato aggiunto per realizzare l’associazione tra acquisto e fornitore Entità rigaAcquisto genera la tabella RigheAcquisto (CodiceRiga, CodiceAcquisto, CodiceArticolo, quantità, prezzoAcquisto) -Dove il codice acquisto è stato aggiunto per realizzare l’associazione tra acquisto e rigaAcquisto; il codiceArticolo è stato aggiunto per realizzare l’associazione tra la rigaAcquisto e l’articolo

Terzo esempio: dal modello E/R al modello logico Entità vendita genera la tabella Vendite (Codice, descrizione, Data, CodiceCliente) -Dove il codice cliente è stato aggiunto per realizzare l’associazione tra vendita e cliente Entità rigaVendita genera la tabella RigheVendite (CodiceRiga, Codicevendita, CodiceArticolo, quantità, prezzoVendita) -Dove il codice acquisto è stato aggiunto per realizzare l’associazione tra acquisto e rigaAcquisto; il codiceArticolo è stato aggiunto per realizzare l’associazione tra la rigaAcquisto e l’articolo Infine per realizzare l’associazione tra gli articoli e i loro fornitori (associazione N : M) introduciamo la tabella AcquistiFornitori (CodiceArticolo, CodiceFornitore)

Nozioni di algebra relazionale Matematicamente l’algebra relazionale, da cui il modello logico relazionale deriva, definisce varie operazioni. Gli operandi sono della relazioni che possono essere costanti (relazioni specifiche) o variabili (relazioni incognite) . Ogni operando è rappresentato dal suo schema (schema della relazione) Le operazioni dell’algebra relazionale si possono classificare in due categorie: Operazioni insiemistiche, cioè le operazioni dell’algebra degli insiemi applicate alle entità relazione e le Operazioni relazionali non presenti nell’algebra degli insiemi.

Operazioni insiemistiche Le operazioni più comuni sono quelle insiemistiche: Unione di due o più relazioni: unione insiemistica con il vincolo che gli operandi devono avere lo stesso schema. Il risultato ha lo stesso schema degli operandi Intersezione di due o più relazioni: intersezione insiemistica con il vincolo che gli operandi devono avere lo stesso schema. Il risultato ha lo stesso schema degli operandi Differenza di due o più relazioni: differenza insiemistica con il vincolo che gli operandi devono avere lo stesso schema. Il risultato ha lo stesso schema degli operandi

Operazioni relazionali Proiezione Proiezione: serve ad eliminare alcune colonne dallo schema di una relazione. L’operatore di proiezione ha come operandi una relazione ed una lista di attributi scelti tra quelli dello schema della relazione. Il risultato dell’operazione è una relazione che contiene solo gli attributi della lista. La cardinalità della relazione risultato è di norma la stessa a meno di righe uguali che vengono ridotte a una. Matematicamente: Sia R una relazione con attributi {A1, A2, … Ak} e (B1, .. Bn) una lista che contiene alcuni degli attributi di A, allora  B1, .. Bn ( R ) è la proiezione di R sugli attributi B1, .. Bn Esempi: nella relazione: Clienti (Codice, Cognome, Nome, DataNascita) Visualizzare un elenco di clienti contenente il loro Cognome, il nome e la data di nascita Proiezione di clienti su Cognome, Nome, DataNascita Cognome, Nome, DataNascita (Clienti)

Selezione Selezione: serve ad eliminare alcune righe dalla relazione. Viene usata in modo particolare per effettuare ricerche su una tabella. Ha come operandi una relazione ed una condizione logica. Il risultato è una relazione che contiene solo le ennuple della relazione di partenza che soddisfano la condizione data. Matematicamente se R è la relazione, C la condizione e  l’operatore di selezione allora c ( R) Nella condizione C: gli operandi possono essere attributi dello schema della relazione o costanti Gli operatori di C sono gli operatori di confronto (<, <=, >, >=, etc…) e gli operatori logici (and, or, not) Esempio: nella relazione: Clienti (Codice, Cognome, Nome, DataNascita) Trovare tutti i clienti nati prima del 1984 Selezione dei clienti per dataNascita < 1984 DataNascita < 1984 ( Clienti) Articoli (Codice, Descrizione, Giacenza, ScortaMin, ScortaMax) Trovare tutti gli articoli con giacenza inferiore alla scorta minima Selezione degli Articoli per Giacenza < ScortaMin Giacenza < scortaMin ( Articoli)

Composizione di operatori Gli operatori di proiezione e selezione possono anche comporsi matematicamente (come le funzioni composte) Esempio nella relazione Articoli (Codice, Descrizione, Giacenza, ScortaMin, ScortaMax) Trovare la descrizione di tutti gli articoli la cui Giacenza è minore della scorta Minima: Proiezione della selezione degli articoli per Giacenza minore della Scorta Minima sulla descrizione  Descrizione ( Giacenza < scortaMin ( Articoli) )

Giunzione Giunzione: serve per ottenere dati tra due o più relazioni che presentano associazioni tra di loro. Nel modello logico le associazioni tra due entità si ottengono inserendo in una relazione R la chiave primaria di un’altra relazione S (attributo che diventa chiave esterna nella relazione R). Le due relazioni R ed S hanno quindi uno o più attributi in comune La giunzione serve per ottenere dati dalle due relazioni che hanno uno o più attributi in comune. Il risultato è una relazione che contiene la composizione delle ennuple delle due relazioni con valori uguali negli attributi comuni

Giunzione Matematicamente: Sia R una relazione con attributi {A1, A2, … AN} e S una relazione con attributi (B1, .. BM), siano Ai e Bj due attributi comuni alle due relazioni; questi attributi diventano i parametri dell’operatore di giunzione. La giunzione di R e di S, R  Ai =Bj S viene costruita: prendendo ogni ennupla r di R ed ogni ennupla s di S e confrontandole. Se la componente AI di R e la componente BJ di S sono uguali allora si ottiene una ennupla appartenente alla giunzione costituita da tutti gli attributi di R seguiti da tutti gli attributi di S ad eccezione di Bj, in quanto è uguale ad AI. Lo schema del risultato è quindi la relazione G (A1, A2, … AN , B1 , … BJ-1, BJ+1, … BM) Ovvero l’insieme degli attributi di R e di S escluso Bj. Se nella sequenza di attributi risultante dovessero comparire attributi con nomi uguali è possibile rinominarli Questo tipo di giunzione viene chiamata giunzione naturale (natural join ) o inner join

Giunzione Giunzione di Esempi: nella relazione: Amici (Codice, Cognome, Nome, Telefono) Appuntamenti (CodiceAppuntamento, Data, Ora, Luogo, CodiceAmico) Visualizzare l’elenco degli appuntamenti con gli amici il cui cognome è specificato dall’utente: dato il cognome di un amico trovare tutti gli appuntamenti avuti con lui Proiezione di Selezione di amici per cognome = Cognome inserito Su Giunzione di Amici e appuntamenti su Amico.codice = Appuntamenti.codiceAmico Su Cognome, nome, telefono, data, ora e luogo Amico.Cognome, Amico.nome, Amico.Telefono, Appuntamento.Data, Appuntamento.Ora, Appuntamento.luogo (amico.cognome = cognome inserito (Amici Amico.codice = Appuntamenti.Codice Appuntamenti)) Oppure Giunzione di Su Amici e appuntamenti con Amico.codice = Appuntamenti.codiceAmico

Normalizzazione Una forma normale è una proprietà di una base di dati relazionale che ne garantisce la “qualità”, cioè l'assenza di determinati difetti Quando una relazione non è normalizzata: presenta ridondanze, si presta a comportamenti poco desiderabili durante gli aggiornamenti Le forme normali sono di solito definite sul modello relazionale, ma hanno senso in altri contesti, ad esempio il modello E-R

Normalizzazione Procedura che permette di trasformare schemi non normalizzati in schemi che soddisfano una forma normale La normalizzazione va utilizzata come tecnica di verifica dei risultati della progettazione di una base di dati Non costituisce una metodologia di progettazione

Una relazione con anomalie

Anomalie Lo stipendio di ciascun impiegato è ripetuto in tutte le ennuple relative ridondanza Se lo stipendio di un impiegato varia, è necessario andarne a modificare il valore in diverse ennuple anomalia di aggiornamento Se un impiegato interrompe la partecipazione a tutti i progetti, dobbiamo cancellarlo anomalia di cancellazione Un nuovo impiegato senza progetto non può essere inserito anomalia di inserimento

Perché questi fenomeni indesiderabili? abbiamo usato un'unica relazione per rappresentare informazioni eterogenee gli impiegati con i relativi stipendi i progetti con i relativi bilanci le partecipazioni degli impiegati ai progetti con le relative funzioni

Per studiare in maniera sistematica questi aspetti, è necessario introdurre un vincolo di integrità: la dipendenza funzionale

Proprietà Ogni impiegato ha un solo stipendio (anche se partecipa a più progetti) Ogni progetto ha un bilancio Ogni impiegato in ciascun progetto ha una sola funzione (anche se può avere funzioni diverse in progetti diversi)

Dipendenza funzionale relazione r su R(X) due sottoinsiemi non vuoti Y e Z di X esiste in r una dipendenza funzionale (FD) da Y a Z se, per ogni coppia di ennuple t1 e t2 di r con gli stessi valori su Y, risulta che t1 e t2 hanno gli stessi valori anche su Z

Impiegato Progetto  Funzione Notazione XY Esempi: Impiegato  Stipendio Progetto  Bilancio Impiegato Progetto  Funzione

Altre FD Impiegato Progetto  Progetto Si tratta però di una FD “banale” (sempre soddisfatta) Y  A è non banale se A non appartiene a Y Y  Z è non banale se nessun attributo in Z appartiene a Y

Proprietà delle dipendenze funzionali X, Y, Z sono insiemi di attributi della relazione R. Valgono le seguenti proprietà: Riflessività Se X contiene Y, allora X  Y (FD banale) Aumento Se X  Y, vale anche XZ  YZ Transitività Se X  Y e Y  Z allora X  Z Proprietà derivata: unione Se X  Y e X  Z allora X  YZ

Inferenza di dipendenze funzionali Utilizzando le proprietà viste è possibile arricchire l’insieme di FD a partire da un insieme iniziale di FD La chiusura di un insieme F di dipendenze funzionali è l’insieme di dipendenze funzionali che possono essere inferite da F con le proprietà viste È possibile inoltre trovare la chiusura di un insieme di attributi X secondo un insieme di D.F. F, cioè l’insieme W di tutti gli attributi per cui la dipendenza X  W appartiene alla chiusura di F

Definizione di chiave Sia R una relazione e U l’insieme di attributi del suo schema L’insieme di attributi X è chiave di R se: La chiusura di X corrisponde a U Non esiste nessun sottoinsieme Y di X, per cui la chiusura di Y è ancora uguale a U

Le anomalie sono legate ad alcune FD gli impiegati hanno un unico stipendio Impiegato  Stipendio i progetti hanno un unico bilancio Progetto  Bilancio

Non tutte le FD causano anomalie In ciascun progetto, un impiegato svolge una sola funzione Impiegato Progetto  Funzione Il soddisfacimento è più "semplice"

Impiegato Progetto  Funzione Una differenza fra FD Impiegato  Stipendio Progetto  Bilancio causano anomalie Impiegato Progetto  Funzione non causa anomalie Perché?

Impiegato Progetto  Funzione Impiegato  Stipendio Progetto  Bilancio Impiegato Progetto  Funzione

FD e anomalie La terza FD corrisponde ad una chiave e non causa anomalie Le prime due FD non corrispondono a chiavi e causano anomalie La relazione contiene alcune informazioni legate alla chiave e altre ad attributi che non formano una chiave

abbiamo usato un'unica relazione per rappresentare informazioni eterogenee gli impiegati con i relativi stipendi i progetti con i relativi bilanci le partecipazioni degli impiegati ai progetti con le relative funzioni

Impiegato Progetto  Funzione Impiegato  Stipendio Progetto  Bilancio Impiegato Progetto  Funzione Impiegato Progetto è chiave Impiegato solo no Progetto solo no Le anomalie sono causate dalla presenza di concetti eterogenei: proprietà degli impiegati (lo stipendio) proprietà di progetti (il bilancio) proprietà della chiave Impiegato Progetto

Forma normale di Boyce e Codd (BCNF) Una relazione r è in forma normale di Boyce e Codd se, per ogni dipendenza funzionale (non banale) X  Y definita su di essa, X contiene una chiave K di r La forma normale richiede che i concetti in una relazione siano omogenei (solo proprietà direttamente associate alla chiave)

Che facciamo se una relazione non soddisfa la BCNF? La rimpiazziamo con altre relazioni che soddisfano la BCNF Come? Decomponendo sulla base delle dipendenze funzionali, al fine di separare i concetti

Non sempre è così facile Impiegato  Sede Progetto  Sede

Decomponiamo sulla base delle dipendenze

Proviamo a ricostruire Diversa dalla relazione di partenza!

Decomposizione senza perdita Una relazione r si decompone senza perdita su X1 e X2 se il join delle proiezioni di r su X1 e X2 è uguale a r stessa (cioè non contiene ennuple spurie) Se le relazioni decomposte sono due, vale la seguente proprietà: la decomposizione senza perdita è garantita se gli attributi comuni contengono una chiave per almeno una delle due relazioni decomposte Se le relazioni decomposte sono più di due, si può eseguire un semplice test (vedere testo Ullman, Basi di Dati e Basi di Conoscenza)

Proviamo a decomporre senza perdita Impiegato  Sede Progetto  Sede

Un altro problema Supponiamo di voler inserire una nuova ennupla che specifica la partecipazione dell'impiegato Neri, che opera a Milano, al progetto Marte Impiegato  Sede Progetto  Sede

Effettuando la join delle relazioni decomposte si ottiene la seguente relazione. La FD Progetto  Sede risulta essere violata!

Conservazione delle dipendenze Una decomposizione conserva le dipendenze se ciascuna delle dipendenze funzionali dello schema originario coinvolge attributi che compaiono tutti insieme in uno degli schemi decomposti Progetto  Sede non è conservata

Qualità delle decomposizioni Una decomposizione dovrebbe sempre soddisfare: la decomposizione senza perdita, che garantisce la ricostruzione delle informazioni originarie la conservazione delle dipendenze, che garantisce il mantenimento dei vincoli di integrità originari

Una relazione non-normalizzata Progetto Sede  Dirigente Dirigente  Sede

La decomposizione è problematica Progetto Sede  Dirigente coinvolge tutti gli attributi e quindi nessuna decomposizione può preservare tale dipendenza quindi in alcuni casi la BCNF “non è raggiungibile”

Una nuova forma normale Una relazione r è in terza forma normale se, per ogni FD (non banale) X  Y definita su r, è verificata almeno una delle seguenti condizioni: X contiene una chiave K di r ogni attributo in Y è contenuto in almeno una chiave di r

BCNF e terza forma normale la terza forma normale è meno restrittiva della forma normale di Boyce e Codd (e ammette relazioni con alcune anomalie) ha il vantaggio però di essere sempre “raggiungibile”

Decomposizione in terza forma normale La decomposizione dipende dalle dipendenze funzionali individuate Si crea una relazione per ogni gruppo di attributi coinvolti in una dipendenza funzionale: così si garantisce la conservazione delle dipendenze Si verifica che alla fine una relazione contenga una chiave della relazione originaria, altrimenti si aggiunge una relazione che abbia questa proprietà. Questo garantisce la decomposizione denza perdite.

Una possibile strategia se la relazione non è normalizzata si decompone in terza forma normale alla fine si verifica se lo schema ottenuto è anche in BCNF Se una relazione ha una sola chiave allora le due forme normali coincidono

Uno schema non decomponibile in BCNF Dirigente  Sede Progetto Sede  Dirigente

Una possibile riorganizzazione Dirigente  Sede Reparto Sede Reparto  Dirigente Progetto Sede  Reparto

Decomposizione in BCNF Progetto Sede Reparto Marte Roma 1 Giove Milano Saturno 2 Venere Dirigente Rossi Verdi Neri

Progettazione e normalizzazione la teoria della normalizzazione può essere usata nella progettazione logica per verificare lo schema relazionale finale si può usare anche durante la progettazione concettuale per verificare la qualità dello schema concettuale

PartitaIVA  NomeFornitore Indirizzo Codice Nome prodotto Indirizzo Prodotto Partita IVA Prezzo PartitaIVA  NomeFornitore Indirizzo

PartitaIVA  NomeFornitore Indirizzo Analisi dell’entità L’entità viola la terza forma normale a causa della dipendenza: PartitaIVA  NomeFornitore Indirizzo Possiamo decomporre sulla base di questa dipendenza

Nome prodotto Partita IVA Nome fornitore Codice (0,N) (1,1) Fornitura Prodotto Fornitore Prezzo Indirizzo

Dipartimento Tesi Professore Studente Corso di laurea (0,1) Tesi Professore Studente (0,N) Corso di laurea Studente  Corso di laurea Studente  Professore Professore  Dipartimento

Analisi della relationship La relationship viola la terza forma normale a causa della dipendenza: Professore  Dipartimento Possiamo decomporre sulla base di questa dipendenza

Afferenza Dipartimento Tesi Professore Studente Corso di laurea (1,1) (0,N) (0,1) Tesi Professore Studente (0,N) Corso di laurea

Ulteriore analisi sulla base delle dipendenze La relationship Tesi è in BCNF sulla base delle dipendenze Studente  CorsoDiLaurea Studente  Professore le due proprietà sono indipendenti questo suggerisce una ulteriore decomposizione

Professore Studente Tesi Dipartimento Afferenza Corso di laurea (0,1) Dipartimento Afferenza (1,1) Corso di laurea Corso di laurea Iscrizione (0,N) (1,1)

STRUMENTI DI ANALISI DI ACCESS ANALIZZATORE TABELLE: CONSENTE DI ANALIZZARE UNA TABELLA ALLA VOLTA E DI PROPORRE UNA NUOVA STRUTTURA PER LA TABELLA, O DI DIVIDERLA IN PIU’ TABELLE ASSOCIATE SE NECESSARIO ANALIZZATORE DI PRESTAZIONI: ANALIZZA L’INTERO DATA BASE E FORNISCE CONSIGLI E SUGGERIMENTI (IMPLEMENTABILI CON LA CREAZIONE GUIDATA)

TIPI DI INTEGRITA’ DEI DATI Integrità di dominio o integrità di colonna: specifica un insieme di dati validi per una colonna, e determina se valori null sono consentiti. Viene ottenuta per mezzo di: controlli di validità (validity checking); restrizioni sul tipo di dati restrizioni sul formato restrizioni sul range

TIPI DI INTEGRITA’ DEI DATI Gli insiemi di valori con cui è possibile denotare gli elementi di una colonna sono: interi; reali; booleani; caratteri; intervalli di interi e caratteri; stringhe di caratteri; testo, immagine, definiti dall’utente.

TIPI DI INTEGRITA’ DEI DATI Integrità di entità o integrità di tabella: richiede che tutte le righe in una tabella abbiano un identificatore univoco (primary key). Se il valore della chiave primaria può essere modificato o se l’intera riga può essere cancellata dipende dal livello di integrità richiesto tra la chiave primaria e le altre tabelle Integrità definite dall’utente Consente di definire specifiche regole di business che non cadono in una delle precedenti categorie di integrità. Per creare integrità definite dall’utente si possono usare: -constraints -stored procedure -triggers

TIPI DI INTEGRITA’ DEI DATI Integrità referenziale: garantisce che la relazione tra la chiave primaria (di una tabella a cui si fa riferimento) e la chiave esterna (foreign key) in ogni tabella referente (che fa riferimento alla tabella contenente alla chiave primaria), sia sempre mantenuta una riga nella tabella a cui si fa riferimento non può essere cancellata, né la chiave primaria modificata, se una chiave esterna fa riferimento a quella riga una riga non può essere aggiunta ad una tabella che fa riferimento ad un’altra tabella se il valore della chiave esterna della tabella referente non coincide con il valore della chiave primaria della tabella a cui si fa riferimento (esempio: non si può creare un ordine (tabella che fa riferimento) per un cliente che non esiste