Calhoun: The NPS Institutional Archive

DSpace Repository

Theses and Dissertations 1. Thesis and Dissertation Collection, all items

1996-03

Design and analysis of an object-oriented

database of electronic warfare data

Coyne, Kevin M.
Monterey, California. Naval Postgraduate School

[Link]

Downloaded from NPS Archive: Calhoun

NAVAL POSTGRADUATE SCHOOL
Monterey, California

THESIS
DESIGN AND ANALYSIS
OFAN
OBJECT -ORIENTED DATABASE
OF
ELECTRONIC WARFARE DATA

by

Kevin M. Coyne

March 1996
Thesis Advisor: David K. Hsiao
Co-Advisor: C. Thomas Wu

Approved for public release; distribution is unlimited•

.. T 'f'TIV INSPECJTED 3
DTIC QU AUJ.J. ..

19960724 044
 Form Approved
REPORT DOCUMENTATION PAGE OMB No. 0704-0188
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time reviewing instructions, searching existing data sources
gathering and maintaining the data needed, and oompleting and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this
oollection of infonmation, including suggestions for reducing this burden to Washington Headquarters Services, Directorate for lnfonmation Operations and Reports, 1215 Jefferson
Davis Highway, Su~e 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.

1. AGENCY USE ONLY CLeave Blank) 12. REPORT DATE 3. REPORT TYPE AND DATES COVERED
March 1996 Master's Thesis
4. TITLE AND SUBTITLE 5. FUNDING NUMBERS
Design and Analysis of an Object-Oriented Database of Electronic
Warfare Data(U)

6. AUTHOR(S)
Coyne, Kevin, M.

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION

Naval Postgraduate School REPORT NUMBER

Monterey, CA 93943-5000

9. SPONSORING/ MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/ MONITORING

AGENCY REPORT NUMBER

11. SUPPLEMENTARY NOTES

The views expressed in this thesis are those of the author and do not reflect the official policy or position
of the Department of Defense or the United States Government.

12a. DISTRIBUTION I AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE

Approved for public release; distribution is unlimited.

13. ABSTRACT (Maximum 200 words)

The Electronic Warfare Integrated Reprogramming Database (EWIRDB) is the primary Department of Defense (DoD)
approved source of electronic warfare (EW) data. Its utilization in the areas of battle planning and EW research enables our
military forces to effectively exploit the electromagnetic spectrum and shape the outcome of battle. The EWIRDB, however, lacks
a viable conceptual data model. EWIRDB data are represented in disjoint parametric tree models that are implementation-oriented;
to the extent that the tree structures are used as conceptual modeling tools, their hierarchical form is too restrictive to adequately
describe EW data semantics. Moreover, these structures address only technical parametric data. Associated administrative,
reference, and comment data are excluded. In practice, the EWIRDB is described in terms of the coded and record-based format
of its output media, not its conceptual model.
The primary goal of this thesis is the development of a semantically-improved conceptual design of EWIRDB data based on
the object-oriented data model (OODM). The secondary goal of the thesis is the specification of a logical design, based on the new
conceptual design, to:r;ovide the structure for a subsequent implementation ofEWIRDB data on the Multimodel and Multilingual
Database System (M DBS) in the Laboratory for Database Systems Research at the Naval Postgraduate School.
The results of the work contained herein are: (1) an object-oriented conceptual design ofEWIRDB data that supports the
semantics of both the file format and tree structures, and (2) the specification of an object-oriented logical design for an M2 DBS
implementation of sample EWIRDB data.
14. SUBJECT TERMS 15. NUMBER OF PAGES
Object-oriented Database Design 106
Electronic Warfare 16. PRICE [Link]:

Electronic Warfare Inte :rated Reprogramming Database

17. SECURITY CLASSIFICATION 18. SECURITY CLASSIFICATION 19. SECURITY CLASSIFICATION 20. LIMITATION OF ABSTRACT
OF REPORT OF THIS PAGE OF ABSTRACT
Unclassified Unclassified Unclassified UL
NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)
i Prescribed by ANSI Std. 239-18
ii
 Approved for public release; distribution is unlimited

DESIGN AND ANALYSIS

OF AN OBJECT-ORIENTED DATABASE
OF ELECTRONIC WARFARE DATA

Kevin M. Coyne
Lieutenant, United States Navy
B.S., United States Naval Academy, 1987

Submitted in partial fulfillment of the

requirements for the degree of

MASTER OF SCIENCE IN COMPUTER SCIENCE

from the

NAVALPOSTGRADUATESCHOOL

March 1996

Author:

Approved by:

Department of Computer Science

iii
iv
 ABSTRACT

The Electronic Warfare Integrated Reprogramming Database (EWIRDB) is the

primary Department of Defense (DoD) approved source of electronic warfare (EW) data.
Its utilization in the areas ofbattle planning and EW research enables our military forces to
effectively exploit the electromagnetic spectrum and shape the outcome of battle. The
EWIRDB, however, lacks a viable conceptual data model EWIRDB data are represented
in disjoint parametric tree models that are implementation-oriented; to the extent that the
tree structures are used as conceptual modeling tools, their hierarchical form is too
restrictive to adequately descn"be EW data semantics. Moreover, these structures address
only technical parametric data. Associated administrative, reference, and comment data
are excluded. In practice, the EWIRDB is described in terms of the coded and record-
based format of its output media, not its conceptual model
The primary goal of this thesis is the development of a semantically-improved
conceptual design of EWIRDB data based on the object-oriented data model (OODM).
The secondary goal of the thesis is the specification of a logical design, based on the new
conceptual design, to provide the structure for a subsequent implementation of EWIRDB
2
data on the Multimodel and Multilingual Database System (M DBS) in the Laboratory for
Database Systems Research at the Naval Postgraduate School
The results of the work contained herein are: (1) an object-oriented conceptual
design of EWIRDB data that supports the semantics of both the file format and tree
2
structures, and (2) the specification of an object-oriented logical design for an M DBS
implementation of sample EWIRDB data.

v
vi
 TABLE OF CONTENTS

I. INTRODUCTION .................................................................................................. 1

A AN" OVERVIE.W OF TliE EWIRDB ..... ,................................................... 1

B. TIIE FORMAT OF TIIE EWIRDB ............................................................. 4

1. The [Link] Tree Model ............................................................... 5
a. The [Link] Tree Structure and Notation .......................... 5
b. The Limitations Of Hierarchical Data Modeling ..................... 9
2. The File Structure ofthe Output Data .............................................. 11
3. Summary ......................................................................................... 16

C. TIIESIS OBJECTIVES .............................................................................. 17

D. TIIE ORGANIZATION OF TliE TIIESIS ................................................ 17

II. DESIGN CONCEP'fS ......................................................................................... 19

A TliE CONCEPTUAL DESIGN ................................................................. 19

B. TIIE LOGICAL DESIGN .......................................................................... 20

III. OBJECT-ORIENTED DESIGN CONCEP'fS .................................................. 23

A. OBJECTS .................................................................................................. 24
1. Object State ..................................................................................... 25
a. Silnple Attn"butes ................................................................. 26
b. Complex Attributes and Relationships .................................. 26
2. Object Behavior and Encapsulation .................................................. 27

B. OBJECT CLASSES ................................................................................... 29

1. Instantiation and Classification ......................................................... 31
2. Generalization and Specialization ..................................................... 32
3. Aggregation .................................................................................... 33
4. Covering ......................................................................................... 34

IV. A CONCEPTUAL OBJECT-ORIENTED EWIRDB ....................................... 35

A A GLOBAL SCIIEMA. .............................................................................. 37

vii
 B. Tiffi EMITlER SCIIEMAS ...................................................................... 42
1. The Kilting Emitter Class ................................................................. 43
2. The Association of an Emitter to its Signal ...................................... 46
3. The S&TI and USNCSDB Emitter Classes ...................................... 47

C. Tiffi SCIIEMAS WITIUN LOGICAL GROUPS ......................................... 50

1. Antenna Data .................................................................................. 50
2. Signal Data ...................................................................................... 52
3. Receiver Data .................................................................................. 55
4. WARM Data ................................................................................... 58

D. Tiffi PARAMETRIC DATA CLASS ......................................................... 58

E. SUFFIX CODING AND TilE SUFFIX TABLE ........................................ 63

V. A LOGICAL OBJECT-ORIENTED EWIRDB ................................................. 65

VI. CONCLUSION .................................................................................................. 83

LIST OF REFERENCES .......................................................................................... 87

INITIAL DISTRJBUTION LIST .............................................................................. 89

viii
 LIST OF FIGURES

1. The Merging of Data into the EWIRDB ................................................................... 3

2. The Pulsed/Continuous Wave (P/CW) Parametric Tree ............................................ 6

3. The Receiver Performance Assessment (RPA) Tree ................................................. 6

4. A Detailed Portion of the P/CW Tree ....................................................................... 8

5. A Description ofTERF Elements ............................................................................. 13

6. An Object Class and its Objects .............................................................................. 30

7. Conceptual Object-Oriented Design Symbology ...................................................... 36

8. The Conceptual Schema: A Global View ................................................................ 3 8

9. The Conceptual Schema: Kilting Emitter Data ........................................................ 44

10. The Conceptual Schema: S&TI Emitter Data ........................................................ 48

11. The Conceptual Schema: USNCSDB Emitter Data ............................................... 49

12. The Conceptual Schema: Antenna Data Enlargement ............................................ 51

13. The Conceptual Schema: Signal Data Enlargement ............................................... 53

14. The Conceptual Schema: Receiver Data Enlargement ........................................... 56

15. The Conceptual Schema: WARM Data Enlargement ............................................. 59

16. The Conceptual Schema: Parametric Data ............................................................. 61

17. The 0-0DDL Class Specification ......................................................................... 66

18. The 0-0DDL Inheritance Specification ................................................................ 66

19. The 0-0DDL Cover Specification ........................................................................ 67

20. The 0-0DDL Set_ofand Inverse_ofSpecifications .............................................. 67

ix
21. The Logical Design: DDL Implementation of the PARAMETRIC DATA Class .... 68

22. The Logical Design: DDL Implementation of the EMITTER Class ....................... 70

23. The Logical Design: DDL Implementation of the KILTING EMITTER and
KIT.,TING ADMINISTRATIVE DATA Classes ................................................... 70

24. The Logical Design: DDL Implementation of the ANTENNA Class ...................... 71

25. The Logical Design: DDL Implementation of the SIGNAL Class .......................... 74

26. The Logical Design: DDL Implementation of the RECEIVER Class ..................... 77

27. The Logical Design: DDL Implementation of the WARM Class ............................ 79

28. The Logical Design: DDL Implementation of the SUFFIX TABLE Class .............. 80

29. The Logical Design: DDL Implementation of the S&TI EMITTER and
S&TI ADMINISTRATIVE DATA Classes .......................................................... 80

X
 ACKNOWLEDGMENTS

I would like to thank Dr. David Hsiao and Dr. C. Thomas Wu for their guidance in
the development of this thesis. And thanks to Tom McKenna and J.J Lee who epitomize
the concept of teamwork.
I would also like to thank Doris Mlezko, Sharon Cain, and Donna Colehour for
their enthusiastic support.
Most importantly, I would like to thank my wife Maureen and my son Matthew for
their endless patience.

XI
Xl1
 I. INTRODUCTION

In this thesis, I propose an object-oriented design for a representative portion of

the Electronic Warfare Integrated Reprogramming Database (EWIRDB). In this chapter,
I highlight the important role of the EWIRDB in the national defense and provide a
description of the current format of the database. I conclude with specific thesis
objectives and an outline for the organization of the thesis.

A. AN OVERVIEW OF THE EWIRDB

Advances in electronic warfare (EW) technology have had tremendous impact on

modem military operations. The application of electromagnetic energy to secure friendly
use of the electromagnetic spectrum, and to detect, reduce, or prevent its hostile use may
well be the decisive factor in the outcome of battle. A force that effectively utilizes the
electromagnetic spectrum gains the initiative. A force that exploits the weaknesses in an
adversary's EW systems renders the adversary blind to the actual tactical situation.
Success in EW is a prelude to victory. Failure in EW is militarily devastating.
In the context oftoday's electronically-dependent warfare, frequent data collection
and analysis is essential to the development of EW technologies to counter the enemy
threat. Efficient maintenance of the latest data, obtained directly from measurement, or
indirectly via electronic intelligence (ELINT), is the basis of successful EW. The National
Air Intelligence Center (NAIC) maintains the latest data, in-depth and specific, on EW
systems of the United States, friendly forces, and non-friendly forces. These data are
stored in the Electronic Warfare Integrated Reprogramming Database (EWIRDB ).
"The EWIRDB is the primary Department ofDefense (DoD) approved source for
technical parametric and performance data on noncommunications emitters and associated
systems."[l] Noncommunications emitters include radars, jammers, navigational aids,
transponders, target-sensing systems, and others. All such emitters generate and receive
electromagnetic radiation and may be used to gain the advantage in armed conflict.

1
EWIRDB emitter data are therefore indispensable in the analysis and execution of EW;
without them, our ability to effectively manipulate the electromagnetic spectrum would be
compromised.
The EWIRDB is the union of data from three constituent sources. The National
Security Agency (NSA) contributes data from its ''Kilting" database. Obtained through
ELINT, Kilting data are referred to as observed data in the EWIRDB. Observed data
result from the direct measurement and analysis of an emitter's electromagnetic signature
following the signal intercept; they are fundamental in describing an emitter's
performance. The Scientific and Technical Intelligence (S&TI) community, under the
jurisdiction of the Defense Intelligence Agency (DIA), contributes parametric data
assessments to the EWIRDB. S&TI systems ana1ysts consider all available sources of
information and then estimate or derive the total operational capability of an emitter.
Derived parametric data in the EWIRDB are referred to as assessed data. The United
States Noncommunications Systems Database (USNCSDB), supported by the Air Force
Information Warfare Center (AFIWC), holds data on US owned and operated
noncommunications emitters. USNCSDB service analysts provide inputs based on
evaluation of system specifications. EWIRDB data of this type take the same format as
assessed data, and for this reason, are generally referred to as assessed data as well.
The EWIRDB is thus a data composite. Moreover, this pooling of EW data may
reflect different data values from different sources. Figure 1 depicts the EWIRDB as a
composite of its three contn"butory sources.
Developed in the seventies to support the reprogramming of EW systems, the
EWIRDB and its role has since grown in both scope and in significance. While its primary
focus remains in EW software reprogramming, the EWIRDB has become vital in other
areas: EW research, development, test, and evaluation (RTD&E); modeling and
simulation (M&S); training and acquisition. Merits of the EWIRDB are revealed by post-

2
 Various Producers

Kilting USNCSDB
(NSA) (AFIWC)

ELINT SYSTEMS SERVICE

ANALYST ANALYST ANALYST

assessed

EWIRDB
observed data (NAIC) specification

Figure 1. The Merging of Data into the EWIRDB

3
Desert-Storm figures: the value of the reprogrammable EW equipment directly supported
by the EWIRDB has been estimated at $30 billion; the value of the operational systems,
RTD&E, M&S, and training and acquisition programs that employ the EWIRDB has been
estimated to be $1 trillion [ 1].
In short, the EWIRDB is an indispensable tool that helps to bridge the gap
between data analysis and effective exploitation of the electromagnetic environment by
EW systems. It is a medium whose use ultimately helps maintain military readiness and
minimize the loss of life in combat.

[Link]~B

Although effective in its implementation, the data model of the EWIRDB is

