Java Reference
In-Depth Information
Web
Application
Third-Party
Interface
Integration
Database
Web
Application
Third-Party
Interface
batch
Transactional
Database
Web
Service
Reporting
Tool
batch
Web
Service
Reporting
Tool
Reporting
Database
Figure 1.5
An example of enterprise database architecture
In the example depicted by figure 1.5, the requirements have been separated in
terms of horizontal and nonfunctional requirements. That is, the databases have
been separated into integration concerns, online transactional concerns, and
reporting concerns. Both the integration database and the reporting database
interface with the transactional system via a batch load, which implies that for this
system it is acceptable to have reports that are not exactly up-to-date and that the
transactional database only requires periodic updates from third-party systems.
The advantage is that the transactional system has a great deal of load lifted from
it and can have a simpler design as well. Generally it is not practical to design a
database that is efficient for integration, transactions, and reporting. There are
patterns for each that ensures the best performance and design. However, it is
sometimes a requirement to have near real-time integration and reporting func-
tions. For that reason this kind of design may not work. You might instead find
that your enterprise database has to be partitioned vertically by business function.
Regardless of your enterprise database design, it's easy to appreciate the differ-
ence between an application database and an enterprise database. It's important
to understand the particular limitations of your environment to ensure that your
application uses the database effectively and is a good neighbor to other applica-
tions that are using the same database.
