Anteprima
Vedrai una selezione di 6 pagine su 24
Business Intelligence - Appunti Pag. 1 Business Intelligence - Appunti Pag. 2
Anteprima di 6 pagg. su 24.
Scarica il documento per vederlo tutto.
Business Intelligence - Appunti Pag. 6
Anteprima di 6 pagg. su 24.
Scarica il documento per vederlo tutto.
Business Intelligence - Appunti Pag. 11
Anteprima di 6 pagg. su 24.
Scarica il documento per vederlo tutto.
Business Intelligence - Appunti Pag. 16
Anteprima di 6 pagg. su 24.
Scarica il documento per vederlo tutto.
Business Intelligence - Appunti Pag. 21
1 su 24
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

Architetture per l'aggiornamento in tempo reale

Ci sono anche architetture per fare in modo di avere un aggiornamento in tempo reale.

Modello Multidimensionale

Si usa il modello multidimensionale perché si presta bene al suo scopo.

I fatti sono oggetti di interesse da analizzare, fatto e cubo sono in relazione 1 ad 1, una dimensione è come un asse cartesiano con dentro tante tacchettine.

Fatto, misura e dimensione sono i concetti principali del modello multidimensionale, poi ci saranno anche le gerarchie.

In un esempio di cubo delle vendite di un supermercato il prodotto non è il singolo oggetto in scala ma sono quelli che hanno codice a barre diversi, se non c'è il cubo allora vuol dire che non c'è stata la vendita (non mancanza di dati perché c'è stata la pulitura).

La selezione si può fare in 2 modi, slicing (selezione) che riduce la dimensionalità perché isola solo una parte e dicing (cubettatura) che ne trova un sottocubo perché ne seleziona più di uno.

Le gerarchie

permettono di raggruppare ad esempio i negozi per città, le città a loro volta per regioni con associazioni molti a 1

Per l'aggregazione è come usare un group by che accorpa degli eventi per ottenere degli eventi derivati chiamati secondari, ho una visione più di sintesi, ogni evento primario casca in un solo evento secondario

Modello Relazionale (ripasso)

Molto pragmaticamente una relazione è una tabella.

Una relazione ha sempre due componenti: uno schema (nome della relazione e nomi degli attributi, insomma la struttura) e un'istanza (un insieme di righe, dette tuple)

La cardinalità di una relazione (che è un insieme) è il numero di righe (tuple), mentre l'arità è il numero di colonne

Il null è il concetto che si usa per dire che non si conosce un valore, quindi non è una stringa vuota o qualsiasi altra cazzata

Una relazione è soggetta a dei vincoli di integrità, deve rispettare dei vincoli.

Il vincolo con lo scope più piccolo è il vincolo di dominio (ad esempio voto deve essere >=18 e <30), vincolo di tupla (che si deve verificare su tutta una tupla, ad esempio la colonna lode può essere vera solo se il voto è 30), vincolo di chiave (si verifica guardando l'intera relazione, e c'è almeno una chiave), vincolo di integrità primaria (che dice che la chiave primaria non può essere null), vincolo di integrità referenziale (vedendo due relazioni, se nella seconda relazione c'è un attributo con chiave esterna (foreign key) questo può assumere solo valori della chiave primaria della prima relazione oppure anche null). Una foreign key può essere anche null, ma non se fa parte della chiave primaria. La superchiave è un insieme di attributi (può essere anche più di uno) che identifica univocamente una tupla. La superchiave minimale si chiama chiave, ed è quando non posso più

rimuovereattributi altrimenti non unicizza più la tuplaCi possono anche essere due chiavi in una tabella(relazione), ma o uso una oppurel'altraNon può esistere una relazione senza chiave(basta prendere tutte le colonne eusarle come chiave)(non possono esistere due righe identiche in una relazione,come in un insieme)Una dipendenza funzionale è quando un attributo dipende da altri (ad esempiocodice scale da cognome e nome)Per de nizione, la chiave determina tutti gli altri attributi1' forma normale, tutti gli attributi devono avere valori atomici2' forma normale, a volte ci sono dipendenze funzionali spurie in una relazione, siha quando è su ciente una parte della chiave per determinare un attributo, è inseconda forma normale se non ci sono dipendenze parziali, perciò si trancia larelazione3' forma normale se non presenta dipendenze transitive(un esempio è creare unatabella a parte per città e regioni)Su

Internet dice che le forme normali sono utilizzate per eliminare le ridondanze e le incoerenze dei dati, la 4' e la 5' forma normale non sono di solito usate perché riducono le prestazioni del sistema quando si fa una ricerca o una modifica.

Operazioni di Report e OLAP:

  • Il roll-up aggrega mentre il drill-down (trapanare) disaggrega
  • Il slice and dice
  • Il pivoting (che ho gli stessi valori ma li sposto)
  • Il drill-across (trapanare attraverso) è come un join lavoro su cubi diversi

C'è un plugin su Excel per fare OLAP ma manca tutto il lavoro a monte.

Tipi di OLAP:

  • Relational OLAP (in questo momento è il leader indiscusso), nel backend ho un database relazionale e nel frontend uso OLAP con il modello multidimensionale e per farli comunicare utilizzo un motore multidimensionale
  • MOLAP è nativamente multidimensionale, non ha problemi di prestazioni, multidimensionale lo vede l'utente e multidimensionale lo vede il computer
'e ilproblema della sparsità perché nel rolap metto solo le tuple degli eventi veri catimentre nel molap metto tutte le tuple possibili
Il molap non si è di uso, ma si può comunque trovare come sistema di contorno inun azienda

HOLAP è la via di mezzo, con l'idea di prendere il meglio di ROLAP e MOLAP

Ciclo di vita di un Data Warehouse

Una volta si usava l'approccio top-down che veniva fuori un monolite tutto alla nementre ora si usa l'approccio bottom-up

Scegliere quale sarà il primo data mart(una parte del data warehouse, include piùcubi multidimensionali) da prototipare

Il ciclo di sviluppo inizia con la de nizione degli obiettivi, poi la progettazionedell'infrastruttura e poi la progettazione e sviluppo dei data mart.

Tutto quello di cui si parlerà da ora in poi riguarderà la progettazione e lo sviluppodi un singolo data mart.

La progettazione dell'ETL è la parte dello sviluppo di un data

La parte più costosa del lavoro è il data mart, che può arrivare anche al 70% del lavoro perché è l'unica parte dove bisogna scrivere del codice e non è riutilizzabile per altri progetti o altri data mart.

Il quadro metodologico ha 2 approcci, guidato dai dati e dai requisiti. Secondo il prof, l'approccio guidato dai dati è il migliore, si può applicare quasi sempre ed è la carta vincente visti i tempi brevi e i pochi errori. Si parte dai database di produzione che di solito sono relazionali e li si unisce in uno schema riconciliato. Poi si fa l'analisi dei requisiti con le interviste, tenendo conto dei primi due passaggi si disegna uno schema concettuale (non si usa l'ER). Successivamente si crea lo schema logico creando tabelle, poi si ha tutto quello che serve per l'ETL, e ne si fa la progettazione sica (farlo su Oracle non è come farlo su SQL Server) per lo schema sico e poi si passa alla reportistica.

Il grosso dello sforzo per lo schema concettuale può essere fatto da un algoritmo, oltre a fare l'ETL.

sarà più semplice grazie alla progettazione. Per poter applicare questo approccio bisogna avere a disposizione il database sorgente normalizzato. L'approccio guidato dai requisiti invece inizia con l'analisi dei requisiti con interviste e solo sulla base di questo si disegna la progettazione concettuale e poi tutto il resto, si parte quindi da un foglio bianco, il rischio è che si richiedano cose che in realtà non ci sono, inoltre è molto complicato quindi è più difficile, ci vuole più tempo ed è più facile fare degli errori. Analisi e riconciliazione delle sorgenti Basta conoscere gli schemi dei sorgenti e non i dati, nella prima fase si fa una ricognizione e normalizzazione (di solito significa spezzare) di ogni database partendo dallo schema logico e poi si integrano gli schemi con uno schema concettuale globale. Analisi dei requisiti Devo raccogliere i bisogni informativi degli utenti, essa ha un'importanza strategica.La fonte principale saranno i business users (un consiglio è portarsi una scheda per evitare di dimenticarsi qualcosa) ma anche quelli che gestiscono i database per sapere come è strutturato. Le interviste, secondo gli psicologi, si fanno a piramide (si parte da domande molto dettagliate) o ad imbuto (si parte da domande molto generali dove è difficile dare una risposta sbagliata). Cosa fondamentale da queste riunioni sono i fatti, i concetti su cui gli utenti nel data mart baseranno il processo decisionale, decidere il livello di granularità (il più alto livello di dettaglio) e l'intervallo di storicizzazione (l'arco temporale da tenere memorizzato). Bisogna fare anche un glossario dei requisiti, da fare vedere a tutti quelli che partecipano alla riunione perché a volte viene fuori alla fine che non ci si è capiti. Progettazione concettuale Obiettivo: creare uno schema concettuale del data mart, non legata ad una specifica implementazione (ROLAP, MOLAP, Oracle, SQL Server, etc.).

Ecc.), non si usa l'ER perché è troppo espressivo e sarebbe inutilmente complicato, alcuni progettisti stupidi non fanno nemmeno lo schema concettuale e partono direttamente con lo schema logico, ci sono circa una dozzina di tipi di schemi concettuali, il più di uso è il DFM (dimensional fact model) che è un modello grafico e permette anche all'utente di capire se una query è possibile lanciarla oppure no, è pensato espressamente per essere compreso anche da un utente non studiato e quindi si condivide con l'utente finale che lo raffinerà e poi si parte con lo schema logico, modelleremo fatto dimensione misure e gerarchie.

LE DIMENSIONI NON SONO NECESSARIAMENTE 3, ma anche 10 ecc

Un fatto esprime sempre un'associazione molto a molti tra le dimensioni

Le gerarchie sono alberi direzionati, il verso dell'arco è sempre quello che si allontana dalla radice

Gli attributi descrittivi sono sempre presenti in un progetto reale, si

denota con una sottolineatura anziché pallino, la differenza sta che non ci posso fare aggregazioni sopra perché non ha senso farlo, ma posso comunque fare selezione, vengono messi perché nel report li voglio vedere In associazione 1 a 1, il figlio deve sempre essere descrittivo, e viceversa gli attributi descrittivi sono sempre foglie, nome e cognome di solito sono attributi descrittivi Alcuni archi possono essere opzionali fi fi fi fi ff fi fi fi fi ffi ffi fi ff In realtà le gerarchie possono presentare dei cicli, quindi non sono sempre alberi, la gerarchia condivisa è un'abbreviazione grafica (si riusa un pezzo di gerarchia anziché ricopiarla tante volte) anche perché non posso avere più pallini con lo stesso nome Convergenza e condivisione, differenza? Sta nel fatto che per esempio in uno ho due stati per ogni singolo negozio, mentre nell'altro ho un
Dettagli
Publisher
A.A. 2021-2022
24 pagine
SSD Scienze matematiche e informatiche INF/01 Informatica

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher luca2695 di informazioni apprese con la frequenza delle lezioni di Business Intelligence e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli Studi di Bologna o del prof Rizzi Stefano.