Download View/Open - Calhoun: The NPS

UNCLASSIFIED
SECURITY CLASSIFICATION OF THIS PAGE
REPORT DOCUMENTATION PAGE
1a
REP6RT SECURITY CLASSIFICATION
2a
SECURITY CLASSIFICATION AUTHORITY
3 DISTRIBUTION/AVAILABILITY
Approved
DECLASSIFICATION DOWNGRADING SCHEDULE
2b
RESTRICTIVE MARKINGS
ib.
UNCLASSIFIED
distribution
PERFORMING ORGANIZATION REPORT NUMBER(S)
4
6a.
NAME OF PERFORMING ORGANIZATION
(if
ADDRESS
Monterey,
8a.
8c.
1 1
.
CA
7b.
ADDRESS (City, State, and ZIP Code)
Monterey, CA 93943-5000
93943-5000
NAME 6E FUNdINg/sPoNSorINg
ORGANIZATION
ADDRESS
NAME OF MONITORING ORGANIZATION
Naval Postgraduate School
CS
and ZIP Code)
(City, State,
8b.
OFFICE SYMBOL
(if
TITLE (Include Security
PROCUREMENT INSTRUMENT
9
IDENTIFICATION
NUMBER
applicable)
10. SOURCE OF FUNDING NUMBERS
PROGRAM
PROJECT
TASK
ELEMENT NO
NO.
NO.
and ZIP Code)
(City, State,
unlimited
7a.
applicable)
Naval Postgraduate School
6c.
SYMBOL
is
MONITORING ORGANIZATION REPORT NUMBER(S)
5.
6b OFFICE
Computer Science Dept.
OF REPORT
for public release;
WORK
12. PERSONAL AUTHOR(S)
Bourgeois, Paul A.
13a. TYPE OF REPORT
Master's Thesis
16. supplementary notation
(U)
TIME COVERED
15. PAGE COUNT
14. DATE OF REPORT (Year, Month, Day)
March 1993
from 04/90 to 03/93
The views expressed in this thesis are those of the author and do not reflect the
policy or position of the Department of Defense or the United States Government.
13b.
GROUP
m.
offici
SUBJECT TERMS (Continue on reverse if necessary and identify by block number)
Data model, data language, multibackend database system, multilingu
18.
COSATI CODES
FIELD
r
Classification)
THE INSTRUMENTATION OF THE MULTIMODEL AND MULTILINGUAL USER INTERFACE
17.
UNIT
ACCESSION
SUB-GROUP
database system, multimodel database system, user interface design.
1
9.
ABSTRACT
The
(Continue on reverse
traditional
single data
of these
if
necessary and
identify
by block number)
approach to database-management-system
model and
its
corresponding data language
tions to operate several different
tabase-system design
This approach
is
is
the
designs focuses upon the implementation of
order to support applications for a given database task. Eac
in
monomodel and monolingual database systems
data model-language can be supported on a single
(DBMS)
homogeneous database system, since only or
database system. The application diversity forces many organiz
represents a
homogenous database systems
to support its operations.
A different approach to d
development of a DBMS which supports multiple data models and their data language
multimodel and multilingual database system (MM&MLDS) as implemented on th
the focus of the
Multibackend Database Supercomputer (MDBS).
With the proliferation of new data model-languages
to incorporate these
in the
database technology, the objective of
MM&MLDS
i:
new data model-languages onto the same MDBS. The goal of this thesis is to develop procedure
MM&MLDS as new interfaces. Three
methods, and tools for the incorporation of new data model-languages into
areas of research are critical to achieving this goal
DISTRIBUTION/AVAILABILITY OF ABSTRACT
SAME AS RPT.
fj UNCLASSIFIED/UNLIMITED
22a. NAME OF RESPONSIBLE INDIVIDUAL
20.
Q
.
21.
fj DTIC USERS
1473, 84
MAR
APR
22b.
edition
All
may.be used
user's
manual
for familia
ABSTRACT SECURITY CLASSIFICATION
TELEPHONE
(Include
(408) 656-2253
83
MDBS
UNCLASSIFIED
David K. Hsiao
DD FORM
development of a
First, the
until
exhausted
other editions are obsolete
Area Code)
22c.
OFFICE SYMBOL
CS/Hq
SECURITY CLASSIFICATION OF THIS PAGE
UNCLASSIFIED
TOEGQ1
£
UNCLASSIFIED
CURITY CLASSIFICATION OF THIS PAGE
Continued: ization as well as instruction for system users. Second, the specification of generic processing
lgorithms used as a foundation for each module of the new model-language interface. Third, our software meth19.
dology considerations for new data model-language interface implementation.
SECURITY CLASSIFICATION OF THIS PAGE
u
UNCLASSIFIED
Approved
for public release; distribution
is
unlimited
THE INSTRUMENTATION OF THE MULTIMODEL
AND MULTILINGUAL USER INTERFACE
by
Paul Alan Bourgeois
Captain, United States Marine Corps
B.S. Economics, United States
Submitted
Naval Academy, 1987
in partial fulfillment of the
requirements for the degree of
MASTER OF COMPUTER SCIENCE
from the
NAVAL POSTGRADUATE SCHOOL
March 1993
Gary i^ugTiel^ Acting Chairman,
Department of Computer Science
in
ABSTRACT
The
upon
traditional
approach
to
database-management-system
the implementation of a single data
model and
its
(DBMS)
designs focuses
corresponding data language in
order to support applications for a given database task. Each of these
monomodel and
monolingual database systems represents a homogeneous database system, since only one
data model-language can be supported on a single database system.
diversity forces
systems
many
A
to support its operations.
development of a
approach
This
organizations to operate several different
(MM&MLDS)
With the
objective of
is
DBMS
the
different approach to database-system design
of the
new
the
multimodel and multilingual database system
(MDBS).
data model-languages in the database technology, the
MM&MLDS is to incorporate these new data model-languages onto the same
MDBS. The
goal of this thesis
incorporation of
new
is to
develop procedures, methods, and tools for the
data model-languages into
MM&MLDS
as
new
interfaces.
areas of research are critical to achieving this goal. First, the development of a
user's
is
their data languages.
as implemented on the Multibackend Database Supercomputer
proliferation of
application
homogenous database
which supports multiple data models and
focus
The
manual
for familiarization as well as instruction for
interface. Third, our software
data model-language interface implementation.
IV
MDBS
system users. Second, the
specification of generic processing algorithms used as a foundation for each
new model-language
Three
module of the
methodology considerations
for
new
TABLE OF CONTENTS
I.
INTRODUCTION
II.
AN OVERVIEW
B.
OUR MOTIVATION AND GOALS
THE ORGANIZATION OF THE THESIS
C.
THE MULTIBACKEND DATABASE SUPERCOMPUTER (MDBS)
1
A.
A.
ITS KERNEL
DATA LANGUAGE
THE MULTIMODEL AND MULTILINGUAL DATABASE
C.
SYSTEM
PROCEDURES TO INTRODUCE NEW MODEL-LANGUAGE
B.
in.
THE DESIGN
THE KERNEL DATA MODEL AND
INTERFACES
A.
B.
C.
THE CONTROLLER SOFTWARE
NEW MODEL-LANGUAGE INTERFACE REQUIREMENTS
a.
c.
d.
5
6
7
12
14
The
The
The
The
14
Language Interface Layer
Kernel Mapping System
Kernel Formatting System
18
Kernel Controller
19
Among Module
14
16
22
2.
Communications
3.
Data- structure Requirements
25
4.
The Makefile Development
27
VERSION CONTROL AND MANAGEMENT
GENERAL STEPS TO A NEW MODEL-LANGUAGE INTERFACE
A.
THE MDBS USER INTERFACE
D.
1.
On
2.
The User's Manual
the Interface Familiarization
OUR SOFTWARE METHODOLOGY
1.
Models With A Formal Data Language
2.
3.
Models With No Formal Data Language
Kernel Model-Language Mapping Strategies
THE CONCLUSION
A.
RESULTS OF OUR RESEARCH EFFORT
B.
FUTURE RESEARCH
APPENDIX A. MDBS USER'S MANUAL
V.
5
Considerations for the Language Interface Software Module
b.
B.
4
11
Design
IV.
3
11
JUSTIFICATION
1.
1
27
29
29
29
30
32
33
34
35
37
37
38
39
APPENDIX
APPENDIX
APPENDIX
B.
C.
D.
MODEL-LANGUAGE INTERFACE GENERIC
FUNCTION MAPPING
MM&MLDS GENERIC MODEL-LANGUAGE
DATA STRUCTURE
GENERIC MAKEFILES FOR NEW MODEL-LANGUAGE
INTERFACES
106
110
Ill
REFERENCES
113
INITIAL DISTRIBUTION
115
VI
LIST
Figure
1
:
Figure 2
:
Figure 3
:
The Multi-Backend Database Supercomputer
The Multimodel and Multilingual Database System
The Model-Language Interfaces as Implemented on
Database System,
Figure 4:
Figure
5:
Figure
6:
Figure
7:
Figure
8:
Figure
9:
Figure 10:
Figure 11:
Figure 12:
Figure 13:
OF FIGURES
The
6
8
a Kernel
MDBS
File Organization
9
and Structure for Data Model-Language
Interfaces within the Front-End Controller
13
The
The
The
The
Generic Algorithm for All Language Interface Layers
15
Generic Algorithm for All Kernel Mapping Systems
17
Generic Algorithm for All Kernel Formatting Systems
18
Schematic Diagram of Processing Steps of the
Kernel Controller
21
The
The
The
The
The
22
Generic Algorithm for All Kernel Controllers
Module Communication Path
Module Communication Path
Load
23
for Executing Transactions
24
for a Data-Definition
25
User_info Structure
li_info Structure with the
new_model_language_info
26
Included
Figure 14:
The Relationship Between Model/Language
and the Test Interface
Figure 15: The Lex and Yacc Parsing Processes
vu
Interfaces (ML/Is)
30
34
I.
A.
INTRODUCTION
AN OVERVIEW
Database systems have revolutionized the workplace by combining the advancements
in
today's information technology with the information
governments. These organizations have come
demands of
to rely
large corporations and
heavily upon the efficiency of
database systems to increase their productivity. Though the rapid growth that has taken
place in the area of database research and development resulting in
systems and increased productivities,
has also presented
it
proliferation of different database systems,
cannot communicate with each other.
proliferation
of
heterogeneous
In
databases
more
a
efficient database
problem due
to
the
heterogeneous database systems, that
i.e.
examining the factors and issues of the
and
systems,
we must
review
first
the
conventional design of a database system.
The design of
a database system begins with the selection of a data
model which
characterizes the needs of data in order for the processing to be accomplished by the
database system.
Once an
approriate data
model
has been selected, a corresponding data language
and data languages include
SQL
(i.e relational,
is
chosen.
network, or hierarchical)
Some examples
for the relational data model,
of data models
DML for the
network data
model, and DL/I for the hierarchical data model. Each database system can only support
one specific pair of data model and data language
are characterized as
monomodel and monolingual.
.
These conventional database systems
A
user of such a database system must
have thorough understanding of the underlying data model and data language supported by
the system in order to use the system effectively. This restricts the user to the single data
model and data language supported by
the system.
Any experience
with another data model
and data language will be useless, since the database system can not support
that pair of
data model and languag.
A different approach to the database design is the incorporation of several data models
and data languages into one database system
[DEMU
87]. This
more
flexible database
known
design will result in a database system
system
(MM&MLDS).
advantages
not
This approach
found
in
as the
to the
database design provides several distinct
approach
conventional
the
multimodel and multlingual database
to
the
database
design.
The
consolidation of several data models and data languages on one system will defray the cost
spent on procurring several different
monomodel and monolingual database
systems.
The
number of support personnel required
consolidation of resources will also reduce the
to
maintain the different database systems. Replacement costs will be reduced since any
system upgrade will only be necessary toa single database system instead of several. For
example,
if
one conventional database system
is
upgraded, the other conventional database
systems will not reap the benefits of the upgrade. With the
models and data languages
will benefit
from the upgrade of the single database system.
Re-training costs are also eliminated since a user
MM&MLDS.
models and data languages with
a user
who
is
MM&MLDS approach, all data
is
not required to learned a
Through cross-modeling access
inexperienced in using a certain
new
new
data
capability,
data model-language can access a
heterogeneous database with a transaction written in the data model-language more
familiar to the user. For instance, a user
SQL
databases using the data language
transactions, not
The
DL/I
who
is
experienced
in
working with relational
could access hierarchical databases using
SQL
(hierarchical) transactions.
MM&MLDS
concept
is
currently implemented at the Naval Postgraduate
School's Laboratory for Database Systems Research on the Multi-Backend Database
Supercomputer (MDBS).
the
characteristics
MDBS
associated
is
designed to support
with
a
federated
database
transparent access to heterogenous databases, local
database, and multimodel/multilingual capability.
A
MM&MLDS and together, to have
system.
They include
the
autonomy of each heterogeneous
in-depth look into the database design
approach to federated databases and systems can be found in [HSIA 92] and [HSIA 89].
B.
OUR MOTIVATION AND (iOALS
The
MDBS currently implemented at the Naval Postgraduate School's Laboratory for
Database Systems Research incorporates four data-model-and-data-language interfaces.
These
are
(ABDL)
the
attribute- based-data-model
interface,
the
(ABDM)-and-attribute-based-data-language
relational-data-model-and-SQL-data-language
network-data-model-and-CODASYL-data-language
interface,
interface,
the
and the hierarchical-data-
model-and-DL/I-data-language interface. Four separate software modules are written for
each model/language interface. The process of incorporating a new data model and data
language into the current
MDBS
requires spending
numerous man-hours deciphering
the
data structures and internal logic of previous model-language interfaces.
The
first
goal of this thesis
incorporation of a
new
new model-language
data languages are developed,
and efficient incorporation of
to all interfaces
looking
at the
therefore, to provide a pedagogical aid
is,
interface into
the
MDBS. As new data models and their
we want to develop
their interfaces.
to
procedures that will ensure accurate
We will examine the
internal logic
common
and highlight the necessary functions that a new interface must possess by
four software modules that comprise each interface. Procedures will be
presented which outline specific issues that must be addressed prior to any implemention
of a
new
data model-language interface.
The second goal of
setting
up
set or user's
manual
for
designed specifically as an introduction to
MDBS
for
this thesis is to
MDBS. The manual
is
develop an instructional
first-time users, but will also function as a reference
MDBS.
Since no user's manual currently exists for
the need for expert assistance for those
manual
will address topics
request
files,
who
manual
for
any further research on
MDBS, this user's manual will alleviate
desire to
work on
and methods such as starting
and accessing each data model- language
MDBS. The MDBS
MDBS,
interface.
user's
developing schemas and
Sample databases
given to assist the user in the understanding of each data model and
its
will be
data language.
THE ORGANIZATION OF THE THESIS
C.
Since
of
MDBS
all
is
research efforts in this thesis have been accomplished for
necessary which
is
presented in Chapter
we focus upon the system structure, the kernel
II.
More
MDBS,
specifically, in
an outline
Chapter
II,
data model and the kernel data language, and
the multimodel-mulitlingual database system design.
procedures and methods for the introduction a
new
In
Chapter
III,
we
outline the
data model-language interface. Issues
such as program and data structure modifications, makefile development, as well as
functionality requirements for each
Chapter IV,
we
module within the model-language
management
address the various interface
model-language interface
is
MDBS.
incorporated into
strategies
when
In Chapter V,
we
a
new
database
enviroment,
and
design
implementation
data
present our
concluding thoughts concerning the interface management in the multimodel
multilingual
In
interface.
decisions
for
and
the
implemention of a new data model-language interface, and future work.
Appendix
A
is
the first
volume of
MDBS
areas concerning the front-end software of
file
User's Manual. This manual details those
MDBS
to include the execution of
MDBS itself,
development, and the utilization of the data model-language interfaces. Appendix
provides the generic mapping of functions required by
as well as specifications for the each software
all
B
data model-language interfaces
module of the language
interface.
II.
THE MUL TIBACKEND DATABASE SUPERCOMPUTER (MDBS)
THE DESIGN
A.
The
known
heart of
MDBS is the configuration of the database stores and database processors
as database backends.
MDBS
relies
upon these database backends
to
provide the
storage and processing functions. Each backend consists of a microprocessor and three data
disk drives; a smaller Winchester-type for paging and another smaller one for metadata and
a larger disk drive for base data.
in
parallel via an ethernet
MDBS architecture allows these backends to be connected
LAN
using point-to-point communication for one-to-one
communications between separate backends and broadcast communication from one
backend
to
many.
A
front-end microcomputer
known
as the controller,
which
is
separate
from the backends, controls the interface between the user and the backends and also
provides for backup and recovery. In Figure
1,
we
illustrate
MDBS architecture [HSIA 91].
Each database backend contains a portion of a stored database through a process called
clustering. In clustering, the base data
sets.
The
is
spread across the backends in mutually exclusive
distribution of the database records through clustering permits parallel access to
the data and
is
integral to the high-performance of
MDBS. When
a transaction is
broadcasted from the controller, each backend can execute the transaction
in parallel
with
the other backends.
The
MDBS architecture allows for increases in performance and capacity through the
addition of backends. Unlike the traditional database system which required an extensive
and costly modification or replacement
to
achieve a decrease in the response time or a
greater capacity without any degradation of the response time,
addition of one or
more backends
performance gains achieved by
to achieve
MDBS
MDBS
such decrease or capacity growth. These
through the addition of more backends are
as the response-time reduction and the response-time invariance
MDBS
provides greater flexibility, since no modification
which runs on
MDBS. The number
requires only the
is
[HALL
known
89]
required to the software
of backends the system can support
is
not limited by
connection ports of either the controller or a backend. Therefore,
required for the incorporation of a
new backend
to the
MDBS
"down-time"
little
is
configuration. At one time,
there can be eight backends configured in the Laboratory for Database
System Research
Meta data disk
Base data disks
Paging disk
Tape Drive
Base data disks
Controller
-
Paging disk
The User
Meta data
disk
Base data
disks
Paging disk
Figure
B.
1
:
The Multi-Backend Database Supercomputer
THE KERNEL DATA MODEL AND
ITS
KERNEL DATA LANGUAGE
One of the requirements of a federated database system is to
and
their data
support
languages on the same, single system. Such a system
multimodel and multilingual.
MDBS
is
a database system
many data models
is
known
as being
which uses a mapping function
(1) to support
amongst
multimodel/multilingual capability and (2) to enhance data sharing
its
different heterogeneous databases.
the different data
models and
their data
language or kernel data model and
sharing and
kernel data language.
its
based data model
(ABDM)
its
MDBS
languages into a single data model and
mapping algorithms can be found
This kernel data model and
have led
The mapping function used by
in
(HSIA
An
maps
its
data
in-depth discussion of data
92].
MDBS
kernel data language used by
is
the attribute-
and attribute-based data language (ABDL). Several factors
to the selection of the
ABDM;
these include: the separate modeling of base data
and meta data,the clustering of base data into mutually exclusive
sets for storage
on the
backends, and the allowance of parallel accesses to the clustered base data. The semantic
richness of
ABDL
SQL, DL/I, and
Schema
their
allows for the translation of other traditional data languages, such as
DML into ABDL for processing on MDBS.
definitions and transaction requests developed for traditional data
models and
languages are either transformed or translated into equivalent schemas of the kernel
data model or equivalent transactions in the kernel data language for processing in the
kernel database system. Using the multiple- models/languages to the single-model-
language mapping function,
MDBS
requires only (n-1)
transaction translators, were n represents the
and
C.
their
languages
to
be supported in
number of
schema transformers and
(n-1)
different heterogeneous databases
MDBS.
THE MULTIMODEL AND MULTILINGUAL DATABASE SYSTEM
In
Figure
2,
we
illustrate
multilingual database system
(UDM)
the general system structure of the multimodel
(MM&MLDS).
and
Transactionswritten in the user's data model
and user's data language (UDL) are transformed and translated into the kernel data
model (KDM) and kernel data language (KDL) equivalent via
interface.
the
Four software modules comprise the model/language
MDBS model/ language
interface.
These are the
language interface layer (LIL), the kernel mapping system (KMS), the kernel formatting
system (KFS), and the kernel controller (KC).
The following paragraphs
with the language interface as well as
UDL must first be processed by LIL.
these
transactions
transactions.
created,
it
Two
KMS
may
KDM
and
KDL
LIL forwards
database-definition
KMS.
transactions
Upon
KDM-database
definition to
database system
This transformation process
successful transformation of
KC.
(KDS) where
KDS when
the
passes
UDM-database
KDM-database
new database
is finally
a
LIL
UDM
UDL
:
:
LIL
KMS
KFS
KC
M/LI
KDS
KDM
KDL
:
:
:
:
:
:
:
:
UDM/
Notice that
query-request
new
database
is
called data-definition
definition,
KMS
sends
definition to the kernel
defined on
that the database definition has
UDL
UDM and transforms
MDBS. The KC
the database definition has successfully processed
notifies the user through
Figure 2
KC
is
KMS.
or
when
First,
takes the database-definition (or database schema) of
KDM.
and
.Each transaction issued in
these transactions to
major tasks are accomplished by
transformation.
notified by
be
either
into a database definition of
UDM
outline the general interaction between
and
been loaded.
User Data Model
User Data Language
Language Interface Layer
Kernel Mapping System
Kernel Formatting System
Kernel Controller
Model/Language Interface
Kernel Database System
Kernel Data Model
Kernel Data Language
The Multimodel and Multilingual Database System
KC
is
in turn
Secondly,
KMS
transactions through a process
these transactions to
KC
transaction execution,
transactions
translates
known
reformats
KDM
to
sends the results
results
from
KDS
to
interface. In other words,
KC. The
for execution.
KC in KDM
KDS
interface supported
forwards
Upon completion
of the
format. Through LIL, the
MDBS
by
own
its
has
its
set of LIL,
own language
KMS, KFS,
and
and consistency of each data model-language must be
incorporated within the language interface modules.
implementation of the
KMS
KDL
UDM form.
each language interface has
functionality, integrity,
equivalent
format. In order to display the
UDM
into the correct
results of the queries are displayed to the user in
Each data model-language
into
UDM format, KC passes the results from KDS to KFS.
results of a transaction in the proper
KFS
UDL
in
as the data-language translation.
which passes them
KDS
written
MM&MLDS
structure in
In,
Figure
3,
we
represent the
MDBS.
(The index indicates
i-th model-language
i
the
interface)
Figure 3 :The Model-Language Interfaces as Implemented on a Kernel
Database System,
MDBS
Using
its
capability to
model
different data
languages on one system,
transactions
experiment
with
different
data
MDBS
models and
models and
affords
their
different
prolierating stand-alone database systems. Further, a user
pair
which
is
best suited for the user's needs.
incorporated into
models and
MDBS
their data
is
the
to
user the
data
may choose
Most importantly,
translate
the
different
opportunity to
language
without
the model-language
MM&MLDS
concept
an invaluable paradigm for the understanding the various data
languages without having to use a separate database system for each
data model-language.
10
III.
PROCEDURES TO INTRODUCE NEW MODEL-LANGUAGE
INTERFACES
JUSTIFICATION
A.
As
the database system continues to
new
education, and industry,
grow
in
use and size within government,
data model-languages will be developed to support the
constantly changing requirements placed upon existing data model-language interfaces. At
the Naval Postgraduate School's Laboratory for Database Research,
able to incorporate these
new
design and programming teams must
MDBS
through hands-on exposure
designing a
new
user interface
model-language interface
MDBS. The
data model-languages into
additional data model-language interfaces into the
first
become
to the current
is to
MDBS
we would
is
introduction of
not a small task. First, the
familiar with the idiosyncrasies of
MDBS
system. Since a primary focus of
maintain consistency throughout each application (or
in the case of
MDBS) [SHN1 92], it is essential that designers and
programmers understand the design of previous data model-language
interfaces.
Second, once these teams become familiar with the current version of
thorough understanding of the general architecture of
is
like to be
MDBS
is
MDBS,
an
required. This requirement
generally satisfied by reading various papers written on the
MDBS.
Topics such as
federated databases, database architecture, and multimodel/multilingual database design
should be covered.
Third, a review of previously designed and implemented data model-language
interfaces
must be accomplished. Each data model-language
approximately ten
to
twenty thousand lines of programming code written
Lex and Yacc. Few students
Unix
tools
interface
are familiar with the
Lex and Yacc. Now, they must
in
programming language C,
consists
of
C, and with
let
alone the
learn these languages and tools in order to
understand the internal logic of these previously designed interfaces. This review
represents a majority of the
of
work
that
must be accomplished
C code for the new data model-language
interface.
11
prior to writing the first line
Previous research has been conducted in the development of traditional data modellanguages; however, no research has been done in the area of data model-language interface
management on MDBS. Too much time
is
spent on trying to complete the tasks previously
mentioned. The development of an effective tool
will alleviate the
efficient
is
therefore necessary, so that the tools
burden placed upon designers and programmers and
is
integral for an
and accurate data model-language incorporation. Currently, no such tool
The scope of
First, a user
this
data-model-language-interface management strategy
manual must be developed
that introduces first-time user to
functional as a quick reference for experienced users. Second, for each software
the language interface contains procedures that are
interfaces, an
awareness of these features
common
to designers
to all data
and programmers
threefold.
is
MDBS
exists.
and
is
also
module of
model-language
is
accomplished
by the introduction of generic software module algorithms. Third, general steps must be
provided for incorporating
the
fulfillment of this
new
data model-language interfaces into
strategy
that
we
are
able to
MDBS.
It is
through
provide the paradigm for the
instrumentation of the multimodel and multilingual user interface.
B.
THE CONTROLLER SOFTWARE
The
MDBS
software. All
version of the
configuration
MDBS
MDBS
software
is
separates the controller
loaded under in a directory
software. Currently that version
is
software from the
named
most current
VerE.6. Subdirectories under the
VerE.6 directory contain the software for each particular aspect of
CNTRL
after the
backend
MDBS
execution.
The
directory contains the software for the data model-language interfaces as well as
the software for the communications between the front-end controller and the backends.
Our research focus
is
placed upon the software which comprises the data model-language
interfaces. This software is located in the
TI
(for Test Interface) directory
and subsequent
subdirectories of TI. Figure 4 illustrates the file organization of the test interface directory
and
its
relationship with the data model-language interface.
12
c
N
T
R
L
CONTROLLER TO
BACKEND
COMMUNICATION
SOFTWARE
CNTRL
Tl:
Figure
:
Controller
LI:
4:
The
Language
Interface
DMLI: Data Model Language Interface
Test Interface
File Organization
and Structure for Data Model-Language
Interfaces within the Front-End Controller
Within the TI directory resides the program module which drives the user interface for
MDBS.
This program,
ti.c,
determines the number of backends the system has currently
configured for execution, loads the schemas for existing database schemas, and displays the
MDBS
system menu. Implementors of new data model-language interfaces must include
an option in the main (argc, argv) procedure of ti.c for the selection of the
new
language interface. This includes adding the appropriate case statement
allow continued
processing of the
new model-language interface. Appendix B provides
the test interface directory structure as
The TI
pertains to the
MDBS
a detailed outline of
user interface.
directory also contains the procedures for executing the kernel data model-
language interface,
a
it
to
data model-
i.e.,
new model-language
attribute- based data
interface.
The introduction of
interface does not require any modification of the
in the test interface directory
In order to alleviate the
software modules,
model-language
MDBS
with the exception of
ti.c
programs residing
as mentioned above.
burden of data passing among functions residing
relies
upon global data
structures to
in different
communicate between
software modules within the language interface. Within the TI directory, global datastructures
and variables are stored
in a
header
file
13
named licommdata.h.
Part 4 of Section
C
outlines
the
data structures required
relationship to the licommdata.h
relationship required by
C.
all
file.
by
all
Appendix
new model-language
model-language interfaces and
C
their
diagrams the generic data- structure
interfaces.
NEW MODEL-LANGUAGE INTERFACE REQUIREMENTS
1.
Considerations for the Language Interface Software Module Design
As previously
noted, the language interface consists of four software modules:
the language interface layer, kernel
controller.
mapping system, kernel formatting system, and kernel
Each new data model-language introduced
language interface modules; specifically,
its
own
into
LIL,
each data model-language interface implemented on
MDBS
must include
KMS, KFS,
MDBS
has
It is
its
MDBS.
This
is
new
set
all
set of
model-language
must be
data model-language interface on
accomplished by examining the language interfaces of existing data model-
languages and identifying the commonality that
a.
own unique
these required functions and corresponding internal logic that
addressed when designing and implementing a
own
and KC. Even though
language interface software modules, certain functions must exist in
interfaces.
its
is
present in each module.
The Language Interface Layer
The language
interface layer (LIL) of the
MDBS
between the user and the controlling software which drives
model-language
interface
communicate with
implemented
the user via LIL.
on
MDBS,
all
Communications with
functions as the bridge
MDBS.
Regardless of the
model-languages
the kernel
interfaces
mapping system,
kernel controller, and kernel formatting system are also the responsibility of LIL.
Since
all
model-language interfaces interact with the user
be some form of consistency
interface design for
among
the different user interfaces.
in
LIL, there must
The goal of
the user
MDBS is to develop a user interface that is common for each different
data model-language interface. Achieving this goal reduces the time required by the user to
familiarize the user with the functionality of a different user interface with each data model-
language present on
MDBS.
For instance, a user familiar with the relational/SQL user
14
interface does not have to learn a completely different user interface in order to use the
hierarchical/Dl/1 interface.
Each data model-language possesses
LIL
a similar pattern of processing for the
We require that LIL is to adhere to a generic algorithm for the interaction with the user
KMS, KC,
as well as
generic algorithm into
the generic
New
and KFS.
its
model-language interfaces must incorporate
own language
interface layer. Figure 5 outlines the structure of
LIL processing algorithm.
Allocate
and
Process
new
If new
initialize
memory for data-structures.
or old database?
database...
-
Enter and store database name into the database catalog.
-
-
Load schema input from the terminal or file.
Load the file into linked-list.
-
Create template and descriptor files, index attributes
-
Send schema
-
-
(in linked-list
Display errors from
Prompt
to
data structure) to
KMS for parsing.
KMS during parsing (if any).
continue to process as old database or
exit.
If old database...
-
Check database name against the catalog. If not found check other
model-language catalogs (this is for use with cross-model accessing
only).
if found in other data model-language, transform schema.
Determine the mode of the input request.
-
-
-
Store requests in a linked-list data structure.
-
Display numbered queries
-
Option
-
Send the
-
Display errors from
-
Send the parsed request
to the user.
to redisplay queries or process a request.
list
of requests to
KMS for parsing.
KMS (if any).
to
KC for processing against a database
KDS.
-
Display results from
-
De-allocate the
Exit to
Figure
KFS
to user.
dynamic memory.
main menu and repeat above steps or
5:
this
The Generic Algorithm
for All
15
exit
system
Language
Interface Layers
in
Notice that this algorithm applies directly to any data model-language
interface
implemented on
MDBS. The
language interface layer
Much
develop from a programmers stand point.
is
by far the easiest layer to
of the code already developed from
new
previous model-language interfaces can be modified to suit the requirements of the
model-language interface. The application of the generic algorithm guarantees consistency
amongst the various model-language
the
LIL
interfaces as well as the basic
framework by which
functions.
The Kernel Mapping System
b.
The kernel mapping system
is
responsible for the parsing of the model-
language based transactions for further processing in the kernel controller. This parsing
involving the transformation and translation of transactions written in the user's data
model-language into the data model-language of the kernel database system. Though
transformation and translation of
UDM-L takes place in KMS,
transformation and translation
being conducted. This
is
is
is
the user
known
is
unaware
that this
as the transparency and
one of the requirements of a federated database system. Designers and programmers of
new model-language
interfaces
must ensure
that
KMS does not interface directly with the
user but instead interfaces with the user through LIL. Again, this
is to
maintain consistency
and transparency throughout the model-language interfaces.
A majority of KMS is comprised of mapping and formatting algorithms that
are specific to the model-language implemented.
KMS
must read input streams from LIL
containing either data-definition or request transactions. In order for the input streams to be
readable by
KDS,
KMS
uses the
grammar and semantics of
or translate the input stream into tokens recognizable by
UDM and UDL to transform
KDS. Functions
written in
KMS
must accommodate the semantics, syntax, and grammar of the model-language being
introduced.
translation
translation
By
analyzing the semantics, syntax, and grammar of
and transformation into
and transformation, but
is
KDM
and
KDL,
the parser
UDM
is
and
UDL
not only capable
also capable of detecting errors in the transaction
16
for
Even though
the
UDM
grammar and semantics of
and
A
KMS
generic algorithm which outlines the basic functions required of
model-languages
for all
is
proposed. Implementation and
algorithm will alleviate the burden of determining what
the other
modules of
dictate the
KMS in all model-
transformation and translation process, certain functions are required by
language interfaces.
UDL
the
new language
MDBS.
model-language interface on which
KMS called by
LIL
required by
adherence
KMS
to this
in relation to
interface.
KMS
Figure 5 outlines the generic
model-language interfaces on
is
strict
it is
processing algorithm required in
Notice that this algorithm
is
all
independent of the
implemented.
to process transactions
Begin parse of the input stream.
error found in parsing
If
-
memory allocated for the data-definition or request
memory is generally the memory allocated by
model-language kmsjnfo data-structure.
deallocate the
input streams. This
the
-
If
issue the error message.
no errors found
-if
-
a data-definition transaction to load a database schema
if
KC
-
send transformed schema to
-
send LIL the confirmation of schema load.
to load
onto
KDS.
a request transaction for querying.
UDM request to KC.
UDM request in KDM format via LIL
-
send the translated
-
display the translated
End processing
Figure
6:
The Generic Algorithm
Because
language interface,
we
KMS
for All Kernel
represent over half the
suggest for a
Mapping Systems
programming requirement
new model-language
design of the kernel mapping system.
We
also focus
interface, three steps in the
on the mapping and formatting
process. These steps function as a guideline for the design of
KMS
prior to
grammar and semantics of the new model-language
1.
Outline the
2.
Determine the mapping algorithm
UDL into KDM
to
programming.
interface.
mapping grammar and semantics of
and KDL.
17
for the
UDM and
3.
Incorporate the
mapping and formatting functions
into the generic
algorithm.
The Kernel Formatting System
c.
The primary function of
the kernel formatting system
KDM-formatted transactions received from
the kernel controller
UDM
are only
format.
Communications with KFS
completion of a
RETRIEVE
transactions issued to
results to the user
or
(KFS)
(KC)
is
to
reformat
into the proper
established after the successful
RETRIEVE-COMMON
transaction
in
KC. Other
KC only require notification to the user of successful or unsuccessful
execution. However, the
in
KMS
RETRIEVE and RETRIEVE-COMMON transaction display data
and therefore must be transformed into a format familiar
to the user (i.e.,
UDM).
Each model language has a unique representation of an
regards to the syntax and structure of the data model. Therefore,
result data stream (or response)
in the
from
KC in
attribute-based
KFS
ABDL
request in
simply parses the
form and displays
it
to the user
UDM form.
Of
the four modules,
KFS
provides only one simple task to the
MDBS
transaction execution process and thus comprises the least coding required to implement.
Though simple
the
in
coding, specific steps must be found in every KFS. This does not prevent
new model-language
been output by
designer from creating a complex display screen for data having
MDBS. With this in mind, we propose a generic kernel controller algorithm
for the implementation in all
KFS
modules. Figure 7
illustrates the generic
Receive an output stream from KC.
Correlate
ABDL
Display results
Return
to
request data with
UDM attributes.
to the user.
LIL
Figure 7: The Generic Algorithm for All Kernel Formatting
Systems
18
KC algorithm.
.
d.
The Kernel Controller
The
at the
intersection of the language interface and the back-ends of
kernel controller (KC). Without a thorough understanding of
KC
's
MDBS
meet
internal logic
coupled with the utilization of a generic algorithm outlining the functional requirements of
KC,
the implementation of a
Once
translated
new model-language
interface
would be
a user's data definition or request transaction has been transformed or
by the kernel mapping system (KMS), the control
controller for the loading of this (or these) transaction(s) onto
to issue
it
the transactions that
1
of semantic correctness,
2.
of syntactic correctness,
3.
in
proper
meet the following
new_model_language_info data
KC
structure.
kernel controller. First, the introduction of a
flag to
is
MDBS. KC relies upon KMS
criteria:
CreateDB. This sends a signal
are based
Two
upon
the operation flag within
situations present themselves to the
new database
into
MDBS
UDM data definition into KDM form and
new database,
template
file is
KMS
LIL has created template and
KC must now load the template file onto MDBS
required by
KDS
in
sets the operation
to the kernel controller indicating that a data
definition has not been loaded for this particular database. Since
the
passed to the kernel
KDM format.
The operations performed by
the
virtually impossible.
order to conduct the
has transformed
descriptor files for
backends. The database
initial
database load. In the
attribute-based data model-language, the template file represents the data definition used
by the supported data-model language
to establish a
As previously mentioned,
model-language reside
Interface provides the
the controller. Other
to the controller
new database on
the system.
functions which comprise the attribute- based data
in the Test Interface section of the controller software.
communication
link
from the language
modules with the controller
and vice versa.
19
aid in the
The Test
interface to the backends via
communication of the backends
KC
must
dbl_template() function in the program dbl.c in the Test
call the
Interface. This function copies the template file into the UserFiles directory
the process of loading the template file onto the
during the load of the template
dynamic memory
file will
MDBS
back-ends.
and then
Any errors
be displayed to the user and
all
starts
encountered
corresponding
will be de-allocated.
The second
situation involves translated transactions
from
KMS
awaiting
processing by KC. Each request transaction has an associated operation flag assigned upon
KMS
completion of
parsing function.
this flag
It is
which determines what processing
functions must be performed by the kernel controller. Operation flags are model-language
specific, but
must incorporate the
five basic operations of the attribute-based data language
RETRIEVE-COMMON, DELETE, INSERT,
(ABDL): RETRIEVE,
Depending on the operation specified
within
KC will
than one
be called.
ABDL
If
in the operation flag, the appropriate
the request transaction required an
statement,
a requestJiandler function
UPDATE.
and
request_handler
ABDL translation
must be invoked
to
of more
ensure
UDM requests from which
they were parsed. This will prevent an incomplete execution or the original UDM request.
continuity between the multiple
Aside
from
the
this
scenario,
new jnodelJangauge_execute
The
ABDL requests and the
the
single
request handler
will
pass
to
the
makes
the
control
function.
new modelJangauge_execute
function
within
KC
necessary function calls with the Test Interface section for subsequent execution on the
MDBS
processors.
The
translated
UDM
format for execution by changing
exception of the
loaded to the
first
MDBS
all
request
modified into the proper
ABDL
characters in the request to lower case with the
character of the request.
for execution
is first
Upon
completion, the modified request
by calling the TI_$$TrafUnit() function
is
in the Test
Interface.
After loading the request,
KC
checks for responses from
contain the results from previously loaded queries. This
is
KDS
which may
accomplished by invoking the
nml_chk_response_left () function within KC. Maintaining a count of the number of ABDL
20
—
requests needed for a single
messages
KDS
(or responses)
UDM
from
KDS
nml chk response JeftQ function receives
request, the
and ensures
all
ABDL results have
been received from
prior to sending the results to the kernel formatting system (KFS).
completion of
all
of each query as
through
the
forwarded to
the requests or transactions, a file
it
finishes
its
maintained that appends the results
execution. Errors in processing will be addressed to the user
TI_ErrRes_Output() function.
KFS
is
Pending the
Successfully
for display to the user. Figure 8
processed requests will
be
shows a schematic diagram of the kernel
controller processing steps.
nmlkernelcontrol ler
(
^^-^"
CreateDB
load template
\
check operation
^
flag
J~
^
Request Transaction
request handler
files
modify
Return to LIL
ABDL
request
load request
errors
TI_$$TrafUnit()
TI_ErrRes_OutputO
correct
request pending
_,
'
nml chk_response_left
done
Store_in_buffer_file
Figure
8:
Forward To KFS
The Schematic Diagram of Processing Steps of the Kernel
Controller
Data model-language specifics do not have a major impact upon the design
of the
KDM
KC because model-language transactions reach KC have already been translated into
form. Therefore,
translated
all
KCs must
have a similar algorithm which processes the
UDM transaction and extracts the results from KDS. We propose a generic KC
21
algorithm required
model-language interfaces. This algorithm provides the basic
in all
foundation by which
KCs
all
should be developed. Figure 9 illustrates this algorithm.
KMS via LIL.
-
Receive the parsed transaction from
-
Determine the subsequent action based on the operation flag.
if operation Jag = CreateDB
- dbljemplatei) /* in Test Interface to load template file.
-
if operation Jlag
-
return to LIL.
=
a request transaction
-
requestJiandlerO /* based on the operation Jlag set in
-
nml_execute()
ABDL request to proper format.
ABDL request to MDBS.
-
fix_ABDL_req()
/*
-
TI_$$TrafUnit()
/* loads the
-
nml_chk_response_left() /* have
-
TI_R$Message()
message from
TI_R$Type() /* is the message correct?
switch (TI_R$Type)
-
-
KMS.
modify the
all
/* receive
requests processed?
MDBS.
case correct response:
-
TI_R$ReqRes()
/* receive the results.
check_last_response() f* are there results pending?
case RETRIEVE or RETRIEVE
-
COMMON:
-
if
results pending, store results in the buffer
loop
-
case
till
all
and
request results are completed.
KFSO I* forward results to KFS.
INSERT or UPDATE or DELETE:
-
print the query-completion notification.
-
return to LIL
case Errors
Figure
2.
9:
-
TI_R$ErrorMessage()
-
TI_ErrRes_Output()
-
return to LIL.
I* finds the error type.
I* display the error to user.
The Generic Algorithm
for All Kernel Controllers
Communications Among Modules
Figure 2 illustrated the basic relationship between the software modules
comprising the language interface. For the design and implementation of
language interfaces,
this figure
must be expanded
22
to
new model-
provide a more in-depth view of the
communication paths
Interface
must be included
Language
Interface for
The path
new database
between modules. Additionally, the role of the Test
that exist
all
to
show
the relationship the Test Interface has with the
data model-languages.
selection
is
based upon whether a user
is to
be loaded, the following intercommunication takes place between the
modules and the Test
definition via LIL;
Interface. First, the user issues a
LIL then queries
request for the data-definition
file.
completed, the control
loading of the
KDM
is
data-definition to
LIL
LIL
data-definition to
MDBS
KDS
name and
KDM
(step 2.)
format (see step
1.
which then makes a
LIL
file,
in
name
calls
to
KMS
KC (step 3.)for
call to
calls the Test Interface to
&
5.).
After
KDS
data-
Figure 10). Once
KC
(steps 4.
new
uses the
KDS.
perform the
has successfully loaded the
and notified the Test Interface (steps
(step 8.). This
to load a
After receiving the data-definition
returned to
actual loading of the data to
command
the user for the database
to parse the data-definition file into the
illustrates the
loading a data-definition for a
or loading request transactions for processing against an existing database. If
a data-definition
control to
is
6.
&
7.),
KC
completes the loading of the data-definition
returns the
file.
Figure 10
aforementioned communication sequence with sequence numbers.
^
KMS
/*
a.
KC
LIL
8.
Figure 10: The Module Communication Path for a Data-Definition Load.
Notice that
KFS
is
not involved
when loading
a data-definition
file.
KFS
is
not
required in the communication process, since there are no (request) transactions to be
23
displayed to the user.
communication
The omission of KFS
is
distinguishing
the
path.
Our second communication path involves
KDS.
the execution in
the issuing of (request) transactions for
After the user has responded to the prompt by loading (request/
query) transactions via LIL, those transactions are sent to the
KDM
form
which
in turn
(step
1.
in Figure 11).
KMS
sends the transactions to the Test Interface (step
Test Interface (step
5.) in
processed. Figure
transactions in
1 1
LIL
for parsing into the
on
3.) for
(step 8.)
illustrates the
user in the
where the process
KC
(step 2.)
execution on
KDS
MDBS, results are forwarded
order to further communicate the results to
KC forwards the results to KFS for display to the
are then finally returned to
KMS
passes the parsed transaction(s) to
(step 4.). After processing against the appropriate database
to the
of this
feature
KC
(step 6.).
UDM form (step 7.). Controls
is
repeated
if
more requests
are
communication path for the execution of (request)
MDBS.
1.
^f KMS
\
2.
y'
KC
LIL
8.
Figure
11:
KFS
7.
The Module Communication Path
In both cases, errors resulted in
to
any module
for Executing Transactions.
will cause the control to be returned
LIL. Error messages will be displayed to the user by the module where the error was
detected.
24
3.
Data-structure Requirements
The
data-structure design for the representation of a
data model-language
MDBS. To
must incorporate features of both the model-language and
propose a generic data-structure which
new
accomplish
and allows expansion for features of the new model-language interface.
with data-structure representation
Any
types in the
data- structure
in the
fits into
development on
design for
MDBS.
MDBS,
In
order to
one must become familiar
programming language C.
MDBS
programming language C. Two derived
in the data- structure
we
requirements of the language interface
satisfies the
understand where the generic data-structure
this,
requires an understanding of derived
types, structure and union, are essential
Structures aggregate data of different types (derived
types included) into a single data type. Unions allow alternative values to be stored in a
single shared portion of the
memory.
types are useful in representing the
Integrated into
new
complex
data model-language.
these derived types, with examples, can be found in
The
structure
structure userjnfo,
data- structures, these derived
shown
in
A
detailed explanation of
[KELL]
Figure 12,
the building block of the data-
is
network which comprises each model-language
interface. This structure contains
a variable of the type union, lijnfo, which stores the data structure of the model-language
interface selected for execution.
into
MDBS
The implementation of new model-language
requires the modification of lijnfo to include a
model-language interface as shown
data- structure for
in
Figure 13. This
new model-language
new
new
structure
structure for the
is
userjnfo
{
char
union
ui_uid[UIDI_ength +1];
lijnfo
ui_li_type;
struct
user
*ui
Figure 12:
The User_info
info
next user;
}
25
Structure
new
our proposed generic
interfaces.
struct
interfaces
union
IMnfc
{
struct
sqijnfo
I
struct
dlijnfo
I
struct
_dml;
dmljnfo
dapjnfo
_dap;
new_model_language_info
_sql;
_dli;
I
struct
I
struct
Figure 13:
The
li_nml;
li_info Structure with the
new_model_language_info Included
The generic
data-structure for
new model-language
interfaces
is
a
C
structure
called newjnodel_langauge_info. This structure contains all the pertinent information
required by
MDBS,
including:
KMS, KC, KFS,
1.
Unions for the new model-language
2.
Operation flags to indicate user requests, operations, and errors.
3.
Structures for storing filenames, transactions, and data-definitions.
Specifics
of
the
new
new modelJangauge Jnfo
model-language
structure.
The unions
should
for
C
illustrates
the generic data structure
relationship to other data structures within
be
also
KMS, KC,
and
included
KFS
in
the
as well as the
model-language are stored therein.
structure types specific to the features of the selected
Appendix
and LIL.
newjnodelJangaugeJnfo and
its
MDBS.
All language-interface data-structures reside in the header file licommdata.h in the
Test Interface portion of
this file
and use the
interface.
Using a
especially useful
C
MDBS. New
model-languages must store
construct include in
common
file
all
programs of the new model-language
for the declaration of
when designing
their data- structures in
model-language data-structures
is
a cross-model access capability into a model-language
interface since each model-language has the access to the data- structures of the other
model-languages.
26
The Makefile Development
4.
As with
to
all
programs written
compile several related programs
programming language C, a makefile
in the
in
one
step. The
words, LIL,
KMS, KFS,
and
its
KC
own
of the
for the
KMS, KC,
resulting
in order to
compile
all
the
modules
indicate the appropriate directory to store
must also be recompiled due
to
at
one
include a makefile for each module
object code
all
from the compilation process. After compiling the new model-language
the Test Interface
new
and KFS, a single makefile should be
new model-language should
new model-language and
language interface of a
should each have a separate makefile.
developed for the new model-language interface
The makefile
in the
makefile for separate modular compilation. In other
After the development of LIL,
time.
used
programs which comprise a new
model-language interface are no exception. Each module
model-language should contain
is
changes made
to the
program
interface,
ti.c.
These
changes are a result of adding a new selection option for the new model-language interface
to the
MDBS
main menu. Appendix
D
illustrates a generic
makefile for a
new model-
language interface.
D.
THE VERSION CONTROL AND CONFIGURATION MANAGEMENT
With
the proliferation of
new model-languages,
present an area of concern to
introduced to the
and managed.
A
MDBS
the need of the version control will
system managers. As new model-languages are
MM&MLDS, new versions of the MM&MLDS software must be created
strategy
must be developed
to
ensure the proper documentation and
maintenance of its software when new versions of the
Coupled with the version control
is
MM&MLDS software is developed.
the configuration
management which must
also be
addressed.
The implementation of a new model-language
version of the
MM&MLDS
software.
The
interface results in the creation of a
latest version
of the
MM&MLDS
should be the only version residing on the system after testing and evaluation
27
is
new
software
completed.
Utilizing the tape drive on the front-end controller, back-up copies of the old version and
new
version should be
The version
software.
made
control
is
in
case of a catastrophic system failure.
not limited to changes or additions to the
MM&MLDS
System upgrades may require the modification of the existing backend software.
Therefore, the following steps must be followed
when
a modification occurs to
MDBS
software.
1.
Back-up old and new versions
to a tape.
Ensure only new version
is
resident on the
system.
2.
Properly label tapes and maintain a logbook indicating what modifications were
made
and why.
3.
Ensure
all
Through
specific data
the
MDBS
systems receive the updated version of the
the version control and configuration
new
software.
management, systems requiring only
model-language interfaces can modify the new version of the
MM&MLDS
software so that only those interfaces needed will be available for the selection. This can be
accomplished by deleting the statements and respective case statements for the unwanted
model-language interface
in
program
ti.c
of Test Interface.
The system manager can then
recompile Test Interface and delete any references to the unwanted model-languages from
the makefile. This simple process allows system
languages required
managers
to offer
only those model-
at his specific site.
Any mismanagement of the
MM&MLDS software can be costly. Slight modifications
(especially to Test Interface) can result in
minor errors
to a
system
failure.
aforementioned version control and configuration management strategy,
these problems.
28
we
Following the
will
minimize
IV.
GENERAL STEPS TO A NEW MODEL-LANGUAGE
INTERFACE
A.
THE MDBS USER INTERFACE
On
1.
the Interface Familiarization
The
menus
current version of the
for user interactions with
MM&MLDS
MDBS.
software utilizes
Prior to the design and
model-language interface, a period of familiarization
MDBS
idiosyncrasies of the
among
shells
a
new
understand
the
development of
needed
to
their
in
interfaces will exist on
own unique
MDBS.
An absence
fashion.
This will force users to have
understand and learn the processing steps of several different user interfaces,
the semantics, syntax,
and grammar of the new data model-languages.
problem, standardization of the user interface
is
standard and maintaining a level of consistency
Our
new model-language
development. Menus appearing
we
among
interface with
to the user in
user in the other model-language interfaces.
encounter
of
is
the
in addition to
because of
this
is
adhering to that
the different model-language
a guide for the
interface;
however,
this is
user interface
one data model-languages must appear
Of course, some
variation
the specifics of the model-language. For example, references to sets
focus
to
familiarization with previous model-language interfaces will provide the
designers of the
network/DML
It is
of
a must.
After establishing a standard, the problem
interfaces.
and scrolling
user interface. Without such experience, future model-
language interfaces will be constructed
standardization
is
C
to the
must be allowed
is
for
appropriate for an
not the case for an object-oriented interface. Our
placed on the general framework of the model-language interface with the specifics
model-language
incorporated
into
this
framework.
Maintaining
a
level
of
consistency amongst the different model-language interfaces will reduce both errors and
the confusion on the part of the user
interfaces.
Unique model-language
when
alternating
between different model-language
interfaces will detract
from the concepts of multimodel
and multilingual interfaces instead of enhancing the users understanding of the overall
29
concept of
MDBS.
In
Appendix D, we
illustrate a basic
framework
for model-language
interface design.
When we
discuss standardization of model-language interfaces,
user interface associated with the attribute- based data model-language.
The
we exclude
the
attribute-based
data model-language interface software resides outside the model/language interface
portion of
MM&MLDS.
Since
all
model-language interfaces are either transformed or
translated into the attribute- based data model-language, those functions specific to this
kernel data model-language should be separate from those model-language interfaces.
The
attribute-based data model-language interface contains the functions that allow direct
communication
with
the
backends
communicate with the backends via
14,
we show
unlike
other
model-language
interfaces
that
the attribute- based model-language interface. In Figure
the interface relationship
between the model-language interfaces and the
attribute-based model-language interface in regards to backend communication.
Test Interface
Figure 14: The Relationship Between Model/Language
Interfaces (ML/Is) and the Test Interface
2.
The User's Manual
MDBS
addressed the concept of federated databases and solutions
problems presented by heterogeneous databases. Therefore,
30
in a
to
the
classroom or research
environment,
MDBS
offers an excellent opportunity to (1) familiarize students with the
various data model-languages supported on
which
to further study the federated
MDBS
and
(2)
allow researchers a vehicle by
and heterogenous database concepts. Unfortunately,
in
MDBS.
the past, potential users required the expert assistance in order to properly operate
This placed a tremendous burden upon the user. The user had no written documentation of
how
to operate the
system and therefore was forced
This greatly diminished the learning objectives of
on figuring out how the system operated through
to learn the
MDBS,
trial
and
system by
since the user
error.
trial
and
error.
was more focused
This lead to frustration and
confusion on the part of the user.
In order to alleviate these problems,
we propose
manual which outlines every possible aspect of
were
intentions
to
set or user's
the user interaction with
MDBS. Our
design a manual that would be beneficial to both first-time users as well
as experienced users. Since
the user's
an instructional
manual
is
MDBS
is
such a valuable resource for instructional purposes,
also designed as a teaching aide for advanced database topics.
Therefore, a practical vice theoretical lab would be possible, giving the students a more
dynamic indoctrination
into
advanced database topics
students in the advanced database course
further their
CS4312
to the
MDBS
is
this time,
User's Manual to
new model- language
interface on
new model-languages. Topics covered
are:
1.
Multimodel and multilingual
2.
System overview.
3.
Starting the system
4.
Data-definition and request file development.
5.
Kernel data model-language interface
capabilities.
31
in the
is
the first
MDBS.
an excellent tool for familiarizing oneself with the idiosyncrasies of
required in the design of
Manual
MDBS
User's Manual, found in Appendix A,
step in the design and implementation of a
is
are using the
At
knowledge of database concepts.
The introduction
manual
in addition to lectures.
MDBS
MDBS
This
that
User's
DML,
6.
Execution of SQL,
7.
Execution of the cross-modeling access capabilities.
8.
UNIX
9.
Sample databases
aliases
and
C
and DL/I interfaces.
shells.
for the user familiarization.
As new model-languages and new functions
introduced to
effect
makes
MDBS,
the
to existing
additions and deletions to the user's manual
model-languages are
must be made. This
in
MDBS User's Manual a living document that can be updated as the system
grows. Furthermore, as students use the manual as a part of their classroom instruction,
clarifications
and modifications can be made
Through proper maintenance,
instructing
B.
MDBS
the
to further
enhance the learning process.
MDBS User's Manual is the most effective paradigm for
users.
OUR SOFTWARE METHODOLOGY
The design and implementation of
software design decisions that must be
introduction into
MDBS.
a
new model-language
made
to
ensure effective model-language interface
These decisions are a
result of
strategy needed for incorporating the idiosyncrasies of
syntax,
interface involves several
developing the best possible
MM&MLDS
with the grammar,
and semantics of the new model-language interface. Of the four modules
comprising the Model/Language Interface, the development of
amount of planning and preparation since
it is
in this
KMS
modules where
involves the greatest
the
grammar, syntax,
and semantics of the new model-language interface must be addressed. The other three
modules
in
mind,
rely
we
upon the design of
KMS
as a building block for their
own
introduce our software methodology for the design of a
interface. In order to understand our
methodology, three areas
models with no formal data language,
With
this
new model-language
critical to the
model-language interface software must be addressed. These are
interface for data
design.
(1)
(2) designing a
design of the
designing a
new
new
interface for
data models with a formal data language, (3) mapping strategies using the kernel model-
language.
32
Models With
1.
The
A Formal
introduction
Data Language
model-languages
of standardized data
MM&MLDS
into
requires the development of an implementation strategy that encompasses
constraints of the model-language. Since there
is
all
specified
the documentation
which specifies the
programmers
are not required to
constraints of the model-language, the designers and
develop the constraints for new model-language. Instead, they have the opportunity
themselves a useful programming tools to parse the data model and
ensure complete coverage of
all
These programming
new
data language to
possible constraint violations.
tools,
Lex and Yacc, allow parsing of an input stream
in the
data model-language for future conversion into the kernel data model-language. Lex
and Yacc are useful, since
language
is
its
to avail
their
modules can be incorporated
C and thus be included
in the
directly into the
programming
KMS portion of the Model/Language Interface.
Lex
a lexical analyzer which parses the input stream into recognizable tokens, these tokens
are then input into a compiler create
by Yacc. Yacc, which stands for Yet Another
Compiler-Compiler, creates a compiler which accepts the tokens from Lex and processes
them
in
a
finite-state
standardized,
all
automaton.
Since
the
data
model-language
constructs
are
possible accepting states of a valid string are identified and thus can be
incorporated into the finite-state automaton generated by Yacc. Further explanation of the
implementation and design of Lex and Yacc can be found
By
utilizing
model-language that
Lex and Yacc, we may have
is to
be introduced into
a
would allow
and
(2)
its
(1) the addition
[LESK and [YACC
]
more complete
MM&MLDS.
becomes standardized since being implemented on
should be converted from
in
If a
C
description of the data
model-language interface
MM&MLDS,
existing parser written in
].
the parser within
KMS
with a Lex and Yacc parser. This
and modification of constraints not found
in the original parser
produce a parser that covers the constraints of the standardized model-language. In
Figure 15
we
illustrate the role
of Lex and Yacc in the parsing process of
33
KMS.
Lexical specifications in
regular expressions.
i
input stream
Lexical Analyzer
_^Y
~
LEX
gSKon.
parse d tokens
|
inite-State
based
acceptable states
with valid tokenized
stream of data.
BNF
in
AutomatonA
YACC
grammar and/or syntax
errors
Figure 15:
2.
The Lex and Yacc Parsing
Processes.
Models With No Formal Data Language
With the
model-languages
proliferation of
may become an
new
data model-languages, the standardization of these
when no formally accepted
involved process especially
standard for the model-language has
become
available.
Such
the case of the Object-
is
Oriented Data Model and Data Language. The object-oriented data model-language
concept has been addressed throughout the database community; however, no acceptable
standard has been declared.
is
By
standard,
we mean
a data
model and
universally accepted and implemented; e.g. relational and
its
data language that
SQL are a standard data model
and a data language.
At the Laboratory
for
Database System Research,
model-languages into our system whether a data model and
its
we
intend to introduce
data language have
new
become
standardized or not. Without a standardized data model-language to incorporate into the
MDBS
system, the designers and programmers must develop their
proposed data model-language.
It is
this representation that
34
own
representation of a
must be developed prior
to
any
programming
efforts to ensure compatibility
standardized data model and
its
between the model and
its
language.
data language generally evolve from extensive research and
testing to ensure all possible integrity constraints are addressed. In the case of data
and
models
languages that are not standardized, extensive testing has not yet been
their data
conducted and thus the testing requirement
the
A
new model-language
standardized data model-languages
efficient parser to parse the data
language as addressed
upon the designers intending
MDBS. The documentation
on
interface
falls
is
to
implement
of integrity violations in
a tremendous aid in developing an accurate and
model and
in the next section.
language into the kernel data model-
its
This aid
is
not available to the designers of a
model-language with no formal data model-language. Because of
this, the
development of
a parser for a model-language interface with no formal data model-language
must be
written in a lower-level form without the benefit of higher-level, program-development
tools.
Another method of parser development
programming language
model-language.
C
Since
programmers
much
More
third
specifically,
the
BNF
we
can use
method
KMS
is
[LESK
be
developing
much
easier than using higher-level
78] and
[JOHN
for the
and
the
model-language
programming
tools
78]. This affords the designers
and
new model-language
data
is to
write formal specifications for the
write the regular expressions for
specifications for
LEX
and request of the new
will
spent
parser that uses the
parsing process.
method
we
KMS
time
the opportunity to incorporate the design of the
structures into the
The
design a
to effectively parse the data-definitions
representation, this approach
such as Lex and Yacc
is to
its
syntatic structures
YACC to
development of
code.
35
legitemate tokens.
We also write
and grammar. With these specifications,
generate the parser for
KMS
its
new model-language.
KMS
readily.
We
recommend
this
3.
Kernel Model-Language Mapping Strategies
In the case of a data
development of a language
model-language that has yet
to incorporate
suggest the third method mentioned in the previous section.
the
effort
expressions and
for the
MM&MLDS,
will be able to properly address considerations that
will save the design
is
of course
new model-language.
software methodology for the
programming of the new model-language
programming
The overhead
developing the formal specifications, both regular
BNF specifications,
By following our
programmers
to
be standardized, the
with the data model can be an involved process.
We
and time devoted
to
interface.
designers and
must be made
prior to the
Focusing on these issues prior
to
and program teams valuable man-hours developing a
software methodology which in incompatible with
36
MM&MLDS.
V.
A.
THE CONCLUSION
RESULTS OF OUR RESEARCH EFFORT
In this thesis,
we have developed
MDBS. By
language interfaces on
introduction into
MDBS,
a paradigm for the introduction of
detailing a three-step process to a
a noticeable reduction in
new model-
new model-language
development time spent on new model-
language interface incorporation will be realized. This paradigm will result
effective use of
MDBS
for both first-time user's and
therefore important for us to
As
summarize the
MDBS
of introducing a
User's Manual
is
new model-language
in the educational
advanced database
developers.
It is
multimodel and multilingual database
the first step that designers
interface.
must take
in the
process
This manual has also proven instrumental
environment as a supplement
students a vehicle with which to operate
more
efforts of our research.
a pedagogical aid for the instruction on the
system, the
new model-language
in a
MDBS
to the
classroom lectures by providing
and thus further
their
understanding of
topics.
The understanding of the procedures, methods, and
model-languages into
MM&MLDS
is vital
tools required for introducing
for designers of a
new
new model-language. From
our generic development algorithms for each software module of the Model/Language
Interface, designers will be provided with a
model-languages will be implemented. The
framework and foundation from which new
strict
smooth introduction of the new model-language
adherence
into
to these
algorithms will ensure
MM&MLDS. Our development of the
generic data structure also provides the needed foundation from which the specifics of a
new model-language may be implemented on
MM&MLDS.
Our explanation and
outline
of the relationship between the Test Interface and the Model/Language Interface sections
of
MM&MLDS
allows designers to focus upon the interaction which must take place
between the new model-language and the kernel database system. This
MM&MLDS process.
37
is
the heart of the
Our software methodology
a
new model-language
of
outlines considerations that
interface for
MDBS.
Addressing key issues that will face designers
new model-languages, our methodology provides
interface design
We
must be made when designing
options for more effective model-
and incorporation.
believe our paradigm
is
MDBS. The
model-language interfaces into
new
instrumental to the successful incorporation of
problems associated with heterogeneous
databases are facing organizations world-wide and especially in the Department of
Defense. The multibackend, multimodel, and multilingual approach to the database system
design
B.
is
an effective solution to these problems
FUTURE RESEARCH
The rapid growth of computer technology
MDBS.
Conversion of the current Laboratory of Database System Research
RISC architecture
will
soon be realized. Research
backend configuration on
this
new
architecture
With the successful incorporation of
Windows
will
TAE
the
in the area of the
Plus, a
new
generates code written in
new
Sun4
developers of
architecture,
user interface for
this interface
new
to
new
tools
will
Using a programming
MDBS,
MDBS
MDBS
tools such as
since
TAE
Xbe
tool
Plus
software readily.
The
TAE
The
written in
Plus.
would be an excellent research opportunity and allow
new model-languages
language by not having
MDBS.
and can thus be incorporated into
author has developed a prototype user interface for
implementation of
Sun4
must be addressed.
user interface could be designed for
C
to the
software portability and
be available for users and programmers. These
instrumental in the design of the
such as
have a tremendous impact upon
will
develop a
to focus
new
more on
interface.
38
the structure of the
new model-
APPENDIX
A.
MDBS USER'S MANUAL
LABORATORY FOR DATABASE
SYSTEM RESEARCH
Naval Postgraduate School
Monterey, California
The Multibackend Database System
(MDBS)
The Multimodel and Multilingual Database System User's Manual
Volume 1
by
Paul Alan Bourgeois
17
MDBS
Advisor:
Approved
December 1992
Dr. David K. Hsiao
for public release; distribution is unlimited.
TABLE OF CONTENTS
I.
II.
IE.
INTRODUCTION
A.
BACKGROUND
42
B.
SCOPE
42
SYSTEM OVERVIEW
A.
GENERAL
B.
MULTIMODEL/MULTILINGUAL CAPABILITIES
MDBS LANGUAGE INTERFACE SOFTWARE MODULES
C.
SCHEMA AND REQUEST FILES
A.
OVERVIEW
B.
C.
IV.
V.
VI.
VII.
VIE.
42
SCHEMA
FILES
REQUEST FILES
B.
44
44
46
48
48
48
50
GETTING STARTED AND RUNNING MDBS
A.
MDBS PROCESSES
B.
META-DISK MAINTENANCE
C.
SETTING UP THE USER'S SCREEN
THE RELATIONAL/SQL INTERFACE
A.
INTRODUCTION
B.
LOADING A NEW DATABASE
C.
PROCESSING AN EXISTING DATABASE
D.
THE MASS LOAD FUNCTION
E.
LOADING RECORDS USING SQL INSERT AND
PROCESSING OTHER TRANSACTIONS
THE NETWORK/CODAS YL INTERFACE
A.
INTRODUCTION
B.
LOADING A NEW DATABASE
C.
PROCESSING AN EXISTING DATABASE
D.
LOADING AND EXECUTING CODASYL
TRANSACTIONS VIA REQUEST FILES
THE HIERARCHICAL/DL/1 INTERFACE
A.
INTRODUCTION
B.
LOADING A NEW DATABASE
C.
PROCESSING AN EXISTING DATABASE
D.
REQUEST FILE ORGANIZATION FOR LOADING DL/1
TRANSACTIONS
THE CROSS-MODELING ACCESS CAPABILITY
A.
44
OVERVIEW
SCHEMA TRANSFORMATION
40
53
53
55
56
59
59
60
62
62
63
67
67
67
70
71
73
73
74
76
77
80
80
80
EXECUTING THE HIERARCHICAL TO RELATIONAL
CROSS-MODELING CAPABILITY
THE ATTRIBUTE-BASED DATA MODEL-LANGUAGE
INTERFACE
C.
IX.
A.
B.
C.
OVERVIEW
DATABASE CONSTRUCTS
THE ATTRIBUTE-BASE DATA MODEL INTERFACE
2.
The Template and Descriptor
The Mass Load File
3.
Executing the
1.
UM APPENDIX A:
A.
B.
3.
84
84
84
85
85
87
89
95
95
95
96
Shell
The stop.cmd C
The run C Shell
README FILE
97
Shell
98
THE
APPENDIX B: DEMO DATABASE EXECUTIONS
OVERVIEW
A.
B.
THE RELATIONAL/SQL INTERFACE
THE NETWORK/CODASYL INTERFACE
C.
THE HIERARCHIC AL/DL/1 INTERFACE
D.
THE CROSS MODEL CAPABILITY
E.
F.
THE ATTRIBUTE-BASED/ABDL INTERFACE
C.
UM
ABDM interface
USEFUL UNIX AND MDBS COMMANDS
THE .alias FILE
C SHELLS
1.
The zero C
2.
Files
81
41
99
101
101
101
102
103
104
104
I.
INTRODUCTION
BACKGROUND
A.
The Multi-backend Database System (MDBS)
at
NPS. Under
the direction of Professor
is
the research database laboratory
David K. Hsiao,
this
system provides a research
testbed for solutions to the problems of heterogeneous databases and design concepts
required for the development of a federated database system.
data language capability of
MDBS
The multiple data model and
allows the user to implement a wide variety of database
models and data languages on a single system. Through
its
cross-model access capability,
MDBS permits a user experienced in relational databases and the relational language SQL
to access a hierarchical
database by transforming the hierarchical schema into a relational
schema and thus allowing transactions written
Though
a transformation of
schema takes
in
SQL
to
access the hierarchical database.
place, this transformation
is
transparent to the
user.
B.
SCOPE
The scope of
MDBS.
this user's
Sections will include
database as well as
how
to
manual
how
to
will be to explain all user interface aspects of the
load and run a relational, hierarchical, and network
use the cross-model capabilities of the system.
Because the
system uses the data sharing method of multiple data model/language mapping
(or kernel) data model/language,
instructions are provided
execution of an Attribute Based Database
(ABDM)
(ABD)
models and data languages are provided throughout
overview of the system
is
files
this user's
Examples of
manual
Two
Model
certain data
as well as formats
necessary to build a database.
discussed in Chapter
hardware and software of MDBS. Appendix
on the development and
using the Attribute Based Data
and the Attribute Based Data Language (ABDL).
used to construct the schema and request
to a single
A
brief
to familiarize the user with the
A provides a glossary of key terms and UNIX
functions necessary for database implementation are also provided. Appendix
42
B
is
the step-
by-step instructions required to load, process, and execute
the four user interfaces on the
MDBS.
43
II.
A.
SYSTEM OVERVIEW
GENERAL
The Multibackend Database System (MDBS)
currently consists of six backend
computers and one controller computer. Each backend
a database processor with
is
its
own
micro-processor and database store. The backends are arranged in parallel in order to
maximize performance through
invariance.
response-time reduction, and response-time
scalability,
Both paging and meta-data
are stored are stored
Winchester type disk drives while the base data
Megabyte moving-head standard-type
Local Area Network. The controller
is
access to the meta-data and base data.
and recovery of the backends.
drives.
from the backends in
much
at the
larger
via an Ethernet
does not require
is to
provide backup
Naval Postgraduate School,
DB8
8) with the front tape drive, is the controller. Figure 2-1 illustrates the relationship
the forward controller and the
of the
MDBS. The number
number of connection
B.
slots
500
it
that
main function
controller's
On the MDBS
maintained on
The backends communicate
different
The
is
on separate 96 Megabyte
(ISIV
between
backend processors as well as the structure and organization
of backends the system can support
is
limited only by the
provided for the backend processors by the controller.
MULTIMODEL/MULTILINGUAL CAPABILITIES
In order to support
MDBS
unlike traditional
data language.
claim of being multi- model/multi-lingual,
models and data languages as well as
traditional data
language.
its
its
own
MDBS supports four
kernel data model and data
supports these data models and data languages on the same system
homogeneous database machines which support only one data model/
The four data models/data languages supported by
network/CODASYL,
MDBS:
relational/SQL,
hierarchical/DL/1, and functional/DAPLEX (Author's note: at the
time of this user's manual, the functional data model was in the process of being completed
on MDBS), are
is this
all
mapped
to a kernel data
model/data language on the
mapping process of the user's data model and data language
model and data language
that represent the heart of the
44
MDBS.
MDBS
system.
It
into the kernel data
The kernel data model used
its
for
MDBS
is
the attribute-based data
corresponding attribute-based data language (ABDL).
primary database operations:
and
DELETE. Through
RETRIEVE, RETRIEVE
clustering, the
ABDM
The
model
ABDM
COMMON,
(ABDM) with
supports the five
INSERT, UPDATE,
allows the base data to be partitioned into
mutually exclusive sets and these sets of clusters to be distributed to the backends
permitting parallel access to the base data.
Meta data
disk
Base data disks
"•-•' YiYi'i
Tape Drive
mm
i i i i
Paging disk
Meta data
disk
Base data disks
Meta data disk
Base data disks
Paging disk
Figure 2-1
Structure and Organization of
45
MDBS
C.
MDBS LANGUAGE INTERFACE SOFTWARE MODULES
Each data model/data language supported by
MDBS
has four language interface
software modules that perform the translation of the data model and data language into the
kernel data
model and data language. These four modules
(LIL), Kernel
Language
Interface Layer
Mapping System (KMS), Kernel Formatting System (KFS), and Kernel
Controller (KC).
A
detailed description of each
strategies for loading
new
databases to the
MDBS
interface
management system
how each
data model/data language
models linked
are the
to the
for
is
module as well
MDBS
as interface
management
system, and a prototype for a
can be found
in
[BOUR
93].
Figure 2-2 shows
composed of the four software modules, with
Kernel Database System (KDS) and eventually
to the
Figure 2-2
Multiple database interfaces linked to single kernel database
46
MDBS
all
data
Kernel Data
Model (KDM) and Kernel Data Language (KDL).
system on
new
A demonstration/class account cs4322
is set
password can be obtained from Professor Hsiao.
that
comprises the
MDBS
system as well as
up
An
MDBS
befoundin|HSIA91|.
47
to
execute the
MDBS
from DB3. The
in-depth description of the hardware
performance studies and
statistics
can
SCHEMA AND REQUEST FILES
III.
OVERVIEW
A.
Each of
file
the databases developed
and the option
to
use a request
schema
by
file
subdirectory of UserFiles but when the user
or request
file,
the user
must
system requires the use of a schema
schema and request
All
file.
the UserFiles directory in order to be used
that directory to verify if the
MDBS
on the
MDBS
since
MDBS
is
the
name
of the
is
MUST be resident in
hard
-
coded
to
check
actually exists. Files can be resident in a
is
prompted by the system
include the path
name
CREATE/QUERY
to input the
schema
starting with the subdirectory
followed by a forward slash, and then the schema or request
What
files
file
—
>
name
file
name
(Figure 3-1).
/DEMO/COURSEsqldb
Figure 3-1
Request
B.
for
SQL schema file
SCHEMA FILES
The schema
query language,
file
i.e.
that the descriptor
outlines the
SQL,
schema of the user's desired database
CODAS YL,
and template
DL1, or ABDL.
(the ".d
and
It is
.t" files)
in its respective
from the loading of
are generated
this file
by the Language
Interface Layer.
For
clarity, all
<database
files
should be
named
in the
namexthe acronym of the interface
For example,
should be
schema
if
a relational database
COURSEsqldb. There
is
no
name
is
language
COURSE,
file
(ie. sql,
then
restriction to this rule, but
have been developed, finding the corresponding schema
be lead to using the wrong schema
following convention:
and having
a dollar sign "$" on the last line of the file to
mark
48
file
schema filename
once several databases
when executing
to start over. All
the
its
dml, dli)>db
schema
a database can
files
must have
end of file. Otherwise, the parser
will
not find and
in
EOF mark
and not process the schema
Figure 3-2 through 3-4 and can also be found
Sample schema
file.
in the
cs4322 account
DEMO directory.
create table employee: Iname (char(8)),
fname
(char(8)),
ssn (char(9)),
sex (char(1))
@
create table job: essn (char(9)),
position (char(10))
@
create table pay: essn (char(9)),
salary (int(6))
$
Figure 3-2
SQL schema file EMPRECsqldb
name= sqd
segm name= co
field name= (sno, seq), bytes= 2
field name= sname, bytes= 2
segm name= maint parent= co
field name= (mdn, seq), type= int, bytes= 2
field name= mname, type= char, bytes= 2
segm name= ops, parent= co
field name= (odn, seq, m), type= int, bytes=
field name= oname, type= char, bytes= 2
segm name= acft, parent= ops
field name= (ano, seq), type= int, bytes=2
field name= aname, type= char, bytes= 2
dbd
,
$
Figure 3-3
DL1 schema
file
49
SQDdlidb
2
files are
in the
shown
UserFiles/
;
SCHEMA NAME
RECORD NAME
IS
NET1
IS
Supp;
DUPLICATES ARE NOT ALLOWED FOR SNO;
SNO CHARACTER 10.
SNAME CHARACTER 10.
CITY; CHARACTER 10.
RECORD NAME IS Parts;
DUPLICATES ARE NOT ALLOWED FOR PNO;
PNO CHARACTER 10.
PNAME CHARACTER 10.
CITY; CHARACTER 10.
RECORD NAME IS Purch;
SNO; CHARACTER 10.
PNO CHARACTER 10.
;
;
;
;
;
QTY; FIXED 4.
SET NAME IS SuppPurc;
OWNER IS Supp;
MEMBER IS Purch;
IS AUTOMATIC
RETENTION IS FIXED;
SET SELECTION IS BY VALUE OF SNO
SET NAME IS PartPurc;
INSERTION
IN
Supp;
OWNER IS Parts;
MEMBER IS Purch;
INSERTION
IS
AUTOMATIC
RETENTION IS FIXED;
SET SELECTION IS BY VALUE OF PNO
IN Parts;
$
Figure 3-4
CODASYL schema file SQDdlidb
C.
REQUEST FILES
The request
file
contains transactions the users wishes to process against a certain
database. These transactions are written in the appropriate data
data
model of
the database.
The format
for each request file is similar in that files
contain multiple transactions must have an
must have an end of
file
model language given
"@"
which
sign in between each transaction. All files
marker (denoted by the dollar sign) on the
50
the
last line
of the
file.
Sample request
files are
cs4322 account
in the
shown
in Figures 3-5
UserFiles/DEMO
through 3-7 and can also be found
directory.
select
*
from employee
@
select
*
from job
@
select
*
from pay
@
select
*
from employee
where sex = 'M'
@
ssnjname
from employee
where sex = 'F'
select
$
Figure 3-5
Figure Portion of SQL request
file
EMPRECreq
MOVE Sup1 TO SNO IN Supp
MOVE DEC TO SNAME IN Supp
MOVE MONT TO CITY IN Supp
STORE Supp
@
MOVE Parti TO PNO IN Parts
MOVE NUT TO PNAME IN Parts
MOVE MONT TO CITY IN Parts
STORE
Parts
@
MOVE
FIND
Sup1 TO SNO IN Supp
ANY Supp USING SNO IN Supp
GET Supp
$
Portion of
Figure 3-6
request
CODASYL/DML
51
file
NETIreq
in
the
build (sno,
sname)
:
('AiyV2')
co
isrt
@
build (mdn,
isrt
mname)
co (sno =
maint
:
(10,
'pr')
'A1')
@
build (odn,
isrt
oname)
co (sno =
:
(55,
'tp')
'A2')
ops
@
gu co
@
gu co (sno='A2')
ops
@
gnpops
$
Figure 3-7
Portion of DL1 request
SQDreq
52
file
GETTING STARTED AND RUNNING MDBS
IV.
Once
now
all
schema
begin running the
mdbs
MDBS
A
system.
files
have been constructed, the user can
directories
can use either the
used primarily for thesis research and therefore has numerous
is
from which the
number of backends
application.
Due
to
MDBS
system
that the user
may
run from and options exists to predetermine
wishes to use while running a particular database
constant manipulation and changes that occur from thesis research, our
focus will be placed on using the cs4322 account on the
key
MDBS
user logging into the
or the cs4322 account. Both accounts will log into their respective default directory.
The mdbs account
the
and optional request
files
UNIX commands
Logging
into
and
C
shells used to setup the
db3 with the cs4322 account
of db3/usr/work/cs4322.
db3
file for
Appendix
A covers
MDBS.
will take the user into the default directory
The subdirectory UserFiles
should contain the schema and request
terminal.
(or a subdirectory of UserFiles)
the database to be processed. If this has not
been done, the user must transfer his schema and request
files
the UserFiles
into
subdirectory (or a subdirectory of UserFiles).
Once
all
schema and request
files are
change directories from the default path
the following files exist:
stop.cmd*, zero*
Within the
to the subdirectory test.
test directory,
README, run*, stop.cmd*, zero*. The README file outlines
name
the limits for file
located in the proper directory, the user will
length, characters per attribute
commands
do.
A copy
of the
name
as well as
what the run*,
README file is provided in Appendix A
along with a listing of the run* stop.cmd* and zero* commands.
A.
MDBS PROCESSES
Prior to executing the run
still
running the
MDBS
command
system.
The
processes on your terminal whether you
run of the
the user
must verify
UNIX command
own
that there are
no processes
ps ax will display
all
active
those processes or not. Because an aborted
MDBS system can leave MDBS processes still running, the ps ax command will
53
:
help locate these processes and by using the
lingering processes.
Look
any process
for
PID TT STAT TIME
26590
26757
26758
26822
26827
26828
26829
26830
26831
26832
26833
26834
26835
26836
26837
26839
26844
26845
UNIX command
like those highlighted in
typing
1
COMMAND
I
I
I
I
I
I
I
I
I
I
I
p1
p1
kill
kill
those
I
S 0:00
S 0:00
rlogind
-csh (/bin/csh)
command
and the process number, you can terminate the extraneous processes.
kill
the extraneous processes
the shell file
running and
Figure 4-
kill
? IW 0:00 desktop -d console (/etc/getty)
pO 0:02 rlogind
pO IW 0:02 -csh (/bin/csh)
pO IW 0:00 /bin/csh run
pO 0:00 /usr/work/cs4322/VerE.6/CNTRL/scntgpcl.out
pO 0:00 /usr/work/cs4322/VerE.6/BE/sbegpcl.out
pO 0:00 /usr/work/cs4322/VerE.6/CNTRL/scntppcl.out
pO 0:00 /usr/work/cs4322/VerE.6/CNTRL/pp.out
pO 0:00 /usr/work/cs4322/VerE.6/CNTRL/iig.out
pO 0:00 /usr/work/cs4322/VerE.6/CNTRL/reqprep.out
pO 0:00 /usr/work/cs4322/VerE.6/BE/dirman.out
pO 0:00 /usr/work/cs4322/VerE.6/BE/cc.out
pO 0:00 /usr/work/cs4322/VerE.6/BE/recproc.out
pO IW 0:00 /usr/work/cs4322/VerE.6/BE/dio.out
pO 0:00/usr/work/cs4322/VerE.6/BE/sbeppcl.out
pO 0:01 /usr/work/cs4322/VerE.6/CNTRL/dblti.out
second method of
command;
you can
-
Figure 4-1
Result of executing the ps ax
By
kill,
them
as
is listed in
shown
is to
Appendix A,
use the stop.cmd
A
command. This
will find all the extraneous processes
in Figure 4-2. If the
stop.cmd command
is
issued and no
MDBS
processes are running on the system, the user will be notified that there are no
MDBS
processes to
kill
as
shown
in
Figure 4-3.
54
db3/usr/work/cs4322/test--38>stop.cmd
Stopping MBDS processes
killing 26827 26828 26829 26830 26831 26832 26833 26834 26835
26836 26839
Figure 4-2
Result of the stop.cmd
command
db3/usr/work/cs4322/test--4> stop.cmd
Stopping MBDS processes
killing
kill:
Too few arguments.
Figure 4-3
Executing the stop.cmd command
with no MDBS processes running
B.
META-DISK MAINTENANCE
Upon
there
is
verification that
no extraneous processes are running, the user must ensure
no existing database currently loaded
the alias pry, this
pry command
command
will display
4-4, then the data disk
is
0000000
will
to the system.
check the disk
what data
is
to
on the disk,
make
if
This
is
that
accomplished by using
sure there
is
no data on
it.
The
the line displays zeroes, as in Figure
clean and you are ready to execute the
MDBS
system.
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
\0
*
Figure 4-4
Clean meta-disk
However, there may be an existing database stored on the
pry command
will look similar to Figure 4-5.
55
disk,
and the result of the
000000
0000016
003
\0 \0
E
M
R
P
C
E
\0 \0 \0 \0 \0 \0 \0
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
Figure 4-5
Meta-disk with existing data
The zero command
loading a
new
will let the user clean the meta-disk of
any existing
database to the system must ensure that the meta-disk
is
Users
data.
clean or the
execution of the database will crash. Figure 4-6 displays what the user will see after
executing the zero
command.
Provided the user has either clean the meta-disk or plans to process an existing
now
ready to execute the
database, the user
is
user will type the
command
takes place after the run
run to start the
command
described in this manual
is
is strictly
MDBS
MDBS
system.
From
the test directory, the
interface. Figure 4-7 illustrates
entered. (Author's note:
The execution of
the
what
MDBS
for use with the class account cs4322. Execution of the
MDBS using the thesis research account mdbs is accomplished in various ways with options
to select the
number of backends
the user wishes to use. Since current thesis research
is
being conducted in the area of user selection of backends, a future appendixes appear in the
next edition of the
MDBS
C.
MDBS
User's Manual, will outline the steps necessary to execute the
using the thesis research account mdbs.).
SETTING UP THE USER'S SCREEN
It is
advisable that the user use two
C
shells while operating the
MDBS
system.
shell will be used strictly for database execution while the other shell will be
checking the UserFiles directory for ensuring that
that the user
can verify that
all
class account, the user will
necessary database
all
processes are running.
have
six
When
running the
backend (BE) processes running and
(CNTRL) processes running. These processes are highlighted in Figure 4-1.
not have
kill
all
these processes running, then the user
must
exit the
and so
from the
six control
If the
user does
system using Control-c,
any extraneous processes with the stop.cmd command, double check
56
used for
files exist
MDBS
One
to
ensure no
extraneous processes are running using the ps ax
zeroed, and then restart the
MDBS
command, ensure
system using the run
the data disk has been
command
db3/usr/work/cs4322/test-
39>zero
No match.
No match.
File to
zero = /dev/sd1c
File size = 105638400
Bytes to zero = 8000000
Bytes written...
819200
1638400
2457600
3276800
4096000
4915200
5734400
6553600
7372800
8000000
Figure 4-6
Result of the zero command
As seen
in
Figure 4-7, The Multi-Lingual/Multi-Backend Database System
Menu
own
unique
offers an assortment of database
models
to choose.
Since each interface has
idiosyncrasies, the next section four sections will
Hierarchical, and
ABDM
the Relational,
database models and respective user interfaces.
the database the user desires to implement, the
execute the
examine
commands and
Network,
Regardless of
steps used to prepare and
MDBS pertain to all data models implemented on the MDBS
57
its
system.
db3/usr/work/cs4322/test--42> run
2]
29569
29570
3]
29571
1]
4] 29572
5] 29573
6] 29574
7] 29575
8] 29576
9] 29577
10] 29578
11] 29579
The Multi-Lingual/Multi-Backend Database System
Select an operation:
(a)
-
(r)
-
(h)
-
(n)
-
(f)
-
(x)
-
Execute
Execute
Execute
Execute
Execute
the attribute-based/ABDL interface
the relational/SQL interface
the hierarchical/DL/l interface
the
network/CODASYL
interface
the functional/DAPLEX interface
Exit to the operating
system
Select->
Figure 4-7
Result of executing the run
58
command
V.
A.
THE RELATIONAL/SQL INTERFACE
INTRODUCTION
The
Hence,
relational interface
all
on the
MDBS
interface will resemble Figure 3-2 using the basic
The user must ensure
At
as the data
model language.
request files developed in conjunction with the relational interface will use
The schema
statements to manipulate the relational database.
MDBS
SQL
system uses
the request and
schema
SQL
for the relational/SQL
file
SQL constructs to create the schema file.
created prior to execution of the
files are
system.
this point, the user
command and
has entered the run
Lingual/Multi-Backend Database System
Menu
as
shown
is
looking at the Multi-
in Figure 4-7. Select r for the
relational/SQL interface and the system will prompt the user for the operation desired
(Figure 5-1). Select option(l) to load a
new
database, (p) to process a database currently
Enter type of operation desired
Action
(I)
-
(p)
-
(x)
-
new database
process existing database
load
MLDS/MBDS
return to the
system menu
—>
Figure 5-1
System prompt to load a new or process an existing database
resident on the systems data disk, or (x) to return to the Multi-Lingual/Multi-Backend
Database System Menu. After selecting option
database
name
(Figure 5-2). If the user
is
(l)
loading a
or (p) the user will be
new database,
the
should (for clarity) give an idea of what the database represents
schedules could be called
base,
it is
SCHEDULE).
If the
prompted for the
name
(i.e.
of the database
a database of class
user desires to process an existing data-
imperative that the database exist or the system will endlessly loop asking for
the database
name.
If this situation presents itself, enter
59
Control-c
to abort the
system and
start
again as described in the Getting Started section. The database
in all capital letters or
small case
letters, there is
Enter
name
of
no
name may be
written
restriction.
database
— ->
Figure 5-2
Enter database
B.
name prompt
LOADING A NEW DATABASE
Loading a new database
schema
differs
from processing an existing database
(Figure 5-3).
developed
(this is
the terminal.
The
mode
user must either select option
of input desired to load the schema
and have a schema
(f)
highly recommended) or select the option
Option
(x) will take the user
instructions are provided
if
back
mode
(t)
from a
read
in
a group
read
in
creates from the terminal
Action
return to the
of creates
file
main menu
—>
Figure 5-3
Loading of the schema
After selecting option
menu. Unscrewing
of input desired
(t) -
already
(t).
(f) -
(x)
file
of loading the schema from
to the type of operation
the user selects option
Enter
file. If
new
for the database has yet to be loaded to the system. After the user has entered the
database name, the user will be prompted as to the
file
in that the
(f)
the user will be
file
prompted
to enter the
the file resides in a subdirectory of UserFiles, the user
directory that the file resides as
shown in Figure
60
5-4.
name
of the schema
must provide the path of the
As covered in the Schema and Request
File section of this
(the.t
and
manual, the schema
create the template and descriptor files
file will
.d files).
What
is
the
name
of the
CREATE/QUERY file
— -> DEMO/EMPRECsqldb
Figure 5-4
Enter
The
MDBS
file
system will parse the schema
name prompt
file
model language, ABDL. The parse
the kernel data
schema
schema
and transform the relational schema into
will determine
what the
relations of the
are and a screen will appear displaying the relations and a opportunity to index
attributes in the relation if so desired. Figure 5-5 illustrates this action.
The
following are the Relations
in
the
EMPREC
Database:
EMPLOYEE
JOB
PAY
Beginning with the
first
Relation,
You
we
will
present each
be prompted as to whether
as an Indexing Attribute,
and, if so, whether it is to be indexed based on strict
EQUALITY, or based on a RANGE OF VALUES. If you do not want
to enter any indexes for your database, type an 'n' when
the Action -> prompt appears
Attribute of the relation.
you wish
Strike
RETURN
Action
will
to include that Attribute
—>
or
'n'
when ready
to continue.
Figure 5-5
Relations from a relational
If the user desires to
indexing
is
desired.
In
file
and
attribute indexing
index attributes, onscreen instructions will direct the user
properly index the attributes.
if
schema
The user
most
will traverse through all relations
cases, the indexing is not used.
61
and every
how
to
attribute
The user has now completed loading
system.
to
Once
the
new database schema
onto the
MDBS
the user has either finished indexing the appropriate attributes or desired not
index attributes, the user will be prompted by Figure 5-1 and will select option (p) to
process an existing database
C.
PROCESSING AN EXISTING DATABASE
In order to process an existing database, the user will select
and will be prompted
schema now
exists
to enter the
MDBS
on the
database
name
system, the user
option (p)
as in Figure 5-2.
may now
in
Figure 5-1
Since the database
input records into the system.
After inputting the database name, the user will receive the screen display in Figure 5-6.
Options
two use
(f), (t),
and (m)
all
SQL transactions to
provide a means to input records into the database. The
insert records into the database (as well as other transactions)
while the third option allows the user to input several records into the database from a
This option
is
the
first
mass load function and
mode
Enter
read
read
it is
only offered with the relational interface.
of input desired
in
a group
in
queries from the terminal
of queries
from a
(f)
-
(t)
-
(m)
-
mass
(d)
-
display the current database
(x)
-
return to the previous
Action
file.
load a
file
file
schema
menu
—>
Figure 5-6
Record input menu
D.
THE MASS LOAD FUNCTION
The mass load function
is
a unique
method of loading records
database. Without having to write several
numerous records
INSERT
into the database using the
transactions in
mass load
option, the user will be
prompted
62
SQL,
the user can load
mass load function. All mass load
contain the suffix ".r" and should be prefaced by the database
selecting the
into each relation of the
for the
name
files
for clarity. After
mass load
file as in
Figure
Figure 5-8
5-7.
an example of a mass load
is
file.
The system
will not read the space
file
must be maintained
in the
Enter
a
TAB
file,
the
and not the
produce by the spacebar and assume one large
As with
attribute value or crash the system.
developing a mass load
must be separated by
space in between attribute values along a tuple
spacebar.
When
the
schema and request
files, the
mass load
UserFiles directory or a subdirectory of UserFiles
name
of record
file
— -> DEMO/EMPREC.r
Figure 5-7
Prompt
After indicating the mass load
to input
file
mass
name, a
load
file
ABDL
series of
appear. If this does not happen then there has been an error in the
A
system will crash.
the
mass load
load option does not replace the traditional
faster
method of initializing
INSERT command
mass load
file
and the
period of inactivity greater than 20 seconds indicates problems with
and the necessity for the user
file
insert statements will
to abort the
SQL INSERT command
a database with base data.
to load the database is
system and
still
The
traditional
a viable option on
restart.
The mass
but merely offers a
method of using
SQL
MDBS.
LOADING RECORDS USING SQL INSERT AND PROCESSING OTHER
E.
TRANSACTIONS
user desires to insert records into the relational database via the traditional
If the
SQL INSERT commands
method of using
and/or wishes to process
against data currently residing on the database, option
maintain a
a
list
file
of the
prompt
will be chosen.
transactions
The user must
within the UserFiles directory (or a subdirectory of UserFiles) that contains
SQL
transactions to be processed against the relational database. This file
commonly known
A
(f)
SQL
as the request file and the file
name
is
always contains the suffix "req".
will appear after option (f) is selected requesting the user to input the
the request file (Figure 5-9). Figure 3-5
shows an example of a request
63
is
file
name of
developed for
the
EMPREC database. An explanation of request file format is covered in the Schema and
Request
File section.
EMPREC
@
EMPLOYEE
JOHN
JONES BETTY
HART
PETE
SMITH
THOMAS
TINA
JUDY
KEWIN
111111111
222222222
333333333
444444444
555555555
M
F
M
F
M
@
JOB
MANAGER
222222222 MANAGER
333333333 ACCOUNTANT
111111111
444444444
SECRETARY
@
PAY
111111111 50000
222222222 60000
333333333 45000
444444444 30000
$
Figure 5-8
Mass load file
What
is
the
name
of the
CREATE/QUERY file
Figure 5-9
Prompt for request
After inputting the request
multiple transactions on one
file is
left
will
MDBS
file
will scan the request file and, in the case of
number each
transaction. If the display of the request
longer than the screen display, the -more- prompt will be displayed in the bottom-
comer of the
of the
file,
file,
— >EMPRECreq
file.
active
For longer
window. Pressing the return key will display the remaining contents
files, this
process
may
be repeated several times before reaching the
64
end of file. Once the transactions
in the
request
have been displayed
file
to the user, a
menu
selection, as seen in Figure 5-10, will appear requesting the user to either execute a
transaction, redisplay the contents of the request
Note
that the first
two options
will execute
or exit back to the previous menu.
and then return
the user decides to use another request file or
to the
must enter
menu
entering option (x) will send the user to the
The
file,
in
menu
in
Figure 5-10.
It
a transaction via the terminal,
Figure 5-6
user will process transactions against the database by simply entering the
number
of the transaction after the Action prompt in Figure 5-10.
The
for semantic and syntactic correctness and,
an appropriate message will be
displayed.
A
if in error,
serious error violating the conventions of the data language could result in a
catastrophic error causing a bus error (core
number
Pick the
(num)
-
dump) and
the need to restart the system.
or letter of the action desired
execute one of the preceding queries
of queries
(d)
-
redisplay the
(x)
-
return to the previous
Action
file
menu
--
Figure 5-10
Transaction execution
If
menu
a transaction processes correctly, a display of the
transaction will be given and, in the case of a
the query.
transaction will be checked
This
is illustrated in
translation of the
SQL
RETRIEVE operation, the data resulting from
Figure 5-11.
Appendix B outlines the steps necessary
relational database
ABDL
EMPREC on the MDBS
65
to load
and process the demonstration
[
RETRIEVE (TEMP = Employee)(LNAME, FNAME, SSN, SEX)
LNAME
|FNAME
|SSN
|SEX||
SMITH
|JOHN
|BETTY
|PETE
1111111111
|M
JONES
HART
THOMAS
JUDY
222222222
IF
|333333333
|444444444
|M
JTINA
IKEWIN
I555555555
IM
IF
Figure 5-11
Result of a
SQL
retrieve operation with
66
ABDL translation
]
VI.
A.
INTRODUCTION
The network
all
THE NETWORK/CODASYL INTERFACE
interface
network data models.
on the
MDBS
system uses
schema and request
All
CODASYL as the data language for
files require
order to construct and manipulate the network databases on
network/CODASYL
interface will resemble Figure
constructs to create the
schema
file.
are created prior to execution of the
At
this point, the user
that the request
CODASYL
and schema
files
system.
has entered the run
Lingual/Multi-Backend Database System
statements in
MDBS. The schema file for the
3-4 using the basic
The user must ensure
MDBS
CODASYL
Menu
command and
as
shown
is
looking
at the Multi-
in Figure 4-7. Select
n for the
network/CODASYL interface and the system will prompt the user for the operation desired
(Figure 6-1). Select option
(I)
to load a
new
database, option (p) to process a database
Enter type of operation desired
load
(I) -
Action
(p)
-
(x)
-
new database
process existing database
return to the operating system
—>
Figure 6-1
System prompt to load a new or process an existing database
currently resident on the systems data disk, or option (x) to return to the Multi-Lingual/
Multi-Backend Database System Menu. After selecting option
prompted
name
for the database
name
(Figure 6-2). If the user
is
(l)
or (p) the user will be
loading a
new
database, the
of the database should (for clarity) give an idea of what the database represents
a database of parts records could be called
ing database,
it is
PARTS).
If the
start
user desires to process an exist-
imperative that the database exist or the system will endlessly loop ask-
ing for the database name. If this situation presents
system and
(i.e.
itself,
enter Control-c to abort the
again as described in the Getting Started section. The database
67
name
may
be written in
all
capital letters or small case letters, there
Enter
name
of
is
no
restriction.
— ->
database
Figure 6-2
Enter database
B.
name prompt
LOADING A NEW DATABASE
Loading a new database
schema
differs
from processing an existing database
new
for the database has yet to be loaded to the system. After the user has entered the
database name, the user will be prompted as to the
file
in that the
mode
of input desired to load the schema
(Figure 6-3). Notice the difference between input options presented in the network
interface
and the relational interface (Figure
the option to input a
file exists prior to
The network
the terminal. Therefore
it
is
interface does not provide
imperative that the schema
executing the network interface since further processing will not be
schema
possible without a
menu
schema from
6-3).
Selecting option (x) will take the user back to the previous
file.
(Figure 6-1).
Enter
mode
(f) -
(x)
Action
-
of input desired
database description from a
return to the to main menu
read
in
—>
Figure 6-3
Loading the schema
After selecting option
file. If
(f)
the user will be
file
prompted
to enter the
the file resides in a subdirectory of UserFiles, the user
directory that the file resides as
Request
shown
File section of this manual, the
files (the.t
and
file
in Figure 6-4.
schema
.d files).
68
file will
name
of the schema
must provide the path of the
As covered
in the
Schema and
create the template and descriptor
What
is
the
name
of the
DBD/REQUEST
file
— ->DEMO/NET1 dmldb
Figure 6-4
Prompt
The
to enter
network schema
file
name
MDBS system will parse the schema file and transform the network schema in the
kernel data model. Attribute Based Data
Attribute Based Data
Model (ABDM), and kernel data language,
Language (ABDL). The parse
will determine the records that
comprise the network database schema. The next screen will
database as a result of reading the network schema
file
list
the records of the
(Figure 6-5). Also available
opportunity to index attributes for selected records in the database.
The
following are the
Records
in
the
network
If
is
the
the user desires to
NET1 Database:
SUPP
PARTS
PURCH
Beginning with the first Record, we will present each
Attribute of that Record. You will be prompted as to whether
you wish to include that Attribute as an Indexing Attribute,
whether it is to be indexed based on strict
or based on a RANGE OF VALUES. If you do not want
to enter any indexes for your database, type an 'n' when
the Action -> prompt appears
and,
if
so,
EQUALITY,
Strike
RETURN
Action
—>
or
'n'
when ready
to continue.
Figure 6-5
Records from a network schema and
attribute indexing
index attributes, a prompt will appear for every attribute in every record as to whether
index values for that attribute are desired. In most cases, indexing of attributes
The user has now completed loading a new network database schema onto
system.
Once
is
not used.
the
MDBS
the user has either finished indexing the appropriate attributes or desired not
69
to
index attributes, the user will be prompted by Figure 6- 1 and will select option
(
p) to
process an existing database.
C.
PROCESSING AN EXISTING DATABASE
In order to process an existing database, the user will select
and will be prompted
to enter the database
database schema on the
MDBS,
the user should
CODASYL
make
in a
as in Figure 6-2.
may now execute
no records stored
the database. Since there are
schema had been loaded
the user
name
option (p)
in the
Now
in
Figure 6-1
that the
network
CODASYL transactions against
database
at this
time (unless the
previous session and records were added during that session)
the first group of transactions in the request file
MOVE and STORE
transactions, in order to load the database with data prior to processing any
query transactions.
The record input menu, Figure
name. Options
request
file
(f)
and
(t)
6-6, will appear after inputting the correct database
provide the user the opportunity
or through the terminal respectively. If option
unsure that the request
mode
Enter
(t) -
Action
file
CODASYL
in
a group
in
CODASYL
of
requests from a
requests from the terminal
(d)
-
display the current database
(x)
-
return to the previous
file
schema
menu
—>
the request
and "req" as a
chosen, the user must
resides in the UserFiles directory or a subdirectory of UserFiles.
Figure 6-6
CODASYL record input
The name of
(f) is
of input desired
read
read
(f) -
file
should use the
suffix, thus the
PARTSreq. Additional request
identify
to either input transaction via a
how many
request
name of
files
name
menu
of the database
the request
file
for the
(i.e.
PARTS
can have an additional numerical
files exist for
PARTS)
as a prefix
database would be
suffix after "req" to
a database. Figure 3-6 illustrates a sample
CODASYL request file. An explanation of the format used for request files is found in the
70
Schema and Request Hie
I).
section of this manual.
LOADING AND EXECUTING CODASYL TRANSACTIONS VIA REQUEST
FILES
After select option
name
a
the
list
the user will be
The user will
as in Figure 6-7.
numbered
(f),
prompted
to enter the
enter the appropriate
of transactions will appear on the screen.
CODASYL request file name and
If
the
-more- message appears
bottom lefthand corner of the screen, simply press Return
request
file.
selection as
After
shown
all
in
CODASYL request file
review the
to
in
rest of the
transaction have been displayed, the user will be displayed a
menu
Figure 6-8.
What
is
the
name
DBD/REQUEST file
of the
— ->
Figure 6-7
Prompt
Pick the
number
(num)
Action
-
for
CODASYL
execute one
Attribute
preceding
of the
CODASYL
(d)
-
redisplay the
(x)
-
return to the previous
file
of
CODASYL
requests
requests
menu
—>
Figure 6-8
transaction execution
CODASYL
The user may now begin executing
Figure 6-8.
file
or letter of the action desired
CODASYL
entering the
request
number corresponding
If a
transactions against the database by
to the transaction desired at the
CODASYL STORE
transaction
Based Data Language (ABDL)
return to Figure 6-8 for further processing.
ABDL translation
menu
is
Action
— > prompt
in
executed, the system will display the
translation of the
CODASYL
request and then
A CODASYL GET transaction will generate an
followed by the display of data from the query and then Figure 6-8 for
further processing. If the user executes a
CODASYL ERASE or MODIFY transaction, the
71
system will only display the
ABDL translation of the CODAS YL request and will return to
Figure 6-8 upon completion. In order to ensure
transaction accomplished
request
file that
Any
all
STORE, ERASE, and MODIFY
what was desired, the user should include transactions
verify the correctness of these three transactions
errors that
may result from
violations of integrity constraints will be displayed to
the user Catastrophic errors violating the conventions of the data language
system crashing and
(x)
up
to the
in the
restart of the
system necessary. The user
Multi-Lingual/Multi-Backend Database System
CODASYL database.
Appendix B provides
may
may result in the
simply follow the option
menu when
finished with the
a quick reference for executing the network/
CODASYL interface
72
THE HIERARCHICAL/DL/1 INTERFACE
VII.
A.
INTRODUCTION
The
hierarchical interface on the
Schema and
hierarchical data models.
MDBS
uses DL/1 as the data language for
request files used in the hierarchical interface must
MDBS.
use DL/1 statements in order to manipulate the hierarchical database on
3
is
an example of a DL/1 schema
schema
file
must be created prior
file.
to
all
As
in the case of the
execution of the
MDBS
Figure 3-
network database, the DL/1
since
schema creation
is
not
possible through terminal input.
The user has executed
the
the
run command from the
UNIX prompt and should now have
Multi-Lingual/Multi-Backend Database System Menu, as shown
displayed.
To begin
operations
menu will appear (Figure
Figure 4-7,
in
the hierarchical/DL/1 interface, select option (h) and the desired
menu. Whether the user
7-1).
selects option
(I)
Option
(x) will return the user
or (p), the next
prompt
back
to the
MDBS
will request the user to
Enter type of operation desired
load
(I) -
Action
new database
(p)
-
process existing database
(x)
-
return to the operating
system
—>
Figure 7-1
System prompt to load a new or process an existing
database
input the database
name
as
shown
in Figure 7-2. If processing an existing database, the
user should check the metadisk with the pry
that the database
name
schema
is
command
prior to running
MDBS
to
ensure
resident on the system. If the user does not correctly input the
of an existing database, Figure 7-2 will infinitely loop until the user inputs an exist-
ing database name.
system.
Control-c will exit the user from the
If this situation
occurs, the user must kill
73
all
infinite
loop and also the
MDBS
processes using the stop.cmd com-
mand and
There
restart the system.
the database
name,
it
is strictly
B.
restriction as to the case of the letters
name
prompt
of
database
— ->
Figure 7-2
to enter database
name
LOADING A NEW DATABASE
Loading a new database
schema
differs
from processing an existing database
in that the
new
for the database has yet to be loaded to the system. After the user has entered the
database name, the user will be prompted as to the
file
comprising
the users preference.
Enter
MDBS
no
is
mode of input desired
to load the
schema
(Figure 7-3). Notice the difference between input options presented in the hierarchical
interface
and the relational interface (Figure
the option to input a
file exists
The network
the terminal. Therefore
it is
interface does not provide
imperative that the schema
prior to executing the network interface since further processing will not be
possible without a
menu
schema from
5-3).
schema
file.
Selecting option (x) will take the user back to the previous
(Figure 7-1).
mode
Enter
(f) -
(x)
Action
of input desired
database description from a
return to the to main menu
read
-
in
file
—>
Figure 7-3
Loading the hierarchical schema
After selecting option
file. If
(f)
the user will be
prompted
to enter the
the file resides in a subdirectory of UserFiles, the user
directory that the file resides as
Request
files (the
shown
File section of this manual, the
.t
and
in
Figure 7-4.
schema
.d files).
74
file will
file
name
of the schema
must provide the path of the
As covered
in the
Schema and
create the template and descriptor
What
is
the
name
of the
DBD/REQUEST
file
— ->DEMO/SQDdlidb
Figure 7-4
schema filename
Entering the hierarchical
The
MDBS
system will parse the schema
data model. Attribute Based Data
in the kernel
file
and transform the hierarchical schema
Model (ABDM), and
Attribute
Based Data Language (ABDL). The parse
compose
the hierarchical database schema.
will
described in Figure 7-5, the user
segment
is
determine the segments that
The next screen
hierarchical database as a result of reading the hierarchical
kernel data language,
will
list
schema
the records of the
file
(Figure 7-5).
As
given the opportunity to index specific attributes of each
in the hierarchical database.
Indexing
the user does opt to use attribute indexing,
all
is
not a required function of
attributes in every
segment
MDBS
and
if
will be screened
for possible indexing.
The
Segments
following are the
in
the
SQD
Database:
CO
MAINT
OPS
ACFT
first Segment, we will present each
Segment. You will be prompted as to whether
you wish to include that Field as an Indexing Field,
and, if so, whether is to be indexed based on strict
EQUALITY, or based on a RANGE OF VALUES. If you do not want
to enter any indexes for your database, type an 'n' when
the Action --> prompt appears
Beginning with the
Field of that
it
Strike
RETURN
Action
—>
or 'n'
when ready
to continue.
Figure 7-5
Segments from a
hierarchical
schema and
attribute indexing
After completing the action in Figure 7-5, the user has
hierarchical
schema
to the
MDBS
system and
is
75
ready
to
now
successfully loaded the
process DL/1 transactions against
the database.
The user
prompted by Figure 7-1 and
will be
will select
option (p)
an existing database. Figure 7-2 will appear prompting the user for the database
process. Enter the
name
of the database
process
to
name
to
whose schema was just loaded.
PROCESSING AN EXISTING DATABASE
C.
In order to process an existing database, the user
been loaded
the
schema
to the
file
MDBS.
If the
schema
file
must ensure
that the
schema
has not been loaded, select option
When
as described in the previous section.
(I)
file
has
and load
processing an existing
database, the user has the opportunity to load data into the database, execute queries, as well
as
modify and delete existing records.
If the
schema
file
has just been loaded to the system,
the user should ensure the first group of transaction processed against the database are used
to load initial data into the appropriate
As
segments.
with the other data models, the user will have the option of executing DL/1
transactions using a request file with transactions or creating transactions at the terminal as
illustrated in Figure 7-6. If the user
the
same convention
chooses option
as outlined in the other data
Database section for Network
interface).
user opts for terminal input of
DL/1
A
(f),
mode
the request file should be
named
in
sections (see Processing an Existing
DL/1 request
file is listed in
Figure 3-3.
transactions, onscreen instructions will explain
If the
how
to
properly enter and format the transactions.
Enter
mode
(f) (t) -
(x)
Action
-
of input desired
read
read
a group
in
DL/1 requests from the terminal
of DL/1 requests
return to the previous
menu
Figure 7-6
of input for DL/1 transactions
REQUEST FILE ORGANIZATION FOR LOADING
With
file
—>
Mode
D.
from a
in
DL/1
TRANSACTIONS
the hierarchical database, any records loaded to the database
hierarchical order with those records belonging to the root
76
must be done
segment loaded
first,
in a
children
segments second and so
1
BUILD commands
When
forth.
creating your request
beginning of the
at the
file
file, it is
and ordered
easier to put the
in a hierarchical
DL/
fashion in
regards to the hierarchy of the segments.
After choosing option
(f)
or
(t),
the user will be given a numerical listing on the screen
of the DL/1 transactions either entered via a request
the
-more- message appears
Return
review the
to
Network/CODASYL
file
or through direct terminal input. If
bottom lefthand corner of the screen, simply press
Note, after selecting option
rest of the request file.
be prompt to input the request
name
in the
same manner
(f ) the
user will
as discussed on page 28 in the
interface section and illustrated in Figure 6-7.
Upon completion
transactions
in the
file
of the transaction
from the menu
in
the user will be ready to execute those
list,
Figure 7-7. Unlike the relational and network interface, the
hierarchical interface has a currency pointer
transaction that uses a
DL/1
BUILD command
which
starts
must begin
at the root
at the root
segment.
segment
Any
in order to
load data onto the database. Therefore, option (r) must precede the selection of option
(
num
)
for every
BUILD transaction issued so that the data in the transaction can follow the
Pick the
number
(num)
(d)
(r)
(x)
Action
or letter of the action desired
execute one
preceding DL/1 requests
- redisplay the file of DL/1 requests
- reset the currency pointer to the root
- return to the previous menu
-
of the
—>
Figure 7-7
DL/1 transaction execution
path
down
the hierarchy to the segment
where
the data
menu
is to
be stored. Figure 7-8 shows a
sequence of resetting the currency pointer and executing a transaction. Note that a
cation message
using
is
given upon any
GU, GHU, GNP
tions will
BUILD, IRST, and REPL
will display the data requested and
have the equivalent
ABDL translation displayed
77
transaction and
all
verifi-
queries
no message. All DL/1 transacon screen
after successful exe-
cution.
The user can see from
ABDL translation how
the
the database hierarchy in order to reach
GU
After executing a
its
the transaction
is
traced through
destination segment.
transaction (Get Unique),
if
the next transaction
is
a
Next Pointer) within the same segment, then the currency pointer does not need
number
Pick the
(num)
(d)
(r)
—>
(d)
(x)
Action
of DL/I requests
menu
r
number
(num)
(r)
preceding DL/I requests
of the
file
return to the previous
-
Pick the
or letter of the action desired
execute one
preceding DL/I requests
- redisplay the file of DL/I requests
- reset the currency pointer to the root
- return to the previous menu
-
of the
—>8
[RETRIEVE ((TEMP = Co) and (SNO =
(SNO) BY
A2))
SNO
RETRIEVE ((TEMP = Ops) and (SNO = A2) and (ODN =
[
to be reset
reset the currency pointer to the root
-
(x)
Action
redisplay the
-
(Get
or letter of the action desired
execute one
-
GNP
(ODN) BY
ODN
]
55))
]
INSERT (<TEMP,
<ANAME, Bd>)
[
<SNO, A2>, <ODN,
Acft>,
55>,
<ANO, 07>,
]
Insert
accomplished
Figure 7-8
Sequence
of selection
ABDL translation and
when
message. Note ABDL statedatabase in order to insert
the proper segment.
verification
ments follow the hierarchy
the data
If the
currency pointer
is
reset
rency pointer
first,
in
and the
Figure 7-9 will be displayed. If an
resetting currency pointer with
of the
GNP
ISRT
transaction
is
executed, the error message in
transaction is executed without resetting the cur-
the user will be displayed the error
78
message shown
in Figure 7-10.
These examples are derived from the
in the
SQD hierarchical
DEMO subdirectory of UserFiles.
interface
is
provided
A
quick reference for executing the hierarchical
Appendix B. This quick reference
in
demonstration hierarchical database
Action
Error
DM
schema and request files found
will step the user through the
SQD.
— > 12
in
GN
-
You have specified no previous
Operations.
or specify a
First return to
the root
comftete-p^/i transaction number
Figure 7-9
Error resulting
when
resetting the currency pointer
is
not
required
Action
— > 3 ^^
DL/1 transaction
Error
-
number
an ISRT must occur from the root
of the
Figure 7-10
Failure to reset currency pointer for a DL/1 ISRT
79
database
command
VIII.
CROSS MODEL ACCESS CAPABILITY RELATIONAL TO
HIERARCHICAL
-
OVERVIEW
A.
The
benefit of
throughout
to
MDBS
as a multi-model/multi-lingual
system has been shown
manual. Large corporations using several separate homogeneous database
this
form one large heterogeneous database can benefit from the single system design of
MDBS. With
several different data models
mapped
model/data language
to a kernel data
on the same system, the sharing of data between two different data models
amount saved through
as well as the vast
is
now possible
the consolidation of these several resources into
MDBS offers the capability for a relational user to access a hierarchical database using
one.
SQL
transactions.
This
transaction translation.
relational
is
possible through the use of
schema transformation and
Instead of copying the existing hierarchical database into a
database (and thus having to maintain two different databases), schema
transformation permits the schema of the hierarchical database to be transformed into a
relational
B.
schema
so that
SQL transactions may
be processed
SCHEMA TRANSFORMATION
Figure 8-1 illustrates the concept of schema transformation of the hierarchical schema
into a relational
can
now
schema. The hierarchical database
is
transparent to the relational user
access the hierarchical database using the relational interface.
transactions
map
directly into the
hierarchical data language.
ABDL
However,
who
SQL SELECT
language and require no translations into the
SQL INSERT, SELECT,
require a translation into the hierarchical data language
DL/1
and
DELETE
in order to
transactions
maintain the
parent/child relationships of the hierarchical database. Because the relational
cannot detect the parent/child relationships
of the
hierarchical
schema
schema, the
SQL
transactions cannot guarantee the parent/child relationship between segments will be
violated.
The
translated into
transaction translator realizes that certain
DL/1
SQL
transactions
must be
in order to maintain the integrity of the hierarchical database.
80
The
work of the
user
who
transaction translator and
schema transformer
is all
transparent to the relational
can access the hierarchical database as though the database was
still
strictly
relational.
Hierarchical Data Model
Model
and
Data Language
Relational Data
and
Data Language
Schema
I
I
Transformer
HLI
RLI
KDS
Kernal Data Model
and
Data Language
Figure 8-1
Schema Transformation Process
C.
EXECUTING THE HIERARCHICAL TO RELATIONAL CROSS
MODELING CAP ABILITY
Now
is
familiar with the concept behind the cross
ready to use
this capability.
The
first step
model capability of
the user
must take
is to
MDBS,
the user
load a hierarchical
database as described in the Hierarchical/DL/1 Interface section. Only the schema has
be loaded to the hierarchical database.
It is
to
not necessary to load the hierarchical database
with data using DL/1 transactions. Once the schema
81
is
loaded, the user should back out to
the Multi-Lingual/Multi-Backend Database
The user
relational/SQL interface
the
name
The
System Menu and
will then request
option (p)
in
select option (r) for the
Figure 8-2 and then enter
of the hierarchical database just loaded.
user will
now
be requested
Figure 8-3. Even though the user
database, the user
Transparency
is
is
to select the
of transaction input as shown in
accessing and processing records against a hierarchical
given the same prompts as
to the user is
mode
maintained
if
the database
was
strictly relational.
at all times.
Enter type of operation desired
(p)
-
(x)
-
Action
Enter
new database
process existing database
load
(I) -
return to the
MLDS/MBDS
system menu
—>p
name
database
of
— -> sqd
Figure 8-2
Processing an existing hierarchical database
using the relational interface
mode
Enter
read
in
(t) -
read
in
(m)
-
(f) -
mass
of input desired
a group
of queries
from a
queries from the terminal
load a
file
(d)
-
display the current database
(x)
-
return to the previous
Action
file
schema
menu
—>
Figure 8-3
Relational/SQL interface mode of transaction
input screen
As with
the other models, the user
may choose a prepared
input or type transactions from the terminal.
file
of
The mass load function
82
SQL transactions for
will not function with
the cross-model capability
covered
in the
and thus should not be chosen. The remaining steps mirror those
Relational/SQL Interface
One important note: when
interface, there
is
hierarchical/DL/1
no need
interface.
section.
is
executing transactions within the relational/SQL
to reset the
currency pointer as required when using the
the user
The schema transformation and
transaction
alleviates the relational user of having to maintain the currency pointer
SQL
transaction.
A
Currency pointer manipulation
is
translation
when executing
transparent to the relational user.
quick reference and an example of the execution of the cross-model access
capability
is
provided
(also created in
in
Appendix B. This appendix
Appendix B)
will use the hierarchical database
SQD
as the hierarchical database to be transformed into a relational
schema.
83
THE ATTRIBUTE-BASED DATA MODEL-LANGUAGE
IX.
INTERFACE
A.
OVERVIEW
The
attribute- base data
model
(ABDM)
system. Coupled with the attribute- based data language
language
(ABDL),
for the
this data
MDBS
model/data
the key to the multiple data model/data language to single data model/data
is
MDBS
language mapping that makes
kernel data
model
the kernel data
is
model based because
it
a federated database.
stores the
The
ABDM was chosen as the
meta data and base data separately, introduces
equivalence relations which partitions the base data into mutually exclusive sets called
clusters,
and allows these clusters
to
be distributed across the backends inducing parallel
access to the base data.
ABDL
was chosen
as the kernel data language because
complete language such that transactions written
or
CODASYL, can
be translated into
ABDL.
it is
in a traditional
It is
a semantically rich and
language like SQL, DL/1,
this translation capability that
makes
the
MDBS mapping process a multiple data model/data language (i.e. relational/SQL, network/
CODASYL,
hierarchical/DL/1) to a single data model/data language
ABDL
mapping.
also
ABDM/ABDL)
supports the five basic database operations of
RETRIEVE COMMON, INSERT, MODIFY,
B.
(i.e.
and
RETRIEVE,
DELETE.
DATABASE CONSTRUCTS
Data
in the
ABDM is stored as an attribute-value pair. This attribute-value pair
is
the
simple building blocks of the kernel database. The attribute-value pair consist of the
attribute
name and
its
corresponding value.
When displayed, an attribute-value pair will be
enclosed by a pair of angled brackets with the attribute
for that attribute.
An example would be <Vehicle,
and Car would be
A
its
first,
followed by the value
Car>, were Vehicle
is
the attribute
name
corresponding value.
set of attribute-value pairs constitutes a record.
value pairs
name
may have the same
attribute-value
name and
84
Within a record, no two
at least
attribute-
one of the attributes
in the
record
is
a key. These
that the record
parenthesis
two
rules ensure that each attribute-value pair
can be identified by one attribute which
with
attribute-value
pairs
within
is
these
A
a key.
is
single valued and
record
is
enclosed by
(<Vehicle,
parenthesis:
Car>,
Manufacturer, Ford>, <Model, Explorers <Year, 1992>, <VIN, 1234567890>, <Owner,
John Doe>).
A
a collection of records that share unique set of attributes. If a record belongs
file is
to a certain file, then the first attribute-value pair of the record will contain the attribute File
and the corresponding
first
attribute-value
file
name. All records belonging
For
pair.
example,
same
to the
file will
RegisteredCars>,
(<File,
have the same
<Vehicle,
Car>,
Manufacturer, Ford>, Model, Explorer>, <Year, 1992>, <VIN, 1234567890>, <Owner,
John Doe>), would indicate that the record belonged
to the file RegisteredCars.
and [HSIA 91] contain a detailed description of the
is
C.
encourage
ABDM and ABDL and the user
to read these prior to executing the attributed-based interface.
THE ATTRIBUTE-BASE DATA MODEL INTERFACE
The
user interface for the
interfaces discussed earlier.
ABDM differs slightly from the three traditional data model
The
ABDM interface does not require the use of a schema file
or request file but instead uses template and descriptor
models, the schema
file
(with or without indexing)
descriptor files necessary for
mapping
files.
was used
In the three traditional data
to generate the template
and
into the kernel data model/data language. In the
ABDM interface the user must create the template and descriptor file prior to execution. A
facility exists to generate a
therefore
it is
recommended
template and descriptor
1.
database but there are bugs in creating the descriptor
that the user use a text editor
(i.e.
emacs or
file
and
vi) to create the
files.
The Template and Descriptor
The template and
Files
descriptor files (the .d and
structure of the attribute-based database.
It is
.t
files) are
these files which
tell
used
to describe the
the kernel database
system what the template names are and the attributes within a template. Furthermore, the
85
and any constraints on these
attribute type
attributes will be noted in these files.
A template
can be thought of as a name of relation in a relational database.
The template file contains the name of the
database, followed by the
number
of templates within the database. After the number of templates, the next number
number of attributes
in the
attributes in that template
following template. The template
and
their respective type
attributes for a template are listed, the
number of
have been
database called
listed.
Figure 9- 1
is
is listed
the
followed by the
string, integer, etc.).
Once
all
attributes in the next template is listed,
followed by the next template's name. This process
attributes
(i.e.
name
is
is
all
the templates and
file for
the demonstration
repeated until
an example of a template
SALES.
SALES
3
3
Item
TEMPs
PARTNO s
PARTNAME
s
3
Customer
TEMPs
CUSTIDs
CUSTNAME
s
4
Order
TEMPs
CUSTIDs
PARTNO
PRICE
s
i
Figure 9-1
Template
'
upon the
The
descriptor
file
File
SALES.t
contains information with regards to constraints placed
attributes within the template. In order to achieve the
MDBS,
there are three descriptor types
attribute
which has a disjointed range of values
which an
(i.e.
86
attribute
scores
mutual exclusivity of the
may
>0 <=
take on. Type a
100).
Type b
is
is
an
an attribute
of distinct value
determined
at
(i.e.
color
=
Type c
black).
is
an attribute that has a dynamic range that
run time. In figure 9-2, attribute
values are the template names
whose value range
is
in the
from P0001
are also type a attributes
to
database.
TEMP
The
is
a type b attribute
attribute
P9999. The attributes
whose value range goes from
PARTNO
is
whose
is
distinct
a type a attribute
PARTNAME and CUSTNAME
the letter
A
to Z.
SALES
TEMPbs
Item
Customer
Order
@
PARTNO
a s
P0001 P9999
@
PARTNAME
as
AF
Gl
JP
QT
UZ
@
CUSTNAME as
AF
Gl
JP
QT
UZ
@
$
Figure 9-2
Descriptor File
2.
The Mass Load
SALES.d
File
Like the relational/SQL interface, the
mass load option
database
to load records to the database.
name with
a.r suffix.
The mass load
87
ABDL
The mass load
file
interface also supports the
file will
format used in the
be named after the
ABDM
interface is
exactly like the
mass load
file
mass load
file
format used
resembles a template
template name. The database
name
symbol. After each template, an
End of file
is
marked by
system looks for
TABS
file
in the
relational/SQL interface. In a sense, the
with data instead of attribute names underneath the
will appear at the top of the file followed
@
@ symbol must be used as a separator between templates.
a $ symbol.
between
An
important note
when
creating a
mass load
file,
the
attribute values in a record (or tuple). If the spacebar is
used between attributes, the system will not read the space as the
and will erroneously read the mass load
demonstration database
by an
file.
of a
new
Figure 9-3 illustrates the mass load
SALES.
SALES
@
Item
P8845
P3985
P9002
P1233
Widget
Bucket
Jack
P4501
Hammer
Rake
P4423 Ibeam
P7269 Vice
@
Customer
C101 Bradley
C1 02 Andrews
C103Kreed
C1 04 Ridley
C105Zaxxon
C1 06 Gibson
@
Order
C102P9002 29
C103P4501 19
C104P8845 14
C106P7269 79
C105 P4423 99
$
Figure 9-3
Mass Load
start
File
88
SALES.r
attribute
file for the
Once
the
MDBS
the user
these files have been created, the user
ABDM
system using the
must ensure
interface.
that the meta-disk has
As with
is
ready to begin execution of
the previous data
model
interfaces,
been cleared and that no extraneous
MDBS
processes are executing.
3.
Executing the
ABDM interface
After entering the run
account
like the
select option (a)
one
command from
the test directory of the cs4322
from The Multi-Lingual/Multi-Backend Database System menu
in Figure 4-7.
The next menu
to
appear will look like Figure 9-4. Selecting
option (g) will take the user through the steps needed to create template and descriptor
Due
to a
bug
in the option to create a descriptor file, this
required to create a template
file
through the
manual
files.
will only outline the steps
ABDL interface.
The attribute-based/ABDL
interface:
(g)
-
(I)
-
(r)
-
Generate a database
Load a database
Request interface
(x)
-
Exit to the previous
menu
Select->
Figure 9-4
ABDM interface menu
If the
a
list
user selects option (g), a
of options in regards to
file creation.
menu
will appear similar to Figure 9-5 with
Select option
(t) -
Generate record template.
The user will then be prompted for the name of the template file. Remember to use the same
name
of the database and add the suffix. t. The user will then be prompted to enter the
database ID; which
is
simply the database name. The
filenames similar to the manner in which
ABDL interface
is
case sensitive to
UNIX is case sensitive. The user will then
be lead
through a series of questions in regards to the number of templates in the database and the
89
A
B
number of
will
have
attributes within
to
each template. Figure 9-5 shows the sequence of steps the user
go through using an example template
Enter the template
called
TEST.t
name: TEST.t
file
ENTER DATABASE
file
ID:
TEST
ENTER THE NUMBER OF TEMPLATES FOR DATABASE TEST:
2
ENTER THE NUMBER OF ATTRIBUTES FOR TEMPLATE
ENTER THE NAME OF TEMPLATE
ENTER ATTRIBUTE
#1
ENTER VALUE TYPE
(s
#1
:
string,
i
=
(s
=
string,
i
Templatel ATT1
:
Templatel
:
ATT2A
= integer): s
ENTER THE NUMBER OF ATTRIBUTES FOR TEMPLATE
ENTER THE NAME OF TEMPLATE
ENTER ATTRIBUTE
#1
ENTER VALUE TYPE
(s
string,
i
=
(s
=
string,
i
=
(s
=
string,
i
=
Template2:
ATT2B
integer): s
ENTER ATTRIBUTE #3 FOR TEMPLATE
ENTER VALUE TYPE
Template2: ATT1
integer): s
ENTER ATTRIBUTE #2 FOR TEMPLATE
ENTER VALUE TYPE
Template2:
integer):
ATT3B
i
Figure 9-5
Sequence
of steps in creating template file
90
#2: 3
#2: Template2
FOR TEMPLATE
=
2
integer): s
ENTER ATTRIBUTE #2 FOR TEMPLATE
ENTER VALUE TYPE
:
Templatel
FOR TEMPLATE
=
#1
Once
to the
the template file
is
completed exit the menu
in
Figure 9-4 and return
attribute-based/ABDL interface menu. Figure 9-3. The user should have already
created a descriptor
file
with the same
name
as the template file with a ".d" vice ".t" suffix,
refer to Section 2 of this chapter if this has not
The user
now
is
ready to load the database to the
from Figure 9-3 and then choose option
requesting the
sensitivity)
name of
and press
the meta-disk of the
illustrates this
been done.
sequence of
name
and the user
A
will
now
is
prompt
(1)
appear
of the database (don't forget case
The database template and
MDBS
Select option
from the next menu.
(u)
the database. Enter the
return.
MDBS.
descriptor files are
now
loaded to
ready to mass load data. Figure 9-6
steps.
The attribute-based/ABDL
interface:
(g)
-
(I)
-
(r)
-
Generate a database
Load a database
Request interface
(x)
-
Exit to the
previous
menu
Select->
Select an operation:
(u)
-
(r)
-
Use a database
Mass load a file
(x)
-
Exit, return to
of records
previous
menu
Select-> u
Enter the
name
of the
database:
SALES
Figure 9-6
menu
Sequence steps
to
The next menu
appear
in Figure 9-6. Select
requesting the
name of
to
option
the
(r)
use an attribute-based database
-
mass load
is
a select operation
Mass load a
file.
file
of records.
The mass load
91
menu
file
similar to the second
A
prompt
will appear
must reside within the
r
UserFiles subdirectory of the cs4322 class account. Since the mass load
to the database,
normal.
If
the
it
may
require a
mass load
file
little
was
more time
to execute.
A delay
file is
loading data
of up to 20 seconds
successful, the user will return to the previous
select option (x) to return to the attribute-based/ABDL interface
is
menu and
menu. Figure 9-7 shows
the screen display for the sequence of steps outlined above.
Select an operation:
Select->
(u)
-
(r)
-
(x)
-
Use a database
Mass load a file
Exit, return to
of records
previous
menu
r
Enter the record
name: SALES.
file
Select an operation:
(u)
-
(r)
-
Use a database
Mass load a file
(x)
-
Exit, return to
of records
previous
menu
Select-> x
The attribute-based/ABDL
interface:
(g)
-
(I)
-
(r)
-
Generate a database
Load a database
Request interface
(x)
-
Exit to the previous
menu
Select->
Figure 9-7
Steps
At
interface.
in
processing the mass load
the attribute-based/ABDL interface
The next menu
to
menu,
appear will be the subsession
92
file
select option (r)
menu
-
Request
that appears in Figure 9-
8.
The beginning
user should only be concerned with option
subsession menu. Option (p)
is
(s),
and (d) of the
(n),
used primarily for setting the internal and external clock to
gauge system performance when increasing/decreasing the number of backends. Option
(r)
ABDL
allows the user to choose where the output from the
routed.
The choice of routes
(o) are self-explanatory with
are printer,
option (m) being a
or removing traffic units from a
transactions.
A
list
other three data
of traffic units
model
CRT (or monitor),
file.
is
interfaces and
is
Options (m) and
both, or none.
menu driven
Note: traffic units
normally stored
transactions should be
process of adding, modifying,
is
the
name given
in a file similar to a
sometimes referred
for
request
ABDL
file in
the
to as a traffic unit file.
Select a subsession:
SELECT: select traffic units from an existing
(or give new traffic units) for execution
NEW LIST: create a new list of traffic units
NEW DATABASE: choose a new database
(s)
(n)
(d)
list
PERFORMANCE TESTING
(p)
*
(r)
*
(m)
*
REDIRECT OUTPUT: select output for answers
MODIFY: modify an existing list of traffic units
(o)
*
OLD
LIST: execute
existing
all
EXIT: return to previous
(x)
the
traffic units in
an
list
menu
Refer to the MLDS/MBDS user manual before choosing
subsessions marked with an asterisk (*)
Select->
Figure 9-8
Subsession menu
Option
(n) allows the user to create a
process against an existing database. This
switch to a
the user
new database
is
also
new
menu
(or file) of traffic units to
driven.
(provided template and descriptor
may execute traffic
list
Option
files exist).
(n) lets the user
Option
(s) is
were
units against the attribute-based database. Select option (s)
93
and
a
prompt
name of the
will appear requesting the
must contain
traffic unit file
example, the database
second version
a '#'
SALES
entered, the screen will display a
will appear, see Figure 9-9,
symbol before the
has a
traffic unit file is
traffic unit file to
first
numbered
file
called
SALES#1,
so forth. After the traffic unit
of the traffic units to be processed.
list
prompting the user
version number. For
traffic unit file
version traffic unit
SALES#2, and
be processed. Note: the
to
execute a
traffic unit, create a
the
file is
A menu
new
traffic
subsession menu.
unit, redisplay traffic units, or return to
Select Options:
(d)
redisplay the
(n)
enter a
traffic units in
new traffic
unit to
the
list
be executed
(num) execute the traffic unit at [num]
from the above list
(x)
exit from this SELECT subsession
Option ->
Figure 9-9
Traffic unit
At
to
the Option-> prompt, enter the
be processed. After
build a
new
database.
processing
all traffic
units
number corresponding
have been processed the user
attribute- based database, or process a
Appendix B provides a step-by-step
attribute-based database
menu
SALES.
94
new
to the traffic unit
may
exit the
MDBS,
traffic unit file against the original
outline of executing the demonstration
UM APPENDIX A: USEFUL UNIX AND MDBS COMMANDS
THE .ALIAS FILE (ABRIDGE)
A.
TABLE
1
:
Common System Commands Used
ALIAS
UNIX
COMMAND
MDBS
Prior to
Execution
EXPLANATION
P
ps X
shows
test
cd -/test
change
X
exit
logs user out of db3.
user
cd -/UserFiles
change
directory to UserFiles.
data
cd -/UserFiles
change
directory to UserFiles.
disk
cd -/RunData/Disks
change
directory to Disks.
is
od -c/dev/sd1c
pry
all
running processes.
directory to test.
stored here.
octal display of the meta-disk.
indicate meta-disk
-/test/stop, cmd
burn
These
aliases are the
cs4322 default directory, a
stop
all
current
most commonly used on the
list
Base data
is
clean.
MDBS
MDBS.
Zeroes
processes.
In the file .alias in the
of more aliases can be found. These aliases deal primarily
with accessing the directories which contain the code for the user interface as well as the
backend software.
C SHELLS
B.
MDBS
uses three
remembering several
when
the
C
C
shells
to
ready the system for execution. The burden of
UNIX commands in a specific
shells are used.
These
C
shells are
order
found
is
no longer placed upon the user
in the test directory of the
account and are zero*, stop.cmd, and run*. Figures A-l through A-3
used by the
MDBS
software and a brief explanation of each
provided.
95
C
list
the three
cs4322
C
shells
shell function is also
1.
The zero C
Shell
The zero C
executing the zero
the
remove
file
shell
command,
command
UNIX awk commands
the user
specify the
be echoed with
file it
"No Match". This
was supposed
to
file).
The
number of bytes
files
rm
rm
rm
rm
rm
rm
a result of
MDBS
resulted in
were never removed from the system. The "cp /dev/
copy
line will
last line
,
null bytes into the file
were the base data
is
u /usr/work/cs4322/.z /dev/sdlc 8000000", will
that will be copied over. In Figure A-l,
be nulled.
#file:
is
After
remove. Most of these
are issued in case the previous execution of the
~/RunData/Disks/diskO"
stored (the diskO
may
not finding the
abnormal termination and these
null
will clean the meta-disk of all previous data.
/usr/work/cs4322/test/zero
-f
~/test/.*cat
-f
~/test/.sql.dbl
-f
~/test/.hie.dbl
-f
~/UserFiles/.R*
-f
~/UserFiles/*.iig.at
-f
~/UserFiles/*.cinbt
cp/dev/null -/RunData/Disks/diskO
/usr/work/cs4322/.z /dev/sd1 c
Figure A-1
The zero* C shell
96
8000000
8000000 bytes
are to
2.
The stop.cmd C
Shell
The stop.cmd C
Figure A-2,
shell.
any
kills
MDBS
process running on the
system. The process numbers killed will be listed across the screen.
contains the parameters by which the
UNIX awk command
are found, they are copied to a file list2.stop.
numbers of the jobs
as
any data existing
#
to
will search. If
G_CPCLC and G_G_BPCLB
echo 'Stopping
|
awk
-f
MBDS
processes'
.test.awk >! list2.stop
set noclob
set a='cat list2.stop'
echo
killing
kill
#
rm
rm
rm
$a
$a
list2.stop
-f
-f
##rm
/usr/work/cs4322/RunData/G_BPCLB
/usr/work/cs4322/RunData/G_CPCLC
-f
\tr core .b*
Figure A-2
The stop.cmd C
97
.test.awk
any parameters
shell
file is
sockets of the
/usr/work/cs4322/test/stop.cmd
file:
file
list2.stop file contains the process
be killed. After the jobs are killed, the list2.stop
in the
ps -x
The
The
erased as well
RunData
directory.
The run C
3.
Shell
The run C
executable
files that
shell,
Figure A-3, starts the
MDBS
file:
The commented
-f
-f
/usr/work/cs4322/test/run
/usr/work/cs4322/RunData/G_BPCLB
/usr/work/cs4322/RunData/G_CPCLC
/usr/work/cs4322/VerE.6/CNTRL/scntgpcl.out >&! /dev/null
/usr/work/cs4322/VerE.6/BE/sbegpcl.out >&! /dev/null
&
&
/usr/work/cs4322/VerE.6/CNTRL/scntppcl.out >&! /dev/null
&
/usr/work/cs4322/VerE.6/CNTRLVpp.out >&! /dev/null &
#/usr/work/cs4322/VerE.6/CNTRUpp.out >&! /usr/work/cs4322/test/pp.tr &
/usr/work/cs4322/VerE.6/CNTRL/iig.out >&! /dev/null &
/usr/work/cs4322/VerE.6/CNTRLVreqprep.out >&! /dev/null &
#/usr/work/cs4322/VerE.6/CNTRL/reqprep.out >&! /usr/work/cs4322/test/reqp.tr &
#
/usr/work/cs4322/VerE.6/BE/dirman.out >&! /dev/null
&
#/usr/work/cs4322/VerE.6/BE/dirman.out >&! /usr/work/cs4322/test/dm.tr &
/usr/work/cs4322/VerE.6/BE/cc.out >&! /dev/null
&
/usr/work/cs4322/VerE.6/BE/recproc.out >&! /dev/null
&
#/usr/work/cs4322/VerE.6/BE/recproc.out >&! /usr/work/cs4322/test/recp.tr
/usr/work/cs4322/VerE.6/BE/dio.out >&! /dev/null
# must
the
lines (those pre-
#
rm
rm
all
drive the backends and controller. Tracer files can be used to track
places were the system failed during a particular session.
#
system by calling
NOT start
until
cntgpcl
is
&
listening
(sleep 10 ;\
/usr/work/cs4322/VerE.6/BE/sbeppcl.out >&! /dev/null
/usr/work/cs4322/VerE.6/CNTRL/dblti.out1
#chmod g+w *.tr
#rm *.trcore .b*
Figure A-3
The run C shell
98
)
&
&
ceded by a #)
that are used in calling an executable
user desires to use tracer
files,
then the executable
tile,
are setup to use tracer
files set
up with a tracer
tiles.
file (i.e.
If
the
#/usr/
work/cs4322/VerE.6/CNTRL/pp.out >&! /usr/work/cs4322/test/pp.tr &) must comment
out the matching line containing the same executable
mation
to null (i.e.
file
name which sends
tracer infor-
/usr/work/cs4322/VerE.6/CNTRL/pp.out >&! /dev/null &).
99
README FILE
C.
The
in
README file can be found in the test directory of the cs4322 account.
Figure A-4, the
README file contains a list of system constraints place upon file size,
attribute length case sensitivity, etc.
file
As shown
when developing
a
new
The user should always have
a
copy of the
README
database in order to have a quick reference to the system
constraints.
LIMITS
max
OF YOUR SINGLE USER SYSTEM
length of unix
file
name
for the
template & descriptor
10 chars.
max
retrieves per transaction
5
is
max chars
for attribute
name
is
10
max
for attribute
value
is
30
chars
max #
of attributes
max #
of descriptors
max #
of clusters
max #
of records per cluster
max #
of templates per
max # of traffic
you can have per template
you can have
you can have
db
is
1
150 per
50
attribute
00
200
is 1
query
units per
is
is
is
file is
25
the largest integer value you can use to join on a retrieve
common
is
2147483647.
Figure A-4
The
README file
100
file is
UM APPENDIX B: EXECUTION OF DEMONSTRATION
DATABASES
A.
OVERVIEW
The purpose of
this
executing the
demo
stored in the
DEMO
appendix
the
provide the user with step-by-step reference to
will aid the user in
is
MDBS
developing new databases on the
MDBS
interface.
processes running (use the
clear (using the
that are
MDBS system and giving the user a hands-on opportunity
must ensure
Prior to executing the interfaces, the user
MDBS
and cross model databases
directory of the UserFiles directory in the cs4322 class account.
by familiarizing the user with the
work with
to
hierarchical, relational, network,
These step-by-step instructions
to
is
UNIX
ps ax
command
that there are
to verify)
no extraneous
and that the meta-disk
pry command). Note: the meta-disk must have data from the hierarchical
database in order to execute the cross-model accessing capability.
B.
THE RELATIONAL/SQL INTERFACE
Type run from
From
the
the mdb3/usr/work/cs4322/test directory.
MDBS menu select option
Select option
load
(I) -
name
Select option
read
desirec
-
-
Execute the relational/SQL interface.
new database from
Enter the database
(f)
(r)
EMPREC
in a
the type of operation
menu.
(caps not required).
group of creates from a
file
from
the
mode
of input
menu.
What is the name of the CREATE/QUERY hie prompt, enter the schema file
name DEMO/EMPRECsqldb.
At the
If
prompted
to use the existing descriptor file,
EMPREC.d,
enter n for no.
After the relations of the database are displayed, enter n for no indexing.
Select option (p)
-
Enter the database
For
mode
Enter
process existing database for the
name
EMPREC
at the
of operation.
(caps not required).
of input desired, enter option (m)
DEMO/EMPREC.r
mode
name
-
mass load a
file.
of record file— > prompt
After the records from the mass load have been displayed, select option
a group of queries from a
file at
the
mode
101
of input menu.
(f) -
read in
•
What is the name of the CREATE/QUERY file prompt, enter the request file
At the
name DEMO/EMPRECreq.
•
The
SQL
transactions in the request
numbered. Hit the return key
hand corner
•
EMPRECreq
prompt
the -more-
in order to finish scrolling
1, let
SQL
will be displayed
and
displayed in the bottom right
is
SQL
through the
At the action prompt enter the number of the
Enter
transactions.
transaction
you wish
to process.
the transaction process and observe the results, then execute transaction 2
and so forth
•
if
file
until all the transactions in the request file
Once completed,
number or
enter option (x)
-
return to the previous
letter of the action desired
•
Keep
•
Type zero from
selecting option (x) until
have been processed.
menu
at the
Pick the
menu.
MDBS
you have exited the
system.
the mdb3/usr/work/cs4322/test to clean the meta-disk in order to
execute the next interface.
C.
THE NETWORK/CODASYL INTERFACE
Type run from
From
the
the mdb3/usr/work/cs4322/test directory.
MDBS
menu
select option (n)
-
Execute the
network/CODASYL
interface.
Select option
load
(1) -
new database from
Enter the database
name NET1
Select option
read
desirec
(f) -
in
the type of operation
(caps not required).
a group of creates from a
file
from
the
mode
of input
menu.
What is the name of the DBD/REQUEST
name DEMO/NETldmldb.
At the
If
menu.
prompted
use the existing descriptor
to
file,
file
prompt, enter the schema
NETl.d,
file
enter n for no.
After the records of the database are displayed, enter n for no indexing.
Select option (p)
-
Enter the database
Select option
(f) -
process existing database for the
name NET1
What is the name
name DEMO/NETlreq
The
of the
of operation.
file at
the
(caps not required).
read in a group of queries from a
At the
mode
DBD/REQUEST
file
mode
of input menu.
prompt, enter the request
file
CODASYL transactions in the request file NETlreq will be displayed and
numbered. Hit the return key
if
the -more-
prompt
is
displayed in the bottom right
CODASYL transactions.
At the action prompt enter the number of the CODASYL transaction you wish to
hand corner
in order to finish scrolling
process. Enter
transaction 2
1
,
let the
and so
through the
transaction process and observe the results, then execute
forth until all the transactions in the request file
processed.
102
have been
•
Once completed, enter option (x) - return to the previous menu
number or letter of the action desired menu.
•
Keep
•
Type zero from
selecting option (x) until
you have exited the
MDBS
at the
Pick the
system.
the mdb3/usr/work/cs4322/test to clean the meta-disk in order to
execute the next interface.
THE HIERARCHICAL/DL/1 INTERFACE
D.
Type run from
From
the
the mdb3/usr/work/cs4322/test directory.
MDBS menu select option (h)
Select option
load
(I) -
name
Select option
read
desirec
At the
-
Execute the hierarchical/DL/I interface.
new database from
Enter the database
(f)
-
SQD
in
the type of operation
menu.
(caps not required).
a group of creates from a
file
from the mode of input
menu.
What
is
name
the
of the
DBD/REQUEST
file
prompt, enter the schema
file
name DEMO/SQDdlidb.
If
prompted
to use the existing descriptor file,
SQD.d,
enter n for no.
After the segments of the database are displayed, enter n for no indexing.
Select option (p)
Enter the database
Select option
At the
What
(f) -
is
process existing database for the
-
name
SQD
name
of operation.
file at
the
(caps not required).
read in a group of queries from a
the
mode
of the
DBD/REQUEST
file
mode
of input menu.
prompt, enter the request
file
name DEMO/SQDreq
The DL/1
transactions in the request
Hit the return key
if
the
SQDreq
file
-more- prompt
is
will be displayed and
numbered.
displayed in the bottom right hand corner in
order to finish scrolling through the DL/1 transactions.
In order to execute the first ten
option(r)
Since the
-
DL/1 transactions,
the user
must
first select
reset the currency pointer to the root, then the transaction number.
irst
transactions that are being loaded to the hierarchical database
a hierarchical order
(i.e.
data loaded to the root segment
first,
must be
in
then children segments,
etc.), the root pointer must be reset after each transaction to ensure a complete path
from the root
•
to the children segments.
Reset the currency pointer prior to transaction 11 but do not reset the currency pointer
for transaction 12. This is because the currency pointer is already at the
from which the
•
seqment
GET operation is being executed.
Reset the currency pointer prior
to
transaction 13 and then execute transaction 14
since the currency pointer does not need to be reset prior to the execution of
transaction 14.
•
The currency
pointer must be reset prior to executing both transactions 15
103
and
16.
menu
•
Once completed,
•
number
•
Keep selecting option (x) till you reach The Multi-Lingual/Multi-Backend
Database System menu. Do not exit the MDBS system if you wish to use the cross
model capability of the MDBS. Go to Section E for the steps need to execute the
cross model interface.
enter option (x)
-
return to the previous
or letter of the action desired
at the
Pick the
menu.
THE CROSS MODEL CAPABILITY
E.
•
MDBS system, the user should have the hierarchical database
MDBS and be at The Multi-Lingual/Multi-Backend Database
Without exiting the
SQD
loaded to
System menu.
•
From
MDBS
the
menu
select option (r)
-
Execute the relational/SQL interface.
•
Select option (p)
•
Enter the database
name
•
Select option
read in a group of queries from a
•
•
-
-
(f)
process existing database for the
SQD
of operation.
file at
the
(caps not required).
mode
of input menu.
What is the name of the CREATE/QUERY file prompt, enter the request file
name DEMO/SQDRTHreq. This file contains SQL transactions to be processed
against a hierarchical database already loaded to MDBS.
At the
The
SQL transactions
in the
request
numbered. Hit the return key
hand corner
•
mode
if
the
file
SQDRTHreq will
-more- prompt
in order to finish scrolling
through the
is
be displayed and
displayed in the bottom right
SQL
transactions.
At the action prompt enter the number of the SQL transaction you wish to process.
Enter 1, let the transaction process and observe the results, then execute transaction 2
and so forth until all the transactions in the request file have been processed. Notice
that there is no longer a need for a currency pointer as in the hierarchical database
interface.
•
Once completed, enter option (x) - return to the previous menu
number or letter of the action desired menu.
•
Keep
•
Type zero from
selecting option (x) until
you have exited the
MDBS
at the
Pick the
system.
the mdb3/usr/work/cs4322/test directory to clean the meta-disk in
order to execute the next interface.
THE ATTRIBUTE-BASED/ ABDL INTERFACE
F.
•
From
the
MDBS
menu
select option (a)
Execute the attribute-based/ABDL
-
interface.
•
Select option
•
Select option (u)
•
Enter
Load a database from
(I) -
SALES
-
the attribute-based/ABDL interface menu..
Use a database.
as the
name
of the database
104
name
of the database to be processed.
Remember that the ABDL
interface
is
case sensitive. Also, there must be template and
descriptor files already created for the database to be processes. If not, exit and create
a
new
template
be created using a
Generate a database. The descriptor
emacs or vi.
using option (g)
file
test editor like
-
After entering the database name, select option (m)
Enter
SALES. r
as the
mass load
file to
-
Mass load a
tile
file
must
of records.
be processed.
Select option (x) to return to the attribute-based/ABDL interface menu.
Select option (r)
From
Request interface.
-
the subsession
existing
list
(or give
Enter the filename
menu,
new
SELECT:
select option (s)
SALES#1
as the traffic unit file to be processed.
unit file will be displayed.
From
processed. There are only
1 1
at all
all traffic
menu
units
by using the
the
menu,
Be sure
zero command.
to clean the
105
list
select the
traffic units to
of all traffic units in the traffic
number of
the traffic unit to be
be executed.
have processed, exit the
that appear.
from an
traffic units) for execution.
After entering the traffic unit filename, a numbered
After
select traffic units
MDBS
system by selecting option
(x)
meta-data disk after exitting the system
)
APPENDIX
)
B.
)
))
)
)
) )
MODEL-LANGUAGE INTERFACE GENERIC FUNCTION
MAPPING
Language Interface Layer
tl.C
I
newuser.c
new_model_language_user(
nmlmain.c
nml_main(
"
lil.c
To nml_kemel_controller()
nml_language_interfacejayer(
n_load_new(
n_process_old(
lilcommon.c
nmldbd_to_KMS( )
readrtnes.c
nmlfree_requests(
n_read_transactiion_file(
nmlreq_to_KMS(
n_read_file( )
list_nmlreqs(
n_read_terminal(
morenmlreqs(fname)
n_read_file( )
find_nmlreq(num)
To nml_kernel_mapping_system{)
new user by
granting user
1.
Establish
2.
Call to
3.
Whether processing an
4.
Call
is
to allow
made
user access to
existing or
to either load
a
id (for
kmsgenerals.c
use with a mult-user system).
new model-language
interface.
new database, determine mode
new database
to
of input (terminal or file)
MDBS or process an existing database
KMS to parse the schema
KMS to parse a request transaction selected by the user.
Call to KC to execute a transaction or load a schema parsed by KMS onto MDBS.
5.
Call to
6.
Call to
7.
LIL
in
file.
106
in
nml_kc.c
)
)
)
Kernel Mapping System
Loading a Schema
File
From nmldbd_to_KMS
( j in
lilcommon.c
From nml_load_new(
) in lil.C
1.
~l imsgeneral.s.c
_^~—
2-
nml.c
—
nml_parser()
nml_yyparser()
free_duplicatesjist()
7T
error(t)
nml.v
YACC_CODE
3.
yy_error()
nml.l
LEX_CODE
buildnmldesc.c
buildndl.c
nml_build_desc_file()
n_build_ddl_files()
6.
print_record()
build_nml_template_files()
nml_traverse()
1.
Function
call
from LIL
to
KMS to
load the
schema
file.
2.
KMS
3.
Call
-
calls the parsing function.
LEX and YACC code
Loading a Request
to validate input
4.
Control returned to kmsgenerals.c
5.
Build the template
6.
Build the descriptor
file.
file.
stream
File
From find_nmlreq_to_KMS
( ) in
lilcommon.c
1
I
D.C
lilTKd
kmsgenerals.c
dml_kernel_mapping_system(
nml_parser()
free_duplicates_list(
nml_yy parse ()
error(t)
nml_schema_cleanup(
nml_yy_error()
nml_kmsjnfo_cleanup()
4.
nml_reset_ variables?)
To
LEX and YACC code
in
nml.y and nml.l
Return control to
1.
Function
call
from LIL to
KMS
to load the
request
2.
KMS call the
3.
Call
4.
Transaction execution complete, return to LIL.
file.
parsing function.
LEX and YACC code
to validate
107
request transaction.
LIL
c
Kernel Controller
From
lil.c
1
mill
RC.C
nml load
la.
tl.C
dbl_template()
nml requestliandler.c
6b.\
\
2.
lb>
N.
6a.
tables.
nml_ load_ tables ()
nml_kemel_controller()
nml
3.
\
f
exec.c
nml_execute()
nml_request_handler()
4.
1 r
tisr.c
Return to
LIL
Reformat results
in
K.FS
TI_S$TrafUnit(dbid, trafunit)
TI_Finish()
new schema,
template
la.
If
loading a
lb.
If
loading a request, call appropriate request handler based on transaction
calls the function to load
file.
type.
2.
Call the Test Interface to load the template
3.
Execute the transaction on
4.
Call the Test Interface to
5a.
Schema
is
loaded to
file.
MDBS.
send transaction
MDBS,
to
KDS.
control returned to
LIL.
5b. Transaction completes execution and must be reformatted by the
KFS
Kernel Formatting System
From nml
kc.c
1.
X
nmlkts.c
-
nml_kfs()
Return control to
LIL
with reformatted
result for display to the user.
1.
Receive control from
KC;
reformat
ABDL
108
result into
UDM format
.
APPENDIX C.
MM&MLDS GENERIC MODEL-LANGUAGE DATA
STRUCTURE
CCO.
o
l.
JJ
O
.
—
OOO
eo
—
CD c£2
i
0-
C_T3
en
5
,
CO
—
*l
b
*
oo o
0>
c
c
c
"O
T3
*
cd
1)
*
U.
H
u
D.
C.
c_
cd
cU
[•<
.E
CQ
B
i>
>-
c/>
C
<u
31
cr
CU
u.
<u
E
B
oo
"O
*
§
O)
oo
*
o
c
*
§
*
§
*
cr
w
C
cr
cr
cU
c
1
H
i
•o
cU
JS
u-
I
e
§
*
*—
s
c
•c
©
c
*
1
•o
J2
•o
I
a"
cr
J J J
,1
S
c
—
.-
coo
G o °
i1
e
_3
=
«
0-7
cdcj-cj
CL,
«
x:
t-
C
D.
cU
BO
00
q
*
4D
E
C
#
CU
i—
1
JS
•a
a
*
u-
*
1
1
er
T3
O
C
o
c
1
T3
"3
•a
c
b
o T3
-C -C
o a
__l
D
La
JS
aj
e
o
o
B
cu
1_
«
ex
TT
JS
•a
a>
CU
CD
"g
"8
"8
"g
E
a
B
c
j
—
J
rt
eB
.1
3
B
U
C3
u.
.E
c
c
b
£ —
Q
E
cr
1
cr
cr
cr
OJ
u.
In
1
cr
cU
1
_l
cd
TD
cr
CD
cu
In
1
0)
E
"3
«
i>
&
E
cd
B
X
&
•a
•a
,©
«—
i
i
•o
c
o
cr
cr
H
cU
25
CjC
"°i
-a
o
o
c
t'
y=
a
o
•a
a
—o
(4-1
u.
i
i-i
o «
cr
<0
u.
rt
«J
ao do
•o
o
b
o
E
<^>
A
o
1
1
c
u
1
cfl
i-
3
0)
O
E
Tl
o
E
1
T3
X!
"O
%
o
JS
•fc-
T3
a>
(J
ci
a>
TD
O
E
3
o
—
^
OiJ
cd
E
J
_E
o
E
cr
cr
CU
1—
cU
G
,
,
E
f
ai
cr
CA
3
•a
^^
&
i
T3 T3
<™H
^^
c2
S.2
s c
o.S
a>
CU
60
00
a
SC3
v
'
so
CS
O 3
O O0
0JD
C3
3
C
3-'
1-s
Oo
T3
O
.2
—
E
.5
=3
T3
E
1
c
z
109
to
.
u E
'3
d<2
j
CU
00
0)
2
C
00
b<0 u
3 S
2 c o
= O
T3
CO
2_
«
ut2
C-O
«J
o2«
E-o
u
c
1c
—V3 —
•Si
|
J=
C
^
O
O
|
CD
^
^
MO
M
*
*
*
*
<*-
3 3
s
*
*
O
4*!
J
<D
J*
#
O
M
c
C/3
•—
(/J
o
c
E,
a,
u
*
O
c
«*
fi
2
c-o
o 2 3
E-o
a
CO
•V.TJ to
ol
a-
t-i
C_
n 3 CU
h
C/l
— ?
BH °
'5
O V
W 00
a)
0)
« 3 £
~ °°S
«B
1
1
."^
<*-
E
^
o
c
E
O
C
o
C
<4-
c
1
1
1
c
a
CD
.^ ,w
3 a — 2
^O
c/]
c/3
/
\
O.
S
CD
"D
T3
ya
i
d
e
1
#
ya
O
c
«*-
c
0
a
1
<L>
CB
I
3
60
*'
0)
c
E
2
1
4)
00
00
eo
ca
00
00
3
S
O
E
1
1
4>
8P
1
,0
tS
.2
C/2
•O
^
S
•O •O
1
ya
1
3
4>
(U
"O
T3
o
E
*
a>
c
E
o
Eh
tu
«9
1
§
S3
ya
O
E
i<2
1
1
—
•s
V
c
E
o
s
tu
2
E
E
£
.s
0!
E
00
CO
3
C
1
* 00
c
CO
|(M
s
is?
1
=
£
Cos
A, e.2
I fj
1
110
j
O
C
<4-l
c
U
£ Sc
1
I
<y
i
T3
c
1
c
o3
-C
—O —O
£5
(4-1
1
s
J4
ya
O
-^
^j
1
|
S
CD
MO
APPENDIX
D.
GENERIC MAKEFILES FOR NEW MODEL
LANGUAGE INTERFACES
######################################################################################
#
Title Generic Makefile for a new model-language interface.
#
#
:
hie: Makefile
#
# path: db3 /usr/work/mdbs/NewVersion/CNTRL/TI/LangIF/src/NML/Makefile
#
###############################^fli####################################################
LIB= $(HOME)/lib/nml.a
HOME=/usr/work/mdbs/NewVersion/CNTRLAn/LangIF
LPR=
lpr
LPRFLAGS= -p
AR=ar
ARFLAGS= cr
Replace NewVersion with the most current version
RANLIB=ranlib
of MDBS software will be stored.
name of MDBS
S(LIB): objects
rm -f $(LIB)
$(AR) S(ARFLAGS)
S(RANLIB) $@
$@
*/*.o
quick:
rm-f$(LIB)
$(AR) S(ARFLAGS) $(LIB)
*/*.o
$(RANLIB) $(LIB)
objects:
cd Alloc; make
cd Kc; make
cd Kfs; make
cd Kms; make
cd
Lil;
make
clean:
cd Alloc; make clean
cd Kc; make clean
cd Kfs; make clean
cd Kms; make clean
cd
Lil;
make clean
print:
cd Alloc; make
print
cd Kc; make print
cd Kfs; make print
cd Kms; make print
cd
Lil;
make
print
111
software. This
is
where the new version
######################### #############M####M########################################
# Tide
:
#
makefile
tile:
Generic Makefile for compiling
all
model-language interfaces.
#
#
# path: db3 /usr/work/mdbs/NewVersion/CNTRL/TI/LanglF/makefile
#
######################################################################################
SRC = /usr/work/mdbs/NewVersion/CNTRL/TI/LangIF/src/
quick:
#
cd $(SRC)Com; make
make
#
cd $(SRC)Dli;
#
cd $(SRC)Dml; make
#
make
cd $(SRC)Dap; make
cd $(SRC)Obj; make
cd $(SRC)NML; make
#
#
To compile specific mode I- language interfaces, remove
the
cd $(SRC)Sql;
#
from
of the model-language to be compiled. To
model-language interfaces, remove the #
in front
compile
all
all the
commands under quick:
.
clean:
#
cd $(SRC)Com; make clean
#
cd $(SRC)Dli: make clean
#
cd $(SRC)Dml: make clean
#
cd $(SRC)Sql;
#
cd $(SRC)Dap; make clean
#
cd $(SRC)Obj;
#
cd
make
clean
make clean
$(SRC)NML; make clean;
To delete all object files after compilation, remove the #
in
print:
front of the
clean:..
model-language desired under the
To print out the source code for a model-lan-
#
cd $(SRC)Com; make print
guage, remove the
#
cd $(SRC)Dli; make print
print:
#
cd $(SRC)Dml: make print
#
cd $(SRC)Sql; make print
#
cd $(SRC)Dap; make print
#
cd $(SRC)Obj; make print
#
cd
$(SRC)NML; make
print
112
.
it
in front
of the commands below
REFERENCES
[BENS
85]
Benson,
T.
P.,
and Wentz, G.
The Design and Implementation of a
L.,
Hierarchical Interface for the Multilingual Database System,
Master's
Thesis, Naval Postgraduate School, Monterey, California, June 1985.
[BROD89]
Brodie,
J.,
and Plauger,
Series, Microsoft Press,
|DEMU87]
Standard C: Programmer's Quick Reference
P.J.,
1989.
The Multi-Lingual Database System - A Paradigm and
Test-Bed for the Investigation of Data-Model Transformations, Datalanguage Translations and Data-Model Semantics, Ph.D. Dissertation, The
Ohio State University, 1987.
Demurjian,
S. J.,
The Implementation of a Network CODASYL - DML Interface for
the Multilingual Database System, Master's Thesis, Naval Postgraduate
School, Monterey, California, December 1985.
EMDI
85]
Edmi,
[HALL
89]
James E., Performance Evaluations of a Parallel and Expandable
Database Computer - The Multi-Backend Database Computer, Master's
Thesis, Naval Postgraduate School, Monterey, California, June 1989.
f
[HSIA
89]
B.,
Hall,
Hsaio, D. K., and Kamel,
Issues,
and
Solutions",
Engineering, Vol.
[HSIA
91]
Hsiao,
D.
K.,
1,
"A
No.
M.
N.,
IEEE
1,
"Heterogeneous Databases: Proliferations,
Transactions
March
Parallel,
on Knowledge and Data
1989.
Microprocessor-Based
Scalable,
Database
Computer for Performance Gains and Capacity Growth", IEEE Micro,
December 1991.
[HSIA 92]
Hsiao, D. K., "Federated Databases and Systems:
Their Data Sharing",
[JOHN
78]
Johnson,
Murray
S.
C,
Hills,
VLDB Journal,
Part
I
-
A
Tutorial on
1992.
Yacc: Yet Another Compiler-Compiler, Bell Laboratories,
New
Jersey, July 1978.
[KELL
84]
Kelly, A., and Pohl, I., A Book on C - An Introduction to Programming
The Benjamin/Cummings Publishing Company, Inc., 1984.
[KLOE
85]
Kloepping, G. R., and Mack,
J.
in C,
E, The Design and Implementation of a
Relational Interface for the Multilingual Database System, Master's Thesis,
Naval Postgraduate School, Monterey, California, June 1985.
[LESK78]
Lesk, H. E., and Schmidt, E., Lex
Laboratories,
Murray
Hills,
-
A
New Jersey,
113
Lexical Analyzer Generator, Bell
July 1978.
[SCNI 92]
Shneiderman,
B.,
Designing the User Interface: Strategies for Effective
Human-Computer Interaction, 2nd
Company, Inc., 1992.
114
ed., pp. 11,
Addison-Wesley Publishing
3
INITIAL DISTRIBUTION LIST
Defense Technical Information Center
Cameron
Station
Alexandria, Virginia
22304-6145
Dudley Knox Library
Code 052
Naval Postgraduate School
Monterey, California
93943
Chairman, Code
CS
Computer Science Department
Naval Postgraduate School
Monterey, California
93943
Director Training and Education
MCCDC Code C46
1019
Elliot
Road
Quantico, Virginia
22134-5027
Professor David K. Hsiao
Computer Science Department
Naval Postgraduate School
Monterey, California 93943
Captain Paul A. Bourgeois,
USMC
103 Adventure Trail
Cary, North Carolina
275 1
115
DEMCO