Metodologia di Progettazione database relazionali

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Metodologia di Progettazione database relazionali"

Transcript

1 Informatica e Telecomunicazioni S.p.A. Metodologia di Progettazione database relazionali I&T Informatica e Telecomunicazioni S.p.A Via dei Castelli Romani, Pomezia (Roma) Italy Tel Fax Febbraio 1999 Marketing Operativo e Innovazione Hi Tech - Knowledge Technology Relatore: Nino RUSSO a.russo@ietit.com

2 Indice 1 Introduzione alla progettazione Ciclo di vita dei sistemi informativi Metodologia e fasi di progettazione Progetto concettuale del database Livello vista Schemi ed Istanze Progetto logico del database Progetto fisico del database Indipendenza dei dati Prodotti delle varie fasi della progettazione 7 2 Progettazione concettuale Raccolta e analisi dei requisiti Modello Entità-Relazione Criteri generali di rappresentazione Documentazione dei diagrammi Entità-Relazione Utilità dei diagrammi Entità-Relazione Strategie di progetto Strategia top-down Strategia bottom-up Strategia inside-out Stategia mista Qualità di uno schema concettuale Metodologia generale 19 3 Progettazione logica Analisi delle prestazioni su schemi E-R Ristrutturazione di schemi E-R Modello dati logico Modello dati relazionale Traduzione verso il modello relazionale Vincoli di integrità Vincoli di chiave Vincoli di integrità referenziale Algebra relazionale Operatori di base Operatori derivati Normalizzazione dei dati Ridondanza e anomalie Dipendenze Scomposizioni Prima forma normale Seconda forma normale Terza forma normale Linee guida sulla normalizzazione Implementazione dello schema logico 35 4 Progettazione fisica 36 2

3 1 Introduzione alla progettazione Progettare una base di dati (o banca dati o database) significa definire struttura, caratteristiche e contenuto: si tratta di un processo nel quale bisogna prendere molte decisioni strategiche e l uso di opportune metodologie è fondamentale per la realizzazione di un prodotto di alta qualità. La metodologia cui fa riferimento la I&T è articolata in tre fasi: la progettazione concettuale, la progettazione logica e la progettazione fisica. 1.1 Ciclo di vita dei sistemi informativi La progettazione di una base di dati costituisce solo una componente del processo di sviluppo, all interno di una organizzazione, di un sistema informativo complesso e va quindi inquadrata in un contesto più ampio, quello del ciclo di vita dei sistemi informativi. Come illustrato in figura 1.1, il ciclo di vita di un sistema informativo comprende, generalmente, le seguenti attività. Studio di fattibilità Raccolta e analisi dei requisiti Progettazione Implementazione Validazione e collaudo Funzionamento Fig. 1.1 Ciclo di vita di un sistema informativo Studio di fattibilità. Serve a definire, in maniera per quanto possibile precisa, i costi delle varie alternative possibili e a stabilire le priorità di realizzazione delle varie componenti del sistema. Raccolta e analisi dei requisiti. Consiste nella individuazione e nello studio delle proprietà e delle funzionalità che il sistema informativo dovrà avere. Questa fase richiede una interazione con gli utenti del sistema e produce una descrizione completa, ma generalmente informale, dei dati coinvolti (anche in termini di previsione sulla loro frequenza). Vengono inoltre stabiliti i requisiti software e hardware del sistema informativo. 3

4 Progettazione. Si divide generalmente in progettazione dei dati e progettazione delle applicazioni. Nella prima si individua la struttura e l organizzazione che i dati dovranno avere, nell altra si definiscono le caratteristiche dei programmi applicativi. Le due attività sono complementari e possono procedere in parallelo o in cascata. Le descrizioni dei dati e dei programmi prodotte in questa fase sono formali e fanno riferimento a specifici modelli. Implementazione. Consiste nella realizzazione del sistema informativo secondo la struttura e le caratteristiche definite nella fase di progettazione. Viene costruita e popolata la base di dati e viene sviluppato il codice dei programmi. Validazione e collaudo. Serve a verificare il corretto funzionamento e la qualità del sistema informativo. La sperimentazione deve prevedere, per quanto possibile, tutte le condizioni operative. Funzionamento. In questa fase il sistema informativo diventa operativo e richiede, a meno di malfunzionamenti o revisioni delle funzionalità del sistema, solo operazioni di gestione e manutenzione. Va detto che accanto alle attività citate, viene oggi spesso effettuata anche un attività di prototipizzazione, che consiste nell uso di specifici strumenti software per la realizzazione rapida di una versione semplificata del sistema informativo, con la quale sperimentare le sue funzionalità. La verifica del prototipo può portare a una modifica dei requisiti e una eventuale revisione del progetto. Le basi di dati costituiscono in effetti solo una delle componenti di un sistema informativo che tipicamente include anche programmi applicativi, le interfacce con l utente e altri programmi di servizio. Comunque, il ruolo centrale che i dati hanno in un sistema informativo giustifica uno studio autonomo relativo alla progettazione delle basi di dati e che si individua nella terza fase del ciclo di vita riportato in figura 1.1. Con questo approccio, in linea di principio, viene prima progettata la base di dati e, successivamente, le applicazioni che la utilizzano. 1.2 Metodologia e fasi di progettazione Una metodologia di progettazione è una combinazione di una serie di passi e di proprietà che permettono di ottenere prodotti di alta qualità. In buona sostanza, una metodologia di progettazione consiste in: una decomposizione in passi successivi indipendenti dell intera attività di progetto, una serie di strategie da seguire nei vari passi e alcuni criteri per la scelta in caso di alternative, alcuni modelli di riferimento per descrivere i dati di ingresso e uscita delle varie fasi. Le proprietà che una metodologia deve garantire sono principalmente: la generalità rispetto alle applicazioni e ai sistemi in gioco (e quindi la possibilità di utilizzo indipendente dal problema allo studio e dagli strumenti a disposizione), la qualità del prodotto in termini di correttezza, completezza ed efficienza rispetto alle risorse impiegate, la faciltà d uso sia delle strategie che dei modelli di riferimento. Nel corso degli anni, nell ambito delle basi di dati, si è consolidata una metodologia di progetto articolate in tre fasi principali da effettuare in cascata. Essa si fonda su un principio molto semplice 4

5 ma efficace: quello di separare in maniera netta le decisioni relative a cosa rappresentare in una base dati (prima fase), da quelle relative a come farlo (fasi successive). Ogni fase si riferisce a un livello di astrazione nella rappresentazione dei dati e delle relazioni tra essi, e ha lo scopo di separare le attività di risoluzione dei problemi e di garantire la possibilità di modificare delle soluzioni adottate ai livelli inferiori senza dover riprogettare quanto definito nei livelli superiori. A ciascuna fase di progettazione corrispondono diversi modelli per la rappresentazione dei dati, ovvero tecniche per la rappresentazione degli aspetti rilevanti della realtà da modellare, definite da strumenti e vincoli specifici. La rappresentazione generata seguendo le regole del modello viene definita schema (vedi fig. 1.2). realtà di interesse modello (regole di rappresentazione) schema Fig. 1.2 Realtà/modello/schema Le fasi riconosciute fondamentali nella progettazione di un database sono le seguenti: progetto concettuale, progetto logico e progetto fisico (vedi figura 1.3) Progetto concettuale del database Obiettivo della fase di progettazione concettuale è la rappresentazione completa (formale) della realtà di interesse (informale) ai fini informativi, in maniera indipendente da qualsiasi specifico DBMS (Database Management System) e quindi senza tenere conto degli aspetti implementativi. Tale rappresentazione, detta schema concettuale (che fa riferimento a un modello concettuale dei dati), è la rappresentazione più astratta, ovvero più vicina alla logica umana, nella definizione di dati e relazioni. I modelli dei dati usati nella progettazione concettuale vengono definiti modelli semantici. Nel corso degli anni sono stati definiti diversi modelli dei dati ad iniziare da quelli reticolari e gerarchici seguiti da quello entità-relazione e infine quelli orientati agli oggetti e alla logica Livello vista Una vista, sottoschema, o subschema, è una parte del database concettuale o un astrazione di parte del database concettuale. In un certo senso, la costruzione delle viste è l inverso del processo di integrazione di un database: per ogni collezione dei dati che hanno contribuito alla costruzione del database concettuale globale, possiamo costruire una vista che contenga proprio quei dati. Le viste sono importanti anche per far valere la sicurezza in un sistema di database, permettendo solo agli utenti che ne hanno l autorizzazione di osservare i sottoinsiemi dei dati. Spesso una vista è proprio come un piccolo database concettuale ed ha lo stesso livello di astrazione. Però, in un certo senso, una vista può essere più astratta di un data base concettuale, in quanto i dati in essa coinvolti possono essere costruiti a partire dal database concettuale, senza però essere effettivamente presenti in quel database. 5

6 Requisiti della base di dati Progettazione di base di dati Progetto concettuale Modello concettuale Schema concettuale Progetto logico Modello logico Schema logico Progetto fisico Modello fisico Schema fisico Prodotti della progettazione Fig. 1.3 Fasi della progettazione di una base di dati Schemi ed Istanze Quando si progetta un database si è interessati al suo schema, quando invece si usa si è interessati ai dati effettivamente presenti in esso. Si noti che i dati nel database cambiano frequentemente, mentre gli schemi rimangono gli stessi per lungo tempo. Il contenuto corrente del database si chiama istanza del database (o estensione del database o stato del database). Come visto, il termine schema è usato nelle varie fasi della progettazione di un database, così avremo schema concettuale per riferirsi al livello di progettazione concettuale del database, schema logico per il progetto logico, schema fisico per il progetto fisico e semplicemente sottoschema per il livello delle viste Progetto logico del database La fase di progettazione logica del database ha lo scopo di tradurre lo schema concettuale espresso mediante un modello semantico in una rappresentazione mediate un modello logico dei dati. La rappresentazione che si ottiene viene definita schema logico del database. 6

