Topic
  • 3 replies
  • Latest Post - ‏2013-03-13T16:30:25Z by Jogden
Jogden
Jogden
6 Posts

Pinned topic Modifying USRPROP to allow Database Relationships

‏2013-03-12T18:14:33Z |
I'm looking for some assistance with a USRPROP. I'm attempting to relate the DEFINITION "ORACLE View" to its source Table. I'm using the following USRPROP:


DEFINITION 
"ORACLE View" 
{ PROPERTY 
"Uses Tables" 
{ ZOOMABLE EDIT ListOf 
"Table" RELATE BY 
"uses" 
} 
}


The problem I keep running into, is whenever I select the appropriate table from the CHOICES list, it creates a brand new table definition -- nearly identifical to the one I was attempting to reference.

Is there something wrong in my syntax or something else I need to use so to simply relate one definition to another, instead of it creating a new definition?

Your help is greatly appreciated!
Updated on 2013-03-13T16:30:25Z at 2013-03-13T16:30:25Z by Jogden
  • SystemAdmin
    SystemAdmin
    1061 Posts

    Re: Modifying USRPROP to allow Database Relationships

    ‏2013-03-12T18:22:35Z  
    "Table" is a multi-keyed definition. I recall there are seven keying properties.

    Therefore, when Table is part of a reference property, you need to include the KEYED BY {key1, key2, key3, ... } statement, where the keying properties are delimited by commas. Where a keying property is itself a referenced definition (such as Database), you will need to use the QUALIFIABLE keyword.

    I know this is not a complete answer, but it's all I have time for now!

    Scott
  • Jogden
    Jogden
    6 Posts

    Re: Modifying USRPROP to allow Database Relationships

    ‏2013-03-12T18:36:54Z  
    "Table" is a multi-keyed definition. I recall there are seven keying properties.

    Therefore, when Table is part of a reference property, you need to include the KEYED BY {key1, key2, key3, ... } statement, where the keying properties are delimited by commas. Where a keying property is itself a referenced definition (such as Database), you will need to use the QUALIFIABLE keyword.

    I know this is not a complete answer, but it's all I have time for now!

    Scott
    Thank you for the quick response. If I understand this correct, the format for a table is typically something like this:

    
    
    "Physical Data Model".
    "Physical Database".
    "SV-11 Physical Data Model".Table.
    "Owner Name"
    


    I count that as five keys. Maybe I'm missing a few, but I'm unsure. So if I follow your logic my USRPROP should be revised something like this:

    
    DEFINITION 
    "ORACLE View" 
    { PROPERTY 
    "Uses Tables" 
    { ZOOMABLE EDIT ListOf 
    "Table" KEYED BY 
    {
    "Physical Data Model", 
    "Physical Database", 
    "SV-11 Physical Data Model", Table:*, 
    "Owner Name") RELATE BY 
    "uses" 
    } 
    }
    


    Does that look right?
  • Jogden
    Jogden
    6 Posts

    Re: Modifying USRPROP to allow Database Relationships

    ‏2013-03-13T16:30:25Z  
    • Jogden
    • ‏2013-03-12T18:36:54Z
    Thank you for the quick response. If I understand this correct, the format for a table is typically something like this:

    <pre class="jive-pre"> "Physical Data Model". "Physical Database". "SV-11 Physical Data Model".Table. "Owner Name" </pre>

    I count that as five keys. Maybe I'm missing a few, but I'm unsure. So if I follow your logic my USRPROP should be revised something like this:

    <pre class="jive-pre"> DEFINITION "ORACLE View" { PROPERTY "Uses Tables" { ZOOMABLE EDIT ListOf "Table" KEYED BY { "Physical Data Model", "Physical Database", "SV-11 Physical Data Model", Table:*, "Owner Name") RELATE BY "uses" } } </pre>

    Does that look right?
    For those who care to know, here's the solution:

    
    PROPERTY 
    "Uses Tables" 
    { ZOOMABLE EDIT ListOf 
    "Table" KEYED BY 
    {
    "Model" QUALIFIABLE, 
    "Source Diagram Name" QUALIFIABLE, 
    "DBMS" QUALIFIABLE, 
    "Database Name" QUALIFIABLE, 
    "Owner Name" QUALIFIABLE, 
    "Name"
    } RELATE BY 
    "originated from" HELP 
    "Select the tables used by this view" 
    }
    


    Thanks to a fellow EA over on the LinkedIN IBM Rational System Architect group for the solution!