Even though Network Configuration Manager offers a great number of pre-defined queries, the real power of the Attributed Model (AM) is in the ability of users to formulate their own customized queries.
Queries are defined by completing various tabs within the Query Form . Query Forms are now used to create Policies, Standards, and Tests.
To create or build your own query, some database concepts must first be understood.
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 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 AM uses four types of Absolute Keys:
-
OIDs - (stands for Object IDentifier). OIDs are generated by Network Configuration Manager, and are used in almost all of the existing tables. These are 32-byte binary values. OID keys are almost always named "XXXOid" where XXX is the name of the Object class.
-
IDs (or Long identifiers) - Long Identifiers were introduced as part of the AM. The Long identifiers are a Long integer, generated by the database itself when the record containing the key is first written to the database. Long ID keys are usually named "XXXId" where XXX is the name of the Object class.
-
Device IDX keys - These are integer keys, provided by Device Services, that uniquely identify a device. Device IDX values are used in logs generated by Device Services. This key is named "DeviceIdx".
-
RDN – which is an acronym for Relatively Distinguished Name. This is a relative key, used within Device Services to distinguish one attribute from another in the AM. RDN keys are not used by the Application Server. RDNs can be viewed to aid debugging.
You do not normally have to be concerned with keys, other than to recognize them. Most queries make keys initially not visible. It is possible, however, to construct queries based on a specific key.
Keys are often used to relate entries in one table to another. For example, AclExtendedRule contains a relative key, the RuleNumber, and a reference to the absolute key of the AccessList that contains it (which is AccessListId). The AccessList entries in turn, contain DeviceId keys, which identify the Device they belong to.
Queries can be built without referring specifically to the keys needed to relate tables. Instead, the Query references the Navigation by name, which specifies how two (or often more) tables are related.
These are the same Navigations as shown in Introducing the Data Model .
Navigations often express relationships, for example the Device query 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.
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, or the ability to match values in one or more columns, to select one or more rows from the table.