CA1325066C - Method of integrating software application programs using an attributive data model database - Google Patents

Abstract

ABSTRACT OF THE DISCLOSURE

A common data structure for access by several application programs is created from a single primitive data element or attribute data object. The attribute data objects can be extracted from node data and node data descriptors in the application programs' databases. The attribute data objects are arranged in an attribute file in accordance with certain rules which impose a hierarchical organization upon the attribute data objects. Nonhierarchical relationships may also be used to represent the node data descriptors. The simplicity of the attribute data objects and their lack of limitations make them well suited for use with a wide variety of application programs' databases.

Description

1 3 2 ~

The subject matter of this applicatlon i5 related to that of Canadian Patent 1,308,198, entitled "Data Processing System Having a Data Structure Wlth a Slngle, Slmple Prlmitlve" by Edward S. Lowry, issued September 29, 1992.
BACKGROUND OF THE_INVENTION -Thi~ invention relates generally to the field of databases, and more speciflcally to the uses of common databases by several applicatlon programs.
Often many different application programs must be adapted to share or exchange information with other programs in a computer system. One notable example is a set of interactive -~
computer programs which provlde assistance ln the design and manufac~ure of products. Such interactive programs typically include computer-aided design ~CAD) programs and computer-aided `
manufacturing (CAM) programs that are used in the development of ~ `
products. Other examples of appllcation programs often requiring information exchange are document retrieval programs and pro~ect manage~ent programs.
In such systems, output data from one application program is often input data for one or more other application programs. For example, the output data of a CAD program used to develop the design of a circuit board may be u ed a~ input data for a CAM program which facilitates manufacture of the designed circuit board.
In order for output data from any application program to `~
func..ion ~s the input data for another application program, 132~
however, bot~ application programs m~st be designed to allow such a transfer of data may take plac~ The output data must b~
prepared and pres~nted in a.form which is acceptable for uso by the applic~tion p~o~ram which operates on the data. Application programs which com~nicate in this manner are said to be inte-: grated. : -Achieving integrat}on between pairs of software application programs is ~ relatively simple task. Such inte~ration merely .
re~ires modification to one or both of the t~o application pro- :
grams sought to be integra.ted.
Achieving integration among several other Application pro-grams, on the other hand, becomes increasin~ly complex as the : .
number of programs increases. Integrating several pro~rams is nvt uncommon, however. Por example, one CAD program for d~signing integrated circuits may need to be integrated wi~h ~another CAD program for designing circuit ~oards as well as with ;
a C~M progra~ to manufacture the boards.
Typic~lly, the integration of one applic~tion program with '-several other application programs is achieved by designing tbe . first program t~ be in~egrablo with each of th2 other prsgrams.
:, This design strategy, however, requires detailed knowledge ~bout ~
. th2 input requirements o~ each progr.am and may require redesign :
of the first ~pplication program each time a new application - program is added. If ~he other application programs are instaad ~5 redesigned ~or integr~tion with the first application program, ~imilar problems arise.
.:

: ~3- . :
:', . ' ' ; :

.: .- . '. ' ;' .. ' ':'-' ' ' ` . .' . ' . : ,. . ' . . , 1 3 2 ~
Alternatively, a conversion progr~m may be used to inte- , gra~e the first appli~ation program with tho other application programs. AS other progr~ms are added, however, additional csn- ~ ;
version programs must be designed. .
The use o~ these ~onversion programs and the redesign of the i~pplication programs to achieve integration require consid-erable time, effort, and expense. This time, effort and expense dr~m~tically increases with the number of programs to 4e inte- .
grated.
lo To obviate the need for additional conversion programs, common databases ~ave been adopted to store data in memor~ in an area which is accessible by the diffeient program Systems . using a common database only require each a~plicaation pro~r~m to h~ve an interface ~ith the common database. Such int~rfac0s convert dat~ output by an application program into a common format for storage at the common database, and convert the da~a . from its com~on format into a format in the common database ~cceptable for t~e application programs. Common database sys-; tems which are known o~ used to store da~a include, for example, , the "relational,n nfunctional,~ and ilCodasyl" data models.
Al~hough comm~n database sy5tem~ usi~9 conven~ional data ' models overcome the threshhold problem of progr3m integration ;
described abo~e, the use of conventional data models presents distinct program~ing and performance problems for the int~grated : ::
programs. For one discussion of the programming and performance ~ro~lems presented by conventional data models see U.S. Pa~tent --~
No. 4,631,664 issued to Cha~lss W. Bachman.
- ' ' '~'' .' -4- ` -.

.., .. ' ,, . .:

~ \ ~
- 132aO~
~ccordingly, it is ~n object of th~ pr~sent invention to provide a method for integrating several application p~ograms using a common data str~ctur~ in a manner which reduces th~ need and complexity of additional c~nversion programs or redesign of application programs.
It is also an object of the present invention to provide ~
program integration method which overcomes the practical perfo~-mance pro~lems encountered by common database systemS utilizing conventional data models.
is anoth~r object of this in~cntion to provid~ a means for mansging the access to such a co~mon d~ta structu~e by application programs~
Yet another object of the present inventlon is to pro~ide a common data structure which can be easily adapted to a data pro-cessing system with auxiliary memory.
It is ~ further object of ~he pres~nt invention to express information in application programs using only a single primi-~ive element which can represent the complex interrelationships ~ of ~pplication program information.
Addi~ional ob~ects and advantagQs of the inv~ntion will b~
; se~ forth in the description which follows or may be learned by practice of the in~ention.

. . ' -''' -5- ~

~' ' ' ',~

132~0 ~J~
. , .
SUMMARY 0~ TH~ INVEN~IOU .
To achi~ve the foregoing objects, and in ac~ordance wi~h ~the pur~ose of the invention as embodied and broadly de~cribed herein, a data structure for access by a plurality o~ applica-tion progr~ms is created from single primitive dat~ elements or attribute data o~jects. According to the prese~t in~ention, a data processor which executes the applica~ion programs also cre- .
ates the d~ta structure in d me~ory coupled to the data proces- :
sor. The d~ta structure is created using data origin~ting in . the application progra~s and including node data and node data descriptors. Specifically, the method of creating t~e da~a str~cture comprises the steps, executed by said data processor, ~-of creating a different one of the attrib~te data objects for . each of the node da~a and organizing the attrib~te da~a objects : hierarchically according to a being-held relationship by choos- -.
ing from ~h~ attribute data objects for each of the attribute ;
data o~jects, a holder data object such ~hat a hierarchical , ~-being-held relationship exists ~etween each attrib~te dat~ ob-ject and a singl~ holder data object.
The method furth~r compri~es the st~p o~ e5tablishing non- - ;
nier rchical relationships for selected ones of the attribute ; .
datz o~jects created from node da~a associated with at leas~ one o~ said node data descriptors by choosinq, from the attribute : -d~ta ob~ects, reEer~nt data objects for ~he selected attribut~
. dat~ vbjec~s. Each chosen re~erent data object re~lec~s a nod~ :
. data desoriptor of the node data for which a corresponding ,, :.
-6- - ;
. , ' ", . . ~ .

. " . ; ,. ,.. . ,- , ,! .. . . ', :' ; ' 132~

selected attribute data object was created. The selected attribute data objects are called relation data objects and the attribute data objects without referent data objects are called element data objects.
The method further includes the steps of creating an apex data objec~ with which at least one of the attrlbute data objects has a being-held relationship, the apex data ob~ect having no being-held relationship with any of the attribute data ob~ects, creating an attribute file for the attribute data objects, and lo entering each of the attribute data objects into the attribute - ~-fll~.
Also according to the present invention, the method comprises the steps of entering holding pointers far each of the attribute data objects into said attribute file, the holding poi~ter of each attribute data object indicating the one of the attribu~e data objects having a being-held relationship with that ;
at~ribute data object, and enterlng referent pointers into the at~ribute file, the referent pointers reflecting the non- ~-hierarchical relationships between the attribute data objects.
~o Different aspects of the invention are claimed hereinafter.
According to one aspect, the invention provides a method for creating a data structure for access by a plurality of application programs, said application programæ being executed by a da~a processor which also create~ said data structure in a m,emory coupled to the data processor, said da~a structure being created from application data originating in said applicatlon 132~6~ 68061-141 programs and including a plurality of node data and node data descriptors, and said method comprising the steps, executed by said data processor, of: ~a) creatlng a different one of a plurality of attribute data objects for each of said node data; -:
(b) organizing said attribute data objects hierarchically :.
according to a being-held relationship by choosing from said plurality of attribute data objects for each of said attribute data sbjects, a holder data object such that a hierarchical being- ~
held relationship exists be~ween each attribute data object and a ~ .:
lo single holder data object; (c) establishing non-hierarchical :
relationships for selected ones of said attribute data objects created from node data associated with at leaæt one of said node data descriptors by choosing, from said attribute data objects, : ~
referent data objects for said selected attribute data objects . .
such that the chosen referent data object reflects a node data descriptor of the node data for which a corresponding selected aktribute data object was created, said selected attribute data objects being called relation data objects and the attribute data F
objects without referent data objects belng called element data ~.
~o objects; (d) creating an apex data object with which at least one -of said attribute data objects has a being-held relatlonship, said apex data object having no being~held relationship with any of said attribute data objects; (e) creating an attribute file for said attribute data objects; (f) entering each of said attribute data objects into said attribute file; (g) entering into said attribute file holding pointers for each of said attribute data objects, the holding pointer of each attrlbute data object 7a 132~S

indicating the one of said attribute data objects having a being-held relationship with that attribute data object; and (h) .
entering referent pointers into said attrlbute file, said referent pointers reflecting said non-hierarchical relationships between ~
said attribute data objects. ~ -According to another aspect, the invention provides in a data processing system including at least one central processor ~`
executing a plurality of application programs and also including a -memory containing a data structure common to said application programs, said common data structure containing a plurality of attribute data objects each having hierarchical being-held relationships with a single other one of said attribute data objects or with an apex, wherein selected oneæ of said attribute data object~ have non-hierarchical relationships, and wherein each ~ -of said attribute data objects has an associated meDory area including pointers to memory areas for other ones of said attribute data object which have said being-held relationship wlth ~ :
that attribute data ob~ect, a method for adding a desired one of said attribute data objects to 8aid data structure comprising the ::
steps, executed by said central processor, of: creating a memory area for said desired attribute data object; locating, as a holder attribute data object, the one of said attribute data objects with ;:
whlch said desired attribute data object has a being-held -~
relationship; adding in the memory area for said holder attribute data object, a pointer to the memory area of said desired attribute data object; and linking~said deslred attribute data ; -object with other ones of said attribute data objects having a --:
:,,'" '.' 7b ,,, - : .

1325066 68061-141 ;
being-held relationship with said holder attribu~e data object.
According to yet another aspect, the inventlon provide~ ~
in a data processing system including at least one central ~i processor executing a plurality of application programs and also including a memory containing a data structure common to said application programs, said common data structure containing a data structure with a plurality of attribute data ob~ects each having hierarchical being-held relationships with a single other one of said attribute data objects or ~ith an apex, wherein selected ones ~;;
of said attribute data objects have non-hierarchical relationships with others of said attribute data objects, and wherein each of said attribute data objects has an associated memory area, a method for creating a desired non-hierarchical relationshlp between a given one of said attribute data objects and a referent one of said attribute data ob~ects comprising the steps, executed by said central processor, of, determining a location of said referent at~ribute data object; accesglng the memory area for said yiven attribute data object; and placlng a pointer to gald referent attribute data object location in said memory area of said ylven attribute data object.
According to a further aspect, the invention provides a memory system coupled to a central procegsor and contalning a data --structure including an apex, a plurality o~ elements each corresponding to a different node datum in an application program executed by said central processor, hierarchical holdlng relation-ships among said elements, and non-hierarchical relations for said -ele~ents, said hierarchical holding relation~hips in said data '-~' ~, 7c ~
:' 1 3 2 ~
- 68061-141 ~-structure being restricted such that for each of said elements, : .
only one other element or said apex has a holding relationshlp with that element, said memory system comprising, element storage means for containing information about each of said elements, said ~.
element storage means including a header portion containing identifying information about said elements, holding pointers identifying the elements for which each of said element has one of :
said holding relationshlps, and relation identifiers specifying said non-hierarchical relations; and apex storage means for ~;
containing information about said apex, said apex storage meanæ ~.
including identifier information for said apex, and element pointers to the elements having one of said holding relationships with said apex.
The accompanying drawings, which are incorporated in and which constitute a part of this specification, illustrate an ~:
embodimen~ of the invention and, together with the description, explain the principles of the invention.

.: ..

', ';

, '::

7d ..... -, .~

~32~0~6 BRIEF DESCRIPTION OF THE DRAWINGS
Fig. 1 shows an example of a data processing system in accordance with the present invention;
Fig. 2 shows an example of an attribute data object as taught by the present invention;
Fig. 3 shows a circuit for use in illustrating the use of Attributive data model of the present invention;
Fig. 4 shows a data structure for representing the circuit of Fig. 3 according to the Attributive data mode;
Fig. 5A shows a block diagram of certain components of a software system in accordance with the preferred embodiment of the present invention;
Fig. 5B shows a block diagram of certain components of a software system in accordance with an alternate embodiment of the present invention.
Fig. 6 shows a portion of the contents of a memory system containing a data structure including a plurality of files in accordance with the present invention;
Fig. 7 shows a 32-bit longword used as a pointer in the preferred embodiment of this invention;
Fig. 8 shows a more detailed block diagram of the constitu-ent portionq of the attribute file shown in Fig. 6;
Fig. 9 shows a block diagram of an element header block shown in Fig. 8;
Figs. 10A and 10B show block diagrams of the preferred embodiment of a relation sub-block shown in Fig. 8;

: Fig. 11 shows a blo~k diagram of the preferred embodiment of a "held~ o~ject su~-block shown in Fig. 8;
Fig. 12 shows a block diagram for a plural relation h~ader block shown in Fi~. 8; -~igs. 13A and 13B shows block diagrams of the preferred embodiments of two kinds of pl~ral r~lation sub-blocks shown in Fig . 8;
Fig. 14 shows a block diagram of th~ preferred ~mbodiment of an instance root block shown in ~ig. 8;
Fig. 15 shows a block dia~ram of a preferred embodiment of a dictionary f ile shown in Fig. 6: ~ .
Fiq, 16 shows a block diagram for the basic structure and - contents of the preferred ~mbodiment of either an apex block or a context block shown in Fig. 15;
. Fig. 17 shows a block diagram of a pr~farred embodiment o~ .
an element type block shown in Fig. 15; ~:~
Fig, 18 shows a block diagram ~or an attributs typo block shown in Fig. 15;
Fig. 19 shows a preferrad ambodiment of a block diagram of ~ ;
- an index branch b~ock in ac~ord~nce with the present invention;
; Fig. 20 shows a block diagram of a preferred embodiment of an index branch header block shown in Fig. 19; . ;
Fig. 21 shows a block diagram of an index branch .
sub-blscks shown in Fig. 19;
~5 Fig. 22 shows 8 block diag~a~ o~ a p~c~crred ~mbodiment an index directory block shown in Fig. 8;
'.. :

"'' ~"
.. , ., ~., ,,. ~,.. .~, .,. ... - .,, ... -,,. " . . - . ..

~ , 1 3 2 ~
Figs. ~3A and 23B show a flow dia~ram depicting the steps involved in ~ preferred method of creating an element dat~ ob-ject according to the present invention;
~ Figs, 24~ and 24~ show a flow chart depicting the steps in- -volved in a preferred method ~f creating a relation in accor-dan~e with the present invention Pig. 25 shows a flow chart depicting the steps involved in the pre~erred method of erasing a relation in accordance with the present invention;
Fig, 26 shows a flow ~hart describing the steps lnvo~ved in er~sing an element data obj~ct in ~cco~dance with the present invention; .
Figs, 27A and 27B show a flow chart describing the steps : invol~ed in the preferred met~od of a~cessing the common data structure in accordance with the present invention; :~
Fig. 28 shows a flow chart describing the steps involved in : an alternative preferred method of ac~essing the common data structure using key values in accordance with the present inven-tion 2p ~ Fi~, 28A shows an ind~x result block:
Fig, 29 shows a detailed block diagram of a preferred embodim~nt of ~ommon data structure lg~' in accordanc~ with ~he presen~ invention; :~
- Fig. 30 shows a ~lock diagram o~ ~ pr~ferred embodiment of : the pointer/count~r section o~ a controller sho~n in Pig. 29:

132~06~ :
Fig. 31 shows a block diagram of version blocki~ shown in Fig. 29;
Fig. 32 shows a block diagr~m of switc~ blocks shown in Fig. 29;
Fiq, 33 shows a flow chart describing the steps involved in updating data structure 140' in accordance with the present invention;
Fi~. 34 shows a flow diagram ~or a pref~rred COMMIT rou~ine ~;
indicated in Fig. 33;
Fig. 35A, 35~ and 35C show flow diagrams of the procedures followed in the initial, intermediat~ and final housekeeping - ;~
steps, respectively, of ~he COMMIT routine shown in Fig. 34; and ; ~
Fi~. 36 shows a preferred embodiment of a flow chart for . .
accessing t~e desired v~r~ion of common data structure l~O' in ~ accordance with the present invention.

.....

' .', ~
' ,, . ' ' '"~- -.:. ' '.', ,~

--11-- . . -, . ",' " ' ~.'''-'-' 132~0~
DESCRIPTION OF THE PREFERRED ~MBODI~
Re~erence ~ill now be made in detail to presently pre~erred . embodiments Oc this invention, examples of whi~h are illustrated . in th~ accompanying drawings. :~ :
~. Common Da~abase Str~cture Fig. 1 ~ho~s a picture of a data pro~e~sinq system 100 including a central processing unit (CPU) 110 and a memory lZ0. -CPU ll0 can be any standard and commonly known central pro- :
cessing uni~, and memory 120 can in~lude magnetic ~ore, semicon~
1~ ductor ~A~, magnetic disks and magneti~ tapes, or any oth~r known memory device. CPU 110 can also ~epres~nt several inde~ .
pendently running central processing unit9 which may be ~ :~
executing application programs simultaneously. As sho~n i~ Fig. i 1, applicatisn programs 130, 132, and ~34 are a}ternately axa- , .
. cuted by CPU 110. Fig. 1 shows CPU 110 executinq application ' ;:
program 130 ~hile application progra~s 132 and 134 are stored ~n memory 120.
, ~ .
In acc4rdance with the pre~ent invention, application p.ro- :
:~ crams 130, 132, and 134 share a common dat~ s~ruct~re 140 which is based upon an Attributive data model. The Attr~b~tive data model repreSents all of the informdtion sccessed ~y application l .
programs 130, 132 and 13~ a various combinations of a single . .
primitive. In general, application programS 130, 132, and 13~
have their own databases which contain data eitber in the . .-2s Att~ibutive data model's format or in some other format. If the ~ ~.
application program information is not in the ~tt~ibutive d~ta .:
.:
: , - .: ' -12- ~ :

