Hitachi Vantara Pentaho Community Wiki
Child pages
  • 05. Creating Relationships Between Business Tables
Skip to end of metadata
Go to start of metadata

Once you have all of your business tables created, you will need to create relationships between the tables, so that the query generators and SQL generators that work with Pentaho metadata can create the data queries correctly.

This is very much like drawing a relational diagram to show primary and foreign key relationships. Although relational links are not the only relationships that can be modeled. You can create a relationship between any two tables, link any two columns between them and dictate what the relationship is (one to many, many to many , etc.).

So the important pieces of information to know before you try to create a relationship is:

  1. what two business tables would you like to associate with this relationship,
  2. what columns in the business tables identify the relationship,
  3. and what kind of relationship is it - one to one, one to many, many to one, etc.

Tree Navigator: Creating a New Relationship

To create a new relationship between business tables using the Tree Navigator, first make sure that the model you want to add this relationship to is selected, and the Relationships node is visible (lives under the business model name node).

  1. Right-click (or ALT-click) on the Relationships branch in the Navigator Tree.
  2. Select the New Relationship... option from the popup menu.
  3. The *Relationship Properties" dialog displays.

  4. Select from the From Table / Field list the business table that you would like to start the relationship from.
  5. Select from the To Table / Field list the business table that you would like the relationship to go to.
  6. You must also specify the business columns (from the adjacent lists) from each business table that identify this relationship. An alternative, if the business column names are similar, is to click the Guess Matching Fields button, and let the dialog attempt to determine the columns for you.
  7. Next step, define the relationship from the Relationship drop down list.
  8. If the relationship requires a complex join, select the complex join checkbox, and enter your SQL in the text box provided.
  9. Click OK to close the dialog.
  10. You should see a new relationship line drawn between the two tables on the Editor Graph, and the relationship represented in the tree.

    A Special Note on Complex Joins

    Note that complex joins appear in the WHERE clause of the SQL statement, so currently any joining that takes place in the FROM clause of the SQL statement is not supported.  An example of a complex join might be TABLE_A.COL_A=TABLE_B.COL_A AND TABLE_A.COL_B=TABLE_B.COL_B.  This represents a join of two tables based on two key columns vs. a single join column.
    Also note, the complex join expression provided must utilize the names of the physical tables and physical columns, not business tables and business column names.

Editor Graph: Creating a New Relationship

In the Editor Graph, creating a new relationship is simplified a bit, because you select the two business tables on the canvas, and the Relationship Properties dialog is pre-populated with your selections.

To begin, make sure that the model you want to add this relationship to is selected, and the business tables are displayed in the Editor Graph.

  1. Select the two business tables you want to include in the new relationship, either by click and dragging a marquee around the tables, or by holding the SHIFT+CTRL keys, then clicking on the tables.
  2. Once your business tables are selected in the Graph, right-click (or CTRL-click) on the selection. Click the New Relationship... option from the popup menu.
    Follow the instructions from step 4 above to fill in the relationship properties. Note that when the Relationship Properties dialog displays, the To and From tables are selected for you.



Relationship Definitions

The relationships that can be chosen are defined with examples: 

Link: A 0:0 optional relationship basically states that a person can occupy one parking space, that I don't need a person to have a space and I don't need a space to have a person.
SubType: A 1:0 relationship; optional only on one side. This would indicate that a person might be a programmer, but a programmer must be a person. It is assumed that the mandatory side of the relationship is the dominant.
Physical Segment: A 1:1 mandatory relationship and demonstrates a segmentation denormalization. A person must have one and only one DNA pattern and that pattern must apply to one and only one person.
Possession: A 0:N (zero to many) optional relationship indicating that a person might have no phone, one phone or lots of phones, and that a phone might be un-owned, but can only be owned by a maximum of one person.
Child: A 1:N mandatory relationship, the most common one seen in databases. A person might be a member or might not, but could be found multiple times (if the member entity represents membership in multiple clubs, for instance).
Characteristic: A 0:N relationship that is mandatory on the many side. It indicates that a person must have at least one name, but possibly many names, and that a name might be assigned to a person (might not) but at most to one person.
Paradox: A 1:N relationship mandatory on both sides. The "Chicken and the Egg" is involved since you have to have a person to have citizenship, but citizenship to have a person.
Association: A N:N (many to many) optional relationship. Conceptually, it means that a person might or might not work for an employer, but could certainly moonlight for multiple companies. An employer might have no employees, but could have any number of them. Again, not hard to visualize, but hard to implement. Most solutions of this situation involve creating a third "Associative Entity" to resolve the M:M into two 0:M relationships. This might be an entity called employee because it does link the person to the employer the person works for.

  • No labels


  1. user-c7db9

    Is it possible to do an outer join? If so how? The relationship dropdown does not seem to affect the sql. And the complex join seems to only be in the where clause so I guess the "(plus)" syntax would work on databases that understand it.

  2. user-dc351

    bpair, outer joins will be added in the next release.

  3. user-0d127

    Hi, I'm in the process of doing some proof of concept work with Pentaho and I'm finding this site a little confusing.  Given that I have two questions...

    1) When is the next release coming out that will support outer joins (maybe this is obviously documented somewhere but I haven't found it)?

    2) Sorry not related to the PME but is there a central posting forum for each of the Pentaho applications that contains all help related posts?


  4. user-66a10

    platform version 1.7 GA PCI windows 


    I´ve done some tests with the complex join.

    Using the names of the physical tables (as the names are defined in the database) seams to work. But the are errors (parser) in the console.

    So I mailed with Matt. He told me to use the table and colums like they are defined in the busines view and also to use square brackets. Here is the result when I joined the orderfacts und the orderdetails tables out of the pentaho samples.




     With this clause I have got a result in adhoc-reporting without any parser- and other errors in the console.

    have fun