7 A differenza dello schema concettuale, lo schema logico dipende strettamente dalla categoria di DBMS utilizzato e in particolare del suo modello logico dei dati. Un modello logico dei dati è quindi la tecnica di organizzazione e di accesso ai dati utilizzata da specifiche categorie di DBMS. In particolare, in riferimento al modello logico dei dati su cui si basano, vengono distinti DBMS gerarchici, reticolari, relazionali, ad oggetti e basati sulla logica. Un ulteriore compito della progettazione logica è quello di dichiarare le viste, tramite il DDL (Data Definition Language) o gli specifici linguaggi di definizione dei dati del sottoschema. Successivamente per presentare interrogazioni ed operazioni su tali viste, può essere previsto un linguaggio di manipolazione del sottoschema altrimenti viene usato il DML (Data Manipulation Language) generico Progetto fisico del database Nel progetto fisico viene stabilito come le strutture a livello logico debbano essere organizzate negli archivi e nelle strutture del file system: esso dipende quindi non solo dal tipo di DBMS utilizzato, ma anche dal sistema operativo e in ultima istanza dalla piattaforma hardware del sistema che ospita il DBMS. È pertanto il livello di progettazione in cui si può far uso del minor livello di astrazione, dovendo rispettare i vincoli tecnici imposti dal sistema ospite Indipendenza dei dati La catena di astrazione della figura 1.3, dal database concettuale, a quello logico e a quello fisico, fornisce due livelli di indipendenza dei dati. È ovvio che in un database ben progettato, lo schema fisico possa essere modificato senza alterare quello logico e senza richiedere una ridefinizione dei sottoschemi. Questa indipendenza è nota come indipendenza fisica dei dati. Ciò implica che le modifiche all organizzazione del database fisico possono alterare l efficienza dei programmi applicativi, ma non sarà mai chiesto di riscrivere tali programmi solo perché lo schema fisico ha modificato l implementazione dello schema logico. Anche la relazione tra vista e il database concettuale, fornisce un tipo di indipendenza chiamata indipendenza logica dei dati. L uso del database può rendere necessario modificare lo schema concettuale, per esempio aggiungendo informazioni su diversi tipi di entità o altre informazioni su entità già esistenti. Lo schema concettuale può subire molte modifiche, senza coinvolgere i sottoschemi esistenti, mentre altri tipi di variazione allo schema concettuale possono essere fatte solo ridefinendo la corrispondenza tra sottoschema e schema concettuale. Ancora una volta non sono necessari variazioni ai programmi applicativi. L unico tipo di variazione dello schema concettuale che non si riflette in una semplice ridefinizione della corrispondenza col sottoschema, si verifica quando vengono cancellate alcune informazioni del sottoschema. Naturalmente tali variazioni richiederanno la riscrittura o l eliminazione di alcuni programmi applicativi. 1.3 Prodotti delle varie fasi della progettazione I requisiti delle base di dati vengono utilizzati in maniera differente nelle varie fasi della progettazione. Nella progettazione concettuale si fa uso soprattutto delle specifiche sui dati mentre le specifiche sulle operazioni servono solo a verificare che lo schema concettuale sia completo, contenga cioè le informazioni necessarie per eseguire tutte le operazioni previste. Nella progettazione logica si fa invece riferimento allo schema concettuale per quanto riguarda i dati (cioè 7

8 non si fa più uso diretto delle specifiche sui dati), mentre le specifiche sulle operazioni si utilizzano, insieme alle previsioni sul carico applicativo, per ottenere uno schema logico che renda tali operazioni eseguibili in maniera efficiente. In questa fase bisogna anche conoscere il modello logico adottato ma non è ancora necessario conoscere il particolare DBMS scelto (solo la categoria a cui appartiene). Infine, nella progettazione fisica si fa uso dello schema logico e delle specifiche sulle operazioni per ottimizzare le prestazioni del sistema. In questa fase bisogna anche tener conto delle caratteristiche del particolare sistema di gestione di base di dati utilizzato. Il risultato della progettazione di una base dati non è solo lo schema fisico, ma è costituito anche dallo schema concettuale e dallo schema logico. Lo schema concettuale fornisce infatti una rappresentazione della di base di dati ad alto livello, che può essere molto utile a scopo documentativo, mentre lo schema logico fornisce una descrizione concreta del contenuto della base di dati che, prescindendo dagli aspetti implementativi, può essere utile come riferimento per le operazioni di interrogazione e aggiornamento. Nella figura 1.4 vengono mostrati i prodotti delle varie fasi nel caso della progettazione di una base di dati relazionale, basata sull uso del più diffuso modello concettuale dei dati, il modello Entità- Relazione. A partire da requisiti rappresentati da documenti e moduli di vario genere, acquisiti anche attraverso l interazione con l utente, viene costruito uno schema Entità-Relazione (rappresentato da un diagramma) che descrive a livello concettuale la base di dati. Questa rappresentazione viene poi tradotta in uno schema relazionale, costituito da una collezione di tabelle. Infine, i dati vengono descritti da un punto di vista fisico (tipo e dimensione dei campi) e vengono specificate strutture ausiliarie per l accesso efficiente ai dati. Nel seguito del documento saranno affrontati in maniera dettagliata i vari passi della progettazione di base di dati secondo la decomposizione di figura 1.3 e con riferimento ai modelli usati nella figura

9 Realtà Progettazione concettuale Schema Entità-Relazione Progettazione logica Schema Relazionale Progettazione fisica Strutture fisiche d accesso Fig. 1.4 Prodotti delle varie fasi del progetto di una base dati relazionale con il modello Entità-Relazione 9

10 2 Progettazione concettuale La progettazione concettuale è la prima fase che viene eseguita nella costruzione di una base di dati, e in essa si produce, uno schema concettuale che rappresenta 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. Di seguito verranno descritte le strategie che è possibile seguire in questo processo di sviluppo graduale di uno schema concettuale e il più diffuso modello che permette di realizzare il suddetto schema, il modello Entità-Relazione. Prima di iniziare a parlare di queste strategie, vale però la pena spendere qualche parola sull attività che precede la progettazione vera e propria: la raccolta e l analisi dei requisiti. Questa fase, infatti, non è completamente separata da quella della progettazione, ma procede, in molti casi, parallelamente ad essa. Possiamo, infatti, iniziare a definire uno schema Entità-Relazione 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. 2.1 Raccolta e analisi dei requisiti Va detto innanzitutto che il reperimento e l analisi dei requisiti di una applicazione sono attività difficilmente standardizzabili perché dipendono molto dall applicazione con cui si a che fare. Vogliamo però parlare di alcune regole pratiche che è conveniente seguire in questa fase di sviluppo di una base di dati. Per raccolta dei requisiti si intende la completa individuazione dei problemi che il sistema da realizzare deve risolvere e le caratteristiche che tale sistema dovrà avere. Per caratteristiche del sistema si intendono sia gli aspetti statici (i dati) che gli aspetti dinamici (le operazioni sui dati). I requisiti vengono inizialmente raccolti in specifiche espresse in linguaggio naturale e, per questo motivo, spesso ambigue e disorganizzate. L analisi dei requisiti consiste nel chiarimento e nell organizzazione delle specifiche dei requisiti. Si tratta ovviamente di attività fortemente interconnesse: l attività di analisi inizia con i primi requisiti ottenuti per poi procedere di pari passo con attività di raccolta. I requisiti di una applicazione provengono, nella maggior parte dei casi, da fonti diverse. Le principali fonti di informazione sono, in genere, le seguenti. Gli utenti dell applicazione. In questo caso le informazioni si acquisiscono mediante opportune interviste, anche ripetute, oppure attraverso una documentazione scritta che gli utenti possono aver predisposto appositamente per questo scopo. Tutta la documentazione esistente che ha qualche attinenza con il problema allo studio: moduli, regolamenti interni, procedure aziendali e normative. È richiesta, in questo caso, un attività di raccolta e selezione che viene assistita dagli utenti, ma è a carico del progettista. Eventuali realizzazioni esistenti, ovvero applicazioni che si devono rimpiazzare o che devono interagire in qualche maniera con il sistema da realizzare. La conoscenza delle caratteristiche di questi pacchetti software (tracciati record, maschere, algoritmi, documentazione associata) può fornirci importanti informazioni anche in relazione ai problemi esistenti che è necessario risolvere. 10

