Zu jedem Feld kann man sich in QlikView und Qlik Sense die
Information Density anzeigen lassen. Das ist eine wichtige Information, um die Datenqualität Ihrer App zu überprüfen.
Hier ein Beispiel: im Kundenstamm haben nur 75,8% aller Kunden eine
Telefax Nummer gepflegt. Das könnte bei Ihrer nächsten Telefax-Marketing Kampagne (falls es soetwas noch gibt :-)) störend, für Ihre nächste Rechnungslegung unter Umständen sogar sehr ärgerlich sein!
 |
Information Density - links in Qlik Sense, rechts in QlikView |
Jedes einzelne Feld zu überprüfen ist einigermaßen zeitaufwendig, weswegen wir in unserem Heldendaten Applikationstemplate gerne den Data Profiler von
quickintelligence.co.uk nutzen. Dort sieht man die "Null Values" eines Feldes auf einem Blick.
 |
Telefax hat 22 Null Values, was die Information Density von 75,8% ergibt |
 |
Auch andere Felder im Kundenstamm haben eine Information Density < 100 % |
Information Density bei Concatinierter Faktentabelle
Schwieriger wird es mit der Information Density-Kennzahl, wenn Sie ein Datenmodell mit mehreren Faktentabellen bauen. Das passiert sehr häufig: Ihre Applikation hat mehrere Faktentypen (IST-Zahlen und Budget-Zahlen) oder Sie verheiraten die ERP-Altdaten mit Daten ihres aktuellen ERPs. Steht ist es wichtig zu wissen, welche Spalten wie gut gefüllt sind. Vor allem wenn man sicherstellen möchte, dass der Anwender mit seinen Selektionen die Daten aus allen Quellsystemen wählt (also die Information Density 100% ist)
Zur Veranschaulichung, hier ein Beispiel wie in Qlik solche Faktentabellen aussehen:
 |
Concat Fakten in gemeinsame Faktentabelle |
Für den Faktentype
Procurement Cost gibt es das Feld
Region in der Quelle nicht. Damit ist die Information Density für diese Feld jetzt nur noch 14 (befüllte Zeilen) /20 (Zeilen insgesamt) =
70%. Viel interessanter wäre es aber zu wissen, dass das Feld
Region folgende Information Densities hat:
- Sales: 100%
- Plan Yearly: 100%
- Procurement Cost: 0%
Wählt ein Anwender einen Eintrag im Feld
Region an der Oberfläche, so sieht er keine Procurment Costs mehr. Das kann gewünscht sein, oder ein fehlerhaftes Mapping/fehlende Daten sein. Eine Information Density
pro Faktentyp ist also Notwendig für eine umfassende Problemanalyse.
Dafür benötigen wir zuallererst ein Feld
Source um zu wissen aus welcher Quelle welche Datensatzzeile ursprünglich kommt. Das Aufbauen Ihrer Faktentabelle
Facts sollte also etwa so aussehen (je nachdem ob aus Datenbank/QVD/resident)
Facts:
load
*,
'Sales' as Soure
from/resident Sales;
concatenate (Facts)
load
*,
'Plan Yearly' as Soure
from/resident Plan Yearly;
concatenate (Facts)
load
*,
'Procurement Cost' as Soure
from/resident [Procurement Cost];
Als nächsten Schritt müssen
NullCounts() für alle Felder im Script berechnet werden. Wenn Sie ein 3-Schichtenmodell nutzen, würde ich das Script im Datenmodell hinzufügen. Bei großen Datenmengen und vielen Faktenspalten kann das Skript schon mal länger rechnen - fügen Sie sich vielleicht einen Variablen-Schalter ein, damit das Skript beim Entwickeln nicht ständig ausgeführt wird.
//config
let tFactTableName = 'Facts';
let tSourceTable_Field = 'Source';
//Generate Fields that are in Facttable
let vAggregations = '';
for i = 1 to nooffields('$(tFactTableName)')
let vField = Fieldname($(i),'$(tFactTableName)');
if (vField <> '$(tSourceTable_Field)') then
let vAggregations = vAggregations & 'nullcount([$(vField)]) as [$(vField)] ,';
end if
next
trace *************** Check for fields: $(vAggregations);
ttFactsInfo:
load
$(tSourceTable_Field),
$(vAggregations)
1 as dummy
resident $(tFactTableName) group by $(tSourceTable_Field);
drop field dummy;
//Transform table to get all Fieldnames in a single column
tFactsInfo:
CrossTable (FieldName,NullCount,1)
load
*
resident ttFactsInfo;
drop table ttFactsInfo;
//Check how many rows each "Source Table" has
MappingFactsSourceCount:
mapping
load
$(tSourceTable_Field),
count($(tSourceTable_Field)) as AllCount
resident $(tFactTableName) group by $(tSourceTable_Field);
//Generate FactsInfo
FactsInfo:
load
$(tSourceTable_Field),
FieldName,
applymap('MappingFactsSourceCount',$(tSourceTable_Field), -99)
as AllCount,
NullCount,
applymap('MappingFactsSourceCount',$(tSourceTable_Field), -99)-NullCount
as FoundCount
resident tFactsInfo;
drop table tFactsInfo;
//optional drop table Facts;
let tFactTableName = ;
let tSourceTable_Field = ;
Das Skript erzeugt einen neue Tabelle FactsInfo mit den Feldern
NullCount und
FoundCount für jeden
Fieldname pro
Source-Tabelle. Damit lässt sich dann eine Pivottabelle bauen, die Ihnen die Information Density pro Feld zeigt. Unterhalb sehen Sie ein beladenes Beispiel in Qlik Sense
 |
Information Density für die Fakten: Buget, ORDERS und VBRP |
Die
Gesamtwerte-Spalte zeigt die Information Density wie sie Qlik im Datenmodell anzeigen würde. Daneben sehen wir die Befüllung in den Faktenquellen. Man sieht zum Beispiel auf einen Blick, dass das Feld
PRODH (Produkthierarchie) in einigen
ORDERS-Faktenzeilen
nicht befüllt ist, da die Information Density dort nur
99,98% ist. Das Feld
%KUNNR hat leere Einträge in
ORDES und
VBRP. Die Spalte
NetSalesBudget hat nur eine Information Density von
1,94% - das ist aber OK weil es nur in der
Source-Tabelle Budget befüllt ist (und dort dafür mit
100% immer einen Wert hat)
Als keines Gimmick sei auch noch das Sortieren der Pivot-Tabelle genannt. Sowohl die Sortierung nach Information Density, als auch eine alphabetische Sortierung der Feldnamen kann Sinn machen. Mit einer Variable kann die Sortierung hin- und hergeschalten werden. Siehe Screenshot mit alphabetisch sortierten Feldnamen - jetzt mit QlikView:
 |
Information Density alphabetisch sortiert |
Das komplette Beispiel für QlikView und Qlik Sense finden Sie unter
content.heldendaten.eu/InformationDensity.zip
0 Response to "Information Density bei Concatinierter Faktentabelle"
Kommentar posten