ER Diagrams   «Prev 

Entity Patterns

As you gain experience in designing databases, you will start to notice little patterns that emerge. For example, the "many" side of a one-to-many relationship tends to be an optional entity much of the time. But much does NOT mean always, so do not get carried away and just ASSUME it is optional all the time.
The interesting aspect about noticing patterns is that, when you find examples that break the pattern, they catch your eye. Always look into things that seem a bit atypical. A lot of mistakes are discovered in just this way.
Think of the Entity as an object.
  1. The Entity set represents a collection of similar entities.
  2. The Entity is similar to a class in object-oriented languages.
  3. The attribute represents a property of (the entities of) an entity set.
  4. Attributes are simple values, such as integers or character strings. Attributes are not structs or sets.

  1. Entity set Beers has two attributes, name and manf (manufacturer).
  2. Each Beers entity has values for these two attributes, for example (Bud, Anheuser-Busch)


ERD Relationship

A relationship connects two or more entity sets. It is represented by a diamond, with lines to each of the entity sets involved
  1. Bars sell some beers.
  2. Drinkers like some beers.
  3. Drinkers frequent some bars.

Relationship Set

  1. The current value of an entity set is the set of entities that belong to it.
    Example: The set of all bars in our database.
  2. The value of a relationship is a relationship set, a set of tuples[1] with one component for each related entity set.

Entity Abstraction

Entity Abstraction is a design pattern, applied within the design paradigm which provides guidelines for designing reusable services whose functional contexts are based on business entities.
The automation of a business process involves the analysis of the business domain and then designing solution logic that represents the different steps within the business process. Some of these steps relate just to that specific business process while others may be of use to other business processes as well. Part of this reusable logic pertains to the business entities that usually remains the same when compared to the rules and processing steps that may change in future. If services are designed that contain both
  1. process-specific logic and
  2. entity-specific logic,
the chances of reusing the same entity-specific logic, from another business process, become somewhat negligible.
If this kind of logic is split up into a separate container, then any new business processes, which make use of the same business entity, can reuse this logic. Apart from the reusability problem, in order to address the change in the behavior of a business entity, updating the entrenched entity related logic across multiple business processes requires extra efforts and makes the maintenance of such services a complex task.
The Entity Abstraction pattern advocates that logic that relates to the processing of business entities be separated from the process-specific single purpose logic and designed as independent logic, which has no knowledge of the overall business process in which such logic is being utilized.
[1]tuples: In the lexicon of relational database design another word for rows or records.