-:
. - ' ' ' - 132aO~
model format, it is converted into th~t format by me~n~
desçribed belo~. In this manner, data structure 140 can be acces~ed by each of the application progra~s 130, 132, and 134. ::
The common data structure 140 is different from more c~n~
~entional database systems by tne unique data struct~reS which ar~ created and accessed ~y the application programs. The ~ ~:
Attributi~e data ~odel uses, as its single primitiv~, an --~-attribu~ce or attribute data object which contains certain hier- ~
~rc~ical information about its relationship with other :
lo attribu~es, and which can "point to~ attributes to reflect a - nonhierarchical relationship. The u~e of t~e attributes in ~ -accordance with the presen~ invention is limited by the use of certain simple rules. These limited num~er of rules allow the a~tributes tne flexibility to accurately represent complox ob~
1~ jects and relationships. ~ -Fig, 2 shows an example of an attribute data object 200. .;.
Attribute data object 200's hierarchical relationship with othe~ ::
- attribute data objects is denoted as a hold ng or being-held..e- : ~
lationship, depending upon how the r~lationship i~ c~nside~ed. ~;

2~ In general, each attribut~ data obj~ct can have a being-held re-la~ionship with (i.e., can be held by~ only one other attribute data object, 4ut each attribute ~ata object ~an have a holding `--relationship with ~i.e., can hold~ se~eral other attribute data objects, Ea~h att~ibute data object 200 is relatqd hierarchically t~
a hoider attribute dat~ object 210. Holder at.tribute data -13- ;
'.' 1 3 2 ~
: object 210 is the attribute data object which has ~ holding re lationship with attribute data object 200. Conversely, attribute data object A 200 has a being-held relationship with : attrib~te data objec~ 210.
The nonhierar~hical or pointing relationship describes the :
relationships between the information represented b~ attribute :- -d~ta objects. Certain attri~ute data objects may also b~ relat-ed to a single referent attrib~te data objeet to reflect the pointing relationship. A re~erent attribute data object 220 representS the info~mation which has a nonhierarchal relation-ship with the information represented by attribute da~a objec~
200, Each attribute data object 200 may al$o b~ related to type data which describes the relationship between the ~tSribute data ; .-~
. vbject 200 and those attribute data objects` for which attribute data object 200 has a holdin~ relationship as well as the : ref~rent attribute data objects which attribute data objec~ 200 "points to~ n , .
There are only a ~ew rules which the attribute data objects 2~ must ohey in accordance with this inYention. Although each : -~ttribute data object may hold several other attrib~e data ob~
- jects, each attribu~e data object ca~ only have a beinq-held re~
lationship with a single other attribute data objsct. Thus, . 2ach ~tribute data object h~s only one holder attribute data ob~ect.

-i4-; ' ' ' :
'.', 132~0~ ~
One kind of at~ri~ute data o~ject, the element da~a obj~ct or element, ~oes not hav~ a separate referent attribute da~a ob-ject because elements are considered to "point to" themselv~s, --~
i.e., each ele~ent is its own referent. Another kind of attri~ute data object, the rela~ion data object, is related to a single sepa~te referent attribute data o~ject. Each attribute data object may be a referent attri~ute data o~ject for a plu-rality of attribute data objects B~sic to the Attribu~ive data model is the concept that the single pri~itive element, the attribute, can represent complex information in other dat~ases. An attribute expressas the idea --~
that one thing is attributed to another ~hing. For example, things normally attributed to an auto~obile include its color, its engine, and i~s owner. ~o organize complex datab~ses around the at~ribute as ~ primitive represents the view that a dat~base ::
is basically a collection of attribu~ions. ~ommon data struc- ~
ture 140 is a concrete representa~ion of that view.
As indicated, element~ or element data o~jucts ~re attribute data o~jects which ref~r to themselves, or in other . .
~0 words have only a holder a~tribute data object and no separate referent attrib~te data objoc~s. An element can represent a .
thing, s~c~ ~s an automobile, an engine, a version of a multi-: plier circuit, or a signal. Elements which have a being-held - relation~hip with an element ~an, for ex~mple, represent the in-- ternal structure of the thing represented by that ~lement. For ex~mple, if an element represents an en~ine, other elements - ' " . . . ''. : .
. .

, - .. ~ . ... .... ., . , , ., .. , . ,, . , .. ., . .. j .. .. . . . .

132~0~S
having a being-held relationship with the element representing the engine can includ~ the pistons, the cylinders, a~d the rings.
Each embodiment of data structure 140 has one attribute data ob~ect which does not have a ~eing-held relationship with another attribute data objec~. That ~tribute data obje~t is called the apex or apex attribute data object and holds at least one other attrib~te data object. In addition to the requirement of a single apex attribute data object and the single holder for ::.
each attribute data ob~ct, each embodiment of data structure 140 has the configuration of attrib~te data obje~ts in accordance with the invention such that it is possible, b~t not nece~sary, to create the configuration by start~n~ with the apex .
and by adding the other attributes, one at a ti~e, in a holding ~:
relationship. This restriction creates a hie~archy and preventS : ~`
certain circular or loop configurations, such as when ~ first . -:
at~ribute data object has a holding relationship with a socon~
attribute data object, w~ich in turn has a holding relations~ip with a third attri~ute data object, whi~h then has a h~ld~ng ~-lationship back with the first attr1bute data object. Such a config~ra~ion would not ~e hierarchical according to ~hi3 inven-: tion~ .
The relation or relation data object, as explained above, :`
is an attrib~te data o~je~t which is related to a referent 2~ at~ribute data o~ject different from the attri~ute data ob~ect ~.
i~self. Relations can have a ibeing-held relationship ~ith Fn ~a ' ' . ', . ' .... "' ~

132~06~ ~
elements, for example, if an el~ment r~presénts a multiplier circ~it, one relation can ~ttribute to t~at element a previous version of the multiplier. In addition, relations c~n have holding and being-held relationships with other relations. For ~ :
example, if a first rel~tion attrib~te data object attributes a part number to a multiplier, that first relation attribute data :~
objec~ may hold a second relation attribute d~ta object which attrib~tes to the ~irst relation attribut.e data object the date ;::~
on which the part number was assigned to the multiplier. - :~
lo The Attributive data model can be better understood by an example. ~i~. 3 shows a circuit including two ~ND gates, 320 and 330, having th~ee inputs and t~o inputs, respectively. The ~; .
inputs ~f AND gate 320 are 322, 324, and 326, and the inputs of AN~ gate 330 are 332 and 334. Input 322 of AND gate 320 is driven by output 336 of A~D gate 330, and input 334 of AN~ gate , .. -330 is driven by output 328 of AND gate 320. ~;
The circuit in Fig. 3 can ~e rep~esented according ~o many different data models. For example, if it were represented.by a -~ ~.
r~lational data model, there ~ould be separate tables for gates, .
?o inputs, and load~ of thQ gates. ~hose tables ~ould then contain identifi~rs of entries in the other tablss.
FIg. 4 shows a dat~ structure 400 r~presenting the inform3-. tion in Fig. 3 in accordance with the A~tributiYe data model of : this invention, Data sSructure 400 can b~ stored in the common 2~ dat~ st~uctur~ 140 in ~ig. 1.
':
'' '.

-17- . . .

,:

132~0~
Data structure 400 includes an apex glO which, as described above, does not have a being-held relationghip with a~y other object. In addition, apex 410 holds (i.e., has a holding rela-tionship with) CPU ~tribute data object 42~, which can also be a context. The context is a construct to facilitate naming of attr~bute data objects, because those names ha~e meaning only in the context holding the named objec~s, and to establish holding relationships for attribute data o~jects that are associated :~
with the context, like the circuits and signals in Fig~ 3.
, .~ .
lo CPU attribute data object 4~0 holds attribute data objects 430 and 440 whi~h are ci~cuit elements. A~tribute data o~ject g30 represents the circ~it in ~ig. 3. Attribute data object ~30 in turn holds two attribute dat~ o~jects 450 and 46~ which ar~
. gate elements. Gate element 450 in turn holds ~our attribute data objects 480, 4~2, 486 and 488 which are p~n elements. In ~-:
~his way, a hierarchical ho~ding relationship is imposed upon the in~ormation in Fiq. 3.
As Fis, 4 shows, the other information from Fig. 3 is a~so hierarchically organi~ed. ~pex 410 al~o holds elemsnts 462, ~64, ~66, 468, 490, and 492 repreSenting l~els for other ~le-. ments, and attribute data object 420 tCPU elem~nt) holds ele- -, ments 470, 472, ~74, and ~76 w~ich reprssent si~nal elements.
The hierarchical arrangement of attribute data objects ::
gives rise to a ~containment tree," which is used to contain the ~5 at~ribute data o~je~ts that collectiv~ly reprcaont conceptual -o~jec~s. A containment tree of an attribute data o~ject, called ..
-18- ~:

'- - ' ' '" ': '" . :'' '~'' ' ' ; ~'.

132~0~S
the root attribute data obje~t or root of the contAinment tree, :
includes all attribute data object, held by the root (i.e., : -directly held), as well as all attribute data objects held by any other attrib~te data objects in the containment tree (i.e., s indirectly held)~ An ~ttribute data object held directly or in-di~ectly by another attribute data object is said to be "con-tained" by that other dttribute data obiect or in that ~ther attri~ute data object's containment tree. In a containmen~ :
tree, the conceptual o~ject represented by that tree corresponds to the root, .~11 other attri~ute data objects in the contain-~ent tree represent conceptual sub-objects, such as components, listed items, or relationships wit~in the conceptual objec~ rep~
resented by the tree. The attribute data objacts in 8 contain- -.:
: ment tree may ~Iso represent rel~tionships with atSrib~te data ~-. objects outsid~ the ~ontainment tree. - :
In Fig, 4, the containment tree ~or circuit element 430 : -.
would include gate e}ements 450 and 460, and the relation data objects held ~y gate elcments 430, and 45~ (i.e., the rolaticn da~a objects pointing to elements 440 and ~68 and the relation ~ata object pointing to element 462), the element~ hold by ele- ...
men~ 450 (i.e., pin ~lements g80, 482, 486, and 488), and the relatlon data obj~cts held by pin el~ments 480 and 48~ ~i.e., ; rel~tion d~tA objects poin~ing to elements 464, 470, 472 and :, : ~6~. -~5 The use of o containment tree, as expl~ined in ~etail belo~ simplifies operations such a~ erasing complex objects, ~:~

~ . . , , ', . . ! . . ' . . ' ' ' , ' , 132~
As an example~ erasure of an object involves the removal from the com~on d~ta structure ~f the corresponding containment tree.
~his in~ention allows all attribute data objects in that tree to be identified quickly, making feasible the elimination of random pauses caused by automatic garbage col}ection commo~ly used in prior art databases.
Fig. 4 also contains several other attribute data o~jec~
which are representative of infor~ation describing each of the ~hings in Fig. 3 represented in Fig. 4 by attribute data cb-jects. For ex~mple, attribut~ data object 430 holds a relation .dat~ object pointing to the name "xyz." T~is relation data ob-ject has ~xyz" as a reerent attribute data object, The name -~
"xyz" is element 468. In ~ similar matt~r, element ~50 has a rel~tion data obiect pointing to element 462, which is th~ num- -ber (320) of the AND ~ate in Fig. 3 re.pr~sented by element 4~0. :
Fig. 4 shows other r~lations as well. For ex~mple, ele-ments 470, 472, 474, and g76, representing signals such as Sl and s2, are organized into a linked lis~ which is represented by a series of relations. .Furthermore, attribute data objoct 480 2V also holds ~ relation pointing to attribute data object 470 : :
showing that the signal reprssented by that.object is an input ; -t~ thE gate represented by object 450. The ~onverse relation-ship is also represented by a relation held by element 4~0 ~: ~
~pointing to element ~80. The name of the signal represented by ~ -2s : at~ribute data o~ject 170 is re~lec*ed by the relation held by attribute data objec~ 470 and pointing thé attribute data object .
~90, which represents the label ~Sl~

::

.. . . ~ . . . = .. . . . .

1~2~066 Preferably, a simple con~tant, such as the inte~er 35 or the characte~ "K,~ is an element and is represented by ~ s~ngle .
attribute data object held by the apex. A character string is also preferably an element held by the apex. The ch~racter string element, however, holds a list of relations to its con- :
stituent character ob~ects. Thus, for example, the string "CAT" :
co~ld be represented by an element data object which held first relations to three other element data objects or elements: the letters ~C,~ nA" and "T.~ Th~ ordering of those letSer element~ .
~o ~o form the character string "CAT" could be represented by sec- :
ond relati~ns that organize the first relations into a list.
For example, the relation from "CAT~ to nc~ would hold a rela-tion whose referent data object is the relat;on from "~AT" to ~A." . -B. Software Utilit~ Orqanization . .
Fig. 5A shows a block diagram of certain components of a software system in accordance with the preferred embodiment of the present invention. ~he operation of certain of t~ese compo-nents is presentQd in a later section, All that will be . . .
~o d~scrib~d with regard to Fig. 5A i5 the ma~or functio~s of each :
one o~ the componen~s and their relationship to other compo~
. nents. .
Preferably, the common data stru~ture 140 shown in Fig. 1 - includes ~ master database 510 and a slaYe database 520, Any upda~es to the common dat~ structure 140 are made t~ master .
database 510, and a copy of it is later mad~ to form the nexf vers~on of sl~ve database 520.

-21- .

1 3 2 .~
In Fig. 5A, ~30 and S60 represent twO application programs, such as th~ application programs 130! 132 and 134 in Fig, l. In , : accordanee with the present invention, the dsta processing sys-. tem includes means for retrieving from the common data structure .
the referent attribute data object fo~ a specified relation data object. For applicatioA program 530 shown in Fiq. SA, retrieval program 580 performs such retreival f~nction. ~e sla~e database 520 provides the actual data to the application pro- .
gram~ 530 and 560.
The details of an exemplary embodiment of portions of a retrieval program 580 are discussed in a later section. In g~n- ', eral, however, application program 530 specifies a rolation data , object to retrieval program 580 and asks for the referent data . object(s) for ~hat specified relation data object. Retrieval ` program 5~0 then searches the slave database S20 for ~he I ~
specified relation data o~ject. When ~hat spacified relation , ~:
data object is obtained, retrieval program 58~ copies the ~ -~
. desired r~ferent attribute data object(s), performs any conv.er~
. sion necessary to place the referent data object into the format . appli~a~le ~or application program 530, and returns the , ~:
formatted referent data object to application program 530. . -:~
. The data struct~re ~f the present invention also in~udes m ans ~or retrieving from the common data stru~ture all of thos~
at~ribu~e data ~bjects which have a being-held relationship with ~-Z5 ` a speci~ied attribute data ~bject. Again, retrieYal progra~ 580 , ; in the preferred em~odiment shown in Fig. 5A performs this type '` ~'',., -~2-, .. :, .; . ; .

/
~., .... , . ,~ ~

132~0~ `
of retrieval also. In operation, applicat~on pr~gram 530 specifies an attri~ute data object and asks for all thos~ other attri~ute data objects which are held by the spe~i~ied at~ribut~ .
data objec~. Retrieval program 580 then translates that request S in~o an appropriate format, and searches through the slave database 520 ~ntil the specified attribute data ob~ect i~ locat~
ed. Once the specified attribute data object ls locat~d, retrieval program 580 o~tains copies ~f all of the attribut~
data ob~ects which are held by that specified data object.
Retrieval program 580 then converts those held attri~ute data ~
~bjects into the format applicable for application program 530 :. .
and transmits those converted attribute data objects to applica- :
t ion program 530 .
In accordance with the present invention, the data pro- .
cessing system also includes means for retrieving from th~ com-mon d~ta struc~ure information from all attribute data objects of a specified type. ~etrieval program 580, in response to s~ch a request from application program 530, searc~es the common ~ata :
~ structure 140 in slave database 520 for all attribute data ob~
jects of the specified type~ When thosé specified attribute data objects a~e found, the attribute data objects a~e .
- extr~cted, conve~ted ~nto the appropridte format, and sent to retrieval program 580. .
Preferably, retrieval program .530 performs the same func-~ions as r~erieval program 580. The only functional difference between retrieval programs S80 and 590 would reflect the manner ~ --~3-, . i ". :~ :

13 2 ~ 0 6 6 in which information is transmitted to appllcation progra~s 530 and 560. For example, retrieval progra~ 59~ could perform a se-ries of retriev~ils as described above, converting the data so obtained into appropriate format for application program 560, s and write this data into a file 5~5. Application program 560 ::
would then read the retrieved data from file 5~.5.
Further in accordance with the present in~ention, the data pro~essing system includes means for creating a new attribute ~ata object in the common da~a st.ructura from an identification lQ of the attribute data object desired to be the holding attri~ute data obje~t for the created attribute data object. ~hat . .
creating means co~ld also include means for creatin~ ~he new . `
attribute data o~ject from an identific~ion of a referent data : --object as well to form the created relation data object.:; :
Fig.. 5~ shows different ways for creating new attribute da~a objects in the common data structure 1~0 acco~d~ng to th~
preferred embodiment of the invention. For example, application program 530 uses con~erter program 540 which receives the nece~
sary infor~ation from a database in application program 530, extract~ the needed information ~or ~orming common data struc- ~.
t~re 140 in master database 510, and then constructs attribute . d~ta objects by determining the holder attri~ute data obj~cts.
and the refer~nt data objec~s. Converter prog~am 540 then sends ~:
~hese at~ribute data objects to master database 510 for storags.
2s As another example, information ~reated in appli~ation pro-gram 530's database ca~ be sent to master dat~base 510 as -24- . .
. ' . -. .

'' ''; ~' ' '' I 132~0~
l j ..
" ~ollows. ~irst, application program 530 sends a request to.up- , date synchronizer 550. This request includes information char- :
, ~cterizing the desired update. Update synchronizer 550 then ,~ modifies m~ster database 510 by signaling converter program 540 : ~o modify master d~t~base 510 by creating attribute data objects in common data structure 140 uslng information from appli~ation program 530. update synchronizer may also be used to create . :1 ' attribute ~ata objects in master database 510 in accordance with ~ :
j ~he characterization in~ormation ln the update re~uest.
'. Prsf~rably, converter program 570 pe~f~rms the same ~unc~
tions as converter program 54~. ~he only dlffer~nca between converter programs 54Q and 570 shown in Fi~. 5A is ~he manner in ~ .-~ which inform~tion is t~ansmitted from app~ication program 560- i .
. Application program 560 first writeS data into a file 565. Con- ¦
' verter program ~70, after receiving a signal from update syn- !
" c~ronizer 550, reads file 565 and cre~tes attribut~ data objects ~ .:
in common data str~cture 140 of master database S10 in accor-' dance with data in file 565.
Modi~ications of master database 510 and signals to con-2D . ~erter progr~ms 540 and 560 are performed by update synchronizer ,¦ 550 to ensure that m~ster database 510 is updated in a regular 1 and noninterruptive manner while the ~ommon data structure 1~0 in master database S10 and slave dataDase 520 are used by appli-`! ca~ion programs. ~pon completion of modifications to ~aste~
'~ datab~se 5iO by converter program S40 or conve~ter program 570, ~I copy of the co~mon data structu~e 140 of master database 510 -.
,1, . , , , , ,' ` .
} -~
-25- . .

' ~

- -: : : - . - - ~

