1.1 I componenti di un DBMS... 5

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "1.1 I componenti di un DBMS... 5"

Transcript

1 Indice 1 Introduzione ai DBMS Scopi di un DBMS Modelli dei dati Schemi e Istanze Linguaggi per basi di dati Data Definition Language Data Manipulation Language Architettura di un DBMS Progettazione Concettuale Introduzione Uno strumento per la progettazione concettuale: il modello E/R Entità Relazioni o Associazioni Attributi Costruzione di schemi con i costrutti di base Cardinalità delle relazioni Cardinalità degli attributi Identificatori o chiavi delle entità Generalizzazioni Documentazione degli schemi E/R Ulteriori usi degli schemi E/R Regole di progettazione concettuale Esercizi Esercizio Esercizio

2

3 Elenco delle figure 1.1 I componenti di un DBMS Alcuni esempi di entità Un esempio di Relazione Tra le stesse entità vi possono essere diverse relazioni Tra le istanze di una relazione non vi possono essere ennuple ripetute Due esempi di relazione ricorsiva Un esempio di relazione ternaria Esempio di attributi Esempio di attributo composto Esempio di schema complesso Esempio di cardinalità di relazione Vari tipi di cardinalità Esempio di cardinalità di attributo Modellazione alternativa di alcune cardinalità di attributi Rappresentazione degli identificatori in uno schema E/R Rappresentazione di una chiave esterna in uno schema E/R Raffinamento dello schema complesso di Figura Rappresentazione delle generalizzazioni

4

5 Elenco delle tabelle 2.1 Dizionario delle Entità Dizionario delle Relazioni Annotazioni allo schema E/R

6

7 1 Introduzione ai DBMS Questo capitolo ha lo scopo di introdurre lo studente al mondo dei database. Innanzitutto verranno esaminati gli scopi di un database; successivamente verranno introdotti alcuni concetti fondamentali, quali quelli di modello dei dati, schemi e istanze, linguaggi per basi di dati. La lezione si chiude con una descrizione, semplificata, dell architettura di un DBMS. 1.1 Scopi di un DBMS Un DataBase Management System (DBMS) consiste in una collezione di dati correlati e in un insieme di programmi per accedere questi dati. Le collezioni dei dati, generalmente denominati database, contengono informazioni su una determinata organizzazione. Il primo scopo di un DBMS è quello di fornire un ambiente che è sia conveniente che efficiente da usare nel recupero e nella memorizzazione delle informazioni. I DBMS sono stati progettati per gestire grandi quantità di informazioni. La gestione delle informazioni comporta tanto la definizione di strutture per la loro memorizzazione che di meccanismi per la loro manipolazione. Inoltre, un DBMS deve gestire la sicurezza delle informazioni memorizzate, ovvero deve essere capace di far fronte sia a crash del sistema che ad accessi non autorizzati. Un DBMS deve essere capace di gestire, in modo corretto ed efficiente, la condivisione dei dati tra diversi utenti. Per comprendere meglio tutte queste problematiche consideriamo il seguente esempio. Supponiamo di dover gestire l informatizzazione di una filiale di una banca che mantiene informazioni sui clienti e sui conti. Un modo per mantenere l informazione su un computer è quello di memorizzarla in file permanenti. Per consentire agli utenti di manipolare le informazioni, il sistema deve avere un certo numero di programmi applicativi che manipolano i file corrispondenti; tra questi programmi dovranno necessariamente essere presenti: un programma per la gestione dei depositi e dei prelievi; un programma per aggiungere un nuovo conto; un programma per calcolare il saldo di un conto; un programma per generare gli estratti conto. Questi programmi applicativi vengono scritti da programmatori in risposta alle necessità della banca. Nuovi programmi applicativi vengono aggiunti al sistema mano a mano che nascono nuove necessità (si pensi, ad esempio, ai programmi per la gestione dei conti on line). Così, con il passare del tempo, più file e più programmi applicativi vengono aggiunti al sistema. I file che compongono il sistema sono supportati da un sistema operativo convenzionale. Le informazioni di interesse vengono memorizzate in vari file; inoltre, vengono scritti diversi programmi applicativi per estrarre o inserire nuovi dati nei file appropriati. Prima dell avvento dei DBMS le organizzazioni memorizzavano le informazioni utilizzando tipicamente tali sistemi.

8 2 1 Introduzione ai DBMS Questo modo di gestire le informazioni comporta, però, alcuni grossi svantaggi. Più specificatamente, vi possono essere: Ridondanze ed inconsistenze dei dati. Dal momento che i file e i programmi applicativi vengono scritti, nel tempo, da programmatori differenti, i vari file avranno probabilmente formati differenti e i programmi possono essere scritti in diversi linguaggi di programmazione. Inoltre, la stessa informazione può essere duplicata in diversi posti. Per esempio, l indirizzo e il numero di telefono di un particolare cliente può apparire nel file dei conti e, ad esempio, nel file dei depositi. Tale ridondanza porta a dei costi di memorizzazione e di accesso più alti. Inoltre, essa può portare ad inconsistenza dei dati, ovvero le varie copie degli stessi dati potrebbero differire. Ad esempio, il cambiamento dell indirizzo di un cliente può essere stato registrato nel file dei conti e non in quello dei depositi. Difficoltà nell accedere ai dati. Si supponga che uno degli impiegati bancari debba selezionare i nomi di tutti i clienti che vivono nella parte di città con CAP L impiegato chiede al dipartimento di elaborazione dei dati di generare tale lista. Poichè tale richiesta non è stata prevista quando il sistema originale è stato progettato, non vi è alcun programma applicativo già pronto per soddisfarlo. C è, tuttavia, un programma applicativo per generare la lista di tutti i clienti. L impiegato bancario ha ora due scelte: o ottiene la lista di tutti i clienti ed estrae da questa manualmente l informazione desiderata oppure chiede al dipartimento di elaborazione dei dati di scrivere un opportuno programma applicativo. Entrambe le alternative sono, ovviamente, insoddisfacenti. Si supponga che tale programma sia stato scritto e che, alcuni giorni dopo, lo stesso impiegato deve aggiornare la lista per includere solo quei clienti che hanno un saldo maggiore di euro. Chiaramente, un programma per aggiornare tale lista non esiste. Ancora una volta l impiegato ha le due opzioni precedenti, nessuna delle quali è soddifacente. Il punto qui è che i tradizionali ambienti per l elaborazione dei file non permettono un recupero conveniente ed efficiente delle informazioni di interesse. Isolamento dei dati. Poichè i dati sono distribuiti su più file e questi possono avere formati differenti, è difficile scrivere nuovi programmi applicativi per recuperare le informazioni desiderate. Problemi di integrità. I valori dei dati memorizzati nel database devono soddisfare alcuni vincoli di integrità. Per esempio, il bilancio di un conto in banca non può mai scendere al di sotto di un valore prescritto (diciamo, 25 euro). Per controllare che tali vincoli vengano rispettati, gli sviluppatori dovranno aggiungere del codice appropriato nei vari programmi applicativi. Tuttavia, se vi è la necessità di aggiungere nuovi vincoli, sarà necessario cambiare i programmi aggiungendo nuovo codice per controllare che i vincoli stessi vengano rispettati. Ciò risulta essere molto difficile. Tale attività diventa particolarmente complessa quando i vincoli coinvolgono diversi dati provenienti da file differenti. Problemi di atomicità. Un computer, come qualunque altro dispositivo meccanico o elettronico, è soggetto a guasto. In molte applicazioni è cruciale assicurarsi che, una volta che è avvenuto un guasto e che lo stesso è stato individuato, i dati vengano riportati all ultimo stato consistente esistente prima del guasto. Si consideri, a titolo di esempio, un programma per trasferire 50 euro dal conto A al conto B. Se accade un guasto nel sistema durante l esecuzione del programma è possibile che 50 euro vengano rimossi dal conto A ma non accreditati nel conto B, comportando una inconsistenza nel database. Chiaramente è essenziale, per la consistenza del database, che vengano registrati sia gli accrediti che gli addebiti oppure che non vengano registrati nessuno dei due. In altre parole, il trasferimento dei fondi deve essere un operazione atomica, cioè deve avvenire nella sua interezza o non deve avvenire affatto. È difficile assicurare tale proprietà con un file system tradizionale. Anomalie nell accesso concorrente. Affinchè si possa migliorare la performance complessiva del sistema, ottenendo un tempo di risposta alle interrogazioni minore, molti sistemi consentono a più utenti di aggiornare simultaneamente i dati. In tali ambienti l interazione di aggiornamenti concorrenti può portare a dati inconsistenti. Si consideri un conto A che contiene 500 euro. Se due clienti prelevano soldi (diciamo 50 euro e 100 euro, rispettivamente) dal conto A nello stesso istante, il risultato dell esecuzione concorrente può lasciare il conto in uno stato incorretto (o inconsistente).