11 Risulta chiaro che, nella fase di acquisizione delle specifiche, gioca un importante ruolo l interazione con gli utenti del sistema informativo. Durante questa interazione, avviene spesso che gli utenti diversi forniscono informazioni diverse, spesso complementari ma qualche volta contraddittorie. Gli utenti a livello più alto possiedono in genere una visione più ampia, ma meno dettagliata. Possono però indirizzare verso gli esperti dei singoli sottoproblemi. Come criterio generale da seguire possiamo dire che, nel corso delle interviste, è opportuno effettuare con l utente verifiche di comprensione e consistenza sulle informazioni che si stanno raccogliendo. Questo può essere fatto attraverso esempi (generali e relativi a casi simili) oppure richiedendo definizioni e classificazioni precise. È inoltre molto importante in questa fase cercare di individuare gli aspetti essenziali rispetto a quelli marginali e procedere per raffinamenti successivi. Partendo quindi dai principali aspetti del problema allo studio, dei quali si ha inizialmente una conoscenza solo parziale, si procede cercando di acquisire via via maggiori dettagli. Come abbiamo già accennato, la specifica dei requisiti raccolti avviene spesso, almeno in prima battuta, facendo uso di descrizioni in linguaggio naturale. Sappiamo bene però che il linguaggio naturale è fonte di ambiguità e fraintendimenti. È molto importante quindi effettuare una profonda analisi del testo che descrive le specifiche per filtrare le eventuali inesattezze e i termini ambigui presenti. Alcune regole generali per ottenere una specifica dei requisiti più precisa e senza ambiguità sono le seguenti: Scegliere il corretto livello di astrazione. È bene evitare l utilizzo di termini troppo generici o troppo specifici che rendono poco chiaro un concetto. Standardizzare la struttura delle frasi. Nella specifica dei requisiti è preferibile utilizzare sempre lo stesso stile sintattico. Ad esempio, per <dato> rappresentiamo <proprietà> per la descrizione dei dati e se <condizione> allora <azione1> altrimenti <azione2> per descrivere le azioni. Evitare frasi contorte. Le definizioni devono essere semplici e chiare. Individuare sinonimi/omonimi e unificare i termini. I sinonimi indicano termini diversi con lo stesso significato; gli omonimi indicano termini uguali con diversi significati. Queste situazioni possono generare ambiguità e vanno chiarite: nel caso di sinonimi, unificando i termini, nel caso di omonimi, utilizzando termini diversi o specificandoli meglio. Rendere esplicito il riferimento tra termini. Può succedere che l assenza di un contesto di riferimento renda alcuni concetti ambigui: in questi casi bisogna esplicitare il riferimento tra termini. Costruzione di un glossario dei termini. È molto utile, per la comprensione e precisazione dei termini usati, definire un glossario che, per ogni termine, contenga: una breve descrizione, possibili sinonimi e altri termini contenuti nel glossario con i quali esiste un legame logico. Dopo aver individuato le varie ambiguità e le imprecisioni, esse vanno eliminate sostituendo i termini non corretti con i termini più adeguati. In caso di dubbio, è necessario intervistare nuovamente colui che ha fornito il dato o consultare la documentazione relativa. A questo punto si possono riscrivere le specifiche apportando le modifiche proposte. Naturalmente, accanto alle specifiche sui dati, vanno raccolte le specifiche sulle operazioni (inserimenti, consultazioni, aggiornamenti, stampe, ecc.) da effettuare su questi dati. Bisogna cercare di utilizzare la medesima terminologia usata per i dati (possiamo per questo fare riferimento al glossario dei termini) e informarci anche sulla frequenza con la quale le varie operazioni vengono eseguite. Come vedremo, la conoscenza di questa informazione sarà determinante nella fase di progettazione logica. 11

12 Dopo questa strutturazione dei requisiti, siamo pronti ad avviare la prima fase della progettazione che consiste nella costruzione di uno schema concettuale in grado di descrivere in maniera adeguata le specifiche dei dati raccolte. A tal fine noi usiamo il modello Entità-Relazione. 2.2 Modello Entità-Relazione Lo scopo del modello Entity-Relationship (Entità-Relazione E-R) è quello di permettere la descrizione dello schema concettuale di una situazione reale senza preoccuparsi dell efficienza o della progettazione del database fisico, che ci si aspetta invece nella maggior parte dei modelli fisici. Di solito si pensa che lo schema entità-relazione così costruito sia poi tradotto in uno schema logico di un modello logico dei dati, ad esempio quello relazionale, che al momento è il più diffuso. Di seguito sono descritti i costrutti che il modello mette a disposizione per esprimere la realtà di interesse in maniera formale e facile da comprendere, e che prescinde dai criteri di organizzazione dei dati negli elaboratori. Entità Il modello entità-relazione, prevede come prima attività della progettazione concettuale, la individuazione delle entità. Una entità è qualcosa che esiste ed è distinguibile: possiamo cioè riconoscere un entità tra le altre. Ad esempio ogni persona è un entità, così come ogni automobile. Set di entità Un gruppo composto da entità tutte simili forma un set di entità. Il termine entità simili non è definito in modo preciso e si possono stabilire infinite proprietà diverse con cui definire set di entità. Nella progettazione del modello concettuale di un database, la scelta dei set di entità, è una operazione fondamentale così come è importante individuare tutte le proprietà caratteristiche di un set di entità che vengono descritte mediante gli attributi. Dalla somiglianza, quindi, nasce la necessità dell individuazione di un insieme di caratteristiche comuni a tutti gli elementi del set di entità. Il set di entità è un concetto a livello di schema, mentre il corrispondente concetto a livello di istanza è il relativo sottoinsieme corrente di tutti gli elementi del dato set di entità nel database. Lo schema entità-relazione ha una rappresentazione grafica che permette di avere immediatamente la visione globale dello schema concettuale del database. La rappresentazione grafica che si ottiene, a volte, invece di schema, viene chiamata diagramma entità-relazione (Entity-Relationship Diagram ERD). In questa rappresentazione grafica si usa una convenzione per rappresentare i vari oggetti. I set di entità vengono rappresentate con dei rettangoli con il nome del set di entità all interno. Attributi e chiavi Come già detto, i set di entità possiedono delle proprietà, chiamate attributi, le quali associano ad ogni entità del set un valore appartenente al dominio dei possibili valori per quell attributo. Di solito il dominio sarà un insieme di interi, numeri reali, stringhe di caratteri, valori booleani ma anche immagini, audio e video come nei più recenti database multimediali. La scelta degli attributi caratteristici per i set di entità è un punto abbastanza critico nell ideare lo schema concettuale di un database. Tra tutti gli attributi di un particolare set di entità ne va scelto uno o un insieme, i cui valori identificano in modo univoco ogni entità del set. Questo attributo o insieme di attributi è chiamato chiave per quel dato set. In linea di principio ogni set di entità possiede una chiave soddisfacendo la richiesta che ogni entità sia distinguibile da ogni altra. Ma se 12

13 per un set di entità scegliamo un insieme di attributi tra i quali non si possa individuare una chiave, non saremo in grado di distinguere una entità dall altra. Però è possibile fornire un codice identificativo arbitrario da usare come chiave. La rappresentazione grafica degli attributi è un ellisse con il nome dell attributo scritto all interno e si collega con il rispettivo set di entità con dei segmenti (non orientati). Agli attributi che fanno parte della chiave per il rispettivo set, viene aggiunta una sottolineatura al nome. Nel caso speciale di set di entità con un singolo attributo, a volte si identifica il set con l attributo stesso, chiamando il set col il nome dell attributo. In tal caso, invece che con un rettangolo, il set di entità è rappresentato con un ellisse collegata a qualunque relazione con cui sia coinvolto il set di entità. Relazioni Le dipendenze o associazioni di interesse informativo tra i dati da rappresentare vengono espresse nel modello entity-relationship mediante relazioni tra le corrispondenti entità. Le relazioni dello stesso tipo compongono l insieme di relazioni (relation set) tra i due insiemi di entità. Per ottenere un modello adeguato del mondo reale, spesso è necessario classificare le relazioni a seconda del numero di entità associabili tra un set di entità e l altro. Relazioni uno-a-uno La relazione più semplice, e più rara, fra le relazioni che collegano due set è quella uno-a-uno, cioè che ogni entità di un set è legata con al più un elemento dell altro set. Le relazioni vengono rappresentate graficamente con dei rombi e vengono collegati ai propri set di entità con dei segmenti orientati o non a seconda del tipo di relazione. Nel caso di relazione uno-auno il segmento è orientato in entrambi i versi. Un alternativa all utilizzo dei segmenti orientati è quella di mettere sui segmenti che collegano la relazione ai set dei numeri che indicano la cardinalità della relazione. Un esempio di relazione 1:1 è la relazione tra nazioni e capitali. Ogni nazione ha un unica capitale, ad una capitale corrisponde un unica nazione. Relazione uno-a-molti Due set E1 ed E2 sono in relazione uno-a-molti da E1 ad E2 se una entità nel set E1 è associata con zero o più entità nel set E2, ma ogni entità in E2 è associata con al più una entità in E1. Un esempio di relazione 1:N è la relazione tra madri e figli. Una madre può avere più figli, mentre ad un figlio corrisponde un unica madre. La rappresentazione grafica della relazione 1:N è un rombo con segmenti che uniscono i set di entità coinvolti e orientati soltanto nella direzione del set di entità con cardinalità uno. Relazione molti-a-molti Due set E1 ed E2 sono in relazione molti-a-molti se ad ogni elemento di E1 possono corrispondere più elementi di E2 e viceversa. Sulle relazioni molti-a-molti è da notare il fatto che non esistono efficienti strutture dati per la loro implementazione, spesso è richiesto di scomporre tali relazioni con varie relazioni molti-a-uno. Un esempio di relazione N:M è la relazione tra corsi e studenti. Un corso è seguito da più studenti, e lo stesso studente segue più corsi. La rappresentazione grafica della relazione N:M è un rombo con segmenti non orientati che uniscono i set di entità coinvolti. Gerarchia ISA Un tipo particolare di relazione è quella chiamata ISA o sottotipo/supertipo. Diciamo che A isa B, cioè A è un B (A è il sottotipo e B è il supertipo), se il set di entità B è una generalizzazione di entità del set A, o in modo equivalente se A è un tipo particolare (specializzazione) di B. Lo scopo 13