1 3 2 5 ~
is then made av~ilable as a new version of slave database 520r ' where it may ~e accessed by retrieval programs S80 and 590.
.. , ~ .
i The present invention also includes means for re~oving a specified attri~ute ~ata object from the common data structur~.
- This is sometimes known as ~n er~se operation and is easily per-formed due to the hierarchical data arrangement o~ the common data structure 140. In the preferred embodi~ent, a database ~ .
modifying program such es converter 540 first locates a specified attribute data object in response to a re~uest re- , -. ceived fr~m applicati~n program 530. Then conver~er 540 removes the attribute data object from the common data structura l~0. ! :
.' In addition, application program 530 ~an request not only .
, that the specified attribute data object b~ removed, but also j that the entirs containment tree for that attributc data object lS ; be removed. In respons~ to such requests from application pro~ I .
. gram 530, converter 54~ lo,~ates the specified attribute data o~
.~ jec~, Converter 54~ also locat~s all attribute data objects which are held by the specified attribute data object. Con- .
. verter 540 tra~erses through the containment tree by examining , holding relationships and locating all of the attribute data ob~
! jects which ar~ held directly or indirectly by th~ origina~ly s~eci f ied attribute data object. Convert~r 540 remo~s all lo- , -,~ ca~ed attri4ute data objects from common data st~ucture 140.
i~Figure 5~ shows a block diagram of an alternate embodiment ~ -2s of the component~ of the software sys~em in canmon dat~ struc- ' -~, . . . . .
ture 1407. The items surrounded by the dotted line, application ~.

! -2S-., ~ " .. ~.
; i , : . :
- , ~, ., 132~06~ ~
program 530, converter progra~ 540 and retrieval program 580, , a~e essentially identical to the ~orresponding alement~ in Fig~
ure 5A.
: ;
common data structure 140' in Fig. 5~ contains a master S data file 515 and a snapshot data file 525. Like slave dat~base 520 of com~on data structure 140, snapshot file S25 of comm~n .
data structure 1~0~ contains at least one complete copy of a version of master d~a file 515. However, unlike slave database :
520, snapshet file S25 is designed to represent a plur~lity of ~ . versions of master data f il9 ~15 ~y storing portions of mast~r ~l .
data file 515 which have been updated. In contrast, sla~o , : -database 520 is design~d to represent complete copies of t~e ' ;
current version of master dat~ba~e 510. Co~mon d~ts structure 1~0' ~lso includes a control file 55S which includes data neces- I :
sary for the control of the common data structure 140' as well I .
' as ~ertain locks to pre~ent simultaneous access of structure . . , ~
140' by several application programs. Two of the locks which Rre shown are ALTE~ lock 568 and ~BC lock.569. Th~se are . :~
explained in greater de~ail ~elow.
In addition, storage management softwar~ 566 is shown as ,' providing an interface between common data structure 140' and ~i the software encompassed by the dotted line$ in Figure SB. A .
. preferred embodiment of portions of storage managem~nt softwar~
566 will be expl~ined in greater detail below. ~ :
.~ , ' ' .
, . . .

~ -27- ~
:` ~
,,' . ~ -'`

.... ., . .. ,. .. .. ~ . ... . -- 1 3 2 ~ 0 i~
. C . Data $~r~ture ReE~ L_ation of the Common D
.1 In a preferred embodiment of the invention, common data structures 140 or 140' are stored-in memory 120 along with , application programs such as programS 132 and 134. This arrangement is shown schematically in Figure 6 as is the pre-ferred organiz~tional structure of common data structure 140 - into a plurality of files.
As Fig. 6 shows, the common dat~ structure 140 portion of memory 120 preferably includes an at~ribute file 600, a dictio-' nary file 700, dnd an index file 800. Prior to a detailed . explanation of these files, a general des.cription of the files' , functions will be provided to facilit~te an understanding of the ', entire system.
Attribute file 600 preferably includos all of the attribute I
. data objects or, more precisely, a memory area or data entry for !
, each of the attribute data objects. In the prefe~red embodi~ent i ~:
of attribute file 600, the attribute data ob~ects, including ~, ;
both as element data objects and rolation data objects, are.or- I
ganized in a manner which is consistent with the information in , : .
~0 ., ~he dat~bases o~ programs 130, 132 and 134. F~r example, in a .~.
¦ manner described in greater detail below, node data and nod~
da~a descriptors of the database~ are corresponded to element and relation data objects, and the hierarchical holding rela~
.' tion~hi~ is imposed on t~e attribute da~a objects in a logi~al '. manner designed t~ facilitate the access to and id~nti~ication , -! f desired at~ribute data objects.
.. - , -28~
,; ~ .- .
i' ; :: :
'I ' ' ', ' ~: ' ' `:

132~0 ! .
Dlctlonary file 700 preferably in~ludes ~ata entries for ~ -the apex and other contexts, ~s well.as information descriptiv~ , of the ~ype of attribute data objects in attribute file 600.
~ The data entries for the apex and contexts could instead be . :.
stored in the attribute file, ~ut those entries ha~e ~een s~ored in dictionary f ile 700 in the preferred embodiment of the inven-tion because that ~ile is t~eated primarily as a read only file, and the apex an~ context data generally do not change ~
ndex file 800 preferably includes information used ~y CPU
0 110 to obtain quick access to attribute data ob3ects in the.
attribute file. Index file 600 is designed to take advantage of ' c~rtain features of many practical implemen~ations of data ' structure 140 to in~rease the efficiency with which data struc-,, ture 140 may be used.
In the p~eferred embodiment of the present in~ention, attribute file 600, dictionary file 7~0, and index file 800 in ~ ::
common data structure 140 are main~ained in a ~permanent~ memory section of memory 12~, such as a disk. When CPU 110 needs to access cert~in portions of files 600, 700, and 800, CPU 110j ~, transfers those portions to ~ primary memory, such ~s semicon-,~ ductor RAM memory. ~he permanent memory i~ relati~ely larqe in . comparison with the p~imary memory and CPU 1~0 prQferably man~
, ages the f~o~ of d~ta between the permanent memory and the pri-! :
- :~ m~ry memory in usin~ known ~itual memory techni~ues and in a '~ preferred manner set ~orth below.

: -2 ,, - , ;. ', .
.;

132~0~
Preferably, data in each of the files in common data structure 140 are grouped in macropages. Each macropage iq a contiguous 64K byte portion of a file which consists of 128 512-byte pageq. In known embodiments of the invention, attribute file 600, dictionary file 700, and index file 800 have permitted up to 16K macropages of storage.
In the preferred embodiment of this invention, the standard unit of data in attribute file 600, dictionary file 700, and index file 800 is a longword composed of four bytes or 32 bits.
The pages or macropages of the files typically include several blocks each of which consists of a group of several longwords.
Often the longword is used as a pointer.
Fig. 7 qhows a 32-bit longword 615 used as a pointer. In :~
the preferred embodiment, CPU 110 derives longword pointers for -~
each of the data blocks in the files of common data structure 140. -According to the preferred embodiment, longword pointer 615 includes a leftmost bit, or TEMP field 616, which indicates whether the block of memory to which this pointer "points" is not part of the permanent data structure, in which case the rest of the pointer is the virtual address of the block in primary memory. The other fields shown in Fig. 7 apply only when the block is part of the permanent data structure located in permanent memory and transferred to primary memory as needed. ~
KIND rield 618 is two bits long and designates the kind of - -block to which longword pointer 615 points. For example, in tha -3Q- -:

:.:: , .

l 132~0~6 I; preferred embodiment, this ield indicates where the block j pointed to is in attribute file 600, dictionary file 700, or index file 800, The next ~ield, R field 620, is one bit wid~. R field 620 ; is presently reserved to allow an additional kind of pointer to be defined for use with the present invention.
The final field of longword pointer 615 is OFFSE~ field 622 ~hich comprises the twenty-eight rightmost ~its of longword . pointer 615. OF~SET field 622 identifi~s the referenced infor- , mati~n by specifying the location of that informa~ion as a , .

, longword o~fset from the beginning o~ a file containing th- ~ef- ~ -' erenced block.
.~ ~he pointers used in the preferred embodiment are not the , - -Only ones necessary to effect the present invention. Fo~ exam~
ple, the pointers can directly indicate the location of the cor~

responding items or can indicate that location indirectly through procedures such as indir~t or indexed addressing.
. 1. Attribute File Fig. a shows a more detailed block diagra~ of the con~titu- `
en~ portions of attribute file 600. Attribute file 600 includes l sev~r~l element blocks. Only one element b~ock is shown, how~
,~ ever, for simplicity, and for des~rip~ion purposes in ~h~s sec- . : .
j, ~ion, the ~ttribute data object r~presentQd by element block 60Z

, will be c~lled the ~represented eiement.~ T.he element block is ~ the b~sic data ~ni~ ~or representing an e~ement attribute data , object in the preferred embodiment.of attribute file 600.

. . .
. , ~ . .
. 31- ~
. i - ' ~:
., , , .,., .. ,. ., .,., ,.. ... , ; .. .. : , .

132~0~ ~
lement block 602 preferably includes one element header block 1.
~04, one or more relation s~-blocks 606 (optional), and one o~
more "held" element s~b-blocks ~08 (optional). In~ormation i regarding the number and ~ype of contiguous sub-blocks in ele-ment kilock 602 follo~ing element header block 604 is preferably provided in dictionary file 700 or through the use o~ a com- ~-~
piler. These blocks and sub-blocks are de~cribed in detail below.
Attri~ute file 600 also in~ludes plural relation blocks I :-lo ., 610, only one of which is shown for simplicitY. Each plural re-la~ion block 610 contains data for one or more relation data ob~
jects representing the non-hierarachical relationships in data ,. structure 1~0. Plural relation ~lock 610 preferably i~cludes a `, plur~l relation header block 612 ~nd one or more plural relation ¦
. sub-blocks 614. These blocks and su~-blocks aro also described in detail belo~
`, Finally, attrib~te file 600 includes instance root blocks I :
625 and index dictionary ~locks 630, only ~ne of aach of ~ich ;s shown for simplicity. These two blocks aro described in ,, detail below.
,l Fig. 9 shows a ~lock diagram of element header block 6Q4 in ! ;
.' the preferred embodiment of the invention. In this embodiment, each attri~ute data object in d~ta struct~re 140 would b~ repre~
~i sented by an element header block, such as element header ~lock 604. As shown, element header ~lock 604 includes six lon~words ' 900, 920, 925, 930, 935, and 94 ,i - I
i 3 ;
- .

1 132~66 I Longword 900 preferably includes a blank field 905, a SIZE
j field ~10, and a CLASS field 915. SIZ~ field 5'10 indicate~ thH
~! numbe~ of longwords in element header block 604. CLASS 915 in-,1 dicates that block 604 is an elem~nt header block.
Longword or TYPE DEFINITION pointer 920 specifies a loca-. tion in diction~ry file 700 containing elemant type information fo~ the represented element. Type information coul~ also hav~
been made available to common data structture 140 by some other . means, for example, through the use of a special compiler which : :
,, also could establish the apex, othe~ contexts, and identifiers ~ ~:
~i for contexts.
" NEXT and PREVIOUS pointers ~25 and 9io, respecti~ely, des~
" ignate the loc~ttions of element blocks ~or attribute data o~
,~ jects having the sa~,te holder attribute data object as the ~epr~
, sented element. In the preferred e~bodiment of the present 'I invention, attribu~e data objects of a common type having ~e ' .
s~me holder attribute data objects ar~ linked ~y use of $hes~
~i longword pointers, ~ha NEXT ard PRE~IOUS pointers 925 and 940, .
, ~espectively, effect s~ch linking.
, HOLDER and REFER~N~ES pointers 930 and 935 o~ el~m~nt 1~ header block 604 respectively indi~ate ths hierarchical being- ' :
'¦ held relationships and non-hierar~hical relations between the Il repre~ented elemen~ and other at~ribute data objects represetnted . ~ :
,I, in attribute file 600. HOL~ER pointer 630 points to the element 2~ lock ~or an attribute data o~ject, i.e., the ~holder object~
with which th~t represented attri~uto data object has a i, , , -.
t'' ' ' ~' !
132~06~
~¦ ~eing-held relationship. Thus, HOLDER pointer 630 points ~o the j Il element block of the attribute data Qbject which holds the !~ a~tribute data object represented by element block 602.
i The REF~R~NCES pointer 935 points to a first of a sequence ~ of plural ~elation blocks (e.g., ~lock 610 in Fig. 8) in ~t~ri~ute ~ile 600. Those plural relation blocks indicate the , ~
. attribute data objects which hold relations of ~hich the repre- ' -' sented element is a referent data object. The d~tails of plura.l relation ~lo~ks ~re discussed below. i, '. Relation sub-block 60~ and "held" element sub-hlock 608 of !
o~ject block 602 (shown in Fig. 83 are pre~erably ~ontiguous ¦ ;1 . sub-blocks which are also continguous to element header bloc~
6~4. For each o~ject block there msy be severa~ relation 5ub~
j blocks and several ~held~ element sub-blocks~ Relation su~
blocks 606 specify referent attribu~e data objects for singular ,~, relations held by the represented element. "Held" eIement sub~
. block 608 specifies the attribute data objects which have a being-~eld relationship with the repres~nted element. ~h~ r.ela- i -~ tioQ sub-blocks 606 and "heldl' element sub-block5 608 for the Zo I representHd object possi~ly appear in mixed order, .:~
igs. lOA and lOB show block diagram~ of the preferred embodiment of relation sub-block 606. Relation sub-block 606 prefe~ably contains one of two kinds of information. If rel~
l tion su~-blo~k 6~ is ~ relation pointer, then it appears as a ' :
,l longword or R~LA~IO~ point~r lO00 ~Fig. lOA) which specifi~s I -:
,j ei~her an element ~lock of a single referent attribute data-" -3.~

... , ~ - ., .. , . . .. - . .. . .. ... .

- , . .. - ..... , . ~,, . . ~, .. .

132~0~
object or a plural relation block (e.g., block 610 in Fig. 8) which in turn identifies several referent attribute data objects for the relations held by the represented element.
Alternatively, relation sub-block 606 may be a -NUMæRIC/STRING identifier for identifying a number or date, or a string. If relation sub-block 606 is a numeric or date -identifierf then it appears as double longword. Identifier 1050 may be a pointer to an element block representing an attribute data object for a character string or may itself be an integer or floating point constant or a date.
Fig. 11 shows a block diagram of the preferred embodiment of "held" element sub-block 608 shown in Fig. 8. Sub-block 608 includes longword pointers 1100, 1110 and 1120. Longword or -FIRST pointer 1100 identifies an element data block of the first in a selected order of attribute data objects which have a being-held relationship with the represented element. If only ~
one attribute data object has that relationship, then FIRST ~ -pointer 1100 identifies that attribute data object. Longword or LAST pointer 1110 identifies the last in the selected order of such attribute data objects, but also identifies the first attribute data object if only one held object exists. The selected order of attribute data objects having a being-held relationship with the represented object is the linkage defined by the NEXT and PREVIOUS pointers of those "held" attribute data ;
objects.

.~, .' ,,:

- l I 132~06~ 1 il ~ongword or INDEX pointer 6~0 contains a pointer to an ¦ ~-index directory block. These blocks are de5~ribed in greater i detail below, and the function of I~D~X pointers 640 will be ~n- !
il derstood from that description. . , ~
. As explained above, plural relation blocks 610 provide an ~' :
~fficient means of reference when sev~ral referent at~ribute data objects must ~e identi~ied. Ea~h plural relation bloc~ 610 ~ :
includes ~ plural relation header block 612 and one ~r more plu-i¦ ral relation sub-blocks.
lo ll, Fig, 12 shows a block diagram for plural relation header I ~ :
,¦ ~lock 612 according to a preferred embodiment of t~e p~sent ij inv~ntion. Plural relation h.eader block 61~ comprises longwords :-1200, 1210, 1220 and 1230. Longword 1200 includes a U5E field 1203, an ~NTRI'S field 1205, a SIZE field 1207, and a CLASS
' 15 11 field 1209. USE field 1~03 indicates the last on~ of the plural ^:
relatlons su~-blocks 614 for header block 612 ~hich may contain ~ : :
a valid pointer. EN~RIES field 1205 contains the number of con-,' tiguous plural relation su~-blocks 61g following header bloak ~12 which are included in plural ralaSion block 610, whethe~
l those sub-blocks contain poin~ers or not. SIZE.field 1207 and , . -the CL~SS field 1209 indicate, respective~y, the nu~ber~of j :::
I longwords in plural relation block 610 and that this header . I - :
block is a plural relation header block. ¦ :
I¦ BIT MASK f ield 1230 contains bits indicating which I :
2~ !¦ sub-blocks ~14 contain valid pointers. Thus, although the US~ I
~! field indicates the largest nuwbers o~ contiguous sub-blocks ~ --36- .~
Il . . ,',,.~
Il , . .. , ,' .

i 132.~0~
, which may have valid pointers, not all of those pointerS may 'l necessaril~ by valid. BIT MAS~ field 1230 supplies this latter information, ` ~! Plural relation ~loc~s are linked in a manner similar to ~ the linksge of element blocks for attribute data ob}ects having the same holder attribute d~ta object. Accordingly, header block 612 includes NEXT and PREvIOUS longword pointers 1210 and ~ -1220, respectively, which specify n~xt and previous plural rela-'. ~ion blocks in a selected order of such blocks. The plural re-l lation hea~er blocks in that order are ~11 used ~y the same :~
'I holder attribute data object.
! Figs. 13A and 13B shows block diagrams of preferred ~mbodi- :-m~nts of two kinds of plur~l re~ation su~-blocks 614. ~f the . .
,~ referent ~ttribu~e data object is an element attribute data ob-ect other than a strin~, num~er, or date, then, RELATION point-', er 1300 is a longword ~hich points to the ~lem~nt ~lock ~or that ¦ :
,l attribute data object. If the referent dttrib~t~ data object is ¦
a n~mber or d~te or a character string, then NUMERIC/S~RING .
field 1310 is used to point to a floating point number, or dat~, I
~, vr a block r~presenting a chara~ter string~ ¦
!¦ Creation and use of element ~lock 602 and plural relation 5 :-tl bloc~ 610, according to the te~chings of the present invention, are described in ~urther detail below. As can now ~e readily , appreciated, the data structure representations for attribute . ¦
, ~ile 600 discussed ab~ve embody the princlp~es of an Attribute , .
'1~ d2ta model according to this invention.

, .. , , ... ..... ,,, . ....... i.. , .j. .. .
. 1 ,. ,. ., ... ,. .... ~ ... . .
.. ,.. ~ . , " .. ... ....... ..... . .. .

.. . .... , .. ~ .. ; .... . ..... ..... ... . ... ..
.. . . .... .... i .. ,; ... j, ".. . ..... .
....... ,.. ~.. ,.... ,..... .. .... ... .. . ~ .

1~ 1 3 2 ~

