Databases Reference
In-Depth Information
mapping, testing, and parallel activities. It is expected that the details
of this are included in the full lifecycle methodology.
•
Complete Testing:
Testing a database usually is done in the context of
applications and is covered in the full lifecycle methodology. Some
specific types of testing, such as stress testing, benchmarking, and re-
gression testing, can be used to refine the performance of the physical
data model. These require high volumes of data, testing tools, and dis-
tribution tools.
DELIVERABLES
Some of the important deliverables that are created from inception to
the creation of a physical database are discussed in this section. It is useful
to build a reference database that contains samples of each of these deliv-
erables so that project teams know in advance what they are attempting to
build.
•
This is the statement of the business require-
ments for the application being developed. This deliverable can con-
tain narrative and any number of models or prototypes to capture and
represent the business requirements.
Requirements Document:
•
Conceptual Model/Subject Areas:
This is a high-level view of the busi-
ness subject areas that are within the scope of the data model (e.g., ac-
counting, administration, billing, engineering).
•
This contains entities, attributes, and business
rules within the subject areas. The model also shows relationships be-
tween the entities. Key fields and foreign keys also can be identified in
this model.
Logical Data Model:
•
Transaction Analysis:
This is a list of transactions supported by the
system, the entities (and possibly the fields) that are accessed by the
transactions, and the frequency with which they are accessed. A cre-
ate, read, update, and delete (CRUD) matrix is a useful input for help-
ing with this analysis.
•
This is a denormalized version of the logical data
model that is optimized for performance under a specific technical en-
vironment and refined through the transaction analysis results. The
physical data model usually is refined throughout a development cy-
cle and is not finished until implementation. The physical data model
contains physical objects such as tables, fields, indexes, foreign keys,
primary keys, views, user-defined data types, and rules.
Physical Data Model:
•
Object Model:
An object model supports the logical data model. This
often serves as an intermediate layer between an object-based user in-
terface and a relational back-end database.
•
Validation Model:
This is a cross-reference of models, such as process
models, to the logical data model to prove its validity. It often includes
Search WWH ::
Custom Search