MDBS V104 System Documentation Aug1980 pdf

MDBS _{Data Management} System Documentation

Version

1.04

Micro Data Base Systems,

Inc.

P. O. Box ₂₄₈

Lafayette,

Indiana

47902 (317) 448-1616

(317) 742-7388

August 1980

Copyright Notice

This

entire

manual

is provided for

the _use of" _{the customer and the}

eustomer"s employees. The

entire

contents

have been

copyrighted

by Micro Data Base Systems,

Inc.,

and

reproduction

_{by any means}

is

prohibited

except _as

permitted

in

a

written

agreement

with

Micro Data

Base Systems,

Inc.

© _{COPYRIGHT 1979, 1980, Micro Data Base Systems,}

MDBS 2!at:

a

Manage: _{ment System Documentation} ?REFACE

Tk

i

'3 rnan"ctai Z·3 cc:ncerTjed wiU"z data base _{management. and} :_it.s

use as a t. ocj !

in

soCtware development. Many

exµerts

_{Rave rn^edicted} t.ha t. _two

innovaiions

wit!

dominate

th

e computing _scene

iri

t.he 1g7;g"s- Th f'

first

innovation

i

s

i

rí

th

e ar' e a o

f

computer hardware w .i t" r2 t. h e

devel"jµrr\e-nt of" _{the micro—computers (computer o n a chip")}

. The seconc!,

a sof't.ware advarice,

is

the _us e _o

f

highly

sophisti.c"ttéñ

_'iía"a b 3-s e

management

techniques

to eont:

"o1 _{complex data}

structures.

_{The :e} t.wo

ínríovatícmc _are com'{'i";nec!

together

in

th

e !v!im^e TJata Ba ""' 1> j7y"7teTt" '

soghisticated

í'at.a Ba: 3e _{?4anagement System.} We _be!

iev

that

íj?á _{.-."g E3sf±}

mar,agernent systems (DBMS) w i t. !7

their'

capability

_o

[

supporting

selective

retrieval

to

"what. i-f"" t:_{yµe inquirü-es and}

their ability

to

suppc·rt

restructuring

as the riat-ure

of

the dernrnds change,

will

become the

focal

software in

uüicro"s _as

they

_are

already in

mini— and :

mixi-"-computers. The uÜcro—coírµuter. w

i th

its

fantastic

computing _power c) yj a-

per—dollar

basis,

combined w

i th

_{a power"í"v-l data base management}

system,

will

be a

formidable tcol

i"o

r

mana¿"ing

enterprises

c f" a } l

types .

Th e _purpose o?

th

i

s _user " s manual

is

twoPold.

First

there is

introduc".or,y material

to

the _area of" _{data base management. Since}

this

i

s such a

vast

and

important

_area we

real ly

cari"

t

do complete

justice

to

this

topic

and

suitable

references are:

1

. Haseman . \n'. D . an d A . B. Whinston,

Introduction

to Da

ta

Management,

Richard

D.

Irwin

.

Inc.

, Homewood. IL , 1977.

2.

Martin,

J. , Comouter Data—Base

Organizat.íori, Prericice

Ha I !

,

Englewood

Cliffs,

NJ, 1975.

MDBS _{Data Management System Documentation}

3.

Holsapple, C.,

Primer _{on Data} Base Management, MDBS

Inc.,

Box

248,

Lafayette,

IN, 1979.

The second goal

of

this

manual

is to give

a

detailed

guided

tour

through

the _use OÍ" MDBS.DDL _and MDBS.DMS. _{Here our aim}

is

to

_{be as}

complete _{and as comprehensive as}

possible.

Finally,

we

request

comments from _our

readers

_as

to

how

successful,

in

their

view, we have been

in achieving

these

goals.

Have _you been

able

to follow

our

description

of

how MDBS.DDL and MDBS.D!A.S should be

used and

actually

have _{you achieved} the expected

results?

Or _have

there

been

points

where the

steps

_were

unclear

_or ambiguous? We

plan

to incorporate

these

suggestions in future

versions to

finally

achieve

a manual

that

is

a

tit

companion

to

what we

feel

is

a remarkable and

truly

innovative

sQt"tware

product in

the micro--computer _area.

© COPYRIGHT

MOBS _{2ata Management System Documentation} TABLE OF CONTENTS

Page

I.

INTRODUCTION... . !5

II.

MDBS.DDL DATA DESCRIPTIObl _LANGUAGE....

....

1'7

A.

Introduction...

i': '

B.

Features.

_.

..

. .

..

. . . 18

C.

Getting Started

_With

MDBS.DDL...

2C

i.

Initial

loading

and

test.

run...

-...

20

2.

Relocating

KIDBS.DDL...

2Z

3.

Important

MDBS.DDL _addresses:

Personalizing

and

patching MDBS.DDL...

23

D. MDBS _Data

Description

Language...

₂₅

1.

Iritroduction

and,

Definitions...

25 2. IJDL

Example...

27

3. Many—to—Many

Example...

33

4.

Multiple

owner/member

example...

40

5. LU)L

Specifications...

44

El. _Notes on Data Bm: e

Files...

7C) E. _Modes

of

Operation...

72

1.

Introduction...

72

2. Text Entry/Commanci

mode...

75

MDBS _{Data Management System Documentation}

3.

Line editing

mode...

95

4. DDL

analyzer

mode...

103

III.

MDBS.DMS DATA MANAGEMENT

SYSTEM...

₁₄₉

A.

Introduction...

149

B. _Features

...

150

C.

Getting Started

_With

MDBS.DMS...

151

1.

Relocating

MDBS.DMS...

151

2.

Personalizing

and

patching MDBS.DMS...

151

D. MDBS _{Data Management}

System...

155

1.

Introduction...

...

155

2.

Calling

procedure...

174

3. Data management system

routines..-...

177

IV. CONCLUDING

REMARKS...

₂₅₈

APPENDIX

1...

262

APPENDIX

2...

264

-© _COPYRIGHT

MDBS _{Data Management System Documentation} DDL COMMANDS

(a) By _{Mnemonic Pa ge}

BAGKSPACE-key Delccte

text.

. . . .

..

.

..

.

..

. . . .

..

. . . 74

BYE _Return

to operating

_{system. .} "7_q

C _Change

a

line

of"

text.

_.e . .

..

. .

..

. . . .

..

97

C _{Repeat changes.}

. . . - . . . 1 C) Ci

Ccmtr<il C

Interrupt

ap

operation.

. . . 74

Control

H _{Backspace and}

delete

a

character.

. . . '74

Control

P _{Toggle outpu!- . . . ,}

. . . 73

Control

X

Interrupt.

_a

line

of"

input.

. .

.. ..

. .

.. .. ..

73

D

Delete