problematic. The EWIRDB is descnbed in terms of a data-implementation model to the
exclusion of a legitimate semantic data model. Data is presented in a hierarchical tree that
is inherently arbitrary and reliant on the use of reference codes to link related pieces of
data throughout the hierarchy. The non-intuitive hierarchical organization and coding
scheme prevent the user from gaining a meaningful view of an emitter's performance
parameters. Consequently, the nature and semantics of the EW data are obscured by its
current representation.
The administrative information maintained for emitter systems and their associated
parametric data entries is excluded from the existing data model The administrative data
are addressed only in terms of the formatting of the data output file. This is a major

shortcoming; the administrative data are important to the analysis and tracking of
parametric data, and represents a significant portion of the database.
In general, the ''intuitiveness" of data representations and the ease with which data
formats may be intetpreted largely determine the usefulness of a database. The current
EWIRDB oversteps the boundaries of both criteria. So while it remains the foremost
source of mission-critical EW data, lack of an adequate semantic data model ultimately
results in a reduction of the EWIRDB's effectiveness as an instrument ofEW.

4
 1. The Parametric Tree Model
The upper-level hierarchical data model of the EWIRDB is illustrated in Figures 2
and 3. The Pulsed/Continuous Wave (P/CW) tree in Figure 2 is used principally to
evaluate and identify the electromagnetic energy radiated by emitters. The Receiver
Parametric Performance (RPA) tree in Figure 3 contains receiver design and performance
information on the receiver portion of emitter systems and serves as a vital reference in the
development of electronic countermeasures (ECM) techniques and systems. The P/CW
and RPA trees together provide a comprehensive report on an emitter's performance. A
third hierarchical structure, the Electronic Countermeasures (ECM) tree, exists; it is not
shown in any figure. ECM tree data descn"be jamming systems, and are referenced in the
development of electronic counter-countermeasures (ECCM) to overcome the jammer
threat. At present, however, the viability of the ECM tree is being reevaluated by the
agencies that participate in and contn"bute to the EWIRDB program. The ECM tree is
therefore not addressed in this thesis.

a. The Parametric Tree Structure and Notation

As depicted in Figures 2 and 3, the tree structures graphically show how
emitter data are catalogued. ''The tree is a management tool that orders a long list
logically and hierarchically in a way that proceeds from broad characteristics through
levels of successively finer characteristics" [ 1]. Each branch contains a heading or label to
indicate the type of parameters or attributes associated with the branch. For example,
"SIGNAL POWER" of the 11 B (B) SIGNAL POWER branch in Figure 2 is a branch
name or heading. Branches contain zero or more parameters. A branch with zero
subordinate parameters is referred to as a "superheader". Superheader branches pose a
unique modeling problem - they contain no data and are not reflected in the data contained
within the database. However, superheaders are useful, despite their lack of parametric
data, in identifying a major areas of interest to be decomposed in subordinate branches.

5
 10 8 (A) GENERAL INFORMATION

11 8 (B) SIGNAL POWER

12118 (C) TX ANJENNAPOLARIZATION

121 8 ANJENNA POLARIZATION 1212 8 (D) RX ANIENNA POLARIZATION

1213 8 (E)TXIRX ANJENNAPOLARIZATION

12 8 ANTENNA
12218 (F) 1RANSMITONLY ANIENNA
I 8 P/CWTREE
122 8 ANT CHARACTERIS11CS 12228 (0) RECEIVE ONLY ANJENNA

12238 (H) ANJENNAPOLARIZATION

1311 8 (I) PULSEDSIGNALSHAP E(AM)

1312 8 (J) PR11P0R1 13123 8 (K) MULTIPLE PULSE GROUPS

131 8 PULSED SIGNAL
13131 B (L) RFI..INES1RUCTURE
1313 B FREQUENCY
Jl3132 B (M) PULSED RF
13 B FREQUENCY AND
MODUlATION CHAR
1321 B (P) CWFREQUENCY
132 8 CW
1322 8 (Q) CWMODUIATION

14 8 (R) ASSOCIAlED SIGNALS/SYSTEMS

Figure 2. The Pulsed/Continuous Wave (P/CW) Parametric Tree

IS11 E (AB) RECEIVER FRONT END

IS12 E (AC) FREQUENCY CONVERSION

I Sl3 E (AD) IF SECTION

lSI E (AAl RECEIVER PARAMETERS

IS14 E_{AE) SINOLEPULSEPROCESSINO

ISIS E (AF) MULTIPLE PULSE PROCESSING

IS E RPAlREE

IS16 E (AO) DISPLAY/INDICATOR

IS2 E (AH) ECCM CAPABIUI1ES

IS3 E (AI) SYSTEM INFORMATION

Figure 3. The Receiver Performance Assessment (RPA) Parametric Tree

6
 Thus, in a parametric tree, branches categorize emitter and signal
parameters, whereas parameters hold actual data values in the database. A numbering
system is also provided for descn"bing branching throughout the depth of the parametric
tree. The branch number is given as the first entry on a branch. Each branch has a single
predecessor and is assigned a ~que number to define a unique path from the root of the
tree to any given branch. The "11" of the 11 B (B) SIGNAL POWER branch in Figure 2
is an example of a branch number.
As specified by branch markers called subfile codes, data are organized
throughout the tree to effect logical groupings of parameters. Subfile codes appear in
parentheses in Figures 2 and 3. Data subhierarchies rooted at subfile-coded branches are
meant to encapsulate major aspects of an emitter's performance or convey the semantics
of high-level emitter and signal characteristics: Subfiles are therefore equivalent to
subtrees, and accentuate major groupings of related data. The "(B)" listed on the 11 B
(B) SIGNAL POWER branch in Figure 2 indicates that subfile B, rooted at branch 11,
contains data that in the composite is descriptive of the high-level characteristic "SIGNAL
POWER".
All branches and parameters in the EWIRDB are not applicable to all
database users. A branch or subordinate parameter may be useful to an S&TI analyst, for
instance, and meaningless to Kilting analyst. Likewise, the data in a particular branch may
be applicable to all users. Parametric trees contain usage codes to distinguish usability of
branches and parameters among participating agencies. The non-parenthesized ''B" on the
11 B (B) SIGNAL POWER branch, for example, indicates that the SIGNAL POWER
branch is used for Kilting, S&TI, USNCSDB, and NSRL (National SIGINT Requirements
List) purposes. In other words, that branch is applicable to all agencies that use the
EWIRDB. The other codes are K for Kilting and NSRL usage, E for S&TI assessed data
and USNCSDB, and N for NSRL-only usage.
The hierarchy depicted in Figure 4 offers perspective on the complexity of
the parametric tree. Specifically, all branches subordinate to branch 121 B ANTENNA

7
 121Xll B2 LINEARPOLARIZATION

.lOB I MAJOR AXIS TILT ANGLE DEG!HOR

121Xl B 2 FIXED POLARIZATION .20 B 6 AXIAL RATIO DB

.IOB4TIMETOSWITCH MILLISEC
121X12 B 2 CD!.CULAR OR [Link]
.20 B 4 AtiTO OR MANUAL SWITCHING (1EXI)
.IOB2 SENSE(LH-RH) (1EXI)
.20 B S AXIAL RATIO DB
.30 B 2 MAJOR AXIS TILT ANGLE (ELLIPSE)

121X21 B 2 ADAPilVEPOLARIZATION
.01 B 2 CHANGE PATTERN (1EXI)
.lOB 2 RATE OF CHANGE HERTZ
.20 B 2 REASON FOR CHANGE (1EXI)
1211 B TXANTENNAPOLARIZATION

121X22 B 2 MANUAL POLARIZATION CHANGE

121X2 B2 VARIABLE POLARIZATION .lOB 2 RATE OF CHANGE HERTZ
.20 B 2 REASON FOR CHANGE (1EXI)
121 B ANTENNA POLARIZATION 1212 B RXANTENNAPOLARIZATION
121X23 B2 PERIODIC PROGRAMMED POLARIZATION

.IOB3 RATEOFCHANGE HERTZ

.20B4 CHANGEPATTERN (1EXI)

1213 B TXIRXANTENNAPOLARIZATION 121X24 B 3 POU\RIZATION MODULATION

.I 0 B S CONilNUOUSIDISCRETE POU\RIZATION(1EXI)
.20B4 MODULATINGWAVEFORMORCODE (1EXI)
.30 B 4 MODULATING RATE MHZ
.40B4 NBROFDISCRETEPOLARIZATIONS INTEGER
.SOBS BITLENGTII MICROSEC
.60BS NBROFBITS INTEGER

121X3 B2 CROSSPOU\RIZATIONCHAR

.I 0 B 3 PATTERN PEAK OFFSEI" DEGREES

.20B SPATTERNPEAK RESPONSE DB

Figure 4. A Detailed Portion of the P/CW Tree

8
POLARIZATION in the P/CW tree, that is all parameters associated with the branch, are
revealed. This portion of the parametric tree is neither the most complex nor the most
populated, but it is a precise and representative sampling of the data that reside in the
lower levels of the parametric tree.
The new notation in Figure 4 requires a brief explanation. A parameter is
listed with a two digit decimal number as a means to differentiate between parameters in a
given branch. (Branches themselves include the decimal notation, ".00", but the notation is
implicit and not shown in the tree model) The combination of the branch number and the
two-digit decimal number is referred to as the parametric number. Thus, locating a
parameter within the tree or within an output data file is a straightforward function of
indexing into the data via the parametric number. For example, parametric number
121Xl.10 indexes to the parameter .10 B 4 TIME TO SWITCH under the 121Xl B 2
FIXED POLARIZATION branch in Figure 4. (The X in the branch number is a variable
that specifies the type of antenna being considered, ie., transmit, receive, or transmit and
receive. The variable takes on the value 1, 2, or 3, accordingly.)
Additionally, since each parameter contains data, each includes an entry for
units of measure. Branches, in contrast, are not data entries but rather indicate that
parametric data groupings may be identified by a branch name or number, and therefore
do not specify units of measure.

b. The Limitations of Hierarchical Data Modeling

In general, the hierarchical data modeling of the EWIRDB parametric trees
is misleading in its representation of parametric data. Aside from highlighting the
complexity of the EWIRDB parametric tree, the sample hierarchy in Figure 4 also exposes
the arbitrary nature of the trees' hierarchical structure. An inability to precisely represent
data semantics is common to generic tree structures such as those of the EWIRDB. The
current EWIRDB tree model is strapped with this inherent arbitrary quality that limits the

9
EWIRDB' s effectiveness as a database and places the burden of data interpretation on the
user.
Specifically, the parallel branches, 121Xl B 2 FIXED POLARIZAT ION,
121X2 B 2 VARIABLE POLARIZAT ION, and 121X3 B 2 CROSS

POLARIZAT ION CHAR, seem to indicate that for a given antenna, polarization is
either fixed or variable or exhibits cross polarization characteristics. This is not actually
the case. For a given antenna, polarization is either fixed or variable, and all antennas may
be descnoed by cross polarization characteristics. Whereas the fixed and variable
polarization branches determine a clear boundary based on fundamental differences in an
antenna's characteristics, the cross polarization branch is applicable to all antennas,
regardless of their differences. The hierarchical structure in Figure 4 does not convey this
idea. It provides only a generic and inadequate treatment of the intended data semantics.
A similar situation arises in the hierarchy rooted at branch 121X2 B 2
VARIABLE POLARIZAT ION in Figure 4. The arbitrary nature of the hierarchical
modeling structure depicts a variably polarized antenna that appears to be rigged as one of
four types: adaptive, manually changed, periodic programmed, or modulated. Again, this
does not accurately reflect the intended meaning of the data. The correct interpretation is
that a given variably polarized antenna can be described as one of three types: adaptive,
manually changed, or periodic programmed. And just as the cross polarization branch
applied to any given entry in the preceding antenna polarization branch, the polarization
modulation branch describes characteristics common to all variably polarized antennas.
The polarization modulation is therefore not a criteria by which to categorize types of
variable polarization.
Another flaw in the EWIRDB tree model is a collateral effect of the general
layout of the data. Parametric data is scattered over a large number of separate records
comprising two distinct and largely independent structures, the P/CW and RPA trees. A
search of these two distinct structures and their associated parameters is required to

10
ascertain the performance of a given emitter. Consequently, the global view of an
emitter's performance, from a modeling perspective, is obscured.
Deficiencies in the parametric tree model are further exacerbated by the
fact that the trees are designed to characterize only parametric data. The EWIRDB also
contains administrative, reference, and commentary information, all associated with
parametric data. At best, then, even if the trees were perfect parametric data modeling
tools, only a portion ofEWIR data would have been taken into account.
The data not included in the parametric tree are loosely modeled in terms
of a file structure. The file structure is not, however, a data model. It is a description of
the data as presented in the output form Parametric data is therefore also descn'bed in
terms of the output format. While the file "model" incorporates all aspects of the
database, the overall semantic picture is difficult to grasp; the file format is also complex
and disjoint.

2. The File Structure of the Output Data

The EWIRDB output file format is designed to provide a comprehensive view C!f
parametric and associated data for emitters. It is cryptic in presentation, however, and
does not compensate for the lack of a semantically correct data model. While the view of
an emitter's parametric and associated data in the output file is complete, it is non-
intuitive. The Technical ELINT Reference File format (TERF) is the standard distn'bution
format for the EWIRDB and is composed of six different types of records, referred to as
logical information records. The record types are specified as follows, with the record
name preceding the record type designator in parentheses: Classification Record (SOO),
Emitter Name Record (SOl), Subfde Header (S02), Parametric Data (S03),
Reference Data (S04), and Comments (S05) [1].
A brief description of the TERF data fields is required to bridge the gap between
the data as modeled in the parametric trees and the data as presented in the TERF output.
Because the EWIRDB consists of data merged from different sources (see Figure 1), some

11
fields are source-specific. A tabular summary of the parametric data and other types of
data in the output file is provided in Figure 5. In the figure, "assessed data only" refers to
both S&TI and USNCSDB contnouted data, as stated earlier in Section I.A. A full

description of the TERF format, including the actual "look" of an output file, is given in
[1].
Three fields do not appear in Figure 5 but are common to all records in a file. The
first is Record Type, which specifies the record as SOO, SOl, 802, 803, 804, or 805. The
second field is the Source Designator, which identifies the contributory source of the data
contained in that record; K for Kilting, E for S&TI assessed data, and U for USNCSDB.
The third field is Notation, which provides the ELNOT (ELINT Notation) assigned to the
given emitter. The ELNOT is an administrative label that uniquely identifies an emitter.
Overall, the TERF format is complex. It represents a merger of data from different
sources with different needs and provides for nonstandard, source-specific data formats.
The TERF contains many codes. Some codes differ in symbology but relate to identical
components, and some apply to only certain types of data. Other codes distinguish
between multiple versions of the same parameter, and some relate mutually dependent
parameter values. Mode combinations and the suffix table pose a particularly challenging
modeling problem While modal relationships are critical in the identification and
evaluation of emitters, the relationships as coded in the suffix table are difficult to grasp,
especially if emitter modes number in the hundreds of thousands. (Suffix codes are given
more detailed treatment in Chapter IV).
Many TERF fields exist solely to link information in one portion of the file to
information in another segment of the file. The coding and linking picture grows more
complex within the following context. A TERF consists of emitter data partitioned into
subfiles represented in the S02 records. Each contributory source (Kilting, S&TI
Assessed, USNCSDB) may supply many different subfiles for a given emitter, each may
supply multiple versions of the same subfile, and sources may overlap in the subfiles they

12
 RECORD j RECORD NAME~ DESCRIPllJON .. ..
l ur TERE ffJE.tJ2 ~ .:
SOO . Oassification 1 one SOO per emitter
l Classilication 1 overall classification of emitter file l
•••••••uoouoooooooooooooouoo•!••ooooooooooOooooo•oooooooUoo~~oooooooouooeooo~ooooooooooooooooonouoooooooooooooo•oou•ooouoooooooooooooooooouoouoouooooooooooooooooooooooooooooooooooo•oooooooooooooooooooooooo:
l Retrieval Date 1 Kilting only, data of data extraction from NSA database 1

············soi··········t··············F:~«~;·N~~--1···~~~-·so-i·p~;··~~~trib~t~·n;··~;~~~--iK~~m········. ························j
................................1................ ~~~-~~!.:.~~~~-.L~~~--~~~~Y...~~-~-~-~-~!~.~~-~~--g!:~g!_ _ ..........................)
1 S&TI Code 1 assessed data only; 4 character code that identifies the l

