BUSINESS PURPOSE
The purpose of this activity is to define the Application
Logical Data Base Model (ALDBM). This includes the Objects,
Views and Data Elements required by an Information System.
It is executed by Systems Engineering with Data Engineering
supervising.
OVERVIEW
If ISEM and DBEM are performed properly, this activity
should be an academic exercise. During Phase 2 of ISEM, a
System is decomposed into Sub-Systems, complete with their
logical files. Thereby, this activity is used to simply
confirm the definitions of the files, records, and data
elements.
The purpose and use of logical Objects is described in
both the Methodology Overview and the Phase Overview.
They consist of logical Views (perspectives
about the Objects), which in turn are composed of data elements.
ALDBM Objects represent the facts and events of interest to the
enterprise within the confines of the Information System.
Because of this, ALDBM Objects represent a subset of enterprise
level objects.
The identification of ALDBM Objects is a critical step in
data base design in that it identifies the facts and events
related to the business. This fact/event approach to data
abstraction is unique to the Data Base Engineering Methodology
and was designed to make the process of creating models more
practical and less ambiguous then the Entity oriented approach
commonly used. The major difference between these two
approaches is not in the form of representation of the model,
but rather in the semantic difference between Objects and
Entities. While Entities represent "things" that exist in the
real world, Objects are more general, in the sense that they can
be any convenient data abstraction known to the enterprise.
Ideally, Objects should be initially identified in EEM,
refined in ISEM, and completed in DBEM. In the absence of such
preliminary activity, the definition of the object defaults to
DBEM for completion.
RULES FOR OBJECT DEFINITION
Objects within the ALDBM must satisfy the following
properties:
- An Object must relate to at least one internal business
function (FE/FD Relationship).
- Each Object is clearly described in business terms on
the corresponding FD resource definition. Objects may
either represent "facts" (name/location related), or
"events" (date/time related).
- An Object must be uniquely identified by a single indicative
data element. This is commonly referred to as the "primary
basic grouping" data element of the object. The "primary
basic grouping" is also used to group views (logical
records) together into a logical file.
- All Objects must have an "Identification View" (logical
record) to uniquely identify the Object.
- A fact-related Object may or may not have one or more
"Characteristic Views" (logical records) that are used to
describe the Object internally. The "basic grouping" for
the view consists of the "primary basic grouping" element,
followed by one or more "view identifiers" (not a "foreign
key").
- An event-related Object must have one or more "Relationship
Views" (logical records) to express some form of interaction
between two fact related Objects. The "basic grouping" for
the view consists of the "primary basic grouping" element,
followed by "foreign keys" to the other fact-related
Objects. No more than two fact-related Objects can be
associated with a single "Relationship View." Relationships
between views are explicitly defined using RD/RD
Relationships.
- Views will contain only primary data elements (not
generated) that are either descriptive or quantitative
in nature (not indicative). The "basic grouping" of the
view adds meaning to the subordinate data (for example,
when "Name" is related to "Customer Number," it represents
"Customer Name." Further, the "basic grouping" of the view
must allow no more than one occurrence of a data element
(thus creating a dependency).
THE "CLEANLINESS" OF DATA
An essential part of Object definition is data definition.
The objective is to define unique, unambiguous data elements
(clean data). Some guidelines are in order:
- PRIMARY DATA - the business definition of primary
data should be simple and to the point.
For INDICATIVE DATA the data element should be
strong enough to either describe a whole object or a view
within it. Data elements such as "Control Number" or
"Identification Code" would not qualify based on this
criteria. Instead, "Customer Number," "Territory Code,"
"Order Number," "Contact Number," and "Address Code"
would be legitimate.
DESCRIPTIVE data elements should be kept in
simple terms, allowing their definition to be interpreted from
their dependency with indicative data elements. From this
perspective, data elements such as "Employee Name," and
"Vendor Address," would be illegitimate. Instead,
"Name" and "Address" would be legitimate.
QUANTITATIVE data elements should be more
explicitly defined than descriptive data since they may or may
not be used to compute generated values. From this
perspective, data elements such as "Quantity" would not
be valid. Instead "Quantity Ordered" and "Quantity
Shipped" would be legitimate. Such precision in data
definition also provides insight into the dependencies
to objects.
- GENERATED DATA requires much more explanation
than primary data. For example, "Net Pay - Hourly Workers"
would be valid, not simply "Pay" or "Payment." The
distinguishing characteristic that differentiates generated
data is that each element has a unique set of data dependencies
and formula/algorithm for calculation. This is what
distinguishes "Net Pay - Hourly Workers" from "Net Pay -
Salaried Employees" and "Net Pay - Sales Commissions."
Although each may share certain data elements, each has
a unique formula for calculation that produces a different
result.
In other words, it is simply not sufficient to say one
generated data element is different than another. The
data elements and formula/algorithm must be distinctly
different (even if it is a small or subtle difference).
Generated data also includes "group" data elements such
as "Credit Card Number" and "Telephone Number." These
represent a concatenation of indicative data elements
representing objects. For example, "Telephone Number"
is a valid group item to identify a "Communications Area"
and its views for a telephone company. But if
"Communications Area" is not a pertinent object to your
business, there is little point in defining it as a
group item. Instead, it is a simple primary value.
As with other generated data elements, a group item should
express a unique set of data dependencies and a unique
algorithm for assigning them.
STEPS IN EXECUTION
- Systems Engineering reviews the specifications resulting
from Phase 1, along with any other pertinent system
documentation related to the application (such as ISEM
Phase 1 and 2 manuals). Based on the specifications,
Systems Engineering prepares a Detail estimate and schedule
to complete the phase. This is based, in part, on the
Order-of-Magnitude estimate/schedule resulting from Phase
1. The Detail estimate/schedule is reviewed with Project
Management for approval.
- Systems Engineering defines the objects, views, and data
elements associated with the application using FD, RD, and
DD resource definitions in the IRM. Data Engineering is
consulted during resource definition.
- Systems Engineering relates the logical files (objects)
to the sub-systems within the application, and to the
business functions associated with them.
- Systems Engineering prepares "Application Logical File
Discussions" for each logical file in the application,
along with a "Data Structure Display," and reviews them
with Data Engineering for accuracy. These deliverables
are retained for inclusion in the final Phase 2 design
manual.