Introduction

Logical entities represent "things" consumed or produced by logical activities. It represents something of value to the system under study, therefore the entity object is likely persistent. They are also a representation of real-world objects within the system, customer for example, and as such they will have relationships with many other entities within the system. 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 and should be defined external to entities and workflow—they are separate objects themselves.

At the logical level IT concepts such as storage appear, but since we are at the logical level the specifics of tables and primary keys and other implementation details are not necessarily included in the model. Candidate keys and other logical level details may be defined. 

What is a Logical Data Model

• Graphical representation of the business requirements
• Contains the things of importance in an organization and how they relate to one another
• Contains business textual definitions and examples
• Validated and approved by a business representative
• Basis of physical database design

This is sometimes incorrectly called a "physical data model", which is not what the ANSI people had in mind. 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 model, or technology model in the enterprise architecture context.

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.

Why Build Logical Data Model

• Helps common understanding of business requirements
• Provides foundation for designing a database
• Facilitates data re-use and sharing
• Decreases development and maintenance time and cost
• Confirms a logical process model and helps impact analysis.

Logical Modeling Benefits

• Clarifies functional specifications and avoids assumption
• Confirms business requirements
• Facilitates business process improvement
• Focus on requirements independent of technology
• Decreases system development time and cost
• Becomes a template for the enterprise
• Facilitates data re-use and sharing
• Faster ROI
• Gathers metadata
• Foster seamless communication between applications
• Focuses communication for data analysis and project team members

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 Logical Entity

• Its name and description are clear and understandable.
• Logical 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.