. . . . . . . . . . . . . . . . i. . . . . . . . . . . . . . . . . . . . . . . . . L~~-cy-~~~.P..~~~i~!-~.f'?.r..~~ -~~~9!. ....................................................1

l SAE Code 1 Kilting only; 4 character code that identifies the agency
1 j responsible for the ELNOT
Multiple Source 1 assessed data only, date of the last full review of the
Review Date ~ assessed data file for a given emitter
. Date ofLast 1 Kilting only, date of last full review of the Kilting data
................................J..§!.~tfi.:~~~.f~z:~..!. P.:!~.f'?.r..~.g!_y~-~~-~E..................................................................................,
~ Parametric Update ~ date of most recent change to any S03, S04, or S05 1
l ~l~~ l
···········-------------------···r·--··-·······-------------------------------------~-------------········------········---------·············------------------------------------------···········- .. ·---···············--·~

S02 , Subfile Header ~ one S02 per parametric data subfile per contributory ~
. . . . . . . . . . . . . . . . !. . . . . . . . . . . . . . . . . . . . . . . . . l..~-~~~~;--~~~P-~~-§~~--~~~~ !.~~-~~Y ................................................J
!
! [Link] Tree ! subfile-codedbranch number
! Number~ !
································r··············s~:[Link]~--N~~~--r-~~~--(h~~g).~rili~--~~b"fii;~d~~~-ib;;;-~h·····················--···········1
l Subfi..le Code ~ 1 or 2 character code denotin~Z the subfile or subtree
••u•••••••••••••••••••••••••u•t•••••••••••••••••••••••••• •••••••••••••••••••••••!•••••••••••••••••••••••••••••••••••••••ouo uo•ooo••••••••••••••••••Q•••••••••••••••••••••••••••••••••••••••• ••••••••••••••••••••••••:
!
~ Technical Date ! Kilting only, date oflast change in any S03 record ~
~ ~

. . . . . . so3. . . . . .-r···...:p;:~~tri~··n;t;-t"·~~~. t~··;~;;Y··soi;~·;;;d~. P~;-P;;~~tri~--d:;t;··~~t;:y··. . . 1

l ~ per contributory source; multiple S03 records likely ~
................................l .................!..t:.~.~.!.flf.!!!:!?.~.r...L.~~-~~-~!!~P..~E~.~-~~--~~~-~r.?..~~~-~--~~~..P.~.~~!?.~.~~--!~~--.)
emitter
Suffix Code 1 1 or 2 character code assigned to help describe 1

~ modes; helps differentiate between multiple entries for ~

~ the same tree number; links related (dependent) j
! parameters 1

