- As noted earlier, a key objective of AOA is to maintain application focus on the logical structure of data and to avoid thinking about that data through any other structure, such as the SQL, relational model. It thus follows that the current industry query solutions are not architecturally compatible with AOA and work against that principle. It should also seem likely that, since AOA introduces a logical data structure to simplify the analysis and implementation of data, that same structure would be applicable to querying data. That is exactly the reality, as the AOA structure is the foundation of AOA query and is used to address two prominent query issues.
Query Issue 1: Understanding Data – As noted earlier, the LOD structure of data is used to analyze and document data by providing a visual, logical structure of that “data in context.” But, this is exactly the requirement for the first stage in solving any query problem: understanding that data from an end-user perspective. Actually, a clear understanding of how persistent data is structured and related to the business problem is the biggest obstacle to any but the simplest queries. The use of the LOD as the foundation of AOA queries resolves this problem in AOA. Though there are multiple levels of query, as explained below, defining data structures through the LOD provides the foundation for query at all levels.
Query Issue 2: Specifying the Query – Once a logical understanding of the data is gained, the next step is to enter the detail elements of a specific query. It is naturally desired that the interface for specifying these elements goes against the same logical structure used in gaining an understanding of the data. This is true in AOA, where the entity/attributes of a Query LOD are listed in a table and the user selects which elements are to be included in the output, and which elements and element values are to be used in selecting data from the database. Additional functionality can be provided by specifying Derived Attributes and Derived Entities, as can be done for any LOD within an application.
To the right are three diagrams presenting three steps in the specification and execution of a query:
1. An example of a Student query LOD.
2. An example of a query against that same LOD.
3. An example of the interface for displaying and processing 
the result set returned from the execution of a query for a Class LOD. Note that several options exist for the use of that result set, including 1) creating a contact list from selected entries in the list, 2) printing a report of all entries in the list and 3) saving the result set as an CSV or XML file.
Emphasizing logical structure is the most important technique used in AOA queries. However, a second technique is nearly as important, which is providing the ability to support query/report problems at multiple levels of complexity, flexibility security and user knowledge.
Every large organization has employees with a variety of needs and skills. At one end, there are those with 1) very little high-level understanding of system data, 2) limited authority to access that data, and 3) a need to access that data through only a handful of reports using pre-specified queries. At the other end, there are a very few who have the understanding, authority and need, along with the commensurate knowledge, to query and report on any data in the system and to create queries and reports to be run by those with limited understanding and authority. Then, there are, of course, the majority of users who fall somewhere in between those two extremes.
At the most complex end, an AOA user is given the ability to create any LOD against the logical database structure and to build any query against that LOD. That query can then be run by the user or used to format a report to be run by another user with more limited authority. Such ability is powerful, but it also exposes a great deal of sensitive data and needs to carefully controlled in any application. In OpenCUAS, such capability is limited to only those who have Systems Administration authority.
More commonly in OpenCUAS, different functional groups have ownership of a subset of the complete database and can build a query/report only against the subset defined for them. However, they also have the authority to build any report from the data they own and then give the authority to run that report to someone from a different group that would normally not have access to that data. In other words, any owner can allow selected users to see parts of data that would normally be off-limits to them.
At the simplest end, a user is given a list of reports that can be run with a single click of the mouse. The selection criteria and data to be presented to the user are completely
controlled by the person who created the query/report. At an intermediate level, the creator of a query/report can open some or all of the selection criteria to be modified by the user who runs it. In any case, the user running the report can format the output as an online report, a printed report, a CSV file going to Excel or an XML file to be exported to an external system. The user can also use the results of a query to create a “contact list” of entries (ex., students, prospects, classes, employees) that can be used to process those entries in other parts of the application.
The two diagrams above and to the right show the specification
and run-time interfaces of a report tied to a query. Note in the report specification that the person defining the report selects which selection criteria can be changed by the person running the report, as shown by the two entries that are checked. The second diagram shows the run interface with those two selection criteria items available for specification.