9 1.3 Schemi e Istanze 3 Si supponga che i programmi che gestiscono il prelievo leggano il vecchio saldo, riducono il valore della quantità da prelevare e riscrivano il risultato. Se i due programmi vengono eseguiti concorrentemente essi possono entrambi leggere il valore 500 euro e scrivere di nuovo 450 euro e 400 euro, rispettivamente. A seconda di chi scrive il valore, il conto può contenere 450 euro oppure 400 euro, piuttosto che il valore corretto di 350 euro. Per affrontare tale problema il sistema deve mantenere qualche forma di supervisione. Poichè i dati possono essere acceduti da programmi applicativi che non sono stati precedentemente coordinati, la supervisione è difficile da garantire. Problemi di sicurezza. Non tutti gli utenti del DBMS dovrebbero essere capaci di accedere a tutti i dati. Per esempio, in un sistema bancario, il personale che gestisce i pagamenti deve vedere solo la parte del database che contiene informazioni sui vari impiegati bancari. Esso non deve accedere ad informazioni sui conti dei clienti. Tali vincoli di sicurezza possono essere difficilmente garantiti con una gestione basata sui file dal momento che che, in questo caso, è difficile controllare tutti i programmi ad-hoc che, via via, vengono aggiunti al sistema. Queste difficoltà, tra le altre, hanno stimolato lo sviluppo dei DBMS. 1.2 Modelli dei dati Un modello dei dati è un formalismo matematico composto da due parti: una notazione per descrivere i dati; un insieme di operazioni per manipolare i dati. I modelli si suddividono in: Modelli concettuali; essi vengono utilizzati per descrivere i dati in maniera completamente indipendente dalla struttura del DBMS sottostante; tali modelli non sono disponibili su DBMS commerciali. Il loro nome deriva dal fatto che essi tendono a descrivere i concetti del mondo reale, piuttosto che i dati utili a rappresentarli. I modelli concettuali vengono utilizzati durante la fase preliminare del processo di progettazione di basi di dati, per analizzare nel modo migliore la realtà di interesse, senza preoccuparsi del DBMS con cui questa viene successivamente rappresentata. Il più importante modello concettuale è il modello Entità/Relazione. Modelli logici; essi sono gli effettivi modelli di riferimento per i vari DBMS; essi descrivono la realtà avendo come riferimento una strutturazione concreta dei dati (ad alberi, a grafi, a tabelle, ad oggetti). Modelli logici molto comuni sono il modello gerarchico, quello reticolare, quello relazionale e quello orientato agli oggetti. Il modello gerarchico è basato sull utilizzo di strutture ad albero, e quindi di gerarchie. Esso è stato definito agli albori della teoria delle basi di dati. Il modello reticolare (detto anche CODASYL, dal comitato di standardizzazione che lo definì con precisione) è stato sviluppato successivamente al modello gerarchico ed è basato sull uso dei grafi. Il modello relazionale rappresenta la realtà di interesse per mezzo di relazioni. Una relazione si può rappresentare mediante una tabella le cui righe rappresentano specifiche istanze e le cui colonne corrispondono a specifiche proprietà; l ordine delle righe e delle colonne è sostanzialmente irrilevante. Il modello ad oggetti, sviluppato negli anni 80 come evoluzione del modello relazionale, estende alle basi di dati il paradigma di programmazione orientata agli oggetti. 1.3 Schemi e Istanze Nelle basi di dati esiste una parte sostanzialmente invariante nel tempo, detta schema della base di dati, che definisce le caratteristiche e la struttura dei dati, ed una parte variabile nel tempo, detta istanza o stato della base di dati, che memorizza i valori effettivi. Ad esempio, consideriano un fornitore. Il corrispondente schema è dato dal codice, dal nome e dall indirizzo. Scriveremo:

10 4 1 Introduzione ai DBMS FORNITORE(Codice, Nome, Indirizzo) Le istanze rappresentano gli effettivi fornitori. Ad esempio: 1 Rossi Reggio Calabria 2 Bianchi Cosenza 3 Verdi Roma Lo schema prende anche il nome di componente intensionale della base di dati mentre le istanze rappresentano la sua componente estensionale. 1.4 Linguaggi per basi di dati Ad un DBMS possono essere associate due diverse tipologie di linguaggi: una tipologia viene utilizzata per definire lo schema della base di dati mentre l altra viene utilizzata per gestire l aggiornamento dei dati e la loro interrogazione Data Definition Language Uno schema di basi di dati viene specificato mediante un insieme di definizioni espresso mediante uno speciale linguaggio denominato Data Definition Language (DDL). Il risultato della compilazione delle istruzioni DDL è un insieme di tabelle che viene memorizzato in un file speciale denominato dizionario dei dati o directory dei dati. Un dizionario dei dati è un file che contiene metadati, ovvero dati sui dati. Tale file deve essere consultato dalle applicazioni prima che esse leggano o modifichino i dati effettivi del database Data Manipulation Language Per manipolazione dei dati intendiamo: l estrazione delle informazioni memorizzate nel database; l inserimento di nuove informazioni nel database; la cancellazione di informazioni dal database; la modifica di informazioni precedentemente memorizzate nel database. Un Data Manipulation Language (DML) è un linguaggio che permette agli utenti di accedere e manipolare i dati. Esistono fondamentalmente due tipologie di DML: I DML procedurali che richiedono ad un utente di specificare non solo quali sono i dati desiderati ma anche le modalità tramite cui recuperarli. I DML non procedurali che richiedono ad un utente di specificare quali sono i dati desiderati senza dover indicare le modalità tramite cui recuperarli. I DML non procedurali sono generalmente più facili da imparare e da utilizzare rispetto a quelli procedurali. Tuttavia, dal momento che un utente non deve specificare come recuperare i dati, essi possono generare codice che non è così efficiente come quello prodotto dai linguaggi procedurali. Una query è un istruzione che richiede l estrazione di informazioni. La porzione di un DML che si occupa dell estrazione delle informazioni viene denominata Query Language. Sebbene non sia tecnicamente corretto, è pratica comune utilizzare i termini Query Language e Data Manipulation Language come sinonimi.

11 1.5 Architettura di un DBMS 5 Istruzioni dell Utente Programma Applicativo Schema del Database Tabella delle Autorizzazioni Query Language Processor Database Manager Compilatore DDL Tabelle di Descrizione Tabella per il Controllo della Concorrenza File Manager Database Fisico Figura 1.1. I componenti di un DBMS 1.5 Architettura di un DBMS La Figura 1.1 illustra come interagiscono i linguaggi e i vari componenti di un DBMS. In alto a destra vediamo lo schema del database che, sottoposto al compilatore DDL, produce una descrizione interna del database. Le modifiche allo schema del database sono molto rare, rispetto alla frequenza con cui vengono eseguite le interrogazioni o altre manipolazioni. In un database multi-utente di notevoli dimensioni, tali modifiche vengono normalmente effettuate da un Database Administrator. Nella figura vediamo anche il Query Language Processor che riceve i programmi di manipolazione dei dati da due fonti: una fonte è costituita dalle istruzioni dell utente (per effettuare interrogazioni oppure operazioni di manipolazione) immesse direttamente dal terminale. La seconda fonte è data dai programmi applicativi, nei quali le istruzioni di interrogazione e di manipolazione dei dati vengono inserite in un linguaggio host e sottoposte al pre-processore per essere successivamente eseguite. Le parti di un programma applicativo scritte in un linguaggio host vengono gestite dal compilatore di tale linguaggio. Le parti di un programma applicativo costituite da istruzioni del linguaggio di manipolazione dei dati vengono gestite dal Query Language Processor che è responsabile dell ottimizzazione delle istruzioni stesse. Le istruzioni DML che estraggono i dati dal database, specialmente le query, sono spesso trasformate in modo significativo dal Query Language Processor in modo tale che possano essere eseguite più efficientemente rispetto a quanto accadrebbe se venissero eseguite così come sono scritte. Dalla figura si vede che il Query Language Processor accede alle tabelle di descrizione del database: queste sono state create dal compilatore DDL per avere alcune informazioni utili per l ottimizzazione delle interrogazioni, in particolare per conoscere l esistenza o meno di determinati indici. Al di sotto del Query Language Processor opera il Database Manager, il cui ruolo è quello di ricevere i comandi espressi ad alto livello di astrazione e di tradurli in comandi espressi a basso livello, in modo tale che gli stessi possano essere compresi dal File Manager. Il Database Manager gestisce la Tabella delle Autorizzazioni e la Tabella per il Controllo della Concorrenza. La Tabelle delle Autorizzazioni permette al Database Manager di controllare che l utente abbia il permesso di eseguire l interrogazione proposta o di modificare il database. Le variazioni a questa tabella vengono effettuate dal Database Manager in risposta a comandi effettuati da utenti adeguatamente autorizzati. La Tabella per il Controllo della Concorrenza consente di gestire l accesso contemporaneo agli stessi dati da parte di più programmi di interrogazione e manipolazione. Più specificatamente, qualunque istruzione volta a modificare una relazione deve poter bloccare (lock) la relazione stessa fino al suo completamento; è necessario, cioè, evitare che vi possano essere istruzioni simultanee e in conflitto tra di loro. La Tabella per il Controllo della Concorrenza viene utilizzata proprio per memorizzare i lock attivi.

12 6 1 Introduzione ai DBMS Il Database Manager traduce i programmi sottomessi dal Query Language Processor in operazioni sui file, che vengono gestite dal File Manager. Questo può essere un File System general purpose dotato di tutte le operatività del sistema, oppure un sistema specializzato. Per esempio, un File Manager specializzato può provare a porre in un unico cilindro di un disco quelle parti di un file a cui è probabile si acceda come ad un unica entità. Ciò minimizza il tempo di accesso ai dati dal momento che è possibile leggere l intera unità spostando la testina del disco soltanto una volta. Come altro esempio di File Manager specializzato consideriamo un File Manager che ottimizza la gestione della concorrenza. Tale tipologia di File Manager sarebbe particolarmente interessante in quanto, se è possibile associare lock a dati con granularità fine, si consentirà a più processi concorrenti di accedere al database. Se, per esempio, si pone un lock a livello dei singoli blocchi che costituiscono un grande file, diversi processi saranno in grado di accedere e modificare simultaneamente il file, se i dati di loro interessi si trovano in blocchi diversi del file.

