Research Informatioin Center

National Bureau of Standards

Gaithersburg, Maryland 20899

NBSIR 88-3709

I'SL.aS 1 ou

mar 1 » 1988

Reference Model for DBMS User

Facility

by

User Facility Task Group

of the ASC X3/SPARC Database System Study Group

Authors:

Elizabeth Fong, National Bureau of Standards

John Gersting, Indiana Univ.-Purdue Univ. at Indianapolis

Kate Kinsley, Datawise, Inc. Nancy McDonald, Computer Technology Planning

John North, AT&T Technologies

Mark Sastry, Honeywell Inc. Edward Stull, GTE Government Systems

January 1988

*

U.S. DEPARTMENT OF COMMERCE

NATIONAL BUREAU OF STANDARDS

NBSIR 88-3709

REFERENCE MODEL FOR DBMS USER

FACILITY

by

User Facility Task Group

of the ASC X3/SPARC Database System Study Group

Authors:

Elizabeth Fong, National Bureau of Standards

John Gersting, Indiana Univ.-Purdue Univ. at Indianapolis

Kate Kinsley, Datawise, Inc. Nancy McDonald, Computer Technology Planning

John North AT&T Technologies

Mark Sastry, Honeywell Inc. Edward Stull, GTE Government Systems

January 1988

U.S. DEPARTMENT OF COMMERCE, C. William Verity, Secretary

NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director
M-

. , -.^r" ' • ;;r";l5 «!.,'

*

•• --••*’^- - ••

• fiV’C.':.*:-

'

'. pS^ "!;¥<' : :.

p?. • ' •'

V

' l.r?'' .
TABLE OF CONTENTS

PREFACE 1

EXECUTIVE SUMMARY 2

1. INTRODUCTION 3

1.1 PURPOSE AND SCOPE . 3

1.2 STRUCTURE OF THE REPORT 3

1.3 EXPLANATION OF THE TERM "REFERENCE MODEL" .... 3

1.4 USES OF A USER FACILITY REFERENCE MODEL (UFRM) . . 3

1.5 RELATIONSHIP OF UFRM TO OTHER DATABASE REFERENCE

MODELS 4

1.5.1 The DAFTG Reference Model 4

1.5.2 The Communications Model 5

1.5.3 The Actor/Act/Action/Message Model .... 5

1.5.4 The Fundamental Theory of Computation Model 6

2. BACKGROUND 7

2.1 INTRODUCTION 7

2.2 THE USER ENVIRONMENT/USER FACILITY 7

2.2.1 The DB User Task Translation Sequence ... 8

2.2.2 User Roles 9

2.2.3 User Attributes 12

2.3 INTERACTION DEVICES 14

2.4 EXISTING DBMS FACILITIES 15

3. USER FACILITY REFERENCE MODEL 16

3.1 INTRODUCTION 16

3.2 FUNCTIONAL DESCRIPTION OF THE USER FACILITY ... 16

3.3 COMPONENTS OF THE UFRM 16

3.4 POTENTIAL COMPONENTS FOR STANDARDIZATION 19

3.4.1 The User Data Language Interface (UDL) ... 19

3.4.2 The Internal User Data Language Interface

(iUDL) 22

3.4.3 The Data Language (DL) and Internal Data

Language (iDL) 23

3.5 EXAMPLE 23

3.6 SUMMARY 25

4. . CONCLUSION AND FUTURE WORK 27

5. REFERENCES 28

6. GLOSSARY 29
.,3-

P

4^

IV

r

S-'

SX

' u: 3J' .»* <i. Vi

^^1,. ax. di

Bl

su

^ i”

'

fix

£X

s.firs

i'i i;.

it

"

' ^ i,. '*' *

ikiMj

lOKajjasa® a«/.6Ai?A<i mmK>

y

*' *- .' ,•' a

• t

‘v-

' '

'

, X. -; ;-:'

'

' :;

* - . '^ i'.- ^ ^ . V- , ,, '\-

,

.. -''A-. X

'

,

- ' '-A-'

. . . . • * ,-i. ,-:' '.: <-, ^oriowoiiTifi

*?0 ^DX^X5iD^30 JilHOIXQWlP'^

m%^ JiCBi'*' tc)

i i, , . Koxm^xaE^d-WAX^s.xKOf

, X . -( J.O0 )

-

' i!s:? a®;' f

.sie.d l^Ci:mstnT

• ' » '* ^'* ,• /# * • * * '» ' *, » *' * -’‘‘ » * ..i^ - \X'Od^ y

'X b'Jb'^ bgi£ '(Jd) 0:p&p"g^'%ski ®,:^'Bd; ''t.^%'dti

, . - -'. •. -?’»,.• «. - . . « ^ {JCU) ^^t^rngmCL ,'i ;

' a»«si&SEa . f,

VM«. 0KI

.-' ,<;»-> 3 j, JU 7

*2^'

,.

.. . -:

; ,..,

- *?• w

««(«»

.*

' -

- aw' ^

• * •« tf ' ^

» .?!

‘ 4

.* -

* <> 'V «). u ,X A «

' 4'

,

,

I - r.r .A^

5f'

i-'.i.;-.'v-'i

..-. ,A- (,
LIST OF FIGURES

Figure 1.1 - DAFTG DBMS Reference Model 5

Figure 1.2 - Communicating Actors 6

Figure 2.1 - User Task Translation Sequence 8

Figure 2.2 - User Roles 10

Figure 2.3 - User Roles to Attributes Matrix 12

Figure 3.1 - A Unified Perspective 17

Figure 3.2 - The User Facility Reference Model (UFRM) ... 17

Figure 3.3 - User to DBMS Communication 2 0

Figure 3.4 - Example Flow in UFRM 24

Figure 3.5 - Organization of current tools 25

Figure 3.6 - UFRM/DAFTG RM configuration 26
,vM'

^ -f

.-•T yj-w^..

Pr-.'.

,,

^ '* ^.T.? ': ' 'r't

vf ’.» ..:r:^~^i^‘"::;r

J ., -i' - “Wr, .

;.,, -\K :

d.lXUk^'

.y«

J#:'

' ,'Tr*.. .*

,;: I'.r

/’"•'

' fti’-'/'V vwv=

- m

;i»3'

' • ... '.Ji 'I.j:(i>jJ

.

, ., ...v! '••''

;f " '

•• 'h., ''; !'-.. H i * 4 '^•-V-

)V5.

-V

‘

'

-'.. • Ci- 01

, , '.m

’•'*V

^

i. K'

' \19JS

• f' ' - Mv iii.

, l-,»i

fe

*

A/4 '.<©'
PREFACE

This report is a contribution to X3/SPARC Database system

Study Group (DBSSG) . The technical work represents the careful

distillation of the contribution of the authors and others who

have participated in the meetings and studies of the User

Facility Task Group (UFTG) which is a sub-group of the DBSSG.

The UFTG invites comments and suggestions for improvement.

Please forward your comments to;

Dr. John Gersting

Computer and Information Science

Indiana University Purdue University at Indianapolis

P. O. Box 647

1201 E. 38th Street

Indianapolis, IN 46223

This work was done under the leadership and chairmanship of:

Dr. Nancy McDonald

Computer Technology Planning

550 North Reo Street

Suite 222

Tampa, FL 33609-1033

1
EXECUTIVE SUMMARY

In this report we present the following reference model for the

user facility portion of a database management system.

UFRM DAFTG RM —

-j

I • l> <1 |>i<l |> <|D1> <|H1

lU.TI >U< luj >U< IDl > < IM] >i< io|