I! ~he contents and structure of an instance root blocX are ~ ;
il sh~wn in Fig, 14. "Instances" of an element type refer to a set jI of attribute data objects all having the ~ame element typ~ and Il all having the same holder attribute data object. It has been , determined that such ~roups of ~ttribute data o~jects are refer~
enced often. Thus, the instance root block was developed to provide an efficient mechanism to aceess such attribute data ob~
jects. Locating instance root block-625 in attrib~te ~ile 600 , allows it to be dynamically updat~d more easily than if this lo il block were located in essentially read-only dictionary file 7~0. !
,~ Instance root block 60~ comprises a longword 1410 which in- ~ -.
I~ cludes a SIZE field 1413 and a CL~SS field 141~ indicating, re- ¦
,¦ spectively, ~he num~er of longwoods in root block 625 and that !~ block 625 is an instance root bloc~
il Instance root block 625 also includes FI~S~ and LAST point~
~! ers 14~0 and 1~30, respectively, which indicate f irst and last ¦ :
! attribute d~ta objects in any set. Preferably, point~rs 1420 ,~ ~nd 1430 id~ntify ~h~ locations ~f the element type blocks (.dis-'j cussed in a later sec~ion in relation to dictionary fil~ 70~) of ' those attribute data objects.

i An IN~EX pointer 1440 of block 625 points to an index ,1 directory bloc~ (described in detail bel~w) in attribute file ' i 600 which permits ready acces~ ~o each ins~nce of th~ linked , :
~ list of attribute data o~jects, the first and la&t object of ¦ ~;
I; which ~re 5pecif ied by pointers 14Z0 and ls3o of instanc~ root ~ : .
¦1 ~loc:k 600.

~, -3 ! I :
' n r7 132~0~3~
'~ (2) DictionarY File i! Fi~. 15 shows a block diagram of a preferred embodiment of ,j dictionary file 700. In the preferred embodiment, the portions ~ of the com~on database structure in dict ionary f i le 700 include an apex block 702, other context blocks 70g an~ 706, element . :
type blocks 710 and 712, attribute type blocks 714 and symbol . -table 716.
.' Apex block 702 is a special kind o~ contoxt block which represents the apex data object. According to the basic rules l ~ -, of the Attribute data model of the present inventi~n, the ap~x ¦
data object hiolds ~ontexts or attribute d~ta o}:~jectsr but is not ¦
itself ~ield by any cffntext or attribute data object.
Context blocks 704 and 706 are used to ropresent a context ,I such as CPU 420 described in connection with Fig. 4. Elem~nt , type blocks 710 and 712 each represent a di~ferent type Of ¦
attribute data obj~ct in attribute file 600. Prefera~ly, for , e~ch different type of attribute data object there is a corre~
sponding element type block. Attribute type block 71~ includeg ', inform~tion regarding the type of relations which exist betweon ¦ -i attrib~te data objects ~f a specified type and referents for ! ~ .
¦¦ these attribute data objects. Symbol table 716 contains ¦¦ identifiers for the apex, contexts, element ~ypes, and attributa ~ :~
~ypes represeni~ed in the dif~erent blocks o~ dictionary fil~
ll 70~. j -i! ~i explained a~oYe, apeX block 702 and context blo~ks 704 1 ~:
il and 706 are preferably stored in dictionary file 70~ because i . 1, .. -.
~' , ,, , ~'~' .i'~ , 'I ~'~.

~ 13~5066 , ~
¦ dic~ienary file 70~ is usually a read only file, Apex block 702 ~ :
Il and context blocks 70~ and 706, which are ~ery similar and will Il be disc~ssed together, are generally not modified and thus are Il primarily for a read only f ile. , ,-~
' Fig. 16 shows a block diagram for the basic structure and contents of the preferred embodiment of either apex block 702 or .
context blocks 704 or 70~. Because of the similaritiqs of apex ;
, and context blocks, only th~ file struct~re for c4ntext blocks 'I will b~ discussed with the understanding tha~ the f ile structure ~ -'! for apex blocks is similar.
iI In context block 704, longword 1600 includes a SIZ~ field 1603 and a CLA5S field 1606. SIZ~ field 1603 indicates the num- ¦
j ber of longwords of context block 704, and C~ASS field 1606 in- i ! dic~tes either that the ~lock is an apex block or a context J
.,l b~ock, i Longword or N~ME pointer 1610 identifies an entry in symbol I
1' ta41e 716 (see Fig. 14) specifying an identifier for the apex or ~
other context represented by block 7~4. i ;.
~ Longword or F~RS~ CONTAIN~D CONTEXT pointer 1620 points to 7Q 1l ~he first context block of a set o~ contexts which are held by ¦I c~ntext block 704. Poin~e~s 1630 and 1640 described below, are ,1 empty in apex block 702.
For context block 704, Longword or NEXT pointer 163~ points , il ~o the next context in the ordered set of contexts ~ust-~ .
~5 )I describec~. Longws:~d or HOLl~ER pointer 164~ points to the con- . -.
¦l ~ext block or apex bloc~ of the context or apex which holds the context for blo~k ~04.
''l .' , ,''' '`~

3 .
i - _ f~
il .

~ .", . ........

~, 132~0~ I
¦I Longword or FIRST OBJECT TYPE pointer 1650 points to ~ j .~ f irst one of an arder~d set of ele~ent type blocks, e.g., block~ ¦
~! 710 ~r 712. The element type blocks in that ordered set repre-i sent elemen~ types of attribute data objeCts held by the context : r~presented by context blo~k ~04. The ordered set is preferably a linked list as explained below in the description of element type blocks.
~' Longword or FIRST SYMBOL polnter 1660 identifies an entry in symbol ~able 716 which is designated ~s a first symbol for ,, the first of an ordered set of symbol~ for other contexts, ob- ¦
jects or relations h~ld by the context repres~nt~d by block 704. ¦ :
Preferably, the apex data object or a context attribute I da~a object provides the first or top portion of a containment ' tree. Access to an attribute data object of a specified element !
i5 I type in ~ context may be obtained ~y entering the containment tree through the dpex and by proceeding through the tree to the l 1-the con~xt in which the desi~ed attribute data object is found. I -~
I Bec~use the apex and contexts are represented by apex ~nd con- ! -.,-text blocks in dictionary file 700 in the preferred embodiment ~ :
. o~ the invention, entry into the preferred embodiment of the j d~ta structure through the apex or context requires acc~ss to ~¦ the information stored in-the apex or context blocks in d~ctio~
¦¦ nary file 700. In different embodiments according to this ¦ invention, access ~hrough a dictionary flle would not be re~
~uired.
,~ ' , . I ' ~! J
i.! . 1 ' :~'.

.. .. ~. .... . , .. ... .... , ;. -.-,, - . . , - .. .

1 3 2 ~ 0 ~
~ig. 17 shows a block diagram of a preferred embodiment of ' .
i an element type block such as element type blocks 710 or 712.
For purposqs of this description, element type block 712 alane ' will be deseribed with the understanding that element type block 710 has the same co~ponents.
For e~ch type of element in ~ttribute file 600, there ;:
exists an element type block 712 in dictionary file 700. In the ' preferred embodiment, the creation of an element of a certain . type in attribute file ~00 m~s~ ~e prec~d~d by a declaration io , tha~ elements of that type may exist. ~he mechanism for ~ep~e- , '~ senting the existen e of objects of a specified type is element ¦ .
" type block 712. ¦ ..
Element type blOck 7}2 contains general parameters for cer-'~ tain element blocks in a~tri~ute file 600, for example, info~m~
'~ tion regarding the length of those element blocks and informa- I
, tion regarding the instances of a given element t~pe. ¦ :
The contents and structure of element type block 712 are as j : -shown in Fig. 17. Included in element type block 712 is longword 1700 ~hich has SIZE field 1703 ~nd CLASS ~ield 1~0 ~0 ,~ As in the case with other data blocks, 5IZ~ field 17~3 indicates ~! the number of longwohds in element type block 712 and th~ CLASS
I! field indicates that block ~12 is an elemen~ type ~lock.
i~ Longword or ~OD~ FORM f ield 171~ indicates whether .~ at~ri~ute data objects of the type specified by element typ~ , `
2S '.' ~lock ~12 haye a predetermined order and wheth~r the elements of ~ ~ -~i tnis type are held by a context or held by other elements.

,,~ , -:
'~ -42-1~1 f~
! 1325~66 IlLongword or NAME pointer 1720 points to an entry in symbol table il 716 having a name or identifier for attribute data objects of ,I this type. INSTA~CE LENGTH field 1~30 specifies the length of , -Il an element block 602 for attribute data o~jects of the type ~, specif ied by block 712.
~- As indscated above, element type ~locks for typeS of attribute data objects contained by (i.e., in the containment tree for) the same context ar~ prefer~bly organized into ordered ' 'sets. Ln fact, these blocks are preferably linked using ~ longword or N~XT pointer 1740, ~hich specifies th~ next element j :~
~I type block.
Longword or ~ONT~XT pointer 1750 ~oints to the context block or apex block in which e~em~nts of ~he type sp~cified ~y ,i block 712 are contained. Longword or INSTANCE pointer 1760 ,I points to an instanCe root block in at~ribute file 600 whiCh contains pointers affording access to each of the instances of ¦ :
an element of this type in attribute file 600. The remainin~
field of element type block 712 includes longword or ATTRIBUT~ ' ;
,!pointer 177~. ATTRIBUTE pointer 1770 points to the first rela-,, taon typ~ for relation types contained by this element type.
i~ ~ictio~ry file 700 also provides a mechanism for speci- 1, Il fying the types of relations w~ich may exist between ~ttribute ' ::
;~ data objects of a type specified ~y an element type block 712 ', :: .
~, and thear referent attribute data objects. This mechanism in~
2~ , cl~des attribute type ~locks s~ch as block 714 ~see Fig. 15). ~, :
' ~..
':
,ll 43~

.' ~ , ~.
.~ , ', ' .:

. - - - - . ~ ... ... . ~ - .
-: .- : : .: . . . . -: ,. . .:: . : :

ll 1 3 2 ~ 0 ~
Fig. 18 shows a block diagra~ ~or attribute ~ype blo~k 714 ~ccording to a preferred embo~iment of the present invention. I
¦ Attribute type block 114 includes longwords 1800, 1810, 1820, ' -.
!1 1830, 1840, 1850 and 1860. Longword 1800 contains SI~ field ~ 1803 ~nd CLASS field 1806 which indieate, respectively, the num-ber of longwords in block 714 and that block 71~
; Longword or ~PSTYL~ field 1810 indi~tes the manner in " which relations for.attribute data objects are to be specified. . :~
Acc~rdin~ to the preferred embodiment of the present in~ention, V ,i rel~tions between attribute data objects and their re~erent ¦~ attribute data objects may be specified either directly or indi~
il rectly. For directly spe~ified or singular reiations, a rela-jj tion su~-block 606 (see Figs. 7 and l~A) in the element block ¦
l¦ 60~ contains the point~r for a referent attri~ute data object.
lS ll For indirectly spe~ified or plural relations, a plural relation I :~
I sub-block 614 o a plural relation block 610 ~see Figs. a ¦' and 13) accessed from the obj~ct block 602 for the referenced ,~. object cantains pointers to the re~erent att~ibute d~ta objects.
Longword or NAME pointer 1820 of block 71~ points to an I identifier entry in symbol table 716 ~or attribute ~ypo block 114. Longword or OFFSET field lB30 contdinS an offset from the be~inning of ~n element ~lock 602 for a relation sub-block 606 represen~ing relations o~ thi~ type, or an o~fset for a held elemen~ sub-block 608 representing elemQnts of thi~ type.
A~tribu~e type blocks ~1~ for a given element type ar~
¦l linked ~y me~ns of a NEXT pointer 18~0 in the manner described il j . .
,'~

, . - -. - . ,. , - ; ~, .: - ... : . ; . .. . :
- . - ,.... . - . ~ .. ,,: . . . . .
:, . ~ . . :
, . , . - - .. . . . . . .

132JO jl)() !
,~above for other linked blocks. Longward or ~OLDER pointer 18$0 poin~s to the element type block 71~ for the type of attribute ~ ~ata object w~ich holds the type of relation sp~cified by .attribute type block 714. Longword or REF~RENT TYP~ pointer 1860 also points to an element type block, but that element type block is on~ specifying the type of the refe.rent attribute data object~ in t~e event that attribu~e type block 714 corresponds to a relation.
; i . .
, (3~ Index File " ~ndex f ile 800 provide~ another efficient and direct means , ;
to access attr~bute data objects ~hich share a common holder attribute data object. Specifically, inde~ file ~00 provides a ' :
¦means for accessing certain ones of the attribute data ob~ects !j .
! to which unique ~ey values have been assigned. Z ;~
, In the preferred embodiment, index file 800 comprises se~
eral index ~ranch blOcks organized into at least one index i. : -~, having ~ tree structure. The branch blocks o~ an index include .,, leaf blocks each of which corresponds to a different set of ~he ~ key values. Each ~ey value for an attribute data object is in !, only one of the different sets of key values and, therefore, only one le~ block has a correspondence with that key value and , I the a~tri~ute data object to which that key value is assigned. . ~ -~
~eaf hlocks incl~de pointers, each of w~ich corresponds ~o ! a key Yalu~ of the leaf block and to th~ location in attribute ,, fil~ 60~ for the attribute data objec~ having the key ~alue as '~i its assigned key value. Quick a~cessing of a desir~d attri~ute , ``
!

132~06~ ~ I
data object i~ achieved by ~ntering an index with a key value for the desired attribute data object, and b~ locating a unique pathway through the tree structure of the index to th~ lea~ I :
; block having that key value and the corresponding pointer to the , -desired att~ibute data object.
Accordingly, in the preferred embodiment an index's tree structure includes a root block to provide an entry into the tree structure. The root block "branc~es~ to a plurali~y of ~t ; branch blocks each o~ which corresponds t~ a different, non-overlapping group of the sets of key values to which c~rtain leaf blocks correspond. ~he branch blocks are organized to pro- i vide a unique pathway from the roo~ block throuqh one or more , middle branch blocks to a sin~le leaf blo~k having a correspond- ¦
, ing set of key val~es for which the uniqu~ pathway exists. By organizing the root, middle branch and leaf blocks in such a ¦ :~
manner, the leaf block ha~ing a corresponding set of key values, I
which includes a key value for a desired ob~ect, can be loca~ed I :
expeditiously, In t~rn, the pointer to an attribute data object !
having tha~ key value as its key value can be quickly located, ~ ~.
Z~ ' as can th~ attribute data ob~ect it elf, ,1 ~he root branch, middle branch, and leaf blocks of an ind~x ,l¦ are prefer~bly represented by index branch blocks. Fig. l9 ! shows an in~ex branch block 810 which comprises an index branch ,J header block 820 and several index branch sub-~locks 830. ~ :
2~ ~ Fig. 20 is a block diagram of an index branch header bloc~
820. In the preferred embodiment, branch header block 820 ~ -46-.', ' i, ~ ' ' : ll 132~0~ I
! ' , ¦ in~ludes longwords 2000, 2020, 2040 and 2060. Lon~word 2~00 in-~ludes a BRAN~H KIND field 2004, a K~Y YALUES field 2008, a SIZE ¦
, field 2012, and a CLASS field 2016.
l~ BRANCH RIND field 2004 specifies whether ind~x branch block '.
s 810 is a root, middle branch, or leaf block. A KEY vALuEs field ~ -2008 indicates the number of key values speci~ied in sub-blocks 830. SIZE field 2012 and CLASS f~eld 2016, respectively, indi- . :
,', cate the number of longwo~ds in branch block 810 and that block -~
810 is an index branch ~lock, ' :;
~ Different index branch bLocks B10 ha~ng the same trunk I .:
! block are linksd through longword or ~XT point~r 2020 and ' longword or P~7~VIOUS pointer 2040, which point to designated 7 , nex~ and previous branch blocks for the same trunkr respective-i ly, Longword or T~UNK pointer 2060 points to the trunk block 15 i; for ~n index branch blo~k 81~
'1 In the preferred embodiment, index branch header block 820 ~ ~`
, is followed contiguously ~y one or more index branch sub-blocks , 830.
.l The index br~nch sub-blocks 830 sho~n in Fig. 21 prefera~ly ~1 include a longword or K~Y VA~UE pointer 2100 and a longword or ~ -,I L~,AF/OBJ~CT po~nter 2150~ XEY VALU~ pointer 2100 specifie~ a ~ . -, location ~t~ri~ute file 600 holding a key value.
If index block 810 is a leaf branch ~lOck, its LEAF/OB~ECT ~ :
¦ field 2150 points ts an element block 602 for an attribute data 2s ~1 o~ject in attri~ute file 600 having the key v~l~e denoted ~y the '~
'l corresponding XEY VALUE fiel~ 2100 in sub-block 830. Otherw~se, . , . , ' .- ':

~ 47 ~ t ~ :
't'~
',:

... ..... ..

Il 1 3 2 ~ 0 ~ ~ ' if the index b~anch block 810 is a branch block, the LEAP/OBJ~CT , :
, f ield 2150 points to a branch block in the uni~ue pathway to a ~1 leaf block, the set of key values of w~ich a~e within the group ~ ~:
'lof sets f~r that branch block.
In the preferred embodiment, each index branch block al0 is .
used either as an ordering index or as an acce~sing index. The ordering index is used to insert elements into a list according to prescribed ordering rules and enables quick access to the place in the list o~ elements, e.g., as ~escribed by an instance . root block 625 or a held element sub-blo~k 608. An accéssing j .
index is used to access existing elements quickly using a key ' value.
, In the preferred embodiment of the invention, ~oth the or- ! -I dering and accessing index re~uire ~se of index directory ~lock l 630, discussed briefly with regard to the constituents of ., ~
'¦ attribute file 6C0 (see Fig. 7), A block dia~ram of index ~ directory block 600 is shown in Fig. 22.
:' Index directory block 630 includes longwords 2210, 2250 and , :
' 2270. Lvngword 2210 includes SIZ~ and C~ASS field 2230 and ' :~
~l 2240, respecti~ely, which indicate tho numb~r of longwords in , ~ .
iI ind~x directory ~lock 600 and that block 600 is 2~ index direc- I
tory bloc~. ~ongwora or ORDERING pointer 2250 identifies the ~ :
instance root block for an ordering index, and longword or ' ~-l¦ ACCESSING pointer 2200 indicates a root ~ranch block for an -~-~I ~c,_essin~ index. '.
" . ~ .
.. . .
~. :
-48- . -, ' - 1. . ' i,~ . , .
. . ~ .

1 3 2 ~ii O ~
.1 Access to an index directory block 630 which designates in- , dices for q~ickly accessing attribute da~a obje~ts is obtained .~ either through an instance root ~lock ~25 or through a "held~
~ object s-~b-block 608. Preferably, for ~ttribute data objects ( held by a context, index pointer 1440 of an instance root block ~; 625 points to the index directory block ~3~ so that attribute . data ob~ects held by a specified context can be accessed easily.
For attribute data objects held by another attribute data ob .
ject, index directory block ~30 is accessed using the INDEX ; ~ :
. point~r 1120 of the "held~ object sub-block ~08 specifying des-ignated first and last ones of ~he held objects. The accessing operations are explained in greater detail below.
' D. Basic Database Q~erations ~, .
1 Using the preferred embodiment of the invention, certain ! ~:
' basic data operations such aS creation, erasure, and access, can ! be easily and efficiently carried o~t according to preferred method~ described below. ~e following description presumes ~ ~
i tha~, wh~ther by use of a compiler or dictionary 700, certain , ::-data like an apex or the contex~s which a~e necessary to ~he ' :
. ~ .
~ li cre~tion of attribute data object~, already exist in common data , ~, structures 140 or 14~'. It i5 also assumed that the elements ,~
,l and rela~ions to be created and the element types and relation !! types for the elements and relations to be created have already , -il been ~pecified ~o data structure 14~, so that the appropriat.e A_ ~ element ~ype blocks and referent type blocks have a}ready be~n .~ created.
. ~ . ~ , .
: :-ii . .
-49~ ' ',i ' . , '.~
I t '' "' 'l 132~0~
( 1 ) Element Cr~t~
¦! , , .
~ Figs. 23A and 23B show a flow diagra~ 2300 for a preferred '~method of creating an element d,~ta obj~ct ('1new el~ment") ;~ according to the present invention. As stated above in connec-:tion with the description of application programis 132 and 134, these programs either contain the information needed for forming common dat~ str~icture 140 in memory 120 or have thei~ databases alrady organized in accordanc~ with the Attributive data model , of this invention.
o . If the application program datab~ses need to be converted ' -. .
. ~o t~e Att~ibutive da~a model of this invention, She information i -~
needed ~rom these programs to create an element i~ in tho form of "node data.n A~tribute data objects to be create~ may corr~
'spond ~o node data from the application programs or may b,~ spe~
'cifically derived for creation. Accordingly, creation of an !
~ele~ent data object may in~olve the extraction of node data fro~
, an application program and a determination of the type of corre- ;
sponding element dat~ ob~,ect to be created f~om the node dat~.
. (S~ep 230~), Ex~mples of su~h extract~on appear in the next 2~ ,I sect ion.
on,e the type of the ne~ element has been determined, the ~l~ instance length, ~hat is the length of elem~nt block ~2 for the ,I ne~ elem~nt, can be determined by reference to the INSTANCE
~! LE~TK field 1730 of an e~isting elewent typs block 712 for the ~ ~:
". new ~slemen~ ~5tep 2310).
.,j :
r . ' ., ~ 5 0-- ~