14 principale per dichiarare le relazioni isa tra i set di entità A e B è che in tal modo A eredita gli attributi di B, ma avrà anche attributi che non avrebbero necessariamente significato per gli elementi di B che non siano anche elementi di A. La rappresentazione grafica della gerarchia isa è un rombo con etichetta isa con segmenti orientati nella direzione del set supertipo. Un esempio di relazione isa è quello di una società che può avere un set di entità Dipendenti con attributi Matricola, Nome e Stipendio. Se la società fosse una squadra di calcio, alcuni dei dipendenti, i Giocatori, avrebbero altri importanti attributi come Ruolo (portiere, difensore, attaccante), che non riguarderebbero gli altri dipendenti. Il modo migliore per progettare questo schema, è quello di avere un altro set di entità, Giocatori, legato con la relazione isa al set Dipendenti. Gli attributi (anche le chiavi) che appartengono a Dipendenti (Matricola, Nome, Stipendio), verrebbero ereditati da Giocatori, ma solo Giocatori avrebbe un attributo come Ruolo. Attributi delle relazioni Il modello entità-relazione prevede che anche gli insiemi delle relazioni abbiano degli attributi che ne specificano le caratteristiche. Tali attributi vengono rappresentati graficamente con una ellisse, cioè come per gli attributi di un set di entità, con un segmento orientato nel verso che va dal rombo all ellisse. 2.3 Criteri generali di rappresentazione Prima di affrontare le metodologie di progetto, è conveniente stabilire alcune criteri generali per tradurre una specifica informale in un costrutto del modello Entità-Relazione. Va precisato che 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. Nel caso della progettazione concettuale conviene, in buona sostanza, seguire le regole concettuali del modello E-R. Se un concetto ha proprietà significative e/o descrive classi di oggetti con esistenza autonoma, è opportuno rappresentarlo con una entità. Se un concetto ha una struttura semplice e non possiede proprietà rilevanti associate, è opportuno rappresentarlo con un attributo di un altro concetto a cui si riferisce. Se sono state individuate due (o più) entità e nei requisiti compare un concetto che le associa, questo concetto può essere rappresentato da una relazione. Se uno o più concetti risultano essere casi particolari di un altro, è opportuno rappresentarli facendo uso di una generalizzazione. I criteri visti hanno validità generale, sono cioè indipendenti dalla strategia di progettazione scelta. Come vedremo in seguito, in ogni strategia esiste prima o poi un momento in cui va presa la decisione sul costrutto da scegliere per rappresentare un certa specifica. 2.4 Documentazione dei diagrammi Entità-Relazione Gli schemi Entità-Relazione ben congeniati sono in genere autoesplicativi e quindi facilmente comprensibili. È buona norma però corredare uno schema con una documentazione di supporto, che 14

15 possa servire a facilitare l interpretazione dello schema stesso e a descrivere proprietà dei dati rappresentati che non possono essere espressi direttamente dai costrutti del modello. I concetti rappresentati in uno schema possono essere documentati facendo uso di uno dizionario dei dati. Esso è composto da due tabelle: la prima descrive le entità dello schema (dizionario dei dati delle entità) con il nome, una descrizione informale, l elenco degli attributi e gli identificatori, l altra descrive le relazioni (dizionario dei dati delle relazioni) con il nome, una descrizione informale, le entità coinvolte, la cardinalità e gli attributi. L uso del dizionario dei dati è particolarmente importante nei casi in cui lo schema è complesso (molti concetti collegati in maniera complicata) e risulta pesante aggiungere allo schema tutti gli attributi di entità e relazioni. Inoltre, esiste un altro aspetto molto importante di uno schema E-R che va documentato: la presenza di vincoli di integrità sui dati che non possono essere rappresentati con i costrutti del modello. Ad esempio un vincolo non esprimibile direttamente potrebbe essere il fatto che un impiegato non può avere uno stipendio maggiore del direttore del dipartimento al quale afferisce. In questi casi, la cosa migliore è di aggiungere allo schema delle annotazioni (una tabella dei vincoli di integrità sui dati) che completano la descrizione delle proprietà associate ai concetti presenti nello schema e non esprimibili altrimenti. 2.5 Utilità dei diagrammi Entità-Relazione Perché dovremmo essere interessati al modello dati di un sistema? In primo luogo perché le strutture di dati e le relazioni possono essere così complesse che vogliamo evidenziarle ed esaminarle indipendentemente dall elaborazione che avrà luogo. In effetti, ciò è particolarmente vero quando il modello del sistema viene mostrato agli utenti esecutivi di livello superiore in un organizzazione (ad esempio, i vicepresidenti o direttori di reparto). Tali utenti sono spesso interessati ai dati: quali dati servono per condurre gli affari? In che modo i dati sono correlati ad altri dati? Chi possiede i dati? A chi è consentito l accesso ai dati? La risposta ad alcune di queste domande ad esempio, l accesso ai dati e l identificazione dei proprietari è fornita dai DA (Data Administrator). Ogni volta che si inizia a costruire un nuovo sistema informativo, si ha bisogno di parlare con queste persone in modo da poter coordinare le proprie informazioni sul sistema col loro modello di informazioni globale a livello aziendale. Il diagramma entità-relazione è un utile strumento per svolgere la conversazione col gruppo dei DA. Si dovrà altresì conversare con il gruppo dei DBA (Data Base Administrator), situato solitamente nel reparto di elaborazione dati (mentre i DA non vi appartengono necessariamente), il cui compito è quello di garantire che i database computerizzati siano organizzati, gestiti e controllati efficacemente. Quindi essi costituiscono spesso la squadra di implementazione che ha la responsabilità di prendere un modello essenziale (cioè, un modello indipendente dalla tecnologia specifica) e convertirlo in un progetto di database fisico efficace ed efficiente per Oracle, Informix, DB2 o qualche altro sistema di gestione di database. Il diagramma di entità-relazione è un efficace strumento di modellamento per comunicare col gruppo di DBA. In base alle informazioni presentate dal diagramma E-R, il gruppo di amministrazione del database può iniziare a determinare i tipi di chiave o di indici o di puntatori che servono per accedere efficientemente ai record del database. 15

16 Quindi il modello dei dati fornisce, oltre alla rappresentazione dei dati del sistema che si vuole gestire, un utile strumento di conversazione con gli altri gruppi di lavoro che interagiscono in un progetto. In realtà fornendo rappresentazioni facili da comprendere dei dati coinvolti da un applicazione, gli schemi E-R possono essere utilizzati anche indipendentemente dallo scopo finale di realizzare un applicazione. Esistono diversi esempi di possibile uso degli schemi concettuali che prescindono dall attività di progettazione: gli schemi E-R possono essere per esempio utilizzati a scopo documentativo, perché sono facilmente comprensibili anche da non specialisti di base di dati; possono essere utilizzati per descrivere e analizzare un sistema informatico già esistente e, nel caso di sistema costituito da diversi sottoinsiemi, c è il vantaggio di poter rappresentare le varie componenti con un linguaggio astratto e quindi unificante; possono essere infine utilizzati per comprendere, in caso di modifica dei requisiti di una applicazione, su quali porzioni di sistema si deve operare e in cosa consistono le modifiche da effettuare. 2.6 Strategie di progetto Lo sviluppo di uno schema concettuale a partire dalle sue specifiche può essere considerato a tutti gli effetti un processo di ingegnerizzazione e, come tale, risultano ad esso applicabili le comuni strategie di progetto utilizzate anche in altre discipline. Vediamo quali sono queste strategie con specifico riferimento alla modellazione di una base di dati Strategia top-down In questa strategia, lo schema concettuale viene prodotto mediante una serie di raffinamenti successivi a partire da uno schema iniziale che descrive tutte le specifiche con pochi concetti molto astratti. Lo schema viene poi via via raffinato mediante opportune trasformazioni che aumentano il dettaglio dei vari concetti presenti. Si procede definendo vari piani di raffinamento del processo: ognuno di questi piani contiene uno schema che descrive le medesime informazioni a un diverso livello di dettaglio. Con questa strategia quindi, tutti gli aspetti presenti nello schema finale sono presenti, in linea di principio, a ogni livello di raffinamento. Nel passaggio da un livello di raffinamento ad un altro, lo schema viene modificato facendo uso di alcune trasformazioni elementari che vengono denominate primitive di trasformazione top-down. Queste primitive operano su un singolo concetto dello schema e lo trasformano in una struttura più complessa in grado di descrivere il concetto di partenza con maggiore dettaglio. Di seguito sono elencate queste primitive. Trasformazione da entità a relazione tra entità. Si applica quando si comprende che una entità descrive due concetti diversi legati logicamente tra di loro. Trasformazione da entità a generalizzazione. Si applica quando si comprende che una entità è composta da sotto-entità distinte. Trasformazione da relazione a insieme di relazioni. Si applica quando si comprende che una relazione descrive in realtà due relazioni diverse tra le medesime entità. 16

