Introduction

Technical entities represent "things" consumed or produced by (technical) activities. It represents something of value to the enterprise, therefore the business entity object is likely persistent. They are also a representation of real-world objects within enterprise systems and processes, customer for example, and as such they will have relationships with many other entities within the enterprise. The attributes of the entities reflect their purpose and usage, but should not have attributes that define how and by whom it should be used. These are business rules, defined external to entities and workflow and are separate objects themselves.

At the technical level, implementation decisions are made, such as Oracle vs. Sybase, along with the specifics of tables and primary keys and other such details. Again, the level of detail specified depends upon the scope, context and objectives of the IT architecture effort.

This technical level involves the transformation of the logical data model into detailed and perhaps optimized physical database table designs, or other physical representations. The physical design of a database involves deep use of particular database management technology. For example, a table/column design could be implemented on a collection of computers, located in different parts of the world. That is the domain of the physical implementation project(s)—the technology model in the IT architecture context will likely not specify the solution to that level of detail..

Difference Between Logical & Physical Data Model

People often get confused with the fact that logical and physical data model is very different in their objective, goal and content. Following are some key differences.

Attributes

An attribute of a class represents a piece of information about an object of that class that is kept with the object. An attribute has an attribute type. Each attribute and attribute type, respectively, has a name.

An object normally holds different pieces of information that describe some of its characteristics. Such pieces of information can either be described implicitly in the textual description of the object's class or modeled explicitly as an attribute of the class.

An attribute is of a certain type. An attribute has a name, preferably a noun that describes the attribute's role in relation to the class. An attribute type can be more or less primitive, for example a simple number or string. Different classes can have attributes with identical structures. Those attributes should share a description; that is, they should share an attribute type.

Attributes vs. Entities

A key consideration in modeling the entities is always the question: entity or attribute? In other words, is the "thing" in question important and involved enough to be modeled as an entity, or should it simply be an attribute of another entity? As always when doing architectures the short answer is "it depends". It depends, in this case, upon how the "thing" is used within the enterprise. Is it simply a bit of information or are there other attributes about the thing that need to be understood and used?

If the phenomenon you wish to model is not used by any other class, you can model it as an attribute of an entity class, or even as a relationship between entity classes. On the other hand, if the phenomenon is used by any other class in the design model, or if there are attributes about the phenomenon required, then you must model it as a class.

Characteristics of a Good Technical Entity

• Its name and description are clear and understandable.
• Entity relationships do not depend on each other.
• Each relationship is used in the workflow of at least one activity.
• All "things" in the business, such as products, documents, contracts, and so on, are modeled as entities.
• It participates in at least one activity.

System Events

Events can be used to notify interested parties (including other entities or activities) of a change in state of the entity. The creation and destruction of an entity may be significant. If you have defined a state machine for an entity, examine the defined states. Each transition is a potential (business) event. Also inspect the attributes and operations of the entity. Significant operations that are used infrequently may have an event associated with them. Changes to important attributes may trigger an event. Process patterns and entity patterns may also provide insight into useful events. For example, if a business entity must be approved before being used further, a <something> Approved business event may be useful to notify other parties. For more information on finding events, see Guideline: Business Event.