Component Design for Relational Databases - High-Performance Web Databases: Design, Development, and Deployment - page 392

3. Again, depending on the application, a single class DA may provide
the functionality provided by DA1, DA2, and DA3.
4. Note that DM1 and DM2 provide the business view of the data model
and this case is basically driven by the choice of B1 and B2 as the
business classes. Depending on the requirements, classes DM1,
DM2, and DM3 could correspond to DA1, DA2, and DA3 or any other
combination that makes sense.
5. Note that classes DM1 and DM2 could create and return a variety of
object. For example, object O11 might correspond to a specific
record in the table T1. Object O12 might correspond to a collection of
records. Alternatively, O12 may be implemented as an object contain-
ing a collection of O11 objects. Similarly, objects O21 through O2N
might correspond to Table T2. Alternatively, O21 through O2N might
correspond to data linked between Tables T2 and T3 if appropriate.
The possibilities are endless. The examples listed previously illustrate
some of the considerations that might come into play during the design of
the component. To reiterate one of the main points in this article, effective
change management, assume that a change is to be made to this design.
Instead of accessing data in Table T2 and T3 directly, applications must use
a View instead. In this case, only relevant classes in the data access layer
and maybe the data mapping layer will need to be changed. All other classes
in the business and the interface layer of the component can remain
unchanged. Also, the client applications using the component remain unaf-
fected. Thus use of a multi-tiered component-based architecture has pro-
vided for flexibility (providing ease of change by restricting the area of
change) as well as robustness (limiting the scope of the effect of change).
DATA-COMPONENT MINING
Data-component mining is the process by which an existing data model
can be analyzed and broken up into sub data models with associated data-
components. One approach to component mining is to study the data model to
identify loosely coupled sets of entities. Each such set of entities can be called
a sub-data model. Each sub-data model is a good candidate for a component
and more so if the sub-data model is used by more than one application. Use
cases have become a standard way to defining requirements/functionality
in object-oriented design. A list of existing as well as future use cases can
also provide a valuable perspective during data-component mining design.
Related use cases can be combined to help identify sub-data models and
consequently corresponding data components.
For example, in a portfolio management system, analysis of the ERD
(entity relationship diagram) of the data model might suggest that the set of
entities containing historical performance data could constitute a sub-data
model M1. Similarly, the set of entities pertaining to investment choices in a