I S . C |==> D <==| F 1==> D <==| M |==> D <==j C j==> D <== | S | lE.Sj >L< I I >L< ITI >L< |si >L< \ T \ |R. |><j !><! |><j j><| I 1*1 li il It II

+ - -+ + + + + +-—+ + +

The User Facility Reference Model (UFRM)

This figure is a representation of a database management system

beginning with the user at the left and ending with the computer

system on the right. The model depicted here is composed of two

major parts, the User Facility Reference Model (UFRM) , which is

the topic of this report, in conjunction with the DAFTG (Database

Architecture Framework Task Group of the DBSSG) reference model

[DAF85] . There are three components of the UFRM, the User

Facility (UF) , and the interfaces; the User Data Language (UDL)

and the Internal User Data Language (iUDL)

.

The UDL is the single interface between the user environment and

the UF. It provides a uniform mechanism through which user

requests and resulting responses can be posed.

The UF contains components that process messages from and present

output to the user. It also sends and receives information from

the DBMS.

The iUDL is the single interface between the UF and the Data

Management Tool (DMT) layer of the DBMS. It provides a mechanism

to categorize the connections needed by various tools, thus

providing for reusability of UF implementations.

The User Facility Reference Model offers a separation between the

Data Management Tools and the User. The User Data Language and

the Internal User Data Language are candidates for

"standardization". Since the Data Management Tool Layer is

continually evolving and current technology often embeds a user

interface in each tool, the process of "standardization" must be

staged. The work here indicates that the User Data Language can

provide a focus for the start of this process. This report also

provides a theoretical basis from which a User Data Language

could be developed.

2
1 . INTRODUCTION

1.1 PURPOSE AND SCOPE

This report describes the aggregate work of the User Facility

Task Group (UFTG) of the Database System Study Group (DBSSG) in

developing a Reference Model for a database management system

user facility.

1.2 STRUCTURE OF THE REPORT

This chapter gives a short definition of the term "reference

model" and indicates how one may be used. In addition, a brief

review of other models examined by the UFTG is given.

Chapter 2 looks at the user and various devices that might be at

the user's disposal.

Chapter 3 suggests a User Facility Reference Model in terms of

component and functional descriptions.

Chapter 4 concludes, and discusses avenues for future work.

1.3 EXPLANATION OF THE TERM "REFERENCE MODEL"

The term Reference Model (RM) [FON86] is defined as a conceptual

framework for a subject area. The main use of an RM is to divide

standardization work into manageable pieces and to know at a

general level how these pieces are related to each other. This

definition is especially appropriate for this effort that seeks

to provide some order and structure to the User Facility (UF) of

a Database Management System (DBMS)

1.4 USES OF A USER FACILITY REFERENCE MODEL (UFRM)

There are numerous benefits that will be gained from the

development and acceptance of a UFRM for users, purchasers,

vendors, designers, servicers, teachers, and students of DBMSs.

Some of these benefits are discussed below.

* Promote understanding of DBMS.

By separating the DBMS functions from the user facility

functions and highlighting the interfaces between these

two sets of functions, many people will obtain a better

understanding of the DBMS inner workings as well as the

manner in which those workings are reflected to the

user populations.

* Help maintenance and control activities.

Through this type of top-down division of systems.

3
developers and users will obtain an increased

understanding of functions, which leads to easier

maintenance and stronger control mechanisms.

* Provide guidelines for modularization of functions and

standardization of interfaces.

The identification of pieces and their

interrelationships will establish a framework for

standardization. Such a framework will enhance

portability of software, improve human productivity,

reduce training requirements, provide comparability,

and potentially reduce costs of products.

* Aid in Comparison and Selection of Systems.

The categorization of the UFs is the first step toward

their qualification. This in turn aids the efforts of

organizations to choose, change, train for, and

maintain a new UF and/or DBMS.

1.5 RELATIONSHIP OF UFRM TO OTHER DATABASE REFERENCE MODELS

The DBSSG/UFTG reviewed several models related to the user

facility area. The most important of these was the DBSSG/DAFTG

(Data Architectural Framework Task Group) Reference Model [DAF85]

since it is used to establish the relationship between the user

facility and the proposed DBMS reference model. Other models

examined were Foley's model of communication [F0L81] for the

human elements of the problem, the actor/act/action model [HEW73]

for its humanistic appeal, and the fundamental theory of

computation for its computer orientation.

1.5.1 The DAFTG Reference Model

As will be seen, the User Facility Reference Model (UFRM) will

serve as a front-end to the DAFTG DBMS Reference Model ; these

together form a functionally compatible means of describing

interaction between the user and a database system. (See Figure

1 . 1 .)

The DAFTG Reference Model itself consists of three components,

each communicating via a language interface. Starting from the

right in Figure 1.1, the Operating System (OS) supports the DBMS

and communicates with the Data Mapping Control System (DMCS)

through the internal Data Language (iDL)

.

The DMCS is the "core" DBMS and provides operators for data

manipulation and data description. The Data Language (DL)

interface is the data manipulation language for the DMCS data

4
model. The Data Management Tools (DMT) represent software tools

that support high-level functions such as high-level query

languages, graphics-systems, report writers and database design

tools. There, tools communicate with the DMCS through the DL

interface.

U DATA

S DATA MAPPING

E MGMT CONTROL OPERATING

R TOOLS SYSTEM SYSTEM

S

DMT DL DMCS* iDL OS

^ Data Language internal Data Language

USER FACILITY DAFTG Model

Figure 1.1 - DAFTG DBMS Reference Model

1.5.2 The Communications Model

The Communications Model [F0L81] consists of four layers. At

the highest layer, the conceptual layer defines the key

application concepts of objects, relationships, and operations on

these objects in terms understood by the user. The semantic

layer defines items needed for each conceptual operation as

specified by the user to the machine and the machine to the user.

The syntactic layer defines sequences or a grammar of the tokens

exchanged between the user and the machine. The lexical layer

associates the primitive operations of the support hardware with

the tokens of the syntactic layer.

1.5.3 The Actor/Act/Action/Message Model

The Actor/Act/Action/Message Model (A3M) [HEW73], described in

this paper, is a modeling approach that is based on artificial

intelligence concepts and provides a humanistic model. Described

here is a perception where database actions are considered to be

the result of database acts being carried out by database

actors

The meta-model applied here for studying behavior in user

