If we are to avoid programming-level tasks, then it is mandatory that we somehow generate data access statements from the high-level, design structures that we’ve created during the design process. Within AOA, this means that we must be able to generate SQL statements from the combined structure of the LOD and its associated data in the Database Technical Environment definition (DTE).

Data access is triggered in AOA from an Activate statement against a particular LOD. The Activate also specifies parameters necessary to qualify the data returned for that request. The following is a small sample of such activates.

 

 

Returns all instances of that object (Classes) in the database.

 

Returns all instances (Classes) of that object in the database that are for a selected College Term in another object. Part of the generated SQL for the last statement is shown in the diagram to the right. Note that the first SQL statement is for the root of the object (CLASS) and other entities that are in a 1-to-1 relationship with it. The next several SQL statements are for subobjects with a 0-to-m relationship with the root.

 

 

 

Returns the academic data for a student, but restricts the enrollment data to a single college term as specified in another object. Part of the generated SQL for the last statement is shown in the diagram to the right. Note that the SQL performs joins as necessary to optimize performance.

There are, of course, other development tools that generate SQL. The critical AOA difference is that the generated SQL is never saved or modified. It is always dynamically generated at run-time based from the content of the LOD and related DTE. Thus, any modification to the logical data definition or physical environment will automatically cause a modification in the generated SQL. This allows all data access to be completely defined and maintained at the logical level.