The ER Diagram used in AOA is the traditional ER diagram that has been used in the IS industry for over two decades, where Attributes (ie., data elements) are grouped into normalized containers, called Entities. A typical example is the Person entity, which contains attributes such as LastName and DateOfBirth to define characteristics of a person. Actually, the ER Diagram in AOA is somewhat noted for what it doesn’t do: It doesn’t define subtypes. It doesn’t define objects or methods. Functions such as these that have been added as extensions to other ER Diagrams are addressed in the key AOA component, the LOD (or AOA Object). Instead, the ER Diagram restricts itself to the definition of persistent data, and some non-persistent, reusable data. In doing so, it avoids the problem of “overloading” an effective technique trying to make it do something for which it wasn’t intended.

A Relationship is defined between two entities by drawing a line between them to describe how the two groupings of attributes are related to each other, including their cardinality (such as 0-to-m, m-to-m, etc.). For example, the Student entity has a relationship “is student assistant for” with cardinality 0-to-1 to tie a particular Student entity to a particular Class entity. In a large ERP, some entities have dozens of relationships. In OpenCUAS, the Student entity is at the heart of much processing and has 69 Relationships to other entities, as well as 87 Attributes.

Relationships are transformed into foreign keys when the data from an ER Diagram is implemented using an SQL database, but foreign keys are never used in any logical specification in AOA. The automatic processing of foreign keys based on their tie to a relationship in the ER Diagram is one of the vehicles by which AOA keeps application definition at the logical level and removes much of the complexity of data access.

Each entity has an Identifier specified, which specifies which single or multiple attributes are necessary to uniquely designate an instance of that entity. Though, any number of attributes and/or relationships can be used to define an Identifier, it is recommended that an automatically assigned integer attribute be used, as it simplifies problems when unique attributes are modified and improves performance in most cases. Managing the unique identifiers is then the responsibility of the execution-time system, the AOA Object Engine.

The only innovation in the AOA ER Diagram is the specification of a Domain for each attribute (see examples above). Because the actual physical data is encapsulated from all rules and interfaces, the Domain definitions (defined earlier) enforce the data integrity rules at the element level and automate the formatting of data on human interfaces without additional specification.