Connect public, paid and private patent data with Google Patents Public Datasets

Method for online revision control

Info

Publication number
WO1997050052A2
WO1997050052A2 PCT/US1997/009688 US9709688W WO1997050052A2 WO 1997050052 A2 WO1997050052 A2 WO 1997050052A2 US 9709688 W US9709688 W US 9709688W WO 1997050052 A2 WO1997050052 A2 WO 1997050052A2
Authority
WO
Grant status
Application
Patent type
Prior art keywords
version
database
field
table
list
Prior art date
Application number
PCT/US1997/009688
Other languages
French (fr)
Inventor
Alan J. Eisenberg
Original Assignee
Base Ten Systems, Inc.
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

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRICAL DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/30Information retrieval; Database structures therefor ; File system structures therefor
    • G06F17/30286Information retrieval; Database structures therefor ; File system structures therefor in structured data stores
    • G06F17/30289Database design, administration or maintenance
    • G06F17/30309Managing data history or versioning
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRICAL DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/30Information retrieval; Database structures therefor ; File system structures therefor
    • G06F17/30286Information retrieval; Database structures therefor ; File system structures therefor in structured data stores
    • G06F17/30345Update requests
    • G06F17/30377Details of updates performed during online database operations; commit processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRICAL DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/30Information retrieval; Database structures therefor ; File system structures therefor
    • G06F17/30286Information retrieval; Database structures therefor ; File system structures therefor in structured data stores
    • G06F17/30345Update requests
    • G06F17/30348Concurrency control
    • G06F17/30351Optimistic concurrency control
    • G06F17/30356Optimistic concurrency control using versioning
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99951File or database maintenance
    • Y10S707/99952Coherency, e.g. same view to multiple users
    • Y10S707/99954Version management

Abstract

A method for controlling a database comprises storing field definitions defining a version of the database, storing an effectivity table including descriptors corresponding to the versions and field definitions and an effective date for each and storing records with data for the fields along with a date when the record was created. When the version of the database is changed, only revised field definitions are stored and the stored effectivity table is updated only with changes in a state of field definitions and/or version changes and the effective date thereof.

Description

METHOD FOR ONLINE REVISION CONTROL

BACKGROUND OF THE INVENTION

The present invention relates to a

manufacturing execution system and, more specifically, to

the versioning or revision control of the system database

and electronic batch records.

Manufacturing execution systems, which control

the manufacture of food products, pharmaceuticals,

mechanical and electronic equipment, chemical

compositions, etc., generally maintain a database of

information which controls and supports the production

process . These systems also record event data relating

to particular events in the manufacturing process and

support data.

The support data comprises numerous records,

each of which having a plurality of fields in which data

is stored. From time to time in such a system, it is

necessary to revise the internal definitions that are

used for the fields of the support data, although the

external appearance to the user may be unchanged. Each

time the internal definitions of data fields are changed,

this results in a new version of the database.

In prior systems, if a change was made to

information relating previous activities to the previous version of information, this event was recorded in a

chronological log, and then the change was applied to the

database causing a new modified version of the database

to exist. Additionally, the state of the information

database as it appears when the event occurs, if it was

required to be available with associated events (such as

production operation) , would require storing the

appearance of all pertinent data with the record, thus

causing the environment to be stored with each record.

This is cumbersome and impractical. Since pertinent data

cannot always be identified at the time the event is stored, since after the fact auditing may require

information that was not anticipated at the time of the

first occurrence, all data might have to be stored or

referenced at the time of storing, and a recreation of

the database from this stored data would be required.

This would be long and laborious.

SUMMARY OF THE INVENTION

The main object of the present invention is to

provide a method for the online revision control of the

database to give the system the ability to permit

modifications to information used for controlling and monitoring a manufacturing process while still being able

to easily recreate the environment that existed when a

specific product was manufactured when a specific action

was performed.

A key feature of the present invention is to

not have to construct a list of all items associated with

any version of the environment, but rather, to minimize

the number of records within the database so that

sufficient information is available to reconstruct the

total environment at any instance in time.

Another object of the present invention is a

method which allows previous versions of the database to

be reapplied, for example, summer and winter hours being

alternately made effective, thereby giving traceability