13 2 Progettazione Concettuale In questo capitolo viene trattata la progettazione concettuale di una base di dati. Dopo una breve introduzione, ci concentreremo sullo strumento ancora più utilizzato per gestire tale progettazione, ovvero il modello E/R. Dopo di ciò esamineremo il Diagramma delle Classi di UML che, oramai, sta affiancando, ed in alcuni casi sostituendo, il modello E/R. Al termine illustreremo le regole da adottare per condurre con successo la progettazione concettuale di una specifica realtà. 2.1 Introduzione La progettazione concettuale di una base di dati consiste nella costruzione di uno schema concettuale in grado di descrivere al meglio la realtà di interesse. Anche nel caso di applicazioni non particolarmente complesse, lo schema che si ottiene può contenere molti concetti correlati in una maniera piuttosto complicata. Ne consegue che la costruzione dello schema finale è, necessariamente, un processo graduale: il nostro schema concettuale viene progressivamente raffinato e arricchito attraverso una serie di trasformazioni ed eventuali correzioni. La progettazione vera e propria è preceduta dalla raccolta e dall analisi dei requisiti. Questa fase non è completamente separata dalla progettazione, ma procede in molti casi parallelamente ad essa. Possiamo, infatti, definire uno schema concettuale quando non abbiamo ancora terminato di raccogliere e analizzare tutti i requisiti, per poi arricchirlo progressivamente man mano che le informazioni in nostro possesso aumentano. Il modello concettuale che noi utilizzeremo è il modello Entità/Relazione; questo è, sicuramente, il modello concettuale più utilizzato da coloro che operano in questo contesto. Esamineremo, comunque, anche il Diagramma delle Classi di UML che oramai sta affiancando, e in alcuni casi sostituendo, il modello Entità/Relazione. 2.2 Uno strumento per la progettazione concettuale: il modello E/R Il modello Entità/Relazione (E/R) è un modello concettuale di dati e fornisce una serie di strutture, detti costrutti, atte a descrivere la realtà di interesse in modo facilmente comprensibile e prescindendo dai criteri di organizzazione dei dati negli elaboratori. I costrutti messi a disposizione del modello E/R vengono utilizzati per definire schemi che rappresentano una specifica realtà secondo un determinato modello. Per ciascun costrutto del modello E/R esiste una rappresentazione grafica; essa consente di definire uno schema E/R mediante un opportuno diagramma che ne facilita la sua comprensione Entità Un entità è una classe di oggetti (fatti, persone) che hanno proprietà comuni ed esistenza autonoma ai fini dell applicazione di interesse; esempi di entità sono Città, Impiegato, Dipartimento. Un istanza di entità è un oggetto della classe rappresentata dall entità. Ad esempio, Roma e Milano sono istanze di Città mentre Rossi è istanza di Impiegato.

14 8 2 Progettazione Concettuale Un istanza di entità ha un esistenza ed un identità indipendente dalle proprietà ad essa associate. In questo senso, il modello E/R differisce da altri modelli, quali quello relazionale, in cui un oggetto è rappresentato dall insieme delle sue proprietà. In uno schema, ciascuna entità ha un nome che la identifica univocamente e viene rappresentata graficamente mediante un rettangolo con il nome dell entità all interno. In Figura 2.1 viene mostrata la rappresentazione grafica di alcune entità. Città Impiegato Dipartimento Vendita Figura 2.1. Alcuni esempi di entità Relazioni o Associazioni Le relazioni o associazioni rappresentano legami logici tra due o più entità. Risiede è un esempio di relazione che può sussistere tra Città e Impiegato. Un istanza di relazione è un ennupla (coppia nel caso più frequente di relazione binaria) costituita da istanze di entità, una per ciascuna delle entità coinvolte. La coppia di oggetti composta dall impiegato Rossi e dalla città di Roma è un esempio di istanza della relazione Risiede. In uno schema E/R ciascuna relazione ha un nome che la identifica univocamente e viene rappresentata graficamente mediante un rombo, con il nome della relazione all interno e con linee che lo connettono a ciascuna delle entità coinvolte (Figura 2.2). Città Risiede Impiegato Figura 2.2. Un esempio di Relazione Possono esistere relazioni diverse che coinvolgono le stesse entità, come le relazioni Risiede e Lavora tra le entità Città e Impiegato (Figura 2.3). Risiede Impiegato Città Lavora Figura 2.3. Tra le stesse entità vi possono essere diverse relazioni Tra le istanze di una relazione del modello E/R non vi possono essere ennuple ripetute. Questo aspetto ha importanti conseguenze. Per capire una delle più importanti consideriamo la Figura 2.4: in questo caso la relazione Segue non è in grado di descrivere il fatto che un determinato studente ha seguito più volte lo stesso corso. In tal caso, la frequenza andrebbe rappresentata mediante una entità legata mediante relazioni alle entità Studente e Corso. È anche possibile avere relazioni ricorsive, ovvero relazioni tra un entità e se stessa. Per esempio, nella Figura 2.5, la relazione ricorsiva Conosce sull entità Persona connette coppie di persone che si

15 2.2 Uno strumento per la progettazione concettuale: il modello E/R 9 Studente Segue Corso Figura 2.4. Tra le istanze di una relazione non vi possono essere ennuple ripetute conoscono, mentre la relazione Succede sull entità Sovrano associa a ciascun sovrano di una dinastia il suo immediato successore. Conosce Predecessore Succede Successore Persona Sovrano Figura 2.5. Due esempi di relazione ricorsiva Va osservato che la relazione Succede non è simmetrica. In questo caso è necessario specificare i due ruoli che l entità coinvolta gioca nella relazione: ciò può essere fatto associando degli identificatori (nel nostro caso Successore e Predecessore) alle linee uscenti dalla relazione ricorsiva. È possibile, infine, avere relazioni che coinvolgono più di due entità. Un esempio di ciò si ha nella Figura 2.6; la relazione Fornisce tra le entità Fornitore, Prodotto e Dipartimento descrive il fatto che ciascun fornitore può fornire un determinato prodotto ad un determinato dipartimento. Un possibile insieme di istanze di questa relazione potrebbe stabilire che la ditta Rossi fornisce Stampanti al dipartimento Vendite e Calcolatori al dipartimento Sviluppo, mentre la ditta Bianchi fornisce Calcolatori al dipartimento Ricerca e Fotocopiatrici al dipartimento Vendite. Fornitore Prodotto Fornisce Dipartimento Figura 2.6. Un esempio di relazione ternaria Attributi Gli attributi descrivono proprietà elementari di entità o relazioni di interesse ai fini dell applicazione. Per esempio, Cognome, Stipendio ed Età sono possibili attributi dell entità Impiegato, mentre Data e Voto lo sono per la relazione Segue tra Studente e Corso. Un attributo associa a ciascuna istanza di entità (o di relazione) un valore appartenente ad un insieme, detto dominio dell attributo, che contiene i valori ammissibili. Per esempio, l attributo Cognome dell entità Impiegato può avere come dominio l insieme delle stringhe di 20 caratteri. Nella Figura 2.7 viene mostrata la rappresentazione grafica degli attributi. I domini non vengono riportati nello schema ma sono generalmente descritti nella documentazione associata Può risultare comodo raggruppare attributi di una medesima entità o relazione che presentano affinità nel loro significato o uso: l insieme di attributi che si ottiene in questo modo viene denomi-

16 10 2 Progettazione Concettuale Data Esame Voto Matricola Anno di Iscrizione Studente Segue Corso Nome Anno di Corso Figura 2.7. Esempio di attributi nato attributo composto. Possiamo, per esempio, raggruppare gli attributi Via, Numero Civico e CAP dell entità Persona per formare l attributo composto Indirizzo. La rappresentazione grafica di un attributo composto viene mostrata nella Figura 2.8. Cognome Persona Età Sesso Via Indirizzo Numero Civico CAP Figura 2.8. Esempio di attributo composto Per ridurre la complessità degli schemi, nel seguito, gli attributi composti verranno usati raramente, preferendo usare, per quanto possibile, attributi atomici Costruzione di schemi con i costrutti di base I tre costrutti del modello E/R visti fino a questo momento ci consentono già di costruire schemi per descrivere realtà di una certa complessità. Si consideri, ad esempio, lo schema E/R di Figura 2.9. Dirige Codice Cognome Stipendio Età Impiegato Dipartimento Nome Telefono Afferisce Data Inizio Partecipa Data Afferenza Composta da Nome Budget Data Consegna Progetto Sede Città Via Numero Civico CAP Figura 2.9. Esempio di schema complesso Si comprende facilmente che questo schema rappresenta alcune informazioni di carattere organizzativo relative ad un azienda con diversi siti. Partendo dall entità Sede e procedendo in senso antiorario si può vedere che una sede dell azienda è dislocata in una città e ha un certo indirizzo (attributi Città e Indirizzo). Ciascuna sede è organizzata in dipartimenti (relazione Composta Da) e ciascun dipartimento ha un nome e un numero di telefono. A questi dipartimenti afferiscono, a partire da una certa data, gli impiegati dell azienda (relazione Afferisce e relativo attributo); vi sono impiegati che dirigono tali dipartimenti (relazione Dirige). Per gli impiegati vengono rappresentati il cognome, lo stipendio, l età e un codice che serve ad identificarli (entità Impiegato e relativi attributi).

17 2.2 Uno strumento per la progettazione concettuale: il modello E/R 11 Gli impiegati lavorano su progetti a partire da una certa data (relazione Partecipa e relativo attributo). Ciascun progetto ha un nome, un budget e una data di consegna (entità Progetto e relativi attributi) Cardinalità delle relazioni Le cardinalità delle relazioni vengono specificate per ciascuna entità che partecipa ad una relazione e descrivono il numero minimo e massimo di istanze di relazione a cui le istanze delle entità coinvolte possono partecipare. Esse dicono, quindi, quante volte, in una relazione tra entità, un occorrenza di una di queste entità può essere legata a occorrenze delle altre entità coinvolte nella relazione. Si consideri, ad esempio, la Figura In essa ad un impiegato deve essere assegnato almeno un incarico ma non più di cinque. Un determinato incarico può non essere assegnato a nessun impiegato oppure può essere assegnato a un numero di impiegati inferiore o uguale a 50. Impiegato (1,5) (0,50) Assegnato a Incarico Figura Esempio di cardinalità di relazione La cardinalità minima e massima delle entità di una relazione in uno schema E/R vengono specificate tra parentesi. Le cardinalità delle relazioni costituiscono dei vincoli di integrità, ovvero proprietà che occorrenze di entità e di relazioni devono soddisfare per poter essere considerate valide. In linea di principio è possibile assegnare un qualunque intero non negativo a una cardinalità di una relazione con l unico vincolo che la cardinalità minima deve essere minore o uguale di quella massima. In realtà, nella maggior parte dei casi, è sufficiente utilizzare solo tre valori: 0, 1 o il simbolo N (che indica, genericamente, un intero maggiore di 1). Per la cardinalità minima, i valori generalmente adottati sono 0 oppure 1; nel primo caso si dice che la partecipazione dell entità relativa è opzionale, nel secondo si dice che tale partecipazione è obbligatoria. Per la cardinalità massima, i valori generalmente utilizzati sono 1 oppure N. Consideriamo la Figura Osservando le cardinalità massime, è possibile classificare le relazioni binarie in base al tipo di corrispondenza che viene stabilita tra le istanze delle entità coinvolte. Ordine (0,1) (1,1) Relativo a Fattura Persona (1,1) (0,N) Risiede Città Turista (1,N) Prenota (0,N) Viaggio Figura Vari tipi di cardinalità Le relazioni aventi cardinalità massima pari ad 1 per entrambe le entità coinvolte, come la relazione Relativo a, definiscono una corrispondenza 1 ad 1 tra tali entità e vengono, quindi, denominate relazioni uno ad uno. In maniera analoga, le relazioni aventi un entità con cardinalità massima pari ad 1 e l altra con cardinalità massima pari ad N, come la relazione Risiede, vengono denominate relazioni uno a molti. Le relazioni aventi cardinalità massima pari ad N per entrambe le entità coinvolte, come la relazione Prenota, vengono denominate relazioni molti a molti.

