Associationer mellan logiska tabeller

En databas kan ha många tabeller. Varje tabell kan betraktas som en lista över något, och varje post motsvarar en instans av någon typ av objekt.

Exempel:  

Om två tabeller innehåller olika saker - såsom om den ena är en lista över kunder och den andra en lista över fakturor - men har ett fält gemensamt, exempelvis kundnummer, betyder detta vanligtvis att det finns en relation mellan de båda tabellerna. Enligt standardiserade SQL-frågeverktyg ska de två tabellerna nästan alltid länkas (join).

Tabeller som definieras i QlikView-skriptet kallas logiska tabeller. QlikView gör associationer mellan tabellerna utifrån fältnamnen och skapar länkningar när ett urval görs, t.ex. när användaren väljer ett fältvärde i en listbox.

En association är således nästan samma sak som en join. Den enda skillnaden är att en länkning (join) skapas vid skriptexekveringen: en logisk tabell är vanligen resultatet av en länkning. En association, däremot, görs efter det att den logiska tabellen skapats: associationer görs alltid mellan logiska tabeller.

Fyra tabeller: en lista över länder, en lista över kunder, en lista över transaktioner och en lista över medlemskap, vilka alla associeras med varandra genom fälten för Country och CustomerID.

QlikView-association jämfört med SQL natural outer join

En QlikView-association liknar en SQL natural outer join. Associationen är dock mer generell: en outer join i SQL resulterar vanligen i en enkelriktad projektion (en tabell på en annan). En association resulterar alltid i en fullständig (dubbelriktad) naturlig outer join.

Frekvensinformation i associerande fält

Det finns vissa begränsningar i användningen av de flesta associerande fält, d.v.s. fält som är gemensamma för en eller flera tabeller. När ett fält förekommer i mer än en tabell är det svårt för QlikView att avgöra vilken av tabellerna som ska användas för att beräkna frekvens.

QlikView analyserar data för att se om det går att entydigt identifiera en huvudtabell för beräkningar. Ibland är detta möjligt, men för det mesta kan programmet bara göra antaganden. Eftersom ett felaktigt antagande skulle kunna bli katastrofalt (det skulle se ut som om QlikView gjorde ett räknefel), har programmet konstruerats så att vissa operationer inte är tillåtna när de riskerar att ge tvetydiga resultat för associerade fält.

Begränsningar för associerade fält

  1. Det går inte att visa frekvensinformation i en listbox som visar fältet i fråga.
  2. Statistikboxar för fältet visar n/a för de flesta statistiska enheterna.
  3. I diagram är det omöjligt att skapa uttryck som innehåller funktioner som är beroende av frekvensinformation (exempelvis Sum, Count-funktioner och Average) för ett fält, såvida inte Distinct-modifieraren är aktiverad. Efter varje ny laddning undersöker QlikView alla diagramuttryck för att se om några tvetydigheter uppkommit till följd av ändrade datastrukturer. Om tvetydiga uttryck påträffas, visas en varningsdialog och uttrycket inaktiveras. Det går sedan inte att aktivera uttrycket igen förrän problemet rättats till. Om en loggningen är aktiverad, kommer alla tvetydiga uttryck att anges där.

Kringgå detta

Det finns ett enkelt sätt att få bukt med dessa begränsningar. Läs in fältet ytterligare en gång under ett annat namn från den tabell för vilken frekvensinformationen ska ges. Använd sedan detta nya fält för en listbox med frekvens, en statistikbox eller för att göra beräkningar i diagram.

Hjälpte den här informationen?

Varför var informationen inte till hjälp och hur kan vi förbättra den?