UGISS Community

Ciao Stefano,

faccio prima una premessa: confesso di non aver compreso appieno cosa vuoi ottenere con precisione.

Anche perchè nel titolo parli di security ma da quello che posso avere capito probabilmente il tuo problema è un altro.

Potresti chiarirmi meglio la cosa e in particolare:

- se l'eliminazione dell'elemento "Sotto Livello 1.2" vuoi ottenerla nel risultato della/e query MDX o direttamente nei metadati.

- che soluzione avevi adottato in SSAS 2000 per risolvere il problema?

Francesco

La cosa da tenere in considerazione è che i livelli che io vado ad escludere, non sono fissi, cioè può venirsi a creare la situazione che con un aggiornamento quel/i determinati livelli possano trovarsi invece la misura piena ed in quel caso l'utente deve vederli. Questa precisazione nasce dal fatto che non posso a priori escludere questo livello, ne manutenerlo  mensilmente visto che ho una serie di clienti e tante dimensioni di analisi che mi costerebbe troppo verificare ogni mese, singolarmente quali dei livelli dovrebbero riempirsi piuttosto che no e quindi escluderli manualmente.

Come mi chiedi ti faccio un esempio di come applicavo la security in 2000 dove addirittura facevo vedere i livelli risultanti da una crossjoin di 2 dimensioni e dove appunto i livelli della dimensione disponibili all'utente vengono filtrati sempre a livello di metadati.

Questa espressione la applico alla Dimensione1 nel campo Allowed Members, coinvolgendo un ulteriore Dimensione2 con i relativi sotto livelli, estrae e filtra solo quelli che non sono vuoti.

Ciao Stefano,

da quello che scrivi avevo interpretato correttamente. Sinceramente non mi è mai capitato di "nascondere" nei metadati dei membri di dimensione in funzione delle misure. Al momento sono impossibilitato a fare qualche test (spero nel weekend!), comunque qualche considerazione la posso fare.

1) In 2005 le Dimension Data security (database dimension o cube dimension) vengono configurate a livello di attributo. Quindi è possibile definire un set di Allowed o Denied members per un dato attributo. Per effetto dell'autoexists, però, vengono influenzati anche i membri degli altri attributi della dimensione, quindi, implicitamente, si definisce una sicurezza a livello di dimensione.

2) Teoricamente quello che hai fatto in SSAS 2000 è quindi replicabile in SSAS 2005

3) Nel codice MDX che utilizzavi in SSAS 2000, non vengono definite nè la misura nè la data. Quindi significa che quel codice utilizzerà i rispettivi default member. Per ciò che riguarda la misura ciò comporta che il codice funzionerà solo con una misura e che, nel caso tu abbia una sola misura, con l'intero cubo. Per ciò che riguarda la data se, come spesso accade, questa dimensione ha un membro "All" e quest'ultimo è il default member, significa che quel codice elimina tutti i membri che non hanno la default measure valorizzata nell'intero cubo (data = "All") Se queste ipotesi sono vere potresti considerare l'eventualità di "eliminare" direttamente nella fase ETL i membri non valorizzati (cosa che mi è capitata spesso di fare)

4) Considera anche la possibilità di usare la funzione NonEmpty() (al posto di Filter(Set, NOT IsEmpty(Value))) che fornisce prestazioni migliori in quanto simula il comportamento dell'autoexists

Spero di riuscire presto a trovare il tempo per fare qualche prova e darti una risposta definitiva per il tuo problema

 Francesco

Ciao Francesco.

Ho l'impressione che ti abbia posto un quesito di non facile risoluzione e mi scuso se la sua esposizione da parte mia non risulta molto chiara.

Per farti capire la mia esigenza ti prova a dare lo scenario.

Ho n fact nel mio udm che raccolgono informazioni di n clienti.

La struttura dei cubi che realizzo è uguale per tutti i clienti; quindi se il mio cubo prevede 25 dimensioni di analisi e 40 misure queste devono essere visibili per tutti i clienti.

Quello che può cambiare da un cliente ad un altro è ciò che deve essere reso visibile durante la navigazione in termini di livelli delle dimensioni.

L'MDX che ti ho inserito ho sempre creduto che ragionasse implicitamente sulle misure, cioè che il filter mostrasse i livelli delle dimensioni incrociate tra loro solo per quelle misure che per almeno un livello di entrambe non restituisse un cella nulla.

Quindi quello che vorrei riuscire a fare è quello di rendere dinamici i livelli di una dimensione di analisi proprio a livello di metadati; se comunque in 2005 vi è una modalità diversa da 2000 a me sta bene lo stesso in quanto può anche essere che le modalità per fare questo siano variate.

Credo che l'ottica di lettura per la risoluzione di questo problema possa anche essere un'altra ovvero: data una dimensione cliente che ha una gerarchia che si sviluppa in questa maniera ORAGANIZZAZIONE --> RAGGRUPPAMENTI DELLE FILIALI --> NOME PUNTUALE DELLA FILIALE incrociata con la dimensione ANNO --> SEMESTRE --> TRIMESTRE --> MESE e la misura VENDITE renda visibile solo i membri a livello di metadati quindi fisicamente selezionabili laddove non vi sia un incrocio null; ovviamente senza sapere a priori quali sono i valori delle dimensioni che creano incroci vuoti.