to when the discontinuous times each of the versions was

active.

The version control of database records along with the effectivity control according to the present

invention will permit the association of information and

its exact appearance to its use. Specific information

has an internal definition of use while having an

external appearance to the user. The system according to

the present invention is able to associate the internal use with data as well as through effectivity control to

define the user appearance at the time of a specific

occurrence.

The system only requires revised fields, which

define a new version, to be stored along with entries in

an effectivity table. If a previous version is to be

used, then only version entries in the effectivity table

need be added.

Another object of the present invention is to

provide list control which is able to identify the

correlation of item usage with the entire list itself.

One advantage of the present invention is that

the environment at any instant can be reconstructed

through the correlation of different versions of elements

of the database along with the effectivity control

information. This is extended to lists of elements to be

able to reconstruct all members of the list at any

instant .

The method in accordance with the present

invention is useful in critical or regulated processes

where the ability to reconstruct the entire environment

which also includes that part of the environment of

interest quickly at any point in time in order to prove proper operation is essential.

In accordance with the invention, when an

existing field is modified, this generates a new field

closely linked to the first on previous records, but with

a new version.

Since the user will only have one version

actively being used for new inputs, but all versions

might have been used in the past, there are records in

the system which define their active field as a previous

version. Also the actual effectivity of the field might

shift between versions.

If viewed on a time line allowing one to know

when a specific version was effective, particularly if

there is a disjointed use of changeable field

definitions, a subsidiary effectivity table along with

all records which use the information identifies the data

and its version and will allow reconstruction of the environment at any instant in time. For lists of data, a

structure using headers and list entries will allow

recreation of the list at any instant while permitting

complete correlation of entries from the alternatives of

the list.

These and other features of the present invention are achieved in accordance with the present

invention by the method according to the present

invention comprising storing field definitions to define

a version of a database, storing an effectivity table

including a descriptor for each version (corresponding to

a consistent set of fields) or field definition and the

effective date therefor, storing records with data for

the fields along with a date when the record was created,

changing the version of the database, thereafter storing

only revised field definitions and updating the stored

effectivity table only with changes in a state of field definitions and version changes and an effectivity date

therefor. The act of storing records can be repeated as

many times as is desired. The version of the database

can be thereafter optionally changed along with the

storing of revised field definitions and updates to the

effectivity table. The database version is reconstructed

for a given record by obtaining the creation date of the

given record, searching the stored effectivity table to determine the active version and the active fields of the

database when the given record was created, and obtaining

the stored active field definitions. All records

referred by the given record also contain a version definition within the given record in order to get an

immediate correlation of the given record and its

ancillary data. As a result, even if the database has a

different version of the ancillary record, this given

record is intrinsically tied to the version that existed

at the time the given record was created.

Where at least one of the fields is a list

field comprising a list of items each having a

definition, the method further comprises storing item

definitions defining a header version of the list field

and storing a second effectivity table for the list.

When the version of the list field is changed, only

revised item definitions are stored along with a revised

header and the second effectivity table is updated with

only changes in state and header versions and the

effective dates thereof. The list field is reconstructed

for a given record by obtaining the creation date of the

given record, using the creation date to search the

second effectivity table for the active header and the

active items at the time the record was created and

obtaining the stored active item definitions.

These and other features of the present

invention are described in more detail with regard to the attached drawings, wherein:

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a block diagram of a manufacturing

execution system using the method according to the

present invention;

Fig. 2 shows the database of Fig. 1 in

accordance with the present invention;

Fig. 3 shows another portion of the database in

accordance with the present invention; and

Figs. 4-7 are flow charts of the method according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION

In a manufacturing execution system such as the

one shown in Fig. 1, various workstations 12A-12N are

distributed throughout the production system and control

various functions of the manufacturing execution system,

such as receiving and inventory management, dispensing,

quality control, scheduling, resource management,

equipment management, human resources management,

security, production positions, waste management and

facility and equipment monitoring and control . Data from each of the workstations 12A-12N is stored in the

database 11 under the control of a server 10 all

communicating over a central bus 13.

The database 11 can be stored in a memory which

can be an optical memory, a semiconductor memory, a

magnetic memory or other conventional memories that are

