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.
Entity Abstraction is a design pattern, applied within the service-orientation 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 process-specific logic and 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.
In response to the aforementioned issues, 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 that has no knowledge of the overall business process in which such logic is being utilized.