What the heck is ODBC? Pt 2

What the heck is ODBC? Pt 2
Photo by Etienne Girardet / Unsplash

Following on from the part one post, Kate had some follow up questions. Tableau has an ODBC discovery layer, which analyses the driver and assesses if Tableau functionality will be impacted when using a live connection (which is limited to the capabilities of the database, rather than the broader capabilities of Tableau).

When major limitations are detected, it is recommended to create an extract and perform filtering and other functions in Tableau. Does this mean that you bring in more items/words since you can't perform the full translation at the database source/in the original language?

What are the costs of limited translations? How does it impact the data on platform?

The ODBC discovery tool is pretty neat - imagine if we had something like that for regular languages! So, sort of, but I might explain it a bit differently.

- When watching something on TV, particularly something newsy or specialist, if you turn on live closed captioning/translation, do you find that sometimes it fluffs the words and concepts that the original is trying to communicate? Whereas if you're watching a drama or something non live, if you know both languages you might differ in how you choose to translate it into closed captions, but essentially the differences are pretty minor?

Creating an extract, in my mind, is the latter. Some languages are easier to translate between live because they have similar concepts, or grammatical structures (French and Portuguese follow mostly the same word order in a sentence, for example), while some we need to read or listen to the whole item before we do any translating because it's expressing a complex concept, which might not have a direct translation in our language. "Hygge" in Danish is often translated to English as "cosy"; in Danish, it has much more meaning - but cosy will do in most concepts for translation. "Saudade" in Portuguese however, is a small word for a very big cultural concept and as per the length of this wiki trying to explain the translation, a single common word in English wouldn't really cut it.

So, returning to ODBC, as per Tableau's list of ODBC discovery, Major and Fatal limitations indicate there is something in the way the database works that is either missing or conceptually different which cannot be bridged very quickly (as it would be with Full Functionality or Minor Limitations). Creating an extract means taking it and creating a version of it in Tableau's hyper engine to then work with. So, taking a recording of something and giving yourself a couple of hours with the dictionary to ensure that it's being translated properly, as opposed to throwing it in Google Translate and hoping for the best.

The costs of limited translations depends on what you're doing. Looking at this support article, Tableau is highlighting a bunch of limitations with the driver for Access. A bunch of these are to do with mathematical and spatial geometry, and if you aren't doing geometry, alright whatever. However, not having "NOW()" - well, if you're doing something which involves relative time (e.g. an awful lot of operational reporting), that could get pretty annoying.

So, you take an extract of the data so you can do those operational reports. That means that Tableau is storing the data somewhere (which is technically duplicating it), and also means that you might have to maintain an extract schedule (which is another gizmo to break, in the grand scheme of all the gizmos you might have going on). It also means that your Tableau-Extract reporting is doing a bunch of calcs which might already exist in Access (but can't be translated over: imagine all the cooking words missing from a dictionary (but everyone still cooks!)), and once you've translated something, you're probably most of the way there but things might come out a little differently. In data however, we value a level of precision as standard that we don't often need when translating languages, so there can be some faff in ensuring they are accurate/of parity.

I'm in Brazil at the moment and I had a curry (Indian) last week, which was customised for Brazilian tastes. I'm used to curries which are customised to UK tastes, and also influenced by a massive South Asian diaspora in the UK; neither Brazilian nor UK curries are quite like what you might get in downtown Mumbai, but the UK one is probably a bit closer than the Brazilian one. São Paulo has a massive Japanese diaspora though, so I imagine the inverse would be true for a Japanese dish like sushi.

I imagine a fatal limitation is probably fairly rare, and probably on niche use cases; there is an Amazonian tribe which doesn't have words to indicate numbers, for example (essentially just "one", "two", "some" and "many").

FragileData

FragileData

A data oik in chaos central.
London