18 12 2 Progettazione Concettuale Per le cardinalità minime va detto, invece, che il caso di partecipazione obbligatoria per tutte le entità coinvolte è piuttosto raro, perchè quando si aggiunge una nuova istanza di entità molto spesso non sono note le corrispondenti istanze di entità collegate attraverso relazioni. Per esempio, quando si riceve un nuovo ordine, non esiste ancora una fattura ad esso relativa e non è, quindi, possibile costruire un occorrenza della relazione Vende che contiene il nuovo ordine. Nelle relazioni n-arie le entità coinvolte partecipano quasi sempre con cardinalità massima pari ad N. Un esempio concreto viene fornito dalla relazione ternaria Fornisce; in questo esempio le istanze di ciascuna delle entità coinvolte partecipano a più istanze di tale relazione. Nel caso in cui un entità partecipa ad una relazione n-aria con cardinalità massima pari ad 1, si ha che che ogni sua occorrenza può essere legata ad una sola occorrenza della relazione e, quindi, ad un unica n-upla di occorrenze delle altre entità coinvolte nella relazione. Ciò implica che è possibile eliminare la relazione n-aria mediante delle procedure di normalizzazione che vedremo successivamente Cardinalità degli attributi Le cardinalità di un attributo descrivono il numero minimo e massimo di valori dell attributo associati a ciascuna occorrenza di entità o di relazione. Nella maggior parte dei casi la cardinalità di un attributo è pari a (1,1) e viene omessa. In questi casi l attributo rappresenta sostanzialmente una funzione che associa ad ogni occorrenza di entità uno ed un solo valore. Il valore per un certo attributo può essere nullo oppure possono esistere diversi valori di un determinato attributo associati ad un occorrenza di entità. Queste situazioni possono essere rappresentate associando all attributo in questione una cardinalità minima pari a 0 nel primo caso ed una cardinalità massima pari ad N nel secondo. Si consideri l esempio di Figura 2.12; in esso una persona ha uno ed un solo cognome, può avere o non avere un numero di patente, ma se ne ha uno è unico, può non avere automobili, ma può anche possedere più di una. Persona (0,N) (0,1) Targa automobile Cognome Numero patente Figura Esempio di cardinalità di attributo Le cardinalità degli attributi costituiscono dei vincoli di integrità, ovvero proprietà che occorrenze di entità e di relazione devono soddisfare per poter essere considerate valide. Un attributo con cardinalità minima pari a 0 è opzionale per la relativa entità, mentre è obbligatorio se la cardinalità minima è pari ad 1. Diremo, infine, che l attributo è multivalore se la sua cardinalità massima è pari ad N. In molte situazioni reali accade che alcune informazioni non sono disponibili ed è, quindi, utile avere la possibilità di specificare attributi opzionali. Gli attributi multivalore vanno, invece, utilizzati con maggiore cautela, perchè essi rappresentano situazioni che possono essere modellate, in alcune occasioni, con entità a sè, legate da relazioni uno a molti (o molti a molti) con l entità cui si riferiscono. Ad esempio, abbiamo detto che una persona può avere più automobili. L automobile è comunque un concetto a sè e può essere condiviso da altre entità: può risultare, quindi, più naturale modellarlo con un entità a parte legata all entità Persona da una relazione uno a molti (si veda la Figura 2.13). Il discorso verrà approfondito successivamente. Nome Numero Patente (0,1) Persona (0,N) Possiede (0,1) Automobile Figura Modellazione alternativa di alcune cardinalità di attributi

19 2.2.7 Identificatori o chiavi delle entità 2.2 Uno strumento per la progettazione concettuale: il modello E/R 13 Gli identificatori o chiavi delle entità descrivono i concetti dello schema che permettono di identificare in maniera univoca le occorrenze delle entità. In molti casi, uno o più attributi di un entità sono sufficienti ad individuare un identificatore: si parla, in questo caso, di identificatore interno (detto anche chiave). Per esempio, la targa è chiave per un automobile e gli attributi nome, cognome e data di nascita formano una chiave per una persona. In uno schema E/R gli identificatori si rappresentano come specificato nella Figura Targa Cognome Automobile Modello Persona Nome Data di Nascita Colore Indirizzo Figura Rappresentazione degli identificatori in uno schema E/R Alcune volte, però, gli attributi di un entità non sono sufficienti ad identificare univocamente le sue occorrenze. Si consideri, per esempio, l entità Studente in Figura Può sembrare, a prima vista, che l attributo Matricola possa essere un identificatore per tale entità; tuttavia, ciò non è vero: lo schema descrive, infatti, studenti iscritti a varie università e due studenti iscritti ad università diverse possono avere lo stesso numero di matricola. In questo caso, per identificare univocamente uno studente serve, oltre al numero di matricola, anche la relativa università. Quindi, un identificatore corretto per l entità Studente in questo schema è costituito dall attributo Matricola e dall entità Università. Questa identificazione è resa possibile dalla relazione uno a molti tra le entità Università e Studente, che associa ad ogni studente una ed una sola università. Quindi un entità E può essere identificata da altre entità solo se queste ultime sono coinvolte in relazioni a cui E partecipa con cardinalità (1,1). Nei casi in cui l identificazione di un entità è ottenuta utilizzando altre entità si parla di identificatore esterno. La rappresentazione diagrammatica di un identificatore esterno è riportata nella Figura Matricola Anno Cognome Studente (1,1) (1,N) Iscritto Università Nome Città Indirizzo Figura Rappresentazione di una chiave esterna in uno schema E/R Un identificazione esterna può coinvolgere diverse entità (purchè legate con relazioni cui l entità partecipa con cardinalità pari a (1,1)). Un identificazione esterna può coinvolgere un entità che è, a sua volta, identificata esternamente, purchè non vengono generate, in questo modo, cicli di identificazioni esterne (perchè, in questo caso, non sarebbe più possibile identificare alcuna entità). Concludendo il nostro discorso sugli identificatori osserviamo che ogni entità deve avere almeno un identificatore (interno o esterno), ma ne può avere in generale più di uno; nel caso di più identificatori, gli attributi e le entità coinvolte in alcune identificazioni (tranne una) possono essere opzionali (ovvero, possono avere cardinalità minima uguale a zero). Riportando i concetti visti finora nello schema di Figura 2.9 si ottiene una sua versione più raffinata illustrata in Figura Si può osservare che il nome di una città identifica una sede dell azienda: questo vuol dire che non c è più di una sede nella stessa città. Un dipartimento è invece identificato dal nome e dalla sede di cui fa parte (dalle cardinalità si evince che una sede ha diversi dipartimenti ma ogni dipartimento fa parte di una sola sede). Un dipartimento ha almeno un numero di telefono, ma può averne più di uno. Un impiegato (identificato da un codice) può afferire a un solo dipartimento (ma può accadere che non afferisca a nessun dipartimento, per esempio se appena assunto) e può dirigere o zero o un dipartimento. Viceversa, ogni dipartimento ha un solo direttore e uno o più impiegati. Sui progetti (identificati univocamente dal loro nome) lavorano diversi impiegati (almeno uno) e ogni impiegato

20 14 2 Progettazione Concettuale (0,1) Dirige (1,1) Codice Cognome Stipendio Età Impiegato (0,N) Dipartimento (1,1) (1,N) Telefono Nome (0,1) Afferisce (1,N) Data Inizio Partecipa Data Afferenza Composta da (1,N) (1,N) Nome Budget Data Consegna (0,1) Progetto Sede Indirizzo Città Via Numero Civico CAP Figura Raffinamento dello schema complesso di Figura 2.9 lavora in generale su più progetti (ma può accadere che non lavori a nessun progetto). Infine, la data di scadenza di un progetto può non essere nota Generalizzazioni Le generalizzazioni rappresentano legami logici tra un entità E, detta entità padre, e una o più entità E 1, E 2,..., E n, dette entità figlie, di cui E è più generale. Si dice in questo caso che E è generalizzazione di E 1, E 2,..., E n e che le entità E 1, E 2,..., E n sono specializzazioni dell entità E. Per esempio, l entità Persona è una generalizzazione delle entità Uomo e Donna mentre Professionista è una generalizzazione delle entità Ingegnere, Medico e Avvocato. Le entità Uomo e Donna sono specializzazioni dell entità Persona. Ogni occorrenza dell entità figlia è anche un occorrenza dell entità padre. Per esempio, un occorrenza di Avvocato è anche un occorrenza di Professionista. Ogni proprietà dell entità padre (attributi, identificatori, relazioni e altre generalizzazioni) è anche una proprietà delle entità figlie. Per esempio se l entità Persona ha attributi Cognome ed Età, anche le entità Uomo e Donna possiedono questi attributi. Inoltre, l identificatore di Persona è un identificatore valido anche per le entità Uomo e Donna. Questa proprietà delle generalizzazioni è nota sotto il nome di ereditarietà. Le generalizzazioni vengono rappresentate graficamente mediante delle frecce che congiungono le entità figlie con l entità padre. Per le entità figlie, le proprietà ereditate non vengono rappresentate esplicitamente. Alcuni esempi di generalizzazioni vengono riportati in Figura Una stessa entità può essere coinvolta in più generalizzazioni diverse. Possono esserci, inoltre, generalizzazioni su più livelli: si parla in questo caso di gerarchia di generalizzazioni. Infine, una generalizzazione può avere una sola entità figlia: si parla in questo caso di sottoinsieme o di relazione isa. A titolo di esempio, in Figura 2.17, il legame che esiste tra l entità Responsabile di Progetto e Progettista rappresenta una relazione isa Documentazione degli schemi E/R È buona norma corredare uno schema E/R con una documentazione di supporto che possa facilitare l interpretazione dello schema stesso e possa descrivere proprietà dei dati rappresentati che non possono essere espressi direttamente dai costrutti del modello. I concetti rappresentati in uno schema possono essere descritti facendo uso di un dizionario dei dati. Esso è composto da due tabelle: la prima presenta le entità dello schema (in particolare, il nome), una descrizione informale, l elenco degli attributi e degli identificatori (si veda la Tabella 2.1);