17 Trasformazione da relazione a entità con relazioni. Si applica quando si comprende che una relazione descrive un concetto con esistenza autonoma ai fini dell applicazione. Introduzione di attributi su entità. Si applica per aggiungere proprietà (attributi) a entità. Introduzione di attributi su relazioni. Si applica per aggiungere attributi a relazioni. Il vantaggio della strategia top-down è che il progettista può descrivere inizialmente tutte le specifiche dei dati trascurandone i dettagli, per poi entrare nel merito di un concetto alla volta (si osservi che le primitive di trasformazione agiscono su singoli concetti). Questo però è possibile solo quando si possiede, sin dall inizio, una visione globale e astratta di tutte le componenti del sistema, ma ciò è estremamente difficile quando si ha a che fare con applicazioni di una certa complessità Strategia bottom-up In questa strategia, le specifiche iniziali sono suddivise in componenti via via sempre più piccole, fino a quando queste componenti descrivono un frammento elementare della realtà di interesse. A questo punto, le varie componenti vengono rappresentate da semplici schemi concettuali che possono consistere anche di un singolo concetto. I vari schemi così ottenuti vengono poi fusi fino a giungere, attraverso una completa integrazione di tutte le componenti, allo schema concettuale finale. Questo procedimento consiste, quindi, di una fase di decomposizione delle specifiche, di una successiva fase di rappresentazione delle componenti di base e di una fase finale di integrazione degli schemi elementari. A differenza della strategia top-down, con questa strategia i vari concetti presenti nello schema finale vengono via via introdotti durante le varie fasi. Anche in questo caso, lo schema finale si ottiene attraverso alcune trasformazioni elementari che vengono denominate primitive di trasformazione bottom-up. Queste primitive introducono nello schema nuovi concetti non presenti precedentemente e in grado di descrivere aspetti della realtà di interesse che non erano ancora stati rappresentati. Vediamo queste primitive. Generazione di entità. Si applica quando si individua nelle specifiche una classe di oggetti con proprietà comuni. Generazione relazione. Si applica quando si individua nelle specifiche un legame logico tra due entità. Generazione di una generalizzazione. Si applica quando si individua nelle specifiche un legame tra diverse entità riconducibili a una generalizzazione. Aggregazione di attributi su entità. Si applica quando, a partire da una serie di attributi, si individua una entità che può essere vista come aggregazione di tali attributi. Aggregazione di attributi su relazione. Si applica in maniera simile alla trasformazione precedente, quando si individua una relazione che può essere vista come aggregazione di alcuni attributi. Il vantaggio della strategia bottom-up è che si adatta ad una decomposizione del problema in componenti più semplici, facilmente individuabili, il cui progetto può essere affrontato anche da progettisti diversi. È quindi un tipo di strategia che si presta bene a lavori svolti in collaborazione o suddivisi all interno di un gruppo. Lo svantaggio di questa strategia è invece il fatto che richiede delle operazioni di integrazione di schemi concettuali diversi che, nel caso di schemi complessi, presentano quasi sempre grosse difficoltà. 17

18 2.6.3 Strategia inside-out Questa strategia può essere vista come un caso particolare della strategia bottom-up. Si individuano inizialmente solo alcuni concetti importanti e poi si procede, a partire da questi, a macchia d olio. Si rappresentano cioè prima i concetti concettualmente più vicini ai concetti iniziali, per poi muoversi verso quelli più lontani attraverso una navigazione tra le specifiche. Questa strategia ha il vantaggio di non richiede passi di integrazione. D altro canto è necessario, di volta in volta, esaminare tutte le specifiche per individuare concetti non ancora rappresentati e descrive i nuovi concetti nel dettaglio. Non è quindi possibile procedere per livelli di astrazione come avviene nella strategia top-down Stategia mista La strategia mista cerca di combinare i vantaggi della strategia top-down con quelli della strategia bottom-up. Il progettista suddivide i requisiti in componenti separate, come nella strategia bottomup, ma allo stesso tempo definisce uno schema scheletro contenente, a livello astratto, i concetti principali dell applicazione. Questo schema scheletro fornisce una visione unitaria, sia pure astratta, dell intero progetto e favorisce le fasi di integrazione degli schemi sviluppati separatamente. Definito lo schema scheletro possiamo procedere considerando, anche separatamente, i concetti principali e proseguire per raffinamenti successivi (procedendo quindi in maniera top-down) oppure estendere il (sotto)schema con concetti non ancora rappresentati (procedendo quindi in maniera bottom-up). La strategia mista è probabilmente la più flessibile tra le strategie viste perché si adatta bene a esigenze contrapposte: quella di suddividere un problema complesso in sottoproblemi e quella di procedere per raffinamenti successivi. In effetti, questa strategia ingloba anche la strategia insideout che, che come abbiamo detto, è solo un caso particolare della strategia bottom-up. È infatti abbastanza naturale, durante uno sviluppo bottom-up di una sottocomponente di un progetto, procedere a macchia d olio per rappresentare le specifiche della nostra base di dati non ancora rappresentate. C è anche da dire che, in quasi tutti i casi pratici di una certa complessità, la strategia mista è l unica che si può effettivamente adottare perché, come abbiamo detto precedentemente, è spesso necessario cominciare la progettazione quando non sono ancora disponibili tutti i dati e, dei dati noti, abbiamo spesso delle conoscenze a livello di dettaglio non omogenei. 2.7 Qualità di uno schema concettuale Nella costruzione di uno schema concettuale vanno comunque garantite alcune proprietà generali che uno schema concettuale di buona qualità deve possedere. Analizziamo le qualità più importanti e vediamo come è possibile verificare, durante la progettazione, queste qualità. Correttezza Uno schema concettuale è corretto quando utilizza propriamente i costrutti messi a disposizione dal modello concettuale di riferimento. Come avviene nei linguaggi programmativi, gli errori possono essere sintattici o semantici. I primi riguardano un uso non ammesso di costrutti come, per esempio, una generalizzazione tra relazioni invece che tra entità. I secondi riguardano invece un uso di costrutti che non rispettano la loro definizione. Per esempio, l uso di una relazione per descrivere il fatto che un entità è specializzazione di un altra. La correttezza di uno schema si può verificare per ispezione, confrontando i concetti presenti nello schema in via di costruzione con le specifiche e con le definizioni dei costrutti del modello concettuale usato. 18

19 Completezza Uno schema concettuale è completo quando rappresenta tutti i dati di interesse e quando tutte le operazioni possono essere eseguite a partire dai concetti descritti nello schema. La completezza di uno schema si può verificare controllando che tutte le specifiche sui dati siano rappresentate da qualche concetto presente nello schema che stiamo costruendo, e che tutti i concetti coinvolti in una operazione presente nelle specifiche siano raggiungibili navigando attraverso lo schema. Leggibilità Uno schema concettuale è leggibile quando rappresenta i requisiti in maniera naturale e facilmente comprensibili. Per garantire questa proprietà è necessario rendere lo schema autoesplicativo, per esempio, mediante una scelta opportuna dei nomi da dare ai concetti. La leggibilità dipende anche da criteri puramente estetici: la comprensione di uno schema è per esempio facilitata se tracciamo il relativo diagramma su una griglia nella quale i vari costrutti hanno le stesse dimensioni. Alcuni suggerimenti per rendere lo schema più leggibile sono i seguenti: disporre i costrutti in una griglia scegliendo come elementi centrali quelli con più legami (relazioni) con gli altri; tracciare solo linee perpendicolari e cercare di minimizzare le intersezioni (si noti che le intersezioni si possono evitare se lo schema è un grafo planare); disporre le entità che sono padri di generalizzazioni sopra le relative entità figlie. La leggibilità di uno schema si può verificare facendo delle prove di comprensione con gli utenti. Minimalità Uno schema è minimale quando tutte le specifiche sui dati sono rappresentate una sola volta nello schema. Uno schema quindi non è minimale quando esistono delle ridondanze, ovvero concetti che possono essere derivati da altri. Una fonte di ridondanza tipica in uno schema E-R è la presenza di cicli dovuta alla presenza di relazioni e/o generalizzazioni. A differenza delle altre proprietà comunque, non sempre una ridondanza è indesiderata, ma può nascere da precise scelte progettuali. In ogni caso però, queste situazioni vanno documentate. La minimalità di uno schema si può verificare per ispezione, controllando se esistono concetti che possono essere eliminati dallo schema che stiamo costruendo senza inficiare la sua completezza. Per quanto detto, si deve prestare particolare attenzione ai cicli presenti nello schema. Nel prossimo paragrafo illustreremo come la verifica delle qualità di uno schema concettuale appena viste, possa essere inglobata in una metodologia di progettazione generale. 2.8 Metodologia generale In quest ultimo paragrafo vogliamo cercare di tirare le somme su quanto detto relativamente alla progettazione concettuale di base di dati. Per quel che riguarda le strategie di progetto viste, va precisato che, in pratica, non accade quasi mai che un progetto proceda sempre in maniera topdown o bottom-up. Indipendentemente dalla strategia scelta, nelle situazioni reali capita infatti di modificare lo schema in via di costruzione sia con trasformazioni che raffinano un concetto presente (e quindi tipicamente top-down) sia con trasformazioni che aggiungono un concetto non presente (e quindi tipicamente bottom-up). Presentiamo quindi una metodologia per la progettazione concettuale con il modello E-R con riferimento alla strategia mista che, come abbiamo detto, fa uso delle tecniche su cui si basano le altre e le comprende come caso particolare. La metodologia è composta dai passi seguenti. 19