facilities extends the actor system of C. Hewitt and the

concept of object programming. Actors have the following

properties

o An actor may perform any number of acts. The

behavior of an actor results from the

"actions” taken as it performs an act.

5
o An actor embraces the internal knowledge

about itself.

o For communication, an actor may monitor and

send messages to other actors over one or

many communications channels.

Actors are agents that carry out acts resulting in actions as

pictured in Figure 1.2. An actor specified as an example of one

or more other actors may inherit properties from these

actors. Lateral actors are autonomous and may only communicate

through messages.

Figure 1.2 - Communicating Actors

1.5.4 The Fundamental Theory of Computation Model

The fundamental theory of computation (FTOC) Model is simply that

a machine, concrete or abstract, produces a result based on

descriptions (e.g. , data, instructions) operated upon by a set of

description-manipulating functions (sometimes called the

interpreter)

.

6
2 . BACKGROUND

2 . 1 INTRODUCTION

Three areas for collection of background information surfaced

early on:

- the user environment

modes of interaction with the DBMS (primarily

hardware devices)

"facilities" available in current DBMS

implementations

These areas were examined in some detail. This chapter contains

the salient results of these examinations.

Little is included on the latter two areas. These are mostly

subsumed in the DAFTG, which became available during the course

of the UFTG's studies, and by the User Facility Reference Model

itself. The user is still the most important element of the

study and will be the focus of the next sections.

2.2 THE USER ENVIRONMENT/USER FACILITY

The UFTG's decision to address the user facilities' needs for

DBMS and not the general user facilities for all of the user's

computing needs was appropriate for a subgroup of the DBSSG.

However, the UFTG quickly discovered that limiting the scope of

the project to DBMSs did not really limit the scope of the user

facilities since DBMSs are rapidly becoming the backbone to most

computer application systems.

Reviewing past research in related areas proved only partially

helpful. The existing literature about DBMS user facilities

mainly concentrates on such narrow aspects of the user's

interaction with DBMSs as query languages or experiments with

"novice" users.

The work of [MCD82] and [VAS82] developed classification schemes

for the functionality of query languages and for query language

users. They then developed a set of tables to aid the users in a

preselection of query languages based upon the user's interaction

capabilities, the structure of the task under consideration, and

the functionality of the query language. The final selection is

most often based on other indirect criteria such as cost and

existing hardware and software compatibility. Even though the

cited work addresses only a portion of the user facilities, query

languages, it has aided us in defining and combining the various

user attributes and in developing the table that associates user

roles with user attributes.

7
The British Computer Society, first through its Query Language

Group and now through its End User Systems Group and some of its

members, has produced several related papers, [BCS81] , [TAG84],

and [TAG85] . This work initially concentrated on query languages,

but now is aimed at models for user interactions with computing

systems. The UFTG members have used these ideas in our

discussion for relating user facilities to database architecture.

The use of a dialog manager and service manager interfacing to

the data access routines and application programs supports the

separation of the UF from the DMT layer in our work.

2.2.1 The DB User Task Translation Sequence

A user facility must provide good support for aiding the user in

performing a specific task with the DBMS. The task will differ

considerably depending upon the user's current role. It varies

from defining additional data structures for the database, to

building a new application program for performing a monthly

summary, to browsing through a portion of the database to help

make a business decision. But there is a common thread for all

the tasks independent of the user's role - the way a user

approaches the translation from his mental representation to the

physical sequence of operations that interact with the I/O system

or the user facility. The User Task Translation Sequence is

depicted in Figure 2.1.

User

I Task Representation

TASK INTERFACE Conceptual

I Functional Representation |

TOOL INTERFACE Semantic

I Dialogue System

DIALOGUE INTERFACE Syntactic

I I/O Subsystem

Figure 2.1 - User Task Translation Sequence

8
The user has a conceptual model of the various objects, their

relationships, and the manipulations necessary to solve a task.

This Task Representation is usually in terms familiar to the user

(e.g. a business model of the enterprise and its goals) . This is

typically too conceptual for immediate translation to the system.

Thus the user first translates the Task Representation into a

Functional Representation that the system knows. This Functional

Representation includes the various data structures and commands

that the database management system uses. But even this set of

objects and commands must be translated into terms that the

Dialogue System understands before the user can interact with the

system.

The Dialogue System supports the user with many different modes

including menus, forms, command prompts, icons, etc., depending

upon the user's previous knowledge of the system, the task, and

the environment. Finally, the user translates a request from the

Dialogue System into physical movements or operations such as

entering keystrokes, picking an item on a menu, or speaking the

request to a voice recognizer.

As projected in Figure 2.1, the user performs a sequence of

mappings from the user's mental task representation into the

physical interactions with the user facility. We have indicated

the relationship to the conceptual, semantic, and syntactic

notions along the right side of Figure 2.1. The conceptual

mapping translates the user's mental Task Representation into the

functional representation the system knows; the semantic mapping

maps the database objects and functions to the various

representations available to the user in the Dialogue System; and

the syntactic mapping allows the user to interact with various

dialogue representations by manipulating the physical devices of

the user facility.

2.2.2 User Roles

In the early days of DBMSs the user classes of database

management systems were more distinct - the database

administrator was responsible for maintaining all the data

objects associated with the database management system as well as

monitoring and optimizing system performance; the application

programmer developed the transactions via screens for capturing

the information entered by the data clerks to be stored on the

database; and the end-user made use of reports generated from the

application programmer's programs.

Today, the use of DBMSs has migrated from mainframe systems,

through departmental computers, to single user workstations and

computers. The single user computer is often used by small

businesses to run one or more applications using a DBMS. This

9
migration has clouded the distinction of user classes so much

that it is best to consider users in the roles they are executing

at a moment in time.

The major roles that will be considered in this reference model

include the system programmer, the application programmer, the

database administrator, and the end user. Obviously, there are

many different subroles under each major role. Each role has

associated with it attributes that are necessary for the

successful execution of the role. Besides the human roles that

we usually associate with information systems, we must also

consider the virtual user. This is a computer system that has

been developed and implemented to stand-in as an agent for the

human. Figure 2.2, User Roles, shows the simple analysis of four

specific roles, the interface tool required, and the system

component needed.

Interface System

Role Technicme Component

database

system

programmer

prog I operational

lang j* environment

database 1 high | application j order j application

programmer j lang j generator

database 1 data

administrator j def

I lang

information

resource

dictionary

system

database | data | operational

end 1 manip j data

user 1 lang j base

Figure 2.2 - User Roles

The system programmer role deals with either the DBMS software

itself or utility programs written to support the administration

of the database. There are three major subroles in this group - the DBMS system programmer, the DBA system programmer, and the

tool builder. Each of these subroles demands a high level of

10
knowledge of the system's data structures, the hardware, and the

interface and functions of the operating system. People in these

roles direct the action of the system.

The DBMS system programmer develops interfaces to the internal

access methods, command language interpreter, etc. The DBA