,' ' i ~, .' ' "' ,-l 132~0~ !
,, Onee the instance length is determined, primary memo~y is 1.
checked to see whether storage spaco.is available for 01ement block 6~2 ~Step 2315). I~ storage space does not exist, then prim~ry ~emory space for that element block is created (St~p 2320). The details for managing storage space by CPU 110 in .~:
permanent and primary memory is described in more de~ail in a .
later section and involves virtual memory and mapping techni~ues ~
readily ascertainable to artisans o.f or~inary skill. . . ~:
After storage space for element block 602 in primary memory :~
~ is located or created, that space is alloc~ted for elemen~ block I :
602 for the new ele~ent (Step 2325). ~PU 110 then forms a '~ pointer to that allo~ated primary memory space (Stçp 2330) ! :
Next, ~ holder attribute data object is ~hosen for the ~ew ~ element such that a bein~-held relationship exists ~etween the ' new el~ment and its holder att~ibute data object ~Step 2335).
Selection of the holder attribute data object, allows FIRST, 5~ ~nd IND~X pointers, 1100, 1110 and 1120, re~pectively, in I :
nheldn object s~-block 608 o~ element block 602 for the ho~der , attrib~te data object to be located (stsp 2335). ' ~`:
, PIRST, LAST and I~D~X pointers 1100, 1110 and 1120, respec~
.! tively, may be ~pdated ~hen to reflect the existence of the new ' element as an ~lement now held by the holcer attri~ute data ob~
,' jec~. Of course, updating these fields is not necessary if the ~'i new elemen~ is not the first or last element held by the holder , :~
~ at~rib~te dat~ object.

., -51- ' -I, i :: ',...
,.......................................................... . ..

~l 132~0~
After locating the sub-block 608 pointe~s, ~EXT, PREVIOUS, and HOL~E~ pointers 925, gi0 and 930, respectively o~ element header hlock 604 in element block 602 o~ the new attribute data obj ect are used to link ths new element to the element blocks 'or the other elements having ~he same holder as that new ele- . :
ment a~d indicates the holder attribute data object or the new ~:
. element (Step 2340). ~his is done by locating H01DER pointer :~
~ 930 in ~bject header block 604 for the new o~ject. That HO~DER I -! pointer 930 points to a mem~ry area in which an e~ement block ~ 602 for the holder attribut~ data element of ~he obj~ct being .I created may be found. In addition, ele~ent pointers to other '.~ attribute data objects which have ~he same h~lder attribute data j , object as the new attribute data object are provided as N~XT
I pointer 9~5 and PREVIOUS pointer 940, If the new element is the !
~ only at~ribl~te data object held, no pointer will be provided in NEXT pointer 925 of element header block 604 and no object pointer will exist as PREVIOUS pointer 940.
Next, the FIRSI', LAST, and IND~X pointers 1100, 1110 an~ ' -1120, respectively, on the "held" elemen~ sub-block 608 of the ~0 Ij holder a~tribute data object, which have been previously locat-¦l ed, are updated to reflect the existence of the new element and li to re~lect its "being-held relationship with ~he holder attribute data ohject ~Step 2345). With r~gard to such ,l upd~ting, if the new o~ject is the first attribute data object 2~ !~ held ~y the holder attri~u~e data object, then a pointer to the !i element block ~02 of the holder attribute data object will be : !
1 -s2- i :
if .1 '' ' il 132506~ ~
, ~ .
', provided in t~e FIRST pointer 1100. INDEX pointer 1130 will ~ .

;,' also be up~ated to identify an index directory block 630 if '~ appropriate.
~, . .
~' To complete the creation of the new element in method 2300, other f ieldS of element block 60~ must be initialized. For ex~mple, TYPE D~FINITION pointer 920 of element header blo~ 604 for the new attrib~te data object must be pro~ided with appro- .
priate ~ointers, such as a pointer to ehe element ~ype block 712 ;
~ in dictionary ~ile 700 ~hic~ specifies the type of the new ele-lo ment. "~eld~ element sub-block ~08 and ~elat;on sub-bloc~ 606 for the new element are initialized for such time as.the new I attribute data object co~es to hold or comes to have rela~ions .. with other attribute data objects~
) Creatinq a Relat~n he steps shown in Figs. 23A and 23B are s~fficient for creation of an element data object. To create a rclatLon data . object, additional steps are needed. Figs. 2~A and 24B show a , :~ :
'~ flow chart 2400 depicting the steps involved in creating d rela~
j tion between the new ele~ent and a ref eren~ attribute data ob~
. ..~
2u jl ~ect. As indicated previously, node data descriptors in an ,1 application program database may be used to form a relation. '. ;-,, Alternatively, the relation may be formed by computations per~
¦ formed by one of the application programs. Thus, a node data ~ -,i descriptor from one of the application programs can be extracted .
. -..
,~ for u5e in creating a relation attribute data object. This ', extrac~ion function is described in greater detail below. When , 1 .
, -s3- ~ :

, .

132~0~6 Il ,11 extracting the node data descriptor, the appropriate ettribute data objec~ to be the referent attribute data object for the re-I lation data object is selected.
l Once the ex~raction and selection are complete, the ~ela- , tions sub-blo~k ~06 in the proper element block 602 is ~hen . :~ -identif ied (Step 240S). From the position cf the relation s~b-. block 606 in element block 6~2, the nature of the rela~ion between the holder attribute data and the referent attributq .
data object (i.e., plural or singular) can be determined (Step . " 2~10). 1 ,~
. If th~ relation is singular, a pointer ~rom the holder ~, ~ttribu~e data object to the refsrent data object will be pr~
vided in relation sub-block 606 of the element block for the ~ corresponding element. If the relation is tO be plural, a .' pointer to a plura~ relation block 612 will be provided in that , relation sub-b}ock 606. A referent pointer to the roferent data I :
~,' object will then be provided in the plural ~elation biock 612 ¦
identi~ied by the pointer in the element block 602 for the cor~
rasponding element.
l, If the new relation is slngular, a determ~nation must be made whe~her the relation sub-block 606 (see Fig8. 8, 10A and il 10B~ of th~ holder attribute data object already contains a ~.
~; pointPr (Step 2420). If this is also true, creation of the re- I
~l lation will be tempo-rarily halted while a previsus relation :~ specified in relation suib-block 606 is erased so that a new sin- .
guiar rel~tion can be created (Step Z~5). When relation ~ i ~54~
'I ~

32~0~
, I , ~
I s~b-~lock 606 does not ~ontain a pointer to a re~erent attrib~t~
,I data object, then a object pointer to the referent attribute data object for this relation is obtained and plac~d $n relation " ~ub-block ~0~ ~Step 2430).
If the relation to be created is not singular, then a plu- -ral relation block 610 is allocated for specifying the new rela~
.~ tion data o~ject, unless one has already b~en allocated ~Step -2435). A poin~er to the plural rolation block for the new rela~
tion is then plai~ed in~o the appropri~te relation s~b-block 60 ~ . -: .
lG ~Step 2440).
~ ext, the plur~l relation sub-~locks 614 (see Fig~. 8, 13A
and 13B) of the allocated plural relati~n ~lock 610 are scanned i R
as well as plural relation sub-blocks 6~6 in other plural r~la-tion blocks linked to the pointed to plural relation block 610 ~5tep 2445), As described above, plural relation blocks 610 , ;
are linked by means of NEXT and PREVIOUS pointera, so scanning p~eferably proc~eds using those pointers. ! :
If none of the scanned plural relation sub-~locks 614 are ' .. ..-~, fr~e (Step 2450), then d ~lural relation b~ock which contains a I free plural rYlation sub-block 614 i3 allocated (Ste~ 2455), A
~! sub-block is free if it does not contain a ~alid pointer to an , -.-'I object bloc~ 602 for a referent d~a object. The ne~ly allo- !
: ', cated plural relation blsck 610 iS then linked with the other !! plural relation blocks 610 for the new object (Step 2460~
'i ~ter the ~llocation and linking of ~ new plu~al relations ~. block 613, or if a free sub~block in one o~ the linked plu~al ,1 i '~-, , I , : .

.; . i - .

li 132aO~
,, relations block was located, pointer ~o the ~eferent data object ~
;¦ is ob~ained and placed in the fr~ plural rela~ion sub-block 614 ¦
o~ the plural relqtion blo~k ~10 ~Step 2470~. ~ext, or after 'I the pointer for a singular relation is obtained, the pointer for ' ` the referent is placed into one of the plural relation blocks ; 610. That block 610 is the one aecessed from the REFERENCES
pointer 935 of element header block 604 ~or the element blo~
602 of the holder attribute data object ~Step 2~75).
(3) i~his section describes erasu~e of all relations of a civen ¦
type held by a given element. Rel.ation erasure involve5 freeing I
the memory of space used to hold the pointers which relate an !
' ~ttribute data object to its re~erent attribute da~a object~ ¦
'' Fig. 25 shows a flow chart.2500 depicting the steps involved in the preferred me~hod of erasing a relation. I
.', First, the relation sub-block 606 used to rolate the rela- ¦
.' tion's holder attribute data obiect and referent attribute data ,' object is located (S~ep 2505) using the OFFSET 1830 of the rela- I
'l tion type. I
1! Next, a determination is made, according to the relation I
~! type, whether the relation i~ sin~ular (Step 251C). I~ so, the t plural rel~tion blocks 610 specified in the REFERENCES point~r.. , 'I 935 o~ the referent's element block 602 are scanned to ~ind the ~
'' object pointer to the holder attribute data obje~t for this re-2~ ' lation (Step.2515~ when the type is not numeric, a date o~ a 'I string. Then the object pointer to the holder attribute ~ata j ~,1 ;

'I -56-l !

- , ., ~ - .. ' - . !, - '!' ' '. ",' . : '.. . . .

:, ., ... 3 .. ', ,.. .'~: ., ' ", ,, , . , ,., , ., ,: , 132~0~
!l o~ject is cleared from the plural relation block pointed to ~y ;j the R~FERENcEs pointer 935 of the re~erent's element block 602 `I (Step 2520). Finally, sub-block 606 in the holder attribute data object which contains a pointer to the referent attribute : data o~ject is cleared along with any string data pointed to . (Step 2525), If th~ rel~tion to be erased is not a ~ingular relation, -~
then plural relation blocks 610 of t~e holder attribute data ob-.'. ject are scanned unless the referent ~ype is numeric, a date or ..
lo a string (Step 2530). The purpose of the scanning is to locate.
,i. ~he pl~ral relation blocks 610 accessed by th~ REF~RENC~S point- j ;
er of ths element block 60~ for the indicated referent attribute .
data objec~s those referent attribute data objects are the ones . pointed to by the referent point~rs in those plural relation l blocks ~10 o~ ~he appropriate type ~or the holder attribl~te data .
ob3ect of the relation to be eras~d ~Step Z535~. Next, th~ plu~
ral relation blocks 610 accessed by the R~F~ENCES pointer 935 i of th~se referent attribute obj~ct blockc are scanned to find a ' pointer to the holder attribute data object (Stop 2540).
ii When the pointer to the holder attribu~e data obj~ct is ¦I found in a plural relation block &10, the holder pointer to the , ~ :
referent attribute data object is rendered inoperative by re~
setting th~ corresponding bits in ~I~ MASK field 1230. Tha~ BIT
AS~ f ield 1230 is found in the pl~ral relation header blocks . -~.
~5 ' 612 for the plur~l relation blocks 610 in which pointers to the , .-', ho!d~r attribute data object pointer are ~ound. ~in~lly, t~e ~ ::
., . . .' . .
. -57~
i,i , ' '' 1 132~0~6 I ~
spa~ for plur~l relation blocks 610 which were scanned is re-i claimed along with any strinq data p~inted to and the r~lation ,i s~b~block is cleared (Step 25g5).
'~- (4) l~m~Er~sure ' Fig . 26 shows a flow chart 2600 descri4ing the steps by ~
whioh an element object is erased. After this element is ~ -accessed, plural relation blocks 610 for the object being erased , :.
are obtained from REPERENCES pointer 935 for the element to ~e ~ -' erased (Step 261Q).
,i Next, pointers to ~his element are erased from the plu~al ! rela~ion blocks under the elements acc~ssed from those plural .' relation ~locks (Step 2620~, ,I A~ter erasing these poin~ers, all singular and plural rela~
,' tions held by the element ~re erased (Step 2640) and space used ,, by any plural relation blocks associated with this element is ~ : -s also freed (Step 2~50). All element blocks ~eld by the element i ~
are ~rased ~y recursive use of this procedure. Ele~ents or ob- I :
' jects h~ld by this element are then erased (Step 2655). Next, ,s indices pointed to by the I~EX pointer 1120 in the olement 1 block for the ~lement being erased are freed (Step 2~60), The ¦ element block for the elewent being erased is unlinked from ele- ! :
i ment blocks for ~he other elements having the same holder ~Ste~
¦¦ ~670), Finally, space for the element is r~claimeid ~Step 2680~
!
Z5 'i From t~e or~anization of the pre~erred data structures I :
,~ deccribed above, as well as from the pre-~erred methods for 1! ~
il -58- 1 ~

,l 132~0~
I creating and erasing elements and relations also described I :
.~ above, different ways of accessing e.lements and relations wi~
, be apparent to persons of ordinary skill in the art, ~ccessing, I~, of course, depends upon the type of inform~tion desired, and th~
: data stru~t~re provided in the preferred embodi~ent show path- -- ways or such accessing.
~ig~res 27A and 27B show a flow chart 2100 describing a preferred method of accessing common data structure 140 or 140r to find either the elemen~s having a ~eing-held ~elationship ., with a given element or to find referents of certain relations o~ ~hat element. ~he procedure reflected by flow chart 27~0 may ¦ :
also be used to obtain held elem~nts and referents of relations ~ .
for multiple attribute data elements. ~he des~ribed me~hod is j - .
not ~he only such method, bu~ it is provid~d as illustrativ~ of - ~ the types of methods which can be used to ~arry Out the purpose5 ~
o~ this inven~ion. I :
Flow chart 2~00 assumes that during the creation of the ~ .. .
common data structure 140, a compiler or some similar sort of languae,e processing software (included in converter programs S~0 ~G ,,l and ~,70~ generated a virtu~l addr~ss or offset for each -~
il identi$ier. The flow chart further assumes that com~on dat~ ~ :
!l structure pl~ced that virtual ~ddress or offset in an addr~ss li , , ::.
~I table located in a co~mon area of memory 120 so it could be -:~
',' 3ccessed by retrieval programs, such as retrieval programs 580 ~5 .~ and S~O shown in Figures 5A and 5B. ~hose retrieval programs are preferably interpreters, but tkey could also b~ any ot~or ~:.
., type of lan~uage processinq so~tware, s~ch as co~pilers.
! ! -:

~ ' :

. . ~.. ,, ,r ~ " ;~ " ~ "

--- 132~0~6 Flow chart 2700 also assumes that prior to its execution, a virtual address for accessing a referent or held element of the given element has already been retrieved as have the virtual addresses of the attribute type block 714 corresponding to the relations or elements (collectively called attributes) to be fetched. The given element(s) will be referred to as the hold-er(s).
The first determination to be made upon entering flow chart 2700 is whether the relations for a holder of a given type are singular or plural (Step 2705). If singular, the next determi-nation is whether there is a first or next holder of the ele-ment(s) or relation (8) to be accessed (Step 2710). If there is no such holder, then a completion indicator is set (Step 2715), --indicating that the search for all the holders is complete, and the execution of the access routine is ended with a return of no result (Step 2720).
If there was a next holder, the offset field (e.g., 1830 shown in Fig. 18) from the attribute type block is then used to find the off~et from the start of the holder's element block to find a pointer to any element block for the relation or el~ment de~ired (Step 2723). The element block of that next holder is then retrieved by using the virtual address from the address table in the common area of memory 120 ~Step 2725).
Next, a determination must be made to see whether there is a re-lation or held element for this particular holder (Step 2730).
If so, (i.e., if the appropriate pointer i~ not zero), then the "
-' . '' ' ..
' ' .'"'.

.

!1~ 132aO~6 virtual address for the attribute type block of the desired ~ :
attribute is examined to ~ccess that.attribut~ (Step 2735), 1 :
When there is a non-zero p~inter, the information abo~t the desired referent or held element is r~turned (St~p 2745)~ :
; If the appropriate pointer is zera tStep 2730), then there is no relation or element of the required type in the element block of the next holder attribute data object. In this case, ~ :
. ;f a plurality of holders is specified, then a ~earch conti~ues . either until a holder is found with a relation or an element to be returned (Steps 2710, 2723 and 2725), or until th~re are no i ~ ....
,' more holders (Steps 2710, 2?15 and 2729).
- i ,, If, in the initial determination, the attribute type was ~ ::
'.' found to be plural (Step ~705), then a determination is made ,i whether execution of the access is first commencing (i.e., is ' the examina~ion of the entire expression commen~ing) or at lea~t j : ~:
" commencing examination of a new holder element (Step 2750). 1 so, then as with the single attribute type, the next determina~
. tion is whether there is some next holder (Step 2751). If not, the completion indicator is set (Step 275S), and a return is , ~ made with no resul~s ~skep 2760)~
~! If there is a next hold~ar, th~n the element block ~or that il next holder is retrieved (Step 2763), and t3 determination is ~¦ made from ~h~t element block whether there is a relation ~lock ,l 610 or a first held e~ement for the next holder. ~'his can be , de~ermined by examining the element block ~or the next hold~r ~ ~Step 27~). If no attribute exists for the nex~ holder, then ., ~ .
-6~

"

-:

132~0 !
isubsequen~ holders are obtained and examined until ei~her a , ~
.,holder is obtained which has an attrlb~te (Steps 2751 and 2763) , :
or until there are no more holders (Steps 2751, 2753 and 2760). '.
,, From the attribute type block, a determi~ation is made whether those attri~utes are r~lation.~ (Step 2773), If so, then the next relation is retrieved fro~ the corresponding plural re-~- lation block (Step 277~). Associated with the ~c~ess of this plural relation block is a "place indicator~ which keeps track of the next one of the ~elations from the plural relation blocks , ~ to be accessed. This is done because the routine in flow chart 2700 only returns one result in each access. When the last re- , , lation from the plural relation blo~k 610 is obtained, ~he ~ :
,, nplace indicator" directs that the next in~uiry into the exis- I :
.' tenee of ~ relation or an element t~ be obtained be answered in , .
~I the negative. Each time a relation is obtained, the "place in~
,~ dicator~ is updated to the next.position, and a return from the ! ~ :~
.. . .
.~ procedure is m~de witn the indicated result ~Step 27~0). 1 -If the desired attributes were instead found to be ele~ents or if the examinat~on was not co~encin~ ~Step 2773), th~n a , determination would be made whether that element was the first in a linked list of elements having a being-held relationship ~, with the holter (Step 2783), If not, then the next held elemen~
is obt~ined using NEXT field 925 from ~he element accessed imme-., . ~ . .
~ ~iately prisr to the prese~t element (Step 2786). A different Z3 "~ nplaee indicator~ which keeps track of tn~ n~xt associated one , of the e~ements to be accessed is updated to point to the next ~i ., .
~, . . .

' ' -~ 132aO~
of the held objects. The return is then made with indicated result (Step 2780).
If the desired element was the first of the held elements (Step 2783), then the held object block is obtained using the offset pointer and the holder attribute data object's element block, and the appropriate place indicator is initialized (Step 2790). The return i5 then made with the indicated result (Step 2780).
Figure 28 shows another example of an access procedure. The flow chart 2800 in Fig. 28 is used for finding an attribute data object using the index file 800 and a key value. Again, it must -be remembered, that flow chart 2800 is only one method of access and is not meant to limit the invention. `
When using a key value to identify and find an attribute data object, the index directory block (see index directory block 630 in Fig. 8) is searched for that key value tStep 2810). If that key value ic not found (Step 2820), then a return is made from the routine in Figure 28 with no result (Step 2830). `~
If a key value is found, then an index result block 2890 shown in Fig. 28A is created with four longwords set to the fol-lowing values (Step 2840). First leaf node 2891 is set to the pointer of the leaf index branch block 810 containing the first occurrence of the desired key value. First leaf index 2892 con-tains the ordinal of the index branch sub-block 830 in the index branch block 810 which is the first occurrence in the leaf index branch block. Similarly, last leaf node :'' ~ ' ' ;r i i1 132~0~6 2893 and last leaf index 2ag4 contain a pointer and o.rdinal, re- , :
spectively, for ths~ l~st occurrence of the deslred key va~e, ~'Index result block 2890 is a temporary data structure cr~ated , ~lonly ~or access using index file 800.
Next, the address o~ the desired element(s) is found using index result block 2890 (Step 2850). If the key is unique, then : first and last occurrences are the sSsme. If the key is not - ;
,unlque, as may be the case for the ordering index, then the com- - :
.- plete set of valid results can be found u5ing the index result ~ block 2890 because the index branch ~ilocks are linked. ~he .' pointer to the attribute data objS3c~ i5 found using the r6sult 1 :~
.I block.
If the key value is found, it wili ~ontain an address in the attribute data f ile 600 for a corresponding attrib~te data ' :
. objeet. A return from this procodure is then made with the in- I :
dicated result (Step 2860).
E. ~ i, : -In accordan~e with this invention, the information us~d by ' :
~ application p~ograms such as program~ 530 and 56C shown in ~'ig-,' ures 5~ and 5B, must be f it into an organi2aticn of coNmon data i structure 140 lor 14~' ) . In many cases the application progr~ms ' are previou~ly written in terms of their o~n databases, and in . I .
jl s~ther case3 application programs may already us~ attribute data ' :.
! objects organized in accordance with the present invention. ~ ::
~,~he process of extraction and conve~sion refers to the methods by which data ~rom application pro~ram databases ~r~

i~ -64- ~ -.. ' ' ~:
' ::

converted to the common data structure 1~0 tor 140'). As shown in Fig~res 5A and 5B, converter progrsms 540 and 510 ta~e data Erom the application databases and convert that data ~rom th~
forma~ in those databases into a ~ormat proper for ~ommon data structure 140 (or 140').
There are several w~ys to organize a common data struct~re aceordin~ to the present invention for each application program database, The organization and conversion of the application program data for the the common data structure likely depends upon the contents of the data in the application program database, as well as upon the antieipated usage of the common data s~ructure.
Organization of the com~on data structure, and ~onsequently extrastion and conversion, need not follow a~solute and unwavering rules, Instead~ t~is section contains some general guidelines and design considerations for persons desiring to practice this invention. Additional guidelines and design con-siderations will be apparent to persons of ordinary skill in the art, without ~ndue experimentation, fro~ the entire description of the pr~ferred embodiment s~ch a~ the construc~ ion of the pr~-ferred data structures and the pre~erred methods of access, cre-a~ion, and eraSure.
Quite oft~n, the first conc~rn in building a common data structure according to this invention is the selection of ~le-ment data objec~s. The information in th~ application program from which ele~ent data ob3ects ~re often selected can be i - 132~0~6 1 .. . .
referred to as node da~a. Node data generally includes "things" ,' :
~hat ~re either "objects~ or "subjects" in the databa~ie. In terms of parts of speech, t~erefore, ~lement data objects are most li~ely data th~t would be described ~y no~ns. For example, node data can include physical objectsj such as circuits, gates, .
portions of an engine, or persons. No~e data can also include e~ents, such as time line entries or ~iling dates. Another example of node data are concepts, su~h as ideas and colors.
Once the elements are selec~ed, then the holding relation-, 1~ ' ships between elements are e~tablishsd. The determination of ~ -.
holding relationships usually reflects some hierarchy among the , elements. As with the selection of elements themselves, the determination of the hierarchy r~flected by the holding rela~
' tionship is, in most cases, not unigue. Preferably, the deter- ¦
mination of the holding relationship $h~uld also ~ake into . account the anticipa~ed use o~ tha data. The existence of a re- I ;
.
atlonshlp between two elements (or between an element and a re- , .
lation) does not necessarily mean that su~h a rclationship ~ :.
should b~ reflected as ~ holding relation~hip in the common data ' 2~ .I structure. ~hat relationship can also be represented by the ', ~ nonhier~rchical relationship indicated by the .relation data ob- !
.l jects, The types of relationships which aro most often reflected ~l in the holding relationship reflect some natural hi~rarchy, s~cn , ~i5 ' as officers ~ a corporation, or refl~ct the constituent parts - ~' of a thing, such as ~he parts o~ a machine, the chapters of a ., ; .
:
.~ . ; :
! --~6- , ~ .

1 132~0~S
~ook, or cities in ~ state. The holding relationships can also ¦ reflect the possession of one thing by another. ', Once the holding relationships are determlned, however, a '.
', context must ~sually be selected. As explained in an earlier ; section, t~e context is a construc~ to help in na~ing attribute ; ~:
. data objects since the names of s~c~ objects have meaning only in the context holding thcse objects~ The context should b~ . -used to refiect groupings of rela~ed attrib~te data objects for ~. convenience of reference and to allow the use of specialized ~o-~I cabulary. For example, design infor~ation about printed ci~cuit ¦ :
. boards ~ig~t be organized into a different context from design ,1 information ~bout V~SI chips, so that terminolo~y famili~r in ',' either application area can be used without ~on~llct. In the ' example demons~rated in Figs. 3 and 4, the term "gat~ ~an hav~ ¦
ii different meanings in these two application areas. ~he use of ,'~ separate c~ntexts allows the same term "gat~" to have di~ferent I ~.
~I me~ning in each context.
,~ Qne can also have seYeral lay~r~ o~ contexts. For example, ''~1 a first context ~ay contain objects related to general applica-,j tion eonceptæ such aS ver~ion tracking and project management. ' :~
¦¦ ~ach of a plurality o~ contexts held by the first context might Il contain attribute objects for particular technologies, such as ¦~ mechanical or electrical. . ~ :
¦~ Relations are usually determined next, After the node data , '~ are assigned as elements, the in~orma~ion remaining usually con- , cerns th~ relations or attributes of such node data which, if -67~
,'1 ' . . . ..
i ":

132aO~
nctt ref lected in ~he hierarChiCal hold1ng relatioships, can kte '1 thought of as gens~rally reflecting dt3scriptors of the node data. , .
¦I The purpose of the relations is to reflect nonhierarchical rela- ' 1 tionships that exist among attribute data objects. Srhe rela- :
, tions are cr~ated so that they S~ssoS~iate the appropriate objects , in order to refles~ the relationships between node data and their descriptors as expressed by the origi~sal application data.
Examples o~ node data doscriptors, preferably represented by re- ;
~ lations~ includ~ the conn~c~ion o~ gates to signals, the identi- , , ication of the designer o~ a circuit, and the connsction of ,i events in a project plan. ¦ -',J The final steps of data organization involve typo ~etermi- j ~
'i nation and selection of key values, ~rhe ~typing'' of an 1 ~ :
,1 attribute generally follows the designation of elements and re~
'', lations, as well as the designation of holding r~lationships. I
.I The types generally reflect the sets into which the elements and l :
jS
! relations have already been grouped and describe the com~
~I monalities of the elements or relations in those sets. ¦
.~ The selection of key values depends again on the data. ~he i ;~
ll use of key values is pri~arly an aid to access, so the d~termi~
!I nation and selection of the keys ~ihould ~ollow the anticipated . usa~e of common data structure 140 or 140'~ In addition, the ! ~s~ of key values may ref lect an ordering of the infor~ation in - ¦ the application programSs databases to facilitate use of such in-'i formation by.the application programs.

E , ~ ~

68- . I

, . -... .. .. . ' '. ' ~

13 2 ~ O ~ 6, he details of converter programs 540 and 570 are specific o the requirements of applica~ion programs S30 and 560, respec-~', tively, the following example of the processing performed by .' su~h converter programs is provided to illustrate the guidelines ~ provided above. rf an application program 560 generates the circuit shown in Figure 3, file 565 (Figure 5A) might contain ; the following information descriptive o~ the circuit.

1) ADD 3-I-A; ~20;
2~ ADD 320.322~S2 . ::
! 3~ 320.324 , ~) 320,326 ~, '~' 5) 320.328/Sl ;j 6) .!
,' 7) A~iD 2-I-A: 33~; i .~ 8) ADD 330 332 .' 9) 330;334/Sl ~, :
~' lO) 33~.33~/S2 .I :~

,', Each non-blank line of thiS file repreSents a node datum. ~ -:
~ Line 1 ~alls ~or the c~eation of three-input AND gate 320.
'~, Lines 2 through S call for the creation of pins 322, 32~, 3~6, ¦ `
and 328 of gate 320. Line 7 calls for the creation of two-input i , AND gate 330. ~ines S ~nd ~ in~i~ate that pin 328 is conne~ted to pin 334 by signal "Sl." Similarly, lines 2 and lO indicata . that pin 322 is connected to pin 336 by signal rS2.
2.5 i Con~erter proyram 570 could be designed tO read file 565 ,~
an~ create common data structure 140 or 140' repr~senting the circuit of Figure 3 using operatiC-ns described in the proceeding i .¦ sections. Part of the common data structure so created is shown ', ~, in ~igure 4~. ~ach o~ the "t~ingsn ~i.e., gates and pins or sig- ! -nals) is an element. The holding relationships represent ~Xe !
,1 -69-'I . I ' ',' ,, ': ' ' , ' , . . .
. ,, :. . .: - . , . .'. . ' 132~0~
hierarchy implicit in the creation -- ~irst the AND gates, then the pins or signals. The ~e~aining rela~ionships, such as sig-l nal connectionS ~nd names, are created as relations.
:' F- 5L~9 As may be expec~ed, the amount of storage.required ~o im-plemen~ an embodiment according the present invention can be quite great. This section discusses a pref~rred embodiment af a , ~ .
, storage management technique for maintain~ng/ ~dating and ', . accessing common data str~cture 140' in order to achieve bene- I -!~ f its s~eh as a redution in the am~unt of req~ired stora~e. ¦.
i This preferred embo~iment of a storage management technique i~ 1 ~
l also designed to provide an easy and effici~nt me~ns of l .-,j accessing and upd~iting the da~a structure 1~0' of memory 120 by 'I application programs. . j ;
lS 'j The descrip~ion of the storage management te3chnique i5 j ';
,, based upon the representation of the system show~ in Figure SB ¦~
~ shcwing common data structure 140' as including a copy of master I
., data file 515/ snapshot data fil~ 525, and control file S55 with ~
i locks 568 ~nd S~9. Storaga management software 566 controls tho i .
l, ~iles in common data structure 140'.
A block diagram of an embodiment of common data structure ~1 140' is shown in greater detail in Fig~re 29. Pigure 29 in~
j, clu~es a master data file 2~00, ~hich corresp~nds to mast~r data 3 :
rile 515 in Figure 5B. Master data f ile 2900, shown as ~5 ', including macropages 0 - 3, corrasponds tO the most recen~ ver- , .. - ~, s;on of the common ddta structure 140'. That most recent ii : `

~i -70- ~
il . ~: --i !:
' l i . -..

.,. , . ;. ;, - ~ -' ~ ' " ! .~ ! ' ~ ' ' .
_~ I ~ ,~
132~;0~
version is either the version currently being modifie~ or th~
i o~e which was most recently modified..
`i As Fig, 2g shows, each macropage in m~ster data file 2900 has an associated nu~tbered entry composed of two p~tions. The ,.
larger number of an entry refers ~o the ma~ropage n~mber and the : superscript portion o~ an entry refers to the version number. . .
The version number indicates a version of the da~abase as up- j dated by a ~ingle user. In accordance with the pref~rred 1 :
embodiment, newer vers ions always have a higher number than 0 J older versions. The total number of macropages depends on the .
' to~al size of the da~abase.
,l Snapshot data file 2910 corresponds to snapshot data fil~ i 525 in Figure 5B and includes several slots 0-5. Each slot con~
tains a macropage and corresponds to one of the macropages from ¦ -.
1 either the current version of master data file 2900 or from a ¦
pr~vious ver~ion of that file. The macropages from previous I :
, versions of the master data file 2gO0 still main~ain~td in snap- I
. shot file 2910 are for versions which are sti~1 active. A ~er- j . sion is still active if there is at least one application pro-2~ 1~ gr~m vr user which is currently a~ces~ing macropages of that ver ion.
~he numbered entries associated with each macropatge in ~I snapshot dat~ f i le 2910 include as the largor nu~TIber a value fs:~r , - ~ .
Il ~he corresponding macropage in master da~ca file 2~00, and in- , . .
?5 ~ clude a~ a supers~ript a number indicating the version of that I macropage~

, ., -71- . .

i ... ,:.,. :. ,.- . :- -:: ~ . ~

Il 132~0~
. After mast~r data file 2900 i~ updated, those macropages "I from the master data file 2900 which were changed are ~opied ¦, into slots of snapshot data file 2910. This copying accounts ,~ for the multiple versions of ma~rop~ges from the master data ` fil~ 290Q which are stored in snapshot data file 2910. The sn~pshot data file must not grow indefinitely, so housekeeping routines, which are explained in greater detail below, are in-vo~ed to remove outdated m~cropages.
, Certain of the slots of snapshot data file 2~10 are lh ' referred to as a "natural slots. n A ~natural slot" refers to a ~ ;. .
~1 slot in snapshot data ~ile 2910 having a slot num~er which is ! --,il the same as the corresponding macropage num~er. Thi~ is the ¦
;, state of sn~pshot data file 2910 when it originally receive~ the j eontents o~ the master data file 2900, This initial state, in " . . ...
l~ . which all the macropa~es are in their natural slots, is desired !I for eff iciency, ata Base Controller ~D~C) 2920 controls the storage man~
. a~ement f~nctions. ~C 2920 corresponds to the control file 555 , i in ~igure SB. In general, DBC file ~20 con~r~l~ the modifica~
~ tion of data structure 140' as well a~ the access to that data , str~cture, DBC 292~ controls the modification of data structu~e ¦ ~-l4g' by managing and keeping track of changes to the data struc-i ture and by ensuring, through the use o~ ALT~ loc~ (See Fig.
~i 5B) that only one user can make modifi~ations to a version of a , -, macropage of the data structure. DBC file ~g20 controls access ! to the data structure by keeping track of the location of all ' ..... ;
''~ ' , ': :`.
-72- i ~
!:

,........................... . .

., .. , , i ., , " . - . , . , . ~; ... ` ;, - `

Il 132aO~ I
~ctive macropa~es and by preventing collisions with ~ertain ! users thro~gh the use of DBC loc~ (See Flgure 53).
! ~BC 2920 contains four major components One comp~nen~
, pointer~counter section 2g22 which indi~ates where the oth~r . I
I por~ions o~ ~BC 2920 reside. Another component is HASH table 292~ which provides a means for loi~ating the acti~e macropages in snapshot file 2910. .Version ~lock section 2326 contains ver- .
sion blocks, such as blocks 2930, 2940, and 2950, which contain , .
, information about different ve~sions of data structure 140'.
,. Switch block section 2928 contains section blocks, exa~ples of , :
which are 2932, 2Y3~, 2936, 2~38, 2942, 2944, 2952, 295~, 29S6 l and 2958, wh~ch contain information about the active ~.acropages.
i Preferably, different kinds of switch bloc~s are used for . changes in ~ttribu~e ~ile 600 and in index fila 800. If, how-" ever, the information in attribute file 600 and index file 800 `~i resided in a single file, one kind o~ switch ~lock would be ¦ .:
~" nePded~ In the ensuing discussion, the discussion about switch j : -blocks applies ~o changes either in attribute ~ile 600 or inde~
.~ file 800, ¦ ~igure 30 shows a preferrèd embodiment of pointer~counter sections 2922 in greater detail. As shown in Fig~re 30r point-i er/cou~ter section 2922 prelsrably contains a user count 3005 I and several other ~ields and pointers. User count 3~0~ indi- ., '.l cates the total number of users which ar~ accessing or m~di~ying , ~-~¦ common daita str~c~ure 1401. Each time a new user ~ants to ~l acce~s common da~a structure 140', the storage management ~ -~i ' I . .
! ~73~

~ - ~ ~
~: ~ ~ i ` 132aO6~ 1 !¦ software obtains the D~ lock, increments user count field 3005, ¦ :
~nd r~turnS the DBC lock. The purpqse of the DEiC lock in this , instance is to prevent multiple users from simulatan~ously ' :
!! accessing the user count and improperly inc~ementing it..
Rollback version nu~ber ~ield 3010 and roll~ack version ~ --~ p~inter 3015 refer to a rollback func~ion. ~his function allows ~
a user to retract certain changes made to a version of common ~ -. . .
data structure 140'~ Rollback occurs onl~ while changes which ~ 11-`I are being made to common data structure 140' by a user are still , lo '. in pr~gress~ Rollbaek o~cur~ ei~her because the user performing the changes ~voluntarily~ deci~es lt does not want to proceed 5 wi~h the changes and wishes instead to restore master data file .
~, 2900 to its state before the modifications start~d, or b~caus~
'I an error makes it impossible to complete the ~hanges. ¦ -15 ~ In the preferred embodiment, the version being roll~d bac~
.1 îs fully modi~ied in accordance with tho changes specified by ~! the user~ The storage management and updating steps described j ~:
' below are executed, but this to-be~rolled-back version of coi~mon ! - -~
' data structure 140' is not made avail~ble to o~her use~. Imme-li diately ~ter the to-be-rollèd-back version has been created, a ¦I new ~rsion, the roll~ack ~ersion, i8 created. The rollback i, .
l¦ version, by use of switch blocks in section 2~?8 and snapshot ~-¦¦ d~ta fi}e 2glO, undoes all the changes brought by the to-be- ~ :.
5~ rolled-~ack ver~ion. Accordingly,.a~ter the roll back thg mas~
~5 ,j ~er data file 2900 fo~ the rolled back ver$ion has been returned '~
¦ to its state before the roll back sequence was initiated.

