To build queries in the Attributed Model, you have to understand a few Database concepts.
Tables are used to hold Objects and to express relationships between Objects. A table is essentially a row-column view of arbitrary data, like the Result Set or Result Views.
Tables consist of Columns which contain the attributes associated with the Objects represented by the Table. Columns contain typed data, such as Strings, Integers, Longs, IpAddresses, or binary data. The Query Forms allow selection of the columns to display in the result set, and the ability to match values in one or more columns to select one or more rows from the Table.
Tables contain key values that allow you to find a particular record. There are two types of keys:
-
Absolute
-
Relative
Absolute keys identify a single row (record) within a table; therefore an absolute key has a unique value for each row within the table.
Relative keys identify a unique value but only in the context of an Object containing the objects in the table. For example, InterfaceName is a relative key, because in the context of a single Device, there can be only one Interface with a given name. The Attributed Model uses several different types of keys. “Attributes common to many tables in the data model” on page 64 provides information on the various types of keys used.
One table (or set of Objects) may have an attribute that is the key of another table within it. For example, a table of Interfaces may have as a column that is the key of the Device entry that contains the interface. In database terminology this is called a foreign key reference. Foreign key references allow tables to be joined together, meaning, to find all the entries in table B that correspond to a particular entry in table A.
Joins can be understood by the following example of combining two tables, Table A, and Table B.
A.Key |
A.Field1 |
A.Field2 |
x |
xa1 |
xa2 |
y |
ya1 |
ya2 |
z |
za1 |
za2 |
B.Key |
B.Field3 |
B.Field4 |
p |
x |
pb4 |
q |
x |
qb4 |
r |
z |
rb4 |
In this example, Table A has three columns, A.Key, A.Field1, and A.Field2, and Table B has three columns, B.Key, B.Field3, and B.Field4. The field B.Field3 is a foreign key reference to Table A’s key (A.Key). The fields can then be joined so that each combination of A and B are combined where the B.Field3 foreign key reference in a Table B entry matches the A.Key key in a Table A entry. The result of the join is A Join Table B.
A.Key |
A.Field1 |
A.Field2 |
B.Key |
B.Field3 |
B.Field4 |
x |
xa1 |
xa2 |
p |
x |
pb4 |
x |
xa1 |
xa2 |
q |
x |
qb4 |
z |
za1 |
za2 |
r |
z |
rb4 |
The join creates a (temporary) single unified table containing fields from both Tables A and B where the record entries represent those that share the same A.Key and B.Field3 foreign key reference.
The Join result contains no entry for the A.Key of y; that is because there is no matching record in the B table with a B.Field3 of y. It is important to understand Joins so that you can visualize what will happen when you construct a query that contains two tables which are joined together.
In Network Configuration Manager, Queries can be built without referring specifically to the keys needed to join each of the tables. Instead, the Query references a Navigation by name; the Navigation specifies how two (or sometime more) tables are related, and what keys are used to join the two tables together. Navigations often express relationships, for example Device contains AccessList, which contains AclExtendedRule. Going in reverse order, AclExtendedRule is contained in AccessList which is contained in Device. There is also an implicit references relationship, such as InterfaceAccessList references AccessList.
The general process of creating a Query involves these steps:
Naming the Query, and filling in descriptions and general attributes on the Form’s General Tab.
Naming each of the tables used in the Query, and specifying how each of the succeeding tables is joined (related to) a previous table (usually by using a Navigation). This is accomplished on the Form’s Tables Tab.
Selecting the columns to be displayed (and the order of display) in the Form’s Columns Tab.
Adding any desired Selection Criteria to limit (or filter) the rows to be displayed. This is done with entries in the Form’s Selection Tab.
Defining Variables to be initialized from the Query Results after running the Query. This is done with the Form’s Variables Tab.
Preview the Query, and making any adjustments needed. This is a very interactive process.
Saving the Query.
You will need to know what tables are involved in creating the Query before you begin. If you are not sure of the tables to use or their relationships, use the MetaData browser to see the tables and the relationships that connect them, or refer to the earlier sections on the Data Model if you need more information.