20 1) Analisi dei requisiti 2) Passo base a) Costruzione di un glossario dei termini; b) Analizzare i requisiti ed eliminare le ambiguità presenti; c) Raggruppare i requisiti in insiemi omogenei; a) Individuare i concetti più rilevanti e rappresentarli in uno schema scheletro; 3) Passo di decomposizione (da effettuare se opportuno o necessario) a) Effettuare una decomposizione dei requisiti con riferimento ai concetti presenti nello schema scheletro; 4) Passo iterativo: da ripetere, per tutti i sotto-schemi (se presenti), finché ogni specifica è stata rappresentata. a) Raffinare i concetti presenti sulla base delle loro specifiche; b) Aggiungere nuovi concetti allo schema per descrivere specifiche non ancora descritte; 5) Passo di integrazione (da effettuare se sono presenti diversi sotto-schemi) 6) Analisi di qualità a) Integrare i vari sottoschemi in uno schema generale facendo riferimento allo schema scheletro; a) Verificare la correttezza dello schema ed eventualmente ristrutturare lo schema; b) Verificare la completezza dello schema ed eventualmente ristrutturare lo schema; c) Verificare la minimalità, documentare le ridondanze ed eventualmente ristrutturare lo schema; d) Verificare la leggibilità dello schema ed eventualmente ristrutturare lo schema. Si osservi che se il passo 3) e il passo 5) non vengono effettuati e nel passo 4) si procede solo mediante raffinamenti (azione a)), abbiamo una strategia top-down pura. Viceversa se il passo base non viene effettuato e nel passo 5) vengono solo aggiunti nuovi concetti, ci stiamo muovendo secondo la strategia bottom-up pura. Infine, nelle trasformazioni bottom-up, si può procedere a macchia d olio, cioè secondo la strategia inside-out. Si noti inoltre che nell ultimo passo c è una verifica finale della completezza, sebbene la verifica di tale proprietà viene fatta anche a ogni esecuzione del passo iterativo. Concludiamo questa presentazione con una breve riflessione sulla fase finale della metodologia presentata, quello dell analisi della qualità del progetto. Questo ultimo passo costituisce in effetti un importante momento di verifica del risultato dell intera attività di progettazione, nel quale è spesso necessario dover effettuare delle ristrutturazioni per rimediare a errori fatti nelle fasi precedenti. Bisogna porre, in questa fase, particolare attenzione a concetti dello schema aventi proprietà particolari: per esempio, entità senza attributi, insiemi di concetti che formano cicli, gerarchie di generalizzazione troppo complesse o porzioni dello schema particolarmente contorte. Come accennato in precedenza, non è detto che questa analisi porti necessariamente a delle ristrutturazioni, ma solo a una riorganizzazione dello schema che ne aumenta la leggibilità. È 20

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Progettazione Basi Dati: Metodologie e modelli!modello Entita -Relazione Progettazione Base Dati Introduzione alla Progettazione: Il ciclo di vita di un Sist. Informativo

Dettagli

Progettazione concettuale

Progettazione concettuale Progettazione concettuale Strategie top-down A partire da uno schema che descrive le specifiche mediante pochi concetti molto astratti, si produce uno schema concettuale mediante raffinamenti successivi

Dettagli

La Progettazione Concettuale

La Progettazione Concettuale La Progettazione Concettuale Università degli Studi del Sannio Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica CorsodiBasidiDati Anno Accademico 2006/2007 docente: ing. Corrado Aaron Visaggio

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

Basi di dati. (Sistemi Informativi) teoria e pratica con Microsoft Access. Basi di dati. Basi di dati. Basi di dati e DBMS DBMS DBMS

Basi di dati. (Sistemi Informativi) teoria e pratica con Microsoft Access. Basi di dati. Basi di dati. Basi di dati e DBMS DBMS DBMS Basi di Basi di (Sistemi Informativi) Sono una delle applicazioni informatiche che hanno avuto il maggiore utilizzo in uffici, aziende, servizi (e oggi anche sul web) Avete già interagito (magari inconsapevolmente)

Dettagli

Database. Si ringrazia Marco Bertini per le slides

Database. Si ringrazia Marco Bertini per le slides Database Si ringrazia Marco Bertini per le slides Obiettivo Concetti base dati e informazioni cos è un database terminologia Modelli organizzativi flat file database relazionali Principi e linee guida

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

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

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

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

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi Indice generale OOA Analisi Orientata agli Oggetti Introduzione Analisi Metodi d' analisi Analisi funzionale Analisi del flusso dei dati Analisi delle informazioni Analisi Orientata agli Oggetti (OOA)

Dettagli

SISTEMI INFORMATIVI AVANZATI -2010/2011 1. Introduzione

SISTEMI INFORMATIVI AVANZATI -2010/2011 1. Introduzione SISTEMI INFORMATIVI AVANZATI -2010/2011 1 Introduzione In queste dispense, dopo aver riportato una sintesi del concetto di Dipendenza Funzionale e di Normalizzazione estratti dal libro Progetto di Basi

Dettagli

Informatica Industriale Modello funzionale: Informazione Progettazione concettuale

Informatica Industriale Modello funzionale: Informazione Progettazione concettuale DIIGA - Università Politecnica delle Marche A.A. 2006/2007 Informatica Industriale Modello funzionale: Informazione Progettazione concettuale Luca Spalazzi spalazzi@diiga.univpm.it www.diiga.univpm.it/~spalazzi/

Dettagli

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Analisi Giulio Destri Ing. del software: Analisi - 1 Scopo del modulo Definire

Dettagli

Automazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it

Automazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it Automazione Industriale (scheduling+mms) scheduling+mms adacher@dia.uniroma3.it Introduzione Sistemi e Modelli Lo studio e l analisi di sistemi tramite una rappresentazione astratta o una sua formalizzazione

Dettagli

Sommario. Definizione di informatica. Definizione di un calcolatore come esecutore. Gli algoritmi.

Sommario. Definizione di informatica. Definizione di un calcolatore come esecutore. Gli algoritmi. Algoritmi 1 Sommario Definizione di informatica. Definizione di un calcolatore come esecutore. Gli algoritmi. 2 Informatica Nome Informatica=informazione+automatica. Definizione Scienza che si occupa dell

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

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

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni Introduzione Ai Data Bases Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni I Limiti Degli Archivi E Il Loro Superamento Le tecniche di gestione delle basi di dati nascono

Dettagli

Progettazione di basi di dati. Progettazione di basi di dati. Ciclo di vita dei sistemi informativi. Fasi del ciclo di vita [1]

Progettazione di basi di dati. Progettazione di basi di dati. Ciclo di vita dei sistemi informativi. Fasi del ciclo di vita [1] Progettazione di basi di dati Progettazione di basi di dati Requisiti progetto Base di dati Struttura Caratteristiche Contenuto Metodologia in 3 fasi Progettazione concettuale Progettazione logica Progettazione

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

Progettazione di una base di dati Ufficio della Motorizzazione

Progettazione di una base di dati Ufficio della Motorizzazione Corso di Gestione dell Informazione Studenti NON frequentanti A.A. 2008/2009 1 Scopo del progetto Progettazione di una base di dati Ufficio della Motorizzazione Si vuole realizzare un applicazione base

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

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

Gestione Voti Scolastici

Gestione Voti Scolastici Gestione Voti Scolastici Progettare un modello di dati per la gestione delle informazioni riguardanti le prove, nelle diverse materie, sostenute dagli studenti di una scuola media superiore. Il sistema

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

CORSO ACCESS PARTE II. Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?)

CORSO ACCESS PARTE II. Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?) Ambiente Access La Guida di Access Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?) Guida in linea Guida rapida Assistente di Office indicazioni

Dettagli

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico Introduzione alle basi di dati Introduzione alle basi di dati Gestione delle informazioni Base di dati Modello dei dati Indipendenza dei dati Accesso ai dati Vantaggi e svantaggi dei DBMS Gestione delle

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

APPUNTI DI MATEMATICA LE FRAZIONI ALGEBRICHE ALESSANDRO BOCCONI

APPUNTI DI MATEMATICA LE FRAZIONI ALGEBRICHE ALESSANDRO BOCCONI APPUNTI DI MATEMATICA LE FRAZIONI ALGEBRICHE ALESSANDRO BOCCONI Indice 1 Le frazioni algebriche 1.1 Il minimo comune multiplo e il Massimo Comun Divisore fra polinomi........ 1. Le frazioni algebriche....................................

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

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

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

Progettazione di un Database

Progettazione di un Database Progettazione di un Database Per comprendere il processo di progettazione di un Database deve essere chiaro il modo con cui vengono organizzati e quindi memorizzati i dati in un sistema di gestione di

Dettagli

Dalla progettazione concettuale alla modellazione di dominio

Dalla progettazione concettuale alla modellazione di dominio Luca Cabibbo A P S Analisi e Progettazione del Software Dalla progettazione concettuale alla modellazione di dominio Capitolo 91 marzo 2015 Se qualcuno vi avvicinasse in un vicolo buio dicendo psst, vuoi

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

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

Gli attributi di STUDENTE saranno: Matricola (chiave primaria), Cognome, Nome.

Gli attributi di STUDENTE saranno: Matricola (chiave primaria), Cognome, Nome. Prof. Francesco Accarino Raccolta di esercizi modello ER Esercizio 1 Un università vuole raccogliere ed organizzare in un database le informazioni sui propri studenti in relazione ai corsi che essi frequentano

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

Esercizio data base "Biblioteca"

Esercizio data base Biblioteca Rocco Sergi Esercizio data base "Biblioteca" Database 2: Biblioteca Testo dell esercizio Si vuole realizzare una base dati per la gestione di una biblioteca. La base dati conterrà tutte le informazioni

Dettagli

Database 1 biblioteca universitaria. Testo del quesito

Database 1 biblioteca universitaria. Testo del quesito Database 1 biblioteca universitaria Testo del quesito Una biblioteca universitaria acquista testi didattici su indicazione dei professori e cura il prestito dei testi agli studenti. La biblioteca vuole

Dettagli

Metodologie per la Progettazione Concettuale

Metodologie per la Progettazione Concettuale Metodologie per la Progettazione Concettuale Raccolta e analisi dei requisiti Scegliere il corretto livello di astrazione Standardizzare la struttura delle frasi Evitare frasi contorte Individuare sinonimi

Dettagli

ISTITUTO TECNICO ECONOMICO MOSSOTTI

