Although all processing of data within AOA is done at the logical level, that logical data has to eventually be read and written from/to a physical database. The Technical Environment (TE) is the vehicle that defines one or more physical database environments against the logical definition of data, the ER. The TE can define more than one database, allowing an application to be generated to run against different types of databases at different installations or to run against multiple databases simultaneously at a single installation. An example of the OpenCUAS TE definition for SQL Server is shown to the right, listing the tables, which were generated from the ER.

Components of a TE are mostly tables and fields which are defined relative to the entities and attributes of the ER Diagram. One table exists for each entity, and also for each m-to-m relationship. A field exists for each attribute and also for each foreign key necessary to implement a relationship. (Note the foreign keys in the example to the right.) Typically, a TE is generated automatically from an ER Diagram and is largely ignored by the developer. However, it is valid to change the generated physical characteristics as long as that change doesn’t create an incompatibility with the ER. It should be noted that the TE for the OpenCUAS application, in spite of its size and complexity, is completely generated from the ER.

An important function of the TE is to generate DDL that is run against the SQL database to create or update tables and columns. After changes have been made to the ER, the function, “Build/Rebuild Tables/Rels” is run to generate those changes into the TE. Then the function, “Build Sync DDL” is run to generate the DDL necessary to carry those changes to the database. This allows the developer to focus only on the logical characteristics of the data and to automate the transformation of those logical characteristics into the physical environment.