The purpose of this phase is to design or modify an Application Logical Data Base Model (ALDBM) for an information system. Several events occur during this phase:
METHODOLOGY NAVIGATION
A Phase 2 is initiated following a Phase 1. There is a
one-to-one relationship between Phase 2 and an information
system. In other words, a Phase 2 will be executed for each
system identified in Phase 1 (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 2 is an "ALDBM
Design Manual" consisting of a description of the Application
Logical Data Base Model. This is reviewed with Data Resource
Management who must decide whether to:
Following Phase 2, the DBEM project will proceed to Phase
3, "Enterprise Logical Data Base Design," where the Application
Logical Data Base Models will be merged into the Enterprise
model.
GENERAL DISCUSSION
The Application Logical Data Base Model (ALDBM) represents
a logical view of the data resources required by a single system
(application). It does not represent "global" data resources,
but rather a "local" view. The "global" view is defined by the
Enterprise Logical Data Base Model (ELDBM) as defined in Phase
3. The ALDBM is intended to represent the major facts and
events pertaining to a specific application. There is one such
model for each Information System.
As opposed to the ELDBM, the ALDBM does not have stability
as a major objective, but rather is designed to satisfy the
needs of one system at one particular time. As object views
change, so do the corresponding ALDB Models. Each ALDBM is a
consistent subset of the ELDBM, with redundancy and overlaps
being allowed among the various ALDB Models.
Because the ALDBM is defined for a system, it is normally
prepared by Systems Engineering, the architect of the system.
By this time, the Systems Engineer should be the leading
authority regarding the data requirements for the system and,
thereby, is the in the best position to define the ALDBM.
During this phase, Systems Engineering is supervised by Data
Engineering who provides assistance in logical data base design
related problems.
BASIC CONSTRUCTS
The ALDBM is composed of a set of interrelated Objects as
used in a specific application. To briefly recap the Object
Concept (as described in the Methodology Overview),
Objects represent business facts and events. Facts are somewhat
tangible in nature; e.g., Products, Parts, Employees, Customers,
Vendors, etc. Events represent some form of interaction between
facts; e.g., Shipments, Orders, Billings, Payments, Purchases,
etc. Each object is uniquely identified by a single data
element referred to as the "primary basic grouping." AN
OBJECT IS AN OBJECT ONLY WHEN A DATA ELEMENT HAS BEEN CREATED TO
UNIQUELY IDENTIFY IT.
Objects are decomposed into "views" to describe different
aspects (perspectives) of the object. There are three types
of views:
BASIC GROUPING
Each view consists of the data elements that are used to
identify, describe or quantify the object. A "basic grouping"
(logical key) is established for each view. The basic grouping
uniquely identifies the view and the data elements within it.
The "basic grouping" is composed of one or more of the
following:
OBJECT RELATIONSHIPS
Objects relate to one and other through "Relationship
Views," not "Characteristic Views." Under this approach, a
"Relationship View" is used to link other objects; for example:
These relationships are implicitly defined by the "basic
grouping" of the "Relationship View." In this example, the
"basic grouping" for the "Order Relationship View" would be:
"Order Number," "Customer Number," and "Product Number." In
other words, "Customer Number" and "Product Number" are foreign
keys to other objects.
To explicitly define the relationships between the objects
pointers are defined from the "Relationship View" to the
"Identification Views." Further, it is necessary to establish
rules about the relationships. For example; Can a customer
place many orders? Does an order relate to many products?
This knowledge reflects important business rules and will be
used as the integrity constraints when defining the physical
data base. The typical types of relationship rules between
objects include one-to-many (1:M), many-to-many
(M:M), and many-to-one (M:1). For example:
The first relationship between Customer/Order represents a
one-to-many relationship; a Customer can place many Orders, but
an Order pertains to a single Customer. The Order/Product
Relationship expresses a many-to-many relationship; a single
Order may be for many Products, and one Product may be used by
many Orders.
APPLICATION LOGICAL DATA BASE MODEL (ALDBM) BASIC CONSTRUCTS
NOTES: The pointers represent relationships
between the various resources as physically recorded in the IRM.
The relationship between the Order and the Customer would
be used to indicate types of relationships between views
(e.g., 1:M, M:M). Also, it implies a relationship
to a Product Identification View.
ALDBM/ELDBM RELATIONSHIP
Each ALDBM Object corresponds to an ELDBM Object. As
new Objects and/or data elements are uncovered by Systems
Engineering, they are created first in an ALDBM and later
integrated into the ELDBM by Data Engineering during Phase 3.
In this way, each ALDBM Object will eventually become a subset
of the corresponding ELDBM Object. To illustrate:
This means that there may be many different types of
Employee Objects which contain subsets of data to describe the
object for a particular system. However, there may be only one
"global" Employee Object expressed by the ELDBM to accommodate
all ALDB Models. This "application" versus "enterprise" view
implies an evolutionary approach to data base design, which is
natural.
The integration of ALDBM Objects into the ELDBM is
developed through an iterative process of reviews and
modifications to either model by Data Engineering. Since
Objects are identified through the same criteria for both
logical models, they should be compatible. In fact, in a
hypothetical situation of a completely new enterprise, the first
Application Logical Data Base Model becomes the Enterprise
Model.
To satisfy the requirements of Data Base Engineering, the
ALDBM must be:
ALDBM TO APDBM RELATIONSHIPS
During Phase 5, Data Base Administration will design and
develop the Application Physical Data Base Model (APDBM). This
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.
As we will see in the physical design phases (4 and 5), 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 implementation satisfies
the logical. Again, this mapping is performed in Phase 5.
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. ALDBM REPRESENTATION There are three complementary ways to graphically express the ALDBM:
Two types of ALDBM Matrices are available. The ALDBM Views Matrix expresses the relationships between logical records. The ALDBM Objects Matrix expresses the relationships between logical files; this is deduced from subordinate record relationships.
HOW DATA ELEMENTS ARE USED The data element is the basic building block for all data resources. It is used to identify, describe and quantify the objects of the business. In this respect, it represents the facts about the business. The data element can be related to a variety of information resources, for different purposes. Data elements are documented in the IRM using the Data Description (DD) resource and can be related to: IR - INFORMATION REQUIREMENTS The IR/DD relationship expresses all of the data elements, both primary and generated, needed to support the information requirement. OD - OUTPUT DESCRIPTIONS The OD/DD relationship is used to represent all of the data elements, both primary and generated, that will be physically contained on the output. Data will also be used as the Sort/Access Key for the output. ID - INPUT DESCRIPTIONS Data will be related to inputs to express its Sort/Access Key. FD - FILE DESCRIPTIONS Data will be related to files to express keys: For logical files (Objects), a single indicative data element is selected as the "primary basic grouping." For physical files, one or more data elements can be appointed the Sort/Access Key to the file. RD - RECORD DESCRIPTIONS In records, data will be used both as keys for the record, and as part of the record's content set (the collection of data elements contained in the record). For logical records (Views), one or more indicative data elements are selected as the "basic grouping." For physical files, one or more data elements can be appointed the Sort/Access Key to the record. DD - DATA DESCRIPTIONS Data to data relationships are used to express three different types of data dependencies:
Of all of these resources, DBEM is primarily concerned with FD, RD, and DD resources. DATA DEFINITION (DD) Perhaps the most difficult task in all of DBEM is to correctly define a data element. This requires considerable skill. Historically, analysts and programmers have defined nothing more than a program label. Little insight was recorded in terms of the business facts and events being recorded. In order to properly define the ALDBM, it is necessary to supplant this physical perspective with a logical perspective. Defining logical files and records is relatively easy in comparison to defining data elements. This is not said to intimidate the reader, but rather to issue a strong warning as to the ramifications of superficial work. Systems Engineering will still be responsible for defining data requirements, but it is Data Engineering's responsibility to assure that data is defined correctly with a high degree of precision. If left unresolved in the ALDBM, problems will only cascade to the other data base models in subsequent phases. Although a complete description of the characteristics of a data element are provided in the Methodology Overview (see "Anatomy of a Data Element"), the following recaps the major points in defining data logically:
APPROACH TO DESIGN Ideally, File/Record/Data Definitions should have been created within ISEM Phase 2 (System Design) by Systems Engineering. If not, they are defined here in DBEM Phase 2. Subsequently, Systems Engineering is responsible for defining the relationships between objects using RD-to-RD Relationships. During System Design, should Systems Engineering encounter FD/RD/DD structures in another ALDBM that satisfy the data requirements in the new application, the Systems Engineer may elect to incorporate these data structures into the new ALDBM. As part of this decision to re-use existing resources, Systems Engineering must consider the time frame by which the existing file is created/updated/referenced in other sub-systems. If compatible with the new application's requirements, it is perfectly acceptable to include the data structures in the new ALDBM. The Systems Engineer should, of course, check with Systems Resource Management to assure that this is acceptable. During the preliminary design phases of system development/ modification projects, or as part of documentation projects, records and data elements are created and normalized and relationships are determined. Each such model is then integrated into the Enterprise Logical Data Base Model by Data Engineering during Phase 3.
DESCRIPTION OF PHASE ACTIVITIES
Activity A - Define Application Objects
Systems Engineering reviews the data requirements for
all of the Information Requirements within an application.
From them, an ALDBM is created consisting of File, Record
and Data Descriptions. The files are attached accordingly
to sub-systems.
Data Engineering supervises resource definitions.
Activity B - Design Application Logical DB Model
Systems Engineering defines the relationships between
Objects using RD-to-RD relationships. Data Engineering
supervises these relationships and referees discrepancies
in resource relationships.
Systems Engineering 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 with management.
Systems Engineering conducts a formal review of the
Phase 2 deliverables with Data Resource Management,
Systems Resource Management, Project Management, and Data
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 2 "ALDBM Design
Manual" consisting of:
Based on this report and subsequent review meeting,
management may elect to revise parts of the report,
discontinue the project, or approve it for continuation.
| |||||
