Core Concepts/Features

The EA Diagram Business Domain Entity Data Management 2012-02-19 diagram displays Core table structures of the Steady State Enterprise Architecture.

Model Independence: One Database, Many Models

This design abstracts object model entities in order to accommodate an unlimited number of domain object models in a single enterprise database.

Why Steady State?

Because no matter how many new classes you add to your UML Diagram or new Entities you identify that need to be “added” to the “database”, EASSEA DB never needs to add another table.  The Database Design is literally in a Steady State.


This diagram also displays a revolutionary design for capturing data history for each field in a database record. This is done by representing each property of a logical entity directly in a physical attribute table unencumbered by a Relational Table representation at the physical level. Furthermore, the “Attribute” entity serves as a logical place-holder for the Attribute’s data value(s) OVER TIME.  The AttrTimeInfo table is able to represent multiple time contexts and time types.

Attribute Abstraction

Thus the concept of the logical database column representing a static field in a database table’s records has been abolished allowing the Column to be represented as a first class entity in its own right whose data history can be independently tracked and managed making it possible to effortlessly view the entire history of a given Attribute (formerly known as a (Table Column) because the Attribute is merely an abstraction separate and distinct from its Value Representation over time and format.


Not only are attribute-values-over-time supported but this design also features the concept of Attribute Multivalency, that is, the ability to simultaneous represent more than one Value Type at a time. For example, notice that the entity, AttrVarChar, has a Foreign Key to AttrTimeInfo. Not shown in the diagram are all the other Attribute Value Type Entites (such as date, integer, memo, graphic, int, float, etc.). Thus an attribute ID can support a cluster of related value types at one time besides its own dedicated data type. This will not be useful in all cases but could be useful in specific case where a data value can be naturally expressed in more than one data format and type at a time.

Leave a Reply

Your email address will not be published. Required fields are marked *