presently available. The server and workstations are

preferably microcomputers, such as those using the

Pentium microprocessor or the Power PC processor.

In the manufacturing execution system, data is

entered at each workstation under the control of the

system software and user defined rules for each data

field that will be stored in records in the database 11.

These user defined rules will change from time to time,

and each time there is a change, the version of the

database is changed.

For example, for the production of a

pharmaceutical composition, a master production control

record must be defined which includes a recipe of the

materials, steps, people and equipment needed for the

manufacturing process. The various fields for the master

production control record for each item to be

manufactured would include an identification number for the record, an identification number for the item to be

produced, the batch size, a list of components to use, a

list of processes to perform, a description of each step

of production, controls to be made, the identification of

the operator, a list of qualifications for each step of

production, how the product is to be handled, the

labeling for the product, operating procedures for

sampling, testing and production. Also included are a

list of approved suppliers for each material used in the

batch, the equipment to be used during production and the

persons qualified for operating that equipment. The

field may also include a label format for the item being

produced having a particular appearance and data areas

thereon.

As shown in Table I, for the sake of clarity,

the master production control record is shown to include

six fields A-F. It is understood that more or less

fields can be used. These definitions are stored in the database 11, as shown in Fig. 2.

As is also shown in Table I, at different times

T1-T8, the field definitions are changed. Thus, the

revision of field definitions of fields A, B, E and F

result in revised fields Al, Bl and El which are effective at time T2. These changes become version V2 of the database.

For example, fields A-F relate to a starting

material used in a process and define the material by its

normal expiration time, its name, whether or not it is an

active ingredient, its material code, the unit of measure

used, and the supplier, respectively. Thus, in version 2

of the database, the normal expiration for the material

would be changed from six months to nine months, the name

of the material would be changed, and the unit of measure

would change from kilograms to pounds .

At time T3 , a third version V3 of the database

is created by the change in field A to A2 and the change

in field El back to the previous definition version E and

the change of field F to FI. Version 4, which is created

at time T4, involves the change of Bl to B2, C to Cl, E

to El and FI to F2.

At some time in the future at T5, it is

desirable to again use version V2 of the database to

create records and likewise at time T6, version VI is

used, at time T7, version V4 is used and at time T8, a

new version V5 is created.

Each time a field definition is revised, the

TABLE I

TABLE 0

definition is stored in database 11 as is shown in Fig.

2. When a previously created field definition is used,

there is no need to store its definition, because it is

already in the database.

In accordance with the invention, the database

11 also stores an effectivity table, the data for which

is shown in Table II. In this table, the system stores a

descriptor for each field definition and version and the

effective dates for each. Thus, the initial entries in

the table include A-F, VI and their effective date Tl .

At time T2, there is a change of state of A to

Al, B to Bl, E to El and a change in version of VI to V2,

and the effective date of each is T2. The effectivity

table is updated with this information, as shown in Table

II. When the user returns to a previous version, as in

the case of going to version V2 at T5, since the active

fields for version V2 can be obtained from the change of

state information already in the table, the system only

has to store the descriptor V2 with effective date T5.

Table II is a chronological ordering sorted by

each element in time, though database 11 memory can keep

the listing in any suitable order. This table thus

defines the effectivity of each change associated with each record and is an active indication which defines the

current active version and active element of each field.

This active indication and the effectiveness entries

completely define the state of the system at any time.

Thus, while version VI of the database may have

been created at time Tl, it is effective during the time

period from Tl to T2 and during the period from time T6

to T7. If a record created at some time TX which was

between times T6 and T7, one need only look at the

entries in Table II stored in database 11 to determine

that the active field definitions at that instant in time

were A, B, C, D, E, F.

Thus, aside from the definitions for each of

the fields and their revisions, all that one needs to

store in memory in order to completely reconstruct the

state of the machine at any given time is the effectivity

Table II.

As further changes are made to the fields, the

new definitions are stored in memory and entries are

added into the effectivity table stored in memory.

When data is stored in the database, such as in

records 1-N, the record includes the data for the various

fields, as well as the date that the record was created. In order to then recreate the state of the

system at the time that the record was created, the

system searches the effectivity table stored in the

database memory to see which version and which field

