Modello UDM (Unified Dimensional Model)

Un utente che desidera recuperare informazioni direttamente da un'origine dei dati, ad esempio un database ERP (Enterprise Resource Planning), deve affrontare diversi problemi:

• Il contenuto di tali origini dei dati è spesso molto difficile da interpretare in quanto viene creato per sistemi e sviluppatori invece che per utenti finali.
• Le informazioni di interesse per l'utente in genere sono distribuite tra più origini dei dati eterogenee. Anche nel caso in cui utilizzi semplicemente vari database relazionali, l'utente deve conoscere i dettagli di ognuno di essi, ad esempio il sottolinguaggio SQL utilizzato. Se poi le origini dei dati sono di tipo completamente diverso e includono non solo database relazionali ma anche file e servizi Web, la situazione diventa ancora più complessa.
• Nonostante molte origini dei dati tendano a contenere grandi quantità di dettagli a livello di transazione, spesso le query che supportano il processo decisionale aziendale richiedono l'utilizzo di informazioni aggregate di riepilogo. A mano a mano che i volumi di dati aumentano, il tempo necessario per il recupero di tali valori di riepilogo ai fini dell'analisi interattiva eseguita dall'utente finale può crescere in misura inaccettabile.
• Le regole business in genere non sono incapsulate nelle origini dei dati e gli utenti devono interpretare i dati senza avere a disposizione alcuna indicazione.

Il ruolo di un modello UDM (Unified Dimensional Model) è quello di fungere da bridge tra l'utente e le origini dei dati. Un modello UDM viene creato sulla base di una o più origini dei dati fisiche. L'utente esegue le query sul modello UDM utilizzando svariati strumenti client, ad esempio Microsoft Excel.

Esistono vantaggi di cui l'utente finale usufruisce anche quando il modello UDM viene creato solo come livello sottile sull'origine dei dati: un modello di dati più semplice e immediatamente comprensibile, l'isolamento da origini dei dati back-end eterogenee e un miglioramento delle prestazioni per le query che comportano riepiloghi delle informazioni. In alcuni scenari, è possibile creare in modo automatico un modello UDM semplice. Un maggiore investimento nella fase di creazione del modello UDM consente di ottenere vantaggi aggiuntivi grazie alla ricchezza dei metadati che il modello è in grado di offrire.

Il modello UDM offre i vantaggi seguenti:

• Arricchisce notevolmente il modello dell'utente.
• Consente di eseguire query ad alte prestazioni che supportano l'analisi interattiva anche in caso di volumi di dati di dimensioni particolarmente elevate.
• Consente di acquisire regole business nel modello, in modo da supportare analisi più avanzate.
• Supporta la chiusura del ciclo, consentendo all'utente di eseguire operazioni sui dati visualizzati.

Modello di base dell'utente finale

Si consideri un esempio in cui un utente desideri confrontare le vendite con gli obiettivi di vendita per periodi di tempo diversi.

I dati delle vendite vengono archiviati nel database Sales and Inventory principale, che contiene molte altre tabelle. Dopo avere identificato le tabelle rilevanti, l'utente potrebbe scoprire che i dati di una singola entità, ad esempio Product, sono distribuiti tra numerose tabelle, tra le quali non esiste alcuna relazione perché l'integrità referenziale viene applicata dalla logica dell'applicazione. Gli obiettivi di vendita sono archiviati nel database di un'altra applicazione. Nessuno di questi database include regole business, ad esempio una regola che stabilisca che per confrontare gli obiettivi di vendita con le vendite effettive è necessario fare riferimento alla data di spedizione dell'ordine invece che alle molte altre date degli ordini, tra cui la data di esecuzione dell'ordine, la data di scadenza, la data di pianificazione e così via.

Accesso diretto alle origini dei dati

Verrà innanzitutto preso in esame il caso in cui l'utente accede alle origini dei dati direttamente. Nella figura seguente viene illustrato il caso di una query creata con uno strumento di esempio.

