Joins are an advanced feature of RIB. If your data model is properly configured, joins allow users to query the repository data in a special way. A class which is the intersection of two other classes can be displayed in a matrix.
For example, say there are three classes in your repository : Asset, Machine, and Deployment. Now suppose that the data model was set up in such a way that the Deployment class had a relationship to the Asset class called IsDeploymentOf and to the Machine class called IsDeployedOn . Here, the Deployment class serves as the intersection class because it has relationships to each of the other two classes. The arrangement is illustrated below:
Next an Asset object called "Software A" and a Machine object called "Machine X" are created. Software A is installed on Machine X, and then a Deployment object is created which contains relationships to the Asset and Machine objects just created. Say that the Machine class also has an attribute called Status which is given the value "Successful".
You could then go to the join creation page and enter the parameters for the join (which are described above). When the join is created, it will appear in the matrix as follows:
Machine X | |
Asset A | Successful |
Creating more Asset, Deployment, and Machine objects could make the matrix look as follows.
Machine X | Machine Y | Machine Z | |
Asset A | Successful | Incomplete | Aborted |
Asset B | Successful | Successful | Incomplete |
The join feature can be disabled under the Manage Catalog tab. If it is, the repository templates should also be edited to remove the reference to the join creation page. See the help documentation on Manage Catalog / Templates for information on editing templates.
If the join feature is enabled, consider replacing the default url in the template with a join that has already been constructed. Repository users might find the construction interface a little overwhelming, especially since they probably won't know the data model. To replace the default url, construct the desired join and paste the final URL from the browser into the template. If the object approval feature is enabled for the repository, objects that have not been approved will not appear in joins.
Join with interoperation
You can choose to include interoperation objects in the join result once you have created interoperations with other repositories. If you choose this option, the interoperation objects of the selected class will be displayed in the final matrix in the same manner as other local objects. This process involves contacting remote repositories to get necessary information, so it might be slow sometimes. But it is powerful if you use it properly.
Join condition refinement
If the related class (Machine/Asset in the above example) has vocabulary controlled field(s), you can refine the Join condition by specifying preferred values for these field(s). By doing so, only objects (Machines/Assets) that contain one or more of the selected values in the specified field(s) will show up in the column/row headings of the final Join matrix. For example, instead of displaying the deployment status of all possible assets on all possible machines, you can let the Join matrix only display the deployment status of assets that are "Performance Analysis Tools" on machines that are manufactured by "IBM".