t-ext...

...

...

80

DDL _Data

Definition

_Language

Analyzer.

_{. . . .}

..

82

ÚELETE _{Key B.acksp·ace and}

delete

a

character.

. . . 73

DR _Data

description

format.

for dri'íe.

. . . 83

it

Enter line edit

_{mcAe. - . . . . . . . . . . . . . . . . . . 85}

¿—d

EN _Data

description

format for

_end

line.

_.

..

83

ESCAPE- _{Key Return} t-o

ogerating

_{system. . . . . . . . . . . . . . 79} F_I F'at-a.

description

format

_Í"or

file.

. . . 83

IT Fcítta _descrij"±:

ion format

_for"

item.

_.

..

. . . . 83

L

List

t

e x

t

. . . 86

ME Data

description

format tor

member. . . 83

N _Renumber thc'

text.

. . . 88

OW _Data

description

format

_{f"or owner.}

. . . 83

p

Print

a. _space

ruler.

_{. . . . . .}

...

....

. . . . .

..

9O

PA Data de'umi"iption í'ormat

for

password. , . . 83

R _{Read a}

text

tile...

91

MDBS _{Data Management System Documentation}

RE _Data

description

format for

record...

₈₃

RETURN-Key End _the

current

line

Oí7

input....,...

73 RETURN-Key Move

through

text...

96

S _{Leave the}

editor"

mode...

99

SE _Data

description

format for

set...

83

W

Write

a

text

file...

93

© COPYRIGHT

MDBS _{Data Management System Documentation} DDL COMMANDS

(b) By

Function

Backspace and

delete

a character". .

..

. . . 73

Change a

line

of"

text.

.

..

. . .

..

. .

.. ..

. . .

..

. . . .

..

.

..

. 97

Data

def"inition

language

analyzer.

. . . 82

Data

description

Í7ormat. c'cmman&m

. . . - . . . - . . . . - . . . . 83

Delete

text-. . .

..

. .

..

. .

..

. . . .

.. ..

. .

-.. -..

. . '3 Q

End _the

current

line

'jf

_iní?'Llt.

. . . , . . . - . . 73

^

Enter line edit

mode

. . . - . - . . . 85

Leave t-he

editor

_{mode. . . . q9}

List

text.

. . . 86

Move _through

text.

_{. . . . . . . . ,} . . . - . . . , 96

Print

a _space

ruler.

. . . , . . . , . . . , . . . , . . g a

Read a

text

ri1e..

a V * · * 0 t · O · * D 0 6 6 » 0 b . P b r E 4 P r + · P y · P · V · · t · <4jL~"

Penümber t. "h

e

t

ex

t-. . . - . . . - . . . - . . . 88

Repeat charÁEes- . . . .. . . - . . . .. . . 1 O C)

Restart

a )

ine.

. . . 0 . . . 0 . . . - . > . . 7:"3

Return

to operating

system. . , 79

Write

a

text

file... ...

.... ....

93

MOBS _{Data Management System} Documentation

DDL ERROR MESSAGES

?age

A DEPENDING ON ITEM CANNOT BE A REPEATED _FIELD

.

..

. . .

..

105

A _VARIABLE LENGTH ITEM MUST BE LAST _IN A RECOFD _.

..

. .

..

106

CANNOT WRITE TO _DISK

...

.. .. ..

...

..

.-...

!0'7

CAN'T HAVE OTHER OWNERS WITH SYSTEM

. . . !08

DEPENDING o'\í ITEM MUST BE Éí _{TWO BYTE BINARY VARIABLE}

..

.l_lj9

DEPENDING ON _ITEN lvlUST BE BINARY _{. .}

. . . .

t 1 C)

DEPENDING ON _{ITEM t{oT pREvIc)Ugij.Y DEFINED If.! THLS RI'CCRU} j. ₁₁

DUPLICATE ITEP! NAME IN RECORD

..

. . . .

..

. . . .

..

.

..

. í12

DUPLICATE RECORD NAME

. . . 113

DUPLICATE FET NAME

. . . .

: .

i

4 ERROR _{. . . . .}

. . . .

1

i

5 EXPECTING A _{NUMBER IN A FIELD}

. . . !

1(3

EXPECTING A _{RECORD, ITEM, DR SET LINE}

. . . :

r'

EXPECTING AUTO OR MAN

. . . j1 8

EXPECTING GET OR END ZJNE

... ...

119

FILE HAS NOT BEEN CREATED: PLEASE DC SO _{. . .}

..

. . .

..

. . .

..

!ZG

IMPROPER _DRIVE NUMBER _.

. . . 121

INCORRECT MEMBER ORDER _.

. . . - . . . . 122

INCORRECT OWNER ORDER _{. . - . . . .}

. . . , . . . - . - Z23

INVALID ITEM TYPE

.

..

. .

.. .. ..

.

.. ..

.

.. ..

.

.. ..

. .

..

, . .

..

. 12-l

INVALID SET CHARACTERISTICS

..

. .

....

..

. . . .

..

..

. . .

..

! 25

INVALID SET TYPE

..

...

. ' 2(3

ITEM READ OR 'n'EITE ACCESS LESS THAN RECORD'S

. . . 12'7

KEY UNDECLARED

. . . 128

MOBS _{Kata Management. System Documentation} MAY LENGTH FOR BINARY _\'ARIA!3LE IG 2

. . . 129

MAXIMUN RECORD _SIZE TOO LARGÉ TO _FIT ON PAGE

. . . ',3C

N.LMES CANNÜT START WITH A $ OR BE BLANK

..

.

..

. .

..

. . . .

..

131

NG) _XEMBER AÑD/OR OWNER _LINE FOR A SET

. . . F32

rn: PAGES ALLOCATED Tci A _FILE

. . . E23

¡'.;¿y; _{ENñUgH ROOM} CEil _DEI'/E 1

.

..

. .

..

. . .

..

. . .

..

. . .

..

. .

.. ..

135

NUMBER LARGER THAN ₂₅₅

. . . , . . . . 136

PAGE LENGTH MUST BE _DI\U31!3LE 3Y _{256 .}

..

.

..

. . . .

..

137

PASSWORD _LINE EX7ECTED _{. . .}

. . . 138

PASSWORD ENTRY OR RF:ZORTJ _{LINE EXPECTED}

. . . 139

PREMATURE END OF _{INF'U" . . . .}

. . .

i

"tc)

READ ACCESS GREATER THAN :.\/PITE ACCEF3

. . . i-41

EzccíRD ACCEGG GREATER THAR' GET _{'S . . . .}

- . . . - . . . .

i

42

RECGRD NOT FOUND

. . . 143

REPEATED ITEM TOO LARGE

..

. . . .

.. ..

.

..

. . . .

..

. . . . 144

R/W ACCESS NOT EQUAL FGR DZ7ENDTNG AND CURRENT ITEM

. . . 145

SECOND _LINE OF GET _{DEFINITION INVALID}

..

. .

....

..

.

.. .. .. i46

£OF?T KEY NOT _IN RECORD _{. . . . . . . .}

..

. . . .

..

. . . .

..

. . 147

SYFJTEKJ _{CAb' 'T BE} E _MEMBER.

. . . 148

MDBS _{Data Management- System Documentation}

INDEX OF DML COMMANDS

DML Cornmand _Page

ÁCS Add

Current

OÍ" _run

unit

to

_Set

...,...

179

AMS Add Member

to

_Set

...

180

CCT _Check

Current of

_run

unit

_Type

..¥...

182

CLOSE CLOSE _{the data} b¿)se