A questo punto, l'utente ha già svolto molte delle operazioni necessarie, tra cui:

• Esame di un ampio numero di tabelle con nomi di difficile interpretazione per individuare quelle di interesse.
• Identificazione delle colonne da utilizzare per unire in join le tabelle.
• Selezione delle colonne contenenti i dettagli di interesse da molte tabelle con numerosi dettagli destinati al sistema. Ad esempio, tra le 11 colonne delle tabelle in cui sono archiviati i dettagli relativi alle categorie dei prodotti, solo le due colonne del nome sono in realtà rilevanti per l'utente.

L'utente a questo punto deve decidere dove utilizzare outer join o inner join e come raggruppare i dettagli per fornire le aggregazioni richieste.

L'utente deve tuttavia eseguire attività più complesse, ad esempio stabilire come unire in join i dati di altre origini dei dati. Anche qualora uno dei database supporti le query distribuite, la maggior parte degli utenti non è in grado di creare la query richiesta ed è possibile che gli strumenti disponibili non offrano un supporto adeguato per questa attività. Il codice di esempio seguente illustra un metodo per eseguire una query sui dati esterni.

SELECT Quotas.QuotaAmount, Quotas.EmployeeId, …
FROM OPENROWSET('SQLOLEDB','seattle1';
'Sales';'MyPass',
   'SELECT * FROM Forecasts.dbo.SalesQuota’ ) As Quotas

Quando si utilizzano altre origini dei dati, ad esempio i servizi Web, l'utente si trova di fronte a un altro grande ostacolo, ovvero determinare come eseguire le chiamate remote corrette e quindi come elaborare il codice XML restituito per combinarlo con gli altri dati.

Dopo avere infine eseguito queste operazioni per una query, è necessario ripeterne la maggior parte per la query successiva e per tutte quelle a seguire.

Accesso alle origini dei dati tramite un modello UDM

Il diagramma seguente illustra invece un esempio di creazione di una query nel caso in cui l'utente acceda a un modello UDM semplice creato su tali origini dei dati.

L'interfaccia di progettazione illustrata in questo esempio è disponibile negli strumenti di sviluppo inclusi in Microsoft SQL Server 2005, anche se è possibile utilizzare qualsiasi interfaccia che supporti il modello UDM, tra cui strumenti client quali Office Excel e Office Web Components (OWC) oppure uno dei tanti strumenti di analisi e gestione dei report.

La visualizzazione struttura sulla sinistra mostra il contenuto del modello UDM. In questo esempio si notino i punti seguenti:

• L'utente vede solo gli elementi rilevanti a lui destinati. Le colonne di sistema, ad esempio le colonne contenenti il GUID della riga o la data dell'ultima modifica, non sono visibili.
• Vengono utilizzati nomi descrittivi invece delle convenzioni di denominazione per lo sviluppatore applicate nel database sottostante.

Nel modello UDM, inoltre, tutti gli attributi di ogni entità business sono raggruppati in "dimensioni" distinte, ad esempio Product o Employee. Il client potrebbe pertanto fare riferimento agli elementi Product Color, Subcategory e Category in questo esempio senza eseguire join in modo esplicito tra le molte tabelle coinvolte.

Le colonne che rappresentano i valori delle transazioni, ovvero le misurazioni, sono presentate sotto forma di "misure". In genere l'utente ha necessità, ad esempio, di eseguire operazioni di aggregazione sulle colonne, quali quelle relative all'importo delle vendite o alle quote di vendita. Questa modalità di rappresentazione dei dati sotto forma di "misure" e "dimensioni" è detta modellazione dimensionale.

Nelle parte destra della figura sono illustrati gli elementi utilizzati nella query corrente. In questo caso, per visualizzare l'importo delle vendite e l'obiettivo di vendita per categoria di prodotti, l'utente ha definito la query semplicemente trascinando i tre elementi rilevanti dalla visualizzazione struttura alla parte destra dell'interfaccia di progettazione. Non è stato necessario specificare i dettagli per l'accesso alle due diverse origini dei dati, né eseguire join tra le tabelle coinvolte.

Il modello definisce le semplici formattazioni da utilizzare per impostazione predefinita, ad esempio i simboli di valuta. È inoltre possibile definire formattazioni più complesse, inclusa la formattazione condizionale che consente ad esempio di visualizzare un valore in rosso se è al di sotto di una determinata soglia.

Uno stesso modello supporta svariate query. È ad esempio possibile suddividere i risultati per dipendente semplicemente trascinando un attributo dalla dimensione dei dipendenti.

Estensione del modello di base

L'esempio precedente dimostra come anche un semplice modello UDM possa semplificare notevolmente le operazioni di base di esplorazione dei dati. Quando tuttavia si desidera consentire agli utenti di accedere ai dati, è necessario considerare alcuni problemi aggiuntivi. Ad esempio:

• Un modello UDM che supporta l'esecuzione di svariati tipi di query da parte di utenti diversi può raggiungere dimensioni considerevoli. Come è possibile fare in modo che a un utente impegnato in una precisa attività non venga visualizzato inutilmente un gran numero di informazioni irrilevanti?
• Come è possibile soddisfare le richieste di utenti globali che desiderano visualizzare i report nella lingua nativa?
• Come è possibile semplificare la formulazione di tutte le domande riguardanti il tempo, ad esempio il confronto delle vendite con lo stesso periodo dell'anno precedente?

In questa sezione vengono esaminate alcune di queste domande per illustrare come il modello UDM supporta l'estensione del modello di base per consentire operazioni di esplorazione dei dati più avanzate.

Gerarchie

Nonostante il consolidamento di tutti gli attributi di un'entità all'interno di una dimensione consenta di semplificare notevolmente il modello per l'utente, tra gli attributi esistono relazioni aggiuntive che non possono essere espresse da un semplice elenco. Nel caso precedente, Category, SubCategory e SKU definiscono una delle gerarchie in cui è possibile organizzare i prodotti. Il modello UDM consente di definire tali gerarchie, sulla base delle quali vengono spesso eseguite le analisi degli utenti. Dopo avere visualizzato i totali per categoria, ad esempio, l'utente potrebbe eseguire il drill-down prima nelle sottocategorie e quindi nel livello SKU più basso. Ogni gerarchia è una sequenza di attributi, che è possibile utilizzare nelle query per semplificare gli scenari di drill-down e drill-up.

La figura seguente è un esempio di come le gerarchie possono apparire in un'interfaccia visualizzata all'utente finale. Il modello contiene svariate gerarchie per l'organizzazione dei prodotti. La query visualizzata in questo esempio risponde alla necessità di visualizzare le vendite e gli obiettivi di vendita raggruppati per categoria di prodotti e quindi di suddividere i risultati in sottocategorie. La query è stata definita trascinando la gerarchia "Products By Category" nella griglia. Per visualizzare i dati in dettaglio, l'utente deve fare doppio clic sulla categoria "Bike" per espandere le sottocategorie.

Il modello UDM gestisce i dettagli relativi allo spostamento tra i livelli di una gerarchia, nonché i dettagli relativi ad esempio al fatto che gli obiettivi di vendita non sono disponibili al livello delle sottocategorie ma solo a quello delle categorie

Un tipo particolare di gerarchia è la gerarchia padre-figlio, contenente entità con una relazione involutiva verso se stesse. Nella figura successiva la dimensione Employee include una gerarchia denominata “Employees By Organization Structure”. Questa gerarchia semplifica sia l'esplorazione della relazione padre-figlio sia l'analisi dei valori di cui è stato eseguito il rollup a ogni livello dell'organizzazione. L'obiettivo di vendita del VP of Sales Charles Marshall, ad esempio, include la somma degli obiettivi di vendita di tutto il personale del suo reparto più gli obiettivi di vendita associati direttamente a lui.

Categorizzazione

Gli utenti applicano categorizzazioni ai dati in modo naturale, specificando ad esempio gli attributi che riguardano i dettagli personali dei dipendenti o gli attributi che rappresentano indirizzi di posta elettronica. Il modello UDM offre due meccanismi progettati in modo specifico per utilizzare al meglio tali categorizzazioni:

• È possibile assegnare dimensioni, attributi e altri oggetti a categorie significative da un punto di vista semantico, in modo da supportare utilizzi più intelligenti di tali oggetti da parte di uno strumento client. È possibile, ad esempio, contrassegnare un attributo come URL. Il report che contiene questo attributo può quindi consentire l'esplorazione in base ai valori dell'URL. Un altro attributo potrebbe essere contrassegnato come indirizzo di posta elettronica, in modo da aprire automaticamente un nuovo messaggio di posta elettronica in un client per la gestione dei report quando l'utente esegue una particolare operazione.
• È possibile raggruppare misure, gerarchie e altri oggetti in cartelle significative per l'utente. Questo raggruppamento consente allo strumento di gestione dei report di visualizzare un gran numero di attributi in un modo più gestibile. Potrebbe ad esempio esistere un gruppo di attributi identificati come "Customer Demographics".

Periodi di tempo

Le informazioni relative ai periodi di tempo in genere vengono registrate nell'origine dei dati sottostante utilizzando il tipo di dati DataTime o Date. Nonostante gli utenti con una conoscenza approfondita di SQL o XPath siano in grado di estrarre le informazioni sulle date necessarie per totalizzare i dati di ogni anno, troveranno tuttavia difficile formulare una query relativa a domande basate su altri aspetti temporali, ad esempio visualizzare le vendite per giorno della settimana o visualizzare una suddivisione dei risultati per anno fiscale a partire dall'1 luglio.

Il modello UDM, tuttavia, dispone di nozioni incorporate riguardanti il tempo, inclusi vari tipi di calendari:

• Naturale
• Fiscale
• Di report ("445" e così via)
• Di produzione (13 periodi)
• ISO8601

Il modello può pertanto includere una dimensione temporale contenente una vasta gamma di attributi che definiscono i dettagli di ogni giorno. Nella figura seguente vengono visualizzati i risultati nel caso in cui l'utente scelga di visualizzare l'importo delle vendite e gli obiettivi di vendita per l'anno fiscale 2001. A questo scopo, è sufficiente che l'utente trascini l'elemento rilevante dalla struttura nell'area filtro. Il modello UDM è in grado di tradurre questa operazione dell'utente in un intervallo di date nonché di comprendere la regola business in base alla quale devono essere inclusi nella query gli ordini spediti in tali date e non quelli ordinati o con scadenza in tali date. Il join corretto viene eseguito in modo implicito dal modello UDM.

Il modello UDM offre inoltre un supporto specifico per le risposte a domande comuni relative al tempo, tra cui i confronti tra periodi di tempo, ad esempio il confronto tra il mese corrente e lo stesso mese dell'anno precedente.

Traduzioni

Negli esempi precedenti sia il contenuto del modello che i dati sono visualizzati in una sola lingua. Spesso tuttavia gli utenti internazionali necessitano di visualizzare i metadati nella propria lingua.

Per risolvere questo problema, il modello UDM consente di tradurre i metadati in qualsiasi lingua. Un'applicazione client che si connette utilizzando determinate impostazioni internazionali riceverà quindi tutti i metadati nella lingua appropriata.

Il modello può anche fornire traduzioni dei dati. È infatti possibile eseguire il mapping di un attributo a elementi diversi nell'origine dei dati e fornire le traduzioni di tali elementi in lingue diverse. Se, ad esempio, un utente si connette utilizzando lo stesso strumento utilizzato per gli esempi precedenti, ma da un computer client in cui sono configurate le impostazioni internazionali francesi, il modello UDM e i risultati delle query verranno visualizzati in francese, come illustrato nella figura.

Prospettive

Nonostante il modello utilizzato in questo esempio sia di dimensioni particolarmente ridotte, i modelli reali potrebbero riguardare un ambito molto più ampio e includere decine di misure e dimensioni con decine o centinaia di attributi in ogni dimensione. Gli utenti che desiderano eseguire una particolare operazione non hanno necessità di vedere il modello completo. Per evitare che vengano visualizzati inutilmente tutti i dati del modello, è necessario consentire agli utenti di definire una vista che mostri un subset del modello.

Nel modello UDM sono disponibili tali viste, definite prospettive. Il numero delle prospettive disponibili in un modello UDM può essere elevato e ognuna di esse presenta solo un subset specifico del modello, ad esempio le misure, le dimensioni, gli attributi e così via, rilevante per un determinato gruppo di utenti. Ogni prospettiva può quindi essere associata ai ruoli di protezione degli utenti, che definiscono gli utenti a cui è consentito vedere tale prospettiva.

È ad esempio possibile definire una prospettiva denominata "Seattle Inventory" contenente solo le misure del gruppo di misure Inventory, nella quale la gerarchia "Warehouse By Location" è nascosta e la città predefinita è "Seattle".

Semantica degli attributi

In un modello UDM è disponibile un'ulteriore semantica per gli attributi, che ha lo scopo di migliorare la fruibilità delle informazioni. Di seguito sono riportati alcuni esempi di semantica applicabile agli attributi:

• Distinzione tra nomi e chiavi: quando si esamina il database relazionale, potrebbe non essere evidente che EmployeeID è una chiave univoca generata dal sistema priva di significato. Il modello UDM risolve questo problema consentendo di assegnare all'attributo Employee sia una chiave, ovvero il valore univoco EmployeeID, che un nome, determinato ad esempio dalla concatenazione di FirstName e LastName. Le query eseguite, ad esempio per la visualizzazione dei dipendenti, saranno in grado di distinguere correttamente i dipendenti con lo stesso nome utilizzando gli ID univoci, ma visualizzeranno il nome significativo all'utente.
• Ordinamento: i valori degli attributi devono spesso essere visualizzati in un ordine prestabilito, diverso da un semplice ordine numerico o alfabetico. Il modello UDM consente di definire un ordinamento predefinito per gestire questo requisito. Ad esempio:
  • I giorni della settimana vengono visualizzati come Sunday, Monday, Tuesday e così via.
  • Le priorità vengono visualizzate nel seguente ordine: High, Medium, Low.
• Discretizzazione: per gli attributi numerici talvolta non è utile visualizzare ogni singolo valore dell'attributo. Visualizzare le vendite, ad esempio, per tutti i diversi prezzi di un prodotto ($ 9,97, $ 10,05, $ 10,10,…) è decisamente meno utile che visualizzarle per fascia di prezzo (<$ 10, $ 10 - $ 15,…). Il modello UDM consente di discretizzare gli attributi in intervalli in base a vari criteri.

Indicatori di prestazioni chiave (KPI)

Le aziende spesso definiscono indicatori di prestazioni chiave (KPI), che sono importanti parametri grazie a cui è possibile valutare la solidità dell'azienda. Il modello UDM consente di creare tali indicatori KPI, in modo che le aziende possano raggruppare e presentare i dati in un modo più facilmente comprensibile. Un indicatore KPI può inoltre utilizzare un'immagine per visualizzare lo stato e la tendenza, ad esempio un semaforo che indichi una situazione buona, media o negativa.

Ogni indicatore di prestazioni chiave nel modello UDM può definire fino a quattro espressioni per ogni livello di prestazioni:

• Valore effettivo
• Valore obiettivo
• Stato   Un valore normalizzato compreso tra -1 e 1 che rappresenta il rapporto tra il valore effettivo e il valore obiettivo (-1 significa "pessimo", 1 significa "eccellente")
• Tendenza   Un valore normalizzato compreso tra -1 e 1 che rappresenta la tendenza nel tempo (-1 significa "notevole peggioramento", 1 significa "notevole miglioramento").

Grazie agli indicatori di prestazioni chiave gli strumenti client possono presentare misure correlate in un modo molto più comprensibile per l'utente. Nella figura seguente viene illustrato come in uno strumento client potrebbero essere visualizzati tre indicatori di prestazioni chiave, organizzati in cartelle visualizzate.

Prestazioni

Affinché gli utenti possano eseguire esplorazioni interattive, è necessario garantire tempi di risposta rapidi. Considerate le dimensioni molto elevate dei set di dati su cui spesso vengono eseguite le esplorazioni, questo requisito presenta alcune difficoltà.

Per ottimizzare le prestazioni, il modello UDM offre servizi di caching. Le cache sono in grado di memorizzare sia i dati dettagliati letti dall'origine dei dati sottostante sia i valori di aggregazione precalcolati sulla base di tali dati. L'utilizzo di valori memorizzati nella cache, tuttavia, può comportare un certo grado di obsolescenza dei dati. Il livello di aggiornamento delle informazioni da impostare dipende dai requisiti aziendali. In alcuni casi potrebbe essere indispensabile visualizzare i dati più recenti, mentre in altri potrebbe essere accettabile visualizzare dati che risalgono ad alcune ore o alcuni giorni prima.

Per riflettere questi criteri che determinano il livello di aggiornamento dei dati, il modello UDM consente di gestire la cache in modo esplicito, ad esempio tramite la definizione di una pianificazione per l'aggiornamento giornaliero della cache alle 14.00, oppure in modo trasparente tramite il “caching attivo”. Sulla base del livello di aggiornamento dei dati specificato dall'utente, il modello UDM creerà e gestirà la cache in modo automatico per ottimizzare i tempi di risposta alle query.

Analisi

Nelle sezioni precedenti è stato illustrato come il modello UDM può supportare l'esplorazione interattiva dei dati. La semplice disponibilità delle informazioni nelle origini dei dati sottostanti, anche se in una forma che ne semplifica notevolmente sia l'interpretazione che l'utilizzo, non consente tuttavia di realizzare l'obiettivo di incorporare nel modello dell'utente la regola business. Pertanto, il modello UDM consente di definire calcoli sia semplici che complessi da eseguire sui dati.

Analisi di base

Le query in genere restituiscono dati aggregati. Una query tipica, ad esempio, mostra le vendite per categoria, invece di mostrare ogni ordine di vendita. Nei dati relazionali sottostanti tuttavia non è presente alcun elemento che definisca come aggregare una determinata misura. Per l'importo delle vendite, ad esempio, è possibile eseguire una somma, ma per il prezzo unitario è necessario calcolare una media. Il modello UDM consente di aggiungere questa semantica.

La modalità di aggregazione può essere definita in vari modi:

• È possibile utilizzare una semplice funzione di aggregazione, ad esempio Sum, Count, Distinct Count, Max o Min.
• È possibile definire l'aggregazione come semiadditiva. Pertanto, una semplice funzione quale Sum viene utilizzata per tutte le dimensioni eccetto quella temporale, per la quale viene utilizzato il criterio dell'ultimo periodo. Ad esempio, sebbene il livello delle scorte possa essere calcolato per un'intera categoria di prodotti tramite la somma dei valori dei singoli prodotti, il livello delle scorte per il mese non è determinato dalla somma dei livelli delle scorte di ogni giorno, bensì corrisponde al livello delle scorte dell'ultimo giorno del mese.
• È possibile definire l'aggregazione in base al tipo di conto, ad esempio Income o Expense.
• È possibile personalizzare l'aggregazione per soddisfare particolari esigenze.

Un modello UDM può inoltre contenere membri calcolati. Questi membri non hanno un'associazione diretta con l'origine dei dati, ma derivano da tali dati. Ad esempio, è possibile definire un membro calcolato Variance per calcolare la differenza tra le vendite e gli obiettivi di vendita.

In modo analogo, un modello UDM può definire set di entità di interesse per l'utente, ad esempio i dieci clienti con il volume di vendite più alto oppure i prodotti più importanti. Questi set possono quindi essere utilizzati per limitare l'ambito di una query a un set di entità particolare.

Analisi avanzate

I calcoli richiesti dagli utenti sono talvolta molto più complessi dell'esempio "Variance" proposto in precedenza. Di seguito sono riportati alcuni esempi di calcoli complessi:

• Visualizzare la media mobile di tre mesi per ogni periodo di tempo.
• Confrontare la crescita annuale per questo periodo e per lo stesso periodo dell'anno precedente.
• Se le vendite sono espresse nella valuta di base, convertirle di nuovo nella valuta originale, in base al tasso di cambio medio giornaliero al momento della vendita.
• Calcolare le vendite previste per categoria per l'anno successivo prevedendo un aumento del 10% rispetto all'anno corrente e quindi determinare il budget per ogni prodotto in base alle vendite medie relative negli ultimi tre anni.

UDM offre un modello avanzato per la definizione di questi tipi di calcoli ed è simile a un foglio di calcolo multidimensionale, in cui è possibile calcolare il valore di una cella in base ai valori delle altre celle. Anche questa metafora, tuttavia, non consente di descrivere in modo adeguato la complessità dei calcoli eseguiti nel modello UDM. Il valore di una cella può essere calcolato non solo in base al valore di un'altra cella, ma anche in base al valore precedentemente contenuto in tale cella. È pertanto possibile supportare equazioni simultanee. Ad esempio, il profitto viene calcolato sottraendo le spese dai ricavi, ma i premi produzione, inclusi nelle spese, vengono calcolati in base al profitto.

Oltre a fornire il potente linguaggio MDX (MultiDimensional Expressions), progettato in modo specifico per la gestione di tali calcoli, il modello UDM supporta l'integrazione con Microsoft .NET. Questa integrazione consente di scrivere stored procedure e funzioni in qualsiasi linguaggio .NET verificabile, ad esempio C#.NET o Visual Basic.NET. Sarà quindi possibile richiamare la stored procedure o la funzione da MDX per utilizzarla all'interno di calcoli.

Il client è isolato dai dettagli di tali calcoli. Dal punto di vista delle applicazioni client, il modello include semplicemente misure più utili. Nell'esempio seguente l'utente visualizza varie misure calcolate, in base a Sales, per i prodotti venduti negli Stati Uniti che consentono di realizzare il maggior profitto.

Integrazione con il data mining

La possibilità di visualizzare i dati in un formato avanzato facilmente comprensibile è utile, ma gli utenti devono anche poter derivare nuove informazioni da tali dati.

Il modello UDM è perfettamente integrato con la tecnologia di data mining e consente pertanto di estrarre dati e successivamente di utilizzare i modelli individuati a scopo di stima.

Rendere utilizzabili i dati

Spesso la visualizzazione dei dati genera negli utenti nuovi interrogativi o li spinge a intraprendere determinate azioni. Ad esempio, l'utente può avere necessità di:

• Individuare gli importi dettagliati delle vendite che contribuiscono a determinare un particolare valore.
• Incrementare un obiettivo di vendita troppo basso.
• Aggiungere un commento a un dato strano per contrassegnarlo.
• Verificare le informazioni dettagliate disponibili sul sito Web per una promozione.

Presentare i dati agli utenti in modo facilmente comprensibile non è sufficiente. È anche necessario semplificare l'esecuzione di operazioni sui dati visualizzati.

Il modello UDM supporta queste operazioni in due modi:

• Consentendo di riscrivere le modifiche nei dati
• Consentendo di associare operazioni ai dati

Writeback

Il modello UDM non è di sola lettura e consente di aggiornare i dati. Nel caso delle misure, gli aggiornamenti possono essere memorizzati separatamente rispetto ai valori originali sotto forma di valori delta.

È inoltre possibile aggiornare valori di riepilogo. Si consideri, ad esempio, uno scenario relativo a un budget. L'importo del budget può essere in ultima analisi scomposto a un livello dettagliato, per team e conto, ma inizialmente i valori sono noti a un livello più generalizzato, ad esempio per reparto o per tipo di conto.

Azioni

Il modello UDM supporta l'esecuzione di azioni tramite la creazione di un collegamento tra i dati e un'azione da eseguire sulla base di tali dati. I principali tipi di azioni sono:

• URL: consente di accedere a un URL specificato. Questo tipo di azione supporta l'indirizzamento dell'utente sia a un URL particolare per ottenere ulteriori informazioni sia a un'applicazione basata sul Web per eseguire un'operazione. Ad esempio:
  • Per un prodotto, è possibile accedere al sito Web della società in cui viene descritto tale prodotto.
  • Per una combinazione prodotto/magazzino, è possibile avviare l'applicazione di gestione delle scorte basata sul Web passando i valori del prodotto e del magazzino come parametri in modo da poter aumentare il livello di sicurezza delle scorte.
• Report: consente di eseguire un report specifico. Ad esempio, per un dato prodotto, l'azione potrebbe eseguire un report con parametri nel quale vengono descritti il prodotto e lo stato dell'ordine corrente.
• Drill-through: consente di eseguire il drill-through al livello di dettaglio più basso disponibile. Ad esempio, un utente che esamina le vendite totali per prodotto e cliente può eseguire il drill-through per visualizzare tutte le transazioni di vendita che incidono sul calcolo del totale.

Le azioni possono essere associate ad aree particolari dei dati. Ad esempio, un'azione per la visualizzazione di una pagina Web può essere associata a ogni prodotto, mentre l'azione per la visualizzazione delle transazioni dettagliate di trasferimento delle scorte deve essere associata a ogni valore della quantità per prodotto e magazzino.

Nonostante le azioni vengano definite all'interno del modello UDM, è compito dell'applicazione client recuperare informazioni dettagliate sulle azioni applicabili, rendere le azioni disponibili all'utente e quindi avviare l'azione quando necessario.

Protezione

È possibile controllare l'accesso al modello UDM. Di seguito sono descritte le principali funzionalità di protezione:

• Il modello UDM offre una protezione basata sui ruoli. È possibile definire nuovi ruoli, assegnare autorizzazioni a tali ruoli e aggiungere utenti a ogni ruolo come membri. Le autorizzazioni effettive di un utente sono determinate dall'unione delle autorizzazioni assegnate a ogni ruolo a cui l'utente appartiene. Le autorizzazioni assegnate a un ruolo possono anche includere "negazioni assolute", che rimuovono un diritto indipendentemente dagli altri ruoli a cui un utente appartiene.
• Le autorizzazioni amministrative, ad esempio per la modifica di un modello UDM, possono essere assegnate indipendentemente dalle autorizzazioni di accesso ai dati. È inoltre possibile definire autorizzazioni distinte per la lettura dei metadati dell'oggetto e per l'accesso in lettura/scrittura ai dati.
• È possibile proteggere i dati con diversi livelli di granularità, fino alle singole celle. È ad esempio possibile limitare la possibilità degli utenti di visualizzare le vendite del prodotto "Widget" per il cliente "ACME". È inoltre possibile definire una protezione condizionale, che consente ad esempio a un ruolo di vedere lo stipendio totale di un reparto solo se il numero di dipendenti che lavorano in tale reparto è maggiore di cinque.
• Le autorizzazioni possono definire se è necessario utilizzare totali visualizzati, nel qual caso i totali riflettono solo i membri di livello inferiore per i quali l'utente dispone di autorizzazioni. Anche l'accesso alle celle può essere di tipo condizionale, vale a dire che le celle che derivano da altre celle sono visualizzabili solo se possono essere visualizzate anche le altre celle. Se, ad esempio, il profitto deriva dai redditi e dai costi, gli utenti possono visualizzare i profitti solo per i prodotti di cui sono autorizzati a visualizzare i redditi e i costi.

Vedere anche

Altre risorse

Concetti di base su Analysis Services

Guida in linea e informazioni

Assistenza su SQL Server 2005