system programmer subrole writes utilities to aid in tuning the

system, in performing the backup and recovery of database files,

or in restructuring the database. The tool builder creates a

level of abstraction for application programmers to use when they

want to interface with the DBMS.

The application programmer role deals with extending the range of

data covered in the database while incorporating new functions

within the information systems for the enterprise. This

application programmer often uses a programming language

interface with the DBMS, writing much of the application code in

procedural computer languages. These applications tend to deal

primarily with transaction oriented production systems that have

regularly scheduled reports. In the last several years there has

been a push to infiltrate the data processing department with 4th

generation languages to improve the application programmers'

productivity

The DBA role deals with the metadata for the DBMS. This includes

the definition of the data elements, the enterprise and logical

structure of the data, different user views, and permissions for

security and privacy. Some organizations separate this role into

a DBA subrole that is concerned with interfacing to the

application programmer and the data administration (DA) role that

is concerned with the enterprise model . The DBA has a high level

of knowledge about the metadata and medium knowledge about the

real world data; this is reversed for the data administrator

since he must model the enterprise.

The end-user role is the fastest growing segment of DBMS users.

There are two groups of users, based on the frequency with which

they use the DBMS. The casual user group consists of the

infrequent data entry person, the intermediary for an

organization or management, and management itself. This group

requires a "user-friendly" front end to a general purpose query

language typified by natural language, graphics, or menus and

forms. The daily user group contains the regular data

entry/ inquiry person who, being familiar with the system, can

bypass some aspects of the restrictive front end, and the

analyst/researcher who uses the computer as an integrated tool

for compiling specific information relative to a job function.

These users utilize more command oriented query languages, forms,

non-procedural report languages, and specialized 4th generation

languages

11
2.2.3 User Attributes

Each user role has a set of attributes associated with it as

depicted in Figure 2.3. The first attribute is domain knowledge.

Each user has some knowledge of the domain within which the user

is working. This knowledge can vary from just enough to perform

a data input operation to a level high enough to realize the

ripple impact of changing one data field. Domain knowledge is

typically associated with level of experience and training. As

an example, a DBA programmer writing a utility for restructuring

the data within a database could have little understanding of the

real world data but would have a very good understanding of the

data dictionary metadata. People typically dealing with metadata

receive much more training than many of the end users dealing

with the real world data.

ATTRIBUTES

I skill level | dialog style

|

ROLES

1 domain

1 knowl

1

1 data 1 appl

1 str 1 str

1 hdw

1 |os|

- — 1

sys

dir

user

dir

1 resp

1

1 time 1 -

1

system pgmr

DBMS sys pgmr

1

1

1 L

1

1

1 H L H

1

1 H 1 L H

1

!

1 L

DBA pgmr 1 L 1 H M H H 1 L H 1 L

tool builder 1 M

1

1 H H H H 1 L H 1 L

application pgmr

DP dept pgmr

1

1

1 M

1

1

1 M H M

1

1 M 1 L H

1

1

1 L

info cntr spec 1 L 1 M L M M 1 L H 1 M

dept support 1 M

1

1 M

1 H M M 11 L H i M1 database admin

DBA

1

1

1 H

1

1

1 H M M

1

1 M 1 L H

1

1

1 M

DA 1 H 1 H M M M 1 M M 1 M

end-user

casual users

inf input

1

1

1

1 L

1

1

1

1 L L L

1

1

1 L 1 H L

1

1

1

1 H

intermediary 1 M 1 M M M M 1 M M 1 M

management 1 H 1 M L L L 1 M M 1 M

daily users

reg input

1

1 L

1

1 L L M

1 L 1 H L1

1 H

anal/rschr 1 H 1 M M M M 1 L H 1 H

L = low, M = medium, H = high

Figure 2.3 - User Roles to Attributes Matrix

12
The skill level attributes help differentiate user roles. Skills

encompass familiarity with and ability to manipulate the data

structure (data str )

,

the application structure (appl str) , the

hardware (hdw) used to interface the user to the computer

system, and the underlying operating system (os)

The expertise needed to manipulate the data structure involves

knowing the data elements, the records, and the relationships

between the records. A programmer usually has more knowledge and

concern about the data structure than an end-user who relies on

the system (e.g. help screen, on-line tutorials, forms, graphics)

to help him remember all the data structure attributes.

The application structure skill level requires knowledge about

the operations, the relationship between the operations and

programs, and the transactions, forms and various output

reports. A frequent user may tire of too much system direction

(sys dir) found in rigid prompts, menus, or forms; rather, he may

prefer a user directed (user dir) dialog found in most command

oriented interfaces. The tool builder on the other hand needs

different tools to extend the operations and ensure that

extensions do not interfere with the existing operations.

The ability to use the hardware is tightly tied to the frequency

of use. Again, the highest level of expertise is typically

associated with the people building or enhancing the software

capabilities of the system. The end-user, on the other hand, has

benefited from the drive for "user-friendly" hardware devices

such as pick devices (mouse, light pen, touch screen) , multicolor output devices, high-resolution graphics, etc. Though the

end-user at his own workstation or personal computer has gained

control over the time when data is input, the structure of

reports, and the overall flexibility in dealing with the data, he

no longer can depend on the operators and support staffs found in

large data processing organizations to insulate him from

hardware issues and problems.

Knowledge about the operating system is an important attribute

for users. The programmers must be able to invoke other

commands besides those associated with the DBMS since they deal

with existing data files and generating data files to be used by

other processes on the computer. The end-user prefers to have

all these operating system functions integrated into his

interface facility to minimize his education and memorization

needs

The Dialog Style attribute has been divided into two parts - system directed (sys dir) , and user directed (user dir) . The

notion put forth by this attribute is that there is a low,

medium, or high utilization of dialogue styles by user roles.

Certain dialog styles are easier to learn, more flexible, and/or

easier to use for certain roles.

13
A system directed dialog style typically has less flexibility.

The system must track its current state and determine a list of

possibilities from this state. System directed dialogs are

typically associated with either the casual user or a frequent

data entry person who has just a few possible tasks to perform.

The more knowledge of the domain and the higher level of skills a

user has, the more likely that this user will become bored with a

system directed dialog style.

On the other hand, programmers and daily users needing

flexibility will choose a user-directed dialog style. This style

is typified by command languages often supported with macros

and/or command procedures to execute often run sequences of

operations. These users are often concerned about the

extendability of the command language so they can tailor their

own work environment. One of the recent user-driven dialog

styles is the desk-top metaphor that permits multi-tasking.

Response time requirements are based both on the user's real-time

needs and the user's expected response time. Often the enduser's expectation of response time cannot be met. Some users

lack an understanding of the total number of operations, the

impact of shared resources, and the audit and recoverability

issues needed to achieve a successful completion of a function.

Hence, many users are looking to dedicated workstations to solve

this problem of variability of response times when they use

shared computer systems. Dedicated systems definitely provide a

more consistent response time operating in a single process

environment, but the use of multi-layer interfaces on these

