I'm trying to create a DataSource in Pentaho, but I cant define a join by two or more columns.
For example: my invoice table has the PK defined as [ClientId,InvoiceId] so diferent Clients can have the same InvoiceId. So the join with the table InvoiceProduct should be based by those two columns.
Yet Pentaho only allows me to select only one column from each table to define the join.
This is the official documentation from Pentaho: Create Database Sources. On #9 it talks about Join Definition, but never mentions PKs that have more than one column (which IMHO is quite common), so probably I'm doing something wrong.
Can anyone please point me out on how to define a join that involves more than one column?
Hope I made myself clear.
Best regards,
Federico.
Pentaho 8
Mysql 5.6
Windows 10
I have not tried with two keys, but it is not working you can generate a checksum value using checksum step and then use it while joining.
Hi there I'm knew to SQL and I'm facing what I hope is a basic problem.
Scenario: Say I have 2 tables, let these be Client and Reading. I want to find the table k which holds a relationship to both of them, so that I may perform an inner join to link Client to Reading.
Question: Does a query exist to find table k?
p.s.Client and Reading have many attributes which makes finding a relationship by hand very tedious.
If the tables have foreign keys, then yes you can query the meta tables to find the tables that have relationships to them.
If not, then no, there is no way to find them programmatically.
Is there a way to reference a table by id. Essentially, the table contains rows which pertain to one of many tables.
e.g. I need to reference tables A or B or C in table D's rows so that I know which table to join on.
I assume that if there is no shorthand way to reference a table externally then the only option is to store the table's name.
There is a "shorthand reference" for a table: the object identifier - the OID of the catalog table pg_class. Simple way to get it:
SELECT 'schema_name.tbl_name'::regclass
However, do not persist this in your user tables. OIDs of system tables are not stable across dump / restore cycles.
Also, plain SQL statements do not allow to parameterize table names. So you'll have to jump through hoops to use your idea in queries. Either dynamic SQL or multiple LEFT JOINs with CASE statements ... potentially expensive.
I'm trying to create a relationship between two tables in powerpivot. However, my tables don't have any keys. What I would like to do is create a SQL-Unique-Constraint-like relationship, which is based upon multiple values combined, being the key.
For example:
Table1 columns are First, Last, Address, Phone
Table2 columns are the same.
I want to create a relationship in excel that is the equivalent of
select * from Table1 full join Table2 on 1.Fist=2.First and 1.Last=2.Last and 1.Address=2.Address
However, the create relationship dialogue doesn't allow multiple columns to selected. I tried going the route of just creating multiple 1-column relationships. However, relationships also cannot include columns were there are duplicate values in the column.
I have a feeling I may just be approaching accomplishing this from the wrong direction. Any help is appreciated! Thank you.
Zee,
You are right that PowerPivot does not natively support multi-column relationships. There are however 2 work arounds:
Add a key to each table of the respective columns concatenated together and providing this is unique in at least one the relationship can be created. If you have a situation where neither table has unique keys then an intermediate table of unique keys could be created using SQL.
Technically multiple relationships can be created between tables but only one can be active. There is a DAX function called USERELATIONSHIP() which can use inactive relationships. This is an advanced technique.
Your solution may well be to combine the two tables in your source SQL query.
Jacob
If all you want to do is inner join using 2 or more columns, please consider creating a calculated column that concatenates the 2 or 3 columns in each of the 2 tables and then create a relationship between them.
I have had similar cases and used this technique.
I need to explain to somebody how they can determine what fields from multiple tables/views they should join on. Any suggestions? I know how to do it but am having difficulty trying to explain it.
One of the issues they have is they will take two fields from two tables that are the same (zip code) and join on those, when in reality they should be joining on ID columns. When they choose the wrong column to join on it increases records they receive in return.
Should I work in PK and FK somewhere?
While it is indeed typical to join a PK to an FK any conversation about JOIN clauses that only revolve around PK's and FK's is fairly limited
For example I had this FROM clause in a recent SQL answer I gave
FROM
YourTable firstNames
LEFT JOIN YourTable lastNames
ON firstnames.Name = lastNames.Name
AND lastNames.NameType =2
and firstnames.FrequencyPercent < lastNames.FrequencyPercent
The table referenced on each side of the table is the same table (a self join) and it includes three condidtions one of which is an inequality. Furthermore there would never be an FK here because its looking to join on a field, that is by design, not a Candidate Key.
Also you don't have even have to join one table to another. You can join inline queries to each other which of course can't possibly have a Key.
So in order to properly understand JOIN you just need to understand that it combines the records from two relations (tables, views, inline queries) where some conditions evaluate to true. This means you need to understand boolean logic and the database and the data in the database.
If your user is having a problem with a specific JOIN ask them to SELECT some rows from one table and also the other and then ask them under what conditions would you want to combine the rows.
You don't need to talk in terms of a primary key of a table but you should point to it and explain that it uniquely identifies a given row and that you must join to related tables using it or you could get duplicated results.
Give them examples of joining with it and joining without it.
An ER diagram showing all of the tables they use and their key relationships would help ensure that they always use the correct keys.
It sounds to me like neither you, nor the person you are trying to help understands how this particular database is constructed and perhaps don't really even understand basic database fundamentals, like PK's and FK's. Most often a PK from one table is joined to a FK to another table.
Assuming the database has the proper PK's and FK's in place, it would probably help a great deal to generate an ER diagram. That would make the joining concept much easier to grasp.
Another approach you could take is to find someone who does understand these things and create some views for this person to use. This way he doesn't need to understand how to join the tables together.
A user shouldn't typically be doing joins. A user should have an interface that lets them get the data that they need in the way that they need it. If you don't have the developer resources to do that then you're going to be stuck with this problem of having to teach a user technical details. You also need to be very careful about what kind of damage the user can do. Do they have update rights on the data? I hope they don't accidentally do a DELETE FROM Table with no WHERE clause. Even if you restrict their permissions, a poorly written query can crush the database server or block resources causing problems for other users (and more work for you).
If you have no choice, then I think that you need to certainly teach them about primary and foreign keys, even if you don't call them that. Point out that the id on your table (or whatever your PK is) identifies a row. Then explain how the id appears in other tables to show the relationship. For example, "See, in the address table we have a person_id which tells us who that address belongs to."
After that, expect to spend a large portion of your time with that user as they make mistakes or come up with other things that they want to get from the database, but which they can't figure out how to get.
From theory, and ideally, you should define primary keys on all tables, and join tables using a primary key to the matching field or fields (foreign key) in the other table.
Even if you don't define or if they're not defined as primary keys, you need to make sure the fields uniquely identify the records in the table, and that they should be properly indexed.
For example, let's say the 'person' table has a SSN and a driver's license field. The SSN could be considered and flagged as the 'primary key', but if you join that table to a 'drivers' table which might not have the SSN, but does have the driver's license #, you could join them by the driver's license field (even if it's not flagged as primary key), but you need to make sure that the field is properly indexed in both tables.
...explain to somebody how they can determine what fields from multiple tables/views they should join on.
Simply put, look for the columns with values that match between the tables/views. Preferably, match exactly but some massaging might be necessary.
The existence of foreign key constraints would help to know what matches to what, but the constraint might not be directly to the table/view that is to be joined.
The existence of a primary key doesn't mean it is the criteria that is necessary for the query, so I would overlook this detail (depending on the audience).
I would recommend attacking the desired result set by starting with the columns desired, and working back from there. If there's more than one table's columns in the result set, focus on the table whose columns should be returning distinct results first and then gradually add joins, checking the result set between each JOIN addition to confirm the results are still the same. Otherwise, need to review the JOIN or if a JOIN is actually necessary vs IN or EXISTS.
I did this when I first started out, it comes from thinking of joins as just linking tables together, so I linked at all possible points.
Once you think of joins as a way to combine AND filter the data it becomes easier to understand them.
Writing out your request as a sentence is helpful too, "I want to see all the times Table A interacted with Table B". Then build a query from that using only the ID, noting that if you wanted to know "All the times Table A was in the same zip code as Table B" then you would join by zip code.