Data model to combine the fact table(s) with the sessions table

Tableau Row-Level Security Using Initial SQL with PostgreSQL

Imagine you have Tableau dashboards that require the use of row-level security on data coming from PostgreSQL, but the connection to that database is established through the same technical user for everyone. How can you achieve that? Is it even possible? Short answer: it’s possible – and it’s not even that complicated, provided you’re not afraid of some PL/pgSQL scripting, PostgreSQL session IDs, and clicking on that mysterious “Initial SQL” button in Tableau Desktop. For full disclosure I’d like to mention that I found the original idea for this approach on my colleague Bryant Howell’s excellent blog, where he outlines the process for Microsoft SQL Server. That said, the approach I’m showing here is not a mere translation from SQL Server to PostgreSQL, but I also added a few more features.

Continue reading →

Scraping the IMDb for Use in Tableau

In the last quarter of 2016 the German marketing team came up with a great way to follow the immense success of last year’s Tableau Stadium Tour: the Tableau Cinema Tour! After visiting ten cities all over Germany, Austria, and Switzerland, we are now considering rolling it out all over Europe. Stay tuned for that! Since we often got requests for the data used in the main demo, I decided to produce this write-up of how to extract the data from the Internet Movie Database (IMDb). Unfortunately copyright reasons make it impossible for us to just provide you the ready-made data. That said, with this walk-through everybody should be able to get the data!

Continue reading →

Tableau: Ist der erste Film immer der erfolgreichste?

Hinter den Kulissen der Tableau Kino Tour – Teil 2: Die Filmreihen

Dies ist der zweite Teil in einer dreiteiligen Serie zu den technischen Hintergründen der Tableau Kino Tour. Teil 1 beschäftigt sich mit dem Auslesen und Nutzbarmachen der IMDb-Daten, hier geht es um Filmreihen, der dritte Teil wird sich mit den Daten zum “Tatort” beschäftigen.

In den letzten Jahren wurde es unter Filmstudios und Produzenten immer populärer, einen oder meist gleich noch mehrere Teile nachzuschieben, sobald ein Film erfolgreich war. Neudeutsch spricht man dann von einem Franchise – um nicht zu sehr in Anglizismen zu verfallen sprechen wir im Kontext der Tableau Kino Tour lieber von Filmreihen. Die Idee ist ja an sich auch nichts neues, mehrteilige Filme oder Fortsetzungen gibt es schon sehr lange. Man denke nur an “Star Wars”: Der erste Film 1977 wurde noch als einzelnes Werk konzipiert, dann wurden nach dem großen Erfolg zwei weitere Teile produziert, 16 Jahre später nochmals drei Teile, und dann wiederum 10 Jahre später nochmals drei Teile – wovon bisher allerdings erst einer tatsächlich veröffentlicht wurde, auf die restlichen beiden müssen wir uns noch ein wenig gedulden.

Continue reading →

Tableau Kino Tour: Budget vs. Einspielergebnis

Hinter den Kulissen der Tableau Kino Tour – Teil 1: Die IMDb

Im letzten Quartal 2016 haben wir als würdigen Nachfolger der Tableau Stadion Tour 2015/16 die Tableau Kino Tour 2016/17 aus der Taufe gehoben. Nach vier bisher sehr erfolgreichen Stationen (Frankfurt, Hamburg, Berlin und Düsseldorf) warten jetzt im zweiten Teil der Tour in 2017 noch Wien, München, Zürich und Stuttgart auf uns. Da immer wieder die Frage nach den Daten kam, die hinter der Kino Tour stecken, und auch weil es tatsächlich ein sehr interessantes und spaßiges Projekt war, diese Daten zu generieren, habe ich im Folgenden mal die einzelnen Schritte zusammengefasst, vom Download der Quelldaten bis zum fertigen Produkt. Aus Copyright-Gründen dürfen wir die fertigen Daten leider nicht einfach so zum Download anbieten, aber mit der Schritt-für-Schritt-Anleitung sollte es nicht allzu schwierig sein, das zuhause selbst nachzustellen.

Continue reading →

Annoying join behavior in QGIS

Today I stumbled across something I wouldn’t exactly consider a bug, but at least some rather unintuitive and annoying behavior in QGIS when performing table joins.

I did something very mundane: joining a Postgres table of spatial data to another Postgres table of attribute data. The normal way to do this (for me) is as follows:

  1. Open the spatial table using Layer > Add Layer > Add PostGIS Layers...
  2. Open the attribute table the same way (1 & 2 can be loaded in one go)
  3. Join the tables in the spatial table’s Properties dialog.

For that last step I decided to join the two tables (plr is the spatial table here, while mss has the attributes) using the field plr_id, which exists in both tables and only once on each side (hence a plain vanilla 1:1 join).

Add vector join dialog window in QGIS 2.8

Add vector join dialog window in QGIS 2.8

That works perfectly fine, except that somehow the order of the joined fields appears to get messed up:

QGIS attirbute table with erroneously shifted field contents

QGIS attirbute table with erroneously shifted field contents

Some research revealed that this seems to be a problem caused by identical field names in the two joined tables other than the join field itself. In my case the aforementioned plr_id was used to join the two tables, but in addition both tables also had a field gid, as can be seen in the following screenshot on the left:

Table design in pgAdmin: original table including field gid on the left, fixed table without (unnecessesary) field gid on the right

Table design in pgAdmin: original table including field gid on the left, fixed table without (unnecessesary) field gid on the right

Removing this field gid from the attribute table mss was no problem, since the 1:1 relation to the spatial data uses the key plr_id anyways. As can be seen in the screenshot above on the right, the new table mss2 is identical to mss, only without the field gid. And lo-and-behold – joining this attribute table to the spatial table plr in QGIS works flawlessly now:

QGIS attirbute table with correct field contents

QGIS attirbute table with correct field contents

This problem had already been identified in QGIS 2.0 in late 2013, and has been marked as fixed in the meantime. Removing fields with identical names in the two tables is one – admittedly rather radical way – to solve circumvent the issue. Another, more intuitive way would be to choose a meaningful table prefix in the Add vector join dialog which can be seen in the first image above. As you can see I checked the Custom field name prefix checkbox but left the field empty. I prefer this, since it keeps my field names nice and tidy, but in cases where homonymous fields exist in the two tables you will run into trouble – hence entering a prefix here would be a nice and easy fix for this issue.

Everything described above was performed on QGIS 2.8.1-Wien (64bit) on a Windows 7 machine and PostgreSQL 9.1.16 on a 64bit Ubuntu 4.6.3 server (PostGIS 1.5.3).