Modellazione concettuale

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Modellazione concettuale"

Transcript

1 Sistemi Informativi Avanzati Anno Accademico 2011/2012 Prof. Domenico Beneventano Modellazione concettuale Versione estesa rispetto alle dispense originali realizzate dal Prof. Stefano Rizzi e state tratte dal suo libro Data Warehouse - teoria e pratica della Progettazione Autori: Matteo Golfarelli, Stefano Rizzi; Editore: McGraw-Hill Le estensioni riguardano sia l introduzione di esempi sia la descrizione più approfondita di alcuni concetti. Alcuni concetti sono già stati trattati nell introduzione al modello multidimensionale; i relativi lucidi sono qui ripetuti solo per completezza.

2 Quale formalismo? Mentre è universalmente riconosciuto che un DW si appoggia sul modello multidimensionale, non cè accordo sul formalismo di modellazione concettuale e quindi sulla metodologia di progettazione concettuale. Il modello Entity/Relationship è molto diffuso nelle imprese come formalismo per la documentazione dei sistemi informativi relazionali, ma non può essere usato per modellare il DW. 2

3 Il Dimensional Fact Model (DFM) E un modello concettuale grafico per data mart, pensato per: supportare efficacemente il progetto concettuale; creare un ambiente su cui formulare in modo intuitivo le interrogazioni dellutente; permettere il dialogo tra progettista e utente finale per raffinare le specifiche dei requisiti; creare una piattaforma stabile da cui partire per il progetto logico (indipendentemente dal modello logico target); restituire una documentazione a posteriori espressiva e non ambigua. La rappresentazione concettuale generata dal DFM consiste in un insieme di schemi di fatto. Gli elementi di base modellati dagli schemi di fatto sono i fatti, le misure, le dimensioni e le gerarchie 3

4 Il DFM: costrutti di base Un fatto è un concetto di interesse per il processo decisionale; tipicamente modella un insieme di eventi che accadono nellimpresa (ad esempio: vendite, spedizioni,...). È essenziale che un fatto abbia aspetti dinamici, ovvero evolva nel tempo Una misura è una proprietà numerica di un fatto e ne descrive un aspetto quantitativo di interesse per lanalisi (ad esempio, ogni vendita è misurata dal suo incasso) Una dimensione è una proprietà con dominio finito di un fatto e ne descrive una coordinata di analisi (dimensioni tipiche per il fatto vendite sono prodotto, negozio, data) fatto prodotto Un fatto esprime una associazione molti-a-molti tra le dimensioni dimensione misura data VENDITA quantità v enduta incasso num. clienti prezzo unitari o negozi o 4

5 Il DFM: costrutti di base Con attributo dimensionale si intendono le dimensioni e gli altri attributi, che le descrivono (per esempio, un prodotto è descritto dal suo tipo, dalla categoria cui appartiene, dalla sua marca, dal reparto in cui è venduto) Una gerarchia è un albero direzionato i cui nodi sono attributi dimensionali e i cui archi rappresentano associazioni molti-auno tra coppie di attributi dimensionali: larco da X a Y rappresenta la dipendenza funzionale X Y La gerarchia racchiude una dimensione, posta alla radice dellalbero, e tutti gli attributi dimensionali che la descrivono attributo dimensionale anno trime stre mese gio rn o vacanza settimana data gruppo di marketin g prodot to tipo VENDIT A quan tità ve nduta incasso num. clie nti prezzo u nitario categoria marca reparto cit tà dell a marca responsabi le d elle vendite distretto di vendita nego zio gerarchia cit tà del regio ne nego zio sta to 5

6 6 vacanza responsabile delle vendite distretto di vendita settimana negozio PRODOTTO NEGOZIO DATA qtà venduta incasso prezzo unitario num. clienti data prodotto MESE mese TRIMESTRE trimestre ANNO anno città CITT regione REGIONE stato STATO tipo TIPO categoria CATEGORIA reparto REPARTO MARCA marca CITT MARCA città marca (0,n) (0,n) (0,n) vendita RESP. VENDITE DISTRETTO VENDITA giorno VACANZA GIORNO SETTIMANA GRUPPO MARKETING gruppo marketing Il DFM: corrispondenza con le/r

7 Naming conventions Tutti gli attributi dimensionali in ciascuno schema di fatto devono avere nomi diversi Eventuali nomi uguali devono essere differenziati qualificandoli con il nome di un attributo dimensionale che li precede nella gerarchia Ad esempio, warehouse city è la città in cui si trova un magazzino, mentre store city è la città in cui si trova un negozio I nomi degli attributi non dovrebbero riferirsi esplicitamente al fatto a cui appartengono Ad esempio, si evitino shipped product e shipment date Attributi con lo stesso significato in schemi diversi devono avere lo stesso nome 7

8 Eventi primari e dimensioni Un evento primario è una particolare occorrenza di un fatto, individuata da una ennupla costituita da un valore per ciascuna dimensione. A ciascun evento primario è associato un valore per ciascuna misura Nelle vendite, un possibile evento primario registra per esempio che, il 10/10/2001, nel negozio NonSoloPappa sono state vendute 10 confezioni di detersivo Brillo per un incasso complessivo di 25 euro Un fatto F con n dimensioni Dim 1,, Dim n e k misure Mis 1,, Mis k si può considerare come una relazione F(Dim 1,, Dim n, Mis 1,, Mis k ) che ha come chiave D = { Dim 1,, Dim n } quindi ciascuna misura dipende funzionalmente da D Questo parallelo con il modello relazionale ci consente di parlare di dipendenze funzionali tra le dimensioni, tra le dimensioni e le misure 8

9 Eventi secondari e pattern Dato un insieme di attributi dimensionali (pattern), ciascuna ennupla di loro valori individua un evento secondario che aggrega tutti gli eventi primari corrispondenti. A ciascun evento secondario è associato un valore per ciascuna misura, che riassume in sé tutti i valori della stessa misura negli eventi primari corrispondenti Pertanto, le gerarchie definiscono il modo in cui gli eventi primari possono essere aggregati e selezionati significativamente per il processo decisionale; mentre la dimensione in cui una gerarchia ha radice ne definisce la granularità più fine di aggregazione, agli altri attributi dimensionali corrispondono granularità via via crescenti Pattern Primario e Pattern Secondari Pattern primario: è il pattern formato dallinsieme delle dimensioni Pattern secondario: è un qualsiasi altro pattern diverso dal primario, ovvero contenente almeno un attributo dimensionale che non è una dimensione 9

10 Eventi e aggregazione Evento secondario (1-2001,Roma,Viteria) Evento secondario (1-2001,Viteria) città! negozio tipo! prodotto tipo! prodotto mese Pattern secondario {mese,tipo-prodotto} mese negozio Evento primario ( ,BigWare,Vite) data prodotto Pattern primario {data,negozio,prodotto} 10

11 Pattern ed aggregazione Un pattern secondario specifica un aggregazione P1 = {Prodotto, Regione,Data} " P2 = { Tipo, Regione, Mese, Giorno} " P3 = {Tipo,Trimestre} " " Pn = {} " Un pattern che contiene due attributi dimensionali A e B tali che A B è non significativo in quanto il raggruppamento su A,B equivale al raggruppamento su A P = { Tipo, Regione, Mese, Giorno, Stato} è non significativo in quanto Regione Stato Nella visualizzazione bi-dimensionale di A e B, la DF A B comporta che per ogni A ci sarà un solo B corrispondente e quindi un solo evento secondario del pattern { A, B} Nel caso di pattern primario non significativo si parla di Dipendenze funzionali tra le dimensioni 11

12 Pattern: roll-up e drill-down Dati due pattern P1 e P2 con P1 P2, allora passare da P1 a P2 (da P2 a P1) significa aumentare (diminuire) l aggregazione, ovvero effettuare un roll-up (drill-down). " Esempi di roll-up {Prodotto, Regione,Data} { Tipo, Regione, Trimestre} " {Prodotto, Regione,Data} {Prodotto, Regione }" Dati due pattern significativi P1 e P2, se P1 P2 allora P1 P2, quindi passare da P1 a P2 (da P2 a P1) significa fare un roll-up (drill-down). " Passare da P = {Regione, Mese, Giorno, Stato} non significativo al sottoinsieme P = {Regione, Mese, Giorno} non implica nessun roll-up" Nel seguito per pattern si intende un pattern significativo, ovvero privo di dipendenze funzionali tra i suoi elementi. Un pattern è anche detto cuboide. 12