definitions were active at that instant in time and then

obtains those field definitions which are already stored

in memory. This information enables the environment to

be totally reconstructed.

When a field is a list field, such as field F

in Table I, the list can be controlled in a manner

similar to that of the database versioning control.

As shown in Table III, the list field F has a

header version HI associated with it at time Tl, and each

element of the list 1-5 is given a header number, so that

the elements of the list are numbered F1.1-F5.1.

At each time T2-T8, if the definition for a

particular list item is changed to create the list versions F, FI, F2 and F3 shown in Table I, the system

need only store the definitions for the various items

F1.1-F5.2, as well as an effectivity table shown in Table

IV. Additionally, the effectivity table will contain the

effective time of each of the header versions themselves.

Thus, if an item changes, we know the effective time of TABLE m

TABLE rv

the new item, and if the whole list changes, then we know

the effective time of the list.

Table IV indicates each change of header

version and change of state of a list item and the time

at which it became effective. Thus, field F, for

example, a list of approved suppliers, is changed to

version 2, corresponding to FI, when a particular

supplier is temporarily not approved, or changes to form

version 3 (F2) when a supplier is temporarily added.

This would correspond to the changes of F4.1 and F4.2 and

F5.1 and F5.2. By storing the times at which changes in

state became effective, the list of items for any

particular header can be recreated from the stored

effectivity table when the creation date of a record is

known.

If at a later time the list is again changed to

a previous version, then the header version member need

only be stored, such as HI at T5. If a new version of

the list is created, the new list item definitions are

stored along with the version number and the effective

date thereof, such as the version H4 at T8.

Figs . 4 and 6 show the steps according to the

present invention for defining the various versions of the database and the various headers used for recreating

the database.

Although the steps are shown in a particular

order, it is understood that the order may be changed and

still be able to carry out the method according to the

present invention.

As shown in Fig. 4, in 100, the field

definitions are stored in the database 11 under the

control of the server 10. This defines one version of

the database. A descriptor for each field definition and

its effective date, as shown in Table II, form an

effectivity table stored in database 11 in 101.

Thereafter, records are stored with data for the fields

along with a creation date in 102. At some point in

time, the version of the database is changed in 103.

This is done by revising one or more field definitions or

returning to an earlier defined version. According to

the invention, only the revised field definitions are

stored in memory in 104, and the effectivity table is

updated to include only changes in the state of the field

definitions and/or version changes and their new

effective dates in 105.

The storing of records is repeated as desired and the version is optionally changed with the

corresponding storage of revised field definitions and

updates to the effectivity table in 106.

In Fig. 6, referring to the database entries in

Fig. 3, in 200, the item definitions are stored in the

database 11 to define a header version of the list. A

descriptor for the header version, each item definition

and its effective date, as shown in Table IV, form a

second effectivity table for each list and is stored in

the database 11 in 201. Only new versions of items need

to have their effectivity stored, i.e., a new descriptor

is created where at least one item in the list does not

match any previous version of the list.

Thereafter, records are stored with data for

each list field and a creation date in 202. This data is

shown in Fig. 2. At a point in time it is desired to

change the version of the list in 203 by revising an item

definition or returning to an earlier defined version.

In accordance with the invention, only the revised item

definitions are stored in memory in 204, and the second

effectivity table is updated to include only changes in

header versions and changes in the state of the item

definitions and their effective dates in 205. The version of the list is optionally changed

along with the storing of only revised item definitions

and updates to the second effectivity table in 206.

The user of the system is able to recreate the

list version for a given record using the method

according to the present invention as shown in Figs. 5

and 7.

If the user selects a given record in 110, the

system under the control of the server 10 obtains the

creation date of the given record in 111. With this, the

effectivity table is then searched and in 112 for the

active version and active fields at the creation date.

In 113, the system is able to obtain the stored active

field definitions identified from the effectivity table.

From this, the system is able to reconstruct the database

version for the given record in 114 under the control of

the server 10.

This would be particularly useful for trying to

recreate the format and entries for a particular label

that was used in an earlier version of the database.

Since even though the active version is used for all new

labels created, there are still labels which were created

from previous versions of the label definition which must be recognized and interpreted. Thus, in actuality,

