CA1308198C - Data processing system having a data structure with a single, simple primitive - Google Patents

Data processing system having a data structure with a single, simple primitive

Info

Publication number
CA1308198C
CA1308198C CA000596586A CA596586A CA1308198C CA 1308198 C CA1308198 C CA 1308198C CA 000596586 A CA000596586 A CA 000596586A CA 596586 A CA596586 A CA 596586A CA 1308198 C CA1308198 C CA 1308198C
Authority
CA
Canada
Prior art keywords
attribute data
data objects
attribute
objects
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CA000596586A
Other languages
French (fr)
Inventor
Edward S. Lowry
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Digital Equipment Corp
Original Assignee
Digital Equipment Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Digital Equipment Corp filed Critical Digital Equipment Corp
Application granted granted Critical
Publication of CA1308198C publication Critical patent/CA1308198C/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/901Indexing; Data structures therefor; Storage structures
    • G06F16/9024Graphs; Linked lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • G06F16/211Schema design and management
    • G06F16/212Schema design and management with details for data modelling support

Abstract

ABSTRACT OF THE DISCLOSURE
A data structure in a computer memory is constructed from a single primitive data element or attribute. Attributes of the data structure are arranged in accordance with certain rules which impose a hierarchical organization upon the attributes as well as non-hierarchical relationships. Means for creating and erasing the attributes include a data processing system contain-ing the memory.

Description

~3~8198 66822-99 RELATED APPLIC~TION
This application is related to Canadian Patent Appli-cation Serial No. 597,577, entitled "Method of Integrating Software Application Programs Using An Attributive Data Model Database" by Edward S. Lowry, Earl C. Van Horn, and David M.
Nixon, Filed on April 13, 1989.
BACKGROUND OF THE INVENTION
This invention relates to software and more specifically to data models as they are used to represent information in application programs and databases.
Software systems, especially large ones, suffer from a variety of problems in their development, use, and adaption to new requirements. Programs tend to be complex and obscure.
Interfaces to functionalitytend to be numerous, specialized, and hard to coordinate. Data structures tend to reflect indirectly the information they represent. Independently developed data structures and applications tend to interact only with the help of elaborate conversion subsystems.
The choice and varlety of data models used can afect the severity experienced with these problems. A data model is that part of a language (i.e., a type of interface to functionality) which defines the permissible structures for subject matter of the language. For example, operations described using relational database languages necessarily talk about tables of tuples. Programs written in APL necessarily talk about integer indexed arrays. Programs written in PL/l talk about a wider variety of data structures, composed from records, arrays, pointers, strings, etc.
,.,~ , ~k ~PR 13 '89 IZ:54 F~OM FINNEGRN HENDERSON P5~GE.160 f~ ~, ~ 3 ~8 19 8 LangU~ges tend tO hsve one of two general kinds of da~a .models, each with di~ferent limitationc. Some languages such as relational d~t~base languages and APL are "functionally expres-sive. n ~hey can ~e used to express many operations on lar~e S aggre~ates of data all in a sin~le statement. However, e~ch such language has a very limited range o~.data str~tures .ellowing accurate representation of onceptual structures for only a narrow class of applications. Operations in susch lan-guS~ges tend to be complicated by a need to deal with special conventions used to adapt the conceptual structures of the . application to the li~ited available data structures in the lan-guage, Other langua~es such as PLJl and COBOL have a ~reater abil-ity to represent rich structures accurately. ~hey may be described as S~tructurally expressiv~. n ~owever, the variety of elementary data structures used in sucS~ a language makes it im-.: pract~cal to also provide pow~,rful nested operatlons on largedata aggregates within a lans~u~ge of manaS~eable size. The lack o~ powerful operations leads to complication~ of expression in ao' the lan~u~ge o~ a di~férent kind.
One object of the pre5ent invention is ~o provide a data , mod~l on which it is possible to design interface9 to func-tionality which largely eliminates both thos0 kinds of complica-t~on.
25 . It i5 also an ob~ect of the present lnv~ntlon to simplify ~wO~c.- interface~ to functionslity.
FINN5!~N ~IN~ER50~;5 5:
F~CW, S~Mnt ~ DUNSN~K
IS~ S~ n~ N ~.
w~l~or~, D. C,~OOO~ ~ ' Joo~ 5s~0 ~ 2-"::

RPR 13 '89 IZ:55 FROM FINNEGQN HENDERSON P~GE.161 ~ 136~ 38 , SUMMARY OF T~i INVENTION
~ o achieve the foregoing objects, and in accorda~ce with th~ purpose of the inv~ntion as embodied and broadly described herein, a data structure is constructed from~single primitive data o~ject, the attribute, to provide ~ expres-ct l~na siveness. Structural expressiveness is achieved by making ~ha~
primiti~e data object ex~re~ely simple and allowing for highly unconstr~ined interconnections between attri~ute instances.
More specifically, the data structure of the present inven-10. tion resides in a memory of a data proc~ssing system for accessby an application progra~ being exec~ted ~y the data processing system. The data s~ructure comprises a plurallty o~ attribute ~ata obiects stored in the memory.
The data ~tructure further comprises a single hol~er attribute data object for each of the attribute data objec~s, . ~ach of the holder attribute data objects is cho~en from the plurality of attributo data objects ~uch that a ~eing-held rela-tion~hip ex~sts betwe~n each attribute data obioct and its hold- .
' er attribute d~ta object and such that a hierarchy of the 20l attri~ute data object$ i~ established by ensuring that each of ~I the attribute data opjects has a being-h~ld relationship with i only a ~ingle other attribute data object.
I The ~ata structure also comprises a single referen~
' attribute data object ~or s~lected one~ of the attribute data 25 , object~. A refor~nt attribute data object is nonhierarchically ~WO~C~ ., relat~d to the holder attribut~ data object of the sa~e flUNGC~N, ~I~NDI!RXJN
P~. c~Rm aDuNN~R
177C K ~7~t, Il. W~ , j 7o~ c~ooo~ ' .. ~,.. O -3-: ., ', , ~PR 13 '89 12:55 FROM FINNEG~N HENDERSON P~GE.16 ~ 3~Q~ 98.
;', ` attribute data objeets. Those attribute data objects with only . holder attribute data objects are called "element data objects,"
:and those attribute ~ata objects also pointin~ to re~erent attribute ~ata objects are called "relation data objects."
~he da~a structure further incl~des an apex data ob~ect stored in th~ memory. The apex data object has no being-held relationship with any a~tribute data object, howe~er, at least one attribute data object has a being-held relstionship with the .apex data object.
In connection with the above-described data structure, the pr~sent invention also includes methods for creating attribute~
d~ta objec~sfor storage in the memory, and for ~etrieving attribute data objects.
~he accompanying drawings, which are incorporated in and which constitute a part o~ this specification, illustrate an embodiment of the invention and, together with the description, explaln the principles of the invention.
:, .
, , ... . .

:, , I .

25, ~W OrrlC~L
PINN~ J, H~NWIU~J
F~v.G~
8D~eR
IT7~ T, ~, w~
W~NlllaTON, D, e. ~ow~ 4 ,, ~PR 13 '89 12:56 FRO~ FINNEG~N HEN~ERSON P~GE.163 ,; r~, .

BRIEF DESCRIPTION OF TH~ D~AWINGS
Fig. l shows an example of a data processing system in accordance with the present invention;
Fig. 2 shows an example of an att~ibute data object as taught by the present invention;
Fig. 3 shows a circuit for use in illustrating the use of .
'J ~h~
Attributiv~ data model of the present invention;
Fi~, 4 shows a data structure for representing the circuit . of Fig. 3 according to the Attributive data ~L~ rnoJcl;
l0~i~. 5A shows a block diagram of certain components of a software system in accordance with the preferred ~mbodiment of the presen~ invention;
Fig. 5B shows a block diagram of certain components of a '.
software system in accordance with an al~erna~e embodiment of lS the present invention.
Fig. 6 showfi a portion of the ~ o a me~o~y system ~ontalning ~ data structure including a plurality of files in accordance with the present invention;
. Fig. 7 show~ a 32-bit longword used as a ~ointer in the 20 , preferred embodiment of this invention Fig. 8 shows a more detailed block di~gram of the con5titu-ent portions of the ~t~rib~te ~ile shown in Fig. 6;
Fig, 9 shows ~ block diagram of an element header block shown in Fig. ~;
Figs. l0A and l0B show block diagrams o~ th~ pre~erred ~w~ c, ' embodiment of a relation sub-block shown in Fig. 8;
Fr~ C~, H~ RSON
F~. C~R~r ~ DU~N~
TI-lCtT.~.W.~ ' WACb~ tb~ OOC-- I 5 ~0~1~ J~ O
'j ' , RP~ 13 '8g 12:57 FROI1 FINNEG~N HEN~ERSON P~GE~1~4 ~ 8198 Fig. 11 shows a block diagram of the prefe~red embodimen~
of a ~held" object sub-bl~ck shown in ~ig. 8;
Fig. 12 shows a block diagr~m for a plural relation header block shown in ~ig. 8;
,i .", .
.,;h5 Figs, 13A and 13B show~ ~lock diagram~ of the preferred embodiments of t~o kinds of plural relation sub-~locks shown in Fi~. 8;
Fig, 14 sh~ws a block diagram of the preferred embodiment of an instance root block shown in Fig. 8;
10..... Fig. ~5 shows a ~lock diayram of a preferred embodiment of a dictionary file shown in Fig. 6;
Fi~. 16 shows a block diagram for the hasic structure and contents of the preferred em~odiment of either an apex block or a context block shown in Fig. 15;
Fig, 17 shows a block diagram of a preferred ~mbodiment of an element type block shown in Fig. 15;
Pig, 1~ show~ a block diagram for an attribute type block 8hown in Fi~. lSs Fiy, 1~ ~howY a pr~ferr~d embodlmQnt of a block diagram of ~0, an index branch block in accordance with the present invention;
,~ Fig. 20 shows a block diagram of a preferr~d embodiment of an index ~ranch header block shown in Pig. 1~;
Fig. 21 shows a block diagram of an index branch ~ sub-block~ shown in Fig, 19;
Fig. ~2 shows a block diagram o~ a pr~f~rred embodim~nt o~
~O~C~ an index diractory block shown in Fig. 8;
~NN~N,HI~D~
P~v, C,~P.Rerr ~ Du~eR
177f K ~,ml;leT, t~. ~, TDl~, D, C,~ODO~ , r ~t~D~ 0 --D--.. . .

RPR 13 '~9 1~:57 FROM FINNE~N HEMDERSON P~GE.I65 .

~igs. 23A and 23B sho~ a flow diagram depicting the steps ! i~volved in a preferred method of creating an element data ob-ject accordiny ~o ~he present in~ention : Figs. 24A and 24B show a ~low chart ~epicting the steps in-volved in a preferred method of creating a relation in accor-dance with th~ present invention;
Fig. 25 shows ~ flow ehart depicting the s~eps involv~d in the preferred method of erasing a re}ation in accordance with the present invention;
Fig. 26 shows a flow chart describing the steps involved in ~rasing an element data obje~t in ac~ordance with the present invention;
Figs. 27A and 27B show a flow chart describing the steps . involved in the preferred method of accessing the common data ~tructure in accordance with the pres~nt invention, Fi~ 28 ~hows a flow chart describing the step~ in~olved in an al~ernative pre~erred method of acce6sing the com~on data ~tructure u~ing key values in accordance with the pres~nt in~en- ;
. tionJ
20,l Fiy, 28A shows an index r~sult block;
Flg, 29 ~hows a détailed block diagram o~ a preferred ', ambodim~nt of common data structure 140' in accordance with the " pre~ent invention;
, Pig, 30 ~hows a block diagram of a preferred em~odiment of 2S the pointer/count~r sactlon o~ a controller shown in Fig. 29:
u~ o~f~a~ I
hNN~w~H~D~oN :
F~W,G~m ~D~NNe~
It~ Il f~f~f CT, Il. W, , ' oto1~,~,c.ooo~ "
~.O.~ O -7-. . .
' ~PR 1~ '89 IZ:5~ FROM FINNEGQN HENDERSON P~GE.166 l30a~
Fig. 31 shows a b1Oek diagram of version bloc~s shown in Fig. 29;
Fig. 32 shows a block diagram of switch blocks shown in Fig. 2g;
Fig. 33 shows a flow chart describing the steps involved in upd~ting data structure 1~0' in accordance with the present nveAt lon: -Fig. 34 shows a flow diagram for a preferred COMMIT ro~tine indicated in Fig, 33;
Fig. 35Ar 35B and 35C show flow diagrams of the procedures followed in the initial, intermediate and final housekeeping : . . .
.steps, respectively, of the COMMIT routine shown in Fig. 34; and Fig, 36 shows a praferred embodiment of a flow char~ for , acces~ing the desired version of common data struct~re 140' in lS accorddnce wi th tha pre5ent invention.

. :
.; ' .. .
,. .
i 25', :
uw O~C~
hN~Jtc~, HeM~E~soN
FhlWo~qv, C;~RJUT1' lJNNUl !
m~ 5~ T.t~W. !
o~o~ e~oDo~ _ a _ o RPR 13 ' 89 12: 59 F ROI~1 F I NNE G~N HE NDE RSON P~GE . 167 .
~308~98 Reference will now be made in detail to presently preferred ; em~odim~nts of this invention, examples of which are illu~trated in the accompanying drawings.
A . 5_~g~
Fig. 1 shows a pictur~ of a data processing system 100 includin~ a central processing unit (CPU) 110 and a memory 120.
CPU 11~ can be any standard and commonly known central pro-cessing unit, and memory 120 can include magnetic eore, somicon-ductor RAM, magnetic disks and magnetic tapes, or any other ; known memory devico. CPU 110 can also represent several inde-; pendently r~nning central processing units which may beexecuting application programs simultaneously. As shown in Fi~.
1, a~plication programs 130, 132r and 13~ are alternately exe-1~ cuted by CP~ 110. Fig. 1 shows CPU 110 executing applica~ionprogram 130 while application programs 132 and 134 are stored in , memory 1~0.
In accordance with the p~esent invention, application pr~-grams 130, 132, ana 134 share a ~ommon data structure 140 which 20, i~ ba~ed upon an Attributive data model. The Attrib~tive data model represen~s ~ll of t~e in~ormation access~d by application programs 130, 132 and 13~ as ~ariaus com~inations of a single primitive. I~ general, applicatlon programs 130, 132, and 134 have thei~ own databases which contain data ~ither in th~
Attributivo data model's ~ormat or in 5Pme other format, If th~
u~o~lccr ' application program in~ormation i~ not in th~ At~rlbutive da~a , INNtGl~,N, H~ND~PSaN:
' F~wow, ~Mnt DUNN~
S ~c~r. t~. w.
~IIIIIOTI;)I~ OOO~
1~0 ~ ", . , .

RPR 13 ' ~39 1~: 59 F ROM F I NNE GflN HE NDE RSON Pf~GE . I ~i2 : 1308~98 model format, it is converted into that format by means described below. In this manner, data structure 140 can ~e accessed by ~ach of the application programs 130, 132, and 134.
The common data struct~re 140 is different from more con-ventional database sys~ems by the unique data structures which are created and ~ccessed by the ~pplication progra~s. The Att rib~tive data model uses, as its singl e primi tive, an attri~ute or attribute data object which contains certain hier-archical information about its r~lati~nship with other attributes, and which can "point to~ attributos to reflec~ a nonhierarchical rela~ionship. The use of the attributes in accordanc~ with the present invention is limited by the uce of cortain simple rules. ~es~ limited number of rtlles allow the attributes the f lexibility to accurately represent complex ob-lS ~ects and rolation~hips.
Fig. 2 shows an example of an attribut0 data object 200.Attr~bute dAta o~ject 200' 5 hierarchical relationship with oth~r attribut~ data ob~ects i5 donoted a~ a hold~ng or being-h~l~ re-lation~hip, depending upon how the r~lationship is con~idered.
20. ~n gen~ral, each attribute data object can have a being-held re-tionsh~p with (i.e., can be held by) only ono other attribute data ~ ct, but each attribute data object can have a holding r~lat ~n~hip with (i,o~, can hold) se~ral othor attr~ute data objec~s .
2S, ~,ach attribute data ob~ect ~00 i5 related hierarchically to ~O~IC~ a h~ r attribute data object 210, Holder ~ttribute d~ta hNN~ H~Nb~
F~ow, GW.
T~U, t~. W~ ~:
oOo~
~n~ o . ' ~ v ~
!

. .

