I am trying to learn all about Data Visualization and Tableau, so I was wondering if one can combine multiple fields into one, and how to do that?
Thanks
Yes, Tableau is quite versatile. There are many ways to combine multiple fields, for many meanings of the word "combine". If you just want to add some numeric fields together to make a new variable, or string some text fields together to make a larger text field, you can do that by defining a "computed field".
These videos are free and you can watch them to get an idea of what can be done.
Here's a 23 minute overview: https://www.youtube.com/watch?v=6py0jyZc7K4
I see the short intro video on Tableau's site isn't working right now.
Here's another walk-through of what's possible
https://www.tableau.com/learn/training/20213
Wade
Related
Any advice on this would be appreciated! I'm a newbie to Power Automate and Flows, though have watched a lot of tutorial content. I haven't seen a guide for exactly what I'm looking to do, so was hoping an experienced user could provide some advice.
What I need to do is split a PDF into smaller PDFs grouped by entity ID numbers that are on each page. I can't go an split on an increment because some entities have more pages of data that others. Generally the PDF will be about 700 pages and will be split into about 300 PDFs grouped by entity. Currently this is a labor intensive process, and automating would be incredible.
I'm looking into doing it with an Encodian split PDF by text action, but that requires the text is provided. What I need is a way to identify which pages have the same ID and group those into PDFs.
Does anyone have any experience doing something similar?
I have tried putting this together, but so far have only found operations that will let me split when I find a specific text string that must be provided during the operation. What I need is a way to find the entity IDs on each page, and then group the pages for the each entity together and split into its own smaller PDF file.
In my project, I am asked to implement a text query service on the database we are using; Postgresql. I have used Postgresql Full Text Search features, which works fairly fine in terms of time. One problem about full text search is, it does not have fuzzy search abilities. On the other hand, there is an extension named pgtrgm providing functions and operators for determining the similarity of alphanumeric text. Also there are several examples of text search using pgtrgm like:
select actor
from products
where actor % 'tomy';
As you know example of postgres FTS also here;
SELECT title
FROM pgweb
WHERE to_tsvector(body) ## to_tsquery('friend');
So, the main question is, what is the difference between these two search strategies? Which one is more appropriate way for searching texts? Is it possible to mix them? I also need to say that performance is an important concern as well. Thanks in advance!
They do completely different things. About the only thing that is not different between them is that they operate on text and can benefit from use of indexes. From you question, it seems like you already have a good sense of the differences. The appropriate one is the one that does what you want. If one of them was always appropriate, we probably wouldn't have created the other one.
You can mix them, but you will need different indexes for each one, they cannot share an index. Also, you probably need different tables as well, as full text search is more appropriate for sentences or paragraphs while trigram for individual words or short phrases.
One way to mix them would be to have one table of full texts, and another table which lists only each distinct word present in any of the full texts. The 2nd table could be used to detect probable typos in the query, and then once those are fixed by suggestions from trigram searching, run the fixed query against the 1st table.
The difference is quite huge - in fuzzy search, you're searching for a similar result, in full-text search - for the exact same. If one is more appropriate than the other is the matter of use-case.
If you don't need fuzziness, don't use it, it's a huge performance overhead because it has to match the text not exactly, but also try other combinations.
I am going to attend the Instance Matching of OAEI, now I need to make my results to Alignment Format. In order to achieve it, I have learned official tutorials.(link:http://alignapi.gforge.inria.fr/tutorial/tutorial1/index.html).
But there are many differences between the method taught and the method I want. In other words, I can't understand the API.
This is my situation:
I have 2 rdf file(person11.rdf and person12.rdf respectively.data link is http://oaei.ontologymatching.org/2010/im/index.html, the PR dataset), each file has information of many person. I want to find the coreferent entities, the results must be printed in Alignment Format. I find the results by using SPARQL, but I don't know how to print it in Alignment Format.
So, I have three questions:
First, if I want to generate a Alignment Format file, is the method taught the only way?
Second, can you give me your method(code better) to generate the Alignment Format file? Maybe I am wrong from the beginning, can you give me some suggestions?
Third, if you attended OAEI or know something about Instance Matching, can you give me some advice? I want to find the coreferent entities.
Thank you!
First question: I guess that the "mentioned method" is the one in tutorial1. It is not the appropriate one since you have to write a program to output the alignment format and this is a command line interface tutorial. In this case, you'd better look at http://alignapi.gforge.inria.fr/tutorial/tutorial2/index.html
Then, there are basically two ways to do:
The advised one (for several reasons and for participating to OAEI) is to follow these tutorials, to create an empty alignment in it, to create the correspondences from the results of your SPARQL query and to render it. Everything is covered by the tutorials but the part concerning your SPARQL queries. This assumes that you are programming in Java.
The non-advised solution (primarily non advised because you will have to debug your own renderer), is to write, in any programming language that you want a program that output the format (which corresponds to what you cite).
Think about it: how would you expect that the Alignment API knows the results of your SPARQL query? If you come up with a nice solution, contact the API developers, they may integrate it and others could benefit.
Second question: I cannot do better than what is above.
Third question: too general. Read the OAEI results (http://oaei.ontologymatching.org) and look at the code of others.
Good luck!
Suppose I am to search against two types [cars] and [buildings], and I would want the results to be separated. Is there a way one can group results by types?
I understand one simple way will be to query each types separately, but for other use cases one may actually need to query tens or hundreds of types together. Is there a native way or hacky way(like using sort) to achieve this?
This type of grouping behavior is (currently) not available in elasticsearch. It has been a long standing request:
https://github.com/elasticsearch/elasticsearch/issues/256
There are two approaches that can help, both of which are far from perfect, but may be good enough for some use cases.
Client side aggregation. Request a lot more results than you plan on displaying and the then bucket those.
Using multi-query. This allows you to easily pass down some number of queries in a single batch, but will have potential scaling problems if the number of queries gets to large.
This is one feature that Solr has that elasticsearch doesn't, but I have never tried it. I used a similar feature with Autonomy IDOL years back, but the performance was abysmal.
If you want the results separated in groups of documents, you're going to have to restructure your documents, since, elasticsearch is focused on finding matching documents. You might get around this by designing a document that has child documents then you can query for matches on the parent document that represents your type.
I guess there might be some common field (let's say it's [price]) if you want to search against different types. Then it would be reasonable to add some different type like [price_aggregator] and put into it fields [type] and [price]. And then you could easily build your query against just one type. This requires some additional work while indexing and more memory to store index but it's much performant when you search.
Situation
I have a report which is to be export by customers to excel format when they please that must meet certain formatting criteria.
Problem
This report is a statutory return that must be returned in a specific format. I have decided this can be achieved with the use of pivots. Instead of a list view they require a grid of totals, like this
o...
This can be done manually by writing out lots and lots of pivots in a big complex statement, but would need to be updated as soon as the column I am pivoting on has a new entry, which will be frequent.
Perfect Solution
The perfect solution for this would be for somebody to find something magical that automatically pivots on all data in one column and does so programmatically, so if entry's are added to that column, they will also be pivoted on.
I am not looking for exact code here because that's lazy and I won't learn anything. A shove in the right direction would be nice though, if this is at all possible.
You can do this with dynamic SQL (Example in this answer). Although this is frequently best achieved through an application/reporting layer rather than directly in SQL.
In your case you can embed reports in Windows Forms Applications, which gives the option of just viewing the report, or exporting in a number of formats. If the pivot needs to be done in SQL then dynamic sql is the only way to do it.