21 2.2 Uno strumento per la progettazione concettuale: il modello E/R 15 Persona Codice Fiscale Cognome Nome Età Uomo Donna Impiegato Studente Numero Parti Stipendio Matricola Orario Segretario Direttore Progettista Responsabile dei Progetti Figura Rappresentazione delle generalizzazioni ENTITÀ DESCRIZIONE ATTRIBUTI IDENTIFICAZIONE Impiegato Impiegato che lavora Codice, Cognome, Codice nell azienza Stipendio, Età Tabella 2.1. Dizionario delle Entità RELAZIONE DESCRIZIONE ENTITÀ COINVOLTE ATTRIBUTI Dirige Associa un dipartimento Impiegato (0,1), - al suo direttore Dipartimento (1,1) Tabella 2.2. Dizionario delle Relazioni la seconda presenta le relazioni dello schema (in particolare il nome), una descrizione informale, l elenco degli attributi e le entità coinvolte (si veda la Tabella 2.2). Un aspetto molto importante che uno schema E/R non riesce a documentare è la presenza di vincoli di integrità sui dati. Ad esempio un impiegato può essere direttore solo del dipartimento a cui afferisce: questa proprietà non può essere espressa direttamente sullo schema perchè fa riferimento a due concetti (Dirige e Afferisce) che sono indipendenti e non possono essere correlati. Come ulteriore esempio, un vincolo di integrità potrebbe stabilire che un impiegato non può avere uno stipendio maggiore del direttore del dipartimento al quale afferisce. In questi casi si aggiungono allo schema delle annotazioni che completano la descrizione delle proprietà associate ai concetti presenti nello schema e non esprimibili altrimenti. Un esempio di tali annotazioni è rappresentato nella Tabella 2.3. Identif. Regola Regola A1 Il direttore di un dipartimento deve afferire a tale dipartimento A2 Un impiegato non deve avere uno stipendio maggiore del direttore del direttore del dipartimento al quale afferisce A3 Un dipartimento con sede a Roma deve essere diretto da un impiegato con più di dieci anni di anzianità A4 Un impiegato che non afferisce a nessun dipartimento non deve partecipare a nessun progetto Tabella 2.3. Annotazioni allo schema E/R

22 16 2 Progettazione Concettuale Ulteriori usi degli schemi E/R Abbiamo detto più volte che gli schemi E/R costituiscono utili strumenti nelle attività di progettazione delle basi di dati. In realtà, tali schemi, fornendo rappresentazioni astratte dei dati di un applicazione, possono essere utilizzati con profitto anche per attività non strettamente legate alla progettazione. Si possono fare a tale riguardo diversi esempi: gli schemi E/R possono essere utilizzati a scopo documentativo, poichè sono facilmente comprensibili anche da non specialisti di basi di dati; gli schemi E/R possono essere utilizzati per descrivere i dati di un sistema informativo già esistente (per esempio per integrarlo con altri) e, nel caso di sistema costituito da diversi sottosistemi, c è il vantaggio di poter rappresentare le varie componenti con un linguaggio astratto e, quindi, unificante; gli schemi E/R possono essere utilizzati per comprendere, in caso di modifica dei requisiti di un applicazione, in quali porzioni del sistema si deve operare e in che cosa consistono le modifiche da effettuare. 2.3 Regole di progettazione concettuale Qualunque sia la strategia prescelta, è possibile stabilire alcuni criteri generali per tradurre una specifica informale in un costrutto del modello entità-relazione. Spesso non esiste una rappresentazione univoca di un insieme di specifiche, perchè la stessa realtà può essere rappresentata in modi differenti e non comparabili. Comunque, quando ci si trova davanti a diverse possibilità, è utile avere delle indicazioni sulle scelte più opportune. Se un concetto ha proprietà significative e/o descrive classi di oggetti con esistenza autonoma, è opportuno rappresentarlo con un entità. Per esempio, è naturale rappresentare il concetto di docente con un entità, in quanto possiede diverse proprietà (cognome, età, data di nascita) e la sua esistenza è, in qualche modo, indipendente dagli altri concetti. Chiaramente, lo stesso discorso vale anche per concetti astratti come, ad esempio, quello di corso. Se un concetto ha una struttura semplice e non possiede proprietà rilevanti associate, è opportuno rappresentarlo come attributo di un altro concetto a cui si riferisce. Per esempio, il concetto di età è certamente da rappresentare come attributo dei partecipanti ai corsi. In effetti, in questa applicazione, anche il concetto di città, che a prima vista può sembrare un concetto autonomo e strutturato, è opportuno che sia rappresentato come attributo perchè, oltre al nome, non è di interesse nessuna altra proprietà. Se sono state individuate due (o più) entità e nei requisiti compare un concetto che le associa, esso può essere rappresentato da una relazione. Per esempio, nella nostra applicazione, il concetto di partecipazione a un corso è certamente rappresentabile da una relazione tra le entità che rappresentano i partecipanti e i corsi. È importante sottolineare il fatto che questo vale solo nel caso in cui il concetto in questione non abbia, esso stesso, le caratteristiche delle entità. Un esempio tipico e già citato è il concetto di esame relativo a studenti e corsi. Questo concetto può essere rappresentato con una relazione tra studente e corso nel caso in cui interessa, per esempio, solo la votazione. Ma se dell esame sono di interesse anche la data, la sessione, la commissione e, soprattutto, vogliamo descrivere il fatto che lo stesso studente può sostenere più volte un esame per lo stesso corso, allora l esame va rappresentato con un entità collegata da relazioni uno a molti con le entità che rappresentano gli studenti e i corsi. Se uno o più costrutti risultano essere casi particolari di un altro, è opportuno rappresentarli facendo uso di una generalizzazione. 2.4 Esercizi Esercizio Si effettui la progettazione concettuale di un sistema informativo per la gestione di un hotel capace di gestire almeno le seguenti informazioni:

Il modello Entity-Relationship per il progetto delle basi di dati

Il modello Entity-Relationship per il progetto delle basi di dati 1 Il modello Entity-Relationship per il progetto delle basi di dati Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova Le metodologie di progettazione delle Basi di Dati 2 Una metodologia

Dettagli

PROGETTAZIONE CONCETTUALE

PROGETTAZIONE CONCETTUALE Fasi della progettazione di basi di dati PROGETTAZIONE CONCETTUALE Parte V Progettazione concettuale Input: specifiche utente Output: schema concettuale (astrazione della realtà) PROGETTAZIONE LOGICA Input:

Dettagli

Organizzazione degli archivi

Organizzazione degli archivi COSA E UN DATA-BASE (DB)? è l insieme di dati relativo ad un sistema informativo COSA CARATTERIZZA UN DB? la struttura dei dati le relazioni fra i dati I REQUISITI DI UN DB SONO: la ridondanza minima i

Dettagli

Database. Organizzazione di archivi mediante basi di dati. ing. Alfredo Cozzi 1

Database. Organizzazione di archivi mediante basi di dati. ing. Alfredo Cozzi 1 Database Organizzazione di archivi mediante basi di dati ing. Alfredo Cozzi 1 Il database è una collezione di dati logicamente correlati e condivisi, che ha lo scopo di soddisfare i fabbisogni informativi

Dettagli

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File system verso DBSM Vantaggi di un DBMS Modelli dei dati Utenti

Dettagli

Introduzione ai sistemi di basi di dati

Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Alessandro.bardine@gmail.com alessandro.bardine@iet.unipi.it Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File

Dettagli

Introduzione al data base

Introduzione al data base Introduzione al data base L Informatica è quella disciplina che si occupa del trattamento automatico dei dati con l ausilio del computer. Trattare i dati significa: raccoglierli, elaborarli e conservarli

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Progettazione di un DB....in breve

Progettazione di un DB....in breve Progettazione di un DB...in breve Cosa significa progettare un DB Definirne struttura,caratteristiche e contenuto. Per farlo è opportuno seguire delle metodologie che permettono di ottenere prodotti di

Dettagli

Informatica (Basi di Dati)

Informatica (Basi di Dati) Corso di Laurea in Biotecnologie Informatica (Basi di Dati) Introduzione alle Basi di Dati Anno Accademico 2009/2010 Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati Lucidi del Corso di Basi di Dati

Dettagli

Data Base. Prof. Filippo TROTTA

Data Base. Prof. Filippo TROTTA Data Base Definizione di DataBase Un Database può essere definito come un insieme di informazioni strettamente correlate, memorizzate su un supporto di memoria di massa, costituenti un tutt uno, che possono

Dettagli

Le Basi di dati: generalità. Unità di Apprendimento A1 1

Le Basi di dati: generalità. Unità di Apprendimento A1 1 Le Basi di dati: generalità Unità di Apprendimento A1 1 1 Cosa è una base di dati In ogni modello di organizzazione della vita dell uomo vengono trattate informazioni Una volta individuate e raccolte devono

Dettagli

Corso di Informatica (Basi di Dati)

Corso di Informatica (Basi di Dati) Corso di Informatica (Basi di Dati) Lezione 1 (12 dicembre 2008) Introduzione alle Basi di Dati Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati Lucidi del Corso di Basi di Dati 1, Prof. Carlo Batini,

Dettagli

Progettazione base dati relazionale

Progettazione base dati relazionale Progettazione base dati relazionale Prof. Luca Bolognini E-Mail:luca.bolognini@aliceposta.it Progettare una base di dati Lo scopo della progettazione è quello di definire lo schema della base di dati e

Dettagli

Sistemi Informativi e Basi di Dati

Sistemi Informativi e Basi di Dati Sistemi Informativi e Basi di Dati Laurea Specialistica in Tecnologie di Analisi degli Impatti Ecotossicologici Docente: Francesco Geri Dipartimento di Scienze Ambientali G. Sarfatti Via P.A. Mattioli

Dettagli

Design di un database