RPR 13 '89 13:00 F~OM FINNEG~N HENDERSON PRGE.I69 .
1308~98 object 210 is the attribute data object which his a holding re-lationship with attribute data object 200. Conversely, attribute data object A 200 has A being-held relationship with a~tribute data object 210.
The nonhierarchical or pointing relatîonShip de~cribes th~
relationships between the information represented by attribute data obje~ts. Certain attribute dat~ objects may als~ be relat-ed to a single referent attribute data object to reflect t~e poin~ing relationship. A referent attribute data object 220 represents the information which has a nonhierarchal rela~ion-ship with the information represented by attri~ute data o~ject 200.
~ ach attribute data object ~00 may also be related to type data which descri~es the relationship between the attribute data , 4bje~t 200 and those attribut~ data objects for which attribute i data obje~t Z00 has a holding relationshi~ as well as the ; re~or~nt attribute dsta obj~cts which attribute data object 200 "point~ to.~
Th~re dre only a few rules which the attribute data objects 20" m w t ob~y in accord~nce with this invention. Although each attribute data object may hold se~eral other attri~ute data ob-cts, ea~h attribute ~ata object can only have a being-held re-, lationship with a singl~ other attribute d~ta object. Thus, each attribute data object ha~ only on~ holder attrlbut~ da~a 25 ~ ob~ect, ~v O~IC~ :
FhNE~W,H~ND~N
PM,~a~. ~h~ .
Ia ~ul`1~
e~"~, W. ~ .
w~ no~on, D. O, ~000 ' ~O~ O

' .
'' RPR 13 '89 13:01 FRO~ FINNEGRN HENDE~SON PRGE.170 1308~1~8 one kind of attrib~te data object, the element data object or element, does not have a separate referent attribute data ob-: ject because e~ements ar~ considered to ~point to" themselves, i.e., each elem~nt is its own referent. Another kind of attrib~te data object, the relation data object, is related to a single ~e~arate referent attribute data object. E~ch attribute d~ta object may be a referent attribute data obiect for a plu rality of attribute data o4je~s.
~asic to the Attributive data model is the concept that the lO single primitive element, the attrib~te, can represent complex information in other data~ase~ An attribute expresses the idea .
that one thing is attributed to another thin~. For example, thlngs normally attributed to an automobile include its color, its engine, and its owner, To organize complex databases around lS the attribute as a primitive repre~ents the view that a database .
is ba~cally a collecti~n of attributions, Common data stru~- .
ture IgO is a concrete representation of th~t view.
As indicated, elements or element d~ta ob~ects are attribute ~ata objects which refer to themselve~, or in other 20 word~ have only a holder attribute data object and no separate rsfer~nt attribute data objects, An element can represen~ a ~, t~ing, such aS an automobile, an engine, a version of ~ multi-, ~ller circuit, or a ~ignal. El~m~nts which have a being-held , rclation8hip ~ith an ~lement can, for example, represent the in-s 25, ternal struc~u~e of the thing r~presented ~y that element, ~or ' F~NSG~HiN'D~h~N example, if ~n element represent~ an engine, other element~
: P~. ~RI~T
a D~8~ ' r~ T~ r, b, ~
, W~ T
~0~ D
,', '''' , ,'; ' , . .
, RPR 13 '~9 13:01 FRO~ FINNEG~N HEN~ERSON PRGE.171 308~98 .¦ having a being-held relationship with the element representing the engin~ can include the pistons, the cylinders, and the " rings.
'l, Each embodi~ent of data stru~ture 140 has one a~tribute data object which does not have a being-held relationship with another attribute data object, That attribute data object 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 at~ribute data object and the single holder for lol~ each attribute data object, each embodime~t of data 'l structure 14~ has the configuration of attribute data objects in ¦
,¦ accordance with the in~ention such th~t it is possi~le, but not necessary, to cr~ate the configuration by starting with the apex ¦
l and by adding the other attributes, one at a time, in a holding 15)¦ relationship, This restriction creates a hierarchy and preve~ts j~ certain circular or loop configurations, such as when a first ,¦ attribute ~ata object h~s a holding relationship with a second '~i attribut0 data object, which in turn ha~ a holding r~lationshlp ,~ w~th a third attribute data obj~ct, which then has a holding re-2~ I lati~nshi~ back with the fir#t attribute dat~ object. Such a ¦ confi~uration would not b~ hierarchical according to this inven-tion, ¦ The relation or relation data object, as explained above, ~ an attribute data o4ject which ~g re~at~d to a referent 2~ attribut~ ~sta object different ~rom th~ attribute data object ,ff'lN~ N ~ itself. Relation~ can have a being-held relationehip with rr 1 9 I)UNNt~
r . t. I
tO~.D.C,~OOD~ I
~20029~ 0 1 -13-l .

~PR 13 '~ 02 FRO~ FINNEGRN HENDE~SON P~GE.172 1308~98 ..
elements, for example, if an element represents a multiplier . oircuit, one relation can attribute to that element a previous . version of the multiplier. In addition, relations can have holding and being-held relationships with other ~elations. For exa~ple, if a f irst relation attri~ute data object attributes a p~t number to a multipli~, that first relation attribute d~ta object m~y hold a second relation attribute d~ta object which attri~utes to the first relation attribute data object the date on which the part number was assigned to the multiplier, 10; The Attributive data model can be better understood by an . example. Fig. 3 shows a circuit including two AND gates, 320 a~d 330, having three inputs and two inputs, res~ectively. The inputs o~ A~D gate 320 are 32~, 324, and 326, and the inp~ts of . A~D ~ate 330 are 332 and 334. Input 322 of AND g~te 320 is driven by output 336 of AND ~ate 330, and input 334 of AND ga~e 330 i~ ~ri~en by output 328 of AN~ qate 320.
The circuit in Fig. 3 can be represent~d accordin~ to many dif~erent dat~ m~del~. For exampl~, if it wor~ rep~esen~ed by a relationdl data modcl, there would be separ~te t~bles for yates, 20, inputs, and load~ of the gates. Those tables would then con~din j, idantifi~rs of entrie~ in the other tables.
'i Fig. 4 shows a data structure 400 representing the informa-, tion in Fi~. 3 in accordance with the Attributive data model of ' this invention. Data structure 400 can be stored in the common 2s,~, data ~tructure 140 in Fig, 1, ce~
PINNUJWH~ND~X~:~
f~wo~, G~A~urr O~N~ , m~ T~ t, Il. ~. ,;
WA~hlllO~O~ ,C,~ooe~ ~
~!''~ ' " ~~4~
, . ;

QP~ 13 'g9 13:~3 FRO~ FlNNEGhN HENDERSCN PRGE.173 Data str~cture 400 in~l~des an apex 410 which, as described , above, does not have a being-held relationship with any other object, In addition, apex 410 holds (i.e., has a holding rel~-tionship with) CPU attribute data object 420, whi~h can also be a context. The context is a construct to facil,itate naming of attribute datat objects, because those names have,meaning only in the context ho}ding the named objects, and to establish holding relations~ips for attribute data objects that are associated with the context, like the circuits and $ignals in ~ig. 3.
, 10 CPU attribute data vbject 420 holds attribute data o~jscts 43~ and 440 which are circuit elemen~. Attrib~te data objec~
430 represents the c~rcuit in Fig. 3. Attribute data ob~ect 430 , in turn holds two at~ribute data objects 4~0 and 460 w~ich are gate elements. Gate element 450 in turn holds four attrib~te lS data objects 480, 482, ~86 ~nd 48a which are pin element~, In this way, a hiurarchical holding rela~ionship is impo~ed'upon . the in~ormation in Fig. 3.
As Fig. 4 shows, the other information ~rom Fig. 3 is also hierarchically org~n~zed. Apex 410 also holds elements 462, 464, 466, 46a, 490, ~nd 492 representing labels, for other el~-, ments, and attrlbute data o~ject 420 (CPU element) hold~ ele-ments 470, 472, 474, and 4~6 which represent signal elements.
The hierarchical arrangemerlt of attribute data ob~ects , gives rls~ to a "containment tre~," which is used to contain the . 25 , attribute data object~ that collectively repre~ent conceptu~l uw~ e~ , o~jects. A containment tree of an attribute data object, called tUNU~N, H~ND-~N
FhJU~V, c~R~
8 D~
~. ,. ~,~",. ~.
or~ , q .~

RPR 13 '89 13:~3 FROM FINNEGRN HENDERSON PRGE.174 11 ' Ij 1308198 : I
i the root a~tribute data object or root of the containment tree, I include~ all attribute dat~ object, held by the root ti.e., i direçtly held), as well as all attribute data objects held by 1, any other a,ttribute data objects in the containment tree (i.e., 5 j indirectly held). An attribute data object held directly or in-directly by another attribute data object is said to ~e "con-tainfsd" by that other attribute data object or in that other attrib~te a,~ta objec~'s containment tree. In a containment I tree, the conceptual object re~resented ~y that tree corresponds lOiI to the root. All other attribute data objects in the contain- ¦
j, ment tree represent conceptual suk,-objects, such as components, ¦i listed items, or relationships within the conceF,tual object rep- ¦
re~ented by ~he tree. The attribute data objects in a contain-~! ment tree may also rspresent ~elationships with 2,ttribute data 151! o~ject,s outside the containment tree.
~ti In Fig. g, f~vhe containment tree ~or circuit element 430 ~, wou,ld include gate el0ments 450 and 460, and ~he relation dataobjects held by gat~ elements 430, and 450 (i.e., the relat~on data ob~ect~ pointing to ~lement~ 440 and 468 and tho r~lation ~d data ob~ect pointing to element 462), the elements held by ele-¦ ment 4S0 (i,e,, pin elements g80, g82, 486, and 4~), and the I re~lation data ob~ects held by pin elements 480 and 4a8 (i.~
¦ relation data ok~jects pointing to elements 464, 470, 472 and ~¦ 466J.
2ql The usi0 oE a containment ~,r~e,e, as explained in d~tail ~O~ee- ! bel3w, 5implifies ~peration5 such as erasing complex ob~ect~
f~ . H~NDeRX~N ¦
F,~uo~ f~RRnT j O DuN~f&R , m~ rf rfT~fC~T,~f.~l~ I
~,urnf~,raKf~ o~ ooo~ ff -16-~OSI ~fr~s,~-u~o I

,,, , ,, ii RPP 13 '89 13:~4 FRO~ FINNEG~N HENDERSON P~GE.175 .

As an exa~ple, erasure of an object involves the removal from the common data structure of the corresponding containment ~ree.
This invention allows all attribute da~a objects in that ~ree to be identified quickly, ~aking feasible the elimination of random 5 pauses caused by automatic garbage collection com~o~ly used in prior art databases.
Fi~. 4 also cont~ins several other attribute data objects, whic~ ~re representative of information descri~ing e~ch of the things in ~ig. 3 represented in ~ig. 4 by attribute data o~-jects- For example, attri~ute data object 430 holds a relation . da~a object pointing to the name "xyz.~ This relation da~a ob-ject has "xyz~ as a referent attribute data object. ~he name ~xy~" is element ~8. In a similar matter, el~ment 450 has a :rèlation data object pointing to element 462, which is ~he num-ber (320) of the AND gate ~n Fig. 3 represented by element 450.
Fig. 4 shows oth~r rolations as well. For example, ele-- ments 47û, 472, 474, and 476, representing signals such as Sl an~ S2, are or~an~zed into a link~d li~t w~ich i~ represented by a series o~ relation~. Furthermore, attribute data obj~ct 480 20 al~o holds a relation pointing to ~ttrib~te data object 470 ~showing th~t the signal repre~ented by that obj~ct is an input to the gat~ represented by object 450.. The conv~rse relation-:ship is also ropresented by a relation held by element 470po~nting to ~lement 480. The name of the signal represented by 25 attribut~ dat~ obj~ct 470 is refl~cted by ~h~ relation held by ~womo~ attribute datn object 470 and poin~ing the attribut~ data object Fl~,H~bE~N
~ D~G~UunT ggo, which represent5 the label "Sl."
C~. N. W, OrON, 1~, c, 70a~
D~ O

~* TOT~L P~GE.175 ~

~ .:

~PR 13 '89 14:40 FROM FI~NEGRN HENDER50N PRGE.0Z0 --` ^ 1308198^
' ' ' , . ' .

Preferably~ a simple constant, such as the int~ger 35 or the charact~r "K, n is an element and is repres~nt~d by a single attri~ute data object held by.the apex. A character.string is als~ preferably an element held by the apex. The character string element, how~ver, holds a lisS of relations to its con-stituent character objects. Thus, for example, the string ~CAT"
could bo repre~ented by an element data object which held fir~t relations to three other element data objects or elements: the letters "C," nA~ and "T." The ordering of those letter elements to form the character string ~CAT" could be represented by sec- -ond relations that organize the first relations into a list.
For example, the relation from "CAT" to "C" would hold a rela-tlon who~e referent data object is the relation from "CA~ to ~A.n lS B. So~tware UtllitY Oraanization ~ ig, 5A shows a block diagram of certain components o~ a software sy~tem in ac~ordance with the pr~Tferred emb4diment of the present invention. The operation o~ cert~in of these compo-nents i~ pre~ent~d ln a later section. All thst wlll be ~0 l ~escribed wlth regard to Fig, 5A i5 the m~jor functions of each one o~T th~ component5 and their relationship to other comp~-nent~, ,;
Preferably~ the common data ~tructure 140 shown in Fig. 1 includ-s a ma~ter databa~e 510 and a slsv~ database 520. Any 2$ ' upda~s to theT common ~ata structure 140 ar0 made to ~aster ~o~ databa~eT 510, and a copy of it is l~ter made to form the next F~ ~, H-ND~tON
FM~aw, I~R,RILTT
~D~t~ : version of slave databa~e 520, m~ u ~ w, lT ~IIII~OTO-~.O C~OI~OO
~00 ~ 0 ;' '' : ,:-,, , :

~PR 13 '89 14:41 FRO~ FINNEGRN HEN~ER50N PRGE.021 `!
13~8198 In Fig. 5A, 530 and 560 represent two spplication programs, such as the application programs 130, 132 and 134 in Fig. l. In ccordanco with the pr~sent invention, the data processing sy~-tem includes means for retrieving from the common data structure5 the referent attribute data object for a specified relation data Ob;eCt, For application program 530 shown ln Fig. 5A, retrieval program 580 performs such retreival function. The slave database 520 provides the actual data to the application pro~
, grams 530 and 560.
la' The details of an exemplary embodiment of portions of a ~ retrieval program 580 are di~cussed in a later ~ection. rn ~en-", eral, however, application prog~am 530 specifies a relation data ~bjoct to retrieval program $80 and asks for the r~fer~nt data object(s) for that specified relation data ob~ect. Retrieval ~5ll program 580 t~en searches the slave database 520 for the l~, specl~iod relatlon data object. When that specifi~d relation !' dsts ob~ect l~ obtalnod, retr~ev~l program S80 copie~ th~
de~iro~ refer~nt attribute data ob~qct~s), perform~ any ~onver-' ~ion nece~ssry to place the referent data object into the format 20l¦ ~p~1icable for appllcation program 530, and return~ the !~ formatted referent d~ta objoct to applicatlon program 530.
!I The data s~ructure of the present invention al~o includ~s ~ means ~o~ retrieving from the c~mmon dsta str~cture all o~ those j~ attribute data objects which have a being-held relationship with 2~¦ a ~pecifled attribute dats ob~ect. Again, r~trieval progrsm 580 ~o~r~c~ in the preferr~d embodiment ~hown in Fig. 5A perform~ thls type FINN~GW, H-~D-~X~
FA~O~, ~Q~
a Du w~u~O~.o,~,~ooo~
uon~ o--o , ! -19 - :

Il ,X
:,:

.
, ~PR 13 '89 14:4Z FROM FINNEGRN HENDERSON P~G~.022 of retrieval also. In aperation, applicat~on program 530 specifl~ an attribute data object and asks for all thos~ other attrib~te da'ca obiects which are held by the specif ied at~ribute data object. Retrieval program 580 then translates that request 5 into an approp~iate format, and searches through the slave databas~ S20 until tho spec~fied attribute data ob~ect is locat-ed. Once the specified ~tribu~e data object is located, retrieval program 580 o~tains copies of ~11 o~ th~ attribute data objects which are held by that specif ied data ob3ect.
10 Retrieval program 580 then converts those held attribute data objects into th~ ~ormat applicable for application program 530 and transmits those converted attribut~ data objects to applica- ' ~ion program 530.
In accordance with the pre~ent in~antion, the da~a pro-lS cesaing sy~t~m ~lso includes mean~ ~or retrieving from the com-mon data atructure infor~ation from all attrlbute data objects ; of a spqci~ied typ~. Retrieval program 5~0, in respon~e to sucha reque~t from application program S30, aearch~s the common data structure 140 lr~ sla~e database 520 ~or all attr~bute data ob-20 ~ct~ of the spec~ied type. When thos~ specified attribute data ob~ect~ are ~ound, the attribute data objects are extracted, converted into the appropriate format, and sent to retrie~al program S80.
Pr~fer~bly, retrieval program 590 perform~ the ~ame func-2S tions ~ retrieval program S~0. Th~ only ~unctional d~r~or~nce UwO"~O.~ between re~r~val programs 580 an~ 590 would re1~ct the ma~ner ueGN,H~ ~0N
.~RR~r OD~NN~R
~ ,-" ~-o~,~,c,~ooc~
~ I,o,~ 20-RPR 1~ '89 14:4Z FROM FINNEG~N HENDERSON P~GE.023 .~ .................... . , ' , ` ~308~98 ~jin which infor~ation is tr~n~mitted to applica~fon programs 530 and 560. For example, retrieval program 590 could perform a se-,.rie~ of retrievals as described a~o~e, converting the da~a soobtained into appropriate format for application program ~60, and write this data into a f ile 595. Application program 560 would then read the retrieved data from file 595.
Further in accordance ~ith the present invention, the data processing system in~ludes means for crea~ing a new attrib~te , data object in the common data structure from an identification 10~ of tho attribute dat~ object desired to be the holding attri~ute ' data object for the created attribute data o~ject. That ' creating means could also include means for creating the new ,, attrlbute data object from an identification of a referent data `
, ob~ect as well to ~orm the created relation data object.
15j', Fig. 5A shows differsnt ways ~or creating new attribute data obj0ct~ in the common data ~ructuro 140 according to the ~, prof~rrHd embodi~en.t of the in~rention, For exampl~, application program 530 uses converter ~rogram S~0 which rocelves tho neces-, sary informatio~ from a database ln application program 530, 20!¦ oxtracta the needed in~o~mation ~o~ ~orming common data struc-~,¦ ture 140 in master database 510, ~d then constructB attributedata objects by determining the holder attribute dat~ objects 3 and the roferont data o~jocts. Convortor program 540 thon sends ~ thos~ a~tribute ~ata object~ to master databsse 510 ~r storase.
2~i As another example, information created in application pro-~w,~",c.. '3 ~r~m 530's database ean be sent to m~ter database S10 as ~N~H~ND~N:l F~,~FT j, oto~.t,.c.~ooo- j . .