································-r·M."~~!f.!:.~~~!.?!..!.f~!!!:.~ .. ~...~~~~P.~~~-~-~~--~E~~~P.~~~~~~E.~~~~--~-P..~~~~~~-~-~~~---~
l Units l corresponds to units specified for parameters in ~
~ ~ parametric tree; for textual data, the format may be l
·······························-~·-······························ ·················J..~P-~~~-~~~~---··································································································.1l
j Lower/Upper Value j actual parametric data; for numeric data, lower/upper
l or Text ~ value is filled in (with same values if data is single- ~
................................L.................................................l...Y.~!~~2....................................................................................................................l
Figure 5. A Description of TERF Elements (continued into next page)

13
 RECORD RECORD NAME . llESGRIPIDlO.N .. .,
. =or TERE FIELD . · · .
l 803 Confidence Level assessed data only; specifies the analyst's confidence in
L. . . .~~~f-~............................................................
S&TI Code assessed data
--~~.P.~E~~-~-~~--~~---········ ..········································..······..·············""""""""""" 0

only; 3 character code that identifies the

agency responsible for the ELNOT
Reference Number links 803 to a reference (S04); 4 character code that
refers to a line in an S04; I st character in code denotes
the data source, R=Kilting, A=S&TI Assessed,
1 F=USNCSDB (differs from 80Icode)
r·································· ······e:;;;;~~~t·ii~-;"b~;·· ·--~d~-~t"·;~~~~-t~--~-ik~--~-~-·so·s·;··i 5i·~h:~~~ct~~--~--~d"~---···
l denotes the data source; C=Kilting, K=S&TI Assessed,
1 N=USNCSDB (differs from SO I and Reference Number
l codes)
r·································· ···············R.~;;~~-M~d~-- ·--~d~-t~-kdi~t~-ili~t"ili~-~~~~--~fth~-p~~~;ri~-&1;:·~~---···

1 mode, is a wartime reserve mode (WARM); also

~--································ .................................................. ·--~~~!~.~--~~.Y.~)..~~~~~--~-~~--~-~-~~-~-~~~!.......................
j Classification assessed data only;
L......................................................................................!!.~~~-~-~-~!~-~!f~~-~-~~~!1.~-~~~~?..!?.~.I~~P...~~~~---·
~ Releasability
assessed data only; 2 character code designating the
~ countries to which the data is releasable
Date ofLast date the last significant change was made to the data
Update
j Measurement Kilting only; + or - range if available, used with
~--································ ..........................:1.E~.lf:!..f!.o/ .. --~~~~~~--1?.~~~~~-~~-~~---····································································· .
Measurement Kilting only; same as the units field unless the accuracy
································· ............:1..~~-l!:!..f!.o/..l!..J?:~f!.... --~~--~~--~~-~!..~!?.!.~~--~~1?.~~-~-~~-~~--~~-~~--~~Y.............................
Intelligence Source Kilting only; I character code, denotes type of source
used to derive parametric data (ex. ELINT, non-ELINT)
Preferential Rating Kilting only; one digit code to signify the relative
importance of the data, the importance of obtaining the
data

r···---·····so4··---········ ...........ii~i~;~~~~·n;~.....;;;~-t~. ~-;~;;·s-o4··;~~~;d~··p-~;-~-~~~~-:p-~;-~;riti~;··ru~;·····

l required if a reference was specified in an 803 record;
L.....................................................................................P!'.~Y.!~~~--~-~~-~~--~~~--!~.-~!'!W!!.~~..~-~~£~-~~~~~~~---·---····
l Reference Number same as those specified in the S03 records
Reference Line sequential and contiguous; many lines of text may be
Number required to describe a reference for a given reference
number

Figure 5 cont' d. A Description of TERF Elements (cont' d into next page)

14
 RECORD f [Link]! DESCRlPT:ION ·
; or TERE FJELll ;
S04 Reference Text • assessed data format: textual description of the ~
cont'd parametric data reference followed by a formatted ~
classification/releasability line (refers to the S04) l
• Kilting format: reference text or document ~
number (document title), report date, producer, ~
.................................. :...................................................................?.!~~~i~~~-~~..~f~~--~~~~ .........................................................1
S05 ! Comments zero to many S05 records per parametric data item !
~ per sonrce; required if a comment was specified in ~
~ an S03; suffix table stored in "comment zero"; ~
i general emitter comments stored in "comment i
l one" i
. Comment Number same as those in S03 records .
··································r-················-c~;;;;~~t-ii~~-·· --~~~~-~i"·;;d··~~ti~~~~·;·~;;·i~;·~ft~;rt·;~;;·b~·-···1
~ Number required to describe a comment for a given comment ~
..................................l ........................................................~~!?.~~---········································································································j
Comment Text used to explain, describe, elaborate, and qualify
parametric data entries and modes
• assessed data format: includes a formatted
classification line for every comment; at least one
··························································································· ........... .?.!~~~-~~~~-~~..~~~}.~.E~~~~..f.~~..~~~..9.?.~~~··········
Figure 5 cont'd. A Description ofTERF Elements

15
supply to the EWIRDB. Each [Link] in turn may consist of many different parametric
data entries, and there may be many data entries for the same parameter as represented in
the 803 records. Finally, where applicable, parametric data links to source-specific
reference documentation and comments in the 804 and 805 records, respectively. And for
a given emitter, each source may require many 804 and 805 records. The effect of the
data merge, codes, and links with this framework is an elaborate and burdensome
presentation of parametric and associated data.

3. Summary
The EWIRDB represents a challenging database modeling problem The problem
stems from several factors, the foremost of which is the inherent complexity of the data.
Capturing the nature ofEW systems and signals is difficult.
Additionally, the parametric trees, the semantic basis of the EWIRDB, have been
designed and used primarily for database management, not as data modeling tools. To the
extent that the trees have been used to model parametric data, their hierarchical and
intrinsically arbitrary structure has proven too restrictive to accurately capture the
semantics of the data. The database user is therefore required to logically determine the
true nature of the data, if the need for interpretation is recognized at all.
Further, TERF-formatted EWIRDB output provides a comprehensive view of
emitter data, but does not .fill the semantic gap. While it incorporates the structure of the
parametric tree model and catalogues associated reference and commentary data, it cannot
be construed as a data model. Moreover, the TERF format introduces extras into the
data, such as reference codes, to link related pieces of information. The use of codes
throughout the file muddles the meaning of the data.
Finally, without system-supported semantics, the burden of EWIR data
interpretation is transferred to the user. This is not an easy task for the user; the EWIRDB
is difficult to comprehend because the nature and relationships of EW data are not
adequately modeled and are subject to coding. Because the EWIRDB is generally

16
described in terms of data implementation and not data semantics, there exists a
requirement for the development of a more meaningful, intuitive, and system-supported
design. The recent advance in object-oriented data modeling indicates that the object-
oriented alternative may prove useful in simplifying and clarifying the data semantics,
relationships, and formats of the EWIRDB.

C. THESIS OBJECTIVES

The primary objective of this thesis is to provide a new object-oriented design for a
sample portion of the EWIRDB. NAIC has identified the EWIRDB for our
experimentation in object-oriented database design. The object-oriented data model is
arguably the most semantically rich and flexible of all database design tools. The
effectiveness of the object-oriented data model, however, remains untested for any military
or warfare-related design of the scope of the EWIRDB.
The secondary objective is to use the object-oriented data definition language (0-
0DDL) as a design tool for the specification of the object-oriented EWIRDB. At present,
the 0-0DDL used in this thesis is the product of a larger thesis effort that produced an
object-oriented interface to the Multimodel and Multilingual Database System (M2DBS)
[7] at the Naval Postgraduate School (NPS). The 0-0DDL specification of a new
EWIRDB design is therefore a continuation of the NPS research. It will ultimately provide
an on-line object-oriented EWIRDB with which to demonstrate both the utility of the new
M 2DBS object-oriented interface, and the usefulness of the new object-oriented EWIRDB
design.

D. THE ORGANIZATION OF THE THESIS

In Chapter IT of the thesis, I address basic issues in the object-oriented database

development, within the context of conceptual design and logical design processes. In
Chapter m, I provide the design mechanisms of the object-oriented data model. In

17
Chapter IV, I further describe the tools of the proposed object-oriented design and present
the conceptual design of the EWIRDB. In Chapter V, I briefly describe the logical design
2
structures native to the M DBS and present the logical design. In Chapter VI, I

summarize my assessment of the new object-oriented EWIRDB.

18
,..-----------------------------------------------

ll. DESIGN CONCEPTS

Database design is a multiphase process. Each phase addresses a different aspect

of the design process and yields a separate design result or model. The partitioning of the
design process in this way guarantees the viability of each design phase as a distinct entity.
Moreover, it simplifies the entire process, because the complexity of the design problem is
also partitioned. Only certain aspects of the design need be addressed in each phase, and
the designer is exposed to the details of a given level only. The correct and thorough
design of one phase lends itself to the development of a subsequent phase.
In this chapter I addresses those aspects of database design that are central to this
thesis: the conceptual design and the logical design. These are the first phases in the
overall design process and are therefore elemental to the overall design. Together, the
conceptual and logical design phases take a proposed database from abstraction to
implementable form
The treatment here is generic; design mechanisms specific to object-oriented
database design are examined in Chapter ill.

A. THE CONCEPTUAL DESIGN

Much like an architect's sketch crystallizes the customer's architectural design

vision, the conceptual design captures the nature of data in a way that closely resembles
the database users' perception of data and the usage of data.
The fundamental goal of conceptual database design is thorough understanding of
the database through development of a conceptual schema. A tool known as the high-
level data model, also referred to as a semantic or conceptual data model, is used. A
high-level data model is intuitive, [Link], and comprehensive in its description of data. It
is the means by which a schema is developed to approximate the users' perception and
usage of the proposed database. To this end, the set of abstraction concepts underlying

19
the semantic data model are sufficiently expressive of data, simple in nature, unambiguous,
minimal in number, and nonoverlapping in meaning [2].

Devised within the framework of the high-level data mode~ the conceptual schema
thus characterizes the structure of data. The structure of the data is the sum and
substance of the database, encompassing data types, data relationships, and data
constraints. Since the conceptual design should be intuitive, its design notation is typically
associated with a diagrammatic representation of its modeling constructs. A diagram is a
simple, precise, high-leve~ and straightforward means of expressing the nature of data.
An essential quality of a conceptual schema is that it be independent of a specific
database management system (DBMS). A DBMS-independent semantic data model is
generic and free of any limitation or peculiarity imposed by a particular DBMS.
Consequently, the details of data implementation and physical data storage are suppressed
in the conceptual schema. Such detail is not useful in the development of a high-level
conceptual design. Accordingly, the conceptual schema cannot be used directly to
implement the database. This, however, is not disadvantageous. Rather, it highlights the
importance of the conceptual design and the value of the conceptual schema as a stable
description of the database. A stable database description - the conceptual schema -
remains unaltered by any modification to the underlying DBMS-dependent logical and
physical designs.
As the initial phase in the design effort, conceptual design is paramount in database
development; the entire process depends on the creation of a stable and correct conceptual
schema.

B. THE LOGICAL DESIGN

The architect's initial sketch, like the conceptual schema, is the foundation for all
subsequent design work. After capturing the essence of the customer's desires in the
sketch, the architect then addresses the specifics of the design layout. Decisions are made

20
based on the environment and the available materials. The outcome is a blueprint, a
specification for the construction of the design.
As the blueprint follows the sketch, the logical design in database development
follows the conceptual design. The logical design likewise yields a ''blueprint" of the
conceptual schema that accounts for the type of database system in which the database
will reside.
The logical design is equivalent to a mapping from conceptual schema to the data
model of the selected DBMS. The mapping is accomplished by the designer via the
DBMS's native data definition language (DDL}; the output DDL statements are
equivalent to a DBMS-readable specification of the conceptual schema. The end result of
logical design is thus a transformation of the database as proposed in the conceptual
design to a database in the DBMS-compatible form for eventual realization in the DBMS.

21
22
 ill. OBJECT-ORIENTED DESIGN CONCEPTS

Conceptual design and logical design, as descnl>ed in Chapter II, cast the
foundation of database development; a high-level data model provides the mechanisms
required to formulate these designs. Thus, both design processes proceed within the
framework of the chosen data model. The data model is therefore the starting point.
The definitive measure of a data model's effectiveness is it abstraction capability,
or the degree to which its design mechanisms capture ''real-world" semantics. Traditional
data models, including the hierarchical model, are limited with respect to their abstraction
capabilities. The EWIRDB hierarchical model is a prime example; and as detailed in
Chapter I, the model is :fundamentally deficient in its representation of EWIR data. For
traditional data models in general, the more complex the nature of the data, the greater the
semantic mismatch between the real-world data and its representation.
Object-oriented database design, a departure from traditional methods, seeks to
eliminate the semantic mismatch between real-world entities and their database
representations. The object-oriented data model (OODM) is the basis of the design
effort. The OODM is more semantically rich than the earlier models. Object-orientation
more closely parallels the way we observe the real-world. We are surrounded by objects:
computers, cars, roads, buildings, trees, people, animals, the atmosphere - the list of
objects is infinite. People tend to reason about real-world "objects" in terms of their
characteristics, both static and dynamic. A car, for instance, might be classified by its
make, model, and year, as well as by its performance in various driving conditions. We
also tend to apply different degrees of abstraction to the real-world entities that we
encounter. Depending on a person's point of view, a real-world "object" may be looked
upon as a single, indivisible unit, or as the composite of a number of component objects.
Returning to the car example, the typical car owner probably takes the view that a car is
an integral unit that provides a means of transportation. A car mechanic, on the other
hand, probably sees a car as the sum of its parts - parts that require maintenance and
replacement. The object-oriented approach is a close approximation to these human views

23
of the world. It is for this reason that object-oriented abstraction techniques are generally
considered to be more powerful than those of the traditional data models.
The OODM thus provides the design mechanisms with which to model diverse and
sophisticated applications in a natural way. In a larger sense, within the context of overall
database development, the object-oriented approach reflects a move toward an
''intelligent" DBMS that directly supports advanced data modeling. In such a system,
semantic correctness remains intact from abstraction to implementation. The burden of
translation is lifted from the user.
The object-oriented paradigm remains the focus of the active research. While
researchers and developers agree on the underlying principles, the exact nature and
direction of the object-oriented approach is at present an issue of debate. Consequently, a
final and irrefutable definition for the OODM has not yet been forwarded. Despite the
evolutionary condition ofthe OODM, the motivation to preserve a direct correspondence
between real-world entities and their database representations warrants its use. The
EWIRDB is an ideal candidate for object-oriented modeling.
In this chapter, I present the basic concepts of the OODM. Because the OODM
was developed with the ease of implementation in mind, some implementation issues are
also briefly addressed. These concepts lay the groundwork for an application of the
OODM, within the context of both conceptual and logical design, to a representative
portion ofEWIRDB data in Chapter IV.

A. OBJECTS

The object is the basic element of the OODM, and the component that populates
the database. An object corresponds to any entity in the real world: ideas, concepts,
people, events, places, physical structures, and time to name a few. The uniform
application of objects to model the spectrum of real-world entities simplifies the designer's
view of the real world [4] and infuses some consistency into the designer's task.

24
 In an object-oriented database management system (OODBMS), an object is
specified with a unique, system-generated marker called the object identifier (OlD). The
OID is immutable, or permanent and unchangeable [2]. This is an important aspect of the
OODM from a modeling and implementation point ofview. The use of OlD's effectively
decouples the object existence from the object value. An objects can therefore be
referenced via the OID, independent of an identifying value. Two objects with different
OlD's remain distinct, even if the two objects have the same values. In traditional models,
on the other hand, the identities of data items are value-based. The cumbersome task of
creating and managing unique identifiers (called keys traditionally) is therefore imposed on
the application programmer. Consequently, meaningful keys are likely long and non-
unique, and the management of key values is carried out external to the DBMS. The
effect is a degradation in database performance.
The hierarchical model of the EWIRDB is value-based and therefore subject to
these shortcomings. Specifically, data items referenced by application programs steer
through an identification scheme that includes the ELNOT and a burdensome hierarchical
labeling network. For a given ELNOT, or equivalently for a given emitter, a data record
is uniquely identified by a suffix code/tree number/source combination [1]. In an object-
oriented EWIRDB, a data object is uniquely identified by a system-maintained OID.
The OODM also provides for the creation of objects of arbitrary complexity [2].
The internal structure of objects is thus sufficiently adaptable to include all significant
information that describes an entity. This internal structure is referred to as the object's
state and behavior [3]. These aspects of the OODM are addressed in the following
sections.

1. Object State

An object is characterized by internal properties generally referred to as attributes.

The values of an object's attn'butes define the state of the object. Attn'bute values may
either be simple or complex.

25
 a. Simple Attributes
Simple attributes are those whose values are literals - character strings,
integers, floating-point numbers, and other primitive values. Typically, literals are not
considered as objects. For efficiency reasons, they are usually represented directly or are
self-identifying, and not associated with OlD's [4].

b. Complex Attributes and Relationships

Complex attributes are those whose values are composed of other objects
or groupings of values. There are three kinds of complex attributes: reference attributes,
collection attributes, and derived attributes [4]. The first two types provide for an

arbitrarily deep or recursive nesting of objects, where the state of an object is descn"bed by
attnlmtes whose values are objects whose values may be objects as well, and so on. A
natural representation, then, for the state of an object is a set of OlD's of the objects that
are the values of the attributes of the object [3].
Reference attributes are the means by which relationships between entities
are represented in the OODM. In taking on object values, reference attributes explicitly
refer to, or draw a relationship to, other entities. Specifically, in the logical design, -
reference attributes may be used to model binary and non-binary one-to-one, one-to-many,
and many-to-many relationships. A relationship may be modeled in one direction, such as
from an object A to an object B, where object A refers to object B but object B contains
no such reference to object A, or in both directions through the use the of an inverse
reference or inverse attribute [2]. An inverse reference facilitates traversal of the
relationship. The relationship is "visible" to each object; object A refers to object B and
object B refers to object A inversely. All the relationships in which a particular object type
participates are thus packaged within the object itself in the form of reference attributes.
In contrast, a complete inspection of the parametric trees and TERF output may be
required to ascertain the relationships that exist between particular parametric entities in
theEWIRDB.

26
 In implementation, reference attnlmtes provide an additional benefit. They
cannot be corrupted, i.e. inadvertently or maliciously changed: the integrity of
relationships and references is maintained by the OODBMS throughout all database
operations. Moreover, from a modeling perspective, because a reference attribute refers
to an OlD and not a value, the values encapsulated within the object to which the
reference attribute points may be changed with no effect on the OlD, and thus no effect to
the reference attnoute. [4] The use of reference attnoute has one possible shortcoming,
however. Beyond meaningful reference attribute names, references in the OODM do not
imply any special semantics. Basically, references can only convey the idea of an
association between entities.
Collection attnoutes encompass those characteristics of an object that are
descnoed by more than one value, or present a complex arrangement of values. These
values are stored in constructors such as lists, sets, or arrays. The value sets, or domains,
from which the values comprising the collection are taken may contain simple values or
references. For example, a collection attnoute may be a set of integers or a list of entities
that participate in a relationship with the object.
Object properties that are subject to frequent or regular modifications, such
as those that are time-based or date-based, are best modeled with derived attributes.
Derived attnoutes, as the name implies, are not stored explicitly. Rather, they are defined
via the execution of a particular procedure. A given value for a derived attnoute, and
therefore its storage, is temporary in nature.
Except for the brief introduction to derived attnoutes, the discussion of
object state to this point has dealt with the static characteristics, or structure of an object.
The next section addresses object characteristics that are dynamic in nature.

2. Object Behavior and Encapsulation

An important aspect of the OODM is its ability to incorporate the operations to be
applied to an object of a certain type into the object itself The procedures that modify or

27
return the state of an object in an OODBMS are called methods. The behavior of an
object is thus defined by the methods specified to act on it.
Methods are much like programs. They are written in a typical programming
language. A method consists of two parts: an external interface (or signature) and the
actual code to implement the method. The external interface defines the parameters
whereby an object interaction is recognized. It is the only legal means by which to invoke
the method. Typically, the execution of a method is accomplished via the message
passing [2]. U: for example, an object A sends a properly-parameterized message to an
object B in order to invoke a method in object B that returns the data stored in object B,
then the method of object B would return the data to requesting object A This concept of
restricting access or providing well-defined access to an object is referred to as
encapsulation. If strict encapsulation is enforced, then the object itself- its internal
structure and methods - is accessible only via the specified parameters. The only "user-
visible" portion of the object is the external interface; the data contained within the object
and the details of the method's implementation are completely hidden from external users.
Procedures that are visible outside the object are public methods. An object may also
encapsulate private methods, or those available only to the object itself In practice,
however, strict object encapsulation is too restrictive in any OODBMS [4]. In addition to
the public methods, attributes may be made visible as well
Encapsulation is a basic tenet in the OODM. Its benefit is straightforward:
encapsulation permits a change in the implementation of objects without forcing any
change in the external programs that use them As long as external interfaces remain the
same, the means to access and manipulate objects remain the same. Provided the external
interface remains intact,_ it follows that objects whose structure has been modified will
appear unchanged to the external world. Encapsulation is also important in introducing
the concept of object class.

28
B. OBJECT CLASSES

A database generally contains clusters of similar objects. Each cluster contains

objects that encapsulate the same structure and behavior, or attributes and methods. Just
as an abstract data type is the specification for a number of data structures in a typical
program, a class in the OODM is the specification for a number of similar objects in a
database. A database containing multiple clusters of similar objects would therefore be
comprised of several classes. And just as identically-formatted data structures may
contain different stored values, objects of similar structure and behavior, or objects in the
same class, may exlnoit different states.
These ideas are illustrated in Figure 6 which represents a small portion of data
maintained in a fictitious database at NPS. The THESIS class definition provides the
blueprint for creation of THESIS objects. This definition specifies three simple attributes
- title, author, and date of publication - and two methods - author bio and number
distributed. The method author bio returns the author's branch of service and warfare
specialty (data stored elsewhere in the fictitious database). The method number
distributed returns for a given thesis the number of copies distributed, a value that may be
subject to periodic change. The class THESIS is void of any actual data, but the objects
of class THESIS contain values for each specified attribute and invoked method. These
attnoute and_ method values differ from object to object; each object of class THESIS
therefore exlnoits a different state.
Classes are the basic building blocks of the object-oriented modeling. The concept
of class is therefore the basis of fundamental modeling mechanisms in the OODM. These
modeling mechanisms are the focus of this section. Some of these mechanisms are
considered to be core concepts in the model The semantically-important is-instance-of
relationship is one. The concept of generalization-and- specialization is another. Less-
widely-acknowledged object-oriented modeling concepts of aggregation and covering are
addressed as well.

29
 CLASS DEFINITION

INSTANTIATION

······························ ······························ ···'·························· ······························ ·······

attributes:
........A..!~.-~!~-~~8...!?.~:0.:~.~-----··j
J.J. Lee ~
1MAR96 .
··;~th~d;;···················································1

............~Y~ ..!.~.J?..~~~~!............. l
33 1

Figure 6. An Object Class and its Objects

30
 In addition to its value in the data modeling, the class concept has important and
favorable consequences in implementation. When viewed as the collections of their
instances rather than as the specifications of individual objects, classes form the logical
basis for the formulation of queries [5]. Further, because attribute and method
specifications common to objects of the same class are stored as a class object, there is no
need to replicate the common information in each object of the class. The effect has
considerable savings in storage space. Finally, the class concept provides a degree of
''type checking" throughout a class composition hierarchy [3]. The class composition
hierarchy is the direct result of the recursive nesting of objects as attribute values, an idea
introduced in section ID.A I. b. These objects are restricted in their values by their
respective class specifications. In this sense, the class is analogous to the traditional
notion of attribute domain. Just as the domain defines legal values or types for a given
attribute, the class defines the legal values for a particular object of that class. The class
thus provides a degree of type checking for an attribute whose value is an object.
With the OODM concepts of the object and the class as building blocks, the
following sections detail the design abstractions applied to the proposed object-oriented
design ofEWIRDB data.

1. Instantiation and Oassification

The class itself is an object, void of actual data. Thus, it is also termed the class
schema. It functions as the ''blueprint" with which to generate objects of the same class.
Viewed in this light, an object based on the blueprint of a given class can be thought of as
an instance or an occurrence of that class. Since a class contains the definition of a set of
objects, it is also an abstraction mechanism [5]. The class abstraction is rooted in the
complementary semantic modeling concepts of instantiation and the classification.
The instantiation is the process of creating objects within the parameters of a given
class schema. Classification is the inverse of instantiation. It is a process of systematically

31
assigning objects of similar structure and behavior to their respective object classes.
Classification permits the modeling of common characteristics that apply to all of the
objects in the class.
Because its a single blueprint from which many objects may be created and
catalogued, the class structure may be reused as required to instantiate many similar
objects. In Figure 6, the blueprint for the class THESIS is used three times to instantiate
each of the three THESIS objects shown. For this reason, instantiation and classification
are collectively considered to be the first reusability mechanism of object-oriented design.
Inheritance, addressed in the next section, is the second such mechanism.

2. Generalization and Specialization

Inheritance among classes produces class hierarchies that characterize the OODM
abstraction concepts of the generalization and the specialization. In an inheritance
hierarchy, a class referred to as the subclass inherits the structure and behavior of another
class called the superclass. In addition to its inherited characteristics, the subclass may
encapsulate attnoutes and/or methods not contained in the superclass. These distinct _
additions to the subclass differentiate it from the superclass and identifY the subclass as
worthy of a class status all its own. In the hierarchy, a subclass is viewed as a
specialization of its superclass. Likewise, a superclass can be perceived as the
generalization of those subclasses (from one to many) participating in the inheritance
hierarchy. Collectively, the concepts of generalization and specialization are equivalent to
the is-a-kind-of relationship. If an independent and unique subclass Xl inherits the
attributes and methods of a superclass X, then XI may be considered "a kind of' X.
A data hierarchy based on the inheritance is natural and well-defined, unlike
hierarchies based on arbitrary and coded tree structures, such as those found in the
EWIRDB. Inheritance emphasizes both the commonality and the uniqueness among
classes. Moreover, the implementation of an inheritance (i.e., a generalization and a
specialization) as a mapping from class to another class eliminates data duplication and

32
localizes the management of common data. It is for this last reason that inheritance is
touted the second reusability mechanism of object-oriented design.

3. Aggregation

The aggregation abstraction considers a composite object as the sum of its parts.
It is not restricted to an object as an aggregation of its attn"butes. The term is primarily
meant to represent an object as an aggregation of other objects, ie., a composite object as
the sum ofits component objects. The semantics are comparable to those of the is-a-part-
of relationship, where an entity is the grouping of its components.
The objects of component classes participating in the aggregation each have their
own state. Likewise, each object of the composite class exhibits its own state. But the
state of the composite object in a given aggregation is dependent upon the states of its
component objects. A composite object thus contains a "global" type of structure and
behavior that reflects the composite state of its component parts.
Simply drawing a relationship between an object and its aggregates is not
semantically sufficient; it does not capture the dependency between the composite object
and its components. From an implementation point of view, a relationship will not
maintain the integrity of the aggregation, or the interactions within the aggregation,
throughout all possible database operations. In particular, an operation on the composite
object should affect component objects. Conversely, an operation on a component object
should affect the composite object. The deletion of a composite object, for example,
should cause deletion of all components of the object. The aggregation and the notion of
a composite object can also be used as the basis for the clustering of data [4].
The aggregation abstraction is an important semantic concept in the OODM. It is
a design concept not found·in other models.

33
 4. Covering

The covering abstraction is accepted as a fundamental concept in the OODM

within the European community. It adds a dimension of flexibility in the modeling and
manipulation of data. The covering terminology is as follows: class X covers class Y if
every object in class X corresponds to a subset of objects in classY. These subsets ofY
need not partition Y; they are certain subsets of all the subsets generated for the objects of
Y. Mathematically, all the subsets of Y form the power set of Y, ie., P(Y). The

correspondence is a mapping f which determines for an object, x, from class X all the
objects, y's, of the subset f(x) from classY, such that f(x) = y for every one of those y's
Class X is referred to as the cover class and classY is called the member class. [6]
A covering relationship thus corresponds an object of one class to a subset of the
power set (the set of all subsets) of objects of another object class. It is therefore an
object-to-object-set mapping.
A simple and practical example involving a team and its players is useful in
descn"bing the covering relationship between two classes. In this example, the team class
covers the player class. The team's existence is entirely dependent on the participation of
its players, a type of existence dependency. While a team object has its own structure and
behavior, its real value is derived from its encapsulation of the nature of a particular set of
players that comprise the team Further, a team object may be operated on as a single
object or as a set of player objects. And as is generally the case in the real-world, the
elimination of a team (object) does not necessarily entail the demise of its players.
The covering is a valuable abstraction mechanism, specific to the OODM, that
accurately models entities of the real world.

34
 IV. A CONCEPTUAL OBJECT-ORIENTED EWIRDB

In this chapter, I apply the principles of the OODM, as presented in Chapter III, to
develop a genuine conceptual design for the EWIRDB. My intent is not to redefine the
kinds of data required to characterize an emitter's performance; the existing EWIRDB
data items have sound scientific roots. Nor do I attempt to address every existing data
element in the EWIRDB. My goal is to justify the proposition that the object-oriented
approach is feasible for the EWIRDB by providing a conceptual design of a representative
portion of the database - a portion that adequately reflects the nature of electronic warfare
data. Diagrams are used at every stage to codify the conceptual design. A description of
the conceptual design symbology must first be addressed.
The absence of a standardized OODM introduces some variation in its
diagrammatic representation. However, most of the symbology adopted in this thesis for
the conceptual design of the EWIRDB is commonly used. Possible exceptions are those
notations corresponding to abstractions such as covering and aggregation. Variations
aside, the consistent use of an adequately-expressive symbology is all that matters.
The symbology used in the conceptual design of the EWIRDB are shown in Figure
7. The inheritance abstraction as it appears in Figure 7 includes some detail not previously
addressed. The concept of overlapping inheritance stipulates that an object of the
superclass (generalization class) may be a member of more than one subclass of the
specialization. Disjoint inheritance states that an object of the superclass may be a
member of at most one subclass of the specialization. Regardless of the type, however,
each inheritance hierarchy in the conceptual design of the EWIRDB is a total
specialization. This idea states that every object of a superclass must be a member of
some subclass in the given inheritance hierarchy[2].

35
 CLASS

~( CLASS NAME ~)

··································------·---- - ... ·····-·······················--------····--- .... ·- .

OVERLAPPING //_..-DISJOINT INHERITANCE
INHERITANCE

SPECIALIZATION SPECIALIZATION
SPECIALIZATION CLASS NAME CLASS NAME
CLASS NAME

....................................................... .........
_ ...... ..... ---····································----
AGGREGATION

"-- ..................................................... .. -·"

COVERING '

,( ~':".... )---0 ~
----- --
'
.... _________ ...................................... .. .......... . .

Total ·-..,:
RELATIONSHIP
-Participation
_ _ Partial

·--------
·.
CLASS NAME CLASS NAME
Participation

Figure 7. Conceptual Object-Oriented Design Symbology

36
 The representation of relationships requires amplification as well. Figure 7
includes a description of the participation constraints in relationships between the objects
of participating classes. A total participation constraint indicates that for the class of
objects whose participation in a given relationship is total, the very existence of that class
of objects depends on its participation in the relationship. For example, in a relationship
between common entities such as transportation vehicles and license plates, the
participation oflicense plates would be total; license plates are unnecessary if there are no
vehicles to license. Ergo, the existence of license plates depends on the relationship
between cars and license plates. A partial participation constraint, in contrast, states that
all objects of a particular class need not participate in a given relationship. In a
relationship between married couples and children, for instance, not all married couples
have children. The participation of married couples in the relationship is therefore partial.
Participation constraints are an important aspect of conceptual modeling. They further
characterize the nature of data relationships.

A. A GLOBAL SCHEMA

The EWIRDB was descnoed earlier (Figure 1) as the administrative merging of

data from three contnoutory sources. Now, a global and object-oriented view of the
merged structure of the EWIRDB is provided in Figure 8 with the use of aggregation
semantics. The "big picture" object-oriented view of the EWIRDB in Figure 8 is largely
administrative. It may at first seem strange to proceed in this manner, to initially approach
the modeling task from an administrative rather than technical point of view, especially in
light of the technical nature of emitter data. But this approach is valid. As explained in
Chapter 1, the data items that descnoe an emitter retain the formatting particular to the
database from which they were contnouted. In a global view, source-specific groupings
of data items are assigned group-specific administrative labels. A design that proceeds
within an administrative context preserves these important associations.

37
 1

multiple source review multiple source review

date of last significant date date

Figure 8. The Conceptual Schema: A Global View

38
 As a result of the merging, the data items contnouted by each source to descnoe a

particular emitter may overlap. Moreover, each source may contribute multiple value
entries for a given data item But the identity of each data entry remains intact. Multiple
entries for a given data item are not ''fused" together to form a single EWJRDB entry.
Each data item remains separate and distinct, in a form that is suggestive of its source.
Approaching the conceptual design from an administrative bias thus ensures that the
overall structure of the database as a collection of emitter data from multiple sources will
be accurately reflected in the object-oriented schema.
In Figure 8, the aggregates KILTING EMITTER, S&TI EMITTER, and
USNCSDB EMITTER combine to form the composite EMITTER class of objects.
This aggregation precisely models the multi-source structure of the database. As the
composite, an EMITI'ER object represents the merging of all data for a given emitter.
Each aggregate, on the other hand, represents a source-specific portion of the data in the
composite. The aggregate KILTING EMil IER encapsulates Kilting technical data
contributed to the EWJRDB for a given emitter. The S&TI EMITTER aggregate
encapsulates the technical data contnouted from S&TI centers, and the USNCSDB
EMil IER aggregate encapsulates USNCSDB data for a given emitter.
With aggregation semantics, emitter parametric data may be reasoned about on
two levels of abstraction: in the composite, dealing with all available data, or on the
aggregate (component) leve~ where the data from a particular contributory source is
considered singularly. This adds a degree of fleXIoility in the manipulation of data that
may not be achievable in more conventional models. Further, categorizing emitter data by
source is appropriate because it allows the drawing of relationships between source-
specific administrative data and the aggregates themselves. In Figure 8, each aggregate
participates in a 1:1 relationship with an administrative-data class of objects; KILTING
EMil IER with KILTING ADMINISTRATIVE DATA; S&TI EMITI'ER with
S&TI ADMINISTRATIVE DATA; and USNCSDB EMITTER with USNCSDB
ADMINISTRATIVE DATA. The participation of each administrative data class in its

39
respective 1:1 relationship is total because the existence of an administrative data class
depends solely on the viability of the relationship. ~ for instance, the Kilting database

contnlmted no data to the EWIRDB for a given emitter, then for that given emitter, the
KILTING EMil I'ER class of objects would be undefined. In effect, KILTING

EMITTER would be non-existent, as would any relationship in which it participated. In

this example, the existence of the KILTING ADMINISTR ATIVE DATA class of
objects would be meaningless as well.
As mentioned in Chapter I, the formatting for S&TI and USNCSDB data are the
same. The attributes in the related administrative data classes are also the same. The
attribute values, however, are likely different between the two classes. This does not rule
out the possibility that some or all of the values may be identical But the posst'bility,
likely or not, that the attn'bute values may differ depending on the source necessitates the
appearance of the same attnbutes in both classes. For the same reason, the attn'butes
classification and releasability are duplicated in all three administrative data classes.
This seems to contradict object-orientation, wherein commonality is factored out among
similar classes to form a superclass. However, because the attnbute values may posstbly
be different from class to class, the common attnbutes, by virtue of their values, still
function to differentiate the classes. In these particular situations, the semantics of
generalization simply do not apply and the same attn'bute values may appear in each class.
The EWIRDB ADMINISTR ATIVE DATA class contains methods to extract
information from the source-specific classes in the schema. These methods retrieve
administrative data for a given emitter that in tum define the administrative state of all
merged emitter data. An object of the class EWIRDB ADMINISTR ATIVE DATA may
reflect data retrieved from more than one class of the schema. The method overall

classification returns the highest classification from among the source-specific

administrative data classes; it defines the classification or the composite classification for a
given emitter. Although not at present an attnbute explicitly accounted for in the
EWIRDB, the method overall releasability was included to satisfY the requirement that

40
" ... The releasability and handling caveats reflect a merger of the three sources... "[1] This
method, like the :first, returns the most stringent of the releasability instructions and thus
defines the releasability for the data of a given emitter when the data are considered in the
composite. The method parametric update searches through all the class attributes in
the database for a given emitter and returns the latest data update date. The effect is an
EWIRDB ADMINISTRATIVE DATA class that describes the composite EMITTER
class of objects. EWIRDB ADMINISTRATIVE DATA therefore participates in a 1:1
relationship with EWIR EMII'IER. And like the source-specific administrative data
classes, its participation in the relationship is total.
In Figure 8, the attnoute ELNOT in the EMITTER class is a kind of social
security number for emitters. It uniquely identifies an emitter, or more precisely, the signal
that is characteristic of an emitter. ELNOT is an important attnoute because it is the
primary means of emitter identification, and may often be the launch point for EWIRDB
queries. The attnoute color is an appropriate addition to EMfl'IER because it describes,
in general, an emitter's role in terms of friendly or hostile use. The choice of attnoute
values are "blue" for those emitters aboard US military platforms, ''blue/gray" for those
originally in US production that were legitimately transferred to Rest of World (ROW)
countries (non-US, non-Communist), "gray" for emitters aboard non-Communist country
platforms, and ''red" for emitters produced by Communist countries [guide]. The attnoute
color thus provides a big picture look at an emitter. Because it is not a source-specific
characteristic, it is best placed in the composite class.
The global, object-oriented view of the EWIRBD presented in Figure 8
incorporates all the data elements contained in the SOO and SOl records in the TERF
output. The S&TI Code found in SOl records (Figure 5) is included in both the S&TI
ADMINISTRATIVE DATA and USNCSDB ADMINISTRATIVE DATA classes. It
therefore applies to all assessed data encapsulated within an instantiation of S&TI
EMITTER or USNCSDB EMITTER. The duplicate S&TI Code entry found in S03
records (Figure 5) is removed from any further consideration.

41
 Object-orientation eliminates the need for S02 branch information. The S02 data
element Technical Date (Figure 5), however, specific to Kilting emitter data, is included
as a method in the KILTING ADMINISTRAT IVE DATA class. Similar to the method
parametric update, this method returns a date that indicates the latest update to emitter
data, but applies to smaller, more specific groups of data. These groups are collections of
generally related data elements, referred to in this thesis as logical groupings. Logical
groupings are introduced in section B and elaborated in section C.
The benefit of object-orientation is a more coherent and intuitive design. Now, for
a given emitter, administrative and technical emitter data are encapsulated within the
EMITTER· class via aggregation, relationships, and inheritance. To this point in the
conceptual design, particularly from the administrative point of view, the presentation of
data is clearer than that found in the parametric tree-TERF model

B. THEENDTTERSCHEMAS
The next step in the development of the conceptual design focuses on the technical
aspect of emitter data and addresses the data encapsulated within the classes KILTING
EMITTER, S&TIEMIIIER , and USNCSDB EMIIIER.
To reiterate, the conceptual designs presented in this section are based on portions
of the EWIRDB. These portions are sufficiently representative of the entire database and
accurately reflect the nature of EW data. Because the focus of this section is the overall
organization of emitter parametric data, the detail of object structure and behavior is
omitted. (Specific class attnoutes are provided in Chapter Vas part of the logical design.)
This does not, however, take away from the intended semantics, and the schematics reveal
the utility of the object-oriented approach in providing a unified and intuitive picture of
emitter parametric data.

42
 1. The Kilting Emitter Class
The overall configuration of the data encapsulated within the aggregate KILTING
EMil lER class is depicted in Figure 9. An emitter object is not descn'bed as the
composite of its component parts, ie., an aggregation. Modeled as an aggregation, the
analysis of complex EW emitters could then be one of a hardware-oriented divide-and-
conquer. An overall performance assessment could be made based on the intermediate
results obtained in the evaluation of the hardware components. But the hardware
components themselves are not central to the discussion ofEW. For the purposes of the
EWIRDB, hardware components are only important in that they have some effect on, or
participate in the generation of: a given signal. The signal itself is pivotal in the analysis -
not the hardware. This is reflected in the design shown in Figure 9. Rather than being
exposed hardware component by hardware component, the KILTING EMII'lER class
of objects is instead related to several logical groupings of data, all of which are signal-
based in their description of emitter performance.
KILTING EMil lER participates in a one to many relationship with
ANTENNA, a class that encapsulates a logical grouping of antenna-signal data. A single
emitter may contain one or more antennas, each of which may have a different function or
produce a different effect on a signal However, antenna hardware is not explicitly
addressed within the antenna-data grouping. Modeling the relationship between
KILTING EMil lER and ANTENNA as one-to-many is not intended to treat this
portion of EWIRDB data as hardware oriented, although this may be a collateral effect.
More important is the effect of any given antenna on an emitter's signal The one-to-many
relationship reflects the fact that that there may be multiple antennas, or multiple versions
of antenna data for a particular emitter, depending on the number of antennas and the
availability of information on each. The antenna data grouping is given more detailed
treatment in section C.l.

43
 ::
ANTENNA DATA
N

WARM DATA

~ ...................................... .
--------~~-------

..
..
~ ·•
·.. ~ ..................... -........ -............ --

Figure 9. The Conceptual Schema: Kilting Emitter Data

44
 :[Link] EMITTER participates in a one-to-many relationship with the class
SIGNAL, perhaps the most important grouping of data in identifying an emitter and its
signal signature. The one-to-many relationship indicates that an emitter's identifying
signal is subject to variation. A change in the configuration of the emitter's controls, for
example, causes a variation in the signal. Therefore, an emitter's signal may behave
differently, with respect to fundamental signal characteristics, depending on the
employment of the emitter. Signal characteristics are described in section C.2.
:[Link] EMil IER also participates in a one-to-many relationship with the
WARM (Wartime Reserve Mode) class, which encapsulates those signal characteristics
likely to be encountered only when an emitter is in a wartime reserve mode. A single
emitter may have from zero to many such special modes. Wartime reserve modes are
those emitter capabilities, dehoerately held in reserve, that differ from or exceed normal-
use capabilities. WARM's are used exclusively in emergency or wartime scenarios to
counter attempts to exploit the perceived weaknesses in an emitter's performance. A
sound assessment or a foreknowledge of the WARM's employed by an enemy can be a
huge advantage in the prosecution ofEW. WARM data is therefore an important aspect
of the EWIRDB.
To provide for a simplified diagrammatic layout, the WARM class is surrounded
by a circle to represent the existence of a disjoint inheritance hierarchy. WARM data is
examined more closely in section C.4.
Finally, :[Link] EMil IER objects have a one-to-one relationship with the
SUFFIX TABLE class of objects. The suffix table as it currently exists in the EWIRDB
descnoes complex emitter mode combinations in concise fashion. Knowledge of these
combinations allow EWIRDB analysts to establish emitter performance patterns and mode .
usage tendencies. The suffix table is thus an important tool that helps the analyst to
discriminate between signals and ultimately associate a signal to an emitter. It is examined
more closely in section C.5.

45
 2. The Association of an Emitter to its Signal

Associating a unique signal to its emitter is a difficult modeling problem, object-

oriented or otherwise. The association is characterized by an ELNOT that uniquely
identifies an emitter that is uniquely identified by its signal signature. (ELNOT is an
attnlmte encapsulated withln the EMIIIER class shown in Figure 8.) More precisely,
the ELNOT is "assigned to each noncommunications emission for collection guidance and
reporting purposes."[!] Thus, the uniqueness of the ELNOT, assigned to
noncommunications emissions, implies a one-to-one relationship from signal to emitter, or
equivalently from emitter to signal This modeling is easy to reason about in theory, but in
application, hard to achieve. In Figure 9, the general organization of the parametric data
describes an emitter by its signal attributes within the context of antenna-induced effects
(ANTENNA DATA), signal characteristics in general (SIGNAL), reserve modes
(WARM), and combinations of modes (SUFFIX TABLE). While this design provides a
comprehensive view of signal-based parametric data, the one-to-one nature of the
relationship between emitter and signal becomes obscured. Although the data are more
semantically meaningful when described within the logical groupings, the effect is a
partitioning of the data. Consequently, a relationship must be developed between the
emitter (KILTING EMII'I'ER) and each partition. Several relationships then exist to
descnbe the relationship between emitters and signals. Not all, however, are one-to-one;
KILTING EMITTER participates in a one-to-many relationship with ANTENNA
DATA, SIGNAL DATA, and WARM DATA. The end result is an association between
an emitter and its signal, but the uniqueness of the relationship is directly modeled only
through the use of the ELNOT. The ability of an emitter to vary its signal characteristics -
and effectively produce more than one signal - makes it more difficult to visualize the one-
to-one nature of the relationship between emitter and signal, and therefore between
ELNOT and emitter. The one-to-one relationship remains intact, but is perhaps more
identifiable because of the existence of the ELNOT.

46
 3. The S&TI and USNCSDB Emitter Oasses

As discussed in Chapter I, the S&TI community produces performance

assessments based on an exhaustive search of all available information. These assessments
are particularly useful in developing an understanding of an emitter's receiver capabilities.
USNCSDB data, derived from equipment specifications, also includes receiver
performance data. Similar in all other design aspects, the USNCSDB and S&TI
conceptual designs shown in Figures 10 and 11 are the same.
In contrast, the KILTING EMfl'IER schema in Figure 9 does not contain
receiver data because Kilting data reveals nothing about receiver performance. Kilting
data are obtained from the direct analysis and measurement of emitter signals following
signal intercept. An emitter's receiver, however, produces no obvious observable effect.
The class RECEIVER, which encapsulates the logical grouping of receiver data in both
Figures 10 and 11, is similar to the ANTENNA class in that the information it presents is
important in descn'bing the effect of hardware on any given signal. RECEIVER,
however, encapsulates data that tends to be more hardware-oriented. The receiver's
function is to accept a signal, process it, and then relay signal information to a display.
A receiver's manipulation of a signal is strictly internal and does not directly produce an
effect that is visible in the atmosphere. The internal function of receivers in processing
signal data is therefore best descn'bed within the context ofhardware components.
The one-to-many relationship between the emitter class and RECEIVER in
Figures 10 and 11 convey the idea that an emitter may consist of one or more receivers.
The receiver data grouping is given more detailed treatment in section C3.

47
 ANTENNA DATA

WARM DATA
SIGNAL DATA

N
..... ···································

Figure 10. The Conceptual Schema: S&TI Emitter Data

48
 ANTENNA DATA

SIGNAL DATA

.................................. ·<>··
N 1

\\\\
···················-----·-···------·----·---

Figure 11. The Conceptual Schema: USNCSDB Emitter Data

49
C. THE SCHEMAS WITHIN LOGICAL GROUPS

In this section I present a more detailed view of the data contained within the
logical data groupings descn"bed in the previous section. Logical groupings, like the
sub:files that currently exist in the EWIRD, encompass logically-related data elements. But
the schemas depicted in this section reinforce the notion that the OODM provides for data
semantics previously unachievable in the EWIRDB. Emphasis is placed on the schema
design; complete technical descriptions of each data class are provided in [8] and [9].
Supplemental information is provided in [10] and [11].

1. Antenna Data
Figure 12 is an enlargement of antenna-related signal data. It represents a
substantial improvement over the semantically limited hierarchical tree representation of
antenna data discussed in section I.B.l. b.
Specifically, an antenna may exhibit a polarization and a particular radiation
pattern, as descn'bed by the one-to-one relationship between ANTENNA and
POLARIZATION, and by the one-to-one relationship between ANTENNA and
RADIATION PATTERN. Two disjoint hierarchies branch out from the
POLARIZATION class. One addresses the orientation of the electromagnetic wave,
specializing the polarization as either linear or circular/elliptical. The other descn"bes the
variation of the polarization as either fixed or variable. Thus, using the tools of the
OODM, the four posSI"ble polarization combinations- fixed-linear, fixed-circular/elliptical,
variable-linear, variable-circular/elliptical - are captured intuitively in the schema. An

antenna's cross polarization characteristics are now correctly modeled in the one-to-one
relationship between POLARIZATION and CROSS POLARIZATION. No longer are
cross polarization characteristics confused with those that determine an antenna's design
wave orientation or its polarization variation properties. Moreover, access to data

50
 Ref..-ence from:
WARM Data (Fig 15)
PERIODIC

Ref..-ence from:
KILTINGEmitta- (Fig9)

s&TI Emitta- (Fig 10) : - - - - '

USNCSDB Emitta-(Fig 11)

Ref..-ence from:
WARM Data (Fig 15)

ElECTRONIC SCAN

Figure 12. The Conceptual Schema: Antenna Data Enlargement

51
concerning an antenna's polarization also guarantees access to data concerning the
antenna's cross polarization, via the relationship.
The same is now true for antenna data connected with the VARIABLE
POLARIZATION class. The classes ADAPTIVE POLARIZATION, MANUAL
POLARIZATION, and PERIODIC PROGRAMMED POLARIZATION in the
hierarchies are clearly specializations, or types of variable polarization. The class
POLARIZATION MODULATION, possibly mistaken for a type of variable
polarization in the parametric tree mode~ is instead related to, and therefore descriptive
of: VARIABLE POLARIZATION via the one-to-many relationship.
The remainder of Figure 12 provides a straightforward representation of other
aspects of an antenna's functionality. An antenna may radiate directionally or
omnidirectionally. If the antenna is direction~ then it is associated with one or more
scanning techniques. The antenna scan data is further refined within the specialization's
subordinate to the mechanical and electronic scan classes. In addition, an electronically
scanning antenna may be controlled by one or more scan programs, and employs a beam
formation method to effect its scanning movement. A directional antenna also performs a
tracking function, which may include simultaneous mechanical and electronic tracking.
Finally, the features of electronic scanning are largely determined by one or more
functional scan programs.
Figure 12 represents some of the salient aspects of antenna data in a way that is
understandable to both expert and novice. This depiction of antenna data, in the form of
the OODM, is clearly superior to that of the arbitrary tree model.

2. Signal Data

Figure 13 depicts an enlargement of the logical grouping of signal data and

addresses the complexities of signal transmission in a natural and intuitive way. The
information contained in this. grouping details fundamental signal characteristics.

52
 WARM Data (Fig 15)

cw
: REf.....,c:e from:

~~-- ..~--~~==~=-----~:KffiTING~ (Fig~

:[Link]:efrom: :s&TI~ (FlglO)
)wARMData (FlglS) ;USNCSDB~ (Flgll)

OT CONSTANT PIUIP

::R.c...mc:efrom:
;WARM Data (Fig 15)

( C PERIODIC MODULATION)
:R.c.....,c:e from:
lWARMData (FlglS)
:Ra.....,c:efrom:
~WARM Data (Fig 15)

RECURRENT
IN'IERVAL
SEQUENCES

Figure 13. The Conceptual Schema: Signal Data Enlargement

53
 Any given signal is generated with a certain power that is either constant or
variable in nature. The object-oriented representation exactly matches these semantics.
SIGNAL participates in a one-to-one relationship with TRANSMISSION POWER, the
generalization of the specialization classes, CONSTANT POWER and NOT
CONSTANT POWER. The SIGNAL class is the root of the inheritance hierarchy that
spawns the PULSED RF (Pulsed Radio Frequency) and CW (Continuous Wave)
specialization classes. PULSED RF is the basis of the conceptual schema in Figure 13; it
is the starting point in the modeling of basic signal characteristics such as pulse duration,
pulse amplitude, pulse repetition interval (PRI) and pulse group repetition interval (PGRI),
and frequency (RF). (CW signal characteristics are represented within the class CW but
are not examined any further.)
For a given occurrence of PULSED RF there exists a one-to-one relationship with
the classes PULSE DURATION, PULSE AMPLITUDE, PRJJPGRI, and RF LINE
STRUCTURE. These classes characterize in detail the nature of a given signal pulse.
PULSED RF is a generalization class in the inheritance hierarchy that refines the
description of a pulsed signal's carrier frequency. The basis of specialization is the
constancy of the carrier frequency. A given pulsed signal therefore belongs to either the
RF CONSTANT class or RF NOT CONSTANT class. A subordinate hierarchy rooted
at RF NOT CONSTANT further describes the nature of the variation in the carrier
frequency.
Objects in the classes PULSE DURATION and PULSE AMPLITUDE may be
static or variable, as indicated by the specialization classes PD MODULATED and PA
MODULATED, respectively. Both are single specializations. :U: for instance, an object
of the class PULSE DURATION is not modulated, then there is no information outside
of the class PULSE DURATION that is required to descnbe that object. If the intent is
to descnbe a modulated pulse duration, then additional or specialized data is required, and
an object of class PD MODULATED would be instantiated.

54
 Objects of the class PRIIPGRI belong to either the CONSTANT PRIIPGRI
specialization class or the NOT CONSTANT PRIIPGRI, depending on the pulse-to-
pulse changes in pulse interval A member of the NOT CONSTANT PRIIPGRI reflects
interval changes that are either discrete or continuous. The classes DISCRETE and
CONTINUOUS are themselves generalizations in overlapping inheritance hierarchies.
Additionally, a pulsed signal whose pulse repetition interval is not constant exln"bits the
characteristics of some type of interval scheduling control A one-to-one relationship
therefore exists between NOT CONSTANT PRIIPGRI and the class INTERVAL
SCHEDULING. An interval scheduling control induces one or more recurrent pulse
repetition intervals. The schema therefore includes a one-to-many relationship between
INTERVAL SCHEDULING CONTROL and the class RECURRENT INTERVALS.
The RECURRENT INTERVALS class is important in its description of recurrent
interval sequences; it may be thought of as a higher level abstraction for an arrangement of
interval sequences. Moreover, it becomes meaningless as an abstraction without the
existence of interval sequences. Viewed in this way, a mapping may be developed
between recurrent interval an recurrent interval sequences. In Figure 13 this mapping is
represented as a covering; cover class RECURRENT INTERVALS covers the member
class RECURRENT INTERVAL SEQUENCES.

3. Receiver Data

Aggregation semantics model the hardware-orientation of the receiver data. In

Figure 14, the class RECEIVER is the "outermost" composite in a nested aggregation
wherein some of a receiver's aggregates are themselves composites that are composed of
aggregates. Objects that belong to the classes IF PREAMPLIFIER and IF
AMPLIFIER, for example, are aggregates of objects of the class INTERMEDIATE
FREQUENCY SECTION. Objects of the class INTERMEDIATE FREQUENCY
SECTION are, in tum, aggregates of objects of the class RECEIVER.

55
 REfenncefrom:
KILTING Emitter (Fig 9)
S&TI Emlttlr (Fig 10)
USNCSDB Emitter (Fig 11)

(AMPLITUDE) (PHASE) (I&Q) DEIECI'OR

DE'IECTOR DEIECI'OR

~
l:::::..J

Figure 14. The Conceptual Schema: Receiver Data Enlargement

56
 Thus, RECEIVER represents the sum total of all components that function
together to perform the receiver task. More precisely, receiver functionality and
component functionality, not hardware, is the basis of the aggregation. The specifics of
the hardware is important only in drawing boundaries between functional sections of
components that are common to all receivers. And despite hardware differences, all
receivers may be modeled in this way because of a similar functionality. This is a logical
and natural representation of the data. The receiver portion of an emitter may now be
reasoned about in general terms as a singular unit and, or exposed in more detail as the
aggregation, or nested aggregation, of distinct functional sections.
Many of the actions performed by a receiver are described as either single pulse
processing or multiple pulse processing. These labels can be assigned to receiver
processes, within the setting of aggregation semantics, as shown in Figure 13. In the
schema, applicable object classes participate in one-to-one relationships with SINGLE
PULSE PROCESSING objects or MULTIPLE PULSE PROCESSING objects.
However, both the SINGLE PULSE PROCESSING and MULTIPLE PULSE
PROCESSING classes exist solely to provide the capability to access receiver-signal
information from a single pulse/multiple pulse processing bias. Their primary purpose is
navigational. These two classes are descriptive of receiver data in name alone.
Multiple one-to-one relationships originate from the SIGNAL PROCESSOR
SECTION class. The other participating classes - SPECIAL CAPABILITIES,
DOPPLER PROCESSING, INTEGRATION, MOVING TGT INDICATION, TGT
TRAC~G, and THRESHOLDINGffGT DETECTION - encapsulate data that
descn"be the functionality of a receiver's signal processor section. The choice to use
reference relationships instead of aggregation relationships is based on the composition of
the EWIRDB data. In general, as signal processing is addressed with an increasing level
of detail with respect to functionality, hardware differences among receivers tends to
become more pronounced. In other words, as the granularity of data increases, receivers
may still be described in terms of common functionality, but tend to be less alike in

57
hardware. Functionality is therefore less prone to be cast in the light of hardware as the
data become more detailed. The other classes are not so much parts of SIGNAL
PROCESSOR SECTION as they are descriptors of the types of actions performed in
that section. Aggregation semantics become less applicable; reference relationships better
model the nature of this interaction.

4. WARMData

The design of Figure 15 echoes previously introduced elements of the conceptual

schema. For example, the class POWER ECCM participates in a one-to-many
relationship with TRANSMISSION POWER from Figure 12. As will be found in the
logical design, this relationship indicates that a WARM mode affecting signal power, or an
object of the class POWER ECCM, is essentially a new instantiation of the class
TRANSMISSION POWER. WARM modes that are not variations of existing data
classes fall within the class OPERATIONAL ECCM.
The inheritance hierarchy in Figure 15 is disjoint; any given object of the WARM
class is a member of only one specialization class. However, an emitter may exhtoit
multiple WARM modes, as modeled in the one-to-many relationships between the classes
KILTING EMI'ITER and WARM, S&TI EMIIIER and WARM, and USNCSDB
EMil IER and WARM.
This approach to the modeling of WARM data does away with the need to
account for the Reserve Mode entry found in S03 records (Figure 5).

D. THEPARAME TRICDATAC LASS

As discussed in section ill.A l.b, complex attributes support objects as attnoute

values. Therefore, in the case of complex attnoutes, the ''type" of a given attribute is

58
 Reference to:
Reference to:
POLAIUZATION in Fig1IJe 12
'IRANSMI8SION POWER in Fig1IJe 13
-----------························
: ............. (...-,P;;,O""'WER"""'""'EC"""c'""M...---,) ( [Link] ............. ~

Reference ftom:
KILTING EMITTER (Figme9)
S&TIEMITTER (Figme10)
Reference to:
Reference to: SCAN in Fig1IJe 12
PULSED RF in Fig1IJe 13

ANIENNA SCAN
ECCM

OPERATIONAL )
ECCM

Reference to:
PRJIPGBI in Fig1IJe 13 PULSEDURATIONinFigute 13
PULSE AMPLITUDE in Fig1IJe 13

(P<UED =:""").... u •••••••••• uuuu. uuu