Design di un database Design di un database Progettare un database implica definire quanto i seguenti aspetti: Struttura Caratteristiche Contenuti Il ciclo di design di un database si suddivide in tre fasi principali: progettazione

Dettagli

Database. Appunti di Amaranto Oronzo e Giancane Diego Lezione dell Ing. Lucia Vaira 24/04/2014

Database. Appunti di Amaranto Oronzo e Giancane Diego Lezione dell Ing. Lucia Vaira 24/04/2014 Database Appunti di Amaranto Oronzo e Giancane Diego Lezione dell Ing. Lucia Vaira 24/04/2014 Cos'è un database? È una struttura di dati composta da tabelle a loro volta composte da campi. Caratteristiche

Dettagli

Identificatori delle entità

Identificatori delle entità Identificatori delle entità Permettono di identificare in maniera univoca le occorrenze delle entità Ogni entità deve averne (almeno) uno Targa Automobile Modello Colore Nome Persona Data di nascita Indirizzo

Dettagli

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE.

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. INFORMATICA Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. APPLICAZIONI WEB L architettura di riferimento è quella ampiamente diffusa ed

Dettagli

Lezione 5: Progettazione di Software e Database. Ingegneria del Software. Il Software 19/11/2011. Dr. Luca Abeti

Lezione 5: Progettazione di Software e Database. Ingegneria del Software. Il Software 19/11/2011. Dr. Luca Abeti Lezione 5: Progettazione di Software e Database Dr. Luca Abeti Ingegneria del Software L ingegneria del software è la disciplina che studia i metodi e gli strumenti per lo sviluppo del software e la misura

Dettagli

Basi di dati. Le funzionalità del sistema non vanno però ignorate

Basi di dati. Le funzionalità del sistema non vanno però ignorate Basi di dati La progettazione di una base di dati richiede di focalizzare lo sforzo su analisi, progettazione e implementazione della struttura con cui sono organizzati i dati (modelli di dati) Le funzionalità

Dettagli

Corso di Basi di Dati A.A. 2013/2014

Corso di Basi di Dati A.A. 2013/2014 Corso di Laurea in Ingegneria Gestionale Sapienza - Università di Roma Corso di Basi di Dati A.A. 2013/2014 8 - Progettazione Concettuale Tiziana Catarci, Andrea Marrella Ultimo aggiornamento : 27/04/2014

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Introduzione ai Database! Tipologie di DB (gerarchici, reticolari, relazionali, oodb) Introduzione ai database Cos è un Database Cos e un Data Base Management System (DBMS)

Dettagli

Sistema di Gestione di Basi di Dati DataBase Management System DBMS

Sistema di Gestione di Basi di Dati DataBase Management System DBMS Base di dati (accezione generica) collezione di dati, utilizzati per rappresentare le informazioni di interesse per una o più applicazioni di una organizzazione (accezione specifica) collezione di dati

Dettagli

Corso di SISTEMI INFORMATICI E TELEMATICI PER LA PROFESSIONE. Lezione 2: Data Base. Ing. Maria Grazia Celentano www.mariagraziacelentano.

Corso di SISTEMI INFORMATICI E TELEMATICI PER LA PROFESSIONE. Lezione 2: Data Base. Ing. Maria Grazia Celentano www.mariagraziacelentano. Corso di SISTEMI INFORMATICI E TELEMATICI PER LA PROFESSIONE Lezione 2: Data Base Ing. Maria Grazia Celentano www.mariagraziacelentano.it 1 Introduzione La raccolta, l organizzazione e la conservazione

Dettagli

Data Base Relazionali. Ing. Maria Grazia Celentano www.mariagraziacelentano.it

Data Base Relazionali. Ing. Maria Grazia Celentano www.mariagraziacelentano.it Data Base Relazionali Ing. Maria Grazia Celentano www.mariagraziacelentano.it 1 Introduzione La raccolta, l organizzazione e la conservazione dei dati sono sempre stati i principali compiti dei sistemi

Dettagli

DEFINIZIONI FONDAMENTALI

DEFINIZIONI FONDAMENTALI Consorzio per la formazione e la ricerca in Ingegneria dell'informazione DEFINIZIONI FONDAMENTALI Per vincere ci vuole una buona partenza... Docente: Cesare Colombo CEFRIEL colombo@cefriel.it http://www.cefriel.it

Dettagli

Progettazione di Basi di Dati

Progettazione di Basi di Dati Progettazione di Basi di Dati Prof. Nicoletta D Alpaos & Prof. Andrea Borghesan Entità-Relazione Progettazione Logica 2 E il modo attraverso il quale i dati sono rappresentati : fa riferimento al modello

Dettagli

70555 Informatica 3 70777 Sicurezza 2. 70555 Mario Rossi 70777 Anna Bianchi. Esempio istanza:

70555 Informatica 3 70777 Sicurezza 2. 70555 Mario Rossi 70777 Anna Bianchi. Esempio istanza: DOMANDE 1) Definire i concetti di schema e istanza di una base di dati, fornendo anche un esempio. Si definisce schema di una base di dati, quella parte della base di dati stessa che resta sostanzialmente

Dettagli

Alessandra Raffaetà. Basi di Dati

Alessandra Raffaetà. Basi di Dati Lezione 2 S.I.T. PER LA VALUTAZIONE E GESTIONE DEL TERRITORIO Corso di Laurea Magistrale in Scienze Ambientali Alessandra Raffaetà Dipartimento di Informatica Università Ca Foscari Venezia Basi di Dati

Dettagli

Basi di dati. Il Modello Relazionale dei Dati. K. Donno - Il Modello Relazionale dei Dati