workstations will cause the response times to elongate. The user

who chooses a dedicated workstation must also become responsible

for providing the audit and recoverability of functions, the data

to other users, and the concern for performance.

2 . 3 INTERACTION DEVICES

Another of the initial concerns of the UFTG was how the user

interacts with the DBMS. Lists of devices were compiled,

including the obvious items of keyboard, light pen, mouse, voice,

etc. These lists seemed to require continual updating. In any

case, from a reference model point of view, the problem became

intractable (e.g., should defining a standard mouse interface be

part of the UFRM development?)

.

Figure 2.1 suggests that the task, not the device, is the

important item. For example, the user might be requested to make

a forced choice among, say, five items. This choice involves

"traffic" over the user interface. Such traffic should be

independent of the mode of presentation of the choice (e.g.,

menu, command line, and so forth) and of the device used to make

the choice (e.g., light pen pick, key stroke, and so forth). In

14
this case, the UFRM proposed later in this work might take on the

form of 5 items passing toward the user and one of the 5

returning.

In order to render the hardware problem tractable, the proposed

"interface” will be between the devices available to the user and

the rest of the DBMS, as opposed to an interface between the user

and the devices.

2.4 EXISTING DBMS FACILITIES

The third area of background investigation was the facilities

available in current DBMS implementations. Again, the limitation

of a database orientation did not really limit the scope of the

problem because a graphics display system or a statistical

package can present equally valid user facilities for databases.

The problem was to separate the user facility from a particular

user interface. Feature analysis techniques for some selected

systems were developed, but the results were difficult to

evaluate

When the DAFTG Reference Model became available, it provided a

solution to the problem in the form of the DMT, Database

Management Tool Layer, a "top layer." The natural place for the

user interface is between the user and the DMT. The next chapter

presents these ideas in more detail.

15
3. USER FACILITY REFERENCE MODEL

3.1 INTRODUCTION

The User Facilities Reference Model is defined to be a conceptual

categorization of functions/facilities that a database user would

like to use while interacting with a DBMS. It will provide a

common basis for the coordination of standards development, while

permitting existing standards to be placed into perspective. The

model has sufficient flexibility to accommodate advances in

technology and expansion in user demands. Accordingly, the model

should permit the phased transition from existing implementations

to new DBMS standards.

The database system is an agent that carries out a variety of

tasks on behalf of its user. It is from this perspective that

the database system must be studied to determine the support it

is to provide a user facility.

Figure 3.1 depicts the unification of the previously mentioned

models (DAFTG, Communications, A3M, FTOC) in the framework

proposed for the UFRM. The diagram itelf shows the form of the

proposed UFRM along with the DAFTG model. In the top of the

blocks are DAFTG terms (conceptual, syntactic, tool command,

database, operating system) . In the lower portion of the blocks

are the Communication Model's terms (semantic, lexical,...). The

D and I indicate data values and interpreters, i.e., that local

data and computing power exist at each stage. The A3M model is

used to describe how the "traffic" flows through the various

stages of the model.

3.2 FUNCTIONAL DESCRIPTION OF THE USER FACILITY

The User Facility Reference Model serves as a front end to the

DAFTG-DBMS Reference Model and together they form a functionally

compatible means of describing interaction between the user and

the system.

A User Facility: (1) transforms a user's request (for

information from a database) into functional requests for data

management tools and (2) maps the output from data management

tools into a presentation format to the user.

3.3 COMPONENTS OF THE UFRM

Figure 3.2 positions the UFRM within a database-oriented system.

This work focuses on the three components of the UFRM, called the

UF, UDL, and iUDL. The remaining portion of Figure 3.2 is the

DAFTG Reference Model. For completeness, all 9 of the elements

of Figure 3.2 are described below, first the processes (boxes)

and then the interfaces, denoted by > < .

16
abstract

representation

in

user's mind

concrete

representation

for machine

processing

H H

I Conceptual |

I Structures 1

I D I + +=

I I I

I Semantic |

I Interpreter j + +

}

}

} U {

} {

} U {

D

L

:===} {==

} {

} {

+ +

I Syntactic 1

I Structures j __l D

1

I I I

I Lexical |

I Interpreter j + +

Tool

Command

Language

D

D {====

L {

{

:+ +=

I Tool I I

I Command j

I Language j

1 Interpreter j + +

+• Database

+

) {

} D {

{

{

{

D

==)

}

}

====+. -+===>

Database

Management

System

} {

} i (

Operating

System

+

====) D {====+

} L {

} {

D

I

•+ Hardware

Host

Figure 3.1 - A Unified Perspective

UFRM DAFTG RM

+ + + + + + + + + +

I * l> <1 |>i<| |> 
 <|H| |U.T| >U< |U| >U< IDI > < 1M| >i< |01

I S . C 1==> D <==| F |==> D <==| M 1==> D <==i C |==> D <== | S | |E.S| >L< I I >L< |T| >L< |S| >L< |T| |R. !><! !><! !><! !><! I

I • j II II II II

+ + + + + + + + + +

Figure 3.2 - The User Facility Reference Model (UFRM)

17
Processes:

o The term "user" represents a user environment

that interacts with a DBMS. This includes

the human component examined in Chapter 2 and

may include hardware devices in the form of

the TCS, Terminal Control System.

o The User Facility (UF) contains components

that process messages from and presents

output to the user and in turn directs and

accepts data to and from the database

management system as defined by the DAFTG of

the DBSSG.

o The Data Management Tools (DMT) processor,

as defined by the DAFTG, contains software

components that are plug-compatible with the

DMCS through the DL-interface . A simple DMT

could be a data definition language macro

facility which would transform DDL statements

into sequences of DL statements.

o The Data Mapping Control System (DMCS) , as

defined by the DAFTG, is a "core" database

management system (DBMS) supporting and

enforcing the ANSI/SPARC dimension of

external , conceptual , and internal schemas

and the orthogonal intension-extension

dimension of data model schemas, data

dictionary schemas, application schemas, and

application data. An active/dynamic data

dictionary system is an integral part of the

DMCS. Although the DMCS would be typically a

one-data-model DBMS, it is the core of a

potentially multi-data-model DBMS.

o The Host is the computational host for the

DMCS. The DAFTG defines Operating System

(OS) as part of the environment of a DBMS

which here is considered to be part of Host.

The operating system services in many

existing systems are either too slow or

inappropriate to support the DBMS. Therefore,

many current DBMSs provide their own

operating system environment. Future

operating system designers must recognize

such needs of the DBMS; these needs are to be

specified in the iDL interface.

18
Interfaces

o The User Data Language (UDL) is the

interface to the UF. UDL is an interface

between the user and user facility to

transcribe user requests and present the DBMS

responses

o The internal User Data Language (iUDL) is

the interface to data management tools so

that the user is not required to learn what

may be the specialized language requirements

for each data management tool

o The Data Language (DL) is the single

interface to the services offered by the

DMCS. It is the data manipulation language

for the fundamental data model of the DBMS

The fundamental data model is a data model

that supports the established data models

such as the relational, the

ent ity~relat ionship, the network, the

object-role models. Because of the

intension-extension dimension of the data

description and because the fundamental data

model is used at all levels of this

dimension, the DL supports both data and

meta-data management. The data model schema

is self-describing and thus all data

including data descriptions are defined,

retrieved, and manipulated through the DL

interface

o The internal Data Language (iDL) is the

single interface between the DMCS and the OS

through which all data is passed whether real

data, meta-data, meta-meta-data, etc.

3.4 POTENTIAL COMPONENTS FOR STANDARDIZATION

In keeping with previous standards practices, interfaces within

reference models are likely candidates for standardization. For

the UFRM this would be the User Data Language and the Internal

User Data Language.

3.4.1 The User Data Language Interface (UDL)

Communication between the user and the DBMS may be perceived as

an ordered series of assertions and interrogatives from one to

the other (Figure 3.3, User to DBMS Communication). Both

interrogatives and assertions are imperatives but here

19
imperatives are all those messages that are neither

interrogatives nor assertions. An interrogative message is

defined to be any action intended by the transmitting actor to

only examine knowledge available to the receiving actor. An

assertional message is any action intended by the transmitting

actor to cause a change to the knowledge available to the actor

receiving the message. In the most general sense, both

assertions and interrogatives of an actor may result in further

assertion and interrogative messages to the corresponding actor.

Note that both the transmission and receipt of a message are

actions resulting from an actor performing an act.

assertions and interrogatives

DBMS

assertions and interrogatives

Figure 3.3 - User to DBMS Communication

Assuming the DBMS is in operation, it somehow prompts, that is

interrogates the user for some act to be performed and upon

receipt, attempts to perform the act resulting in a corresponding

action possibly with side-effects to cause modification to the

database and advise (i.e., assert to) the user of its action.

Whether the user or the DBMS is in control is not important here.

What is important is the investigation of how it is that the user

may cause the DBMS to perform the correct act through a natural

and minimal effort on the part of both the user and the DBMS.

The following two definitions are provided from the database

system perspective:

1) An interrogative act is an act that

examines the content of the database. The

database may optionally respond to the user

with the results of the examination.

2) An assertional act is an act that causes a

change in the state-of-af fairs of the

database. It typically would be a statement

of new information with an embedded or

implied modification-type command.

20
In the most general sense, assertional acts may result in

other assertional acts as well as interrogative acts. Note:

Composite operations, such as audit trailing and user

queries, are considered a composite of both assertional and

interrogative acts.

All assertions belong to one of four major classes:

1) extend - The extend assertion adds new

knowledge (extensionally) to the knowledge

base.

2) update - The update assertion modifies

