Information Density bei Concatinierter Faktentabelle

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 in Qlik
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 Example Concat Facts
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 veröffentlichen

heldendaten GmbH,2017