...

183

GMT _{Check cLlrrer}t} Member _Type

...

184

COT _Check

current

_{Owner Type}

...

185

CR _{Create Record}

...M.

186

CRS _{Create Record and}

Store

_data

...

1É37

DEFINE DEFINE a data

bloek...

189

DEC

Delete

_{Record based on}

Current of

_run

unit

...

í90

DRM

Delete

_{Record based on}

current

_Member

...

192

DRO

Delete

_{Record based on}

current

_Owner

...

194

DRR

Delete

_{Record based on}

current

_Record

...

196

EXTEND EXTEND _{a data}

block...

198

FFM _Find

First

Member

...,...

200

FFO _Find

First

_Owner

...

201

FINDM _FIND Member

...,....

202

FINDO _{FIND Owner}

...,...,...

2C3

FLM

Find Last

Member

...,...

204

FLO _Find

Last

_Owner

...

205

FMSK

Find

Member _based oí": _{'Sort Yey}

...

206

FNM _{Find Next} Member

...

207

FNO _{Find Next Owner}

...

208

E) COPYRIGHT 1979, 1980.

MDBS _{Data Management. System Docuraentation} FC'FK _Find Owner'" }: .;,.)e't3(i

on

Sort

key _{. . . . . - - . . . . . . . . . . .} :'Z'.: "i":'

FP\' Find

F"evi:

>us M±mber _.

-. . . X . . . , . , : ZIC'