Figure 15. The Conceptual Schema: WARM Data Enlargement

59
equivalent to the particular object class from which that object value was instantiated.
Further, complex attributes may reflect an arbitrarily deep or recursive nesting of objects.
All complex attributes in the object-oriented design ofEWIRDB, regardless of the
depth of nesting, ultimately lead to objects of the class PARAMETRIC DATA, the focus
of this section. The PARAMETRIC DATA class itself exhibits a nesting of objects that
incorporates the semantically-useful data elements of the S03, S04, and S05 records.
The PARAMETRIC DATA class and the data encapsulated therein is depicted in
Figure 16. TEXTUAL DATA and NUMERIC DATA are specializations of
PARAMETRIC DATA, and intuitively indicate whether the parametric data entry for a
given attnoute is text-based or numerical. Numerical parametric data are either single-
valued or range-valued as expressed in the specialization classes SPECIFIC VALUE and
VALUE RANGE.
In the EWIRDB, comments are used to further characterize parametric data
values. PARAMETRIC DATA thus participates in one-to-one relationship with the
class DATA COMMENT. The participation of DATA COMMENT in the relationship
is total; a parametric data entry must first exist before a corresponding comment can be
made, but not all parametric data entries must be commented. If a parameter is assessed,
then a related comment must also include the comment classification. This is depicted in
the specialization class ASSESSED DATA COMMENT. Comment data and the
inheritance hierarchy directly subordinate to the PARAMETRIC DATA class are
enclosed within the dotted line in Figure 16. Together they constitute the core of
EWIRDB parametric data.
On the global scale, each emitter is linked to emitter-specific administrative data;
on a smaller scale, each class attribute is associated with the attribute-specific
administrative data associated with the S03, S04, and S05 records. The attnoute-specific
administrative data identifies data references and highlights important descriptive
information. As indicated in Figure 15, the format of this data is source-dependent.
ORIGINAL SOURCE DOCUMENTATION includes those attributes common to both