multiple versions of a definition can be active

simultaneously.

Similarly, a version of a list field can be

reconstructed for a given record which is selected in

210. The creation date of the given record is obtained in 211, and the effectivity table is searched in 212 for

the active header and active items at the creation date.

The stored active item definitions for the identified

active items are obtained in 213, and the version of the

list is reconstructed for the given record in 214, all

under the control of the server 10.

It is understood that the embodiments described

hereinabove are merely illustrative and are not intended

to limit the scope of the invention. It is realized that

various changes, alterations, rearrangements and

modifications can be made in the acts and steps by those skilled in the art without substantially departing from

the spirit and scope of the present invention.

Claims

What is claimed is :
1. A method for controlling a database,
comprising the acts of :
a. storing field definitions defining a
version of a database;
b. storing an effectivity table including
descriptors corresponding to the version and the field
definitions and an effective date for each;
c. storing records with data for the fields
along with a date when the record was created;
d. changing the version of the database; e. storing only revised field definitions and
updating the stored effectivity table only with at least
one of field state changes and version changes and the
effective date thereof; and
f. repeating the act of storing records and
optionally repeating acts d and e.
2. The method according to claim 1, further
comprising reconstructing a database version for a given
record by
obtaining the creation date of the given
record; searching the effectivity table for an active version and for active fields at the creation date; and
obtaining the stored active field definitions.
3. The method according to claim 1, wherein
at least one of the fields is a list field comprising a
list of items each having a definition and further
comprising for each list field:
g. storing item definitions defining a header
version of the list field;
h. storing a second effectivity table
including descriptors corresponding to the header version
and the item definitions and an effective date for each;
i. changing the version of the list field; j . storing only revised item definitions and
updating the stored second effectivity table only with at
least one of item state changes and header version
changes and the effective date thereof; and k. optionally repeating acts i and j.
4. The method according to claim 3, further
comprising reconstructing a list field version for a
given record by obtaining the creation date of the given record; searching the second effectivity table for an
active header version and active items at the creation
date; and
obtaining the stored active item definitions.
5. The method according to claim 4, further comprising reconstructing a database version for the
given record by
searching the first effectivity table for an
active version and active fields at the creation date; and
obtaining the stored active field definitions.
6. The method according to claim l, wherein
the database is a database for a manufacturing execution
system.
7. The method according to claim 6, wherein
the records comprise support data for a manufacturing
execution process.
PCT/US1997/009688 1996-06-12 1997-06-04 Method for online revision control WO1997050052A2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US08660945 US5970503A (en) 1996-06-12 1996-06-12 Method for online revision control
US08/660,945 1996-06-12

Publications (1)

Publication Number Publication Date
WO1997050052A2 true true WO1997050052A2 (en) 1997-12-31

Family

ID=24651566

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1997/009688 WO1997050052A2 (en) 1996-06-12 1997-06-04 Method for online revision control

Country Status (2)