t"'"--; _{I Mind F'"u?v.lo1j3} C:_wne" "7) 1 :

GEtC GET ciaf"a _frorú Curr"e,"ít. of" _{run uniÁ.}

. . "" '"'

GETM GET _data !"""'cm:

'currerzt Member

. . . 2.í: :"

GETO GET _data

fror

current

Üwner" _. ?.;

l

GETR GET _{data from curr"e'nt Record .}

..

. . . .

.. ..

. . . - 215

GFC GET

Field

_from

Current

of" _run

unit.

....

..

....

,..

me

GFM _'-;et

Field

_f"rcm

current

Member" _{. . . . . . .}

. . . Z 17

GFO _Get

Field

_{from current: Owner ,}

. - . . - . , . . . , . . . ;"' ! S

GFR _Get

Field

t"rnm

current

_{Record . . . . . . . . . . . . . . .} :"' " _g

GMC _Get Member _{Count . . .} '"2C\

GCg _{g e}

t

'7)wn

e

r

"íounf . P 22

i

GTC _Get

record-Type

oÍ"

Current

of" _run

unit

_{. .}

..

. . .

..

:222

GThC _Get

record-Type

of"

current

_{Member . . . . . . . . . . . . 223} GTO _{Get recorcí-T,ype}

of current

_{Owner . . . . . . . . . . . . . . . Z24}

X

OPEN OPEN _{data base}

. . . :'">5

PUTC PUT _data

into Current of

_run

unit

_.

..

. . . .

..

. . . 227

PUTK! FUT _data

irAo current

Member

. . . - . . . 22t?

T"_{UTO PUT data :nt:o current. Owner}

. . . 23C)

FUTR PUT _data

into

_{current. Record . . . . . . . . . . . . . . . . . . .} ¿'32 RMS Remove

current

Member _{from Set}

. . . - . . . 233

RSM Remove

all

Set k4embers

. . . , . . . 234

SCM _Set

Current

_{of run}

unit

based on Member . . . 235

seo Set Current.

of

run

unit

based on Owner . . . 236

SCR _Set

Current

of

r'jn unit

based on Record . . . 23'7

MDBS _{Data Management System Documentation} SFC _Set

Field

in Current

OÍ" _run

unit

..

. . . .

..

. . 238

SFM _Set

Field

in current

_{Member .}

..

. . . 239

SFO _Set

Field

in

_{cur-rent Owner}

.. ..

.

...

.... ....

241

SFR _Set

Field

in current.

_{Record . . . .}

..

.

..

. .

.. ..

.

.. -.

242

SMC _Set Member _{based on}

Current

oí^ _run

unit

_{. . . . . . . . 243} SMM _Set

current

Member _{based on}

current

_{Member . . . . . Z44} SMO _Set

current

Member _{based on}

current

_{Owner . . . . . . 245} SMR _Set

current

Member _{based on}

current

_{Record . . . . .} Z4S SOC _{Set Owner based on}

Current of

_run

unit

. . . 247

SOM _Set

current

_{Owner based on}

current

Member

. . . 248

SQQ _Set

current

_{Owner tmsed on}

current

_Owner

. . . 250

SOR _Set

current

_{Owner based on}

current

_Record

. . . 252

SRC _{Set Record based on}

Current

of" _run

unit

. . . 253

SRM _Set

current

_{Record based on} Member

. . . - . . . 254

SRO _Set

current

_{Record bz'sed on Owner .}

. . . 25'q

STAT

return

_run

S'TATistics.

.

.. .. .. ..

. . .

..

.

..

. . . . .

..

. . 256

TOGGLE TOGGLE _run

optimization

switch.

. . . .

..

. . . ., . 257

(9 COPYRIGHT 1'379,

MOBS _{Data Management System Documentation}

NEW RELEASES, VERSIONS, AND A WARNING

Any programming endeavor of" _{the magnitude} cjf' _the MDBS _system.s

i

_s

bound

t

c)

continue

t

o evolve _over

time.

Realizing

this,

Micrr'

Data

Base Systems _vows

to provide it.s users with

updates

to

t.heir

version

f" co

r

a nomina!

handling fee.

Updat.es _{can be pr(?vided}

only

z-f'ter the'

signed End _{[Jeer Agreement Form}

is

_on

t'i le with

MIJB3, _{In c .} New

versions

of" MDBS

sort\/are

_wi I ! _{b e considt=r:} :zd

as sermraZe

products.

However , owners

of previous

versi.ons

will

I)?

entitled

to

a

preferential

rate str'-iU.ure

(as sc.on _{as the} signed End User A.gr"."emer,t

Form

is received

by MDBS, _{In c .} )

.

Finally,

each _'33py fjf^ MOBS

products

is perso:

nalized with

the

licensee's

name. There are

several

levels

o

r

th

i

s

j;ersonal i zat.ion,

some o

r

which

involve

encryption

methods gum^ariteed t.

c b e

combinatorally

hard _{cc ciecyphe:} '". 1vU)BS

products

were produced w

i

Eh Za

sizable

investment

of"

capital

_and

labor to

_say

nothi:

"ig of" _{the year'¶:} O!"

prior

involvement

in

the data base management _area. b y

prin3iµalt>

ot" MOBS _.

Accordingly,

we _are

seriously

concerr,ed about. _any uríauthcrized-copying of" _our

products

_and

will

_{take an y} anc". _a i _l :_2vai!?.b|e

lega!

action against i.llegal

copying _or

distribution

_{of' our}

products.

MDBS _{Data líanagement System} Documentation

I.

íNTEIODUCTION

The Micro Data Base Systems (MD!3S) _{has components}

for defining

_data

structures

and f'or the

storage

and

retrieval

of data.

Add—on _packages

available

for

N!DBS _{a! low the}

kgging

_oí

transacticns

Icu"

recovery,

th

e

restructuring

of

a data base, and query

handlirig.

MDBS

is

not a mere í'

i

I

e management system. Th e ideas used

in designing

MOBS take the CCJDASYL _{Data Base Task Grcmp Report}

{Apri

l 71 ) _{as a sEart.ing}

point.

However" _, 2'!DBG _{p1"cu/ ides man y}

mdditional

da

la

struct.uring

_{and data}

mar)ip'Á!atioI1 f'eA:

ures that

_are not-

available

in

strictly

CODASYL _data

t.ase systems. MDBS

is

_implemented

entirely

in

_{machine language.} Fo

r

each

appAication

system a

logical

structure

oí" the data base

must

initially

be

defined;

that.

is,

a f"orrnal

definition

i

s made

i

n

which

th

e

relationships

hetu'een

th

e data e1er,ients

is presented.

Ríitial!y

a _user may

list

the

various

data items

(field

names)

that

'ñ 'i l I be

involved in

_a

particular

apptication.

The process c>f"

def"ining

a

logical

data

structure

consists

of"

grouping

data items

into

record

types ( o

r

,

in conventional

data Kjrocessing

terminology,

into

logical

files)

and

indicating

appropriate

relationships

between

record

types.

These

Te|ationship3

_are

only

conceptual and do _not

imply

_any

physical

storage allocation.

Nowhere ir. t:_{he use of' the data} managernerít. _system

does a _user

refer

to

an

actual

data

storage location,

but

rather,

h e

refers

t

o th e conceptual

structure

_as

initially

defined.

Th

i

_s

defining

o

r

th e .data

structure

is

done

via

the DDL _(Data

ljef"init

_ior':

Language) and µr'ocessed by the _program narííed MDBS. DDL.

e: _{COPYRIGHT 1979, 1980, Micro}

MDBS _{Data Management System Documentation}

Alter

the

structure

has been

defined

the

application

_programs t·:

i

I _l ,

o f'

course,

need

to

_access dM:a from _or

place

new data

luto

the ("íat.7.

base. An

application

_program cÍOé3

not,

_however

, r"u3 zí ( or" "ii!" i t-a

:' t._hC'

desired

data

directly

f"

r

om ( o

r

t

o )

t

'ne dat 3 bas e . l?1ste¿"('j. i t".

requests

the data management

routines

(MOW. D!d3)

t

_{o p¿!rforY. t.h e}

necessary

operations.

This

requires

the

writer

o!" _the

applicatio»

programs

to

know

only

the conceptual

structure

of" _{the data base; th e}

"

OMS

i

_s

responsible

f^_o

r

maintaining

th

e ph.ysi cal

structür'e.

Th e

requests to

the DMZ _are made

via subroutine

c¿: .l l s wh

i

ch _{ma k e u;"} ¿-i

collection

o!7 commands cc'mpz"isir.g t.h e DML

Pata

M3r:

iµu!at.iori

Language) .

The

basic

MDB3 _package

consists

of" MDBG.DDL _and ?.¢!3!32

. CJMC . Ther·e

ar" e other",

very

useUi! , add—ons

to

M!JB3-

C'ccasior;a!ly,

it.

tiay become

necessary

to

alter

the

logical

struc-t'-ire

OÍ _ari

existing

dzz _{t. a bas}

e ,

The MDBS.DRE _system

is

_{designeá U)}

permit

_chemges

to

bE: _{made tcj 3 i.ata}

base

structure

without

the need Cc) _dump

an d i'e-]c¿íci zhe da

t

3 base .

Another add—on

is

!V1DBS. _{RTL which logs}

a

l!

transactions

made cr. j, ci-atní

base

since

the

last

data base backuµ. In the event

of

a syster,: crash ( e . g . , power

loss)

t

h e data base car. be

restored

autotüat-ica!

iy

by

invoking

a

recovery

utility.

A

third

add-on

is

MDBS.QRS whích accepts

English—like,

rlonprocedur(3 I

queries

and produccs

desired

r"eµort.s. This

cuts

programming

effort

substantial

ly.

Fu l i

detai

_{Is about} dt-he3e

?

add-ons may be found

in

the MDBS.DRS. MDBS.RTL, and MIJBZ.QRG User s

Manuals.

MDBS _Data Managemen'c _{System Documentation}

I I .

?v!D!3S

..DDL

A

,

Int-roduction

Ir,

this

section,

we concF"r)trat.e _or

ldicro

Data Ease Svs'um 's_%' "Da i".a

Description

Ana

.iyzer/'Editor

_{which we cal} l MDBS.DDL

(for

_M,icro .3.ata

Base System 's 3ata Descr"ipt.ion LanÉ"uage) .

In

Part

B _we

list

severa! features

o

r

MDBS. BOL which

zr

e

t

."ien

described in

more det.ai- !

i

n

later

sect:

íons.

Iii

Sect.i.: m t": t.l?.e _user"

i

s

]nstruc-ted

3ñ h ("w t-o " b

r

i

n_g—up " MDBS

. !JDL ; tb e i:

ind

o!'

modif"icaticn"

Jhat _{can ba} made

to t'ais

_are

alsa

_{descr Jbed.}

T c develop a data base

proper,

data base management _{c7ríc€pcs "ire}

necessary.

Ii' Section

I-J, we

discuss

such concepts and present. the

data

description

language (DDL)

for

describing

a data base

structure.

The user may

also

want

to

look ahead

to Section

i

II

. !J

to

see how such conceK)t.s _are used.

To

create

_{a data base, the user must}

first

describe

the

structure

Qr _{the data}

using

_{the data}

description

_!anE"uage (as

discussed

i

r,

Section

IJ ) _{and then}

pnysical ly

initial

ize

the data base

with

the

proper tables.

This is

a) ]. óone by the DDL

ana],yzer,/eaitor

which

is discussed in Section

E. The _anal

yzer/editcr

permití:

t-ne

in?ut

,

editing

and z-tza!ysis of" _{a data}

description.

© _{COPYRIGHT '1979, 1980, iQicro Data Base Systems,} T

,;

MOBS _{Data Management System Documentation} B

. Features

MDEIS.DDL

allows

_{the user}

to describe

_{a data bas e}

structure

anc!

initialize

a data ba s e. A data base

structure

is dcfined using

the data

description

language (DDL) . Suc h a

description

i

s

entered

into

the computer

(either

i

n lower _{or upper"} case)

via

the

Text Entry/Command mode _of MDBS.DDL.

This

mode

supports:

1. _Text

entry

2 _-

Listing

3.

Deleting

4. Saving

5 _{. Ret.r"ieving} 6 _{. Renumbering}

as

well

as

providing

formats

and

other text

entry aids.

Once

entered,

the t.ext _{can be}

edited

using

th

e l ine

editor

o

r

MDBS _. DDL.

Finally,

th

_e DDL

analyzer

_{processes a} da

ta

_{bas e}

description

and,

if

no

errors

_are

detected,

initializes

a data

base. If"

a

syntactical

o

r logical

error

i"

detected,

_an

error

message

is displayed

and the user can

quickly

correct

the problem

using

the

text

entry

_or

edit

features.

MDBS

supports

_the

fol

_lowing

features

for

_{data base design work:}

i

.

Variable

and Í"ixed

length records.

2.

Character,

integer,

floating

point

(real),

logical,

internal

decimal,

externa!

decimal , and

binary

record

fields

(data items).

i4}L);2S _{Data i\áanagerne.nt System 'Doeumentat}

i

_on .-2

, {jr-"--tc_íme, cm e—to—many , many_:ío—one , and many_to—

':'!2¿Fny s:€:t-

types.

E _Sc :_'Led

, '-IFO . FIFO , ne x

t

,

prior.

and

immaterial

s e t: -:_jrderZn,gs.

5

. Automatic or manual

record insertion

into sets.

t":

. Read and

write

access

protection

via

passwords

at

" · 7 7

z-he

item, recora

_aria

set levels

o e

organizat-ion.

m

O Record t.yp es may own

other

occurrences o'? the same

'"'ecord- type (

i

. e . ,

recursive

set".)

.

e e T

8 _. M""'ny _reccmd t:_ypes

can

Dart1cipat.e ín

a an í'éñ

set.

g _, Fu-; l _{network data}

structures.

These i'eatu.res _are discussed

in Section

!1.

A _{data base can} be

physical ly

_{spread over} a number of"

drives

'"8

maximum) an d the

drives

_can be

floppy

(mini—or

ful!— sized)

_or

hard

disks.

The data base

is organized using

a paging system. A

single

drive

can

logically

contain

3191 pages an d a _page

i

s

logiealiy

restricted

to, at

most, 65536

bytes.

Thus

large

data bases _can be

supported

{subject

to

opermting system

constraints

on the

size

of' a

fi

le).

Gnc:_{e a data- tú'íse descr i.pZion has been}

entered

_{an d a data bas e}

initialized,

t

Fi

e _user ear, ezzsi 'l,_{y access} the data base through a

host lar)guz: gc ( ¿;uch _{as BASIC) us} i-rig MDBS. DMS. _In

Section

_{I I I we}

take _{up the}

discussion

of" í\'!DF3:

;.

DMS.

© CCTYRIGPÁ

MOBS _{Data Management System Documentation} C.

Getting Started with

MDBS.DDL

1.

initial

Loading and Test Run

The

details

specific

to

_your system

for

making _an

initial

t.est

of

the MDBS.DDL _{package are}

outlined

in

_the MDBS _system

specific

_manual

which

is

supplied

when _{'Iou purchase the system.}

!2rief"\y.

_you

will

execute _program DDL _{(see the manual} MDBS _system

specific

_manual f"'or

its

f"ul!y qualifi-ed

name) which

will

display:

MDBS.DDL VER X.X

(C) COPYRIGHT _{1979, 1980, \'Jicro Data Base Systems,}

Incorporated

Reg # XXXXX

Your name and

address

At

this

point

you can read a sample data base

deseriptiorj

stored

in

file

INVNTRY

(again

_{see the system}

specific

manual

for

the

fully

qualified

name). The procedure

is

shown below

(underlined

text

is

generated by the MDBS.DDL system):

1

This

example was used by M. Gagíe, G.

Koehíer,

and A.B. Whi"nston

in

their article

"Data—Bame Systems And Micro—Computers: An

Overview",

published in

BYTE _magazine.

MDBS _{Data Management System Documentation}

R "Read _a

Fi le"

command

FILENA}j'"i computer prompt

INVNTRY

fully qualified

f"ile

name

for

INVNTRY

To

list

this

sample

description

type

"L".

To

actually

initialize

_a

smal l _{data basc·}

with

this

description

_type DDL.

This

will

result

in

the prompt:

DATA-BASE FILENAME?

to

which _you should respond

with

a

fully

qualified

file

name which

exists

on

th

e

first

drive of

_your system (use a temporary

file

for

this

purpome). The data

description

will

then be

displayed

(without

line

numbers) and a data base

initialized.

The complete _sequence looks

like

DZ)L

"Enter

DDL

Analyzer"

command

DATA-BASF _{FILENAME? computer prompt}

name

fully qualified f'ile

_rame

(DDL _{out,gut) computer generated}

output

DDL PROCESSING CCJMPLETED

I r _you have not had. _{a euecessf"ul run}

, re—read

this

s gctic-F) and the

system

specif'ic

manual and

try

again.

I

r

y ou

still

have n o : _uck ,

please cal } _Micro

Data Rase Systems, In c . Í"or

help.

© _{COFWRIGHT 1979,}

MDBS _{Data Management System Documentation}

2.

Relocating

MW3S.DDL

Under some opera-ting systems,

it

may be

desiraiAe

to locate

MDBS.DDL

at

_a

position

other

_than

that supplied

_by

Micro

!J)aÜ _Ease

Systems. For

thi.s

_purpose, we have

provided

a

relocatable

f"o""rr. oí' the

—

data

description

analyzer

and a

relocator

_{so that. an}

executable

form

of the

analyzer

_{can be} ORGed

to

_any

place in

_{memory. Please}

refer

to

the system

specific

manual

for further

information.

MDBS _{Data Managem'"nt System} Documentation

3.

Important

Addresses:

Personalizing

and

Patching

MDBS.DDL

MDBS.DDL

consists

of

a _program

region

and work _area

region.

These

are

contiguous

ancí the work _area

immediately follows

the program area.

The

size of

the 'm:_{mk area can} be

increased

_{or decreased} through a

patch

to

the _sys em.

There _are

several

addresses

that

the _user

should

be aware or

in

MDBS.DDL. _{The user may}

alter

_{these as shown}

in

_{the system}

specific

manual. A

brief

description

of" _{each item}

follows.

(a)

Initial

Entr;,'

Point

Upon

entry

at

this

point,

all

_program

variables

and

regions

are

either

physically

or

logically

re—initialized.

Registers

are not saved but the

entering

stack is preserved.

H:

j

I/O Entry Points

Dif"f"erent

operating

systems handle

input

and

output to terminals,

printers

and

disks in

a

variety

of

_ways. To keep

this

manual

free

of

system

specií"ics

the

I/O inf"ormation relevant for

_your sYstem

is published in

the system

specific

manual. Patches

to

non—standard.

I/O

routines

should be made

in

_accordance

with

_the

instruction"i

of

the system

specific

manual.

..

(C) Echo Toggle

(Default

00 _hex)

This byte

is: checked

to

_see if" the _user wants

to

have MDBS.DDL

echo

input

to

the

output

device.

It

the

byte

value

is

_zer~í,

echoing

will

take place-

If

it

is

the value _one, no echoing

will

be performed..

G _{COPYRIGHT 1979, 1980, Mie:-o}

MDBS _{Data Management System Documentation}

(d) Last Word

of

Memory (Def"ault OBFFF _hex)

Th e address

stored

here

gives

the

last aval lable

word cjf memory

that

the MDBS.DDL _{program may use. Note}

that

MDBS. _{ijDL uses a l} !

-V,

memory

starting

f'

r

om

i

ts

load address _up

to

t.he value

in this

field.

Needless

to

_say, the _{user" should} make _sure

that

lhe

!

a s

t

--word

of

_memory

is physical ly

beyond

the

end of the _program. (e) Screen

Control

Byte

(Default

OB hex)

This

byte

should have _one of" _the

following

values:

Screen Width Byte Value

less than _or equal

to

64 1 1 _{(OB hex)}

characters

greater

than _or equal tCj 80 15 (OF _hex)

characters

64

to

80

characters

_per

greatest

irzteger less

line

(ca:

l

it

N) _{than cu" equal}

t-o :

N/5 _-1

(t)

Re-entry Point

I f

th

e _user wishes

t

o re—enter MDBS.DDL. whi le ;:'resen"ving

al

].

program

varimbles

and

regions,

then he must

issue

a jump

to

th

j. s address.

In

the next.

section

we

discuss

the data

descript.ion

language. Th e

data

description

langut-tge and í"eatures or a data bas e

design

ar

e

illustrated

with

examples.

MDBS _{Data Management System Documentation}

D

. DDL (Data

Definition

Language) 1

.

Introduction

3ñcÍ

Definitions

The DDL _{i s used}

t

_o

formally

describe

_{a conceptual}

(or logical)

structure

of

a data base. These

descriptions

_are

i

n terms o

t

data

i

terns ,

record types,

and

sets.

A DATA-ITEM

is

_the

smallest unit

of

_named

data.

An ITEM—OCCURRENCE

is

a

representation

of

a value OÍ" a

data--item.

( Eg . AGE

i

3 a data—

item,

and an a ge or 21 might be an occurrence of" AGE) A

"repeating

,

. - . I

item" acts

as a o?\é?—dimensional

array

whose maximum

rep! i-cation factor

must b e

specii"i

-i; a "depending on" item may

optionally

be

specified

.~~N%~~~Nu

-

'f · .' . · ae

··

'

-

u we

which

indicates

the current. "

len&th"

.,.QjL==La_rray. "

A RECORD—TYPE

is

_a named

collection

of"

zero,

on e , o

r

more data—

items.

A RECORD-OCCURRENCE

is

_{a sampling}

of values

of" _the

data-items

\

def"ined

to

be

contained

_{by the record—type. There may be an} :

":rbitrary

number

of occurrences in

the data base OÍ" _{each record—type}

sp'ecified.

No _{two record—types may have the same name. The data—item}

names mus

t

b e unique

only within

the

record-type.

(The same data—item name may be _used

in

_{more tlían one}

record type.

) _The

order,

type

, an d

size

of"

t

h e items

within

a

record

type _are

defined in

the

record description.

Consider the f"ol lowing example

ot

a

record description:

RECORD EMPLOYEE

ITEM NUMBER INT 8

ITEM 7AME CHAR ₂₀

ITEM !/1AGE _{REAL 8}

ITEM "i'AX REAL 8

© _{COPYRIGHT 1979, 1980, Micro Data}

MDBS _{Data Management System Documentation}

The above example

defines

a record—type EMPLOYEE

containing

r

_our

data-items:

NUMBER _{(employee number)}

, NAME, WAGE (wages) and TAX

(taxes

withheld).

The "

types "

or

th

e data—items 3

r

e

integer,

""Y

character,

rea l , and

rea!,

respectively,

and NAME

is specified

to

be a

maximum óf7 ₂₀

characters

in ler.gth.

An

occurrence of

this

record—type

might be ₍₁₅₂₀

, A

B SMITH, 7520

. 20 , 158. 42) . There would be an

occurrence

tor

each employee

in

the company.

"Record—type"

i

s used

i

n

def"ining

a

structure

, and

"record-occurrence"

i

s used

to reler

to

the

actual

data

values.

A _group of"

data values may make _up a

record occurrence,

and

they

_are sUmed

using

th

e name

of

the record—type and the _names

of

the data—iten'.u.

If

the names

of al

l ernployees are

desired (using

the

definition

az"

i

_n

th

_e

above example) , the

application

program would

request

of" th·:± DMS a! !

--occurrences

of

t-he record—type EMPLOYEE and

[

o

r

each on e

i

t

would

request

the _occurrence

(the value)

of" _the

data-item

NAF-IE.

A _SET

i

s a named

relationship

between record—types. One _{or more}

record—types _are dec

lared

_{as the} "owners" _{and one or more record—types} ar e

declared

a s

th

e "members"

of

the set.. Any record—type may be

declared

as the owner record—type

of

one or more

sets;

liktt'".'ise

ro

r

member _{record—types.} A

set

_occurrence may have _an

arbiti"ary

r,umber

of

occurrences

of

each

of

the record—types. The

"set order" (the logical

order of

the memEer

record occurrences)

_{must be}

declared.

Th e

set is

t.r'"

basic struct.ural

unit

of" _{tlú" data base. I} t"

is

used

t

o

define

th

e

relationship

between

different.

recorA—2:.y;:'es. In

particular,

the

set links

ezch _owner

record

_occurrence

to

it-3

related

© _{COPYRIGHT 1979, 1980, Micro Data Base Systems,}

MDBS _{Data Management System Documentation}

member

record occurrences.

This is best explained

through

examples. 2 _. DDL _Example

A

simple

_{but c"ommon business problem}

is

_{the need}

to maintain

lists

of" _{people or}

orgcmizations

sorted in

diíferent

orders.

_Consider

th

_e

case o í' a _company which

maintains

lists

of" customers sort: od by name,

address, and zi-p code. The !4DB2 _{s,y3tern handles}

this

_problem

using

_the

dat.a

structure

of'

7i

_gure

II.D.

1. _The

actual options avaiÁuble

_{f'or the}

data

definition

" '"'_e

detai

led

i

_n

th

_e

remaining

portions

_or

thi

_s

section.

Note

t"mt only

_one

record

type (CUSTOMER) _{has been}

defined,

while three sets

Oames, NUMBERS _{and ZIP) are shown. The}

record

_type

SYSTEM, _{used as owner}

in

_these

sets,

is

_a

special

_{recorc'. predM"ined by} KÍDBS.DDL _which

permits

_access

to

_data

in

_{the data base. There}

is only

on e

instance

of" t.he SYSTEM record—type

in

the data base and

there is

no data associate.-i

with

t.h

i

s record—type. Th e SYSTEM

record

i

s

discussed later

in this

section.

The CUSTOMER recc)[""d

t

_ype

contains

_{a l} ! _{the data}

re!aLing

to

a

customer. Data—item NUMBER

contains

_{the customer} number" _,

i

_tem NAME

tb

e customer name , e

t

c . A l I of" the data—items

store g}]aracter data,

as

indicated

by the CHAR

specification.

_{Th e}

i

_tern

size

foilows

_the

word CHAR.

Th e _use OT '¶:_'2ree

sets is

the key

to maintaining

the customer

file

in three

differe

orders.

Th e MDBS. DMS _{system wi} I _l

automatically

insert

a

record

i

n the _proper"

location

in

each

of

these

three sets

when _the

record is created.

_Note

that this

i

s a

logical

construct

on l y —-- _a

record is only physical ly present in

one

place.

By use of"

e COPYRIGHT _{1979, 1980, Micro Data Base Systems,}

MDBS _{Data Management} SysA: em _{Documentation}

approprÑate DML _{conmands, a given}

record

can be accessed

eU"ícíent.iy,

o

r

, t: y use o

r

other

DML commands, a

sorted list.

oí' '"'ecords _can be

accessed. Examples

of

such _{programs are}

ii

iustrated

in Section

III.D.

A I _i

three

sets

i

n

Figure

II.D.

1 _are SORTED. The

"sort.

key"

is

stated for

each

set

(NAME

for set

NAMES

,

et

c . ) an d

i

s

t!i

e

field-defined

f"

o

r

t

h e

set to

be

sorted

_upon. Each customer recc.rd _occurs

only

once

in

the data base,

yet three logical

set orders exist..

There _are

six allowable set

orders.

Besides SORTED _{, t'aere ar e}

also:

FIFO —

re\.ord

_{occurrences are} added

to

the end oí" thc. set. such

tmt

each new rec- :,rd _occurrence beccnnes

logically

the ] _as

t

member o f' t:_he

set;

_LIFO —

record

_{occurrences are} added

to

the

f'ront

_c ¿" the

set

such t.hat each new

record

oc.:

nírrence

becomes

logically

"L_'je

first

member of" _the

set;

NEXT — a rú=w

record

_occurrence

is

ioi;ically

placed

in

the

set

after

the

"current"

member

record oí

_the

set ("current"

i

_s

defined

i

n

th

e DML

discussion)

; PRIOR — a new

record occurrence is

logically

placed in

the

set beíore

the

"current."

Inem:_,'jer

record

_of'

th

_e

set;

an d IMMAT — the user does not care about the set"

orúr.

Note

that

the IMMAT

set ordering al

_{lows the} MDBS _sy'U.em

to

_!^ea 1_i-ze

certain

ef"ficieneies

and shouk2 be _used

if

possible.

In

th

e s e

t

description

of Figure II.D.1

the

specification

"AUTO"

appears.

This indicates

that. as occurrences of"

record

tyoe CU3TOI','!EF are

created,

the

records

will

automatical ly

be

inserted

in set

ONORDER by the MDBS _{system. The word} "MAN"

(for

manual)

could also

;'"ñiíve _been

specified.

These

options

ar e discussed fur-b-her

in 3+ctio

i

I!.IJ.5.

Also,

the

specification

"1: N"

states that

the

relationship

between the

MDBS _{Data Management System} Documentation

owner

of

the seb and

its

members

is

a one—to—many

relationship.

For each _owner occurrence

there

may be many member"

occurrences,

but

not

vise

versa.

Most data base systems

support

only

this

type

of

relationship

—— _a many—to—many (N: M)

relationship

supported

by the

MDBS _system

is described in

_the

next section.

0

Developing

the DDL

for

_{a data base}

to

_{be used}

in

_the MOBS _system

does

not require

_any knowledge

of

t-he DML (Data Management Language). The user needs

only to define

the data base

structure;

the system

will

take _care

of

data

storage

and

retrieval

for

application

programs.

However, much

insight

will

be _gained

ir

the sect.ion

describing

the IJML

is

read

(Section

III.D).

By _{seeing what} commands _are

available,

it

will

be

easier to

understand how

to

_{design the data base and}

establish

set relationships.

Also,

the

additional

examples

will

be

extremely

helpful.

Our example of7

Figure

II.D.1

_{can be extended}

to include

_more

inf"ormation.

Suppose

that

we wish

to

keep a

record of orders

that

a

customer has

placed.

Conceptually,

each customer may have

several (or

one or even

zero) orders that

have been

placed.

Each

order

though

is

associated

with

just

one customer. Thus we have what

is called

a

"one—to—many"

structure

(one customer

to

many

orders),

which

is

a

natural

structure

for

a data base

set relationship.

In

order to

extend the example

of Figure

II.D.1,

we

derine

a second

record

type

which

represents

a customer

order

(see

Figure

II.D.2).

or

_course,

to

actually

define

the complete DDL

for

this

example, we would add the new

record descri.ption

after

the

description

tor

the CUSTOMER

record.

© COPYRIGHT 1979,

MOBS _{Data Management System Documentation}

Note

that in record

type ORDER _{we have def"ined}

five

da t-.

a

items:

NUMBER

(for

order

numb'zms)

, DATE

(order date)

, PART

(the stock

rüsmber

of

the

part ordered)

, QUANTITY

(the quantity

ordered)

anti I"R'CE ( t.h e

invoice

price).

Three o

f

t

h e data items

hold

chareíetar é-iata, but.

QUANTITY _{and PRICE have data t','pes BIN}

(Binary)

_and REAL

respectively.

QUANTITY

i

_s

stored

_{as a}

binary

_{data itern} t.c) r?duc-í-

storage

requirement.s.

This is

reasonab!e

since

QUANTI TY

will

_{n e v e}

r

exceed

É35535

i

_n

this

application.

_{Th e}

binary

_{dat-a type}

is

usec2

to

_stcr·m

integral

values in binary

format.

instead

of" _{the packed decimal format.} c ommon

t

o mari y BASICs. The

digit.

"2" aí't.er" BIP'

indicate

-

that

two

bytes

should be _a!

located

_{t: o}

store

t

_{h e}

binary

_{va i l) e.} Th e REAL

specification

for

PRICE

is

_a

real

_{number whose data ler,gt-.h}

i'

8

bytes.

LOG

(Logical)

_{and INT}

(Integer)

_data

types

_are

also supported.

The

set

ONORDER

links

_each _customer

t

_o h

i

_s

orders.

_{Th e s e t.}

ordering

i

s FIFO , s o tha,

t

,

[

or" each customer, the

orders

will

be

maintained in

a

first—in,

first—out

basis,

which

will

normally

be

th

e

sequence

i

n whi.": h the

orders

_were

received.

The new set-

dE'3cription

would be _added

to

_the DDL

after all

_the

record descripti

_")ñ3 72Lre

gi'ieri.

MDBS _{Data Management System} Documentation

RECORD CUSTOMER _Customer

record

ITEM NUMBER CHAR 8 _{Customer number}

ITEM NAME CHAR 20 _{Customer name}

ITEM ADORERS CHAR 20

Street

_address

ITEM CITY CHAR ZD

City

ITEM _ZIP-CVJE CHAR 5

Zip

_code

SET NAMES AUTO

Í:

_{N Sorted by} Name

SORTED NAME OWNER SYSTEI'4

MEMBER CUSTC'"."ER

SET NUMBERS AUTO _{1:N Sortcu"! by Number}

SORTED NUMBER OWNER SYSTEid

MEMBER CUSTQÉIER

SET _ZIP AUTO _1:N

Sorted

_by

Zip

_code

SGRTED ZIP-CODE OWNER SYSTEM

MEMBER CUSTCMER END

FIGURE

II.D.1

DDL

Declarations

for Multiply

Sorted

_Records

MDBS _{Data Management System Documentation}

RECORD ORDER _Custemer

orders

ITEM NUMBER CHAR 6 _{Order number}

ITEM DATE CHAR 8 _Date

received

ITEM PART CHAR 6

Part

number-ITEM QUANT'TY _BIN 2

Quantity

_ordered

ITEM PRICE REAL 8

Unit

_cost

SET ONORDER MAN _I : N

Link

customers

FIFO

to orderc

OWNER CUSTOIW"R K!ENB"R ORDER

END

FIGURE

II.D.2

DDL

Declarations

for

_{Cu3toIner Orders}

MOBS _{Data Management System} Documentation 3 _. Many—to—Many _{Examp) e}

. t? t?

Standard (COñÁSYL) data base systems

require

a one—to—many

relatiQric.hip

between

th

e _{owner' and the} members

of

a

set üccurrence.

Thi"

restricticn

may fújrce the _use of"

unnatural

data

structures

. wh

i

c::"\

complicates

DIVÍL

programs

unnecessari ly,

making the program

harder to

conceptualize

anf7

to maintain.

_These

unnatural

structures

r

e a I_so

quite

ineff"icien"'"

i

n terms o

r

both

storage

and

processing.

As _an

example, imagine _.. computerized

bibliography

system

in

which we have book

titles

that

may be

classified

by a number oí" l'.ey\t.".jrds. We wish

to

be

able to obtain:

I)

A

sorted

list

of" _books

corresponding

t.

o a

given

keyword, a: "id

, 2 ) A

sorted

list

of

keywords corr"c: ¿sponding t.o a

given book. Sinc"" each keyword

describes

many books, _and

since

on e

book _{c an have severa'} I _keywords,

a many—to—many

relat.ion: íhip exists

between keywords nnd books.

If

we _are

restricted

to standard

"one—to—many"

sets,

w _e woul d b e

forced

t

o

introd'iíce

artificial

"link

records"

wh

i

eh _are used f.o

simulate

many—to—many

sets in conventional

_{database systemm These}

link

records

force

us

to

adopt a

highly

unnatural

,

rest.ric'ted

dateg

structure

which, Nríce the

link

records contain

_no data , has

little

conceptual

va !ue . A DDL (Data

Description

Language)

descriptiori

of'

such a

structure

is

shown

in Figure II.D.3.

The

set relations

involved

_are a l i one—to—many

relationships

however, we mus

t

create

_{an occurrence} of" _{reccu"d type LINK}

for

_each

book—keyword

pair' in

_our database. In a _more complex example (such _as when

authors

_a:" ·--'

introduced),

the

actual

data

relati'.mships

_present.

MOBS _{Data Management System Documentation}

quicjcly

become

unclear.

An

additional

_problem

with

this

structure

i

s

that

i

t

i

s

quite

dif1"icult

to maintain

a

sorted order

between the books and keywords.

Also,

t

h e u s e o

r

l

ink

records

results

i

n a

wastage

of

data base

storage

_space.

.

Th e MOBS _{Data Management System}

permits

explicit

use

of

many-·to—

many

sets.

A

special

internal

structure

is

_{used which}

a!lowí:

_the li'!I)BS f

system

t

o

automc'tically

maintain

the data base

pointers

_necessary

to

represent

such

sets.

Th

i

_{s means}

that

situations

_{such a s}

th

_e

bibliography

exai'üp} e c_an b e

conveniently

handled b y

th

·2 schema

declaration

of Figure II.D.4.

In the

declaration

for

set. S3, the

specification

of

a second s e

t

ordering

indicatc-s

that

t

h e

set is

a many—to--many

set

anc"

that

the

owner

records

are

to

be

maintained in sorted

order.

The

f'irst

set

ordering

speeif"ication

indicates

that

the members of" _the

set

_are

also

to

be

maintained in

a

sorted order.

Note

that

this

feature al

lows _one

to

either

rim all

keywords

for

a

given

book _or t.o

list-

all

b