existing knowledge. The modification

identifies the previous knowledge as being

out-of-date and revokes it. Depending on the

intent of the roles involved, this may

initiate other appropriate actions such as

notifying the change.

3) correct - The correct assertion, like the

update assertion, modifies existing knowledge

and revokes it. However, the modification

identifies the previous knowledge as being

incorrect and, depending on the intent of

the roles involved, may initiate other

appropriate actions such as signaling an

error and resolving problems specified in the

cognitive models that used the incorrect

knowledge.

4) revoke - The revoke assertion also modifies

existing knowledge. Revoking explicit

knowledge may or may not cause deletion from

the information store depending on the

intent of the roles involved as in the

update and correct assertions. For example,

revoking implicit knowledge (i.e. information

which does not exist physically but must be

computed) causes knowledge to be added to the

information store that initiates failure of

the inference (i.e. computed information) for

the implicit knowledge being revoked.

Any system that assimilates new knowledge must both provide and

enforce semantics for the effects of assertion. This is perhaps

one of the weakest properties in many current knowledge base

systems. Often new rules and facts are admitted and stored

regardless of whether they make any sense in terms of the

existing knowledge. A sensible universe of discourse must always

21
be maintained and enforced between the external world and the

DBMS.

There are four important classes of interrogation:

1) The literal interrogation is an act that

attempts to solve a problem literally as

stated typically using only that inference

necessary to search the store of

information. Consider the fact: CPU is part

of computer. The fact employs the domain of

CPU, a relation of "is part of" and a

codomain of computer. A literal

interrogation of this fact would succeed only

if the problem were stated using any of

these three components (e.g.

,

<X> is part of

computer, CPU <Y> <Z>)

.

2) The explicit interrogation is a relaxation

of the literal interrogation. The relaxation

is to permit a limited inference over any or

all of the components of the problem.

Consider the problem: <X> has CPU. With a

small amount of inference, it may be reasoned

that <X> has CPU could be stated as CPU is

part of <X> thus leading to the solution of

CPU is part of a computer.

3) The implicit interrogation is the antithesis

of literal and explicit interrogation in that

it attempts to solve a problem by using

implied information. Even though the

information store contains the fact above,

implicit interrogation would only succeed if

it could somehow be implied that a CPU is

part of a computer.

4) The general interrogation is simply a

combination of all possible solutions

generated by interrogating literally,

implicitly and explicitly using whatever

information can be discovered to contribute

to the discovery of another solution. For

example, a literal interrogation may lead to

discovering an implicit solution, and so on.

3.4.2 The Internal User Data Language Interface (iUDL)

The iUDL provides the interface between the user facility (UF)

and the data management tools (DMT) . The iUDL provides a

mechanism to categorize the connections needed by various tools.

22
thus providing for reusability of UF implementations.

The existence of the iUDL makes the assumption that the data

management tools can be accessed directly by the iUDL, i.e.,

remotely from the user. This would provide access to data

dictionary tools or graphics tools from the UF. Embedding the

details of such accesses at the iUDL, the user need only see the

UDL view of these tools while benefiting from their full

capabilities

Currently many data management tools must be invoked directly by

the user. Providing categorization for the interfaces of the

wide variety of tools that will become available is an area for

future work.

3.4.3 The Data Language (DL) and Internal Data Language (iDL)

The remaining interfaces in Figure 3.1 are the DL and the iDL.

These are part of the DAFTG Reference Model.

3 . 5 EXAMPLE

Figure 3.4 demonstrates how the User Facility Reference Model

integrates with the DBMS Reference Model. For example, a row

could be inserted using a software tool such as Query-By-Example.

The UDL interface accepts the signal from the input device

whether it is a keyboard, light pen, audio or video response,

etc. —and sends it to the UF. The UF then interprets this signal

into the binary code that represents the action, such as the

number "1" selected from a menu, and passes it to the DMT through

the internal-Data Language (iUDL) for processing. The iUDL is

the interface through which all data is passed between the DMT

and the UF. In a similar fashion, the UF relays the correct

control sequences to cause the output device to display, print,

etc. , according to the information passed to it by the DMT via

the iUDL.

23
FUNCTION: Insert via form

UDL iUDL DL iDL

User/TCS 1 UF 1 DMT 1 DMCS 1 OS