- - , . - - ~ . ... , - ~ .. .. ~ . .. ,- , .............. .. .

, - ,. - ". : ~, .. : . ... .. ~ : ., .: ~ ., .,: .. . .. -Il 132aO6~ l ~
i~ Snapshot data file 2910 is not returned to its state before i creation of the to-be-rolled ba~k master file 2gO0. A~ter roll I back, snapshot data file 2910 contains two additional version~, 'I the "bad versiOn" that was rolled back and the new current ver-~ sion. As stated above, however, users-are not able to read the "bad version," and the new ~urrent version is just ~ ~opy of the , . macropages initially changed by the nb~d version. n The ~ad . version~ is already obsolete ~t the completion of roll back and will ~e deleted by ~ouseke~ping r~utin,~s to be described later. ~.
In pointer/counter section 2922, roll back version number 1ii 3010 refers to the number of the version whiCh is ~rolling bachn i ., the "bad version" and ro}l back version pointor 3015 points tO , ~ ~.
I the version block of that version number. ¦ .
~ ~ext version number 3020 and next v~rsion pointer 3025 in '' section 2922 refer to the version of common data s~ructure 140' fl ~hich is either currently bein~ updated or, if there is no ver-i sion currently being u~dated, which will be the ve~sion to be 7 updated next.
Current version number 3030 and curre~t vers~on pointer ~ i 3035 refer to the most recent version which i~ currently r~ad- ' ,1 able~ This is the most currant vorsion which is available in , ~-il snapshot data file ~910. The oldest version number field 3040 !l and ~he old~s~ version poin~er 30g5 re~er to the the active ver-!~ sion which is the least recent ~ield 3~0 and pointer 3045 are ~
~5 ,l, changed as common data structure 1~0' is being updated and obso- !
'ete (i.e., inactive) versions are ~reed. I ~ .

, j ~ , '~ I
i,. . 1 '~

I ¦ 1 3 2 ~ o 6 ~ ~ I
The initial version number 3050 refers to a verSion of com- i mon da~a structure lgO' existing at the time an event referred to ~s a "checkpoint" occurs. For purposes of error recovery, 1I the contents of common data struct~re 140' in master data file ' 515 are replaced with a checkpoint. This ~checkpoint version"
may be used to continue operation of the system ~fter the loss .`
. or destruction of part or all of the data structure lgO' con~
' tents. `
,' Initial version number 3050 indicates the newest v~rsion in ,~ sn~pshot data fil~ 291~ when the most recent checkpoint oc~
~I curred, j :
,i HASH table 2924 provides a meAns for accessing the ac~ive I .
, macropayes in a manner described in greater detail ~elow. HASH
~t table 2924 is prefer~41y a standard HAS~ Table and thus will not .~ ~e described in any further detail. HA~H Table 2924 preferably Il contains pointers to the switch block correspondinq to the most i, recent Yersion of each ~ac~opage. As d~scribed below, each ! ~:
. switch b~ock is linked to its earlier versions. Thus, by enter~
I ing thro~gh HASH tabl~ 2924, a user can locate every active v~r~
~I sion of each m~cropage in snapshot data ~llo 2~10. ~ersion area ¦ 2926 preferably includes a plurality of version blocl~s 2930, 294~ and 2950 shown in Fig. 29. ~ach one of those ~ersion I ~ -blocks preferably contains the fields and poin~ers shown in ver- j .
~i sion blo~k 3100 ~f Fig. 31. . ~ :
2s l~ version bloc~ 3100 includ~s a version numb-r fi~ld 3110 ~I which identifies the number of the version to which version I.
,~ . '. .'.' '. .. :

I~ -7~
~ .''- ,.

.

. . ..... -., -.. ,.. , . .. ~,. .

1 132aO~ ' block 3100 pertains. This field is also shown schematically in ig. 29 by the numbers 1, 2, and 3 a~ the top of version ~locks 2930, 2940, and 2950, respectiv~ly.
~! Version use-count field 3120 refers to the number of users .. c~rrently accessing ~he version corresponding to version blo~k ~ 3100. Each time a user wishes to initiate a new version, v¢r-; sion use-count field 3120 of ths current version 3120 is incre-mented by one. When the ~ser finishe~ with the version, ~ se-count field 3120 is decrom~nted by ~ne. ~he purpose of the .~ ~ersion use-count 312~ is to identify versions which are no t . longer being accessed so that the m~cropag~s of that ve~sion can l , be replaced if newer versions of master data file 2~00 become il availa~le. .
., Newer version field~3130 points to the ve~sion block for ¦
', the nex~ most recent version of the m~ster data file 2~00. ~he , pointer in field 3130 effect~ a type of linking shown schemat- , , ically in Fig. 29 as version block Z930 points to version block ' 2940 and version block 294~ points to version block 2gS0, .' Relat~d to newer ver~ion field 3130 is older version field ~, 3140 whic~ points in the opposite direc~ion to the vorsion block for the next version of master data file 2900. ?hus the linking .
¦ ~etween version blocks is bidirectional. As demonstrat~d in .
Fig. 29, version block 2950 points to ~ersion block 2940, which , . in t~lrn points to v~rsion block 2930.
~1 The version last changed fiela 3150 contains a poin~cer to ~ the m~cropageS for the corresponding ~ersion which was first , . ... .
~j _77~

~ . . ' ' ! , . ~ ' ' ~ , . .
Il 132~0~6 I ::
!~ changed most recently. The fun¢tion of this field is expl~ined I .
I in greater detail below, but as a brief expl~nation, the first I ~.
Il tlme a m~cropage is changed for a particular version, a "nex~
I! updated field" of that ~cropage is changed to contain the con~
,I tents of version last changed feld of the version block 3100, ;. and YerSion last changed field 3150 of version block is changed to point to this maeropa~e. ~ersion last changed ~ield 3150 of ~i verslon block 3100 is initially set to zero. The flrst ti~e ', each macropage is first c~anged, it is link~d to the he~d of a lo l¦ list of macropages changed in this version. The version last j! ch~n~ed pointer thus p~ints to the macropage that was fi.rst changed most recently.
~¦ The reason for this procedure is efficiency in data opera- ¦
',1 tion. When a new macropage is first modified, it is v~ry possi-1~ ¦i ble that the macropage modified next most recently has ~en ,¦ placed back on disk to save space in the primary memory, rt ~! would be inefficient to retrieve this macropage from disk merely l -: ,~ to update one pointer. It is instead easier to update the co~
I! responding field of veraion block 31~, since that version ~lock j 1~ always resides in primary memory, i ~
A first attribute switch ~ield 3160 and a first index I .
swit~h field 3165 point to the switch blockQ for the attribute and index files, respectively, ~hich wer~ the first ones created ~

! for the corresponding version. Of course if the attribute and i . :-:
~5 ~l index files ~re combined, then only one of these fields is noc~
ssary.

, 13250~ ~
I~ Completing version blo~c 3100 are our ver~ion initial .~ macropage number fields 3170, 3175, 3180, and 3185. The initial i ;-attribute macropage number field 3170 identi~ics the llighest ~, macropage nu~nber for the master data f ile 2gO0 corresponding to : attribu~e file ~ûO at the start of that ~fersion. For the exam-ple in Fig. 29, the number in f ield 3170 wo~ld be 3 . The ini- :
t iel snapshot macropage number f ield 3175 contains the highest macropage nwnber in sn~p-~hot file 2910 for attribute file 600 at the start of that ~ersion. In the example shown in Fig. 29, this f ield would contain the numb~r 5.
~he i~itial index macropage number file 3180 and ~he ini-.~ tial sn~pshot index macropage nu~ber field 3 85 have functions . --equivalent to thoss of fields 3170 and 3175, but relate to mas- !
. ter data and snapshot d~ta files for index flie. 800~ .Th~ maste~ ~ -, znd snapshot da~a f iles for index f ile 800 are not shown but are I ~
~ i , preferably identical to the master and snapshot data files for ¦ .attribute file 600. Of course if the index file 800 is combined with attribute file 600, fields 3180 and 3185 are not needed.
The switch block section 2928 in d~ta~ase control file 29?0 , 1l in~l~d~ the switch blocks, such as blocks 2932, 2934,. ~g3~, l~ 293~, 2942, 2944, 2~52, 2954, 2956, and 2958 shown in Fig. 29.
!. I :
l~ Switch blocX 3200 in Fig. 32 is an example of such switch ~ -'i blocks. ~he preferred embodiment of switch ~lo~k 3200 applies ' -'' to switch blocks which are for att~ibute file 600 as well as 2i inde~ f ile 800. If there ~s a single attribute~index ~ile, ~ there is only one type of switch block.
~ - .
,~ . j ~ `. :.
, -79- j ~
i: :

:, -.~ .

132~0~
.'` Switch blo~k 3200 includes a versi~n number ~ield 3210 , which identifies the version number for ~hich that s~itch block exists. This number is also shown in repr~sentative fashion in ' Fig. ~9 b~ the number in the upper right-hand co~ners in each of i -these switch blocks. . .
Switch block 3200 preferably also contains a version point-er 3220 which identif ies the ~ocation of the vers~on black for , :-the version to which switch block 3200 corresp~nds. The next . field, macropage number field 3230, identifies the correspondin~
, macropage in m~ster data fi1e 2900, or in the equivalent master I ::
data fil~ fsr index ~ile 80~. Micropage slot number 3240 j - :.
identi~ies the slot number in snapshot data ~ile 291~ (or in the , ~l snapshot data file for index file 800) into which.the YersiOn of 1 ; ~ the macr~pzge corresponding to switch block 3200 is stored I -lS , The next two fields in switch block 3200 are the new~r and ', . ...... :
- .I older version fields 3250 and 3260, resp~ctively, which Contain ~ .:;` .
pointers to ~he switch blocks corresponding to th~ immediately t , more rBcent and the immediately less recent ~ersions, respe~
,, ~ively, of the same macropages in master ~ata file 2900 tO which i~ swi~ch block 3200 corresponds. Although the use of these fields is explained in greater detall b~low when discussing how to ¦ acces~ common data structure 140', dn exampl~ of the use of such ~ ~.
fields can ~e appreciated by considering Fig. 33.

i! To access a macropage, one enters HASH ta~le 2924 with a ,' desired macropage number and obtains a pointer to the switch 'I ~lock corresponding to the most recent version of that , , ~ , . . ....
. ' :.
-8~
, ~ .''' , : f~ r~ ;r'or .~

,l 132~0~ I
'.macrapage. To obtain an earlier version of that macropage, on~
.'continues to use the olde~ version pointers 32~0 until the swi~ch block for t~e desired version of the mdcropage is locat-:led.
,; :
switch block 3210 also contains a switch next pointer 3270 .~hich identifies the next swit~h block for the same version, The linking effe~ted by switch next field 3270 is shown schemat- :
ically in Fig. 29 ~y ~he rightw~rd poi~ting arrows betwe~n switch ~locks 295Z, 2954, 2956, and 2958; ~etween switc~ blo¢ks 2942 and 29~4; and bet~een s~itch blo~ks 293~, 293~, 2930 and ), 2938 ~ ~he final ~ield in switch ~lock 3200 is the switch b flags field which are switc~ b flags include a s~itch-~-shared- ', slot flag. This flag is used in roll back error recovery .described ~bove. Th~ flag indi~ates that anot~r switch block is identical to this s~itch ~lock. For ex~mple, a version n of I :
~ macropage x may be a 510t y. So also a version n~2 of a ~' -macropage x ~ay be in slot y, th~se versions corresponding to . , ~-the identical state of a version just ~efore and 3~st aft~r roll back.
, . ~ .
2~ With the understanding of the common ~tr~ctural data 140' j~ust provided, the creation and acce~s procsdures described gen~
~erally for the common data structure o~ thiS invention can be Lnderstood with regard to the specific i~plementations of this 'iinvention, Flow charts 3300, 3400, 3500, 3520, 3530.and 3700 in Pigs~ 33-36 show preferred methods for upda~ing and accessing , ~ --common data structure 140' shown in Figs. 29-32. Preferably, ~ : ~

Il , ... .
1 -81- 1 ~-,,,,i ' '~ ~.
. ''~'.':

l! 132~0&~ ~:
the procedures in Figs. 33-36 are carried out by storage and I ~
manage~ent software 566. ~ -At the outset of the procedure in Fig. 33, the ALT~R an~
" DBC locks are obtained (SteP 3310). ~he purpose of ALTER lock . 568 is to ensure that only on~ application is modifying the com-: mon d~t~ str~eture l40' at any one time. The purpose of the 3B~ .
. ~69 lock is to make sure that only one app~ication is modlfying - , ~he database eontrol file 2920 at any one time. ' ::
, Next, a new version block is created for this particular I .`
;I version (Step 3315). ~hen DBC lock 56g can be return~d ~Step ¦ .
,~ 3320).
`' The next step is to determine whether th~ next modifi~ation ¦ .
to be made is tO an unmarked (i.~., previously unmodified in ~ ~ ;
¦ this versiOn macropage (Step 332S). If so, then several act~ons ¦ .
'I haYe to taka place. ¦ . .
.~ First, the application obtains DBC lock 56g (Step 3330) . ¦ . . .
' Next, the c~rrent contents o~ the last chan~ed field of version block 3150 is copied to the next updated ~i~ld of ~he mac~op~ge ~; (Step 3335). ~hen the pointer to the ma~ropa9e is copi~d ~o the 1 version last changed field 3150 of tho ~ersion block (St~p 3340). Finally, ~BC lock 569 is returned (Step 3345).

I If the next modification w2S not to an unmarked page, or ~fter the macropage has beén linked to the version block, the ~ modifica~ions to he maCropage can be made (Step 33~0~. Subse~
23 1 ~uen~ly it is determined whether there are any more modifica-tions to be made ~Step 3355)~ }f so, then the process is I; , . . .
I i ~ . , , l _ ' Il 13250~ i repeated begi~ning with the inq~iry whethe~ the next modi~ica-'~ tion is to an unmarked page (Step 3325). I~ there are no more modif~cations to be made, then the COMMI'r routine is c~lled ,' ($tep 3360) to store the ~aster data file 2900 macropages to snapshot data file 2910, and to indicato that this verSion of : data structure 140' can now be accessed by oth~r applications . programs.
Fig~re 34 shows a preferred flo~ diagram for the ~OMMIT i - :~
routin~. Th~ first step is to get the DEiC lock (Step 3405), 1~ ' Next, ~ determination must ~e made as to whether the last , .
changed ~iel~ 3150 in version block 3100 iS equal to zero. If so, then no changes ha~e been made, If ~ersion last changed , pointer i~ not equal to zero, c~anges have been made and initial .~ housekeeping must be performed (Step 3415). This housekeeping ¦ .
is expl~ined in greater detail below. , -:
, Next, thQ macropage indicated by the version last changed ' :.
i pointer must be retrieved (Step 3g20). ~hen th~ slo~ number for that retrie~ed m~cropage must be updat~d to indicate the slot , ~
-~ number of ~nap~hot data file 2S10 into which the retreived i ; .
~ macropag~ is to be stored (Step 3425). Tha~ slot numbe~ is i preferably in some sort o~ list contained ~y the storage and . s~f~ware 565 of free slots for snapshot data file 2910.
' Nex~, ~he linkage of the switch block to the ~ersion i8 . .
, verified ~St~p 3~30), and the macropage ~s copied ~rom master ~5 ., data file 2900 into snapshot ~ata file 2glO at the app~op~iate !~ slot number (Step 3435). Then, HASH table 2924 i5 updated to .i ' ,,:

.... - ..... , -.

- ' . ,' ' . , ,: ,' . :; : ' . . ' : . ' ' ' ": : : ' -- ll 132-~
, point to ~he switch block ~or this most recent version of th0 ,modified ma~ropage, and to link that switch block to earlier i .
jversions of the switch block for that same macropage ~Step '.34 . After this updating, the next updated field of the current macropage is obt~ined (Step 3~45). If that next updated field is not equal to Zi3~0 ~Step 3450), indi~a~ing that ther~ are additional ma~ropages whic~i were modified, then the nex~ updated , ~:
macropage is obtained and the pro~edure is rspeated beginning .
,,with the entry into the proper switch bloi~k (Step 3425). j If the next updated field of ~he rurrent macropage is zerc,, ,then there are no more ~odified macropages, and inte~mediate .i housekeeping is performe~ (S~ep 3460). This step also takes ' place if the version first field is zero (step 3410). This in~
. termediate housekeeping i~ also explained in detail below. ~ .
,I Next, the current version number 3030 and the version block ,~ pointer fieId 3035 in the pointer/counter block 2922 of the data ~
; base control fi}e 2920 are updated. I'his is now the com~,it . ~.
'' point at which time the other appli~ations become aware of the ,I newest versior,, o~ the master data f~le 2900 (Step 3465), Then : ~I final housekeeping is per~ormsd (St~p 3470), and bcth the DBC f , and ALTER locks are returned (Step 3475)-.
Figures ~5A-C show the pro~edures followed in th~ initial, !::
!f Il intermediase and final housekeeping steps of the COMMIT ro~tine , .
~ in Fig. 34.. Flow chart 3500 shown in Fig. 35~ cor~esponds to ¦
i¦ ~he initial hou~ekeeping; flow chart 3520 show~ in Fig. 3SB j ..

sl~ -84- 1 ~

i 1 :, ;: .: , ,1 132~0~6 1 -, corresponds to the intermediate housekeeping: and flow chart ' , 3540 shown in Fig. 35C corre$ponds to the f inal housek~eping, In the initial housekeeping proce~ure, th~ first step is to i l delete obsolete version blocks and switch blocks (Step 3505). A
version block is obsolete when it is not the most recent version .
and when, as indicated by version user count field 3120, there are no current ~sers. A deletion occurs by unlinking these , -switch blocks and version blocks and ~y placing the memory cor- j :
responding to these unlinked blocks onto the list of free lo ., blo~s.
~ The size of master data file 2900 is then compared to the ,' size of snapshot~data file 2910. If new macropages were added " to master data file 2900 making ît larger than the snapshot fil~ ~ .`
, 291û, ~hen snapshot data file ~910 must be increased accordingly :
, (Step 3510). When this occurs, the added macropages to the ~:^
~napshot file are also put on ~he list o~ natural slots for the ¦
corresponding macropages added to the mastRr data file, i In the inter~ediate housekeeping, shown in ~low chart 35Z0, ~
. the first step ;s to ~vict all squatt^ers ~step 352s) . A squat- j I ter is a macropage whlch is in the natural slot for anoth~r I¦ exicting macropage. Thus, if the natural slot for macropage 3 'I ^ :
,i (in o~her words slot number 3) has a macropage. not e~ual to 3, ~ hen that macropage is moved somewhere ~lse in snapshot ~ata . ^~
l file 2510, , Next, the ~acropage corresponding to the vacant natural ~ ~ :
i, slots are moved into those natural slots ~Step 363~). In our '.
. . ? ^

-:

i" 132~0~
example, the most recent version of the macropage number 3 is then found and inserted back into its natural slot.
In the final housekeeping, the only actions that occur are the deletion of obsolete versions and switch blocks (Step 3545).
Figure 36 shows a preferred embodiment of a flow chart 3600 for accessing a desired version of a macropage. In the first step, the HASH table is searched to determine the location of ths most recent version of the desired macropage (Step 3610). Next, if the HASH table indicates a location for the macropage, the version number of that macropage is tested to see if it is less than or equal to the desired version number (Step 3620). This is necessary because an application already operating with one -version must continue to access the same version for all the other macropages. while accessing one macropage, however, several other versions may have been completed, so the current version may not be the appropriate version.
If the version number of the macropage currently accessed i~
larger than the version number for the application, then the switch block pointer is accessed to find thé next older version macropage, in the same test as made ~Step 3630). Once the proper verqion is found, then the switch block for the desired macropage ~-is used to point to the location in the snapshot file 2910 for that macropage (Step 3640).
If the entry is not found in the HASH table (Step 3610), then the macropage number itself i~ used as the macropage's slot number to access the macropage (Step 3640). The routine is then exited.

, . ':

j G, ~m~Y 1 3 2 ) 0 ~ ~
j It ~hould be apparent ~o those ski.lled in the art th~it var-ious ~odification~ m~y be made to this invention wi~hout '! departing from the scope or spirit o~ ~he invention. Thus, it is intended th~t the invention ~over modification$ and va~ia-tions of the invention, provided they come ~ithin the scope o~
the appended claims ~nd their legally entitle~ equivalents, , -, .

.. ..

., ' ' .
,.......................................................... . . .

.. . .
,, . ,, ,: ..

.:

.,, . ',, ~' ~ ':

'I ' ' ' .. I. ~ ~ ~

,, -87- ' ~
~1 ' ' I ,' ' ;'.;,

Claims (40)

1. A method for creating a data structure for access by a plurality of application programs, said application programs being executed by a data processor which also creates said data structure in a memory coupled to the data processor, said data structure being created from application data originating in said application programs and including a plurality of node data and node data descriptors, and said method comprising the steps, executed by said data processor, of:
(a) creating a different one of a plurality of attribute data objects for each of said node data;
(b) organizing said attribute data objects hierarchi-cally according to a being-held relationship by choosing from said plurality of attribute data objects for each of said attribute data objects, a holder data object such that a hierar-chical being-held relationship exists between each attribute data object and a single holder data object;
(c) establishing nonhierarchical relationships for selected ones of said attribute data objects created from node data associated with at least one of said node data descriptors by choosing, from said attribute data objects, referent data ob-jects for said selected attribute data objects such that the chosen referent data object reflects a node data descriptor of the node data for which a corresponding selected attribute data object was created, said selected attribute data objects being called relation data objects and the attribute data objects without referent data objects being called element data objects;

(d) creating an apex data object with which a.
least one of said attribute data objects has a being-held relationship, said apex data object having no being-held relationship with any of said attribute data objects;
(e) creating an attribute file for said attribute data objects;
(f) entering each of said attribute data objects into said attribute file;
(g) entering holding pointers for each of said attribute data objects, the holding pointer of each attribute data object indicating the one of said attribute data objects having a being held relationship with that attribute data ob-ject; and (h) entering referent pointers into said attribute file, said referent pointers reflecting said nonhierarchical re-lationships between said attribute data objects.

2. The method according to claim 1 wherein said attribute file includes an object block for each of said attribute data objects, and wherein said step of entering said attribute data objects into said attribute file includes the substeps of creating an object header block for each different attribute data object; and entering into that object header block information about that object block.

3. The method according to claim 2, wherein the step of entering holding pointers into said attribute file includes the substep of entering into each of said object blocks the holding point-er for the attribute data object corresponding to that object block, the holding pointer identifying the location in said attribute file of the object block of the attribute data object with which that attribute data object has a being-held relation-ship.

4. The method according to claim 2, wherein selected sets of said object header blocks are linked and wherein the method further comprise the substep of entering linkage pointers into each said object header blocks in said selected sets.

5. The method according to claim 2, wherein selected ones of said object blocks also include held object sub-blocks and wherein the method further comprises the substep of placing into said held object sub-blocks of each of said selected object blocks being-held pointers to object blocks for attribute data objects having a being-held relationship with the attribute data object for that selected object block.

6. The method according to claim 2, wherein selected ones of each of said object blocks for relation data objects include relation sub-blocks and wherein the step of entering referent pointers into said attribute file includes the substep of enter-ing into said relation sub-blocks for each relation data object one of said referent pointers to the referent attribute data ob-ject for that relation data object.

7. The method according to claim 6, wherein the object blocks for certain of the relation data objects includes a plu-ral relation sub-block identifying a plurality of referent pointers, and for said certain referent data objects, the sub-step of entering referent pointers further includes the sub-step of entering a pointer to one of said plural relation sub-blocks into the relation sub-block for the certain relation data objects.

8. The method according to claim 7, wherein the object block for said certain relation data objects includes a plural relation header block, and wherein the method further includes the sub-steps for each of said certain relation data objects, of creating a valid plural relation sub-block for each of said referent attribute data objects for that relation data object, and placing a indicator into the plural relation header block that the created plural relation sub-block is valid.

9. The method according to claim 8, further including the sub-step of linking the plural relation header blocks for each referent data object.

10. The method according to claim 1 further comprising the steps of:
identifying each of said attribute data objects as one of a plurality of object types;
specifying an identifier for each of said object types, creating a dictionary file containing a storage area for each of said object types for holding information associated with that object type; and entering into said storage areas for each object type the specified identifier for that object type and the informa-tion associated with that said object type, said associated in-formation, including a name pointer between that object type and the identifier specified for that object type.

11. The method according to claim 10 wherein the step of entering identifiers and associated information into storage areas includes the step of entering into each of said storage areas instance pointers identifying in said attribute file those attribute data objects having the object type associated with that storage area for which all of the attribute data objects have a being-held relationship with the same attribute data ob-ject.

12. The method according to claim 10 wherein said storage areas of said dictionary file include an object type block for each of said object types, and wherein the method includes the step of placing into each said object type blocks linkage point-ers to effect an order of said object blocks.

13. The method of claim 12 further including the step of placing into each said object type blocks an indicator of wheth-er attribute data objects of that type are ordered.

14. The method according to claim 10, further comprising the steps of:
(a) creating a first file for said apex data object and (b) entering holding pointers into said first file for said apex data object, said holding pointers identifying said attribute data objects having a being-held relationship with said apex data object.

15. The method according to 14 wherein said first file is said dictionary file.

16. The method according to claim 1 further comprising the steps of:
(a) assigning to certain ones of said attribute data objects unique key values for allowing quick access to said cer-tain ones of said attribute data objects in said attribute file, (b) creating leaf blocks each corresponding to a dif-ferent set of said key values such that each said key value is in only one one set, (c) entering, into each of said leaf blocks, pointers to the locations in said attribute file of each of the attribute-data objects having one of the assigned set of key values corresponding to that leaf block, and (d) organizing said leaf blocks according to said sets of key values to provide expedited determination of the leaf block corresponding to each of said set of key values to obtain the location of a desired attribute data object, the assigned key value of which corresponds to one of said set of key values for that leaf block.

17. The method according to claim 16 wherein said step of organizing said index blocks includes the substep of ordering said index blocks into at least one tree structure.

18. The method according to claim 17 wherein the substep of ordering said index blocks into a tree structure includes the substeps of (a) creating a root block for said tree structure to provide an entry into said tree structure, (b) creating a plurality of branch blocks, each cor-responding to a different nonoverlapping group of said sets of key values, (c) organizing said branch blocks to provide a unique pathway through said nonoverlapping groups of key values for each of said sets of key values, and (d) organizing said leaf blocks and said branch blocks such that each of said unique pathways leads to the leaf block corresponding to the set of key values for which that pathway was provided, the set of key value including the assigned key value for the desired attribute data object.

19. The method according to claim 18 further including the step of building an index directory block in said attribute file identifying, for a specified one of said certain attribute data objects, the tree structure containing a pathway to the index block for the key value associated with the specified one of said certain attribute data objects.

20. The method according to claim 10, wherein the step of entering said holder pointer into said attribute data file com-prises the substeps of:
determining the object type of each attribute data ob-ject;
allocating, in accordance with the object type of each element data object, an attribute file area in said attribute file for that element data object and for said holding pointers;
deriving an object pointer to each of said attribute file areas containing one of said attribute data objects;
providing, as said holding pointers to each holder data object, said object pointers for at least one of said ele-ment data objects having a being-held relationship with that holder data object; and providing, as a holder pointer for each attribute data object in said attribute area for that attribute data object, said object pointer to the one of said attribute file areas con-taining said holder data object of that element data object.

21. The method according to claim 20, wherein the step of entering said holding pointer into said attribute data file fur-ther comprises the substep of linking selected sets of said attribute data objects which are of the same object type by including, in said attribute file area for each of said attribute data objects which are of the same object type, at least one of said object pointers for one of said attribute data objects of the same type as that attribute data object.

22. The method according to claim 21, wherein the step of linking selected sets of said attribute data objects includes the substep of providing as a first object pointer a pointer to a first one in each of said sets of attribute data objects.

23. The method according to claim 22, wherein the step of linking selected sets of attribute data objects also includes the substep of providing a second object pointer a pointer to a last one in each of said sets of attribute data objects.

24. The method according to claim 23, wherein said sets of attribute data objects include only element data objects.

25. The method according to claim 20, wherein the step of entering said holder pointers into said attribute data file fur-ther comprises the substep of linking selected sets of said attribute data objects having said being-held relationship with the same holder data object by including, in said attribute file area for each of said attribute data objects having the same holder data object, at least one of said object pointers for one of said attribute data objects having the same said holder data object as that attribute data object.

26. The method according to claim 25, wherein the step of linking selected sets of said attribute data objects includes the substep of providing as a first object pointer a pointer to a first one in each of said sets of attribute data objects.

27. The method according to claim 26, wherein the step of linking selected sets of attribute data objects also includes the substep of providing as a second object pointer a pointer to a last one in each of said sots of attribute data objects.

28. The method according to claim 27, wherein said sets of attribute data objects include only element data objects.

29. The method according to claim 20 wherein the step of entering referent pointer into said attribute file further com-prises the substeps of:
determining, for each of first ones of said relation data object having a being-held relationship with one of a first set of said element data objects, whether the referent attribute data object for that relation data object is to be specified in an attribute file area for that element data object;
choosing as the referent pointer for each said ele-ments data objects in said first set, the object pointer of the referent attribute data object for the relation data object having a being-held relationship with that element data object entering, for each of the first set of element data objects for which the referent attribute data object for first relation data object is to be specified in the attribute file area of that element data object, that chosen referent-pointer into the attribute file area for that element data object;
allocating in the attribute file area for each of said first set of element data object for which one of said relation data objects has a being-held relationship, a referent data ob-ject area in the attribute file area for that element data ob-ject when the referent attribute data object of that relation attribute object is not to be specified in the attribute file area of that attribute data object; and providing, in the referent data object area of that element data object, the object pointer of said chosen referent attribute data object as the referent pointer for that relation data object.

30. In a data processing system including at least one central processor executing a plurality of application programs and also including a memory containing a data structure common to said application programs, said common data structure con-taining a plurality of attribute data objects each having hier-archical being-held relationships with a single other one of said attribute data objects or with an apex, wherein selected ones of said attribute data objects have non-hierarchical rela-tionships, and wherein each of said attribute data objects has an associated memory area including pointers to memory areas for other ones of said attribute data object which have said being-held relationship with that attribute data object, a meth-od for adding a desired one of said attribute data objects to said data structure comprising the steps, executed by said cen-tral processor, of:
creating a memory area for said desired attribute data ob-ject;
locating, as a holder attribute data object, the one of said attribute data objects with which said desired attribute data object has a being-held relationship;
adding in the memory area for said holder attribute data object, a pointer to the memory area of said desired attribute data object; and linking said desired attribute data object with other ones of said attribute data objects having a being-held relationship with said holder attribute data object.

31. In a data processing system including at least one central processor executing a plurality of application programs and also including a memory containing a data structure common to said application programs, said common data structure con-taining a data structure with a plurality of attribute data ob-jects each having hierarchical being-held relationships with a single other one of said attribute data objects or with an apex, wherein selected ones of said attribute data objects have non-hierarchical relationships with others of said attribute data objects, and wherein each of said attribute data objects has an associated memory area, a method for creating a desired non-hierarchical relationship between a given one of said attribute data objects and a referent one of said attribute data objects comprising the steps, executed by said central proces-sor, of determining a location of said referent attribute data ob-ject;
accessing the memory area for said given attribute data ob-ject; and placing a pointer to said referent attribute data object location in said memory area of said given attribute data ob-ject.

32. The method according to claim 31 wherein said desired non-hierarchical relationship is selected to be one of a prede-termined type of relationships, wherein said memory system in-cludes a type area identifying said types of non-hierarchical relationships and identifying where in said memory area for said attribute data objects to find pointers to referent attribute data objects of said types, and wherein the step of placing a pointer includes the substeps of determining the type of said desired non-hierarchical rela-tionship;
finding, in said type area, a location in said memory area for relationships of the type Of said desired non-hierarchical relationship; and placing said pointer into said memory area of said given attribute data object found for said desired non-hierarchical relationship type.

33. In a data processing system including at least one central processor executing a plurality of application programs and also including a memory containing a data structure common to said application programs, said common data structure con-taining a data structure with a plurality of attribute data ob-jects each having hierarchical being-held relationships with a single holder one of said attribute data objects or with an apex, wherein selected ones of said attribute data objects have non-hierarchical relationships, and wherein each of said attribute data objects has an associated memory area containing sequence pointers to the ones of said attribute data ele-ments having a being-held relationship with the same holder one of said attribute data objects, a holder pointer to said holder one of said attribute data objects, and referent pointers to any of said referent ones of said attribute data objects with which that attribute data object has a non-hierarchical relationship, a method for erasing a memory area for a desired one of said attribute data objects comprising the steps, executed by said central processor, of:
locating said memory area for said desired attribute data object, erasing said referent pointers;
locating the memory area for said holder attribute data ob-ject;

erasing the one of said holder pointers for said desired attribute data object;
adjusting said sequence pointer to remove any pointers to said desired attribute data object; and erasing the memory areas for all containment tree ones of said attribute data objects which have a being-held relationship with said desired attribute data object or which have a being-held relationship with another one of said containment tree attribute data objects.

34. In a data processing system including at least one central processor executing a plurality of application programs and also including a memory containing a data structure common to said application programs, said common data structure con-taining a data structure with a plurality of attribute data ob-jects each having hierarchical being-held relationships with a single other one of said attribute data objects or with an apex, wherein selected ones of said attribute data objects have non-hierarchical relationships with referent others of said attribute data objects, and wherein each of said attribute data objects has an associated memory area, containing referent pointers to any of said referent ones of said attribute data ob-jects with which that attribute data object has a non-hierarchical relationship, said associated memory area for each of said referent attribute data objects containing a non-hierarchical relationship pointer to that attribute data object having a non-hierarchical relationship with that referent attribute data object, a method for erasing a desired non-hierarchical relationship between a given one of said attribute data objects and a referent one of said attribute data objects comprising the steps, executed by said central proces-sor, of:
locating the memory area for said given attribute data ob-ject;
locating the referent pointer to said given referent attribute data object in the memory area for said given attribute data object;

locating said given referent attribute data object using said referent pointer;
locating the non--hierarchical relationship pointer to said given attribute data object in the memory area for said referent attribute data object;
erasing said non-hierarchical relationship pointer and erasing said referent pointer.

35. A memory system coupled to a central processor and containing a data structure including an apex, a plurality of elements each corresponding to a different node datum in an application program executed by said central processor, hierar-chical holding relationships among said-elements, and non-hierarchical relations for said elements, said hierarchical holding relationships in said data structure being restricted such that for each of said elements, only one other element or said apex has a holding relationship with that element, said memory system comprising:
element storage means for containing information about each of said elements, said element storage means including a header portion containing identifying information about said elements!
holding pointers identifying the elements for which each of said element has one of said holding relationships, and relation identifiers specifying said non-hierarchical relations and apex storage means for containing information about said apex, said apex storage means including identifier information for said apex, and element pointers to the elements having one of said holding relationships with said apex.

36. The memory system according to claim 35 wherein said data structure includes at least one context with which said apex has a holding relationship, wherein each said at least one context has a holding rela-tionship with at least one of said elements, wherein each said at least one context corresponds to a containinment tree which includes all of said elements with which that element has a holding relationship and any other of said elements with which other ones of said elements in the con-tainment tree of that at least one context has a holding rela-tionship, such that each of said element is included in the con-tainment tree of only one s id at least one context, wherein said elements are named such that the ones of said elements in the containment tree of each said at least one con-text have unique names which need not be different from the names of said elements in the containment trees of different ones of said at least one context, and wherein said memory also includes context storage means for containing said at least one con-text, said context storage means further including identifier information for said at least one context, and element pointers to the elements having one of said holding relationships with each said at least one context.

37. The memory system according to claim 35 wherein cer-tain of said elements are each associated with a different one of a plurality of key values, and wherein said memory also in-cludes index storage means for containing said plurality of key values, said index storage means further including index storage portions placing nonoverlapping subsets of said key values in an ordered fashion, and key value pointers for specifying, for each of said key values, the location of in said element storage moans of the identifying information for the elements associated with that key value; and index pointers for identifying said portions of said index storage means containing each of said key values.

38. The memory system according to claim 39 wherein cer-tain of said elements and relations are associated with differ-ent types, and wherein said memory also includes dictionary storage means for containing information about said types of elements and relations, said dictionary storage means including element fields containing, for each of said types of elements, information about the elements of that type, and relation fields containing, for each of said types of relations, information about the relations of that type;

index pointers for identifying portions of said index storage means containing desired key values.

39. A data processing system for maintaining and providing access to a common data structure, said data processing system comprising:
a central processor executing a plurality of application programs which exchange data via said common data structure, said common data structure including an apex, a plurality of elements each corresponding to a different node datum in an application program executed by said central processor, hierar-chical holding relationships among said elements, and non-hierarchical relations for said elements, said hierarchical holding relationships in said data structure being restricted such that for each of said elements, only one other element or said apex has a holding relationship with that element;
a memory being coupled to said central processor and con-taining said common data structure, said memory including element storage means for containing information about each of said elements, said element storage means further including a header portion containing identifying informa-tion about said elements, holding pointers identifying the elements for which each of said element has one of said holding re-lationships, and relation identifiers specifying said non-hierarchical relations, and apex storage means for containing information about said apex, said apex storage means further including identifier information for said apex, and element pointers to the elements having one of said holding relationships with said apex.

40. A data processing system for maintaining and provid-ing access to a common data structure, said data processing sys-tem comprising:
a plurality of central processors simultaneously executing a plurality of application programs which exchange data via said common data structure, said common data structure including an apex, a plurality of elements each corresponding to a different node datum in an application program executed by said central processors, hierarchical holding relationships among said ele-ments, and nonhierarchical relations for said elements, said hi-erarchical holding relationships in said data structure being restricted such that for each of said elements, only one other element or said apex has a holding relationship with that ele-ment;
a memory system being coupled to said central processors and containing said common data structure, said memory system including element storage means for containing information about each of said elements, said element storage means further including a header portion containing identifying informa-tion about said elements, holding pointers identifying the elements for which each of said element has one of said holding re-lationships, and relation identifiers specifying said non-hierarchical relations, and apex storage means for containing information about said apex, said apex storage means further including identifier information for said apex, and element pointers to the elements having one of said holding relationships with said apex.