ISTITUTO TECNICO ECONOMICO MOSSOTTI CLASSE III INDIRIZZO S.I.A. UdA n. 1 Titolo: conoscenze di base Conoscenza delle caratteristiche dell informatica e degli strumenti utilizzati Informatica e sistemi di elaborazione Conoscenza delle caratteristiche

Dettagli

Corso di Access. Prerequisiti. Modulo L2A (Access) 1.1 Concetti di base. Utilizzo elementare del computer Concetti fondamentali di basi di dati

Corso di Access. Prerequisiti. Modulo L2A (Access) 1.1 Concetti di base. Utilizzo elementare del computer Concetti fondamentali di basi di dati Corso di Access Modulo L2A (Access) 1.1 Concetti di base 1 Prerequisiti Utilizzo elementare del computer Concetti fondamentali di basi di dati 2 1 Introduzione Un ambiente DBMS è un applicazione che consente

Dettagli

Alla ricerca dell algoritmo. Scoprire e formalizzare algoritmi.

Alla ricerca dell algoritmo. Scoprire e formalizzare algoritmi. PROGETTO SeT Il ciclo dell informazione Alla ricerca dell algoritmo. Scoprire e formalizzare algoritmi. Scuola media Istituto comprensivo di Fagagna (Udine) Insegnanti referenti: Guerra Annalja, Gianquinto

Dettagli

I Sistemi Informativi

I Sistemi Informativi I Sistemi Informativi Definizione Un Sistema Informativo è un mezzo per acquisire, organizzare, correlare, elaborare e distribuire le informazioni che riguardano una realtà che si desidera descrivere e

Dettagli

EXPLOit Content Management Data Base per documenti SGML/XML

EXPLOit Content Management Data Base per documenti SGML/XML EXPLOit Content Management Data Base per documenti SGML/XML Introduzione L applicazione EXPLOit gestisce i contenuti dei documenti strutturati in SGML o XML, utilizzando il prodotto Adobe FrameMaker per

Dettagli

Introduzione alla teoria dei database relazionali. Come progettare un database

Introduzione alla teoria dei database relazionali. Come progettare un database Introduzione alla teoria dei database relazionali Come progettare un database La struttura delle relazioni Dopo la prima fase di individuazione concettuale delle entità e degli attributi è necessario passare

Dettagli

Base di dati e sistemi informativi

Base di dati e sistemi informativi Base di dati e sistemi informativi Una base di dati è un insieme organizzato di dati opportunamente strutturato per lo svolgimento di determinate attività La base di dati è un elemento fondamentale per

Dettagli

Soluzione dell esercizio del 2 Febbraio 2004

Soluzione dell esercizio del 2 Febbraio 2004 Soluzione dell esercizio del 2 Febbraio 2004 1. Casi d uso I casi d uso sono riportati in Figura 1. Figura 1: Diagramma dei casi d uso. E evidenziato un sotto caso di uso. 2. Modello concettuale Osserviamo

Dettagli

DATABASE. A cura di Massimiliano Buschi

DATABASE. A cura di Massimiliano Buschi DATABASE A cura di Massimiliano Buschi Introduzione Con Microsoft Access: Immissione dati e interrogazione Interfaccia per applicazioni e report Ma prima bisogna definire alcune conoscenze di base sui

Dettagli

Rappresentazione grafica di entità e attributi

Rappresentazione grafica di entità e attributi PROGETTAZIONE CONCETTUALE La progettazione concettuale, ha il compito di costruire e definire una rappresentazione corretta e completa della realtà di interesse, e il prodotto di tale attività, è lo schema

Dettagli

Basi di dati. Concetti Introduttivi ESEMPIO. Fisica, Analisi, Informatica. Entità Relazioni Interrogazioni. Database 2

Basi di dati. Concetti Introduttivi ESEMPIO. Fisica, Analisi, Informatica. Entità Relazioni Interrogazioni. Database 2 Basi di dati Concetti Introduttivi ESEMPIO Fisica, Analisi, Informatica Entità Relazioni Interrogazioni Database 2 Tabella (I) STUDENTE Attributi Data di Nascita Indirizzo Matricola Luca Neri 27/10/1980

Dettagli

Stefania Marrara - Esercitazioni di Tecnologie dei Sistemi Informativi. Integrazione di dati di sorgenti diverse

Stefania Marrara - Esercitazioni di Tecnologie dei Sistemi Informativi. Integrazione di dati di sorgenti diverse Politecnico di Milano View integration 1 Integrazione di dati di sorgenti diverse Al giorno d oggi d la mole di informazioni che viene gestita in molti contesti applicativi è enorme. In alcuni casi le

Dettagli

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Corso di Laurea Magistrale in Ingegneria per l Ambiente e il Territorio A.A. 2014-2015 Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Strutture di dati: DB e DBMS DATO E INFORMAZIONE Dato: insieme

Dettagli

La Metodologia adottata nel Corso

La Metodologia adottata nel Corso La Metodologia adottata nel Corso 1 Mission Statement + Glossario + Lista Funzionalià 3 Descrizione 6 Funzionalità 2 Schema 4 Schema 5 concettuale Logico EA Relazionale Codice Transazioni In PL/SQL Schema

Dettagli

Fasi del ciclo di vita del software (riassunto) Progetto: generalità. Progetto e realizzazione (riassunto)

Fasi del ciclo di vita del software (riassunto) Progetto: generalità. Progetto e realizzazione (riassunto) Università degli Studi di Roma La Sapienza Facoltà di Ingegneria Sede di Latina Laurea in Ingegneria dell Informazione Fasi del ciclo di vita del software (riassunto) Corso di PROGETTAZIONE DEL SOFTWARE

Dettagli

I database relazionali sono il tipo di database attualmente piu diffuso. I motivi di questo successo sono fondamentalmente due:

I database relazionali sono il tipo di database attualmente piu diffuso. I motivi di questo successo sono fondamentalmente due: Il modello relazionale I database relazionali sono il tipo di database attualmente piu diffuso. I motivi di questo successo sono fondamentalmente due: 1. forniscono sistemi semplici ed efficienti per rappresentare

Dettagli

Traccia di soluzione dell esercizio del 25/1/2005

Traccia di soluzione dell esercizio del 25/1/2005 Traccia di soluzione dell esercizio del 25/1/2005 1 Casi d uso I casi d uso sono in Figura 1. Ci sono solo due attori: il Capo officina e il generico Meccanico. Figura 1: Diagramma dei casi d uso. 2 Modello

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

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

MODELLO E/R. Modellazione dei dati

MODELLO E/R. Modellazione dei dati MODELLO E/R Maria Mirto Modellazione dei dati Modellare i dati significa: costruire una rappresentazione semplificata della realtà osservata, individuandone gli elementi caratterizzanti e i legami intercorrenti

Dettagli

Capitolo 13. Interrogare una base di dati

Capitolo 13. Interrogare una base di dati Capitolo 13 Interrogare una base di dati Il database fisico La ridondanza è una cosa molto, molto, molto brutta Non si devono mai replicare informazioni scrivendole in più posti diversi nel database Per

Dettagli

Il database management system Access

Il database management system Access Il database management system Access Corso di autoistruzione http://www.manualipc.it/manuali/ corso/manuali.php? idcap=00&idman=17&size=12&sid= INTRODUZIONE Il concetto di base di dati, database o archivio

Dettagli

Esercitazione di Basi di Dati

Esercitazione di Basi di Dati Esercitazione di Basi di Dati Corso di Fondamenti di Informatica 6 Maggio 2004 Come costruire una ontologia Marco Pennacchiotti pennacchiotti@info.uniroma2.it Tel. 0672597334 Ing.dell Informazione, stanza

Dettagli

DATABASE RELAZIONALI

DATABASE RELAZIONALI 1 di 54 UNIVERSITA DEGLI STUDI DI NAPOLI FEDERICO II DIPARTIMENTO DI DISCIPLINE STORICHE ETTORE LEPORE DATABASE RELAZIONALI Dott. Simone Sammartino Istituto per l Ambiente l Marino Costiero I.A.M.C. C.N.R.

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

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

BASI DI DATI - : I modelli di database

BASI DI DATI - : I modelli di database BASI DI DATI - : I modelli di database DAL 1960 ci si e' orientati verso 3 direzioni: 1 MODELLO GERARCHICO Se i dati si presentano naturalmente in una struttura ad albero (ES. File System) Limiti: rigidità

Dettagli

Siamo così arrivati all aritmetica modulare, ma anche a individuare alcuni aspetti di come funziona l aritmetica del calcolatore come vedremo.

Siamo così arrivati all aritmetica modulare, ma anche a individuare alcuni aspetti di come funziona l aritmetica del calcolatore come vedremo. DALLE PESATE ALL ARITMETICA FINITA IN BASE 2 Si è trovato, partendo da un problema concreto, che con la base 2, utilizzando alcune potenze della base, operando con solo addizioni, posso ottenere tutti

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

COMUNE DI RAVENNA GUIDA ALLA VALUTAZIONE DELLE POSIZIONI (FAMIGLIE, FATTORI, LIVELLI)

COMUNE DI RAVENNA GUIDA ALLA VALUTAZIONE DELLE POSIZIONI (FAMIGLIE, FATTORI, LIVELLI) COMUNE DI RAVENNA Il sistema di valutazione delle posizioni del personale dirigente GUIDA ALLA VALUTAZIONE DELLE POSIZIONI (FAMIGLIE, FATTORI, LIVELLI) Ravenna, Settembre 2004 SCHEMA DI SINTESI PER LA

Dettagli

Generazione Automatica di Asserzioni da Modelli di Specifica