13 Reticolo di roll-up Dato uno schema di fatto F, l insieme dei suoi pattern ordinato sulla base della relazione di dipendenza funzionale è detto reticolo di roll-up " PRODOTTO NEGOZIO CASSA VENDITA Reticolo di roll-up CASSA, PRODOTTO Pattern: 1. {CASSA,PRODOTTO} 2. {NEGOZIO,PRODOTTO} 3. {CASSA} 4. {PRODOTTO} 5. {NEGOZIO} 6. {} NEGOZIO, PRODOTTO NEGOZIO PRODOTTO { } CASSA 13

14 Reticolo di roll-up Per semplicità, le sono rappresentate (a volte) da linee, e si intendono dall alto verso il basso: {CASSA,PRODOTTO} {NEGOZIO,PRODOTTO} Sono riportate solo le dirette e non quelle indirette, quali {CASSA,PRODOTTO} {NEGOZIO} CASSA, PRODOTTO NEGOZIO, PRODOTTO NEGOZIO PRODOTTO CASSA { } " Diamone una definizione formale 14

15 Perchè si chiama Reticolo? L ordinamento dei pattern in base alla relazione è " 1. Parziale " tra P1 = {Regione} e P2 = {Tipo,Trimestre} non c è relazione" 2. Ha come elemento massimo (che determina tutti gli altri) il pattern primario P0 " 3. Ha come elemento minimo (determinato da tutti gli altri) il pattern vuoto Pn = {} 4. Inoltre ogni coppia di pattern ha un estremo superiore ed un estremo inferiore " La coppia di pattern Px = {Tipo,Trimestre} e Py = {Prodotto,Anno} ha come estremo superiore Psup = {Prodotto,Trimestre} : infatti Psup Px e Psup Py e come estremo inferiore Pinf = {Tipo,Anno} : infatti Px Pinf e Py Pinf & L insieme dei pattern ordinato con la relazione è un reticolo " 15

16 Reticolo di roll-up : esempio 16

