| PRIDE | ® | -DBEM |
| ||||||
"A Data Base should naturally evolve over time and
synchronize with all Information Systems."
- Bryce's Law
This section contains the following:
Copyright © 1971-2006 by
M. Bryce & Associates
Palm Harbor, Florida, USA
All rights reserved.
The purpose of this phase is to design or modify an Application Physical Data Base Model (APDBM) for an information system. Several events occur during this phase:
METHODOLOGY NAVIGATION
A Phase 5 is initiated following Phase 4. There is a
one-to-one relationship between Phase 5 and an information
system. In other words, a Phase 5 will be executed for each
system in the project (normally there is just one). As such,
the Project Manager may bind the system number to the
project/phase key. For example:
Even if the scope of the project is to only modify a small
portion of a system (such as a single sub-system, procedure,
program or module), the whole system identifier should be used.
The formal deliverable resulting from Phase 5 is an "APDBM
Design Manual" consisting of a description of the Application
Physical Data Base Model. This is reviewed with Data Resource
Management, Project Management, Data Communications
Administration and Software Engineering.
Following Phase 5, the DBEM project will proceed to Phase
6, "DBEM Evaluation."
GENERAL DISCUSSION
Phase 5 closes the loop between the four data base models.
The objective is to define all of the physical file structures
needed to support a single information system, not the
enterprise as a whole. As such, the APDBM represents a subset
of the EPDBM.
During Phase 2 of ISEM, Systems Engineering identified the
primary logical files needed for the system. From these logical
files, decisions were made as to how these files should be
physically implemented. Ultimately, these files represent the
primary storage files required by the system. Later, during
Phase 3 of ISEM, Systems Engineering may have identified the
need for manual files to store input/output documents, and
computer files for input transactions and to capture output
data. During Phase 4-II of ISEM, Software Engineering
identified the need for working files to pass data between
programs and modules. Whereas the thrust in DBEM has primarily
been concerned with the ISEM Phase 2 files, Data Base
Administration must also accommodate those files identified in
Phases 3 and 4 of ISEM.
As Data Base Administration completes the APDBM, the
physical file structures are delivered to Software Engineering
as part of Phase 4-II/Activity C of ISEM. These data structures
will then be included as part of the programming specifications.
In other words, Software Engineering is the ultimate beneficiary
of DBEM.
The purpose of the APDBM is to provide data structures in
a way that is convenient for the specific application, avoiding
the complexities of the global picture. In the absence of a
DBMS, the APDBM is just a subset of the EPDBM which refers to
the particular application, that is: the physical files used by
the application. If a DBMS is used, it can be different from
the enterprise model to an extent that varies with the DBMS
used. Differences between the two physical models that cannot
be accommodated by the DBMS, (or in the absence of one), must be
implemented by the application programs. The View mechanism of
IBM's DB2 is one of the most powerful in this respect. The
Subschema mechanism is used for CODASYL type DBMS package, while
IMS uses the Logical Data Base.
Ideally, if the DBMS could provide 100% data independence,
the APDBM should have exactly the same structure as the ALDBM,
or else match it as closely as possible. In this way, Software
Engineering would have no difficulty in translating the logical
data structures designed by Systems Engineering into physical
ones. In practice, one has to adhere to the constraints of the
DBMS and provide additional differentiation through program
code.
Security and integrity constraints can also be implemented
through this model by hiding certain records, data elements and
relationships present in the Enterprise Model from a particular
application.
For a more complete description of physical file
considerations, consult the Phase 4 narrative.
APPLICATION PHYSICAL DATA BASE MODEL (APDBM) BASIC CONSTRUCTS
NOTES: The pointers represent relationships
between the various resources as physically recorded in the IRM.
RD-to-RD and FD-to-FD relationships depend on the selected file
management technique.
EPDBM TO APDBM RELATIONSHIPS
The EPDBM represents the global view of data storage
requirements. During Phase 5, Data Base Administration
must consider physical requirements for individual systems.
Ultimately, the APDBM represents subsets of the EPDBM.
Relationships between the EPDBM and the APDBM can be
expressed using RD-to-RD and FD-to-FD relationships.
ALDBM TO APDBM RELATIONSHIPS
The Application Physical Data Base Model (APDBM) will
consist of physical files and records that must store the data
needed to satisfy the ALDBM. There is not always a one-to-one
relationship between logical and physical structures. One
logical file may be implemented by multiple physical files.
Conversely, one physical file may implement many logical files.
Physical implementation is based on what is cost-effective and
may take many forms (e.g., indexed files, indexed sequential,
flat files, hierarchical/network/relational DBMS, etc.). The
point is, the relationships between logical and physical must
be mapped in the IRM to demonstrate that the physical
satisfies the logical.
RECORD DESCRIPTION (RD)
As this discussion indicates, the Record Description (RD)
resource in the IRM is used for a variety of purposes. In a
logical context, the RD represents a "View"; in a physical
context, the RD represents a "Record." The RD is also used to
represent other physical structures, such as: screen panels,
print maps, input transactions, output data, messages, tables,
etc. All of these structures exhibit the same characteristics;
all require some form of unique key, and all contain data
elements.
The File Description (FD) is used to represent logical
files (Objects), physical files, and data bases. Files consist
of records, thereby an FD/RD relationship is required. A data
base represents a global view of data, therefore an FD/FD
relationship is used to map all of the files within a data base.
The RD is also the primary resource used to map the
relationships between all four data base models. Although the
File Description (FD) provides for FD-to-FD relationships, it is
the RD that is used to connect the models.
The following diagram illustrates all of the BASIC
relationships needed to map the four data base models in the
IRM. Additional pointers are available for different purposes,
particularly for complicated physical file structures.
IRM RESOURCE RELATIONSHIPS - MAPPING THE FOUR DATA BASE MODELS
This diagram illustrates all of the BASIC relationships needed to map the four data base models. Additional pointers are available for different purposes, particularly for complicated physical file structures. APDBM REPRESENTATION Graphical techniques to represent physical file management techniques may vary from vendor to vendor. Data Base Administration should use whatever technique is available. To represent FD/RD/DD structures in the IRM, a variety of matrices are available:
Aside from the matrices, the other major deliverable resulting from this phase are file layouts which detail the physical data structures. These are provided to Software Engineering as part of their programming specifications.
DESCRIPTION OF PHASE ACTIVITIES
Activity A - Analyze ALDBM & EPDBM
Data Base Administration reviews the ALDBM, the EPDBM and
performance, security and integrity requirements as
reflected in the phase documentation.
Activity B - Define Application Physical DB Model
Data Base Administration designs the Application Physical
Data Base Model to match the ALDBM and EPDBM. Physical
file/record/data structures are entered in the IRM and
mapped between the three models.
Activity C - Create D.D.L. Statements
Data Base Administration finalizes the design by preparing
program file structure statements (such as Data Definition
Language statements, COBOL copybooks, etc.).
DBA then assembles the deliverables produced in the phase
and packages them into a single phase review document which
is evaluated by Quality Assurance prior to conducting the
formal phase review.
Data Base Administration conducts a formal review of the
Phase 5 deliverables with Data Resource Management, Data
Communications, Project Management, and Software
Engineering. The review is used to evaluate the work
performed thus far and revise as required. At this time,
management will review the formal Phase 5 "APDBM Design
Manual" consisting of:
Based on this report and subsequent review meeting,
management may elect to revise parts of the report.
If acceptable, the designs are turned over to
Software Engineering for inclusion in programming.
| |