May 2008 Archives

IT

Ricordo che alla prima lezione di statistica il professore ci aveva parlato di campionamento statistico e inferenza statistica, poiché è improponibile fare un'indagine su tutta la popolazione statistica.
In realtà, con il data mining non solo è più che proponibile, ma è la norma.

Comunque, con QlikView qualora si voglia caricare un campione di righe casuale da una tabella si può usare sample.
sample è un prefisso di load e select il cui unico argomento è la probabilità di caricare una riga.

Ad esempio:

sample '1%' load * from file.qvd (qvd);

Se file.qvd è una tabella di 100 milioni di righe, QlikView ne caricherà solo circa un milione scelto a caso.

EN

On my first statistics class, our teacher told us about sampling, and why it is really necessary for real world applications. Actually, data mining does indeed work on a full statistic population, usually.

By the way, you can load a random sample from a table by using the sample prefix, whose only argument is the probability of actually reading a row.

Here's an example:

sample '1%' load * from file.qvd (qvd);

Given a 100 million rows file, QlikView will load roughly 1 million of random rows.

IT

Ricollegandomi al messaggio di qualche giorno fa, elenco qualche appunto sulla restrizione accessi di QlikView.

Funzionamento * (asterisco) in Section Access
Indipendentemente dall'eventuale valore di star is, l'asterisco nella Section Access non si comporta come nella Section Application.
In quest'ultima, posto che sia stato specificato star is *;, significa qualunque valore (generalmente utilizzato per campi chiave, permette di collegare quella riga a righe di altre tabelle in cui c'è qualunque valore in quel campo); nella Section Access, invece, significa i valori già elencati in questo campo nella Section Access.
Faccio un esempio pratico: supponiamo di avere, nella Section Application, una tabella di fatti con i centri di costo 1, 2, 3. Nella Section Access vorremo specificare due utenti normali, i responsabili dei centri di costo 1 e 2, e un superutente (diciamo l'amministratore delegato). I primi due vedranno appunto il centro di costo 1 e 2 rispettivamente, ma mettendo un * per la riga dell'amministratore si otterrebbe che quest'ultimo può vedere solo i centri di costo 1 e 2, cioè i valori di quel campo nella Section Access. È alquanto diverso da ciò che solitamente ci aspetteremmo.
Questo problema è aggirabile sostituendo il * con un determinato codice e utilizzando una tabella di decodifica nella Section Application che faccia appunto uso di star is *;.

Utente di dominio in più gruppi
Utilizzando QlikView Server è possibile definire restrizioni in base al nome utente o al nome di un gruppo di Active Directory a cui l'utente appartiene (NTNAME nella tabella della Section Access).
In caso un utente appartenga a due (o più) gruppi, entrambi presenti come NTNAME, possiamo individuare due casi:

1. i gruppi filtrano sullo stesso campo: QlikView si fermerà alla prima regola che viene incontrata, quindi solo uno dei gruppi
2. i gruppi filtrano su campi diversi: QlikView considererà tutte le regole, quindi tutti i gruppi

Se il caso in questione è il primo e si vorrebbe che venissero considerati tutti, conviene caricare la tabella molti a molti delle associazioni utente - gruppo direttamente nella Section Access e fare quindi policy basate su utente, è potenzialmente fattibile con una query LDAP su Active Directory.

Appena ho altro tempo libero mi riprometto di scrivere qualche altro appunto.

EN

Regarding my last post, I'm posting some notes about QlikView access restrictions.

Star in Section Access
Whatever the value of star is, * doesn't work the way we would expect it to in Section Access.
While inside Section Application (provided star is *; is declared) a * in a key field means roughly every value of this field in related tables, though it means every other value within this field of this table when in Section Access.
Let's pretend we have a fact table in Section Application with cost centers 1, 2, 3. We want to declare two normal users in Section Access who can only see respectively costs center 1 and 2, and a third user, an administrator, who can see every cost center. If we used a * as field value in Section Access, we would allow him to see just cost centers 1 and 2, the ones already specified in Section Access, not everyone as we would expect.
This problem is easily bypassed by using a sentry value instead of * and specifying a decode table in Section Application enclosed within star is declarations.

Domain user in multiple groups
By using QlikView Server you can specify restrictions based on Active Directory usernames or groupnames.
Whenever a user belongs to more than one groups and thus more group-based rules match, two cases arise:

1. the rules are filtering on the same field: QlikView will stick to the first one, thus just one group will actually be considered
2. the rules are filtering on different fields: QlikView will match and actually use every single rule

In the former, you could avoid the problem and let every rule match by loading the user - groups associations directly into Section Access, from LDAP for instance.

As soon as I have enough spare time, I'm writing some more tips.