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.
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.
- The Entity set represents a collection of similar entities.
- The Entity is similar to a class in object-oriented languages.
- The attribute represents a property of (the entities of) an entity set.
- Attributes are simple values, such as integers or character strings. Attributes are not structs or sets.
- Entity set Beers has two attributes, name and manf (manufacturer).
- 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
- Bars sell some beers.
- Drinkers like some beers.
- Drinkers frequent some bars.
Relationship Set
- 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. - 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
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.
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
- process-specific logic and
- entity-specific logic,
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.
Entity Abstraction Pattern
In the context of an Entity-Relationship Diagram (ERD), the "Entity Abstraction Pattern" refers to a design strategy where common attributes, relationships, or behaviors are extracted from multiple entities and consolidated into a single, more abstract entity. This abstract entity then serves as a parent or superclass for the more specific entities, which inherit the properties and relationships defined in the abstract entity.
The purpose of the Entity Abstraction Pattern is to reduce redundancy, improve maintainability, and promote reusability within the data model. By abstracting shared characteristics into a separate entity, changes to these characteristics can be made in a single location, rather than having to update each individual entity that shares the same attributes.
For example, consider a university ERD with separate entities for students, faculty, and staff. These entities may share common attributes such as name, date of birth, and contact information. Using the Entity Abstraction Pattern, a new abstract entity called "Person" could be created, containing these shared attributes. The student, faculty, and staff entities would then inherit from the Person entity, reducing redundancy and simplifying the overall data model.
The purpose of the Entity Abstraction Pattern is to reduce redundancy, improve maintainability, and promote reusability within the data model. By abstracting shared characteristics into a separate entity, changes to these characteristics can be made in a single location, rather than having to update each individual entity that shares the same attributes.
For example, consider a university ERD with separate entities for students, faculty, and staff. These entities may share common attributes such as name, date of birth, and contact information. Using the Entity Abstraction Pattern, a new abstract entity called "Person" could be created, containing these shared attributes. The student, faculty, and staff entities would then inherit from the Person entity, reducing redundancy and simplifying the overall data model.
[1]tuples: In the lexicon of relational database design another word for rows or records.
[2]:
