LA PROGETTAZIONE DI UN DATABASE IL DISEGNO RELAZIONALE

Fin dall'antichità l'uomo ha sempre avuto bisogno di memorizzare ed elaborare informazioni. Che fossero parole o numeri poco importava, quello che serviva era uno strumento per far sì che queste informazioni non fossero affidate solo alla memoria umana, ma continuassero ad esistere e ad essere disponibili a tutti. INTRODUZIONE

Prima dell'avvento dei computer l'unico supporto su cui era possibile memorizzare i dati era la carta (fogli, libri, ecc.) con tutte le limitazioni che essa comportava Con l'introduzione dei computer le cose migliorarono decisamente si cominciarono a studiare metodi e sistemi di gestione delle informazioni tali da ottimizzarne la ricerca e l'elaborazione.

Si sentì quindi il bisogno di organizzare il contenuto dei file in maniera organica; perché ciò fosse possibile furono realizzati dei programmi che generavano DATABASE, vale a dire dei file in cui i dati erano memorizzati secondo precisi criteri di omogeneità e sequenzialità. Sulla base di tali criteri i suddetti programmi furono poi in grado di ricercare ed elaborare i dati con notevole velocità.

Un DBMS (Data Base Management System) è un programma in grado di generare ed elaborare uno o più DATABASE, cioè uno o più file in cui i dati relativi a determinate entità (animali, persone, prodotti, fatture, ecc.) sono organizzati secondo i seguenti criteri: - ciascun elemento appartenente all'entità viene descritto da un RECORD (riga); - ogni record è suddiviso in CAMPI (colonne), ciascuno dei quali contiene un attributo (caratteristica) della suddetta entità.

Un database di clienti, ad esempio, può contenere i seguenti campi che descrivono le caratteristiche di ciascun cliente: - codice cliente - nome - cognome - indirizzo - città - CAP

Cercando di ottimizzare le prestazioni dei programmi DBMS ci si accorse ben presto che i database, così come erano strutturati, contenevano molti dati inutilmente ripetuti. Dovendo archiviare gli ordini dei clienti, ad esempio, era necessario ripetere per ogni ordine i dati anagrafici dei clienti che avevano effettuato più di un ordine.

Se, in aggiunta, si volevano memorizzare le fatture emesse, ecco che i dati anagrafici dei clienti dovevano essere di nuovo ripetuti, con un evidente spreco di tempo degli operatori e di spazio sui dischi dei computer.

Si cercò allora il modo di ovviare a questo inconveniente progettando dei programmi in grado di archiviare i dati in contenitori differenti, in base alla loro natura: le cosiddette TABELLE, e di mettere queste tabelle in relazione tra loro, secondo le necessità. Nacquero così gli RDBMS (Relational Data Base Management System). |