• • keystroke

select from

menu

. interpret

. keystroke

interpret

keystroke

to menu

retrieve

from

database

1

^ M M M «

• 1

1 form info v

form 1

1

1

1

. escape

. sequence

. characters .

interpret

form info

V

1 • • post ion cursor, interpret . enter contents keystrokes.

. to binary .

generate

check

validity

of DDL

1 check 1

1

1

1

1 ^

1 generate

append

DDL

• •

process

write to OS.

User/TCS 1 UF 1 DMT 1 DMCS 1 OS

UDL iUDL DL iDL

Figure 3.4 - Example Flow in UFRM

24
3 . 6 SUMMARY

The goal of the UFRM is to provide a framework within which

transportable components for a user facility can be constructed.

These components fit between the user environment and the DBMS,

more specifically between the user and the DMT.

A mechanism, the A3M, is proposed as a starting point for the

UDL. The A3M would be used to "phrase” the traffic between the

user and the UF across the UDL interface.

The figure below restates the problem. Reviewing current

technology indicates that most systems expect the user to

interact with the DMT layer directly. The tools have "built in"

interfaces. Figure 3 . 5 shows such a situation.

1 User 1

/ 1 \

/ 1 \

/ 1 \

/ 1 \

/ 1 • • • \

/ 1 \

Tool 1 Tool 2 Tool n

1 user [process! 1 user 1 process j 1 user [process

1 inter. j 1 j 1 inter.

2 1 I inter. j n

\ 1 /

\ 1 /

\ i /

\ 1 /

\ 1 /

\ 1 /

\ /

DBMS

Figure 3.5 - Organization of current tools

25
The UFRM and DAFTG RM suggest the configuration shown in Figure

3.6.

I Process 1 | / \

/ \

/ \

/ \

User ---| UF | ----- | Process 2 1 ----- | DMCS 1 \ /

\ /

\ /

\ /

I Process n |

UDL UF iUDL DMT DL DMCS

Figure 3.6 - UFRM/DAFTG RM configuration

The configuration in Figure 3.6 provides for portability and

modularity of system components without a large impact on the

user.

26
4. CONCLUSION AND FUTURE WORK

The UFRM described and discussed in this document is a

consolidation of models from graphics, cognitive psychology,

database technology, and theoretical computer science thinking.

We, the UFTG, have attempted to mesh the concepts from many

disciplines. A major consideration was consistency with the

DAFTG Database Reference Model since that was our application

focus. We believe that the UFRM is a natural outgrowth of the

general database reference model. Throughout this report, we

have attempted to explain how our thinking was influenced by the

various models we analyzed and utilized to achieve our result.

Future activities are expected to revolve around two general

areas: 1. review of existing products, and 2. design and

development of new UF products. Initially, we believe an

analysis of the effectiveness of present systems and subsystems

with unmodularized UFs will be useful to better understand the

features that are most useful for certain actions and to

extrapolate into a single UF. From that experience, we

anticipate some interesting development activities that will

incorporate the lessons learned.

It is expected that the UDL and iUDL will be standardized to

facilitate future DBMS development.

27
5. REFERENCES

[BCS81] British Ccomputer Society, "Query Languages - A Unified Approach", Report of the British

Computer Society Query Language Group, Heyden

& Son Ltd., Cambridge, Great Britain, 1981.

[DAF85] Database Architecture Framework Task Group

(DAFTG) of the Database System Study Group,

"Reference Model for DBMS Standardization,"

NBSIR 85-3173, May 1985. (Also published in

SIGMOD Record, Vol . 15, No. 1, March 1986).

[FOL80] Foley, James D., "The Structure of

Interactive Command Languages", Methodology

of Interaction, Guedj (ed.). North Holland

Publishing Company, IFIP, 1980.

[FOL74] Foley, James D. and Victor L. Wallace, "The

Art of Natural Graphic Man-Machine

Conversation", Proceedings of the IEEE, Vol.

62, No. 4, April 1974.

[FON86] Fong, E.N. and D.K. Jefferson, "Reference

Models for Standardization", Institute for

Computer Sciences and Technology, National

Bureau of Standards, Proceedings of Computer

Standards Conference, May 1986.

[HEW73] Hewitt, C. , P. Bishop and R. Steiger, "A

Universal Modular Actor Formalism for

Artificial Intelligence", Stanford

University, August, 1973.

[MCD82] McDonald, N.H. and J.P. McNally, "Query

Language Feature Analysis by Usability",

International Journal of Computer Languages,

Vol. 7, Nos. 3/4, 1982.

[TAG85] Tagg, R.M, "Object Modeling in a Generalized

End-User System", Unpublished paper, 1985.

[TAG84] Tagg, R.M. and M. Sandford, "Where to Now the

Mouse has Arrived?", Computer Bulletin (UK),

December 1984.

[VAS82] Vassiliou, Y. and M. Jarke, "A Framework for

Choosing a Database Query Language", NYU

Symposium on User Interfaces, May 1982.

28
6 . GLOSSARY

A3M - see Actor/Act/Action/Message Model

act - that which is carried out by an actor to perform an action

(see Actor/Act/Action/Message (A3M) Model)

action - the result of an actor carrying out an act (see

Actor/Act/Action/Message (A3M) Model)

actor - that abstraction which carries out an act resulting in an

action (see Actor/Act/Action/Message (A3M) Model)

Actor/Act/Action/Messaqe fA3M) Model - a model based on

artificial intelligence concepts. Actors are agents which

carry out acts resulting in actions. Each actor embraces the

internal knowledge about itself. The behavior of an actor results

from the "actions" taken as it performs an act. An actor may

perform any number of acts. For communication, an actor may

monitor and send messages to other actors. An actor specified as

an example of one or more other actors may inherit properties

from these actors. Lateral actors are autonomous and may only

communicate through messages.

ANSI - the American National Standards Institute

ASC - Accredited Standards Committee

BCS - the British Computer Society (BCS)

Communications Model - J. D. Foley defines a linguistic approach

broken into four layers of abstraction: the conceptual, the

semantic, the syntactic, and the lexical layers. The highest

layer, the conceptual layer, defines the key application concepts

of objects, relationships, and operations on these objects in

terms understood by the user. The semantic layer defines the

services needed for each conceptual operation as specified by the

user to the machine and the machine to the user. The syntactic

layer defines sequences or the grammar of the tokens exchanged

between the user and the machine. The lexical layer associates

the primitive operations of the support hardware with the tokens

of the syntactic layer.

DA - see Data Administrator

DAFTG - the SPARC/DBSSG Database Architectural Framework Task

Group

Data Administrator (DA) - Some organizations separate this role

into a DBA subrole that is concerned with interfacing to the

application programmer and the data administration (DA) role that

is concerned with the enterprise model. The DA must model an

29
enterprise with his understanding of the real world data and its

relationships as opposed to the Database Adminstrator (DBA) who

has a high level of knowledge about the metadata and medium

knowledge about the real world data.

Data Lanquacre (DL) - the single interface to the services of the

Data Mapping Control System (DMCS) . It is the data manipulation

language for the fundamental data model of the DBMS. The DL

supports both data and meta-data management.

Data Management Tools (DMT) - Data Management Tools processor is

a collection of software components that are plug-compatible

with the DMCS through the DL-interface. A sample DMT could

be a data definition language macro facility which would

transform DDL statements into sequences of DL statements.

The DMT supports high-level functions such as high-level query

tools. Each tool may have its own user interface.

Data Mapping Control System (DMCS) - a "core” database management

system (DBMS) providing operators for data manipulation and data

description, supporting and enforcing the ANSI/SPARC dimension

of external-, conceptual-, and internal-schemas and the

orthogonal intension-extension dimension of data model-, data

dictionary-, and application schemas, and application data. An

active/dynamic data dictionary system is an integral part of the

DMCS.

Database Administrator (DBA) - deals with the metadata for the

DBMS. This includes the definition of the data elements, the

enterprise and logical structure of the data, different user

views, and permissions for security and privacy. Some

organizations separate this role into a DBA subrole that is

concerned with interfacing to the application programmer and the

data administration (DA) role that is concerned with the

enterprise model. The DBA has a high level of knowledge about

the metadata and medium knowledge about the real world data as

opposed to the data administrator who must model an enterprise

with his understanding of the real world data and its

relationships

.

DBA - see Database Administrator

DBMS Reference Model - consists of three components, each

communicating via a language interface. The Operating System

(OS) supports the DBMS and communicates with the Data Mapping

Control System (DMCS) through the internal Data Language (iDL)

.

DBSSG - the X3/SPARC Database System Study Group

DL - see Data Language

DMCS - see Data Mapping Control System

30
DMT - see Data Management Tools

end-user - the fastest growing and largest segment of DBMS users

typically considered to be composed of two sub-segments depending

on frequency of use: the casual user and the daily user.

extensional information - the information being described by

intensional information.

FTOC - see fundamental theory of computation

fundamental data model - a data model that supports the

established data models such as the relational-, the

entity-relationship-, the network-, the object-role models.

fundamental theory of computation (FTOC) - is simply that a

machine, concrete or abstract, produces a result based on

descriptions (e.g., data, instructions) operated upon by a set of

description-manipulating functions (sometimes called the

interpreter)

Host - the computational host for the DMCS. The DAFTG

defines Operating System (OS) as part of the environment of

a DBMS which here is considered to be part of the Host.

Host Environment Actor - a more general concept for the DAFTG

Operating System. Here, the OS is considered data being operated

upon by the hardware. (Note, the firmware and microcode levels

are considered part of the hardware for simplicity.) This actor

also closely corresponds to Foley's lexical layer. There is no

good correspondence to the OSI except it might be said that it

would cover the OSI session through physical layers.

internal Data Language ( iPL) - the single interface between the

DMCS and the OS through which all data is passed whether real

data, meta-data, meta-meta-data, etc.

internal User Data Language ( iUDL) - the single interface to

data management tools. Thus, the user is not required to learn

what may be the specialized language requirements for each data

management tool . The iUDL provides the interface between the

User Facility (UF) and the Data Management Tools (DMT) . The iUDL

provides a mechanism to categorize the connections needed by

various tools, thus providing for reusability of UF

implementations

intensional information - the information that is description of

a description.

ISO - International Standards Organization

31
message - see Actor/Act/Action/Message (ASM) Model

OSI - see Open System Interconnection Reference Model

Open System Interconnection Reference Model fOSI) - the seven