Basi di dati. Il Modello Relazionale dei Dati. K. Donno - Il Modello Relazionale dei Dati Basi di dati Il Modello Relazionale dei Dati Proposto da E. Codd nel 1970 per favorire l indipendenza dei dati Disponibile come modello logico in DBMS reali nel 1981 (non è facile realizzare l indipendenza

Dettagli

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati INTRODUZIONE Accesso ai dati tramite DBMS Livelli di astrazione Modello dei dati: schema / istanza / metadati Alcuni modelli dei dati Linguaggi per DBMS Architettura di base di un DBMS cesarini - BDSI

Dettagli

Basi di dati. Maurizio Lenzerini. Dipartimento di Informatica e Sistemistica Antonio Ruberti Università di Roma La Sapienza. Anno Accademico 2011/2012

Basi di dati. Maurizio Lenzerini. Dipartimento di Informatica e Sistemistica Antonio Ruberti Università di Roma La Sapienza. Anno Accademico 2011/2012 Basi di dati Dipartimento di Informatica e Sistemistica Antonio Ruberti Università di Roma La Sapienza Anno Accademico 2011/2012 http://www.dis.uniroma1.it/~lenzerin/home/?q=node/44 4. La progettazione

Dettagli

Informatica Introduzione alle basi di dati

Informatica Introduzione alle basi di dati Informatica Introduzione alle basi di dati Prof. Giovanni Giuffrida e-mail: giovanni.giuffrida@dmi.unict.it 27 November 2014 Basi di Dati - Introd. - Prof. G. Giuffrida 1 Materiale didattico Atzeni,Ceri,Paraboschi,Torlone,

Dettagli

Informatica (Basi di Dati)

Informatica (Basi di Dati) Corso di Laurea in Biotecnologie Informatica (Basi di Dati) Modello Entità-Relazione Anno Accademico 2009/2010 Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati Lucidi del Corso di Basi di Dati 1, Prof.

Dettagli

Corso di Laurea in Ingegneria Informatica Algoritmi e basi di dati Modulo Basi di dati a.a. 2010-2011

Corso di Laurea in Ingegneria Informatica Algoritmi e basi di dati Modulo Basi di dati a.a. 2010-2011 Corso di Laurea in Ingegneria Informatica Algoritmi e basi di dati Modulo Basi di dati a.a. 2010-2011 2011 Docente: Gigliola Vaglini Docente laboratorio: Alessandro Lori 1 Obiettivi del corso Imparare

Dettagli

Introduzione alle Basi di Dati

Introduzione alle Basi di Dati 1 Introduzione alle Basi di Dati Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova Sistema Azienda 2 Sistema organizzativo è costituito da una serie di risorse e di regole necessarie

Dettagli

Sistemi Informativi Aziendali II

Sistemi Informativi Aziendali II Modulo 2 Sistemi Informativi Aziendali II 1 Corso Sistemi Informativi Aziendali II - Modulo 2 Modulo 2 La gestione delle informazioni strutturate nell impresa: La progettazione di un Data Base; Le informazioni

Dettagli

Informatica 2 Basi di dati

Informatica 2 Basi di dati Informatica 2 Basi di dati Prof. Giovanni Giuffrida e-mail: giovanni.giuffrida@dmi.unict.it DB - Introduzione 1 Recapiti Prof. Giuffrida Giovanni Email: giovanni.giuffrida@dmi.unict.it Info sul corso:

Dettagli

database: modello entityrelationship

database: modello entityrelationship Insegnamento di Informatica CdS Scienze Giuridiche A.A. 2007/8 database: modello entityrelationship Prof.Valle D.ssaFolgieri Lez7 25.10.07 Trattamento dati. Database: modello entity-relationship 1 Fasi

Dettagli

Abilità Informatiche A.A. 2010/2011 Lezione 8: Basi di Dati. Facoltà di Lingue e Letterature Straniere

Abilità Informatiche A.A. 2010/2011 Lezione 8: Basi di Dati. Facoltà di Lingue e Letterature Straniere Abilità Informatiche A.A. 2010/2011 Lezione 8: Basi di Dati Facoltà di Lingue e Letterature Straniere Base di dati (accezione generica, metodologica) Insieme organizzato di dati utilizzati per il supporto

Dettagli

LABORATORIO. 2 Lezioni su Basi di Dati Contatti:

LABORATORIO. 2 Lezioni su Basi di Dati Contatti: PRINCIPI DI INFORMATICA CORSO DI LAUREA IN SCIENZE BIOLOGICHE Gennaro Cordasco e Rosario De Chiara {cordasco,dechiara}@dia.unisa.it Dipartimento di Informatica ed Applicazioni R.M. Capocelli Laboratorio

Dettagli

Le funzionalità di un DBMS

Le funzionalità di un DBMS Le funzionalità di un DBMS Sistemi Informativi L-A Home Page del corso: http://www-db.deis.unibo.it/courses/sil-a/ Versione elettronica: DBMS.pdf Sistemi Informativi L-A DBMS: principali funzionalità Le

Dettagli

Informatica per l'impresa. Sistemi per la gestione di basi di Dati

Informatica per l'impresa. Sistemi per la gestione di basi di Dati Informatica per l'impresa Sistemi per la gestione di basi di Dati Prof. Mauro Gaspari gaspari@cs.unibo.it 1 1 Sistema Informativo Insieme degli strumenti, risorse e procedure che consentono la gestione

Dettagli

Istituto Angioy Informatica BASI DI DATI. Prof. Ciaschetti

Istituto Angioy Informatica BASI DI DATI. Prof. Ciaschetti Istituto Angioy Informatica BASI DI DATI Prof. Ciaschetti Introduzione e prime definizioni Una Base di dati o Database è un archivio elettronico opportunamente organizzato per reperire in modo efficiente

Dettagli

DBMS (Data Base Management System)

DBMS (Data Base Management System) Cos'è un Database I database o banche dati o base dati sono collezioni di dati, tra loro correlati, utilizzati per rappresentare una porzione del mondo reale. Sono strutturati in modo tale da consentire

Dettagli

Cardinalità e identificatori. Informatica. Generalizzazioni. Generalizzazioni. Generalizzazioni. Generalizzazioni

Cardinalità e identificatori. Informatica. Generalizzazioni. Generalizzazioni. Generalizzazioni. Generalizzazioni e identificatori Codice (0,1) (1,1) Dirige Informatica Lezione 8 Laurea magistrale in Scienze della mente Laurea magistrale in Psicologia dello sviluppo e dell'educazione Anno accademico: 2012 2013 1 Cognome

Dettagli

Corso di Informatica Generale 1 IN1. Linguaggio SQL

Corso di Informatica Generale 1 IN1. Linguaggio SQL Università Roma Tre Facoltà di Scienze M.F.N. di Laurea in Matematica di Informatica Generale 1 Linguaggio SQL Marco (liverani@mat.uniroma3.it) Sommario Prima parte: le basi dati relazionali Basi di dati:

Dettagli

Introduzione ai Database e a Microsoft Access

Introduzione ai Database e a Microsoft Access Introduzione ai Database e a Microsoft Access 1 Il Sistema Informativo aziendale Un Sistema Informativo aziendale è costituito: dall'insieme delle informazioni utilizzate, prodotte e trasformate da un'azienda

Dettagli

Progettare una basi di dati vuole dire progettare la struttura dei dati e le applicazioni

Progettare una basi di dati vuole dire progettare la struttura dei dati e le applicazioni LA PROGETTAZIONE DI BASI DI DATI Progettare una basi di dati vuole dire progettare la struttura dei dati e le applicazioni La progettazione dei dati è l attività più importante Per progettare i dati al

Dettagli

Facoltà di Pianificazione del Territorio A.A. 2011/2012. Informatica

Facoltà di Pianificazione del Territorio A.A. 2011/2012. Informatica Facoltà di Pianificazione del Territorio A.A. 2011/2012 Informatica Le basi di dati 2 Dati e Informazioni Un dato in sé non costituisce un informazione in quanto consiste semplicemente di un insieme di

Dettagli

Database (Base di dati)

Database (Base di dati) Database (Base di dati) Cos è un database Per comprendere appieno cos è un database e quali sono i vantaggi legati al suo impiego, è necessario definire in modo esatto e preciso cosa si intende per: Database

Dettagli

Metodologia di Progettazione database relazionali

Metodologia di Progettazione database relazionali Informatica e Telecomunicazioni S.p.A. Metodologia di Progettazione database relazionali I&T Informatica e Telecomunicazioni S.p.A Via dei Castelli Romani, 9 00040 Pomezia (Roma) Italy Tel. +39-6-911611

Dettagli

Teoria sulle basi di dati

Teoria sulle basi di dati Teoria sulle basi di dati Introduzione alle basi di dati Una base di dati (database) può essere considerata come una raccolta di dati logicamente correlati, utilizzata per modellare una realtà. I dati

Dettagli

PROGETTAZIONE DI UN DATABASE

PROGETTAZIONE DI UN DATABASE Indice PROGETTAZIONE DI UN DATABASE 1.Il modello ER (entity relationship)...1 Generalità...1 I costrutti principali del modello...2 Entità...2 Associazioni...2 Attributi...2 Altri costrutti del modello...2

Dettagli

1. BASI DI DATI: GENERALITÀ

1. BASI DI DATI: GENERALITÀ 1. BASI DI DATI: GENERALITÀ BASE DI DATI (DATABASE, DB) Raccolta di informazioni o dati strutturati, correlati tra loro in modo da risultare fruibili in maniera ottimale. Una base di dati è usualmente

Dettagli

14. LA PROGETTAZIONE CONCETTUALE: IL DIAGRAMMA ER

14. LA PROGETTAZIONE CONCETTUALE: IL DIAGRAMMA ER 14. LA PROGETTAZIONE CONCETTUALE: IL DIAGRAMMA ER La progettazione concettuale consiste nel riorganizzare tutti gli elementi che si hanno a disposizione dopo la fase di raccolta delle richieste (utente),

Dettagli

Lezione V. Aula Multimediale - sabato 29/03/2008

Lezione V. Aula Multimediale - sabato 29/03/2008 Lezione V Aula Multimediale - sabato 29/03/2008 LAB utilizzo di MS Access Definire gli archivi utilizzando le regole di derivazione e descrivere le caratteristiche di ciascun archivio ASSOCIAZIONE (1:1)

Dettagli

Basi di Dati. Programmazione e gestione di sistemi telematici

Basi di Dati. Programmazione e gestione di sistemi telematici Basi di Dati. Programmazione e gestione di sistemi telematici Coordinatore: Prof. Paolo Nesi Docenti: Prof. Paolo Nesi Dr.sa Michela Paolucci Dr. Emanuele Bellini Cosa e l informatica? Scienza del trattamento

Dettagli

Università degli Studi di Napoli Federico II Facoltà di Medicina e Chirurgia Corso di Laurea in Infermieristica

Università degli Studi di Napoli Federico II Facoltà di Medicina e Chirurgia Corso di Laurea in Infermieristica Università degli Studi di Napoli Federico II Facoltà di Medicina e Chirurgia Corso di Laurea in Infermieristica Corso di Sistemi di Elaborazione delle Informazioni A.A. 2011/2012 Prof. Ing. Ivan Giammona

Dettagli

BASI DI DATI per la gestione dell informazione. Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone

BASI DI DATI per la gestione dell informazione. Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone BASI DI DATI per la gestione dell informazione Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone Libro di Testo 22 Chianese, Moscato, Picariello e Sansone BASI DI DATI per la Gestione dell

Dettagli

11 - Progettazione Logica

11 - Progettazione Logica Corso di Laurea in Ingegneria Gestionale SAPIENZA Università di Roma Esercitazioni del corso di Basi di Dati Prof.ssa Catarci e Prof.ssa Scannapieco Anno Accademico 2011/2012 11 - Progettazione Logica

Dettagli

Introduzione ai database I concetti fondamentali Database e DBMS Per comprendere appieno cos'è un Database e quali sono i vantaggi legati al suo impiego, soprattutto nel settore gestionale, è necessario

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

Il modello Entity-Relationship (ER)

Il modello Entity-Relationship (ER) Il modello Entity-Relationship (ER) Prof. Genny Tortora tortora@unisa.it Università di Salerno, a.a. 2010/2011 E.R.: Introduzione Il modello Entità-Relazione (ER) è un diffusissimo data model di alto livello,

Dettagli

Facoltà di Farmacia - Corso di Informatica

Facoltà di Farmacia - Corso di Informatica Basi di dati Riferimenti: Curtin cap. 8 Versione: 13/03/2007 1 Basi di dati (Database, DB) Una delle applicazioni informatiche più utilizzate, ma meno conosciute dai non informatici Avete già interagito

Dettagli

L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE

L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE Roccatello Ing. Eduard L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE Agenda Presentazione docente Definizione calendario Questionario pre corso

Dettagli

Introduzione ai sistemi di basi di dati

Introduzione ai sistemi di basi di dati Introduzione ai sistemi di basi di dati Basi di dati 1 Introduzione ai sistemi di basi di dati Angelo Montanari Dipartimento di Matematica e Informatica Università di Udine Introduzione ai sistemi di basi

Dettagli

Definizione Un modello astratto è la rappresentazione formale di idee e conoscenze relative a un fenomeno.

Definizione Un modello astratto è la rappresentazione formale di idee e conoscenze relative a un fenomeno. MODELLI INFORMATICI 1 Definizione Un modello astratto è la rappresentazione formale di idee e conoscenze relative a un fenomeno. Aspetti di un modello: il modello è la rappresentazione di certi fatti;

Dettagli

PERSONA UOMO MILITARE

PERSONA UOMO MILITARE Capitolo 6 Esercizio 6.1 Considerare lo schema ER in figura 6.36: lo schema rappresenta varie proprietà di uomini e donne. Correggere lo schema tenendo conto delle proprietà fondamentali delle generalizzazioni.

Dettagli

MODELLO RELAZIONALE. Introduzione

MODELLO RELAZIONALE. Introduzione MODELLO RELAZIONALE Introduzione E' stato proposto agli inizi degli anni 70 da Codd finalizzato alla realizzazione dell indipendenza dei dati, unisce concetti derivati dalla teoria degli insiemi (relazioni)

Dettagli

Organizzazione delle informazioni: Database

Organizzazione delle informazioni: Database Organizzazione delle informazioni: Database Laboratorio Informatico di base A.A. 2013/2014 Dipartimento di Scienze Aziendali e Giuridiche Università della Calabria Dott. Pierluigi Muoio (pierluigi.muoio@unical.it)

Dettagli

Basi di dati Progettazione logica. Elena Baralis Politecnico di Torino

Basi di dati Progettazione logica. Elena Baralis Politecnico di Torino Progettazione logica Progettazione logica Richiede di scegliere il modello dei dati!modello relazionale Obiettivo: definizione di uno schema logico relazionale corrispondente allo schema ER di partenza

Dettagli

Che cos è un DBMS? Capitolo 1. Perché usare un DBMS? DBMS. Descrizioni dei dati nei DBMS. Modelli di dati

Che cos è un DBMS? Capitolo 1. Perché usare un DBMS? DBMS. Descrizioni dei dati nei DBMS. Modelli di dati Che cos è un DBMS? Capitolo 1 Introduzione ai sistemi di basi di dati Una collezione integrata molto grande di dati Modella organizzazioni del mondo reale Entità (ad esempio studenti, corsi) Relazioni

Dettagli

Databases relazionali e architetture dei RDBMS

Databases relazionali e architetture dei RDBMS A01 87 Salvatore Sessa Ferdinando Di Martino Michele Giordano Databases relazionali e architetture dei RDBMS Introduzione ai databases relazionali e all uso di Access Copyright MMVI ARACNE editrice S.r.l.

Dettagli

Archivi e Basi di Dati

Archivi e Basi di Dati Archivi e Basi di Dati A B C File Programma 1 Programma 2 A B C File modificati Programma 1 DBMS DB Programma 2 Informatica Generale (CdL in E&C), A.A. 2000-2001 55 Problemi nella gestione di archivi separati

Dettagli

Lezione 2. Il modello entità relazione

Lezione 2. Il modello entità relazione Lezione 2 Il modello entità relazione Pag.1 Introduzione alla progettazione delle basi di dati 1. Analisi dei requisiti Quali sono le entità e le relazioni dell organizzazione? Quali informazioni su queste

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 A2 Introduzione ai database 1 Prerequisiti Concetto di sistema File system Archivi File e record 2 1 Introduzione Nella gestione di una attività, ad esempio un azienda, la

Dettagli

Basi di Dati Relazionali

Basi di Dati Relazionali Corso di Laurea in Informatica Basi di Dati Relazionali a.a. 2009-2010 PROGETTAZIONE DI UNA BASE DI DATI Raccolta e Analisi dei requisiti Progettazione concettuale Schema concettuale Progettazione logica

Dettagli

Archivi e database. Lezione n. 7

Archivi e database. Lezione n. 7 Archivi e database Lezione n. 7 Dagli archivi ai database (1) I dati non sempre sono stati considerati dall informatica oggetto separato di studio e di analisi Nei primi tempi i dati erano parte integrante

Dettagli

Il modello relazionale dei dati

Il modello relazionale dei dati Il modello relazionale dei dati Master Alma Graduate School Sistemi Informativi Home Page del corso: http://www-db.deis.unibo.it/courses/alma_si1/ Versione elettronica: 04Relazionale.pdf Obiettivi della

Dettagli

Corso di Basi di Dati A.A. 2014/2015

Corso di Basi di Dati A.A. 2014/2015 Corso di Laurea in Ingegneria Gestionale Sapienza Università di Roma Corso di Basi di Dati A.A. 2014/2015 Tiziana Catarci, Andrea Marrella Ultimo aggiornamento : 21/02/2015 Risorse di una organizzazione

Dettagli

Analisi Modelli per la specifica dei requisiti

Analisi Modelli per la specifica dei requisiti Modelli per la specifica dei requisiti Modelli semantici dei dati Entità-Relazioni (E-R) Modelli orientati all elaborazione dati Diagrammi di Flusso dei Dati (Data-Flow Diagrams, DFD) Modelli orientati

Dettagli

Algebra e calcolo relazionale. Ripasso. Le 7 Virtù del DBMS persistenza affidabilità volume condivisione riservatezza efficienza efficacia

Algebra e calcolo relazionale. Ripasso. Le 7 Virtù del DBMS persistenza affidabilità volume condivisione riservatezza efficienza efficacia Algebra e calcolo relazionale Ripasso Le 7 Virtù del DBMS persistenza affidabilità volume condivisione riservatezza efficienza efficacia I 4 Livelli di astrazione Le Tabelle Livello fisico (o interno)

Dettagli

PROGRAMMAZIONE MODULARE. Periodo mensile. Ore previste

PROGRAMMAZIONE MODULARE. Periodo mensile. Ore previste PROGRAMMAZIONE MODULARE Indirizzo: INFORMATICA SIRIO Disciplina: INFORMATICA Classe: QUINTA Ore previste: 16 di cui 66 ore di teoria e 99 ore di laboratorio. N. modulo Titolo Modulo Titolo unità didattiche

Dettagli

LABORATORIO di INFORMATICA

LABORATORIO di INFORMATICA Università degli Studi di Cagliari Corso di Laurea Magistrale in Ingegneria per l Ambiente ed il Territorio LABORATORIO di INFORMATICA A.A. 2010/2011 Prof. Giorgio Giacinto IL MODELLO ER PER LA PROGETTAZIONE

Dettagli

LABORATORIO di INFORMATICA

LABORATORIO di INFORMATICA Università degli Studi di Cagliari Corso di Laurea Magistrale in Ingegneria per l Ambiente ed il Territorio LABORATORIO di INFORMATICA A.A. 2010/2011 Prof. Giorgio Giacinto INTRODUZIONE AI SISTEMI DI BASI

Dettagli

1. Analisi dei requisiti

1. Analisi dei requisiti 1. Analisi dei requisiti 1a. Requisiti espressi in linguaggio naturale 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 Si vuole realizzare una base di dati

Dettagli

Corso di Laurea in Ingegneria Informatica Fondamenti di Informatica II Modulo Basi di dati a.a. 2013-2014

Corso di Laurea in Ingegneria Informatica Fondamenti di Informatica II Modulo Basi di dati a.a. 2013-2014 Corso di Laurea in Ingegneria Informatica Fondamenti di Informatica II Modulo Basi di dati a.a. 2013-2014 Docente: Gigliola Vaglini Docente laboratorio: Francesco Pistolesi 1 Obiettivi del corso Imparare

Dettagli

Basi di dati. Informatica. Prof. Pierpaolo Vittorini pierpaolo.vittorini@cc.univaq.it

Basi di dati. Informatica. Prof. Pierpaolo Vittorini pierpaolo.vittorini@cc.univaq.it pierpaolo.vittorini@cc.univaq.it Università degli Studi dell Aquila Facoltà di Medicina e Chirurgia 18 marzo 2010 Un esempio di (semplice) database Quando si pensa ad un database, generalmente si immagina

Dettagli

Cultura Tecnologica di Progetto

Cultura Tecnologica di Progetto Cultura Tecnologica di Progetto Politecnico di Milano Facoltà di Disegno Industriale - DATABASE - A.A. 2003-2004 2004 DataBase DB e DataBase Management System DBMS - I database sono archivi che costituiscono

Dettagli

INFORMATICA PER LE APPLICAZIONI ECONOMICHE PROF.SSA BICE CAVALLO

INFORMATICA PER LE APPLICAZIONI ECONOMICHE PROF.SSA BICE CAVALLO Basi di dati: Microsoft Access INFORMATICA PER LE APPLICAZIONI ECONOMICHE PROF.SSA BICE CAVALLO Database e DBMS Il termine database (banca dati, base di dati) indica un archivio, strutturato in modo tale

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 B1 - Progettazione dei DB 1 Prerequisiti Ciclo di vita del software file system Metodologia di progettazione razionale del software 2 1 Introduzione Per la realizzazione

Dettagli

Basi di dati. Concetti introduttivi ESEMPIO. INSEGNAMENTI Fisica, Analisi, Aule. Docenti. Entità Relazioni Interrogazioni. Ultima modifica: 26/02/2007

Basi di dati. Concetti introduttivi ESEMPIO. INSEGNAMENTI Fisica, Analisi, Aule. Docenti. Entità Relazioni Interrogazioni. Ultima modifica: 26/02/2007 Basi di dati Concetti introduttivi Ultima modifica: 26/02/2007 ESEMPIO INSEGNAMENTI Fisica, Analisi, Informatica Aule Docenti Entità Relazioni Interrogazioni St udent i Database 2 Tabella (I) STUDENTE

Dettagli

Database: collezione di fatti, registrabili e con un ben preciso significato, relazionati fra di loro

Database: collezione di fatti, registrabili e con un ben preciso significato, relazionati fra di loro Database relazionali: un'introduzione Database: collezione di fatti, registrabili e con un ben preciso significato, relazionati fra di loro Rappresentazione astratta di aspetti del mondo reale (Universe

Dettagli

PIANO DI LAVORO EFFETTIVAMENTE SVOLTO IN RELAZIONE ALLA PROGRAMMAZIONE DISCIPLINARE

PIANO DI LAVORO EFFETTIVAMENTE SVOLTO IN RELAZIONE ALLA PROGRAMMAZIONE DISCIPLINARE Istituto di Istruzione Secondaria Superiore ETTORE MAJORANA 24068 SERIATE (BG) Via Partigiani 1 -Tel. 035-297612 - Fax 035-301672 e-mail: majorana@ettoremajorana.gov.it - sito internet: www.ettoremajorana.gov.it

Dettagli

Lo schema concettuale risultante dalla progettazione concettuale è l input alla fase di progettazione logica.

Lo schema concettuale risultante dalla progettazione concettuale è l input alla fase di progettazione logica. Progettazione logica Lo schema concettuale risultante dalla progettazione concettuale è l input alla fase di progettazione logica. La progettazione logica è basata su un particolare modello logico dei

Dettagli

Corso di Sistemi di Elaborazione delle Informazioni I Anno 2005/2006. Esercizi entità relazione risolti. a cura di Angela Campagnaro 802749

Corso di Sistemi di Elaborazione delle Informazioni I Anno 2005/2006. Esercizi entità relazione risolti. a cura di Angela Campagnaro 802749 Corso di Sistemi di Elaborazione delle Informazioni I Anno 2005/2006 Esercizi entità relazione risolti a cura di Angela Campagnaro 802749 Indice: Esercizio 1: Un insieme di officine 1.1 Testo esercizio.3

Dettagli

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it UML: Class Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Class Diagram Forniscono una vista strutturale

Dettagli

Vincoli di Integrità

Vincoli di Integrità Vincoli di Integrità Antonella Poggi Dipartimento di informatica e Sistemistica Sapienza Università di Roma Progetto di Applicazioni Software Anno accademico 2010-2011 Questi lucidi sono stati prodotti

Dettagli