Country Link
US (1) US5970503A (en)
WO (1) WO1997050052A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101702161B (en) 2009-11-05 2012-07-04 金蝶软件(中国)有限公司 Data extraction method, device and data management system

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6223343B1 (en) * 1997-04-04 2001-04-24 State Farm Mutual Automobile Insurance Co. Computer system and method to track and control element changes throughout application development
US6393458B1 (en) * 1999-01-28 2002-05-21 Genrad, Inc. Method and apparatus for load balancing in a distributed object architecture
US7617175B1 (en) * 1999-04-21 2009-11-10 Cisco Technology, Inc. Method and apparatus for upgrading a database in a redundant environment by release chaining
US6385768B1 (en) * 1999-09-30 2002-05-07 Unisys Corp. System and method for incorporating changes as a part of a software release
US7174353B2 (en) * 2003-10-24 2007-02-06 International Business Machines Corporation Method and system for preserving an original table schema
US7799273B2 (en) 2004-05-06 2010-09-21 Smp Logic Systems Llc Manufacturing execution system for validation, quality and risk assessment and monitoring of pharmaceutical manufacturing processes
US7444197B2 (en) 2004-05-06 2008-10-28 Smp Logic Systems Llc Methods, systems, and software program for validation and monitoring of pharmaceutical manufacturing processes
GB0410288D0 (en) * 2004-05-07 2004-06-09 Pickering Paul Continually versioned,editioned and audited database
JP2006004024A (en) * 2004-06-16 2006-01-05 Fujitsu Ltd Program for execution by directory server
US7299102B2 (en) * 2004-12-02 2007-11-20 Norman Ken Ouchi Method and system for engineering change implementation
EP1785893A1 (en) 2005-11-15 2007-05-16 Paul Pickering Temporal relational databases
US20070250549A1 (en) * 2006-04-24 2007-10-25 Abb Ab Updating of Objects in Object-Based Control Systems
US20090271021A1 (en) * 2008-04-28 2009-10-29 Popp Shane M Execution system for the monitoring and execution of insulin manufacture
US8949824B2 (en) 2012-09-28 2015-02-03 Wal-Mart Stores, Inc. Systems and methods for installing, managing, and provisioning applications
US9235491B2 (en) 2012-09-28 2016-01-12 Wal-Mart Stores, Inc. Systems and methods for installing, managing, and provisioning applications
US9317269B2 (en) 2012-09-28 2016-04-19 Wal-Mart Stores, Inc. Systems and methods for installing, managing, and provisioning applications
US9128792B2 (en) 2012-09-28 2015-09-08 Wal-Mart Stores, Inc. Systems and methods for installing, managing, and provisioning applications

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4646229A (en) * 1982-11-15 1987-02-24 At&T Bell Laboratories Time-ordered data base
US4558413A (en) * 1983-11-21 1985-12-10 Xerox Corporation Software version management system
US5191534A (en) * 1990-08-21 1993-03-02 International Business Machines Corporation Engineering and manufacturing change control mechanism
US5278979A (en) * 1990-12-20 1994-01-11 International Business Machines Corp. Version management system using pointers shared by a plurality of versions for indicating active lines of a version
US5586313A (en) * 1993-02-12 1996-12-17 L.I.D.P. Consulting Services, Inc. Method for updating a file

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101702161B (en) 2009-11-05 2012-07-04 金蝶软件(中国)有限公司 Data extraction method, device and data management system

Also Published As

Publication number Publication date Type
US5970503A (en) 1999-10-19 grant

Similar Documents

Publication Publication Date Title
Braglia et al. A new value stream mapping approach for complex production systems
US5873087A (en) Computer system for storing data in hierarchical manner
US5983241A (en) File management system and file management method
US6014633A (en) Method for the analysis and standardization of bills of resources
US6917941B2 (en) Method and apparatus for creation and maintenance of database structure
US5233533A (en) Scheduling method and apparatus
Bravoco et al. A methodology to model the functional structure of an organization
US5897636A (en) Distributed object computer system with hierarchical name space versioning
US6163774A (en) Method and apparatus for simplified and flexible selection of aggregate and cross product levels for a data warehouse
US5978811A (en) Information repository system and method for modeling data
US5905984A (en) Computer-implemented control of access to atomic data items
US6920457B2 (en) Virtual database of heterogeneous data structures
US5796614A (en) Level-by-level explosion method for material requirements planning
US20030023622A1 (en) Manual activity persistence in content management workflow systems
US6901408B2 (en) Method of structuring a catalog
US6609100B2 (en) Program planning management system
US5701453A (en) Logical schema to allow access to a relational database without using knowledge of the database structure
US5444842A (en) Method and apparatus for displaying and updating structured information
US6341279B1 (en) Method and apparatus for event modeling
McDonald et al. Utilising simulation to enhance value stream mapping: a manufacturing case application
US5311424A (en) Method and system for product configuration definition and tracking
US20060064428A1 (en) Methods and apparatus for mapping a hierarchical data structure to a flat data structure for use in generating a report
US6292797B1 (en) Method for determining actionable patterns in a database
US6199059B1 (en) System and method for classifying and retrieving information with virtual object hierarchy
US5713020A (en) Method and system for generating database queries containing multiple levels of aggregation

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE HU IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG UZ VN AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase in:

Ref country code: JP

Ref document number: 98503039

Format of ref document f/p: F

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct app. not ent. europ. phase
NENP Non-entry into the national phase in:

Ref country code: CA