Spero d'avere aggiunto ulteriori dettagli alla casistica in questione.

Grazie Francesco.

 Stefano

Ciao Stefano,

intanto ti confermo quanto scritto nel mio precedente post, ossia che quanto da te fatto in SSAS 2000 è replicabile in SASS 2005. Mi sono limitato a testare su di una sola dimensione (Tempo) la possibilità di "filtrare" i soli mesi aventi dei dati associati nel cubo. In questo semplice scenario, utilizzando la funzione NONEMPTY(), la cosa funziona tranquillamente.

Veniamo alla tua situazione.

E' evidente che lo scenario che delinei è più articolato di quanto si poteva intuire all'inizio. Ovviamente è impossibile fornirti una soluzione senza conoscere tutti i dettagli ed è altrettanto improponibile riuscire a farlo in questa sede.

In linea generale quello che stai cercando di ottenere attraverso la security (con una sorta di "dynamic security")  rischia di diventare molto presto improponibile in termini di prestazioni e scalabilità perchè di fatto costringe il motore di SSAS ad interrogare l'intero cubo per ottenere i metadati. E questa cosa con cubi grandi e con molti utenti è sicuramente da evitare.

Come indicazione generale ti consiglierei, come prima cosa, di fermarti un momento ad analizzare il tuo scenario a 360 gradi verificando innanzitutto le "reali" esigenze dei tuoi clienti/utenti. Mi è capitato spesso di confondere la soluzione tecnica che avevo in mente con le reali esigenze dei mei utenti/clienti e ti posso assicurare che fermarsi a rianalizzare un'intero progetto (magari alla luce di nuovi dettagli di cui non avevamo conoscenza all'inizio) è un'attività che ripaga sempre.

Come secondo passo (conseguenza del primo) prova a verificare se non esistano alternative praticabili relativamente al design dei cubi e delle dimensioni e/o alla fase ETL e che ti consentano di ottenere più agevolmente ciò che ti serve.

Francesco

Ciao Francesco, innanzi tutto grazie per l'ulteriore risposta.

Rispondo prima alle tue considerazioni sulla "valutazione della situazione": con il passaggio dalla versione 2000 alla versione 2005 vi è stato una rianalisi dei requisiti utente ed un'attenta rianalisi della metodologia sino a qui utilizzata.

Risultato: non vi è nulla di modificabile nè in ambito ETL nè in ambito esigenze utente (non mi dilungo nelle motivazioni, ma "deve essere così")

L'applicazioni delle security così come sono impostare ora su 2000 ci hanno sempre permesso d'avere prestazioni più che dignitose quindi a maggior ragione con i benchmark prestazionali offerti dalla versione 2005 non dovremmo avere problemi.

Ritengo comunque che i concetti suggeriti siano un must da un punto di vista progettuale ed essendo un collaboratore di una persona che ha disegnato concettualmente la prima versione in 2000 non ho molta possibilità di sovvertire certe decisioni....anche perchè personalmente sono molto acerbo sotto questo punto di vista.

Detto questo, ho una domanda forse stupida: quando parli dell'applicazione del NONEMPTY (premetto che con una query MDX ho già verificato il corretto funzionamento della stessa) in che punto dovrei andarla ad inserire? Cioè quando applico questa sintassi ad una dimensione in una query MDX essa viene applicata sull'intera dimensione, mentre quando devo inserirla in Visual Studio 2005 la dimensione ragiona per livelli della dimensione e non globalmente.

Quindi al momento il mio problema consiste nell'applicazione della sintassi alla dimensione...

p.s. io credo di dover lavorare sul tab "Dimension Data" del "Role" associato al mio utente, se questo però non è corretto....ok attendo consigli.

Sempre grazie,

 Stefano

Ragazzi ci sono riuscito.

Ringrazio Francesco.

Praticamente il mio errore consisteva nel NON applicare la security agli ATTRIBUTI della dimensione bensì dimensione.

Detto questo quando facevo la query MDX applicata alla dimensione non avevo errori però nel momento in cui applicavo tale MDX ovviamente non poteva funzionare perchè li si ragiona sugli attributi.

Credo d'avere commesso un errore forse un pò banale, ma volevo comunque ringraziarvi per i suggerimenti e per le risposte che avete dato.

Stefano

Ciao Stefano,

sono contento che tu sia riuscito a risolvere il problema e mi scuso se non sono stato sufficientemente chiaro riguardo le sicurezze degli attributi (punto 1 del mio secondo post).

Per quanto riguarda l'errore, non preoccuparti, se a posteriori un errore ci sembra "banale" significa che abbiamo capito e soprattutto abbiamo imparato qualcosa ergo non commetteremo più l'errore (perlomeno non "quello" ).

Francesco