Database Reference
In-Depth Information
•
Loss of business rules
. When we abstract, we can also lose business rules. To
be more specific, the rules we enforced on the data model before abstraction now
need to be enforced through other means such as through programming code. If
we wanted to enforce that an
Employee
must have a
Start Date
, for example
,
we
could no longer enforce this rule through our abstracted data model.
•
Additional development complexity
. Abstracting requires sophisticated develop-
ment techniques to turn attributes into values when loading an abstract structure,
or to turn values back into attributes when populating a structure from an abstract
source. Imagine the work to populate
Party Role
from the source
Employee
. It
would be much easier for a developer to load data from an entity called
Employee
into an entity called
Employee
. The code would be simpler, and it would be very
fast to load.
So, although abstraction provides flexibility to an application, it does come with a cost. It
makes the most sense to use abstraction when the modeler or analyst anticipates addition-
al
types
of something coming in the near future. For example, in our abstract data model,
additional types of people might become important in the future such as
Contractor
and
Consumer
. Roles such as
Contractor
and
Consumer
can be added gracefully without up-
dates to our model. Abstraction might also be used when there is an integration requirement
such as the requirement to recognize that
Bob
the employee is also
Bob
the student.
To minimize the cost of abstraction, some modelers prefer to wait until the physical re-
lational data model before abstracting. This way the logical data model still reflects the
business language, and then flexibility and integration can be performed in the application
through abstraction in the physical data model.
If we are building a MongoDB database, abstraction can be even less desirable because
MongoDB does not require us to define our physical schema in advance; therefore, we
lose the flexibility benefit of abstraction because MongoDB is already flexible by design.
Therefore, the only benefit of abstraction in a MongoDB world is when there is a require-
ment for integration and the abstract concepts such as
Party
serve as integration points in
our application.
STEP 3: DETERMINE THE MOST USEFUL FORM
Recall during conceptual data modeling how we needed to identify the validator (the person
or group responsible for ensuring our modeling results are correct) and the users (the per-
son or group who is going to use the data model). We need to perform the same activity at