Nelle suddette tabelle ciascun record è contraddistinto da un campo contenente un identificatore univoco (un dato che compare una volta soltanto nell'intera tabella); questo identificatore viene utilizzato nelle altre tabelle, invece di ripetere per intero il record che lo contiene.

Se ad esempio, ogni cliente contenuto nella tabella anagrafica dei clienti viene identificato da un numero progressivo (ID Cliente), nella tabella degli ordini e in quella delle fatture emesse sarà sufficiente inserire questo numero invece di ripetere ogni volta tutti i dati anagrafici del cliente.

Programma del corso l Partiamo da un semplice esempio... l Il modello relazionale l I vantaggi della tecnologia relazionale l Il processo di progettazione di un database l La “normalizzazione” di un database

Partiamo da un semplice esempio... l Desideriamo costruire l’archivio dei nostri contatti. l Si tratta di persone che normalmente operano in azienda l Possono svolgere ruoli diversi l Vogliamo rintracciarle per azienda o per nome

I ipotesi: organizzazione “piatta” per azienda L’archivio è organizzato per azienda Vengono predeterminati gli incarichi previsti

I ipotesi: organizzazione “piatta” per azienda: i problemi l Alcuni incarichi potrebbero non esistere in particolari aziende l Come memorizzare un nominativo che non lavora in nessuna azienda? l E se bisogna inserire un ruolo non previsto (ad esempio il portinaio!)? In realtà questo approccio risulta: –POCO FLESSIBILE –MOLTO COSTOSO IN TERMINI DI SPAZIO

II ipotesi: organizzazione “piatta” per persona PersonaAziendaRuolo Bertasi RenzoFlower s.p.a.Amm. Del. Ferrini FrancaFlower s.p.a.Dir. Gen. Martini MarcoMartini s.r.l.Dir. Amm. Martini MarioMartini s.r.l.Amm. Del. Noaro FlavioFlower s.p.a.Dir. Comm. l L’archivio è organizzato per persona l Per ogni persona viene memorizzato il ruolo e l’azienda in cui opera l I dati dell’azienda sono replicati tante volte quante sono le persone

II ipotesi: organizzazione “piatta” per persona: i problemi l Vi è una inutile e costosa ripetizione delle informazioni l Quante modifiche sono necessarie se cambia la ragione sociale dell’azienda? Questo approccio è: –molto flessibile –presenta grosse difficoltà di gestione

Il modello relazionale Aziende Ragione Sociale Partita IVA Indirizzo Pagamento Banca Persone Cognome Nome Indirizzo Ruolo Cellulare Aziende e Persone sono classi di entità diverse della realtà, che devono essere descritte indipendentemente l’una dall’altra

Il modello relazionale l Presuppone il riconoscimento del tipo di legame, cioè di relazione, che lega le diverse entità del fenomeno che si intende rappresentare

Il modello relazionale Costruire un database relazionale significa quindi: –Individuare i dati elementari –Identificare le entità (tabelle) –Individuare, per ogni entità, la CHIAVE –Scoprirne le relazioni –Creare un modello della realtà che faccia riferimento alle entità individuate ed alle loro relazioni

Il modello relazionale l Garantisce espandibilità e flessibilità nella costruzione del modello e delle applicazioni che ne derivano l Elimina la necessità di duplicare i dati

Le Tabelle l Le informazioni relative ad una classe di entità vengono memorizzate in una struttura chiamata TABELLA l La Tabella è organizzata in righe (RECORD) e colonne (CAMPI) l Ogni campo identifica una proprietà dell’entità ed assume in ogni record un valore specifico l Ogni riga identifica un elemento dell’insieme delle entità. In ogni riga viene registrata l’informazione relativa a una specifica entità

Le Tabelle CAMPI o COLONNE RECORDRECORD

Costruzione del modello Per costruire un modello relazionale bisogna poter associare, se due tabelle (entità) sono in relazione, ogni record di una tabella con il record corrispondente della tabella collegata. Quanti tipi di relazione possono esistere?

Relazione “uno a uno” l Ad ogni record di una tabella principale è associato al più un record della tabella relazionata: Posti numerati Galleria 1 Galleria 2 Platea 1 Platea 2 Platea 3 Prenotazioni numerate Patrizia Giovanna Isabella

Relazione “uno a uno” l I posti esistono anche se non ci sono prenotazioni l Ogni prenotazione è relativa ad un posto (deve esistere il record corrispondente nella tabella POSTI) l Non possono esserci più prenotazioni per lo stesso posto

Relazione “uno a molti” l Ad ogni record di una tabella possono essere associati nessuno o molti record di una tabella collegata, ma ad ogni record di questa è associato sempre un’unico record di quella d’origine Clienti Rossi s.p.a. Bianchi s.r.l. Verdi s.n.c. Ordini

Relazione “molti a molti” l Ogni record di una tabella può essere associato a molti record della tabella collegata, e viceversa Clienti Rossi s.p.a. Bianchi s.r.l. Verdi s.n.c. Prodotti Penne Matite Carta Inchiostro Calamai

Come vengono create le relazioni l Relazioni 1 a 1 e 1 a molti –In ogni record della tabella relazionata si deve inserire il riferimento al record corrispondente della tabella principale

Come vengono create le relazioni l Relazioni molti a molti intermedia –bisogna creare una tabella intermedia, legata con una relazione “uno a molti” con entrambe le tabelle originarie Clienti Rossi s.p.a. Bianchi s.r.l. Verdi s.n.c. Prodotti Penne Matite Carta Inchiostro Calamai Ordini

La “Chiave Primaria” l E’ quindi necessario poter identificare in maniera univoca ogni record della tabella principale della relazione l Questo compito è svolto dalla CHIAVE PRIMARIA l La chiave primaria garantisce l’unicità del record: non ci possono essere due record di una tabella con la stessa chiave primaria

La “Chiave Primaria” l Le tabelle collegate (relazionate) conterranno un campo dove viene indicata la chiave primaria del record della tabella principale l Questo campo viene chiamato CHIAVE ESTERNA

La “Chiave Primaria” l La chiave primaria può consistere in un singolo campo: –Tabella FATTURE > CP Numero fatt. l in una combinazione di campi: –Tabella CITTA’ -----> CP Latitud. + Longitud. – PV + NUM (targhe) l in un valore esterno (artificiale): –Tabella CLIENTI ---> CP Codice cliente

Esempio di relazione tra tabelle (uno a molti) CodRag. SocialeIndirizzo 001Rossi s.p.a.V.le Monza, Verdi s.n.c.P.zza Garibaldi, 6 003Bianchi s.r.l.Via Palladio, 2 DataNumeroCod. cliente 2/5/ /5/ /5/ TABELLA CLIENTI TABELLA ORDINI

Gli indici l Una tabella è naturalmente ordinata: –secondo l’ordine di inserimento dei record se la tabella non ha una chiave primaria –secondo la chiave primaria se esiste l Tuttavia i record di una tabella devono poter essere ordinati secondo un qualsiasi campo, in senso crescente o decrescente; questa funzione è svolta dagli indici

Gli indici l Un INDICE è uno strumento che mantiene costantemente ordinati i record di una tabella secondo i campi su cui è applicato l L’insieme dei record ordinati non è una nuova tabella, ma un “altro punto di vista” della tabella stessa.

Gli indici l Se esiste un indice corrispondente al criterio di ordinamento, l’elenco è ordinato in ogni momento –viene rallentato l’aggiornamento, ma l’ordinamento è immediato l Se non esiste un indice, i record vengono ordinati quando ciò viene richiesto –è più veloce l’aggiornamento, ma è lento l’ordinamento

Gli indici l Di conseguenza conviene associare un indice ai metodi di ordinamento utilizzati di frequente: –elenco clienti in ordine alfabetico --> indice associato –elenco dipendenti in ordine di età --> nessun indice associato

La progettazione di un DB 1.Identificare gli oggetti (entità) ---> TABELLE 2.Scoprire le relazioni ---> RELAZIONI TRA TABELLE 3.Determinare le proprietà --> CAMPI 4.Controllare la validità dei dati inseriti 5.Individuare gli indici adatti 6.Gestire la sicurezza (accessi in lettura/scrittura) 7. Documentare l’applicazione

Approcci alla progettazione l Bottom - up –Applicazione --> Schema (analisi)--> Database –Analisi limitata agli aspetti inerenti all’applicazione l Top - down –Realtà --> Analisi --> Database --> Applicazioni –Analisi completa della realtà e generazione della applicazioni come conseguenza

I vantaggi dei DB relazionali l Il disegno dei dati è indipendente dalle applicazioni e viene mantenuto aggiornato l Il linguaggio di accesso al DB è standarizzato (SQL - QBE) l Il motore del database è intercambiabile l E’ semplificato l’accesso al DB da applicazioni standard (Microsoft Office)

Controllare la validità dei dati l Definire il tipo di dato di ogni campo –numero intero o con la virgola, testo, data, valuta, oggetto, ecc. l Definire i limiti dei valori del campo –massimo e minimo di un numero, lunghezza di un testo, ecc. l Aspetti formali (maiuscolo e minuscolo) l Controllare un valore in funzione di un altro campo

L’integrità referenziale l Gestire l’integrità referenziale significa: –rendere impossibile cancellare un record o modificarne la chiave primaria se esso ha dei record collegati in un’altra tabella l Ciò impedisce la possibilità che esistano record della tabella collegata che fanno riferimento a record della tabella principale che non esistono

L’integrità referenziale Quando si applica l’integrità referenziale non è possibile: l aggiungere record ad una tabella relazionata se nella tabella principale non esistono record associati l modificare i record della tabella principale che genererebbero record isolati in una tabella correlata l eliminare record dalla tabella principale se in una tabella correlata sono inclusi dei record correlati corrispondenti

Regole da seguire l Relazionare ogni campo al soggetto della tabella –un campo che descrive il soggetto di un’altra tabella appartiene all’altra tabella l Non inserire nella tabella valori calcolati l Indicare i campi nelle loro più piccole suddivisioni logiche

La normalizzazione del DB l La normalizzazione è un processo formalizzato di costruzione e verifica del DB che garantisce la correttezza della progettazione e grazie a ciò: –la semplicità –la flessibilità –la manutenibilità –la capacità analitica delle applicazioni costruite sul DB

I forma normale: campi ripetitivi l Richiede che le tabelle siano “piatte” e che non contengano gruppi ripetitivi: una tabella piatta ha solo due dimensioni - lunghezza (numero dei record) e larghezza (numero dei campi) e non può contenere caselle di dati con più di un solo valore

II forma normale: dipendenza da CP l Richiede che i dati contenuti in tutte le colonne non chiave siano completamente dipendenti dalla chiave primaria: –ciò significa che i valori dei dati in ogni colonna siano determinati univocamente dal valore della chiave primaria

III forma normale: indipendenza dei campi l Richiede che tutte le colonne (campi) non chiave siano dipendenti dalla chiave primaria ed indipendenti tra loro

IV forma normale: no relazioni “molti a molti” l Richiede che le entità dei dati indipendenti non siano contenute nella stessa tabella quando esistono delle relazioni “molti a molti” tra quelle entità

V forma normale l Richiede che deve essere possibile la ricostruzione della tabella di origine dalle tabelle in cui essa è stata scomposta –questa operazione viene eseguita per mezzo di “query”

Ora quanto abbiamo capito ? RIPRENDIAMO ALCUNI CONCETTI CHIAVE: ENTITA’ TABELLE RELAZIONI CHIAVE PRIMARIA, CHIAVE ESTERNA INDICI ITER DI PROGETTAZIONE INTEGRITA’ REFERENZIALE NORMALIZZAZIONE

I database relazionali: un esempio

Cos’è Access l Access è un DBMS, cioè una applicazione nata per gestire delle grosse quantità di dati. l Per realizzare questo compito, è necessario che i dati abbiano una loro strutturazione ben definita e retta da regole l Quindi Access consente di definire queste regole e di creare sui dati delle vere e proprie applicazioni per scopi specifici (applicazioni verticali)

SVILUPPATORE: colui che crea l’applicazione UTENTE: la persona che utilizza l’applicazione, potrebbe essere anche un neofita di computer. Con Access si fa ingresso nella categoria di sviluppatori di applicazioni che verranno utilizzate da persone con poca o nessuna esperienza di computer. ACCESS serve anche per creare APPLICAZIONI Una applicazione è un database automatizzato, lo scopo è creare un prodotto che tutti possano utilizzare, anche le persone che non sanno nulla di Access. ACCESS E I DUE PUNTI DI VISTA

Perché usare un RDBMS come Access? l Perché si hanno molte informazioni da gestire e magari e si vogliono organizzare e razionalizzare l Perché si vogliono utilizzare gli stessi dati per molti scopi diversi l Perché le informazioni devono essere condivise tra molti utilizzatori (utenti) l Perché si vuole garantire la correttezza dei dati (tramite dei meccanismi automatici di input) l Perché si vuole rendere le informazioni disponibili solo a chi serve e “nascoste” agli altri

Access Base: Contenuti l Definizioni: che cos’è un database e che cos’è Access l Progettare un database l L’interfaccia e gli oggetti di Access l Tabelle, dati e tipi di dati l Relazioni, chiave primaria e chiave straniera l Dai dati alle informazioni: le Query l Importazioni ed esportazioni semplici l Input e output con Maschere (schede) e Report