17 Reticolo di roll-up : considerazioni In uno schema di Fatto con n dimensioni (senza gerarchia) D1, D2,, Dn, i pattern sono 2 n (corrispondono infatti agli elementi dell insieme potenza di {D1, D2,, Dn} Esempio : n=3 17

18 Reticolo di roll-up : considerazioni Nel caso generale in cui le dimensioni hanno una gerarchia associata: i pattern del reticolo di roll-up sono in un numero minore di 2 N, dove N è il numero di attributi dimensionali Esempio : N=4, numero di pattern = 9 18

19 Reticoli di roll-up: Esempio CITTA TIPO NEGOZIO VENDITA PRODOTTO Pattern: 1. {NEGOZIO,PRODOTTO} 2. {CITTA,TIPO,PRODOTTO} 3. {CITTA,PRODOTTO} 4. {TIPO,PRODOTTO} 5. {CITTA,TIPO} 6. {CITTA} 7. {PRODOTTO} 8. {NEGOZIO} 9. {TIPO} 10. {} 19

20 Corrispondenza tra DFM reparto ed E/R REPARTO gruppo marketing GRUPPO stato MARKETING STATO ANNO categoria CATEGORIA semantica dei costrutti del nuovo modello DFM a partire dalla città semantica del modello E/R (e quindi del modello CITT relazionale) marca regione MARCA REGIONE TRIMESTRE tipo TIPO prodotto marca MARCA città CITT MESE prodotto PRODOTTO VENDITA Questa corrispondenza è utile per spiegare il significato, la data quantità v enduta incasso num. clienti prezzo unitari o negozi o negozio NEGOZIO (0,n) (0,n) vendita qtà venduta incasso num. clienti prezzo unitario (0,n) DATA anno trimestre mese data RESP. VENDITE Un fatto esprime una associazione responsabile delle vendite molti-a-molti tra le dimensioni DISTRETTO VENDITA distretto di vendita VACANZA vacanza SETTIMANA GIORNO giorno settimana 20

21 reparto REPARTO Corrispondenza tra DFM ed E/R GRUPPO stato MARKETING STATO categoria CATEGORIA La corrispondenza a livello di istanze: CITT regione MARCA data prodotto VENDITA quantità v enduta incasso num. clienti prezzo unitari o negozi o città negozio REGIONE CITT NEGOZIO tipo prodotto (0,n) TIPO PRODOTTO (0,n) vendita qtà venduta incasso MARCA num. clienti prezzo unitario (0,n) gruppo marketing città marca marca ANNO TRIMESTRE MESE DATA anno trimestre mese data Le istanze del fatto sono gli eventi primari con le corrispondenti misure (si riporta solo Incasso) RESP. VENDITE responsabile delle vendite DISTRETTO VENDITA distretto di vendita VACANZA Le istanze dello schema E/R sono vacanza quelle ottenibili con lo schema relazionale corrispondente (si riporta solo Incasso) SETTIMANA GIORNO giorno settimana 21

22 Corrispondenza tra DFM ed E/R Lassociazione molti-a-molti VENDITA si può anche esprimere, in modo del tutto equivalente, in forma reificata (nello schema E/R sono riportate solo le entità e non gli attributi) prodotto data VENDITA quantità v enduta incasso num. clienti prezzo unitari o negozi o DATA (0,N) VENDITA (0,N) NEGOZIO (0,N) PRODOTTO 22

23 città marca CITT Corrispondenza tra DFM ed E/R regione MARCA REGIONE tipo TIPO marca MARCA città CITT prodotto prodotto PRODOTTO Dimensione Opzionale TRIMESTRE MESE trimestre mese data VE NDITA quantità v enduta incasso num. clienti prezzo unitario negozi o negozio RESP. VENDITE NEGOZIO DISTRETTO VENDITA (0,n) (0,n) vendita qtà venduta incasso (0,N) num. clienti prezzo unitario (0,n) VACANZA DATA data GIORNO Promoz responsabile delle vendite distretto di vendita Promoz vacanza SETTIMANA Questa corrispondenza non è del tutto esatta in quanto nello schema di fatto Promoz è opzionale (cioè ci sono vendite senza la Promoz) mentre nello schema E/R Vendita è un associazione quaternaria che per esistere necessita anche di Promoz Per una corrispondenza esatta si dovrebbe considerare lo schema E/R reificato al quale aggiungere una entità VENDITA_IN_PROMO come subset di VENDITA. giorno settimana si semplifica tutto considerando un particolare valore di PROMOZIONE: 23

24 Corrispondenza tra DFM ed E/R L opzionalità viene codificata con un opportuno valore a livello di eventi primari prodotto data VENDITA quantità v enduta incasso num. clienti prezzo unitari o Promoz negozi o PROMOZ Prodotto Negozi Data Incasso Estate P1 o A 18/4 13 NO_PROMO P2 B 18/4 12 Estate P2 B 18/4 12 Con questa codifica la corrispondenza tra schema di fatto e schema E/R si può considerare esatta se anche nello schema E/R consideriamo che ci sia unistanza di Promoz con valore NO_PROMO, da usare appunto nelle istanze di vendita senza promozione 24

25 Modellazione e progettazione concettuale Modellazione: sintassi e semantica del modello DFM la semantica dei costrutti del modello DFM viene spiegata a partire dalla semantica del modello E/R Progettazione: metodi per progettare uno schema secondo il modello DFM Progettazione a partire da schemi E/R: dato uno schema E/R ed i requisiti del Data Warehouse, progettare lo schema di fatto corrispondente 25

26 Introduzione alla progettazione concettuale a partire da schemi E/R La progettazione concettuale verrà fatta più avanti, dopo aver introdotto tutti gli elementi del modello DFM Le scelte fondamentali che deve fare il progettista durante la progettazione concettuale sono 1. Scelta delle dimensioni e quindi della granularità del fatto 2. Scelta delle misure e dei relativi operatori di aggregazione 3. Scelta della gerarchia associata a ciascuna dimensione 26

27 Definizione delle gerarchie Un arco da X a Y rappresenta la DF X Y ma non tutte le DF (disponibili nello schema E/R) sono riportate in una gerarchia : Una gerarchia deve rappresentare solo quelle dipendenze funzionali che il progettista ritiene utili ai fini dell analisi dei dati. In fase di analisi dei dati, le operazioni OLAP (quali ad esempio roll-up e drill-down) saranno possibili solo lungo gli archi della gerarchia Anche le interrogazioni MDX si basano sugli archi definiti nella gerarchia 27

28 Definizione delle gerarchie: esempio Consideriamo la gerarchia di PRODOTTO in VENDITA Nello schema di fatto possiamo riportare tutta la gerarchia CATEGORIA PRODOTTO VENDITA TIPO oppure decidere che il tipo non è utile ai fini dell analisi: CATEGORIA PRODOTTO VENDITA 28

29 Definizione delle gerarchie: esempio Un altra possibilità è quella di scegliere una granularità meno fine, e quindi non considerare PRODOTTO (schema di fatto temporale): CATEGORIA TIPO VENDITA Un altra possibilità ancora è quella di considerare tutti gli attributi nella gerarchia, ma di non considerare l arco TIPO GATEGORIA: CATEGORIA PRODOTTO VENDITA TIPO Il confronto tra queste possibilità verrà trattato in fase di progettazione concettuale. 29

30 Il DFM: costrutti avanzati Un attributo descrittivo contiene informazioni aggiuntive su un attributo dimensionale, a cui è connesso da una associazione uno-a-uno. Non è usato per laggregazione poiché ha valori continui e/o poiché deriva da unassociazione uno-a-uno Alcuni archi dello schema di fatto possono essere opzionali attributo descrittivo an no trimestre me se gi orno va can za settim ana responsabile da ta pe so capo reparto gr upp o di ma rketin g pr odotto tipo VENDITA ca tego ria ma rca di eta qu antità venduta in cas so nu m. clie nti pr ezzo u ni tario ( AVG) reparto ci ttà d ell a ma rca ne gozio arco opzionale responsabile dell e vendi te di stretto di vendita ci ttà d el stato ne gozio regione indi rizzo telefono 30

31 Il DFM: costrutti avanzati nonaggregabilità anno trimestre mese giorno vacanza settimana respon sabile data peso capo reparto gruppo di marketing prodotto tipo VENDITA categoria marca dieta quantità venduta incasso num. clienti prezzo unitario (AV G) reparto città della marca respon sabile delle vendite distretto di vendita negozi o IVA attributo cross-dimensionale città del stato negozio regione indirizzo convergenza telefono data inizio data fine costo promo zione pubblicità sconto dimensione opzionale 31

32 Convergenza Vincolo di integrità (non esprimibile in E/R): gruppo capo lo stato della marketing città del responsabile negozio deve reparto essere reparto lo stesso di quello del distretto del negozio GRUPPO MARKETING TIPO (0,N) di (1,N) REPARTO Questa informazione è esprimibile sullo schema (1,N) (1,N) di fatto indicando tipouna per convergenza: categoria per la convergenza rappresenta un vincolo di integrità. La convergenza dieta riduce di il numero prezzo (0,1) unitario di pattern nel reticolo di roll-up: Il Pattern peso PRODOTTO { Negozio.DistrettoVendite.Stato, CATEGORIA data (0,N) (1,N) vendita SCONTRINO (1,N) quantità Negozio.Citta.Regione.Stato dimensione } da prodotto magazzino (1,N) ammette come eventi secondari indirizzo solo MAGAZZINO coppie di valori uguali: quindi nel reticolo di roll-up si considera solo {Stato } num. scontrino responsabile vendite (0,N) (1,N) in NEGOZIO in negozio (1,N) di num. distretto DISTRETTO VENDITA (1,N) di indirizzo in (1,N) regione STATO REGIONE (1,N) stato di di CITT telefono città (1,N) prodotta in In un pattern che contiene un attributo MARCA con condivisione o convergenza, per distinguere le due occorrenza marca occorre qualificare con Il percorso nella gerarchia (1,N) 32

33 Il DFM: costrutti avanzati distretto uso del num. chiamante distretto del numero chiamante distretto del numero chiamato uso del num. chiamato prodotto uso numero telefonico SPED IZIONE numero costo chiamante chiamato numero chiamante numero chiamato CHIAMATA numero durata ruolo CHIAMATA numero durata magazzino ordine da ta di sp edi zion e data c liente mese gerarchia condivisa ora data ora data anno mese mese città regione stato anno anno La gerarchia è sicuramente condivisa: il numero del chiamante deve essere diverso dal numero del chiamato È il numero di chiamate, mentre la durata è quella complessiva. 33

34 Condivisione: reticolo di roll-up Attributo CITTA condiviso ESAME FACOLTA STUDENTE CITTA Pattern: 1. {STUDENTE, FACOLTA } 2. {STUDENTE, FACOLTA_CITTA} 3. {FACOLTA, STUDENTE_CITTA } 4. {STUDENTE_CITTA, FACOLTA_CITTA} 5. {FACOLTA_CITTA} 6. {STUDENTE_CITTA} 7. {STUDENTE} 8. {FACOLTA } 9. {} (Per il reticolo: vedi pag. 18) STUDENTE Non ha senso considerare un pattern {CITTA} in quanto con la condivisione si rappresentano due citta: ESAME FACOLTA CITTA_ STUDENTE CITTA_ FACOLTA 34

35 Convergenza: reticolo di roll-up In caso di condivisione: ha senso considerare {CITTA} in quanto un esame non è associato univocamente ad un unica città Nel caso di convergenza ha senso considerare {CITTA} in quanto un esame è associato univocamente ad un unica città! ESAME STUDENTE CITTA Pattern: 1. {STUDENTE, FACOLTA } 2. {STUDENTE} 3. {FACOLTA } 4. {CITTA} 5. {} FACOLTA STUDENTE, FACOTA STUDENTE FACOLTA CITTA { } 35

36 Reticolo di roll-up: esempio Condivisione su CITTA: la città dello studente non coincide necessariamente con quella della facoltà Convergenza su STATO: lo stato (della città) dello studente coincide con lo stato (della città) della facoltà ESAME FACOLTA STUDENTE CITTA Per semplicità, del reticolo di roll-up si riportano solo i pattern, ma non le relazioni tra di loro STATO Pattern: 1. {STUDENTE, FACOLTA } 2. {STUDENTE, FACOLTA_CITTA} 3. {STUDENTE, FACOLTA_STATO} 4. {FACOLTA, STUDENTE_CITTA } 5. {FACOLTA, STUDENTE_STATO} 6. {STUDENTE_CITTA, FACOLTA_CITTA} 7. {STUDENTE_CITTA, FACOLTA_STATO} 8. {STUDENTE_STATO, FACOLTA_CITTA} 9. {FACOLTA_CITTA} 10. {STUDENTE_CITTA} 11. {STATO} 12. {} 36

37 Attributi cross-dimensionali: pattern Attributo cross-dimensionale ANNO (anno di iscrizione di uno studente ad una facoltà) ANNO ESAME STUDENTE FACOLTA Pattern: 1. {STUDENTE, FACOLTA } 2. {STUDENTE, ANNO} 3. {FACOLTA, ANNO } 4. {STUDENTE} 5. {FACOLTA} 6. {ANNO} 7. {} STUDENTE E equivalente allo schema di fatto con tre dimensioni e con dipendenza funzionale tra le dimensioni {STUDENTE,FACOLTA} ANNO che rende non significativo {STUDENTE,FACOLTA, ANNO} ANNO ESAME FACOLTA 37

38 Attributi cross-dimensionali: pattern LUSTRO Attributo cross-dimensionale ANNO (anno di iscrizione di uno studente ad una facoltà) Pattern: ANNO ESAME STUDENTE FACOLTA 1. {STUDENTE, FACOLTA } 2. {STUDENTE, ANNO} 3. {STUDENTE, LUSTRO} 4. {FACOLTA, ANNO } 5. {FACOLTA, LUSTRO} 6. {STUDENTE} 7. {FACOLTA} 8. {ANNO} 9. {LUSTRO} 10. {} E equivalente allo schema di fatto con tre dimensioni e con dipendenza funzionale tra le dimensioni {STUDENTE,FACOLTA} ANNO che rende non significativo {STUDENTE,FACOLTA, ANNO} LUSTRO ANNO ESAME STUDENTE FACOLTA 38

39 Archi e dimensioni opzionali Derivano da una cardinalità minima pari a zero nelle associazioni, ovvero da associazioni opzionali Arco Opzionale Prodotto Dieta Un Prodotto ha una sola Dieta; per alcuni prodotti la dieta è indefinita, ovvero assume un valore NULL A livello di analisi dei dati, normalmente tale valore NULL viene rappresentato con un valore significativo, quale NESSUNA DIETA Dimensione Opzionale Promozione Un evento primario è identificato dalle dimensioni; se una dimensione è opzionale alcuni eventi primari sono identificati solo dalle altre dimensioni: le vendite senza promozione sono identificate da prodotto-negozio-data e con un valore significativo per Promozione, es. NESSUNA PROMOZIONE L opzionalità si propaga ai discendenti nella gerarchia Gli eventi senza promozione non hanno sconto A livello di analisi dei dati, al valore NESSUNA PROMOZIONE faremo corrispondere NESSUN SCONTO per l attributo dimensionale sconto. 39

40 Copertura di un arco opzionale copertura di arco opzionale Prodotto (p,e) data c liente c odord LINEA D'ORD INE quantità importo data sc adenza taglia P-E tipo prodoto c odprod Alimentare data scadenza Abbigliamento taglia La proprietà di copertura influisce sul numero di eventi secondari ammissibili Il Pattern {Data scadenza, Taglia} in caso di copertura esclusiva non ammette eventi secondari 40

41 Arco Multiplo genere VENDITA autore libro numero incasso data mese anno arco multiplo Un arco multiplo corrisponde ad unassociazione molti-a-molti: il padre (libro) non determina funzionalmente il figlio (autore) Nellesempio si aggregano le vendite dei libri sulla base dei loro autori: un libro è scritto da più autori quindi non si può associare ad un unico autore Gli archi multipli verranno trattati a parte: in particolare si vedrà che per definire in modo consistente laggregazione anche per gli archi multipli sia a volte necessario definire un peso Intuitivamente, nell esempio delle vendite di un libro, il peso stabilisce la percentuale dell incasso di un libro che deve essere attribuita a ciascuno dei suoi autori Arco multiplo sulle dimensioni: verrà trattato a parte. 41

42 Dipendenze funzionali tra dimensioni Una DF tra le dimensioni si ha quando, dato linsieme delle dimensioni D, esistono due sottoinsiemi X ed Y di D tali che X Y. ogni misura M dipende solo da X, cioè X M Una DF tra le dimensioni rende il pattern primario P0 non significativo In questo caso lo schema di fatto F è equivalente, ovvero può essere semplificato in uno schema di fatto F con dimensioni X e con le restanti vecchie dimensioni in Y sono inclusi come attributi cross-dimensionali determinate da X Rappresentare gli attributi di Y come dimensioni è comunque più utile per dare maggiore risalto al loro ruolo nellaggregazione. 42

43 Il DFM: costrutti avanzati (riepilogo) nonaggregabilità anno trimestre mese giorno vacanza settimana respon sabile data peso capo reparto gruppo di marketing prodotto tipo VENDITA categoria marca dieta quantità venduta incasso num. clienti prezzo unitario (AV G) reparto città della marca respon sabile delle vendite distretto di vendita negozi o IVA attributo cross-dimensionale città del stato negozio regione indirizzo convergenza telefono IVA {Prodotto, Negozio} IVA! data inizio data fine costo promo zione pubblicità sconto dimensione opzionale 43

Modellazione concettuale

Modellazione concettuale Sistemi Informativi Avanzati Anno Accademico 2013/2014 Prof. Domenico Beneventano Modellazione concettuale Dal Capitolo 5 del libro Data Warehouse - teoria e pratica della Progettazione Autori: Matteo

Dettagli

Il Dimensional Fact Model

Il Dimensional Fact Model Il Dimensional Fact Model Per le slides si ringrazia il Prof. Stefano Rizzi (http://www-db.deis.unibo.it/~srizzi/) e il Dott. Angelo Sironi Quale formalismo? Mentre è universalmente riconosciuto che un

Dettagli

Modellazione concettuale

Modellazione concettuale Sistemi Informativi Avanzati Anno Accademico 2015/2016 Prof. Domenico Beneventano Modellazione concettuale Dal Capitolo 5 del libro Data Warehouse - teoria e pratica della Progettazione Autori: Matteo

Dettagli

Sistemi Informativi Avanzati Anno Accademico 2013/2014 Prof. Domenico Beneventano. Archi multipli

Sistemi Informativi Avanzati Anno Accademico 2013/2014 Prof. Domenico Beneventano. Archi multipli Sistemi Informativi Avanzati Anno Accademico 2013/2014 Prof. Domenico Beneventano Archi multipli Capitoli 5.2.5 e 9.1.4 del libro Data Warehouse - teoria e pratica della Progettazione Autori: Matteo Golfarelli,

Dettagli

Sistemi Informativi Avanzati Anno Accademico 2012/2013 Prof. Domenico Beneventano. Archi multipli

Sistemi Informativi Avanzati Anno Accademico 2012/2013 Prof. Domenico Beneventano. Archi multipli Sistemi Informativi Avanzati Anno Accademico 2012/2013 Prof. Domenico Beneventano Archi multipli Capitoli 5.2.5 e 9.1.4 del libro Data Warehouse - teoria e pratica della Progettazione Autori: Matteo Golfarelli,

Dettagli

Un arco multiplo corrisponde ad un associazione molti-a-molti: il padre (libro) non determina funzionalmente il figlio (autore)

Un arco multiplo corrisponde ad un associazione molti-a-molti: il padre (libro) non determina funzionalmente il figlio (autore) Arco Multiplo Schema di fatto contenente un arco multiplo: genere autore libro VENDITA numero incasso data mese anno arco multiplo (AM) Per illustrare il concetto di arco multiplo si parte da uno schema

Dettagli

Estensioni del linguaggio SQL per interrogazioni OLAP

Estensioni del linguaggio SQL per interrogazioni OLAP Sistemi Informativi Avanzati Anno Accademico 2012/2013 Prof. Domenico Beneventano Estensioni del linguaggio SQL per interrogazioni OLAP Esempio! Esempio delle vendite con scontrino (nella tabella, per

Dettagli

! Un arco multiplo corrisponde ad un associazione molti-a-molti: il padre (libro) non determina funzionalmente il figlio (autore)

! Un arco multiplo corrisponde ad un associazione molti-a-molti: il padre (libro) non determina funzionalmente il figlio (autore) Arco Multiplo! Schema di fatto contenente un arco multiplo: genere autore libro VENDITA numero incasso data mese anno arco multiplo (AM) " Per illustrare il concetto di arco multiplo si parte da uno schema

Dettagli

Sistemi Informativi Avanzati

Sistemi Informativi Avanzati Anno Accademico 2012/2013 Sistemi Informativi Avanzati Corso di Laurea Magistrale in Ingegneria Gestionale Domenico Beneventano Andrea Scavolini Introduzione 1 Obiettivi Il corso si propone di fornire

Dettagli

Sistemi Informativi Avanzati Anno Accademico 2011/2012 Prof. Domenico Beneventano SQL-OLAP. Estensioni OLAP in SQL

Sistemi Informativi Avanzati Anno Accademico 2011/2012 Prof. Domenico Beneventano SQL-OLAP. Estensioni OLAP in SQL Sistemi Informativi Avanzati Anno Accademico 2011/2012 Prof. Domenico Beneventano SQL-OLAP Estensioni OLAP in SQL Estensioni OLAP in SQL SQL99 è stato il primo standard SQL ad offrire soluzioni per l analisi

Dettagli

Progettazione concettuale:

Progettazione concettuale: Progettazione Concettuale da schemi E/R Dott. Marco Comerio Progettazione concettuale: approcci Basata sui requisiti Il progettista deve essere in grado enucleare, dalle interviste condotte presso l utente,

Dettagli

Indice. Prefazione. Capitolo 1 Introduzione al data warehousing 1

Indice. Prefazione. Capitolo 1 Introduzione al data warehousing 1 Indice Prefazione XI Capitolo 1 Introduzione al data warehousing 1 1.1 I sistemi di supporto alle decisioni 2 1.2 Il data warehousing 3 1.3 Architetture per il data warehousing 6 1.3.1 Architettura a un

Dettagli

Progettazione concettuale

Progettazione concettuale Sistemi Informativi Avanzati Anno Accademico 2015/2016 Prof. Domenico Beneventano Progettazione concettuale Dal Capitolo 6 del libro Data Warehouse - teoria e pratica della Progettazione Autori: Matteo

Dettagli

Sistemi Informativi Avanzati

Sistemi Informativi Avanzati Anno Accademico 2015/2016 Sistemi Informativi Avanzati Corso di Laurea Magistrale in Ingegneria Gestionale Domenico Beneventano Roberto Piuca Introduzione 1 Obiettivi Il corso si propone di fornire all'allievo

Dettagli

3.1. CorsodiElementidiBasididati Il modello Entita Relazione (72) vendita ordine studente. Impiegato. Dipartimento. città. Città.

3.1. CorsodiElementidiBasididati Il modello Entita Relazione (72) vendita ordine studente. Impiegato. Dipartimento. città. Città. Costrutti fondamentali del modello Entità-Relazione 3.1. dielementidibasididati Il modello Entita Relazione (72) Entità Attributi di entità Relazioni Attributi di relazione IS-A e Generalizzazioni Basi

Dettagli

Progettazione concettuale di una base di dati

Progettazione concettuale di una base di dati Progettazione concettuale di una base di dati Progettazione concettuale Analisi dei requisiti I requisiti devono innanzitutto essere acquisiti Le fonti possono essere molto diversificate tra loro: utenti,

Dettagli

Le Basi di dati: progettazione concettuale

Le Basi di dati: progettazione concettuale Le Basi di dati: progettazione concettuale Progettazione di una base di dati requisitidel Sistema Informativo progettazione concettuale SCHEMA CONCETTUALE SCHEMA FISICO progettazione fisica progettazione

Dettagli

Informatica Industriale Modello funzionale: Informazione Modello Entità-Relazione

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

Dettagli

INTRODUZIONE ALLA PROGETTAZIONE. Patrizio Dazzi a.a

INTRODUZIONE ALLA PROGETTAZIONE. Patrizio Dazzi a.a INTRODUZIONE ALLA PROGETTAZIONE Patrizio Dazzi a.a. 2017-2018 COMUNICAZIONI Lezione odierna e successive Metodologia di progetto Progettazione concettuale Progettazione logica Fondamentali per il secondo

Dettagli

Il modello relazionale. A. Ferrari

Il modello relazionale. A. Ferrari Il modello relazionale A. Ferrari Progettazione logica relazionale La progettazione logica relazionale consiste nella conversione di un diagramma E/R in un insieme di relazioni (o tabelle), che costituisce

Dettagli

Cardinalità degli attributi

Cardinalità degli attributi Cardinalità degli attributi Descrive il numero minimo e massimo di valori dell attributo associati ad ogni occorrenza di entità o relazione. Di solito la cardinalità è (1,1) e viene omessa. A volte il

Dettagli

Progettazione concettuale

Progettazione concettuale Sistemi Informativi Avanzati Anno Accademico 2012/2013 Prof. Domenico Beneventano Progettazione concettuale Dal Capitolo 6 del libro Data Warehouse - teoria e pratica della Progettazione Autori: Matteo

Dettagli

Sistemi Informativi Avanzati Anno Accademico 2011/2012 Prof. Domenico Beneventano. OLAP - Analysis Services

Sistemi Informativi Avanzati Anno Accademico 2011/2012 Prof. Domenico Beneventano. OLAP - Analysis Services Sistemi Informativi Avanzati Anno Accademico 2011/2012 Prof. Domenico Beneventano OLAP - Analysis Services OLAP: cubi multidimensionali OLAP : insieme di tecniche software per l'analisi interattiva e veloce

Dettagli

DATABASE - MODELLO E-R ENTITÀ E RELAZIONI TRATTO DA CAMAGNI-NIKOLASSY, CORSO DI INFORMATICA, VOL 2, HOEPLI. Informatica

DATABASE - MODELLO E-R ENTITÀ E RELAZIONI TRATTO DA CAMAGNI-NIKOLASSY, CORSO DI INFORMATICA, VOL 2, HOEPLI. Informatica DATABASE - MODELLO E-R ENTITÀ E RELAZIONI TRATTO DA CAMAGNI-NIKOLASSY, CORSO DI INFORMATICA, VOL 2, HOEPLI Informatica Introduzione L astrazione permette di creare dei modelli su cui vengono costruite

Dettagli

Entità. Relazioni. Cardinalità delle relazioni. Ogni entità ha un nome che la identifica

Entità. Relazioni. Cardinalità delle relazioni. Ogni entità ha un nome che la identifica Entità Ogni entità ha un nome che la identifica univocamente nello schema: I nomi devono essere per quanto possibile espressivi Convenzioni Si usa il singolare Si rappresenta di solito con un rettangolo

Dettagli

Entità. Modello Entità-Relazione (E-R) Relazioni (associazioni) Attributi

Entità. Modello Entità-Relazione (E-R) Relazioni (associazioni) Attributi Modello Entità-Relazione (E-R) Modello concettuale di dati. Fornisce una serie di strutture (costrutti) per descrivere un problema in modo chiaro e semplice. I costrutti vengono utilizzati per definire

Dettagli

Definizione e calcolo delle misure

Definizione e calcolo delle misure Definizione e calcolo delle misure! Misure Derivate! Misure Calcolate! Misure Derivate e Progetto Logico! Calcolo delle Misure! Aggregabilità Misure Derivate " Sono misure definite a partire da altre misure

Dettagli

A. Ferrari modello relazionale

A. Ferrari modello relazionale modello relazionale informatica progettazione logica relazionale o progettazione logica relazionale: o conversione di un diagramma E/R in un insieme di relazioni (tabelle), che costituisce lo schema logico

Dettagli

Le basi di dati. Lez. 2: Progettazione di un DB. Laboratorio di informatica gestionale

Le basi di dati. Lez. 2: Progettazione di un DB. Laboratorio di informatica gestionale Le basi di dati Lez. 2: Progettazione di un DB Cos è un dato? Un dato (dal latino datum) è la descrizione elementare di una cosa, di un avvenimento. Un dato è utilizzabile se esiste una chiave di interpretazione.

Dettagli

Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill, Capitolo 6: Progettazione di basi di dati: Metodologie e modelli

Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill, Capitolo 6: Progettazione di basi di dati: Metodologie e modelli Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill, 1996-2002 : Progettazione di basi di dati: Metodologie e modelli Altri costrutti del modello E-R Cardinalità di relationship di attributo Identificatore

Dettagli

Unità A2. Progettazione concettuale. Obiettivi. Astrazione. Astrazione per aggregazione

Unità A2. Progettazione concettuale. Obiettivi. Astrazione. Astrazione per aggregazione Obiettivi Unità A2 Progettazione concettuale Imparare ad astrarre i dati per definire entità. Saper distinguere tra astrazione per classificazione, per aggregazione e per generalizzazione. Saper distinguere

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 ModelloEntity-Relationship. E-R E il modello concettuale più diffuso Fornisce costrutti per descrivere le

Dettagli

Sistemi Informativi Territoriali

Sistemi Informativi Territoriali ANNO ACCADEMICO 2002-2003 SISTEMI INFORMATIVI GEOGRAFICI (SIT) GEOGRAPHICAL INFORMATION SYSTEMS (GIS) Sistemi Informativi Territoriali 2. La progettazione concettuale: il modello GEO-ER ALBERTO BELUSSI

Dettagli

Progettazione concettuale usando il modello Entità-Relazione (ER)

Progettazione concettuale usando il modello Entità-Relazione (ER) Progettazione concettuale usando il modello Entità-Relazione (ER) 1 Introduzione alla progettazione delle basi di dati Progettazione concettuale (in questa fase si usa il modello ER) Quali sono le entità

Dettagli

Sistemi Informativi Avanzati Anno Accademico 2011/2012 Prof. Domenico Beneventano SCENARI TEMPORALI

Sistemi Informativi Avanzati Anno Accademico 2011/2012 Prof. Domenico Beneventano SCENARI TEMPORALI Sistemi Informativi Avanzati Anno Accademico 2011/2012 Prof. Domenico Beneventano SCENARI TEMPORALI Dalle dispense originali realizzate dal Prof. Stefano Rizzi (http://www-db.deis.unibo.it/~srizzi/) e

Dettagli

ESEMPIO A: Arco multiplo su LIBRO- AUTORE

ESEMPIO A: Arco multiplo su LIBRO- AUTORE ESEMPIO A: Arco multiplo su LIBRO- AUTORE Consideriamo un DBO con il seguente schema E/R ed il corrispondente schema relazionale: AUTORE(AUTORE,CITTA) LIBRO(LIBRO,GENERE) PESO(AUTORE:AUTORE, LIBRO:LIBRO,PESO)

Dettagli

Ma: progettazione dei dati. progettazione delle applicazioni. Progettazione di basi di dati

Ma: progettazione dei dati. progettazione delle applicazioni. Progettazione di basi di dati di basi di dati E. Giunchiglia Basi di dati 1 (trasparenze basate su Atzeni,, Ceri, Paraboschi, Torlone: : Basi di dati, Capitolo 6) di basi di dati: Metodologie e modelli 05/10/2004 È una delle attività

Dettagli

Unità 3. Modello Relazionale

Unità 3. Modello Relazionale Unità 3 Modello Relazionale Modello Logico Modelli logico che deriva da concetti Matematici Permette di descrivere in modo corretto ed efficiente tutte le informazioni contenute nel modello E/R Meno astrato

Dettagli

Ma: progettazione dei dati progettazione delle applicazioni. Progettazione di basi di dati

Ma: progettazione dei dati progettazione delle applicazioni. Progettazione di basi di dati di basi di dati Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill, 1996-2002 Capitolo 6: di basi di dati: Metodologie e modelli 17/10/2002 È una delle attività del processo di sviluppo dei sistemi

Dettagli

Atzeni, Ceri, Paraboschi, Torlone Basi di dati. Progettazione di basi di dati: Metodologie e modelli

Atzeni, Ceri, Paraboschi, Torlone Basi di dati. Progettazione di basi di dati: Metodologie e modelli Atzeni, Ceri, Paraboschi, Torlone Basi di dati Parte II, Capitolo 7: Progettazione di basi di dati: Metodologie e modelli Il problema della progettazione di una BD Proviamo a pensare, progettare una applicazione

Dettagli

Modello Entità-Relazione (E-R)

Modello Entità-Relazione (E-R) Università Magna Graecia di Catanzaro Informatica Modello Entità-Relazione (E-R) Docente : Alfredo Cuzzocrea e-mail : cuzzocrea@si.deis.unical.it Tel. : 0984 831730 Lucidi tratti da: Atzeni, Ceri, Paraboschi,

Dettagli

Prima di iniziare. Diamo qualche definizione :

Prima di iniziare. Diamo qualche definizione : 1 Prima di iniziare. Diamo qualche definizione : Modello E/R (Entity/Relationship in italiano Entità- Relazione) : è un modello concettuale di dati e, come tale, fornisce una serie di strutture, detti

Dettagli

Altri costrutti del modello E-R. Esempio di cardinalità. Cardinalità di Residenza. Occorrenze di Residenza. Cardinalità di relationship

Altri costrutti del modello E-R. Esempio di cardinalità. Cardinalità di Residenza. Occorrenze di Residenza. Cardinalità di relationship Altri costrutti del modello E-R Cardinalità di relationship Cardinalità di relationship di attributo Identificatore interno Coppia di valori associati a ogni entità che partecipa a una relationship specificano

Dettagli

Il modello Entità-Relazioni (entity-relationship)

Il modello Entità-Relazioni (entity-relationship) Il modello Entità-Relazioni (entity-relationship) Introduzione alla progettazione Problema: progettare una base di dati a partire da requisiti sulla realtà di interesse Progettare=definire struttura caratteristiche

Dettagli

Basi di dati Prova di autovalutazione 17 gennaio 2011

Basi di dati Prova di autovalutazione 17 gennaio 2011 Basi di dati Prova di autovalutazione 17 gennaio 2011 Domanda 1 Si consideri la seguente relazione, che contiene informazioni relative alle operazioni eseguite sui vari conti correnti utilizzati (presso

Dettagli

Informatica per Statistica Riassunto della lezione del 28/11/2012

Informatica per Statistica Riassunto della lezione del 28/11/2012 Informatica per Statistica Riassunto della lezione del 28/11/2012 Igor Melatti Introduzione alla progettazione concettuale di basi di dati Questo riassunto è da intendersi come un commento alle slide BD2002-06.PDF

Dettagli

Vincoli. In ogni schema E/R sono presenti dei vincoli Alcuni sono impliciti, in quanto dipendono dalla semantica stessa dei costrutti del modello:

Vincoli. In ogni schema E/R sono presenti dei vincoli Alcuni sono impliciti, in quanto dipendono dalla semantica stessa dei costrutti del modello: Vincoli In ogni schema E/R sono presenti dei vincoli Alcuni sono impliciti, in quanto dipendono dalla semantica stessa dei costrutti del modello: ogni istanza di relazione deve riferirsi ad istanze di

Dettagli

Le relazioni hanno una naturale rappresentazione per mezzo di. D. Gubiani Il Modello Relazionale 3

Le relazioni hanno una naturale rappresentazione per mezzo di. D. Gubiani Il Modello Relazionale 3 Università degli Studi di Udine Facoltà di Agraria CORSO DI LAUREA IN SCIENZE E TECNOLOGIE DELL AMBIENTE E DEL TERRITORIO Sistemi di Elaborazione dell Informazione Il Modello Relazionale D. Gubiani 19

Dettagli

Ciclo di vita di un sistema informativo

Ciclo di vita di un sistema informativo Ciclo di vita di un sistema informativo Studio di fattibilità definisce le varie alternative possibili, i relativi costi e le priorità di realizzazione. Raccolta e analisi dei requisiti individua proprietà

Dettagli

SISTEMI INFORMATIVI E DATABASE

SISTEMI INFORMATIVI E DATABASE SISTEMI INFORMATIVI E DATABASE SISTEMA INFORMATIVO AZIENDALE (S.I.) In una realtà aziendale si distingue: DATO elemento di conoscenza privo di qualsiasi elaborazione; insieme di simboli e caratteri. (274,

Dettagli

2 - Metodologie e modelli per la progettazione di BD. Informatica II Basi di Dati (08/09) Parte 1. Introduzione alla progettazione

2 - Metodologie e modelli per la progettazione di BD. Informatica II Basi di Dati (08/09) Parte 1. Introduzione alla progettazione Informatica II Basi di Dati (08/09) Parte 1 Gianluca Torta Dipartimento di Informatica dell Università di Torino torta@di.unito.it, 0116706782 2 - Metodologie e modelli per la progettazione di BD Introduzione

Dettagli

Architetture per l analisi dei dati

Architetture per l analisi dei dati Architetture per l analisi dei dati Esercizio 8.1 Progettare un cubo multidimensionale relativo all analisi dei sinistri per una compagnia assicurativa, basandosi sulle specifiche accennate nel paragrafo

Dettagli

Progetto concettuale delle basi di dati

Progetto concettuale delle basi di dati Progetto concettuale delle basi di dati Gian Pietro Picco Dipartimento di Elettronica e Informazione, Italy picco@elet.polimi.it http://www.elet.polimi.it/~picco Il progetto dei dati Specifiche dei dati

Dettagli

Tecnologie dei sistemi informatici: Basi di Dati e Reti. Lezione 3. Parte I Il modello ERA: introduzione e concetti base

Tecnologie dei sistemi informatici: Basi di Dati e Reti. Lezione 3. Parte I Il modello ERA: introduzione e concetti base Tecnologie dei sistemi informatici: Basi di Dati e Reti Lezione 3 Parte I Il modello ERA: introduzione e concetti base Prof. Gabriella Carrozza ga.carrozza@unina.it Fonti e riferimenti o Libro di testo

Dettagli

Sistemi Informativi Aziendali. Sistemi Informativi Aziendali. Sistemi Informativi Aziendali

Sistemi Informativi Aziendali. Sistemi Informativi Aziendali. Sistemi Informativi Aziendali DIPARTIMENTO DI INGEGNERIA INFORMATICA AUTOMATICA E GESTIONALE ANTONIO RUBERTI Introduzione al Data Warehousing per b. Progetto di Datawarehouse 1 Progetto di Data Warehouse Definizione di obiettivi e

Dettagli

Perché preoccuparci?

Perché preoccuparci? Perché preoccuparci? Proviamo a modellare una applicazione definendo direttamente lo schema logico della base di dati: da dove cominciamo? rischiamo di perderci subito nei dettagli dobbiamo pensare subito

Dettagli

Modello Entità - Relazione. Basi di dati. Elena Baralis 2007 Politecnico di Torino D B M G D B M G2 D B M G4 D B M G6. Progettazione di basi di dati

Modello Entità - Relazione. Basi di dati. Elena Baralis 2007 Politecnico di Torino D B M G D B M G2 D B M G4 D B M G6. Progettazione di basi di dati di basi di dati Modello Entità-Relazione concettuale logica Normalizzazione Sistemi informativi D B M G D B M G2 Modello Entità-Relazione di basi di dati di basi di dati Entità e relazioni Attributi Identificatori

Dettagli

D B M G D B M G 2. Sistemi informativi. Progettazione di basi di dati

D B M G D B M G 2. Sistemi informativi. Progettazione di basi di dati Sistemi informativi D B M G Progettazione di basi di dati Modello Entità-Relazione Progettazione concettuale Progettazione logica Normalizzazione D B M G 2 1 Progettazione di basi di dati D B M G Modello

Dettagli

Modellazione dei dati

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

Dettagli

Introduzione. Il Modello Relazionale. Relazioni e Tabelle. Relazioni Matematiche - 1. Relazioni Matematiche - 2. Relazioni Matematiche - 3

Introduzione. Il Modello Relazionale. Relazioni e Tabelle. Relazioni Matematiche - 1. Relazioni Matematiche - 2. Relazioni Matematiche - 3 Università degli Studi di Udine Facoltà di Medicina e Chirurgia CORSO DI LAUREA IN TECNICHE DI RADIOLOGIA MEDICA PER IMMAGINI E RADIOTERAPIA Il Modello Relazionale Donatella Gubiani 10 marzo 2011 È un

Dettagli

D B M G D B M G 2. Basi di dati. Progettazione di basi di dati. Elena Baralis 2007 Politecnico di Torino 1. Modello Entità-Relazione

D B M G D B M G 2. Basi di dati. Progettazione di basi di dati. Elena Baralis 2007 Politecnico di Torino 1. Modello Entità-Relazione D B M G Progettazione di basi di dati Modello Entità-Relazione Progettazione concettuale Progettazione logica Normalizzazione D B M G 2 2007 Politecnico di Torino 1 Progettazione di basi di dati D B M

Dettagli

ESEMPIO TELEFONATE. Esempio di progettazione con indicazioni per lo svolgimento della Tesina. DIAGRAMMA RELAZIONALE

ESEMPIO TELEFONATE. Esempio di progettazione con indicazioni per lo svolgimento della Tesina. DIAGRAMMA RELAZIONALE ESEMPIO TELEFONATE Esempio di progettazione con indicazioni per lo svolgimento della Tesina. DIAGRAMMA RELAZIONALE NOTA: Molte tabelle hanno come chiave un identificatore ID che è stato rinominato (è possibile

Dettagli

ESAME CFU (C) VOTO (AVG) SOST REG

ESAME CFU (C) VOTO (AVG) SOST REG Schema di Fatto CITTA ESERCIZIO DEL 20 MAGGIO 2011 STATO STUDENTE DOCENTE CORSO FACOLTA ESAME CFU (C) VOTO (AVG) SOST REG Schema Logico del DM con Push- Down Backup DM e DB OLAP sono disponibili in : http://www.dbgroup.unimo.it/sia/20110520

Dettagli

Il modello Entity-Relationship: elementi avanzati

Il modello Entity-Relationship: elementi avanzati Il modello Entity-Relationship: elementi avanzati Sistemi Informativi T Versione elettronica: 06.2.ER.avanzato.pdf Identificatori esterni Oltre a poter identificare un entità E mediante uno o più attributi

Dettagli

Progettazione Concettuale/1

Progettazione Concettuale/1 Basi di Dati Prof. Alfredo Cuzzocrea Università degli Studi di Trieste Progettazione Concettuale/1 Credits to: Prof. P. Atzeni UniRoma3 Prof. S. Ceri PoliMI Prof. S. Paraboschi UniBG Prof. R. Torlone UniRoma3

Dettagli

Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill, La normalizzazione

Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill, La normalizzazione Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill, 1996-2002 : La normalizzazione Forme normali Basi di dati - Modelli e linguaggi di interrogazione- Paolo Atzeni, Stefano Ceri, Stefano Paraboschi,

Dettagli

Il modello Entity-Relationship: elementi avanzati

Il modello Entity-Relationship: elementi avanzati Il modello Entity-Relationship: elementi avanzati Sistemi Informativi T Versione elettronica: 06.2.ER.avanzato.pdf Identificatori esterni Oltre a poter identificare un entità E mediante uno o più attributi

Dettagli

Traduzione. Scelta degli identificatori principali

Traduzione. Scelta degli identificatori principali Scelta degli identificatori principali E molto importante per l importanza rivestita dalle chiavi nel modello relazionale Bisogna scegliere una chiave principale secondo i seguenti criteri: Escludere gli

Dettagli

Basi di dati (Sistemi Informativi)

Basi di dati (Sistemi Informativi) Basi di dati (Sistemi Informativi) teoria e pratica con Microsoft Access Basi di dati Sono una delle applicazioni informatiche che hanno avuto il maggiore utilizzo in uffici, aziende, servizi (e oggi anche

Dettagli

Catena del valore (studio di caso)

Catena del valore (studio di caso) (studio di caso) aprile 2012 1 Sono stati finora studiati individualmente alcuni processi di business può essere però utile anche inquadrare tali processi congiuntamente, in un contesto più ampio in particolare,

Dettagli

Generalizzazione. Docente : Alfredo Cuzzocrea Tel. : Informatica

Generalizzazione. Docente : Alfredo Cuzzocrea   Tel. : Informatica Università Magna Graecia di Catanzaro Informatica Generalizzazione Docente : Alfredo Cuzzocrea e-mail : cuzzocrea@si.deis.unical.it Tel. : 0984 831730 Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill,

Dettagli

Data warehouse. Progettazione di un data warehouse

Data warehouse. Progettazione di un data warehouse Data warehouse Progettazione di un data warehouse Architettura di un dw 2 Componenti di un dw Due funzioni principali: 1. Prendere le informazioni dai sistemi operazionali, pulirle e metterle dentro il

Dettagli

Modello Entità-Relazione (E-R)

Modello Entità-Relazione (E-R) Modello Entità-Relazione (E-R) Modello concettuale di dati. Fornisce una serie di strutture (costrutti) per descrivere un problema in modo chiaro e semplice. I costrutti vengono utilizzati per definire

Dettagli

IL MODELLO CONCETTUALE ENITÀ-RELAZIONE (ER) (CAPITOLO 5 DELLA VERSIONE ITALIANA)

IL MODELLO CONCETTUALE ENITÀ-RELAZIONE (ER) (CAPITOLO 5 DELLA VERSIONE ITALIANA) 1 IL MODELLO CONCETTUALE ENITÀ-RELAZIONE (ER) (CAPITOLO 5 DELLA VERSIONE ITALIANA) Obbiettivo: Introdurre la progettazione concettuale Definire il linguaggio E-R Discuterne i costrutti principali Esempi

Dettagli

Lezione 5. Il Modello dei Dati Relazionale Vincoli sui Database Relazionali

Lezione 5. Il Modello dei Dati Relazionale Vincoli sui Database Relazionali Lezione 5 Il Modello dei Dati Relazionale Vincoli sui Database Relazionali 1 Sommario Concetti del Modello Relazionale Vincoli del Modello Relazionale e degli Schemi di Database Relazionali Operazioni

Dettagli

Sistemi informativi D B M G

Sistemi informativi D B M G Sistemi informativi D B M G Progettazione di basi di dati Modello Entità-Relazione Progettazione concettuale Progettazione logica Normalizzazione D B M G 2 Modello Entità-Relazione Ciclo di vita di un

Dettagli

Il ciclo di vita del Data Warehouse

Il ciclo di vita del Data Warehouse Il ciclo di vita del Data Warehouse Prof. Stefano Rizzi Perché? Molte organizzazioni mancano della necessaria esperienza e capacità per affrontare con successo le sfide implicite nei progetti di data warehousing

Dettagli

I modelli logici dei dati

I modelli logici dei dati I modelli logici dei dati I modelli logici tradizionali sono tre: gerarchico reticolare relazionale I modelli gerarchio e reticolare sono più vicini alle strutture fisiche di memorizzazione. Quello relazionale

Dettagli

Lezione 11. database: modello entityrelationship. Proff.Valle Folgieri. Lez11 Trattamento dati. Database: modello entity-relationship 1

Lezione 11. database: modello entityrelationship. Proff.Valle Folgieri. Lez11 Trattamento dati. Database: modello entity-relationship 1 Lezione 11 database: modello entityrelationship Proff.Valle Folgieri Lez11 Trattamento dati. Database: modello entity-relationship 1 Fasi di sviluppo di un database Quando si sviluppa un database si passa

Dettagli

Tornando all esempio..

Tornando all esempio.. Tornando all esempio.. gli impiegati hanno un unico stipendio Impiegato Stipendio i progetti hanno un unico bilancio Progetto Bilancio in ciascun progetto, un impiegato svolge una sola funzione Impiegato

Dettagli

Data warehouse Introduzione

Data warehouse Introduzione DataBase and Data Mining Group of DataBase and Data Mining Group of DataBase and Data Mining Group of Database and data mining group, D MG B Data warehouse Introduzione INTRODUZIONE - 1 Database and data

Dettagli

La progettazione concettuale

La progettazione concettuale PROGETTAZIONE La progettazione concettuale Sintesi tra la visione degli utenti e la visione dei progettisti. I progettisti devono essere certi di aver compreso esattamente e completamente le esigenze degli

Dettagli

Forme normali. Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill. La normalizzazione. Normalizzazione. Una relazione con anomalie.

Forme normali. Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill. La normalizzazione. Normalizzazione. Una relazione con anomalie. Forme normali Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill Hill,, 1996-2002 Capitolo 9: La normalizzazione 23/10/2002 Una forma normale è una proprietà di una base di dati relazionale che

Dettagli

Data warehouse Introduzione

Data warehouse Introduzione D M B G Data warehouse Introduzione INTRODUZIONE - 1 Supporto alle decisioni aziendali La maggior parte delle aziende dispone di enormi basi di dati contenenti dati di tipo operativo queste basi di dati

Dettagli

Unità Due. Modello E/R

Unità Due. Modello E/R Unità Due Modello E/R Progettazione Concettuale Consiste: Riorganizzare tutti gli elementi presenti nella documentazione Per rappresentare la realtà di interesse In termini di una descrizione formale,completa

Dettagli

Metodologie e Modelli di Progetto

Metodologie e Modelli di Progetto Metodologie e Modelli di Progetto Università degli Studi del Sannio Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica CorsodiBasidiDati Accademico 2006/2007 docente: ing. Corrado Aaron Visaggio

Dettagli

Fondamenti di Informatica e Programmazione

Fondamenti di Informatica e Programmazione Fondamenti di Informatica e Programmazione Prof. G ianni D Angelo Email: giadangelo@unisa.it A. A. 2018/19 Dati e Basi di Dati 1/4 I dati sono importanti poiché costituiscono una risorsa aziendale La loro

Dettagli

Datawarehouse. Proge.azione logica

Datawarehouse. Proge.azione logica Datawarehouse Proge.azione logica 1) Modello a stella implementato 3 Semplici join permettono di ricostruire i fatti. Le tabelle dimensione sono generalmente denormalizzate: contengono le dipendenze funzionali

Dettagli

Il Modello Concettuale Enità-Relazione (ER)

Il Modello Concettuale Enità-Relazione (ER) Il Modello Concettuale Enità-Relazione (ER) (Capitolo 5 della versione italiana) Obbiettivo: Introdurre la progettazione concettuale Definire il linguaggio E-R Discuterne i costrutti principali Esempi

Dettagli

Progettazione del Data Warehouse

Progettazione del Data Warehouse Progettazione del Data Warehouse Queste dispense sono state estratte dalle dispense originali del Prof. Stefano Rizzi, disponibili in http://www-db.deis.unibo.it/~srizzi/) e sono state tratte dal libro

Dettagli

La progettazione concettuale

La progettazione concettuale La progettazione concettuale Angelo Chianese,, Vincenzo Moscato, Antonio Picariello, Lucio Sansone Basi di dati per la gestione dell'informazione 2/ed McGraw-Hill Capitolo 3 (Paragrafi 3.1, 3.2,3.3,3.4)

Dettagli

Laboratorio di Basi di Dati

Laboratorio di Basi di Dati Laboratorio di Basi di Dati Esercizi di progettazione concettuale Anno accademico 2017-2018 Paolo Perlasca Esercizio LEZIONI EROGATE DA UN CENTRO DI FORMAZIONE REGIONALE 2 Analisi dei requisiti Si vuole

Dettagli

Il modello multidimensionale. Per le slides si ringrazia il Prof. Stefano Rizzi (http://www-db.deis.unibo.it/~srizzi/) e il Dott.

Il modello multidimensionale. Per le slides si ringrazia il Prof. Stefano Rizzi (http://www-db.deis.unibo.it/~srizzi/) e il Dott. Il modello multidimensionale Per le slides si ringrazia il Prof. Stefano Rizzi (http://www-db.deis.unibo.it/~srizzi/) e il Dott. Angelo Sironi Verso il modello multidimensionale Che incassi sono stati

Dettagli

Elena Baralis, Claudio Demartini

Elena Baralis, Claudio Demartini Progetto concettuale Il progetto concettuale 1 Obiettivo: produrre lo schema concettuale Strumenti: meccanismi di astrazione forniti dal modello Entità-Relazione Specifiche iniziali: descrizioni in linguaggio

Dettagli

IL MODELLO ENTITÀ- RELAZIONE. Gli altri costruttori

IL MODELLO ENTITÀ- RELAZIONE. Gli altri costruttori IL MODELLO ENTITÀ- RELAZIONE Gli altri costruttori Sommario Cardinalità Identificatori Generalizzazioni Costruzione di schemi E-R E R con tutti i costruttori Cardinalità delle relazioni Coppia di valori

Dettagli

Basi di dati. La normalizzazione

Basi di dati. La normalizzazione Basi di dati La normalizzazione Forme normali Una forma normale è una proprietà di una base di dati relazionale che ne garantisce la qualità, cioè l'assenza di determinati difetti Quando una relazione

Dettagli