layer architecture for autonomous communicating systems as

specified by the International Standards Organization (ISO)

.

reference model fRM) - conceptual framework for a subject area,

divides standardization work into manageable pieces and to know

at a general level how these pieces are related with each other.

SPARC - the Standards Planning and Requirements Committee of the

accredited standards committee Information Processing Systems

(X3) of ANSI.

Terminal Control System (TCS) - see User Facility (UF)

UFTG ” see User Facility Task Group

user “ the UFTG's abstraction to represent and describe any

user of the user facility; here, only those properties of a

user involved in using a database management system are

considered.

User Data Language CUDL) - the single interface to the UF. Most

DBMSs have user languages built-in to the DBMS. Under this

model, the user language is externalized relative to the DBMS.

Other languages are possible or an existing language may be

extended or adapted in the UF to accommodate the user. The UDL

interface accepts the signal from the input device—-whether it is

a keyboard, light pen, audio or video response, etc. —and sends

it to the UF.

User Facility (UF) - contains software components which process

messages from the user and in turn directs and accepts data to

and from the database management system as defined by the DAFTG

of the DBSSG. It is the major component of the User Facility

Reference Model and is the control system for the input and

output devices.

User Facility Reference Model (UFRM) - serves as a front-end to

the DBMS Reference Model and together they form a functionally

compatible means of describing interaction between the user and

the system. It is composed of five processors and four

interfaces. The processors are; the User, the DMT, the DMCS,

and the Host. The interfaces are; the UDL, the iUDL, the DL, and

the iDL.

User Facility Task Group (UFTG) - a task group of the SPARC/DBSSG

developing a reference model for the user facilities of a data

base management system.

32
virtual user - a software/hardware agent of some human or group

of humans. The range of this user is limited only by

intelligence built into the processes which represent this type

of user.

33
NBS-n4A (REV. 2-80

U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET (See /nstruct/ons)

1. PUBLICATION OR

REPORT NO.

NBSIRS8-3709

2. Performing Organ. Report No, 3. Publication Date

J a nua r y 19 8 8

4. TITLE AND SUBTITLE

Reference Model for DBMS User Facility

5. AUTHOR(S)

Elizabeth N. Fong (Editor)

6. PERFORMING ORGANIZATION (If joint or other than MBS, see instructions)

NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

7. Contract/Grant No.

8. Type of Report & Period Covered

9.

SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street, City. State. ZIP)

10.

SUPPLEMENTARY NOTES

Document describes a computer program; SF-185, FIPS Software Summary, is attached.

11.

ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significant

bibliography or literature survey, mention it here)

In this report we present a reference model for the user facility portion of a database management system. The User Facility Reference Model offers a separation

between the Data Management Tools and the User. The User Data Language and the

Internal User Data Language are candidates for "standardization". Since the Data

Management tool Layer is continually evolving and current technology often embeds

a user interface in each tool, the process of "standardization" must be staged.

The work here indicates that the User Data Language can provide a focus for the

start of this process. This report also provides a theoretical basis from which

a User Data Language could be developed.

12. KEY WORDS (S/x to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolon s) database management system, data language, end-users, reference model, standards,

user facility, user interface.

13. AVAILABILITY

Uni imited

1 1 For Official Distribution. Do Not Release to NTIS

1 1 Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.

20402.

Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

38

15. Price

$11.95

USCOMM-DC 6043-P80

[I

. . * ' 1 : *. • fkj