RPR 13 '89 14:43 FRO~ FINNEGRN HEN~ERSON PRGE.024 :. _ 1308~98 follows. ~irst, applicati.n program S30 sends a r~quest to up-date sync~ronizer 550. This r~quest inclYdes information ¢har-acterizing the dosired update. Update synchronizer ~50 th~n modifies ~aster database 510 by sign~ling converter program 540 S to modify master database S10 by creatin~ attribute data objec~s in common d~ta str~cture 140 using in~ormation from application program 530, Update synchroniz~r may also be used to create attribute data objects in master database Sl~ ~n accordance with the characterization information in the ~pdate request, Preferably, converter program 570 p~rforms the same func-~ions~as converter program 540. The only difference between converter program~ 540 and 570 ~hown in Fig. 5A is the manner in which infor~ation i~ transmitted from applicat~on program 56~.
Application pro~ram 560 first writ~s data into a file ~6S. Con-verter program 570, aft~r receiving a signsl from updat~ syn-chron1zor SS0, read~ ~ile 565 and creates attribute dat~ objects in common datA structure.140 of ma~t~r database 510 ln accor-dan~e with data in ~lle 565, Modi~ication~ of master datab~sQ S10 and signals to con-20, v~rter programs S~0 and 560 Rr~ p~rformed by ~pdate synchronizer 550 to en~ur~ that ma~ter database 510 is upda~ed in a r~gular and nonintarruptive manner while the common data struct~re 140 ln master database 510 and slavc database 520 are used by appli-cation pro~ram~. Upon completion of modificat~on5 to master 2S database 510 by converter progr~m 540 or convert~r program 570, ~orr~c~ n ~opy of the common data ~tructure l~ o~ ma~tor da~aba~e 510 Fl~e~N.H~ND~
F~W~W ~nT
~D~N~ ) ,~," " """~, ", w. :
0TO~, O, e, -OOO~
~o~ a - f, ~, -RPR 13 '8~ 14:44 FRO~ FINNEGRN HENDERSON PRGE.0Z5 13~81g8 is then made available as a new version of slave database 520, where it may be a~essed by retrieval programs 580 and 590.
~ he present invention also includes means for remo~ing a specified attribute data ob~ect from the common data strl~cture.
This is sometimes known as an erase op~ration and is easily per-formed due to the hierarchical data arrangement of the common data strUcture 140. In the preferred embodiment, a database modifying program such as converter s4o first locates a specified attrib~e data ohject in response to a requ~st re-ceived from application program 530. ~hen converter 540 removest~e att~ibute data o~ject from tha common data structure 140.
~ n ~daition, appli~ation program 530 can r~quest not only that the spocified attribute data o~ject be removed, but also that th~ entire containment tree for that attribute data o~ject be r~moved. In response to such requests from application pro-gram 530, converter 540 locates the specified attribute ~ata ob-~ect. Convortor 540 al50 locat~s all attribute data objects which are held by the 5p~cif ied attribute data object, Con.
verter 540 traverses through the contalnment tree by examining 20.~ holding rel~tion~hips and locating all of tho ~ttribute data ob-~ect~ which are h~ld diroctly or indirectly by thR originally ~ speci~ied attribute data ob~cct, Converter 540 removes all lo-" cated attribute data objects ~rom common d~ta structure 140.
~ F~gurc 5B shows a block di~g~am o~ an alternate embodimen~
o~ the componen~ o~ thc software ~y~tem ~n common dat~ struc-- ~wO~c...... ture 140l. The it~ms surrounded by the dotted line, appli~ation ~11' NCGA~J, Htt~DE~saN, m~ . W, ~A~hl~ lTen~, D, C, ~000-~
~o~ o -23-. , , RPR 1~ ' as 14:44 FROM FINNEGRN HENDERSON P~GE.0Z6 " ,, r`- , -f ~308198 program 530, converte~ program 540 and retrieval program 580, are essentially identical to the corresponding elements in Fig-ure 5A.
Common data structure 140' in Fig. 5B contains a master ~ 5 data f ile 515 and a snapshot data file S25. Like slave database ; 520 of common d~ta structure 140, snapsho~ file 525 of common data structur~ 140' c~ntain~ at lea~t on~ complete copy of a ~ersio~ of master data ile S15. However, unlike slave database 520, snapshot file 525 is desiqned to represent a plurality of 10. ver~ion~ of master data fil~ 515 by storing portions of master data file Sl~ which have been updated. In contrast, slave d~tabase 520 is designed to represent complete copies of the current version of master database S10. ~ommon data str~tcture 140' ~lsc includss a control file 555 which includes data neces- :
sary or the control of t~.te co~mon data ~tructure 14~' as well a~ certain locks to prevent simultanoous access o~ structure 140' by ~ever~l application progr~nts. Two of thfl locks whi~h are shown are A~ER lo~k 568 and D3C lock 569. ~hese are expl~ined ln gr~at~r det~il below.
In addition, ~torage management software 566 is shown a~
, providing ~n interf~ce between common ~a~a structure 140' and the ~of.tware encompasqed b.y ~he ~otted lines in Figure 5B. A
preferred embodim~nt of por~ions of storage mana~ement ~oftware ~ 566 will be ~xplained in greater detail b~low.
25~' uw O~C~ .
Ft~tt~W, HtND~
h~uo~Gu~t~r ~ Du~R ;, 1~7~ tn~ N. W, 0~1, O, O. ~ooO-10~ 0 -2~-.. . .

. : .:,. : ,., RPR 13 '89 14:45 FROM FINNEG~N HENDERSON PRGE.027 ~.

, C. Data Structure RePresentation o the Co~mon Database In a pre~erred embodiment of the invention, eommon data structures 1~0 or 14~' are st~re~ in memory 120 along with application programs such as programs 132 and 134, This arrangement is shown schematically in Flgure 6 as is the pre-¦ ferred organizatio~al structure of common data ~tructure 140 into a plurality of files.
As Fig. 6 shows, the co~mon data structure 140 portion ofmemory 120 preferably includes an ~ttribute file 600, a dic~io-nary file 700, and an index file 800. Prior to a d0tailedexplanation of these files, a general description of the files' functions w~ e provided to facilitate an understanding of the ontire sy~tem~
Attribute file 600 preferably includes all of the attri4u~e data o~jects or, ~oro precisely, a memory area or data ontry for each o~ the attribute data ob~acts. In the preferr~d embodiment of attribu~e ~ila 600, the attribute data objects, including both as element data ob~cts and relation data objects, are,or-gnnlzed in a manner whlch iS con~istent with the in~ormatlon in ~0 the databa~e~ of programs 130, 132 and 13g. Por 0xample, ln a " manner de~cribed in greater d~tail below, nodo data and node data do8criptor~ o~ the database5 are correspcnded to element and relation data objects, and the hierarchical holding rela-tion~hip i~ imposed on the attribut~ data o~jects in a logical 25 : manner dacigned to facilitat~ the acce~ to and identi~ication ~WO~ of desir~d nttribute data o~ect~.
FI~N~N, ~l~tJD-~
F~ow, C~rr ~ DUNNU~ :
TlK~r, IL W.
W~ OTOII, O, C . ~ 04 0--,-o.,.. ,.~o -25-. ' , ~ ,.,.: . , RPR 13 '~9 14:46 FROM FINNEG~N HEN~ERSON PQGE.02 r--~
~30~3198 Dictionary file 700 pref~rably includei~ data entries fo~
the ~pex and other contexts, as well as inform~tion descriptive o~ the type of attribute dAta ob~ects in attribute ~ile 600, The data entries for the apex and contexts c~uld instead be stored in the attribute file, but those entries have been stored in dictionary file 700 in t~e preferred embodiment of the inven-tion because that file is treated primarily AS a read only file, ~nd the apex and context data generally do not change.
Index file 800 preferably includes information used by CPU
llO to obtain quick access to attribute data objects in the attribute file. Index file 600 is designed to take advantage of csrtain features of many pra~tical implementations of data str~cture 140 to increase the ef ficiency with which data struc-tu~e 1~0 m~y be used.
1~ In the preferred embodiment of the present invention, attribute file 600, dictionary file 700, and index file 800 in common d~ta structure 140 are ma1ntained in a "p~rman~nt" memory section o memory 120, isuch a~ a disk. When CPU 110 needs to acceisi~ certain portions of ~ile~ 600, 700, and 800, CPU llO
~ trani~L'er~ thos~ portions to a primary ~emory, ~uch ai~ semicon-ductor ~AM m~mory. The permanent mem4ry is relatively large in comp~rison wlth the primary m~mory and CPU 110 preferably man-' aq~s the flow of data between thelpermanent memory and the p~i-mar~ ~emory in using known vi~u~l m~mory ~chni~u~s and in d pre~errod manner set forth ~low.
~ c~
Fl~t~w~ H~ND~
~, C~R~

r~ sT~t~T. ~, w.
~n~ TO~l.P.C.~-~.0,, ,,~.. ,.0 --~ 6 -RPR 13 'B9 14:46 FROM FINNEGRN HENDERSON PRGE.0Z9 `` 1308198 , - . Preferablyr data in each o~ the ~iles in common data stru~-ture 14~ ar~ gro~ped in macropatges, ~ach macropage is a eontig-uous 64X byte portion of a file which oonsi~ts of 128 512-byte pages. In known embodiments of the invention, attribute file 60~, dictionary file 700, and index file 800 h~ve permitted up to 16K macropages of storage.
In the preferred embodi~ent of this invontion, the standard , unit of data in attribute ~ile 600, dictionary ~ile 7~0, and index file 800 is ~ longword composed of four bytes or 32 bits.
The pages or macropages of the files typically include soveral blocks each of which consists of a group of several longwords.
Often the long~ord is us~d as a pointer,.
Fig. 7 ~ho~s a 32-bit longword 615 used as a pointer. In tho preferred ombodim~nt, ~PU liO derives lo.~gword pointer~ ~or lS each of th~ data blocks in the files of com~on tata struct~re 140. . .
According to the preferred embodiment, longword pointer 615 includes a le~tmost b~t, or 'rEMP field 616, which indicate~.
whether the block o~ memory to which this polnter "points" is 2~,, not p~rt o~ the permanent data stru~ture, in which case the rest o~ the pointer ~ the virtual address of th~ block in primary ! t mcmory. ~h~ othe~ f~elds shown in Fig . 7 apply only when the ', block is part of tho p~rmanent data structure located in perma- ,.
i; trorls~erreA `~
, nent ~nemory 4nd ~~ ho~ to prim~ry memory ~s neede~. ~t~i XIND ~eld 618 i~ two bits long an~ te~ignates t~e kind of F~w~He~ block to wh~ch longword pointor 615 point~. For ~xample, in ~h~
F~,~Tr ~D~R
17.7- 1'. 7~-Fr, ~1 ~. "
w~ 70~, 0, e ~OOC~
,,0~,,.~. o -27-' ' ~PR 1~ '89 14:47 FROM FINNEG~N HEN~ERSON P~GE.030 . ~` ~

preferred embodimen~, this field indicates where the block pointed to is in attribute fila 600, dictionary file 700, or index file 800.
The next ~ield, R f ield 620, is; one bit wide. R ~ield 6~0 is presently reserved to allow an additional kind of pointer to be defined for use with the present invention~
Tho fin~l field of longword pointer ~15 is OFFSET field 622 which comprises the twenty-eight rightmost bits of longwQrd pointer 615. OFFS~T ~ield 62~ identifies the referenced infor-mation by specifying the location of that inform~tion as alongword oset from the b~ginning of a file containin~ the re~-ere~ced bloc~, ~ The pointers used in the preferred embodiment are not the only ones necessary to effect the present invention. For exam-ple, th~ po~ntors can directly indicate t~e location of the cor-re~ponding ltemrO or can indicate that loc~tion indirectly through pro~edures such d~ indirect or indexed addressing.
1. ~t~r ikut~ Fi l e Plg~ 8 ~how3 B more det~iled block diagram of the constitu-~nt portlon~ oi~ attribute ~ile 600, Attribute fil~ 600 includes " s~veral element block~. Only one elemont block is. shown, how-evar, for simplicity, and.~or description purpo~es in thi8 ~ec-! tion, the attri4ute data object represented by olement bloc~ 602 , will be c411ed th~ "repr~sented element.~ ~he elemen~ block is th~ b~ic data unit for represonting an ele~ent attribute d~ta ~WO~C~ ob~ect in the pr~orred ~mbodim~nt of attribut~ R 600.
F~W,~ C~RSrr 0 Ds~ R
IS!7- S~ S~. S,~, W~
~511110~01~,0 C~loO~
~o~o~ o ~1 -2~-, . .
. . .

RPR 13 '89 14:~8 FRO~ FINNEG~N HENDERSON PRGE.031 . .
.Element block 60~ pref~rably lncludes one element header block ..604, one or more relation sub-blocks 60~ (optional), and one or more "held" element sub-blocks 608 (optional). Information :regarding the n~mbe~ and type of contiguous sub-blocks in ele-5 ment block 602 following element heade~ block ~04 is preferablyprovided in dic~ionary file 700 or through the use of a com-pil~r. These blocks and sub-blocks are descri~ed in detail below.
Attribute file 600 also includes pl~ral relation blocks 10 . 610, only one of which is shown for simplicity. Ea~h plural re-' lation blo~k 610 contains data for on~ or more relation data ob-:' ~ects representing the non-hierar~chical relationships in data structure 140. Plural relation blo~k 610 p~eferably includes a , plural relation header block 612 and one or mor~ plural relation 15 ' #ub-blocks 614. The~e blocks and sub~~locks ar~ also describ~d " ln detall below.
Flnally, attribute file 600 includes instance root blocks 625 nnd index dict~onary block~ 630, only one of each of wh~ch i~ ~hown ~or simplicity. Thes~ two blocks a~e described in 20',', det~il below.
'¦ Pig. 9 ~how~ a block diagra~ of el~ment header block 604 in ¦ tho preferred embodiment o~ the invention. In thix embodiment, ch attribut~ data object in data structure 1~0 would be repre-~ is~nted b~ an elemént header block, ~uch ai~ ~lement header block 25"' 604. Aa ~hown, element head~r block 60g includ-s 8iX longwords .j F w4H~te~ 900, 920, 928, 930, 935, and 9~0.
F~R~ow. ~ j, O DUNN~
W~ 070~ .0~000- i-U14~1Jl~ 0 ' _~9_ RPR 13 '89 14:48 FROM FINNEGRN HENDERSON PRGE.032 . ,_ ~

Longword 900 preferably includes a blank field 905, a SIZ~
field 910, and ~ CL~SS field 915, SIZE field 910 indicates the number of longwords i~ element header block 604. CLASS 915 in-dicates that block 604 is an elemen~ header block.
Lo~gword or TYP~ DE~INITIO~ pointe~ 920 specifies a loca-tion i~ dictionary file 700 containin~ element type Information for the repre~ented element. Type in~ormation could also have been made available to common data structure 140 by some other mean~, for example, through tha use of a ~pecial.compiler which 0 al~o could sstablish the apex, o~her contexts, and identifiers.
. ~or cont~xts.
U~XT and PR~VIOUS pointers 92~ and 940, respectively, des-ignat~ the locations of element blocks ~or attribute data ob-jecta having the sa~e holder attribute data object ~s ~he repre-15 , sented element. In th- preferred embodimen~ of the present inv~ntion, attribute data o~ect~ o~ a common type having the same ~old~ a~trlbute dat~ obj~cts are llnk~d by use of these lon~word ~o~nter8. The N~XT and PR~V~OUS polnters 925 and,940, r~pectively, ~f~ect ~uch link~ng.
HOLD~R ~nd R~F~ENC~s pointers 930 and 935 of element he~der block 604 respectively indicate the hierarchical being-h~ld relation$hips and non-hierarchical r¢lations betw~en the , ~e~resentcd eloment and other attribute data objects represented , in ~ttribut~ ~ile 600. HO~D~R point~r 630 p4ints to the element 2SI block for an attrLbute data objec~, i.e., the ~holder obj~ct~
~wo~r~CC~ : with which the r~presented attribute ~ata object ha~
FlN~eC~N H~NDeR.SON .
6~ Du~t, ~cn, ~. w.
'lAll~ OTOI~"~ OOO~ ' .
uo~ o~ 30- .

.. . .

. .

RPR 13 '89 14:49 FRO~ FINNEG~N HENDERSON P~GE.~33 !i .~ , ,.~, ,.

'l . . . .
being-held relationship. Thus, HOL~ER pointer ~30 points to the ~, element block of the attribute data object which holds the l qttribute data object represented by element block 60~.
,I The REFER~NC~S pointer 93~ points tO a first of a sequence 5 . of plural relation blOCkS (8.g., block 610 in Fig~ 8) in . a~tribute fil~ 600. Those plural relation blocks indicate the attri~ute data objects which hold relations of which the repre-sented element is a ref erent data o~jeot. The details of pl~ral ., relation blocks are discussed below, Relation sub-block 606 and held" element sub-blo~k 608 of object block 602 (shown in Fig, 8) are preferably contiguous sub-bloc~s whîch are also contin~uous to elem~nt header block ~; 604. For each object block there may be se~oral relation su4-~I blocks and several "held~ element sub-blocks. Relation s~b-15¦¦ blocks 606 specify referent attrib~te data objects for singular ,I r~lation~ held by the represented element. "Held" ~lem~nt sub- i ~ block 608 specifies the attribute dat~ objects which have a ~, .~ being-held relationship with the r~presented elemen~. The rela- l ,i tion ~ub-block~ 606 and nheld" element sub-blocks 608 for the 2q¦ represented object pos~ibly appear in mixed order.
Fi~s. 10A and 10B show block diagram~ of the pref~rred em~odiment of relation sub-block 606. Relation sub-block 606 ¦¦ proforably contain~ on~ of two kinds of information. If rela-~I tion ~ub-block 606 is a relation pointer, then it appears as a 2~1 longword or R~LA~ION ~ointer 1000 (Pig~ 10A) which spQc1fies ~wO",c.- . ~ith~r an elom~nt block o~ a single referent attribute data PINN~6~, H~ID~P~I I
F~W, cu~rr at~u~N~h 1¦
I~S 1~ T, N. W. I
WA~NlNlnaN. Il. C,~004~1 i ,.O.~ , -31- ~

!; . .

~r~ 13 ' 0~ 1~; 5~3 rl~0~1 r ~ Gl~li IlCllD~1~501~ r~G~

; ~ 1308~98 obje~t or a plural ~elation block (e.g,, block 610 in Fig~ 8) which in turn identifies sev~ral referent attributs data objects .for the r~lations held by the represented element.
Alternatively, rela~ion sub-~lock 606 may ~e a 5 NVMERIC/ST~ING identifier for identifyin~ a n~m~ c or date, or :f/i nu,r ~et~l~
a string. If relation sub-bloc~ 606 is a n~mb~P~ng or date identif ier, then it ~pp~ars as doublR longword. Identifier 1050 may be a pointer to an element block representing an attribu~e data object for a character string or may itself be an integer or floating point const~nt or a date.
Fig. 11 shows a ~lock di~gram of the preferred embodiment . of ~held" element sub-block 6~8 shown i~ Fig, 8. Sub-block 608 includes longword pointers 1100, 1110 and 1120, Longword or FIRST pointer 1100 identiies an e}~ment data block of the ~irst lS ~n a Yelected order of attribute data objects which have a being hald relationship with the represent~d element. If only one attribute data object has that relationshipr then FIRST
pointer 1100 ldentifies that attribute d~ta object, Longword or LAST polnter 1110 identlfies the la~t in the selected order of 20,, ~uch attribute data objects, but al~o identifies tho f irst attribute data object i$' only on~ held object ~xists, The Ye-lected or~er of attribute tata objects having a being-held rela-tlonship with the represented object is the linkage de~ined by the NEXT and PR~VIOUS pointera of those "held" attrib~te data 2S', object~.
UM~ O~l-lC~
F~ 50N:
FM~r, C~RR~rr ~ DUI~ A , .
IC~T. r~. W.
~rlmCTO~, D. 1000 ~o~tO~ 0 , - 3 2~

,, .
:. .

~PR 13 '89 14:51 FROM FINNEGRN HENDERSON PRGE.035 ,. ,s~ ~
' ~308198 - Longword or l~D~X pointer 640 cont~ins a pointer to an index directory block. These blocks are deacri~ed in greate~
. deta~l below, ~nd the function of INDEX pointers 6~0 will be un-derstood from that description.
As expl~ined abo~e, plural rel~tion blocks 610 provid~ an e~ficient ~eans of reference when several re~e~ent attribute data objects must be identi~ied. Each plural relation block 610 includes a plural relation header block 612 and one or mor~ plu-ral relation sub-~locks.
Fig. 12 ~hows a block diagram f or pl~ral relation header block 612 a~cordinq to d preferred embodim~nt of the present invent~on. Plural relation header block 612 comprises longwords .
1200, 1210, 1220 and 1230. r~ongword 1200 includes a USE ~ield 12~3, an ~NTRIES fi~ld 120S, a SIZE f ield 1207, and a CLASS
fiold 1209. US~ field 1203 indic~tes the last one of tha plu~al ; relations su~-blocks 614 ~or header block 612 whi~h may contain ! a ~lid pointer. ~NTRIES fleld 1205 contains the numb~r of con- .
~iguow plur~l reli~tion ~ub-block~i 614 following header blocik 61Z which ~r~ in~luded ~n plural relatlon block 610, whether 20 : tho~o sub-block~ contain point~r~ or not. ~IZ~ ~ield 1207 and , the C~ASS field 1209 ~ndic~te, r~sp~ctively, the numbcr of 'j longword~ in plural relation block 610 and that ~his header ; blok 1~ i~ plural r~lation header block.
, BIT MASK Sl~ld 1230 contain~ bit~ in~lc~ting whlch 25i ~ub-blocks 614 contaln v~ polnter~. Thus, although ~he ~S~
U~O~C~- ' fiel~ ~ndicat~s the largest numborsi o contiguou~ aub-block3 f~N-GW,H~NDC~W~
F~w~G~RT
~D~
T~ r"~, ~. , , W~ ~O~I.O a.~ooo~ 33_ ~O~ o ~PR 13 '89 14:51 FRO~ FINNEG~N HENDERSON P~GE.036 rf~
1308~L98 .
w~ich may have valid pointerS, ~ot all of those pointers may necessarily by valid. BIT MASK field 1230 supplies this latter infor~ation, Plural re}ation blocks are linked in a manner similar to 5 the linkage of element bloeks for attri~ute data objects having the same holder attri~ute data ob~ect. Accordingly, header . block 612 includes N~XT and PREVIOUS lon~word pointers 1210 and 1220, resp~ctively, whi~h specify next and previous plural r~la-tion blochs in a selected order of such blocks. The plural re-la lation head~r blocks in th~t ord~r are all used by the same holder attribute data object.
Figs. 13A and 13B show~ block diagrams o~ pref~rred embodi-ments of two kinds of plural relation sub-bloc~s 61~. If the re~erent attribute data o~ject is an element attribute data o~- :
15 iect other than a string, number, or date, then, RELATION point- .
. er 1300 i~ a longword which points to the element block for that .
attributo d~ta object. I~ the referent attribuee data obje~ is a numbor or date or a character ~tring, then NUMERIC/STRING.
: fi~ld 131~ is used to point to a floating point number, or date, 20, or a block repreaenting a character ~ring.
~re~tlon and u~e of element block 602 and plural relation block 610, according to the teachings o~ the present inv~ntion, are d~scribed in ~urther deta~l below. As can now be readily l appreciat~d, the d~ta structur~ representations for attribute Z5 , filo 600 di~uss~ above embody the principl~ of an Attribute u~or~lcs~ ~4ta mod~l accordinq to this ~nvention.
F~N~G~,H~u~
F~WK~G~R~
~t~JN~
~n~ ~ T~Ct-, ~1. W. ,:
~D ~ Ob,D C,~oOO--I~O~t~ O ' l - 34-RPR 13 '89 14:5Z FRO~ FINNEG~N HENDERSON PRGE.037 ~308~98 ~ he contents and strueture of an instance root block are shown in Fig, 1~. "InstanCes~ of an element type refer to a set . of attribute data objects all having the sam~ element type and : all ha~in~ the sa~e holde~ attribute data objeet. It has ~een S determined that such groups of attri~ute data objects are refer-enced often. ~hus, the instance root block was developed ~o pro~ide an ef~icient mechanism to access s~ch attribute data ob-iects. ~ocating instance root block 62S in attribute file 600 allows it to be dynamically upd~ted more easily than if this block wore located in essentially read-only dictionary file 700. .
Instance root block 600 ¢omprises a longword 1~10 which in~
cludes a SIZE ~ield 1413 and a C~ASS field lgl6 indicating, re-spoctively, the numb¢r of longwoods in root block ~25 and that , block 625 i~ an inRtance roo~ block.
1~ Instance root block 625 al50 includes FIRST and LAST point-er~ 1420 4nd 1430, re~pectively, which indicate first and last attrlbute data objects ln any ~et. Pre~erably, pointers 1420 and 1430 idontify the locations of the ~lement type blocks ~dls-cw 30d in a l~ter section in relation to tlctionary file 100) of ~ho~e tttribute data objects.
" An l~D~X point~r 1440 of block 625 points ~o an index diroctory block (de9cribed in detail below) in attribute ~ile 600 which permit~ ready acce~s to each ln~tanco of tho linked ~ t o~ at~ribute data objects, the first a~d la~t objec~ o~
which aro ~pecif i~d by ~ointer~ 1420 and 1430 of instence root ~w orr~a~ ' block 600.
Fl~tnG~, ~UD~
F~,G~T
O DUrJ~R
WA~I I 4T , O O, COtl-- _3~_ , . . .

RPR 13 '89 14:53 FROM FINNEGRN HENDERSON P~GE.038 ~' ~
. 1308198 :, (2) ~
Fig, 15 shows a block diagram of a preferred embodiment of dictionar~ file 700. In the preferred embodiment, ~he portions of the ~ommon database structure in dictionary ~ile 700 include an apex block 702, other context blocks 70~ and 706, element type ~locks 710 and 712, attribute type blocks 714 and symbol ta~le 716, Apex block 702 is a special kind of context block which repr~se~ts the ape~ data object. According to the basic rul~s o~ the Att~ibute dat~ model of the present invention, th~ apex data object hol~s contsxt~ or attribute data objects~ but is not its~lf hqld by any context or attribute data object.
Cont~xt blocks 704 and 706 are used to represent a context such a~ CPU 420 de~cri~ed in oonnection with Fig. 4. Ele~ent type blocks 710 and 712 each repre~ent a different type of attribute da~a object ~n attribu~e flle 600. Pre~rably, for ~ach dif~eront ty~ of attrlbute d~ta object there i~ a corro-~ponding element type block. Attribute type block 714 includes in~ormatioh regarding the typo of rolation~ which exist~ between 20,'. attribute data ob~ects of a spe~ified typo and refer~nt~ for 'i the~e attribut~ data ob~ct~. Symbol table 716 contains ! ~dontif~r~ for the apdx, cont~xt~, ~lement type~, an~ attri~t~
'!
,, type8 ropre~cnted in the different block~ of dictionary fil~
, 7~0.
25, A~ expla~ned abovo, ~pex block 702 and context bloc~s 704 ~wor~e~ and 7~6 are pr~fer~bly 3tored in ~ict~on~ry f~le 700 because f~NN~ NI~
F~v. C~ m ~ DU~
W~b~ To~o~c~oclo~
00~ 0 ~ ~7 V

. -."' , ~PR 13 '89 14:53 FROM FINNEG~N HEN~ERSON PRGE.03~

.dictionary file ?00 is usually a read only file. Apex block ~02 and context block~ 704 ~nd 706, which are very similar and will be di~cuss~ together, are generally not ~odi~ied and thus are primarily fo~ a read only file.
Fig, 16 shows a block diagra~ for th~ basic structure and contents of the preferred embodiment of eith~r apex block 702 or context blocks 704 or 706. Because of the similarities of ape~
and context blocks, only the file struct~re for context blocks ~ill b~ discussed with the understanding that the file structure 10 . for apex bloc~s is si~ilar.
In cont~xt block 704, long~ord 1600 include~ a SIZE fi~ld1603 and a CLASS field 1606. SIZE field 1603 indicat~s thé num-ber of longwords of context block 70g, and CLASS field 1606 in-dic~tes e~the~ that the block i~ an apex block or a context block.
Longwor~ or NAM~ ~ointer 1610 ~dentifies an ~ntry in symbol table 716 ~e~ ~ig, 14) specifying ~n i~ntifier ~or the apex or other context r~pre~ented by block 704.
L'ongword or FIRST CONTAINÉD CON~XT pointer 16~0 point3 to the fir~t con~ext block of a set of contexts which a~c held by .I contcxt block 704. Pointers 1630 and 1640 described b~low, are e~pty in apex block 702.
Fcr context block 704, Longword or ~X~ pointer 1630 points to the next context in the ordered ses o~ con~exts just ~5 de~cr1be~. Longword or ~OLDER pointer 1640 ~o~nts to the con~
~O~c~ text block or apex block o~ the context or apex which holds the F~W~, Hl~ D~
~D~ context for block 704.
177~ 4 ~ T~ ~, '~I.V,411~04, O, C, ~OC~
UO~ 0 ~ , -37-RPR 13 ' 89 14: 54 F R01`1 F I NME GRN HE NDE RSON PI~GE . a4E3 1308~98 . Longword or FIRST osJ~c~ TYPE pointer 1650 points to a first one o~ an ordered set o~ element type blocks, e.g., blocks 710 or 712. The ~lement type blocks in that ordered set repre-s~nt ele~ent types of attribute data objectC held by the context represe~ted by context block 704, The ord~red set is prefera~ly a link~d list as explained below in the description of element type blocks.
~ ongword or FIRST SYMBOL pointer 1660 identifies an en~ry i~ symbol table 716 which is designated as a fir~t symbol for 10. th~ ~irst of an ordered set of symbols for other contexts, ob- :
' jects or relations held by the context represented by block 704.
Preferably, the apex data object or a context attribute data obj~ct provid~s tho first or top portion of a containment tres. Acces~ to an attri~ute data object of a sp~cified element lS type in a context may be obtained by entering th~ containment ' tree through the apex ~nd by proceeding through the tre~ to the the contoxt in wnich the de~ir~d attribute data.object i~ found.
Because the ~pex and contexts are represented by apex ~nd con-téxt blocks in dictiona~y file 700 in the prefe~ed embodiment of the invention, entry into the preferred embodiment of th~
,j data ~truCture through the apex or cont~xt requires access to ! the information stor~d in the apex or context blocks in dictio-, nary f ~1~ 70~. In di~erent embodim~nt~ according to this ~, inventlon, acce5$ through a dictionary file would not b~ re-25 , quired.
~ O~lc~ I ' ..
FI~N~C~, H~ND~R5CN
. G~R~m ., a DVNN~ !
~n~ T~en. N. W, ' I
~-nlNO~O~, O. C. ~000-UO~ O -3~-. . , RPR 13 '89 14:55 FROM FINNEG~N HENDERSON P~GE.041 f ~ ' ~3()8198 Fig. 17 shows a block diagram of ~ pref~rr~d e~bodiment of an ole~ent type block such as ele~ent type blocks 710 or 712.
For purpo~es o this description, ele~ent type ~lock 712 alone will ~e described wi~h the understanding that element type block S 710 has the same components.
For each type of element in attribute ~ile 600, there exi8~s an ele~ent type block 712 i~ dictionary file 7~0. In the preferred embodiment, the creation of an element of a certain type Ln attribute file 600 must be preceded by a declaration that elements of that type may exist. ~he mechanism for repre-senting the existsnce of objects of a specifi~d type is element ty~e block 712, Eleme~t type ~lock 71~ contains g~neral parameters for cer-tain element blocks in attri4ute file 600, for example-, informa- :
lS tLon reg4rding the length of those element blo~ks and informa-tion rc,garding tht. instances o~ ~ ~iven element type.
Th~ contents and ~tructure olT element type block 712 are as ~hown ln Fig. 17. Included in ele~ent type bl~ck 712 is longword 1700 which has SIZ~ ~ield 1703 snd CLASS ~ield 1706.
A4 Ln the case with other data blocks, SIZE field 1703 indicat~s ' the n~nber o~ longword~ in cle~ent type block 712 and the CLASS
fleld indicate~ that block 712 is an ~lement type blo~k.
Lonsword or NO~ FORM f Leld 1710 lndicates whether attribute d~ta object~ o~ th~ type sp~clfied by elem~nt typ~
2S block 712 have a pr-determined ord~Tr e~nd whc.ther th~ elem~nts o~
",e....... thi~ type are.. held by a context or held b~ other ~l~.ment~.
F~ w.Ht~D~
~D~NIR
orl~ o~ ooo- _ ~ 9 _ ~o~ o ., RPR 13 '89 14:55 FRO~ FINNEGRN HENDERSON PRGE.042 1308~98 : Longwo~d ~r NAME pointer 1720 points to an entry in symbol table 716 having a name or identi~ier for attribute data objects of this type, INSTANCE LE~G~ fiold 1730 spocifies the length of an element block ~02 for attribute data objects o~ the type S specified by block 112.
As indicated above, element type blocks for types of attrib~t~ data objects contained by (i.e., in the containment tree for) the same context are pre~erably organized into ordered sets. In fac~, these blocks are preferably linked using longword or ~ExT pointer 1740, which specifies the next element type block~ ;
Longword or CO~T~XT pointer 1750 points to th~ context block or apex block in which elements of ~he type specified by block 712 ar~ ~ontained. Longword or INSTANCE pointer 1760 points to an ~nstance root block in ~tribute f ile 600 which contain~ pointers affording access ~o each o~ the instances of an elemçnt of this typo in attribute file 60~. The r~maining ~i~ld o~ element type block 712 includes l~ngword or ATTRIBUTE
pointer 1770. ATTRIBU~ polnter 1770 points to the ~irst rela~
zo. tion ty~o for relation typ~s contain~d by thi~ elem~nt type.
Dictionary filo 700 also provid~ a ~echanism for speci-fy~ng the ty~es of rel~tions which may exist botween attribut~
~ data objects of a type s~clf iod by an element type block 712 :. and their roferent attrib~te dat~ ob~ects. This ~e~hanlsm in-clu~es attriPute t~pe blocks such as block 71~ (s~ Fi~. 15).
~ O~C~
FINN ~,H~ND~CN :
FM~W,~R
~ DUtJ~J~R
177~ K ~ . W.
,W~o~,O.O,~OOO- A 1'1 (~00 ~ 0 --'~ U--,, , , ,:

RPR 13 '89 14:56 FROM FINNEGRN HENDERSON P~GE.~43 1308~98 - Fig. 18 shows a block diagram for attribute type block 714 according to a preferred embodiment of the pre~ent invention.
Attribute ~ypa block 714 includes longwords 1800, 1810, 1820, 1830, 1840, 1850 and 1860. Longword 1800 contains SIZE field 1803 and CLASS field 1$06 which indicate, respe~tively, the num-ber of longword~ in blo~k 714 and that blo~k 114, ~ongword or REPSTYLE field 1810 indicates the manner in which relations for attribute data o~jects are to be specified.
According to the pref erred embodiment of the present invention, relations between attribute data objects ~nd their referent attribute ~ata objects may be ~pecified either directly or indi-rectly. For directly specified or singular relations, ~ rela-tion ~ub-block 606 (see Figs, 7 and lOA~ in the element block 602 contain~ the pointer for.a refarent attribute data object.
~or indirectly specified or plural relations, a plural relation sub-blo~k 614 o~ a plural relation block 610 ~see Figs, 8 an~ 13~ acce~aed from the object block 602 or thQ referenced object contain~ pointers to the r~erent ~ttribut~ datd objects.
Lon~word or NAME polnter 182~ of block 714 point~ to ~n identifi~r entry in symbol table 716 for attribute type block 714. Longword or OFF8E~ ~ield 1830 contains an offset from the , be~inning of an ~lement block 602 ~or a relation ~ub-block 60 ! representing relation~ of this type, or an of~et for a held .element ~ub-block 60a repre~enting elements o~ t~is type.
Att~ibute typ~ blocks 714 for a gl~en e~ement typ~ are ~wo~r~o~ ~ linke~ by me~n~ of a ~XT pointer l~gO in the msnner d~scribed FI~G~,H~5~X~
PA~U~r,~nT
aP~
IYrS 1~ ."~. w.
~A~ , D. ~ 04C~ 41 uO~ 0 RPR 13 '89 14:57 FRO~ FINNEG~N HENDERSON P~GE.044 ~ . .
1308~98 : abeve for other linked blocks. Longword or HOLDER pointe~ 1850 points to the element type block 712 for the type of attri~te data object whic~ holds the type of relation specified by attrib~te type block 714. ~ongword or R~FEREN~ TYPE pointQr 1860 also points to an element type block, but ~hat element type block is one specifying the type of the referent attribute data objects in the event that at~ribute type block 714 corresponds to a r~lation.
(3) Index File Index file 800 provides another efficient and direct means . to acces~ attrib~te dc~ta obje~ts which share a common holder attribute data object. Specifically, index file 800 provides a ~ean~ for accessing certain ones ef the s~ttribute data objects to which unique key values have been assi~ned.
In the prefsrred embodi~ent, index file 800 comprises sev-eral lndex branch 410ck3 organiz~d into at leas~ one index having ~ tree structure. ~he branch blocks of an index include l~a~ blocks e~ch o~ whi~h corresponds to a diffarent $et of the key values, Each key value ~or an sttribut~ data o~iect is in only one o~ the differ~nt sets of key values and, thorefore, only on* lHaf block has a correspon~ence with t~at key value and , the attribute data object to which that key valu~ i~ assigned.
Lsaf blocks include pointers, each o~ which corresponds to S B key valua of the leaf block and to th~ location ln attributo 25 , file 600 ~or tne attribute aata object having th~ ~ey valu~ as ~wO~ls~lss~ it~ assigned key ~alue. Quick acces~ing o~ a de~ir-d attribute FINN~W,~8UD~X~ ' F~R~s~v~ C~
~N~
~Y~n.~,W.

ll~ll~lO~Ot~,~.C,-~OO~
~O~.. ,~.O , 42-RPR 13 '89 14:57 FROM FINNEGRN HENDERSON PRGE.04S

, . .
1308~98 . data object is achieved by entering an index with a key value for the de-~ired attribu~e data object, and by locating ~ unique pathway through the tree str~cture of the index ~o the leaf block having that key val~e and the corresponding pointer to the desired attribute data objec~. .
Accordingly, in the pr~erred embodiment an index's tree structure includ~s a root block to provide an en~ry into the tree structure. The root block "branches~ to a plurality of branch blocks each of which corresponds to a different, non-overla~ping group of the sets of key ~alues to which certainleaf blocka correspond. ~rhe branch blocks are organiz~d to pro-~ ~ide a uni~ue pathway ~rom the root block through one or more mid~le branch blocks to a s ingle leaf block having a co~respond-ins set of key ~alues for which the unique pathway exis~s. ~y 15 organizing th~ roctt, ~iddle branch and leaf blocks in such a manner, the leaf block having a corresponding sot of key val~es, which include~ a key value for ~ d~sired object, can be~ located expe41tiously. In turn, th~ pointer to an attribute data object having that key vdlue 4s its key value can be quickly located, as can tho attribute data object it~lf.
~h~ root branch, middle brancht and leaf blocks of an index , are pre~rably r~presented by ~ndex bran~h block~. Fig. 19 show~ an index branch block 810 which com~r~ses an index branch header block 820 and sevcr~l lndex branch ~ub-~locks 830.
2S Fig. 20 i~ a block d~gr~m of an in~ex ~trnnch header block ~ c~ 820. In ~he pre~errad ombod~ment, branch header block 820 FIN~ N. H~NDE~aN
O CtUNN~ , . .
,"~ . w.
w~ ~O~,O.c.. Ooo~ _43_ ~-0.~ .... O , I , , ~PR 13 '89 14:58 FRO~ FINNEGRN HENDERSON PRGE.04~

~ ,~ ,~
~308198 includes longwords 2000, ~20, 20~0 and 2060. Longword 2000 in-cludes a BRANCH ~IND field 2Q0~, a K~Y ~AL~ES field 2008, a SIZE
field 2012, and a CLASS field ~016.
BRANCH KI~ field 2004 specifieg whether index branch block S 810 is a root, middle branch, or leaf block. A XEY VALUES field 2008 indicate~ the number o~ key ~alues specif ied in sub-bloc~s 830. SIZE field 2012 and CLASS ~ield 2016, respec~ively, indi-cate th~ number of longwords in branch block ~10 and that blo~k 810 is an index branch block.
~ifferent index branch blocks 810 having the same trunk block are linked through longword or N~XT pointer 2020 and longword or PREVIOUS pointer 2040, w~ich point to designated next and previous branch blocks for the same trunk, respective-ly. Longword or TRU~X pointer 2060 points to the trunk ~lock ~or an ind~x branch block 810.
: In th~ p~eferr~d embo~iment, index branch header block 820 i~ followed contiguously by one or more index branch sub-block~
830.
~h~ index bran~h sub-block8 ~30 shown in Fig, 21 pr~ferably includ~ a longword or K~Y VA~UE pointer 2100 and a lon~word or ~EAF/OBJECT po~nter 2150. K~Y VALUE po~nt~r 2100 specifies a location ~ttribute il~ 600 holding a key value.
If index block 810 is a leaf branch block, its ~3A~JOB~CT
field ~lS0 points to an elemen~ block 602 for an attribu~e data o~ct in attribute ~ile 600 ha~ng the k~y value deno~ed by the ~O~C~ corre~ponding K~Y VA~U~ field 2100 in sub-block 830. Othe~wis~, FI~WN, H8~
F~ow, G~u8Tr 1~ DUNN~r~
m~ , w, w~ To~l~o 4~0~~ 44--I~o~ o ~PR 13 '89 14:59 FROM FINNEGRN HENDERSON PRGE.047 .` f~ .~
308~9~3 ~f the in~e~ branch block 810 is a bran~h block, the LEAF~OBJ~CT
field 2150 points to a br~nch blo~k in the ~niq~e pathway to a le~f block, the set of key values of whi~h ~r~ within th~ group of sets for that branch block.
In the pre~erred ~mbodim~nt, each index branch ~lock 810 is used eithar as an ordering index or as an accessing indes. The ordering index is ~sed to insert elements into a list according to prescribed ordering rules and enabl~s quick access to the place in the list of elements, e.g., as described by an instance root block 625 or a held ~lement sub-block 608~ An a~c~ssing indRx is us~d to access existing ~le~ents quickly using a key ~all~e.
In the preferred embodiment of ~he invention, both the or-: doring and acc~ssing indox require use of index directory block 1~ 630, aiscussed briefly with reg~rd to the ~onstituents o~
attribute file 600 (see Fig, 7). A block diagram of ind~x . direc~ory block 600 is ~hown in Fig, 22.
Index directory block 630 includes l~ngword~ 2210, 22S0 and ~270, Longwor~ 2210 inclu~s SIZ~ and C~ASS fi~ld 2230 and 20j 2240, respectlv~ly, which lndicate th~ number of longword~ in index directory block 600 and tha~ block 600 is an ind~x dir~c-tory block. Longword or ORDERING pointer 2250 identif i~s the instance root bloc~ for an ordering index, and lonsword or A~C~SS~NG p~int~r 2200 indicates a root branch block for an 2S access ing index .
~ O~IC~- :
ht~ tJD~
F~uoo~, ~
a DU~"~ .
177~ t, ~. w.
~ o~,~.c.-O~ , -45-~OJ~
, ; a :~ r K ~ l r 1 1~ 1 t ~a l l l`~ r~ C l`~ lJ t rt ~ V I`1 r l l la t . W ~ la Access to an index directory block 630 which d~signates in-. dices for quickly accessing att~ibute data objects is obtainedeither through an instance root block 625 o~ throu~h ~ ~held"
object sub-block 608. Preferably, for attribute data ob~ects held by a context, index pointer 1440 of an instance root block 62~ points to the index directory block 630 so that attribute data objects held by a specified context can be accessed easily, For attribute data objects held by another attribute data ob-ject, index directory block 630 is eccessed using the INDEX
point~r 1120 of the "held" object ~ub-blo~k ~08 specifying des-ignated first and last ones o~ the held objocts. The accessing op~r~tions are explained in greater detail below.
D. B~sic Databaso ODerations Using the pre~erred embodiment of the inveneion, certain lS ba~c data operations ~uch a~ ~reation, erasure, and acces~, can b0 e~ily and eff iciently carried out according to pr~ferred m0thods described b~low. The following description presumes that, whe~her by u~e of A compil~r or d~ct~onary 700, certaLn data llke an ~pex or the contexts which are ,necessary to the creation o~ attribute da~ obje~ts, already ~xist in common data structure~ 140 or 140'. It is also assumod that the elements . and rel~tion~ to be created and the element typ~s and relation typos for the elem~nts and relations to b~ created have alreedy ~e~n speci~ied to data 4tru~t~re 1~0, so that the appropriate element typ~ blocks and r~f~r~t typ~ blooks have alr~y b~en ' ~O~c~ ~ croA~d, F~ a~
FM~, ~M~Tr 0 DuNN~R
m~ A~n, N. W, ~ N~TON. a. ~ ooo~ 4 6 ~o~ o RPR 13 ' 89 15: 00 F ROI~I F I NNE GRN HE NDE RSOI`I PRGE . 049 , ~ ,, _~

. (1) ~l,e~ent C~eation ~ igs, 23A and 23B show a flow diagram 2300 for a preferred method o~ creating an ~lement data object (nnew elementn) according to the present invention, As s~ated above în connec-S tion wit~ the descriptlon of applicati~n p~ograms 132 and 134,these programs either contain the information needed for forming common data structure 140 in memory 120 or ha~e their data~ases alrady organized in accordance with the Attributive data model of ~his invention.
If the application program databases need to be converted to the Attributive data model of thi~ in~ntion, the information :
needed fro~ these programs to create an ~lement is in the form o~ ~node data, n Attribute data objec~s to be created ~ay corre-spond to node data from the a~plication programs or may be spe-cifically derived ~or creati~n, Accordin~ly, creation of an 0lement ~ata ob~ect may involve the extraction of node data from an ~pplication ~rogram and a determin~tlon of the type of corre-sponding elemont data o4joct to be created from the node data.
(Ste~ 2305), ~xamples of such extraction appear in the next 20 ~ section, 'l Onc~ the type o~ the new olement has been determin~d, the in~Sance leng~h, that is th~ len~th o~ olement blocX ~02 ~or the new element, can ~e determined by re~rence to the INSTANC~
. L~GTH field 1730 of an exi~ting element type ~lock 712 for the 25 1 new element (Step 2310).
uw o",c~- :
Fl~lNEc~N~ ND~1~50N
PAIWO~
O DUNN~
. ~, W.
~h~1~o7Oh,O.C.
oo~ 47-, . , RPR 1~ '89 15:01 FROM FINNEG~N HEN~ERSON P~GE.050 , .

Once the instance lenqth is determined, primary memory is checked to see whether storage space i~ available for element block 60~ (s~ep 2315). If storage space does not exist, then primary memory space for that element bloc~ is created (step 2320). The details for managing storage space by ~PU ll~ in permanent and primary memory is described in more detail in a later section and involves virtuat memory and mapping techniques readily ascertainable to a~tisans o$ ordinary skill.
After storag~a space for ele~ent ~lock ~02 in primary memory 0, i5 located or created, that space is allocated for element block 602 for the new element ~Step 2325). CPU 110 then forms a pointer to that allocated primary memory space ~step 2330), ~ ext, ~ holder attribute dat- object i-~ chosen for the new ~ element such that a being-held relationship exists between the l~ ~ew element and it~ holder attr~but~ dat~ object (Step 2335).
Selection o~ the holter attribut~ ~at~ object, allows FIRST, LAST and INDEX po~nters, llO0, 1110 ~nd 1120, rospect~vely, in "held" ob~ect ~ub-block 608 of el~ment block 602 for the holder attrlbute data o4ject to be locat~d (Step 2335)~
FIRS~, LAST and INDEX pointers 1100, lllO snd 1120, respec-tlvely, may be upd~ted t~en to reflect the exi~tence of the new ~lement a~ an element now held by the holde,r ~trlbute data ob-ject. O~ course, updating th~se ~'lelds 15 not necessary if the, new eleme,nt ifJ not th~, Sir,~t o~ last ~lem~"nt held by the holder Z5 ' attrlbute da,t~3 o~,~ect.
~" 0"~0~
f,fNUr.C~. I.~ND6f7~ ':
F~, G~
~ D~
. w. ~ f ~f ~ f~TOI~.o.C,~OOO- ' ,,o,~"~ o -48-RPR 13 '89 15:01 FROM F~NNEG~N HENDERSON PQGE.051 1308~98 .
After lo~ting th~ sub-block 608 pointers, NEXT, PRFVIOUS, .and ~OLDER pointers 925, 940 and 930, resp~ctiv~ly of ~lement : header block 6~4 in element block 602 of the new ~ttri~ute data object ar~T used to link th~ new element to the element block~
for the other elements having the.same holder ~s that new ele-ment and indicates the holder attribute data obj~t for the new element.(Step ~340), This is don~ by locating ~OLDE~ poin~er 930 in object header block 604 for the new object. ~hat HOLDER
point~r 930 points to ~ memory area in which an element block 602 for th~ holder attribute data element of the obiect being created m~y be found. In addition, ol~mont pointers to other attribute data objects which hav~ th~ sam~ holder attribute data object as the new attribute data object are provided as ~EXT
pointer 925 and P~EVIOUS pointer 940. If the new element is the only attributo data object held, no ~inter will be provided in a NEXT pointer 925 of element header block 604 and no obj~ct poin~cr will exi~t ~s PR~VIOUS pointer 940.
Next, the FI~ST, LAST, and INDEX pointers 1100, 1110 and 1120, respecti~ely, on tho "held~ eloment sub-block 608 o~ tho 20 l holder attribute d~ta o~jeCt, whiCh have been previou~ly loca~-ed, ar~ updated to ref lect tho exist~nce o~ th~ n~w element and .I to re~lect it~ ~being-held relationship with the holder ,'. attri~ute data o~ject ~Step 2345). With regard to ~uch updating, i~ th¢ new object i~ the fir~t attributo da~a object ~5 hold by the holder attribut~ data ob~ect, then a poLnt~r to th-Fl~e~WH-N~D;~ elemont block 602 of the holdcr attribute data object will be FA~UOW,C~T
~DU~
1~ 11 ~T~IT~t. /~, W.
ll~5~ t.C.~04a~ 1 0~ -49-, . ~

QPR 13 1 89 15: 02 F ROM F I NNE GRN HE NDE RSON PQGE . 052 ~308198 - pro~ided in the FIRS~ pointer 1100. I~iEX pointer 1130 will al~o be updated to identify an index directory block 630 i~
appropr iste .
To c~mplete the cre~tion of the n~w el~ment in method 2300, other fields of element block 602 must be initiali2ed. For example, TYPE DE~INITION pointer ~2~ of element header block 604 for the new attribute da~a object must be provided with appro-priate pointers, s~ch as a pointer to the element type block 71 in dictionary file 10iO which specif ies the type of the new ele-ment. "Held~ ment i~ub-b'~ock 608 and relation sub-block 606 for tho ne~ element are, initializ~d for such tim~ as the new attribute data object comes to hold or comes to have relations with other attribute data ob1,ects, (2) Creatinq ~ R~l~$,~p~
The step~ shown in Figs, 23A and 23B are sufficient for craation of an element data object. To create a relation data ob~ect, additional 5~eps ar~ needed. Figs. Z4A and 24B show a flow chart 2~00 depictlng the step~ involved in creating a rel~-tion betw0en the new elem~nt and a re~Rr~nt nttribute data ob-20~l ~,ect. A~, indicatod previc,usly, node data deqcriptors in an ' applicatlon program database may be used to form a r~lation, ,~ Alternatively, the relation may be ~ormed by computations pe,r-" formed by one of the applicatio,n ~ro~r~ms. Thus, a node data ~ descrip~or ~rom one of tho application programs can be extracted 25, for u~ ln creatlng a ralation attrlbute dats ob~,ect. This ~w~ c-- extraction ~unction is descrlke,d in groate,r ~etail below, When FINNUW, H~ND~R50N , F,'~, C~P~nT
0 DU~NU~ ;:
ltt711 t f~ t. W.
ttttt~tibil~rtnD~fD~C~U~OO~ ; ~
UO~ O ~, --t i O--,, .

RPR 13 '83 15:0~ FROM FINNEG~N HENDERSON PQGE.053 `` . ~ ' .

extr~ctin~ th~ nod~.data descriptor, the appropriate attribute data o~ject to be the referent attribute data objeet fo~ the re-.lation data object i~ ~lected.
Once the extraction and selection are complete, the rela-tions sub-block 606 in the proper element block 602 is then identified (Step 2405~. From the position of the relation sub-block 606 in element block ~02, the nature of the relation between the holder attri~ute data and-the referent at~ribute data object (i,e., plural or singular) can be determined (Step 2410).
If the relation is singular, ~ pointer from the holder . a~tribute data object to the referent data object will be pro-vided in relation sub-blo~k 6~ of the element block for the corresponding element. If the relation is to ~e plural, a pointer to a plural relation bloc~ 612 will be pr~vided in that rel~tion ~ub-block 606. A ~eferent pointer to the reerent data obj~ct will then ~e pro~id~d in th~ plural rRlation block 612 identified by the pointer iA the oloment block 602 ~or tho c~r-re~ponding elom~nt.
~f the new relation i~ singul~r, a determination must be ,' m~de ~hether the ralation sub-block 606 ~ee ~ig~. 8, 10A and ; l0B) of tho holder attribute dsta object already contains a point~r ~Step 2420~ this is also true, creation of ~ho re-lation will be temporarily halted while a previous relation sp~cl~ied in relation ~ub-blo~k 6~6 i~ era~ed iSO th~t ~ new sin-uwo~C~a i gular relation can ~e created ~Step 2425)- When relation FIN~JI~N. H~ND~h4ON
F~. c~RRcrr ~ DUNN~
T~ 1,W, ' .
w~ oro~, D. ~,~000-(~o~ o -51-., , ' RPR 13 'B9 15:03 FROM FlNNEG~N HENDERSON P~GE.~54 ` 1308~98 . sub-block 606 does not contain a pointer to a referent attribute . data object, then a object pointer to the referent attribute data obje~t for this relation is obtained and placed in relation sub-block 606 ~Step 2430).
If the relation to be created is not singular, th~n a plu-ral relation block 610 is allocated for specifying the new rela-tion data object, unless one has already been allocated (Step 2435). A pointer to the plural relation block for the new rela-tion is then placed into the appropriate relation sub-bloc~ 606 (Step 2440).
: Next, the ~lural relation sub-blocks 614 ~see Figs~ 8, 13A
. and l3B) of the allocated plural relation block 610 dre scanned as well as plural relation sub-blocks 606 in other plural rela-tlon ~lockx linked to the pointed to plural relation bloc~ 610 15 ' (Step 2445). A~ described above, plural relation ~locks 610 ;: ~ra linked by mean~ o~ NEXT an~ PREVIOUS pointers, so scanning pre~er~bly proceed5 using tho8~ polnter$.
If none o~ th0 8canned plural relation sub-blocks 614 are frc~ (Step 245a), then a plural relation block which c~ntains a z0 , fre0 plural relation sub-blo~k 61~ is alloc~ted ~Step 2455).
"i sub-bloçk ~s ree if it docs not contain a ~alid point~r to an ' o~j~ct block 602 for a re~erent data object. ~he n~wly allo-cated plural relation block 61~ i~ then linked with the other , plural relation ~locks 610 for the new object (Step 2~60), 2S ~ Aft~r the allocation an~ linkiny of a new plural rolatlo~s ~o~ block 610, or if a fre~ sub-block in one of th0 linked plur~l :
FIN~J6G~, HtND~
F~, ~P.dTT ~', ill r~UtJ~BR
W~ OOO-/to~ 4~0 ' ~ 52-"' . , .

.

~PR 13 '89 15:04 FROM FINNEGRN HENDERSON PRGE.055 . ! r~ ,~
13~8198 . relations block w~s located, pointer to the referent data object ! iS obtained and placed in the free plural rela~ion sub-block 61 o~ the pl~ral relation block 610 (Step 2~70). N~xt, or after .the pointer ~or a ~ngular relation is obtained, th~ pointer for the re~eren~ is placed into one of the plur~l relation blocks 610. ~hat block 610 is the one accessed from the R~F~R~NCES
pointer 935 of element header block 604 for the element bloc~
602 of the holder attribute data object (Step 24~5).
(3) Relation Erasur~
This section describes erasure o~ all relations of a given type held by a given element. Relation erasure involves fraeing the memory of space used to hold the pointers which relate an : attribute data object to its referent attribute data object.
Fig. ~5 ~hows a flow chart 2500 dopicting the steps involved in :the preferred method of erasing a relation.
First~ the relation sub-block 606 u~ed to r~lat0 the rela-tion's holder attribute data object and r~erent attribute data ob~0ct i5 located (Step ~505) using the OFFS~T 1830 of the rela-tlon type, ~0 " Next, a ~eterm~nation is made, according to the r~lation ,j typo, whethor the rela~ion i8 singul~r ~S~p 2510). I ~o, th~
, plur~l relation blocks 610 specified in the REFERE~ES ~ointer 'i 935 of the referent'~ element block 602 are ~canned to find the o~ect pointer to the holder attribute data object for this re-lation (Step 2515) when tho type i~ not numQric, a date or a ~w~,,,c~- ~tring. ~hen the. obioct po~n~er to the holder attribute data F~ cw, HtNb~N
P~.
OD~
~- ,. ~.... ,.. W.
.~llll~O~Ol~,O.C.DOOO~
010L ~ O li --53--.j , .
,, .

~PR 13 '89 15:05 FROM FINNEG~N HENDERSON PRGE.056 object i5 cle~red fro~ the plural relation ~lock pointed to by the R~FERENCES pointer 935 of the referent's element block 602 (Step 2520), ~in~lly, sub-block 606 in the holder attribute data object which contains a pointer to the referent attribute 5 data object is c}eared along with any string data pointed to (Step 25~5).
If the relation to be erased is not a singular relation, then plural relation blocks 610 of the holder attribute data o~-ject are sc~hned unless the referent type is numeric, a date or a st~ing (Step 2530). ~he purpose of the scanning is to locate the plural relation ~locks 610 ac~essed by the REPFR~NCES point- .
. er of th~ element block 602 for the indlcated referent attribute data ob~ects those referent attribute data objects are the ones : pointed to by the referent pointers in those plural relation lS blocks 610 of the ~ppropriat~ type ~o~ the holder attribute da~a object of th~ relation to be orasQd (Step 2535). Next, the plu-ral r~l~tion blocks 610 acces~ed by the R~F~RFNCES pointQr 935 of those refsr~nt attribute object ~locks are ~canned to find a po~nt0r to the ~lder attri~e data object (Step 2540), " Whon tho pointer to tho hold~r attribute data object is ~ound in a plural r~lntion block 610, th~ holder pointer to the ~, referent ~ttribute data object i8 rendered inoperative by re-setting th~ corresponding bits in BIT MAS~ ~ield 1230. ~hat BI~
~ MASX field 1230 is found ln ~he plural relation header blocks 612 for tho ~lursl relation block~ 610 in which pointers to the ~4~rle~ .. holder attribut~ data object pointer are found. ~incallyl the FI~K~,H~ND~
P~ RR~Tr OD~R
o~ol~ ~,c.~o~o-~o~ o -S4-RPR 13 '89 15:05 FRO~ FINNEG~N HENDERSON P~GE.057 ~308~98 : space for plura~ relatiOn bloeks 610 which were scoaned is re-cl~i~ed along with any string data pointed to and the relation su~-block is cleared (Step 25gS), (4) ~lçment Erasure Fig. 2~ shows a flow chart 26~0 describing the steps by which an element object is erased. After this element is accessed, plural relation blocks 610 for the object being erased ~re obtained ~rom REF~RENC~S pointer 935 for the element to ~e eras~d (Step 2610).
Next, pointers to this element are erased from the plural relstion blocks under the elements accessed from those plural rslation blocks (Step 2620), Aftor erasing these pointers, all singular and plural rela-tion~ held by the olement are erased (Step 2640) and space used by any plural r~lation blo~ks a5~0ciated with this element is also ~roet (Step 2650). All el~mont bloc~s held by the element are ~rased by recursivo use o~ thl~ procedure. Elements or ob-~ects held by th1~ element are then ~ra50d (Stap 2655). Next, lndic~s pointed to by the INDEiX pointer 1120 in the element 2~ ,, block ~or tho el~ment being erased are freed (Step 2660). The element block ~or the element being erased i9 unlinked from ele-' ment block~ for the ~ther elements having thç same holder ~Step ,'~ 26~0) . Finally, space for the elemen~ i~ reclaimed ~Step 2680).
,- ~5) ~
From th~ organization ~f the proforred t~t~ ~tructures ~worr~C~- de~cribed above, as well as from the pre~erred methods for FI~N~
~wow, ~Tr ~D~N~ j In~ n. t~. w.
w~h~O~Ot~ ~ ~
/IC~ 55~

:

RPR 13 '89 15:06 FRO~ FINNEGRN HENDERSON P~GE.058 13~8198 ;creating and er~sin9 elements and relatlons also described abovo, di~fQrent ways of accessing elements and relations will ; be apparent to persons of ordinary skill in the art. Accessing, of course, depends upon thE type of lnformation desired, and the data structure provided in the preferred embodiment show pat~-ways for such accessing.
~ igure~ 27A and 27B show a flow chart 2700 describing a preferred method of accessing common data structure 140 or 140' to find eit~er the elements having a being-held relationship with a giYen element or to find referents of certain relations of that elem~nt. The proced~re roflected by flow chart 2700 may al~o ~e used to obtain held elements and refere~ts o~ relations for m~tiple attri~ute data elements. The described method is not the only such method, but it is pro~ided as illustrative of the type~ o~ method$ which can bo used to carry out the purposes o~ this inventlon.
.; Flow chart 2700 a~umes that during the creation of the common dat~ ~tructur~ 140, a comp~lar or ~ome similar sort of : language ~roces~ing so~tware ~included in conver~er programs 5~0 ~O!~ and 570) gen~rated a virt~l addr~ss or o~aet for ~ach ,l id~ntifier. ~he ~low chart further assumes that common data j structure ~l~cod that virtuaI address or offset in an addross table located in B co~mon ar~a of memory 120 so it could b~
~ accessed by retrieval ~rogr~ms, ~uch as retri~val programs 580 and 590 shown in Figure~ 5A and SB. Those retrieyal prog~ams F wor~ are pr0~rably in~rpr~tflr~, but they could also ~e any oth~r F~WK~ ~T
~D~ER type of lan9uage prw es~in~ 50~twar~, 4uch as c~mpilers.
WAJIIIUIVTCIU. D, C, ~ooe~
00~ 0 ' , -56-RPR 13 '89 15:07 FRO~1 FINNEGRN HENDERSON PRGE.059 , _~
: ~308198 - Flow chart 2tO0 also.assumes that prior to its execution, a virtual address ~or accessing a referent or held element of the given ele~ent has already been retrievetd as have the virtual addresse~ 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 bet made upon entering flow chart 2700 is whether the relations for a hold~r o a given type ~re singul~r or plural (Step 2705). If singular, the next deter~i-, nat~on ~s whether there is a first or next holder of the ele-: ment(s) or relation~s) to be acce~ed (Step 2710). I~ there is no such holder, then a completion indicator is set ~Step 2715), indlcating that the search for all the holders is comple~e, and lS th~ execution of the ~cce~s rc,utine is ended with a return of no re~ult (Step 2720).
If ~h~re was a next holder, tho ofLTset field (e.g., p~int~ ff~
1830 shown in Fig. 18) from the ~ttribute typ~ block is then ~ed to f~nd the offset from the s~art o~ the holder's element 20,l block to f ind ~ pointer to any etlement ~lock for ~he relation or I elemeTnt de~i~ed ~Step 2723). The element block of that next ! holdeTr i~ then retri~ved by using the virtual address from the I addres5 table in the common area of memory 120 (Step 2725).
s Next, a ~etermination mu~t be ma~e to soe wheTther there i5 a re-25'~ tion or he~d elemeTnt for thi~ particul3r holder (Step 2730).
.
If ~o, (l.o~ the Appropriste pointer i8 not zero), then the ~,h~r u~
--T, Il. W~ t ~OI~, O. 0,1000-~o~ O , 7 ,, .

RPR 13 '~9 15:07 FRO~ FINNEGRN HENDERSON P~GE.060 l 1308198 ,virtual address for the attribute type block of the desired 'attribute is examlned to acc~ss that attribute (Step 2735).
When there iB a non-zero pointer, the information about the ,d~sired referent or held element i~ ret~r~ed (Step 2745).
the appropriat~ pointer is zero (Step 2730), then there i~ n~ relation or element of the required type in the elem~nt block of the next holder attribute d~ta object. In this case, if a plurality of h~lders is specified, then a se~rch continues either until a holder is found with ~ relation or an element to lo ,' be returned (Steps 2710, 2723 and ~725), or until there are no .more hold~r~ (Step~ 2710, 2715 and 2720).
, in the initial determination, the attribute type was ,found to be plural (Step 2705), then a determin~tion is made :
wh~ther ~x~cution of the access is first commen~ing (i.e" is ., the examination of th~ entire expres~ion commencing) o~ at lea~t 'SCommencing examination of a new holder ~l~m~nt (Step 2750). I~
'so, then ~s with t~ 5in~1e attrlbute type, the next determina-t~on ~8 whethe~ there ls some next holder (Step 2751). ~f not, ~th~ completion indicator i8 set (Step 2755), and a return i8 20~j m~e with no re~ults Istep 2760), ~¦ If there is ~ n~xt holder, then the element block for that l noxt holder is retrieved IStep 2763), ~nd a determination ls lj made from that el~m~nt block whether there is a rel~tlon block ,j 610 or a ~irst held element for th~ next hold~r. Thi~ can be 2~ ~et-rmined by examining th~ ~lement block for the n~xt holder ~, , U~O~ t~ i~ (Step 27~6), If no attri~ute ex~sts ~or the next holdflr, th~n Fi~ Ww,H~ND~N:
F~WW~,G~T 1~
~D~R ~i ccr,~
W~ OTO4,D,~,~ODC~ ~ ~
~O~ O ~5~~

subsequent holders are obtained and examined until either a holder is obtained which has an attribute (Steps 2751 and 2763) or until there are no more holders (Steps 2751, 2753 and 2760).
From the attribute type block, a determinatlon is made whether those attributes are relations (Step 2773). If so, then the next relation is retrieved from the corresponding plural rela-tion block (Step 2776). Associated with ~he access of this plural relation block is a "place indicator" which keeps track of the next one of the relations from the plural relation blocks to be accessed. This ls done because the routine in flow chart 2700 only returns one result in each access. When the last relation from the plural relation block 610 is obtained, the "place indica-tor" directs that the next inquiry into the existence of a rela-tion or an element to be obtained be answered in the negative.
Each time a relation is obtained, the "place lndicator" is updated to the next posltion, and a return from the procedure is made with the lndlcated result (Step 2780).
If the deslred attrlbute~ were instead found to be ele-ments or lf the examlnatlon was not commenclng (Step 2773), then a determlnatlon would be made whether that element ~as the flrst in a llnked list of element~ having a belng-held relationship with the holder (Step 2783). If not, then the next held element i8 obtalned u~ing NEXT field 925 from the element accecsed lmmedla-tely prior to the present element (Step 2786). A different "place indicator" whlch keeps track of the next as~ociated one of the elements to be accesced is updated to polnt to the next of the held ob~ects. The return ls then made wlth lndlcated results (Step 2780).
If the deslred element was the flrst of the held ele-ments (Step 2783), then the held ob~ect block ls sbtalned uslng the offset polnter and the holder attrlbute data ob~ect's element block, and the approprlate place indiGator is lnitiallzed (Step 2790). The return ls then made wlth the lndicated result (Step 2780).
Flgure 28 ~ihows another example of an access procedure.
The flow chart 2800 ln Flg. 28 ls used for flndlng an attrlbute data ob~ect uslng the lndex flle 800 and a key value. Agaln, lt mu~it be remembered, that flow chart 2800 ls only one method of access and 18 not meant to limlt the lnventlon.
When uslng a key value to ldentlfy and flnd an attrlbute data ob~ect, the lndex dlrectory block (see lndex dlrectory block 630 ln Flg. 8~ 18 searched for that key value (Step 2810). If that key value 18 not found (Step 2820), then a return is made from the routlne ln Flgure 28 wlth no result (Step 2830).
If a key value 18 found, then an lndex result block 2890 shown ln Flg. 28A 18 created with four longwords ~et to the followlng value~ (Step 2840). Flrst leaf node 2891 18 set to the polnter of the leaf lndex branch block 810 contalnlng the flrst occurrence of the deslred key value. Flrst leaf index 2892 con-talns the ordlnal of the lndex branch sub-block 830 ln the lndex branch block 810 whlch 18 the flrst occurrence ln the leaf lndex branch block. Slmllarly, last leaf node iL~

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

RP~ 13 '~9 13:42 FROM FINNE~RN HENDERSON P~GE.003 ~308198~
.
. 2893 and last leaf index 2894 contain a pointer and ordinal, re-spectively, for the last occurrence of the desired key value.
.Index result block 2890 is a temporary data structure crea~ed only for access using index file 800.
N~xt, the address o~ the desired ele~en~(s) is ~ound usin~
index result block 2890 (Step 2850~. If the key is ~nique, then f i rst and last occurrences are the same. If the key is not unique, as may pe the case for the ordering inde~, then ~he com- .
plete set of valid results can be found using the index result 10 , block 2890 ~e~ause the index branch block5 are linked. ~he . pointer to the attri~ute d~ta object is found u~ing the result .~lock.
If the key value is found, it will contain an address in , the attribute data file 600 for a correspondlng attribu~e data g.. object. A return f~om this procedure is then made with the in-dicated result ~Step 2860).
E, Data O~adnLz~tion. Ext~action, and Conversion In accordance with this inveSnsion~ the information used by applic~tion program~ ~uch as program~ S30 and 5~0 ~hown in Fig-20 , ure~ SA and 5B, ~ust be fit into an organization of common da~a '1 s~ructur0 140 ~or 140'). In many cases the application programs i. are previously written in terms o~ their own databa~es, and inother cas~ application ~rograms m~y already use attribute data ,l objects o~ganized in accordance with the pS~esent invention.
2S ' The process o~ extraction and converslon ref~rs to th~
~Or,,-~- ;i m0thods by which data ~rom application p~ogram database~ are FINN~W, ~Dt~N
F~uo~C~RDI~
~ ~S~N~e~ ', ;
17~JI N ~I;~T, 1~. lb, ~ .
N~--OS~-D.c~ ' 61 aS~st~ O

, . . . .
I

QPR 13 '8~ 13:4Z FROM FINNEG~N HEN~E~SON P~GE.~4 .', ~ ,"~.
1308~98 ' , ` converted to the com~on data structure 140 (or 140'). As ~hown : in Figures 5A and 5s, con~erter programs 540 and 570 take data . ~rom the ~pplication dat~bases and convert that data from the for~at in those datab~ses into a format proper for common data - structure 140 ~or 140'.)~
There are several ways to organize a common data structure a~cording to the present invention for each application program database, The organization and çonversien o~ the application program data for the the common data struct~re likely depends upon the contents of the data in the application program datab~se, as well as upon the antici~ated ~sage of the common .
data s~ructure.
, , :
Organization of th~ common data structure, and consequently extraction and conversion, need no~ follow absolute and 15 ' ~nwa~ering rules, Instead, this section contains some ~eneral guidelines and design considerations for persons desirin~ to ~ractice this lnvention. Additional guidellnes and design con slder~t~on~ wi~l be apparHnt to perso~s of ordina~y skill in the art, without undue experimentati~n, from the ~ntir2 description 20'.1 o~ the pre~erred embodiment ~uch as the construction of the pre-! ~erred data ~tructures and the preferred methods o~ access, cr~- .
j at ion, an~ er~sure.
~I Quite often, the first concern in buildin~ a common data ~ ~tructuro according to this invention is the ~election of ele-25 ~ m~nt data objects. Th~ in~orma~ion in the application program L~ a~. '. from ~h~ch element data object~ are oft~n selecte~ can be F~l~GW.H~D~RK~I;
F~o~,Guun~
OD~u~
R. ~, w. ;, ~HII~TO1~ 000~
I~o~ 0 ., ~ ~;7 ~G '' ' RPR 13 '83 13:~3 FRO~ FINNEGRN HENDERSON P~GE.005 ,_, .referred to as node data. Node data ~ener~lly includes "things"that are either "object~" or "subjects" in ~he database. In terms of parts of speech, ther2fore, element data objects are ~ost likely data that would be des~ribed by noun~. For example, node data can include physiçal objects, such as circuits, gates, portions of an engine, or persons. Node data can also include events, such is time line entries or filing dates. ~nother example o~ node data are concepts, such as ideas and colors.
Once the elements are selected, then the holding relatio~-ships between elements are established. The determination of holding rela~ionships usually reflects some hierarchy among the elements. As with the selection of elements themselves, the determination of the hierarchy reflected by the holding rela-tionship iS, in most Cases~ not uni~Ue. Preferably, the de~er-~ination of the hoiding relationship should also take into account the anticlpated use of the data. The existence of a re-lationshi~ between two elements (or betwsen an element and a re-l~tion~ does not necessarily mean that such a relationship should be reflQct~d a~ a holding relationship in ~he common data 20 , ~tructure. .That r~lationship can al80 be represented by the , nanhierar~hical relationship indicated by the relation data ob-~cts~
., The types of relationships which ~re most often rQflected in the holding relationship reilect soms natural hi~rarchy, such 2S ~s offic~s of a ~orporation, or r~1ect th~ con~iituent parts u~O~ of a thing, ~uoh as the parts of a machine, th~ chapt~rs o~:a FINN~G~, HCND~
F~LWO~V, C~rr ~ Dv~tJe~ ;
NIN~T4~l~ O. C . ~ 000 -,.o ~

'; ' '.

RPR 13 'eg 13:44 FROM FINNEG~N HENDERSOI~ P~GE.006 ~308198 book, or ~ities in a st~te. The holding relationships can also refleet the posse~sion of ons thing ~y another.
Once the holding relatîonships are determined, howe~er, a context must us~ally be selected. Aa explained in an earlier 5 . section, the context is a construct to help in naming attribu~e data objects slnce the names of such ob~ects have meaning only in the ~ont~xt holding those o~iects. ~he context should be used to reflect groupings of related attri~ute data objects for convenience of reference and to allow the use of specialized vo-10 cabulary. For example, de~ign information about printed circuit board~ might ~e organized into a di~ferent context from design . information about VLSI chips, so that terminology familia~ in either applic~tion area can be used without conflict. In the example demonstrated in Figs. 3 and 4, th~ term "gate" can have ; differ~nt meanings in these two application areas, The use of separ~to contexts allows the same term "gate~ to ha~e di~f~rent meaning in each context.
One ~an also have ~everal layers of contexts. For example, a first context may contain object~ relat~d to general applica-20 , tion concepts such as version tracking and ~roject management.
.E~ch o~ a plurality of contexts held ~y the first context might contain attribute o~jects for particular technologies, ~uch as mechanical or el~ctrical.
Relations are usually determined next. A~ter the node data , as ~r~ a5~ign~d a~ elem~nt~, the in~ormation remainin~ usually c~n-~O~IC~ cern~ the relations or attributes of such node dat~ which, if FI~N.H~
~ Dur.lN~I~
17~ K ~T"tn. Il. W, TO~. O. C. ~
~OO~ O -64-,' , , RPR 13 '89 13:45 FRO~ FINNEG~N HENDERSON PRGE.~07 " ~
1308~98 .
~not reflected in the hierarchical holding relatioships, ~an be thought of as generally reflecting descriptors of the no~e d~ta.
The purpose of the relations is to reflect nonhier~rchical rela-tionships that exist among attribute data objects. The rela-tions are created so that they associate the appropriate objectsin order to reflect the relationships between node data and their descriptors as expressed by the original applica~ion data.
~xamples of node data d~scriptors, preferably represented by re-la~ions, include the connection of gates to signals, the identi-fication of the designer of a circuit, and the connection ofevents in a project plan.
The final steps of data o~ganization involve type determi-nation and selection of key values. ~he ~typing" of an attrlbute generally follows the designation of e!ements and re-lations, as well as the designati~n of holding relationships.
; ~he type~ generally refl~ct the sets into which the elements andrelations h~v~ already been grouped and describe ~he com-; mon~ ies of the elem~nts or rela~ion~ in those sets.
Th~ ~election of key values depend~ again on the data. The use of koy value~ is primarly ~n aid to acce~, so the determi-, nation and selection of the keys should follow the anticip~tedusage of common data structure 140 or 140'. In addition, the use of key valuos may reflect an ordering of the lnformat~on in , .
the application programs databas~s to facilitate use of such in-formation by the application programs, ~w O~C~-Fl~.H~
F~,G~TT
a DUNN~R :
rll~:R"~ W, ~IIIIIOTCIN, ~1, C. 10~10-- --6 5 ~or~ c~oo ;' .""

~PR 13 '89 13:45 FRO~ FINNEGRN HENDERSON P~GE.008 ~308198 The details of converter programs 540 and ~70 are speci~ic t~ the requirements of application programs 530 and 560, respe~-, tively, the follo~ing example of the prooessing performed by such converter programs is provided to illustrate the guidelines pro~ided above. If an application progra~ 56~ generates the circuit shown in ~igure 3, file 565 (Figure 5A) might contain the following information descriptive of the circuit.
1) AD~ 3-I-A; 320S
2 ) AI~D 320 . 322~S2 3 ) 320 . 324 4) 320 . 326 S) 3~0. 328/51 6) 7) AD~ 2-I-As 330;
. 8 ) A~D 330 . 332 ,; g) 330.33g/Sl ;, 10) 330 . 336/S2 ~ach non-blank line of this file represents a node datum.
~ine 1 calls ~r the creation of three-input AN~ gate 320, Z0 ~ines 2 ~hrough 5 call ~or the creation o pins 322, 324, 326, an~ 328 of g~te 3~0. Llne 7 calls for the creation of two-input .
AND gate 330. Lin~ 5 and 9 indicate that p~n 32a is conne~ted to pin 334 ~y si~n~l "Sl~" Slmilarly, 11n~s 2 and 10 indicate th~t pin 322 i~ conn~cted to pin 336 by signal "s2,"
2S ~i Conv0rter program 570 could ~e d~signed to read file 565 and creat0 common data structure 140 or 140' representing the circuit of Figure 3 using operations de~cri~ed in the proceeding .
~ections, Part o~ the common data s~ructure so created is shown ~ ln Figure 4. Each of ths nthings~ ~l,e,, gates and pins or sig-- u~O~ i nals) i8 an ele~ent. The holding rela~ionships represent the , H~NDOI,SON
F~o~, G~Rm m~ ~1 5Tl~tT, ~. W. ', rq~.D C,~OOO~ --66--OO~ J~ O

. . .

~PR 13 '89 13:4~ FRO~ FINNEGRN HENDERSON P~GE-~09 ,~

hierarchy implicit in the creation -- ~ir~t the AND gates, then i the pins or signals. The remaining relati~nships, such as sig-nal connections and names, are created as r~lations.
F. Storaae Manaqement As may ~e expected, ~he amount of storage required to im-plement an embodiment according the present invention can be quite great. ~his section discusse~ a preferred embodiment of a storage management technique for maintaining, updating and accessin~ common data structure 1~0' in order to achieve bene-10; fits s~ch as a reduction in the amo~lnt of required storage.
~his preferred embodiment of a storage management techniqu~ is also desi~ned to provide an easy and eficient means of `.
a~c~ssing and updating the data structure 140' o~ ~emory 120 by application programs.
The doscription of the storage management technique is based upon t~e representation of the system shown in Figure 5B
showing Common data 4tr~cture 140' as including a copy of master data fil~ 515, snap~hot data file 525, and control filR 555.with lock~ 56B and 569. Storage managem~nt soft~are S66 controls the 20, file4 in common data structure 140', ;~ A block diagrc~m of an embodiment of common data structure140' is ~hown in ~re~ter detail in Figure 29. Figure 29 in-~ludex a master data file 2900, which correspond~ to master data , fils 515 in Figure ~B. Ma~ter data file 2900, shown as including mscr~pag~s 0 - 3, correspondY to the mo~t recent ver-~WO~IC~5 '' sion o~ th~ com~on data ~tructure 140'. That most recen~
FINUU~W,HE~D~O~ , F~,~T
3D~
Irt~ TI~C~,~W~ , W~ TCh, D, C . l Y~7 0 ' 67 I,~bO ~ 0 , '' ~PR 13 ' 89 13: 47 F R0~1 F I NNE G~N HE NDE RSON PflGE . 010 ' ; 1308198 ~ersion iS either the version currently being modified or the one which was most recently modified.
As Fig. 2g shows, each macropag~ in master dat~ file 2900 has an associated numbered entry composed 4f two port ions . ~he larger number of an entry re~ers to the macropage nu~ber and the superscript portion of an entry ~efers to the version number.
~he version number indicates a version of the database as up-dated by a single user. In accordance with the preferred embodiment, newer ~ersions always have a higher number than old~r versionS. The total number of ma~ropa~es depends on the total size of the database.
Snapshot data file 2910 corresponds to snapsh~t data ~ile : 525 in Figure 5~ and includes ~everal slots 0-5. Eaeh slot con-tains a maCropage and corresponds to one of the macropageS from either the current ver ion o~ mast~r data f ile 2900 or from a ~revioUs ver~ion o~ that file, ~he maeropages from previou5 v~rsions O~ th~ m~ster data ~ile 2~00 still maint~in~d in snap-~hot file 2910 are ~or ver~ion~ which are ~til~ activ~ er-slon i~ still activs if thero ig at le~st ona application pro-gram or user whlch is currently ac¢es5ing macropages o~ thdt v~r8ion.

i, ~he numb~red entrl~ associat~d with ea~h macropage in snapshot data ~ile 2910 in~lute a8 the larg~r number a value ~or the corresponding macropage in ma~er data file 2900, and in-clude a5 8 ~uperscrlpt a number indicatlng tho ver~ion o~ that ~WO~C~ macropage.
FINN~ ND~PSON
F~WW~. G~Rm ~ DU~
177511 ~T~ICC~ W, WA~ o~O~ .C,~000 ao~ o ; v ~
;~ ~

~PR 13 '89 13:~7 FRO~ FINNEG~N HEN~ERSON PhGE.011 , 1308198 Af ter master data f i le 2900 is updated, thc~se macropages .: froln the master data file 2900 which were ch~nged are copied into slots of snapshot dal:a f `i le ~910 . This copying accounts for the m~lltiple versions of macropages from the master d~ta f ile 2900 ~hich are stored in snapshot data f ile 2910. The snapshot data file must not grow indef initely, so housekeeping routines, which ~re explained in greater detail below, are in-voked to remove outdated macropages.
Certain of the slots of snapshot data f ile ~910 are 1~ referred to as a "natural slots." A "natural sl~t" refers to a slot in snapshot d~ta file ~910 having a slo~ number which is the same as the corresponding macropage number. This is the ~tate o~ snapshot data file ~910 when it originally recei~es the contents of ~che master data file 2gO0, This initial state, in 15 wnich all the macropage~ ar~ in their natu~al 510ts, is desir~d for ef ficiency.
Dat~ Base Controller ~D~C) 29~0 ~ontrols the storage man~
~gement functions. DBC ~9~0 c~rrespond~ to the control f ile 55 in Figur~ 5B. In general, DBC file 2920 controls the mo~i~ica-20; tion of data structure 140' as well as the acce~s to ~hat d~tastructure. DBC 2920 controls the modification of ~ata struc~ure i 140' by managing and keeping track of changes to th~ data struc-. ture and ~y ensuring, through the use of A~T~R lock (See Fig.
SB) tha~ only on2 u~er can mak~ modification~ ~o a version of a 25'; m~crop~ge of the ~ata struc~ure. DBC ~ i le ~920 ~ont~ol~ acc~ss ~WO~ICt~ . to the data ~tructure by keep~ng track of the location of all F~W~I, H~ND&P5C)N

0 DUNtJ~
t. N, W.
~HIY~ o. ~oCoC ~ 6 9--I~O~ ~

~PR 13 ' ~9 13: 48 F ~01`1 F I NNE G~N HE NDE RSON Pf: GE . 012 1308~98 `
.
, active macropages and by preventin~ collisions with certain users through the ~se of DB~ lock (~ee F~gure 5B).
D~C 2920 contains four major components. One component is ' pointer/eounter section 2922 which indicates where ~he other S porti~ns of DBC ~920 reside. Another c~mponen~ is HAS~ table 29~gs which provides a means for locating the active macropages in snapshot file 2910. version bl4ck section 29~6 contains ver-sion blocks, such as blocks 2930, 2940, and 2gS0, which contain information a~ou~ ~ifferent versions of data structure 140'.
Switch ~l~ck section 2928 contains section blocks, examples of , which are 2~32, 293g, ~936, 2938, 294~, 2944, ~952, 2954, ~g56 a~d 2958, which c,ontain information abou~ the active macropages.
'' Proferably, diferent kinds of switch blo~ks are used for , changes in attribu~e file 600 and in index file 800. If, how- ,.
lS ~ver, the information in attribute file 600 and index ~ile 800 ', re~ided in a single file, one kind of switch block would be nee~ed, In the en~ulng di~cussion, the d~scussion about ~witch' blocka applies to changes elther in attribute file ~00 or index file 800~ ' 20 ' Figur~ 30 shows a preerred embodiment of pointer/counter ~i sections 2922 in groater detail, As ~hown in Figure 30, point-" er/counter ~ection 2922 pr~f~rably ~ontains B user ~ount 3005 ~'. and several other fields and p~inters., User count 3005 ind~-, cates the totsl number of u~er~ which are ~essing or mod~fying 2~ common ~ata ~tructur~ 1~0'. ~ach time ~ new u~er want~ ~o u~o~o-~ , acce~ common d~ta structure 140', the ~,torage managem~nt . :
P~CAN. HE~
F~, ~AI~srr ~ DUNN~ ;
rnc ~ n. N, w. ':
NlN~nON,P.c.~000~1 , 7~
~o~ o "
.. ...

~PR 13 '89 13:4S FRO~ FINNEGRN HENDERSON P~GE.013 . ;
1308~98 - : softw~re obtains the DBC lock, increments user count field 3005, and returnS the DBC lock. ~he p~r~ose of the ~BC }ock in this instance is to prevent multiple userS ~rom sim~lataneously i a~cessing the user count and improperly incrementing it, . ~ollback version number field 3010 and rollback version pointer 3015 refer to a rollback function. This function allows a user to re~ot certain changes made to a version of com~on .: data structure 140'. Rollback occurs only while chan~es which are being made to common data structure 1~0' by.a user are still in progress. Rollback occurs either because the ~ser performing .
; the change~ "voluntarily" decides it doe~ not want to proceed ~ith the c~anges and wishes ~nste~d to restore master da~-a ~ile . 2900 to its sta~e b~ore the ~odifications started, or because , an error m~kes it impossi~le to complete the changes, 15 , In the pref~rred ~mbodiment, the version being rolled back i~ lTully modifled in sccordance with the changes specified by th~ user, The stor~ge m~nagement and up~ating ~eps ~escribed bolow are executedr bu~ this to-b~-rolled-back version of common ~ata structuro 140' i8 not made av~ ble to o~her users. Imme-20~; diately a~ter the ~o-be-rolled-back version has been created, a , new version, the rollback v~rsion, is created. The rollback " version, by use o~ switch 41Ocks in section 2928 and snapshot . data ~ile 2~10, undoes all the change~ ~rought by the to-be-. rolled-bac~ ~ers~on. Accordi~gly, a~ter the roll back the mas-25. t~r dat~ ~ile 2900 ~or the rolled back version ~B~ b~Qn r~turned ,,c.~ , to its state ~efore the roll back soquen~e was in~tiated, Plt N~ H5UD~
F~V. /;~RErr :
E~
n~ Tr~rr~T~ u. w. ;
~11141~TOII.I~,C.~4000 , _7 1 --I~lO~ r~ 4~0 ,~ , .

RPR 13 'B3 13:49 FRO,~ FINNEGRN HEN~fERSON P,9GE.014 ' 1308198 ::
' Snapshot data file 2910 is not return~d ta its state befor~
creation of the to-~,e-rolled back master fil~ 2900. After roll . back, snapshOt data file 2910 contains two additional versions, : the "bad version" that was rolled back and the new current ver-sion. As s~ated above, however, users are not able to read the f~'~ad vers~on, n and the new ~urrent version is just a copy cf the .
ma~ropages initia~ly changed by the "bad vers}on." Thfe ~bad version" is already obsolete at the completion of roll back and . will be deleted by housekeeping routines to be described later.
In pointer/counter section 2922, roll back version nu~ber 3alO refers to the num,ber of the version which is r'rolling backr' the "bad verslon'f' and roll back version pointor 3015 points to the version block of that version number, i : ' Next version number 3020 and next version pointe~ 3025 in ~S~, ~ection 2922 refer to the v~rsion of common data s~ructure 140' which is ei~her currently being updated or, if th~re is no ver-' 8$0n curr.on~ly bf,~lng updated, which will be the vers;on to beupdated nex~. , Curr~nt v~rsion number 3030 and curr~nt v~r~ion pointer 20" 3035 re~er to the most recent version wh~ch is currently re~d-I able. Thi8 is the most current version which is available in ,i, sn~p~hot data ~I,le 2~10. The olde~t version number fi~old 30q,0 ~, and the olda~t vsrsion point~d,~ 3045 refer to the the active ver-~, sion wh$ch is the lea,st recent. ~ield 3040 ~nd ~,ointer 30~f,,~ ar~s"
25,' chang-~4 aiYf common data ~tructuré 143~ is b,eing updated and o~,so-~W4~C~fff i' lete (i.e., ina~tive) version,o are freed.
rlNl~ Nf,~LNf~e~, PM~O~, f~TS
f--~ :
r, ~f(~in, fff . w.
,D,C ~ef~ 7 2--~fffC~ cf ,''f' f' , ~PR 13 '89 13:5~ FRO~ FINNEGRN HENDERSON P~GE.015 ,~
1308~98 -The initial version number 3050 refers to a version of com-mon data structure 1~0' existing at the time an event referred to as a "chec~point~ occurs. For purposes of error recoveryr the contents of common da~a structure 140' in master data ile S 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 th~ data structur~ 140' con-~ents.
Initial version n~mbor 3050 indicates the newest version in 10 snapshot data file 2910 when the most recent checkpoint oc-; curr~d. r HAS~ table 2g24 provides a means for accessing the active ' ~acropages in a manner described in greater detail below. HASH
: t~ble 2924 is preferably a standard HAS~ Table and thus will not 15 be described in any ~urther detail. HASH Tabl~ 2924 preferably contain~ pointers to the swltch block correspondin~ to the most recent ver~ion o~ each macropage. As descrihed bolow, each switCh block i3 linked to its earll~r versions. Thus, by e~tor-ing through HASH table 2924, a us~r can ~oc~te every ~ct iV~T ver-sion o~ e~ch maCropage in snapshot ~ta file 2910. Version area ;
,j 2926 prefernbly includes ~ plurality of version blocks 2930, , 2940 ~nd 2950 shown in Fig. 29. Each one ol tho~e version ,5 blocks prelTorably contain~ the fields and pointers shown in ver- .
, sion block 3100 o~ Fig, 31, Version block 3100 include~ c~ veTrsion number ~i~ld 3110 ~wo~C~ , which identi~ies the numbor of the ver~ion to which version F~ P~W' F~WK~,GW~
n~ ~I s~a, t~
~U~UOTOU, D, ~. ~OOD~ , ~o~ 0 , t ; ' ', RPR 13 '83 13:51 FROM FINNEGRN HENDERSON P~GE.016 ,_ _ ~` '.

block 3100 pertains. This field is also shown sch~matically in Fig. 29 by the numbers 1, 2, and 3 at the ~op of version blocks 2930, 29~0, and 29~0, respectively, . Version use-count field 3120 re~ers to the number of users c~rrsntly accessing the version correspo~ding to version block .
3100. ~.ach time ~ user wishes to initiate a new version, ver-. sion use-co~nt field 3120 of th~ current version 3120 is incre-mented by one. When the user finishes with the version, use-count field 3120 is decr~mented ~y one, The purpos~ of the version use-co~nt 3120 is to identify versions which are no longer being accessed so that th~ macropages of that version can be replaced if newer versions of master data file 2900 become avail~ble.
Newer version f ield 3130 points to the version block for the next most recent version o~ the master aata file 2900. The pointer ln ~ield 3130 effect5 a type of linking shown schema~-ically in Fig. ~9 as veraion block 2930 points to ver~ion block ~940 and ~ersion blo~k ~940 points to version block 2~50, Related to n~wer version ~leld 3130 i~ older version field ~, 3140 which pointa in the opposite dir~ction to thé version block r the next Yersion of master data ~ 2900. Thus the linking etween version blocks i~ bidirectional. AS demonstrated in ~ig. 29, ver~ion block ~950 points to v~rs~on block ~940, which in turn point~ to ver~ion ~lock 2930.
2S The v~r~ion last change~ ~eld 31S0 contain~ a pointer to .
the m~crop~ges ~or the corresponding version which was ~irs~
FIU~ N~
F~B~w. G~R~

T~ T. 1 ~A~NIN~iTOb, tl. 0.1~00O--~on~ ,o . _ .

PPR 13 '89 1~ 51 FRO~ FlNNEGfiN HENDERSON PRGE.017 f '`
1308~8 ,` `
changed mos~ recen~ly. I'he function of this f ield is explained in gre~ter detail below, but as a brief explan~tion, the first time a macropage is chanaed for a particular v~rsion, a "next updated field" of tha~ macropage is changed to contain the con-~ents of version last changed field of the versic~n blo~k 3100, end version last changed field 3150 of version block is changed to point to this macropage. Version last ehanged field 3150 of version kilock 3100 is initially set to zero. The first time each macropage is first changed, it is linked to the head of a 10 list of macropages changed in this version. The version last changed pointer thus points to the ma~ropage tha~ was ~irst . changed mo~t recently.
The reason for this procedure is ef~iciencY in data opera- i ' tion. When a new macropage is first modified, it is very possi-15; ~lo that the ~acropage modified next most recently has beenplaced back on disk to save space in the primary memory. It . woul~ be in~f f icient to retri~v~ this macropage from disk merely to update one ~olnter. It i~ in~ead e~sler ~o update the cor-. responding field of ver~ion block 3100, since that version block:
20" dlw~ys ros~des in primary memory~
; A first attribute switch field 3160 and a first index ,' switch field 3165 point to th~ switch block~ for the a~tribut~
, and index ~le8, re~ectively, which were the fir~t ones crea~edfor the corres~onding version. Of cour~e i~ the at~ributo a~d ind~x ~lles ~re com~ined, then only one of th~$~ field~, is n-c-~- e~ary, FINHtG~'. H~
Ft~, C;~RP,FrT ';
. ~S Siu~ i6R~ .
7n 1~ ~TIt~ l';i. W.
o~" o, c~ oo- _ 7 5 _ ~ou.-~ o RPR 1~ '89 ~3:52 F~'O~ FlNNEGhN HEN~ERSON P~E.01 ,^ ,, ,~ ~

Co~pleting version block 3100 are four YerSiOn initial ~acropage number fi~ld~ 3170, 3175, 3180, and 3185. Th~ initial at~ri~u~e macropage number field 3170 idsPntifies the highest macropage number for the master data file 2900 corresponding to S attribute ~ile 600 at the start of that vers ion ~ For th~ exam-ple in Fig. 29, the n~m~er in field 3170 would be 3. The ini-tial snapshot ~acropage number field 3175 co~tains the highest macropage number in snapshot file 2910 for attribute file 600 at the start of that version. In the example shown in Fig. 29, lO : this field would cont~in the number 5.
~ h~ initial index macropage number fil~ 3180 and the ini-tia~sl sn~pshot index macropage number field 3185 have functions equivalent to those of fields 3170 and 317S~ ut rel~te to mas-t~Tr data and snapshot data files for index file 800. The mast~r lS and snap~hot data files for index file 800 are not shown but are , prelTerably id~Tntical to thes master and sn~pshot data files for ~ttribute file 600. Of cours~ if the lnd~x flle ~0~ is .combined with attribute ~lle 600, ~ields 31B0 ~nd 3185 a~0 not ne~ded.
Th~ switch block section 29Z8 in databa~e control file 2~20 20l~ include the swit~h blocks, 5uch as blocks, 2932t 2934, 2936, ,s 293~ 42, 2g44, 2952, 29~4, 2956, and 29~8 shown i~ Fig. 29 ,. Switch block 3200 in ~ig. 32 i5 an example of such ~witch " block~, ~he preferred embodimaTnt of switch block 3200 applies f, ' to switch block~ which are ~or attribute file 600 a~ well as 25'~ index ~ile B00. I~ ther~ is a single at~ribute/index L~wo~rlc~ ther~ i5 on}y one type of switch ~lock.
F~u~c~, H~
F~, G~p~TT
/~ D~nJ~h "
Tr.~
, W~ O~,O,C~O~tO~ -16- oo~ o ,, . .

~PR 13 'B9 13:53 F~9M FINNEGQN HENDERSON P~GE.019 ! 130~3198 .. Switch block 3200 includes a version n~m~er field 3210 ! ~hich identif ies ~he version number for which that switch block .. exists. This number is also shown in representative fashion in Fig. Z~ by th~ num~er in the upper right-hand corne~s in each of .
these switch blocks.
Switch block 3200 preferably also con~ains .a version point- :
er 3220 which identi~ies the location of the version ~lock for ~he version to which switch block 3250 corresponds. The nex~ :
field, macropage number ~ield 3230, identifies the corresponding .
10. macropage in master data file 2900, or in the e~uivalent mas~er data file ~or index file 800. Micropage slot number 3240 identifies the slot number in snapshot data file 2~10 (or in the snapshot data file fo~ index file 8~03 into which the version of the macropage corresponding to switch block 3200 i5 stored.
lS The next two fields in switch block 3200 are the newer and , older ver~ion ~ield~ 3Z50 and 3260, re~pectively, which contain pointer~ to the switch ~lock~ corresponding to the immediat~ly more recent and the immediately le85 recent v~rsions, respec-tively, o~ the same macropage~ in master data file 2gO0 to which 201! switch block 3200 corresponds~ Although th0 use of these fi~lds explaLned ln greater detail below when discussing how to accf~s co~mon data structure 140', an exampla o~ ~he use of suc~
, field~ can be appreciated by considering Fig. 33.
,~ To aCcess a macropag~, one enteri~ HA5H t~ble 292g with a 25~' d0sircd m~crop~ge number and obtainE~ a pointer to the switch wO,~,cc. . block corre~ponding to the most recent ver~ion of that Fl~N,U~DE~;~ .
i~A~r. C~
~ DU~
W~,~O-O~.~C.~o~ -77-~j~O~ o : !

hPR 13 'g9 13:54 FRE/IYI FINNEI;iflN HENrlEF~SIJN Pi:lGE.0~0 ^` '. ~ .~, . 1308198:
mac~opage. To obtain an earlier version of that macropage, one continues to use the older version pointers 3260 until the switch block for the desired version of the macropage is lo~at-` ed.
Switch ~lock 3~10 also contains a swit~h next pointer 3270 which identifies the next switch block fo~ the same version.
The linking effected ~y switch next field 3270 is shown schemat- .
ically in Fig. 29 by the rlghtward pointing arrows between swit~h blocks 2~52, 2954, 2g56, and 2958: between switch blocks 2942 and 2944; and between switch blocks 2932, 2934, 2930 and 2933. ~he final field in switch bl~Ck 3200 iS the switch b f lags f ield which are switch b flags include a switch-v-shared-slot flag. ~his ~lag is used in roll bac~ error recovery described above. ~he flag indicates that ~nother switch ~lock.
is id~ntlc~l to this switch block. For example, a version n of a macropage x may be a ~l~t y. So also a v~rsion n~2 of a macropage x may be in ilot y, these versions corresponding ~o the identical ~tate of a version ~uSt before and just a~t~r.roll '~ack, ~.
20l With the understanding of the ~ommon structural data 140' ! just provided, the creation and access proc~dur~s d¢scribed gen- .
~ rally for the common da~a str~cture of this invention can be ,~ understood with reg~rd to the spec~fic implem~ntations of this.
.', inv~ntion, Flow chart~ 3300, 3400, 3500, 3$20, 3530 and 3700 in , ~5,~ Pigs. 33-3~ show preferred methods for upd~ting an~ acce~ing u~o~,,cc~ common data struc~ure 140' shown in Figs. 29-32. Pre~erabl~, F~J. HE~JP~
F~, , ot~
W~hl~ so,~D.C.tOOOO : --78~
no~ o , ~PR 13 ~89 13:54 FRO~ FINNEG~N HEN~ERSON P~GE.021 ,_ ~ , . 1308198-the procedures in Figs. 33-36 are carried o~t hy storage and manage~ent software 566.
At the ou~set of the procedure in Fig. 33, the AL~R and ~ C lock~ ~re obtained ~Step ~31~). The purpose of ALTER lock ~8 is to ensure that only one application is ~odifying the com- .

mon data structure 140' at any one time. ~he purpose of ~he D~C
569 locX is to make sure that only one application is modifying the database control file 2920 at any one time.

Next, a new version block is created for this particular vergion (St~p 3315). Then DB~ lock 569 ~n ~e returned (Step The next step is to determine whqth~ the next modification to ~e made is to an unmarked (i.e., previously unmodified in . this version macropage (Step 3325). If so, then several actions have to take plAce.
First, the appllcation obtai~s ~BC lock ~6~ (Step 3330).
Next, the current contents of the last chang~d field of version , . . . . .
block 3150 is copied ~o the next updated field o~ the macropage (Step 3335), Then the pointer to the mac~opage is copied to the 20l version last chanqed ~ield 3150 of the ~ersion block (Step 3340). Finally, ~BC lock 569 is returned (Step 33~5).
If ~he next mo~ification was not to sn unmarked page, or . a~ter th~ macropage has bee~ linked to the ~ersion block, the ~i modlfications to the macropage can b~ made (Step 3350). Subse-quently i~ is determined whether th~re are any more mo~ifica-~wO~c-~ tion~ to be made (Step 33S5). If so, th~n th~ process is :INUE~W~H~N~N ~
P~w~R~ :;
~ DU~ R
177~ K ~ t, W, W.
~JII~WI~OI~, D, C . ~1000- _ UO~ 0 ' / 7--.

., ....
, ~ ~ ' " .. ,.. "`' ' ' " ': ' ' j hPR 13 '89 1~:55 FRO~ FINNEG~N HENDERSON PRGE.022 , .
i 1308198 -.
repeated beginning with the inquiry wh~ther the next modifica-., tion is to an unmarked page ~Step 33~5). If there are no more ', modificati4ns to b~ made, then the CO~MIT routine is called . (Step 3360) to store the ~as~er ~ata file 2~00 macropages to snapshot data file 2910, and to indicate that this version of data structure 140' can now be accessed by oth~r applications programs.
Figure 3g shows a preferred flow-diagram for the COMMIT
ro~tine~ The first s~ep is to get the ~BC lock (Step 3~05).
10 Next, a determination m~st be made as to w~ether the l~st ~' changed field 3150 in version block 3100 is equal to zero. I~
, 80, then no changes have been made. If version last changed ', pointer is not e~ual to zero, changes have been made and initial , housekeeping must be performed (Step 3415). This housekeeping ,' 15'' ls explained in greatér detail below.
N0xt, the ma~ropage indicated by the version last changed polnt~r must be r~trioved (Step 3420). Then the slot numbe3~ fo~ , , that r~trieved macropag~ must be upd~ted to ~ndicate the 310k number of ~ffapshot dat,a file 2910 into which the retrelved 20'~ macropaga is ~o be ~tor~d (Step 3425). Tha~ slot nunber i~
", pr~ferably in some s~rt of li~t contained by t,he storage and 30ftware 565 of fr~ slots for snap~hot dat,a file 2910.
Next, the linkage of the swi~ch block to the ~ersion is ri~led (Step 3430), and the mscropage is copied from master 2S~, data f~l~ 2900 into snapshot ~ata f ~le 2910 at the a~propriate ~WO~IC~ 3 slot number (Step 3435). Th~n, HAS~ table 2924 is updated ~oINNK~N,H8ND~3~N:
~,GU~3.
3~
hWllll~ Db,D,C.~1000-- ' , 0~
--O U-- ' , RPR 13 '~9 13:56 FROM FINNEGRN HENDERSON P~GE.0~3 1308'198 ~
. point to the switch block for this most recent version of the ` modified ~acropage, and to link that switch block to earlier . ver-cions of the switch block for that same macropage tStep : 3440).
After this updating, the next updated fie.ld of the current macropage is o~eined (Step.3445). If that next updated field is no~ equal to zero (Step 3450), indicating that there are additional macropages which were modified, then the next updated macropage is obtained and the proced~re is repeated beginning with the entry into the proper switch block (Step 3~25).
If the next updated field of ~he current macropage is ~ero, , then there are no more modlfied macropages, and intermediate housekeeping is performed ~Step 3460~. This step ~lso takes place if the ~ersion first field is ze~o ~s~ep 3410). This in-15 ' terme~i~te ho~sekeeping is also expl~ined in detail below,, Noxt, the current version number 3030 and the version block ! pointer ~ield 3035 ln the pointer/counter biock 2922 of th~ data ~ase con~rol file ~920 are updated, This i~ now the commit point a~ which time the other application~ become aware of the 20~ newest ver$~on of the master d~ta file 2900 (Step -~465). Then ,i final ~ousekeepLng i~ perormed (Step 3470), and both the ~BC
'¦ and ALT~R ~ocks are returned ~Step 3475).
Figures 35A-C ~how the procedures followed in the initial, ~ interme~iate an~ final ho~sekeeping steps o the COMMIT routine 25~ n Fig, 34. Flow chart 3500 shown in Fig. 35A correspond8 tO
~WO~GC~ ,~ the initi~l housekeeping; flow chart 3520 shown in Flg. 35B
~NNecw, HeN~e~
FM~, C~RRnT
~P~R
m~ t~ 1, W. ~ _ O OI~.D.~ O~ 81--oo~

. .

~PR 13 '89 1~:57 FROM FINNEG~N HEN~ERSON P~E.024 ~1 30819~
'.
~orresponds to the intermediate housekeeping; and ~low chart . 3540 shown in Fig. 35C corresponds to the final housekeepinq, In the initial housekeeping procedure, the fir5t step is ~o delete obsol~te version blocks and switch bloeks (Step 35~5). A
. version block is obsolete when it is not the most recent ver~ion and when, as indicated by version user co~nt field 3120, there are no current user~. A deletion occ~rs by unlinking these switch blocks and verslon bloc~s and by placing the memory cor-responding to these unlinked blocks onto the lis~ of free 10 blo~ k5.
Th~ sizie of master dati~ file 2900 is then compared to the size of snapshot data file 2910. If new macropag~s were ~dded to master data file 2900 making it larg~r than the snapshot file 2~10, then snapshot data file 291~ must be increased acco~dingly lS (Step 3510). When thi~ o~curs, the added macropages to the ~, snapshot file are also put on the list o~ natural ~lots for the corresp~ndin~ mac~opages added to the master data file.
In the intermediate housekee~ing, shown in flow cha~t 3520, the ~ir~t step ~s to evict all squatters (Step 3525). A squat-'er i~ a macropage which i8 in the natural slot for another ex~Sting macropag~. Thus, if the natural slot for m~cropage 3 (~n other word~ slot number 3) has a macropage not ~qual to 3, then that macropage i5 moved ~omewh0re else in snapshot data ,i fil~ 2510, 2~ N-xt, th~ m~cropnge cor~e~pondinq to the ~eant natural ~wor~lc~ ~ 810t~ are moved lnto those natural slots (Step 3~30), ~n our INI`I~N, H~?Jb0R5aN ' ', F~v, C~A~ : j .
pmlN~ "
r, ~. w, ,;
)IIN07011.D.C.~00O : Qq UO~ 0 - V , -'~ ' ;

RPR 13 ' ~9 13: 57 F ROM F I NNE G~N HE NDE RSON PflGE . 0~5 ,_ ~ .
~308198 example, the m~st recent version of the macrep~ge number 3 is then found and inserted b~ck into its natural slot.
In th~ final housekeeping~ the only actions that occur are . the deletion of obsolete versions and switch bloc~s (Step 3~45).
Figure 3~ shows a preferred embodiment of a flow chart 3~0 for ~ccess~ng a desired version of a macropage. In the f i~st step, the HAS~ table is searched to determine the location of ~he most recent version of ~he desired macropage (Step 3~10).
Next, if the HASH table indicates a location for the macropage, the version number of that ma~rop~ge 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 v~rsion fo~ all the other macropaqes, While accessin~ one macrop~ge, however, sev-er~l other versions may have been completed, so the current ~er- , :' :
5~0n may not be the ~ppropriate version.
If the version number o~ the macropage currently acces~ed is ~arger than the version number for the application, then,the switch block pointer ls accessed to f~nd ~he next older verslon mac~opage, in the s~me te~t a~ made (Step 3630). Once the prop- ' ,~ er ver~ion is found, then the switch ~lock for the desired ~' macropage is used to point to the location in the snapshot file 2910 for that macropage (Step 36~0).
If the entry is not found in the ~AS~ ta~le (Step 3610), n~ber 25' thQn th~ mac~op~ga~itself is u~d a~ ~he macro~ege'~ slot num~er u~o~c~ to access ~he macropage (Step 3640). ~'he routine is th~n ND~P,50N
F~U~W.~ ' xited a ~ 'R
m~
~OII!IO'tON, ~I.C.~OOO~
~r~ o ~83-. .

~PR 13 ~8g 13:58 F~O~ FINNEG~N HENDERSON PRGE.0~6 ` ` , :, . ~308~98 . 5y~ary It should be apparent to ~h~se skilled in the art ~hat vA~-ious modifications may be made to this inven~ion without departing from the scope or spirit of the invention. ~hus, it 5 . is intend d that the invention cover modifications and varia-tions of ~he invention, provided they come within the iscope of the append~d cl~ims and their legally entitled equivalents.

.
.

,, f fl' , ~,;

C~ICI~ ' ~INN~N~H~D~W~
- F~WW~.
~D~n~ ~
,W. ,:
~TOH, o, c.~o~- ! -8~-~or~

,, --,

Claims (29)

1. A data structure residing in a memory of a data process-ing system for access by an application program being executed by said data processing system, said data structure including information resident in a database used by said application program and comprising:
a plurality of attribute data objects stored in said memory, each of said attribute data objects containing different information from said database;
a single holder attribute data object for each of said attribute data objects, each of said holder attribute data objects being one of said plurality of attribute data objects, a being-held relationship existing between each attribute data object and its holder attribute data object, and each of said attribute data objects having a being-held relationship with only a single other attribute data object, thereby establishing a hierarchy of said plurality of attribute data objects;
a referent attribute data object for at least one of said attribute data objects, said referent attribute data object being nonhierarchically related to a holder attribute data object for the same at least one of said attribute data objects and also being one of said plurality of attribute data objects, attribute data objects for which there exist only holder attribute data objects being called element data objects, and attribute data objects for which there also exist referent attribute data objects being called relation data objects; and an apex data object stored in said memory and having no being-held relationship with any of said attribute data objects, however, at least one of said attribute data objects having a being-held relationship with said apex data object.
2. The data structure of claim 1 wherein more than one of said attribute data objects can have a being-held relationship with another one of said attribute data objects.
3. The data structure of claim 1 wherein at least one of said attribute data objects is a referent attribute data object for a plurality of said attribute data objects.
4. The data structure of claim 1 wherein at least one of said attribute data objects includes type data descriptive of a relationship between that at least one of said attribute data objects and the other ones of said attribute data objects having a being-held relationship with that one attribute data object.
5. The data structure of claim 1 wherein at least one of said relation data objects includes type data descriptive of a relationship between that at least the one of said relation data objects and the referent attribute data object of that one relation data object.
6. A data processing system executing an application program and containing a database used by said application program, said data processing system comprising:
cpu means for processing said application program; and memory means for holding a data structure for access by said application program, said data structure being composed of information resident in said database used by said application program and including a plurality of attribute data objects stored in said memory, each of said attribute data objects representing different information from said database;
a single holder attribute data object for each of said attribute data objects, each of said holder attribute data objects being one of said plurality of attribute data objects, a being-held relationship existing between each attribute data object and its holder attribute data object, and each of said attribute data objects having a being-held relationship with only a single other attribute data object thereby establishing a hierarchy of said plurality of attribute data objects;
a referent attribute data object for at least one of said attribute data objects, said referent attribute data object being nonhierarchically related to a holder attribute data object of the same at least one of said attribute data objects and also being one of said plurality of attribute data objects, attribute data objects for which there exist only holder attribute data objects being called element data objects, and attribute data objects for which there also exist referent attribute data objects being called relation data objects; and an apex data object stored in said memory and having no being-held relationship with any of said attribute data objects, however, at least one of said attribute data objects having a being-held relationship with said apex data object.
7. The data processing system of claim 6 wherein more than one of said attribute data objects can have a being-held relationship with another one of said attribute data objects.
8. The data processing system of claim 6 wherein at least one of said attribute data objects is a referent attribute data object for a plurality of attribute data objects.
9. The data processing system of claim 6 wherein at least one of said attribute data objects includes type data descriptive of a relationship between that at least one of said attribute data objects and the other ones of said attribute data objects having a being-held relationship with that one attribute data object.
10. The data processing system of claim 6 wherein at least one of said relation data objects includes type data descriptive of a relationship between that at least one of said relation data objects and the referent attribute data object of that one relation data object.
11. The data processing system of claim 6 further including means, coupled between said data structure and said application program, for retrieving from said data structure the ones of said attribute data objects having a being-held relationship with a specified attribute data object.
12. The data processing system of claim 6 further including means, coupled between said data structure and said application program, for retrieving from said data structure the ones of said referent attribute data objects for a specified relation data object.
13. The data processing system of claim 6 further including means, coupled to said data structure, for creating a new attribute data object in said data structure from one of said attribute data objects which is the holding data object for the new attribute data object.
14. The data processing system of claim 13 wherein said means for creating a new attribute data object also includes means for creating that new attribute data object as one of said relation data objects from a referent attribute data object for the new relation data object.
15. The data processing system of claim 9 further including means, coupled between said data structure and said application program, for retrieving from said data structure each of said attribute data objects having type data that are the same.
16. The data processing system of claim 9 further including means, coupled between said data structure and said application program, for retrieving from said data structure the type data from a specified attribute data object.
17. The data processing system of claim 6 further including means, coupled between said data structure and said application program, for removing from said data structure a specified attribute data object.
18. The data processing system of claim 17 wherein said means for removing also includes means for removing from said data structure all attribute data objects which have a being-held relationship with said specified attribute data object and all attribute data objects which have a being-held relationship with any attribute data object removed from said data structure by said removing means.
19. The data processing system of claim 6 wherein said cpu means executes a plurality of application programs, and wherein said data structure is a common data structure for access by all of said application programs and composed of information resident in databases used by said application programs.
20. In a data processing system executing an application program, wherein said application program is accessing a data structure composed of information resident in a database used by said application program, wherein said data structure resides in a memory of said data processing system and includes a plurality of attribute data objects each representing different information from said database, wherein for each of said attribute data objects there exists a holder attribute data object and for certain of said attribute data objects there also exists a referent attribute data object related to a holder attribute data object for that attribute data object, each of said holder and referent attribute data objects being one of said plurality of attribute data objects, and wherein each of said plurality of attribute data objects has a being-held relationship with its holder attribute data object thereby establishing a hierarchy of said plurality of attribute data objects, a method of accessing attribute data objects in said data structure comprising the steps of:
selecting, by said application program, information resident in said database;
searching, by a data management program executed by said data processing system, said data structure for one of said attribute data objects representing said selected information;
retrieving, by said data management program, the attribute data objects having a being-held relationship with said one of said attribute data objects representing said selected information; and transmitting to said application program by said data management program, information related to said retrieved attribute data objects.
21. In a data processing system executing an application program, wherein said application program is accessing a data structure composed of information resident in a database used by said application program, wherein said data structure resides in a memory of said data processing system and includes a plurality of attribute data objects each representing different information from said database, wherein for each of said attribute data objects there exists a holder attribute data object and for certain of said plurality of attribute data objects there also exists a referent attribute data object related to a holder attribute data object for that attribute data object, each of said holder and referent attribute data objects being one of said plurality of attribute data objects, and wherein each of said attribute data objects has a being-held relationship with its holder attribute data object thereby establishing a hierarchy of said plurality of attribute data objects, a method of access-ing attribute data objects in said data structure comprising the steps of:
selecting, by said application program, information resident in said database;
searching, by a data management program executed by said data processing system, said data structure for one of said attribute data objects representing said selected information;
retrieving, by said data management program, a referent attribute data object for said attribute data object representing said selected information; and transmitting to said application program by said data management program, information related to said retrieved referent attribute data object.
22. In a data processing system executing an application program, wherein said application program is accessing a data structure composed of information resident in a database used by said application program, wherein said data structure resides in a memory of said data processing system and includes a plurality of attribute data objects each representing different information from said database, wherein for each of said attribute data objects there exists a holder attribute data object and for certain of said attribute data objects there also exists a referent attribute data object related to a holder attribute data object for that attribute data object, each of said holder and referent attribute data objects being one of said plurality of attribute data objects, and wherein each of said attribute data objects has a being-held relationship with its holder attribute data object thereby establishing a hierarchy of said plurality of attribute data objects, a method of creating attribute data objects in said data structure comprising the steps of:
selecting, by said application program, information to be entered into said database;
creating, by a data management program executed by said data processing system, an attribute data object for said selected information;
choosing, by said data management program, one of said attribute data objects as a holder attribute data object for said created attribute data object, the chosen holder attribute data object being chosen according to said selected information; and entering, by said data management program, the created data object into said data structure.
23. The method of claim 22 further including the step of choosing a referent attribute data object for said created attribute data object from said data structure, said chosen referent attribute data object being chosen according to said selected information.
24. A method for creating a data structure for access by an application program, said application program 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 program, and said method comprising the steps, executed by said data processor, of:
(a) creating a different one of a plurality of attribute data objects from said application data;
(b) organizing said plurality of 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 objects, a holder data object, a hierarchical being-held relationship existing between each attribute data object and a single holder data object;
(c) establishing nonhierarchical relationships for certain ones of said attribute data objects created from said application data by choosing, from said attribute data objects, referent data objects for the ones of said selected attribute data objects, each chosen referent data object corresponding to one of said attribute data object, said selected attribute data objects being called relation data objects and attribute data objects without referent data being called element data objects;
(d) creating an apex data object with which at 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, each of said holding pointers indicating one of said attribute data objects having a being-held relationship with that attribute data object; and (h) entering referent pointers into said attribute file, said referent pointers reflecting said nonhierarchical relationships between said attribute data objects.
25. In a data processing system including a central processor and a memory, said memory containing a data structure with 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 certain ones of said attribute data objects have nonhierarchical relationships with others of said attribute data objects, and wherein each of said attribute data objects has an associated memory area includ-ing pointers to memory areas for other ones of said attribute data objects which have a being-held relationship with that attribute data object, a method for adding new attribute data objects to said data structure comprising the steps, executed by said central processor, of:
creating a memory area for said new attribute data object;
choosing, as a holder attribute data object, one of said attribute data objects, said new attribute data object having a being-held relationship with the chosen one of said attribute data objects;
adding in the memory area for said holder attribute data object, a pointer to the memory area of said new attribute data object; and linking said new attribute data object with other ones of said attribute data objects having a being-held relationship with said holder attribute data object.
26. In a data processing system including a central processor and a memory, said memory containing a data structure with 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 certain ones of said attribute data objects have nonhierarchical 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 nonhierarchical relationship between one of said attribute data objects and a referent one of said attribute data objects comprising the steps, executed by said central processor, of:
determining a location of said referent attribute area object;
accessing the memory area for the one of said attribute data objects; and placing a pointer to said referent attribute data object location in said memory area of the one of said attribute data objects.
27. The method according to claim 26 wherein said non-hierarchical relationship is one of a predetermined type of relationships, wherein said memory includes a type area identify-ing said types of nonhierarchical relationships and identifying where in a memory area for said attribute data objects to find pointers to referent attribute data objects having said predetermined type of relationship to said attribute data objects, and wherein the step of placing a pointer includes the substeps of determining the one of a predetermined type of said nonhierarchical relationship;
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.
28. In a data processing system including a central processor and a memory, said memory containing a data structure with a plurality of attribute data objects each having hierarchical being-held relationships with a single holder one of said attribute data objects or with an apex, wherein certain ones of said attribute data objects have nonhierarchical relationships with others of said attribute data objects, and wherein each of said attribute data objects has an associated memory area containing sequence pointers to ones of said attribute data elements having a being-held relationship with a single holder one of said attribute data objects, a holder pointer to said single holder one of said attribute data objects, and referent pointers to any of said attribute data objects with which that attribute data object has a nonhierarchical relationship, a method for erasing a memory area for one of said attribute data objects comprising the steps, executed by said central processor, of:
locating said memory area for the one of said attribute data objects;
erasing from said memory area for the one of said attribute data objects any referent pointers to any of the ones of said attribute data objects with which the one of said attribute data objects has a nonhierarchical relationship;
locating the memory area for said holder attribute data object;
erasing from said memory area for the one of said attribute data objects said holder pointer for the one of said attribute data objects;
adjusting said sequence pointers in said memory area for the one of said attribute data objects to remove any pointers to the one of said attribute data objects; and erasing the memory area for all containment tree ones of said attribute data objects which have a being-held relation-ship with the one of said attribute data objects or which have a being-held relationship with another one of said containment tree attribute data objects.
29. In a data processing system including a central processor and a memory, said memory containing a data structure with 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 certain ones of said attribute data objects have nonhierarchical relationships with referent ones 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 attribute data objects with which that attribute data object has a nonhierarchical relationship, said associated memory area for each of said referent attribute data objects containing a nonhierarchical relationship pointer to that attribute data object having a non-hierarchical relationship with that referent attribute object, a method for erasing A desired nonhierarchical relationship between one of said attribute data objects and a referent one of said attribute data objects comprising the steps, executed by said central processor, of:
locating the memory area for the one of said attribute data objects;
locating the referent pointer to said referent attribute data object in the memory area for the one of said attribute data objects:
locating said referent attribute data object using said referent pointer;

locating the nonhierarchical relationship pointer to the one of said attribute data objects in the memory area for said referent attribute data object;
erasing said nonhierarchical relationship pointers; and erasing said referent pointer.
CA000596586A 1988-04-13 1989-04-13 Data processing system having a data structure with a single, simple primitive Expired - Fee Related CA1308198C (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US07/181,105 US5664177A (en) 1988-04-13 1988-04-13 Data processing system having a data structure with a single, simple primitive
US07/181,105 1988-04-13

Publications (1)

Publication Number Publication Date
CA1308198C true CA1308198C (en) 1992-09-29

Family

ID=22662924

Family Applications (1)

Application Number Title Priority Date Filing Date
CA000596586A Expired - Fee Related CA1308198C (en) 1988-04-13 1989-04-13 Data processing system having a data structure with a single, simple primitive

Country Status (5)

Country Link
US (1) US5664177A (en)
EP (1) EP0368965A1 (en)
JP (1) JPH02501516A (en)
CA (1) CA1308198C (en)
WO (1) WO1989009972A1 (en)

Families Citing this family (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5604899A (en) 1990-05-21 1997-02-18 Financial Systems Technology Pty. Ltd. Data relationships processor with unlimited expansion capability
EP0601254A1 (en) * 1992-12-10 1994-06-15 International Business Machines Corporation Method for allowing the access of a database by an application program
US6446199B1 (en) * 1995-06-06 2002-09-03 International Business Machines Corporation Disk drive incompatible firmware recovery
JPH0934763A (en) * 1995-07-19 1997-02-07 Fuji Xerox Co Ltd Device and method for managing file
GB9604522D0 (en) * 1996-03-02 1996-05-01 Univ Strathclyde Databases
US5845296A (en) * 1996-07-10 1998-12-01 Oracle Corporation Method and apparatus for implementing segmented arrays in a database
US6173327B1 (en) 1996-07-11 2001-01-09 Jeroen De Borst Object-oriented method and apparatus for information delivery
US6263485B1 (en) 1996-07-11 2001-07-17 Andrew Schofield Method and apparatus for describing an interface definition language-defined interface, operation, and data type
US5897636A (en) * 1996-07-11 1999-04-27 Tandem Corporation Incorporated Distributed object computer system with hierarchical name space versioning
US7212632B2 (en) 1998-02-13 2007-05-01 Tecsec, Inc. Cryptographic key split combiner
US6885747B1 (en) * 1997-02-13 2005-04-26 Tec.Sec, Inc. Cryptographic key split combiner
US6694433B1 (en) * 1997-05-08 2004-02-17 Tecsec, Inc. XML encryption scheme
US6735253B1 (en) 1997-05-16 2004-05-11 The Trustees Of Columbia University In The City Of New York Methods and architecture for indexing and editing compressed video over the world wide web
US8077870B2 (en) * 1998-02-13 2011-12-13 Tecsec, Inc. Cryptographic key split binder for use with tagged data elements
US7079653B2 (en) * 1998-02-13 2006-07-18 Tecsec, Inc. Cryptographic key split binding process and apparatus
US7095852B2 (en) * 1998-02-13 2006-08-22 Tecsec, Inc. Cryptographic key split binder for use with tagged data elements
US6122679A (en) * 1998-03-13 2000-09-19 Compaq Computer Corporation Master DMA controller with re-map engine for only spawning programming cycles to slave DMA controllers which do not match current programming cycle
US6141738A (en) * 1998-07-08 2000-10-31 Nortel Networks Corporation Address translation method and system having a forwarding table data structure
US8631066B2 (en) * 1998-09-10 2014-01-14 Vmware, Inc. Mechanism for providing virtual machines for use by multiple users
US7143434B1 (en) 1998-11-06 2006-11-28 Seungyup Paek Video description system and method
US6978262B2 (en) * 1999-01-05 2005-12-20 Tsai Daniel E Distributed database schema
WO2000045307A1 (en) * 1999-02-01 2000-08-03 The Trustees Of Columbia University In The City Of New York Multimedia archive description scheme
US6941325B1 (en) * 1999-02-01 2005-09-06 The Trustees Of Columbia University Multimedia archive description scheme
US6463439B1 (en) * 1999-07-15 2002-10-08 American Management Systems, Incorporated System for accessing database tables mapped into memory for high performance data retrieval
US6125395A (en) * 1999-10-04 2000-09-26 Piiq.Com, Inc. Method for identifying collections of internet web sites with domain names
US6523042B2 (en) * 2000-01-07 2003-02-18 Accenture Llp System and method for translating to and from hierarchical information systems
US6684222B1 (en) 2000-11-09 2004-01-27 Accenture Llp Method and system for translating data associated with a relational database
US20020169639A1 (en) * 2001-05-09 2002-11-14 Jeffrey Yu Systems for generating radiology reports
US7130457B2 (en) * 2001-07-17 2006-10-31 Accuimage Diagnostics Corp. Systems and graphical user interface for analyzing body images
US6901277B2 (en) 2001-07-17 2005-05-31 Accuimage Diagnostics Corp. Methods for generating a lung report
US20030028401A1 (en) * 2001-07-17 2003-02-06 Leon Kaufman Customizable lung report generator
WO2003051031A2 (en) 2001-12-06 2003-06-19 The Trustees Of Columbia University In The City Of New York Method and apparatus for planarization of a material by growing and removing a sacrificial film
US6910040B2 (en) * 2002-04-12 2005-06-21 Microsoft Corporation System and method for XML based content management
CA2391717A1 (en) * 2002-06-26 2003-12-26 Ibm Canada Limited-Ibm Canada Limitee Transferring data and storing metadata across a network
US20040044686A1 (en) * 2002-08-28 2004-03-04 Shiang-Yu Lee Information object emulator
US7577675B2 (en) * 2003-04-30 2009-08-18 Oracle International Corporation Determining a mapping of an object to storage layer components
US7685008B2 (en) * 2004-02-20 2010-03-23 Accenture Global Services Gmbh Account level participation for underwriting components
US7213103B2 (en) * 2004-04-22 2007-05-01 Apple Inc. Accessing data storage systems without waiting for read errors
US7499939B2 (en) * 2004-10-18 2009-03-03 International Business Machines Corporation Method for efficiently managing membership in a hierarchical data structure
WO2006086508A2 (en) 2005-02-08 2006-08-17 Oblong Industries, Inc. System and method for genture based control system
WO2006096612A2 (en) 2005-03-04 2006-09-14 The Trustees Of Columbia University In The City Of New York System and method for motion estimation and mode decision for low-complexity h.264 decoder
US7814129B2 (en) * 2005-03-11 2010-10-12 Ross Neil Williams Method and apparatus for storing data with reduced redundancy using data clusters
US7523146B2 (en) * 2005-06-21 2009-04-21 Apple Inc. Apparatus and method for peer-to-peer N-way synchronization in a decentralized environment
US8495015B2 (en) * 2005-06-21 2013-07-23 Apple Inc. Peer-to-peer syncing in a decentralized environment
US8537111B2 (en) 2006-02-08 2013-09-17 Oblong Industries, Inc. Control system for navigating a principal dimension of a data space
US8370383B2 (en) 2006-02-08 2013-02-05 Oblong Industries, Inc. Multi-process interactive systems and methods
US9910497B2 (en) 2006-02-08 2018-03-06 Oblong Industries, Inc. Gestural control of autonomous and semi-autonomous systems
US9823747B2 (en) 2006-02-08 2017-11-21 Oblong Industries, Inc. Spatial, multi-modal control device for use with spatial operating system
US8531396B2 (en) 2006-02-08 2013-09-10 Oblong Industries, Inc. Control system for navigating a principal dimension of a data space
US7797670B2 (en) 2006-04-14 2010-09-14 Apple Inc. Mirrored file system
US7860826B2 (en) 2006-08-04 2010-12-28 Apple Inc. Method and system for using global equivalency sets to identify data during peer-to-peer synchronization
US8078687B1 (en) * 2006-09-06 2011-12-13 Marvell International Ltd. System and method for data management
US7657769B2 (en) 2007-01-08 2010-02-02 Marcy M Scott N-way synchronization of data
JP5905662B2 (en) * 2007-04-24 2016-04-20 オブロング・インダストリーズ・インコーポレーテッド Protein, pool, and slows processing environment
WO2009126785A2 (en) 2008-04-10 2009-10-15 The Trustees Of Columbia University In The City Of New York Systems and methods for image archaeology
US10642364B2 (en) 2009-04-02 2020-05-05 Oblong Industries, Inc. Processing tracking and recognition data in gestural recognition systems
US9952673B2 (en) 2009-04-02 2018-04-24 Oblong Industries, Inc. Operating environment comprising multiple client devices, multiple displays, multiple users, and gestural control
US9740922B2 (en) 2008-04-24 2017-08-22 Oblong Industries, Inc. Adaptive tracking system for spatial input devices
US9740293B2 (en) 2009-04-02 2017-08-22 Oblong Industries, Inc. Operating environment with gestural control and multiple client devices, displays, and users
US9495013B2 (en) 2008-04-24 2016-11-15 Oblong Industries, Inc. Multi-modal gestural interface
US8723795B2 (en) 2008-04-24 2014-05-13 Oblong Industries, Inc. Detecting, representing, and interpreting three-space input: gestural continuum subsuming freespace, proximal, and surface-contact modes
US9684380B2 (en) 2009-04-02 2017-06-20 Oblong Industries, Inc. Operating environment with gestural control and multiple client devices, displays, and users
WO2009155281A1 (en) 2008-06-17 2009-12-23 The Trustees Of Columbia University In The City Of New York System and method for dynamically and interactively searching media data
US8671069B2 (en) 2008-12-22 2014-03-11 The Trustees Of Columbia University, In The City Of New York Rapid image annotation via brain state decoding and visual pattern mining
US9305288B2 (en) * 2008-12-30 2016-04-05 Ford Global Technologies, Llc System and method for provisioning electronic mail in a vehicle
US20100190439A1 (en) * 2009-01-29 2010-07-29 Ford Global Technologies, Llc Message transmission protocol for service delivery network
US9317128B2 (en) 2009-04-02 2016-04-19 Oblong Industries, Inc. Remote devices used in a markerless installation of a spatial operating environment incorporating gestural control
US10824238B2 (en) 2009-04-02 2020-11-03 Oblong Industries, Inc. Operating environment with gestural control and multiple client devices, displays, and users
US8266029B2 (en) * 2009-09-04 2012-09-11 Hartford Fire Insurance Company System and method for managing data relating to investments from a variety of sources
US9971807B2 (en) 2009-10-14 2018-05-15 Oblong Industries, Inc. Multi-process interactive systems and methods
US9933852B2 (en) 2009-10-14 2018-04-03 Oblong Industries, Inc. Multi-process interactive systems and methods
US20110225228A1 (en) * 2010-03-11 2011-09-15 Ford Global Technologies, Llc Method and systems for queuing messages for vehicle-related services
US8718632B2 (en) 2010-08-26 2014-05-06 Ford Global Technologies, Llc Service delivery network
US9990046B2 (en) 2014-03-17 2018-06-05 Oblong Industries, Inc. Visual collaboration interface
US10529302B2 (en) 2016-07-07 2020-01-07 Oblong Industries, Inc. Spatially mediated augmentations of and interactions among distinct devices and applications via extended pixel manifold

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4183083A (en) * 1972-04-14 1980-01-08 Duquesne Systems, Inc. Method of operating a multiprogrammed computing system
CH632365A5 (en) * 1978-01-30 1982-09-30 Patelhold Patentverwertung DATA EXCHANGE PROCESS BETWEEN MULTIPLE PARTNERS.
US4583164A (en) * 1981-08-19 1986-04-15 Tolle Donald M Syntactically self-structuring cellular computer
US4462077A (en) * 1982-06-24 1984-07-24 Bell Telephone Laboratories, Incorporated Trace facility for use in multiprocessing environment
US4631664A (en) * 1983-07-19 1986-12-23 Bachman Information Systems, Inc. Partnership data base management system and method
US4635189A (en) * 1984-03-01 1987-01-06 Measurex Corporation Real-time distributed data-base management system
US4649479A (en) * 1985-02-28 1987-03-10 International Business Machines Corp. Device driver and adapter binding technique
US4774661A (en) * 1985-11-19 1988-09-27 American Telephone And Telegraph Company, At&T Information Systems Database management system with active data dictionary
US4805134A (en) * 1986-01-09 1989-02-14 International Business Machines Corporation Electronic system for accessing graphical and textual information
GB8613069D0 (en) * 1986-05-29 1986-07-02 Univ Manchester Parallel storage allocation
US4791561A (en) * 1987-04-17 1988-12-13 Wang Laboratories, Inc. Interactive construction of means for database maintenance

Also Published As

Publication number Publication date
US5664177A (en) 1997-09-02
WO1989009972A1 (en) 1989-10-19
JPH02501516A (en) 1990-05-24
EP0368965A1 (en) 1990-05-23

Similar Documents

Publication Publication Date Title
CA1308198C (en) Data processing system having a data structure with a single, simple primitive
US4864497A (en) Method of integrating software application programs using an attributive data model database
US5561793A (en) System and methods for data field management in a computer database system
US5201048A (en) High speed computer system for search and retrieval of data within text and record oriented files
US6374252B1 (en) Modeling of object-oriented database structures, translation to relational database structures, and dynamic searches thereon
US7424490B2 (en) System for document management and information processing
US5745896A (en) Referential integrity in a relational database management system
US7610317B2 (en) Synchronization with derived metadata
EP0113352B1 (en) Database management system for controlling concurrent access to a database
US20120210298A1 (en) Locating changes in source code
Kornacker High-performance extensible indexing
US20050114365A1 (en) System and method for removing rows from directory tables
WO2001063480A2 (en) Browser oriented method to view database structures
JPH08123713A (en) File storage managing system for data base
Sheng Non-blocking Lazy Schema Changes in Multi-Version Database Management Systems
JP3157235B2 (en) Data management device
JP2940567B2 (en) Image database system
Walker An information retrieval package for microcomputers
JPS63124147A (en) Directory managing system for file system
JPH041855A (en) Document/drawing control system
Leone et al. Design and implementation of a document database extension
Pazel et al. The system architecture of EAS-E: An integrated programming and data base language
JPH08147328A (en) Method and device for retrieving document
JPH03180943A (en) Record storage system
JPH04138565A (en) Connection processing system of plural files

Legal Events

Date Code Title Description
MKLA Lapsed