Generazione Automatica di Asserzioni da Modelli di Specifica UNIVERSITÀ DEGLI STUDI DI MILANO BICOCCA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea Magistrale in Informatica Generazione Automatica di Asserzioni da Modelli di Specifica Relatore:

Dettagli

Progettazione di Database. Un Esempio

Progettazione di Database. Un Esempio Progettazione di Database Un Esempio Data Base Management System Applicazione 1 Applicazione 2 Applicazione 3 DBMS A B C D E Il Modello Relazionale Una relazione è costituita su un insieme di domini, non

Dettagli

Le Basi di Dati. Le Basi di Dati

Le Basi di Dati. Le Basi di Dati Le Basi di Dati 20/05/02 Prof. Carlo Blundo 1 Le Basi di Dati Le Base di Dati (database) sono un insieme di tabelle di dati strutturate in maniera da favorire la ricerca di informazioni specializzate per

Dettagli

Concetti di base di ingegneria del software

Concetti di base di ingegneria del software Concetti di base di ingegneria del software [Dalle dispense del corso «Ingegneria del software» del prof. A. Furfaro (UNICAL)] Principali qualità del software Correttezza Affidabilità Robustezza Efficienza

Dettagli

I casi d uso corrispondono ai compiti che l attore (che può essere una persona fisica e non) può svolgere.

I casi d uso corrispondono ai compiti che l attore (che può essere una persona fisica e non) può svolgere. UML e i Casi d USO I casi d uso specificano una sequenza di azioni che producono un risultato visibile agli attori del sistema. Essi nascono per fornire descrizioni delle capacità del sistema. I casi d

Dettagli

Fasi di creazione di un programma

Fasi di creazione di un programma Fasi di creazione di un programma 1. Studio Preliminare 2. Analisi del Sistema 6. Manutenzione e Test 3. Progettazione 5. Implementazione 4. Sviluppo 41 Sviluppo di programmi Per la costruzione di un programma

Dettagli

Esercizi su. Funzioni

Esercizi su. Funzioni Esercizi su Funzioni ๒ Varie Tracce extra Sul sito del corso ๓ Esercizi funz_max.cc funz_fattoriale.cc ๔ Documentazione Il codice va documentato (commentato) Leggibilità Riduzione degli errori Manutenibilità

Dettagli

4.5 CONTROLLO DEI DOCUMENTI E DEI DATI

4.5 CONTROLLO DEI DOCUMENTI E DEI DATI Unione Industriale 35 di 94 4.5 CONTROLLO DEI DOCUMENTI E DEI DATI 4.5.1 Generalità La documentazione, per una filatura conto terzi che opera nell ambito di un Sistema qualità, rappresenta l evidenza oggettiva

Dettagli

Linguaggi e Paradigmi di Programmazione

Linguaggi e Paradigmi di Programmazione Linguaggi e Paradigmi di Programmazione Cos è un linguaggio Definizione 1 Un linguaggio è un insieme di parole e di metodi di combinazione delle parole usati e compresi da una comunità di persone. È una

Dettagli

Progettazione Logica. Progettazione Logica

Progettazione Logica. Progettazione Logica Consorzio per la formazione e la ricerca in Ingegneria dell'informazione Tabelle per ogni concetto Docente: Cesare Colombo CEFRIEL colombo@cefriel.it http://www.cefriel.it Passaggio al modello logico (1)

Dettagli

Modello dei Dati ENTITÀ-RELAZIONE (ENTITY-RELATIONSHIP) é l insieme di concetti, simboli, regole che useremo per rappresentare il modello concettuale

Modello dei Dati ENTITÀ-RELAZIONE (ENTITY-RELATIONSHIP) é l insieme di concetti, simboli, regole che useremo per rappresentare il modello concettuale Modello dei Dati E-R ENTITÀ-RELAZIONE O (ENTITY-RELATIONSHIP) é l insieme di concetti, simboli, regole che useremo per rappresentare il modello concettuale R.Gori - G.Leoni Modello dei Dati Entità-Relazione

Dettagli

1. PRIME PROPRIETÀ 2

1. PRIME PROPRIETÀ 2 RELAZIONI 1. Prime proprietà Il significato comune del concetto di relazione è facilmente intuibile: due elementi sono in relazione se c è un legame tra loro descritto da una certa proprietà; ad esempio,

Dettagli

Soluzione dell esercizio del 12 Febbraio 2004

Soluzione dell esercizio del 12 Febbraio 2004 Soluzione dell esercizio del 12/2/2004 1 Soluzione dell esercizio del 12 Febbraio 2004 1. Casi d uso I casi d uso sono riportati in Figura 1. Figura 1: Diagramma dei casi d uso. 2. Modello concettuale

Dettagli

Project Cycle Management La programmazione della fase di progettazione esecutiva. La condivisione dell idea progettuale.

Project Cycle Management La programmazione della fase di progettazione esecutiva. La condivisione dell idea progettuale. Project Cycle Management La programmazione della fase di progettazione esecutiva. La condivisione dell idea progettuale. Il presente materiale didattico costituisce parte integrante del percorso formativo

Dettagli

5.2.1 RELAZIONI TRA TABELLE 1. 5.2.4.1 Creare una relazione uno-a-uno, uno-a-molti tra tabelle 9

5.2.1 RELAZIONI TRA TABELLE 1. 5.2.4.1 Creare una relazione uno-a-uno, uno-a-molti tra tabelle 9 5.2.1 RELAZIONI TRA TABELLE 1 5.2.4.1 Creare una relazione uno-a-uno, uno-a-molti tra tabelle 9 Il grado di un verso di un associazione indica quanti record della tabella di partenza si associano ad un

Dettagli

Basi di Dati e Microsoft Access

Basi di Dati e Microsoft Access Basi di Dati e Microsoft Access Lun: 16-18 e Mer: 14-17 Alessandro Padovani padoale@email.it Database: definizione Un database (DB) è una collezione di informazioni organizzata in gruppi, che consentono

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

GENERALIZZAZIONE E SPECIALIZZAZIONE ISA 1

GENERALIZZAZIONE E SPECIALIZZAZIONE ISA 1 GENERALIZZAZIONE E SPECIALIZZAZIONE ISA 1 Le gerarchie spesso nella analisi di un settore aziendale può risultare che più entità risultino simili o casi particolari l una dell altra, derivanti da viste

Dettagli

MODULO 5 Appunti ACCESS - Basi di dati

MODULO 5 Appunti ACCESS - Basi di dati MODULO 5 Appunti ACCESS - Basi di dati Lezione 1 www.mondopcnet.com Modulo 5 basi di dati Richiede che il candidato dimostri di possedere la conoscenza relativa ad alcuni concetti fondamentali sui database.

Dettagli

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

Dettagli

I database. Cosa sono e a cosa servono i Database

I database. Cosa sono e a cosa servono i Database I database Estratto dal Modulo 1 - I database Prof. Piero GALLO 1 Cosa sono e a cosa servono i Database Un database(o base di dati) e' una raccolta organizzata di dati correlati. Il principale scopo di

Dettagli

Prova scritta del corso di Basi di dati attive 17 Dicembre 1999. Agenzia

Prova scritta del corso di Basi di dati attive 17 Dicembre 1999. Agenzia Prova scritta del corso di Basi di dati attive 17 Dicembre 1999 Si desidera automatizzare la gestione dei banchetti organizzati da un agenzia di pubbliche relazioni. Le specifiche del sistema informativo,

Dettagli

Lezione 1. Introduzione e Modellazione Concettuale

Lezione 1. Introduzione e Modellazione Concettuale Lezione 1 Introduzione e Modellazione Concettuale 1 Tipi di Database ed Applicazioni Database Numerici e Testuali Database Multimediali Geographic Information Systems (GIS) Data Warehouses Real-time and

Dettagli

BASE DI DATI: introduzione. Informatica 5BSA Febbraio 2015

BASE DI DATI: introduzione. Informatica 5BSA Febbraio 2015 BASE DI DATI: introduzione Informatica 5BSA Febbraio 2015 Di cosa parleremo? Base di dati relazionali, modelli e linguaggi: verranno presentate le caratteristiche fondamentali della basi di dati. In particolare

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T3 1-Sottoprogrammi 1 Prerequisiti Tecnica top-down Programmazione elementare 2 1 Introduzione Lo scopo di questa Unità è utilizzare la metodologia di progettazione top-down

Dettagli

2003.06.16 Il sistema C.R.M. / E.R.M.

2003.06.16 Il sistema C.R.M. / E.R.M. 2003.06.16 Il sistema C.R.M. / E.R.M. Customer / Enterprise : Resource Management of Informations I-SKIPPER è un sistema di CONOSCENZE che raccoglie ed integra INFORMAZIONI COMMERCIALI, dati su Clienti,

Dettagli

I Problemi e la loro Soluzione. Il Concetto Intuitivo di Calcolatore. Risoluzione di un Problema. Esempio

I Problemi e la loro Soluzione. Il Concetto Intuitivo di Calcolatore. Risoluzione di un Problema. Esempio Il Concetto Intuitivo di Calcolatore Fondamenti di Informatica A Ingegneria Gestionale Università degli Studi di Brescia Docente: Prof. Alfonso Gerevini I Problemi e la loro Soluzione Problema: classe

Dettagli

Basi di dati 9 febbraio 2010 Compito A

Basi di dati 9 febbraio 2010 Compito A Basi di dati 9 febbraio 2010 Compito A Domanda 0 (5%) Leggere e rispettare le seguenti regole: Scrivere nome, cognome, matricola (se nota), corso di studio e lettera del compito (ad esempio, A) sui fogli

Dettagli