60
 ... --···························································································----....
1
....----t. attribute: ...............................................
i suffix code
: ~ . f .

r .. au:=~t·t~;tt·······1 '

. ASS,ESSED.-
J)ATA ¢[Link]
attribute:
comment attribute: !:
' : . . . . .E.P.P.~.i.~!~~::::::::::r
classification

··. ·..
N

M
---···-·:::?lower value

.....
_ ~
?

·------·············· ----·-···············································-------·············-----·
_...... ---
1

report classification

i
rattributes: do~~~t"~~b~-----. ............ . ~ attributes: ......................................................
,...
L. .....................~~~~~~-~~~---····················
r·····················d~-~~eiii"iiii~······················

[:::::::::::::::::::::::::!.~~~:~!~::::::::::::::::::::::::::
L.........................J?!~.~~~---·························
l.................!~~~~~-~.C?.~~~---···············

.. ...............................................-: attributes:
..............~~-~~~~-~£~~~Y...............J confidence level
........~~~~~~-~~~~-~Y..~~........J classification
..................~~~~~~-~~-~~P!~.~.................l releasibility
...................P!.~~~!.~~L~~~.L ...............J
Figure 16. The Conceptual Schema: Parametric Data

61
 formats, report classification and report releasability. Formatting distinctions are made
within the specialization classes ASSESSED REFERENCE and OBSERVED
REFERENCE. Attribute values are further characterized in the DATA DESCRIPTION
class by date of last update. ( The method parametric update date in the class
EWIRDB ADMINISTRATIVE DATA (Figure 9) accesses date of last update
information throughout the database and returns the most recent value for a given
emitter.) Source-dependent characteristics that generally describe the soundness and
accuracy of a given attn"bute value are addressed in the specialization classes ASSESSED
DATA and OBSERVED DATA.
Two methods are specified in the PARAMETRIC DATA class: return all data
and return parametric data. For a given attribute, return all data will reply with all
available data - the actual parametric data as well as the associated administrative data.
return parametric data will yield only the data enclosed within the dotted line in Figure
15 for a given attribute. One attn"bute is specified as well, suffiX code, a label for the
given attribute as it appears in the suffix table.
Thus, all useful data items from the S03, S04, and S05 records, with the exception
of suffix table information, are nested within the PARAMETRIC DATA class of Figure
. 15. Object-orientation eliminates the need for many previously maintained data items
listed in Figure 5. Tree Number, which provides indexing into the parametric tree is no
longer required. Linking-type entries related to the format of the output file - Reference
Number (S03), Comment Number (S03), Reference Number (S04), Reference Line
Number, Comment Number (S05), and Comment Line Number - are eliminated. Finally,
the entry Measurement Name (S03) is replaced by the attn"bute name itself.
At this point, all meaningful data entries of the TERF have been integrated into
one comprehensive, encapsulated model.

62
E. SUFFIX CODING AND THE SUFFIX TABLE

EWIRDB suffix-coded data and the suffix table representation of data comprise
the most difficult modeling task in the conceptual design. Suffix coding is incorporated
within the EWIRDB to describe the vast array of mode combinations an emitter may
exhibit. In effect, suffix-coding links together the parametric values that characterize
known or suspected emitter usage. A particular combination of parametric values defines
a given mode; suffix coding and suffix table thus provide the means for establishing
relationships between parametric values throughout the database. (A comprehensive
review of suffix coding and the suffix table is provided in [ 1]. )
Herein lies the complexity in modeling modal relationships. Parametric values are
synonymous with attn'bute values. The attributes whose values describe a given mode are
likely interspersed throughout the many classes in the schema. The relationships defined
by suffix coding and the suffix table therefore describe associations between attributes --
not classes. An additional complication is the possibility of multiple values (multiple
instantiations of the object that contains the attribute) each for a given attribute. Modeling
modal (attnbute) relationships is difficult because neither the OODM, nor any other data
model, explicitly supports such a capability. From a modeling perspective, the problem of
representing modal relationships such as those found in the suffix table reduces to problem
of representing attribute-to-attn'bute relationships and attn'bute-to-attnbute combinations.
Upgrading each attnbute to a class is an ineffective solution. Related attn'butes are
grouped into classes for the purpose of collectively descn'bing the characteristics of a
particular set of objects. The transformation of attribute to class obscures these semantics;
each attribute instead becomes a reference within a given class. Moreover, the problem of
modeling combinations remains unsolved. There exists no "built-in" OODM mechanism
for the purpose of defining combinations of objects, not to mention attributes, throughout
a schema.
The process of defining modal combinations, regardless of the modeling tool used,
is formidable in the realization that an emitter could likely exln'bit hundreds of thousands

63
of modes. Object-orientation does not appear to simplify this task. Despite its
dependence on an artificial labeling system and a non-intuitive table representation, suffix
coding has proven to be effective in this combination-oriented modeling. Moreover, it
helps to link signal signatures to emitters. At present, I am unable to offer an easier or
more viable modeling alternative. The current methodology is therefore incorporated into
the object-oriented conceptual design.
The conceptual schema includes a suffix code entry for every attribute throughout
the schema; a suffix code entry can be made for every attnoute in each instantiation of the
object to which the attnoute belongs. This provides for the same modeling :[Link] as
exists in the current model: the binding together of related parameters, the labeling of
multiple values for a given attnoute, and the inclusion of suffix-coded data within the
SUFFIX TABLE class of objects (Figures 9, 10, 11) to develop modal combinations.
SUFFIX TABLE objects would also contain a method, expand table (not shown), to
return all combinations represented in the suffix-coded data table.
In the object-oriented design, the use of the special suffix codes is no longer useful.
The semantics of the special suffix code,++, used to indicate that a particular parametric
value is present in all modes, may be addressed via comment in the DATA COMMENT
class (Figure 15). The special code,//, applies specifically to the parametric tree structure
and indicates that a given value pertains to all modes described within the subtree rooted
at the branch containing the special code. Such semantics are implicit in inheritance and
aggregation hierarchies, and may be explicitly addressed via comment.
This completes the conceptual design phase. The next stage in the overall design
process is the logical design, addressed in Chapter V.

64
 V. A LOGICAL OBJECT-ORIENTED EWIRDB
2
The 0-0DDL native to the M DBS in the NPS Laboratory for Database Systems
Research provides the structure of the logical design presented in this chapter. The 0-
0DDL, designed and specified in [12], thus provides the means to convert the conceptual
2
database as proposed in Chapter IV into an M DBS-compatible representation.
2
Still in its first phase of development, the object-oriented intetface to the M DBS
is functional but does not yet support all aspects of the object-oriented paradigm. To
2
date, methods and the aggregation abstraction are not imp1ementable on the M DBS.
Therefore, in the logical design, aggregation will be represented via relationships, and
methods will not be addressed.
It is not necessary to address all aspects of the conceptual schema in the logical
2
design to demonstrate the operation of the M DBS object-oriented interface in handling
EWIRDB data. To this end, I address a representative portion of the conceptual schema
in developing the logical design. The subsequent implementation of the logical schema on
2
the M DBS is a continuation of the work in this thesis, and is addressed in [13,
unpublished]. The final result of this combined effort will be an on-line object-oriented
2
EWIRDB with which to demonstrate both the utility of the new M DBS object-oriented
intetface, and the use:fu1ness of the new object-oriented EWIRDB design.
The 0-0DDL logical design constructs are reproduced in Figures 17 through 20.
Refer to [12] for a comprehensive discussion of the 0-0DDL specification.
In Figure 17, "attnlmte type" refers to the traditional notion of attribute domain.
As descnoed earlier in sections m.A La and b, the domain or type of an attribute may be
simple, characterized by literal attribute values, or the type may be complex, characterized
by object attribute values. Complex attributes can therefore exhibit an arbitrarily deep
nesting of objects. Whereas a simple attnoute may be of type "character" or 'mteger", the
type of a complex (or reference) attnoute is a class. The class defines the legal attn"bute
values (object values) for the given attribute.

65
 Figures 18 and 19 contain the specifications for the inheritance and covering
abstractions. In Figure 20, one-to-many and many-to-many relationships are addressed.
One-to-many (1:N) relationships between object classes are represented via the set_of
construct. set_of appears within the class on the "1" side ofthe relationship; an attnl>ute
that references the class on the "1" side of the relationship appears within the class on the
''N'' side of the relationship. Many-to-many (N:M) relationships are represented with the
set_of (N side) and inverse_of (M side) constructs. One-to-one (1:1) relationships are
represented directly through use of reference attributes. The classes in the 1: 1 relationship
each contain an attnl>ute whose type is that of the class to which it is associated via the
1: 1 relationship.

Oass Class_name{
attribute_type1 attribute_name1;
attribute_type2 attnl>ute_name2;

attnl>ute_typen attnl>ute_namen
};

Figure 17. The 0-0DDL Oass Specification

Class Class_name_Xl: inherit Class_name_X{

attnl>ute_type1 attnl>ute_name 1;
attnl>ute_typ~ attnl>ute_name2;

attnl>ute_typen attribute_namen
};

Figure 18. The 0-0DDL Inheritance Specification

66
 Oass Class_name_Xl: cover Class_name_X{
attribute_type1 attribute_name1;
attribute_type2 attn'bute_name2;

attribute_typen attribute_namen
};

Figgie 19. The 0-0DDL Cover Specification

set_of Class_name attribute_name;

inverse- of Class- [Link]'bute- name attn'bute- name;

Figure 20. The 0-0DDL Set_of and Inverse_of Specifications

The logical design incorporates the 0-0DDL constructs as outlined in Figures 21

through 29. Because all complex attn'butes in the object-oriented design of EWIRDB,
ultimately lead to objects of type PARAMETRIC DATA (section IV.D), the logical
design begins with the 0-0DDL representation of PARAMETRIC DATA in Figure 21.
The design then proceeds with the classes EMII'IER (Figure 22), KILTING
EMil IER and KILTING ADMINISTRATIVE DATA (Figure 23), ANTENNA
(Figure 24), SIGNAL (Figure 25), RECEIVER (Figure 26), WARM (Figure 27),
SUFFIX TABLE (Figure 28) and S&TI EMITTER and S&TI ADMINISTRATIVE
DATA (Figure 29).

67
 class Parametric_Data{
char* suffix code;
Data Comment comments;
Data_Descript description;
set_of Orig_Src_Doc; references;
};

class Textual_Data: inheritParametric_Data {

char* text;
};

class Numeric_Data : inherit Parametric_Data {

char* units;
};

class Speci.fic_Value: inheritNumeric_Data{

char* value;
};

class Value_Range: inheritNumeric_Data{

char* upper_value;
char* lower_value;
};

class Data_Comment {
char* comment_text;
Parametric Data parametric_data;
};

class Assess_Comment : inherit Data_Comment {

char* com classif;
};

Figure 21. The Logical Design: DDL Implementation of the

PARAMETRIC DATA Class ( cont' d into next page)

68
 class Data_Descrip {
char* last_update;
Parametric Data para_data;
};

class Assessed_Data : inherit Data_Descrip{

char* confidence level;
char* classification;
char* releasability;
};

class Observed_Data: inheritData_Descrip{

char* meas_accuracy;
char* meas_ace_units;
char* intel_source;
int prefer_rating;
};

class Orig_Src_Doc {
char* rpt_classif;
char* rpt_release;
inverse_of Parametric_Data.references p_data;
};

class Assessed_Ref: inherit Orig_Src_!Joe {

char* reference_text;
};

class Observed_Ref: inherit Orig_Src_Doc {

char* document_number;
char* document_title;
char* report_date;
char* producer;
char* report_classification;
};

Figure 21. (cont'd) The Logical Design: DDL Implementation of

the PARAMETRIC DATA Oass

69
 class Emitter{
char* e1not;
char* color;
Kilting Emitter kilting_data;
S&TI Emitter s- and-ti-data;
};

Figure 22. The Logical Design: DDL Implementation of the

EMITTER Class

class Kilting Emitter{

char* technical_date;
Kilting_Admin k_admin_data;
set_of Antenna antenna_data;
set_of Signal signal_data;
set_of Receiver receiver_data;
set_of WARM war_res_modes;
Suffix_Table modes;
Parametric Data weapon_system;
Parametric Data function;
Parametric Data platform;
Emitter general_data;
};

class Kilting_ftdmin{
char* nsa_date;
char* sae_code;
char* date_sig_change;
char* kclassification;
char* kreleasability;
};

Figure 23. The Logical Design: DDL Implementation of the

KILTING EMil IER and KILTING
ADMINISTRATIVE DATA Classes

70
 class Antenna{
Parametric Data antenna_type;
Parametric Data antenna_function;
Parametric Data horizontal_dimension;
Parametric Data vertical_dimension;
Polarization ant_polarization;
Radiation Pattern ant rad char;
Kilting_Emitter kilt_emitter;
};

class Polarization{
Cross Polarization cross_pol_char;
Antenna antenna;
};

class Cross_Polarization{
Parametric Data patt_pk_offset;
Parametric Data patt_pk_resp;
Polarization polarization; };

class Linear Polarization : inherit Polarization{

Parametric Data major_axis_tilt_angle;

};

class Circ_or_Ellipt_Polarization: inherit Polarization{

Parametric Data sense;
Parametric Data axial_ratio;
};

Figure 24. The Logical Design: DDL Implementation of the

ANTENNA Oass ( cont' d into next page)

71
 class Radiation_Pattern{
Parametric Data antenna_gain;
Antenna ant;
};

class Directional_Ant : inherit Radiation_Pattern {

Parametric Data beamwidth az;
Parametric Data beamwidth el;
Parametric Data first_ sidelobe_lvl_az;
Parametric Data first_ sidelobe_lvl_el;
set_of Scan scanning_char;
set_of Track tracking_char;
};

class Omnidirectional : inherit Radiation_Pattern{

Parametric Data
elevation_coverage_angle;
};

class Scan{
Parametric Data sample_avg_time;
Parametric Data SNR_threshold;
Parametric Data plane_of_scan;
Directional Ant dir antenna;
};

class Mechanical_Scan : inherit Scan{

Parametric Data type_change;
Parametric Data scan_function;
};

class Circular: inheritMechanical_Scan{

Parametric Data cperiod_limits;
};

Figure 24. (cont'd) The Logical Design: DDL Implementation of

the ANTENNA Oass (cont'd into next page)

72
 class Sector: inheritMechanical_Scan{
Parametric Data sector_type;
Parametric Data speriod_limits;
Parametric Data sector- width- az;
Parametric Data sector_width_el;
};

class Track{
Parametric Data plane_of_scan;
Directional Ant clirect_ant;
};

class Mech_Tracking : inherit Track{

Parametric Data
auto_track_max_rate_az;
Parametric Data
auto_track_max_rate_el;
};

Figure 24. ( cont' d) The Logical Design: DDL Implementation of

the ANTENNA Class

73
class Signal{
Trans Power signal~wr;
Kilting_Emitter k_emitter;
};

class Trans_Power{
Parametric Data line_loss_on_tx;
Parametric Data pk~wr_ eff_rad;
Parametric Data pk~wr_at_trans;
Signal signal;
};

class Constant_Power : inherit Transmission_Power{

Parametric Data time_to_switch;
};

class Not_ Constant_Power : inherit Transmission_Power{

Parametric Data max_rate_of_change;
};

class Pulsed_RF : inherit Signal{

RF- Line- Structure coherence;
Pulse Duration pulse_)ength;
PRIIPGRI pulse_groups;
};

class RF_Line_Structure {
Parametric Data 3_db_spec_width;
Parametric Data trans_type;
Pulsed RF rf~ulse;
};

Figure 25. The Logical Design: DDL Implementation of the

SIGNAL Oass (cont' d into next page)

74
 class Pulse_Duration{
Parametric Data pulse_dur_lim;
Parametric Data pd_most_prob;
Pulsed RF pulse;
};

class PD_Modulated : inherit Pulse_Duration{

Parametric Data dev_limits;
Parametric Data modulation rate;
};

class RF_Constant : inherit Pulsed_RF{

Parametric Data rf limits·
- '
Parametric Data most_prob_rf;
};

class RF_Not_Constant: inheritPulsed_RF{

};

classMod_on_Pulse: inheritRF_Not_constant{
Parametric Data rf_mod_change;
};

class PMOP: inheritMod_on_Pulse{

Parametric Data rf limits·
- '
Parametric Data phase_shift;
};

class FMOP: inheritMod_on_Pulse{

Parametric Data fmop _rf_limits;
Parametric Data :freq_excursion;
};

Figure 25. (cont'd) The Logical Design: DDL Implementation of

the SIGNAL Oass (cont'd into next page)

75
 class Pulsed_Agility : inherit RF_Not_constant{
Parametric Data agil_func_ corr;
Parametric Data mod waveform;
};

class Cont_Agility : inherit Pulsed_Agility{

Parametric Data rf limits·
- '
};

class Disc_Agility : inherit Pulsed_Agility{

Parametric Data rf- limits·'
Parametric Data no_disc_steps;
};

class PRJ{
Parametric Data meas_bandwidth;
Pulsed RF rf:
'
};

class Not_Const_PRI: inherit PRJ{

Parametric Data modulation_type;
lntvl Sked interval_cntrl;
};

class Intvl_Sked{
Parametric Data duty_cycle;
set_of Recurrent_Intvl intervals;
};

Figure 25. ( cont' d) The Logical Design: DDL Implementation of

the SIGNAL Oass

76
 class Recurrent_Intvl{
Parametric Data nbr_ dscrete_int;
Jntvl Sked sked_control;
};

class Recur_Intvl_Seq : cove r Recurrent_lntvl{

Parametric_Data sequence_I;
};

Figu re 25. ( cont' d) The Logi cal Desig n: DDL Impl emen
tatio n of
the SIGN AL Class

class Receiver{
Parametric Data receiver_type;
Sig_Proc_Sect sig_processor;
A_D_Conv_Sect a_d_section;
S&Tl_Emitter s_emitter;
};

class Sig_Proc_Sect {
Doppler_Processing dop_ proc;
Receiver receiver;
};

class Doppler_Processing {
Parametric Data coh_proc_intrvl;
Parametric Data pulses_in_cpi;
Sig_Proc_Sect proce ssor
};

Figu re 26. The Logic al Desig n: DDL Impl emen tatio n

of the
REC EIVE R Class (cont 'd into next page)

77
-

class Multiple_Pulse_Processing {
Doppler_Processing mp_ dop_proc;
};

classA_D_Conv_Sect {
Parametric Data a_sample_period;
Parametric Data conv_trig_meth;
Receiver rcvr;
};

class Single_Pulse_Processing{
A-D-Convr- Sect a_d_converter;
Pulse_Compression pulse_compress;
};

class Pulse_Compression{
Parametric Data type_of_coding;
Parametric Data time_band_prod;
Sig_Pulse_?roc single_pulse;
};

Figure 26. The Logical Design: DDL Implementation of the

RECEIVER Class

78
 class WARM{
char* prob_code;
Kilting_Emitter kilt_emit;
};

class Power_ECCM: inherit WARM{

set_of Trans_Power res_pwr_mode;

};

class Polar_ECCM: inherit WARM{

set_of Polarization res_polar_mode;
};

class Ant_Scan_ECCM: inherit WARM{

set_of Scan res_scan_mode;
};

class Sig_Shape_ECCM: inherit WARM{

set_of Pulse_Duration res_pd_mode;
};

class RF_ECCM: inherit WARM{

set_of Pulsed_RF res_rf_mode;
};

Figure 27. The Logical Design: DDL Implementation of the

WARM Class

79
 class Suffix_Table{
char* modematrix;
};

Figure 28. The Logical Design: DDL Implementat ion of the

SUFFIX TABLE Class

class S&TI_Emitter{

S&TI Admin k_ admin_data;

set_of Antenna antenna_data;
set_of Signal signal_data;
set_of Receiver receiver_data;
set_of WARM war_res_modes;
Suffix_Table modes;
Parametric Data weapon_system;
Parametric Data function;
Parametric Data platform;
Emitter general_data;
};

class S&TI_Admin {
char* s&ti code;
char* mult_src_review;
char* sclassification;
char* sreleasability;
};

Figure 29. The Logical Design: DDL Implementat ion of the

S&TIENDTTERandS&TIAD~TRA1TVE
DATA Classes

80
 The effect of the object-oriented logical design is profound. Now, all available
data for a given emitter, both technical and administrative, is contained within an object of
the class EMITIER. This effect is achieved via the nesting of objects within the
framework of relationships, inheritances, and a covering.
EMil lER contains complex (reference) attnlmtes (object values) of type
PARAMETRIC DATA, and also contams references to source-specific emitter data
objects of type KILTING EMil I'ER and S&Tl EMITTER. KILTING EMITTER
and S&Tl EMITTER objects likewise contam attnoutes of type PARAMETRIC
DATA, and attributes that reference analogous administrative data objects. These
administrative data objects contam simple-valued, source-specific attnoutes corresponding
to SOO, SOl, and S02 record data. The KILTING EMITIER and S&Tl EMITTER
objects additionally encapsulate antenna data, signal data, receiver data, WARM data, and
suffix table objects. (Suffix table objects correspond to S05 record data). The attributes
within each ofthese objects, in turn, are either of type PARAMETRIC DATA, or exlnoit
a nesting of objects that ultimately lead to attributes oftype PARAMETRIC DATA.
. Finally, attnoutes of type PARAMETRIC DATA exlnoit a nesting of objects that
leads to simple parametric values and simple parametric-value-related administrative data.
All such information corresponds to S03 record data.
The overall result is a cohesive, encapsulated, and comprehensive logical schema
ofEWIRDB data.

81
82
 VI. CONCLUSION

The EWIRDB is a vitally important instrument of EW and EW research and

development, containing up-to-date and mission-critical performance data on the EW
systems of friendly and hostile forces. Its utilization in the areas of battle planning and
EW research helps to shape the outcome of war. The usefu1ness of the EWIRDB,
however, is hampered by its cumbersome data model, the basis of which is an inherently
arbitrary parametric tree structure. The inconsistencies that exist among the data as
modeled in the parametric tree and the data as addressed in the record-based output file
further obscure the intended semantics. The overall data representation is non-intuitive,
disjoint, and difficult to comprehend. The burden of data interpretation is transferred to
the user, and the user must deal at length with formatting and coding issues.
In this thesis, I have proposed an alternative and improved representation of
EWIRDB data. The design effort was centered on the development of a legitimate
conceptual design, followed by development of a logical design suitable for
2
implementation on the M DBS in the NPS Laboratory for Database Systems Research.
The conceptual and logical designs are the first two phases in the overall database design
and implementation process.
The conceptual design has yielded a conceptual schema that captured the nature of
a representative portion of EWIRDB data in a way that closely paralleled the user's
perception of the data. The basis of the conceptual design was the OODM, a powerful
modeling tool that enables the designer to reduce the semantic mismatch between real-
world entities and their database representations. The OODM incorporates the concepts
of objects, encapsulation, object classes, instantiation and classification, generalization and
specialization, aggregation, and covering to achieve this end. The object-oriented
conceptual design has captured both the technical and administrative semantics of EW
data to a degree not previously achievable. This was the realization of the primary
objective of the thesis.

83
 In the logical design, I have mapped the object-oriented conceptual schema to the
2
object-oriented data model of the M DBS. The mapping is accomplished via the 0-
2
0DDL native to the M DBS. The resulting 0-0DDL statements constitute the logical
2
schema; they are an M DBS-readable specification of the conceptual schema. The 0-
0DDL provided for an arbitrarily deep nesting of objects within a framework of
relationships, inheritance, and covering. The semantics of the data have been preserved in
2
the mapping; when implemented on the M DBS, these semantics will be supported by the
2
M DBS. This is a huge benefit - the database user is thereafter relieved of the
responsibility of data translation and interpretation. Although it does not yet support
methods or aggregation, the 0-0DDL provides for an intuitive, cohesive, and nested
implementation of technical and administrative data. Therefore, the implementation is
much improved over the complex record-based format that currently exists.
The logical design portion of the this work provides input for the subsequent use
2
and evaluation of the object-oriented interface to the M DBS, and in this regard satisfies
the secondary objective of the thesis. In due course, the logical schema will be
2
implemented on the M DBS to produce an on-line object-oriented EWIRDB with which
2
to demonstrate both the utility of the new M DBS object-oriented interface and the
usefulness of the new object-oriented EWIRDB design.
Object-orientation did not appear to simplify the formidable task of modeling
emitter mode combinations, currently represented through use of suffix codes and suffix
tables. For this reason, I retained the suffix code-suffix table system in the designs
presented in this thesis. Consequently, the use of this system complicates the
implementation of the database. In the object-oriented approach, however, a reliance on
external software to interface with suffix tables is unnecessary. Such manipulation may be
achieved internal to the DBMS via methods. A true modeling solution may depend on the
development of a data model that provides the flexibility to address attnoute-to-attnoute
relationships and combinations.

84
 Overall, the conceptual and logical designs developed in this thesis support and
confirm the object-oriented approach as a viable solution to the modeling inadequacies of
the present EWIRDB.

85
86
 LIST OF REFERENCES

[1] National Air Intelligence Center, Electronic Waifare Integrated Reprogramming

Database (EWIRDB) Guide, Volume 1, April1994.

[2] Elmasr4 R, and Navathe, S., Fundamentals ofDatabase Systems, The

Benjamin/Cummings Publishing Company, Inc., 1994.

[3] Kim, W., "Object-Oriented Databases: Definition and Research Directions," IEEE
Transactions on Knowledge and Data Engineering, vol. 2, no. 3, September 1990.

[4] Cattell, R, Object Data Management- Object-Oriented and Extended Relational

Database Systems, Addison-Wesley Publishing Company, Inc., 1994.

[5] Bertino, E., Martino, L., "Object-Oriented Database Management Systems:

Concepts and Issues," Computer, April1991.

[6] Hsiao, D., ''The Object-Oriented Database Management: A Tutorial On It's

Fundamentals," Proceedings of the Second Far-East Workshop on Future
Database Systems, Kyoto, Japan, April1992.

[7] Hsiao, D., ''Interoperable and Multidatabase Solutions for Heterogeneous

Databases and Transactions," a speech delivered at ACM CSC 1995, Nashville,
Tennessee, March 1995.

[8] National Air Intelligence Center, Pulsed/CW Tree Measurement Guide Table, July
1992.

[9] National Air Intelligence Center, RPA Measurement Guide Table, July 1992.

[10] Stimson, G., Introduction to Airborne Radar, Hughes Aircraft Company, 1983.

[11] Frieden, R, Principles ofNaval Weapons Systems, United States Naval Institute,
1985.

[12] Badgett, R, Design and Specification of an Object-Oriented Data Definition

Language, Master's Thesis, Naval Postgraduate School, Monterey, California,
September 1995.

[13] McKenna, T., Lee, J., The Object-Oriented Database and Processing of
Electronic Warfare Data, Master's Thesis, Naval Postgraduate School, Monterey,
California, to be published March 1996.

87
88
 INITIAL DISTRIBUTION LIST

1. Defense Technical Information Center ............................................................ 2

8725 John J. Kingman Rd., STE 0944
Ft. Belvoir, VA 22060-6218

2. Dudley Knox Library, Code 13 ....................................................................... 2

Naval Postgraduate School
Monterey, California 93943-5101

3. Sharon Cain .................................................................................................... 1

NAIC/SCDD
4115 Hebble Creek Rd
Wright-Patterson AFB, Ohio 45433

4. Chairman, Code CS ........................................................................................ 1

Computer Science Department
Naval Postgraduate School
Monterey, California 93943

5. Dr. David K Hsiao, Code CS/HS ................................................................... 1

Computer Science Department
Naval Postgraduate School
Monterey, California 93943

6. Dr C. Thomas Wu, Code CS/KA .................................................................... 1

Computer Science Department
Naval Postgraduate School
Monterey, California 93943

7. LTKevinM. Coyne ........................................................................................ !

203 Colmar Rd
Seaside, California 93955

89